SSID・パスフレーズ交換の標準規格「WPS 2.0」、「WPS 1.0」の脆弱性を解消

1万1000回の総当たりで突破可能な「WPS 1.0」のPIN認証

　順序から言えば、先に「WPS 2.0」の話になるのだが、その前に「WPS 1.0」の脆弱性の話を紹介したい。2011年12月27日、米CERT/CCは、WPS 1.0のPIN認証における脆弱性情報「VU #723755」を公表した。日本では2012年1月4日、JPCERT/CCが「JVNVU #723755」として公開している。

　これは、前回は紹介しなかった「PIN（Personal Identification Number）認証」を利用した際の脆弱性で、その接続手順は以下となる。

1. アクセスポイントとクライアントをPINモードに設定
2. アクセスポイントないしクライアント側で8桁のPINを生成（仕様では乱数など用いた生成を要求）
3. 生成されたPINを相手側に登録
4. 登録されたPINを元に、アクセスポイントとクライアントとの間で認証作業を行う

　プロトコルとしては、実は前回紹介したWPSボタンを押す場合の「PBCモード」と同じだ。PBCモードでは、Device Passwordに"00000000"を利用するのだが、PINを利用する場合は、PINがDevice Passwordになるかたちで実装されている。

　例えば、アクセスポイント側でPINを生成した場合、そのPINを利用してクライアントからEAPリクエストを送信し、これが一致していなければ「EAP NACK」（正確に言えばEAP Messageの中に「WSC_NACK」が含まれる）が返され、セッションが終了する、というわけだ。

　さて、脆弱性の話だが、そもそもPINの場合、上位7桁は乱数で生成される。ただ、最後の1桁はチェックサムとなっており、実質7桁分の強度しかないことになる。おまけに、仕様では8桁となっているが、世の中には4桁のみ、つまり実質で言えば3桁だけでPINが実装された製品が少なくない。

　この結果、総当たりで試しても、PINコードの解読が実質1万1000回程度の試行で可能になってしまう。また、機器の中には、連続して複数回失敗した際に、しばらく認証を受け付けないという対策が、採られていないものもある。こうした機器の場合は、より迅速にPINコードを解読できてしまうわけだ。

　これに関しては、実質的に対処法がない。WPS 2.0では、この総当たり攻撃に対抗するべく、2012年1月30日リリースの「2.0.2」において、PINを利用した場合のプロトコルを一部変更している。ただし、WPS 1.0の機器を利用する限りにおいて、通常はPINモードを無効にする、つまりWPSそのものを無効にするくらいしか、対策がないのが実情だ。

　もっとも、現実問題としては、普段から煩雑に新規クライアントの登録が必要といった環境でもなければ、WPSを無効にしておいても大きな支障はない気もする。

　ただ、これはWi-Fiの設定に慣れた人間の言い分で、不慣れなユーザーには、この状態での運用は難しいと思われる。そんなわけで、対策としては「早急にWPS 2.0対応のアクセスポイントへ入れ替えましょう」ということになる。

2010年12月リリースの「WPS 2.0」

　さて、WPS 2.0である。こちらは2010年12月20日に「2.0.0」がリリースされ、その後何度か改訂されている。現時点では、2018年4月26日にリリースされた「2.0.6」が最新版だ。WPS 1.0とWPS 2.0の関係は、WPAとWPA2の関係とは異なっており、基本的に大きくは変わっていない。

　WPS 2.0ではWPS 1.0で不明確だった部分をきちんと定義し直したり、PINコードを入力する場合への対応が行われたほかは、60GHz帯へのサポートや、一部Wi-Fi Directへの対応を追加したり、といった程度に留まっている。このため、アクセスポイントがWPS 2.0に対応している一方、クライアント側がWPS 1.0にしか対応していない場合にも、問題なく利用可能である。

　定義し直した点というのは、プロトコルのシーケンスが「PBC basesd setup」と「PIN based setup」で誤解を招かないよう別々に説明された。例えば、PIN based setupの場合に、クライアントの生成したPINコードをアクセスポイントに入力する「External Registrar trigger first」と、アクセスポイントの生成したPINコードをクライアントに入力する「Enrollee trigger first」の2つが、きちんと図示されるようになっている。

出典は"Wi-Fi Simple Configuration Technical Specification Version 2.0.6"

　ちなみに、先ほど出てきたPIN based setupにおける総当たり攻撃への対応だが、例えば上の1枚目と、10月23日付の本連載で掲載した以下のWPS 1.0の手順を比べると、Probe Requestの後に、Beacon、Authentification Request/Response、Association Request/Responseが追加されているのが分かるだろう。

　この追加シーケンスでは、アクセスポイントとPINコードの交換を行うクライアントのMACアドレスを特定し、この特定された（AuthorizedMACs）クライアントとのみ、PINコードの交換を行うかたちだ。ちなみに、相手がWPS 1.0相当だった場合は、このMACアドレスにワイルドカード（FF:FF:FF:FF:FF:FF）を利用することになっている。

　それでもMACアドレスを偽装されてしまえば破られる可能性はある。その場合、同じMACアドレスを持つデバイスが2つ存在することになるので、正常な通信ができなくなる。このため、とりあえずPINコードを読み取られて侵入される可能性は、なくなることになる。

　逆に、正当なクライアントが通信できない場合があるという問題は起こるが、それは、WPS側で対処できることでも、対処することでもない、という割り切りがあったと思われる。

　さて、今のところWi-Fi Allianceとしては、このWPS 2.0と先日発表になった「WPA 3」で、セキュリティ標準が一応は満足できる状況にあると考えているようだ。今のところ「WPS 3.0」といった話は特に聞こえてきておらず、むしろIoT機器などの新しい分野をどうセキュアにつなぐか、といった方向での検討に入っているようだ。つまり、スマートフォンやPCのような「人間が利用する機器」については、WPA 3＋WPS 2.0で一段落、ということではないかと思われる。

　ちなみにWPS 3とWPS 2.0を組み合わせた環境でカバーされるのは、あくまで個人宅やオフィスなど、ある意味閉じた環境でのものであり、公衆無線LANをはじめとしたオープンネットワーク環境下ではあまり意味がない。こうした環境に向け、Wi-Fi Allianceは2018年6月に「Wi-Fi Certified Enhanced Open」を発表しているし、キャリア向けには「Wi-Fi Certified Passport」などの技術も提供されている。来週からは、このあたりを少し紹介したい。