web-dev-qa-db-ja.com

悪意のある証明書に同じ「サブジェクトキー識別子」が含まれている場合、どのような損害が生じる可能性がありますか？

Subject Key Identifier CA証明書の属性 であり、検証でCAが果たす役割を理解し、クライアントソフトウェアの検証がそれをどのように誤解する可能性があるかを推測しようとしています。

  • CAまたはエンド証明書の検証におけるサブジェクトキー識別子の役割は何ですか？
    一般的なソフトウェアパッケージの実装方法に関する知識があれば役立ちます

  • 攻撃者が同じハッシュを含む公開キーを生成できる場合、攻撃者は何をすることができますか？

私が読んだところ RFC328 サブジェクトキー識別子（SKI）は、PKIチェーンの構築と検証に使用される接着剤のようなものであることがわかります。また、SKIは、2つの証明書をバインドするためにも使用された証明書のシリアル番号と名前よりも安全なバージョンのようです。

証明書ハッシュのクライアント検証に関して、クライアントは単にSKIの「パターン一致」を行うか、または以下に説明するように実際に計算されたチェーンSKIです。

CA証明書の場合、サブジェクトキー識別子は以下から派生する必要があります（SHOULD）
公開鍵または一意の値を生成するメソッド。 2つの一般的な
公開鍵から鍵識別子を生成する方法は次のとおりです。

  (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
  value of the BIT STRING subjectPublicKey (excluding the tag,
  length, and number of unused bits).

  (2) The keyIdentifier is composed of a four bit type field with
  the value 0100 followed by the least significant 60 bits of the
  SHA-1 hash of the value of the BIT STRING subjectPublicKey
  (excluding the tag, length, and number of unused bit string bits).

私が軽減しようとしているリスクの1つの例は、正しいSKIにハッシュされない公開鍵を持つ不正な形式のCA証明書です（手動のASN.1で編集され、攻撃者のルートから証明書を再署名します）。

certificatespublic-key-infrastructurecertificate-authoritythreat-mitigation
13
goodguys_activate

Subject Key Identifierはnotが検証で役割を果たす、少なくとも RFC 528 のセクション6を構成するアルゴリズムではそうではない。 パス構築、検証の前に行われるアクティビティの助けになることを意味します：これは、証明書を検証したいエンティティが潜在的なその後、セクション6アルゴリズムで処理される証明書チェーン。セクション4.2.1.2では、この拡張機能について説明し、次のテキストを含みます。

証明書パスの構築を容易にするために、この拡張はすべての準拠CA証明書、つまり、cAの値がTRUEである基本制約拡張（セクション4.2.1.9）を含むすべての証明書に出現する必要があります。準拠するCA証明書では、サブジェクトキー識別子の値は、この証明書のサブジェクトによって発行された証明書のオーソリティキー識別子拡張（セクション4.2.1.1）のキー識別子フィールドに配置された値である必要があります。アプリケーションは、証明書パスの検証を実行するときに、キー識別子が一致することを確認する必要はありません。

これらの「必須」はCAの義務です。RFC5280で説明されているプロファイルに準拠するには、CAはAuthority Key Identifier自身が発行する証明書のSubject Key Identifier。最後の文に注意してください。この一致は、検証で検証する必要があるもののではない部分です。

RFCでは、ハッシュを使用してキー識別子を計算することをお勧めします。これにより、衝突が最小限に抑えられ、パス構築のためのこの拡張の最大効率が保証されます。ただし、ハッシュは必須ではありません。 CAは、適切と思われる方法で識別子を選択できます。ベリファイアは確かに識別子を再計算しますしません。これは、純粋なバイト間等価テストです。また、Microsoftのパス検証の実装は、キー識別子が一致しないパスを構築して検証する準備ができていることも知っています。

不正なCAがキー識別子を再利用することでできる最悪の事態は、パスの構築をより困難にすることです。これは、キー識別子を介してパス構築を行い、遅延して他の方法を試すことができない検証者に対して、一種の サービス拒否 をトリガーする可能性があります。実際には、検証者は、主要な識別子ではなく、サブジェクトと発行者のDNを照合することによってパスを構築する傾向があるため、実際の影響はゼロに近いはずです。

19
Thomas Pornin

ルージュキー識別子は、明確なパス検索を妨げます。

最悪の場合、いくつかの潜在的なパスの有効性をチェックする必要があります。しかし、とにかくトラストストアに不正な識別子を含む証明書があるでしょうか。信頼できない場合は、そのパスを確認する必要はありません。そして、あなたがそれを信頼するなら、thatパスは検証されません。

0
Robert Siemer