Akzeptanz von Vertrauensräumen in IT-Infrastrukturen

Transkript

1 Frédéric Naujokat, Arno Fiedler, Wolfgang Schwab Akzeptanz von Vertrauensräumen in IT-Infrastrukturen Bildung nicht hierarchischer Vertrauensräume mittels des ETSI TSL-Konzeptes im Gesundheitswesen Für das Gesundheitswesen wird eine komplexe Telematikinfrastruktur mit hohen Anforderungen sowohl an die Berechtigungsnachweise handelnder Akteure als auch an die Sicherheit der im Netz eingesetzten technischen Komponenten benötigt. Grundsätzlich werden alle Identitäten mit X.509-Zertifikaten verwaltet. Im Beitrag wird dargestellt, wie die dabei beteilligten Zertifizierungsinstanzen in einer Bridge-Konfiguration auf Grundlage des ETSI TSL-Konzeptes zu einem Vertrauensraum zusammen geführt werden. Frédéric Naujokat IT-Consultant beim IT-Dienstleister adesso AG. Als Medizininformatiker ist er Spezialist für die Prozesse im Gesundheitswesen und verfügt über umfassende Erfahrung im Bereich Telematik, PKI sowie in allen Fragen rund um die elektronische Gesundheitskarte. Arno Fiedler GF der Nimbus Techn o l o g i e b e r a t u n g GmbH, Berlin. Projekterfahrung bei ChamberSign, ISIS- MTT, Signaturbündnis, JobCard. Derzeit aktiv für die PKI der EGK und bei ETSI ESi arno.fiedler@teletrust.de Wolfgang Schwab Mitarbeiter der gematik. Projektleiter zur Realisierung der Komponenten-PKI wolfgang.schwab@gematik.de Einleitung Aufgrund des medizinischen Fortschritts wächst die Leistungsfähigkeit des deutschen Gesundheitswesens kontinuierlich trotz des enormen Kostendrucks. Wie in den meisten anderen Lebensbereichen auch bildet die effektive Erhebung, Verarbeitung und Speicherung von Informationen dabei einen entscheidenden Erfolgsfaktor sowohl für den Einzelnen als auch für das Gesamtsystem. Allerdings besteht in keinem anderen Bereich eine so starke Notwendigkeit einer selbstbestimmten und datenschutzgerechten Verwendung der gesundheitsrelevanten Informationen wie im Gesundheitswesen. Mit der Einführung der elektronischen Gesundheitskarte wird zurzeit ein bundesweites Gesundheitsnetzwerk aufgebaut, mit dessen Hilfe Krankenhäuser, Krankenkassen, Ärzte, Apotheker und Patienten zuverlässig und vertrauenswürdig Informationen austauschen können. Diese Infrastruktur der Gesundheitstelematik hat einen sehr hohen Schutzbedarf hinsichtlich der Vertraulichkeit, Integrität, Zugriffsberechtigung und der Nicht-Abstreitbarkeit. Zur Sicherstellung der Vertraulichkeit werden alle sensiblen Daten mehrfach verschlüsselt. Die jeweiligen Entschlüsselungs-Codes werden unauslesbar in sicherheitsevaluierten High-Security-Modules, z. B. Kryptochipkarten, gespeichert. Wesentlich für die Akzeptanz einer solchen Telematikinfrastruktur ist aber auch, dass ausschließlich berechtige Akteure, z. B. die behandelnden Ärzte, auf die für sie relevanten Daten zugreifen dürfen. Hierfür werden durch eine übergeordnete vertrauenswürdige Instanz X.509-Identitätszertifikate ausgestellt, die sowohl die Person identifizieren als auch deren berufsrechtliche Zulassung erkennen lassen. Um das Netzwerk abzusichern und logisch die Zugriffe zu beschränken, werden auch alle technischen Komponenten mit Zertifikaten ausgestattet. Einige Komponenten, wie z. B. die Konnektoren, erhalten sogar mehrere davon. Die Vertrauenswürdigkeit der Instanzen (Zertifizierungsstelle, Trust-Service- Provider (TSP), welche derartige Identitätszertifikate herausgeben, bildet das entscheidende Kriterium für die Sicherheit, Verfügbarkeit und die Akzeptanz der gesamten Infrastruktur. Zur Überprüfung der Zertifikate muss gewährleistet sein, dass dem signierenden TSP uneingeschränkt vertraut werden kann. Das Vertrauen in die gesamte Infrastruktur kann nur bestehen, wenn alle beteiligten TSP DuD Datenschutz und Datensicherheit

2 Abb. 1 Struktur der PKI mit TSL und beteiligten Akteuren 1 ETSI als Basis einheitlichen Sicherheitsvorgaben genügen, deren Einhaltung durch eine unabhängige Instanz bestätigt wird. In den 80er und 90er Jahren wurde zur Bestätigung der Identität der vertrauenswürdigen TSP der klassische Ansatz einer PKI-Hierarchie gewählt. Hierbei ordnen sich die TSP dem Betreiber einer zentralen Root unter. Beispielhaft dafür ist das von der Bundesnetzagentur betriebene System für akkreditierte Zertifizierungsdiensteanbieter auf Basis des Signaturgesetzes. Ein derartiger Ansatz entspricht nicht immer den Bedürfnissen der Anwender nach Flexibilität und individueller Gestaltung der Abläufe. Oftmals bestehen auch psychologische Barrieren bei der Akzeptanz, insbesondere in einem föderalistisch geprägten System. Zwecks Schaffung des Vertrauensraumes für die Infrastruktur der Gesundheitstelematik wurde nach umfangreicher Evaluierung entschieden, für die übergeordneten X.509-Zertifikate der ausstellenden Organisationen (bzw. deren TSP) nicht den Ansatz einer hierarchischen Kontrolle der Zertifikatserstellung zu verfolgen, sondern das Konzept einer zentralisierten (Online-)Zertifikatsprüfung umzusetzen. Die Erfahrungen der European Bridge CA des TeleTrusT e. V. dienten als Grundlage zur praktischen Umsetzung. Die Zulassung erfolgt auf Basis der nachgewiesenen Umsetzung (z. B. durch ein unabhängig auditiertes Sicherheitskonzept) der Vorgaben einer einheitlichen und abgestimmten Certification-Policy. Hierbei werden die Zertifikatsprüfinformationen der TSP zentral erfasst und in einer Trust-service Status List (TSL) in Form einer XML-Datei zusammengesetzt [ETSI], welche wiederum von der gematik bzw. einem beauftragten Dienstleister signiert wird. Die gematik verwendet für die Telematikinfrastruktur zwei dieser Listen, eine für Personen und Organisationen und die andere für Infrastruktur-Komponenten. Damit stellt die jeweilige TSL den gemeinsamen Vertrauensraum im Sinne einer White-List dar. Mit dem Ansatz der Trust-service Status Lists werden im Vergleich mit einem hierarchischen Modell folgende Vorteile erzielt: Die bestehenden heterogenen und komplexen Strukturen im Gesundheitswesen können mit geringem Aufwand integriert werden. Unterschiedliche Sicherheitslevel hinsichtlich personen- und organisationsbezogener Zertifikate können in einer Infrastruktur abgebildet werden. Anpassungen an neue oder veränderte Rahmenbedingungen sind schnell zu implementieren. Der Vertrauensstatus aller TSP ist für die Fachöffentlichkeit aufgrund der transparenten Darstellung objektiv nachvollziehbar. Entscheidend für den Erfolg der Akzeptanz von PKI ist die Nutzung und Prüfung der Zertifikate auch durch Dritte (Relying-Party), die nicht unmittelbar in die Infrastruktur und deren technische Vorgabe einbezogen sein müssen. Frühzeitig wurde dieser Bedarf an Interoperabilität durch die internationalen Normungsgremien erkannt. Auf europäischer Ebene haben sich in diesem Bereich CEN und ETSI die Aufgaben geteilt: Bei CEN liegen die Schwerpunkte im Bereich der Kryptochipkarten, der sicheren Signaturerstellungseinheiten und spezifischen Anwendungen (z. B. Citizen- Cards). ETSI erstellt Spezifikationen auf Basis internationaler Best Practises z. B. für Signaturformate, Certification-Policies und deren Anwendungen, z. B. im Bereich registered und einvoice. Eine Besonderheit stellt der Standardisierungsprozess der Trust-service Status List in den Jahren 2002 bis 2004 dar. Hier wurde unter Berücksichtigung der verschiedenen europäischen Rechtssysteme ein integrativer Ansatz zur Bildung von Vertrauensräumen entwickelt. Die im Mai 2005 veröffentlichte Version des ETSI TS V1.2.1 ( ) Technical Specification Electronic Signatures and Infrastructures (ESI); Provision of harmonized Trust Service Provider status information zielt vorrangig darauf ab, die Informationen über die Dienste, den Status und die relevanten Prüfinformationen des TSP in standardisierter, signierter und maschinenlesbarer Form bereitzustellen. Durch verschiedene Generationen von TSL kann auch eine komplette Historie des TSP-Status verlässlich dokumentiert werden. Dadurch wird die Möglichkeit geschaffen, Zertifikatsprüfungen unter Einsatz des international gebräuchlichen Gültigkeitsmodells auf in der Vergangenheit liegende Prüfzeitpunkte durchzuführen. Die staatliche italienische Aufsichtbehörde CNIPA nutzt diese Mechanismen seit dem Jahre 2003 zur Dokumentation des Vertrauensstatus und zur Verteilung der Root-Schlüssel aller zugelassenen TSP. Die flächendeckende Verteilung dieser Liste soll über die italienische Version des Acrobat Reader erfolgen. 606 DuD Datenschutz und Datensicherheit

3 2 Das TSL-Konzept Abb. 2 Struktur der PKI mit TCL und beteiligten Akteuren Hinsichtlich der verwendeten kryptographischen Komponenten in Bezug auf Algorithmengüte, Schlüssellängen, Schutz des geheimen Schlüssels und Systemverfügbarkeit sind an alle Signaturerstellungseinheiten und die zugehörigen Zertifikate sehr hohe Anforderungen zu stellen. Für Verschlüsselungs- (ENC/ENCV), Authentisierungs- (AUT/AUTN) und Organisationszertifikate (OSig) ist das Konzept einer flachen zweistufigen Hierarchie, wie es für qualifizierte elektronische Signaturen mit Anbieterakkreditierung gesetzlich bestimmt wurde, sektorübergreifend nicht durchsetzbar. Der Grund dafür ist eine zu erwartende Vielzahl von Zertifikatsherausgebern und die Notwendigkeit der Einbindung bestehender Strukturen. Die Abbildung 1 zeigt die beteiligten Akteure in der PKI und unterstreicht die Komplexität des Systems. In Hinsicht auf Verbraucherschutz, Haftungsaspekte, Identifizierung und Registrierung durch die Kostenträger, einen Mechanismus zum Entschlüsseln der Daten bei Verlust des ENC-Schlüssels sowie Dauer und Kosten der Einführung bestehen grundsätzliche Unterschiede zu den Regelungen bei qualifizierten Zertifikaten. Daher wurde entschieden, als Vertrauensmodell eine Bridge-Struktur zu wählen, bei der die individuellen Vertrauensinformationen der verschiedenen TSP in einer signierten XML-Datei abgelegt werden (ETSI Trust-service Status List). Nähere Informationen zur TSL sind in dem Dokument [gemx.509_tsl] veröffentlicht. Hierzu wird auf Basis der im Sicherheitskonzept als erforderlich definierten Maßnahmen zur Nutzung von PKI-Komponenten eine übergreifende Certificate- Policy für ENC-, AUT- und OSig-Zertifikate der egk und der SMC-Typ-B entwickelt. Alle beteiligten TSP müssen in ihrem Certification-Practice-Statement die Erfüllung dieser Vorgaben zusichern. Die konkrete Umsetzung der Sicherheitsmaßnahmen im laufenden Betrieb des TSP wird durch zugelassene Prüfinstitute begutachtet. Jede der in diesem Vertrauensmodell aufgeführten Certificate-Authority (CA) muss durch eine zentrale Stelle legitimiert worden sein. Dieser Vorgang geschieht durch die Aufnahme in eine Trusted-Service Status-List. Die TSL enthält die öffentlichen Schlüssel aller vertrauenswürdigen CA sowie die Information über den für diese CA akkreditierten Zertifikatstyp als auch die Adresse der Zertifikats-Status-Dienste (OCSP-Responder und CRL Provider). Sie ist durch gematik-tsl-service-provider signiert. 2.1 Anpassung der Struktur an die Telematikinfrastruktur Da bei den geräte- und dienstspezifischen Komponentenzertifikaten ähnliche Rahmenbedingungen hinsichtlich Herausgeber- und Strukturvielfalt bestehen, wird hier analog verfahren. Die Vertrauensinformationen der Herausgeber dieser Zertifikate werden in einer eigenen TSL abgelegt und veröffentlicht. Zur Unterscheidung wird diese als Trusted-Component- List (TCL) bezeichnet. Somit ergibt sich eine Struktur, wie sie in Abbildung 2 dargestellt ist. Nähere Informationen zur TCL sind im Dokument [gemx.509_tcl] veröffentlicht. 2.2 Verteilung und Akzeptanz Für die Auswertung der Zertifikate sind normative Festlegungen bzgl. der Prüfung des Vertrauensraumes (kommt das Zertifikat aus einer vertrauenswürdigen Quelle?) und des Zertifikatsstatus (ist das Zertifikat gültig oder gesperrt?) essentiell. Die Prüfaufgaben lassen sich wie folgt formulieren: Ist diesem Zertifikat zu vertrauen? Welche Rolle bestätigt dieses Zertifikat? Welche Identität bestätigt dieses Zertifikat? Dafür ist einerseits sicherzustellen, dass die prüfende Komponente über eine lokal vorliegende und auf Gültigkeit geprüfte TSL verfügt, andererseits muss die Validierungskette komplett durchlaufen werden, um die aktuelle Gültigkeit des Zertifikats bewerten zu können. Generell gilt für die Zertifikatsprüfung, dass zum einen das End-Entity-Zertifikat per OCSP, zum anderen das Aussteller- Zertifikat anhand der TSL auf Gültigkeit geprüft wird. Die TSL hat dabei die Funktion eines gemeinsamen Vertrauensraumes im Sinne einer White-List der zugelassenen Herausgeber. Um ein Aussteller-Zertifikat mittels TSL prüfen zu können, muss zunächst eine aktuelle und gültige TSL im zertifikatsprüfenden System vorliegen. Im Folgenden werden die notwendigen Prüfschritte zur Prüfung des Vertrauensraumes kurz aufgelistet: Download der TSL Prüfung der Aktualität und Validierung der TSL Prüfung des TSL-Signaturzertifikats mit Hilfe eines sicher verwahrten gematik-tsl-root-schlüssels DuD Datenschutz und Datensicherheit

4 Abb. 3 Use-Case-Diagramm Prozesse zur Nutzung des Vertrauensraumes näher erläutert. Dieser Prozess orientiert sich an den Anforderungen der Telematikinfrastruktur. Für die Prüfung der Zertifikate gelten folgende Vorbedingungen: die aktuelle TSL liegt vor, der Vertrauensraum wurde dadurch erfolgreich initialisiert und überprüft, die TSL wurde ausgewertet und z. B. in einen Truststore geladen. Die folgende Use-Case-Übersicht verdeutlicht die Aktionen dieses Systems. Die nachfolgenden Schritte sind für eine Prüfung des Zertifikats (fortgeschrittene Zertifikate) zu durchlaufen und werden hier kurz aufgelistet: Prüfung der Gültigkeit. Prüfung der Vertrauenskette zum jeweiligen Herausgeber, bis zur Identifizierung durch die TSL. Prüfung der mathematischen Korrektheit des Zertifikats (Signaturprüfung). Abfrage des Sperrstatus des ursprünglich zu prüfenden Zertifikats im Ver- Prüfung der Integrität der TSL durch Prüfung der Signatur der TSL Neue TSL-Service-Provider-Zertifikate werden (z. B. bei Generationswechsel) rechtzeitig in die TSL integriert. Dies betrifft konkret folgende Zertifikate: TSL-Signaturzertifikat TSL-Root-Zertifikat Dadurch wird die Integrität der neuen Schlüssel durch die gültigen alten gesichert. Abb. 4 Use-Case-Diagramm Zertifikatsprüfung 3 Mechanismen und Prüfungen In der Telematikinfrastruktur muss jede CA Informationen über durch sie signierte und widerrufene Zertifikate zur Verfügung stellen. Hierdurch wird es gegebenenfalls möglich, einzelne Zertifikate sowie alle durch eine CA signierten Zertifikate zu sperren. Innerhalb der Telematik müssen Statusabfragen für Zertifikate immer durch das Online-Certificate-Status-Protokoll (OCSP) durchgeführt werden. Daher muss jede CA einen OCSP-Responder für die durch sie signierten Zertifikate anbieten. Dies hat den Vorteil, dass zwar für ein gegebenes Zertifikat der Status abgefragt werden kann, jedoch die Information über gesperrte Zertifikate nicht unnötig verteilt wird. Bei Bedarf allerdings nur im Ausnahmefall wird aus Gründen der Skalierbarkeit und Komplexitätsreduktion die Verwendung von Certificate-Revocation- Lists (CRLs) zur Verifizierung von nicht qualifizierten Signaturen vorgegeben. Die Adresse des OCSP-Responders (und ggf. CRL-Providers) ist für jede CA in dem TSL-Eintrag des entsprechenden CA-Zertifikats enthalten. In diesem Abschnitt wird die Gültigkeitsprüfung von X.509-Zertifikaten in Verbindung mit dem Vertrauensraum TSL gleich mit dem im ServiceSupplyPoint der TSL eingetragenen OCSP-Responder. Danach erfolgt die Prüfung: der Autorität des OCSP-Zertifikats (ist der OCSP-Responder in der TSL registriert?), des Inhalts der OCSP-Antwort (Sperrstatus). Rollenprüfung. Bei jeder dieser Prüfungen muss nicht nur die mathematisch-kryptographische Kor- 608 DuD Datenschutz und Datensicherheit

5 rektheit der jeweiligen Mechanismen, sondern auch deren Zulässigkeit mit in die Prüfung einbezogen werden. Zum Beispiel darf ein Zertifikat, welches nicht mit einem zugelassenen Hash-Algorithmus signiert ist, nie als gültig eingestuft werden. Wenn auch nur eine Prüfung aus technischen oder anderen Gründen fehlschlägt, darf das Zertifikat nicht als gültig gesehen werden. Die Verwendung von Informationen aus Zertifikaten kann nur dann erfolgen, wenn das zugehörige Zertifikat validiert wurde. Somit muss eine Zertifikatsprüfung der Ermittlung bestätigter Zertifikatsinformationen vorangehen. Abb. 5 QES-Prüfschritte 4 TSL und QES In diesem Abschnitt werden einige grundsätzliche Aspekte im Hinblick auf die Prüfung von qualifizierten elektronischen Signaturen dargestellt: Prüfung der Gültigkeit des Zertifikats in Bezug auf den Signaturerstellungszeitpunkt bzw. Authentifizierungszeitpunkt und dem zu Grunde liegenden Gültigkeitsmodell. Prüfung des Status des Zertifikats. Der jeweilige ZDA stellt dazu entsprechende Abfragedienste zur Verfügung. Prüfung der Anwendungsbereiche des Zertifikats und die damit verbundenen Einschränkungen. Die Schlüsselpaare und Zertifikate dürfen nur für ihren jeweiligen Anwendungsbereich benutzt werden (im Sinne der Nicht-Abstreitbarkeit ( nonrepudiation bzw. content commitment ). Eine Aussage über die Gültigkeit der Signatur wird über eine zugelassene, im Amtsblatt der BNetzA aufgeführten, Signaturanwendungskomponente getroffen. Prüfung auf Vorhandensein der Extension QCStatement. Bei der Prüfung eines qualifizierten Zertifikates muss der gesamte Zertifikatspfad bis hin zur Root ermittelt und überprüft werden. Dies stellt besondere Anforderungen an die Aufbewahrung und Ermittlung des sicheren Schlüsselspeichers. Die TSL könnte für den Aufbau dieses Zertifikatspfades verwendet werden. Sie stellt somit den sicheren Zertifikatsspeicher dar. In der Abbildung 5 sind die wesentlichen Use-Cases dargestellt, die verantwortlich für die QES-Zertifikatsprüfung sind. Die Systeme verwenden hier die TSL als Grundlage des Zertifikatspfades und zur Prüfung des End-Anwender-Zertifikates. Fazit Bedingt durch die heterogenen Strukturen des deutschen Gesundheitswesens bildet die TSL einen pragmatischen und flexiblen Ansatz zur Bildung eines einheitlichen Vertrauensraumes. Die Vorteile gegenüber einem strikt hierarchischen Ansatz überwiegen. Leider wartet eine supranationale Realisierung dieses Konzeptes trotz des dringenden Bedarfs innerhalb der Europäischen Union noch immer auf die Umsetzung. Eine vereinheitlichte Trust-service Status List der jeweils nationalen Regulierungen unterliegenden TSP kann für alle Anwendungsfelder des elektronischen Geschäftsverkehrs von hohem Nutzen sein und zur Bildung eines Europäischen Vertrauensraumes beitragen. Es ist zu hoffen, dass die positiven Erfahrungen im Bereich der deutschen Gesundheitstelematik den Impuls für eine paneuropäische Realisierung des TSL-Konzeptes geben können. Wenn alle Beteiligte, also auch die Gesamtheit der Krankenversicherten, dieser Infrastruktur aufgrund objektiver (z. B. Zertifizierung und Zulassung) und subjektiver Kriterien ( gefühlte Sicherheit) vertrauen, werden die erforderlichen Veränderungen der Prozesse zeitnah umzusetzen sein. Das Konzept der Trust-service Status List als Fundament eines transparenten Vertrauensraumes bildet eine gute Basis dafür. Literatur ETSI ETSI Technical Specification TS ( Provision of harmonized Trust Service Provider (TSP) status information ) ISIS ISIS-MTT-Specification, Common ISIS-Mail- TrusT Specification For PKI-Applications, T7 & TeleTrusT Version 1.1 gemx.509_tsl PKI für die X.509-Zertifikate: Registrierung eines Trust Service Provider, gematik, Version gemx.509_tcl PKI für X.509-Zertifikate: Konzeption und Registrierungsanforderungen der Trusted Component List (TCL), gematik, Version DuD Datenschutz und Datensicherheit