Warum E-Mail-Verschlüsselung nach PGP gar nicht so einfach ist

Und wie übertragen wir das ganze jetzt auf E-Mails? Da fangen die Probleme an. Mit TextSecure, Threeman und iMessage funktioniert das alles wunderbar, denn:

  • Es gibt einen zentralen Schlüsselserver
  • Jeder hat nur ein Endgerät (sein Smartphone)
  • Es muss nicht abwärtskompatibel sein

Bei E-Mail ist das anders. E-Mail ist dezentral, es gibt keine zentralen Server auf denen man Schlüssel lagern könnte. Natürlich könnte ein Anbieter den einrichten, aber damit würde das E-Mail-Netz ein inkompatible Teile zerfallen, wie es aktuell mit Messengern der Fall ist. E-Mails werden auf vielen Geräten gelesen, auch im Web. Aktuell ist es z.B. so, das es bei Threema zwar möglich ist, eine Identität (also den Private-Key) auf ein anderes Gerät zu übertragen, aber das benutzt fast keiner. Die Leute erstellen sich einfach einen neuen Key, wenn sie das Smartphone wechseln. Das ist da kein so großes Problem, weil das nicht so häufig vorkommt, und die Leute immer nur ein Gerät gleichzeitig benutzen. Sie müssten dann zwar von Ihren Gesprächspartnern neu verifiziert werden, aber das macht vermutlich eh kaum einer. Bei E-Mail geht das nicht. Die Leute benutzen viele Geräte parallel, folglich müssen die zu einer Identität gekoppelt werden. Schlussendlich muss das ganze abwärtskompatibel sein. Natürlich kann ich zu Leuten, die keine verschlüsselten Mail annehmen, einfach normale senden, aber was ist mit dem Mails in meinem Posteingang? Wenn ich die dort verschlüsselt speichere, komme ich nur daran, wenn man mein Gerät die Verschlüsselung auch unterstützt. Sie dort wieder unverschlüsselt zu speichern macht aber keinen wirklichen Sinn.

Was war nun also meine Idee? Ich dachte mir folgendes:

Es gibt keine zentralen Keyserver, stattdessen wird der Publickey im DNS gespeichert. Über DNSSEC kann ich mir sogar sicher sein, dass er nicht manipuliert wurde (sogar ohne, dass ich mit dem anderen einen Fingerprint ausgetauscht habe!) – zumindest, wenn ich dem Serverbetreiber vertraue. Es muss aber auch ohne DNSSEC funktionieren, damit es auch jetzt schon läuft. Natürlich können die Antworten dann manipuliert werden, aber eben nur aktiv. Warum DNS? Es „funktioniert einfach“, ist mit DNSSEC potenziell sehr sicher und wer die DNS-Einträge eines Mail-Servers ändern kann hat vermutlich auch Zugriff auf die Mail-Accounts dieses Servers, es kann also nicht einfach jeder Keys ausstellen. (Die Idee ist vom Grundsatz her natürlich komplett von DANE geklaut, nur eben ohne die Forderung nach DNSSEC, damit es nicht nur theoretisch benutzt werden kann!).

Gut, benutzen wir also DNS für die dezentrale Verwaltung der Schlüssel. Jetzt müssen aber auch noch die „halben“ Schlüssel im DNS hinterlegt werden, und wenn die Mal alle sein sollten, muss ich neue generieren. (Theoretisch muss ich sogar sicherstellen, dass ein „halber“ Schlüssel nur ein Mal verwendet wird, was über das DNS natürlich nicht machbar ist.) Es muss also ein Protokoll her, mit dem die Mail-Clients das DNS automatisch ändern können. Damit das ganze möglichst einfach bleibt, würde ich das als SMTP-Extension einbauen. Und schon gibt es wieder Probleme: Vielleicht bekommt man einen großem Mail-Anbieter dazu, ein solches Protokoll zu unterstützen. Alle aber kaum. Dazu kommen die ganzen kleinen selbst gehosteten Mail-Server, die vielleicht gar keinen eigenen DNS-Server haben, sondern den von einem Provider benutzen… Ein Alternative wäre hier natürlich ein eigenes Protokoll, vielleicht mit Firmen, die Server dafür anbieten (unabhängig vom Mail-Account). Dann bleibt nur das Problem zu einer Mail-Adresse den richtigen Server zu finden, ohne wieder in das aktuelle Problem von PGP zu rennen, dass jeder für jede Mail-Adresse Keys ausstellen kann (wenn die Keys im DNS liegen geht das nicht!). Und auch hier ist natürlich die Gefahr da, dass das Netz in Teile zerfällt, kommerzielle Anbieter sind ja meistens nicht so begeistert von Interoperabilität mit Konkurrenten.

Ein weiteres Problem ist das Management des privaten Keys. Da E-Mail auf vielen Endgeräten benutzt wird (und potenziell auch nur kurz – siehe Webmail), kann es nicht pro Endgerät einen Key geben. Man kann den Benutzer aber nicht damit belasten, den Key zu verwalten. Wo also hin mit dem Key? Hier war meine Idee, den auch im DNS zu speichern. Auch dafür müsste es dann ein Protokoll geben, wobei der Key sich ja selten ändert, sodass es bei kleinen Installationen vielleicht möglich ist, den Key selber dort manuell einzutragen. (Wer einen eigenen Mail-Server betreibt, kann das). Natürlich ist es nicht so intelligent, den Private-Key im öffentlichen DNS zu speichern, dass ist mir schon klar. Natürlich wäre der Key verschlüsselt (leider wird es wohl das gleiche Passwort wie das für den Mail-Account sein müssen, weil die Leute das Passwort sonst vergessen). Um zu verhindern, dass massiv Bruteforce Angriffe gefahren werden, könnte man die Keys „verstecken“: Der Domainname, unter dem der Key zu finden ist, ist ein bcrypt-Hash des Passworts mit einem sehr hohen Work-Faktor (da er ja nur bei der Einrichtung eines neuen Gerätes gebraucht wird). Auf diese Weise kann man nicht einfach Keys abgreifen (weil sie eben unter fhzsfgsdfbszdfgsifgsfsf.info_at_niklas-rother.de.mailcrypto.niklas-rother.de liegen, und niemand den ersten Part erraten kann. Ist vielleicht noch die Lösung mit den wenigsten Haken, aber so richtig super klingt das auch alles nicht.

Also, warum kann man tolle verschlüsselnde Messenger machen, aber keine tolle E-Mail Verschlüsselung? E-Mail

  • ist dezentral
  • wird auf vielen, wechselnden Endgeräten gleichzeitig benutzt (speziell auch im Web!)
  • muss abwärtskompatibel zu alten Clients sein

Das sind meiner Meinung nach genau die Punkte, die E-Mail von Messengern unterscheiden, und damit leider einfache Verschlüsselung aktuell unmöglich machen. Ich bin aber der Überzeugung, dass es intelligente Lösungen für diese Probleme gibt!

Schreibe einen Kommentar

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