In zwei Jahrzehnten als Vollzeitnerd hat sich der ein oder andere Text angesammelt, mit denen ich unseren Azubis versucht habe, Grundlagen über unseren Job (TCP/IP, aber auch bevorzugt Telefonie) zu erklären.

Das stelle ich hier, wann immer ich so einen Text nochmal irgendwo finde, zusammen. Diese Texte haben nicht den Anspruch, zu 100% exakt zu sein (sondern manches ist des besseres Verständnisses wegen vereinfacht worden). 

Heute:

E-Mail-Kommunikation ist vom Sicherheitsniveau vergleichbar mit einem normalen Brief: Die Absenderin Alice schreibt oben rechts auf den Brief (und auf die Rückseite vom Umschlag) ihren Namen, der Empfänger Bob liest die Angabe und vertraut darauf, dass der Brief wirklich von Alice ist, denn das steht ja oben. 

Moderne Farbdrucker machen's möglich: Wenn der Brief gar nicht von Alice kommt, sondern vom bösen Ben, aber der einfach oben rechts Alice' Adresse draufschreibt, dann kann Bob drauf reinfallen. Nichts anderes passiert bei E-Mails, egal ob Spam oder Phishing-Mails, ob Trojaner-Versand oder sonstige Einbruchsversuche: Der Täter gibt einfach falsche Adressangaben an.

Das führt zu einem Katz- und Mausspiel zwischen böswilligen (Spam-)Versendern und Spam-Filtern, die das verhindern wollen. 

Bevor wir uns über die Echtheit der Mails durch Signaturen Gedanken machen, gehen wir einen Schritt zurück:

Mittels SPF-Records (Sender Policy Framework) kann Alice im Nameserver ihrer Domain veröffentlichen, welche Mailserver überhaupt von ihr befugt wurden, in ihrem Namen Mails zu verschicken. Damit kann man zwar den Inhalt der Mail nicht validieren, aber zumindest kann man gucken, ob man sozusagen dem Absender-Poststempel vertraut oder schon daran erkennen, dass die Mail eine Fälschung sein könnte.

Den Aufbau von SPF-Records habe ich im Thema DNS bereits erklärt. 

Ideen zum Signieren und Verschlüsseln von Mails gibt's schon viel länger, PGP und S/MIME sind zwei Techniken aus den späten 90er Jahren.

Beim Signieren geht es darum, die Mail digital zu unterschreiben, so dass der Empfänger Bob prüfen kann, ob es wirklich Alice war, die den Brief geschrieben hat (und auch, ob der Brief noch den gleichen Inhalt hat wie bei ihr und nicht auf dem Transportweg verändert wurde).

Zum Signieren errechnet Alice' Mailprogramm zuerst eine Prüfziffer (ein sog. Hash-Wert) aus dem Inhalt ihrer Mail. Wenn Bob nach dem gleichen öffentlichen Verfahren eine Prüfziffer aus dem Inhalt der Mail errechnet, und die gleiche Prüfziffer rausbekommt, weiß er, dass der Inhalt auch gleich sein muss.

Als nächstes wird diese Prüfziffer mit Alice' private key signiert. Wie bei anderer Verschlüsselung auch (z.B. https) kommen zwei kryptografische Schlüssel zum Einsatz, den private key kennt nur die autorisierte Person (in dem Fall Alice) und kann damit unterschreiben, den public key darf jeder kennen und kann damit überprüfen, ob die Unterschrift wirklich von Alice stammt. Bob kann jetzt also mit ihren Public Key gucken, ob die Prüfziffer auch wirklich von ihr signiert wurde (und damit ist auch klar, dass die ganze Nachricht unverändert von ihr stammt). 

(Theoretisch könnte Alice auch einfach die komplette Nachricht signieren. Dann ist aber sozusagen das "Begleitdokument", mit dem nur die Echtheit geprüft werden muss, genauso groß wie die Nachricht selbst, einschl. aller Attachments. Die Prüfziffer hingegen ist ja relativ klein, entsprechend braucht dieses Verfahren weniger Platz, weniger Rechenleistung und weniger Transportkapazität).

Beim Verschlüsseln geht es darum, die Mail so zu verschlüsseln, dass nur Bob sie lesen kann, aber jemand außenstehendes nicht. Das Prinzip ist dabei andersrum, dazu braucht Alice dann Bobs public key, kann damit die Nachricht verschlüsseln, und nur der Inhaber des private keys, also in dem Fall Bob, kann die Nachricht dann wieder entschlüsseln. Auch hier kann man ein bisschen Rechenleistung sparen: Wenn eine Nachricht an z.B. fünf Empfänger geschickt wird, wird die eigentliche Nachricht nur einmal symmetrisch verschlüsselt (d.h. mit einem Schlüssel, den alle beteiligten Parteien kennen). Und dieser vergleichsweise kleine Schlüssel wird dann für jeden Empfänger individuell asymmetrisch mit dessen public key verschlüsselt.  

Die beiden Techniken PGP (Pretty good privacy) und S/MIME (Secure Multipurpose Internet Mail Extensions) konkurrieren an der Stelle um die Gunst der Nutzer. Beide sind vom Sicherheitsniveau vergleichbar, beide haben sich (leider) nicht wirklich in breiter Masse durchgesetzt, S/MIME zumindest langsam. Der große Unterschied ist der Schlüsselaustausch, PGP basiert darauf, dass man seinen public key irgendwo veröffentlicht (würde ich PGP nutzen, würde ich z.B. meinen Key in mein Impressum packen und jeder, der mit mir sicher kommunizieren will, kann ihn da rauskopieren), was im Massen-Alltag eher unhandlich ist. S/MIME hingegen basiert auf Zertifikaten (vergleichbar https) mit allen damit verbundenen Vor- und Nachteilen. 

Okay, also:

Alice hat dank SPF festgelegt, über welche Postämter/Briefkästen sie überhaupt nur Briefe verschickt. So kann bereits Bobs Mailserver (Postbote) zu einfach gefälschte Briefe von Alice, die in Wirklichkeit aus einer ganz anderen Stadt kommen, erkennen und wegwerfen.

Wenn Alice ihre Mails mit PGP oder S/MIME signiert, und Bob das ebenfalls nutzt (wobei das Überprüfen ankommender S/MIME-Signaturen inzwischen in vielen Mailprogrammen als Standardfeature eingebaut ist), dann kann er sicher sein, dass die Mail von Alice stammt. Aber dazu muss er sie auch erhalten und öffnen, und er muss in dem Moment auch daran denken, dass Alice normalerweise digitale Signaturen benutzt. 

Oder in der Nicht-technischen Welt: Wenn Alice ein spezielles Wasserzeichen-Papier benutzt, erkennt Bob direkt beim Lesen, dass der Brief von Alice ist. Aber wenn nun ein Betrüger trotzdem einfach Alice' Namen als Absender auf ein Schreiben druckt und z.B. Bob sich seine Post von einem Dienstleister einscannen lässt, dann wird er den Betrug u.U. trotzdem nicht bemerken.

Und an der Stelle kommen zwei neue Techniken zum Einsatz:

DomainKeys Identified Mail (DKIM)

DKIM ist eine Technik, bei der - ähnlich wie auch bei PGP oder S/MIME - die Mail digital signiert wird. Der Unterschied besteht darin, dass das auf beiden Seiten auf Mailserver- und nicht auf Mail-Client-Ebene erfolgt. Also nicht Alice signiert ihre Mail selbst (mit ihrem persönlichen S/MIME-Zertifikat). Sondern Alice' Mailserver signiert die Mail mit einem Schlüssel, den auch nicht Alice selbst kennt, sondern der Mailserver-Betreiber (also z.B. der Arbeitgeber).

Und nicht Bob prüft (bzw. lässt sich von seinem Mailprogramm anzeigen) prüft, ob die Signatur vorhanden und richtig ist, sondern der Server seines Mailproviders. Das ganze läuft dabei nicht über Zertifikate ab, sondern der entsprechende public key wird auch im DNS in einem sog. TXT-Record veröffentlicht (ähnlich wie bei SPF z.B. auch):

alicemails._domainkey.beispieldomain.de.  IN TXT "v=DKIM1; p=ABCJOSD12DCF123"

"alicemails" ist in diesem Fall der Selector, deren kann es mehrere geben. Der absendende Mailserver schreibt beim Signieren dazu, welchen Selector er benutzt hat, es kann ja durchaus sein, dass verschiedene ganz unterschiedliche Mailserver Mails verschicken, dann kann jeder einen eigenen Key und Selector bekommen. Dann kommt das Schlüsselwort _domainkey, das ganze ist dann eine Subdomain von Alice' Absenderdomain, und der IN TXT-Eintrag beginnt dann in mit "v=DKIM1" gefolgt vom public key, in diesem Fall der (zu kurze) ABCJOSD...  

Der große Unterschied zu PGP und S/MIME ist der Anwendungsfall: PGP und S/MIME bilden eine Ende-zu-Ende-Verschlüsselung (bzw. -Signatur) ab. Sie geben Bob die Sicherheit (ggf. auch rechtssicher), dass Alice die Mail wirklich selbst geschrieben hat, weil sie die Mail mit ihrem persönlichen Schlüssel signiert hat. Den Mailservern zwischendurch ist das egal, es ist noch nicht einmal wichtig, über welche Mailserver die Mail transportiert wurde.

DKIM hingegen ist nicht für Alice, nicht für Bob, sondern ist eine Sache zwischen den Mailservern der beiden: Der Mailserver von Bob kann prüfen, ob diese Mail mit diesem Inhalt wirklich von dem Mailserver, der für Alice' Mailadresse zuständig ist, verschickt wurde.Ob sie wirklich von Alice stammt (oder von einem Kollegen, der den gleichen Mailserver nutzt), und ob sie vollständig bei Bob angekommen ist (oder ob Bobs Mailserver z.B. noch Attachments aus Sicherheitsgründen entfernt hat), darüber gibt DKIM keine Auskunft.

DKIM alleine schützt aber noch nicht davor, dass Leute unsigniert Mails schicken. Dafür gibt es dann:

Domain-based Message Authentication, Reporting and Conformance (DMARC)

DMARC wird ebenfalls wieder (darum heißt es auch "domain-based") im DNS-Zonenfile der Domain eingetragen, und zwar wieder als TXT-Record:

_dmarc.beispieldomain.de.  IN TXT "v=DMARC1; p=reject; ruf=mailto:it@beispieldomain.de; adkim=r; aspf=r"

In diesem Fall gibt es keinen Selector, wir wollen ja für diese Domain generell vorgeben, dass z.B. immer DKIM benutzt werden soll, darum muss das natürlich auch öffentlich (ohne dass man einen Selector kennt) abfragbar sein.

Dann kommt ein TXT-Record vom Typ "DMARC1", und der enthält eine policy (in dem Fall reject) und eine "Domain forensic reporting"-Aktion (ruf), in dem Fall mit einer Mail-Adresse.

Heißt im Klartext: Wenn eine Mail reinkommt mit einem Absender beispieldomain.de, dann hat Alice' Domainprovider klargestellt, dass SPF und DKIM geprüft werden sollen (adkim und aspf sind die Abgleichmodi/alignments, r steht für relaxed, s für strict. Führt jetzt an der Stelle etwas zu weit, aber selbst der Default-Wert r sorgt dafür, dass beides Pflicht ist). Und wenn das fehlschlägt, dann wird die Mail abgewiesen (reject). Und die ruf-Adresse bekommt einen Forensic-Report, u.a. um mögliche Konfigurationsfehler finden zu können.

Wichtig: Ab dem Moment, wo o.g. DMARC-Eintrag konfiguriert ist, würden alle unsignierten Mails als potentieller Spam abgewiesen ("reject")!