Kann eine Datei in böswilliger Absicht so geändert werden, dass der ursprüngliche SHA-1-Hash erhalten bleibt?

Nach diesem und vielen anderen Artikeln ist SHA-1 nicht sicher.

In meinem Fall kümmere ich mich nicht um Passwörter oder digitale Zertifikate. Ich mache mir Sorgen um die Integrität der Datei.

Ist es möglich, dass eine Datei (z. B. ein ISO-Image oder eine ausführbare Datei) in böswilliger Absicht auf folgende Weise geändert wird:

• Behält den SHA-1-Hash der Originaldatei bei und
• Behält den gesamten Inhalt und die gesamte Funktionsweise der Datei bei (schließt jetzt jedoch bösartigen Inhalt ein, der ursprünglich nicht vorhanden war)

So wie ich es sehe, würde eine Änderung einer Datei, die eine SHA-1-Kollision ergibt, die Datei völlig unbrauchbar machen. Die ISO-Datei wäre vollständig beschädigt, oder die ausführbare Datei wäre so stark verwürfelt, dass sie nicht einmal mehr ausführbar wäre.

Aber die Art, wie ich es sehe, könnte falsch sein. Bisher habe ich bei Google-Suchen keine Informationen darüber gefunden, ob SHA-1 weiterhin für die Überprüfung von Dateien geeignet ist. Irgendwelche Einsichten?

Niemand hat dies bisher für SHA-1 erreicht. Es ist theoretisch möglich, aber immer noch nicht praktisch. Die Berichte über Unsicherheit in SHA-1 bedeuten lediglich, dass die Sicherheitsstufe nicht so hoch ist, wie wir es uns wünschen, und dass wir nicht so viele Jahre Zeit haben, um uns darüber Gedanken zu machen, wie wir dachten.

Es ist schwieriger, eine Datei mit demselben SHA-1-Hash wie eine bestimmte Datei zu erstellen, als zwei Dateien mit demselben SHA-1-Hash selbst zu erstellen. Und so weit wir wissen, hat noch niemand auf der Welt diese einfachere Aufgabe erfüllt. Das heißt aber nicht, dass es morgen nicht passieren kann.

Es ist theoretisch möglich, aber es wurde noch nicht getan.

Was Sie suchen, wird als "Hash-Kollision" bezeichnet: zwei Dateien mit demselben Hash. Kryptografische Hash-Codes wie SHA-1 sind im Allgemeinen so konzipiert, dass sie dies erschweren. Da es sich bei SHA-1 um einen 160-Bit-Code handelt, sind durchschnittlich 2 ^ 159 Brute-Force-Versuche erforderlich, um ein Duplikat zu finden. Wenn ein Algorithmus gefunden wird, der zuverlässig besser als ein kryptografischer Hash ist, wird der Hash als "defekt" betrachtet.

MD-5 ist ein Beispiel für einen sehr kaputten Hash. Es sollte eine Stärke von 128 Bit haben und durchschnittlich 2 ^ 127 Versuche erfordern. Da bekannte Sicherheitslücken missbraucht werden, kann die tatsächliche Anzahl der erforderlichen Versuche nur 2 ^ 47 betragen. Dies ist eine Menge kleiner als 2 ^ 127. Tatsächlich wurde dies in einem modernen Computercluster in weniger als einem Tag erledigt.

Ich gebe dieses Beispiel an, weil es der Frage am nächsten kommt, wie Sie SHA-1 verwenden möchten. Dies ist jedoch nicht die häufigste Methode der Kryptoanalyse, um sicherzustellen, dass Hashes nicht beschädigt werden. Sie ermöglichen normalerweise eine Kollision zwischen zwei Dateien, wie vom Angreifer ausgewählt, anstatt dass Sie eine Datei auswählen und der Angreifer danach sucht, sie abzugleichen. Diese Art von Angriff hat den Vorteil, dass sie einfacher zu bewerten ist. Wenn ich finde, dass es "schwer" ist, Ihre Datei zu knacken, bedeutet das, dass eine andere Datei ähnlich stark ist? Dieser Angriff, bei dem der Angreifer beide Dateien auswählen kann, stellt sicher, dass wir das Schlimmste vom Schlimmsten abfangen.

Diese Art von Angriff erlaubt einen interessanten Trick, der als " Geburtstagsangriff " bekannt ist. Um es kurz zu machen: Die Verwendung des Geburtstagsangriffs halbiert die Stärke des Algorithmus, sodass für SHA-1 durchschnittlich 2 ^ 80 Versuche und für MD5 durchschnittlich 2 ^ 64 Versuche erforderlich sind. Dies sind die Hälfte von 160 bzw. 128.

SHA-1 hat bekannte Angriffe, die seine Stärke von 2 ^ 80 auf 2 ^ 69 verringern. Das wird dir nicht viel ausmachen. 2 ^ 69 Versuche ist eine lange Zeit.

Aus der Geschichte haben wir jedoch herausgefunden, dass Hash-Algorithmen nicht spontan, sondern im Laufe der Zeit kaputt gehen. Niemand knackt einen Algorithmus wie MD-5, der ihn über Nacht von 2 ^ 64 auf 2 ^ 47 erhöht. Es passiert im Laufe der Zeit, da viele Personen Artikel über die Mathematik veröffentlichen, die sie dagegen anwenden. Man kann normalerweise beobachten, wie die Komplexität der Angriffe von Beginn an langsam abnimmt (wobei der beste Angriff normalerweise der Geburtstagsangriff ist).

Die Tatsache, dass sich die Kollisionen ändern, deutet darauf hin, dass SHA-1 das Licht am Ende des Tunnels erblickt. Es ist immer noch stark, aber es könnte ein Wunsch bestehen, auf das neueste SHA-3 zu steigen, das derzeit viel sicherer ist.

Sie sollten solche Entscheidungen wirklich aus der Perspektive eines Bedrohungsmodells treffen. Wie viel Schaden kann ein Angreifer anrichten, wenn er eine dieser Kollisionen erleidet? Sind Ihre Angreifer Skriptkinder mit Zugriff auf ein paar Laptops oder Regierungen mit ganzen Supercomputer-Clustern zur Verfügung. Wie groß ist das Zeitfenster, in dem ein Angreifer den Hash brechen muss, bevor er keine Verwendung findet? All dies wirkt sich darauf aus, wie ernst Sie Kollisionen in Betracht ziehen müssen.

Die in diesem Artikel besprochenen Fehler in SHA-1 sind sehr spezifisch: Sie ermöglichen es Angreifern, zwei Dinge zu erstellen, die den gleichen Wert haben (dies wird als "Kollisionsangriff" bezeichnet). Ein Kollisionsangriff erfordert jedoch, dass der Angreifer beide beteiligten Dateien kontrolliert . Wenn der Angreifer die ursprüngliche Datei nicht kontrolliert, kann er bei einem Kollisionsangriff keine andere Datei mit demselben Hashwert finden.

Der Grund, warum dies für TLS / SSL (und Signaturen im Allgemeinen) von Bedeutung ist, ist, dass ein Angreifer mit diesen häufig beide Dateien steuern kann . Ein TLS-Zertifikat wird meistens von der Person erstellt, die es anfordert (die Bits, die sie nicht kontrollieren, sind häufig vorhersehbar). Durch Kollisionen können sie ein legitimes und ein unzulässiges Zertifikat erstellen, das legitime Zertifikat signieren und die Signatur übertragen.

Für Dateien gilt nicht immer die gleiche Situation. Wenn Sie befürchten, dass die Person, die die Datei erstellt, der Angreifer ist (z. B. wenn sie eine Sache unabhängig als gut verifiziert bekommt und Ihnen dann die böse Nutzlast mit demselben Hash sendet), gilt der SHA-1-Angriff, und Sie sollten nachsehen in Richtung Auslaufen (obwohl es noch nicht kritisch ist, wie David Schwartz erwähnte). Wenn die Originaldatei als vertrauenswürdig eingestuft ist, kann ein Angreifer die derzeit bekannten SHA-1-Angriffe nicht anwenden. Sie sollten jedoch nach Möglichkeit darüber nachdenken, sie schrittweise zu beenden. 2).

