P2P Verschlüsselung

WhatsApp behauptet, dass alle Nachrichten verschlüsselt sind und das alles ohne Zertifikat, PKI-Strukturen o.ä. funktioniert. Warum geht das nicht auch per Mail. Ein Versuch einer Gegenüberstelllung und ein Entwurf einer ähnlichen Umsetzung für normale Mails.

Verschlüsseln und Signieren mit Mail bisher

Bei E-Mail kennen wir schon seit Jahrzehnten die Funktion eine Nachrichten per S/MIME oder PGP zu verschlüsseln und zu signieren. Technisch ist der Prozess schon allzu oft erklärt worden. Jeder Teilnehmer hat ein Schlüsselpaar aus "Privatem" und "Öffentlichen" Schlüssel. Wer etwas mit dem öffentlichen Schlüssel einer Person verschlüsselt kann sicher sein, dass es nur der Besitzer des passenden privaten Schlüssels wieder lesen kann. Wer mit seinem privatem Schlüssel eine Mail signiert, ermöglicht dem Empfänger die Prüfung auf Unverfälschtheit hinsichtlich Absender und Inhalt. Die Kombination aus beiden erlaubt eine sichere und verifizierte Mailübertragung, unabhängig vom Mailserver selbst. Es ist eine "Ende zu Ende"-Absicherung und basiert nicht auf TLS oder andere Techniken auf dem Transport, über den der Absender oder Empfänger keine Kontrolle haben.

Da Problem dabei ist, dass zum einen der öffentliche Schlüssel zum Absender muss und er idealerweise von einer vertrauenswürdigen Zertifizierungsstelle (CA) signiert wurde. Das kostet Geld, die Rolle der CA ist auch nicht immer rühmlich und verschlüsselten Mails werden unlesbar, wenn der Empfänger seinen privaten Schlüssel verliert oder nicht auf die verschiedenen Endgeräte überträgt. Daher gibt es Gateways wie z.B. NoSpamProxy, die das komplette Zertifikat-Handling an die Grenze m Internet verlagern und damit intern die Komplexität deutlich verringern. So können auch Stellvertreter, Weiterleitungen und verschiedene Clients problemlos solche Mails verarbeiten und die Firma stellt sicher, dass ausgehende Mails entsprechend der Richtlinien verschlüsselt sind.

Das "Problem" mit den Zertifikaten ist damit aber nicht gelöst sondern nur verlagert, auch wenn der Anwender davon entlastet wird.

Verschlüsseln und Signieren bei WhatsApp

In der Anfangszeit hat WhatsApp natürlich erst einmal "Funktionen" liefern und das Backend dem Wachstum entsprechend aufbauen müssen, Da war Sicherheit erst einmal sekundär. Über die Mobilfunknummer ganz es eine ziemlich eindeutige Identität und per SMS oder Anruf eine einfache Möglichkeit der Authentifizierung. Kennworte konnte sich WhatsApp so auch noch sparen.

Aber es wurde natürlich auch bald offensichtlich, dass die Nachrichten selbst unverschlüsselt übertragen wurde. Sicher nutzte WhatsApp schon damals auch HTTPS-Verschlüsselung aber wir wissen alle, dass entsprechende Provider diese Daten auch aufbrechen können. Auch auf den Servern von WhatsApp waren die Daten am Ende des HTTPS-Tunnel wieder lesbar und weckten damit Begehrlichkeiten. Dabei macht es keinen Unterschied, ob das nun ein "demokratisches Rechtssystem" ist oder ein Tyrannenstaat oder Geheimdienste, Die die Kommunikationen überwachen wollen. Alles natürlich nur zum Wohle der Bürger. Für WhatsApp ist es aber schwer einzuordnen, welche Anfangen man stattgeben soll und welchen nicht. Wenn die Daten aber komplett verschlüsselt sind, dann gibt es auch zumindest "inhaltlich" nichts, was man weitegeben kann.

Es bleiben natürlich immer noch die "Verkehrsbeziehungen", also die Metadaten über die die Partner und Gesprächskreise ausgewertet werden können. Und dieses Daten sind teilweise sogar interessanter als die eigentlichen Nachrichten.

