公開鍵基盤

暗号技術において、公開鍵基盤は公開鍵暗号方式や電子署名方式で用いる公開鍵とその公開鍵の持ち主の対応関係を保証するための仕組みである。公開鍵認証基盤、公開鍵暗号基盤とも呼ばれる。

PKIの実現例として、たとえばX.509がある。

1. 概要
-----

インターネットのような電子的な通信路を介して通信を行う際、通信の安全性を確保するための技術として、公開鍵暗号方式や電子署名方式がある。これらの技術では通信相手の公開鍵を用いることで送信する文書を暗号化したり、文章に対する署名を検証したりすることで、文章の秘匿性や真正性を保証する。

これらの技術を使う際には、暗号化や署名検証で用いた公開鍵が通信相手のものであることを事前に確認する必要がある。なぜなら、もしこの確認がなされていないと、たとえば、不正者が通信相手の公開鍵を偽の公開鍵とすりかえるなりすましなどの攻撃が可能になってしまうからである。

しかし、公開鍵とその持ち主との対応関係を確実に保証するのは容易ではない。インターネットは基本的に匿名の通信路であるので、公開鍵の所有者と名乗っている人物が本当に所有者当人であるのかを知るのは容易ではないからである。

PKIは、公開鍵とその持ち主の対応関係を認証局という第三者機関を用いて保証するための技術である。

各認証局Aは自身の公開鍵pksubを公開しており、この公開鍵pksubとそれに対応する秘密鍵を用いることで、PKIの利用者や団体、他の認証局などの公開鍵pksubとその所有者名Bの組に対する署名文certsubを作成する。この署名文certsubを、公開鍵pksubの所有者がBであることを保証する公開鍵証明書という。

PKIの各利用者Cは、自身が最も信頼できると思われる認証局Zの公開鍵を事前に何らかの方法で入手しておく。この認証局Zの公開鍵pksubは、PKIにおける全ての信頼関係の起点となるので、認証局ZをCのトラストアンカーという。

PKIの利用者Cが別の利用者Dの公開鍵pksubが本当にDのものであることを確認するには、pksubに対する公開鍵証明書certsubを入手する。次に、この公開鍵証明書certsubを発行した認証局Eの公開鍵pksubと、pksubに対する公開鍵証明書certsubとを入手する。以下同様に繰り返し、最後にトラストアンカーの認証局Zにたどり着き、しかもそれまでに入手した公開鍵証明書が署名文として正当なものであれば、公開鍵pksubをDの公開鍵として受理し、そうでなければ棄却する。

以上がPKIの基本的な仕組みである。PKIには、この他にも公開鍵を失効するための仕組みや利用者の属性を証明する仕組みなどが備わっている。

2. 認証局
------

認証局は公開鍵証明書などの電子証明書を発行するエンティティである。

2.1. 運用ポリシー
-----------

各認証局は証明書の利用目的を定める証明書ポリシーと、CA の運用方法を定める認証実施規定を規定する。

2.2. 信頼モデル
----------

認証局同士の信頼関係のモデルを信頼モデルという。様々な組織が様々な信頼モデルに基づいて認証局を運用しているが、代表的な信頼モデルとして以下のものがある。

単独モデルは1つの認証局が全てのユーザに証明書を発行するモデルであり、企業内の認証局などユーザ数が小規模な場合に用いられる。

階層型モデルは複数の認証局がツリー型の階層構造をなすモデルであり、WebモデルはWebブラウザなどのクライアントアプリケーションに予め認証局の一覧を埋め込むモデルである。

メッシュモデルは階層構造を持たない認証局が相互に認証しあうモデルであり、異なる運用ポリシーを持つ「CAドメイン」の間を横断して接続する際に使われる。メッシュモデルでは異なるCAドメインにある認証局同士が相互に認証しあう相互認証でつながりあう。相互認証で用いられる証明書を相互認証証明書という。

ブリッジCAモデルは認証局同士がブリッジCAという認証局を通して接続するモデルである。メッシュモデルと同じく異なるCAドメイン間を結びつけるときに用いるが、各認証局が相互に認証しあうメッシュモデルと違い、各認証局は1つのブリッジCAとのみ相互認証する。これにより認証局1↔}}ブリッジCA↔}}認証局2というブリッジCAを媒介とした信頼関係が形成される。認証局の数が多い場合、認証局同士が直接相互認証するメッシュモデルでは相互認証の数が膨大になるが、ブリッジCAモデルではブリッジCAを媒介としたスター型のトポロジーの相互認証が形成されるのみなので、認証パスの数を減らすことができるという利点がある。

2.3. ルート認証局
-----------

ルート認証局とは上位の認証局の認証を受けず、自分の正当性を自分で証明する認証局のことで、階層型モデルにおけるツリーの頂点に位置する認証局やWebモデルでアプリケーションに事前に登録されている認証局がこれに相当する。この二種類のルート認証局を区別するため、Webモデルのルート認証局をパブリックルート認証局と呼ぶことがある。ルート認証局以外の認証局は中間認証局と呼ぶ。

ルート認証局はPKIの信頼の起点であるトラストアンカーとして機能する。いずれかのCAドメインに属するルート認証局をトラストアンカーとして採用すれば、そのCAドメインと相互認証されている他のCAドメインの認証局の証明書も、相互認証を介してトラストアンカーまでたどり着くことができる。

3. 電子証明書
--------

電子証明書とは公開鍵証明書をはじめとした、認証局が発行する証明書のことである。電子証明書の標準としてX.509が広く採用されている。X.509に従って作成された電子証明書は、X.509証明書と呼ばれる。

3.1. 電子証明書の種類
-------------

X.509証明書には次の3種類がある。公開鍵とその所有者の対応関係を証明する公開鍵証明書、公開鍵証明書で証明された人が所有する権限や役割を証明する属性証明書、自然に対して発行することを目的とした適格証明書がある。単に証明書といった場合は公開鍵証明書を指すことが多い。

公開鍵証明書には認証局に対して発行するCA証明書とPKIのユーザに対して発行されるエンドエンティティ証明書がある。CA証明書の特殊なものとして、認証局が自身の秘密鍵で署名した自己署名証明書がある。

暗号用の公開鍵と署名検証用の公開鍵は別のものを用いることが多く、このためこれら２つの公開鍵に別々の公開鍵証明書を発行することが多い。このような方法をデュアル鍵ペア方式という。

認証局が他の認証局に証明書を発行する場合などでは、相手を完全に信用するのではなく、証明書の拡張領域に条件を記載することで条件付きの信頼関係を構築することも可能である。

3.2. 公開鍵証明書の発行
--------------

公開鍵証明書を発行する際、主に2つの作業を行う。1つ目は新しく証明書を発行してほしいエンティティの本人確認などの登録手続きで、2つ目は加入者に実際に公開鍵証明書を発行することである。

この２つの手続きをいずれも認証局が行う運用形態もあるが、２つの手続きを別の機関で運用する運用形態もあり、この場合登録手続きを行う機関を登録局、証明書発行手続きを行う機関を発行局という。

ただし「発行局」という言葉は実際にはあまり使われていず、発行局のことを「認証局」と呼ぶことが多い。本稿でも、以下では発行局を認証局と呼ぶことにする。

証明書の発行手順は以下のとおりである。まず加入者は自身が用いる公開鍵・秘密鍵ペアの生成と登録局における本人確認とを行う。

次に加入者は登録局に証明書の発行申請を行い、登録局は認証局に証明書の発行を依頼する。認証局は申請書を確認したあと証明書を発行し、登録局経由で証明書を加入者に配布する。

認証局はPKIの他の利用者が加入者の証明書を見つけやすいよう、加入者の証明書をリポジトリに公開する。

上では加入者が自分で鍵ペアの生成するケースを説明したが、企業が全新入社員を加入者として一括登録するようなケースでは登録局である企業の側が全員分の鍵ペアを生成して各加入者に鍵ペアを配布する事も有り得る。この場合登録局が加入者に証明書を配布する際、一緒に秘密鍵も配布する。

3.3. 他の利用者の公開鍵証明書の入手
--------------------

PKIの利用者Aが別の利用者Bの公開鍵証明書を入手する方法として、利用者Bから電子メールなどの手段を用いて公開鍵証明書を送ってもらうというものがある。これをアウトオブバンドの送信方法という。

また公開鍵暗号や電子署名を利用する通信プロトコルの一部として公開鍵証明書の送信方法が組み込まれている場合があり、こうした通信プロトコルにしたがって利用者Bから公開鍵証明書を送信してもらう方法をインバンドな送信方法という。インバンドで公開鍵証明書を送信するプロトコルとしてS/MIME、PGP、TLSなどがある。

利用者Bから直接証明書を送ってもらうのではなく、多数の利用者の証明書を保存しているリポジトリからBの証明書を受け取る方法もある。リポジトリの実装方法に関しては様々なものがあり、いくつかはRFCになっている。具体的にはLDAPやX.500のようなディレクトリ・サービスを利用したもののほか、FRPやHTTPを使ったもの、DNSを使ったものがある。

3.4. 公開鍵証明書の更新
--------------

公開鍵証明書には有効期限が定まっており、この有効期限を超えた期限切れの証明書は無効になってしまう。

そこでPKIの利用者は証明書の期限が切れる前に新しい鍵ペアを生成し、新しい鍵ペアに対する証明書を発行してもらう必要がある。この作業を証明書の更新という。

更新時には古い鍵ペアを使って認証局から認証を受ける事ができるので、新しい証明書の発行の際にはネットワーク越しに更新手続きを行うことができる。

更新手続きを行ってから古い証明書が有効期限切れになるまでの間は、新旧両方の証明書がある事になる。この新旧の証明書を関連付けるため、リンク証明書という証明書を認証局から発行してもらう。リンク証明書にはNewWithOld、OldWithNewなどの証明書がある。NewWithOldは古い鍵ペアを使って作成した新しい公開鍵に対する証明書で、OldWithNewは逆に新しい鍵ペアを使って作成した古い公開鍵に対する証明書である。

利用者Aの古い公開鍵とその証明書をすでに所有している利用者Bは、利用者Aの新しい公開鍵とともにNewWithOld証明書を受け取る事で新しい公開鍵の真正性を確認できる。これにより利用者Bは利用者Aが新しい鍵ペアで署名した署名文の正当性を検証する事ができる。

逆に利用者Aの新しい公開鍵とその証明書をすでに所有している利用者Cは、利用者Aの古い公開鍵とともにOldWithNew証明書を受け取る事で古い公開鍵の真正性を確認できる。これにより利用者Cは利用者Aが古い鍵ペアで署名した署名文の正当性を検証する事ができる。

3.5. 公開鍵証明書の失効
--------------

自身が保有する秘密鍵が漏洩した場合や、退職等により署名権限失った場合には、まだ期限が切れていない公開鍵証明書を無効化する必要がある。このための手続きを公開鍵証明書の失効という。

失効した証明書のリストの管理は認証局自身が行う場合と証明書の有効性検証に特化した組織が行う場合があり、後者の場合その組織を検証局という。

証明書が失効しているか否かを確認する方法としてCRLとOCSPがある。

3.5.1. CRL
----------

CRL'//はすでに失効した公開鍵証明書のリストである。各利用者がこのリストを確認することで公開鍵の失効状況を確認ができる。//

CRLの発行者は多くの場合証明書を発行した認証局自身であり、CRLにはその真正性を示すため発行者の署名が付与されている。

CRLはリポジトリという公開サーバに格納し、PKIの利用者はこのサーバにアクセスすることでCRLを入手できる。

CRLの中には、認証局の失効情報に特化したものが存在し、これを認証局失効リストという。

CRLは定期的に更新され、新しい失効情報がCRLに随時載っていく。しかし利用者が証明書の失効を申請してからCRLが更新されるまでタイムラグが生じるという問題を抱える。そこでCRLの定期更新より早い頻度で最後の更新が行われてからの差分情報が公開することがある。この差分情報をデルタCRLという。

CRLの運用形態にはいくつかある。完全CRLは全ての失効情報を１つのCRLに記載する方法であるが、失効情報の数が大きくなるとCRL取得の負荷が大きくなる。

区分CRLでは失効情報を複数のCRLに分割する。区分CRLを用いるには証明書発行の段階で、その証明書が失効した場合に失効情報がどのCRLに載るかという情報を証明書に記載しておく。PKIの利用者はCRLDPを頼りにして、リポジトリから必要な区分CRLを取得する。

またPKI利用者の利便性を高めるため、様々な認証局が発行したCRLを別のCRL発行者が１つにまとめて配布する場合があり、このようなCRLを間接CRLという。

3.5.2. OCSP
-----------

OCSPは証明書の失効状況の確認を実現するプロトコルであり、RFC 6960に規定されている。

この方法ではOCSPレスポンダというサーバに証明書が失効しているかどうかの情報が一括管理されている。証明書の失効状況を知りたい利用者がOCSPレスポンダに失効情報の問い合わせを行うと、OCSPレスポンダは「有効」、「失効」、「不明」のいずれかを返す。この際返答内容に対するOCSPレスポンダの署名文も同時に送信する。

失効情報をOCSPレスポンダで管理するため、認証局は失効情報をOCSPレスポンダに送信する必要がある。その際の送信プロトコルに規定はないが、CRLの形で失効情報を認証局から得たり、OCSPのプロトコルにしたがって認証局に失効情報を確認したりする。

またOCSPレスポンダとOCSPリクエスタの間の通信のレイヤに関しても規定がないが、HTTP、SMTP、LDAPなどが使われる。

4. 日本の行政機関におけるPKI
-----------------

政府認証基盤は日本政府が運用するPKIであり、全省庁共通の政府共用認証局、政府認証基盤の外にある認証局と相互認証するためのブリッジ認証局、および国民や企業に配る文書やプログラムにつける署名に対する証明書を発行するアプリケーション認証局から構成される