<前の日記(2008年11月29日) 次の日記(2008年12月11日)> 最新 編集

高木浩光@自宅の日記

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

2008年12月06日

公衆無線LANで使うと危ないiPod touchアプリに注意

ヨドバシカメラでiPod touchを購入すると公衆無線LANサービスの加入案内が付いてくるように、iPod touchは、公衆無線LANでの使用が奨励されている機器である。

しかし、現状の公衆無線LANサービスは、無線通信の暗号化に用いる鍵が加入者全員で同一のところがほとんどであり(あるいは、暗号化しないところもある)、電波を傍受されて通信内容を読まれる危険性や、気付かないうちに偽アクセスポイントに接続してしまう(そして、通信内容を読まれたり書き換えられたりする)危険性がある。

ただ、現時点では、このリスクはしかたのないものとして受容されており、その代わりに、パスワードや重要な情報を送受信する際には、アプリケーションレベルでの暗号化(SSL等の使用)が必須という考え方になっている。

つまり、Webブラウザを使う場合であれば、「安全なWebサイト利用の鉄則」の手順に従って、入力の直前に、SSLでの接続(とドメイン名)を確認することが必須ということになる。

では、Webブラウザ以外の、それぞれのiPhone/iPod touchアプリはどうなっているのだろうか。

パスワードを送信していそうなアプリとして、「はてな touch」、「mixi」(mixi公式アプリ)、「MixiDock mini」の3つ(図1)について調べてみた。

図1: 「はてな touch」と「mixi」と「MixiDock mini」

これら3つのアプリは、いずれも、アプリの設定画面でIDとパスワード(はてなやmixiの)を保存し(図2)、パスワードが必要な操作をしたときにそれを自動送信するように作られている。

図2: 「はてな touch」のID・パスワード保存画面
(パスワードは架空のもの)

図3は、「はてな touch」でログインが必要な機能を使用したときの通信内容を傍受した様子*1である。

図3: 「はてな touch」使用時の無線LAN通信の傍受

「X-Wsse」「WWW-Authenticate: WSSE ...」とあることから、Atom Publishingプロトコル(RFC 5023)でかつてしばしば用いられていた、いわゆる「WSSE認証」*2が用いられているようだ。

調べてみると、「はてな touch」のページに、「はてなダイアリー AtomPub」を使用していると書かれており、はてなの「はてなダイアリーAtomPub」には、「はてなダイアリーAtomPubを利用するために、クライアントはWSSE認証を行う必要があります」と書かれている*3

この認証方式では、パスワードのハッシュ値が送信されているので、傍受されても(パスワード文字列が十分に長ければ)パスワードを復元されない*4

次に、mixiの公式アプリについて調べてみた。

図4: 「mixi」使用時の無線LAN通信の傍受

図4のように、mixiの公式アプリもいわゆる「WSSE認証」を使っているようだ。

ところで、このmixiの公式アプリは評判が悪いようだ。App Storeのレビューで酷評されており(図5)、ギズモード・ジャパンの「MixiDock mini」の紹介記事でも、「mixi公式アプリより使いやすかったりするかも」「その反面、公式のmixiアプリは(略)レビューも散々なことになっていますけど…。」と、mixi公式アプリの不評ぶりを伝えている。

図5: mixi公式アプリに対する酷評

では、その公式より良いと評判の「MixiDoc mini」の通信内容はどうなっているだろうか。

図6: 「MixiDoc mini」使用時の無線LAN通信の傍受
(「flower」は架空のパスワード)

IDとパスワードが丸見えだ。SSLも通していない。

というわけで、「MixiDoc mini」はパスワードを盗聴される危険性があるので、特に公衆無線LANで使用しないよう、注意が必要だ。

解決策としては、アプリの開発者らがSSLを通すように作るべきだろう。*5

このように、(Webブラウザの場合では、WebサイトがちゃんとSSLを使っているかどうかは利用者が目視で確認することができたのに対し、)個別に作られたアプリケーションの場合は、それがちゃんと暗号化を施しているかどうかは、通信を傍受するなどして確かめてみないとわからないという問題がある。

よって、重要な情報を送受信するアプリがちゃんと暗号化をしているかどうか、皆で監視して、情報共有していかなければならない。(こういう役割は、ギズモード・ジャパンのようなソフト紹介のメディアに担ってもらいたい。)

*1 自分の無線LAN通信を自分で傍受し、自分用の事前共有鍵でWPAの暗号を復号した様子。

*2 「WSSE認証」はRFC 5023の一部ではない。RFC 5023のInternet-Draftの01版で削除された経緯がある。WSSE認証なるものがその後ちゃんと規格化されたのかよくわからない。初期の作られたころに書かれた設計意図の説明によると、たいした必然性があったようには見えない。

*3 いわゆる「WSSE認証」は、リプレイ攻撃すら防げないあまり出来のよくないプロトコルであり、どうせならHTTP Digest認証を使う方がましなのに、なぜこれが使われているのだろうか?

*4 パスワードが短いと、辞書攻撃を併用した総当たり攻撃で復元され得る。ここによれば、ランダムな文字列でも16文字が必要で、一般的なパスフレーズでは40文字でも足りないとある。通常、パスワードについて、ランダムならば8文字でも十分と考えられているが、それは、オンラインでしかパスワードを試すことができない場合の話であり、パスワードのハッシュ値等が得られる状況では、オフラインでパスワードを試すことができるため、オンラインに比べて高速に試行できることから、長いパスワードが要求される。(無線LANの事前共有鍵でも、同様の理由から長い文字列を必要とする。)

*5 「WSSE認証」を使っているアプリもあまりよくない。はてなやmixiに長いパスワードを登録している人はいないだろう(通常その必要がないので)から、「はてな touch」や「mixi」でも、ハッシュ値が傍受されるとパスワードを復元されるリスクがある。Webブラウザでなら、公衆無線LANからログインするときには、https:// のページに移動してSSLを通してパスワードを入力することができたが、これらのアプリでは、利用者の意思でSSLを利用することができない。アプリ開発者はSSLを使うべきではないか。


<前の日記(2008年11月29日) 次の日記(2008年12月11日)> 最新 編集

最近のタイトル

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|04|07|11|12|
2025|01|02|03|04|05|06|10|11|12|
<前の日記(2008年11月29日) 次の日記(2008年12月11日)> 最新 編集