web-dev-qa-db-ja.com

U2Fの認証メカニズムは、キーマテリアルの出所をどのように保証しますか?

私は、ユビコのU2F標準に関するドキュメントを理解しようとしていて、 PIV証明 の部分に夢中になっています。

セキュリティの主張は、正式に署名された 登録時にデバイスから送信された認証証明書 によって、証明書利用者(〜=サーバー)が 2Fによって生成されたキー情報が登録 はデバイスの外部に保存またはコピーされていません。

これがどのように可能になるのか混乱しています。証明書は、公開鍵と秘密鍵の関連をどのように表していますか?オンザフライで生成されたすべてのキーペアに対して、証明証明書に署名するにはどうすればよいですか?

アテステーション証明書の生成方法を示す唯一のコードは、RustのこのSoftU2F実装で使用される(静的な自己署名)証明書です: https://github.com/danstiner/ Rust-u2f/blob/master/u2f-core/src/self_signed_attestation.rs

ここに欠けているものがあるはずです。おそらく、ユビキーが具体的に証明証明書に署名する方法にあります。おそらく、すべての登録のキー情報が ある意味で であることを利用しています。

たとえば、YubikeyのU2Fデバイスによって生成され、 this CA cert によって署名された認証証明書が、サーバーがU2F登録で使用されたキー情報の出所を検証できるようにする方法を誰かが理解できるようにできますか、またはデバイスモデル情報の信頼性?

別の言い方をすると:U2Fデバイスを登録し、その証明書、キーハンドル、および公開キー( protocol詳細 )、そして私は証明証明書のルートCAを信頼しています...これをどのように使用して鍵情報の出所を確認できますか?

3
Dan Lenski

U2Fの仕様 概要 は次のように述べています。

意図は、各ベンダーが使用するすべての「Attestation」キーペアの公開キーがパブリックドメインで利用可能になることです。これは、ルート公開キーにチェーンされた証明書によって、または文字通りリストとして実装できます。 FIDO内で、認定ベンダーが認証公開鍵を公開する方法の詳細を決定します。

実際には、ほとんどの主要ベンダーは、証明書の検証に使用できるルート証明書をどこかに提供しています。これは他の [〜#〜] pki [〜#〜] と同じように機能します。


各認証システムには、認証署名の作成に使用される認証秘密鍵と、認証システムが使用される各登録の一部として送信される関連する認証証明書が含まれています。認証秘密鍵は、サービスが認証鍵に基づいて個人を識別できないようにするために、少なくとも100,000の認証システムによって共有されます。秘密鍵は認証者から抽出することが不可能であり、したがってベンダーにしか知られていないため、その目的は、どのベンダーがキーを製造したかを証明する方法を提供することです。

登録応答メッセージ には、証明書と署名が含まれています。証明書は、通常のDERエンコードされたX.509証明書であり、署名は、残りの応答メッセージと関連するリクエストの一部に対する証明書秘密鍵で作成されます。

Registration Response Message from FIDO U2F V1.2 Spec

証明書を適切に検証するには、まず証明書の公開鍵を証明書から抽出し、応答の署名の検証に使用します。この手順がなければ、攻撃者は既知の承認済み認証システムから認証証明書を取得し、独自のデバイスの認証証明書の代わりにそれを使用する可能性があります。

応答署名が検証された後(証明証明書を登録キーペアに関連付け)、証明証明書自体を検証する必要があります。例として、これはopenssl x509 CLIでデコードされた私のキーの1つからの証明書です。

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 618376000 (0x24dbab40)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = Yubico U2F Root CA Serial 457200631
        Validity
            Not Before: Aug  1 00:00:00 2014 GMT
            Not After : Sep  4 00:00:00 2050 GMT
        Subject: CN = Yubico U2F EE Serial 13503277888
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:02:b0:94:be:34:7d:47:79:41:c4:77:8e:be:c5:
                    ca:4d:ed:2a:47:9f:aa:1e:6f:ec:39:af:eb:de:0c:
                    20:70:cb:5b:d4:bd:69:c9:6a:78:e3:bf:87:51:fe:
                    b5:79:1b:8d:fa:ca:c2:94:01:75:1c:b1:57:b9:7c:
                    09:e4:39:1a:36
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            1.3.6.1.4.1.41482.1.1: 

    Signature Algorithm: sha256WithRSAEncryption
         a3:63:ae:0e:98:3a:f3:0b:ba:f1:2c:8b:2d:f3:5a:59:bf:1c:
         bb:4a:1b:0f:cb:68:c4:84:55:84:90:f6:87:34:58:65:b8:db:
         02:69:c3:46:e5:53:88:4c:2c:56:07:af:0e:a2:7b:90:ac:8c:
         f1:ef:43:1f:72:ac:18:9d:b2:1c:82:49:14:bf:17:88:a5:51:
         1a:33:d0:7b:4c:8e:34:64:7c:e9:f6:1e:15:16:a9:a9:b3:6e:
         90:0a:40:20:61:f6:9a:a4:6e:12:c5:32:b9:93:f9:42:3e:fa:
         aa:4c:f9:a3:b6:54:b4:dd:de:f2:92:4a:54:8f:d5:99:95:51:
         0d:d4:f7:f4:d9:a4:d5:21:93:87:3c:71:c9:b8:7e:86:85:3e:
         9e:2d:a7:5e:8f:0c:6d:28:30:53:74:d4:ef:dd:5e:14:96:f8:
         c3:39:06:10:7b:d6:8b:d6:35:0d:aa:d2:c3:78:11:ec:a3:ca:
         43:bc:93:0b:73:40:97:de:f6:9d:68:8d:94:55:0c:4c:fb:18:
         a9:e2:4b:86:a2:e5:d8:8f:49:98:99:a0:9b:ce:5b:81:0c:53:
         6c:af:39:0d:c8:bd:de:96:0d:f3:30:ca:ca:bc:05:21:a1:83:
         23:95:7f:fe:bc:a5:9c:a9:0b:20:b1:0d:09:b5:23:1c:58:c2:
         7e:ba:67:83

発行証明書は、[発行者]フィールドから判別できます。この場合は、ユビコのU2FルートCAです。アプリケーションがそのCAを信頼していると想定すると、そのルート証明書から公開鍵が取得され(ルート証明書自体は信頼されたルートのリストから取得されます)、それを使用して、証明証明書の署名を検証します。検証が成功した場合、登録キーペアは証明証明書に暗号化され、証明証明書は信頼されたルートに暗号化されます。

ベンダーがオーセンティケーターを適切に製造し、認証の秘密鍵とキーラッピングシークレット(またはデザインによってはキーストレージ)を抽出できないと信頼できる場合は、登録されたキーが、ルート証明書を取得したベンダー。

1
AndrolGenhald