電子証明書と認証局：PKI基礎講座（2）

　さて、前回の記事中で、公開鍵はだれがどんな方法で入手してもよいもので、その公開鍵の持ち主を証明するものが電子証明書であることを書いた。今回はこのあたりについてちょっと突っ込んだ話をしよう。

公開鍵はだれのもの？

　電子証明書は実世界における印鑑証明書にたとえられることが多い（図1）。印鑑証明書の目的は自治体がその印鑑の持ち主を証明することだ。

図1　電証明書は印鑑証明と性質が似ている

　印鑑証明書の内容は、

1. 登録された印鑑の印影
2. その印鑑の持ち主の情報
3. 印鑑証明書を発行した自治体名
4. その自治体の印

といったものだろう。

　この「登録された印鑑」を「公開鍵」に、「発行自治体」を「認証局」に読み替えたものが電子証明書だと思ってよいだろう。つまり、電子証明書の中身はざっと以下のようなものということになる。

1. 登録された公開鍵
2. その公開鍵の持ち主の情報
3. 証明書を発行した認証局の情報
4. 発行元認証局の署名

　電子証明書の詳細なフォーマットについては、ITU-T（国際電気通信連合——電気通信標準化部門）が定めたX.509という規格に沿ったものが広く使用されている。

画面1　証明書の内容をInternetExplorerで表示させたところ（画面をクリックすると拡大表示します）

信頼の基盤としての認証局

　よくありがちな誤解が、「電子証明書を持っている＝信頼できる」というものである。しかし、電子証明書の発行自体はパソコン1台で簡単にできてしまう。つまり、電子証明書を発行することはだれにでもできてしまうのである。

　ちょっとここで電子証明書というものがなぜ必要なのかおさらいしてみよう。

　公開鍵暗号方式の場合、公開鍵はどのような方法で配布してもよく、だれが知っていても問題はない。ただ、公開鍵で暗号化されたものは、ここで1つ問題がある。例えばAさんがBさんと暗号メッセージのやりとりを行う必要があり、電子メールでBさんから公開鍵を受け取ったとする。しかし、その公開鍵を送ってきたのが本当にBさんであるかどうかを検証することができないのである。

　もしかしたらCさんがBさんに成りすましてCさんの公開鍵を送っているかもしれない。そうすると、AさんがBさんあてに送付した暗号文をCさんが読めてしまうことになる。そこで、AさんとBさんの双方が信頼できる認証局から証明書を発行してもらい、それをもってAさんが受け取った公開鍵が本当にBさんのものであることを証明するのである。

　ここで重要なのは「AさんとBさんがともに認証局を信頼できること」である。

　例えば、その認証局において、CさんがBさんに成りすましてBさんとしての証明書を受け取ってしまうことができるようなら、AさんもBさんもその認証局を信頼することができない。

　つまり、PKIにおいて認証局とは「信頼の基盤」となるものなのだ。

認証局の果たす役割

　「信頼の基盤」として認証局が行わなければならないことは非常に多い。

　例えば、証明書には認証局の署名がされていると書いたが、これは認証局の鍵をだれかが盗んでしまうと、その認証局に成りすましていくらでも証明書を発行できることを意味している。このため、認証局は自分の秘密鍵を非常に強固に守る必要がある。また、先に述べたように第三者に成りすましたものへの証明書の発行を行わないよう、十分な本人確認も必要だし、第三者が勝手に証明書発行オペレーションを行えないよう、オペレーションルームへの厳重な入退室管理も必要だろう。さらに証明書発行に関する記録も改ざんされないように記録しなければならない。

　このような認証局運用のガイドラインというものがいくつかあるが、日本では電子商取引推進協議会（ECOM）が発表している「認証局運用ガイドライン」（ここよりダウンロード可能）が分かりやすいだろう。

　また、このような認証局の信用にかかわるような運用方針は、認証局が「認証局運用規程（CPS：Certificate Practice Statement）」としてまとめ、公開することが多い。認証局から証明書の発行を受けようと思う人や、受け取った証明書が信頼できるものかどうか判断したい人は、この運用規程を読むことによってその判断を行うことができるようにするためだ。