Antwort auf "Die Kollision ist nicht nützlich" - Während ein Angriff keinen Angreifer erfordert, um eine nützliche Kollision zu erhalten, ist es im Allgemeinen nicht allzu schwierig, "Kollision" in "nützliche Kollision" umzuwandeln. Viele Dateiformate verfügen über ausreichend Speicherplatz, in dem Sie alles haben können, was Sie möchten, ohne die Funktionalität der Datei zu beeinträchtigen. Ein Angreifer kann dies normalerweise ändern, um eine Kollision zu erhalten (wenn Kollisionen praktisch auffindbar sind), während der funktionale Teil so bleibt, wie er es haben möchte. Die Kluft zwischen "akademischem Angriff" und "praktischem Angriff" kann groß sein. die Lücke zwischen "irgendeiner Kollision" und "nützlicher Kollision" ist im Allgemeinen viel kleiner.

Das ernstere Problem, das nichts mit der Wahl des Algorithmus zu tun hat, ist, wie Sie den Hash erhalten. Alles, was ein Hash tut, ist, das Problem von "Holen Sie sich die echte Datei" zu "Holen Sie sich den echten Hash-Wert" zu verschieben. Ein Hash-Wert, der von demselben Server und über denselben Verbindungstyp wie die Datei gesendet wird, ist gegen böswillige Änderungen absolut wertlos (jeder Angreifer, der die Datei manipulieren kann, kann den Hash manipulieren). Hashes sind nur dann nützlich, wenn Sie dem Hash mehr vertrauen können als der Datei. Während dies manchmal der Fall ist (Torrents, Spiegel), werden sie oft verwendet, wenn dies nicht der Fall ist. Deshalb sollten Sie sehr vorsichtig sein, wenn Sie Hashes zur Überprüfung der Integrität verwenden.

Man muss zwischen einem Kollisionsangriff und einem Preimage-Angriff unterscheiden . Es ist eine Kollisionsattacke, zwei Nachrichten zu finden, die den gleichen Wert haben.
Das Ersetzen einer bestimmten bestimmten Nachricht (hier: eine ausführbare Datei) durch eine andere Nachricht mit demselben Hash ist ein (zweiter) Preimage-Angriff.

SHA-1 ist insofern defekt, als ein Kollisionsangriff in 2 ⁵² Operationen gemäß einem Wikipedia-Artikel ausgeführt werden kann, der keine Angabe für diese Nummer enthält (der beste Angriff, dessen Glaubwürdigkeit mir bekannt ist, ist der von Marc Stevens , was 2 ⁶⁰ Operationen dauert ). Aber lassen Sie uns annehmen , die pessimistische Fall von 2 ⁵² .

Dies ist insofern von Bedeutung, als ein Angriff in dieser Größenordnung nicht nur theoretisch denkbar, sondern auch auf einem Multi-GPU-Rig in weniger als einem Tag perfekt ausführbar ist . Dies ist natürlich ein Problem für Anwendungen, bei denen "zwei beliebige" Nachrichten ausreichen. Sogar die von Stevens angegebene Zahl von 2 ⁶⁰ (256-mal mehr Arbeit) ist durchaus realisierbar, wenn Ihr Angreifer bereit ist, etwas zusätzliches Geld auf das Problem zu werfen, oder bereit ist, ein Jahr Zeit zu verbringen.
Genau diese Art von Dingen hindert niemanden , der an Spionage- oder Internetkriminalität beteiligt ist, Zertifikate zu fälschen.

Nun hat ein Preimage-Angriff einen Exponenten, der doppelt so groß ist. Wenn man also 2 ⁵² für den Kollisionsangriff annimmt , wären das 2 ¹⁰⁴ Operationen, was ein völlig anderer Ballpark ist.

Dies ist nicht nur unpraktisch (eine Maschine, die eine Milliarde Mal schneller ist als die im vorherigen Absatz genannte, würde immer noch etwa 6 Millionen Jahre in Anspruch nehmen), sondern angesichts unserer mickrigen Möglichkeiten zur Energieerzeugung ist dies auch völlig unmöglich.

Eine solch massive Berechnung würde eine Energiequelle erfordern, die viel größer ist als alles, was wir uns leisten können, um sie einem einzelnen Vorgang zu widmen. Nein, nicht ganz eine Energiequelle von der Größe der Sonne, aber immer noch eine ziemlich große .

