高木浩光＠自宅の日記(2005-03)

2005年03月05日

■ Suica番号がメールアドレスと結び付けられ始めた

昨日はIC CARD WORLD 2005の展示を見に行ってきた。通りがかりに上野駅のコンコースを通ると、﹁Suicaポスター﹂というイベントが展開されていた。これのことらしい。 ●Suicaを使った新しい交通メディア﹁Suicaポスター﹂登場！, ジェイアール東日本企画, 2005年2月16日 ●JR上野駅でSuica利用を促進するキャンペーン, ITmediaニュース, 2005年2月22日 ●JR上野駅にSuica対応の自販機やコインロッカーが登場, ケータイWatch, 2005年2月22日すぐさま嫌な予感がしたので、とりあえず登録を試してみると、まず、プライバシーポリシーが存在しない。 Suica番号を入力するサイトに﹁利用規約を読む﹂というリンクがあるが、﹁1.適用範囲﹂から始まって﹁2.期間﹂﹁3.サービス内容﹂﹁4.登録︵利用開始︶の申し込み﹂﹁5.登録内容変更﹂﹁6.登録解除︵利用終了︶の申し込み﹂﹁7.禁止事項﹂﹁8.免責﹂﹁9.規約の変更﹂﹁10.配信の停止﹂とダラダラダラダラと長文が書かれており、携帯電話画面でスクロールさせるだけで相当な時間がかかるところまで進めてやっと﹁11.登録情報の取り扱い﹂という条項があるだけだ。そして﹁12.準拠法および管轄裁判所﹂﹁13.規約の発効﹂と続く。読ませる気があるとは到底思えない。﹁登録情報の取り扱い﹂よりも、﹁禁止事項﹂の方が上にあることが何を意味するか考えてみるとよい。﹁11.登録情報の取り扱い﹂には次のように書かれていた。 (1) 当社は、登録ユーザが本サービスの申し込み時に登録した登録情報︵変更情報を含みます。以下﹁登録情報﹂とします。︶を、合理的な範囲内でセキュリティの強化に努めるものとします。 (2) 当社は、登録情報を、原則として秘密保持契約を締結した協力会社以外に開示いたしません。ただし、以下に該当する場合、登録会社以外の機関に開示することがあります。 a. 登録ユーザの同意がある場合 b. 法令等により開示を求められた場合 c. 公共の利益の保護その他正当な理由がある場合 d. 当社が︵ユーザを特定しない形式での︶統計資料を作成する場合 (3) 当社は、本サービスの終了期間後2005年3月末日をもって、本サービスで取得した登録ユーザデータは全て消去抹消いたします。ようするに、何も書いてない。ここでなすべきことは、このメールアドレスとSuica番号がどのように使われるのか、その使用目的を示すことである。﹁秘密保持契約を締結した協力会社以外に開示しない﹂というが、当然ながら、このポスターの広告主も﹁秘密保持契約を締結した協力会社﹂であり得るわけだから、ポスター広告主に私のメールアドレスが渡るのかどうかが気になる。現場の担当者にそれを尋ねると、今回の実証実験では広告主にメールアドレスは渡さないという。今回は実験なので、ポスターにSuicaをかざしただけで詳細情報がメールで届くというシステムを動かすためだけに、メールアドレスを必要としているのだろう。しかし、実用化された際にはどうだかわからない。当然ながら、広告主は自分のポスターに関心を持ってくれた人のメールアドレスが欲しいだろう。しかも、Suica番号は、日ごろの電車利用で記録される入退場履歴と結び付けられて、JR東日本の巨大データベースに蓄積されている。これまで、この入退場履歴データベースは番号だけで管理される半匿名情報だった︵定期券の場合を除く︶のが、今回とうとうメールアドレスと結びつけられるのだ。これはとても美味しいマーケ情報となるはずである。あるポスターに関心を持った人が日ごろどの駅をどんな頻度であるいはどんな順序で利用しているかの分析に利用できてしまう。しかも特徴あるものについて、その人のメールアドレスを特定することも可能となる。そのことを担当者に言うと、担当者は﹁住所、氏名は頂いていませんので……﹂と定番のことを言い始める。たしかに、携帯電話のメールアドレスは秘密にしておく人が多い︵迷惑メールを避けるため︶かもしれないが、メールアドレスは本来公開して使うものであって、人によっては氏名と合わせて公開しているものだ。さらに言えば、Suicaは今や、駅構内の店や一部のコンビニで、物を買うのに使えるようになっている。どのSuica番号の人がいつどの店でいくら買い物をしたか記録しているし、何を買ったかまで記録しようと思えば可能だろう。それらが、﹁JEXXX XXXX XXXX XXXX﹂というひとつの固定ID番号によって結び付け可能になっているところに、とうとうメールアドレスまで結び付けられそうになっている。個人情報保護法では、本人の了解なしに個人情報を流用することを禁じているが、今回の実験では利用目的が示されていないので、何が流用に当たるのかさえわからない。第三者に提供しないのだとしても、JR東日本自身が巨大なデータベースを持っているので、そこにメールアドレスが結び付けられることそのものが、個人のプライバシーリスクに大きな影響を及ぼすのだから、第三者に渡さなければそれでよいという話でもない。この実験では登録手順が面倒すぎたので、実用化には登録をもっと容易にする必要があるだろう。今回は実験終了と同時にメールアドレスは破棄されるとのことだが、実用化されたら、一回の登録で継続的に記録されていくことになるだろう。もしかすると、Suicaカードを購入する時点でメールアドレスを登録するようになるかもしれないし、モバイルSuica︵携帯電話をSuicaカード代わりにするシステム︶がスタートすれば、メールアドレスは自動的に登録となるかもしれない。そのときには、電車の乗り降りも、店での買い物も、メールアドレスと結び付けられる可能性が懸念されることになる。懸念はまだ他にもある。Suicaリーダがいつ読取りをしているか、保証がない。今回のシステムでは2センチメートルの距離まで近づけないと﹁プー﹂と鳴らなかったが、50センチくらいの距離からだって読もうとすれば読めるはずで、担当者にそれを言ってみると、技術的に可能ではあると認める。もし、50センチの距離から読むようにすれば、ポスターの前に立った人のSuica番号を集めることもできるので、魅力的なシステムであるはずだ。もちろん、﹁プー﹂という音を出している以上、音が鳴らない距離でこっそり読み取るなどということを、JR東日本がするはずはなく、そこは信じてよいだろう。だが、他社がそれをやるとしたらどうか。それをJR東日本が止めることはできるだろうか？

■ Edyナンバーをいろいろ流用するのが花盛り

肝心のIC CARD WORLDはどうだったかというと、今年は、RFIDタグを使ったシステムの展示が少なくなっていたようで、これといって問題のありそうな怪しい展示は見つけられなかった︵2時間半しかなかったので見つけられなかっただけかもしれないが︶。流行っていたのは、非接触ICカード︵RFIDカード︶を認証に使うものだった。そのような目的には暗号演算能力を持ったICカードを使うのが本来の姿である。 EdyやSuicaなどとして使われているFeliCaは、現状で最も普及したICカードであり、これをこの際いろいろな目的に使ってみようとする展示が目についた。たとえば、ドアの電気錠の開錠に社員証を使うのでなしに、手持ちのEdyカードを使う︵事前にEdyナンバーを登録するとドアが開けられるようになる︶とか、同様に金庫や貴重品ボックス︵ゴルフ場とかの︶の鍵に使うといったもの。磁気ストライプカードやRFIDタグと違って、ICカードは暗号演算機能を持つので、たとえEdyナンバーが誰でも読み出せるものであっても、リーダとの通信プロトコルにおいて、そのEdyナンバーとしてリーダに認識させるように振舞うことは困難になっているのであるから、このような応用は技術的には正しいといえる。しかし、Edyナンバーは、Edy対応ショップでの買い物履歴と結び付けられている固定ID番号であるのに、このような用途に流用してよいのだろうか？ Edyナンバーを使ったサービスが、Edyを運営するビットワレット社の管理下にある組織のみによって運営されているときは、プライバシーについて信用をすることもできるかもしれないが、こうした流用サービスが誰でも提供できるようになってきたとき、何が起きるだろうか。たとえば、展示会場では﹁ Edyポイントラリー﹂というイベントが展開されていた。これは以下のように報道されている。 ●EdyやSuicaでスタンプラリー〜IC CARD WORLD 2005, ITmediaニュース, 2005年3月2日ようするに、上野駅で展開されている﹁Suicaポスター﹂と同じ仕組みで、携帯電話のメールアドレスとEdyナンバーを結びつけて登録しておくと、いいことがあるよというものだ。ここでもやはりプライバシーポリシーが見当たらない。まあ、上野駅のイベントが一般人向けであるのとは違って、展示会場に来る業界関係者向けの実験なので、こんなものだろう。また、他にも、﹁Edyチャージで5万円当たる﹂という類似のイベントも展開されていた。こちらは、携帯電話に限らずPCからも申し込みが可能で、以前から実施されているもののようだ。ここでもやはり、メールアドレスがEdyナンバーと結び付けられる。ここでは、なぜか生年月日の登録も必要なようだ。ただし、こちらにはちゃんとプライバシーポリシーのページが用意されており、以下のように利用目的が示されていた。 (2)個人情報の利用目的弊社は、お客様からご提供いただく個人情報を下記の目的で使用させていただきます。また、弊社は、個人情報の使用目的の範囲内で必要な業務を委託する協力会社に対し、厳重な個人情報の管理を求めたうえで個人情報を開示することがあります。なお、弊社及び協力会社は、お客様からの問い合わせ対応歴などのお客様に関する個人履歴を記録する場合がありますことをご了承願います。 1.電子マネー﹁Edy﹂5万円分が当たる！Edyチャージキャンペーンの抽選、当選の連絡、及び統計的な集計 2.︵メルマガ購読を希望した方︶電子マネー﹁Edy﹂に関する情報提供キャンペーンにおけるプライバシーポリシー, Edyチャージで5万円分当たる, ビットワレットただ、﹁統計的な集計﹂の意味が不明確だ。﹁それぞれのメールアドレスについてその人がどんな趣味を持っているかの統計的な集計﹂ということだってあり得る。文章として練られていない。上の強調部分は﹁利用目的﹂について書いたものではないだろう。﹁開示することがあります﹂は、次の節﹁個人情報の提供﹂に書くべきだし、﹁問い合わせ対応歴﹂の話もここに書くことではない。法律家に相談せずに作られたものだろうか。