認証局の階層

　それでは、ある証明書が確かにそこに記述されている認証局から発行されているものであるかどうかはどのように検証したらよいのだろうか。

　先ほど、「証明書には認証局の署名がされている」と書いた。そうなのだ。その署名を検証すればよいのだ。署名を検証するためには認証局の公開鍵が必要なのはもうお分かりだろう。ということは認証局の証明書というものが……実は存在するのである。では、その証明書を発行するのはいったいだれなのだろうか。

　これには以下の2つの方法がある。

1. その認証局が自分で発行する
2. さらに上位の認証局が存在し、その認証局が発行する

　上記2の場合でも、結局その根本をたどっていくと1の方式で証明書を発行した認証局が存在する。このような認証局を「ルート（Root）認証局」という。そのような認証局の証明書には、その認証局自身の署名がされている。このような証明書を「自己署名（Self-Sign)がされた証明書」という。

　InternetExplorerなどのWebブラウザにはあらかじめいくつかの認証局の証明書がインプリメントされている。InternetExplorerで「『ツール』メニュー→『インターネットオプション』→『コンテンツ』タブの証明書ボタン」を押してみてほしい。ここでは、いまこのWebブラウザで使用できる証明書が表示される。この中の「信頼されたルート証明機関」というタブを見てみると、多くの証明書が表示されているはずだ（画面2）。これは、これらの認証局はすべてルート認証局であり、あらかじめブラウザに「信頼する認証局」として登録されていることを示している。

画面2　InternetExplorer上で使用可能な証明書を表示させたところ（画面をクリックすると拡大表示します）

　例えば、このうちのいずれか1つの証明書を選択し、ダブルクリックしてみよう（画面3）。この証明書は「発行元」と「発行先」が同じだということが分かるだろう。今度は「中間証明機関」というタブを見てほしい。ここでも、いくつかの証明書が表示されるはずだ（画面4）。同じようにそのうちの1つをダブルクリックしてみよう。今度は、その証明書の「発行元」と「発行先」が異なっているはずだ（画面5）。さらに、この「発行元」は「信頼されたルート証明機関」に名前があるはずだ。これは、この認証局はさらに上位のルート認証局から証明書の発行を受けた認証局であることを示している。ちなみに、認証局から証明書の発行を受け、それをインストールすると「個人」タブからほかの人の証明書がもらえ、それをインストールすると「他人」タブからその情報を見ることができる。

画面3　「信頼された証明機関」一覧にある証明書の詳細を見たところ。発行先と発行元が同じだということが分かる（画面をクリックすると拡大表示します）

画面4　画面2のダイアログボックスで中間証明機関タブを選択して一覧を表示したところ（画面をクリックすると拡大表示します）

画面5　「中間証明機関」による証明書は、発行先と発行元が異なる。証明書の発行元は、画面2の一覧にある「信頼された証明機関」のものであることが分かる（画面をクリックすると拡大表示します）

Webブラウザに実装された認証局の証明書

　さて、少し話はそれてしまうが、もう一度このInternetExplorerに認証局の証明書があらかじめ実装されていることの意味を考えてみよう。それはすなわち、このブラウザのユーザー、つまりあなたがこれらの認証局をすでに信頼しているということになるのだ。

　実際にどのようなことが起こるのだろうか？ 例えばブラウザとサーバの間でSSLのセッションを張ろうとする場合、クライアント側にはそのWebサーバの証明書が送られてくる。もちろん、このWebサーバの証明書が信頼できる認証局から発行されたものでなければ、このサーバが本当に自分が意図して接続しようとしている相手に間違いがないのかを検証することができない。しかし、このサーバの証明書があらかじめブラウザに登録された認証局から発行されたものであれば、信頼できる認証局から発行された証明書として処理をするのだ。もしこのサーバ証明書を発行した認証局があらかじめブラウザに登録されたものでなければ、ブラウザは「このサーバ証明書を発行した認証局は信頼できるかどうか分からないが、処理を継続するか」というダイアログボックスを表示する。

