暗号と証明書

"証明書 - 公開鍵にデジタル署名する」。

自動車を運転するには、運転免許証が必要です。免許証には、顔写真、氏名、生年月日などの個人情報のほか、有効期限や運転できる車種などが記載されています。免許証には、有効期限や運転可能な車種などの個人情報のほか、公安局の印が押されています。この免許証を見れば、その人が自動車を運転する資格があると公安局が判断したことがわかります。

公開鍵証明書は、デジタル署名を付与するものです。公開鍵証明書を見ればすぐに、認証局がその公開鍵がその人のものであると判断したことがわかります。公開鍵証明書は、単に証明書とも呼ばれます。

認証局とは、「公開鍵がこの人のものである」と判断し、電子署名を生成できる個人や組織のことです。認証局には、国際機関や政府が設立した組織、認証サービスを提供することで利益を得ている一般企業などがあり、個人でも認証局を設立することができます。

証明書の応用シナリオ

ここでは、証明書の代表的な適用シナリオを通じて、証明書の役割を理解する方法を説明します。

次の図は、アリスがボブに暗号文を送り、その暗号文を生成するのに使われたボブの公開鍵が認証局を通して入手されるシナリオを示しています。

認証機関は信頼に足るものでなければなりません。「信頼される第三者」については、下図で「トレント」という名称が使われていますが、これは「信頼」という言葉に由来しています。

ここで、上の写真と照らし合わせながら、これらのステップが何をするのか、具体的に見てみましょう。

1. ボブは鍵ペアを生成します。

   Bobは公開鍵と秘密鍵のペアを生成し、秘密鍵は自分自身で安全に保管します。ここで、鍵ペアはBob自身が生成するか、認証局がBobに代わって生成することができます。

2. Bobは自分の公開鍵を認証局Trentに登録します。

   • これは、Bobが認証局Trentに自分の公開鍵の電子署名を依頼する必要があるためです。

   • TrentがBobの公開鍵を受け取ると、受け取った公開鍵がBob自身のものであることを確認します。

     コラム：本人確認と認証に関する運用ガイドライン

     私」の身元を確認する認証機関の方法は、認証機関の認証実施声明（CPS）の内容に関連しています。認証機関が試験サービスを提供している場合は、身元確認がまったくない場合があります。認証機関が政府部門によって運営されている場合は、身元確認を行うことが法律で義務付けられている場 合があります。内部使用のために組織によって設立された認証機関である場合は、部門長に電話で直接確認することがあります。

     たとえば、ベリサインの「Authentication Code of Practice」では、ID 確認を 3 つのクラス、クラス 1 ～ 3 に分類しています。

     • クラス1: メールボックスにメッセージを送信して身元を確認します。
     • クラス2：第三者データベースによる本人確認
     • Class3：対面認証・本人証明による本人確認

     ランクが上がるほど、識別は厳しくなります。

3. sha256-with-RSA-Encryption

4. AliceはBobの公開鍵と認証局Trentのデジタル署名を取得します。

   アリスはボブに暗号文を送る必要があるので、トレントから証明書を取得します。証明書にはボブの公開鍵が含まれています。

5. Aliceは認証局Trentの公開鍵を使ってデジタル署名を検証し、Bobの公開鍵の正当性を確認します。

   アリスは認証局トレントの公開鍵を使って証明書の電子署名を検証します。検証が成功すれば、証明書に含まれる公開鍵が本当にBobのものであることを確認するのと同じです。この時点でアリスは正当なボブの公開鍵を手に入れたことになります。

6. アリスはボブの公開鍵でメッセージを暗号化し、ボブに送ります。

   アリスは送信するメッセージをボブの公開鍵で暗号化し、ボブに送信します。

7. ボブは自分の秘密鍵で暗号文を解読し、アリスのメッセージを得ます。

   ボブはアリスから送られた暗号文を受け取り、自分の秘密鍵で復号し、アリスのメッセージを見ることができるようにします。

以上が、認証局 Trent を利用した公開鍵暗号通信の流れです。ステップ1,2,3は、公開鍵を新規に登録するときにだけ行うもので、 毎回の通信では必要ありません。また、ステップ4はアリスが初めて公開鍵暗号を使ってボブにメッセージを送るときだけ必要で、アリスのコンピュータにボブの公開鍵が保存されていれば、以後の通信で直接使うことができます。

証明書標準仕様 X.905

証明書は認証機関によって発行され、ユーザーはそれを検証する必要があるため、さまざまな形式があると不便です。そのため、証明書の標準仕様が開発され、最も広く使われているのがITUとISOが開発したX.509仕様です。多くのアプリケーションがx.509をサポートし、証明書の生成と交換の標準仕様として使用しています。

X.509は非常に一般的な証明書フォーマットです。すべての証明書はITU-T X.509国際標準に準拠しているため、あるアプリケーション用に作成された証明書は、他のX.509準拠のアプリケーションにも使用できます。X.509証明書は、ASN1（Abstract Syntax Notation One）を使用してデータ構造を記述する構造になっており、ASN.1構文を使用してエンコードされます。

証明書では、公開鍵とその所有者の名前が同じであることが証明されなければなりません。X.509証明書では、証明者は常にCAまたはCAによって指定された誰かです。X.509証明書は、ユーザーまたはデバイスとそれに対応する公開鍵に関する情報を含む標準的なフィールドの集まりです。

一般に、電子証明書のコンテンツには、基本データ、CA のデジタル署名などが含まれます。

証明書の仕様

最も広く使用されている標準は、X.509 バージョン v3 の ITU-ISO 合同仕様（RFC5280）であり、以下の証明書情報フィールドが定義されています：

• バージョン番号（Version Number）：仕様のバージョン番号で、現在はバージョン3で、値は0x2；

• シリアル・ナンバー：CA が発行する証明書ごとに割り当てられる列番号で、CA が管理し、証明書の追跡と失効に使用。発行者情報とシリアル番号さえあれば、証明書を一意に識別することができ、最大でも20バイトを超えることはありません；

• 署名アルゴリズム：以下のようなデジタル署名に使用されるアルゴリズム：

  • RSA暗号化付きsha256

  • ccdsa-with-SHA2S6；

• 有効期間：証明書の有効期間は、開始時刻と終了時刻を含め、非常に長い。

• サブジェクト公開鍵情報（SubJect Public Key Info）：保護される公開鍵に関連する情報：

  • 公開鍵アルゴリズム（Public Key Algorithm） 公開鍵に使われるアルゴリズム；
  • サブジェクト公開鍵：公開鍵の内容。
• X.509 DER(Distinguished Encoding Rules)サフィックス付きのエンコーディング：.der .cer .crt
• X.509 BASE64サフィックス付きのエンコーディング：.pem .cer .crt

• エクステンション：オプションのエクステンション。含まれる場合があります：

  • Subject Key Identifier (サブジェクト鍵識別子): エンティティの秘密鍵の識別子；
  • 基本制約：CAであるかどうかの表示。
  • Authority Key Identifier：証明書発行者の公開鍵識別子；
  • CRL 配布ポイント：失効文書が発行されたアドレス；
  • レイヤ 1 はルート証明書です。

さらに、証明書発行者は、証明書の内容が他者に改ざんされるのを防ぐために、自身の秘密鍵を用いて証明書の内容に署名を加える必要があります。

証明書フォーマット

X.509仕様では、証明書関連ファイルの保存にPEM（Privacy Enhanced Mail）形式の使用を一般的に推奨しています。証明書ファイルのファイル名拡張子は通常、.crt または .cer です。対応する秘密鍵ファイルのファイル名拡張子は通常.keyです。 証明書要求ファイルのファイル名拡張子は.csrです。ファイル名の接尾辞としてpemが使用されることもあります。

PEMフォーマットは保存にテキストを使用します。一般に、ヘッダーとフッターのタグとコンテンツブロックが含まれ、これらは Base64 でエンコードされます。

コーディング形式の概要。

• 拡張子が .pem .cer .crt の X.509 BASE64 エンコーディング

例えば、PEM形式の証明書ファイルのサンプルの内容を以下に示します：

-----BEGIN CERTIFICATE-----
MIIDyjCCArKgAwIBAgIQdZfkKrISoINLporOrZLXPTANBgkqhkiG9w0BAQsFADBn
MSswKQYDVQQLDCJDcmVhdGVkIGJ5IGh0dHA6Ly93d3cuZmlkZGxlcjIuY29tMRUw
EwYDVQQKDAxET19OT1RfVFJVU1QxITAfBgNVBAMMGERPX05PVF9UUlVTVF9GaWRk
bGVyUm9vdDAeFw0xNzA0MTExNjQ4MzhaFw0yMzA0MTExNjQ4MzhaMFoxKzApBgNV
BAsMIkNyZWF0ZWQgYnkgaHR0cDovL3d3dy5maWRkbGVyMi5jb20xFTATBgNVBAoM
DERPX05PVF9UUlVTVDEUMBIGA1UEAwwLKi5iYWlkdS5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDX0AM198jxwRoKgwWsd9oj5vI0and9v9SB9Chl
gZEu6G9ZA0C7BucsBzJ2bl0Mf6MSN0Iee1DfeydfEKyTmBKTafgb2DoQE3OHZjy0B
QTJrsOdf5s636W5gJp4f7CUYYA/3e1nxr/+AuG44Idlsi17TWodVKjsQhjzH+bK6
8ukQZyel1SgBeQOivzxXe0rhXzrocoeKZFmUxLkUpm+/mX1syDTdaCmQ6LT4KYYi
soKe4f+r2tLbUzPKxtk2F1v3ZLOjiRdzCOA27e5n88zdAFrCmMB4teG/azCSAH3g
Yb6vaAnKyDLGunW51sSesWBpHceJnMfrhwxCjiv707JZtAgMBAAGjfzB9MA4G
A1UdDwEB/wQEAwIEsDATBgNVHSUEDDAKBggrBgEFBQcDATAWBgNVHREEDzANggsq
LmJhaWR1LmNvbTAfBgNVHSMEGDAWgBQ9UIffUQSuwWGOm+o74JffZJNadjAdBgNV
HQ4EFgQUQh8IksZqcMVmKrIibTHLbAgLRGgwDQYJKoZIhvcNAQELBQADggEBAC5Y
JndwXpm0W+9SUlQhAUSE9LZh+DzcSmlCWtBk+SKBwmAegbfNSf6CgCh0VY6iIhbn
GlszqAqVMxAEDlR/YJTOlAUXFw8KICsWdvE01xtHqhk1tCK154Otci60Wu+tz
1t8999GPbJskecbRDGRDSA/gQGZJuL0rnmIuz3macSVn6tH7NwdoNeN68Uj3Qyt5
orYv1IFm8t55224ga8ac1y90hK4R5HcvN71aIjMKrikgynK0E+g45QypHRIe/z0S
/1W/6rqTgfN6OWc0c15hPeJbTtkntB5Fqd0sfsnKkW6jPsKQ+z/+vZ5XqzdlFupQ
29F14ei8ZHl9aLIHP5s=
-----END CERTIFICATE-----

証明書内の解析された内容：

Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number:
 10:e6:fc:62:b7:41:8a:d5:00:5e:45:b6
 Signature Algorithm: sha256WithRSAEncryption
 Issuer: C=BE, O=GlobalSign nv-sa,=GlobalSign Organization Validation CA-SHA256-G2
 Validity
 Not Before: Nov 21 08:00:00 2016 GMT
 Not After : Nov 22 07:59:59 2017 GMT
 Subject: C=US, ST=California, L=San Francisco, O=Wikimedia Foundation, Inc.,=*.wikipedia.org
 Subject Public Key Info:
 Public Key Algorithm: id-ecPublicKey
 Public-Key: (256 bit)
 pub: 
 04:c9:22:69:31:8a:d6:6c:ea:da:c3:7f:2c:ac:a5:
 af:c0:02:ea:81:cb:65:b9:fd:0c:6d:46:5b:c9:1e:
 ed:b2:ac:2a:1b:4a:ec:80:7b:e7:1a:51:e0:df:f7:
 c7:4a:20:7b:91:4b:20:07:21:ce:cf:68:65:8c:c6:
 9d:3b:ef:d5:c1
 ASN1 OID: prime256v1
 NIST CURVE: P-256
 X509v3 extensions:
 X509v3 Key Usage: critical
 Digital Signature, Key Agreement
 Authority Information Access: 
 CA Issuers - URI:http://..com/cacert/.crt
 OCSP - URI:http://..com/gsorganizationvalsha2g2
 X509v3 Certificate Policies: 
 Policy: 1.3.6.1.4.1.
 CPS: https://..com/repository/
 Policy: 2.23..2
 X509v3 Basic Constraints: 
 CA:FALSE
 X509v3 CRL Distribution Points: 
 Full Name:
 URI:http://..com/gs/.crl
 X509v3 Subject Alternative Name: 
 DNS:*.wikipedia.org, DNS:*.m.mediawiki.org, DNS:*.m.wikibooks.org, DNS:*.m.wikidata.org, DNS:*.m.wikimedia.org, DNS:*.m.wikimediafoundation.org, DNS:*.m.wikinews.org, DNS:*.m.wikipedia.org, DNS:*.m.wikiquote.org, DNS:*.m.wikisource.org, DNS:*.m.wikiversity.org, DNS:*.m.wikivoyage.org, DNS:*.m.wiktionary.org, DNS:*.mediawiki.org, DNS:*.planet.wikimedia.org, DNS:*.wikibooks.org, DNS:*.wikidata.org, DNS:*.wikimedia.org, DNS:*.wikimediafoundation.org, DNS:*.wikinews.org, DNS:*.wikiquote.org, DNS:*.wikisource.org, DNS:*.wikiversity.org, DNS:*.wikivoyage.org, DNS:*.wiktionary.org, DNS:*.wmfusercontent.org, DNS:*.zero.wikipedia.org, DNS:mediawiki.org, DNS:w.wiki, DNS:wikibooks.org, DNS:wikidata.org, DNS:wikimedia.org, DNS:wikimediafoundation.org, DNS:wikinews.org, DNS:wikiquote.org, DNS:wikisource.org, DNS:wikiversity.org, DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wmfusercontent.org, DNS:wikipedia.org
 X509v3 Extended Key Usage: 
 TLS Web Server Authentication, TLS Web Client Authentication
 X509v3 Subject Key Identifier: 
 28:2A:26:2A:57:8B:3B:CE:B4:D6:AB:54:EF:D7:38:21:2C:49:5C:36
 X509v3 Authority Key Identifier: 
 keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C
 Signature Algorithm: sha256WithRSAEncryption
 8b:c3:ed:d1:9d:39:6f:af:40:72:bd:1e:18:5e:30:54:23:35:
 ...

CA

証明書とは、何かが確かに何かであることを証明するためのものです。平たく言えば、証明書は上記の公印のようなものです。公印によって、対応する文書の真正性を証明することができます。

理論的には、誰もが証明書ツールを見つけて、自分で証明書を作ることができます。では、悪者が証明書を作って人を騙すのをどうやって防ぐのでしょうか？続くCAの紹介をご覧ください。

CAはCertificate Authorityの略で、「認証局センター」とも呼ばれます。

CA は、あたかも信頼できる仲介者のように、証明書の管理と発行に責任を負う第三者機関です。一般的に言って、CA はすべての業界およびすべての一般市民から信頼され、認知されていなければなりません。したがって、十分な権限を持たなければなりません。A社とB社が公印の仲介者としてC社を利用する前に、C社を信頼しなければならないようなものです。

• CA 証明書

  CA証明書はその名の通り、CAが発行する証明書です。

  すでに述べたように、証明書を作る道具は誰でも手に入れることができます。しかし、小さなゴロツキであるあなたが作った証明書は何の役にも立ちません。なぜなら、あなたは権威あるCAオーソリティではないからです。

  例えば、ある悪人が自分の公印を彫って紹介状に押すんです。しかし、それが信頼できる機関の公印でないことがわかると、他の人はそれを無視します。悪人の企みは成功しません。

• 信頼の連鎖

  証明書は直接的な信頼関係を持つことができ、それによってある証明書は別の証明書も真正で信頼できることを証明することができます。 実際、証明書間の信頼関係は入れ子にすることができます。例えば、CがA1を信頼し、A1がA2を信頼し、A2がA3を信頼する......。これを証明書の信頼の連鎖と呼びます。チェーン内の最初の証明書を信頼する限り、後続の証明書も信頼できます。

  Cがその証明書でAとBを信頼し、AはA1とA2を信頼し、BはB1とB2を信頼するとすると、両者は次のようなツリー関係を形成します。

  

  一番上、ツリーの根元にある証明書が「ルート証明書」です。ルート証明書以外の証明書は、自分自身を証明するために上位の証明書に頼らざるを得ません。では、誰が「ルート証明書」の信頼性を証明するのでしょうか。実は、ルート証明書が信頼できることを証明するのは、ルート証明書自身なのです。

  ルート証明書は、証明書システム全体のセキュリティの根幹です。したがって、証明書システム、ルート証明書の問題が発生した場合、ルート証明書によって信頼される他のすべての証明書は、もはや信頼できなくなります。

• 証明書の意味は？

  1. ウェブサイトが信頼できるかどうか

     通常、特定の機密性の高いウェブページを閲覧する場合、プロトコルはHTTPではなくHTTPSを使用します。 HTTPプロトコルは平文であるため、悪者があなたのウェブ通信を盗み見た場合、彼/彼女はウェブ通信の内容を見ることができます。一方、HTTPSは暗号化されたプロトコルであるため、悪者があなたの通信を盗み見ることはできません。

     しかし、HTTPSプロトコルは暗号化されているから安全だとは思わないでください。暗号化だけでは十分でないことを示すために、別の例を挙げましょう。インターネットバンキングの偽サイトを作って、あなたをこのサイトに誘い込んだ悪者がいたとします。あなたが比較的単純で、注意を払わないと仮定して、口座番号とパスワードを入力します。そうすれば、悪者の陰謀は成功します。

     悪者がこのようなことをしないように、HTTPSプロトコルには暗号化メカニズムに加えて証明書メカニズムがあります。証明書は、サイトが本当にサイトであることを保証します。

     証明書では、ブラウザが HTTPS サイトにアクセスすると、そのサイトの CA 証明書を検証します。ブラウザが証明書に問題がないと判断した場合、ページが開きます。そうでない場合、ブラウザはサイトの証明書に問題があるという警告を表示します。以下は、IEとFirefoxがどのように見えるかを図式化したものです：

     

     

     HTTPSプロトコルを使用している有名なウェブサイトのほとんどは、信頼できる証明書を持っています。ですから、今後、有名なウェブサイトにアクセスし、ブラウザに上記の警告が表示されたら、注意が必要です！

  2. 文書が信頼できるかどうかの確認

     証明書は、特定のウェブサイトを確認するだけでなく、ファイルが改ざんされていないことを確認するためにも使用できます。具体的には、証明書はファイルのデジタル署名を作成するために使用されます。デジタル署名を作成するプロセスは専門的すぎるので、ここでは省略します。ファイルの電子署名を検証する方法は、後で説明します。ほとんどの人がWindowsを使っていることを考慮して、Windowsの例を取り上げます。

     例えば、手元にGoogle Chromeのインストールファイルがあります。そのファイルのプロパティを見ると、以下のようなインターフェースになっています。よく見える人なら、「デジタル署名」タブがあることに気づくでしょう。このタブが表示されない場合、そのファイルはデジタル署名されていないことを意味します。

     

     通常、署名リストには1つの署名しかありません。それを選択し、「詳細」ボタンをクリックします。以下の画面が表示されます：

     通常、この画面には「このデジタル署名は正常です」という行が表示されます。この行がある場合、ファイルは工場からあなたに改ざんされていないことを意味します。ファイルが改ざんされている場合は、ダイアログボックスに「デジタル署名は無効です」という警告が表示されます。

     

     署名が正しいかどうかにかかわらず、「証明書を表示」ボタンをクリックできます。この時、証明書のダイアログボックスがポップアップします。ダイアログボックスは以下の通りです：

     

     

     後者の画面では、先ほど説明した証明書の信頼の連鎖を見ることができます。図の信頼の連鎖には3つの層があります：

     • キー・ペアの生成
     • レイヤー2は、シマンテックが署名専用に使用する証明書です。
     • レイヤー3はGoogle独自の証明書です。

     現在、実行ファイルをリリースしている有名企業のほとんどは、実行ファイルにデジタル署名を施しています。自分でチェックしてみてください。

     ソフトウェアをインストールする際には、まずそのソフトウェアが電子署名されているかどうかを確認することをお勧めします。もしそうであれば、上記の手順で確認してください。デジタル署名が悪ければ、インストールしないでください。

