iOS 5, S/MIME und Verwaltung digitaler Zertifikate

iOS 5, das neue Betriebssystem von Apple für iPad, iPhone und iPod Touch, wird "bald" veröffentlicht - Apple sagt offiziell "diesen Herbst", und viele Prognosen deuten auf irgendwann im Oktober hin. Während die neue Version Hunderte von neuen Funktionen enthält, ist die Funktion, die für Fachleute für digitale Identität wie CSS von besonderem Interesse ist, eine, über die bisher nur wenig berichtet wurde: S/MIME.

Die aktuelle Version von iOS 4.x unterstützt die Verwendung digitaler Zertifikate für die Authentifizierung, z. B. bei drahtlosen Netzwerken, VPNs und Microsoft ActiveSync. Ab iOS 5 können iPhone-, iPad- und iPod Touch-Benutzer digital signierte E-Mails senden und empfangen. und verschlüsselte E-Mail-Nachrichten direkt von ihrem Gerät zu senden und zu empfangen.

Dies ist ein großer Schritt, der die Relevanz von iOS im Unternehmensbereich nochmals erhöht. Doch selbst unter den einfachsten Umständen sollte die Planung des S/MIME-Einsatzes nicht auf die leichte Schulter genommen werden. S/MIME in Verbindung mit mobilen Geräten erhöht die Komplexität noch weiter.

Unser Ziel ist es, einige der Planungs- und Bereitstellungsüberlegungen im Zusammenhang mit einer S/MIME-Einführung mit iOS-Geräten zu skizzieren.

Ein kurzer Überblick über S/MIME

Das Protokoll S/MIME (Secure Multipurpose Internet Mail Extensions) gibt es seit den späten 1990er Jahren - fast so lange wie SSL - und wird von fast allen gängigen E-Mail-Programmen unterstützt. Dennoch hat es sich nicht annähernd so weit verbreitet wie SSL.

Warum ist das so? Die Antwort liegt wahrscheinlich in der Art und Weise, wie S/MIME funktioniert. Zu den wichtigsten Faktoren gehören:

• Der Empfänger benötigt ein Zertifikat: Aufgrund der Funktionsweise der Public-Key-Kryptografie wird eine Nachricht mit dem öffentlichen Schlüssel des Empfängers aus dessen Zertifikat verschlüsselt. Nur der entsprechende private Schlüssel des Empfängers kann die Nachricht entschlüsseln. Das bedeutet, dass Sie, wenn Sie gerade eine PKI eingerichtet oder ein E-Mail-Zertifikat von einem Dritten erworben haben, nicht unbedingt besser in der Lage sind, S/MIME-verschlüsselte E-Mails zu versenden. Wenn sich der Empfänger außerhalb Ihres Unternehmens befindet und kein E-Mail-Zertifikat besitzt, haben Sie Pech gehabt.
• Sie müssen das Zertifikat des Empfängers haben : Es klingt simpel, aber zu dem Zeitpunkt, an dem Sie die Nachricht versenden wollen, muss Ihr E-Mail-Client das Zertifikat des Empfängers zur Hand haben, damit er dessen öffentlichen Schlüssel zur Verschlüsselung der Nachricht verwenden kann. Wenn der Empfänger zu Ihrem Unternehmen gehört, kann sein Zertifikat wahrscheinlich in einem Unternehmensverzeichnis nachgeschlagen werden. Wenn nicht, haben Sie vielleicht wieder Pech. Die meisten E-Mail-Clients bieten eine Ad-hoc-Methode für die gemeinsame Nutzung von Zertifikaten, indem sie zunächst digital signierte E-Mails mit dem Empfänger austauschen. Dies ist jedoch nicht immer praktisch oder skalierbar. Daher konzentrieren sich viele S/MIME-Implementierungen auf rein interne Verschlüsselungsszenarien.
• Alte private Schlüssel müssen beibehalten werden: Wenn das Zertifikat eines Benutzers abläuft und er sich für ein neues anmeldet, kann das alte nicht gelöscht werden, da der Benutzer sonst keine E-Mails mehr lesen kann, die mit dem alten Zertifikat verschlüsselt wurden.
• Private Schlüssel müssen archiviert werden: Immer wenn Sie Daten in verschlüsselter Form auf der Festplatte speichern wollen - und verschlüsselte E-Mails sind ein Paradebeispiel dafür - brauchen Sie einen soliden Plan für die Archivierung und Wiederherstellung der Schlüssel, sonst riskieren Sie einen Datenverlust. Wenn ein Benutzer seinen privaten Schlüssel verliert, gekündigt wird, in den Ruhestand geht usw., muss der Zugriff auf seine E-Mails weiterhin möglich sein. In vielen Fällen handelt es sich dabei um eine Anforderung zur Datenaufbewahrung, die rechtliche oder Compliance-Folgen hat.
• Trennung von Zertifikaten: Verschlüsselungszertifikate benötigen archivierte private Schlüssel. Authentifizierungs- oder Signaturzertifikate haben jedoch die gegenteilige Anforderung, wenn es um den Schutz von Schlüsseln geht: Damit digitale Signaturen einen "Non-Repudiation"-Wert haben, wollen Sie in der Lage sein zu sagen, dass der Benutzer, und nur das ist natürlich unmöglich, wenn die Schlüssel archiviert werden und von anderen wiederhergestellt werden können. Aus diesem Grund unterstützen die meisten E-Mail-Clients die Verwendung separater E-Mail-Zertifikate: eines für die E-Mail-Verschlüsselung und ein anderes für die Signierung. Aber im Gegensatz zu Verschlüsselungszertifikaten besteht bei einem verlorenen Signaturzertifikat kein Risiko eines Datenverlusts; Sie können einfach ein neues ausstellen.

S/MIME und iOS

Glücklicherweise ist all das mit der richtigen Planung machbar. CSS bietet die folgenden Vorschläge für einen allgemeinen Ansatz zur Unterstützung einer S/MIME-Bereitstellung unter iOS 5.

Anmeldung für Authentifizierungs- und Signaturzertifikate mit SCEP: iOS-Geräte unterstützen von Haus aus das Simple Certificate Enrollment Protocol (SCEP)... und eine Reihe von Zertifizierungsstellen, darunter auch Microsoft CA. Bei SCEP-registrierten Zertifikaten von iPhones und iPads werden die privaten Schlüssel auf dem Gerät selbst generiert, und sie können niemals exportiert werden. Wenn das Gerät durch einen Passcode geschützt ist, haben Sie eine relativ gute Nichtabstreitbarkeitsgeschichte. Darüber hinaus werden Authentifizierungszertifikate in der Regel für die Authentifizierung gegenüber internen Systemen wie VPN und drahtlosen Netzwerken verwendet, was bedeutet, dass eine öffentlich verwurzelte PKI unnötig ist.

Melden Sie sich NICHT für E-Mail-Verschlüsselungszertifikate über SCEP an: Die Anmeldung über SCEP verhindert die Möglichkeit, die privaten Schlüssel zu archivieren. Außerdem muss jeder Benutzer genau einen privaten Schlüssel besitzen, um E-Mails an mehreren Standorten lesen zu können. ein Jedes System, auf dem der Benutzer seine E-Mails liest, muss über dasselbe Zertifikat und denselben privaten Schlüssel verfügen, und jeder, der ihm E-Mails sendet, muss dieses Zertifikat verwenden, wenn er verschlüsselte E-Mails versendet.

E-Mail-Verschlüsselungszertifikate müssen daher an anderer Stelle erstellt und sicher in das Gerät importiert werden. Die Registrierung von Benutzern für Zertifikate auf ihren Laptops oder Workstations und die anschließende Migration ihrer Schlüssel auf das Gerät stellen jedoch eine zusätzliche Herausforderung dar. Wenn irgend möglich, sollten die privaten Schlüssel der Endbenutzer nicht als exportierbar gekennzeichnet werden. Es ist zu einfach für Benutzer, sie zu exportieren und an Orte zu verschieben, an die sie nicht gehören. Außerdem wählen die meisten Benutzer miserable Passwörter, um die exportierten Schlüssel zu schützen, und löschen die Dateien nicht, wenn sie damit fertig sind, so dass sie einem großen Risiko der Kompromittierung ausgesetzt sind. CSS empfiehlt dringend, eine zentralisierte Lösung für die Archivierung und Wiederherstellung von Schlüsseln einzusetzen.

Der bevorzugte Ansatz ist daher eine automatisierte Lösung, die die aktuellen und früheren S/MIME-Verschlüsselungszertifikate eines Benutzers mit minimalem Aufwand auf seinem iOS-Gerät registrieren und/oder bereitstellen kann.

Zertifikat Managementplanung

Die Zertifikatsverwaltung ist nach wie vor einer der am wenigsten beachteten Aspekte bei der Bereitstellung von PKI-gestützten Anwendungen. Bevor eine Unternehmensanwendung bereitgestellt wird, sollten Aspekte wie diese sorgfältig geprüft werden:

• Einschreibung von Zertifikaten: Wie werden die Zertifikate eingeschrieben und zugestellt?
• Ablauf des Zertifikats: Was passiert, wenn die Zertifikate ablaufen? Wer ist für die Aktualisierung der Zertifikate zuständig und wie sieht dieser Prozess aus?
• Widerruf von Zertifikaten: Müssen diese Zertifikate unter bestimmten Umständen widerrufen werden? Wenn ja, welche sind das, wer ist dafür verantwortlich und wie wird das gehandhabt?
• Zertifikatsverlust: Wie sieht der Ersatzplan aus, wenn ein Zertifikat verloren geht? Wenn Verschlüsselungszertifikate verwendet werden, muss das genaue Zertifikat (oder zumindest ein Zertifikat mit denselben privaten und öffentlichen Schlüsseln) wiederhergestellt und dem Nutzer zurückgegeben werden. Je nach Art der Zertifikate kann dies auch eine Diskussion über die Sperrung beinhalten.

Aufgrund seiner Komplexität erfordert S/MIME auf mobilen Geräten eine besonders sorgfältige Planung der Zertifikatsverwaltung. So ergreift iOS beispielsweise keinerlei Maßnahmen zur erneuten Anmeldung oder zur Benachrichtigung des Benutzers, wenn sein Zertifikat bald abläuft. Es unternimmt auch nichts, wenn das Zertifikat tatsächlich abläuft.

Eine Lösung zusammenstellen

Keyfactor löst seit über einem Jahrzehnt schwierige Probleme von Großunternehmen mit einer Kombination aus Standardprodukten, professionellen Dienstleistungen und eigenen Produkten und Tools. Die Komponenten für eine umfassende Lösung für die oben genannten Herausforderungen sind größtenteils bereits vorhanden. Wir stellen uns eine Lösung vor, die die folgenden Produkte umfasst:

• Eine Public-Key-Infrastruktur auf der Grundlage von Microsoft CA software zur Erstellung und Bereitstellung von Zertifikaten an die erforderlichen Akteure. SCEP wird über die Rolle Network Device Enrollment Service (NDES) auf Windows Server 2008 unterstützt.
• Microsoft Active Directory, das den Inhalt der Zertifikate und die Registrierungskriterien steuert und die registrierten E-Mail-Zertifikate der Benutzer für die Verwendung mit E-Mail-Clients wie Outlook speichert. iOS 5 kann die Zertifikate von Empfängern automatisch über den nativen Exchange-E-Mail-Connector aus Active Directory abrufen.
• Microsoft Forefront Identity Manager - Zertifikatsverwaltung: Als weniger bekannte Komponente der Identitätsmanagement-Suite von Microsoft bietet "FIM-CM" skalierbare Arbeitsabläufe und Automatisierung für die im obigen Abschnitt erwähnten Ereignisse im Lebenszyklus von Zertifikaten - insbesondere die Archivierung und Wiederherstellung privater Schlüssel.
• Das Certificate Reporting Tool (CRT) von Certified Security Solutions, das die Überwachung von Microsoft CAs auf ablaufende Zertifikate unterstützt und Zertifikatsinhaber oder Administratoren über den bevorstehenden Ablauf von Zertifikaten benachrichtigt. CRT bietet außerdem ein anpassbares, flexibles Framework für die Durchführung benutzerdefinierter Aktionen im Zusammenhang mit der Handhabung von Zertifikaten. Weitere Informationen zu CRT finden Sie hier.
• Das Mobile Certificate Management System (mCMS) von Certified Security Solutions: mCMS soll im Oktober 2011 auf den Markt kommen und ermöglicht eine reibungslose Automatisierung von SCEP-registrierten Zertifikaten, ohne potenzielle Sicherheitslücken zu öffnen. Weitere technische Informationen zu mCMS finden Sie hier.
• Apples iPhone Configuration Utility (IPCU), mit dem Administratoren grundlegende Konfigurationsprofile erstellen können, die von CSS' mCMS verwendet werden.
• Besuchen Sie die Seite Mobile Certificate Management System (mCMS) hier.