KRACK: Key Reinstallation Attacks

今週の月曜あたりで話題になっていた、WPA2の脆弱性に関連する論文が、ちょうどタイムリーなのでネタにしていこうと思います。CTFと関連するかは微妙ですが、流行りに乗ってしまうのが若者の性なので。

概要

今日の概要は次の点です

  • WPA2(WPA)の接続に関するプロトコル概観
  • KRACKについて

正直論文読んでからわかったことではあるんですが、思ったよりネタがつまらない（僕が技術力なくて再現できないため、こうこうこういう挙動が起きうるんだよ〜〜だって論文に書いてあるもん状態）こともあり、多分そんなに時間がかからないことや、今学期からの人も多いことから時間が余ったら、CTF概観についてもう一度やろうかなと思います

ところで、間違いなどツッコミをお願いします

WPA2って何

WPA2とは、いわゆるWi-Fiのセキュリティプロトコルのことをいう。多分今もっとも世の中で使われている形式。無線LANネットワークは（とても明らかだが）、任意の人が接続できてしまう点で、タダ乗りや、盗聴（もっとも平文で通信する以上盗聴されても仕方ないが）されたりする危険性が、有線でつないだときよりも高い（とされている）。無線LAN普及に伴って、こういった問題を解決するために策定されていて、基本的にはアクセスポイント（以下APと略す）と同じ鍵を持っていれば認証が通って、そのAPを使うことができるようになる仕組みになっている。

（どうでもいいかつ無限に話されてきた事実として、WEPという古いプロトコルがあるが、これはそこらへんに落ちているツールで簡単に解析できて少しウケるため、最高に暇な時に試すとちょっと面白いかもしれない）

WPA2の認証

今回着目する部分として、Supplicant(Client)がAuthenticator(Access Point)に接続をするときにどのような処理が行われているかについて説明する。

enter image description here

Association Stage

クライアントがWiFiのネットワークに接続したいと思った時に一番最初に始まるステージである。この部分は過去のWEPにおいて認証として使われていた部分であり、オープン認証と言われる。実際の認証はこのあとの4 way Handshakeで行われ、ここでは暗号方式の確認などが行われる。

4 way handshake

主役部分。PMKと呼ばれる、いわゆるWiFiに接続されるために必要となる鍵を元として、今後通信で使うことになる鍵PTKをAPとClientで生成する。今回の論文ではここが重要となる。

まず、ANonceをAuthenticatorがSupplicantに送り、SupplicantはSNonceをAuthenticatorに送り返す。これらは、PTK生成のための乱数である。この二つをAuthenticatorとSupplicantが共有すると両者はそれぞれPTKをPMK, ANonce, SNonceそしてSupplicantとAuthenticatorのMACアドレスから計算する。 　これにより、AuthenticatorとSupplicantは、このSessionの間で使用が可能となった共通の鍵を生成したことになり、これを用いてGTKと呼ばれるマルチキャスト用の鍵をAuthenticatorから共有してもらう。基本的にこのGTK交換以降は全てセッションキーで暗号化された状態で通信が行われるようになる

Key Reinstallation

4 way handshakeでのSupplicantにおける状態遷移

　プロトコル上の欠陥であるといわれるのは、この状態遷移に問題があるためである。これについて簡単に説明する。

　802.11iの規格においてはどのようにState machineが記述されるべきかについての記述がなく、ただ疑似コードが書かれているだけである。これが、そもそも規格書がクソと言われる所以である

IEEEがカス ちなみに論文内にもカスって書いてある

Supplicatnt State machineの概要は次のような図で表される

enter image description here

4 way handshakeが始まるとまずPTK-INITというstateに入る。このStateにおいて、PMKを指定する。APから4 way handshakeの一つ目となるMSG1を受け取ると、stateはPTK-STARTに入る。この際に、すでに説明したようにSNonceやそれを元にしてPTKが計算でき、そしてMSG2を送信する。ところでこの状態の間に再びMsg1を受け取ると再びこの状態に戻る。

AuthenticatorがMSG2を受け取ると、MSG3を送ってくれる。このMSG3を受け取ってかつ、MIC(Message Integration Check)が通り、またreplace Counterが正しければ、PTK-NEGOTIATINGという状態に入る。

PTK-NEGOTIATINは基本的にTPTKをvalidとしてPTKとして決め、MSG4を送るだけである。

すると、そのままPTK-DONEという状態に入る。これにより、4 way handshake自体は終了する。

ところで、PTK-DONEとは実際にネットワーク通信を行うフェーズである。この間に例えばセッションキーを初期化しようとするためにAPがMsg1を送ってきたり、またMsg4が正しくAPに送信されなかった時にMsg3を再び送信してくる可能性がある。

特に重要なのは後者の場合で、このようにMsg3が再び送られてきたときに、キーを再設定する必要がある。今回問題となったのはこの部分である。

The Key Reinstallation Attack

