最新 追記

高木浩光@自宅の日記

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

2011年12月04日

ご愛読の皆様へお知らせ:Google Analytics使用開始の予告

急きょ、Google Analyticsがいかなるものか把握する必要が生じたため、この日記サイトにおいて、Google Analyticsの埋め込みを一定期間行います。

開始日は12月6日以後の予定で、1か月程度以内で中止する予定です。Google Analyticsのアクセス解析にさらされたくない方は、その間、この日記サイトへのアクセスを避けてください。

本日のリンク元 TrackBack(0)

2011年12月12日

Google Analyticsの使用を開始しています

前回予告した、Google Analyticsがいかなるものかを把握するためにこの日記サイトでGoogle Analytics一定期間使用する件、12月11日から埋め込みを開始しました。遅くとも2012年1月10日ごろまでに中止する予定で、その際には、発行したcookieの自動消去スクリプトを埋め込む予定です。

なお、Google Analyticsの設定で選択できる「Googleの他の製品との共有」及び「Google以外との共有」については、共有しない設定にしています。

Google Analyticsの機能である「イベント」のトラッキング機能の能力を試すため、イベントアクション名として「XX:XX:XX:XX:XX:XX」や「YY:YY:YY:YY:YY:YY」などを埋め込んでいます*1が、これらはどの閲覧者にも同一の固定の文字列として設定しており、閲覧者を識別するものではありません。

*1 HTMLソース参照。

本日のリンク元 TrackBack(0)

2011年12月18日

ミログ第三者委員会の「提言」を許してはならない

10月10日の日記「スパイウェア「app.tv」に係るミログ社の大嘘」の件、ミログ社から「第三者委員会報告書」(以下「報告書」という。)が開示された。

100ページにも及ぶこの報告書の内容は、「app.tv」と「AppLog」について事実関係を明らかにした上で、いずれも違法行為ではなかったとする結論を導くものであり、加えて、冒頭で、「ユーザーからの同意取得に関する提言」として、一般論を社会に向けて提案するものとなっている。

報告書には次の2つの重大な問題がある。

  • app.tvの不正指令電磁的記録該当性の検討で肝心の点がすっ飛ばされている。
  • 「ユーザーからの同意取得に関する提言」は到底受け入れられるものではない。

以下、これらを順に明らかにする。

app.tvの不正指令電磁的記録該当性の検討で肝心の点がすっ飛ばされている

報告書は、刑法168条の2の不正指令電磁的記録に当たるかの検討に際して、それが「意図に反する動作をさせる指令を与える電磁的記録か」と「不正な指令を与える電磁的記録か」の2点に分けて検討し、AppLogについてはどちらにも該当しないとしている。

一方、app.tvについては、(1)「意図に反する動作をさせる指令を与える電磁的記録」であることについて「疑いを拭いきれない」と認めた上で、(2)「不正な指令を与える電磁的記録」ではないとすることによって不正指令電磁的記録に該当しないとの結論を下している。

以下、この2点について見てみる。

まず、app.tvが「意図に反する動作をさせる指令を与える電磁的記録」であるかについて、報告書はp.75からp.76にかけて以下のように述べている。

(略)しかし、やはり、端末にインストールされている全てのアプリケーションの起動履歴情報を一定の間隔で収集することについて、この記載のみから予測することは困難であるといわざるを得ない。また、このような情報収集は、動画を視聴するというapp.tv本来の機能とも関係がなく、基本性能からこれを予測することもできない

そもそもapp.tvにおいては、「アプリケーションに関する情報、端末の情報、画面遷移に関する情報」、「個人情報と一体となった趣味・嗜好等」といった比較的抽象的な表現が見られるだけで、AppLogにおけるような、「アプリの起動履歴」との明確な記載はなく、上記の表現からapp.tvがアプリの起動履歴情報を収集していると予測するのは困難であるといわざるを得ない。また、当初はターゲティング広告に利用するための情報収集を行う機能は装備されていなかったことから、AppLogにおいて見られた「(略)」といったような、情報収集機能に関する基本的な動作・利用目的を説明する記載もないため、ユーザーにおいて、そのような機能を果たすために合理的に必要とされる範囲で情報を収集するのだろう、といった推測を可能とする程度の情報の開示もなされているとは言いがたい

むしろ、ユーザー登録画面における「利用規約、プライバシーポリシーをよくお読みになり、ユーザー情報をご登録ください。」との記述は、性別、生年月日というユーザー情報を取得するに当たってのポリシーが記載されているように読め、それとは無関係なアプリ情報の取得・送信に関する説明が記載されているとは思わないユーザーが多いのではないかと思われる点でミスリーディングである。同様に、利用規約における「AppReward等のリワード広告システムを利用する際に、ユーザーの端末にインストールされているアプリケーションに関する情報などの一部個人情報を利用することがあります。」との記載も、AppLogSDK収集情報は取得せず、リワード広告に利用するためにapp.tv収集情報のみを取得するという当初の状態を前提とした文言であって、AppLogSDK収集情報の利用目的の記載としてはやはりミスリーディングであるといわざるを得ない。

したがって、app.tvの行う端末情報の収集は、ミログにおいてそのように意図して行ったものとは認められないものの、結果的に、ユーザーの実際の意図していた、又は意図することが合理的に期待できた動作の範囲を超えていた疑いを拭いきれない

株式会社ミログ 第三者委員会報告書, 2011年12月16日

遠慮がちな表現が多用されているが、これは要するに「意図に反する動作をさせる指令を与える」ものであることを認めているのであり、ここでは第三者委員会の中立性が保たれている。

ここで、故意があったと言えるかについて検討しておくと、報告書は、このようなユーザ登録画面の構成が過失によるものだったとは主張していない。むしろこの画面があればOKという認識だったことが書かれている。今回の事件で問題とされているのは、このような、単にボタンさえ押させればあとは何をやっても許されるのかということであり、有効な同意なくボタンを押す利用者が続出することを認識、認容して行為に及んだかが焦点となるだろう。

さて話を戻すと、報告書は、このように「意図に反する動作をさせる指令を与える」ものであることは認めたものの、続く節で、「不正な指令を与える」ものではないとして、それを理由に不正指令電磁的記録に関する罪に当たらないと結論付けている。

「不正な指令を与える」ものではないとする理由は、「AppLogについて述べたところと同様」としており、それはp.62からp.66にかけて書かれている。

報告書はp.62で、法務省見解*1を参照し、以下のように述べている。

法務省見解では、プログラムによる指令が「不正な」ものに当たるか否かは、その機能を踏まえ、社会的に許容し得るものであるか否かという観点から判断するとしている。そこで、ユーザーの行動履歴に関する情報を、android_id等の情報とともに収集する行為が社会的に見て「許容し得る」ものであるかを検討する。

株式会社ミログ 第三者委員会報告書, 2011年12月16日

app.tvが違法か否かはここにかかってくる。

この検討は、次の2点から構成されている。

  • (i) 個人情報又はプライバシー権の侵害に当たらないこと
  • (ii) 従来のクッキー情報を利用したターゲティング広告との比較

まず、(ii)の点が看過できない。報告書は、要するに、app.tvがやっていたことは従来のcookieを用いたターゲティング広告と同じだという。そんなわけがない。

以下、この(ii)の点を詳しく見てみる。

報告書は、p.63からp.65にかけて、cookieを用いたターゲティング広告の仕組みを示した上で、次のように述べている。

以上に述べたとおり、クッキーを使用したターゲティング広告の手法は、一般的に広く行われている行為であり、これに対して消費者の苦情が多く寄せられていたり、訴訟が広く提起されていたり、監督官庁による規制が具体的に検討されているなどの事実は認められない。クッキーを使用したターゲティング広告の手法自体は、現時点において社会的に許容されていると考えられる。

