web-dev-qa-db-ja.com

エンドエンティティ証明書より上の証明書がSHA-1ベースであっても問題ないのはなぜですか?

エンドエンティティ用のSHA-1ベースの証明書の段階的廃止、およびGoogle Chromeに概説されている手順により、SHA-1証明書が以前に期限切れにならないように、より積極的な警告を段階的に表示することについて聞いた2016年1月1日。

彼らのブログの一番下で、SHA-1を徐々に日没、これについて、彼らは言及し、引用します:

注:信頼されたルート証明書のSHA-1ベースの署名は問題ありません。TLSクライアントは、ハッシュの署名ではなくIDによってそれらを信頼するためです。

ここでは違いがわかりません。

身元は、提唱者(上位機関)が証明書のハッシュに署名することによって証明されませんか?

8
Breakhty

これは、「エンドエンティティより上の証明書」ではなく、「ルート証明書」のみです。

pure X.509 には、「ルート証明書」などはありません。 証明書があり、トラストアンカーがあります。証明書には、公開鍵と、その鍵を所有するエンティティの名前が含まれ、別のエンティティ(「上位の証明機関」)によって署名されています。この署名プロセスはどこかで開始する必要があり、そのどこかが「トラストアンカー」です。トラストアンカーは、名前と公開鍵です。

X.509は、どのエンティティがトラストアンカーをエンコードするかを指定していません。トラストアンカーは、既知のアプリオリであり、ネットワーク上で交換されるものではないためです。ただし、トラストアンカーを格納するtraditionalメソッドは、証明書と同じ形式を使用することです。証明書には、とりわけ、上位CAからの署名用の非オプションフィールドが含まれています。トラストアンカーの新しい形式を定義する代わりに、「署名フィールド」に自己署名を入力するのが伝統です。したがって、ルート証明書:自己署名証明書としてエンコードされたトラストアンカーが生成されます。

しかし、その自己署名は無意味です!セキュリティ上の価値は一切ありません。同様に、誰もそれを検証しません(*)。したがって、疑わしいと思われるハッシュ関数の使用に問題はありません。

(*)自己署名証明書はのみをルートとして使用でき、それ以外のものとして使用できないため、一部のシステムはその署名をヒューリスティックにチェックします。しかし、これはセキュリティ機能ではありません。これは、ユーザーインターフェイスの利便性のためであり、その署名の安全性に依存していません。したがって、SHA-1またはMD5またはMD2で問題はありません。

13
Tom Leek

身元は、提唱者(上位機関)が証明書のハッシュに署名することによって証明されませんか?

ルート証明書はシステムに組み込まれています(またはブラウザーに同梱されています)。それらは信頼チェーンの終わりであり、それらに署名したより高い権限はありません。自己署名されていますが、署名が必要なためです。署名をチェックする必要がないため、署名ハッシュのセキュリティは重要ではありません。

つまり、リーフ証明書とチェーン証明書の信頼は、署名者への信頼に基づいており、署名によって表現されます。この信頼を偽造できないようにする必要があります。つまり、SHA-1の代わりにSHA-256を使用します。自己署名証明書の場合、これはそれ自体が信頼できることを意味します。誰かがどれだけ自分を信頼するかは関係ありません。他の人がどれだけ信頼できるかだけが関係します(つまり、組み込みの証明書は完全な信頼を意味します)。

この場合の信頼とは、誰かが証明書を発行したという信頼のみを意味することに注意してください。サイトの安全性を意味するものではありません。ハッカーは簡単に証明書を入手することもできます!

4
Steffen Ullrich