委任パス検証

委任パス検証（DPV）は、デジタル証明書の証明書パス検証作業をクライアントから信頼できるサーバーにオフロードするために使用される暗号化手法です。[ 1 ]このプロセスは、公開鍵基盤（PKI）に依存するさまざまなセキュリティプロトコルに不可欠です。DPVは、このタスク専用のサーバーを活用し、検証結果をクライアントに提供することで、証明書パス検証の効率性を高めることを目的としています。このアプローチは、クライアントが広範な証明書検証を自ら実行するための計算能力を持たない、リソースが限られた環境で特に有用です。 [ 1 ]

証明書パスの検証

デジタル証明書の信頼チェーンを示す図。ルート CA からエンド エンティティ証明書までの階層を示しています。

証明書パス検証は、PKIにおける重要なプロセスであり、デジタル証明書の真正性と信頼性を保証します。このプロセスはRFC  5280で標準化されており、検証対象の証明書（エンドエンティティ証明書）から信頼できるルート証明機関（CA）までの証明書チェーンを検証します。 [ 2 ]検証プロセスには、いくつかの重要なステップが含まれます。[ 2 ]

  • パスの構築: クライアントは、各証明書の発行者フィールドとサブジェクト フィールドのチェーンをたどって、エンド エンティティ証明書から信頼されたルート証明書までのパスを構築します。
  • 署名の確認: チェーン内の各証明書は、発行者によって正しく署名されていることを確認するためにチェックされ、各証明書の整合性と信頼性が検証されます。
  • 有効期限の検証: 各証明書の有効期間をチェックして、パス内のどの証明書も期限切れになっていないことを確認します。
  • 失効ステータスの確認: 各証明書は、証明書失効リスト(CRL) またはオンライン ステータス プロトコル ( OCSPなど)と照合され、失効していないことが確認されます。
  • ポリシーの適用: 証明書パスが必要なセキュリティ標準とプラクティスに準拠していることを確認するために、証明書利用者によって指定された追加のポリシーが適用されます。

これらのチェックがすべて正常に通過した場合、証明書パスは有効であるとみなされ、エンドエンティティ証明書は信頼できます。[ 2 ]

検証ポリシー

DPV を使用すると、サーバーは、検証ポリシーと呼ばれる一連の定義済みルールに基づいて、パス検証プロセス全体を処理できます。[ 1 ]このポリシーには、複数のトラスト アンカーが含まれる場合があります。トラスト アンカーは、公開鍵、証明機関 (CA) 名、および有効期間によって特徴付けられ、追加の制約を持つこともできます。[ 3 ]自己署名証明書を使用して、トラスト アンカーの公開鍵、発行者名、および有効期間を指定できます。認証ポリシー制約や命名制約など、トラスト アンカーの追加の制約を定義できます。これらの制約は、自己署名証明書の一部にすることもできます。[ 1 ]パス検証を正常に行うには、エンド エンティティ証明書とトラスト アンカーの間に有効な認証パスを確立し、パス内の証明書が期限切れまたは失効していないこと、およびパスのすべての制約が満たされていることを確認する必要があります。[ 1 ]検証ポリシーは、次の 3 つの主要コンポーネントで構成されます。[ 1 ]

  1. 認証パス要件: 認証パス処理を開始するために必要な信頼アンカーのシーケンスと検証の初期条件を定義します。
  2. 失効要件: エンド エンティティおよび CA 証明書が失効していないことを確認するために必要なチェックを指定します。
  3. エンド エンティティ証明書固有の要件: エンド エンティティ証明書に、特定のタイプまたは値を持つ特定の拡張機能を含めることが必要になる場合があります。

プロトコル要件

RFC  3379では、効果的かつ安全な委任パス検証を保証するためのいくつかの重要な要件が規定されています。

まず、クライアントがDPVサーバーがサポートしていない特定の検証ポリシーを要求した場合、サーバーはエラーを返す必要があります。これにより、クライアントは要求されたポリシーを適用できないことを認識できます。クライアントが検証ポリシーを指定しなかった場合、サーバーはレスポンスでどの検証ポリシーが使用されたかを示す必要があります。この透明性により、クライアントは検証がどのような根拠に基づいて行われたかを理解できます。[ 1 ]

