高木浩光＠自宅の日記

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