Unternehmenslösung zur E-Mail-Verschlüsselung

Erfahrungsbericht eines Mitglieds des Arbeitskreis Verschlüsselung und Signierung (AK Krypto). Beschreibung einer Unternehmenslösung zur E-Mail-Verschlüsselung – unter Berücksichtigung der unterschiedlichen Kommunikationspartner mit unterschiedlichsten IT-Kenntnissen und -Ausstattungen.

Der im letzten Jahr neu gegründete AK Krypto des BvD hat sich vorgenommen, verschiedene Themen in Form von Blog-Beiträgen zu veröffentlichen. Der hier vorliegende Text ist ein Erfahrungsbericht im Rahmen dieser Veröffentlichungen. Der Autor stellt die E-Mail-Verschlüsselungslösung vor, die bei dem Unternehmen umgesetzt ist, bei dem er als Datenschützer (Stellvertreter des Konzerndatenschutzbeauftragten) bestellt ist.

Es handelt sich bei der eingesetzten Lösung um eine Appliance (also nicht nur Software, sondern eine Komplettlösung aus Hard- und Software), mit der alle E-Mails des Unternehmens von einem Gateway ver- und entschlüsselt werden können. Das große praktische Problem bei der Etablierung einer E-Mail Verschlüsselung ist, dass es hierfür keinen einheitlichen Standard gibt, bei dem man davon ausgehen kann, dass ihn jeder Kommunikationspartner einsetzen kann (oder will). Zunächst gibt es zwei Standards, die untereinander nicht kompatibel sind: PGP und S/MIME. Beide basieren auf einer Verschlüsselung mit öffentlichen Schlüsseln. Der Vorteil der Verschlüsselung mit öffentlichen Schlüsseln (Public-Key Kryptographie) ist, dass man keine „geheimen“ Schlüssel austauschen muss, sondern nur „öffentliche“. Das vereinfacht den Schlüsselaustausch sehr, weil diese öffentlichen Schlüssel entweder auf einem Schlüsselserver veröffentlicht sind und von dort abgerufen werden können oder auch per normaler unverschlüsselter E-Mail zugesendet werden können. Möglich ist dies, weil man mit diesen öffentlichen Schlüsseln nur ver- aber nicht entschlüsseln kann. Zum Entschlüsseln braucht man den zum jeweiligen öffentlichen Schlüssel passenden privaten Schlüssel, den nur der Empfänger selbst hat und den er sich mit niemandem teilen muss/darf/kann. Um die Vorteile dieser Verschlüsselung nutzen zu können, muss der Empfänger jedoch auch eines dieser Systeme (S/MIME oder PGP) nutzen bzw. der Absender muss vom Empfänger einen für diese Systeme passenden/kompatiblen [1] PGP-Schlüssel oder ein S/MIME-Zertifikat [2] haben, mit dem die zu verschlüsselnde E-Mail verschlüsselt werden kann.

Das große praktische Problem bei der Einführung einer unternehmensweiten Verschlüsselung ist nun, dass man weder davon ausgehen kann, dass sich alle Kommunikationspartner auf eines dieser Verfahren einigen können, noch, dass alle Kommunikationspartner überhaupt gewillt und/oder in der Lage sind, eines dieser Verfahren bei sich einzuführen. Zur Lösung dieses Problems kommt nun die oben genannte Appliance zum Einsatz.

Wenn ein Mitarbeiter des Unternehmens eine E-Mail versenden will, wird er zunächst gefragt, ob sie verschlüsselt werden soll. Wenn diese Frage mit „nein“ beantwortet wird, wird die E-Mail unverschlüsselt versendet. Diese Möglichkeit soll es nach wie vor für unkritische E-Mails geben. Falls die Frage jedoch mit „ja“ beantwortet wird, geht der Inhalt dieser E-Mail nur verschlüsselt über das Internet – egal welche Variante der Empfänger bei sich installiert hat. Es gibt nun die folgenden drei Möglichkeiten:

  1. Falls vom Empfänger (bzw. der E-Mail-Adresse) ein S/MIME-Zertifikat vorliegt, dann wird die E-Mail mit dem öffentlichen S/MIME-Schlüssel verschlüsselt.
  2. Falls vom Empfänger (bzw. der E-Mail-Adresse) ein PGP-Schlüssel vorliegt, dann wird die E-Mail mit dem öffentlichen PGP-Schlüssel verschlüsselt.
  3. Falls vom Empfänger (bzw. der E-Mail-Adresse) weder ein S/MIME-Zertifikat noch ein PGP-Schlüssel vorliegt, dann kommt ein Verfahren zum Einsatz, das „SecureMail“ genannt wird. Dabei wird die vertrauliche E-Mail zunächst gar nicht versendet. Stattdessen geht eine E-Mail an den Empfänger, im der dieser darüber informiert wird, dass eine (vertrauliche) E-Mail für ihn zur Abholung auf einem DFS-Server (dem Gateway) bereitsteht. Diese E-Mail ist bereits mit einem Link zum Gateway bzw. zur vertraulichen Nachricht versehen. Wenn der Empfänger den Link dieser E-Mail anklickt wird er über eine verschlüsselte Verbindung (https:…) mit der Anmeldeseite des Gateways verbunden. Hier kann er sich mit seiner E-Mail-Adresse und einem Passwort anmelden. Bei der ersten Anmeldung muss er sich dieses Passwort selbst vergeben und (wie üblich) merken. Bei weiteren E-Mails kann er sich immer wieder mit diesem Passwort sofort anmelden. Die Gefahr eines Missbrauchs besteht somit nur bei der ersten Verbindung, so dass man hier möglichst noch keine wirklich vertraulichen Daten versenden sollte. Erst wenn man vom Empfänger (z. B. telefonisch) eine Bestätigung bekommen hat, dass er die erste Test-Mail auch entschlüsseln konnte, weiß man, dass er es auch ist, der den Zugang über das selbst gewählte Passwort zu den vertraulichen E-Mails hat.