Mittlerweile verschlüsseln die verschiedenen WhatsApp-Clients, wenn Sie aktuell genug sind über einen proprietären Weg. Jeder Anwender generiert sich dazu quasi ein eignes Schlüsselpaar, welcher er dann an die Gegenseite übermittelt. Die Identität muss ja nicht durch eine Signatur sichergestellt werden, wenn wir davon ausgehen, dass die Rufnummer des Absenders "unfälschbar" ist.

Rein technisch denke ich, dass hier immer noch ein Man in the Middle möglich ist, zumindest wenn WhatsApp "mithilft" und beim Austausch der Schlüssel zwischen den Partnern eingrätscht oder in der App auf dem Smartphone "Zusatzfunktionen" einbaut, die z.B. in den Ländern unterschiedlich ausgespielt werden. Es wäre nicht der erste Hersteller, der seine Produkte je Zielland anpasst um den lokalen Gesetzen zu entsprechen.

Gehen wir also nun davon aus, dass ein halbwegs sicherer Schlüsselaustausch ohne Veränderungen möglich ist, dann gibt es noch zwei Themen, die bei der Verschlüsselung bearbeitet werden müssen. Vorher sollten Sie sich in Erinnerung rufen, dass es bei WhatsApp wiederrum Dinge gibt, die das Leben mit Verschlüsselung für den Hersteller einfacher machen:

  • Nur ein aktiver Client
    Anders als bei E-Mails, die Sie auf ihrem PC, Smartphone, Tablet oder per Webbrowser auf unterschiedlichen Clients "nebeneinander" lesen, können Sie WhatsApp eigentlich immer nur auf genau einem Gerät, ihrem primären Smartphone, nutzen. Das ist zwar geografische Mobilität pur aber nicht bezüglich des Clients
  • Keine Verschlüsselung von Bestandsnachrichten
    Es sind "Instant Messages" und anders, als bei E-Mails, werden die Nachrichten nach dem Empfang entschlüsselt und auch so gespeichert. Die Nachrichten sind auf dem Gerät nicht weiter mir ihrem PublicKey verschlüsselt, so dass Sie beim Verlust des eigenen Schlüssels bisher empfangene Nachrichten nicht mehr lesen können. Interessant warum kein Mailclient diese Option bietet, empfangene Nachrichten unverschlüsselt zu speichern.
  • Nur ein Client
    Der sicher größte Vorteil ist aber die Tatsache, dass die WhatsApp-Plattform auch nur mit dem WhatsApp-Client genutzt werden kann. Der Hersteller muss sich also nicht mit unterschiedlichsten Betriebssystemen, Versionen oder Zusatzprogrammen herumschlagen. Bei E-Mail gibt es eine ganze Fülle von unterschiedlichen Mailservern (Exchange, Notes, Postfix, SendMail, u.a.) und vor allem Clients. und Abrufprotokollen (POP, IMAP, ActiveSync, MAPI, EWS u.a.), die letztlich auf dem Nachrichtenformat RFC-822 aufsetzen.

Die beiden Aktionen, die bei SMIME/PGP-Benutzern immer ein Risiko bedeuten sind:

  • Umzug
    Wenn Sie das Endgerät wechseln, müssen Sie sicherstellen, dass ihre privaten Schlüssel "mit kommen". Ansonsten könnten sie ihre früher verschlüsselt empfangenen Mails selbst nicht mehr lesen. Das ist bei WhatsApp anders, da hier Mails zwar "Ende zu Ende" aber eben nur auf dem Transportweg verschlüsselt werden. Sie können ihre "alten" Nachrichten, Bilder etc. in WhatsApp einfach "sichern" und auf dem neuen System wieder herstellen. Wobei Sie dann natürlich beachten sollten, wie die Sicherung der an sich unverschlüsselten Daten selbst gegen Fremdzugriff "gesichert" wird.
  • Verlust des Schlüssels.
    Sollte ihr Schlüssel verloren gehen, dann stellen Sie sich einfach ein neues Schlüsselpaar aus und informieren ihre Kommunikationspartner darüber. Natürlich bekommen diese eine Warnung, dass sich etwas geändert hat und bei sensiblen Verbindungen sollte man schon nachfragen, ob das alles mit rechten Dingen zugeht. Viele WhatsApp-"Partner" laufen sich aber immer mal wieder über den Weg und können hier das nachholen. Das ist bei E-Mails sicher seltener der Fall

Insofern ist es auch gar nicht wichtig eine "Sicherung" des privaten Schlüssels zu haben, denn er ist nur über den Transport der Nachricht erforderlich. Die Nachricht selbst ist schon verschlüsselt, so dass sie nicht von einer durchgängigen Verschlüsselung auf dem Transport (Vergleiche STARTTLS).

Wenn das nun mit WhatsApp so einfach ist, sicher und verschlüsselt zu kommunizieren, dann frage ich mich schon, warum das per Mail nicht genauso einfach gehen sollte. Können wir nicht einfach das Verfahren entsprechend adaptieren ?

AdHoc-Verschlüsselung bei Mail

Ich denke ja, es könnte funktionieren, aber das geht nicht ohne einen Standard und erst recht nicht ohne eine breite Mitwirkung aller verschiedenen Mailclients. Und da gibt es schon eine Menge. Email ist eben nicht ein "junges" Produkt, welche keine Altlasten mit sich schleppt sondern schon in die Jahre gekommen. Aber auch dann ist es aus meiner Sicht dennoch denkbar. Ich selbst habe natürlich weder die Macht noch die Mittel so etwas zu forcieren. Aber Denkanstöße sind immer möglich und vielleicht greift sie z.B. Microsoft auf, die mit Hotmail, Outlook.com, Office 365 und dem Clients Outlook/Win, Outlook/IOS und Outlook/Android, Windows 10 Mail schon eine recht umfangreiche Anwenderzahl bedienen.

Stellen Sie sich das folgende Szenario vor.

  • Der Mail Client A erstellt automatisch ein Schlüsselpaar
    Das passiert "unbemerkt" durch den Anwender A. Natürlich könnte er per Konfiguration auch unterbinden aber per Default wäre diese Funktion "ein". Der private Schlüssel von A wird lokal gespeichert
  • Der PublicKey von A wird im Header der Mail immer mit beigefügt
    Wenn dieses Feld auf dem Transport nicht entfernt wird, dann kommt es bei jedem Empfänger entsprechend an. Für die weitere Beschreibung nennen wir einen der Empfänger  einfach "B"
  • Das kompatible Gerät beim Empfänger "erkennt" den Key und merkt ihn sich
    Ab sofort kann das Empfänger seinerseits an den Absender schon einmal verschlüsselt senden. Da er das aber auch mit seinem Schlüssel im Header tut, lernt auch A, dass er verschlüsselt senden kann.
  • Die "Partnerschaft" ist etabliert.
    Um dies zu kennzeichnen, wäre ein eigenes Icon wünschenswert. Zudem sollte das Programm ab sofort warnen, wenn eine eingehende Mail mit einem anderen Key signiert wurde.

Kling einfach und ist auch einfach. Aber es gibt natürlich Sonderfälle und andere Herausforderungen.

Sonderfälle

Anders als bei WhatsApp, was eigentlich immer eine "persönliche" Kommunikation zwischen zwei Personen oder einer Gruppe ist, gibt es bei Mail auch andere Anwendungsfälle:

  • Sonderfall Weiterleitung über Regel
    Wenn es sich um eine Regel auf dem Client handelt, dann kann der Client die Mail vorher auch dechiffrieren und dann an das Weiterleitungsziel wieder neu verschlüsselt weiterleiten. Anders wirken sich Server-Regel aus. Wenn der Server nicht damit umgehen kann, dann leitet der Crypt-Text weiter, mit dem der Empfänger nicht anfangen kann. Dazu müsste der originale Empfänger seinen Schlüssel auch an den Stellvertreter aushändigen. Denkbar aber würde natürlich die Verschlüsselung schwächen.
  • Sonderfall Stellvertreter
    Auch wenn ein Stellvertreter direkten Zugriff auf das Postfach hat,, so sieht er ohne den passenden Schlüssel nur Buchstabensalat. Das ist ja auch so beabsichtigt, aber kann in der internen Firmenkommunikation natürlich nicht gewollt sein. Für Firmen wäre also schon zu überlegen, ob man Ausnahmen auf Domainlevel einrichten kann.
  • Sonderfall Mailingliste
    Was in WhatsApp die intensiv genutzten Gruppen sind, sind bei Mailsystemen Mailinglisten und Verteiler. Die Mailingliste wird von einem eigenen Prozess  bedient, der eingehende Mails liest und wieder verteilt. Die Teilnehmer sehen quasi nicht, wer in der Liste alles enthalten ist. Der Prozess müsste natürlich für dieses Verfahren angepasst werden. Aber solange die Mailingliste selbst keinen Schlüssel mit verteilt, kann auch kein Teilnehmer verschlüsselt an die Liste senden.
  • Sonderfall Verteiler
    Eine Mal an einen "Verteiler" ist insofern knifflig, da der "Expansion Server" sich um die Entschlüsselung und Neuverschlüsselung kümmern muss. Er müsste eine eigene "Identität" haben, zumindest solange die Sender eine Mail an den "Verteiler" senden. Innerhalb einer Firma kann Outlook natürlich auch auf dem Client die Mitglieder selbst "expandieren" und die Mail mit dem Schlüsselmaterial jedes einzelnen Empfängers verschlüsseln. So macht Outlook das heute auch schon. Nicht schön aber vielleicht wäre eine Mailingliste oder ein anderes Ziel sogar besser.
  • Andere Clients (Public Folder, Teams, Office Groups)
    Neben Postfächern und Verteilern gibt es zumindest im Office 365 Umfeld noch weitere Mailempfänger. Solange diese ihrerseits aber keinen Schlüssel im Header anbieten, sendet auch niemand mittels AdHoc-Verschlüssekung

Viele Probleme lassen sich im Firmenumfeld auch hier durch ein entsprechendes Gateway "lösen", welches an der Grenze der Firma steht und als Umsetzer dient. Dann bleiben wieder die Mails intern "unverschlüsselt" mit voller Funktion innerhalb des "geschützten" Firmenverbunds aber externe Mails werden weiterhin gesichert.

Herausforderung: Mehrere Clients und Wechsel des Clients

Auch wenn die Mails auf dem primären Client entschlüsselt wieder abgelegt und damit von anderen Clients ebenfalls gelesen werden können, so gibt es bei Mail eben nicht den einen primären Client. Ein Anwender liest nach meiner Erfahrung seine Mails nicht nur auf dem PC sondern mindestens auch auf einem Smartphone. Das geht natürlich nur, wenn beide den gleichen Schlüssel nutzen.

Der ganze Prozess muss natürlich "bedienbar" bleiben und ich will es dem Anwender nicht zumuten, irgendwelche Dateien zu übertragen oder gar 4096-bit Schlüssel abzutippen. Bei einem Wechsel des Endgeräts wäre ein neuer Schlüssel ja noch tolerierbar. WhatsApp macht es ja auch so. Aber das ist keine Lösung für den Parallelbetrieb.

Wenn ich mich nicht irre, dann sollte es aber einen ganz einfachen Weg zur Übertragung des privaten Schlüsselt von der aktiven primären Instanz an eine zweite Installation geben. Ich richte meinen zweiten Mail-Client ein und als erste Aktion sende ich eine Mail an mich selbst. Im Detail:

  • Einrichten eines neuen zusätzlichen Mailclient
  • Errechnen eines "neuen" Schlüsselpaars KEY2
  • Senden einer unverschlüsselten" Mal "an mich selbst" mit dem neuen Schlüssel KEY2Publix und einer "Schlüsselanforderung
  • Der primäre Client bekommt die Mail
  • Der primäre Client fragt den Anwender, ob er gerade einen weiteren Client eingerichtet hat
    Wenn der Anwender zustimmt, dann sendet der primäre Client seinen Schlüssel KEY1PUBLIC und KEY1PRIVTE in einer mit KEY2PUBLIC verschlüsselten Mail an sich selbst
  • Der zusätzliche Client kann diese Mail lesen..
    ... und extrahiert sich das Schlüsselmaterial KEY1. Den KEY2 verwirft er
  • Nun hat auch der zusätzliche Client das gleiche Schlüsselmaterial wie der bislang primäre Clients

Das kann der Anwender immer und immer wieder machen. Zur weiteren Absicherung könnte der zusätzliche Client natürlich noch eine Information anzeigen, die der Anwender auf dem primären Client vergleichen kann. Zukünftig wäre auch eine Übertragung per NFC, Bluetooth o.ä. denkbar aber das würde ich ganz hinten anstellen.

Angriffsflächen

Natürlich muss ich mir auch überlegen, welche Angriffsvektoren es gibt. Die erste Kommunikation und die generelle Veröffentlichung des eigenen Schlüssels über eine unverschlüsselte Mail öffnet natürlich jeden Angriff erst einmal Tür und Tor. Ein System, welches sich in den Transportweg einklemmt, kann z.B.

  • Den Header mit dem Public Key unterdrücken
    Der Empfänger bekommt dann gar nicht mit, dass die Gegenseite das Verfahren unterstützt. Eine einfache Lösung gibt es hier nicht. Ein solches Gateway könnte ja auch die SMIME/PGP-Schlüssel herausfischen und signierte Mails wieder "entsignieren". Es hängt letztlich am Anwender, ob er auf die Zeichen achtet, wenn eine Mail unsigniert und unverschlüsselt ankommt und daher z.B. ein "Schloss" fehlt
  • "Man in the Middle" (MITM) mit Key ersetzen
    Wenn das System zuverlässig zwischen zwei Kommunikationspartnern ist, dann könnte es in beide Richtungen die Schlüssel jeweils durch eigene Werte ersetzen und damit beiden eine "vertrauenswürdige Verbindung" vorgaukeln. Das ist tatsächlich so denkbar und ich wüsste auch nicht, wie WhatsApp dies anders löst. Daher dürfte WhatsApp auch unterscheiden, ob ein Schlüssel verifiziert ist oder nicht. Die Anwender könnten sich auf einem anderen Weg, z.B. per Telefon o.ä. den Hashwert überprüfen und solche Unstimmigkeiten erkennen.
  • KeyExport durch "Anforderung"
    Ein Angreifer könnte z.B.: so tun., dass er ein zusätzlicher Client wäre und ihr primäres Schlüsselmaterial anfordert. Daher darf der primäre Client diese Information erst nach Rückfrage des Anwenders rausrücken.
  • Störung durch Fremd-Schlüsselpaar
    Natürlich könnte ein Angreifer sich auch einfach als Gegenstelle ausgeben und einen anderen Schlüssel senden. Solange eine Domäne nicht per SFP, SenderID, DKIM o.ä. verifizierbar ist, ist das Risiko hoch, dass das Opfer den neuen Schlüssel akzeptiert und auf die Mail mit der Bitte um Informationen antwortet. Der Angreifer kann die Mail abfangen und lesen. Der eigentliche Empfänger bekommt davon erst bei den nachfolgenden Mails mit, die er dann natürlich nicht mehr entschlüsseln kann.

Es gibt also schon Risiken, die zum Teil auch der dezentralen Organisation der Schlüssel geschuldet sind. Es gibt erst einmal keine "Signierstelle", die einen Schlüssel entsprechend unterschreibt und damit vertrauenswürdig macht.

Proxy statt Client Support

Ich denke es wäre vermessen zu erwarten, dass in naher Zukunft alle Clients eine solche Spezifikation unterstützen würde. Zudem gibt es genauso viele "Altsysteme", die vielleicht gar keine Updates mehr bekommen. Ich habe weiter oben schon geschrieben, dass Gateways für Firmen eine solche Integration sehr einfach bereit stellen könnten. Aber wie gehen 1und1, Outlook.com, HotMail, Yahoo, Google-Mail und andere Dienste damit um und wie kann ein Anwender diese Dienste damit verwenden, wenn weder der eigene Client dies unterstützt noch der Provider ein entsprechendes Gateway integriert.

Die Lösung könnte in Proxy zwischen Client und Server sein, wie er heute schon z.B. von Antiviren-Programmen gerne eingebaut wird, um Mails beim Versand per SMTP oder Empfang per IMAP/POP3 zu scannen. Ein solcher Proxy könnte auf dem Client, vorzugsweise natürlich dann Windows oder Linux, selbst laufen. Aber auch mobile Clients sind nicht automatisch ausgeschlossen. Ein Proxy als Hosted Service könnte die Verbindung entsprechend sichern. Wobei dann natürlich das "Schlüsselmaterial" auf eben diesem System liegen würde. Wir sprechen hier aber von einer Übergangsphase, um die Technik zu nutzen, bis die Mehrheit der Clients eine direkte Integration bieten.

