Wer wars wirklich? Absender-Authentifizierung durch DomainKeys Identified Mail (DKIM)

Ordnungsmerkmale

erschienen in: <kes> 2007^#6, Seite 74

Zusammenfassung: E-Mail-Absender sind einfach fälschbar – "persönliche" Signaturen jedoch äußerst aufwändig. DomainKeys Identified Mail (DKIM) will hier eine pragmatische Lösung zur Nachrichten-Authentifizierung schaffen.

Autor: Von Reiner Baumann, München

E-Mail-Absender sind mehr oder minder beliebig fälschbar, da die Einlieferung von Nachrichten per Simple Mail Transfer Protocol (SMTP) beim Empfänger(-Server) keine Authentifizierung vorsieht. Phishing-Mails mit "vertrauenswürdigen" Absenderadressen sind somit leicht zu erstellen. Einem Bericht der Anti-Phishing Working Group ( www.apwg.org) zufolge haben Kriminelle Mitte dieses Jahres 126 bekannte Unternehmensnamen für solche Zwecke missbraucht, 90 % dieser gefälschten Absendeadressen gehörten zu namhaften Finanzinstituten. Leider sind auch die Zeiten vorbei, in denen man Phishing-Mails und -Websites auf den ersten Blick an ihrer unprofessionellen Aufmachung erkannte: Oft steht in der Absenderzeile zweifelsfrei die "richtige" Adresse des Kreditinstituts und der enthaltene Link führt zu einer täuschend echten Kopie der Bank-Seiten.

Um eine stärkere Authentizität der E-Mail-Absender zu erreichen, ohne jeden Teilnehmer in eine globale Public-Key-Infrastruktur (PKI) aufnehmen zu müssen, kam die Idee einer Prüfung der Absender-Domain auf: Wenn Nachrichten über den zuständigen SMTP-Server eines Absenders laufen, bestätigt dieser das mittels digitaler Signatur – der Empfänger oder dessen Mail-Server können diese Tatsache dann überprüfen. Yahoo hatte hierfür das Verfahren der "Domain Keys" entworfen und gemeinsam mit Cisco im Juni 2005 "Domain Keys Identified Mail" (DKIM) bei der Internet Engineering Task Force (IETF) als Vorschlag für einen zukünftigen Standard eingereicht. DKIM besitzt in der Form des RFC 4871 vom Mai 2007 derzeit den Status eines Proposed Standard [1] – an dieser Version haben zudem auch PGP und Sendmail mitgewirkt.

Die Design-Kriterien von DKIM waren:

• Kompatibilität mit existierender E-Mail-Infrastruktur und größtmögliche Transparenz,
• minimale zusätzliche Infrastruktur,
• Implementierung (auch) unabhängig von E-Mail-Clients,
• Möglichkeit einer schrittweisen Verbreitung und
• Möglichkeit der Echtheitsbestätigung (auch) durch autorisierte Dritte sowie mit Mehrfachsignaturen (z. B. für Weiterleitungen durch Mailing-Listen).

Das DKIM-Prinzip ist einfach: Schickt ein Unternehmen seinen Kunden eine E-Mail, so signiert – in der Regel – der annehmende Message Transfer Agent (MTA, z. B. SMTP-Server) des Absenders ausgewählte E-Mail-Header und den Nachrichtentext mithilfe eines geheimen Schlüssels, sinnvollerweise nachdem er die Einlieferungs-Berechtigung und interne Policies geprüft hat. DKIM sieht zudem auch Möglichkeiten vor, entsprechende Signaturen auf Sub-Domain-Basis oder im einliefernden Mail-Client (Mail User Agent, MUA) zu erstellen.

Als Algorithmen sind RSA-SHA-256 (Default-Verfahren) und RSA-SHA-1 vorgesehen; dabei sind zumindest Schlüssellängen zwischen 512 und 2048 Bit zu unterstützen. Das Ergebnis landet als DKIM-Signatur-Header in der E-Mail – Anwender bekommen den Eintrag also normalerweise nicht zu Gesicht und auch Mail-Clients, die nicht mit DKIM umgehen können, werden nicht "verwirrt".

