Die Verschlüsselung mit GnuPG (GNU Privacy Guard) und PGP (Pretty Good Privacy) kann das digitale Leben erheblich sicherer machen. Das Einrichten ist wirklich leicht, doch durch das falsche Einsetzen der Tools ist der erhoffte Sicherheitsgewinn meist nur mäßig.
Wo ist das Problem?
Zwar sind das Installieren und die initiale Konfiguration sehr leicht, jedoch müssen Schlüssel (private wie öffentliche) lokal gepflegt werden, um stets einen hohen Level an Sicherheit zu gewährleisten. Passiert das nicht, ist der Frust meist groß. Ein gutes Beispiel dafür ist das Generieren eines neuen privaten Schlüssels. Der Vorgang der Schlüsselgenerierung ist einfach und schnell getätigt, jedoch scheitert es häufig an der Verteilung, auch wenn alles ordnungsgemäß hochgeladen wurde. Die Folgen dessen sind Mails, die für ungültige, veraltete oder gar verlorene Schlüssel verschlüsselt worden sind, und ein „Hinterherrennen“, dass sich die Leute den aktuellen Schlüssel besorgen. Um diese und weitere Probleme zu vermeiden, gibt es durchaus Mittel und Wege, die jedoch von allen eingehalten werden sollten, vergleichbar mit guten Tischmanieren.
Schlüssel richtig erstellen
Wenn es schnell gehen muss, liest man häufig nur halbherzig oder desinteressiert, doch gerade bei GnuPG und PGP kann man erheblich an Sicherheit gewinnen, wenn man die Details genauer betrachtet. Für gewöhnlich generiert man seine Keys mit
gpg --keygen
Jedoch hat GnuPG die suboptimale Voreinstellung, nur 2048-Bit-RSA-Schlüssel zu generieren. Das ist jedoch nicht zu empfehlen ohne guten Grund, doch dazu mehr weiter unten. Ein Schlüssel, der länger ist, erhöht die Sicherheit der verschlüsselten Daten ungemein. Daher sollte nach Möglichkeit eher eine Schlüssellänge von 4096 Bit gewählt werden.
Auch ein Verfallsdatum ist sinnvoll, denn damit kann man im Falle des Verlusts sicherstellen, dass der Schlüssel zu einem gewählten Zeitpunkt automatisch seine Gültigkeit verliert. Sollte der Schlüssel jedoch noch vorhanden sein und seine Integrität weiter haben, kann man einfach das Verfallsdatum verlängern. Das Verfallsdatum sollte aus Prinzip nicht zu großzügig gesetzt sein, denn dadurch verliert dieser Mechanismus an Bedeutung.
Es ist ebenfalls ratsam, Unterschlüssel für die jeweiligen Aufgaben einzusetzen. Ich persönlich habe einen Unterschlüssel zum Verschlüsseln, einen zum Signieren und einen zum Authentifizieren. Der Masterschlüssel, der immer erstellt wird, ist im eigentlichen Sinne nur für das Keymanagement verantwortlich, die Unterschlüssel dienen dann zur tatsächlichen Aufgabenerfüllung. Per Default erstellt GnuPG immer einen Masterschlüssel mit einem Unterschlüssel zum Verschlüsseln und Signieren, was wiederum einige Nachteile hat. Ist der Unterschlüssel kompromittiert, ist es möglich, einen neuen Unterschlüssel für die jeweilige Aufgabe zu erstellen, deshalb sollte man jeweils einen Unterschlüssel zum Verschlüsseln, einen zum Signieren und einen zum Authentifizieren haben, denn damit vermindert man die Wahrscheinlichkeit, dass alle drei Aufgaben zeitgleich verhindert sind durch den Verlust eines Unterschlüssels. Gleichzeitig ist ein wesentlich besseres Management möglich, da jeder Unterschlüssel autark konfiguriert werden kann und somit beispielsweise verschiedene Verfallsdaten hat.
gpg -K sec rsa2048/0x8C859FD829F10BDB 2017-05-30 [SC] [verfällt: 2018-05-30] Schl.-Fingerabdruck = D2A8 01AF A566 6AD5 169F FB7E 8C85 9FD8 29F1 0BDB uid [ ultimativ ] Ben Rösler <ben.roesler@gzevd.de> ssb> rsa2048/0x65C88B9BCEC43491 2017-05-30 [E] [verfällt: 2018-05-30] ssb> rsa2048/0xDB086DE8E0E33804 2017-05-30 [S] [verfällt: 2018-05-30] ssb> rsa2048/0x4121D9A5AC02E54E 2017-05-30 [A] [verfällt: 2018-05-30]
Übrigens hat mein Schlüssel nur eine Länge von 2048 Bit, da ich eine SmartCard verwende, die leider technisch diese Limitierung mitbringt.
Unabhängig davon, wie sicher man sich fühlt, sollte man immer ein Passwort für seinen privaten GnuPG-Schlüssel verwenden. Es gibt keinen guten Grund, dies nicht zu tun.
Zudem ist es noch wichtig, einen Widerrufsschlüssel zu generieren, denn dieser kann bei Verlust des privaten Schlüssels die letzte Hoffnung zum Schutz vor Missbrauch sein. Wurde ein Schlüssel erst einmal widerrufen, so lässt sich dies nicht mehr rückgängig machen.
Pflege von GnuPG
GnuPG kümmert sich nicht selbst um die Pflege von öffentlichen und privaten Schlüsseln, was den meisten Benutzern noch nicht bewusst zu sein scheint. Die Folge dessen ist oft ein Gefühl, einem Komplexitätsgrad gegenüberzustehen, den man aus Zeitdruck oder Desinteresse als belastend empfindet. Doch es geht auch anders - und leichter. Das Zauberwort ist "Cron" - und es hält, was es verspricht. Ich lasse meine Pflegeaufgaben jeden Tag um 2:00 Uhr nachts abarbeiten, so findet sich in meinem crontab folgende Zeile:
0 2 * * * /usr/bin/gpg --batch --refresh-keys > ~/.log/gpg-keys-update.log
Das Kommando /usr/bin/gpg --batch --refresh-keys sorgt dafür, dass alle Schlüssel regelmäßig aktualisiert werden. So bekomme ich schnell mit, falls jemand seinen Schlüssel widerrufen haben sollte.
Vertraue und bestätige deinen Mitmenschen
GnuPG ist sinnfrei, wenn man nicht vertrauen kann. Es gibt sogenannte „Key-Signing-Parties“, auf denen nichts anderes getan wird, als anderen Schlüsselinhabern zu bestätigen, dass ein bestimmter Schlüssel zu ihnen gehört. Das klingt erst einmal ziemlich aufwendig, aber es gibt dazu bereits Tools, beispielsweise Pius. Sofern man keine Zeit oder keine Möglichkeiten hat, kann man das natürlich auch selbst machen. Das funktioniert folgendermaßen:
gpg --edit-key $YOUR_FRIENDS_KEY sign yes save
Damit bestätigt man, dass der Schlüssel wirklich zu der jeweiligen Person gehört, dafür steht man dann mit seinem Namen.
Eine weitere, nicht so verbindliche Möglichkeit ist es, einem Schlüssel sein Vertrauen zu schenken, davon haben aber wiederum andere nichts. Man sollte es dennoch tun.
gpg --edit-key $YOUR_FRIENDS_KEY trust 5 y quit
Somit legt man sein volles Vertrauen in diesen Schlüssel. Wer dies nicht in dieser absoluten Form möchte, sollte einfach den Dialog von GnuPG lesen und diesem folgen, da GnuPG verschiedene Abstufungen von Vertrauen kennt.
Praktische Gadgets und Tools
Abschließend möchte ich gerne noch kurz ein paar Tools erläutern, die GnuPG verwenden, um mehr als nur Mailverschlüsselung und -signierung bereitzustellen.
Passwortverschlüsselung
Mit password-store lassen sich Passwörter exzellent und sicher verwalten, und das sogar mit mehreren Benutzern versioniert mittels git. Es lohnt sich, dieses einfache Skript in seinen Alltag zu integrieren, denn dadurch lassen sich sogar Skripte realisieren, die wiederum Passwörter benötigen. Für GUI-verliebte Menschen gibt es auch mehrere grafische Oberflächen und Integrationen für MacOS X und Linux.
SSH-Agent
Der GnuPG-Agent hat einen eingebauten ssh-agent, der den traditionellen ssh-agent komplett ersetzen kann. Dazu muss man den GnuPG-Agenten wie folgt starten:
#!/bin/sh /usr/bin/gpg-agent --daemon --enable-ssh-support export GPG_TTY=$(tty) export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
Den ssh-agent braucht man ab dieser Stelle nicht mehr. Man kann wie gewohnt alle ssh-Tools verwenden, auch ssh-add. Hat man einen Unterschlüssel zum Authentifizieren, kann man diesen auch als SSH-Schlüssel verwenden. Den öffentlichen SSH-Key bekommt man mittels
gpg -a --export $KEYID > $KEYID.public.key
Den privaten Key hat man im privaten GnuPG-Schlüsselbund als Unterschlüssel zu seinem privaten Schlüssel.
Dieses Konzept macht sich noch besser mit einer GnuPG-kompatiblen SmartCard, denn damit kann man seinen privaten Schlüssel auf die Karte packen und kann ihn somit immer mit sich tragen. Das erhöht zum einen die Sicherheit, da eine SmartCard zur Verwendung des Schlüssels notwendig ist, und zum anderen die Flexibilität, da die SmartCard mit mehreren Geräten verwendet werden kann.
Git
Es ist möglich, seine Commits zu signieren. Zusammen mit dem zuvor beschriebenen ssh-agent ist somit der Commit eindeutig einer Person zuzuordnen und die Authentifizierung ebenfalls absolut sicher via GnuPG. Um das zu verwirklichen, muss neben ssh-agent noch Git konfiguriert werden, dazu kann man folgende Kommandos verwenden:
git config --global commit.gpgsign true git config --global gpg.program gpg2
Es gibt darüber hinaus noch weitere GnuPG-Integrationen in Git, diese funktionieren jedoch nicht bei jedem Git-Dienstleister. Gegebenenfalls können diese aber auch für das jeweilige Git-Repo konfiguriert werden:
git config push.gpgsign true git config tag.forceSignAnnotated true