公開鍵暗号入門

公開鍵暗号と関連する標準および技術は、署名付きメールや暗号化されたメール、シングルサインオン、SSL (Secure Sockets Layer) 通信など、多くの製品のセキュリティ機能の根底にあります。このドキュメントでは、公開鍵暗号の基本的な概念を紹介します。SSL の概要については、"SSL 入門" を参照してください。暗号化と復号化の概要については、"暗号化と復号化" を参照してください。電子署名に関する情報は、"電子署名" を参照してください。

公開鍵暗号は、盗聴、改ざん、なりすましなどの攻撃から通信を保護するための確立された技術と標準のセットです。

  • 暗号化と復号化により、2 つの通信相手がお互いに送信する情報を偽装することができます。送信者は情報を送信する前に暗号化 (スクランブル) します。受信者は情報を受信した後、情報を復号化 (スクランブル解除) します。送信中は、暗号化された情報は侵入者には理解できません
  • いたずら検出により、情報の受信者は、情報が転送中に変更されていないことを確認することができます。データを変更したり、偽のメッセージを正当なものに置き換えようとする試みはすべて検出されます
  • 認証を行うことで、情報の受信者は情報の出所を特定することができ、つまり送信者の身元を確認することができます
  • 否認防止は、情報の送信者が後日、その情報が送信されなかったことを主張することを防止します

以下のセクションでは、これらの機能の根底にある公開鍵暗号の概念を紹介します。

証明書と認証

証明書は誰かを識別するもの

証明書は、個人、サーバ、会社、またはその他のエンティティを識別し、その ID を公開鍵と関連付けるために使用される電子文書です。運転免許証、パスポート、またはその他の一般的に使用される個人 ID のように、証明書は、一般的に認識されている個人の身元を証明するものです。公開鍵暗号化は、なりすましの問題に対処するために証明書を使用します。

運転免許証を取得するには、通常、免許証を発行する前にあなたの身元、運転する能力、あなたの住所、およびその他の情報を確認する自動車局などの政府機関に申請します。学生証を取得するには、学校や大学に申請し、ID を発行する前に異なるチェック (授業料を支払っているかどうかなど) を行います。図書館のカードを取得するには、あなたの名前とそれにあなたの住所が記載された公共料金の請求書のみを提供する必要がある場合があります。

証明書は、これらの身近な身分証明書とほとんど同じように機能します。認証局 (CA) は、本人確認を行い、証明書を発行する機関です。認証局は、独立した第三者であるか、または独自の証明書発行サーバソフトウェア (Red Hat 証明書システムなど) を実行している組織のいずれかとなります。ID を検証するために使用される方法は、特定の CA のポリシーによって異なります。一般に、証明書を発行する前に、CA は、証明書を要求するエンティティが実際に本人であると主張していることを確認するために、そのタイプの証明書について公表されている検証手順を使用しなければなりません。

認証局が発行する証明書は、特定の公開鍵を、証明書が識別するエンティティの名前 (従業員やサーバの名前など) にバインドします。証明書は、なりすましのための偽の公開鍵の使用を防ぐのに役立ちます。証明書によって認証された公開鍵のみが、証明書によって識別されたエンティティが所有する対応する秘密鍵と連携します。

証明書には、公開鍵に加えて、証明書が識別するエンティティの名前、有効期限、証明書を発行した CA の名前、シリアル番号、およびその他の情報が常に含まれています。最も重要なことは、証明書には、発行した CA の電子署名が常に含まれていることです。CAの電子署名により、証明書は、CAを知っていて信頼しているが、証明書で識別されるエンティティを知らないユーザーのための "紹介状" として機能することができます。

CA の役割の詳細については、"信頼を確立するための CA 証明書の使用方法" を参照してください。

アイデンティティを確認する認証

認証とは、身元を確認するプロセスです。ネットワーク相互作用の文脈では、認証には、ある当事者が別の当事者によって自信を持って識別されることが含まれます。ネットワーク上での認証は、多くの形式をとることができます。証明書は、認証をサポートする一つの方法です。

ネットワーク上の相互作用は通常、パーソナル・コンピュータ上で実行されるブラウザ・ソフトウェアなどのクライアントと、Web サイトをホストするために使用されるソフトウェアやハードウェアなどのサーバとの間で行われます。クライアント認証とは、サーバがクライアントを確信を持って識別すること (すなわち、クライアントソフトウェアを使用していると想定される人物を識別すること) を意味します。サーバ認証とは、クライアントがサーバを確信を持って識別すること (つまり、特定のネットワークアドレスでサーバの責任者と想定される組織を識別すること) を意味します。

証明書がサポートする認証の形式は、クライアント認証とサーバ認証だけではありません。例えば、メール・メッセージの電子署名は、送信者を識別する証明書と組み合わせて、その証明書で識別された人物が実際にそのメッセージを送信したことを示す強力な証拠となります。同様に、HTML フォームへの電子署名を、署名者を識別する証明書と組み合わせることで、その証明書によって識別された人物がフォームの内容に同意したことを、事後的に証明することができます。認証に加えて、どちらの場合も電子署名はある程度の否認防止を保証します。つまり、電子署名は、署名者が後でメールやフォームを送信しなかったと主張することを難しくします。

