Einführung der Gesundheitskarte Verwendung von Zertifikaten in der Telematikinfrastruktur

Transkript

1 Einführung der Gesundheitskarte Verwendung von Zertifikaten in der Telematikinfrastruktur Version: Revison: main/rel_main/21 Stand: Status: freigegeben gematik_pki_verwendung_zertifikate_der_ti.doc Seite 1 von 102

2 Dokumentinformationen Änderungen zur Vorversion Anpassung des Speicherorts für den Zertifikatstyp von AdditionalInformation nach CertificatePolicies. Anpassung des Use Case zur Ermittlung des Zertifikatstyps. Die Zertifikatsprüfung wird um das Eingangsdatum Referenzzeitpunkt erweitert. Aufnahme der QES-Prüfung in Kap. 12. Anpassung der SSL-Prüfung in Kap. 11. Inhaltliche Änderungen gegenüber der letzten freigegebenen Version sind gelb markiert. Sofern ganze Kapitel eingefügt oder umfassend geändert wurden, wurde zur besseren Lesbarkeit lediglich die Überschrift durch gelbe Markierung hervorgehoben. Referenzierung Die Referenzierung in weiteren Dokumenten der gematik erfolgt unter: [gemverw_zert_ti] gematik: Einführung der Gesundheitskarte - Verwendung von Zertifikaten in der Telematikinfrastruktur Dokumentenhistorie Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Bearbeitung Neuerstellung gematik AG Bearbeitung gematik AG Neue Diagramme, Überarbeitung gematik AG Validierungspfad, Rollenermittlung gematik AG Überarbeitung gematik AG Neue TUC und Überarbeitung gematik AG Erweiterung TUC gematik AG Präzisierung der TUCs gematik AG ,8 der TUCs gematik AG TUC-Erweiterungen SPE/ZD Einarbeitung Kommentare Komplette Überarbeitung mehrer Kapitel SPE/ZD gematik_pki_verwendung_zertifikate_der_ti.doc Seite 2 von 102

3 Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Bearbeitung Einarbeitung Kommentare (nach weiterer IQS) SPE/ZD freigegeben gematik ,9 Überarbeitung SPE/ZD Einarbeitung Kommentare SPE/ZD freigegeben gematik , 12 QES-Prüfung, Einführung Referenzzeitpunkt SPE/ZD Einarbeitung Kommentare SPE/ZD freigegeben gematik gematik_pki_verwendung_zertifikate_der_ti.doc Seite 3 von 102

4 Inhaltsverzeichnis Dokumentinformationen...2 Inhaltsverzeichnis Zusammenfassung Einführung Zielsetzung und Struktur des Dokumentes Zielgruppe Geltungsbereich Arbeitsgrundlagen Abgrenzung des Dokumentes Methodik Verwendung von Schüsselworten Hinweis auf offene Punkte Technische Use Cases (TUC) Anforderungen Gesamtüberblick der verwendeten Zertifikate Standardvorgaben für Zertifikate Angaben zum Zertifikatstyp in der Extension CertificatePolicies Admission Einordnung der Zertifikate innerhalb der Gesamtarchitektur Einteilung der Zertifikate Vertrauensraum Prozesse zur Nutzung des Vertrauensraums Initialisierung im Offline-Fall Initialisierung ohne Vorbedingungen Referenzierbare Use Cases Erreichbarkeit der TSL TUC_PKI_001 "Initialisierung Vertrauensraum" TUC_PKI_019 "Prüfung der Aktualität der TSL"...27 gematik_pki_verwendung_zertifikate_der_ti.doc Seite 4 von 102

