Digitale Signatur und Verschlüsselung – eine Einführung

Der vertrauliche Transport von Emails und Anhängen ist in den meisten Unternehmen nach wie vor ein ungelöstes Thema. Aus diesem Grund wollen wir uns dem Thema etwas ausführlicher widmen – im ersten Teil zu den Grundlagen…Zum Prinzip: Die Kommunikation per Mail verläuft als Standard unverschlüsselt. Dies bedeutet, dass einerseits jegliche „Zwischenstation“ den Inhalt einsehen kann (Sie erinnern sich bestimmt an das Beispiel der Postkarte), andererseits aber auch jeder mit Postfachzugriff beim Empfänger (z.B. Serveradministratoren) die Nachricht einsehen kann. Letztlich kann aber auch jede Nachricht auf dem Weg zum Empfänger manipuliert werden, ohne dass es der Empfänger einfach nachvollziehen kann.

Was ist mit TLS und SSL?

Eine Differenzierung vorab: wir sprechen hier von einer client-basierenden Technologie. Email-Verschlüsselungsverfahren basierend auf TLS oder SSL ermöglichen eine Absicherung des Übtragungswegs (von Server zu Server), die Nachricht selbst bleibt davon unberührt.
Zuerst aber zur wichtigen Unterscheidung der beiden Begriffe Signatur und Verschlüsselung: Eine digitale Signatur ist nicht mehr als die digitale Variante einer persönlichen Unterschrift. Dennoch ist ihr Wert nicht zu unterschätzen! Eine eindeutige Authentifizierung des Absenders ermöglicht dem Empfänger die Sicherheit, dass ein vertrauliches Dokument (Rechnung, Auftrag, o.ä.) wirklich von dem vorgegebenen Absender stammt. Einen Mailabsender kann heute ja jedes Kind vortäuschen. Neben der Gewissheit des richtigen Absenders bringt die digitale Signatur aber auch die Gewissheit, dass der Inhalt der Mail auf dem Weg zum Empfänger nicht verändert wurde. Damit wird folglich eine Sicherstellung der getätigten Aussagen möglich (technisch erfolgt dies durch die Bildung eines Hashwerts). Unbenommen davon bleibt das Lesen der Mail trotz Signatur jedem möglich.
Erst die Verschlüsselung – zusätzlich zur Signatur – unterbindet die Einsicht Dritter in die Korrespondenz. Damit ist (auch für den Versender) sichergestellt, dass auch wirklich nur der gewollte Adressat der Nachricht dessen Inhalt einsehen kann.

S/MIME oder PGP

Wir beschäftigen uns an dieser Stelle nur mit S/MIME. Der Grund liegt darin, dass das Dasein von PGP seit der Übernahme von diversen Konzernen (zuletzt von Symantec, davor auch McAfee) eine ungewisse Zukunft hat – von einer Vielzahl von technischen Problemen bei der Implementierung ganz zu schweigen. Der zweite wichtige Grund, der für S/MIME spricht: bei der Nutzung von Standard-Mailprogrammen (allen voran Outlook 2010, auch in Kombination mit Exchange Server 2010) funktioniert die Implementierung Out-of-the-Box. Es muss also keinerlei Software von Drittherstellern installiert werden – vor allem beim Rollout in größeren Umgebungen ein unschätzbarer Vorteil.
S/MIME basiert ausschließlich auf Zertifikate. Diese werden entweder von einer eigenen PKI-Infrastruktur (z.B. mithilfe der Active-Directory-integrierten Zertifikatsstelle) oder über öffentliche Trustserver (wie VeriSign) ausgestellt. Dabei prüft der Aussteller die persönlichen Daten des Zertifikatbesitzers. Das erstellte Zertifikat wird zusammen mit dem öffentlichen Schlüssel auf einem Verzeichnisserver veröffentlicht und kann dort vom Anwender abgerufen werden. Nur der Besitzer verfügt letztendlich über den privaten Schlüssel. Ohne eine vertrauenswürdige Zertifizierungsstelle geht also für beide Seiten (Absender und Empfänger der Mail) gar nichts.

S/MIME im Unternehmen

Beim Einsatz von S/MIME in Exchange-Umgebungen erfolgt die Konfiguration ebenfalls auf dem Client (lokaler Zertifikatspeicher). Der Rollout einer firmenweiten PKI ist aber keine Sache von Minuten, sondern sollte gut geplant werden. Vor allem die Schulung der Anwender stellt dabei – neben allen technischen Herausforderungen – eine nicht zu unterschätzende Hürde dar. Da auch die Schlüssel der Empfänger verfügbar gehalten werden müssen (wenn möglich im AD) und auch die interne Verarbeitung im Exchange Server erst seit Version 2010 sauber funktioniert, wollen wir dieser Problematik einen eigenen Blogeintrag widmen. Wir sind ja erst bei der Einführung.

Anzeige

