AES-GCM はメッセージの機密性を保護し、不正な変更を検出できます。ただし、それ自体では、それ以外の点では有効なメッセージがすでに処理されたかどうかを受信者に知らせません。
混同しやすい要件が三つあります。暗号化で鍵と nonce の組を一意にすること、メッセージとその文脈を認証すること、プロトコル層でリプレイを処理することです。HKDF は鍵の導出に役立ちますが、三つすべてを自動的に満たすわけではありません。
nonce の再利用とリプレイは異なる事象
| 事象 | 起きること | 必要な保護 |
|---|---|---|
| 暗号化時の nonce 再利用 | 異なる平文が同じ GCM 鍵と nonce で暗号化される | 信頼できる鍵/nonce の割り当て戦略 |
| 改ざん | 暗号文または認証対象の文脈が変更される | 認証付き復号と、検証失敗時の拒否 |
| リプレイ | 以前は有効だった暗号化メッセージが再び配送される | 重複や古いメッセージを認識する状態とアプリケーション規則 |
| 順序の入れ替わり | 有効なメッセージが異なる順序で到着する | プロトコルで定義された順序規則と範囲を限定した順序外処理 |
再送された暗号文にも有効な認証タグが残っている場合があります。何も変更されていないからです。したがって、重複はすべて自動的に AES-GCM 認証に失敗する、と言うのは誤りです。RFC 5116 は AEAD インターフェースとリプレイ防止サービスを明確に区別しています。
鍵と nonce の組を繰り返してはいけない理由
GCM の nonce は秘密である必要はありませんが、ある鍵の下で方式の一意性要件を満たす必要があります。96 ビット、つまり 12 バイトの nonce が一般的ですが、その長さを選ぶだけで正しい生成が保証されるわけではありません。
異なる平文に同じ鍵と nonce を再利用すると、暗号化の鍵ストリームが再利用され、平文同士の関係が露出します。真正性を損ない、偽造を可能にすることもあります。影響は深刻ですが、過去のすべての鍵やアカウント内の全メッセージが自動的に明らかになると表現すべきではありません。影響範囲は再利用された鍵とプロトコルに依存します。
NIST SP 800-38D は GCM とその要件を定義しています。実装は「この件数までは安全」という単純な目安ではなく、適用される呼び出し回数の制限と nonce 生成規則に従わなければなりません。
HKDF が担う役割
RFC 5869 で規定された HKDF は、抽出と展開の段階を使い、入力された秘密材料から鍵材料を導出します。プロトコルは文脈ラベルや異なる入力を使い、用途ごとの鍵を分離できます。
HKDF は決定論的です。クラッシュやロールバックを経たクライアントが同じ状態と入力を繰り返すと、同じ出力を再び導出し得ます。そのため、設計に HKDF を追加しても nonce の再利用が不可能になるわけではありません。
メッセージごとの鍵は、一つの鍵で保護される内容の量を減らせますが、安全な状態の更新、鍵の分離、削除は引き続き重要です。本当に異なる鍵の下で同じ nonce 値を使うことは、鍵/nonce の組を繰り返すのと同じ失敗ではありません。プロトコルは鍵が本当に異なることを確立する必要があります。
リプレイ防御はプロトコルの役割
受信者はメッセージ識別子、シーケンス位置、セッションエポック、使用済みのラチェット鍵を追跡できます。攻撃者が古いメッセージを新しいものとして付け替えられないよう、関連フィールドは認証する必要があります。
そのうえで、アプリケーションは重複が何を意味するかを決める必要があります。チャットの吹き出しが二重に表示されるのは不便ですが、同じ操作を二度実行することはもっと重大になり得ます。ネットワーク再試行は普通に起きるため、暗号学的な検査に加えて冪等な処理が必要になることがよくあります。
プロトコルが規定していない限り、すべての有効なメッセージが厳密な順序で届くことを要求しないでください。モバイルクライアントは日常的に再接続、再試行、遅延したメッセージの受信を行います。安全な処理は正当な遅着メッセージと、すでに処理済みまたは文脈が誤ったメッセージを区別します。
保護を主張する前に試験すべきこと
- nonce を割り当ててから送信を記録するまでの間に再起動する。その割り当ては繰り返され得るか。
- 古い状態のスナップショットを復元する。鍵、カウンター、リプレイ記録が巻き戻る可能性はあるか。
- 二つのワーカーや端末から並行して送信する。鍵/nonce の領域は分離されているか。
- 同じ有効なメッセージを二度配送する。アプリケーションの操作は一度だけ実行されるか。
- セッション識別子やヘッダーを変更する。文脈は暗号学的に結び付けられているか。
- 有効なメッセージを順序外で配送する。古い状態を受け入れずに、対応範囲内の遅延を処理できるか。
認証付き復号 API は、検証に成功した場合にのみ平文をアプリケーションへ返すべきです。これはインターフェースの要件であり、どの実装も内部で一時的な平文バッファーを計算しないという主張ではありません。
Livara の主張を正確に読む
Livara のセキュリティ文書は AES-256-GCM、メッセージごとのチェーン、LVR1/LGS1 の文脈に言及しています。これらの暗号プリミティブだけで、正しいクラッシュ復旧、nonce 割り当て、リプレイ拒否が証明されるわけではありません。そうした主張にはバージョンを明記したプロトコルの詳細と試験の証拠が必要です。
堅牢な設計は役割を明示的に割り当てます。鍵導出は意図した鍵を作り、AEAD は内容と文脈を認証し、状態を持つプロトコルロジックは有効なメッセージを今受け入れてよいか判断します。
