E-Mails signieren mit DKIM
Seite 2: Sicherungskasten
Kopfsache
Um den Inhalt einer E-Mail (den Body) zu signieren, genügen der verschlüsselte Hash und ein Hinweis auf den Schlüssel. Doch DKIM sichert auch die Header gegen Manipulationen und soll möglichst flexibel einsetzbar sein, auch in mehrstufigen Mail-Systemen und bei E-Mail-Dienstleistern. Daher sind einige Zusatzinformationen erforderlich. Der Server fügt in die E-Mail einen zusätzlichen Header "DKIM-Signature" ein, an dem sich die Probleme und Prinzipien des Verfahrens zeigen. Er sieht beispielsweise so aus:
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple;
d=example.net; s=mail200801; i=dau@sub.example.net;
h=Date:From:To:Subject:Message-ID:References:Content-
Type:Content-Disposition:Content-Transfer-Encoding;
bh=8FBe8u6BvmKcvYyKlx+oYvPBSj4=; b=I+oWYOxFAk
...
Ajcxdz66BEmd8Mqs9lD2U=
Der Header besteht aus mehreren Feldern, die jeweils aus einem Buchstaben, gefolgt von einem Gleichheitszeichen und dem Wert bestehen. Hinter v= steht die benutzte Version des DKIM-Standards, die seit der Veröffentlichung des RFC "1" lauten sollte. Mit a= werden Hash- und Verschlüsselungsalgorithmus angegeben.
Hinter c= verbirgt sich die "Canonicalization": Auf dem Weg der Mail kann es passieren, dass Server die Mail anders umbrechen, die Großschreibung ändern und Leerzeichen einfügen oder löschen. Besonders bei den Headern ist das üblich, um sie leserlicher zu gestalten. Doch solche im Mail-Standard erlaubte Änderungen würden die Signatur entwerten. Wenn jedoch der Versender vor dem Signieren und der Empfänger vor dem Prüfen der Signatur die Nachricht auf die gleiche Weise umformatieren, bleibt die Unterschrift gültig. Hier bedeutet relaxed unter anderem, Umbrüche aus den Headern zu entfernen und mehrere Leerzeichen zu einem zusammenzuführen. Hingegen erlaubt strict keinerlei Änderungen. Die Empfehlung lautet, wie im Beispiel die Header relaxed zu behandeln und den Rest der Mail strict, was die beiden durch einen Schrägstrich getrennten Angaben bewirken.
Mit d= wird die Domain angegeben, mit deren Schlüssel die Nachricht signiert wurde. Das muss nicht unbedingt der im From:-Header angegebene Absenderadresse entsprechen, zum Beispiel wenn eine Mailingliste im Spiel ist. Zusätzlich gibt s= einen "Selektor" an, den Namen des Schlüssels. Der Versender legt seinen öffentlichen Schlüssel unter diesem Namen in der Subdomain _domainkey in seinem DNS-Server ab, und zwar als Eintrag vom Typ TXT. So kann jeder Empfänger den Schlüssel leicht abfragen und eine zusätzliche Infrastruktur zur Schlüsselverwaltung entfällt. Außerdem ist es nicht nötig, dass eine vertrauenswürdige Stelle die Echtheit des Schlüssels bestätigt, denn nur der Absender kann seinem DNS-Server einen Eintrag hinzufügen.
Der Schlüssel lässt sich auch auf der Kommandozeile mit dem Befehl nslookup -type=TXT mail200801._domainkey.example.net abfragen. Der zurückgelieferte TXT-Record ähnelt auf den ersten Blick der Signatur:
v=DKIM1; k=rsa;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC0N
...
lK5b7PeJHBv4MejV0G3hwIDAQAB
Die Felder enthalten die DKIM-Version (v=, optional), den Schlüsseltyp (k=, optional) und den Schlüssel selbst (p=). Durch unterschiedliche Selektoren kann eine Domain mehrere Schlüssel benutzen. Der RFC empfiehlt, den Schlüssel regelmäßig zu wechseln und den alten als ungültig zu kennzeichnen. Dazu lässt der Admin den TXT-Record in seinem DNS, löscht jedoch den eigentlichen Schlüssel, also den Teil hinter p=. Über eine Versionsnummer oder Datumsangabe im Selektor lässt sich dann leicht zwischen gültigen und widerrufenen Schlüsseln umschalten. Die Signatur umfasst den Körper der Mail und die Header, um beispielsweise sicherzustellen, dass sich kein Fälscher als Absender ins From: einträgt. Damit unterwegs eingefügte oder unwichtige Header die Signatur nicht stören, enthält der DKIM-Header eine Liste der signierten Felder (h=). Hier können auch Header stehen, die in der E-Mail gar nicht vorkamen, um zu verhindern, dass sie unterwegs eingefügt werden. Das Feld i= enthält die "Identity", für die signiert wurde. Das kann der komplette Absender sein oder auch die (Sub-)Domain, für die der signierende Server zuständig ist. Das Beispiel zeigt, dass die E-Mail-Adresse durchaus zu einer Subdomain der mit d= angegebenen Domain gehören darf. Im Header steht der Hash des Body (bh=), damit der Empfänger Veränderungen auch dann bemerken kann, wenn der öffentliche Schlüssel durch eine DNS-Störung nicht verfügbar ist oder widerrufen wurde. Am Ende steht dann mit b= die eigentliche Signatur.
Vertrauenssache
Eine korrekte DKIM-Signatur zeigt dem Empfänger, dass die Mail den Server passiert hat, auf dem der private Schlüssel liegt, der zu dem per DNS veröffentlichten passt. Doch bedeutet eine fehlende Signatur nur dann, dass die Nachricht gefälscht wurde, wenn der Absender ausnahmslos alle E-Mails signiert. Solche "Policy"-Informationen waren auch Bestandteil des Yahoo-Verfahrens DomainKeys, doch DKIM lagert sie in einen eigenen RFC aus, der noch nicht verabschiedet ist. Das Protokoll soll "Sender Signing Practices (SSP)" heißen und den Umgang mit nicht oder ungültig signierten Nachrichten regeln.
DKIM – auch ohne SSP – stellt sicher, dass die E-Mail aus der Domain des angegebenen Absenders stammt. Gegen Phishing mit prinzipbedingt gefälschten Absendern hilft das Verfahren sofort. Doch schon jetzt gibt es den ersten signierten Spam zum Beispiel von Yahoo- und Googlemail-Adressen. Eine korrekte Signatur allein reicht folglich nicht als Filterkriterium; der Postmaster muss zusätzlich einschätzen, ob aus einer per DKIM bestätigten Domain Spam zu erwarten ist. Damit befasst sich der Standard jedoch nicht, da es keine technische Frage ist, sondern eine des guten Rufs. Bekannte Absender kann der Admin dank DKIM am Spamfilter vorbeilassen, doch bislang fehlt es an Verfahren, um die Reputation eines unbekannten Senders zu berücksichtigen. Mit Karmasphere gibt es aber schon einen ersten Versuch, diese Information zu sammeln und maschinenlesbar zur Verfügung zu stellen.
