最新 追記

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 982   昨日: 2734

2009年09月19日

ドワンゴ勉強会でお話ししたこと

8月28日の夕刻、ドワンゴ主催の「技術勉強会」にお招き頂き、少しお話をしてきた。テーマは「P2Pネットワーク」。もしもニコニコ動画をP2P方式で配信する(回線コスト軽減のため)としたらというテーマが暗に想定されているようだったので、それに沿ってお話しした。講演者は他に、金子勇氏と、NTTの亀井聡氏、P2P型掲示板「新月」の開発者でドワンゴ社研究開発部の福冨諭氏ほか。

私からお話ししたのは主に以下の2点。

  1. そもそもなぜP2Pにするのか。手段が目的になってしまってはいけない。
  2. 利用者のプライバシーを確保する設計の必要性と可能性。

1点目は、以前からあちこちで話してきたことで、そもそも「P2P」とは何かというときに、peer-to-peer方式のネットワークという元来の意味に立ち返れば、decentralizedな構成にできて、ad hocに構成できるといった性質が技術的特長となるわけだけども、そういうのは昔からあったわけで、この10年「P2P」と呼ばれるようになったものの新しい性質はといえば、ピアの管理主体が個人であることであって、その結果として出てきた特徴が、管理不能性の実現が可能となったことと、トラフィックの分散が商業的な運営主体を介さずに実現可能ということである。

ニコニコ動画の配信にあたっては、管理不能性は無用であるから、P2P化することの意義はトラフィックの分散という点に尽きる。トラフィックの分散化が本当に効率的に実現可能なのかというテーマについては、亀井さんから興味深い解説があった。私も質問したのだけども、日本の現状のISPの構造では、物理的な通信回線と論理的なインターネット回線が別事業者により提供されていることが多い関係上、行って戻ってくるという無駄なトラフィックが多く発生し、P2Pに向かない傾向があって、将来に向けて何か対策が求められるところと理解した。

2点目は、適切なプロトコルを設計すべしという話と、ポート番号を所定の番号にした方がよいという話をした。

金子さんの講演で、彼が現在開発に関わっているというコンテンツ配信システムで、通信プロトコルを暗号化しているとの話があったので、その暗号化は何のためのものかと質問したところ、難読化のためなのであまり意味はないがいちおう暗号化しているというような説明*1があった。

たしかに、Winny等の不特定多数向けのP2P型ファイル共有ソフトでは、通信の部分をいくら複雑な暗号アルゴリズムで処理しても、リバースエンジニアリングによってアルゴリズムと埋め込み鍵が判明してしまえば、その意味は無くなる。このことは金子勇著「Winnyの技術」p.151に書かれている通り*2である。しかし、それはすべてのP2P型システムに言えることではない。たとえば、Skypeでは適切な方式で暗号化して秘匿性や完全性が確保されているだろう。

管理サーバが存在する場合には、ピアのプログラムがリバースエンジニアリングされても破られないような制御方式を設計することが可能なはずである。ニコニコ動画の配信にあたっては、管理不能性は無用であるから、管理サーバをなくすことはもとより追求しないのであろうし、利用者は基本的にニコニコ動画のアカウントでユーザ認証した状態で使用するのであるから、管理サーバが持つ秘密情報に基づいて個々のピア間の通信を制御することで、プロトコルについての防御はさほど複雑な方法でなくとも可能だろう。

尤も、隣のピアが要求するファイルを自身のcacheから送信するという単純な仕組みにする場合、どのファイルが持って行かれているかは判別できてしまう。それをわかりにくくする工夫はいろいろあり得るだろうけども、効率は下がるだろうから、実際問題どこまでやる必要があるのかということになる。

隣のピアが自分と嗜好が近い人だということがある程度バレてしまうのはやむを得ないとするあたりが現実的な落とし所だとしても、クローラーのようなものが作られてピアが観測されてしまうようなプロトコルは避けておきたいところだろう。ニコニコ動画の場合では、コンテンツの転送以外の要求(検索やコメントの書き込み等)は直接サーバで処理すればよく、その部分をP2P方式にする必要性はないだろうし、ピア間通信のための制御情報も直接サーバからもらうようにすることもできるので、その懸念は簡単な方法で回避できるのではないか。

もし本当にニコニコ動画のP2P配信化が実現されるなら、ぜひこうした観点を踏まえて開発してほしい旨を伝えた。

