当“万能钥匙”也能被复制：谷歌同步Passkey三大攻击链深度解析

通行密钥（Passkey）被认为是密码的终结者。但 Palo Alto Networks Unit 42 的最新研究提醒我们：密码学没有被攻破，被攻破的是密码学周围的那一圈实现细节。当恶意软件已经站在你的电脑上，三根支撑 Passkey 安全的“支柱”，可能一根一根被拆掉。

一、背景

过去几年，无密码认证的普及速度超出了大多数人的预期。FIDO 联盟《State of Passkeys 2026》报告估算，全球在用的 Passkey 已达约 50 亿个，消费者认知度达 90%，约四分之三的用户至少在一个账户上启用了 Passkey；在登录成功率上，Passkey 约为 93%，而传统密码只有 63% 左右。电商、加密货币交易所、企业身份平台都在跟进，个别交易所甚至强制用户使用 Passkey 登录。

Passkey 用公钥密码学取代了共享秘密：没有密码可猜、可撞库、可钓鱼，传统凭证盗窃产业的一批“老工具”正在失效。

但攻击者从未退场，只是在转移阵地。2025 年以来，对抗中间人（AiTM）钓鱼工具包以订阅制形式产业化，实时中继认证过程、窃取会话 Cookie，让传统 MFA 形同虚设——有研究统计，被此类手法攻陷的账户中 84% 早已开启 MFA。2025 年 7 月曝光的 PoisonSeed 钓鱼活动甚至尝试滥用 FIDO2 跨设备认证的 QR 码流程实施降级攻击，最终因规范强制要求蓝牙近距离校验才未能规模化。

这些案例的共性是：攻击者不再正面硬碰密码学，而是转向认证流程的实现层、回退路径和终端本身。Unit 42 于 2026 年 8 月初发布的 passkey 系列研究第三篇《Pass the Passkey: A Novel Attack Surface in Passwordless Authentication》，正是沿着这个思路，系统性拆解了谷歌同步 Passkey 生态在终端被攻陷后的真实暴露面。

该系列的三篇文章中：第一篇分析 Passkey 的全球突破与架构，第二篇剖析谷歌云认证器（Cloud Authenticator）的隐藏机制，第三篇则从“怎么建”转向“怎么打”。

二、谷歌同步 Passkey 的三根“安全支柱”

要看懂攻击，先得看懂谷歌的设计在保护什么。谷歌的同步 Passkey 实现之所以有代表性，是因为它在两个关键环节树立了较高标准：

• 私钥在云飞地（cloud enclave）隔离环境中生成和使用。所有同步的 Passkey 私钥由一把 32 字节的对称主密钥——安全域秘密（Security Domain Secret，SDS）加密保护；设备上只保存加密后的 wrapped_secret，只有云认证器能在自己的隔离环境中用设备专属的 wrapping_key 解开它。
• 硬件背书、设备绑定的密钥控制云端密码学操作的准入。设备持有 TPM 背书的密钥，向云认证器证明“用户就在这台受信任设备上”。

这套设计对应了 Passkey 认证的三条核心预期——也可以理解为三根支柱：

1. 用户在场：认证需要用户在设备上明确确认；
2. 用户验证（MFA 场景）：用户还需解锁设备，通过生物特征或 PIN 完成“你所是/你所知”的校验；
3. 私钥不可分享、不可复制。

三、攻击第零步：先摸清受害者的 Passkey 家底

一切攻击始于侦察。Chrome 会把同步的 Passkey 数据作为同步过程的一部分持久化在本地：在 Windows 上，这些数据以 proto 编码的 WebauthnCredentialSpecifics 记录形式，存放在同步数据库中：

%LocalAppData%\\Google\\Chrome\\User Data\\\\Sync Data\\LevelDB

关键在于：读取这些记录不需要任何提权。普通用户权限的恶意软件即可枚举出受害者在哪些服务上用了 Passkey，以及对应的用户名、凭证标识符和（加密的）私钥。

也就是说，恶意软件一落地，就能拿到一张“受害者在哪些高价值目标使用了 Passkey”的清单。接下来要做的，就是绕过私钥的保护机制——而私钥由主密钥 SDS 加密，设备上只有加密版本，理论上只有云认证器能解。理论上。

四、攻击一：Pass-ta-key——冒充设备身份，静默完成认证

4.1 问题出在哪：身份密钥的“可导出”实现

正常流程中，Chrome 向云认证器发起的请求需要用设备的硬件背书密钥签名。签名涉及两把设备密钥：身份密钥（identity key）和用户验证密钥（UV key）。虽然两把都是硬件绑定的，但访问方式并不相同——问题就出在身份密钥上。

在 Windows 上，Chrome 调用 NcryptCreatePersistedKey 时不指定密钥名称，使这把 TPM 背书的密钥成为临时密钥、不落盘持久化；随后调用 NcryptExportKey 将其导出为 NCRYPT_OPAQUE_KEY_BLOB——即由 TPM 驻留密钥加密后的私钥包裹体。这个包裹体以 wrapped_identity_private_key 的形式保存在 passkey_enclave_state 文件中，供同一物理 TPM 上日后使用。

这一实现选择的后果是：恶意软件可以从磁盘或 Chrome 内存中取出这个包裹体，然后完全模仿 Chrome 的行为，通过标准 Windows CNG API（NCryptOpenStorageProvider、NCryptImportKey、NCryptSignHash）请求 TPM 完成签名——无需提权、无需解锁设备、无需用户交互。公开报道指出，Chromium 源码中的实现逻辑与该研究发现一致，且源码中留有相关改进的 TODO（Chromium issue 398125799）。

4.2 攻击流程

1. 完成第零步侦察后，攻击者选定目标账户，发起 Passkey 登录；
2. 依赖方（Relying Party）返回一个新鲜的认证挑战；
3. 攻击者与谷歌云认证器发起 WebSocket 握手；
4. 以握手哈希为基础，利用提取出的身份密钥，让受害者设备的 TPM 对“握手哈希 + 断言请求”签名；
5. 携带身份密钥签名向云认证器发送断言请求；
6. 在云认证器视角，这是一台受信任设备发起的合法请求，于是返回有效断言；
7. 攻击者将断言转发给依赖方，完成认证，接管账户。

4.3 一个比特的生死线：UV 标志位

这种攻击并非对所有账户都有效，分水岭是认证器数据中的一个比特——User Verified（UV）标志位。

• 断言用 UV 密钥签名 → UV 标志位置 1；
• 断言用身份密钥签名（即本攻击）→ UV 标志位为 0。

按 WebAuthn 规范，依赖方若将 userVerification 设为 required，必须在 UV 位缺失时拒绝认证。但现实中大量依赖方为了兼容性和体验设为 preferred，对本攻击敞开大门。更值得注意的是执行不一致：Unit 42 实测中，GitHub 严格校验 UV 位、攻击失败报错；而 eBay 虽然将 userVerification 设为 required，却未正确校验 UV 标志位，攻击在“要求 MFA”的情况下依然成功——认证实际上被降格为单因素。研究者已将该问题通报相关依赖方，eBay 在披露后修复了校验缺陷。

五、攻击二：Silver Pass-ta-key——“偷梁换柱”的用户验证密钥

对于金融、政务等强制用户验证的高价值账户，UV 位这道坎必须迈过去。正面绕过 UV 密钥几乎无望——它的访问由操作系统以设备解锁同级的机制把守。攻击者换了一个思路：

不绕过 UV 密钥，而是废掉它，再注册一把由攻击者控制的新 UV 密钥。

5.1 第一步：让现有 UV 密钥失效

攻击者可以复用攻击一的能力——用身份密钥签名、以受害者名义向云认证器发出 device/forget 命令；或者更简单粗暴：直接删除本地的 passkey_enclave_state 文件，因为没有任何内置保护阻止其被删除。无论哪条路，下次用户使用 Passkey 时，Chrome 都被迫重新执行设备入网（onboarding）。

5.2 第二步：利用 uv_key_pending 的窗口期

这里有一个关键的产品设计细节。在 Windows 上，设备入网要到同一设备上第二次使用 Passkey 时才真正完成：第一次使用时，Chrome 在后台开始入网，同时提示用户输入 Google Password Manager 恢复 PIN；如果此时创建 UV 密钥，还会紧接着弹出 Windows Hello 验证。两个 PIN 类提示背靠背出现容易让用户困惑出错，因此 Chrome 推迟了 UV 密钥的创建——设备先以 uv_key_pending（UV 密钥待创建）状态注册，恢复 PIN 临时充当用户验证，真正的 UV 密钥留待下次使用 Passkey 时再创建注册。

