U2F协议解析

原文链接：http://blog.csdn.net/u014142287/article/details/52966845

服务器关联的密钥对
U2F设备产生的密钥对应该是服务器关联的，一对密钥对应一个服务器，而不是一个U2F设备对应一个服务器。在
注册的时候，服务器给U2F设备传入服务器相关信息，U2F设备产生一对密钥对，将此密钥对和服务器相关信息相
关联，给此密钥对分配一个key handle,将其和公钥传给服务器，服务器将注册的账户信息，公钥，key handle
全部关联在一起并保存。
当用户需要使用U2F验证操作时，服务器产生Challenge数据，使用U2F设备做签名，此时服务器将key Handle和
服务器信息通过浏览器传给U2F设备，U2F设备使用Key Handle，寻找对应的密钥对，如果密钥对存在，检验密钥
对应的服务器信息是否和传入的服务器信息匹配，如果不匹配，说明服务器是伪造或者不正确的。如果正确，
U2F设备等待用户按键确认，用户按键后，U2F设备对Challenge数据做签名，签名值返回给服务器，服务器验证

签名值，如果签名正确，说明此公钥对应的唯一私钥是正确的，表明用户拥有合法的U2F设备，如果签名不正确，

说明此用户正在伪造身份登录。可见，U2F验证身份是双向的，U2F验证服务器的真伪，服务器验证U2F的真假。

U2F设备“激活”和浏览器提醒
注册时，在产生密钥对前，U2F设备需要先被激活，例如，通过用户按U2F设备上的按钮表示用户允许继续，激活
U2F设备，U2F接着做后续操作。等待用户按键时，浏览器需要提醒用户按键确认。
验证时，在做签名时，U2F设备仍然需要先被激活。例如，通过用户按U2F设备上的按钮，表示用户允许继续，激
活U2F设备，U2F接着做签名操作。等待用户按键时，浏览器需要提醒用户按键确认。
U2F设备可以很廉价
为了保证安全性，私钥的保护很重要。U2F协议允许一个廉价的设备，同时保证此设备不会泄露私钥。Key 
handle可以不是U2F设备上一个私钥的索引，相反，Key Handle可以用来存储私钥和服务器相关信息，这些信息
可以被加密保存到一个Key Handle中。（例如使用aes加密私钥和服务器数据）
验证U2F的真伪
服务器需要一种方式，来确定用户使用的设备是服务器所授权和允许使用的，例如，某银行只使用了飞天诚信的
U盾，银行服务器就应该有足够的认证信息，来判断用户使用的U盾就是飞天诚信的，而不是别的厂商制造的。这
样对厂商版权有利，对银行安全性也有保障。一个厂商生产的一批U2F key中，他们应该都共享一对公共的根密
钥对，使用此根密钥对来颁发证书，服务器将验证此证书的合法性，当然，验证使用的是对应的公钥。FIDO草案
中，目前还未指明如何颁发跟密钥对的过程，这个过程还在修订中。
防止U2F设备被克隆
U2F协议中，使用了计数器。在用户注册完设备之后，服务器会初始化计数器(从0开始)，设备内部，对应的密钥
对也有一个计数器。用户每验证一次，设备内计数器加1，此计数会传给服务器，服务器比对服务器上的技术和
设备的计数器，如果服务器的计数器小于设备的计数器，数正常操作，服务器验证成功后，将计数器更新为设备
当前的计数器。如果服务器的计数器大于设备的计数器，说明U2F设备已被克隆。例如，用户注册完一次时候，
并登陆，服务器的计数器更新为1，U2F设备也为1，下次用户再次登录，服务器和设备都更新为2.如果U2F设备被
克隆，其他人使用该设备登录，服务计数器会随着恶意使用者的登录，计数器会递增。假设，恶意用户登录了两
次，服务器的计数则为4,。当真正的用户登录时，它的计数器加1，变为3，传给服务器。服务器发现他的计数比
服务器上的小，服务器就会给用户发出警告信息，警告用户设备已经被克隆。但这种计数有个滞后的弊端，如果
用户不再登录，或者很长时间都没有登录，用户是无法发现被克隆的。即便是很快发现了，估计也为时过晚。
防止钓鱼网站
假如，某钓鱼网站在你注册的时候，获取到了你的key Handle和公钥。当做认证的时候，浏览器获取的网址
(application identity)和你注册的时候网址是不一样的。这样将key Handle，app_id信息传入U2F设备中也不
会实施签名操作，因为他发现自身存储的key handle对应的app_id和传入的app_id不一样。