Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03128.jsonl.gz/1497

Der Einsatz eines verteilten Zertifikat-Managementsystems in der Schweizerischen Bundesverwaltung
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
Zusammenfassung
Um den zunehmend grossen Bedarf an CA-Dienstleistungen in der Schweizerischen Bundesverwaltung abdecken zu können, hat die Sektion Informatiksicherheit des Bundesamtes für Informatik (BFI/SI) eine Architektur erarbeitet, die von einer möglichst weitgehenden Delegation und Dezentralisation von Authentifikations- und Autorisierungs-aufgaben auf dafür zuständige Mitarbeiter(innen) ausgeht. Die resultierende Architektur eines verteilten Zertifikat-Managementsystems (Distributed Certificate Management System, DCMS) ist zwischenzeitlich auch umgesetzt und in Form einer Sammlung von CGI- und Perl-Skripts als Perl Certification Authority Network (PECAN) pilotiert worden. In diesem Beitrag werden die Architektur des DCMS, die Pilotimplementierung PECAN, sowie die Betriebsabläufe und Vorgehensweisen für den Einsatz von PECAN in der Schweizerischen Bundesverwaltung vorgestellt und diskutiert. Im Hinblick auf einen Fremdbezug von CA-Dienstleistungen wird zu dem ein mögliches Zertifizierungsschema für Zertifizierungsdienst-leistungserbringer vorgeschlagen und zur Diskussion gestellt.
1. Einleitung
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
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.
2. Die Architektur des DCMS
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:
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:
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].
Während der DCMS Kern in einer physikalisch geschützten Umgebung installiert sein und betrieben werden muss, können die DCMS Frontends durchaus auch auf handelsüblichen SSL-fähigen HTTP-Servern installiert sein und betrieben werden. Die Kommunikation zwischen dem DCMS Kern und den DCMS Frontends muss aber in jedem Fall vor aktiven Angriffen geschützt sein. Weil der Kern und die Frontends in der Regel auch geographisch verteilt sind, müssen entweder die Leitungen selbst physikalisch geschützt sein oder der Einsatz von kryptographischen Verfahren muss einen solchen Schutz realisieren. Im praktischen Einsatz wird sicherlich die zweite Möglichkeit die einfacher zu realisierendere sein. Im Rahmen der im folgenden Abschnitt vorgestellten Pilotimplementierung der DCMS-Architektur wird z.B. das Programmscp (secure copy) des Softwarepa ketes Secure Shell (SSH) eingesetzt, um zwischen dem DCMS Kern und den entsprechenden DCMS Frontends gesicherte, d.h. authentifizierte und chiffrierte, Tunnels aufzubauen und zu betreiben [Oppliger98]. Diese (authentifizierten und chiffrierten) Tunnels können das Eindringen eines aktiven Angreifers wirksam verhindern. Natürlich kann ein ähnlicher kryptographischer Schutz auch mit Hilfe von anderen Softwareprodukten erreicht werden (man denke hier insbesondere an IPsec- und VPN-Produkte). Schliesslich verwaltet der DCMS Kern eine Datenbank, die periodisch auf die Frontends repliziert und mit diesen auch abgeglichen und synchronisiert wird. In ihr werden Zertifikate (Certificate-DB), Gruppen (Group-DB) und Zugehörigkeiten von Zertifikaten zu bestimmten Gruppen (Memberships-DB) verwaltet.
Die Architektur des DCMS zeichnet sich durch zwei charakteristische Eigenschaften aus:
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:
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.
3. Pilotimplementierung
Die im zweiten Abschnitt umrissene DCMS-Architektur ist von BFI/SI zwischenzeitlich auch umgesetzt und pilotiert worden. Als Entwicklungsumgebung wurde Perl 5.0 mit dem Datenbankmodul Sprite gewählt. Die Benutzerschnittstelle des Frontends ist in PECAN in Form eines CGI-Skripts namensCA.cgi realisiert.
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
4. Betriebsabläufe und Vorgehensweisen
Für Administratoren, Agenten und Benutzer sind in PECAN unteschiedlcihe Betriebsabläufe und Vorgehensweisen vorgesehen.
Administratoren
In der Architektur des DCMS und im Rahmen von PECAN sind Administratoren für die Verwaltung des Kerns und der entsprechenden Datenbank zuständig. Für die Erfüllung dieser Aufgaben sind in PECAN die in Abschnitt 3 genannten Perl-Skripts vorgesehen (sync.pl, sign.pl, acls.pl, index.pl und importOld-Certs.pl). Die Skripts sync.pl und sign.pl müssen periodisch gestartet und durchlaufen werden, während das Skript acls.pl eingesetzt werden kann, um Zugriffskontrolllisten für SSL-basierte HTTP Server mit einer an die Stronghold-Serversoftware angelehnten Syntax für Zugriffskontrolllisten zu extrahieren. Schliesslich müssen die Skripts index.pl und importOldCerts.pl nur dann eingesetzt, wenn aus Kompatibilitätsgründen alte Zertifikate eingelesen und in ein neues Format konvertiert werden müssen.
Die Bedienung der Perl-Skripts erfordert in der Regel einen Shell-Zugriff auf das dem Kern zugrunde liegenden Betriebssystem. Damit ist in der Regel auch ein physikalischer Zugang zum Kern erforderlich.
Agenten
In der Architektur des DCMS und im Rahmen von PECAN sind Agenten für die Verwaltung von Gruppen zuständig, d.h. Agenten können für die Gruppen, für die sie als Agenten nominiert sind, Gruppenzugehörigkeiten für Zertifikate bestimmen. In diesem Sinne stellt auch die Gruppe der authentifizierten Benutzer eine Gruppe dar (mit der spezifischen Bezeichnung "."). Einem Zertifikat, dem Gruppenzugehörigkeit zu "." gewährt worden ist, wird entsprechend attestiert, dass der Zertifikatsbesitzer von einem für "." zuständigen Agenten authentifiziert worden ist (für "." zuständige Agenten werden auch etwa als Validatoren bezeichnet). Dabei sind Gruppenzugehörigkeiten zu "." auch mehrfach bestätigbar und solche Mehrfachbestätigungen werden in der Datenbank auch als solche vermerkt. Für bestimmte Applikationen kann es hilfreich und nützlich sein , dass festgestellt werden kann, wer einen bestimmten Benutzer authentifiziert hat.
Als Dienstzugangspunkt dient dem Agenten ein beliebiges Frontend bzw. ein entsprechendes CGI-SkriptCA.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).
Benutzer
Benutzer können mit Hilfe eines handelsüblichen WWW Browsers mit SSL-Unterstützung auf PECAN zugreifen. Eine Policy muss festlegen, welche Informationen ein (anonymer) Benutzer auf einem Frontend einsehen kann. In einer ersten Phase sind diesbezüglich in PECAN noch keine Restriktionen definiert, d.h. ein Benutzer kann grundsätzlich alle Zertifikate mit entsprechenden Statusinformationen einsehen. Diese Policy wird man in einer späteren Version von PECAN vielleicht ändern müssen.
Aus der Sicht eines Benutzers, der in den Besitz eines Zertifikates gelangen möchte, sieht der Betriebsablauf folgendermassen aus:
Eine Schwachstelle beim heutigen Einsatz von Zertifikaten und dazugehörigen privaten Schlüsseln stellt die Client-seitige Verwaltung dar. Idealerweise würden diese Schlüssel in Chipkarten abgelegt und die sichere Umgebung nie verlassen. Weil Chipkarten und entsprechende Lesegeräte aber heute noch relativ teuer und entsprechend wenig verbreitet verbreitet sind, werden die privaten Schlüssel meist mit Hilfe eines symmetrischen Kryptosystems chiffriert und im lokalen Dateisystem abgelegt. Der Schlüssel, der zur Chiffrierung und Dechiffrierung der privaten Schlüssel eingesetzt wird, wird dabei von einem vom Benutzer wählbaren Passwort oder Passsatz abgeleitet. Die Schwäche dieses Verfahrens ist in vielen empirischen Untersuchungen nachgewiesen worden. Längerfristig wird diese Schwäche durch den Einsatz von Chipkarten und entsprechenden Lesegeräten sicherlich reduziert. Massgeblich an dieser Entwicklung beteiligt sind natürlic h Signaturgesetzte (wie z.B. das SigG in Deutschland), die den Einsatz von Chipkarten und entsprechenden Lesegeräten explizit oder implizit vorschreiben.
5. Schlussfolgerungen und Ausblick
Um den zunhemend grossen Bedarf an CA-Dienstleistungen in der Schweizerischen Bundesverwaltung abzudecken, hat die Sektion Informatiksicherheit des Bundesamtes für Informatik (BFI/SI) die Architektur eines verteilten Zertifikat-Managementsystems (DCMS) erarbeitet und in Form einer Sammlung von CGI- und Perl-Skripts mit der Bezeichnung PECAN auch umgesetzt und pilotiert.
In diesem Beitrag sind die Architektur des DCMS, die Pilotimplementierung PECAN, sowie die Betriebsabläufe und Vorgehensweisen für den Einsatz von PECAN in der Schweizerischen Bundesverwaltung vorgestellt und diskutiert worden. Auf das spezielle Problem der Schlüsselrücknahme ist dabei nicht eingegangen worden. Im Prinzip gibt es für dieses Problem zwei sich gegenseitig ergänzende Ansätze [Oppliger00]:
Die Situation ist vergleichbar mit der Sperrung von kompromittierten Kreditkarten. Wurden früher noch entsprechende Listen mit gesperrten Kreditkartennummern an die Händler verteilt, ist man in der jüngeren Vergangenheit in zunehmendem Masse zu Online-Statusabfragen übergegangen. Eine solche Entwicklung zeichnet sich zur Zeit auch für den Einsatz von Zertifikaten ab.
Abb. 2 ¾ Ein mögliches Zertifizierungsschema für CA-Dienstleistungserbringer
Die Aufwände für die Pilotierung sind relativ bescheiden und die mit PECAN gemachten Erfahrungen können als positiv bezeichnet werden. Eine auch in anderen Zusammenhängen immer wieder gemachte Feststellung kann dabei einmal mehr bestätigt werden: Im operativen Betrieb einer CA bzw. PKI bereitet insbesondere die Schnittstelle zu den Benutzern immer wieder und zum Teil auch grössere Probleme. Diesen Problemen kann man nur durch eine solide Grundausbildung der Benutzer in bezug auf die grundlegenden Konzepte und Techniken asymmetrischer Kryptosysteme und entsprechender Zertifizierungsmechanismen, sowie durch ein technisch versiertes und entsprechend grosszügig ausgelegtes Help Desk begegnen. Beide Ziele sind nicht einfach zu erreichen.
Längerfristig wird man in der Schweizerischen Bundesverwaltung wahrscheinlich dazu übergehen, CA-Dienstleistungen fremdzubeziehen. Für diesen Fall muss aber die Frage geklärt sein, wann d.h. unter welchen Bedingungen und Voraussetzungen man einem CA-Dienstleistungserbringer vertrauen darf. Um diese Frage sinnvoll beantworten zu können, wird ein Zertifizierungsschema für Zertifizierungsdienst-leistungserbringer erarbeitet, das in Abb. 2 schematisch dargestellt ist. In diesem Schema gibt es eine Schweizerische Akkreditierungsstelle, die für die Akkreditierung sowohl von Prüflaboratorien (Information Technology Security Evaluation Facilities, ITSEFs) als auch von entsprechenden Zertifizierungsorganen (Certification Bodies, CBs) in der Schweiz zuständig ist (andere Staaten haben andere Stellen, die für Akkreditierungen zuständig sind). Die ITSEFs sind ihrerseits für die sicherheits-technische Prüfung von Produkten zuständig. Diese Prüfung kann auf der Basis bestehender Kriterienkataloge erfolgen, wie z.B. den Trusted Computer Security Evaluation Criteria (TCSEC), den Information Technology Security Evaluation Criteria (ITSEC) oder den Common Criteria (CC). Auf der anderen Seite sind die CBs für die Zertifizierung von CA-Dienstleistungserbingern zuständig. Diese Zertifizierung kann auf der Grundlage verschiedener Kriterienkataloge erfolgen, wobei im Hinblick auf eine digitale Signaturgesetzgebung sich wahrscheinlich ein entsprechender Katalog durchsetzen wird. Die für die Zertifizierung zu verwendenden Kriterienkataloge werden in der Schweiz im Rahmen der AG DigSig und unter Mitwirkung entsprechender Wirtschaftsvertreter erarbeitet. Längerfristig ist sehr stark damit zu rechnen, dass die Kriterienkataloge auf europäischer bzw. internationaler Ebene harmonisiert werden.
Literatur
[Blakley79] Blakley, G.R.: Safeguarding cryptographic keys. Proceedings of the AFIPS 1979 National Computer Conference, 1979, S. 313 – 317
[Menezes96] Menezes, A.J., van Oorschot, P.C., Vanstone, S.A.: Handbook of Applied Cryptography. CRC Press, Boca Raton, FL, 1996
[Feigenbaum98] Feigenbaum, J.: Towards an Infrastructure for Authorization. Position Paper presented at the 3rd USENIX Workshop on Electronic Commerce, 1998
[Ford97] Ford, W., Baum, M.S.: Secure Electronic Commerce - Building the Infrastructure for Digital Signatures and Encryption. Prentice Hall, Upper Saddle River, NJ, 1997
[Feghhi99] Feghhi, J., Feghhi, J., Williams,P.: Digital Certificates: Applied Internet Security. Addison-Wesley Longman, Reading, MA, 1999
[Greulich99] Greulich, A., Oppliger, R., Trachsel, P.: A Distributed Certificate Management System (DCMS) Supporting Group-based Access Controls. Zur Publikation eingereicht
[He96] He, J., Dawson, E.: On the Reconstruction of Shared Secrets. Proceedings of IFIP SEC ‘96, pp. 209 – 218
[ITU88] ITU-T Empfehlung X.509: Information Technology – Open Systems Interconnection – The Directory: Authentication framework. 1988 (ISO/IEC 9594-8)
[Oppliger98] Oppliger, R.: Internet and Intranet Security. Artech House, Norwood, MA, 1998
[Oppliger00] Oppliger, R.: A Security Primer for the World Wide Web. Artech House, Norwood, MA, 2000
[Oppliger99] Oppliger, R., Pernul, G., Strauss, Ch.: Using Attribute Certificates to Implement Role-based Authorization. Zur Publikation eingereicht
[Schneier96] Schneier, B.: Applied Cryptography. 2nd Edition, John Wiley & Sons, 1996
[Shamir79] Shamir, A.: How to share a secret. Communications of the ACM, Vol. 22, No. 11, November 1979, pp. 612 - 613