この攻撃、大変言っていることは単純である。まとめれば次の通りである。

  • SupplicantとAuthenticatorの間に入る（いわゆる中間者攻撃）
  • Supplicantから送信されるMsg4を妨害し、Authenticatorに送らせない
  • AuthenticatorはMsg3/Msg4かが喪失したと考えMsg3を再送信する
  • 結果として鍵がリセットされ一度使われたNonceが再び用いられる

Nonceとは定義から「number used once」すなわち一度しか使われないことを保証されている値でありこれが複数回使われることは問題である。

実際Nonceが複数回使われることによって発生しそうな問題についてはあとで考える。

Android6.0固有の問題（正確には特定のバージョンのwpa_supplicantを使っている場合の問題）

実は今回の問題がとても大きくなったのは、LinuxやAndroidで使われていた（すでに古いものになっているが）とある実装に結構やばめのバグがあったためではないかと思っている。具体的なバージョンとしては、wpa_supplicantの2.4と2.5がやばい。

これは何が起きているのかといえば、上記の方法でMsg3が再びこのSupplicantに送信されると実装上のバグにより、鍵の値が0になってしまうというバグである。これにより明らかに暗号が意味をなさなくなる。

GTK Handshake、FT Handshakeや実装依存の問題

各論になるためはしょります:)

sslstripって何

https://moxie.org/software/sslstrip/

例の動画に関して

まぁだいたい何が起こっているかがわかった（そもそも今見たら日本語の字幕がついててウケる）

内部で起きていること

  1. Man In The Middleをする。これはMac Addrを同じにしないといけないという制約を満たしつつ、行うために、一度つないだネットワークに対して、違うChannelを使うように誘導する（これは実は攻撃者のAP）ことで行う。
  2. sslstripをする。これは、通信を傍受してhttpsっぽいリクエストなりリンクなりをhttpに変えちゃうすごいやつらしい
  3. Key Reinstallation。今回の主役。これをするとAndroidでは、なんとキーが0になるという激ヤババグがあるため誰でも通信の復号が可能となる。これにより、WPAの暗号を突破。
  4. httpsは全く突破しているわけではなく、sslstripにより、httpで接続させた結果行った先にサイトがhttpによる通信を拒絶しなければそのまま通信がバレてしまう

ところでNonce Reuseがどれくらい問題か

Confidentiality and Integrity Protocols

今回データを実際に暗号化するために使われるプロトコルとして主に次の三つがある

  • TKIP
  • CCMP
  • GCM

TKIP

RC4を使う。鍵の生成に、PTKから作られる128bitのEncryption KeyとNonce, MAC Addressを用いる。これはRC4を使っている観点からすでにdeprecatedであるとされている。

CCMP

CCMモードでAESを使う。IVの生成にMAC Addressと48bitのNonceなどを使う。このときIVが再び使われることがない必要がある。

GCMP

GCMモードでAESを使う。これもIVの生成にMAC Addressと48bitのNonceを使うのだが、IVが再び使われることがない必要があり、実際にCiphertextが正しく認証されているかを判定するGHASH関数に使われている鍵を、Nonceのreuseで復元できることが論文として発表されている。

データ復元できるの？🤔

TKIPはまずそう

TKIPに関しては基本的に、同じ鍵で異なる文章を暗号化するのは基本的にかなり問題である。というのは、RC4はKeyを元に生成されたバイト列とのxorを平文とかけているだけであるため、Nonceが同じ値になる場合、生成される鍵のストリームは完全に一致する。結果として、Msg1とMsg2に関して

C1 = Msg1 + Key_stream C2 = Msg2 + Key_stream

C1 + C2 = Msg1 + Msg2

となり鍵の関与がなくなる。例えば片方のメッセージが推測可能であった場合、自明にもう片方のメッセージは獲得可能であるほか、頻度解析により復元が可能となる。（これは多分WEPが死ぬのと同じ理由である）

残る二つに関して

ところで、他の暗号に関してはAESを使っているため自明な危険性がよくわからない。

例えばAES GCMに関しては過去の事例としてTLSの話がググると引っかかる

nonce-disrespect

これはGCMモードのAESに関連してIVが再利用される時に最悪の場合任意の改ざんができるとのことである。

これに関連する問題として、Sharif CTF 2016GCM Magicがあるようである。@elliptic_shihoさんのWriteup

しかし、これによってバレるのは、Ciphertextが認証されているかどうかに関する値であり、実際の暗号文ではない。これによって可能となるのは、通信の改ざん（というのは通信した値が妥当であるかを示すための鍵に関してはバレるため）である。

参考 本当は怖いAES-GCMの話

論文では結構強気に改ざんや解読が可能と書いてあるような気がするが、あまりよくわかっていないため教えて欲しい。色々できるのなら、CTFの問題に出てたら楽しそうな話題であるため、見かける気がするのだけれど、（言うほど解いてないが）見たことがないため、現実的手法があるのかどうかがよくわからない（まぁ暗号学者的には常識みたいな話があるのかもしれないが）。

そもそもNonceは一回しか使われないことを前提に暗号が設計されているわけで、安全性に関する証明もそれを前提としているため、問題なことには違いないが、これにより現実的にどういうことが起きるのかについては完全にはまだ理解が走っていない。ごめんなさい。