高木浩光＠自宅の日記

■ 電子政府の混乱解決に 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]