前のページ 目次 次のページ

最終更新日:2005年 2月 1日


3.4  PKI の運用

3.4.1  運用ポリシー(CP/CPS)

CA は、信頼の基盤となるものなので、正しく運用される必要があります。そのため、CA を運用する際には、証明書の利用目的を定める証明書ポリシー (CP: Certificate Policy) と、CA の運用方法を定める認証実施規定 [47] (CPS: Certification Practice Statement) を規定します。CP と CPS のガイドラインは 、RFC 3647 において「情報提供 (Informational)」として公表されています [48]

表 3-8 CP と CPS の違い

種類

説明

証明書ポリシー(CP)

証明書の目的や利用用途を規定するものです。CP は、証明書の拡張領域に OID 形式で記載されます。

認証局運用規定(CPS)

CA の運用規定を定めたものです。CA のシステムや運用手順を明示的な文書にして、証明書に記載された URI などで利用者に公開します。

なお「CPS のセキュリティレベルに関する詳細な内容を、非公開とするか/一般に公開するか」は、CA のポリシーによって異なります。

3.4.2  秘密鍵(プライベート鍵)のセキュリティ

公開鍵暗号方式における秘密鍵(プライベート鍵)は、漏洩しないように厳重に保管する必要があります。秘密鍵(プライベート鍵)をセキュアに保管するために、スマートカード(IC カード)などの専用のハードウェアに格納する方法があり、このハードウェアは、「PKI  トークン」と呼ばれます。「PKI トークン」には秘密鍵(プライベート鍵)と証明書を格納することができます。秘密鍵(プライベート鍵)を使った復号や署名などの演算は、「PKI トークン」内で行われ、秘密鍵(プライベート鍵)が「PKI トークン」から出ないようになっています(図 3-10、図 3-11)。

図 3-10 スマートカードを用いたデジタル署名

図 3-11 スマートカードを用いたネットワーク認証

「PKI トークン」を使うことによって、以下の利点が生じます。

(1)  秘密鍵(プライベート鍵)は、トークンから読み出せないため、外部に漏洩する危険性が減少します。

(2)  秘密鍵(プライベート鍵)の持ち運びが可能になるため、可用性が向上します。

「PKI トークン」の紛失や盗難などに対応するため、PKI トークンを使用する際には PIN (パスワード)などによって利用者を認証します。より厳密な本人確認を行うために、最近ではパスワードだけではなく、指紋などのバイオメトリクス認証を取り入れた PKI トークンも登場しています。バイオメトリクスを利用する場合でも、生体情報は PKI トークン内に格納されるため、利用者の心理的負担が小さくなると考えられます [49]

利用者が「PKI トークン」にアクセスするための規格を以下に示します(表 3-9)。

表 3-9 PKI トークンのインターフェース

種類

説明

PKCS #11

Netscape 社の製品等で採用されています。

CryptoAPI

Microsoft 社の製品で採用されています。

CA の秘密鍵(プライベート鍵)を保護するためには、ハードウェア セキュリティ モジュール(HSM) とよばれる「PKI トークン」を利用します。HSM は、より高いセキュリティを備えており、複数の管理者が秘密鍵を分割して所有し、それぞれが揃わないと使用できないようにする機能などを持っています。

暗号モジュールのセキュリティレベルの評価基準として、NIST において規定された FIPS140-2 があります。FIPS140-2 においては、セキュリティレベルを 4段階で評価します。

3.4.3  Dual Key Pair

RSA 公開鍵暗号方式では、一つの鍵ペアを暗号化と署名の両方に利用できます。しかし、暗号化と署名では、鍵ペアに求められる要件が異なります(表 3-10)。

表 3-10 鍵ペアに求められるセキュリティ

用途

説明

暗号化

1つしか存在しない秘密鍵が破損・紛失した場合、以前に暗号化されたデータも失われてしまいます。そのため秘密鍵のバックアップが必要になる場合もあります。

秘密鍵(プライベート鍵)をバックアップする場合、暗号化されたデータを不正に見られないために、鍵を安全に管理する必要があります。

署名

否認防止の機能が求められるため、鍵のバックアップは推奨されません。秘密鍵(プライベート鍵)を複製すると、署名行為を否認する根拠を与えてしまいます。秘密鍵(プライベート鍵)が破損・紛失した場合は、新しい鍵ペアを生成して、新しい証明書を発行することが望まれます。以前の秘密鍵による署名は、公開鍵のみを保存しておくことで検証できます。

