2003年08月09日
■ ツーカーセルラー東海から回答書がきた
7月9日の日記「ツーカーセルラー東海に期待」に書いた、ツーカーセルラー東海*1に対するサブスクライバーIDに関する問い合わせに対し、回答書が送られてきた。その内容は以下の通り。（「2002年」となっているのは原文のまま。）
2002年8月1日高木様株式会社ツーカーセルラー東海
お客さまセンター拝啓 季夏の候、時下ますますご清祥の段、お慶び申し上げます。
平素はひとかたならぬ御愛顧を賜り、厚く御礼申し上げます。
先般は、サブスクライバーIDについてのお問い合わせをいただきまして、ありがとうございました。お問い合わせについて、関係部署と相談を致しました結果を以下のとおり回答させていただきます。
サブスクライバーIDは、モバイルインターネットをより快適にご利用いただけるよう、お客様の利便性を高めることを第一の目的として提供してきたものです。
それ自体は、単なる文字、数字及び記号の羅列であって、それによって個人を特定できる情報ではありませんので、コンテンツプロバイダー（以下「CP」）への提供自体に問題はないと考えております。
それを取得したCPが個人情報と結びつける等、CP側の管理方法によっては、相対的なものとして個人を特定できる情報になり得ることは認識しておりますが、この場合、当該CPがその収集した個人情報に対する管理責任を果たすべきだと考えております。
しかしながら、ご指摘のような悪意のCPが違法に当該情報を利用する事態も想定されることから、ユーザ保護の観点からは、その利便性とのバランスも勘案しつつ対策を検討していく必要があると感じております。
EZwebサーバーを実際に管理・運営しているKDDIにおいてもご指摘の事象については認識しており、その対策について検討を行っていると聞いております。状況ご斟酌頂き、何卒ご理解賜りますよう宜しくお願いいたします。
敬具まずは、「KDDIにおいてもご指摘の事象については認識しており、その対策について検討を行っていると聞いております。状況ご斟酌頂き、」とされている点を評価したい。「今すぐやめよ」と言っても無理であることは重々承知だ。重要なのは、こうしたシステム設計がダメであることを（少なくとも技術者と経営責任者の）皆が認識し、将来に同じような問題を生み出してしまうのを避けることである。
しかし、この回答書は、私の質問に答える形式になっていなかった。よくあることだが、個別の質問に答えるのを避けて、自らの主張をに述べるだけということがよくある。そうならないためには、質問を Yes / No 形式で示せばよい。今回も Yes / No 形式で質問したのだが、無視されてしまった。
お客さまセンターに再度電話し、1か月前の私の質問がどうなっていたかを確認したところ、以下のようにしっかりと箇条書きの文章としてセンターに記録されていた。
(1) サブスクライバーIDは個人情報であるか。
(2) コンテンツプロバイダーとの契約において、サブスクライバーIDは個人情報であるので、厳重に管理し外部に漏らさないとの契約はあるか。
(3) 非公式サイトに対してサブスクライバーIDを送信するのはプライバシーの問題があるのではないか。
(4) 非公式サイトへのサブスクライバーIDの送信を止める機能はあるか。EZweb@mail を一旦削除して登録しなおす方法以外に、サブスクライバーIDを変更する方法はあるか。
(1)と(3)については回答を得られたと言える。(1)については、
個人を特定できる情報ではありません
とあるので、「個人情報ではない」という回答だ。(3)についても、
コンテンツプロバイダー（以下「CP」）への提供自体に問題はないと考えております
とあるので、「問題ない」という回答だろう。ただし、（問題はないが）対策を検討しているということのようだ。
これに対し、(2)と(4)の回答は得られなかった。
(2)は、質問にミスがあった。「サブスクライバーIDは個人情報であるので」という前提付き質問なので、前提が否定されたため回答されなかったのかもしれない。改めて、コンテンツプロバイダとの契約について尋ねておいた。
公式コンテンツプロバイダと通信事業者の間の契約には、エンドユーザ（消費者）の個人情報に関わる何かしらの契約条項があるのではないかと考えられる。あるのであれば、通信事業者は、消費者に対して、コンテンツプロバイダとの契約内容を開示する義務があるのではないか。そのような契約がないのであれば、「ない」ことを開示してくれればよい。
(4)について回答してくれなかったのはちょっと理解できない。質問しているだけなのだから、「そのような機能はありません」と回答してくれればよい。ましてや、「プライバシーの問題」はないという回答なのだから、「そのような機能はありません」と答えるのをためらう理由はなかろう。
■ サブスクライバIDは法律でいう「個人情報」に該当するか
ツーカーセルラー東海の回答では、
それ自体は、単なる文字、数字及び記号の羅列であって、それによって個人を特定できる情報ではありません
となっているが、これを、行政機関の保有する電子計算機処理に係る個人情報の保護に関する法律 第二条と比べてみると、
当該情報に含まれる氏名、生年月日その他の記述又は個人別に付された番号、記号その他の符号により当該個人を識別できるもの
とあり、数字や記号が「個人情報」となるかが両者の間で違っている。後者では「個人別に付された番号」とあり、サブスクライバーIDが「個人別に付された番号」であることは自明であるが、前者では「個人別に付された」という事実があえて書かずにおかれている。
検索してたまたま見つけたのだが、自由民主党本部のプライバシーポリシーには次のように書かれている。
個人情報とは、以下の情報により特定の個人を識別できるものをいいます。
- 氏名、年齢、性別、住所、電話番号、職業、メールアドレス
- 個人別に付与されたID、パスワード、その他の記号など
- その情報のみでは特定の個人を識別できないものの、他の情報と容易に照合することができ、これにより特定の個人を識別できるもの
「個人別に付与されたID」が自由民主党本部では明確に個人情報として扱われている。誰が付与したものかを限定していないので、携帯電話から自民党本部Webサイトへのアクセスで送られてくるサブスクライバーIDも、自民党は個人情報として扱うことを約束していることになる。
昨日の日記に書いたように、民間をも対象とした個人情報保護法では、「個人別に付された番号」の記述はなくなっており、他の情報との照合についても、営業の自由への配慮から、「容易に」という要件が加わっているのであるから、ツーカーセルラー東海の回答が法律に反しているとは直ちには言えない。「容易に照合する」ことができるかどうかが焦点となる。
ツーカーセルラー東海の回答では、
それを取得したCPが個人情報と結びつける等、CP側の管理方法によっては、相対的なものとして個人を特定できる情報になり得ることは認識しておりますが、この場合、当該CPがその収集した個人情報に対する管理責任を果たすべきだと考えております。
とあるが、ここで言う「管理責任」とは何に対するどのような管理のことだろうか。
「サブスクライバーIDを個人情報と結びつける」というのは、コンテンツプロバイダが別の手段（そのサイトにおけるユーザ登録など）で個人情報を持っていて、それにサブスクライバーIDを結びつける行為を指しているだろう。そして、「当該CPがその収集した個人情報に対する管理責任を」というのは、コンテンツプロバイダが元々収集している個人情報の管理責任を負っているはずだということなのだろう。
つまり、個人情報と結び付けない状態のサブスクライバーIDは、コンテンツプロバイダにも管理責任がないということだ。なにしろ、通信事業者でさえ個人情報でないとする情報なのだからコンテンツプロバイダがそれを個人情報として扱わされるいわれはない。
すなわち、例えば、アクセスしたという事実そのものが私事性を持つようなサイトが、アクセス者のサブスクライバーID（およびアクセス先内容も含む場合がある）リストを売却していても、違法性がないことになる。
違法性がないことから、「誰だかわからない状態」のままサブスクライバーIDと、そのIDの人の無数のサイトにおけるアクセス行動が集積されることが起こり得る。誰でもそれを購入できたり、無料でダウンロードできる事態にさえなるかもしれない。
あとは、どこか一箇所でも、個人情報とサブスクライバーIDの対応リストを漏らすと、その集積情報が誰のものであるかが、誰にでもわかる事態となるのだが、管理責任があるのはその漏らしたサイトだけだということを、ツーカーセルラー東海の回答は語っている。そのときの、漏らした事業者の損害賠償額はどうやって見積もられるのだろうか。
また、誰も、個人情報とサブスクライバーIDの対応リストを漏らさなかったとしても、正規の理由で個人情報を預かっている者は、上の集積情報が誰のものなのかが容易にわかる。消費者がそのサイトを信用して個人情報を預ける際に、そこまでの集積情報が相手に渡ることをはたして予想しているだろうか。
さらに次の場合はどうだろうか。7月8日の日記「とうとうsubscriber IDの収集が始まったのか？」に書いた、無差別迷惑メール業者が、あてずっぽうのメールアドレスにspamメールを送って、メール中のID付きURLにアクセスしてきた消費者のサブスクライバーIDを収集するケースを考えてみる。
この場合、この業者は、メールアドレスを収集したわけではない。メールアドレスが個人情報保護法で言う個人情報に当たるか否かも議論の余地があるようだが、仮に収集したメールアドレスが個人情報だとしても、この迷惑業者は、消費者からメールアドレスを収集したわけではなく、ランダムに文字列を生成したにすぎない。ということになると、この業者が、メールアドレスのような文字列と対応するサブスクライバーIDのリストを売却することは、違法性がないことになるのではないか。
ツーカーセルラー東海の回答には、
しかしながら、ご指摘のような悪意のCPが違法に当該情報を利用する事態も想定されることから、ユーザ保護の観点からは、その利便性とのバランスも勘案しつつ対策を検討していく必要があると感じております。
とある。あくまでも違法に利用される事態が起きるなら対策を検討する（「俺たちの責任じゃないけどね」という意味）とされており、違法でない事態への対策については述べられていない。
これでよいのだろうか？
*1 つくば市在住なのになぜ「東海」なのかというと、東海地方に住んでいた7年前に契約した電話番号をまだ使っているため。
2003年08月14日
■ 「リスクコミュニケーション」はIT分野に馴染むか？
リスクコミュニケーションという考え方があるらしい。主に化学物質などが自然・生活・都市環境に与える影響について対象としているようだ。情報技術やプライバシーは対象となっていないようだ。
経済産業省製造産業局化学物質管理課のサイトにある「こんな思いこみはしていませんか？」はなかなか興味深い。
- 環境対策が決まるまで情報は公開すべきでない。
- 情報を出すと世間が混乱する。リスクについて情報公開すれば、住民はパニックになる。
- 住民は、科学的な情報は理解できない。住民はゼロリスクを求める。
- コミュニケーションにわざわざ人や時間を割く必要はない。
- マニュアルを作ったから、問題が起こっても対応できる。
リスクコミュニケーションがどのようなものかを知るには、たとえば、三井情報開発総合研究所の田島哲也氏の時事コラム「リスクコミュニケーションについて」がわかりやすいかもしれない。
リスクコミュニケーションとは、企業活動等に際して安全・衛生・環境等面で大きなリスクが発生する可能性のある活動を行なう場合、リスクを負う可能性のある関係者（職員、地域住民等）に対してそのリスクの性質・内容等について周知させ関係者の注意を喚起し、関係者からの不安・警戒・疑問等に答えるととも、関係者からの指摘を自己のリスク管理に取り入れることによりリスクの削減を図ることである。（略）
検索してその他のページも見てまわったところ、どうやら、リスクコミュニケーションというのは、基本的には、専門家が分析して結論を出したリスク評価を、行政や企業が一般市民に対して「説得する」ためのコミュニケーション手法のことを指すらしい。コミュニケーションによってリスク分析が進むという話ではない。
ただし、上の田島氏の概説にもあるように、「関係者からの指摘を……取り入れることによりリスクの軽減を図る」ということも、リスクコミュニケーションの意義として謳われているようだ。実際に一般市民の声が専門家の分析を覆すことは、めったには起きないだろうが、その可能性があることを前提としたコミュニケーションを図ることによって、単に不安・警戒を抑えるということだけでなしに、リスク評価を行う者に緊張感を与え、他の意図にそそのかされて評価を誤るという事態を防止できる効能があるのだろう。
さて、IT分野でのリスクコミュニケーションの現状はどうなっているだろうか。化学物質がもたらす環境リスクと、情報技術がもたらすプライバシーリスクとには、どのような違いがあるだろうか。いろいろと論点がありそうだ。列挙し始めると長くなりそうなので今日はやめておく。
ひとつだけ挙げておくと、そもそもIT分野でのリスク分析は、専門家の間でもあまり進められていないのではないかということがある。暗号の強度については専門家による評価が行われてきたが、暗号以外の部分の欠陥がもたらすリスクとか、その他の技術のプライバシーへの影響といったことは、化学物質の環境リスク研究などと比べると、研究分野、研究体制として確立していないように思えるが、どうか。
専門家の評価体制ができていないものを、リスクコミュニケーションだと言って「説得」しようとするのはおかしい話だ。リスクコミュニケーションの定義に反する。
■ 倹約家新婚ご夫婦の誕生日プレゼント
「消費者に理解されていない「ICタグ」」より。
いきなりだが，結婚したばかりの友人から送られてきた電子メールを紹介したい。このメールが届いたのは，7月下旬のこと。ちょうど記者が，日経コンピュータの8月11日号で「ICタグの真実」と題した特集記事を執筆している最中だった。
ごぶさたです。最近よく記事で目にするゴマ粒チップについて聞きたいのですが，このチップを埋め込んだシールを作って自分の大切なモノに張っておくと，GPSなどの位置情報システムと連動して所在地が分かるの？ 実は，1週間前に奥さんからもらった誕生日プレゼントの定期入れを，定期や免許証と一緒に落としてしまいました。それで，ゴマ粒チップを使って発見できたら便利だなと思った次第です。
結婚一年目の誕生日プレゼントが定期入れとは、なかなか堅実なご夫婦だ。それを紛失とは、さぞかし痛恨の極みのこととお察しする。
2003年08月15日
■ 村井先生の講義
7月30日の日記で、固定ID型RFIDのプライバシー問題について村井先生の講義で取り上げられていたことを書いたが、別の講義「インターネットの進化と可能性」でも論点のひとつとなっていた。
2003年08月16日
■ 理解せずに語られているcookieのプライバシー性
総務省のサイトに「電気通信サービスFAQ」というページがある。「５−１ 携帯電話は誰かに盗聴されたりする心配はないのですか。」などは、総務省の公式な見解として読むと興味深い。
このFAQ、よく書けているところと、そうでもないところがあって、それぞれ担当した人が別なのかなあとも感じられるのだが、それはともかく、第5章「通信の秘密、個人情報保護 」に、「クッキーとは何ですか。クッキーを受け取らないようにすることは可能ですか」というQがある。
小さなデータ
回答の冒頭にはこう説明されている。
クッキーとは、ホームページを置いているサーバコンピュータが送信した情報をインターネットの利用者のパソコンに保存させ、その利用者が次に同じホームページにアクセスした時に自動的に保存された情報をサーバに送信するシステムのことをいいます。
この説明は正しい。続く部分、
このシステムの機能は、利用者の情報に固有の番号を振り、利用者が入力した情報の一部をサーバに覚えさせておくことで、その利用者が次回にそのホームページにアクセスした時にその情報を利用して、入力すべき情報を省かせたりします。
ここもおおむね正しい。
正しいのが当然なのになぜこれを取り上げるかというと、あまりにもいいかげんなcookie解説が巷にあふれているため、この正しい説明が珍しく見えてしまうのだ。いいかげんな解説はプライバシーポリシーや個人情報保護方針の文中に見られる。例えば、「クッキー 小さなデータ」で検索してみると、わらわらと変な解説が出てくる。典型的な文章はこんな感じだ。
クッキーは、ウェブサーバーからブラウザに送信される小さなデータです。
データが小さいかどうかは、プライバシーに何ら関係がない。総務省のFAQにあるように、サーバが発行し、ブラウザが受信して保存し、後に同じサイトにアクセスするときに自動的に送り返されるところに、cookieの本質がある。プライバシーポリシーを書く立場の職種の人たちは、cookieがどういうものかわからないままに書いている（書かされている）ことがあるのだろう。
「技術的に不可能ではない」？
そういうわけで、「電気通信サービスFAQ」のこのcookie解説は、きちんと技術的な仕組みを理解した方によって書かれたものと思われる。ところが、続く部分がちょっと変なのだ。
利用者がこの機能を正しく認識して使用すれば便利なものですが、ホームページの中には、利用者のパスワードなど必要以上の情報を保存させる場合があり、他人が利用者のパスワードを読むことも技術的に不可能ではありません。
「技術的に不可能ではありません」と言うと、まるで、どうやっても防げない話のように聞こえる。実際には、セキュリティホールがない限り、他人にcookieを読まれることは起こりえない。cookieを盗まれるセキュリティホールは、ブラウザにある場合もあれば、サーバ側のWebアプリケーションにある場合もある。cookieは、中身がパスワードだろうが、単なるセッションIDであろうが、他人に読まれることはあってはならないものであり、それが起きるのは何らかの欠陥があるということだ。
とはいえ、実際問題として、ブラウザやサーバ側にセキュリティホールが残っていることも避けられない現実であるとして、ユーザ向けにそのリスクを説明することの意義はあるのであるから、そのような意図で書かれた解説なのかもしれない。ただ、仕様上の話と、欠陥がある場合の話は区別して説明するべきだ。なぜなら、欠陥があるならまず欠陥を直すことが第一だからだ。
で、この日記で言いたいのはその話ではない。なぜ、欠陥の存在を前提とした話を、「技術的に不可能ではない」という不用意な表現で書いてしまったのだろうか、ということだ。 これを私は次のように憶測する。
よくわからないが問題があるらしい
そもそも、cookieの話を「通信の秘密、個人情報保護」というFAQに書くからには、プライバシー上の問題点について書かないわけにはいかない。ブラウザにcookieの受入れを拒否する設定機能が存在するという事実から、cookieがプライバシーに何らかの影響があるらしいことは確かだ。そこで捻出されたのが、「他人が利用者のパスワードを読むことも技術的に不可能ではありません」という想定ではなかろうか。
つまり、このFAQの著者は、cookieの動作原理は理解しているものの、cookieがなぜプライバシー上の問題のあるものとされているのか、その本当の理由を理解していないのではないかということだ。
cookieの本当のプライバシー問題（のうち最も重大なもの）は、「第三者cookie」によるユーザ追跡効果にある。
第三者cookieとは、ユーザが今見ている画面のURLとは異なるドメインのサーバから発行されてくるcookieのことを指す。具体的には、たとえば、ページ中に貼り付けられた画像だ。HTMLの仕様上、画面を構成するHTMLの置かれているサーバとは別のサーバに置かれている画像ファイルを、ページ中に貼り付けることができる。このとき、画像を供給するサーバ（第三者のサーバ）がcookieを発行していると、ブラウザはそれを自動的に受け付けてしまう。これを「第三者cookie」と呼ぶ。
予測できなかった第三者cookieの乱用
第三者cookieの応用として最も多いのが、「バナー広告」だ。バナー広告の画像（Flashコンテンツでもよい）は、通常、広告業者のサーバに置かれていて、広告を掲示するページでは、その画像へのリンクが張られている。
広告業者がバナー広告の画像にcookieを発行する理由は、第一には、閲覧者に効果的な広告の見せ方をすることにある。たとえば、同じ閲覧者に同じ広告を何度も何度も見せても効果が薄いかもしれないし、閲覧者が既にクリックしたことのある広告を再び同じ閲覧者に見せても無駄に終わるかもしれないのだから、できるだけ新しい広告を見せるようにした方がよい。そうした仕組みは、cookieを使うことで簡単に実現できる。閲覧者ごとに固有の固定IDを、cookieとして発行すればよい。あるIDの人からアクセスがあったとき、そのIDの人に過去にどんな広告を見せたかを調べて、適切な広告画像を返すようにすればよい。
広告業者は、一社で、非常に多くのサイトに広告を流している。広告業者は、各閲覧者が過去にどこのサイトを訪れているかを、広告画像の Referer: フィールドの記録から知ることができる。これを活用すれば、各閲覧者のアクセス嗜好に応じた広告を選んで流すこともできる。普段ポルノサイトに行くことの多い人は、食品販売のサイトに行ったときにも、ポルノ系広告が現れるということが起こり得る。
もし10万か所のサイトに、同一広告業者のバナー画像が貼り付けられていたならば、その広告業者は、それぞれの人たちがその10万か所にどのようにアクセスしているのかを知ることができてしまう。IDだけでは、それが誰のIDであるかは不明だが、その10万か所のうちのどこかで、ユーザが個人情報を登録していて、それと広告のIDとが突き合わされる事態が起きれば、それが誰であるかも判明してしまう。
これが「第三者cookie」のプライバシー問題である。これが一部の特殊な人たちにだけ懸念されている問題というわけではないことは、最近のブラウザのcookie設定の画面を見れば明らかである。以下のように、NetscapeにもInternet Explorerにも、第三者cookieは、通常のcookieとは別に許可・拒否の設定ができるようになっている。IEでは、第三者cookieは「サードパーティのCookie」と表記されている。
cookieの機能を最初にブラウザに取り入れたのはNetscapeだった。彼らは、cookieなどという複雑な仕組みを編み出さなくても、ブラウザに固定IDを埋め込むだけで目的を果たせたはずだが、それをしなかった。それは、固定IDがプライバシー上の問題があるという見識を持っていたからだろう。だが、そんな彼らにも予測できなかった使われ方をしてしまった。それが、第三者cookieのサイト横断的利用だった。当初予想できなかった問題が起きれば、ブラウザ側で新たな対策をとる。それが上の新しい設定画面だ。
蚊帳の外だった日本が初めて患う大人の麻疹
FAQの文章に戻ると、
このシステムの機能は、利用者の情報に固有の番号を振り、利用者が入力した情報の一部をサーバに覚えさせておくことで、その利用者が次回にそのホームページにアクセスした時にその情報を利用して、入力すべき情報を省かせたりします。
というように、cookieが固有番号を記憶するために使われていることは理解されているようだが、それ自体はプライバシー上の懸念をもたらすものではないとして説明されている。あくまでも、
ホームページの中には、利用者のパスワードなど必要以上の情報を保存させる場合があり、 総務省 電気通信サービスFAQ
というように、サイト側がcookieの使い方を誤って、パスワード（やユーザ名）をcookieに直接入れてしまっている場合にだけ問題が起きるとして書かれている。
こうした誤った理解は、総務省の担当者だけでなく、かなり広範囲の人たち（技術者を含む）に根強く残っているのではなかろうか。
このFAQの文章が総務省の総意を示すわけではないことは重々承知しているのだが、携帯電話事業の監督官庁である総務省の関係スタッフが、もし固定IDの問題を理解していないとすると、それはまずい。
EZwebの「サブスクライバーID」や、J-PHONEの「ユーザーID」は、その仕組みからして、第三者cookieと同じプライバシー問題を起こす能力を持ち、それどころか、cookieのようにID発行の準備をせずとも最初から電話会社から勝手にIDが送られてくるという点で、より性質の悪い仕組みになっている。
「電気通信サービスFAQ」でcookieが取り上げられているのは、「cookieにプライバシー問題あり」というのが、国際的コンセンサスとなっているからだろう。それに対し、携帯電話の簡易Web機能は、日本市場で先行して普及してきたため、まだ諸外国ではそのプライバシー問題がほとんど認識されていない。今後、欧米諸国に普及していったときに、消費者団体からのバッシングに遭い、政府の介入という事態にもなると予想される。
私が固定IDのプライバシー問題をここで書いているのは、私個人がプライバシーに敏感だからとかそういうことではない。セキュリティ問題を追いかけてきた経験から、国際的に何がプライバシー問題（どんな技術手法が禁じ手）として認識されているのかを、たまたま詳しく知る立場にあった。それがどうやら、肝心な人たちには理解されていないらしいことが、昨年あたりからわかってきたため、このままではまずいと思い、筆をとっているところだ。
日本は、これまで、こうした技術の標準化において蚊帳の外にいることが多かった。主なWebブラウザは日本製ではないし*1、IntelのPentium IIIにIDを内蔵させて活用する件でも日本は蚊帳の外だった。固定IDにプライバシー問題があるという議論は、海外ニュースの翻訳版で対岸の火事として傍観する程度のかかわりしか持ってこなかった。「Webバグ」の議論だって日本のメディアが独自に取り上げることはなかった。日本にとってRFIDの今の議論は、大人になって今ごろかかった麻疹のようなものだ。
「e-Japan重点計画-2003」では、「安全・安心」がキーワードとなっており、各技術でプライバシーを確保することが謳われている。国際的に恥をかくはめにならないよう、なんとか固定IDの問題を正しく認識した上での政策を進めていただきたい。そのためにはあらゆる協力を惜しまないつもりでいるのだが……。
と、こんなところで言っていてもはじまらないのだが。
■ 補足
「e-Japan重点計画-2003」のp.45に次の記述がある。
(2) インターネット端末やインターネット家電が普及し、それらがインターネットに常時接続されることを想定し、十分なアドレス空間を備え、プライバシーとセキュリティの保護がしやすいＩＰv6を備えたインターネット網への移行を推進する。
IPv6が「プライバシーの保護がしやすい」ものだというのは、初めて目にした。どういう根拠なのだろうか。ちゃんとわかっている人が書いているのかどうか、不安になる。
「電気通信サービスFAQ」の別のページにはこんな記述もある。
４−４−４ 自分のパソコンがコンピュータ・ウィルスに感染しないようにするには、どうすればよいのでしょうか。
○ パソコンがコンピュータ・ウィルスに感染すると、パソコンに保存してあるファイルが破壊されてしまうことがあります。このようなコンピュータ・ウィルスに対処するためには、市販のウィルス対策ソフトを活用し、ウィルスの侵入を防ぐことが大切です。
○ ウィルスは電子メールに添付されて侵入する場合が多く、添付ファイルを開くとパソコンがウィルスに感染してしまいます。そして、コンピュータの中のメールアドレスなどを参照して、勝手にウィルス付きの電子メールを送信し、知り合いにもウィルスの被害を広げてしまうことがあります。
○ 最近のウィルスは手口が高度化してきており、メールの添付ファイルを開かなくても、メールを読むだけで、あるいはＷｅｂを見るだけで感染してしまうようなケースがあります。 ○ このため、ウィルス対策ソフトを定期的に起動させて、ウィルスチェックを行うことをお勧めします。また、身に覚えのない相手や怪しい件名のメールが届いたときには、安易に添付ファイルを開かずに削除したほうがよいでしょう。
○ また、新しいウィルスが日々発見されている状況なので、ウィルス対策ソフトや、その定義ファイルの更新を常に行うようにすることが重要です。
○ プロバイダによっては、自動でメールのウィルス検査を行うサービスを提供しているので、こういうサービスを利用する方法もあります。
セキュリティホールの話や、パッチをあてよという話が全く書かれていない。これはちょっと愕然とする。
きっとこの文書は3年前くらいに書かれたものなのだろう。そのころは、こんな報道もあったくらいで、世間の認識はそういうレベルだった。
中央省庁などのホームページの不正書き換え事件で、１５件のうち６件は、ハッカーがサーバーコンピューターに一度に大量のデータを送信して異常作動を起こさせる方法で侵入していたことが、１５日までの警視庁麹町署捜査本部の調べで分かった。この方法は「バッファ・オーバー・フロー攻撃」と呼ばれる手口。大量のデータを受けたサーバーコンピューターからあふれ出たパスワードなどのデータを使ってハッカーが不正アクセス用の「裏口」を作り、管理者になりすましてホームページを書き換える。防ぐのは難しいという。
たった3年半前の話なのに、隔世の感がある。
■ まだこんなことを言っている人がいるよ その2
- 菊田一郎, RFIDの実用化と セキュリティ問題, 月刊「マテリアルフロー」, 2003年8月
タグには危ない情報を入れないこと
...いろいろなサイトの書き手が、すぐにあの小説「１９８４年」に出てくる、プライバシー情報を含む一切の支配者・ビッグブラザーを持ち出したりしています。
ＲＦＩＤタグに、商品名や製造日や原料や値段（上代・下代）やサイズ・色、といった全ての情報をそのまま書き込むのだろう、そんなこと他人に知られてはたまらない、と言う理解がまず頭にあるから、そうした反応になるのでしょうか。
...タグに入っているのは製品のシリアルナンバーだけです。数字の羅列。それだけでは意味がなく、製品情報・生産情報・流通情報はそれぞれの責任を担う企業のサーバに置き、ネットワーク経由で権利のあるものだけがアクセスできる方式を目指しています。
...てなわけで、...
導入関連社側が根気よく、一般消費者に向けて説明していくことでしょう。
コメントは不要だろう。この人を理解させるにはどういう手段があるのか。
*1 例外はあるが。
2003年08月17日
■ 「固有ID」の問題なのか「固定ID」の問題なのか
8月16日の「辺境から戯れ言」に次の主張がある。
「固有 ID」という言い回しは誤解を生みやすく取り扱いが難しいように思う。
私も、「固有ID」という呼び方を避けている。この日記では初日の5月5日の日記でだけ「固有ID」と書いてしまったが、これはミスで、その後は「固定ID」と書くようにしている。4月のネット時評でも、「固定ID」と書いていて、「固有ID」とは書いていない。「固有のID」という表現は出てきているが、問題ありという文脈では使っていない。
両者はどう違うのか。
まずひとつは、IDを（時間的に）固定にしないことによる解決策があるという含みを持たせるためだ。
具体的なことはこれまでの日記にたびたび書いてきた。下の1つ目のように一時的なIDを使う方法と、2つ目のようにIDにスクランブルをかける方法がある。
- IPv6の匿名アドレスはどう運用されるのか, 5月25日
アプリケーションレベルの識別子は、一時的なID（セッションID）とすることができる。Webアプリケーションでは一般的な方法だ。最初に何らかの方法でユーザ認証を行った後は、一時的なIDを使って個体識別を継続する。この場合、最初のユーザ認証の時点で、ユーザの意思により個体識別を許しているので、プライバシーの問題は生じない。
- 「これはいたずらな不安の煽りである」という合理化, 6月29日
RFIDチップ内に、単純増加カウンタと公開鍵暗号の演算回路と公開鍵を内蔵させる。スキャナからアクセスがある毎に、カウンタの値を1増やしながら、カウンタの値と固定IDの連接ビット列を公開鍵で暗号化してスキャナへの応答とする。スキャナ側は、スキャンする毎に異なるビット列が返ってくるので、そのままでは個人追跡には使えない。チップ内の公開鍵に対応する秘密鍵を保有している者だけが、固定IDを取り出すことができる。
これらでは、仮のID（変化するID）が外に見えているだけで、真のIDが関係者にしか見えないところに存在しており、それは固定IDである。
もうひとつは、IDのドメインを可能な限り狭くすべきだという含みを持たせるためだ。
「IDのドメインが広い」とは、例えば、「どこのサイトに行っても使えるユーザ名」がそれで、具体的には、Microsoft Passportのユーザ名や、NTTドコモのFirstPassのクライアント証明書のcommon name、EZwebの「サブスクライバID」、J-PHONEの「ユーザID」などがそれに該当する。
- 通信キャリアの独占型PKIは安全なのか
これは、「Webのあらゆるログインサービスで、ユーザ名が唯一の機関によって定められている」という状況に近いと言える。つまり、たとえば、Microsoftの「Passport」サービスが独占的に普及した世界を想像すればよい。Windowsを購入すると、無料でPassportサービスにアカウントを作ってもらうことができ、どこのネットショップに行ってもPassportの同じアカウントでログインするという世界だ。さらに、勤務先のイントラネットに外出先からアクセスする際にも、MicrosoftのPassportのアカウントでログインするという世界だ。
このときの「ドメイン」は、そのIDの使えるサイト全域に広がっていることになる。これは「共通ID」と呼ぶこともできる。共通IDは、どこのサイトに行っても同じ、つまり固定であるから、「固定ID」という表現は、そのような「共通ID」のことも指す意味を含ませているつもりだ。（ただこれはいまいちな表現だと思っている。きっと定着したもっとよい専門用語があるのだろうが、不勉強なのでまだ知らない。）
必要最小限のドメインで独立した固有IDが、時刻によって変化しない意味で固定のIDだとしても、それは直ちに問題ありとはならない。例えば、ネットショップなどで、その店のことを信用してユーザ登録し、自分の固有IDでログインしてサービスを受けるシステムのことを、プライバシーの問題があると言う人は少ないだろう。
必要最小限のドメインで独立した固有IDの例としては、ネットショップのユーザ名の他に、日本の住民基本台帳の住民票コードもそれに該当する。住民票コードは、民間での利用が禁じられており、行政機関における法で定められた範囲での利用しかできない*1。これは固有IDであるが「共通ID」（=「固定ID」）ではない*2。
昨日の日記で第三者cookieのことを書いた。本来、cookieは、DNSのドメインごとに名前空間が仕切られており、必要最小限のドメインで独立したものとなるよう設計されたが、第三者cookieのサイト横断的使用という予測できなかった利用形態により、「共通ID」的な利用がされるようになってしまったという話だと言える。
固有IDのドメインが、サービス提供サイトごとに独立していると、ユーザはその都度、IDを使い分け（さらにはパスワードを使い分け）なくてはならず、それが不便すぎるという話がある。だからといって、ここで共通IDを使うことにするのは、技術的に安直な方法だということを認識しておきたい。
Liberty AllianceのID-Federation Frameworkでは、サービス提供サイトごとに独立した固有IDがあることを前提とし、ユーザが自らの意思によって、自身がそれぞれのサイトに持つ固有IDを、必要に応じてそれらが同じ人のものであることを第三者機関（アイデンティティプロバイダ）に登録（アイデンティティ連携）することで、シングルサインオンを実現する。こうした仕組みを導入することで、プライバシーレベルは保たれることになる。
携帯電話のWebにとっては、ID-Federationのような仕組みを導入するのは、複雑すぎて現実的でないという議論があるかもしれない。しかし、簡略化したシステムを導入することはできるのではなかろうか。
簡略化したアイデンティティプロバイダを携帯電話事業者が担い、認証を携帯電話事業者が行う。サービスプロバイダはそれぞれに独立した固有IDの空間を持ち、ユーザとその各サービスプロバイダ用の固有IDとの対応付けを携帯電話事業者が行う。
対応付けの簡単な実現方法としては、DNSのドメインを基にして、ドメイン毎に異なるサブスクライバIDを携帯電話事業者が決めて、それをサービスプロバイダに送信するようにすることが考えられる。サービスプロバイダ側から見ると、ユーザの固有ID（= サブスクライバID）は携帯電話事業者から与えられることとなり、そのIDは別のサイトでは通用しないものであるから、「共通IDのプライバシー問題」は生じない。サービスプロバイダは、認証機構の実装を省略でき、簡単な実装でサービスを提供できるのではなかろうか。
このように、固定IDの問題は技術的に解決可能な方法が存在している場合が多い。利便性を捨てよと言っているわけではないことは、言うまでもない。
今話題となっている、固定ID単純応答型RFIDタグのプライバシーの議論は、固有IDのドメインが制限されていないところに問題の本質があるといえる。供給側の意図として特定のドメインでだけ使う固有IDのつもりであっても、それ以外のところでも使えてしまうのでは「共通ID」として働いてしまう、という話だ。
そして、技術的解決方法は存在するのだが、一部の応用分野では、低コスト化が最優先されているため、対策せずに導入されるのではないか、という懸念が出ているという話だ。
2003年08月19日
■ 家電製品と汎用コンピュータの切り分け
今月公開された、株式会社ラックの「脆弱性報告と公開のポリシー」に、「SNSポリシーに関する意見」として、夏井高人先生の見解が公表されている。この中で、ソフトウェア製品を2つに区分する提案がなされており、たいへん興味深い。
興味深かった結論は、次の部分。
技術的に完全なものとしてソフトウェアを製造・販売またはライセンスし、かつ、完全な法的責任（損害賠償責任、補修責任、交換責任）を負うことを約束しているベンダーについては、そのベンダーの事前の同意がない限り（コンテクストから同意しているものと推定される場合を含む。）、その脆弱性情報を公開することが許されないと解釈すべきであろう。この場合、もし問題が発生したら、そのベンダーが全責任を負うべきである。
これに対し、技術的に完全なものとしてソフトウェアを製造・販売またはライセンスし、かつ、完全な法的責任（損害賠償責任、補修責任、交換責任）を負うことを約束しているのではないベンダーについては、事前の同意なく、その脆弱性を公表しても違法ではないと解釈すべきである。この場合において、そのベンダーが、自分自身以外の者から脆弱性情報が提供されることを嫌うのであれば、誰よりも早く脆弱性を発見し、その情報をユーザに提供するような仕組みを完全に保証すべきである。
この結論に至るまでの論旨はこうだ。まず、
一般に、欠陥のある商品やサービスの提供は、それ自体として違法である。多くの場合、債務不履行（不完全履行）として欠陥の補修や損害賠償の責任を負わなければならない。
とし、ソフトウェアがPL法の適用外であるのは、単に、欠陥の不存在の立証を製造者側に持たせる「証明責任の転換」が適用されないという話であって、欠陥の存在を原告が立証するのであれば、債務不履行（不完全履行）として製造者の責任を追及できるということが説明されている。
続いて、
ほとんどのパッケージソフトウェアの利用契約（ライセンス契約）には、免責条項（免責約款）が付記されている。...(略)... しかし、このような無制約の免責条項は、消費者契約法によって無効なものとされているので、意味のない条項である。
としながらも、
しかしながら、汎用のソフトウェアには多少困った事情もある。つまり、ソフトウェアの開発・出荷時には、そのソフトウェアがどのようなPCにインストールされるのか、インストールされるPCにはどのような装置や機器が接続されているのか、インストールされるPCには他にどのようなソフトウェアがインストールされているのかを予め知ることができないという問題である。この組み合わせ問題は無限に存在し得るので、...(略)
として、汎用コンピュータにおけるソフトウェアの完全性を求めることが困難であることにも理解を示し、
厳格に法を適用することは、確かに酷であるような場合がある。
としている。
そこで、提案されているのが、最初に引用した部分の結論である。つまり、欠陥に対する「完全な法的責任」を約束している場合には、第三者の脆弱性公開を許されないものとし、責任を約束していない場合には、脆弱性公表を違法でないとするべきだと。
夏井先生のこの小論では、第三者による脆弱性情報の無断公開を許されないものとする立場を基本とした上で、「完全な法的責任」を約束をしていない場合を例外として、その場合には脆弱性公開が許されるという構成になっているように思う。
「完全な法的責任」を約束をしている場合に、第三者の脆弱性公開がなぜ許されないのかという点について、まだ議論の余地があるように感じられるのだが、この小論では、脆弱性公開が許される条件を示すことに力点が置かれているのだと思う。現状は、ほとんどのソフトウェア製品が「完全な法的責任」を約束していないのだから、この小論は、脆弱性公開を違法でないと解釈すべき根拠を示したもの言える。
それと同時に、「完全な法的責任」を約束する販売形態を製造者に促す意味も含まれているように思う。製造者の立場として、脆弱性情報をコントロールするという目的のために、「完全な法的責任」を約束することにメリットが生まれる。
私もかねてより、家電製品と汎用コンピュータはそろそろ明確に区別すべき時期にきているのではないかと考えてきた。汎用コンピュータ用のソフトウェアの完全性保証が無理なのは、夏井先生の小論にもあるように、同時に動作する他のソフトウェア部品との相互作用など、予測が困難な要素が多すぎるからだ。その一方で、消費者の多くが、「パソコン」を電子メールとWebとデジカメ写真編集くらいにしか使っていないという実態があるように思う。
つまり、メールとWebと写真（とあといくらか）の機能しか持たないような、お手軽なネット端末が、「家電製品」として販売されてもよいのではないかと思う。そうした製品は、過去にもいくらか出ていたと思うが、ことごとく失敗してきた。売れなかった原因は、拡張性がないために、最新のWeb技術に追いついていけずすぐに陳腐化したこと、もうひとつは、価格を抑えることが簡単でなかったためではなかろうか。
本来、技術者が自己責任で使う道具であった汎用コンピュータが、ごく普通の消費者にまで「パソコン」として売り込まれているという、ここ数年の状況は、汎用コンピュータにソフトウェアを載せるという作り方が、低価格で製品を提供できたことと、アプリケーションソフトウェアの進歩が著しかったためであろう。
しかし、ここ1年ほどで、Webにせよ、メールにせよ、進歩が緩やかになってきたのではないだろうか。だとすれば、今こそ、「家電製品」としてのネット端末が商機を迎えているかもしれない。そうであるなら、セキュリティ欠陥について「完全な法的責任」を負うと約束する販売形態も、現実味を帯びてくるのではないか。
携帯電話は、「完全な法的責任」を負うと約束しているかどうかは知らないが、搭載ソフトウェアに欠陥が見つかった場合、回収・交換という措置がとられている。その一方で、搭載機能が高度化し、欠陥をなくすのが大変になってきていると聞く。あるシンポジウムで、現場の開発技術者の声として聞いたところでは、携帯電話のソフトウェアも、Windowsなどと同じように、パッチを（電波経由で）自分でダウンロードして修正できるようにしたいという意識があるようだった。
Java搭載の携帯電話は、拡張性と完全性の両立を実現したものだったと思う。同時に複数のアプリケーションが動かないようにしたり、非常に強く制限されたJava機能により、安全性も確保されていた。しかし、これも最近では、拡張性が不十分だということで、複雑化、機能制限の緩和という方向に向かっており、「パソコン」への道を歩み始めている。携帯電話も「無保証」の文化に移ってしまうのだろうか。
それはさておき、「完全な法的責任」が約束されている製品に、第三者が脆弱性を見つけた場合、どのような展開を生むだろうか。発見者が製造者に報告をしたとき、無視されたらどうなるだろうか。公開が法的に制限されているとなると、発見者はどこかに告発しなくてはならない。どこがそれを受け付けるのか。
現在のように、「無保証」のソフトウェアに欠陥が発覚しても、製造者がたいした社会的、経済的ダメージを受けない状況では、発見者も比較的気楽だったのに比べて、「完全な法的責任」が約束されている場合には、発見者に身の危険が及ぶ（もしくは、そうなると発見者が感じる）可能性が高くなるため、告発者の保護にも配慮が必要であろう。
また、製造者が「それは問題ではない」という見解を示すことが起こり得る。それは、これまでにもたびたびあった。特に日本では携帯電話事業者がそうした見解を示すことがある。
例えば、2001年4月にiアプリ開発者達のメーリングリストで発覚したスクラッチパッドの欠陥では、発見者が情報漏洩の危険性があると指摘していたにもかかわらず、携帯電話事業者は「動作が不安定になる場合がある」とだけ説明したということがあった。
- 関連報道: ドコモ最新型携帯 相次ぐ欠陥「バグ 避けられぬ」 専門家通報ルール確立訴え, 西日本新聞, 2001年5月17日朝刊
他にも、2002年7月にauの料金照会ページが他人にも見えてしまうという欠陥が発覚した際に、携帯電話事業者が、「個人が特定できる情報が漏れることはありません」と発表したことがあった。
- 関連: 漏洩データに個人を特定できる情報が含まれていなくても、プライバシーは侵害され得る, [memo:4710]
こうした場合に、発見者が自由に情報公開できないとなると、誰がどうやって脆弱性を評価するのかということになる。
ところで、ソフトウェアの製造物責任を考えるとき、他の製造物と比べてソフトウェアのセキュリティ欠陥には、再現性が高いという特徴がある。
壊れやすい椅子とか、火を噴きやすい電源といった欠陥は、確率的にしか事象が発生しないため、構造的な欠陥があることを消費者が立証するのは困難であり、だからこそPL法によって、欠陥の不存在を被告が証明しなければならないことになっているのだろう。それに対し、ソフトウェアのセキュリティ欠陥は、見つかってしまえば、100% の再現性があって検証が可能な場合が多く、欠陥の立証が容易かもしれない*1。
*1 ただ、被害は起きたものの、原因がわかっていない場合には、やはり立証が困難かもしれないが。
2003年08月21日
■ 自動車登録番号追跡サービスのビジネスモデル
結城さんの「固有IDのシンプル・シナリオ」の、「加筆・修正予定のメモ」に現時点で掲載されている論点のいくつかについて、私なりのコメントを書いてみる。
自動車のナンバープレートは固有IDになりうるだろうか。
昨年のJIPDECのヒューマンインタフェース技術調査委員会の席で出た話題なのだが、あまり書くと本当にやる奴が出かねないと、あまり書きたくない気もしないでもなかったのだが、書いてしまおう。
次のような、USB2.0接続のCCDカメラと専用ソフトウェアのキットが、ブロードバンド家庭に無料配布され、そのソフトを動かしておくだけで、月に1,000円〜1万円程度もらえるとしたら、あなたは参加するだろうか。
- USB2.0接続の安価で高解像度なCCDカメラを、窓の、外の道路がよく見える位置に取り付ける。
- カメラを接続したパソコンを、常時電源を入れ、常時接続のインターネットにつないだままにし、専用ソフトを動かしておく。
- 専用ソフトは、窓の外の画像に映った自動車のナンバープレートを画像解析し、自動車登録番号（ナンバー）を抽出し、これをインターネット経由でサーバに送信する。（設置場所の情報と供に）
- 情報を集めたサーバは、その情報を必要とする人に有料で提供する。
- 運営者は、参加者に対し、車の流量に応じた協力謝礼金を支払う。
このシナリオは、ほんの数年前では、コスト的にあり得ない話だった。現時点でもやや苦しいが、ナンバープレートを読み取るのに十分な解像度のCCDカメラが、このビジネスに見合うだけの低価格となるのは時間の問題であろうし、パソコンが十分に低い負荷でナンバープレートの解析を実行できる時は、もうすぐにでもやってくる（もしかしたら既に可能か？）だろうし、ブロードバンド常時接続はもう普及してしまった。
あとは、協力者への謝礼金の額と協力ノード数、集積情報の販売価格とその需要のバランスが、ビジネスとして成立するかどうか。こうしたビジネスが考えられ得るのが、自由なインターネットの優れたところだ。
余談だが、自動車登録番号が得られると、最寄の陸運局に行けば、誰でもどこの地域の車でも、所有者や使用者を調べることができるという話がある。平成13年から本人確認が必要となったようだが、本人確認といっても、請求者が偽でないかを確認するだけのようなので、請求することに後ろめたさがないならば、誰でも取得できるのだろうか。
それはともかく、所有者を特定しない場合でも、情報の価値はあるだろう。同じ車が、いつどこにいたかの情報は、渋滞予測や、マーケティングなどにも利用できそうだ。そして、所有者を特定できる人がその情報を購入すると、所有者のプライバシーが損なわれることになる。
さて、これが本当に民間で始まったとすると、その後どうなるだろうか。おそらく、法規制を求める声があがり、個人情報保護法の延長か何かで規制されることは起こり得るように思う。
このシナリオが規制されそうに思えるのは、次の性質があるからだろう。
- 自動車登録番号が「個人情報」だと直感する人は多い。（陸運局で調べられるため。）
- 自動車登録番号は法律で定められた番号であるため、法律で規制しやすい。
- 自動車登録番号の民間での特定利用を禁じても、利便性にあまり不都合はない。
それに比べて、RFIDの固定IDや、現状のサブスクライバIDや、固定IPアドレスは次の性質を持つ。
- IDが個人情報だと直感できない人が多いらしい。（今の議論を見ていると。）
- IDは民間が自由に用意したものなので、法律で規制しやすいわけではない。
加えてRFIDの場合には、さらに次の性質もあるので、法による規制はうまくいかないように思える。
- RFIDのIDは街中でスキャンして積極的に有効利用するというのが、期待されている「ユビキタスコンピューティング社会」の姿である。
そして、自動車登録番号をナンバープレートとして見えるところに設置しなくてはならないのは、ひき逃げ事件があったときに、現場にいた人が（特別な装置を持たなくても）目で見て番号を記憶できるようにしておくためなどの理由で、やむを得ない制度であるのに対し、RFIDにはそうした、やむを得ないという事情が存在しない。
「固有IDをもったアイテムを知らないうちに渡される」は団体客が目の前を通った場合、アリス個人の特定は難しいかも、という指摘あり。
場所Aで、アリスが団体にまみれた一人だったとしても、場所Bでアリスが単独で存在していれば、場所Bにおいて、目の前にいるアリスが場所Aにいたことは判明してしまう。こうした判明を避けるには、アリスは、ID読取機を持っている知人の前、個人情報を提供する場（のうちID読取機が設置されているかもしれない場所）のすべてで、団体行動をとるようにせざるを得ない。
「薬品の固有IDをすりかえるというのは極端な例なので不自然」という指摘あり。
これはプライバシーとは別の問題だが、物の管理を電子的な方法に頼り過ぎたとき、過信によってそうした事故や事件が起きかねないことが、業界でも心配される点として議論の要点のひとつとなっている。
■ ネタメモ
甲南大学法学部の園田寿教授による「韓国法最前線」に、興味深い資料がある。
- 金基中, 情報支配社会における電子住民カードの意味とその危険性
- 金鐘鐵, 大韓民国の住民登録制度
- 韓国行政自治部, 大韓民国の住民登録制度 (PDF)
- 韓国ソウル特別市瑞草区, 韓国の住民登録制度 (PDF)
まだ読んでいない。
- （韓国）個人情報保護ガイドライン
第10条（技術的対策）サービス提供者は、利用者の個人情報を取扱うにあたって、個人情報が紛失、盗難、漏れ、変造または壊されないように、安全性の確保に必要な次の各号の技術的対策を講じなければならない。
- パスワードなどを利用した保安装置
- ワクチンプログラムを利用したコンピューターウイルス防止装置
- 暗号アルゴリズムなどを利用して、ネットワークに個人情報を安全に電送できる保安装置
- 侵入遮断システムなどを利用したアクセスコントロール装置
- その他安全性確保のために必要な技術的装置
ウイルス対策ソフトの導入は書かれているのに、セキュリティホールの修正のことが書かれていないあたりが、情けない感じ。2000年に書かれたものだから、「セキュリティ対策といえば、ファイアウォール、ウイルス対策、暗号」という素人発想もやむを得ないか。日本の各種ガイドラインもその程度だったし。それにしても、どうして素人がこういう文書の作成に携わるのだろうか。
2003年08月22日
■ プライバシーに関わらないRFID応用
日経デジタルコアの4月のトレーサビリティ研究会の席で、RFIDを研究題材となさっている国立情報学研究所の佐藤一郎さんから、興味深い話をうかがった。
（ユビキタスコンピューティングをプライバシーを確保しつつ実現するには）RFIDを（人が身に付ける）物ではなく、街角の方に付け、人の方がリーダを持って歩けばよい。
リーダを携帯ネット端末と一体にし、読み取った場のIDをネット経由で検索して利用するようにすれば、プライバシーは、携帯端末の通信に使用する通信事業者と、通信先のコンテンツプロバイダの運用体制によって確保されることになる。
このように、当然ながら、RFIDも使い方によって、プライバシーの問題を生じさせない場合がある。佐藤さんの7月12日の日記でも、
Wal-MartがRFIDタグを実証実験の延期を決めましたが、物流や倉庫管理を目的に、複数商品を詰めたパレットや段ボールにRFIDタグを貼る分にはプライバシー上の問題もおきないのに、個々の商品にまで色気を出すので話がややこしくなります。どちらにしてもRFIDは話題先行のバブル状態でしたから、これで落ち着いて実用化ができるのではないでしょうか。
と述べられている。
日経ニューメディアの7月25日の記事に次の記述があった。
今回の欧米の動きは，日本の関係者にも衝撃を与えている。欧米と同じ事態を招かないために総務省は，日本では電子タグに対応した各種のネットワーク対応サービスを充実させることによって，消費者に様々な利便性を訴える考えである（詳細は日経ニューメディア2003年7月28日号に掲載）。 日経ニューメディア, 解説：電子タグの導入中止に傾く欧米の流通業界，プライバシー問題から消費者が反発
これを見て、「ごまかし通そうという話？」と嫌な予感がしたのだが、日経ニューメディア2003年7月28日号を取り寄せて記事の全文を読んでみたところ、次のように書かれていて、ちょっと安心した。
こうした事態について総務省は，「欧米では犯罪発生率が高いという背景があるため，万引きや盗難などを防止するために電子タグを導入するという発想から抜けきれない。管理者サイドに立ったこうした導入方針が，消費者の反発を招いたのではないか」としている。...(略)
欧米と同じ事態を招かないために総務省は，日本では電子タグに対応した各種のネットワーク対応サービスを充実させることによって，消費者に様々な利便性を訴える考えである。例えば食品の流通管理では，消費者に農薬の使用履歴などの正確な情報を提供できる。またＩＴＳ（高度道路交通システム）関連では，車両ごとに最適な経路に誘導するサービスなどが考えられている。...(略)
もっとも日本でこうした導入方策が考えられたのは，外国に比べて犯罪発生率が低いため，流通業者が犯罪防止の目的だけから電子タグのシステムを導入しても，現行のバーコードに比べて採算が合いにくいという事情があったからだ。実際こうした理由から日本では，流通業者による電子タグの導入意欲は低い。...(略)
「高度道路交通システム」についてはどうやってプライバシーを確保するのか、やや心配なところもあるが、この応用事例では、RFIDのコストは数百円以上するものでも受け入れられるだろうと考えると、チップ内暗号演算による解決が可能かもしれない。
8月18日には、総務省の「ユビキタスネットワーク時代における電子タグの高度利活用に関する調査研究会」の中間報告が公表された。
まだ全部を読んでいないが、中間報告概要をざっと見ると、推進分野として選出された応用事例が、比較的、個人のプライバシーに影響のないものが注意深く挙げられているようにも見える。
中間報告の第4章を、「プライバシ」で検索してみると、
■プライバシー開示制御
電子タグが一般消費者との接点を持つ場面においては、タグの機能の無効化、および消費者のパーミッションによる情報開示レベルのコントロールなどを実現することによって、技術面からのプライバシー保護を実現する必要がある。
■ユーザーに対するサービス品質・リスクの開示
電子タグを利用したサービスを消費者等に対して提供する場合、そのサービスの品質レベルの保証を行う必要がある。また、サービス利用者にとって何らかのリスクがある場合には、そのリスクを明確にした上でサービスの提供を行う必要がある。
■データ活用のメリット訴求による社会的コンセンサス形成
電子タグの利活用が高度に進んだ場合のメリットを消費者あるいは企業に示した上で、電子タグ普及に対する社会的コンセンサスを形成する必要がある。コンセンサスを得ることにより、プライバシー等の問題に対する過剰な抵抗を軽減させることも可能であると考えられる。
■プラットフォーム間プライバシー保護
タグの無効化やユーザーのパーミッションによる情報開示レベルのコントロールなどを、プラットフォームが連携した場合にも有効にする必要がある。また、異なるプラットフォームに対してはそれぞれ適した情報開示レベルを設定する、などの仕組みを実現する必要がある。
■「人」に関わる情報を扱う際のプライバシー保護
電子タグが人によって所有され、個人の属性情報と紐づいた場合には、プライバシーの保護をどのように行うかが課題となる。前述のように技術的な対応方策の開発・実用化を積極的に進めると同時に、運用面の対応を強化することも必要であり、このため、電子タグの利活用に対応したプライバシー保護ガイドラインの制定などが必要になると想定される。
といった論点が書かれている。
RFIDは、応用目的によって、ICチップにコストをかけられる場合や、通信距離を数ミリに抑えてかまわない場合や、個人に属さない場合など、プライバシーに影響を与えないものとなることがある。
重要なことは、それぞれの応用において、プライバシーをどのようにして確保するかを洗い出し、解決が困難な応用については当面実用化しないことを早めに決断し、消費者に隠すことなく説明していくことであろう。
日経コンピュータ誌のように「問題がないことにする」というのは、業界の足をかえって引っ張るだけだろう。そろそろそのことに気づいて欲しいものだ。
2003年08月23日
■ 続・ツーカーセルラー東海から回答書がきた
8月9日の日記で、(1)〜(4)の4項目の質問をしたのに(1)と(3)にしか回答をくれなかったと書いた件について、その後、再度コールセンターに問い合わせ*1、(2)と(4)についても回答をくれるように依頼していたのだが、その回答書が来た。
2003年8月15日（挨拶部 略）
■コンテンツプロバイダとの契約にて「サブスクライバーIDは個人情報なのでこれを厳重に管理し外部に漏らさない」との項目はあるか？
（回答）コンテンツプロバイダとの契約におきましては、本サービスの提供にあたり知り得た顧客に関する一切の情報について、第三者へ開示・漏洩しないことを明記致しております。
■非公式サイトヘのサブスクライバーIDの送信を止める機能はあるか？ またEZweb@mailを一旦削除して登録しなおす方法以外に、サブスクライバーIDを変更する方法はあるか？
（回答）現行のシステムでは、非公式サイトにサブスクライバーIDへの送信を止める機能はございません。またEZweb@mailを削除して再加入頂く以外にサブスクライバーIDを変更することはできません。
「知り得た顧客に関する一切の情報について、第三者へ開示・漏洩しない」ことが契約で約束されているというのであるから、顧客としては、この文章を見ると直感的に安心感を覚える。
しかし、この回答文は、よく読むと、サブスクライバーIDが「知り得た顧客に関する情報」に含まれるのかどうか、答えていない。「一切の情報」という文節に注目すれば、含まれるように聞こえるが、「顧客に関する」という文節に注目すると、顧客に関するものとしているのかどうかが、不明だ。
この回答を前回の回答とあわせて4項目を並べてみると次のようになる。
(1) サブスクライバーIDは個人情報であるか。
それ自体は、単なる文字、数字及び記号の羅列であって、それによって個人を特定できる情報ではありません。
(2) コンテンツプロバイダとの契約にて「サブスクライバーIDは個人情報なのでこれを厳重に管理し外部に漏らさない」との項目はあるか？
コンテンツプロバイダとの契約におきましては、本サービスの提供にあたり知り得た顧客に関する一切の情報について、第三者へ開示・漏洩しないことを明記致しております。
(3) 非公式サイトに対してサブスクライバーIDを送信するのはプライバシーの問題があるのではないか。
コンテンツプロバイダー（以下「CP」）への提供自体に問題はないと考えております。
(4) （略）
(1)の回答からすれば、サブスクライバーIDは、(2)における「顧客に関する情報」にはあたらないと解釈できる。
その解釈の下では、公式サイトとの契約においても、（個人情報との結び付けさえしなければ）外部に転売することが許される（誰かわからないこのIDの人が、いつどんな閲覧をしたかの情報の転売が許される）という解釈も可能に思える。
一方、(2)の質問は、「これ（サブスクライバーID）を厳重に管理し外部に漏らさない」ことを約束しているかという問いである。「顧客に関する情報」でないのなら、
サブスクライバーIDは個人情報ではないので、契約において個別に明記していません。と回答してもよさそうなものだ。それなのに、「顧客に関する一切の情報について開示・漏洩しない」という回答をここにもってくるのには、「サブスクライバーIDの保護を契約で明記していない」とは回答したくないという気持ちがあるのだろう。
であるなら、なぜ(3)のように、契約関係にないコンテンツプロバイダーである「非公式サイト」への提供について、「問題はない」という回答になるのだろうか。
ここでもやはり、「お客さまの情報は守る」ということと、「お客さまの情報ではない」という二枚の舌が巧みに使われている。
*1 コールセンターの責任者は、今回もとても顧客想いの対応だった。私からの電話だとわかるやいなや、こちらから話の口火を切るより先に、回答書が回答になっていなかったことに理解を示すのだ。私も昔、いろいろなコールセンターに問い合わせたことがあるが、こんな顧客本位の対応はとても珍しい。回答に責任を持つため明快な回答を避けざるを得ない立場の者と、顧客対応の者とは別といったところだろうか。まさに組織と顧客の仲介役という感じだった。
2003年08月24日
■ セキュリティ研究者はプライバシーを理解しているのか
日本の移動通信システムに関わる業界と個人が集結した「モバイルITフォーラム」というグループがある。ここに、7月25日に公開された「MC部会平成14年度活動報告書」という資料がある。その中に「技術専門委員会活動報告 認証WG報告書」という文書がある。この中に「モバイルID」という用語が出てくる。
「モバイルID」という用語が現れる個所を引用すると次のようになる。
モバイルITフォーラム, MC部会平成14年度活動報告書 技術専門委員会活動報告 認証WG報告書, p.42
- 携帯電話で実装される可能性の高いという観点（既述）から、電子メール、Ｗｅｂアクセス、電子署名（ＦＯＲＭ署名）を考える。
- 電子メールでは、メールアドレスがユーザID として一般に利用されている。認証の確実性を上げるための方法としてはS/MIME が一般的であり、S/MIME 用証明書がプロファイルの参考になる。
- Web アクセスにおいては、携帯電話固有のID（ソフトID、ハードID など、以下モバイルID）がユーザID としてE コマースに使われている。これらはモバイルの世界固有の方法で実現されている。PKI ベースの認証が行なわれていないため、証明書のプロファイルは存在しない。
- 電子署名は、市場ニーズは顕在化していないが、法的効力をもたせるために、個人の氏名を含むユーザID が使われると思われる。民生向けの特定認証業務のプロファイルがある。
２．２．２．２ 証明書の位置付けに関するプロファイル
２．２．２．２．１ 証明書発行対象本プロファイルでは、携帯電話契約の「契約」に対して発行することとする。なお、証明書に記載する発行対象は、契約ごとに一意で、かつ証明対象の特定が困難なモバイルID で表現する。
２．２．２．３．２ 証明対象の表現
証明対象は「Subject」にDN(distinguished name)で表現する。以下の項目は共通仕様とし、他の項目(OU 等)は任意とする。
C = jp
O = (オペレータ社名の英語表記)
CN = (モバイルID。フォーマットは任意)
用語集
モバイルID
携帯電話会社が携帯電話契約の「契約」に対して付与するID で、契約ごとに一意で、かつ証明対象の特定が困難なID を意味する。
「モバイルID」とは、KDDIグループ（auおよびツーカー）の「サブスクライバーID」、J-PHONEの「製造番号」ないし「ユーザID」、NTTドコモの「端末ID」などのことを指すようだ。この報告書は、これらのIDが、「証明対象の特定が困難なID」であるという前提をおいている。
この報告書は、モバイルコマースを実現するための認証技術として、どのような方式が適切であるかを議論し、結論をまとめたものだ。この報告書は90ページにもおよぶが、この内容を8ページにまとめたものが、7月18日に開催された、情報処理学会コンピュータセキュリティ研究会と電子情報通信学会情報セキュリティ研究会の合同研究会で、研究会報告論文として発表されている。
- 田中 俊昭, 関野 公彦, 菊地 仁, 梅澤 克之, モバイルコマースにおけるPKIの現状と課題 ―mITFモバイルコマース部会認証ＷＧの活動状況―, 情報処理学会研究報告「コンピュータセキュリティ」, No.22-28, 2003.
その論文から冒頭部分を引用する。
1. はじめに
公開鍵基盤（ＰＫＩ）を認証技術として用いた電子政府の実現にともない、これまでのＰＫＩの様々な技術検討が実サービスとして結実し、その技術の可能性が立証されつつある。一方、携帯電話の普及に伴い、モバイルインターネットサービスが普及し、着信メロディの有料配信サービスのような携帯電話を用いた決済サービス（モバイルコマース）が立ち上がり始めている。このような背景を踏まえ、より安全で信頼性の高いモバイルコマースの実現と、オープンな標準技術によるモバイルコマースへの適用が注目されている。
ＰＫＩは、その技術標準の核となるX.509がITU-T/JTC1で、また、様々な拡張検討がIETFのPKIX-WGで検討されており、現在、ドラフトも含めて膨大な技術仕様ができあがっている。これまで、この技術仕様について机上調査あるいは、各種ベンダー製品の相互接続実験に基づいた検討を行うなどの試みがあるが、モバイルコマースという一つのサービスに着目し、その適用性について検討を行った例はなく、ＰＫＩに基づくモバイルコマースの実現性について、課題とその解決法を明確にすることが、モバイルコマースをさらに発展させ、かつ、ＰＫＩ技術の利用促進に大きく寄与すると考えられる。
これらの点を考慮し、非営利団体であるモバイルＩＴフォーラムＭＣ部会の認証ＷＧでは、平成１３年度から、上記に述べたＰＫＩのモバイルコマースへの適用を目的とした技術検討を進めている。本稿では、モバイルコマース部会・認証ＷＧでの１４年度の検討結果であるＰＫＩ技術の現状、ＰＫＩをモバイルコマースへ適用する際の課題とその検討状況について報告する。
2. モバイルＩＴフォーラムＭＣ部会
モバイルＩＴフォーラムは、第４世代移動通信システムやモバイルコマース等の新世代モバイルの早期実現を図るため、新世代モバイルに関する研究開発及び標準化の調査研究、関係機関との連絡調整、情報の収集を目的とした非営利団体であり、その中でも、モバイルコマース部会（ＭＣ部会）は、インターネットにおける標準技術をベースとして携帯電話、モバイル網を対象に、モバイルコマースを実現するためのビジネスおよび技術の側面からの検討を行う作業部会である。
この論文は、まず最初に、モバイルコマースにおけるオンラインクレジット決済の方式を、「データ入力型モデル」と「端末格納型モデル」、「サーバ管理型モデル」に分類し、それぞれにおいて必要となる認証方式を洗い出した後、ドメイン間認証技術を分類し、その後に、共通プロファイルの規定について述べている。
さて、肝心の部分は、3.4.3節「モバイルID」にある。ここには次のように書かれている。
3.4.3. モバイルID
一般に、公開鍵証明書が証明する対象(subject)としては、氏名、電話番号、端末製造番号、契約番号などいろいろな可能性があり、サービス提供者が統一的に扱うためには共通化が必要である。プロファイルの規定に当たっては、証明書発行者がオペレータドメインのCAであることから特に以下の条件を考慮した。
(1) 加入者のプライバシ保護
公開鍵証明書への個人情報を記載にはプライバシ保護の観点から注意が必要である。署名時あるいは公開鍵証明書の通知時にはユーザプロンプトにより利用者に注意を促すことが一般に行われているが、通信事業者としては携帯電話ユーザのリテラシや電話紛失等の事故を考慮し、証明書の記載事項レベルでより厳密にプライバシを考慮する必要がある。
(2) 回線契約業務との整合性
（略）
(3) 端末変更の可能性
（略）
以上の考察により認証ＷＧでは
- リアルの世界で利用者個人を特定する情報（実名、電話番号、住所）が隠蔽される。
- 機種変更時にも連続性を保証される。
という性質を持つIDとして、加入者契約と一対一に対応し匿名性を持つIDを定め「モバイルID」と呼ぶこととした。モバイルIDは上記条件を満たす限りフォーマットは自由である。モバイルIDはオペレータドメイン証明書のSubjectのCNとして用いられる。
つまり、NTTドコモのFOMA向けクライアント認証証明書発行サービス「FirstPass」が、ここで提案されている方式の一実装といえる。
6月24日の日記「通信キャリアの独占型PKIは安全なのか」や、8月17日の日記「「固有ID」の問題なのか「固定ID」の問題なのか」で書いたように、すべてのCP/SP（コンテンツプロバイダ/サービスプロバイダ）ドメインに共通のIDとなる「モバイルID」を使用することは、第三者cookieや、住民票コードの民間利用などと同様のプライバシー問題を生むものである。
しかし、この論文にはそのことが全く考察されていない。「MC部会平成14年度活動報告書」にもその考察はない。
3.5節で考察されているように、現状のモバイル端末がネットワーク的、ハードウェア的に非力であることと、ユーザのリテラシの低さからくる制約は、たしかにあるだろう。3.5.1節には、ドメイン間認証方式として「独立方式」を採用しない理由が次のように述べられている。
独立方式を用いてドメイン間認証を実現する場合には、複数のドメインの証明書を検証するために、ドメインの数だけ認証局証明書をモバイルユーザがポリシーを理解した上で、安全に入手する必要があり、これは、ユーザリテラシ、端末の記憶容量等の観点から問題点が多い。
「独立方式」とは、サービスプロバイダ自身が運営する認証局からユーザ証明書としてクライアント証明書を発行してもらう方式のことで、PCのWebブラウザではこれが標準となっている。6月25日の日記では次のように書いた。
この件で私が言いたいのは、「FirstPass」は大成功するかもしれないが、「クライアント認証ってこういうものなのね」という理解はして欲しくないということだ。
モバイル端末の上記のような制約から、独立方式ではなく、オペレータドメイン（携帯電話事業者）が認証局となる方式を採用せざるを得ないという結論を出すのは、まあ、よいとしよう。プライバシー上の問題があるにもかかわらず、それを採用し、問題点について触れないようにしておくというのは、営利企業の行動としてはしかたのないことだと、諦めるとしよう。「モバイルITフォーラム」が非営利団体だとはいえ、所詮は業界団体なのだからしかたのないことだと、諦めるとしよう。
だが、情報処理学会のコンピュータセキュリティ研究会、電子情報通信学会の情報セキュリティ研究会という、学術発表の場において、問題点の議論を避けるというのは、いかがなものか。
論文では、「証明書発行者がオペレータドメインのCAであることから特に以下の条件を考慮した」として、「加入者のプライバシ保護」を挙げているものの、実名、電話番号、住所をDNに含めないようにしたというだけで、問題は解決しましたと言わんばかりである。
「固定IDのプライバシー問題は程度問題であるから、程度を考察した結果、モバイル端末の制約上、やむを得ない選択といえる」という結論を出したのなら、その過程を書くのが学術発表というものだ。
これが、意図的に問題点を隠蔽したものではないとするならば、固定IDの問題を知らないということなのだろう。
「セキュリティ研究者」といっても様々な分野の人たちがいる。暗号のプライバシー応用の研究をしている者からすれば、モバイルIDが「匿名性を持つID」とは片腹痛い話だろう。セキュリティ脆弱性を研究する者からすれば、第三者cookieのプライバシー問題や、SuperCookies問題といった過去の事例から、モバイルIDがプライバシー上のセキュリティホールと批判されることは容易に予測できるだろう。PKIのセキュリティ研究者は、固定IDの問題を本当に知らないのか？
しかし、2001年11月に掲載されたZDNet JAPANの記事「「勝手サイトのトラフィックを増やしたい」──WAP2.0に賭けるKDDI」という記事に次の記述がある。
またEZweb端末では，加入者情報である「サブスクライバID」がサーバ側で簡単に取得できるのが特徴だ。NTTドコモなどではサブスクライバIDは公式コンテンツ向けにしか提供されず，一般サイトではユーザー認証に工夫が必要。新端末でも「社内で議論はあったが，サブスクライバIDは変わらず取得できる」と保戸田氏は言う。
NTTドコモでは、契約の縛りのある公式サイト内で閉じたドメインでしか、サブスクライバーIDは使われておらず、503i以降で導入された、「端末ID」を非公式サイトにも送信できるようになった機能も、<form>タグに「utn」属性が付けられているページだけで送信されるもので、かつ、ユーザの同意確認付きという配慮がなされている。これは明らかにプライバシーへの配慮であり、同業他社であるKDDIが、その意図を知らないはずがない。「社内で議論はあったが」とは、プライバシーの問題があるとする意見もあったということだろう。
1年半前に既に「社内で議論はあった」という性質の問題について、モバイルITフォーラムのような場で議論されないなどということがあるのだろうか。ましてや、学術発表の場で話題にしないなどということがあっていいのか。
学会発表の日、質疑応答で質問の手を挙げたが、先に出たぬるい質問にのらりくらりと時間をとられ、時間切れで議論にならなかった。セッション終了後に講演者に質問に行ったとき言われたことはこうだった（メモより）。
- ユーザに説明すればよいことだ
- 住民票コードとは別の話ですよね、番号を付けられるのがイヤだとか
- 法律で担保すればよい
「ユーザに説明すればよいこと」というが、NTTドコモの「FirstPass Q & A」のページには、当時、次のように書かれていた。
Q. FirstPassではユーザ証明書を利用して認証を行うようですが、個人情報が流出することはありませんか？
A. ユーザ証明書にはお客様の名前や電話番号等個人情報が記載されていません。ユーザ証明書だけでは個人情報が流出することはありません。
その後このページは改定されたようで、現時点の同ページは、次のようになっている。
Q. FirstPassではユーザ証明書を利用して認証を行うようですが、個人情報が流出することはありませんか？
A. ユーザ証明書には重複しない番号が契約者ごとに割り当てられており、お客様の名前や電話番号等のドコモが管理しているお客様情報は記載されておりません。ユーザ証明書から、ドコモの管理するお客様の名前や電話番号等のお客様情報を知ることはできません。
「ドコモの管理するお客さま情報」は知ることはできないというのは、そりゃそうだろう。だが、問題にされているのはそういうことではない。これが、発表者らの言う「ユーザに説明すればよいこと」なのか？ 改定してもこういう説明に終始するわけか。
ユーザに説明すべきことは、まず少なくとも、この図*1の左下の画面にある「ユーザ証明書を送信します はい/いいえ」の確認画面で、「いいえ」を選択すべきなのがどういう場面なのかということだ。「アクセス先のサイトが信頼できないときには「はい」を押さないでください」と説明すべきだ。どうしてそれを説明しないのか。せっかくQ & Aを改定したというのに。
「住民票コードとは別の話ですよね、番号を付けられるのがイヤだとか」という発言には、心底呆れた。住民票コードの民間利用が禁じられた理由を、理解していないということだ。セキュリティ研究者がだ。
「法律で担保すればよい」については、8月3日の日記で述べたとおりだ。
我ながら、こういうことをこういうところに書くのはいかがなものかとも思う。反論があるなら、同じ学会の場で発表するのがスジだろう。だが、そういう悠長なことを言っている場合ではない。これは霞を食う話ではなく、社会に直結した問題だ。加えて言うと、情報処理学会は、そういう問題を議論する場になっていない。淡々と論文発表が積み重ねられているだけで、議論というものが存在しない。「誌上討論」という制度が設けられてはいるが、基礎領域以外の分野で活用されているのを見たことがない。
正直なところ、私もこういうことを書くのはつらい。実はごく身近な方が関係者だったりすることもあるので、こういうところに書くのはつらい。この件は当事者には既に言いたいことを言った。それでもここに書くのは、固定IDのプライバシー問題がかくもきちんと対応されていないという現実を、とりあえず多くの技術者が知ることしか、この問題の解決の道はないと思うからだ。このことについては、7月18日の日記「いろいろな人に会うということ」に書いた。
結城浩氏の日記「「固有IDのシンプル・シナリオ」を書いた経緯」で、氏は
しばらくして高木さんの日記が「はてなダイアリー」で始まり、固有ID（固定ID）の問題がなかなか理解されない、という話題が書かれていました。（中略） 高木さんの書かれている内容もよく理解できました。しかしそれと同時に、高木さんの文章に物足りないものも感じていました。 1つは長いこと。それから話が正確で具体的であるあまり、話の大きな流れが見えにくいこと、それから当事者に対するいらだちがちらちら文章の中に現れるためか、「技術そのもの」よりも「人」にフォーカスがあたりがちだという点です。
と述べている。同氏の「固有IDのシンプルシナリオ」は、この問題の当事者の人の要素を排除したものなのだろう。
だが、これは本質的に「人の問題」なのだ。技術的な理屈はべつにたいした話ではない。問題に薄々感づいていながら、問題がないことにする人、フォーラムや学会の場ですら問題点を整理しようとしない人、「ユーザに説明すればよいこと」と言いながら、ユーザには決して説明することをしない人。そこにこそ問題の本質がある。
学会発表ではこういう「人の問題」は書くわけにはいかないだろう。だから5月5日、このように日記という媒体を使うしかないと決意をしたのだ。
■ 追記
次の部分を考えてみる。
- Web アクセスにおいては、携帯電話固有のID（ソフトID、ハードID など、以下モバイルID）がユーザID としてE コマースに使われている。これらはモバイルの世界固有の方法で実現されている。 モバイルITフォーラム, MC部会平成14年度活動報告書 技術専門委員会活動報告 認証WG報告書, p.42
なぜこれが「モバイルの世界固有の方法」となっているのか。
ひとつには、携帯電話の世界では、必ず携帯電話事業者のゲートウェイを経由して、かつ、携帯電話事業者のゲートウェイから直接コンテンツプロバイダへアクセスすることになるため、顧客に固有のIDを確実にふることができ、かつ、成りすましを防ぐことができる<$=fn "携帯電話事業者からコンテンツプロバイダまでのインターネット通信路上でパケット改竄が可能な場合を除く"%>ためだ。PCの世界でそれを実現しようとすると、なりすましを防ぐための何らかのプロトコルが必要となる。Intelは、1999年にPentium IIIにPSN (Processor Serial Number)を導入したが、その目的は、
Q: Why is Intel developing security features for the platform?
A: The increased use of the Internet for communications and electronic commerce is raising PC users' concerns about the confidentiality and integrity of transaction-oriented data. Since computers are the primary connections to the Internet, they are a logical place for companies to add security features. Over the next several years, Intel is adding security building blocks in order to move the industry forward in developing secure solutions for our customers.
Intel(R) Pentium(R) III Processor Processor Serial Number Questions & Answers
と説明されていた。単に、PSNをコマースサイトに対して送信するだけの方式では、実在するPSNがどこか一か所ででも漏れれば、どこからでもなりすましができるようになってしまうのだから、何らかの工夫が必要となる。
もうひとつの理由は、PCの世界では、ユーザのコンピュータに固有の番号を付けて活用しようという動きは、ことごとく批判されて、すべてお蔵入りになってきたという歴史があるためだ。しばしば、「Pentium IIIのPSNは問題とされるのに、ネットワークインターフェイスのMACアドレスはなぜ問題にされないの？」という声を耳にするが、MACアドレスをユーザ認証に使おうとしたメジャーな動きがなかったために批判されなかったにすぎない。IPv6で下位64ビットにMACアドレスをそのまま使うという話が出たときは、プライバシーの問題があるとして批判され、RFC 3041ができたという経緯がある。
ではなぜ「モバイルの世界」では批判されてこなかったか。これは、モバイルコマースが日本で先行して普及しているためではなかろうか。EZweb方式のサブスクライバーIDのHTTP上の名前である「X-UP-Subno」でGoogle検索しても、英語圏のページがあまりヒットしない。ほとんど話題になっていないのだ。日本で先行しているからこそ、「モバイルITフォーラム」というドメスティックなグループが、
これまで、この技術仕様について机上調査あるいは、各種ベンダー製品の相互接続実験に基づいた検討を行うなどの試みがあるが、モバイルコマースという一つのサービスに着目し、その適用性について検討を行った例はなく、ＰＫＩに基づくモバイルコマースの実現性について、課題とその解決法を明確にすることが、モバイルコマースをさらに発展させ、かつ、ＰＫＩ技術の利用促進に大きく寄与すると考えられる。
という先例のない検討を行うことができるわけである。そして、8月16日の日記「蚊帳の外だった日本が初めて患う大人の麻疹」で述べたように、日本ではこれまで固定IDのプライバシーの議論をする機会がなかった（住基ネットの話題を除いて）ため、技術を設計する立場の人たちが見識を持たないまま、ここまできてしまったと思われる。
PKIの話に戻すと、PKIとはそもそも人を特定するための技術であり、プライバシーとは相反するのはある意味当然である。証明書にズバリ実名と住所を書いていたらどうだろうか。ユーザは、住所と氏名を相手に提供する場合にだけ、その証明書を使うことになるだろう。証明書にメールアドレスを記載している場合はどうだろうか。ユーザは、メールを送信する場合など、相手に自分のメールアドレスを伝えて当然である場面で、その証明書を使うだろう。
Webアクセスでは、メールと違い、通常のアクセスでは自分が誰であるかを伝えないのが前提となっている。商品の送り先を指定する際に、住所氏名を送信するようにして使う。もし、携帯電話用のクライアント証明書に、住所氏名が記載されていたらどうなるだろうか。Q & Aには次のような説明が出てくるだろう。
Q. 「証明書を送信しますか？」というプロンプトが出ます。これはどのような場合に「はい」と答えてよいのでしょうか？
A. 証明書にはお客様の氏名と住所が記載されています。送信先のサイトに住所氏名を提供してもかまわない場合にだけ「はい」を押すようにしてください。
これはこれでわかりやすい話だ。消費者は、証明書の取り扱いに注意するだろう。
これに対し、モバイルITフォーラムの論文では、証明書に住所氏名を掲載しなかった理由を次のように述べている。
(1) 加入者のプライバシ保護
公開鍵証明書への個人情報を記載にはプライバシ保護の観点から注意が必要である。署名時あるいは公開鍵証明書の通知時にはユーザプロンプトにより利用者に注意を促すことが一般に行われているが、通信事業者としては携帯電話ユーザのリテラシや電話紛失等の事故を考慮し、証明書の記載事項レベルでより厳密にプライバシを考慮する必要がある。 モバイルコマースにおけるPKIの現状と課題 ―mITFモバイルコマース部会認証ＷＧの活動状況―
つまり、ユーザプロンプトで利用者に注意を促しても、ユーザのリテラシレベルが低すぎるから、なんでも「はい」を押してしまうことを懸念し、紛失時に住所がばれてしまうことも懸念したためとされている。
このことがかえって証明書の取り扱いを曖昧なものにしてしまったと言える。証明書には「証明対象の特定が困難なID」しか書かれていないので、ユーザのリテラシが低くて何でも「はい」を押してしまう状況でもかまわないというわけだ。かまわないのだから、Q & Aにも説明がされない。
ところで、これはもはや「モバイル世界固有の方法」ではないことに注意してほしい。PKIを使わない状況でのモバイルIDは、先に述べたように、
必ず携帯電話事業者のゲートウェイを経由して、かつ、携帯電話事業者のゲートウェイから直接コンテンツプロバイダへアクセスすることになるため、顧客に固有のIDを確実にふることができ、かつ、成りすましを防ぐことができる
ものであるため、「モバイル世界」ならではの方式だったが、PKIの証明書のcommon nameにユニーク番号を付けるというこの方式は、ゲートウェイやネットワーク方式とは無関係であるのだから、モバイル世界固有でもなんでもない。
PKIのWebアクセスのクライアント認証での使われ方を国際的に見渡したとき、このような各ドメイン全域に共通なIDを付与する方式は、他に類を見ないものだろう。それは、モバイルITフォーラムの案が先進的だからなのではなく、単にプライバシーの問題があるから誰もやっていないというだけだろう。「モバイル世界固有の話なので」という釈明は通用しない。国際的な赤っ恥をかく前に、早めに代替案を検討しておいた方がよい。
*1 ZDNet JAPAN, ドコモ、FOMA向けクライアント認証サービス「FirstPass」に掲載の図。
2003年08月25日
■ 住民基本台帳カードをゲット
住基ネットにはこれといって思い入れのない私なのだが、今日は早起きしたし、せっかくの初日なのだしと、がらにもなく市役所に出向いて住基カードをゲットしてきた。行ってみると支庁舎で2番乗りだった。係員が慣れない様子で発行までずいぶん時間がかかったが、その間、次の申請者は現れなかった。カードは非接触型ではなかった。がっかり。
何に使えるのかと係員に尋ねると、親切に教えてくれた。他の市町村の役所から住民票を取得できるのだという。だが、カードを機械に入れると発行してくれるわけではなく、申請書は手で書く必要がある。住基カードは本人確認のために使われるそうだ。しかも、そのとき、住基カードでなく、運転免許証でもかまわないのだとか。なんだよ、住基カードの出る幕ないじゃん。ようするに、住基カードは免許証を持たない人々のための公的身分証ということらしい。（つくば市の場合。）（今のところ。）
来年の秋には公的個人認証が始まって、自宅からインターネット経由で婚姻届とかが出せるようになるのだとか。楽しみだ。つくば市では、それまでは使い道がないようだ。気長に待つとしよう。
係員さんも初々しく、やたら丁寧に説明してくれるので、役所にしては楽しいひと時だった。窓口の向かい合う席で、係員がオペレータ用ICカードをリーダに挿す。そしてキーボードを打つ。おいおい、パスワードが丸見えだよ。その係員さんの打ったパスワードは、4桁の数字だった。とても覚えやすい番号だった。まあ、そんなもんだろう。たいしたことじゃないんだし。
そしてカードに自分の暗証番号を登録する。もう一台ある手前側のリーダにカードを挿し、フード付きのテンキーを押して4桁の暗証番号を入力。フードの高さは3センチくらい。係員さんからもよく見えたことだろう。お客さんが確認キーを押していなければ、押してくださいとアドバイスができて親切な感じだ。フードは奥側にしかないので、後ろからは丸見えだ。でも大丈夫。誰もいない。
係員さん、操作をミスったのか戸惑っている様子。端末の画面を覗き込んでみると、コマンドプロンプトの黒いウィンドウが。何やら接続中みたいなメッセージが。前にどこかで見たことがある。おお、これが噂の住基ネット端末か。
端末の裏側を見るとごく普通のパソコンだ。裏側を見るといっても、客側なので目の前にそれはある。うむむ、青色のイーサーネットケーブルが普通に挿さっているぞ。抜いたらどうなるかなあ。間に何か挟んだらどうなるかな。鞄の中のノートPCに挿すとどうなるだろうか。カードリーダもUSB接続か。抜いたらどうなるかなあ。間に何か挟んだらどうなるかなあ。キーボードコネクタも手が届きそう。USBソケットにフラッシュメモリとか差し込むとどうなるかなあ。まさか「自動再生」でプログラムが動き出したりしないよね。まあ、そんなことしても何ができるやら。やる価値があるのかどうか。
しかし、考えてみると、こういう風景って他では見かけない。銀行とか、郵便局とか、図書館とか。まあ、お金を盗られるわけじゃないし。公的個人認証が始まったわけでもないし。あ、今のうちに盗まれてたものが1年後に悪用開始されると困るなあ。気をつけよう。
今日も平凡な日記だ。
■ 追記3
係員がオペレータ用ICカードを挿入して暗証番号を打つシーンが、夜7時のNHKニュースで放映されていた。以下に、公正な慣行に合致したニュース映像の引用をする。
- 日本放送協会, 2003年8月25日「ニュース7」 19時23分ごろより3.5秒間 (MPEG 634 KB)
これはきっと実演を依頼されて、偽の暗証番号をタイプしているところなのだろう。キーボードの見通しは良好。まあ、オペレータの暗証番号くらい、どうってことない。
2003年08月28日
■ 擬似固有PICC識別子
山根さんの日記8月27日より:
おお、そういうことだったのか。住基ネットにこれといって思い入れのない私なので、自治体の自由選択なのかなあという程度の認識だった。両方のインターフェイスを持つなどという冗長な設計は思いもよらなかったが、たしかに、カードは全国で使えないといけないのだから、どちらかが必須でないといけないわけで、ISO/IEC 14443 TYPE B の方を必須としたと。住基カード表面にはチップがついてますが，これに端子を接触させなければ通信できないのでしょうか?
いいえ，住基カードは非接触式と接触式のチップを一つにまとめ，メモリを共用できるようにしており，これをカード業界ではコンビネーションカード（コンビカード）と呼んでいます．
「公的分野における連携ICカード技術仕様（公的分野におけるＩＣカードの普及に関する関係府省連絡会議申し合せ）」に基づいたものということだろうか。
地方自治情報センターの「住民基本台帳ネットワークシステム住民基本台帳カード仕様書」は公開されていない（少なくともWebでは）ようだが、ニューメディア開発協会の「近接型通信インタフェース実装規約書 第1.1版R2」の第12章には、次のように書かれている。
１２．２．９．２ 擬似固有PICC 識別子（PUPI）
（１） 基本仕様擬似固有PICC 識別子（PUPI）は、衝突防止処理時にPICC を識別するために使用される。4 バイトの数値で、一時的に発生された乱数（または固定値の一部を切り取ったもの）である。PUPI の値は、IDLE 状態の場合以外は変更することができない。
１２．２．９ リクエスト応答（ATQB）
（１） 基本仕様REQB/WUPB コマンドとスロットマーカコマンドに対する応答を、ATQBと呼ぶ。
１２．２．９．１ ATQB の形式
（１） 基本仕様PICC から送出されるATQB の形式を「図１２．２−１２ ATQB の形式」に示す。
第１バイト 第２〜第５バイト 第６〜第９バイト 第１０〜第１２バイト 第１３・第１４バイト ‘50’
（1 バイト）PUPI
（4 バイト）応用データ
（4 バイト）プロトコル情報
（3 バイト）CRC_B
（2 バイト）１２．２．７ REQB/WUPB コマンド
（１） 基本仕様REQB およびWUPB コマンドは、動作磁界内にタイプB のPICC が存在するかどうかを検出するために使用される。
ほほう。
■ ネタメモ
ZDNetニュース「RFIDのプライバシー問題、遮断タグで対応」
論文はこれ。アンチコリジョンの制御を逆手にとって、リーダが読めなくする話のようだが、まだ読んでない。プライバシーゾーンを使い分ける話、悪意ある「Blocker Tag」についての考察があるもよう。
- A. Juels, R. Rivest and M. Szydlo, The Blocker Tag: Selective Blocking of RFID Tags for Consumer Privacy
2003年08月31日
■ 住基カード裏面のサインパネル
先日ゲットしてきた住基カード、裏面を見ると、なぜだかメモ書きできるところが用意されている。何を誰が書くところなんだろう？
やはり、お年をめされた方が暗証番号を忘れないようにメモできる欄なのだろうか。
非接触ICカード普及センターの「カード調達時の選択指針」を見ると、用途はとくに決まっていないらしい。
Q：裏面印刷はどのように考えるか、サインパネルはどう考えるか
A：住基カードの裏面印刷は、特に仕様の提示がないため、独自のデザイン（何も印刷しないことも含め）が可能です。利用面から考えますと、表面の記述内容（住所、電話番号等）が変更になった場合の新しい内容をサインパネルに記述する等のことが考えられ、利用上の注意事項等を記載しておくことも考えられます。ＮＭＤＡでは、裏面の標準印刷仕様を準備し、検討していただけるように考慮しています。いずれも必須事項ではないので、自治体側の必要性に応じて対応することとなります。
とりあえず、ダミーの4桁数字を書いてみた。適当な4桁数字で暗証番号ではない。万が一カードを紛失し、悪意ある者が拾って窃用しようとしたとき、きっとこれを暗証番号だと思って打ち込むだろう。2回目ももう一回試すかもしれない。そうなれば、犯人に残されたチャンスはあと1回だけとなる。
あ、もしかして勝手に書いちゃいけないところかな。よく考えてみると運転免許証の裏もメモ欄があるのだが、勝手に書いちゃいけないっぽい感じがする。だけど、住基カードを受け取るとき、書いちゃダメといった注意は何もなかった。
■ マイクロソフトのテレビCMで
朝テレビをつけたら、マイクロソフトのWindows 2003 ServerのテレビCMが流れていたのだが、最後の一瞬の画面に、「あなたの資産を守るため、Windows Updateをしましょう」みたいなことが書かれていた*1。
たばこのCMの「あなたの健康を損なうおそれがありますので吸いすぎに注意しましょう」、薬のCMの「用法用量を守って正しくお使いください」、はたまた消費者金融の「ご利用は計画的に」みたいだ。
すばらしい。まずはよい一歩だと言えよう。だが、これでは既にわかっている人にしか意味は伝わらないだろう。そもそもうちの両親なんかには「Windows Update」という横文字を読むことすらできまい。
いっそ、Windows Updateの使い方を実演してみせるCMを流したらどうだろうか。無理な話なのだろうか。
政府広報とか、公共広告機構のTVスポットで流すというのはできないのかなあ。特定の民間事業者についてだけ流すというわけにはいかないのだろうか。Mac OS Xと同時にならどうか。
政府広報にはこんな番組もあるようだ。
- 新ニッポン探検隊！
身近でホットな情報、知って良かったと思える情報について、VTR取材又は有識者等が出演し、国民各層向けに分かりやすく解説する。
- ご存知ですか〜生活ミニ情報〜
政府施策のうち、国民生活に密着したテーマに関する情報及び告知的なものについて、有識者又は各府省の担当者等が出演し、主婦層を対象に解説する。
まあ、無理な話っぽい。政府施策にならないうちは無理っぽい。
誰か試しにスポットCM映像を作ってみるとか。Flashとかでかっこいいのを作ればけっこう出回るかも？
あと、「Windows Update」だと横文字を読めない人たちには記憶に残らない問題を解決するため、名前を日本語に変えたほうがよいのではないか。「欠陥修理」とか。無理か。
■ 追記
マイクロソフトのテレビCM、夕方の番組で偶然録画できていた。メッセージは正確にはこうだった。
あなたのPCを守るため、
“Windows Update” を
今すぐご利用ください。www.microsoft.com/japan
表示時間は3秒間だった（30秒CMのうち）。
ところで、Windows Update をする必要があることは、マニュアルに記載されているのだろうか。
3年前、Microsoft VM for Javaのセキュリティホール発覚に関わったとき、パソコンメーカー各社に、修正方法の説明なしに、欠陥があるとわかっているソフトウェアを内蔵したパソコンを販売するのはおかしいのではないかと、掛け合ったことがある。当然、無視されたわけだが、その後、ソニーのVAIOでは、箱の中に何枚か入っている注意書きの色紙のひとつに、「インターネットにはウイルスなどの危険が潜んでいるのでセキュリティ情報を収集しましょう」のようなことが書かれた紙が同梱された。他社がどうなっているかは知らない。
もっと明確に、Windows Updateが必須の作業であることを説明し、その手順を説明する紙を、パソコンメーカー各社は同梱する義務があるのではなかろうか。
現状は、「お客様が最新版をお使いになりたければ Windows Update することができます」的な説明に終わっている状況ではないか。
そもそも、パッチを同梱せずに欠陥品を販売し続けていることに、違法性はないのかと。
参照:
一般に、欠陥のある商品やサービスの提供は、それ自体として違法である。...
製造物責任法の適用がなければ一切の法的責任がないという見解もあるが、これは、完全な誤解に基づく間違った見解である。
メーカと何らかの契約関係にあるときは，契約違反が理由になる。メーカと消費者のように契約関係でない場合は，民法709条が適用できる。条文は「故意又は過失に因りて他人の権利を侵害したる者は之に因りて生じたる損害を賠償する責に任ず」。これを「不法行為責任」と呼ぶ。予見できる欠陥は，製品出荷前に修正すべきである。これを怠り，欠陥を残したソフトウェアをそのまま販売したのなら，メーカに過失があると考えられる。この場合は，不法行為責任を根拠にメーカを訴えられる注12）。ただしその欠陥が一般的に予見できないものと判断されれば，メーカに過失はないことになり，責任は問われない可能性が高い。
パッチがリリースされているのだから、「予見できる欠陥」であるのは間違いないだろう。
*1 録画し損ねた。次はどこで放送かな。