運用WEP暗号化の基礎と実践7.おわりに 井上孝司 |
||
マルチベンダ環境における互換性問題
筆者の手元には、Wi-Fiに対応したメルコ社製WLI-PCM-L11Gのほかに、Wi-Fi非対応の富士通製のFWL11CARDというカードもある。同じIBM社製アクセス・ポイントを通信相手に指定してWindows 2000でWEPの設定を行ったところ、メルコ製品はASCII文字列でキーを指定するだけで通信できたのに対し、富士通製品では16進数値でキーを指定しないと通信ができなかった。もともとWi-Fi非対応製品で、他社製品との相互接続も保証されていないため、ベンダを責めることはできないが、実際にこのようなケースがあったということで付記しておく。
このように、異なるメーカーの製品同士でWEP暗号化通信を試みると、通信不可能なケースが発生する可能性は否定できない。無用なトラブルを回避するには、同じベンダの製品で統一するのが無難だろう。
キー生成はだれの仕事? |
WEPはどれだけ頼りになるか?
もちろん何も暗号化しない状態で利用しているのに比べれば、たとえキー長の短い40bit(64bit)WEPでも、まったく使わないよりは、使っている方が安全性は高いといえる。また、MACアドレスによるアクセス制限を併用し、さらにクライアントからのSSID検索を不可能にしておけば、さらに安全性は向上する。この3つのセキュリティ関連機能は、互いに競合するわけではなく、むしろ補完的な関係にあるので、すべての対策を実行するように心がけておきたい。
ただし、WEPには当初から脆弱性を指摘する声がある。
真っ先に問題になるのが、ユーザーが指定するASCII文字列の内容だ。ASCII文字列として、英和辞典に載っているような平易な単語をそのまま使用した場合、総当たり攻撃で破られる危険性がある。特に40bit(64bit)WEPの場合、使用可能な文字数が5文字と短いので、この範囲内で「大文字+小文字+数字+記号」というような、破られにくい文字列を考え出すのは、正直な話、困難といわざるを得ない。
その点、104bit(128bit)WEPの場合は13文字使用できるので、文字列の指定にも自由度が高くなる。そのため、単にキー長が長いという以上に、安全性の面で有利になる。
なおこうした問題に対処するため、現在開発中のWEP2では、キーとなるASCII文字列とIV(初期化ベクタ)が、それぞれ128bitの長さを持つことになっている。また、米RSAセキュリティ社も、この問題を解決するためにIEEE802.11委員会メンバーと共同開発した「Fast Packet Keying」を発表している(この件に関するRSAセキュリティ社の文書はこちら)。
このように、現行のWEPは安全性の面でパーフェクトとはいえない部分があるので、無線LANにより高い安全性を求めるなら、WEP以外のセキュリティ対策を併用したり、キー生成用の文字列を定期的に変更したりするなどの対策をとる必要があるだろう。
関連リンク | |
Fast Packet Keyingに関する文書 |
運用 |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|