Login
Newsletter
Werbung

Mo, 27. Februar 2017, 14:22

Software::Entwicklung

Torvalds zur Zukunft von SHA-1 in Git

Nach der Vorstellung des ersten erfolgreichen Kollisionsangriffs auf das Hash-Verfahren SHA-1 sind auch die Tage von SHA-1 in Git gezählt. Kritisch ist das Problem aber noch nicht.

Linus Torvalds, Initiator des Linux-Kernels

Linux Foundation

Linus Torvalds, Initiator des Linux-Kernels

Linus Torvalds hat nach dem Start des Linux-Kernels die Welt noch ein zweites Mal revolutioniert, als er 2005 das Versionsverwaltungssystem Git in kaum zwei Wochen entwickelte. Git war spezifisch auf seine Anforderungen zur effizienten Verwaltung des Linux-Quellcodes ausgelegt, wurde aber in der Folge von zahllosen Projekten genutzt und auch die Geschäftsgrundlage von Firmen wie Github.

Torvalds ist heute nicht mehr aktiv an der Weiterentwicklung von Git beteiligt, ist aber wohl weiterhin der größte Kenner des Systems. Daher gab er nun einen Kommentar zur Verwendung von SHA-1 in Git und zu dessen Zukunft ab. Anlass ist die letzte Woche erfolgte Bekanntgabe, dass für SHA-1, ein kryptografisches Hash-Verfahren, ein »praktikabler« Kollisionsangriff gefunden wurde. »Praktikabel« bedeutet, dass beim aktuellen Stand der Technik 6500 CPU-Jahre Rechenzeit nötig waren (bei einer Million parallel rechnenden CPUs wären das 57 Stunden), um zu einer Datei eine andere, mit selbst gewählten Daten bestückte Datei zu finden, die denselben Hash ergibt. Kriminelle, die entsprechende Kapazitäten aufbieten können, könnten so einzelne Dateien verfälschen, ohne dass sich deren Hash ändert. Im Normalfall ist davon auszugehen, dass zwei unterschiedliche Dateien niemals denselben kryptografischen Hash liefern - dies ist eine der definierenden Eigenschaften von kryptografischen Hashverfahren.

Anzeichen, dass solch ein Angriff einmal gelingen könnte, gab es bereits seit einigen Jahren, daher wurde SHA-1 bereits vielerorts für nicht mehr sicher genug erklärt und entweder gehärtet oder durch einen Nachfolger ersetzt. Vielfach kommt als Nachfolger SHA-256 oder SHA-3 zum Einsatz, jüngere Verfahren, die noch einmal um ein Vielfaches stärker als SHA-1 sind, aber auch mehr Rechenzeit benötigen.

Laut Torvalds ist die Verwendung von SHA-1 in Git ziemlich unkritisch. SHA-1 wird in Git zu einem doppelten Zweck genutzt, erstens um zu entscheiden, wann Dateien identisch sind und daher nur einmal gespeichert werden müssen, und zweitens, um die Integrität der Dateien prüfen zu können, da Dateien durch Übertragungs-, Speicher- oder Hardwarefehler unbeabsichtigt beschädigt werden können. Theoretisch könnte ein Angreifer versuchen, eine manipulierte Datei in ein Git-Repositorium zu bringen, doch dies würde laut Torvalds auffallen: Git würde bemerken, dass es denselben Hash bereits gibt, so dass eine manuelle Inspektion erforderlich wäre. Beim Verwalten von Klartextdateien, für die Git überwiegend gemacht wurde, würde außerdem bereits die Betrachtung der Dateien die Manipulation aufdecken. Denn gezielt eine Datei zu erzeugen, die nicht nur den gewünschten Hash-Wert hat, sondern auch noch unverdächtig aussieht, ist auch mit SHA-1 so gut wie unmöglich.

Problematischer ist die Verwendung von SHA-1 zur Signatur ganzer Code-Zweige. Doch Git wird in absehbarer Zeit Abhilfe schaffen. Zum einen gibt es Möglichkeiten, die SHA-1-Manipulation automatisch zu erkennen, und es liegen bereits Patches vor, dies in Git einzubauen. Zum anderen wird SHA-1 in Git generell durch ein anderes Verfahren ersetzt. Das wird allerdings noch einige Zeit dauern, dafür wird es so implementiert werden, dass die Benutzer keinen Aufwand damit haben und keine manuelle Konvertierung der Repositorien nötig ist.

Während Git von dem SHA-1-Problem bisher nur theoretisch betroffen ist, wurde in SVN in diesem Zusammenhang ein schwerwiegender Fehler entdeckt, der Repositorien zeitweise funktionsunfähig machen kann. Dabei besteht das Problem nicht in der Speicherung der Dateien selbst, denn SVN funktioniert anders als Git und verwaltet die Dateien nicht über SHA-1 oder andere Hashes. Vielmehr entsteht ein Problem, wenn man im Repositorium die automatische Deduplikation eingeschaltet hat, was wohl sehr oft der Fall ist. Checkt man in das Repositorium zwei unterschiedliche Dateien mit identischem Hash ein, beispielsweise die beiden Beispieldateien von shattered.io, dann läuft die Deduplikation in einen Fehler. Die SVN-Entwickler bekamen den Fehler in ihrem eigenen System zu spüren und es kostete eine manuelle Bereinigung, das System wieder lauffähig zu machen. An einer Korrektur wird gearbeitet.

Werbung
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung