Gefährlicher SHA-1-Algorithmus aus SSH-Bibliotheken entfernt


Die Komplexität von Angriffen auf SHA-1. Der Preis basiert auf der Berechnung des Mietpreises einer GTX 1060 bei 35 USD / Monat.

Viel später als alle anderen, aber die Entwickler der Bibliotheken für SSH haben beschlossen, die veraltete SHA-1-Kryptofunktion standardmäßig endgültig zu deaktivieren. Heute kostet die Auswahl des Serverauthentifizierungsschlüssels SHA-1, dh ein Konflikt mit dem ausgewählten Präfix, auf einem gemieteten GPU-Cluster 45.000 US-Dollar , wie in der obigen Tabelle angegeben. Dies macht den Angriff nicht nur für staatliche Geheimdienste, sondern auch für gewerbliche Kunden zugänglich.

DeaktivierenSHA-1 von Standard wurde von den Entwicklern der OpenSSH openSSH (gleichzeitig angekündigte Release Notes ) und libssh ( Codeänderung )Bibliotheken.

Der Secure Hash-Algorithmus (SHA) wurde von der NSA in Zusammenarbeit mit NIST entwickelt. Die erste Version von SHA-0 wurde 1993 eingeführt, aber die NSA erinnerte sich bald an diese Version und verwies auf einen Fehler, den sie entdeckte und der nie veröffentlicht wurde.

Eine feste Version der NSA wurde 1995 veröffentlicht und hieß SHA-1.

Die kryptografische Hash-Funktion SHA-1 (Secure Hash Algorithm 1) generiert eine 160-Bit-Zeichenfolge, die als Hash-Digest bezeichnet wird. Theoretisch sollten Digests für jede Datei, Nachricht oder andere Eingabe in die Funktion eindeutig sein. Als Eingabewert akzeptiert SHA-1 eine Nachricht nicht mehr als2641Bit, d. h. ungefähr 2 Exabyte.

Es ist klar, dass der Bereich der Digest-Werte kleiner als der Bereich der Eingabewerte ist. In der Praxis sollten Digest-Kollisionen angesichts der Leistungsfähigkeiten vorhandener Computerressourcen jedoch nicht möglich sein. Leider erfüllt SHA-1 dieses Kriterium nicht mehr.

2017 stellten Mitarbeiter von Google und dem Zentrum für Mathematik und Informatik in Amsterdam den ersten Weg vor, um Kollisionen für SHA-1 zu generieren .

Sie veröffentlichten einen Beweis: zwei PDF-Dokumente mit unterschiedlichen Inhalten, aber denselben digitalen Signaturen SHA-1.


  $ls -l sha*.pdf 
  -rw-r--r--@ 1 amichal  staff  422435 Feb 23 10:01 shattered-1.pdf
  -rw-r--r--@ 1 amichal  staff  422435 Feb 23 10:14 shattered-2.pdf
  $shasum -a 1 sha*.pdf
  38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-1.pdf
  38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-2.pdf



Auf der shattered.it Website, können Sie eine beliebige Datei prüfen , ob es im Raum der möglichen Kollisionen enthalten ist. Das heißt, ist es möglich, einen anderen Datensatz (eine andere Datei) mit demselben Hash abzurufen. Der Angriffsvektor ist klar: Ein Angreifer kann eine „gute“ Datei durch seine Kopie durch ein Lesezeichen, ein bösartiges Makro oder einen Trojaner-Downloader ersetzen. Und diese "schlechte" Datei hat den gleichen Hash oder die gleiche digitale Signatur.

In den letzten Jahren haben viele Programme und Dienste die Verwendung von SHA-1 eingestellt, nachdem Forscher praktische Möglichkeiten zur Fälschung digitaler Signaturen mit SHA-1 aufgezeigt haben. Experten sind sich einig, dass dieser Algorithmus jetzt nicht in allen Sicherheitskontexten sicher ist.

Google hat lange sein Misstrauen gegenüber SHA-1 zum Ausdruck gebracht, insbesondere, weil es diese Funktion zum Signieren von TLS-Zertifikaten verwendet. Zurück im Jahr 2014, das Chrome - Entwicklungsteam kündigte den Ausstieg aus dem SHA-1.

Im Jahr 2017 nutzten Forscher die Google-Infrastruktur, um Berechnungen durchzuführen und theoretische Berechnungen zu überprüfen, wie viel die Suche nach Kollisionen dauern würde. Entwickler sagen, dass dies eines der größten Computer war, die jemals von Google durchgeführt wurden. Insgesamt wurden neun Billionen SHA-1-Berechnungen durchgeführt (9.223.372.036.854.775.808), für die in der ersten Phase 6.500 Prozessorjahre und in der zweiten Phase des Angriffs 110 Jahre GPU erforderlich waren.

Nachrichtenblöcke mit demselben SHA-1-Hash


Im Jahr 2019 demonstrierten die Forscher Gaetan Laurent und Thomas Peyrin einen Angriff auf die Suche nach einem Konflikt mit einem ausgewählten Präfix, was für die Auswahl bestimmter PGP / GnuPG-Verschlüsselungsschlüssel praktisch sinnvoll ist. Schließlich gelang es den Autoren im Januar 2020, den Angriff um eine Größenordnung zu optimieren und seine theoretischen Kosten auf einen kommerziell akzeptablen Preis zu senken (siehe Tabelle oben und pdf ). Zur Demonstration haben sie ein Paar verschiedener PGP / GnuPG-Schlüssel mit denselben SHA-1-Zertifikaten erstellt.

