如何核查开源通信应用？哈希、签名与审计

开源让人能够检查代码，但本身不能证明已安装的应用就是这些代码，也不能证明它没有漏洞。评估通信应用时，最好区分几种证据：源代码、构建过程、文件签名、协议测试和审计报告。

每种证据究竟说明什么？

证据	主要作用	单独不能证明的事项
可阅读的源代码	能够检查设计与实现	与安装文件一致，或不存在任何缺陷
可复现构建	能够比较从指定源代码和环境生成的输出	代码本身安全
APK 签名	核查签名，以及文件与可信签名密钥的关联	应用行为无害
SHA-256 哈希	相对于可信摘要，发现字节差异	当攻击者同时替换文件和摘要时，文件仍然真实可信
测试向量	对指定输入输出检查特定行为	覆盖所有状态和执行路径
独立审计	对指定范围和版本的检查结果	为未来所有版本提供永久保证

可复现构建不等于下载一个哈希相同的文件

按照 Reproducible Builds 的定义，可复现性指的是从指定的源代码、环境和指令构建出相同的输出。如果你只是将下载文件与开发者公布的哈希进行比较，那么做的是完整性检查；你还没有亲自从代码构建文件。

评估可复现性声明时，应索取代码版本、依赖项、构建指令，以及其他人复现结果的报告。“源代码在 GitHub 上”不能代替这些证据。

如何正确理解 APK 检查？

1. 从官方渠道获取明确版本的文件。
2. 从你信任其真实性的来源获取摘要和签名者信息。
3. 计算文件哈希，并与同一版本的数据比较。
4. 在技术检查中，还应验证签名；官方工具 apksigner 支持此操作。
5. 如果发现不一致，停止安装并查明原因；不要为了绕过错误而重新签名文件。

供已安装 Android SDK Build Tools 的专业人员使用的验证命令示例：

apksigner verify --verbose --print-certs app.apk

app.apk 只是示例文件名。命令成功运行并不意味着可以不必知道发布者的有效可信密钥。

Proof Lab 起什么作用？

Livara Proof Lab 提供用于特定检查的工具。请阅读每项实验的范围：文件哈希、密钥协商示例和拒绝篡改数据回答的是不同问题。一次密码学演示成功，不等于审计了整个已安装应用、服务器、更新机制或账户管理。

Livara 威胁模型 也明确指出，如果攻击者同时替换 APK 文件和显示的摘要，仅凭哈希一致不能证明真实性。这是哈希检查的普遍局限，并非某个通信应用特有的问题。

阅读审计报告时应问什么？

• 哪个组织或哪些人进行了检查？公开报告在哪里？
• 检查的是哪个版本和哪次 commit？
• 哪些部分不在检查范围内？
• 重要发现是如何修复并重新测试的？
• 你安装的是同一版本，还是包含相应修复的版本？

在这些问题没有得到回答前，不要仅凭“已获认可”等词语下定论。采用标准算法，也不等于整个产品获得了标准认证。

对选择通信应用的启示

开源与可验证性不是竞争关系，而是互补的证据。优先选择声明准确、可追溯且范围明确的产品。然后把同样的检查用于自己的使用场景，例如群组、网页版、备份和关联设备，而不是从一次测试成功推导出绝对安全。