■ 電子パスポートの光学式アクセス制御

IC CARD WORLDの展示会場では、電子パスポート︵e-Passport)の読取り装置のデモを見ることができた。パスポートの電子化については、米国では暗号機能を搭載しないという報道が出ている。個人報漏洩が懸念される﹃RFID﹄タグ内蔵パスポート, Wired News, 2005年2月24日 18日(米国時間)発表の新規定案によると、米国政府はチップ内蔵のパスポートのデータを暗号化するつもりはないという。だが、このような形でのパスポートのハイテク化は新たなセキュリティーリスクを生むという批判が、セキュリティー専門家の間で広く起こっている。日本の電子パスポートもRFID方式による非接触無線読取りとなるのだが、展示ブースの説明員さんによると、日本のものでは、光学式読取りを併用した﹁BAC﹂(Basic Access Control) という機能が搭載されるからそうした問題はないのだという。どういう仕組みかというと、パスポートには現行のものでも、写真のあるページの下の部分に、なにやら番号が書かれている。﹁機械読取り式﹂と呼ばれるもののようだ。外務省のサイトに説明がある︵図の﹁機械読取り式旅券﹂と矢印で示されている部分︶。この部分は光学式スキャナのようなもので読み取るようだ。コピー機のような装置の上にパスポートを開いて乗せると、この番号が読み取られるというデモがIC CARD WORLDで展示されていた。そして、BAC付きのe-Passportでは、ここで読み取った番号からあるアルゴリズムで生成した暗号鍵を使って、通信するのだという。なるほど。ちなみに、最近小耳に挟んだところによると、この方式は、日本から提案して、一部を除く各国で採用された方式なのだそうだ。さて、海外ニュースで流れてくる米国のパスポートの話は他人事として、米国に入国するときの日本のパスポートはどうなるのだろうか？米国がBACなしを強行した場合に、他の国もBACなしのパスポートを強制される︵あるいは機能はあっても無効にすることを強制される︶といったことは起こり得ないのだろうか。ところで、このあたりの話は日本では全く報道されていないように記憶しているが、どうか。ちょっと検索してみたところ、外務省が以下のQ &Aを公開していた。 ●パスポートQ & A, 機械読み取り式旅券・IC旅券とアメリカ入国ビザの関係, 外務省 Q5．日本はいつ﹁IC旅券﹂を発給するのですか。アメリカの定めた期限に間に合いますか。 A外務省では2006年3月までの﹁IC旅券﹂導入を目指して取り組んでおり、所要の法改正手続きも進めていますが、アメリカの定めた期限には間に合いません。したがって、現状では2005年10月26日から日本が﹁IC旅券﹂を発行する日までに発行される旅券は、現行の﹁機械読み取り式﹂であってもアメリカに入国する場合はビザが必要となります。︵後述の参考3.を御覧ください。︶︵略︶参考 3. 2005年10月26日のIC旅券導入期限が再延期される可能性は？ほとんどの国にとってこの新たな期限までに﹁IC旅券﹂を発行するのは難しい状況であり、アメリカ議会が再度の導入期限延長を行わない限り、多くの国では2005年10月26日以降に発行された﹁非IC旅券﹂を所持してアメリカに渡航する者はビザを取得しなければならないことになります。外務省はそのような事態を避けるために今後も最大限の努力をしてまいります。もし米国がおかしなことを強制してきて日本の外務省も困るような状況が生じ得るとすれば、日本国民の総意として︵たとえば暗号化なしの電子パスポートを拒否するといった︶世論形成をしておく必要があるだろう。しかし日本のマスコミは、後戻りできなくなったころに糾弾する能力しかない。少なくとも役所にはそう思われているので、役所は密かに自力で問題解決を図るのだろう。日本の優秀な官僚さんたちに安心してまかせようというわけだ。ただ、それが万が一失敗したときは痛いことになる。聞くところによると、米国が暗号なしのパスポートを採用し、今も強行しようとしている理由について、﹁どうせ見せるための情報なんだから﹂ということを言っているらしい。その感覚がプライバシー的に受け入れられるものかどうかは、それぞれの国の国民性によって左右されるものであるのだから、役所がなんとかするだけでなく、日本国民がそのような方式をどう考えるのか、世論を形成しておくことは必要だろう。まあ、マスゴミはプレスリリースでも流してろって。 ●電子旅券導入、欧州5ヵ国合意, 日本経済新聞, 2004年10月19日朝刊 ●シャープ、電子旅券用ＩＣ、豪政府に納入, 日本経済新聞, 2004年10月26朝刊 ●シャープ‥豪政府にＩＣチップ1万個を納入, 毎日新聞, 2004年10月26日大阪朝刊 ●豪のＩＣパスポート、シャープの技術採用国籍・顔写真、読み取り, 朝日新聞, 2004年10月26日朝刊 ●電子パスポートにシャープの部品豪政府が実証実験で使用, 大阪読売新聞, 2004年11月4日朝刊 ●電子パスポート、実証実験実施へ――来月上旬から外務省など、ＩＣチップで本人確認, 日本経済新聞, 2005年1月15日朝刊 ●ＩＣパスポート‥来月上旬から実験−−外務省, 毎日新聞, 2005年1月15日朝刊 ●ＩＣパスポート実現へ瞳などで旅客認証、成田空港で実証実験−−来月から／千葉, 毎日新聞, 2005年1月16日地方版 ●﹁ＩＣパスポート﹂導入へ実験外務省で町村外相, 朝日新聞, 2005年2月4日朝刊 ●05年度にＩＣ旅券政府、ＩＴ化の年限明記−−ｅ―Ｊａｐａｎ戦略２, 毎日新聞, 2004年2月6日朝刊 ●電子パスポートに日章旗を記せ, 産経新聞, 2005年2月16日東京朝刊 ●論説委員に聞こう: ＩＣを付けて偽造防止−−森嶋幹夫・論説委員, 毎日新聞, 2005年2月23日朝刊

本日のリンク元 TrackBacks(9)

2005年03月06日

■ 自治体は誠実なのか不誠実なのか

先月、﹁半数の企業がハッキングされても報告しない﹂という海外ニュースが流れる中、佐賀県が、サーバが侵入されてフィッシング詐欺用の偽サーバを稼動させられていた事実を、記者発表した。 ●︵財︶佐賀県地域産業支援センターのインターネットによるサービスの一部のご利用を停止しています, 佐賀県農林水産商工本部商工課, 記者発表資料, 2005年2月16日別添のとおり、平成17年2月15日に、財団法人佐賀県地域産業支援センターがインターネット上で公開しているＷｅｂサーバにおいて、個人インターネットバンキングのユーザＩＤ及びパスワードの入力を促す英文の偽装サイトが開設されるというフィッシング被害を受けました。これには感心した。事故が起きたら包み隠さず公表する。さすが自治体は誠実なんだなと。これとは対照的な話がある。1月11日の日記﹁高知県情報企画課曰く﹁とくにおかしいと思わない﹂﹂には、続きがあるのだ。高知県情報企画課への電話は、このオレオレ証明書問題の問い合わせの後、もうひとつ別の問題についてインタビューしていた。

私: それからもう一点あるんですけどね、﹁はい﹂を押すと別の警告が出ますよ。﹁はい﹂を押してアクセスを進めるとですね、Windows XP SP2ですと、﹁発行元を確認できないためこのソフトウェアはブロックされました﹂﹁不明な発行者﹂というのが出るんですけども、

図1: 高知県電子申請システムをデフォルトのセキュリティ設定でアクセスした様子（SP2の場合）

県︵情報企画課︶: あー、はい。私: これは明らかに異常なんですけども、どうですか？県: ……。私: あるいは、Windows XP の SP2を入れてない、前のバージョンでやると、﹁現在のセキュリティ設定ではこのページのActiveXコントロールは実行できません﹂というのが出るんですよ。これはどうですか？

図2: 高知県電子申請システムをデフォルトのセキュリティ設定でアクセスした様子（SP1の場合）

