Sicherheit

Sichern von E-Mails mithilfe digitaler Zertifikate

Matt Clapham and Blake Hutchinson

Auf einen Blick:

• Erstellen einer überprüfbaren Identität
• Aktualisierung des Zertifikatstatus
• Abrufen und Austauschen von Zertifikaten
• Problembehandlung für Ihr S/MIME-System

Seit Jahrtausenden verwenden Menschen unterschiedliche Methoden zum Verbergen von Informationen während der Weitergabe, zum Überprüfen des Absenders und zum Authentifizieren der Nachricht. Heute gibt es eine Methode für alle drei Aufgaben, die sich immer mehr verbreitet. Secure Multi-Purpose Internet Mail Extensions (S/MIME)

ist ein System für das sichere Senden von E-Mails mithilfe von Verschlüsselung und digitalen Signaturen.

Es gibt derzeit zwei Haupttypen von Technologien zum Verschlüsseln (und Verbergen): Algorithmen mit symmetrischen (geheimen) Schlüsseln, wie z. B. den Datenverschlüsselungsstandard (Data Encryption Standard, DES) oder den erweiterten Verschlüsselungsstandard (Advanced Encryption Standard, AES), sowie Algorithmen mit asymmetrischen (öffentlichen/privaten) Schlüsseln, wie z. B. RSA oder ECC (Elliptical Curve Cryptography). Die heutigen Absenderprüfungstools sind mathematische unidirektionale Funktionen, Hashes genannt, die eindeutige Signaturen erstellen. Zwei gebräuchliche Hashmethoden sind der Message Digest 5-Algorithmus (MD5) und der Secure-Hash-Algorithmus (SHA). Computer können diese zum Generieren eines eindeutigen Hash oder einer Zahl verwenden, der bzw. die dem jeweiligen Quelltext entspricht (identische Quelltexte ergeben denselben Hashwert). Diese einfachen Tools werden genutzt und kombiniert, um ein PKI-System (Public Key-Infrastruktur) zu erstellen.

Eine überprüfbare Identität

Zertifizierungsstellenressourcen

• Verwenden einer Zertifizierungsstelle für das verschlüsselnde Dateisystem
• Zertifizierungsstellenserver können nicht umbenannt oder aus dem Netzwerk entfernt werden
• Entfernen einer vertrauenswürdigen Zertifizierungsstelle von Computern in der Domäne
• Außerbetriebsetzung einer Windows-Unternehmenszertifizierungsstelle und Entfernen aller verwandten Objekte aus Windows Server 2003 und Windows 2000 Server
• Verschieben einer Zertifizierungsstelle auf einen neuen, auf einem Domänencontroller ausgeführten Computer

Identitäten innerhalb eines PKI-Systems werden mithilfe digitaler Zertifikate verwaltet, die sich nicht wesentlich von dem Identifikationsdokument unterscheiden, das die meisten Menschen für Grenzübertritte bei sich tragen, – dem Reisepass. Der Reisepassstandard der digitalen Zertifikatwelt ist das X.509-Format, und es wird allgemein sowohl für das Signieren als auch für das Verschlüsseln in Technologien wie S/MIME, Internetprotokollsicherheit (IPSec), Secure Shell (SSH), Drahtlosnetzwerksicherheit, virtuellen privaten Netzwerken (VPN) und sogar sicheren Serverkommunikationen (z. B. SSL-Websites) verwendet.

Zertifikate bauen auf asymmetrischer Kryptografie und Hashes auf. Zum Erstellen eines Zertifikats generiert der Anforderer (die Entität, die einen Schlüssel wünscht, der von einer höheren Autorität signiert wurde) einen privaten Schlüssel. Der Schlüssel wird weggeschlossen, sodass seine Echtheit nie in Frage gestellt wird. Zusammen mit dem privaten Schlüssel wird auch ein entsprechender öffentlicher Schlüssel generiert. Wie der Name andeutet, ist der öffentliche Teil des Paars nicht geheim und wird frei verteilt, obwohl selbst das auf eine gewisse Weise seine Echtheit sicherstellt.