Es ist realistisch, dass Sie mit einem Watt zwischen 10 und 50 GFLOPS rechnen können. Unter der Annahme, dass eine Art Wunder geschieht und Prozessoren über Nacht mehrere tausend Mal energieeffizienter werden, könnte man 1 SHA ≈ 1 FLOP annehmen (ziemlich optimistisch!). Dies würde bedeuten, dass Sie ein 10 ¹² W-Kraftwerk benötigen , um 2 ¹⁰⁴ Hash-Berechnungen innerhalb von 10 Jahren durchzuführen . Um den Angriff innerhalb eines Jahres ausführen zu können, benötigen Sie ein 10 ¹³ W-Kraftwerk. Das ist etwa das 50-fache dessen, was die gesamten Atomkraftwerke der USA, Frankreichs und Japans zusammen produzieren können, nur um einen einzigen Hasch zu fälschen.

Dies wird nicht passieren , es gibt viel einfachere Möglichkeiten, dasselbe Ziel zu erreichen (Ausnutzen des Servers, auf dem der ursprüngliche Hash gespeichert ist, Ersetzen des Servers, Erpressen von jemandem usw.).

Der allgemeine Punkt des Artikels, auf den in der Frage verwiesen wird, lautet: SHA1 ist veraltet und sollte auslaufen, solange Sie noch Zeit haben, dies reibungslos zu tun. In einigen Bereichen läuft die Zeit ab, da Google und Microsoft Fristen durchsetzen.

Faustregel für veraltete Technologie:

• Wenn Sie ein neues Design erstellen oder Features hinzufügen, verwenden Sie es nicht (SHA1).
• Wenn Sie etwas Altes pflegen, erstellen Sie einen Plan für den Austausch (SHA1).

Zusammenfassendes Zitat aus dem Blog-Beitrag 2012 von Bruce Schneier: "Der Punkt ist, dass wir in der Community jetzt mit der Migration von SHA-1 zu SHA-2 / SHA-3 beginnen müssen."

Für den SHA-1-Hash-Kollisionsteil Ihrer Frage wurde dies durch einige der Antworten behoben.

Ein großer Teil davon hängt jedoch von der Art der Datei ab, mit der wir arbeiten:

Behält den gesamten Inhalt und die gesamte Funktionsweise der Datei bei (schließt jetzt jedoch bösartigen Inhalt ein, der ursprünglich nicht dort geändert wurde.)

Was dies bedeutet, hängt stark davon ab, was die Änderungen erkennen:

• Wenn es sich um eine signierte ausführbare Datei handelt, keine (vernünftige) Chance: Sie müssten irgendwie zwei Hash-Kollisionen erhalten: das SHA-1 der Datei und die interne .exe-Signatur.
• Wenn es sich um eine nicht signierte ausführbare Datei, .com, eine nicht signierte DLL oder eine ähnliche Datei handelt, können ihre Ressourcengabeln so hinzugefügt werden, dass sich ihre Funktionsweise nicht ändert. Auf diese Weise kann (möglicherweise) eine Hash-Kollision auftreten, die von "normal" nicht erkannt werden kann. Operation.
• Wenn es sich um eine Quellcodedatei oder eine ähnliche Struktur handelt (.cs, .c, .h, .cpp, .rb, .yml, .config, .xml, .pl, .bat, .ini), müssen Sie diese hinzufügen, ändern oder entfernen kann auf eine gültige Kommentarsyntax beschränkt werden, sodass die Änderung für die meisten Verwendungszwecke (Kompilieren oder Ausführen, nicht mit einem Texteditor öffnen) nicht erkennbar ist.
• Wenn es sich um ein ISO- oder ZIP-Format oder ein anderes Containerformat handelt, ist dies auch unwahrscheinlicher, da die meisten zufälligen Änderungen den Container beschädigen. Es ist möglich, einen gefälschten Dateieintrag hinzuzufügen oder einen Inhalt im Container zu ändern und ihn erneut zu überprüfen, aber Sie erhöhen die Komplexität und nehmen zusätzliche Zeit in Anspruch, um das Ergebnis zu überprüfen, und haben eingeschränkte Freiheitsgrade in Bezug auf den Inhalt wie und welche Inhalte geändert werden dürfen.
• Wenn es sich um einen Text oder ein textähnliches Format handelt, können sie fast beliebig geändert werden, während sie noch eine "gültige" Datei sind, obwohl der Inhalt wahrscheinlich erkennbar sein wird.
• Bei vielen Formaten wie .rtf, .doc, .html, .xslx und anderen markup-ähnlichen Formaten können sie auf eine Weise hinzugefügt oder geändert werden, die von Parsern nicht erkannt werden kann, also anders als die Länge (oder sogar mit einer eingeschränkten Länge) , weniger Freiheit) Die Dateien können geändert werden, um (eventuell) eine Hash-Kollision zu erhalten, obwohl sie nicht nur eine gültige Datei sind, sondern auch in keiner Weise merklich geändert werden, die für die typischen Anwendungen, mit denen sie verwendet werden, sichtbar wäre.

