Cryptography-public-key-infrastructure

提供:Dev Guides
移動先:案内検索

公開鍵インフラ

Public Key Infrastructure(PKI)の最も明確な機能は、基礎となるセキュリティサービスを実現するためにキーのペアを使用することです。 キーペアは、秘密キーと公開キーで構成されます。

公開鍵はオープンドメインにあるため、悪用される可能性があります。 したがって、これらのキーを管理するには、ある種の信頼できるインフラストラクチャを確立して維持する必要があります。

キー管理

暗号システムのセキュリティは、そのキーが安全に管理されているかどうかに依存することは言うまでもありません。 暗号化キーを処理するための安全な手順がないと、強力な暗号化スキームを使用する利点が失われる可能性があります。

暗号化スキームは、設計の弱点によってめったに侵害されないことが観察されています。 ただし、それらはしばしば不十分なキー管理によって危険にさらされます。

次のようなキー管理のいくつかの重要な側面があります-

  • 暗号化キーは特別なデータです。 キー管理とは、暗号化キーの安全な管理を指します。
  • キー管理は、次の図に示すように、キーのライフサイクル全体を扱います-

キー管理ライフサイクル

  • 公開キー暗号化のキー管理には、2つの特定の要件があります。
  • *秘密鍵の秘密。*鍵のライフサイクルを通して、秘密鍵は所有者であり、使用を許可されている者を除くすべての関係者の秘密を保持する必要があります。
  • *公開キーの保証。*公開キー暗号化では、公開キーはオープンドメインにあり、データの公開部分と見なされます。 デフォルトでは、公開鍵が正しいかどうか、誰と関連付けることができるか、または何に使用できるかについての保証はありません。 したがって、公開鍵の鍵管理は、公開鍵の目的の保証により明確に焦点を合わせる必要があります。

「公開キーの保証」の最も重要な要件は、公開キー暗号化をサポートするためのキー管理システムである公開キーインフラストラクチャ(PKI)によって実現できます。

公開キー基盤(PKI)

PKIは公開鍵の保証を提供します。 公開鍵とその配布の識別を提供します。 PKIの構造は、次のコンポーネントで構成されています。

  • 一般に「デジタル証明書」と呼ばれる公開鍵証明書。
  • 秘密鍵トークン。
  • 認証局。
  • 登録認定機関。
  • 証明書管理システム。

デジタル証明書

たとえば、証明書は個人に発行されたIDカードと見なすことができます。 人々は、運転免許証、パスポートなどのIDカードを使用して、身元を証明します。 デジタル証明書は、電子の世界で同じ基本的なことを行いますが、1つの違いがあります。

デジタル証明書は、人々に発行されるだけでなく、コンピュータ、ソフトウェアパッケージ、または電子の世界で身元を証明する必要がある他のあらゆるものに発行できます。

  • デジタル証明書はITU標準X.509に基づいており、公開鍵証明書と証明書検証の標準証明書形式を定義しています。 したがって、デジタル証明書はX.509証明書とも呼ばれます。 +ユーザークライアントに関連する公開キーは、クライアント情報、有効期限、使用法、発行者などの他の関連情報とともに、証明機関(CA)によってデジタル証明書に保存されます。
  • CAはこの情報全体にデジタル署名し、証明書にデジタル署名を含めます。
  • クライアントの公開キーと関連情報について保証が必要な場合は、CAの公開キーを使用して署名検証プロセスを実行します。 検証に成功すると、証明書で指定された公開鍵が、証明書で詳細が指定された人のものであることが保証されます。

個人/エンティティがデジタル証明書を取得するプロセスを次の図に示します。

デジタル証明書

図に示すように、CAは公開鍵を証明するためにクライアントからのアプリケーションを受け入れます。 CAは、クライアントの身元を正当に検証した後、そのクライアントにデジタル証明書を発行します。

認証機関(CA)

前述のように、CAはクライアントに証明書を発行し、他のユーザーが証明書を検証するのを支援します。 CAは、発行される証明書を要求するクライアントのIDを正しく識別する責任を負い、証明書に含まれる情報が正しいことを保証し、デジタル署名します。

CAの主な機能

