Entwicklertools · SHA-Hash-Rechner
SHA-1 Kollisionen erklärt: Was ist noch sicher und was muss migriert werden
· Warum es wichtig ist
sha-256 Kryptographie Sicherheit
Ein Scanner markiert SHA-1 und das Management fragt, wie dringend es ist. In diesem Beitrag wird erläutert, was ein Kollisionsangriff bewirkt und was nicht, wo SHA-1 weiterhin toleriert wird und wie eine Migration geplant wird.
Der Scanner sagt, dass SHA-1 kaputt ist – aber wofür kaputt? Die Frage, die über die Dringlichkeit der Migration entscheidet
Ein Netzwerksicherheitsscanner markiert SHA-1 in Ihrer Infrastruktur. Das Management fragt, wie dringend es sei. Die Antwort hängt ganz davon ab, wofür Sie SHA-1 verwenden, und diese Frage verrät, ob Sie ein Compliance-Problem, ein aktives Sicherheitsproblem oder einfach ein Legacy-Artefakt haben, das katalogisiert werden muss. SHA-1 ist kryptografisch fehlerhaft – wissenschaftliche Demonstrationen haben Kollisionen nachgewiesen. Aber „kaputt“ bedeutet je nach der Rolle, die SHA-1 in Ihrem System spielt, unterschiedliche Bedeutungen.
Ein kryptografischer Hash dient in verschiedenen Kontexten unterschiedlichen Zwecken. Manchmal handelt es sich um eine Prüfsumme, die vor versehentlicher Korruption schützt. Manchmal handelt es sich um eine Verpflichtung, etwa um eine veröffentlichte Download-Prüfsumme, mit der Benutzer überprüfen können, ob sie die vom Herausgeber beabsichtigte Datei erhalten haben. Manchmal ist es Teil einer Signatur- oder Zertifikatskette, in der ein Angreifer mit ausreichender Kontrolle zwei aussagekräftige Dokumente erstellen kann, die denselben Hash verwenden, und so die Authentifizierung fälschen kann. Die Schwere einer SHA-1-Kollision hängt entscheidend davon ab, welche dieser Rollen SHA-1 in Ihrem System hat.
Kollision versus Vorbild – warum öffentlich demonstrierte Angriffe auf Kollisionen abzielen und was das für einen vorhandenen Hash bedeutet
Ein Kollisionsangriff erzeugt zwei verschiedene Eingaben mit derselben Ausgabe. Ein Angreifer findet keine Nachricht, die einen Hash auf einen vorgegebenen Wert erstellt – das wäre ein Preimage-Angriff und für SHA-1 weiterhin undurchführbar. Stattdessen bedeutet ein Kollisionsangriff, dass der Angreifer zwei Dokumente mit identischem Hash erstellen kann. Wenn sich ein System auf einen Hash verlässt, um zu beweisen, dass zwei Dinge gleich sind, wird dieser Beweis durch eine Kollision ungültig. Der Angreifer muss beide Eingaben erstellen, was Zeit und Rechenaufwand erfordert, aber das Ergebnis sind zwei unterschiedliche Dinge, die unter dem Hash identisch erscheinen.
Ein Preimage-Angriff würde bedeuten, dass ein Angreifer einen veröffentlichten SHA-1-Hash nehmen und eine dazu passende Eingabe finden könnte. So funktionieren SHA-1-Angriffe nicht. Wenn Sie über ein Repository mit SHA-1-Digests verfügen und sich Sorgen darüber machen, ob eine Datei wirklich mit diesen übereinstimmt, ist ein Kollisionsangriff keine Gefahr. Die Gefahr besteht darin, dass jemand mit Zugriff auf Ihr Repository eine andere Datei desselben Digests fälschen könnte. In den meisten Fällen ist dies ohne Kontrolle des Hashing-Prozesses selbst auch nicht realistisch. Das spezifische Angriffsmodell ist ebenso wichtig wie der Algorithmus.
Die 2017-Demonstrationen – zwei verschiedene Dateien mit demselben SHA-1, qualitativ beschrieben und die darauf folgende Arbeit mit dem gewählten Präfix
Der SHAttered-Angriff von 2017 zeigte eine praktische Kollision: zwei verschiedene PDF-Dateien mit demselben SHA-1-Digest. Die Forscher haben beide Dateien sorgfältig erstellt und sie bei der Kollision zu gültigen PDFs gemacht. Die Arbeit erforderte einen erheblichen Rechenaufwand und spezielle Hardware. Entscheidend ist, dass es überhaupt möglich war: Der Kollisionswiderstand, der die Verwendung von SHA-1 aus Sicherheitsgründen rechtfertigt, ist weg. Der Angriff bewies, dass zwei semantisch unterschiedliche Dokumente einen Digest teilen könnten, was jedes System kaputt macht, das dem Digest als Identitätsnachweis vertraut.
Der in 2020 folgende Angriff namens „SHA-1 ist ein Durcheinander“ ging den nächsten Schritt: Kollisionen mit ausgewählten Präfixen. Diese Variante bedeutet, dass ein Angreifer zwei beliebige Dokumente nehmen, jeweils unterschiedliche Suffixe verketten und eine Kollision herbeiführen kann. Dies ist der gefährliche Angriff für Signaturen und Zertifikate. Ein Angreifer muss nicht bei Null anfangen; Sie können zwei aussagekräftige, unterschiedliche Dokumente kollidieren lassen. Dadurch wird das Sicherheitsmodell jedes Systems zerstört, das SHA-1-Digests signiert. Der Angreifer kann zwei Dokumente erstellen, die beide den gleichen Hash haben und beide etwas anderes bedeuten.
Wobei SHA-1 inakzeptabel ist – Signaturen, Zertifikate und alles, was ein Angreifer auf beide Seiten beeinflussen kann
Die Unterscheidung ist wichtig, weil SHA-1 in einigen Rollen immer noch tolerierbar und in anderen völlig inakzeptabel ist. In Git wird SHA-1 als Inhaltsadresse verwendet – ein Name für einen bestimmten Snapshot von Dateien. Git verwendet SHA-1 nicht zur Authentifizierung; es ist ein Namensschema. Ein Angreifer könnte theoretisch zwei verschiedene Repository-Status mit derselben ID berechnen, aber dazu ist es erforderlich, den gesamten Prozess der Inhaltserstellung zu kontrollieren und beide Versionen zu pushen, bevor es jemand bemerkt. Für die meisten Teams ist dieses Maß an Angreiferkontrolle nicht das Bedrohungsmodell. Aus diesem Grund geht Git bewusst zu SHA-256 über, anstatt es als Notfall zu behandeln.
In einem Web-Download-Verifizierungsszenario veröffentlicht ein Herausgeber eine Datei und ihre Prüfsumme SHA-1 auf demselben Server. Ein Angreifer, der diesen Server kompromittiert, kontrolliert sowohl die Datei als auch die Prüfsumme. Sie können eine Datei hochladen und deren SHA-1 veröffentlichen, und es ist keine Kollision erforderlich. Wenn die Prüfsumme an anderer Stelle veröffentlicht wird – in einem sicheren VPN, in einer signierten E-Mail gedruckt oder in einer anderen Infrastruktur veröffentlicht –, muss der Angreifer kollidieren, und das wird undurchführbar. Die Prüfsumme ist nur so vertrauenswürdig wie ihr Kanal. Aus diesem Grund erfordert die Download-Verifizierung mehr als einen Hash.
Wo es mit weniger Risiko verweilt – Inhaltsidentifizierung in nicht kontroversen Umgebungen und Gits schrittweiser Übergang zu SHA-256
Für Signaturen und Zertifikate ist SHA-1 nicht vertretbar. Eine Zertifikatskette stammt von einem vertrauenswürdigen Stamm. Wenn eine Zertifizierungsstelle zwei verschiedene Zertifikate mit demselben SHA-1-Digest signiert, kann ein Angreifer durch einen Kollisionsangriff eines davon fälschen. Dies ist nicht theoretisch: Angriffe gegen Zwischenzertifizierungsstellen wurden dokumentiert. Jedes Signaturschema, das auf SHA-1 basiert, kann von einem Angreifer mit ausreichenden Ressourcen potenziell gefälscht werden. Jeder große Browser- und Betriebssystemanbieter hat SHA-1 in Zertifikaten als veraltet markiert. Neue Zertifikate müssen SHA-256 verwenden. Die Plattformanbieter haben sich deutlich geäußert, denn die Bedrohung ist real und unmittelbar.
NIST, das US-amerikanische Normungsgremium, hat einen expliziten Zeitplan angegeben. Ab 2024 sollte SHA-1 nicht mehr für neue Anwendungen verwendet werden. Ab 2030 wird SHA-1 voraussichtlich vollständig aus den föderalen Systemen entfernt. Dies ist keine vage Abwertung; Es ist ein konkreter Auftrag für staatliche Auftragnehmer und ein Signal an die Industrie. Durch die Einhaltung des NIST-Zeitplans stellen Sie sicher, dass Ihre Systeme der Verfallskurve immer einen Schritt voraus sind, anstatt sich nach Ablauf der Frist zu drängen.
Repository-Beweise unterstützen die Verwerfung von SHA-1, nicht eine ungelesene NIST-Veröffentlichung oder ein Außerkraftsetzungsdatum
Die Repository-Quelle dokumentiert SHA-1 als Legacy-Interoperabilität und nennt nachgewiesene Kollisionsarbeit, enthält jedoch keinen Zeitplan für die Außerbetriebnahme durch die Normungsorganisation. In diesem Abschnitt wird daher die Gliederung korrigiert, indem die veraltete Version als technisches Inventarproblem behandelt wird, anstatt eine ungelesene Veröffentlichungsnummer oder ein Konformitätsdatum anzugeben.
Für richtliniengesteuerte Umgebungen wenden Sie sich an die Behörde, die für diese Bereitstellung zuständig ist, und notieren Sie das genaue überprüfte Dokument. Produktbeweise unterstützen hier eine engere Aktion: Halten Sie SHA-1 verfügbar, um vorhandene Werte zu reproduzieren, kennzeichnen Sie es als ungeeignet für neue Sicherheitsanwendungen und berechnen Sie einen SHA-256-Ersatz, wo immer das umgebende Protokoll eine Migration zulässt.
Arbeitsbeispiel – eine Migrationscheckliste, die auf eine ältere Download-Überprüfungsseite angewendet wird
Ein Migrationspfad von SHA-1 beginnt normalerweise mit einer Bestandsaufnahme: Wo wird SHA-1 verwendet? Zertifikate und Unterschriften? Unmittelbare Priorität. Git-Repositories und Inhaltsadressierung? Mittlere Priorität, folgen Sie dem Git-Migrationstempo. Veröffentlichte Prüfsummen für Downloads? Hängt vom Vertrauensmodell ab. Interne Prüfsummen für Deduplizierung oder Archivierung? Niedrigere Priorität, mehr Zeit für die Planung. Die Inventarisierungsphase deckt die tatsächliche Oberfläche auf und hilft Ihnen, Prioritäten basierend auf dem tatsächlichen Risiko und nicht auf der Grundlage abstrakter Dringlichkeit zu setzen.
Für jede Rolle sieht die Migration anders aus. Zertifikate werden sofort auf SHA-256 aktualisiert. Git-Repositorys werden schrittweise in SHA-256-Referenzen integriert, während SHA-1 aus Gründen der Abwärtskompatibilität beibehalten wird. Download-Prüfsummen werden zunächst sowohl in SHA-1 als auch in SHA-256 veröffentlicht, schließlich nur noch in SHA-256. Ältere SHA-1-Digests in einer Prüfsummendatenbank können mit dem ToolAcre SHA-Hash-Rechner überprüft werden, und neue Einträge sollten SHA-256 verwenden. Das Tool unterstützt beide Seiten des Übergangs, sodass Sie alte Hashes überprüfen und neue erstellen können.
Takeaway: SHA-1 zum Vergleich, SHA-256 für neue Arbeiten – der ToolAcre SHA-Hash-Rechner enthält SHA-1, damit ältere Digests überprüft werden können, nicht als Empfehlung
Für die meisten Organisationen besteht die Migration nicht darin, „SHA-1 morgen auszuschalten“. Es gehe darum, „zu verstehen, wo es eingesetzt wird, sicherheitskritische Rollen zu priorisieren und einen Mehrjahresplan zu haben.“ Ein Git-Repository mit jahrelangen SHA-1-Commits sollte schrittweise umgestellt werden, mit Tools, die beides bewältigen. Eine Zertifikatsinfrastruktur sollte bereits migriert sein. Veröffentlichte Prüfsummen sollten während eines Übergangsfensters dual-algorithmisch sein. Eine schrittweise Migration reduziert bahnbrechende Änderungen und gibt den Systemen Zeit, sich an die neue Realität anzupassen.
Der ToolAcre SHA-Hash-Rechner bietet beide Seiten dieses Übergangs. Sie können vorhandene SHA-1-Digests aus Ihren Altsystemen überprüfen, um sicherzustellen, dass eine Datei mit ihnen übereinstimmt. Sie können SHA-256 Hashes berechnen, um mit der Veröffentlichung des Migrationspfads zu beginnen. Das Tool gibt nicht vor, dass SHA-1 sicher ist; Es bezeichnet es als kaputt und erklärt, warum. Aber Sie können damit mit den Legacy-Hashes arbeiten, die Sie noch pflegen müssen, während Sie die Brücke zu SHA-256 bauen und Ihre Abschaffung planen.