WPA2の脆弱性【KRACK】は具体的にどのような仕組みで盗聴する?プロトコル自体の脆弱性とはどの部分?

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 にする)だったら防げていたのかもしれません。

緩和策

この攻撃の緩和策として2つ紹介されています。

1つ目は、キー再インストールの際に、同じものかどうかを確認し、同じものだったらnonce#をリセットしないことです。

2つ目は、そもそもキー再インストールをせず、新たに4way Handshakeをやり直す、ということです。

参考文献

[1] Mathy Vanhoef and Frank Piessens. Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2, 2017.

シェアする

  • このエントリーをはてなブックマークに追加

フォローする