Irre ich mich mit dem Verständnis, dass jemand, der eine Kollision findet, sich als Verisign-Stammzertifizierungsstelle ausgeben und daraus ein Zwischen- und dann ein Serverzertifikat generieren könnte, dem ein Browser oder ein Betriebssystem vertrauen würde.
Sie irren sich meistens darüber, dass Sie sich mit nur einer Hash-Kollision als Stammzertifizierungsstelle ausgeben können, da ein erfolgreicher Angriff auf das Zertifikat einer Stammzertifizierungsstelle weitere Schritte erfordern würde, wie nachstehend ausführlich erläutert.
Wie unten erläutert, können Sie sich jedoch erfolgreich als Zwischen-Zertifizierungsstelle ausgeben, indem Sie nur eine Hash-Kollision verwenden.
Kurz gesagt, der 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 Zertifizierungsstelle verwendet werden kann, um die RSA-verschlüsselte Signatur des Hash des TBS-Zertifikats zu überprüfen, muss der private Schlüssel der Zertifizierungsstelle bekannt sein, um die Signatur zu generieren, mit der Sie sich als Zertifizierungsstelle ausgeben können.
Angenommen, Sie konnten eine solche Hash-Kollision des TBS-Teils eines CA-Stammzertifikats generieren, indem Sie ihn so ändern, dass er 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 tatsächlichen Zertifikats der Zertifizierungsstelle. Bei der Validierung eines signierten Zertifikats ruft der Client den Fingerabdruck oder die Signatur des Unterzeichners vom 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 Stammzertifizierungsstelle auszugeben und eine RSA-verschlüsselte Signatur zu generieren, würde ein Client darauf vertrauen, dass Sie zuerst eine Kollision des TBS-Teils des Zertifikats der Stammzertifizierungsstelle aus einem von Ihnen generierten TBS-Zertifikat suchen müssen, das eine öffentliche Datei enthält, für die Sie die 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 besteht. Zu diesem Zeitpunkt hätten Sie ein gefälschtes Zertifikat mit einer SHA1-Hash-Kollision und einer RSA-Signaturkollision. Wenn Sie dies alles irgendwie erreicht haben, müssten Sie schließlich einen Client austricksen, damit dieser Ihr gefälschtes Zertifikat abruft, wenn er nach dem Zertifikat der Stammzertifizierungsstelle sucht, anstatt seine lokale Kopie des Zertifikats der Stammzertifizierungsstelle abzurufen.
In fast allen denkbaren Szenarien, in denen Sie all diese Dinge erreichen könnten, hätten Sie viel effizientere Angriffsmöglichkeiten, bei denen Sie nicht zuerst eine SHA1-Hash-Kollision eines Zertifikats finden müssen, das einen Ihnen bekannten privaten Schlüssel enthält, der auch einen RSA generiert verschlüsselte Signaturkollision, die den Client dazu verleiten muss, sie für die Signaturüberprüfung zu verwenden, anstatt das Zertifikat der echten Stammzertifizierungsstelle zu verwenden, das, da der Client ihm vertraut, lokal auf dem Client gespeichert wird.
Ein plausiblerer Angriff wäre stattdessen, eine Hash-Kollision des Zertifikats einer Zwischenzertifizierungsstelle zu finden, mit der Sie sich als Zwischenzertifizierungsstelle ausgeben können, um Zertifikate zu signieren. 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 die Hash-Kollision anhand der RSA-verschlüsselten Signatur einer vertrauenswürdigen Zertifizierungsstelle überprüft, sodass bekanntermaßen versucht werden muss, den Client auszutricksen Vertrauen in die Zertifizierungsstelle, die das Zertifikat signiert hat.
Wenn einem Kunden ein Zertifikat von einer von einer zwischengeschalteten Zertifizierungsstelle signierten Website vorgelegt wird, für die er keine lokale Kopie besitzt, versucht er, die Zertifizierungsstelle des zwischengeschalteten Unternehmens von der Website herunterzuladen, auf der das Ticket von der Website vorgelegt wurde, auf der das Zertifikat in der Website vorgelegt wurde erster Platz. Unter Hinweis darauf, dass ein Client den Hash des TBS-Teils des Zertifikats dieses Vermittlers verwendet und dann überprüft, ob die RSA-verschlüsselte Signatur auf diesem 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 jetzt vereinfacht, um eine Hash-Kollision des TBS-Teils des CA-Zertifikats eines gültigen Vermittlers zu generieren.
Sobald man den öffentlichen Schlüssel des Zertifikats einer überprüfbaren Zwischenzertifizierungsstelle durch einen öffentlichen Schlüssel ersetzen kann, für den der private Schlüssel bekannt ist, kann man andere Bytes nach Bedarf ändern, um eine Hash-Kollision mit dem überprüfbaren Zertifikat zu generieren. 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 er den Fingerabdruck der Zertifizierungsstelle, die es signiert hat. Wenn auf dem Client das Zertifikat dieses Vermittlers nicht lokal installiert ist, lädt er das Zertifikat von der Website herunter und ruft das zu überprüfende Zertifikat ab. Der Client generiert dann den Hash der TBS-Website. ' s Zertifikat und überprüfen Sie, ob es mit dem öffentlichen Schlüssel des heruntergeladenen Zwischenzertifizierungsstellenzertifikats digital signiert wurde. Dieser Prozess ist insofern rekursiv, als er dann einen Hash des TBS-Teils des heruntergeladenen Zwischenzertifikats erstellt und den Fingerabdruck der Zertifizierungsstelle liest, die das Zwischenzertifikat signiert hat. Anschließend wird nach dem Zertifikat der Zertifizierungsstelle gesucht und überprüft, ob die RSA-verschlüsselte Signatur auf dem Zwischenzertifikat mithilfe des öffentlichen Schlüssels der ausstellenden Zertifizierungsstelle generiert wurde, um den Hash des TBS-Zertifikats im Zwischenzertifikat zu signieren. Da der Intermediär-Hash des TBS-Zertifikats im Intermediär-Zertifikat mit dem Hash des ursprünglichen Intermediär-Zertifikats übereinstimmt und die Signatur auch mit der Signatur der Original-Intermediär-Signatur unserer modifizierten Intermediär-CA übereinstimmt. ' Das Zertifikat wird validiert. Der Client schließt den Vorgang rekursiv ab, bis er ein Zertifikat findet, das von einer ihm vertraulichen Zertifizierungsstelle ausgestellt wurde und dessen Punktüberprüfung erfolgreich ist, und wir uns erfolgreich als zwischengeschaltete Zertifizierungsstelle ausgegeben haben.
NIST und die NSA warnten davor
"SHA-1 sollte nach Januar 2016 nicht mehr vertraut werden, da ein gut finanzierter Angreifer oder eine gut finanzierte Regierung zunehmend eine SHA-1-Hash-Kollision finden kann, die es ihnen ermöglicht, sich als SSL-Website auszugeben", und Microsoft und Google warnten ein Jahr lang später von Verbindungen, die SHA-1 verwenden.
http://windowsitpro.com/security/your-organization-using-sha-1-ssl-certificates
Es ist wichtig, dass die Zertifikatkette 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 nach dem 1. Januar 2017 auch SHA-2 verwenden müssen. In der Regel stellt Ihre Zertifizierungsstelle die Zwischen- und Stammzertifizierungsstellenzertifikate bereit, wenn sie bereitgestellt werden das SHA-2-Zertifikat. Manchmal bieten sie einen Link zum Herunterladen der Zertifikatkette. Es ist wichtig, dass Sie diese Kette mit SHA-2-Zertifikaten aktualisieren. Andernfalls vertraut Windows Ihrem neuen SHA-2-Zertifikat möglicherweise nicht.
Root-Zertifikate 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 Entität signiert, der die Berechtigung erteilt wurde.
Aus dem gleichen 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 gekettet sind. Ich gehe jedoch davon aus, dass zukünftige Versionen von Exchange SHA-2 in selbstsignierten Zertifikaten verwenden werden.