無線LANで使われる暗号プロトコルには複数の手法がありますが、以前から脆弱性が広く知られる WEP [2, Sec. 8.2.1] の他、一般に WPA (TKIP) と呼ばれるプロトコルについての脆弱性も 2004 年頃から指摘されています [5]。 2008 年には Beck ら [1] により15分程度での改竄防止鍵の推測およびパケットの限定的な改竄手法が報告された他、 2009 年 8 月にはこの攻撃についての新たな考察が報告されています [6]。 今回のレポートは、これらの攻撃の影響について解析し、具体的な影響範囲と対策手段について検討したものです。検討結果の概要は次の通りです。
暗号化アルゴリズム | |||
---|---|---|---|
WPA の版 | TKIP | AES | (参考)別の呼称 |
WPA | 要対策 | ◎ | WPA-PSK |
WPA2 | 要対策 | ◎ | WPA2-PSK, RSNA, 802.11i |
鍵更新間隔 | ||
---|---|---|
QoS 機能 | 2分程度に短縮 | 通常 |
あり | ○ | ▲ |
なし | ○ | △ |
文献 [1] や [6] による攻撃に対し、WPA (TKIP), WPA2 (TKIP) の組合せはどちらも脆弱であると考えられます。 一方、現時点で WPA (AES) および WPA2 (AES) に対して、これらの攻撃は適用できず、有効な改良手法もまだ報告されていません (表1)。
攻撃の現実性については、文献 [1] の攻撃のうちの1つ については、ネットワーク機器が特定の機能(QoS=通信ごとの優先度設定)を有する場合、 単純なネットワーク盗聴で攻撃が可能なため、現実の脅威があるものと考えられます。 この攻撃については、既に攻撃ツールが公開されています。 一方、文献 [1] のもう1つの攻撃と、文献 [6] の攻撃については、 実際の攻撃として成立するためには、無線LANの通信を能動的に妨害する必要があり、 たとえ攻撃に必要なツールを入手した場合でも、現実の多くの無線LAN導入環境においては攻撃の可能性は比較的低いと考えられます (表2)。
これらの攻撃が成功した場合には、WEP だけでなく TKIP 暗号プロトコルを用いた通信についても、 一部のネットワークパケットの偽造が可能になります。但し、攻撃可能なパケットについては厳しい制約があるため、 任意のパケットを偽造することは出来ません。 これにより考えられる最大の脅威としては、ネットワークに設置されたアクセス制限機器を回避し、 外部から無線LANに接続したPC等への接続などができる可能性があります。
以上の解析結果から、本稿では可能であれば、無線LANアクセスポイントについて WPA (AES) または WPA2 (AES) への設定変更を行なうことを推奨します。
一方、TKIP が利用可能であるが AES への移行が困難である場合であっても、 アクセスポイントに鍵更新間隔の設定機能がある場合には、120秒(2分)などの短い値に設定を変更することで、 文献で指摘される攻撃を回避することが可能です。やむをえず TKIP を利用する場合、この設定変更を推奨します。 但し、本設定値を短くすることで、アクセスポイントの負荷が上がることが予想されます。 導入に際しては事前にテストを行なうことをお薦めします。
また QoS 機能が運用上重要でない場合、アクセスポイント、クライアントの両方に QoS の機能の有効・無効を 設定できる機能がある場合には、この機能を「利用しない」設定にすることでも、攻撃の現実性を大きく下げることが出来ます。 このような対策がどちらも取れない場合には、本稿の以下の記述などを参考に、実際の運用環境における攻撃可能性とリスクを検討してください。 検討の結果必要であれば、AES 対応機器への移行か、下記のような運用上の対策を取ることをお薦めします。
また、TKIP 以前の規格である WEP を使っている場合も、本稿で指摘される脆弱性の他にもたくさんの脆弱性が 指摘されており、WEP の通信は事実上常に盗聴・侵入の危険に晒されていると想定されます。 現実的にパケットの解読が可能になる可能性があることから、早急に AES(やむを得ない場合は TKIP)への移行を推奨します。 但し、移行に際しては、WPA および WPA2 ではアクセスポイント1台当たりの接続数の 上限が少なくかつ厳密になっていることがあります。特に家庭用のアクセスポイントでは、10台程度のクライアントしか 接続ができない場合もあります。これは、WEP ではアクセスポイントは1つの暗号鍵で全てのクライアントと通信していたのに対し、 WPA および WPA2 では接続したクライアント台数分の暗号鍵を常に保持し管理しなければならないためです。 そのため、特に10台以上のクライアントを接続する可能性のある無線LANでは、機種選定に注意が必要です。 移行が出来ない場合、以下のような運用上の対策を施すことを強く推奨します。
なお、上記の問題その他により WEP の利用を廃止できない場合や、TKIP を利用するに当たりリスクを否定できない場合には、 一般論としてリスクを軽減するために次のような運用上の対策を施すことが考えられます。
なお、本稿の結果を実際の無線LANシステムに適用するに当たっては、以下の点に留意して下さい。
本稿の一般向けの情報は以上です。以下では解析の詳細について、第2節でこれらの技術の概要を、 第3節で報告されている攻撃手法を、 第4節で CCMP への適用可能性を、第5節で WPA と WPA2 の差異および攻撃の適用可能性について報告します。 第6節では、WPA ネットワークの運用上の留意点として、パスフレーズの強度について述べます。
WPA (Wi-fi Protected Access) および WPA2 は、 無線LAN機器ベンダの業界団体である Wi-fi Alliance が定めた無線LANのセキュリティ機能の名称です。 2001年頃、それまで使われていた WEP というセキュリティプロトコルの弱点が次々と報告され、 セキュリティに問題があるとの認識が広まったため、 無線LANの技術標準を定める IEEE の 802.11 委員会で、 新しいセキュリティ規格拡張 802.11i の検討が始まりました。 一方で、標準規格の策定には時間がかかるため、 Wi-fi Alliance は検討中の規格の第3原案を元に、 暫定的な業界規格として WPA を策定しました。 802.11i 規格拡張はその後 2004 年に正式規格となり、 業界規格としても WPA2 として採り入れられました。 本規格拡張は 2007 年の 802.11 規格の改訂に伴い、 802.11 規格の本体に取り込まれています。
802.11i の原案の段階で、WEP に変わる新しい暗号アルゴリズムとしては2つの手法が提案されていました。 1つは「TKIP (Temporary Key Integrity Protocol)」、もう1つは「CCMP (CTR with CBC-MAC Protocol)」と 呼ばれるものです。TKIP は、これまでの無線LAN機器の多くにハードウェアとして組み込まれていた WEP のための 回路を最大限に流用し、可能な限りソフトウェアの変更だけで対応できるように設計されたものです。 一方、CCMP は最新の標準暗号プリミティブであり暗号強度に優れたAESを取り入れたほかにも、 WEP の古いやり方にとらわれず、暗号化の処理方法を1から再設計したものになっています。 なお、CCMP はその利用プロトコルの名前から、現在一般に市販されている機器の設定項目などでは 通常「AES」と表記されています。
ちなみに、WPA の時点では TKIP の実装は必須である一方、CCMP の実装は任意となっていました。つまり、 TKIP にのみ対応した機器も、「WPA 対応」という触れ書きで販売することができるようになっていました。 一方、「WPA2 対応」機器と名乗るためには、CCMP も実装することが必須になっています。 そのため、一部には「WPA = TKIP、WPA2 = AES」とか、「WPA では AES は使えない」とかいった誤解が あるようです。実際には、WPA の時点でも両方のアルゴリズムが定義されていました。 また、WPA2 で TKIP をサポートした機器も存在します。
本節では、[1] で報告されている脆弱性について、技術的な概要を述べ、また [6] との関係について触れます。
2008年 [1] で報告された WPA (TKIP) の問題は、2004年に [4] で指摘された WEP への 攻撃手法が元になっています。この「chopchop 攻撃」と呼ばれる攻撃は、 WEP に指摘される多くの他のセキュリティ脆弱性と異なり、 RC4 の弱鍵に関係した性質には必ずしも依存しないものになっています。
WEP 暗号化を用いた無線LANのパケットは、[図 2] のような構造になっています。 この図で ICV の部分には、Data 部分の書き換えを検知するために、CRC-32 関数で計算した Data のチェックサム(4バイト)が格納され、 Data と ICV の両方を合わせた全体が RC4 で暗号化されています。 暗号化処理の概要図を [図 3] に示します。 ここで、RC4 に代表されるストリーム暗号に一般的な性質として、
があります。一方で、CRC-32 を元データの直後に繋げているというこのデータ構造では、 CRC-32 関数の代数的な性質 [1, p. 82] から、もしこの ICV の部分の 末尾1バイトが分かっていれば、このデータから1文字を削ったデータに適当な文字列を XOR することで、 その削ったデータを再び「1文字少ない Data + そのデータの正しい CRC-32」という形に変形することが可能です。 この RC4 および CRC の両方の性質から、もし元の暗号化前の ICV の末尾1文字が分かれば、それを元に1文字短い別の 暗号文をつくって、暗号を復号した後のチェックサムを一致させることができることになります。
Chopchop アタックでは、この性質を逆に使って攻撃を行ないます。 傍受した WEP 暗号化済みパケットについて、暗号化前の ICV の最後の1バイトについては256通りの可能性がありますが、 その1つずつについて上記の変形を順番に試してアクセスポイント (AP) に送信してみる、ということを行ないます。 AP は不正なチェックサムを持つ WEP パケットを受信するとエラーを通知するパケットを返すので、 この通知パケットを監視して応答のなかったパケットを探すことで、 最初に256通り想定した「ICV の平文の最後の1バイト」のどれが正しかったかどうかを判断できます。 これを順に繰り返せば、後ろから1バイトずつ「Data + ICV」の部分の平文が判明しますので、 Data の末尾部分についても、平文の解読がある程度可能になります。
一方で、TKIP の場合の暗号化パケットの構成を [図 5] に、 暗号化処理の概要図を [図 6] に示します。 前節で述べた通り TKIP は WEP の実装を最大限利用できるように設計されているため、 このパケットの Data から ICV の部分は、処理図右端で「WEP Encapsulation」 と書かれた部分で WEP と全く同じ方法で暗号化されています。 但し、WEP と異なるのは、
という点です。末尾の ICV は、「MIC」も含んだデータに対する CRC-32 のチェックサムになっています。
しかしながら、基本的な暗号化のやりかた自体は WEP と同じですから、 同じような手法でパケットの末尾の ICV から1文字ずつ推測していく攻撃は、 この WPA (TKIP) でも適応可能です。 TKIP では ICV 不一致のエラーに対しては通知が行なわれませんが、 chopchop 攻撃で1文字短縮したパケットでは ICV は正しくても MIC は通常一致しないため、 クライアントから AP へ MIC 不一致のエラーが報告されることを利用して攻撃を行ないます。
ただ、WPA の設計段階で TKIP がセキュリティ上完全でないことは既に意識されており、 攻撃をさらに難しくする要素が2つ追加されています [2, Sec. 8.3.2.4, pp. 171-180]。
このため、通信盗聴したパケットで WEP と同じように chopchop 攻撃を行なっても、 既に攻撃に使う暗号文と同じ IV のパケットが既に受信済みのため 1. の制限で受信を拒否され、攻撃が成功しません。 また、この問題を回避できればICVの末尾1文字目の解読はできますが、 1分以内に2文字目の解読を行なうと、1分以内の2回の MIC 不一致エラーのため 2. の制限で自動的に接続が切断され、「マスターキー」を交換されて攻撃が失敗してしまいます。
文献 [1] では、1. の対策として、パケットに優先順位を付けられる QoS の機能を利用しています。 TKIP では IV カウンタを優先度毎に持っていることから、 ある優先度で盗聴したパケットを別の優先度で攻撃に使うことで、 この制限を回避しています。また、2. については攻撃速度を1文字当たり1分に制限することで回避していますが、 このために攻撃に必要な程度までパケットを解読するのに12分程度を要します。
また、QoS 機能が実装されていない場合においても、無線環境を改変でき、 本来のAPとクライアントの間でパケットが直接届かず、かつ攻撃者とAP、攻撃者とクライアントの間では パケットが到達する状況を作り、かつ10分ほどの無通信時間を許容すれば、 同様の攻撃が実現できる可能性を指摘しています [1, p. 84]。
一方で、Michael は設計自体に問題があり、一旦平文とそれに対応する MIC が分かってしまえば、 元になった鍵(MIC 鍵)が簡単に計算できてしまうことが [1, p. 84] 等で指摘されています。 そのため、一旦 chopchop アタックでパケットの平文と MIC を解読すれば、 パケットの改竄は比較的容易にできる(改竄後のデータに対する正しいMIC値が計算できてしまう)ことになります。 一旦 MIC 鍵を入手した後は、特定の暗号文の盗聴と最短約4分ほどの解析によって、 最大7パケット(QoS を用いない場合は1パケット)の改竄したパケットを生成することができます。
まず、攻撃の可能性については、QoS 機能が無線LANで有効に設定されている場合(シナリオ1)、本攻撃の仮定は十分に現実的であり、 現実的な時間と可能性において Michael の改竄検知鍵が解読されると考えられます。 また、攻撃中もクライアントの通常の通信は平常通りに可能であり、攻撃が覚知される可能性も低いと考えられます。 これらの攻撃に必要な技術も既に2008年の段階でツールが公開されており、入手可能です。
一方で、シナリオ2については、PC とアクセスポイントの間の通信を傍受・中継するだけでなく、 空中波によるPC・アクセスポイント間の通信を妨害する必要があります。 一般に WPA が必要とされる職場のような環境では、無線APとクライアントの間に見通しが取れることが 多く、そのような状況で盗聴だけでなく直接通信を妨害することは、可能性を否定できないものの相当な困難が伴うことと 思われます。一方、Michael 鍵を入手するための10分程度の通信断絶時間については、 攻撃にユーザに気付く可能性が高くなるものの、攻撃の可能性を否定するほどには至らないと考えます。
一方、攻撃に伴うリスクについては、本攻撃で解読される鍵はMichael の改竄検知鍵だけであり、 暗号化鍵は入手できないため、攻撃に成功しても一般の盗聴したパケットを直ちに解読できるようにはなりません。 また、解読可能なパケットはある程度予測可能である必要があり、 改竄対象も限定的になります。
本攻撃が成功した場合に発生する実際上のリスクについて、 文献で述べられているもののうち最も脅威のあるものは、一方向性ファイヤウォールの回避 [1, p. 84] であると考えられます。 ファイヤウォール装置のうち外部からの不正な通信のみを排除し 内部から外部方向の通信を遮断しないものは、通信パケットの内容を検査し、 内→外方向のパケットと、それに対する外→中方向の応答のみを通過させるようになっています [図 9]。 このようなネットワークに接続要求パケットを偽装して注入すると、 1パケットのみの偽装で TCP/IP の双方向通信を外→内方向に確立させることができる可能性があります [図 10]。 この攻撃は、通信接続の追跡をしないもの(stateless firewall)については成立するものと思われます。 一方、接続の追跡をしているもの(stateful firewall)や NAT の機能を有する物については、 攻撃の可否はその実装に依存します。とりわけ、内部から外部方向のパケットについての状態追跡失敗に 比較的寛容なものについては攻撃が可能です。
本攻撃に対する対抗策として、[1] の 5.1 節では TKIP の代わりに CCMP を用いることの他に、 2つの暫定的な対策を提示しています。 1つ目は MIC 不一致エラーの通知パケットの送出を止めることで、解読の手がかりとなる応答を無くすことができますが、 クライアント側の無線LANのファームウェア・ドライバの改造を要します。 2つ目は、TKIP を用いる際の WPA の鍵更新間隔を120秒程度に短くすることを提案しています。 これにより、Michael の解読が成功する前に鍵の更新が行なわれることを保証できるため、攻撃が難しくなります。 やむを得ず TKIP を用いる場合で鍵更新間隔の設定を 変更できる場合には、この変更を施しておくことが推奨されます。 ただし、本変更によりアクセスポイントの負荷が重くなり、 特にクライアントが多数存在するネットワークでは負荷が不安定になる可能性がありますので、 設定の際は留意が必要です。
なお、文献 [1] でも述べられていますが、本攻撃手法の攻撃の容易さは、 それぞれのクライアントおよびAPの実装に依存します。 特に、TKIP 規格で要求されている「2回の MIC 不一致に関する通信断絶処理」が AP またはクライアントに 正しく実装されていない場合、攻撃に必要な時間がどちらのシナリオでも1分以下になり、 攻撃がかなり現実的になることが予想されます。
文献 [6] で報告されている攻撃は、基本的には [1] と同一の攻撃です。 このうち、無線環境の想定の変更については、[1] での第2の想定シナリオと同一と考えられます。
[6] での新たな主張として、3.2 節で述べた WPA での追加要素 2. に対する対策として、 全通信を攻撃者が中継している状況では攻撃のタイミングを攻撃者が自由に設定できるので、 まずはパケットの中継を行ないながらネットワークを監視し、 うまく重要な通信のないタイミングを見計らって10分程度中継を止めて攻撃を仕掛ければ、 ユーザの通信に対する影響を押えつつ解読が可能になるとしています。
パケットの改竄については、解読するパケットのもつ平文の可能性が高々256個程度に限定できる状況では、 chopchop アタックで1文字削って ICV の最後の1文字を入手すれば、あとは推測したパケットの ICV と比較してやることで 「ある程度の確率で正しいパケット」を当てられるので、改竄時の通信断絶を(4分から)最短数秒にできる、という主張です。 具体的な対象としては、アドレス範囲が既知の IP ネットワークにおける ARP パケットが想定されています。
この論文で置いている数々の仮定については、その実運用環境での妥当性については状況により判断が分かれるものと思われます。 まず、無線環境の想定については 3.2.1 節で述べた通り、 無線環境での直接通信の妨害は、可能性を否定できないものの相当な困難が伴うことと思われます。 次に、鍵解読のための10分程度の通信断絶時間については、 論文中の「通信が再開された際に攻撃が発覚しないために鍵探索を中断する」部分については疑問が残ります (10分程度の断絶後のTCP通信はARP問い合わせから発生するため、通常のARPだけの断絶させてもいい通信との区別には困難がある)が、 通常のPC利用でも無線LANの接続が継続している状態での10分程度の未使用時間は十分あり得るため、 現実に起こる可能性を完全に否定するには至りませんでした。 最後の攻撃時間の削減については、1バイトで推定可能な攻撃対象パケットが [1] と比較して更に限定され、 事実上 ARP パケットに限定されます(他のパケット、たとえば DNS とか TCP SYN などでは数バイトの推測不可能データがある)が、 これを利用した攻撃については著しく大きな影響はないと考えられます。
以上の点から、文献 [6] で提示された脆弱性は、現実の無線LANの常用環境での 攻撃は比較的困難であり、直ちに実用環境でのデータの盗聴などの深刻な被害の蔓延は予想されないものの、 文献 [1] の攻撃が存在することからも、 現時点で WPA (TKIP) (および WPA2 (TKIP)) を用いている環境では AES への設定変更を行なうことを本稿では推奨します。
なお、本報告 [6] で短縮されたとされている攻撃時間はパケットの改竄攻撃にかかる時間であり、 その前段階で必要となる MIC 鍵の解読には、依然として10分以上の時間を要しています。 そのため、3.2.2 節で触れた文献 [1] の鍵更新間隔変更による対抗策は、 この報告における攻撃にも有効であると考えられます。 また、想定される脅威、実装欠陥がある場合に起こる危険性の増大についても、 3.2.1 節(シナリオ2)と同様の結論が導き出されます。
本節では、特に [2, Sec. 8.8.3.3] で定義される CCMP、いわゆる「WPA2 (AES)」について、 前節と同様の手段による攻撃可能性を検証します。
CCMP で用いられるパケットのフォーマットを [図 11] に、暗号化処理の概要図を [図 12] に 示します。まずパケットの図で分かるのは、 TKIP では WEP からの互換性のために維持されていた ICV フィールドが削除されていることです。 また、処理図を前節のものと比較すると、WEP と共通のコンポーネントがほとんどなくなり、 1から暗号化の設計をやり直していることが分かります。
CCMP で用いられている「CCM encryption」の処理は、「Counter with CBC-MAC (CCM)」[7] という 暗号化プロトコルに、128 bit 鍵の AES 暗号化、2バイトのパケット長、8バイトのMAC長をそれぞれ適用したものです。 この暗号化プロトコルについては、一定の仮定の元での安全性の証明が行なわれており、その詳細は [3] に 記載されています。
前節の攻撃は全て、ICV において暗号文中で改竄検知に本来適していない CRC-32 を用いており、 しかもその使い方がたまたま CRC の代数的性質とマッチしていて、 直接 CRC 値を求めずとも1文字短縮というデータ改変をする方法があったこと、 更にそのデータ改変に求められる処理の性質が、RC4 をはじめとする単純なストリーム暗号に 共通する性質の全てにたまたまマッチしていることなど、「運のいい(悪い?)」要素が多分に含まれています。 一方で、CCMP にこれらの要素の多くが含まれていないことも確認できます。
このことと文献 [3] の証明から、少なくとも現時点で文献 [1] 等で指摘されている方法およびその些少な改良では、802.11 の CCMP 暗号化 (WPA2 (AES)) に対しては攻撃が成功しない、と結論づけることができます。
最後にこの節では、前2節で取り上げなかった残り2つの組合せ、WPA2 (TKIP), WPA (AES) に対する検討と、 「TKIP/AES 両対応モード」について検討します。
まず、IEEE 802.11-2007 規格に含まれる TKIP 仕様、いわゆる WPA2 (TKIP) [2, Sec. 8.3.2] については、 その仕様書から詳細な仕様について確認することができます。その結果、第3節で述べたような WPA (TKIP) に関する 性質には設計上の変更はなく、全く同じ攻撃が可能であることが確認できました。
一方、WPA (AES) については、WPA2 と異なり一般に仕様書が公開されていないことから、 文献調査には困難があります。TKIP と CCMP の基本的な部分については変更がないことは ほぼ判っていたことから、第3節の攻撃自体が4節同様不可能であることは確信があったものの、 鍵生成部分など他の部分について、差異がある可能性が否定できませんでした。 元となった 802.11i draft 3 の仕様書からの検討も考慮しましたが、 その暫定仕様から業界規格への間に変更点がある可能性も否定できないことから、 今回は両プロトコルを実装している Linux の wpa_supplicant のソースを解析し、 差異について検討しました。
この解析の過程で判明した、WPA → WPA2 (802.11i) での主な変更点は次の通りでした。
これらの変更点について、むしろ WPA2 で新たにセキュリティ検討が必要な変更点 (2., 4. など) がいくつかあるものの、 WPA から WPA2 でセキュリティ上強化のために変更された可能性があるのは 7. のみであり、 7. も通常のAPの実装では問題が生じるとは考え難く、更に少なくとも WPA (AES) 単独で運用する際には 全く問題にならない (後述) ため、WPA2 (AES) が安全と仮定できる状況では WPA (AES) も同様に安全と仮定できます。
最後に、「TKIP/AES 両対応モード」について、一部の AP には AES と TKIP の両方のクライアントが 同時に接続できる機能がサポートされています。 このうち、少なくとも 1つの PSK、1つの SSID のみを設定して用いるモードは、第3節の攻撃の影響を 受ける可能性があります。これは、WPA の用いる通信鍵に、各クライアント毎に生成する 「個別鍵」と。全クライアントで共通して用い、APからのブロードキャストパケットなどの暗号化に 用いる「グループ鍵」が存在することによります。通常の TKIP モードや AES モードでは、 個別鍵とグループ鍵は同じ暗号化手法(TKIPかCCMP)を用いますが、 この併用モードでは CCMP をサポートしているクライアントとは CCMP で通信しつつ、ブロードキャストパケットは TKIP 利用者にも CCMP 利用者にも届ける必要があるため、 「個別鍵に CCMP、グループ鍵はTKIP」という形で利用されます ([図 13])(ちなみに逆は意味がないので認められていない)。 このため、あるクライアントについて個別鍵が CCMP になっていても、 AP からのブロードキャストパケットが TKIP で送信され、攻撃の対象となる可能性があります。 そのため、今回の攻撃に対する対策として CCMP への移行を行なう場合、AP 側の設定は「CCMP(AES)固定」にすることが必要です。
ちなみに、7. の変更点は、グループ鍵が TKIP で、個別鍵が AES の時に、グループ鍵を送るための暗号化方式が AES でも RC4 でもよかったとも解釈できたのが、WPA2 では明確に AES に限定された、というものです (see wpa_supplicant-0.6.9, src/rsn_supp/wpa.c:1505)。もともと RC4 暗号化のための鍵なので、セキュリティ強度上の問題はありませんし、本稿で推奨する AES 固定モードでは影響がありません。
なお、WPA および WPA2 のプロトコルのうち、通常の環境で用いられることの多い事前共有鍵(PSK)のパスフレーズを用いる設定 (WPA-PSK, WPA2-PSK) に おいては、事前共有鍵が十分に予測不可能であることが必要です。WPA の通信確立に用いられる鍵交換プロトコルにおいて、 まずパスフレーズは AP、クライアントの双方でハッシュ関数 [2, Sec. H.4.1] を用いて事前共有鍵に変換されます。 その上で、アクセスポイントとクライアントはいくつかの値 (Nonce) を平文通信で交換し、 それらの値と事前共有鍵からハッシュ関数を用いて通信鍵を導出します [2, p. 198]。 そのため、パスフレーズの候補を(辞書などを用いて)事前に絞り込むことが出来る場合、 鍵交換通信のパケットを盗聴し、有り得るパスフレーズの可能性の全てについて鍵を計算し通信内容と照合することで、 パスフレーズと通信鍵を取得し暗号通信パケットの盗聴・改竄を行なうことが可能になります。
この問題を避けるためには、パスフレーズは十分に予測不可能なものである必要があります。本稿では最低20文字以上で、 第3者に推測が不可能な文字列を設定することを推奨します。