M 5.100 Einsatz von Verschlüsselungs- und Signaturverfahren für die Exchange 2000 Kommunikation
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
Verschlüsselung und digitale Signaturen dienen dem Schutz der Integrität und Vertraulichkeit sowie auch der Nicht-Abstreitbarkeit elektronisch übermittelter Nachrichten.
Für eine Absicherung der E-Mail-Kommunikation stehen entsprechend dem OSI-Schichtenmodell mehrere mögliche Lösungsansätze zur Verfügung:
- Auf physikalischer Ebene ist eine Linkverschlüsselung denkbar, jedoch im allgemeinen nicht praktikabel.
- Auf Netzebene ist die Einrichtung eines Virtuellen Privaten Netzes (VPN) möglich. Wegen der hohen Verbreitung des Internet-Protokolls IP wird dabei in der Regel der Standard IPSec verwendet. IPSec erlaubt die Absicherung von IP-Verbindungen zwischen Standorten, zwischen Endgeräten und auch von Endgeräten zu Standorten. Es können sowohl fest vorkonfigurierte Schlüssel (preshared keys) als auch Public Key Infrastrukturen (PKI) für das Schlüsselmanagement verwendet werden. Um auf Basis von IPSec eine Absicherung zu erreichen, müssen alle am E-Mail-Routing beteiligten Rechner über IPSec kommunizieren. An den Knotenpunkten liegt die Information jeweils im Klartext vor.
- Auf Nachrichten-Ebene haben sich in der Praxis die Standards S/MIME und PGP durchgesetzt. Das Schlüsselmanagement von S/MIME setzt den Betrieb einer PKI voraus. PGP setzt dagegen auf ein offenes Schlüsselmanagement und verlangt keinen Aufbau einer zentralen PKI.
Die Absicherung auf Nachrichten-Ebene wird von Drittherstellern in der Regel als Plug-In-Lösung für einen oder mehrere E-Mail-Clients realisiert. Im Projekt SPHINX werden Produkte verschiedener Hersteller auf übergreifende Interoperabilität untersucht. Weitere Informationen zu SPHINX finden sich auf dem Internet-Angebot des BSI (http://www.bsi.bund.de) und M 5.110 Absicherung von E-Mail mit SPHINX (S/MIME).
Auch auf der Ebene des Dateisystems sind Lösungen, z. B. in Form von Shell-Erweiterungen, zur Verschlüsselung und Signatur einzelner Dateien verfügbar. Derart geschützte Dateien können dann als Dateianhänge via E-Mail versendet werden.
Public Key Infrastruktur
Outlook 2000 bietet einen eingebauten Mechanismus zur E-Mail-Verschlüsselung auf Basis von S/MIME. Dieser nutzt die Vertrauensbeziehungen einer Public Key Infrastruktur, die mit Hilfe der eigenen Windows 2000 Enterprise CA oder einer fremden CA betrieben werden kann. Die von einer CA selbstsignierten Wurzelzertifikate müssen dem System zur Verfügung stehen. Dazu sollten die als vertrauenswürdig geltenden Wurzelzertifikate zentral über eine Windows 2000 Gruppenrichtlinie konfiguriert werden.
Als nächster Schritt zur Nutzung von Verschlüsselung und digitaler Signatur in Outlook 2000 müssen die Benutzer ihre Schlüsselinformationen, bestehend aus dem Zertifikat (signierter öffentlicher Schlüssel) und dem zugehörigen privaten Schlüssel, erhalten. Die Windows 2000 Enterprise CA bzw. der Schlüsselverwaltungsdienst Windows 2000 Key Management Services (KMS) unterstützen eine organisationsweite Verteilung der Schlüsselpaare.
Hierzu muss zunächst eine Windows 2000 Enterprise CA mit wenigstens einem Enrollment Agent installiert werden. Danach lässt sich der KMS unter Verwendung eines Exchange Certificate Templates betreiben. Der Start des KMS wird innerhalb des Exchange-Snap-Ins der Microsoft Management Console (MMC) vorgenommen, und zwar unter dem Punkt Advanced Security | Key Manager.
Weiterhin muss Outlook 2000 mit der so genannten Corporate or Workgroup Service Option in der Organisation installiert sein. Nun lassen sich die Schlüsselinformationen der Benutzer verteilen.
Kennwörter
Bei der Installation des Schlüsselverwaltungsdienstes wird ein Kennwort zum Starten des KMS generiert. Dabei stehen zwei Möglichkeiten zur Verfügung: das Kennwort ist bei jedem Start der KMS manuell einzugeben oder auf einer Diskette zu speichern, um so einen automatischen Start der KMS zu ermöglichen. Die manuelle Eingabe des Startkennworts wird als die sicherere Methode empfohlen.
Da während der KMS-Installation ein Standard-Kennwort für die spätere Administration festgelegt wird, muss dieses nach der Installation umgehend geändert werden.
Der KMS-Dienst unterstützt das Vier-Augen-Prinzip. Es wird empfohlen, folgende sicherheitsrelevante Aufgaben nur von (mindestens) zwei Administratoren erledigen zu lassen:
- Hinzufügen/Löschen von Administratoren und Modifizieren der Kennwort-Policy,
- Wiederherstellung eines Benutzerschlüssels (key recovery),
- Import/Export von Benutzereinträgen.
Die Anzahl der erforderlichen Administratoren wird im Exchange System Manager unter Key Manager | Properties | Passwords festgelegt.
Auswahl geeigneter kryptographischer Algorithmen und Formate
Exchange 2000 bietet in seiner Konfiguration die Möglichkeit, zwischen zwei Formaten für verschlüsselte E-Mails zu wählen: S/MIME oder Exchange 4.0/5.0. Die Wahl des Formats hängt von den zu unterstützenden Clients ab. Beim geplanten Einsatz von Outlook 2000 (auch Outlook 98) sollte das S/MIME-Format ausgewählt werden. Exchange 2000 erlaubt weiterhin die Wahl eines bevorzugten Verschlüsselungsalgorithmus. Es wird empfohlen, für die Verschlüsselung den 3DES-Algorithmus zu verwenden. Die Einstellungen für das Verschlüsselungsformat und den bevorzugten Verschlüsselungsalgorithmus werden im Exchange System Manager unter Advanced Security | Encryption Configuration | Properties | Algorithms vorgenommen.
Der KMS-Dienst kann Benutzerzertifikate in zwei verschiedenen Zertifikatsversionen ausstellen: X.509 v1 und X.509 v3. Die Version 1 ist für die Kompatibilität mit Exchange 4.0 und 5.0 erforderlich. Besteht eine solche Forderung nicht, sollte die Version 3 verwendet werden. Diese Einstellungen finden sich im Exchange System Manager unter Key Manager | Properties | Enrollment | Certificate Version.
Schlüsselverteilung
Die Schlüsselverteilung läuft generell in mehreren Phasen ab: die Erstellung der Schlüsselpaare und Sicherheitstoken durch einen Administrator, die Zustellung des Sicherheitstokens an die Benutzer und das Importieren der erzeugten Schlüssel durch die Benutzer.
Besonders sicherheitskritisch ist dabei die Zustellung der erzeugten Sicherheitstoken an die Benutzer. Hierfür bestehen zwei Möglichkeiten: Das Sicherheitstoken kann entweder manuell vom Administrator verteilt oder aber automatisch per E-Mail zugestellt werden. Da das Sicherheitstoken in einer E-Mail im Klartext übermittelt wird und somit unter Umständen von einem Angreifer mitgelesen werden kann, wird empfohlen, die standardmäßig eingestellte manuelle Verteilung beizubehalten.
Sollen die Benutzer über die Ausstellung des Sicherheitstokens automatisch benachrichtigt, das Sicherheitstoken selbst jedoch nicht automatisch in einer E-Mail übermittelt werden, wird folgende Vorgehensweise empfohlen: Die automatische Zustellung wird zwar aktiviert, aber die Vorlage für die automatische E-Mail-Benachrichtigung wird angepasst, indem die Variable %TOKEN% entfernt wird. Dies erfolgt im Exchange System Manager unter Key Manager | Properties | Enrollment | Token distribution | Customize Message.
Weitere Sicherheitsvorkehrungen
Um einen sicheren Betrieb zu gewährleisten, sind die folgenden Vorkehrungen zu treffen:
- Absicherung der eingesetzten Komponenten,
- Verwendung von Zertifikatsrückruflisten (Certificate Revocation List - CRL),
- Schulung der Administratoren,
- Schulung der Benutzer (speziell im Umgang mit verschlüsselten bzw. signierten Nachrichten).
Zusätzlich zu den allgemein bekannten Systemkomponenten von Exchange 2000 müssen noch die Komponenten abgesichert werden, die für den Betrieb von Exchange mit Verschlüsselungs- und Signatur-Funktionalität zuständig sind. Dies sind vor allem die Zertifizierungsinstanz (CA), der Key Management Service (KMS) und die KMS-Datenbank (Exchsrvr \ KMSData \ Kmsmdb.edb).
Beim Rückruf eines oder mehrerer Benutzerzertifikate spielt die Gültigkeitsdauer der Zertifikatsrückrufliste eine wesentliche Rolle. Es wird empfohlen, die CRL nach einem Rückruf sofort zu veröffentlichen und nicht auf den nächsten eingeplanten Zeitpunkt der Veröffentlichung zu warten. Es ist jedoch zu beachten, dass durch die Veröffentlichung einer neuen CRL die alte Liste nicht ihre Gültigkeit verliert und somit die Clients, die bereits eine gültige CRL besitzen, von der neuen keinen Gebrauch machen werden. Generell empfiehlt es sich daher, die Gültigkeitsdauer von CRLs relativ kurz zu bemessen, so dass die Clients entsprechend häufig ihre CRLs erneuern müssen.
Verschlüsselung der Chat-Kommunikation
Chat ist ein Klartextprotokoll, das die Verschlüsselung über SSL oder TLS nicht unterstützt. Soll diese Kommunikation geschützt werden, so ist der Einsatz eines VPN in Betracht zu ziehen (Point-to-Point Tunneling-Protokoll - PPTP, Layer 2 Tunneling Protocoll - L2TP, IPSec).
Ergänzende Kontrollfragen:
- Sind die Benutzer im Umgang mit der Verschlüsselungs- und Signaturfunktionalität geschult worden?
- Wurde das Standard-Kennwort geändert?
- Ist der Ablauf der Zustellung der Sicherheitstoken an die Benutzer zweckmäßig festgelegt?