Kochrezept für elektronische Zertifikate

Seit Beginn dieses Jahres ist in der Schweiz das Bundesgesetz über Zertifizierungsdienste im Bereich der elektronischen Signatur in Kraft (ZertES) [1]. Durch die Ratifizierung des Gesetzes und dessen Verankerung im Obligationenrecht ist eine Signatur in Form eines elektronischen Zertifikats der persönlichen Unterschrift gleichgestellt, sofern der Hersteller des Zertifikates den in ZertES definierten Bedingungen genügt.

Die Zulassungsbedingungen für staatlich anerkannte Zertifizierungsstellen sind hoch. Die Hersteller rechtlich bindender Zertifikate werden von einer zentralen Akkreditierungsstelle bestimmt [2]. Gegenwärtig sind noch keine Anbieter zertifiziert - die ersten beglaubigten Zertifikate werden wohl nicht vor 2006 zur Verfügung stehen.

Die neuen Rechtsgrundlagen öffnen den Zertifikaten zum Beispiel den Zugang zum E-Government. In vielen Fällen ist die rechtliche Bindung hingegen nicht derart strikt. Ein Beispiel ist die Authentifizierung im Intranet- oder Extranet-Bereich. Insbesondere im internen Umfeld kontrolliert die Firma selbst die sichere Erzeugung und Verteilung der Zertifikate auf den Arbeitsplatzrechnern und bürgt somit für die Glaubwürdigkeit der Signatur. Die Unterstützung elektronischer Zertifikate durch Standard-Software erlaubt auch ein gemeinsames Anmelden an verschiedenen Systemen (Single Sign On).

Moderne kryptographische Verfahren beruhen auf aufwändigen mathematischen Verfahren, die die Verschlüsselung und Entschlüsselung von Daten ermöglichen. Die Algorithmen der gebräuchlichen Verfahren sind öffentlich bekannt. Trotzdem wird die Sicherheit garantiert, indem eine grosse Zahl - der Schlüssel - für die Berechnung des verschlüsselten Textes verwendet wird. Ein kryptographisches Verfahren gilt als sicher, wenn es nicht möglich ist, den verwendeten Schlüssel zu erraten, auch wenn der benutzte Algorithmus bekannt ist. Anders gesagt existiert keine effizientere Lösung zum Brechen eines sicheren Verfahrens, als das Ausprobieren aller möglicher Schlüssel. Die steigende Rechenleistung der letzten Jahre hat diesbezüglich auch zum Wachstum der Schlüssellängen geführt. Galten früher 128- bis 512-Bit als sicher, weisen heutige Schlüssel meist eine Länge von 1024- bis 2048-Bit auf.

Grundsätzlich wird zwischen symmetrischen und asymmetrischen Verfahren unterschieden. Bei symmetrischen Algorithmen wird derselbe Schlüssel sowohl für die Verschlüsselung als auch für die Entschlüsselung verwendet. Sinnbildlich entspricht dies einem Safe, der von jedem Besitzer eines Schlüssels geöffnet und wieder verschlossen werden kann. Der Nachteil symmetrischer Verfahren liegt in der sicheren Verbreitung des Schlüssels. Falls dieser in unbefugte Hände fällt, sind die gesamten verschlüsselten Daten zugänglich. Zusätzlich ist auch kein Nachweis möglich, welcher der Schlüsselbesitzer ein gesichertes Dokument erstellt hat. Beispiele heutiger symmetrischer Verfahren sind 3-DES und IDEA [3].

In asymmetrischen Verfahren werden zwei unterschiedliche Schlüssel eingesetzt, wobei die Daten jeweils mit einem gesichert und mit dem anderen rekonstruiert werden. 1978 publizierten Rivest, Shamir und Adleman einen entsprechenden Algorithmus, der heute unter dem Namen RSA bekannt ist [3]. Ein Teil des Schlüsselpaars wird in persönlichem Besitz behalten (Private Key) und der andere veröffentlicht (Public Key). Zur Veranschaulichung dieser Methode dient ein Briefkasten. Das Einwerfen von Briefen ist jedem möglich, aber nur der Besitzer des Schlüssels besitzt die Möglichkeit, den Kasten zu öffnen. Zusätzlich zur Verschlüsselung ist mit Public Key Kryptographie auch die Signatur der Daten möglich. Die Signierung eines Dokuments durch den Private Key identifiziert dessen Eigentümer eindeutig, und jede Person, die im Besitz des Public Keys ist, kann dies überprüfen.

