当我们谈论用户验证时，CAPTCHA 挑战题代表了一种基于行为的范式 —— 通过分析鼠标轨迹、点击节奏、页面交互来推断是否为真人。然而，Google 推动的 Play Integrity API 正在将验证逻辑从「行为模式判断」转向「硬件级设备完整性证明」。这不仅是技术路线的迁移，更涉及平台信任模型的根本转变。
本文聚焦 Play Integrity API 的技术机制、桌面浏览器场景下的验证边界，以及以 GrapheneOS 为代表的开源社区提出的替代方案。
Play Integrity API 的信任链架构
Play Integrity API 的前身是 SafetyNet Attestation API，后者于 2025 年 5 月 20 日正式完成迁移使命。该 API 通过 Google Play Services 暴露接口，本质上是一套基于云端的设备完整性验证服务。
核心验证流程如下：当应用发起完整性请求时，设备上的 Google Play 服务会调用名为 DroidGuard 的专有运行环境。DroidGuard 执行多层级检查，包括 Bootloader 解锁状态、ROM 签名校验、内核字符串指纹提取，同时结合 Android Verified Boot 2.0（AVB2.0）与 dm-verity 机制生成设备认证令牌。该令牌以短生命周期的签名形式返回给应用服务器，后端通过验证签名完整性来判定设备是否通过 Google「Certified」认证。
这种架构的关键特征在于信任根的集中化：验证有效性完全依赖 Google 的服务器端签名与证书链，而非设备本身的硬件根。这意味着未安装 Google Play Services 的 Android 环境（如 GrapheneOS）天然无法参与该信任体系。
桌面浏览器的验证盲区
Play Integrity API 的设计初衷是保护 Android 原生应用 —— 它依赖 Play Services 在设备侧的深度集成。对于真正的桌面浏览器场景，该 API 并未提供直接的 attestation 路径。
Google 通过 Play Games for PC 拓展了部分覆盖范围，使游戏引擎可以调用完整性检查来保护跨平台游戏经济体系。然而，这种扩展仍然是围绕「存在 Play 安装环境的设备」构建的，而非面向纯 Web 环境。当用户通过桌面 Chrome 访问银行服务或加密货币交易所时，系统无法通过 Play Integrity 获取设备信任信号，只能退而求其次使用指纹采集、行为分析或 WebAuthn 协议。
实际工程中，桌面场景通常采用混合策略：对于涉及敏感操作的端点，在移动端触发 Play Integrity 验证后通过会话令牌传递信任状态；对于纯浏览器端，则使用 reCAPTCHA Enterprise 或基于设备的指纹方案作为替代。这种分层设计在安全性与用户体验之间做出妥协，但并未真正实现「硬件级」验证承诺。
Play Integrity API 的安全性争议
GrapheneOS 社区对 Play Integrity API 提出了尖锐的技术批评。他们指出，该 API 提供的保护强度实际上弱于 Android 平台原生的硬件 attestation 机制，后者可以生成由设备硬件密钥直接签名的证明，无需依赖任何服务端中间人。
更关键的问题是信任链的脆弱性。Play Integrity API 的验证逻辑可以被绕过，手段是利用从最不安全的 Android 设备泄露的指纹数据。开源社区已经开发出 Play Integrity Fix 等模块，能够让非标准 ROM 伪装成合规设备通过验证。这种绕过并非理论推断，而是已经在实际攻击链中被使用。
GrapheneOS 维护者在公开讨论中明确表示：「硬件级证明本身可以是安全的，但 Play Integrity API 使用它的方式高度不安全 —— 它通过泄露的密钥绕过所有安全边界。安全的使用方式是密钥固定（pinning），而非信任所有链接到根证书的实体。」
从平台竞争角度看，这种批评有其合理性：开发者若被引导使用 Play Integrity API，实际上是在将自己的安全决策外包给 Google 的黑盒服务，而非利用 Android 系统本身提供的透明验证能力。
替代路径：硬件原生 attestation 与开源验证
面对 Play Integrity API 的局限性，开源社区提供了更透明的选择。以 GrapheneOS 为例，其 Auditor 应用实现了设备端到端的硬件证明：基于 Android 原生的硬件 attestation API 生成由设备 TPM 或 Secure Element 签名的证明，服务器端可以直接验证签名有效性而无需任何第三方介入。
这种方案的优势在于：
- 信任根下沉：验证基础是设备硬件本身，而非 Google 的服务器签名链
- 隐私最小化：不强制安装 Google Play Services，减少数据暴露面
- 跨平台兼容：硬件证明可以服务于任何运行环境，包括桌面浏览器
当然，这种方案也面临生态壁垒：它要求应用端到端的支持，而当前主流应用的验证策略仍以 Play Integrity API 为主导。
工程实践建议
对于需要在混合环境中实现用户验证的开发团队，建议采用分层验证策略：
移动端高安全路径：优先使用 Android 硬件 attestation API，而非依赖 Play Integrity API。当设备支持时，通过 KeyStore 获取由硬件根签名的证明用于关键操作验证。
桌面浏览器路径：使用 WebAuthn 协议配合平台认证器（如 macOS Windows Hello）实现设备绑定验证；对于非敏感操作，使用 reCAPTCHA Enterprise 作为行为判断辅助手段。
信任传递机制：通过安全的会话令牌在移动端验证与桌面端操作之间建立信任桥梁，避免在桌面环境中重复调用移动端 API。
回退策略设计：始终假设完整性验证可能失败，因此需要设计优雅的降级路径 —— 例如在 Play Integrity 调用超时时允许用户继续操作，但记录该事件用于后续风控分析。
结论
Play Integrity API 代表了一种将设备信任根云端化的工程思路，它降低了开发者的集成门槛，但同时将安全决策权让渡给第三方平台。对于追求真正硬件级验证的场景，理解其信任链的局限性至关重要 —— 当验证基础是 Google 的签名而非设备硬件时，整个安全模型的实际强度需要重新评估。
在隐私保护与平台依赖之间做出选择，最终取决于具体业务场景对安全边界的定义。以 GrapheneOS 为代表的开源方案提供了另一种可能性：让硬件自己说话，而非通过云端代理传递信任。
资料来源：GrapheneOS 官方文档、Wikipedia Play Integrity API 词条、Android 开发者官方博客（2024-2025）
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。