最新 追記

高木浩光@自宅の日記

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

2004年10月02日

「一切の著作権その他知的財産権」という定型句

私としても、たまたま発見したこの件について、この状況でどのようにするのがよいのかいろいろなケースを想定して悩んだ上で、適切な解決のためにはこうするのが最善であるとの結論に至り、以下のことを日記に書き留めておくしだいです。

7月20日の夜、次のことに気付いた。Webページの日本語文に読み仮名をふって表示するWebブラウザソフト「れじぶら」が、「KAKASI」を使っている。このことはインストールしたディレクトリ(図1)を見て気付いた。

図1: 「れじぶら」のインストールディレクトリ

「KAKASI」はGPLで配布されているプログラムであるが、「れじぶら」には、インストーラの画面においても、配布ページにおいても、インストール後のディレクトリにおいても、GPLに関する記述はみあたらず、「KAKASI」を使用しているという説明もない。同梱のファイル「license.rtf」には次のように書かれている。

(略)

2.知的財産権

(1) 当センターは、本ソフトウェアの一切の著作権(プログラム・画像・ドキュメント等を含む)、その他知的財産権を保有しています。

(2) ご利用の皆様は、本ソフトウェアまたはそれらに包含される内容(コンテンツ)を、一部あるいは全部を問わず複製、公開、送信、頒布、貸与、翻訳、翻案、使用許諾、転載、再利用、修正、改変、表示、上映、出版、二次的著作物の作成、譲渡あるいは販売しないことに同意するものとします。

3.禁止事項

(1) ご利用の皆様は、本ソフトウェアについて、修正、改変、二次利用、譲渡または再利用許諾を行うことはできません。

(2) ご利用の皆様は、本ソフトウェアについて、リバースエンジニアリング、逆コンパイルまたは逆アセンブルを行い、またはその他の方法でソースコードを解読することはできません。

(略)

れじぶら 使用許諾契約書, 国立教育政策研究所教育研究情報センター

これと同様の文は、「れじぶらのダウンロード」のページに現在も記載されている(図2)。

図2: 「れじぶらのダウンロード」<http://www.nicer.go.jp/legibler/download.html>より引用

「れじぶら」がどのように「KAKASI」を使用しているのかについて、「れじぶら」の前身である「れじぶる」というソフトウェアについて書かれた、以下の論文で知ることができた。

  • 榎本聡,室田真男,清水康敬, 漢字かな自動変換機能等を備えたインターネット学習システムの開発, 電子情報通信学会論文誌, Vol.J83-D1, No.3, pp.384-394 (2000年3月).
    漢字かな変換を行うことができるソフトウェアとして、kakasiが公開されている。kakasiは、「最長一致法」という手法により、日本語の分かち書きを行い、漢字かな混じり文をひらがなやカタカナ、ローマ字変換することができる。付属する辞書のkakasidictには、「漢字」とそれに対する「読み」がテキスト形式で登録されている。

    本システムでは、kakasiを改良して学年別漢字かな変換機能を実現した。なお、kakasiはGNU Public Licenseのもとで改変が認められているソフトウェアである。

    2.2.2 学年別漢字かな変換辞書

    公開されているkakasiとkakasidictでは、入力された文章をすべてひらがなにすることしかできない。漢字表記レベルに応じた変換を実現するために、学年別の漢字かな変換辞書を作成した。

    学年別漢字かな変換辞書は、既に習得した漢字の「読み」の部分を漢字に置き換えることにより作成した。学年による習得漢字は、学年別漢字割当表[9]及び常用漢字表[10]をもとにした。図4にその一部を示す。

    (略)

    この変換のために、kakasi 2.2.5を改良した。kakasiは、ローマ字変換の機能も実現するために、変換後の表記に漢字が含まれることを許していない。そこで、kakasiのソースファイルにおける、辞書の「読み」の部分(略)にかな以外の文字が含まれているかどうかをチェックする部分を取り除いた。

    また、インターネット上の任意の情報に対して、漢字かな変換を実現するため、漢字かな変換プログラムをCGI (Common Gateway Interface) アプリケーションにすることにより、WWW上から利用できる「漢字かな自動変換機能」を実現した。

このコンテンツ変換ゲートウェイは、「れじぶる」という名称で以下のURLのページで運用されている。

http://www.nicer.go.jp/cgi-bin/legible/legibleNC/index.cgi

「れじぶる」のプログラムは配布されなかったようで、ゲートウェイサービスのために使うのは、(同じくGPLで配布されている)NamazuをWebサイトで使うのと同じことだから、GPL上、適切な利用である。

それに対して「れじぶら」は、「れじぶる」と同じ機能をWebブラウザとして提供する(クライアント側で独立して動作するプログラムとして提供する)ものとして後に製作され、インストーラの形で配布されるようになった。

このような改変著作物の配布形態が、「KAKASI」の著作者の許諾を得てのものかどうか、7月21日から26日にかけて、原作者の高橋裕信さんに連絡をとって確認した。(「KAKASI」の配布物には、高橋さんの連絡先が古いものしか記載されていないため、当初、高橋さんへの連絡手段が見つからず右往左往したが、たまたま知人のつてで現在の連絡先がわかり、直接お会いしてお話する機会が得られた。)

高橋さんは、この件について個別の許諾をしていないとのことだった。「KAKASI」は、「SKK」の辞書を元にして作ったもので、「SKK」がGPLでの配布となっていたため、必然的に「KAKASI」もGPLでの配布となったのであり、「GPLに従って利用してくだくしかないです」とのことだった。自分だけの著作物ではないのであり、皆でGPLの下で発展させてきたものだから、自分の一存でGPLに従わない利用を許諾することはあり得ないということだった。

高橋さんからうかがったところによれば、「SKK」の辞書は、毎年たくさんの協力者達による辞書の提供を受けて、次第に語彙が充実させられていったものなのだそうだ。まさにGPLの考え方に則って、皆で少しずつ協力して利益を得て共有するという、GPLに相応しいプロジェクトだったようだ。「KAKASI」では、第二水準漢字の読みを整備したり、たくさんの提供者からの辞書を統合する作業など、大変な手間がかかったとうかがった。

「れじぶる」の論文の図によれば、「れじぶる」は、「KAKASI」の辞書をそのまま幼稚園および小学校1年用の辞書として使い(すべてがひらがな)、そこから自動変換で派生させた辞書「1nen_dict」を小学校2年用として使う(辞書内の小学校1年で習得する漢字のエントリについてひらがなが漢字に置き換えられている)という仕組みのものらしい。「れじぶら」のインストールディレクトリの「dict」の中もそのようになっている(図3)。

図3: 「れじぶら」のインストールディレクトリ

このようにして作られた辞書およびプログラムからなる二次的著作物を、ソフトウェアパッケージとして配布するにあたって、

本ソフトウェアの一切の著作権(プログラム・画像・ドキュメント等を含む)、その他知的財産権を保有しています。

一部あるいは全部を問わず複製、公開、送信、頒布、貸与、翻訳、翻案、使用許諾、転載、再利用、修正、改変、表示、上映、出版、二次的著作物の作成、譲渡あるいは販売しない

とするのは、あまりにもあんまりだと思う。

高橋さんは、7月末ごろに第三者を通じて、「れじぶら」の配布者で「れじぶる」論文の著者である、国立教育政策研究所教育研究情報センターの清水康敬センター長に、どういうことなのかと打診したそうだ。そうしたところ、配布を中止して近いうちに謝罪するとのことだったそうだ。

たしかに、8月上旬にサイトを見に行ったところ、「れじぶらのダウンロード」のページは、「メンテナンス中のため、現在ダウンロードを中止しております。」という表示に変わっていた(図4)。無事に円満に解決しそうだとホッとしていた。

図4: 「れじぶらのダウンロード」<http://www.nicer.go.jp/legibler/download.html>より引用

ところが、それから2か月が経過した現在も変化がない。著作権表示はそのまま今も掲示されている。

先日高橋さんにお会いして、どうなりましたかときいてみた。すると、先方からの説明の連絡は一度もないのだという。先方から説明の連絡があってしかるべきだから連絡を待っているとのことだった。だが、この様子だとこのままフェードアウトになりそうだと、ふたりして心配になった。そもそも配布中止の理由が「メンテナンス中」というところからしておかしい。

センター長の清水康敬先生は、文化審議会著作権分科会の委員も務められ、特に、著作権法改正で「教育機関等での著作物活用の促進」を盛り込むべく、かねてより「コンピュータ、インターネット等を活用した著作物等の教育利用に関する調査協力者会議」などを通して多大なる貢献をなされた方で、著作物の利用のあり方等には大変造詣の深い先生でいらっしゃる。

今後についてはGPLに従っていただくとして、これまでの件を解決するには、どのような誤りがあったのかを正確に認めて自ら公表していただければよいと、高橋さんはお考えのようだ。清水先生ならば必ずや適切に事後処理なさるはずだと思いたい。

ところで、文化庁のサイトで「GPL」で検索してみても一件もヒットしない。文部科学省のサイトでも2件しかヒットしない。プログラムの二次利用文化について、著作権法を預かる文化審議会でどのように認識されているのか知りたいと思った。

本日のリンク元 TrackBack(0)

2004年10月04日

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

7月15日の日記では、不正アクセス禁止法の立法上の不備として一部法学者が主張する、「『電子計算機の利用』とは有体物としての電子計算機の利用を指し、個々の情報処理を指すと解釈することはできない」という考え方があることを確認し、続く7月18日の日記では、法案を作成した警察庁関係者によって書かれた書籍「逐条不正アクセス行為禁止等に関する法律」から立法者の意図を推定した上で、「制限されている」の定義が不明だということを書いた。

さて、推定される立法者の意図に沿ってこの法律を読むとき、(差別的表現としての)「理系的」思考で3条2項の2号を読むと、「制限されている」の定義とは別に、何か変だと直感するはずである。変だと感じるのは法律の読み方を知らないせいで、法律とはそういうものなんだろうと郷に従い、考えるのを避けてきたが、どうもそういうことではないらしい。

変だと感じた原因を突き詰めていくと、「アクセス制御機能」が複数ある場合についての規定の曖昧さにあることがわかる。

一般に「理系的」思考では、どんなものであれそれが複数あるうちの一つのことを言っているのか、全部のことを言っているのか、一つしか存在しないそれのことを言っているのかを常に意識し、複数ある場合には帰納的理解を試みようとするものだが、この法律には、2つ以上のアクセス制御機能が存在する場合についての直接的な記述がない。

第3条に「アクセス制御機能を有する特定電子計算機に電気通信回線を通じて」という文があることから、アクセス制御機能は1個存在するか、または0個存在するのいずれかであると想定しているようにも読める。もちろんそうとは限らないわけだが、実際に、法曹の人たちが、「アクセス制御機能はあったのか?なかったのか?」という点だけに注目してしまう現実がある。

アクセス制御機能が複数存在する可能性は、3条2項1号を理解するうえでは、問題にならない。なぜなら、1号違反行為では、識別符号を入力するのであるから、その入力を受け付けた「アクセス制御機能」が1つ存在し、それだけが構成要件となるのだから、他にも「アクセス制御機能」があるかどうかは関係がない*1

ところが、2号、3号を理解しようとするときには、「当該アクセス制御機能による利用の制限を免れることができる情報」の、「アクセス制御機能による制限」というのが、「すべてのアクセス制御機能によって制限されている」――(A) という意味なのか、「少なくともひとつのアクセス制御機能により制限されている」――(B)という意味なのか、どちらなのかという疑問がわいてくる。

この点を明確にするため、不正アクセス禁止法の内容を数理的に記述することを試みたが、1つの解釈には定まらないためうまく結果を出せなかった。以下では図を用いた直感的な理解の試行により、その曖昧さを明らかにすることを試みる。

まず、「アクセス制御機能」と、それによって「制限された利用」を以下の図で表すことにする。

箱の底辺は、その電子計算機に存在し得るあらゆる「利用」の集合を表し、赤線部分は、アクセス制御機能によって利用の制限が解除されるという条件を満たす部分集合を表している。

次の図は、1つのアクセス制御機能が複数の利用権者についての制御をしている場合を表したものである。

黄色と橙色が異なる2つの利用権者を表し、それぞれが赤色の部分集合と、青色の部分集合の要素である利用を可能にする。

このとき、赤色と青色は共通部分を持ち得る。具体例で考えてみると、このアクセス制御機能がUnixのログイン機能であるならば、「ファイル 『/usr/include/stdio.h』の読み出し」という利用がこれに相当する。ログインしないと利用できないという意味でこのアクセス制御機能により利用が制限された利用であり、かつ、ユーザAでログインしたときでも、ユーザBでログインしたときでも利用の制限が解除される利用である。

赤には含まれるが青には含まれない利用の例としては、ownerがユーザAで、permissionが「rw-------」と設定されたファイル(通常、ユーザAのホームディレクトリに置かれることが多い)の読み出しなどが該当する。

不正アクセス禁止法には、2条3項で、「当該特定利用の制限の全部又は一部を解除するものをいう」という文章が現れるが、「一部」というのは、このように、赤には含まれるが青には含まれない利用が存在するのであるから「一部」となるわけで、1つのアクセス制御機能において複数の利用権者が存在する場合を想定していることがうかがえる。

次に、複数のアクセス制御機能が付加されている場合を考えてみる。

この図は、2つの異なるアクセス制御機能が司るそれぞれの利用権者(黄色と橙色)によって利用の制限が解除される利用を、赤と青で表したものである。一般的には、この図のように、赤と青の共通部分が存在し得るであろう。

ここで、誰でも利用できる利用、つまり「アクセス制御機能により制限されていない利用」がこの図でどのように表せるのかを考えてみる。

誰でも利用できる利用とは、例えば、HTTPサーバで公開されているWebコンテンツの閲覧であったり、SMTPサーバへの接続などである。さらには、loginプロンプトを表示させる処理や、誤ったパスワードを入力してエラーを表示させる処理なども、どのアクセス制御機能によっても制限されていない「利用」であろう。

そうした利用を可能にするには、何らかの「サービス」が電子計算機上で稼働していなくてはならない。Unixでは「daemon」などと呼ばれる。しかし、それに該当する言葉は、不正アクセス禁止法の法文上には全く現れない。そこをどう理解すればよいだろうか。

そもそも、もし、単純に「アクセス制御機能とは利用を制限するものである」と理解するならば、そのアクセス制御機能が存在しないことは、その利用の制限がないのであるから、「可能な利用の範囲はより広くなる」と導いてしまう。それは全くおかしい。何の機能も備えていない電子計算機では利用できる利用は何一つないはずであり、そのことに矛盾してしまう。

結局のところ、不正アクセス禁止法における「アクセス制御機能の付加」とは、利用を制限するだけでなしに、同時にサービスの稼働もさせることを暗に前提としていると考えるしかない。

つまり、以下の図で表すように、1つのアクセス制御機能には必ず1つのサービスも付随しており、まずサービスが稼働することによって、ある範囲の利用集合が(便宜上一時的に)可能になったところへ、アクセス制御機能本体が即座に働くことによって、その利用集合の全部または一部*2が一旦利用を制限され、後に利用権者の識別符号が入力されると「入力された符号が当該利用に係る識別符号であることを確認して当該利用の制限の全部又は一部を解除する」という動作をするのだ――とみなすのが妥当であろう。

逐条解説においては、

オ 「当該利用の制限の全部又は一部を解除する」とは、当該利用をすることができるようにすることである。

明文で規定はしていないが、アクセス制御機能については、識別符号等が入力されない状態では利用が制限されていることが前提となっている。

逐条不正アクセス行為禁止等に関する法律, p.54

と書かれているが、さらに明文で規定されていないこととして、アクセス制御機能が付加されることは、当該アクセス制御機能で制限しようとする利用の全部を一旦利用可能にするサービスを稼働させることを前提としているのである。その上で、識別符号が入力されない状態で、その全部の利用が制限されていることを前提としている。

そのように理解すると、誰でも利用できる利用、つまり「アクセス制御機能により制限されていない利用」は、以下の図で表すのが妥当であるように思える。

つまり、それはアクセス制御機能の特殊なケース(常に1つの利用権者で識別符号の入力なしに利用可能な状態)とみなせる。

これを裏付けるものとして、逐条解説に次の記述がある。

エ 識別符号は、「当該利用権者等を他の利用権者等と区別して識別することができるように」付されるものでなければならない。(略)

