暗号学の世界において、AES-GCM（Galois/Counter Mode）は「黄金律」のように扱われてきました。高速な並列処理が可能で、データの秘匿性（Encryption）と完全性（Authentication）を同時に担保するAEAD（Authenticated Encryption with Associated Data）の代表格だからです。
しかし、この洗練されたアルゴリズムには、設計者が「絶対に踏んではならない」と警告する、あまりにも脆い急所が存在します。それがNonce（Number used once）の再利用です。
巷の教科書では「Nonceを使い回すとセキュリティが低下する」と一言で片付けられがちですが、我々現場の人間が直面するのは、そんな生易しい事態ではありません。それは、暗号スイートの完全な崩壊、すなわち「認証キー（GHASH Key）の完全な漏洩」を意味します。
今回は、この「Forbidden Attack（禁じられた攻撃）」のメカニズムを低レイヤの視点から解剖し、現代のアーキテクチャでどのように防衛線を張るべきか、その本質を共有します。
—
1. なぜNonceの再利用が「致命的」なのか：GHASHの数学的構造
AES-GCMが認証タグを生成する際、内部ではガロア界（$GF(2^{128})$）上の多項式評価に基づいた「GHASH」という関数が動いています。
GCMモードにおける認証タグ $T$ は、大まかに以下の式で表されます（単純化しています）。
$T = \text{GHASH}(H, A, C) \oplus E(K, J_0)$
ここで $H$ はハッシュキー（AESキー $K$ から派生）、$C$ は暗号文、$J_0$ はNonceから生成される初期カウンタブロックです。
もし、同じ鍵 $K$ と同じ Nonce を使って2つの異なるメッセージを暗号化した場合、何が起きるでしょうか。
1. 暗号文のXORによる情報漏洩: AES-CTRモードと同様、暗号文同士をXORすることで平文の差分（XOR和）が露出します。
2. ハッシュキー $H$ の特定: これが最も致命的です。2つの認証タグの差分をとることで、$H$ を変数とする多項式方程式が得られます。攻撃者はこの方程式の根を解くことで、認証キー $H$ そのものを算出できてしまうのです。
ひとたび $H$ が攻撃者の手に渡れば、そのNonce以降の通信において、攻撃者は任意の暗号文を捏造し、正しい認証タグを付与することが可能になります。これはもはや「暗号化」としての機能を喪失したことを意味します。
—
2. 実装上の盲点：96-bit Nonceという「罠」
AES-GCMの仕様（NIST SP 800-38D）では、Nonceの長さは任意とされていますが、96-bit（12バイト）が推奨されています。これには明確な理由があります。
Nonceが96-bitの場合、GCMはそれに 00000001 という32-bitのカウンターを直接連結して128-bitの初期ブロック $J_0$ を作ります。しかし、96-bit以外の長さ（例えば128-bitや64-bit）を選択すると、内部でGHASHによるハッシュ計算が走り、そこから $J_0$ が導出されます。
この「ハッシュ計算」が曲者で、計算コストが増大するだけでなく、ごく稀に異なるNonceから同じ $J_0$ が生成される衝突リスクを孕みます。
現場で散見される「脆弱な実装」の例
多くの開発者が、UUIDやランダムな64-bit値をNonceに採用しようとします。しかし、「誕生日のパラドックス」を忘れてはなりません。
64-bitのランダムNonceを使用した場合、約 $2^{32}$ パケット（約40億パケット）で衝突確率は50%に達します。ギガビットイーサネットが標準の現代において、40億パケットなど数時間から数日で到達する数字です。ステートレスなマイクロサービス間でこの設計ミスがあると、攻撃者は静かにパケットをキャプチャし続けるだけで、システムを沈黙させることができます。
—
3. 安全なNonce生成のプラクティス（Python/Cryptography例）
防衛側のアーキテクトとして、我々が採用すべきは「決定論的なカウンター」か「暗号学的に安全なランダム（ただし十分な長さ）」の二択です。
以下に、cryptography ライブラリを用いた堅牢な実装例を示します。
import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
def secure_encrypt(key, plaintext, associated_data):
"""
AES-GCMによる安全な暗号化の実装例
"""
aesgcm = AESGCM(key)
# 【重要】Nonceは必ず96-bit (12 bytes) を選択する。
# NIST SP 800-38D推奨。計算効率と衝突耐性のバランスが最適。
nonce = os.urandom(12)
# 暗号化と同時に認証タグを生成。
# associated_data (AD) には、メタデータ（ヘッダー情報など）を含めることで改ざんを検知可能にする。
ciphertext = aesgcm.encrypt(nonce, plaintext, associated_data)
return nonce, ciphertext
def secure_decrypt(key, nonce, ciphertext, associated_data):
"""
AES-GCMによる復号と完全性検証
"""
aesgcm = AESGCM(key)
try:
# 復号プロセス。タグが不正（Nonceの再利用による改ざん等）であれば、
# ここで例外がスローされ、データは破棄される。
decrypted_data = aesgcm.decrypt(nonce, ciphertext, associated_data)
return decrypted_data
except Exception as e:
# ログには詳細を出さず、認証失敗として処理する（サイドチャネル攻撃対策）
print("Decryption/Authentication failed.")
return None
# 鍵の管理は、可能であればHSMやKMS（AWS KMS, Google Cloud KMSなど）で行うこと。
key = AESGCM.generate_key(bit_length=256)
header = b"user_id:12345"
data = b"confidential project data"
nonce, ct = secure_encrypt(key, data, header)
print(f"Nonce: {nonce.hex()} \nCiphertext: {ct.hex()}")—
4. 監査とアーキテクチャの観点：さらなる防衛層
パケット構造とプロトコル設計
TLS 1.3では、このNonce再利用リスクを劇的に軽減するために、シーケンス番号（レコード番号）をNonceの生成に組み込む「XOR-Nonce」スキームを採用しています。これにより、同じ鍵で同じNonceがネットワーク上を流れることを構造的に防いでいます。自前でプロトコルを設計する場合、この手法を模倣すべきです。
耐量子暗号（PQC）への視座
AES-256自体は、Groverのアルゴリズムに対して十分な耐性を持つと考えられていますが、AES-GCMの「認証構造」そのものは量子コンピュータによる攻撃対象になり得ます。将来的な移行パスとして、AES-GCM-SIV (RFC 8452) の採用を検討してください。これは、万が一Nonceが重複しても、認証の完全性が即座に崩壊しない「合成Nonce」型（Nonce-Misuse Resistant Encryption）のアルゴリズムです。
AIガードレイルとしての暗号基盤
昨今の生成AIブームにおいて、プロンプトインジェクションへの対策が叫ばれていますが、LLMと外部ツール（API）を連携させる際のセッショントークンの受け渡しにAES-GCMが使われるケースが増えています。ここでNonceを再利用するような実装があれば、AIエージェントを介して中間者攻撃（MITM）を仕掛け、認証トークンを偽造することが容易になります。AIのガードレイル設計において、低レイヤの暗号実装は「信頼の起点（Root of Trust）」なのです。
—
結論：美しきアルゴリズムに潜む「牙」を制御せよ
AES-GCMは強力ですが、それは「運用の厳格さ」という代償の上に成り立っています。
Nonceの再利用は単なるバグではなく、暗号学的破綻です。
我々セキュリティスペシャリストの役割は、開発チームに対して「Nonceはランダムで」と伝えることではありません。「なぜ96-bitなのか」「なぜカウンター管理がステートレス環境で危険なのか」という攻撃者の論理をアーキテクチャに組み込むことです。
コードの一行一行に潜む数学的な意味を理解し、泥臭いインシデントハンドリングの経験を設計に昇華させる。それこそが、真に堅牢なエンドポイントセキュリティを構築する唯一の道なのです。
コメント