APP签名的透明性如何影响用户信任？

传统APP签名建立在一个隐含假设之上：有合法签名的应用就是可信的。然而，当攻击者可以窃取签名密钥并用它签署恶意软件时，这个假设就崩塌了。签名的存在只能证明“这个二进制文件来自持有该私钥的人”，却无法证明“这个二进制文件是开发者打算公开发布的那个版本”。数字签名是“出身证明”，而二进制透明性才是“意图证明”。Google直言：“仅靠二进制文件的签名已不够充分”。APP签名的透明性，正是为了填补这一信任鸿沟——它通过公开、可验证的日志，将用户对签名的信任从“盲目”升级为“可查证”。

传统签名的信任困境：有签名不等于可信

用户面对一个带有合法签名的APP时，实际上在进行一场赌博。签名证书由CA机构签发，CA核实了开发者的身份，但这只能说明“这个应用来自某某公司”。它无法回答一个更关键的问题：这个版本的APK，真的是开发者打算发布到用户设备上的那个吗？攻击者可以入侵开发者的构建系统，用合法密钥签署一个被篡改的版本；内部员工可以恶意植入后门并签名发布；甚至CA机构本身也可能被攻破。Fraunhofer研究所对Google Play上97%的免费应用进行了评估，发现当前的签名实践“使得定向攻击变得异常容易，且几乎不可能被用户和应用开发者检测到”。传统签名提供的是一个“非黑即白”的二元判断——签名有效则通过，无效则拒绝——却无法回答“这个有效签名是否被滥用”这个更致命的问题。

透明性日志：将“隐式信任”变为“可验证信任”

透明性机制的核心是一个“只可追加、不可篡改、公开可审计”的加密日志。Google的Android二进制透明性将每一个官方发布的APK的哈希值、包名和版本号记录在日志中。任何收到可疑APK的人，都可以查询这个公开日志：如果APK的哈希不在日志中，即使它有合法的Google签名，也不是官方发布的版本。Google明确承诺：2026年5月1日之后发布的生产Android应用，如果不在这个账本上，“Google就没有将其作为生产软件发布”。微软的签名透明性服务则更进一步——它为每一个签名事件生成一个加密收据，永久记录“谁在什么时候签署了什么”。这套机制基于零信任原则，将信任从“相信签名”转变为“验证记录”。

透明性日志的威慑力在于：即便攻击者窃取了签名密钥，他要么选择不把恶意APK记录到日志中（这本身就是危险信号），要么留下一个永久的、公开的、不可抹除的犯罪记录。攻击的可发现性大幅提升，供应链攻击的防御率也因此显著提高。微软Azure CTO Mark Russinovich在发布签名透明性时指出：“即使攻击者入侵了签名密钥，他们也无法掩盖行踪——任何篡改或意外的签名都可以被任何一方通过透明性日志检测到”。

透明性如何重塑用户信任：从“盲信”到“可查证”

透明性对用户信任的影响，本质上是将信任的决策权从操作系统和开发者手中部分交还给用户和独立审计方。在传统模式下，用户只能信任“系统说这个签名有效”。在透明性模式下，任何用户、安全研究员或独立第三方都可以查询公开日志，自行验证一个APK是否真的是官方发布版本。Google鼓励外部独立方监控其透明性日志的完整性，并报告任何篡改行为。这种“众包验证”机制大幅降低了攻击者隐藏恶意签名的可能性。

更重要的是，透明性改变了信任的性质。Google将其描述为从“隐式信任”向“可验证信任”的演进。透明性创造了问责制的基础——如果软件不在账本上，Google就无法否认其发布意图；如果出现了一个账本上没有记录的签名版本，任何人都可以提出质疑。微软的签名透明性服务则作为一个“公正的签名公证人”，为软件供应链提供了独立验证的能力。这种“可查证性”本身就是信任的增强剂——当用户知道每一个签名都有公开记录可查时，对签名的信任就不再是盲目依赖，而是建立在可验证事实之上的理性判断。

APP签名的透明性不是要取代签名，而是要给签名加上一层“公开验证”的外衣。签名证明“谁签的”，透明性证明“这是开发者打算发布的那个版本”。Google的二进制透明性和微软的签名透明性正在将信任从“隐式假设”重塑为“可验证事实”。对于用户而言，这意味着他们不再需要无条件信任一个看不见的签名——他们拥有了一个公开的、可查询的“真相来源”。透明性不会让攻击消失，但它让攻击者再也无法在不留下公开记录的情况下完成一次签名攻击。而这，恰恰是用户信任最坚实的基石。