最新 追記

高木浩光@自宅の日記

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

2005年01月01日

「たけしのやってはいけない」でRFIDの話題?

「たけしのやってはいけない」でRFIDの第三者読み取りの問題が扱われたらしい。

  • 非接触型ICカードのスキミングについて, コハリトの見下げ果てた日々, 2004年12月18日

    開いた口がふさがらぬ、とはまさにこのことである。テレビ番組「たけしのやってはいけない」で取り上げた、非接触型ICカードのスキミングについてである。

    (略)

    番組関係者に言いたい、取り上げるのならきっちり勉強した上でその筋の専門 家に解説させろ、と。一般ユーザーに間違った知識を植え付けるのはやめてく れ、あとで説明しなおすのがえらく大変なのである。

残念ながら見ていない。

どうやら、12月17日放送の「スーパー フライデー たけしの緊急警告SP 絶対やってはいけない」のことらしい。 どんな内容だったのだろうか。

見たい。見たい。見たい。

本日のリンク元 TrackBack(0)

2005年01月07日

夢を適当に語るだけで済む商売は楽でいいね

正月だからということもあるのだろうか、毎日新聞に「夢と希望いっぱい、 近未来の新技術」という記事が出ていた。

  • 近未来のテクノロジー:夢と希望いっぱい、近未来の新技術(その1), 毎日新聞, 2005年1月4日

    ◇横断歩道−−お年寄りもゆっくりと

    ICタグは、高齢化社会の安全を守ることにも応用できる。

    お年寄りや障害のある人にICタグを配り、あらかじめデータベースにしておく。外出時には胸にICタグを付けてもらい、センサー付きの信号機に近づくと、信号機を制御するコンピューターが、お年寄りや障害のある人であることを感知。青信号に切り替え、道路の向こう側の信号機センサーが渡り終わったことを感知するまでは、青のままにしておくことが可能だ。これで、横断の途中で信号が変わってしまい、事故に巻き込まれるような不幸なケースを減らすことができる。

くだらない。

そんなシステムを導入すると何が起こるか予想してみよう。

まず、そのタグを持ったお年寄りはしだいに信号機のその動作に慣れてくる。 ほとんどすべての信号機がその機能に対応した未来が到来すると、お年寄りは 信号機が当然にそういう動作をするものだと思い込むようになる。すると、 信号がもうすぐ赤になりそうかどうかに無頓着に、青を見たなら渡ってしまう 癖を持つお年寄りが出てくるだろう。

そういうお年寄りが、タグを持ってくるのを忘れたとき、あるいはタグを電波 が遮断されるところに入れていたとき、既に青信号のところを渡り始めるとど うなるか。信号機はタグを検出せず通常通りのタイミングで変わり*1、お年寄 りはダンプカーに跳ね飛ばされて死亡する。

あるいは、保険金目当てなどで特定のお年寄り(その信号システムに慣れてい るとする)を殺したいと企てた者が、電波を遮断するカバンをお年寄りにプレ ゼントして、お年寄りがたまたま青信号のところを渡り始めるのを期待し、車 にはねられ事故死するいくらかの確率に期待する。

あるいは、いつでも青信号にして渡れるタグだとして、健常者のくせにお年寄 り用のタグを入手して密かに横断歩道を我が物にする人々が続出し*2、自動車交通は麻痺し始める。

あるいは、たくさんの人で溢れている都会の交差点で、お年寄りが横断歩道を 渡り始めたがまだ渡りきっていないとき、歩行者用信号は青点滅を繰り返すこ とになるだろう*3が、 そのとき後から来た他の人の群集も、青信号だということで渡り始める。そして、 群衆の中で見えないお年寄りが渡り終えた直後、信号は突如赤に変わり、たく さんの人々が中央分離帯に取り残される。

RFIDタグをなんとかして「善」(っぽい)用途に使って見せようと必死な人が、 こういう浅はかな発想に溺れがちで、怖い。

HTMLメール、その嫌われ者としての歴史

これはよい記事。

HTMLメールが(心ある人達には)忌み嫌われてきた、その理由の変遷という形 でまとめられている。

*1 こ の問題を回避するには、押しボタンなどで人が意識的に機械に指示を与えるよ うにする必要があるだろう。何でもシームレスにすりゃ近未来っぽいという発 想がくだらない。RFIDはそのボタンを押す権限を持つ人かどうかを認証するた めに使えばよい。ただし暗号演算つきのRFIDである必要がある。

*2 こ れはどうやって防ぐか。お年寄りでもないのにそのタグを持っている人がいな いか、誰かが監視するのだろうか。

*3 点滅にはならないという設計も考えられるが、その場 合は、点灯青信号だと思って渡り始めると、突如赤になるという事態になる。 それを避けるために、お年寄りが渡りきった後に青点滅の期間が入るという設 計にもできるが、すると、誰もいないときに無駄な青信号時間が生じてしまう。

本日のリンク元 TrackBacks(2)

2005年01月11日

広島市曰く「警告は出ますがセキュリティ自体には問題ない」

広島市がサービスしている「広島市大型ごみ収集申し込み」というWebサイトがある。ページの下の方を見ると、

※ ここから先は、SSLによって全ての個人情報は暗号化されます。
下のボタンを押すと申込みの開始となります。

と約束されている。その「申 込みのページへ」ボタンを押すと、ブラウザが次の警告を出す。

図1: 広島市大型ごみ収集申込みのページにアクセスしようとしたときの画面

黄色い警告マークが3つも並んでいるのは珍しい事例だ。証明書の内容を確認 すると、図2のように、有効期限が2003年1月(2年前)に切れており、証明書 の発行者は、「Hiroshima」の「Hiroin」という組織の「ITO Center」という ところとだ書かれている。

図2: https://www.ogatagomi.kankyo.city.hiroshima.jp/ が送信してくるサーバ証明書の内容

また発行先(サブジェクト)のCommon Nameを見ると、図3のように 「www.hiroins-net.ne.jp」と書かれており、 アクセス先サーバである広島市の「www.ogatagomi.kankyo.city.hiroshima.jp」 とは全く異なるサーバ用の証明書が使われている。

図3: https://www.ogatagomi.kankyo.city.hiroshima.jp/ が送信してくるサーバ証明書の概要

www.hiroins-net.ne.jp のトップ ページにアクセスしてみると、株式会社広島市産業情報サー ビスという第三セクターの組織が取得しているドメイン名だということが わかる。

当社は、急速な情報化の進展の中で、広島市経済の振興を図るため、地域企業 における経営の効率化と情報機能を強化し、高度な情報処理機能と地域の特性 を活かした情報ネットワークを形成することを目的として、昭和63年2月、 広島市・地元企業などが出資して設立した第三セクター方式の株式会社です。

株式会社広島市産業情報サービス 会社概要

このことについて広島市役所はどう考えるのか、電話でインタビューしてみた。


私: セキュリティの警告というのが出たのですが。

広島市: こちらで借り上げしているサーバの関係で、 サーバの認証の期限が切れているそうなんです。 それでセキュリティの警告が出てしまうのですが、 特段問題ないはずなので、 そのまま申し込んでください。

私: 特段問題ない……?

市: ええ。単に認証の期限が切れているということなので。

私: でも、セキュリティの警告っていうくらいですから、何か問題があるんじゃ ないかと思うんですけども。

市: 認証機関が発行する期限を過ぎているということで表示が出てしまうんです。 市からも職員が行っている関係団体のサーバを借り上げているので、 セキュリティ自体には問題なかろうと思います。

私: セキュリティ自体には?

市: ええ、セキュリティ自体には問題ないはずです。

私: でも、何のために期限というものがあるんですかね?

市: 期限については広島市ではいかんともしがたい。 認証してくれる機関のやっていることなので。 マイクロソフトが警告を出す出さない設定するらしい。 警告が出ていたら必ずしも怪しいというものではない。 あくまで参考程度に考えていただくのがよろしかろう。

私: はあ。あくまでも参考程度のものだと。

市: マイクロソフト社というところがですね、パソコンを安全に使っていただ くにあたってそういう仕組みを導入しているものですから、

私: はい、じゃあやっぱり安全のために必要な仕組みじゃないんですかね?

市: 安全な仕組みではあろうかと思う。で、サーバの認証がたまたま今、期限 が切れているということなので、警告文が出てしまうんですけども、 セキュリティ自体に問題があるわけではない。

私: そのときのおっしゃる「セキュリティ自体」というのはどういう意味です か?

市: 通信する際に個人情報が漏れるんじゃないかということですね。 それがセキュリティということでしょうから。

私: 暗号化ということですか?

市: そうですね。暗号化によってよその者のアクセスによってお宅様の個人情 報が奪われないようにするためのものが暗号化ですから。

私: 期限はどうでもよいということなんでしょうか?

市: いえいえそういう意味じゃなくて、更新はしないといけないのですが、 更新は広島市のサーバではなくて、 借りている先の会社に更新してくれと言わないといけないのですけども。 広島市が直接できるわけではないので。

私: え? でもこのサービスの管理責任者は誰なんですか?

市: 広島市長になろうかと思います。

私: であれば、広島市ができるわけじゃないというのはおかしいんじゃないで すか? あなた方がこれを管理する責任があるんじゃないのですか?

市: ええ、それをこちらで会社の方にしてくれと言っていますので。

私: それはいつの話ですか?

市: それは……、期限がいつになっているのか記憶していないので、 今わからないのですが。

私: これ、今もやっているサービスですよね?

市: はい。

私: 有効期限が2003年1月なんですけど。2年も経っていますが。

市: ほうほうほう。ちょっとその表示もどうかと思うんですが……。 借り上げしている会社の方に確認してみます。

私: 同様の問い合わせはきていませんか? 警告が出るという。

市: 警告が出るという問い合わせはたまに来る。年に2、3件くらいはある。 今年度で私が受けたのが2回目ぐらいです。 前回のときも会社に確認してみたんですが。

私: で、どうなったんでしょうか。

市: 「わかりました」ということでですね、それ以降連絡とってなかったので。 まだそれが更新されていないということなので、ちょっともう一度確認をとっ てみようと思います。

私: 期限が切れてから2年もたっているというのはかなりおかしいと思うんで すが、どうでもよいということでしょうか?

市: 少なくとも広島市としては、サーバの安全性は確保しているということは、 自信を持って回答できるのですが。

私: セキュリティについて広島市としては自信を持って……何ですか?

市: 安全なサーバだということは、広島市の関連団体のサーバですので、 サーバ自体の安全性については、問題ないと。

私: 安全というか、ようするに偽じゃないということがおっしゃりたいのでしょ うか?

市: サーバが安全なものか安全でないものか、わからないよというのが警告文 の趣旨だと思いますので。

私: 違いますよ。通信が暗号化されるかどうかの話ですよね。 暗号化に使う証明書の有効期限が切れているのですが。

市: いや、暗号化に使う証明書の証明期限が切れているということはないと思 うんですが。暗号化というのは有効期限があるわけではないので。

私: あります。

市: 暗号化というのは情報を送るときの方式なので。

私: 暗号化するにあたって、秘密鍵に有効期限があるわけですよ。 だんだん暗号は弱くなっていくわけですね。 もし誰かが鍵を解くために大きなコンピュータで総当りで試していくと、 たとえば何十年か、何百年かで、確率的には鍵がばれてしまう可能性は あるわけで、いつまでも同じ鍵を何年も使っていてよいわけではないから、 有効期限というのがあると思うんですがね。

市: 出ている表示に、暗号化の有効期限と出ていますか?

私: でもそういうことなんですよ。 それからですね、有効期限の問題だけではなくて、 他にも全部で3つ警告が出ているのですが。

市: 3つ警告が出ている?

私: お使いになったことはありますか?

市: はい。

私: 2番目の警告が有効期限のものですが、「このセキュリティ証明書は信頼 する会社から発行されていません」というのが1番目、3番目が「証明書の名前 が無効であるかまたはサイト名と一致しません」という、他の警告も出ている のですよ。

市: はい。それはですから、すべてそのサーバの認証の期限が切れていること によるものだと思うんですけども。

私: 違います。

市: 違いますか?

私: はい。

市: 私が聞いている説明と異なってくるのですが。

私: 出ている警告の文章をご自身でご覧になりましたか?

市: ええ。

私: 名前が無効またはサイト名と一致しないと言っているのですし、信頼する 会社から発行されていませんと出ているのですよ。

市: はい。マイクロソフト社が認証するのに適した機関として認めた会社から 出てないということだと思うのですが。

私: そうですね。それが何ですか? 普通のサイトでこんな警告は出ないですよね。

市: ですからそれは、 マイクロソフト社が認証を発行すると認めている会社の認証をうけているから ですよね。

私: 誰がですか?

市: そこそこのホームページを持っている会社のサーバはですね。

私: なぜ同じようにやらないのでしょうか?

市: ですからそれは、こちらの方で借り上げているサーバの問題がありますの で、その点について不自然を感じられる点についてお詫びします。 今それを改善をはかっているところですので。

(中略)

私: 信頼済みとして登録していない認証機関から発行されているからですね。

市: 認証機関から発行されているかされていないかはわからないのでは ないですかね。

私: わかりますよ。証明書の表示というボタンがありますが、押したことない ですか?

市: いやあります。

私: どう出ましたか?

市: 今、発行している機関が偽の機関が出るということですか?

私: 偽と区別がつかないということです。

市: マイクロソフトが認証していない会社だからということですかね?

私: マイクロソフトがというかですね、……まあ、それでもいいですが、 だから何だということでしょうか?

市: マイクロソフトが認証していない会社から出ているということですか?

私: もっと正確に言うとですね、Windowsには信頼済みルート認証機関という のがたくさん登録されているわけです。有名なところではベリサインとか、 国内ですとセコムトラストネットとか、日本認証サービスといった会社がある んですが、そういうところから証明書を発行してもらわないと意味ないのですよ。

市: まあですから、承認というのがですね……

私: 承認? 暗号自体が正しく動かないのですよ。

市: 受付はできているんですけどね……。

私: それはだから、盗聴される可能性がある状態で受付ができているというこ とですよ。暗号は働いてないってことです。

市: んー? んー。 改めてホームページを作っているところ、○○○なんですけどね、そこに確認 をとらせていただきます。

(中略)

市: お宅様がそこまでの知識をお持ちというのはそういう関係のお仕事をされ ているということでしょうか?

私: 普通の知識です。普通ですこんなのは。だいたい、警告が出るということ はおかしいのですよ。でもあなたは最初にご説明いただいたように、問題ない とおっしゃいましたよね。こういう警告が出ても無視すればよいと市民に説明 なさっているわけですよね?

市: はい。

私: じゃあ、悪い人が盗聴しようと思って、間に入ってですね、偽の証明書を 出してですね、偽のといってもですね、全く同じ偽の証明書を作ることはでき るんですよ。発行者とか発行先とかに hiroins-net.ne.jp といった全く同じ 表示をする証明書を作ることは誰もすぐにできるんですよ。タダで。ソフト動 かして証明書作るだけなんですね。ここに書いてあることは全く意味を持たな いんですよ。これに、公開鍵暗号という仕組みを使って電子署名することでやっ と、本物だということが確認できるわけですね。 それはどこかの第三者機関にやってもらわないといけないわけですよ。

市: はい。

私: しかもそれは、普通の社会における第三者に認証してもらうといっ たそういう話ではなく、技術的な意味が重要なんですよ。つまり、Windowsに 最初から入っている認証機関から署名してもらうことによって、機械的にこれ が本物だということが確認できるんですね。よそはみんなそうやってやってい るんですよ。そういうときは正常だから警告が出ないで、SSLでhttpsのアクセ スができるわけですが。

市: はい。

私: もし悪い人がなりすまして通信の間に入って、本物サイトとの通信を傍受 するということをしようとすれば、この警告が出るわけですよ。そのための 警告なんですね。

市: はい。……うん。

私: おわかりいただけたでしょうか?

市: はい。あの、その点についても hiroinと○○○に確認をとらせてくださ い。今驚いているというのが正直なところです。

私: だいたい、そもそもこんなことは誰でも知ってないといけないのですよ。 べつに専門家じゃなくても、一般の市民でも。

市: いやー、一般の市民でそこまでご存知の方いらっしゃらないと思いますよ。

私: 違います。一般の市民はセキュリティの警告が出たら「いいえ」のボタン を押さないといけないのですよ。理由は知らないにしてもです。 セキュリティの警告が出たら相手が偽かもしれない、直接の通信先が偽かもし れないわけだから、「いいえ」を押さないといけないわけですよ。これは 知っていないとどうしようもないですよね?

市: 自分のパソコンを守るという点でですね。あと、自分の情報を守るという 点でその方が必要と判断すればやはり「いいえ」を押さないといけないと思い ます。

私: そうですね。だからこれは高度な話ではないんですよ。誰もがコンピュー タを使うにあたってのリテラシーとしてですね、知ってないといけないことで す。それをあなた方は、過去に年に2、3人の人に対して、「はい」を押してよ いと、何ら問題ありませんと説明してきたわけですね。これは、広島市のシス テムを安全に使えなくなっているというだけでなく、その間違った説明を受け た市民達は、よそのEコマースサイトなんかに行ったときにですね、 もし間に悪い人が入って偽の証明書で通信させられたときでも、 「ああ、これは広島市の人が問題ありませんと言っていたな」と、これは警告 を無視して「はい」を押してもいいんだと、誤った理解をしているわけですよ。

市: んー。

私: あなたも誤った理解をしているし。

市: それはあのー、広島市の大型ごみの受付システムのサーバについてのご説 明しかしていませんので。

私: だけどあなたは、警告が出ても「はい」を押していいと言ったわけですよね?

市: まあそうですね。それが危険なことであるということは、今、おうかがい したのですのですけども。

私: あなた自身も、よそのサイトを使うときに、この警告が出たとしたら、ど うしますか?

市: 私が今しようとしていることの重要性で判断しますね。危険性をあえてお かしてまで「はい」を押すかどうか。

私: でも、あなたはこの警告は無視して「はい」を押していいと、危険じゃな いと、さっき私にたいして説明したわけですよ。

市: ですから、大型ごみ受付システムについてはですね。 私は、あくまでも大型ごみ受付システムを使っている方にご説明しただけで、 一般的に市民の皆さんにコンピュータの扱いについて説明できる立場にないの で。

私: でもそれをしたのですよ、あなたは。 このセキュリティの警告というのは、暗号化がちゃんと正しく動いていません という警告を出しているものなんですよ。本当は。ところがあなたの説明は 問題ないというものだった。

市: そこに私の解釈の間違いはありました。ただ、私が問題ないと言ったのは、 大型ごみ受付システムだけの話であって、よそのサイトに行ってその表示が出 たときに、それは「はい」を押していいという説明は一切していないのですけ ども。

私: してないけれど、したのと同じなんですよ。なぜかというと、この警告が 出たら常に「いいえ」を押さないといけないんですよ。

市: 「いいえ」を押すか押さないかというのは、その使用者のする方が判断し なきゃいけないんじゃないですかね。でなければ、その選択の余地は必要ない んじゃないかと思うんですが。

私: そうですね、「はい」を押したけども個人情報は入れないという手はある んですよ。

市: それを一般の市民の方はご存じないと思いますよ。

私: そういう仕組みなんですよ。それを本当は市民に本来ならば教えておかな いといけないことなのに、あるいは文部科学省が小学生からこの警告の意味を 説明して、大事な情報を送信するときは、この警告が出たら「はい」を押して 書くようなことはしてはいけないということを、本当はそういう教育をしなく ちゃいけないんですけども、行われていないのが現状ですね。それはしかたが ないとしても、少なくともやっちゃいけないことは、こういう警告を出すサー ビスを公的機関が運営したうえ、しかも「はい」を押してよいという、誤った 使い方を教えてはいけないんですよ。

市: そうですね。もしあのー、お客様がおっしゃるとおりであれば、私は間違っ た案内をしていたということですので、間違っていたということになろうかと 思います。

(中略)(発注のあり方について議論)

私: たぶん今あなたが思ってらっしゃる感想としては、こんなの普通じゃない かと、誰にわかるんだ? と、こんな難しいこと普通わからない。みんな本当 にわかって発注しているのか? と疑問を持たれると思いますが。

市: ま、ホームページの扱いをしている部署であればわかって作っているのだ ろうなと。そういうところに相談して作ればよかったなと思っているとこです が。

私: 市の人もこの大型ごみのページを見に行くことはないんですかね。 この警告が出た時点でおかしいと思うはずなんですよ。

市: 警告が出ることについて私、今までさきほどご説明したような認識でいた ので、特に問題ないと思っていたんですよ。

私: 話はすごい簡単なんですよ。警告が出たら異常だってことです。 改めて考えてみればあたりまえなことでしょ?

市: それは私も警告が出ても行くときがありますし、やめるときもありますね。

私: なんでそうなっちゃったんですかね。けっきょく誰が始めたかわからない けども、警告が出ても進んでいいと言っている人があちこちにあるんですよ。 Webサイト見てもですね、こんな警告が出るけども問題ありませんという解説 を書いているところっていくつかあるんですね。そういうのを見た経験のある 人がですね、「警告は無視してもいいんだ」ということをなんとなく思うわけ ですよ。そういう誤った理解がどんどんどんどん伝染病のように広がっている わけですね。それが問題の根本なんですよ。あなたもそれにひとつ加担したわ けですよ。あなた自身もその誤解をしたのは、つまり警告が出ても 「はい」を 押して進んでもいいと思ったのは、きっとどこか誰かがですね、うちのサイト で警告が出るけどもこれは無視していいとか書いてたわけですよ。それをたぶ ん目にしたんでしょう。だから、あなた自身も警告が出てもべつに異常と思わ ない感覚がついてしまって、またそれを別の人に伝えて、また別の人がそう思 うようになっていくと。こうやってどんどん広がっているわけですよ

市: はい。

私: 元に立ち返ればものすごくシンプルな話で、単にとにかく警告が出たら異 常なんだ、ただそれを思うだけでいいんです。何も難しくないでしょ。

市: はい。

私: だから、サービスを開始するときに警告が出るようだったら、こんなじゃ 始められないと、委託先に言うだけでいいんですよ。そうすれば○○○がどう するべきか教えてくれるかもしれないし、もしそのときに相手が「警告が出て も問題ないです」とか言ったら、そこは戦うしかないですね。「それはおかし い」と。ま、そんな感じです。


高知県情報企画課曰く「とくにおかしいと思わない」

高知県電子申請・届出システム」でログイン画面 にアクセスすると、次の警告が出る。図4はFirefoxの場合、図5はInternet Explorerの場合である。

図4: 高知県電子申請・届出システムを使用しようと したときに現れる警告(Firefoxの場合)

図5: 高知県電子申請・届出システムを使用しようと したときに現れる警告(Internet Explorerの場合)

送られてくるサーバ証明書の内容を確認すると、図6のように、発行者は 「Substantive test CA」と書かれている。「実証実験認証局」という意味 だろうか。テスト証明書でやっているのか、あるいは、かつて実証実験の段階 で仮構築したCAをそのまま実運用に流用しているといったところだろうか。

図6: https://www.cdc.net-kochi.gr.jp/ が送ってくるサーバ証明書の内容

市や村ならともかく、県ともあろうものがこの杜撰さはひどい。

このことについて高知県情報企画課に電話でインタビューしてみた。


私: セキュリティの警告というのが出るのですが。

高知県: 高知県に証明書を発行するサーバを立てていまして、そこからその証 明書を発行していますので、どうしてもその表示が出てしまうということになっ ています。

私: これはどうしたらいい、というか、どう理解すればいいのでしょうか?

