D-TRUST Telematik-Infrastruktur Certification Practice Statement Version 1.0 Erscheinungsdatum 01.05.2015 Datum des Inkrafttretens 01.05.2015
Vermerk zum Copyright D-TRUST Telematik-Infrastructure Certification Practice Statement 2015 D-TRUST GMBH, alle Rechte vorbehalten. Ohne Einschränkung der vorstehenden vorbehaltenen Rechte und über den im Folgenden gestatteten Rahmen hinaus darf kein Teil dieser Veröffentlichung auf irgend eine Weise oder mittels irgend eines Verfahrens (elektronisch, mechanisch, durch Fotokopie, Aufzeichnung oder auf sonstige Weise) ohne vorherige schriftliche Zustimmung der D-TRUST GMBH reproduziert, gespeichert oder in ein Speichersystem geladen oder übertragen werden. Unbeschadet des Voranstehenden ist es gestattet, dieses CPS auf nicht-exklusiver, gebührenfreier Basis zu reproduzieren und zu verteilen, sofern (i) der vorstehende Copyright-Vermerk und die einleitenden Absätze an deutlicher Stelle zu Beginn jeder Kopie erscheinen und (ii) dieses Dokument wortgetreu und vollständig wiedergegeben wird, beginnend mit der Nennung der D-TRUST GMBH als Verfasser des Dokuments. Anträge auf jede sonstige Genehmigung zur Reproduktion oder anderweitige Verwendung dieses CPS der D-TRUST GMBH sind zu richten an: D-TRUST GMBH Kommandantenstr. 15 10969 Berlin, Germany Tel: +49 (0)30 259391 0 E-Mail: info@d-trust.net
Dokumentenhistorie Version Datum Beschreibung 1.0 01.05.2015 Initialversion
Inhaltsverzeichnis 1. Einleitung... 5 1.1 Überblick... 5 1.2 Name und Kennzeichnung des Dokuments... 6 1.3 Teilnehmer der Zertifizierungsinfrastruktur... 6 1.4 Verwendung von Zertifikaten... 7 1.5 Pflege der CP/des CPS... 7 1.6 Begriffe und Abkürzungen... 7 2. Verantwortlichkeit für Verzeichnisse und Veröffentlichungen... 8 2.1 Verzeichnisse... 8 2.2 Veröffentlichung von Informationen zu Zertifikaten... 8 2.3 Häufigkeit von Veröffentlichungen... 8 2.4 Zugriffskontrollen auf Verzeichnisse... 8 3. Identifizierung und Authentifizierung... 9 3.1 Namensregeln... 9 3.2 Initiale Überprüfung der Identität... 14 3.3 Identifizierung und Authentifizierung von Anträgen auf Schlüsselerneuerung... 15 3.4 Identifizierung und Authentifizierung von Sperranträgen... 16 4. Betriebsanforderungen... 17 4.1 Zertifikatsantrag und Registrierung... 17 4.2 Verarbeitung des Zertifikatsantrags... 17 4.3 Ausstellung von Zertifikaten... 18 4.4 Zertifikatsübergabe... 18 4.5 Verwendung des Schlüsselpaars und des Zertifikats... 19 4.6 Zertifikatserneuerung (certificate renewal)... 19 4.7 Zertifikatserneuerung mit Schlüsselerneuerung... 20 4.8 Zertifikatsänderung... 21 4.9 Sperrung und Suspendierung von Zertifikaten... 21 4.10 Statusabfragedienst für Zertifikate... 23 4.11 Austritt aus dem Zertifizierungsdienst... 23 4.12 Schlüsselhinterlegung und wiederherstellung... 23 5. Nicht-technische Sicherheitsmaßnahmen... 24 5.1 Bauliche Sicherheitsmaßnahmen... 24 5.2 Verfahrensvorschriften... 24 5.3 Eingesetztes Personal... 25 5.4 Überwachungsmaßnahmen... 26 5.5 Archivierung von Aufzeichnungen... 27 5.6 Schlüsselwechsel beim TSP... 28 5.7 Kompromittierung und Geschäftsweiterführung beim TSP... 28 5.8 Schließung des TSP... 29 6. Technische Sicherheitsmaßnahmen... 30 6.1 Erzeugung und Installation von Schlüsselpaaren... 30 6.2 Sicherung des privaten Schlüssels und krytographische Module... 31 6.3 Andere Aspekte des Managements von Schlüsselpaaren... 33 6.4 Aktivierungsdaten... 33 6.5 Sicherheitsmaßnahmen in den Rechneranlagen... 34 6.6 Technische Maßnahmen während des Life Cycles... 35 6.7 Sicherheitsmaßnahmen für Netze... 36 6.8 Zeitstempel... 36 Seite 3 von 42
7. Profile von Zertifikaten, Sperrlisten und OCSP... 37 7.1 Zertifikatsprofile X.509-nonQES-Zertifikate für HBA und SMB-C... 37 7.2 Sperrlistenprofile... 41 7.3 Profile des Statusabfragedienstes (OCSP)... 41 8. Überprüfungen und andere Bewertungen... 42 9. Sonstige finanzielle und rechtliche Regelungen... 43 Seite 4 von 42
1. Einleitung 1.1 Überblick Dieses Dokument ist das Certification Practice Statement (CPS) des von der D-TRUST GMBH betriebenen TSP der Telematikinfrastrukur für Zertifikate des HBA und der SMC-B. 1.1.1 Vertrauensdiensteanbieter 1.1.2 Über dieses Dokument Dieses CPS definiert Abläufe und Vorgehensweisen des von der D-TRUST GMBH betriebenen TSP im Umfeld der telematik Infrastruktur während der gesamten Lebensdauer der Zertifikate von HBA und SMB-C. Es werden Mindestmaßnahmen konstatiert, die von allen Teilnehmern der Zertifizierungsinfrastruktur zu erfüllen sind. In den ausgestellten Zertifikaten des TSP können CPs referenziert werden, die detailliert Anforderungen und Beschränkungen definieren. Zu diesen CPs gehören Certificate Policy Gemeinsame Zertifizierungsrichtlinie für Teilnehmer der gematik-tsl (s. [gemrl_tsl_tsp_cp]), Certificate Policy Gemeinsame Zertifizierungsrichtlinie für Teilnehmer der gematik-tsl - Sektorspezifische Präzisierung für SMC-B-Zertifikate in Erprobungsphase ORS1 (s. [gemrl_smc-b_ors1]), Gemeinsame Policy für die Ausgabe der HPC Zertifikatsrichtlinie HPC (s. [CP-HPC]), ZOD 2.0 - Certificate Policy (s. [ZODPol]) und CPME European eid-policy for Physicians" Version 1.0.0 (s. [CPME]) Diese Policy beschreibt auch die Mindest-Anforderungen an das qualifizierte Zertifikat eines HBA. Aufgrund von SigG und SigV sind durch den Zertifizierungsdiensteanbieter umfangreiche weitere Anforderungen hinsichtlich des Betriebs, der Identifizierung, der Validierung und Archivierung umzusetzen. Die gesetzeskonforme Umsetzung dieser Vorgaben wird in einem Sicherheitskonzept der D- TRUST GmbH beschrieben und im Rahmen des Akkreditierungsverfahrens durch anerkannte Prüf- und Bestätigungstellen geprüft. Das Sicherheitskonzept ist nicht öffentlich zugänglich. Berechtigte Anfragen dazu können über die Kontaktadresse (s. [CP#1.1.1]) gestellt werden. Seite 5 von 42
Die für die Zertifikatsnutzer relevanten Informationen werden in der Unterrichtung nach 6 SigG und auf den Webseiten der Herausgeber des HBA (Bundesärztekammer) bereitgestellt. Die Struktur dieses Dokumentes ist eng an den Internet-Standard RFC 3647 Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework angelehnt, um eine einfache Lesbarkeit und Vergleichbarkeit mit anderen CPSs zu erreichen. Das CPS erläutert bzw. erweitert die in der zugehörigen CP beschriebenen Verfahren, bei identischen Formulierungen werden Referenzen auf die CP eingesetzt. Werden Anforderungen an den TSP-X.509QES und TSP-X.509nonQES bzw. an TSP-X.509QES-Zertifikate und TSP-X.509nonQES-Zertifikate gleichermaßen gestellt, wird in diesem Dokument nur vom TSP bzw. von Zertifikaten gesprochen. 1.1.3 Eigenschaften der Zertifizierungsinfrastruktur 1.2 Name und Kennzeichnung des Dokuments Dokumentname: D-TRUST Telematik-Infrastruktur Certification Practice Statement Version 1.0 1.3 Teilnehmer der Zertifizierungsinfrastruktur 1.3.1 Zertifizierungsstellen (CA) 1.3.2 Registrierungsstellen (RA) 1.3.3 Antragsteller 1.3.4 Zertifikatnehmer (Anwender, Subscribers) Seite 6 von 42
1.3.5 Zertifikatsnutzer (Zertifikatsprüfer, Überprüfer, Relying Parties) 1.3.6 Sperrberechtigter Ein Sperrberechtigter ist eine natürliche oder juristische Person, die zur Sperrung eines Zertifikates berechtigt ist. 1.4 Verwendung von Zertifikaten 1.4.1 Erlaubte Verwendungen von Zertifikaten 1.4.2 Verbotene Verwendungen von Zertifikaten 1.5 Pflege der CP/des CPS 1.5.1 Zuständigkeit für das Dokument Dieses CPS wird durch die D-TRUST GMBH gepflegt. Der Leiter des TSP übernimmt die Abnahme des Dokuments. 1.5.2 Ansprechpartner/Kontaktperson/Sekretariat 1.6 Begriffe und Abkürzungen 1.6.1 Deutsche Begriffe und Namen 1.6.2 Englische Begriffe 1.6.3 Abkürzungen 1.6.4 Referenzen Seite 7 von 42
2. Verantwortlichkeit für Verzeichnisse und Veröffentlichungen 2.1 Verzeichnisse 2.2 Veröffentlichung von Informationen zu Zertifikaten Der TSP veröffentlicht folgende Informationen: Vom TSP ausgestellte Endanwender-Zertifikate, sofern dieses vom Zertifikatnehmer aus-drücklich gefordert wurde, CA-Zertifikate (von HBA-CA und SMCB-CA) als Trust-Anchor, Sperrlisten (CRLs) und Statusinformationen für vom TSP ausgestellte Zertifikate, die CP, dieses CPS. 2.3 Häufigkeit von Veröffentlichungen Zertifikate können veröffentlicht, d.h. in das öffentliche Verzeichnis des TSP aufgenommen werden. Veröffentlichte Zertifikate bleiben bis zum Ende ihrer Gültigkeit sowie mindestens für fünf weitere Jahre und bis zum jeweiligen Jahresende abrufbar. Die CA-Zertifikate (von HBA-CA und SMCB-CA) werden nach ihrer Erstellung veröffentlicht und mindestens fünf Jahre und bis zum Jahresende nach Ablauf der Gültigkeit der CA vorgehalten. Sperrlisten werden regelmäßig und bis zum Ende der Gültigkeit des ausstellenden CA-Zertifikats ausgestellt. Sperrlisten werden unmittelbar nach Sperrungen erstellt und veröffentlicht. Auch wenn keine Sperrungen erfolgen, stellt der TSP sicher, das mindestens alle 24 Std. eine neue Sperrliste ausgestellt wird. Die Sperrlisten werden mindestens ein Jahr nach Ablauf der Gültigkeit der CA vorgehalten. Die CP und das CPS werden wie unter Abschnitt 2.1 genannt veröffentlicht und bleiben dort mindestens so lange abrufbar, wie Zertifikate, die auf Basis dieser CP ausgestellt wurden, gültig sind. Die Webseiten sind hochverfügbar. 2.4 Zugriffskontrollen auf Verzeichnisse Seite 8 von 42
3. Identifizierung und Authentifizierung 3.1 Namensregeln 3.1.1 Arten von Namen 3.1.2 Notwendigkeit für aussagefähige Namen 3.1.3 Anonymität oder Pseudonyme von Zertifikatnehmern 3.1.4 Regeln für die Interpretation verschiedener Namensformen Die Abbildung einer realen Identität (Person, Dienst, Institution) (eines Zertifikatsnehmers) in ein Zertifikat erfolgt durch den Inhalt der Felder SubjectDN (subject distinguishedname). Dabei werden die übergreifenden Kodierungsvorschriften aus [gemspec_pki#4] umgesetzt. Insbesondere wird für die einzelnen Felder ein Zeichensatz gemäß [Common-PKI#Part1] und speziell eine UTF8- Kodierung eingesetzt. Somit können Sonderzeichen und Umlaute verwendet werden (s. [gemspec_pki#4.1.1]). Die Vorgaben für den Inhalt der Felder SubjectDN der Zertifikate für den HBA sind in den folgenden Dokumenten beschrieben: Zertifikatsprofile für X.509 Basiszertifikate der Ärzte [baekcerts] Zertifikatsprofil des elektronischen Zahnarztausweises [bzaekcert] Zertifikatsprofile für X.509 Attributzertifikate [baekattr] Gemeinsame Policy für die Herausgabe der HPC [CP-HPC] Die Vorgaben für den Inhalt der Felder SubjectDN der X.509-nonQES Zertifikate für die SMC-B werden in [gemspec_pki#5.3] definiert. SubjectDN Felder für Zertifikate für den HBA Folgende Felder SubjectDN Felder werden für Zertifikate für den HBA verwendet: countryname serialnumber Seite 9 von 42
surname givenname (derzeit nicht zulässig, RFU): title commonname Der commonname enthält den vollständigen Namen des Zertifikatnehmers, ohne akademische Titel (auch wenn sie im Personalausweis des Antragstellers eingetragen sind). Die Länge des Attributes ist auf 64 Zeichen beschränkt. Falls der vollständige Name nicht aufgenommen werden kann (z. B. weil er zu lang ist), dann muss, nur dann wenn dies aus gesetzlichen Bestimmungen hervorgeht, der commonname als Pseudonym gekennzeichnet werden. In diesem Fall wird der Zusatz :PN (ohne Anführungsstrichen) aufgenommen; die effektive Länge reduziert sich damit auf 61 Zeichen. Falls eine Kürzung vorgenommen werden soll, entsprechen die Kürzungsregeln den Regelungen in der egk-spezifikation: erster "Givenname" und Surname bleiben vollständig, sonstige Vornamen werden auf den ersten Buchstaben plus Punktzeichen gekürzt, falls immer noch >61 bzw. 64 Zeichen: sonstige Vornamen werden gestrichen, falls immer noch >61 bzw. 64 Zeichen: der Nachname wird gekürzt und mit Punktzeichen gekennzeichnet, so dass die Gesamtlänge (ggf. inkl. :PN) 64 Zeichen beträgt Der surname enthält (zusätzlich zum commonname) den Nachnamen des Inhabers. Evtl. vorhandene Namensbestandteile wie Graf von, jr., so genannte generation qualifier (üblich im amerikanischen Sprachraum, z.b. III ) usw. werden im surname aufgenommen, wenn sie im Reisepass oder Personalausweis als Teile des Nachnamens betrachtet werden. Ggf. im Personalausweis aufgenommene akademische Titel (DR) werden nicht im surname aufgenommen. Das Attribut givenname enthält (zusätzlich zum commonname) alle Vornamen des Zertifikatnehmers. Um eine Unterscheidung bei Namensgleichheit zu gewährleisten, wird das Feld serialnumber verwendet. Um unterschiedliche Namen im globalen LDAP-Tree über alle TSP zu erreichen, sind zweistellige Prefixe definiert und den TSP zugewiesen. Das serialnumber-feld aller Zertifikate für HBAs, die durch den von der D-TRUST GMBH betriebenen TSP ausgestellt werden, beginnt mit dem zugewiesenen Prefix 10 (ohne Anführungszeichen). Alle Zertifikate eines HBA erhalten die gleiche Nummer im serialnumber-feld wie das Zertifikat für qualifizierte Signaturen dieses HBA. Seite 10 von 42
Das Attribut countryname enthält den ISO-3166 Code des Landes, also DE, kodiert als printablestring. Die Felder serialnumber, givenname, surname, ggf. title und commonname werden in einem SET als ein einziges multivaluedrdn kodiert. Die entsprechenden Kodierungsregeln von X.690 (Reihenfolge im SET) werden dabei berücksichtigt. Die Reihenfolge der RelativeDistinguishedNames in der RDNSequence ist: country,(givenname+surname+title+serialnumber+commonname) SubjectDN Felder werden für X.509-nonQES Zertifikate für die SMC-B Folgende Felder SubjectDN werden für alle X.509-nonQES Zertifikate (Sektorübergreifend) für die SMC-B verwendet: countryname serialnumber Der eindeutige Identitätsschlüssel der Organisation oder Einrichtung des Gesundheitswesens wird durch die Telematik-ID in der Zertifikatserweiterung Admission abgebildet. Die serialnumber wird als technisches Unterscheidungsmerkmal mit den 10 letzten Ziffern der ICC Serial Number (Chipkarten-Seriennummer) der SMC-B belegt. Das Attribut countryname enthält den ISO-3166 Code des Landes, also DE, kodiert als printablestring. Sektorspezifisch (KZBV, KV, DKTIG) werden folgende Felder SubjectDN für X.509-nonQES Zertifikate für die SMC-B belegt: commonname o KZBV o KV Gemäß Freigabedaten der zuständigen KZV Der commonname beinhaltet den Kurzname der Institution, so wie er sich selbst nach [DIN5008] auf dem Anschriftenfeld findet. (Zeilen 1-2, ggf +3-4). Überlange Attribute des SubjectDN werden zusätzlich in der Extension SubjectAltNames in voller Länge abgebildet. Seite 11 von 42
o DKTIG organizationname o KZBV o KV o DKTIG streetadress o KZBV o KV o DKTIG postalcode o KZBV o KV Der commonname beinhaltet den Kurzname der Institution, so wie er sich selbst nach [DIN5008] auf dem Anschriftenfeld findet. (Zeilen 1-2, ggf +3-4). Überlange Attribute des SubjectDN werden zusätzlich in der Extension SubjectAltNames in voller Länge abgebildet. Gemäss Freigabedaten der DKTIG Gemäß Freigabedaten der zuständigen KZV (Telematik-ID) 9-stellige Betriebsstättennummer (z.b. 121234512 ) der Praxis als eindeutige Nummer. Für privat abrechnende Ärzte wird hier eine 10-stellige Ersatznummer eingefügt. Kein Wert Kein Wert Strasse, Hausnummer der Anschrift Strassen-Anschrift der Institution (mehrere Wörter sind durch Blank getrennt) Kein Wert Seite 12 von 42
o DKTIG localityname o KZBV o KV o DKTIG Postleitzahl der Anschrift Postleitzahl des Ortes der Institution (Deutsche PLZ werden 5-stellig abgebildet) Kein Wert stateorprovincename title o KZBV o KV o DKTIG o KZBV o KV o DKTIG surname Stadt des Standortes Stadt des Institut-Standortes Kein Wert Bundesland des Standortes Bundesland des Institutstandorts Kein Wert Titel des Verantwortlichen/Inhabers Titel des Verantwortlichen/Inhabers Seite 13 von 42
o KZBV o KV o DKTIG givenname o KZBV o KV o DKTIG Kein Wert Nachname des Verantwortlichen/Inhabers Nachname des Verantwortlichen/Inhabers Kein Wert 3.1.5 Eindeutigkeit von Namen Vorname des Verantwortlichen/Inhabers Vorname des Verantwortlichen/Inhabers 3.1.6 Anerkennung, Authentifizierung und die Rolle von Markennamen 3.2 Initiale Überprüfung der Identität 3.2.1 Nachweis für den Besitz des privaten Schlüssels Es werden zwei Fälle unterschieden: 1. Schlüsselpaare von Zertifikatnehmern werden im Verantwortungsbereich des TSP produziert. Mit der Übergabe der Token oder Soft-PSE (LCP) und ggf. PIN- Briefe gemäß Abschnitt 4.4.1 an die Zertifikatnehmer durch den TSP wird sichergestellt, dass die privaten Schlüssel in den Besitz der Zertifikatnehmer gelangen. 2. Schlüsselpaare werden im Verantwortungsbereich des Zertifikatnehmers produziert. Der Besitz des privaten Schlüssels muss entweder technisch nachgewiesen werden oder vom Zertifikatnehmer nachvollziehbar bestätigt werden. Mit der Übersendung eines PKCS#10-Requests an den TSP bestätigt der Zertifikatnehmer verbindlich im Besitz des privaten Schlüssels zu sein. Seite 14 von 42
3.2.2 Identifizierung und Authentifizierung von Organisationen Organisationen, die entweder in einem Zertifikat genannt werden oder in deren Namen Zertifikate ausgestellt werden, müssen sich eindeutig authentisieren. Die vorgestellten Prüfverfahren werden wie folgt auf die DN-Bestandteile nach Abschnitt 3.1.4 und ggf. weitere Attribute angewendet. Die angegebenen Verfahren sind in Abschnitt 4.2.1 beschrieben. Nachweise in nicht lateinischer Schrift werden nicht akzeptiert. 3.2.3 Identifizierung und Authentifizierung natürlicher Personen Natürliche Personen, die Zertifikate beantragen, müssen sich eindeutig authentisieren und ggf. ihre Berechtigung zur Antragstellung durch die Organisation nachweisen. Die Prüfung der Identität des Antragstellers erfolgt mit den Verfahren ZDA-Ident/Postident Basic bzw. KammerIdent mit Hilfe der jeweiligen Kammer oder direkt beim ZDA. Nachweise in nicht lateinischer Schrift werden nicht akzeptiert. 3.2.4 Ungeprüfte Angaben zum Zertifikatnehmer 3.2.5 Prüfung der Berechtigung zur Antragstellung Im Rahmen der Antragstellung wird die Prüfung der Berechtigung des Antragstellers auf einen HBA bzw. eine SMC-B durchgeführt. Dabei werden Identitätsnachweis und Kammerzugehörigkeit geprüft bzw. bestätigt. 3.2.6 Kriterien für die Interoperabilität 3.3 Identifizierung und Authentifizierung von Anträgen auf Schlüsselerneuerung 3.3.1 Routinemäßige Anträge zur Schlüsselerneuerung 3.3.2 Schlüsselerneuerung nach Sperrungen Seite 15 von 42
3.4 Identifizierung und Authentifizierung von Sperranträgen Die Sperrberechtigung wird wie folgt geprüft: Bei einem Sperrantrag mit handschriftlich unterschriebener Briefpost muss aus dem Unterschriftenvergleich erkennbar sein, dass der die Sperrung Beantragende entweder der Zertifikatnehmer selbst oder ein Sperrberechtigter Dritter ist. Bei telefonischem Sperrantrag muss der Sperrberechtigte das entsprechende Sperrpasswort korrekt nennen. Bei einer Sperrung über E-Mail, das Freigabeportal, die SOAP-Schnittstelle oder das Praxisregister muss der Antrag qualifiziert signiert sein. Die Gültigkeit der Signatur wird zur Authentifzierung geprüft. Sperrverfahren werden in Abschnitt 4.9 definiert. Seite 16 von 42
4. Betriebsanforderungen 4.1 Zertifikatsantrag und Registrierung 4.1.1 Berechtigung zur Antragstellung 4.1.2 Registrierungsprozess und Zuständigkeiten Dem Zertifikatnehmer (Antragsteller für einen HBA oder eine SMB-C) liegen vor Beginn des Registrierungsprozesses CP, CPS sowie Unterrichtungsunterlagen vor, zu deren Einhaltung sich der Zertifikatnehmer verpflichtet. Die Dokumente werden veröffentlicht. Der Antrag beinhaltet weiterhin die Einverständniserklärung des Zertifikatnehmers zur Veröffentlichung entsprechender Zertifikate. Nachweise werden elektronisch oder papierbasiert hinterlegt. 4.2 Verarbeitung des Zertifikatsantrags 4.2.1 Durchführung der Identifizierung und Authentifizierung Der beschriebene Identifizierungs- und Registrierungsprozess muss vollständig durchlaufen und alle nötigen Nachweise dabei erbracht werden. Der TSP folgt dabei hier den Prüfverfahren für die Beantragung qualifizierter Zertifikate für den HBA: ZDA-Ident / Postident Basic Die natürliche Person muss sich gegenüber einer RA oder einem zugelassenem Partner (im Fall von Postident Mitarbeiter der Filiale der DPAG) oder einem externen Anbieter, der die Maßgaben der CP erfüllt, anhand eines gültigen amtlichen Ausweises persönlich authentifizieren. Zulässige Dokumente sind Personalausweis oder Reisepass bei Staatsangehörigkeit eines Mitgliedstaates der Europäischen Union oder eines Staates des Europäischen Wirtschaftsraumes, oder Dokumenten mit gleichwertiger Sicherheit. Nachweise werden hinterlegt. Die Bestätigung der Berufsgruppe erfolgt über das Freigabeportal KammerIdent Mit einem ausgedruckten Antrag begibt sich der Antragssteller zu der ihm zugeordneten Kammer (Kartenherausgeber). Dort führt der dortige Identifikationsmitarbeiter eine Identifizierung anhand des Personalausweises durch. Bei einer erfolgreichen Identifikation bestätigt der Identifikationsmitarbeiter die korrekten Antragsdaten. Identifizierung und Authentifizierung finden gemäß den Abschnitten 3.2.2 und 3.2.3 CP statt. Seite 17 von 42
4.2.2 Annahme oder Ablehnung von Zertifikatsanträgen Eine vom TSP beauftragte "unabhängige zweite" Person der laut Sicherheitskonzept entsprechenden Rolle prüft die Antragsunterlagen nach folgenden Kriterien: wurde die Authentifizierung des Zertifikatnehmers korrekt durchlaufen und dokumentiert, wurden alle notwendigen Nachweise erbracht, liegen Gründe vor, die eine Ablehnung des Antrags nahe legen. Mögliche Ablehnungsgründe sind in der CP festgehalten. Treten bei der Prüfung der Identität oder der Prüfung auf Korrektheit der Daten im Zertifikatsantrag oder den Ausweis- und Nachweisdokumenten Unstimmigkeiten auf, die der Zertifikatnehmer nicht zeitnah und restlos ausräumt, wird der Antrag abgelehnt. 4.2.3 Fristen für die Bearbeitung von Zertifikatsanträgen Richt relevant. 4.3 Ausstellung von Zertifikaten 4.3.1 Vorgehen des TSP bei der Ausstellung von Zertifikaten Im Hochsicherheitsbereich des Trustcenters der D-Trust GmbH werden die entsprechenden Zertifikate ausgefertigt. Dabei wird sichergestellt, dass bei der Zertifikatserstellung die korrekte Zeit verwendet wird. Die vollständige Antragsdokumentation wird entweder vom TSP gemäß Abschnitt 5.5 revisionssicher abgelegt oder der TSP schließt vertragliche Vereinbarungen mit Partnern, dass die Antragsunterlagen und/oder Requests sicher und vollständig bis zum Ablauf der Frist nach Abschnitt 5.5.2 zu verwahren sind. 4.3.2 Benachrichtigung des Zertifikatnehmers über die Ausstellung des Zertifikats 4.4 Zertifikatsübergabe 4.4.1 Verhalten bei der Zertifikatsübergabe Seite 18 von 42
4.4.2 Veröffentlichung des Zertifikats durch den TSP 4.4.3 Benachrichtigung anderer PKI-Teilnehmer über die Ausgabe des Zertifikats 4.5 Verwendung des Schlüsselpaars und des Zertifikats 4.5.1 Verwendung des privaten Schlüssels und des Zertifikats durch den Zertifikatnehmer 4.5.2 Verwendung des öffentlichen Schlüssels und des Zertifikats durch Zertifikatsnutzer 4.6 Zertifikatserneuerung (certificate renewal) 4.6.1 Bedingungen für eine Zertifikatserneuerung Haben sich grundsätzliche Änderungen an den Nutzungsbedingungen ergeben, wird der Zertifikatnehmer darüber informiert. Der Zertifikatnehmer bestätigt die neuen Bedingungen. Detaillierte Regelungen sind in der CP festgehalten. 4.6.2 Berechtigung zur Zertifikatserneuerung 4.6.3 Bearbeitung eines Antrags auf Zertifikatserneuerung 4.6.4 Benachrichtigung des Zertifikatnehmers über die Ausgabe eines neuen Zertifikats Es gelten die in Abschnitt 4.3.2 festgelegten Regelungen. 4.6.5 Verhalten bei der Ausgabe einer Zertifikatserneuerung Seite 19 von 42
4.6.6 Veröffentlichung der Zertifikatserneuerung durch den TSP 4.6.7 Benachrichtigung anderer PKI-Teilnehmer über die Erneuerung des Zertifikats 4.7 Zertifikatserneuerung mit Schlüsselerneuerung 4.7.1 Bedingungen für Zertifikate mit Schlüsselerneuerung Haben sich grundsätzliche Änderungen an den Nutzungsbedingungen ergeben, wird der Zertifikatnehmer darüber informiert. Der Zertifikatnehmer bestätigt die neuen Bedingungen. Die weiteren Regelungen sind in der CP festgehalten. 4.7.2 Berechtigung zur Schlüsselerneuerung 4.7.3 Bearbeitung von Zertifikatsanträgen für Schlüsselerneuerungen Ein Antrag auf eine Zertifikatserneuerung entspricht einer Sperrung der entsprechenden Karte (HBA oder SMB-C) und eines Antrags auf eine neue Karte. 4.7.4 Benachrichtigung des Zertifikatnehmers über die Ausgabe eines Nachfolgezertifikats 4.7.5 Verhalten für die Ausgabe von Zertifikaten nach Schlüsselerneuerungen 4.7.6 Veröffentlichung von Zertifikaten nach Schlüsselerneuerungen durch den TSP-X.509 nonqes 4.7.7 Benachrichtigung anderer PKI-Teilnehmer über die Ausgabe eines Nachfolgezertifikats Seite 20 von 42
4.8 Zertifikatsänderung Zertifikatsänderungen werden nicht angeboten. 4.9 Sperrung und Suspendierung von Zertifikaten 4.9.1 Bedingungen für eine Sperrung Die Sperrung eines Zertifikats wird bei folgenden Ereignissen durchgeführt: auf Verlangen des Zertifikatnehmers bzw. eines berechtigten Sperrantragstellers, Ungültigkeit von Angaben im Zertifikat, wenn der TSP seine Tätigkeit beendet und diese nicht von einem anderen TSP fortgeführt wird, Unabhängig davon kann der TSP Sperrungen veranlassen, wenn: der private Schlüssel der ausstellenden oder einer übergeordneten CA kompromittiert wurde, das Schlüsselpaar sich auf einer Karte (HBA oder SMB-C) befindet, auf der gleichzeitig ein Schlüsselpaar liegt, das zu einem (qualifizierten) Zertifikat gehört, welches gesperrt wird, Schwächen im verwendeten Kryptoalgorithmus bekannt werden, die ernste Risiken für die erlaubten Anwendungen während der Zertifikatslaufzeit darstellen, die eingesetzte Hard- und Software Sicherheitsmängel aufweist, die ernste Risiken für die erlaubten Anwendungen während der Zertifikatslaufzeit darstellen, die eindeutige Zuordnung des Schlüsselpaars zum Zertifikatnehmer nicht mehr gegeben ist, ein Zertifikat aufgrund falscher Angaben erwirkt wurde, der Kunde nach zweimaliger Mahnung mit dem Entgelt in Verzug ist, das Vertragsverhältnis gekündigt oder in sonstiger Weise beendet wurde. Sperrungen enthalten eine Angabe des Zeitpunkts der Sperrung und werden nicht rückwirkend erstellt. Sperrberechtigte müssen sich gemäß Abschnitt 3.4 authentifizieren. Seite 21 von 42
4.9.2 Berechtigung zur Sperrung 4.9.3 Verfahren für einen Sperrantrag 4.9.4 Fristen für einen Sperrantrag 4.9.5 Zeitspanne für die Bearbeitung des Sperrantrags durch den TSP 4.9.6 Verfügbare Methoden zum Prüfen von Sperrinformationen 4.9.7 Häufigkeit der Veröffentlichung von Sperrlisten 4.9.8 Maximale Latenzzeit für Sperrlisten 4.9.9 Online-Verfügbarkeit von Sperrinformationen 4.9.10 Notwendigkeit zur Online-Prüfung von Sperrinformationen 4.9.11 Andere Formen zur Anzeige von Sperrinformationen 4.9.12 Spezielle Anforderungen bei Kompromittierung des privaten Schlüssels 4.9.13 Bedingungen für eine Suspendierung Seite 22 von 42
4.10 Statusabfragedienst für Zertifikate 4.10.1 Funktionsweise des Statusabfragedienstes Der Statusabfragedienst ist über das Protokoll OCSP verfügbar. Die Erreichbarkeit des Dienstes wird als URL in den Zertifikaten angegeben. Die Formate und Protokolle der Dienste sind in den Abschnitten 7.2 und 7.3 beschrieben. 4.10.2 Verfügbarkeit des Statusabfragedienstes 4.10.3 Optionale Leistungen Keine. 4.11 Austritt aus dem Zertifizierungsdienst Die Gültigkeit eines Zertifikats endet mit dem im Zertifikat vermerkten Termin. 4.12 Schlüsselhinterlegung und wiederherstellung 4.12.1 Bedingungen / Verfahren für die Hinterlegung und Wiederherstellung privater Schlüssel 4.12.2 Bedingungen / Verfahren für die Hinterlegung und Wiederherstellung von Sitzungsschlüsseln Seite 23 von 42
5. Nicht-technische Sicherheitsmaßnahmen Die Beschreibungen dieses Kapitels beziehen sich auf die HBA- und SMC-B-CA, die bei der D-TRUST GMBH betrieben werden. 5.1 Bauliche Sicherheitsmaßnahmen Die D-TRUST GMBH ist akkreditierter Zertifizierungsdiensteanbieter nach deutschem Signaturgesetz. Für die baulichen Sicherheitsmaßnahmen liegt eine detaillierte Dokumentation vor (Sicherheitskonzept des signaturgesetzkonformen Zertifizierungsdiensteanbieters [SiKo-DTR]), die bei begründetem Interesse in den relevanten Teilen eingesehen werden kann. Das Sicherheitskonzept wurde durch eine von der Bundesnetzagentur anerkannte Prüf- und Bestätigungsstelle geprüft. Die Prüfung und Bestätigung wird nach sicherheitserheblichen Veränderungen sowie in regelmäßigen Zeitabständen wiederholt. Teil des Sicherheitskonzepts ist eine detaillierte Dokumentation der baulichen Sicherheits- und Überwachungsmaßnahmen, die im Einzelfall und bei begründetem Interesse in den relevanten Teilen eingesehen werden kann. Ferner wurde dem Sicherheitsbereich des Trustcenters der D-TRUST GMBH durch den TÜV-IT die Anwendung und Umsetzung der Infrastrukturmaßnahmen für hohen Schutzbedarf Level 3 beurkundet (gemäß Prüfkriterienkatalog für Trusted Site Infrastructure ). Mit diesem TÜV-IT-Zertifikat Trusted Site Infrastructure werden alle Infrastruktur-relevanten Aspekte untersucht und bewertet. Diese Prüfung wird alle zwei Jahre wiederholt. Die genannten Zertifikate bestätigen der D-TRUST GMBH diesen hohen Sicherheitsstandard der nicht-technischen Sicherheitsmaßnahmen. Die CAs der hier behandelten Zertifizierungsinfrastruktur werden vom TSP unter den gleichen Bedingungen betrieben wie die CAs der D-TRUST GMBH zur Ausstellung qualifizierter Zertifikate mit Anbieterakkreditierung nach deutschem Signaturgesetz. 5.2 Verfahrensvorschriften 5.2.1 Rollenkonzept Teil des Sicherheitskonzeptes ist ein Rollenkonzept [Siko-DTR], in dem Mitarbeiter einer oder mehreren Rollen zugeordnet werden und entsprechende Berechtigungen erhalten. Die Berechtigungen der einzelnen Rollen beschränken sich auf diejenigen, die sie zur Erfüllung ihrer Aufgaben benötigen. Die Zuordnung der Berechtigungen wird regelmäßig revisioniert und umgehend nach Entfall des Bedarfs entzogen. Mitarbeiter, die im Bereich der Zertifizierungs- und Sperrdienste tätig sind, agieren unabhängig und sind frei von kommerziellen/finanziellen Zwängen, die ihre Seite 24 von 42
Entscheidungen und Handlungen beeinflussen könnten. Die organisatorische Struktur des TSP berücksichtigt und unterstützt die Mitarbeiter in der Unabhängigkeit ihrer Entscheidungen. Die Identität, Zuverlässigkeit und Fachkunde des Personals wird vor Aufnahme der Tätigkeit überprüft. Regelmäßige und anlassbezogene Schulungen gewährleisten die Kompetenz in den Tätigkeitsbereichen sowie die allgemeine Informationssicherheit. Schulungen und Leistungsnachweise werden dokumentiert. Der TSP erfüllt somit die Forderungen aus Abschnitt 12.1 [GL- BRO]. 5.2.2 Mehraugenprinzip Besonders sicherheitskritische Vorgänge müssen mindestens im Vier-Augen- Prinzip durchgeführt werden. Dies wird durch technische und organisatorische Maßnahmen wie beispielsweise Zutrittsberechtigungen und Abfrage von Wissen durchgesetzt. 5.2.3 Identifikation und Authentifizierung für einzelne Rollen Das Rollenkonzept wird durch technische und organisatorische Maßnahmen, wie beispielsweise Zutrittsberechtigungen und Abfrage von Wissen, durchgesetzt. Die durchführende Person muss sich, bevor sie Zugriff auf sicherheitskritische Anwendungen erhält, erfolgreich authentifizieren. Über Event-Logs kann die durchführende Person nachträglich einer Aktion zugeordnet werden; sie ist rechenschaftspflichtig. 5.2.4 Rollenausschlüsse Das Rollenkonzept sieht diverse Rollenausschlüsse vor, die verhindern, dass eine Person allein ein Zertifikat ausstellen und in den Verzeichnisdienst einstellen kann. 5.3 Eingesetztes Personal Der TSP erfüllt die Anforderungen an das Personal aus dem [SigG] und [SigV] und beschreibt sie im Sicherheitskonzept [SiKo-DTR]. 5.3.1 Anforderungen an Qualifikation, Erfahrung und Zuverlässigkeit Der TSP gewährleistet, dass die im Bereich des Zertifizierungsdienstes tätigen Personen über die für diese Tätigkeit notwendigen Kenntnisse, Erfahrungen und Fertigkeiten verfügen. Seite 25 von 42
5.3.2 Sicherheitsprüfungen Der TSP erfüllt die Anforderungen gemäß 5 (5) SigG und beschreibt sie in seinem Sicherheitskonzept [SiKo-DTR]. So müssen unter anderem regelmäßig Führungszeugnisse vorgelegt werden. 5.3.3 Schulungen Der TSP schult Personen, die im Zertifizierungsdienst tätig sind. 5.3.4 Häufigkeit von Schulungen und Belehrungen Der TSP schult Personen, die im Zertifizierungsdienst tätig sind zu Beginn ihres Einsatzes und bei Bedarf. 5.3.5 Häufigkeit und Folge von Job-Rotation Rollenwechsel werden dokumentiert. Die entsprechenden Mitarbeiter werden geschult. Rollenwechsel finden unter Berücksichtigung des Sicherheitskonzeptes [SiKo-DTR] statt (Zugriffsrecht, Zugriffskontrolle). 5.3.6 Maßnahmen bei unerlaubten Handlungen Der TSP schließt unzuverlässige Mitarbeiter von den Tätigkeiten im Zertifizierungsdienst aus. 5.3.7 Anforderungen an freie Mitarbeiter Freie Mitarbeiter werden nicht eingesetzt. 5.3.8 Ausgehändigte Dokumentation Umfangreiche Verfahrensanweisungen definieren für alle Produktionsschritte die zuständigen Mitarbeiterrollen und -rechte sowie entsprechende manuelle und maschinelle Prüfungen. Durch die sicherheitstechnische Infrastruktur der D- TRUST ist gewährleistet, dass von diesen definierten Verfahren im Produktionsbetrieb nicht abgewichen werden kann. 5.4 Überwachungsmaßnahmen Der TSP betreibt umfangreiche Überwachungsmaßnahmen (beispielsweise durch Videoüberwachung) zur Absicherung der Zertifizierungsdienstleistungen und deren zugrunde liegenden IT-Systemen und Dokumenten. Diese Maßnahmen sind im Sicherheitskonzept [SiKo-DTR] beschrieben. Die Überwachungsmaßnahmen werden durch organisatorische Regelungen ergänzt. Beispielsweise sieht die Besucherregelung unter anderem vor, dass Besucher mindestens 24 Stunden vor dem Besuch namentlich angemeldet sein müssen und während ihres Besuchs die Personaldokumente abgeben. Im Bereich des Seite 26 von 42
Trustcenters müssen Besucher stets in Begleitung eines Mitarbeiters des TSP sein. Ein weiterer Bestandteil des Sicherheitskonzepts ist eine Risikoanalyse, die Bedrohung für den Betrieb des TSP umfassend analysiert sowie Anforderungen und Gegenmaßnahmen definiert. Ferner ist eine Restrisikoanalyse enthalten, in der die Vertretbarkeit des Restrisikos aufgezeigt wird. 5.5 Archivierung von Aufzeichnungen 5.5.1 Arten von archivierten Aufzeichnungen Es wird zwischen Aufzeichnungen in elektronischer Form und papierbasierten unterschieden. Archiviert werden die vollständigen Antragsunterlagen (auch Folgeanträge), Dokumente zu Verfahrensrichtlinien (CP, CPS), Zertifikate, Sperrdokumentation, elektronische Dateien und Protokolle zum Zertifikatslebenszyklus. Dabei werden die Vorgänge zeitlich erfasst. 5.5.2 Aufbewahrungsfristen für archivierte Daten Dokumente zur Antragstellung und Prüfung sowie die Daten zum Zertifikatslebenszyklus von X.509-QES-Zertifikaten sowie die X.509-QES- Zertifikate selbst werden mindestens 30 Jahre nach Ende der Gültigkeit des Zertifikats und bis zum Jahresende aufbewahrt. Dokumente zur Antragstellung und Prüfung sowie die Daten zum Zertifikatslebenszyklus von X.509-nonQES- Zertifikaten sowie die X.509-nonQES-Zertifikate selbst werden mindestens fünf Jahre nach Ende der Gültigkeit des Zertifikats und bis zum Jahresende aufbewahrt 1. Die Frist beginnt nach Ablauf der Gültigkeit des Zertifikates, das zuletzt auf der Basis dieser Dokumente ausgestellt wurde. 5.5.3 Sicherung des Archivs Das Archiv befindet sich in gesicherten Räumen und unterliegt dem Rollen- und Zutrittskontrollkonzept des TSP. 5.5.4 Datensicherung des Archivs Vertraulichkeit und Integrität der Daten werden gewahrt. Die Dokumentation erfolg unverzüglich, so dass sie nachträglich nicht unbemerkt verändert werden kann. Die Datenschutzanforderungen aus Bundes- und Landesrecht werden nachweislich eingehalten. 1 Sind auf dem Token zusätzlich zu den nicht-qualifizierten Zertifikaten der Root-PKI weitere Endnutzerzertifikate (qualifizierte oder qualifizierte mit Anbieterakkreditierung), ist gelten die in Aufbewahrungsfristen dieser Zertifikate. Seite 27 von 42
5.5.5 Anforderungen zum Zeitstempeln von Aufzeichnungen Der TSP betreibt keinen Zeitstempeldienst in der TI. 5.5.6 Archivierung (intern / extern) Die Archivierung erfolgt intern beim TSP sowie extern in gleichwertig gesicherten Räumen. 5.5.7 Verfahren zur Beschaffung und Verifikation von Archivinformationen Das Verfahren zur Beschaffung und Verifikation von Archivinformationen unterliegt dem Rollenkonzept des TSP. 5.6 Schlüsselwechsel beim TSP Eine angemessene Zeit vor Ablauf einer CA werden neue CA-Schlüssel generiert, neue CA-Instanzen aufgesetzt und veröffentlicht. 5.7 Kompromittierung und Geschäftsweiterführung beim TSP 5.7.1 Behandlung von Vorfällen und Kompromittierungen Der TSP verfügt über ein Notfallkonzept sowie einen Wiederanlaufplan, die den beteiligten Rollen bekannt sind und von ihnen im Bedarfsfall umgesetzt werden. Die Verantwortlichkeiten sind klar verteilt und bekannt. 5.7.2 Wiederherstellung nach Kompromittierung von Ressourcen Das Sicherheitskonzept beschreibt die Durchführung von Recovery-Prozeduren. 5.7.3 Kompromittierung des privaten CA-Schlüssels Im Fall einer Kompromittierung oder der Bekanntgabe von Insuffizienz von Algorithmen oder assoziierten Parametern durch die Herausgeber der maßgeblichen Kataloge nach Abschnitt 6.1.6, veranlasst der TSP folgendes: betroffenen CA-Zertifikate sowie deren ausgestellte und bisher nicht ausgelaufene Zertifikate werden gesperrt, involvierte Zertifikatnehmer werden über den Vorfall und dessen Auswirkungen informiert, der Vorfall wird auf den Webseiten des TSP veröffentlicht mit dem Hinweis, dass Zertifikate, die von dieser CA ausgestellt wurden, ihre Gültigkeit verlieren. Aus der Analyse der Gründe für die Kompromittierung werden, wenn möglich, Maßnahmen ergriffen, um zukünftige Kompromittierungen zu vermeiden. Unter Berücksichtigung der Gründe für die Kompromittierung werden neue CA- Signaturschlüssel generiert und neue CA-Zertifikate ausgestellt. Seite 28 von 42
5.7.4 Möglichkeiten zur Geschäftsweiterführung nach Kompromittierung und Desaster In einem Notfall entscheidet der TSP je nach Art des Vorfalls, ob ein Recovery des in Abschnitt 6.2.4 beschriebene Backups der CA durchgeführt oder bei Kompromittierung gemäß Abschnitt 5.7.3 verfahren wird. 5.8 Schließung des TSP Bei Beendigung der Dienste von CAs informiert der TSP alle Zertifikatnehmer und beendet alle Zugriffsmöglichkeiten von Unterauftragnehmern des TSP in Bezug auf die betroffenen CAs. Nach Ankündigung der Einstellung des Betriebs werden keine Zertifikate mehr ausgestellt, deren Gültigkeit über den Termin der Einstellung des Betriebs hinausgeht. Alle noch gültigen und von den betroffenen CAs ausgestellten Zertifikate werden zum Zeitpunkt der Betriebseinstellung gesperrt. Betroffene private CA-Schlüssel werden zerstört. Der Verzeichnisdienst und Dokumente zur Antragstellung von X.509-QES- Zertifikaten werden an die Bundesdruckerei GmbH übergeben und unter equivalenten Bedingungen weitergeführt. Die Aufrechterhaltung des Verzeichnisdienstes wird bis Ablauf der Gültigkeit des X.509-QES-Zertifikats zugesichert und entweder einem anderen TSP oder der Bundesdruckerei GmbH übergeben. Der Verzeichnisdienst und Dokumente zur Antragstellung von X.509-nonQES- Zertifikaten werden an die gematik mbh übergeben und unter equivalenten Bedingungen weitergeführt. Mit Beendigung des Betriebes wird alle Funktionalität der CAs eingestellt, so dass eine Zertifizierung nicht mehr möglich ist. Seite 29 von 42
6. Technische Sicherheitsmaßnahmen Die Beschreibungen dieses Kapitels beziehen sich auf die HBA-CA und SMBC-CA, die bei der D-TRUST GMBH betrieben werden. 6.1 Erzeugung und Installation von Schlüsselpaaren An dieser Stelle wwerden Schlüsselpaare für die Zertifikate von HBA und SMB-C betrachtet. 6.1.1 Erzeugung von Schlüsselpaaren Schlüssel werden vom TSP kryptographisch sicher erzeugt und entsprechen den Vorgaben von CP und CPS. Werden Schlüssel und Zertifikate auf Karten aufgebracht, verfährt der TSP bei der Beschaffung, Lagerung, Personalisierung und beim PIN-Handling wie im qualifizierten Betrieb SigG-konform und gemäß Sicherheitskonzept der D-TRUST GMBH. Der TSP kann Dritte mit der Schlüsselgenerierung und Personalisierung der Chipkarte beauftragen, die ein SigG-konformes Sicherheitskonzept vorweisen. Der TSP betreibt seinerseits eine SigG-konforme Schnittstelle zu diesen externen Personalisierern. 6.1.2 Lieferung privater Schlüssel an Zertifikatnehmer Werden die privaten Schlüssel beim TSP erzeugt, werden sie gemäß Abschnitt 4.4.1 zugestellt. 6.1.3 Lieferung öffentlicher Schlüssel an Zertifikatsherausgeber Nicht relevant. 6.1.4 Lieferung öffentlicher CA-Schlüssel an Zertifikatsnutzer Der öffentliche Schlüssel der CA ist im CA-Zertifikat enthalten. Dieses Zertifikat befindet sich i. d. R. auf der Karte (HBA oder SMC-B), die dem Zertifikatnehmer übergeben wird. Darüber hinaus können die CA-Zertifikate aus dem öffentlichen Verzeichnis (siehe Abschnitt 2.1) bezogen werden, in dem sie nach ihrer Erstellung veröffentlicht werden. 6.1.5 Schlüssellängen Für CA-Zertifikate werden derzeit RSA-Schlüssel mit einer Schlüssellänge von mindestens 2048 Bit verwendet. Seite 30 von 42
Für die Endanwender Zertifikate auf HBA und SMC-B werden derzeit RSA- Schlüssel mit einer Schlüssellänge von mindestens 2048 Bit verwendet. 6.1.6 Festlegung der Schlüsselparameter und Qualitätskontrolle CA- und Endanwender-Zertifikate werden auf Grundlage von Schlüsseln ausgestellt, die den Vorgaben der Gematik in der aktuell gültigen Fassung entsprechen, soweit Kompatibilität im Verwendungsumfeld gewährleistet ist. Signatur- und Verschlüsselungsalgorithmus sind im Abschnitt 7 CPS genannt. 6.1.7 Schlüsselverwendungen Private CA-Schlüssel werden ausschließlich zum Signieren von Zertifikaten und Sperrlisten benutzt (siehe Abschnitt 7). Die Schlüssel dürfen nur für die im Zertifikat benannten Nutzungsarten verwendet werden. Die Nutzungsarten werden in den Feldern KeyUsage und ExtKey- Usage im Zertifikat definiert und ggf. durch weitere Extentions eingeschränkt (siehe Abschnitt 7). 6.2 Sicherung des privaten Schlüssels und krytographische Module 6.2.1 Standards und Sicherheitsmaßnahmen für kryptographische Module Die vom TSP eingesetzten kryptographischen Module funktionieren einwandfrei. Während des gesamten Lebenszyklus (einschließlich Lieferung und Lagerung) werden die Module durch technische und organisatorische Maßnahmen vor unbefugter Manipulation geschützt. Zur Sicherung der CA-Schlüssel wird ein HSM eingesetzt, das entsprechend FIPS 140-2 Level 3 evaluiert wurde. Der TSP betreibt geeignete hard- und softwarebasierte Schlüsselgeneratoren um die Qualität der Schlüssel zu sichern. 6.2.2 Mehrpersonen-Zugriffssicherung zu privaten Schlüsseln (n von m) Das HSM, auf dem die CA-Schlüssel aufbewahrt werden, befindet sich in der sicheren Umgebung des Trustcenters. Die Aktivierung des privaten Schlüssels erfordert zwei autorisierte Personen. Nach der Aktivierung kann das HSM beliebig viele Zertifikate signieren. Ein Zugriff auf private Schlüssel besteht nur im Ausnahmefall einer Schlüsselhinterlegung gemäß Abschnitt 6.2.3. Seite 31 von 42
6.2.3 Hinterlegung privater Schlüssel (key escrow) Private CA-Schlüssel werden nicht bei Dritten hinterlegt. In Ausnahmefällen kann das Hinterlegen privater Schlüssel durch den Kunden, für den die CA betrieben wird, schriftlich beantragt werden. 6.2.4 Backup privater Schlüssel Es ist ein Backup der privaten CA-Schlüssel vorhanden. Ein CA-Schlüssel-Backup erfordert zwei für diese Tätigkeit am HSM autorisierte Personen und findet in der sicheren Umgebung des Trustcenters statt. Für das Backupsystem gelten die gleichen Voraussetzungen und Sicherungsmaßnahmen wie für das Produktivsystem. Eine Wiederherstellung privater Schlüssel erfordert ebenfalls zwei autorisierte Personen. Weitere Kopien der privaten CA-Schlüssel existieren nicht. 6.2.5 Archivierung privater Schlüssel Private CA- und Schlüssel werden nicht archiviert. 6.2.6 Transfer privater Schlüssel in oder aus kryptographischen Modulen Ein Transfer privater CA-Schlüssel in oder aus dem HSM erfolgt nur zu Backupund Wiederherstellungszwecken. Ein 4-Augen-Prinzip wird erzwungen. Bei Export/Import in ein anderes HSM schützt eine Verschlüsselung den privaten CA- Schlüssel. Ein Transfer privater Schlüssel aus dem kryptographischen Modul kann erfolgen, wenn der Zertifikatnehmer nachweist, dass er nach Abschnitt 4.12.1 berechtig ist, den Schlüssel wiederzuverwenden und der Transfer technisch möglich ist. Der Schlüssel verlässt das Modul nie im Klartext. 6.2.7 Speicherung privater Schlüssel in kryptographischen Modulen Die privaten CA-Schlüssel liegen verschlüsselt im HSM vor. 6.2.8 Aktivierung privater Schlüssel Die privaten CA-Schlüssel können nur im 4-Augen-Prinzip und von den zuständigen Rollen und für die zulässigen Nutzungsarten (keycertsign, crlsign) aktiviert werden. Private Schlüssel werden durch Eingabe der PIN aktiviert. 6.2.9 Deaktivieren privater Schlüssel Die privaten CA-Schlüssel werden durch Beendigung der Verbindung zwischen HSM und Anwendung deaktiviert. Seite 32 von 42
Die jeweilige Anwendung deaktiviert den privaten Schlüssel, spätestens aber das Ziehen der Karte aus dem Kartenleser. Eine dauerhafte Deaktivierung der privaten Schlüssel auf Chipkarten erfolgt, wenn die PIN-Eingabe aufeinander folgend mehrfach fehlerhaft ist. Die Anzahl der Reaktivierungsvorgänge der Karte durch Eingabe der PUK ist begrenzt. Mehrfachsignaturkarten verfügen nicht über eine PUK. 6.2.10 Zerstörung privater Schlüssel Nach Ablauf der Gültigkeit der privaten CA-Schlüssel werden diese gelöscht. Dies erfolgt durch Löschen auf dem HSM und gleichzeitigem Löschen der auf Datenträgern angelegten Backups. Bei Stilllegung des HSMs werden die privaten Schlüssel auf dem Gerät gelöscht. Wird der Chip der Karte zerstört oder werden die Dateien, die den privaten Schlüssel enthalten, gelöscht, so ist der private Schlüssel zerstört. Die Zerstörung beim TSP hinterlegter Schlüssel (nach Abschnitt 4.12.1) kann beantragt werden. 6.2.11 Beurteilung kryptographischer Module Der TSP betreibt geeignete hard- und softwarebasierte Schlüsselgeneratoren um die Qualität der Schlüssel zu sichern. Die eingesetzten HSM sind FIPS 140-2 Level 3 konform. 6.3 Andere Aspekte des Managements von Schlüsselpaaren 6.3.1 Archivierung öffentlicher Schlüssel Öffentliche CA- und Schlüssel werden gemäß Sicherheitskonzept in Form der erstellten Zertifikate archiviert. 6.3.2 Gültigkeitsperioden von Zertifikaten und Schlüsselpaaren Die Gültigkeitsdauer der CA-Schlüssel und Zertifikate beträgt 8 Jahre. Die Gültigkeitsdauer der Schlüssel und Zertifikate beträgt 5 Jahre. 6.4 Aktivierungsdaten 6.4.1 Erzeugung und Installation von Aktivierungsdaten Die Aktivierungsdaten der CA-Schlüssel werden durch das HSM abgefragt. PIN- Vergabe erfolgt während der Bootstrap-Prozedur. Ein 4-Augen-Prinzip wird erzwungen. Erzeugt der TSP die Schlüssel für den Zertifikatsnehmer, wird entweder ein Transport-PIN-Verfahren genutzt oder die PINs werden in einen PIN-Brief ge- Seite 33 von 42
druckt und an den Zertifikatnehmer versandt oder übergeben. Eine Installation ist nicht erforderlich. 6.4.2 Schutz von Aktivierungsdaten Die Aktivierungsdaten der CA-Schlüssel setzen sich aus zwei Geheimnissen zusammen, von denen jeweils ein berechtigter Mitarbeiter eines kennt. Der Zugriff auf die Aktivierungsdaten ist nur bestimmten vorgesehenen Mitarbeitern möglich. Beim Transport-PIN-Verfahren ist die Unversehrtheit der Karte für den Zertifikatsnehmer über die Transport-PIN erkennbar. In anderen Verfahren werden die PINs einmalig in einen besonders gesicherten PIN-Brief gedruckt und an den Zertifikatnehmer versandt oder übergeben. 6.4.3 Andere Aspekte von Aktivierungsdaten Produktspezifisch wird Zertifikatnehmern mit Signaturkarte zusätzlich zu der PIN eine Personal Unblocking Key-Nummer (PUK) zum Entsperren der Signaturkarte (nach dreimaliger Fehleingabe der PIN) angeboten. Mehrfachsignaturkarten verfügen nicht über eine PUK. 6.5 Sicherheitsmaßnahmen in den Rechneranlagen 6.5.1 Spezifische technische Sicherheitsanforderungen in den Rechneranlagen Die vom TSP eingesetzten Computer, Netze und andere Komponenten stellen in der eingesetzten Konfiguration sicher, dass nur Aktionen durchgeführt werden können, die nicht im Widerspruch zu CP und den Vorgaben der Telematikinfrastruktur der Gematik stehen. Die Computersicherheit des TSP wird für exponierte Systeme u.a. durch mehrstufige Sicherheitssysteme zum Zwecke des perimetrischen Virenschutzes, Endpoint-Protection und integritätssichernde Werkzeuge sichergestellt. Zertifikatnehmer und Zertifikatsnutzer müssen vertrauenswürdige Computer und Software verwenden. 6.5.2 Beurteilung von Computersicherheit Die für die CA-Schlüssel eingesetzten Computer, Netze und andere Komponenten wurden durch eine von der Bundesnetzagentur anerkannte Prüf- und Bestätigungsstelle geprüft. Seite 34 von 42
6.6 Technische Maßnahmen während des Life Cycles 6.6.1 Sicherheitsmaßnahmen bei der Entwicklung Bei der Entwicklung aller vom TSP oder im Auftrag des TSP durchgeführter Systementwicklungsprojekte werden Sicherheitsanforderungen im Entwurfsstadium analysiert. Die gewonnenen Erkenntnisse werden als Anforderungen bei der Entwicklung festgelegt. 6.6.2 Sicherheitsmaßnahmen beim Computermanagement Ausschließlich entsprechend dem Rollenkonzept (des Sicherheitskonzepts des signaturgesetzkonformen ZDAs D-TRUST GMBH) autorisiertes Personal darf Computer, Netze und andere Komponenten administrieren. Es findet eine regelmäßige Auswertung von Logfiles auf Regelverletzungen, Angriffsversuche und andere Vorfälle statt. Überwachungsmaßnahmen beginnen mit Inbetriebnahme eines Gerätes und enden mit dessen Entsorgung. 6.6.3 Sicherheitsmaßnahmen während des Life Cycles Eingesetzte Geräte werden gemäß Herstellerangaben betrieben. Vor Inbetriebnahme werden sie eingehend geprüft und kommen nur zum Einsatz, wenn zweifelsfrei feststeht, dass sie nicht manipuliert wurden. Durch Versiegelung der Hardware und Softwarechecks beispielsweise werden Manipulationen und Manipulationsversuche bei jeder Aktion oder Revision erkennbar. Bei Verdacht auf Manipulation einer Komponente, wird eine ggf. geplante Aktion an der Komponente nicht durchgeführt und der Vorfall dem TSP-Leiter gemeldet. Um kurzfristig und koordiniert auf eventuelle sicherheitsrelevante Vorfälle reagieren zu können, definiert der TSP klare Eskalationsrichtlinien für die einzelnen Rollen. Kapazitätsanforderungen und -auslastungen sowie Eignung der beteiligten Systeme werden überwacht und bei Bedarf angeglichen. Ausgetauschte Geräte oder obsolete Datenträger werden derart außer Betrieb genommen und entsorgt, dass Funktionalitäts- oder Datenmissbrauch ausgeschlossen wird. Änderungen an Systemen, Software oder Prozessen durchlaufen einen Change-Management- Prozess. Sicherheitskritische Änderungen werden durch den Sicherheitsbeauftragten geprüft. Nach Ablauf der Gültigkeit von CAs werden die privaten Schlüssel vernichtet. Elektronische Daten oder papiergebundene Protokolle dokumentieren alle relvanten Ereignisse, die den Life-Cycle der CA sowie der ausgestellten Zertifikate und generierten Schlüssel beeinflussen und werden auf langlebigen Medien revisionssicher gespeichert. Die Medien des Unternehmens werden entsprechend ihrer Kassifizierung im Rahmen der Dokumentationsrichtlinie des TSP zuverlässig vor Schaden, Entwendung, Verlust oder Kompromittierung geschützt. Seite 35 von 42