Passkeys背后的密码学

当大多数人想到密码学时，首先想到的通常是加密：保持信息的机密性。但同样重要（甚至更重要）的是真实性：确保信息确实来自可信来源。当您访问网站时，服务器通常通过由Web公钥基础设施（PKI）认证的传输层安全（TLS）证书来证明其身份。密码是用户身份验证的传统解决方案，但它们容易受到网络钓鱼攻击和数据泄露的影响。这就是Passkeys的用武之地。

本文不会解释Passkeys是什么以及为什么它们比密码更好——许多其他资源已经涵盖了这一点——而是将探讨Passkeys背后的密码学、它们提供或不提供的保证，以及您可以使用它们进行的有趣密码学操作，例如生成密码学密钥和存储证书。您需要了解Passkeys背后的密码学，才能正确实现安全身份验证。我们还将讨论主要的Passkey规范WebAuthn，并向您展示如何使用Passkey机制的扩展来构建具有不同功能的更复杂系统。

Passkey密码学基础

Passkeys的核心只是用于生成数字签名的密钥对。注册Passkey时，网站保存公钥和标识符。通过Passkey验证用户身份时，网站提供一个挑战，并等待包含此挑战（以及一些其他元数据，如标识符）的签名响应。标识符用于查找公钥，公钥用于验证签名。

从密码学的角度来看，这非常简单。私钥验证用户身份，但不会向服务器传输对攻击者有用的敏感信息。如果服务器挑战是正确生成的——例如，作为32字节的均匀随机序列——那么它将防止重放攻击。由于服务器仅持有公钥，且用户不会向其发送敏感信息，因此在被黑客攻击时没有可泄露的内容。

但仅凭数字签名不足以解决网络钓鱼问题。如果我们仅停留在密码学原语层面，用户仍然容易受到攻击。例如，在没有额外保护措施的情况下，攻击者可能会诱骗用户为错误的网站签名挑战，或在多个网站上重复使用相同的密钥对。

这就是为什么Passkeys建立在W3C的WebAuthn规范之上，该规范在基本密码学之外添加了关键的安全属性。让我们看看WebAuthn如何将这些简单的密码学原语转变为抗网络钓鱼的身份验证系统。

WebAuthn

WebAuthn是Passkeys背后的主要规范。简单来说，用户通过浏览器（WebAuthn用户代理）在设备（如笔记本电脑、手机或PC）上访问网站（依赖方）。浏览器与认证器交互，认证器是生成Passkey密钥对的硬件或软件，并使用此密钥对创建数字签名。

图1：Passkey身份验证流程的简化视图。

在上面的图中，您可以看到Passkey身份验证的工作原理：

1. 网站通过浏览器请求身份验证。
2. 浏览器与认证器通信。
3. 认证器检查凭据和用户存在。
4. 认证器返回签名响应。
5. 浏览器将此响应转发给网站进行验证。

（浏览器和认证器之间的交互在另一个规范中有更详细的描述：FIDO联盟的客户端到认证器协议（CTAP）。）这是一个简化的描述；WebAuthn规范允许更多种类的用例（例如，一切都可以通过移动应用程序而不是网站/浏览器工作）。然而，这些细节与理解Passkeys如何与密码学配合工作无关。

反网络钓鱼保护

WebAuthn通过源绑定解决网络钓鱼问题。该规范要求浏览器向认证器提供请求的来源（即网站域名）。认证器仅在发出请求的网站与创建Passkey的网站匹配时使用Passkeys。

这意味着，如果您为bank.com创建了一个Passkey，那么位于fake-bank.com的网络钓鱼网站根本无法使用它——您的认证器将拒绝该请求。每个网站还拥有自己唯一的密钥对，完全消除了密码重复使用问题。

此外，该规范仅允许使用HTTPS的来源，这意味着请求来自具有相应来源有效证书的服务器。

认证器类型

通常，认证器是“您拥有的东西”。所有认证器都可以检查用户在身份验证时是否实际存在。一些认证器还可以根据“您知道的东西”（如PIN）或“您是什么东西”（如生物特征）来验证用户。

