SHA1シグネチャを持つルートCAがリスクではない理由
たとえば、sha1ハッシュ署名を持つルートCAがあるVerisignのWebサイトを見てみましょう。衝突を見つけるためのものであると誤解しましたが、VerisignルートCAになりすまして、ブラウザまたはOSによって信頼される中間証明書を生成してからサーバー証明書を生成する可能性があります。
https://www.entrust.com/need-sha-2-signed-root-certificates/ の状態：
つまり、ソフトウェアはルート証明書の公開鍵を直接信頼するため、ルート証明書の署名は検証されません。ルート証明書は自己署名されており、権限を与えられた別のエンティティによって署名されていません。ルート証明書は、オペレーティングシステムまたはブラウザ開発者が管理するルート証明書プログラムを通じて権限を取得します。
そして、Googleリンクを参照します： https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html
注：信頼されたルート証明書のSHA-1ベースの署名は問題ではありません。TLSクライアントは、ハッシュの署名ではなく、IDによってそれらを信頼するためです。
私が新しいブラウザの作者であると仮定します-SuperUserBrowser。ブラウザに同梱されているルート証明書がハッシュ署名以外のものであることを他にどのように信頼できますか？
SHA1署名のあるルートCAが「問題ではない」のはなぜですか？
衝突を見つけるためのものであると誤解しましたが、VerisignルートCAになりすまして、ブラウザまたはOSによって信頼される中間証明書を生成してからサーバー証明書を生成する可能性があります。
あなたは間違っている。
署名自体のセキュリティに関しては：
証明書の署名は、信頼チェーンを構築するために、その証明書の発行者を検証するために使用されます。ルートCAは、事前に信頼されている（つまり、OSのトラストストアに格納されている）ため、信頼チェーンの信頼できる端であるため、ルートCAの発行者を検証する必要はなく、ルートCAの署名は問題にならない。
また、弱いハッシュアルゴリズムで署名されたルートCAを使用して新しい証明書を作成する場合：
別の証明書に署名する（つまり、リーフまたは中間証明書を作成する）には、CAの秘密鍵が必要です。証明書が自己署名されている（つまり、取得しようとしている秘密鍵を使用して署名されている）場合でも、証明書の公開鍵と一致する秘密鍵は、証明書の発行者によって発行された署名から取得できません。
証明書への署名は、最初に不可逆ハッシュアルゴリズムを使用して証明書の重要な部分をハッシュし、次に発行者の秘密鍵で「暗号化」することによって行われます。新しい証明書の署名に必要な秘密鍵を取得するには、暗号化（RSAまたはECC）を攻撃する必要があります。つまり、ハッシュされた証明書を「暗号化」するときに同じ署名になる鍵を見つけます。ただし、RSA/ECC署名はまだ壊れていないため、秘密鍵を抽出できず、この鍵を使用して新しい証明書を生成できません。この証明書で署名された新しい証明書を作成する別の方法は、同じハッシュ値になる証明書を作成することです。ただし、SHA-1は衝突攻撃に対して脆弱です（つまり、同じ出力を持つ2つの入力を見つけます）が（MD5とは対照的に）現在、プリイメージ攻撃（特定の出力の入力を見つける）に対して脆弱ではありません。つまり、この攻撃ベクトルも失敗します。
衝突を見つけるためのものであると誤解しましたが、VerisignルートCAになりすまして、ブラウザまたはOSによって信頼される中間証明書を生成してからサーバー証明書を生成する可能性があります。
以下で詳細に説明するように、ルートCAの証明書に対する攻撃が成功するためには、より多くの手順が必要になるため、ハッシュ衝突だけでルートCAになりすますことができると誤解されています。
ただし、以下で説明するように、ハッシュの衝突のみを使用して中間CAを偽装することができます。
つまり、証明書のRSA暗号化署名が、CAの公開鍵を使用して生成されるRSA暗号化署名と一致し、証明書内のTBS証明書のバイトのハッシュに署名することを確認します。 CAの公開鍵を使用してTBS証明書のハッシュのRSA暗号化署名を検証できますが、CAの偽装を可能にする署名を生成するには、CAの秘密鍵を知っている必要があります。
CAルート証明書のTBS部分のハッシュコリジョンを、秘密鍵がわかっている公開鍵を含むように変更することによって生成できたとすると、変更されたCA証明書には、 CAの実際の証明書と、CAによって署名された証明書を検証するクライアントには、ローカルにインストールされたCAの実際の証明書のコピーがあります。署名された証明書を検証するとき、クライアントは署名された証明書から署名者の拇印または署名を取得し、そのCAによって署名された証明書の署名を検証しようとするときに、その証明書のローカルコピーの公開鍵を取得します。
したがって、ルートCAになりすましてRSA暗号化署名を生成するには、クライアントはまず、プライベートを知っているパブリックを含む、生成するTBS証明書からルートCAの証明書のTBS部分の衝突を見つける必要があると信頼します。キー。また、CAの公開鍵を使用してRSA署名検証に合格するような衝突を見つける必要もあります。この時点で、SHA1ハッシュの衝突とRSA署名の衝突の両方が発生した偽造証明書が作成されます。どういうわけかすべてこれを達成した場合、ルートCAの証明書のローカルコピーを取得するのではなく、ルートCA証明書を探すときに、偽造された証明書を取得するようにクライアントをだます必要があります。
これらすべてのことを実行できるほぼすべての想像できるシナリオでは、RSAも生成する既知の秘密キーを含む証明書のSHA1ハッシュの衝突を最初に見つける必要がない、はるかに効率的な攻撃の機会があります。暗号化された署名の衝突。これにより、クライアントをだまして署名の検証に使用させる必要があり、実際のルートCAの証明書を使用します。この証明書は、クライアントが信頼しているため、クライアントにローカルに保存されます。
代わりに、より可能性の高い攻撃は、中間CAの証明書のハッシュ衝突を見つけることであり、これを使用して中間CAを偽装して証明書に署名できます。この攻撃は、2つの理由でより可能性が高くなります。1つはクライアントに中間CAの証明書を簡単にダウンロードさせることができ、2つ目はハッシュの衝突が信頼できるCAのRSA暗号化署名に対して検証するため、クライアントをだまそうとする必要があることがわかっています。証明書に署名したCAを信頼します。
ローカルコピーがない中間CAによって署名されたWebサイトからの証明書がクライアントに提示された場合、クライアントは、証明書を提示したWebサイトからチケットを提示したWebサイトから中間CAをダウンロードしようとします。最初の場所。クライアントがこの仲介者の証明書のTBS部分のハッシュを取得し、この証明書のRSA暗号化署名がローカルで信頼されたCAまたはローカルで信頼されたCAにつながるCAのチェーンを使用して実際に署名されていることを確認することを思い出してください。 、攻撃が成功すると、有効な仲介者のCAの証明書のTBS部分のハッシュ衝突が生成されるようになりました。
検証可能な中間CAの証明書の公開鍵を、秘密鍵がわかっている公開鍵に置き換えたら、検証可能な証明書とのハッシュ衝突を生成するために必要に応じて他のバイトを変更できます。この変更された証明書は、他の証明書に署名するために使用できます。このような署名付き証明書は、たとえば、この変更された中間証明書と一緒にWebサーバーにインストールできます。クライアントが証明書を取得すると、署名したCAの拇印を読み取ります。クライアントにこの仲介者の証明書がローカルにインストールされていない場合、クライアントは、検証している証明書を取得したWebサイトから証明書をダウンロードします。次に、クライアントはTBS Webサイトの証明書のハッシュを生成し、ダウンロードした中間CA証明書の公開鍵を使用してデジタル署名されていることを確認します。このプロセスは再帰的で、ダウンロードした中間証明書のTBS部分のハッシュを作成し、中間証明書に署名したCAの拇印を読み取ります。次に、そのCAの証明書を検索し、発行元のCAの公開キーを使用して中間証明書のRSA暗号化署名が生成され、中間証明書のTBS証明書のハッシュに署名されたことを確認します。中間証明書のTBS証明書の中間ハッシュは元の中間証明書のハッシュと一致し、署名は元の中間署名の署名とも一致するため、変更された中間CAの証明書が検証されます。クライアントは、信頼するCAによって発行された証明書が見つかるまでプロセスを再帰的に完了し、どのポイントの検証が成功し、中間CAの偽装に成功します。
NISTとNSAは、
「資金の豊富な攻撃者や政府がSHA-1ハッシュの衝突を発見し、SSL Webサイトになりすますことを可能にする実用性が高まっているため、SHA-1は2016年1月を過ぎて信頼されるべきではありません」とMicrosoftとGoogleは1年警告を始めましたSHA-1を使用する接続のそれ以降。
http://windowsitpro.com/security/your-organization-using-sha-1-ssl-certificates
証明書チェーンはSHA-2証明書で暗号化することが重要です。 （証明書チェーンは、最終証明書の認証に必要なすべての証明書で構成されます。）つまり、中間証明書も2017年1月1日以降にSHA-2を使用する必要があります。通常、CAは中間およびルートCA証明書を提供するときに、それらを提供しますSHA-2証明書。場合によっては、証明書チェーンをダウンロードするためのリンクが提供されます。このチェーンをSHA-2証明書で更新することが重要です。そうしないと、Windowsが新しいSHA-2証明書を信頼しない可能性があります。
ルート証明書は別の話です。 OSはルート証明書の公開鍵を直接信頼するため、Windowsはこれらの証明書を暗黙的に信頼するため、これらは実際にはSHA-1証明書になる可能性があります。ルート証明書は自己署名されており、権限を与えられた別のエンティティによって署名されていません。
同じ理由で、自己署名証明書はSHA-1アルゴリズムを使用できます。たとえば、Microsoft Exchange Serverはインストール中に自己署名SHA-1証明書を生成します。これらの証明書はCAにチェーンされていないため、新しいSHA-2ポリシーから除外されます。ただし、Exchangeの今後のリリースでは、自己署名証明書でSHA-2を使用する予定です。