WKD einrichten und nutzen

Vorspiel: warum wir unsere Emails verschlüsseln müssen

Emails gehören verschlüsselt. PUNKT. Nicht nur der Transportweg, sondern die gesamte Email. Es wird immer deutlicher und wichtiger für uns Menschen, dass wir unsere Daten (und dazu gehört besonders unsere Kommunikation) gegen Augen dritter absichern. Ich meine nicht den neugierigen Partner im eigenen Haus (wer vor dem etwas verheimlicht hat ganz andere Probleme!). Ich meine vor den großen Email-Anbietern, staatlichen Akteuren und allen dritten Parteien. Es geht niemanden etwas an, was ich mit wem schreibe und was da drin steht. Das macht mich in gewisser Weise zu einem Terroristen, ja, ist aber mein Grundrecht: Ich habe ein Recht auf den Schutz meiner Privatspähre. Wenn wir diesen Schutz aufgeben, weil wir “nichts zu verbergen” haben, geben wir ein Stück unserer Freiheit und Selbstbestimmung auf. In der heutigen digitalen Welt sind Daten Gold. Wortwörtlich. Unternehmen und Regierungen sammeln Daten und analysieren, suchen Muster, trainieren ihre Software, manipulieren uns gezielt. All diese Daten können aktiv gegen jeden einzelnen Menschen genutzt werden. Selbst wenn heute vielleicht keine bösen Absichten bei der Sammlung bestehen, kann sich das in Zukunft ändern. Einmal gesammelte Daten können von bösen Menschen (und die gibt es!) für Zwecke missbraucht werden, die wir heute vielleicht noch gar nicht absehen oder abschätzen können. Was heute harmlos erscheint, könnte morgen als höchst verdächtig eingestuft werden. Dagegen müssen wir uns wehren. Heute schon. Jetzt. Eine umfasende Überwachung, die durch das Fehlen von Verschlüsselung ermöglicht wird, kann zu einem schleichenden Verlust unserer bürgerlichen Freiheiten führen. Dagegen gehe ich aktiv vor.

targets

Die Sache mit dem öffentlichen Schlüssel

Ich nutze sehr gerne Verschlüsselungsverfahren für meine Emails. GnuPG hat sich da einfach bewährt. Man generiert einen öffentlichen und einen privaten Schlüssel, trötet seinen öffentlichen Schlüssel einfach überall hinaus und die Menschen da draußen nutzen den öffentlichen Schlüssel, um Nachrichten an mich zu verschlüseln. Mit einem kryptografischen Umkehrverfahren kann ich dann mit meinem privaten Schlüssel die Email wieder entschlüsseln. Perfekt. Auf dem Transportweg kann niemand mitlesen. Kein Betreiber eines Mailservers (BETREIBT EURE EIGENEN!), kein Staat, kein Nachbar, niemand. Es gab nur immer einen Haken mit den öffentlichen Schlüsseln: wie kommt man an diese heran? Soll mir jemand per Klartext schreiben, dass er gerne meinen privaten Schlüssel haben möchte? Das wäre sehr auffällig. Es wäre quasi so, als ob sich 2 Agenten heimlich im Stadtpark treffen, um dort die geheime Passphrase für ihre geheime Kommunikation auszutauschen. Unschön. Die Lösungsansätze für dieses Problem waren vielschichtig. Viele Menschen im Netz haben ihre Schlüssel auf ihre Website gepackt und in irgendeiner Form angeboten. Meisten in einem aboutme oder contact oder impressum. Man musste sich die Schlüssel dort händisch kopieren, im eigenen System einfügen und Emails damit verschlüsseln… Hoher Aufwand, es können Fehler passieren, der Mensch dem ich schreiben mag muss eine website haben und dort den Schlüssel veröffentlichen… Blöd. Gangbar, aber blöd. Die Alternative, die sich daraus entwickelt hat, sind Schlüsselserver. Es gibt da ein paar bekannte, große, zuverlässige Schlüsselserver, namentlich erwähnt seien keys.openpgp.org, pgp.mit.edu, keyserver.ubuntu.com, keys.gnupg.net oder keys.mailvelope.com. Auf diesen Servern kann jeder Mensch der mag seine Email-Adresse und einen passenden PGP-/OpenPGP-Schlüssel veröffentlichen. Dies hat den Vorteil, dass ich nur den Adressaten kennen muss und direkt mit ihm schreiben verschlüsselt schreiben kann, sofern derjenige seinen Schlüssel dort veröffentlicht hat. Nachteil ist, dass quasi jeder dort Schlüssel veröffentlichen kann und dort ein Haufen falscher Schlüssel unterwegs sind und man bei manchen Email-Adressen gar nicht sagen kann, welcher Schlüssel nun der richtige ist(sogenanntes “key flooding”). Abhilfe hat hier die Validierung von keys.openpgp.org geschaffen. Email-Adressen müssen dort verifiziert werden. Ist aber immer noch eine unschöne Art. Warum? Angenommen du möchtest mir eine verschlüsselte und vertrauliche Email schreiben. Du müsstest erst zu einer dritten Partei gehen und dich dort bekennen à la “ich möchte gerne mit leisefuxX kommunizieren”. Auch unschön.

Die Lösung: WKD - Web Key Directory

WKD ist ein fundamental anderer Ansatz zum verteilen von öffentlichen Schlüsseln. Die Kernidee ist eine Dezentralisierung der Schlüsselverteilung hin zum Domaininhaber. Anstatt den oder die öffentlichen Schlüssel zu einem Keyserver hochzuladen, liegt der oder die auf dem Webserver der Domain, die zu dieser Email-Adresse gehört. An meinem Beispiel wäre das zum Beispiel fuxx.space. Dazu wird von dem Mail-Client (oder einem anderen beliebigen Programm) ein standardisiertes URL abgefragt, sobald meine Email-Adresse abgefragt wird. Ich muss als Benutzer also nichts weiter machen. Ich möchte mail@example.com eine Email schreiben, trage die Adresse in das Adressfeld meines Mail-Clients ein und dieser schaut automatisch auf example.com/WKD_URL nach dem entsprechenden öffentlichen Schlüssel zu der angegebenen Email. Findet er einen, bietet er es dem User direkt an zu nutzen. Das macht es so einfach und so schön, dass es einfach bitte jeder Admin nutzen und einrichten möge und ich möchte hiermit eine kleine Anleitung geben, was wer wie und wo genau gemacht werden muss.

der WKD-Pfad auf dem Webserver

als Beispiel nehmen wir meine fuxx.space Adresse und den Benutzer leise.

https://DOMAIN/.well-known/openpgpkey/hu/HASH-WERT-Email-Prefix
ergibt ein
https://fuxx.space/.well-known/openpgpkey/hu/n4ykgn3ykoxozhd3e3f5ezeenxixa5m4

aber wie komme ich an den Pfad?

Ordnerstruktur erstellen

Beginnen wir mit dem Ordnerpfad, in welchem der öffentliche Schlüssel abgelegt wird. Diesen erstellen wir im Stammverzeichnisses unseres webservers. Bei nginx wäre das zum Beipsiel

mkdir -p /var/www/html/.well-known/openpgpkey/hu

das huin der Domain steht übrigens für hashed-userid. Anschließend muss noch eine Datei erstellt werden, die den WKD-Clients mitteilt, dass WKD grundsätzlich angeboten wird. Diese kann leer sein und es reicht sie einfach nur zu berühren:

touch /var/www/html/.well-known/openpgpkey/policy

Das war es im wesentlichen auch schon mit der Grundstruktur. Die öffentlichen Schlüssel der Userpräfixe können jetzt bereitgestellt werden.

DNS anpassen / TXT-Eintrag im DNS hinterlegen

