为什么 WebAuthn API 在浏览器中将数据从身份验证器重组到 WebAuth 中的依赖方?

Why WebAuthn API at browser restructures data from authenticator to relying party in WebAuth?

在注册期间,身份验证器响应包括 public 密钥和证明数据,如 https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/WebAuthn_Client_Registration.html 中所示。将步骤4中的attestationObject改为步骤5中的AuthenticatorAttestationResponse,为什么authenticator不直接生成AuthenticatorAttestationResponse或者我们在步骤5中直接发送attestationObject

我的猜测是“因为关注点分离”。

FIDO2 标准由以下部分组成:

W3C WebAuthn:https://fidoalliance.org/fido2/fido2-web-authentication-webauthn/

FIDO 联盟 CTAP2:https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html

前者控制浏览器应用程序如何与较低级别交互,后者控制 browser/OS 如何与兼容的身份验证器交互。

为了支持这种分层,需要进行一些映射和转换,就像允许 WebAuthn 数据结构序列化为 JSON 以通过网络传输一样。

这是一个很好的问题,要回答这个问题,我们需要了解所有 FIDO 组件的作用。在 FIDO 协议中,有三个主要组成部分:

  • 服务器(又名 RP)- 启动身份验证会话,因此它的职责是生成良好的质询,并正确验证响应。

  • 客户端(又名浏览器)- 确保会话安全(又名 TLS)并提供物流以通过可用传输(NFC/USB/BLE)与设备通信。所有这些功能都打包到 Webauthn API.

  • Authenticator(Security Keys and Built-in Platform Authenticators) - 提供密钥管理和用户验证。

每个组件都有自己的限制:

  • 服务器不知道用户看到了什么,所以委托Client/Browser做好TLS的强制执行。
  • 浏览器不处理私钥,也不进​​行用户验证,因此它希望验证器足够安全。
  • Authenticator 希望浏览器没有被利用,attacker.xom 无法替代 RPID。

这就是为什么当服务器生成带有质询的 MakeCredential 请求并调用 Webauthn API 时,浏览器所做的是:

  • 检查 TLS 会话是否正常。没有 MITM,也不是 HTTP。
  • 他们检查请求 RPID(login.example.com 想要登录 代表 example.com) 是允许的并且不超出安全范围。
  • 然后它会调用所有可用设备以查看它们是否知道指定的凭据,如果知道,它将等待用户执行某些操作,例如点击按钮或滑动手指。
  • 当操作成功时,它会接受响应,并根据认证选项,none/direct,它会删除认证信息或保留它,然后检查是否没有隐私问题字段被发送到服务器(CTAP2. 1 个 CredBlobKey 扩展)
  • 浏览器然后对剩余的证明结构进行编码并附加会话信息(CollectedClientData)并将其发送到服务器
  • 服务器解码证明和 clientDataJSON,并验证响应不是来自 ATATACKER.XOM,而是来自预期来源 example.com。

总之:

  • 身份验证器正在签名
  • 浏览器正在确保您的 TLS 会话是安全的,并且没有俄罗斯黑客试图欺骗您。

有用的资源: