最新 追記

高木浩光@自宅の日記

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

2005年02月04日

政策の専門家達は問題の本質「欠陥の排除」からなぜ目を背けるのか

という記事が出ているが、またもや問題の本質から目が背けられている。

RSA Conference Japanの実行委員長を務める安延申氏は、「経営の問題として 情報セキュリティを考える必要がある」と指摘する。

(略)安延氏は、こうした傾向を象徴するのが、1月に発覚したゴルフ場にお けるスキミング(カード偽造)事件だと述べた。この事件では、本来ならば利 用客を守るべき立場にあるゴルフ場の支配人自ら犯行グループに加担し、貴重 品ロッカーのマスターキーを渡していた。

ゴルフ場を舞台にしたカード偽造事件は「今の情報セキュリティの問題の象徴」, ITmedia, 2005年2月4日

この事件で注目すべきは次の点だろう。

  • スキミング:ゴルフ場支配人ら逮捕 窃盗団、暗証番号入手, 毎日新聞, 2005年1月20日

    これらのゴルフ場は富岡コースの系列で、貴重品ボックスはいずれも同じメー カーの製品だった。マスターキーは通常、利用者が暗証番号を忘れた 場合などに備え、鍵穴に差し込むと使用中の貴重品ボックスすべての暗証番号 が紙に印字されたり画面に表示される。(略)

    グループは、貴重品ボックスの利用者が暗証番号を記憶しやすいようにキャッ シュカードと同じ暗証番号を使うケースが多いことを悪用していた。

暗証番号忘れに対応するには、マスターキーで指定の箱を開錠できるようになっ てさえいればよい。暗証番号を印刷したり表示する必要性は全くないはずである。

「ユーザのパスワードは管理者でさえ見られないようにしておく」というのは、 システム設計の基本的な鉄則であり*1、それは現に実践されているところだ。RSA Conferenceの講 演者などにとっては間違いなく常識的なことだろう。

にもかかわらず、安延氏は次のように続ける。

いくら技術的な対策を施したとしてもセキュリティは 完結しないということが典型的に現れた事件だ」(同氏)。

この事件では、支配人自身が「悪者」であるという、ロッカーのセキュリティ 対策を施した技術者が想定もしなかった事態が起こった。(略)

ゴルフ場を舞台にしたカード偽造事件は「今の情報セキュリティの問題の象徴」, ITmedia, 2005年2月4日

ハァ? 想定しないのが悪いのであり*2、それを常識 としていかなければ社会はセキュアにはならない。このケースは、技術的な対 策などなかった事例として見るべきである。

どうしてそこから目を背けるのか。貴重品ボックスメーカーの信用を守ること の方が優先してしまうというわけではあるまい。

安延氏の主張は続く部分に見られるように、技術開発だけでは解決しないとい う話題の提供が目的であったようだ。それはその通りである。

同時に、技術開発の部分だけでなく、実装や運用面でのセキュリティも取り上 げていく方針だ。「技術だけでなく、運用の部分も重要だ。 個人認証基盤もその例だが、実装上の問題はたくさんある。技術論だけで完結 せず、それを実効あらしめるためにはどうすべきかを探っていきたい」。さら に、フォレンジックをはじめ、セキュリティと法律とのかかわりについて考察 する内容も盛り込んでいくという。

ゴルフ場を舞台にしたカード偽造事件は「今の情報セキュリティの問題の象徴」, ITmedia, 2005年2月4日

おっしゃる通りだが、「運用」のうち最も重要で解決が難しいのは、使用して いる技術に欠陥が見つかったときの対処である。

おそらくこの貴重品ボックスの暗証番号印刷機能の存在は、一部の人たちの間 では、欠陥として以前から認識されていたであろう。他社の類似製品に同様の 機能がなければ、特定メーカーの製品だけ欠陥があるということになる。その ときに、誰も声をあげられないということが問題なのだ。どうやってそこを解 決するのか。

これは技術論では済まない話なので、まさに経営、ガバナンス、政策の問題と してあなた方のような人達に解決してもらうしかないのだが、技術的前提を 間違えて欠陥を欠陥として認知できないようでは解決は絶望するしかない。

ちなみに、RSA Conference 2005 JAPANのWebサイトのメニューに「スポンサーシップ/ 出展に関するお問い合わせ」というリンクがあるが、クリックすると以下の 図のようになる。

SSLのサーバ証明書の有効期限が切れている(期限が切れてから一週間が経過 している)のに加え、情報入力画面のアドレスバーが隠されている。

図1: 証明書の期限が切れている様子
図2: アドレスバーがわざわざ隠されている様子

どうしたら、こうした事態をなくしていけるのかだ。

ところで、2000年の「IT 憲章」から5年、今度は総務省から、「ユビキタス社会憲章」というもの が出るとのことで、パブリックコメントが募集されている

第6条が「情報セキュリティ」となっているが、

第六条 情報セキュリティ

(ネットワークの安全確保)
1.あらゆるものが相互につながり、波及性の高いユビキタスネット社会では、 サイバーテロや大規模災害等に対し安全で強固なネットワークを構築・維持す ることに努めなければならない。

(不適切な利用の回避)
2.ネットワークを利用するすべての人は、コンピュータウイルスや迷惑メー ル等ネットワークの不適切な利用が社会に及ぼす影響を正しく認識するととも に、これを回避し、被害の拡大を防止するよう努めなければならない。

(セキュリティ技術の開発)
3.取引の安全性を確保するための電子認証、電子署名、暗号その他 のセキュリティ技術の開発を促進するとともに、高度なセキュリティ 知識を有していなくても容易に安全性を確保できる仕組みを整備することが必 要である。

と、残念ながらここでも欠陥の問題から目が背けられている。

欠陥の問題に取り組むということは、まず安全基準を作っていくということだ。 たとえば、「ルート証明書を手作業で入れさせてはならない」といった安全基 準が、「高度なセキュリティ知識を有していなくても容易に安全性を確保でき る仕組み」のために欠かせない。

日経デジタルコアの12月14日の月例会で、この憲章案について議論の場が設け られたとき、私は同様の意見を述べた。欠陥の問題を解決せずして、暗号だの、 署名だの、認証だのの技術開発を(いまどき)進めたところで問題は解決しま せんよ*3と。「ズバリ申し上げさせていただくなら、5年前 のレベルにとどまっているという印象です。」とも言った。奇しくも、ちょう ど5年前の2000年の「IT 憲章」を(今初めて)読んだところ、本当に似たような文章が書かれていた。

7. 情報社会における情報通信ネットワークの発達に関しては、民間部門が主導的な役割を果たす。しかし、情報社会に必要な、予測可能で透明性が高くかつ差別的でない政策及び規制の環境を整備することは、政府の役割である。

(略)

取引の安全性及び確実性を確保するための、電子認証、電子署名、 暗号及びその他の手段の更なる開発及びその効果的な機能。

G7/G8, グローバルな情報社会に関する沖縄憲章

*1 困難ならともかく、技術的に可能 なのだから。

*2 内部関係者がマスターキーを悪 用する可能性は元々常にあるのであり、開錠されて内容物を直接盗まれるリス クはどのみち避けられないだろう。しかし、その場合は客がすぐに盗難に気づ くので、同じゴルフ場で事件が多発すれば内部犯行が疑われるのが明白である から、マスターキーの流出などということが起きる危険性は小さめに抑えられ ている。この事例では、貴重品ボックスメーカーが暗証番号の印刷機能を設け たことが、そのリスクを飛躍的に高めたと見るべきである。

*3 もちろん、暗号、認証などの技術の進歩と改善が欠かせないこ とは言うまでもない。

本日のリンク元 TrackBacks(3)

2005年02月05日

PKIよくある勘違い(2)「安全に配布すればルート証明書を入れさせてよい」

オープンソースプロジェクトなので……?

1月20日の日記「日本のPKIを殺した真犯人は誰か」に対して、「SQS Development:暫定的な方法:SourceForge.jp上のHTTPSで保護されたページを通じて,証明書のMD5SUM値を確認する」というトラックバックを頂いた。訪れてみると、オープンソースプロジェクトとして開発されている、「SQS SourceEditor」と「SQS MarkReader」というJavaアプリケーションが、Java Web Startの仕組みで配布されていた*1

配布されている「SQS SourceEditor」を起動しようとすると、図1の警告画面が現れる。

図1: オレオレ証明書で署名されたJavaアプリケーション

「このコードをインストールおよび実行しないことを強くお勧めします」と警告されているのは、「この証明書の信頼性を検証できません」「コードの出所および妥当性を表明できません」という理由からだ。オレオレ証明書で署名されているため、このようになる。

そこで、トラックバック元のエントリでは、署名に使った証明書をダウンロードして、Java Web Startのルート証明書ストアに登録するよう、説明している。ここで、ダウンロードの際に偽の証明書を掴まされることのないよう、証明書が本物であるか確認するため、証明書のMD5SUMを求めて照合せよと書かれている*2。そして、その値を、sourceforge.jp の https:// ページに掲載していることから、正しく確認できるはずだとされている。

たしかに、コード署名用の証明書は、年額何十万円もする高価なものであり、しかも、そもそも個人に対して発行してくれないものである。オープンソースプロジェクト(の多く)は、開発そのもので対価を得るものとして動いているわけではないので、単にプログラムを安全に配布するという目的のためだけに、年額何十万円も負担するわけにはいかないということになる。

しかし、だからといってルート証明書を入れさせるというのは誤りである。

これは、単に、「煩雑な作業の手間を負わせるから」とか、「フィンガープリントの確実な照合が素人には無理だから」とか、そういった理由からではない。たとえユーザが確実に安全にルート証明書を受け取ることができるとしても、やってはいけないことである。

なぜなら、自分が作ったルート証明書を他人に入れさせるということは、そのルート証明書の秘密鍵の管理に重大な責任を負うことになるからだ。もし、ルート証明書の秘密鍵が流出すれば、その鍵を使って、たとえば「Microsoft Corporation」を名乗るコード証明書を作って、悪意ある署名済みソフトウェアを配布するといった悪事が可能になってしまう*3

実際、ベリサイン社などの認証サービス事業者たちは、建屋の耐震性から入退室管理まで、多額の費用をかけて秘密鍵を死守しているのであって、それと同様の責任を個人が負うことができるはずがない。もしかすると損害賠償を求められるかもしれない。その覚悟があるのか、だ*4

たしかに、「GPKIおよびLGPKIにおけるルート証明書配布方式の脆弱性と解決策」では、ルート証明書の配布方法の案として、通信先の確かさが確保された https:// ページを用いてフィンガープリントを照合する方法が挙げられているが、これは、中央政府や地方公共団体が発行する場合に限定した議論である。「政府がやってよいのなら民間や個人も同様にやってよい」ということにはならない。「本来は避けるべきことであるが、どうしてもいろいろな都合と、公益性から、そうせざるを得ない」という状況において、この方法でインストールさせることも辛うじて妥当と言えるかもしれないとしたら、GPKIとLGPKIの2枚の証明書くらいなものだという議論である。

したがって、ルート証明書を入れさせるくらいならそのまま「はい」を押させる方がましだ――ということになる。しかし、昨今の自治体のように、何でもかんでも「はい」を押せというのが常態化してしまうのはまずい。

どうすればよいのか

そもそも、Java Web Startや、Javaアプレットや、ActiveXコントロールなどに限らず、プログラムをダウンロードして実行するという行為自体がリスクを伴うものであり、本来ならば電子署名を検証したうえで起動するべきであるが、その習慣はあまり浸透していないのが現状である。

Windows XPでは、Service Pack 2において、インターネットから(Internet Explorerで)ダウンロードして保存した .exe ファイルを起動しようとしたときに、以下のような警告が現れるように改良された。

図2: Windows XP SP2における、ダウンロードした実行形式ファイルを起動しようとしたときの警告
適切に署名されている場合

署名されていればこのようになるが、署名されていなければ次のようになる。

図3: Windows XP SP2における、ダウンロードした実行形式ファイルを起動しようとしたときの警告
署名されていない場合

オープンソースプロジェクトの場合はどうすればよいのだろうか。トラックバック元では「追記」として次のように書かれていた。

(追記2)そもそも,われわれが実施しているJavaWebStartでのお試し利用サービスは,暫定的・便宜的なものです.本来的には,ソースコードで配布されたものを独自にビルドして,自分自身の証明書で署名し直して,自分のサーバ上に配置した上で,JavaWebStartでの利用をしてほしい,と思います.

日々是開発:SQS Development, 2005-01-21

これは正論だ。一般に、オープンソースプロジェクトを考えるとき、開発と、配布(ディストリビューション)とは分けて考えることができ、後者をビジネスとして成立させるモデルが注目されることがある。このとき、配布がビジネスであるなら、配布者の正規の証明書によるコード署名によって配布されるというのが順当であろうし、企業内での特定の環境下での利用に限定するのなら、プライベートCA発行の証明書による署名ということも妥当な場合がある。