您会遇到两种主要类型的认证器：

• 平台认证器：这些位于用户设备本身内部。

  • 示例：iCloud钥匙串、Google密码管理器、Windows Hello、1Password
  • 优点：方便，通常包括云备份功能
  • 缺点：如果设备本身被入侵，则容易受到攻击

• 漫游认证器：这些是独立的专用硬件设备

  • 示例：YubiKeys、Titan安全密钥、飞天密钥
  • 优点：更高的安全隔离性，不受设备入侵影响
  • 缺点：可能丢失或损坏，通常没有备份机制

如果平台可以进行跨平台通信（如蓝牙），其平台认证器也可以通过与其他设备（如智能手机¹）通信用作漫游认证器。对于高价值应用中的最大安全性，我们建议使用专用硬件安全密钥作为您的认证器。

一些认证器会向用户显示其正在生成数字签名的请求的详细信息。对于无法执行此操作的认证器，浏览器将显示这些详细信息。在批准身份验证请求之前，请务必验证这些详细信息。

当用户在网站上注册Passkey时，认证器会生成一个Passkey和一个标识符（凭据ID）。网站存储公钥和标识符，并将它们与用户帐户绑定。然后，网站可以使用此标识符告诉认证器他们想要访问哪个Passkey。一些认证器具有大量存储空间，并自行存储所有用户Passkey。其他认证器没有，因此它们会加密Passkey，并在注册期间将加密的Passkey作为标识符提供给网站。当网站想要验证用户身份时，它会向浏览器提供标识符，浏览器再将其提供给认证器，认证器解密并使用Passkey。本质上，网站存储Passkey，但由于它是加密的，如果网站被黑客攻击，其价值有限。

理论上，您可以将密码学密钥对存储在文件中，围绕它编写一些使用此密钥对进行密码学操作的软件，并假装它是一个认证器。但网站如何知道其用户是否在使用安全认证器？认证器可以在用户创建Passkey时通过生成证明声明来密码学证明其来源的某些事实，例如谁制造了它；此声明由制造商签名的证书链支持。这对企业用户尤其有用，因为它允许企业确保所有用户都拥有符合某些安全要求的特定认证器。然而，证明是可选的：WebAuthn规范不要求认证器支持它。

最后，与任何“您拥有的东西”身份验证因素一样，一个重要的问题是，当您丢失或损坏它时会发生什么？一般来说，丢失认证器意味着丢失由其控制的所有Passkey。由于Passkey本质上是随机生成的密码学密钥对，因此确实没有恢复的希望。大多数平台认证器，如iCloud钥匙串、Google密码管理器和1Password，允许通过将Passkey同步到云端来进行备份。然而，这总是一种权衡：可恢复的Passkey具有更大的攻击面，因为攻击者可能尝试通过恢复机制获取Passkey。一般来说，网站必须为用户丢失Passkey访问权限时提供恢复机制，同时要记住攻击者可能针对此恢复机制。

虽然使用具有备份功能的平台认证器降低了丢失Passkey的风险，但并未消除它。被平台封禁的用户将失去对其Passkey的访问权限，并且平台可能意外删除Passkey。此外，平台还可以支持Passkey共享或家庭帐户，其中多个用户可以访问相同的Passkey。网站应根据Passkey提供的访问权限警告用户这些风险。

威胁模型

尽管您可能听说过营销宣传，但Passkeys并不是安全银弹。让我们看看它们实际保护什么。

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规范列出了一些已定义的扩展，并链接到互联网号码分配机构（IANA）注册表以获取更多扩展的定义。这些扩展范围从启用与旧API的向后兼容性到支持完全不同的密码学功能。由于这篇博客文章是关于密码学的，后者扩展最有趣。

其中一个扩展是WebAuthn规范称为prf（伪随机函数族）的扩展，它建立在FIDO CTAP v2.1规范中定义的hmac-secret扩展之上。使用prf扩展，认证器可以使用固定的随机生成的32字节HMAC密钥计算HMAC-SHA-256。HMAC计算的输入是固定WebAuthn前缀的SHA-256摘要，后跟网站提供的输入。虽然此扩展不够灵活，无法实现像HKDF这样的功能，但可以使用它来实现HKDF Extract²。

另一个扩展称为largeBlob，并提示支持认证器存储一个“大 blob”的不透明数据，网站可以在身份验证断言期间读取或写入。网站可以使用它来存储任何（敏感）数据，如证书或密码学密钥。

因此，使用这些扩展，可以派生或存储静态密码学密钥。如largeBlob示例中所建议的，您甚至可能将其用于端到端加密。然而，与浏览器设置中所有密码学应用一样，实现真正的端到端安全性极其困难，甚至不可能。通常，这要求系统能够抵抗恶意服务器。Web密码学运行在服务器提供的JavaScript上，这意味着恶意服务器可以仅提供恶意JavaScript来提取密钥、将解密的消息发送回服务器等。更糟糕的是，恶意服务器可以以高度针对性的方式执行此操作，向大多数用户提供正确的JavaScript，但向特定目标用户提供恶意JavaScript。为Web上的代码实现子资源完整性（例如，将所有发布版本的哈希与受信任的第三方存储）和二进制透明度技术（例如，公开可验证、防篡改的日志）是解决此类问题的两种有前途的解决方案。

此外，重要的是要注意规范将所有扩展视为可选的，这意味着不能保证浏览器和认证器支持它们。网站在需要特定扩展时需要检查扩展是否可用，否则用户将无法访问其服务。将来，希望所有主要浏览器和认证器都支持它们，这可以改进Web上密码学的密钥管理。

总的来说，规范正在积极开发中，并且有空间容纳更多有趣的扩展。可能的扩展包括额外的密码学原语（如更高级的签名方案和零知识证明），但单调计数器将是一个有趣的扩展。虽然这不是直接的密码学功能，但单调计数器可用于保护外部存储——例如端到端加密的云存储——免受回滚攻击。

Passkeys的前进道路

现在是采用Passkeys的时候了。Passkeys的密码学基础提供了强大的安全保证，使它们在正确实现WebAuthn时成为现代身份验证系统的明确默认选择。虽然不是完美的安全解决方案，但Passkeys消除了困扰密码数十年的许多关键漏洞：Passkeys从不向服务器传输敏感信息，不能在站点之间重复使用，并通过源绑定抵抗网络钓鱼。

以下是我们对用户和开发者的建议：

• 用户应采用Passkeys，开发者应尽可能支持它们。硬件安全密钥为高价值应用提供最强的保护，而平台认证器通常提供更好的用户体验和备份功能。在不受信任的设备上进行身份验证时，使用来自具有自己显示屏的单独设备的Passkeys来验证身份验证请求。
• 开发者应实现帐户恢复机制，因为Passkeys是密码学密钥对，如果丢失则无法重建。即使具有备份功能的平台认证器也带有用户应了解的风险。

Passkeys可以作为第一个身份验证因素、第二个身份验证因素，甚至多个身份验证因素。然而，开发者需要在其更广泛的威胁模型中考虑Passkeys。为了保护免受恶意服务器（如E2EE应用中的）的攻击，请实现子资源完整性和二进制透明度技术。随着WebAuthn的发展，新扩展将启用更多密码学应用，尽管支持因浏览器和认证器而异。

如果您正在实施Passkeys或探索WebAuthn扩展的新颖用途，请联系我们以评估您的设计和实施，并帮助保护您的用户。

¹智能手机通常还支持称为“混合传输”的功能，其中手机通过WebSockets与浏览器通信，同时通过蓝牙低功耗单独证明其与浏览器的物理接近性。 ↩︎

²HKDF Extract的盐参数将是凭据的随机生成的32字节密钥，输入密钥材料将是SHA-256摘要。结果值可用作HKDF Expand的伪随机密钥。不建议以这种方式为每个Passkey生成多个伪随机密钥。相反，可以通过改变HKDF Expand的info参数从单个伪随机密钥派生多个密钥。 ↩︎