设备认证用硬件密钥加密证明设备真实性:Play Integrity、App Attest 的原理与隐私代价。
核心要点
- 设备认证是密码学证明,而不是统计猜测。 硬件级信任根会对一份声明进行签名,断言设备、操作系统和应用未被篡改,服务器再用厂商的密钥校验这个签名。
- 目前有两套方案已经落地: Android 上的 Play Integrity API(取代了旧版 SafetyNet Attestation),以及 iOS 上的 App Attest / DeviceCheck。
- 浏览器版本的方案已被撤回。 谷歌面向开放网页提出的 Web Environment Integrity 从未上线——但谷歌在 Android 上更新的远程认证方案又重新点燃了同样的争议,参见电子前哨基金会(EFF)2026 年 7 月的批评文章。
- 设备认证和浏览器指纹回答的是同一个问题——"这是真的吗?"——但方式完全不同。 指纹识别是从大量弱信号中推断,而设备认证是断言一个经过密码学签名的强信号。
- 代价是平台把关权的集中。 一套能拦截被篡改设备的方案,同样可能连带排除掉 root 过的手机、替代浏览器和从未打算作恶的隐私工具。
新闻由头:EFF 对谷歌新一轮远程认证方案的警告
2026 年 7 月,EFF 发表了《谷歌的新远程认证方案和旧方案一样糟糕》一文,认为谷歌针对 Android 推出的最新设备认证方案,重蹈了此前提案的覆辙:它让认证结果成为访问应用和服务的门槛,判断依据是设备的软件栈是否与"批准过的、未经修改"的配置一致——这在挡住真正恶意流量的同时,也把自定义 ROM、root 过的设备和替代浏览器一并挤了出去。
这篇批评文章针对的是谷歌的某一个具体举措,但设备认证这套底层机制要广泛得多:它已经在移动平台上大规模部署,也曾一度被提议(后又撤回)用于网页本身。真正持久有价值的部分,是理解它到底是如何运作的——某一具体方案的新闻热度终会过去。
设备认证到底是什么
指纹识别是一种推断。网站会收集数十种个体上都可被伪造的弱信号——canvas 渲染结果、字体列表、屏幕尺寸、GPU 渲染器字符串,再用统计方法判断这些信号组合起来是否像一台真实、一致的设备。我们的浏览器指纹指南详细介绍了这种推断是如何构建的。
设备认证则完全跳过了推断这一步。它依赖设备芯片内置的硬件信任根——可信执行环境(TEE)或安全区域——用一把任何软件都无法提取的私钥对声明进行签名。这份签名声明("认证令牌")断言的是具体、可核验的事实:Bootloader 是否解锁、操作系统是否匹配已知的正版镜像、请求方应用的签名是否与发布版本一致。远端服务器用硬件厂商的公钥校验这个签名,从而决定信任或拒绝这枚令牌。
区别的关键在于:指纹可以被任何能令人信服地伪造运行环境的脚本欺骗;而认证令牌若不破解硬件私钥或攻破校验方的密码学方案,就无法伪造——这比修改几个 navigator 属性要难得多。
真正存在的方案有哪些
"认证"这个词很容易把三种不同的东西混为一谈,所以有必要分清哪些是真实上线的,哪些只是被提议、后来又夭折的。
Android——Play Integrity API。 这是谷歌当前用于 Android 应用的机制,取代了更早的 SafetyNet Attestation。应用调用该接口后会得到一份判定结果,涵盖设备完整性(这是不是一台正版、未被篡改的 Android 设备)、应用完整性(这个应用是否通过 Google Play 安装、且未被篡改)以及账号信息。银行类应用、有反作弊需求的游戏、依赖 DRM 的视频应用是最典型的使用方。
iOS——App Attest 与 DeviceCheck。 苹果对应的一对机制:App Attest 让应用能向服务器证明某次请求确实来自该应用在正版苹果硬件上运行的一个实例,依据的是安全隔区(Secure Enclave)生成的硬件密钥。DeviceCheck 是更早、更粗粒度的版本,主要用于设备级的欺诈信号,例如"这台设备是否已经领取过免费试用"。
网页——Web Environment Integrity(已撤回)。 谷歌曾提议把同样的思路带到浏览器里:一个 JavaScript 接口,让网站能请求一枚认证令牌,证明浏览器本身未被修改、运行在受信任的操作系统之上。反对声浪几乎立刻出现,浏览器厂商和隐私倡导者都表示反对——这不仅会挡住机器人,还会让网站拒绝为广告拦截器、替代浏览器或自动化无障碍工具提供服务。该提案已从积极开发中撤回。这里有必要说清楚:WEI 从未上线,而 Play Integrity 和 App Attest 却已在生产环境的应用中真实生效。EFF 在 2026 年这篇文章里认为,谷歌在 Android 一侧的新一轮认证举措,是在另一个场景下重提了同样的核心争议。
这对机器人与真人的判定意味着什么
设备认证比典型的机器人检测方案要强得多,因为它完全不依赖推断。一台被 root 的 Android 模拟器可以伪造 User-Agent 字符串,甚至修改 navigator.webdriver,但它通常无法在没有真机硬件密钥的情况下生成一枚有效的 Play Integrity 令牌——这也是为什么无头浏览器检测这类技术会去捕捉网页端指纹伪造遗漏的那些破绽,因为网页目前还没有对应的硬件认证方案。正因如此,欺诈风险高的移动应用——银行、博彩、票务——才更倾向依赖 Play Integrity 和 App Attest,而不是浏览器式的指纹打分:密码学证明比统计画像更难被大规模伪造。
隐私代价
EFF 批评的核心,也是设备认证充满争议、而非"显然正确"的原因在于:能拦下作弊游戏客户端或欺诈机器人的同一套机制,同样也会拦下那些运行自定义 ROM、自行解锁 Bootloader,或使用注重隐私的替代浏览器的合法用户。设备认证无法区分"为了作弊而修改"和"为了加装拦截广告或无障碍功能而修改"——它只能证明软件栈是否符合平台厂商批准的某个配置,而这个把关权集中在谷歌或苹果手中,而非站点运营者或用户自己。
这恰好是"如何证明这是一个真人"这一问题的另一种正在兴起的解法的镜像:匿名凭证让用户能够证明某个狭窄的属性(例如"不是机器人"),却完全不透露设备身份。设备认证和匿名凭证是对相近问题的两种相反回答——一个证明"这是这台经过批准的特定设备",另一个证明"这是某个合法用户,但不说是谁"。两者并无绝对优劣,只是在可验证性与用户自主权、平台开放性之间做出了方向相反的取舍。
现在这一切对你意味着什么
对网页用户来说,眼下什么都不会改变——Web Environment Integrity 已被撤回,目前也没有任何浏览器提供设备认证接口。而移动应用用户其实早已频繁地、往往是无感地与 Play Integrity 和 App Attest 打交道,只要打开一次银行或游戏类应用就会触发。真正值得了解的是基线情况:在完全没有硬件认证参与的前提下,一个网站眼下究竟能观察到你设备的哪些信息。
常见问题
设备认证和浏览器指纹是一回事吗?
不是。指纹识别是从 JavaScript 收集的大量弱信号、可被伪造的信号中推断设备一致性;设备认证则是硬件信任根给出的单一密码学签名声明,只要底层密码学没被攻破,就无法伪造。
网站今天能使用设备认证吗?
浏览器端目前不能——本可以让这一切实现的 Web Environment Integrity 提案已被撤回。设备认证如今只在原生移动应用内真实生效,依靠的是 Android 的 Play Integrity 和 iOS 的 App Attest / DeviceCheck。
root 或越狱设备会让认证失效吗?
一般来说会,而且这正是设计使然——这恰恰是设备认证要报告的信号,因为被修改的 Bootloader 或操作系统本身就是硬件信任根要断言的"事实"之一。这也正是 EFF 批评的核心:拦下被篡改的欺诈设备的同一道关卡,也会拦下那些出于正当理由修改了自己硬件的机主。
现在就看看网站能观察到你的哪些信息
设备认证是移动平台已经在强制执行、而网页几乎要采纳的一种硬件级证明;指纹识别与行为打分才是网站今天真正用来评估你浏览器的手段。在 BrowserInsight 上同时看看这两面:机器人检测工具会展示检测系统能打分的自动化与一致性信号,指纹检测则会展示在完全没有设备认证参与的情况下,网站能拿到的完整设备信号集合。


