高木浩光＠自宅の日記(2004-11)

2004年11月13日

■ 虚偽の郵便番号と誕生日（住所ではない）

先週、はてなからこういう内容のメールが届いた。

はてな登録情報の住所追加、正しい情報登録のお願いについて

■ はてな登録情報の住所追加、正しい情報登録のお願いについて

この度、はてなでは、ユーザー様にはてなをご利用いただくにあたって、必要な登録情報項目として「住所」を追加し、「氏名」「生年月日」「性別」についても正しい登録をおこなっていただき、皆様に安心してはてなをご利用いただくための「はてな住所登録、正しい情報登録キャンペーン」を実施します。

（略）

～住所登録、正しい情報登録のお願いならびにキャンペーン実施概要～

（略）

2）抽選で150名様に「はてなポイント付き住所確認はがき」をお送りします

住所登録をおこなっていただいたユーザー様の中からランダムに抽出をおこない、150名様に「はてなポイント付き住所確認はがき」を発送いたします。発送対象者様には、メールでご連絡もいたします。

（略）

※上記はがきをお受取りになったものの、所定の手続きでポイント獲得処理をおこなって頂けなかったユーザー様は、一時的にはてなをご利用頂けなくなります。（略）

自分は、実名でこの日記を書いているので、氏名は本物に違いないが、誕生日と郵便番号の登録はどうしていたっけ？と、登録情報変更画面に行ってみたところ、次の内容で登録していたことに気付いた。

誕生日: ある適当に決めた年月日（年は±3年程度以内の差しかないもの。）
郵便番号: 305-0000 （上位3桁は実際のものだが、下位4桁は実際と異なる。）

なぜこのような登録をしたのだったか、振り返ってみた。

はてなは、以前はユーザ登録にあたって住所の届出を求めていなかった。そのような状況において、郵便番号が本人特定のために使うものでないことは明らかである。誕生日も同様である。

そもそも、郵便番号と誕生日だけ登録して何の意味があるのかわからないところであるが、実際に、無料サービスなどでそうした登録方式をとっているサイトがたくさんある。見よう見まねでそうしたやり方が広まっているのではないか。

あるいは、パスワードリマインダとしての利用を想定して登録させることが多いのかもしれない。つまり、ユーザがパスワードを忘れて、メールも届かなくなってどうしようもなくなって、サービス運営者に電話で泣きついてくるということは十分に起き得る。そのときにどうやって本人だと確認するのか。登録されている郵便番号と誕生日を電話口でスラスラと言えるかを確認するということが考えられる。

実際、ユーザ登録の画面で、住所以外の情報（誕生日や都道府県など）を書かせるところで、以下のような注意書きをしているサイトをみかけることがある。

パスワードの確認などで利用しますので、必ず正確に入力してください

アンケートや顧客動向の分析のために郵便番号や誕生日を使っているという話があるが、統計処理のためには、年代や都道府県までで十分であろう。郵便番号なら「305」まであれば上等である。

そして、誕生日や郵便番号が本人確認のために使われているのであれば、当然ながら、他のサービスにおいても同様に誕生日や郵便番号で本人確認が行われていると推察できるわけであるから、誕生日や郵便番号程度の情報であっても、それらが漏洩する可能性を持つことは自分にとってリスクとなる。

サイトにとって必須でないはずの情報であり、かつ、自分にとっても必要がなく（パスワードを忘れたりはしない）、自分にとってむしろリスクを負うことになる誕生日や郵便番号の登録は、架空の情報を登録してしまって差し支えない。パスワードリマインダにランダムな文字列を登録するのと同様の自衛手段である。

――そのように考えたと思われる。

しかし、先週になって、はてなから、利用規約の改定と施行の予告とともに、住所の登録が求められてきた。住所を虚偽の内容で登録するというわけにはいくまい。

郵便番号や誕生日と違って、住所を登録するということは、それは本人特定のためであることを意味するものであるし、今回のはてなからの告知で、明確な意思を持って正しい登録を求めていることが明らかになった。そのような状況で、虚偽の内容を登録するわけにいくまい。

改定規約の施行がまだ何か月か先であることから、それまでの間、あえて住所を登録しないでいることは許されるかもしれない。しかし、「305-0000」という郵便番号はどうしたものか。住所記入欄が設置されてそれに併置される形で郵便番号記入欄があるという状況（もはやパスワードリマインダ用には見えない）で、事実と異なる郵便番号を登録したままでよいのか。

誕生日はどうか。いまだ、生年月日を登録させる（生年だけとするのでなしに）目的は不明なままである。

そのような思考過程の末、どうするべきかすぐには心の整理がつきそうになかった。そこで、事実を説明するとともに急遽、一旦プライベートモードに移行することにしたのであった。

現在は、正しい郵便番号を登録した。生年月日は変更していない。

■ おまえが入力したのは金のパスワードかい？それとも銀のパスワードかい？

昨年9月23日の日記で「はてなの安全性を考える」というものを書いた*1。このようなことを書けたのは、当時、はてなが、さほど高いセキュリティを要求されないで済むサービスをしていたからだった*2。たしか、SSLによるログイン機能が用意されたのも、そんなに古くからではなかったと記憶している。

はてなは、SSLの提供について、気になる人は使うことができるという「オプション」として提供していたように見える。そのことは、プライバシーポリシー案において以下のように表現されていたことからもうかがえる。

はてなでは、データ伝送を保護するために業界標準のSSL 暗号を使用できます。

実際のところ、SSLは絶対に必要であるという社会のコンセンサスがあるわけではないだろう。たとえば、スラッシュドットにおいても、SSLを使わずにパスワード入力が行われているわけで、それは十分に妥当だと考えられているようである。パスワードと一口に言っても、常に暗号で保護されるべきものとは限らない。

そもそも一般に、インターネット利用者は、基礎的なリテラシーとして、「金の鍵」や「銀の鍵」と、「ベニヤ板の鍵」とを常に区別して扱うという考え方を身に着けていなくてはならない。

SSL非対応のサイト（掲示板サービスなどの重要でない画面）で入力するパスワードは、いつか漏れてもかまわない「ベニヤ板のパスワード」にする。本当に重大な安全性が求められるサービス（銀行など）で入力する「金のパスワード」を、けっして掲示板などで使ったりしないようにしないといけない。

たとえば、ポータルサイト「goo.ne.jp」のサービスでは、「ログインパスワード」とは別に「決済パスワード」なるものが用意されている。

フリーメールを使うときや、「教えて！goo」などを使うときに、SSLを使ったログインはしないのだけれども、決済を伴うサービスにおいてはSSLを使う必要があり、両者で同じパスワードを使っていたのでは、SSLで保護する意味がなくなってしまう。だから、ベニヤ板のパスワードと金のパスワードとが使い分けられる。求められるセキュリティレベルの異なる雑多なサービスが同居する、ポータルサイトならではであろう。

そのような、パスワード使い分けのリテラシーが確立していることが前提となっているため、スラッシュドットのような掲示板サービスにおいて、SSLが使われなくても妥当だと考えられるわけである。かつてのはてなも、そのようなサービスのひとつとしてみなされていたのであろう。

では、住所を送受信する機能があるときに、SSLによる保護は必須なのだろうか。これは、世論が決めることである。

今回、はてながユーザに住所登録を求めた際、一部の画面でSSLを通さずに住所情報が送受信される状態になっていたことが指摘され、ユーザの反発を招く原因のひとつとなったようである。

はてなへの住所登録の背景について

11月1日に開始しました、はてなへの住所登録のお願い、正しい情報登録のお願いについて、昨日は、SSL通信の徹底に一部不備があり、また、新プライバシーポリシーにも不備があるなど、はてな社内での準備に至らない点があり申し訳ございませんでした。

はてなは、先に書いたように、元々、SSLを必須のものとは考えていなかったふしがあるが、ユーザはそれに納得しなかったということであろう。

しかし、現時点においても、「利用者の皆様の個人情報はSSL暗号通信で保護しております」といった（よくある）うたい文句は、はてなは言っていない（「使用できます」と書かれている）ので、SSLが有効に機能することが、はてなの仕様であるわけではないようだ。つまり、SSLが機能していなくても、直ちにそれが脆弱性であるということにはならない。

そこで書いてしまうのだが、はっきり言って、はてなの住所登録画面はSSLで保護されているとは言えない。以下の種類の問題点が存在する。

Cookie盗聴によるWebアプリケーションハイジャックの危険性とその対策, 2003年7月

SSLを使うというのは、通信路上でパケット盗聴される可能性を想定して、盗聴されても安全なようにすることが目的である。しかし、はてなでは、ダイアリーやアンテナ等のサービスでHTTP通信は暗号化されておらず、ログイン状態を維持するためのセッション追跡用IDが、cookieとしてブラウザからサーバに常に送信されている。

つまり、パケット盗聴ができる状況では、cookieに書かれたセッションIDを盗まれるのであるから、それを使ってセッションハイジャックができてしまうということである。

そして、はてなでは、セッションさえ乗っ取れば「https://www.hatena.ne.jp/sslregister?mode=change」にアクセスするだけで、そのユーザの登録情報を閲覧することができる。

入力されるパスワードそのものは、たしかに暗号通信によって保護される状態にあるが、それは、「ベニヤ板の鍵」を使うべきサービスにおいて「金の鍵」を使ってしまうようなユーザを保護する役割にしかなっていない。

現在のはてなの登録情報変更画面が、SSLで保護されなければならないものであるかどうかは知らないが、ユーザがそれを希望しているのならば、現在はそれに叶うものになっていないと言える。

このことは既に何人もの人たちによって指摘されていたようだ。

羊堂本舗, はてなの Cookie が洩れると個人情報も洩れる, 2004年11月8日
tdiary.ishinao.net, [はてな] 技術的な話, 2004年11月9日

解決策は、cookieを2つ以上使うか、もしくは重要な画面に入る際にはもう一度パスワード入力を必要とするようにすることである。

実は、この問題をかかえているサイトは非常に多く、珍しいことではない。しかし、ネットショップなどのサイトでは、ログイン中の状態を長く継続させることはあまりないのに対して、はてなでは、特にアンテナでは、ほとんどログインしっぱなしの状態でサービスを使うのが普通であると考えられ、セッションハイジャックの被害に遭うリスクは、相対的に高い状態にあるという点が特殊である。

■ 日記の移転にあたって

1年半にわたり書いてきたこの日記を、独自ドメインで確保したサーバに移転することにした。移転先は以下である。

http://takagi-hiromitsu.jp/diary/

昨年9月23日の日記に、

