次の方法で共有

証明書と公開キー

  • [アーティクル]

証明書サービスは、情報を保護および認証するための手段を提供する公開キー 基盤 (PKI) の基盤の 1 つです。 証明書所有者、証明書所有者の ID、および証明書所有者の 公開キー の関係は、PKI の重要な部分です。 このインフラストラクチャは、次の部分で構成されています。

公開キーと秘密キーのペア

PKI では、公開キーと秘密キーのペアを使用する必要があります。 公開キーと秘密キーのペアの数学は、このドキュメントの範囲外ですが、公開キーと秘密キーの間の機能的な関係に注意することが重要です。 PKI 暗号化アルゴリズム、暗号化されたメッセージの受信者の 公開キー を使用してデータを暗号化し、関連する 秘密キー し、関連する秘密キーのみを使用して暗号化されたメッセージを復号化します。

同様に、以下で詳しく説明するコンテンツの デジタル署名 は、署名者の秘密キーを使用して作成されます。 すべてのユーザーが使用できる対応する公開キーは、この署名の検証に使用されます。 秘密キーが侵害された後にフレームワークが分離されるため、秘密キーの秘密を維持する必要があります。

十分な時間とリソースがあると、公開キーと秘密キーのペアが侵害される可能性があります。つまり、秘密キーを検出できます。 キーが長いほど、ブルート フォースを使用して秘密キーを検出するのが難しくなります。 実際には、十分に強力なキーを使用して、秘密キーをタイムリーに判断することが不可能になり、公開キー インフラストラクチャを実行可能なセキュリティ メカニズムにすることができます。

秘密キーは、保護された形式でディスクに格納できます。その場合、別のコンピューターに物理的に移動しない限り、その特定のコンピューターでのみ使用できます。 別の方法として、スマート カード リーダーとサポート ソフトウェアがあれば、別のコンピューターで使用できるキーをスマート カードに配置することもできます。

デジタル証明書のサブジェクトの公開キーは、秘密キーではなく、証明書要求の一部として含まれます。 (そのため、証明書要求を行う前に公開キーと秘密キーのペアが存在している必要があります)。その公開キーは、発行された証明書の一部になります。

証明書要求

証明書を発行する前に、証明書要求 を生成する必要があります。 この要求は、エンド ユーザー、コンピューター、アプリケーションなどの 1 つのエンティティに適用されます。 説明のために、エンティティが自分であると仮定します。 ID の詳細は、証明書要求に含まれます。 要求が生成されると、証明機関 (CA) に送信されます。 その後、CA は ID 情報を使用して、要求が証明書を発行するための CA の基準を満たしているかどうかを判断します。 CA が要求を承認すると、要求で指定されたエンティティとして証明書が発行されます。

証明機関

証明書を発行する前に、CA によって ID が検証されます。 証明書が発行されると、ID は公開キーを含む証明書にバインドされます。 証明書には、CA のデジタル署名も含まれています (証明書を受け取ったすべてのユーザーが検証できます)。

証明書には発行元 CA の ID が含まれているため、この CA を信頼する関係者は、その信頼を証明書に拡張できます。 証明書の発行は信頼を確立しませんが、信頼を転送します。 証明書コンシューマーが発行元の CA を信頼しない場合、証明書は信頼されません (少なくとも信頼できません)。

署名された証明書のチェーンを使用すると、信頼を他の CA にも転送できます。 これにより、異なる CA を使用する当事者は、証明書を信頼できます (チェーン内に共通の CA がある場合、つまり、両方の当事者によって信頼されている CA がある場合)。

証明書

公開キーと発行元 CA の ID に加えて、発行された証明書には、キーと証明書の目的に関する情報が含まれています。 さらに、失効した証明書の CA の一覧へのパスが含まれており、証明書の有効期間 (開始日と終了日) を指定します。

証明書コンシューマーが証明書の発行元 CA を信頼していると仮定すると、証明書コンシューマーは、証明書の開始日と終了日を現在の時刻と比較し、証明書が CA の失効した証明書の一覧に含まれていないことを確認することによって、証明書がまだ有効かどうかを判断する必要があります。

証明書失効リスト

証明書が有効な期間に使用されていて、証明書コンシューマーが発行元 CA を信頼していると仮定すると、証明書コンシューマーが証明書を使用する前に確認する項目がもう 1 つあります。証明書失効リスト(CRL)。 証明書コンシューマーは、CA の CRL (証明書に拡張機能として含まれているパス) を調べて、失効した証明書の一覧に証明書が含まれていないことを確認します。 CRL は存在します。証明書の有効期限が切れていないが、信頼できなくなる場合があるためです。 CA は定期的に、更新された CRL を発行します。 証明書コンシューマーは、証明書を信頼できると見なす前に、証明書を現在の CRL と比較する必要があります。

暗号化に使用する公開キー

送信者がメッセージを送信する前に暗号化する場合、送信者は最初に証明書を取得します。 送信者が CA が信頼されており、証明書が有効であり、失効していないと判断した後、送信者は暗号化アルゴリズムを使用して公開キー (証明書の一部であることを思い出す) を使用して、プレーンテキスト メッセージを暗号化。 暗号テキストを受け取ったら、秘密キーを使用して暗号テキストの暗号化を解除します。

第三者が暗号文の電子メール メッセージを傍受した場合、第三者は 秘密キーにアクセスせずに暗号化を解除することはできません。

ここに記載されているアクティビティの大部分は、ユーザーによって直接ではなく、ソフトウェアによって処理されることに注意してください。

署名の検証に使用する公開キー

デジタル署名 は、メッセージが変更されていないことを確認し、メッセージ送信者の ID の確認として使用されます。 このデジタル署名は、秘密キーとメッセージの内容に依存します。 メッセージを入力と秘密キーとして使用すると、暗号化アルゴリズムによってデジタル署名が作成されます。 メッセージの内容は、署名プロセスによって変更されません。 受信者は、(証明書の有効性、CA の発行、失効状態を確認した後に) 公開キーを使用して、署名がメッセージの内容に対応しているかどうかを判断し、メッセージが送信されたかどうかを判断できます。

第三者が意図したメッセージを傍受し、(少しでも) 変更し、それを受信者に転送した場合、受信者はメッセージと署名を調べると、メッセージが疑わしいと判断できるようになります。 同様に、サード パーティがメッセージを作成し、ユーザーから送信された偽のデジタル署名で送信した場合、受信者は公開キーを使用して、メッセージと署名が相互に対応していないと判断できます。

非否認 は、デジタル署名でもサポートされています。 署名されたメッセージの送信者がメッセージの送信を拒否した場合、受信者は署名を使用してその要求を反論できます。

ここに記載されているアクティビティの大部分は、ユーザーによって直接ではなく、ソフトウェアによっても処理されることに注意してください。

Microsoft Certificate Services ロール

Microsoft Certificate Services には、証明書要求者の ID を確保する役割を担うポリシー モジュールの指示にしたがって、証明書を発行するか、証明書の要求を拒否する役割があります。 証明書サービスには、証明書を取り消す機能と CRL を発行する機能も用意されています。 証明書サービスは、発行された証明書を (ディレクトリ サービスなどに) 一元的に配布することもできます。 CRL の発行と共に、証明書の発行、配布、取り消し、管理を行う機能により、公開キー インフラストラクチャに必要な機能が提供されます。