Warum sind Root-CAs mit SHA1-Signaturen kein Risiko

Irre ich mich mit dem Verständnis, dass man, wenn man eine Kollision findet, sich als Verisign-Stamm-CA ausgeben und damit ein Zwischen-und dann Server-Zertifikat generieren könnte, dem ein Browser oder ein Betriebssystem vertrauen würde.

Sie irren sich meistens, wenn Sie sich mit nur einer Hash-Kollision als Root-CA ausgeben können, da ein erfolgreicher Angriff auf das Zertifikat einer Root-CA weitere Schritte erfordern würde, wie unten ausführlich erläutert.

Sie könnten jedoch, wie unten erläutert, geben Sie sich erfolgreich als Zwischen-CA aus, indem Sie nur eine Hash-Kollision verwenden.

Kurz gesagt, Client überprüft, ob die RSA-verschlüsselte Signatur auf einem Zertifikat mit der RSA-verschlüsselten Signatur übereinstimmt, die mit dem öffentlichen Schlüssel der Zertifizierungsstelle generiert wird, um den Hash der Bytes des TBS-Zertifikats in diesem Zertifikat zu signieren. Während der öffentliche Schlüssel der CA verwendet werden kann, um die RSA-verschlüsselte Signatur des Hash des TBS-Zertifikats zu überprüfen, müsste man den privaten Schlüssel der CA kennen, um die signatur, mit der Sie sich als CA ausgeben können.

Angenommen, Sie könnten eine solche Hash-Kollision des TBS-Teils eines CA-Stammzertifikats erzeugen, indem Sie ihn so ändern, dass er einen öffentlichen Schlüssel enthält, für den Sie den privaten Schlüssel kennen, besteht das Problem darin, dass Ihr geändertes CA-Zertifikat einen anderen öffentlichen Schlüssel als das tatsächliche Zertifikat der CA enthält und alle Clients, die ein von der CA signiertes Zertifikat überprüfen, eine lokal installierte Kopie des tatsächlichen Zertifikats der CA haben. Bei der Validierung eines signiertes Zertifikat Der Client ruft den Fingerabdruck oder die Signatur des Unterzeichners aus dem signierten Zertifikat ab und ruft den öffentlichen Schlüssel seiner lokalen Kopie dieses Zertifikats ab, wenn er versucht, die Signatur eines von dieser Zertifizierungsstelle signierten Zertifikats zu überprüfen.

Um sich als Root-CA auszugeben und eine RSA-verschlüsselte Signatur zu generieren, würde ein Client daher darauf vertrauen, dass Sie zuerst eine Kollision des TBS-Teils des Zertifikats der Root-CA aus einem TBS-Zertifikat finden müssen, das Sie generieren enthält eine Öffentlichkeit, für die Sie den privaten Schlüssel kennen. Sie müssen auch eine solche Kollision finden, die die RSA-Signaturüberprüfung mit dem öffentlichen Schlüssel der CA besteht. Zu diesem Zeitpunkt hätten Sie ein gefälschtes Zertifikat mit einer SHA1-Hash-Kollision und einer RSA-Signaturkollision. Wenn Sie all dies irgendwie erreicht haben, müssten Sie endlich einen Client austricksen, damit er Ihr gefälschtes Zertifikat abruft, wenn er nach dem Root-CA-Zertifikat sucht, anstatt seine lokale Kopie der Root-CA abzurufen Zertifikat.

In fast allen denkbaren Szenarien, in denen Sie all diese Dinge erreichen könnten, hätten Sie viel effizientere Angriffsmöglichkeiten, bei denen es nicht erforderlich wäre, zuerst eine SHA1-Hash-Kollision eines Zertifikats zu finden, das einen Ihnen bekannten privaten Schlüssel enthält erzeugt auch eine RSA-verschlüsselte Signaturkollision, die den Client dann dazu verleiten muss, sie für die Signaturüberprüfung zu verwenden, anstatt das Zertifikat der realen Stamm-CA zu verwenden, da der Client vertraut ihm, wird lokal auf dem Client gespeichert.

Stattdessen wäre ein plausiblerer Angriff, eine Hash-Kollision des Zertifikats einer zwischengeschalteten CA zu finden, mit der Sie sich als zwischengeschaltete CA zum Signieren von Zertifikaten ausgeben können. Dieser Angriff ist aus zwei Gründen plausibler: Erstens können Sie einen Client leicht dazu bringen, das Zertifikat einer zwischengeschalteten Zertifizierungsstelle herunterzuladen, und zweitens wird der Hash-Code anhand der RSA-verschlüsselten Signatur einer vertrauenswürdigen Zertifizierungsstelle überprüft, sodass keine Notwendigkeit besteht versuchen Sie, den Client dazu zu bringen, der Zertifizierungsstelle zu vertrauen, die das Zertifikat signiert hat.