ちなみに、私が5月にWeb日記を始めるにあたってはてなを選んだ経緯は、まずは自分でシステムを設置しようと思ったが、個人の立場で書くことが重要であるため勤務先の資源を使うことを避け、しかしながら契約している接続プロバイダのWebページサービスではCGIを使えないため、自宅サーバを確保するしかなかった。面倒なのと時間がなかったのでそれを諦め、tdiary.netを使いたかったが募集が終わっていたので、はてなを使うことになった。

と書いていたように、元々、本来は独自ドメインで tDiaryで日記を書きたかった。

こうした日記システムでは、個人的に、リンク元（Referer:）の表示機能が重要と考えてきたが、はてなのシステムは、「コメントを書く」の画面に入らないとリンク元を閲覧できない。そして、「コメントを書く」の画面に入れるようにするには、誰でも（ログインしていない状態でも）コメントを書ける設定にするか、さもなくば、リンク元を見たい人がはてなにユーザ登録するしかない。仮にそこまでしても、閲覧できるリンク元は上位10件までになっている。そのほかにも、リンク元表示まわりには、個人的に不満足なところが多数あり、tDiaryを使いたいという思いは、ずっと続いていた。

しかし、毎日追われるようにして書いてきたところに、tDiaryのインストールなどの作業をする余裕なぞなかった。

また、リンク元表示のために、コメント機能をログインユーザだけに許可する設定でスタートしたわけであるが、コメント欄で有益な情報を提供してくださる方が現れ、そのうち何人かには、そのコメントを書くためだけにはてなにユーザ登録なさったと思しき方もいらして、正直、そのことを心苦しく感じていた。（しかし、コメント欄への書き込みを不特定多数に開放するつもりはなかった。）

システム改良案の要望を出せばよいという考え方もあるが、当初の、「『はてなへの要望』と書いておけばキーワードリンクされて見てもらえるかもしれないよ」という、中途半端な合議制が性に合わなかった。システム実装上の都合もあるだろうから、あまり無理な提案をするわけにもいかないだろうし、どのくらいスタッフに直接要望を言ってよいものかもよくわからない状態だった。提案をまとめる努力が報われるかの見通しも立たない感じがしたので、もう要望を述べることはしなくなっていた。

はてなに愛着があるわけでもとくになかった。なんでこうも「はてな、はてな」言う人が多いのか理解に苦しむところがあった。

今回、いったん日記をプライベートモードにしたことで、ようやく、独自ドメインでの tDiaryの運用の作業をすると決意することができた。

やっと自分の思うように日記システムをいじれるようになって、嬉しい。

■ はてなは生まれ変わろうとしている

はてなが今回、住所登録を要請してきているのは、実名で書くことを何らためらわない人たちだけからなるコミュニティを目指そうとしているのだろうと、個人的には憶測する。

そのようなコミュニティを目指すのは自由だ。いろいろな性質のコミュニティがあって、時と場合に応じて選べるようになっているのが、理想的なネット社会だと考える。

ただ、途中でコミュニティの方向性を変更することは、困難の伴う作業となることは誰にでも容易に想像がつく。きっと、それを承知の上での舵取りなのだろうと個人的には憶測している。

思い返せば、1年ちょっと前の段階では、はてなは、無料ダイアリーのユーザから寄付金を受け付けていた。私も寄付したことを昨年9月23日の日記に書いている。

その寄付はどう活用されたのか、本当に寄付が必要だったのかもよくわからないのだが、今ではずいぶんとそのときとは状況が変わってきたな、と感じる。

今、私が日記をはてなから独自ドメインへと移転させる理由は、上に書いたとおり元々移転したかっただけだ……というとウソになるだろう。

はてなは少し前から、利用規約の改定と、プライバシーポリシーの策定を進めていた。プライバシーポリシー案に対する意見募集がなされていたので、私も意見を言う、あるいは、そのプライバシーポリシー案をネタにして、プライバシーポリシーのあるべき姿の話でも書こうかと考えた。

しかし、内容を見るとあまりたいしたことが書いてなく、そもそも、はてなにはたいした個人情報を与えていない（住所や電話番号を提供していない）のだから、これを真剣に検討しようというだけの力を注ぐ気がしなかった（優先度が低かった）。

そうして意見を出さないまま期限が過ぎ、プライバシーポリシー案が確定したかと思ったら、その後になって、住所登録必須へとの方針転換である。

これはあまりにもダメすぎる。

住所登録制は以前から検討していたものだとどこかで読んだが、じゃあ、プライバシーポリシー案に対する意見募集はいったいどういうつもりだったのか？ポリシーの重要性を低く見積もらせる状況のままポリシー案に意見を求めるなんて、バカにするのもたいがいにしろ、だ。

なお、移転先はレンタルサーバなので、当然ながら本物の住所、電話番号等を登録している。試用期間が終わって本登録の段階となると、はがきで最終パスワードが送られてくるシステムのようだ。

はてなが脱皮して生まれ変わることを激励したい。私もここを出て生まれ変わる。

*1 その後いくらか対策され、現在では、IDはときどき変更されるようになったと聞いている。

*2 すぐさま危機の迫った危ない問題点については、書くことをしていない。

本日のリンク元 TrackBack(0)

2004年11月14日

■ tDiaryへの移転でつまづいたところ

はてなからtDiaryへ移転する際につまづいたところをメモしておく。

レンタルサーバのサービスが既にtDiaryをインストールする仕組みを用意してくれていたので、基本的なインストールはとても簡単だった。

まず、ツッコミ機能をオフにしようとしたが、オフにする仕組みはないようだったので、とりあえず、スタイルシートを使って隠すことでごまかした*1。

次に、トラックバックのプラグインを有効にして、受信のテストをしたところ、文字化けした。Web検索して調べてみると、Rubyライブラリの「Uconv」がないためらしい。ここのサーバにはインストールされていないようなので、ソースをダウンロードして、サーバにアップロードし、シェルアカウントでコンパイルして、 tdiary.rbと同じ場所に置いたところ解決した。

過去の日記を移転しようとして、tDiaryの記法が自分には使いにくいことに気付き、途方にくれたが、etDiary スタイルという別の記法を使えることに気付き、そちらを使うことにした。

これで移転の作業を進めていたところ、title_tag.rbプラグインの挙動が変だった。「サブタイトル1, サブタイトル2, サブタイトル3」となるはずのところが、「サブタイトル1,,,,サブタイトル2,,,,,, サブタイトル3」などとなってしまった。これまた途方にくれたが、同様に、recent_list.rbプラグインの挙動も変だったことから、原因が予想できた。

どうやら、パラグラフ（<p>...</p>）が全部セクション扱いされてしまっているようだ。etdiary_style.rbのeach_sectionイタレータがパラグラフごとにyieldするようなので、セクションサブタイトルのないパラグラフでは yieldしないように改造してみたところ、今度はパラグラフの本文が表示されなくなってしまった。

きちんと直すのは難しそうだったので、title_tag.rbとrecent_list.rbの方を改造した。each_sectionのイタレーション内で、サブタイトルが空のときはnextするようにした。

これでうまくいったかのように見えたが、RSSが変だというご指摘のメールを頂いた。makerss.rbプラグインも直す必要があるのだった。同じように改造して仮対処したが、この方法では、セクションの概要がRDFファイルに書き出されない。ちゃんと直すのは面倒そうだ。同じ原因で、トラックバックを送信するときにも概要が送られないだろうと予想される。

それから、html_anchor.rbプラグインを有効にしてみたところ、IEでは普通に動作するが、Firefoxでアクセスすると、どういうわけか、2回に1回必ず、応答がなく空白のページになってしまうという異常が発生する。私の環境だけなのかがよくわからない。

html_anchor.rbを使うにあたって、Apacheでmod_rewriteを使うのが推奨とされているが、ここのサーバには残念ながらインストールされていないので、「Actionを利用する」で説明されている方法でやっているが、これが原因なのだろうか。

これは他にも解決方法がありそうだ。http://example.com/diary 自体をCGIにすれば、「/20041114.html」の部分を「PATH_INFO」で取得できるので、これを使うようにtdiary.rbを改造することができるはずだ。プラグインとしても実現可能だろうか。ただ、この方法でこのURLだと、トップディレクトリにtdiaryのファイルを展開することになりかねないが、それは避けたいところ。

ところで、旧日記の移転は全部は完了していない。とりあえず10月までさかのぼって移転させてみた。

さきほど、hatenaスタイルというものがあると知った。これは使える！と思ったが、互換性のない点として、パラグラフを区切るには2行の空行を入れないといけない仕様らしい。ちょっとこれは残念。旧日記を移転するには修正点が多すぎるなあと。

■ 自分流スタイルを作るぞ

2行の空行でパラグラフ区切りというのには馴染めないが、逆に、はてなの、改行が区切りになるというスタイルも実はあまり好みでない。LaTeXのスタイル、つまり、1個の改行には意味がなく、空行がパラグラフの区切りとなるのが好みだ。これは etDiaryが目指したものか。ただ、etDiaryの、行頭に「<」を書くと特別な意味になってしまうため、行頭に空白を空けないといけないのは、好みでない。

はてなの「((...))」記法は便利だった。tDiaryのfootnote.rbプラグインの記法はいまいち書きにくい。

はてなの記法は便利だったが、物足りないところもあった。行頭に「-」が続くと ULエレメントとなるわけだが、LIに続けてBLOCKQUOTEを書きたいことが多かったので、そのときは一旦整形なしモードに移って手でHTMLタグを書いていた。

BLOCKQUOTEのCITEを「<blockquote cite="..." title="...">」で書く記法を使っていたが、これがはてなの機能だったと気付いた。てっきり、HTMLの機能かと思っていた。

この記法も書き辛いものだった。改行を使ってもっとシンプルに書けるのではなかろうか。たとえば、

[[
引用先の表題
http://foo.example.com/

引用文本文、
最初の段落

引用文本文、
2つ目の段落
]]

のようにして、最初の空行までをCITEに使う仕様とか。ついでに、CITEの部分に <div class="cite">を入れてスタイルシートで見た目を調整できるようにできるとよいなあ。

それから、今回の移転で、記法を書き換える作業のついでに、画像を埋め込んでいた部分に、<div class="figure"> を入れて、キャプション付きで図を埋め込むスタイルを作りこんでみた。なかなかよい。これをもっと手軽に書けるようにしたい。たとえば、

<<
キャプション文字列

http://画像のURLその1
http://画像のURLその2
>>

のような記法などどうか。

Wikiとかはよく知らないので、このあたりはもう既にいろいろな記法があるのだろうか。

あと、パラグラフの先頭にインデントを入れないCSSにしているのは、 BLOCKQUOTEの直後にインデントが入るのを避けたい場合があるためだ。それはたとえば、BLOCKQUOTEの直後に「となっているが」などの文で続けたい場合などだ。これはどうしようもないのだろうか。

そのうち自分流のtDiary用スタイルを作ってみたい*2。