Der nachfolgende Schritt ist nur notwendig, wenn die Domain openpgpkey.eureDomain.de aufgelöst wird. Dann solltet ihr wie nachfolgend beschrieben einen (leeren) TXT-Record anlegen. Alternativ könnt ihr auch ein gültiges TLS-Zertifikat für die Subdomain openpgpkey.eureDomain.de ausliefern und einen Redirect auf eure Schlüssel-URI vornehmen. Das Anlegen eines TXT-Records ist etwas einfacher.

Die Implementierung von WKD unterscheidet zwischen einer Advanced- und Direct-Methode zur Abfrage der Schlüssel-URI. Bei der Advanced-Methode wird der öffentliche Schlüssel unter der Subdomain https://openpgpkey.fuxx.space gesucht. Diese Subdomain habe ich allerdings nicht eingerichtet, sondern verwende die Direct-Methode. Da die Domain https://openpgpkey.fuxx.space bei mir jedoch aufgelöst wird bzw. erreichbar ist, muss zusätzlich ein TXT-Record im DNS hinterlegt werden, damit Clients den öffentlichen Schlüssel von der URL https://fuxx.space/.well-known/openpgpkey/hu/n4ykgn3ykoxozhd3e3f5ezeenxixa5m4 beziehen können bzw. überhaupt dort danach suchen. Standardmäßig werden Clients zunächst versuchen, den öffentlichen Schlüssel über die Advanced-Methode zu beziehen, also von openpgpkey.eureDomain.de. Durch das Anlegen des TXT-Records unterbindet man praktisch, dass der DNS-Server einen A-Record oder CNAME zurückliefert und unser Webserver die Anfrage anschließend entgegennimmt – das möchten wir vermeiden.

Begebt euch daher in die DNS-Einstellungen eures Hosting-Anbieters und legt dort einen DNS-Eintrag an.

  • Host: openpgpkey
  • Type: TXT
  • Inhalt: beliebig (ich nehme “empty”) Beim Feld Inhalt muss ein beliebiger Eintrag erfolgen – es ist nicht möglich einen leeren TXT-Record anzulegen. Ich verwende daher einfach die Bezeichnung bzw. Eintrag empty.n Anschließend könnt ihr den TXT-Record ausgeben lassen – je nach DNS-Server wird dies etwas dauern:
host -t txt openpgpkey.fuxx.space

Die Rückgabe bei mir lautet hier:

openpgpkey.fuxx.space descriptive text "empty"

Webserver anpassen

Ich habe mal 3 Codesnippets für die gängigen Webserver zusammengeklöppelt. Im Wesentlichen müssen 2 Dinge erfüllt sein:

  1. der Stream muss als octet-stream kommen
  2. der Header “Access-Control-Allow-Origin” muss auf beliebig, also “*” stehen.

nginx:

## WEB KEY DIRECTORY ##
location ^~ /.well-known/openpgpkey {
   default_type application/octet-stream;   
   add_header Access-Control-Allow-Origin * always;
}

Apache:

## WEB KEY DIRECTORY ##
<Directory "/.well-known/openpgpkey">
   <IfModule mod_mime.c>
      ForceType application/octet-stream
      Header always set Access-Control-Allow-Origin "*"
   </IfModule>
</Directory>

Caddy:

your.domain {
   root * /var/www/your_web_folder
   file_server
   header /.well-known/openpgpkey/* Access-Control-Allow-Origin *
   header /.well-known/openpgpkey/* Content-Type application/octet-stream
   [...]
}

Hashwerte der Email-Präfixe auslesen und WKD-Datei erstellen

Woher bekommt man in dem Unterordner hu denn jetzt den Dateinamen und den Inhalt für die öffentliche Schlüsseldatei? Dies machen wir mit gpg direkt. Ich kann mir mit dem Befehl gpg --with-wkd-hash --fingerprint leise@fuxx.space die Fingerprints meiner Schlüssel ausgeben lassen. Bei mir sieht dies exemplarisch so aus:

❯ gpg --with-wkd-hash --fingerprint leise@fuxx.space

pub   ed25519 2025-06-13 [SC]
      AA12 BA30 1FDD BF71 692F  B656 309D 21E6 1B52 BC1A
uid        [ unbekannt ] leisefuxX <leise@fuxx.space>
           n4ykgn3ykoxozhd3e3f5ezeenxixa5m4@fuxx.space
sub   cv25519 2025-06-13 [E]

in der vorletzten Zeile sehen wir den Fingerprint für das Email-Präfix n4ykgn3ykoxozhd3e3f5ezeenxixa5m4ist das Präfix für die leise@fuxx.space-Adrese. Um die WKD-Datei zu erstellen, reicht ein einfaches gpg --no-armor --export leise@fuxx.space > n4ykgn3ykoxozhd3e3f5ezeenxixa5m4 und ich habe eine binärdatei mit dem passenden Namen. Diese Datei lade ich jetzt mit sftp oder irgendeinem anderen Programm auf meinen webserver im webordner https://fuxx.space/.well-known/openpgpkey/hu/ (was bei meinem nginx im dateisystem dem ordner /var/www/html/.well-known/openpgpkey/huentspricht) und fertig. Insgesamt ergibt sich darau dann folgende Struktur

.well-known/
└── openpgpkey
    ├── hu
    │   └── n4ykgn3ykoxozhd3e3f5ezeenxixa5m4
    └── policy

Testen der WKD-Schlüsselerkennung

Mit dem folgenden Befehl wird GnuPG angewiesen, den öffentlichen Schlüssel via WKD zu beziehen – sogar dann, wenn er lokal bereits im GnuPG-Keyring vorhanden ist:

gpg -v --auto-key-locate clear,wkd,nodefault --locate-key leise@fuxx.space

Die Ausgabe verrät mir, dass alles cool ist und geklappt hat:

gpg: enabled compatibility flags:
gpg: verwende Vertrauensmodell pgp
gpg: pub  ed25519/309D21E61B52BC1A 2025-06-13  leisefuxX <leise@fuxx.space>
gpg: Schlüssel 309D21E61B52BC1A: "leisefuxX <leise@fuxx.space>" nicht geändert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg:                             unverändert: 1
gpg: auto-key-locate found fingerprint AA12BA301FDDBF71692FB656309D21E61B52BC1A
gpg: `leise@fuxx.space' automatisch via WKD geholt
pub   ed25519 2025-06-13 [SC]
      AA12BA301FDDBF71692FB656309D21E61B52BC1A
uid        [ unbekannt ] leisefuxX <leise@fuxx.space>
sub   cv25519 2025-06-13 [E]

Prima! Der Import via WKD hat funktioniert. Alternativ könnte man auch mit einem der verfügbaren WKD-Checker hier oder hier schauen, ob die Auflösung klappt.

targets

mein Fazit

Das Auffinden von Schlüsseln via WKD ist einfach, elegant und praktisch gelöst – die Einrichtung ist fix erledigt. Jeder, der verschlüsselte E-Mails via PGP bzw. GnuPG austauscht und eine eigene Domain besitzt, sollte WKD einrichten. Damit macht ihr es eurem Gegenüber so einfach wie möglich, mit euch eine sichere Kommunikation aufzubauen. Clients wie Thunderbird/Enigmail prüfen noch während des Verfassens der E-Mail, ob ein Schlüssel via WKD beziehbar ist. Sofern dies zutrifft, wird die E-Mail auf Wunsch bzw. je nach Einstellung ohne manuellen Eingriff direkt mit dem korrekten Schlüssel verschlüsselt. Fake-Keys gehören damit der Vergangenheit an.

EINRICHTEN! JETZT! LOS!

P.S.: hier steht meine Email im Klartext… ihr könnt sie gerne nehmen und mir eine verschlüsselte Email schreiben. (: Von Spam bitte ich abzusehen <3 euer fuxX

Mehr Informationen

Eigentlich wollte ich nur OpenPGP in meinem K9 einrichten und bin dabei über diesen Artikel hier gestolpert. Habe mich dann ein bisschen weiter eingelesen und das ganze mal eben umgesetzt (: