Passkeys 与 WebAuthn PRF：实现端到端加密 (2025)

WebAuthn 和 Passkeys 已经彻底改变了网络身份验证，通过公钥加密技术提供了能抵御网络钓鱼的无密码登录方式。但其功能远不止于登录。其中一个激动人心的特性是 WebAuthn 伪随机函数 (PRF) 扩展。该扩展允许 Web 应用程序在用户验证期间，直接从用户的 Passkey 或硬件安全密钥中派生出密钥。这使得我们仅用 Passkey 就能实现端到端加密数据或解密安全保险库，而无需额外的密码。在本文中，我们希望回答以下问题：

• Passkey PRF 用例： WebAuthn PRF 扩展有哪些有趣的用例？
• PRF 扩展支持： 目前，WebAuthn PRF 扩展在各大操作系统和浏览器中的实际支持情况如何？

本文将分析 WebAuthn PRF 扩展，探讨其技术规范、用例、实现细节、安全考量以及当前浏览器和操作系统的支持格局。我们将重点关注 2025 年生态系统的变化，并扩展 Matthew Miller 和 Levi Schuck 在 2023 年奠定的基础，他们早期的文章提供了详细的技术背景、实时示例和在线测试（包括加密）。

WebAuthn PRF 扩展 (PRF) 在 WebAuthn Level 3 规范中有正式定义。其核心目的是允许信赖方 (Relying Party)（即你的 Web 应用程序）在身份验证流程 (navigator.credentials.get()) 中，请求评估与特定 WebAuthn 凭证 (Passkey) 关联的伪随机函数。

PRF 使用一个安全保存在 authenticator 内并与凭证绑定的密钥，以及一个或多个由 Relying Party 提供的输入值，来生成一个确定性的、看起来像加密随机的输出。这个输出通常是一个 32 字节的字符串，可供客户端应用程序使用，最常见的用途是作为 WebAuthn 加密或密钥派生的对称密钥材料。

许多 authenticators，特别是 FIDO2 安全密钥，都实现了一个在客户端到认证器协议 (CTAP2) 中定义的基础功能，称为 hmac-secret 扩展。这个 CTAP2 扩展提供了对硬件支持的 HMAC（基于哈希的消息认证码）功能的访问，该功能就充当了伪随机函数。WebAuthn PRF 扩展则作为一种标准化的方式，让 Web 应用程序可以通过浏览器的 WebAuthn API 来访问这个 hmac-secret 功能。

为了防止网站可能欺骗 authenticator 生成用于非 Web 用途（如本地操作系统登录）的 HMAC，从而引发潜在的冲突或安全问题，WebAuthn 规范强制要求一个重要步骤：网站提供的输入（第一个和第二个盐值）在传递给底层的 hmac-secret 函数之前，必须先与一个特定的上下文字符串（“WebAuthn PRF” 和一个空字节）进行哈希运算。这有效地划分了 PRF 的输入空间，确保了从 Web 派生的输出与可能在其他上下文中使用的输出是截然不同的。

能够派生与 authenticator 绑定的密钥，为开发者解锁了几个引人注目的用例：

1. 客户端/端到端加密 (E2EE)： 这是 WebAuthn PRF 扩展的主要驱动力。基于浏览器的应用程序可以在登录时为每个凭证派生一个唯一的加密密钥。这个密钥随后可以与 WebCrypto API 一起使用，来加密本地或服务器上存储的用户数据。数据在静态时保持加密状态，只有在用户使用特定的 Passkey 成功验证后才能解密，从而增强了隐私和数据安全性。服务提供商可以存储用户数据而永远无法访问明文。这对于无密码世界中的应用程序尤其有用，因为如果没有 PRF 扩展，它们将需要额外请求一个以密码形式存在的秘密，这与无密码架构相矛盾。

2. 无密码保险库解密： 像密码管理器（例如 Bitwarden、1Password）或安全笔记应用（例如 Notesnook、Reflect）可以使用 PRF 来取代传统的主密码。用户使用他们的 Passkey 进行身份验证，PRF 扩展派生出保险库解密密钥，然后保险库就被解锁了——完全不需要主密码。Bitwarden 已经宣布支持此功能。此外，Dashlane 最近也采用了 WebAuthn PRF 扩展来加强网络钓鱼防护，并提高访问加密保险库的安全性。用户使用他们的 Passkey 进行身份验证，让 PRF 能够安全地派生保险库解密密钥，从而完全消除了对主密码的需求。