利用権者等が一人しかいない場合、すなわちアクセス管理者以外に電子計算機の利用に係る許諾を得て利用をする利用権者をおよそ予定していない場合には、当該利用の際に自分が用いるID・パスワードをアクセス管理者が設定していたとしても当該ID・パスワードはアクセス管理者を他の利用権者と区別して識別することができるように付されているわけではないから、当該ID・パスワードは識別符号に該当しない。

電子計算機の利用の一部(例えばホームページの閲覧)についてはすべてのネットワーク利用者に許諾し、その他の利用全体はアクセス管理者のみがID・パスワードを入力して行うような場合には、利用権者等は複数存在し、符号によりアクセス管理者を他の利用権者と区別して識別することができるから、当該ID・パスワードは識別符号に該当する。

逐条不正アクセス行為禁止等に関する法律, p.40

これによると、「ホームページの閲覧」という誰にでも利用できるようにした利用についても、その利用者を利用権者とみなすという考え方があり得るらしい。まさに、上の図のように、識別符号による利用の制限の解除を予定しないで(利用を制限しないで)サービスだけを提供するアクセス制御機能(の特殊形)と捕らえることができる。

では、上の逐条解説からの引用部分にあるように、アクセス管理者が一人いて、「ホームページの閲覧」というサービスが提供されている状況を図に表すとどうなるだろうか。

まず、以下のように考えてみた。左のアクセス制御機能が管理者のためのもので、右の(擬似)アクセス制御機能がWebサーバを表す。

ここで、Webサーバで公開されるファイルの読み出しという利用は、ネットワーク利用者が右の擬似アクセス制御機能(公開サービス)を通して利用するのみならず、コンテンツ管理者が左のアクセス制御機能にコンテンツ管理者の識別符号を入力して利用することもできる。すなわち、図のように、赤色と青色が重なった部分の利用が存在する*3

この重なった領域をどのように考えるべきだろうか。公開サービスによって利用可能な利用が「アクセス制御機能によって制限されている利用」とは言えないのだとすると、次の図のように修正されるべきであろう。

こちらの図の考え方は、利用について、利用の手段を問わないという前提をおいている。つまり、あるファイルのデータを取得するにあたり、Webサーバ経由でアクセスしているのか、コンテンツ管理者用識別符号を入力してアクセスしているのかに関係なく、同じ「利用」であるとみなしている。そのため、青色部分の利用のすべては、左のアクセス制御機能によって「制限された利用」とはなり得ないことになる。

では、利用の手段を問わずに同じ利用だとみなすことが、この法律の意図したところかどうかというと、3条2項の2号および3号で、「利用の制限を免れることができる情報又は指令を入力して(略)その制限されている利用をし得る状態にさせる行為」という規定があることから、利用の手段を問わずに同じ利用だとみなしているとしか考えられない*4

そのように整理してみると、3番目の図、

はちょっとおかしいということになる。「2つの利用権者に共通の制限された利用」とある部分は、右のアクセス制御機能に識別符号が入力されてある利用権者に利用可能になっているときには、左のアクセス制御機能で利用が制限されていないことになってしまう。

この時点で既にこの法律のほころびが見えてきたような気がするのだが、ひとまずこれはおいておく。

次に、3条2項2号の行為、すなわちセキュリティホールを突いて制限された利用をし得る状態にするという状況を図にしてみる。

このように、例えばバッファオーバーフロー脆弱性を突いてroot権限を得たような場合は、ほとんど全ての利用(青色の部分)がし得る状態になる。

root権限を奪取したが何の利用もしなかった行為であっても、この法律はそれを罰するものであるが、上の図の青色の領域が、アクセス制御機能が制限している利用である赤色の領域に重なっているかどうかが、構成要件の一つとなっている。

セキュリティホールには他にも色々の種類があり、次の図のように、ごく狭い範囲の利用だけが利用し得る状態になるものもある。

もし、青の領域が、赤の領域*5に重なっていない、つまり以下の図のような場合は、構成要件を満たさないことになるはずである。

つまり、この電子計算機にはアクセス制御機能が1つだけ付加されているが、そのアクセス制御機能のどの利用権者の識別符号を入力しても利用可能にならない利用を、セキュリティホールを突いて利用可能にしたとしても、不正アクセス禁止法違反にならないことになってしまう。

これはどうなのか。

不正アクセス禁止法 罪数の矛盾?

ここまで整理したところで、次の図を考えてみる。

このセキュリティホールは、「制限されている利用をし得る状態にさせる」わけであるが、その「制限されている利用」の制限する主体は、法文に「当該アクセス制御機能による利用の制限を免れることができる情報又は指令」とあるように、「当該アクセス制御機能」であるわけだが、それが、図中のAのアクセス制御機能を指すのか、Bのアクセス制御機能を指すのか、という疑問が出てくる。

ここは、AとBが対称であることから、両方が該当するとしか考えられない。

ところで、逐条解説には、第八条の解説の部分で次のように書かれている。

6 罪数

(1) 不正アクセス行為の罪数

不正アクセス罪は、アクセス制御機能に対する社会的信頼の侵害に着目してこれを処罰しようとするものであり、他人の識別符号等を電子計算機に入力してアクセス制御機能により制限されている利用をし得る状態にすることで成立する。 したがって、不正アクセス罪は、アクセス制御機能を単位として成立すると考えるのが相当である。アクセス制御機能の単位は、これを付加したアクセス管理者ごとに判断されるべきものであり、具体的には次の通りであると考えられる。

ア 一のアクセス管理者が電子計算機に付加した一のアクセス制御機能を侵害すれば、一の不正アクセス罪が成立することになる。

ところで、一のアクセス管理者が電子計算機に付加した一のアクセス制御機能が、同一機会に連続して二回以上にわたり侵害されることも考えられるが、その場合にも、不正アクセス行為に該当する行為は複数回行われてはいるものの一のアクセス制御機能が侵害されるにとどまるものであることから、一罪として処断されるべきである。

この場合、不正アクセス行為の手段として入力される識別符号等が同一でなくとも一罪として評価できるものと解する。 例えば、(略)

イ 一の電子計算機に付されたアクセス制御機能であっても、二以上のアクセス管理者が各別に付加したアクセス制御機能であれば、それらが順次侵害されれば、それぞれについて不正アクセス罪が成立することになる。 例えば、一のISPのユーザA、Bが当該ISPのWWWサーバにそれぞれホームページを開設し、Aが会員制のインターネット・ショップを、Bが会員制の有料コンテンツ事業を営むためにそれぞれのホームページの閲覧についてアクセス制御機能を付加した場合には、これらのホームページに各会員の識別符号を盗用して順次アクセスすれば、各別に不正アクセス罪が成立することになる。

また、(略) ウ 同一の者が付加したアクセス制御機能であっても、各別の立場から付加されたものに対して不正アクセス行為が行われた場合には、アクセス管理者としては同一であると評価できないことから、それぞれについて不正アクセス罪が成立する。

例えば、(略)

逐条不正アクセス行為禁止等に関する法律, p.146

このことから、上の図で、AとBの二つのアクセス制御機能があるが、このアクセス制御機能を付加した者(それぞれのアクセス管理者)が同一であれば一罪であり、別々であるなら二罪ということになる。

ここで不可解なことが生ずる。

上の図のケースのように、一つのセキュリティホールを突いて、緑色の領域で示した「利用」を一回だけし得る状態にしたとき、それによって、二つのアクセス制御機能(に対する社会的信頼)を侵害したことになるのである。

具体例で考えてみる。

あるレンタルサーバ屋のホスティングサービスを使ってWebサイトを開設している会社Aがあるとする。会社Aは、レンタルサーバ屋から、

/usr/local/apache/public_html/company_A/
の場所にコンテンツを置くよう指示された。ここに置いたファイルがWebサイトのコンテンツとして公開される。ファイルの設置には、FTPを使ってアップロードするように指示された。

次に、ショッピングカートをCGIとして設置した。その場所は、

/usr/local/apache/cgi-bin/form.cgi
で、これはレンタルサーバ屋が作成して自由に使わせているものだった。このCGIで受け付けたデータは、
/usr/local/apache/public_html/company_A/data/order.csv
に保存するようにし、「http://company_A.com/data/」にアクセスがあったときにはパスワードによるアクセス制限がかかるよう、会社Aの担当者がBasic認証の設定をした。

このとき、このCGIにセキュリティ上の欠陥があって、ある方法で、任意のパス名のファイルを読み出せる状態だったとする。攻撃者がその方法を使って、

/usr/local/apache/public_html/company_A/data/order.csv
を読み出したとする。

さて、この行為は、どのアクセス制御機能(に対する社会的信頼)を侵害したことになるだろうか?

上の図で抽象的に検討した通りであれば、この行為は、レンタルサーバ屋が付加したアクセス制御機能(FTPサーバ)と、会社Aの担当者が付加したアクセス制御機能(Basic認証)の両方を侵害したことになる。

「order.csv」というファイルを読み取ったことから、「直感的に最も近い」位置にある会社Aの付加したアクセス制御機能が侵害された感が強いかもしれないが、この法律はそうした感覚による罪の大きさの違いの存在を予定していない。第3条2項は、実際に利用をしたかを構成要件としておらず、利用をし得る状態にした段階で処罰しようとしている。したがって、「order.csv」というファイルを読んだことは、罪の判断に何ら関係がない。「order.csv」が読めたということは、FTPサーバのアクセス制御機能による制限も回避したことになるし、Basic認証による制限も回避したことにもなる。

よってこの行為は、二罪と評価されるしかないことになる。

次に、この同じレンタルサーバ屋に、別の会社BもAと同様に契約してWebサイトを開設していたとする。会社Bも、

/usr/local/apache/public_html/company_B/data/
にBasic認証をかけている。

このとき、CGIプログラム「form.cgi」が、apacheのowner権限で稼働するものであるため、「form.cgi」のセキュリティ欠陥を突いた任意パス名のファイルの読み出しの行為では、

/usr/local/apache/public_html/company_A/data/order.csv
/usr/local/apache/public_html/company_B/data/order.csv
も、両方とも読み出せるのだとする。

この場合に上と同じ行為が行われると、これは三罪ということになる。たとえ、「company_A/data/order.csv」だけを読んだのだとしても、どのファイルを読んだかは関係がなく、その直前にform.cgiで読み出し可能な任意のパス名のファイルを読み出し可能な状態にさせたわけであって、そこが罪に問われているのだから、「company_B/data/order.csv」の読み出しという利用もし得る状態にさせたわけであるから、会社Bの付加したアクセス制御機能(に対する社会的信頼)をも侵害したことになるはずである。

ということは、そのレンタルサーバ屋の同一の電子計算機内に100の会社が同じようにWebサイトを開設していたとすると、101罪ということになる。

これはいくらなんでもおかしいのではないか?

とすると、どこが間違っているのだろうか。

form.cgiを使って「company_A/data/order.csv」を読み出した行為が、どの範囲の利用をし得る状態にしたかについて、「company_A/data/order.csv」の読み出しという利用だけをし得る状態にしたと評価するべきなのだろうか? それはどのような理由によるものなのか?

攻撃者が突いたセキュリティホールが、apacheのバッファオーバフロー脆弱性だった場合はどうか。シェルを起動し、それ以上は何もしなかったとする。この法律は、それだけで罪に問うものであるから、それによってどの範囲の利用をし得る状態にさせたかが問われる。シェルを乗っ取ったわけであるから、何でもできよう。会社AのBasic認証で保護されている「company_A/data/order.csv」も読めたであろうし、会社BのBasic認証で保護されている「company_B/data/order.csv」も読めたであろう。100社が利用しているサーバならば、101罪と評価しなくてはならないはずである。これとCGIの場合とで、何が違うというのか?

この推論から得られる結果が、常識からかけ離れているように感じられるのは、「company_A/data/order.csv」を読み出した行為者が、他の99社のBasic認証のアクセス制御機能の存在を認識していなかったであろうと推察されるからではないだろうか。

一般に刑罰を科すには、行為者に故意が認められなければならないのだそうだ。「company_A/data/order.csv」を偶然にでなく読み取った行為者は、(行為に至るまでの背景しだいでは)会社Aの付加したアクセス制御機能による制限を免れようとする故意を持って行為に及んだと解されるだろう。しかし、存在自体を知らない、会社Bやその他98社の付加したアクセス制御機能による制限については、免れようとする故意はなかったと解されるのかもしれない。

そのような法理解が正しいのだとすると、アクセス制御機能(に対する社会的信頼)を侵害したことを罪を問う不正アクセス禁止法は、行為者がそのアクセス制御機能の存在を認識していたことが要件となるはずである。さらには、存在を認識した上で、自分の行為がそのアクセス制御機能によって制限されている利用をし得る状態にさせるものであることを認識している必要がある。

となると、次の場合はどうだろうか。上のレンタルサーバ屋の事例で、攻撃者がform.cgiを使って読み出したのは、

/usr/local/apache/cgi-bin/form.log
だったとする。行為者は、会社Aが付加したBasic認証のアクセス制御機能の存在を知らなかった。

行為者の認識が以下のどれだったかが鍵になるということになるだろうか。

黄色はレンタルサーバ屋が用意したFTPサーバに対する誰かのログインを示す

*1 2号、3号では「識別符号であるものを除く」とされているので、1号違反が同時に2号、3号違反にもなることは起こり得ない。

*2 Apacheが稼働しているところへBasic認証というアクセス制御機能を付加する場合は、Apacheというサービスの存在を前提としてBasic認証があるのであり、Basic認証の付加はサービスの一部を制限するものととらえる。

*3 黄色の利用権者がこの電子計算機全体の管理者であるならば、青色部分の全部が赤色部分に重なるが、他のコンテンツ管理者も存在し得るのであるから、一般には、赤に重ならない青も存在し得る。

