2026-08-09 05:21:02 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： PaloAltoNetworksUnit42团队发现针对Google同步Passkey的三类Pass-ta-key攻击,利用Windows平台Chrome同步生态的工程逻辑漏洞,而非破解底层加密算法。攻击需恶意软件前置条件,包括静默绕过解锁验证、伪造用户验证密钥实现持久劫持、窃取全局SDS主密钥批量导出私钥。守住本地设备安全是核心防护手段。 综合评分： 88 文章分类： 漏洞分析,威胁情报,恶意软件,红队,实战经验

cover_image

号称无法复制的通行密钥出现三类劫持攻击

原创

黑鸟黑鸟

黑鸟

2026年8月7日 23:46 广东

在小说阅读器读本章

去阅读

密码泄露、钓鱼盗号是互联网用户常年遭遇的安全痛点，为解决这类长期风险，Google 苹果微软等厂商集体推出 Passkey（通行密钥）这套无密码认证方案。官方宣传里 Passkey（通行密钥）自带多重安全保障，不会像文字密码一样被复制、转发、钓鱼窃取，登录时必须持有对应设备并完成指纹人脸或设备 PIN 解锁，从根源上切断绝大多数盗号路径。

Palo Alto Networks 旗下 Unit42 威胁研究团队近期发布深度报告，针对 Windows 平台 Chrome 浏览器同步至 Google 账号的 Passkey（通行密钥）生态，挖掘出一套命名为 Pass-ta-key 的新型攻击体系，包含三种递进式账户劫持手段。整套攻击没有破解 Passkey 底层非对称加密算法，而是瞄准 Google 云认证器（Cloud Authenticator）设备注册、账号恢复、设备信任校验流程里的逻辑漏洞，只要受害者设备运行恶意软件，攻击者就能绕开所有官方预设安全规则接管账号。今天我们用通俗语言拆解整套攻击原理，同时整理普通用户与企业可落地的防护办法。

先搞懂 Google 同步 Passkey（通行密钥）的三大安全预设

想要看懂漏洞攻击，先要理清 Google 设计这套体系时定下的三条核心安全底线，所有 Pass-ta-key 攻击全部是打破了这些预设逻辑。

认证必须获得用户明确授权，登录流程会弹出生物识别或设备解锁弹窗，确认用户本人在场
开启多因素校验场景下，必须完成设备解锁验证 UV（User Verification 用户验证）标识，证明操作者是账号持有人
Passkey 私钥和设备深度绑定，无法复制、导出、跨设备随意转移，不存在批量售卖的可能

为支撑这三条底线，Google 同步 Passkey 架构做了两层硬件隔离防护，私钥生成与运算全部运行在 cloud enclave（云端隔离安全环境），本地设备依靠 TPM（可信平台模块）生成硬件绑定密钥，每次向云端发起认证请求都需要硬件密钥签名佐证设备可信。

攻击前置：Stage Zero 侦查阶段，恶意软件提前收集凭证线索

所有 Pass-ta-key 系列攻击的前提，是攻击者已经通过木马病毒等恶意程序控制受害者 Windows 电脑，全程不需要管理员高权限就能完成侦查操作。

Chrome 会把同步后的 Passkey 相关凭证以 WebauthnCredentialSpecifics 记录形式，保存在本地 LevelDB 同步数据库，存储路径为 % LocalAppData%\Google\Chrome\User Data\Sync Data\LevelDB。恶意程序直接读取这份本地文件，就能批量枚举受害者绑定 Passkey（通行密钥）的全部网站、对应账号名、凭证唯一标识以及加密后的私钥。

读取完成后恶意程序会把整套凭证数据回传给攻击者控制的 C2 命令服务器，攻击者挑选目标网站发起后续劫持流程，整套侦查全程静默无弹窗，用户完全无法察觉后台数据读取行为。

本地加密私钥依靠 SDS（Security Domain Secret 安全域密钥）解密，这份 32 字节主密钥不会长期保存在本地，理论上仅 Cloud Authenticator（云认证器）隔离环境具备解密权限，而三类攻击正是分别从签名校验、设备注册、主密钥泄露三个环节突破这套加密防护。

