Das Symptom
Jemand hat sich vorgenommen, seine E-Mails endlich zu verschlüsseln. Nach einer
Stunde steht ein Schlüsselpaar, nach zwei Stunden ist die erste verschlüsselte
Mail unterwegs – und beim Empfänger kommt ein Anhang an, den sein Programm nicht
öffnen kann. Oder umgekehrt: Der Kollege aus der Firma schickt etwas
Verschlüsseltes, und das eigene Programm zuckt nicht einmal. Beide haben alles
richtig gemacht, und trotzdem funktioniert nichts.
Die „Layer 8“-Wahrheit
Der Grund ist so banal wie hartnäckig: Es gibt nicht ein Verfahren für
verschlüsselte Mail, sondern zwei, und sie kennen einander nicht. S/MIME und
OpenPGP lösen dieselbe Aufgabe mit denselben mathematischen Bausteinen, aber sie
verpacken das Ergebnis unterschiedlich und beantworten die entscheidende Frage
unterschiedlich – nämlich woher man weiß, dass ein Schlüssel wirklich der Person
gehört, an die man schreibt. S/MIME beantwortet sie hierarchisch: Eine
Zertifizierungsstelle bürgt, die Kette lässt sich bis zu einem Wurzelzertifikat
prüfen. OpenPGP beantwortet sie flach: Man vertraut Schlüsseln, die man selbst
oder jemand, dem man vertraut, geprüft hat. Das BSI stellt beides nebeneinander
und zieht den Schluss, der die meiste Frustration erklärt – sie sind nicht
kompatibel miteinander.
Man sieht es sogar im Rohtext der Nachricht. S/MIME steckt seinen Inhalt laut
RFC 8551 in application/pkcs7-mime, PGP/MIME laut RFC 3156 in
multipart/encrypted mit dem Protokoll application/pgp-encrypted. Für ein
Programm, das nur eines davon kennt, ist das andere ein Anhang wie jeder andere:
vorhanden, unlesbar, unerklärt. Es ist also kein Fehler, sondern ein
Missverständnis mit Dateiendung.
Die zweite Hälfte der Wahrheit ist unbequemer. Verschlüsselte Mail ist die eine
Schutzmaßnahme, die man nicht allein einführen kann – sie braucht immer jemanden
am anderen Ende, der dasselbe getan hat. Genau daran scheitert sie seit
Jahrzehnten, und das BSI sagt es erfreulich unbeschönigt:
Ende-zu-Ende-Verschlüsselung wird bisher nur sehr selten eingesetzt, unter
anderem weil die meisten verbreiteten Mail-Programme sie gar nicht anbieten. Das
ist kein Versagen der Kryptografie. Die Spezifikation reicht in ihrer eigenen
Ahnenreihe weit zurück – RFC 9580 beschreibt sich als Revision von RFC 4880, das
seinerseits RFC 2440 revidierte, welches RFC 1991 ersetzte. Nicht die Technik
fehlte all die Jahre. Es fehlte die Verabredung.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.Zuerst klären, was die Gegenseite überhaupt kann
Verschlüsselte Mail lässt sich als Einzige der gängigen Schutzmaßnahmen nicht allein einrichten. Beide Seiten brauchen dasselbe Verfahren und den öffentlichen Schlüssel der jeweils anderen. Der ehrlichste erste Schritt ist deshalb eine unverschlüsselte Frage: Kannst du S/MIME oder OpenPGP, und wenn ja, welches. Alles davor ist Vorarbeit ins Blaue.
2.Nachsehen, welches Verfahren das eigene Programm mitbringt
Manche Programme können beides von Haus aus, manche nur eines, manche nur mit Erweiterung. Unter Linux, macOS und Windows liegt für OpenPGP fast immer GnuPG zugrunde; ein Blick auf die Version zeigt, ob es überhaupt installiert ist. Für S/MIME gilt stattdessen: Es braucht ein persönliches Zertifikat, das eine Zertifizierungsstelle auf deine Adresse ausgestellt hat.
gpg --version
gpg --list-keys
3.Den eigenen öffentlichen Schlüssel exportieren und verschicken
Bei OpenPGP ist der öffentliche Schlüssel dazu da, verteilt zu werden – er ist kein Geheimnis. Der private Schlüssel bleibt, wo er ist. Der Export erzeugt einen Textblock, den man anhängen oder in eine Mail kopieren kann.
gpg --export --armor deine.adresse@example.com > publickey.asc
4.Den erhaltenen Schlüssel über einen zweiten Kanal prüfen
Der wichtigste Schritt ist der, den fast alle überspringen. Ein per Mail zugeschickter Schlüssel beweist nichts: Das BSI beschreibt genau den Fall, dass ein Angreifer diese Mail abfängt und den Schlüssel durch seinen eigenen ersetzt, woraufhin man unwissentlich für ihn verschlüsselt. Die Gegenmaßnahme ist unspektakulär und wirksam: den Fingerabdruck über einen anderen Kanal abgleichen, etwa am Telefon.
gpg --fingerprint deine.adresse@example.com
5.Den Unterschied selbst sichtbar machen
Dass die beiden Verfahren nicht ineinander passen, lässt sich in einer Minute vorführen statt zu glauben. Der erste Befehl erzeugt eine OpenPGP-verschlüsselte Datei mit Passphrase, der zweite lässt ein S/MIME-Werkzeug daran scheitern. Die Fehlermeldung ist kein Defekt, sondern die Antwort: Es ist schlicht ein anderes Format.
printf 'Testinhalt\n' > /tmp/probe.txt
gpg --batch --yes --passphrase 'Testpassphrase' --symmetric --armor --output /tmp/probe.asc /tmp/probe.txt
head -2 /tmp/probe.asc
openssl cms -cmsout -in /tmp/probe.asc -inform PEM
6.Signieren und Verschlüsseln nicht verwechseln
Eine Signatur macht eine Nachricht nicht vertraulich, sie macht sie überprüfbar. Das BSI trennt die Ziele sauber: Durch die Verschlüsselung der E-Mail wird die Vertraulichkeit gewährleistet, mit der Signatur ihre Integrität und ihre Authentizität. Wer nur signiert, hat einen offenen Brief mit Siegel – für jeden lesbar, aber nachweislich unverändert und nachweislich von dir.
7.Die Verabredung dokumentieren, sonst zerfällt sie
Verschlüsselte Mail scheitert selten an der Kryptografie und fast immer an der Organisation: ein neues Gerät ohne den privaten Schlüssel, ein abgelaufenes Zertifikat, ein Kollege mit dem anderen Verfahren. Es lohnt sich, einmal festzuhalten, welches Verfahren mit wem gilt, wo der private Schlüssel gesichert liegt und wann das Zertifikat ausläuft. Ein privater Schlüssel ohne Sicherung ist ein Datenverlust mit Terminvorbehalt.