クライアント認証は、ほとんどのイントラネットやエクストラネット内のネットワークセキュリティの重要な要素です。以下のセクションでは、2 つの形式のクライアント認証を対照的に説明します。

  • パスワードベースの認証。ほとんどすべてのサーバソフトウェアは、名前とパスワードによるクライアント認証を許可しています。例えば、サーバは、サーバへのアクセスを許可する前にユーザに名前とパスワードの入力を要求することがあります。サーバは名前とパスワードのリストを管理しています。特定の名前がリストにあり、ユーザが正しいパスワードを入力すると、サーバはアクセスを許可します
  • 証明書ベースの認証。証明書に基づくクライアント認証は、SSLプロトコルの一部です。クライアントはランダムに生成されたデータに電子署名を行い、証明書と署名されたデータの両方をネットワーク経由で送信します。サーバは公開鍵暗号技術を用いて署名を検証し、証明書の有効性を確認します。

パスワードベースの認証

図4は、名前とパスワードを使用してクライアントを認証する際の基本的な手順を示しています。図4では、以下のように想定しています。

  • ユーザーは、認証を行わずに、あるいは SSL によるサーバ認証に基づいて、サーバを信頼することをすでに決めています
  • ユーザーはサーバが管理するリソースを要求しました
  • サーバは、要求されたリソースへのアクセスを許可する前にクライアント認証を要求します

Figure 4. Using a Password to Authenticate a Client to a Server

これらは、図4に示すようなステップです。

  1. サーバからの認証要求に応答して、クライアントは、そのサーバのユーザーの名前とパスワードを要求するダイアログボックスを表示します。ユーザーは、作業セッション中に使用したい新しいサーバごとに、名前とパスワードを個別に入力する必要があります
  2. クライアントは、ネットワーク上で名前とパスワードを送信します。クリアまたは暗号化されたSSL接続のいずれかの方法を使用することができます
  3. サーバは、ローカルのパスワードデータベースから名前とパスワードを検索し、それらが一致する場合は、ユーザーの身元を認証する証拠としてそれらを受け入れます
  4. サーバは、特定されたユーザが要求されたリソースへのアクセスを許可されているかどうかを判断し、許可されていればクライアントにアクセスを許可します

この方式では、ユーザはサーバごとに新しいパスワードを提供しなければならず、管理者は各ユーザの名前とパスワードを、通常は別々のサーバに管理しなければなりません。

適切な実装では、パスワードは平文では保存されません。その代わりに、パスワードとユーザごとのランダムな値 (いわゆる「ソルト」) を連結し、その結果のハッシュ値をソルトと一緒に格納します。これにより、ある種のブルートフォース攻撃がより困難になります。

次のセクションで示すように、証明書ベースの認証の利点の1つは、図4の最初の3つのステップの代わりに、ユーザが (ネットワークを越えて送信されない) 1つのパスワードを供給するだけで、管理者がユーザ認証を集中的に制御できますようにするメカニズムを使用できますことです。

証明書ベースの認証

図 5 は、証明書と SSL プロトコルを使用したクライアント認証の仕組みを示しています。ユーザをサーバに認証するために、クライアントはランダムに生成されたデータに電子署名を行い、証明書と署名されたデータの両方をネットワーク経由で送信します。ここでは、データに関連する電子署名は、クライアントがサーバに提供した証拠と考えることができます。サーバは、この証拠の強度に基づいてユーザの身元を認証します。

図 4 と同様に、図 5 では、ユーザがすでにサーバを信頼することを決めてリソースを要求しており、サーバが要求されたリソースへのアクセスを許可するかどうかを評価する過程でクライアント認証を要求していると仮定しています。

Figure 5. Using a Certificate to Authenticate a Client to a Server

図 4 に示す処理とは異なり、図 5 に示す処理では、SSL を使用する必要があります。図 5 はまた、クライアントがサーバに対してクライアントを識別するために使用できます有効な証明書を持っていることを前提としています。証明書ベースの認証は、一般的にパスワードベースの認証よりも、ユーザが持っているもの (秘密鍵) だけでなく、ユーザが知っているもの (秘密鍵を保護するパスワード) に基づいているため、好ましいと考えられています。しかし、この 2 つの仮定が真であるのは、不正な人がユーザのマシンまたはパスワードにアクセスしていない場合、クライアントソフトウェアの秘密鍵データベースのパスワードが設定されている場合、およびソフトウェアが合理的な頻度でパスワードを要求するように設定されている場合のみであることに注意することが重要です。

パスワードベースの認証も証明書ベースの認証も、個々のマシンやパスワードへの物理的アクセスに関連するセキュリティ問題には対応していません。公開鍵暗号は、あるデータに署名するために使用される秘密鍵が証明書の公開鍵と一致していることを確認することしかできません。マシンの物理的なセキュリティを保護し、秘密鍵のパスワードを秘密にしておくのはユーザの責任です。

