NTT docomoのスマホ向け独自サービス「spモード」が、今月20日に大規模な事故を起こして、重大事態となっている。
この事故は「spモードメール」で表面化したが(目に見える現象が起きたため苦情が相次いだ)、その他にも、目に見えにくい事故、つまりコンテンツ課金など、spモードの他のサービス(利用者識別に基づくもの)でも、利用者取り違えの事故が起きていた可能性があり、現在も調査中とされている。*1
この事故の原因を巡っては、spモードの詳細な仕組みが会見で公表されたことから、技術者達の間に物議を醸している。
(略)一部のサーバーが処理能力不足に陥ったことが、なぜ「自分のメールアドレスが他人のものに置き換わる」という通信の秘密にかかわる事故に発展したのか。大きな理由の1つは、メールアドレスが端末固有のIDでなく、端末に振り出されたIPアドレスとひも付いていた点にある。
(略)NTTドコモのspモードシステムの場合、3G網に接続して電話番号とIPアドレスをひも付けた後は、パケットのヘッダーにあるIPアドレスを使い、パケットを送信したAndroid端末を識別していた。NTTドコモはこの件について「spモードシステムはIP網の中で動いており、パケットのIPアドレスとユーザーをひも付けるのは自然の発想だった」としている。当然、iモードメールのメールアドレスも、最終的にはIPアドレスとひも付けられている。
このシーケンス図と、会見内容を伝える報道から推測するに、次のようになっているようだ。
経験のある技術者なら、こういう作り方は危ういと直感するのではないか。「IPアドレスと利用者」というマッピングが、2か所(端末と「パケット交換機」を含む電話網側と、「セッション管理」サーバの2か所)で管理されていて、これらを同期しなくてはならなくなっており、片方で更新が滞ると何が起きるかわからないという点で不安になって、避けたくなるはずの設計ではないか。
しかも、IPアドレスは再利用されるIDであり、同じIPアドレスが(解放後に)別の利用者に割り当てられるものであるから、IPアドレスを利用者識別に用いたら、この同期の失敗は、利用者の取り違えという重大事故につながる。
これに対して、docomoが会見で、「パケットのIPアドレスとユーザーをひも付けるのは自然の発想」と言ってのけたということで、技術者は皆、仰天し、「利用者識別にIPアドレスを用いるなんぞアリエナイ」といった声が相次いだ。
では、なぜdocomoは、IPアドレスによる利用者識別を実装してしまったのだろうか。
このことは、実際にdocomo端末を用意して、spモードを使ってみて、すぐにわかった。以下、外形的な事実から論理的に導かれる推測を示す。
最近のspモードでは「dmenu」なる、ガラケーのiモードのような機能が提供されている。以下の図1は、Webブラウザで「spモード各種設定」の画面を閲覧したときの様子である。
ここで注目すべきは、IDもパスワードも入力していないのに、既にログイン中の状態になっていることである。
URLにはユーザ名もセッションIDもなく、cookieをオフに設定してcookieを削除してこの画面を開いても、利用者である私はWebサイト側に識別されていて、そのまま私向けの設定を続行することができるようになっている。
一般のPCと普通のインターネットのWebでは、こういうことはあり得ない。電話網の仕掛けによって、利用者である私が識別されて、それがWebアプリ上で利用されていることを意味する。
ここで、図1の画面のURLが https:// である点に注意したい。SSLが使用されている。つまり、端末のアプリ(この場合はWebブラウザ)とWebサーバとが、end-to-endのSSL暗号化通信をしている。
となると、Webサーバはどうやって私を識別しているのか。end-to-endのSSL暗号化通信が用いられている限り、間のゲートウェイで「X-DCMGUID:」(iモードID)をHTTPリクエストヘッダに挿入するなどという、ガラケーでやってきた芸当は不可能である。*2
図1のhttps://のリクエストには何らパラメータが埋め込まれていないのだから、そうすると、Webサーバとしては、接続元のIPアドレスの他に頼りにする情報がない。
つまり、以下の図2のようなシーケンスになっていると推定できる。
このように、HTTPSリクエストを受けたWebサーバは、(リクエストの中身が空なので)接続元のIPアドレスを「セッション管理」サーバに問い合わせて、ユーザID*4を得るしかない。*5
こういう作り方が危ういのは上に述べた通りであるが、では、12年もの長年の実績のあるiモードで、これまで同様の事故が起きなかったのはなぜか。
上で引用した日経IT Proの記事では、「当然、iモードメールのメールアドレスも、最終的にはIPアドレスとひも付けられている」などと書かれているが、これは間違いで、iモードではIPアドレスは使用していなかったと思われる。
iモードでは図3のようなシーケンスになっていただろう。
iモードが始まった当初は、PDC方式上にインターネットアクセスを実現したため、今のスマホとは違って、端末とWebサーバが直接TCP/IPの通信をするのではなく、「パケット交換機」がTCP/IP接続を開始するようになっていた。そのため、この「パケット交換機」が、HTTPリクエストに電話番号などの利用者識別子をヘッダに載せることができた。
docomoの公開資料「技術的条件集別表8-2-1」によると、「パケット交換機」がHTTPリクエストを出すとき、拡張ヘッダとして電話番号(MSISDN)を載せるようになっていて、「プロキシサーバ」に渡すようになっているそうだ。資料には書かれていないが、おそらくは、この「プロキシサーバ」がいわゆるiモードの「ゲートウェイ」であり、そこで、電話番号からiモードID(やuid)への置き換えがなされているのだろう。
こうして、iモードでは、リクエストヘッダ中のiモードID(やuid)を参照することで、Webサーバが利用者を識別することができた。
このような方法を採用できたのは、iモードID(やuid)の送信が、その仕様として、https:// に非対応だったからである。(端末からWebサーバまでのend-to-endのSSL通信では、ヘッダに何かを挿入することはできない。)
以上のことから推察するに、spモードが図2のような設計になったのは、iモードと同じ使い勝手の実現と、https:// への対応を両立させることが、絶対的な実現目標とされたためではないだろうか。
「iモードと同じ使い勝手」というのは、要するに、「ID・パスワードが存在しない」ということである。
存在しないと言っても、「ネットワーク暗証番号」(4桁数字)は存在するわけだが、これは、端末を落としたときに物理的に他人に操作されないようにする役割*7であって、インターネットからの任意のアクセスに対して本人認証するという役割ではない(だから4桁数字という非常に弱い識別符号で許される)。
そして、docomoとしては、携帯電話の多くの利用者には、4桁数字の暗証番号は使えても、PCで使うようなパスワードを使いこなすことは無理(お年寄りなどには)と考えているのではないか*8。無理ではなくとも、利用が敬遠されて、利益がiモードのときのように出ないと考えているのではないか。そのことが、経営上の判断として、iモードと同じ使い勝手の実現に向かわせているのではないか。
あるいは、「水平分業」化をくい止めるために、ID・パスワードの使用という使い方を避け、「垂直統合」モデルの優位性を顕示するために、電話網との統合でなければ不可能なことを実現したかったのではないか。
そうだとするとこの問題は根深い。「諦めてID・パスワード方式にしようよ」と言ったところで、聞き入れる気はないと思われる。今どきHTTPSをやめてHTTPにするわけにもいかないだろう。
どうしても両立して実現したいなら、以下の図4のような方法がよいかもしれない。
つまり、HTTPSリクエストの中身にセッションIDを入れてWebサーバに渡すようにする。そして、そのセッションIDが、ID・パスワードなしで、電話網の認証機能から得られるようにする。(ただし、「専用アプリ」には注意点があり、そう簡単な話ではない。この件については下に書く。)
というわけで、このような背景があって、27日、NHKニュースが以下のように伝えた。
NTTドコモのスマートフォン向けのサービス「spモード」で起きた今回のトラブルについて、コンピューターやネットワークの専門家からは、IPアドレスを用いて利用者を識別する「spモード」の仕組みが不十分だったのではないかという指摘も出ています。
(略)高木浩光主任研究員は「従来の携帯電話で提供してきたi-modeと同じ利便性を維持するために、パスワードがなくても認証できるようにIPアドレスを利用したとみられる。しかし、再利用できないIDを用いるなど、アドレスの重複を防ぐシステムを整えなければ、今後も小規模なトラブルが起きる可能性がある」と指摘しています。
こうした指摘に対し、NTTドコモでは「IPアドレスを利用した認証方式は広く利用されており、問題はないと考えているが、サーバーなど設備を増強するとともに、IPアドレスの取り違えが起きないようにシステムの改修を進めるなど、対策をしていきたい」と話しています。
docomoは「IPアドレスを利用した認証方式は広く利用されており、問題はないと考えている」と言うのだが、はたして本当だろうか。
たしかに、IPアドレスを払い出して管理するという、ISPとしての機能の部分では、利用者とIPアドレスが紐付けられて管理されているに違いない*10けども、そこをアプリレイヤが使って、IPアドレスから利用者IDを検索するということが「広く利用されている」というのには疑問なのだが、他のキャリアで、同様のことが実現されている例(ID・パスワードなしとHTTPSの両立)があるのだろうか。
この話は、シングルサインオンの実現方式の話として見ることもできる。「パケット交換機」でのログイン状態を「Webサーバ」に引き回すにはどういう実現方式があるかだ。一般に、シングルサインオンの実現方式は、2つあって、リバースプロキシ方式と、SAMLやOpenIDに代表されるアクセストークン引き回し方式だと言われる。図3のiモードの方法はリバースプロキシ方式に相当し、図4の方法はSAMLやOpenIDなどの方式に相当すると言えよう。それに対して、図2のspモードの方法は、どちらでもない、ユニークなものとなっている。はたしてこの方式は安定的なのだろうか。
以上は、Webの場合について検討してきたが、今回事故が表面化した「spモードメール」の場合も、同様に、メールサーバが利用者を識別する際に、図2のようにIPアドレスをキーにしてユーザIDを問い合わせているのではないか。
本来、メールサーバは、POP3やSMTP AUTHのログイン名とパスワードで利用者を認証・識別するものだが、spモードメールでは、事情が違うようだ。このことは、docomoのテクニカル・ジャーナルに書かれていた。
(略)しかし、POP3S/SMTPSは、ユーザ認証時にメールアカウント(ユーザID/パスワード)を利用するプロトコルであるため、一般的なメールクライアントでは、ユーザ自身がメールアカウントの設定作業を行う必要がある。
そこで、spモードメールでは、プロビジョニング機能を用意し、メールアカウントの設定作業を不要とした。すなわち、自動的にサーバ側で生成され払い出されたメールアカウントを用いて認証を行う方式とした。また、払い出すメールアカウントに有効期限をもたせ、サーバ側から強制的に変更を行うことでセキュリティを高めている。メールアカウント取得からメール送受信までのシーケンス図を図2に示す。
「プロビジョニング」で取得する「メールアカウント」というのは、iモードメールアドレスのfoo@docomo.ne.jpの「foo」の部分をログイン名とし、ランダムに生成された長い文字列をパスワードとしたものとなっているようだ。
こんなこと*11が可能なのは(パスワードなしに自動でアカウントを設定できるのは)、Webの「dmenu」と同様に、3G経由での接続中は「パケット交換機」で(認証済みの)利用者識別ができるからで、図2と同様に、それをアプリレイヤで活用しているのだろう。
メールサーバでもWebと同様に図2の方式で利用者識別をしているのだとすれば、spモードメールのプロトコルは、おそらく以下の図5のようなシーケンスになっているのではないか。
今回の事故は、上半分が正常に作動せず、「プロビジョニング」の際に、「セッション管理」サーバの「IPアドレス,ユーザID」対応表が古いままになっていて、他人の「ユーザID」がメールサーバに渡され、その結果、その他人のメールアドレス(と乱数で生成されたパスワード)が、spモードメールアプリに返されたということではないかと推察する。
docomoが27日に発表した「発生した事象のイメージ」は、この推定に符合する。
「プロビジョニング」の際に「上半分が正常に作動せず」だったのは、図の「お客様(A)」である。その状態で(A)がメールを送信すると、古い「IPアドレス,ユーザID」対応表に従って、「お客様(C)」にすり替わって送信してしまい、結果、「お客様(B)」には、知らない人(C)からのメールのように見えた。(それに気付かず返信してしまった人が1,195人。)
また、同じ頃に、(C)宛にメールを送った「お客様(D)」のメールは、メール到着の通知は別の方法(SMS)で行われているため正常に(C)に届き、そのとき(C)が圏内でメール本体の受信を済ませていればそのまま(C)に届いたが、(C)が圏外だった場合には、先に(A)が、(C)にすり替わって(C)のメールボックスのメールを受信してしまう事態が起きた(1,335人分)ということだろう。
ところで、上で「「専用アプリ」には注意点があり」と書いた件は、どういうことか。
少なくともAndroidのスマートフォンにおいては、図4の仕組みが安全に成り立つには、以下の各要件を満たす必要がある。
つまり、悪意あるアプリや、悪意あるテザリング接続者に、なりすまされてしまうことのないようにする必要がある。
どうやったらそれを実現できるかは、現時点の私の知識ではわからない。たとえば、販売時から、プリインストールの「専用アプリ」に専用のクライアント証明書をインストールしておけば実現できるような気がする。しかし、その場合、配備するクライアント証明書とユーザの紐付けを販売時までにしておく必要があり、あまり現実的でないのかもしれない。
と、ここまで考えて気付いたのだが、ということは、現状の「dmenu」の仕組みだって、同様の問題を抱えているはずである。
dmenuの画面は、テザリングで接続している端末からどのように見えるのだろうか?
docomoの実際の端末で確かめてみたところ、テザリング中は、dmenuなどがアクセスできないようになっていた。以下の図7の画面が現れるようになっている。
なるほど、ちゃんと対策されているようだ*13。しかし、これはこれで、にんともかんとも不便な話ではある。
では次に、悪意あるアプリから「dmenu」はどう見えるのだろうか。
「dmenu」は、Android標準搭載の「ブラウザ」でしか見られないわけではない。Firefoxでも、Operaでも「dmenu」を普通に使うことができた。このことから、試してみるまでもなく、悪意あるアプリからでも「dmenu」は見えてしまうと言える。*14
「dmenu」には「ネットワーク暗証番号」や「spモードパスワード」の入力を必要とする画面が多いが、すべての画面でそれらを要するわけではない。例えば、「dmenu」トップにある「マイメニュー」ボタンを押すと、図8のように「マイメニュー 一覧」の画面が現れ、ここには、個人に関する情報が表示されるのだが、それにもかかわらず、暗証番号やパスワードは不要である。
このように、私が「毎日新聞」のコンテンツを購読している事実を、悪意あるアプリから収集することができてしまう。
これは「dmenu」の仕様だろう。修正されることはないと予想する。
「そもそも悪意あるアプリを入れるのが悪い」とdocomoは弁明するかもしれない。たしかに、一般のPCの世界ではそうであった。しかし、Androidでは、permissionモデルが採用されており、利用者は、マーケットでアプリをダウンロードする際に、要求されるpermission(「許可」)を確認して「同意してダウンロード」ボタンを押すことになっている。
「dmenu」をのぞき見するには、「ネットワーク通信(完全なインターネットアクセス)」のpermissionだけがあれば可能である。今や、かなり多くのアプリがこのpermissionを要求しているので、このpermission要求で怪しいと気付けることはまずないだろう。むしろ、要求パーミッションが「ネットワーク通信(完全なインターネットアクセス)」だけだったら、クリーンなアプリと感じる人も多いのではないか。
こんなことでよいのだろうか。
問題点はまだ他にもある。
spモードには、「spモードパスワード」という、「ネットワーク暗証番号」とは別の、4桁数字のパスワード(「パスワード」ではなく暗証番号と呼ぶべきだ)の仕組みがある。その初期設定が全員「0000」になっているのである。
図右のように、一応、docomoは「お客様独自のものに変更してください」と注意書きをしているが、図左のように、ご丁寧にも「初期パスワードは0000です」と案内しているコンテンツプロバイダまでいる始末だ。
docomoとしては、この暗証番号は、端末を落としたときの不正使用を防ぐため、あるいは、有料サービス登録の際の支払いの意思確認の役割のものと考えていて、そのため、こんなぞんざいな扱いにしているのかもしれない。
しかし、「0000」のまま使っている人が多いとすると、悪意あるアプリによって無断で有料サービスを登録されてしまう危険があるのではないか。
こんなことでよいのだろうか。
こんなことになっているのは、「ID・パスワードが存在しない」つまり、電話網による利用者識別をアプリレイヤで活用するという、spモードの特徴から来たものである。どうしたら対策できるか思いつかない。「ID・パスワードが存在しない」という特徴を捨てて、普通のインターネットのWebと同じやり方に仕様を変更するしかないのではないか。
そして最後にもう一点。
上で参照した、NTT docomo テクニカル・ジャーナルの記事に、こんなことが書かれている。
3.2サービスアプリ認証機能
メール送受信時のメールアカウントを自動で払い出すには、メールクライアントがドコモの正規のアプリケーション(以下、正規アプリ)であることを確認する必要がある。本開発では、spモードメールを含むドコモ独自サービスの利用をドコモの正規アプリのみに限定し、なりすましなどの不正利用を防止する仕組み(サービスアプリ認証)を導入した。
サービスアプリ認証では、ユーザ認証情報要求するアプリケーションが、正規アプリであるか否かをドコモ独自の認証方式により識別し、正規アプリであると識別できた場合のみユーザ認証情報を払い出す。(略)
2010年スマートフォン新サービス・機能 ――spモードのメールサービス――, NTT docomo テクニカル・ジャーナル, Vol.18, No.3
いったいどうやって実現しているのだろう? 最初に読んだときは「そんなことできるわけがない」と思ったが、上で検討したように、何か方法はあるのかもしれない。
ところが、既に、この「ドコモ独自のサービスアプリ認証」を解析し、spモードメール互換のアプリを開発した人がいる。
先日、その方からメールを頂き、「ドコモ独自のサービスアプリ認証」がどういう手順のものか、詳細情報を教わった。その方式はナンセンスなもので、単にアプリに埋め込まれた鍵で暗号化やハッシュをかけているだけのものであった。(解析した方には、詳細情報(具体的な手順)の公表を控え、IPAの脆弱性届出窓口に届け出ることをお勧めしておこうと思う。)
要するに、「ドコモ独自のサービスアプリ認証」なるものは、Winnyプロトコル並の難読化にすぎない。
正直、呆れた。この一点だけとってみても、docomoが、アーキテクチャ設計において、セキュリティレビューを受けていないことがわかる。
――特徴的な機能であるコンテンツ決済についてですが、使い勝手としてはiモードと同等になっているのでしょうか。
久永氏
簡単なspモード用パスワードを入力すると、コンテンツプロバイダへ決済情報が渡され認証される、という形です。(略)――ユーザーがiモードからspモードへ移行、ということができれば開発側からすると楽なのかもしれませんが、なかなかそうもいきませんね。
久永氏
今までiモードに10年以上馴染んでいただいて、パソコンはわからないけれどiモードはがんがん使えるという方はいらっしゃると思います。ガラパゴスと揶揄されることもありますが、作り込んだからこそ使いやすく安心、といった面も(iモードには)あると思います。
spモードが目指すところはそもそも技術論的に無理があるのではないか。今一度、技術者の声に耳を傾け、根本から考え直す勇気を持ってはどうだろうか。
上に書いたように、現在のspモードには、spモードメールを盗み読まれたり、「マイメニュー 一覧」を盗み読まれたり、無断で有料サービスに登録させられる等の危険がある。しかし、回避策があるので、以下、その回避策を周知する。
docomoが技術文書で謳っている「ドコモ独自のサービスアプリ認証」は既に解析されて破られています。以下の方法で、他人があなたのspモードメールを盗み読みしたり、あなたになりすましてメール送信できてしまう危険があります。
今後、短期的にdocomoが取り得る対策としては以下のものが考えられます。今後の動向に留意してください。
spモードの「dmenu」には、暗証番号やパスワードの入力なしに、個人に関する情報を閲覧できる画面が存在します。例えば「マイメニュー 一覧」の画面です。そこには、あなたがどんなサービスに登録しているかが表示されます。この内容を、以下の方法で盗み読まれる危険があります。
今後、短期的にdocomoが取り得る対策はほぼないと考えられます。強いて挙げれば、「マイメニュー 一覧」など、個人に関する情報が表示される画面の全てについて、閲覧に際して「ネットワーク暗証番号」か「spモードパスワード」の入力を必要とするよう、仕様変更されるかもしれません。しかし、「怪しいアプリに警戒し、不用意にインストールしない」のが基本であるとして、そのような仕様変更はなされないかもしれません。
spモードには「spモードパスワード」(4桁数字の暗証番号)の仕組みがありますが、初期設定では全員が「0000」に設定されています。そのため、以下の方法で、無断で有料サービスに登録されてしまう危険があります。
今後、短期的にdocomoが取り得る対策はありません。
以上。
*1 21日のCNETの記事によると、会見で「コンテンツの誤課金などの可能性は?」との質問に対しdocomoは、「それも論理的には可能性がある。一時停止した21項目のspモードサービスはIPアドレスを使っているので、電話番号とIPアドレスが紐付かないといろいろな事が起きると思う。そこについても通信記録を解析して、実際に何が起きたかを確認しているところ。」と答えていた。また、27日のケータイWatchの記事でも、「コンテンツの誤課金、コンテンツプロバイダへの対応について、今回の発表では触れられておらず、あらためて案内される見込み」とされている。
*2 MITMで動的に偽サーバ証明書を自動生成して、ルート証明書を端末に出荷時から入れておくという方法があるにはあるが、電気通信事業者がそのような手段をとるのは不適切であり、やってはいけない。
*3 WebSequenceDiagrams.comで作成。
*4 docomoの会見で示されたシーケンス図では、「C:α」の「C」は「電話番号」とあるので、私の推定のように「ユーザID」を用いるのではなく、電話番号を直接Webサーバで用いているのかもしれない。
*5 一度この方法でユーザIDを得れば、後は、通常のWebアプリ同様に、セッションIDをcookieにセットして、この問い合わせを省略することもできる。dmenuの一部のページではそのようになっているように見える(確認はしていない)。
*6 WebSequenceDiagrams.comで作成。
*7 あるいは、有料サービス登録の際の、支払いの意思確認の役割。
*8 この数か月、スマホの購入時にGoogleのIDとパスワードを紙に書くよう指示する販売店があるとのことで、問題視されつつある(この件は別の機会にまとめる予定)が、特に、docomoショップでの事例が多数報告されている。そのことからも、「利用者にパスワードなど使えない」との考えの一端がうかがえる。
*9 WebSequenceDiagrams.comで作成。
*10 その部分では、利用者とIPアドレスのマッピングは1つであって、spモードのように2つのマッピングの同期に失敗することが原因の事故というのは、起き得ないのではないか。
*11 このプロトコルも一見して変だと感じる(メールアカウントの取得がパスワードなしに自動で可能なのなら、そのままメールもその方法で送受信すればいいじゃないの?と思える)が、まあ、アカウント取得部分の認証のコストが重くて、POP3/SMTP AUTHは軽いから、認証のcacheのようなことをやっているとみれば、まあ、合理的と言えるか。加えて、Wi-Fi接続時のメール送受信を実現するために必要だったとも言えるかもしれないが、そのわりにはWi-Fiでspモードメールを使うには別のパスワード設定が必要だったりして、意味不明なところがある。
*12 WebSequenceDiagrams.comで作成。
*13 どうやって実現されているのかは確認していないが。
*14 実際に、https://service.smt.docomo.ne.jp/cgi/mymenu/top のURLにアクセスしてHTMLを取得するだけのAndoroidアプリを作成して動かしたところ、spモード接続中に使用すると、「マイメニュー一覧」のHTMLが取得できたという報告がある。
ドコモのメールトラブル約1万9千人実害
配信元:産経新聞 2011/12/27 19:14更新
http://www.iza.ne.jp/news/newsarticle/business/infotech/540008/
----
今更感はあるが、現実問題でもちょっと気にな
このエントリの見方 長いので手早く読みたい方は、前置きとリンクしている高木さんのエントリを確認し、結論とまとめに飛び、シーケンス図を確認し、補足とおまけを後回しにしながら必要な所だけ順番に見るといいかもしれません。時間と根気がある方は順番にどうぞ。 ド..