最新 追記

高木浩光@自宅の日記

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

2003年05月05日

RFID反応リンク集の件

ある方の日記で「RFIDはその一端にすぎず、直視すべきは監視技術全般とその背後にあるものだ」という反応があった。そうした考え方があるのは知っているのだが、あのネット時評では、努めてそうした考え方を排して書いた。追跡するのはあくまで迷惑業者と想定している。

なぜそうしたか。「監視社会がやってくる」といった主張では耳を傾けない人たちがいるからだ。たとえば、「ICカードで買い物をすると誰が何を買ったかの行動が監視される」と指摘したとする。それに対する事業者の反応は、「お客様を監視するつもりはありません」となる。それに対して「嘘だろ」と言っても始まらない。次に指摘するのは、「購買履歴を名簿業者に転売するのでは?」といったところか。これに対しても反応は、「お客様のプラバシーは大切に保護します」だろう。あとは、「そう言ったって漏れたりするんじゃないの?」となるが、これも「万全のセキュリティ対策をとっています」と言われるだけだ。「名寄せ」にいたっては、「誰がそんなことするの?被害妄想の甚だしい人がいるね」と言われて、「電波系サヨク市民運動家」のレッテルを貼られかねない。

これは、プライバシー問題を議論する対面した会合で私は実際に目の当たりにしてきた。この領域の権威とされている大学教授が、住民票番号による名寄せの可能性の議論で、「番号がなくたって氏名と住所で名寄せできるでしょ?今どきの情報処理技術を知らんのか?」と言っている(私に対して言ったのではなく櫻井某とかに対して)のを見た。人に番号を付けることそのものを嫌悪する人たちがいるが、これは電波系とみなす人が多いだろう。番号は既にいくらでも人に付いているのだから。住民票番号に問題がどこにあり得るかというと、それが全国民に必ず付いていることが保証されるために、様々な場面で(どうでもいい場面を含めて)番号の入力を求めるように「都市がデザイン」されていく点に尽きると私は考える。(念のため実例を挙げておく。去年のデジタルコアでのセキュリティの勉強会の席で、「インターネットで何度も繰り返し個人情報を入力させられるのは消費者として不便だからなんとかならないか」という質問があった。上の議事録には書かれていないが、私はこう答えた。「住民票番号を入れるようにすればいいですね」と。もちろん冗談なので、会場は笑いに包まれたが、無警戒な人たちの中にそういう要望は確実にあり、そういうデザインに雪崩れ込んでいく力が働いているのは確かだ。)

そのため、住民台帳法では住民票コードの民間利用が罰則付きで禁止された。この問題は正しく認識されていて解決済みだ。なのに、「番号がなくたって……」と論点のボケたことを言う専門家(とされる偉い人)がいるのだ。彼らは、「反対派」を電波系と決め付け、そこにある個々の論点を理解しようとせず、大雑把な議論に終始する。運動の動機がどうであれ、手法が電波系であれ、そこで展開されている個々の主張のうち正しいものは理解すべきだが、それをしようとしない人が日本には(と限定されるかどうか知らないが)あまりに多いというのが、私のこれまでの経験から感じている問題意識だ。

公開されている情報からそうした実例を挙げておく。 -RFIDのプライバシーの脅威は会員証と違わないという発言[slashdot.jp] -RFID研究者による、会員証やクレジットカードなどと変わりないという発言[slashdot.jp] -サブスクライバーIDを個人情報に結び付けるのはかなり困難だとする発言[slashdot.jp] -免許証番号だってあるしビデオ屋の顧客IDだってあるという発言[slashdot.jp]

この種の「問題があるとは思えない」という考えは、技術者ほど陥りがちという状況がある。非技術者は、「番号があると個人追跡される」と一般雑誌で騒がれれば、なんとなく信じてしまうかもしれないが、(素朴な)技術者は「そんなわけない」ということを考え始め、「問題あり」とする人は非技術者だからしかたないと考えるようになる。

RFIDの話に戻すと、去年、JIPDECの委員会でプライバシー問題の議論をしたときも、ユビキタス方面の専門家たちも、最初は、固有IDの問題をきちんと理解していなかった。cookieの問題やMicrosoftのSuper Cookies問題に照らし合わせて話すと理解してもらえ、プライバシー問題に対する態度が変化した。今年年頭のデジタルコアの議論でも、「気にするのは一部の人だけ」という発言があったし、トレーサビリティ研究会の席でも出てくるのは、属性情報を読まれる危険性の話ばかりで、私が言い出すまでは固有IDの問題は出てこない。そういう状況が現段階ですらある。

どうしてそういう状況なのか。「番号があると追跡される」と言えばわかっている人にはわかる。だが、それを電波系だと思っている技術者、専門家がいる。筋道を立てた説明を誰もしてこなかったからじゃないのか。主観的な要素を排除して論理だけで問題の原理を説明した文章が今まであったのか。私は、もうこれ以上同じ説明をその場その場で繰り返すのは避けたいと考え、あらためて固有IDの問題を文章にしたというのが、あのネット時評の記事だ。べつに新しいことを書いているつもりはなく、まだ問題を理解していない人への説明用のリファレンス文書として使ってもらえることを期待して書いたものだ。

「そんなのみんなわかってるさ」と言う人がいるかもしれないが、日経バイトの記事の件を見て、「暗号化で解決されたから大丈夫」と誤って安心した人がどれだけいることか。実例は日記にも見られる。私のネット時評を参照し、この「RFID反応リンク集」も参照して、ブックフェアに行ってきたという人が、「IDを識別できないように暗号化するという感じで」と早速、問題が解決されていると誤って理解している。それほどまでにこの問題の正しい理解は行き届きにくいようだ。私の力も及ばず無念だ。

「そんな細かいことはどうだっていい」と言う人がいるかもしれない。それよりも、治安のための監視技術の普及とプライバシーのバランスをどうとっていくかの議論の方が重要だと。もちろんそれは別途議論すればいいことだ。それは私のような職種の人の役割ではない。私の役割は、正しい事実を理解した上で議論することの必要性を示すこと(誤った理解が導いた危険な結果の実例を指摘すること)だ。

ちなみに中央公論はまだ読んでない。週明けにでも探して読むつもりだ。

日記を書くことにする

WWWを知った9年前、個人的なことは書くまいと思ったのを覚えている。Web日記が流行し始めたときも、「自分は書かないぞ」と決意したものだ。言いたいことはメーリングリストに書くことで満足していたし、他の人が意見を述べればそれが同じ場で皆に見えるという、メーリングリストの性質が自分には合っていた。Web日記はそうではない。小さなコメント機能はあっても議論の場とはならないし、誰かの反感を買ってどこか知らないところであれこれ言われるのは不安だ。それに、「これは個人的な日記だから」と暗に反論を牽制する結果をもたらす仕組みになっているのも、自分には合わないと思っていたし、そうした牽制を必要とする話題を書く動機がなかった。

だが、状況は変わってきた。tDiaryなどのRefererを自動集計してくれる便利な日記システムや、検索能力の高いGoogleの登場で、特定の話題に関心を持った少数の人たちのコミュニティが形成されるようになってきた。メーリングリストは基本的に参加者の皆が求めていそうな話題しか書けない(書きにくい)システムなので、関心ある者が臨機応変に集まる必要のある話題には向かない。

もうひとつの状況変化は、自分の関心が移り変わってきたことだ。以前は純粋な技術論だけで満足だったのでメーリングリストでよかった。ここ3年は、セキュリティ脆弱性の話題を扱うようになって、公の場では書けない情報を握るようになり、書けない鬱憤が溜まるようになった。しかし、書いてはならないことは、「個人的な」Web日記であろうとも、いずれにせよ書くわけにはいかない。ところがここ9か月ほどはプライバシーの話題にも首を突っ込むようになってきた。セキュリティ脆弱性の話は論理だけで事がすむ。証拠を示して問題点を指摘すれば私の役割は完結する。ところが、プライバシーの話はそうはいかない。正直、そういう性質の話題には首を突っ込みたくなかったし、自分の役割でもないと思っていたのだが、結局首を突っ込んでしまった。

「今日からWeb日記を書くぞ」と決意したことはこれまでにも何度かあったが、いろいろ迷いがあって、その都度断念している。今回もいつまで続けるかわからない。すぐにやめてしまうかもしれない。

本日のリンク元 TrackBacks(4)

2003年05月06日

はてなダイアリーのリンク元表示