*1 ツッコミ機能を使えなくするのはtDiary（ツッコミダイアリーの略だと聞く）のポリシーに反するのかもしれない。

*2 が、そんなことをしている時間はないはずのわけで……。

本日のリンク元 TrackBacks(100)

2004年11月15日

■ キャッシュカードの暗証番号見られ放題、スキミングされ放題を演出するビデオ

「デビットカードを使ってみよう！」, 日本デビットカード推進協議会

この家族の表情を見よ。

本日のリンク元 TrackBacks(2)

2004年11月18日

■ ロボットアクセスが侵入に当たる？

法とコンピュータ学会の研究会の様子が報道されているが、そこにこういう記述がある。

P2Pやアクティベーションで問われる法的責任とは, INTERNET Watch, 2004年11月15日
ソフトのアクティベーションや違法著作物の検索システムは合法か？

（略）一方で、JASRACが運営する「J-MUSE」に代表される検索ロボット技術を使った違法著作物検索システムについては、「他人のシステムへの侵入に当たるために自力救済と考えられる可能性があり、（前記の2条件が満たされない限り）違法と判断されることもあり得る」と指摘した。

「J-MUSE」というのはこれのことのようだ。

JASRACの違法音楽配信サイト対策～J-MUSE、プロバイダー責任法、電子透かし, INTERNET Watch, 2003年2月17日

2002年12月末時点で、J-MUSEがデータベース化した違法サイトは約6,000サイト。基本的には、日本のドメインのみだという。ただし、J- MUSEは階層構造をどんどんたどっていくため、違法ファイルだけを海外のサイトに置いているようなケースでも把握している。当然、HTMLを置かずに、音楽ファイルだけを公開している場合でも、リンクをたどって検出する。菅原氏は、「掲示板やアップローダーに関して、現時点では優先順位は低い。しかし、技術的には対象にすることは可能ですから、将来的には視野に入れていくでしょう」とコメントする。

普通に読めばこれは普通のWebロボットのように思える。リンクをたどるだけの Webロボットのアクセスは当然に適法なアクセスであろう。それが「他人のシステムへの侵入に当たる」というのは理解に苦しむ。

J-MUSEがその後、他の通常でないアクセス方法も試みる機能が別に搭載されるようになったとか、そういうことなのだろうか？

質問しに行くべきだった。まことに残念。

ところで、「侵入」というのは、とても便利な言葉だ。自分が気に入らないものは何でも「侵入だ」と、言うだけならば誰でも言うことが可能だ。

先日も、 NTT西日本が顧客にWebで入力させたアンケートのデータを丸見えにしていた事故が発覚したが、NTT西日本はこれについて次のように発表してる。

お客様の情報が外部から閲覧できる状況にあった事象について, NTT西日本, 2004年11月16日

ＮＴＴ西日本大阪支店では、去る１１月１２日、弊社がＷｅｂ上で実施しているアンケートにお答えいただいたお客様の情報が外部から閲覧できる環境にあるとの指摘があり、直ちに当該サイトを閉鎖して調査したところ、関係者のみが知るアンケート集計・閲覧用アドレスに外部からアクセスされていた ことを確認いたしました。（略）

１．アンケート実施並びに集計・閲覧方法

・アンケートの実施にあたって、アンケート回答用のアドレスはアンケートにご協力いただけるお客様のみに郵送にて通知していたものであり、ホームページ上等でオープンにしていたものではありません。

・アンケートの集計・閲覧はアンケート回答用のアドレスとは別の非公開アドレスを利用して実施していました。

（略）

５．外部からアクセスできた原因

アンケート集計・閲覧用アドレスには関係者しか知らない非公開のアドレスを付与していたものの、何らかの理由で部外者がアドレスを知り １１月１２日１７時３０分頃からフリーメールでアドレスが広まった可能性があると考えています。

「侵入されました」とこそ書かれていないものの、気に入らないアクセスをされたと言わんばかりの不満たっぷりな様子がありありと見える。「自分たちに非はないはずだ」という思い込みからどうしても抜けきれないのだろう。

万が一、ロボットアクセスが「侵入に当たる」というのが法曹界の通説となるような事態になれば、NTT西日本のような連中が堂々大手を振って歩く世の中が到来するであろう。

■ デバイスIDで何をしてはいけないことにするか

別の記事では、夏井先生のご発言が次のように紹介されている。

現状はプロバイダーやP2Pの提供者などに刑事責任を負わせすぎている, INTERNET Watch, 2004年11月15日

また夏井氏は最近、研究・開発が進んでいるいわゆる「TrustedOS」についても、「TrustedOSの世界では、CPUやBIOS、OSなどそれぞれにID番号を振り、それにハッシュ値を組み合わせてシステムの改竄を監視するといったことをやっているが、これにアクティベーションのような機構が組み合わさると個人を特定した形でどんどん情報が吸い上げられてしまう」として、TrustedOSが決していいことばかりではと警告を発した。

Trusted OSに限らず、IDは既にいろいろなハードウェアデバイスに埋め込まれている。たとえばネットワークインターフェイスのMACアドレスはよく知られているユニークIDである。問題は、それをどう使うか、どのようには使わないようにするかである。

1999年に、IntelがPentium IIIプロセッサに PSN (Processor Serial Number)と呼ばれるユニークIDを埋め込み、機械語命令で読み出せるようにしたことを公表したとき、プライバシーの問題があるとして批判され、ボイコット運動にまで発展し、この機能の提供を中止するという結末に追い込まれたことがあった。

Intelの「チップID構想」に期待と不安, ZDNet News, 1999年1月21日（リンク先消失）
批判渦巻く中，IntelがチップID構想を修正, ZDNet News, 1999年1月26日（リンク先消失）
Intelの「チップID」に対する反対運動，さらに激化, ZDNet News, 1999年2月1日（リンク先消失）
1年以上続いた論争に幕――Intel，チップIDを削除へ, ZDNet News, 2000年4月28日（リンク先消失）

日本ではこの件について批判する人はあまり多くはなく、むしろ、何が問題なのかわからないといった声が技術者からあがっていた。たしかに、MACアドレスを消費者追跡のために使うソフトウェアを作成することは可能なのだから、無垢な技術屋的視点からすれば、IDを埋め込むことそのものが批判されることに納得がいかないのだろう。

だが、Intelの当時の発表では、このユニークIDをインターネットのネット取引のユーザ番号代わりに使うことをメリットのひとつとして挙げていたようだ。それを示すズバリの資料が現在では見つからないのだが、以下の資料からそれをうかがい知ることができる。

B5スリムパソコン DyanBook SS 3440/3410, 東芝,

DynaBook SS 3440には、イントラネット、グラフィックス、マルチメディアなどでの生産性を向上させるモバイルIntel(R) Pentium(R) プロセッサ500MHzを搭載しています。プロセッサ・シリアルナンバー*3により、信頼性の高いインターネットビジネスの実現や、システム運用管理において管理者の負担を軽減することができます。

つまり、インターネットでアクセスする様々なネット対応ソフトウェアにおいて、プロセッサ番号を使うことで、サーバ側からアクセス元のユーザ特定を容易にできるようになりますよ――というわけだ。

もちろん、CPUにIDが埋め込まれていようとも、またそれが有効になっていようとも、それに対応するソフトウェアが登場することさえなければ問題ではなかった。

だが、必ずやどこかのアンポンタンなソフトウェアベンダーが、PSNを使った個人特定ソフトウェアを作ってしまい、それを世に出してしまい、後で取り返しがつかなくなったりするであろうことが予想されたのだろう。あの時点で、きちんとした批判、ボイコット運動がなされていなければ、そのようになってしまっただろう。

また、MACアドレスは必然性があってユニークIDを搭載しているのに対し、CPUにはその本来の機能からすれば必然性がないという点にも、反対運動の根拠があったと思われる。

話を戻すと、その後、MicrosoftがWindows XPにアクティベーション機能を搭載することになったが、当初からMicrosoftはプライバシーへの配慮に気を遣っていたように記憶している。Microsoftは既に、IDをどのように使おうとするとプライバシー問題があるとして批判を浴びるかを学習済みであり、IDをどのように使ってはならないか、理解していたのではなかろうか。

それでもなお、Windows XPのアクティベーション機能には様々な疑いがかけられ、また、Windows Update機能についても、個人特定が行われているのではないかと、多くの人たちによって検証が行われてきたように思う。意図して追跡していないにしても、誤って特定できてしまうような仕組みになっていれば、外部から発見、批判され、知らされれば修正するということが繰り返されているのではないか。

重要なことは、このように消費者が「監視」を続けることであろう。残念なことに、日本のメーカーに対する「監視」は皆無に等しい。

ところが、まことに興味深い事例がつい最近現れた。

VAIO Update Ver.2 サービス開始のお知らせ, ソニー, 2004年10月26日
VAIO Update Ver.2 では、以下の機能を改善しました。

（略）

個人情報をソニー株式会社（以下「弊社」とします）のサーバーに送信しなくなりました。

VAIO Update Ver.1 では、個人情報としてお客様がお使いの VAIO のシリアル番号、OS およびインストールソフトウェア等の個人情報をサーバーに送信していましたが、VAIO Update Vers.2 では、お客様の個人情報を送信することなくサービスをご提供しております。

なお、VAIO Update からサーバーへ新着情報を確認する時に、ご使用の VAIO の IP アドレスがサーバー上に記録されることがありますが、これは、サーバーの履歴情報やアクセス統計のためにあり、ここから個人情報への結びつけは行いません。（略）

おおおっ。

VAIO Updateの前のバージョンは私も使っていたので、それがVAIOのシリアル番号等をソニーに対して送信するものであることは知っていた。ただ、最初に起動したときに、そのことがきちんと（比較的丁寧に）説明される画面が現れ、同意して利用するようになっていたこともあり、個人的には目くじらを立てるものにはあたらないと考えていた。

苦情があったのか、それとも全く自主的な判断なのかわからないが、今回の新バージョンで送信しないように仕様変更されたことは、同社のプライバシーへの考え方がよく表れているのではなかろうか。

他のメーカーのパソコンは使っていないので、他の日本のメーカーがどうなっているかは知らない。

本日のリンク元 TrackBacks(44)

2004年11月20日

■ GPSで居場所が通知される携帯電話？

小学一年生の児童が殺害されるといういたましい事件が起きた。これを伝える報道で、GPS付き携帯電話で犯人の位置が通知されたとしているものがあるが、これは部分的に間違っている。

まず、18日のNHKニュース7では次のように言っていた。

母親の携帯電話に「娘はもらった」というメールが届きました。女の子の写真もメールで送られてきました。このメールは女の子が持っていた携帯電話から送られていました。この携帯電話には、GPSと呼ばれる人工衛星を利用した位置特定システムが組み込まれています。メールは、女の子の自宅から南西に数キロほど離れていた地点から送られていたことがわかりました。

これを普通に聞くと、メールを送信しただけでGPSが作動し、GPSで計測される誤差5メートル精度の位置が電話会社に記録され、警察の捜査によって明らかになったという話のように聞こえる。

GPSケータイを使っている人なら、「えええ？そんなわけないのでは？」と思うはずだ。GPSの計測にはそれなりに時間がかかる*1し、GPSを作動させるには、本人の確認を必要とするようになっているのが通常だ。メールを送る度にGPSが作動しているとは思えない。

別の報道ではこうなっていた。

行方が分からなくなった１７日午後以降、母親や近所の人たちが通学路付近を捜していたところ、同日夕、母親の携帯に女児の携帯から電話がかかり、着信音１回ですぐに切れた。

持っていた携帯電話は、人工衛星を使った全地球測位システム（ＧＰＳ）を利用して居場所が分かる機能を備えており、電源さえ入っていれば、母親が自分の携帯電話を操作して、場所を示す地図付きのメールを取り寄せることができる。この機能によって、自宅近くの公園付近からの電話だったことが判明したという。

メール、発見現場近くから　ＧＰＳ機能で判明　女児殺害, 朝日新聞, 2004年11月18日

どうも話が違うようだ。一方で、同じ記事にこういう記述もある。

１７日午後８時すぎに母親（２８）の携帯電話に届いたメールは、奈良県平群（へぐり）町内の遺体発見場所付近から発信されたことが県警捜査本部の調べでわかった。

メール、発見現場近くから　ＧＰＳ機能で判明　女児殺害, 朝日新聞, 2004年11月18日

じつは、2つの別々の方法で位置特定がなされていたようだ。

ある情報筋からの話によると、今回、「母親が自分の携帯電話を操作して」位置を調べたというのは、 auの「EZお探しナビ」サービスを使ったものだそうだ。

「EZお探しナビ」とは、以下のようなサービスだそうだ*2。

基本サービス
情報料 315円/月 (税込)

お客さまの携帯電話1台と検索する相手の携帯電話1台の位置情報検索が可能です。
月間10回の検索が可能です。
セキュリティ・プライバシーの確保

検索される側で検索拒否の設定が可能です。
検索保留中、検索される側で検索を中止することが可能です。
検索された後、検索者の電話番号などが表示されます。
検索した履歴・検索された履歴とも最新5件を保持します。

KDDI au: auだからデキる > EZお探しナビ

「EZお探しナビマニュアル登録編」によると、位置を特定される側の携帯電話は、事前に、特定の相手からの検索要求を許可する設定が必要になっているようだ。

許可済みの相手から検索コールがかかってくると、自動的にEZアプリ（ないしJavaアプリ）が起動して、GPS計測が始まるという仕掛けらしい。

また、同マニュアルの検索編「登録メンバー側での確認画面です」によると、「○○さんが検索しています。このままお待ちください。」と表示されて、「現在地を確認中」というプログレスバーとともに、GPSによる測定にしばらく時間がかかることが示されている。ここで中止ボタンを押すこともできるのだろう。

KDDI「EZお探しナビマニュアル」p.11 より

これなら納得できる。

ならば、記事中の「県警捜査本部の調べでわかった」というのは何だろうか。これについて、翌日のNHKニュース7は、前日の報道を訂正するかのように、次のように説明していた。

これまでの調べで、おととい午後8時すぎ、女の子の携帯電話から母親の携帯電話に、「娘はもらった」という内容の写真を添えたメールが送りつけられ、さらにその10分ほど前にも母親に電話がありすぐに切れていたことがわかっています。警察でこれらの発信記録を調べたところ、午後8時すぎのメールは、この携帯電話会社の基地局（基地局の映像）で受信されていたことがわかりました。（略）

メールが発信されたのはこの基地局を基点に、東側3.5キロ、南東側3.5キロの三角形で結ばれる範囲内であることがわかりました。

メール発信遺体発見現場の南, NHK, ニュース7, 2004年11月19日

というわけで、警察の通話記録の調査にGPSは関係がない。

18日のNHKニュースは2つの話を混同したようだ。この誤報は、「GPS付き携帯電話を持つと常に5メートルの精度で位置を記録されてしまう」などといった、GPSに対する誤った理解を多くの人々に植え付けたと思われる。

朝日新聞の18日23時57分掲載の記事「メール、発見現場近くから　ＧＰＳ機能で判明　女児殺害」も、本文は正しくても、見出しが誤報になっている。メール発信地点が遺体発見現場近くだと判明したのは、警察が携帯電話会社に問い合わせて得た基地局の情報からであり、「GPS機能で判明」というのは、「自宅近くの公園付近からの電話」のときだと書かれていて、時刻も場所も異なる別の話だ。

今日出た新聞記事を読んでみても、GPSと基地局の話を混同した記事ばかりになっている。

調べでは、この携帯電話はＧＰＳ（全地球測位システム）で地図上の場所の測定が可能。緊急時には、電源が入っていれば、各地に設置されている携帯電話の電波発信局のうち、どこの管内にあるかを突き止められる。

奈良女児誘拐殺人：写真メール送信後の携帯電話の所在確認, 毎日新聞, 2004年11月20日

警察が携帯電話会社に要請するのが遅れたとして、警察を責めている記事も散見される。

電話会社「ＫＤＤＩ」（東京）によると、警察から依頼があれば電波を追跡し、リアルタイムで携帯の位置情報（アンテナ基地局のエリア単位）を把握できる。追跡態勢を取っていれば、メールと同時に携帯が使われたことが分かり、エリアが特定された上、ＧＰＳを使って誤差５メートルまで発信場所を知り得た可能性がある。だが、県警の追跡依頼はメールより前にはなく、ＫＤＤＩは追跡態勢を取っていなかった。結局、メールは通信記録で奈良県平群町の基地局のエリア内から発信されたことが確認できただけだった。

楓ちゃん殺害犯人“居場所”特定できた!?, 大阪日刊スポーツ, 2004年11月20日

この記事は大間違いだ。携帯電話会社がGPSを作動させられるわけではない。他の記事ではきちんと、「母親は」と書かれている。

ＫＤＤＩによると、警察から依頼があれば電波を追跡し、リアルタイムで携帯の位置情報（基地局のエリア単位）を把握できる。また追跡態勢を取っていれば、メールと同時に携帯が使われたことが分かり、楓ちゃんの携帯は衛星利用測位システム（ＧＰＳ）機能付きのため、母親はＧＰＳで誤差５メートルまで発信場所を知り得た可能性がある。

悔やまれる…携帯の電波追跡“一瞬の差”, スポニチ, 2004年11月20日

メールが届けばすぐさまEZお探しナビを作動させようとすることができるのであり、そのことに警察の携帯電話会社への要請は関係がない。実際、犯行メールより前の午後2時ごろに、母親はEZお探しナビで位置を特定していたと報道されている。

これより約六時間前の午後二時過ぎにも母親の携帯にワン切りがあり、母親が衛星利用測位システム（ＧＰＳ）付き携帯電話の位置情報を使い、自宅から約二百メートル離れた児童公園付近に楓ちゃんの携帯電話があったことを確認した。

小１誘拐・殺害　遺体の歯抜かれる　メール写真、殺害後に撮影, 産経新聞, 2004年11月20日

サンスポなどは「初動捜査ポカ」などと書いている。

奈良県警が楓ちゃんの携帯の電波追跡を電話会社に依頼したのは、母親の携帯への遺体写真付きメール受信後で、発信場所に駆け付けることができなかったことが１９日、分かった。（略）

電話会社「ＫＤＤＩ」（東京）によると、警察から依頼があれば電波を追跡し、リアルタイムで携帯の位置情報（基地局のエリア単位）を把握できる。

また追跡態勢を取っていれば、メールと同時に携帯が使われたことが分かり、母親はＧＰＳで誤差５メートルまで発信場所を知り得た可能性がある。

しかし奈良県警の追跡依頼はメールより後だったことから、ＫＤＤＩは追跡態勢を取っていなかったため、通信記録で平群町の基地局内から発信されたことを確認できただけという。

奈良県警、初動捜査ポカ？小１女児誘拐殺人事件, サンスポ, 2004年11月20日

「発信場所に駆け付ける」というが、一辺3.5キロメートルの三角形内という情報で駆け付けるという話なのだろうか。もちろんその情報もあったほうがよいに違いないが、この記事を書いた記者は、警察の要請で5メートルの誤差で場所を特定できると勘違いしているのではないか？

しかも、携帯電話はずっと電源が入っていなかったはずなのだが。

■ 誘拐殺害事件で注目される位置特定システム

今回の事件をきっかけに、子供を守るための位置特定システムの是非が改めて注目されているようだ。

18日のニュースの森は、以下の内容の放送をしていた。

今、携帯電話を持つ小学生が増えていると言います。親が子供の安全を確認するために持たせるのです。しかし、奈良県で楓ちゃんが殺害された事件では、携帯電話は身の安全を守ってはくれませんでした。（略）

狙われた下校、安全をどう守るか？, TBSニュースの森, 2004年11月18日

この中で、ココセコムを子供に持たせて、ほぼ毎日子供が学校に行くときに、家のPCから子供の移動を地図上で見守っているという母親のインタビューが紹介されていた。

朝、長男のリュックサックに位置を測定する小型の器具を入れているのです。「どこにいるか常にわかると安心する」と主婦は言います。（略）

主婦は「子供を守るのは親しかいないですから。人が何と言おうと私はこれで納得していますから」と話します。

狙われた下校、安全をどう守るか？, TBSニュースの森, 2004年11月18日

人に何か言われているのだろうか。

また、小学校のランドセルICタグの話も紹介されており、小学校の校長のコメントが映像に出ている。

全国で初めて子供のランドセルにＩＣタグをつけ、児童の登下校時間を確認する安全対策を始めた小学校があります。ＩＣタグで子供の登下校を確認。保護者に登下校の時間がメールで知らされる仕組みです。（略）

「ある学校で誘拐事件が起こった時に、その子がいないということを１時間目まで気付かなかったというニュースが昔ありまして、それをすごく恐れたんですね」（立教小学校の田中司校長）

子供に危険が及んでいることをいち早く知ることはできますが、誘拐対策としては、安全とは言えないと言います。

狙われた下校、安全をどう守るか？, TBSニュースの森, 2004年11月18日

この部分に続く校長のコメントはこうだ。

危険なことが起こったときに真っ先にそれがわかるというだけで、これが安全を確保するというものではないですね。今よりも安全にするためにどういうアイデアがあるか、一緒に考えたら何かいい答えが見つかるような気もします。