Im umgekehrten Fall, wenn vertrauliche E-Mails zurückgeschickt werden sollen, geschieht dies analog:

  1. Falls der Absender eine mit S/MIME verschlüsselte E-Mail an unser Unternehmen sendet, dann wird die E-Mail mit dem privaten S/MIME-Schlüssel des Gateways entschlüsselt und dann an den entsprechenden Mitarbeiter weitergeleitet.
  2. Falls der Absender eine mit PGP verschlüsselte E-Mail an unser Unternehmen sendet, dann wird die E-Mail mit dem privaten PGP-Schlüssel des Gateways entschlüsselt und dann an den entsprechenden Mitarbeiter weitergeleitet.
  3. Falls der Absender weder S/MIME noch PGP verwendet, dann kann er sich wieder über seinen Zugang zum Gateway über die verschlüsselte Internetverbindung mit dem Tool verbinden (SecureMail) und dort direkt seine Nachricht (ggf. einschließlich der Anhänge) eingeben, die dann an den entsprechenden Mitarbeiter weitergeleitet wird.

Vor- und Nachteile des Verfahrens:

  • Aus Sicht der Beschäftigten des Unternehmens ist es egal, ob von einem Empfänger ein S/MIME-, ein PGP- oder gar kein Schlüssel hinterlegt ist. Die zu versendende E-Mail wird geht in jedem Fall nur verschlüsselt über das Internet. Falls aufgrund mehrerer Empfänger unterschiedliche Verfahren zum Einsatz kommen müssen, werden aus einer einzigen zu versendenden E-Mail ggf. unterschiedliche E-Mails generiert – mit unterschiedlichen Verschlüsselungen. Die Kollegen merken nichts davon.
  • Im Falle von „SecureMail“ kommt zwar ein Passwort zum Einsatz, das der Kommunikationspartner sich merken muss, aber auch dieses Passwort wird nur mit dem Gateway vereinbart und nicht mit Mitarbeitern unseres Unternehmens. Letztere müssen sich somit weder ein Verfahren noch ein Passwort merken, das beim Kommunikationspartner verwendet wird.
  • Für die jeweiligen Kommunikationspartner ist der Einsatz des Tools auch weitgehend unbedeutend, sofern er S/MIME oder PGP nutzt und die entsprechenden Zertifikate/Schlüssel ausgetauscht wurden. Nur für den Fall, dass er keines der beiden Verfahren nutzt, wird die E-Mail-Kommunikation für ihn schwieriger. Falls er sich daran stört die E-Mails aus unserem Server immer abholen zu müssen, anstatt sie in seinem eigenen E-Mail Eingang vorliegen zu haben, muss man ihm klarmachen, dass IT-Sicherheit nicht ganz umsonst zu haben ist. Er muss entweder mit dieser unkomfortablen Situation umgehen oder sich nachträglich für eine Kommunikation über S/MIME oder PGP entscheiden. Sowie er mit uns einen entsprechenden Schlüssel (bzw. ein Zertifikat) ausgetauscht hat, liegen auch wieder alle (ab diesem Zeitpunkt versendeten) E-Mails direkt in seiner Eingangsbox vor.
  • Bei uns wurden sowohl für S/MIME als auch für PGP nur Gateway-Schlüssel generiert – also keine individuellen Schlüssel für jeden Beschäftigten. Somit handelt es sich nicht um eine Ende-zu-Ende Verschlüsselung, sondern nur um eine Verschlüsselung ab bzw. bis zum Gateway des Unternehmens. Das Wesentliche bei einer Unternehmenslösung ist jedoch, dass die Daten nicht unverschlüsselt über das (offene) Internet übertragen werden und das ist mit dieser Lösung der Fall.
  • E-Mail Clients der jeweiligen Kommunikationspartner haben in manchen Fällen Probleme mit den Gateway-Schlüsseln. Das liegt daran, dass die Zertifikate/Schlüssel nur eine allgemeine E-Mail-Adresse des Unternehmens (aber nicht die exakte der jeweiligen Empfänger) haben können und somit nicht vollständig mit den E-Mail-Adressen der in den E-Mails eingetragenen Empfänger übereinstimmen können. Bei PGP lässt sich das bei manchen Clients einstellen, indem dem E-Mail Client mitgeteilt wird, dass alle E-Mails mit z. B. der Endung „@company.de“ mit dem vorliegenden PGP-Gateway-Schlüssel des Unternehmens verschlüsselt werden sollen. Bei S/MIME lässt sich das in manchen Fällen nicht konfigurieren. Kleine Unternehmen und Berater nutzen jedoch häufig PGP (bzw. gpg oder gpg4win). Große Unternehmen und speziell Behörden nutzen eher S/MIME – jedoch auch mit irgendeiner Serverlösung für die Verschlüsselung, bei der serverseitig oft eingestellt werden kann, dass alle E-Mails mit der gleichen Endung den selben S/MIME-Schlüssel verwenden sollen. Trotzdem gibt es Fälle, bei denen wir hier noch keine Lösung und somit ein Problem haben.
  • Bei Variante drei, bei der sich die Kommunikationspartner über ein Passwort Zugang zu den E-Mails verschaffen, muss sichergestellt sein, dass die erstmalige Anmeldung (mit der Passwortvergabe) auch wirklich der berechtigte Empfänger durchführt. Falls die E-Mail mit dem Link von Unbefugten abgefangen wurde, könnten diese sich auch das Passwort vergeben. Daher sollte die erste Kommunikation noch keine wirklich vertraulichen Daten enthalten und es sollte nach der Passwortvergabe noch einmal (z. B. telefonisch) sichergestellt werden, dass die E-Mail auch wirklich vom korrekten/berechtigten Empfänger gelesen wurde. Danach ist die Kommunikation sicher.
  • Ähnlich ist es mit der Aufnahme der öffentlichen PGP-Schlüssel oder S/MIME-Zertifikate der externen Kommunikationspartner. Auch hier sollte einmalig überprüft werden, dass die importierten Schlüssel/Zertifikate wirklich von dem Kommunikationspartner stammen, mit dem man kommunizieren möchte. Ansonsten besteht die Gefahr eines Man-in-the-Middle-Angriffs [3]. Überprüfen lassen sich die öffentlichen Schlüssel z. B. über deren Fingerabdrücke, die man schnell auch telefonisch abgleichen kann.