︵埒が明かない様子を略︶私: さっきの方にかわってくださいよ。県: 少々お待ちください。県︵業者︶: もしもしお電話変わりました。私: あーもしもし？第2の問題もあるのですが、そこで﹁はい﹂を押して次の画面に進むとですね、別のエラーが出るわけですよ。﹁現在のセキュリティ設定ではこのページのActiveXコントロールは実行できません﹂というのが出るんですよ。県: はい。私: これは駄目じゃないですか？県: えーっと、今使われているOSは何になるんでしょうか…… 私: 今のはWindows XPのSP1ですね。県: そのような表示が出てしまうと。私: 出ないですか？そっちでは。県: こちらで確認して回答するという形でよろしいですか？私: 出るでしょ？警告は。出るから説明が書いてあるでしょ。﹁ヘルプを見て設定してください﹂と、あなた、書いてるじゃないですか。県: ええ。私: それのことを言っているわけですよ。県: えーと、そのActiveXというものは、ホームページからダウンロードはされているんでしょうか？私: いやですから、普通のデフォルトのセキュリティ設定ではダウンロードができないようになっているわけですよ。危ないから。県: はい。で、えーと、ホームページ上では設定を変えてダウンロードしてくださいと書いてあると。私: そうですね。これはまずいんじゃないですか？県: セキュリティレベルを戻してダウンロードするのは危険じゃないのかなと私: 戻すじゃなくて、下げてるでしょ？デフォルト設定から。県: はい。私: 駄目じゃないですか？これは。県: えー、その点についてはですね、こちらで独自に開発したプログラム私: うん、そんなことはわかってますよ。よそのサイトに行っても、署名がないやつをすぐインストールしちゃうわけですね、この設定にしておくと。県: えー、署名といいますかActiveX 私: あなたねー、2000年ごろから社会問題になった、しらないうちに国際電話に電話がかかるようになってて何十万円っていう請求がくるってやつ知ってますか？県: あーその、個人情報が流れたりっていう私: ちが、怪しいサイトをアクセスしているとですね、知らないうちにプログラムを埋め込まれて、ダイヤルアップの接続先を変えられて、国際電話経由でインターネット接続するように変えられて、外国の電話会社経由で30万円くらい請求されるというのご存知ですね？最近は常時接続が一般的になりましたから、あまりそういうことは聞かなくなりましたが、2000年ごろはそういう被害が多発していましたね？県: はい。私: その原因はですね、知らないうちにプログラムを埋め込まれたからなんですけども、それはActiveXコントロールで作られていたわけですよ。で、Internet Explorerの初期設定では当然ながら、署名のないActiveX コントロールは動かないようになっているわけですよ。悪い奴がそういうことをしようとしますからね。県: はい。私: アクセスしただけでプログラムが埋め込まれるというのは、おかしいでしょ？県: はい。え？あのー、ダウンロードはされて、動かそうとするとそのような私: アクセスしただけでダウンロードして組み込まれるような設定にしろと言っているのはあなた方なんですよ。県: でーですね、あのー、私: つまりあなた方の指示に従っている市民は、30万円ぐらいの被害が出るような危ない設定をさせられているわけですよ。県: えーとそのー、ActiveXをダウンロードするっていう件なんですけども、そのActiveXのプログラムがどういうものかに、よるとは思うんですけども私: あなた方のはいいんでしょう。だから、その設定のままよそに行ったらどうなるか？って言っているわけですよ。県: あ、そのーActiveXっていうのは、一言でActiveXって言われていると思うんですけども、ActiveXは個々にプログラムは動作は別々で、独自で動いてると。で、そのー、被害を被るActiveX？っていうものはそのー、第三者が悪くプログラムを作ってActiveXを作成していると。でー、今現在高知県の方からダウンロードするActiveXは、そのようなプログラムなしで単に申請を行うためのプログラムで作ってあるActiveX であるので、そのActiveXを用いてどうのこうのっていうのは、できないようになってます。私: そんなことはわかっているんですよ。誰もそんなことは聞いてないの。県: はい。私: アクセスしただけでダウンロードしてインストールするような設定をするようにあなた方は説明しているわけでしょ？ヘルプで。県: はい。私: それでいいんですか？って言ってるんですよ。よそにこのままアクセスに行ったらどうなるんですか？県: えーとよそっていうのは、えーと、そのActiveXを用いてよそに接続に行ったらどうなるかと？私: ちがう、ちがう、ちがう。ヘルプに、セキュリティ設定で、未署名の ActiveXコントロールを有効にしなさいと説明してるでしょ？県: はい。私: そんなのは危険だって言ってるわけよ。県: はい。でー、私: はい？わからないんでしょ？まだ。県: でその、私: あなた方は未署名のActiveXコントロールを配布していて、 Internet Explorerのデフォルト設定では当然危険だから動かさないような設定になっているが、あなた方は自分達だけは正しいと思っているから、未署名のActiveXコントロールのダウンロードを、有効にしなさいと、何もしなくても自動的にインストールして動くようにしてくれと、県民に対して指示しているわけですよ。その状態で県民が、どっかのサイトに行ったらばですね、この設定だったら、どんなことでもできちゃいますよ？ウイルスを埋め込む、個人情報を盗み取る、あるいは国際電話にダイヤルアップする設定に変える、何でもできちゃいますよ。そういう危険な設定を、あなた方は県民に対してさせているわけですよ。

図3: 高知県が未署名のActiveXコントロールを有効などに設定せよと指示していた様子

県: そのまあ、ヘルプの件ですけども、えー、……たしかに……、セキュリティレベルを……落とすようにと。ような記述になっていますね。私: 告訴されたら負けると思いますよ。これのせいで30万円請求されたと。あるいはウイルスの被害に遭ったと、個人情報盗られたと、損害が何百万円か出たと。その原因はこの設定をしていたせいだったと。したがって、高知県に対して損害賠償を請求するとやられたらですね、どうですか？県: そうですね、私: たいていの人は原因もわからないまま泣き寝入りでしょうけどね。県: そうですね、ここのヘルプの部分を、まあ、修正してですね、私: 修正っていうか削除ですよ、こんなバカな設定は。削除だけじゃなくて、この設定をしている人は元に戻してくださいって説明してまわならいと責任問われますよ。県: そうですね、高木さんのおっしゃるとおりだと思うんで。私: ヘルプの説明が間違ってましたと、セキュリティ設定は﹁中﹂以上に戻してくださいと。いうふうに、間違って設定している全員に対して説明する義務があなた方にありますよ。横の人、聞いてますか？県: じゃあちょっとかわりますので。県︵情報企画課︶: もそもし電話かわりました。 ActiveXをダウンロードして、設定を元に戻す必要があるという私: そうじゃないですよ、こんな設定しなくてもダウンロードできるように作ればいいんですよ。なぜしないんですか。みんなはそうやってやっているんですよ。なんであなた方だけこんな変な作り方して、動かないもんだから、設定を変えろといって、県民を危険な目にさらしているわけですよ。ウイルスに即座に感染する。まあようするに、セキュリティホールを作らせているようなもんですね、手作業で。県民自身に自分のコンピュータに穴を開けさせてるわけですよ、あなた方が書いていることというのは *1。県: はい。︵繰り返しにつき略︶私: わかりましたか？県: 内容だいたい、ご意見はわかりました。私: ヘルプを改善すればいいってもんじゃないですよ。既に、ヘルプに書いてあった通りのことをやっちゃった人がいるわけですから、そういう人達全員に歩いてまわってですね、設定を戻してくださいと、﹁中﹂以上にしてくださいと、セキュリティ設定を下げろなんてのは大間違いだったと、理由も必要ですね、もしおかしなプログラムが動いちゃったとか、ウイルスに感染したとか、損害が出ているのだったら我々の責任かもしれないと、本当は言うべきですね。もちろんあなた方は言わないでしょうけどね？県: ……………………。そうですね、はい。私: 署名すればいいんですよ、ActiveXコントロールに署名していればこんなことにならないんですよ。よそのはみんなそうなってるじゃないですか。 Windowsを使っていると、このActiveXコントロールはMicrosoft社が作ったと言ってますと、これを信頼してインストールしますか﹁はい﹂﹁いいえ﹂っていうのが出るじゃないですか。そこにMicrosoftが作ったとか出るのはそこに電子署名しているからなんですね。プロウグラムに。なぜしないの？︵以下略︶

そしてこの電話から1か月が経過した2月16日、再び高知県のサイトを訪れてみると、ヘルプだけが少しだけ修正されていた。

図4: 修正された高知県の「ヘルプ」

対応はこれだけなのか？というわけで、その日に電話して問い合わせた。すると、県の担当者は、これが対応だという。これはあんまりだと思ったので、課長に電話をつないでくれないかと言ってみた。すると、折り返し電話するからしばらく待てという。待つこと一時間以上、折り返しの電話は来た。電話は課長ではない。この1時間に何をしていたのかと尋ねると、部内で対応を再度検討していたという。もうちょっと対応を改善するという結論になったという。課長にかわってくれるんじゃなかったのかと尋ねると、課長が電話に出てくださった。私はそこで、﹁なぜ市民に注意喚起を出さないのか﹂と主張した。プレスリリースくらい出して告知を徹底したらどうかと提案した。そのつもりはないという。どうしてないのかと尋ねると、﹁そこまでするほどのこととではないと判断している﹂というような回答だった。﹁判断している﹂というからには分析した根拠があるはずだからそれを聞かせて欲しいと尋ねたところ、応えに窮していた様子だったので、﹁ようするに、なんとなくそう思ったというレベルだということですか？﹂と尋ねた。そう言われたらそうだと認めざるを得ないというような回答だった。課長にも問題は正しく理解されているようだったが、告知する気はないという。私はたとえ話をした。﹁コンビニの牛乳に異物混入が見つかったら何をしますか？﹂と。﹁コンビニの入り口に張り紙してそれで終りですか？﹂と。被害の拡大を防ぐためには周知が必要。周知にはコストがかかるが、プレスリリースを出すなりすればマスメディアの力を借りて低コストで告知を徹底できるでしょう、と。なぜそれをしないのかと。かなり厳しいことを言ったと思うが、具体的な表現は忘れてしまった。最終的に課長は事態を認識し、対応は改善すると約束してくださった。そして、それからさらに1か月近くが経った。そして、何も変わっていない。トータルで2か月も経過しようとしているのにだ。こんな簡単なことで、だ。冒頭の佐賀県の事例のように、自治体はこうした事故に対して誠実に対応してくれるものだと思っていた。民間企業がソフトウェアに脆弱性を指摘されたとき、事実を隠したがることがあるのは、それによって販売が落ち込むかもしれないと短期的な勘定に走ることがあるからだろう︵長期的には信頼を得るために事実を的確に公表することが効果的だとも言えるのに対して︶。それに比べて、自治体の場合はどうか。短期的な損失は気にする必要はなかろう。それによって、県を去る、国を去るということはないのだから。佐賀県の事例は、必ず市民に周知しないといけないものかというとそうでもない︵もちろん公表した方がよいが︶。それに対して高知県の事例は、利用者︵過去に利用していて今は利用していない者を含む︶に対して確実に周知しないといけないものだ。必須でない佐賀県の事例が記者発表されて、周知が必須の高知県の事例では発表がないというのは、どういうことなのか？高知県が特殊なのだろうか。佐賀県が特別なのだろうか*2。

追記

Internet Explorerのセキュリティ設定には、ActiveXコントロール関係のものが複数ある。このうち重要なのは以下の3つ。 ●スクリプトを実行しても安全だとマークされていない ActiveXコントロールの初期化とスクリプトの実行 ●署名済み ActiveXコントロールのダウンロード ●未署名の ActiveXコントロールのダウンロードこれら3つの設定を絶対に変更させるな。どんなシステムを実現する場合であろうとも、その必要はない。業者がここの設定変更が必要だと言って来たら、その業者は無能なので、縁を切れ。

図5: Internet Explorerのセキュリティ設定の初期値

（それぞれを無効に変更するのはユーザの自由。）

*1 類似事例: [memo:4491], [memo:4632], 2002年7月 *2 だが、佐賀県の記者発表文をよく読みなおしてみると、私の買いかぶりだったことに気づいた。﹁フィッシング被害を受けました﹂と書かれているが、フィッシングの被害者は、カード番号を入力してしまった一般の人たちであって、佐賀県ではない。佐賀県はむしろ加害者に加担してしまった立場であるはずだ。発表文はそのことについてとくに触れていない。ようするにこれは、﹁自分達は被害に遭った﹂という発表なのだ。役所にだけは勤めたくない。

本日のリンク元 TrackBacks(6)

2005年03月11日

■ 非接触ICカードがなりすまし不能とまでは言わないので注意

