Enigmail/GnuPG auf SHA-2 umstellen

Hallo,

unter dem Titel: "Todesstoß: Forscher zerschmettern SHA-1" veröffentlichte Heise in der letzten Woche einen Artikel, der darüber informiert, dass es Forscher von der CWI Amsterdam und Google gelungen ist, eine erfolgreiche Kollision gegen SHA-1 zu fahren.
Konkret ist es gelungen, zwei inhaltlich identische PDF-Dokumente zu erzeugen, die dennoch denselben SHA-1-Hash haben.

Das kann klingt zunächst einmal sehr besorgniserregend, vor allem bei einer Überschrift, wie man sie sonst eher von anderen Verlagen kennt. Bei uns in der Firma hat das bei einigen prompt zur Verunsicherung und entsprechenden Nachfragen geführt. Ich möchte deshalb ein paar Hinweise zu GnuPG geben.

GnuPG und somit auch Enigmail verwenden standardmäßig SHA-1, obwohl es "bessere" Hash-Algorithmen beherrscht. (Zumindest ist das in der GnuPG 2.0.22 noch so.) Die Präferenzen lassen sich durch eine Änderung in der gnupg.conf ändern. Ich empfehle, folgenden Zeilen hinzuzufügen:

# Standardpräferenzen für Chiffre, Hash und Kompression, geändert durch ... am ...
personal-cipher-preferences AES256 TWOFISH AES192 AES
personal-digest-preferences SHA512 SHA384 SHA256
personal-compress-preferences ZLIB BZIP2 ZIP

Die erfolgreiche Umstellungen kann danach folgendermaßen getestet werden:

Sendet euch selbst eine unverschlüsselte aber signierte E-Mail. Wenn ihr dann in der empfangenen E-Mail an der Stelle, an der Enigmail die korrekt Unterschrift anzeigt auf Details -> Enigmail-Sicherheitsinfo klickt, dann sollte dort RSA und SHA512 stehen.
Im Quelltext der Mail sollte ebenfalls SHA512 stehen.

Der Angriff ist ohne Frage beeindruckend. Dennoch möchte ich ein paar Punkte erwähnen, denn man sollte die Kirche schon im Dorf lassen:

• Für diese eine Kollision waren laut des Artikels 6500 CPU-Jahre und 100 GPU-Jahre an Rechenzeit erforderlich.
• Die Kollision erfolgte, indem man die Overhead-Daten des PDF sehr geschickt veränderte. In einem reinen Textfile wäre das ungleich schwieriger, denn das hat keinen solche Overhead.
  Einen nackten Text so abzuändern, dass er nicht nur denselben Hash ergibt sondern auch noch den gewünschten, falschen Inhalt, ist nach wie vor nahezu ausgeschlossen. Gleiches gilt für Programmdateien, denen man einen funktionsfähigen Schädling beigeben möchte. Das ist ohne eine Veränderung des Hash-Wertes nicht hinzubekommen.
• SHA-1 ist ein Hash-Algorithmus. Das hat mit der Verschlüsselung von Inhalten nichts zu tun. Die Verschlüsselung durch GnuPG ist daher nicht betroffen.
  Wohl aber die digitale Unterschrift und das Komprimieren.

Ich empfehle dennoch ebenfalls auf ein sichereres Hash-Verfahren umzustellen - schon aus Prinzip. Ein Grund zur Panik oder gar zu einer solchen Wortwahl, zu der Heise in der Überschrift gegriffen hat, kann ich aber beim besten Willen nicht erkennen.

Gruß

Susanne

Zitat von generalsync

Bei der Gelegenheit kann man auch noch erwähnen, dass jeder öffentliche PGP-Key die Information zu unterstützten Hash-Verfahren enthält.

Oh ja, das ist ein guter Hinweis. An die ganz alten Schlüssel hatte ich gar nicht mehr gedacht. Alle mir bekannten stammen aus der Version 1.4 oder neuer. Die haben schon

Digest: SHA256, SHA1, SHA384, SHA512, SHA224

Also ja, das Überprüfen lohnt sich. Wer weiß, wie viele ältere Schlüsselpaare noch in Gebrauch sind. Bei der Gelegenheit biete es sich an, einmal darüber nachzudenken, alte Schlüsselpaare zu widerrufen und durch neue zu ersetzen.

Zitat von generalsync

Es wäre aber einfacher als für Textdateien. Zumindest in der veränderten Version kann man schließlich beliebigen Overhead einbauen

Das ist prinzipiell richtig, würde aber auffallen. Denn zu einer Prüfung der Integrität einer Datei gehört neben dem Hash immer auch die Dateigröße. Das sollte überhaupt die erste Überprüfung sein, denn wenn die Dateigröße nicht stimmt, kann dann die Datei nicht original sein. Den Hash-Wert braucht man dann gar nicht erst zu kontrollieren.
Schadcode hinzuzufügen ohne die Dateigröße und den Hash zu verändern, halte ich für ausgeschlossen.

Zitat von generalsync

eine der zentralen Eigenschaften einer sicheren Hashfunktion (Kollisionsresistenz) ist erwiesenermaßen nicht erfüllt.

Zu jedem Hash-Verfahren gibt es Kollisionen. Das liegt in der Natur der Sache, denn der Hash ist ja stets kleiner als die Datei, deren Hash man berechnet.

Ein Beispiel:

Ein Hash mit 256 Bit kann 2^256 = 1,2*10^77 verschiedene Werte annehmen. Das ist zwar eine sehr große Zahl mit 77 Nullen, aber bereits eine sehr kleine Datei von nur einem KB enthält 1024 BIts. Es gibt somit 2^1024 mögliche verschiedene 1-KB-Dateien, also bereits bei einer so kleinen Datei wesentlich mehr mögliche Dateien als es Hashes geben kann.

Die Frage ist also nicht die, ob Kollisionen möglich sind, sondern welcher Aufwand getrieben werden muss, eine zu erzeugen. SHA-1 hat prinzipielle Schwächen, die einen solche Angriff für Supercomputer in den Bereich des Möglichen rücken. Die Kollision auf ein einziges PDF benötigte 6500 CPU-Jahre. Selbst ein Supercomputer mit 6500 CPUs hätte daran also immer noch ein Jahr zu rechnen. Da können wir Privatleute ganz entspannt bleiben.

Zitat von generalsync

Die Verwendung von SHA1 sollte daher eingestellt werden

Ohne Frage, ja! Allerdings ohne die Benutzer zuvor so unnötig zu verunsichern, wie Heise das erreicht hat. Wir haben bereits Anfragen von Kunden erhalten, die von uns eine ISO- und ITIL-konforme Bestätigung haben möchten, dass unsere Produkte kein SHA-1 verwenden.
Das klinkt zunächst banal, ist es aber nicht, weil wir Komponenten von Zuliefern verwenden, über die wir keine Aussage treffen können. Wenn nun ein Kunde eine rechtswirksame Aussage verlangt, dass wir den Gebrauch von SHA-1 absolut ausschließen können, dann ist das ein echtes Problem und bedarf juristischer Unterstützung.
Zum Glück haben wir (noch) keine Anfrage in solch einer Absolutheit. Die Kunden haben einen gesunden Menschenverstand. Aufwand erzeugt das Thema aber jetzt bereits.

Zitat von generalsync

In der Praxis wird die Dateigröße jedoch nicht immer geprüft,

Das ist sicher richtig. In der Praxis werden bei Downloads aber auch Hashwerte oft nicht geprüft. Schlimmer noch: Viele Benutzer klicken auf alle möglichen Downloadlinks und laden sich Maleware. Das ist schon ein komisches Argument.

Zitat von generalsync

Das ist klar, ich sprach ja auch von (starker) Kollisionsresistenz.

Nun, wie Du Deinem Link entnehmen kannst, bedeutet selbst schwache Kollisionsresistenz, dass es praktisch undurchführbar ist, zu einem gegebenen Dokument ein zweites Dokument das mit diesem kollidiert. Die erwähnten 6500 CPU-Jahre sind nach meinem Dafürhalten für uns normale Bürger praktisch genug.