3. 安全密钥轮换： WebAuthn PRF 扩展允许在身份验证期间提供两个输入“盐值”（第一个和第二个）。这有助于实现加密密钥轮换方案。服务器可以使用第一个盐值请求“当前”密钥，使用第二个盐值请求“下一个”密钥。随着时间的推移，服务器可以更新哪个盐值对应当前密钥，从而在不干扰用户体验的情况下实现无缝轮换。在法规要求或内部政策要求所有密钥在特定时间内轮换的情况下，这一点尤为重要，并且能提高安全性。

4. 身份钱包和非托管系统： PRF 可以派生密钥来保护数字钱包中的身份数据，或启用非托管系统，在这些系统中私钥永远不会暴露在服务器端。

尽管规范已经定义，但实际的浏览器和平台支持是开发者面临的关键因素。支持情况一直在演变，直到最近，主要还局限于基于 Chromium 的浏览器。跟踪支持情况可能具有挑战性，因为 CanIUse.com 上没有专门针对 PRF 扩展的条目（搜索“webauthn”显示的是通用的 API 支持，而非特定扩展）。信息通常必须从浏览器发布说明、错误跟踪器和状态页面中收集。成功使用 WebAuthn PRF 扩展需要在技术栈的三个不同层面进行协调。PRF 扩展支持必须在每个层面都存在，该功能才能正常工作：

1. Authenticator： 这是硬件（如安全密钥）或平台组件（如 Windows Hello、iCloud Keychain 及相应的硬件模块，例如 TPM 或 Secure Enclave），它安全地存储凭证的密钥并执行实际的伪随机函数计算（通常使用 CTAP2 hmac-secret 功能）。如果 authenticator 缺乏这种基础的加密能力，PRF 就无法工作。

2. 操作系统 (OS)： 操作系统是浏览器和 authenticator 之间的桥梁。它提供必要的驱动程序和系统级 API，让浏览器能够发现、通信并请求 authenticators 的操作（特别是平台 authenticators 和通过 USB/NFC/蓝牙连接的设备）。操作系统必须能够识别并向浏览器暴露 authenticator 的 PRF (hmac-secret) 功能。如果操作系统不提供这条路径，浏览器就无法访问该功能。

3. 浏览器： 作为 Web 应用程序的接口，浏览器必须实现 WebAuthn JavaScript API，特别是要识别 prf 扩展，将 Web 请求转换为适用于操作系统/authenticator 的适当命令，处理将输入与上下文字符串进行哈希计算的关键安全步骤，并正确解析结果返回给应用程序。

在这三个层面——Authenticator 的能力、操作系统的暴露、或浏览器的实现——任何一个层面的失败或缺乏支持，都会导致 PRF 扩展无法工作。

这个时序图展示了这些参与者如何协同工作以支持 PRF 的简化版本。

一个能正常工作的 PRF 工作流需要 WebAuthn ↔ CTAP 链中的每一层都相互协作。 为了清晰起见，我们将讨论分为 (1) 浏览器 + 操作系统行为和 (2) authenticator 行为。

实现广泛 PRF 支持的过程凸显了 Web 标准扩展的一个常见挑战：实现通常是分阶段进行的，需要解决特定于平台的问题。我们将努力保持此表的更新，但请记住，由于 PRF 扩展是需要整个兼容性链进行适配的最新增补之一，预计会持续进行调整。

下面，我们按操作系统分解支持情况。

Windows 对 WebAuthn PRF 扩展的支持有限，因为其原生平台认证器 (Windows Hello) 目前缺少必要的 hmac-secret 功能。因此，PRF 功能依赖于外部安全密钥。

随着 macOS 15 的发布，平台认证器也开始支持 PRF。Safari 和 Chrome 都通过 iCloud Keychain 支持 PRF。Firefox 对平台认证器的支持仍在开发中。安全密钥仅适用于 Chrome。

iOS 和 iPadOS 上的情况与 macOS 类似，PRF 通过 iCloud Keychain 工作。然而，存在一些重要警告：iOS 18 的早期版本中存在一个可能导致数据丢失的错误，并且对外部安全密钥的支持尚未实现。