リンク元が自分の編集画面にしか表示されないなあ。「設定」の「日記のリンク元を公開しない」のチェックははずしてあるのだが。ヘルプには「日記編集画面、およびコメント編集画面には、リンク元とその回数が表示されます。」とあるので、そういうもの(編集画面だけで見える)なのだろうか。じゃあ、「公開しない」の設定は何なんだ? あ、もしかして、コメント機能をオンにしないと出ないのか?

[追記] とりあえずコメントありにしてみた。「コメントを書く」をクリックしないとリンク元リストを見れないのかなあ。そうだとするとちょっといまいちだ。日記開設にあたって、リンク元機能を重視してtdiary.netに陣取りたかったのだが、とっくに募集が終了していて打ちひしがれたのだった。

本日のリンク元 TrackBack(0)

2003年05月07日

Suicaの説明責任

固定IDの話はまた後日ゆっくりまとめるとして、今日は別の話題としてSuicaのことを少し。

JR東日本の「Suicaイオカード」は、カード内に入退場の履歴を記録している。このことは、ソニーが「PaSoRi」を使った「SFCard Viewer」をリリースするまで確証を持てなかった。実現方式の可能性として、カードにはIDだけが入っていて、すべてをオンライントランザクションで処理する方式もあり得たからだ。駅のSuica対応自動券売機には履歴表示・印字機能もあるのだが、これもオンラインかもしれないと考えられた。だが、SFCard Viewerにより、オフライン状態のパソコンで残高や入退場履歴を閲覧できることから、カード内に記録されていることが確実となった。

そして今年2月、「CLIE PEG-NZ90」という携帯端末が発売された。これはFeliCaリーダを備えており、SFCard Viewerがプリインストールされている。当初、CLIE版SFCard Viewerは、残高しか表示できなかったのだが、3月31日にリリースされたv.1.11にアップデートすることで、入退場履歴(日付、入場駅、退場駅)のリストを表示できるようになった。(最初からそうしなかったのは、おそらく、駅番号から駅名文字列への対応表を、圧縮データから検索するプログラムを準備するのに、時間がかかったためではないかと憶測している。)

このことを知っている人は、CLIEを使えば、満員電車で隣り合わせた人のSuicaの入退場履歴を盗み見れるのではないかということを、一度は想像するだろう。試しに財布に入れたままCLIEにかざしてみたところ、分厚い財布だとなかなか読み取れないが、薄めの財布なら、ジーパンの後ろポケットに財布ごと入れた状態で、お尻にCLIEをかざせば、履歴情報を読める場合もあった。カードからCLIEまで1センチメートル以内の距離で読めるようだ。

人づてに聞いた話では、女性向けの小さなバッグにSuica対応のものがあるとかで、バッグの底にSuicaを入れるポケットがあり、利用者はバッグごと改札機にタッチアンドゴーするのだという。(私は、たまにしか電車に乗らないので見たことがない。その鞄の情報はWebにはないものだろうか。) これだと、満員電車で背後に立つ人に、電車の利用履歴を盗み知られてしまう状況は、比較的現実的にあり得ることではなかろうか。

こういうことを書くとまた、何も新しくないとか言われそうだが、CLIEに接する機会のないごく普通の人たちのほとんどは、この事実を知らないのではなかろうか。JR東日本のSuicaのページには、カード内に履歴が記録されている事実が説明されていない。「Suica Q & A」のページには、

現行のイオカードでは、カード裏面に履歴(ご利用明細)が印字されていますが、Suicaではどうなるのですか?

という問いはあるものの、その回答は、

Suicaでは、Suica対応の機器(券売機等)で残額の確認やご利用履歴(明細)の確認およびその内容の印字が可能となります。

とあるだけで、駅の券売機以外でも読めることが普通の人にわかるとは思えない。

仮に、CLIEをお尻や鞄底にあてがってデータを読むのが困難だとしても、他に考えられるのは、Suicaイオカードを机の上に放置したり、クローゼットに入れっぱなしにしているときに、同僚や配偶者にCLIEを使って履歴を読み取られる可能性がある。それを、カード所有者が予期できているかどうかだ。

旧イオカードのように、ローテクなカードでは、カード面に利用駅名が印字されていたので、人は、それを普段から目視する経験により、カードが他人の手に渡ったるとどんな事態を招くか、直感的に理解していた。これが、Suicaのようにハイテクなカードとなると、人は、起こり得る事態を容易には予見できなくなる。

もう1つの問題点。カードに他に何が記録されているのかが公開されていない。CLIEのSFCard Viewerでは、利用日の月と日しか表示されないが、時刻はどうなのか。記録されていないのか、記録されているがSFCard Viewerが表示しないだけなのかが判別できない。人づてに聞いたところによると、自動開札非対応の駅でSuicaを駅員に処理してもらった際に、「何時何分に乗りましたね?」と言われたというから、時刻は記録されている可能性が高い。

CLIE付属のSFCard Viewerで表示できないとしても、ソフトウェアを自力で作れば、時刻も読めてしまう可能性がある。Suicaのベースとなっているカード技術「FeliCa」は、カード読み書きソフトウェアの開発キット「SDK for FeliCa」を一般向けに販売している。私も購入を試みたのだが、秘密保持契約書にサインが必要とのことで、契約条項には、何を秘密とするかが後から決められると書いてあったので、買うのを断念した。(すでに契約していて開発のできる方に、こちらから指定した機能のプログラムを作ってもらうことは可能だろう。)

もうひとつわからないのは、Suicaから履歴情報を読み出す際に、暗号鍵が必要になっているのか、それとも鍵なしに誰でも読めるようになっているのかだ(データの書き換えにはもちろん暗号鍵が必要)。読み出しに鍵がいらないのなら、開発キットさえあればSuica対応アプリケーションを作れるだろう。鍵を必要としているならば、CLIEかPaSoRi用のSFCard Viewerがクラックされない限り安全ということになる。

いずれにせよ、JR東日本は少なくとも次の2つの点の説明責任を果たしていない。

  • Suicaイオカードは、カード内に残金や入退場履歴などを記録していて、市販の携帯端末で1センチメートル程度の距離からそれを読み出せるという事実の、Suica利用者への告知
  • Suicaイオカードに記録されていて読み出し可能な情報は何か(時刻やその他の情報は含まれるのか)の情報公開

こうした懸念が「何も新しくない」、「誰でも考えてるよ」というのなら、どうしてジャーナリストは実験なりをして、消費者に伝えることをしないのか。そういう記事ってこれまでにあっただろうか。こんなのは私のような職種の人の役割ではないのだが。

<<コメント機能について>>

コメント機能はオフで始めた日記ですが、リンク元表示のためやむを得ずオンにしました。頂いたコメントにはお返事しない場合がありますので、ご承知おきください。ここのコメント機能では議論するつもりがないためです。他の方法を検討してください。簡単な連絡事項はお書きいただいてけっこうです。議論を必要とするような長いコメント(基準は……、2行を超えるものを目安としましょうか)は削除させていただくかもしれません。

本日のリンク元 TrackBack(0)

2003年05月11日

「お客さまに安心してご利用いただく」とは

「SSL ご安心ください 鍵マーク」などでGoogle検索すると、


 フレームを使用しているため表示URLにsが表示されなかったり、右下に鍵マークや「セキュリティ」の鍵が表示されない場合がございますが、SSLを利用しておりますので、ご安心ください。

といった説明が大量に見つかる。これはどういうことか。HTMLのFRAMESETを使って作られたWebサイト(縦横に分割された複数の「サブフレーム」から構成される)はよくあるが、そのサブフレーム中のリンクをたどって、個人情報を送信する画面にたどり着いたとする。個人情報入力のHTMLがきちんと「https://」のURLとなるよう作られていても、メインのフレーム(外枠)のURLが「http://」のままだと、ブラウザの右下の錠前アイコンが施錠されてない表示となる。このことについて述べられたものだ。ブラウザは「暗号がかかっていない」と表示しているが、実際にはSSLを使って送信されるので「ご安心ください」というわけだ。