DomainKeys Identified Mail (DKIM) greift zur Schlüsselverwaltung auf das Domain Name System (DNS) zurück und kommt ohne aufwändige PKI aus.

DNS statt PKI

Der öffentliche Schlüssel zur Prüfung der DKIM-Signatur ist über einen Textrecord des Domain Name System (DNS) verfügbar und nicht an eine PKI gebunden – die Authentizität des Schlüssels basiert also ausschließlich auf dessen Verfügbarkeit über den entsprechenden DNS-Server. Der Mail-Server (oder -Client) des Empfängers entscheidet bei der Verifikation anhand der Versender-Identität, welcher öffentliche Schlüssel per DNS abzuholen ist – stimmt die Signatur, bestätigt das System die Identität des Versenders.

Um E-Mail-typische Modifikationen (Header-Umformatierung, Leerzeilen- und Whitespace-Behandlung) im Verlauf der Zustellung über möglicherweise mehrere Zwischenschritte zu ermöglichen, kann der Signierende optional auch eine "tolerante" normalisierte Form (Relaxed Canonicalization) der betreffenden Nachrichten-Teile unterschreiben. Inhaltliche Veränderungen des Nachrichtentextes oder der signierten Header würden jedoch auch dann eine erfolgreiche Verifikation verhindern.

Durch die Auswahl, welche Header-Informationen signiert werden und welche nicht, funktioniert das DKIM-Verfahren auch für Mailing-Listen oder externe Mail-Dienstleister, die üblicherweise zusätzliche Informationen in die Nachrichten einfügen. Einem Empfänger steht es naturgemäß frei, zur Akzeptanz einer Signatur eigene Policies aufzustellen, die zur positiven Verifikation die Signatur bestimmter Header fordern.

Die Art der Information des Endanwenders über eine erfolgreiche oder nicht-erfolgreiche DKIM-Prüfung ist im Standard nicht geregelt. Da ein Anwender in seinem Mail-Client auch bei minimaler Header-Anzeige in der Regel zumindest das "From"-Feld sieht, könnte ein DKIM-verifizierender Empfänger-MTA das Ergebnis der Signaturprüfung beispielsweise in diesem Feld dokumentieren. Etwa durch 'From: "Max Mustermann via <mailing@list.org>" <mustermann@example.com>', wenn die betreffende E-Mail nicht von mustermann@example.com, sondern von der benannten Mailingliste als Versender signiert wurde. Der Benutzer kann dann entscheiden, ob dies in Ordnung ist oder nicht. In jedem Fall sollte das Ergebnis der Authentifizierung in einem zusätzlichen Header-Feld "Authentication-Results" eingefügt werden.

Grenzen

Die vergleichsweise leichte Implementierbarkeit und die Möglichkeit der schrittweisen und wahlfreien Einführung und Nutzung von DKIM bedingen einige Grenzen des Verfahrens: Allem voran ist ohne Weiteres nur eine positive Bestätigung von Absendern möglich, Negativaussagen erfordern hingegen zusätzliche Schritte. Denn Nachrichten ohne DKIM-Signatur werden weiterhin die Regel oder immerhin weit verbreitet bleiben, sodass ein Zurückweisen unsignierter E-Mails zumindest vorerst nicht infrage kommt. Zumindest müsste man hierzu genau wissen, ob beziehungsweise wann die absendende Domain Nachrichten DKIM-signiert und ob sie das ausschließlich selbst durchführt (First Party Signature) oder auch Dritten eine Signatur gestattet. Erst dann wäre eine unsignierte E-Mail als "Fälschung" abzuweisen. Entsprechende (Vor-)Überlegungen für ein DKIM Signing Practices Protocol (SPP) enthält der brandneue RFC 5016 vom Oktober 2007 an [2].

Zudem sind eine Reihe von Angriffen gegen die DKIM-Signatur-Systeme und vor allem gegen die Signatur-Praktiken möglich – RFC 4686 beschreibt ausführlich mögliche Täter und Szenarien. Neben den typischen kryptographischen Angriffsvektoren sind darin nicht zuletzt auch Attacken gegen das (derzeit quasi ungesicherte) DNS, die Verwendung mehrerer Absenderadressen (gem. RFC 2822 durchaus erlaubt) oder durch den Missbrauch der Third-Party-Signatur-Möglichkeit beschrieben.

Außerdem hilft DKIM nicht gegen die im Phishing üblichen "ähnlichen" oder "internationalisierten" Domains: Wenn www.examp1e.com (mit der Ziffer "1" statt eines "l") unter der Kontrolle eines Angreifers steht, kann dieser naturgemäß auch korrekte DKIM-Signaturen für E-Mails von dieser Domain erstellen, die bei oberflächlicher Betrachtung als example.com durchgehen mag. Es bleibt also für den Anwender weiterhin notwendig, Absenderadressen aufmerksam auf "Korrektheit" zu prüfen.

Gut oder böse?

Neben der Authentifizierung, ob vorgeblicher und tatsächlicher Absender übereinstimmen, muss daher auch eine Bewertung erfolgen, ob ebendieser Absender seriös ist oder nicht. Eine "echte" Nachricht kann dennoch – wie im vorigen Beispiel – unerwünscht oder gefährlich sein. Technische Hilfe können hierbei so genannte reputationsbasierte Dienste leisten: Der "Reputation Score" gibt Erfahrungswerte wieder, mit der eine bestimmte Domain oder IP-Nummer als Malware-, Phishing- oder Spam-Versender aufgefallen ist.

Gerade bei den bekannten, großen Absendern haben die Reputationsdienste durch die Analyse einer Vielzahl bereits versandter E-Mails keine Probleme, deren Seriosität fundiert einzuschätzen. "Neue", lediglich für den Menschen ähnlich wirkende Domains haben dann entweder noch gar kein Scoring, was bei vorgeblichen Nachrichten von Großbanken Anlass zum Misstrauen geben sollte. Oder die Phishing-Sites haben bereits aufgrund erster Analysen schon eine negative Beurteilung, was eventuell schon ein Abweisen am Gateway ermöglicht.

Fazit

Absender-Authentifizierung ist ein wesentlicher Schritt hin zu einem deutlich besseren E-Mail-System. In Zukunft könnten damit – bei entsprechender Verbreitung – Absenderfälschungen bei Phishing-Mails drastisch erschwert werden. Dies setzt jedoch auch auf Empfängerseite entsprechende Echtheits- und Policy-Prüfungen voraus. Erste große Provider unterstützen DKIM bereits und auch einige Sicherheitsanbieter haben dieses Verfahren schon in ihre Gateway-Lösungen integriert.

Bis der Standard allerdings eine flächendeckende Verbreitung findet, wird es wohl noch etwas dauern. Der Grund liegt in den erforderlichen Modifikationen der Mail-Server: Administratoren müssen die zugehörige Software testen und zum Einsatz bringen. Zudem benötigen die für DKIM notwendigen kryptographischen Verfahren erhöhte Rechenleistung. Mit spezialisierten Mail-Gateways und immer schnelleren, aktuellen Server-Systemen sollte dies jedoch selbst für große Organisationen kein grundsätzliches Problem darstellen.

Solange noch nicht alle Netzteilnehmer DKIM unterstützen, können jedoch nicht-authentifizierte E-Mails kaum automatisiert verworfen werden, sodass flexible, mehrschichtige Sicherheitsmechanismen weiterhin notwendig bleiben – und auch die Aufmerksamkeit beim Anwender dürfte noch lange Zeit eine bedeutende Komponente in der Phishing-Abwehr darstellen.

Reiner baumann ist verantwortlich für die Region Zentral- und Osteuropa bei der Cisco-Geschäftseinheit IronPort.

zurück zum Inhalt
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2007^#6, Seite 74
tag:kes.info,2007:art:2007-6-074