既存のクッキーによるターゲティング広告の特徴としては、以下の点が挙げられる。

・既存のターゲティング広告では、クッキーによる情報の収集について、利用者の事前の同意(オプトインの手続)は法律や官公庁の公表しているガイドライン等において要求されておらず、実際に事前の同意を取得している例もほとんどない。(以下略)

株式会社ミログ 第三者委員会報告書, 2011年12月16日

つまり、cookieを用いたターゲティング広告は無断で情報を収集しているにも関わらず社会に許容されているとしている。

その上で、p.64からp.66にかけて「(C) クッキーによるターゲティング広告と、アンドロイド端末の行動履歴に基づくターゲティング広告の違い」を検討しているのだが、「違い」とされているのは以下の4点である。

  • クッキーにおいては、情報はユーザーの支配下に置かれており、ウェブサイトが情報を収集するのではなく、ウェブサイトを訪問する際にユーザーのPCがこれをウェブサイトに送るという仕組みになっている点
  • ブラウザの設定によりユーザーが自身でクッキーによる情報送信を拒絶できる点
  • ブラウザ単位までしか特定できないという点
  • クッキーの取り扱いにおいてはこれを一定期間経過後に廃棄するということも可能であるが、端末の識別番号は端末を変更しない限り不変であるとの点

報告書はこれら4点について検討して、「決定的に異ならしめるものとはいえない」「決定的な差異があるとは思われない」「本件との事情と大きな違いがあるわけではない」と締めくくっている。

それもそのはず、肝心の違いを挙げていないからだ。

肝心の違いがどこにあるかは、10月27日の@ITの記事で示されている。

  • スマホアプリとプライバシーの「越えてはいけない一線」, @IT, 2011年10月27日

    とはいえPCの世界でも、Cookieを用いてユーザーのWeb閲覧履歴を収集し、それを基に最適化した広告を配信する「行動ターゲティング広告」は広く行われている。ミログのケースもその一種ととらえることはできないのだろうか。なぜ、端末の情報を収集して送信することが問題になり、サービス中止にまで至ったのだろうか?

    産業技術総合研究所 情報セキュリティ研究センター 主任研究員の高木浩光氏によると、取得する情報の範囲が「自分の広告ネットワークの範囲かどうか」に、越えてはいけない一線があるのではないかという。

    PC向けのWebの世界では、まず、自社サイト内で完結する形でユーザーの行動を追跡することができる。もしそれがイヤならば、ユーザーはそのサイトを避けて通ることができる。

    第三者Cookieを利用した「アドネットワーク」が使われることも多い。広告配信会社は、自社のアドネットワークに参加している複数のサイトに広告を配信する。その際、多様なWeb媒体の中で広告配信を最適化するために、行動ターゲティングが使われてきた。

    しかし、「アドネットワークが情報を収集するのは、広告を張っているサイトに関するものだけで、それ以外の広告を張り巡らしていないサイト、無関係なサイトの履歴までは取っていない」(高木氏)。

    これは技術的な限界によるものだが、同時に、倫理的にもこの一線を越えてはならないという不文律のようなものがあった。Mozillaなど複数のWebブラウザに存在したバグを使って、「アドネットワークを使わずに、あらゆるサイトの履歴を取得する」とうたった「楽天ad4u」というサービスが登場した際には、当の広告業界からも「行動ターゲティング広告ではなく、行動スキミング広告である」として、反対の声が上がったこともある。

    だがミログのやったことは、まさに「自社の広告の貼ってあるサイト以外の履歴まで取ってしまうこと」に相当すると高木氏はいう。

これは別の言い方をすると以下のように説明できる。

cookieを用いたWebのターゲティングが広告が概ね*2許容されているのは、Webサイトは元々(その黎明期からの慣習として)アクセスログをとるものだからである。Webにアクセスするということは、そのサイトにアクセスログをとられるということであり、cookieに訪問者番号を与えられて、リピーター(再訪問者)か否かをそのサイトに識別されることも、元からWebとはそういうものであって、受け入れざるを得ないものである。

それが、第三者cookieを用いたアドネットワークとなると、少し違ってきて、広告を貼付けたサイトは、言わば、自サイトのアクセスログを自動的に広告会社のサーバに転送しているようなもの*3であり、アクセスログを(閲覧者に無断で)第三者に提供するのはいかがなものかという問題と、cookieによる識別が広告サーバ発行のcookieで行われることによりサイト横断的に閲覧者が識別されるという点が問題となるのだが、問題はその程度のものであって、「Webにアクセスするとアクセスログをとられる」ことに違いはない。

これがオプトアウト手段の提供程度で許容されているのは、広告サーバにアクセスログを「転送」するようなサイトは嫌だという人は、アドネットワークの広告が貼られたサイトを訪れなければよいという考え方があるからだろう。そして、そのように敬遠されては困るサイトは、アドネットワークの広告を貼らなければよい。実際、そうしているサイトもたくさんあるだろう。

他方、ブラウザのツールバーがアクセスログを転送している場合となると、話は違ってくる。同意なくそれをすればスパイウェアと看做される。なぜなら、Webサイト側の意向と関係なくログが転送されてしまうからだ。ミログがやったことはこれに相当する。

今日では、スマホのアプリに埋め込む広告も台頭しつつあるが、この場合も、普通は、広告の埋め込まれたアプリの起動状況が収集されるのみであって、それ以外のアプリの起動状況まで収集してしまうミログ方式は、普通ではない。

このことの具体的な問題性について、私は、10月31日に出演したMIAUのニコニコ生放送で、以下のように述べている。

  • スマートフォンとプライバシー 〜MIAU Presents ネットの羅針盤〜, ニコニコ生放送, 2011年10月31日

    (1:43:40 あたりから)

    高木: ログをとるエンジンを一旦インストールしてしまえば、他のインストールされているすべてのアプリの起動状況を調べてサーバに送信するというものだったんですね。

    スライド

    津田: ユーザさんが医療アプリを入れてたりとか、ゲームアプリを入れてたりみたいなものを、アプリの中に埋め込まれていることによって、それを通して別のサーバに送られるということですね。

    高木: えー、ちょっと注意してほしいのは、このアプリには埋め込まれてないんですよ。

    津田: あ、そうなんですか。

    高木: さっきの、この許されるパターン

    スライド

    というのは、広告が埋め込まれているアプリについては、記録されてしまうのはしょうがない。ユーザの選択なんだと。このアプリを使ったら使ったとバレてるぞと、認識しながら使うんだから嫌なら使うなってことなんですよ。

    津田: それが、

    高木: それが、こういうふうに

    スライド

    やられてしまうと、医療アプリはそんな履歴とかとられたら嫌な感じなので、医療アプリを作っている人はそんな広告を埋め込んだりしないと思うんですね。ところが、そうやって配慮してあえて広告を埋め込まずに提供していたにも関わらず、こう、ほかからバッと見られてしまってログをとられてしまうとなると、情報を履歴を持って行かれた個人の被害者っていうだけじゃなくてですね、こういった医療アプリを提供するような事業者にとっても被害があると。自分のアプリの信用が下がると。こういうのが当たり前になって常態化してしまうと、もうセンシティブな情報をスマホで扱うのをやめようって、皆思うようになる。

同様の説明は、11月4日のidcon#10での講演でも述べている。(4:30あたりから。)

