Verstehe ich mich mit dem Verständnis, dass es sich bei der Suche nach einer Kollision um die Verisign-Stammzertifizierungsstelle handeln würde, um daraus ein Intermediate und dann ein Serverzertifikat zu generieren, das einem Browser oder Betriebssystem als vertrauenswürdig eingestuft wird.
Sie irren sich meistens darüber, dass Sie eine Stammzertifizierungsstelle nur mit einer Hashkollision verkörpern können, da ein erfolgreicher Angriff auf das Zertifikat der Stammzertifizierungsstelle mehr Schritte erfordern würde, wie nachstehend ausführlich beschrieben wird.
Sie können jedoch, wie nachstehend erläutert, eine Zwischen-CA mit einer Hash-Kollision erfolgreich nachahmen.
Kurz gesagt, stellt der Client sicher, dass die RSA-verschlüsselte Signatur eines Zertifikats 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 Zertifizierungsstelle dazu verwendet werden kann, die RSA-verschlüsselte Signatur des Hash des TBS-Zertifikats zu überprüfen, muss man den privaten Schlüssel der Zertifizierungsstelle kennen, um die Signatur zu generieren, die es Ihnen ermöglicht, die Zertifizierungsstelle zu benennen.
Angenommen, Sie könnten eine solche Hash-Kollision des TBS-Teils eines CA-Stammzertifikats generieren, indem Sie das Zertifikat so ändern, dass es einen öffentlichen Schlüssel enthält, für den Sie den privaten Schlüssel kennen. Das Problem besteht darin, dass Ihr geändertes CA-Zertifikat einen anderen öffentlichen Schlüssel als den enthält Das tatsächliche Zertifikat der Zertifizierungsstelle und alle Clients, die ein von der Zertifizierungsstelle signiertes Zertifikat überprüfen, verfügen über eine lokal installierte Kopie des realen Zertifikats der Zertifizierungsstelle. Beim Validieren eines signierten Zertifikats ruft der Client 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 versucht wird, die Signatur eines von dieser Zertifizierungsstelle signierten Zertifikats zu überprüfen.
Um sich als Root-CA auszugeben und eine RSA-verschlüsselte Signatur zu erstellen, würde ein Client darauf vertrauen, dass Sie zunächst eine Kollision des TBS-Teils des Stammzertifikats der Root-CA aus einem von Ihnen generierten TBS-Zertifikat suchen müssen, das ein öffentliches Zertifikat enthält, für das Sie das Private kennen Schlüssel. Sie müssen auch eine solche Kollision finden, die die Überprüfung der RSA-Signatur mit dem öffentlichen Schlüssel der Zertifizierungsstelle durchläuft. Zu diesem Zeitpunkt hätten Sie ein gefälschtes Zertifikat mit einer SHA1-Hash-Kollision und einer RSA-Signatur-Kollision. Wenn Sie dies erreicht haben, müssen Sie schließlich einen Client täuschen, damit er Ihr gefälschtes Zertifikat abruft, wenn Sie nach dem Zertifikat der Stammzertifizierungsstelle suchen, anstatt dessen lokale Kopie des Stammzertifikats der Stammzertifizierungsstelle abzurufen.
In fast allen vorstellbaren Szenarien, in denen Sie all diese Dinge erreichen könnten, hätten Sie viel effizientere Angriffsmöglichkeiten, bei denen es nicht erforderlich war, zuerst eine SHA1-Hashkollision eines Zertifikats zu finden, das einen Ihnen bekannten privaten Schlüssel enthält, der auch einen RSA generiert verschlüsselte Signaturkollision, die den Client dazu bringen muss, die Signaturüberprüfung zu verwenden, anstatt das Zertifikat der echten Stammzertifizierungsstelle zu verwenden, das angesichts der Tatsache, dass der Client ihm vertraut, lokal auf dem Client gespeichert wird.
Ein plausiblerer Angriff wäre stattdessen die Suche nach einer Hashkollision des Zertifikats einer zwischengeschalteten Zertifizierungsstelle, mit der Sie die zwischengeschaltete Zertifizierungsstelle zum Signieren von Zertifikaten verwenden können. Dieser Angriff ist aus zwei Gründen plausibler. Erstens können Sie einen Client dazu bringen, das Zertifikat einer zwischengeschalteten Zertifizierungsstelle herunterzuladen. Der zweite ist die Hashkollision, die anhand einer mit RSA verschlüsselten vertrauenswürdigen Zertifizierungsstelle verifiziert wird. Daher müssen Sie versuchen, den Client zu täuschen vertrauen der Zertifizierungsstelle, die das Zertifikat signiert hat.
Wenn einem Kunden ein Zertifikat von einer Website vorgelegt wird, das von einer zwischengeschalteten Zertifizierungsstelle unterzeichnet wurde, für die er keine lokale Kopie besitzt, wird er beim Versuch, die Zertifizierungsstelle des Vermittlers von der Website herunterzuladen, die das Ticket vorgelegt hat, von der Website, die das Zertifikat in der Website vorgelegt hat erster Platz. In Erinnerung, dass ein Client den Hash des TBS-Teils des Zertifikats dieses Vermittlers übernimmt und dann überprüft, ob die RSA-verschlüsselte Signatur für dieses Zertifikat tatsächlich mit dem öffentlichen Schlüssel einer lokal vertrauenswürdigen Zertifizierungsstelle oder einer Kette von Zertifizierungsstellen signiert wurde, die zu einer lokal vertrauenswürdigen Zertifizierungsstelle führt Ein erfolgreicher Angriff wird nun vereinfacht, um eine Hash-Kollision des TBS-Teils des Zertifikats der Zertifizierungsstelle eines gültigen Vermittlers zu erzeugen.
Einmal kann man den öffentlichen Schlüssel eines nachprüfbaren CA-Zertifikats durch einen öffentlichen Schlüssel ersetzen, für den der private Schlüssel bekannt ist, und dann andere Bytes nach Bedarf ändern, um eine Hash-Kollision mit dem überprüfbaren Zertifikat zu erzeugen. Dieses geänderte Zertifikat kann dann zum Signieren anderer Zertifikate verwendet werden. Solche signierten Zertifikate können dann beispielsweise neben diesem modifizierten Zwischenzertifikat auf einem Webserver installiert werden. Wenn ein Client das Zertifikat abruft, liest es den Fingerabdruck der Zertifizierungsstelle, die es signiert hat. Wenn der Client das Zertifikat dieses Vermittlers nicht lokal installiert hat, lädt er das Zertifikat von der Website herunter, indem er das Zertifikat abruft, das er überprüft. Der Client generiert dann den Hash der TBS-Website. ' s Zertifikat und vergewissern Sie sich, dass es mit dem öffentlichen Schlüssel des heruntergeladenen CA-Zertifikats digital signiert wurde. Dieser Prozess ist rekursiv, indem er einen Hash des TBS-Teils des heruntergeladenen Zwischenzertifikats erstellt und den Fingerabdruck der Zertifizierungsstelle liest, die das Zwischenzertifikat signiert hat. Anschließend sucht es nach dem CA-Zertifikat und verifiziert, dass die RSA-verschlüsselte Signatur des Zwischenzertifikats mit dem öffentlichen Schlüssel der ausstellenden Zertifizierungsstelle generiert wurde, um den Hash des TBS-Zertifikats im Zwischenzertifikat zu signieren. Da der Vermittlerhash des TBS-Zertifikats im Vermittlerzertifikat mit dem Hash des ursprünglichen Vermittlerzertifikats und der Unterschrift auch mit der Unterschrift der ursprünglichen Vermittlerunterschrift übereinstimmt, hat unsere modifizierte Vermittler-CA ' Das Zertifikat wird bestätigt. Der Client wird den Prozess rekursiv abschließen, bis er ein von einer vertrauenswürdigen Zertifizierungsstelle ausgestelltes Zertifikat findet und welcher Verifizierungspunkt erfolgreich ist und wir die Zwischen-Zertifizierungsstelle erfolgreich nachahmten.
NIST und die NSA warnten das
"SHA-1 sollte nicht vor Januar 2016 vertrauenswürdig sein, da es zunehmend praktikabler ist, dass ein gut finanzierter Angreifer oder eine Regierung eine SHA-1-Hashkollision finden könnte, die es ihnen ermöglicht, sich als SSL-Website auszugeben", und Microsoft und Google begannen vor einem Jahr zu warnen später von Verbindungen, die SHA-1 verwenden.
http://windowsitpro.com/security/ihr-organisationsverwendung-sha-1-ssl-zertifikate
Es ist wichtig, dass die Zertifikatskette mit SHA-2-Zertifikaten verschlüsselt wird. (Eine Zertifikatskette besteht aus allen Zertifikaten, die zur Zertifizierung des Endzertifikats erforderlich sind.) Dies bedeutet, dass alle Zwischenzertifikate SHA-2 nach dem 1. Januar 2017 verwenden müssen. Normalerweise stellt Ihre Zertifizierungsstelle die Zertifikate der Zwischenzertifizierungsstelle und der Stammzertifizierungsstelle bereit das SHA-2-Zertifikat. Manchmal stellen sie einen Link zum Herunterladen der Zertifikatskette bereit. Es ist wichtig, dass Sie diese Kette mit SHA-2-Zertifikaten aktualisieren. Andernfalls vertraut Windows Ihrem neuen SHA-2-Zertifikat möglicherweise nicht.
Stammzertifikate sind eine andere Geschichte. Dies können tatsächlich SHA-1-Zertifikate sein, da Windows diesen Zertifikaten implizit vertraut, da das Betriebssystem dem öffentlichen Schlüssel des Stammzertifikats direkt vertraut. Ein Stammzertifikat ist selbstsigniert und wird nicht von einer anderen Instanz signiert, die über die Berechtigung verfügt.
Aus demselben Grund kann jedes selbstsignierte Zertifikat den SHA-1-Algorithmus verwenden. Beispielsweise generiert Microsoft Exchange Server während der Installation selbstsignierte SHA-1-Zertifikate. Diese Zertifikate sind von der neuen SHA-2-Richtlinie ausgenommen, da sie nicht an eine Zertifizierungsstelle gebunden sind. Ich gehe jedoch davon aus, dass zukünftige Versionen von Exchange SHA-2 in selbstsignierten Zertifikaten verwenden werden.