検証ポリシーは複雑になる場合があり、ルート自己署名証明書などのパラメータが含まれることがあります。DPVプロトコルでは、クライアントがリクエストにこれらのポリシー依存パラメータを含めることができる必要があります。ただし、ほとんどのクライアントは、アプリケーションに適した検証ポリシーを参照するか、DPVサーバーのデフォルトの検証ポリシーを受け入れることが想定されます。[ 1 ]

クライアントは、DPVサーバーに対し、現在時刻以外の特定の時刻における証明書の有効性を確認するよう要求することもできます。この場合、サーバーは指定された検証時刻に関連する失効ステータス情報を取得する必要があります。必要な失効ステータス情報を取得できない場合、サーバーは証明書が無効であることを示すステータスを返さなければなりません。また、無効の理由に関する追加情報を提供する場合もあります。[ 1 ]

検証を進めるには、証明書がリクエスト内で直接提供されるか、CA識別名、証明書シリアル番号、証明書ハッシュなどの詳細によって明確に参照される必要があります。これにより、正しい証明書が検証されることが保証されます。[ 1 ]

DPVクライアントは、検証対象となる各証明書に関連する有用な証明書と失効情報を検証サーバーに提供できる必要があります。これには、証明書の現在のステータスを確認するために不可欠なOCSPレスポンス、CRL、およびDelta CRLが含まれます。[ 1 ]

DPVサーバーは、検証が必要な証明書にアクセスできる必要があります。リクエストに証明書が含まれていない場合、サーバーは証明書を取得し、クライアントが提供した参照と一致することを検証する必要があります。レスポンスには、特にCA鍵の侵害が関与する場合には、サーバーは証明書または証明書への明確な参照のいずれかを含める必要があります。[ 1 ]

DPVサーバーからの応答は、次のいずれかのステータスを示す必要があります。[ 1 ]

  • 証明書は検証ポリシーに従って有効です。
  • 検証ポリシーによれば、証明書は有効ではありません。
  • 検証ポリシーによると、証明書の有効性は不明です。
  • エラーのため有効性を判定できませんでした。

証明書が有効でない場合、サーバーはその理由も提供する必要があります。一般的な理由としては、証明書パスを構築できない、構築したパスが検証アルゴリズムに失敗した、証明書が要求された時点で有効でなかった（有効期限開始前や一時停止中など）などが挙げられます。[ 1 ]

さらに、DPVプロトコルは、クライアントがサーバーに応答に追加情報を含めるよう要求できるようにする必要があります。この追加情報は、DPVサーバーを信頼していない証明書利用者が、証明書の検証が正しく行われたことを確信するのに役立ちます。DPV応答はDPV要求にバインドされている必要があり、これは応答に要求の一方向ハッシュを含めることで実現できます。このバインドにより、応答の構築においてすべての要求パラメータが考慮されることが保証されます。[ 1 ]

クライアントがDPVサーバーを信頼していることを確認するには、応答を認証する必要があります。クライアントが証明書の検証が正しく処理されたことを第三者に証明するには、エラーを報告する場合を除き、DPV応答にデジタル署名が必要です。DPVサーバーの証明書はサーバーを認証する必要があり、これにより検証プロセスに信頼性とセキュリティの新たなレイヤーが追加されます。[ 1 ]

リレー、リダイレクト、マルチキャスト

TLSベースの通信に DPV フレームワークを適用し、プライマリ DPV サーバーによるリレー メカニズムをオプションで使用します。

