Andreas Greulich Rolf Oppliger Peter Trachsel

Bundesamt für Informatik

Sektion Informatiksicherheit

Monbijoustrasse 74

CH-3003 Bern, Schweiz

{andreas.greulich,rolf.oppliger,peter.trachsel}@ bfi.admin.ch

Viele Sicherheitstechnologien basieren heute auf dem Einsatz asymmetrischer Kryptosysteme, wobei eine breite Nutzung dieser Systeme die Bereitstellung entsprechender Zertifizierungsinfrastrukturen für öffentliche Schlüssel erforderlich macht [Schneier96,Menezes96]. Eine solche Infrastruktur, die sich aus einer Hierarchie oder einem Geflecht von sich möglicherweise auch gegenseitig anerkennenden und zertifizierenden Zertifizierungsdienstleistungserbringer (Certification Authorities, CAs) zusammensetzt, wird auch etwa als Public Key Infrastructure (PKI) bezeichnet. In der Literatur sind verschiedene Modelle für den Aufbau und Betrieb von PKIs vorgestellt und diskutiert worden [Ford97,Feghhi99]. Die Modelle verfolgen entweder einen streng hierarchischen, einen dezentralen oder einen gemischten Ansatz. Auf jeden Fall stellt der Aufbau und Betrieb einer (oder mehrerer) PKI(s) eine Aufgabe dar, die für das Funktionieren von heutigen und insbes ondere auch zukünftigen Sicherheitslösungen essentiell ist.

In der Schweiz hat das Bundesamt für Informatik (BFI) die Frage des Aufbaus und Betriebs einer Zertifizierungsinfrastruktur für die Bundesverwaltung im Rahmen einer interdepartementalen Arbeitsgruppe (AG BV-TTP) thematisiert. Als Resultat hat die AG BV-TTP die Erarbeitung eines Zertifizierungsschemas für Zertifizierungs-dienstleistungserbringer vorgeschlagen (auf dieses Zertifizierungsschema wird in Abschnitt 5 noch eingegangen). Weil sich ein derartiges Zertifizierungsschema nicht auf die Bedürfnisse der Bundesverwaltung alleine beschränken muss, ist seine Erarbeitung zwischenzeitlich in einen gesamtschweizerischen Kontext gestellt worden. Die entsprechenden Arbeiten werden vom Bundesamt für Kommunikation (BAKOM) im Rahmen einer Arbeitsgruppe Digitale Signatur (AG DigSig) koordiniert. Neben der Umsetzung und Etablierung eines entsprechenden Zertifizierungsschemas für Zertifizierungsdienstleistungserbringer in der Schweiz wird im Rahmen dieser Arbeitsgrupp e auch eine Lösung für die rechtliche Anerkennung bzw. rechtliche Gleichstellung der digitalen Signatur mit der handschriftlichen Unterschrift gesucht. Auf diese Arbeiten und auf entsprechende Haftungsfragen wird im Rahmen dieses Beitrages nicht eingegangen.

Die Aktivitäten der AG DigSig sind langfristig ausgerichtet und bieten für den heutigen Einsatz von asymmetrischen Kryptosystemen und entsprechenden CA-Dienstleistungen (noch) keine Lösung an. In der Schweizerischen Bundesverwaltung gibt es aber einen zunhemend grossen Bedarf an CA-Dienstleistungen für bestimmte Anwendungen, wie z.B. den Einsatz von

• IPsec-Protokollen für das transparente Authentifizieren und Chiffrieren von IP-Paketen auf der Internet-Schicht,
• SSL- (Secure Sockets Layer) und TLS-Protokollen (Transport Layer Security) für sichere WWW-basierte Intranet-Lösungen und für das kryptographisch abgesicherte Traversieren von Firewall-Systemen, sowie
• S/MIME (Secure MIME) für den sicheren Austausch von elektronischen Nachrichten.

Diese Technologien sind in [Oppliger98,Oppliger00] beschrieben und werden in diesem Beitrag nicht weiter diskutiert. Die Technologien haben gemein, dass sie auf dem Einsatz von Zertifikaten basieren, die konform sind zu der ITU-T Empfehlung X.509 (in der Version 3), die zwischenzeitlich von allen namhaften Standardisierungs-gremien (wie z.B. ISO/IEC) adapiert worden ist [ITU88]. Insbesondere wird eine Profilierung von X.509v3 auch im Rahmen der Internet Engineering Task Force (IETF) Public Key Infrastructure X.509 (PKIX) Working Group (WG) angestrebt. Eine entsprechende Reihe von RFCs ist im Frühjahr 1999 verabschiedet und in die Internet-Standardisierung eingebracht worden (vgl. Standards Track RFCs 2459, 2510, 2511 und 2559, sowie die informativen RFCs 2527 und 2528).

