Loading article…
委任パス検証( DPV ) は、デジタル証明書の認証パスを検証するタスクをクライアントから信頼できるサーバーにオフロードするために使用される暗号化方法です。[1]このプロセスは、公開鍵インフラストラクチャ(PKI)に依存するさまざまなセキュリティプロトコルに不可欠です。DPV は、検証結果をクライアントに提供するこのタスク専用のサーバーを活用することで、認証パス検証の効率を高めることを目的としています。このアプローチは、クライアントが広範な証明書検証を自分で実行するための計算能力を持たない可能性がある、リソースが制限された環境で特に役立ちます。[1]
証明書パスの検証
証明書パス検証は、デジタル証明書の真正性と信頼性を保証するPKIの重要なプロセスです。このプロセスはRFC 5280で標準化されており、検証対象の証明書（エンドエンティティ証明書）から信頼できるルート証明機関（CA）までの証明書チェーン を検証します。[2]検証プロセスには、いくつかの重要なステップが含まれます。[2]
- パスの構築: クライアントは、各証明書の発行者フィールドとサブジェクト フィールドのチェーンに従って、エンド エンティティ証明書から信頼されたルート証明書までのパスを構築します。
- 署名の確認: チェーン内の各証明書は、発行者によって正しく署名されていることを確認するためにチェックされ、各証明書の整合性と信頼性が検証されます。
- 有効期限の検証: 各証明書の有効期間をチェックして、パス内のどの証明書も期限切れになっていないことを確認します。
- 失効ステータスの確認: 各証明書は、証明書失効リスト(CRL) またはオンライン ステータス プロトコル ( OCSPなど)と照合され、失効していないことが確認されます。
- ポリシーの適用: 証明書パスが必要なセキュリティ標準とプラクティスに準拠していることを確認するために、依存当事者によって指定された追加のポリシーが適用されます。
これらのチェックがすべて正常に通過した場合、証明書パスは有効であるとみなされ、エンドエンティティ証明書は信頼できます。[2]
検証ポリシー
DPV を使用すると、サーバーは、検証ポリシーと呼ばれる一連の定義済みルールに基づいて、パス検証の全プロセスを処理できます。[1]このポリシーには、複数のトラスト アンカーが含まれる場合があります。トラスト アンカーは、公開キー、証明機関 (CA) 名、有効期間によって特徴付けられますが、追加の制約がある場合もあります。[3]自己署名証明書を使用して、トラスト アンカーの公開キー、発行者名、有効期間を指定できます。認証ポリシー制約や命名制約など、トラスト アンカーの追加の制約を定義できます。これらの制約は、自己署名証明書の一部にすることもできます。[1]パス検証を成功させるには、エンド エンティティ証明書とトラスト アンカーの間に有効な認証パスを確立し、パス内の証明書が期限切れまたは失効していないこと、およびパスのすべての制約が満たされていることを確認する必要があります。[1]検証ポリシーは、3 つの主要コンポーネントで構成されます。[1]
- 認証パス要件: 認証パス処理を開始するために必要な信頼アンカーのシーケンスと検証の初期条件を定義します。
- 失効要件: エンドエンティティおよび CA 証明書が失効していないことを確認するために必要なチェックを指定します。
- エンドエンティティ証明書固有の要件: エンドエンティティ証明書に、特定のタイプまたは値を持つ特定の拡張機能を含めることが必要になる場合があります。
プロトコル要件
RFC 3379 では、効果的で安全な委任パス検証を保証するためのいくつかの重要な要件が指定されています。
まず、クライアントがDPVサーバーがサポートしていない特定の検証ポリシーを要求した場合、サーバーはエラーを返す必要があります。これにより、クライアントは要求されたポリシーを適用できないことを認識できます。クライアントが検証ポリシーを指定しない場合、サーバーは応答でどの検証ポリシーが使用されたかを示す必要があります。この透明性により、クライアントは検証が行われた根拠を理解できます。[1]
検証ポリシーは複雑になる可能性があり、ルート自己署名証明書などのパラメータが含まれる場合があります。DPVプロトコルでは、クライアントがこれらのポリシー依存パラメータをリクエストに含めることができるようにする必要があります。ただし、ほとんどのクライアントは、アプリケーションに適した検証ポリシーを参照するか、DPVサーバーのデフォルトの検証ポリシーを受け入れることが予想されます。[1]
クライアントは、DPV サーバーが現在の時刻以外の特定の時刻に証明書の有効性を判断するように要求することもできます。このような場合、サーバーは指定された検証時刻に関連する失効ステータス情報を取得する必要があります。必要な失効ステータス情報が利用できない場合は、サーバーは証明書が無効であることを示すステータスを返す必要があり、無効の理由に関する追加の詳細を提供する場合もあります。[1]
検証を進めるには、証明書がリクエスト内で直接提供されるか、CA識別名、証明書のシリアル番号、証明書ハッシュなどの詳細によって明確に参照される必要があります。これにより、正しい証明書が検証されます。[1]
DPVクライアントは、検証サーバーに、検証対象の各証明書に関連する有用な証明書と失効情報を提供できる必要があります。これには、証明書の現在のステータスを確認するために重要なOCSP応答、CRL、およびデルタCRLが含まれます。[1]
DPV サーバーは、検証が必要な証明書にアクセスできる必要があります。要求で証明書が提供されていない場合、サーバーは証明書を取得し、クライアントが提供した参照と一致することを確認する必要があります。応答では、サーバーは証明書または証明書への明確な参照のいずれかを含める必要があります。特に CA キーの侵害が関係する場合はそうです。[1]
DPVサーバーからの応答は、次のいずれかのステータスを示す必要があります。[1]
- 証明書は検証ポリシーに従って有効です。
- 検証ポリシーによれば、証明書は有効ではありません。
- 検証ポリシーによれば、証明書の有効性は不明です。
- エラーのため有効性を判定できませんでした。
証明書が有効でない場合、サーバーはその理由も提供する必要があります。一般的な理由としては、証明書パスを構築できない、構築したパスが検証アルゴリズムに失敗した、または証明書の有効期限が切れる前や一時停止中など、要求された時点で証明書が有効でなかった、などがあります。[1]
さらに、DPV プロトコルでは、クライアントがサーバーに応答に追加情報を含めるよう要求できるようにする必要があります。この追加情報は、DPV サーバーを信頼していない証明書利用者が証明書の検証が正しく実行されたことを確信するのに役立ちます。DPV 応答は DPV 要求にバインドされている必要があります。これは、応答に要求の一方向ハッシュを含めることで実現できます。このバインドにより、応答の構築時にすべての要求パラメータが考慮されることが保証されます。[1]
クライアントがDPVサーバーを信頼していることを確認するには、応答を認証する必要があります。クライアントが証明書の検証が正しく処理されたことを第三者に証明するには、エラーを報告する場合を除き、DPV応答にデジタル署名する必要があります。DPVサーバーの証明書はサーバーを認証する必要があり、検証プロセスに信頼とセキュリティのもう1つのレイヤーを追加します。[1]
リレー、リダイレクト、マルチキャスト
特定のネットワーク環境、特にファイアウォールのある環境では、DPV サーバーは検証要求を処理するために必要なすべての情報を取得するのに困難に遭遇することがあります。これに対処するために、DPV サーバーは他の DPV サーバーのサービスを活用するように構成できます。このようなシナリオでは、クライアントはプライマリ DPV サーバーが要求を満たすために追加のサーバーを利用していることに気付きません。基本的に、プライマリ DPV サーバーは別の DPV サーバーのクライアントとして機能し、より包括的な検証プロセスを促進します。エンド クライアントとは異なり、DPV サーバーは通常、より大規模なコンピューティング リソースとメモリ リソースを備えているため、リレー、リダイレクト、またはマルチキャスト メカニズムを使用できます。[1]
これらの操作をサポートするように設計されたプロトコルには、DPV サーバー間のリレー、リダイレクト、またはマルチキャストを容易にするためのオプション フィールドと拡張機能が含まれる場合があります。ただし、DPV クライアントがこれらの機能をサポートすることは想定されていません。プロトコルにこのような機能が組み込まれている場合は、これらの高度な機能をサポートしていない DPV クライアントとサーバーとの互換性を確保し、基本的なプロトコル要件に準拠するためのメカニズムも提供する必要があります。[1]
セキュリティへの影響
DPVプロトコルには、リプレイ攻撃を防ぐためのメカニズムが組み込まれている必要があり、悪意のあるエンティティが検証要求を再利用して不正アクセスを取得できないようにする必要があります。[1]重要なのは、このリプレイ防止がクライアントとサーバー間の同期されたクロックに依存してはならないことです。クロックが正確に調整されていない場合、脆弱性が発生する可能性があります。[4]
指定されたポリシーに従って証明書が正常に検証された場合、DPV サーバーはクライアントからの要求に応じてこの情報を応答に含める必要があります。ただし、証明書が無効であることが判明した場合、またはサーバーがその有効性を判断できない場合、サーバーは機密情報の不必要な開示を避けるためにこの情報を省略することを選択できます。[1]
DPV サーバーが使用する失効ステータス情報は、クライアントのリクエストで指定された検証時間に関係します。この検証時間は、証明書の秘密鍵が文書またはトランザクションに署名するために使用された実際の時間と異なる場合があります。[1]したがって、DPV クライアントは、いくつかの遅延を考慮して検証時間を調整する必要があります。[1]
- 証明書所有者（エンドエンティティ）が自分の秘密鍵が侵害されたか、侵害される可能性があることに気づくまでにかかる時間。
- エンドエンティティがキーの侵害を関係当局に報告するのに必要な時間。
- エンドエンティティから提出された失効要求を失効機関が処理するのに必要な時間。
- 失効権限者が新しい失効ステータス情報を更新して配布するのにかかる時間。
これらの要素を考慮することで、DPVプロトコルは失効ステータス情報が証明書の現在の有効性を正確に反映していることを確認し、検証プロセスの全体的なセキュリティと信頼性を高めます。[1]
参照
参考文献
- ^ abcdefghijklmnopqrstu vw RFC 3379 (2002 年 9 月)、第 4 章「委任パス検証および委任パス検出プロトコルの要件」。
- ^ abc RFC 5280 (2008 年 5 月)、第 6 章、インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト (CRL) プロファイル。
- ^ Ma, Zane; Austgen, James; Mason, Joshua; Durumeric, Zakir; Bailey, Michael (2021-11-02). 「ルーツをたどる: TLS トラストアンカーエコシステムの探索」。第 21 回 ACM インターネット測定会議の議事録。IMC '21。ニューヨーク、ニューヨーク州、米国: Association for Computing Machinery。pp. 179–194。doi : 10.1145 / 3487552.3487813。ISBN 978-1-4503-9129-0。
- ^ Syverson, P. ( 1994). 「リプレイ攻撃の分類法 [暗号化プロトコル]」。Proceedings the Computer Security Foundations Workshop VII。IEEE Comput. Soc. Press。pp. 187–191。doi :10.1109 / CSFW.1994.315935。ISBN 978-0-8186-6230-0。
さらに読む
- Vacca, John R. 編 (2014)。「第 3 章 - 公開鍵インフラストラクチャ」。サイバー セキュリティと IT インフラストラクチャ保護(第 1 版)。マサチューセッツ州ウォルサム: Syngress は Elsevier の出版物です。ISBN 978-0-12-416681-3. OCLC 861507009.
外部リンク
- 「分散委任パスの検出と検証」。Google Patents 。2024 年 7 月 9 日閲覧。
- Braun, William. 「認証パスの検証」。docs.hidglobal.com 。 2024年7月11日閲覧。