U2F的认证机制如何保证关键材料的来源？
我正在尝试理解Yubico关于U2F标准的文档，并被挂在PIV认证上。
安全声明似乎是，授权签名的设备注册后发出的认证证书将允许依赖方(~=服务器)验证U2F注册生成的密钥材料没有存储或复制到设备之外。
我不知道这怎么可能。认证证书是如何代表公钥和私钥材料之间的关联的？如何对在飞行中生成的每个键盘签署认证证书？
我能找到的唯一代码显示了认证证书是如何生成的，就是这个SoftU2F实现在Rust：https://github.com/danstiner/rust-u2f/blob/master/u2f-core/src/self_署名_attestation.rs中使用的(静态的、自签名的)证书。
这里一定有我遗漏的东西，可能是关于Yubikey如何具体地签署认证证书的，也许是利用了每个注册在某种程度上的密钥材料。
有人能帮助我理解吗?例如，由Yubikey的U2F设备产生并由这个CA证书签名的认证证书如何允许服务器验证U2F注册中使用的密钥材料的来源，或者设备模型信息的真实性？
换句话说:如果我注册一个U2F设备并接收它的认证证书、密钥句柄和公钥(如协议细节中所描述的)，我相信认证证书的根CA .我怎样才能用这个来验证键控材料的来源？
回答 1
Security用户
发布于 2020-01-25 03:47:37
U2F规范概述说：
其意图是，每个供应商使用的所有“认证”密钥对的公钥将在公共域中可用--这可以通过链接到根公钥的证书来实现，也可以从字面上作为列表来实现。我们将在FIDO内部决定认证供应商如何发布他们的认证公钥的细节。
在实践中，大多数关键供应商提供一个根证书，您可以使用它来验证认证证书。这和任何其他PKI一样工作。
每个身份验证器都包含一个用于创建认证签名的认证私钥，以及作为每个认证者注册的一部分发送的相关认证证书。认证私钥将由至少100,000个认证者共享，以防止服务基于认证密钥识别个人。其目的是提供一种方法来证明是哪个供应商制造了密钥，因为私钥不可能从认证者那里提取，因此只有供应商才知道。
注册响应消息包括一个认证证书和一个签名。认证证书是一个普通的DER编码的X.509证书，该签名是在响应消息的其余部分和相关请求的一部分上使用认证私钥创建的。
为了正确地验证认证，首先从证书中提取认证公钥并用于验证响应的签名。如果不执行此步骤，攻击者只需从已知的被接受身份验证者那里获取认证证书，并使用它来代替他们自己设备的认证证书。
在验证响应签名之后(将认证证书绑定到注册密钥区)，必须对认证证书本身进行验证。例如，下面是来自我的一个密钥的证书，该证书由openssl x509 CLI解码：
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，它将从该根证书获取公钥(根证书本身将来自受信任的根列表)，并使用它验证认证证书上的签名。如果验证成功，注册密钥将以加密方式绑定到认证证书，而认证证书将以加密方式绑定到受信任的根。
如果您相信供应商已经正确地制造了他们的验证器，从而无法提取认证私钥和密钥包装秘密(或密钥存储取决于设计)，那么您可以确信注册的密钥来自由您获得根证书的供应商创建的身份验证器。
https://security.stackexchange.com/questions/224692
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号