Ende zu Ende Verschlüsselung

Wenn es um die Sicherheit von E-Mails geht, fällt schnell der Begriff einer "Ende zu Ende"-Verschlüsselung und anscheinend interpretieren insbesondere Behörden und sogar Anwaltskammern diesen Betriff sehr "kreativ". Ich verstehe darunter eine Verschlüsselung vom Einflussbereich des Absenders bis zum Einflussbereich des Empfänger ohne Wenn und Aber. Als Ende an meiner Seite sehe ich die Haustür nach draußen und nicht erst mein Schreibtisch. Quasi ein verschlossener ungeöffneter Postbrief auf den Weg in den Firmenbriefkasten. Natürlich kann mein Sekretariat den Brief "im Auftrag" öffnen.

Eine "Umschlüsselung", wie dies bei De-Mail und beim beA - Besonderes elektronisches Anwaltspostfach integriert ist, verträgt sich aus meiner Sicht nicht mit dem Ende zu Ende Ansatz. Ich habe daher eine Kurzfassung zum Thema Verschlüsselung mit unterschiedlichen Ansätzen als kleinen Vortrag zusammen gestellt.

Diese Seite gibt es auch als Video
https://youtu.be/3AIQpDlm2EQ

Symmetrische Verschlüsselung

Wir fangen erst einmal einfach an. Die einfachste Option eine Information gegen fremden Zugriff zu sichern ist ein Kennwort auf das Dokument oder z.B. das Packen als ZIP-Archiv mit einen Kennwort. So kann das Dokument nur von jemandem gelesen werden, der das Kennwort kennt. Wenn das Kennwort "lang" genug ist, ist der Aufwand dieses per Brute Force zu knacken zu hoch als dass es sich lohnen würde.

Das Problem bei der symmetrischen Verschlüsselung ist natürlich, dass das Kennwort zum Empfänger des verschlüsselten Dokuments kommen muss und der Empfänger nicht prüfen kann, ob das Dokument von ihnen stammt. Ein "sicherer Weg" für das Kennwort muss gefunden werden.

Es gibt noch andere Einschränkungen. Wenn Sie ein Dokument an mehrere Personen senden, kennen letztlich alle das gleiche Kennwort. Damit verbietet es sich das Kennwort häufiger zu verwenden. Je mehr Dokumente sie also verschlüsselt senden und empfangen, desto länger wird ihre Kennwortliste, die sie irgendwo speichern werden.

Die symmetrische Verschlüsselung ist an sich ganz in Ordnung und sicher, wenn das Kennwort pro Dokument einmalig und komplex bzw. lang genug ist. Merken wir und das für später.

Asymmetrische Verschlüsselung

Sicher haben Sie schon mal etwas von RSA gehört. Die drei Buchstaben stehen für die Familiennamen der Mathematiker Rivest, Shamir und Adleman, die um das Jahr 1976 eine mathematische Theorie der Herren Whitfield Diffie und Martin Hellman überprüft haben. Sie sind dabei auf eine Formel gestoßen, mit der eine Information mit einem Schlüssel codiert werden kann und ein passender zweiter Schlüssel die Decodierung erlaubt hat. Es gibt also ein Schlüsselpaar, bei denen man einen Schlüssel auch nicht aus seinem Partner herleiten kann.

Damit war die Grundlage für das RSA-Verfahren geschaffen. Jeder Teilnehmer errechnet für sich so ein Schlüsselpaar, bei dem Zufallszahlen und Primzahlen mit eine Rolle spielen. Einer der beiden Schlüssel wird dabei zum "privaten Key" bestimmt und verlässt nicht die Umgebung des Inhabers. Der andere Schlüssel wird idealerweise von einer Zertifizierungsstelle signiert und kann nun öffentlich gemacht werden. Wenn Sie eine Mail mit Outlook digital signieren, dann hängt Outlook einfach dieses Zertifikat mit an, so das immer mehr Empfänger nun ihren öffentlichen Schlüssel haben

Die zu schützende Information wird nun vor der Übertragung mit dem öffentlichen Schlüssel des Empfängers verschlüsselt und versendet. Der Empfänger hat den für die Entschlüsselung erforderlichen privaten Schlüssel. Niemand sonst kann die Information wieder lesbar machen.

Signierung von Informationen