狙われた下校、安全をどう守るか？, TBSニュースの森, 2004年11月18日

何度も言うが、かえって危険になるという要素も存在することから目を遠ざけてはならない。

まあ、小学校の狙いとしては、何かあったときに「お子さんは既に学校の門から出た記録がありますので」（我々の監督責任外です）と言える体制を実現したいのだろうと思うが *3。

ちなみに、安物の暗号なしICタグでは第三者にも読まれてしまう危険があるのに対し、ココセコムや、EZお探しナビのように、携帯電話が元から持っている暗号通信を通じたサービスには、その心配はほぼないと言ってよいだろう。

ココセコムで常時子供の位置を把握することに対して、そこまで監視しなくてもと批判的に見る人はいるだろうが、それは親の自由だろう。もし学校が強制的に全員にココセコムを持たせるようになれば、批判されてしかるべきなのかもしれないが。

一方、EZお探しナビは、常時使うものではないようだし、検索され始めたときに本人が中止させられるというのは、プライバシー的にはなかなかよい機能だ。子供に、自分の位置を知られることへの拒否の権利を意識させることができる。これはなかなかほどよい感じに設計された位置特定サービスかもしれない。

今回の事件で「携帯電話は身の安全を守ってはくれませんでした」とニュースの森は言うが、別の報道によれば、犯行メールが送られてくるより前に、母親は、EZお探しナビで携帯電話の位置を特定し、捜索を始めていたとされている。今回は間に合わなかったものの、間に合うケースもあるかもしれない。

ただ、計画的な犯行ならば犯人はこの仕組みを知った上で行動するだろうから、そう簡単になんとかなるとは限らない。今回の犯人も、電源を入れるタイミングに注意しつつ犯行メールを送ったのかもしれない。

それに、今回の場合、

これより約六時間前の午後二時過ぎにも母親の携帯にワン切りがあり、母親が衛星利用測位システム（ＧＰＳ）付き携帯電話の位置情報を使い、自宅から約二百メートル離れた児童公園付近に楓ちゃんの携帯電話があったことを確認した。

小１誘拐・殺害　遺体の歯抜かれる　メール写真、殺害後に撮影, 産経新聞, 2004年11月20日

のときに、犯人は、「EZお探しナビ」の「○○さんが検索しています」という画面を見たのかもしれない。これを見て電源を切ったのかもしれない。もしかすると、あわてて中止ボタンを押そうとしたかもしれない。

KDDI「EZお探しナビマニュアル」p.11 より

あるいはもしや、犯人はこれを見たために、殺害の意思を……？？

テレビで年老いたコメンテータが、「犯人は携帯電話で写真を送るのに慣れた20代の若者」などと機械音痴ぶりを発揮していたが、犯人は、写真をメールで送るくらいは普通に使いこなしていたものの、「EZお探しナビ」で検索されるのは初めての体験だったのかもしれない。

追記

自分の携帯電話で「EZお探しナビ」を試してみた。

事前の準備をした後、PCから専用サイトにアクセスして、自分で決めた暗証番号を入力してログインし、検索ボタンを押すと、携帯電話側でアプリが起動した。

ゲームなど別のEZアプリを起動中でも、このアプリは起動するようだ。

ピロピロピロピロピ・ピロピロピロピロピと大きなアラーム音を鳴らしながら（もしくはバイブレータを振動させながら）GPS計測をし、十数秒ほどで位置を計算して送信するようだ。送信完了すると、「○○へ位置をお知らせしました。」と表示された。

自分の携帯電話をどこかに置き忘れてきたときに、探すのに便利そうだ。

*1 連続的な計測を除いて。

*2 私の携帯電話もこれに対応しているのに、こんなサービスがあるとは知らなかった。

*3 そういうタグを持たされてニコニコしていた母親たちが不憫でならない。

本日のリンク元 TrackBacks(2)

2004年11月21日

■ 不正アクセス禁止法続・数理的理解の試み

10月4日の日記では、不正アクセス禁止法をその曖昧さについて、アクセス制御機能が複数ある場合に着目して考えてみた。とくに結論といえるようなものは出ていない。

今回はその続きとして、別の点に着目してみる。

前回の検討では、「アクセス制御機能により制限されている利用」というものを解釈するにあたって、利用の集合という考え方をした。つまり、電子計算機に存在し得るあらゆる「利用」、それらを要素とする集合があって、あるアクセス制御機能によって制限されている利用というものは、その部分集合として決定されるという考え方である。

ここで、法文上の「利用」という表現が、集合としての「利用」を指しているのか、それとも、その要素としての「利用」を指しているのかが曖昧になっているという点に着目する。

まず、第二条3項には、

この法律において「アクセス制御機能」とは、（略）当該利用をしようとする者により当該機能を有する電子計算機に入力された符号が当該利用に係る識別符号（略）であることを確認して、当該利用の制限の全部又は一部を解除するものをいう。

とあるが、前回の検討では、ここの「利用」を、集合の要素としての「利用」として解釈するのを前提としていた。つまり、たとえばファイル「foo.txt」を読み出す行為をひとつの「利用」とみなしたとき、上の条文に当てはめて次の文を作ることができる。

foo.txtを読み出そうとする者により（略）入力された符号が foo.txtの読み出しに係る識別符号（略）であることを確認して、foo.txtの読み出しの制限を解除する

また、第三条2項2号にも適用してみると次の文ができる。

当該アクセス制御機能による foo.txtの読み出しの制限を免れることができる情報又は指令を入力して（略）その制限されている foo.txtの読み出しをし得る状態にさせる行為

「foo.txtの読み出し」の部分は他の様々な（具体的）利用に置き換わり得る。置き換わり得る利用の集合が、そのアクセス制御機能により制限された利用集合ということになる。

この考え方をすると、識別符号を入力せずに「foo.txtの読み出し」をする行為は、直ちにこの法律に違反することになる。

しかし現実問題として、foo.txt はWebサーバで公開されているのかもしれないのだから、直ちに同法違反というのはおかしい。

この矛盾を払拭するため、辻褄を合わせようと試みたのが前回の検討であり、また、7月18日の日記では、そもそも

何をもって「制限されている」ことになるのかが未定義である。

とすることによって、この矛盾をやむを得ないものとして理解しようとした。

しかし、法文にある「利用」を、要素としてではなく、集合そのものを直接に指すものとして解釈するとどうだろうか。

すなわち、第三条2項2号に、

当該アクセス制御機能による利用の制限を免れることができる情報（略）又は指令を入力して当該電子計算機を作動させ、その制限されている利用をし得る状態にさせる行為

とあるが、「利用をし得る状態にさせる」の「利用」とは、要素としての利用（「foo.txtの読み出し」といった個々の処理）を指すものではなく、そのアクセス制御機能によってもたらされている利用の制限全体を（不可分に）利用し得る状態にさせる行為を指すと解釈する。

この場合、「foo.txt の読み出し」という行為を行っても、そのアクセス制御機能が（その識別符号について）「bar.txt の読み出し」などの他の処理をも制限しているものであるならば、この法律に違反しないということになる。

厳密には、「foo.txt の読み出し」という行為にも2種類があって、あらゆる利用をし得る状態にした上で「foo.txt の読み出し」だけを実行した場合と、「foo.txt の読み出し」だけをし得る 状態にした上で「foo.txt の読み出し」を実行した場合があり、前者であればこの法律に違反するが、後者ならば違反しないという解釈である。

簡単に言い換えれば、ようするに、2号違反行為とは（識別符号を入力せずに）識別符号を入力したのと同じ状態にする行為を指すという解釈である。

この解釈を採用すると、前回に検討した疑問点は払拭されるように思える。

つまり、2号違反行為とは、下の図のように、いずれかの識別符号から写像される利用集合に一致する利用集合を利用し得る状態にするような、セキュリティホールを突く行為だけが該当するということになる。

これに該当する行為の例としては、次などが挙げられる。

バッファオーバーフロー脆弱性を突いてシェルを乗っ取った
セッションIDを窃用してセッションハイジャックした
パスワード入力欄の処理に存在するSQLコマンドインジェクション脆弱性を突いてパスワードなしにログインした

さて、この解釈は「正しい」だろうか。「正しい」とはどういう意味か。

立法者の意図に一致する。
法曹界の通説に一致する。
裁判例に矛盾しない。
国民がこの法律に期待しているものに近い。

2.と3.は不明であるが、1.と4.についてそれぞれ検討する必要がある。

なお、この解釈を採用してもなお、何をもって「制限されている」ことになるのかの曖昧性はまだ残るような気もするが、まだ考えていない。

（未完、改訂予定）

本日のリンク元 TrackBack(0)

2004年11月23日

■ 人工衛星に監視されるイメージに囚われている？

昨日のNHKニュース10で「子どもの登下校に小型の発信機」と題したコーナーが放送されていたが、また事実と異なることを言っていた。

奈良市の事件を受けて教育現場では、児童の安全な登下校が課題になっています。静岡県の島田市では今日から、人工衛星で児童の位置を確認できる小型の発信機を、希望する小学生に持たせる取り組みを始めました。

（略）島田市の教育委員会が配ったのは、大手の警備会社が作った小型の発信機です。元々一人暮らしなどの高齢者を対象に開発されました。子どもの居場所は警備会社のホームページで地図に示されます。発信機の信号を人工衛星が捕らえ、子どもが今どこにいるのかを知ることができます。

（報告金森大輔 NHK静岡）

NHK, ニュース10, 「子どもの登下校に小型の発信機」, 2004年11月22日

違うっての。

紹介されていたのは、綜合警備保障の「あんしんメイト」であり、これは、GPSで位置を計測してNTTドコモのDoPaサービス（携帯電話網を使用している）を使って送信する仕組みのものだ。断じて、人工衛星に向けて発信するシステムではない。

念のため、GPSがどういうものか大雑把に書いておくと、電波を出すのは人工衛星の方で、GPS対応端末はそれを受信する。電波には正確な時刻情報が乗せられていて、GPS対応端末が複数の人工衛星からの電波を受信すると、それぞれの時刻に差が生ずるので（電波は10メートル進むのに0.03マイクロ秒かかるので）、各々の人工衛星からの距離が計算でき、これを元に位置を求める。

どうにもこう「人工衛星は何でもお見通しだ」みたいな勘違いは根強いようだ。こういう映像*1 がそういうイメージを招いているのだろうか*2。そもそも、この図からして誤解を助長している。人工衛星と自動車が双方向に通信する図になっているし、人工衛星が1台しかない。

そして、そうした勘違いをRFIDタグ推進派が逆手にとることもある。

たとえば昨年11月の「RFID Privacy Workshop @ MIT」で、ThingMagic社の「Physics of RFID」と題した招待講演のスライドの最後のページ「Conclusions」には、

- There are serious practical limitations to passive RFID read range.