Dieses Schlüsselpaar ermöglicht zwei grundlegende Vorgänge. Zunächst kann jeder den öffentlichen Schlüssel verwenden, um etwas zu verschlüsseln, das nur der private Schlüssel entschlüsseln kann. Darüber hinaus kann der öffentliche Schlüssel verwendet werden, um etwas zu entschlüsseln, das mit dem privaten Schlüssel verschlüsselt wurde. Das ist wichtig zum Überprüfen einer Signatur, die nur von einem privaten Schlüssel erstellt worden sein kann.

Die Anforderung an die Zertifizierungsstelle umfasst Details wie z. B. die Identität der Person oder des Computers, für die bzw. den der Schlüssel vorgesehen ist, den Algorithmustyp und die Stärke sowie den öffentlichen Teil des Schlüsselpaars. Die Zertifizierungsstelle empfängt und überprüft die Informationen in der Anforderung und erstellt mithilfe eines Hashalgorithmus einen eindeutigen Bezeichner, der den Informationen entspricht.

Mithilfe des privaten Schlüssels verschlüsselt die Zertifizierungsstelle den Hash der Informationen und assembliert ihn in ein Standardformat (wie z. B. X.509), wobei ein Zertifikat erstellt wird, das der ursprünglichen Anforderung entspricht. Das X.509-Zertifikat enthält eine Liste der Ansprüche einschließlich der Identität des Zertifikats, eines Gültigkeitszeitraums, des öffentlichen Schlüssels sowie der Vorgänge, für die das Zertifikat verwendet werden kann. Das Zertifikat wird dann an den Anforderer zurückgegeben. Es ist ein Beweis der eigentlich besagt: „Ich, die Zertifizierungsstelle, verbürge mich für diesen öffentlichen Schlüssel und den zugehörigen privaten Teil für alle hierin beschriebenen Verwendungen.“

Bei Stammzertifizierungsstellen (jene auf der höchsten Ebene der Vertrauenskette) sind Zertifikate selbstsigniert. Die akzeptabelsten Stammzertifizierungsstellen sind im grundlegenden Betriebssystem oder in der Anwendung vorinstalliert, können aber über Pakete oder die Unternehmenskonfiguration aktualisiert oder verändert werden. Zwischen der Stammzertifizierungsstelle und einem untergeordneten Knoten (der in der Regel eine einzelne Person oder ein System beschreibt) kann es eine oder mehrere Zwischenzertifizierungsstellen geben.

Die Kette besteht aus allen Knoten und allen vorhergehenden Zertifikaten, die darin eingebettet sind, signiert von der Zertifizierungsstelle auf dieser Ebene. Ein Dritter, der versucht, das Zertifikat zu validieren, kann den lokal berechneten Hash prüfen und mit jenem vergleichen, der vom Zertifikat verschlüsselt wurde. Dazu wird der entsprechende öffentliche Schlüssel für diese spezielle Zertifizierungsstelle oder Person verwendet. Das ist es – eine vollständig validierte Vertrauenskette – vorausgesetzt natürlich, die Stammzertifizierungsstelle ist vertrauenswürdig.

Aktualisieren des Zertifikatstatus

Jede gute Zertifizierungsstelle verfügt über ein Mittel zum Verteilen einer Liste mit Zertifikaten, die nicht mehr vertrauenswürdig sind. Diese Zertifikatsperrliste (Certificate Revocation List, CRL) beschreibt, welche ausgegebenen Elemente von der Zertifizierungsstelle explizit abgewiesen wurden. Praktischerweise ist der Speicherort der CRL in der Regel eine Eigenschaft des Zertifizierungsstellenzertifikats.

Zertifizierungsstellen geben CRLs routinemäßig auf zwei Grundlagen aus: einem Zeitplan (möglicherweise alle zwei Wochen) oder einem Ereignis (eines, das anzeigt, dass einem ausgestellten Zertifikat nicht mehr vertraut werden sollte). Eine Zertifizierungsstelle signiert ihre ausgestellten CRLs bei Veröffentlichung. Wenn ein Empfangssystem die Gültigkeit einer Kette evaluiert, versucht es in der Regel, die CRL für jede ausstellende Zertifizierungsstelle in der Kette zu erlangen (über die Details, die in die Zertifikate selbst eingebettet sind, oder durch einen vordefinierte vertrauenswürdige Verteilungsmethode). Wenn eine CRL nicht verfügbar ist, darf der Client auf eine neue, erfolgreich zwischengespeicherte Kopie zurückgreifen, solange sie nicht älter ist als der festgelegte CRL-Aktualisierungszeitraum. Schlägt das jedoch fehl, zeigen die Clientsysteme in der Regel Fehler an, die besagen, dass das Zertifikat gültig erscheint, aber der Sperrstatus nicht bestimmt werden kann.

Viele Anwendungen brauchen bedeutend länger, um ein Zertifikat zu laden, wenn sie die Kette oder die CRL nicht für jeden Knoten in der Kette überprüfen können. In Abhängigkeit davon, was das Zertifikat schützen sollte, kann der Benutzer ihm vertrauen oder nicht. Ein regelmäßig aktualisierter, allgemein verfügbarer CRL-Verteilungspunkt ist für jede Zertifizierungsstelle zwingend notwendig, vor allem für die öffentlichen Stammzertifizierungsstellen.

Stammzertifizierungsstellen sind die Grundlage der Zertifikatkette, und Verkettung ist die Grundlage aller Zertifikathierarchien. Die meisten Clientsysteme oder Anwendungen werden nur annehmen, dass ein untergeordnetes Zertifikat gültig ist, wenn die Kette zurück zu einer vertrauenswürdigen Stammzertifizierungsstelle führt. Das kann eine Unternehmenszertifizierungsstelle sein, die dem Unternehmen gehört und von ihm betrieben wird, oder eine öffentliche Stammzertifizierungsstelle (wie z. B. VeriSign).

Von öffentlichen Stammzertifizierungsstellen wird höchste Zuverlässigkeit erwartet, sodass die Integrität gesichert ist. Unternehmen sollten um die gleiche Zuverlässigkeit für ihre innerbetrieblichen Vorgänge bemüht sein, da die absolute Vertrauenswürdigkeit einer Stammzertifizierungsstelle in diesem Zusammenhang ebenso wichtig ist. Für optimalen Schutz sollten Stammzertifizierungsstellen offline sein und nur zum Ausstellen von Zertifikaten und zum Aktualisieren von CRLs verwendet werden. Weitere Informationen zu bewährten Methoden des Zertifizierungsstellenbetriebs finden Sie in den Artikeln, die in der Randleiste „Zertifizierungsstellenressourcen“ aufgeführt sind.

Ein wichtiger Aspekt, der bedacht werden sollte, betrifft die Schlüsselwiederherstellung. Um Untersuchungen zu vereinfachen und sicherzustellen, dass Daten von einem Benutzer nicht unwiederbringlich weggeschlossen werden, sollte das Unternehmen Sicherungskopien von allen vom Benutzer veröffentlichten Schlüsseln anfertigen. Außerdem sollten diese Sicherungskopien in einem sicheren Repository gespeichert werden. Geht der Schlüssel eines Benutzers verloren, z. B. wenn eine Smartcard in einem Taxi zurückgelassen wird, kann trotzdem auf den Inhalt zugegriffen werden, der durch den Schlüssel geschützt ist.

Letztendlich gibt es in jedem guten kryptografischen System das Konzept der Lebenszyklusverwaltung. Je schneller Computer werden, desto schwächer werden Algorithmen. Jedes gute kryptografische System benötigt die Fähigkeit, sich zu erneuern und mit der Zeit zu neuen Algorithmen und Schlüsselgrößen überzugehen. Zertifizierungsstellen sollten angemessen aktualisiert werden, wenn kryptografische Schwächen identifiziert werden und bestimmte Funktionen eingeführt werden oder auslaufen.

Implementieren von S/MIME

