KRACK（WPA2鍵再インストール攻撃）

何が起きたか（影響範囲・深刻度）

2017年10月16日、Mathy Vanhoef と Frank Piessens が論文「Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2」（ACM CCS 2017）で公開した攻撃です。標的は特定製品ではなく、Wi-Fiの標準暗号であるWPA/WPA2の規格そのものでした。パーソナル（PSK）でもエンタープライズ（802.1X）でも、4ウェイハンドシェイクを使う限り原理的に影響を受け、公開当時「正しく規格に従った実装ほど脆弱」という異例の事態になりました。

割り当てられたCVEは対象ハンドシェイクごとに10本に及びます。中核はペアワイズ鍵の再インストールを突く CVE-2017-13077、グループ鍵は CVE-2017-13078/13079、高速ローミング（802.11r Fast BSS Transition）を突く CVE-2017-13082 などです。攻撃には被害クライアントとAPの通信圏内に入り、両者の間に割り込む中間者（machine-in-the-middle）の位置取りが必要で、遠隔からインターネット越しには実行できません。とはいえパスワードを一切知らずに暗号化トラフィックを復号し、多くの構成でTCPコネクションへのパケット注入まで至るため、深刻度は高いと評価されました。

脆弱性の原理（なぜ起きるか）

WPA2では、PMK（事前共有鍵や802.1Xで得た鍵）から実際の暗号鍵PTK（Pairwise Transient Key）を導出するために4ウェイハンドシェイクを行います。流れの要点は次のとおりです。

AP  --(Msg1: ANonce)-->            Client
Client: SNonce生成 → PTK = KDF(PMK, ANonce, SNonce, MACs)
AP  <--(Msg2: SNonce, MIC)--       Client
AP  --(Msg3: GTK, MIC)-->          Client   ← 鍵確定・インストール指示
AP  <--(Msg4: ACK, MIC)--          Client

クライアントはメッセージ3を受け取った時点でPTKを「インストール」し、以後の暗号化を始めます。ここでCCMPやTKIP、GCMPはブロック暗号をカウンタ/ストリームモードで使うため、フレームごとに一意なnonce（実体は送信パケット番号 PN）と、暗号鍵の組で保護します。鍵とnonceの組が二度と重複しないことが安全性の絶対条件です。

問題は、メッセージ4が電波状況で失われるとAPがメッセージ3を再送する点にあります。規格の状態機械は、再送されたメッセージ3を受けたクライアントに、既にインストール済みの同じPTKをもう一度インストールし直すことを許していました。鍵の再インストールに伴い、送信nonce（PN）と受信リプレイカウンタが初期値へリセットされます。攻撃者はメッセージ4をブロックしてメッセージ3の再送を誘発・保持し、任意のタイミングで再注入することで、このリセットを意図的に強制できます。鍵は変わらないのにnonceだけが巻き戻る、これがnonce再利用（キーストリーム再利用）の直接原因です。

エクスプロイトの流れ（概念）

横にスクロール

攻撃は概念的には次の段取りで進みます（具体的なフレーム生成手順やコードは割愛します）。

1. 中間者の確立: 正規APと同じSSID・同じMACアドレスで別チャネルにローグAPを立て、Channel-based MitMで被害クライアントの通信を中継し、任意のフレームを保持・遅延・再注入できる位置を作る。
2. メッセージ4のブロック: クライアントからのメッセージ4をAPへ届かせない。APはハンドシェイク未完了と判断し、メッセージ3を再送する。
3. メッセージ3の再注入: 攻撃者が保持したメッセージ3を狙った時点でクライアントへ届け、PTKの再インストール＝nonce/カウンタのリセットを強制する。
4. nonce再利用の悪用: 同一鍵・同一nonceで暗号化された複数フレームが観測できるようになる。ストリーム暗号では C1 = P1 XOR KS、C2 = P2 XOR KS から C1 XOR C2 = P1 XOR P2 となり、鍵不明のまま平文差分が漏れる。既知平文（DHCP・ARP・TLSヘッダ等）があれば復号が進む。

影響は暗号方式で差が出ます。CCMP（AES）はキーストリーム再利用による復号とリプレイが主で、フレーム偽造は困難です。一方TKIPやGCMPではMIC鍵やGCMの認証鍵まで危うくなり、復号だけでなく任意フレームの改ざん・偽造（クライアント→AP方向を含む）に発展し得ます。復号後は、暗号化されていないHTTP等に対しHSTSの未徹底を突いてコンテンツ注入を狙う、といった二次攻撃につながります。

修正と対策（パッチが何を変えたか）

修正の本質は暗号アルゴリズムの差し替えではなく、実装側での鍵再インストールの禁止です。ベンダは協調的開発で一斉にパッチを配布し、Microsoftは 2017年10月10日（MS Patch Tuesday）で先行、Appleやディストリビュータも相次いで対応しました。プロトコルとしての後方互換は保たれるため、パッチはクライアント側・AP側のどちらか一方でも適用すれば当該ハンドシェイクの再インストール経路を塞げます（両側適用が望ましい）。緩和策としては、対応が済むまでの間、機微な通信をTLS/VPNで多重に保護すること、802.11rを使わない構成に寄せることなどが挙げられました。根本的な後継が WPA3 で、4ウェイハンドシェイク前段の鍵合意をSAE（Simultaneous Authentication of Equals、Dragonfly）に置き換え、前方秘匿性とオフライン辞書攻撃耐性を強化しています（ただしWPA3自体も後年、Dragonblood等のサイドチャネル指摘を受けています）。

教訓（一般化できる原則）

KRACKの怖さは、AESもハンドシェイクの暗号学的設計も破られていない点にあります。破られたのはプロトコルの状態機械、すなわち「再送は起こりうる」という現実に対して「同じ鍵を二度インストールしてよい」という遷移を規格が黙認していた一点です。個別実装のバグではなく仕様の欠陥だったからこそ、規格に忠実な実装ほど広範に影響しました。

• 暗号の安全性は鍵とnonceの一意性という運用前提に全面依存する: アルゴリズムが健全でも、nonce再利用を許す状態遷移が一つあれば保護は崩壊する。カウンタ/ストリームモードを使う設計では、鍵とnonceの組の非重複を不変条件として明示的に守る。
• リトライ・再送は攻撃者が制御できる入力である: 「まれに起きる再送」を良性と決めつけず、敵対的に何度でも誘発される前提で状態機械を設計する。冪等性（同じメッセージを二度処理しても状態が壊れない）を仕様レベルで要求する。
• プロトコル仕様は形式検証すべき対象である: 4ウェイハンドシェイクは長年安全と信じられ、部分的な形式証明もあったのに、証明のモデルが鍵再インストールの副作用（nonceリセット）を扱っていなかったため見落とされた。証明は前提・モデルの範囲でのみ有効であり、実装が持つ状態（鍵・カウンタの再初期化）まで含めてモデル化しないと保証が空洞化する。ハードウェアでの投機実行を突いたセキュリティ分野のSpectre / Meltdownと同様、「仕様上は正しいのに前提の外側が破れる」典型例といえる。

無線・リンク層のプロトコル設計はネットワーク、鍵管理や多層防御の考え方はセキュリティの各トピックもあわせて参照してください。