Original-URL des Artikels: https://www.golem.de/news/hashfunktion-der-schwierige-abschied-von-sha-1-1703-127041.html    Veröffentlicht: 30.03.2017 15:22    Kurz-URL: https://glm.io/127041

Hashfunktion

Der schwierige Abschied von SHA-1

Die Hashfunktion SHA-1 ist seit kurzem endgültig gebrochen. Doch an vielen Stellen ist sie noch im Einsatz. Beispielsweise in Git, in Bittorrent und, was manche überraschen wird, auch in TLS.

Das Schicksal der Hashfunktion SHA-1 ist vor kurzem endgültig besiegelt woden. Der Kryptograph Marc Stevens erzeugte in einem Kooperationsprojekt mit Google zwei unterschiedliche PDF-Dateien, die den selben SHA-1-Hash besitzen. Damit verletzt SHA-1 eine wichtige Eigenschaft kryptographischer Hashfunktionen: die sogenannte Kollisionsresistenz.

Doch SHA-1 aus der Welt zu schaffen, wird nicht ganz einfach. In vielen Softwareprodukten erfüllt sie wichtige Funktionen, und ein Austausch ist aus Kompatibilitätsgründen oft nicht trivial. Und die möglichen Probleme wurden lange Zeit von vielen Entwicklern heruntergespielt und ignoriert.

Unsichere Hashes in Git

Ein prominenter Nutzer von SHA-1-Hashes ist das Versionskontrollsystem Git. Es wurde von Linus Torvalds für die Bedürfnisse der Kernel-Community entwickelt. Inzwischen ist Git das mit Abstand beliebteste Werkzeug zur Verwaltung von Quellcodes.

Git nutzt intern ein sogenanntes Content-addressable Storage-System. Ein Git-Repository besteht aus verschiedenen Objekten. Die eigentlichen Dateien in einem Repositor sind als "Blob"-Objekte abgelegt. Daneben gibt es verschiedene andere Objekte, die die Struktur abbilden. Tree-Objekte enthalten eine Liste von Dateien, sie bilden also Verzeichnisse ab. Daneben gibt es Commits, die eine Änderung des Repository-Inhalts beschreiben und Tag-Objekte, die einen bestimmten Zustand des Repositories festhalten.

Alle diese Objekte werden mit einem Header versehen gehasht. Anhand ihres Hashes werden die Objekte gespeichert. Sichtbar ist das im .git/objects-Verzeichnis, das sich in jedem Git-Repository befindet. Darin befinden sich Unterverzeichnisse, die mit den ersten beiden Hexadezimalwerten des Hashes benannt sind, und darin die eigentlichen Objektdateien, die vorher noch mit Zlib gepackt werden. Ein Objekt mit dem Hash e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 landet also im Verzeichnis .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391. Bei größeren Repositories findet man dort jedoch nicht alle Objekte, da manchmal mehrere Objekte gepackt und anders abgelegt werden.

Linus Torvalds hatte in der Vergangenheit mehrfach gesagt, dass die Sicherheitseigenschaften von SHA-1 für Git nicht relevant sind. An anderer Stelle hatte er diese Ansicht jedoch auch wieder relativiert. Denn es gibt durchaus Angriffsszenarien.

PGP-signierte Commits nur so sicher wie SHA-1

Ein Feature von Git ist es, Commits mittels OpenPGP zu signieren. Signiert werden dabei aber eben nur Commit-Objekte, die wiederum nur Referenzen auf die SHA-1-Hashes von Tree-Objekten und indirekt Blobs enthalten. Somit ist die Sicherheit der Signaturen direkt von der Sicherheit von SHA-1 abhängig.

Ein denkbarer Angriff: Jemand könnte zwei Dateien erstellen, die innerhalb von Git den selben SHA-1-Hash erhalten. Dabei könnte es sich etwa um Bilder oder PDF-Dateien handeln. Bei reinen Text-Dateien ist ein Angriff nicht direkt machbar, zumindest Teile des Dokuments müssen beliebige Daten enthalten können, die beim Interpretieren ignoriert werden. Die von Google bereitgestellten Dateien lassen sich für so einen Angriff nicht nutzen, da Git jedem Objekt noch einen Header voranstellt.

Eine der Dateien ist harmlos und kann an jemanden geschickt werden, der ein Git-Repository betreibt. Wenn dieser die Datei in das Repository signiert eincheckt, ist diese Signatur auch für eine bösartige Kopie des Repositories gültig, das die andere Datei enthält.

Das ist nur ein denkbarer Angriff. Problematisch ist ebenfalls die Nutzung von Submodulen, die über ihre Hashes identifiziert werden, oder die Deduplikation von Services wie Github.

Hardcodierte Arrays werden entfernt

Die Nutzung von alternativen Hash-Algorithmen war in Git nie vorgesehen. An vielen Stellen im Code werden Arrays mit einer fest eingestellten Größe von 20 Bytes für die Hashes verwendet, was genau für die 160 Bit von SHA-1 reicht. Sichere Hash-Funktionen nutzen üblicherweise 256 oder 512 Bit. Git-Entwickler Brian Carlson fing bereits vor einigen Jahren damit an, diesen Code auf einen generischen Objekttyp umzustellen, doch diese Arbeiten sind längst nicht abgeschlossen.

Aber diese Restrukturierung des Codes ist nur der allererste Schritt einer Migration. Relativ einfach wäre es, neue Repositories zu erstellen, die ein neues Datenformat und eine sichere Hashfunktion nutzen. Aber es gibt unzählige bestehende Repositories. Und der Umgang mit diesen ist nicht trivial. Linus Torvalds hat in einer E-Mail einen groben Plan zur Umstellung vorgestellt.

Der Content-addressable Storage sorgt dafür, dass eine Datei an einer eindeutigen Stelle abgelegt ist. Wie würde das jedoch nach einer Umstellung aussehen? Sollen alle Dateien zusätzlich mit einem besseren Hash an anderer Stelle abgelegt werden? Torvalds Plan sieht das vor. Demnach wäre es bei allen neuen Tree- und Commit-Objekten verboten, alte Objekte zu referenzieren. Das dürfte einmalig dazu führen, dass Repositories in ihrer Größe deutlich anwachsen, da viele Objekte dann doppelt vorgehalten werden müssen.

Die Probleme hätten leicht vermieden werden können. Denn Git ist nicht so alt. Die erste Version wurde 2005 veröffentlicht. Damals waren die Schwächen von SHA-1 bereits bekannt. John Gilmore hatte bereits früh darauf hingewiesen, Linus Torvalds ignorierte die Warnungen jedoch und machte sich über sie lustig.

Übrigens: Bei den Konkurrenten zu Git sieht es überwiegend nicht viel besser aus. Auch Mercurical nutzt SHA-1. Selbst Subversion, das nach außen überhaupt keine Hashes nutzt, hatte Ärger mit Hashkollisionen. Beim Versuch des Webkit-Teams, zu Testzwecken die kollidierenden PDF-Dateien einzuchecken, verursachte Subversion einen Fehler und das Repository wurde unbenutzbar.



Bittorrent mit Backdoor

Ein weiteres Protokoll, das im Kern auf SHA-1 setzt, ist Bittorrent. Eine Torrent-Datei prüft die Korrektheit der heruntergeladenen Daten anhand einer Kette von SHA-1-Hashes.

Beim Erstellen von Torrent-Dateien werden die Daten in gleich große Blöcke geteilt und für jeden Block ein Hash berechnet. Bei einer sicheren Hashfunktion wäre damit garantiert, dass eine Torrent-Datei immer zu identischen Downloads führt, egal von wem die Daten heruntergeladen werden.

Ein Angriff mit dem Namen Biterrant zeigt, welche Konsequenzen die Hash-Kollision in SHA-1 hat. Dafür war kein neuer Angriff auf SHA-1 nötig, der Biterrant-Angriff nutzt die PDF-Dateien von Google, um bösartige Torrents zu erzeugen. Biterrant erzeugt zwei EXE-Dateien. Eine davon ist harmlos, die andere führt bösartigen Code aus. Die harmlose EXE-Datei enthält zwar ebenfalls den bösartigen Code, er ist jedoch verschlüsselt und nicht aktiv.

Sichere Downloads via Bittorrent?

Teilweise wurden Torrents in der Vergangenheit als mögliche sichere Download-Option genutzt, da viele Softwareprojekte nach wie vor keine Downloads über HTTPS anbieten. Lädt man die Torrent-Datei über HTTPS, wäre bei einem sicheren Hash die Integrität der heruntergeladenen Dateien gewährleistet. Durch den SHA-1-Angriff ist das deutlich problematischer. Allerdings: Der Angriff setzt voraus, dass sowohl das harmlos aussehende als auch das bösartige Torrent von derselben Person erstellt wurden.

Im Bugtracker von Bittorrent wird über ein neues Torrent-Format diskutiert, das einen sicheren Hash-Algorithmus nutzt. Außerdem diskutiert wird dabei, künftig nicht mehr nur einzelne Blöcke zu hashen, sondern die gehashten Daten als Merkle-Tree abzuspeichern. Bislang dreht sich ein Großteil der Diskussion darum, ob künftig SHA256 oder die neuere Hashfunktion Blake2 genutzt werden soll. Allerdings ist dies nur eine Detailfrage: Beide Hashfunktionen gelten als sehr sicher, Angriffe sind auf absehbare Zeit nicht zu erwarten.

Für Bittorrent gilt ähnlich wie für Git: Man hätte es längst wissen können. Auf der Bittorrent-Mailingliste gab es 2005 bereits eine Diskussion um die Schwächen von SHA-1. Das hatte aber keine Konsequenzen.



TLS: Signaturen im Handshake

Ein weiteres Protokoll, das SHA-1 noch sehr häufig einsetzt, ist TLS. Das dürfte manche überraschen. Denn an einer Stelle ist die Ablösung von SHA-1 in TLS bereits geschafft: Nach viel Diskussionen und Mühen haben sich alle großen Browserhersteller dazu entschlossen, keine SHA-1-Signaturen in Zertifikaten mehr zu akzeptieren. Zertifizierungsstellen dürfen seit einiger Zeit keine derartigen Zertifikate mehr ausstellen, allerdings gibt es immer wieder Ausnahmen.

Doch TLS nutzt Hashfunktionen an verschiedenen Stellen. Unproblematisch ist die Nutzung von SHA-1 für das HMAC-Verfahren, denn dabei ist die Kollisionsresistenz nicht relevant. Das betrifft etwa Cipher-Modi wie ECDHE-RSA-AES256-SHA. Dabei wird AES im CBC-Modus und HMAC mit dem SHA-1-Algorithmus verwendet. Die Kombination von CBC und HMAC ist aus anderen Gründen nicht empfehlenswert, da sie sehr anfällig für Timing-Angriffe ist, die Schwächen von SHA-1 spielen hier aber keine Rolle.

An einer weiteren Stelle ist ein schwacher Hash jedoch durchaus ein Problem: Teile des Handshakes von TLS werden bei Forward-Secrecy-Verfahren signiert. Und dabei kommt noch häufig SHA-1 und manchmal sogar das noch ältere und unsicherere MD5 zum Einsatz. Die Probleme, die schwache Hashes in TLS mit sich bringen, wurden Anfang 2016 von Sicherheitsforschern als SLOTH-Angriff veröffentlicht.

Grund zur Panik besteht nicht unbedingt: Für einen erfolgreichen Angriff müsste eine SHA-1-Kollision innerhalb von Sekunden während eines Handshakes gefunden werden. Google benötigte viele Monate auf großen Rechnerclustern für den Kollisionsangriff.

Warum ermöglichte TLS 1.2 2008 noch SHA-1 und MD5?

Warum im TLS-Handshake SHA-1 und MD5 überhaupt noch unterstützt werden ist nur schwer zu verstehen. Denn das aktuelle TLS-Protokoll 1.2 wurde 2008 veröffentlicht. Die Schwächen von SHA-1 waren jedoch bereits seit 2005 bekannt.

Ältere TLS-Versionen nutzten eine Kombination aus MD5 und SHA1. Statt diese Kombination einfach durch eine sichere Hashfunktion wie SHA256 zu ersetzen, entschied man sich, eine Signatur-Erweiterung einzuführen, die die Wahl der Hashfunktion flexibilisiert. Dadurch kann man sich mit TLS 1.2 aussuchen, ob man eine sichere oder eine unsichere Hashfunktion möchte. Die Signaturerweiterung von TLS 1.2 ist ein gutes Beispiel dafür, dass das gern genutzte Prinzip der "Algorithm Agility" oft keine gute Idee ist.

Die alten Hashfunktionen in TLS auszurotten, ist schwierig. Denn viele Server unterstützen zwar TLS 1.2, aber nur mit SHA-1-Signaturen. Aufgeräumt wird hier wohl erst mit TLS 1.3, das dann endgültig die Unterstützung für alle unsicheren Hashverfahren entfernt.

Fazit: Man hätte früher handeln können

Es wird sicher noch einige Stellen geben, an denen SHA-1 zum Einsatz kommt. Ärgerlich ist dabei vor allem, dass die Umstellung so lange dauert. Der Durchbruch bei Angriffen auf SHA-1 ist zwar erst einige Wochen alt, die Grundlage für den Angriff legte jedoch vor zwölf Jahren ein chinesisches Forscherteam um die Kryptographin Xiaoyun Wang. Es wären zwölf Jahre Zeit gewesen, überall auf sichere Hash-Funktionen zu setzen.

Mit SHA256 und den anderen Funktionen aus der SHA-2-Familie stand bereits seit 2002 eine standardisierte, sichere Alternative bereit. SHA-2 gilt weiterhin als sehr sicher. Die einzige Schwäche sind sogenannte Length-Extension-Angriffe, die spielen allerdings in den meisten Protokollen keine Rolle.

Inzwischen gibt es den Nachfolgestandard SHA-3 und als Alternative das schnellere und ebenfalls standardisierte BLAKE2. Für welche dieser sicheren Optionen man sich entscheidet, ist dabei nicht die wichtigste Frage. Wichtig ist nur: SHA-1, MD5 und Co. sollten nicht mehr zum Einsatz kommen.  (hab)


Verwandte Artikel:
Zertifikate: Google wirft Wosign und Startcom endgültig raus   
(10.07.2017, https://glm.io/128830 )
Browser: Microsoft deaktiviert SHA-1-Support in Edge   
(15.05.2017, https://glm.io/127830 )
Kollisionsangriff: Hashfunktion SHA-1 gebrochen   
(23.02.2017, https://glm.io/126355 )
Connect 2017: Microsoft setzt weiter auf Enterprise-Open-Source   
(15.11.2017, https://glm.io/131161 )
Sky Store: Sky verkauft Streaming-Filme auf DVD und Blu-ray   
(20.06.2017, https://glm.io/128473 )

© 1997–2020 Golem.de, https://www.golem.de/