GnuPG und PGP können das digitale Leben erheblich sicherer machen. Das Einrichten der Werkzeuge ist wirklich leicht, doch durch das falsche Einsetzten der Werkzeuge ist der erhoffte Sicherheitsgewinn meist nur mäßig.

Wo ist das Problem?

Zwar ist das Installieren und initiale Konfigurieren sehr leicht, jedoch müssen Schlüssel, private sowie öffentliche, lokal gepflegt werden um stets ein hohen Level an Sicherheit zu gewährleisten. Passiert das nicht so 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 “hinterher rennen” das sich die Leute den aktuellen Schlüssel besorgen. Um diese und weitere Probleme zu vermeiden gibt es aber 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, so sollte nach Möglichkeit eher eine Schlüssellänge von 4096-bit gewählt werden.

Auch ein Verfallsdatum macht durchaus Sinn, damit kann man im Falle des Verlusts sicherstellen das der Schlüssel zu einen gewählten Zeitpunkt automatisch seine Gültigkeit verliert, sollte der Schlüssel jedoch noch vorhanden sein und seine Integrietät noch 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 einzusetzten, 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 einen Unterschlüssel zum Verschlüsseln und Signieren, das hat wiederum einige Nachteile. Ist der Unterschlüssel komprimitiert 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 das alle drei Aufgaben zeitgleich verhindert sind durch den Verlust eines Unterschlüssels. Gleichzeitig ist ein wesentlich besseres Management möglich, da jeder Unterschlüssel autag konfiguriert werden kann und somit z.B. verschiedene Verfallsdaten haben kann.

# 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]

Übrings hat mein Schlüssel nur eine Länge von 2048-bit, da ich eine SmartCard verwende die leider technisch diese Limitierung mitbringt.

Egal wie sicher man sich auch fühlt, man sollte immer ein Passwort für seinen privaten GnuPG-Schlüssel verwenden. Es gibt keinen guten Grund dies nicht zu tun.

Zu letzt ist noch wichtig ein 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, das scheint den meisten Benutzern noch nicht bewußt zu sein. Die Folge dessen ist ein Gefühl einen Komplexitätsgrad gegenüber zu stehen, den man meist wegen Zeitdruck oder Desintresse 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 das alle Schlüssel regelmäßig aktualisiert werden, so kriege ich es schnell mit sollte jemand seinen Schlüssel widerrufen haben.

Vertraue und bestätige deinen Mitmenschen

GnuPG ist sinnfrei wenn man nicht vertrauen kann. Es gibt sognannte “Signing Parties” auf denen nichts anderes getan wird als anderen Schlüsselinhabern zu bestätigen das ein bestimmter Schlüssel zu ihnen gehört. Das klingt erstmal ziemlich aufwendig, aber es gibt dazu bereits Tools, wie beispielsweise Pius. Wenn man keine Zeit oder keine Möglichkeiten hat kann man das natürlich auch im selbst machen. Das funktioniert folgendermaßen:

# gpg --edit-key $YOUR_FRIENDS_KEY
sign
yes
save

Damit bestätigt man das der Schlüssel wirklich zu der jeweiligen Person gehört, dafür steht man dann mit seinen Namen.

Eine weitere, nicht so verbindliche, Möglichkeit ist es einen 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 schenkt 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 folgen, da GnuPG verschiedene Abstufungen von Vertrauen kennt.

Praktische Gadets und Tools

Zum Schluss 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 ersetzten kann. Dazu muss man den GnuPG Agent 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 dann 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 kriegt man mittels

# gpg -a --export $KEYID > $KEYID.public.key

Den privaten Key hat man im privaten GnuPG Schlüsselbund als Unterschlüssel an seinen 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üssel 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 den zuvor beschriebenen SSH-Agent ist somit der Commit eindeutig einer Person zuzuordnen und die Authenfizierung ebenfalls absolut sicher via GnuPG. Um sein das zu verwirklichen muss neben dem 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-Integration in Git, dieser funktionieren jedoch nicht bei jeden 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