SHA-1いつどのようにして本当に問題になるのか

Question

まず、証明書の検証プロセスについての私の解釈を次に示します（間違っている場合は、遠慮なく訂正してください）。

Httpsを使用してWebサイトに接続すると、WebサイトはブラウザにSSL証明書を提示します。 Webサイトの認証に使用されます。ブラウザには、その証明書を信頼するかどうかを決定する方法が必要です。ブラウザは、ウェブサイトの証明書が信頼された認証局によって発行され、署名されているかどうかを確認することでこれを行います。証明書が発行されると、認証局は、実際のCAのみが実行でき、ブラウザが確認できる方法で、秘密鍵を使用して証明書に暗号で「署名」することにより、この証明を含めます。しかし、CAは実際には未加工の証明書に署名しません。は、SHA-1のような一方向ハッシュアルゴリズムを介して証明書を実行し、CAの秘密鍵で署名します。ブラウザーに証明書が提示されると、ブラウザーが最初に行うことの1つは、署名を確認することです。証明書はCAの秘密鍵で署名されているため（証明書はCAが所有していると想定します）、CAの対応する公開鍵は次のようなX.509証明書でラップされているため、サーバーで署名を検証（認証）できます。ブラウザにプリロードされています。次に、ブラウザーはその証明書のSHA-1を計算し、Webサイトから送信された証明書に示されている値と比較して、転送中に変更されていないことを確認して整合性を確認します。

上記に当てはまる場合、次の質問があります。最近Googleの研究者によって、2つの異なる.pdfファイルが同じSHA-1値を生成することが証明されたため、衝突が発生しましたが、これがどのように悪用されるのか疑問に思っています。つまり、example.comがSHA-1値がXである証明書を取得し、Verisignによって署名されているとします。攻撃者がexample.comの証明書を作成し、SHA-1値もXに等しいため、ここでも衝突がありますが、今回は信頼できるCAによるものではありません。では、攻撃者がexample.comになりすまそうとした場合、ブラウザが信頼されたルートCAによって署名されていることをブラウザが確認できない場合、これをどのように悪用することができますか？これは、ルートCAが危険にさらされた場合にのみ問題を引き起こしませんか？

追加：または、なぜそれがドキュメントの署名に問題があるのですか？つまり、ビジネスパートナーが契約を送ろうとしているとしましょう。それは彼によって署名され、私は確認することができ、私は自分の秘密鍵で署名した後にそれを送り返しました。それで、なぜ彼が同じハッシュ値で同様に見えるドキュメントを計算できたのか心配する必要がありますか？受け取っていない場合、私が署名したことを彼はどのように証明できますか？彼はできないと思います。また、「偽の」ドキュメントを受け取ったとしても、署名されているからといって、署名して返送する前に、ドキュメントの内容を確認する必要はありませんか？

編集：

私は理解し始めたと思います。したがって、証明書Aの場合、メッセージダイジェストはXに等しく、ルートCAは秘密鍵でそれに署名します。Xの形式でブラウザに事前にロードされている公開鍵で署名を復号化することにより、誰もがその信頼性を確認できます。 .509証明書、正しいですか？したがって、Xのハッシュ値（いずれにしても秘密ではないため）と、ハッシュに署名した秘密キーがわからない場合でも、最終的な結果（署名）= Yであることがわかります。したがって、証明書Aのハッシュ= Xと別の証明書を計算できます（実際の証明書に署名したルートCAに設定された発行者を使用して）。そのハッシュ値も= X（衝突が発生します）、署名者の秘密鍵がわからない場合でも、署名のY値（証明書の一意のハッシュと秘密鍵による暗号化により、署名値Yが生成されるため）、ブラウザは証明書を受け入れて検証します。これは、証明書を使用して署名を復号化できるためです。検証を実行しているルートCAの対応する公開鍵、そのハッシュを再度計算し、偽のサーバーおよび偽の証明書によって送信されたものと照合します。正しいですか？ありがとうございました

Steffen Ullrich · Accepted Answer

攻撃者がexample.comの証明書を作成し、SHA-1値もXに等しいため、ここでも衝突がありますが、今回は信頼できるCAによるものではありません。

証明書のCAは、証明書内のissuerフィールドで指定されます。証明書は、この発行者をサブジェクトとする信頼できる証明書を探して検証され、この証明書を使用して署名が検証されます。

つまり、信頼できるCAによってSHA-1で署名された有効な証明書が攻撃者にあり、この署名を独自の偽の証明書に使用したい場合、偽の証明書には元の証明書と同じ発行者情報が必要であり、同じSHA-1。両方が指定されている場合、この偽の証明書は元の証明書と同じように信頼されていると見なされます。攻撃者は偽の証明書の内容を完全に制御できるため、発行者フィールドも制御でき、必要に応じて設定できます。