2月6日の日記で﹁ICカードの非接触スキミングですって？ええかげんなことぬかすな﹂というのを書いたが、ICカードならばなりすましできないとまでは言わないように、表現に気をつけたつもりだった。﹁磁気ストライプと違って、読み出せるからといって、なりすませることにはならない。この番組で言われているような方法での複製はできない。しかし改めて読み返してみると、たとえばEdyでは、EdyカードからEdyナンバーを誰でも読み取れるが、Edyのリーダ・ライタに対して、なりすましてそれを与えることはできない。暗号を破らない限り。そのように作られているはずだ。というのはちょっと勇み足だった。3月5日の日記﹁Edyナンバーをいろいろ流用するのが花盛り﹂でも、磁気ストライプカードやRFIDタグと違って、ICカードは暗号演算機能を持つので、たとえEdyナンバーが誰でも読み出せるものであっても、リーダとの通信プロトコルにおいて、そのEdyナンバーとしてリーダに認識させるように振舞うことは困難になっているのであるから、このような応用は技術的には正しいといえる。と書いたがこれも、安全さを強調しすぎる表現にしてしまっていた。ICカードに対するICタグの安全性の低さを説明するために、比較の問題としてICカードの特性を示したため、安全さを強調しすぎてしまった。接触型のICカードにおいても、かねてより、利用者が誤って偽装置に挿入してしまうことの問題点が指摘されてきていたし、非接触型においてはその危険性が増大するという懸念は、表でも指摘が出ていた。そうした攻撃への対策はなされているとの噂も耳にしているが、本当にできているのかどうかは知らない。現実の攻撃の可能性を減らすことはできても、完全にリスクをなくすのは無理な気もしないでもない。 2月6日の日記で言いたかったことは、危険性を訴えるならば検証してからにしてもらいたいということだった。なので、今、ICカードも実は危ないんではないかというようなことを証拠もなく言いたくはないのであるが、今まさに銀行のキャッシュカードをどうするかということが焦点となり、さらには、その安全性の前提が、預金者保護の制度作りがされるのかされないのかに影響を及ぼすかもしれないという今の状況がある中では、﹁ICカードは安全です﹂ということになってしまってはいけないと思う。リンク元をだどってあちこちのblogや掲示板などを見てまわったところ、 Suicaのお金を非接触読取りで盗まれるのではないかといったよくある不安に対して、それはあり得ないことだと説明をしている人が何人かいるのを見たので、ちょっと責任を感じてしまった。本当にそうかどうかはわからないので、もし仮に、知らないうちに残金が減っているという現象が起きているなら、あり得ないことと断定するのではなしに、疑うこともした方がよいかもしれない。プリペイドカードくらいならば、そこまでする盗賊は現れないだろうという前提による安全性なのかもしれないが、これが銀行のキャッシュカードとなると話は別で、盗賊たちはどこまでもやるのかもしれない。少なくとも銀行のキャッシュカードについては、非接触型にするのは本当にやめたほうがいい。その必要もないのだから。ATMを﹁タッチアンドゴー﹂で使いたいわけではあるまい。やっぱり本当に、﹁財布には電磁シールドが必須﹂という未来が現実となる日がやってくるのかもしれない。

■ 無題

3月5日の日記で﹁Suica番号がメールアドレスと結び付けられ始めた﹂というのを書いたのだったが…… ●ＩＣカードと電子ポスターを利用したマーケティング技術を開発, −産総研発ベンチャーを設立し実用化−, 独立行政法人産業技術総合研究所プレスリリース, 2005年3月10日ウアアアァァァァ・・‥‥……。正直、知らんかった。 yoshinovさんか……。そういえばリンク元にも……。とりあえず週明けにコンタクトしてみるとするか。︵他にもアレなナニがあるし。︶

■ 無題2

第8回コンピュータ犯罪に関する白浜シンポジウムの講演録が公開されていた。 ●プライバシー問題の解決が難しいのはなぜか＜事務局より＞今回、高木先生がご多忙なため最終原稿を見ていただいておりません。手違いがございましたら、事務局まで。グアァ……。すみませんすみませんすみません。意味の通らない文が何箇所かあるので、連絡入れます。これだけの分量の大半を正確に文字おこししていただいており、感謝します。ビデオも公開したいのですが、どうやって公開したものかと思案中です。

■ 無題3

国土交通省東北地方整備局郡山国道事務所というサイトがあったので、リンクしてみる。

こ・ち・ら ♥

本日のリンク元 TrackBack(1)

2005年03月15日

■ 銀行業界が自治体に苦情を申し立てても不思議でない

UFJ銀行を装った日本語phishingが発生した。 ●UFJ銀行をかたる日本語フィッシング詐欺メールが出回る, ITmedia, 2005年3月15日 ●偽のＵＦＪ銀行メール送られる・フィッシング詐欺か, 日本経済新聞, 2005年3月15日 ●ＵＦＪ銀装い大量に不審メール　フィッシング詐欺狙いか, 朝日新聞, 2005年3月15日報道によれば、14日の21時半からUFJ銀行のコールセンターに通報が多数寄せられたとのことで、UFJ銀行は15日の11時ごろに注意喚起の発表をしたようだ。 ●ＵＦＪ銀行を偽装した電子メール詐欺が発生していますのでご注意ください, UFJ銀行, 2005年3月15日公式見解がプレス向けに発表されることで、一般紙が報道として扱えるようになる。そして事実が幅広く市民に周知され、そして被害の拡大が抑えられる。このように、迅速な公式発表は顧客保護のために重要である*1。さて、そのUFJの注意喚起文を見てみる。 ■UFJ銀行のホームページを安全にご利用いただくため以下の点をご確認ください ◎UFJ銀行のホームページで暗証番号、パスワード等の重要情報の入力を受付ける場合には、SSLによる暗号化通信を行っております。SSLによる暗号化通信が行われるページのアドレスは﹁https://﹂から始まっており、画面の右下︵Webブラウザのステータスバー︶に鍵のマークが表示されます。鍵マークをダブルクリックしてサーバ証明書を表示し、ＵＦＪ銀行のドメインおよび英文組織名が書かれていることをご確認ください。︻ＵＦＪ銀行のＳＳＬ︵暗号化通信︶証明書︼・ＵＦＪ銀行のドメイン名は﹁ufjbank.co.jp﹂です。証明書の﹁発行先﹂は﹁www.ufjbank.co.jp﹂﹁direct.ufjbank.co.jp﹂のように、﹁ufjbank.co.jp﹂で終わっています。・ＵＦＪ銀行の英文組織名は﹁ＵＦＪ Bank Limited﹂です。︵略︶ＵＦＪ銀行を偽装した電子メール詐欺が発生していますのでご注意ください, UFJ銀行ここまでは適切な説明だ。続いて﹁証明書の確認方法はこちら﹂として、﹁SSL︵暗号化通信︶証明書の確認方法﹂というページが紹介されている。ここを見ていくと、上の方には、アドレスバーとサーバ証明書の﹁発行先﹂ドメイン名を確認する方法が書かれており、真ん中あたりには、証明書の﹁詳細設定﹂の﹁サブジェクト﹂欄で英文組織名を確認する方法が説明されている。問題はその下だ。﹁2.証明書の発行元の確認﹂として、このサーバ証明書が VeriSignによって発行されていることを確認する方法が説明されている。 2. 証明書の発行元の確認当行は日本ベリサイン(株)発行のSSLサーバ証明書を使用しています。証明書の発行元が正しいことの確認方法は以下の通りです。 (1) ﹁証明のパス﹂タブをクリックして表示された画面で、﹁VeriSign/RSA Secure Server CA﹂を選択し、﹁証明書の表示(V)﹂をクリックする。 (2) ﹁詳細設定﹂タブをクリックして表示される﹁拇印﹂の値と、証明書発行元の日本ベリサイン(株)のルート証明書表示ページ︵https://www.verisign.co.jp/repository/root.html︶に記載の数値が一致することを確認する。 SSL︵暗号化通信︶証明書の確認方法, UFJ銀行これはどうだろうか。証明書発行元認証局のルート証明書のフィンガープリントまで確認せよと言っている事例は珍しい。本来ならばそこまで確認する必要はない。ルート証明書のフィンガープリントが一致しない状況があるとしたら、ユーザが、偽のVeriSignルート証明書をインストールしてしまっている場合であり、それは、ユーザが手作業で入れてしまった場合と、スパイウェアやトロイの木馬などを誤って実行した︵もしくは脆弱性を突かれて強制的に実行させられた︶場合がある。たしかに、昨今では﹁ファーミング詐欺﹂という、フィッシングとは別の呼称まで付けられた攻撃手法が流行りつつあると言われている。hostsファイルを書き換えられたうえ、偽VeriSign証明書を入れられてしまっている場合、ブックマークなどから https://www.ufjbank.co.jp/ のURLにアクセスしても、偽サイトにつながったうえ、偽サイトにSSLで接続しているときにはブラウザが出してくれるはずの警告ダイアログも出なくなってしまう。だから、UFJ銀行としては、フィンガープリントを確認せよと言っているのかもしれない。しかし、そのような状況においては、UFJ銀行が説明している方法は、本物であることの確認にはならない。なぜなら、偽のVeriSignルート証明書を入れられてしまっている状況では、﹁日本ベリサイン(株)のルート証明書表示ページに記載の数値﹂も偽ページであることを否定できないからだ。攻撃者は、 www.verisign.co.jp のホスト名を偽のIPアドレスで hosts に登録し、偽の www.verisign.co.jpサーバ証明書を偽VeriSignルート証明書で発行して偽サイトを動かす可能性があるのだから。したがって、UFJ銀行のこの説明は不適切である。誤った確認方法を正しい確認方法であるかのごとく人々を誤解させる点で、有害である。この確認に意義があるかというと、攻撃者が偽VeriSignルート証明書を人々に入れさせていながら、﹁日本ベリサイン(株)のルート証明書表示ページ﹂の偽装まではやっていない場合には意義があると言えるが、それは小さな益であり、それに比較して人々を混乱させる害の方が大きい。よって、この解説は削除するべきである。なぜ、銀行がこのようにフィンガープリントを確認せよなどという普通でない説明をしてしまうのだろうか。ひとつには、日本ではあちこちの自治体が、 LGPKI Application CAのフィンガープリントを確認しなさいと、そこらじゅうで説明しまくっているためではなかろうか。UFJ銀行の担当者はその種のものを目にした経験があって、見よう見まねで、事の本質を考えることもなく、書いてしまっているのではないか。偽のルート証明書が入ってしまっていないかを確実に確認する術は、いまのところない。オンラインではどうやっても完全にはできないだろう。CD-ROMで販売されるソフトウェアにそうした機能を搭載するか、オンラインで配布するチェックツールに電子署名を付けて、そのフィンガープリントを紙媒体の雑誌や新聞の記事に掲載して、それを使用者が自らの理解に基づいて確認するしかない*2。したがって、ルート証明書の真正性確認の説明は、一介の企業であるUFJ銀行がやることではない。むしろ、こういうときに銀行がやるべきことは、オレオレ証明書の警告が出たら必ず﹁いいえ﹂を押しなさいという説明をすることだろう。たとえばこんなふうに書けばよい。 ■○○銀行を安全にご利用いただくため以下の点にご注意ください 1. ︵略︶ 2. ブラウザの警告に注意する当行は△△発行のSSLサーバ証明書を使用しています。Internet Explorer 6、 Mozilla/Forefox、Opera 6 などのブラウザでは正常にお使いいただけることを確認しております。ブラウザが以下の図の警告を出したときは、異常な事態であることを示しており、お客様のコンピュータが偽のサイトに接続している可能性が否定できません。﹁いいえ﹂を押してアクセスを中止してください。

