Die Verschlüsselung von Informationen hat bei den immer weiter verzahnten Geschäftsprozessen eine hohe und steigende Bedeutung. Für die Daten ist die Integrität, Authentizität und der Schutz der Vertraulichkeit wichtig. Das betrifft einerseits die Kommunikation über das Internet. Andererseits sollen mobile Arbeitsplätze oder Telearbeiter sicher mit dem Unternehmen kommunizieren können.

Erreicht werden diese Anforderungen über das Signieren von Informationen sowie Verschlüsselungsfunktionen. Dabei werden gerne asymmetrische Verfahren eingesetzt. Der Sender benötigt für diese Zwecke den öffentlichen Schlüssel (Public Key) des Empfängers, der die Informationen mit seinem privaten Schlüssel (Private Key) wieder entschlüsseln kann. Um sicherzustellen, dass es sich tatsächlich um den Schlüssel des Empfängers handelt, wird dieser digital unterschrieben – die Authentizität des Schlüssels wird zusammen mit seinem zulässigen Anwendungsbereich und Geltungsbereich von einer vertrauenswürdigen Stelle bestätigt. Solche Stellen können Unternehmen, wie beispielsweise VeriSign sein, aber auch eine Stelle im eigenen Unternehmen. Der Schlüssel des Ausgebers eines Zertifikates wird ebenfalls gegengezeichnet. Auch das kann von einer externen Stelle oder auch direkt im Unternehmen geschehen. Durch das gegenseitige Unterschreiben und Bestätigen von Schlüsseln entsteht aus der Kette der einzelnen Zertifikate ein Validierungspfad. Systeme, die es ermöglichen, digitale Zertifikate auszustellen, zu verteilen und zu prüfen nennt man Public-Key-Infrastruktur (PKI). Die Aufgaben einer PKI sind das Signieren von Zertifikats-Anfragen, das Führen einer Zertifikats-Sperrliste (Certificate Revocation List, CRL), Bereitstellen eines durchsuchbaren Verzeichnisses, das die Zertifikate enthält und das Bereitstellen eines Validierungsdienstes, der die Überprüfung von Zertifikaten in Echtzeit ermöglicht. Das Zertifizierungs-System von RedHat besteht aus fünf verschiedenen Subsystemen, die eine vollständige PKI fürs Intranet und Extranet unterstützen. Im Einzelnen sind das die nachfolgend beschriebenen fünf Subsysteme.

I. Certificate Manager (CM)
Endanwender müssen sich, bevor sie mit der PKI arbeiten können sozusagen einschreiben (Abbildung 1). Sie registrieren sich bei der Certificate Authority (CA), die wiederum die angegebenen Informationen verwendet, um den Anwender zu authentifizieren und damit seine Identität zu bestätigen. Schließlich wird ein Zertifikat ausgestellt, das die Identität einer Person mit einem öffentlichen Schlüssel assoziiert und mit dem privaten Signierungs-Schlüssel der CA unterschrieben wurde. Ein Certificate Manager arbeitet hier als Wurzel-CA oder als untergeordnete CA. Er stellt Zertifikate aus, erneuert sie, widerruft die Gültigkeit und generiert CRLs. Zertifikate und CRLs können einerseits in einem LDAP-Verzeichnis und/oder als Dateien veröffentlicht werden. Daneben können sie an einen Online Certificate Status Protocol (OSCP) Responder gesendet werden, wenngleich der CM einen eigenen solchen Dienst bereitstellt. Durch die Verwendung eines separaten OSCP-Dienstes reduziert sich die Last auf dem CM-System. Zur Lastverteilung und zum Failover bei der Zertifikatserstellung können mehrere CMs eingesetzt werden. Das kann auch mit Hilfe von Clones geschehen, die die gleichen Schlüssel und Zertifikate wie der Master-CM verwenden. In einem solchen Szenario gibt jeder einzelne CM Zertifikate aus einem anderen Nummern-Kreis aus. Es ist aber auch möglich, an separaten Standorten eigenständige CMs aufzubauen, die als Sub-CAs arbeiten. Die Zertifikate werden, wenn entsprechend konfiguriert, nach erfolgreicher Authentifizierung gegenüber einem LDAP-Verzeichnis automatisch ohne manuelles Eingreifen erstellt und dem anfordernden Endanwender direkt bereitgestellt. Im anderen Fall werden die Zertifikatsanträge von einem dafür berechtigten Mitarbeiter (Agent genannt) überprüft, der die Zertifikate entweder akzeptiert oder zurückweist. In gewissen Grenzen kann er den Antrag verändern, um beispielsweise den vom Anwender angegebenen Subject-Namen an die Standards einer Organisation anzupassen oder die Gültigkeit des zu erstellenden Zertifikats zu verändern, um dem Anwender vielleicht doch nur ein Zertifikat zum Signieren zu erteilen. Arbeiten mehrere Agenten im Unternehmen, ist es möglich, dass diese eine Anfrage an andere Personen zur Bearbeitung zuweisen. Abhängig von den Einstellungen werden die Antragsteller nach der Bestätigung oder auch bei der Ablehnung durch einen Agenten automatisch vom System darüber informiert. Es ist aber auch denkbar, dass der bestätigende Agent das erstellte Zertifikat per Copy & Paste in eine Mail einfügt und diese mit weiteren Informationen an den Anwender sendet oder ihm auf einem anderen Weg zukommen lässt, wie ein USB-Stick oder eine Diskette. Wird der Endanwender nicht automatisch oder über einen Agenten informiert, kann er das Zertifikat direkt über das Web-Frontend herunterladen. Über die gleiche Oberfläche können nicht nur Zertifikate für Endanwender beantragt werden, sie dient ebenfalls der Versorgung von Serversystemen. Das erfolgt in der Regel dadurch, dass der Server-Admin eine Zertifikatsanfrage mit Mitteln aus dem openssl-Paket erstellt und diese in ein entsprechendes Formular einfügt. Für die Bereitstellung des Zertifikats gilt das oben genannte. Auch die Interaktion von Maschinen mit dem System ist möglich, denn die Servlets können so eingestellt werden, dass sie nur XML zurück liefern, so dass der eigene Code die Verarbeitung recht einfach ausführen kann.

Abb. 1: Aufnehmen eines Eintrages in den Certificate Manager
II. Data Recovery Manager (DRM)
Verliert ein Endanwender seinen privaten Schlüssel verliert er damit gleichzeitig den Zugriff auf Dateien, die er nur mit seiner Hilfe wieder entschlüsseln kann, beispielsweise verschlüsselte E-Mails. In solchen Fällen hilft ein DRM weiter. Dazu muss der Anwender Dual-Zertifikate beantragen. Er bekommt separate Schlüsselpaare für das Signieren und das Verschlüsseln von Nachrichten. Der Server gibt zwei Zertifikate aus und dieses Teilsystem archiviert Schlüssel, die der Verschlüsselung dienen. Für die Wiederherstellung von verlorenen Schlüsseln aus dem Backup oder von Schlüsseln ausgeschiedener oder im Urlaub befindlicher User, die wichtige Informationen verschlüsselt haben, müssen aus Sicherheitsgründen mehrere Agenten (sog. Key Recovery Agents) gleichzeitig diesen Vorgang genehmigen. Wie viele das sein müssen kann konfiguriert werden.

Tabelle 1: Wichtige Abkürzungen
Abkürzung	Bezeichnung
CA	Certificate Authority
CM	Certificate Manager
CRL	Certificate Revocation List
DRM	Data Recovery Manager
OCSP	Online Certificate Status Manager Responder
PKI	Public Key Infrastructure
TKS	Token Key Service
TPS	Token Processing System

III. Online Certificate Status Manager (OCSP)
Der CM kann so eingerichtet werden, dass er die CRL über diesen Dienst veröffentlicht. Ein OCSP kann die CRLs von mehreren CMs erhalten. Clients befragen den Online Certificate Status Manager, um zu überprüfen, ob ein Zertifikat widerrufen wurde. Man bezeichnet diesen Dienst auch als OCSP Responder.

IV. Token Key Service (TKS)
Werden Smart Cards eingesetzt, erfolgt die Kommunikation zwischen den sog. Tokens (in diesem Zusammenhang Karten) und dem Token Processing System ebenfalls verschlüsselt. Das TKS verwaltet den Master- und die Transport-Schlüssel, die für die Bewahrung der Integrität der Schlüssel bei der Kommunikation zwischen dem TPS und anderen Diensten sowie dem Enterprise Security Client verwendet werden.

V. Token Processing System (TPS)
Die Verwendung von Smart Cards setzt die Nutzung des Enterprise-Security-Clients voraus. Dieses Clientprogramm gibt es für Windows-, Mac- und RedHat Linux-Systeme. Es erkennt die in ein Lesegerät eingelegten Karten und übernimmt die Kommunikation mit dem TPS. Das TPS wiederum arbeitet u.a. als Registrierungsstelle für die Authentifizierung und Verarbeitung von Aufnahme-Anträgen. So wird durch das Einlegen einer leeren Smart Card ein Zertifikatsantrag an das TPS gesendet, das die Zertifikatserstellung durch die Certificate Authority initiiert. Daneben ist dieses System für das Formatieren von Karten, die Authentifikation gegenüber einem LDAP-Verzeichnis sowie dem Führen einer Token-Datenbank verantwortlich. Die einzelnen Subsysteme arbeiten in Abhängigkeit mit dem Deployment-Szenario eng zusammen. Ein solches Szenario könnte sein, nur einen Certificate Mager zu betreiben. Ein anderes könnte sein, alle Dienst auf unterschiedlichen Systemen zu betreiben und einen CM-Clone zur Lastverteilung im Netz zu haben. Es ist nicht notwendig, alle fünf Systeme einzusetzen. Wird jedoch mit Smart Cards gearbeitet, müssen TPS und TKS vorhanden sein.

Installation und Konfiguration
Die Installation setzt ein RedHat Enterprise Linux 4 voraus, auf dem einzelne Komponenten des Zertifikatssystems oder auch alle gleichzeitig installiert werden können. Ferner wird ein funktionierender RedHat Directory Server benötigt, auf den im Laufe der Konfiguration zugegriffen und der für einen Teil der Datenhaltung benötigt wird. Während der Konfiguration werden notwendige Schemaerweiterungen im Directory automatisch vorgenommen. Bei der Testinstallation ist unangenehm aufgefallen, dass das System nur auf einem RHEL-Server mit der Primärsprache Englisch korrekt zum Laufen gebracht werden konnte. Versuche auf einem deutschsprachigen System förderten bei der späteren Konfiguration unerklärliche Phänomene zu Tage, die dazu führten, dass eine Initialkonfiguration nach der Installation auf einem solchen System unmöglich war. So wie das Betriebssystem englischsprachig sein muss, werden dem Endanwender die HTML-Seiten ausschließlich in Englisch präsentiert. Lokalisierungen in andere Landessprachen gibt es nicht, Übersetzungen müssen bei Bedarf selber getätigt werden. Die Konfiguration der einzelnen Dienste erfolgt nach der Installation zunächst über ein Web-Frontend. Der Zugriff darauf ist durch eine PIN geschützt, die bei der Installation generiert wird. Dabei werden die Schlüssel der Dienste und die Zugriffs-Zertifikate für die Administratoren generiert. Ferner wird in diesem Schritt die Verbindung zu dem LDAP-Verzeichnis eingestellt. Über ein separat erhältliches Tool namens pkisilent ist es möglich, sämtliche Dienste direkt beim Erzeugen einer Instanz zu konfigurieren, ohne die Notwendigkeit zur Nutzung der Web-Konfiguration. In einem nachfolgenden Schritt werden die Dienste über die sog. Administrative Console (Kommando pkiconsole) weiter eingerichtet, die es für jeden Dienst des PKI-Systems (mit Ausnahme des TPS) gibt. Dabei handelt es sich um ein grafisches Java-Frontend, das einen X-Server benötigt. Bevor das PKI-System in Betrieb genommen werden kann, ist das Lesen der umfangreichen Dokumentation dringend zu empfehlen. Die Abhängigkeiten bei der Konfiguration und die Bedeutungen so mancher Einstellungsmöglichkeiten sind nicht immer intuitiv ersichtlich. Ein Quick-Start-Guide, anhand dessen die wichtigsten Einstellungen schrittweise nachvollzogen werden können, wäre sehr hilfreich bei der Einarbeitung, aber leider gibt es ein solches Dokument leider nicht.

