E-Mail und Identität sind fest miteinander verknüpft. Woher weiß ich, dass eine E-Mail tatsächlich von dem kommt, dessen Namen ich im Absender sehe? Vor allem im geschäftlichen E-Mail-Verkehr ist dieser Nachweis wichtig. Doch wie stellt man das schnell und einfach an?
Was kann beim Mailen schon schief gehen?
Mit welchem Mailsystem auch immer man arbeitet, am Ende ist es SMTP, das Simple Mail Transfer Protocol, welches eine E-Mail zum Empfänger transportiert. Und der Name ist Programm. Es ist wirklich sehr einfach. Die folgenden 9 Zeilen sind es, in denen Voodoo komplett passiert. Mit einer Verbindung per Telnet auf den Port 25 eines offenen SMTP-Servers kann man dies probieren:
[1] MAIL FROM:
[2] RCPT TO:
[3] DATA
[4] From: Mein Name <>
[5] To: Dein Name <>
[6] Subject: Was auch immer
[7]
[8] Bin ich es wirklich?
[9] .
Die Zeile 1 teilt dem Server mit, wer man eigentlich ist. Diese Adresse sollte dem Mailserver bekannt sein. In der Zeile 2 wird die Empfängeradresse kundgetan. Im DATA-Block (Zeile 4 bis 9) wird nun das geschrieben, was ein E-Mal-Client am Ende anzeigt. Die Daten in Zeile 4 müssen nicht mit denen in Zeile 1 übereinstimmen, sie werden nicht einmal geprüft. Mit den Zeilen 5 und 2 verhält es sich analog. Hier ahnt man schon, was ausgenutzt werden kann.
Nun mag man sagen, dass ja SMTP-Server heute eine Authentifizierung verlangen und man solcherlei Betrug damit nicht mehr veranstalten kann, ohne aufzufliegen. Das stimmt nur bedingt. SMTP ist ein dezentrales System. Ich kann mir sehr schnell einen solchen Server aufsetzen und diesen beliebig konfigurieren. Die Zeile 1 obliegt dann vollkommen meiner Kontrolle. Gewiss werde ich damit irgendwann als Spammer geblockt – aber wann ist schon „irgendwann“?
Puh – Und nun?
Mit PGP und S/MIME gibt es zwei Standards für E-Mail-Verschlüsselung. In diesen Systemen steckt aber noch eine viel wichtigere Funktion: Das Nachweis der Identität des Absenders und der Originalität der E-Mail durch die digitale Signatur [1].
Ein Benutzer erhält bei beiden Verfahren einen öffentlichen und einen privaten Schlüssel in digitaler Form. Der öffentliche Schlüssel ist sozusagen der Clubausweis mit Foto und Fingerabdruck, der private Schlüssel sind das dazu passende Gesicht und der Finger. Daten, die mit dem öffentlichen Schlüssel verschlüsselt wurden, können mit dem privaten Schlüssel – und zwar nur mit diesem – wieder lesbar gemacht werden und umgedreht. An die Daten kommt man also nur heran, wenn man entweder der mit dem Gesicht und dem Finger ist, oder wenn man den Clubausweis sieht.
Beim Signieren einer E-Mail wendet der Versender seinen privaten digitalen Schlüssel auf die E-Mail an. Dabei wird eine nur für eben diese E-Mail – also den oben gezeigten DATA-Block – passende Prüfsumme errechnet und mit dem Schlüssel verschlüsselt. Die E-Mail wird dann mit dem öffentlichen Schlüssel als Attachment versandt. Der Empfänger kann die Prüfsumme mit dem öffentlichen Schlüssel entschlüsseln und herausfinden, ob diese mit der von ihm selbst errechneten Prüfsumme übereinstimmt. Somit ist sichergestellt, dass die E-Mail von demjenigen versandt wurde, der in Besitz des privaten Schlüssels zum anhängenden öffentlichen Schlüssel ist. Im oben eingeführten Bild zeigt der Versender also mit seinem Gesicht, seinem Finger und seinem Clubausweis, das er derjenige ist, der auf dem Ausweis eingetragen wurde.
Was ist das für ein Club?
Für das etwas alberne Bild eines Clubausweises habe ich mich entscheiden, weil mehr noch nicht gesagt wurde. Den Ausweis kann nämlich so jeder herstellen. Damit dieser wirklich etwas aussagt, muss er einer höheren Institution, sagen wir von einem Land, unterschrieben werden. Dann wird daraus ein Personalausweis und das Vertrauen in den Ausweis wächst.
So funktioniert das mit S/MIME. Hier erhält der Benutzer anstelle des öffentlichen Schlüssels ein Zertifikat, in dem neben eben dem öffentlichen Schlüssel auch die Beglaubigungen von höherer Stelle bis hin zu einem Wurzelzertifikat eingetragen wird. Vertraut der Empfänger einer der beglaubigenden Organisationen, so ist die Echtheit des Versenders anzunehmen.
S/MIME-Zertifikate
Bei Kopano haben wir uns für die Arbeit mit S/MIME entschieden. Die strenge Hierarchie der Zertifikate passt sehr gut zu unseren Umgebungen. Zertifikate werden über eine PKI (Public Key Infrastrcuture [2]) ausgestellt, verteilt und geprüft. Diese PKI kann man sich selbst aufbauen (komplex), beglaubigen lassen (teuer) oder man kauft ein Zertifikat bei einer öffentlichen Zertifizierungsstelle.
Die Zertifikate gibt es nicht nur in verschiedenen Geschmacksrichtungen (Globesign, Comodo, Trustwave und andere), sondern auch in unterschiedlichen Klassen. Diese sind nicht standardisiert [3], jedoch gilt: Je höher die Klasse, desto persönlich bekannter der Inhaber des Zertifikats. Ich denke, dass die Klasse 1, welche bei allen Anbietern die ich gefunden habe die E-Mail-Adresse verifiziert, ausreichend ist. Sie stellt sicher, dass die im oben genannten DATA-Block benutzte Absenderadresse passt.
Wie komme ich an ein Zertifikat?
Immer wieder habe ich gehört, dass der Kauf bei einem Reseller dem Kauf bei der Zertifizierungsstelle selbst vorzuziehen ist. Preis und Service passen hier besser zusammen, sagt man. Das sind aber gewiss alles sehr individuelle Erfahrungswerte. Ein kostenfreies Zertifikat kann man zum Beispiel bei Comodo [4] bestellen. Ich habe mich letztendlich dafür entschieden, mein S/MIME-Zertifikat bei einem Reseller zu kaufen. Durch Zufall kenne ich sogar dessen Geschäftsführer – Vertrauen zählt eben viel ;-).
Der Prozess der Bestellung beinhaltet immer die Prüfung, ob man es auch wirklich ist. Bei Zertifikaten der Klasse 1 sollte es immer genügen, einen Link in einer Bestätigungs-E-Mail anzuklicken. Je höher die Klasse ist, desto komplexer wird diese Prüfung.
Das finale Zertifikat wird dann typischerweise als PFX-File geliefert. Sehr wichtig ist nun, dass dieses Zertifikat nur in meinen Händen bleibt! Das PFX-File enthält sowohl meinen öffentlichen, als auch meinen privaten Schlüssel.
Zertifikat in den Mailclient einbinden
Je nach Mailclient funktioniert das Einbinden des Zertifikates auf eine andere Art und Weise. Bei Kopano haben wir uns dafür entschieden, nicht auf den Zertifikatsstore der jeweiligen Betriebssysteme zu vertrauen – Unser Client ist plattformunabhängig und das Handling wäre je nach „Welt“ zu unterschiedlich und kompex geworden. Somit kümmern wir uns komplett selbst um die Schlüssel.
Notwendig für die Nutzung von S/MIME ist ein aktiviertes S/MIME-Plugin [5][6]. In der DeskApp oder WebApp kann das Plugin unter Einstellungen → Plugins aktiviert werden.
Ist das Plugin aktiv, so speichert Kopano die öffentlichen Zertifikate empfangener E-Mails automatisch. Diese sind wichtig, um verschlüsselte E-Mails zu versenden. Dann taucht in den Einstellungen auch die Registerkarte S/MIME auf. Hier wird das private Zertifikat – also das PFX-File – hochgeladen und mit dem beim Erstellen des Zertifikates vergebenen Passwort entsperrt. Außerdem kann man hier dieses Passwort ändern und eine Liste der gespeicherten Zertifikate einsehen.
Der Prozess des Signierens ist nun sehr einfach: Beim Erstellen einer neuen E-Mail tauchen sehr präsent zwei neue Buttons zum „Signieren“ und „Verschlüsseln“ auf. Diese machen exakt das, was sie versprechen. That‘s it.
Abschluss und Weiterführendes
Ein langer Blog für einen simplen Button. E-Mails zu signieren ist viel einfacher als die Hintergründe zu verstehen ;-). Das ist auch sehr wichtig, sonst würde es nämlich niemand tun. Für weiteren Verständnis empfehle ich auch einen Blog-Artikel [7], den meine Kollegen Bob und Mike geschrieben haben. Darin erklären sie auch, warum das Speichern der Zertifikate auf unserem Server ein guter Kompromiss zwischen 100%-iger Sicherheit und alltäglich geforderter Usability ist.
[1] https://de.wikipedia.org/wiki/Digitale_Signatur
[2] https://de.wikipedia.org/wiki/Public-Key-Infrastruktur
[3] https://www.psw-group.de/smime/
[4] https://www.comodo.com/home/email-security/security-software.php
[5] https://kopano.com/produkte/email-security/
[6] https://download.kopano.io/community/smime:/
[7] https://kopano.com/smime-description/