ポート番号の話は、Winny等のように初期設定時にランダムに決定(し、ほぼ固定化)するポート番号を使うのではなく、決められたポート番号を全員が使うようにした方がよいという話をした。(外部からの接続待ち受けポートを必要とする設計とする場合には。)

Winnyでも初期のころは7743番で均一だった(金子氏から「最初は80番だった」というツッコミがあった)が、後にランダムに初期設定されるようになった。その目的が何だったのかは知らないが、ネットワーク上で勝手にポート単位で規制されるのを嫌がってのことであれば、ニコニコ動画の配信においては、あえて管理しにくくする必要がないはずだ*3。ポート番号が利用者ごとにバラバラになっていると、IPアドレスとポート番号の組によって個人が追跡される可能性が生じてくるので、そういうのは避けた方がよいという話をした。

適切なプロトコル設計によって秘匿性が実現されたとしても、IPアドレスとポート番号については、接続先のピアに知られてしまう。図1は、Skeype使用中の様子であるが、「netstat」コマンド等によって、自分のコンピュータの現在の接続先のIPアドレスとポート番号を知ることは誰にでもできる。

画面キャプチャ
図1: Skype使用中に「netstat」コマンドを実行した様子

これを繰り返して記録すれば、ある時刻におけるIPアドレスとポート番号の組を各個人が蓄積できるようになる。それぞれの人が蓄積できる量は少ないかもしれないが、もしニコニコ動画がP2P配信化されて、何百万人もの人々に常時使われるようになったとすると、集められる量はそれなりの量になるかもしれないし、各ユーザから蓄積データを買い取ってデータベース化する業者が現れることも考えられる*4

IPアドレスは時々変化するものであるから、ある時刻にAさんの家のものだったIPアドレスが、別の時刻にAさんの家のものだとは限らないわけで、本来、追跡性はブツブツに分断されたものとなるはずである。しかし、ポート番号が人それぞれに異なって設定されているようなP2P型通信プログラムが常時稼働するような状況では、IPアドレスとポート番号の組によって、分断されたものが1つに縫合されてしまう可能性が出てくる。

ポート番号の多様性は高々数万程度であるから、大きなISPでは同じISPで同じポートを使う人が数人程度いるかもしれないが、小さなISPだったり、あるいは、大きなISPでも地域毎にアドレス範囲が分けられていたりすると、ポート番号で個人が識別されることが起き得る。

こうした事態を避けるよう、P2P型のシステムの開発においては、ポート番号に配慮するべきだと思う。所定のポート番号に固定する方法の他にも、適当なタイミングで使用ポート番号を変える設計にすることが考えられるが、その場合は、NATのポートフォワーディング設定を利用者に変更させる手間をかけさせない方法にする必要があるだろう。Skypeでは、NATのポートフォワーディング設定を必要としない方式が採用されていて、ポート番号はおそらく毎回変えられているのだろう。

勉強会では言いそびれたが、適切なプロトコル設計で秘匿性を確保し、ポート番号にも配慮して追跡性を遮断したとしても、プロトコル設計が十分に適切でないと、通信を観測する(通信当事者が自分の通信を観測する)ことで、通信相手を識別できる何らかの固定値を得られてしまう事態も考えられる。その点にも配慮したプロトコル設計が求められると思うし、それは実現可能だと思う。

参考文献

*1 ただ、開発の詳細をすべて把握しているわけではないとの発言もあったので、本当にそうかは確認するまでわからないと考えた方がよさそう。

*2 次のように書かれている。

しかしWinnyの場合、通信相手は不特定であり、Winnyプロトコルを使う誰もが通信相手になれます。たとえば、Winnyプロトコルを真似てWinnyノードに接続するようなプログラムの作成ができれば、接続相手のキャッシュファイルを観察することも可能です。このため、たとえどんなに強い暗号方式で通信内容を暗号化したとしても、通信相手は解読可能であり、通信内容は隠しようがありません。

また、Winnyのキャッシュファイルは、そもそも公開されているデータと考えるべきです。

Winnyの技術, 金子勇, アスキー, 2005年

*3 むしろ企業内ネットワーク等で簡単に規制できる余地を残すためにも、ポート番号は決め打ちにして広く知らせた方がよいという面もあるだろう。

*4 現行の個人情報保護法では、IPアドレスや、IPアドレスとポート番号の組、さらには時刻と組み合わせた情報のいずれも、それら単体では同法の「個人情報」に該当しない。

本日のリンク元 TrackBack(0)

2009年09月23日