県: 表示はされますけども、それはセキュリティ上問題はなく、そのままOKを 押してもらって、安全に通信はできます。ただ、今回証明書を発行するサーバ を高知県用に立てたもので、そのように表示されてしまうと。

私: でも警告だと言っているんですよ。警告が出ているのに問題がないという のは、警告は意味がないということなんでしょうか?

県: 今回に限っては問題ないとは言えると思うんですけども、それはそれを出 すWindows側でそういうことがあったらそう表示するという仕様になってしまっ ているので……。

私: Windowsが悪い、マイクロソフトが悪いという意味ですか?

県: 悪いという意味ではなくて、セキュリティ上いちおう表示した方がいいの ではないかということで、マイクロソフトさんもそういうふうに表示されてい ると。

私: 危ないから警告が出ているという意味だと思うんですが。

県: はい。それでお問い合わせ頂いたと思うですけども、危ないということ…… えーとそれで証明書が送られてくるところが不正なところであればもちろん危 ないということが言えるんですけども、今回は高知県のサーバから証 明書が送られるように作ってありますので、安全であると。

私: つまり、偽のところだったら警告が出るようにしてあるわけで、警告が出 たら偽だと考えないといけないということじゃないんでしょうか?

県: 偽であるかもしれないということを考えないといけないということですね。

私: じゃあどうやって、偽を見分けたらよいのでしょうか?

県: ……。えー。それはあのー、各ホームページを利用されたときに、一般的 にいろいろなホームページがあると思うんですけども、そこでいろいろ見て行っ て表示されるときがあると思うんですけども、それはそのホームページが信頼 できるホームページであるなら、別に問題ないということが言えると思います。

私: 意味がわからないのですが。何のための警告かというということについて あなたが今おっしゃったのは、この警告は偽かもしれないということを言って いるわけですよね?

県: 偽かもしれない……、まああのー、認証局から認証を発行する機関がある のですけども、その安全でないという表示がされていると思うんですけども、 安全であるっていうのが発行している機関がベリサイン社というところから発 行されるということになっていますけども、今回は、発行する機関が高知県に なっておりますので、そこの点で表示されてしまうと。Windowsではベリサイ ン社などからの発行であれば、Windowsも認めているので表示されないと。

私: ええ。どうしてベリサインなどから買わないのですか?

県: 今回は高知県の方で立てているといったことになっております。現状では。

私: なぜですか? 問題があるのでは?

県: とくにセキュリティ上それで問題があると言われても、問題はないんです けども。

私: ああそうですか。じゃあこの警告は意味がないと理解してよいのでしょう か?

県: 今回の警告に対しては問題ないと理解していただきたいと思います。

私: 問題がないものを警告だといって、問題がありますといって表示されるの は、おかしいじゃないですか? 単純に言って。あなたは問題がないと言うけ ども、問題があるという警告が出るんですよ。それは変ではないですか? あ なたが間違ったことを言っているか、そうでないならどう理解すればいいんで しょうか?

県: えー、警告というふうに出ている点ですが、えー、そうですねー。 今回そのー、警告って出ますけども、そのー、先ほど話しましたが、 高知県の方のサーバでやっていますので表示されてしまいますと。 ですが、Windowsで作られているものはベリサイン社などでなかったら 表示されてしまうと。安全なんですけども、どうしても警告が出てしまうって いう状態なんで。

私: 安全なのに警告が出るというのは、あなたが嘘を言っているんじゃないで すか? マイクロソフトは安全じゃないっていう警告を出しているんですよ。

県: はい。

私: どっちかが嘘を言っていると思うんですけども

県: あーそのー、ま、そのー、すべてそのー、そうですね、コンピュータ側で 判断ができたらいいんですけども、どうしてもそれが出てしまうっているのは、 えーしかたがないと言ってはいけないかもしれなけども、それが出てしまうと。

私: え? そうじゃなくてですね、あなたは安全だと言うけども、マイクロソ フトは問題があるという表示を出しているんですよ。

県: 問題があるというか、まー、警告なんですけども。はい。

私: いやいや、問題があると書いてあるんですよ。「しかしこのサイトのセキュ リティ証明書には問題があります」と書いてあるんですよ。問題があるんじゃ ないですか?

県: 問題があるというとちょっと……、まあアレなんですけども、まあベリサ イン社などからのか、ものじゃないかだけの違いなんですけども。

私: だけの違いであると。じゃあ、マイクロソフトがこんなことで問題がある という表示を出すのがおかしいということですか?

県: おかしいと言ってよいのかわかりませんけども。まあ。

私: じゃあ、あなたよりもマイクロソフトの方がおかしいと。

県: 表示の方を厳しくしてあるということですね。ちょっとしたことで警告が 出ると。

私: マイクロソフトだけじゃないですよ。ネットスケープでアクセスしても、 警告が出ますね。しかももっとすごい警告が出ますよ。

県: ネットスケープは今回対応していない……

私: 対応していないとかいう話はけっこうです。そんなことは聞いてないんで すよ。ネットスケープでアクセスするとですね、「www.cdc.net-kochi.gr.jp が信頼できるサイトであると確認できません」というんですよ、考えられる原 因は以下ですとして3つ書いてあるんですね。「このサイトの証明書を認証し ている認証局が不明です」「このサイトのサーバの設定ミスにより証明書が不 完全です」そして3つ目が「あなたの個人情報を入手するために www.cdc.net-kochi.gr.jp であると偽装しているサイトに接続しようとしてい ます」と3つの可能性があると言っているのですよ。3番目の可能性があるので あれば、使ってはいけないわけですね。

県: そうですね。ただ3番目ではないですね。

私: どうしてですか? どうしてそれがあなたにわかるんですか?

県: そこのサーバは高知県として立てたサーバであるために

私: いやいや、私がブラウザでアクセスしている先がどこだかわからないと言っ ているのに、どうしてあなたにわかるんですか?

県: ……。あー。そのー、接続先が正しいのか正しくないのかという問題もあ るというお話でしょうか?

私: 何のために証明書があるかというと、接続先が本物であるか確認できるよ うにですよね?

県: はい。

私: で、うちの場合は問題ないとあなたはおっしゃるけども、私が今自分のブ ラウザでアクセスしている先でこの警告がでるわけだから、どうして私がアク セスしている先がそちらの本物サーバだとあなたが言えるんですか? と聞い てるんですよ。

県: ああなぜ正しいと言えるのかと。

私: 偽にアクセスしようとしているかもしれないとブラウザが教えてくれてい るんですよ、私に対して。どうしてそれについてあなたが、本物に間違いない とどうして言えるんですか?

県: えーそれはそうです。インターネット上からやってという話ですよね。

私: はい。

県: ブラウザ上でそのような警告が表示されてしまうと。

私: ええ、最初からそういう話なんですけど。

県: でですね、その警告なんですけども、そのー、そちらだけではなくてです ね、普通にインターネットからアクセスすると出てしまうということになって います。今、現状。

私: で?

県: 警告が出るので危険じゃないかと思われると思うんですけども、

私: みんなのところでも出ると、私のところでも出ると、だから何ですか?

県: そこの部分を表示されなくできればいいと思うんですが、

私: そんなことを聞いているんじゃないんですよ、安全じゃないと言っている のに安全だとあなたはおっしゃる。それは嘘じゃないですか? 間違っていま せんか? と言っているわけですよ。みんなだって出るんだからとあなたはおっ しゃるけども、だから何ですか?

県: 偽装されているかもしれないと思われるかもしれないですけども、……。 そのホームページを……偽装するというのも……なかなか……技術的に難しい と思うんですけども。

私: じゃあこの警告は意味がないと?

県: 意味がないとは言い切れないですけども。

私: どうしてあなたはマイクロソフトより自分が賢いと思うんですか?

県: それは言ってないですけどもー。

私: マイクロソフトやネットスケープの言っていることの方がおかしいとあな たは言っているわけですけども。

県: いえいえいそんなことは言ってないです。

私: じゃあなぜそういうことを言うのですか?

県: あのーそのーえー、証明書を発行する機関が高知県の……

私: それはわかったんですよ、だから、あなたは安全だと言っている。 ネットスケープもマイクロソフトも安全じゃないと言っているわけですよ。

県: 安全じゃないというか警告っていうことなんですけども。

私: 偽装しているサイトに接続している可能性があると言っているんですよ。 安全じゃないということですね?

県: はい。

私: 安全なんですか? 偽装されているサイトに接続している可能性があって も。

県: 可能性があるなんで。

私: 可能性あるだから安全じゃないでしょ? 実際に偽装されているかどうか は関係ないでしょ? わからないんだから、偽装されているんだかされていな いんだか。安全ではないでしょ?

県: そうですねー。そこのメッセージはそうですね。そう表示されてしまいま すね。

私: でも安全だとあなたは言ったわけですよ。安全じゃないのに安全だと市民 に説明していることについてどう思いますか?

県: 安全でないものを、そのーですね、ホームページ上で表示するかというと、 まーそのー、そのメッセージ自体の文章をとらえると、おっしゃる通りだと思 います。ただそのメッセージが出てしまいますが、えーそのー、通信上は大丈 夫であると。

私: じゃあメッセージが間違っているとあなたは言っているわけですよね? マイクロソフトやネットスケープの方が自分たちより頭おかしいと。言ってい るわけですよね?

県: そこまでは言わないですけども。

私: じゃあ何ですか。メッセージはその通りだが、安全なんですよと。メッセー ジが間違っているとあなたは言っているわけですよね。

県: メッセージのその一部ですよね。今回そこの部分でいうとそうではないん ですけども。

私: え? どういう意味ですか? 誰が間違っているんですか? 一言で言うと。

県: 誰が間違っているか間違っていないかって、そのー言うと、なかなか 間違っているという言い方をすると、間違っているっていうのはないと思いま す。

私: じゃあ、今の会話はなんなんですか。誰も間違ってないのに、矛盾してい るじゃないですか。あなたが言っていることとメッセージが。

県: あ、わかりました、でーえーと、メッセージで安全でないと表示されてし まうと、私が安全であると言っていると。どちらが嘘を言っていると。間違っ ているのかと、いう話なんですけども、今現在、そちらのパソコンからアクセ スして安全でないと表示されてしまうと、安全でないという表示はされてしま いますが、通信上は安全ではあります。

私: にゃっはっは。だから、誰が間違っているの?

県: 間違ってはいないんです。安全に通信するために、そのー、証明書をです ね、使っているんですけども、それを発行しているのが今回、高知県が発行し ていまして、

私: いやいや、そんなことは知っているって。さっき聞きました。あなた誰で すか? どういう人ですか?

県: 今現在、電子申請届出システムを担当している者ですけども。開発を。

私: これは高知県の公式な見解と理解していいのですか?

県: ちょっとお待ちください。

(高知県情報企画課の責任者が出てきて、後日正式に回答すると言われた。)

私: 今の話を聞いていらっしゃいましたか?

県: はい、横では聞いておりました。

私: かなりおかしいと思いませんか?

県: いやとくに、我々はそういう認識をしておりますので、

私: とくにおかしいと思わない?

県: はい。

私: でもあきらかにおかしいじゃないですか。メッセージは問題があると言い、 あなたがたは問題ないと言い。 どっちかが間違ったことを言っているわけですね?

県: 通常のブラウザというのはですね、セキュリティレベルをいろいろできる ことでありますので、Intenet Explorerで他のサイト行ったりよくす るのですが、とくに問題のないサイトでもですね、危険なサイトですとメッセー ジが出たり、そういう警告というのはよく出てくるケースがありますので。

私: あんまりないですね。どこで出るんですか?

県: 出てくるサイトなんかもあります。具体的にどこと言われても今ちょっと そんなあれは…

私: どんな感じのところで? 民間ですか?

県: そうですね。

私: ほとんどないと思いますよ。他の県とか? 国のサイトとかですか?

県: 他県はログインとかやったことないので承知していませんけど。

私: 普通、この警告は出ないですよ。

県: うーん……。

(以下省略)


