WPA/WPA2の脆弱性“KRACKs”、悪用のハードルは？

WPA/WPA2の脆弱性が2017年11月に公表

　AES暗号化の基本的な方式そのものには、2017年あたりまで大きな変化もないまま使い続けられ、AESへの攻撃も、これを直接破ることに成功した事例はなかった。

　では2017年に一体何があったのか？　ベルギーにあるルーヴェン・カトリック大学のMathy Vanhoef氏とFrank Piessens氏の2人が、WPAとWPA2（潜在的にはIEEE 802.1X）の脆弱性を発見したことからスタートする。2人は研究論文をまず大学に提出するが、これはあくまでも提出されただけで、この時点では公開されてはいなかった。

　ただ、この脆弱性の影響は非常に大きいということで、2人は脆弱性の実験を行った機器を開発したベンダーに7月頃に連絡。次いで米CERT Coordination Center（CERT/CC）に対し、脆弱性に関する情報を連絡する。CERT/CCは8月28日、複数の開発ベンダーに対してこの脆弱性を通知し、対処を促している。

　ここから2か月ほど間をおいた10月6日、情報セキュリティ関連では世界最大のイベントである「BlackHat」の公式アカウントが、BlackHat Europe 2017で、WPA2の脆弱性に関する発表があることをTwitterでアナウンス。同日、Wi-Fi AllianceもWPA/WPA2の脆弱性と、これがソフトウェアの修正で対処できることをアナウンスした。

　また同日には、10月30日～11月3日にダラスで開催された「CCS'17（ACM Conference on Computer and Communications Security）」という学会において、Vanhoef氏とPiessens氏の論文は正式に公開され、11月8日には実証コードが公開されたことがVanhoef氏によりアナウンスされた。かくして、WPA/WPA2の脆弱性に関する情報が広く知れ渡ることになった。

　念のために書いておけば、情報公開に至るまでの一連の手順は、実に適切なものだった。米CERT/CCから各ベンダーに連絡が行ってから2か月ほど間が空いているのは、この間に各ベンダーの側がファームウェアへの対策を行い、配布準備を進めていたということである。

　おそらく、主要なベンダーの製品に関しては、対策ファームウェアの配布準備、もしくは先行配布（エンタープライズ向け製品の場合はあり得る）が完了し、脆弱性の情報を公開しても対応できるという連絡が米CERT/CCに入ってきた結果、Vanhoef氏に対して情報公開の許可が下りたものと思われる。

　この手の情報を事前準備なく公開してしまうと、悪用する人間が続出してしまうため危険だ。その一方で、情報を秘匿し続けるのは不可能だし、別の人間が再発見して悪用することもあり得るわけで、脆弱性は脆弱性として早めに公開し、その知見を活かせるようにするのが正しいあり方である。

KRACKs脆弱性悪用のハードルは高い

　この脆弱性は「KRACKs（Key Reinstallation Attacks）」と呼ばれている。具体的な悪用の方法について触れるより前に、まず、前提となる環境の仕組みを説明しておこう。

　最初は、アクセスポイントとクライアントが動作しているWi-Fiのカバー範囲にAdversaryを設置する。このAdversaryは、クライアントにはあたかもアクセスポイントとして、逆にアクセスポイントにはあたかもクライアントとして、それぞれ動作するように見せかける。具体的には、MACアドレスとSSIDをそれぞれ同じように偽装するかたちだ。

　これで、クライアントがアクセスポイントではなくAdversaryに運よく接続してくれれば準備完了である。この時点で、アクセスポイントとクライアントは、通信の経路にAdversaryが入り込んだことは全く認識できない。そもそもIEEE 802.11には、そうした検出の機能はないのだ。

　そうして入り込んだAdversaryは、最初はTransparencyに動作する。つまり、アクセスポイントから届いたパケットはそのままクライアントへ再送するし、逆もしかりである。この状態では、特段何も発生しないが、ここで4-way Handshakeが発生した場合に、介入が始まることになる。

　4-way Handshakeは第9回でも触れた通り、暗号鍵を交換する手順である。この流れをまとめたのが以下の図だ。リンク確立の後で、まずアソシエーションを行った後、Msg1～Msg4までの4つのメッセージをお互いに送り合う。この過程でクライアントは「PTK（Pair-wise Transient Key）」を生成、これのNonceをMsg2で送り出す。これを受け取ったアクセスポイントもPTKを生成した後、いったん仮の「GTK（Group Transient Key）」を生成し、これをMsg3でクライアントに送出、受け取ったクライアントはMsg4で受領確認を行う。