Nyzillaを改良

Nyzilla」をリリースに向けて改良。

画面キャプチャ
図1: Nyzilla作成中テスト画面(無作為に選んだ接続先でテストした際のもの)

ウィンドウひとつに接続先を1つと固定して、Winnyプロトコルで当該ノードだけに接続。応答メッセージから、当該ノードがソースとなっているキーを抽出して表示。1ホップ検索クエリ(当該ノードにしか届かない検索クエリ)を出して、特定のキーワードにマッチするキーの応答を求めることもできる。同時に、応答メッセージから他のノードのアドレスを集約して「他のノード」に表示。そこからノードを選んでダブルクリックすると別ウィンドウとして開く。ダウンロード機能はない。

今回初めてNetBeans IDEを使って開発してみた。Macでの見栄えもよい。しばらく見ないうちにものすごく使いやすくなっていた。GUIビルダなんて使い物になるのかなと思っていたけれど、1日でどうにか使えるようになった。国際化作業も簡単にできるし、JavaのエディタもEclipseよりも使いやすいような感じがした。JTableはほとんど自動で作れるような感じだけども、やりたいことをやるには、TableModelから作らないと駄目っぽい。ここで時間切れ。

関連:

  • Winnyの可視化と無断リンク禁止厨の共通関係に見る問題の本質, 2006年6月11日の日記
  • 金子勇, Winnyの技術, アスキー, 2005年

    しかしWinnyの場合、通信相手は不特定であり、Winnyプロトコルを使う誰もが通信相手になれます。たとえば、Winnyプロトコルを真似てWinnyノードに接続するようなプログラムの作成ができれば、接続相手のキャッシュファイルを観察することも可能です。このため、たとえどんなに強い暗号方式で通信内容を暗号化したとしても、通信相手は解読可能であり、通信内容は隠しようがありません。

    また、Winnyのキャッシュファイルは、そもそも公開されているデータと考えるべきです。

    金子勇著「Winnyの技術」p.151より

本日のリンク元 TrackBacks(100)

2009年09月26日

「WPA-TKIPが1分で破られる」は誤報

先月、無線LANのWPA-TKIPが1分以内に破られるという報道があり、話題となった。

  • 無線LANのWPAをわずか数秒から数十秒で突破する新しい攻撃方法が登場、早期にWPA2に移行する必要あり, Gigazine, 2009年8月5日

    今回の方法は昨年11月に発表された「Tews-Beck攻撃」(略)がQoS制御を利用する機器に限定されるものであり、鍵の導出に15分もの時間が必要であったのに対して、わずか数秒から数十秒で導出してしまうことができるというもの。(略)

    今回発表される方法では、TKIPにおける定期的に変更される鍵について、TKIPのプロトコルの新たな脆弱性を利用して極めて短時間(数秒から数十秒)で導出し、その鍵を効率よく利用する方法として新たな中間者攻撃を開発したとのこと。

  • 無線LANセキュリティ「WPA」をわずか1分以内で破る手法発見される, マイコミジャーナル, 2009年8月31日

    2008年にドイツのErik TewsとMartin Beckという2人の研究者の発見した方法により、15分以内にWPAのセキュリティを破ることが可能になった。(略)この攻撃手法は「Beck-Tews Attack」と呼ばれている。

    大東氏と森井氏が今回発見した手法はBeck-Tews攻撃をさらに発展させたもので、パケットを盗聴するマシンを無線LANアクセスポイントと利用者の PCの間に介在させ(いわゆる"Man-in-the-Middle"攻撃)、中継ポイントとしてBeck-Tews攻撃を行うことで1分以内での解読を可能にした。(略)

    今回の研究論文については、9月25日に広島大学で開催予定の研究会でデモストレーションを交えて発表される予定だという。

用語の問題として、WPA/WPA2の違いとRC4-TKIP/AES-CCMPの違いが混同されており、誤解を招くとの不満の声*1が挙っていたが、問題はそれだけではなかった。8月26日の時点で、RCIS(産業技術総合研究所情報セキュリティ研究センター)が次の技術文書を公表していた。

  • 無線LANのセキュリティに係わる脆弱性の報告に関する解説 (一般向け)

    最近,WPA及びWPA2に対する攻撃についての発表が学会等でなされ,この件について複数の矛盾した報道もなされるなど,一部において安全性に対する理解に混乱が生じています.そこで,我々は発表された攻撃が成功する可能性と,推奨する対策についてまとめました.

  • WPA の脆弱性の報告に関する分析 (技術的詳細)
    産業技術総合研究所情報セキュリティ研究センター, 8月26日