やはり、 よそのサイトで「警告が出るが問題ないのでそのままお進みください」という 間違った解説がされているのを目にしているから、こういう勘違いが伝染して いるようだ。

さすがに民間ではこういう間違った解説をしているところは今では少ない。 それに対して、LGPKIを使っている他の都道府県の多くや、GPKIを使っている 中央官庁の多くが、独自のルート証明書を入れさせる仕組みを採っているため、 最初にこの警告が出る状態で運用している。 「そういう警告というのはよく出てくるケースがありますので」というのは、 それらのことだろう。 そういうのを見た記憶のある人が、このような勘違いをしてしまう。

病原体の発生源は政府である。この国のPKIはもう死んだに等しい。 もはや防ぎようがない。

簡単な結論

けっきょく、自治体の担当者が発注仕様書にセキュリティ要件を書く能力がな い限り、Webアプリケーションのセキュリティ欠陥の問題は解決しないわけだ が、少なくとも上の問題については簡単に解決できる。

ようするに、Webアプリケーションの発注仕様書に、

ブラウザが警告をひとつも出さないこと。

という要件を入れておくだけでよい*1。どんな素人 にでもできることだ。できない理由はあるまい。

*1 ただし、ActiveXコントロールの インストールをさせる必要がある場合には、署名済みActiveXコントロールの インストール確認ウィンドウだけは出すことを許さざるを得ない。その場合、 正しく署名させるなど別のセキュリティ要件が必要となる。

本日のリンク元 TrackBacks(100)

2005年01月14日

小学生にセキュリティ警告を無視させる埼玉県

埼玉県が「わくわくこどもページ」というWebコンテンツを提供している。アクセスカウンタが22万を超 えていることからして、県下の小学校で社会科教育の教材として使わされてい るのかもしれない。

ここに「クイズ」というコーナーがある。 そして、クイズの問題文と答えの入力の画面の「次へ」ボタンのところに、 図1のように書かれている。

図1: 埼玉県が子どもにセキュリティの警告を無視させている様子

