web-dev-qa-db-ja.com

攻撃者はどのようにしてCAを侵害しますか?

いくつかの投稿があり、一部のCAは侵害されており、不正な証明書を配布していたと述べています。

キーがHSMに格納されていて、公開キーしか他の人が使用できないという事実を踏まえて、攻撃者はどのようにCA秘密キーを取得できますか?攻撃者がCA秘密キーを取得する以外にエンティティに証明書を発行する方法はありますか?

4
JzD

発行された証明書を取得するために、CAの秘密鍵にアクセスする必要はありません。特にスマートカードまたはHSM自体の内部で作成された場合、CAはおそらく秘密鍵にもアクセスできません。

代わりに、不正な証明書がCAによって発行されます。

  • 攻撃者はCAに自分がドメインの所有者であると信じ込ませます:
    これは、DV証明書のドメイン所有権の自動検証のために実行できます。この検証は通常、特別な電子メールアカウント、Webサーバーの特別なパス、または所有者ドメインのDNSレコードを使用して、いくつかのチャレンジ/レスポンスメソッドを実装することによって行われます。したがって、攻撃者が live.fiの場合 のようにドメイン内の特定のメールアカウントにアクセスした場合、侵害が可能です。 Comodo OCRの問題 の場合のように、CAにドメインの別の連絡先メールアドレスを信じさせることでも実行できます。攻撃者が元のサイトを侵害してWebサーバーパスの検証を攻撃したり、サイトのDNSを侵害してDNSレコードの検証を攻撃したりした場合も、DV検証がだまされる可能性があります。
  • サードパーティは、CAが発行したサブCAの使用制限に違反しています:
    これは、たとえば SSLインターセプトに使用されたフランスのサブCA の場合に発生し、google.comに対して(とりわけ)証明書が発行されました。
  • CAプロセスのバグ:
    [〜#〜] turktrust [〜#〜] の場合と同様に、通常の証明書の代わりに誤ってサブCA証明書を発行し、任意の新しい証明書を発行するために使用される可能性がありますドメイン。
  • CA自体の侵害:
    これは DigiNotar の場合に発生しました。攻撃者はCAのインフラストラクチャへのディープアクセスを取得できました。この攻撃に関する 最終レポート(PDF) は、自動トランザクションに対してスマートカードの秘密キーをアクティブにするDigiNotarがどのように見えるかを示しています。つまり、すべてのスマートカードトランザクションを明示的に承認する必要があるわけではありません。これにより、攻撃者はシステムに物理的にアクセスすることなく、また秘密鍵を持たずに、自身の証明書に署名することができました。
5
Steffen Ullrich