Um den kurzfristigen Bedarf an ITU-T X.509v3-Zertifikaten (insbesondere für SSL und TLS) abdecken zu können, hat die Sektion Informatiksicherheit des BFI (BFI/SI) eine Architektur erarbeitet, die von einer möglichst weitgehenden Delegation und Dezentralisation von Authentifikations- und Autorisierungsaufgaben auf dafür zuständige Mitarbeiter(innen) ausgeht. Die resultierende Architektur ist als verteiltes Zertifikat-Managementsystem (Distributed Certificate Management System, DCMS) bezeichnet und in anderen Zusammenhängen bereits ausführlich beschrieben worden [Greulich99]. Im Rahmen einer Pilotimplementierung, die als Perl Certification Authority Network (PECAN) bezeichnet wird, ist die DCMS-Architektur zwischenzeitlich auch in Form einer Sammlung von CGI- und Perl-Skripts umgesetzt und pilotiert worden. Bis die AG DigSig ein Zertifizierungsschema für Zertifizierungsdienstleistungserbringer in der Schweiz eingeführt und etabliert hat, wird PECAN in der Schweizerischen Bundesverwaltung eingesetzt, um für einzelne Bundesstellen CA-Dienstleistungen zu erbringen. PECAN wird vom BFI betrieben und dezentral unter Mitwirkung von Anwendungsverantwortlichen (und in Zukunft wohl auch unter Mitwirkung der betroffenen Personalämter) administriert. Gleichzeitig sollen die mit PECAN gemachten Erfahrungen in die Erarbeitung von Richtlinien und Kriterien für das oben erwähnte Zertifizierungsschema einfliessen.

Dieser Beitrag befasst sich schwerpunktmässig mit dem Einsatz von PECAN in der Schweizerischen Bundesverwaltung. Der Beitrag ist folgendermassen aufgebaut: Im zweiten Abschnitt wird die Architektur des DCMS umrissen. Im dritten Abschnitt wird die Pilotimplementierung PECAN vorgestellt und diskutiert, während im vierten Abschnitt vertiefend auf die Betriebsabläufe und Vorgehensweisen für den Einsatz von PECAN in der Schweizerischen Bundesverwaltung eingegangen wird. Schliesslich werden im fünften Abschnitt Schlussfolgerungen gezogen und ein Ausblick gegeben. Insbesondere wird in diesem fünften Abschnitt auch auf das erwähnte Zertifizierungsschema für Zertifizierungsdienstleistungserbinger eingegangen.

Das DCMS stellt ein verteiltes Zertifikat-Managementsystem dar, d.h. die Aufgabe der Zertifikatverwaltung ist auf mehrere - möglicherweise auch geographisch verteilte Instanzen - verteilt. Dabei können als (Teil-) Aufgaben einer Zertifikatverwaltung etwa die folgenden Aktivitäten unterschieden werden:

• Entgegennehmen von Zertifikatsanträgen
• Überprüfen von Identitäten (Authentifizierung der Antragsteller)
• Überprüfen von Privilegien (Autorisierung der Antragsteller)
• Ausstellen von Zertifikaten
• Verteilen von ausgestellten Zertifikaten
• Einspeisen von Zertifikaten in entsprechende Verzeichnisdienste
• Ungültigerklären (oder Zurücknehmen) von Zertifikaten
• Einspeisen von Ungültigkeitserklärungen in Verzeichnisdienste bzw. das Bereitstellen entsprechender Online-Statusabfragemöglichkeiten

Man beachte, dass diese Aktivitäten zum Teil mit erheblichen betrieblichen Aufwänden verbunden sein können (insbesondere erfordert die Authentifizierung der Antragsteller eine physikalische Präsenz). Allzuoft ist man dabei von der Annahme ausgegangen, dass eine zentrale Erbringung all dieser Dienstleistungen in jedem Fall am effizientesten und kostengünstigsten sei. Diese Annahme muss hinterfragt werden, zumal man auch argumentieren kann, dass z.B. das Überprüfen von Identitäten und Privilegien dezentral effizienter erfolgen kann als zentral (weil z.B. dezentral die entsprechenden Organisationsstrukturen, wie z.B. Personalämter, bereits vorhanden sind). Anstelle des Aufbaus einer zentral betriebenen CA kann man sich denn auch fragen, ob der Aufbau einer CA mit dezentralen Steuerungs- und Kontroll-mechanismen nicht effektiver ist. Diese Frage ist der Konzipierung der DCMS-Architektur zugrunde gelegen. Insbesondere hat man versucht, eine Architektu r zu entwerfen, deren hauptsächliche Sicherheitskomponenten zwar zentral betrieben werden, die aber gleichzeitig auch dezentral gesteuert und kontrolliert werden können.

In der Architektur des DCMS werden die folgenden drei Hauptkomponenten unterschieden:

• Ein DCMS Kern, der die eigentliche CA darstellt. Dieser Kern kann Off-line betrieben werden und wird von einem (oder mehreren) Administrator(en) bedient. Weil im Kern unter anderem auch der private Signierschlüssel für die Erzeugung der Zertifikate hinterlegt ist, muss diese Komponente auch physikalisch gut gesichert sein (in der Tat lassen sich viele Kosten beim Betrieb einer CA auf die erforderlichen physikalischen Sicherheitsmassnahmen zurückführen).
• Ein (oder meherere) DCMS Frontend(s), die Dienstzugangspunkte für CA-Dienstleistungen zur Verfügung stellen und entsprechend On-line betrieben werden müssen. Über diese Dienstzugangspunkte können die Benutzer und Verwalter des DCMS (letztere werden im folgenden auch etwa als Agenten bezeichnet) auf entsprechende CA-Dienstleistungen und –funktionalitäten zugreifen. Bevor-zugterweise sollten diese Zugriffe mit Hilfe von handelsüblichen WWW-Browsern mit SSL-Unterstützung (z.B. Netscape Navigator oder Microsoft Internet Explorer) erfolgen können.
• Eine vom DCMS Kern verwaltete Datenbank, in der alle relevanten Daten gespeichert sind. Insbesondere werden in dieser Datenbank Zertifikate, Gruppen und Gruppenzugehörigkeiten von Zertifikaten zu bestimmten Gruppen verwaltet. Der Inhalt der Datenbank wird auf die DCMS Frontends verteilt und neu eingegebene Daten werden periodisch abgeglichen und auf die DCMS Frontends repliziert.

Technisch gesehen stellt der DCMS Kern die eigentliche CA dar, während die DCMS Frontends den aus anderen Architekturen bekannten lokalen Registrierstellen (Local Registration Authorities, LRAs) oder Registrierstellen (Registration Authorities, RAs) entsprechen [Ford97].

Die Architektur des DCMS zeichnet sich durch zwei charakteristische Eigenschaften aus:

• Auf der einen Seite kann der Steuerungs- und Kontrollmechanismus über die DCMS Frontends verwendet werden, um einen hohen Grad an Dezentralisierung und entsprechende Delegationsmöglichkeiten zu erreichen. Dadurch wird insbesondere auch die Skalierbarkeit der Gesamtlösung erhöht.
• Auf der anderen Seite können die ausgestellten Zertifikate auch für Gruppen-basierte Zugriffskontrollen verwendet werden. Gruppen-basierte Zugriffskontroll-möglichkeiten haben sich in verschiedenen Betriebssystemen durchgesetzt (z.B. UNIX).

Von diesen zwei charakteristischen Eigenschaften bietet insbesondere die zweite neue Möglichkeiten zur Kopplung von Authentifikations- und Autorisierungsaufgaben und damit auch zur vereinfachten Verwaltung von Benutzerberechtigungen (z.B. für Intranet-Anwendungen). Eine solche Kopplung scheint für den praktischen Einsatz nützlich und wichtig zu sein [Feigenbaum98]. Dabei gäbe es neben einer Datenbank-basierten Verwaltung von Benutzerberechtigungen auch verschiedene alternative Möglichkeiten:

Alle genannten Möglichkeiten haben Vor- und Nachteile [Oppliger00]. Zusammen-fassend kann man sagen, dass sich der Einsatz einer Datenbank-basierten Verwaltung von Benutzerberechtigungen immer dann anbietet, wenn sich diese Berechtigungen dynamisch verhalten und wenig konstant sind. Ein spezifisches Problem beim praktischen Einsatz von Attribut- und SDSI/SPKI-Zertifikaten stellt auch die Tatsache dar, dass die Standardisierung wenig fortgeschritten ist, und dass entsprechende Implementierungen noch kaum interoperabel sind. In der Praxis werden Attribut- und SDSI/SPKI-Zertifikate denn auch noch kaum eingesetzt und die meisten Lösungen basieren heute entweder auf X.509v3-Zertifikaten oder auf entsprechenden Datenbanksystemen.

