Ende-zu-Ende Verschlüsselung ist ein wichtiges Instrument für Privatsphäre und gegen Massenüberwachung. GnuPG, als Softwareimplementation des offenen Standards OpenPGP, leistet dazu einen wichtigen Beitrag. Um die eigene Kommunikation langfristig vertraulich zu halten, ist die Wahl guter Schlüsselparameter essentiell. Dieser Artikel, der sich an fortgeschrittenere GnuPG Nutzende richtet, möchte dazu Denkanstösse geben.
Allgemeine Fragen wie «wo generiere ich ein neues Schlüsselpaar?», «welche Parameter nutze ich dafür?», «wie schütze ich meinen privaten Schlüssel?», «wie lange soll ein Schlüsselpaar verwendet werden?» oder «was mache ich, wenn mein privater Schlüssel nicht mehr vertrauenswürdig ist?» ergeben sich immer wieder aufs Neue, sind aber für eine vertrauliche Kommunikation essentiell. Nachfolgend soll auf diese Fragen eingegangen werden, um am Schluss eine mögliche GnuPG-Konfigurations-Vorlage aufzuzeigen.
Allgemeiner Hinweis
Es sei darauf hingewiesen, dass GnuPG von Haus aus mit guter und sicherer Verschlüsselungsvorkonfiguration daher kommt. Seine Verwendung für die dezentrale Mailverschlüsselung empfehlen wir auch im Messenger-Vergleich.
Grundvoraussetzung für vertrauliche Kommunikation ist ein persönlicher, vertrauenswürdiger Rechner mit aktuellem Betriebssystem und Security Patch Level.
Beim Erstellen eines neuen Schlüsselpaares sollten folgende allgemeine Punkte berücksichtigt werden:
- Konfigurationsdatei auf Fehler und/oder veraltete Parameter prüfen
- Schlüssel erstellen
- Zusätzliche Identitäten (UIDs) hinzufügen
- Schlüsselparameter prüfen und gegebenenfalls anpassen
- Ablaufdatum definieren (falls nicht schon beim Erstellen definiert)
- Passwort zum Entsperren definieren oder ändern
- Widerrufsschlüssel erzeugen
- Öffentlichen Schlüssel verteilen
Nachfolgend werden wichtige Aspekte dieses Vorgehens beleuchtet.
Schlüssellänge, Chiffren und Signaturverfahren
Als kryptographische Verfahren gelten solche zu wählen, die nach aktuellem Erkenntnisstand als sicher erachtet werden. Sie sollten aber auch in Zukunft noch als sicher gelten. Anhaltspunkte dazu bieten Fachzeitschriften, beispielsweise der heise-Artikel «Kryptographie in der IT ‒ Empfehlungen zu Verschlüsselung und Verfahren» von Jürgen Schmidt oder die Empfehlungen bekannter Kryptologen wie Bruce Schneier und Matthew Green.
Grundsätzlich empfehlen wir einen möglichst langen RSA Schlüssel zu verwenden, weil OpenPGP keine Forward Secrecy kennt. Zurzeit ist ein langer Schlüssel unserer Meinung nach der einzige Mechanismus, die eigene Kommunikation möglichst lange in die Zukunft vertraulich zu halten. Prinzipiell bietet ein 4096 Bit RSA, laut https://www.keylength.com, für die nächsten Jahre genügend Sicherheit. Wer aber einen Schritt weiter gehen möchte und dem eigenen Umfeld vertrauliche Kommunikation über die nächsten 15+ Jahre hinaus bieten möchte, sollte sich einen längeren Schlüssel würfeln. GnuPG erlaubt in Version 2.1 RSA Schlüssel mit einem oberen Maximum von 8192 Bit. Smartcards sind üblicherweise auf 4096 Bit lange Schlüssel beschränkt.
Elliptische Kurven (ECC) werden in Zukunft eine wesentliche Rolle spielen, da sie bei kürzeren Schlüssellängen gleiche oder höhere Sicherheit bieten als lange RSA Schlüssel. GnuPG unterstützt diese kryptographischen Verfahren ab Version 2.1 experimentell. Viele Systeme nutzen aber standardmässig noch die Version 2.0 ‒ welche noch bis zum 31.12.2017 gepflegt wird ‒ oder gar den noch älteren 1.4er «Classic» Release. Deshalb ist die ECC im Moment noch nicht wirklich praxistauglich.
Im öffentlichen Schlüssel wird mitgeteilt welche symmetrischen Verschlüsselungsverfahren, Signaturmethoden und Kompressionsalgorithmen vom Inhaber des privaten Schlüssels bevorzugt verwendet werden.
Soll eine Nachricht an mehrere Empfänger verschlüsselt verschickt werden, werden die sichersten Verfahren aus der Schnittmenge aller öffentlichen Schlüssel verwendet. Bewusst empfehlen wir hier ein umfangreiches Set an kryptographischen Verfahren zu wählen, um ein Zurückfallen auf schwächere Verfahren möglichst zu vermeiden:
- Die sieben symmetrischen Verschlüsselungsmethoden AES und CAMELLIA (jeweils in den unterschiedlichen Blockgrössen 256, 192 und 128) sowie TWOFISH.
- Für die Signatur empfehlen wir die vier Signaturverfahren SHA512, SHA384, SHA256 und SHA224.
- Für die Nachrichtenkompression sind dies die drei Algorithmen BZIP2, ZLIB sowie ZIP.
Die Liste bevorzugter Verfahren wird pro User ID gespeichert. Wer mehrere UIDs in seinem Schlüssel definiert hat, muss die gesetzten Parameter also für jeden Schlüssel setzen respektive prüfen.
Der zehnjährige OpenPGP Standard (RFC4880) schreibt jedoch vor, dass eine Implementation wie GnuPG das symmetrische Verfahren 3DES (TripleDES) sowie das Signaturverfahren SHA1 bereitstellen muss. Dies soll als gemeiner minimaler Standard gewährleisten, dass Sender und Empfänger immer einen gemeinsamen Nenner für eine Verschlüsselung finden oder anders gesagt, dass die Schnittmenge kryptographischer Verfahren aller Empfänger nicht leer ist.
Es gibt berechtigte Gründe SHA1 und 3DES nicht mehr verwenden zu wollen, weshalb der Momentane «workaround» darin besteht, möglichst viele bessere Verfahren anzubieten, sodass möglichst nie auf 3DES und/oder SHA1 zurück gegriffen werden muss.
Die sich zurzeit in Arbeit befindende aktualisierte Version von RFC4880 soll diese beiden Verfahren nicht mehr als Muss-Kriterium vorschreiben und zukunftssichere Algorithmen berücksichtigen.
Eigene Signaturen ‒ zur Signierung des eigenen und anderer öffentlicher Schlüssel sowie zur Signierung eigener Nachrichten ‒ sollten immer mindestens mit SHA265, besser gleich mit SHA512 erstellt werden.
Schutz
Den eigenen Schlüssel über Jahre zu schützen ist eine schwere Aufgabe. Eine Sicherheitskopie, an einem sicheren Ort auf einem USB-Stick, ist eine gute Möglichkeit für ein Backup. Wir empfehlen einen ASCII-armored Export des privaten Schlüssels und/oder die Verschlüsselung des USB-Sticks.
Ebenfalls empfehlenswert ist der Einsatz einer Smartcard. Sie hat die schöne Eigenschaft, dass der private Schlüssel nicht beispielsweise durch Malware auf dem Rechner abhanden kommen kann.
Für ein Ablaufdatum eines Schlüssels gibt es zwei wichtige Gründe: Das jetzige Schlüsselpaar ist nicht bis in die Ewigkeit gültig und es schadet nicht, sich alle paar Jahre wieder einmal mit dem Thema Mailverschlüsselung auseinanderzusetzen. Wer 2001 einen Schlüssel erstellt hat und diesen heute noch immer verwendet, kann davon ausgehen, dass der Schlüssel inzwischen den Anforderungen für sichere Kommunikation nicht mehr entspricht.
Damit der eigene Schlüssel nicht unbemerkt sein Ablaufdatum überschreitet, empfehlen wir im Kalender eine Erinnerung drei Monate vor Ablauf einzutragen. Das Ablaufdatum kann jederzeit angepasst werden, nur muss danach der aktualisierte öffentliche Schlüssel auch wieder in Umlauf gebracht werden.
Schwächstes Glied in der Kette ist und bleibt jedoch das Passwort, welches den privaten Schlüssel entsperrt. Ein langes Passwort in Kombination mit einem Passwortmanager sollte Abhilfe schaffen.
Verbreitung und Verlust
Über ein neues Schlüsselpaar muss das Kommunikationsumfeld informiert werden. Wer sich ein neues Schlüsselpaar würfelt, bevor das existierende abgelaufen ist, hat den Vorteil den neuen öffentlichen Schlüssel verschlüsselt per Mail an entsprechende Personen verteilen zu können. Da der bisherige Schlüssel noch nicht abgelaufen ist, hat das Gegenüber den neuen Schlüssel über einen vertrauenswürdigen Kanal erhalten. Trotzdem empfehlen wir zur Verifizierung den Fingerprint über einen zweiten Kanal zu prüfen.
Kommt der eigene private Schlüssel doch einmal abhanden, sollte das Schlüsselpaar natürlich nicht mehr verwendet werden. Die Kommunikationspartner werden am besten mit dem Widerrufschlüssel informiert. Dieser Schlüssel kann nur aus dem privaten Schlüssel erstellt werden und sollte ebenfalls in einem Backup gesichert sein. Danach gilt es, sich wieder ein neues Schlüsselpaar zu erstellen, zurück auf Feld eins sozusagen.
GnuPG Konfiguration
Aufgrund der besprochenen Themen empfehlen wir für die Konfigurationsdatei gpg.conf folgende Ergänzungen:
# Prefered message signing algorithm SHA512
personal-digest-preferences SHA512
# Prefered key signing algorithm SHA512
cert-digest-algo SHA512
# Prefered cipher list
default-preference-list AES256 CAMELLIA256 AES192 CAMELLIA192 AES128 CAMELLIA128 TWOFISH SHA512 SHA384 SHA256 SHA224 BZIP2 ZLIB ZIP
Darauf basierend ist mittels GnuPG Version >= 2.0 wie folgt ein neuer 8k RSA Schlüssel zu erzeugen:
gpg --enable-large-rsa --batch --gen-key Desktop/params.txt
wobei die Datei Desktop/params.txt folgenden Inhalt aufweist:
Key-Type: RSA
Key-Length: 8192
Subkey-Type: RSA
Subkey-Length: 8192
Name-Real: <dein-name-oder-nick>
Name-Email: <deine-mail-adresse>
Passphrase: <dein-passwort>
Expires: 2y
# My preferences: AES256, CAMELLIA256, AES192, CAMELLIA192, AES128, CAMELLIA128, TWOFISH, SHA512, SHA384, SHA256, BZIP2, ZLIB
Preferences: S9 S13 S8 S12 S7 S11 S10 H10 H9 H8 H11 Z3 Z2 Z1
%commit
Das Passwort sollte entweder im neu erzeugten Schlüssel geändert oder in der Datei selbst gelöscht werden.
Obwohl 3DES und SHA1 oben nicht in den Schlüsseleigenschaften definiert werden, zeigt GnuPG diese in der Schlüsseleigenschaft (showpref) dennoch an, was etwas verwirrend ist. Grund dafür ist die Implementierungsvorgabe aus dem RFC.
Abschliessend
Wer nach dieser Lektüre seinen bestehenden Schlüssel auf allfällige Mängel prüfen möchte, kann dazu, unter GNU/Linux, die Tool Suite hopenpgp-tools installieren und seinen öffentlichen Schlüssel mit diesem Befehl prüfen: hkt export-pubkeys '<fingerprint>' | hokey lint (leider scheint das Tool nicht mit 8k Schlüsseln umgehen zu können…).