Autocrypt für KMail auf gutem Weg

Das Verschlüsseln von E-Mails in den E-Mail-Clients muss einfacher sein, soll es jemals zum Standard werden. Eines der vielen Projekte der NLnet Foundation ist, die Vereinfachung der Verschlüsselung in KMail zu fördern. Das Mittel der Wahl, um dies zu erreichen heißt Autocrypt, eine offene Spezifikation für E-Mail-Verschlüsselung, die unter der Haube OpenPGP und andere E-Mail-Standards verwendet. Autocrypt spezifiziert dabei, wie E-Mail-Programme Verschlüsselungsmöglichkeiten bei regulären E-Mails aushandeln.

Autocrypt handelt Verschlüsselung aus

Autocrypt erfordert nahezu keine Benutzerinteraktion. Es führt den benötigten Schlüsselaustausch transparent im Hintergrund durch und übernimmt die Schlüsselverwaltung automatisch. Dazu verwendet es Protected Headers, ein Protokoll, um Mail-Header im verschlüsselten Mailteil mitzusenden. Der Absender-Schlüssel ist ein separater Header, damit opportunistic mode funktioniert. Autocrypt-fähige Mail-Apps funktionieren mit jedem E-Mail-Anbieter und verwenden bestehende E-Mail-Adressen. Das Verfahren ist aber nicht unumstritten, wie eine Abhandlung im Privacy-Handbuch belegt.

Integration in Kontact-Suite

KDE-Entwickler Sandro Knauß hat in mehrwöchiger Arbeit die Grundlagen gelegt, um Autocrypt für KMail in der KDEPIM-Codebasis zu verankern und so für KMail zugänglich zu machen. In seinem Blog beschreibt Knauß die notwendigen Schritte, die nötig waren, um das zu erreichen. Der derzeit erreichte Stand ermöglicht:

  • das Synchronisieren des Autocrypt-Speichers beim Lesen von Mails
  • das Senden von Mails an Benutzer, die nur Autocrypt-Schlüssel haben
  • das Hinzufügen des Schlüssels zum Autocrypt-Header und Hinzufügen eines Gossip-Headers, falls erforderlich. (Gossip-Header für Gruppen-Mails sind in der Spezifikation erläutert.)

Was noch zu tun ist:

  • das Erstellen und Verarbeiten von Setup-Nachrichten
  • eine Möglichkeit, private Schlüssel zwischen den eigenen Geräten zu übertragen
  • das Erkennen, ob ein Autocrypt-Schlüssel beim Schreiben der Mail vorhanden ist. Derzeit wird der Empfänger so dargestellt, als ob keine Verschlüsselung möglich wäre
  • die Verschlüsselung muss derzeit explizit angefordert werden
  • keine Unterstützung für die im Header möglichen prefer-encrypt-Einstellungen
  • Signaturen von Mails können noch nicht gegen einen Autocrypt-Schlüssel geprüft werden

Die nächsten Schritte sind die Fertigstellung der fehlenden Teile und die Strukturverbesserung der Krypto-Unterstützung in der Kontact-Suite. Derzeit ist noch unklar, ob die Implementation für eine Veröffentlichung im Rahmen der KDE Applications 21.04 am 13. Mai stabil genug sein wird.

Kommentare

2 Antworten zu „Autocrypt für KMail auf gutem Weg“

  1. Avatar von Der Diktator
    Der Diktator

    Was noch fehlt ist die Verschleierung von Sender und Empfänger damit die Frau in der Mitte nicht nur den Inhalt der Nachricht nicht erfährt sondern auch weder den Sender noch Empfänger erkennen kann. So wie Tor nur für email. (oder gibt es das schon?)

    1. Avatar von Nick
      Nick

      So funktioniert E-Mail nicht. Man kann eine extrem antiquierte Technologie wie die E-Mail, nicht ohne erhebliche Nachteile an die Standards moderner Kryptographie angleichen. Es ist mehr als Zeit zu realisieren das die E-Mail keine Zukunft hat, und die Absicherung dieser schlicht unsinnig ist. Auch der OpenPGP-Standard ist streng genommen kaputt, und erfüllt nicht mal im mindesten die Anforderungen an moderne und sichere Kryptographie. Unter anderem in diesem Blog (https://latacora.micro.blog/2019/07/16/the-pgp-problem.html), wird die Problematik recht gut erklärt, und darüber hinaus auf empfehlenswerte moderne Alternativen, für die E-Mail und OpenPGP hinweisen. Und apropos OpenPGP-Standard, so stellt ja gerade GnuPG die Referenzimplementierung dessen dar, die für sich schon mit erheblichen Mängeln glänzt. Zum einen währen da die schier endlosen Optionen, von denen realistisch betrachtet über 90% kaum bis niemals genutzt werden. Alleine das zu pflegen ist wahnsinnig, und schafft eine abschreckende Komplexität die Nutzer buchstäblich erschlägt. Von der Angriffsfläche mal ganz abgesehen. Zudem kommt die mangelhafte Codequalität von GnuPG selbst, und die anhaltende Ignoranz seitens der Entwickler bestehende Probleme, wie die geringe Freundlichkeit auf der Mailingliste, dass sture ablehnen von Verbesserungen für eine moderne wie auch für andere einladende Entwicklung, als auch trivial via Compiler und Fuzzing auffindbare Bugs und Sicherheitslücken anzugehen. Auch die Weiterentwicklung des OpenPGP-Standard stagniert schon Ewigkeiten, da die Verantwortlichen gewissermaßen zerstritten sind und unterschiedliche Vorstellungen haben. Und das obwohl das vor gut 20 Jahren schon hätte passieren müssen, und OpenPGP bis heute immer weniger attraktiv gemacht hat. Wer heutzutage Software schreibt und an zeitgemäßer Kryptographie interessiert ist, denkt an viele Optionen aber ganz gewiss nicht an OpenPGP. Diese ganzen Initiativen OpenPGP in Verbindung mit der E-Mail einfacher zugänglich zu machen, können letztlich nur scheitern.

Schreibe einen Kommentar

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