リプレイ攻撃とNonce再利用の脆弱性

nonce（number used once）は、同じ平文メッセージを 2 回暗号化した場合でも、異なる暗号文が生成されることを保証します。これはセマンティックセキュリティに不可欠です。攻撃者が複数の暗号文を観測しても、それらが同じ平文を暗号化したものか、異なる平文を暗号化したものかについて情報を得られません。ストリーム暗号や CTR モードのブロック暗号では、nonce がキーストリームの生成の初期値となるため、nonce はセキュリティ上極めて重要です。

AES-GCM では、96 ビットの nonce を使用して CTR モード暗号化用のカウンターを初期化し、GHASH 認証計算にも利用します。各 AES ブロックのカウンター値は、nonce から始めてインクリメントすることで生成されます。2 回の暗号化で同じ nonce と鍵を使用すると、同じキーストリームが生成されるため、それぞれの暗号文の XOR は、それぞれの平文の XOR と等しくなります。

同じ（鍵、nonce）の組で暗号化された 2 つの GCM 暗号文では、それらの XOR が平文同士の XOR と等しくなります。攻撃者が一方の平文を知っている場合（選択平文の状況ではよくあります）、もう一方の平文を直ちに復元できます。既知の平文がない場合でも、暗号文同士の XOR から言語のパターンが明らかになり、crib-dragging 技法による攻撃が可能です。これは、暗号技術における最も壊滅的な誤用パターンの 1 つです。

GCM での nonce 再利用には、平文の復元以外にも壊滅的な影響があります。GHASH 認証鍵 H は暗号化鍵だけから導出されます。2 つのメッセージが同じ（鍵、nonce）の組を共有している場合、攻撃者は多項式方程式を解いて H を復元できます。H が分かると、任意の暗号文に対して有効な GCM 認証タグを偽造でき、メッセージの完全性が完全に破られます。

TLS 1.3 は、TLS 1.2 の実装で発生した nonce 再利用のリスクを踏まえて設計されています。TLS 1.3 は、12 バイトの write IV（ハンドシェイクから導出）と、8 バイトのシーケンス番号（12 バイトになるようゼロ拡張）を XOR して GCM nonce を生成します。シーケンス番号はすべてのレコードでインクリメントされるため、各レコードで一意の nonce が使用されます。これにより、ランダムな nonce 生成のリスクをなくし、シーケンス番号の仕組みによって nonce の一意性を保証できます。

リプレイ攻撃とは、有効なメッセージや認証トークンを取得し、後で再送信して不正な効果を生じさせる攻撃です。たとえば、銀行取引を再送信して二重に請求させる、有効な認証応答を再送信してユーザーになりすます、署名付きコマンドを再送信してデバイスを操作するといった例があります。攻撃者はメッセージの内容を理解したり変更したりする必要はありません。取得したデータをそのまま再送信するだけで攻撃が成立します。

認証済みメッセージにタイムスタンプを含めると、リプレイを防止できます。受信側は、申告されたタイムスタンプから短い時間枠（例：5 分以内）にあるメッセージだけを受け入れます。数時間前に再送信されたメッセージは時間枠の外にあるため、拒否されます。攻撃者がタイムスタンプを変更して新しいものに見せかけられないよう、タイムスタンプは認証済みでなければなりません（HMAC または AEAD の追加データに含めます）。

シーケンス番号は、古いメッセージのリプレイだけでなく、重複配信や順序が入れ替わった配信も検出できるため、タイムスタンプより強力なリプレイ防止策となります。受信側は、次に期待されるシーケンス番号と、最近受信した番号のスライディングウィンドウを管理します。各メッセージには許容範囲内のシーケンス番号が付いていなければならず、過去に使用された番号であってはなりません。TLS は、セッション内でのレコードのリプレイを防ぐためにシーケンス番号を使用します。

AES-GCM でランダムな nonce を使用する場合、推奨される生成方法は、暗号学的に安全な疑似乱数生成器（CSPRNG）から 96 ビットを取得することです。96 ビットのランダムな nonce では、誕生日の原理による衝突確率が 2^32 回の暗号化（約 40 億回）の後に 2^-32 に達します。大量のデータを扱うアプリケーションでは、カウンターベースの nonce に切り替えるか、より安全な上限を持つ別の AEAD（192 ビットの nonce を持つ XChaCha20-Poly1305 など）を使用してください。

決定論的なカウンターベースの nonce は誕生日の原理による問題を避けられますが、状態を慎重に管理する必要があります。カウンターはアプリケーションの再起動後も保持しなければなりません。再起動時にカウンターが 0 に戻ると、同じ鍵で直ちに nonce が再利用されます。カウンターは nonce の使用後ではなく、使用前にアトミックに更新する必要があります。分散システムでは、2 つのノードが同じカウンター値を使用しないよう調整が必要です。

XChaCha20-Poly1305 は、ChaCha20-Poly1305 の nonce を 96 ビットから 192 ビットに拡張します。192 ビットのランダムな nonce では、2^96 回の暗号化（天文学的な数のメッセージ）を行った後でも、誕生日の原理による衝突確率は無視できます。そのため、実用上の誕生日の原理による懸念なしにランダムな nonce を安全に生成できます。同じ理由で、libsodium の crypto_secretbox（XSalsa20-Poly1305）は 192 ビットの nonce を使用します。

nonce 再利用の要点：nonce は暗号文の一意性を保証します。GCM で nonce を再利用すると、平文同士の XOR が漏洩し、H の復元によって認証が破られます。TLS 1.3 はシーケンス番号と IV の XOR を使用して nonce の一意性を保証します。リプレイ攻撃では、有効なメッセージが変更されずに再送信されます。認証済みメッセージにタイムスタンプやシーケンス番号を含めるとリプレイを防止できます。GCM には 96 ビットのランダムな nonce（誕生日の原理による上限に注意）を使用するか、より大きなランダム nonce 空間を持つ XChaCha20 を使用してください。