传递通行密钥无密码认证中的新型攻击面本文分析了针对无密码认证的新型攻击类型重点关注 Google 的同步通行密钥生态系统以及桌面客户端使用的云端身份验证器。这些攻击展示了受感染端点上的恶意软件如何滥用注册、恢复和设备信任流程从而接管受通行密钥保护的账户。还展示了攻击者如何在无需用户交互的情况下进行身份验证绕过用户验证要求并提取所有同步的通行密钥私钥。经过数十年的安全漏洞和数十亿的损失以密码和共享密钥为特征的攻击向量终于开始逐渐消失。通行密钥利用公钥加密技术取代了密码和传统的多因素认证MFA减少了多年来一直主导威胁格局的各类攻击。由于没有可窃取、重复使用或钓鱼的共享密钥攻击者许多最可靠的工具正逐渐过时这对凭证盗窃市场造成了重大冲击。然而攻击者不会轻易罢手他们会不断进化因此防御者必须为新一代的攻击做好准备。随着通行密钥的广泛采用并应用于数十亿个账户防御者必须警惕新的攻击面研究中揭示了其中一些。本文是从安全角度审视通行密钥采用情况系列文章的第三部分。若还没阅读过前几部分建议从以下文章开始第一部分无形密钥的艺术——通行密钥的全球突破第二部分Google 身份验证器无密码认证的隐藏机制。Palo Alto Networks 的客户可通过以下产品和服务更好地防范这种新的攻击向量Cortex 云身份安全、Idira 威胁检测与响应、Idira 端点权限管理器、Idira 特权访问管理。如果认为自己可能已遭受攻击或有紧急情况请联系 Unit 42 事件响应团队。背景介绍Google 的同步通行密钥实现具有重要的参考价值其规模庞大并在两个关键方面为私钥保护设定了更高标准私钥在云隔离环境中生成和使用由硬件支持、与客户端设备绑定的密钥控制对基于云的加密操作的访问确保用户在可信设备上进行操作。本文基于此前系列文章第一部分和第二部分的架构分析展开现在将关注点从通行密钥的构建和部署转移到攻击者如何滥用它们。介绍了三种新型攻击这些攻击可实现对受通行密钥保护账户的接管。每种攻击都挑战了通行密钥认证安全的不同核心假设。当客户端使用通行密钥进行身份验证时通常期望满足以下条件用户在设备上提供明确同意以验证用户存在对于 MFA用户还必须解锁设备以验证基于生物特征或知识的认证因素通行密钥私钥不能共享或复制。Google 文档体现了这些核心假设将通行密钥登录过程描述为比密码更安全的替代方案。将挑战这些预期的一类攻击戏称为“Pass - ta - key”这个有趣且层层递进的名字融合了“passkey”和“pass the key”这两个词同时也略带调侃地暗示了这种密钥实现可能会变得多么复杂。这些攻击在实践中各自暴露出不同的弱点Pass - ta - key 攻击攻击者利用运行在受害者设备上的恶意软件接管受 Google 同步通行密钥保护的账户无需提升权限、解锁设备或用户交互Silver Pass - ta - key 攻击攻击者欺骗 Google 云端身份验证器使其相信受害者已通过生物特征解锁设备从而在身份验证期间无需使用受害者设备即可完全接管账户Golden Pass - ta - key 攻击攻击者可以提取所有同步的通行密钥并将其以可共享或在凭证黑市上出售的形式获取。这些攻击表明即使提供商在云端身份验证器中添加了硬件保护措施来保障凭证安全恶意软件仍可利用同步通行密钥的漏洞。免责声明本研究进行了负责任且合乎道德的安全分析已负责任地披露了所有发现的漏洞。云端身份验证器模型被多个浏览器和平台的各种通行密钥提供商所采用然而本研究主要关注 Windows 系统上 Chrome 浏览器中的 Google 密码管理器特别是配备可信平台模块TPM的设备。所有介绍的攻击都基于受害者设备在初始阶段已存在恶意软件的情况。零阶段侦察在尝试任何攻击之前攻击者需要了解受害者账户中通行密钥的使用情况。在受感染的端点上获取这些信息并不困难。Chrome 在同步过程中会本地存储同步通行密钥数据。在 Windows 系统上Chrome 将这些数据以 proto 编码的 WebauthnCredentialSpecifics 记录形式存储在其同步数据库中这些记录代表同步的 WebAuthn 凭证。访问这些记录无需提升权限。通过这些记录攻击者可以确定受害者在哪些服务中使用了通行密钥以及相关的用户名、凭证标识符和加密的私钥。在确定受害者使用通行密钥的服务后攻击者可以尝试以受害者的身份进行身份验证。攻击者面临的主要挑战是绕过用于签署身份验证挑战的私钥保护。该私钥由主密钥保护虽然加密版本的主密钥存储在每个客户端设备上但只有云端身份验证器能够解密它。尽管有这些安全措施该架构仍存在被利用的漏洞。以下部分将详细介绍攻击者可能利用系统机制、以受害者身份进行身份验证并攻破通行密钥保护账户的方法。设备身份模拟Pass - Ta - Key 攻击介绍的第一种攻击是最直接的方法攻击者通过模拟 Google 密码管理器和 Chrome 在正常身份验证过程中的行为接管受通行密钥保护的账户。在正常流程中Chrome 会使用设备的硬件支持密钥对发送给云端身份验证器的请求进行签名。与需要用户交互和设备解锁的正常用户流程不同这种攻击展示了恶意软件如何在无需用户同意、生物特征识别、设备解锁或提升权限的情况下静默获取所需的签名。为了理解这一点需要关注 Chrome 的设备身份密钥该密钥向云端身份验证器证明客户端设备的所有权。生成所需的断言涉及使用设备的一个硬件支持密钥对发送给云端身份验证器的数据进行签名这个密钥可以是身份密钥或用户验证密钥UV 密钥。虽然这两个密钥都与硬件绑定但访问方式不同。对于身份密钥Chrome 会创造条件使其能够在以普通用户身份运行且不提升权限、不触发设备解锁保护机制的情况下请求签名。在 Windows 系统上Chrome 调用相关函数时不指定密钥名称使 TPM 支持的密钥成为临时密钥防止其持久化到磁盘。Chrome 不将私钥存储在 TPM 中而是调用相关函数将密钥导出为 NCRYPT_OPAQUE_KEY_BLOB指示 TPM 使用 TPM 驻留密钥对私钥进行加密。生成的 blob 存储在 passkey_enclave_state 文件中作为 wrapped_identity_private_key以便在同一物理 TPM 上后续使用。恶意软件可以从磁盘或 Chrome 内存中提取这个 wrapped_identity_private_key然后使用标准的 Windows 密码学 API下一代CNGAPI 在不提升权限的情况下调用加密操作模仿 Chrome 的行为。下面详细介绍完整的 Pass - ta - key 攻击流程该流程允许在受害者设备上运行无特权恶意软件的远程攻击者以受害者的身份进行身份验证。攻击流程包括以下阶段攻击者收集受害者的同步通行密钥记录后选择目标账户并发起通行密钥登录依赖方返回新的身份验证挑战攻击者与 Google 云端身份验证器发起 WebSocket 握手攻击者使用握手的哈希值与受害者的 TPM 进行交互并使用提取的身份密钥对握手哈希和断言请求进行签名攻击者向云端身份验证器发送包含身份密钥签名的断言请求从云端身份验证器的角度看该请求看起来像是来自可信设备的有效请求因此它会生成有效的断言响应该断言随后被转发给依赖方完成身份验证攻击者获得对受害者账户的完全控制权。当依赖方不严格要求用户验证时Pass - ta - key 攻击非常有效。许多依赖方将 WebAuthn 的 userVerification 参数配置为“首选”而非“必需”以支持不同的设备和用户体验这使得它们容易受到这种攻击。当依赖方明确要求用户验证时人们通常期望云端身份验证器拒绝未使用通过 PIN 或生物特征验证的密钥签名的请求。然而实际情况并非如此。无论请求是使用身份密钥还是 UV 密钥签名云端身份验证器都会返回有效的断言区别仅在于身份验证器数据中的一个比特即用户验证UV标志。当使用 UV 密钥签名断言时该标志设置为 1当使用身份密钥签名时该标志保持为 0。虽然 Pass - ta - key 攻击生成的断言在密码学上与依赖方的公钥匹配但测试表明当需要用户验证时攻击通常会失败因为 UV 标志未设置。尽管在需要用户验证时身份验证通常会被拒绝但并非所有依赖方都会始终一致地执行此行为。在测试中发现一些依赖方由于未正确验证 UV 标志而接受了身份验证这使得攻击即使在没有用户验证的情况下也能成功。这种缺乏验证的情况实际上将身份验证过程简化为单一因素。攻击者只需攻破设备身份密钥即使在需要 MFA 的情况下也能够成功进行身份验证并接管账户。已将此问题报告给受影响的依赖方。待攻击状态Silver Pass - Ta - Key 攻击当账户受到更强的身份验证要求保护时攻击者还必须绕过用户验证。云端身份验证器要求使用 UV 密钥签名的消息来设置 UV 标志。客户端交互控制对该密钥的访问因为操作系统通过与设备解锁相同的机制验证用户。如果不提升到系统权限或物理访问受害者设备攻击者似乎无法获得这种访问权限。攻击者可以通过以下机制绕过这一挑战攻击者不直接绕过对 UV 密钥的访问而是使云端身份验证器中已注册的现有密钥失效并注册一个由其控制的新生成密钥一旦攻击者控制的密钥注册成功任何使用该密钥签名的消息都会被云端身份验证器接受就好像用户已经成功解锁设备一样。这种方法具有重要意义。它允许攻击者在无需人工交互的情况下对受害者的所有账户进行全自动身份验证即使在强制执行用户验证的情况下也是如此。此外攻击者在身份验证期间不再需要实时访问受害者的设备。与之前的攻击不同之前的攻击每次身份验证都需要受害者设备上的活动恶意软件而 Silver 攻击提供了可重复使用的访问权限。这使得攻击者可以在自己的环境中访问受害者受通行密钥保护的账户而无需受害者的设备在线或处于活动状态。最终攻击者无需提升权限即可接管与受害者关联的所有通行密钥保护的账户。为了实施此攻击首要目标是使与目标设备关联的现有 UV 密钥失效。攻击者可以利用无特权的恶意软件使用设备身份密钥对其控制的请求进行签名并将其发送给云端身份验证器。攻击者可以代表受害者发出 device/forget 命令更简单的方法是直接删除受害者的 passkey_enclave_state 文件因为没有内置保护措施阻止其删除。无论采用哪种方法下次用户尝试使用通行密钥时Chrome 都将被迫重新注册设备。在 Windows 系统上设备注册只有在同一设备上第二次使用通行密钥后才会完成。在第一次使用时Chrome 会在后台与云端身份验证器开始注册流程同时提示用户输入 Google 密码管理器GPM恢复 PIN。如果 Chrome 在此时创建 UV 密钥还会触发 Windows Hello 提示要求用户再次使用生物特征或 PIN 进行身份验证。由于这两个步骤都可能涉及 PIN在同一流程中连续显示可能会让用户感到困惑并导致错误。为避免这种情况Chrome 会推迟 UV 密钥的创建。相反设备最初会以 uv_key_pending 状态注册。在第一次交互期间GPM 恢复 PIN 满足用户验证要求实际的 UV 密钥只会在下次使用通行密钥时创建和注册此时不再需要额外的提示。在迫使受害者进入重新注册状态后攻击者可以利用 uv_key_pending 条件。在自己的环境中攻击者生成一个非对称密钥对然后向云端身份验证器发送 device/add_uv_key 命令并将其控制的公钥作为 UV 密钥提供。云端身份验证器不会验证新注册 UV 密钥的证明以验证它们是否来自安全硬件。因此攻击者控制的密钥会与合法的设备身份密钥一起存储。从这一点开始攻击者可以使用伪造的 UV 密钥为与受害者关联的任何通行密钥请求签名并获取设置了 UV 位的断言。这使得攻击者即使在强制执行和验证用户验证的情况下也能访问高价值账户。窃取主密钥Golden Pass - Ta - Key 攻击在这种攻击中攻击者实际上获得了云端身份验证器的超级能力即解密同步通行密钥的能力。这尤其具有影响力因为它破坏了预期的保护机制。通行密钥的私钥由一个名为安全域密钥SDS的对称主密钥保护。这个主密钥无法直接访问它以加密的 wrapped_secret 形式存储在设备上。只有云端身份验证器能够在其隔离环境中使用其设备特定密钥wrapping_key解密这个 wrapped_secret。这种设计旨在即使客户端设备被攻破也能保护同步通行密钥。正如 Google 在回应一份漏洞报告时指出的那样云隔离身份验证器的主要功能是使窃取通行密钥私有数据变得困难如果这些数据在本地可用将成为恶意软件的明显目标。这种模型的安全性最终取决于对 32 字节 SDS 的保护。如果攻击者能够获取 SDS他们实际上就获得了解密该账户所有同步通行密钥的能力。这使得他们能够以完全验证的用户身份进行身份验证并接管受害者依赖通行密钥的所有服务。这个密钥即使在设备丢失或账户恢复期间也不应暴露给客户端设备。然而意外地发现在与云端身份验证器注册时只需打开 chrome://device - log/FIDOSDS 就会出现在 Chrome 的日志中。在当前的 Chrome 实现中每个加入或重新加入账户安全域的设备都会从恢复密钥存储中检索 SDS。云端身份验证器包含一种机制允许 Chrome 促进恢复流程使密钥无法在客户端设备上解密但这种机制并未被使用。相反Chrome 以可访问的形式恢复了 SDS。一种可能的解释是需要在不同平台上标准化设备加入和恢复流程。与桌面环境不同iOS 和 Android 上的 Google 密码管理器不依赖云端身份验证器必须获取主密钥才能解密同步通行密钥。因此Chrome 似乎遵循了相同的恢复模型尽管云端身份验证器可以实现更隔离的方法。尽管 Google 在报告后从 Chrome 的日志输出中移除了这个密钥但 SDS 仍然会发送到客户端并在 Chrome 的进程内存中保持可访问状态。如果攻击者迫使受害者重新与云端身份验证器注册并知道要查找的模式他们就可以直接从内存中提取 SDS。Golden Pass - ta - key 攻击通过以下步骤实现完全账户接管攻击者使用与 Silver Pass - ta - key 攻击相同的机制迫使 Chrome 触发全新的注册流程攻击者监控系统以检测 passkey_enclave_state 文件的重新创建或修改一旦该文件被重新创建或修改攻击者转储 Chrome 的进程内存并提取暂时以明文形式存在的 SDS攻击者从 Chrome 的同步数据库中读取 WebauthnCredentialSpecifics 记录攻击者使用提取的 SDS 解密每个记录中的加密字段并恢复相应的通行密钥私钥攻击者使用恢复的私钥签署依赖方的挑战并成功以受害者的身份进行身份验证。Golden Pass - ta - key 攻击的影响更为广泛。除了攻击者可以在自己的环境中重复使用访问权限之外SDS 还允许攻击者解密所有现有通行密钥以及为该账户创建的任何未来通行密钥。虽然 Silver 攻击可以通过注销或重新注册设备来缓解但 Golden 攻击具有很强的持久性。即使检测到攻击补救措施也很有限。在 Google 的当前实现中无法轮换或撤销 SDS这意味着所有当前和未来的同步通行密钥仍然由同一个主密钥保护。缓解措施强制严格的用户验证UV验证依赖方应要求 userVerification required并在所有身份验证响应中验证 UV 标志。未能执行此检查可能会将身份验证简化为单一因素。验证设备密钥注册和证明凭证管理器应验证新注册设备密钥包括 UV 密钥和身份密钥的来源和证明。在未进行验证的情况下接受任意密钥会允许未经授权的密钥注册并绕过用户验证要求。强化恢复和设备重新注册流程凭证管理器的恢复 PIN 提示通常与注册或账户恢复相关而非常规的通行密钥身份验证。在正常使用通行密钥期间出现意外或重复的提示可能表明重新触发了注册或恢复流程这可能是由于钓鱼攻击或对通行密钥状态的本地篡改所致。这些流程对安全至关重要因为恢复操作可以重新建立设备信任并恢复对同步凭证的访问。监控代理应检测并限制不必要的注册和恢复流程重新触发特别是在本地通行密钥状态文件被删除或修改之后。在重新建立设备信任或恢复同步凭证之前应进行额外的验证。防止客户端暴露敏感密钥材料敏感材料如主密钥不应暴露给客户端包括通过内存或日志。相反凭证管理器应采用在代表客户端执行加密操作的同时不将底层密钥材料传输到客户端环境的设计。限制对本地通行密钥数据的访问对与通行密钥相关的存储如 Chrome 的同步数据库和本地状态文件如 passkey_enclave_state的访问应仅限于浏览器进程并通过平台访问控制进行保护。这可以减少从受攻击的端点枚举凭证、操纵注册状态或访问设备绑定密钥材料的可能性。改进对异常通行密钥使用的检测WebAuthn 定义了一个签名计数器机制旨在帮助依赖方检测克隆或意外重复使用的凭证。在同步通行密钥系统中身份验证断言通常包含一个恒定的 signCount 值。因此依赖方和凭证提供商对同步凭证的未授权使用包括从意外环境中提取或重复使用通行密钥的情况的可见性有限。集中协调身份验证操作的凭证管理器应考虑实施协调签名计数器机制以解决同步和多设备一致性挑战。这种机制可以提高对意外凭证使用或跨环境重复使用通行密钥的可见性和检测能力。结论通行密钥是身份验证安全领域的重要进步。通过消除共享密钥它们减少了历史上导致广泛账户泄露的各类攻击。那么未来在通行密钥的广泛应用中还会出现哪些新的攻击形式和应对策略呢 通行密钥虽好，但新型攻击面不可不防！
传递通行密钥无密码认证中的新型攻击面本文分析了针对无密码认证的新型攻击类型重点关注 Google 的同步通行密钥生态系统以及桌面客户端使用的云端身份验证器。这些攻击展示了受感染端点上的恶意软件如何滥用注册、恢复和设备信任流程从而接管受通行密钥保护的账户。还展示了攻击者如何在无需用户交互的情况下进行身份验证绕过用户验证要求并提取所有同步的通行密钥私钥。经过数十年的安全漏洞和数十亿的损失以密码和共享密钥为特征的攻击向量终于开始逐渐消失。通行密钥利用公钥加密技术取代了密码和传统的多因素认证MFA减少了多年来一直主导威胁格局的各类攻击。由于没有可窃取、重复使用或钓鱼的共享密钥攻击者许多最可靠的工具正逐渐过时这对凭证盗窃市场造成了重大冲击。然而攻击者不会轻易罢手他们会不断进化因此防御者必须为新一代的攻击做好准备。随着通行密钥的广泛采用并应用于数十亿个账户防御者必须警惕新的攻击面研究中揭示了其中一些。本文是从安全角度审视通行密钥采用情况系列文章的第三部分。若还没阅读过前几部分建议从以下文章开始第一部分无形密钥的艺术——通行密钥的全球突破第二部分Google 身份验证器无密码认证的隐藏机制。Palo Alto Networks 的客户可通过以下产品和服务更好地防范这种新的攻击向量Cortex 云身份安全、Idira 威胁检测与响应、Idira 端点权限管理器、Idira 特权访问管理。如果认为自己可能已遭受攻击或有紧急情况请联系 Unit 42 事件响应团队。背景介绍Google 的同步通行密钥实现具有重要的参考价值其规模庞大并在两个关键方面为私钥保护设定了更高标准私钥在云隔离环境中生成和使用由硬件支持、与客户端设备绑定的密钥控制对基于云的加密操作的访问确保用户在可信设备上进行操作。本文基于此前系列文章第一部分和第二部分的架构分析展开现在将关注点从通行密钥的构建和部署转移到攻击者如何滥用它们。介绍了三种新型攻击这些攻击可实现对受通行密钥保护账户的接管。每种攻击都挑战了通行密钥认证安全的不同核心假设。当客户端使用通行密钥进行身份验证时通常期望满足以下条件用户在设备上提供明确同意以验证用户存在对于 MFA用户还必须解锁设备以验证基于生物特征或知识的认证因素通行密钥私钥不能共享或复制。Google 文档体现了这些核心假设将通行密钥登录过程描述为比密码更安全的替代方案。将挑战这些预期的一类攻击戏称为“Pass - ta - key”这个有趣且层层递进的名字融合了“passkey”和“pass the key”这两个词同时也略带调侃地暗示了这种密钥实现可能会变得多么复杂。这些攻击在实践中各自暴露出不同的弱点Pass - ta - key 攻击攻击者利用运行在受害者设备上的恶意软件接管受 Google 同步通行密钥保护的账户无需提升权限、解锁设备或用户交互Silver Pass - ta - key 攻击攻击者欺骗 Google 云端身份验证器使其相信受害者已通过生物特征解锁设备从而在身份验证期间无需使用受害者设备即可完全接管账户Golden Pass - ta - key 攻击攻击者可以提取所有同步的通行密钥并将其以可共享或在凭证黑市上出售的形式获取。这些攻击表明即使提供商在云端身份验证器中添加了硬件保护措施来保障凭证安全恶意软件仍可利用同步通行密钥的漏洞。免责声明本研究进行了负责任且合乎道德的安全分析已负责任地披露了所有发现的漏洞。云端身份验证器模型被多个浏览器和平台的各种通行密钥提供商所采用然而本研究主要关注 Windows 系统上 Chrome 浏览器中的 Google 密码管理器特别是配备可信平台模块TPM的设备。所有介绍的攻击都基于受害者设备在初始阶段已存在恶意软件的情况。零阶段侦察在尝试任何攻击之前攻击者需要了解受害者账户中通行密钥的使用情况。在受感染的端点上获取这些信息并不困难。Chrome 在同步过程中会本地存储同步通行密钥数据。在 Windows 系统上Chrome 将这些数据以 proto 编码的 WebauthnCredentialSpecifics 记录形式存储在其同步数据库中这些记录代表同步的 WebAuthn 凭证。访问这些记录无需提升权限。通过这些记录攻击者可以确定受害者在哪些服务中使用了通行密钥以及相关的用户名、凭证标识符和加密的私钥。在确定受害者使用通行密钥的服务后攻击者可以尝试以受害者的身份进行身份验证。攻击者面临的主要挑战是绕过用于签署身份验证挑战的私钥保护。该私钥由主密钥保护虽然加密版本的主密钥存储在每个客户端设备上但只有云端身份验证器能够解密它。尽管有这些安全措施该架构仍存在被利用的漏洞。以下部分将详细介绍攻击者可能利用系统机制、以受害者身份进行身份验证并攻破通行密钥保护账户的方法。设备身份模拟Pass - Ta - Key 攻击介绍的第一种攻击是最直接的方法攻击者通过模拟 Google 密码管理器和 Chrome 在正常身份验证过程中的行为接管受通行密钥保护的账户。在正常流程中Chrome 会使用设备的硬件支持密钥对发送给云端身份验证器的请求进行签名。与需要用户交互和设备解锁的正常用户流程不同这种攻击展示了恶意软件如何在无需用户同意、生物特征识别、设备解锁或提升权限的情况下静默获取所需的签名。为了理解这一点需要关注 Chrome 的设备身份密钥该密钥向云端身份验证器证明客户端设备的所有权。生成所需的断言涉及使用设备的一个硬件支持密钥对发送给云端身份验证器的数据进行签名这个密钥可以是身份密钥或用户验证密钥UV 密钥。虽然这两个密钥都与硬件绑定但访问方式不同。对于身份密钥Chrome 会创造条件使其能够在以普通用户身份运行且不提升权限、不触发设备解锁保护机制的情况下请求签名。在 Windows 系统上Chrome 调用相关函数时不指定密钥名称使 TPM 支持的密钥成为临时密钥防止其持久化到磁盘。Chrome 不将私钥存储在 TPM 中而是调用相关函数将密钥导出为 NCRYPT_OPAQUE_KEY_BLOB指示 TPM 使用 TPM 驻留密钥对私钥进行加密。生成的 blob 存储在 passkey_enclave_state 文件中作为 wrapped_identity_private_key以便在同一物理 TPM 上后续使用。恶意软件可以从磁盘或 Chrome 内存中提取这个 wrapped_identity_private_key然后使用标准的 Windows 密码学 API下一代CNGAPI 在不提升权限的情况下调用加密操作模仿 Chrome 的行为。下面详细介绍完整的 Pass - ta - key 攻击流程该流程允许在受害者设备上运行无特权恶意软件的远程攻击者以受害者的身份进行身份验证。攻击流程包括以下阶段攻击者收集受害者的同步通行密钥记录后选择目标账户并发起通行密钥登录依赖方返回新的身份验证挑战攻击者与 Google 云端身份验证器发起 WebSocket 握手攻击者使用握手的哈希值与受害者的 TPM 进行交互并使用提取的身份密钥对握手哈希和断言请求进行签名攻击者向云端身份验证器发送包含身份密钥签名的断言请求从云端身份验证器的角度看该请求看起来像是来自可信设备的有效请求因此它会生成有效的断言响应该断言随后被转发给依赖方完成身份验证攻击者获得对受害者账户的完全控制权。当依赖方不严格要求用户验证时Pass - ta - key 攻击非常有效。许多依赖方将 WebAuthn 的 userVerification 参数配置为“首选”而非“必需”以支持不同的设备和用户体验这使得它们容易受到这种攻击。当依赖方明确要求用户验证时人们通常期望云端身份验证器拒绝未使用通过 PIN 或生物特征验证的密钥签名的请求。然而实际情况并非如此。无论请求是使用身份密钥还是 UV 密钥签名云端身份验证器都会返回有效的断言区别仅在于身份验证器数据中的一个比特即用户验证UV标志。当使用 UV 密钥签名断言时该标志设置为 1当使用身份密钥签名时该标志保持为 0。虽然 Pass - ta - key 攻击生成的断言在密码学上与依赖方的公钥匹配但测试表明当需要用户验证时攻击通常会失败因为 UV 标志未设置。尽管在需要用户验证时身份验证通常会被拒绝但并非所有依赖方都会始终一致地执行此行为。在测试中发现一些依赖方由于未正确验证 UV 标志而接受了身份验证这使得攻击即使在没有用户验证的情况下也能成功。这种缺乏验证的情况实际上将身份验证过程简化为单一因素。攻击者只需攻破设备身份密钥即使在需要 MFA 的情况下也能够成功进行身份验证并接管账户。已将此问题报告给受影响的依赖方。待攻击状态Silver Pass - Ta - Key 攻击当账户受到更强的身份验证要求保护时攻击者还必须绕过用户验证。云端身份验证器要求使用 UV 密钥签名的消息来设置 UV 标志。客户端交互控制对该密钥的访问因为操作系统通过与设备解锁相同的机制验证用户。如果不提升到系统权限或物理访问受害者设备攻击者似乎无法获得这种访问权限。攻击者可以通过以下机制绕过这一挑战攻击者不直接绕过对 UV 密钥的访问而是使云端身份验证器中已注册的现有密钥失效并注册一个由其控制的新生成密钥一旦攻击者控制的密钥注册成功任何使用该密钥签名的消息都会被云端身份验证器接受就好像用户已经成功解锁设备一样。这种方法具有重要意义。它允许攻击者在无需人工交互的情况下对受害者的所有账户进行全自动身份验证即使在强制执行用户验证的情况下也是如此。此外攻击者在身份验证期间不再需要实时访问受害者的设备。与之前的攻击不同之前的攻击每次身份验证都需要受害者设备上的活动恶意软件而 Silver 攻击提供了可重复使用的访问权限。这使得攻击者可以在自己的环境中访问受害者受通行密钥保护的账户而无需受害者的设备在线或处于活动状态。最终攻击者无需提升权限即可接管与受害者关联的所有通行密钥保护的账户。为了实施此攻击首要目标是使与目标设备关联的现有 UV 密钥失效。攻击者可以利用无特权的恶意软件使用设备身份密钥对其控制的请求进行签名并将其发送给云端身份验证器。攻击者可以代表受害者发出 device/forget 命令更简单的方法是直接删除受害者的 passkey_enclave_state 文件因为没有内置保护措施阻止其删除。无论采用哪种方法下次用户尝试使用通行密钥时Chrome 都将被迫重新注册设备。在 Windows 系统上设备注册只有在同一设备上第二次使用通行密钥后才会完成。在第一次使用时Chrome 会在后台与云端身份验证器开始注册流程同时提示用户输入 Google 密码管理器GPM恢复 PIN。如果 Chrome 在此时创建 UV 密钥还会触发 Windows Hello 提示要求用户再次使用生物特征或 PIN 进行身份验证。由于这两个步骤都可能涉及 PIN在同一流程中连续显示可能会让用户感到困惑并导致错误。为避免这种情况Chrome 会推迟 UV 密钥的创建。相反设备最初会以 uv_key_pending 状态注册。在第一次交互期间GPM 恢复 PIN 满足用户验证要求实际的 UV 密钥只会在下次使用通行密钥时创建和注册此时不再需要额外的提示。在迫使受害者进入重新注册状态后攻击者可以利用 uv_key_pending 条件。在自己的环境中攻击者生成一个非对称密钥对然后向云端身份验证器发送 device/add_uv_key 命令并将其控制的公钥作为 UV 密钥提供。云端身份验证器不会验证新注册 UV 密钥的证明以验证它们是否来自安全硬件。因此攻击者控制的密钥会与合法的设备身份密钥一起存储。从这一点开始攻击者可以使用伪造的 UV 密钥为与受害者关联的任何通行密钥请求签名并获取设置了 UV 位的断言。这使得攻击者即使在强制执行和验证用户验证的情况下也能访问高价值账户。窃取主密钥Golden Pass - Ta - Key 攻击在这种攻击中攻击者实际上获得了云端身份验证器的超级能力即解密同步通行密钥的能力。这尤其具有影响力因为它破坏了预期的保护机制。通行密钥的私钥由一个名为安全域密钥SDS的对称主密钥保护。这个主密钥无法直接访问它以加密的 wrapped_secret 形式存储在设备上。只有云端身份验证器能够在其隔离环境中使用其设备特定密钥wrapping_key解密这个 wrapped_secret。这种设计旨在即使客户端设备被攻破也能保护同步通行密钥。正如 Google 在回应一份漏洞报告时指出的那样云隔离身份验证器的主要功能是使窃取通行密钥私有数据变得困难如果这些数据在本地可用将成为恶意软件的明显目标。这种模型的安全性最终取决于对 32 字节 SDS 的保护。如果攻击者能够获取 SDS他们实际上就获得了解密该账户所有同步通行密钥的能力。这使得他们能够以完全验证的用户身份进行身份验证并接管受害者依赖通行密钥的所有服务。这个密钥即使在设备丢失或账户恢复期间也不应暴露给客户端设备。然而意外地发现在与云端身份验证器注册时只需打开 chrome://device - log/FIDOSDS 就会出现在 Chrome 的日志中。在当前的 Chrome 实现中每个加入或重新加入账户安全域的设备都会从恢复密钥存储中检索 SDS。云端身份验证器包含一种机制允许 Chrome 促进恢复流程使密钥无法在客户端设备上解密但这种机制并未被使用。相反Chrome 以可访问的形式恢复了 SDS。一种可能的解释是需要在不同平台上标准化设备加入和恢复流程。与桌面环境不同iOS 和 Android 上的 Google 密码管理器不依赖云端身份验证器必须获取主密钥才能解密同步通行密钥。因此Chrome 似乎遵循了相同的恢复模型尽管云端身份验证器可以实现更隔离的方法。尽管 Google 在报告后从 Chrome 的日志输出中移除了这个密钥但 SDS 仍然会发送到客户端并在 Chrome 的进程内存中保持可访问状态。如果攻击者迫使受害者重新与云端身份验证器注册并知道要查找的模式他们就可以直接从内存中提取 SDS。Golden Pass - ta - key 攻击通过以下步骤实现完全账户接管攻击者使用与 Silver Pass - ta - key 攻击相同的机制迫使 Chrome 触发全新的注册流程攻击者监控系统以检测 passkey_enclave_state 文件的重新创建或修改一旦该文件被重新创建或修改攻击者转储 Chrome 的进程内存并提取暂时以明文形式存在的 SDS攻击者从 Chrome 的同步数据库中读取 WebauthnCredentialSpecifics 记录攻击者使用提取的 SDS 解密每个记录中的加密字段并恢复相应的通行密钥私钥攻击者使用恢复的私钥签署依赖方的挑战并成功以受害者的身份进行身份验证。Golden Pass - ta - key 攻击的影响更为广泛。除了攻击者可以在自己的环境中重复使用访问权限之外SDS 还允许攻击者解密所有现有通行密钥以及为该账户创建的任何未来通行密钥。虽然 Silver 攻击可以通过注销或重新注册设备来缓解但 Golden 攻击具有很强的持久性。即使检测到攻击补救措施也很有限。在 Google 的当前实现中无法轮换或撤销 SDS这意味着所有当前和未来的同步通行密钥仍然由同一个主密钥保护。缓解措施强制严格的用户验证UV验证依赖方应要求 userVerification required并在所有身份验证响应中验证 UV 标志。未能执行此检查可能会将身份验证简化为单一因素。验证设备密钥注册和证明凭证管理器应验证新注册设备密钥包括 UV 密钥和身份密钥的来源和证明。在未进行验证的情况下接受任意密钥会允许未经授权的密钥注册并绕过用户验证要求。强化恢复和设备重新注册流程凭证管理器的恢复 PIN 提示通常与注册或账户恢复相关而非常规的通行密钥身份验证。在正常使用通行密钥期间出现意外或重复的提示可能表明重新触发了注册或恢复流程这可能是由于钓鱼攻击或对通行密钥状态的本地篡改所致。这些流程对安全至关重要因为恢复操作可以重新建立设备信任并恢复对同步凭证的访问。监控代理应检测并限制不必要的注册和恢复流程重新触发特别是在本地通行密钥状态文件被删除或修改之后。在重新建立设备信任或恢复同步凭证之前应进行额外的验证。防止客户端暴露敏感密钥材料敏感材料如主密钥不应暴露给客户端包括通过内存或日志。相反凭证管理器应采用在代表客户端执行加密操作的同时不将底层密钥材料传输到客户端环境的设计。限制对本地通行密钥数据的访问对与通行密钥相关的存储如 Chrome 的同步数据库和本地状态文件如 passkey_enclave_state的访问应仅限于浏览器进程并通过平台访问控制进行保护。这可以减少从受攻击的端点枚举凭证、操纵注册状态或访问设备绑定密钥材料的可能性。改进对异常通行密钥使用的检测WebAuthn 定义了一个签名计数器机制旨在帮助依赖方检测克隆或意外重复使用的凭证。在同步通行密钥系统中身份验证断言通常包含一个恒定的 signCount 值。因此依赖方和凭证提供商对同步凭证的未授权使用包括从意外环境中提取或重复使用通行密钥的情况的可见性有限。集中协调身份验证操作的凭证管理器应考虑实施协调签名计数器机制以解决同步和多设备一致性挑战。这种机制可以提高对意外凭证使用或跨环境重复使用通行密钥的可见性和检测能力。结论通行密钥是身份验证安全领域的重要进步。通过消除共享密钥它们减少了历史上导致广泛账户泄露的各类攻击。那么未来在通行密钥的广泛应用中还会出现哪些新的攻击形式和应对策略呢