2010年06月19日
■ 今こそケータイ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を用いてそのユーザの位置情報を引き出しているのだという。
これは原理的に言って、他人の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左、同図中央）して「電波チェッカー」を起動した（同図右）。
左: 「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
こうしたランダム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）のように申し上げておいた。
まとめ「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
そもそも、「かんたんログイン」というボタンがあること自体がおかしい。押すだけでログインするならば、ボタンを押す意味がない。アクセスしたら即ログイン状態になっていればいいわけで、何のためにボタンを押させるのか。
これはおそらく、かつて必要としていたものの残骸だろう。つまり、iモードIDがまだなかった2008年3月まで、docomo端末では（非公式サイトでは）「utn」属性を用いた端末製造番号送信を使う必要があり、それを使用すると、送信の可否を尋ねる確認ダイアログがポップアップする。これへの対応として、ボタンを押すことになっていたのではないか。アクセスしただけでポップアップが出るのは嫌がられるだろうから、一旦ボタンを押させていたわけだ。*11
今やiモードIDを使っていて、それを使わなくなったのだから、こんなユーザインターフェイス自体ナンセンスなのに、なぜこんなボタンを付け続けているのだろうか。
こういうボタンがわざわざあるおかげで、なんだかトクした気分になる人たちがいるようで、以下の女子大生の会話がまさにその状況を表している。
おそらく、サイト運営者の発注者が「かんたんログインを付けてくれ」と要求仕様に入れてくるのは、この女子大生と同様、ボタンがないと不便になると思い込まされているからだろう。
だからもうこういうボタンは取っ払おう。「かんたんログイン」とかいう言葉を使う必要もない。要求仕様には「ログイン状態を維持できる機能」と書けばよい。
その他、講演では、今この対処をしておく必要性について述べている。つまり、ケータイIDの他の問題（プライバシーの問題）を解決するにあたり、「かんたんログイン」ボタンの蔓延が障害になるからである。
日本のインターネットを終了させないために、いまから「かんたんログイン」を撤廃し、ログイン状態の維持をcookieによる実装に切り替えていこう。
研究者向けの講演、消費者団体向けの講演でお話ししたこと
一昨日、電子情報通信学会の、インターネットアーキテクチャ研究会（IA）と情報通信システムセキュリティ研究会（ICSS）共催の研究会で、招待講演の枠でお話をさせていただいた。Twitterでの反応は以下にまとめられている。
- ICSS 11 （第11回情報通信システムセキュリティ研究会）, Togetter, 2010年6月17日
そのときのスライドを以下に置いた。
- 瀬戸際に立たされた日本のWebプライバシー 〜研究者にできることはないのか〜（スライド）（PDF、3.4 MiB）
こちらの講演では、技術的な話はすっ飛ばして、これまでの経緯の説明と、社会的背景、行政と法律家の現状について紹介している。
会場では何名ものNTTの研究所の方々、KDDI研究所の方々が話を聴いてくださっていた。
スライドをいくつか挙げておく。
この講演の後、何人かの方々から、「そんなことになっているとは知らなかった」という声を頂いた。まだまだぜんぜん周知が行き届いていない。
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時。
*1 UDID（Unique Device IDentifier）とは、iPhone OS独自の端末識別用IDで、その用途については「UDID」でWeb検索してみればわかる。
*2 OpenPNEの話題で始まる部分以降が別件。
*3 実際には自宅でも使用したのだが、それは公開したくないので、ここでは、秋葉原で昼食に出かけたときに使用した際の画面を掲載している。
*4 ここでは秋葉原の場所だけを見せているが、私の自宅の位置も表示された。
*5 ここで言う「ケータイ脳」とは、Web開発技術者が蛸壺化し、日本のケータイでしか通用しないやり方を当たり前のものと思い込んで、他の作り方に発想が及ばず、スマートフォンやiPhoneにまでケータイのやり方を適用しようとしてしまう事態のことを指す。
*6 一般に、「セキュリティと利便性のトレードオフなんだからしかたがないんだ」と易々と主張する人をしばしば目にするが、それは単に解決策を知らないが故の思い込みであり、思考をそこで止めようとしている自分を慰める言葉でしかないことに気付いてほしい。
*7 専用アプリでなく、WebブラウザでアクセスさせるWebサイトの場合には、この方法が通常は使えない。それは、専用IDをcookie等に記憶させるしかなく、cookieは容易に削除されてしまうものだからである。それに対して、専用アプリの場合には、ローカルデータとしてIDをある程度安定的に保存させておくことができる。それが消えるようなときは、登録データも閲覧できなくなるが、それをやむを得ないものとして割り切るサービスの場合は、この方法が使える。たとえば、ゲームのハイスコアのように、消えてしまうのがユーザに予見できるサービスがそうであるし、そもそも日本の携帯電話では、機種変更で継続できなくなるのが受け入れられるようなサービスがたくさんある。また、そうでなくても、ローカルデータの移行手段が用意されていれば、永続的に利用することもできるだろう。
*8 なお、今回のような、独自アプリが単独でユーザを同定するだけの用途では、UUIDのフォーマットに従う必要はない。独自の長さの乱数により、さらに長く安全なIDを使うこともできる。
*9 ケータイの狭い画面では、パスワード入力欄の下にチェックボックスがあるというUIがよくないかもしれないが、それならば、パスワードでログインした直後の画面に、「今後パスワードなしでログイン状態を維持する」というボタンなり、設定画面へのリンクを設ければいいだろう。ケータイIDによる「かんたんログイン」だってそういう設定画面を用意しているのだから。
*10 cookie方式だと、そのうち消えてしまうことがあるのが心配の種なのかもしれないが、消えたらまたパスワードでログインすればいいだけの話だ。むしろ、二度とパスワードを必要としない「かんたんログイン」方式では、パスワードを忘れられてしまう問題（携帯電話解約時に問題になる）が出てくるのだから、何十回かに一度パスワードを求められるくらいがちょうど良いはずだろう。
*11 実際、公式サイトでは、こうしたボタンがなく、アクセスしただけでログイン状態になるサイトが大半である。