(答えは暗号化されて送られます。使っているパソコンの 環境(かんきょう) によっては、セキュリティの警告(けいこく)メッセージが表示されること がありますが、問題ありません。

埼玉県 わくわくこどもページ

そしてこの「次へ」ボタンを押すとアクセスする先は、 ブラウザが図2のセキュリティ警告を出した後に、 住所、氏名、性別、年齢、電話番号を入力させる画面(図3)が現れる ようになっている。

図2: 埼玉県が子どもに無視させているセキュリティ警告

図3: 埼玉県が子どもに個人情報を入力させる画面

埼玉県の子ども達にインタビューしてみたいところだ。


「警告(けいこく)」ってどういう意味だと思う?

「問題ありません」ってどういうことかな?


同様に、「わくわくこどもページ」内の「知事と話そう」というコーナーにある「知事への提言」のページでも、同じ指示がなされている(図4)。

図4: 埼玉県知事が子どもにセキュリティの警告を無視させている様子

埼玉県知事にもインタビューしてみたい。


銀行からのお知らせに、「暗証番号を電話でお尋ねすることはありません」と あるのですが、さきほどかかってきた電話で「こちらは郵便局です。暗証番号 を教えてください。郵便局では問題ありません。」と言われたのですが、これ は問題ないと考えてよいのでしょうか。

……という庶民の疑問があったとき、知事さんなら個人的にどんなアドバイス をなさいますか。


埼玉県が「暗号化自体には全く問題ありません」を撤回?

埼玉県のサイトを「警告 問題ありません」で検索してみると、 たくさんヒットする。

図5: 埼玉県のサイトを「警告 問題ありません」で検索した様子

「暗号化自体には全く問題ありませんのでこのまま」といった似通った文章が、 じつに様々な部署で同じように書かれていることがわかる。

図6: 埼玉県「SSL警告画面説明」のページ(2005年1月13日までの時点)

埼玉県庁に電話して聞いてみた。対応してくださったのは、電子申請システム 担当の方。


埼玉県: 地方公共団体のLGPKIというところのサーバ証明書を使っておりまし て、じつはInternet Explorer等には、たとえば大きなところでベリサインて いう認証会社のものですとか、あらかじめインストールされているんですけども、 私どもが使っております暗号化通信のサーバ証明書はですね、まだInternet Explorerで標準でインストールされているものではないんです。

私: はい。

埼: それですので、証明書を確認できないという警告のメッセージが出てしま うんですけども。

私: はい。

埼: そのまま「はい」で進んでいただければ、埼玉県の証明書でSSL通信、 暗号化通信が始めらるんですが、LGPKIの証明書の方をですね、お客様のパソ コンの方にインストールしていただければ、その警告出ないようになるんです けども。

私: はい。「暗号化自体には全く問題ありませんのでこのまま「はい」 でお進み頂いてかまいません」と書いてあるんですけども、そうなんでしょう か?

埼: そうです。ブラウザの右下のところ、「インターネット」と地球のマーク で書かれているところがあるかと思うんですが、そこに鍵のマークが出てくる かと思うんです。

私: 「はい」を押すとですか?

埼: ええ。鍵のマークが出ているところからもう暗号化通信は始まっておりま すので、そのままもう、暗号化できて使えるんですけども。でそのー、やはり そういった警告が出るので、正式にはですね、警告でないように、とくに心配 のないように頂いたほうがよろしいかと思いますので、LGPKIの……

私: 違いは何ですかね?

埼: 違いはですね、あのー暗号化通信の仕組みというのはご存知でしょうか?

私: えーまー、だいたい。

埼: そうしましたら、私どもの方からまずサーバ証明書というのをお客様のパ ソコンの方に送らさせていただいて、そちらの方で、これはたしかに埼玉県の サーバだということがわかって、そうすると暗号化通信が始まるというのが普 通の暗号化通信の始め方なんですね。

私: はい。

埼: で、アメリカの会社でベリサインっていう会社があるんですけども、そう いう大きなところはあらかじめInternet Explorerの方に、証明ができるように証明 書があらかじめ搭載されておりまして、他のインターネットで通販とかされるとき、 そういう大手の元々インストールされている認証局のものを使うときには、何 もその警告は出ないで、使えるんですけども。

私: はい。

埼: 私どもの埼玉県ですとか地方公共団体が使っている認証局ですので、 まだ始まって間もないということで、標準でインストールされてな いんですね。皆さんのパソコンに。

私: はあ。

埼: どうしてもお客様の初めてお使いなったときに、初めての認証局なので、 警告が出てしまうという、そういうことになっております。

私: 始まったばかりだとおっしゃったんですけども、そうすると何年か待つと……

埼: ばかりと言いましても、もう何年か経っているんですけども、 まだInternet Explorerの方に、標準で装備されていないっていうんでしょう かねー。

私: はあー。「まだ」とおっしゃいましたけども、あと何年か待てば、標準搭 載されるようになるんでしょうか。

埼: これは埼玉県の方でどうというよりもですね、あのー、総務省の方で元は 作っておりまして、ですので、全国的な流れの中でこれからどうなってくのか ということになっていくかと思うんですよね。ですので、いつこうなりますと いうことはなかなかちょっとあのー、私の方からはっきりしたことは申し上げ られないんですけどもー。

私: そうすると、どうなるかわからないということですかね。

埼: そういった方向になるのではないかとは思うんですけども。だんだんこの、 地方公共団体の方でもどんどんこういったIT化というんでしょうか、進めてお りますので。

私: あのー、始まったばかりだからまだ入ってないとおっしゃったということで……

埼: そうですね始まって日も浅いということもありますし、あくまでも Internet Explorerというものは、マイクロソフトっていう会社が作っている ものですよね、民間の会社が。

私: はい。

埼: ですので、マイクロソフトの方とのやりとりという、そういうものもいろ んな調整事項が入ってくるんじゃないかなと思うんですけども。

私: はぁ〜。

埼: あくまでもマイクロソフト社が作っているInternet Explorerっていうブ ラウザの中には、アメリカの会社のベリサインっていうおっきなところ、 そういった証明書はベリサインだけじゃないんですけども、他にも何社か 入っているようですが、そういったところはあらかじめ搭載されているというような、 そういったことになります。

私: 「大きなところ」とおっしゃいましたけども、大きなところじゃないって いうことなんですかね。

埼: そうですね、あくまでもマイクロソフトといいますとアメリカの会社です し、こちら埼玉県という県の証明書になりますし。あと、携帯電話でもSSL通 信、最近使えるようになっておりますけども、やはりあのー、そういうところ もベリサインとか2、3社が入っていたり、どのくらい大きくてどうしてそこが 入っているかと言われてしまいますと、私の方からちょっと、会社同士のやり とりだと思いますので、理由はちょっとわからないんですけども。

(略)


これは興味深いことを伺えた。覚えておこう。

続いて、「全く問題ありません」と書かれていることについても伺った。


私: 「全く問題ありません」というのは納得できないんですよ。

埼: あ、そうですか、そうしましたらですね、そういったご意見頂いたという ことで、ここの表現もですね、ちょっと検討させていただきたいと思います。

私: じゃあ何かやっぱり問題はあるんですかね。

埼: あ、あのー、暗号化されるということについては問題ないんですが、 お客様の方で、この証明書について確認ができない状況であるということ であるというような説明を加えさせていただくような方向になるんじゃないか と思うんですが。私ひとりで今こうしますということはすぐ言えないんですが。 そのように検討したいと思います。

私: でもなんかそのー、暗号自体も問題あると思うんですけどもね。

埼: えーちょっとその、問題があるというのはどのようにお考えでしょうか。

私: SSL自体が正しく働いてないと思うんですけどもね。(以下、説明した 部分略)


その後このページは早速改訂されたようで、今現在アクセスしてみると、 図7のように修正されていた。

図7: 埼玉県「SSL警告画面説明」のページ(2005年1月14日深夜の時点)

「暗号化自体には全く問題ありませんので」が「暗号化は正常に行われますの で」に変更されている……。いやはや……。

続いて、「わくわくこどもページ」の件に ついてもお尋ねした。


私: わくわくこどもページは、子供向けに書かれていると思うんですけどもね、 警告が出るけども問題ないというふうな説明をしていることについて、 どう思いますか。

埼: すみません、私、ちょっとたらいまわしみたいな言い方みたいになってし まって申し訳ないんですが、私、電子申請システムの担当になっておりまして、 わくわくこどもページですとか、通常の埼玉県のホームページ部分といいます と、また別の者がやっておりますので、今この賜ったことをですね、そちらの 担当の方とあわせまして一緒にですね、修正するように連絡したいと思います ので。

(略)

私: しかしー、どういうふうに改善されるんでしょうかね。想像してみても ちょっと考えにくいんですけども。

埼: 今すぐどういうふうにしますとは言えなくてまことに申し訳ないんですけ ども、おそらくこの表示をですね、あのー、ただ一言問題ありませんとしてし まっているのを、まあ、ここ子ども向きのページですので、あまりちょっと難 しくしてしまうのも、あのー、先ほどご覧頂いた大人の方のページっていうん ですかね、あちらはまた、できるだけ証明書いれていただくようにというふう な書き方で、やらせていただいていいかと思うんですけども、ここはもうちょっ と、すぐどうするってことはちょっとあのー、ご回答できないんですが。

私: 無理じゃないですかねえ。

埼: ……。そうですか、ただあのー、問題ありませんというだけでなくて、ま ああのー、もうちょっと解説を加えることもできるのかなーというところなん ですが。

私: 問題はあるけれど、まあ問題ありません。とか書くんですかねえ?

埼: そうですねえあのー。今どうするというのは言えなくてまことに申し訳な いんですがあ。

私: つまり、子どもに説明できないようなものはですね、そもそも無理がある んじゃないですかね。

埼: ああ、なるほどー。はい、はい。

私: たとえば知事さんにですね、ちゃんと設定して使えるんでしょうか。

埼: はい?

私: 知事さんにですね、ルート証明書を入手してきて、インストールするって いうことが、正しく知事さんにできるんでしょうかね。

埼: ああそれは〜(笑)あのーちょっと私からどうというのはちょっと、ええ あのー、存じないんでもうしわけないんですが。はい。

私: そのような子どもにも知事にもできないようなことをやれと言っているわ けですよね。

埼: ああー、まあこういったページ、お子さんだけではできないかもしれない んですが、おうちの方ですとか、学校でやっているのであれば先生なんかでも こういったところを見るかもしれませんし、そういったことも含めて考えるこ ともできるかなと思うんですが。


続いて、ルート証明書のインストール方法を説明しているページ「埼玉県で使用するSSL認証局の設定手順」の内容についても伺った。


私: ルート証明書の入れ方のページですけどね、

埼: ええ、ええ。

私: ダウンロードしてくださいと、でー、それでインストールするっていうの を選んで、次へ、次へと行って、OK、次へ、完了、「はい」って押す。「正し くインポートされました」と。これでいいんですか?

埼: え、あのー、この通りやっていただければ大丈夫かと思うんですが

私: でも、偽の証明書をつかまされたかもしれませんね?

埼: ええ、ええ、あ、そうですね、その場合には、この一番下にございます 「安全な通信を行うための確認」というところで、ご覧頂きまして、証明書を 確認していただくことになるかと思います。

私: でもそれ、説明されてないですよね。

埼: いえあの、この下のとこをご覧……いただけますでしょうか。

私: ええ、「その証明書が正式なものかを確認する方法があります」と 書いてあるだけで(図8)、確認する必要がありますとは書いてないですね。

埼: ええ、ええ。はい。 それもあわせまして検討させていただきたいと思います。

私: 「正式なもの」っていうのはどういう意味ですかね。 正式じゃないもの? っていうか、本物かどうかってことですよね?

埼: そうですね。本物かどうかっていうことです。そうですね。 その表現もあわせて……

私: その確認方法のページなんですけどもね、拇印というところが、フィンガー プリントと、このページに書いてあるフィンガープリントと、同じであること を確認してくださいと、書いてあるわけですけれども、(図9)

埼: はい。

私: この見ているフィンガープリント自体が偽だったらどうするんですかね。

埼: ああ、うっ、たしかにそうですね、このページがっていうことですよねー。 ええ、はい。

私: どうするんですかね?

埼: あー、たしかにそうですね、あのー、そのあたりもですね、ちょっとあのー、 またこういった技術に詳しい者とかとですね、考えさせていただきたいと思い ます。

私: んー、だって、技術とかですね、そういうことじゃなくてですね、 ごく普通の一般の市民感覚からしてですね、単純に言って、うまい話ってない わけですよね。

埼: ええ、ええ。そうですねー。

私: 何もないところからお金が湧いてくるとかですね、永久機関とかですね、 そういうのないわけですね。

埼: ええ、ええ。

私: 安全な通信をするためにSSLを使っていて警告が出ると、警告を消すため にルート証明書を入れてくださいと言うけども、安全な通信がまだ確立されて いないのに、どうやって、安全にそれを持ってくるのかと。そういう疑問が湧 きますよね。

埼: ええ、ええ。

私: で、じゃあフィンガープリントを確認すればいいんだと。でも、今、証明 書をダウンロードすること自体が、安全な通信がまだ確立されていないんだか ら、本物だかどうだかわからないという状況の中で、同じインターネットの接 続でですね、フィンガープリントを見ても、意味ないですよね?

埼: ああー、なるほどーー。

私: 証明書と同じところからフィンガープリントが送られてくるわけですよ、 同じ通信路で。そういうのって、べつに技術とかどうこうじゃなくって、 おかしいと思いません?

埼: はあああ〜〜。 ああなるほど、じゃあお客様はこういったPKI技術全体のことについても、 なかなかあれでしょうか、いろいろなお考えをお持ちというか。

私: いやべつに。だって、誰だって、永久機関が作れるとか言っても信じない ですしね? そうじゃないですか、普通の一般の常識として。

埼: ええ、ええ、ええ。 何もないところというのがじゃあ、LGPKIの、県の。 民間も同じでしょうか?

私: ベリサインとかのなら、何もないところからではないですね。Windowsに 最初からルート認証機関に入っているわけですから。

埼: 第三者のそういった民間の会社ではないんですけどもー、このLGPKIの こちらのものですのでまー、あのー、たしかに民間の会社のように使用料を支 払ったりとか、そういったものとはまた別の証明書かとは思うんですが、あのー、

私: いや、民間とかはいいんです。民間かどうかはどうでもいいんですよ。 Windowsに最初から入ってればいいんですよ。3年後くらいまで待てば入るなら そのときはそれでいいんですけど。Windowsに入っているところから発行され ているというのは、何もないところからという状況じゃないですよね。 ちゃんと第三者がいてですね、つまり何かあるわけですよ、安全な通信には。

埼: あらかじめLGPKIの証明書も、Internet Explorer等に標準で入ってくるようにな れば、また変わってくるというような?

私: 入っていれば、第三者が証明を与えていることになりますが、入ってないっ ていうことは何もないわけですね。何もないところからなんとかしようとして、 証明書を入れろとか言われてもですね、おかしいですよね。

埼: そうですねー。

(略)


参考文献:

  1. 情報処理学会第63回全国大会特別トラック「セキュリティ教育」, ITコマースの脆弱な現実と危機回避に向けた展望, 2001年9月26日
  2. 日本経済新聞2002年3月31日朝刊社会面, 総務省の「電子申請」に欠陥 個人の情報漏れる恐れ
  3. 日本経済新聞2002年4月2日朝刊社会面, 電子証明書 真正確認の手順発表 総務省 個人情報流出を防止
  4. 情報処理学会第5回コンピュータセキュリティシンポジウム, GPKIおよびLGPKIにおけるルート証明書配布方式の脆弱性と解決策, 2002年11月1日
  5. 毎日新聞2002年11月1日朝刊社会面, 総務省の電子認証に欠陥 政府サイトになりすまし可能 きょう論文発表 個人情報盗用も
  6. 日本経済新聞2002年11月2日朝刊社会面, 総務省の電子申請「証明書配布なお欠陥」産総研のグループ

文献1(2001年9月)から引用:

  • そのルート証明書が偽物に摩り替えられる危険性

    サーバが偽物でないことを証明するのが証明書の役割であるが,このサイトでは,ルート証明書をhttp(非暗号化通信)によってダウンロードさせており,ユーザがダウンロードする過程で偽のものに摩り替えられる危険性がある.このような場合,証明書のフィンガープリントを別の手段でユーザに伝えてそれをユーザに照合させるのが通例であるが,このサイトにはそのような説明はない.

  • ルート証明書のインストールがごく平凡な行為であるかのようにユーザを誤解させる

    ブラウザにルート証明書のインストール機能があるからには,それは場合によっては有益な機能となるものであろう.しかし,ルート証明書をインストールする際には,ユーザはその発行機関を信頼すべきかどうかを慎重に見極めなくてはならない.この証券会社の「セキュリティの設定」と題するページには,自社のルート証明書のインストール手順が図解入りで説明されているが,そこには,その結果もたらされる事態の意味が全く説明されておらず,ただ淡々とボタンのクリック方法が指示されているだけである.ブラウザの操作はユーザの自己責任であるとはいえ,ルート証明書の意味を理解していないユーザが大半であると考えられる現状において,このような安易なインストールを促す行為は,ユーザの安全意識を麻痺させてしまうという点で有害だと言える.

この問題について当該証券会社に電話で尋ねてみたところ,問題点を理解していただくことができ,改善を検討するという返事をもらうことができた.そもそもなぜ通常の手順通りに証明書発行機関の署名を受けなかったのかという点について尋ねたところ,「コストの問題」という言葉があった.証明書発行機関から証明書を購入するコストは,年間十数万円程度であるが,こうしたインストール手順の説明ページを用意したり,顧客からの操作に関する電話質問に対応するだけで,既に数百万円のコストを支払っているのではないだろうか.なぜこのようなことになってしまったのか不可解であるが,システムの構築はすべてアウトソーシングしているとのことで,その請負先は,金融機関向けアウトソーシングを主な業務として設立された日本の大手情報関連企業の子会社とのことだった.

そして2004年にリリースされたWindows XPのService Pack 2では、 ルート証明書をインストールしようとすると厳しい警告を出すように、 警告メッセージが変更されている。

図10: Windows XP SP2で仕様変更されたルート証明書インストール時の警告

追記: 警告は無視してねと笑顔で市民に語りかける川崎市長

川崎市の警告無視指示は、川崎市長の肖像とともに市民に語りかけている*1。 これはなかなか絵になる。

図11: 川崎市長自ら「セキュリティの警告はそのまま 「はい」を選択し続行してください」と語りかける様子

デフォルトボタンが本当は「いいえ」なのに、「はい」の方に変えたところを 掲載しているあたりが、こざかしい。

本日のリンク元 TrackBacks(7)

2005年01月15日

民間ブランドが行政機関には無益なのならVeriSign独占化を避けるべき

11日の日記 に対して、「昨日自分で書いた『オレオレ証明書』という言い方が気に入ってきた」というトラックバック を頂いた。「オレオレ証明書」……ソレダ! 使わせて頂く。 オレオレ証明書を発行するのは、「オレオレ中の認証局」といったところか。

11日の日記 の広島市、高知県の事例と、14日の日記の 埼玉県、川崎市の事例とは分けて考える必要がある。後者は、まがりなりにもLGPKI(地方公共団体における組織認証基盤) の利用を前提としており、抗弁可能なケースであるのに対し、前者は、 オレオレ中の認証局発行のオレオレ証明書を使っていて、LGPKIを利用する必 要性さえ理解されていないケースであり、まるっきり論外であった。

広島市と高知県のような事例はさすがに珍しいと思われるが、埼玉県や川崎市 のような事例は全国に何百、何千と存在すると思われる。WebのSSLサーバ証明 書にLGPKIを使っているところでは、どうしても「セキュリティの警告」が出 てしまう。埼玉県の事例だけをとりあげたのは、子供に無視させていたことと、 「全く問題ありませんので」と特に酷い表現を使っていたためである。フィン ガープリントを正しい方法で確認させていないところは、地方公共団体ではほ とんどすべてがそうだろう。

LGPKIは国策なのだから、たとえいくらかの課題が残されていようとも正当性 があるということになる。埼玉県の担当者が口にしていたように、LGPKIが 「まだ始まって間もない」ためにルート証明書が標準搭載されていないだけで、 将来は標準搭載されるというのであれば、LGPKIという仕組み自体は間違いで はなかろう。標準搭載できていない段階で使わせるべきでないというのが正論 だが、それを言っていると普及が始まらないという抗弁が可能なのだろう。

しかし、その「工事中状態」を長く続けることは弊害が大きすぎる。「この警 告は無視してよい」、「全く問題ない」という認識が地方公務員たちの間で常 態化しつつあるようだし、それを市民に解説するコンテンツまで作られている。 高知県や広島市がLGPKIの意義まで忘れてしまったのは、これの影響だろう。

その一方で、Windowsやブラウザに標準搭載のルート認証機関から認証パスを 辿れる証明書(つまりいわゆる「ベリサインなどの証明書」)で https:// ペー ジを提供している地方公共団体もいくつか存在する。地方公共団体がそうした 証明書を使うことを国から禁じられているわけではないようだ。

日経BPの日経ガバメントテクノロジーで「使える電子申請を目指して」の連載を執筆された牟田学氏のサイト「Manaboo's Room」で、 都道府県の電子申請システムの稼働状況がリンク集として整 理されている。

このリンク集をお借りして、各都道府県がSSLにどんなサーバ証明書を使って いるかをリストアップしてみた。これを表1に示す。 「○」は警告が出ないサイト、「なし」はリストに未掲載の都道府県、「不明」 はSSLの使われているページが見つからなかったことを表す。

表1: 都道府県電子申請で使用されるSSLサーバ証明書の種類
都道府県ドメイン名とシステムへのリンク警告発行認証局
北海道 shinseido.ar.pref.hokkaido.lg.jp × LGPKI Application CA
青森県なし
岩手県 www2.pref.iwate.jp VeriSign International Server CA - Class 3
宮城県なし
秋田県なし
山形県なし
福島県なし
茨城県 www1.asp-ibaraki.jp Verisign/RSA Secure Server CA
栃木県 www.ds.pref.tochigi.lg.jp × LGPKI Application CA
群馬県なし
埼玉県 eshinsei.pref.saitama.lg.jp × LGPKI Application CA
千葉県なし
東京都 www.shinsei.metro.tokyo.jp × LGPKI Application CA
神奈川県なし
新潟県 www.shinsei.pref.niigata.jp VeriSign International Server CA - Class 3
富山県 shinsei.kyodo-toyama.jp Verisign/RSA Secure Server CA
石川県 www.shinsei.pref.ishikawa.jp × LGPKI Application CA
福井県なし
山梨県 www.ycma.jp Verisign/RSA Secure Server CA
長野県なし
岐阜県 egov.pref.gifu.lg.jp × LGPKI Application CA
静岡県なし
愛知県 www.shinsei.e-aichi.jp Verisign/RSA Secure Server CA
三重県 www.shinsei.pref.mie.jp × LGPKI Application CA
滋賀県 www5.pref.shiga.jp × LGPKI Application CA
京都府なし
大阪府 www.shinsei.pref.osaka.jp Verisign/RSA Secure Server CA
兵庫県 sinsei2.pref.hyogo.jp Verisign/RSA Secure Server CA
奈良県 www1.shinsei.pref.nara.jp Verisign/RSA Secure Server CA
和歌山県なし
鳥取県なし
島根県 shisetsu.elg-shimane.jp VeriSign International Server CA - Class 3
岡山県 www.e-entry.okix.jp × LGPKI Application CA
広島県 www.shinsei-hiroshima.jp Verisign/RSA Secure Server CA
山口県 www1.shinsei.pref.yamaguchi.lg.jp × LGPKI Application CA
徳島県 www.tok-j.info × LGPKI Application CA
香川県 kds.pref.kagawa.jp × LGPKI Application CA
愛媛県 www.pref.ehime.jp × LGPKI Application CA
高知県 www.cdc.net-kochi.gr.jp × オレオレ中の認証局 Substantive test CA
福岡県 www.shinsei.pref.fukuoka.lg.jp × LGPKI Application CA
佐賀県なし
長崎県 eap.pref.nagasaki.jp × LGPKI Application CA
熊本県なし
大分県 www.egov-oita.pref.oita.lg.jp × LGPKI Application CA
宮崎県なし
鹿児島県 www.kagoshima-e-shinsei.jp × LGPKI Application CA
沖縄県不明

集計してみると、LGPKIを使用しているところが 17箇所、VeriSignを使用して いるところが 10箇所である。オレオレの高知県を除くと、SSLの申請システム を開始しているところの 37パーセントが LGPKI以外の証明書を使用している。

ドメイン名が「lg.jp」か否かということとの関係を見てみると、「lg.jp」ド メインのサイトでLGPKI以外が使われているところは存在しないことがわかる*1

といっても「lg.jp」ドメインを使っているところは 7箇所しかない。そして、 「lg.jp」ドメインでないのにLGPKIを使っているところが 10箇所ある。

しかし、LGPKI以外を使っているところのすべてが、VeriSignを使っていると いうのは、イカガなものか。

そもそもなぜ、警告が出て安全でないのに(そして市民の安全意識さえも蝕む のに)LGPKIを推進しようとするのか、その背景に何があるかというと、推進 させようとする人達に「外国の会社を頼るわけにいかない」という意識がある ものと思われる。埼玉県の担当者も、しきりに「アメリカの会社」という言葉 を繰り返していた。

WebにおけるPKIの仕組みを理解していない非技術者の行政官の思考では、 「外国にわが国の行政機関を『認証』してもらうなど組織の仕組み上あり得な い」ということもあろう。だが、その理屈は、サーバ証明書の役割を誤って理 解している場合にのみ成り立ち得る。

というのは、まず、サーバ証明書がもたらす効果には次の3つがある。

  1. 暗号化の鍵として使われ、受動的な盗聴と直接的な改竄を防止する。
  2. 通信相手が意図したアクセス先のドメイン名と一致する本物であること を保証する。その結果として、なりすましを防止し、能動的な盗聴も防止する。
  3. そのサイトを運営する組織の実在性を証明する。

これら3つの効果のうち、3番目の実在証明は、SSLが正しく働くという意味に おいては、必須のものではない。

民間の会社では、「co.jp」などのドメイン名を使うことになるが、そのドメ イン名が、本当にその会社のものなのかということは、whoisデータベースで 調べればわかるものの、一般の人にwhoisを使うわけにもいかないので、 サーバ証明書の発行先の組織名を読んでもらうことによって、閲覧者にその 会社のドメイン名であることを信じてもらうことができる。

また、マイナーな会社であれば、本当にそんな会社が存在するのかという疑問 を持たれることもあろう。そのときに、SSLでサーバ証明書を示していれば、 VeriSignなどの一定の審査をパスした会社だということを、閲覧者に示すこと ができる。(その信頼性を実現するため、個人にはサーバ証明書を発行しない 方針をとっている認証局が多い。)これが「実在証明」である。

行政機関であれば、そうした実在証明は不要だ(実在を証明するという発想自 体が社会システム上あり得ない話)ということになるし、whoisの代替という 点では、「.lg.jp」ないし「pref.都道府県名.jp」、「city.市町村名.都道府 県名.jp」や「.go.jp」のドメイン名を使っていれば、その役割も不要という ことになる。

これが、行政官の思考を「民間認証局の証明書を使うな」という方向に傾けさ せているのだろう。

もし、サーバ証明書の役割が実在証明だけであるのなら、その行政官的発想は 間違いではないかもしれない。しかし実際には、技術的にサーバ証明書には、 1.と 2.の役割ものあるのであり、そちらが不可欠なのだから、3.が単に不必 要だという事実から「民間認証局の証明書を使うな」という結論を導くのは論 理的に誤った思考である。

また、1.や 2.の機能を得るにしても、外国のサービスに頼っていては安全保 障上の問題があるという発想もあるのだろう。この発想の詳細は次の2つに分 けられる。

  • 外国の認証局が悪意を持ってわが国の組織の偽の証明書を発行する攻撃 をしかけてくるおそれがある。
  • 外国の認証局がわが国に対するサービスを停止してしまうおそれがある。

前者については技術的に誤りである。なぜなら、それはたとえ国内の認証局を 使っていても防げないからだ。Windowsやブラウザの証明書ストアには、多数 の外国のルート認証局が登録されており、その1つがそのような悪意を持てば その攻撃にさらされるのであり、サーバ証明書をそれらの認証局に発行しても らっているかどうかは関係がない*2。――(1)

後者については、サービスを停止された時点で、国内の認証局発行の証明書に 切り替えて使えばよい。サーバ証明書は、文書に対する署名などとは違って、 いつでも新しい証明書に換えてかまわないからだ。

以上のことから、民間の認証局を使ってはならないとする正当な理由は存在し ないことになる。

そして、現時点ではLGPKIを使うと、SSLの 2.の役割が機能しない(ルート証 明書を安全に入れることを子供や知事に説明するの無理だろう)という不具合 があるのだから、民間の認証局を使ったほうがよい理由が存在することになる。

しかしながら、表1のように、LGPKI以外の認証局がすべてVeriSignになってい るというのは、必要なことではない。

VeriSignがもてはやされていて、認証局の代名詞のように言われている*3のは、VeriSignのブランド 価値が高く評価されているからだろう。 その源はおそらく、VeriSign社がRSA Data Security社から分社化された子会 社だったことに由来するのだろう。RSA Data Securityは、公開鍵暗号として 老舗のRSAアルゴリズムの特許を保有していた会社であることから、技術的な 信頼がおかれているものと思われる。 ただ、VeriSignに対する(技術的ではなく)サービス運営上の信頼性がどこか ら生じているのかは知らない。

仮に、VeriSignの証明書発行サービスが他社に比べて安全確実な信頼性の高い ものであるとすると、実在証明の目的で証明書を取得したい者の立場からすれ ば、VeriSignブランドは有難いものということになるのだろう。「セキュアシー ル」なんかを貼って、「当サイトはベリサインセキュアサイトです」などといっ た謳い文句を掲げることに、ある程度の意義はあるのかもしれない。

しかし、実在証明を必要としていない行政機関には、そのブランド価値はほと んど不要である。SSLの 1.と 2.の機能を得たいだけであれば、どこの認証局 から買ってきても同じである。その理由は前述の(1)と同じで、信頼性の低い どこかの認証局が誤って悪意ある人物に証明書を渡してしまう事態が起きたと きには、いくらサイト側が信頼できる認証局から証明書を買っていても、閲覧 者側はいずれにせよ偽の証明書に騙されることになる*4

このことを行政機関の人達は理解していないのではなかろうか。なぜなら、 ベリサインの証明書は最も高価だからだ。マイナーな民間事業者にとっては、 価値あるブランドのコストであっても、行政機関にとっては、無価値なものに 不必要なコストを拠出していることになるのではないか?

加えて、行政機関が特定の民間事業者の独占化に加担しているという問題もあ るだろう。また、国内事業者の育成という観点でも、他の認証サービス事業者 も活用するべきではないのか。

Webブラウザの証明書ストアにルート認証機関として登録されている日本の会 社は、日本認証サービス社の一社 しか存在しない。しかも、日本認証サービスのルート証明書「Japan Certification Services, Inc., SecureSign RootCA1/2/3」は、Windowsには 入っているが、NetscapeやMozillaなどには入っていないため、いまひとつ使 いものにならないと言われている*5

現時点で政府が注力すべきことは、Webで使える民間認証局の育成ではなかろ うか。LGPKIで無理させるようなことを繰り返しているよりもだ。現時点では、 先に述べた「外国の認証局がわが国に対するサービスを停止してしまうおそれ」 に対して、「国内の認証局発行の証明書に切り替えて使う」という回避策が存 在しないのであり、ましてやそのとき民間事業者にLGPKIが証明書を発行して くれるはずもないわけで、このままでは安全保障上の問題が解決されていない ことになってしまう。

LGPKI Application CAに将来はあるのか

LGPKIが「まだ始まって間もない」ためにルート証明書が標準搭載されていな いだけで、将来は標準搭載されるというのであれば、LGPKIという仕組み自体 は間違いではなかろう。

と上で書いたが、では、LGPKIのApplication CAルート証明書が、Windowsや Webブラウザに標準搭載される日は本当にやってくるのだろうか。

まず、Windowsのルート証明書として搭載してもらうには、「WebTrust for CA」 という基準に従った監査を受けて合格することが必須となっている。その上で、 その認証局が十分に社会的価値を持つならば入れてもらえるということのよう だ。このことについては、Microsoft社の以下のページに説明されている。

Netscapeについても、聞くところによると、WebTrustの基準で搭載するかどう かを決めているのだそうだ。

WebTrust for CAについては以下のページなどが詳しい。

さて、LGPKIであるが、じつはLGPKIはちょっと一風変わった構成になっている。 まず、一般に認証機関(CA)は、登録機関(RA: Registration Authority)と 発行機関(IA: Issuing Authority)とに分割できるのだが、LGPKIでは、認証 局証明書が 1個しかないのに対し、各都道府県が RAの機能を持っている。つ まり、都道府県の権限で特定の地方公共団体に証明書を発行することを許可す るようになっている。

IAがどうなっているかは知らない。証明書を物理的に作成する作業が、どこで 行われているのか知らない。もし、都道府県がそれをやっているのだとすると、 LGPKI Application CAの秘密鍵が、各都道府県で管理されていることになる。

もしそうだとすると、すべての都道府県が Web Trust for CA基準の監査にパ スしないといけないことになるが、なんだか無理っぽい予感がする。また、 そもそも、そういった同一の認証局を共有して複数の場所で別々に管理するな どという形態の運用(なんだか危なっかしい気がする)が、Web Trust for CA 基準で認められているのだろうか?

あるいは、IAがどこかの共同施設で一括して行われているのだとすると、RAが 各都道府県で別々に行われることは、Web Trust for CA的にどうなのだろうか。 許されている運営形態なのだろうか。

もしそういった理由でLGPKIが、Web Trust for CA基準をクリアできないのだ とすると、LGPKI(のWebサーバ向けの利用*6)は完全に失敗作だったということになる。 その場合は、未来がないのだから、早急に使うのを止めてしまった方がよい。

もちろん、いずれにせよ「lg.jp」ドメインは活用した方がよい。 (10月27日の日記参照。)

*1 これが重要な何かを意味するのだろうか。

*2 強いて言えば、外国を信用しないと いう立場から、日本以外のルート認証局をすべて証明書ストアから削除してブ ラウザを使いたいという人にとっては、サーバ証明書が国産であることが必要 となるであろうが、そうするとそのブラウザは外国サイトへのアクセスでSSL を使えなくなるのであり、非現実的である。これはブラウザというソフトウェ アが、非常に汎用性の高い日常品であるという性質からやむを得ないことであ る。

*3 実際、私も、説明の便宜上「ベリサインなどの」という表現をせざるを得ない でいるし、埼玉県の担当者もそう言っていた。これは避けるべきだと思ってい る。

*4 閲覧者が認証 局まで目視確認して防衛している場合には、認証局の選択が重要になるという 反論が出るだろうが、最初の画面でいくら目視確認しても、次のページでなり すましされている可能性もあるのだから、すべてのアクセスを目視確認するこ とが現実的でない以上、やはりいずれにせよ偽の証明書に騙されることは防げ ない。(ブラウザの改良で防げるか?)

*5 Windows + IE の利用を強制するこ とになり、これはまた別の独占化の問題を起こす。

*6 LGPKIは、Webサーバ向けの 証明書発行だけではない。職責証明書なども提供しているのであり、そちらは 独自の方式のPKIなのだから閉じた世界で自由にやればよいわけで、それを否 定しているわけではない。

本日のリンク元 TrackBacks(100)

2005年01月20日

日本のPKIを殺した真犯人は誰か

WebのPKIがもはや再起不能なまでにズダボロになったのには、日本特有の原因 もある。そう思える根拠が2つある。

日本サンマイクロシステムズ犯人説

10月17日の日記「電子政府つくるは素人ばかり」に書いた、つくば市の電子申請・届出 システムの事例では、署名Javaアプレットを閲覧者に実行させるにあたり、 つくば市は、「NTT BizLink,Inc」という得体の知れない認証局により発行さ れた「TSUAPP0002」という出鱈目な証明書*1を用いてアプレットに署名していた。 これについて市役所に問い合わせた際、担当者は、 「信頼できる団体と考えている。 矛盾した表示になっているが、これはマイクロソフトが……。」 とコメントしていた。

全くナンセンスなコメントなのだが、じつは、ここにこの問題の病根が垣間見 える。

たしかに、「信頼できない団体」という表現によって、図1のように表示され ると、あたかも NTT BizLinkという会社が、一般的な意味において、信頼でき ない会社であるかのように言われていると聞こえかねない。

図1: 「信頼できない団体」という表示

そういう言い方をされたと受け取った人が、「信頼できる会社のはずだ」と 思考硬直してしまうのは、無理もないことかもしれない。 その帰結として、「マイクロソフトが」間違っているに違いないという結論探 しに陥るのも、わからないでもない。下手をすれば、「マイクロソフトは外国 の会社だから、日本の会社を信頼できない団体よばわりするのだろう」といっ た、劣等意識的ナショナリズム思考を招くことさえあるかもしれない。

ちなみに、この警告を出しているのは、Sun Microsystems社製の「J2RE (Java 2 Runtime Environment)」であり、マイクロソフトは無関係である。

じつは、この「信頼できない団体」という表現は、 サンマイクロシステムズによる誤訳なのだ。

この警告の原文を確認するため、英語版Windowsで動作させたときの様子を、 図2に示す。

図2: 英語版の警告文*2

このように、原文では、

The security certificate was issued by a company that is not trusted.

となっている。「信頼されていない」と訳すべきところを、 誰かが「信頼できない」という変な訳をあててしまった*3

この種のPKIによる真正性の確認というものは、ユーザが信頼の基点として登 録している認証局からの認証パスが辿れるか否か(ユーザによって trusted なのか not trusted なのか)という、機械的な区別でしかないにもかかわら ず、「信頼できない団体」という誤訳が普及してしまったことで、主観的な評 価を指すかのような誤解を招いているのではなかろうか。

また、他の部分でも全般的に訳がいいかげんなため、意味がわかりにくくなっ ていることが、この重要な警告の理解を誤らせているように思える。たとえ ば、「issue」と「publish」が区別なく同じ「発行」として訳されているため、 認証局による証明書の発行と、証明書で署名したコンテンツのパブリッシュが 混同して読まれるおそれがあるし、「authentcity」(出所の正しさ、真正性) が「信頼性」と訳されていて、「trusted」の訳の「信頼」とごっちゃになって、 意味がボヤボヤにぼやけてしまっている*4

マイクロソフトKK犯人説

「信頼できない」と「信頼されていない」の表現にいったいどれほどの違いが あるというのか? という疑問はあるかもしれない。「信頼されていない」と いう表現なら誤解を招かないかというと、怪しいものだ。

図3は、おなじみの、Internet Explorerで https:// ページにアクセスしたと きに出ることのある警告である。ここでは「信頼する会社」という表現が使わ れている。サンマイクロシステムズの受動態表現より、このように能動態で書 かれている方が、いくぶん誤解を招きにくくなっているかもしれない。

図3: IE日本語版の警告文「信頼する会社」のくだり

ところが、これもじつは誤訳なのだ。

英語版のInternet Explorerでは、この警告は図4のように表示される。

図4: 英語版のIEでの警告文

つまり、英語版IEでは、

The security certificate was issued by a company you have not chosen to trust. View the certificate to determine whether you want to trust the certifying authority.

このセキュリティ証明書は、信頼するところとしてあなたが選択して いない会社から発行されています。あなたはこの認証機関を信頼し たいかどうか、証明書を検視して決定してください。

と書かれているのである。きわめて的確な説明が書かれているのだ。

「信頼する会社から発行されていません」では、「信頼する」の主体が誰なの かが曖昧なままだが、原文では、はっきりと「あなたが」と書かれているし、 「信頼できない」とは大違いで、単に「選択していない」だけなのだというこ ともきっちりと書かれている。

いつからこの誤訳が始まったのかを調べてみた*5ところ、 図4の警告画面は、IE 5.0 から始まっていて、この誤訳はそのときからずっと 続いていたことがわかった。

IE 4ではこの警告は図5のようになっていた。


図5: IE 4での警告文

IE 4の時点では、J2REの警告と同程度に曖昧な書き方になっていたようだ。 それが、IE 5になったときに、図4のように改善されたわけだ。 ここの警告文の意味が誤解されないよう、メッセージを改善する必要性が、 当時のMicrosoftに認識されていたことが窺える。

それなのに、IEの日本語化を担当した翻訳者のいいかげんな仕事のせいで、 肝心の「you have not chosen to」の言葉が削られてしまった。

日本のPKIの崩壊は、ここから亀裂が入り始めたのだろう。見よう見まねで、 警告文の意味をだんだんずらして取り違えられてきた。

「信頼するところとしてあなたが選択していない会社から発行されています」→
→「信頼する会社から発行されていません」→
→「信頼されていない会社によって発行されています」→
→「信頼できない会社によって発行されています」

*1 「オレオレ」と名乗ってす らいない。電話口で「TSUAPP002だけど、今すぐ振り込んで」と言っているよ うなもの。

*2 つくば市のサイトは もう改修されているので、再現実験のため別のサイトを例として用いた。 ここでは、公的 個人認証サービスオンライン窓口のサイトで提供されれている署名Java アプレットを例にしている。なお、この警告は本来の使い方では出ないように なっている。 「本来の」とは、「 公的個人認証サービス利用者クライアントソフト」 (市役所で、住民基本台帳カードに公的個人認証機能を入れてもらう手続きを したときに貰えるCD-ROMに含まれている) をインストールしている場合のことで、そのときは、CD-ROMから必要なルート 証明書がインストールされているため、この警告が出ない。ここでは、それを インストールしていない状態でアクセスしたときの様子を例として用いている。 この警告について、「 公的個人認証サービスオンライン窓口利用者マニュアル操作手順編」は、 冒頭部分で、「セキュリティ上の重要な注意点」として、 「悪意のある第三者によって提供された偽のオンライン窓口である可能性があります」 として、「いいえ」ボタンを押すよう、指導している。

*3 J2RE 1.3 では、「このセキュリティ証明書は信頼されていない企業から発行されました。」 と訳されていたが、1.4 からこのおかしな訳に変更されている。これは、 1.5 においてもおかしな訳のままになっている。

*4 また、日本語版固有の問題で はないが、証明書が信頼されていない団体から発行されている場合にも、 「Publisher authenticity verified by ○○」と、あたかも真正性が検証さ れたかのように聞こえる文が書かれているのもまずかった。この点については、 J2RE 1.5 で「Publisher authenticity can not be verified」「発行者の信 頼性を検証できません。」と表示されるよう改善されている。(「発行者」 「信頼性」という訳のいいかげんさは残ったままだが。)


J2RE 1.5 での表示

*5 この調査には、セキュ リティホールmemoメーリングリスト参加者の皆様にご協力いただきました。

本日のリンク元 TrackBacks(55)

2005年01月23日

PKIよくある勘違い(1)「オレオレ証明書でもSSLは正常に機能する」

オレオレ証明書クイズ」なるものが実施されていたようだ。

(1) 案内文の前半にある「暗号化は正常に行われます」は正しいでしょうか。

設問が悪い。案の定、正常だと回答する人が現れ、模範解答を見て 「間違っていなかったようだ」などと言っている。

たとえば、

金庫の上にその鍵が置いてあります。この金庫は正常に機能しているでしょうか?

と問うことのバカバカしさなら理解できるだろうか。あるいは、

共通鍵暗号による暗号化通信をしています。鍵は一緒に配送します*1。この暗号は正常に機能しているでしょうか?

ならどうか。暗号そのものは作動しているだろうが、それを言ったところで何 か意味があるのか? つまり、プロトコル全体として正常に機能しているかが 問われている文脈において、個々の暗号アルゴリズムが作動しているかどうか を云々すること自体が誤りだということだ。

「今の話は共通鍵暗号じゃなくて公開鍵暗号だろ」って? オーケー、では、 次の比較に対してどう答えるか。

  1. 共通鍵暗号による暗号化通信
  2. 公開鍵暗号による暗号化通信で認証なし(認証検証時の警告を無視する使用形態)
  3. 公開鍵暗号による暗号化通信で認証あり

平均的な技術者達の間の認識として、公開鍵暗号は世紀の大発明で(それはそ うなのだが)、共通鍵暗号でなしえなかったことを(何でも)解決してくれる という印象が持たれているところがあるのではないか。

たしかに上の 1.と 3.を比較すれば 3.の方が優れている。事前に鍵を秘密裏 に交換し合っておく手順を省いて、リアルで会ったことのない相手とでも即座に 安全な通信が実現できるからだ。

では、1.と 2. を比べたときはどうか。「3.ほどではないが 1.よりは 2. の 方がまし」と言えるだろうか? それは誤りである。

安全面で 2.は 1.よりも劣っていることに注意したい。1.では、共通鍵を事前 に秘密裏に入手できていることが利用時の前提である(ことが誰にも明白のも のとして認識される)のに対し、2.では、公開鍵を事前に安全に入手すること を前提にしてしない。なぜなら、警告が出るところを無視するのだからだ。

金庫の上に鍵が置かれているなら鍵を手にとって開ければよい。共通鍵暗号の 鍵が平文でいっしょに配送されている暗号化通信ならば、暗号文の傍受と同時 に鍵も傍受してその鍵で暗号文を復号すればよい。公開鍵暗号の公開鍵がいっ しょに配送されている暗号化通信では、傍受点で、流れてきた鍵を、別途用意 した自作鍵に差し替えて流してしまえば、それで暗号化されて戻ってくる暗号 文を復号できる。

こういうのを「正常に機能している」とは言わない。

それでもなお、証明書の検証を無視してSSLで暗号化通信をすることにも、 意義はあるのだという声は出てくるだろう。たしかに何もしないよりはましだ。 共通鍵暗号で鍵がいっしょに配送されてくる暗号化通信では、傍受するだけで 暗号文を復号できたのに対し、SSLのネゴシエーション時に公開鍵を差し替え るには、通信内容の改ざんが必要になるのだから、それが可能な状況というの は、単に傍受ができる状況よりは少な目かもしれない。

じつは、TLS(SSLはRFCでは「TLS」として定義された)には、そうした用途のための 通信モード(「完全な匿名モード」)も用意されている。そのことについて、RFC 2246に 次のように書かれている。

F.1.1. Authentication and key exchange

TLS supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. Whenever the server is authenticated, the channel is secure against man-in-the-middle attacks, but completely anonymous sessions are inherently vulnerable to such attacks. (略)

TLS は 3つの認証モードをサポートしている。:双方の認証、サーバー認証と認証されないクライアントおよび完全な匿名である。サーバーが認証されるときは、そのチャネルはなりすまし攻撃に対しては安全であるが、完全な匿名セッションでは性質上そのような攻撃にさらされやすい。(略)

F.1.1.1. Anonymous key exchange

Completely anonymous sessions can be established using RSA or Diffie-Hellman for key exchange. With anonymous RSA, the client encrypts a pre_master_secret with the server's uncertified public key extracted from ...(略)

鍵交換において RSA または Diffie-Hellman を使用することで、完全に匿名なセッションを確立することができる。匿名 RSA では、クライアントは ServerKeyExchange メッセージから抽出された、認証のされていないサーバーの公開鍵を使用して ...(略)

Warning: Completely anonymous connections only provide protection against passive eavesdropping. Unless an independent tamper-proof channel is used to verify that the finished messages were not replaced by an attacker, server authentication is required in environments where active man-in-the-middle attacks are a concern.

警告: 完全に匿名なコネクションでは、受動的な盗聴者に対する保護しか提供されない。改竄の行われない独立したチャネルを使用して Finished メッセージが攻撃者により置きかえられてはいないことを確認しない限り、能動的ななりすまし攻撃の懸念がある環境では、サーバー認証が必要となる。

RFC 2246, The TLS Protocol Version 1.0, F.1.1. Authentication and key exchange

The following cipher suites are used for completely anonymous Diffie-Hellman communications in which neither party is authenticated. Note that this mode is vulnerable to man-in-the-middle attacks and is therefore deprecated.

以下の暗号スイートは、どちら側のパーティーも認証されることのない、完全に匿名な Diffie-Hellman 通信に使用される。このモードは、なりすまし攻撃を受けやすいため、推奨されないことに注意。

CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };

RFC 2246, The TLS Protocol Version 1.0, A.5. The CipherSuite

7.4.2. Server certificate

The server must send a certificate whenever the agreed-upon key exchange method is not an anonymous one. This message will always immediately follow the server hello message.

サーバーは、クライアントとの間で合意された鍵交換方式が匿名方式でないときには、サーバー証明書を送信しなければならない。このメッセージは常に、 ServerHello メッセージの直後に送信される。

RFC 2246, The TLS Protocol Version 1.0, 7.4.2. Server certificate

つまり、クライアント側(たとえばWebブラウザ)が ClientHelloメッセージにおいて、TLS_DH_anon_ の値を送信して、完全匿名モードでの接続を希望したなら、そのときに限り、(man-in-the-middle攻撃の危険性を承知の上で)そのような通信が行われることになっている。それがSSL(TLS)の仕様だ。

サーバ証明書としてオレオレ証明書を使うことは、完全匿名モードでの通信をしようとするのと技術的に同じ結果をもたらすのだから、クライアントが完全匿名モードを希望していないのにサーバ側で勝手にそれを強制するのに等しく、プロトコルに違反する。

そして、完全匿名モードでの通信を希望するクライアントがあるかというと、現在主流のWebブラウザらは、そのための機能を持ち合わせていないようだ。([memo:8057], [memo:8059])

