ブラウザーが1024ビットRSAを非推奨にしたのにSHA-1を保持したのはなぜですか？
私はMozillaのセキュリティブログを読んでいました 1024ビットのRSAキーによる証明書の段階的削除 。証明書は10〜30年間攻撃に耐えなければならないため、一部のブラウザはCAおよび下位CAの1024ビットRSAを非推奨にしています。
私の知る限り、1024ビットのRSAは、整数因数分解と数値フィールドふるいの進歩により、約80ビットのセキュリティを提供します。 80ビットのセキュリティは、ほとんどの攻撃者の手の届かないところにあります。
Marc Stevenの HashClash により、SHA-1は約61ビットのセキュリティを提供します。 61ビットのセキュリティは、特に AmazonのEC2 または OpenStackのNova で計算時間が非常に安価な場合、多くの攻撃者の手の届く範囲に十分あります。
私が知っている暗号に対する2つの現実の攻撃は（1） Texas Instruments署名鍵 であり、これは512ビットの鍵を因数分解しました。 （2） Flame は、弱い/負傷した署名アルゴリズムでの衝突を悪用しました。 TIから、攻撃者は60ビット程度のセキュリティでキーを因数分解しようと知っています。そして、Flameからknow効果的なセキュリティが約60ビット程度の場合、攻撃者はダイジェスト機能を攻撃します。
ブラウザーが1024ビットRSAでCAおよび下位CAを非推奨にしたのに、SHA-1を保持したのはなぜですか？
CA SHA1署名を壊してもどこにも届きません。正当な署名と同じ署名で公開証明書を再作成できますが、正当な証明書の公開鍵は、ブラウザーに保存されているため、証明書の検証に引き続き使用されます。
証明書を正常に偽造するには、次のいずれかを破る必要があります。
- チェーンのRSA秘密鍵
- 中間機関のチェックサム
- sSL/TLS証明書のチェックサム
チェックサムは必ずしもルートCAと同じアルゴリズムを使用する必要はありません。SHA1でハッシュされたルートCAは、SHA256でハッシュされたTLS証明書に署名するために使用できます。
転送秘密の暗号スイートは普遍的に使用されるわけではないため、通信のコンテンツを安全に保つ必要がある限り、エンドエンティティ証明書のRSAキーを安全に保つ必要があります。一方、ハッシュ関数は、証明書が検証されるときにのみ安全である必要があります。
さらに、ハッシュ関数の場合、さまざまな種類の攻撃に対するセキュリティを区別する必要があります（RSAとは異なり、ほとんどが因数分解されているか、分解されていないため、中間にありません）。ハッシュ関数を引き離す最も簡単な攻撃は、単純な衝突攻撃ですが、あまり有用ではありません。ハッシュ関数に対する最も有用な攻撃は、プリフィックスとサフィックスが柔軟なプリイメージ攻撃ですが、MD5でさえもこれを達成した人はいません。その間に、個別に選択されたプレフィックスと一般的に選択されたサフィックスを持つ衝突攻撃があります。これらは、発行ポリシーが不十分なCAと組み合わせて偽の証明書を作成することができますが、簡単な作業ではありません。
それでも、中間およびエンドエンティティの証明書については、主要なブラウザareがSHA1の段階的廃止を推進しています。ルート証明書の場合、ダイジェストアルゴリズムは基本的に無関係です。クライアントはすでにストアにルート証明書を持っているため、信頼できないソースから取得する必要はありません。