Abb. 2: Konfiguration von Profilen über die pkiconsole
Profil
Welche Informationen für Zertifikatsanfragen in die Formulare eingegeben werden müssen und wie die Zertifikate ausgegeben werden regeln Zertifikatsprofile. Darin werden ebenso Default-Werte angegeben wie auch gültige Eingabewerte. Hier ist genau so ein Punkt, wo die Intuition den Admin schnell im Stich lässt. Wenn man beispielsweise einem Antragsteller nach erfolgreicher Authentifizierung gegenüber dem LDAP-Directory automatisch sein Zertifikat bereitstellen möchte, wird ein entsprechendes Authentifikations-Modul benötigt, das zunächst eingerichtet werden muss. Im Profil muss dann der Name dieses Moduls angegeben werden – die verfügbaren Namen werden jedoch nicht zur Auswahl gegeben, der Admin muss den Namen manuell eintragen. Die einzelnen Parameter für die Einschränkungen und die Defaults sind im Handbuch ausführlich dokumentiert. Im Administrationswerkzeug stehen sie allerdings nur mit ihren Namen, so dass das Handbuch immer in Reichweite sein sollte. Manchmal ähneln sich die zu erstellenden Profile auch sehr stark, so dass ein Profil als Vorlage für ein anderes dienen soll. Kopieren ist allerdings nicht ohne Weiteres möglich, denn das Admin-Tool bietet diese Funktion nicht. Allerdings kann man Profile direkt im Dateisystem kopieren und rudimentär über einen Editor seiner Wahl verändern, so dass diese dann über die GUI weiter bearbeitet werden können. Grundsätzlich können Profile also auch über einen Texteditor gepflegt werden.

Gutes Produkt mit Verbesserungspotenzial
Die Interaktion eines Endanwenders mit dem System gestaltet sich relativ einfach, vorausgesetzt die Anwender sind der englischen Sprache mächtig. Meine Erfahrungen mit deutschen Endanwendern zeigen jedoch, dass diese häufig englische Oberflächen meiden. HTML-Seiten und Profile müssen daher u.U. zunächst mühevoll übersetzt werden. Wenn man davon absieht, kann das System über die Profile relativ einfach an eigene Bedürfnisse angepasst werden – Voraussetzung dafür ist jedoch, dass man das Handbuch gut studiert und sich ausführlich mit den Möglichkeiten des Systems vertraut gemacht hat. In der GUI fehlt an vielen Stellen die Möglichkeit, über einen Doppelklick ein Element zu editieren, wie man es von vielen Anwendungen gewöhnt ist. Hier muss der Edit-Button gedrückt werden. Dass in abhängige Felder manuell Werte eingetragen werden müssen, statt diese über eine Auswahlliste abzufragen ist ebenfalls unschön und fehleranfällig. Hier ist Verbesserungspotenzial für die nächste Version. Die Unterstützung von Smart Cards sieht sehr viel versprechend aus. Da ich keinen Zugriff auf Lesegeräte und Karten habe, konnte ich diese allerdings nicht näher beleuchten. Wenn man den Beschreibungen des Handbuchs glauben darf, gestaltet sich die Verwendung sehr einfach.