<前の日記(2010年06月05日) 次の日記(2010年07月02日)> 最新 編集

高木浩光@自宅の日記

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

2010年06月19日

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

目次

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

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

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

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

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

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

iPhone OSの画面 iPhone OSの画面
図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左、同図中央)して「電波チェッカー」を起動した(同図右)。

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

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

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

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

よりによって今回は携帯電話事業者自身がこれをやってしまった。いかに「ケータイ脳*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)のように申し上げておいた。

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

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

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

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

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

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

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

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

スライド スライド スライド スライド
図5: 講演スライドより

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

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

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

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

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

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

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

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

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

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

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

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

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

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

会場では何名もの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ポータビリティ」の実現も謳われていた。

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 実際、公式サイトでは、こうしたボタンがなく、アクセスしただけでログイン状態になるサイトが大半である。

本日のTrackBacks(全4件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20100619]

以前より高木氏が、携帯電話の固体識別情報の問題点についての記事を書かれているのだが、新しい記事が上がっていたので読んでみた。 今こそケータイ電話IDの解決に向けて 高木氏の記事はいつ読んでも力強いなーとちょっと感心してしまう。 さて、高木氏が問題としている、..

インプレス提供の無料 PDF に応募してゲット。
ようやく読み終わった。

こわいなぁ。イナガワジュンジの怪談より怖い気がする。...

固有ID系の問題で,昨日の未明から燃えているな.勉強しようと思う.見てみたがなんじゃこりゃー状態.
出回る前に何とかしてほしい.

問題のメディアプレイヤーの仕様解説:
http://megalodon.jp/2011...

検索

<前の日記(2010年06月05日) 次の日記(2010年07月02日)> 最新 編集

最近のタイトル

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

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|
<前の日記(2010年06月05日) 次の日記(2010年07月02日)> 最新 編集