Schlagwort: Verschlüsselung

Ende-zu-Ende-Verschlüsselung ist heute bei E-Mails faktisch nicht vorhanden. Es gibt dafür zwei große Konzepte bzw. Standards: PGP (inline/MIME) und S/MIME. Doch sowohl mangels intuitiver Verwendung in den gängigsten E-Mail-Anwendungen als auch aufgrund des schlechten Rufs – hauptsächlich in Bezug auf Benutzbarkeit, aber auch auf Sicherheit – finden sie keine große Akzeptanz.

Dann halt WhatsApp?

Die gängigen Messenger sind inzwischen deutlich sicherer als E-Mail. Viele Organisationen scheuen zudem den Aufwand, eine Ende-zu-Ende-Verschlüsselung einzuführen. Sie fürchten einerseits die schlechte Außenwirkung, wenn E-Mails erst nach organisatorischem Aufwand ausgetauscht werden können (Schlüsselaustausch), und andererseits den Verlust von E-Mail-Historie (Backups), wenn Schlüsselmaterial verlorengeht. Auch das Einbinden von Spam- und Viren-Scanner ist keine einfache Angelegenheit. Es herrscht noch immer das Mantra: „Eine E-Mail muss ankommen und vom Empfänger gelesen werden können, egal wie.“

Stellt eine Organisation die Möglichkeit, E-Mails verschlüsselt zu senden, als Option zur Verfügung, greifen die Mitarbeiterinnen und Mitarbeiter nur sehr selten darauf zurück. Oft sind es vermeintlich nur „nicht-sensible“ Informationen, die ausgetauscht werden. Später, bei kritischeren Daten, heißt es häufig, einmal sei keinmal – bis dann hochsensible Informationen zeitkritisch ausgetauscht werden müssen und keine Zeit mehr für einen Schlüsselaustausch ist.

Pfeiler der Verschlüsselung

Eine gute E-Mail-Verschlüsselung basiert auf drei Pfeilern:

1. Sichere Software,
2. Schulung (zur richtigen Verwendung) und
3. Sensibilisierung (zur Motivation)

Schwächelt nur ein Pfeiler, bricht die ganze Konstruktion zusammen. Gerade die dritte Säule hat einen großen Feind: den Frust. Zu häufig kommt es vor, dass die Gegenseite aus verschiedenen Gründen nicht in der Lage ist, verschlüsselte E-Mail-Kommunikation durchzuführen, während eine unverschlüsselte E-Mail einfach funktioniert.

„Wir haben ein E-Mail-Gateway, das kann das alles.“, ist ein Lösungsansatz, den man öfters mal hört. Es ist richtig, E-Mail-Gateways adressieren einige Schwächen gängiger E-Mail-Anwendungen. Aber intuitive Verwendung ist auch hier Fehlanzeige. Meistens gilt auch hier: Die E-Mail muss raus – und der Schlüsselaustausch verbleibt beim Endanwender. Im Zweifel wird die E-Mail dann doch unverschlüsselt versandt.

Ist eine Verschlüsselung nur optional, kann man aus Versehen unverschlüsselt versenden oder die Notwendigkeit verschlüsselt zu versenden solange hinauszögern, bis eine vertrauliche E-Mail aus zeitlichen Gründen unverschlüsselt versendet werden muss.

Zentrale Qual: S/MIME

S/MIME ist vergleichbar mit HTTPS in folgender Hinsicht: Es braucht eine Welt umspannendes Netz aus PKIs (Public-Key-Infrastrukturen), um gut zu funktionieren.

Was S/MIME im Gegensatz zu HTTPS fehlt, ist ein Schlüsselaustausch-Element. Beim Entwurf von S/MIME (1995) stellte man sich einen Verzeichnisdienst oder eine Verzeichnisdienst-Infrastruktur vor, hatte jedoch die Rechnung ohne den Datenschutz gemacht. Die Alternative zu einem Verzeichnis, sich gegenseitig signierte E-Mails zu senden, kann schnell zu einem größeren Delay führen, wenn nicht beide Parteien gleichzeitig am Rechner sitzen.

Was S/MIME mit HTTPS gemeinsam hat, es werden vertrauenswürdige Zertifizierungsstellen benötigt. Man kann eine eigene Zertifizierungsstelle aufbauen, doch dann hat man das Problem, diese als vertrauenswürdig an alle (auch potentielle) Kommunikationspartner zu verteilen. Hier gibt es keinen einheitlich definierten Weg. Oder man wendet sich an die wenigen öffentlich anerkannten Zertifizierungsstellen, die neben Server-Zertifikaten auch Personen-Zertifikate ausstellen. Diese lassen sich dies jedoch gut bezahlen, vor allem im Vergleich zu Server-Zertifikaten, wo der öffentliche Dienst Let’s Encrypt für einen drastischen Preisverfall gesorgt hat. Ob aber eine öffentlich anerkannte Zertifizierungsstelle wirklich gute Arbeit leistet, ist auch nicht immer sichergestellt. Hier gibt es im Bereich der Server-Zertifikate viele Negativ-Beispiele. Nicht umsonst drohen Größen wie Google, Mozilla und Apple mit dem Rauswurf von Zertifizierungsstellen, wenn diese einmal wieder „Blödsinn“ gemacht haben. Nur gibt es eine solche Marktmacht bei S/MIME nicht.

Pretty Bad: PGP

PGP hat von Anfang an auf eine PKI verzichten wollen, kommt aber ohne einen (dezentralen) Verzeichnisdienst auch nicht wirklich aus. Und die Idee eines Web-Of-Trust kann man weitestgehend als gescheitert betrachten, da braucht man noch nicht einmal die Datenschutz-Karte zu zücken:

„Ach ja, ich konnte Deine E-Mail nicht öffnen“ – und das Tage oder Wochen nach dem Versenden der E-Mail und erst auf Nachfrage. Trotz Schlüsselaustauschs. Was ist passiert? Der Empfänger hat seinen Schlüssel „verloren“, sieht aber keine Notwendigkeit zu handeln, weder proaktiv noch reaktiv. Solche E-Mail-Empfänger adressieren ganz klar den Feind „Frust“.

Transportverschlüsselung als Rettung?

„Aber was ist mit der Transportverschlüsselung, da kann doch dann auch keiner mitlesen?“ Das Hauptproblem auch hier: Eine E-Mail muss ankommen und vom Empfänger gelesen werden können, egal wie. Schlägt beim Versenden die Zertifikatsprüfung fehlt, wird trotzdem übertragen. Bietet die Gegenstelle keine Verschlüsselung an, wird trotzdem übertragen. Interessanterweise ist es immer erstmal ein Fehler des Senders, wenn eine E-Mail nicht versendet werden kann, auch wenn die Gegenstelle sich nicht an geltende Normen hält. Auch das Thema Sender-Authentizität wird von der Transportverschlüsselung nicht geleistet.