Was Ihnen also bleibt, ist, wie Sie Kollisionen in einer beliebigen Struktur erhalten, die nicht korrumpiert und in gewissem Maße möglicherweise nicht nachweisbar ist:

1. Nehmen Sie die gewünschten funktionalen Änderungen vor (möglicherweise das Einfügen von schädlichem Inhalt) und nehmen Sie zusätzliche Änderungen vor, um die spezifische Gültigkeit des Dateiformats beizubehalten
2. Fügen Sie einen Abschnitt hinzu, der nicht funktionsfähig ist (zwischen Kommentarblöcken, am Ende einer Textdatei mit 3k Zeilenumbrüchen darüber, isolieren Sie einen aktuellen Kommentarblock).
3. Fügen Sie ein Zeichen, einen Codepunkt oder ein Byte zum Ändern hinzu oder wählen Sie es aus und probieren Sie jede mögliche gültige Kombination aus (nicht jede Byte-Kombination ist beispielsweise für verschiedene Codierungen gültig).
4. Berechnen Sie den Hash neu, um festzustellen, ob die Kollision übereinstimmt.
5. Wenn nicht, gehe zu 3.

Angenommen, Sie haben einen superschnellen Computer und eine kleine Datei, sodass das Ändern mit einer gültigen Bytefolge und das Neuberechnen des Hashs 1 Millisekunde dauert (wahrscheinlich erfordert dies dedizierte Hardware). Wenn die Hash-Verteilung vollkommen zufällig und über den Bereich verteilt ist, erhalten Sie bei jedem 2^160Versuch eine Kollision mit SHA-1 (Brute Forcing).

2^160/1000/60/60/24/365.24 
= 4.63x10^37 years 
= 46,300,000,000,000,000,000,000,000,000,000,000,000 years 
= 46 undecillion years.

Aber hey, wollen wir versuchen , die 2^60und 2^52Versionen, und behaupten , dass sie es uns ermöglichen , die Datei zu ändern , dass Art und Weise wir wie (sie nicht) und dass auch sie können in 1ms jeden Versuch durchgeführt werden:

2^52 yields 142,714 years 
/*humans might still be around to care, but not about these antiquated formats*/
2^60 yields 3.65x10^7 years = 36,500,000 years 
/*machines will probably have taken over anyway*/

Aber hey, du könntest Glück haben. Wirklich, wirklich, mehr-als-ein-Wunder-als-irgendetwas-Glückspilz.

Nicht wirklich, Sie können eine dieser Bedingungen gleichzeitig erfüllen, aber nicht beide. Es ist möglich, denselben Hash für zwei verschiedene Dateien zu erhalten, aber für jemanden, der eine Datei ändert und dann versucht, denselben Hash zu erhalten, ist so ziemlich unmöglich Soweit ich weiß

Ja, es ist möglich. Überlegen Sie, wie Viren auf EXE-Dateien wirken. Die Malware-Nutzdaten werden an die ursprüngliche EXE-Datei angehängt, sodass das Programm immer noch das tut, was es ursprünglich getan hat, sich aber auch als Virus verbreitet. Um den gleichen Hash aufrechtzuerhalten, müssten Sie zusätzliche speziell gefertigte Polster verwenden .

Das bedeutet, dass die Datei größer wäre. Aber im Fall einer EXE-Datei könnten Sie möglicherweise einen Teil des weniger verwendeten Codes entfernen, sodass das Programm nur anfangs zu funktionieren scheint. Im Falle einer JPEG-Datei können Sie das Bild weiter komprimieren oder ein ganz anderes Bild verwenden. Bei einer ISO können Sie Dateigruppen entfernen. Die zum Replizieren des Hashs erforderlichen Berechnungen wären schwieriger und für bestimmte Fälle möglicherweise mathematisch unmöglich, wären aber im Allgemeinen immer noch möglich.