Im Rahmen der Architektur des DCMS kann ein Zertifikat logisch einer (oder auch mehreren) Gruppe(n) zugeordnet sein, wobei für diese Zuordnung ein (oder mehrere) Agent(en) zuständig ist (sind). Die Gruppenzugehörigkeit eines Zertifikates kann dann im Rahmen einer Zugriffskontrolle ausgenutzt werden, um z.B. Zugriffs-berechtigungen für den jeweiligen Zertifikatsbesitzer zu regeln. Nehmen wir z.B. an, dass einem Zertifikat X Zugehörigkeit zu einer Gruppe Y gewährt worden ist (von einem entsprechenden Agenten), und dass eine Applikation Z nur für Mitglieder der Gruppe Y zugänglich sein soll. In diesem Fall kann eine Zugriffskontrolle für Z sehr einfach prüfen, ob einer Zugriffsanforderung entsprochen werden soll oder nicht. Die Applikation muss nämlich nur prüfen, ob dem Zertifikat X eine Gruppenzugehörigkeit zu Y gewährt worden ist (im positiven Fall wird der Zugriff gewährt und im negativen Fall wird der Zugriff verwe igert). Mit diesem Ansatz lässt sich eine Gruppen-basierte Zugriffskontrolle realisieren, ohne dass die Benutzer individuell erfasst werden müssen. Dadurch erhöht sich die Skalierbarkeit der entsprechenden Zugriffskontrollmechanismen in erheblichem Masse. Für den Betrieb von zugriffsgeschützten Web-Seiten in einem Intranet können dadurch wesentliche Einsparungen bei der Benutzerverwaltung gemacht werden (es müssen nicht mehr Benutzernamen- und Passwortpaare verwaltet werden, sondern nur noch Gruppenzugehörigkeiten, und diese Gruppenzugehörigkeiten lassen sich meist direkt aus vorhandenen Organisationsstrukturen ableiten).

Im operativen Betrieb eines DCMS werden Administratoren und Agenten unterschieden:

• Als DCMS Administrator wird eine Person bezeichnet, die physikalischen Zugang zum DCMS Kern und damit auch Zugriff auf die entsprechende Datenbank hat. Damit hat ein DCMS Administrator potentiell auch Zugang zum privaten Schlüssel, mit dem Zertifikate digital signiert und ausgestellt werden. In Hochsicherheitsumgebungen wird man sicherlich dazu neigen, den Zugriff auf den privaten Signaturschlüssel auf mehrere DCMS Administratoren zu verteilen, d.h. das Erstellen von Signaturen bzw. das Aktivieren eines entsprechenden Signiermoduls für Zertifikate erfordert dann die simultane Präsenz mehrerer Administratoren. Auf der technischen Seite können für diesen Zweck sogenannte Secret Sharing Schemes eingesetzt werden, die das Aufteilen eines kryptographischen Schlüsselwertes auf mehrere Teilschlüssel unterstützen, so dass nur das Zusammenfügen mehrerer dieser Teilschlüssel den Schlüssel rekonstruieren kann [Shamir79,Blakley79]. Man bea chte, dass Secret Sharing Schemes in der Theorie zwar hinreichend gut bekannt sind, dass aus praktischer Sicht aber insbesondere das Zusammenfügen der erforderlichen Teilschlüssel zur Rekonstruktion des kryptographischen Schlüssels nicht unproblematisch und mit neuen Sicherheitsrisiken verbunden sein kann [He96].
• Im Gegensatz zu einem DCMS Administrator handelt es sich bei einem DCMS Agenten um eine Person, die lediglich über einen für bestimmte Aufgaben autorisierten Zugang zu einem (oder mehreren) DCMS Frontend(s) verfügt. Ein DCMS Agent wird notwendigerweise auf dem Frontend, über das er seine administrativen Tätigkeiten ausüben will, stark authentifiziert (z.B. mit Hilfe einer Client-seitigen starken Authentifikaten auf der Basis eines X.509v3-Zertifikates im Rahmen einer SSL/TLS-Verbindung). Danach hat der Agent Zugriff auf die ihn betreffenden Teile der Datenbank, und diese Teile werden periodisch mit der zentralen DCMS Datenbank synchronisiert. Jeder DCMS Agent ist zuständig für eine oder mehrere Gruppen, wobei eine Gruppe durchaus auch von mehreren Agenten gleichzeitig administriert und verwaltet werden kann.

Mit diesen Rollen kann der operative Betrieb des DCMS auf mehrere Personen verteilt werden. Typischerweise ist die Zahl der DCMS Administratoren im Vergleich zur Zahl der Agenten klein.

