前回の記事から3年もしてから続編もないものだと思うけど、ちょっと興味深いことに気付いたのでまとめてみる。
とは言えもしかしたらこのことは周知のことであり気付いている人には目新しいことでも何でもないかも知れない。
まずは前回のおさらいから。
端末IDとか個体識別番号とかサブスクライバーIDとか呼ばれる「端末や契約を識別するために端末側やゲートウェイから送出される識別ID」が偽装できるのかどうか実験と考察をしてみた。
docomoのUTNやSoftBankのシリアル番号などのように「端末から直接送出されるID」は携帯網にスマートフォンを接続するなど任意のアプリを実行可能な環境では詐称可能なことを示した。これは例えばUser-Agent環境変数を偽装するだけなので非常に簡単だ。少なくとも当時から現在においてもこれらを認証に利用することは全く持って推奨されない。
またその時実験は行えなかったが、docomoのuidやSoftBankのx-jphone-uidのようにゲートウェイが付加する(であろうと推測される)IDについてはゲートウェイが正しく付加したり偽装を判別するならば偽装は難しいだろう、というのが結論だった。
逆に言えばもしゲートウェイが騙されるようなリクエストが作成できれば偽装も可能だろうと推測したのだが、実際そうした事例もあったようだ。
実はその後エントリーにはしなかったのだけど、自作のWindowsMobileアプリを搭載したスマートフォンをSoftBankの携帯網(WAP)とイーモバイルのEMNetでx-jphone-uidとX-EM-UIDを偽装してみたがゲートウェイでは正しく本来の端末IDに置き換えてくれた。つまり偽装対策はゲートウェイにて正しく行われているようだ。
但しdocomoとauでは環境が整わなかったので試しておらず未確認だ。
さてその前提で、面白い資料を発見した。元々端末IDに関して各社の仕様を網羅的に記した有意義な資料なのだが、特に以下の部分に注目して欲しい。
用途 | ||||||||
分類 | UTN | iモードID | NULLGWDOCOMO | EZ番号 | SB公式UID | SBシリアル番号 | ||
公式連携 | × | × | ○ | ○ | ○ | × | ||
勝手サイト | ○ | ○ | × | ○ | ○ | ○ | ||
SSL対応 | ○ | × | × | ○ | △ | ○ | ||
URLだけで使用 | × | ○ | ○ | ○ | ○ | ○ | ||
ログインに使用 | ○ | ○ | ○ | ○ | ○ | ○ | ||
URL漏洩時の なりすまし防止 |
△ 不向き |
○ | ○ | ○ | ○ | ○ | ||
SSL URL漏洩時の なりすまし防止 |
△ 不向き |
× | × | ○ | △ GW-SSLのみ |
○ |
「SSL対応」という箇所がある。docomoのUTNとSBシリアル番号およびauのEZ番号のみが○である。
SB公式UID(x-jphone-uid)はSSLゲートウェイを指定すればOKだが他については全て×だ。
これは大変重要な事実を示している。
UTNとSBシリアル番号が○なのは当然だ。SSLはポイント・トゥー・ポイントプロトコルであり、つまりブラウザ (この場合は端末)とWEBサーバーが直接暗号通信することで通信が傍受されたり改変されないことを保証するからだ。逆に言えば通常の携帯ゲートウェイがこの直接通信に介入することはできない(SSLゲートウェイは端末<->SSLゲートウェイ<->WEBサーバという2つの通信を見かけ上束ねているだけだ)。
なのでiモードIDやNULLGWDOCOMO、SB公式uidがSSLに対応しないのはゲートウェイでHTTPヘッダーを付加する必要があるから、と理解することが出来る。つまり当然の帰結なのだ。
しかしauのEZ番号(X-Up-Subno)は全てにおいて○だ。SSLにも対応している。
このことから分かるのは、EZ番号は端末から直接送信しておりゲートウェイは何ら偽装対策を行っていないはず、ということだ。
残念ながら(?)、環境が準備できないので本当にそうなのか僕には確認することが出来ない。しかしSSLの理屈からはまず間違いなくEZ番号は端末から直接送出されており偽装対策はまず取られていない。
何度でも記すが、現在の日本のケータイWEB、特にケータイECを脆弱に支えているのは
(1) そのアクセスがそのキャリアの携帯網からのみであることをサービスプロバイダーが保証すること
(2) 携帯網では端末IDが偽装されていないことをキャリアが保証すること
(3) 端末の自由度を低くして端末IDの偽装などの可能性をできるだけ低く保つこと
という三位一体の原則だ。これが1つでも崩れれば信頼性は崩壊する。
しかしもし上記の推測が正しければ、ことauのEZ番号については(1)と(3)によってのみしか支えられていない。SIMロック解除論議を持ち出すまでもなく、例えばauの携帯網のアクセスポイント情報が明らかになってしまったら。そこにスマートフォンなどで任意のアプリを実行できる端末が接続可能になったら・・・? 恐らくサービスプロバイダーは偽装を見破る術を持たない。
それが現実になれば、恐慌にも似たケータイECの信用崩壊が起こる可能性が非常に高い。
様々な批判に晒される中で「それでも日本のケータイ技術は世界一なのだから」と嘯くのは自由だ。キャリアの皆さんは好きにすればいい。
しかしこんなにも脆弱な 技術に支えられたバブルをどのような理由で自慢できるのか、さっぱり理解できない。
これまで業界を支えてきたかも知れない日本のケータイ技術はすでに賞味期限切れなのだ。そのことに早く気付いて行動を起こして欲しい。
消費者を人質に取るような寡占業界故の保身はすぐにも止めてもらいたい。
2010/4/13 追記しました。
大変興味深く拝見させていただきました。
一つ質問なのですが、仮にEZ番号が端末から直接送出されていると考えた際に以下の仕組み(送出の有無)はSSL接続時にどのように実装されているのでしょうか?
http://www.au.kddi.com/news/information/au_info_20050404.html
HTTP通信時にゲートウェイにて端末から送出されたEZ番号を削除する処理というのは思いついたのですが、HTTPS通信では書き換えができないのでこの辺の振る舞いをご存じでしたらお教え願います。
仕様を知っている訳ではありませんが、ゲートウェイでの設定を端末にダウンロードするのでは無いでしょうか(想像です)
素晴らしい追及だと思いました。
auで試させて頂きたいのですが、
具体的にどうすればいいのでしょうか?
追記 http://blog.rocaz.net/2010/04/873.html もご覧下さい。
こちらにも書いている通りですが、接続する携帯網のアクセスポイント情報とau携帯網へ接続可能で任意のプログラム(HTTPヘッダー改変可能なもの)実行可能な端末を準備する必要があります。理論上は不可能ではないのですが、敷居が高いので通常は試せないと思います。
但し他社事例ですがSBですと携帯端末からのパケット通信設定したPCから携帯網に接続できたり(なので任意のHTTPヘッダー改ざんも可能なはずだが、やはりアクセスポイント情報は必要)、ブラウザがJavaScript(Ajax)に対応したことで一部のHTTPヘッダー改ざんが出来たりという事例もあるようなので、同じような手法が可能な可能性もあるかも知れません。
要するに「従来の携帯網に接続された端末で任意のHTTPヘッダーが改変できるアプリが走らせられたらアウト」という推測です。
http://koookie.posterous.com/softbank-mobilegatewaypc-perlmemo
http://d.hatena.ne.jp/hideden/20090801/1249142985
https://www.hash-c.co.jp/info/20091124.html
http://www.hash-c.co.jp/info/2010052401.html
サイボウズ製品に脆弱性、携帯固有IDでなりすましログイン可能
http://internet.watch.impress.co.jp/docs/news/20100420_362514.html
こんなニュースが出てきました