Wi-Fi最初の暗号化規格「WEP」、当初の目論見は“有線LAN同等のセキュリティ”

　次のお題はセキュリティ関連。といっても複数の話題が含まれる。その基本を、まずは時系列に沿って進めていきたい。今回は「WEP」である。

無線通信では通信の秘匿化が必要に

　元々、Wi-Fiの最初の規格である「IEEE 802.11-1999」の策定作業を行っている最中から、通信の秘匿化が必要であるという認識がWGの中にあったのは間違いない。というのは、何しろ無線であるから、暗号化も何もせずに通信を行ったら傍受し放題で、その気になれば、その改ざんも容易である。

　これをさすがに放置するのはまずい、ということで、通信の暗号化を施そうという判断は、早い時期に下されることになった。

　ただ、1997年当時のプロセッサの性能、特にアクセスポイントやクライアントのWi-Fiコントローラーに搭載されるMCUの性能は、それほど高くなかったため、あまり強固な暗号化を施そうとすると、ボトルネックになる恐れがある。

　最終的に、暗号化の方式が“WEP（Wired Equivalent Privacy：有線と同等の秘匿性）”という名前になったのは、当時想定されていた技術レベルを利用すれば、有線接続と同等レベルのセキュリティが保証できる、という見通しに基づいたものである。

「RC4」で“有線LANと同等”のセキュリティを実現？

　話がそれるが、ここで言う有線（Wired）とは、IEEE 802.3、つまりEthernetのことである。この当時、すでに100BASE-TXが普及を始めていて、Point-to-Pointの接続であれば建前上は傍受は不可能だった。

　ただ、実際には、1台のリピーターハブを間に噛ませば、パケットの傍受をやり放題だったし、パケット自体の暗号化もなされていなかった。要するに有線がセキュアというのは、「物理的に隔絶すれば安全」という以上の意味ではなく、現実問題として安全でないことも珍しくはなかった。その意味であれば、WEPがEthernetと同等レベルで安全（＝しばしば安全ではない）というのは、それほど間違っていない気がする。

　話を戻すと、暗号化方式としてWEPで用いられることになったのは、RSA SecurityのRon Rivest氏によって1987年に開発された「RC4（Rivest Cipher 4）」と呼ばれるものだ。分類としては、一定サイズのブロック単位で暗号化処理を行うのではなく、流れてくるデータを逐次、暗号化処理して送り出す方式である「ストリーム暗号」となる。

　細かくは説明しないが、基本的には、送信側と受信側が同じ鍵を持っていることを前提に、送信側は鍵を使ってデータを暗号化し、受信側は受け取った暗号化されているデータを鍵を使って復号化する「共有鍵暗号」を用いる。

　RC4の場合、鍵は当初128bit長が想定されていたが、最初に標準化されたときには64bit長のみが利用され、128bit長は後から追加するオプションの扱いとなった。これは、128bit長の鍵の利用が、米国の暗号に関する輸出規定「The United States Munitions List」で制限されていたためである。

　要するに、鍵の解読に時間が掛かる強固な暗号化方式は、相当な部分が米国の軍事機密に該当するため、輸出するものに利用してはいけないとされているわけだ。この輸出規定は定期的に改訂されており、暗号化に関しても2000年代に128bit鍵の利用が解禁になったため、以後は、128bitの鍵を利用したWEPが利用可能になっている。

RC4の共有鍵暗号は64bitあるいは128bit

　さて、その鍵が64bitあるいは128bitというのは、RC4の暗号／復号に必要な鍵の全長を指しており、実際には24bitの「IV（Initialization Vector：初期化ベクター）」と、40bitまたは104bitの任意の値の「WEP Key」から構成される。このうちIVについては、WEP Keyを基に生成される疑似乱数が利用される。

　具体的に暗号化を行う仕組みが以下の図だ。まず、元データから「ICV（Integrity Check Value）」を計算する。これは要するにチェックサムであり、CRC-32が利用される。一方、鍵の方は、あらかじめ用意されたWEPキーを利用してIVを生成する。このIV＋WEPキーをRC4で暗号化してKey Streamを生成する。そしてKey Streamと元のデータの間でXORを取ることで、暗号化されたデータができるというわけだ。この暗号化されたデータの先頭にIV、末尾にICVを付加すれば、暗号化パケットの完成である。