これらは、図5に示すようなステップです。

  1. Communicator などのクライアントソフトウェアは、そのクライアントのために発行された証明書で公開されている公開鍵に対応する秘密鍵のデータベースを保持しています。クライアントは、クライアントが特定のセッション中に初めてこのデータベースにアクセスする必要があるとき、例えば、証明書ベースのクライアント認証を必要とする SSL 対応サーバにアクセスしようとするときなどに、このデータベースへのパスワードを要求します。このパスワードを一度入力すると、他の SSL 対応サーバにアクセスする場合でも、残りのセッションではパスワードを再度入力する必要はありません
  2. クライアントは秘密鍵データベースのロックを解除し、ユーザ証明書の秘密鍵を取得し、その秘密鍵を使用して、クライアントとサーバの両方からの入力に基づいてランダムに生成されたデータに電子署名を行う。このデータと電子署名は、秘密鍵の有効性の「証拠」を構成します。電子署名はその秘密鍵でのみ作成することができ、SSL セッションに固有の署名データに対して対応する公開鍵で検証することができます
  3. クライアントは、ユーザーの証明書と証拠 (電子署名されたランダムに生成されたデータの一部) の両方をネットワーク経由で送信します
  4. サーバは証明書と証拠を使ってユーザの身元を認証します。(この仕組みの詳細については、「SSL 入門」を参照してください)
  5. この時点で、サーバはオプションとして、クライアントから提示された証明書が LDAP ディレクトリのユーザのエントリに格納されているかどうかを確認するなど、他の認証タスクを実行することができます。その後、サーバは、識別されたユーザが要求されたリソースへのアクセスを許可されているかどうかの評価を続けます。この評価プロセスでは、LDAP ディレクトリや企業データベースなどの追加情報を使用して、さまざまな標準的な認証メカニズムを使用することができます。評価の結果が肯定的であれば、サーバはクライアントが要求されたリソースへのアクセスを許可します

図 5 と図 4 を比較するとわかるように、証明書は、クライアントとサーバ間の相互作用の認証部分を置き換えます。シングルサインオンでは、ユーザはネットワーク全体にパスワードを送信する必要がありますが、シングルサインオンでは、ネットワーク全体にパスワードを送信することなく、秘密鍵データベースのパスワードを一度だけ入力する必要があります。残りのセッションでは、クライアントは、新しいサーバに遭遇するたびに、ユーザを認証するためにユーザの証明書を提示します。認証されたユーザ ID に基づく既存の認証メカニズムは影響を受けません。

証明書の使用用途

証明書には、信頼を確立するという目的があります。証明書の使用法は、どのような信頼を保証するために使用されるかによって異なります。証明書には、発表者の身元を確認するために使用されるものもあれば、オブジェクトやアイテムが改ざんされていないことを確認するために使用されるものもあります。

SSL プロトコル

SSL (Secure Sockets Layer) プロトコルは、サーバ認証、クライアント認証、サーバとクライアント間の暗号化された通信を管理する一連のルールです。SSL はインターネット上で広く使用されており、特にクレジットカード番号などの機密情報の交換を伴うやり取りに使用されています。

SSL は最低でもサーバの SSL 証明書を必要とします。最初の「ハンドシェイク」プロセスの一部として、サーバはサーバの身元を認証するためにクライアントに証明書を提示します。この認証プロセスでは、公開鍵暗号化と電子署名を使用して、サーバが実際にサーバであると主張していることを確認します。サーバが認証されると、クライアントとサーバは、非常に高速な対称鍵暗号化技術を使用して、セッションの残りの間に交換するすべての情報を暗号化し、発生した可能性のある改ざんを検出します。

サーバは、オプションで、サーバ認証だけでなくクライアント認証を必要とするように構成することができます。この場合、サーバ認証が正常に完了した後、暗号化された SSL セッションを確立する前に、クライアントは証明書をサーバに提示してクライアントの身元を認証しなければなりません。

SSL を利用したクライアント認証の概要や、パスワードベースの認証との違いについては、"アイデンティティを確認する認証" を参照してください。SSL の詳細については、"SSL 入門" を参照してください。

署名されたメールと暗号化されたメール

一部のメールプログラムは、Secure Multipurpose Internet Mail Extension (S/MIME) として広く受け入れられているプロトコルを使用して、電子署名および暗号化されたメールをサポートしています。メールメッセージに署名または暗号化するために S/MIME を使用するには、メッセージの送信者が S/MIME 証明書を持っている必要があります。

電子署名を含むメールメッセージは、それが実際にメッセージヘッダーに名前が現れる人物によって送信されたものであることをある程度保証し、送信者の認証を提供します。電子署名が受信側のメールソフトで検証できない場合は、ユーザにアラートが表示されます。

電子署名は、それに付随するメッセージに固有のものです。受信したメッセージが、コンマの追加や削除によっても、送信されたメッセージと異なる場合は、電子署名を検証することはできません。したがって、署名されたメールは、メールが改ざんされていないことをある程度保証するものでもあります。この文書の冒頭で述べたように、この種の保証は否認防止として知られています。言い換えれば、署名付きメールは、送信者がメッセージを送信したことを否定することを非常に困難にします。これは、多くの形式のビジネスコミュニケーションにとって重要なことです。(電子署名の仕組みについては、「電子署名」を参照してください)。

S/MIME は、メールのメッセージを暗号化することも可能にします。これは、一部のビジネスユーザにとっても重要です。しかし、メールに暗号化を使うには慎重な計画が必要です。例えば、暗号化されたメールメッセージの受信者が秘密鍵を紛失し、鍵のバックアップコピーにアクセスできない場合、暗号化されたメッセージを復号化することはできません。

シングルサインオン

ネットワークユーザは、使用する様々なサービスのために複数のパスワードを覚えておく必要があります。例えば、ネットワークへのログイン、メールの収集、ディレクトリサービスの使用、会社のカレンダープログラムの使用、各種サーバへのアクセスなどのために、ユーザーは異なるパスワードを入力しなければならない場合があります。複数のパスワードは、ユーザーとシステム管理者の両方にとって継続的な頭痛の種です。ユーザーは異なるパスワードを追跡するのが難しく、不適切なパスワードを選択したり、明らかな場所にパスワードを書き留めたりする傾向があります。管理者は、各サーバ上の別個のパスワードデータベースを管理し、パスワードがネットワーク上で日常的に頻繁に送信されるという事実に関連した潜在的なセキュリティ問題に対処しなければなりません。

