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

  • Bei der Gelegenheit kann man auch noch erwähnen, dass jeder öffentliche PGP-Key die Information zu unterstützten Hash-Verfahren enthält. Es ist zumindest empfehlenswert, diese für die eigenen Schlüssel anzusehen und ggf. anzupassen. So würde ich z.B. entgegen der langjährigen Standardeinstellung spätestens jetzt auch längere SHA2-Hashes gegenüber SHA1 bevorzugen (in der Praxis spielt dies jedoch vor allem bei älteren Keys eine Rolle, die nur SHA1 unterstützen). Die aktuellen Einstellungen eines Keys findet man in der Konsole über

    Code
    1. $ gpg --edit-key <keyid>
    2. gpg> showpref

    Mit "setpref" lässt sich die Reihenfolge und Auswahl anpassen. Achtung: man gibt hierbei eine Liste aller Algorithmen (incl. Cipher und Kompression) an, in absteigender Priorität – z.B.

    Code
    1. gpg> setpref SHA512 SHA384 SHA256 SHA224 AES256 TWOFISH CAMELLIA256 BLOWFISH AES192 CAMELLIA192 AES CAMELLIA128 CAST5 ZLIB BZIP2 ZIP Uncompressed

    – die Standard-Algorithmen wie SHA1 und 3DES werden dann automatisch mit geringster Priorität hinzugefügt. Anschließend muss der Key ggf. erneut auf Keyserver hochgeladen werden.


    Mit einem entsprechend eingerichteten Key verwenden die meisten Clients standardmäßig den erstgenannten Algorithmus einer Kategorie, wenn Nachrichten für diesen Key erzeugt werden. Man auf diese Weise also anpassen, welche Hashverfahren von anderen Nutzern verwendet werden sollen, wenn man selbst der Empfänger der Nachricht ist (im Gegensatz zur Einstellung für eigene Nachrichten die Susanne oben ja bereits genannt hat).


    Als schwarzmalerische Ergänzung vielleicht noch:

    Gleiches gilt für Programmdateien, denen man einen funktionsfähigen Schädling beigeben möchte.

    Es wäre aber einfacher als für Textdateien. Zumindest in der veränderten Version kann man schließlich beliebigen Overhead einbauen. Das Problem ist natürlich, dass man nun nicht eine beliebige Kollision sucht, sondern eine Kollision mit einem bestimmten Wert (dem der originalen Datei ohne Schädling). Das ist normalerweise ungleich schwerer, wobei ich die Mathematik hinter dem aktuellen Angriff nicht nachvollzogen habe.


    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.

    Grund zur Panik besteht sicherlich nicht, aber es ist ein weiterer Sargnagel für SHA1: eine der zentralen Eigenschaften einer sicheren Hashfunktion (Kollisionsresistenz) ist erwiesenermaßen nicht erfüllt. Kann man von mir aus auch als Todesstoß bezeichnen, heise hatte da schon reißerischere Überschriften...
    Die Verwendung von SHA1 sollte daher eingestellt werden – dieser Vorgang hat ja auch bereits vor einigen Jahren begonnen, als die theoretischen Grundlagen für diesen Angriff gefunden wurden.

  • 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.


    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.



    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.



    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.

  • 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.

    In der Praxis wird die Dateigröße jedoch nicht immer geprüft, beispielsweise bei Add-on-Updates für Thunderbird: die Dateigröße eines Updates wird in der update.rdf nicht abgelegt (siehe MDN-Artikel zu Add-on Updates). In der Praxis nutzen viele Anbieter hier ohnehin zusätzlich HTTPS, aber ein Update via HTTP mit SHA1-Hashes ist technisch zulässig.


    Zu jedem Hash-Verfahren gibt es Kollisionen.

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

  • 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.

    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.