　ここまでで鍵の交換は完了するわけだが、この後、アクセスポイントはGTKを一度更新し、その鍵をPTKを使って暗号化してクライアントに送出、クライアントはこの受領確認を送り出し、そこでGTKの更新が完了する。これで、アクセスポイントとクライアントの両方が同じGTKを共有できたことになるので、以後はこのGTKを使ってデータを暗号化するかたちになる。

　さて、問題はこのPTKあるいはGTKはリフレッシュできることだ。GTKについては定期的に更新を行う仕組みが入っているが、PTKそのもののリフレッシュも可能であり、これが行われた場合、4-way Handshakeを最初からもう一度やり直すことになる。つまり、すでにアクセスポイントとクライアントが通信を行っている環境で、後からここにAdversaryを追加して通信の傍受（というか通信の仲介）を行わせている場合でも、4-way Handshakeが入る場合がある。

　ここまでの手順を踏まえ、論文ではクライアント側の振る舞いに応じた3パターンほどの攻撃手法が紹介されている。ここでは一番シンプルな方法を説明しよう。

　まず最初のアソシエーションはもう発生しないので、4-way Handshakeからスタートするわけだが、まずMsg1/2の交換はそのまま行われる。そして、アクセスポイントの側では仮のGTKを生成、これをMsg3で送り出すのだが、その返答であるMsg4についてはそのまま返送せずにしばらく留保しておく。

　この状態でクライアントでは、4-way Handhsakeが完了したと理解するので、以後、GTKの交換が完了するまでの間、PTKを使って暗号化したメッセージを送り出す。とりあえずこれをAdversary側ではすべてブロックする。そうしている間に、アクセスポイントの方では、Msg3に対してMsg4が戻ってこないため、Msg3の再送を行うことになる。

　これはそのままクライアントに伝達するわけだが、既にクライアントの側は通信を暗号化するモードに入っているため、Msg4は暗号化されたかたちで送出される。それとともに、PTKとGTKの再インストールが行われる。

　さて、Adversaryはこの段階で、先に保持しておいたMsg3を送り出し、その後PTKで暗号化されたMsg4を送り出す。こうすると、アクセスポイントの側は最初に送り出したMsg3の返答がやっと届いたとみなして、その後は通常通り通信を開始するわけだが、これにより、Adversaryは以下の両方を手に入れることができる。

• 暗号化されていないMsg3
• TKPで暗号化されたMsg3

　この差分から暗号パターンを再生することで、TKPで暗号化された内容が解読可能になり得る可能性があるわけだ。これがKRACKs脆弱性の骨子であり、ここまでの流れをまとめたのが以下の図である。

　ここでポイントとなるのが、クライアント側のNonceの振る舞いである。Nonceは要するにIVのようなもので、パケットごとに変化するのだが、最初に「Msg4(r+1)」を送って暗号化モードに入った後、再び暗号化されていない「Msg3(r+2, GTK)」を受け取ると、一度暗号化モードから抜け、その後の「Enc{Msg4(r+2)}」で再び暗号化モードに入る。しかし、その際にNonceが1に再設定される、という振る舞いをすることが、KRACKsで悪用されるかたちだ。

　このKRACKsでは、同じ理屈を利用して、4-way Handshak以外にGTK、PeerKey、TDLS、FTなどのプロトコルにも有効であるとされる。さらに、「IEEE 802.11r」（ローミング）にも影響を及ぼし得るとされている。

　もっとも、潜在的には大きな影響を与え得る脆弱性ではあるのだが、実際にここからPTKを推定するためには、膨大な数のMsg4を再送せねばならず、またこれで分かるのはPTKであってPMKではないため、マスターキーは安全、といったこともあり、直ちにWPA2が危険になるといった類の話ではない。

　ただ、これに加えてOS側の脆弱性を組み合わせることで、実際にデータの解読を行った以下のデモ動画が、Vanhoef氏により公開されている。

　ということで、業界としてはこれに素早く対応した。例えば上の動画で紹介されているのは、キーの再インストールが発生する際に、AndroidやLinuxでは秘密鍵ではなく「すべて0のキー」を使うため、簡単に解読されてしまうというもの。これはAndroidやLinuxの実装のバグで、Androidは2017年11月6日のセキュリティパッチでこれに対応しているし、Linuxも各ディストリビューションごとに対策パッチが出ている。

　これらのAndroidやLinux以外のOSも含め、現状ではセキュリティパッチをきちんと適用していれば、WPA2を使っていても直ちに通信が傍受される心配はない。

　それとは別に、WPA2の脆弱性の解消のため、4-way Handshakeに代わる新しいプロトコルが必要との認識がWi-Fi Allianceで持ち上がったのは、しごく当然のことだろう。