公開鍵基盤

公開鍵の実用化には、証明書の仕様だけでは不十分で、誰が証明書を発行するのか、どのように証明書を発行するのか、秘密鍵が漏えいしたときにどのように証明書を失効させるのか、コンピュータ間のデータ交換にどのような形式を用いるのかなど、多くの仕様が必要です。ここでは、公開鍵をより効果的に利用するための公開鍵基盤について紹介します。

公開鍵基盤（PKI）とは

公開鍵基盤（PKI）とは、公開鍵をより効率的に使用できるようにするために開発された一連の規範と仕様の総称です。公開鍵基盤は一般に、英語の頭文字をとってPKIと略されます。

PKI は単なる包括的な用語であり、単一の仕様や規格を指すものではありません。たとえば、RSA が開発した PKCS 仕様シリーズも PKI の一種であり、Internet Specification RFC には多くの PKI 関連文書があります。さらに、X.509 などの仕様も PKI の一種です。さまざまな企業によって作成され、PKI プログラムの開発で使用される API や仕様も、PKI 関連の仕様と見なすことができる。

その結果、使用される特定の仕様によってPKIには多くのバリエーションがあり、これが多くの人がPKI全体を理解するのに苦労する理由の1つとなっています。

PKI 全般を理解していただくために、PKI の基本的な構成要素と、業務を担当する認証局を簡単にまとめます。

PKIPKI の構成要素

PKIには3つの主要コンポーネントがあります：

• 利用者 - PKI を使用する人
• 認定機関 - 認定証を発行する機関
• リポジトリ -- 証明書が保管されるデータベース

利用者

ユーザとは、アリスやボブのようにPKIを利用する人のことです。ユーザには、自分の公開鍵をPKIに登録したいユーザと、すでに登録されている公開鍵を使いたいユーザの2種類があります。この2種類のユーザが行う操作を具体的に見てみましょう。

• 公開鍵を登録したユーザーによるアクション

  • キー・ペアの生成
  • デジタル署名の検証
  • 認証機関への証明書申請
  • 必要に応じて登録公開鍵の失効申請
  • 受信した暗号文の復号
  • メッセージのデジタル署名

• 登録された公開鍵を持つユーザーによるアクション

  • メッセージを暗号化して受信者に送信
  • デジタル署名の検証

  /* 
  ==================== ヒント ==================== 
  ブラウザでSSL証明書を検証する方法
  1. Internet Explorerのメニューから「ツール/インターネットオプション」をクリックする。”，コンテンツ」を選択する。”タブで「証明書」をクリックする。”ボタンをクリックすると、IE
   ブラウザはすでに多くの「中間認証局」を信頼している。”信頼されたルート認証局」は、「信頼されたルート認証局」と同じである。サイトを訪問する際、ブラウザ
   サイトのSSL証明書を自動的にダウンロードし、証明書の安全性をチェックする。
  2. 証明書はレベル分けされているため、ウェブサイトの所有者は、ルート認証局から証明書を受け取るか、ルート証明書の次のレベル（国など）から証明書を受け取ることができる。
   SSLを使用する認証センターから証明書を取得したい場合や、都道府県が発行した証明書を取得したい場合は、そうすればよい。SSL技術を使用しているウェブサイトを訪問しており、インターネット・エクスプローラ（IE）がコンピュータ上で動作しているとする。
   ブラウザはSSL証明書を受け取り、この証明書がルート認証局から発行されたものである場合、Internet Explorerは以下の手順に従う。
   チェック：ブラウザは、内蔵ルート証明書の公開鍵を使用して、受信した証明書を認証する。
   SSL証明書がルート・サーバーによって発行されていない場合、ブラウザはSSL証明書がルート・サーバーによって発行されているかどうかを自動的にチェックする。
   対応するルート認証局を見つけるまで、発行局の上位レベルをチェックし、ルート認証局が信頼できる場合、このサイトのSSL証明書
   本書は信頼できるものでもある。
  */
  

認証局

認証局は、証明書を管理する人です。上図ではトレントという名称が与えられており、認証局が実行する具体的なアクションは以下のとおりです：