*4 (telnetでログインしてファイルを読む行為と、バッファオーバーフロー脆弱性を突いてファイルデータを引き出す行為とを、同一の利用だとみなさない限り、「アクセス制御機能により制限されている利用をし得る状態にさせる」という2号、3号の規定は成り立たない。

*5 正確には、このアクセス制御機能が司るすべての利用権者の領域の和集合。

本日のリンク元 TrackBack(1)

2004年10月07日

あさって土曜の「ウェークアップ!」でランドセルのICタグ

讀賣テレビの「ウェークアップ!」(日テレ系毎週土曜日朝8:00〜9:25)で、近頃流行のランドセルにアクティブタグの話が扱われるもよう。

どんな論調になるだろうか。

本日のリンク元 TrackBack(0)

2004年10月10日

実は安物なのだと知らされた淑女達の自尊心は傷つくか

昨日は「越後湯沢ネットワークセキュリティワークショップ」に行っていたので、「ウェークアップ!」の放送は温泉宿のテレビで見た。前日の夜に宣伝しておいた何人かの方や、たまたまテレビをつけていて見たという、ワークショップ参加者の方々から、口々に「安全じゃないと言っているのに、コメンテータは違う話をしていた」と惜しむ声が聞かれた。

たしかにその通りで、残念ではあったが、仕方なかったかもしれない。これは、直前に勤務先に取材申し込みがあり、直前に都内の勤務先で撮影したものだった。

まず、収録時に私が話した内容は以下の通りである。事前に原稿を書いて論点を整理しておき、この通りにいっきに話した。

タグには2種類あります。
読み取り機にかざして使うタイプと、
アンテナが勝手に読み取ってくれるタイプです。
かざして使うタイプでは、
読み取り機からの電波を受け取ると、返事をする仕組みですが、
かざさないタイプでは、
タグが電池を内蔵していて、常時電波を発信し続けます。
学校の門に来たときだけ電波を出すわけではなく、
街中を歩いているときも、電車に乗っているときも、
家の中にいるときも、電波を出し続けます。
電池内蔵型では電波の届く距離は10メートルから数十メートルにおよびますから、
少しはなれたところにいる第三者でも読むことができます。
電波の受信機さえあれば誰でも読めるわけです。
もし裕福な家庭が通う学校だけがランドセルにタグをつけていたら、
悪い人が、受信機を使って、どっちの方向に子供がいるかを探知するかも
しれません。
番号だけだから個人情報ではないと言いますが、
常に同じ番号を出しているわけですから、たとえば、
この家の子供を狙おうと思った悪い人は、
夜のうちに家の外から電波を受信して番号を確認しておいて、
あとは、登下校の時間に、
同じ番号を発信する子供が数十メートル以内に入るのを待つ
ということもできてしまいます。

そういうことができないように、暗号化する対策が必要です。
昨今の実験で使われているタグに暗号機能があるかどうか、
説明されていません。
父兄の方々は、こうしたリスクもあることを知った上で、
本当に便利かどうか検討する必要があります。

もちろん、これ全部が採用されるとは思っていない。一般に、こうしたコメント収録取材の場合、映像に使われるのは二言までである。いきなり肝心の言葉だけしゃべるというのはうまくいかないので、このように、取材スタッフへの説明も兼ねて、一旦全部を通してしゃべった後に、ポイントを絞って要点だけを2度、3度と繰り返して撮るという方法にさせてもらった。

私としては上の強調部分が放送されたらいいなと期待したが、無理かもしれないとも思ったので、簡略化したコメントも述べ、そこが使われた。使われたコメントは以下の通り。

安全のためにタグを取り付けると、いうふうにされているわけですけれども、取り付けることによってかえって、危険も生ずるということも忘れてはならないと思います。

常時電波を出しているタグを使う場合は、電波を受信する受信機さえあれば、誰でも読み取れると。ですから、悪意ある人が勝手に電波を読み取ってですね、何か悪いことに使うのではないか、という心配もあります。

そしてこの後ナレーションが以下のように入った。

ICタグが発信する電波の範囲は所有者を中心に半径10メートル程度と言われ、常時電波を出し続けているため、第三者に傍受される危険はゼロではない。

ナレーション部分には以下のようなアニメーション(円が広がっていく)が入った。これは、先週NHKニュースが流したミスリーディングな映像の誤解を払拭するために、お願いして入れていただいたものだ。

讀賣テレビ「ウェークアップ!」2004年10月9日午前9時2分8秒より引用

この後は、街頭インタビューで、「ちょっと考えますよね、親が完全に監視するという形になるから」という40才前後の女性の言葉と、「そこまでしなくてもいいんじゃないかと思いますけどね、親子の信頼関係をなくすんじゃないかと思いますけどね」という50歳くらいの男性の言葉が紹介され、海外の事例として、仮出所中の性犯罪者の再犯を防止するため、位置情報がわかるブレスレットを付けさせ監視する実験が進んでいるという話が紹介された。

そしてこの後、スタジオのコメンテーターの議論となるわけであるが、このコーナーは、「時代の天秤」という新企画だった。そのことは聞いていなかったので、ここまではっきりと賛成派と反対派に分かれた議論にするのだとは知らなかった。

賛成派は、安全のためには仕方ないということをおっしゃるし、反対派は、「親に逆らえないで成長する子供が増えると、大人になってから何かしでかしてしまうのではないか(安全のためには仕方ないが)」といった主張になっている。

そうした議論も当然ながら必要である。

ようするに、今回のランドセルアクティブタグの事例から議論されるべき論点には、以下ように複数のものがあるのだ。

  1. 安全のためとして監視社会化しつつあるという現状認識
  2. 監視社会が人々の心に与える影響
  3. 子供の場合は監視されても仕方がないのか
  4. このシステムは本当に安全性をもたらしているのか
  5. このシステムはかえって危険性ももたらすのではないか(暗号化していない場合、暗号化していても裕福な家庭の子供だけが持っている場合)
  6. このシステムは単なる欠陥事例ではないか

企画の性質上、これら全部の論点を扱うのは難しかったのかもしれない。直前に取材があったことからしても、もともと既に、安全と監視社会という論点が予定されていたのかもしれない。

実際、コーナーの前半部分では、セコムの位置情報サービス「ココセコム」のCM映像も紹介されており、これはICタグではない*1のだが、上記の1〜3の論点は共通するものであって、その論点を中心に据えているからこそ、紹介されたのだろう。

そういう状況の中で、直前だったにもかかわらず、アニメーションも用意して私の主張を紹介していただけたのはよかった。

本当は、上の4〜6の論点も入れて欲しかったところだが、それを「賛成派 vs 反対派」という形式に構成するのは無理だったかもしれない。違う形の企画だったらよかったのだが。 ただ、ここで気になるのは、「このシステムは単なる欠陥事例ではないか」という点は、テレビ局に放送する勇気はないのではないかという懸念だ。まだ事件が実際に起きたわけではない段階で、こうした悪用の心配があるという放送は、一般に不可能なのかもしれない。

この家の子供を狙おうと思った悪い人は、夜のうちに家の外から電波を受信して番号を確認しておいて、あとは、登下校の時間に、同じ番号を発信する子供が数十メートル以内に入るのを待つということもできてしまいます。
という指摘をアニメーション付きで見せれば、かなり多くの人がギョッとするだろう。「悪用を思いつかせるようなことを言うな」という拒否反応が出るかもしれないし、スポンサーから苦情が入ることもあるかもしれない。

だが、これらの事例はいずれも実験段階なのであり、いつでもやめられるのだから、今のうちにリスクをきちんと周知するべきである。

実験小学校の母親(とされる人)は、今回も「ICタグは学校に入った出たっていうことがすぐにわかりますのでー、とっても安心です(うんうん)」とニコニコして言っていたが、

この家の子供を狙おうと思った悪い人は、夜のうちに家の外から電波を受信して番号を確認しておいて、あとは、登下校の時間に、同じ番号を発信する子供が数十メートル以内に入るのを待つ
というアニメーションを見たうえでも、そのように発言するだろうか。

ココセコムを使うならそういう心配がない(携帯電話同様に)。ただ、ココセコムには利用料金が月額800円ほどかかる。それに対して、ランドセルアクティブタグは、タグがおそらく数百円程度(2千円程度が相場?)で、学校側が用意するシステム一式が数百万円程度と、格安だろう。

ようするにこれは、安全性を犠牲にした杜撰な安物をつかまされているのだ。気品高きハイソな母親達は、そのことを知らされていないのだろう。

「最新技術」と宣伝されているが、野生動物や伝書鳩や家畜に使われてきたシステムの転用にすぎないし、人間用としてはココセコムが既にあった。人間用として必要な安全対策を取っ払った貧乏人向け低価格システムという点で「最新鋭」なだけだ。

なお、プレスリリースに記載されていた問い合わせ先(富士通パブリックセキュリティソリューション本部)に、先週、電話して確認したところ、このシステムのタグは暗号化機能を搭載していないとのことだった*2

岩邑小学校のランドセルは300メートル先から方向を検出可能?

「ウェークアップ!」の放送では、岐阜県の岩邑小学校の事例の映像も放送された。その中でこの画面があった。

讀賣テレビ「ウェークアップ!」2004年10月9日午前8時57分28秒より引用

どうやら、RF Code社のタグ「Spider Tags」または「Mantis Tags」が使われているようだ。

掲載されているデータシートには次のようにある。

SPIDER(tm) Reader can read tags at a range up to 1000 feet. The readers are able to identify the tag's position, as well as inform the host computer whenever something changes; for example, when a tag enters or leaves their range.

RF Code, Inc., SPIDER(tm) III-A Data Sheet

つまり、1000フィート(約300メートル)までの距離から読め、かつ、その位置がわかる*3のだという。

暗号に関する記述はみあたらない。

追記

国内仕様版では電波出力が抑えられているかもしれない。標準アンテナで10メートル、オプションアンテナでそれ以上とされている。FAQページには、距離をのばすことについて、「高利得なダイポールアンテナや八木アンテナを使用することにより可能です」と書かれている。

ちなみに、トップページのキャッチフレーズは、「360度の指向性と長距離通信が可能にする無意識なアイデンティフィケーション」だそうだ。

アクティブ型RFIDタグの電波の受信は電波法の傍受にあたるか

比較的よく知られているように、電波法第59条は、他人が発した一部の電波の受信について、次のように規制している。

(秘密の保護)
第59条 何人も法律に別段の定めがある場合を除くほか、特定の相手方に対して行われる無線通信(電気通信事業法第4条第1項又は第164条第2項の通信であるものを除く。第109条並びに第109条の2第2項及び第3項において同じ。)を傍受してその存在若しくは内容を漏らし、又はこれを窃用してはならない。

電波法

特定の相手方に対して行われる無線通信は、傍受(第一者と第二者が通信する傍らで第三者が受信するのだから「傍受」)と定義され、傍受するのはしかたがない*4が、それの存在や内容を漏らしたり窃用するのは違法とされている。

では、アクティブ型RFIDタグが何秒かおきに発信し続けるビーコン電波は、「特定の相手方に対して行われる無線通信」にあたるだろうか。

校門の前に立っているときのように、受信機が近くにあるときは、タグから受信機へと通信が行われているといえるかもしれないが、学校が用意した受信機のない街中などでは、予定した受信機のない状況で電波を勝手に発信しているわけであり、特定の相手方が存在しない。

これは受信しても傍受にあたらず、なにをやっても違法にならないと思うのだが、どうだろうか。

また、パッシブ型RFIDタグの場合でも、消費財に取り付けるタグでは、誰に読ませるかを制限しない(アクセス制御機能などにより)のならば、誰が読むのも自由であり、電力を供給する人(リーダの使用者)が「特定の相手方」になり、傍受にもあたらないはずだ。

このご時世、ぜひ法律家の方々に議論しておいていただきたい話題ではないだろうか。

絵師・フラッシュ職人さん求む

それにしても、NHKの映像のように、動く絵で見せることの効果は絶大だ。

私としては、

この家の子供を狙おうと思った悪い人は、夜のうちに家の外から電波を受信して番号を確認しておいて、あとは、登下校の時間に、同じ番号を発信する子供が数十メートル以内に入るのを待つ
というシーンをアニメーションで見せたいところだが、どうもテレビでは無理っぽい。

個人的立場で、フラッシュアニメなどを自力で作りたいところだが、それだけの絵心がないし、フラッシュは一度も作ったことがない。

どなたか職人さんにご協力いただくことはできないだろうか。

著作権についてはおおむね次のように考えている。

  • アニメーションのシナリオの著作権は私にあるとする。
  • キャラクターデザインや成果物そのものの著作権は作成者にあるものとする。
  • 成果物はこの日記(もしくは参照するページ)に表示する目的で使用できるものとする。
  • 私が同じシナリオで、別のキャラクターデザインを使用して作り直し、別の目的で使用することを妨げない。
  • 作成者が、このシナリオを発展させた類似のコンテンツを作り、発表することを妨げない。

ご協力いただける方からのご連絡をお待ちしております。

*1 ココセコムのセキュリティ面は、携帯電話が盗聴されないのと同程度に安全といえる。

*2 パブリックセキュリティ本部営業推進部の担当者には、確実な回答をするためとして、開発部隊に問い合わせて、折り返し連絡のうえで回答していただいたので、確かな事実であろう。なお、タグのIDが連番になっていたりはしないかという点についても同様に問い合わせたところ、使うのは、タグ内のメモリのデータではなく、タグの識別番号であり、タグをシャッフルして配布するとのことだった。それでもなお、学校単位で連番でタグを納品すると、学校が識別できてしまうことになるので、納品時からシャッフルしておく必要がある。

*3 おそらく、2個のアンテナを使うことで概ねの方向を得て、電波強度から概ねの距離を得るのだろう。

*4 暗号化された無線通信の場合は、109条の2により、秘密を漏らすないし窃用する目的で復元してはならないとされている。

本日のリンク元 TrackBacks(2)

2004年10月11日

素人がやってはいけないセキュリティの「大発明」

3週間前にBUGTRAQ-JPに以下の投稿をしたのだが、あまり周知されていないことが判明したので、あらためて日記に書き留めておく。

phishingという言葉が定着したのは英語圏では2003年の夏ごろ、日本では2004年の春ごろからのようだが、それまで「偽サイト」と表現されていた同じ手口は、思い返せば、初期のころはPayPal.comが標的とされることが多かったように思う。

Anti-Phishing Working GroupのPhishing Archiveに掲載されている2003年9月以降の手口一覧でも、142件中10件がPayPalが標的となったものになっている。

PayPalが早くから標的にされやすかったのは、ひとつには現金が直接動くということ、もうひとつは、PayPalのサービスがメールで送金するという仕組みだったからだろう。つまり、PayPalユーザは、普段からPayPalからの連絡をメールで受け取っていたため、偽のメールを不自然と思わずに騙されやすいという、詐欺被害の土壌ができあがっていたのではないだろうか。

メールで送金といえば、日本ではイーバンク銀行である。というか、イーバンクは、PayPal日本版という位置付けらしい。

  • 日本電子決済企画が国内サービスで米PayPalと提携, ASCII24, 2001年2月15日

    ネット専業銀行“eBANK(イーバンク銀行)”(仮称)の設立を目指している日本電子決済企画(株)は15日、電子メールで送金が行なえるオンラインサービス“PayPal”を運営する米PayPal社と、日本国内における業務提携で基本合意に達したと発表した。(略) “PayPal”(ペイパル)は、1999年10月にサービスを開始した電子メールによる送金サービス。オンラインオークション“eBay”などの個人の支払いから、企業間の送金にまで対応しており、(略)

  • イーバンク、メールで送金できる「ペイパル」サービスを8月開始, INTERNET Watch, 2001年2月16日

イーバンクでは、このメールで送金できるサービスのことを「メルマネ」と呼んでいる。私も使ってみたが、これはなかなか便利なようだ。

そして先月、イーバンク銀行はフィッシング詐欺対策を9月12日から実施すると発表した。

警察庁からのフィッシングに対する注意喚起があるなか、他行に先駆けてイーバンクが対策をとったのは、イーバンクがPayPal日本版だからこそではないだろうか。

他に先駆けて対策をとるのは賞賛に値するとも言えるが、逆に、PayPalが何年も前からフィッシングの標的となり続けてきたにもかかわらず、これまでずっと放置してきた(アドレスバーを隠し、ステータスバーも隠すログインウィンドウのまま)とも言える。

INTERNET Watchの記事によれば、イーバンクの言い分は、

まず、ログイン画面にアクセスした際に、イーバンクの正規のサイトであることを確認できるようWebブラウザにアドレスバーを表示するとともに、サイトの証明書を確認できるようステータスバーを表示する。従来はURLなどを見せないほうが逆にセキュリティ確保につながるとの考えから、これらの情報をログイン画面では表示しないようになっていたという。 イーバンク、フィッシング詐欺対策でログイン画面に新機能, INTERNET Watch, 2004年9月6日

と、わざとアドレスバーを隠していたかのようになっているが、ならば、ステータスバーを隠していた理由をどう説明するのか。

アドレスバーを、ましてや、ステータスバーを隠していたのを、表示するように改めたというのは、「対策した」というよりは、「欠陥を修理した」と表現するべきものだろう。しかし一般に、そういう言葉は自ら口にしたがらないものだ。

そういう状況のなかで、イーバンク銀行は、同時に「新機能」も提供開始したことで、「対策」と呼べる内容の発表にこぎつけたといえる。

その「新機能」について、INTERNET Watchは以下のように報道している。

次に、ログイン時にキーワードによるログイン方法を追加する。これは、従来からのログインパスワードに加えて、ユーザーがあらかじめ全角10文字以内の “キーワード”を登録しておくことで利用できる。この新しい方法でログインしようとすると、ユーザーが支店番号、口座番号、ログインパスワードの最初の4 文字を入力した段階でキーワードが表示される。このキーワードが正しければ、イーバンクの正規のサイトであると確認できる仕組みだ。キーワードを確認後、ログインパスワードをすべて入力すれば、口座にログインできる。

イーバンク、フィッシング詐欺対策でログイン画面に新機能, INTERNET Watch, 2004年9月6日

こうした報道の影響であろうか、日経IT Proの読者コメント欄に以下の発言があったように、「イーバンクのような作り方が必要だ」といった感想を持った情報システム技術者もいくらかあったようだ。

[2004/09/09]
セキュリティホールを突かずに広がるMyDoomウイルスが猛威を振るうのに、 SenderIDごときでフィッシングが防止できるとは思わない。ユーザは、安全性を計る物差しを持っていないと言う事実を認識すべきです。イーバンクのように、本物の見分け方を徹底させるようなサイト作りをしないとね
(40代,ユーザー企業,情報システム部門 )

読者コメント: 「送信者認証は“スパム対策”ではなくて“フィッシング対策”」――マイクロソフト, 日経BP IT Pro, 2004年9月6日

しかし、この「キーワード確認機能」はフィッシング詐欺対策にならない。なぜなら、偽サイトが、ブラウザからのアクセスの全部または一部を、本物サイトへ中継するようにすれば、完全に本物サイトど同じ挙動をする偽サイトを構成できてしまう*1からだ。

詳しいことはBUGTRAQ-JPへ投稿した文書に書いた。その全文を以下に転載する。

From: Hiromitsu Takagi <takagi@mail1.accsnet.ne.jp>
To: bugtraq-jp@securityfocus.com
Date: Thu, 23 Sep 2004 00:05:41 +0900
Subject: イーバンク銀行が導入したキーワード確認機能はフィッシング詐欺防止にならない

イーバンク銀行が導入したキーワード確認機能はフィッシング詐欺防止にならない
==========================================================================

概要
----
フィッシング詐欺に騙されないよう消費者が自衛できるための手段としてイー
バンク銀行が2004年9月12日より開始した、パスワードの前半部分の入力によっ
て、事前登録しておいたキーワードを表示させる仕組みは、これによって「正
規のサイトであることを確認できる」と説明・報道されているが、実際には、
詐欺師が偽サイト上にユーザ個別の登録キーワードを表示することは容易に実
現できるのであって、これはフィッシング詐欺を防止できるものではない。

消費者はこの種のサービスを信用してはならない。また、他の金融機関および
ECサイトが、これがフィッシング詐欺対策になると誤解して同様のサービスを
真似て導入することがあってはならない。

背景
----
9月6日のイーバンク銀行のプレスリリース「イーバンク銀行、世界的に急増す
る「フィッシング詐欺」への対策を拡充 〜ログイン時にキーワードによるサ
イト確認が可能に〜」
http://www.ebank.co.jp/information/press/2004_09_06.html
において、
| 【イーバンク独自の「キーワード」によるサイト確認】
| イーバンクサイトやショッピングサイトの購入画面からイーバンク口座にログ
| インする際、キーワードを利用したログイン方法を選択します。ログインパス
| ワードの最初の4桁を入力した時点で、お客様が 予め登録しておいたキーワー
| ド(全角10文字以内)が表示されます。このキーワードが正しければ、正規の
| イーバンクサイトであることが確認できます。

と説明されていたことを受け、報道各社は6日から7日にかけて、この機能によ
りアクセス中の画面が正規ものであると確認できるようになると報道した。

・日本経済新聞9月6日朝刊第3面
| ネット専業銀行のイーバンク銀行は、金融機関を装ったホームページを使って
| 不正に口座情報などを取得する詐欺対策を強化する。顧客が事前に登録した文
| 字を使って正規のホームページであると確認ができるサービスを業界で初めて
| 採用する。(略)
| イーバンクは自社のホームページで顧客が事前に登録した文字をいくつか入
| 力すると後続の文字を自動的に表示し、正規と確認できるサービスを月内に始
| める。(略)

・イーバンク、フィッシング詐欺対策でログイン画面に新機能, INTERNET
  Watch, 2004年9月6日
  http://internet.watch.impress.co.jp/cda/news/2004/09/06/4505.html
| イーバンク銀行は6日、PC向けの口座ログイン画面においてフィッシング詐欺
| 対策の新機能を12日より追加すると発表した。(略)
| 次に、ログイン時にキーワードによるログイン方法を追加する。これは、従来
| からのログインパスワードに加えて、ユーザーがあらかじめ全角10文字以内の
| “キーワード”を登録しておくことで利用できる。この新しい方法でログイン
| しようとすると、ユーザーが支店番号、口座番号、ログインパスワードの最初
| の4文字を入力した段階でキーワードが表示される。このキーワードが正しけ
| れば、イーバンクの正規のサイトであると確認できる仕組みだ。キーワードを
| 確認後、ログインパスワードをすべて入力すれば、口座にログインできる。 

・イーバンク銀行、フィッシング詐欺対策で新たなログイン方法を, インター
  ネットコム, 2004年9月6日
   http://japan.internet.com/finanews/20040906/5.html
・キーワードで正規サイト確認 イーバンクがフィッシング詐欺対策,
  ITmedia速報, 2004年9月6日
  http://www.itmedia.co.jp/news/articles/0409/06/news014.html
・イーバンク,フィッシング対策のためにログイン画面を変更, 日経IT Pro,
  2004年9月7日
  http://itpro.nikkeibp.co.jp/free/ITPro/NEWS/20040907/149550/

イーバンク銀行はこの新機能を9月12日からサービス開始し、以下のURLのWeb
ページで、ユーザに対して以下のように説明している。

【フィッシング対策に関する重要なお知らせ】2004年9月12日
http://www.ebank.co.jp/information/information_032.html
| イーバンク口座へのログインの際は、まず次の2点をご確認ください。
| ・画面上部のURLが、https://fes.ebank.co.jpであること。
| ・画面右下の鍵マークをダブルクリックして、表示される証明書情報の発行先
|   末尾が、ebank.co.jpもしくは、fes.ebank.co.jpであること。 
| また、当対策の一環として、お客様は、あらかじめ登録したキーワードを利用
| し、ご覧になっているサイトがイーバンクのサイトであることを確認してから
| ログインできるようになります。 
| これまでどおり支店番号、口座番号、ログインパスワードの入力によるログイ
| ンもご利用いただけますが、さらに安全にご利用いただくために、キーワード
| を利用したログイン方法を推奨いたします。(略)
| イーバンクのホームページやショッピングサイトからのログイン時にはいつで
| も正規のサイトであることをご確認いただけます。

キーワードを利用したログイン前のサイト確認について
http://www.ebank.co.jp/security/measure/top.html
| イーバンク口座へのログインの前に、お客様があらかじめ登録したキーワード
| を利用して、イーバンク銀行のサイトであることを確認できます。
| 安全対策の一環としてご利用をお薦めするものですが、キーワードの登録がお
| 済みでないお客様は下記の説明をご覧のうえ通常にログインし、「セキュリティ」
| 画面よりご登録ください。
|(略)

問題点
------
ユーザがパスワードの前半をサイトに入力してボタンを押したとき、自分の登
録キーワードが画面に表示されたからといって、それが本物サイトであるとは
限らない。

なぜなら、同じ画面を偽サイト上に構築し、騙して入力させた前半のパスワー
ドと口座番号を、偽サイトが本物サイトに送信すれば、偽サイトは本物の「登
録キーワード」を入手することができるのであるから、それを偽サイトの画面
上に表示できてしまう。

そのような偽サイトは、ブラウザからのアクセスの全部を本物サーバへと中継
し、本物サーバからの応答をそのままブラウザに中継して返すという、単純な
プログラムで実現できてしまうのであり、高度な技術を要するものではなく、
そのようなケースを想定しなくてよいことにはならない。

消費者がとるべき行動
--------------------
イーバンク銀行の説明を受けたユーザは、この機能の安全性を信用しないよう、
心がける必要がある。

報道記事を読んで「こういう対策もあるのだな」と信じた一般の消費者は、今
後同様の仕組みが他のサイトで現れたとき、それを信用することのないよう、
考えを改める必要がある。

アクセス先のサイトが本物であるかどうかの確認は、ブラウザのアドレスバー
に表示されたURLを確認することと、ステータスバーの錠前アイコンで示され
るサーバ証明書の内容を確認するのが基本であり、これはいずれにせよ必要で
ある。

アクセス先が本物かどうかは、ブラウザが備えている機能によってしか確認し
得ないのであって、サイト側の工夫だけで真正性を示すことは本来原理的にで
きないのだと心得るとよい。

ただし、アドレスバーやステータスバーを偽装できてしまうという、ブラウザ
の欠陥が発覚することがあるので、それらを過信することにも注意が必要であ
る。しかし、そうした欠陥は「セキュリティ脆弱性」として扱うとする共通認
識が業界には既に確立されており、ブラウザのベンダーはそうした脆弱性を修
正するべきである。

そもそも一般に、脆弱性が修正されていないブラウザは、他の危険を伴うもの
(たとえばcookieを盗まれる脆弱性があれば、セッションハイジャック攻撃に
よる被害に遭う危険性がある等)であり、修正されるまで使用を避けるべきで
ある。それをしないのであれば、フィッシング詐欺だけでなく他の手口による
被害にも遭うおそれがあるのであるから、まず、脆弱性を修正することが必須
である。

ブラウザの脆弱性によるアドレスバーやサーバ証明書表示の偽装を心配せざる
を得ない状況であれば、メール中のリンクをクリックしてサイトにジャンプす
るのを避け、覚えている正しいURLを直接手入力して本物サイトにアクセスす
るようにするべきであって、今回のキーワード確認機能のような不完全なサー
ビスは、信用しないでおくべきである。

Webサイト運営者が取るべき行動
-----------------------------
この種の欠陥機能を新たに設置してはならない。

報道記事を読んで「こういう対策もあるのだな」と信じた経営者、技術者、運
営責任者は、これが対策になっていないことを理解し、同様の欠陥サービスを
自社に導入することのないようにしなければならない。

対応状況
--------
2004年9月12日
   当該サイトにある問い合わせフォームから質問を提出した。システムの都
   合上、500文字以内しか記入できなかったため、概要のみ説明した。
2004年9月14日
   最初の回答を電子メールにて頂いた。回答の要点は、
   > 最初のログイン画面を通過しない場合、キーワード確認画面にたどり着
   > けない為、これで大半の不正なサイトを除外する事ができます。
   というものだったが、これは誤りである。セッションIDのことを指してい
   ると推察されるが、偽サイトが、最初の画面の偽画面から中継するよう、
   誘導していれば、偽サイトであるにもかかわらず正常に機能してしまう。
2004年9月17日
   メールにて、詳細な説明による再度の質問(「公開質問」と題する)を送
   信した。この質問文(一部伏字、一部省略)をこの文書の末尾に示す。
2004年9月22日
   以下を要旨とする回答を得た。

   > <■ご質問1につきまして>
   > ご指摘いただきましたとおり、〓〓〓〓〓〓を使用する事によって、
   > 不正行為者がクライアント〓〓〓〓〓〓間のデータを〓〓等により
   > 盗取する事は可能です。
   > したがいまして、上記のような高度なフィッシングサイトに対しては
   > サーバ証明書、アドレスの確認と必須になります。
   (非公開情報と推察されるため中略)
   > ログインできる回数を制限している為、被害を最小限に留める
   > 仕様となっております。

   > <■ご質問2につきまして>
   > 「キーワードを利用したログイン前のサイト確認について」
   > 「フィッシング対策に関する重要なお知らせ」等のページにて、
   > サーバ証明書、アドレスの確認を行わなくても、イーバンクの
   > 正規サイトである事を確認できるような表現は、一部誤解を招きやすく
   > 適切ではございませんでした。
   > 至急、検討の上改善いたします。
   > 但し、キーワードによる確認によって、下記のような場合において
   > 一定の効果はあるものと認識しております。
   > ・簡易な偽造サイトの除去
   > ・弊行と紛らわしいURLを使用した偽造HTTPSサイトの除去
   > ・セキュリティの甘いブラウザからのリスク軽減
   >  (ブラウザによっては表示するURLを簡単に偽造できてしまう物や、
   > URL、SSLの対応状況が容易に見れない物がございます)
   
   > <■ご質問3につきまして>
   > ご質問2に対する回答から、イーバンクでは1つのセキュリティ対策ではなく、
   > 複数の対策を組み合わせる事によってセキュリティの安全性をより
   > 高める事が可能であると考えています。
   (非公開情報と推察されるため中略)
   > お客様に一部誤解を招く説明なっておりました事をお詫びし、
   > 説明内容を改善いたします。

2004年9月22日
   回答へのお礼とともに、以下の感想を含むメールを送付した。
   >
   > > ・セキュリティの甘いブラウザからのリスク軽減
   > >  (ブラウザによっては表示するURLを簡単に偽造できてしまう物や、
   > > URL、SSLの対応状況が容易に見れない物がございます)
   > 
   > URLやSSLの対応状況が容易に見られないようなブラウザは使うべきではあ
   > りません。そうしたブラウザを使わないように顧客を指導するのが、本来
   > なすべきことであるはずです。

この事実をここに公表することの必然性
------------------------------------
フィッシング詐欺に対して既にいくらか警戒心を持っているユーザであれば、
届いたメールが偽でないかと疑念を抱くであろう。しかし、このキーワード確
認機能の登場によって、ユーザが、これで本物サイトの確認になると信じた場
合には、本来持っていた警戒心を捨てて、「これで本物だと確認できた」と考
えて、パスワードの全部を入力してしまいかねない。

すなわち、このキーワード確認機能は、安全確認にならないだけでなく、ユー
ザをフィッシング詐欺に騙され易くする性格も持ち合わせている。

残念なことに、この件がマスメディアによって大々的に報道されたことにより、
このような仕組みが「正規のサイトであることの確認になる」とする誤った理
解が広まってしまった。

これが誤りであることを誰も公表ぜずにいることは、当該サイトにおいて将来
生じ得るフィッシング詐欺における被害を拡大させることになるだけでなく、
他のECサイトにまで誤った仕組みが導入されてしまい、事態の収拾がより困難
になってしまうおそれがある。

したがって、早い時期に、この仕組みが対策にならない事実を知らせ、可能な
限り多くの人の誤解を解く必要がある。

もし、当該サイトがこの機能を撤廃するのであれば、撤廃の事実と理由が再び
報道される可能性もあるところ、今回の当該サイトへの問い合わせで、撤廃は
しないとの回答を得た。機能の説明方法は改善するとのことであるが、それだ
けでは、既に報道によって広まってしまった認識を変えるまでの効果は得られ
ないと推定する。したがって、報道関係者を含め、技術者や運営責任者に、こ
の事実を正しく伝えておくことによって、適切な事実伝達の機会が得られると
考える。

また、中継によって偽サイトが本物サイト同様にキーワードを表示可能である
という事実を明らかにすることは、「そんなことはできないはずだ」とする誤っ
た認識を改めさせるために必要である。事実、今回の問い合わせにおいても、
「最初のログイン画面を通過しない場合、キーワード確認画面にたどり着けな
い」という誤った釈明がなされ、具体的に方法を指摘して見せるまで、その釈
明が誤りであることは認められなかった。

他のWebアプリケーション開発者に問題を正しく認識させ、こうした欠陥の再
生産を防止するため、中継によるフィッシング詐欺が容易である事実は公表
するべきである。

その他
------
この件は、IPAの脆弱性届出窓口には届出ていない。当該サイト運営者が「こ
れは脆弱性ではない」とする対応をとることが予想されるところ、誤解が拡大
するのを止めるために急を要するところであるので、問題点の指摘と意見を直
接伝えることが必要であると判断した。

以上

高木 浩光
茨城県つくば市在住
-----------------------------------------------------------------------
以下は、9月17日に当該サイトカスタマーセンターに問い合わせた質問文。
「〓」は伏字。一部省略。

(挨拶部略)
公開質問

■質問1

フィッシング詐欺対策として9月12日から開始された、キーワードの確認機能
では、「イーバンク銀行のサイトであることを確認できます」とされています
が、登録したキーワードが表示されたからといって、それがイーバンクの本物
サイトであるとは限りません。

なぜなら、同じ画面を偽サイト上に構築し、騙して入力させた4文字目までの
パスワードと口座番号を(偽サイトが)本物サイトに送信すれば、偽サイトは
本物の「登録したキーワード」を入手することができるため、それを偽サイト
の画面上に表示できてしまうからです。

そのような偽サイトは、ブラウザからのアクセスを本物サーバへと中継する仕
組みとすることで、簡単に実現できてしまうものです。

そのことを実証するため、非透過型〓〓〓〓〓〓〓〓〓〓〓〓〓を自分のコン
ピュータ上で動作させることにより、以下のようにして事実確認をしました。

 1. 〓〓〓〓〓〓〓〓〓を自分のパソコンにインストールする。SSLに対応させ
    るため、〓〓〓もインストールする。

 2. 以下の設定で起動する。
    〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓

 3. Webブラウザで以下のURLにアクセスし、最初のログイン画面を表示させる。
    http://127.0.0.1:〓〓/〓〓https://fes.ebank.co.jp/FES/ebank/〓〓〓〓〓〓〓
    (127.0.0.1 は自分のコンピュータを表します。)

 4. 現れる画面から、「イーバンク銀行のサイトであることを確認してからの
    ログインはこちら」のボタンを押し、キーワード確認付きのログイン画面
    に移動する。そのときのURLは以下のようになる。
    http://127.0.0.1:〓〓/〓〓https://fes.ebank.co.jp/FES/ebank/〓〓〓〓〓〓〓
    
 5. 支店番号、口座番号、パスワードの最初の4文字を入力して「確認」ボタ
    ンを押す。

 6. 登録済みのキーワードが表示されることが確認される。このとき、ブラウ
    ザのURLは、http://127.0.0.1:〓〓/〓〓https://fes.ebank.co.jp/……
    になっている。つまり、アクセス先は 127.0.0.1 である(本物サイトで
    はない)にもかかわらず、キーワードが正しく表示されたということ。

この確認作業では、自分のコンピュータで〓〓〓〓〓〓〓を動かしただけです
が、こうした〓〓〓〓〓〓〓が、詐欺師によって偽サイト上に設置された場合、
ユーザがそれが偽サイトだと気付かずにパスワードを入力してしまうと、〓〓
〓〓〓〓〓〓〓〓から、ユーザが入力したパスワード等を抽出できてしまうと
推定されます。

こうしたアクセスを拒否するための技術的対策として、Referer: フィールド
のチェックということが考えられるかもしれません。すなわち、Referer: の
URLが、https://fes.ebank.co.jp で始まっていない場合はアクセスを拒否す
るようにサイトを作るという考えです。しかし、それは対策にはなりません。
なぜなら、〓〓〓〓〓〓〓〓で、Referer: フィールドを本物と同じURLに差し
替えることが簡単にできてしまうからです。

したがって、ユーザが、アドレスバーやサーバ証明書の確認をせずに、登録し
たキーワードが表示されたことだけでもって、それがイーバンクの本物サイト
であると信ずるよう行動すると、偽サイトに騙されることになります。

これは事実ですか?


■質問2

キーワード確認機能の利用方法をユーザに説明している、「キーワードを利用
したログイン前のサイト確認について」のページ
http://www.ebank.co.jp/security/measure/top.html
には、冒頭に次のように書かれています。

| イーバンク口座へのログインの前に、お客様があらかじめ登録したキーワード
| を利用して、イーバンク銀行のサイトであることを確認できます。

また、「フィッシング対策に関する重要なお知らせ」のページ
http://www.ebank.co.jp/information/information_032.html
にも、「お客様は、あらかじめ登録したキーワードを利用し、ご覧になってい
るサイトがイーバンクのサイトであることを確認してからログインできる」と
書かれています。

このような表記は、「アドレスバーやサーバ証明書の確認をしなくても、キー
ワードさえ表示されれば、イーバンク銀行のサイトであることを確認できる」
という意味として、ユーザに理解されるだろうと考えます。

しかし実際には、質問1で述べたように、キーワードが表示されたことは、何
ら本物サイトの確認にはなっておらず、依然として、アドレスバーと証明書の
確認は必須です。

このようなユーザへの説明は、ユーザを、「キーワードが表示されたら本物だ
と信じてよい」という誤った理解に導くものではありませんか?


■質問3

フィッシング詐欺に対して既にいくらか警戒心を持っているユーザであれば、
届いたメールが偽でないかと疑念を抱いたり、アクセスしたサイトのアドレス
バーや証明書を確認しようとするでしょう。

しかし、このキーワード確認機能の登場によって、ユーザが、これで本物サイ
トの確認になると信じた場合には、本来持っていた警戒心を捨てて、「これで
本物だと確認できた」と、パスワードの全部を入力してしまうと考えられます。

すなわち、このキーワード確認機能は、むしろユーザをフィッシング詐欺に騙
されやすくするものではありませんか?


■意見

以上より、このキーワード確認機能は、本物であることの証明にならないばか
りか、ユーザを混乱させ、かえってフィッシング詐欺に騙されやすいユーザを
作り出してしまっていると考えます。よって、この機能は廃止するべきです。

また、今回の新機能について報道されたことにより、こうした機能で本物サイ
トと確認できるのだという誤った理解が、イーバンク銀行の顧客のみならず、
他の一般の人たちにまで広められてしまいました。このままでは、他のECサイ
ト等において同様の機能が作りこまれるなどし、誤解はさらに広がる恐れがあ
ると危惧しています。したがって、この機能を廃止すると同時に、これがフィッ
シング詐欺対策にならないことが判明したため廃止した旨を、告知するべきで
す。

なお、Webの仕組みから原理的に言って、サーバから見て、アクセス元がユー
ザのブラウザであるのか、それともそれを中継している偽サイトであるのかを、
きちんと区別することはできないものですが、ただし、cookieを使う方法で、
中継攻撃を防ぐことは可能ではあります。その方法の例は以下の通りです。

 (1) 正常にログインした際に、ユーザごとに異なり第三者には予測が困難な
     IDを生成し、有効期限の長いcookieとして発行する。
 (2) 次回以降、ログイン画面にアクセスがあったときは、そのcookie中のID
     からユーザを検索して、ユーザが登録したキーワードを画面に表示する。
 (3) ユーザは、キーワードが表示されていれば本物サイトにアクセスしてい
     ると認識する。

この方法の原理は、cookieが、発行元のドメインのURLにアクセスしたときに
しか送信されない仕組みになっているところにあります。偽サイトにアクセス
したときには、(1)で発行されたcookieは、偽サイトに送られることはありま
せん。

これに類似した方法は、(略)

しかし、この方法では、あまりフィッシング詐欺防止の効果はないと考えます。
なぜなら、cookieは消去されることがあるうえ、別のパソコンでログインしよ
うとしたときにはcookieはありませんから、そういう状況が生ずるたびに、キー
ワードが表示されない事態となります。

キーワードが表示されない場合は偽サイトの疑いがあると、本来は考えるべき
ですが、本物サイトにアクセスしたときにも、キーワードが表示されないこと
が度々あるという状況では、偽サイトにアクセスしたときにでも、「またか」
と感じて、cookieの再発行手続きをしようとしてしまいかねません。

結局のところ、アドレスバーや証明書の確認は必須なのであって、中途半端な
キーワード確認機能は、リテラシーの低い一般ユーザを混乱させ、基本をおろ
そかにさせるものです。

このような悪しき方法が他のECサイトにまで広がって習慣化してしまう事態は、
避けられるべきです。
 

以上

そしてこれがその後どうなったかというと、「フィッシング対策に関する重要なお知らせ」のページが9月26日に改訂されて、表現が慎重なものに改められた。また、「キーワードを利用したログイン前のサイト確認について」のページも、以下のように慎重な表現に改められている。

改訂前

改訂後*2

さて、これは妥当な対応であろうか。

ちなみに、9月26日改訂版の「フィッシング対策に関する重要なお知らせ」の末尾には、次のように今後のことが予告されている。

尚、今後のフィッシング詐欺対策の一環として、個人のお客様に対する「IP制限サービス」(現在は、法人のお客様のみご利用いただけます。詳しくはこちら)を予定しております。 こちらの開始時期等につきましては、当行ウェブサイト上等で追ってご連絡いたします。

フィッシング対策に関する重要なお知らせ, イーバンク銀行, 2004年9月26日

この、既に法人向けにはサービスされているIPアドレスの照合機能については、2月8日の日記にも書いた。しかし、なぜこれが「フィッシング詐欺対策として」なのか。

たしかに、IPアドレス照合機能が個人向けにもサービスされるようになれば、キーワード確認機能を中継により偽装するフィッシング詐欺は防止できるようになる。なぜなら、偽サイトが本物サイトにアクセスを中継するとき、アクセス元のIPアドレスは、ユーザのアドレスではなく、中継者のアドレスとなるから、そのようなアクセスの拒否が可能になる。

ただし、これが有効になるのは、IPアドレス照合機能を使って自宅などのIPアドレスを登録してアクセス元IPアドレスを制限する設定にしていているユーザが、ログイン前にキーワード確認機能を用いて自分のキーワードを表示させて確認したときだ。

とてもややこしい。IPアドレス照合を設定しているユーザでも、キーワード確認(やアドレスバー、ステータスバー確認)を怠れば偽サイトに騙される(偽サイトはIPアドレスの照合をしていないのだから)し、IPアドレス照合を設定していないユーザは、キーワード確認機能が本物サイト確認にならないことを理解している必要がある。

はたして、こうした事実を正確にユーザに説明できるのだろうか。

*1 cookieを用いた特定の制御が存在する場合を除く。

*2 イーバンクのサイトからリンクをたどってこのページに到達すると、このようにアドレスバーを隠したポップアップウィンドウで開くようになっている。この期に及んでこういうものを残すというセンスが理解できない。

本日のリンク元 TrackBack(0)

2004年10月14日

子供の安全を脅かす発信機

10月10日の日記に書いた讀賣テレビ「ウェークアップ!」の9日放送内容がテキストで公式サイトに掲載されていた。

ところで、和歌山県田辺市の小学校の実験はどうなったのだろうか。番組でも出てこなかったし、その後何も情報が聞こえてこない。6月17日の京都新聞では、「10月から和歌山県田辺市の公立小で実験を始める」とされていたが、もう始まっているのだろうか。父兄への説明会とかは開催されたのだろうか。どの小学校なのだろう?

10月5日の日経産業新聞にも関連記事が出ていたが、田辺市の件は書かれていなかった。

3日に2件――。警察庁がまとめた大学生以下の少年少女が巻き込まれる誘拐事件の件数だ。子どもを誘拐の危険から守ったり迷子になるのを避けるため、物流や流通業で普及しているICタグを活用した安全確保の試みが教育現場で始まった。(略)子どものプライバシー確保の問題が残るが、総務省は「今後ICタグの用途を広げるためにも、プライバシー問題をとことん議論してほしい」としている。 (略) 立教学院立教小学校(東京・豊島、田中司校長)も富士通と組み、9月からICタグで児童の登下校情報を管理するシステムの運用を始めた。微弱な電波を発する電池入りのICタグを児童に持たせる。(略)校門をくぐると自動的に反応するので「1年生など幼少の児童がいても導入しやすい」(同校情報処理室長の佐藤稔氏)。(略)運用に問題がなければ、来年1月には全校児童720人に配布する考え。運用費はICタグの価格込みで月額100円を想定し、保護者から徴収する。 (略) ただ子どもといえども一定のプライバシーを確保する必要はある。文部科学省は「学校と保護者との了解を取れば大丈夫では」(スポーツ青少年局学校健康教育課)としている

総務省は「人の所在地確認ではまず教育現場で実用化が進んできた」(情報通信政策局研究推進室)と指摘し、「個人情報や書籍の追跡などし好に関する分野での普及には、プライバシー保護の問題を実験などで十分に検討するべきだ」(同)と話す。

文部科学省スポーツ青少年局学校健康教育課……よりによっていかにも血のめぐりの悪そうな。

総務省は比較的意識が高いようだ。こんな報道もあった。

  • 電子タグの普及にはプライバシーや地域特性への配慮が不可欠〜RFID特別セッション, INTERNET Watch, 2004年10月6日
    政府の側からは、総務省の大臣官房審議官を務める松井英生氏、経済産業省の商務情報政策局審議官を務める桜井俊氏の2人が、現在のRFIDに対する政府の取り組みの状況を語った。 (略) 一方で問題点として挙がったのがやはりプライバシー問題。松井氏は「電子タグは『究極のSCM』を実現するのに欠かせない技術だが、一方で使い方を誤ると『人間のSCM』にもなってしまう」と語ったほか、「日本では便利になるというと消費者が比較的飛びつきやすい傾向があるが、欧米では便利になるというだけでは消費者は飛びつきにくい」「米国ではテロ対策や入退室管理などへの関心が高く、地域によって価値観が違ってくる」と述べ、世界への普及を考えたときにもっとプライバシーなどへの配慮を高めるほか、地域特性に合わせたソリューションを提供しないと、日本企業の持つ技術が国内でしか活用されなくなってしまうという危機感を示していた。

まったくその通り。日本以外の文明国で、子供にアクティブタグ取り付けて「うっとり安心感」なんてのはあり得ない話だろう。

「ワンクリック料金請求」で用語は定着か

5月25日の日記「「ワン切りメール」ですって?」で、良いネーミングがないとしていた件は、10月8日に警視庁から出た注意喚起では、「ワンクリック料金請求にご用心」という表現になっていた。

関連報道

本日のリンク元 TrackBack(1)

2004年10月16日

日経コンピュータは天然なのか病気なのか

去年8月、日経コンピュータ栗原雅記者の伝説のコラム「消費者に理解されていないICタグ」に対してボロカスな読者コメントが寄せられるということがあったが、その後、栗原記者からの釈明が掲載されることもなく、「あそこの読者コメントは著者には読まれていないのではないか」という疑問の声が各所で囁かれていた。

日経コンピュータ誌を漁ってみたところ、読者コメントに対する著者の回答は、本誌の「読者の声Web版」というページに掲載されていた。昨年9月22日の栗原記者の記事「ICタグの具体的な利用提案が続々」に対する読者コメントに対して、日経コンピュータ2003年10月20日号のp.190で栗原記者が答えている。

[読者の声]

また宣伝ですか。「利用者もICタグについて理解してきた」とてもそうとは思えないのですが。一般のユーザーは、ICタグについてまだまだ知らないと思います。業界は良い点ばかり宣伝し、都合の悪いことに口をつぐんで、ただ「ICタグ」という商品を売りつけたいだけではないのでしょうか?

(30代,ユーザー企業,情報システム部門 9/26投稿)

最大の課題であったプライバシ侵害の危険に対して何も触れていないが、進展はないのだろうか? これほど重大な問題点を放置したまま「見切り発車」を急ぐことで、せっかくの有望な市場にぬぐいがたいダーティイメージが固定することを恐れる。そのような自体を防ぐ責任のかなりの部分はマスコミにあると思う。まずは問題点について「無かったことにする」態度を糾弾し、正しい認識を消費者や関係者に啓蒙すべきであろう。 (9/27投稿)

(略)

[記者からひとこと]

初めに、記者および日経コンピュータは「ICタグを宣伝する意図はまったくない」ことをお断りしておきます。 ICタグについて、一般の方々の理解をさらに深める必要があるのは事実です。大前提として、電波法の規制の下でICタグとリーダーが通信可能な距離や、電波の特性など技術面の理解が欠かせません。そのうえで「享受できる可能性があるメリット」と「普及に伴って危惧されるデメリット」の両面を議論すべきだと考えます。それが「正しい認識」につながります。

「都合が悪いこと」すなわちプライバシ侵害から消費者を守ることが大切なのは間違いありません。ただ、「プライバシが危ない」という一方的な視点で議論を進めるのは、消費者の不安をむやみにあおるだけだと考えます。2000年問題のとき、「銀行預金は引き出せなくなり、水道やガスや電気が止まる」と報道したメディアの多くは、企業の対策状況に触れなかったため、社会にばく然とした不安をあおりたてました。ICタグについても、技術特性という大前提を無視して極端な議論をすると、これと同じ状況を招きます。

導入に意欲的な企業と政府はプライバシ侵害の問題を検討し始めました。今後もICタグの取材を強化して、メリットとプライバシ侵害を含む問題点の現状と展望を紹介します。(栗原 雅)

読者の声Web版, 日経コンピュータ, 2003年10月20日号, p.190

で、ICタグのプライバシー懸念について「企業の対策状況」がどうなっているのか、栗原記者はその後、取材や報道をしたのか? 2000年問題で大した実害が発生しなかったのはなぜか、考えたことはあるか?

日経BPの雑誌を「ICタグ」と「プライバシ」をキーワードに全文検索してみたところ、以下の記事などがヒットした。

  • アキヨ・ブラウン[在米ジャーナリスト], ICタグのプライバシ問題で決定的な溝 推進派が提案する「Killタグ」では解決しないと反対派, 日経コンピュータ 2003年12月1日号 pp.19-20
  • 久場英子[米在住ジャーナリスト], ICタグは法制化問題に発展か, US事情 第1回, 日経情報ストラテジー2003年12月号 p.33
  • 高木篤夫[ひかり総合法律事務所・弁護士], ICタグの2つのガイドライン, 弁護士の眼 第7回, 日経情報ストラテジー2004年6月号 p.139
  • 松嶋武[日本総合研究所 事業企画部], 今さら聞けないITの新常識【ICタグ】, 日経コンピュータ2004年1月26日号 pp.218-221

記者による記事よりも、在米ジャーナリストや弁護士などの記事が目立つが、先日、最新の記事が出た。

ここにプライバシー関連の記述が何箇所かあるのだが、あいかわらず、問題を正しく認識しておらず(もしくは、わざと書かないようにしている)、1年前と同じことを繰り返し言っていることがわかる。

6. 他人に持ち物が見られてしまう?

あらゆるモノにICタグが付くようになると、カバンや上着のポケットに入れた持ち物が見ず知らずの人に分かってしまう――。こうした懸念が一部でささやかれている。技術的には、外から見えなくてもリーダー/ライターの電波がカバンやポケットの中に届けば、財布などに付けたICタグの情報を読めるからだ。

だが現実にはタグが付くからといって、通りを歩いたり電車に乗ったときなどに持ち物が見られる危険が急に高まるとは考えにくい。

ICタグに記録してある情報は0と1を羅列したバイナリ・データであることが普通。それだけ読んでも、何ケタ目から何ケタ目までが何を意味しているのかは分からない。バイナリ・データの意味を知るには、ネットワーク上に星の数ほどあるデータベースの中から、そのバイナリ・データを管理しているデータベースを突き止める必要がある。さらにセキュリティの網をかいくぐってハッキングに成功しなければならない。

そもそも、赤の他人に近づいてカバンに入っている持ち物のバイナリ・データをこっそりと読み、その意味を解釈するのにわざわざハッキングなどの手間をかける人間が本当に存在するかどうか疑問が残る。

特集ICタグ35の疑問, 日経コンピュータ2004年10月4日号, p.57

栗原雅が真っ赤な顔をしてキーボードをたたいている様子が目に浮かんでくる。

いまさら言うまでもないがいちおう反論しておく。

指摘されている問題は、モノが何か分かるという点だけでなしに、トラッキングの懸念であるが、栗原記者はそれを無視し続けている。

データベースへのアクセス権の管理をどう設計するかは大変難しい問題で、関係技術者と話をすると、そこが未解決で途方に暮れているという声をよく耳にする。つまり、「ハッキング」など必要ではなく、読み取った番号を正規の装置から検索すればよい。たとえば、本屋のシステムであれば、全国何万もの書店でIDから書名を検索できることになりかねない。モノの所有者が移転する毎にアクセス権も移転させるといったシステム設計が必要となるが、それがうまくできるかが鍵だ。そういうところを取材したり問題提起するのがジャーナリストの仕事だろう。

「ネットワーク上に星の数ほどあるデータベースの中から」とあるが、オートIDラボのインターネット屋の人たちが言っているところでは、DNSを使って、タグのIDからデータベースのIPアドレスを検索するサービスを提供するという話があるようだが、それは誰でも検索できるということではないのか?

また、続くページにはこういう項目もある。

33. プライバシ問題にどう対処すべき?

特集ICタグ35の疑問, 日経コンピュータ2004年10月4日号, p.57

ここは、総務省・経済産業省のガイドラインに関する記述で、まあまあまともに書かれている。

34. 不正な読み取りを防ぐには?

タグが持つデータの不正な読み取りを防ぐ方法は大きく二つある。一つは、消費者の手にICタグが渡ったときにタグのデータを消去する仕組みを付ける。もうひとつは、ICタグのデータを暗号化して、データの中身を分からなくするものだ。

(略)

特集ICタグ35の疑問, 日経コンピュータ2004年10月4日号, p.58

暗号化したデータを格納しても、トラッキングの問題は解決しないのだが、そのことが全く書かれていない。日経コンピュータの記者は、トラッキングの懸念は無視なのだ。上の33.の項目の文章を読んでも、トラッキングの懸念のことは書かれておらず、

たとえ読み取られた情報が個人情報にあたらないとしても、自分にかかわる情報を知らないうちに他人に知られるのは気分のよいことではない。

特集ICタグ35の疑問, 日経コンピュータ2004年10月4日号, p.57

と、気分の問題だということにしている。総務省・経済産業省のガイドラインが出た理由が、気分の問題として解釈されている。

これに比べて、日経バイト誌はよい記事を出している。

  • 安東一真, 大根や財布に無線ICタグを張り付けて測ってみた, 日経バイト2004年6月号

    今後,さまざまなモノに張り付けられ,新たなサービスの提供や管理の効率化を可能にすると期待されている無線ICタグ――。その適用領域を見極めるには,無線ICタグがどこまで読めるのかという基本性能を知っておく必要がある。

    (略)

    無線ICタグの性能を知ることは,懸案となっているプライバシ問題について考える上でも重要である。カバンの中身が外から分かったり,人の行動を追跡されたりする恐れがあるというが,それはどんな場面で起こるのか。それを未然に防ぐには,どのような対策が有効なのか。対策を考え,その妥当性を検証するためにも,どんなときにタグが読まれるのかを知っておきたい。

ジャーナリズムとして極めて正しいアプローチである。栗原記者もそういう視点を持ったらどうか。

また、日経バイトには以下の記事も出ている。

  • 木下真吾のRFIDプライバシ論, 日経バイト2004年9月号

「無線ICタグにIDしか入れていなければプライバシは侵害しない」。こんな主張をたまに見るが、それはウソである。世界で一意のIDがもたらす危険性を、2010年のクリーニング店を舞台に分かりやすく解説する。(本誌)

という編集者からのコメントが付いており、日経コンピュータとは対照的だ。

こうした懸念の存在を踏まえたうえて、その程度問題を議論したり、対策方法を議論するのがなすべきことなのに、日経コンピュータはそれを無視している。

冒頭の読者コメントで、「まずは問題点について「無かったことにする」態度を糾弾し、正しい認識を消費者や関係者に啓蒙すべきであろう」という指摘があったが、「無かったことにする」とは、まさに栗原記者(および日経コンピュータ編集部)がやっていることだろう。

ちなみに、日経コンピュータでも海外発の記事は興味深い内容になっている。

  • アキヨ・ブラウン[在米ジャーナリスト], ICタグのプライバシ問題で決定的な溝 推進派が提案する「Killタグ」では解決しないと反対派, 日経コンピュータ 2003年12月1日号 pp.19-20

    (略)会場にはオートIDラボなどの関係者を含む200人ほどの聴講者がいたが、アルブレクト氏の指摘に対し何の反論もなかった。

    (略)

    「ICタグの技術そのものを否定しているわけではない。消費者を交えた議論や評価という重要なプロセスを経ずに、企業だけで走り出しているのが問題」とアルブレクト氏は主張する。

    (略)会場の参加者のなかからは「私はオートIDラボと共同で仕事をしているベンダーだが、CASPIANの主張はよく理解できた。プライバシに対する考え方が変わった」といった声が挙がっていた。企業と市民団体の対話という点では、米国は日本よりも先行している。

ネタメモ

プライバシーの論点が何もない。昔のZDnetのようなスタンスとは違ってきている。ITmediaは普通の和風メディアになりさがっていくのだろうか。だとしたらまことに残念だ。同じものは二ついらない。

  • RFIDでプライバシーの心配は無用?, ITmedia, 2004年9月9日

    アクセンチュアの堀田徹哉パートナーへのインタビューの4回目は、特に欧米で懸念されているプライバシーの問題を取り上げる。同氏によると、米プライバシー保護団体が騒ぎを起こすほどには心配しなくていい問題のようだ。

これに対してはこんな意見も見られた。

次の記事、

  • NTTソフト、顧客の購買意欲を促進する商品紹介ソリューションを開発, インターネット・コム, 2004年10月6日

    今回、開発した One to One 履歴分析/IC タグソリューションは、ディスプレイ付のショッピングカートに、IC タグが付いた商品を入れることによって、その商品の購入者たちがどのような別商品を購入しているという情報をディスプレイに表示し、購買意欲の促進をはかるもの。

    (略)通常のマーケティング分析で使われる、年齢、性別などの顧客属性や食品、化粧品などの商品属性といった情報を一切使用せず、「誰が」、「いつ」、「何を購入した」という購買履歴だけで分析することが特徴の「選好行動分析フィルタリング技術」を活用したエンジン。(略)

    今後、同ソリューションは、ポイントカードシステムや携帯電話などを組み合わせることにより、従来、ネット販売だけで可能だと考えられていた商品紹介機能を、リアル店舗でも活用できるよう計画をしてる。

「誰が」とあるが、匿名のまま買うことも許してくれるのだろうか。

本日のリンク元 TrackBack(1)

2004年10月17日

電子政府つくるは素人ばかり

つくば市の電子申請・届出システムがリニューアルした。行ってみると、いきなりこんなことが書かれていた。

ご利用のブラウザ等の設定により,下の図のようなセキュリティ情報が表示される場合がありますが,問題ありません。「はい」をクリックしてください。

市役所に電話して尋ねたところ、こういう感じの応答になった。

私: 問題ないのでしょうか?

市: 問題ないですね。

私: 問題ないのにどうして出るのでしょうか?

市: そうですね……。ブラウザの設定に起因する。

私: ブラウザの設定が悪いということですか?

市: そうではない。マイクロソフトがこういうふうにしているので。

これは、https://... のページのサブフレームの中に http://... のページを埋め込んでいるために発生している。フレームの中に入れなければよいのだし、他にも解決方法は何通りもある。

それはまあ些細なこととして、もっと凄いものを目の当たりにした。申請届出システムにログインすると、こういう確認ダイアログが現れる。

これは、署名されたJavaアプレット(Sun MicrosystemsのJava VMでの起動)が使用されているために現れる、署名確認のダイアログウィンドウだが、「信頼できない団体によって発行されています」と警告印が出ている。

しかも、アプレットへの署名者の名前が「TSUAPP0002」と意味不明な記号になっている。(ここは「つくば市役所」(の英語表記)と書かれるべき部分。)

この点についても電話で市役所の担当者に尋ねたところ、こんな感じの返事だった。

NTT BizLinkという第三者機関に認証してもらった。

料金を払って証明してもらっている。

信頼できる団体と考えている。

矛盾した表示になっているが、これはマイクロソフトが……。

「TSUAPP0002」はこちらで決めた名前で、この名前でNTT BizLinkに認証してもらった。

開発ベンダーはNTT東日本。

これは、証明書の発行機関が、Java VMのルート認証局として登録されていない未信頼のところだからこういうことになる。いくら市役所の人たちが「信頼できる団体と考えている」と主張しようとも、PKIとしては全く機能していない。

PKIの基礎をまるで理解していない人達によって、電子政府は作られている。

こういうとき、ルート認証局の証明書をユーザに入れさせる自治体や中央省庁が多いが(それもデタラメなのだが)、この件もそうやって解決すればよいというものではない。その場合、最低でも、そのルート認証局の(「NTT BizLink, Inc.」の)認証局運用規定等を利用者に開示しなくてはならない。

しかし、「NTT BizLink」という会社は初耳だ。コード署名用の証明書発行認証局業務をやっているとは聞いたことがない。

「NTT Bizlink 認証」で検索してみたところ、こういうページが見つかった。

どうやら、電子入札システム用の自治体向け認証公証局サービスをやっているらしい。だが、コード署名用の証明書発行や、SSLサーバ証明書の発行などの業務については書かれていない。

可能性として次などが考えられる。

  1. 電子入札システム用として取得した証明書を、つくば市が(意味もわからず)誤って、アプレットのコード署名用として流用した。
  2. NTT BizLinkが、つくば市の依頼に基づいて、(意味もわからず)指示されるがままに適当に証明書を発行した。
  3. つくば市と開発ベンダーとNTT BizLinkが協議のうえ、「これでよい」という合議のもとでこの証明書を発行した。

電子入札システム用の証明書が勝手に流用されたにしては、その証明書発行者の認証局(電子入札公証局)証明書の名前が、「BizLink CA」というずいぶん素っ気無い名前になっていて、それは不自然だ。

コード署名用の証明書の名前欄が「TSUAPP0002」というのは、どう考えても異常な事態である。これは、スキルとか知識の問題ではない。

"TSUAPP0002"から渡された書名つきアプレットを信頼しますか?
とか、
"TSUAPP0002”はこの内容が安全であることを表明します。
とか、
"TSUAPP0002"を信頼する場合にのみ
という文章を読んで、おかしいと思わないのだろうか? 国語力が欠如しているのか? そんなことはないだろうから、ようするに単に読みもせず適当にやっているのだろう。

つくば市が「TSUAPP0002」という名前に決めたという、そのPKIに対する無理解ぶりも酷いものだが、そんなデタラメな名前の証明書を発行してしまう認証局があるということは信じ難い。

もう、日本のPKIはめちゃくちゃだ。

おそらくもう取り返しがつかないだろう。あと5年はこのままデタラメぶりが続くと予想する。

信頼済みサイトゾーンのセキュリティレベルは「中」でなくてはならない

総務省総合通信基盤局が「総務省 電波利用 電子申請・届出システム」の稼働を開始していた。その「電子申請のための準備のページを見ると、「信頼済みサイトの設定方法について」として、次のように設定するようユーザに指示している。

[セキュリティ]タブの[信頼済みサイト]を選択し、[サイト]ボタンをクリックします。 ブラウザの初期状態ではこのゾーンのセキュリティのレベルは「低」に設定されています。セキュリティのレベルは「低」「中低」または「中」に設定してください。

総務省 電波利用 電子申請・届出システム, 信頼済みサイトの設定方法について

ここは、「中」に設定しなければならないところだ。なぜなら、

[このゾーンのサイトにはすべてサーバーの確認(https:)を必要とする]のチェックをはずします。

総務省 電波利用 電子申請・届出システム, 信頼済みサイトの設定方法について

という設定をさせるからだ。

この「このゾーンのサイトにはすべてサーバーの確認(https:)を必要とする」の設定が、その意味が理解されないまま、オフにするように指示されている。

この項目がデフォルトでオンになっている理由は、[memo:4952]に書かれているように、ドメイン名だけでセキュリティゾーンを切り替えるのは、DNSスプーフィング攻撃などに弱く(SSLでサーバ証明書検証が必要とされている理由の一つ)、たとえその可能性がそれなりに小さいのだとしても、それによってセキュリティレベルが「低」となってしまうのは、リスクが可能性に比べて大きすぎるということだろう*1

実際、マイクロソフトの「ブラウジングと電子メールの安全性を強化する(ハッカーや攻撃者から身を守ることができる3 つのステップ)」という解説の中でも、「ステップ 2: 安全であると考えられる Web サイトを [信頼済みサイト] に追加する」という指示があるが、きちんとその後に、

[このゾーンのセキュリティのレベル] にあるスライダのつまみを [中] に移動します。 これにより、信頼するすべての Web サイトのセキュリティのレベルが [中] に設定されます。
と、正しい手順が書かれている。

総務省総合通信基盤局と同じ過ちは、他にも随所に見られる。

たとえば、7月24日の日記「パソコンユーザを国際電話ダイヤルアップ被害に陥れるNEC」で、「「署名済みActiveXコントロールのダウンロード」の「有効」チェックボックスをチェックします」というとんでもない危険な設定を指示していたことを書いたが、その後このページは改定されて、代わりに、信頼済サイトゾーンを使う設定方法が追記されたが、

「次の Web サイトをゾーンに追加する」に次のURLを入力し、「このゾーンのサイトにはすべてサーバーの確認(https:)を必要とする」のチェックを外して「追加」ボタンをクリックします。

NECパーソナル商品総合情報サイト 121ware.com サポート情報番号 004532

と指示しているにもかかわらず、信頼済みサイトゾーンのセキュリティレベルを「中」にするようには指示していない(デフォルトでは「低」)。

素人にセキュリティ設定の説明を書かせるのは、いいかげんやめて頂きたいものだ。

これはスキルとか知識の問題ではない。セキュリティ設定というシビアなものについて、デフォルト設定でチェックされているもののチェックを外させるということは、それが何を意味するかを当然考えてみてしかるべきだ。考えても意味がわからないのなら、セキュリティを業務にしている人に相談してからにするべきだろう。

使ってもいない機能を意味もわからず有効にさせる人たち

総務省 電波利用 電子申請・届出システムの解説には、こんなものもある。

本システムでは、通信を行うためにクッキー(Cookie)を利用します。下記の手順でブラウザのクッキーの設定を確認してください。

ブラウザの初期状態ではプライバシーの設定は「中」に設定されています。 (略) 3.[自動Cookie処理を上書きする]をチェックし、[受け入れる]又は[ダイアログを表示する]を選択してください。

総務省 電波利用 電子申請・届出システム, 電子申請のための準備 3.ブラウザの確認 - クッキー(Cookie)の設定を確認

図のように、サードパーティのCookieも「受け入れる」にしろと指示している。

本当にサードパーティのCookieを使っているのか? 普通は使う必要がないはずだ。初期設定の「中」で、正常に動作するのではないのか?

仮に初期設定の「中」では動かないシステム構成になっているのなら、P3Pのコンパクトポリシーを提示するよう、Webサーバを設定して解決するべきだ。

ようするに、意味もわからずプライバシー設定を変えさせ、人々のプライバシーを犠牲にしている。

同じことをやっているところは非常に多い。たとえば、山梨県の電子申請システムの解説も同じようになっている。

こういうのは、見よう見まねでどんどん感染拡大していくのだろう。もう、止めようがない。

Internet Weekよ、あんたもか

Internet Week 2004の参加申し込みサイトの「よくあるお問い合わせ(FAQ)」にも、次のような指示がある。

【JavaScriptの設定】
  1. メニューバーの[ツール]-[インターネットオプション]を選択します。
  2. [セキュリティタブ]を選択します。
  3. [レベルのカスタマイズ]を選択し、[Java]の項目で[安全性‐高]にチェック。また、[スクリプト]の項目で[Javaアプレットのスクリプト][アクティブスクリプト][スクリプトによる貼り付け処理の許可]のそれぞれ[有効にする]にチェックし、[OK]を押してください。
Internet Week 2004, よくあ るお問い合わせ, Q2.登録・ログオンができません

本当におまえはJavaを使っているのか? と問い詰めたい。JavaScriptとJavaの区別も付かないだけではないのか? 本当に「スクリプトによる貼り付け処理」をこのサイトで使っているのか? 「スクリプト」と書かれているから意味もわからず、とりあえず「有効にさせときゃいい」と安易に考えているんじゃないのか?

「スクリプトによる貼り付け処理の許可」は「無効にする」にしておかなくてはならない。その理由は以下に説明されている。

*1 Windows XP SP2 で導入されたポップアップウィンドウのブロック機能で、ブロックしないサイトの登録機能に https 云々の機能がないのは、DNSスプーフィングの攻撃の可能性に比べて、それによる結果のリスク(ポップアップウィンドウが出る)が十分に小さいためだろう。

本日のリンク元 TrackBacks(3)

2004年10月22日

行政×マスコミ×フリーライター

次の3つの記事を続けて読むと、何が見えてくるだろうか。

新原: 経済産業省のICタグに関する政策については、インフラ周りの課題、すなわちコード体系の標準化、及びエア・インタフェースの互換性という国際標準化という政策、および価格低減という政策課題の二点に集中して、民間企業の邪魔はしないというのが基本的な方針です。 あなたの知らないICタグの(本当の)話

ICタグのブレークは来年 自戒の念を込めて言う。新聞や雑誌でICタグの話題を目にする機会は増えたが,新たな動きだけを散発的に報道する傾向があった。加えて,新聞や雑誌の報道内容のほとんどは国内外の標準化動向や実証実験,プライバシ問題などに偏っていた。 (略) 誰かに入れ知恵された経営陣や上司が「うちはICタグをやらなくていいのか」と,ある日突然言ってくるかもしれない。いまのうちに,すべてのITプロフェッショナルの方にICタグに関する正しい知識を持ち,誤解や認識のズレをなくしておいていただきたいと思っている。 ICタグのこと,どのくらい知ってますか?

RFIDを話題にするなら、きちんと世間に向かって知らせるべきことを報じ、問うべきことを論じねばならない。そうやって自分たちの存在価値を判断してもらうべき時がきたように思う。根拠はないが、日本のITジャーナリズムの見識と品性が、どうも世界中から疑われている気がしてならない。われわれは、 RFIDについて何をどこまで伝えているのだろう? (略) 経産省や総務省がやるなら、と農水省も国土省もあれこれの開発テーマを挙げて予算取りに走った。そして官の御用達とあれば、何でもありがたがるIT企業がそれに群がった。この連中は、「コンセプトがおかしい」とか「こんな開発実験は意味がない」などと言い立てることは決してしない。与えられたテーマが曖昧でも、欲張り過ぎでも、逆に喜ぶ習性がある。「課題」が多いほど来期以降の受注に繋がるかもしれないからだ。そして、手っ取り早くカタチに残せそうな「実証実験」なるものに取り掛かる。 (略) 「タグ付き本」も悲惨なアイデアのひとつ (略) 総論:RFID報道の大間違いを正す

富士通がRFIDコンサルティング

  • 富士通、RFIDの導入コンサルティングを商品化, 日経ソリューションビジネス, 2004年10月21日
    富士通は10月21日、ユーザー企業がRFID(無線ICタグ)を活用したシステムの導入を支援する「RFIDシステム導入コンサルティングサービス」の提供を開始した。同社はこれまでに手掛けたRFIDの導入や実証実験でのノウハウを蓄積し、商品化の準備を進めていた。(略)

これまでの実績といえば、バーチャル昆虫採取とか。

テレビ東京放送のこの映像で、話している人たちの表情が気がかりなところ。どんな発言がカットされているのかが興味深い。

CSS2004に行ってきた

情報処理学会コンピュータセキュリティシンポジウム2004に行ってきた。初日は別の用事と重なって行けなかったため、RFIDセッションを聴けなかった。まことに残念。

来月10日に、こういうイベントが開催されるとのこと。

頂いたチラシから引用:

RFIDに関する国際ワークショップシリーズ 〜情報共有とプライバシー〜

場所: 東京理科大学 森戸記念会館 主催: 産業戦略的研究フォーラム, 九州大学システムLSI研究センター 参加費: 1000円

[趣旨の説明] ICタグに代表されるRFID (Radio Frequency Identification)技術は、私たちの日常生活に新しい可能性と未知のリスクをもたらします。RFID技術の最良の利用法を本質的に明らかにするためには、要素技術の進歩とともに、私たちの日常生活に関わる技術的・社会的・物理的なインフラストラクチャを再考する必要があります。本ワークショップの目的は、システムデザイナー、ハードウェア・ソフトウェア・セキュリティ・HCI分野の研究者、経済学者、社会学者等が以下の2点を軸に学術的な議論を行うことのできる場を提供することです: ・異なる視点、考え方、アイデアを持ち寄り建設的な議論を行う ・今後3〜5年のRFIDに関わるプライバシーおよび情報共有についてどのような研究を行うべきか明らかにする。

本日のリンク元 TrackBack(0)

2004年10月27日

信頼あるドメイン名の意義を軽視する地方自治体の愚行

全国の都道府県の電子申請システムが続々と稼動を始めつつあるが、そのいくつかは独自ドメインを使用している。例えば以下などがそうだ。

フィッシング詐欺の流行が懸念されているこのご時世に、ニセのドメインと区別しづらいこうしたドメイン名を使うというのは不用意なことであり、これらはセキュリティ意識の欠如した人物が企画したものと推察される。

一般に、Webを使うにあたってユーザは、自分が使うアクセス先サイトの本物のドメイン名を普段から暗記しておかなくてはならない。山梨県の電子申請システムを使う市民たちは、「ycma.jp」という名前をきっちりと覚えておかないといけない。「ymca.jp」と見間違えたりするようでは危険である。富山県を使う人は、本物は「e-toyama.net」であって、「i-toyama.net」ではないし「e-toyama.org」でも「e-toyama.jp」でもないことを知っていなくてはならない。

「i-toyama.net」や「e-toyama.org」などのドメインは誰でも簡単に取得できてしまう。「i-toyama.jp」ドメインも誰でも取れるだろう。徳島県は「tok-j.info」だそうだ。なぜ「.info」などという信頼性の最も低いものを使うのか。案内ページだけでなく、個人情報入力画面自体が「tok-j.info」上に置かれている。

自治体には昔から地域ドメインが割り当てられてきたし、さらに2002年からは「lg.jp」という地方公共団体向けの専用ドメインが用意された。せっかく用意されたのに、これを使わないのは愚かである。

  • 地方自治体専用の「LG.JP」、年内の新設を目標に検討へ, INTERNET Watch, 2002年6月3日
    現在、地方自治体のウェブサイトでは地域型JPドメインを利用する例が多く見られる。ただし、地域型JPドメインは一般にも開放されているため、電子自治体サービスを安心して利用できるよう、地方自治体専用の信頼できるドメイン空間が必要との意見が寄せられていたという。

  • LG.JPドメイン名について, 総合行政ネットワーク全国センター
    LG.JPドメイン名創設の目的 地方公共団体では、政府がe-Japan戦略に掲げる電子政府・電子自治体の実現に向け、住民・企業がインターネットを利用していつでもどこでも申請・届出等の手続が行える仕組みづくりを進めています。 匿名性が高いインターネット上で、住民・企業の皆様が安心して行政サービスを利用できるようにするためには、まずは行政サービスの提供者が地方公共団体であることを、住民・企業の皆様に分かりやすく示す必要があります。このため、政府機関等を収容するドメイン空間「GO.JP」に対応する、厳密に地方公共団体及び地方公務員を収容した住民・企業の皆様に分かりやすい地方公共団体行政専用のドメイン空間が必要とされました。 LG.JPドメイン名の創設は、地方公共団体組織認証基盤(LGPKI)の整備などと合わせて、地方公共団体が提供する電子行政サービスの信頼性を確保し、住民・企業の皆様が安心してサービスを受けられるようにすることを目的としています。 (略)

    行政サービス用ドメイン名とは? 行政サービス用ドメイン名とは、LG.JPドメイン名のうち、地方公共団体が行う行政サービスで、総合行政ネットワーク運営協議会が認定したものを登録対象とするドメイン名を指します。例えば、XX県と県内の市町村が共同で、「XX電子申請サービス」を提供する場合に、”SHINSEI-XX.LG.JP”といった行政サービス用ドメイン名を使用することが考えられます。(略)

このようにして登録が行われている lg.jp ドメインであるのだから、市民は、たとえドメイン名を正確に覚えていなくとも、今見ている画面のアドレスバーのURLのドメインが「…….lg.jp」でありさえすれば、とりあえず詐欺サイトでないことは信じてよいことになる。

山梨県、富山県、茨城県、徳島県がなぜ lg.jp ドメインを使わなかったのか、その言い分を聞いてみたいところだ。

アドレスバーなんかどうでもいいと思っているような連中(フィッシング詐欺が流行ればイチコロで騙されるような連中)が、「.net の方がクールだよねー」「これからは .info ですよー」といったノリでやったのではない、何か別の理由があるのだろうか。

WIDEはど素人か

IC2004の申し込みページを見に行った(初めて見に行った)ところ、こういう説明がされていた。

  • WIDEプロジェクトのメンバーでない皆様へ暗号化されたページについてのご注意
    WIDEプロジェクトのメンバーでない方が暗号化通信(SSL)を使った受付ページにアクセスすると、表示する前に警告が出ると思います。 ここでは、その警告がどういうものかについて説明して、どうすればよいかについて解説します。 (略) 今回インターネットコンファレンスの参加申し込みサーバでは、イベントの共催団体であるWIDEが、イベントの参加申し込みをする人の個人情報を、通信路上で保護するために、サーバ証明書を用意しました。 このサーバ証明書は、ブラウザにあらかじめ登録されているものではないので、申し込み開始時に「信用できるかどうかわからないサーバ証明書を使って暗号化通信をしようとしている」という警告が出ます。
「信用できるかどうかわからない」という表現が、書いた人物の無知ぶりを表している。
どうすればよいか 既にいろいろなチャネルから通知をさせて頂いているCFP等と、Webページの内容を照らし合わせていただき、「www.internetconference.org」の信憑性をご確認頂いた上で、サーバ証明書を使用してください。

「信憑性」を確認しろ? アホか。そういう問題ではないことをいいかげん理解してくれないか。プロだろあんたら。

「個人情報を通信路上で保護するため」に用意したと言っているのだから、盗聴されない通信路が確保されることが期待されているはずである。証明書の認証パスが検証できない状態では、中間者攻撃により通信内容が盗聴(復号され、再度暗号化して中継)されていても、ユーザ側に気付くすべがないことを理解しろ。

注意書きをするならこうだ。


本来ならば、個人情報保護のため、きちんとしたSSLで通信内容を暗号化するべきところですが、このためだけにお金をかけるのは避けたかったので、自前の実験用証明書でやっています。そのため、中間者攻撃による通信内容の盗聴はできてしまいますが、単純にパケットを傍受するだけの「ちょっと見」盗聴はいちおう防げています。その程度のものだと思って使ってください。

WIDEでさえPKIの基礎を理解していないのだから、電子政府がまともに構築されるはずがない。

moCAは証明書を使った実験を行なう為の認証局です。

おたくらいったいこれまで何を「実験」してきたのか。動かせばそれで実験なのか? そんな意味のない実験などやめてしまえ。カス。

RFIDタグのデータを暗号化することが禁止される事例

公正取引委員会が10月21日に以下の発表をした。

公正取引委員会は,キヤノン株式会社(以下「キヤノン」という。)に対し,キヤノン製カラーレーザープリンタに使用されるトナーカートリッジ(以下「カートリッジ」という。)にICタグ(注1)を搭載し,ICタグに搭載されたICチップに記録された情報の解析や書換えを困難にし,当該カートリッジの再生品(注2)が作動しないようにすることにより,再生業者(注3)が当該カートリッジの再生品を販売することを困難にさせている疑いがあったことから,独占禁止法の規定に基づいて審査を行ってきたところ,次のとおり,現在までに再生業者が再生品を再生販売することが可能となっていると認められたことから,審査を終了することとした。(略)

(注1) ICタグとは,ICチップとアンテナにより構成され,物品に搭載されるものであって,その中に当該物品の識別情報その他の情報を記録し,電波を利用することによりこれらの情報の読み取り又は書き込みができるものをいう。 (略)

公正取引委員会はこの文書の最後で次のように指摘している。

<別紙> レーザープリンタに装着されるトナーカートリッジへのICチップの搭載とトナーカートリッジの再生利用に関する独占禁止法上の考え方

近年,レーザープリンタに使用されるトナーカートリッジ(以下「カートリッジ」という。)にICチップが搭載される事例が増えている。レーザープリンタのメーカーがその製品の品質・性能の向上等を目的として,カートリッジにICチップを搭載すること自体は独占禁止法上問題となるものではない。しかし,プリンタメーカーが,例えば,技術上の必要性等の合理的理由がないのに,あるいは,その必要性等の範囲を超えて

(1) ICチップに記録される情報を暗号化したり,その書換えを困難にして,カートリッジを再生利用できないようにすること

(2) ICチップにカートリッジのトナーがなくなった等のデータを記録し,再生品が装着された場合,レーザープリンタの作動を停止したり,一部の機能が働かないようにすること

(3) レーザープリンタ本体によるICチップの制御方法を複雑にしたり,これを頻繁に変更することにより,カートリッジを再生利用できないようにすること

などにより,ユーザーが再生品を使用することを妨げる場合には,独占禁止法上問題となるおそれがある(第19条(不公正な取引方法第10項[抱き合わせ販売等]又は第15項[競争者に対する取引妨害])の規定に違反するおそれ)。(略)

RFIDタグの応用方法によっては、誰にでも読み書きできる状態とすることが義務付けられることもあり得るらしい。

その場合は、通信可能距離を数センチ以内とする必要があるだろう。

本日のリンク元 TrackBack(0)

2004年10月29日

NHKはいったい何がしたかったのか

先週、大きな地震があった。すぐさまテレビをつけ、NHKにチャンネルを合わせると、新潟で震度6強だと伝えていた。しばらくすると、被災地にお住まいの方々の安否の確認ができるよう、NHK教育テレビで伝言サービスを始めるとアナウンスされた。チャンネルをNHK教育に切り替えると、アナウンサーが「エッチティティピーコロンスラッシュスラッシュ……」と連呼していた。アナウンスされていたURLは「http://www.nhk.or.jp/anpi/」だった*1

しばらくすると、テレビ画面に、「心配です連絡ください」といった1行メッセージとともに、心配して連絡を求めている人と、心配されている人の、氏名および住所、たまに電話番号までもが映し出された。

この毎日新聞の記事の写真にあるようにだ。

ギョっとした。いわゆるズバリ「個人情報」である。これまで散々、「個人情報」の取り扱いに注意が必要ということに取り組んできたためか、見ただけでギョっとしてしまう。

この感覚は誤りなのだろうか。「緊急時なのだから個人情報保護なんて言っている場合じゃないだろ」「しょせん個人情報なんてその程度のものだ」「おまえはこんなときにまで個人情報保護とか言うのか」という声が頭をよぎる。

いや待て、少なくとも次の問題があるように思える。

  1. 知人を心配して「連絡ください」と連絡先を公表している人は、自分の意思で自分の個人情報を提供・発表させたのだから自業自得であるにしても、勝手に住所を公開された知人の方の意思はどうなのか?
  2. 番地まで公表することに意義があるのか? 知人同士が連絡を求めているのだから、「東京都○○区の△△△△さんから新潟県○○市の△△△△さん」といった程度の表記に止めておいても、所期の目的は達成されるはずではないか?
  3. 情報提供者たちは、ここまで全部がテレビに放映されるとは理解しないまま、情報を提供した可能性はないのか?

そして当然ながら「これはオレオレ詐欺に悪用されかねない」と心配になる。

そして今週、実際そうした詐欺事例が発生したとの報道が出た。

  • 新潟中越地震:消防署員かたり詐欺未遂 TVの安否情報悪用、振り込み要求−−東京, 毎日新聞2004年10月27日朝刊
    新潟県中越地震に便乗し、消防署員をかたり、東京都江戸川区の女性方に「被災者をとりまとめて振り込みの依頼をしている」と電話がかかっていたことが26日、分かった。NHKの番組で放送された住所と名前が悪用されたとみられ、女性は地元消防署などに相談して被害は免れた。
  • 震災おれおれ詐欺…安否情報を悪用、被災者へ送金装う
    同区や江戸川消防署などによると、NHKの番組で新潟県内の親族に連絡を求めていた同区大杉の女性宅に、25日午後零時半ごろ、男の声で「被災者をまとめ、振り込みの依頼をしたり、お金を下ろして届けたりしている。(女性の親族が)お金を必要としているので振り込んでほしい」と電話があった。
  • 安否情報番組を悪用、おれおれ詐欺, 日刊スポーツ九州, 2004年10月27日
    東京消防庁などによると、同番組で新潟県栄町のいとこに「連絡がほしい」と、江戸川区大杉在住の女性が24日午後に住所と氏名を公開してメッセージを出したが、25日午後0時半ごろ突然電話がきた。「いとこは小学校に避難している。私は被災者を20人ぐらいとりまとめて振り込み依頼をしたりお金をおろしている。いとこは『お金が必要』といっているので午後2時までに振り込んでほしい」と30代ぐらいの男の声だった。

ちなみに、毎日新聞社も「新潟地震安否情報掲示板」という同様のサービスをしていたが、こちらでは、住所は県名まで、または市町村名までを書くよう指示しており、個人情報への配慮が見られる。

  • 毎日インタラクティブ新潟地震安否情報掲示板
    この掲示板は新潟地震に関連する安否情報を書き込む掲示板です。投稿される方は住所(都道府県まで)、氏名を記入して、メッセージ欄に安否を尋ねる人の名前、住所(市町村名まで)、伝えたいことを入力してください。

そして、被災地でも詐欺が起きていたらしい。

  • 震災便乗詐欺事件に注意, NHKニュース, 2004年10月27日
    新潟県内では、地震被害に便乗して「あなたの娘さんが交通事故を起こして、けがをしている。医療機関は満杯で交通もマヒしているため、ヘリコプターを飛ばすことになり、そのための費用を振り込んでほしい」という電話で、金をだましとる詐欺事件がありました。(略)

「NHKよ、おまえが言うんか?」という気もするが、ただ、こちらは、毎日起きている無差別なオレオレ詐欺がたまたま被災地に起きた可能性もある。

「あんな、必要もなく番地まで公開するのは間違っている」とか、「オレオレ詐欺に使われるに決まっている」と感じた人は他にも多数いたようで、検索してみると、同様の感想が書かれたブ日記がいくつか見つかる。

さらには、そもそもこんな放送をしても役に立たない(被災された方がこんな放送を延々と見ているはずがないし、他にもっとよい方法がある)とする意見もちらほら見つかる。

朝日新聞の記事によれば、NHKは、地上デジタル放送の双方向機能を使って、検索できるようにもしていたそうだ。

人は、自分の行いが他人のため、善意でやっているのだとの認識を持った時点で、それが危険をももたらす可能性がある場合においても、そこに考えが及びにくくなるものなのかもしれない。さらには、その行いが実はたいして役に立たないのだという可能性にも、あえて気付こうとしないのかもしれない。

ひどい場合には、問題点を指摘されても、「良いことをしてはいけないと言うのか?」と、話を聞き入れようとしない心理状態(逆切れ)に陥るかもしれない。単に「改善した上で実施する方法がある」と言われているにもかかわらずだ。

そうした現象は、小学生のランドセルにアクティブ型RFIDタグを付けさせる人たちにも見られるかもしれない。

悪しきプライバシーポリシー慣習の蔓延が肝心なときにダメにする

ところで、情報の入力を受け付けていた http://www.nhk.or.jp/anpi/ の画面の末尾には、次のように書かれていた。

・登録された情報は、内容が安否情報として適切かどうかを点検の上で公開しますので、登録してから検索できるようになるまで時間がかかる場合があります。 ・登録された情報に明らかな誤りや不適切な表現が含まれる場合には、登録者への告知なく情報の内容を変更したり、削除したりする場合があります。 ・安否情報システムにご登録いただいたみなさまの個人情報は、安否を確認する目的以外に利用することはありません ・インターネットで登録された情報は、登録者への告知なく放送で利用する場合があります ・情報の削除を希望する方は下記へ連絡ください。(略)

ここでも、誤って広まってしまったプライバシーポリシーの書き方の習慣が、害をもたらしている。

Webの世界では、何年か前から、プライバシーポリシーなるものを提示することがだいぶ一般的になっていた。しかし、何を掲示するべきかを勘違いして書かれたものが非常に多かった。

正しい「プライバシーポリシー」とは、そこで入力した情報がどのように扱われるかを正確に表明することである。ところが、ほとんどのサイトは、「不正な目的には使用しません」という視点で表現された文章になっている。

おそらくプライバシーポリシーを書かされている人たちには、

プライバシーポリシーを書けって? どうしたそんなもの書かないといけないの? うちの会社が不正な目的で使うわけがないじゃないか。
という意識があるのではなかろうか。そういう意識があると、「そういうことはありません」という文章になってしまう。

本来なすべきことは、どんなに当たり前であっても、収集した情報をどのように使うかをそのまま書くことだ。たとえば通販サイトならば、

入力された情報は、商品発送のあて先としてのみ使用します。
という表現になるはずである。

NHKの今回の安否情報のページであれば、本来なすべきことは、入力された住所氏名が、番地まで隠すことなくそのまま教育テレビで全部が放映されるということ、また、Webでの検索や、地上デジタル放送の双方向機能で、どのように閲覧されるかを正確に書くことだったはずである。

それは面倒な作業なのかもしれない。そこへきて、プライバシーポリシーの変な書き方が蔓延してしまったがゆえに、「安否を確認する目的以外に利用することはありません」などという否定形の文章(何をするのかは曖昧な説明のままで済まされる)を書くだけで満足してしまう(義務を果たしたと錯覚してしまう)という現象が起きているように思える。

ちなみに、毎日インタラクティブの安否情報掲示板もダメだ。

情報を記入する画面に、

プライバシーについて(必ずお読みください)
と注意書きされているが、リンク先の「プライバシーについて」は、mainichi-msn.co.jp 全体の一般的なプライバシーポリシーのページになっていて、個別の記入欄の情報がどう扱われるかが書かれているのではない。

サイト全体とか、会社全体でのポリシーを書こうとすれば、当然ながら抽象的なものにならざるを得ない。そうでなければ長大な文章にならざるを得ない。つまり、誰も読まないか、読んでも意味のない文章にしかなりようがない。

日本のプライバシーポリシーの書き方は根本的に間違っている。

*1 アクセスしても数十分もの間、このページは404 not foundだった。まだ準備もできていないページを盛んにアナウンスしてアクセスを促していた。おそらく、「つながりません」という問い合わせの電話が大量にNHKに寄せられていたことだろう。ただでさえ貴重な災害時の電話回線がそれで食いつぶされていたに違いない。

本日のリンク元 TrackBack(0)

2004年10月30日

開発者のプライドか、それとも「脆弱性」のネガティブイメージの影響か

ソフトウェアにセキュリティ脆弱性が見つかると、そのソフトウェアのことを蔑 んで見る人がいるかもしれない。たとえば、「マイクロソフトは糞だ」みたいな ことを言いたい人からすれば、同社の製品に脆弱性が見つかると軽蔑の目でもっ てその事態を見ることになる。

さて、JVN#E59B594Bが 発表された。 これは、 鶴亀メールのS/MIME機能*1が、署名メールの証明書パス(証明 書チェイン)が検証されないものだったという欠陥である。

これについてのベンダーからの告知は、「改版履歴」のペー ジで次のように説明されている。

2004/10/16 V3.69 -> V3.70 バグ修正/仕様変更
  • [重要]メールが1通も無いフォルダ上で「下の未読メール」などを実行すると死んでしまうことがあるバグ修正。(V3.69でのレベルダウン)
  • [重要]S/MIME電子署名されたメールの検証で、電子署名自体は検証しつつも、証明書の検証がなされてなかったバグ修正。証明書が失効されてるかどうかもチェックできるボタンも追加した。
    (略)

「電子署名自体は検証しつつも」といっても、S/MIMEにおいては、証明書の検証がなされなければ、電子署名としての役割を全く果たさない。

なぜなら、S/MIMEにおいては、メールに署名を施すと、その署名を検証するため の公開鍵が証明書の形式で添付されて、本文や署名と共に送信される。受信側は、 送られてきた本文、署名、証明書から、本文が改竄されていないかを確認するこ とになるが、当然ながら、受信した証明書までもが同時に改竄されている可能性 があるわけだから、証明書が本物かどうかを何らかの方法で確認しなくてはなら ない。それを処理するのが、証明書パスの検証*2である。

しかしながら作者氏は、サポー トフォーラムにおいて次のように述べていた。

秀まるお2 さん 04/10/14 16:40

実は、とあるセキュリティ関係の人から連絡を受けたんですが、鶴亀メールの S/MIME関係で脆弱性があります。脆弱性と言われたのでこりゃ大変だと 思ったですが、実は以前から僕自身が手抜きしてた所でして…

S/MIME電子署名されたメールを検証する時に、実は鶴亀メールはその電子署名の 有効期限のチェックをしていません。なので、有効期限が切れていても、特に有 効期限が切れているとかってメッセージが出ないです。

あと、電子署名された証明書のパスというか、その電子署名の発行元、さらには それの発行元(最終的にはベリサインに行き着く?)の検証もしていません。な ので、仮にそういう、個人で作ったような証明書であっても、特に警告は出ない です。

その辺ご注意お願いします。

秀 シリーズサポートフォーラム, 鶴亀メール 情報交換, S/MIMEでの脆弱性の報告

秀まるお2 さん 04/10/14 22:40

とりあえず、

  1. 証明書の期限のチェック。
  2. 証明書パス(certificate chain)についての正当性の検証。具体的には、CertVerifyCertificateChain関数によるチェック。
  3. 証明書のメールアドレスとメールのFrom:メールアドレスの一致チェック。

を入れることにします。(略)

ただ、元々こういうチェックをしてないからといって、それを「脆弱 性」 呼ばわりされるのはどうかという気もします。例えば、証明書の有効 期限を過ぎ照る場合に「有効期限を過ぎてない」と出したらまずいでしょうが、 有効期限について特に何も言ってない分には問題ないというか、そういう仕様 (チェックしてないという仕様)でもいい気もします。

秀 シリーズサポートフォーラム, 鶴亀メール 情報交換, S/MIMEでの脆弱性の報告

修正されたようなので問題点は理解されたようにも見受けられるが、「チェック しない仕様でもいい気もする」というのはどういうことだろうか。

有効期限について期限切れでも警告を出すことがない(期限を表示させて目で確 認する方法が別途用意されている)というのは、あり得るかもしれないとしても、 証明書パスの検証をしない仕様というのは、S/MIME対応を謳う限り、あり得ない ことだ。

作者氏はなぜこういう思考をしてしまうだろうか。「脆弱性と言われたのでこりゃ 大変だと思った」が、大変なことじゃなかったという認識だと思われる。「脆弱 性だ」と認めるのは受け入れがたいことなのだろうか。

ひとつの可能性は、「脆弱性」という言葉が、凶悪なワームに即座に感染するよ うなものだけを連想するという、狭い意味で理解されているのかもしれない。

しかし、S/MIME対応と聞いてそのメーラを使っている人が、信頼する相手から電 子署名されたメールが来たため、完全にその内容を信用して、次のアクションを 起こした(添付ファイルを開くとか、リンク先に情報を入力するとか)ときに、 それが偽だったことによって受け得る被害は、「こりゃ大変だ」という感想に相 応しいものとなり得るはずだ。

「脆弱性」とは、単純に、ソフトウェアの欠陥のうち、悪意ある者によって意図 して悪用される危険性(攻撃にさらされやすい)のあるものを指す。

そして、ソフトウェアの「欠陥」とは、仕様(明示的および暗黙的な)を満たさ ないものを指すのであり、S/MIME対応を謳う仕様においては、証明書パスを検証 しないのは、仕様を満たしておらず、単純にそれは欠陥である。

欠陥とか脆弱性という言葉は、本来は単に事実を指す言葉であるが、社会的な気 運のなかで、言葉にネガティブなイメージが付きまとうことはあるかもしれない。 しかし、だからといって、技術者が、そうした言葉で表現せざるを得ない事実の 指摘を受け入れがたいと感じるようでは、個人的軋轢や社会的困難が生ずるであ ろう。

もし、無償ソフトや評価版などにおいて、実装をサボった状態でリリースしたい のであれば、S/MIMEには完全には対応しておらず、何と何が未サポート(だから 何々には注意せよ)だとする説明の下で配布すればよい。

念のため、S/MIMEの仕様を確認しておく。

RFC 3850「Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling」には次の ように書かれている。

4.2. Certification Path Validation

In creating a user agent for secure messaging, certificate, CRL, and certification path validation SHOULD be highly automated while still acting in the best interests of the user. Certificate, CRL, and path validation MUST be performed as per [KEYM] when validating a correspondent's public key. This is necessary before using a public key to provide security services such as: verifying a signature; encrypting a content-encryption key (ex: RSA); or forming a pairwise symmetric key (ex: Diffie-Hellman) to be used to encrypt or decrypt a content-encryption key. (略)

また、Security Considerationsの節には次のように注意書きされている。

Some of the many places where signature and certificate checking might fail include:

  • no Internet mail addresses in a certificate matches the sender of a message, if the certificate contains at least one mail address
  • no certificate chain leads to a trusted CA
  • no ability to check the CRL for a certificate
  • an invalid CRL was received
  • the CRL being checked is expired
  • the certificate is expired
  • the certificate has been revoked

There are certainly other instances where a certificate may be invalid, and it is the responsibility of the processing software to check them all thoroughly, and to decide what to do if the check fails.

追記

「電子署名自体は検証しつつも」といっても、S/MIMEにおいては、 証明書の検証がなされなければ、電子署名としての役割を全く 果たさない。
と書いたが、他のソフトウェアなども見てみるに、どうも、このような、本文ダ イジェストと署名の突合せをするだけでも、それに意義があると思っている開発 者がけっこういるようだ。たしかに、悪意がない状況で、通信路上で一部が書き 換わったものを検出することはできるだろう。

だが、それがしたいのなら公開鍵暗号なんて使わなくていい。チェックサムでも 使っておけばいい。

JVNにおける「想定される影響」の書き方

今回の事例で、「想定 される影響」の項目は、

想定される影響

自己署名証明書によって生成できる任意のメールアドレスを詐称する証明書で S/MIME署名されたメールを受信しても、受信者は詐称メールであることに気づか ない可能性があります。

と書かれているが、これは届出者(私)が次のように報告したところから影響さ れたものだろう。

6) 脆弱性により発生しうる脅威

自己署名証明書によって生成できる任意のメールアドレスを詐称する証明書で S/MIME署名されたメールを受信しても、受信者は詐称メールであることに気付か ない。S/MIMEとして誤った実装であり、なりすまし防止としての機能を果たして いない。

しかし、これらの説明は、技術者向けにはよいとしても、一般ユーザ向けにはど うだろうか。「自己署名証明書によって生成できる……」とかいう書き出しになっ ている時点で、既に読まれないのではなかろうか。

というわけで、次回からは、「脆弱性により発生しうる脅威」には一般ユーザ向 けの説明を冒頭に書くように心がけることにする。

今回の件ならば、次のように書くべきであった。

偽の証明書で電子署名されたメールを受け取っても、本物と区別されないため、 S/MIMEが本来提供するはずの、なりすまし防止や、改ざん防止の機能が有効に働 かない。

具体的には、自己署名証明書などで生成できる任意のメールアドレスを詐称する 証明書でS/MIME署名されたメールを受信しても、受信エージェントは、証明書パ スを検証しないため、詐称メールであることを検出しない。また、メール本文が 改ざんされて届けられた場合にも、証明書も同時にすり替えられていれば、その 事実は検出されない。

*1 「鶴亀メールの紹介」 のページには、「PGP(PGP/MIME形式も含む)、GnuPG、S/MIMEなどのメールの暗 号化/電子署名にすべて対応。」とある。

*2 ルート認証局もしくはそこから 認証された中間認証局により発行された証明書が使われているかどうかを検証す る。具体的には、その証明書に、それら認証局の署名が正しく施されているかど うかを調べる。

本日のリンク元 TrackBack(1)

最新 追記

最近のタイトル

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|
最新 追記