Einfaches verschlüsseltes Backup

Seit In­kraft­tre­ten der DSVGO  ist Datenschutz in aller Munde. Da wird es einmal Zeit auch den Datenschutz des Monitoring-Servers zu überdenken. Dabei denke ich in diesem Fall nicht an die diversen Härtungsmaßnamen wie SSL für Webserver und Datenbank. Auch Icinga2 erzwingt bei seinen API Verbindungen immer verschlüsselte Verbindungen.
Wo bleiben aber die Backup Dateien? Einmal erzeugt, verlassen sie den Server und liegen dann ‘woanders’. Zum Glück ist es nicht unbedingt nötig, dass man dem File Server voll vertraut. Eventuell ist es günstig die Backup in irgendeine Cloud zu schieben, oder auf den semi public File Server der Unternehmens. Mit Hilfe von GPG kann man seine Daten einfach verschlüsseln und sicherstellen, dass alle Berechtigten sie auch wieder entschlüsseln können. Im folgenden wird erklärt wie man GPG benutzt um ein icinga2 Backup für eine Gruppe von Berechtigten zu verschlüsseln ohne das der private key einer Person den Monitoring Server oder den Backup Server berührt.

1.) gpg Schlüsselpaar erstellen

Am einfachsten benutzt man das CLI tool gpg um den key zu erzeugen. Das sollte man aber auf einem sicheren System machen, z.B. dem eigenen Laptop oder Arbeitsplatz PC. Anschließend wird der öffentliche Teil an einen Keyserver gesendet um den Schlüsselaustausch zu vereinfachen.

$ gpg --full-gen-key
[...]
Ihr Name ("Vorname Nachname"): Max Mustermann
Email-Adresse: max.mustermann@example.org
pub rsa2048 2018-05-31 [SC] [verfällt: 2023-05-30]
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX0BA2D8D6
Max Mustermann <max.mustermann@example.org>
$ gpg --keyserver pool.sks-keyservers.net --send-key 0BA2D8D6

2.) Monitoring Server mit Schlüsseln versorgen

Auf dem Server kann man mit Hilfe der gpg group Funktion die Daten mit den public keys einer ganzen Gruppe verschlüsseln. Hierfür muss man diese Gruppe in der ~/.gnupg/gpg.conf anlegen.

$ vim .gnupg/gpg.conf +80
group icingabackup = max.mustermann@example.org john.doe@example.org

Anschließend kann man die public keys vom keyserver laden und ihnen das Vertrauen aussprechen. Nur wenn man allen Schlüsseln “absolutes Vertrauen” ausspricht läuft der encryption Prozess ohne weitere Rückmeldungen ab.

$ gpg --keyserver pool.sks-keyservers.net --search-keys max.mustermann@example.org
gpg: suche nach "max.mustermann@example.org" auf hkp-Server pool.sks-keyservers.net
(1)  Max Mustermann (Test) <mustermann@example.org>
      4096 bit RSA key 0BA2D8D6, erzeugt: 2013-11-18
$ gpg --keyserver pool.sks-keyservers.net --recv-keys 0BA2D8D6
$ gpg --edit 0BA2D8D6 trust
  5 = Ich vertraue ihm absolut
$ gpg --keyserver pool.sks-keyservers.net --search-keys johndoe@example.org
gpg: suche nach "johndoe@example.org" auf hkp-Server pool.sks-keyservers.net
(1)  John Doe (Work email) johndoe@example.org
      4096 bit RSA key 732D8994, erzeugt: 2018-04-20, verfällt: 2020-04-19
$ gpg --keyserver pool.sks-keyservers.net --recv-keys 732D8994
$ gpg --edit 732D8994 trust
  5 = Ich vertraue ihm absolut

3.) Backup erzeugen und verschlüssen

Das kurze bash Script sammelt Dateien von icinga2 und icingaweb, erzeugt einen mysqldump, packt alles zusammen und verschlüsselt es zum Schluss. Alle Schritte sind im Script kommentiert. Bitte lesen sie unbedingt auch die Hinweise in der icinga2 Dokumentation zu diesem Thema.