以上の理屈から、オレオレ証明書で https:// ページを提供していながら、「正常に機能しています」と表明するのは(「SSLが正常に機能している」という意味においては)虚偽の表明だ――ということになる。

一般に、Webページにおいて「暗号化されて送信されます」と書かれていたら、 読者はSSLのことを指すと思って読むのだから*2、 「私は『暗号は正常に機能している』とは書いたが『SSLは正常に機能している』 とは書いてない」とかいう言い訳は認められないだろう。

不当表示防止法で取り締まれないか

長崎産の豚肉を鹿児島産と表示して販売するくらいのことは、個人的にはべつに気にならないが、このところは、不当景品類及び不当表示防止法で厳しく取り締まられているようだし、最近では、温泉でないのに温泉だと表示していた宿の問題が槍玉にあがっていた。

それに対して、SSLの不当表示はどうか。

SSLとして機能していないのに、「暗号化は正常に行われます」などと表示して、指摘されても直さない。

そういう不当表示を、不当景品類及び不当表示防止法で一掃できないだろうか。

第2条

2 この法律で「表示」とは、顧客を誘引するための手段として、事業者が自己の供給する商品又は役務の内容又は取引条件その他これらの取引に関する事項について行なう広告その他の表示であつて、公正取引委員会が指定するものをいう。