CAの主要な機能は次のとおりです-

  • キーペアの生成-CAは、クライアントと独立して、または共同でキーペアを生成できます。
  • デジタル証明書の発行-CAは、パスポート代理店と同等のPKIと見なすことができます-CAは、クライアントが身元を確認するための資格情報を提供した後に証明書を発行します。 次に、CAは証明書に署名して、証明書に含まれる詳細の変更を防ぎます。
  • 証明書の発行-ユーザーが証明書を見つけることができるように、CAは証明書を発行する必要があります。 これを達成するには2つの方法があります。 1つは、電子電話帳に相当する証明書を発行することです。 もう1つは、何らかの方法で証明書が必要になると思われる人に証明書を送信することです。
  • 証明書の検証-CAは、クライアントのデジタル証明書の署名の検証を支援するために、環境で公開キーを利用可能にします。
  • 証明書の取り消し-CAは、ユーザーによる秘密キーの侵害やクライアントの信頼の喪失などの何らかの理由で発行された証明書を取り消すことがあります。 失効後、CAは環境で使用可能なすべての失効した証明書のリストを保持します。

証明書のクラス

証明書には4つの典型的なクラスがあります-

  • *クラス1 *-これらの証明書は、電子メールアドレスを入力することで簡単に取得できます。
  • *クラス2 *-これらの証明書には、追加の個人情報が必要です。
  • *クラス3 *-これらの証明書は、要求者の身元について確認が行われた後にのみ購入できます。
  • *クラス4 *-非常に高いレベルの信頼を必要とする政府や金融機関が使用する場合があります。

登録機関(RA)

CAは、サードパーティの登録機関(RA)を使用して、証明書を要求している個人または会社に対して必要なチェックを実行し、身元を確認することがあります。 RAはクライアントにはCAとして表示されますが、実際には発行された証明書に署名しません。

証明書管理システム(CMS)

証明書の公開、一時的または永続的な一時停止、更新、または取り消しを行う管理システムです。 証明書管理システムは通常、証明書を削除しません。これは、おそらく法律上の理由により、ある時点で証明書のステータスを証明する必要があるためです。 CAは、関連するRAと共に証明書管理システムを実行して、その責任と責任を追跡できます。

秘密鍵トークン

クライアントの公開鍵は証明書に保存されますが、関連付けられた秘密秘密鍵は鍵所有者のコンピューターに保存できます。 通常、この方法は採用されていません。 攻撃者がコンピューターにアクセスすると、秘密鍵に簡単にアクセスできます。 このため、秘密キーは、パスワードで保護された安全なリムーバブルストレージトークンアクセスに保存されます。

異なるベンダーは、多くの場合、キーを保存するために異なる、時には独自のストレージ形式を使用します。 たとえば、Entrustは独自の.epf形式を使用し、Verisign、GlobalSign、およびBaltimoreは標準の.p12形式を使用します。

CAの階層

広大なネットワークとグローバル通信の要件により、すべてのユーザーが証明書を取得する信頼できるCAを1つだけにすることは実際には不可能です。 第二に、CAが危険にさらされた場合、1つのCAのみの可用性が問題を引き起こす可能性があります。

このような場合、通信する2つのパーティが同じCAとの信頼関係を持たない環境で公開鍵証明書を使用できるため、階層型の証明書モデルが重要です。

  • ルートCAはCA階層の最上位にあり、ルートCAの証明書は自己署名証明書です。
  • ルートCAに直接従属するCA(CA1およびCA2など)には、ルートCAによって署名されたCA証明書があります。
  • 階層内の下位CAの下のCA(たとえば、CA5およびCA6)には、上位レベルの下位CAによって署名されたCA証明書があります。

認証局(CA)階層は、証明書チェーンに反映されます。 証明書チェーンは、階層内のブランチから階層のルートまでの証明書のパスをトレースします。

次の図は、エンティティ証明書から2つの下位CA証明書(CA6およびCA3)を経由してルートCAのCA証明書に至る証明書チェーンを持つCA階層を示しています。

CA階層

証明書チェーンの検証は、特定の証明書チェーンが有効であり、正しく署名され、信頼できることを確認するプロセスです。 次の手順では、認証用に提示された証明書から始まる証明書チェーンを検証します-

  • 信頼性が検証されているクライアントは、一般にルートCAまでの証明書のチェーンとともに、証明書を提供します。
  • 検証者は証明書を取得し、発行者の公開キーを使用して検証します。 発行者の公開キーは、クライアントの証明書の隣のチェーンにある発行者の証明書にあります。
  • 発行者の証明書に署名した上位CAが検証者によって信頼されている場合、検証は成功し、ここで停止します。
  • それ以外の場合、発行者の証明書は、上記の手順でクライアントに対して行われたのと同様の方法で検証されます。 このプロセスは、信頼できるCAがその間に見つかるか、ルートCAまで継続します。