Android 目前为 WebAuthn PRF 扩展提供了最强大和广泛的支持。存储在 Google Password Manager 中的 Passkey 默认包含 PRF 支持，并且在除 Firefox 外的大多数主流浏览器中都能正常工作。

在上表中，我们包含了对第一方 Passkey 提供商支持最重要的组合。然而，当使用密码管理器作为第三方 Passkey 提供商时，必须单独考虑它们的具体能力。例如，1Password 在其 Android 版本中支持 PRF，但在其 iOS 版本中则不支持。此外，作为认证器的 Chrome Profile 也不支持 PRF。有关认证器的更多详细信息，请参见下文。

虽然 WebAuthn 规定了信赖方 (Relying Party) 可以请求什么，但客户端到认证器协议 (CTAP) 定义了认证器必须如何表现。实际上，认证器可分为四类：

1. 不支持 PRF：旧的平台认证器（例如 Windows Hello）、没有 hmac-secret 扩展的传统安全密钥，以及尚未采用 PRF 扩展的第三方提供商。

2. 仅在凭证创建时设置了 PRF 标志才支持 PRF：一些 CTAP 2.0/2.1 安全密钥公开了 hmac-secret，但如果信赖方在首次创建凭证以初始化密钥时没有请求，它们将拒绝 PRF 评估。

3. 即使在创建时未请求，身份验证时也可用 PRF：新一代硬件令牌以及 iCloud 和 Google Password Manager 无条件地公开 hmac-secret 功能；即使没有设置标志创建的凭证，在 navigator.credentials.get() 期间也能与 PRF 一起工作。

4. 完全符合 CTAP 2.2（PRF + 创建时返回第一个 PRF 值）：同步 Passkey 的平台认证器——例如 iCloud Keychain 和 Google Password Manager——可以根据请求，在 navigator.credentials.create() 期间就返回第一个 PRF 输出，从而简化密钥建立流程。

在设计备份、迁移或密钥建立逻辑时，了解认证器属于哪个类别至关重要。我们也在我们的演示中包含了对这些场景的测试。

你可以使用我们的交互式 WebAuthn PRF 演示应用直接体验 WebAuthn PRF 扩展。在这个演示中，你将能够：

• 使用 PRF 注册一个 Passkey，并确认你的认证器是否支持这个强大的扩展。
• 使用你的 Passkey 进行身份验证，并查看 PRF 生成的加密值的实际效果。

亲眼看到 PRF 值，可以突显使用 Passkey 进行安全的、基于密钥的操作的实际意义。它让你能够直接验证认证器对 PRF 扩展的兼容性，并观察 PRF 派生的密钥如何无需密码就能驱动 WebAuthn 端到端加密和安全保险库解密。

花点时间试试这个演示，了解你特定环境的 PRF 能力，有助于你更好地规划为用户量身定制的安全、无密码体验。

准备好测试 PRF 的强大功能了吗？点击上方图片或访问此链接，开始你的实践探索。

WebAuthn PRF 扩展并不是唯一与存储或派生数据相关的 WebAuthn 扩展。那么 Passkey PRF 与其他方案相比如何呢？

• PRF vs. credBlob / largeBlob：

  • credBlob：允许在创建凭证时存储一个很小（32 字节）的静态数据块。它主要不是为存储秘密而设计的，而且支持有限，尤其对于不可发现的凭证。

  • largeBlob：能够随可发现凭证存储更多数据（约 1KB），通常用于辅助数据，如证书。支持也有限（自 iOS 17 起 iCloud Keychain 支持，但 GPM 不支持）。Chrome 开发者明确表示，对于大多数用例，他们更倾向于关注 PRF 而非 largeBlob，尽管未来可能会进行开发。

  • PRF： 相比之下，PRF 是专门设计用于在身份验证期间，使用硬件绑定的秘密按需派生密钥，而不是存储静态数据块。它通常被认为是将加密密钥与 Passkey 绑定的最合适、最安全的标准机制。从讨论使用 blob 存储秘密到 PRF 的标准化和实现重点的演变，表明业界已趋向于将 PRF 作为此用例的专用解决方案。

• PRF vs. 密码派生密钥（例如 PBKDF2）： 传统上，客户端加密密钥是从用户密码派生的。PRF 提供了显著优势：

  • 更强的来源： 密钥源自认证器内部强大的加密材料，而不是可能脆弱或被重复使用的密码。

  • 抗网络钓鱼： 密钥派生与抗网络钓鱼的 WebAuthn 身份验证流程绑定。

  • 无密码： 实现了像保险库解密这样的用例，完全不需要密码。

