Das klassische Web of Trust: In allen drei Beispielen sind alle Schlüssel in Alices Kontext gültig.
Das klassische, ungezügelte OpenPGP Web of Trust ist sicherlich kein Konzept für Unternehmen. Es gibt allerdings Wege, dieses Vertrauensnetz so zu gestalten und zu regulieren, dass eine hochflexible Hierarchie entsteht. Bei näherer Betrachtung stellt sich heraus, dass ein Web of Trust eine Übermenge des Vertrauens-Modells von X.509 darstellt.
Ursprünglich zielt OpenPGP auf die Internet-Gemeinde, X.509 wurde jedoch für strikt hierarchische Strukturen entworfen. Während das X.509-Konzept eine zentrale Zertifizierungsstelle (Root-CA, Certification Authority) voraussetzt, die dem Benutzer vorgibt, wem er vertrauen kann, stellt bei OpenPGP jeder Teilnehmer seine eigene (Root-)CA dar. Mit anderen Worten: Bei X.509 beginnt die Vertrauenskette bei der Root-CA, bei OpenPGP beginnt sie beim Benutzer selbst.
Dem klassischen Web of Trust liegt die allgemeine Theorie zugrunde, dass jeder Mensch jeden anderen Menschen über eine sehr begrenzte Anzahl Personen "kennt", auch wenn er das meist nicht weiß: Alice kennt Bob, dessen Schwager Charlie ein Arbeitskollege vom Cousin des Chauffeurs des Bundeskanzlers sein könnte - in einem bestimmten Sinne "kennt" Alice dann Gerhard Schröder. Das OpenPGP Konzept nutzt diese Theorie zum Aufbau von Vertrauensketten.
Ein einfaches Bespiel: Alice und Bob haben beide einen OpenPGP-Schlüssel. Alice trifft sich mit Bob und unterschreibt seinen öffentlichen Schlüssel. Damit wird Bobs Schlüssel im Kontext von Alice gültig. Diese einstufige Zertifizierung ist der einfachste Fall.
Das klassische Web of Trust: In allen drei Beispielen sind alle
Schlüssel in Alices Kontext gültig.
Mit ihrer Unterschrift kann Alice allerdings auch festlegen, ob sie zusätzlich Schlüssel als gültig ansehen will, die Bob unterschrieben hat. In diesem Fall würde Alice den Schlüssel von Bob als sogenannten Trusted Introducer unterschreiben. Wenn Bob nun Charlies Schlüssel unterschreibt, wird dieser auch für Alice gültig. Dies nennt man transitives Vertrauen.
Das Web of Trust lässt allerdings noch komplexere Situationen zu: Alice könnte Bobs Schlüssel auch als so genannten Meta Introducer signieren, was bedeutet, dass Bob nicht nur direkt andere Schlüssel für Alice gültig machen, sondern das ihm ausgesprochene Vertrauen auch explizit weitergeben kann. Hierzu müsste Bob dann beispielsweise den Schlüssel von Charlie als Trusted Introducer unterschreiben. Wenn Charlie dann den Schlüssel von David (ganz normal) unterschreibt, wird Davids Schlüssel für Alice gültig.
Diese Beispiele stellen den einfachsten, linearen Fall dar. Es gilt jedoch zu bedenken, dass sich Vertrauen und Gültigkeit nicht nur von Alice, sondern von jedem Benutzer aus sternförmig in mehreren Ebenen ausbreiten können. Welcher Schlüssel für wen im Web of Trust gültig ist, kann man nur im Kontext des Benutzers errechnen.
Aus akademischer Sicht ist dieses Modell genial und liegt sehr nah an der Wirklichkeit des menschlichen Vertrauens-Empfindens. Es ist jedoch verständlich, dass Unternehmen traditionell eher auf eine hierarchische Struktur setzen, in der für alle Anwender dieselben Schlüssel gültig sind. Ein solches System lässt sich aber auch mit OpenPGP verwirklichen, denn das Web of Trust ist nichts weiter als eine Übermenge einer Hierarchie.
Nehmen wir noch einmal das zweite Beispiel mit der zweistufigen Vertrauenskette: Alice unterschreibt Bob mit einer Trusted Introducer Signatur. Bob unterschreibt Charlie mit einer normalen Signatur. Im Kontext von Alice ist Charlies Schlüssel jetzt gültig. Sieht man "Bobs Schlüssel" als "CA Schlüssel" an, so ergibt sich bereits der einfachste Fall einer hierarchischen PKI: Alice unterschreibt den CA Schlüssel mit einer Trusted Introducer Signatur. Die CA unterschreibt Charlie mit einer normalen Signatur. Im Kontext von Alice ist Charlies Schlüssel jetzt gültig. Das entspricht exakt dem X.509-Modell, nur dass Alice den CA Schlüssel dort nur in ihr Key-Management aufnehmen muss, statt den Schlüssel wie bei OpenPGP zu unterschreiben. Dieser Vorgang lässt sich allerdings zumindest in "Corporate"-Versionen von OpenPGP-Software automatisieren.
Das einfachste Beispiel einer OpenPGP PKI
Dabei verhält sich dieses Modell absolut konform zum OpenPGP Standard, es bleibt voll kompatibel zu allen OpenPGP Programmen. Es handelt sich hierbei also nicht um einen Missbrauch des Webs of Trust, sondern um eine sehr spezifische Einschränkung der Möglichkeiten der eigenen, unternehmensinternen Benutzer.
Eine so einfache Hierarchie wie im genannten Beispiel ist jedoch für die meisten Anwendungen nicht flexibel genug. Darum ist es sinnvoll, eine weitere Ebene einzuführen, zum Beispiel durch das Aufteilen der Zertifizierungsstelle in eine Root CA und eine Sub CA. Zum Beispiel: Alice unterschreibt die Root CA als Meta Introducer. Die Root CA unterschreibt die Sub CA als Trusted Introducer. Diese unterschreibt David mit einer normalen Signatur. Für Alice wird Davids Schlüssel hierdurch gültig. Wenn diese Zertifizierungskette in beide Richtungen geht, erkennen David und Alice ihre Schlüssel gegenseitig an.
Es ist auch problemlos möglich, mehrere Sub CAs einzubinden. Damit lassen sich zum Beispiel CAs in verschiedenen Standorten des Unternehmens realisieren. Man könnte die Root CA in einer physisch und elektronisch besonders gesicherten Umgebung einrichten, während das Unternehmen für jeden Standort eine eigene operative Sub CA betreibt.
Mehrstufiges CA-Modell
Eine Cross-Zertifizierung ist in der OpenPGP Welt erheblich einfacher als bei X.509 - und zudem flexibler, da ein OpenPGP Key im Gegensatz zu einem X.509-Zertifikat mehrere Signaturen enthalten kann. Um den Benutzer-Zertifikaten eines anderen Unternehmens zu vertrauen, ist es lediglich nötig, deren Sub CA mit dem eigenen Root-Key als Trusted Introducer zu unterschreiben. Der Schlüssel der Sub CA des Partnerunternehmens trägt dann sowohl die Signatur der eigenen Root CA als auch die Signatur der Root CA des Partnerunternehmens. Bei Bedarf kann diese Unterschrift eine beschränkte Gültigkeit haben, sodass etwa jedes Jahr neu zertifiziert werden muss.
Cross-Zertifizierung: Unternehmen Alpha akzeptiert die
User-Zertifikate von Unternehmen Beta.
Für die Mitarbeiter des eigenen Unternehmens werden der unterschriebene Schlüssel der fremden Sub CA und alle dadurch zertifizierten öffentlichen Schlüssel automatisch gültig. Wollen die beiden Unternehmen die Cross-Zertifizierung aufheben, genügt der Widerruf der Trusted Introducer Signatur durch die Root CA - dazu ist allerdings auf eine automatisierte Verbreitung der Signatur-Updates zu achten. Da OpenPGP mehrere Root CAs unterstützt, kann man für die Zertifizierung von externen Partnern auch eine gesonderte Root CA einführen.
Will man keine kompletten Unternehmen cross-zertifizieren, sondern lediglich einzelne externe Personen kann beispielsweise eine Partner Sub CA mit der Root CA als Trusted Introducer unterschrieben werden. Die Partner Sub CA zertifiziert dann direkt den externen Benutzer.
Ein mögliches Web of Trust externer Personen hat keinen Einfluss auf die interne PKI, da der End-Anwender immer nur mit einer normalen Signatur ohne transitives Vertrauen unterschrieben wird.
Im umgekehrten Fall, wenn also ein externer Benutzer die Root CA oder Sub CA des Unternehmens signiert, hat dies nur Einfluss auf das externe Web of Trust, nicht jedoch auf die Public Key Infrastruktur des Unternehmens. Diese Möglichkeit ist sogar wünschenswert: Wenn ein externer Mitarbeiter die Root CA des Unternehmens als Meta Introducer unterschreibt, werden alle Unternehmens-Schlüssel für ihn und eventuell weitere Personen in seiner Umgebung automatisch gültig, ohne dass das Unternehmen tätig werden muss.
Besonders wertvoll ist das bei der gesicherten Kommunikation mit Kunden: Indem der Kunde lediglich die Root CA des Unternehmens durch seine Signatur akzeptiert, stehen ihm alle Schlüssel der Mitarbeiter als gültig zur Verfügung. Diese notwendige Unterschrift und die damit verbundene Entscheidung unterstreicht jedoch seine Unabhängigkeit - das Unternehmen diktiert ihm nicht durch den bloßen Import eines CA-Schlüssels seine Sicht auf die PKI. Und auch wenn das Unternehmen seinen Kunden selbst zertifizieren möchte, kann man in OpenPGP-PKIs bestehende Kunden-Schlüssel verwenden, da diese - anders als in der X.509-Welt - mehrere Zertifikate tragen dürfen.
Wichtig für das Aufrechterhalten der hierarchischen PKI ist, dass den (internen) Benutzern durch entsprechende Mechanismen untersagt wird, Schlüssel in den persönlichen Keyring zu importieren, die nicht zu den CA-Schlüsseln der Unternehmens-PKI gehören. Denn das Importieren und Signieren fremder Schlüssel würde die Hierarchie verwässern; durch den Import fremder Schlüssel in den lokalen Kontext würden Revocations von Schlüsseln eventuell nicht automatisch erkannt.
Obwohl OpenPGP historisch für dezentrale Schlüsselgenerierung steht, ist eine zentrale Schlüsselerstellung für ein Unternehmen aus verschiedenen Gründen unbedingt zu empfehlen. Zum einen kann man sicherstellen, dass die Schlüssel in einer gesicherten Umgebung generiert werden. Zum anderen werden Benutzerfehler oder Probleme auf lokalen Maschinen reduziert. Die zentrale Generierung von OpenPGP-Schlüsseln erlaubt im Übrigen die gleiche CA/RA-Struktur, wie man sie von der Erzeugung von X.509-Zertikaten kennt.
Außerdem ist gewährleistet, dass die Schlüssel im richtigen Format mit den richtigen Signaturen erstellt und die öffentlichen Schlüssel in der PKI verbreitet werden. Ferner ist ein eventuell gewünschtes Backup der geheimen Schlüssel bei einer dezentralen Generierung nur sehr schwer möglich. Das Backup wird zum einen für das firmeninterne Key Recovery benötigt, zum anderen wenn der Benutzer seinen Schlüssel verliert oder das Passwort vergisst. Letztlich braucht die Firma ein Backup, um beim Ausscheiden oder auch nach dem plötzlichen Tod eines Mitarbeiters dessen Schlüssel für ungültig erklären zu können.
Um die obenstehende Public Key Infrastruktur zu ermöglichen, sollte das Schlüsselmaterial, das an den Benutzer ausgeliefert wird, nach der automatisierten Generierung wie folgt aussehen: Der öffentliche Schlüssel des Benutzers muss von der zuständigen Sub CA unterschrieben sein, damit der Schlüssel für andere Benutzer in der PKI als gültig erscheint. Die öffentlichen Schlüssel der Root CAs und der Sub CAs müssen enthalten sein, damit der Benutzer die Gültigkeit von Schlüsseln aus der PKI lokal überprüfen kann. Abschließend müssen alle Root CA Zertifikate vom privaten Schlüssel des Benutzers als Meta Introducer signiert sein - allerdings nicht auf dem Server, sondern nur im Kontext dieses Benutzers. Jetzt ist der User einsatzfähig. Dieser komplette Ablauf lässt sich in guten OpenPGP CAs automatisieren.
Die öffentlichen Schlüssel der Unternehmens-Mitarbeiter müssen an zentraler Stelle zur Verfügung stehen. OpenPGP bietet hier zwei verschiedene Möglichkeiten der Infrastruktur an. Zum einen existieren historisch bedingt HTTP-Keyserver, die auch ältere Clients und exotische Betriebssysteme bedienen können. Diese Keyserver verwalten die Schlüssel jedoch als flache Liste und lassen sich nicht in die restliche Infrastruktur des Unternehmens integrieren. Das bedeutet, dass der Keyserver eine weitere Datenquelle darstellt, in der Benutzer gepflegt werden müssen. Hinzu kommt bei mehreren Standorten das Problem der Replizierung mehrerer Keyserver, was im Allgemeinen für Komplikationen sorgt.
Eleganter und performanter ist die Nutzung eines X.500-Verzeichnisdienstes. Viele Unternehmen verfügen bereits über ein solches Directory oder arbeiten an seiner Realisierung. Es ist problemlos möglich, OpenPGP-Zertifikate in X.500-Verzeichnisdiensten abzulegen und per LDAP auszulesen. Hierfür eignen sich die gängigen, am Markt verfügbaren Produkte wie beispielsweise Microsoft Active Directory, Siemens Dir.X Meta Directory, Netscape Directory Server oder Novell NDS. Es empfiehlt sich, den bereits im Unternehmen existierenden Verzeichnisdienst zu verwenden, um keine weitere Infrastruktur aufbauen und pflegen zu müssen (Konzept, Wartung, Replikation, Verfügbarkeit, Backup usw.).
Bei der Erstellung des Verzeichnisdienst-Schemas sollte man bedenken, dass bei OpenPGP ein Benutzer mehrere Zertifikate erhalten kann. Dies ist besonders wichtig, da widerrufene Zertifikate neben den aktuellen Zertifikaten weiterhin im Verzeichnisdienst enthalten sein sollten. Ferner sollte man die Key-ID des Schlüssels in einem eigenen Feld ablegen und indizieren, da bei verschiedenen Client-Operationen gezielt nach dieser Eigenschaft gesucht wird.
Während das klassische Web of Trust nicht für Unternehmen geeignet ist, lässt es sich durch standardkonforme Einschränkungen zu einer Hierarchie formen, mit der Unternehmen sehr flexible Public Key Infrastrukturen aufbauen können. Für die meisten Organisationen ist ein mehrstufiges CA-Modell empfehlenswert. Bei komplexeren Cross-Zertifizierungen oder der Einbindung externer Personen(gruppen) zeigt sich OpenPGP sehr viel pragmatischer und flexibler als X.509, da OpenPGP-Keys mehrere Signaturen enthalten können. Die Generierung und Zertifizierung des Schlüsselmaterials sollte das Unternehmen zentralisiert vornehmen und öffentliche Schlüssel in einem X.500-Verzeichnisdienst ablegen.
Christian Kirsch ist Product Manager für Security-Produkte bei der Glück & Kanja Software AG, Offenbach am Main.
| Produkt | Hersteller |
|---|---|
 CryptoEx
Security Suite |
Glück & Kanja Software AG |
| GnuPG |
Open Source, Werner Koch/GUUG |
| Pretty
Good Privacy |
Network Associates |
© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 5/2000, Seite 82