この問題を解決するには、ユーザが単一のパスワードを使用して一度ログインし、ユーザが使用を許可されているすべてのネットワークリソースに、ネットワーク上でパスワードを送信することなく、認証されたアクセスを得るための何らかの方法が必要です。この機能はシングルサインオンとして知られています。

クライアント SSL 証明書と S/MIME 証明書の両方が、包括的なシングルサインオンソリューションにおいて重要な役割を果たすことができます。例えば、シングルサインオンの1つの形態は、SSL クライアント認証に依存している ("証明書ベースの認証" を参照) 。ユーザはローカルクライアントの秘密鍵データベースに単一のパスワードを使って一度ログインし、ユーザが使用を許可されているすべてのSSL対応サーバへの認証済みアクセスを得ることができます (ネットワーク経由でパスワードを送信することなく) 。このアプローチでは、新しいサーバごとにパスワードを入力する必要がないため、ユーザーはアクセスを簡素化することができます。また、管理者は、ユーザとパスワードの長いリストではなく、認証局 (CA) のリストを管理することでアクセスを制御できますため、ネットワーク管理も簡素化されます。

証明書を使用することに加えて、完全なシングルサインオンソリューションは、パスワードやその他の形式の認証に依存している、基盤となるオペレーティングシステムなどのエンタープライズシステムとの相互運用の必要性に対処する必要があります。

オブジェクト署名

Communicator は、オブジェクト署名と呼ばれる一連のツールと技術をサポートしています。オブジェクト署名は、公開鍵暗号の標準的な技術を使用して、シュリンク包装されたソフトウェアについて信頼できます情報を得るのと同じように、ユーザーがダウンロードしたコードについて信頼できます情報を得ることができますようにします。

例えば、特定のエンティティによって署名された Java アプレットが特定のユーザのマシン上で特定のコンピュータ機能を使用することを許可するかどうかなどです。

オブジェクト署名技術で署名された「オブジェクト」は、アプレットや他の Java コード、JavaScript スクリプト、プラグイン、またはあらゆる種類のファイルである可能性があります。「署名」は電子署名です。署名されたオブジェクトとその署名は、通常、JAR ファイルと呼ばれる特別なファイルに格納されます。

オブジェクト署名技術を使用してファイルに署名したいソフトウェア開発者やその他の人は、まずオブジェクト署名証明書を取得しなければなりません。

証明書の種類

一般的な証明書の種類には、以下のようなものがあります。

  • クライアント SSL 証明書。SSL (クライアント認証) を介してサーバに対してクライアントを識別するために使用されます。通常、クライアントの身元は、企業の従業員などの人間の身元と同じであると仮定されます。クライアント SSL 証明書がクライアント認証に使用される方法については、"証明書ベースの認証" を参照してください。クライアント SSL 証明書は、シングルサインオンソリューションの一部として使用することもできます
例: 銀行が顧客にクライアント SSL 証明書を与え、銀行のサーバがその顧客を識別し、顧客の口座へのアクセスを許可するようにします。企業が新入社員にクライアント SSL 証明書を与えると、企業のサーバがその社員を識別し、企業のサーバへのアクセスを許可することができます。
  • サーバ SSL 証明書。SSL (サーバ認証) を利用して、サーバとクライアントを識別するために使用します。サーバ認証は、クライアント認証の有無にかかわらず使用できます。サーバ認証は、暗号化された SSL セッションの要件です。詳細については、"SSL プロトコル" を参照してください
例: 電子商取引 (一般的に電子商取引と呼ばれる) に従事するインターネットサイトは、暗号化された SSL セッションを確立し、顧客が特定の会社で識別された Web サイトを扱っていることを保証するために、通常、証明書ベースのサーバ認証を最低でもサポートしています。暗号化された SSL セッションは、ネットワーク上に送信されたクレジットカード番号などの個人情報を簡単に傍受できないようにします
  • S/MIME 証明書。署名された暗号化されたメールに使用されます。クライアントの SSL 証明書と同様に、クライアントの身元は通常、企業の従業員のような人間の身元と同じであると仮定されます。1つの証明書を S/MIME 証明書と SSL 証明書の両方として使用することができます ("署名されたメールと暗号化されたメール" を参照) 。S/MIME 証明書は、シングルサインオンソリューションの一部として使用することもできます
例: ある会社は、従業員の身元を認証する目的でのみ S/MIME 証明書とSSL証明書を組み合わせて導入し、署名付きメールとクライアントの SSL 認証を許可しているが、暗号化されたメールは許可していない。別の会社は、機密性の高い金融や法律問題を扱うメールの署名と暗号化の両方を目的としてのみ、S/MIME 証明書を発行しています。
  • オブジェクト署名証明書。Java コード、JavaScript スクリプト、その他の署名ファイルの署名者を識別するために使用します。詳細については、"オブジェクト署名" を参照してください