第一类攻击 Pass-ta-key：静默绕过解锁验证，无交互完成账号接管

这是三种攻击里门槛最低的基础利用方式，仅依靠受害者本地恶意软件就能实现登录劫持，全程不会弹出指纹人脸设备 PIN 任何验证窗口，也不需要提升系统权限。

核心漏洞逻辑

Chrome 为 TPM 硬件身份密钥（identity key）设计了特殊调用机制，Windows 系统下调用 NcryptCreatePersistedKey 生成密钥时不分配固定名称，生成临时 TPM 密钥后通过 NcryptExportKey 导出为 NCRYPT_OPAQUE_KEY_BLOB 加密数据包，保存到本地 passkey_enclave_state 文件内命名为 wrapped_identity_private_key。

恶意软件可直接从本地磁盘或 Chrome 进程内存提取这份加密身份密钥数据包，调用 Windows CNG（Cryptography API Next Generation）标准加密接口复刻 Chrome 原生签名流程，不需要触发设备解锁校验就能生成云端认可的合法签名。

完整攻击执行流程

攻击者拿到本地同步 Passkey 清单，在自身设备打开目标网站发起 Passkey 登录请求，网站返回专属 authentication challenge（认证挑战值）
攻击者与 Google Cloud Authenticator 建立 Noise NK 加密 WebSocket 握手通道，获取握手哈希值
下发指令给受害者设备内恶意程序，使用提取到的 wrapped_identity_private_key 调用 TPM 对握手哈希与认证请求数据包做联合签名
攻击者携带这份硬件签名向云认证器提交 passkeys/assert 认证请求
云端识别签名来自受信任设备 TPM，直接返回合法认证断言 response
攻击者把断言转发给目标网站，无需任何用户操作直接登录账号

关键短板：UV 标识校验漏洞决定攻击能否成功

认证签名分为两种密钥生成，identity key（设备身份密钥）签名会让断言内 UV（User Verified 用户验证）标识置 0，UV key（用户验证密钥）签名 UV 标识置 1。网站后台如果严格设置 userVerification=required 并校验 UV 标识字段，这次劫持会直接失败，GitHub 就是采取该严格校验逻辑的平台，攻击时会弹出无法使用 Passkey 登录提示。

但报告测试中发现大量网站存在校验缺失问题，此前 eBay 平台虽然配置强制用户验证规则，后台却没有核对 UV 标识数值，导致攻击者依靠本攻击就能绕过生物识别完成登录，研究团队提交漏洞后 eBay 才完成修复。这类校验缺失会直接把多因素认证降级为单设备凭证验证，只要拿下本地设备密钥就能完全接管账号。

第二类攻击 Silver Pass-ta-key：伪造用户验证密钥，脱离受害者设备永久劫持账号

#

相比基础 Pass-ta-key 攻击，Silver Pass-ta-key 实现两大质变突破，一是即便网站严格校验 UV 标识也能成功劫持，二是后续登录不再需要受害者设备保持在线，攻击者可以在自有设备长期复用访问权限，威胁等级大幅提升。

核心漏洞逻辑

Chrome 本地 passkey_enclave_state 文件存储当前设备绑定的 UV 验证密钥，删除该文件或下发 device/forget 指令注销原有设备绑定后，Chrome 下次调用 Passkey 会强制触发设备重新注册 onboarding 流程。

Windows 平台 Chrome 为优化用户操作体验，会把 UV 密钥创建延迟到第二次使用 Passkey 时，首次恢复注册仅依靠 Google Password Manager 恢复 PIN 完成基础校验，设备注册状态临时标记为 uv_key_pending，这个阶段云端不会校验新增 UV 密钥的硬件 attestation（硬件可信证明）来源。