ルート認証局と信頼のモデル

図2　認証局の階層構造

　話を証明書の階層に戻そう。図2を見てほしい。AさんがSub1、BさんがSub2という異なる2つの認証局から証明書の発行を受けていたとしよう。そして、この2つの認証局は、同じrootという認証局から認証されている（証明書を発行されている）とすると、AさんもBさんもroot認証局を信頼している必要がある。

　すると、結局AさんとBさんの間には、root認証局を信頼のベースとした信頼関係が成り立つのである。言い換えれば、信頼関係にある認証局から発行された証明書を持つ者同士には、やはり信頼関係が築かれるのである。

　ではAさんがBさんから証明書（公開鍵）を受け取ったら、Aさんはどのようにしてこれを検証していけばよいのだろうか。まず、AさんはBさんの証明書のほかにSub2認証局の証明書を受け取らなければならない。そして、Sub2認証局の証明書が自分の信頼するroot認証局から発行されていることをSub2認証局の証明書の署名を検証することで確認し、さらにBさんの証明書が確かにSub2認証局から発行されたものであることを、Bさんの証明書に付いている署名を検証して確認するのである。

証明書の廃棄

　認証局が行う重要な業務に、証明書の廃棄というものがある。例えば、証明書の発行を受けていたユーザーが、自分が発行を受けた証明書に対応する秘密鍵を盗まれてしまった場合などは、そのことを直ちに認証局に届け出て、証明書の廃棄処理を行わなければならない。認証局は、廃棄した証明書のリストを公開する。そうしないと、証明書を受け取った側が鍵を盗んだ人間をその秘密鍵の正規の持ち主だと思ってしまうからだ。

　証明書の廃棄情報の公開の仕方には、現在大きく分けて2種類が存在する。

1. CRL（Certificate Revocation List）の配布
2. OCSPレスポンダによる失効問い合わせへの応答

　1のCRLについては、やはりITU-Tがフォーマットを定めている。有効期限をまだ迎えていないが、何らかの理由で失効された証明書の情報が格納される。CRL自体はファイルの形で発行される場合がほとんどで、Webサーバ上に置かれてHTTPで配布してもよいし、ディレクトリサーバに格納してダウンロードさせてもよい。ただ、CRLにはいろいろと欠点がある。まず、証明書の有効性を確認したいアプリケーションが自分でCRLを取り込み、その中に確認したい証明書が入っていないかどうかを自分でサーチしなければならないのだ。さらに証明書の発行枚数が多い認証局であれば、当然廃棄される証明書の数も多くなり、CRL自体が大きくなる。アプリケーション側は証明書を提示されるたびにCRLをダウンロードしていたのでは、処理効率が落ちてしまう。そのため、通常は1日1回程度CRLを取り込み、その日はそのCRLを使用して証明書の有効性確認を行う、というような実装が現実的だろう。そうすると、CRLの発行とアプリケーション側への取り込みにタイムラグが発生し、結果として最新のCRLと検証に使用しているCRLの間に差異が生じる可能性がある。

　2のOCSPレスポンダは、上記のようなCRL配布の欠点をカバーするものとして考えられた。OCSPとは、Online Certificate Status Protocolの略で、証明書の失効問い合わせのためのプロトコルだ。証明書の提示を受けたアプリケーションは、その証明書の有効性をOCSPレスポンダに問い合わせる。OCSPレスポンダは自分が管理している失効リストにその証明書がないかどうかを確認し、アプリケーションに返答する。CRLがどちらかというとバッチ的に処理されるのに対し、OCSPは完全にオンライントランザクションの世界だ。

　上記2つのうちどちらを採用するかは、証明書の用途・廃棄がどの程度クリティカルか、アプリケーションの実装形態など、さまざまな要素を考慮して決定すべきだろう。