そもそも、この警告が出たら﹁いいえ﹂を押すのが当然の常識として人々にもともと理解されているはずのところが、昨今では、その常識が崩れつつある。その原因は、自治体の電子申請システムだ。自治体の愚かな行いが、銀行に対するphishing攻撃の危険性を増大させている。そもそもWebのサーバ証明書は、Webというグローバルなアプリケーションドメインに対して設定されたそれ固有のPKIモデルで稼動しているものであり、銀行をはじめとする事業者たちはこれまで、そのモデルのルールに則って証明書を購入し運用してきた。そこへ、後からやってきた役所の連中が、そのモデルのルールを無視し、勝手認証局を立て、﹁私達も仲間ですよ﹂と利用者達をたぶらかしている。︵ブラウザベンダーに対して﹁仲間に入れて﹂とお願いするのではなしに。︶銀行業界は、このような自治体の迷惑行為に対して、やめてもらえないかと、要請してはどうか。ちなみに、話を戻すと、当行では、電子メールではこうしたご連絡はいたしておりませんのでご注意ください。ＵＦＪ銀行を偽装した電子メール詐欺が発生していますのでご注意ください, UFJ銀行とあるが、UFJ銀行は3年前にこんなメールを顧客に流したという実績がある。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
　　　　　　　　　　　　　ＵＦＪ銀行誕生ごあいさつ
　　　　　　　　三和銀行と東海銀行は、ＵＦＪ銀行になりました
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

三和銀行と東海銀行は、2002年1月15日に合併し、ＵＦＪ銀行として新たに
スタートいたしました。

――――――――――――――――――――――――――――――――――――――
　　　　　　　　インターネットバンキングのご利用について
――――――――――――――――――――――――――――――――――――――

●現在、ＵＦＪ銀行のホームページは、アクセス集中により、大変つながりにくく
　なっております。お客さまには大変ご迷惑をおかけし、誠に申し訳ございません。
　しばらく経ってからご利用いただきますようお願い申し上げます。

　尚、インターネットバンキングのご利用は、当面、下記のＵＲＬよりログイン
　していただきますようお願いいたします。

　　http://www.csweb.co.jp/TBK/ufj/login.htm

このメールに対する返信は受付できませんので、ご不明な点等がございましたら、
下記までお問い合わせください。

――＜お問い合わせ先＞――――――――――――――――――――――――――― 
（略）

 ◇このメールは、旧三和インターネットバンキング2000ご契約者および
　旧＜東海＞ダイレクトの方に配信しております。
――――――――――――――――――――――――――――――――――――――

さすがに、フィッシング詐欺がこれだけ認知された今では、こうしたメールが流されることはないだろうと思われるが、実際につながりにくい事態が今後起きた際には、どうするのだろうか？やはり、公式メールには電子署名があるのが当然という世論形成を今から準備していくしかないだろう。

■ Phishing報道は何を伝えるべきか

今回のphishing事案で、ネットのメディアは画像付きで報道しているが、そのいくつかは、どういうわけか、わざわざアドレスバーを隠した画面を掲載している。なぜこういうことをするのか理解しかねる。

UFJ銀行とみずほ銀行をかたるフィッシングメールが発生, CNET Japan, 2005年3月15日
金融機関を騙ったフィッシングメールが続発、UFJ銀行やみずほ銀行を偽装, INTERNET Watch, 2005年3月15日
記事中の図

「実際のUFJ銀行のサイトと見た目は同じ」というのは当たり前であり、単に恐怖を煽るのが報道の目的でないのなら、どうやって見分けるかを伝えることこそが画面掲載の意義だろう。

その点、ITmediaの報道では、アドレスバーについて画像付きで説明しており、的確だ。

*1 自社が配布していたソフトウェアに脆弱性が見つかったときにも、このようにして広く周知されるべきだろうが、脆弱性パッチのリリースをプレス発表するという事例はほとんど存在しない。かつて、ソニーがVAIOのセキュリティホールを発表したことがあった程度。

*2 それでもなお、そのチェックツールの動作を狂わせる仕掛けが、トロイによって組み込まれていたら駄目だし、署名確認の操作が偽の処理に差し替えられる仕掛けが組み込まれていたら駄目だ。トロイを実行してしまったら、原理的にはもはやどうしようもない。TCGなどの成果を待つしかないか。

本日のリンク元 TrackBacks(100)

2005年03月16日

■ Phishingの偽サイトに https:// でアクセスしてみると

一昨日から発生しているUFJ銀行を騙った日本語phishing事件で、偽サイトのひとつはまだ稼動しているが、その偽サイトで、http:// を https:// に変更してアクセスしてみたときの様子を図1に示す。

図1: UFJ銀行を騙る偽サイトに https:// でアクセスしたときの様子

昨日の日記に書いたように、銀行側は、 phishing詐欺に騙されないために、鍵マークとサーバ証明書の内容を確認せよと言っているわけだが、この図を、かつての広島市のオレオレ証明書サイトのときと比べて眺めてみる。さてどうだろうか。

本日のリンク元 TrackBack(0)

2005年03月24日

■ 不正アクセス禁止法私はこう考える

私は法律について体系的に学んだことがなく、法解釈について本来必要であろう基礎的な素養がないが、自分の本業に関わりの強い特定の法律については、おのずと日ごろから分析させられることになる。とくにその法律の解釈に技術的理解が欠かせない場合においては。

﹁利用﹂とは何か

昨年7月15日の日記﹁不正アクセス禁止法法学者の解釈﹂では、法学者が支持するひとつの主張として、﹁電子計算機の利用﹂とは有体物としての電子計算機の利用を指し、個々の情報処理を指すと解釈することはできないという解釈がある︵﹁サイバー犯罪条約の研究﹂, 日本弁護士連合会組織犯罪関連立法対策ワーキンググループ編, 2003年9月の第2章﹁サイバー犯罪条約の刑事学的意義﹂︵石井徹哉︶, 第3﹁情報セキュリティの刑事的保護﹂参照*1︶ということを書いた。この解釈に沿うと、不正アクセス禁止法は今日では全く役に立たない法律ということになり、作り直しが必要だということになる。それに対し、7月18日の日記﹁不正アクセス禁止法立法者の意図︵推定︶﹂では、同法の立案に参画した警察庁スタッフによって書かれた逐条解説書の記述から、﹁利用﹂とは次のように解釈するのが立法者の意図に近いだろうと書いた。﹁電子計算機の利用﹂といえばそこでサービスを受けられるいろいろな利用それぞれのことを指すという立場の文理解釈では、無数の利用というものがあって、そのうちのどれとどれが﹁制限されている利用﹂にあたるのかということになる。立法者の意図を逐条解説書から探れば、以下の引用部のように、利用というものに﹁範囲﹂なるものが想定されていることから、利用という概念が、範囲の限定を伴いうるものとして意図されていることがわかる。不正アクセス禁止法立法者の意図︵推定︶この考え方を突き詰めて整理を試みたのが昨年10月4日の﹁不正アクセス禁止法数理的理解の試み﹂と11月21日の﹁不正アクセス禁止法続・数理的理解の試み﹂であり、法文中の﹁制限された利用﹂という概念を、要素的な個々の﹁利用﹂の数学的な集合として捉えるという考え方を示した。これらの一連の日記では﹁特定利用﹂を﹁利用﹂と省略して書いていた。不正アクセス禁止法では、すべて﹁特定利用﹂という表記で統一されており、﹁利用﹂という言葉は︵﹁特定利用﹂の定義部を除いて︶一度も使われていないので、便宜的に置き換え可能だからだ。﹁特定利用﹂とは、﹁電気通信回線に接続している電子計算機の、当該電気通信回線を通じて行う利用﹂のことを指す。つまり﹁特定利用﹂とは、欧米諸外国の不正アクセス関連法規における﹁無権限アクセス﹂や、サイバー犯罪条約における﹁権限なしに故意に行われるアクセス﹂に見られる﹁アクセス﹂という言葉を、日本語で表記しなおしたものにすぎないのではないかと考える。石井説の要旨は、注意すべきことは、情報技術上の概念としての情報セキュリティは、不正アクセス禁止法にいう﹁電気通信に関する秩序の維持﹂や﹁高度情報通信社会の健全な発展﹂とも異なるし、俗にいうネットワークの安全性でもない。このような言葉で表現されているものは、せいぜい一般市民の安心感であって、これ自体は法的保護の対象とはいえない。コンピュータシステムがデータを処理することによって規定されていることから示されるように、データ・セキュリティが重要である。具体的には、データの同一性の確保、権限ある者のみによるデータへのアクセス、適切なアドレスへのデータの伝送の確保がデータ・セキュリティの内容といえる。したがって、データ・セキュリティの観点からは、コンピュータシステムがネットワーク構成されているか、スタンド・アローンかということは問題ではない。コンピュータシステム内のデータが不正に処理されるということは、無権限のデータ・アクセスがその内実をなしているのである。この点において、現行の不止アクセス禁止法は、情報セキュリティの観点から全面的に改正されることを必要としているといえる。サイバー犯罪条約の研究, 日本弁護士連合会組織犯罪関連立法対策ワーキンググループ編, 2003年9月, 第2章サイバー犯罪条約の刑事学的意義︵石井徹哉︶という点にあるのだと思うが、この結論を導くために、﹁電子計算機の利用﹂といえば﹁有体物としての電子計算機の︵不可分な︶利用﹂しか指し得ないという、刑法学上の伝統的解釈を引き合いに出して、現行法を全否定する論理構成がとられているが、では、﹁特定利用﹂という表現を単純に外来語たる﹁アクセス﹂に置き換えたら、それでその疑問が払拭されるのかというと、そういうわけでもあるまい。﹁サイバー犯罪条約の刑事学的意義﹂の主張は、﹁アクセス制御機能の社会的信頼の確保﹂を保護法益とするのではなしに、諸外国同様に﹁無権限のデータ・アクセス﹂を直接的に処罰するようにするべきだという点にあるのだと理解した。同様の主張は他の法学者からも口頭での議論において耳にした。しかし、そうした主張を聞きながら私が疑問に思ったのは、﹁では、無権限の定義は何ですか？﹂というものだった。﹁無権限﹂かどうかを客観的に評価できるように法律を定めたのが、不正アクセス禁止法の﹁アクセス制御機能により制限されている﹂という定義なのではないか。ところが、二号違反事件における違法性の解釈において、直感的にはその事例が﹁アクセス制御機能により制限されている﹂ようには見えにくいため、法律で禁止されるべきはずの︵と考えられることの少なくないらしい︶行為に対してこの法律が無力であるように見えるため、﹁アクセス制御機能により制限されている﹂では駄目で、﹁無権限データアクセス﹂で作り直そうという議論が再び巻き起こりかけたのだと思う。そこでそのとき私が主張したかったのは、﹁制限された利用﹂という概念を、要素的な個々の﹁利用﹂の集合として捉えれば、現行法の﹁アクセス制御機能により制限された利用﹂は﹁無権限データアクセス﹂と実質的に同義だということだった。つまり、﹁無権限﹂なるものの客観的定義が明確化された状況においては、﹁無権限のデータアクセス﹂行為は、必ず、利用の制限機構を回避する行為を通じてなされるはずであるのだから、﹁無権限データアクセス﹂を直接に対象としなくても、﹁アクセス制御機能による制限の回避﹂を処罰の対象とすれば済むということであり、これは逐条解説書のそこかしこに書かれている同法の目的の解説と符合している。それでもなお、﹁無権限データアクセス﹂を直接に対象とすべきだという主張は成立し得る。規制を現在以上に拡大しようとする場合においてはである。たとえば、電気通信回線を通じたアクセスだけでなく、直接手で電子計算機を操作して﹁無権限のデータアクセス﹂を行う場合や、目の前に置かれている記憶媒体のデータを許可なくコピーして持ち去ることや、暗号化して置かれているデータを許可なく解読したり復号する行為を処罰しようとすれば、﹁無権限データアクセス﹂という括り方をするのが統一的だということになる。