これは本当に安心してよいのか。安心してはいけない。それはなぜか。SSLを使う(https:// のページを使う)目的は何かというと、盗聴の防止と、改竄の防止と、なりすましの防止だ。盗聴防止のことはよく知られているが、改竄防止はあまり知られていないらしい。改竄といっても、サーバに侵入してコンテンツを書き換えるいわゆる「ウェブサイト改竄」のことではなく、サーバとブラウザ間の通信路上でのパケットの改竄のことだ。外枠のURLが「http://」ならば、それは通信路上で改竄されている可能性がある。外枠のHTML中には、サブフレームへリンクする記述として「https://」というURLがどこかに書かれているはずだが、これが通信路上で、「https」の5バイトが「 http」(スペース+「http」)に差し替えられたらどうなるか。個人情報を入力するHTMLに到達したときに、本来SSLが使用されるはずのところが、使用されない状態にすり替えられることになる。そのまま個人情報を入力して送信すれば、パケット盗聴されてその情報は盗まれる。

こうした事態は簡単に防止できる。サイト側で、外枠のURLが「https://」となるように、Webアプリケーションを修正すればいい。これは簡単に直せるセキュリティホールなのだ。にもかかわらず、直すことをせずに、「ご安心ください」という説明によって、消費者をただただ安心させようとしている。

先日、これに似た話を聞いた。Mozilla dot Party in Japan 4.0の後の宴会の席で、米Netscape/AOLの桃井さんとお話をした。桃井さんとは、Netscapeがまだ「Mosaic Netscape」と名乗っていたころからの旧知の仲なのだが、それはともかく、彼は最近、Netscape 7を公式ブラウザとして認めてもらうよう、日本の金融機関に働きかけてまわったそうだ。何かの問題点が障害になっているならば指摘してもらおうと、話を聞きに行ったそうだ。そのとき、ある銀行はこう注文したという*1


 暗号化ページ中に暗号化されないコンテンツが混在していると、Netscape 7は、「セキュリティに関する警告」の画面を出す。これがお客さまを大変心配させるので、出ないようにして欲しい。(高木による要約)

その警告画面のメッセージはこういう内容だ。

暗号化されていない情報を含む暗号化ページを要求しました。このページに表示される情報またはこのページで入力した情報は、第三者によって簡単に読み取られる可能性があります。

桃井さんは、ブラウザを供給する側の立場として、安全でないものを安全であるかのように振舞う変更は断固できないと踏ん張ったそうだ。私はその話を聞いて、あらためて銀行のアホっぷりにあきれ返った。

ようするに、銀行としては、実際に安全であるかどうかはどうでもよく、お客さまが安全と思ってくれさえすればよいということになる。これは、「ご安心ください」という説明でやみくもに消費者を安心させようとする、冒頭の検索結果に出てくる事業者達と同じ発想によるものだろう。技術者達は、そうした考えが誤りであることに気付いているはずだ。しかし、お客さま対応の責任者は、技術者の言い分なんぞ聞くまでもないことだと決めてかかっているのかもしれない。

こうした状況は今後も続くだろうと思う。上の話は、簡単な技術的解決策があるからまだよい。Webアプリケーションのセキュリティホールを修正すればよい。しかし、すでに普及していて、今からでは解決はできないものについてはどうだろうか。「説明しても、お客さまは正しく理解できないのだから、無用な心配をかけないほうがいい」と、そう考える事業者は多いだろう。

情報自由論(7)を読んだ

中央公論1月号を入手。東浩紀さんの情報自由論の第7回「自由と交換される匿名性」を読んだ。感想は後日。

*1 この話は、「ネタに使っていいですか?」とその場で確認して許可を得たものだ。どこの銀行なのかはあえて聞かなかったので知らない。

本日のリンク元 TrackBack(0)

2003年05月12日

事前登録のパソコンでしか取引できないという対策

サンスポの3月の記事「ネットバンキングに不正アクセス 1600万円盗む」によると、

ネットカフェや漫画喫茶に個人情報を収集するソフトを勝手に仕掛け、パスワードなどを不正に取得し、他人の口座から約1650万円を送金させ約1600万円を引き出した会社員ら2人が6日、警視庁に逮捕された。 ... 容疑者は、都内や神奈川県内のネットカフェや漫画喫茶など十数カ所のパソコンに“秘密兵器”を仕掛けていた。「キーロガー」。パソコンのキー操作をすべて記録するソフトで、打ち込まれたパスワードやメールの内容などを知ることできる。

という事件があったそうだ。

ネットカフェで銀行取引をするなどという、被害者の無用心さの問題もあるわけだが、大手の銀行は、こうした盗聴行為が行われてもある程度の安全性が得られるよう、乱数表によるチャレンジレスポンス方式を採用している。たとえば三井住友銀行の場合では、縦横4列の計16個の枠にランダムな2桁の10進数の書かれた「暗証カード」が契約者の手元に送付されてくる。ネットバンキングで重要な操作をする際、サイト側からランダムに2か所の枠を指定されるので、そこに書かれた計4桁の数字を送信して、本人確認とする。

こうした方式がとられている銀行をネットカフェで利用し、キーロガーによってタイプした文字を盗聴されたとしよう。しかし、犯人は、不正ログインできても、サーバが偶然に同じ2つの枠を指定してこない限り、送金を実行できないことになる。むろん、正規利用者がネットカフェで何度も繰り返し取引を実行すると、16か所の枠がビンゴカードのように次々と盗まれていくことになるので、安全性は徐々に低下していく。このあたりの確率計算の試みが文献*1にある。

さて、冒頭のサンスポの記事には続いてこう書かれている。


 ネット専業のソニー銀行はサービスに応じて別のパスワードを設定、顧客が送金サービスを使う際には、3種類の「合言葉」を答えないと利用できない仕組み。さらに事前登録のパソコンでしか取引できないという対策も講じている。

これはどういうことなのか。

「事前登録のパソコンでしか取引できない」といっても、IPアドレスを書面で申請しておくわけではない。「事前登録」はいつでもオンラインで可能なのだ。ネットカフェのパソコンを「事前登録」することもできる。どういうことなのか、ソニー銀行をネットカフェで使う場合を例にとって手順を説明しよう。

まず、口座番号とパスワードを入力する。すると、「事前登録のパソコン」ではないため、2つ目の暗証番号の入力を要求される。これを正しく入力してパスすると、今度は、3つの合言葉の質問に文字列で答えることになる。質問と回答は、よくあるパスワードリマインダのような形式で、「お気に入りの○○は?」といった感じだ。3つとも正しく入力すると、IDの記載されたcookieが発行され、それ以降は、同じパソコンからならば(正確には、同じブラウザからならば)、最初のパスワードだけでログインできるというわけだ。

さて、これをネットカフェで実行したとき、キーロガーが仕掛けられているとどうなるか。当然ながら、最初のパスワードと、次の暗証番号と、3つの合言葉は、全部そろって盗まれる。つまり、ネットカフェでキーロガーを仕掛けられて銀行口座を乗っ取られたという事件報道の文脈において、

3種類の「合言葉」を答えないと利用できない仕組み。さらに事前登録のパソコンでしか取引できないという対策も講じている。

というのは、何ら効果のある対策ではない。

こうした、安全でないのに安全であるかのように消費者を誤解させる説明は、うんざりするほどよく見かける。よそと違った仕組みを導入していると、「こんな対策をしています」と言いたくなる気持ちはわかるが、あまりに不用意だ。気付かずに言っているならどうしようもない担当者だし、知りながら言っているなら悪質だ。ただ、この記事では、記者が背景を説明せずに広報担当者から対策状況を聞きだした可能性もあるので、どちらに責任があるのかは不明だ。記者にしても、このくらいのことは自分で気付けないものだろうか。

プレビュー機能が欲しい

はてなダイアリーにプレビュー機能がないのはイタい。書きかけの文章を見られてしまうじゃないか。

*1 松本勉, 岩下直行, インターネットを利用した金融サービスの安全性について, 金融研究第21巻別冊第1号, 2002年.

本日のリンク元 TrackBack(0)

2003年05月14日

Suica券売機の履歴印字を試してみた

今日は電車で出かけたので、JR駅のSuica対応券売機の履歴印字機能を試してきた。5月7日の日記に書いたように、CLIEなどで「SFCard Viewer」を使うとSuicaの入退場履歴を閲覧できることから、カード内に履歴が記録されていることは確かだ。SFCard Viewerでは、直近最大20件までの履歴が表示されるのだが、駅の券売機は、50件まで印字されるものだった。この違いはなんなのか。

カードにはじつは50件まで記録されていて、SFCard Viewerが20件までしか表示しないだけなのか、それとも、駅の券売機では、カードのIDを元にオンラインで検索されて、50件まで引き出せるようになっているのか。それが不明だ。

印字機能を試したのは、時刻が印字されるかどうかを確かめたかったからだ。やってみると、日付だけで時刻は印字されない。そこで、せっかくなので、駅員さんに尋ねてみた。親切な駅員さんで、私の「このカードには日付だけでなく時刻も記録されているのでしょうか」という不審な質問に怪訝な顔をすることもなく試してくださった。

駅員が操作する装置で表示させると、現時点の入場時刻(入場中に尋ねたのだ)と、直前1回分の入場と退場時の時刻が表示されたそうだ。それより前の履歴の時刻は表示されなかったという。ただ、これがそれより前の時刻まで記録されていないことの保証にはならない。また、これがカードに記録されている情報だったかも確かではない。この装置がオンラインで検索した可能性も残る。

仕事から帰ってきてから、もう一度同じ駅で履歴印字を試してみた。今度は、古いタイプの券売機の方を使ってみた。すると、「問い合わせ中」という画面が2秒間ほど表示された。オンラインで検索しているのだろうか。

田舎のお婆さんがコンビニ店員をするというミスマッチ

昼飯にと、某コンビニでおにぎりとから揚げを買った。店員さんは50代後半とおぼしきお婆さん。おにぎりを温めてと言ったのに、おにぎりをレンジに入れずに、から揚げを取り出しに行っている。「先におにぎりをレンジに入れてからから揚げの処理を開始せんかいゴルア」と、おもわずクリティカルパスが頭に浮かんでしまうが、まあ田舎の不慣れな婆さんだなと黙って見ていた。

すると、婆さんが、「から揚げは30円引きです」と言って、小さなチケットをくれた。とっさにそれがどういうことかわからなかった。「次回割引ってこと?」「くじでも引くの?」と疑問を浮かべていると、婆さんが説明を始めた。「今、○○茶を買うと、から揚げが30円引きになるんです。でもお茶を買うお客さんはみなさん、から揚げはいらないというので……。」

つまり、他の客がいらないと言った割引券を、レジ横の箱に溜め込んで、他の客に使わせているわけだ。「ええ? そんなことしちゃだめでしょ。だって、これは、から揚げを買う気のない客にから揚げを買わせるキャンペーンとしてやっているんでしょ?」とおもわず注意してしまった。

店を去りながら、なぜか30年前通学路にあった駄菓子屋の婆さんが頭に浮かんできた。駄菓子屋の婆さんならどうしただろうかと考えてみる。客に同化して割引券を融通するか、それとも、複雑なルールの割引システムを客に適用するか……。まあ、駄菓子屋の婆さんといえどプロの商売人なんだから、後者でしょうな。変なゲームとかいっぱいあったしなあ。でも、たまにはズルさせてくれてたような。

本日のリンク元 TrackBack(0)

2003年05月20日

IPA Spring 2003を見に行ってきた

今日はビッグサイトに行ってきた。ビジネスショウを見物に……ではなく、同時開催のIPA Spring 2003で、昨年度の公募開発事業の成果報告発表会があったからだ。ソフテックが展示している「Webサイトのアクセス制御機構に対する脆弱性検出・検証システム」は、私も協働開発に携わった(関連: RSA Conference 2003 Japan, Webアプリにおけるセッション追跡の欠陥とその自動検出法)ので、その発表を見届け、観客の反応を探りに行ってきた。

他の展示では、東芝の「匿名属性証明認証システム」が興味をひいた。グループ署名を初めて実用化を目指して実装したとのこと。プライバシーと利便性の両立がこのように研究として進められているわけだが、問題は事業者がその採用の必要性を感じていないことではないか?という持論を持ちかけて出展者と熱く議論した。他には、沖電気の「印刷文書の改ざん検証ソフトウェア」はすぐにでも実用になりそうに思えた。運用上の点で何か障害があり得るのか質問した。とくになさそうに思えるが、どうか。

もうひとつの目的は、坂村健教授の基調講演と村井純教授の特別講演を聴講に行って質問をブチかますことだったのだが、出発が遅れて坂村先生の講演には間に合わず残念。村井先生のご講演には、固定IPアドレスがもたらすプライバシー問題にどのように取り組まれているかを質問した。モバイルIPのタクシー会社での実験の事例に関して、IPアドレスをスクランブルする取り組みをしていて、論文も発表されているとのこと。これのことかな。

  • Akira Kato, Jun Murai and Satoshi Katsuno, An Internet Traffic Data Repository: The Architecture and the Design Policy, INET'99, June 1999.
  • Kenjiro Cho, Koushirou Mitsuya and Akira Kato, Traffic Data Repository at the WIDE Project, 2000 USENIX Annual Technical Conference, June 2000.

講演終了後ご挨拶にうかがった。実はこれまで村井先生とお話しする機会がなかなかなかったのだ。2001年8月末のIAJapan設立記念パーティの席でセキュリティ脆弱性についてちょっとお話ししたのを思い出す。そのときは、クロスサイトスクリプティング脆弱性蔓延の実態を広く訴えかける前の時点で、「先生、こういうマズい実態があるのですよ。なんとかなりませんかね」と話したのを覚えている。後で私からメールで説明する約束をしたのだが、サボっているうちに、数週間後にはNimdaウイルス大流行事件が起き、世のセキュリティ意識は一変。連絡を頓挫してしまった。今年、奈良先端大に所用で行ったときに、村井先生もいらしたのだが、お忙しいようでじっくり話す間がなかった。

今回お話ししたかったのは、プライバシー問題の勘所のコラムで、オートIDセンターのQ & Aのマズい点と、総務省の委員会の議事録の先生の発言を一方的にネタにしたことに、若干の負い目を感じていたからだ。先生もお読みいただいていたとのことで、ご見解をうかがった。基本的には「おっしゃるとおりで重要なこと」とのこと。議事録にある発言については、真意は、皆で決めて合意を形成していくことが重要という意味だと説明を受けた。そうだろうとは思う。だが、私の言いたかったことは、技術者側から何が起こり得るかを説明していかないと、不十分な情報の中で判断されてしまうおそれがあるということであり、そのことをお話しした。 その他、RFIDについて、日経BPなどで異様な盛り上がりを見せていることについて、まだまだこれからで、決まってないことばかりで、プライバシーもどう解決するか手探りなのに……と、困惑された様子だった。

王様タイプ?

この心理テストを試したら「王様」「軍人」「学者」「職人」のうち、王様タイプと診断された。なわけねー。飲み会盛り上げねーよ。というか、学者タイプの特性が著しく現実と異なるようなのだが。学者って、約束は守らないし、無駄ばかりだし、感情的だし。岡田斗司夫氏がこんなこともやっていたのか。理系のための恋愛論 第100回からたどって知った。「理系のための恋愛論」は、以前からしばしばリンクをたどって到達していたが、苦痛なので読破することはほぼなかったが、今回は面白いじゃないか。ただし内容に賛同するわけじゃないので念のため。これを読んで何を思ったかは秘密だ。

本日のリンク元 TrackBack(0)

2003年05月21日

VIEW Suicaカード誕生

帰宅してこれを見つけた。

VIEW Suicaカード誕生……は結構なのだが、申し込み画面のドメインが「view-order.jp」と、見慣れないところだ。知らないドメインはニセの可能性があるので、https:// でアクセスしてサーバ証明書の内容を確認するのが消費者がとるべき行動の鉄則だ。

ところがそれをやってみると、証明書の発行対象(サブジェクト)が、「Kyodo Printing Co..Ltd.」となっている。JR東日本じゃないのだ。JR東日本と契約しようとしているのだし、画面には「東日本旅客鉄道株式会社」などと書かれているのにだ。Kyodo Printingというのは聞いたことがない。ニセなのか。Googleで「Kyodo Printing」を検索してみると、www.kyodoprinting.co.jp というサイトが見つかり、共同印刷株式会社のことらしいことがわかる。どうして共同印刷なのか。会社案内の事業案内の「ICカード」のところを見てみると、どうやらVIEW Suicaカードの製造会社なのかなと想像できる。あくまでも想像にすぎないのだが、きっとJR東日本に委託されて契約処理システムを運営しているのだろうと考えて、ようやく信用して申し込むことが可能になる。

もしこのことをJR東日本に問い合わせるとどんな返事が返ってくるだろうか。「www.jreast.co.jp のページからリンクをたどれば本物の画面にたどり着きますのでご安心ください」と言われるのかもしれない。だが、それは、5月11日の日記に書いたように、正しくない。http:// の画面は通信路上で改ざんされている可能性があるので、信用してはいけない。ジャンプ先がJR東日本が意図したのと違うところにすり替えられている可能性がある。ならば、閲覧者が自力でまずhttps://www.jreast.co.jp/... にアクセスして、そこからジャンプすればよいかというと、それもだめ。ジャンプ先が http:// なので、ジャンプした直後にニセサイトにリダイレクトされる危険性がある。ではどうすればよいのか。

  1. https://www.jreast.co.jp/... にアクセスして、「こちらからお申し込みください」のリンクのジャンプ先をステータスバーで確認し、「http://view-order.jp/...」であることを記憶する。
  2. 「http」を「https」に書き換えて https://view-order.jp/... にアクセスする。

という手順を踏めばよい。こんなことを消費者にやれというのは無理がある。素直に、JR東日本のサーバ証明書で運用すればこんなことにはならないのだが。どうしてもそれができないのなら、JR東日本のVIEW Suica紹介ページ内で、共同印刷に委託していることを説明すればよい。そうすれば、消費者の安全確認手順は次のように簡略化される。

  1. https://www.jreast.co.jp/... にアクセスして、共同印刷(Kyodo Printing Co..Ltd.)に委託しているという説明を読む。
  2. 普通にリンクをたどって申し込みページに進み、個人情報を入力する画面でサーバ証明書を確認し、「Kyodo Printing Co..Ltd.」と書かれていることを確認する。

これはミスではなく承知の上で行われていることだろうし、誰でも事実とわかることなので隠すことではないし、消費者が警戒しないといけないことなので、日記に書くことをとくに躊躇わない。

非接触ICカード普及センター

共同印刷のページからたどって、非接触ICカード普及センターという組織が立ち上がっていたことを知った。住民基本台帳カードは非接触型が主流になるのだろうか。自治体は住民に次のことをきちんと説明できるのだろうか。

  • 何センチ以上離せば意図せず読み取られることがないのか
  • 市販のカードリーダで暗証番号なしに他人が読み出せる情報は何か

EdyでMy Sony IDにログイン

My Sonyで、EdyカードをPaSoRiにかざすだけでログインできるサービスが始まっている。「やはり来たか」というのが私の思いであった。VAIOノートの次のモデルあたりでFeliCaリーダライタが内蔵されるのだろう。楽しみだ。リーダライタはどのあたりに埋め込まれるのだろう。パームレストの下? キーボードの下? はたまた、液晶パネルの裏側か?

ブラウザからカードを読み書きするため、ActiveXコントロールが使われている。とりあえず、[memo:3784] と同じ不都合がある。ActiveXコントロールのこの、「インストールして実行しますか?」というセキュリティ警告のウィンドウは、ユーザにこのソフトウェアを信頼するかを尋ねているものだ。だから、これがどんなソフトウェアであるかを説明するために、この冒頭の部分には、コントロールの名称を表示してその機能を説明するサイトへのリンクを設ける機能が用意されている。信頼とは説明なしに得られるものではない。信頼など得られなくとも動作しさえすればいいのか。それとも単に、signcodeコマンドの基本的な使い方が知られていないのか。

新しくない話題だし、セキュリティホールではないので、日記に書くことをとくに躊躇わない。

画面キャプチャ

より安全にご利用いただくため

5月12日の日記の補足。ソニー銀行のパスワードや合言葉の説明が「セキュリティに関するご注意」にあった。

より安全にご利用いただくためのお願い

  • 特に、不特定多数のかたがご利用になるパソコンを利用してログインを行った場合には、パスワード等が盗まれる可能性が高くなりますので、速やかにご自宅などのパソコンからパスワード等を変更することをおすすめします。

とある。パスワード変更をその場でやっては変更の意味がないのだから、「自宅のパソコンから」というところがミソだ。つまり、急いで帰宅しないといけない。もしネット送信型キーロガーを仕掛けられていたなら、電気的速度で帰らないといけない。

一般に、「より安全にご利用いただくため」という表現は、文法的には暗に「今も十分に安全だが」ということを意味するはずだが、こういう表現が使われるときというのは、安全じゃないことを認識している場合に限られるはずであるから、この表現を見ただけで直感的に悪寒がはしるのだが、私だけだろうか。

乱数表のない銀行は、ネットカフェでの利用を禁止した方がよいのではなかろうか。ちなみに、イーバンク銀行の「安心してご利用いただくために」には次のように書かれている。


 「なりすまし」や「キーロガー」といった不正行為による被害を回避するために、図書館や学校、インターネットカフェ等、一般に公開されているパソコンや共有のパソコンからのログインはできるだけ避け、ご自分のパソコン、携帯電話よりご利用ください。

本日のリンク元 TrackBack(0)

2003年05月25日

IPv6の匿名アドレスはどう運用されるのか

IPv6アプリコンテスト2003アイデア部門入賞作品が発表されていた。正直、IPv6の必然性を感じない作品も少なくないのだが……まあ私もかつて「Java大賞」なるコンテストに参画していたわけで、「なぜJavaでないといけないのか」というところを突かれたら私も同罪だ。

先月の日経IT Proの「記者の目」に「IPv6は普及するのか?――第1部:事例に見るv6のメリット」という記事があったのを思い出す。この中で、IPv6採用のメリットとして挙げられた4点は、「(1)セキュリティ、(2)マルチキャスト、(3)個体の把握、(4)プッシュ型配信」なのだが、このうち、「個体の把握」については考えさせされたところがある。ここで紹介されているのは、CDショップの各店舗に設置された音楽試聴機の各個体を、サーバで識別するためにIPアドレスをそのまま使うという話のようだ。そうした個体の識別は、アプリケーション屋の発想からすれば、アプリケーションレベルで実現するのが普通に思える。その点について記事では、

もちろん,こうしたことはアプリケーションを工夫することによってIPv4であっても実現できないわけではない。しかし,IPv6を用いれば,シンプルに実現できる可能性がある。

と結んでいる。

シンプルかどうかは疑問だ。IPアドレスレベルで識別しさえすればアプリケーションレベルでの新たな識別子が完全に不要となるアプリケーションでは、たまたま偶然にシンプルとなるものの、ものによっては、IPアドレスで識別した上に、アプリケーションレベルでも別の識別子が必要という、二度手間になる場合もあるはずだ。

とはいえ、これをシンプルだとしたい気持ちはわからないでもない。これは、Javaで言えば、java.util.Observableクラス(など)の考え方にたとえられるかもしれない。これは、オブジェクト指向プログラミングにおける「Observerパターン」を実現するクラスで、イベントを通知してほしいときに、イベントの通知先の識別子として、オブジェクトへの参照そのものを直接的に使う(アプリケーションレベルの識別子ではなく)という設計思想だ。オブジェクトへの参照は、実体としてはオブジェクト用に割り当てられたメモリアドレス(のようなもの)となっていて、一意性が保証されている。その一意性をアプリケーションレベルで借用していると見ることもできる。これは、下層の仕掛けを上層で活用するという点で、上のIPv6アドレスの個体把握への利用の話に共通する。

しかし、そうしたやり方は、システムのプリミティブな部分ではそのまま活用できるものの、より大局的な部分で、別の識別子を導入せざるを得なくなるということは、アプリケーションプログラマなら経験していることだろう。上層で発生した識別子を下層の仕掛けで共通して扱えるように仮想化するということも可能なのだが、それはフレームワーク開発者としては面白いけれども、本当に実用的なのか疑問に思ったことがある。Java RMIとJINIはその最たる例だ。分散システムのあらゆる部品を、個体識別をJava RMIの「リモート参照」で、機能種別をJava言語の型(interface)で、統一的に扱おうという考え方だ。上層の概念を下層の機構で解決しようとしている。これがいまだいまいち成功しておらず、時代はSOAPに流れたというのがなぜなのかを考えてみた方がよい。

元の話題に戻ると、IPv6アプリコンテストの入賞作品を見ると、IPv6の意義を捻出するために個体識別を取り上げた作品が目に付く。「Parking Control System with MIPv6」では、

自動車が駐車場に入った時点で、このシステムと何らかの無線技術でIPv6通信を行う。このシステムは、グローバルIPv6アドレスを基に自動車を識別、どの場所に駐車すべきかを知らせる。

とある。自動車の識別はアプリケーションレベルの識別子によってでも可能なはずだ。この自動車は、駐車場の入場ゲートで、何らかの方法で、このパーキング制御システムに自分自身の存在を伝え、登録処理をするわけで、このときに、駐車場がセッションIDを発行して、自動車がセッションIDを保持し、セッションIDを渡しながら案内を受けるという方法でも実現可能だ。

これには次のような反論があるかもしれない。この作品は、自動車側に駐車場システム専用のソフトウェアを搭載させるのではなしに、単に任意のメッセージを表示する汎用ソフトウェアを持っているだけで、駐車場側からのプッシュ型配信により情報が通知されるのだと。その場合は、メッセージ送信の通信先として、IPアドレスで自動車を特定する必要があるので、そのアドレスをそのまま識別子とすればよく、セッションIDは不要だということになる。

しかし、そうしたプッシュ型配信のサービスは実運用に耐えられるのだろうか。たとえば、「未承諾広告」をどうやって防ぐのか。オプトアウト方式で合意が得られるなら、送信元IPアドレスごとに拒否設定をするのだろうか。オプトイン方式とするのなら、最初にユーザ登録をするのであるから、アプリケーションレベルで個体識別に対応すればよいし、プッシュ型配信を使う必要がないように思われる。

これは「どちらでもできる」という話なのか。つまり、IPアドレス識別 + プッシュ型と、アプリケーションレベル識別子 + ポーリングという2種類の方式があり、どちらでもいいのだと。現在では一部を除きほとんどのアプリケーションが後者の方式となっている。IPv6推進陣営からすれば、その原因が、IPv4の限界とNATの蔓延にあるとしたいのかもしれないが、本当にそれだけなのか。

ここでプライバシーについて考慮してみよう。アプリケーションレベルの識別子は、一時的なID(セッションID)とすることができる。Webアプリケーションでは一般的な方法だ。最初に何らかの方法でユーザ認証を行った後は、一時的なIDを使って個体識別を継続する。この場合、最初のユーザ認証の時点で、ユーザの意思により個体識別を許しているので、プライバシーの問題は生じない。(ユーザ認証にも、個人を特定した後に権限を確認する方式だけでなく、個人を特定せずに権限だけ確認する方式もあり得る。)それに対し、IPアドレスを個体識別に使う方式では、通信をしただけで即座に個体識別されてしまう。通信相手が信頼できないところかもしれない状況では、プライバシーの懸念が生ずる。

Amazon.comのような、積極的にユーザの好みに応じた画面表示をするネットショップを考えてみる。買い物をすると、何を買ったかの記録から、店の陳列棚の内容がそれに応じて変わるわけだが、買わなくても、ただ商品を閲覧しているだけで、何を閲覧したかの情報さえも記録して、それにより推奨商品が決定される仕組みもあり得る。そうした記録が嫌であれば、ユーザは、ログインせずに(ログアウトした状態で)商品を閲覧すればよい。リアルショップでも、店員に話しかけられることなく商品を見たいこともあるし、店員に相談しながら見たいこともある。ユーザの意思表示によってオン/オフが切り替えられるのが理想的だろう。ネットショップの例では、アプリケーションレベルの識別子(具体的にはcookieに格納されるID)の有無によってオン/オフが切り替わる。

IPアドレスによる識別では、識別されることから逃れることができない。通信しただけで識別されてしまう。サービス提供事業者側が、IPアドレスを記録しないように(オフの間は)システムを作ることはできるが、本当に記録していないのかという疑いが生ずる。オプトインしていない事業者のプライバシーポリシーを信じざるを得なくなる。

しばしば、技術者からこういう声が聞こえることがある。現在のWebアプリケーションで、セッション追跡のためにcookieなどを使っているのは、HTTPの出来が悪いからで、しかたなくなのだと。その考え方でいくと、さらにはこういう声も出てくるかもしれない。「IPv6ならばIPアドレスで追跡できるので、cookieなんぞいらない。cookieでセッション追跡なんてのは邪道だ」と。

たしかに、cookieという仕組みが必要だったのは、IPv4世界ではIPアドレスによる追跡があてにならないことも一因だったかもしれない。しかし、cookieが発明された際に、EZWebのsubscriber IDのように固定IDをWebブラウザに持たせるという、安易な方式を採るのでなしに、サーバが必要に応じて一時的なIDを発行できるように設計されたのは、cookie発明者が、固定IDがもたらすプライバシーの問題を理解していたための配慮であろう。

現在のWebアプリケーションで、一時的なIDを発行する方式が主流となっているのは、偶然なのか必然なのか。IPv4世界でたまたまIPアドレスが識別に使えなかったからの「偶然」なのか。そうではないだろう。もし最初からIPv6世界でWebが始まり、IPアドレスでユーザ識別をする仕組みが発展していたなら、必ずプライバシー侵害の懸念が問題化していたはずだ。現状の一時的ID方式は、結果的に得られたものであるが、必然だったと思う。

さて、ここまできたところで、IPv6の「匿名アドレス」について考える。IPv6には、RFC 3041: 「Privacy Extensions for Stateless Address Autoconfiguration in IPv6」という規格がある。通常のIPv6アドレスでは、下位64ビット(インターフェイスID)が、ネットワークデバイスのMACアドレスから一意に決定されるため、そのデバイスがどこのネットワークに移動しても下位64ビットは変化しないという、固定IDとなる。デバイスが個人所有のものであるならば、個人追跡に利用され得ることになる。EZWebのsubscriber IDと同じだ。そこで、下位64ビットをランダムに生成するようにし、ある程度の時間とともに値が変化するようにしようというのが、RFC 3041である。RFC 3041が書かれた経緯について、山根さんがまとめている。アプリケーション屋が問題点を指摘したというところが興味深い。

RFC 3041の実装は進んでいるようだ。Windows XPに搭載されているIPv6プロトコルスタックは、RFC 3041をサポートしている。実際に試してみると、通常のIPv6アドレス(public)と、RFC 3041により生成された匿名アドレス(anonymous)の2個のアドレスが用意されることがわかる。しかし、この匿名アドレスはどのように使うのかがよくわからない。 考えられるのはこういうことだろうか。WebブラウザやMUA(メーラ)などのクライアントソフトウェア(ポーリング型プログラム)では、anonymousアドレスを使い、サーバソフトウェアや、P2P型のソフトウェアでは、publicアドレスを使うという使い分けだ。それが常識化してくると、将来こんなセキュリティ脆弱性情報が流れるかもしれない。「○○が誤ってpublicアドレスを使用する脆弱性」などと。IPv6styleのサイトには、「EdMaxにIPv6対応してもらいました」という企画が掲載されているが、EdMaxはanonymousアドレスを使っているのだろうか。説明は見あたらない。それとも私の上の理解が間違っているだろうか。

そうやって必要に応じて匿名アドレスを使い分けるのだとしても、まだ疑問がある。IPv6アドレスのプレフィクス部(上位64ビット)はどうなるのかだ。典型的な例として、一般消費者が家庭にIPv6ネットワークをひくときを想定してみる。プラグ・アンド・プレイ対応のルータを設置すると、ルータが自動的に接続プロバイダからIPv6アドレスを取得する。このときのアドレスはどのように決定されるのだろうか。ADSLの同じ電話局から提供される全回線に同じプレフィクスアドレスが割り当てられる運用も考えられるし、契約者(回線)ごとにあらかじめ決められたアドレスが固定的に割り当てられる運用も考えられる。前者であれば、従来のダイヤルアップ接続と同レベルのプライバシーが確保できる(匿名アドレスを使ったソフトウェアの場合)が、後者の場合は匿名アドレスを使ったとしても、上位アドレスによって個人を追跡できてしまう。両者の中間として、ルータをリセットしたときなどのタイミングで、毎回異なるプレフィクスアドレスが割り当てられるという方式も考えられる。

RFC 3041は制定済みだし実装も進んでいるのだから、こうしたプライバシー懸念は運用で解決されるのだということなのだろう。だが、こうした運用についての議論を見かけない。たとえば、先のIPv6styleのサイトにある「素朴な疑問」のページには、いろいろな議論が載っているが、プライバシーに関するものは載っていない。

固定IPアドレスの問題は、IPv6ならではの問題ではなく、IPv4においても、近年の常時接続の普及により顕在化しつつある。IPv6技術者は、「今だって常時接続は固定アドレスなんだから今までと変わらない」と言うかもしれないが、今だって本当は問題があると考えるべきだろう。ADSLや光、ケーブルなどの常時接続提供業者は、アドレスを変更する機能を提供するべきだと思うが、どうか。これは消費者が望まなければサポートされることはないだろう。

この日記を始めた当初から書きたかったのは、「望まなければ得られない」ということだ。つまり、消費者が望まない限り事業者側からプライバシーが供給されることはないということなのだが、これは近々なんとかまとめたい。

もうひとつ別の論点を述べておきたい。IPv6推進派は、RFC 3041でIPv6のプライバシー懸念は回避可能になっていると主張するかもしれないが、その一方で、IPv6の意義が語られるとき、匿名アドレスを使わないことを前提としたものが目立つことに注意してほしい。たとえば、冒頭で紹介したIPv6アプリコンテストの入賞作品には、こんな記述が見られる。

さらにこのシステムでは、自分の割り当てた位置に個々の自動車が正しく駐車したかどうかを識別する。割り当てられた場所と違っていたり、2つ以上のスペースを使用していた場合には自動的に割増料金を請求する

このシステムは、駐車場内でアドレスを故意に変えられると正常に機能しなくなる(課金上の不正を許すことになる)ので、匿名アドレスは拒否するのだろう。

IPv6の活用意義を捻出したいばかりに、プライバシーが損なわれかねない応用が次々と構想されているところに、そこはかとない危惧を感じる。もちろん私は、IPv6反対派とか、IPv6懐疑派などではない。普及したらいいねと願っている。

他にいくつか例を挙げておく。Slammerワーム騒動後の荒野高志氏の日経ネット時評「ワームによるネット障害、究極の対策は――IPv6と教育」にはこう書かれていて、正直、目が点になった。

ソフトウエアも含め、すべての製造物/コンポーネントが製造者の手を離れてもトレースできる仕組みがあると、解決の糸口になりそうだが、これにはすべてのものを統一的にアクセス可能にするIPv6の発展を待つしかない。

「なんでIPv6で解決するの?」と疑問に思った。またそれは、「IPv6を待つしかない」ものなのだろうか。その後、荒野氏とは日経デジタルコアの研究会でお会いする機会が多くなったので、今度直接聞いてみるとしよう。

古いところでは、日本IBMのサイトに掲載されている、村井純教授のコラム「end-to-endのコミュニケーション」だ。

テープレコーダーでも電子レンジでも、この先インターネットにつながる可能性のあるものはすべて、ちゃんと特定の「住所」を持っているべきだからだ。そうすれば、これらを使った新しいシステムを作ろう、という新しい発想を伸び伸びと、自由に支援することができるからである。

この種の、最も汎用的に設計しておくのがスマートであるという技術的原理主義は、私も同意するところもあるのだが、それによって拡大するであろうプライバシーの問題をどう解決するのかについても述べてもらいたいところだ。これは、5月20日の日記に書いたように、何かお考えはおありのようなので、今度詳しく話を伺うまではあまり書かずにおく。 すべての物が住所を持つということについて、電話がたとえに借り出されることがある。「IPv6 Online Journal」に掲載されている「Mobile IPv6で可能になるPush型サービス」という記事には次のように書かれている。

例えば、位置情報システムとの連携により、商店街のエリア内に入ってきたターゲットに対して即座にピンポイントでセール情報を提供することができるようになる。 携帯電話でも、電話番号が固定であるため、類似のサービスを実現している。

たしかに、プッシュ型サービスは携帯電話に馴染むものだろう。IPv6が普及すればインターネットも同じようにプッシュ型のサービスが馴染むようになるということなのだろう。電話も固定IDで、人々はそれを受け入れてきた。だが、昔は発信者通知機能がなかったのだし、通知機能が導入された現在でも、非通知をいつでも選択できるようになっている。それに対して、IPアドレスは非通知にできない。

非通知という仕組みが簡単に実現可能なのは、電話網が、特定の事業者(政府に認可された電気通信事業者)によって運営されているからだ。事業者が守秘義務を負うことによって、プライバシーの問題は解決されている。しかし、インターネットはそういう性質のものではない。インターネット上のサービスは誰でも自由に参入できるところに価値がある。信頼できる事業者も、あまり信頼できない事業者も混在することになる。そういう状況で、固定アドレスの使用とプライバシーをどうやって両立させるのかだ。

ただし、固定IPアドレスが常にプライバシーの問題を生じさせるわけではない。完全に受動的なソフトウェア(たとえば、単にメッセージを受け取って表示するだけなど)ではプライバシーは問題にならないだろう。能動的なソフトウェア、つまりたとえば、Webブラウザのようにユーザの意思によってアクセス行動が変化するようなもので、プライバシー問題が生ずる。また、事前に決めた特定の相手としか通信しないソフトウェアもプライバシーの問題を生じさせない。Webブラウザのようにいろいろなサイトに接続するものに、問題が生じる。

同一のソフトウェアであっても、プライバシーの懸念がある処理ではanonymousアドレスを使用し、それ以外ではpublicアドレスを使うという作り方もあるのかもしれない。そのときには、何がプライバシーの問題を生じ得るのかを見極める必要がある。受動的なソフトウェアでも、特定の条件(位置情報などに基づいて)でのみ情報を受け取るシステムでは、その条件と固定アドレスとが結びついてしまうことが考えられる。このあたりの見極めが難しそうだ。この見極めを誤ったソフトウェアの続出で、セキュリティホールの新たな一分野「プライバシーホール」が生まれるのかもしれない。

最後にもう一点。財団法人情報処理相互運用技術協会の情報家電安全性技術委員会が出している「情報家電向けIPv6最小要求仕様案 (Ver.4.2 2002-2-19)」には次のように書かれている。

RFC3041ではIPv6 addressのインターフェイス識別子を乱数化してプライバシーの強化を図る提案がされている.しかし,本稿で実装必須とした手動鍵交換との併用は運用に無理がある.この場合は自動鍵交換の実装を検討しなければならない.

むむむ、大丈夫なのだろうか。「強化」という表現が使われているのも気がかりだ。一般に、「プライバシーを強化」という表現は、通常の日本語の用法では、「これまでもプライバシーはそれなりに確保されていたが、さらに強化した」ということをイメージさせるもの(関連: [memo:4768]の「セキュリティをさらに強化しました」参照)だろう。RFC 3041を使わない場合のプライバシーの懸念が軽く見られているように垣間見られて不安を覚える。

追記

「山根さんがまとめている」というところで出てくる、RFC 2964: 「Use of HTTP State Management」の著者でもあるKeith Moore氏は、なんと、Jack Dongarra先生のところの方だったのですね。というか、6年前のこのときの彼の発表を聞いたはずだし、Ninfのことで質問メールもらってるやん。あいかわらず他人の名前を覚えられない私、ダメすぎ……。ちなみに、私はIETFには全く無縁であることを白状しておきます。調べてみると、Keith Moore氏はいろいろとご活発なのですね。NAT有害論派? 力武さんも議論しているなあ。ちょうどここでも話題になってるし。

追記2

関連する記事で、昔読んだ覚えがあるがどれのことだか思い出せなかった記事を発見。RFC 3041のことが書いてあったと記憶していたのだが、違った。NymIPプロジェクトのことだった。NymIPはその後どうなったのだろうか。

昨年2月の日経ネット時評「シリーズ:IPV6」の全部を読んでみた。7人中、誰一人プライバシーについて触れていない。

追記3

「IPv6アプリコンテスト2003」の本家ページは、こっちの「IPv6普及・高度化推進協議会」のサイトにあった。IPv6アプリコンテスト2003 受賞作品に、応募作品のプレゼン資料が置かれていて、詳しいことがわかる。また、審査員のコメントがある。

本日のリンク元 TrackBack(0)

2003年05月29日

JSPP改めSACSISに出席

今日は、古巣のコミュニティ「JSPP」が改名した「SACSIS」に出席してきた。ポスターセッションで、筑波大加藤研究室の阿部さんによる、P2Pの分散ハッシュ表型探索方式を用いた匿名化Webプロキシのご発表を拝見して、いろいろと議論してきた。阿部さん曰く、来場者の半分くらいがこのシステムのそもそもの意義を理解してくれないのだという。匿名化の研究の意義は、暗号系などの会議であれば参加者は誰もが心得ているだろう。SACSISは元並列処理のコミュニティで、改名しても参加者にあまり変化がなかった。研究者であっても、分野外の人たちだと、匿名化技術の意義が理解されていないということだろうか。

「匿名性」とは何なのか

固定IPアドレスのプライバシー懸念をネットワーク屋の人に話しかけたとき、真顔で「インターネットってそういうものだろう」と言われることがある。

「匿名化技術」と聞いて嫌悪感を抱く人が少なくないように思われる。犯罪捜査が困難になるなどと危惧するためなのかもしれない。しかし、「匿名」といっても、個人の特定を不可能にするものだけを指すわけではない。複数の主体に分割して管理される情報が、何らかの権限発動によって集積されて初めて個人を特定できるようにするシステム(一部の主体の意思だけでは特定できない)も匿名化技術のひとつである。裁判所の令状に基づいて容疑者を特定するといった余地を残すことのできる方法だ。

現状のインターネット接続に匿名性はあるだろうか。ダイヤルアップ接続の場合、電話をかけて接続する毎に、異なるIPアドレスが割り当てられる。IPアドレスから電話局や地域を特定可能なプロバイダもあるが、IPアドレスが変化するため個人を追跡することは困難になっている。しかし、犯罪捜査にプロバイダが協力すると、IPアドレスと時刻から契約者を特定されることがある。そのプロバイダが接続時の認証の記録を保持していればだが。(記録を保持すべきかという議論とは独立であることに注意。)

それが、常時接続が普及するにつれて、IPアドレスは半固定的になってきた。プロバイダが開示請求に応じなければ、プロバイダだけからでは個人が特定されることはないが、IPアドレスが固定であれば、そのアドレスでオンラインショッピングや、その他のログインを要するサービスを利用しているならば、それらのサービスの利用履歴から、そのIPアドレスと個人とが対応付けられることが起こり得る。状況によっては、犯罪捜査などの強い権限を持たない一般の人であっても、何かのアクセスが誰であるのかを特定可能となることがあり得る。

私自身も、1年半ほど前、ある掲示板で、常軌を逸した(他とは異質の)まさに脅迫文を執拗に数週間にわたって書き込まれ続けたことがあった(そんなことはこれまでにそのとき1度しか経験していない)が、referrerとIPアドレスと時間帯とある情報から、それが誰によるものであるかほぼ推定できたという経験がある*1。その掲示板のクロスサイトスクリプティング脆弱性を利用して罠のスクリプトを仕掛けていたなら、次に当人が書き込みした場合にだけ、証拠をその掲示板に書き込ませるということが可能な状態だった(実際にはその罠は仕掛けなかったが)。これが可能だったのは、当人が出張先の某国の大学でUserAgentの特殊なブラウザを使用していたからだ。もし、一般のダイヤルアップ接続を使っていたならば、こうした特定はできなかっただろう。

一般家庭にも常時接続が普及してきたことで、匿名性は失われつつあると言える。常時接続においても、5月25日の日記でも述べたように、IPアドレスを時々変更できる(あるいは自動的に変更される)サービスが登場して良いはずだと思う。それも匿名化技術のひとつだ(「技術」と呼ぶほどでもない、単純な仕組みで可能だが)。

このての発言をすると、「おまえは隠れていかがわしいことをしたいのか」などと言い出す輩が出てくる。私個人について言えば、私はほとんど実名(もしくは固定の仮名)で言いたいことを言って満足しているし、2ちゃんねるなどに見られる臆面もない誹謗中傷などは基本的には同調できるものではない(ただし、これは2ちゃんねるを否定するものではない)。この私的な立場と、ネットワークインフラがどうあるべきかの議論が、独立のものであることは言うまでもない。

かれこれ2年半前になるが、Java Houseにおける匿名発言をめぐって議論になったことがあった。私の立場は「匿名発言をするな」というものであったが、一部でこれに対する反発があった。最終的に私の立場は「実名だったら投稿しないような内容の投稿は禁止」という表現で整理されることとなった。つまり、実際に実名を使っているか仮名を使っているかは重要ではなく、内容を書く際のスタンスを問うものであった。皆が「実名」で書いている場と、皆が「匿名」で書いている場とでは、おのずと内容に傾向が現れてくる。「教えてクン」が放置される場では新たな「教えてクン」が増えていくという現象が見られるが、これは、そうした行為が許される場だと解釈して参加する者が現れるからだ。Java Houseで「実名だったら……」というルールを求めたのは、そのコミュニティではそのスタイルをとった方が有益であるという考えに基づいたものであって、他のコミュニティに対してまで期待するようなルールではない。さまざまなルールのコミュニティがあって、それぞれに固有の雰囲気があり、それによって衰退する場合もあれば、罵倒と自嘲によって一定の秩序が保たれて発展するコミュニティもあり得ることは理解している。

匿名性の話をすると、掲示板における匿名性ばかりが注目されてしまうかもしれないが、そのことよりも、電子商取引サイトなどへのアクセスについて、それがあったほうが良いということを言っていることに注意してほしい。現状では、IPアドレスからでは個人を識別できないため、cookieを使った識別が行われている。もし将来に固定IPアドレスが常態化すれば、ショッピングサイトなどにおいて、cookieを使わずにWebアプリケーションを実装できるようになるかもしれない。そうなると、「ログアウト」ができなくなる。ログアウトすると記録を停止するように事業者のサイトが作られていたとしても、消費者から見ると、記録されているかもしれないという疑いを持つことになる。プライバシーポリシーを確認して、信用できるところだけ使うことになるが、プライバシーポリシーを確認していないサイトを初めて訪れたときから、そのサイトは訪問者が誰であるのかを特定できてしまうことが起こり得る。cookieも使い方によってそのような追跡を可能にするものであるため、P3P (Platform for Privacy Preferences)という仕組みが考え出され、いくつかのブラウザでは、デフォルトでサードパーティのcookieを拒否する設定となっており、この問題は回避されている。IPアドレスの固定化も同じ理由によって回避されるべきと言えるはずだ。

5月28日のセキュリティホールmemoで小島さんが私の5月25日の日記について次のようにコメントしてくださった。

ふつうの IPv6 屋さんは「P2P でつながる事が大前提。プライバシー? 知らん」という考え方のような気が。ふつう見かけるのは実名主義者で匿名主義者はほとんどいないような気が。

実名主義者/匿名主義者というくくり方は、上に述べたように誤解を招くものかもしれない。小島さんの言いたいことはこういうことではなかろうか。最近の状況がどうかは知らないが、少なくとも数年前には、IT技術者が、一般人のインターネット利用法の実態を把握していない言動をする様子がたびたび見られた。わかりやすいところで言えば、「サブジェクトに日本語文字を使うな」という8年くらい前までなら同意する人も多かったことを、2年くらい前になっても言った人は、コンピュータ技術(特にインストール技術)に自負心を持つらしき人だった。他には、かみ合わない議論を続けていると、「自分はインターネットで買い物などしない」と開き直り、しまいには「買うやつが悪い」とまで言い出す人が観察されたこともある。もっと昔の例では、7年前にメーリングリストを始めたとき、Webで案内情報を提供したところ、「Webを使わない人もいるのだから、メールでも案内すべきだ」という意見が出たことがあった。Webを使うように努力すればいいのにだ。昔気質のIT技術者の中には、そうした、新しいものをあえて拒否することを誇りにする人がいるらしい。

研究目的や議論目的だけでネットワークを使用していると、個人の特定が何ら気にならないことがある。私も10年前ならそのような認識だった。しかし、これだけインターネットの利用が一般の人たちの間の普通の生活に入り込んできた今となっては、もうそういう人はいなくなったと信じたい。もしそういう理解のまま、匿名化技術の必要性を否定するIT専門家が幅を利かせているとしたら、社会にとって由々しきことだろう。

*1 普通の誹謗中傷はかまわないが、相手に誰だか容易に予想されるような内容の脅迫を臆面もなく毎日同じ時間帯に書き続けるその人格の異常さに身の危険を感じたため、彼の出身研究室の教授に相談に行こうかとも思った。

本日のリンク元 TrackBack(0)

2003年05月30日

ICカードによる認証とは何なのか

阪神北部TIKIカードのサービスが31日で終了するとのこと。

TIKIの紹介」によると、

「ICカードの普及等によるIT装備都市研究事業」はITを強力に推進するため、住民が個人の情報を安全確実に管理・利用することを可能とする重要なキーデバイスであるICカードシステムを中心とした情報システムを地域に導入し、効果を検証することを目的としています。
とある。ICカードは何やら強固な認証を提供してくれるものと読めるし、ICカードというのはそういうものだと日ごろから耳にしている。

ところが、認証の画面に行ってみると、ActiveXコントロールのインストールがあった後、以下の画面が現れる。

画面キャプチャ

「TIKIカードIDとパスワードを入力してください」とあり、「TIKIカードID」を手で入力できる欄がある。そしてその横に、「→CARD」と書かれたボタンがある。なんだろうか、これは。

このHTMLのソースを見てみると、この「→CARD」ボタンを押したときの動作は次のように書かれている。

    IccRw.MSG = "〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓";
    IccRw.Action();
    if (IccRw.RET == -1) {
        alert("キャンセルしました。");
    } else {
        document.form1.TIKI_ID.value = IccRw.VAL;
        document.form1.PASSWORD.focus();
    }
...
<input type="text" name="TIKI_ID" size="26" maxlength="20">

つまり、このボタンを押すと、ICカードからTIKIカードIDを読み出して、入力フォームの「TIKIカードID」入力欄にその番号を挿入するだけのようだ。あとは、ユーザがパスワードを手入力して「開始」ボタンを押すわけだ。

つまり、このICカードは、ここではただ単に、ID番号の手入力の手間を省くためだけに存在しているにすぎない。これは、人々が安全性について「ICカード」から連想するものと一致しているだろうか。

(他にも気になる点があるが、事実かどうか確認できていない。)

本日のリンク元 TrackBack(0)

最新 追記

最近のタイトル

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