先ほど挙げた@ITの記事でも、次のように書かれている。

  • スマホアプリとプライバシーの「越えてはいけない一線」, @IT, 2011年10月27日

    Androidに対する信頼を損なわないために

    (略)だがもし、端末から情報がなし崩し的に送信されるような事態になれば、社会的な損失が生じるのではないかとの懸念がある。

    「広告を出していない、無関係なところの履歴まで取られることが当たり前になってしまうと、『自分がどのような情報に関心を持っているか、ばれてしまうじゃないか』という懸念が高まり、PCやスマホ自体を使うことをためらったり、医療関係などセンシティブなアプリを使わなくなる可能性がある。ひいては電子計算機に対する社会の信頼を損ない、センシティブなサービスが成り立たなくなる恐れがある」(高木氏)。

    あるAndroidアプリ開発者も、「こういった事例が生じることで、『Androidアプリは怖い』という認識が広がることが怖い」と述べる。

    逆に、ミログが公開したアプリによって今回の議論が巻き起こったことは、コミュニティが健全に機能している証拠とも言える。今後、スマートフォン市場が広がる上でも、どういった情報ならば収集してもよく、どこからはだめなのかについての合意を、ユーザーと開発者の間で作っていくことが必要だろう。

それにもかかわらず、ミログ第三者委員会は、こうした観点に一切触れず、従来のクッキー情報を利用したターゲティング広告と同じであり「決定的に異ならしめるものとはいえない」「決定的な差異があるとは思われない」「本件との事情と大きな違いがあるわけではない」とし、app.tvについて以下のように結論付けてしまっている。

前述のとおり、法務省見解では、プログラムによる指令が「不正な」ものに当たるか否かは、その機能を踏まえ、社会的に許容し得るものであるか否かという観点から判断するとしているところ、ミログが収集した情報は、個人情報保護法における個人情報には該当せず、またミログによるかかる情報の収集行為がプライバシー権侵害を構成するものでもなく、このような民事的に違法とは判断できない情報の収集が、刑事事件では一転して違法と考えられるとの判断は均衡を著しく失するものであること、クッキーを利用したターゲティング広告が既に存在し、これについては現状、何らの法的規制もなく、社会一般的に広く行われている行為であり、これに対して消費者から苦情が多く寄せられているとか、訴訟が広く提起されている、あるいは監督官庁による規制が具体的に検討されているなどの事実も認められないから、現時点において社会的に有用なものとして認知され、許容されていると考えられること等を考慮すれば、本件におけるapp.tvによる情報収集行為が、刑法犯としての「不正」の要件を備えていると考えることはできない。

株式会社ミログ 第三者委員会報告書, 2011年12月16日

もう一度、別の言い方をしてみると、ミログのやったことは、単純に言って、一般のPCでいうところの、ローカルファイルのファイルシステムにアクセスして、「C:\Program Files\」ディレクトリのファイル名一覧を吸い上げたのに相当する。

そこには、プライバシーに係る情報があるだけでなく、企業秘密も存在し得る。

実際、AppLogのことが取沙汰されると、Twitterでは、「未公開の開発中アプリのパッケージ名(アプリ名)をとられてしまう」といった、企業秘密が漏洩する危険性を指摘する声が出ていた。

ミログ第三者委員会の報告書は、「不正な指令」かの判断に際して、「ユーザーの行動履歴に関する情報を、android_id等の情報とともに収集する行為が社会的に見て「許容し得る」ものであるかを検討」としており、「実現する目標が正当か」という観点で検討したようだが、いくら実現する目標が正当であっても、その手段が不正であっては許されない。*4

ローカルファイルシステムから無断で吸い上げることが御法度であるのは、一般のPCとインターネットにおける過去十数年の経験から、共通理解となっているはずである。

手段が不正である場合、個人識別性の有無とか、現にプライバシー権侵害が起きたかは、関係がない。電気通信事業法第4条の通信の秘密は、個人識別性がなくとも通話を盗聴したら即アウトであるし、不正アクセス禁止法でも、不正にログインした後何もしなかった場合でも違法である。

「第三者委員会」はなぜこの点について検討しなかったのか。

「ユーザーからの同意取得に関する提言」は到底受け入れられるものではない

これだけの話であれば、「第三者委員会」というのは名目だけで中立性はなく、結論ありきで書かれた弁護目的の文書なんだろうと、感想で終わる。

しかし、この報告書はそれだけではなかった。冒頭の「結論と提言」の章に、「ユーザーからの同意取得に関する提言」として、AppLogやapp.tvから離れた一般論として、同意取得のあり方を社会一般に向けて提言している。

ところが、その内容が著しく非常識なものとなっているのである。これは放置できない。

報告書はp.4からp.5にかけて以下のように書いている。

1 本件のように、アンドロイド端末を識別する情報とそれに紐づく行動履歴など、将来的に他の個人情報と結びついて当該端末利用者の個人情報に転化する可能性がある情報を取得する場合は、そのような転化が行われる具体的な計画がないとしても、少なくとも以下の情報を、情報取得開始前に、かつ同意を確認する画面と同一の画面内において、利用者に通知すべきである。

(1) 情報取得の事実
(2) 情報を取得する事業者の氏名又は名称
(3) 取得する情報の詳細及び取得の頻度
(4) 利用目的(第三者への提供の場合はその旨も含む)

株式会社ミログ 第三者委員会報告書, 2011年12月16日

この点はまあ良いだろう。*5

しかしそのすぐ下にとんでもないことが書かれている。

* 純粋に統計情報として利用するために、端末識別情報を収集せず、完全に匿名化がなされているなどの措置がとられ、プライバシー感情を害しないと考えられる情報収集を行う場合には、収集時に同意のない情報収集を認めてもよいと考えられる

株式会社ミログ 第三者委員会報告書, 2011年12月16日

そんなばかな。「統計情報として利用する」ためなら、電話も盗聴するし、カメラも盗撮するし、マイクから音も収集するし、あらゆるセンサーを無断で使うし、ファイルも盗むつもりだというのか。

この「第三者委員会」とやらは、本当に独立性があるのか? 誰がここを書いたのか? 第三者委員会は、ミログのやったことに対する調査が目的であるはずなのに、なぜか、ミログがやってもいないもっと酷いことを、正当化するよう社会に呼びかけるという謎の行動に出ている。

トンデモ提言はさらに続く。

2 上記の明示的な通知のある限り、オプトイン(通知時に利用者に同意するかを確認し、同意しない場合は情報収集を行わない)かオプトアウト(通知時に利用者に同意するかを確認しないが、その後手続きを行なえばそれ以後の情報収集を行わない)かは本質的な違いとならないので、いずれも許容される2

脚註2: (略)本第三者委員会は、情報の取得・送信が行われることが、ユーザーにおいて特別の探索や努力を要することなく、誰にでもわかる方法で明示的に示されていることを前提とし、かつ、それに対する情報送信の停止の方法が具体的に示されるといった場合でない限り、これを「オプトアウト」であるとは考えていない。

* オプトアウトだとしても、手続きが明示されていればすぐに情報の収集を停止できる。行動履歴情報の収集の際には、一定程度の期間の情報収集が必要であり、直ちに情報の収集の停止ができれば、オプトアウトであるから全く許されないという制限は必ずしも必要ないものである

株式会社ミログ 第三者委員会報告書, 2011年12月16日

はあ?

こんな理屈がまかり通るなら、室内を盗撮することも、室内の音をマイクで収集することも、電話を盗聴することも、最初の数回程度ならやってしまってOKということになってしまう。

この「第三者委員会」とやらは、情報収集の手段が問題(事前の有効な同意が必要)とされていることをまるでわかっていない。

ここで思い出すのが、朝日新聞11月12日朝刊の「記者有論」である。ミログのやり方を比喩して、次のように述べていた。

最近、ある広告にこんなコピーが踊った。「本棚を見れば人がわかるって言うけれど、これからはスマホのアプリでわかる時代なんだよ」

もし、買った本に仕込まれたカメラによって本棚が監視され、手に取った本に合った広告チラシが郵送されてきたら。「アップログ」とは、そんなプログラムだった。

