![[Aufmachergrafik: heller, corporate design]](07-4-050-0.jpg)
Aus Erfahrung ... Mehr als 10 Jahre DFN-PKI – eine Art Resümee Aus Erfahrung ... Mehr als 10 Jahre DFN-PKI – eine Art ResümeeAllein innerhalb der letzten 18 Monate sind 150 Hochschulen und Forschungseinrichtungen Teil der PKI-Welt des Deutschen Forschungsnetzes (DFN) geworden – Public-Key-Infrastrukturen (PKI) müssen also kein "zähes Geschäft" sein. Das DFN ist das von der Wissenschaft selbst organisierte Kommunikationsnetz für Wissenschaft und Forschung in Deutschland; es verbindet akademische Einrichtungen miteinander und ist nahtlos in den europäischen und weltweiten Verbund der Forschungs- und Wissenschaftsnetze integriert. Als Teil der Infrastrukturdienste wird die DFN-PKI betrieben.
Bereits 1996 begann im DFN die Entwicklung von PKI-Strukturen – zu einer Zeit also, in der quasi jeder im Bereich IT-Security über einen PGP-Schlüssel verfügte und als der Prozess, der letztendlich zum Signaturgesetz führte, erst ganz langsam begann. Lange Jahre führte die DFN-PKI jedoch ein wenig nachgefragtes Schattendasein, bis mit der Neuausrichtung auf X.509 und der Möglichkeit, aufwändige PKI-Komponenten auszulagern, die Weichen für eine breite Nutzung gestellt wurden. Die Einsichten dieser Neuausrichtung sind Gegenstand dieses Beitrages.
Der Nutzen von Zertifikaten ist von jeher unbestritten, der Weg dorthin erweist sich jedoch oft als schwierig. Als Anwender steht eine Organisation in der Regel vor der Entscheidung, selbst eine komplette technische Lösung für ihren Teil der Zertifizierungsinfrastruktur aufzubauen und das entsprechende Personal vorzuhalten oder aber einen entsprechenden Dienst einzukaufen – Kosten in nicht zu vernachlässigender Höhe erzeugen beide Optionen. Denn es ist zwar relativ einfach, mit den entsprechenden Open-Source-Werkzeugen Zertifikate zu erzeugen (vgl. Kasten), aber einen stabilen, verlässlichen und in einem ausgefeilten Rollen-Modell funktionierenden Betrieb zu gewährleisten, ist eine ganz andere Herausforderung.
Anhand der vielen Kontakte zu Hochschulen und anderen wissenschaftlichen Einrichtungen war im DFN der Wunsch stark, Zertifikate einzusetzen. Nur musste eine Lösung gefunden werden, ohne eigenen Zertifizierungsdienst bei den teilnehmenden Organisationen auszukommen. Stattdessen sollten die Anwender soweit wie möglich entlastet werden, also eine gleichermaßen kostengünstige und einfach zu bedienende Lösung erhalten. Trotzdem sollte ein globales Sicherheitsniveau erreicht werden, das die Vorteile einer fortgeschrittenen Signatur auf Basis einer Identifizierung mit amtlichen Lichtbildausweisen à la Verwaltungs-PKI bieten kann. Und natürlich sollte man auch lokale Anforderungen noch berücksichtigen können.
----------Anfang Textkasten----------
OpenSSL (![[externer Link]](../../../../images/link.gif)
www.openssl.org) ist die Basis für Kryptographie in vielen Open-Source-Produkten. Es handelt sich dabei um eine Bibliothek, die neben den Protokollen Secure Sockets Layer (SSL v2/v3) und Transport Layer Security (TLS v1) alle gängigen Kryptographie-Algorithmen implementiert.
Ein wichtiger Bestandteil sind diverse Anwendungen, welche die Funktionen der Bibliothek auf der Kommandozeile nutzbar machen. Mithilfe dieser anfangs nur als Beispielanwendungen gedachten Programme lässt sich eine komplette Zertifizierungsstelle aufsetzen und betreiben. Die Konfiguration sowie die gesamten beim Zertifizierungsbetrieb anfallenden Daten werden dabei ausschließlich in Textdateien gespeichert. Eine feste Struktur für den Speicherort dieser Dateien ist allerdings nicht festgelegt, weshalb es für den Betrieb einer CA mit OpenSSL sinnvoll ist, eigene Skripte zu schreiben, die Ordnung in die Datenhaltung bringen.
Als Quelle für geheime Schlüssel können in OpenSSL sowohl Passwort-geschützte Dateien als auch externe Module als so genannte Engines verwendet werden. Per Engine kann ein für die Zertifizierung verwendeter Schlüssel auch auf einem externen Gerät (z. B. einem Hardware Security Modul oder USB-Crypto-Token) verwendet werden.
Eine grafische Benutzeroberfläche ist nicht Bestandteil des OpenSSL-Projekts; es existieren jedoch einige andere Open-Source-Projekte, die eine solche Oberfläche geschaffen haben (z. B. Tiny CA – http://tinyca.sm-zone.net).
Das OpenCA-Projekt ist das größte Open-Source-Projekt, das eine X.509-Zertifizierungsstelle implementiert. Die komplett in Perl geschriebene Software basiert intern ebenfalls auf OpenSSL, bietet jedoch erheblich mehr Funktionen. So erfolgt beispielsweise die gesamte Bedienung über ein Web-Frontend. Der Zertifizierungsprozess wird aufgeteilt und den verschiedenen daran Beteiligten jeweils eine eigene Schnittstelle zur Verfügung gestellt:
Diese drei Schnittstellen sind so aufgebaut, dass sie auch auf getrennten Rechnern laufen können; in diesem Fall findet ein Datenaustausch über TAR-Archive statt. Den Austausch dieser Dateien übernimmt allerdings nicht die OpenCA-Software – er muss entsprechend von den Betreibern organisiert werden. Oft erfolgt dies manuell, der Sicherheit wegen.
Bemerkenswert ist zudem, dass OpenCA ein Rollenkonzept integriert: Damit lassen sich verschiedene Vorlagen für Zertifikate erstellen, die beispielsweise in unterschiedlichen Verwendungszwecken durch Setzen der X.509v3-Erweiterungen resultieren. Weiterhin ist ein Export der ausgestellten Zertifikate zu einem LDAP-Verzeichnis implementiert, sodass Zertifikate dort zum Beispiel für E-Mail-Applikationen bereitstehen.
OpenCA ist im Internet unter www.openca.org zu finden – auch eine Neuentwicklung auf Basis dieses Projekts ist bereits weit fortgeschritten, mehr Informationen liefert www.openxpki.org.
----------Ende Textkasten----------
Die verschiedenen Aufgabenbereiche eines Zertifizierungsdienstes lassen sich klar gegeneinander abgrenzen. An praktisch jeder Einrichtung ist eine Instanz vorhanden, welche die Aufgaben einer Registrierungsstelle grundsätzlich wahrnehmen kann, zum Beispiel ein Immatrikulationsbüro oder eine Personalstelle. Anders bei einer Zertifizierungsstelle: Die Realisierung dieser Aufgaben erfordert einerseits Mitarbeiter mit speziellem technischen Know-how und zum anderen auch besondere Hardwarekomponenten wie einen gesicherten Raum, einen Safe, ein Bankschließfach und speziell gesicherte Rechner ohne Netzzugang.
Nach den Regeln des neuen DFN-Zertifizierungsdienstes können die Aufgaben von Registrierungs- und Zertifizierungsstellen daher nun getrennt voneinander wahrgenommen werden. Die Anwender können somit den technisch aufwändigen Betrieb ihrer Zertifizierungsstelle an den DFN-Verein auslagern, der in ihrem Namen Zertifikate für die Nutzer und Ressourcen der Einrichtungen ausstellt.
Um die Aufgaben der Registrierungsstelle einfach und effizient durchführen zu können, stellt der DFN-Verein den Hochschulen und Forschungseinrichtungen eine angepasste Webschnittstelle zur Verfügung, über die alle benötigten Angaben erfasst werden und die als Schnittstelle zur ausgelagerten Zertifizierungsstelle dient.
Auf diese Weise wurde die Einstiegshürde zur PKI-Teilnahme deutlich herabgesetzt. Wenn eine Einrichtung bereits einen eigenen Zertifizierungsdienst betreibt, hat sie nun eine Möglichkeit, diesen noch wirtschaftlicher zu gestalten.
Obwohl die Einfachheit der Webschnittstelle tatsächlich den schnellen Einstieg ermöglichte, kamen mit der Einbindung in reale Abläufe schon bald neue Anforderungen hinzu, welche diese Schnittstelle an ihre Grenzen führen. Möchte ein Anwender zum Beispiel USB-Token an seine Benutzer ausgeben, so ist dies auch mit der Webschnittstelle kein Problem. Kommt jedoch die Anforderung, Token im Falle eines Verlusts wiederherstellen zu können, dann bedarf es anderer Schnittstellen. Um darauf reagieren zu können, gilt es zukünftig mächtigere Werkzeuge für die Registrierungsstellen vorzuhalten, die nativ auf die entsprechenden Web-Services der zentralen Infrastruktur zugreifen können.
Nach der erfolgreichen Integration der ersten DFN-Anwender mit ausgelagerter Zertifizierungsstelle wurde deutlich, dass immer noch Berührungsängste bestanden. Dies ist nicht zuletzt auf zahlreiche Artikel und Aussagen zurückzuführen, die PKI immer als schwierig und kompliziert darstellen. Um den Anwendern konkret vorführen zu können, wie sich die Arbeitsabläufe in der Praxis gestalten, wurde deshalb eine Test-PKI mit allen Schnittstellen online gestellt: Beantragung eines Zertifikats, Freischaltung des Antrags durch die Registrierungsstelle, Ausgabe des Zertifikats (die Zertifikate sind technisch funktionsfähig, gehören aber nicht zum Namensraum der DFN-PKI und sind somit nicht Teil derselben).
Interessenten, die sich grundlegend über die DFN-PKI informiert haben, erhalten einen geschützten Zugang zu dem System. Die Erfahrung zeigt, dass anschließend die Fragen zwar nicht weniger, aber zielgerichteter werden und konkret auf die Belange des neuen Teilnehmers ausgerichtet sind.
Besonders hilfreich ist dabei, dass eine für die PKI-Einführung verantwortliche Person den gesamten Prozess vorführen kann, ohne hierzu erst Software installieren oder spezielle Rechner aufsetzen zu müssen. So können sich auch diejenigen in der Einrichtung einen schnellen Einblick verschaffen, die in die Entscheidungsprozesse eingebunden sind oder die später die Aufgaben der Registrierungsstelle übernehmen sollen.
Die DFN-PKI hat deutlich vom Engagement der Pilot-Anwender profitiert, die sich als erstes für die Auslagerung entschieden hatten und mit denen Abstimmungsabläufe gemeinsam verbessert und praktisch getestet wurden. Vielleicht noch wertvoller war ihre Rolle als "positive Multiplikatoren", die anderen Anwendern bestätigen konnten, wie einfach manche als schwierig empfundene Schritte schließlich waren. Natürlich wurde diese Mundpropaganda durch Vorträge und einige Artikel auch direkt durch die Mitarbeiter der DFN-PKI unterstützt.
Die Software der DFN-PKI basiert auf einer eigenen Weiterentwicklung des OpenCA-Projekts (vgl. Kasten), die auf die spezifischen Bedürfnisse zugeschnitten wurde. So ist aufgrund der hohen Anzahl von Zertifizierungsstellen eine Mandantenfähigkeit implementiert worden: Damit genügt es, für jede neue CA nur noch eine neue Konfiguration – statt einer kompletten Installation – zu erstellen. Der Server der DFN-PKI schaltet bei Bedarf einfach die Konfiguration auf die aktuell angeforderte Zertifizierungsstelle um.
Des Weiteren arbeitet die DFN-Version bereits mit den geänderten Vorgehensweisen von Windows Vista bezüglich der Zertifizierung zusammen. Und zudem wurde der Betrieb der OpenCA-Software in der DFN-PKI für die Zertifizierung als Online-CA mit einem Hardware Security Module (HSM) optimiert. Dadurch kann das System Zertifikatsanträge nach deren Genehmigung durch eine digitale Signatur der Registrierungsstelle innerhalb von rund 2 Minuten bearbeiten, die entsprechenden Zertifikate ausstellen und an den Antragsteller verschicken. Diese Online-CA wird in einer sicheren Umgebung in einem getrennten Netzwerk und unter Einsatz von mehreren Firewalls betrieben.
Weiterhin bietet die DFN-PKI auch eine SOAP-Schnittstelle an: Damit ist neben einer "menschlichen" Kommunikation über die HTML-Schnittstelle auch eine Kommunikation zwischen (selbst entwickelten) Anwendungen und der DFN-PKI möglich. Somit kann auch eine Applikation Zertifikate beantragen, genehmigen und abholen. Mögliche Anwendungen dieser Schnittstelle sind die Personalisierung von Smartcards oder USB-Crypto-Token, lokale Sicherheitskopien geheimer Schlüssel, eine Anbindung an Datenquellen der lokalen Infrastruktur (LDAP oder ActiveDirectory), Stapelverarbeitung von Zertifikatanträgen sowie natürlich die Integration in Software von Drittanbietern.
Im Dezember 2006 wurde – etwas weniger als ein Jahr nach Einführung der Auslagerung – das selbst-signierte Wurzelzertifikat der DFN-PKI durch ein neues Wurzelzertifikat ersetzt, das mit einer in Webbrowsern verankerten Zertifizierungsstelle der T-Systems verkettet ist. Diese Alternative zur eigenen Aufnahme in die Webbrowser wurde bewusst gewählt: Vorangegangen waren zwar Gespräche mit Beratungsunternehmen, die eine Zertifizierung nach dem "Webtrust for CA"-Standard anboten. Letztlich entscheidet aber jeder Webbrowser-Hersteller unabhängig von einer solchen Zertifizierung selbst, wer aufgenommen wird und wer nicht.
Die jetzt realisierte Lösung wird von der T-Systems erstmalig in einem Kundenprojekt bereitgestellt. Möglich ist dies unter anderem nur aufgrund der professionellen Betriebsumgebung der DFN-PKI. Im Vorfeld der Vereinbarung wurde die CA-Umgebung des DFN hinsichtlich der Einhaltung von Policies der Deutsche Telekom Root CA und hinsichtlich der erforderlichen Sicherheitsmaßnahmen nach aktuellem Stand der Technik begutachtet und positiv bewertet.
Eine weitere Voraussetzung für die Zertifikats-Verkettung ist ein regelmäßiges Audit der Betriebsumgebung der DFN-PKI durch die T-Systems. Dadurch soll sichergestellt werden, dass die vereinbarten organisatorischen und betrieblichen Abläufe immer korrekt und damit vertrauensvoll erfolgen.
Ein Teil des Sicherheitskonzepts wird durch die bereits angesprochenen Zertifizierungsrechner mit einem HSM nach FIPS 140-1 Level 3 realisiert. Vorausgegangen waren umfangreiche Tests mit Fabrikaten namhafter Hersteller, um die mögliche Einbindung in OpenCA zu ergründen. Bei diesen Tests kamen vor allem Werkzeuge und Erkenntnisse aus dem "PKI Token Evaluation Report" des DFN-CERT zum Einsatz.
----------Anfang Textkasten----------
Im Mai 2005 wurde der Aufnahme des DFN-Vereins in die European Grid Policy Management Authority ( www.EUGridPMA.org) zugestimmt. Über den DFN Zertifizierungsdienst werden deshalb zusätzlich zu den "normalen" Zertifikaten nun auch EUGridPMA-komforme Zertifikate ausgegeben. Im Rahmen von Grid-Projekten spielen Zertifikate eine wichtige Rolle, zum Beispiel beim Remote-Zugriff auf Supercomputer oder verteilt gespeicherte Datenbestände wichtiger Experimente. In der Vergangenheit hat sich eine eigene, weltweite Struktur gebildet, die ihre Rolle in der Koordination der Versorgung von Grids mit Zertifikaten sieht – der europäische Teil dieser Struktur ist die EUGrid-PMA. Durch diese abgestimmte Struktur können Grid-Projekte weltweit authentifiziert und sicher zusammenarbeiten.
----------Ende Textkasten----------
Die Neuausrichtung ist aufgegangen und hat eine technisch anspruchsvolle und wirtschaftlich attraktive Dienstleistung geschaffen, die PKI einfach macht. Den DFN-Anwendern steht nun die Möglichkeit zur Auslagerung im Rahmen ihres DFN-Anschlusses ohne Zusatzkosten offen. Und durch die Verkettung mit der in den Webbrowsern verankerten Zertifizierungsstelle der T-Systems ist auch hier ein großer Schritt gemacht worden.
Dass der DFN-Anwender für die PKI nicht extra zahlen muss, weil diese als Infrastrukturdienst letztendlich allen zugute kommt und hilft, mehr Sicherheit im Netz zu gewährleisten, hat sicherlich zu dem starken Interesse und der breiten Akzeptanz beigetragen. Aber dies ist nicht allein für den jetzigen Erfolg verantwortlich: Nach vielen Jahren des Einsatzes sehr fortschrittlicher Verschlüsselungssoftware in kleinen Expertengruppen war es schlussendlich die Konzentration auf die tatsächlichen Belange der Zielgruppe, die den Wandel in Gang setzte. Nicht jeder Administrator vor Ort möchte erst ein PKI-Guru werden, bevor sie oder er Zertifikate praktisch einsetzen kann...
Wie so oft zeigt sich auch bei der DFN-PKI, dass der Bedarf nach mehr Funktionalität – ist er erst einmal geweckt – schnell immer größer wird. Nun stehen neue Anwendungen wie beispielsweise die Unterstützung der Grid-Anwender im Vordergrund (s. o.) – zudem die Verbesserung der technischen Schnittstellen.
Weitere Informationen zur DFN-PKI gibt es im Internet auf www.pki.dfn.de oder per E-Mail an pki@dfn.de.
Dr. Klaus-Peter Kossakowski ist Geschäftsführer der DFN-CERT Services GmbH. Jan Mönnich ist Team Member der DFN-PKI.
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2007#4, Seite 50
tag:kes.info,2007:art:2007-4-050
| 