例: ソフトウェア会社は、インターネット上で配布されたソフトウェアに署名を行い、そのソフトウェアがその会社の正当な製品であることをユーザーに保証します。このように証明書やデジタル署名を使用することで、ダウンロードしたソフトウェアが自分のコンピュータにどのような種類のアクセスを持っているかをユーザーが識別し、制御することも可能になります。
  • CA 証明書。CA を識別するために使用されます。クライアントとサーバのソフトウェアは、CA 証明書を使用して、他のどの証明書が信頼できますかを判断します。詳細については、"信頼を確立するための CA 証明書の使用方法" を参照してください
例: Firefox に保存されている CA 証明書は、Firefox のコピーが認証できます他の証明書を決定します。管理者は、各ユーザの Firefox コピーに保存されている CA 証明書を制御することで、企業のセキュリティ ポリシーのいくつかの側面を実装することができます。

証明書の内容

証明書の内容は、国際標準化団体である国際電気通信連合 (ITU) が1988年から推奨している X.509 v3 証明書仕様に基づいて整理されています。

ユーザは通常、証明書の正確な内容を気にする必要はありません。しかし、証明書を扱うシステム管理者は、ここで提供される情報に精通している必要があるかもしれません。

証明書のデータ形式

証明書要求と証明書は、複数の形式で作成、保存、インストールすることができます。バイナリ形式とテキスト形式です。これらのフォーマットはすべて X.509 規格に準拠しています。バイナリ形式の例としては、DER エンコードされた証明書、PKCS #7 証明書チェーン、Netscape 証明書シーケンスの 3 つがあります。バイナリ形式のいずれも、行で始まるテキスト形式でインポートすることができます。

-----BEGIN CERTIFICATE-----

この行の後に続くのが証明書データで、説明されているバイナリ形式のいずれかである可能性があります。このデータは、RFC 1113 で説明されているように、base-64 でエンコードされている必要があります。証明書情報の後には、この行が続きます。

-----END CERTIFICATE-----

識別名

X.509 v3 証明書は、識別名 (DN) を公開鍵にバインドします。DN は、uid=doe のような一連の名前と値のペアであり、エンティティ、すなわち証明書のサブジェクトを一意に識別するものです。

例えば、これは例の会社の従業員の典型的な DN であるかもしれません。

uid=doe,e=doe@example.net,cn=John Doe,o=Example Corp.,c=US

この例の各等号の前の略語は、これらの意味を持ちます。

  • uid: ユーザー ID
  • e: メールアドレス
  • cn: ユーザの共通名
  • o: 組織
  • c: 国

DN には、他にもさまざまな名前と値のペアが含まれている場合があります。DN は、証明書のサブジェクトと LDAP (Lightweight Directory Access Protocol) をサポートするディレクトリのエントリの両方を識別するために使用されます。

DN の構築を支配するルールは非常に複雑であり、このドキュメントの範囲を超えています。DN に関する包括的な情報は、以下の URL の A String Representation of Distinguished Names を参照してください。

https://www.ietf.org/rfc/rfc1485.txt

典型的な証明書

すべての X.509 証明書は、2 つのセクションから構成されています。

  • データセクションには、以下の情報が含まれています
    • 証明書がサポートする X.509 規格のバージョン番号
    • 証明書のシリアル番号。CA が発行したすべての証明書には、その CA が発行した証明書の中で一意のシリアル番号があります
    • 使用されたアルゴリズムや鍵そのものの表現を含む、ユーザの公開鍵に関する情報
    • 証明書を発行した CA の DN
    • 証明書の有効期間(例えば、平成11年11月15日午後1時から平成12年11月15日午後1時まで)
    • 証明書のサブジェクトの DN (例えば、クライアント SSL 証明書の場合はユーザの DN) で、サブジェクト名とも呼ばれます
    • オプションの証明書拡張子は、クライアントまたはサーバが使用する追加データを提供することができます。例えば、証明書タイプの拡張子は証明書のタイプを示します。証明書の拡張子は、他にもさまざまな目的で使用することができます
  • 署名欄には、以下の情報が記載されています
    • 発行者である CA が独自のデジタル署名を作成するために使用する暗号アルゴリズム、または暗号
    • 認証局の電子署名は、証明書内のすべてのデータを一緒にハッシュ化し、認証局の秘密鍵で暗号化することで得られます

ここでは、証明書のデータ部分と署名部分を人間が読める形式で示しています。