開発段階のものの入手と使用は、使用者の自己責任でということになる。MD5の値を何らかの信頼できる方法で入手して、手作業で確認するというのが昔から一般的であったし、それに手間がかかるとはいえ、どのみちビルドに手間がかかるのであるから、素人向けのコード署名の話とは分けることができる。

それに対して、Java Web Startはどうか。

これは、「ダウンロードして保存してダブルクリックして起動」という従来のアプリケーション実行の手間を省いて、クリックするだけで起動するようにするための仕組みだ。クリックするだけで自動起動してしまうからこそ、コード署名の検証が必須となっているわけである。

ここで、オレオレ証明書で配布して「はい」を押させるということをやってしまうと、いくらそれが暫定的なものであると説明しても、悪しき習慣をもたらしてしまう。それを避けるには、それがディストリビューション(完成版パッケージ)ではなく、あくまで開発途上の自己責任利用の性質のものである限り、Java Web Startによる起動ボタンは提供しない――という態度をとるのが適切ではなかろうか*5

PKIよくある勘違い(3)「プライベート認証局が妥当ならオレオレ認証局も妥当だ」

企業のプライベートCA

企業の社内向けシステム(いわゆる「イントラネット」)では、「プライベートCA」と呼ばれる認証局が使われることが少なくない。たいていの場合、社員もしくは端末にクライアント証明書を配布して、クライアント認証(パスワードに頼らない安全なログイン認証)を実現するために使用する認証局であり、認証局の証明書は、ルート証明書として端末に組み込んでおく必要がある*6

これは、PKIの誤った使用形態ではない。

事実、日本ベリサインの「マネージドPKI」や、セコムトラストネットの「認証局構築・運用サービス」などに見られるように、企業のその企業名での認証局の運営を前提として、これらPKIを専門とする事業者が、ノウハウの提供、ソフトウェアの提供、もしくはシステム運用の受託という形でサービスする事例が存在する。このとき、その認証局のルート認証局がパブリックなもの(Webブラウザに事前に登録されている)とは限らない。あるPKIサービス事業者の場合、「パブリックオプション」というものがあり、年額いくらかでパブリックにすることもできるというサービス形態になっているようだ。

では、プライベート認証局とオレオレ認証局とでは、何が違うのか。

これを検討するには、そのプライベート認証局を使ったイントラネットシステムが、誰にどのような目的で使用されるのかで区別する必要がある。

たとえば、コールセンターの業務端末を考えてみる。パソコン端末のWebブラウザでイントラネットのWebサーバにアクセスして、顧客情報の管理システムなどを操作するといった形態だ。最も厳格なケースでは、この端末でよそのサイト(インターネット上のサイト)を閲覧することが職務規定で禁止されているだろう。――(A)

この場合に、プライベート認証局の秘密鍵が流出したとすると、発生し得る被害は、そのシステムでの業務に関するものに限定される。イントラネットのプライベート認証局が侵害されるような事態は、既にイントラネット自体が侵害されているのに等しいのであるから、プライベート認証局の証明書を端末にインストールする行為は、何ら追加の問題をもたらすことはない。このケースは単に、「ルート証明書のインストール作業は管理者による端末の様々な設定のうちのひとつ」ということになる。

次の想定として、使用端末を限定せずに社員にクライアント証明書を配布する場合が考えられる。つまり、生活用のパソコンに証明書を入れて、イントラネットにアクセスすることを認めているケースである。研究・開発部門などでは、こうした利用形態もあり得るだろう。――(C)

この場合、プライベート認証局の秘密鍵が流出すると、その証明書をルートとして登録している社員のパソコンには、様々な損害を被る可能性が出てくる。社員がそのパソコンで、休憩時間などにインターネットバンキングで銀行口座を操作するとか、ネットショップにアクセスするといったことが許されている場合、そこで偽サイトに騙されるとか、悪意ある署名アプレットやActiveXコントロールを実行してしまうといった被害が発生することが考えられる。このとき、会社は社員の損害に対して賠償責任を負うことになる……だろうか?

この2つの中間的なケースも考えられる。私的な使用は一切禁止するけれども、インターネットへのアクセスを認めている場合だ。たとえば、社用での、航空チケットの手配や、銀行振り込みの処理などのために使用する場合があるというものだ。――(B)

ここで秘密鍵が流出したときに起き得る損害は、あくまでも会社としての損害ということになる。したがって、このケースも、プライベート認証局の社員用端末へのインストールは(安全に証明書を配布する限りにおいては)妥当だということになる。

蛇足だが、当然ながら、社内向けとして妥当なプライベート認証局も、一般の顧客にも使わせるというのは大間違いである。ところが、社内の人たちにしてみれば、それは空気のようなものであるがゆえに、それを社外の人に強制することの異常さに気づけないことがあるようだ。*7

大学のプライベートCA

企業の場合、上の(A)と(B)のケースのように、損害も社内で閉じる場合には、プライベート認証局で運用することが全く妥当となる場合がある。では、大学ではどうだろうか。

大学の演習室の端末であれば、企業の(A)のケースに相当すると言えるだろう。――(D)

それ以外のケースはどうだろうか。

成績処理用などの目的で、教員にWebを使わせる、学内イントラネットシステムはありそうだが、その場合に、企業における(B)のケース並の、禁止規定が設けられているとは、到底考えにくい。――(E)

また、学生に、履修登録や成績確認や電子申請のために学内イントラネットを使わせることもありそうだが、その場合、証明書のインストール先は、学生の私物パソコンとなる。(入学と同時に専用端末を配布するのでない限り。)――(F)

(E)の場合は相手が教員だからまだどうにかなるかもしれないにしても、(F)の場合には、学生の私的な生活に、大学のプライベート認証局の秘密鍵流出のリスクが波及することになる。鍵が流出して学生に損害が発生した場合、大学は賠償責任を負うことになるのではなかろうか。

そう考えると、大学では、(D)のケース以外でプライベート認証局を使うのは避けるべきだということになる。

ただし、本格的な準備の下で大学が公式にプライベート認証局を運営するのは、アリだ。証明書発行ポリシー(CP)や認証局運用規定(CPS)を用意して、学生に公開して、同意の上使わせるということは妥当である。

もちろん、そのとき、証明書の安全な配布方法に注意せねばならない(入学時に手渡しとか)し、警告に「はい」を押させるということのないようにしなくてはならないし、大学のルート証明書を登録することの重みをきちんと理解させる必要がある。

しかし実態はというと、数多くの大学で、CPもCPSもないオレオレ認証局の証明書を安易に学生にインストールさせている事例が散見されるし、ブラウザの警告に対して「証明書に問題があるわけではありませんので」などと嘘の説明している大学もある。

図4: 警告を無視させる大学(ほんの一例)*8

しかもこれらの大半は、クライアント認証がしたいわけでもなく、単にサーバ証明書を無料で済ませたいためだけに行われているものがほとんどだ。

たしかに、コード署名用の証明書は高価であるし、クライアント認証のためのパブリックな認証局の構築はさらに高額であるから、必ず正規のものを購入せよとするのは無理があるという面もある。それに比べて、サーバ証明書は、最も安いところで年額4万円未満のものもある。ごちゃごちゃと手間をかけたり説明するくらいなら、買った方が安い。そのコスト計算のできないノータリンが大学には多いようだ。

大学でなすべきことは、その大学全体の事務組織の仕事として、証明書の学内への提供サービスを整備することであろう。教員ないしネットワーク委員会からの要求に応じて、事務方で一括して証明書を購入して適切に渡すといった業務フローを設けるべきである。

PKIのことを「PKI技術」などと書く人がいるが、PKIは技術ではないのだ。「I」は「インフラ」なのであり、PKIとは社会システムを指す。

PKIよくある勘違い(4)「認証業者が高すぎるなら自分達で互助会認証局を立てればいい」

1月15日の日記に対していただいたトラックバック「本家 みかままの覚書:あともうちょっと」で、次のような意見が述べられていた。

認証局は別にNPOが運営しててもいいわけで

あ、貧乏かつ公共性の高い組織にとってはね。それこそ草の根NPOとか、学校組織とかね。まぁ地元商店街とかも助かるかもしれませんが。

身近に、CACANETなんてのもあるからそれでもいいんですよ。たぶん現状のスタッフと財政基盤では難しいんじゃないかと思うんだけど。認証局として機能するのに必要なら寄付してもいいわけで。でも、控除はないのね…と別の話にループしちゃうんだけど、それは置いておこう。

オープンソースなブラウザと組んでルート証明書組込みしてもらって、地域コミュニティ限定登録業務いたしますってのも面白いかもね。あんまり乱立されるとユーザとしては混乱しそうだけど…。

本家 みかままの覚書: 2005-01-16

もはや説明は不要だと思うが、安全管理に必要なお金はどこから湧いて出るのか。

利用者も同じ部類の人々に限られるのであれば、それらの人たちで閉じた世界で、危険を承知で使うということはアリだろう。だが、そのコミュニティ以外の人たちに使ってもらうことになった途端に、そのやり方は破綻する。実際にそういう流れで起きたのが、10月27日の日記「WIDEはど素人か」に書いた事例だ。

もちろん、営利事業者なみに安全対策に費用をかけ、証明書発行ポリシーも認証局運用規定もきっちり作って、事故に備えて保険にも入って、そこまでいっぱしのことををやって、ブラウザに入れてもらえるなら、それでもよい。そのとき、証明書を無料で発行できるかは疑問だ。営利企業よりいくらか安い程度にはなるのかもしれないが。

PKIよくある勘違い(5)「なりすましの可能性はあっても盗聴はされない」

盗聴はなりすましの結果のひとつに含まれるわけだが、この勘違いがかなり根強いようで困る。その原因はズバリ言って、マイクロソフトにある。

問題の警告画面(図5)には、「ほかの人から読み取られたり変更されることはありません」と書かれているのだ。つまり、盗聴や改竄されることはないと言っている。ようするに、皆、これに釣られているのだと思われる。

図5: マイクロソフトのまぎらわしい表示

これは誤訳ではない。英語版でも「Information you exchange with this site cannot be viewed or changed by others.」と書かれている。

Trustworthy Computingを標榜するMicrosoftには、早急に改めてもらいたいものだ。

PKIよくある勘違い(6)「フィッシングサイトを作られない限り問題ない」

「偽サイトを準備するような手間をかけた攻撃に遭わない限り問題ない」という勘違いも根強くて困る。通信路上で一部のパケットを差し替えるだけで盗聴が可能になる。そういう機能のコードをルータに埋め込むとか、そういうルータを間に挟むといったこともできるだろう。

それ以前に、偽サイトなんて中継するだけで簡単に作れるのであり、むしろそっちの方が簡単という話もある。

DNSスプーフィングがかなり確実に成功するという報告もあるようだし。

PKIよくある勘違い(7)「日本認証サービスのサーバ証明書は電子署名法対応」

川崎市の「ネット窓口かわさき」の「電子申請実証実験システムについてのよくある質問」には、Q008として、次のことが書かれていた。

図6: 「ネット窓口かわさき」の「よくある質問」

「電子証明法に対応した、サーバ証明書を発行する認証局である『日本認証サービス株式会社』によるサーバ証明」と書かれていたが、たしかに日本認証サービス株式会社は、電子署名法に対応した認証サービスも提供しているが、それは、「AccreditedSignパブリック サービス」のことだろう。

そもそも、SSL通信におけるサーバ証明書の署名が、電子署名法が言うところの電子署名に該当し得るのかさえ疑わしい。

このことについて、川崎市に電話で指摘したところ、即座に訂正された。

どうもこう、高い金払ってSSLを使っているという意識があるのか、「SSLを使っています」ということを説明する文章に、誇大な表現を使いたがる傾向がある。今回の場合、「電子署名法」ではなく「電子証明法」という存在しない法律名が書かれていたので、嘘にならずに済んだ(?)が、この種の不当表示は今後も後を絶たないと予想される。

*1 Java Web StartはJavaアプレットと同様の仕組みで、Javaアプレットでは、Webブラウザのページ内に埋め込まれた形で作動するものだったのに対し、Java Web Startでは、独立したアプリケーションプログラムとして起動するようになっている。アプレットと同様に、署名されていないプログラムでは、ローカルファイルへのアクセスが禁止されているなど、一定のセキュリティ上の制限の下でプログラムは作動するが、署名されたプログラムでは、どんなことでも実行できるようになっている。

*2 このような独自のハッシュ値計算方法をとるよりも、証明書の標準的な方法である、フィンガープリント表示機能を使う方がよい。

*3 もちろん、コード署名証明書を認証サービス事業者から購入する場合であっても、購入した証明書の秘密鍵の管理は必要となるわけだが、それを流出させたときの損害は、自分を名乗る偽のプログラムが現れるというリスクに留まるという点で、責任の大きさが異なる。