(略)ミログ社を取材したが、批判の理由がわからないようだった。「他にも似た広告モデルはあるのに、なぜ、たたかれるのか」と。

「スマホのアプリ 情報のぞき見は許されぬ」, 朝日新聞2011年11月12日朝刊

これが、第三者委員会の「提言」に従うと、

  • 識別情報を収集せず統計情報として利用するなら、無断で本棚撮影してよい。
  • 識別情報を収集する場合でも、オプトアウトで十分であり、最初の数枚程度の本棚撮影は問題ない。

ということになる。

こんな出鱈目な「提言」が通ってしまったら大変なことになる。これは日本の常識を左右しかねない戦いとなるだろう。必要なことは、この第三者委員会に「NO!」を突き付けることだ。この第三者委員会は非常識である旨を声に出して言うことである。

法務省見解にあるように、「不正な指令」であるかは、「社会的に許容し得るものであるか否かという観点から判断」される。社会的に許容し得るかは世論が決めること。世論が司法に反映されるためには、黙っているのではなく皆が意思表示をしていく必要がある。

*1 法務省発表の文書「いわゆるコンピュータ・ウイルスに関する罪について」のこと。

*2 オプトアウト手段が用意されていればという程度で。

*3 実際には転送するのではなく、貼付けられた広告へのアクセスが広告サーバへのアクセスとなることによって、広告サーバに直接アクセスログをとられることとなる。

*4 日本法では特にそれが顕著なようで、グリーンピース宅配便窃盗事件等のように、不正の告発のためであっても違法な手段を用いることに対して寛容でない。

*5 「将来的に他の個人情報と結びついて当該端末利用者の個人情報に転化する可能性がある情報を取得する場合は」とあるように、これはANDROID_IDやIMEIを用いることの危険性に配慮した記述で、実際、報告書はその危険性について、p.50からp.51にかけて妥当な検討をしているのだが、それを言うのであるならば、「利用者に通知するべきである」とする項目には、単に「情報取得の事実」だけでなく、その情報が「将来的に他の個人情報と結びついて当該端末利用者の個人情報に転化する可能性がある情報」である旨を明記することを義務付けるべきだろう。

本日のリンク元 TrackBack(1)

2011年12月21日

Winny等規制法(改)「電磁的記録自動複製流通の適正化に関する法律(私案)」

長かった裁判が終わった。これでやっと誰でも遠慮なく*1、Winny等がどういう性質のものであるか、本当のことを語り合えるようになるはずだ。

一昨年の大阪高裁の無罪判決のとき、朝日新聞の記事で私は以下のようにコメントしていた。

◆有害性に踏み込まず
高木浩光・産業技術総合研究所主任研究員の話 判決が一審同様にウィニーを「価値中立的なソフト」と認定したことには疑問が残る。ウィニーは、従来のファイル交換ソフトと異なり、無差別のダウンロード機能によって必要のないファイルまでかき集め、どんなファイルをやりとりしているのかを利用者が意識できない構造だ。利用者に悪意がなくても、個人情報や児童ポルノのファイルを拡散させるなどの行為に加担させられてしまう。判決はウィニーが抱えるこうした有害性に踏み込んでおらず、利用者に誤ったメッセージを与える可能性がある。

朝日新聞2009年10月8日夕刊

そして今日の朝日新聞朝刊では、記事の最後で以下のようにコメントしている。

共有ソフトで拡散したデータは元に戻せない。産業技術総合研究所の高木浩光主任研究員は「今ではウィニー自体の利用は減る傾向にあるが、共有された児童ポルノ画像などは消せないまま流通し、類似した共有ソフトなども活発に使われている。判決を受けて問題点をしっかり分析し、規制を議論する段階ではないか」と指摘する。

朝日新聞2011年12月21日朝刊

「規制を議論する段階」というのがどんな規制を指しているのか*2は、2009年7月20日の日記「Winny等規制法の案を考えてみた」に書いたもののことである。

その後刑法に不正指令電磁的記録の罪もできたことであるし、少し直しを入れて改めて示しておく。


電磁的記録自動複製流通の適正化に関する法律(私案)

(目的)
第一条 この法律は、不特定多数の者が電気通信回線を通じて互いの電子計算機の間で電磁的記録を繰り返し自動的に複製し流通させることによって当該電磁的記録の消去等の管理を困難にする特定自動複製流通プログラムが、児童ポルノ及び不正指令電磁的記録等の犯罪に係る電磁的記録の流通の阻止を困難にさせることを防止するため、特定自動複製流通プログラムの利用者および開発者に対し一定の注意義務を課すことにより電磁的記録の自動複製流通の適正化を図り、もって高度情報通信社会の健全な発展に寄与することを目的とする。

(定義)
第二条 この法律において「特定自動複製流通プログラム」とは、電気通信回線に接続している電子計算機において作動するプログラムであって、他の電子計算機から電気通信回線を通じて電磁的記録を取得する機能を有し、当該電磁的記録を自動的に自動公衆送信(公衆によつて直接受信されることを目的として公衆からの求めに応じ自動的に送信を行うことをいい、放送又は有線放送に該当するものを除く。以下同じ。)し得るようにする機能を有するもののうち、次の各号のいずれにも該当しないものをいう。

一 取得する電磁的記録を当該電子計算機に蓄積しないもの。

二 取得する電磁的記録を当該電子計算機に蓄積するが、政令で定める期間を超えて蓄積しない措置が講じられているもの。

三 取得する電磁的記録を当該電子計算機に蓄積するが、公衆からの求めに応じて、当該電磁的記録を当該電磁的記録の取得元の電子計算機から再び取得することによって、電磁的記録を取得元の電子計算機の電磁的記録と同じ内容に更新する措置(取得元の電子計算機に当該電磁的記録が消滅している場合には、蓄積している当該電磁的記録を消去する措置を含む)が講じられているもの。

(利用者の責務)
第三条 特定自動複製流通プログラムの利用者は、当該プログラムを利用するに当たって、次の各号に該当する電磁的記録その他を自動公衆送信しないよう、管理しなければならない。(当該利用者が、その連絡先をインターネットの利用その他適切な方法により公表しており、求めに応じて当該電磁的記録を消去する等の措置を講じている場合、又は、当該特定自動複製流通プログラムが蓄積する電磁的記録の消去等の管理が当該利用者以外の管理者によってなされており、当該管理者がその連絡先をインターネットの利用その他適切な方法により公表しており、求めに応じて当該電磁的記録を消去する等の措置を講じている場合は、この限りでない。)

一 児童買春、児童ポルノに係る行為等の処罰及び児童の保護等に関する法律(平成十一年五月二十六日法律第五十二号)第二条第3項各号のいずれかにに掲げる児童の姿態を視覚により認識することができる方法により描写した情報を記録した電磁的記録

二 刑法(明治四十年四月二十四日法律第四十五号)第百六十八条の二第1項第一号に掲げる電磁的記録

(開発者の責務)
第四条 特定自動複製流通プログラムの開発者は、当該プログラムの利用者に、当該プログラムが特定自動複製流通プログラムに該当するものである旨を説明し、電磁的記録の取得に際して当該電磁的記録が自動的に自動公衆送信し得る状態になる旨を説明するよう努めなければならない。

2 特定自動複製流通プログラムの開発者は、人に利用させる目的で当該プログラムを開発するに当たっては、当該プログラムの利用者が電磁的記録を取得するに際して、前条各号の電磁的記録その他の記録を自動公衆送信しないよう管理することを可能とすべく、適切な措置を講ずるよう努めなければならない。

(罰則)
第五条 第三条の規定に違反し、過失により同条各号の電磁的記録その他の記録を自動公衆送信した者は、30万円以下の罰金に処する。