Zur Abwehr eines Angriffs auf das Auffinden von SHA-1-Kollisionen wird empfohlen, auf bessere kryptografische Hash-Funktionen SHA-256 und SHA-3 umzuschalten.

OpenSSH-Entwickler, die in den Notizen zur neuesten Version geschrieben haben, zitieren diese Studie vom Januar 2020: „Jetzt können Sie Angriffe mit dem ausgewählten Präfix mithilfe des SHA-1-Algorithmus für weniger als 50.000 US-Dollar ausführen. Aus diesem Grund werden wir in naher Zukunft den Standard-Signaturalgorithmus für öffentliche Schlüssel ssh-rsa deaktivieren. Leider ist dieser Algorithmus immer noch weit verbreitet. Trotz der Existenz besserer Alternativen ist es seit langem der einzige vom ursprünglichen SSH-RFC definierte Signaturalgorithmus für öffentliche Schlüssel. “

Unter den besten Alternativen nannten OpenSSH-Entwickler die RSA83-RSA-SHA-2-Algorithmen (unterstützt von OpenSSH 7.2 und standardmäßig bereits verwendet, wenn Server und Client dies unterstützen), ssh-ed25519 (unterstützt ab 6.5) und RFC5656 ECDSA (ab Version 5.7). .

Um zu überprüfen, ob der Server beim Generieren des öffentlichen Schlüssels zur Authentifizierung den schwachen SHA-1-Algorithmus verwendet, versuchen Sie, eine Verbindung zu diesem Server herzustellen, nachdem Sie den ssh-rsa-Algorithmus aus der Liste der in ssh (1) zulässigen Elemente entfernt haben :

ssh -oHostKeyAlgorithms=-ssh-rsa user@host

Wenn die Überprüfung fehlschlägt und andere Schlüsseltypen nicht verfügbar sind, sollte die Serversoftware aktualisiert werden.

In zukünftigen Versionen von OpenSSH ist die Option UpdateHostKeys standardmäßig aktiviert, wobei der Client automatisch zu den besten Algorithmen wechselt. Es kann manuell aktiviert werden.

Anscheinend wird das vollständige Herunterfahren von SHA-1 viel Zeit in Anspruch nehmen. Gaetan Laurent vom Nationalen Institut für Informatik- und Automatisierungsforschung (Frankreich), einer der Mitautoren der Januar-Studie, erwartet nicht, dass OpenSSH-Entwickler dies schnell tun: „Wenn sie SHA-1 vollständig deaktivieren, ist es unmöglich, eine Verbindung von der neuen Version von OpenSSH zum Gerät mit der alten herzustellen SSH-Server, - schreibter. - Wahrscheinlich werden sie vorher eine Reihe von schrittweisen Schritten unternehmen (mit lauten Warnungen). Auf der anderen Seite gibt es in eingebetteten Systemen mit SSH, die seit vielen Jahren nicht mehr aktualisiert wurden, wahrscheinlich viele Sicherheitsprobleme, so dass es nicht allzu schlimm sein kann, ihre Arbeit zu stören ... Wie auch immer, ich bin sehr zufrieden mit diesem Schritt genau das, was wir erreichen wollten :-) ”.

Nachdem OpenSSH und libssh Pläne zur Deaktivierung von SHA-1 angekündigt hatten, wurde die Liste der SHA-1-Benutzer kürzer, verschwand jedoch nicht. Die Funktion wird weiterhin in den neuesten Versionen der OpenSSL-Bibliothek unterstützt, mit denen viele Websites und Internetdienste HTTPS und andere Verschlüsselungsprotokolle implementieren. Die neueste Version des GNU Collection-Compilers, die Anfang dieses Monats veröffentlicht wurde, ist mit dem SHA-1-Hash digital signiert.

Linus Torvaldssagtedass in Git-Repositorys Hash-Kollisionen kein Sicherheitsrisiko darstellen. Er erklärte, dass es einen großen Unterschied zwischen der Verwendung eines kryptografischen Hash für digitale Signaturen in Verschlüsselungssystemen und der Generierung einer „Inhaltsidentifikation“ in einem System wie Git gibt. Wenn alle Daten gemeinfrei sind, ist ein echter Angriff fast unmöglich. Die Autoren der wissenschaftlichen Arbeit geben ein Beispiel für einen Angriff auf Dokumente mit demselben Präfix. Dieser Angriff ist erfolgreich, da das Präfix selbst im Dokument wie ein Blob „geschlossen“ ist. Wenn wir Open Source im Repository haben, ist dies eine ganz andere Sache. Es ist kaum möglich, ein solches Präfix aus dem Quellcode zu erstellen (nur aus dem Blob). Mit anderen Worten, um ein identisches Präfix zu erstellen und dann Codezweige mit denselben SHA-1-Hashes zu generieren, müssen Sie einige zufällige Daten in den Code einfügen, die sofort bemerkt werden. Sagt Linusdass es Orte gibt, an denen Sie die Daten verstecken können, abergit fsckfängt schon solche Tricks. Linus hat jedoch einen Plan, SHA-1 nicht mehr zu verwenden, damit niemand seine Repositorys konvertieren muss.

All Articles