特定のネットワーク環境、特にファイアウォールが設置されている環境では、DPVサーバーが検証要求を処理するために必要な情報をすべて取得することが困難になる場合があります。この問題に対処するために、DPVサーバーを他のDPVサーバーのサービスを活用するように構成することができます。このようなシナリオでは、クライアントはプライマリDPVサーバーが要求を処理するために追加のサーバーを利用していることに気づきません。基本的に、プライマリDPVサーバーは別のDPVサーバーのクライアントとして機能し、より包括的な検証プロセスを促進します。エンドクライアントとは異なり、DPVサーバーは通常、より大規模なコンピューティングリソースとメモリリソースを備えているため、リレー、リダイレクト、またはマルチキャストメカニズムを利用できます。[ 1 ]

これらの操作をサポートするために設計されたプロトコルには、DPVサーバー間のリレー、リダイレクト、またはマルチキャストを容易にするためのオプションフィールドや拡張機能が含まれる場合があります。ただし、DPVクライアントがこれらの機能をサポートすることは想定されていません。プロトコルがこれらの機能を組み込む場合、これらの高度な機能をサポートしていないDPVクライアントおよびサーバーとの互換性を確保し、基本的なプロトコル要件を遵守するためのメカニズムも提供する必要があります。[ 1 ]

セキュリティへの影響

DPVプロトコルには、リプレイ攻撃を防ぐためのメカニズムが組み込まれている必要があり、悪意のあるエンティティが検証要求を再利用して不正アクセスを取得できないようにする必要があります。[ 1 ]重要なのは、このリプレイ防止はクライアントとサーバー間の同期されたクロックに依存してはならないことです。クロックが正確に調整されていない場合、脆弱性が発生する可能性があります。[ 4 ]

指定されたポリシーに従って証明書が正常に検証された場合、DPVサーバーはクライアントからの要求に応じてこの情報を応答に含める必要があります。ただし、証明書が無効であると判明した場合、またはサーバーがその有効性を判断できない場合、サーバーは機密情報を含む可能性のある情報の不必要な開示を避けるため、この情報を省略する場合があります。[ 1 ]

DPVサーバーが使用する失効ステータス情報は、クライアントのリクエストで指定された検証時刻に関係します。この検証時刻は、証明書の秘密鍵が文書またはトランザクションに署名するために実際に使用された時刻と異なる場合があります。[ 1 ]そのため、DPVクライアントは、いくつかの遅延を考慮して検証時刻を調整する必要があります。[ 1 ]

  • 証明書所有者 (エンドエンティティ) が自分の秘密鍵が侵害されたか侵害される可能性があることに気付くまでにかかる時間。
  • エンドエンティティがキーの侵害を関係当局に報告するために必要な時間。
  • エンドエンティティから提出された失効要求を失効機関が処理するのに必要な時間。
  • 失効権限が新しい失効ステータス情報を更新して配布するのにかかる時間。

これらの要素を考慮することで、DPVプロトコルは失効ステータス情報が証明書の現在の有効性を正確に反映していることを確認し、検証プロセスの全体的なセキュリティと信頼性を高めます。[ 1 ]

参照

参考文献

  1. ^ a b c d e f g h i j k l m n o p q r s t u v w RFC 3379 ( 2002年9月)、第4章「委任パス検証および委任パス検出プロトコルの要件」。 
  2. ^ a b c RFC 5280（2008年5月）、第6章、インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル。 
  3. ^ Ma, Zane; Austgen, James; Mason, Joshua; Durumeric, Zakir; Bailey, Michael (2021-11-02). 「Tracing your roots: Exploring the TLS trust anchor ecosystem」 . Proceedings of the 21st ACM Internet Measurement Conference . IMC '21. ニューヨーク、ニューヨーク州、米国: Association for Computing Machinery. pp.  179– 194. doi : 10.1145/3487552.3487813 . ISBN 978-1-4503-9129-0。
  4. ^ Syverson, P. (1994). 「リプレイ攻撃の分類法 [暗号プロトコル]」.コンピュータセキュリティ基盤ワークショップ 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版). Waltham, MA: SyngressはElsevierの出版物です. ​​ISBN 978-0-12-416681-3. OCLC  861507009 .
「 https://en.wikipedia.org/w/index.php?title=Delegated_Path_Validation&oldid=1307758985」から取得