﹁無権限﹂をどう定義するか

しかしだからといって、現在の不正アクセス禁止法で守っているものまでもを、同様に﹁無権限データアクセス﹂という概念で括る必要があるということにはならない。もしそのような括りをすれば、﹁無権限﹂という概念の定義が再び求められることになり、けっきょく今と同じ﹁アクセス制御機能による制限の回避﹂に落ち着くのではなかろうか。私は、﹁アクセス制御機能による制限﹂という﹁無権限﹂の定義は、なかなか出来栄えのよいものだったと思っている。もしこれを取り壊して、別の﹁無権限﹂を今から定義しようとしたとき、どのような定義があり得るだろうか。ひとつには、﹁管理者の意図に反したアクセス﹂というものが考えられる。不正アクセス禁止法は、本来、コンピュータネットワークのセキュリティを高めるために必要とされるものであるはずのところ、この法律の存在が、かえってセキュリティを低下させているのではないかと指摘する声を、最近しばしば耳にする。つまり、安全管理が杜撰なWebサイトが不正アクセスによる被害に遭って、顧客に損害をもたらしたとき、運営者は自身の過失を省みるよりも先に、不正アクセスの犯人を非難して見せることによって、顧客からの責任追及を回避するという振る舞いが出てくる。これが社会的に容認されるようであれば、サイトの安全管理は向上しないままとなってしまうという懸念だ。もし、﹁無権限アクセス﹂の定義を﹁管理者の意図に反したアクセス﹂としてしまうと、管理者のこうした責任逃れの口実として、アクセス者が不正アクセス犯に仕立て上げられ、まさにそういう世の中になってしまうだろう。そうしたことが起こり得ることは、2002年に多発した、ファイル丸出し型の情報漏洩事件で実証されている。Webサーバの公開ディレクトリに秘密ファイルを置いておくという、最も杜撰なレベルの安全管理をしていたサイト運営者が、この事実がマスメディアにとりあげられるやいなや、﹁ハッカーによる不正アクセス被害だ﹂と釈明することが何度も繰り返し起きた。幸い、警視庁が被害届を受理せず、﹁道端に名簿を置いていたのと同じ﹂というコメントを出したことによって、そうした弊害は避けられた。つまり、不正アクセス禁止法は、﹁無権限﹂を﹁アクセス制御機能による制限を回避して﹂と定義したことによって、そうした弊害を避けるよう、うまく設計されていたと言えるのではないだろうか。

何を守る法律なのか

しかしその一方で、不正アクセス禁止法は、﹁パスワードさえかけておけば対策したことになる﹂という考え方をもたらした。パスワードがどんなに脆くて弱いものであっても︵たとえば4桁数字など︶、管理者はアクセス管理の責任を果たしたことになってしまう。不正アクセス禁止法が施行される前、いわゆる﹁ハッカー﹂を自称する輩が、﹁社会に警鐘を鳴らす﹂という大義名分の下、パスワード破りをして、パスワード認証の脆弱さを示してみせるという行為が横行していたと耳にする。同法が施行されて以来、そうした大義名分は成り立たなくなったわけで、現在、おそらく、脆弱なパスワードはそこかしこに存在していることだろう。つまり、パスワード認証の安全性についてだけ見れば、不正アクセス禁止法の存在によって、かえって社会は脆弱なままとなってしまったと見ることもできる。事実、強固な認証を実現できるはずである、SSLのクライアント認証︵電子署名による認証︶が2005年になっても未だほとんど普及していないわけだが、その要因の一つが、パスワード認証の信頼が不正アクセス禁止法によって保護されてきたことにあると言えるだろう。しかし、同法が施行された 2000年当時はどうだっただろうか。もし当時から、法による信頼性保護の対象を、電子署名による認証︵不正アクセス禁止法二条2項三号︶だけに限定して、パスワードを除外していたとしたら、その後、ネット社会はどのような進展を遂げていたであろうか。楽観的なシナリオでは、急速にクライアント認証が普及し、誰もが電子署名による認証を活用する安全性の高い社会が到来していたとなるが、悲観的なシナリオでは、何らかの理由でクライアント認証が普及せず、パスワードは破られ放題となり、インターネットによる取引自体が信頼に値しないものとして世間からみなされることとなり、ネット取引は今日ほど発展していなかったかもしれない。また、現時点で、もし、不正アクセス禁止法を改正して、パスワード認証を識別符号の定義から除外することにしたら何が起きるだろうか。施行まで1年程度の移行期間を置いて、その間に署名による認証に置き換えていくことが要請されることになる。たしかに、そうした方が社会は安全になるとも言えるわけだが、一方で、すべての認証が高度なものを要求されることになり、簡易なアクセス制限というものが存在しえなくなってしまうだろう。たとえば、Basic認証の効力について考えてみる。﹁無断リンク禁止教﹂を否定するネット識者の立場は、無断リンク禁止教を信仰する︵考えの浅い︶者たちが、リンクされていないという緩やかな方法でアクセス制限ができていると思い込むことは、情報漏洩のリスクを高めたり、公開すべきでない事柄を安易にネットに書いてしまうといったことをもたらすため、否定されるべき考え方だとの立場にある。情報の公開先を限定したいときは、パスワード認証をかけるのが常識とされなくてはならないと、無断リンク禁止教否定派は主張するわけであるが、これは、不正アクセス禁止法によるパスワード認証の信頼性担保が存在するからこそ成立するものであるとも言える。どんなに弱いパスワードであっても、パスワードさえかけていれば、無断で情報を持っていかれることをある程度制限できることとなり、無断リンク禁止という考え方よりは格段に良い。仮に、不正アクセス禁止法違反を犯してまで、その弱いパスワードを破って認証を突破したとしても、そこで得られた情報を第三者にまで流すことは憚られるはずだという、情報漏洩防止の効果もある。つまり、弱くてもパスワードがかかっていることによって、勝手に持っていくなという意思表示となり、誰でもそれを客観的に理解できる。その程度の弱いアクセス制限で十分な目的の場合もあるのであり、事実、私もその恩恵にあずかっている。もし、不正アクセス禁止法が改正されて、第二条2項から一号の規定が削除されることになったら、こうしてバランスしてきた秩序が崩壊してしまう。そう考えると、パスワード認証の信頼性を保護しているこの法律は、欠かせないものとなっているし、十分な役目を果たしてきていると言える。 1999年当時の報道を調べてみると、発表された法案に対する批判として、次のものがあった。不正な目的で無権限アクセスするのを禁止する目的犯規定になっていないため、偶然見つけた会員性Webサイトに出来心でIDとパスワードを入力したらログインできてしまっただけで、犯罪となってしまう。犯罪目的でログインしたわけでないのに、処罰されるのはおかしいというわけだ。だが、2005年現在、目的がどうであれ他人のIDでログインする行為そのものが禁止されていることによって、上に述べたような秩序が形成されており、他人のIDでログインしてはいけないという倫理観が醸成されていると言える。

不正アクセスを防止する法律に完全は求められない

