1.U2F 消息封包
U2F協定是基于請求-響應方案的，當請求者發送一個請求消息到U2F裝置中時，U2F會傳回一個響應消息給請求者。在現在這一版的U2F協定中，消息的封包是基于ISO7816-4:2005 擴充APDU格式。
請求消息封包的格式如下：
CLA INS P1 P2 LC1 LC2 LC3 <request-data>
響應消息的格式如下：
<request-data> SW1 SW2
2.注冊消息
2.1注冊消息 U2F_REGISTER
注冊消息是需要使用U2F認證的網站在第一使用時，需要注冊U2F裝置的一個操作，注冊請求消息有兩部分，如上圖所示：
challenge parameter[32 bytes]， challenge parameter是對用戶端資料(Client Data)進行SHA-256運算得到的哈希值。Client Data是一個由FIDO用戶端準備的JSON資料結構。
application parameter[32 bytes]，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.509 DER格式的證書
signature ECDSA簽名，簽名的資料為0x00,application parameter, challenge parameter,key handle,user public key
簽名依賴方可以使用attestation certificate中的公鑰進行驗證。依賴方也應該驗證attestation certificate是可信的CA頒發的。
一旦依賴方驗證了簽名，它就應該儲存public key和key handle，這樣就可以在之後的認證操作中使用了。
3.認證消息
3.1 認證請求消息 U2F_AUTHENTICATE
這個消息是U2F令牌進行認證的指令，FIDO用戶端首先連接配接依賴方獲得一個挑戰值（随機數），然後構造認證請求封包下發到U2F令牌中，認證請求封包有下面5部分：
control byte[P1]
值取0x07的時候表示check-only，U2F令牌隻是簡單的檢查傳入的key handle是不是這個令牌産生的，并且是不是給這個應用建立的。如果是，U2F令牌必須傳回一個認證響應。
值取0x03時，表示強制使用者出示并簽名，U2F令牌執行一個真實的簽名并響應一個認證應答消息（好别扭）
challenge parameter[32bytes] Client Data的SHA-256哈希資料
application parameter[32bytes] 是請求注冊的應用id的SHA-256結果
key handle length byte[1 byte] key handle的長度
key handle[變長]注冊時獲得的key handle
3.2 注冊指令的響應
U2F令牌如果發現key handle不是自己建立的，直接Bad Key Handle錯誤。
如果認證成功，傳回響應如下
U2F令牌在處理完認證請求消息後，傳回上面的消息。
user presence byte[1 byte]bit0設定為1，表示使用者确認過了（這一版的協定不明确的要求在進行認證請求是使用者确認的方式）。這個位元組剩下的bit，FIDO保留以後使用，現在都設定為0即可。
counter[4bytes]一個大段的計數器，U2F令牌每次認證都增加一次。
signature ECDSA簽名資料，對app para,user presence,counter,challenge para進行簽名。