Anwenderbericht Hessen-PKI Chipkartenbasierte Sicherheitsinfrastruktur für E-Government

Ordnungsmerkmale

erschienen in: <kes> 2004^#6, Seite 28

Rubrik: Systeme und ihr Umfeld

Schlagwort: Public Key Infrastructure

Zusammenfassung: In einem Pilotversuch nutzt die Hessische Zentrale für Datenverarbeitung (HZD) den Microsoft Certificate Server für chipkartenbasierte Signatur, Verschlüsselung und Windows-Logon nach den Vorgaben der Verwaltungs-PKI. Unter Verwendung eines Crypto Service Provider der Firma Kobil ist dabei auch Key Recovery realisiert.

Autor: Von Klaus-Dieter Brinkmann, Wiesbaden, sowie Pedro Nunez und Jung-Uh Yang, Unterschleissheim

Die Hessische Zentrale für Datenverarbeitung (HZD) hat in Zusammenarbeit mit den Firmen Kobil, Microsoft und T-Systems eine Public-Key-Infrastruktur (PKI) für fortgeschrittene Signaturen unter Verwendung der Netkey-E4-Karte der Deutschen Telekom aufgebaut. Mittels Windows Certificate Server 2003 und Crypto Service Provider (CSP) von Kobil wurden dabei die Rahmenbedingungen der Verwaltungs-PKI des Bundes erfüllt und zudem Key Recovery implementiert. Auf den verwendeten Chipkarten lassen sich zusätzlich Zertifikate für qualifizierte Signaturen freischalten.

Durch die Einbindung eines Chips für kontaktlose Datenübertragung unterstützt das System darüber hinaus Zugangskontroll-, Zeiterfassung- und Bezahlsysteme; so stellt die HZD eine Multifunktionskarte für die hessische Verwaltung bereit. Die dahinter liegende PKI ist Hessens Antwort auf den Aufruf des Kooperationsausschusses ADV (KoopA ADV), der als zuständiges Gremium zur Vereinheitlichung der IT-Anwendungen von Bund, Ländern und Kommunen frühzeitig die Notwendigkeit einer Sicherheitsinfrastrukur erkannt und den Aufbau einer PKI der öffentlichen Verwaltung befürwortet hat. Die Hessen PKI ist Teil der bundesweiten Verwaltungs-PKI, die das Bundesamt für Sicherheit in der Informationstechnik (BSI) aufgebaut hat.

Die Hessen PKI sollte sowohl Teilnehmer aus dem landesweiten Active Directory (Hessen AD, vgl. Abb. 1), als auch zusätzliche Anwender unterstützen. Da es zudem für die Datenpflege im Hessen AD keine verpflichtenden Regelungen, sondern lediglich Empfehlungen gab, kann nicht rechtsverbindlich garantiert werden, dass beispielsweise dort abgelegte Daten von Klaus-Dieter Brinkmann auch wirklich der natürlichen Person Klaus-Dieter Brinkmann zuzuordnen sind. Eine solche Zuordnung setzt der Web-Enrolement-Agent des Microsoft Certificate Server aber bei der Datenübernahme aus dem AD voraus und bietet daher keine Kontroll- oder Korrekturmöglichkeiten.

Deshalb wurde ein Registrierungsagent notwendig, der Daten für AD-Mitglieder zur Korrektur bereitstellt und gleichzeitig in der Lage ist, Daten von Nicht-AD-Mitgliedern manuell zu erfassen. Ein weiteres Problem war der vom BSI festgelegte Namensraum, der auf einer X.500-Struktur beruht und sich vom AD-spezifischen LDAP-Namensraum deutlich unterschied. Die Definition des erweiterten Registrierungsverfahrens übernahm Microsoft.

Abbildung 1: Struktur des landesweiten Active Directory (Hessen AD)

Auf der Smartcard der Hessen PKI liegen drei Zertifikate zur Anmeldung am Windows-PC sowie zur sicheren E-Mail mit Signatur und Verschlüsselung. Um die geforderten Anwendungsszenarien zu adressieren, wurden (zusätzlich zu den primären Zertifikatsvorlagen) unterstützende Zertifikatsvorlagen definiert: Zum erfolgreichen Anmelden in der HZD-Domäne benötigt das System neben dem Benutzerzertifikat auch Domain-Controller-Zertifikate, die aus einer Standardvorlage übernommen werden konnten. Außerdem benötigte man zur Archivierung der S/MIME-Chiffrierschlüssel ein Schlüsselwiederherstellungszertifikat und zum Ausstellen des Anmeldezertifikats (on-Behalf) ein Registrierungsagenten-Zertifikat, mit dessen Hilfe sich Logon-Zertifikate für andere Personen auf Chipkarten erzeugen lassen. Diese drei "Zusatz-Zertifikatstypen" sind im Gegensatz zu den primären Zertifikatsvorlagen jedoch nicht auf Chipkarten aufgebracht

Registrierungs-Agent

Die genannten Anforderungen wurden mithilfe des Microsoft CryptoAPI in einem neuen Registrierungsagenten implementiert. Eine besondere Schwierigkeit beim Zertifikatsregistrierungsprozess sind dabei Schritte, die entweder nur auf dem Client oder nur auf dem Server stattfinden können (vgl. Abb. 2): Die Generierung des Zertifikatsantrags muss der Client übernehmen, weil nur dort der hierzu erforderliche eindeutige und benutzerbezogene Schlüssel existiert. Die Beauftragung und Erstellung des eigentlichen Zertifikats läuft hingegen auf dem Server, weil die CA Zertifikatsrichtlinien überprüft. Die Installation der Zertifikate ist wiederum eine ausschließlich Client-bezogene Aktion, weil diese Daten "lokal" auf dem Benutzerrechner beziehungsweise in eine Chipkarte geschrieben werden.

Abbildung 2: Oberfläche des Registrierungs-Agenten

Um die Benutzerinformation für neu auszustellende Zertifikate zu ermitteln, wird zuerst im AD gesucht, wobei Daten korrigiert oder vollständig neu eingegeben werden können (vgl. Abb. 3). Bei der aus Benutzersicht komfortablen Anforderung Signatur-, Verschlüsselungs- und Anmeldezertifikate auf einmal zu generieren, muss der Agent die unterschiedlichen Merkmale der jeweiligen Zertifikate berücksichtigen. Obwohl die Attribute des spezifischen Zertifikats in der Zertifikatsvorlage vordefiniert sind, setzt jeder Zertifikatstyp einen anderen "Generierungs-Workflow" voraus. So müssen beispielsweise die Zertifikate mit den öffentlichen Chiffrier-Schlüsseln publiziert, lokal für Anwendungen bereitgestellt und der zugehörige geheime Schlüssel dem Archivierungsprozess für das Key-Recovery übergeben werden.

Abbildung 3: Datenfluss beim Registrierungsprozess

Aufgrund der dezentralen Schlüsselgenerierung der Windows-2003-CA ist dabei besonders auf eine starke Absicherung der Übertragung der geheimen Chiffrier-Schlüssel zur Archivierung in der zentralen CA-Datenbank zu achten. Zur verschlüsselten Übertragung dient deshalb ein besonderes CA-Exchange-Zertifikat mit geringer Gültigkeitsdauer (in der Regel eine Woche); der Antragsteller für diesen Zertifikatstyp kann nur die CA selbst sein, sodass Antragsteller und Herausgeber identisch sind. Mit dem jeweils verwendeten Schlüssel kann nur der Zertifikatsdienst verschlüsselte Daten dekodieren.

Der CA-Server chiffriert vor der Speicherung das vom Client (authentifiziert) übersandte Schlüsselmaterial mit einem zufälligen symmetrischen 3DES-Schlüssel, der wiederum mit den öffentlichen Schlüsseln der Key Recovery Agents (KRA) chiffriert wird. Der zum Recovery gespeicherte so genannte Key Blob umfasst also den geheimen Schlüssel des Benutzers (3DES-verschlüsselt) und den 3DES-Schlüssel (verschlüsselt mit den KRA-Zertifikaten).