Aber mit dem Verfahren können wir auch beweisen, dass die Information auf dem Weg nicht verändert wurde und der Absender nicht gefälscht ist. Dieser Prozess nennt man Signierung. Dabei wird eine Prüfsumme über die Information errechnet und diese mit dem privaten Schlüssel des Absenders verschlüsselt. Der Inhalt selbst wird bei einer reinen Signierung nicht verschlüsselt. Der Empfänger kann den Inhalt lesen und den angeblichen Absender ermitteln. Er nimmt nun den öffentlichen Schlüssel des Absender, der ihm schon vorliegt oder als signiertes Zertifikat mit gesendet wurde und dechiffriert damit die angehängte verschlüsselte Prüfsumme. Wenn diese Prüfsumme mit der ebenfalls errechneten Prüfsumme über die Information übereinstimmt, kann der Empfänger sicherstellen, dass nichts verändert wurde und der Absender authentisch ist.

Verschlüsselte und signierte Mails

Bei einer verschlüsselten Mail wird nun allerdings nicht die komplette Mail per RSA verschlüsselt. Das kostet zu viel CPU-Zeit und sobald mehr als ein Empfänger die Information erhalten muss, müssten lauter einzelne Mails gesendet werden. Bei verschlüsselten Mails nutzen die Programme wieder eine symmetrische Verschlüsselung (DES, 3DES u.a.) mit einem zufälligen Kennwort. Nur das Kennwort der symmetrischen Verschlüsselung wird per RSA chiffriert und angefügt.

So kann eine Mail einmal verschlüsselt werden und dieses Kennwort wird einfach mit jedem Public Key eines jeden Empfängers an die Mail mit angehängt. Der Empfänger öffnet dann einfach den Safe mit seinem passenden privaten Schlüssel und entnimmt das Kennwort für die symmetrische Dechiffrierung. Zudem wird der gesamte Inhalte mittels Prüfsumme signiert.

Ende zu Ende Verschlüsselung

Wenn Sie als Anwender nun einen kompatiblen Client nutzen, ein Schlüsselpaar errechnet und den öffentlichen Schlüssel verteilt haben und auch ihre Gegenüber die Vorarbeiten geleistet haben, können Sie direkt signieren und Verschlüsseln. Noch mal zur Sicherheit. Allein zum Signieren reicht es, wenn Sie als Absender ein Schlüsselpaar mit Zertifikat haben. Wer verschlüsseln möchte, braucht vorab den öffentlichen Schlüssel aller Empfänger.

Für alle Zwischenstationen ist die Mail allerdings einfach nur eine Mail mit etwas Buchstabensalat im Body und verschiedenen Anlagen. Sie müssen als auf ihrem Mailserver und anderen Relays keine Veränderungen vornehmen. Das System ist sehr sicher und es gibt aktuell keinen bekannten Angriffvektor auf dem Übertragungsweg. Allerdings sollten sich die Endpunkte natürlich nicht ihre Schlüssel entwenden lassen oder eine Schadsoftware leitet die Information beim Versand vor der Verschlüsselung oder beim Empfang nach der Dechiffrierung aus.

Ehe Sie nun aber zur Tat schreiten, sollten Sie all die Einschränkungen kennen, die es insbesondere in Firmenumfeldern gibt aber auch beim privaten Einsatz sehr schnell nach hinten los gehen können.

Da die Information sowohl beim Absender als auch Empfänger komplett verschlüsselt ist, sind alle Funktionen auf dem Transport nicht mehr möglich. Wenn ihre Stellvertretung keinen Zugriff auf ihren privaten Schlüssel hat, kann Sie ihre Mails nicht in ihrem Auftrag bearbeiten. Auch andere Automatismen für eingehende Mails (Regeln, Archiv) und insbesondere Spamfilter und Virenschutz sind eingeschränkt oder gar nicht wirksam. Archivprogramme können solche Mails ablegen aber ohne den privaten Schlüssel sind sie nicht lesbar. Auch der Versender unterliegt Einschränkungen. Das automatische Anhängen einer Signatur oder Disclaimers auf dem Transport würde die Signatur einer Mail ungültig machen.

Zuletzt könnte der Einsatz von SMIME/PGP auch auf den Clients zu einem erhöhten Aufwand durch die Komplexität führen. Clients, die SMIME/PGP nicht unterstützen, könnten nicht mehr genutzt werden. Und selbst die Arbeit mit mehreren Clients (PC, Terminalserver, Webbrowser, Smartphone, Tablet) ist eingeschränkt, da Sie ihnen privaten Schlüssels ihre Mails nicht lesen können. Der Verlust des privaten Schlüssel verhindert, dass Sie an bereits empfangene Mails kommen. Key Recovery ist eine wichtige Komponente in dem Bild, die beantwortet werden muss

Reicht TLS-Verschlüsselung?

Exchange und andere Mailserver verschlüsseln auch den Transportweg. Sie können sogar über eine Konfiguration vorschreiben, dass Mails zwingen per SMTP/TLS übertragen werden. So sperren Sie zumindest Mitlauscher aus, die auf dem Kabel spionieren. Das klappt natürlich nur, wenn Sie das Zertifikat der Gegenseite überprüfen.

Allerdings ist es auch nur eine Punkt-zu-Punkt-Verschlüsselung zwischen zwei Zwischenstellen. Jeder Smarthost, Mailserver, Relay, Proxy etc. terminiert die Verbindung und baut eine neue Verbindung zum nächsten Hop auf. Damit ist klar, dass der Admin über den Server dort solche Mails mitlesen kann. Zudem haben Sie als Absender keine Kontrolle darüber, dass jede Teilstrecke zwingend verschlüsselt ist.

TLS-Verschlüsselung ist also nur ein zusätzlicher Schutz und kann z.B. zur Identifizierung von entfernten Gegenstellen genutzt werden. TLS sollte natürlich immer dann genutzt werden, wenn Anmeldedaten übertragen werden. Daher sollte der erste und letzte Abschnitt zwischen dem Client und seinem Mailserver immer TLS-Verschlüsselt erfolgen, also POP3S (Port 995) statt POP3 (Port 110) und IMAP4S (Port 933) statt IMAP4 (143) und ebenso SMTPS über Port 465/587 statt 25.

Gateway

Wenn eine richtige Ende-zu-Ende-Verschlüsselung durch den Client keine brauchbare Option ist aber der Verzicht auf Verschlüsselung ebenso wenig toleriert werden kann, dann sollten Sie sich das Prinzip einer Gateway-Verschlüsselung anschauen. Dabei wird erst einmal davon ausgegangen, dass das interne Netzwerk, d.h. der eigene Mailserver und Client als "sicher" gelten und hier eine Verschlüsselung oder Signierung entfallen kann. Exchange erlaubt bei korrekter Konfiguration intern nur authentifizierten Benutzern einen Zugriff auf ihr Postfach über per TLS verschlüsselte Weg (RPC/HTTPS oder MAPI/HTTPS) und auch der Versand ist nur nach Anmeldung und dann mit der entsprechenden SMTP-Adresse möglich.

Dann bleibt nur der Weg über das Internet. Es gibt zwar Verfahren, wie Mailserver miteinander per TLS eine Verschlüsselung erzwingen können, aber dazu sind DNSSEC und kompatible Systeme erforderlich. Als Absender haben Sie aber keine Kontrolle darüber und nicht jeder Kommunikationspartner kann diese Möglichkeiten nutzen. Insofern geht kein Weg an SMIME/PGP vorbei.

Ein Gateway an der Grenze zwischen internem Mailverbund und dem Internet leitet die Mails nun weiter aber signiert die ausgehenden Nachrichten mit zentral vorgehaltenen Zertifikaten. Natürlich kann es vorher noch Disclaimer anfügen. Zudem kann das Gateway die Zertifikate von externen Absendern zentral einsammeln, Signaturen prüfen und ausgehende Mails damit automatisch verschlüsseln.

Wen die Gegenseite die bereitgestellten Zertifikate ebenfalls nutzt, dann können externe Absender Mails verschlüsseln. Das Gateway entschlüsselt die Mails im Auftrag des Empfängers und kann damit sogar den Content für eine Spamerkennung heranziehen.

Klar, das die Klartextmail im internen wie gewohnt auch automatisch weiter verarbeitet werden kann, d.h. Stellvertreter, Regeln, Archiv und andere automatische Prozesse funktionieren wie gewohnt. Es gibt auch keine Einschränkung in der Wahl des Clients, da es einfach nur "Mails" sind. Das Gateway kümmert sich um alle Belange der sicheren Mail und bietet zudem verschiedene Alternativen an, wenn die Gegenstelle nicht mit mit SMIME oder PGP arbeitet, z.B. PDF-Mail, Large File Transfer u.a.

Ausflug Rights Management

Rights Management hat nicht direkt etwas mit SMIME/PGP zu tun aber sie können damit natürlich auch Dokumente und sogar Mails "schützen". RMS geht aber weit über eine einfache Verschlüsselung hinaus, die eher ein Abfallprodukt ist. Wenn Sie eine verschlüsselte Mail senden, dann haben Sie als Absender keine Kontrolle darüber was der legitime Empfänger damit anstellt. Der Empfänger kann die Mail natürlich drucken, weiterleiten etc.

