Sicherheitsmail I: mutt und OpenPGP

Obwohl ich weder ein herausgehobenes politisches Amt noch eine heimliche Affäre habe, hadere ich schon seit langem mit den RFC 822, 2822 und 5322. Glücklicherweise gibt es aber auch die RFC 2045, 1847, 3156, 4880 und 5751.

Etwas weniger verrätselt: Das Internet Message Format als Grundlage aller E-Mails sieht keine Verschlüsselung vor, allerdings gibt es im Rahmen der Multipurpose Internet Mail Extensions (MIME) zwei Signatur- und Verschlüsselungsstandards: S/MIME und OpenPGP. OpenPGP hat den Vorteil, dass die Nutzerin selbst Schlüsselpaare generieren kann, während S/MIME auf eine Infrastruktur von Certificate Authorities zurückgreift, die individuelle Schlüsselpaare (Zertifikate) erstellen und beglaubigen. Darüber hinaus werden öffentliche PGP-Schlüssel in der Regel über Keyserver verwaltet, während der öffentliche Teil eines S/MIME-Zertifikates üblicherweise Bestandteil einer signierten Nachricht ist. Die unterschiedliche Handhabung folgt daraus, dass öffentliche PGP-Schlüssel ihre Vertrauenswürdigkeit durch möglichst viele Signaturen von Einzelpersonen (bzw. durch eine Signatur mit den privaten Schlüsseln dieser Einzelpersonen) erwerben, während S/MIME-Zertifikate dank des impliziten Vertrauens in Certificate Authorities nicht durch zusätzliche Signaturen angereichert werden müssen.

In meinem geradezu US-amerikanischen Pursuit of Autonomy ist mir OpenPGP etwas sympathischer.

Mein minimalistischer MUA verzichtet auf eine OpenPGP-Implementierung und stützt sich stattdessen auf GnuPG. Den warnenden Hinweis auf der Projekt-Website

GnuPG comes in two flavours: 1.4.13 is the well known and portable standalone version, whereas 2.0.19 is the enhanced and somewhat harder to build version.

– sollte man sehr ernst nehmen: Vor der Installation von GnuPG 2.0.19 müssen nämlich libassuan, libgcrypt, libgpg-error, libksba sowie pth kompiliert (./configure --prefix=/usr/local; make) und installiert (/sudo make install) werden. Spätestens vor der ersten Schlüsselgenerierung kommt dann noch pinentry hinzu (./configure --prefix=/usr/local --enable-embedded; make; sudo make install – ohne die embedded-Option bemängelt der Compiler die fehlende X-Umgebung). Anschließend lässt sich mit

gpg --gen-key

ein eigenes Schlüsselpaar erstellen, das automatisch im Ordner ~/.gnupg (pubring.gpg bzw. secring.gpg) abgelegt wird. Die ID des Schlüsselpaares wird während der Generierung angezeigt und lässt sich später wie folgt abrufen:

bash$ gpg --list-secret-keys /home/joe/.gnupg/secring.gpg ----------------------------- sec 4096R/FC382382 2013-05-08 [expires: 2015-05-08] uid Jonathan Dobbs ssb 4096R/AC392911 2013-05-08

Die ID teilen sich öffentlicher und privater Schlüssel, daher taucht sie in Signatur- und Verschlüsselungskontexten auf. Sie muss mit einigen anderen Parametern in der Einstellungsdatei .muttrc abgelegt werden:

# Global crypto options set crypt_autosign = yes set crypt_replyencrypt = yes set crypt_replysign = yes set crypt_replysignencrypted = yes set crypt_verify_sig = yes # PGP crypto options set pgp_sign_as=FC382382 # <- Key ID! set pgp_decode_command="gpg --status-fd=2 %?p?--passphrase-fd 0? --no-verbose --quiet --batch --output - %f" set pgp_verify_command="gpg --status-fd=2 --no-verbose --quiet --batch --output - --verify %s %f" set pgp_decrypt_command="gpg --status-fd=2 %?p?--passphrase-fd 0? --no-verbose --quiet --batch --output - %f" set pgp_sign_command="gpg --no-verbose --batch --quiet --output - %?p?--passphrase-fd 0? --armor --detach-sign --textmode %?a?-u %a? %f" set pgp_clearsign_command="gpg --no-verbose --batch --quiet --output - %?p?--passphrase-fd 0? --armor --textmode --clearsign %?a?-u %a? %f" set pgp_encrypt_only_command="pgpewrap gpg --batch --quiet --no-verbose --output - --encrypt --textmode --armor --always-trust -- -r %r -- %f" set pgp_encrypt_sign_command="pgpewrap gpg %?p?--passphrase-fd 0? --batch --quiet --no-verbose --textmode --output - --encrypt --sign %?a?-u %a? --armor --always-trust -- -r %r -- %f" set pgp_import_command="gpg --no-verbose --import %f" set pgp_export_command="gpg --no-verbose --export --armor %r" set pgp_verify_key_command="gpg --verbose --batch --fingerprint --check-sigs %r" set pgp_list_pubring_command="gpg --no-verbose --batch --quiet --with-colons --list-keys %r" set pgp_list_secring_command="gpg --no-verbose --batch --quiet --with-colons --list-secret-keys %r" set pgp_good_sign="^\\[GNUPG:\\] GOODSIG"

Die nicht sehr eleganten Kommandos (wobei die schlimmsten Verrenkungen im Wrapper pgpewrap verborgen sind) zur Interaktion mit gpg stammen aus der Vorlage share/docs/mutt/samples/gpg.rc und funktionieren nur dann mit GnuPG 2.x, wenn man einen passenden Symlink erstellt:

sudo ln -s /usr/local/bin/gpg2 /usr/local/bin/gpg

Um sicherzustellen, dass man verschlüsselte E-Mails an Bob oder Alice später selbst noch lesen kann, sollte die eigene Schlüssel-ID auch in .gnupg/gpg.conf erscheinen:

encrypt-to FC382382

Aber: BEWARE of the security implications this has. Basically you're adding another vulnerability to the encrypted message. If your or the recipient's key is compromised an attacker can read the message.

Der naheliegende Gedanke, dass diese Konfiguration nach einem API verlangt, ist der erste Schritt in ein Verhängnis namens GPGME. Doch dazu später. Dank hilfreicher Anleitungen funktioniert der Austausch signierter Mails mit mutt und GnuPG erstaunlich gut. Der einzige Nachteil ist mein minimalistisches Web of Trust – nur ein einziger Kollege aus dem nächstgelegenen Rechenzentrum nutzt OpenPGP, so dass mein schicker 4096-bit-Schlüssel kaum Signaturen sammeln kann (und alle anderen sich wahrscheinlich fragen, was der seltsame Anhang mit dem MIME-Typ application/pgp-signature in meinen Mails bedeuten soll. Ich warte auf den ersten Hinweis, dass ich mir wohl einen Virus eingefangen hätte.).

Außerdem unterstützt Apple GnuPG nicht nur nicht, sondern sabotiert sogar das bestehende Portierungsprojekt, indem es die relevanten Spezifikationen des eigenen Mail-Clients regelmäßig ändert. Weil meine wichtigsten Gesprächspartner Apple Mail verwenden, wäre es halsstarrig, in dieser Situation ausschließlich auf OpenPGP zu setzen.