Passkey 背后的密码学原理
Passkey 背后的密码学原理
Joop van de Pol
2025年5月14日
当大多数人想到密码学时，通常首先想到的是加密：保持信息的机密性。但同样重要（甚至更重要）的是真实性：确保信息确实来自真实的来源。当你访问一个网站时，服务器通常通过由 Web Public Key Infrastructure (PKI) 认证的 Transport Layer Security (TLS) 证书来证明其身份。密码是用户认证的传统解决方案，但它们容易受到网络钓鱼攻击和数据泄露的影响。这就是 passkey 发挥作用的地方。
本文不会解释什么是 passkey 以及它们为什么比密码更好，因为已经有许多 其他 资源 进行了介绍，而是将探讨 passkey 背后的密码学原理、它们提供的保证（或不提供的保证），以及可以使用它们进行的有趣的密码学操作，例如生成密钥和存储证书。你需要了解 passkey 背后的密码学原理，才能正确地实现安全认证。我们还将讨论主要的 passkey 规范 WebAuthn，并向你展示如何使用 passkey 机制的扩展来构建具有不同功能的更复杂的系统。
Passkey 密码学基础
从核心上讲，passkey 只是用于生成数字签名的密钥对。当注册一个 passkey 时，网站会保存公钥和一个标识符。当通过 passkey 验证用户身份时，网站会提供一个挑战，并等待一个包含此挑战（以及一些其他元数据，例如标识符）的签名响应。该标识符用于查找公钥，该公钥用于验证签名。
从密码学的角度来看，这非常简单明了。私钥验证用户身份，但不会将对攻击者有用的敏感信息传递给服务器。如果服务器挑战生成正确——例如，作为 32 字节的均匀随机序列——那么它将防止重放攻击。由于服务器只保存公钥，并且用户不发送敏感信息，因此在发生黑客攻击时，不会泄露任何信息。
但是，仅靠数字签名不足以解决网络钓鱼问题。如果我们只停留在密码学原语上，用户仍然容易受到攻击。例如，如果没有额外的保护措施，攻击者可能会诱骗用户为错误的网站签署挑战，或者在多个网站上重复使用相同的密钥对。
这就是为什么 passkey 构建在 W3C 的 WebAuthn 规范之上，该规范在基本密码学之上增加了至关重要的安全属性。让我们看看 WebAuthn 如何将这些简单的密码学原语转换为抗网络钓鱼的认证系统。
WebAuthn
WebAuthn 是 passkey 背后的主要规范。简单来说，用户通过其浏览器（WebAuthn 用户代理）在诸如笔记本电脑、手机或 PC（客户端设备）等设备上访问一个网站（依赖方）。浏览器与认证器交互，认证器是一种硬件或软件，用于生成 passkey 密钥对，并使用此密钥对创建数字签名。
图 1：简化的 passkey 认证流程视图。
在上图中，你可以看到 passkey 认证是如何工作的：
- 网站通过浏览器请求认证。
- 浏览器与认证器通信。
- 认证器检查凭据和用户状态。
- 认证器返回签名响应。
- 浏览器将此响应转发到网站进行验证。
（浏览器和认证器之间的这种交互在另一个规范中有更详细的描述：FIDO 联盟的 Client to Authenticator Protocol (CTAP)。）这是一个简化的描述；WebAuthn 规范允许更多种类的用例（例如，一切都可以通过移动应用程序而不是网站/浏览器来工作）。但是，这些细节与理解 passkey 如何与密码学一起工作无关。
反网络钓鱼保护
WebAuthn 通过源绑定解决网络钓鱼问题。该规范要求浏览器向认证器提供请求的源（即，网站域名）。反过来，认证器仅在发出请求的网站与创建 passkey 的网站匹配时才使用 passkey。
这意味着如果你为 bank.com 创建了一个 passkey，则 fake-bank.com 上的网络钓鱼网站根本无法使用它——你的认证器将拒绝该请求。每个网站还获得其自己唯一的密钥对，从而完全消除了密码重用问题。
此外，该规范仅允许使用 HTTPS 的源，这意味着该请求来自具有相应源的有效证书的服务器。
认证器的类型
一般来说，认证器是“你拥有的东西”。所有认证器都可以检查用户在认证时是否实际存在。一些认证器还可以根据“他们知道的东西”（例如 PIN 码）或“他们是什么”（例如他们的生物识别信息）来验证用户。
你将遇到两种主要的认证器类型：
- 平台认证器：这些认证器位于用户设备本身内部。
- 示例：iCloud Keychain、Google Password Manager、Windows Hello、1Password
- 优点：方便，通常包括云备份功能
- 缺点：如果设备本身受到攻击，则容易受到攻击
- 漫游认证器：这些是单独的专用硬件设备
- 示例：YubiKeys、Titan Security Keys、Feitian keys
- 优点：更高的安全隔离性，不受设备攻击的影响
- 缺点：可能会丢失或损坏，通常没有备份机制
如果一个平台可以进行跨平台通信（例如，蓝牙），其平台认证器也可以通过与另一个设备（例如，智能手机1）通信来用作漫游认证器。为了在高价值应用中获得最大的安全性，我们建议使用专用硬件安全密钥作为你的认证器。
一些认证器会向用户显示它正在生成数字签名的请求的详细信息。对于无法执行此操作的认证器，浏览器将改为显示这些详细信息。在批准认证请求之前，请务必验证这些详细信息。
当用户在网站上注册 passkey 时，认证器会生成一个 passkey 和一个标识符（凭据 ID）。网站存储公钥和标识符，并将它们与用户帐户关联起来。然后，网站可以使用此标识符来告诉认证器他们想要访问哪个 passkey。一些认证器具有很大的存储空间，它们自己存储所有用户 passkey。其他认证器则不然，因此它们会加密 passkey，并在注册期间将加密的 passkey 作为标识符提供给网站。当网站想要验证用户身份时，它会将标识符提供给浏览器，浏览器又将其提供给认证器，认证器会对其进行解密并使用该 passkey。本质上，网站正在存储 passkey，但由于它是加密的，因此如果网站遭到黑客攻击，它的价值有限。
从理论上讲，你可以只将密码学密钥对存储在一个文件中，编写一些围绕它的软件，使用此密钥对进行密码学操作，并假装它是一个认证器。但是，网站如何知道其用户是否正在使用安全的认证器？认证器可以通过在用户创建 passkey 时生成一个证明声明来加密地证明关于其来源的某些事实，例如谁制造了它；此声明由制造商签名的证书链支持。这对于企业用户尤其有用，因为它允许企业确保所有用户都拥有满足某些安全要求的特定认证器。但是，证明是可选的：WebAuthn 规范不要求认证器支持它。
最后，与任何“你拥有的东西”的身份验证因素一样，一个重要的问题是，当你丢失它或它坏了会发生什么？一般来说，丢失认证器意味着丢失了由它控制的所有 passkey。由于 passkey 本质上是随机生成的密码学密钥对，因此实际上没有恢复的希望。大多数平台认证器，例如 iCloud Keychain、Google Password Manager 和 1Password，允许通过将 passkey 同步到云来备份它们。但是，这始终是一种权衡：可恢复的 passkey 具有更大的攻击面，因为攻击者可能会尝试通过恢复机制获得 passkey。一般来说，重要的是网站要有恢复机制，以防止用户失去对其 passkey 的访问权限，同时记住攻击者可能会针对此恢复机制。
虽然使用具有备份功能的平台认证器可以降低丢失 passkey 的风险，但它并不能消除它。被该平台禁止的用户将失去对其 passkey 的访问权限，并且该平台可能会意外删除 passkey。此外，平台还可以支持 passkey 共享或家庭帐户，多个用户可以访问相同的 passkey。网站应警告用户这些风险，具体取决于 passkey 提供的访问权限。
威胁模型
尽管你可能听过一些营销声明，但 passkey 并不是安全银弹。让我们看看它们实际保护什么。
passkey 的威胁模型 显示它们可以防御密码通常可以防御的威胁，同时还可以消除网络钓鱼和密码重用的风险。这是一个重大的改进！WebAuthn 规范的一致性部分 做出了非常强烈的声明，暗示符合该规范的网站、浏览器和认证器可以“安全地”抵御恶意行为。
这种说法过于简化了安全现实。以下是仍然可能发生的真实攻击场景：
- 基于浏览器的攻击：一些认证器（例如 YubiKey 5C）没有内置显示器，完全依赖浏览器来向用户显示他们正在认证的网站。如果你的浏览器被恶意软件或恶意扩展程序破坏，它可能会向你显示“attacker.com”，而实际上向你的认证器发送了为“google.com”签名的请求。
- 受损的认证器：passkey 的安全性取决于认证器保护私钥。伪造的硬件密钥、后门的认证器软件或模仿你操作系统内置认证器的恶意软件可能会秘密提取你的私钥。想想从不可靠的来源购买看起来像 YubiKey 的东西——它可能会将你的密钥副本发送给其他人。
Passkey 不能完全防御用户设备的大多数攻击，例如恶意浏览器或恶意软件。但是，它们确实可以作为攻击的有效速率限制器，因为每个签名都需要用户与认证器进行单独的交互。此外，passkey 不能防御可以控制网站域名的攻击者，无论是通过直接接管还是通过子域名劫持。
网站需要考虑的另一件事是凭据 ID 冲突。该规范仅要求它们是概率上唯一的——这意味着它们是随机生成的，重复的概率极低（但非零），类似于 UUID。
为什么这很重要？当用户注册 passkey 时，网站会将凭据 ID 存储为该用户 passkey 的标识符。如果攻击者可以以某种方式注册一个与其目标受害者具有相同凭据 ID 的 passkey，他们可能会造成认证混乱。
这似乎有些牵强，但请考虑以下场景：
- 知道受害者凭据 ID 的攻击者（可能从网络流量中捕获）可能会尝试注册他们自己的具有相同 ID 的 passkey。
- 恶意认证器应用程序可能会故意生成重复的凭据 ID，而不是遵循协议的随机性要求。
- 实现错误可能会降低凭据 ID 生成的有效随机性。
解决方法很简单：当新 passkey 的凭据 ID 与数据库中已有的凭据 ID 匹配时，网站应始终拒绝注册尝试。这创建了一个简单的“先到先得”的保护措施，以防止凭据 ID 冲突。
扩展
WebAuthn 还支持为用于生成凭据和执行认证的机制定义扩展。基本上，网站可以通过 WebAuthn API 请求使用一个或多个扩展。浏览器和认证器将处理这些扩展（如果它们支持），并忽略不支持的扩展。
WebAuthn 规范列出了一些已定义的扩展，并链接到 Internet Assigned Numbers Authority (IANA) 注册表，以获取更多扩展的定义。这些扩展的范围从启用与旧 API 的向后兼容性到支持完全不同的密码学功能。由于这篇博文是关于密码学的，因此后一种扩展最有趣。
一种这样的扩展是 WebAuthn 规范称之为 prf（用于伪随机函数系列）的扩展，它构建在 FIDO CTAP v2.1 规范中定义的 hmac-secret 扩展之上。使用 prf 扩展，认证器可以使用固定的随机生成的 32 字节 HMAC 密钥来计算 HMAC-SHA-256。HMAC 计算的输入是一个固定的 WebAuthn 前缀的 SHA-256 摘要，后跟网站提供的输入。虽然此扩展不够灵活，无法实现像 HKDF 这样的功能，但可以使用它来实现 HKDF Extract2。
另一个这样的扩展名为 largeBlob，它会提示支持的认证器存储一个“大 blob”的不透明数据，网站可以在认证断言期间读取或写入该数据。网站可以使用它来存储任何（敏感）数据，例如证书或密码学密钥。
因此，使用这些扩展，可以派生或存储静态密码学密钥。正如 largeBlob 示例中建议的那样，你甚至可以将它用于端到端加密。但是，与浏览器设置中密码学的所有应用一样，实现真正的端到端安全非常困难（如果不是不可能）。通常，这要求系统能够抵御恶意服务器。Web 密码学在服务器提供的 JavaScript 上运行，这意味着恶意服务器可以只提供恶意 JavaScript，提取密钥，将解密的消息发送回服务器等等。更糟糕的是，恶意服务器可以以高度有针对性的方式执行此操作，向大多数用户提供正确的 JavaScript，但向特定的目标用户提供恶意 JavaScript。为 Web 上的代码实现子资源完整性（例如，与受信任的第三方一起存储所有已发布版本的哈希值）和 二进制透明度 技术（例如，可公开验证的、防篡改的日志）是解决此类问题的两种有希望的解决方案。
此外，重要的是要注意该规范将所有扩展视为可选，这意味着不能保证浏览器和认证器支持它们。在需要特定扩展时，网站需要检查扩展是否可用，否则用户将无法访问其服务。将来，所有主要的浏览器和认证器有望支持它们，这可以改善 Web 上密码学的密钥管理。
一般来说，该规范正在积极开发中，并且还有许多有趣的扩展空间。可能的扩展包括额外的密码学原语（例如，更高级的签名方案和零知识证明），但单调计数器将是一个有趣的扩展。虽然这并非直接的密码学功能，但单调计数器可用于保护外部存储（例如，端到端加密的云存储）免受回滚攻击。
Passkey 的前进之路
现在是采用 passkey 的时候了。passkey 的密码学基础提供了强大的安全保证，使其成为现代认证系统在通过 WebAuthn 正确实施时的明确默认选择。虽然不是一个完美的安全解决方案，但 passkey 消除了困扰密码数十年的许多关键漏洞：passkey 永远不会将敏感信息传输到服务器，不能在站点之间重用，并且通过源绑定来抵御网络钓鱼。
以下是我们对用户和开发人员的建议：
- 用户应采用 passkey，开发人员应尽可能支持它们。硬件安全密钥为高价值应用提供最强的保护，而平台认证器通常提供更好的用户体验和备份功能。在不受信任的设备上进行身份验证时，请使用来自具有自己显示器的单独设备的 passkey 来验证身份验证请求。
- 开发人员应实施帐户恢复机制，因为 passkey 是密码学密钥对，如果丢失则无法重建。即使具有备份功能的平台认证器也存在用户应理解的风险。
Passkey 可以用作第一认证因素、第二认证因素，甚至是多个认证因素。但是，开发人员需要在更广泛的威胁模型 中考虑 passkey。为了防止恶意服务器（例如在 E2EE 应用中），请实施子资源完整性和二进制透明度技术。随着 WebAuthn 的发展，新的扩展将启用更多的密码学应用，但支持在浏览器和认证器之间有所不同。
如果你正在实施 passkey 或探索 WebAuthn 扩展的新颖用途，请联系我们 以评估你的设计和实施，并帮助保护你的用户。