Für verschiedene Informationen ist es aber erforderlich, dass diese wirklich nur und ausschließlich vom Empfänger gelesen werden. Vielleicht wollten Sie eine Weiterleitung oder ein Ausdrucken verhindern oder sogar eine Zeitbeschränkung implementieren. Angebote oder Preislisten sind meist mit einer Verfallsdauer versehen und mit RMS können solche Beschränkungen problemlos umgesetzt werden. RMS ist also bei weitem nicht nur eine Technik, mit der früher Musikdateien geschützt wurden.

Dieser Schutz basiert natürlich darauf, dass die Information ohne die passenden "Decryption Keys" nicht zugänglich ist. Sie könne so eine Mail sicher über alle Transportwege übertragen.

Voraussetzung ist natürlich die Bereitstellung einer RMS-Plattform, die natürlich Komplexität und Kosten für Lizenzen und Betrieb addiert. Es kommen dabei keine Schlüssel auf dem Client zum Einsatz, sondern der Anwender muss sich an der RMS-Plattform anmelden, um die entsprechenden Schlüssel mit begrenzter Gültigkeit zu bekommen. Zudem wird nicht jeder Empfänger mit RMS arbeiten wollen und sich damit abfinden, dass Sie ihm den Zugriff auf ein erhaltenes Dokument quasi nachträglich wieder entziehen können. Neben der technischen Betrachtung sind hier viele organisatorische und juristische Fragen zu betrachten.

Gegenüberstellung

Ein Vergleich der verschiedenen Optionen ist nicht einfach, da jede Umgebung eigene Anforderungen und Vorgaben hat. Insofern kann ich nur versuchen ein paar Aspekte zu beleuchten. Alles andere ist klassischen Consulting.

  • Anwenderfreundlichkeit
    Anwender erwarten, dass es einfach "funktioniert". Das ist mit SMIME/PGP, dem Zertifikathandling etc. aber nicht immer einfach möglich. Nur die Verwendung von TLS als Transport oder einem Verschlüsselungsgateway geht ohne Änderungen auf dem Client einher. Alle anderen Optionen bedeuten Add-ons, Buttons, Rückfragen uvm.
  • Firmentauglich
    Eine Firma muss einen adäquaten Virenschutz und Spamfilter bieten, ggfls. Compliance-Vorschriften bezüglich Archivierung erfüllen und hat oft ein hohes Maß an Automatisierung mit Regeln und Stellvertretern. Zudem müssen Informationen lange lesbar sein, auch wenn der Anwender ausscheidet oder seine Schlüssel verliert. Das kann eigentlich nur mit einem Gateway bereit gestellt werden
  • Sicherheit
    Hier schneidet natürlich eine symmetrische Verschlüsselung mit Dokumentkennwort oder der alleinige Einsatz von TLS als untauglich entsprechend schlecht ab. Alle drei anderen Ansätze sind aus meiner Sicht gleich sicher. Beim Gateway gilt das nur mit der Einschränkung, dass das interne System entsprechend "sicher" betrieben wird.
  • Anschaffungskosten
    Für den Einsatz von Kennworten mit Office Dokumenten oder ZIP-Archiven ist zumindest nichts einzukaufen und für TLS braucht es nur ein Zertifikat pro Server. Das ist überschaubar. Der Einsatz von Zertifikate auf dem Client oder einem Gateway ist schon teurer. Auch das Gateway gibt es nicht umsonst. Es wäre unfair die hohen Kosten für RMS zu vergleichen, wenn man damit "nur" Mails verschlüsseln will. RMS kann viel mehr.
  • Verwaltung
    Die Schlüsselverwaltung ist bei SMIME/PGP eine knifflige Aufgabe, die je nach Plattform anders zu regeln ist. Es ist unentschuldbar, wenn Sie kein Private Key Recovery oder Backup umgesetzt haben. So etwas geht natürlich mit einem Gateway am einfachsten, da alle Zertifikate und Schlüssel zentral vorliegen und die Anwender nichts damit zu tun haben.

Das sind aus meiner Sicht die wesentlichen Kriterien, die Sie bei ihrer eigenen Bewertung genauer betrachten sollten.

Net at Work kann Sie bei der Analyse ihrer Anforderungen und der Bewertung unterschiedlicher unterstützen.
Bei der Produktauswahl sind wie aber nicht ganz neutral, weil wir mit NoSpamProxy seit vielen Jahren eine eigene Gateway-Lösung entwickeln und vertreiben. Fordern sie uns. Net at Work  und www.nospamproxy.de

Weitere Links