Abschließend sei noch angemerkt, dass die mit S/MIME oder PGP (bzw. gpg oder gpg4win) verschlüsselten E-Mails auch signiert werden können, was bei uns auch entsprechend konfiguriert ist. Bei signierten eingehende E-Mails wird die Signatur geprüft und das Ergebnis dem Empfänger mitgeteilt. Beides geschieht über die gleichen bereits sowieso vorliegenden Schlüssel, worauf in diesem Beitrag jedoch nicht näher eingegangen wird.

Bei der eingesetzten Appliance handelt es sich um „SecureMail Gateway“ von Zertificon Solutions GmbH, es gibt aber auch anderen Anbieter, die ähnliche Lösungen bereithalten.

Für Rückfragen stehe ich gern zur Verfügung

Riko Pieper (für den AK Krypto)
Stellvertreter des Konzerndatenschutzbeauftragten der DFS Deutsche Flugsicherung GmbH, Langen
Kontakt über Riko.Pieper@dfs.de

 

Fußnoten:
[1] Statt PGP „Pretty Good Privacy“ kann auch das kostenlose vom BSI geförderte Tool gpg „Gnu Privacy Guard“ bzw. die auf Windows optimierte GPG-Version „gpg4win“ genutzt werden. Die Schlüssel von PGP und GPG sind zueinander kompatibel.
[2] Bei PGP spricht man von Schlüsseln, bei S/MIME von Zertifikaten. In beiden Fällen braucht man für die Verschlüsselung einen öffentlichen Schlüssel und ein paar Zusatzinformationen wie z. B. eine E-Mail-Adresse, damit ein Tool die jeweils korrekten Schlüssel in Abhängigkeit vom Empfänger nutzen kann. In einem S/MIME-Zertifikat sind ggf. weitere Informationen enthalten auf die hier nicht näher eingegangen wird.
[3] Mehr Informationen zu Man-in-the-Middle-Angriffen unter https://de.wikipedia.org/wiki/Man-in-the-Middle-Angriff

BvD-Blog