• PRF vs. 其他 WebAuthn 数据： 试图从 WebAuthn 响应的其他部分（如签名、authenticatorData 或公钥）派生密钥，是根本上不安全和不正确的。这些组件要么是公开的、非秘密的，要么是为验证而设计的，而不是用于密钥派生。

对于安全地派生与 WebAuthn 凭证或 Passkey 直接关联的加密密钥材料，WebAuthn PRF 扩展是专门为此目的构建并推荐的标准方法。

在将 PRF 扩展集成到你的应用程序时，请考虑以下实用指南：

以下建议有助于开发者有效地应对当前 PRF 扩展支持的现状，并为未来的发展做好规划：

• 将 PRF 视为一种增强功能： 目前，WebAuthn PRF 扩展的支持在不同浏览器、操作系统和认证器之间差异很大。因此，应将 PRF 集成视为一种增强功能，而非核心依赖。

• 避免对 PRF 产生关键依赖： 避免让 PRF 成为关键任务功能的必要条件。当前的支持，尤其是在 macOS 上的 Safari 和 iOS 等平台上，仍然不一致且不完整。

• 为 Passkey 丢失场景做好准备： 请记住，使用 PRF 派生密钥加密的数据完全绑定于特定的 Passkey。丢失该 Passkey 将导致加密数据永久无法访问。务必实施强大的备份和恢复机制。

• 预计到 2026 年将获得更广泛的支持： PRF 扩展的支持正在迅速成熟。预计到 2026 年，它将在主流浏览器、操作系统和认证器中实现一致的可用性，特别是在第一方Passkey 提供商中。

• 关注 Windows 生态系统： 目前缺少通过 Windows Hello 实现的平台认证器支持。Windows 环境中的全面 PRF 集成在很大程度上依赖于微软的采纳策略，因此请密切关注该生态系统的发展。

遵循这些指南可确保开发者在 PRF 的采纳阶段能够顺利地集成它，同时保持兼容性和安全性。

了解 PRF 如何与你的整体 Passkey 策略相结合，有助于你在不增加不必要复杂性的情况下最大化其优势：

• 灵活集成： 没有必要在创建 Passkey 时就决定是否利用 PRF。现有的 Passkey 可以在以后无缝地与 PRF 用例集成，而无需额外的凭证管理开销。

• 对现有 Passkey 应用 PRF： 由于 PRF 在身份验证阶段 (navigator.credentials.get()) 运行，因此先前创建的 Passkey 可以在后期支持基于 PRF 的工作流。这使你的应用程序能够逐步增强安全性，而不会中断已建立的身份验证方法。这种方法适用于 iCloud Keychain 和 Google Password Manager (GPM) 以及较新的安全密钥。对于较旧的安全密钥，可能只有在创建凭证时请求了 hmac-secret 才会生成它。

• Passkey 复杂性考量： Passkey 管理固有的复杂性——例如凭证同步、跨设备身份验证和恢复过程——在使用 PRF 时同样适用。确保你的 PRF 实现与你的整体 Passkey 身份验证策略协调一致，保持简化的用户体验和强大的安全控制。

将 PRF 视为整体 Passkey 策略的一部分，有助于更平稳地过渡到更安全、更用户友好的身份验证实践。

对于处理敏感用户数据的企业服务提供商而言，将 WebAuthn PRF 与 Passkey 结合使用的能力为增强安全性和用户体验开辟了新的可能性，尤其是在需要对个人身份信息 (PII) 进行客户端加密或保护需要端到端加密的应用程序的场景中。虽然 Corbado Connect 主要设计用于无缝的企业 Passkey 集成，但它也可以促进 Passkey 扩展（如 SPC 或 PRF）的实现。

以下是 Corbado 如何协助希望集成 PRF 的组织：