Offen wäre bei einem Proxy nach meinem Verständnis aber, wie mit Interaktion des Clients umgegangen werden muss. Es gibt ja Fälle, in denen der Anwender gefragt wird, wie er sich verhalten will, z.B. wenn sich der Schlüssel eines Teilnehmers ändert.

Könnte es was werden ?

Anders als bei WhatsApp ist E-Mail ein System mit vielen Mitspielern und Komponenten. Die Anwender arbeiten teils schon Jahrzehnte mit ihrem System und jede Veränderung ist erst einmal schwierig. Auf der anderen Seite gibt es ja keinen Zwang oder Pflicht. Jeder Nutzer entscheidet selbst, ob er einen entsprechenden Client nutzt und den Kommunikationspartnern einen Schlüssel anbietet. Es kostet nicht, es gibt keine Abhängigkeit von einer PKI und da die Mail nach dem Empfang quasi entschlüsselt abgelegt wird, gibt es auch keinen Stress mit Key Recovery. Es obliegt dem Anwender seine Ablage natürlich entsprechend zu schützen (Geräteverschlüsselung, Kennwort auf PST-Datei o.ä.) Für Firmen kann es ganz schnell passende Lösungen geben.

Wo bleibt der Standard ?

Mir ist noch nicht bekannt, ob es ähnliche Überlegungen schon gibt oder es sogar schon ein RFC dafür gibt. Ich bin für jede Rückmeldung diesbezüglich dankbar. Ansonsten würde ich einfach mal die obige Beschreibung als Blaupause nehmen:

  1. Man errechnet ein Schlüsselpaar (z.B. 4099bit = 512Byte)
  2. Den öffentlichen Schlüssel addiert man BASE64-codiert als Header in jede Mail
    z.B. mit einem "X-Header "x-p2pkey: ...."
  3. Eingehende Mails prüft man auf den Schlüssel und fragt
    1. Rückfrage, ob der Key verwendet werden soll. Insbesondere bei Schlüsseltausch
    2. ggfls. Update der lokalen Key-Speichers
    3. Anzeige des Status an der Mail
    4. Entschlüsseln der Mail und Ablage in entschlüsselter Form
  4. Migration des eigenen Keys
    Wenn die Mail "angeblich" von mir kommt und ein Key-Request ist, dann frage ich den Anwender um Erlaubnis zur Herausgabe des Schlüssels an mich

Was ist ihre Meinung zu dem Thema?. Denkbar wäre auf die Schnelle ein Outlook Add-on, welches diese Funktion einfach einbaut. Über einen IMAP4-Proxy könnten auch viele mobile Clients davon profitieren und Firmen sollten schauen, dass ihr Gateway ihren Anwendern die Arbeit abnimmt. Einzig die Anwender mit einem Browser sind hier noch Anwender zweiter Klasse, da der Schlüssel ja irgendwie auf den Client kommen muss, damit der Browser die Informationen entschlüsselt. Hier müsste dann schon der Provider "mithelfen". Das Problem ist aber mit SMIME/PGP auch nicht viel anders zu lösen. Eine serverseitige Ent-/Verschlüsselung ist immer ein Vertrauensbeweis für den Provider. das ist aber heute auch schon der Fall, wenn Mails gänzlich unverschlüsselt im Postfach liegen. Der hier vorgestellte Ansatz hat das Ziel eine "massentaugliche" Verschlüsselung und Signierung auf dem Transportweg zu beschrieben. Eine Verschlüsselung im Postfach führt letztlich wieder zur Problematik von SMIME/PGP mit verschlüsselten Mails, die beim Verlust des Schlüssels nicht mehr lesbar sind.

Update. Anscheinend gibt es mit "Autocrypt" (https://autocrypt.org/index.html) einen vergleichbaren Ansatz. Ich beobachte das mal weiter

Weitere Links