Unterschiede und Merkmale von DKIM, PGP und S/MIME

Ab 20. Februar will die Deutsche Telekom ihre Rechnungs-e-Mails mit weiteren Sicherheitsmerkmalen ausstatten, um das Erkennen von Fälschungen zu erleichtern (via heise). Kernbestandteil der neuen Merkmale ist eine kryptografische Signatur. Endlich muss man sagen, denn die Technik hierfür steht schon seit längerem zur Verfügung und wird bereits vielfältig verwendet. Allerdings verwendet die Telekom weder PGP (bzw. GnuPG) oder S/MIME, sondern das allgemein weniger bekannte DKIM. Die meisten Anwender bekommen schon lange DKIM-signierte Mails, wissen es jedoch noch nicht. Das ebenfalls neu eingeführte „E-Mail-Siegel“ (vor dem Absender ein blaues @-Zeichen mit Haken) ist nur eine optische Darstellung einiger am Verbund beteiligter Webmailer (GMX, WEB.DE, freenet und 1&1) und bei Anwendungen der Telekom selbst. Alle anderen, insbesondere diejenigen, die mit einem e-Mailprogramm, arbeiten haben nichts davon, sie könnten die Herkunft einer e-Mail nur anhand der zunächst unsichtbaren DKIM-Signatur verifizieren.

Der Entschluss der Telekom nicht auf S/MIME oder PGP zu setzen dürfte organisatorischer und vor allen Dingen monetärer Natur sein, weil die Implementierung durch einige wenige Techniker erfolgen kann. Eine Zusammenarbeit mit den Kunden oder eine Schulung aller Mitarbeiter eines Unternehmens ist nicht erforderlich. Im Normalfall bemerkt niemand die Einführung einer DKIM-Signatur, da dies vollkommen transparent auf dem Mailserver, durch Hinzufügen einiger weniger Zeilen im Mailkopf vor dem Versenden der e-Mails, erfolgt.

Die Einsatzgebiete von DKIM auf der einen und PGP/GPG und S/MIME auf der anderen Seite unterscheiden sich und sind nicht deckungsleich. Um den Unterschied zu verstehen muß man zunächst wissen wie eine e-Mail aufgebaut ist. Auch wenn sie als eine lange zusammenhängende Zeichenkette verschickt wird, besteht sie im Wesentlichen aus zwei Teilen, dem Kopf (header) und dem Körper (body). Die erste leere Zeile nach dem Betreff (subject) stellt die Trennung der beiden Teile dar. Der normale Anwender sieht vom Kopf üblicherweise nur den Absender, den oder die Empfänger und den Betreff, obwohl er so gut wie immer weitaus mehr Angaben enthält, jedoch sind diese im Alltagsgebrauch irrelevant (alle Mailprogramme haben eine Funktion, für die Anzeige und den Export der Roh-e-Mail). Der Inhalt des Mailkopfes ist identisch mit den Metadaten einer jeden e-Mail. Der Mailkörper hingegen enthält alles was zur eigentlichen Nachricht an den Empfänger gehört, Texte, Bilder, Anhänge etc.

PGP und S/MIME

Sowohl PGP als auch S/MIME dienen der Vertraulichkeit (Verschlüsselung) und Authentifizierung (Signierung), zusammen oder getrennt, einer e-Mailnachricht. Beide Techniken benötigen individuelle Schlüssel — und damit auch eine Schlüsselverwaltung — und befassen sich nur mit dem Mailkörper, die Kopfzeilen (Metadaten mit den Angaben zu Betreff, Absender und Empfänger uva.) bleiben außen vor. Daher können die Geheimdienste auch bei derart verschlüsselten Inhalten immer noch sehr viel Informationen über Sender und Empfänger sammeln. Weiterhin kommen beide Verfahren, insbesondere PGP, nicht nur bei der verschlüsselten Übermittlung von Daten zum Einsatz, sondern auch bei der längerfristigen, vor unbefugtem Zugriff geschützten Lagerung.

PGP (GnuPG)

PGP kann sich jedermann auf seinem Rechner installieren und ganz nach Bedarf einen oder mehrere Schlüselpaare aus geheimem und öffentlichem Schlüssel generieren. Es ist dann seine Aufgabe den öffentlichen Schlüssel seinen Kommunikationspartnern bekannt zu machen. Es gibt keine Hierarchie, alle Schlüssel sind gleichwertig und die Authentizität eines Schlüssels ist zunächst unklar, was durchaus ein relevantes Problem darstellt, da bei der Schlüsselerzeugung beliebige Angaben gemacht werden können. Jeder kann für jede beliebige e-Mailadresse einen Schlüssel erzeugen und vollkommen unkontrolliert verbreiten! Um die Folgen dieses Problems einzudämmen, wurde ein Verfahren zur Signierung von Schlüsseln durch Dritte eingeführt. Kommunikationspartner die sich kennen signieren kreuzweise ihre jeweiligen Schlüssel und bestätigen somit die Angaben im Schlüssel ihres Gegenübers. Je mehr Unterschriften ein Schlüssel trägt, desto höher ist die Wahrscheinlichkeit, daß er echt ist (i.S.v. er gehört zu den im Schlüssel gemachten Angaben) und das jemand der nach einem Schlüssel einer Person sucht, jemanden in der Unterzeichnerliste findet, den er kennt und dem er soweit vertauen kann, daß diese Person die Schlüsselangaben überprüft hat. Das durch das Unterschreiben der Schlüssel entstehende Netz, nennt man „Web of Trust“ (WoT). Um das WoT möglichst dicht zu knüpfen werden manchmal Kryptoparties (z. B. hier) veranstaltet, wo man sich trifft, um sich gegenseitig die Schlüssel zu verifizieren und dies durch Signieren kund zu tun. Bei vollkommen unbekannten Unterzeichnern und bei Schlüsseln ohne Signaturen ist daher immer erhöhte Vorsicht bei der Schlüsselauswahl geboten!

S/MIME

S/MIME hingegen wurde für hierarchische Organisationen entworfen. Üblicherweise werden hier die Schlüssel, Zertifikate genannt, von einer Organisation für ihre Mitarbeiter ausgegeben. Gültigkeit und Geltungsbereich der Zertifikate sind, anders als bei PGP, nicht mehr gleichwertig, sondern hängen von denen der übergeordneten Stelle ab. Ein „Web of Trust“ gibt es nicht. Wird ein Zertifikat einer übergeordneten Stelle ungültig, verfallen (i.S.v. sind nicht mehr vertrauenswürdig) auch die der darunterliegenden Hierarchieebenen. (Es gibt in der Praxis unter gewissen Bedingungen allerdings Probleme beim Rückruf von Zertifikaten, dies ist aber hier jetzt nicht von Bedeutung). An oberster Stelle des Hierarchiebaumes steht ein sogenanntes Trust Center. An ihm hängt alles, denn wird das Wurzelzertifikat des Trust-Centers kompromittiert (oder ein Geheimdienst betreibt gleich selbst das Trust-Center), sind auf einen Schlag Abertausende von Zertifikaten ebenfalls kompromittiert.

DomainKeys Identified Mail (DKIM)

DKIM arbeitet vollkommen anders als PGP S/MIME. Es unterscheidet sich in drei wesentlichen Punkten:

  1. Es dient nicht der Verschlüsselung, sondern ausschließlich der Authentifizierung.
  2. Es bezieht Teile der Metadaten (Mailkopf) ein.
  3. Es gibt keine individuellen personenbezogenen Schlüssel oder Zertifikate, da es domänenbasiert (…@Beispiel.DE) ist.

Beim DKIM-Verfahren werden zusätzlich einige frei wählbare Zeilen des e-Mailkopfes, üblicherweise Empfänger, Absender, Betreff und Message-ID signiert und dabei eine Beziehung zu der Absenderdomäne im „Domain Name System“ (DNS) hergestellt. Für die Signatur selbst wird der e-Mailkopf um einige Zeilen mit den entsprechenden Angaben ergänzt, die daher für den Benutzer im Normalfall unsichtbar bleibt.

Gerade der dritte Punkt dürfte für ein Unternehmen einen wesentlichen ökonomischen Anreiz darstellen, die Herkunft (nicht den Inhalt) seiner e-Mails abzusichern, da man ohne die recht aufwendige Schlüsselverwaltung, Schulung von Mitarbeitern und Information und Zusammenarbeit der Kunden auskommt. Außerdem bietet DKIM den Vorteil, sie beim Empfang durch die Provider anhand einer weißen Liste vollautomatisiert auswerten und ggf. als Spam markieren zu können.

Zur Verdeutlichung mal zwei konkrete Beispiele einer DKIM-Signatur. Der erste Fall ist einer e-Mail eines Tchibo-Newsletters entnommen. Wie man ohne Umschweife erkennen kann, wurden hier aus dem Mailkopf die Angaben für Message-ID, Datum, Absender, Antwortadresse, Empfänger und Betreff signiert. Die Auswertung der Signatur, ergibt ein korrektes Ergebnis und man kann davon ausgehen, daß eine solche e-Mail mit sehr hoher Wahrscheinlichkeit tatsächlich einmalvon von News.Tchibo.DE versendet wurde.

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=mailing; d=news.tchibo.de;
	h=Message-ID:Date:From:Reply-To:To:Subject:MIME-Version:Content-Type:List-Id:X-CSA-Complaints:List-Unsubscribe:X-ulpe; i=Newsletter@news.tchibo.de;
	bh=Z0LU3k+s0QRzuxhbfNm0TrXuFz8=;
	b=I16/KDTpmheCQhmcSsDrG+wQ0evKJe1Wvtq/mCTrS0e9SHlmtd56blMlEoVveTIVkNzfXbtnBBlr
	 mQ+x4t8PKOXqI15zawP2CpfO3wZMoGZIPv1dI5OLaPVl3vgbSq9BB9eHOV3jJrdt4sYyTR3bU5CI
	 6OP1racNTRvkrGDMo6U=