これがどういう趣旨でどういう範囲を対象としたものなのかは、2009年に書いた通り。

関連

*1 2006年12月12日の日記「Winnyの問題で作者を罪に問おうとしたことが社会に残した禍根」参照。

*2 もちろん、ダウンロード刑事罰化のことでは全然ない。

本日のリンク元 TrackBack(1)

2011年12月29日

spモードはなぜIPアドレスに頼らざるを得なかったか

spモードの事故

NTT docomoのスマホ向け独自サービス「spモード」が、今月20日に大規模な事故を起こして、重大事態となっている。

この事故は「spモードメール」で表面化したが(目に見える現象が起きたため苦情が相次いだ)、その他にも、目に見えにくい事故、つまりコンテンツ課金など、spモードの他のサービス(利用者識別に基づくもの)でも、利用者取り違えの事故が起きていた可能性があり、現在も調査中とされている。*1

この事故の原因を巡っては、spモードの詳細な仕組みが会見で公表されたことから、技術者達の間に物議を醸している。

  • [続報]spモード障害、なぜ処理能力オーバーで「メールアドレスの置き換え」が起きたのか, 日経IT Pro, 2011年12月22日

    (略)一部のサーバーが処理能力不足に陥ったことが、なぜ「自分のメールアドレスが他人のものに置き換わる」という通信の秘密にかかわる事故に発展したのか。大きな理由の1つは、メールアドレスが端末固有のIDでなく、端末に振り出されたIPアドレスとひも付いていた点にある。

    (略)NTTドコモのspモードシステムの場合、3G網に接続して電話番号とIPアドレスをひも付けた後は、パケットのヘッダーにあるIPアドレスを使い、パケットを送信したAndroid端末を識別していた。NTTドコモはこの件について「spモードシステムはIP網の中で動いており、パケットのIPアドレスとユーザーをひも付けるのは自然の発想だった」としている。当然、iモードメールのメールアドレスも、最終的にはIPアドレスとひも付けられている。

  • [拡大画像]ドコモ、“他人のメアドになる”不具合は解消――10万人に影響, ケータイ Watch, 2011年12月21日
    写真の引用

このシーケンス図と、会見内容を伝える報道から推測するに、次のようになっているようだ。

  • 「セッション管理」と書かれているサーバで、利用者IDとIPアドレスの対応表が管理されている。(シーケンス図の右の「C:α」の部分)
  • この「セッション管理」の対応表は、他の様々なサーバからの問い合わせに応じて、IPアドレスから利用者IDを検索して応答するようになっている。(推測)
  • IPアドレスの払い出しと解放が行われる際、同時に、「セッション管理」サーバにもそのイベントが通知されて、「セッション管理」サーバ上の当該IPアドレスに対応する利用者IDが更新されるようになっている。(シーケンス図より)
  • 今回の事故で、「ユーザ管理」サーバの負荷集中による機能不全により、「セッション管理」サーバの対応表のIPアドレスが更新されない状態が発生した。(シーケンス図より)

経験のある技術者なら、こういう作り方は危ういと直感するのではないか。「IPアドレスと利用者」というマッピングが、2か所(端末と「パケット交換機」を含む電話網側と、「セッション管理」サーバの2か所)で管理されていて、これらを同期しなくてはならなくなっており、片方で更新が滞ると何が起きるかわからないという点で不安になって、避けたくなるはずの設計ではないか。

しかも、IPアドレスは再利用されるIDであり、同じIPアドレスが(解放後に)別の利用者に割り当てられるものであるから、IPアドレスを利用者識別に用いたら、この同期の失敗は、利用者の取り違えという重大事故につながる。

これに対して、docomoが会見で、「パケットのIPアドレスとユーザーをひも付けるのは自然の発想」と言ってのけたということで、技術者は皆、仰天し、「利用者識別にIPアドレスを用いるなんぞアリエナイ」といった声が相次いだ。

なぜIPアドレスなのか

では、なぜdocomoは、IPアドレスによる利用者識別を実装してしまったのだろうか。

このことは、実際にdocomo端末を用意して、spモードを使ってみて、すぐにわかった。以下、外形的な事実から論理的に導かれる推測を示す。

最近のspモードでは「dmenu」なる、ガラケーのiモードのような機能が提供されている。以下の図1は、Webブラウザで「spモード各種設定」の画面を閲覧したときの様子である。

画面キャプチャ 画面キャプチャ
図1: spモードの「spモード各種設定」の画面

ここで注目すべきは、IDもパスワードも入力していないのに、既にログイン中の状態になっていることである。

URLにはユーザ名もセッションIDもなく、cookieをオフに設定してcookieを削除してこの画面を開いても、利用者である私はWebサイト側に識別されていて、そのまま私向けの設定を続行することができるようになっている。

一般のPCと普通のインターネットのWebでは、こういうことはあり得ない。電話網の仕掛けによって、利用者である私が識別されて、それがWebアプリ上で利用されていることを意味する。

ここで、図1の画面のURLが https:// である点に注意したい。SSLが使用されている。つまり、端末のアプリ(この場合はWebブラウザ)とWebサーバとが、end-to-endのSSL暗号化通信をしている。

となると、Webサーバはどうやって私を識別しているのか。end-to-endのSSL暗号化通信が用いられている限り、間のゲートウェイで「X-DCMGUID:」(iモードID)をHTTPリクエストヘッダに挿入するなどという、ガラケーでやってきた芸当は不可能である。*2

図1のhttps://のリクエストには何らパラメータが埋め込まれていないのだから、そうすると、Webサーバとしては、接続元のIPアドレスの他に頼りにする情報がない。

つまり、以下の図2のようなシーケンスになっていると推定できる。

画面キャプチャ
図2: spモードの推定シーケンス図*3

このように、HTTPSリクエストを受けたWebサーバは、(リクエストの中身が空なので)接続元のIPアドレスを「セッション管理」サーバに問い合わせて、ユーザID*4を得るしかない。*5

こういう作り方が危ういのは上に述べた通りであるが、では、12年もの長年の実績のあるiモードで、これまで同様の事故が起きなかったのはなぜか。

上で引用した日経IT Proの記事では、「当然、iモードメールのメールアドレスも、最終的にはIPアドレスとひも付けられている」などと書かれているが、これは間違いで、iモードではIPアドレスは使用していなかったと思われる。

iモードでは図3のようなシーケンスになっていただろう。

画面キャプチャ
図3: iモードの推定シーケンス図*6

iモードが始まった当初は、PDC方式上にインターネットアクセスを実現したため、今のスマホとは違って、端末とWebサーバが直接TCP/IPの通信をするのではなく、「パケット交換機」がTCP/IP接続を開始するようになっていた。そのため、この「パケット交換機」が、HTTPリクエストに電話番号などの利用者識別子をヘッダに載せることができた。

docomoの公開資料「技術的条件集別表8-2-1」によると、「パケット交換機」がHTTPリクエストを出すとき、拡張ヘッダとして電話番号(MSISDN)を載せるようになっていて、「プロキシサーバ」に渡すようになっているそうだ。資料には書かれていないが、おそらくは、この「プロキシサーバ」がいわゆるiモードの「ゲートウェイ」であり、そこで、電話番号からiモードID(やuid)への置き換えがなされているのだろう。

こうして、iモードでは、リクエストヘッダ中のiモードID(やuid)を参照することで、Webサーバが利用者を識別することができた。

このような方法を採用できたのは、iモードID(やuid)の送信が、その仕様として、https:// に非対応だったからである。(端末からWebサーバまでのend-to-endのSSL通信では、ヘッダに何かを挿入することはできない。)

以上のことから推察するに、spモードが図2のような設計になったのは、iモードと同じ使い勝手の実現と、https:// への対応を両立させることが、絶対的な実現目標とされたためではないだろうか。

「iモードと同じ使い勝手」というのは、要するに、「ID・パスワードが存在しない」ということである。

存在しないと言っても、「ネットワーク暗証番号」(4桁数字)は存在するわけだが、これは、端末を落としたときに物理的に他人に操作されないようにする役割*7であって、インターネットからの任意のアクセスに対して本人認証するという役割ではない(だから4桁数字という非常に弱い識別符号で許される)。

そして、docomoとしては、携帯電話の多くの利用者には、4桁数字の暗証番号は使えても、PCで使うようなパスワードを使いこなすことは無理(お年寄りなどには)と考えているのではないか*8。無理ではなくとも、利用が敬遠されて、利益がiモードのときのように出ないと考えているのではないか。そのことが、経営上の判断として、iモードと同じ使い勝手の実現に向かわせているのではないか。

あるいは、「水平分業」化をくい止めるために、ID・パスワードの使用という使い方を避け、「垂直統合」モデルの優位性を顕示するために、電話網との統合でなければ不可能なことを実現したかったのではないか。

そうだとするとこの問題は根深い。「諦めてID・パスワード方式にしようよ」と言ったところで、聞き入れる気はないと思われる。今どきHTTPSをやめてHTTPにするわけにもいかないだろう。

どうしても両立して実現したいなら、以下の図4のような方法がよいかもしれない。

画面キャプチャ
図4: パスワードなしかつHTTPSを実現する安定的な方法*9

つまり、HTTPSリクエストの中身にセッションIDを入れてWebサーバに渡すようにする。そして、そのセッションIDが、ID・パスワードなしで、電話網の認証機能から得られるようにする。(ただし、「専用アプリ」には注意点があり、そう簡単な話ではない。この件については下に書く。)

というわけで、このような背景があって、27日、NHKニュースが以下のように伝えた。

  • ドコモ システム不十分の指摘も, NHKニュース, 2011年12月27日

    NTTドコモのスマートフォン向けのサービス「spモード」で起きた今回のトラブルについて、コンピューターやネットワークの専門家からは、IPアドレスを用いて利用者を識別する「spモード」の仕組みが不十分だったのではないかという指摘も出ています。

    (略)高木浩光主任研究員は「従来の携帯電話で提供してきたi-modeと同じ利便性を維持するために、パスワードがなくても認証できるようにIPアドレスを利用したとみられる。しかし、再利用できないIDを用いるなど、アドレスの重複を防ぐシステムを整えなければ、今後も小規模なトラブルが起きる可能性がある」と指摘しています。

    こうした指摘に対し、NTTドコモでは「IPアドレスを利用した認証方式は広く利用されており、問題はないと考えているが、サーバーなど設備を増強するとともに、IPアドレスの取り違えが起きないようにシステムの改修を進めるなど、対策をしていきたい」と話しています。

docomoは「IPアドレスを利用した認証方式は広く利用されており、問題はないと考えている」と言うのだが、はたして本当だろうか。

たしかに、IPアドレスを払い出して管理するという、ISPとしての機能の部分では、利用者とIPアドレスが紐付けられて管理されているに違いない*10けども、そこをアプリレイヤが使って、IPアドレスから利用者IDを検索するということが「広く利用されている」というのには疑問なのだが、他のキャリアで、同様のことが実現されている例(ID・パスワードなしとHTTPSの両立)があるのだろうか。

この話は、シングルサインオンの実現方式の話として見ることもできる。「パケット交換機」でのログイン状態を「Webサーバ」に引き回すにはどういう実現方式があるかだ。一般に、シングルサインオンの実現方式は、2つあって、リバースプロキシ方式と、SAMLやOpenIDに代表されるアクセストークン引き回し方式だと言われる。図3のiモードの方法はリバースプロキシ方式に相当し、図4の方法はSAMLやOpenIDなどの方式に相当すると言えよう。それに対して、図2のspモードの方法は、どちらでもない、ユニークなものとなっている。はたしてこの方式は安定的なのだろうか。

spモードメールはどうなっているか

以上は、Webの場合について検討してきたが、今回事故が表面化した「spモードメール」の場合も、同様に、メールサーバが利用者を識別する際に、図2のようにIPアドレスをキーにしてユーザIDを問い合わせているのではないか。

本来、メールサーバは、POP3やSMTP AUTHのログイン名とパスワードで利用者を認証・識別するものだが、spモードメールでは、事情が違うようだ。このことは、docomoのテクニカル・ジャーナルに書かれていた。

  • 2010年スマートフォン新サービス・機能 ――スマートフォン向けサービス提供基盤――, NTT docomo テクニカル・ジャーナル, Vol.18, No.3
  • 2010年スマートフォン新サービス・機能 ――spモードのメールサービス――, NTT docomo テクニカル・ジャーナル, Vol.18, No.3

    (略)しかし、POP3S/SMTPSは、ユーザ認証時にメールアカウント(ユーザID/パスワード)を利用するプロトコルであるため、一般的なメールクライアントでは、ユーザ自身がメールアカウントの設定作業を行う必要がある。

    そこで、spモードメールでは、プロビジョニング機能を用意し、メールアカウントの設定作業を不要とした。すなわち、自動的にサーバ側で生成され払い出されたメールアカウントを用いて認証を行う方式とした。また、払い出すメールアカウントに有効期限をもたせ、サーバ側から強制的に変更を行うことでセキュリティを高めている。メールアカウント取得からメール送受信までのシーケンス図を図2に示す。

    引用した図

「プロビジョニング」で取得する「メールアカウント」というのは、iモードメールアドレスのfoo@docomo.ne.jpの「foo」の部分をログイン名とし、ランダムに生成された長い文字列をパスワードとしたものとなっているようだ。

こんなこと*11が可能なのは(パスワードなしに自動でアカウントを設定できるのは)、Webの「dmenu」と同様に、3G経由での接続中は「パケット交換機」で(認証済みの)利用者識別ができるからで、図2と同様に、それをアプリレイヤで活用しているのだろう。

メールサーバでもWebと同様に図2の方式で利用者識別をしているのだとすれば、spモードメールのプロトコルは、おそらく以下の図5のようなシーケンスになっているのではないか。

画面キャプチャ
図5: spモードメールの推定シーケンス図*12

今回の事故は、上半分が正常に作動せず、「プロビジョニング」の際に、「セッション管理」サーバの「IPアドレス,ユーザID」対応表が古いままになっていて、他人の「ユーザID」がメールサーバに渡され、その結果、その他人のメールアドレス(と乱数で生成されたパスワード)が、spモードメールアプリに返されたということではないかと推察する。

docomoが27日に発表した「発生した事象のイメージ」は、この推定に符合する。

引用した図
図6: docomo発表の「発生した事象のイメージ」より

「プロビジョニング」の際に「上半分が正常に作動せず」だったのは、図の「お客様(A)」である。その状態で(A)がメールを送信すると、古い「IPアドレス,ユーザID」対応表に従って、「お客様(C)」にすり替わって送信してしまい、結果、「お客様(B)」には、知らない人(C)からのメールのように見えた。(それに気付かず返信してしまった人が1,195人。)

また、同じ頃に、(C)宛にメールを送った「お客様(D)」のメールは、メール到着の通知は別の方法(SMS)で行われているため正常に(C)に届き、そのとき(C)が圏内でメール本体の受信を済ませていればそのまま(C)に届いたが、(C)が圏外だった場合には、先に(A)が、(C)にすり替わって(C)のメールボックスのメールを受信してしまう事態が起きた(1,335人分)ということだろう。

そもそもspモードは安全に成り立つのか

ところで、上で「「専用アプリ」には注意点があり」と書いた件は、どういうことか。

少なくともAndroidのスマートフォンにおいては、図4の仕組みが安全に成り立つには、以下の各要件を満たす必要がある。

  • 「専用アプリ」以外の他のアプリから「セッションID」を取得できてはならない。
  • テザリング中に、テザリングで接続している端末から「セッションID」を取得できてはならない。

つまり、悪意あるアプリや、悪意あるテザリング接続者に、なりすまされてしまうことのないようにする必要がある。

どうやったらそれを実現できるかは、現時点の私の知識ではわからない。たとえば、販売時から、プリインストールの「専用アプリ」に専用のクライアント証明書をインストールしておけば実現できるような気がする。しかし、その場合、配備するクライアント証明書とユーザの紐付けを販売時までにしておく必要があり、あまり現実的でないのかもしれない。

と、ここまで考えて気付いたのだが、ということは、現状の「dmenu」の仕組みだって、同様の問題を抱えているはずである。

dmenuの画面は、テザリングで接続している端末からどのように見えるのだろうか?

docomoの実際の端末で確かめてみたところ、テザリング中は、dmenuなどがアクセスできないようになっていた。以下の図7の画面が現れるようになっている。

画面キャプチャ 画面キャプチャ 画面キャプチャ
図7: テザリング中はspモードの認証が必要な機能を使えない様子

なるほど、ちゃんと対策されているようだ*13。しかし、これはこれで、にんともかんとも不便な話ではある。

では次に、悪意あるアプリから「dmenu」はどう見えるのだろうか。

「dmenu」は、Android標準搭載の「ブラウザ」でしか見られないわけではない。Firefoxでも、Operaでも「dmenu」を普通に使うことができた。このことから、試してみるまでもなく、悪意あるアプリからでも「dmenu」は見えてしまうと言える。*14

「dmenu」には「ネットワーク暗証番号」や「spモードパスワード」の入力を必要とする画面が多いが、すべての画面でそれらを要するわけではない。例えば、「dmenu」トップにある「マイメニュー」ボタンを押すと、図8のように「マイメニュー 一覧」の画面が現れ、ここには、個人に関する情報が表示されるのだが、それにもかかわらず、暗証番号やパスワードは不要である。

画面キャプチャ 画面キャプチャ 画面キャプチャ
図8: 「マイメニュー 一覧」の画面(中央は標準ブラウザによる表示、右はFirefoxによる表示)

このように、私が「毎日新聞」のコンテンツを購読している事実を、悪意あるアプリから収集することができてしまう。

これは「dmenu」の仕様だろう。修正されることはないと予想する。

「そもそも悪意あるアプリを入れるのが悪い」とdocomoは弁明するかもしれない。たしかに、一般のPCの世界ではそうであった。しかし、Androidでは、permissionモデルが採用されており、利用者は、マーケットでアプリをダウンロードする際に、要求されるpermission(「許可」)を確認して「同意してダウンロード」ボタンを押すことになっている。

「dmenu」をのぞき見するには、「ネットワーク通信(完全なインターネットアクセス)」のpermissionだけがあれば可能である。今や、かなり多くのアプリがこのpermissionを要求しているので、このpermission要求で怪しいと気付けることはまずないだろう。むしろ、要求パーミッションが「ネットワーク通信(完全なインターネットアクセス)」だけだったら、クリーンなアプリと感じる人も多いのではないか。

こんなことでよいのだろうか。

問題点はまだ他にもある。

spモードには、「spモードパスワード」という、「ネットワーク暗証番号」とは別の、4桁数字のパスワード(「パスワード」ではなく暗証番号と呼ぶべきだ)の仕組みがある。その初期設定が全員「0000」になっているのである。

画面キャプチャ 画面キャプチャ 画面キャプチャ
図9: 4桁数字暗証の「spモードパスワード」が初期設定「0000」になっている様子

図右のように、一応、docomoは「お客様独自のものに変更してください」と注意書きをしているが、図左のように、ご丁寧にも「初期パスワードは0000です」と案内しているコンテンツプロバイダまでいる始末だ。

docomoとしては、この暗証番号は、端末を落としたときの不正使用を防ぐため、あるいは、有料サービス登録の際の支払いの意思確認の役割のものと考えていて、そのため、こんなぞんざいな扱いにしているのかもしれない。

しかし、「0000」のまま使っている人が多いとすると、悪意あるアプリによって無断で有料サービスを登録されてしまう危険があるのではないか。

こんなことでよいのだろうか。

こんなことになっているのは、「ID・パスワードが存在しない」つまり、電話網による利用者識別をアプリレイヤで活用するという、spモードの特徴から来たものである。どうしたら対策できるか思いつかない。「ID・パスワードが存在しない」という特徴を捨てて、普通のインターネットのWebと同じやり方に仕様を変更するしかないのではないか。

そして最後にもう一点。

上で参照した、NTT docomo テクニカル・ジャーナルの記事に、こんなことが書かれている。

3.2サービスアプリ認証機能

メール送受信時のメールアカウントを自動で払い出すには、メールクライアントがドコモの正規のアプリケーション(以下、正規アプリ)であることを確認する必要がある。本開発では、spモードメールを含むドコモ独自サービスの利用をドコモの正規アプリのみに限定し、なりすましなどの不正利用を防止する仕組み(サービスアプリ認証)を導入した。

サービスアプリ認証では、ユーザ認証情報要求するアプリケーションが、正規アプリであるか否かをドコモ独自の認証方式により識別し、正規アプリであると識別できた場合のみユーザ認証情報を払い出す。(略)

2010年スマートフォン新サービス・機能 ――spモードのメールサービス――, NTT docomo テクニカル・ジャーナル, Vol.18, No.3

いったいどうやって実現しているのだろう? 最初に読んだときは「そんなことできるわけがない」と思ったが、上で検討したように、何か方法はあるのかもしれない。

ところが、既に、この「ドコモ独自のサービスアプリ認証」を解析し、spモードメール互換のアプリを開発した人がいる。

先日、その方からメールを頂き、「ドコモ独自のサービスアプリ認証」がどういう手順のものか、詳細情報を教わった。その方式はナンセンスなもので、単にアプリに埋め込まれた鍵で暗号化やハッシュをかけているだけのものであった。(解析した方には、詳細情報(具体的な手順)の公表を控え、IPAの脆弱性届出窓口に届け出ることをお勧めしておこうと思う。)

要するに、「ドコモ独自のサービスアプリ認証」なるものは、Winnyプロトコル並の難読化にすぎない。

正直、呆れた。この一点だけとってみても、docomoが、アーキテクチャ設計において、セキュリティレビューを受けていないことがわかる。

  • ドコモ「spモード」担当者に聞く spモードで目指す“スマートフォンとiモード”の融合, ケータイ Watch, 2010年9月2日

    ――特徴的な機能であるコンテンツ決済についてですが、使い勝手としてはiモードと同等になっているのでしょうか。

    久永氏
    簡単なspモード用パスワードを入力すると、コンテンツプロバイダへ決済情報が渡され認証される、という形です。(略)

    ――ユーザーがiモードからspモードへ移行、ということができれば開発側からすると楽なのかもしれませんが、なかなかそうもいきませんね。

    久永氏
    今までiモードに10年以上馴染んでいただいて、パソコンはわからないけれどiモードはがんがん使えるという方はいらっしゃると思います。ガラパゴスと揶揄されることもありますが、作り込んだからこそ使いやすく安心、といった面も(iモードには)あると思います。

spモードが目指すところはそもそも技術論的に無理があるのではないか。今一度、技術者の声に耳を傾け、根本から考え直す勇気を持ってはどうだろうか。

spモード利用者へ注意喚起:信用できない人にテザリング接続させない。「ネットワーク通信」だけの許可要求のアプリも信用できない。

上に書いたように、現在のspモードには、spモードメールを盗み読まれたり、「マイメニュー 一覧」を盗み読まれたり、無断で有料サービスに登録させられる等の危険がある。しかし、回避策があるので、以下、その回避策を周知する。

spモードメール盗み読み(及びなりすまし送信)の危険

docomoが技術文書で謳っている「ドコモ独自のサービスアプリ認証」は既に解析されて破られています。以下の方法で、他人があなたのspモードメールを盗み読みしたり、あなたになりすましてメール送信できてしまう危険があります。

方法(1) テザリング接続による方法
あなたがテザリング機能を有効にし、他人に接続を許している場合、接続した人が、「サービスアプリ認証」を破る技術を持っているならば、あなたになりすましてメールを送受信することができてしまいます。
回避策: テザリング接続では、信用できる人にだけ接続を許すようにしてください。
方法(2) 悪意あるアプリによる方法
悪意あるアプリをインストールしてはいけないのは今に始まったことではありませんが、もし、アプリが要求する「許可」(パーミッション)が「ネットワーク通信(完全なインターネットアクセス)」だけだったら、そのアプリをクリーンだと思って信用してしまいませんか? しかし、現在のspモードメールの仕組みでは、「サービスアプリ認証」を破る技術があれば、あなたになりすましてメールを送受信するアプリを、「ネットワーク通信(完全なインターネットアクセス)」のパーミッション要求だけで作ることができてしまいます。
回避策: 改めて、これまで以上に、怪しいアプリに警戒し、不用意にインストールしないようにしてください。

今後、短期的にdocomoが取り得る対策としては以下のものが考えられます。今後の動向に留意してください。

対策(A) spモードメールをテザリング接続時には使用不可とする対策
不便さが増しますが、上記方法(1)の危険は解消します。
対策(B) 「ドコモ独自のサービスアプリ認証」を新しいものに取り替える対策
解析済みの方法は使えなくなり、一旦は危険が解消します。しかし、新しいものに取り替えても、それが再び解析される可能性があります。docomoが技術文書で謳っている「ドコモ独自のサービスアプリ認証」は砂上の楼閣で、永久にイタチごっこになる虞れがあります。その場合は、上記(2)の危険は解消しません。

「マイメニュー 一覧」を盗み読まれる等の危険

spモードの「dmenu」には、暗証番号やパスワードの入力なしに、個人に関する情報を閲覧できる画面が存在します。例えば「マイメニュー 一覧」の画面です。そこには、あなたがどんなサービスに登録しているかが表示されます。この内容を、以下の方法で盗み読まれる危険があります。

方法(1) 悪意あるアプリによる方法
悪意あるアプリをインストールしてはいけないのは今に始まったことではありませんが、もし、アプリが要求する「許可」(パーミッション)が「ネットワーク通信(完全なインターネットアクセス)」だけだったら、そのアプリをクリーンだと思って信用してしまいませんか? しかし、現在のspモードの仕組みでは、誰でも簡単に、あなたの「マイメニュー 一覧」の画面を盗み読むアプリを「ネットワーク通信(完全なインターネットアクセス)」のパーミッション要求だけで作ることができてしまいます。
回避策: 改めて、これまで以上に、怪しいアプリに警戒し、不用意にインストールしないようにしてください。

今後、短期的にdocomoが取り得る対策はほぼないと考えられます。強いて挙げれば、「マイメニュー 一覧」など、個人に関する情報が表示される画面の全てについて、閲覧に際して「ネットワーク暗証番号」か「spモードパスワード」の入力を必要とするよう、仕様変更されるかもしれません。しかし、「怪しいアプリに警戒し、不用意にインストールしない」のが基本であるとして、そのような仕様変更はなされないかもしれません。

有料サービスに無断で登録される危険

spモードには「spモードパスワード」(4桁数字の暗証番号)の仕組みがありますが、初期設定では全員が「0000」に設定されています。そのため、以下の方法で、無断で有料サービスに登録されてしまう危険があります。

方法(1) 悪意あるアプリによる方法
悪意あるアプリをインストールしてはいけないのは今に始まったことではありませんが、もし、アプリが要求する「許可」(パーミッション)が「ネットワーク通信(完全なインターネットアクセス)」だけだったら、そのアプリをクリーンだと思って信用してしまいませんか? しかし、現在のspモードの仕組みでは、誰でも簡単に、「spモードパスワード」に「0000」を入力して無断で有料サービスに登録する悪質なアプリを「ネットワーク通信(完全なインターネットアクセス)」のパーミッション要求だけで作ることができてしまいます。
回避策: 「spモードパスワード」が初期設定のままの人は、他人に推測されない暗証番号に変更してください。

今後、短期的にdocomoが取り得る対策はありません。

以上。

*1 21日のCNETの記事によると、会見で「コンテンツの誤課金などの可能性は?」との質問に対しdocomoは、「それも論理的には可能性がある。一時停止した21項目のspモードサービスはIPアドレスを使っているので、電話番号とIPアドレスが紐付かないといろいろな事が起きると思う。そこについても通信記録を解析して、実際に何が起きたかを確認しているところ。」と答えていた。また、27日のケータイWatchの記事でも、「コンテンツの誤課金、コンテンツプロバイダへの対応について、今回の発表では触れられておらず、あらためて案内される見込み」とされている。

*2 MITMで動的に偽サーバ証明書を自動生成して、ルート証明書を端末に出荷時から入れておくという方法があるにはあるが、電気通信事業者がそのような手段をとるのは不適切であり、やってはいけない。

*3 WebSequenceDiagrams.comで作成

*4 docomoの会見で示されたシーケンス図では、「C:α」の「C」は「電話番号」とあるので、私の推定のように「ユーザID」を用いるのではなく、電話番号を直接Webサーバで用いているのかもしれない。

*5 一度この方法でユーザIDを得れば、後は、通常のWebアプリ同様に、セッションIDをcookieにセットして、この問い合わせを省略することもできる。dmenuの一部のページではそのようになっているように見える(確認はしていない)。

*6 WebSequenceDiagrams.comで作成

*7 あるいは、有料サービス登録の際の、支払いの意思確認の役割。

*8 この数か月、スマホの購入時にGoogleのIDとパスワードを紙に書くよう指示する販売店があるとのことで、問題視されつつある(この件は別の機会にまとめる予定)が、特に、docomoショップでの事例が多数報告されている。そのことからも、「利用者にパスワードなど使えない」との考えの一端がうかがえる。

*9 WebSequenceDiagrams.comで作成

*10 その部分では、利用者とIPアドレスのマッピングは1つであって、spモードのように2つのマッピングの同期に失敗することが原因の事故というのは、起き得ないのではないか。

*11 このプロトコルも一見して変だと感じる(メールアカウントの取得がパスワードなしに自動で可能なのなら、そのままメールもその方法で送受信すればいいじゃないの?と思える)が、まあ、アカウント取得部分の認証のコストが重くて、POP3/SMTP AUTHは軽いから、認証のcacheのようなことをやっているとみれば、まあ、合理的と言えるか。加えて、Wi-Fi接続時のメール送受信を実現するために必要だったとも言えるかもしれないが、そのわりにはWi-Fiでspモードメールを使うには別のパスワード設定が必要だったりして、意味不明なところがある。

*12 WebSequenceDiagrams.comで作成

*13 どうやって実現されているのかは確認していないが。

*14 実際に、https://service.smt.docomo.ne.jp/cgi/mymenu/top のURLにアクセスしてHTMLを取得するだけのAndoroidアプリを作成して動かしたところ、spモード接続中に使用すると、「マイメニュー一覧」のHTMLが取得できたという報告がある。

本日のリンク元 TrackBacks(5)

最新 追記

最近のタイトル

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|
最新 追記