Im World Wide Web wird der Einsatz der Public-Key-Kryptographie am deutlichsten durch SSL-verschlüsselte Seiten sichtbar. Der Webserver besitzt ein Zertifikat, das seine Identität nachweist. Der Browser kann dieses Zertifikat verifizieren und sich darauf verlassen, mit einem vertrauenswürdigen Partner zu kommunizieren.

In der Anonymität des Internets ist ein Vertrauensbeweis nötig. Anerkannte Zertifizierungsstellen (Certification Authorities) wie Verisign bürgen für die Glaubwürdigkeit eines SSL-Zertifikates, indem dieses durch einen privaten Schlüssel signiert wird. Browser enthalten zur Validierung der Zertifikate die öffentlichen Schlüssel dieser Zertifizierungsstellen.

Beim Einsatz von Benutzerzertifikaten (Client Certificates) liegt der Nachweis des Vertrauensbeweises auf der gegenüberliegenden Seite. Der Browser gibt sich mittels einer Signatur zu Erkennen, worauf der Webserver die Identifikation akzeptiert. Im Intranet- und Extranet-Bereich ist deshalb keine anerkannte Zertifizierungsstelle notwendig. Stellt eine Unternehmung die Zertifikate selbst her und verteilt diese auf sicherem Weg, so reicht dies als Vertrauensbeweis aus. Die eigenständige Generierung von Benutzerzertifikaten ist auf einfachem Weg unter Benutzung kostenloser Software möglich.

OpenSSL [4] ist eine Funktionsbibliothek, die unter Beachtung einer Open Source Lizenz [5] nicht nur die kostenlose Erzeugung von Zertifikaten für kommerzielle Anwendungen, sondern auch die Weiterentwicklung der Software selbst zulässt. Im folgenden Beispiel benutzen wir OpenSSL, um sowohl SSL- als auch Client-Zertifikate zu erstellen. Als Testumgebung verwenden wir Microsoft Internet Information Services und Internet Explorer. OpenSSL benötigt eine Konfigurationsdatei, die die Attribute der Zertifikate definiert. Die Werte dieser Attribute können für jedes Zertifikat manuell eingegeben werden. Der Inhalt der Konfigurationsdatei ist in Listing 1 ersichtlich.

In einem ersten Schritt erstellen wir ein Root-Zertifikat, in dem wir in der Kommandozeile die Befehle aus Listing 2 eingeben. Diese Datei benutzen wir später um die Client-Zertifikate zu signieren.

Der zweite Schritt erstellt und signiert ein SSL-Zertifikat. Im «Internet Services Manager» erstellen wir einen Zertifikat-Request wie unter [6] im Abschnitt 1.2 beschrieben. Den Zertifikat-Request senden wir aber nicht an Zertifizierungsstelle, sondern signieren ihn mit dem in Listing 3 aufgelisteten Kommando selbst.

Sowohl das Root-Zertifikat als auch das SSL-Zertifikat importieren wir in den Internet Information Server. Diese Schritte werden unter [6] in den Abschnitten 1.4 bis 1.6 detailliert beschrieben. Im letzten Schritt erzeugen wir das Client-Zertifikat mittels der im Listing 4 angegebenen Befehle.

Mit dem letzten Kommando wird das Zertifikat in das PKCS12-Format umgewandelt. Dieses lässt sich durch Doppelklick in den Internet Explorer importieren. Im PKCS12-Format ist neben dem Client-Zertifikat auch der öffentliche Teil des Root-Zertifikats gespeichert. Dieser wird ebenfalls importiert und im Browser unter den vertrauenswürdigen Zertifikaten registriert. Mit dem erstellten Client-Zertifikat ist jetzt der Zugriff auf unseren abgesicherten Internet Information Server möglich.

* Christoph Hauzenberger ist Technical Consultant bei Unic Internet Solutions.