Universal 2nd Factor (U2F) 概述（8）-验证U2F设备的真伪性

U2F协议是开放的，然而为了高安全性，一个U2F设备必须是建立一定的标准。比如，Key Handle中包含了私钥和厂商的特定的规则，必须先经过认证再执行，比如FIDO认证。还有就是选择的安全芯片必须足够保证安全。

出于这些考虑，依赖方需要标识这些设备的的类型，并且可以通过认证信息数据库信息验证的方式检查设备的认证属性是否可以满足要求。比如，金融服务网站可能只会会接受硬件保护的U2F设备进行验证，而其他的网站可能会允许软件实现的U2F认证协议。

每一个U2F设备都有一对共享的“Attestation”秘钥，同一个厂商同一批生产的U2F设备都共享这对秘钥（这也是防止U2F设备有唯一标识性）。在设备注册过程中，使用这个“Attestation”私钥来加密用户的公钥再输出。

这样做的目的是为了每个供应商使用的所有“Attestation”密钥对的公钥将在公共域中使用。可以通过将证书链接到根公共密匙或作为列表来实现。我们将在FIDO内工作，以决定认证供应商如何发布他们的认证公钥。

有了这样的基础设施后，比如像银行这样的依赖方，可能只会接受来自某些供应商的U2F设备，这些供应商拥有适当的发布证书。为了执行此策略，它可以验证用户提供的U2F设备的公钥来自它信任的供应商。

在实践中，对于高质量的U2F设备，我们期望Attestation Key被烧录在安全芯片中，由供应商提供给每批芯片的安全元件制造商，大约有100,000个设备一批。

需要注意的是，Attestation Key只保证了谁是U2F设备的供应商。至于U2F设备是否确实安全，该保证来自于第三方检查供应商的实现的认证。综上所述，Attestation 是认证的有力标识。

在这种背景下,值得注意的是,将秘钥存储在U2F设备中而不是放在KeyHandle中,这样更最安全,因为它不容易受到供应商设计中漏洞影响。不过一个好的加密的KeyHandle设计将远远超过安全的标准，同时也更便宜。

此时，用于在KeyHandle中嵌入私钥的加密技术不属于指定协议的一部分。然而，在U2F工作组材料的示例客户端javacard applet中指定了强大的最佳实践指导方针。在FIDO中包括作为U2F认证的一部分的特定实现的审查可能是合适的。

请注意，供应商可以制造一个没有认证的U2F兼容设备，并且其认证数据库没有在“认证数据库”中发布。一个依赖方仍然可以选择接受这样的设备，但必须清楚的知道此设备类型不在认证数据库中。

使用计数器作为检测U2F克隆设备的标准

U2F协议中，使用了计数器。在用户注册完设备后，服务器会初始化计数器（从0开始），设备内部，对应的密钥对也有一个计数器。用户每验证一次，设备内计数器加一，此计数会传给服务器，服务器比对服务器上的计数器和设备的计数器，如果服务器的计数器小于等于设备的计数器，属于正常操作，服务器验证成功后，将计数器更新为设备当前的计数器。如果服务器的计数器大于设备的计数器，说明U2F设备已被克隆。

例如，用户注册完一次后，并登陆，服务器的计数器更新为1，U2F设备也为1.下次用户再次登陆，服务器和设备都跟新为2. 如果U2F设备被克隆，其它人使用该设备登陆，服务器计数器会随着恶意使用者的登陆，计数器会递增。假设，恶意用户登陆了两次，服务器的技术则为4。当真正的用户登陆时，它的计数器加1，变为3，传给服务器。服务器发现它的计数比服务器上的小，服务器就会给用户发出警告信息，警告用户设备已被克隆。但这种技术有个滞后的弊端，如果用户不再登陆，或者很长时间都没有登陆，用户是无法发现被克隆的。即便是很快发现了，估计也为时已晚，黑客不可能等你发现了再去窃取你的隐私。