• キー・ペアの生成

  鍵ペアの生成には、PKI 利用者自身による方法と、認証局による方法の 2 通りがあります。認証局がユーザー鍵ペアを生成する場合、認証局はユーザーに秘密鍵を送信する必要があり、PKCS#12 などの仕様を使用する必要があります。

• 公開鍵登録時の本人認証、証明書の生成・発行

  利用者自身が鍵ペアを生成する場合、利用者は認証局に証明書の生成を依頼します。証明書を要求するための仕様はPKCS#10で定義されています。

  認証局は、その認証業務ガイドラインに従って利用者の身元を認証し、証明書を生成します。証明書を生成する際には、認証局の秘密鍵を電子署名に使用する必要があります。生成される証明書の形式は、PKCS#6 および X.509 で定義されています。

• 証明書の取り消し

  ユーザの秘密鍵が紛失または盗難された場合、認証局は証明書を失効させる必要があります。また、秘密鍵が無事であったとしても、秘密鍵の使用権の喪失に起因する会社からの離職や、証明書の内容が証明書の内容と一致しないことに起因する改名など、証明書を失効させる必要がある場合もあります。

  紙の証明書は、限り、彼らは破れているとして無効にすることができますが、ここで証明書は、デジタル情報である、それが倉庫から削除された場合でも、ユーザが証明書のコピーを保存するため、無効にすることはできませんが、認証局は、ユーザのコンピュータによって侵略することはできません削除されたコピーされます。

  証明書を失効させるには、認証局がCRL==と呼ばれる証明書失効リスト（Certificate Revocation List）を作成する必要があります。

  CRL とは、認証局によって失効が宣言された証明書のリストであり、具体的には、認証局によって電子署名された、失効した証明書のシリアル・ナンバーのリストです。証明書シリアル・ナンバーは、証明書を発行する際に認証局から与えられた番号で、証明書に記録されています。

  PKI利用者は、認証局から最新のCRLを入手し、公開鍵証明書の署名が無効になっているかどうかを確認する必要があります。

  手元にボブの証明書があると仮定すると、証明書は、正当な認証機関の署名を持っており、また、有効期間が、これらだけでは証明書が有効でなければならないことを示すことはできませんが、また、認証機関の最新のCRLを確認する必要があり、証明書が有効であるかどうかを確認します。一般的に言えば、このチェックは、ユーザー自身によって行われないが、完了するには、ソフトウェアの証明書によって処理されるべきであるが、ソフトウェアの多くは、タイムリーな方法で、より機能的なCRLを持っていません。

認証局、公開鍵登録、個人識別認証の各業務を登録局（RA）で分担できます。これにより、認証局は証明書の発行に専念でき、認証局の負担が軽減されます。ただし、RA の導入には、認証局が RA 自体を認証する必要があることや、構成要素が増えることで 通信プロセスも複雑になり、攻撃ポイントの脆弱性も増大するなどのデメリットもあります。

倉庫

リポジトリとは、PKI ユーザーが必要なときに証明書を取り出すことができる、証明書のデータベースです。電話をかけるときの電話帳のようなものです。この章の最初の例では、特に言及されていませんが、アリスはボブの証明書を取得するときにリポジトリを使うことができます。リポジトリは証明書カタログとも呼ばれます。

さまざまな種類のPKI

PKIという名称は、「公開鍵には権威ある認証局が1つしかない」とか、「世界中の公開鍵は最終的にルートCAによって認証される」といった誤解を常に引き起こしますが、実はこれは誤りです。認証局は公開鍵に電子署名をするだけでよいので、誰でも認証局になることができ、実際、世界にはすでに無数の認証局が存在します。

国、地方自治体、病院、図書館などの公的機関や団体は、認証局を設立してPKIを導入することができ、企業もビジネス上の必要性から社内でPKIを導入することができます。

企業内利用の場合、認証機関の階層は、前項のように企業の組織階層と一対一に対応する場合もあれば、対応しない場合もあります。例えば、東京、大阪、北海道、九州に支店がある場合、各支店が相互に認証し合う仕組みを採用することも可能です。認証局の運用については、PKIを構築するためのソフトウェア製品を購入し、自社で運用することも可能ですし、ベリサインなど外部の認証サービスを利用することも可能です。具体的にどのような方法をとるかは、目的や規模によって異なり、一定のルールはありません。