Abo
  • Services:

Kollisionsangriff: Hashfunktion SHA-1 gebrochen

Forschern von Google und der Universität Amsterdam ist es gelungen, zwei unterschiedliche PDF-Dateien mit demselben SHA-1-Hash zu erzeugen. Dass SHA-1 unsicher ist, war bereits seit 2005 bekannt.

Artikel veröffentlicht am , Hanno Böck
Unterschiedlicher Inhalt, identischer SHA-1-Hash - diese PDF-Dokumente zeigen, dass Google SHA-1 gebrochen hat.
Unterschiedlicher Inhalt, identischer SHA-1-Hash - diese PDF-Dokumente zeigen, dass Google SHA-1 gebrochen hat. (Bild: Google)

Die Hashfunktion SHA-1 ist endgültig gebrochen. Abgezeichnet hat sich das bereits seit vielen Jahren. In einem gemeinsamen Forschungsprojekt, das tausende Jahre an CPU-Zeit benötigt hat, gelang es Google und einem Team der Universität Amsterdam, zwei unterschiedliche Dateien mit demselben SHA-1-Hash zu erzeugen. Das hat Auswirkungen auf zahlreiche Anwendungen. Bei HTTPS-Zertifikaten wurde SHA-1 in den letzen Jahren mit viel Mühen weitgehend abgeschafft. Bei diversen anderen Anwendungen - darunter beispielsweise Git - könnte der neue Fund zu Problemen führen.

Stellenmarkt
  1. über duerenhoff GmbH, Raum Offenburg
  2. Dürr Systems AG, Bietigheim-Bissingen

Hashfunktionen sind ein wichtiger Baustein in diversen kryptographischen Protokollen. Sie werden beispielsweise für digitale Signaturen verwendet. Ein Hash bildet beliebige Eingabedaten auf eine Ausgabe fester Länge ab, bei SHA-1 sind das 160 Bit, die üblicherweise als 40-stellige Hexadezimalzahl dargestellt werden.

Damit eine Hashfunktion als kryptographisch sicher gilt, muss sie zwei verschiedene Eigenschaften erfüllen. Eine davon ist die sogenannte Kollisionsresistenz: Es darf nicht praktikabel möglich sein, verschiedene Eingabedaten zu erzeugen, die zum selben Hash führen. Genau das ist nun gelungen. Google veröffentlichte zwei PDF-Dateien mit unterschiedlichen Inhalten und identischem SHA-1-Hash. Für den Angriff hat Google insgesamt 6.500 CPU-Jahre und 100 GPU-Jahre an Rechenkapazität bereitgestellt.

Seit 12 Jahren absehbar

Absehbar war ein solcher Angriff bereits seit 2005. Die Kryptographin Wang Xiaoyun veröffentlichte mehrere Forschungsarbeiten und konnte die ältere Hashfunktion MD5 praktisch brechen. Für SHA-1 zeigte Wang ebenfalls Angriffe, die sich jedoch aufgrund des Rechenaufwandes nur mit extrem teurer Spezialhardware hätten praktisch durchführen lassen. Über die Jahre gab es immer weitere Verbesserungen an den Angriffen.

Trotz dieser Angriffe tat man sich sehr schwer, MD5 und SHA-1 loszuwerden. Auch nach den Angriffen auf MD5 wurden noch TLS-Zertifikate mit MD5-Signaturen ausgestellt. Das änderte sich erst, als 2009 auf dem Chaos Communication Congress ein praktischer Angriff auf eine Zertifizierungsstelle gezeigt wurde. Bei SHA-1 tat sich bei TLS-Zertifikaten lange Zeit überhaupt nichts. In den vergangenen Jahren machten die Browserhersteller jedoch Druck. Doch obwohl seit 2005 bekannt ist, dass SHA-1 ausgemustert werden soll, beantragen Zertifizierungsstellen immer wieder Ausnahmen.

An vielen anderen Stellen ist SHA-1 jedoch weiterhin im Einsatz. Während es bei TLS-Zertifikaten praktisch nicht mehr genutzt wird, kommt es im TLS-Protokoll selber immer noch zum Einsatz. GnuPG erstellt zwar in der jüngsten Version keine SHA-1-Signaturen mehr, bis vor kurzem war das jedoch noch die Standardeinstellung. Git basiert komplett auf SHA-1 - alle Objekte in Git werden mittels ihres Hashes adressiert. Was dieser Angriff für Git bedeutet, ist nicht ganz einfach zu beurteilen, aber zumindest die Vertrauenswürdigkeit von signierten Commits steht damit in Frage.

Welche Auswirkungen ein Kollisionsangriff hat, ist in vielen Fällen nur mit einer genaueren Analyse feststellbar. So gibt es kryptographische Konstruktionen, in denen Kollisionen keine Rolle spielen und nur sogenannte Preimage-Angriffe vermieden werden müssen. Bei einem Preimage-Angriff kann ein Angreifer für einen bestehenden Hash eine gültige Eingabe finden. Preimage-Angriffe sind bislang für SHA-1 und selbst für MD5 unrealistisch.

Alternativen SHA-2, SHA-3 und BLAKE2

Klar ist: Von wenigen Ausnahmefällen abgesehen, ist jetzt endgültig der Zeitpunkt, SHA-1 möglichst überall zu entsorgen. Als Alternativen stehen SHA-2, SHA-3 und Blake bereit. Die SHA-2 gibt es schon länger, sie haben sich anders als zeitweise erwartet als sehr resistent gegen Angriffe erwiesen. Allerdings sind sie verwundbar für sogenannte Length-Extension-Angriffe. In den meisten Fällen spielt das jedoch keine Rolle. Nach den Angriffen im Jahr 2005 rief die US-Behörde Nist einen Wettbewerb aus, dessen Ergebnis die SHA-3-Funktionen waren. Wem es auf besonders gute Performance ankommt, der kann auch die Funktion BLAKE2 nutzen: Die ist schneller als MD5 und SHA-1 und trotzdem sehr sicher.

In 90 Tagen will Google eine Software veröffentlichen, mit der sich jeder selbst SHA-1-Kollisionen erzeugen kann. Allerdings sollte man sich darauf nicht verlassen. Je nach Situation ist es möglich, die jetzt bereits veröffentlichten Kollisionen zu nutzen, um weitere kollidierende Dateien zu erzeugen. Weiterhin hat Google einen Test bereitgestellt, bei dem man Dateien hochladen und auf Hinweise von Kollisionsangriffen prüfen kann. Dateien, die mittels Gmail verschickt werden, prüft Google automatisch. Ob dieser Test zuverlässig ist oder nur den speziellen Angriff erkennt, ist nicht ganz klar. Wirklich verlassen sollte man sich darauf eher nicht. Wer SHA-1 noch einsetzt und sich auf dessen Sicherheit verlässt, sollte umgehend auf eine sichere Hashfunktion umstellen.



Anzeige
Top-Angebote
  1. 18,99€ (nur für Prime-Kunden)
  2. 99,00€ (bei otto.de)
  3. 54,99€
  4. GRATIS

bombinho 26. Feb 2017

Allerdings ist die ganze folgende Verschluesselung sinnlos, wenn ich die S-Box kenne...

My1 25. Feb 2017

lol, mach ich ähnlich erstmal das passwort mit nen custom salt der im acc steht und nen...

Xiut 24. Feb 2017

Und was genau hat das mit dem Thema zutun? Es ist ja kein Problem, dass man in eine...

My1 24. Feb 2017

gut da war es etwas zu extrem aber die wahrscheinlichkeit geht extrem gegen 1. konztept...

Anonymer Nutzer 24. Feb 2017

wenn nicht jeder commit eines repositories per gpg signiert ist, ist es doch vollkommen...


Folgen Sie uns
       


Huawei zu Spionagevorwürfen im Golem.de Interview

Der deutsche Pressesprecher von Huawei erklärt den Umgang mit Spionagevorwürfen.

Huawei zu Spionagevorwürfen im Golem.de Interview Video aufrufen
Mobile Bezahldienste: Wie sicher sind Apple Pay und Google Pay?
Mobile Bezahldienste
Wie sicher sind Apple Pay und Google Pay?

Die Zahlungsdienste Apple Pay und Google Pay sind nach Ansicht von Experten sicherer als klassische Kreditkarten. In der täglichen Praxis schneidet ein Dienst etwas besser ab. Einige Haftungsfragen sind aber noch juristisch ungeklärt.
Von Andreas Maisch

  1. Anzeige Was Drittanbieter beim Open Banking beachten müssen
  2. Finanzdienstleister Wirecard sieht kein Fehlverhalten
  3. Fintech Wirecard wird zur Smartphone-Bank

Fido-Sticks im Test: Endlich schlechte Passwörter
Fido-Sticks im Test
Endlich schlechte Passwörter

Sicher mit nur einer PIN oder einem schlechten Passwort: Fido-Sticks sollen auf Tastendruck Zwei-Faktor-Authentifizierung oder passwortloses Anmelden ermöglichen. Golem.de hat getestet, ob sie halten, was sie versprechen.
Ein Test von Moritz Tremmel

  1. E-Mail-Marketing Datenbank mit 800 Millionen E-Mail-Adressen online
  2. Webauthn Standard für passwortloses Anmelden verabschiedet
  3. Studie Passwortmanager hinterlassen Passwörter im Arbeitsspeicher

Pauschallizenzen: CDU will ihre eigenen Uploadfilter verhindern
Pauschallizenzen
CDU will ihre eigenen Uploadfilter verhindern

Absurder Vorschlag aus der CDU: Anstatt die Urheberrechtsreform auf EU-Ebene zu verändern oder zu stoppen, soll nun der "Mist" von Axel Voss in Deutschland völlig umgekrempelt werden. Nur "pures Wahlkampfgetöse" vor den Europawahlen, wie die Opposition meint?
Eine Analyse von Friedhelm Greis

  1. Europawahlen Facebook will mit dpa Falschnachrichten bekämpfen
  2. Urheberrecht Europas IT-Firmen und Bibliotheken gegen Uploadfilter
  3. Uploadfilter Fast 5 Millionen Unterschriften gegen Urheberrechtsreform

    •  /