WPA3 と SAE:Dragonfly ハンドシェイクの原理
Wi-Fiのパスワードがどれだけ短くても、捕まえたパケットからの総当たりで破れなくなる理由が腑に落ちる。SAEの相互認証と前方秘匿性、KRACKを封じる設計までWPA3の核を原理から押さえられる。
- 1.WPA2-PSKはパスフレーズからPMKを直接導出するため、4-way handshakeを1回キャプチャすればオフラインで何兆通りでも辞書攻撃を試せた。これがWPA3で塞がれた根本。
- 2.SAE(Dragonfly)はバランス型PAKEで、双方がパスワードの知識を相手に明かさず証明し合う。各接続ごとに楕円曲線の一時鍵を使うため、PMKは毎回新しく前方秘匿性を持つ。
- 3.SAEは1回の試行ごとにAPとの往復通信が必須なので、オフライン総当たりが成立しない。さらにWPA3はPMF(管理フレーム保護)を必須化し、KRACKの足がかりとなるなりすまし切断を封じる。
WPA2-PSK はなぜ辞書攻撃に弱かったのか
WPA2-Personal(WPA2-PSK)の弱点は、暗号の強さではなく鍵の作り方にありました。事前共有鍵モードでは、パスフレーズと SSID から PBKDF2 で PMK(Pairwise Master Key)を一意に決めます。
PMK = PBKDF2-SHA1(passphrase, SSID, 4096回, 256bit)
問題は、この PMK がパスフレーズだけで決まる決定論的な値である点です。接続時の 4-way handshake では、PMK から派生した PTK で MIC(メッセージ完全性コード)を計算してやり取りします。攻撃者はこの handshake を一度キャプチャするだけで、あとは端末を持ち帰り、候補パスフレーズごとに PMK→PTK→MIC を再計算して観測値と突き合わせられます。これがオフライン辞書攻撃です。
決定的なのは「オフライン」という性質です。AP との通信は最初の1回で完結し、以降は手元の GPU が許す限り毎秒数十万〜数百万通りを試せます。パスフレーズが短かったり辞書語だったりすれば、現実的な時間で割れてしまいます。
WPA2 の脆弱性の本質は暗号アルゴリズムの強度不足ではなく、検証が AP との往復なしに手元で完結してしまう点にあります。だから「パスワードを長くする」以外の防御策が事実上なく、利用者の運用に依存していました。WPA3 はこの構造そのものを設計で塞ぎます。
SAE:対等な相手同士の相互認証
WPA3-Personal は鍵交換を SAE(Simultaneous Authentication of Equals) に置き換えました。SAE は RFC 7664 の Dragonfly 鍵交換を 802.11 に適用したもので、分類上は**バランス型 PAKE(Password-Authenticated Key Exchange)**です。
PAKE の狙いは「低エントロピーな共有秘密(パスワード)から、高エントロピーなセッション鍵を、パスワードを漏らさず安全に作る」ことです。「バランス型」とは、クライアントと AP が対等で、どちらも同じパスワードを持つ前提で互いを認証し合うことを指します(サーバーだけが秘密を持つ非対称型 PAKE と対比されます)。
SAE の出力は WPA2 と同じく PMK ですが、決定的に違うのは、その PMK がパスフレーズだけからは決まらない点です。
| 観点 | WPA2-PSK | WPA3-SAE |
|---|---|---|
| PMK の決まり方 | パスフレーズと SSID から決定論的 | パスフレーズ+毎回の一時鍵から導出 |
| 攻撃モデル | handshake 1回キャプチャでオフライン総当たり | 1試行ごとに AP との往復が必須 |
| 前方秘匿性 | なし(PMK 露呈で過去も復号可) | あり(一時鍵が接続ごとに使い捨て) |
| 認証の方向 | 実質的に片方向(鍵の一致確認) | 相互(対等な双方向認証) |
Dragonfly の中身:commit と confirm の2段
SAE のハンドシェイクは commit と confirm の2つの交換からなります。使う数学は楕円曲線(ECC グループ)または有限体(FFC グループ)上の離散対数問題で、TLS の ECDHE と同じ難しさに安全性を預けます(/network/tls13-handshake-internals/ の鍵交換と同系統)。以下は ECC グループでの流れです。
1. パスワード要素 PE を導出する
まず双方が、パスフレーズから曲線上の一点 PE(Password Element) を決めます。当初の SAE は hunting-and-pecking という反復法を使いました。
for counter = 1, 2, 3, ...:
seed = Hash(MAC_A, MAC_B, password, counter)
x = KDF(seed)
if x が曲線上の有効な点を与える: PE を確定し終了
ただしこの反復回数がパスワードに依存して変わるため、処理時間からパスワードを推測するサイドチャネルが問題になりました(Dragonblood 攻撃)。対策として SAE-H2E(Hash-to-Element) が標準化され、反復ループのない定数時間アルゴリズムで PE を求めるようになっています。
2. commit 交換:一時鍵をコミットする
各端末はランダムな2値 rand と mask を選び、scalar = (rand + mask) mod r、element = -mask * PE(曲線上の点)を計算して相手に送ります。rand と mask は秘匿し、合成した scalar と element だけを公開します。
A → B : scalar_A , element_A
B → A : scalar_B , element_B
ここがポイントです。送られるのは PE を一時値で隠した合成値であり、パスワード自体も PE も平文では一切流れません。盗聴者は scalar/element を見ても、離散対数を解かない限り PE を復元できません。
3. 共有秘密の合成と confirm 交換
双方は受け取った値と自分の rand を使い、同じパスワードを持つ場合にだけ一致する共有点 K を計算します。K から KDF で PMK と確認用の鍵を導出し、confirm(相手の値に対する MAC)を交換して、互いが本当に同じパスワードから K を導けたことを検証します。
A → B : confirm_A = MAC(K, scalar_A, element_A, scalar_B, element_B)
B → A : confirm_B = MAC(K, scalar_B, element_B, scalar_A, element_A)
confirm が一致すれば相互認証が成立し、共通の PMK が確定します。この PMK を入力に、従来どおりの 4-way handshake で実際の暗号鍵 PTK を張ります。
Dragonfly の巧みさは、Diffie-Hellman 型の鍵合意とパスワード認証を分離せず一体化した点にあります。PE という共有秘密を曲線上に埋め込むことで、「鍵交換が成功=同じパスワードを知っていた」が同時に保証されます。鍵だけ作って後でパスワードを確認するのではなく、パスワードを知らなければそもそも同じ K に到達できません。
なぜオフライン辞書攻撃が成立しないのか
SAE では、攻撃者がパスワード候補を1つ試すたびに、正規の AP に対して commit を送り応答を得る往復が必要です。盗聴したパケットだけでは、候補ごとに K を再計算して当たりを判定することができません。element は毎回の一時値 mask で隠されており、パスワードを固定しても観測値から K を逆算できないからです。
結果として攻撃はオンライン総当たりに格下げされます。AP は1秒あたりに応答できる回数が限られ、しかも連続失敗をレート制限・ロックアウトで検知できます。WPA2 の「手元で毎秒数百万通り」と、SAE の「AP 越しに毎秒数回」では、現実的な突破可能性が桁違いです。
SAE は弱いパスワードを強くするわけではありませんが、検証を必ずオンラインに縛ることで、辞書語のような弱いパスフレーズでも「手元で一瞬で割れる」状況を避けられます。利用者の運用品質に左右されにくい点が、WPA2 からの実務上の最大の改善です。
前方秘匿性(forward secrecy)の獲得
SAE のもう1つの収穫が前方秘匿性です。commit で使う rand/mask は接続ごとに使い捨ての一時値で、セッション終了後は破棄されます。PMK はこの一時値に依存して導出されるため、たとえ将来パスフレーズが漏洩しても、過去にキャプチャしておいた通信を遡って復号することはできません。各セッションの PMK が独立だからです。
WPA2-PSK にはこれがありませんでした。PMK はパスフレーズで決まるため、後でパスフレーズが判明すれば、保存しておいた過去の handshake から PTK を再構成し、過去のトラフィックを復号できてしまいます。一時鍵で毎回鍵を作り直す発想は TLS 1.3 の ECDHE 必須化(/network/tls13-handshake-internals/)や WireGuard の毎回ハンドシェイク(/network/wireguard-protocol/)と同じ系譜にあります。
KRACK と管理フレーム保護(PMF)
KRACK(Key Reinstallation Attack, 2017) は SAE ではなく、SAE の後段に残る 4-way handshake の実装欠陥を突く攻撃でした。攻撃者が handshake のメッセージを再送させると、一部実装が同じ鍵を再インストールしてノンス(nonce)をリセットしてしまい、キーストリームが再利用されて部分的な復号や改ざんを許しました。
ここで誤解しやすい点を整理します。WPA3 でも PMK を確定したあとは 4-way handshake を行います。KRACK 自体はパッチで WPA2 にも修正が配られました。WPA3 が構造的に堅いのは、PMF(Protected Management Frames, 802.11w)を必須化している点です。
| 攻撃の足がかり | WPA2(PMF 任意) | WPA3(PMF 必須) |
|---|---|---|
| なりすまし Deauth/Disassoc | 平文なので偽造・注入し放題 | 認証付きで偽造フレームを拒否 |
| 強制再接続の誘発 | 容易(KRACK の前提を作りやすい) | 困難(切断を勝手に起こせない) |
| handshake への割り込み | 管理フレームで揺さぶれる | 管理フレームが保護され効きにくい |
KRACK や多くの実用攻撃は、まず偽の認証なし管理フレーム(Deauthentication など)を送って端末を切断・再接続させ、handshake をやり直させる足がかりを必要としました。PMF はこの管理フレームに完全性保護を与え、偽の切断要求を無効化します。足場そのものを奪うことで、再接続を起点とする一連の攻撃を成立しにくくしているわけです。Wi-Fi の管理フレームと MAC 層の基礎は /network/wifi-csma-ca/ も参照すると立体的に理解できます。
「WPA2-PSK の弱点は」→ PMK がパスフレーズから決定論的に決まり、handshake 1回のキャプチャでオフライン辞書攻撃が可能。「SAE は何型の鍵交換か」→ バランス型 PAKE(Dragonfly)で対等な相互認証。「なぜ辞書攻撃に強いか」→ 1試行ごとに AP との往復が必須でオンライン総当たりに制限される。「前方秘匿性が出る理由は」→ commit の一時鍵が接続ごとに使い捨て。「KRACK と WPA3 の関係は」→ KRACK は 4-way handshake の欠陥で SAE 固有ではないが、WPA3 は PMF 必須化で偽 Deauth を封じ足場を奪う。この5点を因果で結べれば上級。
まとめ
WPA2-PSK の根本的な弱点は、PMK がパスフレーズだけで決まるために handshake を1回奪えば手元で無制限に辞書攻撃できたことでした。WPA3 は鍵交換を SAE(Dragonfly) に置き換え、楕円曲線上の一時鍵を使ったバランス型 PAKE に作り替えます。commit/confirm の2段でパスワードも PE も漏らさず相互認証し、出力 PMK を一時鍵に依存させることで、オフライン辞書攻撃の不成立と前方秘匿性を同時に獲得しました。さらに PMF を必須化して偽の管理フレームを封じ、KRACK のような再接続起点の攻撃から足場を奪います。「低エントロピーな秘密を、漏らさず、毎回新しい高エントロピー鍵に変換する」という PAKE の発想が、無線セキュリティの世代交代を支える一貫した設計思想です。
ネットワーク Article
WPA3 と SAE:Dragonfly ハンドシェイクの原理を実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
WPA3
比較で見る軸
難易度: advanced / カテゴリ: ネットワーク / タグ数: 6
導入後に効く点
SAE(Dragonfly)はバランス型PAKEで、双方がパスワードの知識を相手に明かさず証明し合う。各接続ごとに楕円曲線の一時鍵を使うため、PMKは毎回新しく前方秘匿性を持つ。
先に潰すリスク
用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。
- 難易度
- advanced
- カテゴリ
- ネットワーク
- タグ数
- 6
判断チェックリスト
- 自社の用途が「WPA3 / SAE」に近いか確認する。
- 強みである「WPA2-PSKはパスフレーズからPMKを直接導出するため、4-way handshakeを1回キャプチャすればオフラインで何兆通りでも辞書攻撃を試せた。これがWPA3で塞がれた根本。」が本当に評価軸になるか確認する。
- 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。