非衝突耐性ハッシュ関数が自己生成情報に署名するのに安全でないと考えられるのはなぜですか
2番目のプリイメージには耐性がありますが、衝突には耐性がないハッシュ関数があるとします。
次に、攻撃者は、一対の異なるメッセージMとM 'を作成できます。Mは無害でM'は悪意のあるものであり、どちらの場合も署名は有効です。
同じエンティティによって作成されたデータのオリジンを認証するために署名が使用される設定で、これが問題である理由がわかりません。そのため、あるソフトウェアに署名した場合、彼は「このコンテンツは自分で作成したもので、マルウェアが含まれている場合は、私を責めます」と主張しています。キーの場合：「この公開キーには対応する秘密キーがあり、それにアクセスできます」。
衝突を引き起こし、自己生成データに署名した場合...彼はまだ上記のステートメントを主張しています。
それでは、そのようなハッシュ関数は、自己署名証明書やコード署名などに対して安全であると考えるべきでしょうか？
デジタル署名は、次の3つのことを行うように設計されています。
- 署名されたデータの整合性を確保する
- 署名者によるある程度の否認防止を作成する
- あなたが言及した目的は、メッセージの発信元を認証することです
衝突の影響を受けやすいハッシュ関数の最大の問題は、最初の設計目標をすぐに失うことです。 2つの異なるメッセージに同じ署名を付けることができる場合、どちらが本物であるかはわかりません。
それでは、同じ署名で2つの異なるメッセージに署名できるとしたら、何が重要なのでしょうか。彼らはどちらも私から来て、私に責任を負わせることができることをまだ知っていますか？まあ、たぶん。これが悪用されるケースは確かにいくつかありますが、本当の問題ではないので無視します。実際の問題は、同じ署名を持つ2つのメッセージを作成し、そのうちの1つを送信して他の誰かが署名できるようにすることです。
ここでの正規の例は x.509（SSL/TLS）証明書リクエスト です。この場合、設計が不十分な証明書署名プロセスを利用して、認証局に1つのサブジェクトの証明書または1セットのプロパティ（エンドエンティティ証明書など）で署名するように誘導できます。攻撃者が生成した2番目の証明書（攻撃者が制御していないサブジェクトまたはCA証明書に対してが発行されなかった）こと、およびその不正な証明書は、最初の無害な証明書に関連付けられた完全に有効な署名。
Xanderの答えは基本的に正しいです。問題は、他の誰かが無害なメッセージに署名し、悪意のあるメッセージの署名を使用することです。衝突が発生した場合、メッセージを直接決定することはできませんが、メッセージの一部を決定することはよくあります。たとえば、「My name is KOLANICH」に署名して「My name is Josiah」と交換するように説得することはできませんでした。ハッシュが一致する可能性はほとんどありません。しかし、「参照コードZZZZZZZZZZの靴にはアカウント番号X $ 50をお支払いください。」と署名してもらうことができるかもしれません。そして、「参照番号YYYYYYYYYYのアカウント番号X $ 50000をお支払いください。」に置き換えます。このシナリオでは、衝突を起こすために必要なYとZを選択します。
それらが安全でないと考えられる追加の理由は、炭鉱の状況におけるカナリアです。 2番目のプリイメージを見つけるよりも、衝突を見つける方が簡単です。厳密には、2回目のプリイメージ攻撃があった場合、自動的に衝突が発生しますが、その逆は発生しないためです。ただし、衝突を検出する手法を使用しても2番目のプリイメージが直接得られるわけではありませんが、脆弱性が表面化する可能性が高いハッシュ関数に一定の規則性があることが示唆されています。
まあ、理論的にはあなたは正しいでしょう。 いくつかの非常に特殊なケースでは、これらのハッシュは完全には壊れません。
ただし、特に注意する必要があり、おそらく「自己生成」データの一部は実際には安全ではない可能性があります。会計士が作成した小切手は、会計士が自己生成したものだと思いますか？どうやらそうですが、実際には、別のコンテンツの署名を生成するために使用できる外部制御データが含まれています。
それでは、そのようなハッシュ関数は、自己署名証明書やコード署名などに対して安全であると考えるべきでしょうか？
実際には自己署名証明書を検証しないため、使用されているハッシュ関数を無視できます。
一方で、コード署名については安全だとは思いません。おそらく外部ライブラリを使用しているため、サードパーティがライブラリを準備して、コンパイル時にコードブロックを悪意のあるコードブロックに置き換えて、それを衝突させる可能性があります。
一部の特定のケースでは「壊れたハッシュ」が機能する可能性がありますが、壊れていない完全なハッシュ関数があり、そのような注意深い詳細を必要としない場合、可能であればそれらを使用する方がはるかに良いことに注意してください。
最後に、攻撃は時間とともに悪化することを覚えておいてください。その機能のセキュリティマージンは、衝突に強いものよりもはるかに厳しくなっています。ある日実行不可能と思われる攻撃、または衝突耐性がなく、それほど長くないハッシュ関数は、新しい発見でさらに破られる可能性があり、すぐに変更する必要があります。