Für die Verwaltung des PECAN Kerns und der entsprechenden Datenbank sind zudem die folgenden fünf Perl-Skripts entwickelt worden:

Wiederum muss für eine ausführlichere Beschreibung dieser CGI- und Perl-Skripts bzw. ihrer Optionen auf [Greulich99] verwiesen werden. Die Skripts werden ausschliesslich vom Verwalter des Kerns bedient.

In der Schweizerischen Bundesverwaltung sind zur Zeit zwei PECAN Frontends installiert:

Grundsätzlich ist die Installation eines weiteren Frontends immer dann erforderlich, wenn die zusätzlich anzusprechenden Benutzer die bisher installierten Frontends nicht erreichen können. Der Einsatz mehrerer Frontends ist entsprechend eher aus Gründen der Konnektivität und Erreichbarkeit motiviert, denn aus Gründen des Lastenausgleichs. Aber natürlich können zum Zwecke des Lastenausgleichs auf einzelnen Netzsegmenten auch mehrere Frontends intalliert und betrieben werden. Die Sicherheit des Systems wird dadurch nicht tangiert (ähnlich wie das Replizieren von RAs die Sicherheit einer CA-Lösung nicht tangiert).

Die Architektur des DCMS bzw. PEACN und das Zusammenspiel des Kerns (Core) mit den verschiedenen Frontends ist in Abb. 1 schematisch dargestellt. Die festen Linien zwischen dem Kern und den Frontends, bzw. zwischen den Agenten und den Frontends implizieren kryptographisch abgesicherte Verbindungen (entweder mit SSH oder mit SSL/TLS). Demgegenüber implizieren die gestrichelten Linien zwischen den Benutzern und den DCMS Frontends nicht oder nur teilweise kryptographisch abgesicherte Verbindungen (z.B. mit Hilfe von SSL/TLS mit nur Server- bzw. Frontend-seitiger starker Authentifikation).

Abb. 1 ¾ Die Architektur des DCMS bzw. PECAN

Für Administratoren, Agenten und Benutzer sind in PECAN unteschiedlcihe Betriebsabläufe und Vorgehensweisen vorgesehen.

Als Dienstzugangspunkt dient dem Agenten ein beliebiges Frontend bzw. ein entsprechendes CGI-Skript CA.cgi (die entsprechenden Installationen für die Bundesverwaltung sind in Abschnitt 3 genannt). Wie bei einem normalen Benutzer kann dieser Zugriff mit einem handelsüblichen WWW Browser erfolgen, wobei dieser Browser zwingenderweise SSL mit Client-seitiger Authentifikation unterstützen muss (diese Voraussetzung ist für alle henadelsüblichen Browser erfüllt). In der Regel wird sich ein Agent mit Hilfe eines vorgängig ausgestellten und auf dem Browser installierten Zertifikates gegenüber dem Frontend authentifizieren. Damit ist ein kryptographisch abgesicherter Zugriff des Agenten auf die Datenbank des betreffenden Frontends möglich (gegenseitig stark authentifiziert und transparent chiffriert).

• In einem ersten Schritt baut der Benutzer mit seinem Browser eine Verbindung zu einem (der in Abschnitt 3 genannten) DCMS Frontends auf.
• Unter anderem wird er über dieses DCMS Frontend ein Client-seitiges Zertifikat beantragen können. Er wird das entsprechende HTML Formular ausfüllen und gewünschte Gruppenzugehörigkeiten auswählen. Die Gruppenzugehörigkeiten sind erforderlich, um Gruppen-basierte Zugriffskontrollen sinnvoll steuern zu können. Natürlich kann PECAN auch ohne diese Möglichkeit betrieben werden. In diesem Fall wählt ein Benutzer keine Gruppenzugehörigkeiten aus, bzw. die ausgewählten Gruppenzugehörigkeiten werden von PECAN ignoriert.
• Nachdem seine Identität von mindestens einem Validator bestätigt worden ist, wird das Zertifikat ausgestellt (die Ausstellung des Zertifikates erfolgt durch das Perl-Skript sign.pl, das von einem Administrator gestartet werden). Die beantragten Gruppenzugehörigkeiten können dann - unabhängig von der eigentlichen Zertifikatausstellung - von den jeweiligen Agenten bestätigt oder verweigert werden. Die entsprechenden Gruppenzugehörigkeiten werden als Datenbank-einträge abgelegt.
• Nachdem der Benutzer über die Ausstellung seines Zertifikates informiert worden ist, kann er dieses auf seinen WWW-Browser herunterladen und installieren. Für das Herunterladen wird eine temporäre persönliche Identifikationsnummer (PIN) verwendet.