Wenn einem Kunden ein Zertifikat von einer von einer zwischengeschalteten CA signierten Website vorgelegt wird, für die er keine lokale Kopie hat, versucht er, die CA des Vermittlers von der Website herunterzuladen, auf der das Ticket von der Website präsentiert wurde, auf der das Zertifikat zuerst ausgestellt wurde. Unter Hinweis darauf, dass ein Client den Hash des TBS-Teils des Zertifikats dieses Vermittlers übernimmt und dann die RSA-verschlüsselte Signatur auf diesem Zertifikat wurde in der Tat mit dem öffentlichen Schlüssel einer lokal vertrauenswürdigen CA signiert, oder Kette von CA 's, die zu einer lokal vertrauenswürdigen CA führt, ein erfolgreicher Angriff wird nun vereinfacht, um eine Hash-Kollision des TBS-Teils eines gültigen CA' s Zertifikats eines Zwischengeschalteten zu erzeugen.

Sobald man den öffentlichen Schlüssel des Zertifikats einer verifizierbaren zwischengeschalteten Zertifizierungsstelle durch einen öffentlichen Schlüssel ersetzen kann, für den der private Schlüssel bekannt ist, und dann andere Bytes nach Bedarf ändern kann, um einen Hash zu generieren kollision mit einem verifizierbaren Zertifikat. Dieses geänderte Zertifikat kann dann zum Signieren anderer Zertifikate verwendet werden. Solche signierten Zertifikate können dann beispielsweise neben diesem geänderten Zwischenzertifikat auf einem Webserver installiert werden. Wenn ein Client das Zertifikat abruft, liest er den Fingerabdruck der CA, die es signiert hat. Wenn der Client das Zertifikat dieses Vermittlers nicht lokal installiert hat, lädt er das Zertifikat von der Website herunter, von der es die zertifikat es überprüft. Der Client generiert dann den Hash des Zertifikats der TBS-Website und überprüft, ob es mit dem öffentlichen Schlüssel im heruntergeladenen zwischengeschalteten CA-Zertifikat digital signiert wurde. Dieser Prozess ist rekursiv, da er dann einen Hash des TBS-Teils des heruntergeladenen Zwischenzertifikats erstellt und den Fingerabdruck der CA liest, die das Zwischenzertifikat signiert hat. Anschließend wird das Zertifikat dieser Zertifizierungsstelle gesucht und die RSA-verschlüsselte Signatur auf der das Zwischenzertifikat wurde mithilfe des öffentlichen Schlüssels der ausstellenden Zertifizierungsstelle generiert, um den Hash des TBS-Zertifikats im Zwischenzertifikat zu signieren. Da der zwischengeschaltete Hash des TBS-Zertifikats im zwischengeschalteten Zertifikat mit dem Hash des ursprünglichen zwischengeschalteten Zertifikats übereinstimmt und die Signatur auch mit der Signatur der ursprünglichen zwischengeschalteten Signatur übereinstimmt, wird das Cerfitificate unserer modifizierten zwischengeschalteten CA validiert. Der Client schließt den Vorgang rekursiv ab, bis er ihn findet ein Zertifikat, das von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde und dessen Punktüberprüfung erfolgreich ist, und wir haben uns erfolgreich als zwischengeschaltete Zertifizierungsstelle ausgegeben.

NIST und die NSA warnten, dass

"SHA-1 sollte man nicht trauen Vergangenheit. Januar 2016, weil der zunehmende Praktikabilität, dass ein gut finanzierter Angreifer oder Regierung finden konnten, einen SHA-1-hash-Kollision, so dass Sie vorgeben, eine SSL-Website " und Microsoft und Google begannen ein Jahr später zu warnen verbindungen, die verwenden SHA-1.

Http://windowsitpro.com/security/your-organization-using-sha-1-ssl-certificates

Es ist wichtig, dass die Zertifikatskette mit SHA-2 verschlüsselt wird Zertifikat. (Eine Zertifikatskette besteht aus allen Zertifikaten benötigt, um das Endzertifikat zu zertifizieren.) Dies bedeutet, dass jede Zwischenzertifikate müssen auch nach dem 1. Januar 2017 SHA-2 verwenden. In der Regel stellt Ihre CA die Zwischen-und Root-CA bereit zertifikate, wenn sie stellen Sie das SHA-2-Zertifikat bereit. Manchmal sind sie geben Sie einen Link zum Herunterladen der Zertifikatskette an. Es ist wichtig, dass Sie diese Kette mit SHA-2-Zertifikaten aktualisieren. Andernfalls vertraut Windows möglicherweise Ihrem neuen SHA-2-Zertifikat nicht.

- Root-Zertifikate sind eine andere Geschichte. Diese können tatsächlich SHA-1 zertifikate, da Windows diesen Zertifikaten implizit vertraut da das Betriebssystem dem öffentlichen Stammschlüssel des Zertifikats direkt vertraut. Root zertifikat ist selbstsigniert und ist nicht von einer anderen Entität signiert, die wurde Autorität gegeben.

Aus demselben Grund kann jedes selbstsignierte Zertifikat das SHA-1 verwenden Algorithmus. Zum Beispiel generiert Microsoft Exchange Server selbstsignierte SHA-1-Zertifikate während der Installation. Diese Zertifikate sind von der neuen SHA-2-Richtlinie ausgenommen, da sie nicht an a CA. Ich erwarte jedoch, dass zukünftige Versionen von Exchange SHA-2 verwenden werden in selbstsignierten Zertifikaten.