【図解】WPA2の仕組みと脆弱性KRACK, 4way Handshake のシーケンスについて

KRACK で盗聴できるロジック
参考文献
IT/インフラエンジニアの地位とスキル向上のために

KRACK で盗聴できるロジック

2017/10/16 に公開された WPA2 の脆弱性 "KRACK" について、色々な記事を見てみたが、『脆弱性を突かれた結果、どんなことが起きるのか？』については多々記事があったが、『結局どのように盗聴しているの？』という技術者として一番知りたいところが抜けていたので、仕方なく英語の論文を熟読してみましたので簡単に説明します。

前提

攻撃者は、Channel-based MitM なる中間者 (Man in the Middle) 攻撃を使って、盗聴したい無線クライアント (Client) と無線 AP (Real AP) の間に入って全ての通信を (暗号化をほどいて盗聴はできないけど、互いの通信を通過させたり止めたり等で) コントロールできる状態から説明をスタートします。

事前知識　4way Handshake の仕組み・シーケンス

WPA2 で無線 AP にアソシエーション確立後 (さらに IEEE802.1x による認証が要求される場合はそれが終わった後)、4way handshake を行うことで PTK (Pairwise Transient Key) と GTK (Group Temporal Key) という 2 種類の鍵をインストールします。

PTK はユニキャスト暗号・復号用の鍵で、無線 AP と無線クライアント 1 つに対して共通のものが 1 つ、GTK はマルチキャストおよびブロードキャスト暗号・復号用の鍵で、無線 AP 配下の無線クライアント全てで共通のものが 1 つ、となります。

まず、PTK は経路上直接やり取りせず、以下の情報から一意に生成されます。

PMK (Pairwaise Master Key)
Anonce (4way Handshake の Message#1 で送信される)
Snonce (4way Handshake の Message#2 で送信される)
無線 AP の MAC アドレス
無線クライアントの MAC アドレス

PMK (Pairwise Master Key) とは、WPA2-Personal であれば事前共有キー、WPA2-Enterprise であれば IEEE802.1x で交換されるキーです。

4way Handshake の Message#1 と #2 では、Anonce と Snonce の交換を行い、そこで互いに同じ PTK を生成し、インストールします。

PTK は KEK (Key Encryption Key)、KCK (Key Confirmation Key)、TK (Temporary Key) の 3 つから成り、TK はユニキャスト通信暗号・復号用に使います。

4way Handshake の Message#3 では、無線 AP が生成した GTK を、KEK で暗号化して無線クライアントへ送り、受信した無線クライアントは KCK を使って GTK を復号化し、インストールします。

そして最後に無線クライアントは 4way Handshake の完了を示す Message#4 を無線 AP に送ります。

KRACKの攻撃の仕組み・シーケンス

KRACK では、4way Handshake Message#4 を中間者攻撃により意図的に止めることにより、4way Handshake Message#3 を再送させます。

そして無線クライアントはこの Message#3 を受け取るたびに『Message#4 がパケットロスしてしまった』と考え再送するのですが、その際に PTK を再インストールし、同時に、本来は 1 度しか使うべきではない nonce (Number used ONCE) を、再び使ってしまいます。(Anonce, Snonce も nonce の 1 種ですが、ここでいう nonce はそれらとは別のものです。例えば CCMP の nonce だったりします。)

nonce は Temporary Key と一緒に使って通常の通信 (http 等) を暗号化します。

本来は、暗号化するパケット毎に異なる nonce が使われます。例えば 1 パケット目は nonce#1、2 パケット目は nonce#2 となるのですが、この攻撃により PTK を再インストールすると、規格上、nonce が再び #1 からに戻ってしまうのです。

なぜなら規格では Message#3 の再送を許容しており、実施した処理を巻き戻し、プロセスをやり直すことになっているからです。

ここで大きな問題なのは、規格には PTK のインストールのタイミングに関する規定が無く、実装として 1 回目の Message#3 受信のタイミングで PTK をインストールしているものがほとんであることです。つまり、TK と nonce を使って暗号化通信を始めているにも関わらず、Message#3 の再送により処理をやり直すので、同じ TK で同じ nonce を使った通信をしてしまいます。

そして、この Message#3 を繰り返し再送させ続けることで TK もずっと同じものを使わせることができます。そして同じ nonce, 同じ TK、同じパターンの nonce で暗号化されたフレームを解析することで、Temporary Key と nonce のパターンが分かり、盗聴できるようになります。

Android 6.0 等の場合は最悪

Android 6.0 で使われている wpa_supplicant version 2.4 ～ 2.6 では、4way Handshake Message#3 の再送を受信すると、TK (Temporary Key) が全て 0 になってしまう、という致命的なバグがあることが分かりました。このバグは、今回の脆弱性と組み合わさった場合に簡単に攻撃を成功させてしまいます。

wpa_supplicant version 2.3 以前ではこのバグは無かったのに、なぜ 2.4 以降でこのバグが紛れ込んでしまったのでしょうか？

これについて今回の脆弱性発見者は、『IEEE802.11 委員会が「TK は一度インストールしたらメモリから破棄すべき」と言及したことを素直に実装した結果ではないか』と推測しています。

そもそも WPA2 のプロトコル自体の脆弱性っていう話だけど、どの部分なの？

今回の脆弱性で特徴的なのは、WPA2 でセキュリティを保証するための条件として「PTK がリークしないこと」が挙げられますが、この攻撃ではそれがリークしていないことです。

これがまずプロトコル自体の脆弱性であることを示す根拠の 1 つですが、じゃあどの部分が脆弱なの？という点について、今回の脆弱性発見者は、『「各キーをどのようにインストールするか」は定義しているが、「いつインストールすべきか」という定義が抜けており、攻撃による「キーの再インストール」というケースを想定していなかった点』だと指摘しています。仕様策定者たちはもしかしたら『どのタイミングでも問題ないから実装に任せる』というスタンスだったのかもしれません。

具体的に言うと、無線クライアントは Message#3 を受け取った後、すぐに PTK をインストールする、という実装が為されていますが、これは 4way Handshake が完了する前です。

その後何も起きなければ、無線 AP が Message#4 を受け取り、完了するのですが、今回の攻撃はその隙を突いた、ということになるでしょう。なのでキーをインストールするタイミングを限定する仕様 (例えば 5way Handshake にする) だったら防げていたのかもしれません。