Schlüsselwiederherstellung

Zur Schlüsselwiederherstellung muss technisch gesehen sowohl die Berechtigung vorliegen, den Key Blob aus der CA-Datenbank zu exportieren, als auch der korrespondierende geheime KRA-Schlüssel verfügbar sein, um die darin befindlichen Schlüssel zu dechiffrieren. Die organisatorische Umsetzung des Recovery-Prozesses bei der Hessen PKI macht sogar die Teilnahme von sechs Personen erforderlich:

Der Benutzer (Person 1) stellt einen Recovery-Antrag beim Leiter der Zertifizierungsstelle (Person 2).
Dieser beauftragt Person 3, den chiffrierten Schüssel aus der Datenbank zu exportieren und seine Seriennummer sowie den Recovery-Agent zu ermitteln, der bei der Archivierung des wiederherzustellenden Schlüssels beteiligt war.
Der geheime Schlüssel dieses Recovery-Agent lagert auf Disketten in einem Tresor, zu dem wiederum nur Person 4 Zugriff hat. Erst nach Beauftragung durch den CA-Leiter (Person 2) gibt Person 4 die Diskette an die Personen 5 und 6.
Das Kennwort für Nutzung des Recovery-Agent ist in zwei Teile geteilt, von dem die Personen 5 und 6 jeweils nur eine Hälfte kennen. Beim eigentlichen Wiederherstellungsprozess ist also nochmals ein Vier-Augen-Prinzip gewahrt, da diese beiden Personen nacheinander jeweils den ihnen bekannten Passwort-Teil eingeben müssen.

Abbildung 4: Prozessgestaltungsmöglichkeiten zur Schlüsselwiederherstellung

Erfahrungen

Nach Beantragung und Genehmigung durch einen Vorgesetzten erfolgt in der Registrierungsstelle die Personalienprüfung, Daten-Erfassung und Schlüssel-Generierung; gleichzeitig wird der Benutzer über die Grundpflichten im Umgang mit der Chipkarte belehrt. Der Mitarbeiter gibt abschließend vor Ort eine 6-stellige PIN seiner Wahl ein und erhält einen PUK-Brief mit einer 8-stelligen Ziffernfolge (PIN Unblock Key) zur Freischaltung einer durch zu viele PIN-Fehlversuche gesperrten Chipkarte. Jeweils nachts werden automatisch alle neuen Chiffrier-Zertifikate auf HTML-Seiten im Landesintranet und in Outlook-Adressbüchern veröffentlicht, die nicht über Exchange mit dem Hessen AD verbunden sind.

Beim Ausstellen von bisher 120 Chipkarten hat sich die Software voll bewährt und arbeitet nahezu fehlerfrei. Nachbesserungen sind jedoch am organisatorischen Ablauf vorzunehmen, da 90 % der Zeit für das Ausstellen einer Chipkarte durch begleitende Maßnahmen wie Prüfung der Unterlagen, Erläuterungen, Vergabe der PIN und Speicherung der Daten von Chipkarten- und Zertifikatseriennummer verbraucht wurden – nur 10 % für das eigentliche Schreiben der Zertifikate in die Chipkarte (vgl. Abb. 5).

Abbildung 5: Der größte Zeitbedarf beim Ausstellen der Chipkarten entfällt auf begleitende Maßnahmen.

Dass die Anwender für die Auswahl einer PIN etwa 20 % der Gesamtzeit zur Kartenerstellung benötigen, war eine der Überraschungen des Pilotversuchs. Vom Ärger über die Notwendigkeit einer 6-stelligen PIN bis hin zur Schwierigkeit zweimal nacheinander die gleiche PIN einzugeben, konnte man alle nur erdenklichen Probleme und Fehler beobachten.

