高木浩光＠自宅の日記

■ 今こそケータイID問題の解決に向けて

目次

• ソフトバンクモバイル製のiPhoneアプリがUDIDを認証に使用していた件
• Web開発技術者向けの講演でお話ししたこと
• 研究者向けの講演、消費者団体向けの講演でお話ししたこと
• 総務省がパブリックコメント募集中

ソフトバンクモバイル製のiPhoneアプリがUDIDを認証に使用していた件

6月初めのこと、ソフトバンクモバイルが「電波チェッカー」というiPhoneアプリを直々に開発して、iTunesストアで配布を始めたというニュースがあったのだが、それを伝えるITmediaの記事で、「取得された電波状況情報はiPhoneのUDIDとともにソフトバンクモバイルに報告される」と書かれているのが気になった。*1

「電波チェッカー」で検索して世間の反応を探ったところ、ソフトバンクモバイル社のCTO（最高技術責任者）の方が、Twitterで直々に市民と対話なさっているのを見つけた。そこで私も、「電波チェッカー」におけるUDIDについてお尋ねしてみたところ、ちゃんとお相手してくださった。

そのときのやり取りと、その後の展開（別件について*2）を以下にまとめた。

• まとめ「UDID他についてソフトバンクモバイルCTOとのやりとり」, Togetter, 2010年6月1日〜16日

これは要するにどういうことかというと、まず、UDIDを何の用途で使用しているかを尋ねたところ、UDIDでユーザを識別して、ユーザの登録済みの位置情報を画面に表示しているとのこと。つまり、図1のように、このアプリは、ユーザが自分で登録した自分の位置情報を閲覧できるものなのだが、この位置情報は、サーバ（Webアプリケーション）に登録してそれを引き出して画面に表示しているのだそうで、その際にUDIDを用いてそのユーザの位置情報を引き出しているのだという。

図1: 「電波チェッカー」の機能と使用した様子*3
右: 赤い四角の点と灰色の丸い点が登録した位置情報

これは原理的に言って、他人のUDIDがわかればその人の位置情報を閲覧できてしまうことを意味する。そのことを何度か申し上げたのだが、なかなか理解していただけなかったので、実証実験をすることにしたのだった。

実証の方法は何通りも考えられるところであるが、「UDID spoofing」でWeb検索したところ、すぐに「UDID Faker」というアプリが見つかった。これは、jailbreakしたiPhone OS用に配布されているもので、指定したアプリに対してUDIDを差し替えることができる。その仕組みはおそらく、指定のアプリについてAPI呼び出しをフックしてUDIDを差し替えているのだろう。

実験に際して、自分のiPod touchをjailbreakするのが面倒だったので、jailbreak済みのiPhoneを常用している知人に協力を依頼した。jailbreak済みのiPhoneにこの「UDID Faker」をインストールしてもらい、それを借りて、自分のUDID（図1のiPod touchのUDID）をセット（図2左、同図中央）して「電波チェッカー」を起動した（同図右）。

図2: 知人のiPhone上に私の位置情報が表示された様子
左: 「UDID Faker」で「電波チェッカー」を対象にUDIDを差し替える設定をしている様子、
中央: 「UDID Faker」で設定を終えたときの様子、
右: UDIDを差し替えた状態で「電波チェッカー」を起動した直後の様子

このように、図1で登録した私の位置情報が知人のiPhone上に表示されている*4（同じ場所の点が地図上に現れている）。

実証できたことをCTOに伝えると、問題を理解していただくことができ、UDIDから位置情報を引き出すことができないよう、サーバ側（Webアプリケーション）で回避策がとられた。現在は、この危険はなくなっている。詳しい経緯はTogetterの「UDID他についてソフトバンクモバイルCTOとのやりとり」にまとめている。

このようなことがあったわけだが、これは、これまでに何度も書いてきたのと同様の事案である。

• やはり退化していた日本のWeb開発者「ニコニコ動画×iPhone OS」の場合, 2009年8月2日の日記
• ユニークIDがあれば認証ができるという幻想, 2010年4月11日の日記
• ケータイ脳が大手SI屋にまで侵蝕、SI屋のセキュリティ部隊は自社の統率を, 2010年4月17日の日記

よりによって今回は携帯電話事業者自身がこれをやってしまった。いかに「ケータイ脳*5汚染」が根深いものであるかがわかる。一般のインターネットとPC用のアプリケーションで、こういう作り方はしない。