Peter Green · Answer

SHA1については多くの警戒心があります。

ハッシュ関数に対する攻撃にはさまざまなタイプがあることを理解してください。 sha1に対する現在の衝突攻撃では、攻撃者は次のことを実行できます。

衝突する2つのファイルに共通のプレフィックスを選択しますbefore「衝突ブロック」を生成します。
2つの衝突するファイルに共通のサフィックスを選択しますafter「衝突ブロック」を生成します。

これは、merkle-damgaurdハッシュ関数に見られる初期衝突攻撃の典型です。

通常、このタイプの衝突攻撃のエクスプロイトは次の形式を取ります。

攻撃者はゴミを簡単に隠すことができ、合理的に複雑なロジックを実装できるファイル形式を選択します（pdfはポスターの子です）。
攻撃者は、pdfヘッダーといくつかのロジックを含む共通のプレフィックスを作成し、衝突ブロックをスキップします。
攻撃者は衝突ブロックを生成します。
攻撃者は、衝突ブロックを調べ、どの衝突ブロックが存在するかに基づいてドキュメントの見かけのコンテンツを変更する、明確な共通の接尾辞を生成します。
攻撃者は被害者に「良い」文書に署名するように説得します。
攻撃者は署名を「悪」なドキュメントに移植します。

攻撃者は今や明らかに被害者によって署名された「邪悪な」文書のコピーを持っています。彼はその文書を使用して、被害者が実際には同意しなかったことに同意したことを人々に納得させることができます。

これはCAとどのように関連していますか？

攻撃者は、CAによって署名された正当な証明書からの証明書を悪質な証明書に変換することを目的としています。正当な証明書は、攻撃者が正当に所有しているドメインのものであるか、悪質な証明書は、攻撃者がなりすましたいドメインのものであるか、「中間証明書」であり、攻撃者がなりすましたいドメインの証明書を自由に署名できるようにします。

これは、2つの理由から、上記の攻撃よりもはるかに困難です。

CAは、証明書の内容を顧客に限定的にしか制御できません。
Afaict証明書の形式には、PDFのようなもので可能なトリッキーなロジックのレベルの余地がありません。

このため、私は信じられません。CAに対する「単純な」衝突攻撃を悪用することは可能です。

さらに危険なのは、「明確に選択された接頭辞」衝突攻撃です。現在、SHA1で明確に選択されたプレフィックス衝突攻撃は知られていません。 MD5の場合、最初の基本的な衝突が発見されてから約5年後に発見されました。

この場合、攻撃者はできます。

選択した2つの異なるプレフィックスを選択しますbefore衝突ブロックを生成します。
単一の一般的に選択されたサフィックスafterを選択して、衝突ブロックを生成します。

「悪意のある」ファイルのコンテンツを「適切な」ファイル内に隠す必要がないため、明確に選択されたプレフィックス衝突攻撃ははるかに危険です。明らかにランダムなゴミの小さなブロックだけを非表示にする必要があります。また、攻撃者がファイルのコンテンツのほとんどを予測できる限り、攻撃者がファイルのごく一部を制御するだけでよいことも意味します。

ただし、まだ問題があります。証明書には「シリアル番号」があります。シリアル番号は証明書の最初のフィールドの1つであるため、衝突がブロックされる前に必ず発生するため、攻撃者は事前に予測できる必要があります。

CA /ブラウザフォーラムでは、CAはシリアル番号に少なくとも64ビットのランダム性を含める必要があります。 CAがルールに従っている場合、攻撃者がシリアル番号を予測することは事実上不可能であるはずです。

CAがずさんで、ランダムなシリアル番号を使用しない場合のOTOHは、選択された個別のプレフィックスコリジョン攻撃の利用がより現実的になります。そのような攻撃は、学者のグループによってMD5で成功裏に実証されました。攻撃が実証されると、問題のCAはシリアル番号をランダム化し始めました。

SHA1で選択されたプレフィックス衝突攻撃が見つかった場合and攻撃者は十分にずさんなCAを見つけることができ、偽造されたSHA1証明書を作成できる可能性があります。

これは、ブラウザベンダーがSHA1を排除することを決定するのに明らかに十分です。

ハッシュ関数に対する最終的な攻撃は、プリイメージ攻撃です。このような攻撃では、攻撃者は既存の証明書から新しい証明書に署名を移植する可能性があります。ただし、プリイメージ攻撃は衝突攻撃よりもはるかに困難です。 AfaictはMD5プリイメージ攻撃を使用しても、まだ計算上実行不可能です。