攻击者逼受害者进入这个重新注册状态后，在自己的环境中生成一对非对称密钥，向云认证器发送 device/add_uv_key 命令，提交攻击者控制的公钥作为 UV 密钥。

致命的一环在于：云认证器不校验新注册 UV 密钥的认证来源（attestation），不确认它是否真的来自安全硬件。于是云端设备记录变成：

devices[device_id] = {
hw: identity_public_key, // 合法设备身份密钥
uv: (Attacker-controlled) uv_public_key // 攻击者塞进来的 UV 密钥
}

从此，攻击者用伪造 UV 密钥签名的任何消息，都被云认证器当作“用户已成功解锁设备”来处理——可以为受害者名下的任意 Passkey 拿到 UV 位置 1 的断言。

5.3 为什么叫“Silver”：可复用的持久访问

与攻击一相比，Silver 攻击实现了两个质变：

• 无需受害者设备在线。认证不再需要受害者设备上的恶意软件实时配合，攻击者在自己的环境里即可完成全部账户的自动化认证；
• 突破用户验证强制校验。即使依赖方正确设置并校验 UV 位，攻击依然成立。

好消息是，该攻击可通过注销或重新注册设备来缓解——但下面这种攻击就没这么容易收场了。

六、攻击三：Golden Pass-ta-key——直取主密钥，拿到“云端超能力”

这是三种攻击中影响最深的一种：攻击者直接窃取云认证器的核心能力——解密所有同步 Passkey 的主密钥 SDS。

6.1 主密钥本不该出现在客户端

按设计，32 字节的 SDS 永远不应暴露给客户端设备，即使设备丢失或账户恢复时也不例外。谷歌在回应研究者的漏洞报告时也明确表示：“（云）飞地认证器的主要功能就是让窃取 Passkey 私钥数据变得困难——如果私钥在本地可用，它显然会成为恶意软件的目标。”

然而研究者意外发现：在设备向云认证器注册的过程中，SDS 明文出现在 Chrome 的日志里——只要打开 chrome://device-log/FIDO 就能看到。

原因在于当前的入网/恢复实现：每台加入或重新加入账户安全域的设备，都会从恢复密钥库（谷歌 Trusted Vault 服务）取回 SDS。云认证器其实提供了一种机制，可以协助 Chrome 完成“密钥不在客户端解密”的恢复流程，但这个机制没有被使用——Chrome 以可访问的形式恢复了 SDS。一种可能的解释是需要跨平台统一入网与恢复流程：iOS 和 Android 上的 Google Password Manager 不依赖云认证器，必须拿到主密钥才能解密同步 Passkey，Chrome 似乎沿用了同一套恢复模型。

谷歌在收到报告后已将 SDS 从 Chrome 日志输出中移除。但问题没有根治：SDS 仍会发送给客户端，并暂时以明文存在于 Chrome 进程内存中——知道特征模式的攻击者，可以逼受害者重新注册后直接dump内存提取。

6.2 攻击流程

1. 用 Silver 攻击的同样手段，迫使 Chrome 触发全新入网；
2. 监控系统，等待 passkey_enclave_state 文件被重建或修改；
3. 文件一旦重建/修改，立即转储 Chrome 进程内存，提取短暂明文驻留的 SDS；
4. 读取 Chrome 同步数据库中的 WebauthnCredentialSpecifics 记录（第零步侦察）；
5. 用 SDS 解密每条记录的加密字段，还原出对应的 Passkey 私钥；
6. 用还原的私钥签名依赖方挑战，以受害者身份完成认证。

6.3 为什么叫“Golden”：无法撤销的持久化

Golden 攻击的破坏半径远超前两者：

• 拿到 SDS 等于拿到全部现有 Passkey 以及未来新建 Passkey 的解密能力——这些私钥甚至可以被拿到凭证黑市上分享或出售；
• 强持久性、难以补救。Silver 攻击可通过注销/重新注册设备来缓解，而 Golden 攻击即使在失陷被发现后也补救手段有限——在谷歌当前实现中，没有轮换或吊销 SDS 的机制，所有现在和未来的同步 Passkey 仍由同一把主密钥保护。

七、三种攻击横向对比

八、防御清单

Unit 42 给出的缓解建议可按角色拆解如下：

给依赖方（网站/服务运营者）：

• 将 userVerification 设为 required，并在所有认证响应中严格校验 UV 标志位——缺失即拒绝。不执行这项检查，等于把 MFA 降格为单因素；
• 关注同步 Passkey 场景下 signCount 恒为常数带来的可见性损失，结合其他信号做异常检测。