• 促进 PRF 用于加密存储： 在企业环境中，有时需要安全地存储敏感信息，甚至可能直接在客户端存储，以最大限度地减少服务器端的 PII 暴露。Corbado Connect 可以配置为在 Passkey 身份验证流程 (navigator.credentials.get()) 中请求 PRF 值，从而使应用程序能够派生必要的加密密钥。
• 灵活的存储模式： 使用 PRF 派生密钥加密的数据可以根据安全要求和架构以多种方式存储：
  • 客户端： 使用 localStorage 或安全 Cookie 等机制直接存储在浏览器中。明文数据仅在客户端解密期间短暂存在。
  • Corbado 后端 (E2EE)： 虽然 Corbado 通常避免存储客户的 PII，但 PRF 机制在技术上允许在 Corbado 的服务器上存储客户端加密的数据。Corbado 不会拥有解密这些数据的密钥；解密仍将在成功的用户身份验证后在客户端进行。
  • 客户的后端： 加密数据也可以发送到并存储在企业自己的后端系统上，同时仍然受益于客户端加密。
• 安全的密钥派生流程： Corbado Connect 组件管理与 WebAuthn API 的交互。当请求 PRF 时：
  1. 认证器会生成一个与单个 Passkey 绑定的、用户特定的 PRF 输出。
  2. 此输出被安全地返回给客户端应用程序。
  3. 应用程序应随后使用 WebCrypto API 的密钥派生函数 (KDF)（例如 HKDF）从 PRF 输出中派生出一个强大的对称加密密钥。
  4. 此对称密钥与 WebCrypto（例如 AES-GCM）一起用于加密或解密目标信息（如 PII）。
• 后续登录时的无缝解密： 当用户再次使用相同的 Passkey 进行身份验证时，Corbado Connect 会发起相同的 PRF 请求。这将产生相同的 PRF 输出，允许应用程序重新派生相同的对称密钥并在客户端解密先前存储的信息。
• PRF 采纳情报： 实现 PRF 需要了解用户的环境（操作系统、浏览器、认证器）是否支持它。Corbado Connect 在身份验证期间收集有关用户设备和能力的信息。这些情报可用于：
  • 在完全激活依赖 PRF 的功能之前，确定用户群的 PRF 准备情况。
  • 机会性地实现 PRF，为受支持的用户提供增强功能，同时为不支持的用户保留后备机制（如提示重新验证或使用替代方法）。
• 简化 PII 可用性： 通过使用 PRF 加密已验证的 PII（例如，通过验证流程获得的身份属性）并将其存储在客户端，应用程序可以在Passkey 登录后立即为后续交互或交易提供此数据，与重新验证或基于应用程序的流程相比，显著减少了摩擦。
• 启用自定义 E2EE 系统： 虽然 Corbado Connect 为标准流程提供了 UI 组件，但其底层原理允许开发者将 PRF 功能更深入地集成到敏感应用程序中。这使得构建端到端加密系统成为可能，其中前端应用程序直接利用 PRF 派生的密钥对现有或新数据进行复杂的加密操作。目前，这仍然只能是机会性的，并且需要实现后备机制以不同的方式存储这些信息。

Corbado 旨在简化 Passkey 和 PRF 集成的复杂性，使企业能够安全有效地利用标准，适应特定的用例（如客户端 PII 加密），同时应对不断变化的格局。

WebAuthn PRF 扩展标志着在使真正的无密码、端到端加密应用程序成为现实方面迈出了重要一步。通过利用 Passkey 安全地派生加密密钥，它提供了无缝且安全的用户体验，而不会牺牲隐私。

直接回答本文开头提出的问题：

• 有趣的 PRF 用例： PRF 实现了引人注目的用例，例如端到端加密数据存储、密码管理器的无密码保险库解密、安全的加密密钥轮换方案，以及保护用户隐私的安全身份钱包或非托管系统，确保私钥永远不会离开客户端设备。

• PRF 支持的现状（2025 年 6 月）： 支持仍然是碎片化且不断发展的。虽然 Android 在浏览器和认证器方面拥有强大的支持，但像 macOS，尤其是 iOS 这样的平台支持尚不稳定，特别是在作为 CDA 源时存在严重错误。Windows 的支持主要局限于外部安全密钥，而通过 Windows Hello 的原生平台支持则明显缺失。

考虑使用 PRF 扩展的开发者应该预见到快速的改进，但仍需谨慎行事，构建能够优雅地处理当前局限性的弹性应用程序。随着主流平台和认证器生态系统的广泛采纳，支持 PRF 的无密码加密的未来看起来一片光明，有望在 Web 身份验证中增强隐私和可用性。