it-swarm.com.de

Warum werden MD5 und SHA-1 immer noch für Prüfsummen und Zertifikate verwendet, wenn sie als defekt bezeichnet werden?

Ich habe gerade über SSL/TLS gelesen und laut dieser Site (das von Qualys SSL Labs als A bewertet wird), MD5 ist total kaputt und SHA-1 ist seit 2005 kryptografisch schwach Dennoch habe ich festgestellt, dass viele Programmierer und sogar Microsoft uns nur SHA-1/MD5 geben, um die Integrität von Dateien zu überprüfen ...

Soweit ich weiß, ändert sich MD5/SHA-1, wenn ich ein Bit einer Datei ändere. Warum/wie sind sie defekt? In welchen Situationen kann ich mit SHA-1/MD5 erstellten Prüfsummen noch vertrauen? Was ist mit SSL-Zertifikaten, die noch SHA-1 wie google.com verwenden?

Ich interessiere mich für Anwendungen von MD5 und SHA-1 für Prüfsummen und für die Validierung von Zertifikaten. Ich frage nicht nach Passwort-Hashing, das wurde in dieser Frage behandelt .

53
Freedo

SHA-1 und MD5 sind in dem Sinne defekt, dass sie für Kollisionsangriffe anfällig sind. Das heißt, es ist realistisch geworden (oder wird für SHA-1 bald realistisch), zwei Zeichenfolgen zu finden, die denselben Hash haben.

Wie erläutert hier , wirken sich Kollisionsangriffe nicht direkt auf Kennwörter oder die Dateiintegrität aus, da diese unter den Fall Preimage bzw. Second Preimage fallen.

MD5 und SHA-1 sind jedoch immer noch weniger rechenintensiv. Mit diesen Algorithmen gehashte Passwörter sind leichter zu knacken als die derzeit vorhandenen stärkeren Algorithmen. Obwohl nicht speziell defekt, ist die Verwendung stärkerer Algorithmen ratsam.

Bei Zertifikaten geben Signaturen an, dass ein Hash eines bestimmten Zertifikats für eine bestimmte Website gültig ist. Wenn Sie jedoch ein zweites Zertifikat mit diesem Hash erstellen können, können Sie sich als andere Websites ausgeben. Im Fall von MD5 ist dies bereits geschehen, und Browser werden SHA-1 bald als vorbeugende Maßnahme auslaufen lassen ( Quelle ).

Die Überprüfung der Dateiintegrität soll häufig sicherstellen, dass eine Datei korrekt heruntergeladen wurde. Wenn jedoch verwendet wird, um zu überprüfen, ob die Datei nicht in böswilliger Absicht manipuliert wurde, sollten Sie einen Algorithmus in Betracht ziehen, der gegenüber Kollisionen widerstandsfähiger ist (siehe auch: Angriffe mit ausgewähltem Präfix ).

35

Für MD5 verwendet niemand, der sowohl seriös als auch kompetent ist, es in einem Kontext, in dem Kollisionsbeständigkeit wichtig ist. Für SHA-1 wird es auslaufen; Die SHA-1-Unterbrechung war zum Zeitpunkt der Veröffentlichung nicht praktikabel, und erst jetzt wird es wichtig, darüber nachzudenken, sie dort einzustellen, wo Kollisionsfestigkeit erforderlich ist. In der Tat ist es ist auslaufen; Beispielsweise funktionieren langfristige TLS-Zertifikate mit SHA-1 in Chrome nicht mehr, um die Benutzer dazu zu bewegen, auf SHA-2 umzusteigen. Es ist jedoch noch nicht praktisch kaputt, daher ist es vorerst akzeptabel.

Der Grund, warum es nicht für alles sofort fallen gelassen wurde, ist, dass Sicherheit Kompromisse beinhaltet. Sie lassen keinen großen Standard fallen und machen alles mit einer riesigen Installationsbasis inkompatibel, weil dies in einem Jahrzehnt zu praktischen Angriffen führen könnte. Kompatibilität ist wichtig.

Für viele Anwendungen sind MD5 und SHA-1 überhaupt nicht geknackt. Beide haben Schwächen gegen Kollisionsresistenz, was bedeutet, dass ein Angreifer zwei Nachrichten erstellen kann, die sich auf dasselbe beziehen. Weder wird gegen den Vorbildwiderstand (bei gegebenem Hash etwas finden, das diesen Hash erzeugt) noch gegen den Widerstand vor dem zweiten Bild (bei gegebener Nachricht eine andere Nachricht mit demselben Hash finden) oder (ihre Komprimierungsfunktionen) als Pseudozufall gebrochen Funktionen. Das bedeutet, dass Konstruktionen wie HMAC-MD5 immer noch sicher sein können, da sie nicht auf der Eigenschaft von MD5 beruhen, die fehlerhaft ist. Sicher nicht ideal, aber siehe oben "Kompatibilität ist wichtig, wenn sie noch sicher ist".

Die Überprüfung der Dateiintegrität über Hashes ist sowieso fast immer sinnlos. Sofern die Hashes nicht über einen sichereren Kanal als die Datei gesendet werden, können Sie die Hashes genauso einfach manipulieren wie die Datei. Wenn die Hashes are jedoch sicherer als die Datei gesendet werden, können MD5 und SHA-1 die Dateiintegrität weiterhin schützen. Da der Angreifer keinen any Einfluss auf die legitimen Dateien hat (und es muss zero Einfluss geben, um wirklich sicher zu sein), muss eine neue Datei mit demselben Hash erstellt werden Brechen des zweiten Vorbildwiderstands, was niemand für MD5 oder SHA-1 getan hat.

Beachten Sie den Unterschied zwischen Integritätsprüfung und Zertifikaten. Zertifikate werden von einer Zertifizierungsstelle von einem vom Benutzer erstellten CSR ausgestellt. Der Angreifer kann einen großen Einfluss auf den tatsächlichen Inhalt des Zertifikats haben. Bei einem Kollisionsangriff kann ein Angreifer ein legitimes und ein gefälschtes Zertifikat erstellen, das kollidiert, das legitime Zertifikat ausstellen und die Signatur für das gefälschte Zertifikat verwenden. Im Gegensatz dazu hat der Angreifer bei der Dateiintegrität normalerweise keine Kontrolle über die legitime Datei und muss daher eine Kollision mit einer gegebenen Datei erhalten, die viel schwieriger ist (und die, soweit wir wissen, nicht möglich ist) mit MD5 gemacht werden).

15
cpast

MD5 und SHA-1 sind schnell und werden möglicherweise von Hardware unterstützt, im Gegensatz zu neueren, sichereren Hashes (obwohl Bitcoin dies wahrscheinlich durch die Verwendung von SHA-2 geändert hat, indem es zu Mining-Chips führte die partielle SHA-2-Kollisionen berechnen).

MD5-Kollisionen sind machbar und es wurden Fortschritte bei Vorbildangriffen erzielt. dort ist eine öffentlich bekannte SHA-1-Kollision für den offiziellen Vollrundenalgorithmus nach anderen Angriffe, die seine effektive Komplexität erheblich reduzieren , was für den Gelegenheitsangreifer möglicherweise noch nicht praktisch genug ist, aber im Bereich der Möglichkeiten, weshalb dies möglich ist kaputt genannt.

Nichtsdestotrotz können "schwache" oder fehlerhafte Hashes immer noch gut für Anwendungen sein, für die keine kryptografisch sicheren Algorithmen erforderlich sind, aber viele Zwecke, die ursprünglich nicht als solche angesehen wurden kritisch später can stellen sich heraus, um eine potenzielle Angriffsfläche freizulegen.

Gute Beispiele wären das Auffinden doppelter Dateien oder die Verwendung in Versionskontrollsystemen wie git - in den meisten Fällen möchten Sie eine gute Leistung mit hoher Zuverlässigkeit, benötigen diese aber nicht Strenge Sicherheit - Um jemandem Schreibzugriff auf ein offizielles Git-Repository zu gewähren, müssen Sie bereits darauf vertrauen, dass andere Personen nicht herumspielen. Bei Duplizierungsprüfungen sollte zusätzlich der Inhalt verglichen werden, nachdem festgestellt wurde, dass zwei Dateien dieselbe Größe und denselben Hash haben.

Das unzureichende Sichern unsicherer Hashes mit Fakten (z. B. Byte-für-Byte-Vergleich) kann ein Risiko darstellen, z. Wenn jemand wie Dropbox ohne ordnungsgemäße Überprüfung eine Deduplizierung mit MD5 hatte und ein Angreifer Daten mit kollidierenden Hashes einschleicht, um Datenverlust zu verursachen.

git spricht dieses Problem an mit "dem Ältesten vertrauen" , wie Linus selbst sagte:

wenn Sie bereits eine Datei A in Git mit Hash X haben, gibt es eine Bedingung, unter der eine entfernte Datei mit Hash X (aber unterschiedlichem Inhalt) die lokale Version überschreiben würde?

Nee. Wenn es das gleiche SHA1 hat, bedeutet dies, dass wir, wenn wir das Objekt vom anderen Ende erhalten, nicht das bereits vorhandene Objekt überschreiben.

Wenn also jemals eine Kollision auftritt, wird das "frühere" Objekt in einem bestimmten Repository immer überschrieben. Beachten Sie jedoch, dass "früher" offensichtlich pro Repository ist, in dem Sinne, dass das Git-Objektnetzwerk eine DAG generiert, die nicht vollständig geordnet ist. Während sich also verschiedene Repositorys darüber einig sind, was bei direkter Abstammung "früher" ist, wenn die Objekt kam durch separate und nicht direkt verwandte Zweige, zwei verschiedene Repos können offensichtlich die beiden Objekte in unterschiedlicher Reihenfolge erhalten haben.

Unter Sicherheitsgesichtspunkten ist das "frühere Überschreiben" jedoch genau das, was Sie wollen: Denken Sie daran, dass das Git-Modell darin besteht, dass Sie in erster Linie nur Ihrem eigenen Repository vertrauen sollten. Wenn Sie also einen "Git Pull" ausführen, sind die neuen eingehenden Objekte per Definition weniger vertrauenswürdig als die Objekte, die Sie bereits haben, und als solche wäre es falsch, einem neuen Objekt zu erlauben, ein altes zu ersetzen.

[Originalquelle: https://marc.info/?l=git&m=115678778717621&w=2]

Und wie sie sagen, ist ein Festplattenfehler mit größerer Wahrscheinlichkeit wahrscheinlicher als eine versehentlich Hash-Kollision (mehrere Größenordnungen - SHA-1-Kollision <10)-40;; Datenträger nicht wiederherstellbarer Bitfehler ~ 10-fünfzehn).

9
Archimedix

Während möglicherweise Kollisionen vorliegen, ist es unwahrscheinlich, dass die Überprüfung der Integrität einer Datei, wenn sowohl ein MD5 als auch ein SHA1 vorhanden sind, eine Kollision zulässt. Wenn diese beiden einfachen Überprüfungen dieselbe Datei validieren, ist dies ausreichend. Ich sehe sowieso kaum Leute, die in den meisten Fällen auch nur einen von ihnen verifizieren.

0
Hugo