- It is not practical to read a passive UHF RFID tag from Earth orbit.

- Improvements to tag IC design will yield commercially helpful, but probably privacy insignificant increase in read range.

と書かれている。（以下ちょっと日本語訳）

・パッシブ型RFIDの読み取り範囲には容易ならない実用上の制限がある。

・衛星軌道からUHF帯のパッシブ型RFIDタグを読むことは実際的でない。

・タグのIC設計の改良は商業的に役立つものとなっても、読み取り範囲についてプライバシー上の増大はたぶん取るに足らないものとなるだろう。

これに引き続き開催された「RFID Town Meeting」では、その議事録によると、CASPIANのKatherine Albrecht氏が次のように述べたとされている。

We never said that passive tags could be read from satellite. But International paper says that they are using satellites to track passive tags as they move about the supply chain in trucks. They have a passive system that reads the footprint of the truck that is connected with a GPS receiver and some transmitters that uplinks the data to a satellite.

（以下ちょっと日本語訳）

人工衛星からパッシブ型タグが読み取られ得るなんて言ったことないわ。でも、インターナショナルペーパー*3が、サプライチェインを貨物が動き回るのをパッシブタグで追跡するために、人工衛星を使っていると言っていたわ。彼らは、貨物の足跡を読み取るパッシブシステムを持っていて、それはGPS受信機に接続されいて、何かの送信機がデータを人工衛星に送信するの。

（うーむ、人工衛星にアップリンクするというのは、衛星携帯でも使うのだろうか？まあいいか。）

また、日本でもこういう話があった。

最近よく記事で目にするゴマ粒チップについて聞きたいのですが，このチップを埋め込んだシールを作って自分の大切なモノに張っておくと，GPSなどの位置情報システムと連動して所在地が分かるの？

消費者に理解されていない「ICタグ」, 栗原雅＝日経コンピュータ, 2003年8月7日

■ 立教小学校のランドセルアクティブタグ導入の考え方

立教小学校の実験の話が、詳しく説明された記事が専門誌に出た。

労力低減とセキュリティも実現した「ＲＦＩＤタグ」児童の登下校時を完全把握で“あんしん” 約束希望者（保護者）にはメール通信サービスも来春には全校児童で完全導入へ立教小学校, セキュリティ産業新聞社, 2004年11月12日*4

――導入するきっかけはどんな構想ですか。

石井　先生の（雑用など）労力軽減に役立つほか、児童の安全対策も同時に実現できるのではないかと思いました。（略）

例えば児童の出欠（点呼）をとる手間を何とか削減できないかと考えていました。（略）

一方、学校内、厳密にいうと校門をくぐった時点から校内の責任は学校にあると考えています。反対に校門を出た時点から（前提として社会治安や物理的な安全性など公共的な諸々条件が加味されるが）は児童自身と保護者の責任が前提になると考えています。そこで、登校時に何時についたか、反対に下校時は何時だったかを把握することで、一人一人の安全を確認できます。

しかも、登下校時ですから個人のプライバシーを侵すことはありません。（略）なかにはＧＰＳを使ったセキュリティサービスを提供する警備会社もありますが、これは加入者が同意した上で申し込んだ者がサービスの提供を受けるもので、同様な事を学校側が実施するとなると、過剰教育、つまり、プライバシーに抵触する可能性があると考えました。（略）

――いつ頃に導入決定をしたのですか。

石井　学期毎に保護者全員の参加が前提の「ＰＴＡ総会」を行っていますが、年度内２回目となる総会を９月18日に開催し、その席上、田中校長が児童の安全確保に対する考えや、その一環として当システム導入する趣旨などを説明しました。総会で多くの質疑応答や批判などが出た場合はこの計画は取り止めになったかも知れませんが、幸いにして殆どの保護者から同意を得られましたと認識しています。というより、『何重でも良いから、子供達の安全を守ってほしい』という意見・要望が大半であったと思っています。

――今回のシステムは全校児童を対象にスタートとしたのですか。

石井　いえ、（略）

というのも、屋外で、且つ、子どもを対象にした実証試験は実施されておらず、またRFIDタグも、物流などに用いられるものとは全く異なり、新たに開発された専用の製品を投入しましたから、正確に機能するかなどを確かめる意味からあくまで実証実験という段階です。（略）

――今後のスケジュールや抱負などはいかがですか。

（略）その事に限らず、ＩＣタグによる技術の可能性は、学校業務の軽減と言うことに関して、大きな広がりを持っていると考えています。 例えば、遠足などの行事での点呼は重要であるにもかかわらず、非常に煩雑で教員の労力の多くが割かれてしまっています。（略）このような労力を、機械によって可能なことは極力、機械化し、児童との教育的な関わりに、教員の最大の労力を割いてもらうことが、最も重要だと考えています。

「物流などに用いられるものとは全く異なり、新たに開発された専用の製品」というのは、暗号機能を搭載しているのだろうか。以前電話でたずねたときは、専用の製品だが暗号機能は搭載していないとのことだったが。

■ 田辺市の小学校では950MHzタグを使用？

和歌山県田辺市の小学校でのランドセルタグ実験が実施されたことが報道されていた。

総務省近畿総合通信局の「公共分野における電子タグ利活用に関する調査研究会」（座長＝佐藤周・和歌山大学経済学部助教授）は５日、田辺市新庄町の新庄第二小学校での実験を終え、報道関係にシステムを公開した。（略）

実験は10月25日から11月５日まで行われ、同校の全校児童１７３人のうち、１５９人が参加した。

総務省など実験あの子は登下校できた？ＩＣタグで行動確認, 紀伊民報, 2004年11月7日

14人が参加していないという計算になるが、理由は何だったのだろうか。

ランドセルに取り付けたＩＣタグは自ら電波を発信しないパッシブ方式で、ＵＨＦ帯周波数を利用。電池を使わないため半永久的に利用できるほか、広い範囲でタグを読み取ることができるのが特徴という。

総務省など実験あの子は登下校できた？ＩＣタグで行動確認, 紀伊民報, 2004年11月7日

ということは、国内での使用が認められていない 950MHz帯タグの使用許可を総務省から得て実験したのだろうか。

また、校外の安全対策として校内にある「探検の森」を町中の遊び場と想定し、リストバンドタイプのＩＣタグを使った実験もした。

総務省など実験あの子は登下校できた？ＩＣタグで行動確認, 紀伊民報, 2004年11月7日

当初計画されていた、校外に読み取り器を設置する実験は、けっきょく行われなかったということか。こちらの実験ではアクティブ型が使われているようなので、第三者に読み取られて悪用される危険に配慮したということだろうか。

となると、実用化できるできないの指針はこの実験で得られたと言えるのだろうか？

また、別の報道によると、写真撮影までしたそうだ。

◆校舎にアンテナ、通れば写真撮影

（略）校舎の玄関に設置した平面アンテナが、タグ付きのランドセルを背負った児童が通過する瞬間に電波を発射。本人と確認できれば証明写真を撮影する仕組み。データを検出すると電子メールで保護者に連絡、インターネット経由で写真を見ることもできる。

（略）総務省近畿総合通信局は「子供の行方がわからなくなった際、迅速に対応できるメリットがある。地域に安全と安心を届けられるよう、実用化を目指したい」としている。

ＩＣタグで登下校確認　総務省など、田辺市の小学校でシステム公開, 大阪読売新聞朝刊, 2004年11月6日

「タグが通過する瞬間にアンテナが電波を発射」というのは、またもや事実と異なる報道。電波は常に照射されている。「本人と確認できれば」とあるが、本人確認をするわけではない。これも誤報。

■ UHF帯RFID、性能向上中

今月の各紙報道によると、UHF帯RFIDの通信距離を長くする技術改良が進んでいるとのことだ。

三菱電機、ＩＣタグ、読み取り７メートル確保、装置間の干渉防止, 日経産業新聞, 2004年11月12日

三菱電機は十一日、九五〇メガ（メガは百万）ヘルツで通信するＩＣタグ（荷札）の読み取り装置間で起きる電波干渉を回避し、国内最長となる 約七メートルの通信距離を確保する技術を開発したと発表した。（略）
三菱電機、RFID間の電波干渉を防ぐ技術を開発, Enterprise Watch, 2004年11月11日

今回発表された技術は、物流・商品管理での利用が見込まれるUHF（950MHz）帯RFIDにおいて、RFIDタグからの電波を受信するリーダー装置同士で発生する干渉を、独自の「送受周波数分割方式」で回避するもの。さらに微弱な電波の受信電力からより高い電圧を得るための「微弱電界レクテナ技術」を適用することで、電池を搭載しないパッシブ型RFIDタグにおいて最長7m離れた場所からの読み取りが可能となるという。（略）

従来のUHF帯RFIDシステムはリーダーから送信される電波と、タグからの微弱な反射波によるレスポンスが同一のチャンネルであったため「最大10km範囲内に同じチャンネルを利用するリーダーが稼働していると電波干渉が起こり 正確な読み取りができない恐れがあった」。

UHF帯のパッシブ型RFIDシステムでは、13.56MHzを使うICカードの電磁誘導式とは異なり、リーダからの強い電波によって電力を供給するシステムであるため、リーダの信号が広範囲に届いてしまう。上の報道によれば、その距離は10 キロメートルに及ぶようだ。

アンチコリジョン機能（同時に複数のRFIDタグを読むための機能）を搭載している場合、単純な方式では、リーダがタグに対して「xxxx番のタグさん応答してください」という指令を送ることになる。この指令の信号に、タグのID番号がそのまま入っている場合には、正規のリーダで読み取られている他人のRFID タグのID番号が、10キロメートル先にいる第三者から読まれてしまうことになる。

この問題は、「forward channel」の問題として以下の論文などで議論されていた。

Stephen A. Weis, Sanjay E. Sarma, Ronald L. Rivest and Daniel W. Engels, Security and Privacy Aspects of Low-Cost Radio Frequency Identification Systems, First International Conference on Security in Pervasive Computing. 2003

Although readers may only read tags from within the short (e.g. 3 meter) tag operating range, the reader-to-tag, or forward channel is assumed to be broadcast with a signal strong enough to monitor from long-range, perhaps 100 meters. （略）

One security concern is the strong signal of the reader-to-tag forward channel. Eavesdroppers may monitor this channel from hundreds of meters and possibly deriving tag contents. Of particular concern is the binary tree walking anti-collision algorithm, because the reader broadcasts each bit of the singulated tag’s ID.

論文はこのように懸念していたわけであるが、その距離は 100メートルどころか、10キロメートルも先で干渉してしまうほどらしい。

このように、電磁誘導方式でないRFIDシステムでは、アンチコリジョンの方式にもプライバシー上の配慮が必要である。電力供給と選択指令を別のフェーズに分けて、選択指令のフェーズでは微弱電波とするなどの対策が考えられるが、実際のシステムではどうなっているだろうか。読み取り速度が落ちるからそういうことはしないだろうという予感がするが。

日立、ＩＣタグに新製品、書き換え可能型発売――電子マネーなど用途拡大, 日経流通新聞, 2004年11月15日

日立製作所は来春、情報の書き換えが可能なＩＣタグ（荷札）用チップ「ミューチップＲＷ」を発売する。（略）

周波数は従来品と同じ二・四五ギガヘルツだが、通信距離は三倍の約一メートルに伸びる。

書き込み可能型のミューチップが登場したとのこと。電子マネー用途ということは、暗号機能も搭載したのだろうか。

日立、新本社の入館証にＩＣタグ, 日本経済新聞, 2004年10月2日

日立製作所は10月１日から東京・丸の内の新本社で、無線通信可能なＩＣタグ（荷札）を使った来客管理システムの本格運用を開始した。タグを取り付けた入館証を来客者に渡し、許可された区域は自由に行動できるようにする一方、立ち入り禁止区域には入れない。安全管理体制を強化するとともに、同社が手掛けるタグを利用するシステムの認知度を高め販売につなげる。

（略）

カードの価格は１枚100円以下で、入館証として普及し始めた電波通信型ＩＣカードの10分の１以下。10月から同様のシステムの外販も始めた。

やはり暗号機能を搭載したのだろうか。でないと、リプレイ装置で社員から読み取ったIDでなりすまして、禁止区域にその社員のIDで入られてしまうからなあ。それは「安全管理体制」と宣伝するにはまずいから、暗号機能を搭載できたに違いない。それが従来の暗号機能搭載ICカードの10分の1以下の価格とは、画期的な技術だ。すごい。

■ 「素敵に騙して」は最近でも通用するのだろうか

ＩＣタグで連れの客の所在確認・阪急百貨店で実験, 日本経済新聞, 2004年11月9日

阪急百貨店とＮＴＴコミュニケーションズはＩＣタグ（荷札）を使って、買い物客同士が互いに店内のどこにいるか確認する実験を始める。店内に設置した表示装置に客がＩＣタグをかざすと、別行動している連れの客の居場所が表示される。家族やグループで来店した客が、それぞれ自由に買い物しやすくなる。（略）
ＩＣタグで居場所ピタリ　阪急百貨店が実験へ　別々の買い物自由に, 大阪読売新聞夕刊, 2004年11月10日

阪急百貨店は、家族連れやカップルの顧客に協力してもらい、電子荷札「ＩＣタグ」を使って、店内で互いの居場所を確認する実験を行う。百貨店では初めて電波発信タイプのＩＣタグを使い、（略）

（略）十七日から十二月二十一日まで、大型商業施設「ダイヤモンドシティ・プラウ」（大阪府堺市）内の「北花田阪急」（一―三階、約一万六千平方メートル）で実施する。

十六歳以上の来店客に、二人一組でＩＣタグ（縦約五センチ、横約三センチ）をそれぞれ持ち、別々に買い物をしてもらう。タグから発信された電波は、各階に六か所あるアンテナがとらえる。（略）

タグをポケットに入れたままでも電波発信に支障がなく、トイレなど電波が届かない所にいる時は、最後に電波をとらえたアンテナの場所と時刻を表示する。（略）

ほほう。これはつまり、「買い物客同士が互いに店内のどこにいるか確認する実験」と説得しながら、客の動線追跡マーケティングの実験をしたいのだなと。実験で、プライバシーポリシーがどう若いカップルに説明されているかが興味深いところだ。

動線分析の段階で個人を特定しないようにするのだとしても、それを、「お連れ様の所在確認システムですよ！」と勧められるという、そのいやらしさ、あるいはさりげなさを、消費者たちはどう感じ取るだろうか。

*1 人工衛星が地球を見下ろし、街を歩く人にズームする映像。

*2 このビデオはかえってこの製品の印象を悪くしてしまっていやしないだろうか。

*3 米国の製紙会社International Paperのことか？

*4 末尾に「2004年7月25日号より」とあるのは誤りか？

本日のリンク元 TrackBacks(6)

2004年11月24日

■ セキュリティホールmemo BoFでの予定

Internet Week 2004の12月1日のプログラムにある、「セキュリティホール memo BoF」で、「適法な脆弱性発見とは」と題して少しお話しさせていただく予定。30分ほど話してあとは議論を。

内容は、こんな感じにする予定。

Webサイトの脆弱性発見は必要か？
偶発的発見か積極的発見か
可能性の認識と事実の検証
脆弱性情報届出制度
適法な発見に基づく届出の実際
不正アクセス禁止法は何のためにあるか
「侵入」とは何か
良心的意図？外形的行為？
SQLインジェクション脆弱性をどうするのか
脆弱性情報公表と不正指令電磁的記録作成の関係

■ 謎のツッコミ現る

「Moleskin Diary」の24日のエントリ「見えざるツッコミ」で、この日記の11月21日のところに、ツッコミが入れられていることが指摘されていた。

11月12日の日記「おやくそく」に

ツッコミ機能（コメント機能）は使わないことにします。隠してありますので、仮にツッコミが書き込まれても、私も目にすることはないでしょう。

と書いたように、ツッコミ機能は使わないことにしている。使えないようにしたわけではなく、使わないことにしたのであり、スタイルシートで隠していただけなのだ。なので、スタイルシートを無効にする*1だけで、ツッコミ機能のための入力フォームは画面に現れる状態だった。

書き込まれた内容が見えない状態であれば誰も書いたりしないだろうと思っていたが、RSSを生成するプラグイン「makerss.rb」が、 tDiaryのツッコミ設定における「ツッコミの表示」を「非表示」にしている場合でも、ツッコミ内容をRDFファイルに書き出してしまうというバグがあったため、書き込まれたツッコミの文章が、RSSリーダなどに表示されるという事態となったようだ。

というわけで、makerss.rbを改造して、ツッコミを書き出さないようにした。また、14日の日記「tDiaryへの移転でつまづいたところ」にトラックバックを頂いた、 diary.yuko.netの「コメント入力欄を消す方法」にしたがって、設定をした。

これでスタイルシートを無効にしても、コメント入力欄は現れないわけであるが、依然として、直接所定のURLに所定のパラメータで POSTすれば、突っ込みは書き込める状態にある。tdiary.rbを改造して、それさえできないようにすることは可能そうだが、書いても見られないのだから、今のところそれはしていない。

*1 たとえば、Bookmarkletを使う方法や、Mozilla/FirefoxならばExtensionを使う方法などがある。

本日のリンク元 TrackBacks(100)

2004年11月27日

■ Shuriken Pro3 のS/MIME機能に何があったか

確認された事象

まずこの広告ページにじっくり目を通して、S/MIME機能の有益さを理解する。

Shurikenとは？ / 安全 / メールのデジタル署名対応！ , ジャストシステム
Shurikenとは？ / 安全 / メールの暗号化対応！, ジャストシステム

次に、22日に発表されたJVN#B410A83Fを読んでみる。

JVN#B410A83F: Shuriken Pro3 のS/MIME機能で署名検証時にFromアドレスが確認されない, JPCERT/CC / IPA, JP Vendor Status Notes, 2004年11月22日

「署名検証時にFromアドレスが確認されない」とはどういうことなのか、Shuriken Pro3/R.2のバージョン 5.0.1.6 で確認した現象を以下に書いておく。

まず、S/MIME署名されたメールを Shuriken Pro3 で受信し、表示しようとすると以下の図にある画面のように、「このメールは暗号化、または、署名されています。」というメッセージとともに「復号・署名確認」というボタンだけが現れる。

図1: S/MIME署名されたメールをShuriken Pro3で開こうとしたときの画面

この「復号・署名確認」ボタンを押すとどうなるかというと、正規のメール（なりすましも改ざんもされていない）であれば、そのままメール本文が表示されるが、本文が改ざんされているときには、以下の図にあるような警告が現れるようになっている。

図2: メール本文が改ざんされているときに現れる警告

また、偽の認証局から発行した偽の証明書で署名したメールを受信して表示しようとしたときや、期限切れの証明書で署名されたメールを表示しようとしたときには、次の図の警告が表れる。

図3: 偽認証局から発行した偽証明書で署名されたメールを開こうとしたときに現れる警告

図4: 期限切れの証明書で署名されたメールを開こうとしたときに現れる警告

ところが、正規の証明書を使って、他人のメールアドレスを発信者として騙ったメールを受信したときにどうなるかというと、以下の図のように、警告が出ることなくそのまま本文が表示されてしまうのである。

図5: From:アドレスを偽装したメールを開こうとした様子

差出人欄が「info@example.com」というメールアドレス*1になっており、これはなりすましメールにほかならないわけだが、Shuriken Pro3 5.0.1.6 はこのとき警告を出さない。

これは脆弱性と言えるか

9月19日の日記にも書いたように、S/MIMEの仕様では、From:またはSender:欄のメールアドレスと、署名に使われた証明書のメールアドレスが一致していることを確認することがMUSTと規定されており、一致しない場合には、何らかのはっきりとした代替処理をする（証明書にあるアドレスを示すメッセージを表示するなど）ことがSHOULDとされている。

3. Using Distinguished Names for Internet Mail

（略）

Receiving agents MUST check that the address in the From or Sender header of a mail message matches an Internet mail address in the signer's certificate, if mail addresses are present in the certificate. A receiving agent SHOULD provide some explicit alternate processing of the message if this comparison fails, which may be to display a message that shows the recipient the addresses in the certificate or other certificate details.

RFC 2632 - S/MIME Version 3 Certificate Handling

この問題を修正するパッチが、ジャストシステムから11月16日にリリースされたのだが、その修正内容がどのようにユーザに説明されたかというと、以下のようになっている。

仕様変更項目

▼2004.11.16更新時に追加

S/MIMEの署名検証時に電子証明書内に記述されているメールアドレスとメールのFrom欄のメールアドレスが異なる場合に、自動で警告表示するようにいたしました。

※メールの復号時に警告が表示されるため、 メール本文を読む前になりすましメールかどうか確認できます。

Shuriken Pro3 アップデートモジュール, ジャストシステム

この文は暗に、「メール本文を読んだ後ならなりすましメールかどうか確認できたが」と言っているように読める。

たしかに、Shuriken Pro3のヘルプから、S/MIMEに関して説明されている部分を見てみると、次の図のように書かれており、「表示」メニューの「暗号・署名情報の表示」を選択することで、S/MIME署名の真正性を確認するという手順が書かれている。

図6: Shuriken Pro3「ヘルプ」より

この操作をすれば、以下の図のウィンドウが現れるので、証明書のメールアドレスを目視で確認することができるというわけだ。

図7: 「暗号・署名情報の表示」機能を使ったときの様子

さて、これはどうなのだろうか？

改ざんされているときや偽証明書、期限切れのときには、警告が出るのだから、それを知っているユーザは、警告が出なければなりすましメールではないと誤認してしまうだろう。

ただ、そうした事態を見たことのない、そうした警告のことを知らないユーザは、署名メールを受信したら必ず上の操作をしているはずだ……と言えるのだろうか。

たしかに、Shuriken Pro3のヘルプには次のように注意書きされている。

署名者の証明書が期限切れとなっていたり、無効になっていたりすることがありますので、［デジタル署名に使われた証明書］をクリックして、証明書自体の有効性を別途ご確認ください。

Shuriken Pro3 ヘルプ

証明書が期限切れならばボタンを押した時点で警告は出るようになっているのに、期限切れになっていることがあるから、別途クリックして確認せよとされているのはちょっとわからないが、証明書が失効されていないかを確認するには、そのウィンドウを出して、証明書を表示させ、「詳細」ボタンを押して、「失効の確認」ボタンを押す必要があるようである*2。

どのように修正されたか

図5の説明には若干の補足が必要である。

受信したメールの署名者の証明書を、証明書ストア*3に信頼済みのものとして登録していない場合（たとえば、初めての相手からのメールである場合）には、次の図のように、証明書ストアに登録するかと尋ねる確認ウィンドウが現れる。

図8: 証明書登録確認の画面が現れた様子

これが From:を偽ったなりすましメールであるときに、この時点で気づくことができると言うことはできるのかもしれない。「詳細」ボタンを押せば、証明書のメールアドレスを確認することができる。

フィッシング詐欺のメールが From:を偽ってきたときには、たとえそれが正規の証明書で署名されていたとしても、この画面が現れるはずである*4から、「詳細」ボタンを押せば本当の発信者メールアドレスを確認できる。

しかし、証明書ストアに既に登録している相手が、From:を詐称して別の人になりすましてメールを送ってきた場合には、何もウィンドウが現れないままに本文が表示されることになるのだから、やはり、この挙動は問題なしとはいえないだろう。

また、From:を偽ったフィッシング詐欺のメールに対して、図8の画面が現れたとき、「詳細」ボタンを押さないまま、「はい」を押してしまう危険もある。

「証明先」と書かれた部分には、メールアドレスが表示されておらず、証明書の氏名部分が表示されているので、Class 1の証明書が使われている現状では、ここには任意の名称を勝手に名乗ることができる*5のだから、もっともらしい名称を名乗るフィッシング詐欺メールの証明書を、証明書ストアに登録してしまうかもしれない。

今回の修正パッチを適用したバージョン 5.5.6.0 では、「署名者のメールアドレスと差出人のメールアドレスが一致しません」との警告が出るようになり、 From:を詐称したメールに対して図8のウィンドウが現れることはなくなった。やはり、これが本来のあるべき挙動ではなかろうか。

こんな告知でいいのか？

さて、このような状況があったわけであるが、Shuriken Pro3のベンダーは、今回の修正を「仕様変更」であると説明している。「セキュリティ」とか「脆弱性」といった言葉を使ったユーザへの説明はなされていない。 JPCERT/CCと IPAが、これを脆弱性と認めて、JVN#B410A83Fとして発表しているのにもかかわらずである。

ちなみに、6月30日には、こういう告知がなされていた。

Shuriken Pro3、Shuriken Pro3/R.2、Shuriken Pro3/R.2 [ベリサインセキュリティメールセット]で、デジタル署名つきでメールを送信した際に、受信者側で警告が表示される現象について

Shuriken Pro3、Shuriken Pro3 /R.2、Shuriken Pro3 /R.2[ベリサインセキュリティメールセット]にて、デジタル署名付きメールを相互運用いただく際に、受信者側の一部の環境において警告メッセージが表示される現象を確認しました。なお、現状のご使用においてセキュリティ上、安全性を損なう問題ではございませんのでご安心ください。

このときのバグは、偽ではないはずのメールが偽と判断されてしまうという、安全側に倒れているバグだった。だから、「安全を損なう問題ではない」というのは、たしかにそうだ*6。

こういうときには、専用の告知ページを設けて必死に事情説明をしていたくせに、偽のものが偽と警告が出ない今回のような現象（つまり、危険な側に倒れたバグまたは「仕様」）のときには、さらっと流して終わりのつもりのようだ。

図9: Shuriken Pro3アップデートモジュールのページにある説明

しかも驚いたことに、今日、Shuriken Pro3のオンライン販売サイトで、ダウンロード購入してみたところ、販売されていたバージョンは 5.5.4.0 で、このバージョンは、今回の問題点が修正されていないものだった*7。

購入ページや、製品紹介のページに、今回の修正モジュールの適用が必要だといった説明はみあたらない*8。

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

ちなみに、11月17日にこういうニュースが流れていた。

ジャストシステム、Shuriken Pro3のパッチを公開中止, PC Watch, 2004年11月17日

不具合の内容は、「フォルダ-仕分けの設定」内で新規フォルダを作成するとShurikenが強制終了し、再起動後に同名フォルダが作成できなくなるというもの。

こういう不具合は発表しても、セキュリティ脆弱性の修正は発表されないらしい。

JVN#B410A83Fが出たにもかかわらず、それを報道したメディアは存在しなかったようだ。マイナーなソフトウェアの脆弱性情報が報道されないというのならまだ理解できるが、PC Watchの上の記事のように報道される製品ではある。

もし意味がわからないから報道できないということがあるのならば、 JPCERT/CC なり IPAなりに問い合わせればよかろう。

S/MIMEなぞ誰も使ってないし、S/MIME署名メールの真正性なぞ重要でもない――ということなんだとも考えられるが、ならば、冒頭に挙げたベンダーの宣伝ページはなんなんだ、ということになる。

■ 偽の認証局証明書の作成が難しいという誤解があるらしい

10月30日の日記の続きだが、鶴亀メールのサポートフォーラムでの作者氏の発言には続きがあって、

RFC全然読んでないです。すみません。Windowsのセキュリティ関係のAPIの説明だけ読んで作っているし、さらに言うならテストも不十分です。というのは、意図的に不正な証明書を作るテストをしてないです。

不正な証明書とか、不正な認証局とかを意図的に作るのって、難しいような…。（略）

鶴亀メールβテストサポートフォーラム／鶴亀メール・バグ関係

と書かれていた。

不正な証明書を作る作業は、正当な証明書を作ることと何ら違いがないのだが、そのことがあまり理解されていない様子がある。

証明書の元となる公開鍵暗号の鍵ペア（秘密鍵と公開鍵）の生成は、乱数をもとに生成するわけだが、これは、特殊な権限がなくても誰でも自由にできることであり、opensslなどのコマンドを使ってできる。

これは、SSLのサーバ証明書などを用意するときに、サーバ管理者が自分で行うべき操作であり、「サーバ証明書 openssl」などで検索すれば、その方法を解説しているページが多数見つかる。

生成した鍵ペアを証明書にするには、認証局に署名をしてもらうわけであるが、これも opensslコマンドを使って誰でも自由にできる。それは、テスト用に用意されている機能だ。

自分で認証局証明書を作ることも、opensslコマンドを使って可能であり、ルート認証局は自己署名の操作をすればよい。

つまり、証明書が正当なものであるか不正なものであるかは、証明書を作り出した時点で決まるものではない。証明書が正当であるかどうかは、その証明書を使う側の人が、ルート証明書を「信頼済み」として証明書ストアに登録しているか否かの違いでしかない。

たとえば、ベリサイン社が発行した本物の証明書であっても、ユーザが、証明書ストアからベリサインの認証局を削除しているならば、そのユーザにとってそれは「不正な証明書」であるのと何ら違いがない。

総務省の電子申請システムの解説でさえ、そういったことをわかっていない人によって書かれていたことがあった。

上記のようなブラウザのサイトの信用性に関する表示については、誰が正しいと主張しているかを常に確認するようにしましょう。

（略）

総務省以外のサイトで、「ＭＰＨＰＴ　Certification　Authority」という名称の認証局が認証するサイトはあり得ませんので、このような表示が出た際には、サイトへの接続を中止するとともに、総務省に対しＵＲＬ等情報を提供いただけるようお願いします。

総務省「安全な通信を行うための証明書について」（2002年12月の時点で掲載されていたページ）

認証パスが確認できないときに現れる警告について、「誰が正しいと主張しているか」など、信用性になんら関係がない。「誰が」の部分には任意の文字列を誰でも自由に書き込めるのだということが理解されていなかった*9。

こうした観点でのPKIの解説というのはあまりみかけない。

PKIの解説というと、正常なケースでどうして真正性が確認されるかという説明であったり、証明書の正しい作り方の手順の説明だったり、あるいは、テスト証明書を使ったテストの方法の解説だったり、そういうのばかりしかないように思える。

そうした正面からの解説では事の本質が理解されにくいようなので、「こういう誤解をするな」という形式での解説が必要なのではなかろうか。

*1 「example.com」ドメインは、誰にも取得できないドメイン名として予約されたものであり、このように例示のために使ってよいものとされている。当然ながら、このメールアドレス宛てのメールを受信することは誰もできないのであるから、このメールアドレスを発信者としてS/MIME署名されたメールなどというものは、本来は存在し得ないはずである。

*2 自動で失効確認の検査がされている可能性もあるが確認していない。

*3 Windowsの証明書管理ウィンドウで「ほかの人」というタブで示されたところ。ここに登録すると、その相手へ、その公開鍵を使って暗号化メールを送ることができるようになる。

*4 フィッシング詐欺師の証明書を、事前に証明書ストアに事前に入れている人など、いないのだから。

*5 ここには、メールアドレスを表示するべきではなかろうか。

*6 誤って偽と判断されるメールを普段から送ってくる相手のメールを、警告が出ても本物と信じるようになってしまうことがあるという点では、安全性を損なっていると言えなくもないが。

*7 6月24日に作成されたファイルが配布されている。

*8 購入ページに、「アップデートモジュールのダウンロードはこちら」というリンクはあるものの、これは、「/R.2」への無償アップグレードの紹介をしているだけだ。

*9 総務省電子申請・届出システムのこの珍解説は現在では撤回されているが、「誰が正しいと主張しているか」で検索してみると、いまだにこの間違った文章を掲載しているページがあるのがわかる。(1)国家公務員人材バンク求人登録サイトでの解説 (2)内閣府電子申請・届出システムでの解説

本日のリンク元 TrackBacks(32)

高木浩光＠自宅の日記

■ 臨時エントリ

■ はてなから移転

■ おやくそく

■ 経緯

■ このページが発行するcookieについて