第4条

事業者は、自己の供給する商品又は役務の取引について、次の各号に掲げる表示をしてはならない。

1.商品又は役務の品質、規格その他の内容について、一般消費者に対し、実際のものよりも著しく優良であると示し、又は事実に相違して当該事業者と競争関係にある他の事業者に係るものよりも著しく優良であると示すことにより、不当に顧客を誘引し、公正な競争を阻害するおそれがあると認められる表示

(略)

3.前2号に掲げるもののほか、商品又は役務の取引に関する事項について一般消費者に誤認されるおそれがある表示であつて、不当に顧客を誘引し、公正な競争を阻害するおそれがあると認めて公正取引委員会が指定するもの

不当景品類及び不当表示防止法

東京都の消費生活センターにこう解説されていた。

優良誤認(第4条第1号)

品質、規格、その他の内容についての不当表示

(1)商品又は役務の品質、規格その他の内容について実際のものより著しく優良であると一般消費者に誤認される表示

(2)競争事業者の供給する商品又は役務の内容よりも自己の供給するものが著しく優良であると誤認される表示

ここでいう、「品質」とは、その商品に使用されている原材料、添加物、効能、安全性をいい、「規格」とは、国、公共団体及び民間団体が定めた規格、等級などをいいます。また、「その他の内容」とは、間接的に品質または規格に影響を及ぼすもの、例えば、原産国、有効期限、製造方法などをいいます。

不当な表示は禁止されています, 東京都消費生活センター

有効期限や製造方法のようなものですら不当表示の対象になるのだから、明確な規格のあるSSL(TLS)に適合していないものを使っていながら、そうであるかのように言っているのは、十分にこの法律の対象になるのではなかろうか。

「バークシャー州長崎県」と「高知県ニューバリー市」は姉妹都市か

「サーバ管理者日誌」のこのエントリによると、長崎県電子申請システムのサーバ証明書のDNには、「S = Berkshire」と書かれているという。長崎県は黒豚が名産だっただろうか?

図1: LGPKI Application CAから「バークシャー州長崎県」の名で発行された証明書

あちこち見てまわっていたら、他にも、高知県総務部行政経営改革室が運営する「ぷらっとこうち」というサイトで、サーバ証明書に「L = Newbury」という記述があった。こちらは、そもそもがオレオレ中の認証局発行なので、もはやどうでもよい*3。しかも有効期限切れだ。

図2: オレオレ中の認証局発行の「高知県ニューバリー市」と名乗るオレオレ証明書

どうしてこういうことになっているかは、「Berkshire Newbury openssl」で検索してみると、おおかた想像がつく。

高知県の事例はそもそもが論外の外にあるのでお話にならないが、長崎県のサーバ証明書は、きちんとLGPKIのApplication CAから発行されている。こんな証明書を出してしまうようなところに、RA(登録局)ないしIA(発行局)の責任を担う資格があるのか?

少なくとも、この証明書を直ちに失効させる(revokeする)べきだろう。初の事例(?)として、LGPKIの失効システムがどのように機能するかという点でも興味深い。

*1 私も 真似して作ってみた。



  ∧_∧  カタカタ   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 (    )  ∧ ∧ < SSLには証明書が必要です…と。
 (    )  (,,°Д°)  \____________
 ̄ ̄ ̄ ̄ ̄ (つ_つ____
 ̄ ̄ ̄日∇ ̄\|  VAIO |\
        ̄   =========  \

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
| ほう、公開鍵暗号でセキュアプロトコルですか?

   ̄ ̄ ̄|/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ∧_∧       / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ( ・∀・)  ∧ ∧ < な、なんですか?あなた・・・
 (  ⊃ )  (°Д°;)  \____________
 ̄ ̄ ̄ ̄ ̄ (つ_つ____
 ̄ ̄ ̄日∇ ̄\|  VAIO |\
        ̄   =========  \

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
| 証明書は自分で作ってルート入れさせとけば無料ですませる…

   ̄ ̄ ̄|/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ∧_∧       / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ( ・∀・)  ∧ ∧ < それだとフィンガープリントの照合が必要になる…
 (     )  (;°Д°)  \____________
 ̄ ̄ ̄ ̄ ̄ (つ_つ____
 ̄ ̄ ̄日∇ ̄\|  VAIO |\
        ̄   =========  \

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
| フィンガープリントもSSLで送れば大丈夫、と。

   ̄ ̄ ̄|/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ∧_∧       / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ( ・∀・)  ∧ ∧ < フィンガープリント送るときのSSLの証明書も照合しなきゃだめでしょ!!
 (  ⊃ )  (°Д°;)  \____________
 ̄ ̄ ̄ ̄ ̄ (つ_つ____
 ̄ ̄ ̄日∇ ̄\|  VAIO |\
        ̄   =========  \
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

*2 なぜなら、Webブラウザ に他の暗号化通信の機能は無いのだから。

*3 ちなみに、直前の画面には、「個人情報の通信は暗号化されます」という表示がある。

本日のリンク元 TrackBacks(6)

2005年01月29日

「国際フィッシングショー2005」開幕

産経新聞が「フィッシング詐欺17件通報 専用110番」と報道している。産経新聞の1月29日朝刊に 掲載されたようだ。

一方、日刊スポーツにはこんな記事が。

「国際フィッシングショー2005」(略)が28日、千葉・幕張メッセで開 幕した。(略)

今年は「家族で楽しむ 地球と遊ぶ フィッシング!」をテーマに巨大釣り堀 も設置され、特別に招待されたお年寄りたちが次々に釣れてくるニジマスに大 喜びしていた。29日と30日の一般公開では中学生以下の子供を対象に無料 開放され、1回20分12人までの交代制で実施される。(略)

「フィッシングショー2005」開幕, 日刊スポーツ, 2005年1月29日

もうなにがなんだか。

そろそろ、釣具業界や愛好者団体から「フィッシング」の名称を使わないで くれと、苦情がくるころではないか。

写真: 昨年の「ネットワーク・セキュリティワークショップ in 越後湯沢」の会場で見かけた
ポスター「釣り上げるのは好奇心!!」

本日のリンク元 TrackBack(1)

最新 追記

最近のタイトル

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