Es gibt mehrere Phasen für das Starten, Verfassen, Senden und Empfangen signierter oder verschlüsselter E-Mails mithilfe von S/MIME. Die Details, Probleme und potenziellen Lösungen werden im Folgenden anhand eines typischen S/MIME-Szenarios erläutert: zwei Benutzer, die einander mithilfe von Microsoft® Office Outlook® 2007 signierte und/oder verschlüsselte E-Mails senden, und zwar von zwei verschiedenen Active Directory®-Strukturen und unterschiedlichen Zertifizierungsstellenketten (also von betrieblich getrennten Entitäten, entweder im selben Unternehmen oder nicht).

Nehmen wir an, dass die notwendige Infrastruktur bereits eingerichtet ist, um die Vorgänge zu ermöglichen, die beschrieben werden sollen. In unserem Fall verwenden wir einen in Active Directory integrierten Unternehmenszertifikatserver.

Abrufen von Zertifikaten

Die erste Aufgabe besteht darin, die geeigneten Zertifikate abzurufen. Öffnen Sie dafür die Zertifikatverwaltungs-MMC (certmgr.msc), klicken Sie mit der rechten Maustaste auf den persönlichen Ordner, und wählen Sie „Alle Aufgaben“ aus der Popupliste und anschließend „Neues Zertifikat anfordern“ aus der Liste aus.

Dadurch wird der Assistent für die Zertifikatregistrierung gestartet (siehe Abbildung 1). Standardmäßig werden mehrere unternehmensbezogene Optionen angezeigt, aber das Benutzerzertifikat ist das wichtige. Es wird verwendet, um später die Signatur- und Verschlüsselungsprozesse zu aktivieren. Das Zertifikat muss für Folgendes verwendet werden können:

Abbildung 1** Anfordern eines Zertifikats **(Zum Vergrößern auf das Bild klicken)

• Digitale Signaturen (Erstellen einer Nachricht mit einem Echtheitssiegel des Erstellers)
• Schlüsselverschlüsselung (Schützen eines Schlüssels mit einem anderen für Technologien wie das verschlüsselnde Dateisystem)
• Sichere E-Mail (verschlüsseltes Messaging, das nur vom gewünschten Empfänger gelesen werden kann, der in Besitz des entsprechenden privaten Schlüssels ist)

Zum Senden einer mit S/MIME signierten E-Mail ist die Schlüsselverschlüsselungseigenschaft nicht erforderlich. Um jedoch eine verschlüsselte E-Mail senden oder empfangen zu können, wird diese Eigenschaft benötigt, nicht aber die Signatureigenschaft. Standardmäßig ermöglichen die Vorlagen in den Windows®-Zertifikatdiensten diese drei Eigenschaften. Wenn der Benutzer keine neuen Zertifikate anfordern darf, werden beim Start des Assistenten keine angezeigt. Wenn keine Unternehmenszertifizierungsstelle verfügbar ist, wird dem Benutzer ein „Registrierungsfehler“ angezeigt, der besagt, dass die Domäne oder die Zertifizierungsstelle nicht kontaktiert werden konnte. Für diese exemplarische Vorgehensweise nehmen wir an, dass ein einziges Zertifikat sowohl Signatur als auch Verschlüsselung ermöglicht.

Austauschen von Zertifikaten

Die einfachste Möglichkeit für zwei Benutzer, mit dem Senden verschlüsselter E-Mails zu beginnen, besteht einfach im Senden signierter Nachrichten. Nach dem Verfassen einer Nachricht klickt der Benutzer auf die Schaltfläche „Signieren“. (Möglicherweise ist die Schaltfläche in Outlook standardmäßig ausgeblendet, bis sie mindestens einmal verwendet wurde. Klicken Sie dazu im Fenster einer neuen Nachricht auf „Optionen“ und anschließend auf die Schaltfläche „Sicherheitseinstellungen...“, und aktivieren Sie im Dialogfeld „Sicherheitseigenschaften“ das Kontrollkästchen „Diese Nachricht digital signieren“.) Die Schaltfläche „Signieren“ (ein kleiner gelber Umschlag mit einem roten Band) fügt der Nachricht eine digitale Signatur hinzu, um die Echtheit der Quelle zu gewährleisten.

