DKIM steht für DomainKeys Identified Mail und ist ein Verfahren zur Authentifizierung von E-Mails.

Es hilft, die Integrität und Authentizität von E-Mails zu bestätigen. Dabei wird eine digitale Signatur in den Header einer ausgehenden E-Mail eingefügt, die vom Empfänger überprüft werden kann, um sicherzustellen, dass die Nachricht während der Übertragung nicht manipuliert wurde und tatsächlich vom Absender stammt.

Wie funktioniert DKIM?

DKIM verwendet ein Schlüsselpaar aus privatem und öffentlichem Schlüssel, um E-Mails zu verifizieren.

Der private Schlüssel ist auf dem Mailserver des Absenders gespeichert, er dient dazu, ausgehende E-Mails zu signieren.

Der öffentliche Schlüssel wird als TXT-Eintrag im DNS der absendenden Domain gespeichert: Der absendende E-Mail-Dienst berechnet aus dem Inhalt jeder ausgehenden E-Mail die DKIM-Signatur, die auf Basis des Inhalts der Nachricht und des privaten Schlüssels erstellt wird. Diese Signatur wird im E-Mail-Header gespeichert.

Der empfangende E-Mail-Dienst sucht den öffentlichen Schlüssel im DKIM-DNS-Datensatz des Absenders und vergleicht diesen mit der Signatur in der Nachricht. Wenn beide übereinstimmen, gilt die Nachricht als authentisch.

Das bedeutet, dass die E-Mail von dem Absender stammt, von dem sie angeblich stammt, und dass sie während der Übertragung nicht verändert wurde.

Die meisten E-Mail-Dienste führen die DKIM-Prüfung bei eingehenden E-Mails automatisch durch, aber Sie sollten überprüfen, ob sie aktiviert ist.

Sie benötigen für jeden E-Mail-Server, von dem aus Sie E-Mails versenden, einen eigenen DKIM-Schlüssel und einen eigenen DNS-Eintrag. Neben Ihren eigenen E-Mail-Servern müssen Sie möglicherweise auch Anwendungen und Dienste von Drittanbietern berücksichtigen, die E-Mails in Ihrem Namen versenden.

 

 

Der Vorteil von DKIM:

Empfänger können nun prüfen, ob die Signatur der eingehenden E-Mail gültig ist.
Ist das der Fall, ist sichergestellt, dass:

1. Der Versender den privaten Schlüssel besitzt
2. Der Versender Zugriff auf das DNS der signierenden Domain besitzt
3. Der Inhalt der empfangenen E-Mail (zumindest der signierten Teile) auf dem Transportweg von keinem weiterleitenden Mailserver verändert wurde

Wird aligned signiert, sprich die Domain im From:-Header der E-Mail und die DKIM-Domain gehören zu derselben Organisational Domain, können wir somit sicherstellen, dass der Absender der E-Mail auch tatsächlich vom Domainbesitzer zum Versenden berechtigt wurde.

So kann nicht nur die Integrität, sondern auch die Authentizität festgestellt werden.

Der öffentliche Teil des Schlüssels (Public Key) wird im DNS der signierenden Domain hinterlegt. Dazu ist ein Selektor notwendig.

So sieht ein DKIM Key im DNS aus:
SELECTOR._domainkey.DOMAIN.TLD TXT „v=DKIM1; k=rsa; p=PUBLIC_KEY“

Somit ist es möglich, in einer Domain mehrere DKIM Keys – mittels unterschiedlichen Selektoren – zu setzen. Empfohlen wird auch, Keys und Selektoren regelmäßig zu rotieren und – für größere Organisationen – unterschiedliche Key/Selektor Paare für unterschiedliche Einsatzzwecke zu verwenden.

Es wird empfohlen, mit der Versanddomain im FROM:-Header ebenfalls DKIM zu signieren (aligned), da dies ein Erfordernis von DMARC ist.

Abgesehen von v- (Version) k- (Verschlüsselungstyp) und p-Parameter (Key), gibt es noch weitere Parameter, die man setzen kann. Derzeit gibt es nur die Version „DKIM1“. Neben RSA kann man auch ED25519 für die Verschlüsselung verwenden. In der Realität ist ED25519 allerdings praktisch nicht verbreitet, so dass die Implementierung zwar technisch möglich ist, aber in der Praxis keine Alternative darstellt.
Auf https://dkim.org/ finden Sie weitere Details zur Implementierung von DKIM.

 

 

 

Wie sieht ein DKIM-Signatursatz aus:

 

v= Dieses Tag gibt die DKIM-Version an. Hier ist v=1 die einzig aktuelle.

a= Dies ist der Verschlüsselungsalgorithmus, mit dem der Hashwert erzeugt wird. In der Regel ist dies entweder rsa-sha oder rsa-sha256. Es sind auch andere Algorithmen möglich, die jedoch nicht immer unterstützt werden.

q=dns/txt – Derzeit ist dns/txt die einzige unterstützte Methode, aber andere Methoden können zu einem späteren Zeitpunkt hinzugefügt werden. Es muss nicht vorhanden sein und ist standardmäßig auf „dns/txt“ eingestellt.

c= Gibt den Kanonisierungsalgorithmus an, der jeweils für den Header und den Body der E-Mail festgelegt werden. Diese beiden Werte können unabhängig voneinander für den Header und den Body kombiniert werden, um den gewünschten Grad an Toleranz gegenüber kleinen Änderungen festzulegen. Wird dieses Tag weggelassen, wird eine entspannte (reklaxed) Kanonisierung angenommen.

Fall 1: Simple

• Header und Body müssen exakt so beim Empfänger ankommen, wie sie vom Absender verschickt wurden.
• Jede kleine Änderung im Text, wie z. B. zusätzliche Leerzeichen oder Zeilenumbrüche, führt dazu, dass die Signatur ungültig wird

Fall2: relaxed

• Header: Kleinere Unterschiede wie Groß- und Kleinschreibung werden ignoriert, und zusätzliche Leerzeichen werden reduziert.
• Body: Leerzeilen am Ende werden ignoriert, und mehrere Leerzeichen hintereinander werden als ein einzelnes Leerzeichen behandelt.

d= Gibt an, welcher Domänenname bei der Erstellung von Signaturen für Nachrichten, die von diesem Server gesendet werden, verwendet werden soll.

s= Das „s“-Tag ist der Selektorstring, der von einem empfangenden Server verwendet wird, um zu bestimmen, welcher öffentliche Schlüssel zur Überprüfung der Signatur verwendet werden soll.
In unserem Beispiel ist der öffentliche Schlüssel in mail1._domainkey.example.com gespeichert.

Das „h“-Tag enthält eine durch Doppelpunkte getrennte Liste der Kopfzeilen, die beim Signieren der Nachrichtenkopfzeilen enthalten sind. Änderungen an diesen Kopfzeilen während der Übermittlung der Nachricht führen dazu, dass die DKIM-Authentifizierung fehlschlägt.

 

Signieren beliebiger Headerfelder

Angenommen, es sind normalerweise nur die from, to, subject und date Header in die Signatur einbezogen. Ein Header könnte auch zusätzliche Felder wie cc, reply-to und message-id umfassen:

 

Hier werden cc, reply-to und message-id ebenfalls in die Signatur einbezogen, wodurch es für einen Angreifer schwieriger wird, die E-Mail zu manipulieren, ohne die DKIM-Signatur ungültig zu machen.

 

Oversigning und Beispiel für einen „Oversigned“ Header

 

Oversigning bedeutet, dass mehre E-Mail-Header in die DKIM-Signatur einbezogen werden als notwendig oder üblich. Dies kann eine zusätzliche Sicherheitsschicht bieten, da es das Risiko verringert, dass ein Angreifer bestimmte Header manipuliert, ohne die DKIM-Signatur ungültig zu machen.

 

DKIM-Oversigning funktioniert folgendermaßen.

Der (ausgehende) Mailserver ist für die Verwendung von DKIM konfiguriert. Er hat also einen privaten Schlüssel (in Verbindung mit dem öffentlichen Schlüssel, der im DNS veröffentlicht ist). Außerdem muss er so konfiguriert sein, dass er die zu signierenden Felder angibt. Zum Beispiel kann der Server so konfiguriert werden, nur die Felder „From“, „To“, „Date“ und „Subject“ zu signieren.

In diesem Fall sieht der Empfänger (Benutzer) in den Eigenschaften der E-Mail, dass der DKIM-Header „h=From:To:Date:Subject;“ beinhaltet.

Wenn jedoch ein Angreifer bei einer Man-in-the-Middle-Attacke einen weiteren „From“-Header einfügt, kann dieser unbemerkt bleiben (d.h. er ist nicht Teil der mit der DKIM-Signatur signierten E-Mail).

Wenn Sie nun Oversigning verwenden, kann der Mailserver-Administrator die Konfiguration des Mailservers ändern und z.B. „h=From:From:To:Date:Subject;“ angeben.

Dieses doppelte „From:“ sieht seltsam aus, bedeutet aber, dass für „legitime“ Mails ein expliziter „leerer zweiter Von“-Header Teil der DKIM-Signatur ist. Wenn ein Angreifer nun versucht, einen weiteren „From“-Header einzufügen, wird die DKIM-Signatur „gebrochen“ (d.h. der Validator am Empfangsort erhält eine andere DKIM-Signatur und hat somit eine fehlerhafte DKIM-Signatur).

Beim Oversigning werden also kritische Header wie „From“ oder „To“ mehrfach signiert, damit ein Angreifer nicht einfach einen zweiten dieser Header hinzufügen kann

 

Zusammengefasst:

 

DKIM sorgt dafür, dass E-Mail-Empfänger erkennen können, ob eine Nachricht tatsächlich vom behaupteten Absender stammt und unverändert übertragen wurde. Es ist damit ein wichtiges Werkzeug zur Erhöhung der Sicherheit und Vertrauenswürdigkeit in der E-Mail-Kommunikation und schützt vor Angriffen wie Spoofing und Phishing.
Es muss jedoch darauf hingewiesen werden, dass DKIM zwar einen Verifizierungsmechanismus bietet, aber nicht ausreicht, um vor betrügerischen E-Mail-Angriffen wie Spoofing und Phishing zu schützen. Hierzu muss zwingend eine DMARC-Richtlinie zur Verwerfung vorliegen.

 

 

Anhang: DKIM – Tags

DKIM verwendet verschiedene Tags in der DKIM-Signatur im E-Mail-Header, um die Signatur und deren Eigenschaften festzulegen. Hier sind die wichtigsten DKIM-Tags und ihre Funktionen:

Wichtige DKIM-Tags

1. v=
2. • Beschreibung: Version des DKIM-Protokolls.
   • Typischer Wert: v=1 (derzeit die einzige gültige Version).
3. a=
   • Beschreibung: Gibt den Algorithmus zur Signaturerstellung an.
   • Typische Werte: rsa-sha256 (empfohlen und am häufigsten verwendet) oder rsa-sha1 (veraltet).
4. d=
   • Beschreibung: Die Domain, die die E-Mail signiert und als authentifizierter Absender gilt.
   • Beispiel: d=example.com.
5. s=
   • Beschreibung: Der Selector, der auf den öffentlichen Schlüssel im DNS verweist.
   • Beispiel: s=selector1.
6. c=
   • Beschreibung: Canonicalization-Methode für Header und Body, um kleine Änderungen zu tolerieren.
   • Typische Werte: c=relaxed/simple, c=simple/simple, c=relaxed/relaxed.
7. h=
   • Beschreibung: Gibt die Header-Felder an, die in die Signatur aufgenommen werden.
   • Beispiel: h=from:to:subject:date.
8. bh=
   • Beschreibung: Der Hash-Wert des Body-Inhalts der E-Mail (Body-Hash), berechnet vor der Signatur.
   • Beispiel: bh=abc123def… (eine Hash-Zeichenfolge, die überprüft, ob der Body unverändert ist).
9. b=
   • Beschreibung: Die eigentliche Signatur der E-Mail, die auf Basis des Header-Inhalts und des privaten Schlüssels generiert wurde.
   • Beispiel: b=DEF456GH… (eine Base64-kodierte Signaturzeichenfolge).

Weitere optionale DKIM-Tags

1. t=
   • Beschreibung: Zeitstempel der Signatur, in Sekunden seit dem 1. Januar 1970 (UNIX-Epoche).
   • Beispiel: t=1616593200.
2. x=
   • Beschreibung: Ablaufzeitpunkt der Signatur, angegeben in Sekunden seit der UNIX-Epoche.
   • Beispiel: x=1616689600.
3. i=
   • Beschreibung: Die Identität der signierenden E-Mail-Adresse (Subdomain und Domain), falls abweichend von d=.
   • Beispiel: i=user@example.com.
4. l=
   • Beschreibung: Die Länge des signierten Body-Inhalts in Bytes.
   • Beispiel: l=2000.
5. z=
   • Beschreibung: Eine optionale Liste der signierten Header-Felder und deren Werte, um Debugging zu erleichtern.
   • Beispiel: z=From:example@example.com|To:recipient@example.com|….

Zusammenfassung

Die wichtigsten Tags sind v, a, d, s, c, h, bh, und b, da sie die grundlegende Authentifizierung und Verifizierung der E-Mail ermöglichen. Optionalen Tags wie t, x, und i bieten zusätzliche Funktionen wie Ablaufkontrolle und eine erweiterte Verifizierung der E-Mail-Identität.