このため、暗号化に用いる鍵ペアと署名に用いる鍵ペアを別々に用意し、それぞれの鍵に対して証明書を発行する方式が用いられます。この方式をデュアル鍵ペア(Dual Key Pair) といいます。暗号化や署名などの証明書の利用目的は、証明書拡張領域の鍵利用 (keyUsage)フィールドに記載します。

なお、公開鍵暗号方式に DSA アルゴリズムを用いた場合は署名機能しかもたず、暗号化用に DH アルゴリズムなどと組み合わせて使用する必要があるため、必然的にデュアル鍵ペア方式となります。

3.4.4  証明書ライフサイクル

証明書のライフサイクルを以下に示します(図 3-12)。

図 3-12 証明書ライフサイクル

(1)  証明書の発行

証明書を生成して、PKI ユーザに配布するまでのフェーズです。

(2)  証明書の利用

発行された証明書を PKI ユーザが利用するフェーズです。

(3)  証明書の破棄・更新

期限切れや失効などの理由で、証明書の利用を終了するフェーズです。

引き続き PKI を利用する場合は、証明書の更新を行います。

以下では、それぞれのフェーズを個別に解説します。

3.4.5  証明書発行

証明書の発行プロセスには、大別して 2つのモデルがあります。ひとつは加入者(証明書の被発行者)が鍵ペアを生成する方式(図 3-13)であり、もうひとつは RA が一括して鍵ペアを生成する方式(図 3-14)です。

これらのモデルは、用途に応じて使い分けられます。

図 3-13 証明書発行(ユーザ鍵生成モデル)

 

図 3-14 証明書発行(センタ一括鍵生成モデル)

証明書発行の流れは、以下のようになります。

(1)  本人確認

CA または RA は、加入者に対して本人性の確認を行います。要求される本人確認レベルは、CP および CPS に定められた証明書の利用用途と運用ポリシーによって異なります。

(2)  鍵ペア生成

加入者(Subscriber)もしくは RA が鍵ペア(公開鍵と秘密鍵のペア)を生成します。PKI トークンを利用する場合は、PKI トークン内で鍵ペアを生成する方法と、安全な暗号生成装置で生成した鍵ペア及び証明書を後から格納する方法があります。

(3)  申請

加入者が RA に対して、証明書の発行申請を行います。PKCS#10 などの申請書には、加入者の名前やメールアドレスなどの情報と公開鍵が含まれます。

CA または RA は、送付された公開鍵が加入者のものであることを何らかの方法で確認します [50]

(4)  発行

CA は確認した申請内容に対して署名を施し、証明書を発行します。

(5)  配布

発行した証明書を利用者に配布します。鍵ペアを RA で生成した場合は、秘密鍵も一緒に配布します。あるいは証明書を格納した PKI トークンを安全な方法で配布します。

(6)  公開

証明書の利用者がその証明書を参照できるように、CA は発行した証明書をリポジトリに登録します。(リポジトリが存在する場合に限ります。)

証明書発行に使用する代表的なプロトコルには、以下の種類があります(表 3-11)。

表 3-11 証明書発行に使用するプロトコル

プロトコル

説明

PKCS#10, PKCS#7

要求に PKCS#10、発行に PKCS#7 を使用する方法です。初期の PKI で利用されました。

Certificate Management Protocol (CMP)

様々な PKI システム間で使用される、証明書管理に関する通信プロトコルです。CRMF [51] と呼ばれるフォーマットを採用しており、証明書発行、更新、失効、鍵回復などの様々な機能が含まれます。CMP の仕様は RFC 4210 で定められています。

Certificate Management using CMS (CMC)

PKCS #7 を改良した CMS を用いて証明書の管理を行う方法です。PKCS#10 や CRMF を用いた証明書要求も使用することができます。CMC の仕様は、RFC 2797 で定められています。

 

3.4.6  証明書の利用

発行された証明書を利用するフェーズです。

(1)  取得

公開されているリポジトリなどから証明書を取得します。詳細は 6章にて解説します。

(2)  有効性検証

取得した証明書が信頼できるものであることを確認します。

(3)  証明書利用

証明書を使って暗号化や署名検証を行います。具体的な PKI アプリケーションは、7章にて解説します。

(4)  鍵回復

秘密鍵を破損 [52] してしまうと、暗号化したデータが読めなくなってしまいます。このような場合、センターにバックアップしておくことで、秘密鍵を復旧させることが可能です。ただし、バックアップする秘密鍵は、暗号目的のものに限るべきです。利用者の否認防止の効果が無くなるため、署名目的の秘密鍵はバックアップするべきではありません。

証明書の有効性を検証する手順を以下に示します(図 3-15)。

図 3-15 証明書の有効性検証

署名の検証やデータの暗号化のために取得した証明書は、使用する前にその証明書の有効性を検証する必要があります。有効性検証は、「認証パスの構築」と「認証パスの検証」の 2段階で行われます。

「認証パスの構築」では、対象となる証明書が信頼している CA と関係あることを確認します。利用者が信頼している CA のことを、「ルート CA」または「信頼点(トラストアンカー)」といいます。対象となる証明書を発行した CA (図 3-15 では下位 CA2)がルート CA ではなく他の CA の子となっている場合 [53] は、ルート CA に到達するまで上位の CA をたどっていきます。図では頂点の CA (トップ CA)がルート CA なので、それぞれの証明書の発行者(issuer)フィールドをたどり「加入者」→「下位 CA2」→「下位 CA1」→「トップ CA」が繋がっていることを確認します。このような信頼点までの認証チェーンを「認証パス」と呼びます。

「認証パスの検証」では、認証パスのルート CA から対象となる証明書までの全ての証明書に対して、以下の検証を行います。

これら全ての検証が成功した場合にはじめて、対象となる証明書が信頼できることが分かります。

3.4.7  証明書の破棄・更新

発行された証明書は、有効期限切れや失効によって破棄されます。

(1)  期限切れ

証明書には有効期間が設定されており、終了時刻 (notAfter) フィールドに設定された時刻を越えると、証明書は無効になってしまいます。これを証明書の期限切れといいます。

(2)  失効

秘密鍵の漏洩や証明書の記載内容の変更などの理由で、有効期間内であっても証明書の信頼性が保たれなくなる場合があります。この場合、CA は、その証明書を無効であることを証明書の利用者に通知します。これを証明書の失効といいます。失効については、4章で詳しく解説します。

期限切れや失効によって証明書が破棄されたあとでも、デジタル署名の検証を行うために、証明書を保存しておく場合があります。

(3)  更新

証明書の期限切れ後も引き続き証明書を利用する場合は、有効期限切れとなる前に鍵ペアを再生成し、証明書の更新手続きを行います。証明書が破棄された後で更新を行うと、全く新規に発行する場合と同様の手続きが必要となってしまいます。証明書が有効であれば、その証明書を使って本人認証を行うことができるので、オンライン(ネットワーク経由)で更新が行えます。

CA の証明書が期限切れとなる場合、CA は証明書が期限切れとなる前に新しい鍵ペアを生成し、その鍵ペアを使って新しい証明書を発行します(図 3-16)。

図 3-16 CA証明書の更新

新旧 2枚の CA 証明書が存在する期間は、それぞれの CA 証明書をトラストアンカーとする利用者が存在します。古い CA 証明書をトラストアンカーとする利用者が、新しい CA から発行された証明書を検証できるように、CA は 、新しい公開鍵に古い秘密鍵(署名鍵)で署名した証明書 (NewWithOld) と、古い公開鍵に新しい秘密鍵で署名した証明書 (OldWithNew) を発行します(図 3-17)。NewWithOld や OldWithNew などの証明書をリンク証明書といいます。

図 3-17 CA証明書の移行

リンク証明書を使った証明書の有効性検証方法を解説します。

A. 古い CA 証明書を信頼する利用者が、CA が新たに発行した証明書の有効性を検証する場合。

A-1. 古い CA 証明書( OldWithOld)で NewWithOld を検証します。

A-2. NewWithOld で新しい CA 証明書 (NewWithNew) を検証します。

B. 新しい CA 証明書を信頼する利用者が、CA が発行した古い証明書の信頼性を検証する場合。

B-1.新しい CA 証明書 (NewWithNew) で OldWithNew を検証します。

B-2. OldWithNew で古い CA 証明書 (OldWithOld) を検証します。

このようにして、2つの CA 証明書が存在する期間において、どちらの証明書の利用者も。その有効性の検証を行うことができます。


前のページ 目次 次のページ Copyright © 2002 Information-technology Promotion Agency, Japan. All rights reserved.