*4 そもそも証明書発行ポリシー(CP)も認証局運用規定(CPS)も存在しないルート証明書を、言われるがままにインストールするユーザが悪いとも言えるので、賠償責任はないかもしれないが。

*5 つまり、単なるスタンドアローンなJavaアプリケーションとして配布せよということ。あるいは、.jnlp による起動の利便性を示したいのであれば、Sandbox内で動く機能限定版を提供するといったことも考えられる。

*6 少なくともIEの場合は。調査中。

*7 かつて松下電器産業が、「Matsushita Group Root」という松下グループのルートプライベート認証局とおぼしき証明書を消費者に入れさせていたという事例がある。Prepare to be assimilated. Resistance is futile. ……といったところか。参照: [memo:5050], [memo:5077], http://web.archive.org/web/20021216065207/http://www.panasonic.co.jp/customer/video/usr/link_motiondv.html

*8 「こういう環境で教育された学生が入社してくると社内で同じ過ちを再生産される」ということで、そういう大学は就職が不利になってくるおそれさえあるかもしれない。

本日のリンク元 TrackBacks(100)

2005年02月06日

ICカードの非接触スキミングですって? ええかげんなことぬかすな

今日の讀賣テレビの「ウェークアップ!」は、「狙われる銀行預金 偽造カード新手口」という特集を放送していた。

みていたところ、「日本をはじめ世界各国で捜査機関の顧問を務める人物」として紹介される*1松村テクノロジー社長の松村喜秀氏が登場し、銀行のICカードの「非接触スキミング」を実演していた。

おいおいおいおい、ちょっとまて、そんなええかげんな、根拠なしに危機感煽るなよ。

最近、金融機関では、セキュリティー対策として、偽造が極めて困難とされるICチップを導入し始めているが、これにも大きな落とし穴が!

(松村エンジニアリング社長)
「これのデータはどうやって読めるかやってみましょう。 近づけるだけで、非常に早い時間で、簡単に読めます」

そこには、一瞬でカードのデータが現れた。これが、非接触型スキミング。

カードに触れずにデータを盗むことができるのだ。なんと、コートの上からでも反応した。さらにかばんの中でも!

今のところ被害の報告は無いようだが、偽造されるのも時間の問題との指摘もある。

狙われる銀行預金 偽造カード新手口, 讀賣テレビ, ウェークアップ!, 2005年2月6日

あのねー、ICカードと磁気ストライプカードは同じじゃないんだよ。

テレビの映像では、財布に入れたカードをズボンのポケットに入れて、コートの上から RFIDカードリーダで読取ったデータを、そのままパソコン画面上に16進数で表示させていただけだ。データにはモザイクがかかっているので、内容は不明。

そんなもの、そりゃ読取れば何かしらのデータは出る。ICカードが、内蔵の暗号演算器によって、きちんとしたセキュアプロトコルに基づいて通信しているなら、読み取れる生のデータは毎回異なる値となるはずだ。

もちろん、固定の値として読める部分もある。たとえばEdyカードで言えば、Edyナンバーという番号がカードに付されているが、その値は誰でも読み出せてしまうし、Suicaで、入退場履歴が誰でも読み出せてしまうことは、私も書いてきた。 それは、たまたまそのように設計した(プライバシーを軽視して利便性を選択した)ためであって、秘匿できないからというわけではない。生体認証用のパターンデータをICカードに入れる場合には、当然ながら第三者には復号できないようにするだろう*2。読めているデータに何かしら問題があるのなら(たとえば口座番号とか)、何のデータなのかを示して批判するべきだ。

それに、キャッシュカードの文脈では、なりすまし(や複製)の脅威が語られているわけだが、ICカードでは磁気ストライプと違って、読み出せるからといって、なりすませることにはならない。

たとえばEdyでは、EdyカードからEdyナンバーを誰でも読み取れるが、Edyのリーダ・ライタに対して、なりすましてそれを与えることはできない。暗号を破らない限り。そのように作られているはずだ。

暗号くらい破られるとか言い出しそうだが、磁気ストライプの固定データの暗号と同じように解読できるようなものではない。

FeliCaの暗号システムが安全だとは言わないが(知らないので)、住基カードのように、公開鍵暗号演算機能を搭載したICカードであれば、この番組で言われているような方法での複製はできない*3

RFIDタグの遠隔読み出しや、なりすましの問題を訴えてきた私が言うのもなんだが、というか、そういう私だからこそ言わねばならないのだが、本当に安全でないものと、本当は安全なものとを、いっしょくたにして危機感を煽るのはやめていただきたい。

そういうことを続けていると、それこそ、「消費者に理解されない○○」だとか、「消費者が不安がるのは技術を知らないから」などと、問題を隠したい連中の都合のいいネタにされるのがオチだ。

こういうことを避けるためにも、ICカードにせよ、ICタグにせよ、暗号機能を搭載しているのか、どのようなセキュアプロトコルになっているのか、どんな情報が誰でも読み出せる設計になっているのかを、製造者やサービス事業者に、公開させるよう義務付けることが必要だろう。

ちなみにこの放送では、ICカードの話の直前の部分で、磁気ストライプのキャッシュカードで、暗証番号を知っていなくても盗んだカードを使えるという話が出ていた。

(松村エンジニアリング社長)
「ここに他人のカードがあります」

ここで、暗証番号が解っている別のカードを用意する。

(松村エンジニアリング社長)
「これを入れます。暗証番号だけを残しておいて、他のデータを移してしまえば、 本来持っている他人のカードの暗証番号を使われるので暗証番号は関係なく作ることが可能です」

高度な技術を使って、盗んだキャッシュカードのデータのうち、 本人の情報だけを、別のキャッシュカードに移し変えると、 なんと、別のカードの暗証番号のままで、お金を引き出すことができるというのだ。

(記者)
「暗証番号いらないんですか?」

(松村エンジニアリング社長)
「いらないんです。 犯罪グループが、知っている暗証番号をそのまま残して他の部分を入れ替える犯罪も考えられます」

狙われる銀行預金 偽造カード新手口, 讀賣テレビ, ウェークアップ!, 2005年2月6日

エーーーー?? ホントかよ。本当にそうなら、その銀行のシステムはそうとうにタコだということになる。*4

非接触ICカードの話であんなええかげんなことをする人がこれを言ったところで、眉唾に聞こえてしまうのだが……。

ちなみに放送では、松村氏は最初に「可能性はあります」と言って始めていた。

もっとも、この時期に、なにがなんでも銀行のカードは危険だということにしないといけないというのはわかる。

今必要なことは、預金者保護のための制度作りだろう。だが、おそらく、これまで銀行業界は、それを避けるために、ICカードや生体認証が実用になる日がくるまでじっと耐え忍んでいたのではないか。ICカード方式をうまく普及させることができれば、銀行側に責任のあるとされかねない方法での不正引き出しは激減させることができる。あとは、カードを物理的に盗まれて、かつ暗証番号の管理が不適切だった預金者だけが被害に遭うことになる。そのとき、50ドルルールのような制度ができていると、銀行が損をすることになるので、制度を押し付けられる前に早く、「キャッシュカードは安全です」という既成事実を作ってしまいたいところではないか。

それが見え透いているので、なにがなんでもキャッシュカードは危ないということにしなければならない、という動きがあるのは、まあ、わからなくもない。(加担はしたくないが。)

問題にするなら 4桁数字暗証の方だろう。これがそもそも安全でないのだということを認めさせて、預金者保護の制度を作るべきである。

*1 偽ドル紙幣鑑定機の開発で著名な方らしい。

*2 ところがどっこいそんな対策さえされてない……というほど設計がタコなら、それはそれで欠陥だという別の問題であり、直せばよいことだから、証拠を掴んで示してもらいたい。

*3 カードを物理的に手にとられたときに起きることについては知らないが。

*4 スキミングしなくても偽造カードを作れるが暗証番号は別途必要、という話ならまだ可能性として理解できるが。

本日のリンク元 TrackBacks(9)

2005年02月11日

フィッシング報道に見るテレビによる啓発の限界

今週は、フィッシング詐欺の話題を扱うテレビ番組が立て続けにあった。 日曜はTBSの報道特集、 月曜はNHKのクローズアップ現代と特集で扱われ、 そして木曜にはテレビ朝日のやじうまプラスでちょっとだけ扱われた。 やじうまプラスでは、直前に勤務先に取材申し込みがあり、 私もコメントした。

その中で限界を感じたのは、テレビで自衛策を伝えるのはどうにも無理っぽい ということだ。

5年前にソフトウェアのセキュリティ欠陥の問題に首を突っ込んだのは、当時 の私の認識として、あまりにも世間で脆弱性の存在とパッチの必要性が認識さ れておらず、その認識を変えなければどうともならないという思いがあったか らだった*1。その後、インターネットの利用が一般市民へさらに広 がりつつ、大規模なワーム被害が出るなどして、マスメディアがインターネッ トのセキュリティ問題を扱うことがたびたびあるようになってきた。

その中で、取材を申し込まれたりアドバイスを求められたりすることがあった。 そのときいつも意見として主張していたのは、何が根本的な原因で、誰がどう 対処するべきかということこそを、視聴者に伝えるべきだということだった。

しかしそれはなかなか達成されなかった。新聞でもテレビでも、取材する記者 やディレクターさんは、説明すれば問題点をきちんと把握してくださるけれど も、それがデスクに上げられたときに、却下されるというパターンが多いらし い。

「難しい」話はできないというのだ。専門用語がひとつでもあると駄目という のは、端から見ていてもわかることで、「ネット閲覧ソフト」などといった言 い換えがいまだになされている。

今回も当初、「アドレスバー」という言葉を出したときに難しい顔をされた。 アドレスバーと言っても視聴者はわからないだろうから……というのだ。

いろいろ経験して悟ったのは、ようするにテレビというのは、視聴者が理解可 能な話(視聴者達がその話題を理解するのにふさわしい知識の準備ができてい る話)しか扱えないということらしい。まるっきり誰にでもわかりきっている 話なら、それはニュースでないのだから放送する意味がないわけだが、ちょっ とだけ新しいことを入れて伝えるのだと。知らない話を延々とやると視聴者が ヒクということがあるだろう。それは視聴率として現れる。

これはしかたのないことなのだろう。視聴者には、そもそもインターネットに 無縁な人がある程度の割合で存在する。異常プリオンの話とか、有害物質の話 とか、○○が健康にいいとかの話であれば、人々の生活に関わるのだから視聴 者の全員が対象となるのと違ってだ。だが、5年前ならいざしらず、今はどう か。うちの両親(極度の機械音痴)でさえ常時接続でWindowsでいろいろやっ ているらしいし、もうそろそろインターネットと無縁な人の割合は、半分は割っ ているはずではないだろうか。

「アドレスバー」は本当にテレビで使えない言葉なのか? フィッシング詐欺 の話を出すのに、アドレスバーを避けて通ってどうるすのだ? 「アドレスバー」 と言ってヒクような視聴者は、まさにアドレスバーを普段見ておらずフィッシ ング詐欺の被害に遭いかねない人たちなのだから、その人たちに注意を促すに あたって「アドレスバー」という言葉を使わないというのでは、いったいどう しろというのか。

TBSの報道特集*2では、自衛策の紹介は 皆無に等しかった。キャスターの最後の締めくくりの言葉で、「個人情報を求 めているサイトあるいはメールに対しては、送信元に電話で再度確認するなど、 疑ってかかるといいますか、警戒心を持つということしか自衛策はないのかも しれません」と言っただけだった。後半では、スパイウェアによる手口が最近 は出始めている話を紹介するにあたって、トロイの木馬の実演をして見せてい たが、例によって「ハッカーならなんでもできてしまう」的な扱いになってお り、単に消費者たちに恐怖心を植えつけるだけに終わっている。本来ならば、 トロイに感染しないためには、メールの添付ファイルを開かないようにすると か、パッチをあてるようにするとか、そういうことを紹介するべきところだが、 それは全くなしだ。 これでは、視聴者は「フィッシング詐欺 → どうしようもない → 怖い怖い」 という感想で終わってしまう。

クローズアップ現代はどうだったかというと、こちらの番組は、外国で本当に 深刻な事態になっているのだという実態イメージを伝えることに力点が置かれ ていた。カード番号を盗られるとどうなるかという話、SSN(社会保障番号) を盗られてローンを組まれた話などが紹介されていた。個人情報が国際的に 売買されている実態も紹介され、騙されることがどう深刻なのかを伝えていた。 また、偽サイトが侵入された個人のパソコンに作られている話や、日本の法律 では情報を盗み取った段階では取り締まれない話、ウイルスと違って機械的に 防ぐのが難しいという話が伝えられていた。しかし、消費者の自衛手段につい ての紹介はイマイチだった。挙げられていた自衛策は、

  • 個人情報を求めるメールは疑う
  • 疑問を感じたら問い合わせる
  • インターネット用のクレジットカード、預金口座を別に持ち、預金額を制限しておく

というもので、これは実質的に、自衛手段は存在しないと言っているようなも のだ。

クローズアップ現代では、アドレスバーに偽URLの枠なしウィンドウを被せる手口を紹介して、 メモ帳のウィンドウを上に載せることで、「ズラ」が浮き上がって見えるという、 動画像ならではの直感的でなかなかうまい説明をしていたが、 ここで言うべきことは、Windows XP に Service Pack 2を入れれば、この手口 は使えなくなるということだ。

たしかに完全な策はない。いくらパッチを適用していても、未知の脆弱性を突 いた攻撃が突然やってくる可能性は否定できないのだから、「こうすれば安全」 という説明はできない。だからといって、何も説明しないというのはいかがな ものか。

英語圏では、フィッシングの手口は徐々に進化してきたことから、おそらく、 人々も徐々に自衛策の基本を理解してきているのではないかと予想する。 つまり、最初の簡単な手口(http://202.xxx.xxx.xxx/ といったアドレス)が 横行した段階で、「アドレスバーをまず確認する」というのが常識となっただ ろうし、アドレスバーを隠したポップアップウィンドウに入力させる手口が横 行し始めると、「アドレスバーのないウィンドウにはパスワードを入れない」 という常識が浸透していっただろう。英語圏ではそうやって現在があるわけだ が、日本では、そうした段階をすっ飛ばしていきなり高度な手口で、フィッシ ング詐欺が流行るおそれがある。基本的な自衛方法を身につけることを放棄し て、ただ大騒ぎするということになりかねない。

大事なことは、本来あるべき姿と現実的な対応とを分けて示すことだ。そうし ないと、何が誰の責任なのかがわからなくなってしまう。つまり、アドレスバー を確認しないのは、ユーザの責任であるし、アドレスバーが偽装されてしまう のは、ブラウザのメーカーに責任があるか、もしくは本物サイトに責任がある (クロスサイトスクリプティング脆弱性)というように区別する必要がある。 アドレスバー偽装に使われるようなブラウザの仕組みや、気をつけていてもト ロイに感染してしまうような原因箇所は、セキュリティ脆弱性として認識され て修正されてきているのだから、そのことを伝えて、あとは消費者にパッチを あてるよう呼びかける。それでもなお、騙されてしまうことが起き得るので…… と、話を分けるべきだろう。

ちなみに、木曜日のやじうまプラスでは、3分50秒という短い時間の中で、き ちんと、アドレスバーの話と、鍵マークの話も扱ってくださった。よかった*3

しかし、アドレスバー偽装の話はできていないし、トロイを使った hosts 書き換えなどの話もできていない。

こんなので対策になると言ってしまうと、ご批判もあるだろう。錠前アイコン の存在を確認せよという話は、現時点では比較的有効だと思うので、チェック ポイントとして出してもらったが、本当は、サーバ証明書の中身まで見ないと いけない(SSLを提供しているどこかのレンタルサーバが偽サイトに使われる 可能性もある)し、本物サイトにクロスサイトスクリプティング脆弱性がある 場合には、サーバ証明書を確認しても見破れないという話もしておく必要があっ た。それは時間的に無理だった。

もっとも、まだ大規模な被害が確認されていない現段階で、これだけ注意を呼 びかける報道がなされているのは、よいことだ。今後、残念なことに日本でも 欧米並みに被害が深刻になるような事態がおとずれると、自衛策の一つ一つを 紹介する番組が出てくるのかもしれない……が、どうだろうか*4

フィッシングによるカード不正利用の被害はUFJカードだけではあるまい

月曜の昼のNHKニュースで、フィッシング詐欺が原因とみられるクレジットカー ド不正使用被害が、UFJカードの7人の会員について、昨年の10月〜11月に出て いたことが確認されたと報道されていた。

  • このような手口にご注意ください, 一連の報道について, UFJカード

    2005年2月7日、NHKのニュース報道で、当社のお客さまが「フィッシング詐欺の被害を受けた」と報じられました。本件につきまして、以下のとおりご説明いたします。

    ・昨年9月から10月にかけて、ルーマニアなどにおきまして当社のクレジット カードを偽造したカードの使用が発覚いたしました。調査しましたところ、33 名のお客さまのクレジットカードが偽造され、そのうち8名のクレジットカー ドにより現金を借り入れる「キャッシング」が不正に利用されていることが判 明いたしました。被害総額は約150万円です。

    (略)

ここで注意すべきことは、UFJカードの偽サイトが作られたという話ではない という点だ。VISAジャパンとか、ヤフーとか、その他のサイトを装ったフィッ シング詐欺で、クレジットカードの情報を入力してしまった人たちの被害なの だろう。

ということは当然ながら、被害者はUFJカードの会員に限られるはずもないわ けで、他のクレジットカード会社にも同様に被害が出ているはずだろう。

10月の話が今ごろになって表に出てきたわけだが、他のカード会社の被害状況 とかはきちんと把握されているのだろうか。警察庁や経済産業省のフィッシン グ対策連絡会のようなところではきちんと(秘密裏に?)情報が共有されてい るのだろうか。

*1 当時起きた省庁ホームページ改竄事件で、ファイアウォール を入れていなかったからだとか、パスワードがどうのとか、そういう話に終始 していて、脆弱性にパッチをあてるという話が表に出てこなかった。ソフトウェ アは入れたら入れっぱなし。メンテナンスコスト(脆弱性修正としての)がか かるということが認識されていなかった。この認識はソフトウェアベンダ側も 似たようなもので、パッチを出していても重要ユーザにさえろくに伝えていな い(銀行がユーザの事例など)事例があったし、パソコンメーカーがWindows の脆弱性の存在について、知らぬ存ぜぬで通したという状況があった。エンド ユーザが欠陥の存在を認識しない限り、そうした状況は変わず、事故や事件が 置きつつも原因不明のまま被害者が泣き寝入りするという未来が来てしまうと、 そう感じていた。

*2 私は何も協力していないが。

*3 ありがとうございます。

*4 多チャ ンネル化がもっと進んで、専門チャンネルとかができたらいいのに。

本日のリンク元 TrackBacks(3)

2005年02月12日

ファーミング詐欺と区別がつかない自治体電子申請サイト

日経IT Proに勝村氏の「記者の眼」が出ていた。

pharming(栽培、耕作)というのは、なかなかよいネーミングではないかと思っ た。勝村氏は、ベンダーのセールストークということを気にしているようだけ ども(私もフィッシング対策でアドホックな対策技術のビジネス展開には疑問 を感じるが)、フィッシングでないものまでもフィッシングと呼ぶよりはよい のではないか*1

勝村氏は、おそらくメディア記者の中で最もセキュリティ話に強い記者さんで はないかと思う。かなりマニアックな話題が出てくることもあり、技術的に深 く突っ込んで解説されていることが多いし、間違ったことが書かれることが少 ないし、ベンダーの宣伝に踊らされることもない。が、足りないところもある ので、突っ込んでおこう。

今回の話題は、

具体的には,(1)ウイルス(ワーム)などを使って,クライアントのhostsファ イルを書き換える,(2)DNSサーバーに虚偽の情報をキャッシュさせる(これ は「DNSポイズニング」と呼ばれる)――など。(略)

ユーザーとしては,「メール中のURLをクリックせずに,自分でアドレス・バーにURLを入力する」といった,フィッシング対策の一つを実施しているにもかかわらず,偽サイトへ誘導されてしまうのだ。ブラウザのアドレス・バーには,正規のURLが表示されているので,偽サイトだと見抜くのが難しい。

pharming(ファーミング)――オンライン詐欺は「釣り」から「農業」へ?, 勝村幸博, 日経IT Pro 記者の眼

という話であるが、そのケースであれば、ブラウザの錠前アイコンを確認すれ ばよい。そもそも、フィッシング詐欺に遭って困るような情報を入力するとき は、通信が暗号化されていることを確認するのが基本だ*2

hostsの書き換えで誘導される偽サイトは、ドメイン名は本物であるのだから、 本物ドメイン名でのSSLのサーバ証明書を、詐欺師達は持つことができない (認証局がミスをしない限り)ので、もし https:// ページになっているなら、 必ずブラウザが警告を出す。

偽サイトがよそのサイト用の正規のサーバ証明書を使っているなら、IEでは 「セキュリティ証明書の名前が無効であるか、またはサイト名と一致しません」 と出るし、偽サイトがサイト名を一致させようとすれば、偽の認証局から発行 するしかないので、「このセキュリティ証明書は、信頼する会社から発行され ていません」と出る。Firefoxならば、「あなたの個人情報を入手するために www.example.co.jp であると偽装しているサイトに接続しようとしています」 とズバリそのものの警告が出る。

なぜこの自衛策のことをもっと書かないのだろうか。「ファーミング」の話は ここ最近あちこちで報道されているが、錠前アイコンを見よという話はどこで も出てなかったような気がする*3

いちおう、勝村氏の記事でも、最後の部分で、証明書をチェックという話は出 てきている。しかし、

また,DNSサーバーに虚偽の情報をキャッシュされた場合などに備えて,個人情報などを入力するページでは,SSLが使われていることを確認するとともに,ディジタル証明書の内容をチェックしたい。DNSポイズニング攻撃などを受けないように,DNSサーバーの管理者がきちんと対策を施すことも重要だ。

pharming(ファーミング)――オンライン詐欺は「釣り」から「農業」へ?, 勝村幸博, 日経IT Pro 記者の眼

この書きぶりだと、SSLが使われていることの確認が、DNSスプーフィング攻撃 にのみに有効な対策のように読めてしまうが、hosts書き換えにも有効なのだ。

それに、DNSポイズニング攻撃は、DNSサーバの管理でどうにかなるかもしれな いが、それ以外のDNSスプーフィングもあり得て、そちらは脆弱性が原因では なく、盗聴されるのと同じようにあり得る話なので、管理で防ぐ話ではないの ではないか。そうした攻撃があり得るため、(フィッシング、ファーミング以前に) SSLの確認が必要になっているわけで、微妙に誤解があるように読める。

偽サイトで警告が現れるという話をぜひ書いてもらいたいものだ。どんな場合 にもこの警告が出たら「いいえ」を押すという習慣を徹底する。仮に「はい」 を押しても、その先の画面は偽かもしれないと意識して、情報は入れない。

そして、日本の自治体はこの警告を出しまくっていると。

そのルート証明書は本物?それともファーミング用?

上では、ファーミング詐欺サイトでないか見分けるために、錠前アイコンが、 ブラウザの警告なしに現れているかを確認せよという話を書いたが、ファーミ ング詐欺師達がユーザに踏ませるトロイの木馬が、hostsを書き換えるのと同 時に、偽のルート証明書までインストールしてしまっていたら、これは有効な 自衛策とならない。

ということは、ファーミング詐欺が流行りつつあるという今、求められている ことは、Windowsの「信頼されたルート認証機関」に入っている各証明書が、 本物かどうかを確認する手段を確立することであるはずだ。

偽認証局の証明書は誰にでも作れ、認証局の名前は自由につけられるので、見分ける手段は、フィンガープリントしかない。

現状では、一個一個フィンガープリントを目視で照合するしかないのかもしれ ないが、そのために、正規のフィンガープリントの一覧表というものが必要だ が、どこかにあるのだろうか。

近いうちに、自動でチェックするツールが必要になるだろう。*4

しかし、LGPKI Application CA のように、自力で追加インストールしたルー ト認証局がいっぱいあると、そうした自動チェックツールに頼れなくなる。 どうすればよいのか?

JPRSの偽サイト登場??

http://xn--wgv71a119e.jp/access/phishing.html

このサイトは本物だろうか? URLを見ても判別できない。INTERNET Watchの 記事からリンクされていたのだが。

どうやら、これの記述に従ったものらしい。

日本語JPドメイン名のサイトへのリンクの記述方法

日本語JPドメイン名でアクセスできるサイトへのリンク方法はとても簡単です。 「日本語.jp」にリンクしたい場合
<a href="http://日本語.jp/">日本語.jp</a>
もしくは
<a href="http://XN--WGV71A119E.jp/>日本語.jp</a>
という形でhtmlファイルに記述します。

http://xn--wgv71a119e.jp/support/index.html#link, 登録・運用・サポート - 日本語.jp

後者でリンクしてしまうと、偽サイトかどうか確認できない。

下記ページで当該ドメイン名がPunycodeでどのように表現されるか確認することができます。

http://xn--wgv71a119e.jp/support/index.html#link, 登録・運用・サポート - 日本語.jp

とあるが、むしろ逆変換の方が重要なのではないか?

ブラウザが逆変換してアドレスバーに表示するべきだとも思うが、 どうだろうか。

このままだと、Punycodeでリンクしまくる人たちが大量発生して(自治体とか)、 アドレスバーが無いも同然になってしまうおそれがある。

ああ、いやな予感がする。

ところで、

現実には、フィッシングでは誘導先のURIを偽装したり隠蔽したりするなど、 もっと巧妙な手段が使われていることから、視覚的に似たドメイン名を使用す ること自体はあまり有効なフィッシング手段ではないと考えます。

http://xn--wgv71a119e.jp/support/index.html#link, 登録・運用・サポート - 日本語.jp

この主張はいただけない。

URLを偽装できるのは、ブラウザかサイトに脆弱性があるのが原因であり、 それは取り除かれるべきであるし、隠蔽されているところに入力しないという リテラシが確立されるべきであるのだから、きちんと対策と理解が進めば、 最後には、似通ったドメイン名の問題だけが残ることになる。

現時点で相対的に「あまり有効なフィッシング手段ではない」とするのはけっ こうだが、期限を限定せず絶対的に「あまり有効なフィッシング手段ではない」 と言ってしまうのは、「他の人らかて駐車違反してるやん」と言う大阪のおば ちゃんのようなものだ。JPRSともあろう者が見苦しい。

あ、JPRSじゃないかもしれないけど。

*1 フィッシングとファーミングでは、責任の所在や、ユーザの自衛策のあり方の 点で、性質が異なっているように思う。フィッシングでは、アドレスバー偽装 が可能なブラウザの脆弱性が排除されていれば、また、本物サイトのクロスサ イトスクリプティング脆弱性が排除されていれば、つまりベンダー達が責任を 果たしていれば、あとは、ユーザがアドレスバーの確認を怠らないというリテ ラシーが肝となる。それに対してファーミングでは、hostsが書き換えられる ことなどは本来あってはいけないことで、スパイウェアなどに感染してしまっ た(添付ファイルを実行してしまったなど)ユーザの責任、もしくは、任意コー ド実行を許してしまうブラウザの脆弱性に原因があるということになる。 むしろ、何でもかんでも「フィッシング」とひとくくりに言う人たちにこそ、 ユーザの自衛策を整理せずに、製品でアドホックに対策しようとする商魂が見 え隠れするのではないか?

*2 確認は必ず自 分でやらないと意味がない。サイト側が暗号化されるようにリンクを作ってく れているはずだから確認しなくてよい――という考え方は誤りである。なぜな ら、暗号化ページに入る前の非暗号化ページで、通信路上でパケット改竄され たら、リンク先が本来「https://」であるところを「 http://」に書き換えら れるということが起こり得るので、情報を入れようとしている画面が https:// になっていることを自分で確認する必要がある。

*3 それこそ、対策ソフト売りベンダーに、 そういうことをあえて言わないでおく動機があり得る。

*4 あるい は、[memo:3827] に書かれているように、 証明書を削除してしまって、正規のものだけ復 活するのを待つという手もあるかもしれない。 Windows XPでは、「Windowsコンポーネントウィザード」で「ルート証明書の 更新」がONになっていれば、削除したルート証明書が必要に応じて復活する。 しかし、ルート証明書の安全なダウンロードのために、Microsoft認証局発行 の証明書による署名を検証しているはずなので、全部削除するとその仕組みも 動かなくなるかもしれないので、それはやらない方がよいかもしれない(未確 認)。 ちなみに、特定の認証局を信じたくないときは、削除するのではなく、証明書 を表示して、「詳細」タブで「プロパティの編集」ボタンを押し、「証明書の 目的」のところで「この証明書の目的をすべて無効にする」を選択すればよい。

本日のリンク元 TrackBacks(84)

2005年02月16日

「First Server」の認証局?

NHKエンタープライズ21の「RoBoCoN公式サイト」 で「問い合わせ」という部分をクリックするとジャンプする https:// のURL にアクセスしてみたところ、サーバ証明書はこうだった。

図1: RoBoCoN公式サイトのサーバ証明書

ファーストサーバ社のことだろうか? いや、残念ながら私のブラウザでは この証明書の認証パスを辿ることができなかったので、ここに記載された名前 が真正のものかどうかはまったくわからない。信じてはいけない。 サーバ証明書なのに有効期限が10年と胡散臭いところで気づけばよいか。

というより、ファーストサーバ社は「Firstserver, Inc.」 なので違うのだろう。

ちなみに、ファーストサーバ社は、2004年6月からBIZCERTという認証局サービス を提供しているようだ。

(2) RSAセキュリティ社とのチェーン認証で二重の認証

チェーン認証で「二重の認証」ってなんだろうか。美味しいのだかなんだかわ からないが、こちらは正常な認証局のようだ。ちなみに、

「デジタル証明書」がWEBサイトの安全性を高める

と宣伝されているが、 サーバ証明書でWebサイトの安全性が高まるわけではない。 高まるのはそのWebサイトを使おうとしているユーザの安全性だ。

「オレオレ証明書/認証局」が普通の言葉に

2月15日の登 大遊@...SoftEther VPN 日記によると、 筑波大学の授業で普通に「オレオレ証明書」という用語が使われているらしい。

BroadBand Watch内の「BBっとWORD」 にも出ているようだ。

漫画「アキバ署」の次号ネタへの期待にも挙げられている。

例示用には実在しないドメイン「example.com」等を

警視庁のサイトに「フィッシング詐欺にご用心」というページができていた。

送信者名をその企業の名前にして本文には「下記のURL(http://usouso.com)にアクセスして個人情報を入力しないと、あなたのアカウントは失効します」などというようにもっともらしく書かれています。

「usouso.com」……実在したらどうすんだー、と試しに http://usouso.com/ にアクセスしてみると、 本当に実在したよ。韓国のネットショップのようだ。

こういうときには予約済みドメイン名の「example.com」などを使うとよい。

しかし、嘘っぽさや、極悪っぽさや、被害者っぽさを醸し出すには、 example.com ではいまいち物足りないかもしれない。 「usouso.example」でもよいのだが、最後が5文字以上あるとインターネット のドメイン名っぽくない。

その県警サイトは本物?

警察庁の「フィッシング110番」のページの下の方に、各都道府県警察のWebサイトのURLが表で 示されているが、これをざっと眺めると、都道府県警察のドメイン名というの は判別しにくい。都道府県の下部組織なのだから、pref の左に police とな るのか。県庁のWebサイトの一部として設置されているところも多い。 その一方で、長野県警と静岡県警、高知県警、佐賀県警のサイトは、 地域ISPの普通のレンタルホームページにあるようなのだが……。

こんなんでええのんか?

秋田県警は、

と独自ドメインを使っているようだが、そのドメインの登録者名は……??

本日のコードメモ: OreOreTrustManager

class X509OreOreTrustManager implements javax.net.ssl.X509TrustManager {
    public void checkClientTrusted(
        java.security.cert.X509Certificate chain[], String authType
    ) throws java.security.cert.CertificateException {
    }
    public void checkServerTrusted(
        java.security.cert.X509Certificate chain[], String authType
    ) throws java.security.cert.CertificateException {
    }
    public java.security.cert.X509Certificate[] getAcceptedIssuers() {
        return new java.security.cert.X509Certificate[0];
    }
}
class OreOreHostnameVerifier implements javax.net.ssl.HostnameVerifier {
    public boolean verify(String hostname, javax.net.ssl.SSLSession session) {
        return true;
    }
}
static {
    try {
        javax.net.ssl.SSLContext ssl = javax.net.ssl.SSLContext.getInstance("SSL");
        javax.net.ssl.TrustManager[] tm = {
            new X509OreOreTrustManager()
        };
        ssl.init(null, tm, null);
        javax.net.ssl.HttpsURLConnection.setDefaultSSLSocketFactory(
            ssl.getSocketFactory()
        );
        javax.net.ssl.HttpsURLConnection.setDefaultHostnameVerifier(
            new OreOreHostnameVerifier()
        );
    } catch (java.security.NoSuchAlgorithmException e) {
    } catch (java.security.KeyManagementException e) {
    }
}
 

本日のリンク元 TrackBacks(3)

2005年02月18日

最高裁も推奨するオレオレ警告の無視

最高裁判所の「裁判所オンライン申立てシステム よくあるご質問」より:

図1: 裁判所オンライン申立てシステム, よくあるご質問, 最高裁判所

Q12: 申立書の入力画面が表示される前に証明書に関するセキュリティ警告ダ イアログが表示されます。どうすれば良いのでしょうか?

A12: メッセージの内容を確認し,「はい」又は「常に」を押してください。

最高裁判所にそう言われたのでは国民は従うしかない。

ここはひとつ「よくある質問」に次を追加してもらいたいものだ。


Q12-2: 「メッセージの内容を確認し」とはどの内容をどのように確認すれば よいのでしょうか?

週明けにでも電話してみよう。

「受動的攻撃の被害 = 利用者の自業自得」が最高裁基準

コートドミーノサーバにある、裁判所オンライン申立てシステムトップページには、現在、次の「お知らせ」が掲載されている。

図2: 裁判所オンライン申立てシステムに関するお知らせ, 最高裁判所

本申立てプログラムの稼働に必要な中間プログラム(JRE : Java Runtime Environment)の脆弱性について

裁判所オンライン申立てシステムを利用して申立てを行う際に必要なJREについて,悪意のあるWebサイトを閲覧した場合,任意のプログラムを実行させられたり,パソコンを乗っ取られたりするという脆弱性が発見されました。

JREの提供元であるサンマイクロシステムズ社によると,この問題については,JREを最新の「1.4.2_06」にバージョンアップすることで回避できるとのことですが,裁判所オンライン申立てシステムでは,「JRE1.4.2_06」について,動作確認ができていません。

ついては,JREをパソコンにインストールした状態で,信頼できないサイトを閲覧したり,出所不明のアプレット(プログラム)を実行したりすることのないようにしてください

ご利用のみなさまにはご迷惑をおかけしますが,ご理解とご協力のほど,よろしくお願いいたします。

裁判所オンライン申立てシステムに関するお知らせ, 最高裁判所

きょうび、Microsoftですらそんなことは言わない。

既に2か月半が経過しているわけだが、いまだに「動作確認ができていません」 ということなのか。おそらく動作確認などしていないのだろう。

「_06」といったバグフィックスバージョンの違いだけで、この申立てシステム が動かなくなるのは、 専用の「申立てプログラム」のインストーラが、 「C:\Program Files\Java\j2re1.4.2_04\lib\security」という決め打ちの 場所に、必要なファイルをインストールするようになっているからだ。

2か月半経っても「_06」に対応できないのは、そのために必要な予算を確保し ていないということなのか。Webアプリケーションは作ったら終りではない。 欠陥が見つかったら修正しなくてはならないのであり、そのための費用を運用 コストに見込んでおくのが当然である。それができないならサービスを中止す るべきだ。

参考: 2002年9月ごろの議論

サポート中止ソフトをこれからも入れさせる最高な裁判所

最高裁判所の「必要なプログラム等のダウンロードのページ(図3)

図3: 最高裁判所からのリンク「JREをダウンロードします」

は、JREのダウンロード先として、次のURLへリンクしている。


http://java.sun.com/products/archive/index.html

ここは、開発者向けのサイトである。 冒頭には次のようにこのページの趣旨が説明されている。

Sun is providing the products available below as a courtesy to developers for problem resolution. The products available here have completed the Sun EOL process and are no longer supported under standard support contracts. These products are down-revision products that may have various bugs, Y2000, and possibly security issues associated with them. Sun in no way recommends these products be used in a live, production environment. Any use of product on this page is at the sole discretion of the developer and Sun assumes no responsiblity for any resulting problems.

(以下、今適当に書いた訳)

Sunは以下の製品を、不具合解決のための開発者向け特別措置として提供しま す。ここで利用可能な製品は、Sun EOLプロセスを終えており、これらは、 標準のサポート契約でサポートされることはもう二度とありません。 これらの製品は、様々なバグや、2000年問題、またそれに起因するセキュリティ の問題点を有することのある旧版製品です。Sunは、これらの製品を現行の 製品環境で使うことを全くお勧めしません。このページにある製品のいかなる 使用も開発者単独の自由裁量によるものであり、結果として生じるいかなる 問題に対しても、Sunは一切の責任を負いません。

Archive: Java[tm] Technology Products Download, Sun Microsystems

ようするにここは開発者だけが使うところだ。 おそらくこのリンクを張ったのはベンダーの開発者だろう。 開発者の都合でこういうものを使うことはたしかにあるが、 そのノリが一般市民にまで押し付けられている。 Javaはいまだに技術者の実験用玩具だというのか?

技術者がこういうことをしないよう監督する責任が、 最高裁判所のホームページ管理担当事務員にあるだろうが、 英文だから読んでもいないといったところか。

国民を危険に陥れるこれらの行為は法律で規制してはどうか。

本日のリンク元 TrackBacks(3)

2005年02月19日

官公庁の担当者は署名なしアプレットの存在を知らないのか

官公庁や自治体がサービスを始めた電子申請・届出システムのほとんどは、ク ライアント側でJRE (Java 2 Runtime Environment)の使用を前提としており、 利用者にそれをインストールさせているのだが、JREには、年に1、2回程度の 頻度でセキュリティ脆弱性が発覚している。JREはきわめて汎用性の高いミド ルウェアである(ほとんどOSに近い)ため、脆弱性の発覚は、利用者のWeb利 用全般に危険をもたらすことになる。

もし、JREがほとんどのパソコンで購入時から組み込まれているならば、JRE の脆弱性の発覚に対してアップデート作業を行うのは、パソコン購入者の責任 であり、その必要性を購入者に周知する義務が販売者やメーカーにあることに なる。これは、Windows Updateがそうであるのと同じ理屈からだ。

しかし実際はそうではなく、JREを官公庁や自治体が新規にインストールさせ ているのが現状である。省庁によっては、その省庁のシステム専用のプログラ ムのインストーラがJREも同時にインストールするところもあり、この場合は 明らかに、またそれ以外の場合であっても、JREの脆弱性に対して対応を周知 する義務が、各省庁や自治体にあることになる。そうした考え方から、約3年 前にこのような報道があった。

その後、JREをインストールさせている各省庁は、JREの脆弱性が発覚するた びに必ず告知を出すようになった。このような慣行ができあがったことはすば らしいことで、さすが役所ならではのことであろう*1。その流 れの中に、昨日の日記「「受動的攻撃 の被害 = 利用者の自業自得」が最高裁基準」で書いた最高裁からの告知

本申立てプログラムの稼働に必要な中間プログラム(JRE : Java Runtime Environment)の脆弱性について

はある。

ところが、裁判所オンライン申立てシステムでは、「脆弱性が発見されました」 と事実の通知こそしているものの、どうすればよいかの説明が、

ついては,JREをパソコンにインストールした状態で,信頼できないサイトを閲覧したり,出所不明のアプレット(プログラム)を実行したりすることのないようにしてください。

裁判所オンライン申立てシステムに関するお知らせ, 最高裁判所

で済まされてしまっている。このような対応は他省庁には見当たらない。

なぜこうなってしまったのか。その謎を解く鍵は、環境省、金融庁、内閣府、 総務省、および公的個人認証サービス都道府県協議会が出している同じ告知の 文章にありそうだ。図1〜5にそれらを示す。

図5: 公的個人認証サービス都道府県協議会の告知
JRE (Java Runtime Environment) のセキュリティ上の脆弱性について

これらのいずれにも「身元不明なアプレットの実行を承諾しないように」とい う文があるが、これらを書いた人は、JREの脆弱性がアプレットにどのように 危険性をもたらすかについて根本的に誤った理解をしているとしか考えられない。

なぜなら、「承諾」もなにも、普通のJavaアプレットはページを開いただけで 即座に実行が開始されるものだからだ。事実、以下にあるように、この日記 ページを見た人は既にアプレットの実行を許している。

あなたのコンピュータにはJavaがインストールされていないようですので、 あなたは承諾はしてはいません。

では、環境省、金融庁、内閣府、総務省、公的個人認証協議会が言う「承諾」 とは何なのだろうか? おそらくそれはこれ(図6)のことだろう。

図6: 署名付きJavaアプレットが起動されようとする ときに現れる「承諾」確認ウィンドウ

これは、署名付きアプレットが起動されようとしているときに現れる「確認」 ウィンドウである。「確認」とは、このアプレットを実行することを承諾する かを利用者に確認することを指す。

この確認ウィンドウが現れるのは、アプレットが署名付きのものである場合で あり、署名なしのアプレットでは何ら確認なしに、即座に実行が開始される。

署名付きの場合にだけ確認ステップがあるのは、署名付きアプレットの実行を 「承諾」した場合、そのアプレットは、どんな処理でも実行を許される(つま り、ファイルを読むとか、ファイルに書き出すとかいった処理の実行を許され る)のに対し、署名なしのアプレットでは、そうした処理の実行が許されてい ないからだ。

元々Javaアプレットは、「サンドボックス」と呼ばれる強いセキュリティ制約 の上で動作する、Web上のプログラムとして、最初登場した。Webを閲覧しただ けで動き始める、よそのサイトからのプログラムが、閲覧者のコンピュータの ファイルにアクセスするようなことがあってはならないので、そうした処理を 禁止していた。禁止されているからこそ、安心して閲覧できる。 そこが登場当初のJavaの最大の特徴であった。

しかし、そうした制約があると、アプレットにできることは限られたものとな る。ゲームとか、アニメーションとか、コンピュータシミュレーションとか、 そういったものにしか使えず、ビジネスには使えないと言われていた。そこで 後になって登場したのが、署名付きJavaアプレットである。

各省庁が電子申請・届出システムのために署名付きアプレットを使っているの は、それらのアプレットが、利用者のコンピュータ内のファイルを読み取った り、書き込んだりするためである。なぜなら、電子申請・届出システムのアプ レットは、作成途中の届出書類を利用者のコンピュータ上にファイルとして保 存したり、保存してあるものを読み出して送信する機能を備えているからだ。

署名付きアプレットはどんな処理でも実行可能であるから、利用者の確認なし に実行が開始されるようなことがあってはならない。利用者は、その署名が誰 によってなされているかを、PKIの仕組みによって確実にそうだと確認したう え、その署名者を信用する(悪いことをしようとしているプログラムではない だろうと信用する)ときだけ、「はい」ボタンを押して実行を許可するわけだ。

そして、JREに脆弱性が見つかったというのは、たいていの場合、サンドボッ クスを突破できる欠陥が見つかったことを意味している。つまり、署名なしの アプレットがファイルを読んだり書いたりできてしまうということだ。Webを 閲覧しただけでファイルを盗まれたり、ファイルを破壊されたり、スパイウェ アを埋め込まれたりするといった被害に遭う可能性があるということだ。

そのようなJREの脆弱性において、「承諾」というものは何ら関係がない。

身元不明なアプレットの実行を絶対に承諾しないようにしてください。

というのは、まるっきり頓珍漢である*2

おそらく、環境省、金融庁、内閣府、総務省、的個人認証協議会の告知文を書 いた人たちは、「アプレット = 署名付きアプレット」だと思い込んでいるの だろう。自分達が提供しているアプレットが署名付きだから、そこしか見てい ないのだろう。署名なしアプレットの存在そのものを知らないのだろう。

ちなみに、財務省、外務省、厚生労働省の同様の告知文には、この頓珍漢な文 は見当たらない。

  • 財務省 Java 2 Runtime Environment(JRE)脆弱性について

    3.当面の対処方法

    (略)

    動作検証が完了するまでの間、財務省電子申請システムをご利用するにあたっ て、 JREをご利用されている方は、電子申請システムを利用した後にJREをオ フにする操作 (下記4)を実施していただきますようお願いいたします。

  • 外務省 Java Plug-in(JRE)の脆弱性について

    当面の対策方法

    このような被害を回避するため、お手数ですが、汎用受付等システムを利用さ れる場合以外は「Java Plug-in(JRE)」をアンインストールしておくことを 推奨いたします。

  • 厚生労働省 Java 2 Runtime Environment(JRE)の セキュリティ・ホールに関するお知らせ

    【回避策】

    1.電子申請・届出システムにアクセスするとき以外は、JRE を無効にします。 無効にする方法は、こちらをご参照ください。

    2.電子申請・届出システムにアクセスする前に、他のサイトにアクセスしな いようにします。

環境省、金融庁、内閣府、総務省、公的個人認証協議会の文書が、ほぼ同じ文 面になっているのも興味深い。ひとたびどこかが誤ったことを書いてしまうと、 (役所の文書に誤りはないことになっているので)別のところがそれを真似て 書いてしまう。無断リンク禁止教が広まったのと同様に、役所は誤った理解が 伝染しやすい土壌があるのではなかろうか。

そして伝染時にはしばしば変異が生ずる。環境省、金融庁、内閣府、総務省、 公的個人認証協議会の文書では、対応方法として2つを挙げている。一つ目が、 「身元不明のアプレットを承諾しないように」であり、二つ目は「JREをオフ にせよ」である*3し かし、最高裁判所は、見よう見まねでこの注意喚起文を書くにあたり、このう ちの一つ目だけにしてしまった。それで、

ついては,JREをパソコンにインストールした状態で,信頼できないサイトを 閲覧したり,出所不明のアプレット(プログラム)を実行したりすることのな いようにしてください。

などという(きょうび Microsoftでさえ言わない)ことを書いてしまった―― そういうことなのではなかろうか。

セキュリティに関わる文書を書くときは、必ずセキュリティのことがわかる技 術者のチェックを受けるべきである。署名なしアプレットの存在を知らないよ うな人が、一般市民に対してセキュリティに関する対応を指示するのは間違っ ている。素人が「津波の心配はありません」などと言ったりしないのと同じこ とだ。

「よくある質問」は本当によくあるのか?

国土交通省オンライン申請システムの「よくあるご質問」に 面白いことが書いてあった。


「フィンガープリント」の確認を行わなかったらどうなりますか。


「フィンガープリント」とは、拇印や指紋という意味です。 入手した電子証明書の信頼性を確認するために、広く公開している(ここでは 総務省ホームページや国土交通省ホームページで公開しています)フィンガー プリントと入手した電子証明書のフィンガープリントが一致するかを確認します。 一致すれば、自己署名証明書などの電子証明書が正しく入手できているという確認ができます。国土交通省では、この電子証明書を 用いて安全な通信を行っています。申請者の方と国土交通 省の間の安全な通信のため必要な確認ですので、「フィンガープリント」の値をご確認ください

国土交通省オンライン申請システム よくあるご質問

確認しなかったらどうなるか? という問いなのに、答えていない。

本来ならばこう書くべきところだ。


フィンガープリントを確認していない自己署名証明書は、偽物である可能性を 否定できません。まだ安全性を確保できていない通信路上で入手したものは、 通信中にデータが改竄されている可能性が否定できないためです。偽の自己署 名証明書をルート認証機関としてインストールしてしまうと、あなたのコンピュー タは様々な危険にさらされることになります。たとえば、フィッシング詐欺に 騙されやすくなったり、トロイの木馬を実行してしまいやすくなったり、 偽の電子申請システムに情報を送信してしまったり、通信データを盗聴される などの危険性があります。

フィンガープリントが一致すれば、証明書が正しく入手できているという確認 ができます。国土交通省では、申請者の方と国土交通省の間の安全な通信のた めにこの証明書を用いていますので、証明書が偽物でないかを確認するために、 必ず「フィンガープリント」の値をご確認ください。


自分で用意した設問だろうに、どうして自分で答えられないのか、 まったく理解に苦しむ。

*1 同様の問題は Acrobat Readerなどにも存在するが、こちらは解決されていない。首相官邸の「新着情報」の ページなどのように、Acrobat Readerのインストールが必要だとしている 官公庁は多いが、Acrobat Readerに脆弱性が発覚したときに、それらのサイト がその情報を閲覧者に周知するといったことは行われていない。

*2 「承諾」ステップが存在する、 署名付きアプレットの場合には、脆弱性があろうとなかろうと、どのみち、 身元不明なアプレットの実行を承諾しないようにしないといけないわけで、 脆弱性が見つかったから承諾しないようにというのも、それまた頓珍漢な 話だ。もしかして、そのことすらこの人たちは理解していないのではないかと さえ思えてくる。そう考えると、信頼されていない証明書だと警告が出ている にもかかわらず「はい」を押させる彼らの神経も理解できる。

*3 法律の文章によくあるように、and なのか or なのか が不明だという点も興味深い。おそらく and のつもりなのだろうが。

本日のリンク元 TrackBack(1)

2005年02月20日

フィッシング防止のため地方銀行はこうするべき

フィッシング詐欺対策として都市銀行が立て続けに注意喚起を出したことは昨年9月17日の日記 でも書いた。それら注意喚起では、アドレスバーやサーバ証明書の確認方法に ついて書かれていた。

地銀ではどうかというと、一部のセキュリティ意識の高い(?)ところが 同様の説明を書いている。ちょっと探したところでは、常陽銀行と千葉銀行と が見つかった。以下のように書かれている。

これらでは、自社のドメイン名とは別のドメイン名を顧客に覚えてもらわない といけないところが辛い。

常陽銀行のドメイン名は joyobank.co.jp だが、図1では www2.paweb.anser.or.jp/BS?CCT0080=0130 であることを確認せよと言ってい るし、千葉銀行のドメイン名は chibabank.co.jp だが、図2では www2.ib-center.gr.jp となっていることを確認せよと言っている。 難儀な話だ。

これは、自前でインターネットバンキングシステムを構築できない地方銀行が、 NTTデータの「金融ANSERシステムサービス(anser.or.jp)」ないし、 日立の「日立インターネットバンキングセンター(ib-center.gr.jp)」 もしくは、日本IBMの「地銀サイバープロジェクト(cyber-biz.ne.jp)」 のASPサービスを使っているためだ。

フィッシング詐欺に騙されないために、地銀の預金者たちは、これらのドメイ ン名を覚えていないといけない。 いずれも、NTTデータ、日立、日本IBMといった、信頼ある企業名の含まれてい ない名前で、anser だの ib-center だの cyber-biz だのよくわからない名前 で覚えにくいうえ、どれも怪しげな名前にさえ見えるし、gr.jp なんかは誰で も取れるドメイン名というところも危うい。

この問題は現実的な解決策がある。 Webバグ広告業者がやっていることを真似ればよいのだ。

一昨年6月15日の日記 に書いたように、ソニースタイルやアップルコンピュータ、日本航空のメール マガジンでは、Webバグを挿入する際に、Webバグのアクセス先を mail.jp.sonystyle.com や news.apple.co.jp、jmb.jal.co.jp のホストにしている。

しかしそのホストに割り当てられた IPアドレスは、ソニーやアップルや日本 航空が所有するアドレスブロックではなく、DoubleClick社 が所有するものとなっている。

> nslookup mail.jp.sonystyle.com
Non-authoritative answer:
Name:    mail.jp.sonystyle.com
Address:  216.73.91.53

> nslookup news.apple.co.jp
Non-authoritative answer:
Name:    news.apple.co.jp
Address:  216.73.89.11

>  nslookup jmb.jal.co.jp
Non-authoritative answer:
Name:    jmb.jal.co.jp
Address:  216.73.89.11

>  whois -h xxxxxxxx 216.73.91.53
OrgName:    Double Click, Inc. 
Address:    450 West 33rd Street 16th floor
City:       New York
StateProv:  NY
PostalCode: 10001
Country:    US

> whois -h xxxxxxxx 216.73.89.11
OrgName:    Double Click, Inc. 
Address:    450 West 33rd Street 16th floor
City:       New York
StateProv:  NY
PostalCode: 10001
Country:    US

つまり、通信先のコンピュータはDoubleClick社の管理下にあるけれども、 そのような使用をソニースタイル、アップルコンピュータ、日本航空が正式に 認めているということだ。DNSの管理によって。

地銀の共同利用システムも同様にすればよい。つまり、 ログイン画面のコンピュータはこれまでどおり、NTTデータ、日立、日本IBMに 置いたまま、anser.joyobank.co.jp や ib-center.chibabank.co.jp という ホスト名でアクセスできるようにすればよい。

サーバ証明書はどうするかというと、anser.joyobank.co.jp なので常陽銀行 の名前で常陽銀行の社員が証明書を取得したうえ、NTTデータが運営する ANSERシステムのサーバに入れてもらう。

SSLの仕組み上、名前ベースのバーチャルホストが使えなくなるので、同じ コンピュータの上に複数の銀行を置けなくなるが、昔 anser.or.jp がやって いたように、ポート番号で銀行を分ければよいのではないか。

これをやらない理由はないだろう。移行コストの問題だけか。1行あたり、 1千万もかかりやしないと思うがどうか。フィッシング詐欺から顧客を守る ためにいくらかける価値があるか。

ホームページ改竄被害に遭った銀行がなすべきことは?

[connect24h:8320]にあるように、 先月23日ごろ、荘内銀行のホームペー ジが改竄被害に遭ったらしい。

この件について銀行からアナウンスはされていないとのことだが、おそらく、 銀行側の言い分としては、インターネットバンキングは別サーバ (anser.or.jp)で提供しているので、説明の必要はないといったところだ ろうか。

私が見に行ったときは、以下の図のようになっていた。

図3: 改竄が発覚した少し後にアクセスしたときの荘内銀行トップページの画面

つまり、その時点で anser.or.jp へのリンクが置いてあったのだ。 このサーバはこの時点で安全性が確認されていたということなのだろう。 なかなかすばやい安全確認で関心した。

サーバを停止してインターネットバンキングが使えなくなると顧客が困るだろ うから、とりあえず anser.or.jp へのリンクだけでも設置しようというその 気持ちはわかるが、もしこれが再度改竄され、リンク先URLを書き換えられて しまうと、ブックマークからやってくる顧客達が、偽サイトに誘導されてしまう。 つまり、フィッシング(あるいはファーミング、それとも別の用語が必要か?) 被害が発生してしまうので、安全確認は欠かせない。 このサーバが改竄できたことはクラッカー達に知れてわたってしまっていただ ろうから、別のより悪質な目的で再度改竄のターゲットにされる危険性はいつ もよりも高まっていただろう。そういう中でのすばやい安全確認に感心した。

改竄被害といっても子供の悪戯のような改竄(改竄されていることが丸わかり の改竄内容)だったようで、不幸中の幸いだった。(本当にそれだけだったか は知らないが。)

フィッシング詐欺の実態を追いかけよう

spam送信元のブラックリストデータベースを作ろうという 「RBL.JPプロジェクト」のサイトで、 収集しているspamメールから、phishingに関するものだけ選り分けた、 「フィッシング詐欺サイト情報」というページが運営されている。

毎日すばやく更新されているようで、偽サイトの実物を見られるときもあり、 大変参考になる。今年1月から始められたようで、その都度、適切なところへ 通報もなさっているようだ。頭が下がる。

クリックするとトラックバックURLのコピー?

「ブラウザがIEであれば下記をクリックするとURLがクリップボードにコピーされます」でGoogle検索すると、ものすごい数のサイトがヒットするが、 これはどの blogツールの機能だろうか?

この機能を使っている人たちは、IEのセキュリティ設定で、 「スクリプトによる貼り付け処理の許可」を「有効にする」にしているのだろうか。 せめて「ダイアログを表示する」にしたほうがよい。以下の危険がある。

本日のリンク元 TrackBacks(100)

2005年02月22日

公益性のない無断複製自動公衆送信

私の日記が無断複製されて送信可能化され、実際に自動公衆送信されているようだ。

http://livemark.jp/%63%61%63%68%65/0579077897

フィッシングか? と思わせてくれるようなページもあるようだ。

http://livemark.jp/%63%61%63%68%65/0590528629
http://livemark.jp/%63%61%63%68%65/0690697388

***

ところで、この日記が発行するcookieの内容は11月12日の日記に書いたとおりであるが、その内容は実際のところ以下のようにして表示させてみると次のようになる。

このページのcookieの内容: <script>document.write(document.cookie)</script>


このページのcookieの内容:

本日のリンク元 TrackBacks(70)

2005年02月25日

とりあえず「キャッシュ」じゃなく「ミラーコピー」と称してくれないか

22日の日記の件、当該サイトの運営者のものらしきメールアドレスが見つかった*1 ので、23日に以下の内容のメールを送った。

Subject: 著作権侵害に対する警告

あなたが運営していると推察されるサイト「LiVEMARK」http://livemark.jp/
は、私の著作物(http://takagi-hiromitsu.jp/diary/)を無断で複製し自動
公衆送信しており、著作権法に違反していると私は考えます。しかしながら、
私の著作物については私が侵害とみなさなければよいとも言えます(親告罪)。

以下の条件に従ってくださった場合には、私の著作物(上記のもの)について
は黙認することにします。(http://livemark.jp/ における使用に関して。)

和解条件
   「キャッシュ」と書かれているすべての部分(他者の著作物のページをも
   含む)を「ミラーコピー」という名称に変更してください。

ただし、この条件が満たされている場合であっても、この黙認はいつでも中止
できるものとし、その際には私からそちらへその旨を通知するものとします。

以上

しかし、この希望はかなわず、当該機能は廃止されるという結末となった。

22日の日記のリンク元をあちこち辿ると、案の定、 「じゃあProxyサーバのcacheはどうなの?」的な反応がチラホラ見られた。

LiVEMARKの運営者は、自身の運営するフォーラムにおいて、

著作権問題の件ですがツッコマれるかなーって感じです。

正直な話、僕は著作権の問題は詳しくないので頭には入っていたんですがシス テムの利便性を追求した結果どこかにこの問題を置き忘れた状態でした。 現在livemarkは影響力も少ないのでこのままキャッシュ機能をいかしていきたいと思っています。(略)

livemark.jp フォーラム, キャッシュについての考え方を教えて頂けませんか?

という発言をしていたくらいで、今やこのように、法律のことを考えない人 (へたをすると刑罰適用年齢に満たない者)が個人でこういうサービスを自力 で作って始めてくる時代なのだ。よそが同じことをやっているのだから(同じ じゃないのだが)自分もやってよいと思ってしまうようだ。

昨年9月12日の日記「技術用語 「cache」が政治的な言葉として拡大利用される」で懸念していた、 cacheでないものをcacheと呼ぶことの弊害が、 もうここまで来ているということだ。

*1 当時は連絡先さえ書かれていなかった。現在は連絡先が示されている。

本日のリンク元 TrackBack(1)

2005年02月26日

電子政府の混乱解決に Java 5.0が有効かもしれない

LGPKIにしろ、GPKIにしろ、一般市民が安全に使いこなすのは困難という問題 は別として、とりあえず、そのやり方に従って、各ルート認証局の証明書をイ ンストールするとしよう。 しかし、18日の日記「最高裁も推奨 するオレオレ警告の無視」の事例からわかることは、 この「よくあるご質問」ページを書いた人自身が、最高裁判所認証局の証明書 をインストールしていないことを示している。「信頼できない団体によって 発行されています」と表示されているのだから。同様の事例は防衛庁の「一般利用者用マ ニュアル 申請者編」のp.23にも見られる。

なぜこんなことになっているのか。ひとつには、この警告ダイアログの意味が 理解されていないためであろうが、それは後にして、それとは別に、証明書 ストアが複数あることが使い方を難しくしているという点もある。

最高裁の「よくあるご質問」を書いた人は、おそらくWindowsの証明書ストア 「信頼されたルート証明期間」にはインストールしているのだろう。しかし、 問題の警告は、Sun MicrosystemsのJRE(Java Runtime Environment)が出し ているものであり、JREにはまた別の証明書ストアがあり、そちらに登録して いないとこの警告が出るのだ。

それに関して次の興味深い事例がある。

公的個人認証(JPKI)を利用するには、 各省庁(GPKI)、地方公共団体(LGPKI)とは別に、さらに、 「地方公共団体による公的個人認証サービスブリッジ認証局」という認証局*1の 証明書をルート認証局として証明書ストアに登録する必要があるのだが、 公的個人認証を利用するには、住民基本台帳カードにカードアプリケーション をインストールしてもらう必要があるので、市役所に出向く必要があり、 その際に「公的個人認証サービス利用者クライアントソフト」というCD-ROMを手渡しでもらうことになっ ていて、このCD-ROMにこの認証局の証明書が入っている(しかも、 インストーラを実行するだけで証明書もインストールされる)ので、 証明書は安全に配布されている。本来あるべき姿だ。

ところが、「公的個人認証サービス オンライン窓口 利用者マニュアル 操作手順編」のp.7 には、図1のように、Javaアプレットのページを開いたときに「信頼できない 団体によって発行されています」の警告が出ることがあるから、そのときは 「いいえ」を押すようにと指示している。これが出るのは事前準備がうまく できていないからなので、「事前準備編」の2.6.2節に従えと指示している。

図1: 公的個人認証サービス オンライン窓口 利用者マニュアル 操作手順編 p.7より

他の役所のように「はい」を押せなどと言ったりしないところは関心できるが、 CD-ROMで配布しているはずなのになぜこんなことになるのか。

指示に従って「 公的個人認証サービス オンライン窓口 利用者マニュアル 事前準備編」の 2.6.2節を見てみると、p.12に以下のように書かれている。

2.6. ルート証明書のインポート

オンライン窓口システムで申請手続を行うためには、ルート認証局の証明書を 予めブラウザとJava Plug-in にインポートする必要があります。

2.6.1. ブラウザへのルート証明書のインポート

利用者クライアントソフトの取扱い説明書(CD-ROM に格納されています)の 付録2.「公的個人認証サービスブリッジ認証局の自己署名証明書(=ルート証 明書)の登録手順」に従い、ルート証明書のインポートを行ってください。 (利用者クライアントソフトのインストール時にお済みの方は、この 作業は不要です。)

2.6.2. Java Plug-in へのルート証明書のインポート

Java Plug-in へのルート証明書のインポートに関しては、<バッチプログラ ムによる自動登録の場合>と<コマンドプロンプトによる手動登録の場合>に 分けて説明します。

公的個人認証サービス オンライン窓口 利用者マニュアル 事前準備編 p.12

うっかりすると読み違えてしまうが、「ブラウザへのインポート」は、CD-ROM のインストーラでインストール済みの場合には省略できるが、「Java Plug-in へのインポート」は省略できず、自分でやる必要があると書かれている。

それをどうやってやるかは、p.13に書かれているのだが、

registCaCert.batを公的個人認証サービスポータルサイトからダウンロードし、任意のフォルダに保存します。

※ご利用の環境によってダウンロードできない場合は、次の<コマンドプロンプトによる手動登録の場合>(p.17)にお進み下さい。

公的個人認証サービス オンライン窓口 利用者マニュアル 事前準備編 p.13

とある。ダウンロード? どこで? バッチファイル?? と疑問が沸々と湧い てくるが、ようするに、どうやら図2のページのことを指しているらしい。

図2: 公的個人認証ポータルサイトの、バッチファイ ルをダウンロードせよという指示

なんじゃこりゃー? と、そのバッチファイルをダウンロードしてみると、 その内容は以下のようになっていて唖然とする。

@cd "C:\Program Files\Java\j2re1.4.2_01\bin"
@echo **********************************************************************
@echo 注意:これはJRE1.4.2_01用のバッチプログラムです。
@echo JREのバージョンが1.4.2_01以外の場合は正しく動作しません。
@echo また、JREおよび利用者クライアントソフトをインストールする際に初期設定
@echo 以外のフォルダを指定した場合は、ウィンドウ右上の【×】をクリックして、
@echo このウィンドウを閉じてください。「オンライン窓口 利用者マニュアル」の
@echo 該当するブラウザの「事前準備編」の<コマンドプロンプトによる手動登録の
@echo 場合>を参照し、ルート証明書をインストールしてください。
@echo **********************************************************************
@pause
@echo ルート証明書をキーストアに追加しています。
@echo 証明書の信頼を求めるメッセージが表示されるまで、そのままお待ちください。
keytool -import -trustcacerts -storepass changeit -file "C:\Program Files\JPKI\JPKIBCA.cer"
-keystore "C:\Program Files\Java\j2re1.4.2_01\lib\security\cacerts" -alias JPKIONLINE
@echo 処理を終了します。
@pause

見てわかるように、当然ながらこれは本当に 1.4.2_01 でしか動かない。 パス名が決め打ちで書かれているからだ。 他のバージョンのJREを使う場合(脆弱性のあるバージョンを使うわけにはい かないのだから)にはどうするかというと、利用者マニュアルは p.19 で 図3のように言っている。

図3: 公的個人認証が一般市民にコマンドをこのよう に打てと指示している様子

もうね、アホかとバカかと。 こんなことを一般市民に本気でやらせるつもりなのか?と。

JREのバージョンが色々であっても、自動的に場所を探してインストールする プログラムを作ることは、簡単にできるはずであり、このやる気のなさには 呆れ果てる。

それに、せっかく証明書がCD-ROMで安全に配布されているのに、システムを使 うために、別途プログラムファイルのダウンロードが必要となっているようで は、そのダウンロードファイルが真正のものであるか確認しないといけないの であり、その手段*2も用意されていないよう であるから、ニセのバッチファイルをダウンロードさせられたら、利用者は 詐欺師達の餌食となってしまう。安全性の確立していない通信路経由でプログ ラムファイルをダウンロードさせ、署名の確認もさせずに実行させるのはやめ るべきである*3

なるほど、もしかすると、.exeのインストーラではなく、.batのバッチファイ ルとなっているのは、利用者が自分でバッチファイルの内容を読んで、 怪しいプログラムではないことを自力で確認できるようにするためだろうか? いや、さすがにそんなバカな話はないだろう。そんなことを一般市民に強制し てよいはずがない。

そもそもそれ以前に、なぜこのバッチファイル(ないしちゃんと作ったインス トーラ)が、CD-ROMに入っていないのか?

おそらく、CD-ROMを作成した当時(私が持っているCD-ROMには「平成15年12月」 と印刷されている)には、この問題に気づいていたかったのではないか。後で、 警告を無視して「はい」を押すことがまずいとわかり、とりあえず責任逃れで きる範囲の最小限の対処をしたのが、このテキトーなバッチファイルというこ となのではないか。

なぜCD-ROMを作り直さないのか? 本気で市民に公的個人認証を使わせるつも りがあるようには見えない。

このような滅茶苦茶な惨状を招いたのには、ひとつには、ルート証明書を入れ るべき場所が、WindowsとJavaと別々になっていることが要因としてあるわけ だが、ようやく本題に移ると、この問題は Java 5.0を使うならば自然に解決 できるようだ。

「Java 5.0」は、正確には「J2SE (Java 2 Platform Standard Edition) Runtime Environment 5.0」と呼ばれるもの で、以前からのバージョン表記に倣えば「J2RE SE 1.5.0」に相当する。

Javaは 1.4 から 1.5への改版で飛躍的な改良がなされている。そのひとつが、 証明書関連の機能である。図4は「Javaコントロールパネル」(Windowsのコン トロールパネルから起動できる)の「詳細」タブの様子である。

図4: Java 5.0のJavaコントロールパネルの詳細タブ のデフォルト設定

ここに「ブラウザのキーストア内の証明書およびキーを使用する」という項目 がある。これがONになっていると、JavaからWindowsの証明書ストアが(おそ らくMozillaで表示しているときにはMozillaの証明書ストアが)参照されるの で、証明書のインストールは一箇所でよいことになる。

しかもこれがデフォルト設定になっているので、使用するJREを1.5とすれば、 「公的個人認証サービス利用者クライアントソフト」のCD-ROMのインストーラ を実行するだけで、異常事態を知らせる警告の出ない安全な方法でアプレット を実行することができるようになる。具体的には、図5の正常を知らせる 警告ダイアログだけが現れる*4ので、信用する場合には「はい」を押す。

図5: 利用者が確認するダイアログはこれだけであるべき

というわけで、電子政府のシステムをこれから作り直すなら、Java 5.0の使用 を前提とするのがよいだろう。

Java 5.0を使い、こう設定しよう

最高裁にしろ、防衛庁にしろ、説明書で警告を無視させるという誤った記述を してしまうのは、その警告ダイアログの意味がわかりにくいことも、ひとつの 要因だろう。

図6は、JRE 1.4.x の場合の警告ダイアログであるが、これには 5つの問題点 がある。

図6: JRE 1.4.x でのアプレット署名検証時の警告ダイアログ

1つ目は、「信頼できない団体によって発行されている」と警告が出ているの に、(つまり、誰でも自由に作れるニセの「JPKI」認証局発行の証明書なのか もしれないのに)、「……によって発行者の信頼性が検証されました」と表示 されていることだ。

英語版でもここは「Publisher authenticity verified by: "JPKI"」となって いるが、「検証されました」という表現をどう解釈するかだ。おそらく、 開発者の意図としては、検証が成功したという意味ではなく、検証を行った (検証結果は別にして)という意味のつもりだったのだろう。だが、利用者に は、真正であることが検証されたという意味に読めてしまう。

「"JPKI"によって」などと、確認できていない認証局の名称が表示されるので、 もしここが「"VeriSign, Inc.によって」となっていたら、ほとんどの 一般の人は「はい」を押してしまうだろう。そしてもはや言うまでもなく、 誰でも無料のソフトを使って「VeriSign, Inc.」を名乗る認証局を作って オレオレ証明書で署名することは可能なのだ。

2つ目は、「信頼できない団体によって発行されている」にもかかわらず、 画面の雰囲気は正常な場合とよく似ており、異常だということがわかりにくい。

このことは、MicrosoftのActiveXコントロール(および MicrosoftのJava VM における署名アプレット)の仕組みと比べるとよい。 Windows XP SP1以前においては、このような確認できない証明書で署名された オブジェクトの埋め込まれたページにアクセスすると、図7の警告ダイアログ が現れる。一見して異常事態だとわかるようになっている。

図7: Windows XP SP1以前で署名の真正性が確認できないときの警告

図6のSun Microsystemsの警告ダイアログは、Internet Explorerが、https:// ページにアクセスするときにサーバ証明書がオレオレ証明書だったときに出す 警告ダイアログと似ている。有効期限が期限内ならば丸印、期限切れならば三 角印のアイコンを表示し、証明書の発行元が確認できたときは丸印、できない ときは三角印となる点は共通である。つまり、Sunはこれに似せて作ったのは ないかと推察されるわけだが、ここに大きな誤りがある。

https:// へのアクセスで出す警告と、コード署名されたオブジェクトに対す る警告とでは、性質が異なるのだ。https:// では、正常な場合には警告は出 さないのに対して、コード署名では、正常な場合にも警告ダイアログを出す必 要がある。したがって、利用者は、https:// で警告が出たら基本的に「いい え」を押せばよく、コード署名の警告が出たら、検証正常時にはよく考えて 「はい」または「いいえ」を押し、異常時には常に「いいえ」を押すようにす ればよいのだが、この見分けが、Microsoftの仕組みでは容易であるのに対し て、Sunの仕組みでは容易でない(三角印をよく見ないといけない)。

3つ目は、図6の警告ダイアログが、普通の人たちにとっては、見慣れないもの であり、どういう意味なのか、どう操作するべきなのかがわからないという点。

もっともそれは、WindowsのActiveXコントロールでの警告でも同じことである が、この仕組みが導入されてもう7年くらい経っていること、また、2000年ご ろに、悪意あるActiveXコントロールが実際に多く出回った(ダイヤルアップ 接続先を国際電話に変更して多額の請求をするもの)こともあって、この警告 ダイアログが出たらどうするべきかを解説した記事が、雑誌などに多数掲載さ れてきた。それに対して、SunのJavaのこの警告ダイアログは、起き得る被害 は同一であるにもかかわらず、これを解説している記事は皆無だろう。

JREをインストールすることによって、この新たな脅威が生ずるわけだが、 JREをインストールするときにそのことは誰も教えてくれない。

4つ目は、そもそも、証明書の発行認証局が確認できない状況で、署名アプレッ トを実行できてしまうこと(「はい」ボタンがあること)が間違っている。 確認できない証明書で署名されているのは、署名されていないのに等しい。

5つ目は、警告ダイアログでのデフォルトボタンが「はい」になっているが、 これは「いいえ」をデフォルトとすべきである。 Windowsの仕組みではそうなっている。

これらの問題のいくつかが、Java 5.0で解決されているのである。

まず、1つ目の問題は、図8のように改善された。 「発行者の信頼性を検証できません」と表示されるようになり、 検証できないときは証明書の名称も表示されないようになった。

図8: J2SE RE 5.0 でのアプレット署名検証時の警告ダイアログ

2つ目と、3つ目の問題はいくらか改善されたと言える。警告ダイアログが Windowsものにわりと似たデザインに変更されており、 「黄色い三角マークがあったら「いいえ」を押す」という単純なルールで、 利用者のリテラシー教育が可能になるかもしれない。

4つ目の問題は、確認できない証明書で署名されたアプレットの実行を常に拒 否するよう、Javaコントロールパネルで設定できるように改善された。図4の ところに、「ユーザが信頼できない認証局からのコンテンツへアクセス権を 与えることを許可する」という項目があり、ここをOFFにしておけば、 そのようなページを表示したときには、図9のエラーダイアログが現れて、 実行できないようになる*5

図9: Java 5.0で「ユーザが信頼できない認証局から のコンテンツへアクセス権を与えることを許可する」をOFFにしたとき

これがデフォルト設定になっていないのは残念だ。

5つ目の問題は、「詳細」ボタンがデフォルトになったので、ある程度改善さ れたとは言える。ただ、証明書の認証パスが検証できないときは、「詳細」ボ タンで表示される内容を読んだところで何の判断材料にもならない(フィンガー プリントをここで照合しろというの?)のであるから、これをデフォルト ボタンにしても解決にならず、むしろ誤解を生むおそれさえある。

というわけで、Javaは 5.0を使おう。そして設定は以下のようにしよう。

図10: Java 5.0の設定はこうすべし

関連: [j-h-b:51602]

*1 「政府認証基盤ブリッジ認証局」とはまた別らしい。

*2 コード署名するとか。

*3 このバッチファイルは、http:// のページからダウンロー ドするようになっている。

*4  ブラウザのキーストアの認証局から発行されたサーバ証明書の https:// に Javaからアクセスしようとすると、警告ダイアログが出てしまうバグを発見し た。証明書も期限も正常と表示されるのだが、この場合はそもそも警告は出さ ないべきであり、JREの証明書ストアを参照する場合にはこの警告は出ない。 あとでBugParadeに投稿しておこう。

*5 「未証明の証明書」というタイトルはいかがなものか。調べてみると英語版では、「Certificate Not Verified」という 表現になっている。「証明書が検証されていません」と訳すべきところだろう。 こういうとき、「the certificate which is not verified」の略だとして訳されて いるらしきメッセージをしばしば目にするが、ここは表題なのだから、 「certificate is not verified」の略だろう。 IEの「Action Cancelled」が「取り消されたアクション」と訳され続けている のを思い出す。 ちなみに、「詳細情報」ボタンを押すと、「java.security.cert.CertificateException: Your security configuration will not allow granting permission to self signed certificates」とスタックトレースが表示されるが、 このメッセージをダイアログに表示したらいいのに、ずいぶんと手抜きだなあ。

本日のリンク元 TrackBacks(2)

最新 追記

最近のタイトル

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