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。由于 Passkeys 本质上是随机生成的加密密钥对，因此真的没有恢复的希望。大多数平台认证器，如 iCloud 钥匙串、Google 密码管理器和 1Password，允许通过将 Passkeys 同步到云来备份它们。然而，这始终是一种权衡：可恢复的 Passkeys 具有更大的攻击面，因为攻击者可能会尝试通过恢复机制获取 Passkey。一般来说，网站必须为用户失去对其 Passkeys 的访问权限时提供恢复机制，同时记住攻击者可能会以这种恢复机制为目标。

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

威胁模型

尽管您可能听说过营销声明，但 Passkeys 并不是安全银弹。让我们看看它们实际能防范什么。

Passkeys 的威胁模型表明，它们可以防范密码通常防范的威胁，同时还消除了钓鱼和密码重用的风险。这是一个重大改进！WebAuthn 规范的"一致性"部分做出了非常强烈的声明，暗示符合规范的网站、浏览器和认证器可以"安全"防范恶意行为。

这一说法过于简化了安全现实。以下是仍然可能发生的真实攻击场景：

基于浏览器的攻击：一些认证器（如 YubiKey 5C）没有内置显示器，完全依赖浏览器向用户显示他们正在认证的网站。如果您的浏览器被恶意软件或恶意扩展程序破坏，它可能会向您显示"attacker.com"，而实际上向您的认证器发送为"google.com"签名的请求。

被破坏的认证器：Passkeys 的安全性取决于认证器保护私钥。假冒的硬件密钥、有后门的认证器软件或冒充操作系统内置认证器的恶意软件可能会秘密提取您的私钥。想象一下从不值得信赖的来源购买看似 YubiKey 的东西——它可能会将您的密钥副本发送给其他人。

Passkeys 不能完全防范大多数用户设备的破坏，例如恶意浏览器或恶意软件。然而，它们确实有效地限制了攻击速率，因为每个签名都需要与认证器进行单独的用户交互。此外，Passkeys 不能防范可以通过直接接管或子域名劫持控制网站域的攻击者。

网站需要考虑的另一件事是凭证 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 扩展的新颖用途，请联系我们评估您的设计和实现，并帮助保护您的用户。更多精彩内容 请关注我的个人公众号 公众号（办公 AI 智能小助手）公众号二维码

办公AI智能小助手