Weiterhin zeigten sich immer wieder Schwierigkeiten beim Ausfüllen des einfachen Anmeldeformulars und oft hatten die Mitarbeiter trotz Information über die Notwendigkeit zur Identifikation mittels Personalausweis oder Reisepass diesen schlicht vergessen. Aufgrund solcher menschlichen Mängel ist davon auszugehen, dass die Ausstellung einer Chipkarte auch nach technischen und organisatorischen Verbesserungen weiterhin mindestens 10 Minuten dauern wird.

Äußerst schwierig gestaltete sich die Beschaffung von Software zum Signieren von Dokumenten, da nur wenige Produkte heute alle Zertifikate der Netkey-E4-Karte nutzen können. Zurzeit sind daher nur der Acrobat Writer 6.0 und digiseal von der Berliner secrypt GmbH im Einsatz.

Bei der E-Mail erwies sich die technische Integration in das ausschließlich genutzte Outlook XP hingegen als einfach und problemlos. Hervorzuheben ist dabei, dass Outlook die Verwendung unterschiedlicher Zertifikate für Signatur und Verschlüsselung unterstützt. Während die Pilotteilnehmer untereinander völlig problemlos signierte Nachrichten austauschen können, zeigten sich in der Kommunikation mit externen Teilnehmern zahlreiche Überraschungen:

Mehrfach wurden signierte E-Mails von Virenscannern als "verseucht" deklariert und nicht zugestellt.
Ein Virenscanner bemerkte nach mehrmaligem Senden signierter Nachrichten darin ähnliche Bit-Muster (die Zertifikate des Absenders) und warnte den Anwender, dass dieser "offenbar" verseuchte E-Mails zu versenden plane.
Auch nach Aktivierung der Outlook-Option "Signierte Nachrichten als Klartext senden", konnten einige Empfänger die E-Mail-Inhalte nicht erkennen.
Die Outlook-Sicherheitsoption "Signaturbestätigung anfordern" fordert vom Empfänger vor dem Lesen die Eingabe seiner PIN. Ist die Nachricht zusätzlich verschlüsselt, so muss er über denselben Eingabedialog die PIN für die Signaturbestätigung und die PIN für die Entschlüsselung eingeben. Diese mehrmalige Eingabe erwies sich als verwirrend.
Anwender mit PGP-Erfahrung bemängelten, dass es nicht möglich ist, verschlüsselte Nachrichten unverschlüsselt zu speichern. Hierzu wird zurzeit ein Outlook-Add-in entwickelt.

Fazit und Ausblick

Die Erfahrungen im Pilotbetrieb waren derart positiv, dass zur Aufnahme eines zur Verwaltungs-PKI konformen Wirkbetriebs nur geringe Anpassungen zur Erhöhung von Komfort und Bediensicherheit notwendig sind. Hierbei wird angestrebt, den zentralen Verzeichnisdienst des Landes Hessen auf Basis von DirX so zu nutzen, dass Verschlüsselungszertifikate und Sperrlisten direkt veröffentlicht werden.

Überdies lässt sich die Chipkarte der Hessen PKI in die E-Government-Software Governikus und die elektronische Steuererklärung ELSTER integrieren.

Nach einer Vereinheitlichung der Datenstruktur für den kontaktlosen Legic Chip steht für die hessische Landesverwaltung letztlich eine multifunktionale Chipkarte zum flächendeckenden Einsatz zur Verfügung.

Interessierte können per E-Mail von den Autoren eine Langfassung dieses Beitrags anfordern, die unter anderem näher auf die verwendeten Zertifikatsvorlagen und Workflows bei der Schlüssel-Generierung sowie auf weitere Details zum Registrierungsprozess eingeht.

Dr. Klaus-Dieter Brinkmann (kd.brinkmann@hzd.hessen.de) ist Leiter der Stabstelle Hessen PKI bei der Hessischen Zentrale für Datenverarbeitung. Pedro Nunez ist Senior Consultant Development (Security), Jung-Uh Yang ist Principal Consultant Infrastruktur (PKI & Security) bei Microsoft Deutschland.