Certificate:
Data:
 Version: v3 (0x2)
 Serial Number: 3 (0x3)
 Signature Algorithm: PKCS #1 MD5 With RSA Encryption
 Issuer: OU=Ace Certificate Authority, O=Ace Industry, C=US
 Validity:
  Not Before: Fri Oct 17 18:36:25 1997
  Not  After: Sun Oct 17 18:36:25 1999
 Subject: CN=Jane Doe, OU=Finance, O=Ace Industry, C=US
 Subject Public Key Info:
  Algorithm: PKCS #1 RSA Encryption
  Public Key:
   Modulus:
    00:ca:fa:79:98:8f:19:f8:d7:de:e4:49:80:48:e6:2a:2a:86:
    ed:27:40:4d:86:b3:05:c0:01:bb:50:15:c9:de:dc:85:19:22:
    43:7d:45:6d:71:4e:17:3d:f0:36:4b:5b:7f:a8:51:a3:a1:00:
    98:ce:7f:47:50:2c:93:36:7c:01:6e:cb:89:06:41:72:b5:e9:
    73:49:38:76:ef:b6:8f:ac:49:bb:63:0f:9b:ff:16:2a:e3:0e:
    9d:3b:af:ce:9a:3e:48:65:de:96:61:d5:0a:11:2a:a2:80:b0:
    7d:d8:99:cb:0c:99:34:c9:ab:25:06:a8:31:ad:8c:4b:aa:54:
    91:f4:15
   Public Exponent: 65537 (0x10001)
  Extensions:
   Identifier: Certificate Type
    Critical: no
    Certified Usage:
     SSL Client
   Identifier: Authority Key Identifier
    Critical: no
    Key Identifier:
     f2:f2:06:59:90:18:47:51:f5:89:33:5a:31:7a:e6:5c:fb:36:
     26:c9
  Signature:
   Algorithm: PKCS #1 MD5 With RSA Encryption
   Signature:
    6d:23:af:f3:d3:b6:7a:df:90:df:cd:7e:18:6c:01:69:8e:54:65:fc:06:
    30:43:34:d1:63:1f:06:7d:c3:40:a8:2a:82:c1:a4:83:2a:fb:2e:8f:fb:
    f0:6d:ff:75:a3:78:f7:52:47:46:62:97:1d:d9:c6:11:0a:02:a2:e0:cc:
    2a:75:6c:8b:b6:9b:87:00:7d:7c:84:76:79:ba:f8:b4:d2:62:58:c3:c5:
    b6:c1:43:ac:63:44:42:fd:af:c8:0f:2f:38:85:6d:d6:59:e8:41:42:a5:
    4a:e5:26:38:ff:32:78:a1:38:f1:ed:dc:0d:31:d1:b0:6d:67:e9:46:a8:
    d:c4

以下は、ソフトウェアによって解釈された64バイトエンコードされた形で表示された同じ証明書です。


 -----BEGIN CERTIFICATE-----
 MIICKzCCAZSgAwIBAgIBAzANBgkqhkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzER
 MA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEw
 MTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBgNVBAYTAlVTMREwDwYDVQQK
 EwhOZXRzY2FwZTENMAsGA1UECxMEUHViczEXMBUGA1UEAxMOU3Vwcml5YSBTaGV0
 dHkwgZ8wDQYJKoZIhvcNAQEFBQADgY0AMIGJAoGBAMr6eZiPGfjX3uRJgEjmKiqG
 7SdATYazBcABu1AVyd7chRkiQ31FbXFOGD3wNktbf6hRo6EAmM5/R1AskzZ8AW7L
 iQZBcrXpc0k4du+2Q6xJu2MPm/8WKuMOnTuvzpo+SGXelmHVChEqooCwfdiZywyZ
 NMmrJgaoMa2MS6pUkfQVAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQEAwIAgDAfBgNV
 HSMEGDAWgBTy8gZZkBhHUfWJM1oxeuZc+zYmyTANBgkqhkiG9w0BAQQFAAOBgQBt
 I6/z07Z635DfzX4XbAFpjlRl/AYwQzTSYx8GfcNAqCqCwaSDKvsuj/vwbf91o3j3
 UkdGYpcd2cYRCgKi4MwqdWyLtpuHAH18hHZ5uvi00mJYw8W2wUOsY0RC/a/IDy84
 hW3WWehBUqVK5SY4/zJ4oTjx7dwNMdGwbWfpRqjd1A==
 -----END CERTIFICATE-----
 

信頼を確立するための CA 証明書の使用方法

認証局(CA)は、アイデンティティを検証し、証明書を発行する事業体です。認証局は、独立した第三者であるか、独自の証明書発行サーバ・ソフトウェアを実行している組織であるかのいずれかとなります。

証明書をサポートするクライアントまたはサーバソフトウェアは、信頼できる CA 証明書のコレクションを保持しています。これらの CA 証明書は、ソフトウェアがどの他の証明書を検証できるか、言い換えれば、ソフトウェアが信頼できる証明書の発行者を決定します。最も単純なケースでは、ソフトウェアは、証明書を持つ CA の 1 つが発行した証明書のみを検証することができます。また、信頼された CA 証明書が、証明書階層内で上位の CA が発行した CA 証明書のチェーンの一部であることも可能です。

以下のセクションでは、証明書階層と証明書チェーンが、ソフトウェアが信頼できる証明書を決定する方法について説明します。

CA の階層

大規模な組織では、証明書発行の責任を複数の異なる証明書局に委任することが適切な場合があります。例えば、必要とされる証明書の数が多すぎて 1 つの CA が維持できない場合や、組織単位ごとに異なるポリ シー要件がある場合、または CA が証明書を発行する人々と同じ地理的地域に物理的に配置されていることが重要な場合などが考えられます。

証明書発行の責任を下位の CA に委任することも可能である。X.509 規格には、図 6 に示すような認証局の階層を設定するためのモデルが含まれている。

Figure 6. Example of a Hierarchy of Certificate Authorities

このモデルでは、ルート CA が階層の最上位に位置します。ルート CA の証明書は自己署名証明書であり、証明書が識別するのと同じエンティティであるルート CA によってデジタル署名されています。ルート CA の直属の CA は、ルート CA によって署名された CA 証明書を持つ。階層内の下位 CA の下にある CA は、上位レベルの下位 CA によって署名された CA 証明書を持ちます。

組織は、CA 階層を設定する方法について、非常に柔軟性が高い。図 6 に示すのは一例であり、他にも多くの配置が可能です。

証明書チェーン

CA の階層は証明書チェーンに反映されます。証明書チェーンは、連続する CA が発行する一連の証明書である。図7は、あるエンティティを識別する証明書から 2 つの下位 CA 証明書を経て、ルート CA の CA 証明書に至る証明書チェーンを示しています (図 6 の CA 階層に基づく)。

