2017-12-01 18 views
0

私のU2Fトークンの1つで、U2F_REGISTER応答でNIST P-256 ECDSA署名検証が失敗します。U2Fレジスタの署名検証に失敗しました

私は、このプロトコルの説明に従って働いている:https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-raw-message-formats.html

U2F_REGISTER request: 
    b852c99d386769a3289d45708680efcc2350c0a7c152adb93c708b22a55c5d11: challenge 
    8adb4559abbea4a68754314e64aa6785901b6a236db5a14d040916799865e290: application 
U2F_REGISTER response: 
    05: reserved byte 
    user_public_key (NIST P-256): 
    04: key format (uncompressed) 
    db3ca8b3863f2fed19dada227aa8a51dba9bd0ecafcb5313225c04618c9329df: x 
    e540eb5c58d24704e899eaa72feef06722ad4669c5a3d5537ab88dc6a712f96d: y 
    keyhandle 
    40: length (64 bytes) 
    96e7d09341237e1c306a71ed9d59eeb16be621dbb34eb346ca999301ad0bee28f62876fced320734b4f139b89b8608bb4b4cef0f864064c2b3af1966167c4278 
    attestation certificate in X.509 DER format 
    30: sequence 
    82: length (130 bytes) ?? 
     01433081ea... 
    ECDSA signature in X.509 DER format 
    30: sequence 
    44: length (68 bytes) 
     02: integer 
     20: length (32 bytes) 
     6d090eefac83a67f9361adcd391395ab3636470e1eb479dc94e1194dc1f25259: r 
     02: integer 
     20: length (32 bytes) 
     660f7d23cd6b1c74e8499503fd21f6662a3270e916a57096037001baad5c7064: s 

私が00 (1 byte) + application (32 bytes) + challenge (32 bytes) + keyhandle (64 bytes this time) + user_public_key (1 + 32 + 32 bytes)のSHA-256ハッシュを計算します。

次に、私はecdsa.Verify(user_public_key, hash, r, s)と呼んでいます。

私が持っているU2Fトークンの1つとして、ecdsa.Verifyはtrue(正常)を返しますが、別のもの(上記のバイトを参照)に対してはfalseを返します。上記の例で私は間違って何をしていますか?

答えて

1

署名の検証に間違った公開鍵を使用していました。私は証明書の中で公開鍵を(応答の中で直接公開鍵ではなく)使用していたはずです。これにより、署名が正しく検証されました。

ここでは、署名検証を行うPythonのコード例を示します:https://github.com/concise/lightu2f.py/blob/20540f75ee5f86a4b2ad4bffe34074760978cbf9/lightu2f.py#L100。質問のデータ上で正しく動作します。

関連する問題