U2F的证明机制如何保证关键材料的出处？

信息安全 优比键 u2f 菲多
2021-09-11 01:29:34

我正在尝试了解 Yubico 的 U2F 标准文档，并开始关注PIV 认证。

安全声明似乎是设备在注册时发送的权威签名证明证书将允许依赖方（~= 服务器）验证U2F 注册产生的密钥材料没有存储或复制到设备之外.

我对这怎么可能感到困惑。认证证书如何代表公钥和私钥材料之间的关联？如何为动态生成的每个密钥对签署证明证书？

我能找到的唯一显示证明证书是如何生成的代码是这个SoftU2F实现在 Rust 中使用的（静态、自签名）证书：https : //github.com/danstiner/rust-u2f/blob/master/u2f -core/src/self_signed_attestation.rs

这里一定有一些我遗漏的东西，可能是 Yubikey 如何专门签署证明证书，也许是利用了每个注册的密钥材料都以某种方式存在的事实。

谁能帮我理解，例如，由 Yubikey 的 U2F 设备生成并由该 CA 证书签名的证明证书将如何允许服务器验证 U2F 注册中使用的密钥材料的出处，或设备型号信息的真实性?

换一种说法：如果我注册了一个 U2F 设备并收到了它的证明证书、密钥句柄和公钥（如协议详细信息中所述），并且我信任证明证书的根 CA……我该如何使用它来验证密钥材料的出处？

1个回答

U2F 规范概述说：

目的是每个供应商使用的所有“证明”密钥对的公钥都将在公共域中可用 - 这可以通过链接到根公钥的证书或字面上作为列表来实现。我们将与 FIDO 合作，决定认证供应商如何发布他们的证明公钥的细节。

实际上，大多数密钥供应商都会在某个地方提供根证书，您可以使用它来验证证明证书。这就像任何其他PKI 一样工作。

每个身份验证器都包含一个用于创建证明签名的证明私钥，以及作为身份验证器用于的每个注册的一部分发送的相关证明证书。证明私钥将由至少 100,000 个身份验证者共享，以防止服务根据证明密钥识别个人。目的是提供一种方法来证明哪个供应商制造了密钥，因为私钥应该不可能从验证器中提取，因此只有供应商知道。

注册响应消息包括证明证书和签名。证明证书是一个普通的 DER 编码的 X.509 证书，并且在响应消息的其余部分和相关请求的一部分上使用证明私钥创建签名。

来自 FIDO U2F V1.2 规范的注册响应消息

为了正确验证证明，首先从证书中提取证明公钥并用于验证响应的签名。如果没有这一步，攻击者可以简单地从已知被接受的身份验证器中获取认证证书，并使用它来代替他们自己设备的认证证书。

验证响应签名后（将证明证书与注册密钥对绑定），必须验证证明证书本身。例如，这是来自我的一个密钥的证书，使用openssl x509CLI 解码：

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 618376000 (0x24dbab40)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = Yubico U2F Root CA Serial 457200631
        Validity
            Not Before: Aug  1 00:00:00 2014 GMT
            Not After : Sep  4 00:00:00 2050 GMT
        Subject: CN = Yubico U2F EE Serial 13503277888
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:02:b0:94:be:34:7d:47:79:41:c4:77:8e:be:c5:
                    ca:4d:ed:2a:47:9f:aa:1e:6f:ec:39:af:eb:de:0c:
                    20:70:cb:5b:d4:bd:69:c9:6a:78:e3:bf:87:51:fe:
                    b5:79:1b:8d:fa:ca:c2:94:01:75:1c:b1:57:b9:7c:
                    09:e4:39:1a:36
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            1.3.6.1.4.1.41482.1.1: 

    Signature Algorithm: sha256WithRSAEncryption
         a3:63:ae:0e:98:3a:f3:0b:ba:f1:2c:8b:2d:f3:5a:59:bf:1c:
         bb:4a:1b:0f:cb:68:c4:84:55:84:90:f6:87:34:58:65:b8:db:
         02:69:c3:46:e5:53:88:4c:2c:56:07:af:0e:a2:7b:90:ac:8c:
         f1:ef:43:1f:72:ac:18:9d:b2:1c:82:49:14:bf:17:88:a5:51:
         1a:33:d0:7b:4c:8e:34:64:7c:e9:f6:1e:15:16:a9:a9:b3:6e:
         90:0a:40:20:61:f6:9a:a4:6e:12:c5:32:b9:93:f9:42:3e:fa:
         aa:4c:f9:a3:b6:54:b4:dd:de:f2:92:4a:54:8f:d5:99:95:51:
         0d:d4:f7:f4:d9:a4:d5:21:93:87:3c:71:c9:b8:7e:86:85:3e:
         9e:2d:a7:5e:8f:0c:6d:28:30:53:74:d4:ef:dd:5e:14:96:f8:
         c3:39:06:10:7b:d6:8b:d6:35:0d:aa:d2:c3:78:11:ec:a3:ca:
         43:bc:93:0b:73:40:97:de:f6:9d:68:8d:94:55:0c:4c:fb:18:
         a9:e2:4b:86:a2:e5:d8:8f:49:98:99:a0:9b:ce:5b:81:0c:53:
         6c:af:39:0d:c8:bd:de:96:0d:f3:30:ca:ca:bc:05:21:a1:83:
         23:95:7f:fe:bc:a5:9c:a9:0b:20:b1:0d:09:b5:23:1c:58:c2:
         7e:ba:67:83

颁发证书可以从 Issuer 字段确定，在这种情况下，它是 Yubico 的 U2F 根 CA。假设应用程序信任该 CA，它将从该根证书中获取公钥（根证书本身将来自受信任的根列表）并使用它来验证证明证书上的签名。如果验证成功，注册密钥对将加密绑定到证明证书，并且证明证书将加密绑定到可信根。

如果您相信供应商已正确制造了他们的身份验证器，因此无法提取证明私钥和密钥包装机密（或取决于设计的密钥存储），那么您可以确信注册的密钥来自由您从中获得根证书的供应商。

其它你可能感兴趣的问题
上一篇基于会话/cookie 的身份验证是有状态的还是无状态的？ 下一篇argon2i 是否“更适合密码散列和密钥派生”？