Figure 7. Example of a Certificate Chain

証明書チェーンは、階層内のブランチから階層のルートまでの証明書のパスをトレースします。証明書チェーンでは、以下のようなことが起こります。

  • 各証明書の後には、その発行者の証明書が続きます
  • 各証明書には、その証明書の発行者の名前 (DN) が含まれており、チェーン内の次の証明書のサブジェクト名と同じです

図 7 では、Engineering CA 証明書には、その証明書を発行した CA (つまり USA の CA) の DN が含まれています。USA の CA の DN は、チェーン内の次の証明書のサブジェクト名でもあります。

  • 各証明書は、その発行者の秘密鍵で署名されます。署名は、チェーンの次の証明書である発行者の証明書の公開鍵で検証することができます

図7では、米国 CA 用の証明書に含まれる公開鍵を使用して、エンジニアリング CA 用の証明書上の米国 CA のデジタル署名を検証することができます。

証明書チェーンの検証

証明書チェーンの検証は、与えられた証明書チェーンが適切に形成され、有効であり、適切に署名され、信頼できるものであることを確認するプロセスです。Red Hat ソフトウェアは、認証のために提示される証明書から始まる証明書チェーンの形成と検証に、以下の手順を使用します。

  1. 証明書の有効期間は、検証者のシステムクロックが提供する現在の時刻と照合されます
  2. 発行者の証明書が配置されます。ソースは、検証者のローカル証明書データベース (そのクライアントまたはサーバ上)、またはサブジェクトが提供する証明書チェーン (例えば、SSL 接続) のいずれかになります
  3. 証明書の署名は、発行者の証明書の公開鍵を使用して検証されます
  4. 発行者の証明書が検証者の証明書データベースで検証者に信頼されている場合、検証はここで正常に停止します。そうでない場合は、発行者の証明書が Red Hat 証明書タイプ拡張子に適切な下位 CA 表示が含まれていることを確認し、チェーン検証はステップ 1 に戻り、この新しい証明書を使用して再度開始します。図 8 にこのプロセスの例を示します

Figure 8. Verifying a Certificate Chain All the Way to the Root CA

図 8 は、ルート CA のみが検証者のローカルデータベースに含まれている場合の動作を示しています。図 8 に示す中間 CA の 1 つ、例えば Engineering CA のような証明書が検証者のローカルデータベースにある場合、図 9 に示すように、検証はその証明書で停止します。

Figure 9. Verifying a Certificate Chain to an Intermediate CA

有効期限が切れている場合、無効な署名がある場合、または証明書チェーンのどの時点でも発行 CA の証明書が存在しない場合、認証に失敗します。例えば、図 10 は、ルート CA 証明書も中間 CA 証明書も検証者のローカルデータベースに含まれていない場合の検証の失敗を示しています。

Figure 10. A Certificate Chain That Can't Be Verified

電子署名の仕組みについての一般的な情報は、"電子署名" を参照してください。SSLクライアントとサーバ認証のコンテキストでの署名検証プロセスのより詳細な説明については、"SSL 入門" を参照してください。

証明書の管理

証明書は、メールの暗号化からウェブサイトへのアクセスまで、多くのアプリケーションで使用されています。証明書のライフサイクルには大きく分けて2つの段階があります。それは、証明書が発行された時点 (発行・登録) と、証明書が無効になる期間 (更新・失効) です。また、証明書のライフサイクル中に証明書を管理する方法もあります。証明書に関する情報を他のアプリケーションで利用できるようにすることは、証明書を公開し、証明書を紛失した場合に復旧できるようにキーペアをバックアップすることです。

証明書の発行

証明書の発行プロセスは、その証明書を発行する認証局と、その証明書を使用する目的によって異なります。また、非デジタルな身分証明書を発行する際のプロセスも同様に異なります。例えば、カリフォルニア州の自動車局から一般的な ID カード (運転免許証ではない) を取得したい場合、要件は簡単です。通常の運転免許証を取得したい場合は、最初に免許証を取得する際に運転試験を受け、それを更新する際に筆記試験を受ける必要があります。あなたが18輪の商用ライセンスを取得したい場合は、要件ははるかに厳しいです。あなたが他の州や国に住んでいる場合は、様々な種類のライセンスの要件が異なります。

同様に、CA によって、異なる種類の証明書を発行するための手順が異なります。場合によっては、メールアドレスだけが必要な場合もあります。また、UNIX または Windows のログイン名とパスワードだけで十分な場合もあります。もう一方では、多額の支出を承認したり、その他の機密性の高い決定を行うことができます人物を識別する証明書の場合、 発行プロセスでは、公証された文書、身元調査、および個人的な面接が必要となる場合があります。

組織のポリシーに応じて、証明書の発行プロセスは、ユーザーにとって完全に透明なものから、ユーザーの参加を必要とし、複雑な手続きを必要とするものまで様々です。一般的に、証明書の発行プロセスは柔軟性が高く、組織は変化するニーズに合わせてカスタマイズすることができます。

証明書の発行は、別個の登録局によって処理されるいくつかの管理タスクのうちの 1 つです。

証明書と LDAP ディレクトリ

