携帯電話のいわゆる「かんたんログイン」機能における成りすまし問題について、アプリ編はあちこちで書かれているのでキャリア編を書いてみます。まず、問題の概略から。
仕組みとしては図の上のようになり、携帯サービスA,B,Cの全てに対して利用者aはxxxa、利用者bはxxxbという同じuidでアクセスすることになります。このため、
などの問題があり、サービス側だけでの完全な対策は厳しいと言えます。
そうした背景もあり、キャリアの方でできる対策はないかと考えたとき、ShibbolethというSSOで使われているStoredIDを応用すると多少は状況がましになるような気がしてきました。これをかんたんログイン機能向けにモディファイした方法を以下に述べます。
この方法では、キャリアゲートウェイが携帯からインターネットへのアクセス口とSSOにおけるIdP(認証サーバ)の役割を兼務します。また、端末から送信されてきたuid情報はすべて廃棄し、アクセスしてきた端末の回線情報から契約者のIDを生成して、それをuidとして送信します。フィールドとしては互換性を持たせるためにiモードID(HTTP_X_DCMGUID)、ez番号(HTTP_X_UP_SUBNO)、およびX_JPHONE_UID(HTTP_X_JPHONE_UID)を使っても良いですし、新しい X_****_TARGETED_UIDのようなフィールドにしても良いでしょう。
このフィールドでは以下のルールでuidが提供されます。
具体的なuidの例は図の下のようになります。利用者aが携帯サービスAにアクセスするとき、uidとして'xxxa'ではなく、'xxxaA'という値が渡されます。これは利用者aがサービスAにアクセスする時は必ず同じ値です。いっぽうでサービスBにアクセスした時は'xxxaB'、Cでは'xxxaC'というサイトごとに異なるuidが渡されます。利用者bも同様です。こうすることにより、サービスAの提供者に悪意があり、かつキャリアゲートウェイにも穴があって、これを介してサービスCに成りすましアクセスしようとしたとしても、オリジナルやサービスCにおけるuidが分からないため、Cのかんたんログイン機能は使えません。注意点として、uidの表現に必要な名前空間は既存の方法では利用者数分だけで済みましたが、この方法では利用者数×サービス数分が必要となります。
uidは例えば以下のキーを繋げた文字列のSHA-1ハッシュなどにします。
利用者識別子 現在の各社uid サービス識別子 各携帯サービスのサーバのfqdnまたはIPアドレス salt ランダムな文字列
おそらく今でも利用者の携帯電話から各サービスに渡すuidを求めるためにテーブルを引いているはずですから、そこにハッシュ関数を1段入れれば比較的容易に実現できそうな気がします。またStoredIDのように一度計算したハッシュをDBに保存すれば、時間のかかるハッシュ関数を使っていても2回目以降のアクセスではレスポンスを向上させることができるでしょう。
ただ、この方法でも信頼できるIdPとしてのキャリアゲートウェイのリストはどうしても必要になります。こうしたリストについては、キャリア側でhttpsなサーバ上にxmlファイルとかを提供してもらい、サービス提供者側は日に1回ぐらいクロールして随時更新する枠組みなどが欲しいところです。
この方法のメリットとしては、以下のようなものが考えられます。
逆に問題点もあります。
iPhoneによりキャリアとメーカの関係が変わったという話がありましたが、キャリアはいいかげん端末に関しては何でもありな状況を想定し、それでも耐えうる枠組みの構築を真剣に考え、早急に実行する必要があるのではないでしょうか。
.green. ====