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身份验证的工作原理：
- 网站通过浏览器请求身份验证。
- 浏览器与认证器通信。
- 认证器检查凭据和用户存在。
- 认证器返回签名响应。
- 浏览器将此响应转发给网站进行验证。
（浏览器和认证器之间的这种交互在另一个规范中有更详细的描述：FIDO联盟的客户端到认证器协议（CTAP）。）这是一个简化的描述；WebAuthn规范允许更多种类的用例（例如，所有操作都可以通过移动应用程序而不是网站/浏览器进行）。然而，这些细节与理解Passkeys如何与密码学配合工作无关。
反网络钓鱼保护
WebAuthn通过源绑定解决网络钓鱼问题。该规范要求浏览器向认证器提供请求的来源（即网站域名）。认证器仅在发出请求的网站与创建Passkey的网站匹配时使用Passkeys。
这意味着，如果您为bank.com创建了一个Passkey，那么位于fake-bank.com的网络钓鱼网站根本无法使用它——您的认证器将拒绝该请求。每个网站还拥有自己唯一的密钥对，完全消除了密码重用问题。
此外，该规范仅允许使用HTTPS的来源，这意味着请求来自具有相应来源有效证书的服务器。
认证器类型
通常，认证器是“您拥有的东西”。所有认证器都可以检查用户在身份验证时是否实际存在。一些认证器还可以根据“您知道的东西”（如PIN）或“您是什么”（如生物特征）来验证用户。
您会遇到两种主要类型的认证器：
- 平台认证器：这些位于用户设备本身内部。
- 示例：iCloud钥匙串、Google密码管理器、Windows Hello、1Password
- 优点：方便，通常包括云备份功能
- 缺点：如果设备本身受损，则易受攻击
- 漫游认证器：这些是独立的专用硬件设备
- 示例：YubiKeys、Titan安全密钥、Feitian密钥
- 优点：更高的安全隔离性，不受设备受损影响
- 缺点：可能丢失或损坏，通常没有备份机制
如果平台可以进行跨平台通信（如蓝牙），其平台认证器也可以通过与另一台设备（如智能手机¹）通信用作漫游认证器。对于高价值应用中的最大安全性，我们建议使用专用硬件安全密钥作为您的认证器。
一些认证器向用户显示其正在生成数字签名的请求的详细信息。对于无法执行此操作的认证器，浏览器将显示这些详细信息。在批准身份验证请求之前，请务必验证这些详细信息。
当用户在网站上注册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规范列出了一些定义的扩展，并链接到Internet分配号码权威（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，开发者应尽可能支持它们。硬件安全密钥为高价值应用提供最强的保护，而平台认证器通常提供更好的用户体验和备份功能。在不受信任的设备上进行身份验证时，使用来自具有自己显示器的单独设备的Passkey来验证身份验证请求。
- 开发者应实现帐户恢复机制，因为Passkey是无法在丢失时重建的加密密钥对。即使具有备份功能的平台认证器也带有用户应了解的风险。
Passkey可以用作第一身份验证因素、第二身份验证因素，甚至多个身份验证因素。然而，开发者需要在其更广泛的威胁模型中考虑Passkey。为了保护免受恶意服务器（如E2EE应用中的）侵害，实现子资源完整性和二进制透明度技术。随着WebAuthn的发展，新扩展将启用更多密码应用，尽管支持因浏览器和认证器而异。
如果您正在实现Passkey或探索WebAuthn扩展的新颖用途，请联系我们以评估您的设计和实现，并帮助保护您的用户。
¹智能手机通常还支持称为“混合传输”的东西，其中手机通过WebSocket与浏览器通信，同时通过蓝牙低功耗单独证明其与浏览器的物理接近性。↩︎
²HKDF Extract的盐参数将是凭据的随机生成的32字节密钥，输入密钥材料将是SHA-256摘要。结果值可用作HKDF Expand的伪随机密钥。不建议以这种方式每个Passkey生成多个伪随机密钥。相反，可以通过改变HKDF Expand的info参数从单个伪随机密钥派生多个密钥。↩︎
如果您喜欢这篇文章，请分享： Twitter LinkedIn GitHub Mastodon Hacker News
关于我们
自2012年以来，Trail of Bits帮助保护了世界上一些最受针对的组织和产品。我们结合高端安全研究和真实世界攻击者心态来降低风险并强化代码。 阅读更多：www.trailofbits.com
社交 Twitter LinkedIn GitHub Mastodon Hacker News
最近帖子 构建安全消息传递很难：对Bitchat安全辩论的细致看法 使用Deptective调查您的依赖项 系好安全带，Buttercup，AIxCC的评分回合正在进行中！ 使您的智能合约超越私钥风险 Go解析器中意外的安全陷阱
类别 aixcc 8apple 13应用安全 19攻击 14审计 14身份验证 6基准测试 1binary-ninja 15区块链 90c/c++ 1捕获标志 11职业 3codeql 6编译器 33会议 33机密计算 1容器 3密码学 79crytic 4网络大挑战 8darpa 27设计评审 1动态分析 14ebpf 6echidna 1生态系统安全 10教育 17帝国黑客 7工程实践 23事件 8漏洞利用 30模糊测试 51go 10指南 15实习项目 42不变式开发 3iverify 5java 1内核 1kubernetes 3linux 8llvm 5机器学习 36恶意软件 7manticore 17mcp 4mcsema 11内存安全 2meta 12缓解措施 11mlir 2开源 28操作安全 1osquery 23论文评审 11人员 8播客 1政策 14新闻稿 29隐私 9产品 8程序分析 22提示注入 3递归 1研究实践 40逆向工程 18rust 8safedocs 1semgrep 9sinter 1slither 4快照模糊测试 1赞助 12稳定币 1静态分析 37供应链 11符号执行 18测试手册 6威胁建模 4阈值签名 1工具发布 7培训 3vast 2漏洞 4漏洞披露 22windows 3在Trail of Bits工作 4年度回顾 6零知识 12© 2025 Trail of Bits. 使用Hugo和Mainroad主题生成。