（未完成、あとで書く。）
先月27日の日記では、契約者固有IDによる「簡単ログイン」の危うさについて書いた。このログイン認証の実装方式は、携帯電話キャリアの「IPアドレス帯域」情報に基づいて、キャリアのゲートウェイからのアクセスのみ許すことによって、成り立ち得るものと考えられている（ケータイWeb開発者らには）ようだが、そもそも、その「IPアドレス帯域」なるものの安全な配布方式が用意されておらず、ケータイWeb運営者に対するDNSポイゾニング攻撃等によって、当該サイトに致命的な成り済まし被害が出かねない危険を孕んだものであることを書いた。
仮に、「IPアドレス帯域」の配布が安全に行われるようになったとしても、他にもリスクがある。通信路上に能動的盗聴者が現れたときに、致命的な成り済まし被害が出る。たとえば、6月3日の日記「通信路上の改竄攻撃発生に、Webサイト運営者が説明責任を負うのか？」で触れたように、データセンター内でARP spoofing攻撃が発生した場合、通信路上の攻撃者は、契約者固有IDをヘッダに入れてアクセスすることで、全てのユーザに成り済ましてログインできてしまう。*1
「ARP spoofingの脅威なんてあり得ない」という考え方もあるだろう。安価なレンタルサーバサービスのように、悪意ある者とLANを同居し得る状況で発生するものだから、安価でないレンタルサービスを使っていれば、その脅威は十分に小さいとする考え方だ。キャリアからデータセンターまでの通信回線上に盗聴者が入り込む危険性については、「電気通信事業者の回線しか通らないはずだから、電気通信事業者の取扱中に係る通信の秘密は法律によって十分に守られているのだ」とみなすわけだ。
昔の話（5年くらい前だろうか）になるが、「iモードの公式サイトは安全な場所に置かれているんですよね？」とどなたかに尋ねた記憶がある。というのは、ある大手銀行のケータイバンキングのサービスがSSLを使用していないのを見て、きっと、サーバは物理的に安全な場所に置かれているのだろうと思ったからだ。たとえば、NTTドコモのiモードセンター内に、公式サイト用のレンタルサーバが置かれていて、盗聴者の入る余地がないように設計されているとか、サーバは外にあるが、iモードセンターとそのサーバはVPNで接続されているとか、そういうふうになっているんじゃないかと思った。
しかし、それに対するお返事は、「ぜんぜんそんなことはない」というものだったように記憶している。その後も、何度か、「公式サイトは安全だと思っている人がいるようだけど、ぜんぜんそんなことはない」という発言を、掲示板等で何度か見た記憶がある。
たしかに、今や「公式サイト」は膨大な数にのぼっており、それらが全部、安全な場所に置かれている、あるいは安全な方法で接続されているとは考え難い。ただ、さすがに銀行等の一部の大手サイトは、安全な場所に設置されているか、安全な方法で接続されているに違いないと思っている。
携帯電話会社の技術者（あるいは研究者）の方々も、IPアドレス帯域制限と契約者固有IDによるログイン方式が危険なものであることは認識されていると私は理解している。
このことについては、2003年8月24日の日記でも触れている。モバイルITフォーラムという、携帯電話会社と一部のコンテンツ業者、SI事業者らが集まった団体があり、この団体が、安全で簡単に利用できる認証方式を提唱していた。
この研究成果は、NTTドコモの「FirstPass」、KDDIの「Security Pass」として実用化に至っている。*2
これは、個人でも簡単に利用できるように設計されたものであるが、ケータイサイト側で対応しているところを見たことがない*3。おそらく、企業が社員用の用いている事例はあるのだろうと思うが、コンシューマー向けにはぜんぜん普及していないと認識している。
これら「FirstPass」や「Security Pass」は、SSLのクライアント認証を用いてログインを実現するもので、通信路上の盗聴者の存在を仮定する場合に対して、ログインが安全なものとなる方式である。
これは、利便性と安全性を両立させようとした試みで、これが成功していないのは残念である。何が原因で普及していないのかが究明されるべきだと思う。
このように、ケータイWebにおいて、契約者固有IDによる「簡単ログイン」などという方式が不適切なものであることは、中心的な関係者の間では十分に認識されていることであり、その解決方法は、既に示されているし、実用化もされている。
ただし、2003年8月24日の日記にも書いていたように、「FirstPass」や「Security Pass」でも、プライバシー上の問題が残る。どのサイトに行っても同じクライアント証明書を使うようになってしまうと、クライアント証明書のcommon name（氏名等ではないが、ユニークなID文字列）でアクセス者を同定できるようになるわけで、「日本のインターネットが終了する日」で書いたのと類似の懸念がある*4。私としては、このままこれが大規模に普及してしまうのは避けて欲しいと思っているので、悩ましいところだ。
また、これらが普及しない原因として、「SSLを用いること自体が重くて嫌だ」と考えるケータイサイト運営者も少なくないことがあるのではないかと思うが、SSLを使わないのを許すのを前提とした場合において、リスクをPCと同程度に引き下げるためには、cookieをサポートすれば良いだけの話である。NTTドコモはcookieをサポートするべきだ。
「日本のインターネットが終了する日」で書いたように、ケータイWeb（iモード、EZweb、Yahoo!ケータイ、EMnet）では、キャリアのゲートウェイが匿名プロキシサーバ化してしまっているため、ゲートウェイでIDを付けて送信していないと、悪質な書き込み等があったときに、発信者を特定する際に困難が生じてしまうという問題があった。
しかし、これは、「日本のインターネットが終了する日」で書いたように、契約者固有IDである必要はない。1日から1週間ほどで別のIDに変化する番号を送信するようにしておけば十分である。発信者情報開示請求する際には、そのIDとその時刻のペアで指定して、携帯電話会社に請求することになる。
これは、現在のIPv4におけるPCのインターネットの環境と同じ仕組みであり、また、IPv6で一時アドレスが用いられたときとも同様である。
問題は、携帯電話会社がそのようなシステムを構築することを、コスト負担上、嫌がるのではないかという点である。今年3月末から、NTTドコモが「iモードID」の全サイト自動送信を開始したのは、複合的な理由からだったと思うが、おそらく、急いで対応する必要があったために、安易な仕様を選択せざるを得なかったのではないかと思う。
楠正憲氏は、私の「日本のインターネットが終了する日」に対して、「日本のネットは終わらないよ」と題したブログエントリで、次のように意見を表明されている。
サイトを超えて一意のIDを利用することの危険性は、1990年代末から国際的に広く共有されているのだから、携帯キャリアは一刻も早く個体識別番号等の提供形態を見直すべきだ。具体的には、
- 携帯サイトに個人情報を書き込むことの危険性を広く国民に啓発する (可及的速やかに)
- 個体識別番号等の無条件送信をドコモが勝手サイトに対して以前提供していたオプトインに改め、クッキーやサイト毎に異なる個体識別番号等の代替手段を早急に提供する (1年以内に実施)
- ネットに展開可能なオープンかつ安全な通信プラットフォームを早急に整備して移行を促し、個体識別番号等の提供を廃止する (3年以内に実施)
といった安全対策を取ることが考えられる。
日本のネットは終わらないよ, 雑種路線でいこう, 2008年7月22日
実際に廃止できるかどうかはともかく、廃止せざるを得なくなる時の到来を想定して、携帯電話会社は、代替手段を今から準備しておくべきだと思う。
つまり、現在の契約者固有IDに加えて、発信者開示請求用の別のID（1日から1週間で変化するもの）もヘッダに載せて送信するようにするべきだと思う。
システムのコストがどれだけになるかわからないが、DHCPサーバがやっているような仕組みを、数千万ユーザに対して処理することになると思われる。技術的にそれが実現性が低いのであれば、何らかの代替方式を検討できないものだろうか。
なお、イーモバイルについては、「emb」で接続した場合（EMnetを契約しない、あるいは使わない場合の接続）には、通常のPCのインターネットと同様に、電話機にIPアドレスが割り当てられてのアクセスとなるので、発信者情報開示請求の観点からは、そのままIPアドレスを用いればよいのであるから、IDをヘッダに含めて送信する必要性は全くない。*5
（未稿。あとで書く。通信プラットフォーム研究会のことについて書く。）
（未稿。あとで書く。）
（未稿。あとで書く。関係者の中に入って行動するべきか、それとも外野から批評し続ける方が得策か。）
*1 もっとも、この脅威は、SSLを使用していない全てのサイトにおいて元々存在するリスクではある。たとえ、セッションIDを用いたログイン機能実装がなされていたとしても、通信路上の能動的盗聴者は、ログイン中のユーザのセッションIDを盗聴して、それを持ちいて成り済ましアクセス（セッションハイジャック）することはできるし、ユーザのパスワード入力時にパスワードを盗聴して、それを用いて成り済ましログインすることができてしまう。しかし、この場合は、攻撃者の攻撃中にログインした人だけが被害者となるのに対し、契約者固有IDによる「簡単ログイン」方式の場合には、それ以外の全ユーザが即座に成り済まし被害に遭うという点で、リスクの甚大さが異なる。
*2 あれ？ ソフトバンクモバイルは？
*3 今調べたところ、イーバンク銀行が採用しているようだ。
*4 ただし、違いとして、「FirstPass」や「Security Pass」ではおそらく、アクセス時には、証明書送信時に確認ボタンを押す、あるいはPINコードの入力する等の、ユーザの動作を必要とするようになっていると思われる（未確認）。したがって、現在のケータイWebの契約者固有IDの全サイト自動送信とは違い、ユーザが警戒していれば、悪意あるサイトに証明書IDを送信してしまうことを避けられるかもしれない。それでも、この方式が普及すると、どこのサイトに行っても確認が出るようになってくるから、ユーザは、悪意あるサイトでもボタンを押すようになってしまう（サイトを表示する前に確認が現れるため、サイトの内容を確認できない）と考えられ、プライバシーの問題は、現在の契約者固有IDと同様に生じると思う。これを解決するには、複数のクライアント証明書を使うようにすればよいわけで、それをユーザが使い分けられるかという問題はあるかもしれないが、ユーザインターフェイスを工夫することで解決する方法はあるように思う。
*5 その意味で、イーモバイルが、なぜ契約者固有ID送信機能付きのEMnetをわざわざ導入したのかが謎であり、NAVITIMEのような安直なアプリケーション構築手法を温存するためではないかと危惧している。（青少年ネット規制対応のための悪質ユーザ排斥の目的で導入された可能性もあるが。）
高木浩光＠自宅の日記 - ケータイWebはどうなるべきか