攻击者抓住该机制漏洞，强制触发受害者设备进入 uv_key_pending 待注册状态后，自行生成一套全新非对称密钥对，向 Cloud Authenticator 提交 device/add_uv_key 指令，把自己生成的公钥注册为该设备合法 UV 密钥。云端无校验直接存储替换原有可信密钥，设备云端记录会变更为 hw = 合法设备身份公钥 uv = 攻击者可控伪造公钥。

攻击带来的持久风险

密钥替换完成后，攻击者用私钥签名的所有认证请求，云端都会判定为已完成设备解锁用户验证，UV 标识永久置 1，金融政务这类高安全等级平台也无法拦截登录。哪怕后续受害者发现异常注销设备，只要重新触发一次设备注册流程，攻击者就能再次注入伪造 UV 密钥维持持久访问。

第三类攻击 Golden Pass-ta-key：窃取全局解密主密钥，批量导出全部 Passkey 私钥

这是三类攻击中破坏性最强的手段，一旦攻击完成攻击者会永久掌握账号内所有同步 Passkey 的解密权限，不存在短期修复手段，Google 当前架构不支持 SDS 主密钥轮换或撤销。

核心漏洞逻辑

所有同步 Passkey 加密私钥统一由 SDS（Security Domain Secret 安全域密钥）加密保护，设计上 SDS 仅存在于 Cloud Authenticator 云端隔离环境，本地设备只保存加密后的 wrapped_secret 数据包，本地无法独立解密任何 Passkey 私钥。

但设备重新注册流程中，Chrome 会从 Google Trusted Vault 可信密钥库拉取明文 SDS 用于跨平台同步适配，这份明文密钥会短暂保存在 Chrome 进程内存，早期版本还会明文打印在 chrome://device-log/FIDO 日志页面，研究团队上报漏洞后 Google 清理了日志输出，内存暂存漏洞至今没有彻底修复。

完整攻击流程

沿用 Silver 攻击手段删除本地 passkey_enclave_state 文件，强制 Chrome 触发设备重新注册
恶意程序持续监控该状态文件变更，检测到文件重建后立刻抓取 Chrome 完整进程内存
从内存中提取临时明文 SDS 主密钥，同步窃取本地 LevelDB 里全部加密 WebauthnCredentialSpecifics 记录
使用 SDS 批量解密每一条记录内的 Passkey 加密私钥，完整导出可离线使用的原始密钥
攻击者脱离受害者设备，使用全套导出私钥离线签名网站认证挑战，登录账号

无法逆转的持久危害

SDS 是整组账号同步凭证的唯一解密主密钥，只要密钥落入攻击者手中，该 Google 账号后续新同步生成的所有 Passkey 都会被解密窃取，注销设备、修改账号密码、删除本地凭证都无法阻断攻击链路，唯一缓解方式是新建独立 Google 账号重新绑定全部服务。这类密钥完整导出后还能在暗网批量打包售卖，形成规模化盗号产业链。

Passkey（通行密钥）依然是现阶段远优于传统文字密码、静态 MFA 验证码的认证方案，本次 Pass-ta-key 系列攻击没有推翻非对称加密底层安全能力，暴露的只是 GoogleWindows 端同步生态落地时的工程逻辑缺陷，并非 Passkey 标准本身存在致命漏洞。

整套攻击有不可缺少的前置条件也就是终端已被恶意软件入侵，只要守住本地设备安全第一道防线，绝大多数劫持路径会直接失效。

Part 1:

The Art of the Invisible Key – Passkey Global Breakthrough

https://www.cyberark.com/resources/threat-research-blog/the-art-of-the-invisible-key-passkey-global-breakthrough

Part 2:

Google Authenticator: The Hidden Mechanisms of Passwordless Authentication

https://unit42.paloaltonetworks.com/passwordless-authentication/

Part 3：

Pass the Passkey: A Novel Attack Surface in Passwordless Authentication

https://unit42.paloaltonetworks.com/passwordless-authentication-security-risks/

More ⬇️

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：黑鸟黑鸟黑鸟《号称无法复制的通行密钥出现三类劫持攻击》