Noch kurz ein Hinweis zum Unterschied von „privaten“ und öffentlichen Zertifikaten. Werden die Zertifikate von der internen CA (zumeist einem Windows-Domaincontroller) ausgestellt ist keine öffentliche Vertrauensstellung gegeben. Soll der Emailverkehr ausschließlich innerhalb der Firma genutzt werden, so stellt dies kein Problem dar. Wenn aber Nachrichten an externe Mailsysteme übertragen werden, so ist die Vertrauensstellung damit nicht gewährleistet. Hier kann zwar ein manueller Import der privaten Zertifizierungsstelle auf der Partner-Site Abhilfe schaffen – was aber wohl nur in Ausnahmefällen ein gangbarer Weg sein dürfte. Denken Sie an die Zukunftssicherheit Ihrer ID und gönnen Sie sich ein öffentliches, bekanntest und allgemein vertrauliches Zertifikat!

Die Praxis

Wie auch immer der Rolllout erfolgt – letztlich landet beim Anwender ein Zertifikat in seinem Zertifikatspeicher. Nicht vergessen: Sie benötigen auch (und vor allem) den öffentlichen Schlüssel des Empfängers. Am einfachsten erhalten Sie eine digital signierte Mail von Ihrem zukünftigen Partner und speichern dessen Public Key in Ihren Outlook-Kontakten (unter Outlook 2010 ist auch eine Aktualisierung eines bestehenden Kontakts mit dem neuen Key möglich). Langsam? Sie haben noch kein eigenes Zertifikat?

VeriSign und andere vertraute Aussteller

Ihre ganz private Digital-ID zum Mailversand besorgen Sie sich am besten bei einem der vertrauenswürdigen Zertifizierungsstellen. Dies ist fast immer mit Kosten verbunden. VeriSign (mittlerweile auch im Besitz von Symantec) verlangt dafür aktuell rund 20 Euro (pro Jahr! für die digitale ID). Es gibt auch kostenlose Anbieter für Zertifikate. Bedenken Sie aber, dass Ihr Gegenüber auch dieser Instanz vertrauen muss. Dies gilt auch für all Ihre zukünftigen Verschlüsselungspartner!  Und etliche vertrauen keinen Zertifikaten der Nulltarif-Anbieter – meiner Meinung zurecht, da diese nur einen minimalsten Nachweis der Identität erfordern (manchmal reicht schon eine Mail).

Welchen Aussteller Sie auch immer bevorzugen, Sie importieren die digitale ID in den Zertifikatsspeicher (in Windows unter „Aktueller Benutzer, Eigene Zertifikate, Zertifikate“ und können diese Identität dann in Outlook mit ein paar Klicks (unter Datei, Optionen, Sicherheitscenter, Einstellungen, E-Mail-Sicherheit bei Outlook 2010) dann hinzufügen. In Outlook selbst kann der Versand von Mails fortan dann entweder automatisch oder manuell signiert werden (ebenfalls über die Optionen zu konfigurieren).

Die Speicherung von Zertifikaten der Mailpartner erfolgt in Outlook ebenso einfach: Sobald Sie eine signierte Mail erhalten haben, können Sie über einen Rechtsklick auf den Absender sowohl die Adresse wie auch das Zertifikat der betreffenden Mailadresse zu den Kontakten hinzufügen bzw. diese aktualisieren.

Der Versand einer signierten oder verschlüsselten Mail erfolgt in Outlook über eine Auswahl in den Optionen zur zu versendenden Mail.

Ein wichtiger Hinweis zuletzt: Eine verschlüsselte Mail kann auch kein Virenscanner auf Schädlinge prüfen. Aus diesem Grund scheitern auch alle Scanvorgänge auf Firewall- oder Serverseite. Dies bedeutet einerseits für den Empfänger höchste Aufmerksamkeit beim Öffnen der Nachricht. Andererseits – und dies ist eventuell noch wichtiger – blockieren viele Unternehmen genau aus diesem Grund verschlüsselte Nachrichten um nicht mithilfe höchster Sicherheit Schädlinge in das Hausnetz zu befördern.


Anzeige



Teile diesen Artikel

Das könnte Dich auch interessieren …

3 Antworten

  1. 15. Dezember 2011

    […] einigen Wochen haben wir an dieser Stelle das Thema Zertifikat und Verschlüsselung für Einsteiger behandelt. Heute wollen wir etwas tiefer auf einen wichtigen Punkt dazu eingehen. Die digitale ID. […]

  2. 2. Mai 2014

    […] sollte in der Mailübertragung Pflicht sein, S/MIME nur dann, wenn im Unternehmen eine PKI-Infrastruktur implementiert ist. Die Angaben zu Benutzer, […]

  3. 5. Juni 2014

    […] Unterschied von TLS und anderen Transportverschlüsselungsmethoden kodieren S/MIME und PGP die Nachricht selbst. Der Versender nutzt dabei den öffentlichen Schlüssel des Empfängers und […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*