ここでは、AESへの移行が困難でTKIPを使わざるを得ない状況に対して、無線LANアクセスポイントの設定で鍵更新間隔を2分程度にするという回避策が挙げられているほか、様々な検討*2が書かれている。

発見者らのデモを交えた発表が9月25日の電子情報通信学会の研究会であるとのことだったが、日本のIT分野の科学ジャーナリズムには期待できないと思ったので、私は門外漢なのだけども、昨日、広島までこのセッションだけ聴講に行き、質問をして確認してきた。

まず、中間者攻撃のデモはなかった。発表内容は、Beck-Tews攻撃に対する発表者らの改良部分について、実験で実際の成功確率と所要時間を測定したというもので、中間者攻撃の手法は用いておらず、実験はBeck-Tews攻撃と同じ環境*3で行い、Beckらの攻撃ツール「tkiptun-ng」の実装に手を入れて行ったというものだった。

質疑応答の際、私は次のような質問をした。発表スライドの最後で中間者攻撃が効果的であることを示したというようなことが書かれているが、実験では中間者攻撃を用いず、Beck-Tews攻撃と同じ条件とのこと。これはどういうことか。

すると、第二著者の大東広島大学助教から説明があり、今回の発表は「メッセージ改ざんモード」での改竄についての成功確率と所要時間の評価が目的であり、中間者攻撃を用いなくても同じ評価ができるとのことだった。

なるほど、たしかに論文をよく読んでみると、中間者攻撃を用いる趣旨は、IEEE 802.11e対応機器でQoS機能有効という限定的な環境でなくても、広く使われている普通の無線LAN環境で攻撃を可能にするための話であって、「メッセージ改ざんモード」での改竄の所要時間を短縮する話とは、独立した別々の話として書かれている。

つまり、マイコミジャーナルの記事の以下の記述が誤りだったということのようだ。

アクセスポイントと利用者のPCの間に介在させ(いわゆる"Man-in-the-Middle"攻撃)、中継ポイントとしてBeck-Tews攻撃を行うことで1分以内での解読を可能にした。

無線LANセキュリティ「WPA」をわずか1分以内で破る手法発見される, マイコミジャーナル

次に、別の方が質問に立ち、次のような質問をした。この改竄はどのように続くのか。MIC鍵(改竄検知鍵)を復元した後で、鍵が更新されるまでの間、繰り返し短時間で改竄を行えるという意味か。

これについても、第二著者の大東助教から説明があり、その中で、今回の改竄手法は、MIC鍵復元(これの実行には従来通り11分〜12分程度を要する)後のパケット改竄の所要時間を短縮したものであることが言明された。実際、論文にも、今回の手法がどのようなものか、次の通り書かれている。

4.1 中間者攻撃のモデル

(略)我々の攻撃では,中間者攻撃を行う際に以下の3つのモードを使用する.

リピータモード: (略)

MIC鍵復元モード: MIC鍵を復元する際に用いられるモードであり,MIC鍵がない場合のBeck-Tews攻撃と同様の手順でchopchop攻撃と平文の復元を行うため12分程度の実行時間が必要となる.(略)

メッセージ改ざんモード: MIC鍵が得られているという条件の下で暗号化されたパケットの(略)改ざんを高速に実行するモードである.一度MIC鍵が復元されれば送受信者間のMIC鍵が変更されるまでこのモードは使用できる.この際にも,送受信者間の通信の途絶は生じるが実行時間を極力短くすることで通信頻度が高い場合でもパケットを改ざんできる可能性が高くなる.Beck-Tews攻撃と同様の方法を用いると実行時間は4分程度になるが,提案攻撃では4.2節の方法によって実行時間を1分程度まで短縮できる

小澤勇騎, 大東俊博, 森井昌克, 無線LAN暗号化WPAへの改ざん攻撃の実装と評価, 信学技報 LOIS2009-18

つまり、従来手法が、11分〜12分の改竄検知鍵復元時間 + 4分のパケット改竄時間であったところを、新手法は、後者の4分を1分以内(実験では平均で10秒程度)に短縮できるという話である。

つまり、この手法でWPAを破るには11分はかかるということであり、Gigazineやマイコミジャーナルの記事の以下の記述が誤りだったということのようだ。

今回の方法は(略)鍵の導出に15分もの時間が必要であったのに対して、わずか数秒から数十秒で導出してしまうことができるというもの。(略)

今回発表される方法では、TKIPにおける定期的に変更される鍵について、TKIPのプロトコルの新たな脆弱性を利用して極めて短時間(数秒から数十秒)で導出し、

無線LANのWPAをわずか数秒から数十秒で突破する新しい攻撃方法が登場、早期にWPA2に移行する必要あり, Gigazine

2008年にドイツのErik TewsとMartin Beckという2人の研究者の発見した方法により、15分以内にWPAのセキュリティを破ることが可能になった。(略)

大東氏と森井氏が今回発見した手法はBeck-Tews攻撃をさらに発展させたもので、(略)1分以内での解読を可能にした。

無線LANセキュリティ「WPA」をわずか1分以内で破る手法発見される, マイコミジャーナル

この点は重要な部分で、対策についてRCISの技術文書が次のように述べている点にかかわる。

3.2.2 文献 [1] の攻撃に対する対策

本攻撃に対する対抗策として、[1] の 5.1 節では TKIP の代わりに CCMP を用いることの他に、 2つの暫定的な対策を提示しています。 1つ目は(略)。 2つ目は、TKIP を用いる際の WPA の鍵更新間隔を120秒程度に短くすることを提案しています。これにより、Michael の解読が成功する前に鍵の更新が行なわれることを保証できるため、攻撃が難しくなります。やむを得ず TKIP を用いる場合で鍵更新間隔の設定を変更できる場合には、この変更を施しておくことが推奨されます。ただし、本変更によりアクセスポイントの負荷が重くなり、特にクライアントが多数存在するネットワークでは負荷が不安定になる可能性がありますので、設定の際は留意が必要です。 (略)

3.3.1 文献 [6] の攻撃による影響の評価

(略)なお、本報告 [6] で短縮されたとされている攻撃時間はパケットの改竄攻撃にかかる時間であり、その前段階で必要となる MIC 鍵の解読には、依然として10分以上の時間を要しています。そのため、3.2.2 節で触れた文献 [1] の鍵更新間隔変更による対抗策は、この報告における攻撃にも有効であると考えられます。

WPA の脆弱性の報告に関する分析, 産業技術総合研究所情報セキュリティ研究センター

「文献[1]」は2008年のBeck-Tews攻撃の論文のことで、たしかに、次の通り書かれていた。

5.1 Countermeasures

To prevent this attack, we suggest using a very short rekeying time, for example 120 seconds or less. In 120 seconds, the attacker can only decrypt parts of the ICV value at the end of a packet. (略)

(翻訳: この攻撃を防ぐために、攻撃者がパケット末尾のICV値の一部分しか復元できない、とても短い、たとえば120秒かそれ未満の鍵更新時間を用いることを提案する。)

Martin Beck and Erik Tews, Practical attacks against WEP and WPA,

今回の広島での発表では、この点について触れられることはなく、対策方法についての議論はなかった。また、間違った報道がなされているといった釈明あるいは訂正はなかった。

「1分で破られる」という報道は、英語圏でもニュースとなり、世界を駆け巡っていた。

こうした報道に対して、英語圏でも次のように指摘が出ていた。

  • WPA not cracked yet, Reusable Security, 2009年8月27日

    Finally, the "1 minute" time everyone is talking about only applies to injecting forged arp packets into the network, (it still takes around 11-15 minutes to decode a packet with the new attack). They achieved a speedup from the 4-5 minutes it took Beck/Tews attack to inject an arp packet by designing a way to forge the packet without having to contact the access point to verify if the packet is valid. (略)

    Now I want to stress, this is good research that Ohigashi and Morrii are doing, and it almost certainly will lead to more potent attacks. Likewise, their paper is honest about what they are doing and the limitations of their attack. It's just that people see the words "WPA packet injection" and "Less than 1 minute," and automatically assume that WPA is as weak as WEP. Or as the Yahoo article puts it,

    "The second generation of Wi-Fi security systems has now been broken as badly as its notoriously insecure predecessor"

    It's just not true.

つまり、論文は正直に何をやったのかを書いているのに、報道が決めてかかっているのがいけないと、このブログ主は述べている。今回の広島で発表の論文でもアブストラクトは次の通り書かれているのだが、読者は意味を正しく読み取れるだろうか。

  • 小澤勇騎, 大東俊博, 森井昌克, 無線LAN暗号化WPAへの改ざん攻撃の実装と評価, 信学技報 LOIS2009-18

    あらまし

    2008年11月,BeckとTewsはWPA-TKIPに対するパケット改ざん攻撃を提案した.彼らの攻撃(Beck-Tews攻撃)はIEEE802.11e規格に対応した無線LAN機器のみを対象にしており,12〜15分の実行時間でMIC鍵の復元およびARPパケットやDNSパケットのような短い暗号化パケットを改ざんできる.JWIS2009において,大東と森井はBeck-Tews攻撃を改良し,中間者攻撃の仮定の下で3つの攻撃モードを使い分けることでIEEE802.11e未対応機器でも実行可能な攻撃を提案している.さらに,メッセージ改ざんモード(MIC鍵が得られている条件でメッセージを改ざんする処理)を改良し,実行時間を1分程度まで減少させることに成功している.しかしながら,この実行時間は大きく見積もった値であり,実際の実行時間は更に短くなると予想される.本稿では,無線LAN機器を利用した攻撃実験を行うことによってJWIS2009の攻撃の実行時間を計測し,最も良い条件のときに攻撃の実行時間が平均で10秒程度まで減少することを示す.

ところで、「DNSパケット」について、9月14日のマイコミジャーナルの記事に、次のように書かれていた。

筆者らの研究グループが与えた攻撃方法は、WEPの解読法のようにパスフレーズを直接解読するわけではないが、ARPポイズニングや、DNSポイズニングを実行することで現実的な被害を生じさせることが可能で、通信システムとしては極めて危険な状態に置かれることになる。

WPAを破った森井教授からの提言- 無線LAN暗号化の脆弱性〜暗号化の意味と真の問題点〜 考案者自らWPA-TKIPを1分で攻撃できる理由を解説, 森井昌克, マイコミジャーナル, 2009年9月14日

DNS spoofingができるとすればそれは大きな脅威となる。そこで、研究会の質疑応答で、私は次の質問をした。この改竄ができることで、実際的にどのような被害が想定されるか。社会的にはそこに感心があるはず。論文のアブストラクトには「ARPパケットやDNSパケットのような短い暗号化パケットを改竄できる」とあるが、DNSパケットの改竄はできたのか。

これについて第二著者の大東広島大学助教から説明があり、「ARPパケットの改竄ではたいしたことはできない。DNSパケットは(ARPパケットと違って)推測できない値の部分があるので改竄できるかわからない。できないとは言えないので、できないと言うことはできない」というような感じの説明だった。DNSパケットの改竄に成功したわけではない様子だった。

パケット改竄の結果として生じ得る脅威については、RCISの技術文書が図解入りで詳しく解説している。

3.2.1 文献 [1] の攻撃による影響の評価

本攻撃が成功した場合に発生する実際上のリスクについて、文献で述べられているもののうち最も脅威のあるものは、一方向性ファイヤウォールの回避 [1, p. 84] であると考えられます。ファイヤウォール装置のうち外部からの不正な通信のみを排除し内部から外部方向の通信を遮断しないものは、通信パケットの内容を検査し、内→外方向のパケットと、それに対する外→中方向の応答のみを通過させるようになっています [図 9]。このようなネットワークに接続要求パケットを偽装して注入すると、 1パケットのみの偽装で TCP/IP の双方向通信を外→内方向に確立させることができる可能性があります [図 10]。この攻撃は、通信接続の追跡をしないもの(stateless firewall)については成立するものと思われます。一方、接続の追跡をしているもの(stateful firewall)や NAT の機能を有する物については、攻撃の可否はその実装に依存します。とりわけ、内部から外部方向のパケットについての状態追跡失敗に比較的寛容なものについては攻撃が可能です。

WPA の脆弱性の報告に関する分析, 産業技術総合研究所情報セキュリティ研究センター

こうした脅威が存在し得ることから、TKIPを使用している場合には対策をとることが推奨されている。どうすればよいのかについては、以下のRCISの技術文書で一般向けに解説されている。*4

*1 たとえば、Gigazineの記事に対するはてなブックマークコメントなど。

*2 「TKIP/AES両対応」モードのあるアクセスポイントでそれを使用するとTKIPと同程度の危険性となる可能性が指摘されている点など。

*3 IEEE 802.11e対応機器を用いてQoS機能を有効にした環境。

*4 もちろん、今後の発見によって状況が変わる可能性に留意は必要。

本日のリンク元 TrackBacks(18)

最新 追記

最近のタイトル

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|
最新 追記