Das zweite Beispiel ist ebenfalls nicht konstruiert, weist aber aus Anwendersicht auf ein Problem hin. Die e-Mail stammt aus dem Heise-Verlag (c’t, iX) mit Absenderadresse <infoservice@heise.de>. Auch hier wurden die Kopfzeilen zu Datum, Absender, Empfänger, Message-ID und Betreff signiert.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=inxserver.com; s=abc;
	t=1424183457; r=y; bh=o7jN2oJAeTe11u1xDFYqg0yTvAvJ8ktkYBpqc84/OuA=;
	h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type:List-Id:
	 X-Mailer;
	b=CmAXG/QsEKp9E25IQmAaB0mk7aOHhd/iY0XF0FA5uX6h9QQ9P80D5qzY0ZHKqJ40p
	 puh7lJG6GFpC11MtcPHmHsKVoNMzbwFwh/4bAaKGch4rG7JoTrjdgfX4IQdLuZFgiz
	 nfNYB/s23xtEeWpDrvbVeNtf6YwoVvjQ+MvRht8I=

Die Auswertung der Signatur hinterlässt beim Enanwender jedoch ein Fragezeichen. Einerseits liegt aus mathematischer Sicht eine gültige Signatur vor, aber andererseits passt der Absender (…@heise.de) nicht zur signierenden Domäne (inxserver.com). Von wem stammt nun die e-Mail tatsächlich? Ohne weitere Informationen kann der Anwender die Frage nicht beantworten. Hier haben wir einen typischen Fall, in dem die verteilte IT-Architektur ein eigentlich vernünftiges System wieder ad absurdum führt. In diesem Falle stammt die Mail übrigens tatsächlich vom heise-Verlag. Ähnliche Probleme entstehen bei der Umrüstung von Webseiten von http zu https, da die überwiegende Mehrheit aller Webseiten ihre Inhalte von dutzenden von Servern die unter verschiedenen Domänen angesprochen werden zusammenklaubt.

Noch schlimmer sieht es bei Yahoo, einem der ursprünglichen Protagonisten bei der Entwicklung hin zum DKIM-System, aus. Die ausgehenden e-Mails werden zwar signiert, aber manchmal ist die Signatur gültig, ein anderes Mal wieder nicht. Besonders betroffen davon sind die Yahoo-Gruppen. Die Ursache liegt darin, daß nach dem Signieren eine Änderung an den signierten Elementen vorgenommen worden ist. Bei den Yahoo-Gruppen könnte es sich dabei um die nachträglich angehängte Fußzeile mit Werbung handeln. Durch solche Konstruktionen wird das System für den normalen Endanwender unbrauchbar gemacht und Betrügern ein Tor offen gehalten.

Fazit

DKIM signierte e-Mails tragen, da unverschlüsselt, nicht zur Vertraulichkeit des e-Mailinhalts bei, stellen aber ein starkes Indiz für den angegebenen Absender dar. Weiß man, daß eine Organisation immer DKIM-signierte Mails versendet, kann man alle nicht DKIM signierten e-Mails, die von dieser Organisation zu kommen scheinen ignorieren. DKIM stellt also eine Verbindung zwischen Domäne und e-Mailversender her, wohingegen PGP und S/MIME über den Schlüssel den Schreiber der e-Mail mit dem e-Mailinhalt verknüpfen, vollkommen unabhängig davon, welcher Absender in den Kopfzeilen eingetragen ist.

DKIM ist schon seit Längerem im Einsatz, doch wohl so gut wie immer von den Anwendern unbemerkt, da die Standardmailprogramme die DKIM-Kopfzeilen weder anzeigen, noch auswerten. Für Thunderbird gibt es das brauchbare Plugin „DKIM Verifier“, welches die beiden Funktionen Anzeige und Auswertung nachrüstet.

Es ist nicht davon auszugehen, daß die DKIM-Signierung zum völligen Verschwinden von betrügerischen Rechnungsmails führen wird, wie as Beispiel Paypal zeigt. Seit einiger Zeit sind die e-Mails von Paypal zwar DKIM signiert, aber es kursieren immer noch Betrugsmails, die nicht zuverlässig ausgefiltert werden, was darauf hindeutet, daß immer noch genug Leute darauf hineinfallen. Das kann auch darin liegen, daß die e-Mailprogramme DKIM standardmäßig eben nicht auswerten.

Ein Kommentar

  1. […] löschen. (Dies ginge theoretisch schon jetzt, da alle e-Mails aus der Domäne Facebook.com eine DKIM-Signatur tragen, die aber kaum jemand prüft.) Dies ist auch einer Hauptgründe warum Unternehmen […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert