Veraltetes SHA-1 loswerden
Ausgedient
Veröffentlicht in Ausgabe 09/2022 - PRAXIS
Kryptografische Hash-Funktionen besitzen eine Reihe von Eigenschaften. So ist eine Anforderung, dass aus beliebigen Daten eine Prüfsumme mit einer fixen Länge erzeugt werden kann. Des weiteren müssen Kollisionen praktisch nicht möglich sein. Unter einer Kollision ist der Fall zu verstehen, in dem zwei unterschiedliche Datensätze die gleiche Prüfsumme besitzen. Und schließlich sind kryptografische Hash-Funktionen Einwegfunktionen. Dies stellt sicher, dass es praktisch nicht möglich sein soll, auf Basis der Prüfsumme die ursprünglichen Datensätze zu finden.
Diese Eigenschaften eignen sich daher hervorragend zur Integritätsprüfung von beliebigen Daten, weil es praktisch nicht möglich ist, eine Nachricht zu verändern, ohne dass sich hierdurch auch die Prüfsumme der Nachricht ändert. Typische Einsatzgebiete digitaler Signaturen sind beispielsweise X.509-Zertifikate, PGP/GPG-Schlüssel, Softwarepakete oder DNS-Einträge. Und natürlich kommen solche Signaturen auch dann zum Einsatz, wenn es darum geht, Daten über ein Netzwerk zu versenden, um so die Integrität der übermittelten Daten sicherzustellen.
Unsichere Hash-Funktionen
Trifft eine der zuvor genannten Eigenschaften nicht mehr auf eine veröffentliche kryptografische Hash-Funktion zu, gilt diese als gebrochen und sollte von daher auch nicht mehr eingesetzt werden. Jedoch ist hier zwischen theoretischen und praktischen Angriffen auf den Algorithmus zu unterscheiden. So ist es heutzutage mit sehr wenig Aufwand möglich, MD5 (Message-Digest 5) [1] zu brechen, weshalb dieses auch schon länger keine Verwendung mehr findet. Etwas anders sieht es hingegen beim Secure Hash Algorithm (SHA) aus. Dieser wurde in der ersten Version durch das National Institute of Standards and Technology (NIST) im Jahre 1993 veröffentlicht. Der Algorithmus erzeugt eine Prüfsumme von 160 Bit. Wegen eines Designfehlers kam allerdings schon zwei Jahre später eine korrigierte Version des Algorithmus heraus, der allgemein unter den Namen SHA-1 [2] bekannt ist.
Kryptografische Hash-Funktionen besitzen eine Reihe von Eigenschaften. So ist eine Anforderung, dass aus beliebigen Daten eine Prüfsumme mit einer fixen Länge erzeugt werden kann. Des weiteren müssen Kollisionen praktisch nicht möglich sein. Unter einer Kollision ist der Fall zu verstehen, in dem zwei unterschiedliche Datensätze die gleiche Prüfsumme besitzen. Und schließlich sind kryptografische Hash-Funktionen Einwegfunktionen. Dies stellt sicher, dass es praktisch nicht möglich sein soll, auf Basis der Prüfsumme die ursprünglichen Datensätze zu finden.
Diese Eigenschaften eignen sich daher hervorragend zur Integritätsprüfung von beliebigen Daten, weil es praktisch nicht möglich ist, eine Nachricht zu verändern, ohne dass sich hierdurch auch die Prüfsumme der Nachricht ändert. Typische Einsatzgebiete digitaler Signaturen sind beispielsweise X.509-Zertifikate, PGP/GPG-Schlüssel, Softwarepakete oder DNS-Einträge. Und natürlich kommen solche Signaturen auch dann zum Einsatz, wenn es darum geht, Daten über ein Netzwerk zu versenden, um so die Integrität der übermittelten Daten sicherzustellen.
Unsichere Hash-Funktionen
Trifft eine der zuvor genannten Eigenschaften nicht mehr auf eine veröffentliche kryptografische Hash-Funktion zu, gilt diese als gebrochen und sollte von daher auch nicht mehr eingesetzt werden. Jedoch ist hier zwischen theoretischen und praktischen Angriffen auf den Algorithmus zu unterscheiden. So ist es heutzutage mit sehr wenig Aufwand möglich, MD5 (Message-Digest 5) [1] zu brechen, weshalb dieses auch schon länger keine Verwendung mehr findet. Etwas anders sieht es hingegen beim Secure Hash Algorithm (SHA) aus. Dieser wurde in der ersten Version durch das National Institute of Standards and Technology (NIST) im Jahre 1993 veröffentlicht. Der Algorithmus erzeugt eine Prüfsumme von 160 Bit. Wegen eines Designfehlers kam allerdings schon zwei Jahre später eine korrigierte Version des Algorithmus heraus, der allgemein unter den Namen SHA-1 [2] bekannt ist.
Doch auch für diese Version wurde bereits 2005 von chinesischen Wissenschaftlern eine Angriffsmethode vorgestellt, mit der theoretisch eine Kollision möglich ist. Im gleichen Jahr wurde sogar noch eine optimierte Version dieses theoretischen Angriffs veröffentlicht, mit der eine Kollision mit noch weitaus weniger Operationen möglich sein sollte. Allerdings wäre der notwendige Rechenaufwand immer noch so umfangreich gewesen, dass eine Umsetzung kaum praktikabel war.
Aufgrund der Erkenntnisse aus diesen ersten Angriffen auf SHA-1 hat das NIST dennoch zeitnah die Empfehlung ausgesprochen, von nun an SHA-2, einen SHA-1 Nachfolger, einzusetzen. SHA-2 wurde bereits 2001 veröffentlicht und die zu dieser Familie gehörenden Hash-Algorithmen besitzen eine wesentlich längere Prüfsumme als SHA-1, nämlich 256 Bit (SHA-256) oder 512 Bit (SHA-512). Im Jahr 2011 hat das NIST den SHA-1-Algorithmus dann sogar offiziell als "deprecated" eingestuft.
SHA-1 immer noch weit verbreitet
Trotz der Empfehlung des NIST, SHA-1 nicht weiter einzusetzen, und obwohl mit SHA-2 und später dann auch der SHA-3-Familie ein sicherer Nachfolger verfügbar war, kam SHA-1 praktisch überall weiterhin bedenkenlos zum Einsatz. 2017 wurde dann allerdings mit Shattered [3] eine neue Angriffsvariante auf SHA-1 der Öffentlichkeit vorgestellt, bei der Wissenschafter zwei unterschiedliche PDF-Dateien mit der gleichen Prüfsumme, aber im Vergleich zu früheren Angriffen mit relativ wenig Aufwand erzeugen konnten.
Als endgültig gebrochen lässt sich SHA-1 seit 2020 ansehen, da ab diesem Zeitpunkt erstmals sogenannte Chosen-prefix-collision-Attacken erfolgreich waren. Hierbei ist es mit verhältnismässig wenig Aufwand möglich, für zwei beliebige Datensätze die gleiche Prüfsumme zu erzeugen. Dieser Angriff verwendet zusätzliche Byte-Folgen, die in die Datensätze eingefügt werden [4]. Aktuell wird für einen solchen Angriff Hardware im Wert von weniger als 40.000 Euro benötigt und es ist davon auszugehen, dass die Kosten in den nächsten Jahren noch erheblich sinken.
Softwareprojekte ohne SHA-1
Mittlerweile verzichten viele Softwareprojekte komplett auf SHA-1 oder haben zumindest den Einsatzzweck stark eingeschränkt. So erlaubt OpenSSL beispielsweise schon länger nicht mehr, X.509-Zertifikate mit einer SHA-1-Signatur zu versehen, und auch OpenSSH gestattet seit der Version 8.8 keine RSA-Keys mehr, die zur Signatur auf SHA-1 zurückgreifen.
Soll weiterhin der RSA-Algorithmus für den Host-Key eines SSH-Servers zum Einsatz kommen, so ist dieser zusammen mit einem Hash-Algorithmus aus der SHA-2 Familie, also beispielsweise SHA-256 oder SHA-512, einzusetzen. Allerdings unterstützt OpenSSH diese Algorithmen erst ab der Version 7.2 [7]. Alternativ kann stattdessen natürlich auch ein anderer Algorithmus, wie beispielsweise ECDSA, Verwendung finden. Dies ist besonders für ältere OpenSSH-Server interessant, die noch kein SHA-2 unterstützen. Einen neuen Host-Key erzeugen Sie recht fix mit
ssh-keygen -t ecdsa -b 384 -f /etc/ssh/ssh_host_ecdsa_key
Mittels der HostKey-Option tragen Sie diesen dann in der OpenSSH-ServerKonfigurationsdatei "/etc/ssh/sshd_config" ein:
HostKey /etc/ssh/ssh_host_ecdsa_key
Fedora verzichtet auf SHA-1
Die Linux-Distribution Fedora, wie auch hiermit verwandte Distributionen wie CentOS-Stream oder Red Hat Enterprise Linux, haben SHA-1 in den jeweils aktuellen Version komplett verbannt. Mithilfe von sogenannten Crypto-Policies wird geregelt, welche Algorithmen auf dem System erlaubt sind und von den einzelnen Crypto-Komponenten verwendet werden können. Die standardmässige DEFAULT-Policy hat SHA-1 jedoch deaktiviert, sodass sämtliche Crypto-Komponenten auf einem solchen System SHA-1 nicht mehr zum Erzeugen oder Verifizieren digitaler Signaturen verwenden können.
Neben den bereits angesprochenen Problemen mit älteren SSH-Implementierungen merken Benutzer diese Änderung vor allem auch beim Einsatz von Softwarepaketen, die noch über eine SHA-1 Signatur verfügen. Diese können Sie auf einem Fedora-36-System [8] nämlich gar nicht mehr installieren, da das System nicht mehr in der Lage ist, die Signatur des Pakets zu überprüfen. Hier wäre der korrekte Weg, den Hersteller des Pakets darum zu bitten, die Software mit einem anderen Algorithmus als SHA-1 zu signieren. Kurzfristig können Sie auch für einzelne Transaktionen die Überprüfung der Signatur ausschalten. Hierfür verwenden Sie das Kommando
dnf install --setopt=tsflags=nocrypto foo.rpm
Möchten Sie stattdessen lieber direkt den Paketmanager RPM zur Installation des Pakets verwenden, lautet der Befehl
rpm -Uhv --nosignature foo.rpm
Wir weisen an dieser Stelle aber explizit darauf hin, dass die Installation von Softwarepaketen ohne eine Verifizierung der Signatur nicht zu empfehlen ist und die Sicherheit des gesamten Systems gefährdet.
Fallback auf SHA-1
In einigen wenigen Fällen ist es eventuell notwendig, den SHA-1-Algorithmus auf einem System zumindest temporär wieder zur Verfügung zu stellen. Dies ist durch den Einsatz der SHA-1-Crypto-Policy möglich. Diese können Sie einfach zusätzlich zur Standard-Policy laden:
update-crypto-policies --set DEFAULT:SHA1
Jedoch gilt auch hier, dass dieser Vorgang die Sicherheit des gesamten Systems gefährdet, da ab nun wieder sämtliche Crypto-Komponenten Zugriff auf SHA-1 besitzen.
Fazit
Der Witz an Hash-Funktionen ist die Tatsache, dass sich aus einem Hash-Wert nicht der originale Input errechnen lässt und zudem zwei unterschiedliche Eingaben niemals denselben Hash-Wert ergeben. Hierfür setzen die zugehörigen kryptografischen Verfahren auf komplexe Mathematik. Doch nicht nur Fehler in den Algorithmen sorgen dafür, dass die beiden Grundvoraussetzungen bei einigen Hash-Verfahren nicht mehr gelten. Auch die zunehmende Rechenleistung kann ein Knacken schwacher Algorithmen ermöglichen.
SHA-1 gilt schon lange als unsicher und seit einigen Jahren existieren praktische Angriffe, die den Algorithmus mit verhältnismäßig wenig Aufwand brechen. Somit ist es dringend ratsam, auf SHA-1 zu verzichten und stattdessen auf SHA-2 oder SHA-3 zu setzen. Es ist nur konsequent, dass Fedora und andere Linux-Distributionen SHA-1 mittlerweile komplett deaktiviert haben, jedoch Benutzern immer noch die Möglichkeit geben, den Algorithmus bei Bedarf zu reaktivieren – sollte es wirklich zwingende Gründe hierfür geben.
(dr)
Link-Codes
[3] Shattered: https://shattered.io/
[4] Shambles: https://sha-mbles.github.io/
[5] OpenSSL erlaubt kein SHA-1 mehr: https://www.openssl.org/news/changelog.html#openssl-30/
[6] OpenSSH deaktiviert SHA-1: https://www.openssh.com/txt/release-8.8/
[7] OpenSSH Support für SHA-2: https://www.openssh.com/txt/release-7.2/
[8] Fedora und RHEL ohne SHA-1: https://www.redhat.com/en/blog/legacy-cryptography-fedora-36-and-red-hat-enterprise-linux-9/