Nach dem Klicken auf die Schaltfläche „Senden“ wird der Benutzer u. U. aufgefordert, zusätzliche Beweise für den Schlüsselbesitz bereitzustellen, z. B. durch Einlegen einer Smartcard oder Eingeben einer PIN. Dies ist abhängig von den jeweiligen Methoden des Schlüsselschutzes, die im Unternehmen eingerichtet sind.

Der Benutzer, der die mit S/MIME signierte Nachricht empfängt, muss den Namen des Absenders anzeigen und mit der rechten Maustaste auf diesen klicken (hinter „Von:“) und aus dem Kontextmenü „Zu Outlook-Kontakten hinzufügen“ auswählen. Dadurch wird der neue Kontakteintrag entweder hinzugefügt, oder ein vorhandener Kontakt wird aktualisiert. Das Zertifikat ist dann diesem bestimmten Kontakteintrag zugeordnet. Beachten Sie, dass innerhalb einer normalen Active Directory-Umgebung (zwei Benutzer in der gleichen Stammstruktur oder demselben Unternehmen) die Verteilung öffentlicher Benutzerzertifikate automatisch über Attribute im Active Directory-Objekt des Benutzers erfolgt.

Eine andere Möglichkeit, Zertifikate auszutauschen, besteht darin, dass jeder Benutzer seine S/MIME-Zertifikate als Anlage sendet. Dafür müssen beide Teilnehmer Ihre Zertifikate in eine CER-Datei exportieren. Die Benutzer müssen das Zertifikat anzeigen und den Exportvorgang ausführen, der nachfolgend erläutert wird, wobei sie darauf achten müssen, dass der private Schlüssel nicht exportiert wird (siehe Abbildung 2).

Abbildung 2** Exportieren Sie beim Austausch von Zertifikaten nicht den privaten Schlüssel **(Zum Vergrößern auf das Bild klicken)

Jeder Empfänger erstellt dann manuell einen Kontakteintrag in Outlook und fügt das Zertifikat dem Eintrag des Senders hinzu. Nachdem die beiden Benutzer Zertifikate ausgetauscht haben, können sie einander verschlüsselte E-Mails senden.

Problembehandlung

Manchmal hat der Empfänger Schwierigkeiten beim Öffnen der verschlüsselten Nachricht. Die drei wahrscheinlichsten Ursachen für Probleme, die wir in diesem Bereich beobachtet haben, sind Stammzertifizierungsstellen, die nicht vertrauenswürdig sind, Zwischenzertifizierungsstellen, die nicht überprüft werden können, sowie CRLs, die nicht verfügbar sind.

Eine nicht vertrauenswürdige Stammzertifizierungsstelle führt in Outlook in der Regel zu einer Fehlermeldung in Verbindung mit der Signatur: „Probleme mit der Signatur. Klicken Sie auf die Signaturschaltfläche, um Details anzuzeigen.“ Öffnen Sie zum Lösen des Problems das Zertifikat in Outlook, und klicken Sie im Popupdialog auf die Schaltfläche „Zertifizierungsstelle anzeigen“. Sehen Sie sich die Nachricht auf der Registerkarte „Allgemein“ des Dialogfelds „Zertifikateigenschaften“ an. Wird angezeigt, dass das Stammzertifikat der Zertifizierungsstelle nicht vertrauenswürdig ist und installiert werden muss, wechseln Sie zur Registerkarte „Details“. Klicken Sie auf die Schaltfläche „In Datei kopieren...“, und folgen Sie dem Assistenten, wobei Sie alle Standardeinstellungen annehmen und bei entsprechender Aufforderung einen Dateinamen und einen Ordner eingeben.

Öffnen Sie nun eine neue MMC (Microsoft Management Console) als Computeradministrator. Wählen Sie „Datei“|„Snap-In hinzufügen/entfernen“ (Strg+M), wählen Sie „Zertifikate“, und fügen Sie es für das Computerkonto hinzu, indem Sie bei Aufforderung „Lokaler Computer“ wählen. Erweitern Sie als Nächstes in der linken Struktur den Knoten „Zertifikate“, und verfahren Sie gleichermaßen mit den vertrauenswürdigen Stammzertifizierungsstellen. Klicken Sie mit der rechten Maustaste, und wählen Sie „Alle Aufgaben“|„Importieren“ aus dem Popupmenü aus. Importieren Sie die zuvor erwähnte exportierte Zertifikatdatei zu den vertrauenswürdigen Stammzertifizierungsstellen, und klicken Sie auf „Fertig stellen“. Anschließend muss der betroffene Benutzer Outlook neu starten.

Diese Vorgehensweise sollte nur verwendet werden, um eine Stammzertifizierungsstelle hinzuzufügen, von der Sie wissen, dass sie vertrauenswürdig ist. Nicht alle Stammzertifizierungsstellen sind gleich. Achten Sie darauf, wer im Besitz der Stammzertifizierungsstelle ist und diese betreibt, bevor Sie diese Methode zum Hinzufügen einer Stammzertifizierungsstelle zum Speicher des gesamten Systems verwenden. Wenn Ihr Unternehmen die Liste vertrauenswürdiger Stammzertifizierungsstellen über die Gruppenrichtlinie kontrolliert, wird die Konfiguration auf Clientsysteme übertragen. In diesem Fall funktionieren die Anweisungen möglicherweise nicht. Sollte dies der Fall sein, müssen Sie eventuell nach Alternativen suchen, wie z. B. sicheren Websites oder Servern zum Austauschen von Daten, da E-Mails hier nicht problemlos verwendbar und ausreichend geschützt sind.

Das zweite bereits erwähnte Problem, dass Zwischenzertifizierungsstellen nicht überprüft werden können, tritt in der Regel in zwei Situationen auf: Ein Client, der das Zertifikat überprüfen möchte, kann den im Zertifikat festgelegten Speicherort für AIA (Authority Information Access, Zugriff auf Stelleninformationen) nicht abrufen, oder der Client verfügt über eine Version des Zertifikats der Zwischenzertifizierungsstelle, die nicht mit dem übereinstimmt, was die Zertifizierungsstelle ausstellt (der Client ist oft ein oder zwei Versionen hinterher). Diese Bedingungen erscheinen in der Outlook-Benutzeroberfläche sehr ähnlich. Wir haben dies nur in einer ganz bestimmten Situation gesehen, als eine Zertifizierungsstelle in der Mitte der Kette abgelaufen ist und erneut ausgestellt wurde, bevor andere, von ihr ausgestellte untergeordnete Zertifikate abgelaufen waren.

Im Grunde tritt dieses Problem auf, wenn die Kette Lücken aufweist. Einige übergeordnete Zertifikate sind möglicherweise nicht detailliert genug oder nicht richtig in die untergeordneten Knoten eingebettet, wodurch die Situation weiter erschwert wird.

Um dieses Problem zu lösen, muss der Sender eine neue Nachricht öffnen und auf „Optionen“ und dann auf die Schaltfläche „Sicherheitseinstellungen“ und auf die Schaltfläche „Einstellungen ändern“ klicken. Klicken Sie anschließend für das Signaturzertifikat auf die Schaltfläche „Auswählen“ und dann im Popupdialog „Zertifikat auswählen“ auf die Schaltfläche „Zertifikat anzeigen“. Wechseln Sie zur Registerkarte „Zertifizierungspfad“, wählen Sie den Aussteller des untergeordneten Knotens (in der Kette eine Stufe höher), und klicken Sie auf die Schaltfläche „Zertifikat anzeigen“. Klicken Sie auf die Registerkarte „Details“ und dann auf die Schaltfläche „In Datei kopieren...“. Beenden Sie anschließend den Exportassistenten, indem Sie „PKCS #7 (.P7B)“ auswählen. Vergewissern Sie sich, dass die Option „Alle Zertifikate im Zertifizierungspfad einbeziehen“ aktiviert ist (siehe Abbildung 3). Senden Sie nun dem gewünschten Empfänger die exportierte Kettendatei.

Abbildung 3** Schließen der Lücken in einer Zertifikatkette **(Zum Vergrößern auf das Bild klicken)

Nach dem Abrufen der exportierten Zertifikatkette muss der Empfänger die Kette ähnlich wie beim zuvor beschriebenen Importieren einer Stammzertifizierungsstelle öffnen und importieren. Der einzige Unterschied besteht darin, dass die Speicherung in den Zwischenzertifizierungsstellen erfolgen sollte. Wenn die Nachricht geöffnet und das Zertifikat in Outlook als gültig angezeigt wird, funktioniert alles einwandfrei.

Auch für das dritte Problem, dass keine CRLs verfügbar sind, ist die Problembehebung vergleichsweise einfach. Zunächst wird die Antwort von Outlook ähnlich wie beim vorangegangenen Problem aussehen. Allerdings wird der Fehler auch dann angezeigt, wenn die Stamm- oder Zwischenzertifizierungsstellen vertrauenswürdig sind. Öffnen Sie für jede Stufe der Zertifikatkette über der untergeordneten Stelle die Zertifikateigenschaften, dann die Registerkarte „Details“, und sehen Sie sich das Feld namens „CRL-Verteilungspunkte“ an.

Prüfen Sie für jeden aufgeführten CRL-Verteilungspunkt (besonders jene, auf die vom Internet aus zugegriffen werden kann), ob die URL der CRL-Datei geöffnet werden kann. Bewegen Sie sich in der Kette nach erfolgreicher Überprüfung um eine Stufe nach oben. Ist eine CRL nicht verfügbar, so ist dies wahrscheinlich die Ursache des Problems. Um das Problem zu lösen, sollten Sie sicherstellen, dass Ihre lokale Netzwerkrichtlinie Ihren Zugriff nicht blockiert. Versuchen Sie andernfalls, das Unternehmen zu kontaktieren, das in Besitz der Zertifizierungsstelle ist, oder warten Sie, bis der CRL-Verteilungspunkt der Zertifizierungsstelle in den Betriebsstatus zurückgekehrt ist.

Verteilen von Zertifikaten

Die Verteilung ist einfach. Im Grunde wird die signierte Nachricht an einen E-Mail-Server übertragen, der sie dann über eine erprobte und bewährte Methode, SMTP, von einem Speicherort an einen anderen überträgt. Das einzige Problem, das wir mit signierten oder verschlüsselten E-Mails bei der Übertragung feststellen konnten, besteht darin, dass einige E-Mail-Systeme signierte oder verschlüsselte Nachrichten zurückweisen oder beschädigen. Die Problembehebung besteht darin, mit dem IT-Manager des Systems zusammenzuarbeiten, sodass diese Nachrichtentypen zugelassen werden. Wahrscheinlich werden Sie jedoch mit der Tatsache leben müssen, dass einige Nachrichtentypen blockiert werden. Der Empfänger wird sicher gute Gründe haben, verschlüsselte Nachrichten in einer bestimmten Betriebsumgebung nicht zuzulassen.

Verschlüsseln von Antworten

Zum Erstellen einer verschlüsselten Antwort (vorausgesetzt der Bootstrappingprozess wurde bereits abgeschlossen) muss der Absender lediglich eine Nachricht verfassen und dann im Nachrichtenerstellungsfenster auf die Schaltfläche „Verschlüsseln“ klicken (den kleinen gelben Umschlag mit dem blauen Schloss). Sollte die Schaltfläche „Verschlüsseln“ nicht zur Verfügung stehen, führen Sie die Schritte für das Senden einer signierten Nachricht bis auf den letzten Schritt aus, und aktivieren Sie stattdessen das Kontrollkästchen „Nachrichteninhalte und Anlagen verschlüsseln“.

