Foto: stock.xchng, kostenlos
Damit Sender und Empfänger einer E-Mail nicht Opfer eines Lauschangriffs oder von betrügerischen Phishing-Attacken werden, lassen sich elektronische Nachrichten verschlüsseln und/oder digital signieren. Die Signatur ist notwendig, um den Absender zweifelsfrei zu identifizieren. Die Verschlüsselung, um Lauscher und Datendiebe auszubremsen. Beides klappt zwar mit allen gängigen E-Mail-Clients und -Dienstleistern, in manchen Fällen aber eher schlecht als recht. Wir bieten einen Überblick.
Das Verschlüsseln und Signieren von E-Mails ist auch für technisch weniger versierte Zeitgenossen machbar, bringt jedoch einen gewissen Implementierungs- und Verwaltungsaufwand mit sich. Dennoch sind die Verfahren in den vergangenen Jahren deutlich einfacher und verständlicher geworden.
Schreib mal wieder... eine Postkarte!
Nach wie vor dürfte der Großteil aller E-Mails, die mit Empfängern außerhalb der eigenen Unternehmensorganisation ausgetauscht werden, dennoch unverschlüsselt im Klartext auf die Reise gehen (analog einer Postkarte). Schließlich ist es zunächst einmal unabdingbar, dass Sender und Empfänger die gleiche Art der Verschlüsselung einsetzen. Und das über Unternehmensgrenzen hinweg durchgängig sicherzustellen, ist fast unmöglich.
Immerhin werden zumindest innerhalb eines sicherheitsbewussten Unternehmens alle E-Mails dank der vorherrschenden und zumeist gut administrierten Microsoft Exchange- und IBM Domino-Infrastrukturen in der Regel automatisch verschlüsselt. Die Server erledigen alles Notwendige, der Anwender bekommt vom Verschlüsseln nichts mit.
Die fehlende Codierung beim Austausch mit dem "Rest der Welt" hat hingegen noch weitere Gründe als der bereits aufgeführte. Zum einen sind die in Frage kommenden Verfahren (S/MIME und PGP, siehe Kasten) zueinander nicht kompatibel. Zum anderen dürfte die Komplexität, die durch die zum Signieren und Verschlüsseln notwendigen Zertifikate (S/MIME) beziehungsweise Schlüssel (PGP) heraufbeschworen wird, viele IT-Verantwortliche zurückschrecken lassen. Die Furcht ist unberechtigt, ist der Umgang mit den Zertifikaten oder Schlüsseln in der Praxis doch längst nicht mehr so komplex wie noch vor einigen Jahren.
Webmail-Dienste sind unsicherer
Im Prinzip ist es gleichgültig, welcher Dienstleister sich um den E-Mail-Versand kümmert. Ob es also ein Microsoft-Dienst ist wie Office 365, Google Mail oder Apples MobileMe-Service. Sie alle stören sich nicht an der Verschlüsselung - tun jedoch selbst auch nicht besonders viel dafür. Das heißt, dass die Verschlüsselung im E-Mail-Client auf dem Endgerät passieren muss. Im Fall von Office 365 oder Google Mail ergibt sich hier jedoch bereits ein Problem: Der Browser ist kein dedizierter E-Mail-Client und kann daher nicht ohne Erweiterung mit verschlüsselten E-Mails umgehen.
Foto: Uli Ries
Im Zusammenhang mit Office 365 mutet dies merkwürdig an, da das zum Browserzugriff notwendige Outlook Web Access durchaus mit S/MIME umgehen kann. Das gleiche gilt übrigens für den Web Access auf ein Lotus-Domino-Postfach; auch hier können per S/MIME signierte oder verschlüsselte Nachrichten überprüft beziehungsweise gelesen werden. Microsoft hat die S/MIME-Funktion bei Exchange Online (Office 365) jedoch schlicht nicht umgesetzt, so dass sich verschlüsselte Nachrichten mit dem Browser nicht lesen lassen. Um den Webmail-Zugriff auf Google Mail S/MIME-fähig zu machen, steht ein Add-on für Firefox bereit. Der Umgang damit ist aber reichlich komplex, so dass sich der Einsatz des Plug-ins im professionellen Umfeld verbietet. Für alle Webmail-Dienste gilt außerdem: PGP (Pretty Good Privacy) ist grundsätzlich nicht einsetzbar.
Der Client muss es richten
Kommt an Stelle des Browsers ein vollwertiger E-Mail-Client zum Einsatz, ist es quasi egal, ob E-Mails per Microsoft Outlook, Lotus Notes, Apple Mail oder Mozilla Thunderbird verschickt und empfangen werden. Alle Anwendungen kommen problemlos mit dem standardisierten Verschlüsselungsverfahren S/MIME zurecht. Und auch PGP, der Ur-Vater der E-Mail-Verschlüsselung, versteht sich mit zahlreichen E-Mail-Anwendungen.
Die PGP-Version für Mac OS X beherrscht nur das Verschlüsseln von POP3/IMAP-Konten und kann mit E-Mail-Accounts, die auf Exchange-Servern gehostet werden, nichts anfangen. Dabei spielt es keine Rolle, ob per Outlook/Entourage, Thunderbird oder der Mail-App des Betriebssystems auf den Exchange-Server zugegriffen wird - PGP bleibt untätig. Das kostenlose Derivat OpenPGP hilft ebenfalls nicht weiter. Betroffen sind auch die Nutzer von Microsofts Cloud-Angebot Office 365, hinter dessen E-Mail-Dienst eine Exchange-Infrastruktur liegt, die mit PGP per se nicht klarkommt. Von daher sei hier der Einsatz von S/MIME empfohlen, das sich auf dem Mac per Outlook 2011 oder der Mail-App problemlos auch in Verbindung mit Office 365 verwenden lässt.
S/MIME und PGP im Einsatz
Foto: Uli Ries
Betreibt ein Unternehmen keine eigene, vertrauenswürdige Zertifizierungsstelle (CA), können S/MIME-Zertifikate von allen gängigen CAs bezogen werden (für diesen Fall nicht nur über die von der Bundesnetzagentur akkreditierten Stellen). Start SSL und Instant SSL stellen beispielsweise kostenlose Zertifikate aus. Je nach Browser, mit dem der Zertifikaterstellungsprozess erledigt wird, fügt die CA das neue Zertifikat entweder direkt in die Liste der persönlichen Zertifikate im Browser hinzu oder stellt es als Download zur Verfügung. In erstgenanntem Fall kann der Anwender es direkt in den E-Mail-Client (Windows) oder die Schlüsselverwaltung (Mac OS X) aufnehmen. In letzterem Fall muss es manuell aus dem Browser in eine eigene Datei exportiert werden.
In Mac OS X genügt dazu das Aufnehmen des Zertifikats in die Schlüsselverwaltung. Die Mail-App erkennt das Zertifikat automatisch und zeigt im Fenster der zu versendenden E-Mail oben unter dem Betreff zwei Symbole für die Funktionen Verschlüsselung und Signatur, die per Klick aktiviert werden.
Foto: Uli Ries
Unter Outlook 2010 (Windows) findet sich die Option zum Einlesen des Zertifikats unter Datei / Optionen / Sicherheitscenter. Dort lässt sich rechts die Schaltfläche "Einstellungen für das Sicherheitscenter" anklicken und anschließend aus der Liste links den Punkt "E-Mail-Sicherheit" auswählen. Nun kann der Anwender durch einen Klick auf "Importieren/Exportieren" die Zertifikatsdatei laden.
PGP hingegen klinkt sich mittels Proxy in den E-Mailaustausch ein. Am einfachsten lässt sich das bewerkstelligen, wenn das E-Mail-Konto im Client erst nach der Installation von PGP eingerichtet wird. Steht diese Option nicht zur Debatte und scheitert PGP am automatischen Erkennen des Kontos, kann es von Hand über die Option "Messaging" im PGP-Desktop mit der Verschlüsselungssoftware vertraut gemacht werden.
Besonderheit Smartphone
Ist der E-Mail-Client auf PC oder Notebook konfiguriert, muss auch noch an das Smartphone oder den PC zu Hause gedacht werden, sollte mit diesem auf das berufliche Postfach zugegriffen werden. Denn für jedes Endgerät sind eigene Zertifikate notwendig - ein grundsätzlicher Nachteil der Client-basierten Verschlüsselung. Glücklicherweise beherrscht Apples iOS ab Version 5 den Umgang mit S/MIME ab Werk. Die Konfiguration ist vergleichsweise simpel.
Anders sieht die Welt aus, wenn Googles Android zum Einsatz kommt. Hier muss mit Apps nachgeholfen werden. Gängig ist beispielsweise der E-Mail-Client K-9, der S/MIME-kompatibel ist. Wer stattdessen lieber mit der vorinstallierten, Android-eigenen Mail-App arbeiten möchte, muss sich einer Zusatzsoftware wie Djizgo bedienen. Die App beherrscht den Umgang mit den benötigten Zertifikaten - stellt den Anwender aber mangels Nutzerfreundlichkeit auf eine harte Probe. Einmal mehr hat Apple in diesem Fall in Sachen Ergonomie die Nase vorn.
Hintergrundwissen: S/MIME und (Open)PGP
Die De-facto-Standards zum durchgängigen Verschlüsseln und Signieren von E-Mails heißen S/MIME (Secure / Multipurpose Internet Mail Extensions) und PGP (Pretty Good Privacy, kommerzielle Version) beziehungsweise OpenPGP (kostenlose Variante). Beide Verfahren bauen auf einer PKI (Public Key Infrastructure) auf, benötigen also nicht zwingend ein Verschlüsselungs-Gateway im Unternehmen.
Bei S/MIME kommen Zertifikate zum Einsatz. Die fürs Ausstellen zuständigen Zertifizierungsstellen (CAs) sind zumeist identisch mit den CAs, die auch SSL-Zertifikate vergeben dürfen. Kostenlose S/MIME-Zertifikate stellen beispielsweise Start SSL oder die Comodo-Tochter Instant SSL aus. Anders als bei SSL bezeugt das Zertifikat jedoch nicht die Echtheit eines Web- oder E-Mail-Servers, sondern die Authentizität einer einzelnen E-Mail-Adresse. Um den Kommunikationspartnern den öffentlichen Teil des Zertifikats zukommen zu lassen, genügt der Versand einer signierten E-Mail. Der Empfänger speichert diesen Teil im E-Mail-Client und kann von nun an verschlüsselte Nachrichten mit der Gegenseite austauschen.
PGP hingegen setzt auf Private-Public-Schlüsselpaare, die während der Installation pro E-Mail-Adresse erzeugt werden. Zum Absichern der Kommunikation müssen sich die Gesprächspartner gegenseitig ihren Public Key zukommen lassen. Die Software verwendet diesen dann, um die für den Besitzer des Schlüssels gedachten Nachrichten zu verschlüsseln. Alternativ kann der Public Key auch in ein öffentlich zugängliches Verzeichnis hochgeladen werden. Der andere Teil des Schlüsselpaares, der Private Key, verbleibt in jedem Fall auf dem lokalen Client und ist jeweils nur einem der beiden Gesprächspartner bekannt.
Daneben gibt es noch weitere Client-basierte Verschlüsselungsverfahren, wie beispielsweise die Endpoint Protection von Trend Micro. Diese sind jedoch zumeist nicht konform zu den offenen Standards. Verfahren wie SSL/TLS haben schützen zwar die Transportwege zwischen Client und Server beziehungsweise zwischen zwei E-Mail-Servern vor Lauschangriffen. Eine vollständig abgesicherte Kommunikation lassen sie aber nicht zu. Sobald eine E-Mail das Empfängerpostfach erreicht, liegt sie dort umgehend wieder im Klartext vor. Das gleiche gilt für den Ordner mit den gesendeten Nachrichten beim Absender. S/MIME und PGP hingegen sichern sowohl die lokalen E-Mail-Speicher als auch den Transportweg durchgängig ab.
Aber auch diese beiden Verfahren bringen Nachteile mit sich. So ist in der Regel der Anwender selbst für das Schlüssel-Management verantwortlich; Er muss die Schlüssel und Zertifikate seiner Kommunikationspartner sammeln. Gespeichert wird noch dazu pro Endgerät. Das heißt, Zertifikate oder Schlüssel müssen beispielsweise auf Smartphone und Notebook getrennt aufbewahrt werden. Ein weiterer Nachteil ist, dass die client-basierte E-Mail-Verschlüsselung Spam- und Schadsoftwarefilter im Netzwerk ausbremst, da diese die Nachrichten mangels Key nicht entschlüsseln können. Durch den hohen Implementierungs- und Verwaltungsaufwand ist es also nicht verwunderlich, dass es bisher nie einen flächendeckenden Einsatz von S/MIME und/oder PGP gegeben hat. (sh)