5 8.8 TUC_PKI_020 "XML Dokument validieren" TUC_PKI_011 "Prüfung der Integrität des Signaturschlüssels" TUC_PKI_012 "XML Signatur Prüfung" TUC_PKI_013 "Bereitstellen neuer Vertrauensanker" TSL-Einträge für die Bereitstellung neuer Vertrauensanker TUC_PKI_016 "Download der TSL" TUC_PKI_017 "Lokalisierung Download-Adressen" Zertifikatsprüfung Prüfung im Offline-Fall Referenzierbare Use Cases TUC_PKI_018 "Zertifikatsprüfung" TUC_PKI_002 "Gültigkeitsprüfung des Zertifikats" TUC_PKI_003 "CA Zertifikat in TSL finden" TUC_PKI_004 "Mathematische Prüfung der Zertifikatssignatur" TUC_PKI_005 "OCSP Adresse ermitteln" TUC_PKI_006 "OCSP-Abfrage" TUC_PKI_021 "CRL-Check" TUC_PKI_009 "Rollenermittlung" Weitere Prüfungen Umgang mit kritischen Extensions Bestätigte Zertifikatsinformationen TUC_PKI_007 "Unterscheidung von Zertifikatstypen" TUC_PKI_010 "Abgleich ob Zertifikatsherausgeber berechtigt ist" TSL Extension Spezifikation der Extension OIDs für die Dienste für TSL Überprüfung der Zertifikate auf Transportebene Generelle Vorgaben der Gesamtarchitektur zu SSL SSL-Verbindungsaufbau Definition der Error Condition für TLS Festlegungen der gematik QES-Zertifikatsprüfung TUC_PKI_030 "QES-Zertifikatsprüfung" TUC_PKI_031 "QES-Zertifikatspfad bilden und prüfen" TUC_PKI_032 "QES-Zertifikatspfad validieren"...81 gematik_pki_verwendung_zertifikate_der_ti.doc Seite 5 von 102

6 12.4 TUC_PKI_033 "QES-Sperrstatus prüfen" TUC_PKI_034 "QES-Sperrstatus über OCSP" TUC_PKI_035 "QES-Sperrstatus über CRL" Vorgaben zur Fehlerbehandlung...96 Anhang...97 A1 - Abkürzungen...97 A2 - Glossar...97 A3 - Abbildungsverzeichnis...98 A4 - Tabellenverzeichnis...98 A5 - Referenzierte Dokumente...99 A6 Klärungsbedarf / Offene Punkte gematik_pki_verwendung_zertifikate_der_ti.doc Seite 6 von 102

