「IT」カテゴリーアーカイブ

2011-10
20
12:44:55
ドコモ メディアプレーヤーによるIMEI送信に関する公開質問状(とりあえず終了)


(2011/11/19 更新)

(2011/11/18 更新)

(2011/11/11 更新)

(2011/10/29 更新)

取り急ぎ、一般向け窓口宛ではありますが個人的に以下のような公開質問状を送付しました。

やり取りが発生しましたら追記していきます。経験上、最初の回答までには一週間はかかると思います。。。

(2011/10/20) 送付した公開質問状

お世話になります。

先般貴社WEBサイトにて今秋のスマートフォンに搭載されるメディアプレーヤーよりアクセス時のUserAgent情報にIMEIが
付加されるとの発表がありました。
参考: http://j.mp/nJWr9k
これに関しまして以下ご質問させて頂きます。

1. IMEIをUserAgentに付加されることにした意図・目的は何でしょうか

2. 一般にこうしたIDに変動が無く恒久的に容易にユーザートラッキングできる問題はプライバシー上「Super Cookie」
(参考: http://www.horibemasao.org/takagi.ppt3.pdf)問題として広く知られておりますが、こうした問題について
今回どのような検討をされましたか

3. こうしたSuper Cookieが標準で搭載された場合、本来単独では個人が特定できないはずの情報が完全な個人情報として
容易に流通する可能性が高くなります。こうした問題に対してどのような対策を講じようとされていらっしゃいますか。

4. 上記の通り、コンテンツプロバイダー(公式サイトに限りません)はこれまではほぼ不可能だった利用者端末のIMEIを
容易に入手できるようになる訳ですが、これは問題あると考えていらっしゃいますか。あるいは無いとお考えでしょうか。
いずれかにおいて、その理由は何でしょうか。

5.テレビ新聞で報道されている通り「ユーザー同意無く端末情報を取得するスマートフォンアプリ」が複数見つかり
スパイウェアと批判を受けたり更に不正指令電磁的記録取得罪に問われるのではないかとの報道もあります。
これは利用者にアプリケーションの動作を正確に説明していないためですが今回の仕様について利用者にどのようにまた
どの程度のご説明をされていらっしゃいますか。

6. プライバシー問題が大きくクローズアップされている現在、今回のような仕様の導入は早急に中止すべきと個人的には
考えますが、中止されるあるいは検討されるご予定はございますか。

以上です。

なおこの質問は公開質問であり、インターネットなどによって一般に公開される旨、あらかじめご了承下さい。
またご回答はひとまとめではなく、上記一問に付き一答ずつお願い致します。

以上、大変お手数ですがご回答賜りますようどうぞ宜しくお願いします。

 

(2011/10/28) ドコモからの回答

ドコモからの回答がありました。
コメントにもありますように、その後ドコモは「IMEIはメディアプレーヤーがライセンスを取得する際のみ」であることを公表しており回答もそれに沿ったものになっています。
以下、回答を簡単にまとめます。

  •  音楽・動画コンテンツ再生時に端末を限定するためにIMEIを利用する。メディアプレイヤーではライセンスを確認する際にのみC/P側へ問い合わせる
  • AndroidであればIMEIを取得するアプリを作成することはそもそも可能。今回はその前提でメディアプレーヤーのみに限定しており、名寄せされる危険性を最小限にしている
  • 送出時には許諾画面を表示して注意喚起をしており送出しないことも可能な仕様にしている。従ってIMEIを広く収集される危険性はないと考えている
  • 現時点で仕様中止の検討はしていない

ポイントは「IMEIはC/Pサイドにも送信されうる(模様)」「ユーザー許諾を取るので問題無い」としている点となるでしょうか。

 

(2011/10/29) 再質問

当方より再度以下の内容で質問をしました。

お世話になっております。お忙しい中ご回答頂きまして誠にありがとうございました。
下記拝見させて頂きました。その上で追加にてご質問させて頂きたく、再々申し訳ありませんがご回答願えませんでしょうか。
お手数ですが前回と同じく、ひとまとめではなく一問一答にてお願い致します。
なお下記にもご回答頂いております通り、貴社WebサイトにてもIMEI送信はメディアプレーヤーでのみとなっている旨
記載が変更されている点は後日拝見致しました。

1. IMEIをPlayReadyでの端末特定のためのDRM管理キーにされている(あるいはその予定)とのことと理解致しましたが、
これはマイクロソフト殿での仕様でしょうか。若しくはドコモ殿の判断ですか。

2. 端末判別に何故IMEIが必須でしょうか。一般によく知られている手法のように、例えばUUID(C/Pごとに異なるキー。
PlayReadyで言えばドメインごとに異なるキー体系)でも十分なのではありませんか。IMEIで無ければならない積極的な
理由はありますか。

3. メディアプレイヤーの仕様としては、ドコモ殿のサイトへ接続する場合のみIMEIを送信するのでは無く、
例えばC/P殿が独自に設置された(つまりコンテンツが指定した)ライセンスサーバーでも無条件でIMEIは送信される、
ということでしょうか。

4. 3がYESの場合、全くドコモ殿が預かり知らないところでもIMEIは取得可能になろうかと思います
(例えば「勝手サイト」など)。その場合、ドコモ殿がコントロールできることでは無い以上、「IMEIを広く収集される
危険性はない」ということはあり得ないと思われますがいかがでしょうか。

5. 重ねての質問にもなりますが、「ユーザー許諾を取っている」とのことですが、具体的にはどのような周知にて
お客様へお伝えされていますか。例えば、そもそもほぼ全ての一般のお客様はIMEIが何であるのか、名寄せのリスク
とは具体的にどのようなことなのかはほぼご承知では無いでしょう。そこを十分理解して頂かずに形だけ許諾をとっても
実質が伴わなければオプトインでは無いというのがプライバシー上でも民法上でも一般的な考え方です。
先の「スパイウェア」とされたアプリでも形だけの許諾を前提にしていたため、スパイウェアとして理解されるように
なりました。
その前提で、どのようにユーザーへの啓蒙と理解を図られようとされていますか。

6. IMEIのように恒久的に値が変わらずユーザーを特定し続ける所謂「固定ID」については容易に個人情報と
結びつけやすいことから、個人情報として取り扱うべきだ、とのセキュリティ研究者からの意見もあります。

参考: http://www.atmarkit.co.jp/news/analysis/201110/27/smartphone.html

この点に関し、ドコモ殿のご見解をお聞かせ下さい。

以上です。
なお最後に、「メールの一部または全部を転用したり、二次利用することはご遠慮いただ」きたいとのことですが、
どのような根拠・理由によるものでしょうか。
既に十二分にご理解されているのでは無いかと察しますが、本件は現在ネット上含め大変注目されている
「利用者プライバシー」に関わる問題であり、社会的意義の大変大きな問題です。故に最初のメールにても
申し上げました通り「公開質問状」として送付させて頂きました。
ドコモ殿のご見解を適切に引用・周知することは社会公益の点からも大変重要と考えており、随時適切かつ適正に
引用・周知致します旨、何とぞご理解下さい。

以上となります。

お忙しい中大変恐縮ですがどうぞご回答賜りますよう、宜しくお願い申し上げます。

(2011/11/10) ドコモからの回答

以下、ドコモからの回答の要約です。

  • IMEIはCP様が設置されたライセンスサーバーにも送出する
  • IMEIをDRMキーとして考えているのは一部C/P様で必要とされることも想定し、CP様側にて総合的に判断・制御可能として頂けることを想定している
  • IMEIの送出契機はPlayReadyのライセンス確認時に限定され、送出時には以下のような許諾画面を表示して注意喚起し、IMEIを送出しないことも可能として、リスクを最小限化している

—————————————————————-

ライセンスを取得しますか?

ライセンスの取得時には通信が発生します。

また、その際、携帯電話の識別番号(IMEI)が送信されます。

はい/いいえ

—————————————————————-

  •  IMEIのような各種IDに関する法令上の取り扱いについては監督官庁の指導に基づくものと理解している。情報の取り扱いの重要性については十分認識しているのでお客様への注意喚起等の取り組みを行っている
  • 注意喚起として最低限の役割は果たしていると考えているが、指摘頂いた点も踏まえお客様に対してより分かりやすい形でご認識いただけるような改善策を今後検討していきたい

 

(2011/11/11) 再々質問

当方より再々度以下の内容で質問をしました。

お世話になっております。お忙しい中、ご回答誠にありがとうございました。
再々申し訳ございません。
下記ご回答を受けまして再々度ご質問させて下さい。

1.  念のためご確認させて下さい。「IMEIを送出しないことも可能な仕様」とは許諾画面で許可しないことで、
そもそもライセンス取得を行わない、ということを意味していらっしゃいますか。ライセンス取得には行くがヘッダーに
IMEIは付加しない、という意味ではありませんよね?

2. CPのライセンスサーバーではどのような仕様かは分からないものの、IMEIを送出する仕様となっている、
との理解で宜しいでしょうか。つまり実際のライセンス確認方法はCPさんにより異なるということですね。

3. これは個人的な意見ともなりますが。IMEIの送出はそもそもCPさんへのやむにやまれぬ配慮であり、
またプライバシーへの危険性についてもユーザーに今後具体的に周知・啓蒙されていくと言うことでは理解しました。
特にユーザーへの周知はぜひ形だけに終わらず具体的な施策を期待致します。
その上ででもですが、やはりIMEIの送出は正当化できるものではないと考えます。理由は既に貴社にても把握して
いらっしゃる通り、「固定IDとユーザー情報の紐付け」を前提とした仕様はいかなる予防策を講じるにせよ
プライバシー上のリスクは制御できないからです。
恐らくはCPさんからの根強い要望もあった故であり本来であればドコモ様としては避けたかった事態では無いかと
推察はしますが、今後プラットフォーマーの役割としてはそうしたCPさんらがIMEIを使わずともUUIDなどでうまく
運用できる仕組み(例えば永続的にIMEIを使い続けなくともどこかの段階でUUIDや一般的なユーザー認証へ移行する
ことは技術的には可能でしょう)を提供される、あるいはそう誘導されるのもドコモ様の責務のうちでありユーザーへの
責任では無いかと思いますが、いかが考えられるでしょうか。

4. 固定IDの利用についてはリスクがあることを重々承知してらっしゃることはよく分かりました。
しかし一方で、これはIMEI送出だけに限らず、例えばやはり同じく永続的なキーであるiモードIDでも同様かと思います。
更にはiモードIDの場合はほぼ無条件ですべてのCPさんにて取得可能であり(通知可否は選択可能なものの)、
更に昨年よりスマートフォンでも取得可能となっています。
こうした状況を前提にお聞きしたいのですが(但しiモードIDに限らず固定ID送出の取り扱い全般として)、
下記にて「法令遵守・監督官庁指導に従う」「ユーザーへの注意喚起」を述べていらっしゃいますが、
そうしたリスクを捉えつつ利用を継続されるのは施策として矛盾していませんか。
3とも関連しますがプラットフォーマーの立場において、固定IDについてはどのようなポリシーにて運用されようと
していますか。将来廃止への方向性の意図はお持ちになられますか。

5. 固定IDを如何に安全に取り扱うべきか、またどのようなリスクがあるか、CPさんにせよユーザーにせよ、
具体的にどのように啓蒙・周知をされていく予定でしょうか。例えば勝手サイトを含めてCPさん向けに固定IDの取扱規則や
ベストプラクティスを公表する、ユーザーにiモードIDなどの固定IDにどのようなプライバシー上の危険性があるかの
これまで以上に踏み込んだ啓蒙など、予定されませんか。
ドコモさんでのそうした姿勢こそがスマートフォンを中心としたケータイ・ネットワークへの信頼性を高めるものであり、
隠し続けることは逆に疑念しか生み出さないと考えるものですが、どのようにお考えになるでしょうか。

最後になりますが、必要に応じたネット上での引用・周知については十分に適正・適切に行わさせて頂きますこと、お約束させて頂きます。

以上です。長々と申し訳ございません。
お忙しい中大変恐縮ですが、ご回答賜りましたら幸いです。
では、どうぞ宜しくお願い致します。

 

(2011/11/18) ドコモからの回答

  • 「IMEIを送出しないことも可能な仕様」とは「許諾しなければライセンスを取得しない仕様」を意味します
  • 実際のライセンス確認方法はCPさんにより異なり、IMEIを実際に使用するかどうかはCP次第
  • (3-5の質問に対して) IMEIなどの各種IDの取り扱い運用方法およびお客様への周知方法を含め、貴重なご意見をいただき誠にありがとうございます。ご懸念いただいている各種IDの法令上の取り扱いにつきましては、監督官庁の指導に基づき今後の対応の参考とさせていただきます。前回も同様の内容をお伝えさせていただきましたが、今回ご指摘いただいた点も踏まえ、情報の取り扱いについては十分に注意する必要があるということは認識しておりますので、引き続きお客様への注意喚起などの取り組みを行ってまいります

基本的には、まず問い質したかった「固定IDへの考え方・取り扱い方針」については回答拒否ですね。まあもう固定IDを送出しているのは事実なので答えにくいでしょう。但し懸念の表明という点では達せたかなと感じています。
ドコモ的にはこのあたりが限界なのでしょう。

別途、質問ではなく要望という形で先方には伝えて本件はとりあえず取り纏めということになるかと思います。

 

(2011/11/19) 要望送付

まとめとして以下を送付しました。

ご回答ありがとうございました。
全てのご質問に付き明確なご回答頂けなかったのは残念ですが、ご事情はお察し致します。
ご質問という形でさせて頂いて参りましたが、本日はドコモ様に対する「ご要望」として以下お聞き頂ければ幸いです。

1. 固定IDに関しての利用者への啓蒙

既に述べられていらっしゃいますように、今後注意喚起などの啓蒙を行われるということで期待しております。
現状固定IDでのプライバシーリスクについてはキャリア様から発信された情報はほぼ無く、
主に民間のセキュリティ研究者や団体が発信する内容ばかりです。キャリア様としてしっかりと正確に啓蒙・
注意喚起されることを期待しております。特に、正確に事実を利用者が理解しない限りはどのような許諾を得ようと、
恐らく法的にも意味をなさない点にはぜひご留意頂きたいと思います。

2. プラットフォーマーとしてのCP様への指導

あくまでCP様は対等のお立場のビジネスパートナーであることは承知の上で申し上げますが、
これまで頂いた回答をまとめると、結局のところはCP様が固定IDによる名寄せや利用者の了承を得ない
情報取得があれば、如何にドコモ様が「リスクをできるだけ低くしている」と主張されても全く意味を
なさなくなってしまうことはご理解されているかと思います。
つまり如何にして、利用者と同じくCP殿(勝手サイト含む)を教育し啓蒙していけるかが、
「リスクをできるだけ低くしている」との主張を現実的なことにできるかの鍵かと存じます。
こうした仕組みを広く提供されている以上、ドコモ様がどのようなお考えであろうとも世間では
ビジネスモデル全体に責務を負うべき「プラットフォーマー」として見なされるべきかと思います。
自由にCP殿にビジネスをして頂くことは重要でしょうが、一方でCP殿に「正しく」ビジネスをして
頂くように仕向ける責務をドコモ殿は負っていらっしゃるのだと考えます。
また例えば固定IDが必要と主張されるようなCP殿にはドコモ様自ら必要なくとも実現可能な
ソリューションを提供されるなど、そこまでのご認識と責務は負われるべきかと思います。
で無いのであれば、それは所謂「土管業」と何ら変わらなくなるからです。
こうした点が欠けていたからこそ所謂「かんたんログイン」の問題は起きましたし、
それを解決させたのはプラットフォーマーであるはずのドコモ様では無くまたCP殿自らでも無く、
市井のセキュリティ関係者の啓蒙でした。
しかしそうした「異常な」状況をこれ以上続けるべきではありません。

3. 固定IDが前提となるビジネスモデルの廃止と移行

一点ぜひ認識して頂きたいのは、これらプライバシーやセキュリティのリスク(たとえ低い可能性で
あるとしても)を背負うのはドコモ様でもCP殿でも無く、利用者自身だということです。
しかも利用者にそのリスクを避ける選択肢はほぼありません。
これは1,2とも関わることですが、故にプラットフォーマーとしての責任は重いと言わざるを得ません。
IDに関わるソリューションとしては様々取り組まれていると思いますが、固定IDビジネスは一般的に、
これまでのフィーチャーフォンのような「閉じた世界」では有用であったとしても、
スマートフォンが前提とする素のインターネットの世界では非常に脆弱です。
これは十二分にご承知の通りかと思います。
しかし未だ固定IDに引きづられるビジネスモデルがあるのだとすれば、スマートフォンへの移行という
この絶好のタイミング無くして廃止と移行のタイミングは今後存在しないでしょう。
ドコモ様ではiモードIDという古い固定IDビジネスの一方で、ドコモIDというインターネットとの
親和性の高い技術モデルもお持ちになっており、決して不可能なことでは無いと感じています。
繰り返しになりますが、これは選択肢を持てない利用者保護の観点からも、
強くドコモ様自身が推進されるべき方向性では無いかと存じます。

以上となります。長々と失礼致しました。
ぜひご検討頂き、技術関係者様・ビジネス関係者様含めて、上記ご回覧頂ければ幸いです。
またご意見・ご回答なども頂ければ嬉しく存じます。
末筆ながら貴社の益々のご発展をお祈り致しております。
以上、ありがとうございました。今後ともどうぞよろしくお願いいたします。

とりあえず一連の質問は終了とします。

別途まとめのエントリーを後日アップする予定です。

 

 

2011-07
02
01:55:07
オープン化への変貌とキャリアの隠蔽体質を考える – secure.softbank.ne.jpの問題を受けて


7月になってsecure.softbank.ne.jpという一種のSSLプロキシの廃止を受けて、高木さんと徳丸さんから続けて背景説明のエントリーが発表されている。

SoftBankガラケーの致命的な脆弱性がようやく解消
ソフトバンクのゲートウェイ型SSLの脆弱性を振り返る

簡単に言えばこのSSLプロキシの廃止は重大なセキュリティリスクを回避するために絶対的に必要だったと言うことなのだが、詳細はぜひ上記を参照して欲しい。

正直に言うと、この高木さんとソフトバンクモバイル宮川氏のやり取りの前に少しきっかけに関わったので興味を持ってみていたのだが、当初は発端となったアプリ側でのCookieの取り扱いにくさ以上の感触を得ていなかった。
それが違うなと思い直したのは両名が7月を前に盛り上がりだしてからで(笑)、それが同一生成元ポリシーに関わる問題であろうことはその後すぐ気付いた。
しかし実は水面下では、端末のJavaScriptを調整してsecure.softbank.ne.jpでの挙動のみ変更したいたことなどは今回のエントリーで始めて知った次第だ。
アクロバティックな対応だなと思うし、非常に感じるのはこれまで閉塞した世界でなら何も考えずとも良かった問題がJavaScriptやあるいは通信路の解放などといった「オープン化」によって大きく揺らいで行くであろう未来の姿だ。

先のエントリーで徳丸氏は以下のように述べている。

この事例から言えることは、(ガラパゴスと表現されることもある)日本の携帯Web独自の仕様というのものが非常にきわどく、もろいものだということです。

 

携帯Webの仕様がオープンにならないことも問題です。私は前述のJavaScript等の仕様を調べるために、公開されている仕様書だけでは十分でないために、実機での試行錯誤が必要でした。携帯Webの安全性確保のため、開発者やセキュリティ研究者に向けた十分な情報開示を希望します。

僕も全く同意見だ。
そもそもの問題はあまりに日本のケータイWEBがガラパゴスと言われるような独自進化をし、それはクローズドだったからまだよかったものの、ここへ来てスマートフォンに始まり、JavaScriptなどブラウザがリッチ化しOSはAndroidなどよりオープンなもの(逆に言えばキャリアやメーカーが手を加えにくい) となり、また通信路はWi-Fiや定められた端末しか繋げられない閉塞したものではなくPCなどと同居するよりオープンなものへと変貌しつつある。
日本のケータイシーンはただ端末がガラケーからスマートフォンへ置き換えられているだけではない。技術的な観点からすると「一般的なインターネット」へ変貌つつある。

問題はそうした急速な変化の中で果たしてキャリアはこうした旧世代の脆い仕様との乖離に伴う脆弱性に正しく対応可能なのか、ということだ。

少し古い話になるのだが、実は半年ほど前個人的に一ユーザーとして各キャリアに以下のような質問を行ってみた。

1. 具体例は示しませんが、近年携帯電話やスマートフォンに関して、セキュリティ上の脆弱性がネットなどで指摘されることが多くなってきました。
この1年間において御社にて脆弱性が発覚または発見しこれを修正などの対策をされた実績がありますか。ある場合、もし宜しければ具体例をお教え下さい。
2. 1のケースに関わらず、一般論で結構なのですが御社では脆弱性が発覚した場合修正し対応なさいますか。対応する/しないの判断基準はどの点だと認識していらっしゃいますか。
3. その場合、脆弱性があった旨ユーザーに情報を開示されますか。
4. 御社にてこうした脆弱性対応のためのポリシーを策定し運用されていらっしゃいますか。またそれは公開されユーザーへ周知されていらっしゃいますか。

各社様々経緯があり返答に時間もかかり結局一ヶ月近くかかった覚えがあるのだが、簡単にまとめると各社の回答は以下のようなものだった。

質問事項 脆弱性が発覚または発見しこれを修正などの対策をされた実績はあるか 脆弱性が発覚した場合修正し対応するか。対応する/しないの判断基準はどの点だと認識しているか 脆弱性があった旨ユーザーに情報を開示するか 脆弱性対応のためのポリシーを策定し運用しているか。またそれは公開されユーザーへ周知されているか
ドコモ 特に回答無し – ウィルス対策、パターン更新などの対策を行っている
– 対策の判断基準は脆弱性の程度や影響などを総合的に判断
– お客様にお伝えできる情報は弊社ウェブサイト等にて公開させていただきますことをご了承ください 特に回答無し
au – 脆弱性事例はあり(最近の例を例示) – システムに脆弱性があることについて事実確認されアップデートによって脆弱性が解消できることが判明した場合には必ずWEBサイトで告知を実施した上でアップデート対応を実施する – セキュリティに関わる問題については悪用される危険性があるため詳細な内容については公表しない。但し該当ユーザーについては個別に周知している 特に回答無し
ソフトバンク 弊社の機密事項に関するものとなるで社外への情報開示はWEBサイトで公開している内容のみでそれ以外は答えられない
イーモバイル 特に回答無し 特に回答無し – お客様に影響を及ぼす問題が発見された場合には、すみやかに情報を開示し対策を実施することとしています。
情報の開示方法は、弊社ホームページ上に掲載するケースや、
個別にご連絡する場合など案件によって最適な方法で実施いたします。
特に回答無し

 

多少の違いはあるが、どれも判で押したような特に具体性のない内容であることは間違いないだろう。
注目すべきはどこのキャリアも回答には数週間から一ヶ月かかっている、つまりあらかじめ想定している内容ではなく、 社内調整した結果の回答であったのだろう。それは脆弱性ポリシーの有無の質問に対していずれも明確な回答がなかったことからも察しが付く。
つまりは各社とも今回のような脆弱性への対処については明確な社内規定やルールがあり運用されている訳ではなく、発覚した場合のケースバイケースということなのではないだろうか。
これは一言で言って常に対処が後手に回り対処療法に陥りやすい危険な兆候とも言えるだろう。

「フルディスクロージャ」という言葉がある。これは「脆弱性情報を隠蔽しこれを知り得ている一部の悪意あるユーザーに悪用されるよりは、脆弱性情報を発見したらすぐに広くオープンにして全てのユーザーに完全に周知した方が安全だ」という考え方だ。
これはこれで極端な考え方で、例えば0Dayアタックと呼ばれるような一般ユーザーにこのような脆弱性から守る術を持たないうちから攻撃されるリスクが十分あるからだ。
そこまで極端なフルディスクロージャーは近年では採用されることは少ないが、しかし一方で上記のようなキャリアの態度というのは、これまた極端な「隠蔽体質」と言われても仕方ないだろう。

しかし実はこのフルディスクロージャーの考え方には、インターネット黎明期に脆弱性の隠蔽が頻繁に行われ、その結果被害が拡大した結果、反省と反発からの一種の極論から生まれたという背景がある。

キャリアが理解しているかどうかは分からない。しかし僕にはこれまでのキャリアは閉塞網と完全に制御された端末でのうのうと暮らしてきた「井の中の蛙」に見える。
スマートフォンの伸長は歴史の針を一気に進め、蛙を大海へ叩き込んだ、とも言えるだろう。
彼らが今後暮らさなければならない「本当のインターネット」の大海では、脆弱性情報は共有され適切に管理され、インターネット全体の安全性のバランスを取る仕組みと常識感が既に熟成されている。それはインターネットの巨大なプレーヤーとしてはほぼ責務と言っていい。 だがそんな「本当のインターネットでの常識」に付いていけるだけの力を身に付けられているだろうか。僕は甚だ疑問だ。

キャリア各社は今後スマートフォンへ軸足を移し、また「普通のインターネット」を提供したいと発言している。一方で各キャリア毎に課金・認証の仕組みを導入しようとしており、ドコモはiモードを、auはau one IDをすでにAndroidに組み込んでいるようだ。
けれど彼らは本当にそれらがインターネットの大海でどういう意味を持つか理解して実現できるだろうか。
僕はこうした脆弱性ポリシーや、インターネットでは当たり前の技術情報の周知1つ出来ていない現状では結局同じことを繰り返し、更に酷いセキュリティ問題を繰り広げる未来としか思えないのだ。

 

2011-06
20
03:07:46
ソフトバンク回線のパケットロスがひどいというので、ほんとーーにそうなのか確かめてみた


追記書いてます。

#softbank 携帯によるデータ通信でのパケロスは本当に酷いのか?

という話があって、聞こえてくる話では75%のパケットロスもあるのだという。
一般的にネットワークに関わる層には一概に信じられないロス率だが、Twitterなどで流れてくる数値ではよく信用できないのと、ある程度偏ったテスト環境になってしまっている気もしたので、ドコモ回線含め時間帯も変えて比較してみることにした。
テスト環境は以下の通り。

テスト概要
JailBreakしSIMフリー化したiPhone3GS(iOS4.2.1)にてソフトバンク iPhone通常回線(smile.world)とドコモ データ定額(mopera.flat.foma.ne.jp)で複数のサーバーに対してping(ICMP echo)テストを実施し、パケットロス率およびラウンドトリップを計測する。

テスト方法
SSHでiPhoneへログインし、Cydiaのinetutilsに付属するpingコマンドを計30回試行し平均値を得る。

テストサーバー

  1. www.yahoo.co.jp(ロケーション: 東京 丸の内 ブロードバンドタワー)
  2. www.google.co.jp(ロケーション: 恐らくアメリカ西海岸)
  3. テストサーバー1(ロケーション:アメリカ FremontにあるVPSサーバー)
  4. テストサーバー2(ロケーション: さくらインターネットのVPSサーバー。設置場所は不明だが国内)

テストは都内から行っている。また時間帯も変えることとし、とある日曜日のPM9時台と翌日AM2時台の二度行った。

結果は以下の通りである。

テストケース1: PM9時台に実施

フレッツ光(Wi-Fi)
packet loss min avg max stddev
www.yahoo.co.jp 0% 11.704 16.691 23.845 3.0003ms
www.google.co.jp 0% 43.708 46.835 54.807 2.081ms
テストサーバー1 0% 139.024 187.894 239.065 30.026ms
テストサーバー2 0% 18.814 22.512 25.306 1.460ms
docomo(データ定額)
packet loss min avg max stddev
www.yahoo.co.jp 0% 108.174 118.389 154.171 8.798ms
www.google.co.jp 0% 128.898 141.954 155.505 6.944ms
テストサーバー1 0% 206.165 217.398 361.339 26.932ms
テストサーバー2 0% 106.566 132.891 613.313 89.298ms
Softbank(iPhone)
packet loss min avg max stddev
www.yahoo.co.jp 73% 88.733 179.106 370.456 92.697ms
www.google.co.jp 86% 116.306 120.867 126.555 4.248ms
テストサーバー1 76% 240.308 259.038 318.825 24.805ms
テストサーバー2 90% 121.751 131.433 146.446 10.763ms

テストケース2: AM2時台に実施

Softbank(iPhone)
packet loss min avg max stddev
www.yahoo.co.jp 3% 114.327 245.465 2133.128 403.058ms
www.google.co.jp 23% 107.446 178.063 896.914 161.420ms
テストサーバー1 0% 533.464 1064.434 1991.588 373.095ms
テストサーバー2 3% 401.674 967.69 1886.757 345.000ms

 

比較のためWi-Fi(回線はフレッツ光)も付記している。

まず第一に流れている話通り、PM9時台では確かにロス率は70%から最大90%にも達している。まさしく通常はあり得ないレベルだと言ってもいいだろう。
しかしもう一点注目すべきなのは、ラウンドトリップに関しては、実はドコモのそれと遜色ない、若しくは場合により上回っている場合もあるということだ。
次にAM2時台となるとロス率は格段に改善されている。ほぼ問題無いレベルと言ってもいいだろう。しかしその反面ラウンドトリップは極端に落ち込み、特にmax値は10倍以上遅延しているケースもあった。また平均偏差も非常に大きくなっている点にも注目したい。これはネットワーク状態が安定していないことを示している。
果たしてこれらは何を意味しているのか。

ここから憶測にすぎないが、テストケース1において、恐らくソフトバンクのバックボーンネットワークの性能自体はドコモと比較してもそれほどの遜色は元々無さそうだと言うことだ。しかしそれはパケットロス率を上げることでバックボーンへの負荷を低減しているからではないか。
これはテストケース2においてロス率が下がったと同時にラウンドトリップが極端に下がった(つまりネットワークが飽和しつつある)ことからも想像できる。
すなわち、パケットロス率はバックボーンへの負荷を減らすべく元から意図されたもので、時間帯により例えばスイッチングルーターのバッファ量を調整するなどして日夜調整されているのではないかという推測が成り立つ。

僕自身はネットワークの実務経験も乏しく専門性は持ち合わせていないのでこれ以上の論評は差し控えるが、これはこれで1つの「見切り」かも知れないという気はする。
ユーザーとしての感想を述べるなら、僕自身はパフォーマンスも少なくとも最近は1Mbpsを下回ることもなく安定して使えていると思っており、これまでもソフトバンク回線に(電波の入り以外に)大きな不満を感じたことはない。
スマートフォンに絞ればほとんどの通信はTCPベースであることは確かであり(UDPで困るのはDNSぐらいか)非常に多くのリトライパケットが発生するとしても全体としてはそれなりの「実測値」が得られると言うことなのかも知れない。

ネットワーク屋にとってはとても考えられない対応かも知れないし(僕自身もそうしたチューニングを決意する度胸はないが)、単にパケットロス率のみ取り上げて非難するのは簡単だ。しかし1つの方法論として今後「冷静に」大いに議論されても良い点ではないだろうかとも思う。
何故なら、これはもしかすると今後いずれのキャリアも通る道かも知れないからだ。

2011-06
15
11:42:45
auのEZWebがそろそろ終了しそうな件


先日auからEZWebに関わる以下のようなアナウンスがなされた。
KDDI au: EZfactory

EZブラウザは、2011年秋冬モデルにて、EZサーバを含め、「機能」及び「ネットワーク環境」の見直しを行ないます。
これによる主な変更点は以下のとおりです。

<主な変更点>
・EZサーバの言語変換機能が削除され、HDMLが非サポートとなる。
・EZブラウザ、PCサイトビューアーのIPアドレス帯域が統一される。

他にもCookie仕様の変更などがあるのだが注目すべきは、「EZブラウザとPCサイトビューアーのIPアドレス帯域が統一される」という点だ。

以前書いた記事も参照して欲しいのだが、

続:携帯で端末ID詐称は可能かもしれない話
(追記) 続:携帯で端末ID詐称は可能かもしれない話

EZWebつまり日本のケータイECを支えているケータイID(端末ID、サブスクライバーID)は単純に契約者または端末ごとに振られたIDをHTTPヘッダーに載せて通知して、WEBサイト(例えば公式サイトでの決済や課金など)ではこれを元に契約者を特定しているだけなので単にインターネット上で実現するとすぐに偽装や詐称されてしまう。
そこで再掲になるが、auに限らずドコモやソフトバンクでも以下のような脆弱な要件を満たさない限り、ケータイIDが偽装・詐称されずに正しく利用されていることはサイト側(サービスプロバイダー)では見分けが付かない

(1) そのアクセスがそのキャリアの携帯網(IPアドレス帯域)からのみであることをサービスプロバイダーが保証すること
(2) 携帯網ではケータイIDが偽装されていないことをキャリアが保証すること
(3) 端末の自由度を低くしてケータイIDの偽装などの可能性をできるだけ低く保つこと

但しauではEZ番号はゲートウェイで付加されるのではなく端末側から直接送信されているようなので、上記の三原則であれば1と3でしか担保されていない模様だ。

EZ番号を使用したケータイECに対応するのがEZブラウザであり(ドコモであればiモードブラウザ)、PCサイトビューアはEZ番号は発信しない単なるフルブラウザである。
しかし上記条件にあるようにEZブラウザ以外のブラウザやアプリからEZブラウザと同様のIPアドレス帯域に接続でき、かつEZ番号を偽装できるならこの日本独自のケータイECの仕組みは崩壊することになる。
であれば果たしてEZブラウザとPCサイトビューアのIPアドレスが統一された後、PCサイトビューアで偽装が可能になってしまわないのか。

この疑問に早速、徳丸浩氏が実験を行い結果を公表された。

EZwebの2011年秋冬モデル以降の変更内容とセキュリティ上の注意点

上記のように、現状のPCサイトビューアでは、EZ番号が追加できるほか、W52TではUser-Agentも変更できます。2011年秋冬モデルの仕様はわかりませんが、上記と同じ仕様である場合、EZ番号の偽装が可能になります。

 

2011年秋冬モデルでもEZブラウザにJavaScript機能が搭載される予定はないようですが、JavaScript機能があるPCサイトビューアのIPアドレスが統一されることで、結果として、事業者ゲートウェイを経由する端末の中に、JavaScript機能を搭載したものが含まれる状態が生まれます。このため、JavaScriptを悪用した攻撃の可能性が生じてきます。具体的には、JavaScriptによるEZ番号(サブスクライバID)の偽装、DNSリバインディング攻撃などの可能性が生じます。

IPアドレス帯域の統一は7月から、また2011年秋冬モデルからの変更と言うことなので、実際にどうなるかは7月以降の検証を待たなければならない。
しかしもしPCサイトビューアの仕様が大きく変わらないのであれば、EZWebでのあらゆる課金や決済は(たとえ暗証番号があるにせよ)偽装放題と言うことになる。
「でもそもそも他人のEZ番号なんて分からないのでは?」という疑問もあるだろう。しかしEZ番号は端末で「送信する設定」(デフォルト)にしてあれば勝手サイトにであっても常にEZ番号は送信されているのである。
つまり例えば決済や課金など関係ないケータイサイトを運用していても、実はEZ番号は大量にこれまでに入手可能であり、 ユーザー登録の必要なサイトであれば名前や住所などと紐付けられているかも知れないし、そもそも氏名など分からなくとも、ランダムにリスト化されたEZ番号を使って総当たりで詐称攻撃することも可能になるだろう。たとえ暗証番号があるにせよ、また3回間違えるとそのアカウントがロックされるにせよ、最低数百件程度のリストがあれば暗証番号を固定して次々に試せばそのうち幾つかは楽に認証を通ってしまうだろう(これはとてもよく知られた初歩的な攻撃手法に過ぎない)。
知らぬ間に公式サイトで勝手にデジタルコンテンツを大量に買っていたことになっていた・・ということも十分起き得るのである。

率直に言って、何故auがこんな仕様変更を簡単に行ってしまうのか、全く理解できない。そもそもauは、上記のような「脆弱な基盤」に支えられたケータイIDというものを理解していないのではないか。

以前僕はこのようにブログに書いたことがある。

三位一体の原則だ。これが1つでも崩れれば信頼性は崩壊する。
しかしもし上記の推測が正しければ、ことauのEZ番号については(1)と(3)によってのみしか支えられていない。SIMロック解除論議を持ち出すまでもなく、例えばauの携帯網のアクセスポイント情報が明らかになってしまったら。そこにスマートフォンなどで任意のアプリを実行できる端末が接続可能になったら・・・? 恐らくサービスプロバイダーは偽装を見破る術を持たない。
それが現実になれば、恐慌にも似たケータイECの信用崩壊が起こる可能性が非常に高い。

全ては2011年秋冬モデルの発売を待たなければ本当のところは分からないが、まさしくこの懸念が当たる際にいるのかも知れない。

2011-02
16
20:45:48
続々: 楽天銀行アプリのセキュリティについて – 結局UDID送信は中止しないし使用理由開示も行わない


前々回前回の続きをご報告したいと思う。
かなりあれから時間がかかったが、結論としてはシンプルで楽天銀行および楽天CERT・楽天グループとしてはUDIDの送信は停止しないし、また何故送信しているか、どのように利用・管理しているか は「当行不正取引防止システム運営の機密事項」のため一切開示しないとの結論であった。
以下、その詳細。

Continue reading