#!/bin/bash
DATE=`date +%Y%m%d%H%M`
# Backup script for icinga2 and icingaweb2
# Choose which parts will be backed up.
BACKUP_ICINGA2=true
BACKUP_ICINGAWEB2=true
BACKUP_MYSQL=true
ENABLE_ENCRYPTION=true
DELETE_OLD_FILES=true
# Backup target dir
BACKUPDIR=/data/icinga2_backup
# Backup retention time. Files will be deleted after 14 days
RETENTION_TIME=14
# Icinga2 settings
ICINGA2FILES="/etc/icinga2 /var/lib/icinga2 /etc/default/icinga2"
# Icingaweb2 settings
ICINGAWEB2FILES="/etc/icingaweb2 /usr/share/icingaweb2"
HTTPD_ETCDIR="/etc/apache2"
# mysql settings
MYSQL_DATABASES="mysql icinga icingaweb director"
MYSQL_ETCDIR="/etc/mysql"
MYSQL_DUMP="$BACKUPDIR/tmp/icingaMysqlDump.sql.gz"
# encryption settings
GPG_RECIPIENT=icingabackup
# Ensure Backupdir exists
[ ! -d $BACKUPDIR ] && mkdir -p $BACKUPDIR/tmp
# Add icinga2 folders
if [ $BACKUP_ICINGA2 = true ]; then
  BACKUPFILES+=" $ICINGA2FILES"
fi
# Add icingaweb2 folders
if [ $BACKUP_ICINGAWEB2 = true ]; then
  BACKUPFILES+=" $ICINGAWEB2FILES"
  BACKUPFILES+=" $HTTPD_ETCDIR"
fi
# Add my folders and mysqldump
if [ $BACKUP_MYSQL = true ]; then
  BACKUPFILES+=" $MYSQL_ETCDIR"
  if [ ! -z "$MYSQL_DATABASES" ]; then
    mysqldump --create-options --databases ${MYSQL_DATABASES} | gzip > $MYSQL_DUMP
    BACKUPFILES+=" $MYSQL_DUMP"
  fi
fi
# make archive
TAR=$BACKUPDIR/icingaBackup_${DATE}.tar.gz
if [ ! -z "$BACKUPFILES" ]; then
  # Archive all files and delete mysqldump
  tar -czf $TAR $BACKUPFILES 2> /dev/null && [ -e $MYSQL_DUMP ] && rm $MYSQL_DUMP
fi
# encrypt archive
if [ $ENABLE_ENCRYPTION = true ]; then
  gpg --encrypt --recipient icingabackup $TAR && rm $TAR
fi
# delete everything older than 14 days
if [ $DELETE_OLD_FILES = true ]; then
  find $BACKUPDIR -mtime +$RETENTION_TIME -exec rm \{\} \;
fi

4.) Cron

Um das Backupscript jeden Tag auszuführen kopiert man es auf den Server und trägt es im crontab ein:

root@icingaMaster# crontab -e
  @daily /root/backup_icinga2.sh

5.) Decrypt

Da beim verschlüsseln alle User der Gruppe icingabackup berechtigt wurden kann jeder aus dieser Gruppe die Dateien wieder entschlüsseln.
gpg –output icinga2Backup.tar.gz –decrypt icinga2Backup.tar.gz.gpg
 

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Generationswechsel bei GnuPG/PGP Schlüsseln

Die für digitale Signaturen und zum Verschlüsseln von Daten verwendeten GnuPG bzw. PGP Schlüssel sind keine reinen Schlüssel im eigentlichen Sinne. Stattdessen enthalten sie den eigentlichen Schlüssel und diverse zusätzliche Informationen wie, für welche “IDs” (also Kombinationen aus Name und E-Mailadresse) sie gültig sind, wie lange sie gültig sind und einige Informationen über Hash- und Verschlüsselungsalgorithmen, die der Besitzer des Schlüssels vorzieht oder überhaupt zulässt.
Da sich das Wissen über die verwendeten Algorithmen weiterentwickelt und immer mehr Rechenleistung immer günstiger zu haben ist kann man leider nicht davon ausgehen, dass man einen Schlüssel für immer verwenden kann. Irgendwann ist er schlichtweg überholt und kann nicht mehr als sicher gelten. Dafür sind vor allem drei Komponenten ausschlaggebend: Die Länge des eigentlichen Schlüssels, der bevorzugte Verschlüsselungsalgorithmus und der für Signaturen verwendete Hash-Algorithmus.
Bei der Länge wird man beim Erstellen des Schlüssels mit einer Auswahl konfrontiert, die eine minimale und eine maximale Länge angibt. Manchmal kann man diese Auswahl auch übersteuern, läuft dann aber Gefahr, einen Schlüssel zu haben, mit dem viele Kommunikationspartner gar nichts anfangen können oder der so lange für jede Aktion braucht, dass er alleine schon deshalb unbrauchbar ist. Unter einigen Umständen bringt ein extralanger Schlüssel überhaupt nichts, da z.B. damit nur eine weitere, einmalige, Passphrase gesichert wird, die eine fixe Länge hat. (Asymmetrische Verfahren für lange Texte zu verwenden ist auch heute noch zu rechenintensiv, weshalb meist ein symmetrisches Verfahren mit einer einmaligen Passphrase eingesetzt wird und nur die wird asymmetrisch verschlüsselt). Etwas mehr dazu findet man in einem älteren Post zu dem Thema.
Die für die Kommunikation bevorzugten Algorithmen kann man in den “Preferences” des Schlüssels setzen. Mehr dazu im zuvor genannten Blogpost.
Signaturen jedoch werden einmalig erstellt und sollen dann gelten. Wer schon länger mit GnuPG arbeitet wird also noch einige Signaturen mit SHA1, so auch die Selbstsignatur, mit der der Schlüssel ursprünglich ausgestattet wurde. SHA1 gilt aber schon lange nicht mehr als sicher, weshalb man ihn auch nicht mehr benutzen sollte. (Ebenso MD5, mit dem auch früher Signaturen erstellt wurden). Wer einen DSA Schlüssel mit 1024bit Länge hat, sollte sich jetzt angesprochen fühlen.
Es gibt also mittlerweile mehrere Gründe, manche alte Schlüssel zu überdenken. Die Liste der bevorzugten Algorithmen lässt sich auch bei einem bestehenden Schlüssel einfach austauschen. Die Schlüssellänge liesse sich durch einen neuen Subkey realisieren, der aber auch einige extra Schritte beim Handling braucht. Signaturen auszutauschen wird aber ein aufwändiger Prozess, weil man mit allen, die den alten Schlüssel signiert haben, nochmal in Kontakt treten und sie um neue Signaturen auf dem neuen Schlüssel bitten muss. Und da wir ja hoffentlich alle sehr viele Signaturen auf unseren Schlüsseln haben, kann das schon recht aufwändig werden.
Um also möglichst alle Probleme, die ein alter Schlüssel mit sich bringt, auf einmal zu erschlagen, gehen viele User den Weg, einfach einen neuen Schlüssel anhand möglichst aktueller Best Practices (als Ausgangspunkt kann wieder der vorherige Blogpost dienen) zu erstellen und auf den umzusteigen.
Um einen neuen Schlüssel zu etablieren und einen alten dadurch zu ersetzen, kann man folgendermassen vorgehen:

  • Einen neuen Schlüssel anhand aktueller Best Practices erstellen
  • Den neuen Schlüssel mit dem alten Schlüssel signieren
  • Ob man auch den alten Schlüssel mit dem neuen signieren soll, da gehen die Meinungen auseinander. (Ich hab’s jedenfalls immer gemacht)
  • Den neuen Schlüssel (und ggf. den alten, aktualisierten) auf Schlüsselsever hochladen
  • Den neuen Schlüssel bekanntmachen. Am besten über möglichst viele Kanäle, die man sonst auch nutzt, um mit der Welt zu kommunizieren. E-Mail, Soziale Medien, Blog, Website,…
  • “Dinge”, die bestehen bleiben sollen, also Dokumente, Pakete, etc. die mit dem alten Schlüssel signiert wurden mit dem neuen Schlüssel signieren. Wenn mehrere Signaturen möglich sind, sollte die neue hinzukommen, sonst muss sie ersetzt werden. Vor diesem Schritt sollte man etwas warten, damit die Empfänger eine Chance haben, den neuen Schlüssel zu holen bzw. zu bemerken.
  • Die Leute, die den alten Schlüssel signiert haben, sollten informiert und gebeten werden, den neuen Schlüssel ebenfalls zu signieren.

Für den letzten Punkt gibt es einige Vorlagen, die man verwenden kann. Es bietet sich an, ein Klartextdokument aufzusetzen, in dem über den Tausch informiert wird und gleich die nötigen Befehle mitzuliefern, mit der der neue Schlüssel geholt und signiert werden kann. Ein entsprechendes Beispiel habe ich für meine persönlichen Schlüssel verfasst. Dieses Dokument wurde auch gleich sowohl mit dem alten als auch dem neuen Schlüssel unterschrieben, um den Empfängern die Echtheit zu bestätigen.

gpg --digest-algo SHA512 --clearsign -u 6265BAE6 -u A84CB603 key-transition-2018-01-05.txt

Dieses Dokument sollte man möglichst öffentlich machen und an die Leute schicken, die den alten Schlüssel signiert haben.
Verwendet man den Schlüssel auch zum Signieren von Paketen, ist der Umstieg etwas schwieriger. Man kann leider nicht erwarten, dass jeder User, der die Software einsetzt, auch regelmässig ein Blog oder andere Neuigkeiten liest, weshalb ein einfaches Ersetzen des Schlüssels dazu führen würde, dass die User neue Pakete nicht mehr installieren können. Um den Umstieg einfacher zu machen sollte bereits im Vorfeld ein “release”-Paket bereitgestellt werden, also eines das das eigene Repository in den Packagemanager der User konfiguriert und den entsprechenden Schlüssel ablegt. In diesem Paket kann man in einem neuen Release dann auch den neuen Schlüssel hinterlegen, sodass beide, der neue und der alte in den Packagemanager kommen. Stellt man später um, mit welchem Schlüssel man Pakete signiert, werden sie automatisch als valide signiert erkannt. (Da sich verschiedene Packagemanager unterschiedlich verhalten, sollte man das unbedingt vorher testen!)
Nicht abgedeckt sind jene User, die das Repository “von Hand” angelegt und den Schlüssel manuell importiert haben. Klar könnte man in eine Version der Software selbst den neuen Schlüssel-Import ins Paket verbauen, aber das würden einem die User (zu recht) um die Ohren hauen, da das Software Paket nur die Software installieren soll und nichts am Paketmanager verändern. Beim Release-Paket ist das was anderes, da das ja genau für solche Aufgaben gebaut wurde. Hier heisst es, im Vorfeld umso mehr über diverse Kanäle zu kommunizieren und es auch möglichst in alle fertigen Module, Cookbooks, Playbooks, etc. zu integrieren, dass für kurze Zeit zwei Schlüssel vorhanden sind und wann umgestiegen wird. Besonders geeignet ist natürlich der Release einer grösseren neuen Version, wo vielleicht sowieso ein neues Repository gebaut wird.
Einige Zeit, nachdem der Umstieg vollzogen wurde, sollte man den alten Schlüssel “revoken”, damit er nicht mehr benutzt wird. Auch könnte man das Release-Paket dazu bringen, den alten Schlüssel aus den Packagemanagern zu entfernen. Sollte tatsächlich jemand den alten Schlüssel knacken, ist man so auf der sicheren Seite und genau dafür hat man den Umstieg ja gemacht. Alte Informationen, die mit dem alten Schlüssel verschlüsselt wurden, kann man übrigens auch mit einem revoked key noch immer entschlüsseln. Jedenfalls kenne ich keine Software, die das nicht mehr erlauben würde. Nur verschlüsseln geht dann eben nicht nicht mehr.
Etwas mehr zum Nachlesen zum Thema gibt’s unter anderem auf den Debian Seiten.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

Weekly Snap: OSDC 2014, Puppet Camp & GnuPG/GPG Best Practices

weekly snap7 – 11 April was OSDC 2014 and PuppetCamp week, with a few GPG best practices and Python musings slipped in.
Eva ended her countdown to the OSDC with Daniel Kirstenpfad’s talk on ‘Why Virtual Development and Testing isn’t Rocket Science’ and thanked all attendees and sponsors in advance. Dirk and Michael then followed with their highlights from the first and second days at the OSDC 2014.
Continuing with events, Christian announced the next round of webinars featuring Request Tracker, Puppet, Bareos and inGraph and Dirk returned with his review of Puppet Camp 2014.
Thomas then gave a comprehensive rundown of GnuPG / GPG best practices as Alexander shared his thoughts on Python 2.4 and RHEL.
Finally, Georg ended the week by introducing the newest addition to our hardware store: HW Group Poseidon2 3266.

GnuPG / GPG Best Practices

Dieser Artikel richtet sich an User, die bereits etwas Erfahrung mit GnuPG / GPG / OpenPGP haben. GnuPG liefert bereits sehr brauchbare Standardeinstellungen mit und es kann ohne Probleme ohne grossen Zusatzaufwand verwendet werden. Wer aber etwas tiefer eintauchen, höhere Sicherheit und mehr Komfort möchte, findet im Folgenden einige Vorschläge.
Die Konfiguration
Normalerweise konfiguriert man GnuPG durch ein Konfigfile, meist ~/.gnupg/gpg.conf. Einige graphische Frontends sollten einige dieser Optionen auch anbieten und sie gegebenenfalls in eine Konfigurationsdatei schreiben.
Bei mir sieht das so aus:

default-key 91B8ECDC6265BAE6
default-recipient-self
keyserver hkp://keys.gnupg.net
keyserver-options auto-key-retrieve
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
personal-cipher-preferences AES256 AES192 AES
personal-compress-preferences SHA512 SHA384 SHA256 SHA224
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
use-agent
verify-options show-uid-validity

Nicht alle Optionen sind für die Verwendung des Schlüssels für sichere E-Mail wichtig, sondern werden mehr beim Verschlüsseln und Signieren von Dateien auf der Kommandozeile verwendet. Die Optionen können auch beim Aufruf von gpg auf der Kommandozeile angegeben werde. Eine Liste findet sich auf der GnuPG Homepage.
Der default-key gibt einfach an, welcher Schlüssel als eigener Schlüssel für Signaturen oder Verschlüsselung an sich selbst verwendet wird. Dabei wird eine längere Fassung der ID verwendet, da es bei der 8 stelligen Kurzfassung, die man oft sieht, zu leicht zu Kollisionen kommen kann. Wer meinen Schlüssel betrachtet, wird sehen, dass ich auch noch nicht alle dieser Ratschläge mit diesem Key umgesetzt habe. Ein neuer Schlüssel ist generiert, hat aber noch zu wenig Signaturen, um ihn sinnvoll zu verwenden. Es ist also nur mehr eine Frage der Zeit, bis ich mich an meine eigenen Empfehlungen halte. 🙂
Die Option default-recipient-self gibt an, dass man beim Verschlüsseln auf der Kommandozeile keinen Empfänger angeben muss, sondern immer mit dem eigenen Key verschlüsselt wird, wenn keine ID angegeben wird.
Mit keyserver wird der Standardkeyserver angegeben, der genutzt wird, wenn kein anderer Schlüsselserver auf der Kommandozeile genannt wird. Dabei wird immer wieder davor gewarnt, pgp.mit.edu als Keyserver zu verwenden, da dieser berüchtigt dafür ist, Daten nicht sauber mit anderen Servern zu synchronisieren. Welcher andere Keyserver genannt wird, ist meist nebensächlich, da sich eigentlich alle Keyserver miteinander abgleichen sollen.
Durch keyserver-options auto-key-retrieve werden Schlüssel, die im Keyring fehlen, aber zum Verifizieren von Signaturen benötigt werden, automatisch geholt.
Die personal-digest-preferences, personal-cipher-preferences und personal-compress-preferences Listen geben an, welche dieser Algorithmen man bevorzugt, in absteigender Reihenfolge. Beim Versand einer Nachricht wird damit jeweils von links an nach dem ersten Algorithmus gesucht, den alle Empfänger unterstützen. So ist sichergestellt, dass möglichst starke Standards verwendet werden, aber auch an ältere oder suboptimal konfigurierte Clients versandt werden kann. Gibt man z.B. keinen Digest (Hashing) Algorithmus aus der SHA-2 Familie an, nutzt GnuPG Standardmässig SHA-1 für Hashing, was nicht mehr empfohlen werden kann. Es sollte unbedingt ein Algorithmus aus der SHA-2 Familie vor SHA-1 und MD5 in der Liste stehen. Welche Algorithmen in der eigenen Installation zur Verfügung stehen, sieht man übrigens bei einem Aufruf von gpg --version. Bei diesen Optionen eine Liste anzugeben, verhindert den Versand nicht, da immer ein Algorithmus gewählt wird, den alle Empfänger verstehen. Das bedeutet aber auch, dass unter Umständen dennoch unsichere Algorithmen verwendet werden.
Die Option cert-digest-algo ist etwas tückisch. Sie gibt an, welcher Hash Algorithmus beim Signieren von fremden Schlüsseln verwendet wird. Wird der nicht von anderen Usern unterstützt, können Signaturen nicht überprüft werden. Gilt das auch für die Selbstsignatur eines Schlüssels, kann er gar nicht vom Kommunikationspartner verwendet werden. Standard ist eigentlich MD5 für PGP2 Schlüssel und SHA-1 für alle anderen Schlüssel. Da diese aber nicht mehr verwendet werden sollten, steht man vor der Wahl: Unsicherer Algorithmus oder unter Umständen Inkompatibilität zu anderen Usern. Ich habe mich bei neuen Schlüsseln für die mögliche Inkompatibilität entschieden. Vielleicht kann ich damit ja auch den einen oder anderen User zum Upgrade auf eine sichere Version bewegen. Da Signaturen normalerweise nur einmal erstellt werden, sollte man diese Option unbedingt setzen, bevor man einen neuen Schlüssel erstellt. Aus den genannten Gründen führen auch manche Seiten diese Option als “esoteric option” auf. 🙂
Mit default-preference-list gibt man an, welche Algorithmen man selbst unterstützen möchte. Diese Liste wird beim Erstellen eines neuen Schlüssels verwendet, sie sollte also unbedingt gesetzt werden, bevor man einen Schlüssel erstellt. Diese Liste wird auch im Schlüssel verankert und daraus und aus den oben genannten personal-...-preferences wird dann die beste bevorzugte Version ausgesucht, die von allen Beteiligten unterstützt wird. Diese Einstellung kann auch nachträglich am Schlüssel geändert werden. Allerdings muss dann der Absender wieder den aktuellen Schlüssel haben, um die aktuelle Liste zu verwenden. Also auch gleich lieber vor Erstellung eines neuen Schlüssels richtig setzen.
use-agent gibt lediglich an, dass der GnuPG Agent verwendet wird, sofern verfügbar. Damit wird eine eingegebene Passphrase für einige Zeit gespeichert und man muss sie nicht gleich erneut eingeben.
Zu guter letzt sorgt verify-options show-uid-validity dafür, dass beim Anzeigen von UIDs auch gleich deren Gültigkeit angezeigt wird.
Beim Erstellen neuer Schlüssel zu beachten
Wie erwähnt, macht es Sinn, die Optionen in der Konfigurationsdatei zu setzen, bevor man einen Schlüssel erstellt.
Mit gpg --gen-key wird die Erstellung eines neuen Schlüssels gestartet. Ausnahmsweise sei es auch erlaubt, eine GUI dafür zu verwenden. 😉 Dieser Artikel richtet sich an Fortgeschrittene, weshalb auf die Erstellung an sich nicht weiter eingegangen wird.
Als Schlüsselpaar wird bei aktuelleren GnuPG Installationen bereits RSA/RSA vorgeschlagen, was auch übernommen werden sollte.
Dann kommt das leidige Thema der Schlüssellänge. Hier gilt fast noch mehr, als bei den Algorithmen, dass davon die Kompatibilität zu Kommunikationspartnern abhängt. Die meisten sollten inzwischen 4096bit unterstützen. Weniger sollte man alleine schon deshalb nicht mehr wählen, weil man den Schlüssel ja einige Zeit behalten möchte und 4096bit noch länger aktuell bleiben wird, als kürzere Schlüssel. Längere Schlüssel werden noch immer von zu wenig Clients unterstützt. Wobei man bedenken sollte, dass viele Clients zwar keine Erstellung von Schlüsseln über einer bestimmten Länge anbieten, aber sehr wohl mit solchen umgehen können. Es gibt noch weitere Gründe, warum es nicht unbedingt sinnvoll ist, längere Schlüssel als 4096bit zu erstellen, aber dazu vielleicht später mehr.
Es gibt einige Artikel, die darauf eingehen, ob es Sinn macht, ein Kommentar zum Schlüssel hinzuzufügen. Wobei die meisten entweder sehr dafür oder sehr dagegen sind. Ich selbst füge nur mehr Kommentare hinzu, wenn es für mich Sinn macht. Ein Beispiel wäre “package signing key” für Schlüssel, über die ich eigentlich nicht kommunizieren möchte. Kommentare, die nur Informationen enthalten, die man auch aus der zu der uid gehörigen E-Mail Adresse entnehmen kann, kann man getrost weglassen.
Wichtig ist, ein Ablaufdatum festzulegen. Einige Seiten empfehlen, es nicht weiter als 5 Jahre in die Zukunft zu setzen. Es kann jederzeit, auch nach Ablauf des Schlüssels, verändert werden. Nach einer Änderung sollte der Schlüssel wieder auf einen Keyserver hochgeladen werden. Auch wenn man noch so darauf achtet, kann es passieren, dass man den privaten Teil des Schlüssels verliert oder die Passphrase vergisst. Dann sollte der Schlüssel nicht ewig über die Keyserver geistern, sondern irgendwann entfernt werden. Dabei geht es weniger darum, dass Ressourcen gespart werden, sondern mehr darum, dass ein Kommunikationspartner auch wirklich nur Schlüssel von den Keyservern holt, die auch noch zum Entschlüsseln genutzt werden können. Ähnliches gilt, wenn der Besitzer des Schlüssels ihn aus anderen Gründen nicht mehr nutzen kann (z.B. weil er verstorben ist)
Nach dem Erstellen des Schlüssels
Als erstes sollte ein Revocation Certificate erstellt werden. gpg --output revoke.asc --gen-revoke [keyid] Dieses sollte an einem sicheren Platz (USB Stick in einem Tresor, Truecrypt Container, oder vergleichbares) abgespeichert und evtl. sogar ausgedruckt (dazu beim Erstellen die Option --armor verwenden, um das Zertifikat als ASCII zu erhalten) werden, um sie im schlimmsten Fall abzutippen. Mit diesem Zertifikat kann der Schlüssel ungültig gemacht werden, ohne, dass man den privaten Teil oder die Passphrase braucht. Das ist einerseits gut, wenn man einen oder beide dieser Teile verloren hat, aber andererseits sehr gefährlich, weil jeder damit den Schlüssel ungültig machen kann. Um es zu verwenden, importiert man es einfach in seinen Schlüsselbund und lädt den Schlüssel auf einen Keyserver hoch. Ab da scheint er bei jedem als ungültig auf, der die aktuelle Version des Schlüssels hat.
Dann können weitere IDs zu dem Schlüssel hinzugefügt werden. Eine für jede E-Mail Adresse, mit der man den Schlüssel verwenden will. Einige Anleitungen empfehlen auch, eine ID ohne E-Mail Adresse hinzuzufügen, da sich der Name seltener ändert als E-Mail Adressen. Ich bin ein Freund davon, sich zumindest eine Adresse mit einer eigenen Domain zuzulegen, die sich möglichst nie ändert, was diesen Grund wieder relativiert. Ausserdem signieren manche automatisierte Tools nur “aktive” IDs, also solche, von deren E-Mail Adressen man auch Nachrichten empfangen kann, was hier ebenfalls nicht funktionieren würde. Es spricht aber auch nicht wirklich etwas gegen das Erstellen einer solchen ID.
Eine Photo ID finde ich persönlich sinnvoll, vor allem wenn man Schlüssel nur bei persönlichem Kontakt signiert. Legt man sich selbst eine Signatur Policy zurecht, die auch Signaturen ohne persönliches Treffen erlauben, kann es sinnvoll sein, auf die Signatur einer Photo ID zu verzichten. Man kann ja auch einzelne IDs signieren.
Mit gpg --send-key [keyid] schickt man den Schlüssel dann an den konfigurierten Keyserver. An sich reicht es, ihn an einen Server zu senden, da sich die Keyserver untereinander synchronisieren. In der Praxis funktioniert das nicht immer reibungslos, aber im Allgemeinen findet jeder Schlüssel früher oder später den Weg zu den einzelnen Servern.
Regelmässige Wartung
Da, anders als bei S/MIME, aktualisierte Schlüssel nicht beim Versand von E-Mails übertragen werden, sondern immer wieder vom Keyserver geladen werden müssen, ist es sehr wichtig, die Schlüssel regelmässig von einem Keyserver zu aktualisieren. Dazu habe ich folgenden Eintrag in meiner crontab: 40 5 * * 4 /usr/bin/gpg --refresh-keys --keyserver-options no-honor-keyserver-url ; /usr/bin/gpg --refresh-keys --keyserver-options honor-keyserver-url . Das funktioniert, weil ich das Gerät regelmässig für Wartungsaufgaben über Nacht laufen lasse. Wer das anders hält, muss eben die Zeit des cronjobs anpassen. Dabei führe ich --refresh-keys zwei mal aus. Einmal hole ich die Schlüssel von dem Keyserver, den ich mir als Standard konfiguriert habe und einmal von dem Keyserver, den die Schlüsselbesitzer evtl. in ihren Schlüsseln hinterlegt haben. Damit respektiere ich einerseits, falls jemand seinen Schlüssel an einem bestimmten Server pflegt, der sich unter Umständen gar nicht mit anderen Schlüsselservern synchronisiert und bin andererseits dafür gewappnet, dass jemand evtl. einen Server angegeben hat, der gar nicht mehr existiert. Wer keinen hkps fähigen Keyserver verwendet, überträgt damit regelmässig eine Liste der Schlüssel im eigenen Keyring und damit wahrscheinlich eine Liste der regelmässigen Kommunikationspartner. Es gibt Tools, die helfen, das zu Verschleiern, ohne auf hkps umsteigen zu müssen, da aber keine weitere Information enthalten ist, hebe ich Anleitungen dafür für etwaige spätere Artikel auf.
Mit dem Befehl gpg --update-trustdb kann man die Trust-DB ausfüllen. Damit gibt man für alle Schlüssel, für die man das noch nicht getan hat, an, wie sehr man dem Besitzer zutraut, Schlüssel anderer Personen nur nach ordentlicher Überprüfung der Identität zu vertrauen. Diese Information hat durchaus mit der persönlichen Meinung über die Besitzer zu tun und sollte deshalb sehr vertraulich behandelt werden. Sie wird auch nicht mit einem Schlüssel exportiert. Zu beachten ist, dass dies nichts damit zu tun hat, wie sehr man dem Besitzer eines Schlüssels glaubt, tatsächlich der zu sein, der er zu sein vorgibt. Diesen Befehl sollte man regelmässig ausführen, da diese Einstufung bei jedem neu importierten Schlüssel nötig ist. Das muss interaktiv passieren, deshalb macht es keinen Sinn, einen Cronjob dafür zu planen.
Zum Backup der geheimen Schlüssel sollte man ab und zu gpg --export-secret-keys --armor ausführen und den Output an einem sicheren Ort speichern. Zwar ist der Schlüssel mit der Passphrase geschützt, aber nur darauf sollte man sich auf keinen Fall verlassen. Die öffentlichen Schlüssel kann man zwar von Schlüsselservern neu holen, aber wenn man schon mal dabei ist: gpg --export --armor.
Es ist auch sinnvoll, immer wieder zu kontrollieren, ob das Ablaufdatum des Schlüssels nicht kurz bevor steht. Da es einige Zeit braucht, bis alle Kommunikationspartner einen aktualisierten Schlüssel holen, sollte man früh genug damit beginnen, das Ablaufdatum wieder nach hinten zu verschieben und den öffentlichen Schlüssel über die Keyserver zu verteilen.
Als stolzer Schlüsselbesitzer sollte man regelmässig versandte Mails signieren. Das ist wahrscheinlich der effektivste Weg, herauszufinden, ob man nicht unter seinen regelmässigen Kommunikationspartnern auch GnuPG Anwender hat. Ausserdem wird so oft die Rückfrage kommen, was denn “diese komischen Zeichen” sein sollen. Ein sehr praktischer Weg, um ein Gespräch über sichere E-Mailkommunikation zu beginnen. 🙂
Was man sonst noch tun kann
Natürlich sollte man über diesen Vorschlägen nicht vergessen, den Schlüssel einfach auch mal zu verwenden. Zum Signieren und Verschlüsseln von E-Mails, Signieren von Softwarepaketen, Verschlüsseln von Dateien, die man sicher aufbewahren will und einiges mehr.
Die wichtigste Regel im Umgang mit E-Mail Sicherheit ist meiner Meinung die gleiche, die ich für Wiederbelebung in der Ersten Hilfe gelernt habe: Hauptsache, man tut’s. Auch wenn man sich nicht ans Handbuch hält und vielleicht nicht alles perfekt ausführt, ist es immer noch viel, viel besser, als nichts zu tun. Bei beidem gilt jedoch auch, dass man immer nur Chancen verschieben kann. 100% Erfolgschance gibt es bei beidem leider nicht, auch wenn man noch so gut vorbereitet ist. Je besser man sich vorbereitet, umso höher sind aber die Chancen des Erfolges. Sicher ist nur eines: Macht man nichts, sieht’s düster aus.
Für alle, die sich dennoch gerne vorbereiten wollen, soll dieser Artikel einen Anhaltspunkt für den E-Mail Teil des Vergleichs geben, für den Rest gibt’s hier, hier und bei vielen anderen Stellen, die ich leider hier aus Platzgründen nicht mehr nennen kann, Angebote.
Für die Nerds und Geeks unter den Lesern findet sich viel Spass mit Graphen und Statistiken zu Schlüsseln auf http://pgp.cs.uu.nl/
Natürlich gibt es noch viel mehr, was man mit GnuPG und GPG Schlüsseln machen kann, was sich im täglichen Leben als praktisch und/oder sicher erweist, aber als Start sollte dieser Artikel einige Anhaltspunkte geben. Sollte Bedarf bestehen, können gerne Einführungsanleitungen folgen. Eine wunderbare Anwendung des Kommentarfeldes, solchen Bedarf anzumelden. 🙂
Noch eine Anmerkung: Sicherheitstechnologien sind einem ständigen Wandel unterworfen. Es lohnt sich also immer, mal kurz nach dem aktuellen Stand der Technik zu suchen, um zu vergleichen, ob die Informationen nicht schon wieder überholt sind. Bei Kommunikationstechnologien ist das doppelt wichtig, da sich Sender und Empfänger auf einen Satz an Technologien einigen müssen. Dafür wird  oft eine gewichtete Liste konfiguriert, welche Technologien unterstützt werden und welche bevorzugt werden. Das sollte nicht zu restriktiv gehalten werden, sonst kann es schon zu Problemen beim Versand von E-Mails von sehr konservativen Betriebssystemen an Bleeding-Edge OS und umgekehrt kommen. Beispiele solcher Listen finden sich oben in dem Beispiel der Konfigurationsdatei.
Für weitere Vorschläge anderer Best Practices bietet sich ebenfalls die Kommentarfunktion an.
Ein paar weiterführende Links zum Thema:

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...