ディレクトリサービスにアクセスするための LDAP (Lightweight Directory Access Protocol) は、組織内での証明書の管理に大きな柔軟性を提供します。システム管理者は、証明書の管理に必要な情報の多くを LDAP 準拠のディレクトリに保存することができます。例えば、CA は、ディレクトリ内の情報を使用して、証明書に新入社員の法人名やその他の情報を事前に入力することができます。CA は、ディレクトリ情報を他の方法で活用して、特定の組織のセキュリティポリシーに応じてさまざまな識別技術を使用して、証明書を一度に 1 つまたは一括で発行することができます。鍵管理、証明書の更新および失効などの他の日常的な管理タスクは、ディレクトリを利用して、部分的または完全に自動化することができます。

また、ディレクトリに格納された情報を証明書とともに使用して、さまざまなユーザやグループによるさまざまなネットワーク・リソースへのアクセスを制御することもできます。このように、証明書の発行や他の証明書管理タスクは、ユーザやグループ管理の不可欠な部分となります。

一般的に、高性能なディレクトリサービスは、企業の証明書管理戦略に不可欠な要素です。

キーマネジメント

証明書を発行する前に、その証明書に含まれる公開鍵とそれに対応する秘密鍵を生成する必要があります。場合によっては、署名処理用の証明書と鍵のペアを一人の人間に発行し、暗号化処理用の証明書と鍵のペアをもう一人の人間に発行することが有用な場合もあります。署名証明書と暗号化証明書を別々に発行することで、 秘密署名鍵をローカルマシン上にのみ保持して最大の否認防止を実現し、 秘密暗号鍵を中央のどこかにバックアップしておけば、 ユーザーが元の鍵を紛失したり会社を辞めたりした場合にも、 その鍵を取り出すことができます。

鍵は、クライアント・ソフトウェアによって生成されるか、CA によって中央で生成され、LDAP ディレクトリを介してユーザに配布されます。ローカル鍵生成と集中型鍵生成の選択には、トレードオフの関係があります。例えば、ローカル鍵生成では、最大の否認防止効果が得られるが、発行プロセスへのユーザの参加が増える可能性があります。柔軟な鍵管理機能は、ほとんどの組織にとって不可欠です。

鍵のリカバリ、すなわち、慎重に定義された条件下で暗号化鍵のバックアップを取得する機能は、証明書管理の重要な部分となり得ます (組織が証明書をどのように使用するかにもよります) 。鍵回復スキームには通常、m/n のメカニズムが含まれます。例えば、組織内の m/n の管理者が合意し、特定の人の暗号化鍵を回復する前に、それぞれが特別なコードや鍵を提供しなければならない場合があります。この種のメカニズムでは、暗号化キーを復元する前に、複数の権限を持つ担当者が同意しなければならないことが保証されます。

証明書の更新と失効

運転免許証のように、証明書には有効期間が定められています。有効期間の前後に証明書を使用して認証を行おうとすると失敗します。したがって、証明書の更新を管理するメカニズムは、証明書管理戦略に不可欠です。例えば、管理者は、証明書の有効期限が切れそうなときに自動的に通知され、証明書の対象者に不都合を与えることなく、適切な更新プロセスを余裕をもって完了させることができるようにしたいと考えるかもしれません。更新プロセスでは、同じ公開鍵と秘密鍵のペアを再利用するか、新しい鍵を発行します。

運転免許証の有効期限が切れていなくても、例えば重大な運転違反の罰として免許を停止されることがあります。同様に、証明書の有効期限が切れる前に証明書を失効させる必要がある場合もあります。

証明書の失効は、いくつかの異なる方法で処理することができます。組織によっては、認証プロセスに、提示された証明書が存在するかどうかをディレクトリで確認することを含むように サーバをセットアップするだけで十分な場合もあります。管理者が証明書を失効すると、その証明書はディレクトリから自動的に削除され、その証明書を使用したその後の認証試行は、その証明書が他のすべての点で有効であるにもかかわらず失敗します。別の方法として、証明書失効リスト (CRL) 、すなわち失効した証明書のリストを一定の間隔でディレクトリに公開し、認証プロセスの一部としてこのリストをチェックするという方法もあります。組織によっては、認証のために証明書が提示されるたびに、発行 CA に直接確認することが望ましい場合もあります。この手順は、リアルタイムステータスチェックと呼ばれることもあります。

登録機関

証明書によって識別されるエンティティ (エンドエンティティと呼ばれることもあります) と認証局との間の相互作用は、証明書管理の重要な部分です。これらの相互作用には、認証のための登録、証明書の検索、証明書の更新、証明書の失効、鍵のバックアップとリカバリなどの操作が含まれる。一般的に、CA は、要求に応答する前にエンドエンティティの身元を認証できなければなりません。さらに、いくつかのリクエストは、サービスになる前に、権限のある管理者または管理者の承認を得る必要があります。

前述したように、証明書を発行する前に身元を確認するために異なる CA が使用する手段は、組織および証明書が使用される目的に応じて大きく異なる可能性があります。運用上の柔軟性を最大限に高めるために、エンド・エンティティとの相互作用を CA の他の機能から分離し、登録局 (RA) と呼ばれる別のサービスで処理することができます。

RA は、エンドエンティティの要求を受信し、認証し、CA に転送することで、CA のフロントエンドとして機能する。CA からの応答を受け取った後、RA はエンドエンティティに結果を通知します。RA は、異なる部門、地域、またはポリシーや認証要件が異なるその他の運用ユニット間で PKI をスケーリングする際に有用です。

もとのドキュメントの情報