TIPPS & BEST PRACTICE 17. NOV 2016
E-Mail-Verschlüsselung mit Empfängern ohne Zertifikat
Alternative Zustellmethoden nutzen oder
einfach selbst Zertifikate ausstellen?
Verschlüsselung mit Passwort – bewährte Technologie mit hoher Nutzerfreundlichkeit
Nicht zu jeder E-Mail-Adresse, mit der ein vertraulicher E‑Mail-Austausch gewünscht ist, kann ein gültiges Zertifikat gefunden werden. Um trotzdem schnell und sicher kommunizieren zu können, werden beim Einsatz eines Secure E-Mail Gateways üblicherweise passwortbasierte Verschlüsselungsverfahren genutzt.
Der Empfänger erhält die vertrauliche Nachricht beispielsweise als passwortverschlüsselten PDF-, HTML- oder ZIP-Container im E-Mail-Anhang zugestellt. Eine ebenfalls verbreitete Variante der passwortbasierten Verschlüsselung ist die Bereitstellung eines on-the-fly erstellten, HTTPS-gesicherten Webpostfaches. So können Unternehmen ohne Verzögerung mit jedermann verschlüsselt kommunizieren. Die Accounterstellung für externe Nutzer sowie die Verwaltung der Passwörter erfolgen hochautomatisiert, ohne die Mitarbeiter zu belasten. Um eine hohes Sicherheitsniveau zu gewährleisten, kann die PIN zur Aktivierung des Accounts per SMS zugestellt werden.
Ad-hoc Zertifikatsausstellung – von Sicherheitsbedenken und praktischen Widrigkeiten
Eine weitere Möglichkeit, mit Empfängern ohne Zertifikat vertraulich zu kommunizieren, ist diesen automatisiert ein Zertifikat zur Verfügung zu stellen. Was nach einem brauchbaren Ansatz klingt, sollte im Detail durchdacht werden.
Beim Versand einer vertraulichen E-Mail agiert die Organisation des Senders als Certification Authority (CA) und stellt on-the-fly ein Zertifikat für den Empfänger aus. Dies funktioniert bei einfachen Lösungen, die ohne Zugriff auf den Mailflow den üblicherweise notwendigen komplexen Enrollment-Prozess abkürzen müssen, ohne Zeitverzug, weil auch der private Schlüssel für den Empfänger gleich beim Sender erstellt wird.
Auf diese Weise erhält der Empfänger in kurzem zeitlichen Abstand die verschlüsselte Nachricht, den privaten Schlüssel und das Zertifikat. Das Problem dabei ist, dass sicherheitsrelevante Funktionsweisen der Public Key Infrastructure (PKI) umgangen werden: Der private Schlüssel ist nicht mehr geheim. Denn mindestens die Firma, die die Schlüssel ausstellt, kennt den privaten Schlüssel des Empfängers. Die genutzte Verteilungslogik, nämlich das Zertifikat und den privaten Schlüssel zusammen mit der vertraulichen E-Mail kurz hintereinander über den gleichen Kanal zu senden, entspricht auch nicht dem Sicherheitsanspruch einer PKI.
Entwicklung unkontrollierbarer Zertifikatszoos
Ein weiteres Problem ist die unkontrollierte Vermehrung und Verbreitung der oben beschriebenen ad-hoc ausgestellten Zertifikate, wenn sich sich die spontane Zertifikatsausstellung in der Breite durchsetzen würde. Üblicherweise besitzt ein PKI-Teilnehmer nur ein oder zwei Zertifikate, die von allen Kommunikationspartner genutzt werden. Dies ist in etwa vergleichbar mit einer einzelnen Telefonnummer, über die verschiedene Kontakte den Nummerninhaber erreichen können. Erstellen nun aber viele Firmen Zertifikate für Empfänger ihrer Nachrichten, bekäme eine einzelne Person von mehreren Kommunikationspartnern jeweils ein separates Zertifikat ausgestellt. Die Zertifikate lassen sich in der Anwendung allerdings nicht auf die Nutzung mit dem Kommunikationspartner, der das Zertifikat ausgestellt hat, beschränken. Woher weiß der Empfänger, wann er welchen Schlüssel nutzen soll? Wenn der mit einem Zertifikat „Beschenkte“ regelmäßig mit dem zugehörigen privaten Schlüssel E-Mails an Dritte signiert, ist die Verbreitung der Zertifikate nicht mehr zu stoppen und das Chaos perfekt. Zur Validierung benötigte CAs sind nicht vorhanden, Helpdesk-Mitarbeiter aller beteiligten Unternehmen werden involviert, ohne jedoch helfen zu können.
Compliance-widrige Schatten-IT
Noch ein Problem ergibt sich vor allem im B-to-B-Bereich, wenn beim Empfänger durch ein zentral gesteuertes Windows Update alle Schlüssel des lokalen Keystores verloren gehen. Da diese Schlüssel der zentralen IT im Unternehmen gar nicht bekannt sind, können Schlüssel und Zertifikate nicht wiederhergestellt werden. Die eingeschleuste Pseudo-PKI ist Teil der “Schatten-IT”, deren Nutzung mutmaßlich auch gegen Compliance-Regelungen der beschenkten Unternehmen verstößt.
Frust bei Privatanwendern
Beim Versand vertraulicher Daten an Endanwender (B-to-C) ergeben sich ganz andere Probleme. Dem User wird eine Technologie aufgezwungen, die er oft gar nicht verwenden kann. Im Privatbereich ist die Nutzung von Webmailern weit verbreitet. Die Ad-hoc-Ausstellung von Zertifikaten ist üblicherweise auf den S/MIME-Standard beschränkt, Webmailer unterstützen diese Technologie jedoch nicht. Deshalb führt dieser Kommunikationsversuch zu Frust und Verzögerungen, da ein neuer Kommunikationskanal gewählt werden muss.
Neue Unternehmensrolle durch eIDAS und VDG
Weiterhin versetzt die Ad-hoc-Ausstellung von x.509-Zertifikaten für externe Kommunikationspartner eine Firma in die Rolle eines Trustcenters. Nach der eIDAS-Verordnung wird eine Organisation damit zum Vertrauensdiensteanbieter nach Europäischem Recht mit allen rechtlichen Implikationen. Aktuell werden in Deutschland mit dem Vertrauensdienstegesetz (VDG) sogar noch stärkere Compliance-Regelungen erarbeitet, denen die ausstellende Organisation unterliegt.
Fazit: Programmiertes Chaos mit rechtlichen Verpflichtungen besser meiden
Auch wenn unsere Verschlüsselungsprodukte grundsätzlich die technischen Voraussetzungen mitbringen, um einfach Zertifikate für Dritte auszustellen, bleibt für uns die passwortbasierte Verschlüsselung für Empfänger ohne Zertifikate eindeutig die bessere Wahl. Wenn schnell und einfach vertrauliche Mails ausgetauscht werden sollen, ist Z1 SecureMail Gateway mit Z1 Messenger Komponente die bewährte Lösung.
