在移动设备安全领域，一场关于信任根归属的暗战正在上演。当银行 App 要求验证设备运行的是「原厂系统」，当政府应用拒绝 GrapheneOS 用户登录，背后的技术机制并非简单的兼容性检查 —— 而是硬件证明（Hardware Attestation）协议如何被设计成生态控制工具。本文从 TPM / 安全启动的技术链条出发，剖析 attestation 如何从安全机制演变为垄断杠杆，并给出 GrapheneOS 等第三方操作系统的工程应对方案。
信任根的下沉：从云端服务到硬件金钥
传统移动端设备完整性验证依赖 Google Play Integrity API 或 SafetyNet，这些服务将信任根置于 Google 的服务器端。应用调用 API 时，数据流向 Google 服务器，由其判定设备是否「可信」。这种模式存在两个根本缺陷：其一，信任链条延伸到外部服务，一旦 Google 服务宕机或被屏蔽，整个验证体系随之失效；其二，Google 作为唯一仲裁者拥有最终话语权，可以单方面决定哪些设备 / OS 被接纳。
自 Android 8 起，硬件证明 API 成为强制要求。设备须在出厂时预置支持证明协议的硬件金钥存储（Hardware Keystore），并将信任根下沉至 SoC 内置的独立安全环境。与云端验证不同，硬件证明在本地生成由硬件金钥签名的证明链，应用可直接在设备端验证，无需依赖外部服务器。GrapheneOS 在其官方文档中指出，标准硬件证明 API 提供了远比 Play Integrity API 更强的证明形态，因为它将验证逻辑绑定到设备自身的硬件安全模块，而非依赖第三方云服务。
技术流程如下：应用在硬件安全模块内生成金钥对，请求设备生成包含该金钥的证明证书链。证书包含已验证的启动状态（verifiedBootState）、已验证启动金钥指纹（verifiedBootKey）、操作系统补丁级别（osPatchLevel）等元数据，全部由硬件金钥签名。若应用仅接受 verifiedBootState 为 Verified 或 SelfSigned（后者需核对 verifiedBootKey 与已知的官方白名单匹配），则攻击者若想伪造证明，必须攻破硬件安全模块本身 —— 这比绕过软件验证层要困难数个数量级。
Attestation 协议的商业化滥用：垄断工具的形成
硬件证明本应是去中心化的安全机制，但在实际部署中，它被异化为生态锁定手段。以 Play Integrity API 为例，Google 要求应用接受其作为唯一的证明来源。银行应用、政府 App 遵循 Google 划定的边界，将非 GMS 授权的操作系统（如 GrapheneOS）排除在外。GrapheneOS 维护的「封禁 GrapheneOS 的应用」名单涵盖了澳洲 myGov、巴西 gov.br、意大利 IO 政府数字钱包、新加坡 Singpass 等多个国家级应用，以及 Authy、McDonald's 等商业服务。
这些应用并非出于安全考量拒绝 GrapheneOS。GrapheneOS 文档明确指出：「唯一的原因是这些应用强制执行 Google 的商业利益，而非出于安全原因。」从工程视角看，GrapheneOS 不仅完全保留了 Android 标准安全模型，还在多个维度上强化了它：Verified Boot 链完整、硬件证明金钥存储隔离、OS 补丁更新更及时。但 Google 通过 Play Integrity API 的设计，迫使应用必须接受其定义的「可信」边界 —— 即使该边界与技术安全评估无关。
这种机制的结构性特征值得注意：Play Integrity API 基于硬件证明 API 构建，但 Google 在中间增加了一层自定义逻辑，允许其单方面决定哪些设备状态可被接受。应用开发者若想支持 GrapheneOS，需要主动改用标准硬件证明 API 并将 GrapheneOS 官方启动金钥加入白名单。问题是，大多数应用没有这样做的动力 —— 遵循 Google 的默认配置更简单，也避免了与 Google 关系紧张的风险。这正是垄断形成的技术土壤：不是通过强制，而是通过制造「最小阻力路径」来维持控制。
Pinning-Based Security：对抗泄漏的最终防线
在硬件证明领域，存在一个关键工程选择：root-based security 还是 pinning-based security。前者依赖权威 CA 签发的根证书，若根证书泄漏，攻击者可签发任意虚假证明；后者将信任锚点直接绑定到设备硬件金钥，泄漏的证书无法用于未获授权的设备。
硬件证明 API 支持后者。应用可在验证证明时，仅接受来自特定设备硬件金钥签发的证书，而非信任任何持有「合法 CA 根证书」的主体。这意味着，即使攻击者从某处获取了合法的签名材料，也无法将其用于伪造其他设备的证明，因为每台设备的证明必须由该设备自身的硬件金钥签发。
GrapheneOS 推荐的实现策略正是基于 pinning：将应用与服务的安全配对绑定到设备自身的硬件信任锚点，通过定期获取新鲜证明来维持高安全级别。这种模式的安全边界不再依赖于整个生态系统的证书管理质量，而是依赖于设备自身硬件安全模块的物理安全性。GrapheneOS Auditor 应用作为参考实现，演示了如何正确执行硬件证明验证 —— 包括验证证书链结构、确认第二条证书包含证明扩展、避免通过延长证书链伪造证明等细节。
然而，当前实践中仍存在障碍。许多应用未实现 pinning-based security，而是继续依赖 Google Play Integrity API 的「强完整性」级别 —— 这个级别虽然技术上基于硬件证明，但判断逻辑由 Google 控制。这意味着，设备生态的控制权并未真正从 Google 下沉到用户 / 开发者手中，而是从云端服务转移到了 Google 定义的证明逻辑层。
GrapheneOS 的去中心化方案与可操作参数
面对这种局面，GrapheneOS 提出了可操作的工程路径：应用开发者应使用标准 Android 硬件证明 API，绕过 Play Integrity 服务，直接与设备硬件安全模块交互。具体操作包括以下参数与阈值。
验证策略参数：对于 verifiedBootState 为 Verified 的设备，可直接信任；对于 SelfSigned 状态，需核对 verifiedBootKey 是否在 GrapheneOS 官方白名单内。当前白名单通过 https://grapheneos.org/attestation.json 发布，文件带有 OpenSSH 签名，可用 ssh-keygen -Y verify -f allowed_signers -I contact@grapheneos.org -n "attestation keys" -s attestation.json.sig < attestation.json 验证。签发金钥公开位置包括 Bluesky、X、GitHub 等多渠道，以防单点篡改。
OS 补丁级别检查：硬件证明提供 osPatchLevel 字段，可在验证时强制要求不低于某个版本。这比依赖 Play Integrity API 的模糊判断更精确，且即使攻击者在 OS 启动后获取 root 权限，也无法轻易伪造该字段。开发者可设定最低补丁级别阈值，如当前建议不低于设备最新安全更新的发布月份。
回退策略：对于旧设备（如 ro.product.first_api_level 低于 26 或硬件证明实现有缺陷的型号），可实现双轨验证：优先使用硬件证明 API，若失败则降级到 Play Integrity API（接受任一通过即视为成功）。但需注意，部分低质量设备虽然通过了 CDD/CTS 认证，硬件证明实现实际上存在问题，Play Integrity 目前错误地通过了这些设备。
设备列表维护：GrapheneOS 持续支持新 Pixel 设备，验证金钥列表会随新设备发布而更新。开发者应建立定期同步机制，从 GrapheneOS 官方端点获取最新白名单，并将更新集成到应用的安全策略配置中。白名单变更的 timestamp 字段用于防止降级攻击，应检查其不低于本地缓存的最近时间戳。
依赖最小化：硬件证明 API 仅需定期获取撤销金钥列表（用于 root-based 模式），应用服务不依赖 Google Play 服务可用性。这意味着即使 Google 服务中断或对特定应用屏蔽，验证流程仍可持续。Play Integrity API 失败时，应用无需降级或拒绝服务 —— 这是硬件证明相比云端服务的核心优势。
工程边界与当前局限
理解硬件证明的能力边界同样重要。硬件安全模块的物理安全性是整个体系的锚点；若硬件金钥被直接提取（而非通过漏洞利用），整个证明链的可靠性将受威胁。设备供应链攻击 —— 在硬件制造环节植入恶意固件 —— 理论上可破坏信任链，但这类攻击成本极高，且 GrapheneOS 通过仅支持经过审计的 Pixel 设备来降低风险。
另一个局限是应用生态的惯性。即使硬件证明技术可行，大多数应用开发者缺乏主动适配的动力。GrapheneOS 建议用户在 Play Store 为封禁应用留下反馈、发送邮件给开发者说明情况、并在第三方平台施压 —— 这是一种用户驱动的生态压力策略，但见效速度取决于用户基数和开发者响应意愿。
最后，密钥撤销机制需要持续维护。若某台设备的硬件金钥被滥用，需有渠道将其加入撤销列表。硬件证明 API 支持此功能，但需要应用端实现相应的检查逻辑，而非简单地接受首次验证结果后永久缓存。
结语：信任下沉与控制迁移的未竟之争
硬件证明机制的设计初衷是将信任根从云端服务下沉到设备硬件，从技术上看，这本应是去中心化的安全架构。然而，当 Google 通过 Play Integrity API 在硬件证明之上叠加自定义裁决层，并将大量主流应用纳入其定义的「可信」边界时，硬件证明反而成为生态垄断的技术基础设施。GrapheneOS 的应对方案 —— 使用标准 API、支持第三方 OS 白名单、建立 pinning-based security—— 提供了可操作的工程路径，但真正打破这个垄断闭环，需要应用开发者的主动选择与用户群体的持续施压。
信任根的下沉本身不是终点，关键在于谁来定义「可信」的边界。当边界定义权仍掌握在单一厂商手中时，硬件证明只是将锁链从云端迁移到了芯片里。工程层面的改进可以缩小攻击面，但要真正改变生态控制结构，还需要标准层面与商业层面的双重博弈。
参考资料
- GrapheneOS 官方证明兼容性指南：https://grapheneos.org/articles/attestation-compatibility-guide
- GrapheneOS Auditor（参考实现）：https://github.com/GrapheneOS/Auditor
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。