原文链接：http://blog.sina.com.cn/s/blog_625033800102vzsk.html
1.U2F 消息封包
U2F协议是基于请求-响应方案的，当请求者发送一个请求消息到U2F设备中时，U2F会返回一个响应消息给请求者。在现在这一版的U2F协议中，消息的封包是基于ISO7816-4:2005扩展APDU格式。
请求消息封包的格式如下：
CLA INS P1 P2 LC1 LC2 LC3
响应消息的格式如下：
SW1 SW2
2.注册消息
2.1注册消息 U2F_REGISTER
注册消息是需要使用U2F认证的网站在第一使用时，需要注册U2F设备的一个操作，注册请求消息有两部分，如上图所示：
challenge parameter[32 bytes]，challenge parameter是对客户端数据(Client Data)进行SHA-256运算得到的哈希值。ClientData是一个由FIDO客户端准备的JSON数据结构。
application parameter[32bytes]，application parameter是请求注册的应用id的SHA-256结果。
2.2 注册消息的响应
如果注册成功，U2F令牌会创建一个新的密钥对。需要注意的是U2F令牌在返回注册成功的响应消息之前，需要用户确认（一般是带触点按键的，按下按键或者触点，没有按键的一般是拔插一下设备），否则令牌应该返回错误码test-of-user-presence-required。
如果注册成功，返回的响应消息格式如上图所示。
reserved byte[1字节]保留字节永远是0x05
user public key[65bytes]椭圆曲线公钥
key handle length byte[1byte] key handle的长度
key handle [长度根据上面handle lenght确定]U2F令牌用来区分产生的密钥对的。
attestation certificate[变长] X.509DER格式的证书
signatureECDSA签名，签名的数据为0x00,application parameter, challenge parameter,keyhandle,user public key
签名依赖方可以使用attestationcertificate中的公钥进行验证。依赖方也应该验证attestationcertificate是可信的CA颁发的。
一旦依赖方验证了签名，它就应该保存public key和keyhandle，这样就可以在之后的认证操作中使用了。
3.认证消息
3.1 认证请求消息U2F_AUTHENTICATE
这个消息是U2F令牌进行认证的指令，FIDO客户端首先连接依赖方获得一个挑战值（随机数），然后构造认证请求报文下发到U2F令牌中，认证请求报文有下面5部分：
controlbyte[P1]
值取0x07的时候表示check-only，U2F令牌只是简单的检查传入的keyhandle是不是这个令牌产生的，并且是不是给这个应用创建的。如果是，U2F令牌必须返回一个认证响应。
值取0x03时，表示强制用户出示并签名，U2F令牌执行一个真实的签名并响应一个认证应答消息（好别扭）
challenge parameter[32bytes] ClientData的SHA-256哈希数据
application parameter[32bytes] 是请求注册的应用id的SHA-256结果
key handle length byte[1 byte] keyhandle的长度
key handle[变长]注册时获得的keyhandle
3.2注册指令的响应
U2F令牌如果发现key handle不是自己创建的，直接Bad KeyHandle错误。
如果认证成功，返回响应如下
U2F令牌在处理完认证请求消息后，返回上面的消息。
user presence byte[1byte]bit0设置为1，表示用户确认过了（这一版的协议不明确的要求在进行认证请求是用户确认的方式）。这个字节剩下的bit，FIDO保留以后使用，现在都设置为0即可。
counter[4bytes]一个大段的计数器，U2F令牌每次认证都增加一次。
signature ECDSA签名数据，对app para,userpresence,counter,challenge para进行签名。