S/MIME vs. OpenPGP: Eine Entscheidungshilfe

S/MIME-Nutzer behaupten gerne, dass (Open)PGP unsicher sei; OpenPGP-Freunde schimpfen gerne auf die Unsicherheit von S/MIME. Solche Aussagen beruhen jedoch meist auf mangelndem Know-how. Wenn man genau hinsieht, stellt sich heraus, dass beide Protokolle aktuelle Sicherheitsanforderungen gleichermaßen erfüllen. Ohnehin behandeln sie letztlich nur die "Verpackung" von chiffrierten oder signierten Nachrichten. Beide Konzepte beruhen auf anerkannt sicheren kryptographischen Verfahren. In der Vergangenheit gefundene Schwachstellen waren in allen Fällen auf Implementierungsfehler der Hersteller zurückzuführen.

Auch die Verfügbarkeit von Clientsoftware oder Plug-ins für vorhandene Lösungen ist heutzutage kein vorrangiges Auswahlkriterium mehr, da beide Welten die gängigen Applikationen unterstützen (zudem sollte man die Front-Ends ohnehin im eigenen Umfeld evaluieren). Dennoch unterscheiden sich S/MIME und OpenPGP in einigen grundlegenden Dingen, sodass es durchaus praxisrelevante Gründe geben kann, die das eine oder andere Protokoll attraktiver machen. Um die Unterschiede der beiden Standards zu verstehen, ist es hilfreich, kurz auf deren Entstehung einzugehen.

(Open)PGP: Die Entstehung

PGP steht für "Pretty Good Privacy". 1991 hat der damalige Student am US-amerikanischen MIT Phil Zimmermann PGP "erfunden". Zimmermann wollte eine praktikable, einfach bedienbare Software schaffen, die sich an die anarchische Struktur des Internets anlehnt. Da er das Programm als Freeware freigab und den Quellcode offenlegte, fand PGP schnell großen Anklang in der Internet-Gemeinde. Die mangelhafte Benutzerfreundlichkeit der ersten Kommandozeilen-Programme besserte sich im Laufe der Jahre mit dem Erscheinen von Windows-Software und Plug-ins für Mail-Clients, sodass heute auch weniger technisch versierte Benutzer die Software verwenden können.

Einige Jahre später gründete Phil Zimmermann PGP Inc.; das Unternehmen wurde Ende 1997 von [externer Link]

Network Associates (NAI) gekauft, die heute noch im Besitz der PGP-Urheberrechte sind. Das Produkt ist zwar für die private, nichtkommerzielle Nutzung noch immer als Freeware erhältlich, kommerzielle Nutzer, Universitäten und Behörden müssen die Software jedoch – entgegen weit verbreiteter Meinung – kaufen.

Der große Erfolg von PGP sorgte dafür, dass das zugrunde liegende Protokoll nach und nach in Internet-Standards, so genannten RFCs (Request for Comments, [7, 8]) niedergeschrieben wurde. RFC 1991 erschien im August 1996 und definiert das PGP Message Format. NAI und verschiedene unabhängige Kryptographen begannen, den OpenPGP-Standard zu entwickeln [4]. OpenPGP ist abwärts-kompatibel zu alten PGP-Versionen, bietet aber eine breitere Palette an Algorithmen und Funktionen. Der OpenPGP-Standard wurde im November 1998 als RFC 2440 verabschiedet. NAI will seine Produkte in Zukunft kompatibel zum OpenPGP Standard entwickeln.

	S/MIME	OpenPGP	PGP 2.6.x	PGP 5.x
Asymmetrische Algorithmen (Verschlüsselung)	RSA	RSA, ElGamal, noch nicht spezifiziert: Elliptic Curve, Diffie-Hellman (X9.42)	RSA	RSA, ElGamal (hier als Diffie-Hellman bezeichnet)
Asymmetrische Algorithmen (Signatur)	RSA	RSA, DSA, Noch nicht spezifiziert: ElGamal, ECDSA	RSA	RSA, DSA
SymmetrischeAlgorithmen	TripleDES, DES, RC2	TripleDES, IDEA, CAST5, Blowfish, SAFER-SK128, Twofish, Noch nicht spezifiziert: DES/SK, des. AES (Rijndael)	IDEA	TripleDES, IDEA, CAST5
Hash Algorithmen	MD5, SHA-1	MD5, SHA-1, RIPE-MD/160, MD2, Noch nicht spezifiziert: Double-width SHA, TIGER/192, HAVAL	MD5	MD5, SHA-1

Verwendete Algorithmen im Vergleich

Seit der Verabschiedung des OpenPGP-Standards haben verschiedene Hersteller eigene Implementierungen auf den Markt gebracht. So bietet die Glück & Kanja Software AG zum Beispiel eine Public Key Infrastruktur (PKI) auf OpenPGP-Basis an (privaten Nutzern steht auch hier eine Freeware-Version zur Verfügung).

Das "Open" in OpenPGP steht zwar für offener Standard, nicht für Open Source. Die [externer Link]

German Unix User Group e.V. (GUUG) entwickelt jedoch gefördert vom [externer Link]

Bundesministerium für Wirtschaft und Technologie (BMWi) mit einigen Partnern den [externer Link]

GNU Privacy Guard (GnuPG, [5]), eine kommandozeilenorientierte Open-Source-Implementierung des OpenPGP-Standards. Zumindest außerhalb der Unix-Welt fehlt es aber derzeit noch an benutzerfreundlichen Front-Ends.

Die S/MIME-Story

Die Secure Multipurpose Internet Mail Extensions, kurz S/MIME, wurden 1995 durch ein Konsortium von Herstellern entwickelt [2], fanden aber erst in Version 2 nennenswerte Verbreitung. S/MIME Version 2 basiert im Wesentlichen auf RFC 2311 (Message Specification) und RFC 2312 (Certificate Handling) sowie den Public Key Cryptography Standards (PKCS) RFC 2314 (PKCS#10) und RFC 2315 (PKCS#7). Diese RFCs sind jedoch rein informativ, das heisst die [externer Link]

Internet Engineering Taskforce (IETF) hat S/MIME v2 nicht zum Standard erhoben.

Version 3 wurde im Juli 1999 vom IETF verabschiedet [3] und beruht im Wesentlichen auf RFC2630 (Cryptographic Message Syntax, CMS), RFC 2633 (Message Specification), RFC 2632 (Certificate Handling) und RFC 2631 (Diffie-Hellman Key Agreement Method). Gegenwärtig basieren die meisten Produkte jedoch noch auf Version 2, da die Integration von S/MIME v3 bei etlichen Herstellern noch nicht abgeschlossen ist.

Das S/MIME-Konzept sieht eine hierarchische Struktur vor und benötigt zwingend eine vertrauenswürdige Instanz als Certificate Authority (vgl. [1]). Da im Gegensatz zu PGP von Anfang an mehrere Hersteller S/MIME implementierten, gab es zunächst große Probleme mit der Interoperabilität der einzelnen Produkte. Diese scheinen inzwischen zum Großteil gelöst zu sein (s. a. das S/MIME Interoperability Center auf [2]).

Nachrichten-Austauschformat

S/MIME und OpenPGP sind nicht kompatibel, das heisst Anwender der beiden Welten können keine signierten oder verschlüsselten Nachrichten austauschen. Selbst wenn beide die gleichen mathematischen Algorithmen verwenden (zum Beispiel RSA, Triple-DES und MD5), können sich OpenPGP- und S/MIME-Produkte nicht "verstehen". Obwohl es verschiedene Gründe hierfür gibt, ist der wichtigste sicherlich das unterschiedliche Nachrichten-Austauschformat.

MIME ist ein weit verbreiteter Standard für die Formatierung von Internet E-Mails, basierend auf RFC 822 (ARPA Internet Text Messages). S/MIME benutzt RFC 1847 (Security Multiparts for MIME), der die vorhandene MIME-Struktur um kryptographische Elemente erweitert, sodass ein bestimmter MIME-Abschnitt, zum Beispiel der Text einer E-Mail oder ein Dateianhang, signiert oder verschlüsselt werden kann.

Dieses Verfahren ist jedoch nicht auf S/MIME begrenzt. PGP/MIME (RFC 2015), eine Erweiterung zum früheren PGP-Standard, verwendet ebenfalls RFC 1847, um E-Mails und Dateianhänge zu verschlüsseln und zu signieren. Ein Update ist als Draft-IETF-OpenPGP-MIME in Arbeit (s. [3]).

Schlüssel(bund)-Formate

Auch die Schlüssel- und Keyring-Formate der beiden Standards folgen unterschiedlichen Konzepten. S/MIME verwendet X.509-Zertifikate für die Formatierung von Public Keys, die nur eine einzige Unterschrift unter dem öffentlichen Schlüssel erlauben, um dessen Gültigkeit zu belegen. Üblicherweise erstellt eine Zertifizierungsstelle (CA) diese Unterschrift. Ein X.509-Zertifikat kann nur einen öffentlichen Schlüssel, eine User ID und eine Unterschrift enthalten.

Neben der Unterschrift enthält ein X.509-Zertifikat noch andere Teile, wie einen Distinguished Name und eine Seriennummer, die von der CA vergeben wird. Die E-Mail-Adresse ist kein obligatorischer Teil eines X.509-Zertifikats und steckt in optionalen Version-3-Erweiterungen. Es empfiehlt sich jedoch heutzutage, die E-Mail-Adresse des Inhabers im Zertifikat abzulegen, da bei der Verschlüsselung von E-Mails nach dieser Eigenschaft gesucht wird und ein Mail-Client das Zertifikat sonst eventuell nicht automatisch dem Empfänger einer Nachricht zuordnen kann.

Obwohl beide Verfahren auf den gleichen Prinzipien beruhen, spricht man bei X.509 von Zertifikaten, aber bei OpenPGP von öffentlichen Schlüsseln. Der wichtigste Unterschied zu X.509-Zertifikaten ist sicherlich, dass ein OpenPGP-Schlüssel beliebig viele Unterschriften enthalten kann. Ausserdem ist jeder Schlüssel grundsätzlich "durch sich selbst signiert", also mit dem dazugehörigen geheimen Schlüssel unterschrieben (Eigenzertifikat). Der Identifier eines OpenPGP-Schlüssels ist keine durch eine CA zugeteilte Seriennummer, sondern eine so genannte Key ID, der Teil eines Hash-Wertes über den Schlüssel.

[Screenshot: Zertifikatverwaltung bei OpenPGP (hier: CryptoEx)]

Anders als X.509-Zertifikate können PGP-Keys mehrere Zertifikate und Benutzerkennungen tragen.

Ein OpenPGP-Schlüssel kann aus mehreren Schlüsseln bestehen, einem primären und mehreren sekundären. Der primäre Schlüssel kann mehrere Benutzer-IDs tragen, die mehrere Signaturen (Zertifikate) tragen können. Diese Möglichkeiten machen OpenPGP-Schlüssel viel flexibler als X.509-Zertifikate. Dies sieht dann allgemein wie folgt aus:

Vertrauen und Hierarchien

X.509 verwendet ein streng hierarchisches System zur Zertifizierung von öffentlichen Schlüsseln. Eine Certificate Authority (CA) steht an der Spitze der Zertifizierungs-Hierarchie und signiert entweder direkt oder über Sub-CAs die Schlüssel aller Teilnehmer innerhalb der Public Key Infrastruktur (PKI). Die einzelnen Benutzer sind im Besitz ihres eigenen Schlüssels und des öffentlichen CA-Schlüssels und können dadurch die Gültigkeit unbekannter Zertifikate überprüfen.

Im Gegensatz hierzu verwendet OpenPGP im klassischen Modell das so genannte Web of Trust, einen anarchischen Ansatz, der die Vertrauensstruktur der ungeordneten Internet-Gemeinde nachbildet. Während das Web of Trust für die private Nutzung viele Vorteile gegenüber einer X.509-Hierarchie hat, ist es für Unternehmen ungeeignet. Anders als bei S/MIME erlauben OpenPGP-Implementierungen die freie Wahl des PKI-Modells. Mit einer streng hierarchischen Zertifizierungskette setzen durchaus auch Großunternehmen bereits erfolgreich OpenPGP ein (ausführliche Informationen in OpenPGP als PKI für Unternehmen, KES 2000/5, S. 82).

Public Key Infrastruktur

Auch die verschiedenen Spielarten der Public Key Infrastrukturen beziehen sich auf die Geschichte der beiden Standards. Für ein zentrales, öffentlich verfügbares System zur Verteilung von Schlüsseln kommen bei OpenPGP meist so genannte HTTP-Keyserver zum Einsatz. Die (Open)PGP-Gemeinde hat im pgp.net-Verbund [6] sowie mit den Servern der Anbieter von OpenPGP-Softwares (z. B. [externer Link]

www.keyserver.de) bereits eine weltweit – mehr oder weniger gut synchronisierte – "PKI" implementiert. Eine vergleichbare Infrastruktur gibt es in der X.509-Welt bis heute nicht.

Allerdings sind diese Server nichts anderes als Datenbanken, die über eine HTTP-Schnittstelle verfügen und Benutzern erlauben, Schlüssel abzuliefern oder nach bestimmten Suchkriterien zu erfragen. Die Antwort des Servers ist eine HTML-Seite, die sich entweder manuell über einen Web-Browser oder automatisiert mit dem Verschlüsselungprogramm auswerten lässt. HTTP-Keyserver sind einfach und schnell aufzusetzen und bedeuten nur wenig Wartungsaufwand.

X.509-Zertifikate werden in X.500-konformen LDAP-Verzeichnisdiensten gespeichert, wie dem Microsoft Active Directory, dem Novell NDS oder dem Siemens Dir.X Meta Directory. LDAP-Verzeichnisdienste sind eine bessere Lösung für die Speicherung von Zertifikaten als HTTP-Keyserver. Ein Blick auf das Microsoft Active Directory macht dies deutlich: Moderne Unternehmen versuchen, ihre Datenquellen zu konsolidieren. Das Active Directory bietet einen zentralen Platz, um verschiedene Benutzer-"Eigenschaften" abzulegen, wie Benutzergruppen, Passwörter, Telefonnummern und eben Zertifikate. Verzeichnisdienste sind zudem leichter replizierbar und daher in den verschiedenen Niederlassungen eines Unternehmens aktuell verfügbar.

Setzt man für die Ablage der Zertifikate statt eines LDAP-Verzeichnisdienstes ein HTTP-Keyserver ein, müssen jedoch mindestens zwei Datenquellen gepflegt werden, wenn ein Mitarbeiter hinzukommt oder das Unternehmen verlässt. Ausserdem benötigt man für den HTTP-Keyserver einen eigenen Replikationsmechanismus sowie Konzepte für Verfügbarkeit, Backup usw.

Obwohl eine IETF-Gruppe zurzeit bereits an einem Standard zum Ablegen von OpenPGP-Schlüsseln in LDAP-Verzeichnisdiensten arbeitet, wurde noch keine Empfehlung verabschiedet. In der Praxis gibt es jedoch bereits zwei Lösungsansätze: Zum einen haben Network Associates eine Keyserver-Software im Angebot, die über LDAP Schlüssel anbietet. Dabei handelt es sich im Wesentlichen um einen "HTTP-Keyserver" mit einigen Extra-Such-Funktionen, der über ein anderes Protokoll (LDAP) kommuniziert, allerdings nicht als allgemeiner Verzeichnisdienst anzusehen ist. Und zum anderen ermöglicht die [externer Link]

CryptoEx Security Suite, OpenPGP-Keys mit S/MIME-Schlüsseln gemeinsam in einem beliebigen LDAP-Directory zu verarbeiten.

LDAP-Verzeichnisdienste externen Partnern zugänglich zu machen, ist hingegen problematisch: Zum einen erfordert dies eine Kopie des LDAP-Servers in einer Sicherheitszone des Firewall-Systems (DMZ). Zum anderen müssen alle Kommunikationspartner den LDAP-Port auf der Firewall öffnen, damit die Benutzer die Zertifikate erhalten können – und LDAP ist nicht proxy-fähig.

OpenPGP bietet hier aufgrund der langen Erfahrung mit der Internet-Gemeinde eine gute Alternative. Es empfiehlt sich dabei, einen HTTP-Keyserver in der DMZ aufzusetzen, der als HTTP-Relay für LDAP fungiert, also den LDAP-Verzeichnisdienst als Datenquelle nutzt und daher nicht separat gepflegt werden muss. Keyserver antworten zwar standardmäßig auf Port 11371, lassen sich aber auch ohne Probleme auf Port 80 konfigurieren, der auf den meisten Firewalls nicht gesperrt sein sollte; mit HTTP sind dann auch Proxies möglich.

[Grafik: Netzstruktur beim Zugriff auf Keyserver]

Um LDAP-Verzeichnisse externen Partnern zugänglich zu machen, empfiehlt sich beim Einsatz von OpenPGP ein HTTP-Keyserver als "Relaisstation" in der DMZ.

Widerrufene Schlüssel

S/MIME und OpenPGP gehen auch unterschiedliche Wege im Umgang mit widerrufenen Schlüsseln: OpenPGP speichert widerrufene Schlüssel mit den aktiven Schlüsseln im gleichen Keyserver oder Verzeichnisdienst. Der Widerruf (Revocation) wird als eine besonders geformte Signatur an den Schlüssel gehängt. Bei der Überprüfung einer Signatur kann ein entsprechend konfigurierter Client den Schlüssel anhand der Key ID vom Server holen und lokal auf seine Gültigkeit prüfen. Eine solche Überprüfung erfordert zwar eine Online-Verbindung, ist aber jederzeit aktuell.

S/MIME verwendet hingegen Certificate Revocation Lists (CRLs), die alle gesperrten Schlüssel in einer Negativliste verwalten. Die Clients laden in regelmäßigen Abständen die Liste oder ein Listenupdate, um die aktuellen Sperrlisten verfügbar zu haben. In diesem Fall müssen die Clients zwar keine Online-Verbindung zum Server halten, haben aber zum einen nicht immer die aktuellen Informationen, zum anderen wächst die Liste der CRLs ständig, muss regelmäßig heruntergeladen und auf jedem Client gespeichert werden. Außerdem können CRLs als Negativlisten nur aussagen, welche Schlüssel ungültig sind, aber nicht, ob ein Schlüssel gültig ist. Hinzu kommt, dass mit der Menge der externen Partner die Menge der CRL zunimmt und nur schwer zu verwalten ist.

Das Online Certificate Status Protocol (OCSP) bietet eine Alternative zu CRLs bei S/MIME. OCSP arbeitet ähnlich dem bei OpenPGP skizzierten Verfahren. Zur Überprüfung eines Zertifikats schickt man den Zertifikat-Identifier an einen so genannten OCSP Responder, der eine signierte Nachricht mit dem Zertifikats-Status good, revoked oder unknown zurückliefert. Der Unterschied zu OpenPGP ist, dass die CA die Überprüfung des Zertifikats im eigenen Kontext vornimmt, während die Gültigkeitsberechnung bei OpenPGP im Client stattfindet. Mit OCSP kommt S/MIME dem OpenPGP-Konzept also einen großen Schritt näher, auch wenn die beiden Verfahren in diesem Punkt wiederum nicht kompatibel sind. Da OCSP ein sehr neues Protokoll ist, sind von den meisten Herstellern aber noch keine fertigen Implementationen verfügbar.

Betriebsumgebung

Wenn E-Mail Security nur auf Windows-basierenden Systemen gewährleistet werden soll, sind beide Standards gleichermaßen geeignet. Wenn jedoch Unix, Linux oder Palm-PDAs in das Konzept eingebunden werden, ist der Einsatz von OpenPGP zu empfehlen, da dieses auf mehr Plattformen verfügbar ist. Auswertungen der Glück & Kanja Software AG zufolge ist OpenPGP zurzeit der häufiger eingesetzte Standard mit einem Anteil von etwa 60 bis 70 Prozent aller verschlüsselten E-Mails.

Der OpenPGP-Standard erlaubt darüber hinaus die Verschlüsselung von fast beliebigen Informationen: von E-Mails über Dateien und Festplatten bis hin zu IP-Traffic. S/MIME bedeutet Secure MIME und ist daher nur für E-Mails geeignet. Allerdings sind X.509-Zertifikate für fast alle Formen der Verschlüsselung und digitalen Signatur einsetzbar.

Fazit

S/MIME und OpenPGP haben beide die gleiche Aufgabe: das Verschlüsseln und Signieren von Daten. Es gibt zwar einige wichtige Unterschiede, aber letztlich bietet keiner der Standards einen allgemeinen Vorteil gegenüber dem anderen.

Während es vor einigen Jahren noch so aussah, als gewinne S/MIME langfristig die Oberhand, scheinen sich viele Firmen aufgrund der erwiesenen Praxistauglichkeit und dem erheblich einfacheren und flexibleren Aufbau für eine OpenPGP-PKI zu entscheiden. Das Rennen ist also noch nicht gelaufen. Denn auch intern scheinen sich nicht einmal die Großen der Branche einig zu sein: Microsofts Produktentwicklung setzt offiziell auf S/MIME, während die Security Bulletins des [externer Link]

Microsoft Product Security Notification Service regelmäßig durch OpenPGP-Signaturen authentifiziert sind.

Christian Kirsch ist Product Manager für Security-Produkte bei der Glück & Kanja Software AG, Offenbach am Main, einem Unternehmen der Biodata Information Technology AG.

Management und Wissen

E-Mail-Verschlüsselung