このように、パスワードについてだけ見ても、法規制による不正アクセスの防止は、法律の存在によって脆弱な実態を存続させてしまうという負の効果ももたらしてしまうことをどうやっても避けられないし、当然、規制なしというわけにもいかないという、トレードオフの関係にあり、法律に完全さを求めるのは誤りということだろう。同様に、セキュリティホールを突いた攻撃を防ぐという目的での、法規制においても、両面があり、完全さを求めるのは無理がある。その最たる例は、2002年のファイル丸出し型の情報漏洩であろう。これらの事件では、ファイルが丸出しになっている事実が匿名掲示板で暴露されることによって、漏洩先の範囲が拡大した。これはどう考えても避けられるべき事態で、掲示板で暴露する行為は法律で取り締まられてしかるべきだと考える人も少なくなかったことだろう。一部の人は、丸出しのファイルに対してアクセスする行為自体が、不正アクセス禁止法違反にあたると考えたかっただろう。しかしそれは警視庁コメントで否定された。もし、これを不正アクセス行為として取り締まっていたら、本当に酷い脆弱な実態がそのまま温存されてしまったに違いない。一旦は悲惨な被害が多発したが、現在ではこうした事故はごく稀にしか見られなくなり、痛みを乗り越えて対策が進んだことがうかがえる。ファイル丸出し型漏洩も、一種の﹁セキュリティホール﹂や﹁脆弱性﹂として分類されることが多い。管理者の意図からすれば、ホールとなっているし脆弱性であるからだ。だが、法律では、管理者の意図ではなしに、客観的な評価でアクセスが制限されているかどうかで判別される。したがって、原理的には、他の種類のセキュリティホールや脆弱性についても、そこを突く行為が、不正アクセス禁止法で処罰できないものが存在する可能性は否定できないことになる。

二号三号不正アクセス罪の曖昧性﹁∃﹂と﹁∀﹂の解釈

さて、不正アクセス行為の規定は曖昧だということが、以前より指摘されている。第三条2項の一号は曖昧ではないが、二号と三号が曖昧である。一号では、何が﹁制限されている利用﹂にあたるかがその行為自身によって決定付けられている。つまり、他人の識別符号を入力することによって利用制限が解除される利用が﹁制限されている利用﹂であって、他人の識別符号を入力する行為は、それと同一の利用集合を利用可能にするのであるから、曖昧性の余地がない。たが、二号、三号ではそうはならない。まず、﹁当該アクセス制御機能による利用の制限を﹂とされているから、ある行為が二号、三号違反であると示す際には、必ず、﹁どのアクセス制御機能に︵どの識別符号が︶入力されたのときに解除されるはずの制限が免れられたのか﹂を示すことが必須となる。それが示されたならば、示された識別符号の入力による解除が行われた場合における、解除前では制限されていて解除後では制限されていない状態となる利用のそれぞれの集合を指して﹁制限されている利用﹂集合と呼ぶことができ、この解釈はこれで間違いないと思うが、問題は、﹁その﹃制限されている利用﹄をし得る状態にさせる﹂という文の解釈である。ここは次の2つの解釈があり得る。 (a) ﹁制限されている利用﹂集合の要素の少なくとも1つを﹁し得る状態﹂にさせる行為 (b) ﹁制限されている利用﹂集合のすべての要素を﹁し得る状態﹂にさせる行為多くの人は直感的に(a)の解釈を選択するのではないかと思われる。私もかつてはそのように解釈しようとしていた。じつは、昨年10月4日の﹁数理的理解の試み﹂は(a)の解釈を試みたものであり、11月21日の﹁続・数理的理解の試み﹂は(b)の解釈を試みたものである。法律の文章を情報技術者が読むと、﹁かつ (and)﹂なのか﹁または (or)﹂なのかが不明になっていることに苛立ちを覚えることがしばしばある。上の解釈では、﹁∃﹂なのか﹁∀﹂なのかが曖昧だということだ。 (a)の解釈を続けようとすると、矛盾が多数噴出して解釈が続行できなくなる。そうした矛盾は10月4日の日記に既にいくつか書いている。とくに、複数のアクセス制御機能が存在する場合の解釈が困難になる。たとえば、図1のように、2つの異なるアクセス制御機能における2つの別々の利用権者に、共通の制限された利用集合︵赤線と青線が重なった部分︶が存在する場合、橙色の利用権者がその部分の利用をする行為をしたとき、黄色のアクセス制御機能から見れば、そのアクセス制御機能において黄色の利用権者の識別符号によって制限している利用をし得る状態にしたと解釈することができてしまう。

図1: 複数のアクセス制御機能が共通の要素利用を制限解除しているとき

当然ながら、直感的には、橙色の利用権者は自身の正当な権限に基づいてその利用をしたとみなされるべきだと誰もが思うわけだが、不正アクセス禁止法の条文には、複数のアクセス制御機能が存在する場合の除外規定が何も書かれていないので、黄色のアクセス制御機能に対する﹁侵害﹂が、橙色のアクセス制御機能の存在によって除外されるとはどこにも書かれていないのである。もうひとつは、罪数をどう数えるのかが定まらなくなる懸念がある。これについては、10月4日の日記﹁不正アクセス禁止法罪数の矛盾？﹂で検討した。ところが、先の (b)の解釈︵﹁∀﹂の解釈︶を選択すると、これらの矛盾は払拭されるのである。 (b)の解釈は、慣れないと不自然に感じられるかもしれない。利用集合というものがあって、そのすべての要素を利用するというのはどういうことなのか？という疑問が湧くだろう。だが、この法律は、﹁利用する行為﹂ではなく、その制限されている利用をし得る状態にさせる行為とあるように﹁利用をし得る状態にさせる行為﹂と定義されているのである。﹁制限されている利用﹂集合の全ての要素を一旦、利用し得る状態にした上で、その1つの要素を実際に利用する行為――という読み方ができる。ようするに端的に言えば、(b)の解釈は、あるアクセス制御機能に対して、ある識別符号を入力したのと同一の状態を︵識別符号の入力以外の方法で︶作り出す行為を指すという解釈である。この解釈を選択すれば、(a)で湧いてきた矛盾点︵の大部分︶が払拭されるだろうと直感できるはずだ。なぜなら、一号違反行為︵他人の識別符号を入力する行為︶に置き換えて解釈することができるからだ。たとえば、図1のケースは(b)の解釈ならば矛盾なく解釈できる。橙色の利用権者はログインによって、青線の集合の各要素を﹁利用し得る状態﹂にするだけであり、赤線の集合の要素の全てを﹁利用し得る状態﹂にするわけではないからだ。 CGIの引数にパス名を与えたらそのファイルが閲覧できてしまった場合を考えてみる。10月4日の日記にも書いた図2のケースである。

図2: セキュリティホールから可能な利用が制限された利用の一部にすぎない場合

たとえば、黄色のアクセス制御機能はメンテナンス用のFTPパスワード認証だとしよう。FTPで可能なことは、ファイルの読み出しだけでなく書き込みもあるし、アクセス可能な場所はそのアカウントに許されているディレクトリ全域となり、それが赤線の利用集合で表されている。そこに、CGIの引数にパス名を与えたら、青線で示す利用集合が利用し得る状態になった︵そしてそれを利用した︶としよう。その行為によって﹁し得る状態﹂になった利用集合の範囲が、図のように赤色集合を包含していないならば、不正アクセスにあたらない。(b)の解釈ではそのようになる。ではどのような場合が不正アクセスにあたるかというと、11月21日の日記にも書いた図3のケースが該当する。

図3: (b)の解釈で二号違反となる行為

具体的には、まず、バッファオーバーフロー脆弱性を突いてシェルを乗っ取った場合が該当する。シェルを乗っ取った場合というのは、必ず、特定の識別符号でログインしたのと同じ状態を作り出すものであるから、どのアクセス制御機能のどの識別符号が侵害されたかが明確に決定される。その点が明確であることは、この法律の保護法益が﹁アクセス制御機能に対する社会的信頼性の確保﹂であることから、元々要請されているところであり、(b)の解釈は保護法益に即したものとなっていると理解できる。他には、SQLインジェクション脆弱性のあるログイン画面のパスワード入力欄に、SQL文の断片を入力することで、パスワードなしに他人のユーザIDでログインしてしまう行為は、そのユーザIDの識別符号でログインしたのと同じ状態を作り出しているのであるから、(b)の解釈に基づいて、そのアクセス制御機能のその識別符号による制限を侵害したと理解できる。また、他人のcookieに格納されているセッションIDを何らかの方法で盗み出して、それを用いて当該サイトにアクセスする行為︵セッションハイジャック︶も、(b)の解釈に基づいて、そのセッションIDに対応する識別符号をつかさどっているアクセス制御機能を侵害したと単純に理解できる。他にも、CGIの引数にOSコマンドインジェクション脆弱性がある場合は、シェルによるコマンド起動をし得る状態にした上でコマンドを起動したとみなせば、そのプロセスのユーザIDの識別符号についてそのアクセス制御機能を侵害したと解釈できる。ところで、CGI引数にパス名パラメータを渡したら、httpdにとっての非公開領域にあるファイルを閲覧できたという状況について検討してみる。それが管理者の意図に反するものかどうかは、客観的には判別されない。なぜなら、httpdにとっての非公開領域にあるファイルを、CGIプログラムを経由することによって意図して公開する作りになっているサイトは、ごく普通に存在する︵掲示板など︶からだ。それは、CGIにとっては公開領域にあるデータだということになる。しかし、それが管理者の意図によるものではなく、CGIプログラムの欠陥によるものだという場合には、不正アクセス禁止法違反とされるべき行為だと考える人もいるだろう。だが、先に書いたように、この法律の立法趣旨が、﹁無権限データアクセス﹂といった主観的な基準︵管理者の意図など︶によって﹁無権限﹂を定義しているのではなく、﹁アクセス制御機能による利用の制限﹂という客観的な基準で﹁無権限﹂を定義しているのであれば、(a)または(b)の解釈によって客観的に判別するしかなく、(a)の解釈を選択すると矛盾が噴出してしまうところ、(b)ならば矛盾なく解釈でき、(b)で解釈するとすると、その行為は不正アクセスにはあたらないということになる。 (b)の解釈をすると、いくつかのよく知られた脆弱性を突く行為が、法律で規制されないことになってしまう。これは、昨年7月18日の日記﹁不正アクセス禁止法情報セキュリティ技術者が期待するはずのもの﹂に書いたように、情報セキュリティ技術者にとって困ったことになる。だが、ファイル丸見え漏洩という事態だって困ったことであったわけで、先に書いたように、不正アクセスを防止する法律に元々完全は求められないのである。どこかに線引きをして、ここまでは法律による保護もあるが、ここからは保護されないので、最低限の安全対策として︵ファイル丸出し同様に︶必ず実施しなくてはならないこととして、倫理を形成していくしかないのではなかろうか。

建造物侵入との対比

