从U2F到Passkeys

引言

在过去十多年间，一系列标准逐渐发展为Passkeys——一种有望替代密码的认证方案。这些技术在发展过程中积累了相当复杂性，本文按时间顺序阐述这些核心技术的发展历程。所有内容均来自已发布的标准文档，但阅读这些标准并理解其整体架构仍具挑战性。

开端：U2F

U2F代表"通用第二因素"，包含两个标准：一个是计算机与称为安全密钥的可移动设备通信的协议，另一个是网站使用这些设备的JavaScript API。第一个标准也称为客户端到认证器协议（CTAP1），而现已过时的JavaScript API通常被称为"U2F API"。

U2F的目标是消除用户认证中的"持有者令牌"。持有者令牌是认证领域的术语，指任何用于证明身份的密钥。密码是最常见的例子，它之所以是持有者令牌，是因为通过披露它来证明身份，前提是其他人不知道这个密钥。

数字签名优于持有者令牌，因为可以通过签名证明拥有私钥，而无需披露私钥本身。因此U2F允许在Web认证中使用签名。

创建凭证

CTAP1只包含两个命令：创建凭证和从凭证获取签名。网站使用U2F JavaScript API发出请求，浏览器将其转换为CTAP1命令。

CTAP1创建凭证请求结构包含两个重要哈希值：客户端数据哈希和AppID哈希。客户端数据是由浏览器构建的JSON结构，安全密钥在其签名输出中包含此哈希，允许浏览器（或操作系统）将数据放入签名消息中。

注册响应

U2F安全密钥创建凭证后的响应包含：公共密钥、凭证ID、X.509证明证书和ECDSA签名。公共密钥是新创建凭证的公钥，U2F始终使用P-256曲线和SHA-256的ECDSA。

无状态设计

大多数U2F安全密钥在创建凭证时实际上不存储任何内容。返回的凭证ID实际上是加密的种子，允许安全密钥根据需要重新生成私钥。

获取断言

“断言"是来自凭证的签名。CTAP1断言请求结构与凭证创建类似，包含客户端数据和AppID哈希。安全密钥将尝试解密凭证ID并验证AppID哈希。

传输方式

大多数安全密钥是USB设备，在USB总线上显示为人机接口设备（HID）。支持NFC的安全密钥也很常见，通过NFC使用时不需要触摸传感器。还有蓝牙安全密钥，通过GATT协议工作。

FIDO2

U2F生态系统满足了第二因素认证的需求，但要消除密码还需要更多工作。因此开始开发新的安全密钥协议CTAP2，同时更新Web API，最终成为W3C的"Web认证"规范（WebAuthn）。CTAP2和WebAuthn共同构成了FIDO2工作。

可发现凭证

U2F凭证称为"不可发现"凭证，要使用它们必须知道其凭证ID。“可发现"凭证是安全密钥可以自行找到的凭证，因此它们也可以替代用户名。

用户验证

FIDO2具有称为"用户验证"的升级形式的用户存在。不同的安全密钥可以以不同方式验证用户。最基本的方法是在计算机上输入PIN并发送到安全密钥。

RP ID

FIDO2用"依赖方ID”（RP ID）取代了AppID。AppID是URL，而RP ID是纯域名。否则，RP ID的用途与CTAP1中的AppID相同。

CTAP协议变更

除了上述高级语义变更外，CTAP2的语法与U2F完全不同。它使用CBOR而不是具有固定或临时字段长度的二进制协议。

WebAuthn

作为FIDO2工作的一部分，WebAuthn API被完全替换。WebAuthn集成到W3C凭证管理规范中，通过navigator.credentials.create和navigator.credentials.get在JavaScript中调用。

其他认证器类型

WebAuthn不要求所有认证器都是安全密钥。任何能够正确格式化消息的设备都可以是认证器，因此笔记本电脑和台式机本身可以是认证器。这些设备称为"平台认证器”。

caBLE / 混合

虽然平台认证器非常适合在同一计算机上重新认证，但它们永远无法在不同的计算机上登录。caBLEv2被设计为使用最少的蓝牙：从手机发送到桌面的单个广告。这意味着其余通信通过互联网进行。

WebAuthn系列API

WebAuthn是一个Web API，但人们有时也在Web浏览器之外使用计算机和手机。因此虽然这些上下文不能使用WebAuthn本身，但出现了许多类似于WebAuthn的本机应用程序API。

Passkeys

通过混合和平台认证器，人们可以广泛访问WebAuthn认证器。但如果你重置或丢失手机/笔记本电脑，仍然会丢失所有凭证，就像重置或丢失安全密钥一样。

“更好"必须意味着"可恢复”。人们确实会丢失和重置手机，因此FIDO的一个迄今神圣的属性必须放宽，以便将其范围扩展到企业和专家之外：私钥必须备份。

2021年，随着iOS 15，Apple包含了将WebAuthn私钥保存到iCloud钥匙串的功能，Android Play Services获得了混合支持。2022年底，iOS 16添加了混合支持，在Android上，Google密码管理器添加了备份和同步私钥的支持。

人们现在可以普遍访问认证器，能够使用它们跨设备断言凭证，并有合理保证可以恢复这些凭证。为了将其捆绑在一起并赋予更友好的名称，Apple引入了更好的品牌：Passkeys。

未来

Passkeys的初始启动没有任何第三方密码管理器的规定。在iOS和macOS上，必须使用iCloud钥匙串，在Android上必须使用Google密码管理器。这是权宜之计，但从来不是预期的最终状态，随着iOS 17和Android 14，第三方密码管理器可以保存和提供Passkeys。

在2023年撰写本文时，大部分工作正在构建我们已勾勒的生态系统。Passkeys需要同步到更多地方，第三方密码管理器支持需要充实。

然而，有许多主题即将出现。随着FIDO2、CTAP和WebAuthn，我们要求网站更加信任密码管理器。虽然密码管理器长期存在，但使用远非普遍。但通过FIDO2的设计，用户必须使用密码管理器。

接下来，RP ID的概念是Passkeys的核心，但它是一个以Web为中心的概念。有些服务是仅移动端的，没有以域名形式的强大品牌。但Passkeys永远与RP ID关联，这迫使应用程序承诺可能出现在UI中的域名。

RP ID的目的是阻止凭证在网站之间共享，从而成为跟踪向量。但现在我们有了更精细的UI，也许可以向用户显示使用凭证的地方，并让RP ID成为公钥哈希或其他不绑定DNS的东西。

我们还需要考虑用户在生态系统之间过渡的问题。人们从Android切换到iOS，反之亦然，他们应该能够随身携带Passkeys。

有一大堆标有"试图取代密码"的尸体。Passkeys是迄今为止最好的尝试。希望五年后，它们不会成为警示故事。