7 1 Zusammenfassung Das Dokument Verwendung von Zertifikaten in der Telematikinfrastruktur legt normativ fest, wie die Prüfung und Auswertung der X.509-Zertifikate in der Telematikinfrastruktur erfolgen muss. Hierzu beschreibt dieses Dokument im Sinne einer Zusammenfassung die unterschiedlichen Typen von Zertifikaten und deren Herausgabe und Nutzung in der Telematikinfrastruktur. Zur Identifikation von Personen, Objekten, Organisationen, Geräten, Rechten und Rollen werden elektronische Zertifikate verwendet, bei denen die Identität durch eine übergeordnete vertrauenswürdige Instanz mittels einer elektronischen Signatur bestätigt wird. In der Telematikinfrastruktur werden diese Zertifikate genutzt um dann die jeweilige Rolle bzw. Identität zu bestätigen. Ein zentrales hierarchisches Root-Modell ist v. a. aufgrund der Heterogenität und Komplexität der beteiligten Zertifikate und der Vielfalt der beteiligten Organisationen nicht praktikabel umsetzbar. Daher wird für die übergeordneten X.509-Zertifikate der ausstellenden Organisationen, der sog. Trust Service Provider (TSP), das Konzept der zentralisierten (Online-) Zertifikatsprüfung umgesetzt. Hierbei werden die Zertifikatsprüfinformationen der TSPs zentral erfasst und in einer Trust-service Status List (TSL) zusammengesetzt [ETSI], welche wiederum von der gematik bzw. einem beauftragten Dienstleister (gematik TSL-Service-Provider) signiert wird. Die gematik verwendet für die Telematikinfrastruktur zwei dieser Listen, eine für Personen und Organisationen und eine für Infrastruktur-Komponenten. Damit stellt die jeweilige TSL den gemeinsamen Vertrauensraum im Sinne einer White-List dar. Im weiteren Verlauf wird nur von der TSL gesprochen. Damit sind aber beide Listen gemeint. Neben den X.509-Zertifikaten werden innerhalb der Telematikinfrastruktur auch CV- Zertifikate eingesetzt. Diese dienen der C2C-Authentisierung von Chipkarten, hier insbesondere der egk und HBA (bzw. SMC). Bei Anwendung der CV-Zertifikate erfolgt zwischen egk und HBA (bzw. SMC) die vorgeschriebene gegenseitige Authentifikation. Die wichtigsten Aspekte zum Einsatz dieses Zertifikatstyps werden in diesem Dokument zusammenfassend beschrieben. Für die Auswertung der Zertifikate sind normative Festlegungen bzgl. Prüfung des Vertrauensraums (kommt das Zertifikat aus einer vertrauenswürdigen Quelle?) und des Zertifikatsstatus (ist es 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 zum Einen sicherzustellen, dass die prüfende Komponente über eine lokal vorliegende und auf Gültigkeit geprüfte TSL verfügt, zum anderen muss die im Dokument detailliert beschriebene Validierungskette komplett durchlaufen werden, um die aktuelle Gültigkeit des Zertifikats bewerten zu können. Die einzelnen Prüfschritte werden im Dokument in Form von "Technischen Use Cases" dargestellt. gematik_pki_verwendung_zertifikate_der_ti.doc Seite 7 von 102

8 Aus den Personen- bzw. Organisationszertifikaten muss die Rolle des Datenbearbeiters ermittelt werden können. Für die Rollenermittlung werden verbindliche Vorgaben getroffen und Algorithmen beschrieben. Da ein Großteil der Komponentenzertifikate zum Aufbau von SSL-Verbindungen eingesetzt wird, macht das Dokument Vorgaben zum Verhalten und der Zertifikatsprüfung beim Aufbau dieser SSL/TLS-Verbindungen. Abschließend werden konkrete Vorgaben zur generellen Behandlung von Fehlerfällen bei der Überprüfung des Vertrauensraums und dem Abarbeiten der Validierungskette getroffen. gematik_pki_verwendung_zertifikate_der_ti.doc Seite 8 von 102

9 2 Einführung 2.1 Zielsetzung und Struktur des Dokumentes Das Dokument Verwendung von Zertifikaten in der Telematikinfrastruktur beschreibt einerseits die unterschiedliche Nutzung von Zertifikaten in der Telematikinfrastruktur und stellt andererseits normative Vorgaben zur Prüfung dieser auf. Ziel ist die Vorgabe der Verfahren und Rahmenbedingungen für die Spezifikation zur Prüfung von Zertifikaten der einzelnen Komponenten und Dienste der Telematikinfrastruktur. Die Kapitel 4 bis 7 bieten eine Hilfestellung zum Verständnis des Einsatzes der diversen Zertifikate im Rahmen der Einführung der egk. Dabei wird eine überblicksartige Zusammenfassung der Informationen zu den eingesetzten Zertifikaten und deren Nutzung aus den genannten Architektur- und Spezifikationsdokumenten gesammelt und in einem Dokument wiedergegeben. Das Kapitel 8 setzt normative Vorgaben zur Ermittlung des Vertrauensraums. Hierbei werden Vorgaben zur Überprüfung der TSL festgelegt und detailliert in Form von Text und UML-Diagrammen beschrieben. Bestandteil des Kapitel 9 ist die Zertifikatsprüfung. Beginnend mit einem groben Ü- berblick des Validierungsprozesses werden nachfolgend die jeweiligen Teilprüfungen im Detail spezifiziert. Hierbei liegt der Fokus auf der Gültigkeit der Zertifikate gemäß den zugrunde liegenden internationalen Standards. In Ergänzung dazu werden im Kapitel 10 die normativen Vorgaben zur Prüfung der fachspezifischen Inhalte eines Zertifikats beschrieben. Grundlage ist die Ermittlung der Rolle des Handelnden aus einem Zertifikat. Das Kapitel 11 beschreibt die Überprüfung der Zertifikate auf Transportebene. Vorgaben zum Verhalten beim SSL Verbindungsaufbau finden sich hier wieder. Das Kapitel 12 beschreibt die QES-Prüfung. Abschließend werden in Kapitel 13 Vorgaben zur Fehlerbehandlung gemacht. In den Kapiteln 8-11 werden Fehlercodes aus diesem Kapitel referenziert. 2.2 Zielgruppe Das Dokument richtet sich an Mitarbeiter der gematik, die mit folgenden Aufgaben betraut sind: Erstellung von Spezifikationen und Architekturen Definition von Betriebsabläufen Definition und Durchführung von Testprozessen Entwicklung von Prototypen der Telematikinfrastruktur. gematik_pki_verwendung_zertifikate_der_ti.doc Seite 9 von 102

10 Es soll dabei das für deren Aufgaben notwendige Verständnis für den Einsatz und die Bewertung von Zertifikaten vermitteln und setzt normative Vorgaben. Des Weiteren richtet sich das Dokument an die externen Beteiligten zur Einführung der Gesundheitskarte, insbesondere diejenigen, die Komponenten der Telematikinfrastruktur entwerfen, erstellen oder testen, die Zertifikate prüfen oder aus ihnen Informationen ermitteln müssen. Für alle hier genannten Gruppen sind die Vorgaben aus Kapitel 8 bis 12 normativ. 2.3 Geltungsbereich Das vorliegende Dokument soll bei den Beteiligten im deutschen Gesundheitswesen für eine einheitliche Sichtweise auf die Verwendung von Zertifikaten sorgen. Gleichzeitig spezifiziert es für die genannten Zielgruppen die Prozesse zur Prüfung der Gültigkeit und der fachspezifischen Inhalte mit normativem Charakter. 2.4 Arbeitsgrundlagen Grundlage für dieses Dokument sind die internationalen Standards: ETSI Technical Specification TS ( Provision of harmonized Trust Service Provider (TSP) status information ) (Mai 2005) ISIS-MTT Common ISIS-MTT Specifications for Interoperable PKI Applications RFC 2560: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol OCSP RFC 3280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Es wurden die in Anhang 5 referenzierten Dokumente berücksichtigt. 2.5 Abgrenzung des Dokumentes Die langfristige Bestimmung der Hash-Algorithmen, der Schlüssellängen und der Signaturalgorithmen ist nicht Gegenstand der Betrachtung, hier werden jeweils aktuell die Empfehlungen der international relevanten Gremien und die Anforderungen von SigG/SigV [ALGCAT] berücksichtigt. Die Festlegungen zum Aktivieren qualifizierter Zertifikate [gemqes] und die Vorgaben für die Vereinheitlichung der Public-Key-Infrastrukturen, insbesondere hinsichtlich der Policy-Aspekte [gemtsl_sp_cp], werden in gesonderten Dokumenten getroffen. Im vorliegenden Dokument werden ebenfalls keine Aussagen zum Management der kryptographischen Schlüssel getroffen. Diesbezüglich wird auf das übergreifende Sicherheitskonzept der gematik [gemsiko] verwiesen, insbesondere auf Abschnitt F5 [gemsi- Ko#AnhF5]. Die für die Verwendung in der TI zulässigen Algorithmen, Schlüssellängen und maximalen Gültigkeitsdauern von Schlüsseln und Zertifikaten werden in [gemsiko] sowie entspre- gematik_pki_verwendung_zertifikate_der_ti.doc Seite 10 von 102

11 chend der Technischen Richtlinie für ecard-projekte der Bundesregierung [BSI-TR03116] normativ vorgegeben. Die freie Auswahl aus den hier zugelassenen Algorithmen durch die Hersteller könnte zu Interoperabilitätsproblemen führen, während die Implementierung aller zulässigen Algorithmen erheblichen Aufwand verursacht. Dieser Konflikt wird durch [gemspec_krypt] adressiert. Ziel des Dokumentes Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur [gemspec_krypt] ist es, das Spektrum der zulässigen kryptographischen Algorithmen, sofern sie betreiberübergreifend verwendet werden, einzuschränken, um so mit einer minimalen Anzahl von Algorithmen kryptographische Interoperabilität herzustellen. Deshalb wird als Basis zur Referenzierung der kryptographischen Algorithmen auf o. g. Dokument, Abschnitt [gemspec_krypt#5.1.1] verwiesen. Des Weiteren werden keine Vorgaben bezüglich der Speicherung und des Schutzes der Zertifikate und der zugehörigen privaten Schlüssel getroffen. Das Dokument trifft Vorgaben für die QES-Prüfung in Kapitel 12, jedoch sind hierfür auch die spezifischen Policies der Berufsständischen Organisationen, welche HBAs herausgeben [BÄK_POL], maßgeblich. 2.6 Methodik Verwendung von Schüsselworten Für die genauere Unterscheidung zwischen normativen und informativen Inhalten werden die dem RFC 2119 [RFC2119] entsprechenden in Großbuchstaben geschriebenen, deutschen Schlüsselworte verwendet: MUSS bedeutet, dass es sich um eine absolutgültige und normative Festlegung bzw. Anforderung handelt. DARF NICHT bezeichnet den absolutgültigen und normativen Ausschluss einer Eigenschaft. SOLL beschreibt eine dringende Empfehlung. Abweichungen zu diesen Festlegungen sind in begründeten Fällen möglich. Wird die Anforderung nicht umgesetzt, müssen die Folgen analysiert und abgewogen werden. SOLL NICHT kennzeichnet die dringende Empfehlung, eine Eigenschaft auszuschließen. Abweichungen sind in begründeten Fällen möglich. Wird die Anforderung nicht umgesetzt, müssen die Folgen analysiert und abgewogen werden. KANN bedeutet, dass die Eigenschaften fakultativ oder optional sind. Diese Festlegungen haben keinen Normierungs- und keinen allgemeingültigen Empfehlungscharakter Hinweis auf offene Punkte Offene Punkte, die bis zur nächsten Dokumentversion bearbeitet werden, sind vorläufig mit den folgenden Konventionen gekennzeichnet Offene Punkte, die arbeitsgruppenübergreifend abgestimmt werden müssen, sind Magenta eingerahmt. Durch die Abteilung Zentrale Dienste/Infrastruktur aufgrund bereits erfolgter Abstimmungen noch zu erweiternde Punkte sind violett markiert. gematik_pki_verwendung_zertifikate_der_ti.doc Seite 11 von 102

12 Formale noch offene Inhalte sind blau markiert. Das Kapitel wird in einer späteren Version des Dokumentes ergänzt. 2.7 Technische Use Cases (TUC) In den Kapiteln 8-10 werden Technische Use Cases beschrieben. Diese dienen einerseits dazu, gemeinsames Verhalten der hier beschriebenen konkreten Use Cases nichtredundant zu definieren. Andererseits bilden sie auch die Grundlage für die Definition fachdienstspezifischer Use Cases in den Facharchitekturen und können dort referenziert werden. Die Notation der Use Cases richtet sich an die allgemeinen Vorgaben und ist wie folgt aufgebaut: TUC_PKI_NNN Operation. Die Use Cases sind in Form einer tabellarischen und teilweise von UML Diagrammen definiert. Tabelle 1: Muster der von technischen Use Cases Name Anwendungsumfeld Vorbedingungen Auslöser Eingangsdaten Komponenten Ausgangsdaten <Bezeichnung des Use Case> <, was Gegenstand und Ziel der Bearbeitung ist> <Beschr. des fachlichen Umfelds, in dem der Use Case relevant ist> <Referenzen auf Gesetze, Normen oder Beispiele, Dokumentation, etc.> <Auflistung der vorgegebenen (z. B. gesetzlichen) Anforderungen> <Ereignis/Aktion und Akteur, welche den Use Case auslösen> <für die Bearbeitung benötigte Eingangsdaten> <Komponenten, die an der Bearbeitung beteiligt sind> <Ergebnisse der Bearbeitung> Referenzen <Referenzen auf Beispiele, weiterführende Dokumente etc. für diesen Anwendungsfall> Standardablauf Ablaufschritte für den Normal-/Idealfall. Die Schritte werden nummeriert. 1. <[Akteur:] Bezeichnung und des Arbeitsschritts> kann auch sein: <Name des Extension Points: > Varianten/Alternativen Ablaufschritte, welche eine vollständige Alternative zum Standardfall beschreiben bzw. Abweichungen und Verzweigungen des Normalfalls darstellen: 1a. <Eintrittsbedingung> 1a.1 "<[Akteur:] eines Sonderfall-Ablaufs>" kann auch sein: <Name des Extension Points: > 2. der Nachbedingung Fehlerfälle < der Fehlerfälle> Technische Fehlermeldung Verarbeitung vermutet werden.> <Technische Fehlermeldungen, die vorgegeben werden oder im Rahmen der Sicherheitsanforderungen <Anforderungen aus dem Sicherheitskonzept oder vom Gesetzgeber> Anmerkungen, Bemerkungen <Use Case spezifische Besonderheiten, etc.> gematik_pki_verwendung_zertifikate_der_ti.doc Seite 12 von 102

13 Zugehörige Diagramme <Verweis auf das zugehörige Diagramm> Offene Punkte <Use Case spezifischer Klärungsbedarf, etc.> In der Tabelle sind die jeweils relevanten Bereiche gefüllt. Nicht relevante Bereiche werden nicht angezeigt. gematik_pki_verwendung_zertifikate_der_ti.doc Seite 13 von 102

14 3 Anforderungen Die Anforderungen müssen noch mit dem Anforderungsmanagement abgestimmt werden. Das Kapitel wird in einer späteren Version des Dokumentes entsprechend überarbeitet. Die Notwendigkeit für normative Vorgaben zur Verwendung von Zertifikaten ergibt sich aus mehreren Anforderungen zur Sicherstellung der Interoperabilität und zur Bildung eines mindest Sicherheitsniveaus der PKI durch die gematik. Die folgende Tabelle enthält die entsprechenden Eingangsanforderungen, wie sie aktuell bereits identifiziert werden können: Tabelle 2: Bereits erfasste Eingangsanforderungen Quelle Anforderungsnummer Anforderungslevel [gempolicy] A_01298 MUSS gematik MUSS die Interoperabilität aller Telematikkomponenten sicherstellen. Dies gilt im Sinne der: * Spezifikationsverantwortung * Verantwortung für das Test- und Zulassungsverfahren * Betriebsverantwortung (Betriebsprozesse sowie das einzuhaltende Sicherheitsniveau) * Sicherstellung der Interoperabilität über alle PKI-Strukturen der Telematikinfrastruktur des Gesundheitswesens [gemsiko] AS-AI MUSS Die Integrität der Infrastrukturdienste sowie der sicherheitsrelevanten technischen Komponenten MUSS gewährleistet werden. [gemspec_kon] AF_KON_051 MUSS OCSP-Abfrage OCSP [RFC2560] MUSS als primäres Verfahren zur Statusprüfung für Zertifikate unterstützt werden, auch im Falle von nicht qualifizierten Zertifikaten. Diese Prüfung ist nur auf das Nutzerzertifikat und nicht auf CA-Zertifikate anzuwenden. Als alternatives Verfahren MUSS der Konnektor auch die Prüfung gegen CRLs unterstützen. [gemspec_kon] AF_KON_052 MUSS Vertrauensanker Vertrauensanker für Root- und CA-Zertifikate sind die signierte Trust-service Status List (TSL) und die Trusted Component List (TCL) der gematik Bridge-CA. [gemgesarch] A_01209 MUSS Zertifikate zur Authentisierung von Akteuren in der Telematikinfrastruktur (AUT von HBA, BA, Diensten und OSIG von SMC-B) MÜSSEN eine Kennung für die durch das Zertifikat bestätigte Rolle enthalten (ausgenommen die Rolle Versicherter ). gematik_pki_verwendung_zertifikate_der_ti.doc Seite 14 von 102

15 Quelle Verwendung von Zertifikaten in der Telematikinfrastruktur Anforderungsnummer Anforderungslevel AM A_00575 MUSS Im Protokolldatensatz MUSS ein eindeutiges Kennzeichen für die Institution aufgenommen werden. Die eindeutige Identifikation der Person ist NICHT notwendig. AM A_00875 MUSS Das Vertrauensmodell der PKI MUSS auf einer gematik Bridge CA, die als zentrale Instanz a- giert und auf die alle Zertifikate zurückführbar sein MÜSSEN, basieren. Die Verbindung zwischen weiteren Root CAs und der gematik Bridge CA MUSS durch Trust-service Status Lists (TSLs) hergestellt werden. AM A_00876 MUSS Die Verbindung zwischen weiteren Root CAs und der gematik Bridge CA MUSS durch Trusted-service Status Lists (TSLs) hergestellt werden, die durch die gematik signiert und herausgegeben werden MÜSSEN. Innerhalb der PKI MÜSSEN zwei getrennte TSLs existieren: die Infrastruktur TSL und die Personen TSL. AM A_00877 MUSS Die Infrastruktur-TSL (Trust-service Status List) MUSS alle CAs enthalten, die Service- und Netzzertifikate ausstellen dürfen. AM A_00881 MUSS Jede CA MUSS einen OCSP-Responder betreiben, über den die durch diese CA ausgestellten Zertifikate überprüft werden können. Aus Performanzgründen KÖNNEN zwei Optimierungen eingeführt werden: 1. Die spätere Einführung von CRLs bzw. Caching von OCSP-Anfragen. 2. Die maximalen Caching-Zeiten MÜSSEN bei der Verwendung von Caching vor dem Rollout festgelegt werden. AM A_01086 MUSS Nachrichtenkommunikation zwischen verschiedenen Anwendungsservices in der Telematik MUSS Authentifizierung, Autorisierung, Vertraulichkeit und Integritätsschutz über SSL/TLS unter Verwendung von X.509 Zertifikaten (für Clientund Serverauthentifizierung) implementieren. AM A_01110 MUSS Der Status von Zertifikaten der Telematikinfrastruktur MUSS immer über das Online Certificate Status Protocol (OCSP) erfolgen. AM A_01196 MUSS Der durch eine CA benannte OCSP-Responder MUSS Auskunft über den Status jedes Zertifikates dieser CA geben können. AM A_01197 MUSS Zum Widerrufen eines Zertifikates (revoke) MUSS dieses im Backendsystem der CA als gesperrt markiert werden und durch den OCSP Responder ab diesem Zeitpunkt als gesperrt gemeldet werden, um einzelne an der Telematik teilnehmende Identitäten (Personen, Institutionen oder Dienste/Geräte sowie Baugruppen) zu sperren. gematik_pki_verwendung_zertifikate_der_ti.doc Seite 15 von 102

16 Quelle Verwendung von Zertifikaten in der Telematikinfrastruktur Anforderungsnummer Anforderungslevel AM A_01706 SOLL Zur besseren Handhabbarkeit und für eine effiziente Umsetzung von Sicherheitsvorgaben SOLL die Rolle in den verschiedenen Zertifikaten einheitlich (d.h. z.b. gleiches Feld/Attribut, gleiches Encoding und Datenformat) kodiert werden. Anmerkung: Gemäß [gemspec_kon] werden die Anforderungsnummern in der Konnektorspezifikation evtl. noch geändert. gematik_pki_verwendung_zertifikate_der_ti.doc Seite 16 von 102

17 4 Gesamtüberblick der verwendeten Zertifikate Der Gesamtüberblick der verwendeten Zertifikate wird in der Gesamtarchitektur beschrieben. Für weitere Details wird hier auf den Anhang B der Gesamtarchitektur verwiesen [gemgesarch#anhang B]. gematik_pki_verwendung_zertifikate_der_ti.doc Seite 17 von 102

18 5 Standardvorgaben für Zertifikate Initial MUSS in das sich auf den Vertrauensraum stützende System das Root-Zertifikat der TSL sicher eingebracht werden, um den Vertrauensanker zu gewährleisten [gemsi- Ko#AnhC2.77]. Zur Unterscheidung von Zertifikatstypen und zur eindeutigen Ermittlung der Rolle enthalten alle Zertifikate in der Telematikinfrastruktur die Zertifikatserweiterungen "CertificatePolicies und "Admission. Die egk-zertifikate bilden hier jedoch als einzige eine Ausnahme. Da sie keine Rolle bestätigen entfällt die Erweiterung Admission in diesem Profil. 5.1 Angaben zum Zertifikatstyp in der Extension CertificatePolicies Die Extension MUSS neben den Referenzen auf die zugrunde liegenden Policies für die Zertifikate auch die Angaben zum Zertifikatstyp enthalten. Die Extension ist non-critical. ASN.1-Struktur nach [ISIS-MTT] (nur relevanter Teil): CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation PolicyInformation ::= SEQUENCE policyidentifier CertPolicyId, policyqualifiers SEQUENCE SIZE(1..MAX) OF PolicyQualifierInfo OPTIONAL CertPolicyId ::= OBJECT IDENTIFIER Es ist möglich mehrere Policies aufzunehmen. Wenn Anforderungen (z. B. Sicherheitsanforderungen) einer aufgeführten Policy durch eine andere aufgeführte Policy im selben Zertifikat vermindert werden, dann gelten stets die jeweiligen schärferen Anforderungen. Für die Angabe des Zertifikatstyps MUSS ein PolicyInformation eingefügt werdem, das die OID für den Zertifikatstyp als Wert des Unterelements policyidentifier enthält. Dieses PolicyInformation enthält kein Unterelement policy- Qualifier. Das vorliegende Dokument trifft nicht die Festlegungen zu den tatsächlich einzutragenden OIDs. Die normative Festlegung der OIDs trifft das Dokument [gemspec_oid]. 5.2 Admission Die Admission-Extension beinhaltet die Rolle der Identität sowohl als Text als auch in Form einer maschinenlesbarer OID. Vorgaben zum Format und in welchem Feld diese Angaben gespeichert werden, findet sich am Ende des Abschnitts im Bereich Belegte Felder und Formate. gematik_pki_verwendung_zertifikate_der_ti.doc Seite 18 von 102

19 Die genaue Festlegung der OID wird im Dokument [gemspec_oid] spezifiziert. ASN.1-Struktur nach [ISIS-MTT]: AdmissionSyntax ::= SEQUENCE admissionauthority GeneralName OPTIONAL, contentsofadmissions SEQUENCE OF Admissions Admissions ::= SEQUENCE admissionauthority [0] EXPLICIT GeneralName OPTIONAL, namingauthority [1] EXPLICIT NamingAuthority OPTIONAL, professioninfos SEQUENCE OF ProfessionInfo NamingAuthority ::= SEQUENCE namingauthorityid OBJECT IDENTIFIER OPTIONAL, namingauthorityurl IA5String OPTIONAL, namingauthoritytext DirectoryString (SIZE(1..128)) OPTIONAL ProfessionInfo ::= SEQUENCE namingauthority [0] EXPLICIT NamingAuthority OPTIONAL, professionitems SEQUENCE OF DirectoryString (SIZE(1..128)), professionoids SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, registrationnumber PrintableString (SIZE(1..128)) OPTIONAL, addprofessioninfo OCTET STRING OPTIONAL Belegte Felder und Formate: Art der Kennzeich-Ornung Bezeichnung Format Rolle Admission/ ProfessionItem Text ProfessionInfo ProfessionOID OID [ISO ] Entgegen der Optionalität aus [ISIS-MTT] MUSS das Feld ProfessionOID gefüllt werden. gematik_pki_verwendung_zertifikate_der_ti.doc Seite 19 von 102

20 6 Einordnung der Zertifikate innerhalb der Gesamtarchitektur Dieses Kapitel wird in einer späteren Version (nach R2.3.2) finalisiert(geplant für Release 3). Dieser Abschnitt definiert die kryptographischen Identitäten der Telematikinfrastruktur für die egk im deutschen Gesundheitswesen gemäß 291a (SGB V) und ihre Verteilung auf Bereiche und Schlüsselträger. Als kryptographische Identität wird dabei die Zusammenstellung privater Schlüssel und zugehöriger Zertifikate bezeichnet. Da hierbei der private Schlüssel inkludiert ist, kann eine Identität nur jeweils einmal bei ihrem Eigentümer vorhanden sein (der Fall des Klonens privater Schlüssel wird hierbei außer acht gelassen, spielt aber für die nachfolgenden Ausführungen keine Rolle). Die Nutzung der Zertifikate ist im Rahmen der Verteilung der Identitäten nicht modelliert. Die folgenden Identitäten auf Basis von X.509 Zertifikaten sind beschrieben: Abbildung 1: Beschriebene Typen der Zertifikate auf Basis von 509 Zertifikaten aus dem zentralen Repository der gematik gematik_pki_verwendung_zertifikate_der_ti.doc Seite 20 von 102

21 7 Einteilung der Zertifikate Dieses Kapitel wird in einer späteren Version finalisiert (geplant für Release 3). gematik_pki_verwendung_zertifikate_der_ti.doc Seite 21 von 102

22 8 Vertrauensraum Generell gilt für die Zertifikatsprüfung, dass zum einen das End-Entity-Zertifikat per OCSP, zum anderen das Aussteller-Zertifikat gegen die TSL auf Gültigkeit geprüft wird.. Die TSL hat dabei die Funktion eines gemeinsamen Vertrauensraums im Sinne einer White-List der zugelassenen Herausgeber. Um ein Aussteller-Zertifikat gegen die 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 Vertrauensraums in Form von Technischen Use Cases dargestellt. Die Schritte werden hier kurz aufgelistet: Download der TSL Prüfung der Aktualität und Validierung der TSL Prüfung des TSL-Signaturzertifikats gegen einen sicher verwahrten gematik- TSL-Root-Schlüssel Prüfung der Integrität der TSL durch Prüfung der Signatur der TSL gematik_pki_verwendung_zertifikate_der_ti.doc Seite 22 von 102

23 8.1 Prozesse zur Nutzung des Vertrauensraums Abbildung 2: Use Case Diagramm "Prozesse zur Nutzung des Vertrauensraums" 8.2 Initialisierung im Offline-Fall Im Offline-Fall werden Use Cases TUC_PKI_006 "OCSP-Abfrage" und TUC_PKI_005 "OCSP Adresse ermitteln" zur Zertifikatsprüfung nicht berücksichtigt. Jedoch DÜRFEN Komponenten, die nicht für den Offline-Fall vorgesehen sind, diese Einschränkung NICHT nutzen. Des Weiteren ist der Offline-Fall nur in bestimmten Umgebungen zulässig. Die Initialisierung bzw. die Prüfung des Signaturzertifikats einer TSL für den Offline-Fall muss näher beschrieben werden. Dies ist arbeitsgruppenübergreifend zu diskutieren und eine Spezifikation ist für Release 3 geplant. 8.3 Initialisierung ohne Vorbedingungen Einige TUCs im Prozess der Initialisierung des Vertrauensraums sind nur aufgrund bestimmter Vorbedingungen, wie TSL mit gültiger Signatur und TSL mit gültigem Zeitraum, durchführbar. Zum Zeitpunkt der Initialisierung eines Systems können diese Vor- gematik_pki_verwendung_zertifikate_der_ti.doc Seite 23 von 102