security - AES-GCM を使用したプロトコルの nonce / IV のソースと重要性

Question

AES で暗号化されたパケット (つまり、ストリームではない) を使用するプロトコルを作成しています。統合認証を提供し、NSA のスイート B の一部であるため、GCM (CTR に基づく) を使用することにしました。AES キーは ECDH を使用してネゴシエートされ、公開キーは web- ECDSAのようなものを使用した信頼の。GCM には 128 ビットの nonce / 初期化ベクトルが必要だと思います。なぜなら、AES に 256 ビットの鍵を使用しているにもかかわらず、常に 128 ビットのブロック暗号だからです (右?) 後で 96 ビットの IV を使用しますBCコードを読み取ります。

私は間違いなく独自のアルゴリズムを実装していません (プロトコルのみ -- 私の暗号プロバイダーは BouncyCastle です)。同じ DH キーを持つ 2 人の間で使用される AES キーは一定のままであるため、同じノンスを複数のパケットに使用すべきではないことがわかっています。

単純に 96 ビットの疑似乱数をパケットの先頭に追加し、受信者にこれをノンスとして使用させることはできますか? これはピア ツー ピア ソフトウェアであり、パケットはいつでも送信できます (例: インスタント メッセージ、ファイル転送要求など)。乱数ソース。ノンスは秘密にする必要はまったくありませんよね？それとも、必然的に「暗号的に安全な」PNRG と同じくらいランダムですか? ウィキペディアは、それはランダムであるべきだと言っています。さもなければ、選択された平文攻撃の影響を受けやすいと言っていますが、両方の主張の横に「引用が必要です」とあり、それがブロック暗号に当てはまるかどうかはわかりません. 特定のAESキーで送信されたパケットの数をカウントするカウンター（128ビットブロックの数のカウンターとは別）を実際に使用できますか？1から？明らかに、これによりノンスが予測可能になります。GCM が暗号化だけでなく認証も行うことを考えると、これはその認証機能を危うくするでしょうか?

Answer 1

GCMは、認証を伴うブロック暗号カウンター モードです。カウンター モードは効果的にブロック暗号をストリーム暗号に変換するため、ストリーム暗号のルールの多くが引き続き適用されます。同じ Key+IV は常に同じ PRNG ストリームを生成することに注意することが重要です。この PRNG ストリームを再利用すると、攻撃者が単純な XOR でプレーンテキストを取得する可能性があります。プロトコルでは、モードのカウンターがラップしない限り (int オーバーフロー)、同じキー + IV をセッションの存続期間中使用できます。たとえば、プロトコルに 2 つの当事者がいて、事前に共有された秘密鍵を持っている場合、各セッションの IV として使用される新しい暗号化ナンスをネゴシエートできます (ナンスは一度だけ使用することを意味することに注意してください)。

AES をブロック暗号として使用する場合は、CMAC モードまたはおそらく OMAC1 バリアントを検討する必要があります。CMAC モードでは、静止 CBC のすべてのルールが適用されます。この場合、各パケットがランダムな一意の IV を使用していることを確認する必要があります。ただし、IV を再利用しても、PRNG ストリームを再利用するほど悲惨な結果にはならないことに注意することが重要です。

Answer 2

独自のセキュリティ プロトコルを作成しないことをお勧めします。資格のある暗号学者でさえも間違える可能性があることを考慮する必要があることがいくつかあります。TLS プロトコル (RFC5246) とデータグラム TLS プロトコル (RFC 4347) を参照してください。ライブラリを選択して使用します。

GCM モードの IV に関するご質問について。DTLS と TLS がどのようにそれを行うかを説明します。それらは、明示的なナンス、つまり、すべてのパケットに含まれるメッセージ シーケンス番号 (64 ビット) を使用し、送信されない秘密部分 (上位 32 ビット) を使用し、最初の鍵交換から派生します (RFC 5288 を確認してください)。詳しくは）。