给平台与凭据管理器厂商：

• 校验新注册设备密钥（含 UV 密钥与身份密钥）的来源与 attestation，不接受任意密钥；
• 加固恢复与设备重新注册流程：重新建立设备信任或恢复同步凭据前要求额外验证；
• 敏感密钥材料不落地客户端：采用由云端代替客户端执行密码学操作的设计，不将底层密钥材料传输到客户端环境（包括内存与日志）；
• 探索适应多设备同步场景的协调式签名计数器机制，提升跨环境异常使用检测能力。

给企业与安全团队：

• 用平台访问控制限制对 Passkey 本地存储的访问（Chrome 同步数据库、passkey_enclave_state 等），仅浏览器进程可及；
• 监控代理应检测并限制不必要的入网/恢复流程再触发，尤其是在本地 Passkey 状态文件被删除或修改之后；
• 加强端点反恶意软件与进程内存访问防护（如限制其他进程读取浏览器内存的能力）。

给个人用户的信号识别：

• 凭据管理器的恢复 PIN 提示通常只出现在入网或账户恢复场景，日常 Passkey 使用中突然或反复出现恢复 PIN 提示，是异常信号——可能意味着入网/恢复流程被钓鱼或本地篡改重新触发，应提高警惕。

九、结语

Passkey 是认证安全实实在在的一大步：消灭共享秘密，整类历史攻击随之式微，凭证盗窃的经济学被改写。但 Unit 42 这项研究的价值在于，它把视线从“密码学安不安全”拉回到“实现忠不忠实于设计”：设备信任、校验一致性、入网与恢复——这些看似外围的环节，恰恰是攻击者下一阶段的主战场。随着 Passkey 覆盖数十亿账户，攻击者对这个空间的兴趣只会增长。理解这些新兴攻击路径，是让无密码认证在真实世界兑现其安全承诺的前提。

技术附录

附录 A：MITRE ATT&CK 技术映射

附录 B：失陷指标（IoC）与检测线索

说明：Unit 42 原始报告未公布任何文件哈希、C2 地址等传统 IoC，也未分配 CVE。以下为依据报告披露的攻击构件整理的主机痕迹与行为检测线索，供防守方狩猎参考。

B.1 关键文件与路径痕迹

B.2 行为检测线索

• 非 Chrome 进程读取 Chrome 同步数据库 LevelDB 或 passkey_enclave_state 文件；
• 非 Chrome 进程调用 CNG API 序列（NCryptOpenStorageProvider → NCryptImportKey → NCryptSignHash）加载 opaque key blob 并请求签名——正常场景此行为应由 Chrome 发起；
• 任意进程（非调试器/EDR 白名单）打开并读取/转储 Chrome 进程内存；
• passkey_enclave_state 被删除或修改后，短时间内出现 Google Password Manager 恢复 PIN 提示（重新入网触发）；
• 云侧信号（面向身份提供商/依赖方遥测）：异常的 device/forget、device/add_uv_key 事件；来自陌生环境但携带有效 UV 位的断言；同一凭证在不可能的多地/多设备间使用；
• 注意可见性局限：同步 Passkey 的断言通常携带恒定 signCount，依赖方难以仅凭计数器发现凭证克隆，需结合设备、网络与行为上下文综合判断。

参考链接

1. https://unit42.paloaltonetworks.com/passwordless-authentication-security-risks/
2. https://thehackernews.com/2026/08/google-password-manager-attacks-could.html
3. https://www.bleepingcomputer.com/news/security/new-pass-ta-key-attacks-let-malware-hijack-google-synced-passkeys/
4. https://cybersecuritynews.com/google-synced-passkey-malware-attack/
5. https://mojoauth.com/blog/passwordless-passkeys-what-the-adoption-data-shows
6. https://www.authsignal.com/blog/articles/passwordless-authentication-in-2025-the-year-passkeys-went-mainstream
7. https://workos.com/blog/adversary-in-the-middle-attacks
8. https://ssojet.com/news/trends-and-insights-on-passwordless-authentication-in-2025)
9. https://www.epicit.com.au/phishing-resistant-mfa-fallback-downgrade/
10. https://mallory.ai/stories/019fc751-a204-72dc-bc65-461f2b4856c9

声明：本文来自奇安信威胁情报中心，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。