　実際には、暗号化パケットの構造は以下のようになっている。IVが32bit分用意されているが、このうち、実際にIVが格納されているのは先頭の24bit分のみとなる。続く6bitのPadはPaddingで、単に0が埋められている。最後のKey IDはどの鍵を使うかを示すIDである。

サイズはOctet（8bit）を単位としている。出典は「IEEE 802.11-2012("Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications")」

　IEEE 802.11b時代にアクセスポイントやクライアントを使ったことがあれば、鍵の入力フィールドが4つ用意されていたことを覚えているかもしれない。「どの鍵を使ったか」が、このフィールドに収められ、複数のWEPキーを切り替えて使う実装の場合に、このフィールドが役に立つと考えられたわけだ。ただ実際には、そうした実装を行った例を筆者は見たことはない。

　次に、受信側は、まず受け取ったパケットからIVを取り出し、自分の持っているWEPキーと組み合わせてRC4の暗号化を行い、やはりKey Streamを生成する。このKey Streamと暗号化データをXORすることで、元のデータが復元される。ここで復元したデータに対してCRC-32を計算し、ICVと一致していれば、問題ないと判断されるわけだ。

　なお、WEPキーは本当にどんな値でもよいため、任意の文字列を入力されるパターンが多かった。英数字（0～9、A～Z、a～z）ならば、40bit WEPキーだと5文字、104bit WEPキーでも13文字で足りる。ただ、初期の製品には任意の16進の数字（0～F）のものもあり、こちらは10桁ないし26桁が必要で、入力はやや苦痛ではあった。

　当時は、64bit鍵、つまりWEPキーが40bitだとやや脆弱だが、128bit鍵でWEPキーが104bitなら十分強固である、と判断されていた。この判断が誤りだったのは、後で分かることになるが、その話はまた機会を改めよう。

認証メカニズムは「オープンシステム認証」と「共通鍵認証」

　ちなみに、このWEPキーを使った暗号化通信を利用するにあたって、認証を行う方法についても定められた。要するに、クライアントがあるアクセスポイントと通信しようとする場合（インフラストラクチャモード）や、クライアント同士で通信しようとする場合（アドホックモード）に、そもそも接続要求を受け入れていいかどうかを判断する仕組みを入れようというものだ。

　この認証のメカニズムとしては、「オープンシステム認証（Open System Authentication）」と「共通鍵認証（Shared Key Authentication）」の2つが用意された。オープンシステム認証は、実際には何もしていない。例えばインフラストラクチャモードの場合、SSIDが分かっていれば、クライアントはそのアクセスポイントにいつでもパケットを送ることができる。

　ただし、WEPを使っている場合、アクセスポイントはパケットがそのWEPキーを利用して暗号化されているという前提で復号化を行うが、WEPキーを知らないクライアントは当然暗号化ができない、あるいは適当なWEPキーで暗号化しているため、復号後にICVを確認すると全く異なる値となり、そのパケットは破棄されることになる。結果として、WEPキーで認証が成立しているということになる。

　一方、共通鍵認証の場合は、以下のシーケンスを経て認証を完了することになる。

1. クライアントがアクセスポイントに認証要求を送信
2. アクセスポイントはクライアントに「Challange Text」と呼ばれる文章を返信
3. クライアントはChallange TextをWEPキーを利用して暗号化し、アクセスポイントに再度送信
4. アクセスポイントは返信された暗号化データを、自身の持つWEPキーで復号化し、元のChallange Textと一致していることを確認

　ただ、この場合、2.でChallange Textを（暗号化せずに）平文で送り、3.でこれを暗号化した結果を返していることになるので、傍受している側からすれば、WEPキーの手がかりを簡単に手に入れられることになる。そのくらいなら、まだオープンシステム認証の方がマシということで、IEEE 802.11には現在も共通鍵認証の仕様が残されているものの、使わないことを強く推奨されている。というか実際には、WEP自体の使用がすでに推奨されていないわけだが。