一般のインターネットでは、継続的にユーザを識別する必要があるならば、ユーザ登録させる（パスワードを登録させる）のが普通である。しかし、日本のケータイWebでは、ユーザ登録を煩わしいものとみなし、何らかのID（契約者固有IDや端末シリアル番号等のID）だけでユーザを識別しようとする。それは、利便性のためだというのだろう。

しかし、同様の利便性を保ったまま、セキュリティ上（プライバシー上も）問題がない作り方はちゃんとあって、一般のインターネットとPCの世界で普通に使われている。*6

このことについては、今回のケースでも冒頭から申し上げた（図3）。今回のケースでは、アプリ専用の（セキュアな）独自IDを生成してそれを使えばよい。それによって、ユーザ登録なしに、同じ人からのアクセスであることを安全に識別することができる。*7

図3: まとめ「UDID他についてソフトバンクモバイルCTOとのやりとり」 より抜粋

こうしたランダムIDというのは、たとえば「Version 4 UUID」（UUID: Universally Unique IDentifier）として規格化されており、ITU-T Rec. X.667 や ISO/IEC 9834-8 にも記述されているというくらい、確立したやり方である。その無衝突性については、UUIDのWikipediaエントリの「Random UUID probability of duplicates」に説明がある。*8

というわけで、ここまで「ケータイ脳」が業界に深く根ざしているとなると、今後も、iPhoneに限らずAndroid等においても、同様の設計ミスで脆弱性を作り込んでしまう事業者が出てくるだろう。1年半前に「日本Androidの会」幹事の方が、以下のように発言していた。

• ユーザ認証情報の取得方法について, 日本Androidの会, 2008年12月14日

  一般的な携帯用サイトなどでユーザの確認を行う場合、機種固有番号(UID)を使うことが多いのですが、androidの場合これに類するものは取得可能でしょうか?

  android上のブラウザからWebサーバにアクセスした場合(サーバサイドで環境変数などから取得する等)と、androidアプリとしてJavaから取得することができれば、ユーザ認証がかなり楽になると思ったのですが、どうなんでしょう?

  ユーザ特定に使えそうかなぁと思ったもの
  ・アクティベート時に使用したgoogleのアカウント
  ・SIM上のIDや電話番号
  ・ハード上のシリアル番号

この方がその後改心されたかどうかは確認していない。

今回の「電波チェッカー」のように、携帯電話事業者自らがこういうやり方をしていたのでは、こういうのを助長してしまうのだから、CTO殿には以下（図4）のように申し上げておいた。

図4: ソフトバンクモバイルCTOにお願いしたこと
まとめ「UDID他についてソフトバンクモバイルCTOとのやりとり」 より

Web開発技術者向けの講演でお話ししたこと

5月22日のWASフォーラムカンファレンス2010で、「どうするケータイ認証」と題した講演をした。Twitterでの反応は以下にまとめられている。

• WASForumまとめ, Togetter, 2010年5月22日

そのときのスライドを以下に置いた。

• どうするケータイ認証（スライド）（PDF、1.9 MiB）

この内容の前半は、これまでの以下の日記エントリをまとめたものである。

• サイボウズOfficeも匙を投げた「簡単ログイン」, 2010年4月15日の日記
• ここまで破綻しているケータイID認証（簡単ログイン）, 2010年4月25日の日記
• まだまだ他でも破綻しているケータイID認証, 2010年4月27日の日記
• EMOBILEのX-EM-UID、はじめから破綻, 2010年4月28日の日記

後半では、この状況を理由に、Web開発者向けに「じゃあどうすればいいのか」を伝えた。その様子はマイコミジャーナルが報じてくださっている。

• 【レポート】"かんたんログイン"のセキュリティ問題とは何なのか? - WASForum 2010 (2) 「かんたんログイン」の代替案, マイコミジャーナル, 2010年6月7日

これまで幾度となく「かんたんログイン」の危うさを述べてきたが、そのたびに、「ケータイで毎回パスワードなんて無理だから」とつぶやく人がいた。そういう話じゃない。問題とされているのは、「かんたんログイン」と称して使われているケータイIDを用いた実装方法であって、「パスワードなしにログインすること」ではない。このことがどういうわけか理解されない。

パスワード入力の省略なんて、普通に一般のインターネットのPCサイトでも実現されている。Twitterの「次回から入力を省略」、mixiの「次回から自動的にログイン」、はてなの「次回から自動的にログイン」などのチェックボックスがそれだ。これと同じように作ればよい。*9*10

図5: 講演スライドより

そもそも、「かんたんログイン」というボタンがあること自体がおかしい。押すだけでログインするならば、ボタンを押す意味がない。アクセスしたら即ログイン状態になっていればいいわけで、何のためにボタンを押させるのか。

これはおそらく、かつて必要としていたものの残骸だろう。つまり、iモードIDがまだなかった2008年3月まで、docomo端末では（非公式サイトでは）「utn」属性を用いた端末製造番号送信を使う必要があり、それを使用すると、送信の可否を尋ねる確認ダイアログがポップアップする。これへの対応として、ボタンを押すことになっていたのではないか。アクセスしただけでポップアップが出るのは嫌がられるだろうから、一旦ボタンを押させていたわけだ。*11

図6: 講演スライドより「そもそもUIが変」

今やiモードIDを使っていて、それを使わなくなったのだから、こんなユーザインターフェイス自体ナンセンスなのに、なぜこんなボタンを付け続けているのだろうか。

こういうボタンがわざわざあるおかげで、なんだかトクした気分になる人たちがいるようで、以下の女子大生の会話がまさにその状況を表している。

図7: 女子大生の会話

おそらく、サイト運営者の発注者が「かんたんログインを付けてくれ」と要求仕様に入れてくるのは、この女子大生と同様、ボタンがないと不便になると思い込まされているからだろう。

だからもうこういうボタンは取っ払おう。「かんたんログイン」とかいう言葉を使う必要もない。要求仕様には「ログイン状態を維持できる機能」と書けばよい。

その他、講演では、今この対処をしておく必要性について述べている。つまり、ケータイIDの他の問題（プライバシーの問題）を解決するにあたり、「かんたんログイン」ボタンの蔓延が障害になるからである。

図8: 講演スライドより「今後対策が進められる可能性、事前に準備しておくことを推奨」

日本のインターネットを終了させないために、いまから「かんたんログイン」を撤廃し、ログイン状態の維持をcookieによる実装に切り替えていこう。

研究者向けの講演、消費者団体向けの講演でお話ししたこと

一昨日、電子情報通信学会の、インターネットアーキテクチャ研究会（IA）と情報通信システムセキュリティ研究会（ICSS）共催の研究会で、招待講演の枠でお話をさせていただいた。Twitterでの反応は以下にまとめられている。

• ICSS 11 （第11回情報通信システムセキュリティ研究会）, Togetter, 2010年6月17日

そのときのスライドを以下に置いた。

• 瀬戸際に立たされた日本のWebプライバシー 〜研究者にできることはないのか〜（スライド）（PDF、3.4 MiB）

こちらの講演では、技術的な話はすっ飛ばして、これまでの経緯の説明と、社会的背景、行政と法律家の現状について紹介している。

会場では何名ものNTTの研究所の方々、KDDI研究所の方々が話を聴いてくださっていた。

スライドをいくつか挙げておく。

図9: 講演スライドより

この講演の後、何人かの方々から、「そんなことになっているとは知らなかった」という声を頂いた。まだまだぜんぜん周知が行き届いていない。

IPv6を研究テーマにされているというある方は、IPアドレス（の上位アドレス）をあえて動的に変更する必要性があることについて、「そういう方向性の研究テーマがあるとは思わなかった。面白いかもしれない」とおっしゃっていた。しかし、それは単にISPの払い出しポリシーで解決することなので、研究にならないだろう。必要なのは、ISPの業界ガイドラインを作ることである。

そのためには、セキュリティやプライバシーの研究をしている研究者らが、もっと皆で、こういうのは問題だということを社会に向けて言い続けていくことが必要であり、英語圏ではそういうことが行われてきたから、あのように問題あるシステムが普及することなくここまで来ているのだと思う。

プライバシー技術の論文を書くとき枕にする問題定義の記述は、本気でそう思って書いているのか？ と問いたい。

同様の話は、5月に、消費者団体主催の講演で、消費生活センター関係者や弁護士の方々向けにもお話ししている。そのときは、国民生活センターが「IDから住所氏名がわかることは絶対にない」と案内していることの誤りについて、消費生活センターの方から「常識が覆されて頭が混乱している」という発言があった。ぜんぜん周知が行き届いていない。小さな講演では十数人にしか声が届かない。

なお、「悪質利用者排斥」のところの内容は、スライドからでは意味がわからないと思われるが、それについては、日を改めて、詳しくここに書く予定だ。

総務省がパブリックコメント募集中

総務省が、5月26日に「SIMロック解除に関するガイドライン（案）」を発表し、これに対するパブリックコメントを募集している。SIMロック解除がどう関係あるのかと思われるかもしれないが、このガイドライン案の「8. その他」のところに次の記述がある。

(1) プライバシー上のリスクに対する取組

コンテンツプロバイダが同一の利用者からのアクセスであることを継続的に確認するための仕組みについて、SIMロック解除に伴い、利用者の意図しない名寄せ等プライバシー上のリスクが増大する可能性があることから、事業者は、リスクを軽減するため所要の措置を講じるものとする。 

「コンテンツプロバイダが同一の利用者からのアクセスであることを継続的に確認するための仕組み」とは、ケータイIDのことを指している。

「SIMロック解除に伴い（略）プライバシー上のリスクが増大する可能性がある」とはどういうことか。これは、「携帯電話端末のSIMロックの在り方に関する公開ヒアリング配布資料」にある、「特定非営利活動法人東京都地域婦人団体連盟説明資料」に書かれている。

つまり、SIMロック解除がなされると、その先の展開として、利便性向上のためにケータイIDの統一化が実施されると考えられることから、そうなれば、現在も問題があるケータイIDのプライバシー上のリスクが、さらに拡大することになるから、今のうちにリスク軽減に取り組む必要があるということのようだ。

「SIMロック解除がなされると、ケータイIDの統一化が実施される」というのはどういうことかというと、元々、総務省がSIMロック解除の方針を打ち出したのは、2007年のモバイルビジネス研究会であり、そこでは同時に「ユーザIDポータビリティ」の実現も謳われていた。

• 「モバイルビジネス研究会」第10回会合：販売奨励金分離、SIMロック解除、MVNO推進──最終報告書案を提示, ITmedia, 2007年9月19日

  プラットフォーム機能の連携という点では、利用者の利便性向上を理由に、MVNOにも認証・課金機能やプレゼンス情報などを適正な対価で利用できるように環境を整備すべきだとする。特にユーザーIDのポータビリティは、キャリアを変えても同じコンテンツプロバイダからサービスを受ける際などに有効であり、2010年までに実現すべきものの1つに挙げた。

SIMロック解除の意義の一つは、一つの端末をSIMの差し替えによって複数のキャリアを切り替えて使えるようになることとされるが、現状では、たとえば、SoftBankの端末にdocomoのSIMを挿しても、iモードのサービスが利用できるようになるわけではないし、Y!ケータイのサービスも利用できなくなるのだろう。SIMロック解除に反対する事業者の人たちも、その点を挙げて「SIMロックを解除しても意味がない」と主張していた。総務省の「モバイルビジネス研究会」の結論は、その状況を打破することも同時にセットで促しているのであるから、SIMロック解除を契機に、その先の展開として、利便性向上のためにケータイIDの統一化が実施される可能性があるということだろう。

ケータイIDの問題がちゃんと認識され、SIMロック解除ガイドライン案に「プライバシー上のリスクに対する取組」が盛り込まれたことは、大いに評価されるべきことである。

しかし、ガイドライン案が要求していることは、「事業者は、リスクを軽減するため所要の措置を講じるものとする」と、漠然としたものであり、これだけでは、どういう対策がとられるのかわからないし、何をもって対策がとられたと言えることになるのかも不明である。

おそらく、守旧派の人たちは「プライバシーの問題なんて存在しない」「何ら措置を講ずる必要がない」「かんたんログインが使えなくなる」といったパブコメを出してくるだろう。

ケータイIDのプライバシーやセキュリティに問題があると思う人は、ちゃんとパブリックコメントで意見を提出しよう。

どうあるべきかについては、たとえば、総務省の「通信プラットフォーム研究会」報告書に、ケータイの認証とプライバシーのあり方についていろいろ書かれているから、そういった方針に従うよう促すことなどが考えられる。

提出期限は、6月23日水曜日の18時。