不正アクセス禁止法違反行為を﹁侵入﹂という言葉で表現されることが多い*2が、これを建造物侵入︵住居侵入︶のネット版だとみなす考え方も存在する。たしかに、1980年代から90年代前半ごろまでの社会を振り返れば、当時のコンピュータは電話回線でつながっていて、アクセス権者︵たいていは管理者︶だけがそこに電話をかけてパスワードを入れてログインするという使い方があり、そこを第三者が見つけて不正にログインする行為は、住居侵入に近い感じがしないでもない。しかし、インターネットでWWWが普及したこの10年では、サーバは公開状態にあり、誰でも無許諾でアクセスするのが当然であり、リンクは無断で行ってよく、Webロボットは自動的にデータを集めていくものであり、非公開情報はWebに置かないのが当然とする倫理観が形成され、もはやインターネットにつながったコンピュータを住居に喩えるのは無理がある状況となっているように思う。そうした変化が既に訪れ始めていたころに、不正アクセス禁止法は制定されており、その変化に対応できているように私には思える。(b)の解釈をするならばだ。そうすると、不正アクセス禁止法は、﹁住居﹂の概念のように私達の個人の安心した私生活の場を守ってくれるものではないことになる*3。これに対する不満や不安が、今、一般の人々の間にあるかもしれない。不正アクセス禁止法施行後に、ブロードバンド時代が到来し、今や大半の人が自宅でパソコンをインターネットに常時接続しており、それらのコンピュータへの侵入行為がもし法律で処罰されないとすると、法整備が不十分だということになる。しかし、それを現行の不正アクセス禁止法の解釈の拡大で、保護されていることにしようとするのは無理があるのではないか。インターネットには、私的空間と公的空間の区別がない。私的空間を住居のように扱って保護しようとするのであれば、別の立法が必要であろう。たとえば、NATルータの内側を私的空間と定義するとか、一定のファイアウォールの内側を私的空間と定義するといった考え方の延長で何かできるかもしれない。︵できないかもしれないが。︶

*1 その後この文献を入手したので読ませていただいた。肝心な部分は奥村弁護士のはてなダイアリー7月12日のエントリに不足なく引用されている。 *2 とくにマスコミで。﹁不正侵入﹂と書かれることもあるが、侵して入ることなのだから常に不正であるはずで、不正な侵入という表現は変だ。逆に、違法でない行為に対して﹁侵入﹂という表現が使われることがあるが、それも誤りだ。 *3 実際、この法律の初期の案では事業用のコンピュータだけを対象としていたところ、パブリックコメントで、事業用も非事業用も区別なく保護するべきだとの意見があり、区別しないよう変更されたという経緯があるくらいだ。

本日のリンク元 TrackBack(1)

2005年03月27日

■ PKIよくある勘違い(8)「自分専用なのに第三者から証明書を買えというのはおかしい」

PKIというよりSSLにある勘違いであるが、オレオレ証明書を使うべきでないという考え方が広まってくると、今度は、自分専用のサーバなのに、﹁オレオレ証明書じゃだめなのか？﹂と考えてしまい、﹁自分専用なのに何万円も払って証明書を買わないといけないなんてのは、どう考えてもおかしい！何か間違ってる！﹂といった思考に至ることがありそうだ。自分専用であればオレオレのサーバ証明書で運用してかまわない。ただし、ブラウザの警告を無視して﹁はい﹂を押してはいけない。﹁能動的な盗聴﹂の被害に遭うおそれがあるという点で、SSLの機能は完全には働かないからだ。こういうとき、Webブラウザが Firefoxであれば、次の手順で設定することで、自作のサーバ証明書で正しく安全に運用できる。まず、サーバに自作の証明書と秘密鍵をセットする。そして、その証明書を手作業で︵ネットを使わずに︶運んできて、ブラウザにインポートする。インポートの手順は以下の通り。メニューから﹁オプション﹂を開き、﹁詳細﹂を選択して、﹁証明書マネージャ﹂ボタンを押す︵図1︶。

図1: 証明書マネージャ起動ボタン

証明書マネージャで、「サイト証明書」タブを選び、「インポート」ボタンを押す。

図2: サイト証明書ストアにインポート

ファイル選択ダイアログが現れるので、手作業で運んできた証明書ファイルを選んで開く。図3のようにインポートされる。

図3: インポートした直後の様子

インポートした項目を選択して「設定」ボタンを押すと、「サイト証明書に対する信頼性の設定」という設定ウィンドウが現れる。

図4: 「サイト証明書に対する信頼性の設定」画面

ここのデフォルトは﹁この証明書が本物であると信頼しない﹂になっているので、﹁信頼する﹂に変更して﹁OK﹂を押す︵図4︶。これで、サーバにアクセスすると警告なしに正常に SSL接続される。ここで重要なのは、インポート先が﹁認証局証明書﹂ではないということだ。自分で作ったオレオレ認証局証明書を﹁認証局証明書﹂ストアにインポートする方法でも、同様に正常なSSL接続を実現できるが、その設定をすると、万が一秘密鍵が流出したときに、あらゆるサイト︵銀行とかネットショップとか︶の偽証明書に騙される︵もしくは能動的盗聴をされる︶リスクが生じてしまう。それに対し、オレオレサーバ証明書を﹁サイト証明書﹂ストアに登録するこの方法であれば、万が一秘密鍵が流出しても、自分用のサーバへのアクセスにリスクが生じるだけで済む。この方法が妥当なのは、自分ひとりで使うからだ。サーバに証明書を設定するのが自分であるなら、その証明書を運んでブラウザにインポートする作業の手間は問題にならない。複数人で使う場合はどうか。全員に証明書を手渡しできるのであれば、この方法でもよいかもしれない。しかし、大規模な人数となってくると、手渡しにかかるコストが高くなり、商用認証局からサーバ証明書を購入して運用した方が安くなるだろう。なお、インポートする前にサーバにアクセスしたときに出るブラウザの警告で、図5のように、﹁今後この証明書を受け入れる﹂を選ぶことで、上に書いた手順︵サイト証明書ストアへインポートし、﹁この証明書が本物であると信頼する﹂を設定︶と同じ設定になる。

図5: ネットワーク経由でインポートしようとしている様子

しかし、これは、信頼できない通信路のネットワーク経由で証明書を運んでいるのだから、もしこの時点で中間者攻撃を受けているのなら、将来にわたって攻撃され続けることになるので、避けるべきである。そうした事態が発生している確率は小さいだろうという判断から、手抜きをして、図5の方法でインポートすることもアリかもしれないが、そのリスクを理解した上で行わなければならない。サーバをセットアップするような技術者が自分が使うためだけに行うのであればそれもよいだろうが、一般のユーザ向けに使わせるのであれば、図5の方法は避けるべきだ。意味も分からず何でも﹁今後受け入れる﹂を押すようになってしまうに違いない。それを避けるために、証明書を手渡しして、手作業でインポートし、設定させるのがよい。ちなみに、ここまでの話はブラウザが Firefoxの場合であるが、Internet Explorerの場合はどうかというと、なんと、この機能が存在しないのだ。

図6: Internet Explorerの証明書マネージャ

図6のように、IEの証明書マネージャには、サイトを個別に受け入れるための証明書ストアが存在しない。このことが、誤ったPKIの使い方を蔓延させるきっかけになったとも言える。IEでのアクセスを前提とすると、自作のサーバ証明書で運用しようとすれば、オレオレ認証局の証明書をルート認証局としてブラウザにインポートせざるを得なくなる。どうしても、IEを前提としてオレオレ証明書で運用したいなら、次の方法がある。自作のサーバ証明書に自作の認証局で署名したら、署名した直後に認証局の秘密鍵を消去してしまうことだ。こうすることで、秘密鍵が流出したときのリスクが、上のFirefoxでサイト証明書にインポートするときと同じになる。ただし、ルート証明書をインポートするというハイリスクな行為が普通のものだと麻痺させてしまうおそれがあるので、自分専用でない限り避けるべきだろう。というわけで、自作証明書で運用したいなら、﹁Internet Explorerでのご利用はサポートしていません﹂とお断りしよう。

本日のリンク元 TrackBacks(2)

高木浩光＠自宅の日記

2005年03月01日

■ 明後日3日木曜日はIC CARD WORLDでパネル討論

■ 日経サイエンスに「オレオレ証明書」

2005年03月04日

■ 万博やばいです！

2005年03月05日

■ Suica番号がメールアドレスと結び付けられ始めた

■ Edyナンバーをいろいろ流用するのが花盛り

■ 電子パスポートの光学式アクセス制御

2005年03月06日

■ 自治体は誠実なのか不誠実なのか

追記

2005年03月11日

■ 非接触ICカードがなりすまし不能とまでは言わないので注意

■ 無題

■ 無題2

■ 無題3

2005年03月15日

■ 銀行業界が自治体に苦情を申し立てても不思議でない

■ Phishing報道は何を伝えるべきか

2005年03月16日

■ Phishingの偽サイトに https:// でアクセスしてみると

2005年03月24日

■ 不正アクセス禁止法私はこう考える

﹁利用﹂とは何か

﹁無権限﹂をどう定義するか

何を守る法律なのか

不正アクセスを防止する法律に完全は求められない

二号三号不正アクセス罪の曖昧性﹁∃﹂と﹁∀﹂の解釈

建造物侵入との対比

2005年03月27日

■ PKIよくある勘違い(8)「自分専用なのに第三者から証明書を買えというのはおかしい」

最近のタイトル

高木浩光＠自宅の日記

■ 明後日3日木曜日はIC CARD WORLDでパネル討論

■ 日経サイエンスに「オレオレ証明書」

■ 万博やばいです！

■ Suica番号がメールアドレスと結び付けられ始めた

■ Edyナンバーをいろいろ流用するのが花盛り

■ 電子パスポートの光学式アクセス制御

■ 自治体は誠実なのか不誠実なのか

追記

■ 非接触ICカードがなりすまし不能とまでは言わないので注意

■ 無題

■ 無題2

■ 無題3

■ 銀行業界が自治体に苦情を申し立てても不思議でない

■ Phishing報道は何を伝えるべきか

■ Phishingの偽サイトに https:// でアクセスしてみると

■ 不正アクセス禁止法 私はこう考える

﹁利用﹂とは何か

﹁無権限﹂をどう定義するか

何を守る法律なのか

不正アクセスを防止する法律に完全は求められない

二号三号不正アクセス罪の曖昧性 ﹁∃﹂と﹁∀﹂の解釈

建造物侵入との対比

■ PKIよくある勘違い(8)「自分専用なのに第三者から証明書を買えというのはおかしい」

最近のタイトル

■ 不正アクセス禁止法私はこう考える

二号三号不正アクセス罪の曖昧性﹁∃﹂と﹁∀﹂の解釈