Die S/MIME-Signatur ist für das Senden einer verschlüsselten Nachricht an einen Empfänger nicht erforderlich, aber beides passt gut zusammen, da der Leser durch das Signieren den Sender prüfen kann (die Verschlüsselungsfunktion ermöglicht keine Aussagen über den Sender). Beim Verschlüsselungsprozess wird versucht, die Nachricht mit den bekannten öffentlichen Schlüsseln aller Empfänger zu verschlüsseln. Wenn das System für einige gewünschte Empfänger keine Zertifikate finden kann, werden sie in einem Popupdialog gekennzeichnet. Dort besteht die Möglichkeit, die Nachricht unverschlüsselt zu senden (siehe Abbildung 4).

Abbildung 4** Sie können sich entscheiden, eine unverschlüsselte Nachricht zu senden, wenn ein Problem mit einem Zertifikat auftritt. **(Zum Vergrößern auf das Bild klicken)

Standardmäßig sollte das Signieren und Verschlüsseln mit anderen vergleichbar konfigurierten Clientsystemen funktionieren, aber gelegentlich treten beim Senden von Nachrichten, die mit unterschiedlichen Versionen verschlüsselt oder signiert wurden, Probleme auf, wenn der Hash- oder Verschlüsselungsalgorithmus nicht für untere Stufen unterstützt wird. Ein solches Problem trat auf, als wir eine signierte E-Mail (mithilfe von SHA-512 als Hashalgorithmus) an einen Benutzer sendeten, der mit Windows XP SP2 arbeitete. Weil das Empfangssystem den Hash nicht unterstützte, konnte der Benutzer die Signatur nicht validieren und die Nachricht nicht lesen. Es ist aber unwahrscheinlich, dass an diesem Punkt viele Probleme auftreten, wenn die Standardeinstellungen in Outlook nicht geändert wurden.

Nach dem Empfang der Nachricht sollte der gewünschte Empfänger sie öffnen können, vorausgesetzt, der private Schlüssel, der mit dem öffentlichen Zertifikat verbunden ist, steht zur Verfügung. Auch hier muss der Benutzer möglicherweise einen weiteren Beweis für den Besitz des privaten Schlüssels liefern, je nachdem, wie er bereitgestellt wurde. Andere Benutzer, die einen ähnlichen Bootstrappingprozess durchgeführt haben, dürfen an ähnlich signierten und verschlüsselten Kommunikationen mit dem Absender teilnehmen. Wenn ein Benutzer seinen privaten Schlüssel irgendwann ändert (möglicherweise, weil sein Computer verloren ging), muss er Zertifikate erneut anfordern und eine signierte Nachricht oder Zertifikatdatei an andere Benutzer senden, mit denen er verschlüsselte E-Mails austauschen möchte.

Schlussbemerkung

Die Einrichtung von verschlüsseltem und signiertem S/MIME zwischen zwei Benutzern in zwei unterschiedlichen Verzeichnissen oder Organisationen ist in der Regel nicht komplizierter als hier dargelegt. Das Signieren ist sehr praktisch, wenn es richtig eingesetzt wird, da es die Echtheit einer Nachricht belegt. Für vertrauliche Informationen bieten verschlüsselte Nachrichten eine zusätzliche Stufe der Geheimhaltung bei der Übertragung von Daten. Gemeinsam ermöglichen beide die Echtheitsprüfung der Quelle und die Geheimhaltung von Daten. Mit der hier beschriebenen Vorgehensweise wird es für die meisten Benutzer leicht sein, die Vorteile dieser Möglichkeiten zu nutzen.

Matt Clapham, CISSP, ist Security Engineer bei Microsoft IT. Er führt tagsüber Sicherheitsprüfungen für Branchenanwendungen durch und beschäftigt sich in seiner Freizeit mit Technologie, Spielen, Computermusik und Sicherheit. Er spricht gelegentlich vor der Puget Sound-IT-Sicherheitscommunity. Sie erreichen Ihn unter matt.clapham@microsoft.com

Blake Hutchinson ist Support Analyst in der Business Online Services Group (BOSG) bei Microsoft. Zu seinen Aufgaben zählen betrieblicher Support und Projektprüfung für firmenintern erstellte Branchentools für die Unternehmenskunden von BOSB. Zu seinen Hobbys zählen Fotografie, Skifahren und Computerspiele. Sie erreichen ihn unter blakeh@microsoft.com.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.