Security Target für secunet konnektor 2.1.0 (eHealth Rechenzentrums Konnektor PTV5 WR1) secunet Security Networks AG Kurfürstenstraße 58, 45138 Essen Internet: www.secunet.com © secunet Security Networks AG 2022 Bundesamt für Sicherheit in der Informationstechnik Änderungsverlauf Version Datum Änderungen Anmerkungen 1.0 09.05.2022 Initial Version Initiale Version basierend auf dem PTV5 ST (BSI-DSZ- CC-1190-2022), Version 1.3 vom 03.03.2022 1.1 15.06.2022 Anpassen des ST an zertifiziertes PP0098 (BSI-DSZ-CC-0098-V3-2021-MA-01), v1.6 vom 30.03.2022 - 1.2 27.06.2022 Errata ergänzt und Direktiven aktualisiert - Letzte Version: 1.2 (27.06.2022) Inhaltsverzeichnis Seite 4 von 424 secunet Inhaltsverzeichnis 1. ST-Einführung ...........................................................................................9 1.1. ST-Referenz................................................................................................9 1.2. ST-Übersicht.............................................................................................11 1.2.1. Abgrenzung..............................................................................11 1.2.2. Terminologie............................................................................11 1.3. EVG-Beschreibung ..................................................................................13 1.3.1. EVG-Typ..................................................................................14 1.3.2. Einsatzumgebung des Konnektors...........................................19 1.3.3. Schnittstellen des Konnektors..................................................21 1.3.4. Aufbau und physische Abgrenzung des Konnektors...............25 1.3.5. Logische Abgrenzung: Vom EVG erbrachte Sicherheitsdienste ..................................................................................................28 1.3.6. Non-EVG hardware/software/firmware...................................39 2. Postulat der Übereinstimmung...............................................................41 2.1. Common Criteria Konformität ..............................................................41 2.2. Security Target-Konformität..................................................................41 2.3. Paket-Konformität...................................................................................41 2.4. Begründung der Konformität.................................................................41 2.5. ST-Organisation.......................................................................................42 3. Definition des Sicherheitsproblems........................................................43 3.1. Werte.........................................................................................................43 3.1.1. Zu schützende Werte................................................................43 3.1.2. Benutzer des EVG....................................................................51 3.2. Bedrohungen ............................................................................................60 3.2.1. Gegen den Netzkonnektor gerichtete Bedrohungen ................60 3.2.2. Gegen den Anwendungskonnektor gerichtete Bedrohungen...66 3.3. Organisatorische Sicherheitspolitiken ...................................................70 3.3.1. Organisatorische Sicherheitspolitiken des Netzkonnektors.....70 3.3.2. Organisatorische Sicherheitspolitiken des Anwendungskonnektors...........................................................72 3.4. Annahmen.................................................................................................76 3.4.1. Annahmen an den Netzkonnektor............................................76 3.4.2. Annahmen an den Anwendungskonnektor ..............................80 4. Sicherheitsziele.........................................................................................85 4.1. Sicherheitsziele für den Netzkonnektor.................................................85 4.1.1. Allgemeine Ziele: Schutz und Administration ........................85 4.1.2. Ziele für die VPN-Funktionalität.............................................88 4.1.3. Ziele für die Paketfilter-Funktionalität ....................................90 4.2. Sicherheitsziele für den Anwendungskonnektor...................................91 Inhaltsverzeichnis secunet Seite 5 von 424 4.2.1. Allgemeine Sicherheitsziele.....................................................91 4.2.2. Signaturdienst ..........................................................................93 4.2.3. Gesicherte Kommunikation / TLS Proxy ................................96 4.2.4. Terminal- und Chipkartendienst ..............................................98 4.2.5. Verschlüsselungsdienste ..........................................................99 4.2.6. Fachmodule............................................................................100 4.3. Sicherheitsziele für die Umgebung des Netzkonnektors ....................100 4.4. Sicherheitsziele für die Umgebung des Anwendungskonnektors......108 4.5. Erklärung der Sicherheitsziele .............................................................117 4.5.1. Überblick über die Sicherheitsziele des Netzkonnektors.......117 4.5.2. Überblick über die Sicherheitsziele des Anwendungskonnektors ................................................................................................118 4.5.3. Detaillierte Erklärung für den Netzkonnektor .......................121 4.5.4. Detaillierte Erklärung für den Anwendungskonnektor..........129 5. Definition zusätzlicher Komponenten..................................................140 5.1. Definition der erweiterten Familie FPT_EMS und der Anforderung FPT_EMS.1 ............................................................................................140 5.2. Definition der Familie FIA_API Authentication proof of Identity ...140 6. Sicherheitsanforderungen.....................................................................142 6.1.1. Hinweise zur Notation ...........................................................142 6.1.2. Modellierung von Subjekten, Objekten, Attributen und Operationen............................................................................142 6.2. Funktionale Sicherheitsanforderungen des Netzkonnektors.............161 6.2.1. VPN-Client ............................................................................161 6.2.2. Dynamischer Paketfilter mit zustandsgesteuerter Filterung ..164 6.2.3. Netzdienste.............................................................................174 6.2.4. Stateful Packet Inspection......................................................176 6.2.5. Selbstschutz............................................................................176 6.2.6. Administration .......................................................................181 6.2.7. Kryptographische Basisdienste..............................................190 6.2.8. TLS-Kanäle unter Nutzung sicherer kryptographischer Algorithmen ...........................................................................195 6.3. Funktionale Sicherheitsanforderungen des Anwendungskonnektors ..................................................................................................................205 6.3.1. Klasse FCS: Kryptographische Unterstützung ......................205 6.3.2. Klasse FIA: Identifikation und Authentisierung....................219 6.3.3. Klasse FDP: Schutz der Benutzerdaten .................................223 6.3.4. Klasse FMT: Sicherheitsmanagement ...................................291 6.3.5. Klasse FPT: Schutz der TSF..................................................296 6.3.6. Klasse FAU: Sicherheitsprotokollierung...............................303 6.3.7. Sicherheitsanforderungen für die ePA Fachanwendung (PTV4) ................................................................................................306 6.4. Sicherheitsanforderungen an die Vertrauenswürdigkeit des EVG ..320 6.4.1. Verfeinerungen entsprechend Schutzprofil............................320 Inhaltsverzeichnis Seite 6 von 424 secunet 6.4.2. Verfeinerungen hinsichtlich der Fachmodule NFDM, AMTS und ePA..................................................................................323 6.5. Erklärung der Sicherheitsanforderungen ...........................................326 6.5.1. Erklärung der Abhängigkeiten der funktionalen Sicherheitsanforderungen des Netzkonnektors......................326 6.5.2. Erklärung der Abhängigkeiten der funktionalen Sicherheitsanforderungen des Anwendungskonnektors ........326 6.5.3. Überblick der Abdeckung von Sicherheitszielen des Netzkonnektors durch SFRs des Netzkonnektors..................326 6.5.4. Überblick der Abdeckung von Sicherheitszielen des Konnektors durch SFRs des Netzkonnektors und des Anwendungskonnektors.........................................................328 6.5.5. Detaillierte Erklärung für die Sicherheitsziele des Netzkonnektors ......................................................................332 6.5.6. Detaillierte Erklärung für die Sicherheitsziele des Anwendungskonnektors.........................................................342 6.5.7. Erklärung für die Vertrauenswürdigkeitsanforderungen .......358 7. Zusammenfassung der EVG Sicherheitsfunktionalität......................359 7.1. Sicherheitsfunktionen des Netzkonnektors .........................................359 7.1.1. NK.VPN-Client......................................................................359 7.1.2. NK.Dynamischer Paketfilter..................................................360 7.1.3. NK.Netzdienste......................................................................360 7.1.4. NK.Stateful Packet Inspection...............................................361 7.1.5. NK.Selbstschutz.....................................................................361 7.1.6. NK.Administration.................................................................362 7.1.7. NK.Kryptographische Basisdienste.......................................363 7.1.8. NK.TLS-Kanäle unter Nutzung sicherer kryptographischer Algorithmen ...........................................................................364 7.2. Sicherheitsfunktionen des Anwendungskonnektors...........................365 7.2.1. AK.Identifikation und Authentisierung .................................366 7.2.2. AK.Zugriffsberechtigungsdienst............................................367 7.2.3. AK.Kartenterminaldienst.......................................................367 7.2.4. AK.Kartendienst ....................................................................367 7.2.5. AK.Signaturdienst..................................................................368 7.2.6. AK.Software-Update .............................................................370 7.2.7. AK.Verschlüsselungsdienst ...................................................370 7.2.8. AK.TLS-Kanäle.....................................................................371 7.2.9. AK.Sicherer Datenspeicher....................................................372 7.2.10. AK.Fachmodul VSDM ..........................................................372 7.2.11. AK.Sicherheitsmanagement...................................................372 7.2.12. AK.Schutz der TSF................................................................373 7.2.13. AK.Sicherheitsprotokollierung..............................................373 7.3. Sicherheitsfunktionen für die ePA Fachanwendung (PTV4).............374 7.3.1. VAU-Kanal............................................................................374 7.3.2. SGD-Kanal.............................................................................374 Inhaltsverzeichnis secunet Seite 7 von 424 7.4. Abbildung der Sicherheitsfunktionalität auf Sicherheitsanforderungen.....................................................................374 7.4.1. Überblick................................................................................375 7.4.2. Erfüllung der funktionalen Sicherheitsanforderungen...........380 8. ST-Erweiterung......................................................................................381 8.1. Erweiterungen für PTV3, PTV4 und PTV5........................................381 8.2. Erweiterungen für unterstützte Fachmodule......................................393 8.3. Informationen zur Signaturdirektive...................................................397 8.4. Informationen zur Verschlüsselungsdirektive ....................................398 9. Anhang....................................................................................................399 9.1. Auszüge aus der Konnektorspezifikation [27] zum Zugriffsberechtigungsdienst .................................................................399 9.2. Abkürzungsverzeichnis .........................................................................400 9.3. Glossar ....................................................................................................404 9.4. Abbildungsverzeichnis...........................................................................415 9.5. Tabellenverzeichnis................................................................................415 9.6. Literaturverzeichnis ..............................................................................416 9.6.1. Kriterien .................................................................................416 9.6.2. Gesetze und Verordnungen....................................................417 9.6.3. Schutzprofile und Technische Richtlinien............................417 9.6.4. Spezifikationen ......................................................................418 9.6.5. Standards................................................................................420 9.6.6. Dokumentation.......................................................................424 Security Target secunet konnektor 2.1.0 secunet Seite 9 von 424 1. ST-Einführung 1.1. ST-Referenz Titel: Security Target für secunet konnektor 2.1.0 Version des Dokuments: 1.2 Datum des Dokuments: 27.06.2022 Allgemeiner Status: Version zur Evaluierung ST-Registrierung: BSI-DSZ-CC-1202 PP Registrierung: BSI-CC-PP-0098, 1.6 PP Registrierung bei: Bundesamt für Sicherheit in der Informationstechnik (BSI) CC-Version 3.1 (Revision 5) Vertrauenswürdigkeitsstufe: EAL3 erweitert um ADV_FSP.4, ADV_TDS.3, ADV_IMP.1, ALC_TAT.1, AVA_VAN.3 und ALC_FLR.2 Verfasser: SRC GmbH und secunet Security Networks AG TOE Name. secunet konnektor 2.1.0 TOE Version 5.1.2:2.1.0 Ausbaustufe PTV5 WR1 Security Target secunet konnektor 2.1.0 Seite 10 von 424 secunet Dieses Security Target wurde konform zu den folgenden Dokumenten [4] Common Criteria for Information Technology Security Evaluation – Part 1: Introduction and general model, Version 3.1 Revision 5, April 2017, CCMB- 2017-04-001 [5] Common Criteria for Information Technology Security Evaluation – Part 2: Security functional components, Version 3.1 Revision 5, April 2017, CCMB- 2017-04-002 [6] Common Criteria for Information Technology Security Evaluation – Part 3: Security assurance components, Version 3.1 Revision 5, April 2017, CCMB- 2017-04-003 und unter Berücksichtigung [7] Common Methodology for Information Technology Security Evaluation, Evaluation methodology (CEM), Version 3.1 Revision 5, April 2017, CCMB- 2017-04-004 erstellt. Darüber hinaus orientiert sich dieses Dokument in fachlicher Hinsicht an den relevanten Spezifikationen der gematik, die im Anhang in Abschnitt 9.6 (insbesondere Abschnitt 9.6.4) aufgeführt sind; allen voran die Konnektorspezifikation: [27] Elektronische Gesundheitskarte und Telematikinfrastruktur: Spezifikation Konnektor [gemSpec_Kon], PTV5: Version 5.15.0, 31.01.2022, gematik GmbH Security Target secunet konnektor 2.1.0 secunet Seite 11 von 424 1.2. ST-Übersicht Dieses Security Target beschreibt den Schutzbedarf für den Konnektor secunet konnektor 2.1.0 gemäß Spezifikation [27]. Der Konnektor besteht aus dem Netzkonnektor (NK) und dem Anwendungskonnektor (AK) und verwendet die Security Module Card Konnektor (gSMC-K). Der Konnektor stellt die Plattform für die Ausführung von Fachmodulen bereit.  Der Netzkonnektor stellt Paketfilter- und VPN-Funktionalität für die Kommunikation mit der zentralen Telematikinfrastruktur-Plattform und einem Sicheren Internet Service (SIS) bereit, ebenso die gesicherte Kommunikation zwischen dem Konnektor und dem Clientsystem sowie zwischen Fachmodulen und fachanwendungsspezifischen Diensten (Fachdiensten bzw. Intermediären). Darüber hinaus verwendet er die Hardware- Virtualisierung der CPU, um dem AK und seinen Fachmodulen einen Separationsmechanismus zur Verfügung zu stellen.  Die Security Module Card Konnektor basiert auf einer Chipkarte mit einem Chipkartenbetriebssytem und dem Objektsystem für gSMC-K. Sie speichert Schlüsselmaterial für den Netzkonnektor und den Anwendungskonnektor und stellt kryptographische Sicherheitsfunktionen bereit.  Die Sicherheitsfunktionalität des Anwendungskonnektors umfasst die Signaturanwendung, die Verschlüsselung und Entschlüsselung von Dokumenten, den Kartenterminaldienst und den Chipkartendienst. Zusammen mit dem Netzkonnektor ermöglicht der Anwendungskonnektor zudem die gesicherte Kommunikation zwischen dem Konnektor und dem Clientsystem sowie zwischen Fachmodulen und Fachdiensten. 1.2.1. Abgrenzung Das Schutzprofil BSI-CC-PP-0098 [16] definiert die Sicherheitsanforderungen an den Konnektor, bestehend aus Netzkonnektor und Anwendungskonnektor. Die gSMC-K ist nicht Teil des EVG und wird separat betrachtet: Das Chipkartenbetriebssytem der gSMC-K ist von der gematik zugelassen (A.AK.gSMC-K). Für das Chipkartenbetriebssystem existiert eine eigene Spezifikation [31]. Der EVG des vorliegenden ST schließt die gSMC-K als Teil der IT-Umgebung ein. Die relevanten Sicherheitsziele der Einsatzumgebung, wie OE.NK.gSMC-K, OE.NK.KeyStorage und OE.NK.RNG beziehen sich auf die Funktionalität der gSMC-K. 1.2.2. Terminologie Der „Evaluierungsgegenstand“ (EVG, englisch „Target of Evaluation“, TOE) der durch dieses Security Target definiert wird, wird als Konnektor bezeichnet. Der Konnektor bildet die Schnittstelle zwischen der zentralen Telematikinfrastruktur-Plattform des Gesundheitswesens und den Clientsystemen der Leistungserbringer. Die Chipkarten elektronische Gesundheitskarte (eGK), Heilberufsausweis (HBA), die Institutionskarte (SMC- B, Security Module Card Typ B), die SMC-B der Gesellschafterorganisationen (SMC-B ORG), Security Target secunet konnektor 2.1.0 Seite 12 von 424 secunet das Hardware-Sicherheitsmodul HSM-B, die Kartenterminals und die Konnektoren bilden die dezentralen Komponenten der Telematikinfrastruktur. Zu den Clientsystemen gehören die Praxisverwaltungssysteme der Ärzte (PVS), die Krankenhausinformationssysteme (KIS) und die Apothekenverwaltungssysteme (AVS). Der Konnektor stellt auch eine gesicherte Verbindung zu einem Sicheren Internet Service (SIS) bereit. Der Konnektor unterstützt weiterhin die Vorläuferkarten des HBA, den HBA-qSig und den ZOD-2.0. Security Target secunet konnektor 2.1.0 secunet Seite 13 von 424 1.3. EVG-Beschreibung Der Evaluierungsgegenstand ist:  der Konnektor, secunet konnektor 2.1.0 bestehend aus den Komponenten o Netzkonnektor, o Anwendungskonnektor, o Fachmodul „Versichertenstammdatenmanagement“ (VSDM) [37]. welcher als eine Einbox-Lösung1 implementiert wird. Der EVG secunet konnektor 2.1.0 umfasst die Software des Konnektors und die dazugehörige Dokumentation für Administratoren und Benutzer [110], [111] [112] und [116]. Komponenten des Konnektors Version Hardware (nicht Teil des EVG) 2.1.0 BIOS FW (nicht Teil des EVG) CSASR009 oder CSASR011 Fachmodul AMTS (nicht Teil des EVG) 5.1.1 Fachmodul NFDM (nicht Teil des EVG) 5.1.1 Fachmodul ePA (nicht Teil des EVG) 5.1.1 Softwareversion Netzkonnektor2 5.1.2 Softwareversion Anwendungskonnektor (inkl. Fachmodul VSDM) 5.1.2 Bedienhandbuch 6.1 Errata Bedienhandbuch 1.0 Hinweise und Prüfpunkte für Endnutzer 1.8 REST-API Spezifikation 5.0.0 Security Guidance Fachmodulentwicklung 1.5 1 Genauer: zwei Einbox-Konnektoren, die (ohne Einbox-Gehäuse) in einem 19 Zoll Gehäuse mit einer Höheneinheit verbaut sind. 2 Mit dieser Versionsnummer ist auch die Version des Anwendungskonnektors fest bestimmt. Zur exakten bestimmung der TOE Version reicht daher die Angabe der Softwareversion des Netzkonnektor. Security Target secunet konnektor 2.1.0 Seite 14 von 424 secunet Tabelle 1: Komponenten der Einbox-Lösung 1.3.1. EVG-Typ Der Konnektor stellt einen neuen Produkttyp dar, so dass außer dem Gattungsbegriff „Konnektor“ kein weiterer TOE Typ benannt werden kann. Die Verantwortung für den Betrieb des Konnektors liegt beim Konnektor-Betreiber (bzw. Leistungserbringer); der Konnektor stellt jedoch ein Zugangserfordernis zur Telematikinfrastruktur dar und es dürfen nur von der Gematik zugelassene und geprüfte Konnektoren eingesetzt werden. Der Konnektor erbringt Sicherheitsleistungen in drei wesentlichen Funktionsblöcken: Netzkonnektor, Anwendungskonnektor und Sicherheitsmodul. Die Sicherheitsfunktionalität  einer Firewall,  eines VPN-Clients,  von Servern für Zeitdienst, Namensdienst und DHCP-Dienst, und  die Basisdienste zum Aufbau von TLS-Kanälen3 , werden durch den Bestandteil Netzkonnektor erbracht (Teil des EVG). Die Sicherheitsfunktionalität  einer Signaturanwendung,  eines Kryptomoduls für die Verschlüsselung und für die Initiierung der gesicherten Kommunikation zwischen dem Konnektor und dem Clientsystem, zwischen Fachmodulen und Fachdiensten sowie zwischen Servern und dem Kartenterminaldienst, dem Chipkartendienst werden durch den Anwendungskonnektors erbracht (Teil des EVG). Das Sicherheitsmodul gSMC-K stellt interne Sicherheitsfunktionalität zur Speicherung von Schlüsselmaterial und kryptographische Sicherheitsfunktionen für den Konnektor bereit (nicht Teil der Evaluierung). 3 Die Basisdienste zum Aufbau von TLS-Kanälen werden vom Anwendungskonnektor implementiert sind aber formal dem Netzkonnektor zugeordnet. Security Target secunet konnektor 2.1.0 secunet Seite 15 von 424 Die wesentlichen Funktionsblöcke des Konnektors sind in der folgenden Abbildung 1 dargestellt. Abbildung 1: Funktionsblöcke des Konnektors 1.3.1.1. Sicherheitsfunktionen des Netzkonnektors (NK) Firewall Der Netzkonnektor bildet die Schnittstelle zwischen der zentralen Telematikinfrastruktur- Plattform des Gesundheitswesens (außerhalb der Verantwortlichkeit der Leistungserbringer) und den dezentralen Systemen. Er stellt den netzseitigen Abschluss der zentralen Telematikinfrastruktur-Plattform dar. Der Zugriff auf Fachanwendungen der zentralen Telematikinfrastruktur-Plattform wird für Fachmodule des Konnektors auf gesicherte Fachdienste und für Clientsysteme bzw. Fachmodule im LAN des Leistungserbringers auf offene Fachdienste ermöglicht. Die Kommunikation mit aktiven Bestandsnetzen erfolgt ebenfalls nur über den VPN-Tunnel der zentralen Telematikinfrastruktur-Plattform. Für den Fall einer Anbindung des lokalen Netzes des Leistungserbringers an das Internet dient der Netzkonnektor als Internet Gateway und stellt einen sicheren Kanal zum Zugangspunkt des sicheren Internet-Dienstleisters sowie einen Paketfilter (IP-Firewall) zur Verfügung. VPN-Client Der Netzkonnektor baut mit einem VPN-Konzentrator der zentralen Telematikinfrastruktur- Plattform einen VPN-Kanal gemäß dem Standard IPsec (IP Security) auf. Netzkonnektor und VPN-Konzentrator authentisieren sich gegenseitig und leiten einen Sitzungsschlüssel ab, mit dem die Vertraulichkeit und Integrität der nachfolgenden Kommunikation gesichert wird. Dazu nutzt der Netzkonnektor Schlüsselmaterial, welches auf einem dem Netzkonnektor zugeordneten Sicherheitsmodul (gSMC-K) gespeichert ist. NK u. a.: Initiierung der TLS-Kanäle zum Clientsystem, Ablaufkontrolle, Initiierung der TLS-Kanäle zu den KTs Anwendungskonnektor (AK) Netzkonnektor (NK) gSMC-K Konnektor Sicherheitsmodul des Konnektors, dient als Schlüsselspeicher für die verschiedenen Konnektorteile (nicht Teil des EVG) AK Security Target secunet konnektor 2.1.0 Seite 16 von 424 secunet In analoger Weise baut der Netzkonnektor einen VPN-Kanal zum SIS auf. Netzkonnektor und SIS authentisieren sich gegenseitig und leiten einen Sitzungsschlüssel ab, mit dem die Vertraulichkeit und Integrität der nachfolgenden Kommunikation gesichert wird. Dazu nutzt der Netzkonnektor Schlüsselmaterial, welches auf einem dem Netzkonnektor zugeordneten Sicherheitsmodul (gSMC-K) gespeichert ist. Der VPN-Kanal zum VPN-Konzentrator der zentralen Telematikinfrastruktur-Plattform (siehe FTP_ITC.1/NK.VPN_TI für die Kommunikation mit der Telematikinfrastruktur) stellt eine Absicherung der Kommunikationsbeziehung zwischen Netzkonnektor und VPN-Konzentrator auf Netzwerkebene dar. Nach erfolgtem Aufbau des VPN-Tunnels zur Telematikinfrastruktur durch den Netzkonnektor (= Teil des EVG) nutzt der Anwendungskonnektor (= IT-Umgebung) diesen Kanal und authentisiert4 die Organisation des Leistungserbringers gegenüber den Fachdiensten. Dazu nutzt der Anwendungskonnektor Schlüsselmaterial, welches auf einem der Organisation des Leistungserbringers zugeordneten Sicherheitsmodul (SM-B) gespeichert ist. TLS Kanal5 Die Dienste zum Aufbau von Transport Layer Security (TLS) Kanälen zu verschiedenen Zwecken und Endpunkten werden dem Anwendungskonnektor vom Netzkonnektor zur Verfügung gestellt. Hierunter fällt beispielsweise der sichere Kanal zwischen Anwendungskonnektor und Fachdiensten, bzw. zentralen Diensten der TI oder der sichere Kanal zwischen Anwendungskonnektor und Clientsystem im LAN des Leistungserbringers. Die über den TLS-Kanal transportierten Daten werden teilweise auf Anwendungsebene weiter geschützt, beispielsweise durch mit einem HBA erstellte Signaturen. Zeitdienst Der Konnektor stellt einen NTP-Server der Stratum-3-Ebene für Fachmodule und Clientsysteme bereit, welcher die Zeitangaben eines NTP Servers Stratum-2-Ebene der zentralen Telematikinfrastruktur-Plattform in regelmäßigen Abständen abfragt. Der EVG kann die synchronisierte Zeit anderen Komponenten des Konnektors zur Verfügung stellen. Die vom EVG bereitgestellte Zeit-Information wird für die Prüfung der Gültigkeit von Zertifikaten genutzt, und um die Audit-Daten des Sicherheits-Logs mit einem Zeitstempel zu versehen. DNS-Dienst Der EVG stellt an der LAN-Schnittstelle die Funktion eines DNS-Servers zur Verfügung. 4 Diese Authentisierung ist nicht Gegenstand des Security Targets. 5 Die Basisdienste zum Aufbau von TLS-Kanälen werden vom Anwendungskonnektor implementiert sind aber formal dem Netzkonnektor zugeordnet. Security Target secunet konnektor 2.1.0 secunet Seite 17 von 424 DHCP-Dienst Die Sicherheitsfunktion “DHCP-Dienst” ist Bestandteil des Konnektors. Der EVG stellt an der LAN-Schnittstelle die Funktion eines DHCP Servers gemäß RFC 2131 [66] und RFC 2132 [67] zur Verfügung. 1.3.1.2. Sicherheitsfunktionen des Anwendungskonnektors (AK) SCaVA Der EVG stellt als SCaVA (Signature Creation Application and Signature Validation Application) einen Signaturdienst zur Erstellung und Prüfung von qualifizierten Signaturen nach der eIDAS-VO [12] und nicht qualifizierten Signaturen bereit. Er führt über die eHealth-Kartenterminals zu signierende Daten den (qualifizierten) Signaturerstellungseinheiten für die Erstellung von (qualifizierten) Einzel- und Stapelsignaturen und Komfortsignaturen über ein lokales Netz zu. Der Signaturdienst ist für die Erstellung einer begrenzten Anzahl von qualifizierten Signaturen nach der einmaligen Authentisierung des Signaturschlüssel-Inhabers gegenüber der qualifizierten Signaturerstellungs¬einheit (QSEE) mit entfernter und lokaler PIN-Eingabe geeignet (Stapelsignatur nach [21]). Der Signaturdienst unterstützt darüber hinaus die Erstellung von qualifizierten Einfachsignaturen (s.a. [21]) mit lokaler und entfernter PIN- Eingabe. Der Signaturdienst ist für die Erstellung qualifizierter elektronischer Signaturen durch mehrere Benutzer in einem lokalen Netz vorgesehen, d. h. jeder Signaturschlüssel-Inhaber nutzt zur Erstellung dieser Signaturen die Benutzerschnittstelle zum Clientsystem von jedem konfigurierten Arbeitsplatz des lokalen Netzes und seine an einem vor physischen Zugriff geschützten Bereich befindlichen QSEE, dem Heilberufsausweis (HBA). Bei Aktivierung der Komfortsignatur authentisiert sich der Karteninhaber jeweils für eine HBA- Kartensitzung einmalig mittels Signatur-PIN und es wird, falls noch nicht vorhanden, ein Secure Messaging Kanal zwischen Konnektor und Signaturkarte aufgebaut. Der Authentisierungzustand für die HBA-Kartensitzung (CardSession) wird solange aufrecht erhalten bis ein der HBA-Kartensitzung zugeordneter Zähler für Signaturen oder ein Timer abgelaufen sind. Die Maximalwerte für Signaturzähler und Timer können global für alle HBA- Kartensitzungen konfiguriert werden. Der Signaturdienst kann für die Erstellung digitaler (nicht-qualifizierter) Signaturen mit anderen Chipkarten und für die Prüfung digitaler (nicht-qualifizierter) Signaturen verwendet werden. Kryptomodul Der EVG stellt als Kryptomodul einen Verschlüsselungsdienst zur Verschlüsselung und Entschlüsselung von Dokumenten bereit, die von Clientsystemen, dem VSDM Fachmodul oder anderen Fachmodulen übergeben und nach der Bearbeitung an diese zurückgegeben werden. Der Verschlüsselungsdienst benutzt den Zertifikatsdienst und eine lokale oder entfernte Security Target secunet konnektor 2.1.0 Seite 18 von 424 secunet Eingabe der Kartenhalter-PIN für den Zugriff auf die kryptographischen Schlüssel der Chipkarten. Er steht den Clientsystemen zur Benutzung zur Verfügung. Der EVG stellt als Kryptomodul eine gesicherte Kommunikation zwischen dem Konnektor und dem Clientsystem sowie zwischen Fachmodulen und Fachdiensten bereit. Die gesicherte Kommunikation zwischen dem Konnektor und dem Clientsystem über das lokale Netz der Leistungserbringer (LE-LAN) ist konfigurierbar, d.h. wenn sie eingerichtet ist, wird sie durch den EVG erzwungen, und entfällt, sofern sie nicht eingerichtet wurde. Die gesicherte Kommunikation zwischen Fachmodulen und Fachdiensten wird auf Anforderung der Fachmodule hergestellt. Server für Sicherheitsdienste Der EVG stellt den Kartenterminaldienst zur Nutzung der eHealth-Kartenterminals und den Chipkartendienst zur Nutzung der Chipkarten in den eHealth-Kartenterminals gemäß Spezifikation Konnektor [27] zur Verfügung und erbringt Sicherheitsfunktionalität für deren sichere Nutzung und den Schutz der Ressourcen. Der EVG kommuniziert mit den eHealth-Kartenterminals (eHKT, s. [38]) im LE-LAN über gesicherte Verbindungen. Diese Verbindungen beruhen auf dem Einrichten der eHealth- Kartenterminals im LE-LAN (einschließlich Pairing), der gegenseitigen Authentisierung des EVG und der eHealth-Kartenterminals und der Sicherung der Vertraulichkeit und der Integrität der übertragenen Daten durch TLS-Kanäle. Der EVG stellt den Chipkartendienst für den Zugriff auf in eHealth-Kartenterminals gesteckte Karten, die lokale und entfernte PIN-Eingabe und die Card-to-Card-Authentisierung als gekapselte Funktionalität zur Verfügung und nutzt sie selbst im Rahmen anderer Sicherheitsdienste. Der EVG kontrolliert den Zugriff auf Chipkarten in Abhängigkeit von deren Sicherheitszustand. Fachmodul „Versichertenstammdatenmanagement“ Der EVG umfasst das Fachmodul VSDM. Es unterstützt die Anwendungsfälle der Fachanwendung VSDM, indem es dem Clientsystem anwendungsspezifische Schnittstellen zum Auslesen der Versichertenstammdaten der eGK und der KVK anbietet. Dazu nutzt es Funktionalitäten, die der Anwendungskonnektor anbietet, wie z.B. Zugriff auf die Karten. Um die Aktualität der VSD auf der eGK zu prüfen, kommuniziert das Fachmodul unter Nutzung des fachanwendungsspezifischen Intermediärs VSDM mit dem Fachdienst des Kostenträges des Versicherten und aktualisiert bei Bedarf die VSD. Das Fachmodul ist verantwortlich für die fachlichen Abläufe der Fachanwendung VSDM im Konnektor. Wesentliche Teile des Funktionsumfangs sind: Lesen der Versichertendaten von der eGK bzw. von der KVK, Prüfen der Vorbedingungen, Kommunikation mit den Fachdiensten, um die eGK zu aktualisieren und Erstellung des Prüfungsnachweises [37]. Anwendungshinweis 1: Der Begriff VSDM Fachdienst umfasst im Rahmen dieses Security Targets auch den Intermediär VSDM. Dieses bedeutet, dass bei einer Beschreibung einer Kommunikation des EVG mit dem VSDM Fachdienst stets die Tatsache berücksichtigt wurde, dass der EVG nur mit dem Intermediär VSDM kommuniziert und nicht direkt mit dem Fachdienst VSDM Security Target secunet konnektor 2.1.0 secunet Seite 19 von 424 Unterstützung des zentralen Verzeichnisdienstes Der Konnektor besitzt einen LDAP-Proxy und unterstützt die Nutzung des zentralen Verzeichnisdienstes der TI. Sichere Kommunikation zur ePA Fachanwendung Der EVG bietet einen sicheren Kanal zur Dokumentenverwaltung des ePA-Aktensystems (VAU-Kanal) und sichere Kommunikation zur Schlüsselableitungen mit den Schlüsselgenerierungsdiensten (SGD-Protokoll) an. 1.3.2. Einsatzumgebung des Konnektors Der EVG besteht aus einem selbständigen Gerät (Konnektorgerät) und wird in der Einsatzumgebung der Leistungserbringer (LE) verwendet. Das Konnektorgerät wird im Betrieb vor physischen Zugriff geschützt (siehe auch A.NK.phys_Schutz bzw. A.AK.phys_Schutz). Die Betriebsumgebung des EVG ist ein geschützter Einsatzbereich. Die Einsatzumgebung des Konnektors als Einbox-Lösung ist in der folgenden Abbildung 2 dargestellt. Insbesondere wird der Konnektor immer mit einer gSMC-K gemeinsam betrieben, wobei die gSMC-K durch die gematik zugelassen wurde. Dieses ST beschreibt die so genannte „Einbox-Lösung“. Das bedeutet, dass  Netzkonnektor und Anwendungskonnektor in einer Box integriert sind, und dass  die gSMC-K sicher mit dem Konnektor verbunden ist, so dass kein weiterer Schutz der Verbindung zwischen Konnektor und gSMC-K erforderlich wird. Der physische Zugriff auf die benannten Schnittstellen ist durch A.NK.phys_Schutz bzw. A.AK.phys_Schutz ausgeschlossen. Der logische Schutz der Schnittstellen ist Teil der Sicherheitsfunktionalität, die Gegenstand des EVG ist. Die in Abbildung 2 links vom Transportnetz dargestellten Komponenten befinden sich im lokalen Netz (LAN) des Leistungserbringers und werden als dezentrale Komponenten bezeichnet. Der WAN-Router bzw. die VPN-Konzentratoren und die übrigen rechts bzw. unterhalb vom Transportnetz dargestellten Dienste werden als zentrale Dienste oder zentrale Telematikinfrastruktur-Plattform bezeichnet. Alle Teilkomponenten des Konnektors sind durch dicke schwarze Rahmen gekennzeichnet. Der Netzkonnektor und Anwendungskonnektor inkl. VSDM-Fachmodul (Teile des EVG) sind durch dunkelblaue Färbung kenntlich gemacht. Die gSMC-K als fester Bestandteil des Konnktors (nicht Teil des EVG) ist hellblau dargestellt. Durch die dunkelblaue Färbung wird die physische EVG-Abgrenzung des Konnektors beschrieben. Mit der roten Linie werden zum besseren Verständnis Komponenten zusammengefasst, die in einem gemeinsamen Gehäuse untergebracht sind oder die üblicherweise auf einer gemeinsamen Plattform ablaufen. Die rote Linien beschreibt den physikalisch geschützten Bereich (vgl. A.NK.phys_Schutz bzw. A.AK.phys_Schutz). Neben den dargestellten physischen Verbindungen gibt es logische Kanäle, die über die physischen Verbindungen etabliert werden und zusätzlich geschützt werden (sichere Kanäle). Security Target secunet konnektor 2.1.0 Seite 20 von 424 secunet Diese Verbindungen sind in der Abbildung 2 aus Gründen der Übersichtlichkeit nicht dargestellt. Anwendungshinweis 2: Die Bereiche, die durch die Einsatzumgebung zu schützen sind werden in Abbildung 2 als rote Box dargestellt. In der folgenden Abbildung 2 bedeuten die Abkürzungen (siehe auch Kapitel 7.1 in [16]):  NK: Netzkonnektor (EVG)  AK: Anwendungskonnektor (EVG)  KT (= eHealth KT): Kartenterminal im Gesundheitswesen; in der folgenden Abbildung ist aus Gründen der Übersichtlichkeit stets nur ein Kartenterminal dargestellt  PF: LAN-seitiger bzw. WAN-seitiger Paketfilter. Die spitze Seite des Paketfilter- Symbols zeigt jeweils zu der Seite, von der potentielle Angriffe abgewehrt werden sollen.  Clientsystem-HW: Hardware des Clientsystems. Auf dieser Plattform läuft die Software des Leistungserbringers (z. B. Praxisverwaltungssystem, Apothekenverwaltungs- system, Krankenhaus-Informationssystem).  PVS: Praxis-Verwaltungssystem. Dieser Ausdruck steht stellvertretend auch für Apotheken-Verwaltungssysteme (AVS) oder Krankenhaus-Informationssysteme (KIS). Er bezeichnet den Softwareanteil auf dem Clientsystem. Das Betriebssystem des Clientsystems ist in den folgenden Abbildungen nicht dargestellt.  eGK: elektronische Gesundheitskarte  HBA: Heilberufsausweis  SM-B: Security Module Card Typ B oder HSM-B, Träger der kryptographischen Identität der Institution des Leistungserbringers  gSMC-K: Sicherheitsmodul für den Konnektor  SIS: Sicherer Internet Service  TI Telematikinfrastruktur-Plattform  VSDM: Versichertenstammdatenmanagement (EVG)  VSDD: Versichertenstammdatendienst Security Target secunet konnektor 2.1.0 secunet Seite 21 von 424 Abbildung 2: Einsatzumgebung des Konnektors (Einbox-Lösung) Im betrachteten Fall ist der Konnektor als Einbox-Lösung ausgestaltet, hierbei wird der Anwendungskonnektor vom Netzkonnektor durch einen Paketfilter vor Angriffen aus dem LAN geschützt. Bei der hier als Rechenzentrums-Konnektor bezeichneten Variante handelt es sich um eine typische Lösung für Rechenzentren in Krankenhäusern oder andere Einrichtungen: Netzkonnektor und Anwendungskonnektor laufen in einer gemeinsamen Box ab. Es wird angenommen, dass die Einsatzumgebung des Konnektors diesen vor physischen Angriffen schützt (siehe Annahme A.NK.phys_Schutz bzw. A.AK.phys_Schutz). Es wird angenommen, dass die Clientsysteme nicht oder nur in sicherer Weise an potentiell unsichere Netze (z. B. Internet) angebunden sind. Ferner wird angenommen, dass die Clientsysteme nach dem aktuellen Stand der Technik entwickelt wurden und administriert werden, so dass sie das spezifizierte Verhalten zeigen. Für Details siehe zum Beispiel Annahme A.NK.Betrieb_CS in Abschnitt 3.4. 1.3.3. Schnittstellen des Konnektors 1.3.3.1. Physische Schnittstellen des EVG Anwendungshinweis 3: Der EVG unterstützt alle vom PP [16] erwarteten physischen Schnittstellen und implementiert darüber hinaus herstellerspezifische Schnittstellen wie im Folgenden dargestellt. Der EVG besitzt folgende physische Schnittstellen: PS1 Entfällt aufgrund der Einbox-Lösung. Anmerkung 1. In diesem ST wird die Nummerierung aus dem NK-PP [17] übernommen. Durch die für dieses ST relevante Einboxlösung des Konnektors ist die Identifizierung einer physischen Schnittstelle zwischen Netzkonnektor und dem Anwendungskonnektor nicht relevant. Die Kommunikation beider Konnektorteile beschränkt sich auf die logische Schnittstelle LS1. Security Target secunet konnektor 2.1.0 Seite 22 von 424 secunet PS2 Eine Schnittstelle zum LAN bzw. zum Clientsystem. Über diese Schnittstelle können Clientsysteme oder andere Systeme im LAN mit dem Konnektor kommunizieren. PS3 Eine Schnittstelle zu Datennetzen (WAN), welche als Transportnetz für den Zugang zur Telematikinfrastruktur und SIS dienen. Es wird angenommen, dass diese Datennetze möglicherweise öffentlich zugänglich und Verbindungen mit ihnen nicht notwendigerweise verschlüsselt sind. Da der EVG zwei Netzwerkkarten nutzt, findet eine physische Trennung des LAN- bzw. WAN- Zugangs über die Netzwerkkarten statt. Die mit PS2 bezeichnete LAN- Schnittstelle und die mit PS3 bezeichnete WAN-Schnittstelle fallen nicht in einer physischen Schnittstelle zusammen. Anwendungshinweis 4: Die mit PS2 bezeichnete LAN-Schnittstelle und die mit PS3 bezeichnete WAN-Schnittstelle sind durch separate Netzwerkcontroller physisch getrennt. PS4 Eine Schnittstelle zum Sicherheitsmodul des Netzkonnektors (gSMC-K). Die gSMC-K dient als sicherer Schlüsselspeicher für die kryptographische Identität des EVGs in Form privater Authentisierungsschlüssel und der zugehörigen Zertifikate. Die gSMC-K ist sicher mit dem EVG verbunden. Siehe auch OE.NK.gSMC-K. PS5 Schnittstelle zu einer Signaleinrichtung mit Status LEDs Der EVG verfügt über eine Schnittstelle zu einer Signaleinrichtung mit sieben Status-LEDs zur Anzeige des aktuellen Betriebszustands des Konnektors. Die LEDs sind wie folgt belegt: Power On, Betriebszustand, 2x VPN Verbindungszustand (VPN TI, VPN SIS), Fehlerzustand, Remote Administration, Update verfügbar PS6 Eine USB Schnittstelle. Die USB2.0 Schnittstelle wird für die initialisierung des EVG im Rahmen der TOE Entwicklung verwendet. Im Operativen Betrieb wird diese Schnittstelle nicht verwendet. Es wird angenommen, dass der Zugriff auf diese Schnitstelle auf eine sichere Weise erfolgt (siehe A.NK.phys_Schutz bzw. A.AK.phys_Schutz sowie A.NK.Admin_EVG). PS7 Eine Schnittstelle für den Werksreset. Am Gehäuse ist ein gegen unbeabsichtigte Auslösung gesicherten Reset-Taster angebracht, mit dem ein Werksreset des EVGs ausgelöst werden kann. Schließlich wird die physische Hülle des Konnektors als weitere Schnittstelle betrachtet. Aufgrund der Annahme A.NK.phys_Schutz bzw. A.AK.phys_Schutz werden keine Angriffe über diese Schnittstelle betrachtet. Die Abbildung 3 zeigt die verfügbaren physischen Security Target secunet konnektor 2.1.0 secunet Seite 23 von 424 Schnittstellen des Konnektors sowie deren Zuordnung zu den logischen Schnittstellen. Der Stromanschluss ist keine relevante Schnittstelle im Sinne des zugrundeliegenden PP [16]. Anwendungshinweis 5: Die Schnittstellen sind in Abbildung 2 und Abbildung 3 grafisch dargestellt. 1.3.3.2. Logische Schnittstellen des EVG Anwendungshinweis 6: Der folgende Abschnitt stellt eine Übersicht über die logischen Schnittstellen des EVG samt ihrer Zuordnung zu den in Kapitel 1.3.3.1 beschriebenen physischen Schnittstellen dar. Alle logischen Schnittstellen aus dem PP [16] sind enthalten. Es sind zusätzliche Schnittstellen definiert worden. Der EVG besitzt folgende logische Schnittstellen: LS1 (gelöscht) Anmerkung 2. Die logische Schnittstelle LS1 stellt in Anlehnung an das NK-PP [17] eine Schnittstelle zwischen Netzkonnektor und Anwendungskonnektor dar. Nach PP [16] ist dies für den EVG keine externe Schnittsteller mehr und wurde daher entfernt. LS2 Eine Schnittstelle zu den Clientsystemen, die physisch über das LAN (via PS2) des Leistungserbringers erreichbar sind. LS3 Eine Schnittstelle zu den Fachmodulen, die im Konnektor laufen. Da die Kommunikation innerhalb des Konnektors erfolgt, wird hier keine physische Schnittstelle zugeordnet. LS4 Eine Schnittstelle zur entfernten Telematikinfrastruktur, die mittels eines Virtual Private Networks (VPN) über das Transportnetz (WAN, via PS3) erreicht wird. LS5 Eine Schnittstelle zum SIS, die mittels eines Virtual Private Networks (VPN) über das Transportnetz (WAN, via PS3) erreicht wird. LS6 Eine Schnittstelle zu Fachdiensten, die mittels eines VPN über das Transportnetz (WAN, via PS3) erreicht werden. LS7 Eine Schnittstelle zu PKI- und anderen Diensten (WAN, via PS3). Dazu zählen der TSL-Dienst, der CRL-Download, sowie OCSP-Dienst. LS8 Eine Schnittstelle zum Konfigurationsdienst KSR (WAN, via PS3). LS9 Eine Schnittstelle zu eHealth-Kartenterminals (LAN, via PS2). LS10 Eine Schnittstelle zu Chipkarten außerhalb des EVG, die über eHealth- Kartenterminals angesprochen werden (LAN, via PS2). LS11 Eine Schnittstelle zu lokalen Managementfunktionen (Software/Firmware, TSL- Updates, Firewall-Konfiguration) des Konnektors (via PS2). Security Target secunet konnektor 2.1.0 Seite 24 von 424 secunet LS12 Eine Schnittstelle zu einem Sicherheitsmodul für den Konnektor (gSMC-K) (via PS4). LS13 Eine Schnittstelle zu entfernten Managementfunktionen für den Konnektor gemäß Konnektor-Spezifikation [27], Abschnitt 4.3.8 (via PS2). LS14 Eine Schnittstelle zur Signaleinrichtung zur Anzeige von Hinweisen an den Administrator über kritische Betriebszustände des Konnektors gemäß Konnektor- Spezifikation [27], Abschnitt 3.3 (via PS5). LS15 Eine USB-Schnittstelle (via PS6) zur initialisierung des EVG. Im Operativen Betrieb wird diese Schnittstelle nicht verwendet und daher nicht weiter betrachtet. Insbesondere werden keine Bedrohungen in Bezug auf diese Schnittstelle betrachtet, da die Schnittstelle aufgrund der Annahmen an die Zugänglichkeit als sicher zu betrachten ist (siehe A.NK.phys_Schutz bzw. A.AK.phys_Schutz sowie A.NK.Admin_EVG) LS16 Eine Schnittstelle zum Auslösen des Werksreset (via PS7). Im Folgenden werden keine Bedrohungen in Bezug auf diese Schnittstelle betrachtet, da die Schnittstelle aufgrund der Annahmen an die Zugänglichkeit als sicher zu betrachten ist (siehe A.NK.phys_Schutz bzw. A.AK.phys_Schutz sowie A.NK.Admin_EVG) LS17 Eine Schnittstelle zur Vertrauenswürdige Ausführungsumgebung (VAU) der Fachanwendung ePA LS18 Eine Schnittstelle zu den Schlüsselgenerierungsdiensten SGD1 und SGD2 für die Nutzung der Fachanwendung ePA. Das lokale und entfernte Management des Netzkonnektors erfolgt über die LAN- Schnittstelle die vom Netzkonnktor bereitgestellt werden. Security Target secunet konnektor 2.1.0 secunet Seite 25 von 424 Abbildung 3: Konnektor: externe, physische und logische Schnittstellen 1.3.4. Aufbau und physische Abgrenzung des Konnektors Eine grobe Abgrenzung des Konnektors von den übrigen Teilen des Telamtik Infrastruktur erfolgte bereits in Abschnitt 1.3. Anwendungshinweis 7: Die Abbildung 4, Abbildung 5, Abbildung 6 und Abbildung 7 stellen das allgemeine Architekturkonzept des Konnektors dar (EVG). LS15 LS2, LS9, LS10, LS11, LS13 LS4, LS5, LS6, LS7, LS8, LS17, LS18 LS12 EVG: Konnektor (Anwendungskonnektor und Netzkonnektor) PS6: USB2.0 Anschluss PS5: Status-LEDs Strom Bi-direktional Uni-direktional PS4: gSMC-K Schnittstelle PS2: Netzwerkanschluss LAN PS3: Netzwerkanschluss WAN LS14 LS16 PS7: Taster für Werksreset Fachmodule LS3 Security Target secunet konnektor 2.1.0 Seite 26 von 424 secunet Abbildung 4: Konnektor Architekturkonzept (schematisch) Abbildung 5: Konnektor Architektur Komponentenansicht (schematisch) Security Target secunet konnektor 2.1.0 secunet Seite 27 von 424 Abbildung 6: Netzkonnektor Komponenten (Der TLS-Basisdienst wird im Anwendungskonnektor umgesetzt, ist aber formal dem Netzkonnektor zugeordnet) Abbildung 7: Anwendungskonnektor Komponenten (Der Sichere Datenspeicher wird im Netzkonnektor umgesetzt, ist aber formal dem Anwendungskonnektor zugeordnet) Architekturübersicht  Die Hardware stellt die Basis des Netzkonnektors dar. Die Funktionalität der Hardware wird aus dessen Sicht als IT-Umgebung betrachtet (z. B. stellt diese die Echtzeituhr im Sinne von OE.NK.Echtzeituhr bereit). Diese Plattform des Konnektors stellt dem EVG eine Ausführungsumgebung zur Verfügung, die die von ihm verarbeiteten Daten vor dem Security Target secunet konnektor 2.1.0 Seite 28 von 424 secunet Zugriff durch Dritte (andere Programme, Prozesse, IT-Systeme o. ä.) schützt. Die Funktionalität der Hardware ist nicht Teil des EVG.  Der Netzkonnektor basiert auf einem gehärteten Linux-Kernel. Dieser bildet mit seinen Gerätetreibern die Hardwareabstraktionsschicht und setzt direkt auf der Hardware auf. Weiterhin enthält der Linux- Kernel Anteile des VPN Clients, stellt die Routing- und Firewall- Funktionen des Netzkonnektors bereit und bindet ein Cryptographic File System (CFS) als sicheren Speicher ein. Auf dem Kernel läuft eine spezielle Oracle VirtualBox als Hypervisor, die eine virtuelle Maschine (VM1) als Ausführungsumgebung für den Anwendungskonnektor bereitstellt. Zudem sind die Dienste des Netzkonnektors im Basissystem beheimatet. Die beschriebene Funktionalität bildet den EVG.  Die virtuelle Maschine VM1 enthält den Anwendungskonnektor, der aus Basiskonnektor, Management-Modul und den Fachmodulen besteht. Weiterhin ist der Signaturdienst in dieser VM beheimatet. Der Fachmodulkonnektor ergibt sich aus den für Fachmodule vorgesehenen Schnittstellen des Basiskonnektors und des Netzkonnektors. Als Betriebssystem in VM1 kommt ein minimalisiertes Linux zum Einsatz. Die beschriebene Funktionalität bildet den EVG. Die virtuelle Maschine VM2 ist optional und für Erweiterungen vorgesehen.  Für die Entwicklung weiterer Fachmodule wird ein ‚Konnektor-API‘ (linke Seite in Abbildung 5) als Schnittstelle standardisiert. Diese bietet die Funktionen des Fachmodulkonnektors (und damit auch des Basiskonnektors), der Signaturdienst und des Management- Moduls an. Bis auf den Ablageort der digital signierten Konnektor- Firmware ist der gesamte Persistenzspeicher des Konnektors durch das vom Netzkonnektor bereitgestellte CFS verschlüsselt. Die beschriebene Funktionalität ist nicht Teil des EVG. Alle benannten Teile des Konektor befinden sich wie in Abbildung 2 angezeigt innerhalb eines Gehäuses. Die physische Abgrenzung des Netzkonnetors ist durch die „Einbox-Lösung“ des Konnektors definiert. 1.3.5. Logische Abgrenzung: Vom EVG erbrachte Sicherheitsdienste Der EVG bestehend aus den Komponeneten Netzkonnektor und Anwendungskonnektor erbringt die im Folgenden beschriebene Sicherheitsfunktionalität. 1.3.5.1. Vom Netzkonnektor erbrachte Sicherheitsdienste Der EVG erbringt seine Sicherheitsdienste über die in der Konnektor-Spezifikation [27] definierten Schnittstellen weitgehend automatisch. Die Abbildung 6 zeigt die architektonische Aufteilung der im Folgenden beschreibenden Sicherheitsdienste des Netzkonnektors. Security Target secunet konnektor 2.1.0 secunet Seite 29 von 424 Anwendungshinweis 8: Authentisierung des Administrators: Der EVG sieht einen gemeinsamen Administrator-Account für NK und AK vor. Die Authentisierung des Konnektor-Administrators wird vom Managementmodul des AKs vorgenommen. Der AK setzt nach erfolgreicher Authentisierung den Authentisierungszustand und autorisert auf diese Weise die Zugriffe des Administrators. Es wird keine zusätzliche Authentisierung zwischen den Konnektorteilen (NK und AK) durchgeführt. Der Authentisierungszustand ist Aufgrund der Annahme A.NK.phys_Schutz vor Manipulation abgesichert. Anwendungshinweis 9: Vollständigkeit der Dienste: Die Dienste des EVGs wurden aus [16] bzw. aus dem NK-PP [17] übernommen und entsprechend der dort verankerten Freiheitsgrade präzisiert. Anwendungshinweis 10: Transaktionssicherheit: Der Netzkonnektor gewährleistet keine Transaktionssicherheit. Soweit Transaktionssicherheit aus Sicherheitsgründen erforderlich ist, wird sie im Clientsystem und/oder in der zentralen Telematikinfrastruktur-Plattform hergestellt. Der EVG erbringt gemäß [16] bzw. NK-PP [17] folgende Sicherheitsdienste: VPN-Client: Der EVG stellt einen sicheren Kanal (virtual private network, VPN) zur zentralen Telematikinfrastruktur-Plattform (TI-Plattform) zwecks Nutzung von Diensten bereit. Der sichere Kanal zur TI wird zur Kommunikation zwischen Anwendungskonnektor und Fachdiensten, Netzkonnektor und zentralen Diensten sowie zwischen Clientsystemen und Bestandsnetzen genutzt. Ferner stellt der EVG einen sicheren Kanal (VPN) zum SIS her. Dieser Kanal dient der Verbindung der lokalen Netzwerke der Leistungserbringer mit dem Internet. a) Der EVG erzwingt die Authentisierung des Kommunikationspartners (VPN- Konzentrator und SIS) und ermöglicht eine Authentisierung gegenüber diesen Partnern; diese erfolgt auf der Basis von Standard IPsec und mit Hilfe von Zertifikaten nach dem Standard X.509v3. Siehe auch Sicherheitsdienst Gültigkeitsprüfung von Zertifikaten. Der Netzkonnektor authentisiert sich gegenüber den genannten Kommunikationspartnern mittels Schlüsselmaterial, das sich auf einem Sicherheitsmodul gSMC-K befindet. b) Die Nutzdaten, die über das VPN übertragen werden, werden hinsichtlich ihrer Vertraulichkeit und Datenintegrität geschützt (Verschlüsselung und Integritätsschutz der Daten vor dem Versenden bzw. der Entschlüsselung und der Integritätsprüfung nach dem Empfangen). Dazu wird für die VPN-Verbindung ein Sitzungsschlüssel vereinbart. Der Netzkonnektor erzwingt die Benutzung des VPN-Tunnels für den Versand von Daten zur zentralen Telematikinfrastruktur-Plattform und den darüber zugänglichen Netzen und verbietet ungeschützten Zugriff auf das Transportnetz. Der Konnektor kann nicht verhindern, Security Target secunet konnektor 2.1.0 Seite 30 von 424 secunet dass ein Leistungserbringer zu schützende Daten der TI und der Bestandsnetze absichtlich preisgibt6, aber er muss ihre versehentliche Preisgabe verhindern. Dynamischer Paketfilter: Der EVG bindet die Clientsysteme sicher an die Telematikinfrastruktur, den SIS und die Bestandsnetze (über die TI) an. Dazu verfügt der EVG über die Funktionalität eines dynamischen Paketfilters, welcher entsprechende Regeln umsetzen kann. Der EVG schützt das lokale Netz des Leistungserbringers vor Angriffen aus dem Transportnetz und sich selbst vor Angriffen aus dem Transportnetz und dem lokalen Netz des Leistungserbringers. Hierbei werden Angriffe mit hohem Angriffspotential abgewehrt. Der EVG beschränkt den freien Zugang zu dem und von dem als unsicher angesehenen Transportnetz. Die Inhalte der Kommunikation zur Telematikinfrastruktur werden von Netzkonnektor nicht ausgewertet. In jedem Fall unterbindet der Netzkonnektor direkte Kommunikation (außerhalb von VPN- Kanälen) ins Transportnetz (WAN, Internet) mit Ausnahme der für den VPN- Verbindungsaufbau erforderlichen Kommunikation7 sowie Verbindungen zum CRL Download Server. Anwendungshinweis 11: Der LAN-seitiger Paketfilter hindert Schadsoftware, die möglicherweise auf anderen Wegen (z. B. Wechseldatenträger wie CD, DVD, USB-Stick, Diskette) in die IT-Systeme im LAN des Leistungserbringers kommt daran, die Integrität des Konnektors zu bedrohen. Anwendungshinweis 12: Der Netzkonnektor enthält kein Application Layer Gateway. Der Anwendungskonnektor wird topologisch von beiden Seiten von einem Paketfilter umgeben (LAN-seitig und WAN-seitig, d.h. gegenüber dem Clientsystemnetz und gegenüber dem Transportnetz; siehe auch Abbildung 2). TLS-Basisdienst: Der EVG stellt Basisdienste für den Aufbau von TLS-Kanälen zur Verfügung und ermöglicht eine Authentisierung der Kommunikationspartner. Siehe auch Sicherheitsdienst Gültigkeitsprüfung von Zertifikaten 6 Beispielsweise könnte ein HBA-Inhaber zu schützende Daten der TI und der Bestandsnetze von einem Clientsystem auch lokal auf Wechseldatenträger kopieren. 7 Das betrifft insbesondere DNS-Anfragen zur Auflösung der Adresse des VPN Konzentrators sowie Protokolle zum Aufbau des VPN-Tunnels (IKEv2) Security Target secunet konnektor 2.1.0 secunet Seite 31 von 424 Anwendungshinweis 13: Hinweis: Die Entscheidung, für welche Verbindungen diese TLS-Kanäle genutzt werden, liegt beim Anwendungskonnektor. Der TLS-Basisdienst wird durch den Netzkonnektor umgesetzt. Formal ist diese Komponente dem Anwendungskonnektor zugeordnet. Der EVG bietet folgende netzbasierte Dienste an: Zeitdienst: Der Netzkonnektor stellt einen NTP-Server der Stratum-3-Ebene für Fachmodule und Clientsysteme bereit, welcher die Zeitangaben eines NTP Servers Stratum-2-Ebene der zentralen Telematikinfrastruktur-Plattform in regelmäßigen Abständen abfragt. Der EVG kann die synchronisierte Zeit anderen Komponenten des Konnektors zur Verfügung stellen. Die vom EVG bereitgestellte Zeit-Information wird für die Prüfung der Gültigkeit von Zertifikaten genutzt, und um die Audit-Daten des Sicherheits-Logs mit einem Zeitstempel zu versehen. Anwendungshinweis 14: Der EVG implementiert eine Plausibilitätskontrolle der vom Zeitdienst übermittelten Zeit (maximale Abweichung), siehe FPT_STM.1/NK (Siehe auch Konnektor-Spezifikation [27], Anforderung 352 TIP 1 A 4788). Die Zeitsynchronisation erfolgt ausschließlich mit Servern innerhalb der zentralen Telematikinfrastruktur-Plattform, d.h. über einen VPN-Konzentrator für den Zugang zur Telematikinfrastruktur. DHCP-Dienst: Der EVG stellt an der LAN-Schnittstelle (PS2) die Funktion eines DHCP Servers gemäß RFC 2131 [66] und RFC 2132 [67] zur Verfügung. DNS-Dienst: Der EVG stellt an der LAN-Schnittstelle (PS2) und an der Schnittstelle zum Anwendungskonnektor (LS1) die Funktion eines DNS-Servers zur Verfügung. Gültigkeitsprüfung von Zertifikaten: Der EVG überprüft die Gültigkeit der Zertifikate des Kommunikationspartners, die für den Aufbau eines VPN-Kanals verwendet werden.8 Zu diesem Zweck wird eine TSL (Trust- Service Status List) verteilt, welche Zertifikate von Diensteanbietern enthält, die Gerätezertifikate ausstellen können. Der EVG kann anhand der aktuell gültigen TSL die 8 Die Überprüfung des Zertifikats des EVG erfolgt durch den Kommunikationspartner. Eine Überprüfung der eigenen, für den Aufbau eines VPN Kanal verwendeten Zertifikate durch den EVG ist nicht erforderlich. Security Target secunet konnektor 2.1.0 Seite 32 von 424 secunet Gültigkeit der Gerätezertifikate seiner Kommunikationspartner prüfen. Ferner wird eine zugehörige CRL (Certificate Revocation List) bereitgestellt, die der EVG ebenfalls auswertet. Außerdem überprüft der EVG, dass die verwendeten Algorithmen gültig sind. Siehe auch Sicherheitsdienst VPN-Client (a): Authentisierung der Kommunikationspartner). Anwendungshinweis 15: Der EVG führt keine explizite Prüfung der Algorithmen auf deren Gültigkeit gegenüber den Vorgaben in TR-03116-1[19] durch. Die Verwendung von gültigen Algorithmen wird durch das Aufbringen eines korrekten und evaluierten Softwarestandes des EVG unter Nutzung des sicheren Updatemechanismus sichergestellt. Stateful Packet Inspection: Der EVG kann nicht-wohlgeformte IP-Pakete erkennen und implementiert eine zustandsgesteuerte Filterung (stateful packet inspection). Anwendungshinweis 16: Der Konnektor realisiert kein netzwerkbasiertes Intrusion Detection System (IDS) für das Clientsystemnetz. Darüber hinaus implementiert der EVG folgende übergeordnete Dienste: Selbstschutz: Der EVG schützt sich selbst und die ihm anvertrauten Daten durch zusätzliche Mechanismen, die Manipulationen und Angriffe erschweren. Der EVG schützt Geheimnisse (insbesondere Schlüssel) während ihrer Verarbeitung gegen unbefugte Kenntnisnahme. Speicheraufbereitung: Der EVG löscht nicht mehr benötigte kryptographische Schlüssel (insbesondere session keys für die VPN-Verbindung) nach ihrer Verwendung durch aktives Überschreiben. Selbsttests: Der EVG bietet seinen Benutzern eine Möglichkeit, die Integrität des EVGs zu überprüfen. Protokollierung: Der EVG führt ein Sicherheits-Log (security log) in einem nicht-flüchtigen Speicher, so dass es auch nach einem Neustart zur Verfügung steht. Der für das Sicherheits-Log reservierte Security Target secunet konnektor 2.1.0 secunet Seite 33 von 424 Speicher ist hinreichend groß dimensioniert. Die zu protokollierenden Ereignisse orientieren sich an der Konnektor-Spezifikation [27]. Anwendungshinweis 17: Eine (über die Anforderungen der Konnektorspezifikation [27] hinausgehende) Auswertung des Sicherheits-Logs durch den Netzkonnektor erfolgt nicht. Anwendungshinweis 18: Die geschützte Speicherung des Protokolls (u. a. zyklisches Überschreiben, Schutz gegen Manipulation durch den Administrator) wird im PP [16] als übergreifende Funktionalität von NK und AK gefordert (siehe auch FAU_STG.1/AK und FAU_STG.4/AK). Administration: Der EVG ermöglicht ein Management (Administration) nach Autorisierung des Administrators. Der Konnektor setzt eine übergreifende Adminsitratorrolle um. Die Authentisierung des Konnektor-Administrators wird vom Anwendungskonnektor vorgenommen. Der EVG bietet eine lokale und entfernte Managementschnittstelle an. Anwendungshinweis 19: Der EVG bietet die Möglichkeit eines sicheren SW/FW/Konfigurations- und TSL-Updates über die Managementsschnittstellen an. Weitere Managementfunktionen werden gemäß FMT_MTD.1.1/NK umgesetzt. Eine Möglichkeit zur Fernwartung ist gemäß Konnektor-Spezifikation [27], Abschnitt 4.3 implementiert. Zur Absicherung der Fernwartung werden dieselben Mechanismen verwendet wie zur Absicherung der lokalen Administration an der LAN-Schnittstelle (sicherer Kanal zwischen Administrator-Arbeitsplatz und Netzkonnektor siehe FTP_TRP.1/NK.Admin, Autorisierung des Administrators siehe FIA_UAU.1/NK.SMR). Es ist jedoch zu beachten, dass laut Konnektorspezifikation (Kapitel 4.3.8) bei einer Managementverbindung über die WAN Schnittstelle der Verbindungsaufbau immer vom Konnektor ausgeht. Der EVG erzwingt eine sichere Authentisierung des Administrators vor administrativen Aktivitäten. Die Authentisierung wird durch den Anwendungskonnektor durchgeführt. Die Zugriffskontrolle (nur authentisierte Administratoren dürfen administrative Tätigkeiten und Wartungsarbeiten durchführen) ist Sicherheitsfunktionalität von Netzkonnektor und Anwendungskonnektor. Secure System Update: Der EVG ermöglicht das sichere Einspielen von Softwareupdates und stellt dabei die Authentizität und Integrität der Update-Daten sicher. Dabei können die Softwareanteile des Netzkonnektors und des Anwendungskonnektors aktualisiert werden. Security Target secunet konnektor 2.1.0 Seite 34 von 424 secunet 1.3.5.2. Vom Anwendungskonnektor erbrachte Sicherheitsdienste Über die im vorigen Abschnitt 1.3.5.1 genannten Dienste hinaus bietet der EVG-Teil Anwendungskonnektor folgende Sicherheitsdienste an: Signaturdienst: Der EVG ermöglicht im Sinne der eIDAS-VO [12] die Erstellung und Prüfung qualifizierter elektronischer Signaturen (QES). Zudem wird die Erstellung und Prüfung von nichtqualifizierten elektronischen Signaturen (nonQES) ermöglicht. Bei der Signaturerstellung sind sowohl Einzelsignaturen als auch Stapelsignaturen und Komfortsignaturen möglich. Als qualifizierte Signaturerstellungseinheit (QSEE) kommt für QES ein Heilberufsausweis (HBA) mit QES-Signaturschlüsseln zum Einsatz. Für die Erzeugung der nonQES-Signatur wird ein HBA oder die SM-B9 mit non-QES- Signaturschlüsseln verwendet. Für die Beschreibungen in dem vorliegenden Schutzprofil wird der Begriff der Signaturrichtlinie benutzt. Eine Signaturrichtlinie ist ein Satz von Regeln, wie die Daten zu signieren bzw. zu prüfen sind, und umfasst alle Parameter, die für die Signaturerstellung, bzw. Signaturprüfung der signierten Daten nach dem identifizierten Standard notwendig sind. Eine genauere Beschreibung des Begriffes Signaturichtlinie findet sich in [16], Kapitel 1.3.5.2. Dort findet sich auch ein beispielhafter Ablauf einer qualifizierten Signatur-Erzeugung sowie einer qualifizierten Signatur-Prüfung im Fall der fehlerfreien Ausführung. Anwendungshinweis 20: Die genauen Abläufe sind der Spezifikation Konnektor [27] und den dort referenzierten Dokumenten zu entnehmen. Anwendungshinweis 21: S.o. Verschlüsselungsdienst: Der Verschlüsselungsdienst bietet Schnittstellen zum hybriden und symmetrischen Ver- und Entschlüsseln von Dokumenten an. Im Fall der hybriden Verschlüsselung kann die (asymmetrische) Verschlüsselung für mehrere Identitäten, repräsentiert durch X.509 Zertifikate oder durch öffentliche Schlüssel, erfolgen. Zertifikate werden vor Verwendung auf ihre Gültigkeit geprüft. Bei hybrider Entschlüsselung erfolgt die asymmetrische Entschlüsselung in der entsprechenden Chipkarte. Laut Spezifikation Konnektor [27] werden dazu die Module SM-B, eGK und HBAx unterstützt. Als Bestandteil des Verschlüsselungsdienstes müssen symmetrische Schlüssel erzeugt werden können. Dazu erfüllt der EVG die Anforderungen von TR-03116-1 [19] zur Erzeugung von Zufallszahlen. Der Verschlüsselungsdienst bietet für alle unterstützten Dokumentenformate die hybride und symmetrische Ver- und Entschlüsselung nach dem Cryptographic Message Syntax Standard 9 SM-B schließt SMC-B und HSM-B ein. Security Target secunet konnektor 2.1.0 secunet Seite 35 von 424 (CMS, RFC 5652, [78]) an. Darüber hinaus wird die formaterhaltende hybride Ver- /Entschlüsselung von XML Dokumenten nach [79] unterstützt. Für die verwendeten Algorithmen und deren Konfiguration werden bestehende Standards eingehalten, um eine Interoperabilität zwischen verschiedenen Herstellerimplementierungen zu erreichen. Sicherer Datenspeicher: Der sichere Datenspeicher bildet einen internen Dienst des Konnektors für die dauerhafte Speicherung aller sicherheitskritischen, veränderlichen Benutzerdaten und TSF-Daten, die für seinen Betrieb relevant sind. Ferner stellt der Konnektor den in ihm laufenden Fachmodulen die Nutzung dieses Datenspeichers für deren sensible Daten zur Verfügung. Der sichere Datenspeicher sichert die Integrität, Authentizität und die Vertraulichkeit der in ihm hinterlegten Daten im abgeschalteten Zustand des Konnektors. Nur der Konnektor hat auf diesen Datenspeicher Zugriff. Folgende Daten werden im sichern Datenspeicher abgelegt:  die Konfigurationsdaten des Konnektormanagements,  die Trust Service List,  Konfigurationsdaten der eHealth-Kartenterminals, insbesondere deren Administratorpasswörter,  Daten des Zertifikatsdienstes, insbesondere die Certificate Revocation Lists,  sonstige Konfigurationsdaten des Konnektors. Anmerkung 3. Datenobjekte des SDS mit dem Sicherherheitsattribut „Adminstratorobjekt“ werden vom Konnektor nicht unterstützt. Der Sichere Datenspeicher wird durch das CFS des Netzkonnektors umgesetzt. Formal ist diese Komponente dem Anwendungskonnektor zugeordnet. Gesicherte Kommunikation: Die Absicherung der Kommunikation über die externen Netzwerk-Schnittstellen erfolgt auf niedriger Netzwerk-Schicht (Layer 3: IPsec) oder über Transport Layer Security (TLS) hinsichtlich Vertraulichkeit, Integrität und Authentizität. Folgende Verbindungen müssen durch TLS abgesichert werden:  Verbindungen zwischen dem EVG und Clientsystemen zur Nutzung von Fachanwendungen (in Form von Fachmodulen) oder von Basisdiensten des Security Target secunet konnektor 2.1.0 Seite 36 von 424 secunet Konnektors10 . Der Zugriff von Clientsystemen ist durch die Verwendung von Whitelisting einschränkbar;  Verbindungen zwischen dem EVG und Fachdiensten bzw. deren vorgelagerten Intermediären;  Verbindungen zwischen dem EVG und eHealth-Kartenterminals;  Verbindungen zwischen dem EVG und einem externen Managementsystem;  Verbindungen zwischen dem EVG und dem Konfigurationsdienst.  Verbindungen zwischen dem EVG und dem TSL-Dienst für den Download der BNetzA-VL und deren Hash-Wert. Dazu unterstützt der EVG die Erzeugung und den Export von X.509 Zertifikaten und der zugehörigen privaten Schlüssel sowie den Import von X.509 Zertifikaten TLS Dienst: Basierend auf dem TLS-Basisdienst des Netzkonnektors (s. Abschnitt 1.3.5.1) leistet der Anwendungskonnektor folgende Dienste: Fachmodule auf dem Konnektor müssen gesicherte Verbindungen zu Fachdiensten nutzen können. Dazu dient der EVG als Proxy, der jeweils TLS-Kanäle zwischen Fachmodulen und Fachdiensten bzw. den vorgelagerten Intermediären verwaltet11 . Beim Aufbau dieser TLS-Kanäle wird die Authentizität der Endpunkte durch Verwendung von Zertifikaten überprüft. Bei der Authentisierung gegenüber Fachdiensten kann der Konnektor die Identität einer SMC-B über einen entsprechenden Kanal nutzen. Bei fehlerhafter Authentisierung wird die Verbindung bzw. der Verbindungsaufbau abgebrochen. Terminaldienst: Der Terminaldienst umfasst das Management der im lokalen Netz der Leistungserbringer adressierbaren eHealth-Kartenterminals. Er realisiert die Anmeldung (Pairing) von neu hinzugekommenen bzw. die Abmeldung von entfernten Kartenterminals am Konnektor. Das Pairing neu hinzugekommener Terminals erfolgt über einen zuvor aufgebauten TLS- Kanal und unter Aufsicht eines Administrators: Bei fehlgeschlagener Prüfung des Terminal- Zertifikates beim Aufbau der TLS-Verbindung erfolgt kein Pairing und das Terminal steht nicht zur Verfügung. Im anderen Fall entscheidet der Administrator anhand des an der Managementschnittstelle angezeigten Fingerabdruckes des Terminal-Zertifikates über die Akzeptanz des Kartenterminals. Im Fall einer Zurückweisung dieses Fingerabdruckes wird 10 Abhängig von der Konfiguration des Konnektors können auch Verbindungen erlaubt werden, die nicht per TLS gesichert sind. 11 Siehe auch Sicherheitsdienst „gesicherte Kommunikation“ Security Target secunet konnektor 2.1.0 secunet Seite 37 von 424 das Pairing abgebrochen und das Kartenterminal steht für Dienste des Konnektors nicht zur Verfügung. Verbindungen zu angebundenen Kartenterminals werden durch einen TLS-Keepalive Mechanismus aufrecht erhalten. Der Terminaldienst stellt Informationen über gesteckte Karten für Basisdienste und Fachmodule bereit. Ferner ermöglicht er Zugriffe auf Kartenterminals durch Basisdienste und Fachmodule. Damit können Meldungen zur Anzeige am Display des Terminals veranlasst werden und es können Eingaben des Benutzers am PIN- Pad von Kartenterminals abgefragt werden. Die Managementfunktion der Terminals durch den EVG umfasst auch die Behandlung konkurrierender Zugriffsversuche auf ein Kartenterminal in der Weise, dass ein Terminal einem Vorgang (Transaktion) des EVG exklusiv zur Verfügung gestellt wird, bis der Vorgang abgeschlossen ist. Chipkartendienst: Der Chipkartendienst umfasst das Management aller Chipkarten, die in den vom Konnektor verwalteten eHealth-Kartenterminals gesteckt sind. Damit sind alle gesteckten Karten nicht nur identifizierbar und adressierbar, sie sind auch bezüglich ihrer Art und Funktionalität im Konnektor erfasst. Folgende Karten-Typen werden vom Konnektor unterstützt:  KVK  eGK (Generation 1+ und 2)  HBA (Generation 2) sowie HBA-qSig und ZOD-2.0  SMC-B (Generation 2)  gSMC-KT (Generation 2)  gSMC-K (Generation 2) Die Managementfunktion der Karten durch den EVG umfasst auch die Behandlung konkurrierender Zugriffsversuche auf eine Chipkarte in der Weise, dass ein Karte für einen Vorgang (Session) des EVG exklusiv zur Verfügung gestellt wird, bis der Vorgang abgeschlossen ist. Der Konnektor unterstützt das Remote-PIN-Verfahren im Sinne der BSI TR-03114 [21]. Weiterhin wird die PIN-Überprüfung, das Ändern, Entsperren und die PIN-Statusabfrage unterstützt. Systeminformationsdienst: Der Systeminformationsdienst stellt Ereignisse interner Ereignisquellen des EVG an Basisdienste, Fachmodule und an die bei ihm registrierten Clientsysteme zur Verfügung. Dies erfolgt entweder durch einen Pull-Mechanismus oder Push-Mechanismus. Der Pull-Mechanismus des Systeminformationsdienstes erlaubt die Abfrage von Zuständen oder statischen Informationen durch Fachmodule und Clientsysteme. Zu diesen Zuständen bzw. Informationen gehören (siehe [27], Kapitel 4.1.6): Security Target secunet konnektor 2.1.0 Seite 38 von 424 secunet  Auflistung der verfügbaren Kartenterminals  Auflistung der gesteckten Karten  Auflistung aller HSMs  Ressourcen-Informationen zu einer gewählten Ressource Der Push-Mechanismus des Systeminformationsdienstes stellt Ereignisse interner Ereignisquellen des Konnektors aktiv allen Basisdiensten, Fachmodulen und bei ihm registrierten Clientsystemen zur Verfügung. Diese Zustellung erfolgt unidirektional über eine Netzschnittstelle. Darüber hinaus werden die folgenden Dienste nach [27] umgesetzt: Dienstverzeichnisdienst: Der Dienstverzeichnisdienst liefert dem aufrufenden Clientsystem sowohl Informationen über die Version und Produktkenndaten des Konnektors, als auch die SOAP-Endpunkte, über die das Clientsystem die einzelnen Dienstoperationen erreichen kann. Dokumentenvalidierungsdienst: Der Dokumentenvalidierungsdienst ist ein interner Dienst. Er bietet Schnittstellen zum prüfen von Syntax und Semantik. Dabei werden diejenigen spezifischen Dokumentformate unterstützt, die an den Außenschnittstellen anderer Dienste wie Signatur- und Verschlüsselungsdienst auftreten können. Zugriffsberechtigungsdienst: Der Zugriffsberechtigungsdienst ist ein interner Dienst. Er ermöglicht es, für vom Clientsystem aufgerufene Operationen eine Prüfung auf Zugriffsberechtigung für die von ihnen benötigten Ressourcen durchzuführen. Die Prüfung erfolgt direkt nach Aufruf einer Operation des Konnektors durch das Clientsystem und basiert auf den im Clientaufruf enthaltenen Parametern. Der Zugriffsberechtigungsdienst definiert über ein Informationsmodell die erlaubten Zugriffsmöglichkeiten. Dabei werden im Informationsmodell Mandanten definiert und Clientsysteme sowie die vom Konnektor verwalteten externen Ressourcen (z. B. Kartenterminal mit Slots, Arbeitsplatz mit Signaturproxy, SMC-Bs etc.) zugeordnet. Zertifikatsdienst: Der Zertifikatsdienst bietet eine Schnittstelle zur Überprüfung der Gültigkeit von Zertifikaten an. Dies geschieht auf Grundlage des durch den Vertrauensanker (TSL-CA-Signer-Zertifikat und eine aktuelle, gültige TSL) aufgespannten Vertrauensraums sowie unter Security Target secunet konnektor 2.1.0 secunet Seite 39 von 424 Berücksichtigung von aktuellen Statusinformationen (OCSP, CRL). Die Zertifikatsprüfung wird sowohl für nonQES- als auch für QES-Zertifikate unterstützt. LDAP-Proxy: Der Konnektor ermöglicht es Clientsystemen und Fachmodulen durch Nutzung des LDAP- Proxies Daten aus dem zentralen Verzeichnisdienst der TI-Plattform (VZD) mittels des Lightweight Directory Access Protocol abzufragen. Die Kommunikation erfolgt über das LDAPv3 Protokoll. VSDM Fachmodul: Das Fachmodul VSDM ist integraler Bestandteil des Konnektors und ermöglicht die Onlineprüfung und -aktualisierung der Versichertenstammdaten auf der eGK sowie die Bereitstellung und Pflege der Stammdaten des Versicherten in der Telematikinfrastruktur. Das VSDM Fachmodul ist dazu an die entsprechenden VSDM Fachdienste der TI, wie dem Versichertenstammdatendienst, dem Update Flag Service und dem Card Management System angebunden. VAU-Client: Der Konnektor unterstützt das ePA Fachmodule mit dem Aufbau einer sicheren Verbindung zur Vertrauenswürdigen Ausführungsumgebung (VAU) gemäß VAU- Kommunikationsprotokoll. Dabei wird ein sicherer Kanal auf HTTP-Anwendungsschicht zwischen dem Client und der VAU (Server) aufgebaut. SGD-Client: Der Konnektor unterstützt das ePA-Fachmodul bei der Nutzung der Schlüsselableitungsfunktionalität im Zusammenhang der ePA Fachanwendung. Der Gesamtablauf der Schlüsselableitungsfunktionalität für den Konnektor als Client ist aufgeteilt zwischen Basiskonnektor und Fachmodul. Die kryptographischen Vorgaben (u.a. Durchführung des ECDH, Schlüsselerzeugung, Ver- und Entschlüsselung, Signaturerzeugung und -prüfung) werden dabei durch den Konnektor realisiert. 1.3.6. Non-EVG hardware/software/firmware Der EVG ist die Software des Netzkonnektor und Anwendungskonnektor inklusive UEFI Secure Boot Firmware für einen Einbox-Konnektor. Anwendungshinweis 22: Die Hardware ist nicht Teil des EVGs Security Target secunet konnektor 2.1.0 Seite 40 von 424 secunet Die Hardware des Einbox-Konnektors ist eine komplett geschlossene, passiv gekühlte Appliance ohne Lüftungsöffnungen mit externem Netzteil. Das Gehäuse besitzt die in Kapitel 1.3.3.1 beschriebenen physischen Schnittstellen, insbesondere RJ45-Ports für WAN und LAN Verbindungen, USB-Port und LEDs für die Signaleinrichtung. Im Gehäuse sind die gSMC-Ks des Konnektors verbaut. Als gSMC-Ks werden folgende von der gematik zugelassene gSMC- Ks verwendet: STARCOS 3.6 Health SMCK R1 TCOS Security Module Card - K Version 2.0 Release 1 STARCOS 3.7 gSMC-K R1 TCOS Security Module Card – K Version 2.0 Release 2 verwendet. Je Einbox-Konnektor werden dabei immer identische gSMC-Ks verbaut, die anhand der Identifikationsnummer (ICCSN) ermitteln werden können (siehe Handbuch [110]). In der folgenden Tabelle sind die Mindestanforderungen an die HW Komponenten der Einbox- Konnektor Hardware beschrieben: Komponente Beschreibung CPU x86-64 RAM 8GB Harddisk 16GB Netzwerk Zwei getrennte Netzwerkcontroller für WAN/LAN Smartcard-Leser (für gSMC-K) 3 interne Smartcard-Leser für ID-000 Karten RTC Real Time Clock mit max. Drift von +/- 20ppm Tabelle 2: Mindestanforderungen für Komponenten der Einbox-Konnektor Hardware Security Target secunet konnektor 2.1.0 secunet Seite 41 von 424 2. Postulat der Übereinstimmung 2.1. Common Criteria Konformität Das Security Target wurde gemäß Common Criteria Version 3.1 Revision 5 erstellt. Es wurden funktionale Sicherheitsanforderungen (FPT_EMS.1 und FIA_API.1, siehe Abschnitt 5.) definiert, die nicht in CC Teil 2 [5] enthalten ist. Die Anforderungen an die Vertrauenswürdigkeit wurden ausschließlich aus CC Teil 3 [6] entnommen. Daher ist dieses Security Target: CC Teil 2 [5] erweitert (extended) und CC Teil 3 [6] konform (conformant). 2.2. Security Target-Konformität Dieses Security Target behauptet eine „strict conformance“ Konformität zum Schutzprofil Common Criteria Schutzprofil (Protection Profile), Schutzprofil 2: Anforderungen an den Konnektor, BSI-CC-PP-0098, Version 1.6 vom 30.03.2022, Bundesamt für Sicherheit in der Informationstechnik (BSI) Das NK-PP [17] ist vollständig in diesem Schutzprofil enthalten. 2.3. Paket-Konformität Das Security Target strebt die Vertrauenswürdigkeitsstufe EAL3, erweitert um die Komponenten  AVA_VAN.3 (Resistenz gegen Angriffspotential „Enhanced-Basic“),  ADV_FSP.4 (Vollständige Funktionale Spezifikation),  ADV_TDS.3 (Einfaches Modulares Design),  ADV_IMP.1 (TSF-Implementierung),  ALC_TAT.1 (Wohldefinierte Entwicklungswerkzeuge) und  ALC_FLR.2 (Verfahren für Problemreports) an. 2.4. Begründung der Konformität Das Security Target verwendet funktionale Sicherheitsanforderungen aus CC Teil 2 [5] sowie zwei funktionale Sicherheitsanforderung, die nicht in CC Teil 2 [5] enthalten ist, daher ist das Security Target CC Teil 2 erweitert (extended). Das Security Target verwendet nur Anforderungen an die Vertrauenswürdigkeit aus CC Teil 3 [6], daher ist das Security Target CC Teil 3 konform (conformant). Security Target secunet konnektor 2.1.0 Seite 42 von 424 secunet Da das Security Target keine Konformität zu einem anderen Schutzprofil behauptet, können auch keine Widersprüche zwischen Schutzprofilen im EVG-Typ oder in der Definition des Sicherheitsproblems, der Sicherheitsziele und der Sicherheitsanforderungen auftreten. Das zugrundeliegende Schutzprofil fordert die Vertrauenswürdigkeitsstufe EAL3, wie sie in CC Teil 3 [6] definiert ist, zusammen mit der Komponente AVA_VAN.3, um Schutz gegen „Enhanced-Basic“ Angriffspotenzial zu erreichen. Durch direkte und indirekte Abhängigkeiten der Komponente AVA_VAN.3 werden die Komponenten ADV_IMP.1 und ALC_TAT.1 aufgenommen und die Komponenten ADV_TDS.3 und ADV_FSP.4 augmentiert. Darüber hinaus wurde die Stufe EAL3 noch um die Komponente ALC_FLR.2 augmentiert, die keine Abhängigkeiten besitzt; für die Gründe dazu siehe Abschnitt 6.5. Das Security Target übernimmt die Vertrauenswürdigkeitsstufe des Schutzprofils. Damit sind alle Anforderungen an die Konformität erfüllt. 2.5. ST-Organisation Der Aufbau dieses Security Targets folgt der Gliederung, des zugehörigen Schutzprofils („Schutzprofil 2: Anforderungen an den Konnektor, [16], BSI-CC-PP-0098“. Security Target secunet konnektor 2.1.0 secunet Seite 43 von 424 3. Definition des Sicherheitsproblems In diesem Abschnitt wird zunächst beschrieben, welche Werte der EVG schützt, welche externen Einheiten mit ihm interagieren und welche Objekte von Bedeutung sind. Auf dieser Basis wird danach beschrieben, welche Bedrohungen der EVG abwehrt, welche organisatorischen Sicherheitspolitiken beachtet werden und welche Annahmen an seine Einsatzumgebung getroffen werden. Die Namensgebung der symbolischen Bezeichner für die im Folgenden definierten Bedrohungen, organisatorischen Sicherheitspolitiken sowie der Annahmen folgt der des zugrundeliegenden PP [16]. 3.1. Werte Zu schützende Werte sind zu schützende Informationen, Abläufe (Prozesse) oder dezentrale Ressourcen. Der Schutz erfolgt durch den EVG in Verbindung mit Maßnahmen in der Umgebung. Die Aufteilung in vom EVG bzw. von seiner Einsatzumgebung zu erfüllende Sicherheitsziele erfolgt in Kapitel 4. 3.1.1. Zu schützende Werte Bei den zu schützenden Werten wird zwischen primären und sekundären Werten unterschieden, deren Definition aus [16] übernommen wurde: Primäre Werte sind die ursprünglichen Werte, die auch vor Einführung des EVG bereits existierten. Ein typisches Beispiel für einen primären Wert sind Klartext-Nutzdaten, deren Vertraulichkeit zu schützen ist. Sekundäre Werte sind solche Werte, die durch die Einführung des EVG erst entstehen, durch diesen bedingt werden oder von den primären Werte abgeleitet werden können. Ein typisches Beispiel für einen sekundären Wert sind Schlüssel; etwa solche, die zum Schutz der Vertraulichkeit der Nutzdaten verwendet werden. 3.1.1.1. Durch den Netzkonnektor zu schützende Werte Im Folgenden sind die durch den Netzkonnktor zu schützenden Werte definiert. Diese wurden vollständig aus dem PP [16] entnommen und entsprechen den im Schutzprofil BSI-CC-PP-0097 [17] des Netzkonnektor definierten Werten. Die primären Werte sind in der folgenden Tabelle 3 aufgeführt. Wert zu schützende Eigenschaften des Wertes Erläuterung,  davon abgeleitete Bedrohungen bzw. erforderliche Annahmen zu schützende Daten der TI und der Bestandsnetze Vertraulichkeit, Integrität, Authentizität Zwischen den lokalen Netzen der Leistungserbringer und der zentralen Telematikinfrastruktur-Plattform werden zu schützende Daten der TI und der Bestandsnetze ausgetauscht. Unbefugte dürfen weder Security Target secunet konnektor 2.1.0 Seite 44 von 424 secunet Wert zu schützende Eigenschaften des Wertes Erläuterung,  davon abgeleitete Bedrohungen bzw. erforderliche Annahmen während der Über- tragung zwischen Konnektor und zentraler Telematik- infrastruktur- Plattform (beide Übertragungs- richtungen) Kenntnis dieser Daten erlangen, noch diese Daten unbemerkt manipulieren können. Der Absender von übertragenen Daten muss eindeutig bestimmbar sein.  T.NK.local_EVG_LAN, T.NK.remote_EVG_LAN, T.NK.remote_EVG_WAN, T.NK.remote_VPN_Data, A.NK.AK, T.NK.local_admin_LAN, T.NK.remote_admin_WAN, T.NK.counterfeit, T.NK.Zert_Prüf, T.NK.DNS zu schützende Nutzerdaten während der Übertragung zwischen Konnektor und sicherem Internet Service Vertraulichkeit, Integrität, Authentizität Beim Zugriff auf Internet-Dienste werden Nutzerdaten zwischen den lokalen Netzen der Leistungserbringer und dem sicheren Zugangspunkt zum Internet ausgetauscht. Unbefugte dürfen weder Kenntnis dieser Daten erlangen, noch diese Daten unbemerkt manipulieren können. Der angegebene Schutz der Authentizität bezieht sich auf die Tunnel-Endpunkte, nicht auf die im Tunnel übertragenen Daten.  T.NK.local_EVG_LAN, T.NK.remote_EVG_LAN, T.NK.remote_EVG_WAN, T.NK.remote_VPN_Data, A.NK.AK, T.NK.local_admin_LAN, T.NK.remote_admin_WAN, T.NK.counterfeit, T.NK.DNS zu schützende Daten der TI und der Bestandsnetze im Clientsystem Vertraulichkeit, Integrität Auf den Clientsystemen werden zu schützende Daten der TI und der Bestandsnetze vorgehalten. Unbefugte dürfen weder Kenntnis dieser Daten erlangen, noch diese Daten manipulieren können.  T.NK.remote_EVG_LAN, A.NK.phys_Schutz in der zentralen Telematikinfrastruk- tur-Plattform gespeicherte zu schützende Daten der TI und der Bestandsnetze Vertraulichkeit, Integrität Werden zu schützende Daten der TI und der Bestandsnetze in der zentralen Telematikinfrastruktur- Plattform gespeichert, so dürfen diese, abhängig von ihrem Schutzbedarf (abhängig vom Fachdienst), auch dort nicht unbefugt eingesehen oder unbemerkt verändert werden können.  T.NK.remote_VPN_Data, A.NK.sichere_TI Clientsystem, Anwendungs- konnektor Integrität Manipulierte Clientsysteme oder Anwendungs- konnektoren können dazu führen, dass zu schützende Daten der TI und der Bestandsnetze abfließen oder unautorisiert verändert werden. Security Target secunet konnektor 2.1.0 secunet Seite 45 von 424 Wert zu schützende Eigenschaften des Wertes Erläuterung,  davon abgeleitete Bedrohungen bzw. erforderliche Annahmen Im normalen Betrieb wird davon ausgegangen, dass zu schützende Daten der TI und der Bestandsnetze das Clientsystem nur dann verlassen, wenn sie in die zentrale Telematikinfrastruktur-Plattform oder auf eine eGK übertragen werden sollen. Daher werden zu schützende Daten der TI und der Bestandsnetze nur durch den Anwendungskonnektor bzw. (im Fall von Daten der Bestandsnetze) den Netzkonnektor übermittelt. Ein manipuliertes Clientsystem könnte Kopien der Daten einem Angreifer zugänglich machen oder auch zu schützende Daten der TI und der Bestandsnetze gezielt verändern. Ein manipulierter Anwendungskonnektor (oder Fachmodule) könnte zu schützende Daten der TI und der Bestandsnetze falsch übergeben und so die korrekte Übermittlung durch den Netzkonnektor (über den VPN-Kanal zur Telematikinfrastruktur) verhindern. Auf diese Weise könnte einem Versicherten oder einem Leistungserbringer Schaden zugefügt werden.  T.NK.remote_EVG_LAN, A.NK.Betrieb_AK, A.NK.Betrieb_CS, A.NK.phys_Schutz Systeme der zentralen Telematik- infrastruktur- Plattform Verfügbarkeit Der Anwendungskonnektor kann Syntaxprüfungen und Plausibilisierungen von Anfragen an die zentrale Telematikinfrastruktur-Plattform durchführen und auf diese Weise dazu beitragen, dass weniger nicht wohlgeformte Anfragen an die zentrale Telematikinfrastruktur-Plattform gerichtet werden. Bei diesen Aspekten handelt es sich aber um Bedrohungen der zentralen Telematikinfrastruktur-Plattform und nicht um Bedrohungen des EVG. Außerdem kann der Konnektor nicht für die Verfügbarkeit von Diensten garantieren; daher wird Verfügbarkeit nicht als Sicherheitsziel für den EVG formuliert.  A.NK.kein_DoS, A.NK.Ersatzverfahren Tabelle 3: Primäre Werte Die primären Werte, deren Schutzbedarf und das daraus abgeleitete Bedrohungspotential bzw. erforderlichen Annahmen entsprechen denen aus der Tabelle 1 aus dem NK-PP [17] bzw. aus dem zugrundeliegenden PP [16] Die sekundären Werte sind in der folgenden Tabelle 4 aufgeführt: Security Target secunet konnektor 2.1.0 Seite 46 von 424 secunet Wert zu schützende Eigenschaften des Wertes Erläuterung,  davon abgeleitete Bedrohungen bzw. erforderliche Annahmen zu schützende Daten der TI und der Bestandsnetze im EVG Vertraulichkeit, Integrität Auch während der Verarbeitung im EVG müssen zu schützende Daten der TI und der Bestandsnetze gegen unbefugte Kenntnisnahme und Veränderung geschützt werden.  T.NK.local_EVG_LAN, , T.NK.remote_EVG_LAN, T.NK.remote_EVG_WAN kryptographisches Schlüsselmaterial (während seiner Speicherung im EVG oder Verwendung durch den EVG) Vertraulichkeit, Integrität, Authentizität Gelingt es einem Angreifer, Kenntnis von Schlüsselmaterial zu erlangen oder dieses zu manipulieren, so ist nicht mehr sichergestellt, dass der EVG seine Sicherheitsleistungen korrekt erbringt. Werden Sitzungsschlüssel ausgetauscht, so ist vorher die Authentizität des Kommunikations- partners sicherzustellen.  A.NK.phys_Schutz, T.NK.local_EVG_LAN, T.NK.remote_EVG_WAN, T.NK.remote_EVG_LAN, T.NK.local_admin_LAN, T.NK.remote_admin_WAN, T.NK.counterfeit, T.NK.Zert_Prüf Authentisierungs- geheimnisse (im EVG gespeicherte Referenzdaten und zum EVG über- tragene Verifikationsdaten) Vertraulichkeit Die Vertraulichkeit von Authentisierungs- geheimnissen (z. B. Passwort für Administrator- authentisierung, evtl. PIN für die gSMC-K) ist zu schützen.  A.NK.phys_Schutz, alle Bedrohungen, gegen die O.NK.Schutz wirkt (T.NK.local_EVG_LAN, T.NK.remote_EVG_WAN, T.NK.remote_EVG_LAN, T.NK.local_admin_LAN, T.NK.remote_admin_WAN, T.NK.counterfeit) Management-Daten (während ihrer Übertragung zum EVG) Vertraulichkeit, Integrität und Authentizität Wenn der EVG administriert wird, dürfen die administrativen Datenströme nicht eingesehen oder unbemerkt verändert werden können.  T.NK.local_admin_LAN, T.NK.remote_admin_WAN, T.NK.counterfeit Management-Daten (während ihrer Speicherung im EVG) Integrität Management-Daten (z. B. Konfigurationsdaten) des EVG dürfen nicht unbemerkt verändert werden können, da sonst nicht mehr sichergestellt ist, dass Security Target secunet konnektor 2.1.0 secunet Seite 47 von 424 Wert zu schützende Eigenschaften des Wertes Erläuterung,  davon abgeleitete Bedrohungen bzw. erforderliche Annahmen der EVG seine Sicherheitsleistungen korrekt erbringt.  A.NK.phys_Schutz, alle Bedrohungen, gegen die O.NK.Schutz wirkt (T.NK.local_EVG_LAN, T.NK.remote_EVG_WAN, T.NK.remote_EVG_LAN, T.NK.local_admin_LAN, T.NK.remote_admin_WAN, T.NK.counterfeit) Sicherheits-Log- Daten (Audit-Daten) Integrität, Verfügbarkeit Der EVG muss Sicherheits-Log-Daten generieren, anhand derer Veränderungen an der Konfiguration des EVG nachvollzogen werden können (vgl. O.NK.Protokoll und FAU_GEN.1/NK.SecLog). Niemand darf Sicherheits-Log-Daten löschen oder verändern können. Wenn der für die Sicherheits- Log-Daten vorgesehene Speicherbereich aufgebraucht ist, können die Sicherheits-Log-Daten zyklisch überschrieben werden. Die Sicherheits- Log-Daten müssen auch zum Nachweis der Aktivitäten von Administratoren verwendet werden können.  T.NK.remote_EVG_WAN, T.NK.remote_EVG_LAN, T.NK.local_EVG_LAN, T.NK.local_admin_LAN, T.NK.remote_admin_WAN, T.NK.counterfeit Systemzeit Verfügbarkeit, Gültigkeit Der EVG muss eine gültige Systemzeit vorhalten und diese regelmäßig mit Zeitservern synchro- nisieren. Die Zeit wird für die Prüfung der Gültigkeit von VPN-Zertifikaten sowie für die Erzeugung von Zeitstempeln in Sicherheits-Log- Daten oder Audit-Daten verwendet.  T.NK.TimeSync Tabelle 4: Sekundäre Werte Die sekundären Werte, deren Schutzbedarf und das daraus abgeleitete Bedrohungspotential bzw. erforderlichen Annahmen entsprechen denen aus der Tabelle 2 aus dem NK-PP [17] bzw. aus dem zugrundeliegenden PP [16] Security Target secunet konnektor 2.1.0 Seite 48 von 424 secunet 3.1.1.2. Durch den Anwendungskonnektor zu schützende Werte Die primären Werte sind in der folgenden Tabelle 5 aufgeführt: Wert zu schützende Eigenschaften des Wertes Erläuterung,  davon abgeleitete Bedrohungen und Annahmen Nutzerdaten und Metadaten bei der Übertragung zwischen Clientsystem und EVG Integrität, Authentizität, Vertraulichkeit Die Daten bzw. Dokumente, die von den Clientsystemen im lokalen Netz der Leistungserbringer dem Konnektor zur Bearbeitung übergeben werden bzw. die Ergebnisse der Bearbeitung durch den Konnektor dürfen bei der Übermittlung weder verändert noch unbefugt eingesehen werden. Zudem dürfen sie nur an authentisierte Kommunikationspartner geschickt werden.  T.AK.LAN.CS, T.AK.Mani.Client, T.AK.MissbrauchKarte, T.AK.Fehlbedienung, A.AK.Konnektor Nutzerdaten und Metadaten bei der Übertragung zwischen EVG und Fachdiensten sowie PKI-Diensten der TI Integrität, Authentizität, Vertraulichkeit Die Daten bzw. Dokumente, die vom EVG zur Bearbeitung an Fachdienste übergeben werden, bzw. die Ergebnisse der Bearbeitung durch die Fachdienste dürfen bei der Übermittlung weder verändert noch unbefugt eingesehen werden. Zudem dürfen sie nur an authentisierte Kommunikationspartner geschickt werden. PKI-Daten, die der EVG von PKI-Diensten der TI empfängt, dürfen nicht manipuliert werden.  T.AK.WAN.TI, T.AK.Kanal_Missbrauch, T.AK.Mani.TI, T.AK.Mani.ExternerDienst, A.AK.Konnektor, A.AK.sichere_TI Nutzerdaten und Metadaten bei der Übertragung zwischen EVG und Fachmodulen Integrität, Authentizität, Vertraulichkeit Die Daten bzw. Dokumente, die vom EVG zur Bearbeitung an Fachmodule im Konnektor übergeben werden bzw. die Ergebnisse der Bearbeitung durch die Fachmodule dürfen bei der Übermittlung weder verändert noch unbefugt eingesehen werden. Zudem dürfen sie nur an authentisierte Kommunikationspartner geschickt werden.  T.AK.LAN.CS, A.AK.Konnektor Nutzerdaten und Metadaten innerhalb des EVG Integrität, Vertraulichkeit Die Daten bzw. Dokumente, die innerhalb des EVG bearbeitet, gespeichert oder übertragen werden, dürfen Security Target secunet konnektor 2.1.0 secunet Seite 49 von 424 Wert zu schützende Eigenschaften des Wertes Erläuterung,  davon abgeleitete Bedrohungen und Annahmen nicht unautorisiert verändert oder eingesehen werden.12  T.AK.Mani.EVG, T.AK.Mani.TI, A.AK.Konnektor, A.AK.phys_Schutz VAU-/SGD- Inhaltsdaten Integrität, Authentizität, Vertraulichkeit Nutzerdaten und Metadaten, die vom EVG zur Vearbeitung in die VAU-Instanz des ePA- Aktensystems (betrifft ePA-Metadaten und ePA- Aktenschlüssel) bzw. in das SGD-HSM (betrifft SGD- AES-Schlüssel) übergeben werden, bzw. von diesen empfangen werden, dürfen bei der Übermittlung weder unbemerkt verändert noch unbefugt eingesehen werden. Zudem dürfen sie nur an authentisierte Kommunikationspartner geschickt werden.  OSP.AK.VAUSGD Tabelle 5: primäre Werte des Anwendungskonnektors Die primären Werte, deren Schutzbedarf und das daraus abgeleitete Bedrohungspotential bzw. erforderlichen Annahmen entsprechen denen aus der Tabelle 3 aus dem zugrundeliegenden PP [16] Die sekundären Werte sind in der folgenden Tabelle 6 aufgeführt. Wert zu schützende Eigenschaften des Wertes Erläuterung,  davon abgeleitete Bedrohungen und Annahmen Metadaten und Authentisierungsgeh eimnisse bei der Übertragung zwischen EVG und Kartenterminal Integrität, Vertraulichkeit Die Daten und Authentisierungsgeheimnisse bei der Übertragung zwischen Konnektor und Kartenterminal dürfen bei der Übermittlung weder verändert noch unbefugt eingesehen werden.  T.AK.DTBS, T.AK.VAD, T.AK.LAN.eHKT, T.AK.Kanal_Missbrauch, A.AK.Konnektor Metadaten und Authentisierungs- geheimnisse bei der Bearbeitung im Kartenterminal Integrität, Vertraulichkeit Die Daten und Authentisierungsgeheimnisse während der Bearbeitung und Zwischenspeicherung innerhalb des Kartenterminals dürfen nicht unautorisiert verändert oder eingesehen werden.  T.AK.DTBS, T.AK.VAD, T.AK.Mani.Terminal, A.AK.Konnektor, A.AK.Cardterminal_eHealth 12 Hierzu die Daten bei der Übertragung zur gSMC-K Security Target secunet konnektor 2.1.0 Seite 50 von 424 secunet Wert zu schützende Eigenschaften des Wertes Erläuterung,  davon abgeleitete Bedrohungen und Annahmen Nutzerdaten und Metadaten bei der Übertragung zwischen EVG und (externer) Chipkarte Integrität, Authentizität, Vertraulichkeit Die Daten und Metadaten bei der Übertragung zwischen Konnektor und externer Chipkarte dürfen bei der Übermittlung weder verändert noch unbefugt eingesehen werden. Zudem dürfen sie nur an authentisierte Kommunikationspartner geschickt werden.  T.AK.DTBS, T.AK.VAD, T.AK.Kanal_Missbrauch, A.AK.Konnektor, A.AK.Cardterminal_eHealth, A.AK.SMC, A.AK.QSCD, A.AK.Chipkarteninhaber Nutzerdaten, Authentisierungs- geheimnisse, kryptografische Daten und Metadaten bei der Bearbeitung und Speicherung auf der (externen) Chipkarte Integrität, Vertraulichkeit Die Daten, Authentisierungsgeheimnisse und kryptografische Daten während der Bearbeitung und Speicherung innerhalb der externen Chipkarte dürfen nicht unautorisiert verändert oder eingesehen werden.  T.AK.Mani.Chipkarte, T.AK.MissbrauchKarte, A.AK.SMC, A.AK.QSCD, A.AK.Chipkarteninhaber Kryptografische Daten bei der Bearbeitung bzw. Nutzung oder Speicherung im EVG Integrität, Vertraulichkeit Das im EVG erzeugte, verwendete oder gespeicherte Schlüsselmaterial darf nicht unautorisiert verändert oder eingesehen werden.  T.AK.Mani.EVG, A.AK.Konnektor, A.AK.Env_Arbeitsplatz, A.AK.phys_Schutz Management-Daten bei der Übertragung zum EVG Integrität, Authentizität, Vertraulichkeit Bei der Administration des EVG dürfen administrative Daten während der Übermittlung nicht unbefugt modifiziert oder eingesehen werden. Zudem dürfen nur authentisierte Partner kommunizieren.  T.AK.LAN.CS, T.AK.LAN.Admin, T.AK.Mani.AdminKonsole,A.AK.Konnektor, A.AK.Admin_EVG Management-Daten bei der Speicherung und Bearbeitung im EVG Integrität Management-Daten (z. B. Konfigurationsdaten) des EVG dürfen nicht unbemerkt verändert werden können.  T.AK.Mani.AdminKonsole, T.AK.Fehlbedienung, A.AK.Konnektor, A.AK.Admin_EVG, A.AK.phys_Schutz Authentisierungs- geheimnisse bei der Integrität, Vertraulichkeit Die Vertraulichkeit und Integrität von Authenti- sierungsgeheimnissen (z. B. Passwort für Security Target secunet konnektor 2.1.0 secunet Seite 51 von 424 Wert zu schützende Eigenschaften des Wertes Erläuterung,  davon abgeleitete Bedrohungen und Annahmen Speicherung und Bearbeitung im EVG Administratorauthentisierung, evtl. PIN für die gSMC-K) ist zu schützen.  T.AK.Mani.EVG, A.AK.Konnektor, A.AK.Admin_EVG, A.AK.phys_Schutz Sicherheits-Log- Daten (Audit-Daten) Integrität, Verfügbarkeit Der EVG muss Sicherheits-Log-Daten generieren, anhand derer Veränderungen an der Konfiguration des EVG nachvollzogen werden können. Diese Daten dürfen nicht modifiziert oder unautorisiert gelöscht werden.  A.AK.Konnektor, A.AK.Admin_EVG, A.AK.phys_Schutz Systemzeit Integrität, Verfügbarkeit Der EVG muss eine gültige Systemzeit vorhalten und diese regelmäßig mit Zeitservern synchronisieren.  T.AK.Mani.ExternerDienst, A.AK.Konnektor, A.AK.phys_Schutz Software und Hardware des EVG Integrität Gelingt es einem Angreifer, die Integrität des EVG zu verletzen, so ist nicht mehr sichergestellt, dass der EVG seine Sicherheitsleistungen korrekt erbringt.  A.AK.Konnektor, A.AK.phys_Schutz Tabelle 6: sekundäre Werte des Anwendungskonnektors Die primären Werte, deren Schutzbedarf und das daraus abgeleitete Bedrohungspotential bzw. erforderlichen Annahmen entsprechen denen aus der Tabelle 4 aus dem zugrundeliegenden PP [16] Der für die Signaturerstellung notwendige Signaturschlüssel (SCD13 ) ebenso wie die Authentisierungsreferenzdaten (SRAD14 ) des Signaturschlüssel-Inhabers befinden sich in der qualifizierten Signaturerstellungseinheit (QSEE) und werden durch diese geschützt. 3.1.2. Benutzer des EVG 3.1.2.1. Benutzer des Netzkonnektors Die folgenden Benutzer des Netzkonnektors sind dem Schutzprofil BSI-CC-PP-0098 [16], Kapitel 3.1.2.1 entnommen. In der Einsatzumgebung des EVGs gibt es folgende externe Einheiten: 13 Englisch: signature-creation data 14 Englisch: signatory reference authentication data Security Target secunet konnektor 2.1.0 Seite 52 von 424 secunet Benutzer des Netzkonnektors Beschreibung AK Anwendungskonnektor VPN-TI Entfernter VPN-Konzentrator, der den Zugriff auf die Telematikinfrastruktur vermittelt VPN-SIS Entfernter VPN-Konzentrator, der den sicheren Zugriff auf das Internet realisiert DNS-ext (externer) DNS-Server für den Namensraum Internet Zeit-ext (externer) Zeit-Server des Zugangsnetzproviders CS Clientsystem TSL/CRL Bereitstellungspunkte für TSL und CRL Admin NK-Admin oder auch NK-Administrator: Administrator des Netzkonnektors Angreifer Ein Angreifer Tabelle 7: Benutzer des Netzkonnektors Der Admin authentisiert sich gegenüber dem Konnektor (siehe O.NK.Admin_EVG). Der EVG unterscheidet intern zwischen den drei Administrator-Rollen local administrator, remote administrator und super administrator. Siehe auch Anwendungshinweis 36:. Der Angreifer kann sich sowohl gegenüber dem Netzkonnektor als (gefälschter) VPN- Konzentrator als auch gegenüber einem VPN-Konzentrator als (gefälschter) Netzkonnektor ausgeben. Ersteres wird durch die Bedrohungen T.NK.remote_EVG_WAN, T.NK.remote_EVG_LAN, T.NK.remote_VPN_Data und T.NK.remote_admin_WAN (für den VPN-Tunnel in die Telematikinfrastruktur) abgebildet. Es wird nicht ausgeschlossen, dass auch ein Versicherter oder ein Leistungserbringer als Angreifer auftreten können: Der Versicherte hat keinen direkten Zugriff auf den Konnektor, deshalb wird er hier nicht gesondert modelliert. Außerdem ist er natürlich am Schutz der Werte (Nutzdaten, z. B. medizinische Daten) interessiert. Insofern werden über den Schutz der Werte die Interessen des Versicherten berücksichtigt. Ein Versicherter kann in der Rolle des Angreifers auftreten. Für den Leistungserbringer sind die Leistungen des NK transparent, er arbeitet mit dem Clientsystem. Sofern er Einstellungen des NK verändert, agiert er in der Rolle des NK- Administrators. Deshalb sind Leistungserbringer bzw. HBA-Inhaber nicht gesondert als eigene externe Einheiten modelliert. Auch ein Leistungserbringer könnte grundsätzlich in der Rolle des Angreifers auftreten: Innerhalb des NK gibt es Geheimnisse (z. B. Sitzungsschlüssel des VPN-Kanals), die auch ein Leistungserbringer nicht kennen soll. Versucht ein Leistungserbringer, Kenntnis von diesen Geheimnissen zu erlangen, kann dies als Angriff Security Target secunet konnektor 2.1.0 secunet Seite 53 von 424 betrachtet werden. Beim Leistungserbringer gilt jedoch folgende Einschränkung: Weder der NK noch der Anwendungskonnektor können gegen den Willen eines Leistungserbringers Datenschutzanforderungen durchsetzen, solange Clientsysteme dies nicht unterstützen. Daher werden solche potentiellen Angriffe eines Leistungserbringers hier nicht betrachtet (das Verhindern solcher Angriffe ist nicht Bestandteil der EVG-Sicherheitspolitik). Im Umfeld des Konnektors wird der Leistungserbringer als vertrauenswürdig angesehen, da er üblicherweise auch die Erfüllung des Umgebungsziels OE.NK.phys_Schutz sicherstellen muss. 3.1.2.2. Objekte des Netzkonnektors Die folgenden Benutzer des Netzkonnektors sind dem Schutzprofil BSI-CC-PP-0098 [16], Kapitel 3.1.2.2 entnommen. Es werden die folgenden Objekte betrachtet: Objekte des Netzkonnektors Beschreibung CS-Daten Lokal beim Leistungserbringer (in Clientsystemen im LAN) gespeicherte zu schützende Daten der TI und der Bestandsnetze VPN-Daten-TI zu schützende Daten der TI und der Bestandsnetze während des Transports zwischen NK und VPN-K der Telematikinfrastruktur VPN-Daten-SIS zu schützende Nutzerdaten während des Transports zwischen NK und VPN-SIS TI-Daten Entfernt in den Datenbanken der Telematikinfrastruktur bzw. den Bestandsnetzen gespeicherte zu schützende Daten der TI und der Bestandsnetze Es wird davon ausgegangen, dass die VPN-Daten durch den zwischen NK und VPN-Konzentratoren implementierten sicheren Kanal (d.h. durch das VPN) geschützt werden und dass die TI-Daten nur in verschlüsselter Form gespeichert vorliegen (z. B. eVerordnung) (siehe A.NK.sichere_TI in Abschnitt 3.4). Die Sicherheit der Clientsysteme ist nicht Gegenstand der Betrachtung. 3.1.2.3. Benutzer des Anwendungskonnektors Über die in Abschnitt 3.1.2.1 genannten Benutzer unterscheidet der Konnektor die folgenden Benutzer, d.h. externe Instanzen, die mit dem EVG kommunizieren (vergl. CC Teil 1 [4], Kap. 4). Die für sie handelnden Subjekte sind im Kapitel 6.1.2 beschrieben. Security Target secunet konnektor 2.1.0 Seite 54 von 424 secunet Benutzer des Anwendungskon nektors Beschreibung Sicherheitsattribut Administrator Benutzer für administrative Funktionen des EVG. Der Administrator benutzt eine gesonderte Management- schnittstelle (vergl. [27], Kap. 4.3). Identität des Benutzers: Daten zur Identifizierung des Benutzers mit Administratorrechten. Authentisierungsreferenzdaten: individuelles Passwort des Benutzers mit Administratorrechten oder andere Authentisierungsreferenzdaten gemäß FIA_UAU.5. Clientsystem Komponente mit einem Benutzerinterface für fachliche Funktionalität, die über das LAN des Leistungserbringers mit dem Konnektor verbunden ist. Die Primärsysteme der Leistungs- erbringer sind spezielle Client- systeme und umfassen die Praxis- verwaltungssysteme für Ärzte, Zahnärzte und Psychotherapeuten, die Krankenhausinformations- systeme der Krankenhäuser und die Apothekenverwaltungssysteme der Apotheker und stellen die Anwen- dungsprogramme für die Leistungs- erbringer und Versicherten zur Verfügung. Ohne Nutzung eines TLS-Kanals kann der EVG nicht zwischen einer beliebigen Komponente im LAN und einem Clientsystem unterscheiden. Bei Nutzung eines TLS-Kanals zwischen Clientsystem und Konnektor: Öffentlicher Schlüssel Ohne Nutzung eines TLS-Kanals zwischen Clientsystem und Konnektor: keine Sicherheitsattribute Fachmodul Ein dezentraler Anwendungsanteil der Fachanwendung innerhalb der TI mit sicherer Anbindung an die TI-Plattform unter Nutzung der Schnittstellen- und Ablauf- definitionen der TI-Plattform. ServiceInformation: XML-Datei zur Beschreibung der Dienste des Fachmoduls gemäß ServiceInformation.xsd VPN- Konzentrator der TI Der VPN-Konzentrator der Telematikinfrastruktur ist ein Security Target secunet konnektor 2.1.0 secunet Seite 55 von 424 Benutzer des Anwendungskon nektors Beschreibung Sicherheitsattribut Sammelpunkt für mehrere VPN- Verbindungen. VPN- Konzentrator des SIS Der VPN-Konzentrator der Internetserviceproviders ist ein Sammelpunkt für mehrere VPN- Verbindungen zur Erbringung sicherer Internetdienstleistungen. Benutzer des Clientsystems Der Benutzer des Clientsystems als logische Schnittstelle des EVG. Er wird durch den EVG identifiziert. Der Benutzer des Clientsystems kann durch die korrekte Authenti- sierung gegenüber der zu benutzen- den Chipkarte für die Benutzung des EVG autorisiert werden. Die Gültigkeit einer Autorisierung kann für EVG-Funktionen in Abhängig- keit von der verwendeten Chipkarte konfiguriert werden. Für die qualifizierte elektronische Signatur muss eine Autorisierung des Benutzers für das Signieren eines jeden einzelnen Stapels der Stapelsignatur durch die qualifizierte Signaturerstellungseinheit (HBA) erfolgen. Bei der Komfortsignatur erfolgt die Autorisierung des Benutzers durch den HBA jeweils für eine HBA- Kartensitzung bei Aktivierung des Komfortsignaturmodus. Für jede Signaturerstellung in der HBA- Kartensitzung mittels Komfortsignatur authentisiert sich das Clientsystem dann mit einer eindeutigen Identifikationsnummer. Identität des Clientsystem- Benutzers: Datum zur Identifi- zierung des Benutzers. Diese Identität muss den Chipkarten HBA, SMC-B und ggf. eGK zugeordnet werden können. Autorisierungsstatus: Status der Zuordnung des Benutzers des Clientsystems zu dem Authentisierungsstatus der Chipkarte in Abhängigkeit von der gewünschten Funktion. Werte: - „nicht autorisiert“: Zuordnung nicht durch Chipkarte bestätigt, - „autorisiert“: Zuordnung durch Chipkarte bestätigt. Arbeitsplatz: Identität des gegenwärtigen Arbeitsplatzes des Benutzers. Security Target secunet konnektor 2.1.0 Seite 56 von 424 secunet Benutzer des Anwendungskon nektors Beschreibung Sicherheitsattribut Signierender Inhaber des Signaturschlüssels für die Erstellung einer Signatur. Identität des Signaturschlüssel- Inhabers: Identität des Signaturschlüssel-Inhabers, die im Zertifikat des Signaturschlüssels angegeben ist, das der Signatur zugrunde liegt. eHealth- Kartenterminal eHealth-Kartenterminal im lokalen Netz des Leistungserbringers, das über eine gSMC-KT verfügt und mit dem EVG gepaart wird bzw. ist (s. [38] Kap. 3.7). Identität: Umfasst die - ID.SMKT.AUT der gSMC-KT des eHealth-Kartenterminals, - physische Adresse im LAN-LE. Authentisierungsreferenzdaten: Authentisierungsreferenzdaten zur Authentisierung der eHealth- Kartenterminals zum Aufbau des TLS-Kanals; umfasst das Zertifikat in EF.C.SMKT.AUT der gSMC- KT, die zum Pairing benutzt wurde, und das Pairing-Geheimnis ShS.KT.AUT. Arbeitsplatz: Arbeitsplatz bzw. Arbeitsplätze, denen das eHealth- Kartenterminal zugeordnet ist, mit Angabe, ob es für den Arbeitsplatz lokales oder entferntes eHealth- Kartenterminal ist. Ein eHealth- Kartenterminal kann auch keinem Arbeitsplatz zugeordnet sein. gSMC-KT Chipkarte gSMC-KT als Sicherheitsmodule für eHealth- Kartenterminals Identität: ICCSN Authentisierungsreferenzdaten mit Rollenkennung: öffentlicher Schlüssel in den Zertifikaten - C.SMKT.AUT als gSMC-KT. - C.SMC.AUTD_RPS_CVC mit CHAT als PIN-Sender. Security Target secunet konnektor 2.1.0 secunet Seite 57 von 424 Benutzer des Anwendungskon nektors Beschreibung Sicherheitsattribut Benutzer des EVG am eHealth- Kartenterminal Benutzer des EVG, der das eHealth- Kartenterminal als Benutzerschnittstelle nutzt, d. h. der vom EVG generierte Anzeigen liest und Daten über die Tatstatur des eHealth-Kartenterminals eingibt, die durch das eHealth-Karten- terminal entsprechend den SICCT- Kommandos des EVG verarbeitet werden. Keine eGK Chipkarte, die durch den EVG identifiziert und sich gegenüber dem anderen Chipkarten mit CVC und privaten Schlüssel oder davon abgeleiteten symmetrischen Schlüsseln als eGK gegenüber CMS oder VSDM-Fachdienst authentisiert. Identität: ICCSN Authentisierungsreferenzdaten mit Rollenkennung: - öffentlicher Schlüssel und CHA, bzw. CHAT in dem CVC C.eGK.AUT_CVC als eGK gegenüber anderen Chipkarten, - SK.CMS als eGK gegenüber einem CMS, - SK.VSD als eGK gegenüber einem VSDM-Fachdienst. HBA Chipkarte, die durch den EVG identifiziert und sich gegenüber dem EVG mit CVC und privaten Schlüssel oder davon abgeleiteten symmetrischen Schlüsseln als HBA authentisiert. Der HBA dient als QSEE mit Signaturschlüssel PrK.HP.QES, Träger des Entschlüsselungsschlüssels und PIN-Empfänger. Identität: - ICCSN - eindeutige Referenz des Signaturschlüssel-Inhabers für die zu signierenden Daten und Entschlüsselungsschlüsselinhab ers für zu verschlüsselnde Daten. Authentisierungsreferenzdaten mit Rollenkennung: öffentlicher Schlüssel und ggf. CHA, bzw. CHAT in den Zertifikaten - C.HPC.AUTR_CVC als HBA gegenüber SMC und eGK, - C.HPC.AUTD_SUK_CVCals QSEE für Stapelsignatur und PIN-Empfänger Security Target secunet konnektor 2.1.0 Seite 58 von 424 secunet Benutzer des Anwendungskon nektors Beschreibung Sicherheitsattribut - C.HP.ENC als Träger des dazu gehörigen Entschlüsselungs- schlüssels PrK.HP.ENC. Optionale Authentisierungsreferenzdaten: - PuK.RCA.ADMINCMS.CS.E2 56 des CMS gegenüber einem HBA. - SK.CMS.AES128 bzw. SK.CMS.AES256 und SK.CUP.AES128 bzw. SK.CUP.AES256 zur gegenseitigen Authentisierung zwischen CAMS und HBA. HBAx Sammelbegriff für den HBA, den HBA-qSig und den ZOD-2.0. Identität: - ICCSN - eindeutige Referenz des Signaturschlüssel-Inhabers für die zu signierenden Daten und Entschlüsselungsschlüsselinhab ers für zu verschlüsselnde Daten. SMC-B Chipkarte, die durch den EVG identifiziert und sich gegenüber dem EVG mit CVC und privaten Schlüssel oder davon abgeleiteten symmetrischen Schlüsseln als SMC- B authentisiert. Die SMC-B kann in Übereinstimmung mit den Rechten des Kartenhalters als PIN- Empfänger, Träger des privaten Entschlüsselungsschlüssels, Träger des privaten Signaturschlüssels, des privaten Schlüssels zur CVC- Authentisierung gegenüber der eGK und des privaten Schlüssels zur X.509-Authentisierungsschlüssels gegenüber externen Gegenstellen verwendet werden. Identität: ICCSN Authentisierungsreferenzdaten mit Rollenkennung: öffentlicher Schlüssel und ggf. CHA, bzw. CHAT in den Zertifikaten: - C.SMC.AUTR_CVC als SMC- B gegenüber einer eGK, - C.SMC.AUTD_RPE_CVC als SMC-B und PIN-Empfänger - C.HCI.AUT X.509-Zertifikat für die Client-Server- Authentisierung. Optionale Authentisierungsreferenzdaten: - PuK.RCA.ADMINCMS.CS.E2 56 des CMS gegenüber einer SMC-B. Security Target secunet konnektor 2.1.0 secunet Seite 59 von 424 Benutzer des Anwendungskon nektors Beschreibung Sicherheitsattribut - SK.CMS.AES128 bzw. SK.CMS.AES256 und SK.CUP.AES128 bzw. SK.CUP.AES256 zur gegenseitigen Authentisierung zwischen CAMS und SMC-B. HSM-B Hardwaresicherheitsmodul, der durch den EVG identifiziert und sich gegenüber dem EVG mit CVC und privaten Schlüssel als SM-B authentisiert. Der HSM-B wird als Träger des privaten Entschlüs- selungsschlüssels, Träger des privaten Signaturschlüssels, des privaten Schlüssels zur CVC- Authentisierung gegenüber der eGK und des privaten Schlüssels zur X.509-Authentisierungsschlüssels gegenüber externen Gegenstellen verwendet. Ein HSM-B kann mehrere SMC-Bs repräsentieren. Identität: ICCSN Authentisierungsreferenzdaten mit Rollenkennung: öffentlicher Schlüssel und ggf. CHA, bzw. CHAT in den Zertifikaten: - C.SMC.AUTR_CVC als SMC- B gegenüber einer eGK, - C.SMC.AUTD_RPE_CVC als SMC-B und PIN-Empfänger - C.HCI.AUT X.509-Zertifikat für die Client-Server- Authentisierung,. Tabelle 8: Benutzer des Anwendungskonnektors Security Target secunet konnektor 2.1.0 Seite 60 von 424 secunet Benutzer Beschreibung Signaturschlüssel- Inhaber (HBA) Der Signaturschlüssel-Inhaber ist der legitime Benutzer des Signaturschlüssels eines HBA als qualifizierte Signaturerstellungseinheit (Authentisierung mit PIN.QES) Kartenhalter des HBA HBA-Inhaber für alle Funktionen des HBA außer der Signaturfunktion (Authentisierung mit PIN.CH) Kartenhalter der SMC-B Kartenhalter für Funktionen der SMC-B (Authentisierung mit PIN.SMC) Versicherter eGK-Inhaber für die Authentisierung, die Entschlüsselungsfunktion und die Nachrichtenauthentisierung (Authentisierung mit PIN.CH oder Referenz-PIN) KT-Benutzer Benutzer des eHealth-Kartenterminals. Tabelle 9: Benutzer anderer Komponenten in der IT-Umgebung 3.2. Bedrohungen 3.2.1. Gegen den Netzkonnektor gerichtete Bedrohungen 3.2.1.1. Auswahl der betrachteten Bedrohungen Eine Motivation der in Abschnitt 3.2.1.2 beschriebenen Bedrohungen sowie eine Beschreibung der möglichen Angriffspfade ist dem PP [17], Abschnitt 3.3.1 zu entnehmen. Die wesentlichen vom Netzkonnektor abzuwehrenden Bedrohungen sind:  Angriffe aus dem Transportnetz gegen IT-Komponenten des Leistungserbringers oder auch gegen den Netzkonnektor selbst (mit Ziel CS-Daten, siehe T.NK.remote_EVG_WAN und T.NK.remote_EVG_LAN),  Angriffe aus dem Transportnetz auf die Datenübertragung zwischen dem lokalen Netz des Leistungserbringer und der zentralen Telematikinfrastruktur-Plattform (mit Ziel VPN-Daten-TI, siehe T.NK.remote_VPN_Data); hier sind die Vertraulichkeit und Integrität der übertragenen Daten sowie die Authentizität von Sender und Empfänger bedroht.  Angriffe aus dem Transportnetz auf die Datenübertragung zwischen dem lokalen Netz des Leistungserbringer und dem Sicheren Internet Service (mit Ziel VPN-Daten-SIS anzugreifen, siehe T.NK.remote_VPN_Data); hier sind die Vertraulichkeit und Integrität der übertragenen Daten bedroht.  Lokale Angriffe auf die Integrität des Netzkonnektors (siehe T.NK.local_EVG_LAN) mit dem Ziel, dessen Sicherheitseigenschaften zu schwächen oder zu Security Target secunet konnektor 2.1.0 secunet Seite 61 von 424 verändern.Schließlich erlaubt der EVG lokale und entfernte Administration, die ebenfalls das Ziel von Angriffen sein kann (siehe T.NK.local_admin_LAN und T.NK.remote_admin_WAN). 3.2.1.2. Liste der Bedrohungen Ein detaillierte motivation der Bedrohungen findet sich im PP [17], Abschnitt 3.2.1.2. In den folgenden Tabellen werden nur die konkreten Bedrohungen wiedergegeben. Diese wurden unverändert aus dem PP übernommen. T.NK.local_EVG_LAN Ein Angreifer dringt lokal in die Räumlichkeiten des Leistungserbringers ein und greift den Netzkonnektor über dessen LAN-Schnittstelle an. Ziel bzw. Motivation des Angriffs ist es, den Netzkonnektor zu kompromittieren, um im Netzkonnektor gespeichertes kryptographisches Schlüsselmaterial, Management-Daten, Authentisierungsgeheimnisse und zu schützende Daten der TI und der Bestandsnetze im Netzkonnektor in Erfahrung zu bringen,  den Netzkonnektor so zu manipulieren, dass zukünftig vertrauliche zu schützende Daten der TI und der Bestandsnetze und zu schützende Nutzerdaten während der Übertragung kompromittiert werden können, oder  den Netzkonnektor so zu manipulieren, dass zukünftig zu schützende Daten der TI und der Bestandsnetze und zu schützende Nutzerdaten während der Übertragung unbemerkt manipuliert werden können. Für diesen Angriff kann der Angreifer sowohl vorhandene IT-Systeme im LAN des Leistungserbringers nutzen als auch eigene (z. B. Notebook, Netbook, PDA15 , Smartphone/Handy) mitbringen. Nicht vom Anwendungskonnektor generierter direkter Verkehr aus dem LAN könnte an die Telematikinfrastrukturdienste für Dienste gemäß § 291 a SGB V gelenkt werden. Einen Spezialfall dieses Angriffs stellt das Szenario dar, dass ein IT-System im LAN durch lokale Kontamination mit bösartigem Code verseucht wird und danach Angriffe gegen den Netzkonnektor an dessen LAN-seitiger Schnittstelle vornimmt. Lokale Kontamination bedeutet dabei, dass ein lokaler Angreifer den bösartigen Code direkt auf das IT-System im LAN aufbringt, beispielsweise durch Wechseldatenträger (CD, USB-Stick, etc.). Ebenfalls betrachtet werden Angriffe, bei denen ein Angreifer den Netzkonnektor durch manipulierte Aufrufe aus dem Clientsystem-Netz in einen unsicheren Systemzustand zu bringen versucht. 15 Personal Digital Assistant Security Target secunet konnektor 2.1.0 Seite 62 von 424 secunet T.NK.remote_EVG_WAN Ein Angreifer greift den Konnektor aus dem Transportnetz heraus an. Der Angreifer nutzt Fehler des Netzkonnektors aus, um den Konnektor zu kompromittieren – mit allen Aspekten wie in T.NK.local_EVG_LAN beschrieben. Der Angreifer greift den Netzkonnektor unbemerkt über das Netzwerk an, um unautorisierten Zugriff auf weitere Werte zu erhalten. T.NK.remote_EVG_LAN Ein Angreifer greift den Konnektor aus dem Transportnetz bzw. Internet heraus an. Ziel ist wieder eine Kompromittierung des Konnektors, mit allen Aspekten wie bereits in T.NK.local_EVG_LAN beschrieben. Im Gegensatz zur Bedrohung T.NK.remote_EVG_WAN ist das Ziel jedoch nicht, den Netzkonnektor direkt an seiner WAN-Schnittstelle anzugreifen, sondern über den Netzkonnektor zunächst Zugriff auf das lokale Netz des Leistungserbringers (LAN) zu erhalten, um dort ein Clientsystem zu kompromittieren und möglicherweise im Anschluss daran den Konnektor von dessen LAN- Seite her anzugreifen. Die Kompromittierung eines Clientsystems ist gegeben, wenn ein Angreifer aus dem Transportnetz bzw. dem Internet unautorisiert auf personenbezogene Daten im Clientsystem zugreifen kann oder wenn der Angreifer ein Clientsystem erfolgreich und unbemerkt manipulieren kann. Hierzu werden in [17], Abbildung 4 zwei Angriffspfade unterschieden: Im Fall von Angriffspfad 3.1 nutzt der Angreifer Fehler des Netzkonnektors aus, um die vom Netzkonnektor als Sicherheitsfunktion erbrachte Trennung der Netze (Transportnetz / LAN) zu überwinden. Bereits eine Überwindung dieser Trennung stellt einen erfolgreichen Angriff dar. Wird darüber hinaus in der Folge über die LAN-Schnittstelle des Konnektors unerwünschtes Verhalten herbeigeführt, so stellt dies eine erfolgreiche Fortführung des Angriffs dar. Im Fall von Angriffspfad 3.2 nutzt der Angreifer Fehler in der Sicherheitsfunktion des Sicheren Internet Service aus, um über den VPN-Tunnel Zugriff auf IT-Systeme im LAN zu erlangen. Dabei kann auch der Netzkonnektor über dessen LAN Interface angegriffen werden. Einen Spezialfall dieses Angriffs (Angriffspfad 3.1 oder 3.2) stellt das Szenario dar, dass ein IT-System im LAN vom Transportnetz bzw. Internet (WAN) aus mit bösartigem Code verseucht wird und in der Folge Angriffe gegen den Konnektor an dessen LAN-seitiger Schnittstelle vornimmt. Ein IT-System im LAN könnte vom Transportnetz aus mit bösartigem Code verseucht werden, wenn der Netzkonnektor keine effektive Netztrennung16 zwischen WAN und LAN leistet. Betroffene zu schützende Werte sind: 16 Das setzt ein entsprechendes Einsatzszenario des Konnektors voraus, bei dem die Kommunikation zum Internet über den Netzkonnektor erfolgt. Security Target secunet konnektor 2.1.0 secunet Seite 63 von 424  zu schützende Daten der TI und der Bestandsnetze während der Übertragung  zu schützende Nutzerdaten während der Übertragung  zu schützende Daten der TI und der Bestandsnetze im Clientsystem  Clientsystem, Anwendungskonnektor  zu schützende Daten der TI und der Bestandsnetze im Netzkonnektor  kryptographisches Schlüsselmaterial  Authentisierungsgeheimnisse  Management-Daten (während ihrer Speicherung im Netzkonnektor)  Sicherheits-Log-Daten T.NK.remote_VPN_Data Ein Angreifer aus dem Transportnetz hört Daten ab oder manipuliert Daten unbemerkt, die zwischen dem Konnektor und der zentralen Telematikinfrastruktur-Plattform (Angriffspfad 4.2, Abbildung 4 aus [16]) oder zwischen dem Konnektor und dem Sicheren Internet Service (Angriffspfad 4.1, Abbildung 4 aus [16]) übertragen werden. Dies umfasst folgende Aspekte:  Ein Angreifer gibt sich dem Netzkonnektor gegenüber als VPN-Konzentrator aus (evtl. auch man-in-the-middle-Angriff), um unautorisierten Zugriff auf vom Clientsystem übertragene Daten zu erhalten.  Ein Angreifer verändert verschlüsselte Daten während der Übertragung unbemerkt. Betroffene zu schützende Werte sind:  zu schützende Daten der TI und der Bestandsnetze während der Übertragung  zu schützende Nutzerdaten während der Übertragung  in der zentralen Telematikinfrastruktur-Plattform gespeicherte Daten T.NK.local_admin_LAN Ein Angreifer dringt lokal in die Räumlichkeiten des Leistungserbringers ein und verändert (im Rahmen lokaler Administration) sicherheitsrelevante Einstellungen des Netzkonnektors. Dies kann dem Angreifer einerseits dadurch gelingen, dass der Netzkonnektor das Verändern von sicherheitsrelevanten Einstellungen nicht hinreichend schützt (im Sinne einer Zugriffskontrolle), oder andererseits dadurch, dass sich ein Angreifer erfolgreich als Administrator ausgeben und mit dessen Berechtigungen agieren kann (im Sinne einer Security Target secunet konnektor 2.1.0 Seite 64 von 424 secunet Authentisierung/Autorisierung). Ziel des Angreifers kann es sein, Sicherheitsfunktionen des Netzkonnektors zu deaktivieren (z. B. Abschalten der Verschlüsselung auf dem VPN-Kanal oder Erlauben bzw. Erzwingen kurzer Schlüssellängen), die Integrität des Netzkonnektors selbst zu verletzen, Schlüssel auszulesen, um damit Zugriff auf geschützte Daten zu erhalten oder auch die Grundlagen für weiteren Missbrauch zu legen – etwa durch Einspielen schadhafter Software, welche Kopien aller vom Netzkonnektor übertragenen Daten am VPN- Tunnel vorbei zum Angreifer spiegelt. Diese Bedrohung umfasst auch folgende Aspekte:  Ein lokaler Angreifer bringt schadhafte Software auf den Netzkonnektor auf.  Ein lokaler Angreifer greift unautorisiert auf genutzte kryptographische Schlüssel im Arbeitsspeicher des Netzkonnektors zu.  Ein lokaler Angreifer deaktiviert die Protokollierungsfunktion des Netzkonnektors.  Ein lokaler Angreifer spielt ein Backup eines anderen Konnektors ein und überschreibt damit Daten (etwa Konfigurationsdaten).  Ein lokaler Angreifer kann mit modifizierten Konfigurationsdaten beispielsweise per dynamischem Routing den Netzwerkverkehr umleiten. T.NK.remote_admin_WAN Ein Angreifer verändert aus dem Transportnetz heraus sicherheitsrelevante Einstellungen des Netzkonnektors (im Rahmen zentraler Administration). Dies kann dem Angreifer einerseits dadurch gelingen, dass der Netzkonnektor das Verändern von sicherheitsrelevanten Einstellungen nicht hinreichend schützt bzw. an seiner WAN-Schnittstelle verfügbar macht (im Sinne einer Zugriffskontrolle), oder andererseits dadurch, dass sich ein Angreifer erfolgreich als Administrator ausgeben und mit dessen Berechtigungen agieren kann (im Sinne einer Authentisierung/Autorisierung). Der Angreifer verfolgt dieselben Ziele wie unter T.NK.local_admin_LAN besprochen. Diese Bedrohung umfasst auch folgende Aspekte:  Ein Angreifer aus dem Transportnetz bringt schadhafte Software auf den Netzkonnektor auf.  Ein Angreifer aus dem Transportnetz greift unautorisiert auf genutzte kryptographische Schlüssel im Arbeitsspeicher des Netzkonnektors zu.  Ein Angreifer aus dem Transportnetz deaktiviert die Protokollierungsfunktion des Netzkonnektors. Security Target secunet konnektor 2.1.0 secunet Seite 65 von 424 T.NK.counterfeit Ein Angreifer bringt gefälschte Netzkonnektoren in Umlauf, ohne dass dies vom VPN- Konzentrator erkannt wird17 . Der Angriff kann durch den unbemerkten Austausch eines bereits im Einsatz befindlichen Geräts erfolgen – wozu in der Regel ein Eindringen in die Räumlichkeiten des Leistungserbringers erforderlich ist – oder bei der Erstauslieferung durchgeführt werden. Der Angreifer verfolgt dieselben Ziele wie unter T.NK.local_admin_LAN besprochen. Anmerkung: Die Tatsache, dass ein Angreifer gefälschte Netzkonnektoren in Umlauf bringt, ist gleichbedeutend mit dem In-Umlauf-Bringen gefälschter Konnektoren, da der EVG in einer Einbox-Lösung integriert ist. T.NK.Zert_Prüf Ein Angreifer manipuliert Sperrlisten, die im Rahmen der Gültigkeitsprüfung von Zertifikaten zwischen dem EVG und einem netzbasierten Dienst (siehe OE.NK.PKI) ausgetauscht werden (Wert: zu schützende Daten der TI bei der Übertragung), um mit einem inzwischen gesperrten Zertifikat unautorisierten Zugriff auf Systeme und Daten zu erhalten. Ein bereits gesperrtes Zertifikat wird dem EVG gegenüber als noch gültig ausgegeben, indem eine veraltete oder manipulierte Sperrliste verteilt wird. Dazu kann der Angreifer Nachrichten des Sperrlisten-Verteilungspunkt manipulieren oder sich selbst als dieser Verteilungspunkt ausgeben. T.NK.TimeSync Ein Angreifer manipuliert Nachrichten, die im Rahmen der Zeitsynchronisation zwischen dem EVG und einem netzbasierten Dienst (Zeitdienst) ausgetauscht werden, oder gibt sich selbst als Zeitdienst aus, um auf dem EVG die Einstellung einer falschen Systemzeit zu bewirken, oder gibt sich selbst als Zeitdienst aus. T.NK.DNS Ein Angreifer manipuliert aus dem Transportnetz heraus Antworten auf DNS-Anfragen zu externen DNS-Servern. Dies kann einerseits Anfragen des Netzkonnektors betreffen, wenn dieser vor dem Aufbau von VPN-Kanälen die Adresse des VPN-Konzentrators der TI oder des SIS ermitteln will. Im Ergebnis wird keine oder eine falsche Adresse ausgeliefert, so dass der Netzkonnektor ggf. die VPN-Verbindung zu einem gefälschten Endpunkt aufbaut, der 17 Der Netzkonnektor kann seinen eigenen Diebstahl oder das In-Umlauf-Bringen gefälschter Geräte nicht verhindern; die Authentizität des Netzkonnektors muss letztlich der VPN-Konzentrator sicherstellen. Der Netzkonnektor kann aber zum Erkennen solcher Angriffe beitragen, indem er sich gegenüber dem VPN- Konzentrator authentisiert. Daher zielt die Bedrohung T.NK.counterfeit auf das unbemerkte Fälschen bzw. Austauschen von Netzkonnektoren. Security Target secunet konnektor 2.1.0 Seite 66 von 424 secunet beispielsweise eine gefälschte zentrale TI-Plattform vorspiegelt. Dadurch werden die zu schützende Daten der TI und der Bestandsnetze während der Übertragung zwischen Konnektor und zentraler Telematikinfrastruktur-Plattform bedroht. Andererseits können gefälschte DNS- Antworten auch beim Internet-Zugriff von Clientsystemen der Leistungserbringer auftreten. In einem solchen Szenario könnte der Angreifer den Zugriff der Clientsysteme auf manipulierte Systeme umleiten (Wert: zu schützende Nutzerdaten während der Übertragung zwischen Konnektor und sicherem Internet Service), um Clientsysteme mit bösartigem Code zu infizieren, der dann das lokale Netz, den Netzkonnektor und die zu schützenden Werte bedroht. 3.2.2. Gegen den Anwendungskonnektor gerichtete Bedrohungen Über die in Abschnitt 3.2.1 genannten Bedrohungen für den Netzkonnektor hinaus werden die folgenden weiteren Bedrohungen gegen die zu schützenden Werte des Anwendungskonnektors definiert. In den folgenden Tabellen werden die Bedrohungen wiedergegeben. Die Bedrohungen wurden unverändert aus dem PP [17] übernommen. 3.2.2.1. Kommunikation T.AK.LAN.CS Datenübertragung im LAN abhören und/oder manipulieren Ein Angreifer hört im LAN zwischen dem Konnektor (inkl. Fachmodulen) und einem Clientsystem übertragene Daten (zu schützende Daten) ab und erhält so Kenntnis dieser Daten und/oder manipuliert diese Daten. Ein Angreifer gibt sich dem Konnektor (inkl. Fachmodulen) gegenüber als ein rechtmäßiges Clientsystem aus (Vortäuschen einer falschen Identität). Diese Bedrohungen beziehen sich auf die Datenübertragung in beiden Richtungen, also sowohl vom Konnektor (inkl. Fachmodulen) zu einem Clientsystem als auch von einem Clientsystem zum Konnektor (inkl. Fachmodulen). Anwendungshinweis 23: Die komplementäre Bedrohung des Vortäuschens einer falschen Konnektor-Identität gegenüber einem Clientsystem muss durch eine erzwungene Authentisierung des Konnektors durch das Clientsystem abgewehrt werden und stellt somit keine Bedrohung gegen den Konnektor, sondern gegen das Clientsystem dar. Abhängig von dessen Konfiguration kann der Konnektor die Abwehr dieser Bedrohung unterstützen, indem er sich selbst gegenüber Clientsystemen authentisiert. Daher wurde in T.AK.LAN.CS die Formulierung „in beiden Richtungen“ verwendet. T.AK.LAN.Admin Abhören von Daten bei Adminstration Ein Angreifer hört im LAN zwischen dem Konnektor und der Administrationskonsole übertragene Daten ab und erhält so Kenntnis dieser Daten und/oder manipuliert diese Daten Security Target secunet konnektor 2.1.0 secunet Seite 67 von 424 (Management-Daten bei der Übertragung zum EVG). Weiterhin können mitgeschnittene und ggf. modifizierte Daten zu einem späteren Zeitpunkt erneut zum EVG geschickt werden, um auf diese Weise unautorisiert administrative Funktionen des EVG aufzurufen. T.AK.WAN.TI Datenübertragung im WAN abhören und/oder manipulieren Ein Angreifer hört im Transportnetz (WAN) bzw. Zugangsnetz zwischen dem EVG und einem Fachdienst übertragene Daten (zu schützende Daten) ab und erhält so Kenntnis dieser Daten und/oder manipuliert diese Daten. Ein Angreifer gibt sich einem Kommunikationspartner gegenüber als der rechtmäßige andere Kommunikationspartner aus (Vortäuschen einer falschen Identität). Diese Bedrohungen beziehen sich auf die Datenübertragung in beiden Richtungen, also sowohl vom EVG zu einem Fachdienst als auch von einem Fachdienst zum EVG. Anwendungshinweis 24: Analog zu Anwendungshinweis 23: gilt: Die komplementäre Bedrohung des Vortäuschens einer falschen Konnektor-Identität gegenüber einem Fachdienst muss durch den Fachdienst (erzwungene Authentisierung des Konnektors) abgewehrt werden und stellt damit also keine Bedrohung gegen den Konnektor, sondern gegen den Fachdienst dar. Der Konnektor unterstützt jedoch die Abwehr dieser Bedrohung, indem er sich selbst gegenüber dem Fachdienst authentisiert. Daher wurde in T.AK.WAN.TI die Formulierung „in beiden Richtungen“ verwendet. T.AK.Kanal_Missbrauch Missbrauch bestehender Kommunikationskanäle Ein Angreifer kann bestehende Kommunikationskanäle missbrauchen. Ein Angreifer versucht, in bestehende Kommunikationskanäle, etwa zwischen EVG und eHealth- Kartenterminal, zwischen EVG und Chipkarte oder zwischen EVG und Systemen der zentralen TI-Plattform, eigene Daten einzufügen, um unautorisiert Einfluss auf die Funktionalität des EVG oder auf zu schützende Daten zu nehmen. 3.2.2.2. Terminaldienst T.AK.LAN.eHKT Abhören/Manipulieren der Datenübertragung zwischen dem Konnektor und den eHealth-Kartenterminals Ein Angreifer hört im LAN zwischen dem Konnektor und einem eHealth-Kartenterminal übertragene Daten ab oder manipuliert diese Daten. Ein Angreifer gibt sich dem Konnektor gegenüber als ein rechtmäßiges eHealth-Kartenterminal aus (Vortäuschen einer falschen Identität). Diese Bedrohungen beziehen sich auf die Datenübertragung in beiden Richtungen, also sowohl vom Konnektor zu einem eHealth-Kartenterminal als auch von einem eHealth- Security Target secunet konnektor 2.1.0 Seite 68 von 424 secunet Kartenterminal zum Konnektor. Durch diese Bedrohung können Daten der Chipkarten und die Konnektor/eHKT-Kommunikation kompromittiert oder manipuliert werden. 3.2.2.3. Chipkartendienst T.AK.VAD Abhören/Manipulieren von Authentisierungsverifikationsdaten Ein Angreifer versucht die VAD (d.h. die PIN oder PUK) eines Chipkartenbenutzers zu kompromittieren oder zu manipulieren. Ein Angreifer versucht insbesondere, die VAD bei der vom EVG gesteuerten entfernten PIN-Eingabe während der Übertragung zwischen dem PIN-Terminal und der Chipkarten-Terminal oder über das lokale Netz abzuhören oder zu manipulieren. 3.2.2.4. Signaturdienst T.AK.DTBS Einfügen/Manipulieren von zu signierenden Daten Ein Angreifer kann Daten ohne die oder entgegen der Intention des Signaturschlüssel- Inhabers durch die qualifizierte Signaturerstellungseinheit oder andere Chipkarten signieren lassen. Dies kann durch Einfügen, Veränderung oder Ersetzen von zu signierenden Daten in einem Stapel zu signierender Daten bei der Übertragung zwischen Konnektor und Chipkarte (HBA bzw. SMC-B) erfolgen. 3.2.2.5. Manipulation und Missbrauch T.AK.Mani.EVG Manipulation des EVG Ein Angreifer mit Zugriff auf den EVG oder auf Update-Daten für den EVG manipuliert Anteile des EVG, um Zugriff auf zu schützende Daten (Nutzerdaten, Metadaten, kryptographisches Schlüsselmaterial, Authentisierungsdaten) zu erlangen bzw. diese zu modifizieren. T.AK.Mani.Client Manipulation von Clientsystemen Ein Angreifer mit Zugriff auf Clientsysteme manipuliert Clientsysteme, so dass durch unsachgemäße oder unautorisierte Nutzung der Dienste des EVG zu schützende Nutzer- und Metadaten offengelegt oder manipuliert werden können. Der Angriff kann auch durch einen Diebstahl eines Clientsystems oder einen Austausch gegen ein anderes Clientsystem unterstützt werden. Security Target secunet konnektor 2.1.0 secunet Seite 69 von 424 T.AK.Mani.TI Angriff durch manipulierte Systeme der zentralen TI-Plattform Ein Angreifer mit Zugriff auf Systeme in der zentralen Telematikinfrastruktur-Plattform manipuliert Systeme bzw. Fachanwendungen, mit denen der EVG kommuniziert. Dadurch werden sensible Daten wie beispielsweise Kommunikationsschlüssel (Metadaten) oder übertragene zu schützende Daten (Nutzerdaten) kompromittiert. Weiterhin können diese Systeme unautorisierten Zugriff auf den EVG über eine bestehende Datenverbindung erlangen um Zugriff auf dort gespeicherte Nutzer- und Metadaten zu erhalten. T.AK.Mani.ExternerDienst Angriff durch einen manipulierten externen Dienst Ein Angreifer mit Zugriff auf Komponenten externer Dienste, wie etwa dem PKI oder Zeit- Dienst, kann diesen Dienst manipulieren oder verhindern. Damit wird der EVG mit gefälschten PKI- oder Zeit-Informationen versorgt oder die PKI- oder Zeit-Informationen werden komplett blockiert. Dadurch können Sicherheitsdienste des EVG, etwa die Prüfung von Zertifikaten, beeinflusst oder unterbunden werden. T.AK.Mani.Chipkarte Angriff durch manipulierte Chipkarte(n) Ein Angreifer mit Zugriff auf eine verwendete Chipkarte manipuliert diese, um beispielsweise darauf gespeicherte Geheimnisse auszulesen oder mit dem Angreifer bekannten Daten zu überschreiben. Weiterhin kann er auf die Funktion der Karte Einfluss nehmen, um beispielsweise das Ergebnis einer Signaturprüfung zu fälschen. T.AK.Mani.Terminal Manipuliertes Kartenterminal Ein Angreifer mit Zugriff auf eHealth-Kartenterminals manipuliert diese, um unautorisierten Zugang zu Geheimnissen (PIN) zu erlangen oder um sensitive Daten (etwa die Anzeige auf dem Display) zu modifizieren (Wert: Metadaten und Authentisierungsgeheimnisse bei der Bearbeitung im Kartenterminal). T.AK.Mani.AdminKonsole Manipulierte Administrationskonsole Ein Angreifer manipuliert die Administrationskonsole oder setzt ein unautorisiertes System als Administrationskonsole ein. Damit wird unautorisierter Zugriff auf das EVG ermöglicht. In einem weiteren Szenario nutzt ein autorisierter Administrator die manipulierte Konsole und kann damit unbemerkt administrative Funktionen des Angreifers im EVG ausführen. Betroffen sind die Management-Daten bei Übertragung zum und Verarbeitung im EVG. Security Target secunet konnektor 2.1.0 Seite 70 von 424 secunet 3.2.2.6. Bedrohungen in den Betriebsabläufen T.AK.MissbrauchKarte Missbrauch von Chipkarten Ein Angreifer kann die PIN eines autorisierten Benutzer bei der Eingabe ausspähen. Wenn später die Chipkarte gestohlen wird, kann der Angreifer die Karte unautorisiert zum Zugriff auf Funktionalität oder Daten (Nutzerdaten und Metadaten) des EVG verwenden oder sogar Daten auf der Chipkarte modifizieren. T.AK.Fehlbedienung Datenverfälschung oder Fehlkonfiguration durch Fehlbedienung Ein autorisierter Benutzer oder Administrator kann durch Fehlbedienung am Clientsystem bzw. an der Administrationskonsole ungewollte Systemzustände herbeiführen, die zu schützende Daten in ungewollter Weise beeinflussen können. Das kann beispielsweise ein ungewolltes Löschen von Daten bedeuten oder (im Fall des Administrators) das Aktivieren einer ungewollten Konfigurationsoption. Betroffene Werte sind die Nutzerdaten und Metadaten sowie Management-Daten. 3.3. Organisatorische Sicherheitspolitiken 3.3.1. Organisatorische Sicherheitspolitiken des Netzkonnektors In den folgenden Tabellen werden die „Organisatorische Sicherheitspolitiken des Netzkonnektors“ wiedergegeben. Diesen wurden unverändert aus dem PP [17] übernommen. OSP.NK.Zeitdienst Zeitdienst Der EVG stellt einen Zeitdienst bereit. Dazu führt er in regelmäßigen Abständen eine Zeitsynchronisation mit Zeitservern durch. OSP.NK.SIS Sicherer Internet Service Die Einsatzumgebung des EVG stellt einen gesicherten Zugangspunkt zum Internet bereit. Dieser Zugangspunkt schützt die dahinter liegenden Netze der Benutzer wirksam gegen Angriffe aus dem Internet. Von diesem Zugangspunkt gehen keine Angriffe auf die angeschlossenen LANs aus. Security Target secunet konnektor 2.1.0 secunet Seite 71 von 424 OSP.NK.BOF Kommunikation mit Bestandsnetzen und offenen Fachdiensten Der EVG ermöglicht den aktiven Komponenten im LAN des Leistungserbringers eine Kommunikation mit den Bestandsnetzen und den offenen Fachdiensten über den VPN- Kanal zur TI. OSP.NK.TLS TLS-Kanäle mit sicheren kryptographische Algorithmen Der EVG stellt TLS-Kanäle zur sicheren Kommunikation mit anderen IT-Produkten zur Verfügung und verwendet dabei sichere kryptographische Algorithmen und Protokolle gemäß [19] mit den Einschränkungen der gematik Spezifikation für Kryptoalgorithmen [30]. Zudem prüft der EVG die Gültigkeit der Zertifikate, die für den Aufbau eines TLS- Kanals verwendet werden. OSP.NK.SW-Update Software-Update Die Software von Konnektorkomponenten kann aktualisiert werden (Software-Update) und zusätzliche Fachmodule können nachgeladen werden. Dabei ist die (ggf. automatische) Auslieferung des Updates bzw. Fachmoduls durch das Konfigurations- und Software Repository (KSR, Update-Server) über einen sicheren Kanal an den Leistungserbringer und die (ggf. automatische) Installation des Updates bzw. Fachmoduls durch den Administrator zu unterscheiden. Es dürfen nur von einer autorisierten Stelle geprüfte, freigegebene und ggf. zertifizierte Komponenten bzw. Fachmodule signiert und zum Update bereitgestellt werden. Die Updates können je nach Konfiguration automatisch installiert werden. Bevor ein Software-Update installiert wird, wird die Integrität und Authentizität / Zulässigkeit der Software überprüft (Signaturprüfung und Prüfung der Identität des Signierenden, Schutz gegen unbefugtes Wiedereinspielen älterer Software-Versionen18 ). Schlägt die Prüfung der Integrität fehl, verhindert der EVG eine Aktualisierung der Software. Manuelle Installationen von Updates sowie Änderungen der Konfiguration bzgl. automatischer Updates sind administrative Vörgänge und auf entsprechende Nutzer zu beschränken. Ebenso müssen Aktualisierungen Protokoliert werden. Hinweis: OSP.AK.SW-Update und OSP.NK.SW-Update sind identisch. Die doppelte Aufführung ist historisch bedingt. 18 Einspielen älterer Software-Versionen ist nur dann erlaubt, wenn die einzuspielende Version in der aktuell gültigen Liste zulässiger Software-Versionen (Firmware-Gruppe) ist. Security Target secunet konnektor 2.1.0 Seite 72 von 424 secunet 3.3.2. Organisatorische Sicherheitspolitiken des Anwendungskonnektors Die organisatorischen Sicherheitspolitiken des Anwendungskonnektors ergeben sich aus gesetzlichen Anforderungen und übergreifenden Dokumenten für technische Komponenten der Telematikinfrastruktur und der elektronischen Gesundheitskarte. Die organisatorischen Sicherheitspolitiken für den Signaturdienst für die QES ergeben sich aus der eIDAS-VO [12]. 3.3.2.1. allgemeine organisatorischen Sicherheitspolitiken OSP.AK.MedSoc_Data Schutz medizinischer Daten und Sozialdaten Der Konnektor und die eHealth-Kartenterminals schützen die Vertraulichkeit und Integrität aller Daten, die durch oder an die Telematikinfrastruktur, ein Clientsystem des Leistungserbringers sowie eine elektronische Gesundheitskarte übergeben werden, als personenbezogene medizinische Daten oder Sozialdaten. Es werden Dienste zur qualifizierten und nichtqualifizierten elektronischen Signatur, zur Chiffrierung von Dateien sowie zur kryptographischen Absicherung der Kommunikation bereitgestellt. OSP.AK.Konn_Spez Konformität zur Spezifikation Konnektor Der EVG erfüllt die sicherheitsrelevanten Anforderungen des Produktsteckbriefes Konnektor [28] und der Spezifikation Konnektor [27]. Der EVG stellt sichere Dienste zur Signaturerstellung, Signaturprüfung, Verschlüsselung, Entschlüsselung, Kommunikation mit den eHealth-Kartenterminals und der Verwendung der Chipkarten zur Verfügung. Ebenso bietet der EVG einen sicheren Update-Mechansimus und eine sichere Protokollierung. Anwendungshinweis 25: Die Spezifikation Konnektor beschreibt das Verhalten des Konnektors an den äußeren Schnittstellen und Abläufe von Funktionen. Diese Sicherheitsvorgaben verweisen auf diese Beschreibungen soweit dies für die Festlegung von Sicherheitseigenschaften erforderlich ist. OSP.AK.KryptAlgo Kryptographische Algorithmen Alle kryptographischen Sicherheitsmechanismen der technischen Komponenten der Telematikinfrastruktur werden im Einklang mit den relevanten Vorgaben des Dokuments TR-03116-1 [19] mit den Einschränkungen der gematik Spezifikation für Kryptoalgorithmen [30] implementiert. Für den Signaturdienst für qualifizierte elektronische Signaturen gelten die Festlegungen gemäß [12]. Security Target secunet konnektor 2.1.0 secunet Seite 73 von 424 OSP.AK.SW-Update Software-Update Die Software von Konnektorkomponenten kann aktualisiert werden (Software-Update) und zusätzliche Fachmodule können nachgeladen werden. Dabei ist die (ggf. automatische) Auslieferung des Updates bzw. Fachmoduls durch das Konfigurations- und Software Repository (KSR, Update-Server) über einen sicheren Kanal an den Leistungserbringer und die (ggf. automatische) Installation des Updates bzw. Fachmoduls durch den Administrator zu unterscheiden. Es dürfen nur von einer autorisierten Stelle geprüfte, freigegebene und ggf. zertifizierte Komponenten bzw. Fachmodule signiert und zum Update bereitgestellt werden. Die Updates können je nach Konfiguration automatisch installiert werden. Bevor ein Software-Update installiert wird, wird die Integrität und Authentizität / Zulässigkeit der Software überprüft (Signaturprüfung und Prüfung der Identität des Signierenden, Schutz gegen unbefugtes Wiedereinspielen älterer Software-Versionen19 ). Schlägt die Prüfung der Integrität fehl, verhindert der EVG eine Aktualisierung der Software. Manuelle Installationen von Updates sowie Änderungen der Konfiguration bzgl. automatischer Updates sind administrative Vörgänge und auf entsprechende Nutzer zu beschränken. Ebenso müssen Aktualisierungen Protokoliert werden. Hinweise: OSP.AK.SW-Update und OSP.NK.SW-Update sind identisch. Die doppelte Aufführung ist historisch bedingt. Der Konnektor unterstützt die Funktion „AutoUpdate“. Die Fachmodule sind im Image des Anwendungskonnektors enthalten. Updates für Fachhmodule oder zusätzliche Fachmodule können nur über ein Update der Konnektor-Software eingebracht werden. 3.3.2.2. Organisatorische Sicherheitspolitiken zur Signaturerzeugung und Signaturprüfung OSP.AK.SC_Sign Erzeugung elektronischer Signaturen Der Signaturschlüssel-Inhaber nutzt den Heilberufsausweis als qualifizierte Signaturerstellungseinheit sowie den EVG und die eHealth-Kartenterminals mit gSMC-KT zur Erstellung qualifizierter elektronischer Signaturen. Der Benutzer kann den EVG auch zur Erzeugung nicht-qualifizierter elektronischer Signaturen für Dokumente nutzen. Der EVG stellt Schnittstellen für die Erzeugung digitaler (nicht.qualifizierter) Signaturen über Bitstrings mit Authentisierungsschlüsseln bereit. 19 Einspielen älterer Software-Versionen ist nur dann erlaubt, wenn die einzuspielende Version in der aktuell gültigen Liste zulässiger Software-Versionen (Firmware-Gruppe) ist. Security Target secunet konnektor 2.1.0 Seite 74 von 424 secunet OSP.AK.SC_Authorized Autorisierung der Signatur Bei der Erzeugung einer qualifizierten elektronischen Signatur muss durch den Signaturdienst gewährleistet sein, dass eine Signatur nur durch die berechtigt signierende Person erfolgt. OSP.AK.SC_SVAD Schutz der Authentisierungsdaten Bei der Erzeugung einer qualifizierten elektronischen Signatur muss durch den Signaturdienst gewährleistet sein, dass die Authentisierungsdaten nicht preisgegeben und diese nur auf der jeweiligen qualifizierten Signaturerstellungseinheit gespeichert werden. OSP.AK.SC_UnalteredData Unversehrtheit der zu signierenden Daten Der Prozess der Erstellung von Signaturen ist auf Abweichungen zu überwachen und der Benutzer ist über festgestellte Abweichungen zu informieren. Die Erzeugung qualifizierter elektronischer Signaturen darf nur für die vom Signaturschlüssel-Inhaber übergebenen Daten erfolgen, bei festgestellten Abweichungen sind alle Signaturen des Stapels zu verwerfen. OSP.AK.SV_Certificate Prüfung des Zertifikates Bei der Verifizierung einer qualifizierten elektronischen Signatur muss durch den EVG geprüft werden, ob die nachgeprüften qualifizierten Zertifikate im jeweiligen Zertifikat- Verzeichnis zum angegebenen Zeitpunkt vorhanden und nicht gesperrt waren. Für die Prüfung nicht-qualifizierter elektronischer Signaturen und digitaler Signaturen können gesonderte Regeln in der Signaturrichtlinie der signierten Daten festgelegt werden. OSP.AK.SV_Signatory Zuordnung des Signaturschlüssel-Inhabers Für die Überprüfung qualifiziert signierter Daten sind Komponenten erforderlich, die feststellen lassen, „welchem Signaturschlüssel-Inhaber die Signatur zuzuordnen ist“. Die Prüfung nicht-qualifizierter elektronischer Signaturen und digitaler Signaturen muss den Signaturschlüssel-Inhaber, dem die Signatur zuzuordnen ist, feststellen lassen. OSP.AK.SV_Unaltered_Data Unversehrtheit der signierten Daten Der EVG muss bei der Überprüfung qualifiziert signierter Daten gewährleisten, dass die Korrektheit der Signatur zuverlässig geprüft wird und insbesondere, ob die signierten Daten unverändert sind. Die Prüfung nicht-qualifizierter elektronischer Signaturen und digitaler Security Target secunet konnektor 2.1.0 secunet Seite 75 von 424 Signaturen muss feststellen lassen, ob die signierten Daten unverändert sind und welche Prüfungsergebnisse dafür vorliegen. OSP.AK.EVG_Modification Schutz vor Veränderungen Sicherheitstechnische Veränderungen an der EVG-Komponente für qualifizierte elektronische Signaturen müssen für den Nutzer erkennbar werden. Dauerhaft gespeicherte Klartextschlüssel sind gegen Kompromittierung durch physische und logische Angriffe zu schützen. 3.3.2.3. Organisatorische Sicherheitspolitiken für Kryptomodul und Server OSP.AK.Encryption Verschlüsselung und Entschlüsselung Der Konnektor muss Dienste zum Verschlüsseln und Entschlüsseln von Daten im Rahmen fachlicher Anwendungsfälle bereitstellen. Dem Konnektor werden durch das Clientsystem die zu verschlüsselnden und zu entschlüsselnden Dokumente übergeben, die zu verwendende Verschlüsselungsrichtlinie durch den Fachdienst bzw. den Anwendungsfall identifiziert und beim Verschlüsseln eines Dokuments die vorgeschlagenen Empfänger des Dokuments angegeben. Vor dem Verschlüsseln eines Dokuments wird die Gültigkeit der zu benutzenden Verschlüsselungszertifikate geprüft. Alle Verschlüsselungsrichtlinien, die vom Konnektor umgesetzt werden, erlauben das automatische Verschlüsseln und Entschlüsseln von Daten. OSP.AK.CardService Chipkartendienste Der EVG muss Sicherheitsdienste zur lokalen und entfernten Eingabe von PIN und PUK, zur Identifizierung und Authentisierung von Chipkarten sowie zur gegenseitigen Authentisierung zwischen Chipkarten (Card-to-Card-Authentisierung) in den angeschlossenen eHealth- Kartenterminals erbringen. Der EVG kontrolliert den Zugriff auf Chipkarten in Abhängigkeit von deren Sicherheitszustand. 3.3.2.4. Organisatorische Sicherheitspolitiken für Fachanwendungen OSP.AK.Fachanwendungen vertrauenswürdige Fachanwendungen und zentrale Dienste der TI-Plattform Die Fachanwendungen der TI und zentrale Dienste der TI-Plattform sind vertrauenswürdig und verhalten sich entsprechend ihrer Spezifikation. Der Konnektor unterstützt den Fachdienst Versichertenstammdatenmanagement und die Kommunikation mit dem zentralen Verzeichnisdienst. Fachdienste und Fachmodule kommunizieren über gesicherte Kanäle. Für zentrale Dienste der TI kann eine geschützte Kommunikation bereit gestellt werden. Durch Security Target secunet konnektor 2.1.0 Seite 76 von 424 secunet Fachanwendungen genutztes Schlüsselmaterial wird wirksam vor Angriffen geschützt. Wird dennoch eine Komponente einer Fachanwendung und/oder sein Schlüsselmaterial erfolgreich angegriffen, so werden die betroffenen Schlüssel zeitnah gesperrt. 3.3.2.5. Organisatorische Sicherheitspolitiken für die ePA Fachanwendung (PTV4) OSP.AK.VAUSGD Geschützte Kommunikation mit VAU-Instanz und SGD-HSM Der Konnektor muss das „VAU-Protokoll“ zur Kommunikation mit der VAU-Instanz in der ePA-Dokumentenverwaltung und das „SGD-Protokoll“ zur Kommunikation mit dem SGD- HSM des Schlüsselgenerierungsdienst spezifikationskonform umsetzen, um den Wert VAU- /SGD-Inhaltsdaten zu schützen. Die korrekte Implementierung der Protokolle sichert den Datenverkehr des TOE mit der VAU-Instanz in der ePA-Dokumentenverwaltung und dem SGD-HSM des Schlüsselgenerierungsdienst gegen unbefugtes Mithören ab. Die korrekte Implementierung schützt nicht gegen einen aktiven Angreifer, der einen einzelnen Konnektor zu manipulieren versucht. 3.4. Annahmen 3.4.1. Annahmen an den Netzkonnektor In den folgenden Tabellen werden die „Annahmen an den Netzkonnektor“ wiedergegeben. Diesen wurden unverändert aus dem PP [17] übernommen. A.NK.phys_Schutz Physischer Schutz des EVG („sichere Umgebung“) Die Sicherheitsmaßnahmen in der Umgebung schützen den Konnektor (während aktiver Datenverarbeitung im Konnektor) vor physischen Zugriff Unbefugter. Befugt sind dabei nur durch den Betreiber des Konnektors namentlich autorisierte Personen (z. B. Leistungserbringer, ggf. medizinisches Personal). Sowohl während als auch außerhalb aktiver Datenverarbeitung im Konnektor stellen die Sicherheitsmaßnahmen in der Umgebung sicher, dass ein Diebstahl des Konnektors und/oder Manipulationen am Konnektor so rechtzeitig erkannt werden, dass die einzuleitenden materiellen, organisatorischen und/oder personellen Maßnahmen größeren Schaden abwehren. Im Fall eines verteilt betriebenen Mehrkomponenten-Konnektors schützt die Umgebung außerdem den Kommunikationskanal zwischen den Konnektorteilen Anwendungskonnektor und Netzkonnektor, sowie dem Netzkonnektor und weiteren Komponenten des Konnektors während aktiver Datenverarbeitung vor physischem Zugriff und erkennt außerhalb aktiver Datenverarbeitung physische Manipulation. Hinweis: Die Annahme A.NK.phys_Schutz an den Netzkonnektor ist identisch zur Annahme A.AK.phys_Schutz an den Anwendungskonnektors. Der Konnektor wird als Einbox-Konnektor umgesetzt. Security Target secunet konnektor 2.1.0 secunet Seite 77 von 424 A.NK.gSMC-K Sicherheitsmodul für den EVG (gSMC-K) Der EVG hat Zugriff auf ein Sicherheitsmodul (gSMC-K), das sicher mit dem EVG verbunden ist. Sicher bedeutet in diesem Fall, dass die gSMC-K nicht unbemerkt vom EVG getrennt werden kann und dass die Kommunikation zwischen gSMC-K und EVG weder mitgelesen noch manipuliert werden kann. Die gSMC-K dient als Schlüsselspeicher für das Schlüsselmaterial, welches die kryptographische Identität des EVG repräsentiert und welches auch für O.NK.VPN_Auth verwendet wird. Es führt kryptographische Operationen mit diesem Schlüsselmaterial durch (Authentisierung), ohne dass das Schlüsselmaterial den sicheren Schlüsselspeicher dazu verlassen muss. Die gSMC-K ist durch die gematik zugelassen. Anwendungshinweis 26:Nicht relevant. In der Konnektor-Hardware werden physische gSMC-Ks verbaut A.NK.sichere_TI Sichere Telematikinfrastruktur-Plattform Die zentrale Telematikinfrastruktur-Plattform und die damit verbundenen Netze werden als vertrauenswürdig angesehen, d.h., Angriffe aus der zentralen TI-Plattform sowie aus Netzen, die mit der zentralen TI-Plattform verbunden sind, werden nicht betrachtet. Die Betreiber der Telematikinfrastruktur sorgen dafür, dass die Server in der Telematikinfrastruktur frei von Schadsoftware gehalten werden, so dass über den sicheren VPN-Kanal in den Konnektor hinein keine Angriffe erfolgen. Die VPN-Schlüssel auf Seiten der VPN-Konzentratoren werden geheim gehalten und sind nur für die rechtmäßigen Administratoren zugänglich. Es werden weder VPN- Konzentratoren noch deren Schlüsselmaterial durch Angreifer entwendet. Alle Administratoren in der Telematikinfrastruktur sind fachkundig und vertrauenswürdig. A.NK.kein_DoS Keine denial-of-service-Angriffe Denial-of-service-Angriffe aus dem Transportnetz werden effektiv von Komponenten außerhalb des Konnektors abgewehrt. Security Target secunet konnektor 2.1.0 Seite 78 von 424 secunet Anwendungshinweis 27:Der Beitrag des EVG zur Abwehr von Denial of Service Angriffen besteht lediglich darin, dass nur autorisierten Benutzern Zugang zu den Diensten der Telematikinfrastruktur vermittelt wird. Zudem trägt die Verwendung von DNSSEC bei der Ermittlung von IP-Adressen der VPN Konzentratoren TI und SIS zur Abwehr von DoS Angriffen bei. Insofern kann der Netzkonnektor die Abwehr von Denial of Service Angriffen unterstützen, aber nicht die alleinige Verantwortung dafür übernehmen. Die Verantwortung für den Schutz der Systeme der zentralen Telematikinfrastruktur-Plattform liegt bei den Firewall-Systemen im Perimeter der zentralen Telematikinfrastruktur- Plattform. Der Schwerpunkt der Abwehr durch den EVG liegt bei den in O.NK.PF_WAN und O.NK.PF_LAN beschriebenen Bedrohungen. A.NK.AK Anwendungskonnektor nutzt EVG korrekt Der Anwendungskonnektor nutzt die Sicherheitsdienste des EVG über dessen Schnittstellen automatisch. Durch die Art der Aufrufe ist für den EVG jederzeit eindeutig erkennbar, welche Daten über die VPN-Tunnel an die zentrale Telematikinfrastruktur-Plattform (offene und gesicherte Fachdienste, zentrale Dienste) und SIS weitergeleitet werden müssen. Anwendungshinweis 28:Der EVG implementiert einen Paketfilter und stellt separate Kommunikationskanäle für Daten, welche zu schützende Daten der TI und der Bestandsnetze sind (z. B. personenbezogene medizinische Daten für die zentrale Telematikinfrastruktur-Plattform) und entsprechend gekennzeichnet sind zur Verfügung. Basierend auf der Informationsflusskontrolle wertet der Paketfilter die IP Information aus, welche über die logischen Schnittstellen ausgetauscht wird. A.NK.CS Clientsystem nutzt EVG korrekt Die Clientsysteme nutzen die Sicherheitsdienste des EVG über dessen Schnittstellen automatisch. Durch die Art der Aufrufe aus dem lokalen Netz des Leistungserbringers ist für den EVG jederzeit eindeutig erkennbar, welche Daten an Fachmodule und Basisdienste des Konnektors, über den VPN-Tunnel an die zentrale Telematikinfrastruktur-Plattform (offene Fachdienste, gesicherte Fachdienste, zentrale Dienste), die aktiven Bestandsnetze und den SIS weitergeleitet werden müssen. Anwendungshinweis 29: Der EVG implementiert einen Paketfilter und stellt separate Kommunikationskanäle für Daten, welche zu schützende Daten der TI und der Bestandsnetze sind (z. B. personenbezogene medizinische Daten für die zentrale Telematikinfrastruktur-Plattform) und entsprechend gekennzeichnet sind zur Verfügung. Basierend auf der Informationsflusskontrolle wertet der Paketfilter die IP Information aus, welche über die logischen Schnittstellen ausgetauscht wird. Security Target secunet konnektor 2.1.0 secunet Seite 79 von 424 A.NK.Betrieb_AK Sicherer Betrieb des Anwendungskonnektors Der Betreiber des Anwendungskonnektors organisiert dessen Betrieb in sicherer Art und Weise: Er setzt nur gemäß dem Schutzprofil [16] zertifizierte Anwendungskonnektoren ein, die nach dem aktuellen Stand der Technik entwickelt wurden und das spezifizierte Verhalten zeigen. Er administriert die Anwendungskonnektoren in sicherer Art und Weise. Er trägt die Verantwortung dafür, dass die Anwendungskonnektoren und Fachmodule den EVG in der spezifizierten Art und Weise nutzen, also insbesondere die spezifizierten Konnektor-Schnittstellen korrekt nutzen. A.NK.Betrieb_CS Sicherer Betrieb der Clientsysteme Der Betreiber der Clientsysteme organisiert diesen Betrieb in sicherer Art und Weise: Er setzt nur Clientsysteme ein, die nach dem aktuellen Stand der Technik entwickelt wurden und das spezifizierte Verhalten zeigen. Er administriert die Clientsysteme in sicherer Art und Weise. Er trägt die Verantwortung dafür, dass die Clientsysteme den EVG in der spezifizierten Art und Weise nutzen, also insbesondere die spezifizierten Konnektor-Schnittstellen korrekt nutzen. Er sorgt dafür, dass über Kanäle, die nicht der Kontrolle des Konnektors unterliegen (z. B. Einspielen von ausführbaren Dateien über lokale optische Laufwerke oder über USB-Stick, Öffnen von E-Mail-Anhängen) keine Schadsoftware auf die Clientsysteme oder andere IT- Systeme im LAN aufgebracht wird. Er ist verantwortlich dafür, dass eine Anbindung der Clientsysteme an potentiell unsichere Netze (z. B. Internet) unterbunden wird oder ausschließlich in sicherer Art und Weise erfolgt. Die Anbindung an unsichere Netze kann z. B. dadurch in sicherer Art und Weise erfolgen, dass es neben dem definierten Zugang zum Transportnetz über den EVG keine weiteren ungeschützten oder schlechter geschützten Zugänge zum Transportnetz gibt. Die Verantwortung für die Clientsysteme liegt sowohl beim Leistungserbringer (der z. B. lokal potentiell bösartige Software oder auch potentiell fehlerhafte Updates der Clientsystem- Software einspielen könnte) als auch beim Clientsystem-Hersteller (der z. B. den korrekten Aufruf der Konnektor-Schnittstellen sicherstellen muss). A.NK.Admin_EVG Sichere Administration des EVG Der Betreiber des EVG sorgt dafür, dass administrative Tätigkeiten (dies umfasst sowohl die lokale als auch die optionale zentrale Administration) in Übereinstimmung mit der Administrator-Dokumentation des EVG durchgeführt werden. Insbesondere ist für diese Tätigkeiten vertrauenswürdiges, mit der Benutzerdokumentation vertrautes, sachkundiges Security Target secunet konnektor 2.1.0 Seite 80 von 424 secunet Personal einzusetzen. Die Administratoren halten Authentisierungsinformationen und –token geheim bzw. geben diese nicht weiter (z. B. PIN bzw. Passwort oder Schlüssel-Token). A.NK.Ersatzverfahren Sichere Ersatzverfahren bei Ausfall der Infrastruktur Es sind sichere Ersatzverfahren etabliert, auf die zurückgegriffen werden kann, wenn plötzliche Schwächen in den verwendeten kryptographischen Algorithmen bekannt werden, die nicht durch die redundanten Algorithmen ausgeglichen werden können. A.NK.Zugriff_gSMC-K Effektiver Zugriffsschutz auf gSMC-K Es sind effektive Zugriffsschutzmaßnahmen etabliert, die den möglichen Zugriff von Komponenten des Konnektors auf Schlüsselmaterial der gSMC-K kontrollieren und unzulässige Zugriffe verhindern. Die Zugriffskontrolle kann durch eine zentrale Instanz vermittelt werden oder es wird sichergestellt, dass die Komponenten des Konnektors nur auf ihr eigenes Schlüsselmaterial zugreifen. Anwendungshinweis 30:Dieser Aspekt wird im Schutzprofil [16] als übergreifende Sicherheitsfunktion modelliert. 3.4.2. Annahmen an den Anwendungskonnektor In den folgenden Tabellen werden die „Annahmen an den Anwendungskonnektor“wiedergegeben. Diesen wurden unverändert aus dem PP [17] übernommen. A.AK.Versicherter Sorgfaltspflichten des Versicherten Der Versicherte händigt seine eGK nur dann und nur dort einem HBA-Inhaber oder einem seiner Mitarbeiter aus, wenn er diesem Zugriff auf seine Daten gewähren will. Er nimmt seine eGK nach Abschluss der Konsultation wieder an sich. A.AK.HBA-Inhaber Vertrauenswürdigkeit und Sorgfaltspflichten des HBA-Inhabers Der HBA-Inhaber und seine Mitarbeiter sind vertrauenswürdig in Bezug auf den Umgang mit den ihm bzw. ihnen anvertrauten zu schützenden Daten. Alle Leistungserbringer, die Zugriff auf medizinische Daten haben, welche auf Clientsystemen lokal gespeichert werden, gehen verantwortungsvoll mit diesen Daten um. Security Target secunet konnektor 2.1.0 secunet Seite 81 von 424 Der Betreiber des Konnektors administriert seine IT-Umgebung in einer Art und Weise, die Missbrauchsmöglichkeiten minimiert. Der HBA-Inhaber verwendet seinen HBA nur in IT- Umgebungen, die wie im vorigen Satz beschrieben sicher administriert werden. A.AK.SMC-B-PIN Freischaltung der SMC-B Die SMC-B ist nur freigeschaltet, wenn sie und der Konnektor unter der Kontrolle des Leistungserbringers arbeiten. Wenn der Leistungserbringer keine Kontrolle mehr über den Konnektor oder die SMC-B hat, setzt er die Freischaltung der SMC-B zurück (z.B. durch Ausschalten des Kartenterminals oder Ziehen der Chipkarte). A.AK.sichere_TI Sichere Telematikinfrastruktur-Plattform Die zentrale Telematikinfrastruktur-Plattform wird als vertrauenswürdig angesehen, d.h., Angriffe aus der zentralen Telematikinfrastruktur-Plattform werden nicht betrachtet und es wird angenommen, dass die zentrale Telematikinfrastruktur-Plattform die ihr anvertrauten Daten / Informationen nicht missbraucht. Die Administration der Telematikinfrastruktur sorgt dafür, dass die Server in der Telematikinfrastruktur frei von Schadsoftware gehalten werden, so dass über bestehende logische Kanäle zum AK keine Angriffe auf den AK erfolgen. Alle Administratoren der Telematikinfrastruktur sind fachkundig und vertrauens- würdig A.AK.Admin_EVG Sichere Administration des Anwendungskonnektors Der Betreiber des AKs sorgt dafür, dass administrative Tätigkeiten in Übereinstimmung mit der Administrator-Dokumentation des AKs durchgeführt werden. Insbesondere wird für diese Tätigkeiten vertrauenswürdiges und hinreichend geschultes Personal eingesetzt. Der Administrator handelt nur im Sinne des verantwortlichen Leistungserbringers bzw. Konnektor-Betreibers und in dessen Auftrag. Der Administrator ist verantwortlich dafür die automatische Aktualisierung des Konnektor zu konfigurieren und hat im Falle des manuellen Anwendens von Aktualisierungen das Recht das Update anzustoßen. Der Administrator hält Authentisierungsinformationen und -token geheim bzw. gibt diese nicht weiter (z. B. PIN bzw. Passwort oder Schlüssel-Token). Der Leistungserbringer als Nutzer des Konnektors hat die Verantwortung, die Eignung der aktuell genutzten Konnektorfirmware-Version zu prüfen. Anwendungshinweis 31: Die Information der Benutzer des AKs, welche Firmware-Version aktuell genutzt wird kann vom Administrator über die Managementschnittstelle ausgelesen werden. Der Konnektor unterstützt die automatische Aktualisierung („AutoUpdate“). Während der Konnektor aktualisiert wird, müssen die mit dem Konnektor gepairten eHealth-Kartenterminals organisatorisch genschützt werden. Security Target secunet konnektor 2.1.0 Seite 82 von 424 secunet A.AK.Cardterminal_eHealth Nutzung eines sicheren Kartenterminals Für die Chipkarten und die Eingabe von Benutzerverifikationsdaten werden ausschließlich eHealth-Kartenterminals verwendet, die der Spezifikation [38] entsprechen und nach dem Schutzprofil für eHealth-Kartenterminals [22] evaluiert wurden. A.AK.Konnektor Konnektor Die Anwender/Benutzer setzen nur solche Konnektoren ein, welche der Spezifikation [27] entsprechen und nach dem Konnektor Schutzprofil BSI-CC-PP-0098 evaluiert und zertifiziert wurden. Die Plattform des Konnektors stellt dem EVG eine Ausführungsumgebung zur Verfügung, die die von ihm verarbeiteten Daten vor dem Zugriff durch Dritte (andere Programme, Prozesse, IT-Systeme o. ä.) schützt. A.AK.Env_Arbeitsplatz Vertrauenswürdige Einsatzumgebung Der Arbeitsplatz des Clientsystems ist vertrauenswürdig. Wenn dem Benutzer des EVGs zu signierende Daten oder Prüfergebnisse auf dem Arbeitsplatz des Clientsystems angezeigt werden, so wird die genutzte Anzeigekomponente ebenfalls als vertrauenswürdig angesehen. A.AK.Benutzer_Signatur Prüfung zu signierender und zu prüfender Dokumente vor der Übermittlung an den AK Der Benutzer des Clientsystems sorgt vor der Übermittlung an den AK dafür, dass er nur solche Daten zur Signaturerzeugung und zur Signaturprüfung über sein Clientsystem an den AK übergibt, welche er auch tatsächlich signieren bzw. verifizieren will. A.AK.SMC Nutzung einer SMC-B und gSMC-KT Es werden nur solche Chipkarten mit privaten Schlüsseln und dazu gehörigen CVC als SMC- B bzw. gSMC-KT ausgestattet und in den eHealth-Kartenterminals betrieben, deren Betriebssystem der Spezifikation [31] entspricht und nach dem Schutzprofil COS Schutzprofil [15] evaluiert ist und dessen Objektsysteme der Spezifikation [36] bzw. [34] entsprechen. Die genutzte SMC hat eine TR-Zertifizierung nach BSI TR-03144 erfolgreich durchlaufen (Nachweis der vertrauenswürdigen Initialisierung) und die Personalisierung der SMC ist sicher. Der Chipkartentyp SMC kann aus verschiedenen Quellen auf der jeweiligen Karte verlässlich bestimmt werden (bspw. CV-Zertifikat und X.509-Zertifikat). Bei der Personalisierung der Security Target secunet konnektor 2.1.0 secunet Seite 83 von 424 SMC wird sichergestellt, dass die Konsistenz hinsichtlich des Kartentyps zwischen diesen Quellen gewahrt ist. A.AK.gSMC-K Nutzung einer gSMC-K Der EVG hat Zugriff auf ein Sicherheitsmodul (gSMC-K), das sicher mit dem EVG verbunden ist. Sicher bedeutet in diesem Fall, dass die gSMC-K nicht unbemerkt vom EVG getrennt werden kann und dass die Kommunikation zwischen gSMC-K und EVG weder mitgelesen noch manipuliert werden kann. Die gSMC-K dient als Schlüsselspeicher für das Schlüsselmaterial, welches die kryptographische Identität des EVG repräsentiert und von ihm verwendet wird. Es führt kryptographische Operationen mit diesem Schlüsselmaterial durch, ohne dass das Schlüsselmaterial den sicheren Schlüsselspeicher dazu verlassen muss. Die gSMC-K ist durch die gematik zugelassen. Die genutzte gSMC-K hat eine TR-Zertifizierung nach BSI TR-03144 erfolgreich durchlaufen (Nachweis der vertrauenswürdigen Initialisierung) und die Personalisierung der gSMC-K ist sicher. A.AK.QSCD Nutzung einer qualifizierten Signaturerstellungseinheit Es werden nur solche Chipkarten mit privaten Schlüsseln und dazu gehörigen CVC als HBA ausgestattet, deren Betriebssystem der Spezifikation [31] entspricht und nach dem Schutzprofil COS [15] evaluiert ist, deren Objektsysteme der Spezifikation [35] entspricht und das als qualifizierte elektronische Signaturerstellungseinheit nach eIDAS zertifiziert ist. Anwendungshinweis 32: Gemäß Spezifikation [35] wird der Heilberufsausweis mit einem privaten Signaturschlüssel ausgestattet, zu dessen öffentlichen Prüfschlüssel ein zum Zeitpunkt der Ausgabe gültiges qualifiziertes Zertifikat existiert. Der AK prüft für die Erzeugung qualifizierter elektronischer Signaturen, ob dieses Zertifikat zu dem Signaturzeitpunkt oder - wenn dieser nicht bekannt ist – einem angegebenen Zeitpunkt der Signatur gültig ist. Insbesondere erzwingt der HBA, dass für eine Stapelsignatur und auch für eine Komfortsignatur sowohl eine erfolgreiche Authentisierung mit der QES.PIN erfolgt als auch die zu signierenden Daten mit Secure Messaging übersendet werden, das auf der Basis einer Authentisierung der Gegenstelle mit der Identität „SAK“ gebildet wurde. A.AK.Chipkarteninhaber Vertrauenswürdigkeit und Sorgfaltspflichten des Chipkarteninhabers Der Chipkarteninhaber ist vertrauenswürdig in Bezug auf den Umgang mit den ihm anvertrauten zu schützenden Daten. Der Chipkarteninhaber des HBA und der SMC-B wendet seine Chipkarte nur in Umgebungen an, in denen der Leistungserbringer sicherstellt, dass die Security Target secunet konnektor 2.1.0 Seite 84 von 424 secunet IT-Umgebung des Leistungserbringers (insbesondere das Clientsystem) vertrauenswürdig ist. Der Chipkarteninhaber darf seine PIN.CH nur dann an einem Kartenterminal eingeben, wenn der durch den Chipkarteninhaber initiierte Anwendungsfall dies erfordert und wenn das Kartenterminal dem Chipkarteninhaber einen sicheren PIN-Eingabemodus anzeigt. Wird der Chipkarteninhaber von einem Kartenterminal zur PIN-Eingabe aufgefordert, ohne dass das Kartenterminal gleichzeitig den sicheren PIN-Eingabemodus anzeigt, muss der Chipkarteninhaber den Vorgang abbrechen und darf seine PIN nicht eingeben. Der Chipkarteninhaber des HBA und der SMC-B kontrolliert bei der entfernten PIN-Eingabe die Übereinstimmung der Jobnummer, die ihm auf dem Clientsystem anzeigt wird mit der Anzeige auf dem PIN-Kartenterminal. Bei nicht übereinstimmender Jobnummer bricht der Chipkarteninhaber den Vorgang ab. A.AK.phys_Schutz Physischer Schutz des Konnektors Die Sicherheitsmaßnahmen in der Umgebung schützen den Konnektor (während aktiver Datenverarbeitung im Konnektor) vor physischen Zugriff Unbefugter. Befugt sind dabei nur durch den Betreiber des Konnektors namentlich autorisierte Personen (z. B. Leistungserbringer, ggf. medizinisches Personal). Sowohl während als auch außerhalb aktiver Datenverarbeitung im Konnektor stellen die Sicherheitsmaßnahmen in der Umgebung sicher, dass ein Diebstahl des Konnektors und/oder Manipulationen am Konnektor so rechtzeitig erkannt werden, dass die einzuleitenden materiellen, organisatorischen und/oder personellen Maßnahmen größeren Schaden abwehren. Im Fall eines verteilt betriebenen Mehrkomponenten-Konnektors schützt die Umgebung außerdem den Kommunikationskanal zwischen den Konnektorteilen Anwendungskonnektor und Netzkonnektor, sowie dem EVG und weiteren Komponenten des Konnektors während aktiver Datenverarbeitung vor physischem Zugriff und erkennt außerhalb aktiver Datenverarbeitung physische Manipulation. Hinweis: Die Annahme A.AK.phys_Schutz an den Anwendungskonnektor ist identisch zur Annahme A.NK.phys_Schutz an den Netzkonnektors. Der Konnektor wird als Einbox-Konnektor Umgesetzt. Security Target secunet konnektor 2.1.0 secunet Seite 85 von 424 4. Sicherheitsziele Die Namensgebung der symbolischnen Bezeichner für die im Folgenden definierten Sicherheitsziele folgt der aus dem zugrundeliegenden dem PP [16]. 4.1. Sicherheitsziele für den Netzkonnektor In den folgenden Tabellen werden die „Sicherheitsziele für den Netzkonnektor“ wiedergegeben. Diesen wurden unverändert aus dem PP [16] übernommen und um die Sicherheitsziele O.NK.Update und O.NK.Admin_Auth erweitert. 4.1.1. Allgemeine Ziele: Schutz und Administration O.NK.TLS_Krypto TLS-Kanäle mit sicheren kryptographische Algorithmen Der NK stellt TLS-Kanäle zur sicheren Kommunikation mit anderen IT-Produkten zur Verfügung und verwendet dabei sichere kryptographische Algorithmen und Protokolle gemäß [19] mit den Einschränkungen der gematik Spezifikation für Kryptoalgorithmen [30]. Zudem prüft der NK die Gültigkeit der Zertifikate, die für den Aufbau eines TLS-Kanals verwendet werden. Anwendungshinweis 33: Für welche Verbindungen TLS-Kanäle genutzt werden, ist Gegenstand des Anwendungskonnektors. Der Netzkonnektor stellt die kryptographische Grundfunktionalität für TLS zur Verfügung. O.NK.Schutz Selbstschutz, Selbsttest und Schutz von Benutzerdaten Der NK schützt sich selbst und die ihm anvertrauten Benutzerdaten. Der EVG schützt sich selbst gegen sicherheitstechnische Veränderungen an den äußeren logischen Schnittstellen bzw. erkennt diese oder macht diese erkennbar. Der NK erkennt bereits Versuche, sicherheitstechnische Veränderungen durchzuführen, sofern diese über die äußeren Schnittstellen des NKs erfolgen (mit den unter OE.NK.phys_Schutz formulierten Einschränkungen). Der NK führt beim Start-up und bei Bedarf Selbsttests durch. Der NK löscht temporäre Kopien nicht mehr benötigter Geheimnisse (z. B. Schlüssel) vollständig durch aktives Überschreiben. Das Überschreiben erfolgt unmittelbar zu dem Zeitpunkt, an dem die Geheimnisse nicht mehr benötigt werden. Security Target secunet konnektor 2.1.0 Seite 86 von 424 secunet Anwendungshinweis 34: Annahmen zum physischen Schutz: Der Schutz vor physischen Angriffen wird durch die Einsatzumgebung gewährleistet (siehe A.NK.phys_Schutz). Der EVG schützt die TSF Daten (den ausführbaren Code) auf der Basis von geeigneten kryptographischen Signaturen unter Nutzung von Vorgaben gemäß TR-03116-1 [19]. O.NK.EVG_Authenticity Authentizität des EVG Das Auslieferungsverfahren und die Verfahren zur Inbetriebnahme des NKs stellen sicher, dass nur authentische NKs in Umlauf gebracht werden können. Gefälschte NKs müssen vom VPN-Konzentrator sicher erkannt werden können. Der NK ermöglicht auf Anforderung und mit Unterstützung der gSMC-K einen Nachweis seiner Authentizität. Anwendungshinweis 35: Die Auslieferung des Netzkonnektor gegenüber dem empfangenden Leistungserbringer oder dem von ihm beauftragten Servicetechniker erfolgt durch gesicherten Transport. Nach Erhalt des Netzkonnektors muss dieser bis zur Inbetriebnahme in einem gesicherten Bereich aufbewahrt werden. Der Betrieb selbst findet in einer sicheren Umgebung statt (siehe OE.NK.phys_Schutz). Die Authentizität des EVG wird dadurch nachgewiesen, dass der Netzkonnektor sich erfolgreich gegenüber einem VPN-Konzentrator für Dienste gemäß § 291 a SGB V [14] authentisiert hat und fachliche Anwendungsfälle im Online-Modus durchgeführt werden können. O.NK.Admin_EVG Administration nur nach Autorisierung und über sicheren Kanal Der NK setzt eine Zugriffskontrolle für administrative Funktionen um: Nur Administratoren dürfen administrative Funktionen ausführen. Dazu ermöglicht der NK die sichere Identifikation und Autorisierung eines Administrators, welcher die lokale und entfernte Administration des EVG durchführen kann. Der Anwendungskonnektor stellt nur authorisierten Administratoren die Management Funktionen des NK zur Verfügung. Die Administration erfolgt über Netzverbindungen (lokal über PS2 oder zentral über PS3). Die Vertraulichkeit und Integrität des für die Administration verwendeten Kanals sowie die Authentizität seiner Endstellen wird durch eine TLS Verbindung abgesichert (Administration über einen sicheren logischen Kanal). Der NK verhindert die Administration folgender Firewall-Regeln: ● Regeln für die Kommunikation zwischen Konnektor und Transportnetz, ● Regeln für die Kommunikation zwischen Konnektor und Telematikinfrastruktur, sowohl gesicherte als auch offene Fachdienste und zentrale Dienste, ● Regeln für die Kommunikation zwischen Konnektor und den Bestandsnetzen, ● Regeln für die Kommunikation zwischen LAN und dem Transportnetz, ● Regeln für die Kommunikation zwischen LAN und der Telematikinfrastruktur, sowohl gesicherte als auch offene Fachdienste und zentrale Dienste, Security Target secunet konnektor 2.1.0 secunet Seite 87 von 424 ● Regeln für die Kommunikation zwischen LAN und den Bestandsnetzen (außer Freischalten aktiver Bestandsnetze), Anwendungshinweis 36: Der EVG unterstützt die Rolle Administrator. Dabei werden im EVG die Administrator-Rollen local administrator, remote administrator und super administrator unterschieden. Der lokale und Remote Administrator können den EVG jeweils über einen entsprechenden Port an der LAN-Schnittstelle konfigurieren. Der Super Administrator benutzt die gleiche Schnittstelle wie der lokale Administrator und kann zudem Benutzerkonten verwalten und Zugriffsrechten vergeben. Es können alle Management-Funktionen der TSF von den drei Administratoren (mit den entsprechenden Einschränkungen nach TAB_KON_655 und TAB_KON_851 aus [27] für den remote administrator) ausgeführt werden. Daher werden unter dem Subjekt Administrator in den SFRs die einzelnen Rollen zusammengefasst. Anwendungshinweis 37: Jede Änderung, die ein Administrator vornimmt, wird zusammen mit einem Zeitstempel und der Identität (Identifikator) des Administrators protokolliert. Anwendungshinweis 38: Der für die Administration notwendige sichere logische Kanal muss auf den durch [26] vorgegebenen Protokollen und Algorithmen beruhen. O.NK.Protokoll Protokollierung mit Zeitstempel Der NK protokolliert sicherheitsrelevante Ereignisse und stellt die erforderlichen Daten bereit. Anwendungshinweis 39: Der für das Protokoll erforderliche Zeitstempel wird dabei durch O.NK.Zeitdienst bereitgestellt. Anwendungshinweis 40: Eine Protokollierung von Zugriffen auf medizinische Daten nach § 291 a (6) Satz 2 SGB V erfolgt durch den Anwendungskonnektor (auf der eGK oder in der zentralen Telematikinfrastruktur-Plattform). Diese Art der Protokollierung ist hier nicht gemeint; der EVG ist in die Protokollierung von Zugriffen auf medizinische Daten nicht involviert. O.NK.Zeitdienst Zeitdienst Der NK synchronisiert die Echtzeituhr gemäß OE.NK.Echtzeituhr in regelmäßigen Abständen über einen sicheren Kanal mit einem vertrauenswürdigen Zeitdienst (siehe OE.NK.Zeitsynchro). Anwendungshinweis 41: Die sichere Systemzeit wird u. a. für die Gültigkeitsprüfung von Zertifikaten von VPN-Konzentratoren verwendet. Security Target secunet konnektor 2.1.0 Seite 88 von 424 secunet O.NK.Update Software Update Bevor Updatedaten für den NK oder andere Komponenten bereitgestellt werden, muss die Integrität und die Authentizität / Zulässigkeit der Updatedaten überprüft (Signaturprüfung und Prüfung der Identität des Signierenden) und Metadaten (zum Schutz gegen unbefugtes Wiedereinspielen älterer Software-Versionen) angezeigt werden. Schlägt die Prüfung der Integrität fehl, verhindert der NK die Bereitstellung der Updatedaten. Die Installation dieser Updates kann durch den Administrator oder, wenn dies vom Administrator explizit so konfiguriert wurde, automatisch erfolgen. Hinweis: O.NK.Update wurde von O.AK.Update aus dem Protection Profile BSI-CC-PP-0098 [16] des Gesamtkonnektors abgeleitet. Der hier beschriebene Update-Vorgang für die Software des EVG bezieht sich auf die Software des Konnektors, die Updatefunktion für Software wird durch den Netzkonnektor und den Anwendungskonnektor implementiert. Die Updatefunktion für Software kann auch für das Nachladen von geprüften und freigegebenen Fachmodulen verwendet werden. O.NK.Admin_Auth Authentisierung des Administrators Der NK führt selbst die Authentisierung des Administrators durch. Hinweis: Das Sicherheitsziel OE.NK.Admin_Auth für die Umgebung aus dem zugrundeliegendem Protection Profile [16] wurde in ein Sicherheitsziel O.NK.Admin_Auth für den EVG umgewandelt, siehe auch Anwendungshinweis 53: 4.1.2. Ziele für die VPN-Funktionalität O.NK.VPN_Auth Gegenseitige Authentisierung für den VPN-Tunnel Der NK erzwingt die Authentisierung der Kommunikationspartner der VPN-Tunnel (VPN- Konzentratoren der TI und des SIS) und ermöglicht eine Authentifizierung seiner selbst gegenüber den VPN-Konzentratoren in der zentralen Telematikinfrastruktur-Plattform und des SIS. Der NK prüft zertifikatsbasiert die Authentizität der VPN-Konzentratoren der TI und des SIS. Der NK authentisiert sich gegenüber den VPN-Konzentratoren der TI und des SIS. Das dazu erforderliche Schlüsselmaterial bezieht der EVG von der gSMC-K. Außerdem überprüft der EVG, dass die verwendeten Algorithmen gemäß Technische Richtlinie BSI TR-03116-1, Kryptographische Vorgaben für Projekte für der Bundesregierung, Teil 1: Telematikinfrastruktur [19] mit den Einschränkungen der gematik Spezifikation für Kryptoalgorithmen [30] noch gültig sind. Security Target secunet konnektor 2.1.0 secunet Seite 89 von 424 Anwendungshinweis 42: Der EVG implementiert die Algorithmen TR-03116-1 [19] mit den Einschränkungen der gematik Spezifikation für Kryptoalgorithmen [30]. Eine Prüfung der Gültigkeit der Algorithmen wird nicht explizit durchgeführt. Dies wird implizit im Rahmen der Evaluierung des Netzkonnektors sichergestellt. Weiterhin bietet der EVG keine Funktionalität die Verfügbarkeit der in Bezug auf die beannnten Spezifikationen ungültigen Algorithmen selektiv einzuschränken. Eine Einschränkung der im Konnektor verwendbaren Algortihmen kann nur über ein Software-Update erreicht werden. O.NK.Zert_Prüf Gültigkeitsprüfung für VPN-Zertifikate Der NK führt im Rahmen der Authentisierung eines VPN-Konzentrators eine Gültigkeitsprüfung der Zertifikate, die zum Aufbau des VPN-Tunnels verwendet werden, durch. Die zur Prüfung der Zertifikate erforderlichen Informationen werden dem Konnektor in Form einer CRL und einer TSL bereitgestellt. O.NK.VPN_Vertraul Schutz der Vertraulichkeit von Daten im VPN-Tunnel Der NK schützt die Vertraulichkeit der Nutzdaten20 bei der Übertragung von und zu den VPN-Konzentratoren. Bei der Übertragung der Nutzdaten zwischen NK und entfernten VPN-Konzentratoren verschlüsselt (vor dem Versand) bzw. entschlüsselt (nach dem Empfang) der Konnektor die Nutzdaten; dies wird durch die Verwendung des IPsec-Protokolls erreicht. Während der gegenseitigen Authentisierung erfolgt die Aushandlung eines Session Keys. O.NK.VPN_IntegritätIntegritätsschutz von Daten im VPN-Tunnel Der NK schützt die Integrität der Nutzdaten bei der Übertragung von und zu den VPN- Konzentratoren. Bei der Übertragung der Nutzdaten zwischen NK und entfernten VPN-Konzentratoren sichert (vor dem Versand) bzw. prüft (nach dem Empfang) der Konnektor die Integrität der Nutzdaten; dies wird durch die Verwendung des IPsec-Protokolls erreicht. 20 Der Begriff „Nutzdaten“ schließt in diesem Security Target grundsätzlich auch die Verkehrsdaten mit ein, also auch Daten über Kommunikationsbeziehungen – beispielsweise Daten darüber, welcher Versicherte zu welchem Zeitpunkt bei welchem HBA-Inhaber Leistungen in Anspruch genommen hat. Security Target secunet konnektor 2.1.0 Seite 90 von 424 secunet 4.1.3. Ziele für die Paketfilter-Funktionalität O.NK.PF_WAN Dynamischer Paketfilter zum WAN Der NK schützt sich selbst und andere Konnektorteile vor Missbrauch und Manipulation aus dem Transportnetz (dynamische Paketfilter-Funktionalität, Schutz vor Angriffen aus dem WAN). Wenn der Konnektor das einzige Gateway vom LAN der Leistungserbringer zum Transportnetz darstellt21 , dann schützt der NK auch die Clientsysteme. Der NK ermöglicht die Kommunikation von aktiven Komponenten im LAN des LE mit dem SIS. Mit Ausnahme der Kommunikation der Clientsysteme mit den Bestandsnetzen und den offenen Fachdiensten wird grundsätzlich jeder nicht vom Konnektor generierte, direkte Verkehr aus dem LAN in den VPN-Tunnel zur TI ausgeschlossen. Anwendungshinweis 43: Die Inhalte der Kommunikation über den VPN-Tunnel werden vom Konnektor nicht ausgewertet. O.NK.PF_LAN Dynamischer Paketfilter zum LAN Der NK schützt sich selbst und den Anwendungskonnektor vor Missbrauch und Manipulation aus möglicherweise kompromittierten lokalen Netzen der Leistungserbringer (dynamische Paketfilter-Funktionalität, Schutz vor Angriffen aus dem LAN Für zu schützende Daten der TI und der Bestandsnetze sowie zu schützende Nutzerdaten bei Internet-Zugriff über den SIS erzwingt der NK die Nutzung eines VPN-Tunnels. Ungeschützter Zugriff von IT-Systemen aus dem LAN (z. B. von Clientsystemen) auf das Transportnetz wird durch den NK unterbunden: IT-Systeme im LAN können nur unter der Kontrolle des NK und im Einklang mit der Sicherheitspolitik des NK zugreifen. Anwendungshinweis 44: Siehe auch OE.NK.AK. O.NK.Stateful Stateful Packet Inspection (zustandsgesteuerte Filterung) Der NK implementiert zustandsgesteuerte Filterung (stateful packet inspection) mindestens für den WAN-seitigen dynamischen Paketfilter. 21 Dies ist vom Einsatzszenario und der entsprechenden Konnektor-Konfiguration abhängig, siehe [27], Kapitel 2.7. Security Target secunet konnektor 2.1.0 secunet Seite 91 von 424 4.2. Sicherheitsziele für den Anwendungskonnektor Über die in Abschnitt 4.1 aufgeführten Sicherheitsziele für den Netzkonnektor hinaus werden die folgenden Sicherheitsziele für den Anwendungskonnektor definiert: 4.2.1. Allgemeine Sicherheitsziele O.AK.Basis_Krypto Kryptographische Algorithmen Der AK verwendet sichere kryptographische Algorithmen und Protokolle für die qualifizierte elektronische Signatur gemäß [12] und für alle anderen Kryptoverfahren des AK gemäß [19] mit den Einschränkungen der gematik Spezifikation für Kryptoalgorithmen [30]. O.AK.Admin Administration Der AK erlaubt die Durchführung administrativer Funktionen nur besonders berechtigten Benutzern nach erfolgreicher Authentisierung. Dies betrifft insbesondere das Management der eHealth-Kartenterminals, Einrichten des sicheren Datenspeichers, der Arbeitsplätze und die Aktivierung und Deaktivierung der Online Kommunikation, des Signaturdienstes und der Logischen Separation sowie das Management der Konfigurationsdaten der Fachmodule. Die Administration erfolgt über eine Managementschnittstelle. Der AK erzwingt die bezüglich Vertraulichkeit und Integrität geschützte Kommunikation zur Administration über die Managementschnittstelle. O.AK.EVG_Modifikation Schutz vor Veränderungen Der AK macht dem Nutzer zur Laufzeit sicherheitstechnische Veränderungen erkennbar. Dauerhaft gespeicherte geheime kryptographische Schlüssel sind vor Kompromittierung durch logische Angriffe zu schützen. O.AK.Selbsttest Selbsttests Der EVG führt beim Start-up und bei Bedarf Selbsttests durch. O.AK.Protokoll Sicherheitsprotokoll mit Zeitstempel Der AK protokolliert sicherheitsrelevante Ereignisse und stellt die erforderlichen Daten bereit. Diese Protokollierung ist nicht abschaltbar. Der AK stellt sicher, dass das Sicherheitsprotokoll weder von außen noch durch den Administrator verändert oder gelöscht werden kann. Security Target secunet konnektor 2.1.0 Seite 92 von 424 secunet O.AK.Zeit Systemzeit Der AK verwendet bei sicherheitsrelevanten Aktionen (etwa das Sicherheitsprotokoll, siehe O.AK.Protokoll) eine sichere Systemzeit. Dabei greift er auf die Echtzeituhr zurück (siehe OE.AK.Echtzeituhr), die in regelmäßigen Abständen vom Netzkonnektor mit einem vertrauenswürdigen Zeitdienst synchronisiert ist (siehe O.NK.Zeitdienst). O.AK.Infomodell Umsetzung des Informationsmodells durch den AK Der AK verwaltet die persistente Zuordnung von Mandanten, Clientsystemen, Arbeitsplätzen und Kartenterminals sowie die transiente Zuordnung von Benutzern der Arbeitsplätze, in Kartenterminals gesteckten Chipkarten und Kartensitzungen zur Durchsetzung einer Zugriffskontrolle über die den Mandanten zugeordneten Ressourcen, die Chipkarten der Benutzer der Arbeitsplätze und die Chipkarten in Übereinstimmung der für die Kartensitzung erreichten Sicherheitszustände. Anwendungshinweis 45: Das Informationsmodell des Konnektors ist in der Spezifikation [27], Kapitel 4.1.1.1 (PIC_Kon_100, Tab_Kon_507 bis Tab_Kon_510) beschrieben, Details sind dort zu entnehmen. O.AK.Update Software Update und Update von TSL, CRL und BnetzA-VL Bevor Updatedaten für den EVG oder andere Komponenten bereitgestellt werden, muss die Integrität und die Authentizität / Zulässigkeit der Updatedaten überprüft (Signaturprüfung und Prüfung der Identität des Signierenden) und Metadaten (zum Schutz gegen unbefugtes Wiedereinspielen veralteter Software-Versionen) angezeigt werden. Schlägt die Prüfung der Integrität fehl, verhindert der EVG die Bereitstellung der Updatedaten. Die Installation dieser Updates kann, je nach Konfiguration automatisch oder im manuellen Fall durch den Administrator erfolgen. Wenn der Konnektor die Update-Daten (Firmware-Update-Paket) über den KSR (Update-Server) bezieht, wird dazu ein sicherer Kanal zum KSR aufgebaut. Der AK bezieht die Trust-service Status List (TSL) und die Certificate Revocation List (CRL). Er bezieht ebenfalls die Vertrauensliste der Bundesnetzagentur (BNetzA-VL) über den TSL-Dienst, sofern diese in einer aktualisierten Version verfügbar ist. Der für die Aktualitätsprüfung vom TSL-Dienst bezogene Hash-Wert der BNetzA-VL muss auf dem Transportweg geschützt werden. Im Fall der erfolgreichen Prüfung der Integrität und Authentizität der genannten Listen wird der interne Speicher des EVG mit den Inhalten der bezogenen Listen aktualisiert. Der beschriebene Update-Vorgang für die Software des EVG bezieht explizit die Software des Netzkonnektors mit ein. Es steht dem Autor der Sicherheitsvorgaben frei, die Updatefunktion für Software komplett oder in Teilen durch den Netzkonnektor zu Security Target secunet konnektor 2.1.0 secunet Seite 93 von 424 implementieren. In diesem Fall ist dieses Sicherheitsziel und die entsprechenden Sicherheitsanforderungen anzupassen und in den Sicherheitsvorgaben des Netzkonnektors zu berücksichtigen. Weiterhin steht es dem Autor der Sicherheitsvorgaben frei, die Updatefunktion für Software auch für das Nachladen von geprüften und freigegebenen Fachmodulen zu verwenden. Hinweis: Das Sicherheitsziel O.AK.Update wurde unverändert aus dem zugrundeliegenden PP [16] übernommen. Die Freiheitsgrade des ST-Autors im letzten Absatz sind wie folgt umgesetzt: Die Updatefunktion für Software wird zusammen von Anwendungskonnektor und Netzkonnektor umgesetzt. Die Sicherheitsanforderungen zum Netzkonnektor wurden entsprechend angepasst. Die Updatefunktion kann indirekt zum Nachladen von geprüften und freigegebenen Fachmodulen verwendet werden. Dabei ist aber immer ein komplettes Software Update durchzuführen in dem entsprechende Fachmodule enthalten sind. Eine Funktion zum separaten nachladen von Fachmodulen, unabhängig vom Software Update des EVGs ist nicht implementiert. 4.2.2. Signaturdienst O.AK.Sig.SignQES Signaturrichtlinie für qualifizierte elektronische Signaturen Der AK unterstützt die Erzeugung qualifizierter elektronischer Signaturen für Dokumente in den Formaten Text, PDF/A, TIFF und XML22. Die Wohlgeformtheit der zu signierenden Dokumente wird gegen die entsprechende Format-Spezifikation geprüft. Bei reinen Textdokumenten (UTF-8 oder ISO-8859-15), PDF/A und TIFF wird die komplette Datei signiert. Die Signaturformate sind für XML, PDF/A, Text und TIFF das CadES [85] [88] sowie zusätzlich für PDF/A gemäß PAdES [86] [89] und für XML zusätzlich XAdES [82] [87]. Schlägt die Prüfung der Authentizität dieser TSF-Daten, die Prüfung der Wohlgeformtheit der zu signierenden Dokumente fehl oder kann nicht durchgeführt werden, wird dem Clientsystem über die Schnittstellen eine entsprechende Warnung ausgegeben. Anwendungshinweis 46: Die Signaturrichtlinie bestimmt, welche Daten durch den Signaturschlüsselinhaber signiert werden. Sie kann, z. B. im Fall von XML-Signaturen neben der Signaturerzeugung und der Signaturprüfung auch für die weitere automatische Verarbeitung des Dokumentes, beispielsweise für Fachanwendungen, genutzt werden. Deshalb sind die Regeln für die QES und die Verarbeitung aufeinander abzustimmen, um z. B. XML-Signature-Wrapping-Angriffe zu verhindern. Qualifizierte XAdES Signaturen werden ausschließlich unter Verwendung einer im Konnektor enthaltenen oder von Fachmodulen übergebenen Signaturrichtlinie erstellt und geprüft. Anmerkung 4. Nach O.AK.Sig.SignQES wird die Wohlgeformtheit der zu signierenden Dokumente gegen die entsprechende Format-Spezifikation geprüft. Das beinhaltet insbesondere die Prüfung gegen das in der NFDM-Signaturrichtline festgelegte XML Schema. 22 Dies entspricht dem Stand der Liste unterstützter Formate zum Zeitpunkt der Erstellung des ST. Security Target secunet konnektor 2.1.0 Seite 94 von 424 secunet O.AK.Sig.SignNonQES Signaturrichtlinie für nichtqualifizierte elektronische Signaturen Der AK erlaubt die Erzeugung von digitalen Signaturen für nicht-qualifizierte elektronische Signaturen für Dokumente in den Formaten Text, PDF/A, TIFF und von binären Dokumente sowie für Binärstrings23 . Die Wohlgeformtheit der zu signierenden Dokumente wird (außer für Binärdokumente) gegen die entsprechende Format-Spezifikation geprüft. Schlägt diese Prüfung der Wohlgeformtheit der zu signierenden Dokumente fehl oder kann nicht durchgeführt werden, wird eine entsprechende Fehlermeldung erzeugt. O.AK.Sig.exklusivZugriff Unterstützung bei alleiniger Kontrolle Der AK stellt Methoden zur Verfügung, die es dem Signaturschlüssel-Inhaber ermöglichen, die alleinige Kontrolle über die QSEE auszuüben. Der AK initiiert die Erzeugung qualifizierter elektronischer Signaturen nur für die vom autorisierten Benutzer über das Clientsystem übergebenen Daten. Der AK überwacht die Integrität der zum Signieren vom AK übergebenen Daten. Der AK überprüft, ob für die vom autorisierten Benutzer übergebenen Daten ordnungsgemäße qualifizierte elektronische Signaturen erstellt wurden. O.AK.Sig.Einfachsignatur Einfachsignatur Der AK unterstützt die Erzeugung qualifizierter elektronischer Signaturen durch eine Einfachsignatur gemäß [21] mit lokaler oder entfernter PIN-Eingabe. Der AK setzt die Authentisierung des Inhabers des HBAx mittels Eingabe der QES-PIN durch. Der AK steuert die Eingabe der QES-PIN am eHealth-Kartenterminal und die Erzeugung der digitalen Signatur durch den HBA für die vom autorisierten Benutzer über das Clientsystem übergebenen Daten. Bei festgestellten Abweichungen im Signaturprozess wird der Benutzer informiert und die erzeugte Signatur verworfen. O.AK.Sig.Stapelsignatur Stapelsignatur Der AK unterstützt die Erzeugung qualifizierter elektronischer Signaturen durch eine Stapelsignatur gemäß [21]. Der AK steuert die lokale oder entfernte Eingabe der QES-PIN am eHealth Kartenterminal und die Erzeugung der digitalen Signaturen durch den HBA. Der AK authentisiert sich gegenüber dem HBA mit der Identität „SAK“. Die Kommunikation zwischen AK und HBA ist per Secure Messaging geschützt. 23 Dies entspricht dem Stand der Liste unterstützter Formate zum Zeitpunkt der Erstellung des ST. Security Target secunet konnektor 2.1.0 secunet Seite 95 von 424 Der AK kontrolliert die Erzeugung qualifizierter elektronischer Signaturen für die vom autorisierten Benutzer über das Clientsystem übergebenen Daten. Bei festgestellten Abweichungen im Signaturprozess wird das Clientsystem über die Schnittstellen darüber informiert und alle Signaturen des Stapels verworfen. Der AK setzt den Sicherheitszustand des HBA, der nach erfolgreicher Authentisierung des Signaturschlüssel-Inhabers erlangt wurde, nach der Abarbeitung des Stapels zurück. Anwendungshinweis 47: Ein Benutzer des Clientsystems ist dann für die Auslösung des Signaturprozesses einer Stapelsignatur autorisiert, wenn der Benutzer sich an dem eHealth- Kartenterminal gegenüber dem dieser Benutzeridentität zugeordneten Heilberufsausweis erfolgreich mit der PIN.QES authentisiert hat (vergl. [21]). Anwendungshinweis 48: Ordnungsgemäße qualifizierte elektronische Signaturen sind solche fortgeschrittenen elektronischen Signaturen, die zu den Daten des Stapels mit dem Signaturschlüssel des Heilberufsausweises des autorisierten Benutzers des Clientsystems erzeugt wurden und zu dessen öffentlichen Signaturprüfschlüssel zum für die Signatur festgelegten Zeitpunkt ein gültiges qualifiziertes Zertifikat existiert. Dieser für die Signatur festgelegte Zeitpunkt bestimmt den Zeitpunkt der Prüfung der Gültigkeit des qualifizierten Zertifikats durch den AK. Es wird darauf hingewiesen, dass die Gültigkeit einer qualifizierte elektronische Signatur sich für den angegebenen Zeitpunkt der Signaturerstellung ergibt. Anwendungshinweis 49: Der Konnektor setzt die Einfach- und die Stapelsignatur und die Komfortsignatur um. Die Sicherheitsziele des PP [16] wurden entsprechend um das Sicherheitsziel O.AK.Sig.Komfortsignatur ergänzt. O.AK.Sig.Komfortsignatur Komfortsignatur Der AK unterstützt die Erzeugung qualifizierter elektronischer Signaturen durch eine Komfortsignatur. Der AK steuert die einmalige Eingabe der QES-PIN bei Aktivierung des Komfortsignaturmodus für eine HBA-Kartensitzung am eHealth Kartenterminal und die Erzeugung der digitalen Signaturen durch den HBA. Die bei Aktivierung des Komfortsignatur-Modus übergebene User-ID der HBA-Kartensitzung wird dem Authentisierungskontext der HBA-Kartensitzung zugeordnet und dient der Authentisierung des Clientsystems bei der Erzeugung von Komfortsignaturen. Der AK authentisiert sich gegenüber dem HBA mit der Identität „SAK“. Die Kommunikation zwischen AK und HBA ist per Secure Messaging geschützt. Der AK kontrolliert die Erzeugung qualifizierter elektronischer Signaturen für die vom autorisierten Benutzer über das Clientsystem übergebenen Daten. Bei festgestellten Abweichungen im Signaturprozess wird das Clientsystem über die Schnittstellen darüber informiert und die erzeugte Signatur verworfen. Der AK setzt den Sicherheitszustand der HBA-Kartensitzung, der nach erfolgreicher Authentisierung des Signaturschlüssel-Inhabers bei der Aktivierung der Komfortsignatur erlangt wurde, nach Ablauf eines konfigurierten Zeitraumes, nach der Durchführung einer konfigurierten Anzahl von Komfortsignaturen oder bei Deaktivierung des Komfortsignatur-Modus zurück. Anmerkung 5. Der secunet konnektor 2.1.0 unterstützt bis zu zwei parallele HBA- Kartensitzungen für die Komfortsignatur. Security Target secunet konnektor 2.1.0 Seite 96 von 424 secunet O.AK.Sig.Schlüsselinhaber Zuordnung des Signaturschlüssel-Inhabers Bei der Überprüfung der signierten Daten stellt der AK fest, welchem Signaturschlüssel- Inhaber die Signatur zuzuordnen ist oder dass eine solche Zuordnung nicht möglich ist. Im Fall der qualifizierten elektronischen Signatur ist das Prüfergebnis dem Benutzer des Clientsystems über die Schnittstellen bereitzustellen. O.AK.Sig.SignaturVerifizierung Verifizierung der Signatur Der AK prüft zuverlässig die Korrektheit digitaler Signaturen und stellt das Ergebnis der Prüfung an der Schnittstelle zum Clientsystem zur Verfügung. Der AK unterstützt für die Signaturprüfung die kryptographische Algorithmen gemäß [13]. Der AK unterstützt Formate signierter Dokumente gemäß CadES, PAdES und XAdES. Schlägt die Prüfung der Signatur fehl, wurden die Daten mit einem kryptographisch schwachen Signaturalgorithmus erzeugt oder kann die Signaturprüfung nicht durchgeführt werden, so wird eine entsprechende Warnung ausgegeben. O.AK.Sig.PrüfungZertifikat Prüfung des Signatur-Zertifikates Bei der Überprüfung qualifiziert und nicht-qualifiziert signierter Daten prüft der AK die Gültigkeit dieser Zertifikate, auf denen die Signatur beruht, zum Zeitpunkt der Erstellung der Signatur und stellt das Ergebnis der Prüfung an der Schnittstelle zum Clientsystem zur Verfügung. Diese Prüfung schließt ein, ob die für qualifizierte Zertifikate verwendeten Signaturalgorithmen zum Signaturprüfungszeitpunkt gemäß [19] als kryptographisch sicher gelten bzw. galten. 4.2.3. Gesicherte Kommunikation / TLS Proxy O.AK.LAN gesicherte Kommunikation im LAN der Leistungserbringer Der EVG bietet eine gesicherte Kommunikationsverbindung zum Clientsystem an, so dass Angriffe auf die Kommunikation durch Abhören, Manipulieren und Vorgeben einer falschen Identität zwischen Clientsystemen und dem EVG in beiden Richtungen abgewehrt werden können, sofern die Funktionalität durch die Clientsysteme ebenfalls unterstützt wird. Der EVG bietet dazu folgende Sicherheitsfunktionalität: Der Administrator kann durch Konfiguration sowohl  eine nur Server-seitige Authentisierung des EVGs gegenüber den Clientsystemen aktivieren als auch  eine gegenseitige Authentisierung zwischen Clientsystemen und EVG erzwingen. Security Target secunet konnektor 2.1.0 secunet Seite 97 von 424  Schließlich kann die Authentisierung zwischen Clientsystemen und EVG auch vollständig ausgeschaltet werden. In diesem Fall muss der Administrator bzw. der Betreiber des Konnektors den Kommunikationskanal durch geeignete organisatorische Maßnahmen absichern. Die gegenseitige Authentisierung zwischen Clientsystemen und EVG ist bei Auslieferung des EVGs voreingestellt. Sofern eine Authentisierung zwischen Clientsystemen und EVG konfiguriert wurde, wird die Kommunikation mit den Clientsystemen hinsichtlich ihrer Vertraulichkeit und Integrität geschützt. Der EVG authentisiert sich selbst gegenüber den Clientsystemen mit Hilfe von Schlüsselmaterial, welches auf dem Sicherheitsmodul gSMC-K gespeichert ist oder in den EVG importiert bzw. vom EVG generiert wurde. Anwendungshinweis 50: Über die Administrations-Schnittstelle des EVG können Clientsysteme dem EVG bekannt gemacht und deren Schlüsselmaterial (Zertifikate) importiert werden. Das führt zu einer Whitelist von erlaubten Clients, aus der auch Einträge wieder entfernt werden können. Es kann auch Schlüsselmaterial (Zertifikate) für die TLS-Kommunikation vom EVG generiert, exportiert (für Server nur die Zertifikate) und importiert werden. Anwendungshinweis 51: Der Endpunkt eines TLS-Kanals zwischen EVG und Clientsystemen kann sowohl in einem Terminal-Server liegen als auch in einem Client und damit näher am Arbeitsplatz des Nutzers. O.AK.WAN gesicherte Kommunikation zwischen EVG und Fachdiensten Der EVG bietet eine gesicherte Kommunikationsverbindung zu Fachdiensten bzw. Intermediären an, so dass Angriffe auf die Kommunikation durch Abhören, Manipulieren und Vorgeben einer falschen Identität zwischen Fachdiensten bzw. Intermediären und dem EVG in beiden Richtungen abgewehrt werden können, sofern die Funktionalität durch die Fachdienste bzw. Intermediäre ebenfalls unterstützt wird. Dazu können TLS Verbindungen zu Fachdiensten bzw. Intermediären auf- und abgebaut werden. Der EVG prüft die Authentizität des Server-Zertifikates (des Fachdienstes/Intermediärs). Eine Client-seitige Authentisierung des EVG kann mit einer SM-B erfolgen. O.AK.VAUSGD Geschützte Kommunikation mit VAU-Instanz und SGD-HSM Der EVG bietet eine gesicherte Kommunikationsverbindung mittels „VAU-Protokoll“ in die VAU-Instanz des ePA-Aktensystems und mittels „SGD-Protokoll“ in das SGD-HSM des Schlüsselgenerierungsdienst an, sodass das Abhören von Daten für diese Kommunikation unterbunden ist. Das VAU-Protokoll ist gemäß der Spezifikation [30] umgesetzt. Das SGD- Protokoll ist gemäß den Spezifikationen [48] und [30] umgesetzt. Security Target secunet konnektor 2.1.0 Seite 98 von 424 secunet 4.2.4. Terminal- und Chipkartendienst O.AK.exklusivZugriff Alleinige Kontrolle von Terminal und Karte Der AK stellt Methoden zur Verfügung, die es dem Benutzer ermöglichen, die alleinige Kontrolle über die verwendeten Kartenterminals und die verwendeten Chipkarten auszuüben. Nach Beendigung der Transaktion werden die Ressourcen wieder freigegeben. O.AK.PinManagement Management von Chipkarten-PINs Der AK ermöglicht das Ändern, Aktivieren und Deaktivieren von PINs der Chipkarten, das Abfragen der Status von PINs der Chipkarten sowie das Entsperren gesperrter Chipkarten- PINs. O.AK.IFD-Komm Schutz der Kommunikation mit den eHealth-Kartenterminals Der EVG authentisiert die eHealth-Kartenterminals, mit denen er gepaart ist, und schützt die Vertraulichkeit und Integrität seiner Kommunikation mit den eHealth-Kartenterminals durch einen entsprechend gesicherten Kanal. Der EVG stellt diesen Kanal bereit und kontrolliert dessen Nutzung. Anwendungshinweis 52: Es ist vorgesehen, aber durch den EVG nur im Zusammenwirken mit den eHealth-Kartenterminals durchsetzbar (s. OE.AK.Kartenterminal), dass die gesamte Kommunikation der Geräte im LAN des Leistungserbringers mit den eHealth- Kartenterminals über den EVG erfolgt. Das Pairing des Konnektors und der eHKT als Teil der Terminalverwaltung zur gegenseitigen Authentisierung zum Aufbau und der Betrieb des TLS-Kanals sind in [27] beschrieben. O.AK.Chipkartendienst Chipkartendienste des AK Der AK identifiziert Chipkarten an der ICCSN und zusätzlich im Fall der HBA, SMC und eGK den Chipkartentyp mit den in den Zertifikaten auf der Chipkarte enthaltenen Angaben.24 Der AK stellt einen Sicherheitsdienst zur Authentisierung der eGK und zur gegenseitigen Authentisierung zwischen Chipkarten (Card-to-Card-Authentisierung) in den angeschlossenen eHealth-Kartenterminals bereit. Der AK gewährt den Zugriff auf Chipkarten in Abhängigkeit von deren Sicherheitszustand und der Sicherheitspolitik des Anwendungsfalls. 24 Der Chipkartentyp (HBA, SMC und eGK) kann aus verschiedenen Quellen auf der jeweiligen Karte verlässlich bestimmt werden (bspw. CV-Zertifikat und X.509-Zertifikat). Bei der Personalisierung der Karten wird sichergestellt, dass die Konsistenz hinsichtlich des Kartentyps zwischen diesen Quellen gewahrt ist. Security Target secunet konnektor 2.1.0 secunet Seite 99 von 424 Anwendungshinweis 53: Eine erfolgreiche gegenseitige Card-to-Card-Authentisierung besagt nur, dass beide beteiligten Karten CVC aus derselben PKI besitzen und die Karten über die privaten Schlüssel zu den CVC verfügen. Folglich wird die Authentizität einer Chipkarte nur dann nachgewiesen oder widerlegt, wenn die andere Chipkarte bereits als authentisch bekannt ist. Der EVG stellt keinen eigenständigen, von der Nutzung einer bereits als authentisch bekannten Chipkarte unabhängigen Sicherheitsdienst zur Authentisierung von HBA und SMC-B bereit. Diese Authentizität der HBA und SMC-B in Kartenlesern des lokalen Netzes des Leistungserbringers ist durch den Leistungserbringer selbst zu gewährleisten, s. Sicherheitsziel für die Einsatzumgebung OE.AK.Karten. O.AK.VAD Schutz der Authentisierungsverifikationsdaten Der AK steuert die lokale und entfernte Eingabe von Authentisierungsverifikationsdaten der Benutzer der Chipkarten. Der AK unterstützt den Benutzer der entfernten Eingabe bei der Identifizierung des zu benutzenden PIN-Terminals durch die sichere Bereitstellung einer hinreichend eindeutigen Jobnummer für das Clientsystem und der späteren Anzeige der vom Clientsystem übergebenen Jobnummer am PIN-Terminal, die dem identifizierten Arbeitsplatz zugeordnet ist. Der AK initiiert die Eingabe der Signatur-PIN und Signatur-PUK des Signaturschlüssel-Inhabers bzw. der Kartenhalter-PIN und Kartenhalter-PUK des Kartenhalters im sicheren PIN-Modus am PIN-Terminal und deren vertrauliche und integritätsgeschützte Übermittlung im Secure Messaging Kanal zwischen der SMC im PIN- Terminal zur VAD-empfangenden Chipkarte im Chipkarten-Terminal. 4.2.5. Verschlüsselungsdienste O.AK.Enc Verschlüsselung von Daten Der AK verschlüsselt übergebene Daten gemäß der Verschlüsselungsrichtlinie der Fachanwendung bzw. des Anwendungsfalls für die über die Schnittstelle angegeben Empfänger, wenn deren Verschlüsselungszertifikate gültig sind. Es werden die Cryptographic Message Syntax [78] und XML-Encryption [79] unterstützt. O.AK.Dec Entschlüsselung von Daten Der AK entschlüsselt Daten, wenn die Verschlüsselungsrichtlinie und der Sicherheitszustand der Chipkarten mit den benötigten Entschlüsselungsschlüsseln dies erlauben. Security Target secunet konnektor 2.1.0 Seite 100 von 424 secunet 4.2.6. Fachmodule O.AK.VSDM Versichertenstammdatenmanagement Für eine Verbindung zwischen dem VSDM Fachmodul (als Bestandteil des EVG) und dem Fachdienst VSDD bzw. Intermediär VSDM erzwingt der EVG auf Anforderung des VSDM Moduls den Aufbau und die Nutzung eines TLS Kanals mit gegenseitiger Authentisierung. Für eine Verbindung zwischen dem Fachdienst VSDD oder dem CMS und einer gesteckten Chipkarte im eHealth-KT im LAN der Leistungserbringer erzwingt das VSDM Fachmodul den Aufbau und die Nutzung eines Secure Messaging Kanals. Nach Abbau des Secure Messaging Kanals zwischen Chipkarte und Fachdienst wird der TLS- Kanal durch den EVG abgebaut. Für alle Lesezugriffe auf geschützte Versichertenstammdaten (VSD) der eGK sowie für die Aktualisierung von VSD auf der eGK erzwingt das VSDM Fachmodul die Protokollierung auf der eGK. O.AK.VZD Kommunikation mit dem zentralen Verzeichnisdienst Der Konnektor stellt einen gesicherten Kanal vom LDAP-Proxy zum zentralen Verzeichnisdienst der TI-Plattform (VZD) bereit und ermöglicht es, durch Nutzung des LDAP-Proxy, Daten aus dem VZD abzufragen. 4.3. Sicherheitsziele für die Umgebung des Netzkonnektors Aus dem Schutzprofil BSI-CC-PP-0098 [16] sind folgende Sicherheitsziele für die Umgebung des Netzkonnektors übernommen. Dabei werden entsprechend dem Schutzprofil einige Sicherheitsziele für die Umgebung des Netzkonnektors bereits direkt vom Gesamtkonnektor oder dessen Umgebung erfüllt. Eine Abbildung der entsprechenden Sicherheitsziele aus 4.3 findet sich in Tabelle 10: Umgang mit Umgebungszielen des NK im EVG prüfen wieder. Die Einsatzumgebung des Netzkonnektors als Teil des EVG (IT-Umgebung oder non-IT- Umgebung) muss folgende Sicherheitsziele erfüllen: OE.NK.RNG Externer Zufallszahlengenerator Die Umgebung stellt dem EVG einen externen Zufallszahlengenerator bereit, der Zufallszahlen geprüfter Güte und Qualität gemäß den Anforderungen der Klasse PTG.2 oder PTG.3 aus [11] liefert. Security Target secunet konnektor 2.1.0 secunet Seite 101 von 424 Anwendungshinweis 54:Der Zufallszahlengenerator der gSMC-K wird als physikalischer Zufallszahlengenerator der Klasse PTG.2 als (Re-)Seed-Generator für den Zufallszahlengenerator des Betriebssystems genutzt (GET RANDOM Kommando). OE.NK.Echtzeituhr Echtzeituhr Die IT-Umgebung stellt dem EVG eine Echtzeituhr zur Verfügung, die gemäß O.NK.Zeitdienst synchronisiert werden kann. Die Echtzeituhr erfüllt die relevanten Anforderungen zur Freilaufgenauigkeit. Anwendungshinweis 55: Die Hardware des Konnektors muss eine Real Time Clock mit maximal zulässigem Drift von +/- 20ppm (part per million) zur Verfügung stellen (siehe Kapitel 1.3.6). Dies entspricht einer maximalen Abweichung im Freilauf von +/- 34,56 Sekunden über 20 Tage. Die Freilaufgenauigkeit garantiert eine Abweichung von weniger als 2 Sekunden pro Tag, so dass bei einer Synchronisation spätestens alle 24 Stunden der Zeitdienst des Konnektors um maximal 2 Sekunden ungenau ist. Anwendungshinweis 56: Das Umgebungsziel des Netzkonnektors OE.NK.Echtzeituhr wurde aus dem Schutzprofil BSI-CC-PP-0098 [16] entnommen und ist dem Netzkonnektor zugeordnet. Es ist nur zur Vollständigkeit hier aufgeführt, siehe dazu auch Anwendungshinweis 54 im Schutzprofil. OE.NK.Echtzeituhr wird durch das Umgebungsziel OE.AK.Echtzeituhr des Anwendungskonnektors eingeschlossen. Siehe auch Tabelle 10. OE.NK.Zeitsynchro Zeitsynchronisation Die IT-Umgebung (zentrale Telematikinfrastruktur-Plattform) stellt einen Dienst bereit (Zeitserver, die über einen VPN-Konzentrator für den Zugang zur Telematikinfrastruktur erreichbar sind), mit deren Hilfe der EVG die Echtzeituhr gemäß OE.NK.Echtzeituhr synchronisieren kann. Dieser Dienst muss über eine verlässliche Systemzeit verfügen, über einen sicheren Kanal erreichbar sein (Zeitserver stehen innerhalb der Telematikinfrastruktur) und hinreichend hoch verfügbar sein. OE.NK.gSMC-K Sicherheitsmodul gSMC-K Der EVG hat Zugriff auf ein Sicherheitsmodul gSMC-K, das sicher mit dem EVG verbunden ist. Sicher bedeutet in diesem Fall, dass die gSMC-K nicht unbemerkt vom EVG getrennt werden kann und dass die Kommunikation zwischen gSMC-K und EVG weder mitgelesen noch manipuliert werden kann. Security Target secunet konnektor 2.1.0 Seite 102 von 424 secunet Die gSMC-K dient als Schlüsselspeicher für das Schlüsselmaterial, welches die kryptographische Identität des EVG repräsentiert und welches auch für O.NK.VPN_Auth verwendet wird, und führt kryptographische Operationen mit diesem Schlüsselmaterial durch (Authentisierung), ohne dass das Schlüsselmaterial den sicheren Schlüsselspeicher dazu verlassen muss. Die gSMC-K stellt Zufallszahlen zur Schlüsselerzeugung bereit, die von einen Zufallszahlengenerator der Klasse PTG.2 oder PTG.3 erzeugt wurden. Außerdem enthält die gSMC-K Schlüsselmaterial zur Verifikation der Authentizität des VPN-Konzentrators. Anwendungshinweis 57: Der Konnektor verwendet nur von der gematik zugelassene Sicherheitsmodule gSMC-K, siehe 1.3.6. OE.NK.KeyStorage Sicherer Schlüsselspeicher Die IT-Umgebung (ein Teil des Gesamtkonnektors) stellt dem EVG einen sicheren Schlüsselspeicher bereit. Der sichere Schlüsselspeicher schützt sowohl die Vertraulichkeit als auch die Integrität des in ihm gespeicherten Schlüsselmaterials. Der Schlüsselspeicher wird vom NK verwendet zur Speicherung von privaten Schlüsseln, die zur Authentisierung beim Aufbau des VPN-Tunnels verwendet werden (kryptographische Identität des EVG, siehe FTP_ITC.1/NK.VPN_TI) oder im Rahmen des TLS- Verbindungsaufbaus (siehe FTP_ITC.1/NK.TLS). Zudem unterstützt der Schlüsselspeicher den EVG bei der sicheren Speicherung von Geheimnissen, wie zum Beispiel Sitzungsschlüssel (session keys). Sensitive Daten sowie die Konfigurations- und Protokolldaten eines Konnektors werden auf einem verschlüsselten Dateisystem (CFS) unter Verwendung eines geräteindividuellen Schlüssels abgelegt. Der Schlüssel dieses CFS wird mit privaten schlüsseln die in einem geschützten Bereich auf der gSMC-K abgelegt sind verschlüsselt. Anwendungshinweis 58:Der EVG verwendet als sicheren Schlüsselspeicher die gSMC-K. Darin sind auch die privaten Schlüssel zur Entschlüsselung des geräteindividuellen CFS- Schlüssels abgelegt. Die Sicherheit der im CFS abgelegten Daten ist damit wieder auf den sicheren Schlüsselspeicher der gSMC-K zurückzuführen. Sensitive Daten (z. B. VPN oder TLS session keys, Administrator Passwörter, DNSSEC Vertrauensanker) werden im CFS abgelegt. Die öffentlichen Prüfschlüssel zur Verifikation der eigenen Integrität (secure boot) sind in der FW/SW hardcodiert. Diese werden auch zur Verifikation der Authentizität von Software-Updates verwendet. Es ist (abgesehen vom CFS) kein eigener Schlüsselspeicher implementiert. Anwendungshinweis 59: Das Umgebungsziel des Netzkonnektors OE.NK.KeyStorage wird ganz oder teilweise durch die gSMC-K erbracht. Siehe auch Tabelle 10. Security Target secunet konnektor 2.1.0 secunet Seite 103 von 424 OE.NK.AK Korrekte Nutzung des EVG durch Anwendungskonnektor Anwendungskonnektoren müssen zu schützende Daten der TI und der Bestandsnetze, die durch Dienste gemäß § 291a SGB V [14] verarbeitet werden sollen, in korrekter Weise an den EVG übergeben, damit der EVG zu schützende Daten der TI und der Bestandsnetze über den entsprechenden VPN-Tunnel für Dienste gemäß § 291a SGB V versenden kann. Dazu müssen die Anwendungskonnektoren die vom EVG bereitgestellten Schnittstellen geeignet verwenden, so dass die Daten gemäß den gesetzlichen Anforderungen übertragen werden. Anwendungshinweis 60: Siehe auch A.NK.AK. Anwendungshinweis 61:Das Umgebungsziel des Netzkonnektors OE.NK.AK wurde aus dem Schutzprofil BSI-CC-PP-0098 [16] entnommen und ist dem Netzkonnektor zugeordnet. Es ist nur zur Vollständigkeit hier aufgeführt, siehe dazu auch Anwendungshinweis 54 im Schutzprofil. Siehe auch Tabelle 10. OE.NK.CS Korrekte Nutzung des Konnektors durch Clientsysteme und andere aktive Komponenten im LAN Die Hersteller von Clientsystemen müssen ihre Produkte so gestalten, dass diese den Konnektor für Dienste gemäß § 291a SGB V [14] korrekt aufrufen. Aufrufe von Diensten gemäß § 291a SGB V [14] müssen über den Anwendungskonnektor erfolgen. Der Zugriff auf Bestandsnetze und offene Fachanwendungen erfolgt nur durch aktive Komponenten im LAN in den vorgesehenen IP-Adressbereichen. OE.NK.Admin_EVG Sichere Administration des Netzkonnektors Der Betreiber des Netzkonnektors muss dafür sorgen, dass administrative Tätigkeiten der lokalen und zentralen Administration in Übereinstimmung mit der Administrator- Dokumentation des EVGs durchgeführt werden. Insbesondere muss für diese Tätigkeiten vertrauenswürdiges, mit der Benutzerdokumentation vertrautes, sachkundiges Personal eingesetzt werden. Die Administratoren müssen Authentisierungsinformationen und –token (z. B. PIN bzw. Passwort oder Schlüssel-Token) geheim halten bzw. dürfen diese nicht weitergeben. Wenn ein Konnektor und/oder sein Sicherheitsmodul gSMC-K gestohlen wird oder abhanden kommt, muss der Betreiber des EVGs den Betreiber der PKI (vgl. OE.NK.PKI) informieren. Dazu muss sichergestellt sein, dass gestohlene oder abhanden gekommene Geräte (gSMC-K oder NK) eindeutig identifiziert werden können. Anwendungshinweis 62: Der EVG verfügt zur Identifikation über eine eindeutige Seriennummer. Es wird organisatorisch sichergestellt, dass die Seriennummer bei Verlust des Gerätes noch vorliegt oder rekonstruiert werden kann, damit das Gerät bei der Verlustmeldung eindeutig identifiziert werden kann, so dass weitergehende Schritte (z. B. Sperrung des zugehörigen Zertifikats) eingeleitet werden können. Security Target secunet konnektor 2.1.0 Seite 104 von 424 secunet OE.NK.Admin_Auth Authentisierung des Administrators OE.NK.Admin_Auth aus PP [17] ist für den EVG nicht relevant, da der EVG die Authentisierung des Administrators selbst durchführt, siehe O.NK.Admin_Auth und Anwendungshinweis 63: Anwendungshinweis 63: Der Konnektor setzt eine übergreifende Administratorrolle um. Die Authentisierung des Konnektor-Administrators wird dabei vom Netzkonnektor vorgenommen. Das Umgebungsziel OE.NK.Admin_Auth des PP [17] wurde in das EVG-Ziel O.NK.Admin_Auth umgewandelt. Die funktionale Anforderung FMT_MSA.4/NK PP [17] wurde nicht in diesem ST übernommen, dafür wurde mit FIA_UAU.1/NK.SMR eine die Authentisierung des Administrators modellierende Anforderung in das ST aufgenommen. OE.NK.PKI Betrieb einer Public-Key-Infrastruktur und Verteilung der TSL Die Umgebung muss eine Public-Key-Infrastruktur bereitstellen, mit deren Hilfe der EVG im Rahmen der gegenseitigen Authentisierung die Gültigkeit der zur Authentisierung verwendeten Zertifikate prüfen kann. Dazu stellt die Umgebung Zertifikate zulässiger VPN- Konzentratoren für den Zugang in die Telematikinfrastruktur bereit bzw. Zertifikate der ausstellenden CAs. Wird eine Kompromittierung, Betriebsaufgabe oder Vertragsbeendigung eines VPN- Konzentrators, des Schlüsselmaterials eines VPN-Konzentrators, einer CA oder des Schlüsselmaterials einer CA bekannt, so reagiert der Betreiber der PKI geeignet, indem er je nach Erfordernis das zugehörige Zertifikat (des VPN-Konzentrators oder der CA) sperrt und diese Information (z. B. in Form einer Sperrliste (CRL)) für die Konnektoren bereitstellt, so dass EVGs mit kompromittierten VPN-Konzentratoren keine Verbindung mehr aufbauen. Meldet ein Konnektor-Betreiber seinen Konnektor und/oder dessen Sicherheitsmodul gSMC- K als gestohlen oder anderweitig abhanden gekommen, so sperrt der Betreiber der PKI das zugehörige Zertifikat und stellt diese Information (über eine CRL) für die VPN- Konzentratoren bereit, so dass diese mit dem abhanden gekommenen Konnektor keine Verbindung mehr aufbauen. OE.NK.phys_Schutz Physischer Schutz des EVG25 Die Sicherheitsmaßnahmen in der Umgebung müssen den Konnektor (während aktiver Datenverarbeitung im Konnektor) vor physischen Zugriff Unbefugter schützen. Befugt sind dabei nur durch den Betreiber des Konnektors namentlich autorisierte Personen (z. B. Leistungserbringer, ggf. medizinisches Personal). Sowohl während als auch außerhalb 25 Der EVG ist ein Einbox-Konnektor und kein verteilt betriebener Mehrkomponenten-Konnektors. Security Target secunet konnektor 2.1.0 secunet Seite 105 von 424 aktiver Datenverarbeitung im Konnektor müssen die Sicherheitsmaßnahmen in der Umgebung sicherstellen, dass ein Diebstahl des Konnektors und/oder Manipulationen am Konnektor so rechtzeitig erkannt werden, dass die einzuleitenden materiellen, organisatorischen und/oder personellen Maßnahmen größeren Schaden abwehren. Anwendungshinweis 64:Siehe auch A.NK.phys_Schutz resp. O.NK.Schutz. Anwendungshinweis 65:Das Umgebungsziel OE.NK.phys_Schutz des Netzkonnektors und das Umgebungsziel OE.AK.phys_Schutz des Anwendungskonnektors sind identisch formuliert. Letzteres fordert physischen Schutz des gesamten Konnektors. Siehe auch Tabelle 10. OE.NK.sichere_TI Sichere Telematikinfrastruktur-Plattform Die Betreiber der zentralen Telematikinfrastruktur-Plattform müssen sicherstellen, dass aus dem Netz der zentralen TI-Plattform heraus keine Angriffe gegen den Konnektor durchgeführt werden. Das schließt auch Angriffe auf den Konnektor oder auf die lokalen Netze der Leistungserbringer aus weiteren Netzen ein, die mit der TI verbunden sind (Bestandsnetze). Die Betreiber der Telematikinfrastruktur müssen dafür sorgen, dass die Server in der Telematikinfrastruktur frei von Schadsoftware gehalten werden, so dass über den sicheren VPN-Kanal in den Konnektor hinein keine Angriffe erfolgen. Dies impliziert, dass die VPN- Schlüssel auf Seiten des VPN-Konzentrators geheim gehalten werden müssen und nur für die rechtmäßigen Administratoren zugänglich sein dürfen. Alle Administratoren in der Telematikinfrastruktur müssen fachkundig und vertrauenswürdig sein. OE.NK.kein_DoS Keine denial-of-service-Angriffe Die Betreiber der zentralen Telematikinfrastruktur-Plattform müssen geeignete Gegenmaßnahmen treffen, um denial-of-service-Angriffe aus dem Transportnetz gegen die Telematikinfrastruktur abzuwehren. Anwendungshinweis 66:Siehe auch A.NK.kein_DoS. OE.NK.Betrieb_AK Sicherer Betrieb des Anwendungskonnektors Der Betreiber des Anwendungskonnektors muss diesen Betrieb in sicherer Art und Weise organisieren: Security Target secunet konnektor 2.1.0 Seite 106 von 424 secunet Er administriert die Anwendungskonnektoren in sicherer Art und Weise. Er trägt die Verantwortung dafür, dass die Anwendungskonnektoren und Fachmodule den EVG in der spezifizierten Art und Weise nutzen, also insbesondere die spezifizierten Konnektor-Schnittstellen korrekt nutzen. Anwendungshinweis 67:Das Umgebungsziel des Netzkonnektors OE.NK.Betrieb_AK wurde aus dem Schutzprofil BSI-CC-PP-0098 [16] entnommen und ist dem Netzkonnektors zugeordnet. Es ist nur zur Vollständigkeit hier aufgeführt, siehe dazu auch Anwendungshinweis 65 im Schutzprofil. Dieses Sicherheitsziel für die Umgebung des NK wird abgebildet auf die Sicherheitsziele OE.AK.Plattform und OE.AK.Personal des AK. Siehe auch Tabelle 10. OE.NK.Betrieb_CS Sicherer Betrieb der Clientsystems Der Betreiber der Clientsysteme muss diesen Betrieb in sicherer Art und Weise organisieren: Er setzt nur Clientsysteme ein, die nach dem aktuellen Stand der Technik entwickelt wurden und das spezifizierte Verhalten zeigen. Er administriert die Clientsysteme in sicherer Art und Weise. Er trägt die Verantwortung dafür, dass die Clientsysteme den EVG in der spezifizierten Art und Weise nutzen, also insbesondere die spezifizierten Konnektor-Schnittstellen korrekt nutzen. Er sorgt dafür, dass über Kanäle, die nicht der Kontrolle des Konnektors unterliegen (z. B. Einspielen von ausführbaren Dateien über lokale optische Laufwerke oder über USB-Stick, Öffnen von E-Mail-Anhängen) keine Schadsoftware auf die Clientsysteme oder andere IT- Systeme im LAN aufgebracht wird. Er ist verantwortlich dafür, dass eine Anbindung der Clientsysteme an potentiell unsichere Netze (z. B. Internet) unterbunden wird oder ausschließlich in sicherer Art und Weise erfolgt. Die Anbindung an unsichere Netze kann z. B. dadurch in sicherer Art und Weise erfolgen, dass es neben dem definierten Zugang zum Transportnetz über den EVG keine weiteren ungeschützten oder schlechter geschützten Zugänge zum Transportnetz gibt. Die Verantwortung für die Clientsysteme liegt sowohl beim Leistungserbringer (der z. B. lokal potentiell bösartige Software oder auch potentiell fehlerhafte Updates der Clientsystem- Software einspielen könnte) als auch beim Clientsystem-Hersteller (der z. B. den korrekten Aufruf der Konnektor-Schnittstellen sicherstellen muss). OE.NK.Ersatzverfahren Sichere Ersatzverfahren bei Ausfall der Infrastruktur Es müssen sichere Ersatzverfahren etabliert werden, auf die zurückgegriffen werden kann, wenn plötzliche Schwächen in den verwendeten kryptographischen Algorithmen bekannt werden, die nicht durch die redundanten Algorithmen ausgeglichen werden können. Security Target secunet konnektor 2.1.0 secunet Seite 107 von 424 OE.NK.SIS Sicherer Internet Service Die Umgebung stellt einen gesicherten Zugangspunkt zum Internet bereit. Dieser Zugangspunkt muss die dahinter liegenden Netze der Benutzer wirksam gegen Angriffe aus dem Internet schützen. Die Administration des Sicheren Internet Service muss dafür sorgen, dass dieses System frei von Schadsoftware gehalten wird, so dass keine Angriffe über den sicheren VPN-Kanal zum Konnektor von diesem Zugangspunkt ausgehen. Im Fall der Nutzung des SIS als VPN- Konzentrator impliziert dies, dass die VPN-Schlüssel auf Seiten des Sicheren Internet Service geheim gehalten werden müssen und nur für die rechtmäßigen Administratoren zugänglich sein dürfen. Alle Administratoren des Sicheren Internet Service müssen fachkundig und vertrauenswürdig sein. OE.NK.SW-Update Prozesse für sicheres Software-Update Die Einsatzumgebung etabliert Prozesse, die dafür sorgen, dass Update-Pakete und nachzuladende Fachmodule für den NK nur dann signiert und ausgeliefert werden, wenn der Code von einer dazu autorisierten Stelle geprüft und freigegeben wurde. Zertifizierte NK- Komponenten dürfen nur durch zertifizierte Komponenten ersetzt werden. Hinweis: Das Sicherheitsziel für die Umgebung des Netzkonnektors OE.NK.SW-Update ist identisch zum Sicherheitsziel für die Umgebung des Anwendungskonnektors OE.AK.SW-Update. Siehe auch Tabelle 10. Einige der vorgenannten Sicherheitsziele für die Umgebung des Netzkonnektors aus [16], Kapitel 4.3 werden durch den Gesamtkonnektor bereits auf anderer Weise umgesetzt. Diese Sicherheitsziele wurden aus dem NK-PP [17] in das zugrundliegende Schutzprofil nur zur Vollständigkeit übernommen. In den Sicherheitsvorgaben (Security Target) werden sämtliche Umgebungsziele des Schutzprofils [16] vollständig übernommen. Tabelle 10 enthält diese Sicherheitsziele zusammen mit der Erklärung, wie sie entsprechend dem zugrundeliegenden Schutzprofil behandelt werden. Sicherheitsziel aus BSI-CC-PP-0097 [17] Bemerkungen OE.NK.KeyStorage Sicherer Schlüsselspeicher: Dieser Schutz wird durch die gSMC- K erbracht, also entsprechend nicht vom EVG sondern von der Umgebung OE.NK.AK Korrekte Nutzung des Netzkonnektors durch Anwendungskonnektor Das Umgebungsziel des Netzkonnektors wurde aus dem Schutzprofil BSI-CC-PP-0097 [17] des Netzkonnektors in das zugrundeliegende Schutzprofil [16] übernommen und ist nur zur Vollständigkeit in den Sicherheitsvorgaben enthalten. Die korrekte Nutzung der NK-Schnittstellen durch den AK ist Security Target secunet konnektor 2.1.0 Seite 108 von 424 secunet Sicherheitsziel aus BSI-CC-PP-0097 [17] Bemerkungen Gegenstand der Evaluierung des EVG (u.a. CC-Klassen ADV und ATE). OE.NK.Admin_Auth Authentisierung des Administrators: Dieses Sicherheitsziel wird abgebildet auf das Sicherheitsziel O.AK.Admin des Anwendungskonnektors. Dies ist konsistent zum Schutzprofil BSI-CC-PP-0097, weil der Anwendungskonnektor des vorliegenden Schutzprofiles zur Umgebung des EVG aus BSI- CC-PP-0097 gehört. OE.NK.Betrieb_AK Sicherer Betrieb des Anwendungskonnektors: Dieses Sicherheitsziel für die Umgebung des NK wird abgebildet auf die Sicherheitsziele OE.AK.Plattform und OE.AK.Personal für die Umgebung des EVG, sowie die Sicherheitsziele O.AK.Admin und O.AK.EVG_Modifikation des AK. Die korrekte Nutzung der NK-Schnittstellen durch den EVG ist Gegenstand der Evaluierung des EVG. OE.NK.phys_Schutz Physischer Schutz des EVG. A.NK.phys_Schutz und A.phys_Schutz sind identisch formuliert. OE.NK.phys_Schutz und OE.phys_Schutz sind ebenfalls identisch formuliert. A.NK.phys_Schutz OE.NK.phys_Schutz beziehen sich aber nur auf den Netzkonnektor als Teil des aktuellen EVG, während sich A.phys_Schutz und OE.phys_Schutz auf den gesamten EVG beziehen. OE.NK.Echtzeituhr Für den Konnektor wurde OE.AK.Echtzeituhr aufgenommen. Tabelle 10: Umgang mit Umgebungszielen des NK im EVG 4.4. Sicherheitsziele für die Umgebung des Anwendungskonnektors Über die in Abschnitt 4.3 aufgeführten Sicherheitsziele für die Umgebung des Netzkonnektors hinaus werden folgende Sicherheitsziele für die Umgebung des EVG definiert: OE.AK.Versicherter Sorgfaltspflichten des Versicherten Der Versicherte darf seine eGK nur dann und nur dort einem HBA-Inhaber oder einem seiner Mitarbeiter aushändigen, wenn er diesem Zugriff auf seine Daten gewähren will. Nach Abschluss der Konsultation nimmt er seine eGK wieder an sich. Security Target secunet konnektor 2.1.0 secunet Seite 109 von 424 OE.AK.HBA-Inhaber Vertrauenswürdigkeit und Sorgfaltspflichten des HBA-Inhabers Der HBA-Inhaber und seine Mitarbeiter sind in Bezug auf den Umgang mit den ihm bzw. ihnen anvertrauten zu schützenden Daten vertrauenswürdig. Alle Leistungserbringer, die Zugriff auf medizinische Daten haben, welche auf Clientsystemen lokal gespeichert werden, gehen verantwortungsvoll mit diesen Daten um. Der Betreiber des Konnektors administriert seine IT-Umgebung in einer Art und Weise, die Missbrauchsmöglichkeiten minimiert. Der HBA-Inhaber verwendet seinen HBA nur in IT- Umgebungen, die wie im vorigen Satz beschrieben sicher administriert werden. OE.AK.SMC-B-PIN Freischaltung der SMC-B Der Karteninhaber stellt sicher, dass die SMC-B nur freigeschaltet ist, wenn sie und der Konnektor unter seiner Kontrolle arbeiten. Wenn der Karteninhaber keine Kontrolle mehr über den Konnektor oder die SMC-B hat, setzt er die Freischaltung der SMC-B zurück (z.B. durch Ausschalten des Kartenterminals oder Ziehen der Chipkarte). OE.AK.sichere_TI Sichere Telematikinfrastruktur-Plattform Die zentrale Telematikinfrastruktur-Plattform muss als vertrauenswürdig angesehen werden, d.h., es gibt keine Angriffe aus der zentralen Telematikinfrastruktur-Plattform und es ist sichergestellt, dass die zentrale Telematikinfrastruktur-Plattform die ihr anvertrauten Daten / Informationen nicht missbraucht. Zudem ist gewährleistet, dass die Dienste zentrale TI- Plattform die kryptographischen Vorgaben aus [16] erfüllen. Die Administration der Telematikinfrastruktur sorgt dafür, dass die Server in der Telematikinfrastruktur frei von Schadsoftware gehalten werden, so dass über bestehende Kanäle zum AK keine Angriffe auf den AK erfolgen. Alle Administratoren in der Telematikinfrastruktur sind fachkundig und vertrauenswürdig. OE.AK.Fachdienste vertrauenswürdige Fachdienste und zentrale Dienste der TI-Plattform Fachdienste, zentrale Dienste der TI-Plattform und deren Intermediäre werden als vertrauenswürdig angesehen. Es erfolgen keine Angriffe über bestehende Kommunikationskanäle auf den AK. Die Verbindungsschlüssel auf Seiten der Fachdienste, zentralen Dienste und Intermediäre werden geheim gehalten und sind nur für die rechtmäßigen Administratoren zugänglich. Fachdienste, zentrale Dienste, Intermediäre und deren Schlüsselmaterial werden vor Angriffen geschützt. Es wird angenommen, dass nur berechtigte Entitäten über die Telematikinfrastruktur auf Fachdienste, zentrale Dienste und Intermediäre zugreifen können. Dies wird durch technische oder organisatorische Security Target secunet konnektor 2.1.0 Seite 110 von 424 secunet Maßnahmen abgesichert. Wird dennoch ein Fachdienst/zentraler Dienst/Intermediär und/oder sein Schlüsselmaterial erfolgreich angegriffen, so werden die betroffenen Schlüssel zeitnah gesperrt. Alle genutzten kryptographischen Sicherheitsmechanismen werden im Einklang mit den relevanten Vorgaben des Dokuments TR-03116-1 [19] implementiert. Anwendungshinweis 68: Im Fall der Fachanwendung VSDD müssen insbesondere die Komponenten VSDD-Dienst und CMS in der beschriebenen Weise vertrauenswürdig sein. Kommunikationskanäle zwischen VSDD bzw. CMS und gesteckten eGK in einem eHealth KT in dem lokalen Netz der Leistungserbringer müssen durch Secure Messaging bezüglich Vertraulichkeit und Authentizität geschützt werden. Das dazu verwendete Schlüsselmaterial muss in der oben beschriebenen Weise geschützt werden. OE.AK.Admin_EVG Sichere Administration des Anwendungskonnektors Der Betreiber des Konnektors sorgt dafür, dass administrative Tätigkeiten in Übereinstimmung mit der Administrator-Dokumentation des EVG durchgeführt werden. Insbesondere wird für diese Tätigkeiten vertrauenswürdiges und hinreichend geschultes Personal eingesetzt. Der Administrator handelt nur im Sinne des verantwortlichen Leistungserbringers bzw. Konnektor-Betreibers und in dessen Auftrag. Der Administrator ist verantwortlich dafür, die automatische Aktualisierung des Konnektor zu konfigurieren und hat im Falle des manuellen anwendens von Aktualisierungen das Recht das Update anzustoßen. Der Administrator hält Authentisierungsinformationen und –token geheim bzw. gibt diese nicht weiter (z. B. PIN bzw. Passwort oder Schlüssel-Token). Der Administrator implementiert nur Vertrauenswürdige Komponenten (insbesondere eHealth-Kartenterminals) im Informationsmodell. Der Leistungserbringer als Nutzer des Konnektors hat die Verantwortung, die Eignung der aktuell genutztenen Konnektorfirmware-Version zu prüfen. Anwendungshinweis 69: Die Information der Benutzer des AKs, welche Firmware-Version aktuell genutzt wird, kann vom Administrator über die Managementschnittstelle ausgelesen werden. Der Konnektor unterstützt die automatische Aktualisierung („AutoUpdate“). Während der Konnektor aktualisiert wird, müssen die mit dem Konnektor gepairten eHealth-Kartenterminals organisatorisch genschützt werden. OE.AK.Admin_Konsole sichere Administratorkonsole Der Betreiber des EVG stellt sicher, dass die Administrationskonsole (die Benutzerschnittstelle zur Administration des EVG) vertrauenswürdig ist. An dieser Konsole vom Administrator eingegebene Authentisierungsgeheimnisse (z. B. Passwort, PIN, Passphrase) werden von der Konsole vertraulich behandelt und nicht zwischengespeichert. Die Konsole stellt Bildschirminhalte unverfälscht dar. Security Target secunet konnektor 2.1.0 secunet Seite 111 von 424 OE.AK.Kartenterminal sicheres Kartenterminal Als Kartenterminal werden nur Geräte eingesetzt, die nach dem Schutzprofil für das eHealth- Kartenterminals der elektronischen Gesundheitskarte [22] evaluiert und zertifiziert sind. Dies beinhaltet insbesondere, dass das Kartenterminal (1) die gegenseitige Authentisierung mit dem EVG und Nutzung eines TLS-Kanals für die festgelegten SICCT-Kommandos erzwingt und seine Authentisierung mit Pairing- Geheimnis unterstützt, (2) die Kommunikation nur mit höchstens einer Gegenstelle (über höchstens einem TLS- Kanal) zum Empfang von SICCT-Kommandos und zum Senden der dazugehörigen Antworten erlaubt, (3) dem Nutzer vom Kartenleser angezeigt wird, wenn dieser sich im sicheren PIN- Eingabemodus befindet, (4) Kommandos zur Erzeugung geschützter Kommandos zur PIN-Prüfung, zum PIN- Wechsel und zum Rücksetzen des Fehlbedienungszählers im sicheren PIN-Modus unterstützt, (5) die Tastatureingabedaten nur temporär im Kartenleser während der Eingabe gespeichert und nach der Übergabe an die Chipkarte wieder gelöscht werden, (6) die gesteckten Chipkarten bei Abbau des TLS-Kanals zurücksetzt (Reset), und (7) die Vorgaben der TR-03116-1 [16] erfüllt. OE.AK.Plattform sichere Plattform Die Plattform des EVG stellt dem EVG eine Ausführungsumgebung zur Verfügung, die den Konnektor selbst (z. B. seinen ausführbaren Code), die von ihm verarbeiteten Daten (sowohl flüchtige als auch ggf. persistent gespeicherte Daten) und die Fachmodule vor dem Zugriff durch Dritte (andere Programme, Prozesse, IT-Systeme o. ä.) schützt. OE.AK.SecAuthData Schutz der Authentisierungsdaten Die Benutzer schützen ihre Authentisierungsverifikationsdaten, d. h. die PIN und PUK der Chipkarten sowie Passwörter für die Authentisierung gegenüber dem EVG, vor Offenbarung und Missbrauch. Der Chipkarteninhaber darf seine PIN nur dann an einem Kartenterminal eingeben, wenn der initiierte Anwendungsfall dies erfordert und das Kartenterminal dem Chipkarteninhaber einen sicheren PIN-Eingabemodus anzeigt. Wird der Chipkarteninhaber von einem Kartenterminal zur PIN-Eingabe aufgefordert, ohne dass das Kartenterminal gleichzeitig den sicheren PIN-Eingabemodus anzeigt, muss der Chipkarteninhaber den Vorgang abbrechen und darf seine PIN nicht eingeben. Der Chipkarteninhaber kontrolliert, dass die PIN-Eingabe-Aufforderung (einschließlich Jobnummer) konsistent sowohl in seiner Clientsoftware, als auch auf dem PIN-Kartenterminal angezeigt wird. Security Target secunet konnektor 2.1.0 Seite 112 von 424 secunet OE.AK.phys_Schutz Physischer Schutz des EVG Die Sicherheitsmaßnahmen in der Umgebung müssen den Konnektor (während aktiver Datenverarbeitung im Konnektor) vor physischen Zugriff Unbefugter schützen. Befugt sind dabei nur durch den Betreiber des Konnektors namentlich autorisierte Personen (z. B. Leistungserbringer, ggf. medizinisches Personal). Sowohl während als auch außerhalb aktiver Datenverarbeitung im Konnektor müssen die Sicherheitsmaßnahmen in der Umgebung sicherstellen, dass ein Diebstahl des Konnektors und/oder Manipulationen am Konnektor so rechtzeitig erkannt werden, dass die einzuleitenden materiellen, organisatorischen und/oder personellen Maßnahmen größeren Schaden abwehren. Im Fall eines verteilt betriebenen Mehrkomponenten-Konnektors muss die Umgebung außerdem den Kommunikationskanal zwischen den Konnektorteilen Anwendungskonnektor und Netzkonnektor, sowie dem EVG und weiteren Komponenten des Konnektors während aktiver Datenverarbeitung vor physischem Zugriff schützen und außerhalb aktiver Datenverarbeitung physische Manipulation erkennen. OE.AK.Personal Qualifiziertes und vertrauenswürdiges Personal Durch den Einsatz von qualifiziertem und vertrauenswürdigem Personal werden Fehler und Manipulationen bei Installation, Betrieb, Nutzung, Wartung und Reparatur des EVG ausgeschlossen. Das Personal kontrolliert, ob der EVG sicherheitstechnische Veränderungen anzeigt, insbesondere nutzen die Benutzer des EVG die Möglichkeit, die Integrität des EVG durch ein besonders zu schützendes Testprogramm zu überprüfen. OE.AK.SMC Nutzung geeigneter SMC-B und gSMC-KT Es werden nur solche Chipkarten mit privaten Schlüsseln und CVC als SMC-B bzw. gSMC- KT und den relevanten Rollen für die dazugehörigen öffentlichen Schlüssel ausgestattet, wenn das Betriebssystem nach dem dafür vom BSI veröffentlichten Schutzprofilen evaluiert und zertifiziert sowie deren Objektsystem getestet wurden. Für die SMC Typ B wird gemäß Schutzprofil [15] insbesondere gewährleistet, dass die SMC-B für die Benutzung des Signaturschlüssels, des Entschlüsselungsschlüssels und der privaten Authentisierungs- schlüssel als SMC-B die erfolgreiche Authentisierung des Karteninhabers fordert. Die gSMC-KT kontrollieren den Zugriff auf das Schlüsselmaterial für den Trusted Channel zwischen einem eHealth-Kartenterminal und dem EVG. Die SMC verwenden nur sichere kryptographische Algorithmen gemäß [19]. Die genutzte SMC hat eine TR-Zertifizierung nach BSI TR-03144 erfolgreich durchlaufen (Nachweis der vertrauenswürdigen Initialisierung) und die Personalisierung der SMC ist sicher. Der Chipkartentyp SMC kann aus verschiedenen Quellen auf der jeweiligen Karte verlässlich bestimmt werden (bspw. CV-Zertifikat und X.509-Zertifikat). Bei der Personalisierung der Karten muss sichergestellt sein, dass die Konsistenz hinsichtlich des Kartentyps zwischen diesen Quellen gewahrt ist. Security Target secunet konnektor 2.1.0 secunet Seite 113 von 424 OE.AK.gSMC-K Nutzung einer gSMC-K Der EVG hat Zugriff auf ein Sicherheitsmodul (gSMC-K), das sicher mit dem EVG verbunden ist. Sicher bedeutet in diesem Fall, dass die gSMC-K nicht unbemerkt vom EVG getrennt werden kann und dass die Kommunikation zwischen gSMC-K und EVG weder mitgelesen noch manipuliert werden kann. Die gSMC-K dient als Schlüsselspeicher für das Schlüsselmaterial, welches die kryptographische Identität des EVG repräsentiert und von ihm verwendet wird. Es führt kryptographische Operationen mit diesem Schlüsselmaterial durch, ohne dass das Schlüsselmaterial den sicheren Schlüsselspeicher dazu verlassen muss. Die gSMC-K ist durch die gematik zugelassen. Die genutzte gSMC-K hat eine TR-Zertifizierung nach BSI TR-03144 erfolgreich durchlaufen (Nachweis der vertrauenswürdigen Initialisierung) und die Personalisierung der gSMC-K ist sicher. OE.AK.eGK Nutzung geeigneter eGK Chipkarten werden nur dann mit privaten Schlüsseln und CVC als „elektronische Gesundheitskarten“ (eGK) und der relevanten Rolle für den dazugehörigen öffentlichen Schlüssel ausgestattet, wenn deren Betriebssystem nach dem dafür vom BSI veröffentlichten Schutzprofil [15] evaluiert und zertifiziert sowie deren Objektsystem getestet wurden. Dies beinhaltet insbesondere, dass die eGK (1) für die Benutzung des Entschlüsselungsschlüssels PrK.CH.ENC die erfolgreiche Authentisierung des Karteninhabers erfordert, (2) für die Benutzung des Entschlüsselungsschlüssels PrK.CH.ENCV die erfolgreiche Authentisierung des Karteninhabers oder einer Card-to-Card-Authentisierung mit festgelegten Rollen erfordert, (3) nur sichere kryptographische Algorithmen gemäß [19] verwendet. Der Chipkartentyp eGK kann aus verschiedenen Quellen auf der jeweiligen Karte verlässlich bestimmt werden (bspw. CV-Zertifikat und X.509-Zertifikat). Bei der Personalisierung der Karten muss sichergestellt sein, dass die Konsistenz hinsichtlich des Kartentyps zwischen diesen Quellen gewahrt ist. OE.AK.HBA Nutzung einer qualifizierten Signaturerstellungseinheit Chipkarten werden nur dann mit privaten Schlüsseln und CVC als Heilberufsausweis und den relevanten Rollen für die dazugehörigen öffentlichen Schlüssel ausgestattet, wenn deren Betriebssystem nach dem dafür vom BSI veröffentlichten Schutzprofil [15] und der Spezifikation des Objektsystems [35] evaluiert sowie als qualifizierte Signaturerstellungseinheit für qualifizierte elektronische Signaturen nach eIDAS zertifiziert Security Target secunet konnektor 2.1.0 Seite 114 von 424 secunet wurde. Für die Erzeugung einer qualifizierten elektronischen Signatur verfügt der HBA über einen Signaturschlüssel und einen Signaturprüfschlüssel mit einem zum Zeitpunkt der Signatur gültigen qualifizierten Zertifikat. Dies beinhaltet auch, dass der HBA (1) für die Benutzung des Signaturschlüssels die erfolgreiche Authentisierung des Signaturschlüssel-Inhabers erfordert; (2) die DTBS für die Stapelsignatur nur in einem Secure Messaging Kanal akzeptiert werden, der durch eine mit C.SAK.AUTD_CVC authentisierte Gegenstelle aufgebaut wurde; (3) für die Benutzung des Entschlüsselungsschlüssels die erfolgreiche Authentisierung des Karteninhabers erfordert und (4) nur sichere kryptographische Algorithmen gemäß [19] verwendet. Der Chipkartentyp HBA kann aus verschiedenen Quellen auf der jeweiligen Karte verlässlich bestimmt werden (bspw. CV-Zertifikat und X.509-Zertifikat). Bei der Personalisierung der Karten muss sichergestellt sein, dass die Konsistenz hinsichtlich des Kartentyps zwischen diesen Quellen gewahrt ist. OE.AK.Karten Chipkarten im LAN des Leistungserbringers Der Leistungserbringer gewährleistet, dass nur authentische HBA und SMC-B in den Kartenlesern seines lokalen Netzes verwendet werden. Daten der eGK, die vor der Authentisierung der eGK gegenüber dem Konnektor gelesen werden, dürfen nur zur Identifizierung einer gesteckten Karte anhand des Kartenhandles verwendet werden. Elektronisch gespeicherte personenbezogene Daten auf der eGK dürfen nur nach erfolgreicher Authentisierung der eGK gegenüber dem Konnektor verwendet werden. OE.AK.PKI PKI für Signaturdienste, Verschlüsselung und technische Komponenten Der AK erhält Zugriff auf alle notwendigen Informationen, um zu entscheiden, ob die nachgeprüften qualifizierten Zertifikate im jeweiligen Zertifikat-Verzeichnis zum angegebenen Zeitpunkt vorhanden und nicht gesperrt waren. Dies beinhaltet auch die Verfügbarkeit einer stets aktuellen BNetzA-VL. Der Trusted Service Provider (TSP) sichert die Verfügbarkeit von OCSP-Diensten für die Zertifikate und einer stets aktuellen BNetzA- VL für die Zertifikate der qualifizierten elektronischen Signatur mit dem HBA, für Zertifikate für andere Signaturen und für Verschlüsselungszertifikate. Es werden CV Zertifikate nur für solche technischen Komponenten ausgestellt, die den technischen Spezifikationen entsprechen und – wenn vorgeschrieben – zertifiziert wurden. Für alle PKI werden die öffentlichen Schlüssel, bzw. Zertifikate der Vertrauensanker auf vertrauenswürdigem Weg verteilt. Der Betreiber des TSL-Dienstes sichert zu, dass nur die richtigen BNetzA-VL Signer- Zertifikate in die TSL eingebracht werden. Security Target secunet konnektor 2.1.0 secunet Seite 115 von 424 OE.AK.Clientsystem sichere Clientsysteme Die Clientsysteme, die mit dem EVG kommunizieren, müssen als vertrauenswürdig angesehen werden, d.h., es gibt keine Angriffe aus den Clientsystemen und es ist sichergestellt, dass sie die ihr anvertrauten Daten / Informationen nicht missbrauchen. Sofern ein Clientsystem eine gesicherte Kommunikation mit dem EVG unterstützt, muss das Schlüsselmaterial zum Aufbau und Betrieb des sicheren Kommunikationskanals adäquat geschützt werden. Dies gilt auch bei Verwendung von Terminal-Servern: Hier werden die Terminal-Server und die genutzten Thin-Clients in der angegebenen Weise als vertrauenswürdig angesehen. Alle genutzten kryptographischen Sicherheitsmechanismen werden im Einklang mit den relevanten Vorgaben des Dokuments TR-03116-1 [19] implementiert. Bei Verwendung der Komfortsignatur dient die User-ID zur Authentisierung des Clientsytems gegenüber dem Konnektor. Die User-ID muss vom Clientsystem sicher generiert werden. Die Authentifizierung des HBA-Inhabers für die Komfortsignatur muss vom Clientsystem vorgenommen werden. OE.AK.ClientsystemKorrekt Clientsysteme arbeiten korrekt und unterstützen das Informationsmodell Das Clientsystem arbeitet korrekt. Es führt fachliche Anwendungsfälle korrekt durch und nutzt die korrekten Daten. Es übergibt dem EVG die korrekten (vom Leistungserbringer intendierten) Daten. Sofern ein fachlicher Anwendungsfall durchgeführt werden soll, der einen HBA erfordert, identifiziert das Clientsystem den HBA-Inhaber bzw. den zu verwendenden HBA und das zuständige Fachmodul. Der Betreiber des Konnektors muss sicherstellen, dass die in seiner Umgebung betriebene Clientsystem-Software die Leistungserbringer (HBA-Inhaber) korrekt authentisiert. Das Clientsystem dient dem Leistungserbringer als Benutzerschnittstelle zum Konnektor. Es übermittelt die vom Leistungserbringer gewünschten Aufrufe an den Konnektor. Beim Aufruf des Konnektors mit einem Kartenzugriff übergibt das Clientsystem einen geeigneten Satz von Parametern, anhand dessen der Konnektor die Zuweisung oder Verweigerung von Sicherheitsstatus vornehmen kann. Das Clientsystem kontrolliert den Zugriff auf die Entschlüsselungsfunktion des Konnektors, so dass keine unkontrollierten Entschlüsselungen (ohne Zustimmung des HBA-Inhabers, z. B. durch nicht autorisiertes medizinisches Personal) möglich sind. Das Clientsystem kontrolliert den Zugriff auf die Verschlüsselungsfunktion des Konnektors, sodass keine nicht intendierten Verschlüsselungen oder nicht intendierte Empfänger an den Konnektor übergeben werden. Das Clientsystem stellt Rückmeldungen, Warnungen und Fehlermeldungen des Konnektors sowie über den Systeminformationsdienst gemeldete kritische Betriebszustände korrekt, sofort und verständlich dar. Das Clientsystem stellt im Rahmen der Erzeugung und Prüfung einer QES die Dokumente, Zertifikate, Jobnummer und Fortschrittsanzeige der Stapelsignatur korrekt und Security Target secunet konnektor 2.1.0 Seite 116 von 424 secunet vertrauenswürdig dar und ermöglicht die Nutzung der vom AK angebotenen Abbruchfunktion der Stapelsignatur. OE.AK.Benutzer_Signatur Prüfung zu signierender und zu prüfender Dokumente vor der Übermittlung an den AK Der Benutzer des Clientsystems muss vor der Übermittlung an den AK sicherstellen, dass er nur solche Daten zur Signaturerzeugung und zur Signaturprüfung über sein Clientsystem an den AK übergibt, welche er auch tatsächlich signieren bzw. verifizieren will. OE.AK.SW-Update Prozesse für sicheres Software-Update Die Einsatzumgebung etabliert Prozesse, die dafür sorgen, dass Update-Pakete und nachzuladende Fachmodule für den EVG nur dann signiert und ausgeliefert werden, wenn der Code von einer dazu autorisierten Stelle geprüft und freigegeben wurde. Zertifizierte EVG-Komponenten dürfen nur durch zertifizierte Komponenten ersetzt werden. Anwendungshinweis 70: Update-Dateien anderer Komponenten wie der Kartenterminals werden hier nicht erfasst OE.AK.Echtzeituhr Bereitstellung einer Echtzeituhr Die IT-Umgebung stellt dem EVG eine Echtzeituhr zur Verfügung, die für die EVG- Sicherheitsdienste zur Signaturerstellung und Protokollierung verwendet werden kann. Anwendungshinweis 71: Entsprechend Konnektor-Spezifikation [27] ist gefordert, dass falls LU_Online nicht aktiviert ist (MGM_LU_Online=Disabled), sichergestellt werden muss, dass der maximale zulässige Fehler von +/- 20ppm (part per million) gegenüber einer Referenzuhr nicht überschritten wird. Dies entspricht einer maximalen Abweichung im Freilauf von +/- 34,56 Sekunden über 20 Tage. Security Target secunet konnektor 2.1.0 secunet Seite 117 von 424 4.5. Erklärung der Sicherheitsziele 4.5.1. Überblick über die Sicherheitsziele des Netzkonnektors Die folgende Tabelle 11 bildet die Bedrohungen (Threats), organisatorischen Sicherheitspolitiken (OSPs) und Annahmen (Assumptions) auf Sicherheitsziele für den Netzkonnektor und dessen Umgebung ab. Bedrohung (T. ...) bzw. OSP bzw. Annahme (A. ...) O.NK.TLS _Krypto O.NK.Schutz O.NK.EVG_Authenticity O.NK.Admin_EVG O.AK.Protokoll O.NK.Zeitdienst O.NK.Update O.NK.Admin_Auth O.NK.VPN_Auth O.NK.Zert_Prüf O.NK.VPN_Vertraul O.NK.VPN_Integrität O.NK.PF_WAN O.NK.PF_LAN O.NK.Stateful OE.NK.RNG OE.NK.Echtzeituhr OE.NK.Zeitsynchro OE.NK.gSMC-K OE.NK.KeyStorage OE.NK.AK OE.NK.CS OE.NK.Admin_EVG OE.NK.PKI OE.NK.phys_Schutz OE.NK.sichere_TI OE.NK.kein_DoS OE.NK.Betrieb_AK OE.NK.Betrieb_CS OE.NK.Ersatzverfahren OE.NK.SIS OE.NK.SW-Update T.NK.local_EVG_LAN X X X X X X X T.NK.remote_EVG_W AN X X X X X X X X X X X X X X X X T.NK.remote_EVG_LA N X X X X X X X X X X X X X X X X X X X T.NK.remote_VPN_Dat a X X X X X X X X X X X X X X X X X T.NK.local_admin_LA N X X X X X X X X X X X X T.NK.remote_admin_W AN X X X X X X X X X X X T.NK.counterfeit X X X X T.NK.Zert_Prüf X X X X X X X T.NK.TimeSync X X X X X X X X X X X T.NK.DNS X X X X X OSP.NK.Zeitdienst X X X OSP.NK.SIS X X X OSP.NK.BOF X X X X X X X OSP.NK.TLS X OSP.NK.SW-Update X X X X A.NK.phys_Schutz X A.NK.gSMC-K X A.NK.sichere_TI X A.NK.kein_DoS X A.NK.AK X A.NK.CS X A.NK.Betrieb_AK X A.NK.Betrieb_CS X A.NK.Admin_EVG X A.NK.Ersatzverfahren X A.NK.Zugriff_gSMC-K X X Tabelle 11: Abbildung der Sicherheitsziele auf Bedrohungen und Annahmen Security Target secunet konnektor 2.1.0 Seite 118 von 424 secunet Ein Kreuz „X“ in einer Zelle bedeutet, dass die in der Zeile des Kreuzes stehende Bedrohung durch das in der Spalte des Kreuzes stehende Sicherheitsziel (für den EVG oder für die Umgebung) abgewehrt wird bzw. dass die in der Zeile des Kreuzes stehende Annahme auf das entsprechende Umgebungsziel abgebildet wird. Man beachte, dass Common Criteria die Abbildung von Annahmen auf EVG-Sicherheitsziele verbietet; der entsprechende Bereich der Tabelle ist daher grau schattiert. Die Abwehr einiger Bedrohungen wird zusätzlich zu den benannten Sicherheitszielen durch Assurance-Komponenten unterstützt: Die Abwehr von T.NK.local_EVG_LAN wird durch die Klasse ADV und die Familie AVA_VAN unterstützt. Die Abwehr von T.NK.counterfeit wird durch die Komponenten ALC_DEL.1 und AGD_OPE.1 unterstützt. Das Ziel OE.NK.Admin_EVG wird durch die Familie AGD_OPE unterstützt. Anwendungshinweis 72:Die Inhalte in Tabelle 11 und im folgenden Erklärungstext (4.5.3) wurden aus dem PP [16] übernommen. Hierbei wurden die optionalen Zuordnungen, im PP markiert durch (x), entsprechend übernommen oder entfernt. 4.5.2. Überblick über die Sicherheitsziele des Anwendungskonnektors O.AK.Basis_Krypto O.AK.Admin O.AK.IFD-Komm O.AK.Chipkartendienst O.AK.EVG_Modifikation O.AK.VAD O.AK.Enc O.AK.Dec O.AK.Sig.exklusivZugriff O.AK.Sig.SignQES O.AK.Sig.SignNonQES O.AK.Sig.Einfachsignatur O.AK.Sig.Stapelsignatur O.AK.Sig.Komfortsignatur O.AK.Sig.PrüfungZertifikat O.AK.Sig.Schlüsselinhaber O.AK.Sig.SignaturVerifizierung O.AK.Selbsttest O.AK.LAN O.AK.WAN O.AK.VAUSGD O.AK.Protokoll O.AK.Zeit O.AK.Update O.AK.exklusivZugriff O.AK.PinManagement O.AK.Infomodell O.AK.VSDM O.AK.VZD O.NK.Zeitdienst T.AK.DTBS X X T.AK.VAD X X T.AK.LAN.eHKT X X T.AK.LAN.CS X T.AK.WAN.TI X T.AK.LAN.Admin X T.AK.Kanal_Missbrauc h X X X X X X T.AK.Mani.EVG X X X X X X T.AK.Mani.Client X X X X T.AK.Mani.TI X X X T.AK.Mani.ExternerDi enst X X X T.AK.Mani.Chipkarte X X X X X T.AK.Mani.Terminal X X X X X T.AK.Mani.AdminKon sole X X X X Security Target secunet konnektor 2.1.0 secunet Seite 119 von 424 O.AK.Basis_Krypto O.AK.Admin O.AK.IFD-Komm O.AK.Chipkartendienst O.AK.EVG_Modifikation O.AK.VAD O.AK.Enc O.AK.Dec O.AK.Sig.exklusivZugriff O.AK.Sig.SignQES O.AK.Sig.SignNonQES O.AK.Sig.Einfachsignatur O.AK.Sig.Stapelsignatur O.AK.Sig.Komfortsignatur O.AK.Sig.PrüfungZertifikat O.AK.Sig.Schlüsselinhaber O.AK.Sig.SignaturVerifizierung O.AK.Selbsttest O.AK.LAN O.AK.WAN O.AK.VAUSGD O.AK.Protokoll O.AK.Zeit O.AK.Update O.AK.exklusivZugriff O.AK.PinManagement O.AK.Infomodell O.AK.VSDM O.AK.VZD O.NK.Zeitdienst T.AK.MissbrauchKarte X X X X X X T.AK.Fehlbedienung OSP.AK.MedSoc_Data X X X X X X X X X X X X X X OSP.AK.Konn_Spez X X X X X X X X X X X X X X X X OSP.AK.KryptAlgo X OSP.AK.SW-Update X X X X X OSP.AK.EVG_Modific ation X X X X OSP.AK.SC_Sign X X X X X OSP.AK.SC_Authorize d X X OSP.AK.SC_SVAD X OSP.AK.SC_Unaltered Data X X X X OSP.AK.SV_Certificat e X OSP.AK.SV_Signatory X OSP.AK.SV_Unaltered _Data X OSP.AK.Encryption X X OSP.AK.CardService X X OSP.AK.Fachanwendu ngen X X OSP.AK.VAUSGD X Tabelle 12: Abbildung der Sicherheitsziele des EVG auf Bedrohungen und OSPs OE.AK.Kartenterminal OE.AK.Plattform OE.AK.phys_Schutz OE.AK.SecAuthData OE.AK.Personal OE.AK.HBA OE.AK.SMC OE.AK.eGK OE.AK.Karten OE.AK.PKI OE.AK.Echtzeituhr OE.AK.Versicherter OE.AK.HBA-Inhaber OE.AK.SMC-B-PIN OE.AK.sichere_TI OE.AK.Fachdienste OE.AK.Admin_EVG OE.AK.Admin_Konsole OE.AK.Clientsystem OE.AK.ClientsystemKorrekt OE.AK.SW-Update OE.AK.gSMC-K OE.AK.Benutzer_Signatur OE.NK.Echtzeituhr OE.NK.Zeitsynchro T.AK.DTBS X X X X T.AK.VAD X X X T.AK.LAN.eHKT X T.AK.LAN.CS X T.AK.WAN.TI X Security Target secunet konnektor 2.1.0 Seite 120 von 424 secunet OE.AK.Kartenterminal OE.AK.Plattform OE.AK.phys_Schutz OE.AK.SecAuthData OE.AK.Personal OE.AK.HBA OE.AK.SMC OE.AK.eGK OE.AK.Karten OE.AK.PKI OE.AK.Echtzeituhr OE.AK.Versicherter OE.AK.HBA-Inhaber OE.AK.SMC-B-PIN OE.AK.sichere_TI OE.AK.Fachdienste OE.AK.Admin_EVG OE.AK.Admin_Konsole OE.AK.Clientsystem OE.AK.ClientsystemKorrekt OE.AK.SW-Update OE.AK.gSMC-K OE.AK.Benutzer_Signatur OE.NK.Echtzeituhr OE.NK.Zeitsynchro T.AK.LAN.Admin T.AK.Kanal_Missbrauc h X X X X T.AK.Mani.EVG X X X X X X T.AK.Mani.Client X X X X T.AK.Mani.TI X X X X T.AK.Mani.ExternerDi enst X X X X T.AK.Mani.Chipkarte X X X X X X X X X T.AK.Mani.Terminal X X X X X X T.AK.Mani.AdminKon sole X X X X T.AK.MissbrauchKarte X X X X X X X X T.AK.Fehlbedienung X X X X X OSP.AK.MedSoc_Data X X X X OSP.AK.Konn_Spez X X X X OSP.AK.KryptAlgo X X X X X X OSP.AK.SW-Update X X X X OSP.AK.EVG_Modific ation X X X X X X OSP.AK.SC_Sign OSP.AK.SC_Authorize d X X OSP.AK.SC_SVAD X X X OSP.AK.SC_Unaltered Data OSP.AK.SV_Certificat e X OSP.AK.SV_Signatory OSP.AK.SV_Unaltered _Data OSP.AK.Encryption X OSP.AK.CardService X OSP.AK.Fachanwendu ngen X OSP.AK.VAUSGD X A.AK.Cardterminal_eH ealth X A.AK.Konnektor X A.AK.Versicherter X A.AK.HBA-Inhaber X A.AK.SMC-B-PIN X A.AK.sichere_TI X A.AK.Admin_EVG X Security Target secunet konnektor 2.1.0 secunet Seite 121 von 424 OE.AK.Kartenterminal OE.AK.Plattform OE.AK.phys_Schutz OE.AK.SecAuthData OE.AK.Personal OE.AK.HBA OE.AK.SMC OE.AK.eGK OE.AK.Karten OE.AK.PKI OE.AK.Echtzeituhr OE.AK.Versicherter OE.AK.HBA-Inhaber OE.AK.SMC-B-PIN OE.AK.sichere_TI OE.AK.Fachdienste OE.AK.Admin_EVG OE.AK.Admin_Konsole OE.AK.Clientsystem OE.AK.ClientsystemKorrekt OE.AK.SW-Update OE.AK.gSMC-K OE.AK.Benutzer_Signatur OE.NK.Echtzeituhr OE.NK.Zeitsynchro A.AK.Env_Arbeitsplatz X X A.AK.phys_Schutz X A.AK.Chipkarteninhab er X X A.AK.QSCD X A.AK.SMC X A.AK.Benutzer_Signat ur X A.AK.gSMC-K X Tabelle 13: Abbildung der Sicherheitsziele der Umgebung auf Bedrohungen, OSPs und Annahmen 4.5.3. Detaillierte Erklärung für den Netzkonnektor 4.5.3.1. Bedrohungen gegen den Netzkonnektor In diesem Abschnitt wird der Nachweis geführt, dass die oben formulierten und in Tabelle 11 auf die Bedrohungen abgebildeten Sicherheitsziele geeignet sind, um die Bedrohungen abzuwehren. T.NK.local_EVG_LAN T.NK.local_EVG_LAN greift den EVG über seine LAN-Schnittstelle an. Der EVG filtert alle Nachrichten, die ihn auf dieser Schnittstelle erreichen, mit Hilfe des LAN-seitigen Paketfilters (O.NK.PF_LAN; mit grundlegender zustandsgesteuerter Filterungs-Funktionalität); dieser schützt den EVG vor Missbrauch und Manipulation aus möglicherweise kompromittierten lokalen Netzen der Leistungserbringer. Der EVG schützt auch den Anwendungskonnektor vor LAN-seitigen Angriffen (O.NK.PF_LAN) und trägt somit zur Abwehr der Bedrohung bei. Der dynamische Paketfilter wird dabei unterstützt von O.NK.Protokoll, indem sicherheitsrelevante Ereignisse (mit Zeitstempel O.NK.Zeitdienst, OE.NK.Echtzeituhr, OE.NK.Zeitsynchro) protokolliert werden (z. B. die letzte vorgenommene Konfigurationsänderung), und von O.NK.Schutz, indem Selbsttests durchgeführt werden, die Veränderungen der Integrität des EVG erkennen, und Geheimnisse nach Benutzung aktiv gelöscht werden. Für eine sichere Speicherung der Geheimnisse sorgt OE.NK.KeyStorage. Optional kann auch O.NK.Stateful bei der Abwehr von T.NK.local_EVG_LAN unterstützen, indem sicherheitsrelevante Ereignisse protokolliert werden. Siehe auch Anwendungshinweis 72:. Security Target secunet konnektor 2.1.0 Seite 122 von 424 secunet T.NK.remote_EVG_WAN T.NK.remote_EVG_WAN beschreibt einen Angriff aus dem Transportnetz, bei dem der EVG bzw. dessen Integrität bedroht wird. Angriffe aus dem Transportnetz werden durch den VPN- Tunnel und den Paketfilter mit Stateful Packet Inspection (zustandsgesteuerte Filterung) abgewehrt: Anfragen, die ein Angreifer mit Hilfe des VPN-Tunnels zu senden versucht, werden vom EVG als ungültig erkannt (weil der Angreifer die VPN-Schlüssel nicht kennt, O.NK.VPN_Integrität) und verworfen. Die gSMC-K speichert das für die Authentisierung des VPN-Kanals erforderliche Schlüsselmaterial (OE.NK.gSMC-K). Die Inhalte, die durch den VPN-Tunnel übertragen werden, sind nicht bösartig (OE.NK.sichere_TI). Anfragen außerhalb des VPN-Tunnels werden durch den dynamischen Paketfilter gefiltert (O.NK.PF_WAN) – der EVG schützt sich selbst mittels des WAN-seitigen Paketfilters. Der WAN-seitige Paketfilter bietet zustandsgesteuerte Filterung (stateful packet inspection, zustandsgesteuerte Filterung, O.NK.Stateful). Der dynamische Paketfilter wird dabei unterstützt von O.NK.Protokoll, indem sicherheitsrelevante Ereignisse mit Zeitstempel (O.NK.Zeitdienst, OE.NK.Echtzeituhr, OE.NK.Zeitsynchro) protokolliert werden (z. B. die letzte vorgenommene Konfigurationsänderung), und von O.NK.Schutz, indem Selbsttests durchgeführt werden, die Veränderungen der Integrität des EVG erkennen, und Geheimnisse nach Benutzung aktiv gelöscht werden. Für eine sichere Speicherung der Geheimnisse sorgt OE.NK.KeyStorage. Außerdem authentisieren sich die VPN-Partner gegenseitig zu Beginn der Kommunikation (O.NK.VPN_Auth). Im Rahmen der gegenseitigen Authentisierung wird eine Zertifikatsprüfung durchgeführt (O.NK.Zert_Prüf), die wiederum eine entsprechende PKI in der Umgebung voraussetzt (OE.NK.PKI). Im Rahmen der Gültigkeitsprüfung von Zertifikaten benötigt der EVG eine sichere Zeitquelle (O.NK.Zeitdienst, OE.NK.Echtzeituhr und regelmäßige Synchronisation mit einem Dienst in der Umgebung, OE.NK.Zeitsynchro). Die Schlüssel für die VPN-Authentisierung liegen im sicheren Schlüsselspeicher (OE.NK.KeyStorage). Die gSMC-K kann darüber hinaus als Lieferant für gute Zufallszahlen genutzt werden (OE.NK.RNG), die im Rahmen eines Challenge-Response-Protokolls zum Einsatz kommen können. Sichere Ersatzverfahren (OE.NK.Ersatzverfahren) unterstützen bei der Abwehr von Angriffen, die sich gegen Schwächen der beim VPN-Kanal genutzten kryptographischen Algorithmen und Protokollen richten. T.NK.remote_EVG_LAN Angriffe aus dem Transportnetz werden durch die VPN-Tunnel und den Paketfilter mit Stateful Packet Inspection (zustandsgesteuerte Filterung) abgewehrt: Anfragen, die ein Angreifer aus dem Transportnetz durch einen VPN-Tunnel zu senden versucht, werden vom EVG als ungültig erkannt (weil der Angreifer die VPN-Schlüssel nicht kennt, O.NK.VPN_Integrität) und verworfen. Die gSMC-K speichert das für den VPN-Kanal erforderliche Schlüsselmaterial (OE.NK.gSMC-K). Die Inhalte, die durch den VPN-Tunnel mit der zentralen TI-Plattform übertragen werden, sind nicht bösartig (OE.NK.sichere_TI). Anfragen außerhalb des VPN- Tunnels werden durch den dynamischen Paketfilter gefiltert (O.NK.PF_WAN); der EVG schützt durch diesen WAN-seitigen Paketfilter sich selbst und weitere dezentrale Komponenten im LAN der Leistungserbringer. Der WAN-seitige Paketfilter bietet zustandsgesteuerte Filterung (stateful packet inspection, zustandsgesteuerte Filterung, O.NK.Stateful). Der dynamische Paketfilter wird dabei unterstützt von O.NK.Protokoll, indem sicherheitsrelevante Ereignisse mit Zeitstempel (O.NK.Zeitdienst, OE.NK.Echtzeituhr, OE.NK.Zeitsynchro) protokolliert werden. Konnte ein Clientsystem bereits kompromittiert werden, so unterstützt auch der LAN- Security Target secunet konnektor 2.1.0 secunet Seite 123 von 424 seitige Paketfilter beim Schutz des EVG (O.NK.PF_LAN): Im Fall einer Einbox-Lösung schützt der EVG (O.NK.PF_LAN) auch den Anwendungskonnektor vor LAN-seitigen Angriffen und trägt somit zur Abwehr der Bedrohung bei. Der EVG wird – wie bei T.NK.remote_EVG_WAN – unterstützt von O.NK.Schutz, indem Selbsttests durchgeführt werden, die Veränderungen der Integrität des EVG erkennen, und Geheimnisse nach Benutzung aktiv gelöscht werden. Für eine sichere Speicherung der Geheimnisse sorgt OE.NK.KeyStorage. Mit den gleichen Argumenten wie bei T.NK.remote_EVG_WAN (der Aufbau des sicheren Kanals wird vorab durch eine gegenseitige Authentisierung geschützt, die wiederum eine Zertifikatsgültigkeitsprüfung und eine Überprüfung der Systemzeit umfasst), tragen auch die Ziele O.NK.VPN_Auth, O.NK.Zert_Prüf, OE.NK.PKI, O.NK.Zeitdienst, OE.NK.Zeitsynchro, OE.NK.KeyStorage, OE.NK.Ersatzverfahren und OE.NK.RNG zur Abwehr der Bedrohung bei. Angriffe aus dem Internet über den VPN-Tunnel vom Sicheren Internet Service (siehe Angriffspfad 3.2 in Abbildung 2) werden durch die Sicherheitsfunktionalität des Sicheren Internet Service verhindert (OE.NK.SIS). Entsprechende Zugriffe werden dadurch erkannt und vor der Weiterleitung über den VPN-Tunnel zum EVG blockiert. Zusätzlich kann der LAN- seitige Paketfilter (O.NK.PF_LAN) zum Schutz des LAN und des EVG beitragen. Konnte ein LAN dennoch kompromittiert werden, schützen die LAN-seitig installierten Maßnahmen zur Erkennung und Schutz vor bösartigem Code (OE.NK.Betrieb_CS) die Clientsysteme und den EVG. Optional kann auch O.NK.Stateful bei der Abwehr von T.NK.remote_EVG_LAN unterstützen, indem sicherheitsrelevante Ereignisse nicht nur – wie bei T.NK.remote_EVG_WAN – an der WAN-seitigen Schnittstelle, sondern auch an der LAN-seitigen Schnittstelle protokolliert werden (Schreiben von Audit-Daten zur späteren Auswertung mit dem Ziel zustandsgesteuerter Filterung). Siehe auch Anwendungshinweis 72:. T.NK.remote_VPN_Data Der VPN-Client verschlüsselt die Daten mit einem starken kryptographischen Algorithmus; der Angreifer kann daher ohne Kenntnis der Schlüssel die verschlüsselte Nachricht nicht entschlüsseln (O.NK.VPN_Vertraul). Die gSMC-K speichert das für den VPN-Kanal erforderliche Schlüsselmaterial (OE.NK.gSMC-K). Dass die VPN-Schlüssel auf Seiten der VPN-Konzentratoren geheim gehalten werden, dafür sorgen OE.NK.sichere_TI und OE.NK.SIS. Dass die richtigen Daten auch tatsächlich verschlüsselt werden, dafür sorgt OE.NK.AK, indem zu schützende Daten der TI und der Bestandsnetze vom Anwendungskonnektor für den EVG erkennbar gemacht werden, unterstützt von OE.NK.Betrieb_AK (sicherer Betrieb des Anwendungskonnektors) und OE.NK.Betrieb_CS (sicherer Betrieb der Clientsysteme). Der VPN-Client vollzieht die Entschlüsselung von Daten, die ihm ein VPN-Konzentrator verschlüsselt zugesendet hat. Die Nutzdaten werden beim Senden integritätsgeschützt übertragen und beim Empfang auf ihre Integrität hin überprüft (O.NK.VPN_Integrität), was Manipulationen ausschließt. Mit den gleichen Argumenten wie bei T.NK.remote_EVG_WAN (der Aufbau des sicheren Kanals wird vorab durch eine gegenseitige Authentisierung geschützt, die wiederum eine Zertifikatsgültigkeitsprüfung und eine Überprüfung der Systemzeit umfasst), tragen auch die Security Target secunet konnektor 2.1.0 Seite 124 von 424 secunet Ziele O.NK.VPN_Auth, O.NK.Zert_Prüf, OE.NK.PKI, O.NK.Zeitdienst, OE.NK.Zeitsynchro, OE.NK.KeyStorage, OE.NK.Ersatzverfahren und OE.NK.RNG zur Abwehr der Bedrohung bei. Anwendungshinweis 73:O.NK.Protokoll (Sicherheits-Log) wird im ST nicht bei der Abwehr von T.NK.remote_VPN_Data berücksichtigt. Siehe auch Anwendungshinweis 72:. T.NK.local_admin_LAN T.NK.local_admin_LAN betrachtet Angriffe im Zusammenhang mit lokaler Administration des EVG. Der EVG muss dazu eine Zugriffskontrolle implementieren (O.NK.Admin_EVG), so dass Administration nur durch Administratoren nach erfolgreicher Authentisierung (O.NK.Admin_Auth) möglich ist. Die Administratoren halten dazu ihre Authentisierungsinformationen geheim (OE.NK.Admin_EVG) und verhindern so, dass sich ein Angreifer dem EVG gegenüber als Administrator ausgeben kann. Dies wehrt bereits wesentliche Teile des beschriebenen Angriffs ab. Weitere Teilaspekte des Angriffs, insbesondere der Zugriff auf Schlüssel, werden durch weitere Ziele verhindert: Der Zugriff auf kryptographische Schlüssel und andere Geheimnisse im Arbeitsspeicher des EVGs wird durch entsprechende Speicheraufbereitung verhindert (aktives Löschen nach Verwendung der Geheimnisse, O.NK.Schutz). Für eine sichere Speicherung der Geheimnisse sorgt OE.NK.KeyStorage. Administrative Tätigkeiten können im Sicherheits-Log mit Zeitstempel (O.NK.Zeitdienst, OE.NK.Echtzeituhr, OE.NK.Zeitsynchro) nachvollzogen werden (O.NK.Protokoll). Die gSMC-K kann darüber hinaus als Lieferant für gute Zufallszahlen genutzt werden (OE.NK.RNG), die im Rahmen eines Challenge-Response-Protokolls zum Einsatz kommen können. Für die Administration wird ein sicherer TLS Kanal aufgebaut. Hinsichtlich der dabei verwendeten kryptographischen Verfahren trägt OE.NK.Ersatzverfahren zur Abwehr von T.NK.local_admin_LAN bei. Durch OE.NK.phys_Schutz ist der Kommunikationskanals zwischen dem EVG und weiteren Komponenten des Konnektors vor Manipulationen geschützt. Anwendungshinweis 74:Im Rahmen der Administration kommen kryptographische Verfahren zum Einsatz (Implementierung eines sicheren Kanals). Damit trägt auch OE.NK.Ersatzverfahren zur Abwehr von T.NK.local_admin_LAN und T.NK.remote_admin_WAN bei. OE.NK.phys_Schutz trägt zur Abwehr von T.NK.local_admin_LAN beitragen, da durch den Schutz des Kommunikationskanals zwischen dem EVG und weiteren Komponenten des Konnektors Manipulationen am Gerät verhindert werden können. Siehe auch Anwendungshinweis 72: (Anpassung des Security Targets bei Bedarf). T.NK.remote_admin_WAN T.NK.remote_admin_WAN betrachtet Angriffe im Zusammenhang mit zentraler Administration. Der Unterschied im Angriffspfad zwischen T.NK.remote_admin_WAN und T.NK.local_admin_LAN besteht darin, dass der Angreifer bei T.NK.remote_admin_WAN aus dem Transportnetz heraus versucht, seinen Angriff durchzuführen, während bei T.NK.local_admin_LAN die Angriffsversuche aus dem lokalen Netz heraus durchgeführt werden. Bei der Abwehr sind jedoch die gleichen Mechanismen beteiligt (Zugriffskontrolle, Authentisierung des Administrators, Selbstschutz, Protokollierung) und diese wirken unabhängig vom Ursprungsort des Angriffsversuchs, daher gilt hier sinngemäß das gleiche wie unter T.NK.local_admin_LAN. Zur Abwehr tragen die Ziele O.NK.Admin_EVG, Security Target secunet konnektor 2.1.0 secunet Seite 125 von 424 O.NK.Admin_Auth, OE.NK.Admin_EVG, OE.NK.RNG, O.NK.Protokoll, O.NK.Zeitdienst, OE.NK.Echtzeituhr, OE.NK.Zeitsynchro, O.NK.Schutz und OE.NK.KeyStorage bei. Für die Administration wird ein sicherer TLS Kanal aufgebaut. Hinsichtlich der dabei verwendeten kryptographischen Verfahren trägt OE.NK.Ersatzverfahren zur Abwehr von T.NK.remote_admin_WAN bei. T.NK.counterfeit Bei der Bedrohung T.NK.counterfeit bringt ein Angreifer unbemerkt gefälschte Konnektoren in Umlauf. Neben der durch die Vertrauenswürdigkeitskomponente ALC_DEL.1 geforderten Überprüfung des Auslieferungsverfahrens und entsprechenden Verfahren zur Inbetriebnahme (AGD_OPE.1) ermöglicht der EVG auf Anforderung einen Nachweis seiner Authentizität (O.NK.EVG_Authenticity), der durch die kryptographische Identität im Sicherheitsmodul gSMC-K unterstützt wird (OE.NK.gSMC-K). Der EVG wird an einem zutrittsgeschützten Ort aufbewahrt (OE.NK.phys_Schutz), wodurch ein Entwenden erschwert wird. Sichere Ersatzverfahren (OE.NK.Ersatzverfahren) unterstützen bei der Abwehr aller Angriffe, die sich gegen Schwächen in kryptographischen Algorithmen und Protokollen richten, also auch bei Schwächen, die sich auf die kryptographische Identität beziehen. T.NK.Zert_Prüf Bei der Bedrohung T.NK.Zert_Prüf manipuliert ein Angreifer Sperrlisten, die zum Zwecke der Gültigkeitsprüfung von Zertifikaten von einem netzbasierten Dienst verteilt werden. Dieser Angriff wird durch das Ziel O.NK.Zert_Prüf auf Basis der über OE.NK.PKI erhaltenen Informationen abgewehrt. Sichere Ersatzverfahren (OE.NK.Ersatzverfahren) unterstützen bei der Abwehr von Angriffen, die sich gegen Schwächen der bei den Zertifikaten genutzten kryptographischen Algorithmen richten. Im Rahmen der Gültigkeitsprüfung von Zertifikaten werden Plausibilitätsprüfungen durchgeführt, welche die Echtzeit des EVG verwenden; somit trägt auch O.NK.Zeitdienst, OE.NK.Echtzeituhr, OE.NK.Zeitsynchro zur Abwehr von T.NK.Zert_Prüf bei. Zudem trägt auch O.NK.Protokoll und der Paketfilter gemäß O.NK.PF_WAN und entsprechend O.NK.Stateful zur Abwehr von T.NK.Zert_Prüf bei, da fehlgeschlagene oder erfolgreiche Updates der Sperrlisten protokolliert werden. Zum Aufbau des sicheren Kanals zu den Netzdiensten werden Schlüssel verwendet, die in der gSMC-K gespeichert sind, daher unterstützt OE.NK.gSMC-K bei der Abwehr von T.NK.Zert_Prüf. Ein externer Zufallszahlengenerator (OE.NK.RNG) wird darüber hinaus als Lieferant für gute Zufallszahlen genutzt, die im Rahmen eines Challenge-Response-Protokolls zum Einsatz kommen. Anwendungshinweis 75:.O.NK.Zeitdienst, OE.NK.Echtzeituhr, OE.NK.Zeitsynchro, O.NK.Protokoll, OE.NK.gSMC-K, OE.NK.RNG, O.NK.PF_WAN und entsprechend O.NK.Stateful tragen zur Abwehr von T.NK.Zert_Prüf bei. T.NK.TimeSync T.NK.TimeSync beschreibt den Angriff, dass Nachrichten manipuliert werden, die im Rahmen einer Zeitsynchronisation mit einem netzbasierten Dienst ausgetauscht werden, um auf dem EVG die Einstellung einer falschen Echtzeit zu bewirken. Dieser Angriff wird durch das Ziel O.NK.Zeitdienst abgewehrt, da dieses die Synchronisation der durch die Umgebung Security Target secunet konnektor 2.1.0 Seite 126 von 424 secunet bereitgestellte Echtzeituhr (OE.NK.Echtzeituhr) über einen sicheren Kanal fordert. Weil der Zeitdienst innerhalb der zentralen Telematikinfrastruktur-Plattform bereitgestellt wird, dient bereits der VPN-Tunnel zu dem VPN-Konzentrator für den Zugang zur Telematikinfrastruktur als sicherer Kanal (O.NK.VPN_Integrität). Die gSMC-K speichert das für den VPN-Kanal erforderliche Schlüsselmaterial (OE.NK.gSMC-K). Die gSMC-K kann darüber hinaus als Lieferant für gute Zufallszahlen genutzt werden (OE.NK.RNG), die im Rahmen eines Challenge- Response-Protokolls zum Einsatz kommen können. Beim Aufbau des Kanals werden die Kummunikationspartner authentisiert (O.NK.VPN_Auth) und Zertifikat geprüft (O.NK.Zert_Prüf) gegen die PKI der TI (OE.NK.PKI). Sichere Ersatzverfahren (OE.NK.Ersatzverfahren) unterstützen bei der Abwehr von Angriffen, die sich gegen Schwächen der beim VPN-Kanal genutzten kryptographischen Algorithmen richten. Die Zeitserver, die über eine verlässliche Systemzeit verfügen und somit die Basis für eine vertrauenswürdige Zeitinformation im Rahmen der Synchronisierung bilden, werden durch die Umgebung bereitgestellt (OE.NK.Zeitsynchro); außerdem liegen sie innerhalb der Telematikinfrastruktur und bilden somit die Gegenseite des sicheren Kanals. Zudem trägt O.NK.Protokoll zur Abwehr der Bedrohungen bei, da erfolgreiche oder fehlgeschlagene Zeitsynchronisation protokolliert wird. Anwendungshinweis 76: O.NK.Protokoll, OE.NK.gSMC-K, OE.NK.RNG, OE.NK.PKI und OE.NK.Ersatzverfahren tragen zur Abwehr von T.NK.TimeSync bei. T.NK.DNS Die Bedrohung T.NK.DNS beschreibt einen Angriff aus dem Transportnetz, bei dem Antworten auf DNS-Anfragen gefälscht werden. Solche DNS-Anfragen an DNS-Server im Transportnetz bzw. im Internet kommen nur in solchen Szenarien vor, bei denen Adressen im Transportnetz bzw. Internet aufgelöst werden sollen26 . Der Netzkonnektor löst die öffentlichen Adressen der VPN-Konzentratoren mittels DNS-Anfragen auf. Bei erfolgtem Angriff bekommt er nicht die gewünschte Adresse zurück. Das führt aber dazu, dass er keinen VPN-Kanal aufbauen kann, da durch das Sicherheitsziel O.NK.VPN_Auth die Authentisierung der VPN- Konzentratoren erforderlich ist. Dabei findet eine Zertifikatsprüfung statt (O.NK.Zert_Prüf) gegen die PKI der TI (OE.NK.PKI). Sichere Ersatzverfahren (OE.NK.Ersatzverfahren) unterstützen bei der Abwehr von Angriffen, die sich gegen Schwächen der bei den Zertifikaten genutzten kryptographischen Algorithmen richten. Damit erlangt der Angreifer keinen Zugriff auf das LAN des Leistungserbringers und kann die zu schützenden Daten nicht angreifen. Bei versuchtem Angriff kann dieser unter Umständen durch den Paketfilter des Netzkonnektors erkannt und verhindert werden (O.NK.PF_WAN, O.NK.Stateful). Dies hängt einerseits vom Vorgehen des Angreifers und andererseits von der Funktionalität des Paketfilters ab. Bei erkanntem Angriff erfolgt ferner ein Eintrag mit Zeitstempel (O.NK.Zeitdienst, OE.NK.Echtzeituhr, OE.NK.Zeitsynchro) in das Sicherheitsprotokoll (O.NK.Protokoll). Im Fall einer DNS-Auflösung durch Clientsysteme beim Zugriff auf das Internet führt die Manipulation der DNS-Antwort dazu, dass Clientsysteme auf Seiten umgelenkt werden können, die nicht ihrer ursprünglichen Intention entsprechen. Erfolgt dies vom Benutzer unbemerkt, können bei bösartigen Systemen die Clientsysteme durch bösartigen Code infiziert 26 Für Namensauflösungen innerhalb der TI und der darin angeschlossenen Netzwerke stellt die TI eigene DNS- Server bereit, die vom Transportnetz bzw. Internet nicht erreichbar sind. Security Target secunet konnektor 2.1.0 secunet Seite 127 von 424 werden. Dies kann einerseits durch Erkennungsmechanismen im SIS verhindert werden, welches wirksame Maßnahmen gegen Angriffe aus dem Internet implementieren soll (OE.NK.SIS). In jedem Fall muss der bösartige Code auf den Clientsystemen aber durch Mechanismen auf den Clientsystemen (Einsatz von sicheren Produkten und Virenscannern) erkannt und neutralisiert werden (OE.NK.Betrieb_CS). 4.5.3.2. Organisatorische Sicherheitspolitiken für den Netzkonnektor OSP.NK.Zeitdienst Die organisatorische Sicherheitspolitik OSP.NK.Zeitdienst fordert einen Zeitdienst sowie eine regelmäßige Zeitsynchronisation mit Zeitservern. Die regelmäßige Zeitsynchronisation wird durch O.NK.Zeitdienst gefordert. Die Echtzeituhr, welche im Rahmen der Zeitsynchronisation synchronisiert wird, wird durch die Umgebung (OE.NK.Echtzeituhr) bereitgestellt; ohne die Echtzeituhr gäbe es kein Ziel für die im Rahmen der Zeitsynchronisation ausgetauschten Zeitinformationen und der EVG könnte keinen Zeitdienst anbieten, daher unterstützt dieses Umgebungsziel ebenfalls die OSP.NK.Zeitdienst. Damit die Zeitsynchronisation stattfinden kann und im Rahmen der Synchronisation die korrekte Zeit ausgetauscht wird, bedarf es einer Menge von Zeitservern, welche über eine verlässliche Systemzeit verfügen; diese Zeitserver werden durch die Umgebung bereitgestellt (OE.NK.Zeitsynchro). OSP.NK.SIS Die Sicherheitspolitik OSP.NK.SIS fordert einen gesicherten Internet-Zugangspunkt, der die damit verbundenen Netze der Benutzer wirksam gegen Angriffe aus dem Internet schützt. Dieser Zugang wird durch O.NK.PF_WAN (mit zustandsgesteuerter Filterung, O.NK.Stateful) ermöglicht. Von diesem System dürfen keine Angriffe auf die Netze der Benutzer ausgehen. Genau diese Eigenschaften werden durch OE.NK.SIS gefordert. Das schließt neben den technischen Schutzmaßnahmen auch eine sichere Administration des Zugangspunktes ein. OSP.NK.BOF Die Sicherheitspolitik OSP.NK.BOF fordert eine Kommunikation der aktiven Komponenten des LAN des LE mit den Bestandsnetzen und offenen Fachdiensten über den VPN-Kanal zur TI. Diese Kommunikation wird durch den VPN-Kanal entsprechend O.NK.VPN_Auth, O.NK.VPN_Integrität, O.NK.VPN_Vertraul, O.NK.Zert_Prüf und durch den Paketfilter nach O.NK.PF_WAN (mit zustandsgesteuerter Filterung, O.NK.Stateful) ermöglicht und kontrolliert. Gemäß OE.NK.CS erfolgt der Zugriff auf Bestandsnetze und offene Fachanwendungen nur durch aktive Komponenten im LAN in den vorgesehenen IP- Adressbereichen. OSP.NK.TLS Die Sicherheitspolitik OSP.NK.TLS fordert die Bereitstellung von TLS-Kanälen unter Verwendung sicherer kryptographischer Algorithmen und Protokolle zur sicheren Kommunikation mit anderen IT-Produkten. Diese TLS-Kanäle werden durch O.NK.TLS_Krypto ermöglicht. Security Target secunet konnektor 2.1.0 Seite 128 von 424 secunet OSP.NK.SW-Update Die Sicherheitspolitik OSP.NK.SW-Update erlaubt das Einspielen von Software für Konnektorkomponenten im Sinne einer Aktualisierung sowie das Aktualisieren der TSF Daten und das Nachladen von Fachmodulen. Dies ist ein administrativer Vorgang und damit auf Personen mit administrativen Zugriffsrechten beschränkt. Dies wird durch das Sicherheitsziel O.NK.Admin_EVG erreicht. In diesem Zusammenhang stehende sicherheitsrelevante Ereignisse werden durch O.NK.Protokoll protokolliert und mit einem sicheren Zeitstempel versehen. Bei der Bereitstellung der Update-Daten sorgt die Einsatzumgebung gemäß OE.NK.SW-Update dafür, dass nur geprüfte und von einer autorisierten Stelle freigegebene SW-Updates signiert und ausgeliefert werden. Ebenso sorgt OE.NK.SW-Update dafür, dass nur geprüfte und von einer autorisierten Stelle freigegebene Fachmodule signiert und ausgeliefert werden. Zum Software-Update im EVG fordert O.NK.Update, dass nur solche Updates eingespielt werden dürfen, deren Integrität und Authentizität gesichert ist. 4.5.3.3. Annahmen des Netzkonnektors Bei den inhaltlich lediglich umformulierten Annahmen (A. ...) bzw. Umgebungszielen (OE. ...) besteht eine direkte Eins-zu-eins-Beziehung: A.NK.phys_Schutz, A.NK.gSMC-K, A.NK.sichere_TI, A.NK.kein_DoS, A.NK.AK, A.NK.CS, A.NK.Betrieb_AK, A.NK.Betrieb_CS, A.NK.Admin_EVG und A.NK.Ersatzverfahren lassen sich direkt den entsprechend bezeichneten Umgebungszielen zuordnen: OE.NK.phys_Schutz, OE.NK.gSMC- K, OE.NK.sichere_TI, OE.NK.kein_DoS, OE.NK.AK, OE.NK.CS, OE.NK.Betrieb_AK, OE.NK.Betrieb_CS, OE.NK.Admin_EVG und OE.NK.Ersatzverfahren. Zu jeder dieser Annahmen existiert ein entsprechendes Umgebungsziel. Die Annahme A.NK.Zugriff_gSMC-K lautet: Es sind effektive Zugriffsschutzmaßnahmen etabliert, die den möglichen Zugriff von Komponenten des Konnektors auf Schlüsselmaterial der gSMC-K kontrollieren und unzulässige Zugriffe verhindern. Die Zugriffskontrolle kann durch eine zentrale Instanz vermittelt werden oder es wird sichergestellt, dass die Komponenten des Konnektors nur auf ihr eigenes Schlüsselmaterial zugreifen. Diese Annahme wird wie folgt auf die Umgebungsziele OE.NK.gSMC-K und OE.NK.Betrieb_AK abgebildet: OE.NK.gSMC-K impliziert, dass eine gSMC-K existiert und von der gematik zugelassen ist, und dass der EVG Zugriff auf dieses Modul hat. Der Hersteller des EVG verbaut nur solche zugelassenen Module und die gSMC-K ist sicher mit dem EVG verbunden, so dass die Kommunikation zwischen gSMC-K und EVG weder mitgelesen noch manipuliert werden kann. Somit müssen im Rahmen der Zugriffskontrolle überhaupt nur Zugriffe anderer Konnektorteile (AK, SAK) auf die gSMC-K betrachtet werden. Laut OE.NK.Betrieb_AK trägt der Betreiber des EVG die Verantwortung dafür, dass die Anwendungskonnektoren und Fachmodule den EVG in der spezifizierten Art und Weise nutzen, also insbesondere die spezifizierten Konnektor-Schnittstellen korrekt nutzen. Im Rahmen dieser Betrachtung wird das Vorhandensein einer wirksamen Zugriffskontrolle im Gesamtkonnektor sichergestellt. Security Target secunet konnektor 2.1.0 secunet Seite 129 von 424 4.5.4. Detaillierte Erklärung für den Anwendungskonnektor 4.5.4.1. Bedrohungen T.AK.DTBS Die Bedrohung T.AK.DTBS beschreibt Angriffe, bei denen der Angreifer erfolgreich Daten ohne die oder entgegen der Intention des Signaturschlüssel-Inhabers durch die sichere Signaturerstellungseinheit oder andere Chipkarten signieren lassen kann. Mit OE.AK.Benutzer_Signatur ist sichergestellt, dass der Benutzer des Clientsystems vor Übermittlung an den EVG verifiziert hat, dass die an den EVG zur Signierung übermittelten Daten mit den intendierten Daten übereinstimmen. Gemäß O.AK.Sig.exklusivZugriff bereitet der EVG die vom Benutzer des Clientsystems autorisierten, zu signierenden Daten für die Signaturerstellung durch die QSEE vor, sorgt für den alleinigen Zugriff auf die QSEE, sendet sie an die QSEE (der HBA gemäß OE.AK.HBA, im Falle nichtqualifizierter elektronischer Signaturen die SMC-B gemäß OE.AK.SMC), und kontrolliert die empfangenen Signaturen und vergleicht die signierten mit den autorisierten Daten. Zusätzlich wird die Kommunikation zwischen AK und den eHealth-Kartenterminals, in denen die Chipkarten (einschließlich QSEE) stecken, gemäß O.AK.IFD-Komm geschützt. Die TLS-Kanäle werden durch die eHealth- Kartenterminals gemäß OE.AK.Kartenterminal unterstützt. T.AK.VAD Die Bedrohung T.AK.VAD beschreibt Angriffe, über das lokale Netz die VAD (d.h. die PIN oder PUK) eines Chipkartenbenutzers zu kompromittieren oder zu manipulieren. Die Benutzerauthentisierung gegenüber Chipkarten wird durch O.AK.VAD bei lokaler und entfernter PIN-Eingabe direkt geschützt. Die Vertraulichkeit und der Integritätsschutz der VAD bei der entfernten PIN-Eingabe werden durch Secure Messaging Kanäle zwischen der gSMC- K in den PIN-Terminals und den Chipkarten HBA und SMC-B erreicht, welche gemäß O.AK.VAD durch den EVG gesteuert und gemäß OE.AK.HBA und OE.AK.SMC von allen benutzten Chipkarten unterstützt wird. Die Vertraulichkeit und Integrität der VAD wird in den eHealth-Kartenterminals gemäß OE.AK.Kartenterminal geschützt. Die Vertraulichkeit und Integrität der Kommunikation zwischen PIN-Terminal und Chipkarten-Terminal wird zusätzlich durch entsprechend gesicherte Kanäle gemäß O.AK.IFD-Komm und OE.AK.Kartenterminal geschützt. T.AK.LAN.eHKT Die Bedrohung T.AK.LAN.eHKT wird direkt durch das EVG-Sicherheitsziel O.AK.IFD- Komm unter den Bedingungen des Sicherheitsziels der Einsatzumgebung OE.AK.Kartenterminal abgedeckt. O.AK.Admin gewährleistet die Administration der eHealth- Kartenterminals durch Administratoren. T.AK.LAN.CS Die Bedrohung T.AK.LAN.CS beschreibt Angriffe auf die Integrität und Vertraulichkeit der im LAN zwischen dem EVG und Clientsystemen übertragenen Daten. Das Sicherheitsziel O.AK.LAN schützt gegen Abhören, Fälschen und Vorgeben einer falschen Identität bei der Kommunikation mit den Clientsystemen im LAN der Leistungserbringer. Bei der Gegenstelle Security Target secunet konnektor 2.1.0 Seite 130 von 424 secunet der Kommunikation ist ein ebenso vertrauenswürdiger Umgang mit den übertragenen Daten und mit dem genutzten Schlüsselmaterial erforderlich. Dies wird mit dem Sicherheitsziel OE.AK.Clientsystem erreicht. T.AK.WAN.TI Bei der Bedrohung T.AK.WAN.TI werden Daten bei der Übertragung zwischen EVG und Fachdiensten abgehört oder manipuliert. Diese Bedrohung wird seitens des EVG direkt durch das Sicherheitsziel O.AK.WAN adressiert. Bei der Gegenstelle der Kommunikation ist ein ebenso vertrauenswürdiger Umgang mit den übertragenen Daten und mit dem genutzten Schlüsselmaterial erforderlich. Dies wird mit dem Sicherheitsziel OE.AK.sichere_TI erreicht. T.AK.LAN.Admin Die Bedrohung T.AK.LAN.Admin betrachtet Angriffe auf die Kommunikation zwischen Adminstrationskonsole und EVG. Das Sicherheitsziel O.AK.Admin fordert dafür eine bezüglich Integrität und Vertraulichkeit gesicherte Kommunikation, um diese Bedrohung abzudecken. T.AK.Kanal_Missbrauch Bei der Bedrohung T.AK.Kanal_Missbrauch werden bestehende (logische) Kommunikationskanäle durch Angreifer missbraucht. Dies wird durch folgende Maßnahmen adressiert:  Das Sicherheitsziel O.AK.Admin verhindert durch den Schutz der Integrität und Vertraulichkeit des Kommunikationskanals zur Administrationsschnittstelle, dass zusätzliche Daten eingeschleust werden können oder eine bestehende Kommunikation modifiziert werden kann.  Das Sicherheitsziel der Umgebung OE.AK.gSMC-K verhindert durch den Schutz der Integrität und Vertraulichkeit des Kommunikationskanals zwischen EVG und gSMC- K, dass zusätzliche Daten eingeschleust werden können oder eine bestehende Kommunikation modifiziert werden kann.  Das Sicherheitsziel O.AK.IFD-Komm verhindert durch den Schutz der Integrität und Vertraulichkeit der Kommunikation zwischen EVG und eHealth-Terminal, dass zusätzliche Daten eingeschleust werden können oder eine bestehende Kommunikation modifiziert werden kann. Für die Gegenstelle der Kommunikation (eHealth- Kartenterminal) wird entsprechendes in den Sicherheitszielen für die Umgebung OE.AK.Kartenterminal gefordert.  Das Sicherheitsziel O.AK.Sig.exklusivZugriff fordert die Überwachung der Integrität der zum Signieren vom EVG an die QSEE übergebenen Daten. Zudem wird die alleinige Kontrolle über die QSEE durch den autorisierten Nutzer sichergestellt. Damit wird ein Missbrauch des Kanals zur QSEE verhindert.  Bei der Kommunikation zwischen EVG und Clientsystem bzw. zwischen EVG und Fachanwendungen in der zentralen TI-Plattform werden bezüglich Integrität und Vertraulichkeit gesicherte Kanäle verwendet. Dies ist durch die Sicherheitsziele O.AK.LAN und O.AK.WAN für den EVG realisiert, für die Gegenstellen der Security Target secunet konnektor 2.1.0 secunet Seite 131 von 424 Kommunikation wird entsprechendes in den Sicherheitszielen für die Umgebung OE.AK.sichere_TI und OE.AK.Clientsystem gefordert.  Für die Kommunikation zwischen EVG und Kartenterminal bzw. zwischen EVG und Chipkarte fordert das Sicherheitsziel O.AK.exklusivZugriff die alleinige Kontrolle des Benutzers über diese Instanzen. Die genutzten Ressourcen werden nach Beendigung der Transaktion wieder freigegeben. Damit wird ein Missbrauch der entsprechenden Kommunikationskanäle verhindert. T.AK.Mani.EVG Die Bedrohung T.AK.Mani.EVG betrachtet Manipulationen des EVG durch direkten Zugriff auf den EVG oder auf Update-Daten. Das Sicherheitsziel für die Umgebung OE.AK.phys_Schutz schützt den EVG vor Manipulationen und physischen Zugriff durch Unbefugte. Zusätzlich bietet die Plattform (Ausführungsumgebung) des EVG einen Schutz durch OE.AK.Plattform. Das Sicherheitsziel O.AK.EVG_Modifikation adressiert logische Bedrohungen auf sicherheitsrelevante Anteile zur Laufzeit des EVG und sorgt für Erkennung von Modifikationen und den Schutz kryptografischer Geheimnisse. Erkannte Veränderungen führen zu einem entsprechenden Betriebszustand des EVG, der stets den sicheren Zustand des EVG aufrecht erhält. Solche Veränderungen werden durch O.AK.Protokoll sicher protokolliert und durch O.AK.Zeit (mit Hilfe von OE.AK.Echtzeituhr, O.NK.Zeitdienst, OE.NK.Echtzeituhr und OE.NK.Zeitsynchro) mit einem sicheren Zeitstempel versehen. Unautorisierte Veränderungen von Update-Daten werden durch OE.AK.SW-Update verhindert und manipulierte Update-Daten werden durch O.AK.Update erkannt und nicht angewendet. O.AK.Selbsttest stellt Fehler fest, die ggf. durch Manipulationen hervorgerufen werden. T.AK.Mani.Client Die Bedrohung T.AK.Mani.Client betrachtet manipulierte Clientsysteme, um zu schützende Daten offenzulegen oder zu manipulieren. Im Sicherheitsziel OE.AK.Clientsystem werden vertrauenswürdige Clientsysteme gefordert, von denen keine Angriffe ausgehen und die mit zu schützenden Daten und mit Schlüsselmaterial entsprechend sorgsam umgehen. Falls dennoch sicherheitskritische Ereignisse durch manipulierte Clientsysteme im EVG festgestellt werden, so werden diese durch O.AK.Protokoll protokolliert und durch O.AK.Zeit (mit Hilfe von OE.AK.Echtzeituhr, O.NK.Zeitdienst, OE.NK.Echtzeituhr und OE.NK.Zeitsynchro) mit einem sicheren Zeitstempel versehen. Erfolgreich manipulierte Clientsysteme können zu einer Verletzung der spezifizierten Abläufe im EVG gemäß Informationsmodell führen. Diese Verletzungen werden durch das Sicherheitsziel O.AK.Infomodell wirksam verhindert. T.AK.Mani.TI Die Bedrohung T.AK.Mani.TI betrachtet Angriffe durch manipulierte Systeme in der zentralen TI-Plattform. Dies wird durch OE.AK.sichere_TI wirksam verhindert, indem es eine vertrauenswürdige TI fordert, von der keine Angriffe ausgehen und die zu schützende Daten nicht missbraucht. Angriffe durch Administratoren der TI werden ebenso ausgeschlossen wie Bedrohungen durch fehlerhafte Software. Falls dennoch sicherheitskritische Ereignisse durch manipulierte Systeme der zentralen TI-Plattform im EVG festgestellt werden, so werden diese durch O.AK.Protokoll protokolliert und durch O.AK.Zeit (mit Hilfe von OE.AK.Echtzeituhr, O.NK.Zeitdienst, OE.NK.Echtzeituhr und OE.NK.Zeitsynchro) mit einem sicheren Zeitstempel versehen. Security Target secunet konnektor 2.1.0 Seite 132 von 424 secunet T.AK.Mani.ExternerDienst Die Bedrohung T.AK.Mani.ExternerDienst betrachtet den Einfluss externer Dienste (dem PKI- Dienst), die zur ordnungsgemäßen Funktion des EVG benötigt werden. Im Fall von PKI- Diensten fordert das Sicherheitsziel OE.AK.PKI den Zugriff auf alle notwendigen Informationen zur Prüfung von Zertifikaten durch den EVG. Die öffentlichen Schlüssel der Wurzelinstanzen werden auf vertrauenswürdige Weise zur Verfügung gestellt. Dadurch werden Modifikationen an bzw. mit Hilfe des PKI Dienstes zuverlässig vom EVG erkannt und durch O.AK.Protokoll protokolliert und durch O.AK.Zeit (mit Hilfe von OE.AK.Echtzeituhr, O.NK.Zeitdienst, OE.NK.Echtzeituhr und OE.NK.Zeitsynchro) mit einem sicheren Zeitstempel versehen. T.AK.Mani.Chipkarte Manipulierte Chipkarten werden durch die Bedrohung T.AK.Mani.Chipkarte betrachtet. Die eingesetzten Chipkarten sind gemäß OE.AK.SMC, OE.AK.HBA, OE.AK.eGK evaluiert und zertifiziert und verfügen somit über entsprechende Schutzmechanismen, die Manipulationen wirksam verhindern. Gemäß OE.AK.Karten werden gefälschte Chipkarten in Kartenlesern des LAN des Leistungserbringers erkannt bzw. die Verarbeitung ungesicherter persönlicher Daten der Chipkarten verhindert. Die gSMC-K ist durch die gematik zugelassen und verfügt damit ebenfalls über entsprechende Schutzmechanismen (OE.AK.gSMC-K). Der EVG bietet mit der Nutzung einer PKI (OE.AK.PKI) Möglichkeiten zum Zurückziehen von Kartenzertifikaten, die eine weitere Nutzung der betroffenen Identitäten auf den Chipkarten verhindern. Dies wird insbesondere durch die Sicherheitsziele O.AK.Update und O.AK.Infomodell erreicht: Durch O.AK.Update werden dem EVG entsprechende Listen über den Status von Identitäten geliefert, die für die Zuordnung der einzelnen Komponenten im Betrieb des EVG im Sinne des Informationsmodells benötigt werden. Abweichungen vom Informationsmodell werden durch O.AK.Infomodell nicht akzeptiert, durch O.AK.Protokoll protokolliert und durch O.AK.Zeit (mit Hilfe von OE.AK.Echtzeituhr, O.NK.Zeitdienst, OE.NK.Echtzeituhr und OE.NK.Zeitsynchro) mit einem sicheren Zeitstempel versehen. T.AK.Mani.Terminal Die Bedrohung T.AK.Mani.Terminal adressiert manipulierte eHealth-Terminals, um unautorisierten Zugriff auf zu schützende Daten zu erlangen. Das Sicherheitsziel OE.AK.Kartenterminal verlangt den Einsatz von sicheren Kartenterminals, die implementierte Sicherheitsmechanismen sicherstellen, welche für den Betrieb des EVG benötigt werden. Da diese Terminals über Chipkarten (gSMC-KT) verfügen, sind ihre Identitäten durch die PKI- Dienste im EVG (siehe OE.AK.PKI) erfasst. Der EVG setzt das Informationsmodell gemäß O.AK.Infomodell durch, das beim Pairing der Komponenten durch den Administrator konfiguriert werden kann. Nur vertrauenswürdige Komponenten werden durch den Administrator im Informationsmodell implementiert (OE.AK.Admin_EVG). Durch die Nutzung der PKI (OE.AK.PKI, O.AK.Update) werden nicht vertrauenswürdige Terminals von der Nutzung ausgeschlossen. Unautorisierte Zugriffsversuche solcher Terminals widersprechen dem Informationsmodell (O.AK.Infomodell) und werden durch den EVG ausgeschlossen, protokolliert (O.AK.Protokoll) und mit einem sicheren Zeitstempel versehen (O.AK.Zeit (mit Hilfe von OE.AK.Echtzeituhr, O.NK.Zeitdienst, OE.NK.Echtzeituhr und OE.NK.Zeitsynchro)). Security Target secunet konnektor 2.1.0 secunet Seite 133 von 424 T.AK.Mani.AdminKonsole Die Bedrohung T.AK.Mani.AdminKonsole betrachtet manipulierte Administrationskonsolen, um unautorisiert Veränderungen am EVG vorzunehmen oder Zugriff auf zu schützende Daten zu erlangen. Die wird durch OE.AK.Admin_Konsole verhindert, wobei eine sichere Administrationskonsole gefordert wird. Zudem fordert das Sicherheitsziel O.AK.Admin entsprechende Mechanismen, die nur erfolgreich authentisierten Administratoren Zugriff zu administrativen Funktionen des EVG erlauben. Erkannte Verstöße werden durch O.AK.Protokoll protokolliert und durch O.AK.Zeit (mit Hilfe von OE.AK.Echtzeituhr, O.NK.Zeitdienst, OE.NK.Echtzeituhr und OE.NK.Zeitsynchro) mit einem sicheren Zeitstempel versehen. T.AK.MissbrauchKarte Die Bedrohung T.AK.MissbrauchKarte betrachtet Gefahren durch missbrauchte Chipkarten im Zusammenhang mit Diebstahl und/oder Nutzung von ausgespähten PINs. Dies wird durch Sorgfaltspflichten der entsprechenden Kartenbesitzer bzw. Nutzer gemäß OE.AK.Versicherter, OE.AK.HBA-Inhaber, OE.AK.SMC-B-PIN sowie OE.AK.SecAuthData verhindert. Sollte trotzdem eine Chipkarte abhanden gekommen sein, so kann durch Einsatz der PKI (OE.AK.PKI , O.AK.Update) die entsprechende Identität gesperrt werden. Der EVG setzt das Informationsmodell gemäß O.AK.Infomodell durch und verhindert so den Einsatz dieser gesperrten Chipkarten. Versuchte Nutzungen solcher Karten werden gemäß O.AK.Protokoll protokolliert und mit einem sicheren Zeitstempel versehen (O.AK.Zeit (mit Hilfe von OE.AK.Echtzeituhr, O.NK.Zeitdienst, OE.NK.Echtzeituhr und OE.NK.Zeitsynchro)). Bei einer festgestellten ausgespähten PIN erlaubt der EVG das Management von PIN-Änderungen durch den Benutzer (O.AK.PinManagement). T.AK.Fehlbedienung Die Bedrohung T.AK.Fehlbedienung betrachtet Gefahren durch Fehlkonfiguration oder Fehlbedienung des EVG. Im Fall der Administration des EVG verlangt OE.AK.Admin_EVG, dass Administratoren hinreichend vertrauenswürdig und geschult sind, um Fehlbedienungen zu verhindern. Für Benutzer des EVG über Clientsysteme hängt die Gefahr der Fehlbedienung auch von der korrekten Gestaltung der Benutzerschnittstelle und der Software der Clientsysteme ab. Hierzu fordert zum einen OE.AK.ClientsystemKorrekt die korrekte Implementierung der Clientsysteme entsprechend dem Informationsmodell sowie eine korrekte und verständliche Darstellung von Meldungen, Warnungen und kritischen Betriebszuständen. Zum anderen fordert OE.AK.Personal, dass das Personal so qualifiziert ist, dass Fehler bei Betrieb und Nutzung des EVG ausgeschlossen sind. Das minimiert die Gefahr von Fehlbedienungen an dieser Schnittstelle. Sorgfaltspflichten des Benutzers bzw. HBA-Inhabers tragen gemäß OE.AK.Benutzer_Signatur bzw. OE.AK.HBA-Inhaber zur Vermeidung von Fehlbedienungen bei. 4.5.4.2. Organisatorische Sicherheitspolitiken OSP.AK.MedSoc_Data Die Sicherheitspolitik OSP.AK.MedSoc_Data verlangt, Dienste zur qualifizierten und nichtqualifizierten elektronischen Signatur, zur Chiffrierung von Dateien sowie zur Security Target secunet konnektor 2.1.0 Seite 134 von 424 secunet kryptographischen Absicherung der Kommunikation bereitzustellen. Dadurch wird die Vertraulichkeit und Integrität aller Daten, die durch oder an die Telematikinfrastruktur, ein Clientsystem des Leistungserbringers oder eine elektronische Gesundheitskarte übergeben werden, gewährleistet. Die Sicherheitsziele des EVG tragen dem wie folgt Rechnung:  O.AK.Sig.SignNonQES, O.AK.Sig.Stapelsignatur O.AK.Sig.Komfortsignatur und O.AK.Sig.SignQES fordern die Bereitstellung von Signaturdiensten für die Erstellung nichtqualifizierter elektronischer Signaturen mit der SMC-B (s.OE.AK.SMC) qualifizierter elektronischer Signaturen mit dem HBA als QSEE (s. OE.AK.HBA),  O.AK.Sig.PrüfungZertifikat, O.AK.Sig.Schlüsselinhaber und O.AK.Sig.SignaturVerifizierung fordern die Dienste zur Signaturprüfung,  OE.AK.Benutzer_Signatur fordert den Benutzer des Clientsystems zur Überprüfung der zu signierenden Daten vor Übermittlung an den EVG auf  O.AK.Enc und O.AK.Dec stellen die Verschlüsselung und Entschlüsselung von Dokumenten für die Übermittlung in die Telematikinfrastruktur bereit,  O.AK.IFD-Komm schützt die durch den EVG erzeugte Kommunikation im LAN des Leistungserbringers,  O.AK.LAN, O.AK.WAN und OE.AK.gSMC-K schützen Integrität und Vertraulichkeit bei der Kommunikation des EVG mit Clientsystemen, mit Fachdiensten und mit der gSMC-K.  O.AK.exklusivZugriff verhindert den Zugriff auf eine aktive Sitzung (Session) zwischen EVG und Kartenterminal bzw. zwischen EVG und Chipkarte durch unautorisierte Instanzen.  Der EVG implementiert das Infomodell gemäß O.AK.Infomodell und stellt damit sicher, dass spezifizierten Abläufe und Zuordnungen der Komponenten im Betrieb eingehalten werden. OSP.AK.Konn_Spez Die Sicherheitspolitik OSP.AK.Konn_Spez fordert die Erfüllung der sicherheitsrelevanten Anforderungen der Konnektor-Spezifikation [27] und die Durchsetzung der zulässigen Signaturrichtlinien und Verschlüsselungsrichtlinien. Die EVG-Sicherheitsziele O.AK.Admin, O.AK.IFD-Komm, (Kommunikation mit eHealth-Kartenterminals), O.AK.Enc, O.AK.Dec, O.AK.Sig.SignQES, O.AK.Sig.Einfachsignatur, O.AK.Sig.Stapelsignatur, O.AK.Sig.Komfortsignatur, O.AK.Protokoll, O.AK.Zeit (mit Hilfe von OE.AK.Echtzeituhr, O.NK.Zeitdienst, OE.NK.Echtzeituhr und OE.NK.Zeitsynchro), O.AK.Update sowie bezüglich der Verwendung von Chipkarten O.AK.VAD, O.AK.exklusivZugriff und O.AK.PinManagement setzen Spezifikationsanteile von [27] um (und andere EVG- Sicherheitsziele präzisieren diese). Die Durchsetzung zulässiger Signaturrichtlinien wird explizit in O.AK.Sig.SignQES und für Verschlüsselungsrichtlinien in O.AK.Enc gefordert, deren Bereitstellung durch OE.AK.PKI gewährleistet wird. Das Sicherheitsziel OE.AK.Echtzeituhr (mit Hilfe von O.NK.Zeitdienst und OE.NK.Echtzeituhr) deckt die Anforderungen der Konnektor-Spezifikation zur Verwendung von Echtzeit ab. Die spezifizierten Abläufe und Zuordnungen zwischen dem EVG und externen Komponenten werden durch O.AK.Infomodell im EVG implementiert. Security Target secunet konnektor 2.1.0 secunet Seite 135 von 424 OSP.AK.KryptAlgo Die Sicherheitspolitik OSP.AK.KryptAlgo fordert den Einsatz kryptografischer Verfahren im Einklang mit den relevanten Vorgaben des Dokuments BSI TR-03116-1 und wird im EVG direkt durch das Sicherheitsziel O.AK.Basis_Krypto umgesetzt. Außerhalb des EVG wird diese Sicherheitspolitik durch entsprechende Sicherheitsziele für die Umgebung durchgesetzt: OE.AK.sichere_TI fordert die Verwendung von kryptographischen Sicherheitsmechanismen, die Einklang mit den relevanten Vorgaben des Dokuments BSI TR-03116-1 implementiert sind. Gleiches fordert OE.AK.Clientsystem für die Clientsysteme. Im Fall der Kartenterminals und Chipkarten wird die Sicherheitspolitik durch den Einsatz entsprechend zertifizierter Komponenten sichergestellt. Dies drückt sich in den Sicherheitszielen für die Einsatzumgebung OE.AK.Kartenterminal, OE.AK.HBA, OE.AK.SMC und OE.AK.eGK aus. OSP.AK.SW-Update Die Sicherheitspolitik OSP.AK.SW-Update erlaubt das Einspielen von Software für Konnektorkomponenten im Sinne einer Aktualisierung sowie das Aktualisieren der TSF Daten und das Nachladen von Fachmodulen. Der Admin kann konfigurieren, dass die Aktualisierung automatisch stattfindet oder der Admin kann die Aktualisierung manuell anstoßen. Die Änderung der Konfiguration zum automatischen Update und das manuelle Anwenden von Aktualisierungen ist ein administrativer Vorgang und damit auf Personen mit administrativen Zugriffsrechten beschränkt. Dies wird durch das Sicherheitsziel O.AK.Admin erreicht. In diesem Zusammenhang stehende sicherheitsrelevante Ereignisse werden durch O.AK.Protokoll protokolliert und durch O.AK.Zeit (sowie OE.AK.Echtzeituhr, O.NK.Zeitdienst, OE.NK.Echtzeituhr und OE.NK.Zeitsynchro) mit einem sicheren Zeitstempel versehen. Bei der Bereitstellung der Update-Daten sorgt die Einsatzumgebung gemäß OE.AK.SW-Update dafür, dass nur geprüfte und von einer autorisierten Stelle freigegebene und ggf. zertifizierte SW- Updates signiert und bereitgestellt werden. Ebenso sorgt OE.AK.SW-Update dafür, dass nur geprüfte und von einer autorisierten Stelle freigegebene Fachmodule signiert und ausgeliefert werden. Zum Software-Update im EVG fordert O.AK.Update, dass nur solche Updates eingespielt werden dürfen, deren Integrität und Authentizität gesichert ist. OSP.AK.EVG_Modification Die Sicherheitspolitik OSP.AK.EVG_Modification wird durch das EVG-Sicherheitsziel  O.AK.EVG_Modifikation zur Erkennbarkeit logischer Angriffe auf den EVG  O.AK.Protokoll für eine Protokollierung mit einem sicheren Zeitstempel (O.AK.Zeit, OE.AK.Echtzeituhr, O.NK.Zeitdienst, OE.NK.Echtzeituhr und OE.NK.Zeitsynchro) und unter den Bedingungen der Sicherheitsziele für die Einsatzumgebung  OE.AK.Personal zur Kontrolle durch das Personal, ob der EVG sicherheitstechnische Veränderungen erkennen lässt,  OE.AK.phys_Schutz zum physischen Schutz des EVG,  OE.AK.Plattform zur vertrauenswürdigen Plattform zur Ausführung des EVG Security Target secunet konnektor 2.1.0 Seite 136 von 424 secunet geeignet umgesetzt. OSP.AK.SC_Sign Die Sicherheitspolitik OSP.AK.SC_Sign zur Erstellung qualifizierter elektronische Signaturen mit dem HBA als QSEE und digitaler Signaturen mit anderen Chipkarten als Signaturerstellungseinheit und dem EVG wird durch die folgenden EVG-Sicherheitsziele umgesetzt:  O.AK.Sig.SignQES, O.AK.Sig.Einfachsignatur, O.AK.Sig.Komfortsignatur und O.AK.Sig.Stapelsignatur fordern die Erstellung der in OSP.AK.SC_Sign genannten qualifizierten elektronischen Signaturen in Abhängigkeit von der gewählten Signaturrichtlinie.  O.AK.Sig.SignNonQES fordert die Erstellung der in OSP.AK.SC_Sign genannten nichtqualifizierten elektronischen Signaturen in Abhängigkeit von der gewählten Signaturrichtlinie sowie die Erzeugung digitaler Signaturen über Bitstrings mit Authentisierungsschlüsseln. OSP.AK.SC_Authorized Die Sicherheitspolitik OSP.AK.SC_Authorized wird durch Sicherheitsziele für den EVG und der Einsatzumgebung umgesetzt:  O.AK.Sig.exklusivZugriff fordert, dass der EVG nur für solche Dateien und Heilberufsausweise den Signaturprozess auslösen darf, die von dem autorisierten Benutzer des Clientsystems ausgewählt wurden (Stapel). Die Autorisierung basiert auf einer erfolgreichen Authentisierung des Benutzers des Clientsystems als Signaturschlüssel-Inhaber, die nach OE.AK.HBAund OE.AK.SMC für die Nutzung des Signaturschlüssels notwendig ist. Darüber hinaus prüft der EVG, ob nur die autorisierten zu signierenden Daten korrekt signiert wurden.  O.AK.VAD schützt die SVAD durch die Eingabe der Signatur-PIN und Signatur-PUK des Signaturschlüssel-Inhabers im sicheren PIN-Modus am PIN-Terminal und deren vertrauliche und integritätsgeschützte Übermittlung im Secure Messaging Kanal zwischen der SMC im PIN-Terminal zur SVAD-empfangenden QSEE im Chipkarten- Terminal. Außerdem sorgt dieses Sicherheitsziel des EVG für die spätere Anzeige der übergebenen Jobnummer am PIN-Terminal. OSP.AK.SC_SVAD Die Sicherheitspolitik OSP.AK.SC_SVAD wird durch das EVG-Sicherheitsziel O.AK.VAD und die Sicherheitsziele der anderen beteiligten Komponenten der Einsatzumgebung OE.AK.Kartenterminal, OE.AK.HBA und OE.AK.SMC umgesetzt. Security Target secunet konnektor 2.1.0 secunet Seite 137 von 424 OSP.AK.SC_UnalteredData Die Sicherheitspolitik OSP.AK.SC_UnalteredData wird durch die Ziele O.AK.Sig.exklusivZugriff, O.AK.Sig.Einfachsignatur, O.AK.Sig.Komfortsignatur und O.AK.Sig.Stapelsignatur umgesetzt. OSP.AK.SV_Certificate Die Sicherheitspolitik OSP.AK.SV_Certificate wird durch das EVG-Sicherheitsziel O.AK.Sig.PrüfungZertifikat umgesetzt. Dabei unterstützt die Einsatzumgebung den EVG durch das Sicherheitsziel OE.AK.PKI. OSP.AK.SV_Signatory Die Sicherheitspolitik OSP.AK.SV_Signatory wird durch das geeignet formulierte Ziel O.AK.Sig.Schlüsselinhaber umgesetzt. OSP.AK.SV_Unaltered_Data Die Sicherheitspolitik OSP.AK.SV_Unaltered_Data wird durch folgende Sicherheitsziele des EVG und der Umgebung umgesetzt:  O.AK.Sig.SignaturVerifizierung, der vom EVG fordert, zuverlässig die Korrektheit einer qualifizierten elektronischen Signatur und andere digitaler Signaturen und die Unverändertheit der signierten Daten zu prüfen und das Ergebnis der Prüfung zutreffend anzuzeigen. OSP.AK.Encryption Die Sicherheitspolitik OSP.AK.Encryption wird durch die EVG-Sicherheitsziele und die Einsatzumgebung umgesetzt:  O.AK.Enc fordert die Bereitstellung des Verschlüsselns für die übergebenen Daten, Adressaten einschließlich der Prüfung der Gültigkeit ihrer Zertifikate und der Zulässigkeit der Verschlüsselungsrichtlinie.  O.AK.Dec fordert die Bereitstellung des Entschlüsselns für die übergebenen Daten, wenn die Verschlüsselungsrichtlinie und der Sicherheitszustand der Chipkarten mit den benötigten Entschlüsselungsschlüsseln dies erlauben.  OE.AK.PKI gewährleistet die Bereitstellung der PKI für die Verschlüsselung sowie die Identifizierung und Implementation zulässiger Verschlüsslungsregeln. OSP.AK.CardService Die Sicherheitspolitik OSP.AK.CardService wird durch die geeignete Sicherheitsziele O.AK.Chipkartendienst und O.AK.VAD realisiert. Das Sicherheitsziel OE.AK.PKI stellt die benötigten Zertifikate der qualifizierten elektronischen Signatur mit dem HBA, Zertifikate für andere Signaturen, Verschlüsselungszertifikate und CV-Zertifikate für die Kartenhalter und die verwendeten Chipkarten bereit. Security Target secunet konnektor 2.1.0 Seite 138 von 424 secunet OSP.AK.Fachanwendungen Die Sicherheitspolitik OSP.AK.Fachanwendungen fordert die Vertrauenswürdigkeit der Fachanwendungen, zentralen Dienste der TI-Plattform und deren Intermediäre sowie deren gesicherte Kommunikation. Diese setzen sich aus einem Anteil innerhalb des EVG und einen Anteil in der Einsatzumgebung des EVG zusammen. Der Anteil innerhalb des EVG entspricht den Fachmodulen. Da nur ein Fachmodul im Einsatz ist (VSDM), wird dies durch das entsprechende Sicherheitsziel O.AK.VSDM umgesetzt. Das Sicherheitsziel O.AK.VZD verlangt, die Abfrage des VZD durch Clientsysteme und Fachmodule durch Nutzung des LDAP-Proxies Daten aus dem VZD über gesicherte Kanäle zu unterstützen. Die Anforderungen an die anderen Anteile der Fachanwendung werden durch das Umgebungsziel OE.AK.Fachdienste geeignet umgesetzt. OSP.AK.VAUSGD Die Sicherheitspolitik fordert die vor Abhören geschützte Verbindung des TOE in die VAU- Instanz der ePA-Dokumentenverwaltung sowie in das SGD-HSM des Schlüsselgenirierungsdienstes durch die korrekte Implementierung des „VAU-Protokolls“ und des „SGD-Protokolls“. Die OSP wird durch das Sicherheitsziel O.AK.VAUSGD umgesetzt, welches die spezifikationskonforme Implementierung der Protokolle fordert. Die Anforderungen an die korrekte Nutzung der Kommunikationskanäle durch die ePA- Fachanwendungen werden durch das Umgebungsziel OE.AK.Fachdienste geeignet umgesetzt. 4.5.4.3. Annahmen  Die Annahme A.AK.Cardterminal_eHealth wird durch das Umgebungsziel OE.AK.Kartenterminal geeignet umgesetzt.  Die Annahme A.AK.Konnektor wird durch das Umgebungsziel OE.AK.Plattform geeignet umgesetzt.  Die Annahme A.AK.Versicherter wird offensichtlich durch das Umgebungsziel OE.AK.Versicherter abgebildet.  Die Annahme A.AK.HBA-Inhaber wird offensichtlich durch das Umgebungsziel OE.AK.HBA-Inhaber abgebildet.  Die Annahme A.AK.SMC-B-PIN wird offensichtlich durch das Umgebungsziel OE.AK.SMC-B-PIN abgebildet.  Die Annahme A.AK.sichere_TI wird offensichtlich durch das Umgebungsziel OE.AK.sichere_TI abgebildet.  Die Annahme A.AK.Admin_EVG wird offensichtlich durch das Umgebungsziel OE.AK.Admin_EVG abgebildet.  Die Annahme A.AK.SMC wird durch das Umgebungsziel OE.AK.SMC geeignet umgesetzt.  Die Annahme A.AK.QSCD wird durch das Umgebungsziel OE.AK.HBA geeignet umgesetzt.  Die Annahme A.AK.phys_Schutz wird durch das Umgebungsziel OE.AK.phys_Schutz geeignet umgesetzt.  Die Annahme A.AK.Chipkarteninhaber wird durch die Umgebungsziele OE.AK.Personal in Bezug auf die Vertrauenswürdigkeit im Umgang mit den ihm anvertrauten zu Security Target secunet konnektor 2.1.0 secunet Seite 139 von 424 schützenden Daten und OE.AK.SecAuthData im Bezug auf den Schutz seiner Authentisierungsdaten geeignet umgesetzt.  Die Annahme A.AK.Benutzer_Signatur wird durch das Umgebungsziel OE.AK.Benutzer_Signatur geeignet umgesetzt.  Die Annahme A.AK.gSMC-K wird durch das Umgebungsziel OE.AK.gSMC-K geeignet umgesetzt.  Die Annahme A.AK.Env_Arbeitsplatz wird durch die Umgebungsziele OE.AK.Clientsystem und OE.AK.ClientsystemKorrekt umgesetzt. Security Target secunet konnektor 2.1.0 Seite 140 von 424 secunet 5. Definition zusätzlicher Komponenten 5.1. Definition der erweiterten Familie FPT_EMS und der Anforderung FPT_EMS.1 Die Definition der Familie FPT_EMS wurde aus dem BSI-CC-PP-0098, [16], übernommen. Family FPT_EMS – EVG Emanation Family behaviour This family defines requirements to mitigate intelligible emanations. Component levelling: FPT_EMS – EVG Emanation 1 FPT_EMS.1 – EVG Emanation has two constituents: FPT_EMS.1.1 Limit of Emissions requires to not emit intelligible emissions enabling access to TSF data or user data. FPT_EMS.1.2 Interface Emanation requires to not emit interface emanation enabling access to TSF data or user data. Management: FPT_EMS.1 There are no management activities foreseen. Audit: FPT_EMS.1 There are no actions identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST. FPT_EMS.1 Emanation of TSF and User data Hierarchical to: No other components. Dependencies: No dependencies. FPT_EMS.1.1 The TOE shall not emit [assignment: types of emissions] in excess of [assignment: specified limits] enabling access to [assignment: list of types of TSF data] and [assignment: list of types of user data]. FPT_EMS.1.2 The TSF shall ensure [assignment: type of users] are unable to use the following interface [assignment: type of connection] to gain access to [assignment: list of types of TSF data] and [assignment: list of types of user data]. 5.2. Definition der Familie FIA_API Authentication proof of Identity Die Definition der Familie FIA_API wurde aus dem PP BSI-CC-PP-0098, [16], übernommen. Family FIA_API – Authentication proof of Identity Security Target secunet konnektor 2.1.0 secunet Seite 141 von 424 Family behaviour: This family defines functions provided by the TOE to prove their identity and to be authenticated by an external entity in the TOE IT environment. Component levelling: FIA_API – Authentication proof of Identity 1 FPT_ API.1 – Authentication proof of Identity has one constituent: FIA_API.1.1 „Authentication proof of Identity“ describes the functional requirements for the proof of the claimed identity for the authentication verification with an assigned authentication mechanism. The verification of the TSF provided authentication proof of the identity or role is performed by the external entity. Management: There are no management activities foreseen Audit: There are no actions defined to be auditable, if FAU_GEN is part of the PP/ST. FIA_API.1 Authentication proof of Identity Hierarchical to: No other components. Dependencies: No dependencies. FIA_API.1.1 The TSF shall provide a [assignment: authentication mechanism] to prove the identity of the [assignment: identity or role]. Security Target secunet konnektor 2.1.0 Seite 142 von 424 secunet 6. Sicherheitsanforderungen 6.1.1. Hinweise zur Notation Die Auswahl der funktionalen Sicherheitsanforderungen ist durch das zugrundeliegende Schutzprofil, BSI-CC-PP-0098, gegeben. Das Schutzprofil basiert auf Version 3.1 Revision 5 der Common Criteria; diese Version [5] liegt in englischer Sprache vor. Operationen wurden dabei teilweise in deutscher Sprache ausgeführt. Dieses Security Target übernimmt die Formulierungen des Schutzprofils PP [16]. Die Common Criteria erlauben die Anwendung verschiedener Operationen auf die funktionalen Sicherheitsanforderungen; Verfeinerung, Auswahl, Zuweisung und Iteration. Jede dieser Operationen wird in diesem Security Target angewandt. Die Operation Verfeinerung (refinement) wird genutzt, um Details zu einer Anforderung hinzuzufügen und schränkt diese Anforderung folglich weiter ein. In diesem Security Target werden Verfeinerung durch fettgedruckten Text in der Anforderung hervorgehoben und in einem der Anforderung folgenden Anwendungshinweis näher erläutert. Gelöschter Text wird fettgedruckt und durchgestrichen dargestellt. Die Operation Auswahl (selection) wird genutzt, um eine oder mehrere durch die CC vorgegebenen Optionen auszuwählen. In diesem Security Target wird eine bereits im PP [16] ausgeführte Auswahl durch unterstrichenen Text in der Anforderung hervorgehoben. Eine durch das PP bzw. durch die CC vorgegebene und im Security Target ausgeführte Auswahl wird zusätzlich durch [eckige Klammern] hervorgehoben. Für die Operationen ist durch eine Fußnote jeweils der Originaltext bzw. der Text des PP [16] angegeben. Die Operation Zuweisung (assignement) wird genutzt, um einem unspezifizierten Parameter einen spezifischen Wert zuzuweisen. In diesem Security Target werden bereits im PP [16] ausgeführte Zuweisungen durch kursiven Text in der Anforderung hervorgehoben. Durch das PP bzw. durch die CC vorgegebene und im Security Target ausgeführte Zuweisungen werden zusätzlich durch [eckige Klammern] hervorgehoben. Für die Operationen ist durch eine Fußnote jeweils der Originaltext bzw. der Text des PP [16] angegeben. Die Operation Iteration wird genutzt, um eine Komponente mit unterschiedlichen Operationen zu wiederholen. In diesem Security Target werden Iterationen durch einen Schrägstrich „/“ und den Iterationsidentifikator hinter dem Komponentenidentifikator angegeben. 6.1.2. Modellierung von Subjekten, Objekten, Attributen und Operationen Diese Sicherheitsvorgaben betrachten für jeden in Tabelle 8 definierten Benutzer gesonderte Subjekte, die in deren Auftrag handeln, d.h. für jeden Benutzer des Clientsystems auf den Arbeitsplätzen (des Clientsystems), den Anwendungskonnektor, jedes eHealth-Kartenterminal, und für jede gesteckte Chipkarte in jedem Chipkartensteckplatz eines jeden mit dem Konnektor verbundenen eHealth-Kartenterminal werden gesonderte Subjekte betrachtet. Zur Unterscheidung zwischen diesen Subjekten und den externen Benutzern werden die Subjekte in Parenthese gesetzt, z. B. bezeichnet HBA den Heilberufsausweis in der Einsatzumgebung Security Target secunet konnektor 2.1.0 secunet Seite 143 von 424 und S_HBA das Subjekt, welches den Heilberufsausweis als Datenquelle und Datensenke mit seinem Sicherheitsstatus EVG-intern abbildet. Für interne Prozesse, die von den Benutzern angefordert, aber unter interner Steuerung ablaufen, werden die gesonderten Subjekte Signaturdienst, Verschlüsselungsdienst, Chipkartendienst und Kartenterminaldienst definiert. Die Sicherheitsattribute der Benutzer bzw. Subjekte sind in Tabelle 8 definiert. 6.1.2.1. Subjekte Subjekt Beschreibung Sicherheitsattribut S_Administrator Subjekt, das für einen Administrator handelt. Siehe Tabelle 8. S_Signaturdienst Dienst des EVG zur Erstellung und Prüfung qualifizierter und nichtqualifizierter elektronischer Signaturen Das Subjekt übernimmt die Sicherheitsattribute des aufrufenden Benutzers S_Verschlüsselun gsdienst Dienst des EVG zur Verschlüsselung und Entschlüsselung von Dokumenten Kein Sicherheitsattribut S_Chipkarten- dienst Dienst des EVG zur Verwaltung und zum Zugriff auf gesteckte Chipkarten Kein Sicherheitsattribut S_Kartenterminal dienst Dienst des EVG zur Verwaltung und zum Zugriff auf eHealth- Kartenterminals Kein Sicherheitsattribut S_TSL_Dienst Zentraler TSL-Dienst der TI nach [40]. Stellt die TSL und die BNetzA-VL sowie deren Hash zum Download in der TI bereit. Für den Download BNetzA-VL und deren Hash wird der TSL-Dienst über das TLS-Protokoll angesprochen. Kein Sicherheitsattribut S_KSR „Update-Server“ in der TI. Stellt freigegebene Firmware-Update- Pakete für den TOE und eHealth Kartenterminals zum Download bereit. Kein Sicherheitsattribut Security Target secunet konnektor 2.1.0 Seite 144 von 424 secunet Subjekt Beschreibung Sicherheitsattribut S_AK Subjekt, das für einen Prozess des AK handelt, der für einen Funktionsaufruf des Clientsystems oder eines Fachmoduls handelt. Aufrufender: Das Sicherheits- attribut gibt an, ob der Aufruf durch ein Clientsystem oder ein Fachmodul erfolgte. S_NK Subjekt, das für einen Prozess des NK handelt. Kein Sicherheitsattribut S_Benutzer_Clie ntsystem Subjekt, das für den Benutzer des Clientsystems handelt. Der Benutzer wird durch den EVG identifiziert, und die korrekte Authentisierung gegenüber der zu benutzenden Chipkarte autorisiert. Im Fall der Stapelsignatur für die qualifizierte elektronische Signatur muss eine Autorisierung des Benutzers für das Signieren eines jeden einzelnen Dokuments bei Einfachsignatur oder eines Stapels bei der Stapelsignatur erfolgen. Im Fall der Komfortsignatur muss die Autorisierung einmalig bei Aktivierung der Komfortsignatur für eine HBA-Kartensitzung erfolgen. Identität des Benutzers: Datum zur Identifizierung des Benutzers des Clientsystems. Diese Identität muss den Chipkarten HBA, SMC-B und ggf. eGK zugeordnet werden können. Authorisierungsstatus: Status der Zuordnung des Benutzers des Clientsystems zu dem Authentisierungsstatus der Chipkarte in Abhängigkeit von der gewünschten Funktion. Werte: - „nicht autorisiert“: Zuordnung nicht durch Chipkarte bestätigt, - „autorisiert“: Zuordnung durch Chipkarte bestätigt. S_eHKT Subjekt des eHealth- Kartenterminals, das mit dem eHealth-Kartenterminal kommuniziert. eHealth- Kartenterminals besitzen mindestens 1 ID-000 Kartensteckplatz und mindestens 1 ID-1 Kartensteckplatz zur Aufnahme von Chipkarten. Identität: Umfasst die - ID.SMKT.AUT des eHealth- Kartenterminals, - physische Adresse im LAN-LE. Arbeitsplatz: zugeordneter Arbeitsplatz des eHealth-Kartenterminals. Kartenslot: Adresse des Kartenslots und die darin gesteckte Chipkarte. Authentisierungsstatus: - „nicht identifiziert“ – Kartenterminal unbekannter Security Target secunet konnektor 2.1.0 secunet Seite 145 von 424 Subjekt Beschreibung Sicherheitsattribut Identität ohne vereinbarte Pairing-Geheimnis - „identifiziert“ – Identität des eHealth-Kartenterminals ist bekannt, Pairing-Geheimnis bekannt, - „authentisiert“ – erfolgreiche Authentisierung mit der SMC als gSMC-KT und mit Pairing- Geheimnis, bestehender TLS- Kanal S_HBA Subjekt, das einem HBA in einem Chipkartensteckplatz eines eHealth- Kartenterminals zugeordnet ist Identität: - ICCSN, - eindeutige Referenz des Signaturschlüssel-Inhabers für die zu signierenden Daten - eindeutige Referenz des Entschlüsselungsschlüssel- inhabers für verschlüsselte Daten.27 Kartenhandle: identifiziert den HBA in einem Chipkartensteckplatzeines eHealth- Kartenterminals. S_gSMC-KT Subjekt, das einer Chipkarte gSMC- KT in einem Chipkartensteckplatz eines eHealth-Kartenterminals zugeordnet ist. Identität: ICCSN Kartenhandle: identifiziert die gSMC-KT in einem Chipkartensteckplatzeines eHealth- Kartenterminals. S_SMC-B Subjekt, das einer Chipkarte SMC- B in einem Chipkartensteckplatz eines eHealth-Kartenterminals zugeordnet ist.. Identität: - ICCSN, 27 Durch organisatorische Maßnahmen ist sicherzustellen, dass die Identität des Benutzers des Clientsystems (S_Benutzer_Clientsystem) und die Identität des Signaturschlüssel-Inhabers der zu signierenden Daten sowie des vorgesehenen Empfängers zu entschlüsselnder Daten eindeutig einander zugeordnet werden können. Security Target secunet konnektor 2.1.0 Seite 146 von 424 secunet Subjekt Beschreibung Sicherheitsattribut - eindeutige Referenz des Signaturschlüssel-Inhabers für die zu signierenden Daten - eindeutige Referenz des Entschlüsselungsschlüssel- inhabers für verschlüsselte Daten.28 Kartenhandle: identifiziert die SMC-B in einem Chipkartensteckplatzeines eHealth- Kartenterminals. Mandant: Zuordnung zu einem Mandanten. S_eGK Subjekt, das einer Chipkarte eGK in einem Chipkartensteckplatz eines eHealth-Kartenterminals zugeordnet ist. Identität: - ICCSN, - Identität des Chipkartenin- habers. Kartenhandle: identifiziert die eGK in einem Chipkartensteckplatzeines eHealth- Kartenterminals. S_Clientsystem Ein Clientsystem, das zum AK einen TLS-Kanal aufbauen kann und das den AK an dessen LAN Schnittstelle aufruft Schlüsselmaterial: Authentifizierungsmerkmal, mit dessen Hilfe der AK die Authentizität des Clientsystems überprüfen kann Mandant: Zuordnung zu einem Mandanten S_Fachmodul Subjekt, das für ein installiertes Fachmodul agiert. Fachmodule sind Teile von Fachanwendungen die auf dem Konnektor ablaufen (siehe auch Fachmodul im Glossar). Identität: eindeutiger Name zur Identifizierung des Fachmoduls 28 Durch organisatorische Maßnahmen ist sicherzustellen, dass die Identität des Benutzers des Clientsystems (S_Benutzer_Clientsystem) und die Identität des Signaturschlüssel-Inhabers der zu signierenden Daten sowie des vorgesehenen Empfängers zu entschlüsselnder Daten eindeutig einander zugeordnet werden können. Security Target secunet konnektor 2.1.0 secunet Seite 147 von 424 Subjekt Beschreibung Sicherheitsattribut S_VSDM_Fachm odul Subjekt des VSDM Fachmodules Identität: eindeutiger Name zur Identifizierung des Fachmoduls S_VSDM_Interm ediär Subjekt, das für den dem Fachdienst VSDD zugeordnete Intermediär agiert, zu dem der AK einen TLS Kanal aufbauen kann Schlüsselmaterial: Authentifizierungsmerkmal, mit dessen Hilfe der AK die Authentizität des Intermediär überprüfen kann S_ Fachdienst Subjekt, das für einen Fachdienst agiert. Fachdienste sind Teile von Fachanwendungen, die entfernt ablaufen (siehe auch Fachdienst im Glossar). Identität: eindeutiger Name zur Identifizierung des Fachdienstes S_VSDD_Fachdi enst Subjekt, das für den Fachdienst VSDD agiert, zu dem der AK einen logischen Kanal mit der eGK vermittelt. Schlüsselmaterial: Authentifizierungsmerkmal, mit dessen Hilfe die eGK die Authentizität des VSDD überprüfen kann S_CMS Subjekt, das für den Card Management Service Dienst agiert, zu dem der AK einen logischen Kanal mit der eGK vermittelt. Schlüsselmaterial: Authentifizierungsmerkmal, mit dessen Hilfe die eGK die Authentizität des CMS überprüfen kann PIN-Terminal Das PIN_Terminal dient zur Eingabe der PIN im Rahmen der Operationen zur entfernten oder lokalen PIN-Eingabe. Als PIN- Terminal werden eHealth- Kartenterminals genutzt, siehe auch S_eHKT. Siehe S_eHKT S_HBAx Subjektbezeichner, welcher sowohl den HBA, als auch die HBA- Vorläuferkarten (HBA-VK) adressiert (siehe auch HBAx im Glossar) . Identität: Sicherheitsattribut „HBA“ bzw. „HBA-VK“. Security Target secunet konnektor 2.1.0 Seite 148 von 424 secunet Subjekt Beschreibung Sicherheitsattribut S_Verzeichnisdie nst (VZD) Zentraler Verzeichnisdienst (VZD) in der TI nach [41]. Der VZD Enthält Einträge von Leistungserbringern und Institutionen mit allen definierten Attributen. Kein Sicherheitsattribut S_Benutzern Menge der folgenden Subjekte: a) S_AK b) S_Signaturdienst c) S_Benutzer_Clientsystem Siehe entsprechende Attribute der einzelnen Sublekte. Tabelle 14: Subjekte 6.1.2.2. Objekte Diese Sicherheitsvorgaben betrachten für die definierten Werte gesonderte Objekte und deren Sicherheitsattribute. Die definiert zusätzliche Objekte als Ressource, die der Zugriffskontrolle unterliegen und keine Datenobjekte sind, sowie deren Sicherheitsattribute. Objekt Beschreibung Sicherheitsattribut Chipkarte KVK, eGK, HBA, gSMC-K, SMC-B oder gSMC-KT Identität: ICCSN Kartentyp: KVK, eGK, HBA, gSMC-K, SMC-B oder gSMC-KT mit den dafür zulässigen Rollen Kartenhandle: identifziert eine in einem eHealth-Kartenterminal gesteckte Chipkarte Identität des Kartenslots: Kartenslot des eHealth- Kartenterminals, in dem die Chipkarte gesteckt ist. Identität des eHealth- Kartenterminal: eHealth- Kartenterminal, an dem die Chipkarte gesteckt ist. Security Target secunet konnektor 2.1.0 secunet Seite 149 von 424 Objekt Beschreibung Sicherheitsattribut Logischer Kanal einer Chipkarte Logischer Kanal eines HBA, einer SMC oder einer eGK. Sicherheitszustand: Sicherheitszustand des logischen Kanals der Chipkarte (vergl. COS- Spezifikation [31]). SICCT- Kommando Kommandos zur Steuerung der eHealth-Kartenterminals. Die SICCT-Kommandos dienen [38] [42] - der Steuerung des eHealth- Kartenterminals, insbesondere zur Kommunikation mit dem Konnektor, Kommandoabarbeitung und Konfiguration der eHealth- Kartenterminals (hier kurz „eHKT-Steuerungskommando“ genannt), - dem Zugriff auf die Anzeige (Display und Anzeige des gesicherten PIN-Modus), und die Tastatur (lesend) sowie ggf. dem Tongeber (hier kurz „Benutzer- kommuikationskommando“ genannt), - der Kontrolle, Aktivierung, Deaktivierung und Statusabfrage des elektrischen Zustands von Chipkartenkontaktiereinheiten und der Kommunikation mit Chipkarten in den Chipkartenslots (hier kurz „Chipkartenkommando“ genannt), und - die Auslösung der Prozesse zur PIN-Eingabe und dem PIN- Wechsel im gesicherten Modus (hier kurz „PIN- Prozesskommando“ genannt). Typ des SICCT-Kommandos: - eHKT-Steuerungskommando, - Benutzerkommuikationskom- mando, - Chipkartenkommando, - PIN-Prozesskommando. Antwort auf SICCT- Kommando Antwortnachricht des eHealth- Kartenterminals auf ein zuvor gesendetes SICCT-Kommando, siehe [42]. Kein Sicherheitsattribut Security Target secunet konnektor 2.1.0 Seite 150 von 424 secunet Objekt Beschreibung Sicherheitsattribut Arbeitsplatz Arbeitsplatz des Benutzers mit Kartenterminal. Identität des Arbeitsplatzes: Name des Arbeitsplatzes. Identität eHealth- Kartenterminals: Identität (Adresse) der am Arbeitsplatz verfügbaren eHealth- Kartenterminals. Zu signierende Dokumente Daten, deren Authentizität durch die qualifizierte elektronische Signatur oder nichtqualifizierte, elektronische Signaturen geschützt werden sollen und die an den EVG übergeben werden und deren Repräsentation (Hashwert) an die Signaturkarte zum signieren übertragen werden. Die Vertraulichkeit und Integrität zu signierender Dokumente ist zu schützen29 . Autorisierungsstatus: Status der Auswahl der Daten zur Erstellung einer qualifizierten elektronischen Signatur: - „nicht autorisiert“: Auswahl nicht durch Signaturschlüssel- Inhaber bestätigt - „autorisiert“: Auswahl durch Signaturschlüssel-Inhaber bestätigt. Signaturrichtlinie: Beschreibung der Regeln, welche Signatur (qualifiziert, nichtqualifizierte) zu erstellen ist, die signierten Dokumente zu formatieren und – im Fall der QES – wie die Daten darzustellen sind. Signaturstapel Ein Stapel zu signierender Daten, der (nach erfolgreicher Authentisierung des Signaturschlüsselinhabers mit der Signatur-PIN gegenüber der Signaturchipkarte) durch den Signaturdienst an die Signaturkarte zum Signieren gesendet wird. Kein Sicherheitsattribut Signierte Dokumente Daten, denen eine digitale Signatur zugeordnet ist. Die Vertraulichkeit Signaturrichtlinie: Beschreibung der Regeln, wie die Daten zu prüfen sind. 29 Der EVG schützt die Vertraulichkeit zu signierender Dokumente, da diese im allgemeinen Fall medizinische Daten sein können und keine explizite Aussage über einen ausschließlichen Schutz der Integrität getroffen werden kann. Security Target secunet konnektor 2.1.0 secunet Seite 151 von 424 Objekt Beschreibung Sicherheitsattribut signierter Daten ist zu schützen30 . Die signierten Daten dürfen durch den EVG nicht verändert werden. Angegebener Zeitpunkt: angenommener Zeitpunkt der Signturerzeugung auf den sich die Prüfung der qualifizierten elektronischen Signatur bezieht. Ordnungsgemäßigkeit der Signatur: Daten besitzen eine „ordnungsgemäße“ Signatur, wenn die Signaturen zu Daten eines Stapels zu signierender Daten gehören, mit dem Signaturschlüssel des Heilberufsausweises des autorisierten Benutzers des Clientsystems (S_Benutzer_Clientsystem) erzeugt wurden und wenn zum dazu gehörigen Signaturprüfschlüssel zum Signaturzeitpunkt (unter Beachtung der Grace Period) ein gültiges qualifiziertes Zertifikat existiert. Eine Signatur ist „ungültig“, wenn sie zu anderen Daten ausserhalb des Stapels zu signierender Daten gehören oder nicht mit dem öffentlichen Schlüssel des gültigen qualifizierten Zertifikats des autorisierten Benutzers des Clientsystems (S_Benutzer_Clientsystem) erfolgreich geprüft werden konnten. Signaturprüfungs- ergebnis Ergebnis der Prüfung einer Signatur als qualifizierte elektronische Signatur oder nichtqualifizierte elektronische Signatur, das durch den EVG für vorgelegte signierte Daten und einen angegebenen Zeitpunkt erzeugt und dem Benutzer des Clientsystems über die Schnittstellen bereitgestellt wird. Kein Sicherheitsattribut 30 Der EVG schützt die Vertraulichkeit signierten Dokumente, da diese im allgemeinen Fall medizinische Daten sein können und keine explizite Aussage über einen ausschließlichen Schutz der Integrität getroffen werden kann. Security Target secunet konnektor 2.1.0 Seite 152 von 424 secunet Objekt Beschreibung Sicherheitsattribut Die Vertraulichkeit und Integrität des Prüfergebnisses ist zu schützen31 . Zu signierender Bitstring Bitstring von maximal 512 Bit die dem EVG zur Weitergabe and Chipkarten und Erzeugung digitaler Signaturen zum Zweck der Authentisierung von Benutzern gegenüber anderen Instanzen übergeben werden. Kein Sicherheitsattribut Signierter Bitstring Von den Chipkarten empfangene digitale Signaturen von Bitstrings, die als zu signierende Bitstrings dem EVG übergeben wurden. Kein Sicherheitsattribut Zu verschlüsselnde Daten Klardaten, die für identifizierte Empfänger verschlüsselt werden sollen. Die Klardaten und die Empfänger werden vom Aufrufenden dem EVG übergeben und die verschlüsselten Daten an den Aufrufenden zurückgegeben. Die Vertraulichkeit dieser Klardaten ist zu gewährleisten. Objekt-ID: eindeutige Identität der zu verschlüsselnden Daten. Vorgeschlagene Empfänger: Identität der Empfänger der zu verschlüsselnden Daten, die vom Aufrufenden (auch zum Auffinden der zugehörigen Verschlüsselungs- zertifikate) vorgeschlagen werden Verschlüsselungsrichtlinie: siehe Beschreibung zur Verschlüsselungsrichtlinie im Glossar Verschlüsselte Daten Verschlüsselte Daten, die für einen Benutzer entschlüsselt werden sollen. Die verschlüsselten Daten werden vom Aufrufenden dem EVG übergeben und die entschlüsselten Daten an den Aufrufenden zurückgegeben. Vorgeschlagene Empfänger: Identität der Empfänger der zu entschlüsselnden Daten, die vom Aufrufenden (auch zum Auffinden der zugehörigen Entschlüsselungsschlüssel) vorgeschlagen werden. Verschlüsselungsrichtlinie: siehe Beschreibung zur 31 Der Schutz der Vertraulichkeit der Prüfungsergebnisse ergibt sich hier aus dem Bezug zu den vertraulichen zu signierenden bzw. signierten Daten. Security Target secunet konnektor 2.1.0 secunet Seite 153 von 424 Objekt Beschreibung Sicherheitsattribut Verschlüsselungsrichtlinie im Glossar. Ordnungsgemäss verschlüsselt: Status nach erfolgreicher Verschlüsselung wenn (a) die identifizierte Verschlüsselungsrichtlini e gültig ist, (b) zu den vorgesehenen Empfängern gültige Verschlüs- selungszertifikate existieren und für die Verschlüsselung des symmetrischen Schlüssels verwendet wurden, (c) die durch den Xpath- Ausdruck selektierten zu verschlüsselnden Daten vollständig verschlüsselt wurden und keine Fehler auftraten. Zu entschlüsselnde Daten Verschlüsselte Daten, die für einen Benutzer entschlüsselt werden sollen. Die entschlüsselten Klardaten werden an den Vorgeschlagenen ausgegeben. Die Vertraulichkeit der entschlüs- selten Klardaten einschließlich der kryptographischen Schlüssel ist innerhalb der Kontrolle des EVG zu gewährleisten. Vorgeschlagene Empfänger: Identität der Empfänger, für den die Daten entschlüsselt werden, und an den die Daten übergeben werden sollen. Verschlüsselungsrichtlinie: siehe Beschreibung zur Verschlüsselungsrichtlinie im Glossar. Entschlüsselte Daten Entschlüsselte Daten, die für einen Benutzer entschlüsselt wurden. Die entschlüsselten Klardaten werden an den Aufrufenden zurückgegeben. Die Vertraulichkeit der entschlüs- selten Klardaten einschließlich der kryptographischen Schlüssel ist Kein Sicherheitsattribut Security Target secunet konnektor 2.1.0 Seite 154 von 424 secunet Objekt Beschreibung Sicherheitsattribut innerhalb der Kontrolle des EVG zu gewährleisten. Daten der Chipkarten (Versichertenstam mdaten) Daten der eGK (geschützte Versichertenstammdaten), die durch den Konnektor von den Karten gelesen oder auf die Karte geschrieben werden. Versichertenstammdaten (VSD) der eGK: - geschützt Geschützte Versichertendaten (EF.GVD), die nur nach erfolgreicher Authentisierung ausgelesen werden können. - ungeschützt Teil der VSD bestehend aus persönlichen Daten (EF.PD) und Versichertendaten (EF.VD) die frei auslesbar sind. Objektsystem der Chipkarte (eGK) Objektsystem der eGK nach [32], Kein Sicherheitsattribut Konnektor/eHKT- Kommunikation Kommunikation zwischen dem Konnektor und den eHKT in Form von SICCT-Kommandos des Konnektors an die eHKT und Antworten der eHKT und den Konnektor32 Kein Sicherheitsattribut Authentisierungs- verifikationsdaten (VAD) Datum, das vom Benutzer zum Nachweis seiner Identität gegen- über Chipkarten dient. Dies sind VAD der Kartenhalter und die SVAD33 als Signaturschlüssel- Inhaber gegenüber der qualifizierten Signaturerstellungseinheit. Die VAD werden zur Authentisierung des Benutzers und zum Wechsel der VAD durch den Benutzer unter Steuerung des EVG an dem PIN- Kein Sicherheitsattribut 32 Die “Konnektor/eHKT-Kommunikation” schließt alle “Daten der Chipkarten“ ein, geht aber darüber hinaus, z. B. wird der sichere PIN-Modus durch die SICCT-Kommandos gesteuert sendet die eingegebene PIN direkt an eine gesteckte Chipkarte und nur der Returncode der Chipkarte wird an den Konnektor zurückgegeben. 33 Englisch: signatory verification authentication data. Security Target secunet konnektor 2.1.0 secunet Seite 155 von 424 Objekt Beschreibung Sicherheitsattribut Terminal eingegeben und an die Chipkarte übergeben. Dieses Datum kann eine PIN oder eine PUK sein34 . Die Vertraulichkeit und Integrität35 der VAD müssen geschützt werden. Authentisierungs- referenzdaten der Identität „SAK“ Kartenprüfbares Zertifikat C.SAK.AUTD_CVC, welches von dem EVG zum Nachweis seiner Identität gegenüber dem HBA und der SMC präsentiert wird und den öffentlichen Schlüssel PuK.SAK.AUTD_CVC enthält, der zum privaten Schlüssel PrK.SAK.AUTD_CVC korrespondiert. Kein Sicherheitsattribut Authentisierungs- referenzdaten des AK Kartenprüfbares Zertifikat C.SAK.AUT, welches von dem AK zum Nachweis seiner Identität gegenüber den eHealth- Kartenterminals36 präsentiert wird und den öffentlichen Schlüssel PuK.SAK.AUT enthält, der zum privaten Schlüssel PrK.SAK.AUT korrespondiert. Kein Sicherheitsattribut Zu sendende Daten zu schützende Daten, die vom Konnektor an eine andere Komponente der Telematikinfrastruktur übertragen werden. Die zu übertragenden Daten werden vor Übertragung verschlüsselt und integritätsgeschützt Kein Sicherheitsattribut Empfangene Daten zu schützende Daten, die von einer anderen Komponente der Telematikinfrastruktur an den Konnektor übertragen werden. Die Kein Sicherheitsattribut 34 Der Heilberufsausweis als qualifizierte Signaturerstellungseinheit unterstützt nur die Authentisierung durch Wissen. 35 Der Schutz der Integrität ist insbesondere bei einem Wechsel der SVAD erforderlich. 36 C.SAK.AUT kann nach gSMC-K-Spezifikation auch für die interne Kommunikation benutzt werden. Dies ist keine Verwendung als Authentisierungsreferenzdatum für externe Benutzer. Security Target secunet konnektor 2.1.0 Seite 156 von 424 secunet Objekt Beschreibung Sicherheitsattribut empfangenen Daten werden entschlüsselt und integritätsgeprüft. Es werden unverfälscht empfangene Daten ausgegeben. Datenobjekte des sicheren Datenspeichers (Datenobjekt des SDS) Datenobjekte, die im sicheren Datenspeicher gespeichert sind. Administrator: Werte „Administratorobjekt“ und „allgemeines Datenobjekt“ Schlüssel für sicheren Datenspeicher Der Zugriff auf den Inhalt des sicheren (geschützten) Datenspeichers durch den Konnektor ist durch Nutzung von Schlüsselmaterial abgesichert. Datenobjekte im sicheren Datenspeicher dürfen nur verschlüsselt gespeichert werden. Kein Sicherheitsattribut eHealth- Kartenterminal Ein im LAN des Leistungserbringers vorhandenes und gepaartes eHealth-KT Arbeitsplatz: zugeordneter Arbeitsplatz des eHealth-Kartenterminals:  eindeutige Identifikation  erlaubte Zuordnungen als lokales KT zu einem Arbeitsplatz  erlaubte Zuordnungen als entferntes KT zu einem Arbeitsplatz  erlaubte Zuordnungen als entferntes PIN-Eingabe-KT für eine Kombination aus Mandant und Arbeitsplatz  erlaubte Zuordnungen zu einem Mandanten Kartensitzung eGK Kartensitzung einer eGK Für jede eGK-Kartensitzung:  Bindung an den Arbeitsplatz, von dem aus Security Target secunet konnektor 2.1.0 secunet Seite 157 von 424 Objekt Beschreibung Sicherheitsattribut zuerst auf die eGK zugegriffen wurde  Karte, welche die eGK im Rahmen einer Card-to- Card- Authentisierung freigeschaltet hat Kartensitzung HBA Kartensitzung einer HBA Für jede HBA-Kartensitzung:  Bindung an das Primärsystem und die UserID, unter deren Kontext zuerst auf den HBA zugegriffen wurde Kartensitzung SMC-B bzw. SM- B Kartensitzung einer SMC-B bzw. SM-B-Sitzung Für jede SMC-B- bzw. SM-B- Sitzung:  Bindung an den Mandanten, von dem aus auf die SMC-B bzw. SM-B zugegriffen wurde  Karte, welche die SMC-B bzw. SM-B im Rahmen einer Card-to-Card- Authentisierung freigeschaltet hat Clientsystem Ein im LAN des Leistungserbringers vorhandenes Clientsystem Für jedes Clientsystem:  eindeutige Identifikation,  Authentisierungsmerkmal (z. B. TLS-Zertifikat),  erlaubte Zuordnungen zu Arbeitsplätzen  erlaubte Zuordnungen zu Mandanten Neben diesen statischen Sicherheitsattributen verwaltet der AK für das Clientsystem das folgende dynamische Sicherheitsattribut:  dynamische exklusive Bindung einer HBA- Kartensitzung an ein Clientsystem Security Target secunet konnektor 2.1.0 Seite 158 von 424 secunet Objekt Beschreibung Sicherheitsattribut Mandant Nach dem Informationsmodell werden Mandanten dem Clientsystem sowie vom Konnektor verwalteten externen Ressourcen (Kartentermi-nal mit Slots, Arbeitsplatz mit Signaturproxy und SMC-Bs) persistent zugeordenet . Kein Sicherheitsattribut verwaltete SMC-B Ein im LAN des Leistungserbringers verwaltetes SMC-B, siehe Infomodell in Spezifikation Konnektor Für jede verwaltete SMC-B  eindeutige Identifikation  der SMC-B fest zugeordnete Mandanten TLS-Kanal Transport Layer Security. Protokoll zur Verschlüsselung von Datenübertragungen, das einen sicheren Kanal zwischen Anwendungskonnektor und Fachdiensten oder Zentralen Diensten der TI bietet. Anfordernder TLS-Client: Identität des Clientsystems (Fachmodul), das den Aufbau des TLS-Kanals angefordert hat. Der Anwendungskonnektor S_AK steuert und verwaltet den TLS- Kanal zum Fachdienst für das Fachmodul. Eingeschränkter Text Text, der keine unerlaubten Zeichenketten enthält, die den Benutzer des Kartenterminals zur Eingabe einer PIN oder PUK im ungeschützten Mode verleiten könnte. Beispiele für unerlaubte Zeichenketten sind „PIN“, PUK“, „Geheimzahl“ oder „Code“ und deren Abwandlungen durch Groß- Kleinschreibungen oder andere irreführende Schreibweisen (vergl. [27], Kap. 4.1.4.4) Kein Sicherheitsattribut Update-Pakete Software-Komponenten eines zukünftigen EVG, die im Sinne eines Update Prozesses zur Aktualisierung der laufenden Version der Software- Komponente des EVG dienen soll Signatur: Intergritätsschutz des Update- Paketes Zulässige Software-Versionen: Firmware-Gruppe nach [69]. In jeder Konnektor-Software muss Security Target secunet konnektor 2.1.0 secunet Seite 159 von 424 Objekt Beschreibung Sicherheitsattribut eine versionierte Liste zulässiger Firmware-Versionen für Software- Updates integriert sein. Signaturschlüssel externer Signaturchipkarten Schlüssel des HBA oder der SM-B der vom Signaturdienst des Anwendungskonnektors für die erstellung von Signaturen verwedet wird. Kein Sicherheitsattribut Authentisierungssc hlüssel von HBAx oder SM-B Schlüssel des HBAx oder der SM- B der für die Authentsierung zum Signaturdienst verwendet wird. Kein Sicherheitsattribut Tabelle 15: zusätzliche Objekte Die Operationen der Subjekte auf Objekte sind in den Tabellen Tabelle 17, Tabelle 18, Tabelle 19, Tabelle 20, Tabelle 21 und Tabelle 23 nach den jeweiligen Komponenten FDP_ACF definiert. 6.1.2.3. TSF Daten TSF Datum Beschreibung Öffentlicher Schlüssel zur Prüfung der BNetzA-VL BNetzA-VL. Öffentlicher Schlüssel zur Prüfung der XML-Signatur der BNetzA-VL. Dieser Schlüssel des Signer-Zertifikats, mit dem die Signatur der Vertrauensliste (BNetzA-VL) geprüft wird, stellt den QES-Vertrauensanker dar. Die Integrität dieses Schlüssels ist zu schützen. Das BNetzA-VL-Signer-Zertifikat wird durch die Bundesnetzagentur veröffentlicht. Es ist in der TSL enthalten und wird über diese aktualisiert. Entsprechend wird ein neuer QES-Vertrauensanker beim Aktualisierungsprozess der TSL nur durch die Signatur der TSL geschützt, welche mittels des öffentlichen Schlüssel zur Prüfung von TSL geprüft wird Öffentlicher Schlüssel zur Prüfung von TSL Öffentlicher Schlüssel zur Prüfung der XML-Signatur der TSL. Das zur Prüfung des TSL-Signer-Zertifikates notwendige TSL-Signer-CA- Zertifikat ist bei Auslieferung in der gSMC-K vorhanden und kann im Rahmen eines geplanten Wechsels des TI-Vertrauensankers durch ein Folgezertifikat ersetzt werden. Öffentlicher Schlüssel der Sub- CA der Verschlüsselungs zertifikate (CA certificates of an encryption PKI) Öffentliche Schlüssel einer Sub-CA, die Zertifikate für die Verschlüsselung von Daten erstellen. Der EVG kann einen oder mehrere dieser öffentlichen Schlüssel speichern. Die Verteilung dieser Schlüssel erfolgt durch die TSL. Die Integrität dieses Schlüssels bzw. dieser Schlüssel ist zu schützen. Security Target secunet konnektor 2.1.0 Seite 160 von 424 secunet TSF Datum Beschreibung Öffentlicher Schlüssel der Wurzelinstanz der CVC (public keys of the CVC root CA) Öffentlicher Schlüssel PuK.RCA.CS der Wurzelinstanz und somit Vertrauensanker der kartenprüfbaren Zertifikate (CVC) des Gesundheitswesens. Der Schlüssel ist fester Bestandteil des EVG und kann nicht geändert werden. Die Integrität dieses Schlüssels bzw. dieser Schlüssel ist zu schützen. Man beachte, dass PuK.RCA.CS auch auf anderen technischen Komponenten, die CVC besitzen, gespeichert sein kann. Diese dürfen aber nicht für die Prüfung dieser (oder anderer) Komponenten verwendet werden. Die CVC-Zertifikate der CA, die ebenfalls auf diesen Komponenten gespeichert sein können, sind nur ein Zwischenschritt in der CVC-Kette und dürfen nicht ungeprüft verwendet werden. Authentisierungs- verifikationsdaten der Identität „SAK“. Privater Schlüssel PrK.SAK.AUTD_CVC, welcher von der SAK zum Nachweis ihrer Identität gegenüber dem HBA benutzt wird und zum öffentlichen Schlüssel PuK.SAK.AUTD_CVC im Zertifikat C.SAK.AUTD_CVC korrespondiert. Authentisierungs- verifikationsdaten der AK Privater Schlüssel PrK.SAK.AUT, welcher von dem AK zum Nachweis seiner Identität gegenüber den eHealth-Kartenterminals benutzt wird und zum öffentlichen Schlüssel PuK.SAK.AUT im Zertifikat C.SAK.AUT korrespondiert. Authentisierungs- referenzdaten der eHealth-Karten- terminals Identität für die Identifizierung und Authentisierungsreferenzdaten (Pairing- Daten) für die Authentisierung jedes mit dem AK gepaarten eHealth- Kartenterminals. Authentisierungs- referenzdaten des Administrators Identität für die Identifizierung und Authentisierungsreferenzdaten für die Authentisierung des Administrators. Identität des Arbeitsplatzes Identität des Arbeitsplatzes des Benutzers für die Anforderung von Sicherheitsdiensten des EVG, die vom Clientsystem an den EVG übergeben wird. Arbeitsplatz- konfigurations- daten Die Zuordnung der Identität des Arbeitsplatzes zu dem am Arbeitsplatz zur Verfügung stehenden eHealth-Kartenterminals mit deren Anzeige, PIN-Pad und den Chipkartenslots. Für die eHealth-Kartenterminals wird nach dem Aufstellungsort und dem Zugriff durch der Benutzer des Arbeitsplatzes unterschieden zwischen (a) den lokal am Arbeitsplatz aufgestellten eHealth-Kartenterminals, deren gesteckte Chipkarten er zugreifen, dessen PIN-Pad er bedienen und dessen Anzeige des Arbeitsplatzes er sehen kann, und (b) den entfernt vom Arbeitsplatz aufgestellten eHealth-Kartenterminals, auf deren gesteckte Chipkarten er remote zugreifen darf, ohne das PIN- Pad bedienen oder die Anzeige sehen zu können. Kartenhandle Daten zur Identifizierung einer gesteckten Chipkarte in einem konfigurierten eHealth-Kartenterminal. Security Target secunet konnektor 2.1.0 secunet Seite 161 von 424 Tabelle 16: Übersicht über TSF Daten 6.2. Funktionale Sicherheitsanforderungen des Netzkonnektors Die funktionalen Sicherheitsanforderungen werden im Folgenden nicht wie sonst häufig in alphabetischer Reihenfolge aufgezählt, sondern nach funktionalen Gruppen gegliedert. Dadurch soll ein besseres Verständnis der Anforderungen und ihrer Abhängigkeiten untereinander erreicht werden. Die funktionalen Gruppen orientieren sich an den in Abschnitt 1.3.5 beschriebenen Sicherheitsdiensten (hier nur kurz in Stichworten rekapituliert): - VPN-Client: gegenseitige Authentisierung, Vertraulichkeit, Datenintegrität, Informationsflusskontrolle (erzwungene VPN-Nutzung für sensitive Daten); - Dynamischer Paketfilter: sowohl für WAN als auch für LAN; - Netzdienste: Zeitsynchronisation über sicheren Kanal, Zertifikatsprüfung mittels Sperrlisten; - Stateful Packet Inspection: Generierung von Audit-Daten für spätere zustandsgesteuerte Filterung; - Selbstschutz: Speicheraufbereitung, Selbsttests, sicherer Schlüsselspeicher, Schutz von Geheimnissen, optional sichere Kanäle zu anderen Komponenten des Konnektors, Protokollierung Sicherheits-Log; - Administration: Möglichkeit zur Wartung, erzwungene Authentisierung des Administrators, eingeschränkte Möglichkeit der Administration von Firewall-Regeln. - Nutzung starker kryptographischer Verfahren für TLS-Verbindungen. Um die Semantik von Sicherheitsanforderungen leichter erkennen zu können, wurden den Anforderungen teilweise Suffixe angehängt, z. B. „/NK.VPN_TI“ für den Trusted Channel, der den VPN-Kanal in die Telematikinfrastruktur fordert (siehe FTP_ITC.1/NK.VPN_TI). Diese Vorgehensweise erleichtert es auch, inhaltlich zusammenhängende Anforderungen zu identifizieren (z. B. FDP_IFC.1/NK.PF, FDP_IFF.1/NK.PF und FMT_MSA.3/NK.PF) und iterierte Komponenten zu unterscheiden. Für alle SFRs aus diesem Security Target wurde zudem das Suffix „NK“ verwendet, selbst wenn keine Iteration vorliegt. Das wurde zur Vereinfachung im Umgang mit der vorgesehenen Evaluierung des Gesamt-Konnektors eingeführt, bei der die in diesem Security Target definierten SFRs wiederverwendet werden.. 6.2.1. VPN-Client VPN FTP_ITC.1/NK.VPN_TI Inter-TSF trusted channel Dependencies: No dependencies. FTP_ITC.1.1/NK.VPN_TI The TSF shall provide a communication channel between itself and another trusted IT product VPN-Konzentrator der Security Target secunet konnektor 2.1.0 Seite 162 von 424 secunet Telematikinfrastruktur37 that is logically distinct from other communication channels and provides assured identification of its end points using certificate based authentication38 and protection of the channel data from modification and39 disclosure. FTP_ITC.1.2/NK.VPN_TI The TSF shall permit the TSF40 to initiate communication via the trusted channel. FTP_ITC.1.3/NK.VPN_TI The TSF shall initiate communication via the trusted channel for communication with the TI41 . Refinement: Die Anforderung „protection of the channel data from modification and disclosure“ in FTP_ITC.1.1/NK.VPN_TI ist zu verstehen als Schutz der Integrität und der Vertraulichkeit (der Kanal muss beides leisten). Der Trusted Channel muss auf Basis des IPsec-Protokolls aufgebaut werden (siehe Konnektor-Spezifikation [27], RFC 4301 (IPsec) [56], RFC 4303 (ESP) [59]). Zusätzlich soll NAT-Traversal (siehe RFC 7296 [60]) unterstützt werden. Die Anforderung „assured identification” in FTP_ITC.1.1/NK.VPN_TI impliziert, dass der EVG die Authentizität des VPN-Konzentrators überprüfen muss. Im Rahmen dieser Überprüfung muss er eine Zertifikatsprüfung durchführen (siehe FPT_TDC.1/NK.Zert). Erläuterung: Die von O.NK.VPN_Auth geforderte gegenseitige Authentisierung der Endpunkte wird durch FTP_ITC.1.1/NK.VPN_TI geleistet (assured identification of its end points). Der von O.NK.VPN_Vertraul und O.NK.VPN_Integrität geforderte Schutz der Vertraulichkeit und Datenintegrität der Nutzdaten wird ebenfalls durch FTP_ITC.1.1/NK.VPN_TI geleistet (protection of the channel data from modification and disclosure). Um beide Aspekte verbindlich zu machen, wurde die Verfeinerung (refinement) von or zu and durchgeführt. FTP_ITC.1/NK.VPN_SIS Inter-TSF trusted channel Dependencies: No dependencies. FTP_ITC.1.1/NK.VPN_SIS The TSF shall provide a communication channel between itself and another trusted IT product Sicherer Internet Service (SIS)42 that is logically distinct from other communication channels 37 refinement 38 refinement 39 refinement (or  and) 40 [selection: the TSF, another trusted IT product] 41 [assignment: list of functions for which a trusted channel is required] 42 refinement Security Target secunet konnektor 2.1.0 secunet Seite 163 von 424 and provides assured identification of its end points using certificate based authentication43 and protection of the channel data from modification and44 disclosure. FTP_ITC.1.2/NK.VPN_SIS The TSF shall permit the TSF45 to initiate communication via the trusted channel. FTP_ITC.1.3/NK.VPN_SIS The TSF shall initiate communication via the trusted channel for all communication with the SIS46 . Refinement: Die Anforderung „protection of the channel data from modification and disclosure“ in FTP_ITC.1.1/NK.VPN_SIS ist zu verstehen als Schutz der Integrität und der Vertraulichkeit (der Kanal muss beides leisten) aller Kommunikation mit dem Internet. Der Trusted Channel muss auf Basis des IPsec-Protokolls aufgebaut werden (siehe Konnektor-Spezifikation [27], RFC 4301 (IPsec) [56], RFC 4303 (ESP) [59]). Zusätzlich soll NAT-Traversal (siehe RFC 7296 [60]) unterstützt werden. Die Anforderung „assured identification” in FTP_ITC.1.1/NK.VPN_SIS impliziert, dass der EVG die Authentizität des VPN-Konzentrators überprüfen muss. Im Rahmen dieser Überprüfung muss er eine Zertifikatsprüfung durchführen (siehe FPT_TDC.1/NK.Zert). Erläuterung: Die von O.NK.VPN_Auth geforderte gegenseitige Authentisierung der Endpunkte wird durch FTP_ITC.1.1/NK.VPN_SIS geleistet (assured identification of its end points). Der von O.NK.VPN_Vertraul und O.NK.VPN_Integrität geforderte Schutz der Vertraulichkeit und Datenintegrität der Nutzdaten wird ebenfalls durch FTP_ITC.1.1/NK.VPN_SIS geleistet (protection of the channel data from modification and disclosure). Um beide Aspekte verbindlich zu machen, wurde die Verfeinerung (refinement) von or zu and durchgeführt. Anwendungshinweis 77:Der EVG unterstützt RFC 7296 (IKEv2) [60], siehe [30], Kapitel 3.3.1. Dieser Hinweis bezieht sich auf FTP_ITC.1.1/NK.VPN_SIS und FTP_ITC.1.1/NK.VPN_TI. Anwendungshinweis 78:Die Kommunikation von EVGs untereinander ist nicht vorgesehen. Informationsflusskontrolle Die von O.NK.PF_WAN und O.NK.PF_LAN erzwungene VPN-Nutzung für zu schützende Daten der TI und der Bestandsnetze und für zu schützende Nutzerdaten (im Sinne des Abschnitts 3.1) wird durch FDP_IFF.1.2/NK.PF umgesetzt, sofern die Paketfilter-Regeln 43 refinement 44 refinement (or  and) 45 [selection: the TSF, another trusted IT product] 46 [assignment: list of functions for which a trusted channel is required] Security Target secunet konnektor 2.1.0 Seite 164 von 424 secunet geeignet gesetzt sind, was wiederum durch die Administratordokumentation (siehe das Refinement zu AGD_OPE.1 in Abschnitt 6.2.8) sichergestellt wird. 6.2.2. Dynamischer Paketfilter mit zustandsgesteuerter Filterung Dynamischer Paketfilter FDP_IFC.1/NK.PF Subset information flow control Dependencies: FDP_IFF.1 Simple security attributes hier erfüllt durch: FDP_IFF.1/NK.PF FDP_IFC.1.1/ NK.PF The TSF shall enforce the packet filtering SFP (PF SFP)47 on the subjects (1) IAG, (2) VPN concentrator of the TI, (3) VPN concentrator of the SIS, (4) the TI services , (5) application connector (except the service modules), (6) the service modules (German: Fachmodule) running on the application connector, (7) active entity in the LAN, (8) CRL download server, (9) TSL-Dienstserver (10) hash&URL server, (11) registration server of the VPN network provider, (12) remote management server, the information (1) incoming information flows (2) outgoing information flows and the operation (1) receiving data, (2) sending data, (3) communicate (i.e. sending and receiving data)48 . 47 [assignment: information flow control SFP] 48 [assignment: list of subjects, information, and operations that cause controlled information to flow to and from controlled subjects covered by the SFP] Security Target secunet konnektor 2.1.0 secunet Seite 165 von 424 Anwendungshinweis 79:Die dynamischen Paketfilter (LAN-seitig und WAN-seitig) sollen sowohl den EVG vor Angriffen bzw. vor unerlaubten Informationsflüssen (i) aus dem LAN und (iii) aus dem WAN schützen als auch die Informationsflüsse zwischen (ii) LAN und WAN bzw. (iv) zwischen WAN und LAN kontrollieren. Anwendungshinweis 80:Systembedingt bietet IPv4 (Internet Protocol, Version 4) nur eine Identifikation der Informationsflüsse, aber keine Authentisierung. Aus Mangel an besseren Mechanismen müssen dennoch auf dieser Basis die Entscheidungen über die Zulässigkeit von Informationsflüssen getroffen werden. Für die Beschreibung der Filterregeln werden folgende IP-Adressbereiche definiert: IP-Adressbereich Instanz für Kommunikation mit dem Konnektor ANLW_WAN_NETWORK_SEGME NT IP-Adresse / Subnetzmaske des lokalen Netzes des LE, in dem der WAN-Adapter des Konnektors angeschlossen ist. ANLW_LAN_NETWORK_SEGMEN T IP-Adresse / Subnetzmaske des lokalen Netzes des LE, in dem der LAN-Adapter des Konnektors angeschlossen ist. ANLW_LEKTR_INTRANET_ROUT ES Adressbereich des Intranet-VPN des LE NET_SIS VPN-Konzentratoren der SIS NET_TI_ZENTRAL Zentrale Dienste der TI NET_TI_DEZENTRAL Adressbereich der WAN-Schnittstellen der Konnektoren für die Kommunikation mit der TI oder den Bestandsnetzen NET_TI_OFFENE_FD Offene Fachdienste der TI NET_TI_GESICHERTE_FD Gesicherte Fachdienste der TI ANLW_BESTANDSNETZE die an die TI angeschlossenen Bestandsnetze ANLW_AKTIVE_BESTANDSNETZ E die an die TI angeschlossenen und vom Administrator freigeschalteten Bestandsnetze VPN_KONZENTRATOR_TI_IP_AD DRESS IP-Adresse des VPN-Konzentrators der TI VPN_KONZENTRATOR_SIS_IP_AD DRESS IP-Adresse des VPN-Konzentrators des SIS DNS_SERVERS_BESTANDSNETZE IP-Adressen von DNS-Servern für die Bestandsnetze (ANLW_BESTANDSNETZE) Security Target secunet konnektor 2.1.0 Seite 166 von 424 secunet IP-Adressbereich Instanz für Kommunikation mit dem Konnektor CERT_CRL_DOWNLOAD_ADDRES S IP-Adresse des CRL-Download-Servers TSL Diensteserver IP-Adresse des TSL-Diensteserver Hierzu zählen die Download-Bereiche: CERT_TSL_DOWNLOAD_ADDRESS_INTER NET, CERT_TSL_DOWNLOAD_ADDRESS_INTER NET_BU CERT_TSL_IP_ADDRESS_INTERNET CERT_TSL_IP_ADDRESS_INTERNET_BU DNS_ROOT_ANCHOR_URL IP-Adresse des DNSSEC Vertrauensankers für das Internet hash&URL-Server IP-Adresse des hash&URL-Servers registration server IP-Adresse des Registrierungsservers remote management server IP-Adresse des Remote-Managementservers ANLW_IAG_ADDRESS ANLW_IAG_ADDRESS ist die Adresse des Default Gateways. Diese IP-Adresse MUSS innerhalb des ANLW_WAN_NETWORK_SEGMENT liegen. IP-Adressen Erläuterung ANLW_LAN_IP_ADDRESS LAN-seitige Adresse des EVG, unter dieser Adresse werden die Dienste des Konnektor im lokalen Netzwerk bereitgestellt werden. ANLW_WAN_IP_ADDRESS WAN-seitige Adresse des EVG VPN_TUNNEL_TI_INNER_IP IP-Adresse des Konnektors als Endpunkt der IPSec-Kanäle mit den VPN-Konzentratoren der TI VPN_TUNNEL_SIS_INNER_IP IP-Adresse des Konnektors als Endpunkt der IPSec-Kanäle mit den VPN-Konzentratoren des SIS Für die Beschreibung der Filterregeln werden folgende Konfigurationsparameter des EVG definiert: Security Target secunet konnektor 2.1.0 secunet Seite 167 von 424 Konfigurationsparameter Bedeutung und [Werte] ANLW_WAN_ADAPTER_MODUS Parameter aktiviert [ENABLED] oder deaktiviert [DISABLED] den WAN-Port des EVG ANLW_ANBINDUNGS_MODUS Parameter beschreibt die Art der Anbindung des EVGs in das LAN des Nutzers. Bei Schaltung [InReihe] befindet sich der EVG als erste Komponente hinter dem IAG und das LAN spannt sich hinter dem EVG auf. Wenn ANLW_WAN_ADAPTER_MODUS=ENABLED befindet sich der EVG in dieser Schaltung. Bei Schaltung [Parallel] befindet sich der EVG als eine von weiteren Komponenten im LAN. Wenn ANLW_WAN_ADAPTER_MODUS=DISABLED befindet sich der EVG in dieser Schaltung. MGM_LOGICAL_SEPARATION Parameter aktiviert [Enabled] oder deaktiviert [Disabled] die logische Trennung, wodurch trotz Verbindung des EVG mit dem IAG und darüber mit TI Services eine Verbindung von Clientsystemen mit dem Internet, TI Services und Bestandsnetzen vom EVG unterbunden wird. ANLW_INTERNET_MODUS Parameter regelt das Routing von Paketen von Clientsystemen im LAN mit dem Ziele im Bereich Internet. Bei Konfiguration [KEINER] wird kein Traffic ins Internet geroutet. Bei Konfiguration [SIS] wird Internet-Traffic aus dem LAN über den VPN-Tunnel zum SIS geroutet. Bei Konfiguration [IAG] wird das Clientsystem per ICMP-Redirect auf die Route zum IAG verwiesen. ANLW_FW_SIS_ADMIN_RULES Hierbei handelt es sich um vom Administrator definierte Firewall-Regeln (zusätzlich zu den hier beschriebenen) für den einschränkenden Zugriff auf den SIS. Werte sind hier Regeln mit den Parametern Absender-IP-Adresse, Empfänger-IP-Adresse, Protokoll (ggf. mit Absender-Port und Empfänger- Port) und Verbindungsrichtung. Security Target secunet konnektor 2.1.0 Seite 168 von 424 secunet FDP_IFF.1/NK.PF Simple security attributes Dependencies: FDP_IFC.1 Subset information flow control hier erfüllt durch: FDP_IFC.1/NK.PF FMT_MSA.3 Static attribute initialisation hier erfüllt durch: FMT_MSA.3/NK.PF (restriktive Filterregeln) FDP_IFF.1.1/NK.PF The TSF shall enforce the PF SFP49 based on the following types of subject and information security attributes: For all subjects and information as specified in FDP_IFC.1/NK.PF, the decision shall be based on the following security attributes: (1) IP address, (2) port number, (3) protocol type, (4) direction (inbound and outbound IP50 traffic) The subject active entity in the LAN has the security attribute IP address within ANLW_LAN_NETWORK_SEGMENT or ANLW_LEKTR_INTRANET_ROUTES.51 FDP_IFF.1.2/NK.PF The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: (1) For every operation receiving or sending data the TOE shall maintain a set of packet filtering rules that specifies the allowed operations by (i) direction (inbound or outbound), (ii) source and destination IP address involved, and (iii) source and destination port numbers involved in the information flow. (2) The TSF is allowed to communicate with the IAG through the LAN interface if (ANLW_WAN_ADAPTER_MODUS = DISABLED). (3) The TSF shall communicate with the IAG through the WAN interface if (ANLW_WAN_ADAPTER_MODUS = ACTIVE and ANLW_ANBINDUNGS_MODUS = InReihe). (4) The connector using the IP address ANLW_WAN_IP_ADDRESS is allowed to communicate via IAG 49 [assignment: information flow control SFP] 50 IP = Internet Protocol 51 [assignment: list of subjects and information controlled under the indicated SFP, and for each, the security attributes] Security Target secunet konnektor 2.1.0 secunet Seite 169 von 424 a) by means of IPSEC protocol with VPN concentrator of TI with IP-Address VPN_KONZENTRATOR_TI_IP_ADD- RESS, b) by means of IPSEC protocol with VPN concentrator of SIS with IP-Address VPN_KONZENTRATOR_SIS_IP_ADD- RESS, c) by means of protocols HTTP and HTTPS with IP-Address CERT_CRL_DOWNLOAD_ADDRESS, TSL-Diensteserver, DNS_ROOT_ANCHOR_URL, hash&URL Server, registration server and remote management server, d) by means of protocol DNS to any destination. (5) The active entities in the LAN with IP addresses within ANLW_LAN_NETWORK_SEGMENT or ANLW_LEKTR_IN- TRANET_ROUTES are allowed to communicate with the connector for access to base services. (6) The application connector is allowed to communicate with active entities in the LAN. (7) The TSF shall allow a) to establish the IPsec tunnel with the VPN concentrator of TI if initiated by the application connector and b) to send packets with destination IP address VPN_KONZENTRATOR_TI_IP_ADDRESS and to receive packets with source IP address VPN_KONZENTRA- TOR_TI_IP_ADDRESS in the outer header of the IPsec packets. (8) The following rules based on the IP addresses in the inner header of the IPSec packet apply for the communication TI through the VPN tunnel between the connector and the VPN concentrator: a) Communication is allowed between entities with IP address within NET_TI_ZENTRAL and application connector. b) Communication is allowed between entities with IP address within NET_TI_GESICHERTE_FD and application connector. c) If MGM_LU_ONLINE=Enabled the communication between entities with IP address within NET_TI_GESICHERTE_FD and by service moduls is allowed. d) Communication between entities with IP address within NET_TI_OFFENE_FD and active entity in the LAN is allowed. e) Communication between entities with IP address within NET_TI_OFFENE_FD and a service module is allowed. Security Target secunet konnektor 2.1.0 Seite 170 von 424 secunet f) If (MGM_LU_ONLINE=Enabled and MGM_LOGI- CAL_SEPARATION=Disabled) the TSF shall allow communication of connector with DNS with IP address within DNS_SERVERS_BESTANDSNETZE. g) If (MGM_LU_ONLINE=Enabled and MGM_LOGI- CAL_SEPARATION=Disabled) the TSF shall allow communication of active entities in the LAN with entities with IP address within ANLW_AKTIVE_BESTANDSNETZE. (9) The TSF shall allow a) to establish the IPsec tunnel with the SIS concentrator if initiated by the application connector and b) to send packets with destination IP address VPN_KONZENTRATOR_SIS_IP_ADDRESS and to receive packets with source IP address VPN_KONZENTRA- TOR_SIS_IP_ADDRESS in the outer header of the IPsec packets.. (10) Packets with source IP address within NET_SIS shall be received with outer header of the VPN tunnel from the VPN concentrator of the SIS only. (11) For the communication though the VPN tunnel with VPN concentrator of the SIS the following rules based on the IP addresses in the inner header of the IPSec packets apply: a) If (MGM_LU_ONLINE=Enabled and MGM_LOGI- CAL_SEPARATION=Disabled and ANLW_INTERNET_MODUS=SIS) the application connector and active entities in the LAN are allowed to communicate through the VPN tunnel with the SIS. b) The rules ANLW_FW_SIS_ADMIN_RULES applies if defined. (12) The TSF shall redirect the packets received from active entities in the LAN to the default gateway if the packet destination address is not (NET_TI_ZENTRAL or NET_TI_OFFENE_FD or NET_TI_GESICHERTE_FD or ANLW_AKTIVE_BESTAND- SNETZE) and if (MGM_LU_ONLINE=Enabled and MGM_LOGICAL_SEPARATION=Disabled and ANLW_IN- TERNET_MODUS=IAG). (13) The TSF shall redirect communication from IAG to active entities in the LAN if (MGM_LU_ONLINE=Enabled and MGM_LOGICAL_SEPARATION=Disabled and Security Target secunet konnektor 2.1.0 secunet Seite 171 von 424 ANLW_INTERNET_MODUS=IAG und ANLW_IAG_ADDRESS≠““).52 FDP_IFF.1.3/NK.PF The TSF shall enforce the following additional information flow control SFP rules: (1) The TSF shall enforce SFP rules ANLW_FW_SIS_ADMIN_RULES (2) The TSF shall transmit data (except for establishment of VPN connections) to the WAN only if the IPsec VPN tunnel between the TSF and the remote VPN concentrator has been successfully established and is active and working53 . FDP_IFF.1.4/NK.PF The TSF shall explicitly authorise an information flow based on the following rules: Stateful Packet Inspection, [no additional rules]54 . Refinement: Stateful Packet Inspection (zustandsgesteuerte Filterung) bedeutet in diesem Zusammenhang, dass der EVG zur Entscheidungsfindung, ob ein Informationsfluss zulässig ist oder nicht, nicht nur jedes einzelne Paket betrachtet, sondern auch den Status einer Verbindung mit in diese Entscheidung einbezieht. FDP_IFF.1.5/NK.PF The TSF shall explicitly deny an information flow based on the following rules: (1) The TSF prevents direct communication of active entities in the LAN, application connector and service modules with NET_TI_GESICHERTE_FD, NET_TI_OFFENE_FD, NET_TI_ZENTRAL, NET_TI_DEZENTRAL outside VPN channel to VPN concentrator of the TI. (2) The TSF prevents direct communication of active entities in the LAN, application connector and service modules with SIS outside VPN channel to VPN concentrator of the SIS. (3) The TSF prevents communication of active entities in the LAN with destination IP address within ANLW_AKTIVE_BESTANDSNETZE initiated by active entities in the LAN, if (MGM_LOGICAL_SEPARATION=Enabled). (4) The TSF prevents communication of active entities in the LAN with entities with IP addresses within ANLW_BESTANDSNETZE but outside ANLW_AK- TIVE_BESTANDSNETZE. 52 [assignment: for each operation, the security attribute-based relationship that must hold between subject and information security attributes] 53 [assignment: additional information flow control SFP rules] 54 [assignment: rules, based on security attributes, that explicitly authorise information flow] Security Target secunet konnektor 2.1.0 Seite 172 von 424 secunet (5) The TSF prevents communication of service modules with NET_TI_ZENTRAL, NET_TI_DEZENTRAL, ANLW_AK- TIVE_BESTANDSNETZE and internet via SIS or IAG. (6) The TSF prevents communication initiated by entities with IP address within NET_TI_GESICHERTE_FD, NET_TI_OF- FENE_FD, NET_TI_ZENTRAL, NET_TI_DEZENTRAL (except the connector itself), ANLW_BESTANDSNETZE and NET_SIS. (7) The TSF prevents communication of entities with IP addresses in the inner header within NET_TI_ZENTRAL, NET_TI_GESICHERTE_FD, NET_TI_DEZENTRAL, ANLW_AKTIVE_BESTANDSNETZE, ANLW_LAN_AD- DRESS_SEGMENT, ANLW_LEKTR_INTRANET_ROUTES and ANLW_WAN_NETWORK_SEGMENT coming through the VPN tunnel with VPN concentrator of the SIS. (8) The TSF prevents receive of packets from entities in LAN if packet destination is internet and (MGM_LU_ONLINE=Enabled and MGM_LOGICAL_SE- PARATION=Disabled and ANLW_INTERNET_MODUS = KEINER). (9)The TSF prevents inbound packets of the VPN channels from SIS with destination address in the inner header outside a)ANLW_LAN_IP_ADDRESS or b)ANLW_LEKTR_INTRANET_ROUTES if ANLW_WAN_ADAPTER_MODUS=DISABLED or c)ANLW_WAN_IP_ADDRESS if ANLW_WAN_ADAPTER_MODUS=ACTIVE (10)The TSF prevents communication of IAG to connector through LAN interface if (ANLW_WAN_ADAPTER_MODUS= ACTIVE). (11)The TSF prevents communication of IAG to connector through WAN interface of the connector if (ANLW_WAN_ADAPTER_MODUS= DISABLED). (12)[no additional rules] 55 . Refinement: Alle nicht durch den Paketfilter explizit erlaubten Informationsflüsse müssen verboten sein (default-deny). Erläuterung: Der von O.NK.PF_WAN und O.NK.PF_LAN geforderte dynamische Paketfilter wird durch FDP_IFC.1/NK.PF und FDP_IFF.1/NK.PF gefordert. Der Mechanismus „Logische Trennung“ nach [gemSpec_Kon], TIP1-A_4823 wird vom EVG nicht umgesetzt. Das Attribut 55 [assignment: additional rules, based on security attributes, that explicitly deny information flows] Security Target secunet konnektor 2.1.0 secunet Seite 173 von 424 MGM_LOGICAL_SEPARATION kann daher nicht auf ENABLED gesetzt werden. Die Regel FDP_IFF.1.2/NK.PF Regel 4 c) wird auch benutzt um die Operation SendData zum Registrierungsserver zu senden (A_21159). Anwendungshinweis 81:Durch die Festlegung verbindlicher, nicht administrierbarer Paketfilter-Regeln (vgl. auch das Refinement zu FMT_MSA.1/NK.PF) und bei Wahl eines geeigneten Satzes von Paketfilter-Regeln (siehe dazu das Refinement zu AGD_OPE.1 in Abschnitt 6.2.8) erzwingt FDP_IFF.1.2/NK.PF die VPN- Nutzung für zu schützende Daten der TI und der Bestandsnetze und zu schützende Nutzerdaten wie in Abschnitt 3.1 definiert. Anwendungshinweis 82: Der EVG verwaltet Informationen über eine Historie der Verbindung durch die firewall des Betriebsystemkernels (iptables). Es werden eingehende Verbindungen nur als Antworten auf zuvor ausgegangene Anfragen zugelassen, so dass ein ungefragter Verbindungsaufbau aus dem WAN wirkungsvoll verhindert wird. Siehe auch stateful packet inspection im Glossar. Anwendungshinweis 83:Die dynamische Paketfilterung soll die Menge der zulässigen Protokolle im Rahmen der Kommunikation mit der Telematikinfrastruktur geeignet beschränken. Es sind nur die in der Spezifikation Netzwerk [gemSpec_Net] [29], Tabelle 1 aufgeführten Protokolle zulässig. Der EVG beschränkt den freien Zugang zum als unsicher angesehenen Transportnetz (WAN) geeignet zum Schutz der Clientsysteme. EVG erzwingt, dass zu schützende Daten der TI und der Bestandsnetze und zu schützende Nutzerdaten über den VPN-Tunnel in die Telematikinfrastruktur bzw. zum Internet versendet werden; EVG verhindert ungeschützten Zugriff auf das Transportnetz. Darüber hinaus wurden keine weiteren regeln (mittels FDP_IFF.1.3/NK.PF bis FDP_IFF.1.5/NK.PF) ergänzt. Die von FDP_IFF.1.2/NK.PF geforderten Filterregeln (packet filtering rules) sind mit geeigneten Default-Werten vorbelegt (siehe unten, FMT_MSA.3/NK.PF) und können vom Administrator verwaltet werden (siehe FMT_MSA.1/NK.PF, vgl. Abschnitt 6.2.6 Administration). FMT_MSA.3/NK.PF Static attribute initialisation Restriktive Paketfilter-Regeln Dependencies: FMT_MSA.1 Management of security attributes hier erfüllt durch: FMT_MSA.1/NK.PF FMT_SMR.1 Security roles hier erfüllt durch: FMT_SMR.1./NK Security Target secunet konnektor 2.1.0 Seite 174 von 424 secunet FMT_MSA.3.1/NK.PF The TSF shall enforce the PF SFP56 to provide restrictive57 default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2/NK.PF The TSF shall allow the [role administrator]58 to specify alternative initial values to override the default values when an object or information is created. Refinement: Bei den Sicherheitsattributen handelt es sich um die Filterregeln für den dynamischen Paketfilter (FDP_IFF.1.2/NK.PF). Restriktive bedeutet, dass Verbindungen, die nicht ausdrücklich erlaubt sind, automatisch verboten sind. Außerdem muss der EVG bei Auslieferung mit einem Regelsatz ausgeliefert werden, der bereits einen grundlegenden Schutz bietet. Anwendungshinweis 84:Es gibt nur eine Administrator Rolle welche alternative Default-Werte spezifizieren darf. Dabei wird nicht zwischen lokalem und entfernten Management unterschieden. Erläuterung: FMT_MSA.3/NK.PF erfüllt die Abhängigkeit von FDP_IFF.1/NK.PF, weil es die Festlegung von Voreinstellungen für die Paketfilter-Regeln fordert und klärt, welche Rollen die Voreinstellungen ändern können. Die hier noch nicht erfüllten Abhängigkeiten (FMT_MSA.1/NK.PF und FMT_SMR.1./NK) werden in Abschnitt 6.2.6 Administration diskutiert. 6.2.3. Netzdienste Zeitsynchronisation FPT_STM.1/NK Reliable time stamps Der EVG stellt verlässliche Zeitstempel bereit, indem er die Echtzeituhr gemäß OE.NK.Echtzeituhr regelmäßig synchronisiert. Dependencies: No dependencies. FPT_STM.1.1/NK The TSF shall be able to provide reliable time stamps. Refinement: Die Zuverlässigkeit (reliable) des Zeitstempels wird durch Zeitsynchronisation der Echtzeituhr (gemäß OE.NK.Echtzeituhr) mit Zeitservern (vgl. OE.NK.Zeitsynchro) unter Verwendung des Protokolls NTP v4 [51] erreicht. Der EVG verwendet den verlässlichen Zeitstempel für sich selbst und bietet anderen Konnektorteilen eine Schnittstelle zur Nutzung des verlässlichen Zeitstempels an. 56 [assignment: access control SFP, information flow control SFP] 57 [selection, choose one of: restrictive, permissive, [assignment: other property]] 58 [assignment: the authorised identified roles] Security Target secunet konnektor 2.1.0 secunet Seite 175 von 424 Befindet sich der EVG im Online-Modus, muss er die Zeitsynchronisation mindestens bei Start-up, einmal innerhalb von 24 Stunden und auf Anforderung durch den Administrator durchführen. Die verteilte Zeitinformation weicht [nicht mehr als 330ms]59 von der Zeitinformation der darüberliegenden Stratum Ebene ab. Anwendungshinweis 85: Zum Zeitdienst siehe Konnektor-Spezifikation [27], Abschnitt 4.2.5 Zeitdienst. Anwendungshinweis 86: Die im Refinement geforderte Zeitsynchronisation entspricht den Anforderungen der aktuellen Version der Konnektor-Spezifikation [27]. Es wurde keine verschärfung des Refinement aus dem NK-PP [17] vorgenommen. Anwendungshinweis 87: Gemäß Konnektor-Spezifikation [27], Abschnitt 3.3 Betriebszustand, erfolgen Hinweise an den Administrator über kritische Betriebszustände des Konnektors. Darüber hinaus fordert [27] - Im Betrieb MUSS der Zustand des Konnektors erkennbar sein. Zur Anzeige des Betriebszustandes des Konnektors SOLL es eine Signaleinrichtung am Konnektor geben. [TIP1-A_4843]. Der EVG unterstützt eine Signaleinrichtung in Form von Status-LEDs, welche den Betriebszustand an der Außenhaut des Konnektors anzeigt, um die benannte Anforderung der Spezifikation umzusetzen, siehe LS14 und PS5 in Kapitel 1.3.3 sowie die Anforderungen an die Konnektor Hardware in Kapitel 1.3.6. Zertifikatsprüfung FPT_TDC.1/NK.Zert Inter-TSF basic TSF data consistency Prüfung der Gültigkeit von Zertifikaten Dependencies: No dependencies. FPT_TDC.1.1/NK.Zert The TSF shall provide the capability to consistently interpret information – distributed in the form of a TSL (Trust- Service Status List) and CRL (Certificate Revocation List) information – about the validity of certificates and about the domain (Telematikinfrastruktur) to which the VPN concentrator with a given certificate connects60 when shared between the TSF and another trusted IT product. FPT_TDC.1.2/NK.Zert The TSF shall use interpretation rules61 when interpreting the TSF data from another trusted IT product. 59 [selection: nicht mehr als 330ms, [assignement: andere Zeit]] 60 [assignment: list of TSF data types] 61 [assignment: list of interpretation rules to be applied by the TSF] (die Regeln werden teilweise im Refinement angeführt) Security Target secunet konnektor 2.1.0 Seite 176 von 424 secunet Refinement: Der EVG muss prüfen, dass (i) das Zertifikat des Ausstellers (der CA) des VPN-Konzentrator-Zertifikats in der TSL enthalten ist, dass (ii) das Gerätezertifikat nicht in der zugehörigen CRL enthalten ist, dass (iii) sowohl TSL als auch CRL integer sind, d.h., nicht verändert wurden (durch Prüfung der Signatur dieser Listen) und dass (iv) sowohl TSL als auch CRL aktuell sind. Anwendungshinweis 88: Die interpretation rules in FPT_TDC.1.2/NK.Zert entsprechen den Anforderumgen der aktuellen Version der Konnektor-Spezifikation [27]. Der EVG führt keine explizite Prüfung der Algorithmen auf deren Gültigkeit gegenüber den Vorgaben in TR-03116-1[19] durch. Die Verwendung von gültigen Algorithmen wird durch das Aufbringen eines korrekten und evaluierten Softwarestandes des EVG unter Nutzung des sicheren Updatemechanismus sichergestellt. Anwendungshinweis 89: Die TSL und die CRL muss gemäß Anforderung A_4684 in der Konnektor- Spezifikation [27] im Online-Modus mindestens einmal täglich auf Aktualität überprüft werden. Der Konnektor kann die TSL bei Bedarf manuell importieren (siehe Anforderung TIP1- A_4705 und TIP1-A_4706 in [27]). Die Liste der entsprechenden Zertifikate aus der TSL wird im Netzkonektor hinterlegt. 6.2.4. Stateful Packet Inspection Anwendungshinweis 90: Weitergehende Angriffe gegen die Systemintegrität des EVG werden abgewehrt (robuste Implementierung, Resistenz gegen Angriffe wie von AVA_VAN.5 gefordert), aber nicht im Detail erkannt, es gibt keine komplexe Erkennungslogik für Angriffe. Der Aspekt der Stateful Packet Inspection wird durch FDP_IFF.1.4/NK.PF modelliert. 6.2.5. Selbstschutz FDP_RIP.1/NK Subset residual information protection Speicheraufbereitung (Löschen nicht mehr benötigter Schlüssel direkt nach ihrer Verwendung durch aktives Überschreiben); keine dauerhafte Speicherung medizinischer Daten. Dependencies: No dependencies. FDP_RIP.1.1/NK The TSF shall ensure that any previous information content of a resource is made unavailable upon the deallocation of the resource from62 the following objects: cryptographic keys (and session keys) used for the VPN or for TLS-connections, user data (zu schützende 62 [selection: allocation of the resource to, deallocation of the resource from] Security Target secunet konnektor 2.1.0 secunet Seite 177 von 424 Daten der TI und der Bestandsnetze and zu schützende Nutzerdaten), [none]63 . Refinement: Die sensitiven Daten müssen mit konstanten oder zufälligen Werten überschrieben werden, sobald sie nicht mehr verwendet werden. In jedem Fall müssen die sensitiven Daten vor dem Herunterfahren bzw. Reset überschrieben werden. Anwendungshinweis 91: Der EVG speichert zu schützende Daten der TI und der Bestandsnetze oder zu schützende Nutzerdaten niemals dauerhaft; er speichert sie lediglich temporär zur Verarbeitung (z. B. während einer Ver- oder Entschlüsselung). Selbsttests FPT_TST.1/NK TSF testing Selbsttests Dependencies: No dependencies. FPT_TST.1.1/NK The TSF shall run a suite of self tests [during initial start-up]64 to demonstrate the correct operation of [the TSF]65 . FPT_TST.1.2/NK The TSF shall provide authorised users with the capability to verify the integrity of TSF data66 . FPT_TST.1.3/NK The TSF shall provide authorised users with the capability to verify the integrity of [TSF]67 . Refinement: Zur Erfüllung der Anforderungen aus FPT_TST.1/NK implementiert der EVG die Mechanismen, welche dem aktuellen Stand der Technik bei Einzelplatz-Signaturanwendungen entsprechen. Dazu gehören insbesondere:  die Prüfung kryptographischer Verfahren bei Programmstart,  eine Prüfung der korrekten Funktionalität und Qualität des RNG, sofern der EVG einen physikalischen Zufallszahlen- generator beinhaltet und diesen anstelle des Umgebungsziels OE.NK.RNG nutzt. Anwendungshinweis 92: Die kryptographischen Verfahren werden in Software implementiert. Der Benutzer kann die Selftests durch Neustart des EVGs selbst anstoßen. Die im Refinement geforderten Mechanismen werden wie folgt umgesetzt: 63 [assignment: list of objects] 64 [selection: during initial start-up, periodically during normal operation, at the request of the authorised user, at the conditions [assignment: conditions under which self test should occur]] 65 [selection: [assignment: parts of TSF], the TSF] 66 [selection: [assignment: parts of TSF data], TSF data] 67 [selection: [assignment: parts of TSF], TSF] Security Target secunet konnektor 2.1.0 Seite 178 von 424 secunet - Eine Prüfung der Integrität der installierten ausführbaren Dateien und sonstigen sicherheitsrelevanten Dateien (Konfigurationsdateien, TSF-Daten) mit kryptographischen Verfahren beim Programmstart. - Der EVG nutzt den physikalischen Zufallszahlengenerator der gSMC-K als Seed Quelle für den Zufallszahlengenerator des Betriebsystems (OE.NK.RNG). Schutz von Geheimnissen, Seitenkanalresistenz FPT_EMS.1/NK Emanation of TSF and User data Dependencies: No dependencies. FPT_EMS.1.1/NK The TOE shall not emit sensitive data (as listed below) – or information which can be used to recover such sensitive data – through network interfaces (LAN or WAN)68 in excess of limits that ensure that no leakage of this sensitive data occurs69 enabling access to - session keys derived in course of the Diffie-Hellman-Keyexchange- Protocol, - [none]70 , - [none]71 , - [none] 72 , - [none] 73 , - [none]74 and - data to be protected (“zu schützende Daten der TI und der Bestandsnetze”) - [none]75 . FPT_EMS.1.2/NK The TSF shall ensure attackers on the transport network (WAN) or on the local network (LAN)76 are unable to use the following interface WAN interface or LAN interface of the connector77 to gain 68 [assignment: types of emissions] 69 [assignment: specified limits] 70 [selection: none, key material used to verify the TOE’s integrity during self tests] 71 [selection: none, key material used to verify the integrity and authenticity of software updates] 72 [selection: none, key material used to decrypt encrypted software updates (if applicable)] 73 [selection, choose one of: minimum, basic, detailed, not specified] 74 [assignment: list of types of TSF data] Hinweis: Die Auswahlen (selection) wurde vom PP-Autor im Rahmen des assignments hinzugefügt; diese Auswahlen sollen optional sein.. 75 [assignment: list of types of user data (may be empty)] 76 [assignment: type of users] 77 [assignment: type of connection] Security Target secunet konnektor 2.1.0 secunet Seite 179 von 424 access to the sensitive data (TSF data and user data) listed above78 . Anwendungshinweis 93: Es wurden keine weiteren Verfeinerungen vorgenommen. Zur Integritätsprüfung beim Selbsttest und beim Software-Update werden öffentliche Schlüssel verwendet. Die Software Images werden unverschlüsselt übertragen. Die Authentisierung des Administrators wird vom Netzkonnektor durchgeführt. Für die entsprechenden Auswahl Operationen des NK-PPs [17] wurde daher „none“ gewählt. Sicherheits-Log FAU_GEN.1/NK.SecLog Audit data generation Dependencies: FPT_STM.1 Reliable time stamps hier erfüllt durch: FPT_STM.1/NK FAU_GEN.1.1/NK.SecLog The TSF shall be able to generate an audit record of the following auditable events: b) All auditable events for the [not specified]79 level of audit; and c) - start-up, shut down and reset (if applicable) of the TOE - VPN connection to TI successfully / not successfully established, - VPN connection to SIS successfully / not successfully established, - TOE cannot reach services of the transport network, - IP addresses of the TOE are undefined or wrong, - TOE could not perform system time synchronisation within the last 30 days, - during a time synchronisation, the deviation between the local system time and the time received from the time server exceeds the allowed maximum deviation (see refinement to FPT_STM.1/NK); - changes of the TOE configuration.80 - Fehlerzustände according to [27], table 3.81 Refinement: Der in CC angegebene auditable event a) Start-up and shutdown of the audit functions ist nicht relevant, da die Generierung von Sicherheits-Log-Daten nicht ein- oder ausgeschaltet werden kann. 78 refinement (Umformulierung) sowie Zuweisung der beiden assignments: [assignment: list of types of TSF data] and [assignment: list of types of user data] 79 [selection: none, key material used to verify the TOE’s integrity during self tests] 80 [assignment: other specifically defined auditable events] 81 Refinement: Addition of “Fehlerzustände according to [27], table 3“ to the list of auditable events Security Target secunet konnektor 2.1.0 Seite 180 von 424 secunet FAU_GEN.1.2/NK.SecLog The TSF shall record within each audit record at least the following information: a) Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event; and b) For each audit event type, based on the auditable event definitions of the functional components included in the ST, [no other audit relevant information]. Refinement: Das Sicherheits-Log muss in einem nicht-flüchtigen Speicher abgelegt werden, so dass es auch nach einem Neustart zur Verfügung steht. Der für das Sicherheits-Log reservierte Speicher muss hinreichend groß dimensioniert sein. Der Speicher ist dann hinreichend groß dimensioniert, wenn sichergestellt ist, dass ein Angreifer durch das Provozieren von Einträgen im Sicherheits-Log die im Rahmen einer Log-Auswertung noch interessanten Log- Daten nicht unbemerkt aus dem Speicher verdrängen kann. Anwendungshinweis 94: Es werden alle Fehlerzustände die in der Konnektor-Spezifikation [27], Abschnitt 3.3, Tabelle 3 aufgeführt sind protokolliert. Die Konnektor-Spezifikation fordert die Initialisierung des Protokollierungsdienstes und weiterer Dienste in der Boot-Phase und die Meldung des Abschlusses der Boot-Phase durch den Event "BOOTUP/ BOOTUP_COMPLETE". Der Protokollierungsdienst wird als erster Dienst gestartet wird, dieser Zeitpunkt wird als Zeitpunkt für das Ereignis „start-up“ in FAU_GEN.1.1/NK.SecLog, Punkt c) verwendet. Der Protokollierungsdienst als letzter Dienst bei einem Shut-down des EVG beendet wird, dieser Zeitpunkt wird als Zeitpunkt für das Ereignis „shut down“ in FAU_GEN.1.1/NK.SecLog, Punkt c) verwendet. Anwendungshinweis 95: Die benötigte Größe des für das Security Log zu reservierenden Speicherbereichs ist abhängig von der Größe der einzelnen Log-Einträge, von der verwendeten Kodierung und weiteren Produkteigenschaften. Die Hardware des Konnektors muss mindestens 16 GByte Speicher besitzen damit nebem den Software Anteilen von NK und AK ausreichend speicher für Protokolldaten zur Verfügung steht, siehe 1.3.6. FAU_GEN.2/NK.SecLog User identity association Dependencies: FAU_GEN.1 Audit data generation hier erfüllt durch: FAU_GEN.1/NK.SecLog FIA_UID.1 Timing of identification hier erfüllt durch: FIA_UID.1/NK.SMR FAU_GEN.2.1/NK.SecLog For audit events resulting from actions of identified users, the TSF shall be able to associate each auditable event with the identity of the user that caused the event. Anwendungshinweis 96: Der EVG nimmt bei Konfigurationsänderungen durch einen authentisierten Administrator die Identität (Identifikator) des ändernden Administrators in das Sicherheits- Log auf. Es werden keine unterschiedlichen Administrator-Rollen unterstützt. Security Target secunet konnektor 2.1.0 secunet Seite 181 von 424 6.2.6. Administration Administrator-Rollen, Management-Funktionen, Authentisierung der Administratoren, gesicherte Wartung FMT_SMR.1./NK Security roles Dependencies: FIA_UID.1 Timing of identification hier erfüllt durch: FIA_UID.1/NK.SMR FMT_SMR.1.1/NK The TSF shall maintain the roles  Administrator,  SIS,  TI  Anwendungskonnektor82 . FMT_SMR.1.2/NK The TSF shall be able to associate users with roles. Refinement: Die TSF erkennen die in FMT_SMR.1.1 definierte Rolle Administrator daran, dass das Sicherheitsattribut „Autorisierungsstatus“ des Benutzers „Administrator“ den Wert „autorisiert“ besitzt. Anwendungshinweis 97: Der EVG unterstützt die Rolle Administrator. Als Sicherheitsattribut „Autorisierungsstatus“ des Benutzers „Administrator“ wird das Identifikator-Attribut verwendet. Die Autorisierung wird vom Netzkonnektor duchgeführt. Bei erfolgreicher Autorisierung des Administrator wird das Attribut im EVG gesetzt. Anwendungshinweis 98: In einem Gesamtkonnektor kann der Administrator des Netzkonnektors auch als NK-Administrator bezeichnet werden. – Externe vertrauenswürdige IT-Systeme wie Kartenterminals sind keine Rollen, also ohne Einfluss auf FMT_SMR.1./NK. Lediglich der Anwendungskonnektor wurde hier formal als Rolle definiert, da er das Sicherheitsverhalten von Funktionen des EVG steuern kann, siehe FMT_MOF.1/NK.TLS. Die Rollen SIS und TI werden nur im Zusammenhang mit den Paketfilterregeln für die Kommunkation mit deren VPN-Konzentratoren verwendet. FMT_MTD.1/NK Management of TSF data Dependencies: FMT_SMR.1 Security roles hier erfüllt durch: FMT_SMR.1./NK FMT_SMF.1 Specification of Management Functions hier erfüllt durch: FMT_SMF.1/NK 82 [assignment: the authorised identified roles] Security Target secunet konnektor 2.1.0 Seite 182 von 424 secunet FMT_MTD.1.1/NK The TSF shall restrict the ability to [change_default, query, modify, [activate/deactivate VPN]]]83 the real time clock, packet filtering rules [none]84 to the role Administrator85 . Refinement: Die real time clock bezieht sich auf die von OE.NK.Echtzeituhr geforderte Echtzeituhr. Obwohl die Echtzeituhr in der Umgebung liegt, wird ihre Zeit vom EVG genutzt und der EVG beschränkt den Zugriff (modify = Einstellen der Uhrzeit) auf diese Echtzeituhr. Die packet filtering rules legen das Verhalten des Paketfilters (O.NK.PF_LAN, O.NK.PF_WAN) fest. Anwendungshinweis 99: Nur Administratoren dürfen administrieren: Die aufgelisteten administrativen Tätigkeiten können nur von Administratoren ausgeführt werden. Anwendungshinweis 100: Nur der Administrator darf ein Deaktivieren der VPN-Verbindung vornehmen. Die Managementfunktion „Aktivieren und Deaktivieren des VPN-Tunnels“ wurde in die Liste bei FMT_SMF.1/NK aufgenommen und innerhalb von FMT_MTD.1/NK wurde der Zugriff auf diese Managementfunktion auf den Administrator beschränkt. FIA_UID.1/NK.SMR Timing of identification Identification of Security Management Roles Dependencies: No dependencies. FIA_UID.1.1/NK.SMR The TSF shall allow the following TSF-mediated actions:  all actions except for administrative actions (as specified by FMT_SMF.1/NK, see below)86 on behalf of the user to be performed before the user is identified. FIA_UID.1.2/NK.SMR The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. Anwendungshinweis 101: Die Zuweisung all actions except for administrative actions (as specified by FMT_SMF.1/NK) aus dem NK-PP [17] wurde unverändert übernommen. FIA_UAU.1/NK.SMRTiming of authentication Authentication of Security Management Roles Dependencies: FIA_UID.1 Timing of identification 83 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 84 [assignment: list of TSF data] 85 [assignment: the authorised identified roles] 86 [assignment: list of TSF-mediated actions] Security Target secunet konnektor 2.1.0 secunet Seite 183 von 424 Hier erfüllt durch: FIA_UID.1/NK.SMR FIA_UAU.1.1/NK.SMR The TSF shall allow the following TSF-mediated actions:  all actions except for administrative actions (as specified by FMT_SMF.1/NK, see below)87 on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2/NK.SMR The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. FTP_TRP.1/NK.Admin Trusted path Trusted Path für den Administrator. Dependencies: No dependencies. FTP_TRP.1.1/NK.Admin The TSF shall provide a communication path between itself and [remote, local]88 users that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data from [modification, disclosure]89 . FTP_TRP.1.2/NK.Admin The TSF shall permit [the TSF, local users, remote users]90 to initiate communication via the trusted path. FTP_TRP.1.3/NK.Admin The TSF shall require the use of the trusted path for initial user authentication and administrative actions.91 Anwendungshinweis 102: Die Wartung erfolgt immer über die LAN-Schnittstelle (PS2). Lokale und entfernte Administration erfolgt dabei über getrennte Ports an der LAN-Schnittstelle. Der Remote Adminsitrator muss dazu Zugang zum lokalen Netz haben. Siehe dazu die entsprechende Beschreibung im Benutzerhandbuch [110]. Aus Sicht des EVG erfolgt der Zugand für remote user und local users Analog über eine TLS-gesicherte Verbindung gemäß FTP_ITC.1/NK.TLS und nach erfolgreicher Eingabe von Username und Passwort. FMT_SMF.1/NK Specification of Management Functions Dependencies: No dependencies. FMT_SMF.1.1/NK The TSF shall be capable of performing the following security management functions: 87 [assignment: list of TSF-mediated actions] 88 [selection: remote, local] 89 [selection: modification, disclosure, [assignment: other types of integrity or confidentiality violation]] 90 [selection: the TSF, local users, remote users] 91 [selection: initial user authentication, [assignment: other services for which trusted path is required]] Security Target secunet konnektor 2.1.0 Seite 184 von 424 secunet  Management of dynamic packet filtering rules (as required for FDP_IFC.1/NK.PF, FDP_IFF.1/NK.PF, FMT_MSA.3/NK.PF, and FMT_MSA.1/NK.PF). (Verwalten der Filterregeln für den dynamischen Paketfilter.)  Management of TLS-Connections (as required for FMT_MOF.1/NK.TLS). (Verwalten der TLS-Verbindungen durch den Anwendungskonnektor.)92  Aktivieren und Deaktivieren des VPN-Tunnels93 Anwendungshinweis 103: Das Review (Lesen und Auswerten) der von FAU_GEN.1/NK.SecLog erzeugten Audit-Daten wird nicht als Managementfunktion modelliert. FMT_MSA.1/NK.PF Management of security attributes Nur der Administrator darf (gewisse) Filterregeln verändern. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] hier erfüllt durch: FDP_IFC.1/NK.PF FMT_SMR.1 Security roles hier erfüllt durch: FMT_SMR.1./NK FMT_SMF.1 Specification of Management Functions hier erfüllt durch: FMT_SMF.1/NK FMT_MSA.1.1/NK.PF The TSF shall enforce the PF SFP94 to restrict the ability to [query, modify, [change_default]]95 the security attributes packet filtering rules96 to the roles „Administrator“, [no other authorised identified roles]97 . Refinement: Der Administrator darf nur solche Filterregeln (packet filtering rules) administrieren, welche die Kommunikation zwischen dem Konnektor und Systemen im LAN betreffen. Firewall-Regeln, welche – die Kommunikation zwischen dem Konnektor einerseits und dem Transportnetz, der Telematikinfrastruktur, sowohl 92 [assignment: list of management functions to be provided by the TSF] 93 refinement: Aktivieren und Deaktivieren des VPN-Tunnels 94 [assignment: access control SFP, information flow control SFP] 95 [selection: change_default, query, modify, delete, [assignment: other operations]] 96 [assignment: list of security attributes] 97 [assignment: the authorised identified roles] Security Target secunet konnektor 2.1.0 secunet Seite 185 von 424 gesicherte als auch offene Fachdienste und zentrale Dienste, bzw. den Bestandsnetzen andererseits oder – die Kommunikation zwischen dem LAN einerseits und dem Transportnetz, der Telematikinfrastruktur sowohl gesicherte als auch offene Fachdienste und zentrale Dienste, bzw. den Bestandsnetzen (außer Freischalten aktiver Bestandsnetze) andererseits betreffen, dürfen nicht über die Administrator-Schnittstelle verändert werden können. Der Administrator muss den gesamten WAN-seitigen Verkehr blockieren können (siehe Konnektorspezifikation [27], Kapitel 4.2.1.1, Parameter MGM_LU_ONLINE). Der Administrator darf zusätzlich einschränkende Regeln für die Kommunikation mit dem SIS festlegen (siehe Konnektorspezifikation [27], Kapitel 4.2.1.2, ANLW_FW_SIS_ADMIN_RULES) festlegen. Vorgabewerte dürfen nicht verändert werden („change-default“ ist nicht erlaubt). Erläuterung: FMT_MSA.1/NK.PF sorgt als von FMT_MSA.3/NK.PF abhängige Komponente dafür, dass die Regeln für den Paketfilter (packet filtering rules, diese Regeln werden als security attributes angesehen) nur durch den Administrator oder eine andere kompetente Instanz (siehe FMT_SMR.1./NK) verändert werden können. Weiterhin legt die Konnektorspezifikation [27] fest, dynamisches Routing zu deaktivieren. Dies ist Gegenstand der Schwachstelleanalyse. Das Refinement minimiert das Risiko, dass durch menschliches Versagen oder Fehlkonfiguration versehentlich ein unsicherer Satz von Filterregeln aktiviert wird. Es sorgt dafür, dass grundlegende Regeln, welche die Kommunikation zwischen dem Konnektor und dem Transportnetz bzw. der Telematikinfrastruktur oder auch die Kommunikation zwischen dem LAN und dem Transportnetz bzw. der Telematikinfrastruktur betreffen, nicht durch einen administrativen Eingriff (Konfiguration) des Administrators außer Kraft gesetzt werden können. Anwendungshinweis 104: Zu den verschiedenen laut Konnektor-Spezifikation zulässigen Optionen der Administration von Firewall-Regeln gelten die in Kapitel 4.2.1 [27] definierten Anforderungen. Anwendungshinweis 105: Der Administrator kann einzelne Filter-Regeln direkt über die Managment- Schnittstelle administrieren. Ebenso ist es möglich Filterregeln als signierte Regelsätze (XML Pakete) über die Managment-Schnittstelle zu übertragen. Die Signaturprüfung findet im EVG statt. Anwendungshinweis 106: Der Netzkonnektor kann seine Filterregeln abhängig von Ereignissen des Anwendungskonnektors dynamisch anpassen. So gelten standartmäßig sehr restriktive Filteregeln, die zum Beispiel erst beim Aufbau eines VPN Kanals erweitert werden. Einstellungen der Filterregeln durch den Administrator werden dabei niemals überschrieben. Security Target secunet konnektor 2.1.0 Seite 186 von 424 secunet FMT_MSA.4/NK aus PP [17] ist für den EVG nicht relevant, da der EVG die Authentisierung des Administrators selbst durchführt, siehe O.NK.Admin_Auth und Anwendungshinweis 63:. Mit FIA_UAU.1/NK.SMR wurde eine die Authentisierung des Administrators modellierende Anforderung in das ST aufgenommen. Anwendungshinweis 107: Nicht relevant Software Update Der EVG unterstützt das Software Update. Die fogenden SFRs wurden aus dem Protection Profile BSI-CC-PP-0098 [16] des Gesamtkonnektors abgeleitet. FDP_ACC.1/NK.Update Subset access control / Update Dependencies: FDP_ACF.1 Security attribute based access control hier erfüllt durch: FDP_ACF.1/NK.Update FDP_ACC.1.1/NK.Update The TSF shall enforce the [Update-SFP]98 on [  subjects: (1) Administrator (S_Administrator) (2) Anwendungskonnektor (S_AK) (3) Netzkonnektor (S_NK)  objects: (1) Update-Pakete  operations: (1) Importieren (2) Verwenden ]99 Operation Beschreibung Anmerkung Importieren Einlesen von bereitgestellten Update-Paketen und Aktualisieren der Komponenten des EVG. Der Download kann automatisch erfolgen. 98 [assignment: access control SFP] 99 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] Security Target secunet konnektor 2.1.0 secunet Seite 187 von 424 Verwenden Die Update-Pakete werden zum Update der TSF-Daten, zum Update des EVG zu einem neuen EVG oder zum Update anderer externer Komponenten (eHealth-Kartenterminal) verwendet. Das Installieren (Verwenden) des Updates kann automatisch erfolgen. FDP_ACF.1/NK.Update Security attribute based access control / Update Dependencies: FDP_ACC.1 Subset access control hier erfüllt durch: FDP_ACC.1/NK.Update FMT_MSA.3 Static attribute initialisation nicht erfüllt mit folgender Begründung: Für das Datenobjekt Update- Paket findet keine Initialisierung von Sicherheitsattributen im Sinne von FMT_MSA.3 statt: Signatur und Software Version können nicht sinnvoll vom EVG mit Default Werten initialisiert werden. FDP_ACF.1.1/NK.Update The TSF shall enforce the [Update-SFP]100 to objects based on the following: [  subjects: (1) S_Administrator (2) S_AK (3) S_NK  objects: (2) Update-Pakete with security attributes: a. Signatur b. Zulässige Software Version ]101 FDP_ACF.1.2/NK.Update The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [ 100 [assignment: access control SFP] 101 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes] Security Target secunet konnektor 2.1.0 Seite 188 von 424 secunet (1) Der Administrator darf nur Update-Pakete installieren, deren Signatur erfolgreich geprüft wurde. (2) Die Subjekte S_Administrator, S_AK und S_NK dürfen nur Update-Pakete verwenden, die einer Firmwaregruppe angehören, die gleich oder höher der gegenwärtig installierten Firmwaregruppe ist, siehe Übergreifende Spezifikation: Operations und Maintenance [gemSpec_OM]102. ]103 FDP_ACF.1.3/NK.Update The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [no additional rules]104 . FDP_ACF.1.4/NK.Update The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [ (1) Wenn MGM_LU_ONLINE=Disabled gesetzt ist, so darf die TSF keine Kommunikation mit dem Update-Server (KSR) herstellen. ]105 FDP_ITC.1/NK.Update Import of user data without security attributes / Update Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] hier erfüllt durch: FDP_ACC.1/NK.Update FMT_MSA.3 nicht erfüllt mit folgender Begründung: Für das Datenobjekt Update- Paket findet keine Initialisierung von Sicherheitsattributen im Sinne von FMT_MSA.3 statt: Signatur und Software Version können nicht sinnvoll vom EVG mit Default Werten initialisiert werden. FDP_ITC.1.1/NK.Update The TSF shall enforce the Update-SFP106 when importing user data, controlled under the SFP, from outside of the TOE. FDP_ITC.1.2/NK.Update The TSF shall ignore any security attributes associated with the user data when imported from outside the TOE. 102 Refinement: , siehe Übergreifende Spezifikation: Operations und Maintenance [gemSpec_OM] 103 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects] 104 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] 105 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] 106 [assignment: access control SFP(s) and/or information flow control SFP(s)] Security Target secunet konnektor 2.1.0 secunet Seite 189 von 424 FDP_ITC.1.3/NK.Update The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TOE: [Die TSF muss die Integrität und Authentizität der importierten Update-Dateien überprüfen.]107 FDP_UIT.1/NK.Update Data exchange integrity / Update Dependencies: FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] hier erfüllt durch: FDP_ACC.1/NK.Update [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] hier erfüllt durch: FDP_ITC.1/NK.Update FDP_UIT.1.1/NK.Update The TSF shall enforce the [Update-SFP]108 to [receive]109 user data in a manner110 protected from [modification, deletion, insertion]111 FDP_UIT.1.2/NK.Update The TSF shall be able to determine on receipt of user data, whether [modification, deletion, insertion]112 has occurred. 107 [assignment: additional importation control rules] 108 [assignment: access control SFP(s) and/or information flow control SFP(s)] 109 [selection: transmit, receive] 110 refinement 111 [selection: modification, deletion, insertion, replay] 112 [selection: modification, deletion, insertion, replay] Security Target secunet konnektor 2.1.0 Seite 190 von 424 secunet 6.2.7. Kryptographische Basisdienste Anwendungshinweis 108: Die SFR der Familie FCS in CC Teil 2 [5] enthalten ein [assignment: cryptographic algorithm]. Diese Zuweisungen wurden in den SFR im PP [16] in Übereinstimmung mit den gematik-Spezifikationen und Technischen Richtlinien des BSI bereits vorgenommen. Die TSF muss die darüberhinausgehenden verpflichtenden Vorgaben der angegebenen Standards soweit sie die angegebenen Algorithmen und Protokollen betreffen implementieren und darf den angegebenen Standards mit Ausnahme der zugewiesenen Kryptoalgorithmen nicht widersprechen. So fordert RFC 3602 die Unterstützung von AES 128 Bit, die Zuweisung des SFR FCS_COP.1/NK.ESP aber in Übereinstimmung mit der Spezifikation kryptographischer Algorithmen in der Telematikinfrastruktur [30] an seiner Stelle verbindlich den stärkeren AES 256 Bit. Die Zuweisung erfordert nicht, dass die TSF alle in den angegeben Standards zulässigen Optionen für die spezifizierten kryptographischen Operationen und Schlüsselmanagement- funktionen implementieren muss. Die Anforderungen an die Gewährleistung der Interoperabilität sind hiervon nicht betroffen. Anwendungshinweis 109: Die Implementierung des Blockchiffre Advanced Encryption Standard (AES) ist eine für den TOE sicherheitsrelevante Funktionalität. Dabei werden vom EVG auch HW Mechanismen (AES-NI) verwendet, sofern diese vom Administrator explizit ausgewählt werden. FCS_COP.1/NK.Hash Cryptographic operation Zu unterstützende Hash-Algorithmen Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction Alle bisher für FCS_COP.1/NK.Hash genannten Abhängigkeiten werden nicht erfüllt. Begründung: Bei einem Hash-Algorithmus handelt es sich um einen kryptographischen Algorithmus, der keine kryptographischen Schlüssel verwendet. Daher ist auch keine Funktionalität zum Import bzw. zur Generierung des kryptographischen Schlüssels und zu seiner Zerstörung erforderlich. FCS_COP.1.1/NK.Hash The TSF shall perform hash value calculation113 in accordance with a specified cryptographic algorithm SHA-1, SHA- 113 [assignment: list of cryptographic operations] Security Target secunet konnektor 2.1.0 secunet Seite 191 von 424 256, [none]114 and cryptographic key sizes none115 that meet the following: FIPS PUB 180-4 [54].116 FCS_COP.1/NK.HMAC Cryptographic operation Zu unterstützende Hash basierende MAC-Algorithmen Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] hier erfüllt durch: FCS_CKM.1/NK FCS_CKM.4 Cryptographic key destruction hier erfüllt durch: FCS_CKM.4/NK FCS_COP.1.1/NK.HMAC The TSF shall perform HMAC value generation and verification117 in accordance with a specified cryptographic algorithm HMAC with SHA-1, [SHA-256]118 and cryptographic key sizes [128 bit, 256 bit] 119 that meet the following: FIPS PUB 180-4 [54], RFC 2404 [62], RFC 4868 [63], RFC 7296 [60].120 FCS_COP.1/NK.Auth Cryptographic operation Authentisierungs-Algorithmen, die im Rahmen von Authenti- sierungsprotokollen zum Einsatz kommen Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] Die hier genannten Abhängigkeiten werden nicht erfüllt. Begründung: Die signature creation wird von der gSMC-K durchgeführt. Der verwendete private Schlüssel verbleibt dabei immer innerhalb der gSMC-K. Daher ist auch keine Funktionalität zum Import bzw. zur Generierung des kryptographischen Schlüssels erforderlich. Die verification of digital signatures kann auch im EVG durchgeführt werden. Die entsprechenden öffentlichen Schlüsselobjekte werden durch den Import von Zertifikaten in den 114 [assignment: cryptographic algorithm] -> SHA-1, SHA-256, [assignment: list of SHA-2 Algorithms with more than 256 bit size] 115 [assignment: cryptographic key sizes] 116 [assignment: list of standards] 117 [assignment: list of cryptographic operations] -> HMAC with SHA-1, [assignment: list of SHA-2 Algorithms with 256bit size or more] 118 [assignment: cryptographic algorithm] 119 [assignment: cryptographic key sizes] 120 [assignment: list of standards] Security Target secunet konnektor 2.1.0 Seite 192 von 424 secunet EVG eingebracht, die Abhängigkeit wird inhaltlich durch FPT_TDC.1/NK.Zert erfüllt. FCS_CKM.4 Cryptographic key destruction hier erfüllt durch: FCS_CKM.4/NK für die öffentlichen Schlüsselobjekte zur verification of digital signatures im EVG. FCS_COP.1.1/NK.Auth The TSF shall perform a) verification of digital signatures and b) signature creation with support of gSMC-K storing the signing key and performing the RSA or ECC operation 121 in accordance with a specified cryptographic algorithm ecdsa-with- SHA256 OID 1.2.840.10045.4.3.2 (brainpoolP256r1) and sha256withRSAEncryption OID 1.2.840.113549.1.1.11122 and cryptographic key size 256 bit and 2048 bit123 that meet the following: RFC 8017 (PKCS#1) [53], FIPS PUB 180-4 [54], Standard TR-03111 [23]124 . FCS_COP.1/NK.ESP Cryptographic operation Zu unterstützende Verschlüsselungs-Algorithmen für die IPsec- Tunnel in FTP_ITC.1/NK.VPN_TI und FTP_ITC.1/NK.VPN_SIS Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] hier erfüllt durch: FCS_CKM.1/NK FCS_CKM.4 Cryptographic key destruction hier erfüllt durch: FCS_CKM.4/NK FCS_COP.1.1/NK.ESP The TSF shall perform symmetric encryption and decryption with Encapsulating Security Payload125 in accordance with a specified cryptographic algorithm AES-CBC (OID 2.16.840.1.101.3.4.1.42) or AES-GCM (OID 2.16.840.1.101.3.4.1.46 and OID 2.16.840.1.101.3.4.1.6)126 and cryptographic key sizes 128 bit and 256 bit127 that meet the 121 [assignment: list of cryptographic operations] 122 [assignment: cryptographic algorithm] 123 [assignment: cryptographic key sizes] 124 [assignment: list of standards] 125 [assignment: list of cryptographic operations] 126 [assignment: cryptographic algorithm] 127 [assignment: cryptographic key sizes] Security Target secunet konnektor 2.1.0 secunet Seite 193 von 424 following: FIPS 197 [55], RFC 3602 [61], RFC 4303 (ESP) [59], RFC 4106 [65], specification [30] 128 . FCS_COP.1/NK.IPsec Cryptographic operation Zu unterstützende Verschlüsselungs-Algorithmen für die IPsec- Tunnel in FTP_ITC.1/NK.VPN_TI und FTP_ITC.1/NK.VPN_SIS Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] hier erfüllt durch: FCS_CKM.1/NK FCS_CKM.4 Cryptographic key destruction hier erfüllt durch: FCS_CKM.4/NK FCS_COP.1.1/NK.IPsec The TSF shall perform VPN communication129 in accordance with a specified cryptographic algorithm IPsec- protocol130 and cryptographic key sizes 256 bit131 that meet the following: RFC 4301 (IPsec) [56], specification [30]132 . FCS_CKM.1/NK Cryptographic key generation Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation] hier erfüllt durch: FCS_CKM.2/NK.IKE, FCS_COP.1/NK.Auth, FCS_COP.1/NK.IPsec und FCS_COP.1/NK.Hash FCS_CKM.4 Cryptographic key destruction hier erfüllt durch: FCS_CKM.4/NK FCS_CKM.1.1/NK The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [key generation for IPsec Session Keys]133 and specified cryptographic key sizes [128 bit, 256 bit]134 that meet the following: specification [30], TR- 03116 [19]135 . 128 [assignment: list of standards] 129 [assignment: list of cryptographic operations] 130 [assignment: cryptographic algorithm] 131 [assignment: cryptographic key sizes] 132 [assignment: list of standards] 133 [assignment: cryptographic key generation algorithm] 134 [assignment: cryptographic key sizes] 135 [assignment: list of standards] Security Target secunet konnektor 2.1.0 Seite 194 von 424 secunet Anwendungshinweis 110: Für alle mittels FCS_COP.1/... beschriebenen kryptographische Operationen (mit Ausnahme der Hashwertberechnung, siehe FCS_COP.1/NK.Hash) sind kryptographische Schlüssel erforderlich, die entsprechend der Abhängigkeiten von FCS_COP.1 aus CC Teil 2 [5] entweder durch eine Schlüsselgenerierung (FCS_CKM.1) oder durch einen Schlüsselimport (FDP_ITC.1 oder FDP_ITC.2) zu erfüllen sind. In diesem Security Target wurde entsprechend zum Schutzprofil NK-PP [17] eine Schlüsselgenerierung gewählt (siehe FCS_CKM.1/NK), da der EVG im Rahmen des Diffie-Hellman-Keyexchange-Protocols (bzw. Elliptic-curve Diffie– Hellman bei ECC) seine Sitzungsschlüssel (session keys) für die VPN-Kanäle ableitet; diese Ableitung wird als Schlüsselgenerierung angesehen. (Der Aspekt des Schlüsselaustausches mit einem VPN-Konzentrator wird als FCS_CKM.2/NK.IKE modelliert, siehe unten). Alle erzeugten Schlüssel besitzen mindestens 100 bit Entropie, damit der EVG resistent gegen Angriffe mit hohem Angriffspotential ist. FCS_CKM.2/NK.IKE Cryptographic key distribution Schlüsselaustausch symmetrischer Schlüssel im Rahmen des Aufbaus des VPN-Kanals. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] hier erfüllt durch: FCS_CKM.1/NK FCS_CKM.4 Cryptographic key destruction hier erfüllt durch: FCS_CKM.4/NK FCS_CKM.2.1/NK.IKE The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method IPsec IKE v2136 that meets the following standard: RFC 7296 [60], specifications [30], TR-02102-3 [18]137 . FCS_CKM.4/NK Cryptographic key destruction Löschen nicht mehr benötigter Schlüssel. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] hier erfüllt durch: FCS_CKM.1/NK FCS_CKM.4.1/NK The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method [zeroisation]138 that meets the following: [none]139 . 136 [assignment: cryptographic key distribution method] 137 [assignment: list of standards] 138 [assignment: cryptographic key destruction method] 139 [assignment: list of standards] Security Target secunet konnektor 2.1.0 secunet Seite 195 von 424 Anwendungshinweis 111: FCS_CKM.4/NK zerstört die von den Komponenten FCS_COP.1/... sowie FCS_CKM.2 (FCS_COP.1/NK.Auth, FCS_COP.1/NK.IPsec, FCS_CKM.2/NK.IKE) benötigten Schlüssel. Gleiches gilt für die in Kapitel 6.2.8 für TLS-Kanäle verwendeten Schlüssel. Die Schlüssel werden dabei mit Nullen überschrieben. Anwendungshinweis 112: Die Operationen entsprechen den Anforderungen in den Dokumenten [19], [30] und [27]. Es wurden keine weiteren Verfeinerungen der Zuweisungen der Operationen durchgeführt. Gleiches gilt für die in Kapitel 6.2.8 für TLS-Kanäle definierten Kryptoverfahren. Der DH-Exponent für den Schlüsselaustausch weist eine Mindestlänge gemäß [30] auf (mindestens 256 Bit). Für IKE-Lifetime, IPsec-SA-Lifetime und Forward Secrecy wurden die Vorgaben aus [30] berücksichtigt. 6.2.8. TLS-Kanäle unter Nutzung sicherer kryptographischer Algorithmen Anmerkung 6. Die Absicherung der Administrationsschnittstellen des Netzkonnektors erfolgt mittels TLS. Die SFRs aus dem PP [17] wurden dafür entsprechend vervollständigt. FTP_ITC.1/NK.TLS Inter-TSF trusted channel Grundlegende Sicherheitsleistungen eines TLS-Kanals Dependencies: No dependencies. FTP_ITC.1.1/NK.TLS The TSF shall provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels and is able to140 provides assured identification of its end points and protection of the channel data from modification and141 disclosure. FTP_ITC.1.2/NK.TLS The TSF must be able to142 permit the TSF or another trusted IT-Product143 to initiate communication via the trusted channel. FTP_ITC.1.3/NK.TLS The TSF shall initiate communication via the trusted channel for communication required by the Anwendungskonnektor, [for administration]144 . Refinement: Die Anforderung „protection of the channel data from modification and disclosure“ ist zu verstehen als Schutz der Integrität und der Vertraulichkeit (der Kanal muss beides leisten). Dabei umfasst hier „integrity“ außer der Verhinderung unbefugter Modifikation auch Verhinderung von unbefugtem Löschen, Einfügen oder Wiedereinspielen von Daten während der Kommunikation. Der 140 refinement: dieses Refinement soll darauf hinweisen, dass der Netzkonnektor die Möglichkeit implementiert, beide Seiten zu authentisieren, dass es aber Entscheidung des nutzenden Systems (i.a. der Anwendungskonnektor) ist, inwieweit diese Authentisierung genutzt wird. 141 refinement (or  and) 142 refinement (shall  must be able to) 143 [selection: the TSF, another trusted IT-Product] 144 [assignment: list of functions for which a trusted channel is required] Security Target secunet konnektor 2.1.0 Seite 196 von 424 secunet Trusted Channel muss auf Basis des TLS-Protokolls aufgebaut werden (siehe Konnektor-Spezifikation [27] und [30], wobei TLS 1.2 gemäß RFC 5246 [69] unterstützt werden muss. Die folgenden Cipher Suiten MÜSSEN unterstützt werden: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Die Anforderung „assured identification” im ersten Element des SFR impliziert, dass der EVG in der Lage sein muss, die Authentizität des „trusted IT-product“ zu prüfen. Im Rahmen dieser Überprüfung muss er in der Lage sein, eine Zertifikatsprüfung durchführen (siehe FPT_TDC.1/NK.TLS.Zert). Da allerdings der Anwendungskonnektor in Abhängigkeit von der TLS-Verbindung ggf. entscheiden kann, auf eine Authentisierung eines der Endpunkte zu verzichten, wurde ein entsprechendes refinement gewählt. Aus demselben Grund wurde dies für die Frage, ob der EVG selbst oder das andere IT-Produkt die Kommunikation anstoßen kann, durch ein refinement präzisiert, da auch dies vom Typ der TLS-Verbindung abhängt und vom Anwendungskonnektor entschieden wird. Anwendungshinweis 113: Der EVG unterstützt TLS Version 1.2 (s. [30]). Der EVG unterstützt alle im Refinement des SFRs genannten Kryptosuiten als Algorithmen für TLS, dabei werden die Anforderungen aus [30] erfüllt. Die Kryptosuiten werden für die TLS-Kommunikation zwischen dem Anwendungskonnektor und anderen Komponenten genutzt, sowie für die Absicherung der Administrationsschnittstellen. Der Konnektor unterstützt nicht TLS Version 1.0, 1.1 und SSL. FPT_TDC.1/NK.TLS.Zert Inter-TSF basic TSF data consistency Prüfung der Gültigkeit von TLS-Zertifikaten Dependencies: No dependencies. FPT_TDC.1.1/NK.TLS.Zert The TSF shall provide the capability to consistently interpret (1) X.509-Zertifikate für TLS-Verbindungen (2) eine Liste gültiger CA-Zertifikate (Trust-Service Status List TSL) Security Target secunet konnektor 2.1.0 secunet Seite 197 von 424 (3) Sperrinformationen zu Zertifikaten für TLS-Verbindungen, die via OCSP erhalten werden (4) importierte X.509 Zertifikate für Clientsysteme (5) eine im Konnektor geführte Whitelist von Zertifikaten für TLS- Verbindungen (6) [no additional data types]145 when shared between the TSF and another trusted IT product. FPT_TDC.1.2/NK.TLS.Zert The TSF shall use [interpretation rules]146 when interpreting the TSF data from another trusted IT product. Refinement: Die „interpretation rules“ umfassen: Der EVG muss prüfen können, ob die Gültigkeitsdauer eines Zertifikates überschritten ist und ob ein Zertifikat in einer Whitelist oder in einer gültigen Zertifikatskette bis zu einer zulässigen CA (Letzteres ggf. anhand der TSL) enthalten ist. Ebenso muss sie anhand einer OCSP-Anfrage prüfen können, ob das Zertifikat noch gültig ist. Anwendungshinweis 114: Die interpretation rules orientieren sich an der Konnektor-Spezifikation [27]. Anwendungshinweis 115: Die TSL muss gemäß Anforderung TIP1-A_4684 in der Konnektor- Spezifikation [27] im Online-Modus mindestens einmal täglich auf Aktualität überprüft werden. Der Konnektor kann die TSL bei Bedarf manuell importieren (siehe Anforderung TIP1-A_4705 und TIP1-A_4706 in [27]). FCS_CKM.1/NK.TLS Cryptographic key generation / TLS Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation] hier erfüllt durch: FCS_COP.1/NK.TLS.HMAC und FCS_COP.1/NK.TLS.AES FCS_CKM.4 Cryptographic key destruction hier erfüllt durch FCS_CKM.4/NK FCS_CKM.1.1/NK.TLS The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, 145 [assignment: list of TSF data types] 146 [assignment: list of interpretation rules to be applied by the TSF] (die Regeln werden teilweise im Refinement angeführt) Security Target secunet konnektor 2.1.0 Seite 198 von 424 secunet TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384147 and specified cryptographic key sizes 128 bit for AES-128, 256 bit for AES-256, 160 for HMAC with SHA, 256 for HMAC with SHA- 256 and 384 for HMAC with SHA-384148 that meet the following: RFC 5246 [69].149 Anwendungshinweis 116: Der EVG unterstützt TLS Version 1.2 [38] (s. [30]). TLS 1.3 wird zurzeit nicht unterstützt. Der EVG unterstützt alle im SFR genannten cipher suites als Algorithmen für TLS. Die Schlüsselerzeugung basiert auf dem Diffie-Hellman-Keyexchange-Protocol mit RSA-Signaturen (DHE_RSA nach [70]) bzw. dem Elliptic-Curve-Diffie-Hellman- Keyexchange-Protocol mit RSA-Signaturen (ECDHE_RSA nach [71]) oder ECC- Signaturen (ECDHE_ECDSA mit ephemeren Elliptic-Curve-Diffie-Hellman- Schlüsselaustausch die Kurven P-256 und P-384 (FIPS PUB 186-4 [108]) und die Kurven brainpoolP256r1 und brainpoolP384r1 (vgl. RFC-5639 [101] und RFC-7027 [109])). Die Auswahloperation zur Schlüssellänge hängt von den gewählten Algorithmen ab. Die Schlüssel werden für die TLS-Kommunikation zwischen dem EVG und anderen Komponenten genutzt. Es werden jeweils getrennte Schlüssel für jede Verwendung und Verschlüsselung nach FCS_COP.1/NK.TLS.AES und FCS_COP.1/NK.TLS.HMAC berechnet. Der EVG erzeugt Schlüssel mit einer Entropie von mindestens 100 Bit (siehe [19]). Bezüglich Diffie-Hellman-Gruppen für die Schlüsselaushandlung wurden die Vorgaben aus [30] beachtet. Der DH-Exponent für den Schlüsselaustausch weist eine Mindestlänge gemäß [30] auf. Bezüglich Elliptic-Curve-Diffie-Hellman-Keyexchange werden die gemäß [30] vorgegebenen Kurven unterstützt. FCS_COP.1/NK.TLS.HMAC Cryptographic operation / HMAC for TLS Zu unterstützende Hash basierende MAC-Algorithmen Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] hier erfüllt durch: FCS_CKM.1/NK.TLS FCS_CKM.4 Cryptographic key destruction hier erfüllt durch: FCS_CKM.4/NK 147 [assignment: cryptographic key generation algorithm] 148 [assignment: cryptographic key sizes] 149 [assignment: list of standards] Security Target secunet konnektor 2.1.0 secunet Seite 199 von 424 FCS_COP.1.1/NK.TLS.HMAC The TSF shall perform HMAC value generation and verification150 in accordance with a specified cryptographic algorithm HMAC with SHA-1, SHA-256 and SHA-384151 and cryptographic key sizes 160 for HMAC with SHA, 256 for HMAC with SHA-256, and 384 for HMAC with SHA-384152 that meet the following: Standards FIPS 180-4 [54] and RFC 2104 [75]153 . Anwendungshinweis 117: FCS_COP.1/NK.TLS.HMAC wird für die Integritätssicherung innerhalb des TLS-Kanals benötigt. FCS_COP.1/NK.TLS.AES Cryptographic operation Zu unterstützende Verschlüsselungs-Algorithmen für die TLS Verbindung in FTP_ITC.1/NK.TLS Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] hier erfüllt durch: FCS_CKM.1/NK.TLS FCS_CKM.4 Cryptographic key destruction hier erfüllt durch: FCS_CKM.4/NK FCS_COP.1.1/NK.TLS.AES The TSF shall perform symmetric encryption and decryption154 in accordance with a specified cryptographic algorithm AES-128 and AES-256 in CBC and GCM Mode155 and cryptographic key sizes 128 bit for AES-128 and 256 bit for AES-256156 that meet the following: FIPS 197 [55], NIST 800-38D [99], RFC 5246 [69], RFC 8422 [100], RFC 5289 [72], specification [30] 157 . Anwendungshinweis 118: Es gilt Anwendungshinweis 109. 150 [assignment: list of cryptographic operations] 151 [assignment: cryptographic algorithm] 152 [assignment: cryptographic key sizes] 153 [assignment: list of standards] 154 [assignment: list of cryptographic operations] 155 [assignment: cryptographic algorithm] 156 [assignment: cryptographic key sizes] 157 [assignment: list of standards] Security Target secunet konnektor 2.1.0 Seite 200 von 424 secunet FCS_COP.1/NK.TLS.Auth Cryptographic operation for TLS Authentisierungs-Algorithmen, die im Rahmen von TLS zum Einsatz kommen Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] hier erfüllt durch: FCS_CKM.1/NK.Zert und FDP_ITC.2/NK.TLS. Die signature creation wird im Standardfall von der gSMC-K bzw. SM-B durchgeführt. Der verwendete private Schlüssel verbleibt dabei immer innerhalb der gSMC-K bzw. SM-B. In diesem Fall ist auch keine Funktionalität zum Import bzw. zur Generierung des kryptographischen Schlüssels erforderlich. Neben der verification of digital signatures kann auch die signatur creation im EVG durchgeführt werden. Die entsprechenden privaten oder öffentlichen Schlüsselobjekte werden entweder im EVG erzeugt (FCS_CKM.1/NK.Zert) oder importiert (FDP_ITC.2/NK.TLS). Die Interpretation von TLS Zertifikaten wird durch FPT_TDC.1/NK.TLS.Zert erbracht. FCS_CKM.4 Cryptographic key destruction hier erfüllt durch: FCS_CKM.4/NK für die öffentlichen Schlüsselobjekte zur verification of digital signatures im EVG. FCS_COP.1.1/NK.TLS.Auth The TSF shall perform a) verification of digital signatures and b) signature creation with support of gSMC-K or SM-B158 storing the signing key and performing the RSA and ECDSA159 operation160 c) signature creation with help of the FCS_CKM.1/NK.Zert and performing the RSA and ECDSA operation 161 in accordance with a specified cryptographic algorithm sha256withRSAEncryption OID 1.2.840.113549.1.1.11162 or ecdsa- with-SHA256 OID 1.2.840.10045.4.3.2 (brainpool256r1 or brainpool384r1)163 and cryptographic key sizes 2048 bit164 or 384 158 Refinement: or SM-B 159 Refinement: and ECDSA 160 [assignment: list of cryptographic operations] 161 Refinement: c) … 162 [assignment: cryptographic algorithm] 163 Refinement: or ecdsa-with-SHA256 OID 1.2.840.10045.4.3.2 (brainpool256r1 or brainpool384r1) 164 [assignment: cryptographic key sizes] Security Target secunet konnektor 2.1.0 secunet Seite 201 von 424 bit or 256 bit165 that meet the following: RFC 8017 (PKCS#1) [53], FIPS PUB 180-4 [54]166 , Standard TR-03111 [23]167. Anwendungshinweis 119: Die Signaturberechnung gemäß FCS_COP.1/NK.TLS.Auth wird für die Berechnung digitaler Signaturen zur Authentisierung bei TLS verwendet. Der EVG nutzt dafür bei Verbindungen ins lokale Netz (LAN) des Leistungserbringers die gSMC-K oder eine eigene Zertifikatsgenerierung bzw. ein importiertes Zertifikate/Schlüsselpaar (siehe FDP_ITC.2/NK.TLS). Im Fall der gSMC-K oder SM-B wird der dafür benötigte asymmetrische Schlüssel während der Produktion der gSMC-K oder SM-B importiert oder generiert. Es werden deshalb keine spezischen Anforderungen an die Quelle dieses Schlüssels gestellt. Für die asymmetrischen Schlüssel die im Konnektor generiert werden gilt FCS_CKM.1/NK.Zert. Für Verbindungen zum WAN wird eine SM-B verwendet die der Anwendungskonnektor ansteuert. Hier wird nur die LAN-seitige TLS-Verbindung modelliert. Die WAN-seitige TLS-Verbindung erfolgt analog und nutzt dieselben kryptografischen Basisdienste für TLS. FCS_CKM.1/NK.Zert Cryptographic key generation / Certificates Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation] nicht erfüllt mit folgender Begründung: FCS_CKM.1/NK.Zert bietet die Möglichkeit X.509 Zertifikate für die TLS-geschützte Kommunikation mit Clientsystemen zu erzeugen. Gemäß FDP_ETC.2/AK.Enc können die Zertifikate und die zugehörigen privaten Schlüssel vom Administrator exportiert werden. Keydistribution gemäß FCS_CKM.2 findet nicht statt. FCS_CKM.4 Cryptographic key destruction hier erfüllt durch: FCS_CKM.4/NK FCS_CKM.1.1/NK.Zert The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [RSA Key Pair Generation, Elliptic Curve Key Pair Generation]168 and specified cryptographic key sizes 2048 bit169 for RSA and 256 bit for ECC with brainpoolP256r1170 that meet the following: Standard OID 1.2.840.113549.1.1.11, RFC 4055 [52], BSI TR- 03116-1 [19],171 OID 1.2.840.10045.4.3.2, RFC 5639 [101], BSI TR-03111 [23] 172 165 Refinement: or 384 bit or 256 bit 166 [assignment: list of standards] 167 Refinement: Standard TR-03111 [23] 168 [assignment: Algorithm for cryptographic key generation of key pairs] 169 [assignment: cryptographic key sizes] 170 Refinement: for RSA and 256 bit for ECC with brainpoolP256r1 171 [assignment: list of standards] 172 Refinement: OID 1.2.840.10045.4.3.2, RFC 5639 [101], BSI TR-03111 [23] Security Target secunet konnektor 2.1.0 Seite 202 von 424 secunet The TSF shall (1) create a valid X.509 [76] certificate with the generated RSA key pair and (2) create a PKCS#12 [77] file with the created certificate and the associated private key. 173 (3) create a valid X.509 [76] certificate with the generated ECDSA key pair174 Anwendungshinweis 120: Der Algorithmus für die Schlüsselerzeugung muss die Vorgaben aus [30], Anforderung GS-A_4368 umsetzen. Die Verfeinerung zu FCS_CKM.1/NK.Zert soll die Möglichkeit zur Erzeugung von X.509 Zertifikaten für die TLS-geschützte Kommunikation mit Clientsystemen bieten. Die Zertifikate können für Clientsysteme oder den TOE verwendet werden, hierbei werden bei Clientzertifikate Schlüssel und Zertifikate exportiert und bei Serverzertifikaten nur die Zertifikate. Ein Export dieser Zertifikate und der zugehörigen privaten Schlüssel ist Gegenstand von FDP_ETC.2/NK.TLS. FDP_ITC.2/NK.TLS Import of user data with security attributes Import von Zertifikaten Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] Gemäß dem SFR FMT_MOF.1/NK.TLS werden die TLS- Verbindungen des Konnektors durch den Anwendungskonnektor gemanagt. Dies betrifft auch die Bedingungen dafür, wie und wann Schlüssel und Zertifikate für TLS-Verbindungen importiert werden. Die Abhängigkeit wird durch FDP_ACC.1/AK.TLS des Anwendungskonnektors erfüllt. [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] hier erfüllt durch: FTP_TRP.1/NK.Admin FPT_TDC.1 Inter-TSF basic TSF data consistency hier erfüllt durch: FPT_TDC.1/NK.TLS.Zert FDP_ITC.2.1/NK.TLS The TSF shall enforce the Certificate-Import-SFP175 when importing user data, controlled under the SFP, from outside of the TOE. FDP_ITC.2.2/NK.TLS The TSF shall use the security attributes associated with the imported user data. 173 Refinement 174 Refinement: create a valid X.509 [76] certificate with the generated ECDSA key pair 175 [assignment: access control SFP(s) and/or information flow control SFP(s)] Security Target secunet konnektor 2.1.0 secunet Seite 203 von 424 FDP_ITC.2.3/NK.TLS The TSF shall ensure that the protocol used provides for the unambiguous association between the securityattributes and the user data received. FDP_ITC.2.4/NK.TLS The TSF shall ensure that interpretation of the security attributes of the imported user data is as intended by the source of the user data. FDP_ITC.2.5/NK.TLS The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TOE: (1) Die TSF importiert X.509 Zertifikate für Clientsysteme durch den Administrator über die Management-Schnittstelle (2) [Die TSF importiert X.509 Zertifikate und zugehörige private Schlüssel für den TOE durch den Administrator über die Management-Schnittstelle]176 Anwendungshinweis 121: Gemäß FMT_MOF.1/NK.TLS überlässt der Netzkonnektor die Steuerung, unter welchen Umständen der Import von Client oder Server-Zertifikaten erfolgt, dem Anwendungskonnektor. FDP_ETC.2/NK.TLS Export of user data with security attributes Export von Zertifikaten Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] Gemäß dem SFR FMT_MOF.1/NK.TLS werden die TLS- Verbindungen des Konnektors durch den Anwendungskonnektor gemanagt. Dies betrifft auch die Bedingungen dafür, wie und wann Schlüssel und Zertifikate für TLS-Verbindungen erzeugt und exportiert werden. Die Abhängigkeit wird durch FDP_ACC.1/AK.TLS des Anwendungskonnektors erfüllt. FDP_ETC.2.1/NK.TLS The TSF shall enforce the Certificate-Export-SFP177 when exporting user data, controlled under the SFP(s), outside of the TOE. FDP_ETC.2.2/NK.TLS The TSF shall export the user data with the user data's associated security attributes. FDP_ETC.2.3/NK.TLS The TSF shall ensure that the security attributes, when exported outside the TOE, are unambiguously associated with the exported user data. FDP_ETC.2.4/NK.TLS The TSF shall enforce the following rules when user data is exported from the TOE: (1) Die TSF exportiert X.509 Zertifikate für Clientsysteme und den zugehörigen privaten Schlüssel durch den 176 [assignment: additional importation control rules] 177 [assignment: access control SFP(s) and/or information flow control SFP(s)] Security Target secunet konnektor 2.1.0 Seite 204 von 424 secunet Administrator über die Management-Schnittstelle. Als Exportformat wird PKCS#12 verwendet. (2) [Die TSF exportiert X.509 Zertifikate für Serversysteme durch den Administrator über die Management- Schnittstelle.]178 Anwendungshinweis 122: Gemäß FMT_MOF.1/NK.TLS überlässt der Netzkonnektor die Steuerung, unter welchen Umständen der Export von Client- und Server-Zertifikaten erfolgt, dem Anwendungskonnektor. FMT_MOF.1/NK.TLS Management of security functions behaviour Management von TLS-Verbindungen durch den Anwendungskonnektor Dependencies: FMT_SMR.1 Security roles hier erfüllt durch FMT_SMR.1./NK FMT_SMF.1 Specification of Management Functions hier erfüllt durch FMT_SMF.1/NK FMT_MOF.1.1/NK-TLS The TSF shall restrict the ability to determine the behaviour of179 the functions Management of TLS-Connections required by the Anwendungskonnektor180to Anwendungskonnektor181. The following rules apply: For each TLS-Connection managed by the Anwendungskonnektor, only the Anwendungskonnektor can determine: 1. Whether one or both endpoints of the TLS-connection need to be authenticated and which authentication mechanism is used for each endpoint. 2. Whether the Konnektor or the remote IT-Product or both can initiate the TLS-Connection. 3. Whether TLS 1.2 or TLS 1.3 (if provided) are used and which subset of the set of cipher suites as listed in FTP_ITC.1/NK.TLS is allowed for each connection. 4. Whether a “Keep-Alive” mechanism is used for a connection. 5. Which data can or must be transmitted via each TLS- Connection. 178 [assignment: additional exportation control rules] 179 [selection: determine the behaviour of, disable, enable, modify the behaviour of] 180 [assignment:list of functions] 181 [assignment: the authorised identified roles] Security Target secunet konnektor 2.1.0 secunet Seite 205 von 424 6. Whether the validity of the certificate of a remote IT- Product needs to be verified and whether a certificate chain or a whitelist is used for this verification. 7. Under which conditions a TLS-connection is terminated. 8. Whether and how terminating and restarting a TLS- connection using a Session-ID is allowed. 9. Whether and under which conditions certificates and keys for TLS-Connections are generated and exported or imported. 10.[no additional rules] If one or more of these rules are managed by the EVG itself, this shall also be interpreted as a fulfillment of this or these rules. 182 Anwendungshinweis 123: Dieses SFR soll dafür sorgen, dass der Anwendungskonnektor alle Regeln durchsetzen kann, die gemäß der gematik-Spezifikationsdokumente für die verschiedenen vom Konnektor benötigten TLS-Verbindungen durchgesetzt werden müssen. Only TLS 1.2 is provided. Der Netzkonnektor nutzt die TLS-Verbindungen auch zur Absicherung der Administrationsschnittstelle. Die Verbindung wird ebenfalls durch den Anwendungskonnktor gemanagt. Erläuterung: Diese Regeln werden durch verschiedene SFRs des Anwendungskonnektor konkretisiert. Anwendungshinweis 124: Es wurden keine SFRs aus dem Schutzprofil des Gesamtkonnektors [16] bezüglich Managment der TLS-Verbindungen auf den Netzkonnektor übertragen. Das Managment erfolgt durch den Anwendungskonnektor. 6.3. Funktionale Sicherheitsanforderungen des Anwendungskonnektors 6.3.1. Klasse FCS: Kryptographische Unterstützung Der EVG implementiert kryptographische Algorithmen in der Software des Konnektors. Die asymmetrischen Algorithmen mit privaten Schlüsseln und die kryptographischen Algorithmen und Protokolle für die Kommunikation mit Chipkarten (d. h. dem HBA für Stapelsignatur und Komfortsignatur) werden in der gSMC-K (nicht Teil des EVG) implementiert. Die Ausnahme bildet die Verwendung eines X.509 Zertifikates (ID.AK.AUT) durch importiertes oder selbstgeneriertes Schlüsselmaterial. Die Software des Konnektors implementiert kryptographische Algorithmen und Protokolle für die IPsec-Kanäle und:  Algorithmen für die Erstellung und die Prüfung elektronischer Signaturen, wobei die Erzeugung der digitalen Signaturen in den Chipkarten HBA und SMC-B als Träger der Signaturschlüssel genutzt werden,  Algorithmen für die asymmetrische und symmetrische Verschlüsselung von Dokumenten, 182 refinement Security Target secunet konnektor 2.1.0 Seite 206 von 424 secunet  Algorithmen für die symmetrische Entschlüsselung, wobei die asymmetrische Entschlüsselung der Dokumentenschlüssel in den Chipkarten erfolgt,  Algorithmen für die MAC-Berechnung und die MAC-Prüfung (sowohl mit Blockchiffrieralgorithmen als auch mit Hashfunktionen) und  Protokolle für die TLS-Verbindung mit den eHealth-Kartenterminals und die Kommunikation zwischen Fachmodulen und Fachdiensten. Für alle Kryptoalgorithmen gelten die Festlegungen der TR-03116 [19] und der gematik- Spezifikation zu den anzuwendenden Kryptoalgorithmen [30]. Anwendungshinweis 125: Es gilt Anwendungshinweis 109 6.3.1.1. Basisalgorithmen Der Konnektor nutzt kryptographische Dienste der gSMC-K, in der Einsatzumgebung. Anmerkung 7. Für kartenbasierte Ver- und Entschlüsselung mit ECC gilt TAB_KON_747. 6.3.1.2. Schlüsselerzeugung und Schlüssellöschung FCS_COP.1/AK.SHA Cryptographic operation / hash value calculation AK Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/ AK.SHA The TSF shall perform hash value calculation183 in accordance with a specified cryptographic algorithm SHA-256, SHA-384 und SHA- 512184 and cryptographic key sizes none185 that meet the following: Standard FIPS PUB 180-4 [54]186 . Anwendungshinweis 126: Die Hashfunktionen nach FCS_COP.1/AK.SHA werden durch den Signaturdienst benutzt. 183 [assignment: list of cryptographic operations] 184 [assignment: cryptographic algorithm] 185 [assignment: cryptographic key sizes] 186 [assignment: list of standards] Security Target secunet konnektor 2.1.0 secunet Seite 207 von 424 Anwendungshinweis 127: Die zu unterstützenden RSA-Verfahren unterscheiden sich zwischen QES und nonQES, da in letzterem Fall in der TI auschließlich RSASSA-PSS Signaturen mit SHA-256 und Schlüssellängen von 2048 Bit vorkommen, während diese Einschränkungen für QES nicht gelten. Für die Prüfung von Signaturen ist die Verwendung veralteter Algorithmen und Parameter erlaubt, sofern die Algorithmen bzw. Parameter zum Signatur- erstellungszeitpunkt noch gültig waren. FCS_CKM.1/AK.AES Cryptographic key generation / AES keys Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction FCS_CKM.1.1/ AK.AES The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [Random Number Generation for AES keys]187 and specified cryptographic key sizes 128 bit and 256 bit188 that meet the following: [none] 189 . Anwendungshinweis 128: Der EVG erzeugt Schlüssel mit einer Entropie von mindestens 100 Bit (siehe auch [19]). Dazu werden aus dem mit der gSMC-K geseedeten Zufallszahlengenerator des Betriebssystemkernels die entsprechende Anzhal von Bits entnommen. Nach [55] sind keine schwachen Schlüssel für den AES bekannt. Der EVG erzeugt alle Schlüsselbits durch den Zufallszahlengenerator gemäß der Einsatzumgebung, um eine maximale Entropie zu erreichen und keine Schwachstelle gegenüber der möglichen kryptographischen Stärke des AES zu bilden. FCS_CKM.4/AK Cryptographic key destruction Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CMK.4.1/AK The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method [zeroisation]190 that meet the following: [none]191 . 187 [assignment: Algorithm for cryptographic key generation of AES keys] 188 [assignment: cryptographic key sizes] 189 [assignment: list of standards] 190 [assignment: cryptographic key destruction method] 191 [assignment: list of standards]] Security Target secunet konnektor 2.1.0 Seite 208 von 424 secunet 6.3.1.3. Signaturerzeugung und Signaturprüfung Der EVG erzeugt aus den von den Chipkarten erzeugten digitalen Signaturen signierte Dokumente nach den angegeben Standards XAdES [82] [87], CadES [85] [88], PAdES [86] [89] und mit PKCS#1-Containern, PKCS#1v2.2, [90]. Der EVG prüft signierte Dokumente nach den angegebenen Standards und die bei der Stapelsignatur und der Komfortsignatur von den Chipkarten erzeugten digitalen Signaturen. Anmerkung 8. Der Konnektor ermitteln bei der Signaturerstellung und Signaturprüfung (QES und nonQES) die Zertifikate und Schlüssel gemäß den Vorgaben in TAB_KON_900. FCS_COP.1/AK.SigVer.SSA Cryptographic operation / Signature verification PKCS#1 SSA Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/ AK.SigVer.SSA The TSF shall perform verification of digital signatures192 in accordance with a specified cryptographic algorithm RSASSA-PKCS1-v1_5 signature verification193 and cryptographic key sizes 1976 bit to 4096 bit194 that meet the following: Standard PKCS#1 [90]195 . Anwendungshinweis 129: Die Signaturprüfung gemäß FCS_COP.1/AK.SigVer.SSA wird für die Prüfung qualifizierter elektronischer Signaturen und nicht-qualifizierten elektronischen Signaturen verwendet, wobei für die nonQES Signaturprüfung lediglich die Schlüssellänge 2048 Bit unterstützt wird. Die Verwendung von RSASSA-PKCS1-v1_5 für nonQES beschränkt sich auf die Prüfung von Zertifikaten, OCSP-Antworten sowie OCSP- Zertifikaten und wird nicht für die Prüfung von nicht-qualifizierten Dokumentensignaturen verwendet. [30] Anwendungshinweis 130: Die zu unterstützenden RSA-Verfahren unterscheiden sich zwischen QES und nonQES, da in letzterem Fall in der TI auschließlich RSASSA-PSS Signaturen mit SHA-256 und Schlüssellängen von 2048 Bit vorkommen, während diese Einschränkungen für QES nicht gelten. Für die Prüfung von Signaturen ist die Verwendung veralteter Algorithmen und Parameter erlaubt, sofern die Algorithmen bzw. Parameter zum Signatur- erstellungszeitpunkt noch gültig waren. 192 [assignment: list of cryptographic operations] 193 [assignment: cryptographic algorithm] 194 [assignment: cryptographic key sizes] 195 [assignment: list of standards] Security Target secunet konnektor 2.1.0 secunet Seite 209 von 424 FCS_COP.1/AK.SigVer.PSS Cryptographic operation / Signature verification PKCS#1 PSS Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/ AK.SigVer.PSS The TSF shall perform verification of digital signatures196 in accordance with a specified cryptographic algorithm RSASSA-PSS signature verification197 and cryptographic key sizes 1976 bit to 4096 bit198 that meet the following: Standard PKCS#1v2.2, [90]199 . Anwendungshinweis 131: Die Signaturprüfung gemäß FCS_COP.1/AK.SigVer.PSS wird für die Prüfung qualifizierter elektronischer Signaturen und nicht-qualifizierten elektronischen Signaturen verwendet, wobei für die nonQES Signaturprüfung lediglich die Schlüssellänge 2048 Bit unterstützt wird. [30] Anwendungshinweis 132: Die zu unterstützenden RSA-Verfahren unterscheiden sich zwischen QES und nonQES, da in letzterem Fall in der TI auschließlich RSASSA-PSS Signaturen mit SHA-256 und Schlüssellängen von 2048 Bit vorkommen, während diese Einschränkungen für QES nicht gelten. Für die Prüfung von Signaturen ist die Verwendung veralteter Algorithmen und Parameter erlaubt, sofern die Algorithmen bzw. Parameter zum Signatur- erstellungszeitpunkt noch gültig waren. FCS_COP.1/AK.SigVer.ECDSA Cryptographic operation / Signature verification ECDSA Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/ AK.SigVer.ECDSA The TSF shall perform verification of digital signatures200 in accordance with a specified 196 [assignment: list of cryptographic operations] 197 [assignment: cryptographic algorithm] 198 [assignment: cryptographic key sizes] 199 [assignment: list of standards] 200 [assignment: list of cryptographic operations] Security Target secunet konnektor 2.1.0 Seite 210 von 424 secunet cryptographic algorithm ECDSA201 and cryptographic key sizes 256 bit202 that meet the following: Standard TR- 03111 [23]203 . Anwendungshinweis 133: Die Signaturprüfung gemäß FCS_COP.1/AK.SigVer.ECDSA wird für die Prüfung qualifizierter elektronischer Signaturen und nicht-qualifizierten elektronischen Signaturen verwendet [30]. FCS_COP.1/AK.XML.Sign Cryptographic operation / XML signature generation Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/ AK.XML.Sign The TSF shall perform the generation of XML-signed documents204 with digital signatures created from signature smartcards in accordance with a specified cryptographic algorithm (1) XML Advanced Electronic Signature (XAdES), (2) SHA-256 according to FCS_COP.1/AK.SHA for the creation of the DTBS (3) SAML2-Token205 and cryptographic key sizes no key206 that meet the following: Standards SAML2.0 [101],XMLSig [80], XAdES[82] [87] and FIPS PUB 180-4 [54]207 . Anwendungshinweis 134: FCS_COP.1/AK.XML.Sign fordert die Erzeugung von XML-Signaturen nach vorgegebenen Signaturrichtlinien unter Nutzung der durch Chipkarten erzeugten digitalen Signaturen. Die Verfeinerung hebt hervor, dass bestimmte Anteile durch den EVG (insbesondere die Hashfunktion gemäß FCS_COP.1/AK.SHA) und andere Teile durch die Signaturchipkarten der Einsatzumgebung, insbesondere die Erzeugung der digitalen Signatur gemäß RSA mit RSA mit PKCS#1v2.2 PSS sowie ECDSA mit 256 Bit- Schlüsseln, geleistet werden. Der EVG selbst benötigt für diese kryptographische Operation keine Schlüssel. Die Schnittstelle zur Signatur von SAML2-Token ist nur intern für Fachmodule nutzbar. 201 [assignment: cryptographic algorithm] 202 [assignment: cryptographic key sizes] 203 [assignment: list of standards] 204 [assignment: list of cryptographic operations] 205 [assignment: cryptographic algorithm] 206 [assignment: cryptographic key sizes] 207 [assignment: list of standards] Security Target secunet konnektor 2.1.0 secunet Seite 211 von 424 FCS_COP.1/AK.CMS.Sign Cryptographic operation / CMS signature generation Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/ AK.CMS.Sign The TSF shall perform sign documents208 with digital signatures created from signature smartcards in accordance with a specified cryptographic algorithm (1) CMS Advanced Electronic Signature (CadES), (2) SHA-256 according to FCS_COP.1/AK.SHA for the creation of the DTBS 209 and cryptographic key sizes no key210 that meet the following: Standards RFC5652 [78], CadES [85] [88] and FIPS PUB 180-4 [54]211 . Anwendungshinweis 135: FCS_COP.1/AK.CMS.Sign fordert die Erzeugung von CMS-Signaturen nach vorgegebenen Signaturrichtlinein. Die Verfeinerung hebt hervor, dass bestimmte Anteile durch den EVG (insbesondere die Hashfunktion gemäß FCS_COP.1/AK.SHA) und andere Teile durch die Signaturchipkarten der Einsatzumgebung, insbesondere die Erzeugung der digitalen Signatur gemäß RSA mit PKCS#1v2.2 RSASSA-PSS und RSA 2048 Bit-Schlüsseln sowie ECDSA mit 256 Bit-Schlüsseln, geleistet werden. Der EVG selbst benötigt für diese kryptographische Operation keine Schlüssel. FCS_COP.1/AK.PDF.Sign Cryptographic operation / PDF signature generation Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/ AK.PDF.Sign The TSF shall perform sign PDF-A documents212 with digital signatures created from signature smartcards in accordance with a specified cryptographic algorithm SHA-256 according to FCS_COP.1/AK.SHA for the creation of the DTBS213 and 208 [assignment: list of cryptographic operations] 209 [assignment: cryptographic algorithm] 210 [assignment: cryptographic key sizes] 211 [assignment: list of standards] 212 [assignment: list of cryptographic operations] 213 [assignment: cryptographic algorithm] Security Target secunet konnektor 2.1.0 Seite 212 von 424 secunet cryptographic key sizes no key214 that meet the following: Standards PAdES [86] [89] and FIPS PUB 180-4 [54]215 . Anwendungshinweis 136: FCS_COP.1/AK.PDF.Sign fordert die Erzeugung von PDF-Signaturen. Die Verfeinerung hebt hervor, dass bestimmte Anteile durch den EVG (insbesondere die Hashfunktion gemäß FCS_COP.1/AK.SHA) und andere Teile durch die Signaturchipkarten der Einsatzumgebung, insbesondere die Erzeugung der digitalen Signatur gemäß RSA mit RSA mit PKCS#1 PSS und RSA 2048Bit-Schlüsseln sowie ECDSA mit 256 Bit-Schlüsseln, geleistet werden. Der EVG selbst benötigt für diese kryptographische Operation keine Schlüssel. FCS_COP.1/AK.XML.SigPr Cryptographic operation / XML signature verification Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/ AK.XML.SigPr The TSF shall perform verify signed XML documents216 in accordance with a specified cryptographic algorithm (1) XML Advanced Electronic Signature (XAdES), (2) SHA-256, SHA-384 and SHA-512 for QES according to FCS_COP.1/AK.SHA with RSA with PKCS#1 SSA-V1.5 according to FCS_COP.1/AK.SigVer.SSA for QES, RSA with PKCS#1 PSS according to FCS_COP.1/AK.SigVer.PSS for QES 217 and cryptographic key sizes 1976 bit to 4096 bit for QES218 , (3) SHA-256 with ECDSA according to FCS_COP.1/AK.SigVer.ECDSA219 and cryptographic key sizes 256 bit for QES220 that meet the following: Standards XMLSig [1], XAdES [82] [87], FIPS PUB 180-4, PKCS#1[53], and TR-03111 [23]221 . 214 [assignment: cryptographic key sizes] 215 [assignment: list of standards] 216 [assignment: list of cryptographic operations] 217 [assignment: cryptographic algorithm] 218 [assignment: cryptographic key sizes] 219 [assignment: cryptographic algorithm] 220 [assignment: cryptographic key sizes] 221 [assignment: list of standards] Security Target secunet konnektor 2.1.0 secunet Seite 213 von 424 Anwendungshinweis 137: FCS_COP.1/AK.XML.SigPr fordert die Prüfung von XML-Signaturen nach vorgegebenen Signaturrichtlinien und den bereits oben spezifizierten Kryptoalgorithmen. Die Prüfung von nonQES XAdES Signaturen ist nicht gefordert und wird nicht umgesetzt. Für die Prüfung von Signaturen ist die Verwendung veralteter Algorithmen und Parameter erlaubt, sofern die Algorithmen bzw. Parameter zum Signaturerstellungszeitpunkt noch gültig waren. FCS_COP.1/AK.CMS.SigPr Cryptographic operation / CMS signature verification Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/ AK.CMS.SigPr The TSF shall perform verify signed CMS documents222 in accordance with a specified cryptographic algorithm (1) CMS Advanced Electronic Signature (CadES), (2) SHA-256, SHA-384 and SHA-512 for QES and SHA-256 for nonQES according to FCS_COP.1/AK.SHA with RSA with PKCS#1 SSA-V1.5 according to FCS_COP.1/AK.SigVer.SSA for QES, RSA with PKCS#1 PSS according to FCS_COP.1/AK.SigVer.PSS for QES and nonQES223 and cryptographic key sizes 1976 bit to 4096 bit for QES and 2048 Bit for nonQES224 , (3) SHA-256 with ECDSA according to FCS_COP.1/AK.SigVer.ECDSA225 and cryptographic key sizes 256 bit for QES and nonQES226 that meet the following: Standards RFC5652[78], CadES [85] [88], FIPS PUB 180-4, PKCS#1 [53], and TR-03111 [23]227 . 222 [assignment: list of cryptographic operations] 223 [assignment: cryptographic algorithm] 224 [assignment: cryptographic key sizes] 225 [assignment: cryptographic algorithm] 226 [assignment: cryptographic key sizes] 227 [assignment: list of standards] Security Target secunet konnektor 2.1.0 Seite 214 von 424 secunet Anwendungshinweis 138: FCS_COP.1/AK.CMS.SigPr fordert die Prüfung von CMS-Signaturen nach vorgegebenen Signaturrichtlinein und den bereits oben spezifizierten Kryptoalgorithmen. Die zu unterstützenden RSA-Verfahren unterscheiden sich zwischen QES und nonQES, da in letzterem Fall in der TI auschließlich RSASSA-PSS Signaturen mit SHA-256 und Schlüssellängen von 2048 Bit vorkommen, während diese Einschränkungen für QES nicht gelten. Für die Prüfung von Signaturen ist die Verwendung veralteter Algorithmen und Parameter erlaubt, sofern die Algorithmen bzw. Parameter zum Signaturerstellungszeitpunkt noch gültig waren. FCS_COP.1/AK.PDF.SigPr Cryptographic operation / PDF signature verification Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/ AK.PDF.SigPr The TSF shall perform verify signed PDF-A documents228 in accordance with a specified cryptographic algorithm (1) PAdES [86] [89], (2) SHA-256, SHA-384 and SHA-512 for QES and SHA-256 for nonQES according to FCS_COP.1/AK.SHA with RSA with PKCS#1 SSA-V1.5 according to FCS_COP.1/AK.SigVer.SSA for QES, RSA with PKCS#1 PSS according to FCS_COP.1/AK.SigVer.PSS for QES and nonQES229 and cryptographic key sizes 1976 bits to 4096 bits for QES and 2048 Bit for nonQES230 , (3) SHA-256 with ECDSA according to FCS_COP.1/AK.SigVer.ECDSA231 and cryptographic key sizes 256 bit for QES and nonQES 232 that meet the following: Standards PAdES [86] [89], FIPS PUB 180-4, PKCS#1 [53] and TR-03111 [23]233 . 228 [assignment: list of cryptographic operations] 229 [assignment: cryptographic algorithm] 230 [assignment: cryptographic key sizes] 231 [assignment: cryptographic algorithm] 232 [assignment: cryptographic key sizes] 233 [assignment: list of standards] Security Target secunet konnektor 2.1.0 secunet Seite 215 von 424 Anwendungshinweis 139: FCS_COP.1/AK.PDF.SigPr fordert die Prüfung von PDF-Signaturen nach vorgegebenen Signaturrichtlinein und den bereits oben spezifizierten Kryptoalgorithmen. Die zu unterstützenden RSA-Verfahren unterscheiden sich zwischen QES und nonQES, da in letzterem Fall in der TI auschließlich RSASSA-PSS Signaturen mit SHA-256 und Schlüssellängen von 2048 Bit vorkommen, während diese Einschränkungen für QES nicht gelten. Für die Prüfung von Signaturen ist die Verwendung veralteter Algorithmen und Parameter erlaubt, sofern die Algorithmen bzw. Parameter zum Signaturerstellungs- zeitpunkt noch gültig waren. Anwendungshinweis 140: Dieser Anwendungshinweis ist leer. Security Target secunet konnektor 2.1.0 Seite 216 von 424 secunet 6.3.1.4. Ver- und Entschlüsselung von Dokumenten FCS_COP.1/AK.AES Cryptographic operation / AES encryption and decryption Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/ AK.AES The TSF shall perform symmetric encryption and decryption 234 in accordance with a specified cryptographic algorithm AES-GCM235 and cryptographic key sizes 128 bit, 192 bit and 256 bit236 that meet the following: Standards FIPS 197 [55], NIST-SP-800-38A [91], NIST-SP-800-38D [92] 237 . Anwendungshinweis 141: FCS_COP.1/AK.AES wird u.a. für die symmetrische Verschlüsselung und Entschlüsselung von Dokumenten gemäß FCS_COP.1/AK.XML.Ver bzw. FCS_COP.1/AK.XML.Ent, FCS_COP.1/AK.CMS.Ver, bzw. FCS_COP.1/AK.CMS.Ent benötigt. Die Schlüssellängen 128 Bit und 192 Bit werden lediglich für die Entschlüsselung unterstützt. Man beachte, dass AES CBC nur noch für Secure Meassaging der Chipkarten und für TLS-Kanäle des Konnektors verwendet wird. FCS_COP.1/AK.XML.Ver Cryptographic operation / XML encryption Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/ AK.XML.Ver The TSF shall perform encryption of XML documents in a hybrid cryptosystem238 in accordance with a specified cryptographic algorithm ECIES and239 RSA RSAOAEP and AES-GCM with authentication tag length of 128 bit240 and cryptographic key sizes 256 bit for ECC,241 256 bit for AES and 2048 bit for RSA242 that meet the following: Standards 234 [assignment: list of cryptographic operations] 235 [assignment: cryptographic algorithm] 236 [assignment: cryptographic key sizes] 237 [assignment: list of standards] 238 [assignment: list of cryptographic operations] 239 Refinement: ECIES and 240 [assignment: cryptographic algorithm] 241 Refinement: 256 bit for ECC, 242 [assignment: cryptographic key sizes] Security Target secunet konnektor 2.1.0 secunet Seite 217 von 424 NIST-SP-800-38D [92], PKCS#1 [53], FIPS 197 [55] und XMLEnc [79]243 , [gemSpec_Krypt], Kap. 5.7244 . Anwendungshinweis 142: Dieser Anwendungshinweis ist im PP [16] leer und wird hier nur aufgeführt, um eine zum PP identische Nummerierung beizubehalten. FCS_COP.1/AK.XML.Ent Cryptographic operation / XML decrpytion Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/ AK.XML.Ent The TSF shall perform decryption of XML documents in a hybrid cryptosystem245 in accordance with a specified cryptographic algorithm ECIES and246 [RSAOAEP]247 and AES-GCM with authentication tag length of 128 bit248 and cryptographic key sizes 256 bit for ECC,249 128 bit, 192 bit and 256 bit250 that meet the following: Standards NIST-SP-800-38D [92], FIPS 197 [55] und XMLEnc [79]251 , [gemSpec_Krypt], Kap. 5.7252. Anwendungshinweis 143: Die asymmetrische Entschlüsselung des AES-Schlüssels mit privaten Schlüsseln gemäß [30] und [15] erfolgt durch die Chipkarte der Einsatzumgebung (HBA, SMC-B oder ggf. eGK). Anwendungshinweis 144: Dieser Anwendungshinweis ist leer. 243 [assignment: list of standards] 244 Refinement: ECIES Standard hinzugefügt 245 [assignment: list of cryptographic operations] 246 Refinement: ECIES and 247 [selection: RSA RSAES-PKCS1-v1_5, RSAOAEP] (the selection was assigned in the PP) 248 [assignment: cryptographic algorithm] 249 Refinement: 256 bit for ECC, 250 [assignment: cryptographic key sizes] 251 [assignment: list of standards] 252 Refinement: ECIES Standard hinzugefügt Security Target secunet konnektor 2.1.0 Seite 218 von 424 secunet Anwendungshinweis 145: Dieser Anwendungshinweis ist leer. FCS_COP.1/AK.CMS.Ver Cryptographic operation / CMS encryption Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/ AK.CMS.Ver The TSF shall perform encryption of documents in a hybrid cryptosystem253 in accordance with a specified cryptographic algorithm ECIES and254 RSA RSAOAEP and AES-GCM with authentication tag length of 128 bit255 and cryptographic key sizes 256 bit for ECC,256 256 bit for AES, 256 bit for ECC and 2048 bit for RSA257 that meet the following: Standards NIST SP800-38D [92], PKCS#1 [53], FIPS 197 [55] and CMS [78]258 , [gemSpec_Krypt], Kap. 5.7. 259 Anwendungshinweis 146: Dieser Anwendungshinweis ist im PP [16] leer und wird hier nur aufgeführt, um eine zum PP identische Nummerierung beizubehalten. FCS_COP.1/AK.CMS.Ent Cryptographic operation / CMS decryption Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/ AK.CMS.Ent The TSF shall perform decryption of documents in a hybrid cryptosystem260 in accordance with a specified cryptographic algorithm ECIES and261 [RSAOAEP]262 and AES-GCM with 253 [assignment: list of cryptographic operations] 254 Refinement: ECIES and 255 [assignment: cryptographic algorithm] 256 Refinement: 256 bit for ECC, 257 [assignment: cryptographic key sizes] 258 [assignment: list of standards] 259 Refinement: ECIES Standard hinzugefügt 260 [assignment: list of cryptographic operations] 261 Refinement: ECIES and 262 [selection: RSA RSAES-PKCS1-v1_5, RSAOAEP] (the selection was assigned in the PP) Security Target secunet konnektor 2.1.0 secunet Seite 219 von 424 authentication tag length of 128 bit263 and cryptographic key sizes 256 bit for ECC,264 128 bit, 192 bit and 256 bit265 that meet the following: Standards NIST SP800-38D [92], PKCS#1 [53], FIPS 197 [55] and CMS [78]266 , [gemSpec_Krypt], Kap. 5.7267. 6.3.2. Klasse FIA: Identifikation und Authentisierung FIA_SOS.1/AK.Passwörter Verification of secrets / Passwords Hierarchical to: No other components. Dependencies: No dependencies. FIA_SOS.1.1/AK. Passwörter The TSF shall provide a mechanism to verify that administrator passwords meet [TIP1-A_4808 in [27]]268 . Anwendungshinweis 147: Die Verfeinerung von „secrets“ zu „administrator passwords“ wurde durchgeführt, um die Qualitätsanforderungen gegenüber anderen Mechanismen abzugrenzen. Gemäß [27], Kap. 4.3.1, sind Administratorpasswörter gefordert, die den Anforderungen aus dem IT_Grundschutz-Katalog des BSI genügen. FIA_SOS.2/AK.PairG TSF Generation of secrets / Pairing secret Hierarchical to: No other components. Dependencies: No dependencies. FIA_SOS.2.1/AK.PairG The TSF shall provide a mechanism to generate pairing secrets that meet the requirement to consist of 16 random bytes with 100 bit of entropy269 . FDP_SOS.2.2/AK.PairG The TSF shall be able to enforce the use of TSF generated pairing secrets for authentication of eHealth cardterminals270 . FIA_UID.1/AK Timing of identification Hierarchical to: No other components. Dependencies: No dependencies. FIA_UID.1.1/AK The TSF shall allow 263 [assignment: cryptographic algorithm] 264 Refinement: 256 bit for ECC, 265 [assignment: cryptographic key sizes] 266 [assignment: list of standards] 267 Refinement: ECIES Standard hinzugefügt 268 [assignment: a defined quality metric] 269 [assignment: a defined quality metric] 270 [assignment: list of TSF functions] Security Target secunet konnektor 2.1.0 Seite 220 von 424 secunet (1) Self test according to FPT_TST.1/AK.Out-Of-Band, (2) [Alternativer Werksreset und Werksreset für Fail Safe]271 on behalf of the user to be performed before the user is identified. FIA_UID.1.2/AK The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. Anwendungshinweis 148: Es wurde über das zugrundeliegende PP hinausgehend die Möglichkeit „Alternativer Werksreset und Werksreset für Fail Safe“ ohne vorherige Identifizierung durchzuführen. FIA_UAU.1/AK Timing of authentication Hierarchical to: No other components. Dependencies: FIA_UID.1 Timing of identification FIA_UAU.1.1/AK The TSF shall allow (1) Identification of an user of the administrative interface, an user of the a Clientsytem, a smart cardand a eHealth cardterminal, (2) Signature verification according to FDP_ACF.1/AK.SigPr, (3) Encryption according to FDP_ACF.1/AK.Enc, (4) Handover of a card handle of an identified smart card, (5) [Alternativer Werksreset und Werksreset für Fail Safe]272 on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2/AK The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. Anwendungshinweis 149: Der EVG erzwingt nur für die Administratorfunktion durch menschliche Nutzer sowie die Terminals und Chipkarten als technische Komponenten eine Authentisierung. Die TSF-vermittelten Aktionen zum Kartenmanagement, zur Signaturerstellung, zur Verschlüsselung und zur Entschlüsselung durch Benutzer des Clientsystems erfordern eine Autorisierung des Benutzers, d. h. seine erfolgreiche Authentisierung gegenüber der zu benutzenden authentisierten Chipkarte (für Signaturdienst gegenüber der Signaturchipkarte mit der PIN als Signaturschlüssel- Inhaber, für die Entschlüsselung gegenüber der Chipkarte mit dem Entschlüsslungsschlüssel als Kartenhalter als externe Komponenten der Einsatzumgebung. Es wurde über das zugrundeliegende PP hinausgehend die Möglichkeit „Alternativer Werksreset und Werksreset für Fail Safe“ ohne vorherige Authentisierung durchzuführen. FIA_UAU.5/AK Multiple authentication mechanisms Hierarchical to: No other components. Dependencies: No dependencies. 271 [assignment: list of TSF-mediated actions] 272 [assignment: list of TSF-mediated actions] Security Target secunet konnektor 2.1.0 secunet Seite 221 von 424 FIA_UAU.5.1/AK The TSF shall provide (1) [password based authentication mechanism]273 for administrator users, (2) TLS authentication with a pairing secret for eHKT [27], TUC_KON_050, (3) Asymmetric authentication of a smart card including CVC verification without negotiation of symmetric keys, (4) Mutual asymmetric authentication with a smart card with CVC verification and negotiation of symmetric keys for a secure messaging channel274 (5) Authentication of the Clientsystem based on a User-ID with 128 bit length according to RFC 4122 [107]. For activation of the comfort signature mode the User-ID has to differ from the last 1000 User-IDs used for activation275. to support user authentication. FIA_UAU.5.2/AK The TSF shall authenticate any user's claimed identity according to the following rules: (1) The TSF shall authenticate the user for all administration functions. (2) The TSF shall authenticate eHealth card terminals when establishing the TLS channel between the TSF and the eHealth card terminal. (3) The TSF shall support the authentication of a eGK (identified by the ICCSN) with its smart card certificate. (4) The TSF shall authenticate the HBA for a batch signature: a. as a QSEE, b. as a DTBS and PIN receiver before a signature creation process with negotiating symmetric keys for a secure messaging channel, c. constantly during the signature process with secure messaging. (5) The TSF shall authenticate the HBA before a single signature creation within the card session. (6) The TSF shall support mutual authentication in a remote PIN process: The gSMC-KT in the role of the PIN transmitter and the HBA (or the SMC-B) in the role of the PIN receiver276 . 273 [selection: password based authentication mechanism, [assignment: another authentication mechanism]] (The selection was assigned ion the PP) 274 [assignment: list of multiple authentication mechanisms] 275 Refinement: (5) Authentication of the Clientsystem… 276 [assignment: rules describing how the multiple authentication mechanisms provide authentication] Security Target secunet konnektor 2.1.0 Seite 222 von 424 secunet (7) The TSF shall authenticate the Clientsystem of the HBA-owner by means of the correct User-ID for a comfort signature (8) The TSF shall authenticate the HBA for a comfort signature: a. as a QSEE, b. as a DTBS and PIN receiver before an activation of the comfort signatur mode with negotiating symmetric keys for a secure messaging channel, c. constantly during the signature process with secure messaging.277 Anwendungshinweis 150: Eine Authentisierung einer KVK ist wegen der begrenzten Funktionalität der KVK nicht möglich. Die Card-to-Card-Authentisierung umfasst: (1) einseitige asymmetrische Authentisierung ohne Aushandlung eines Sessionkey, (2) einseitige symmetrische Authentisierung ohne Aushandlung eines Sessionkey, (3) gegenseitige asymmetrische Authentisierung ohne Aushandlung eines Sessionkey, (4) gegenseitige symmetrische Authentisierung ohne Aushandlung eines Sessionkey, (5) gegenseitige asymmetrische Authentisierung mit Aushandlung eines Sessionkey (Trusted Channel Schlüssel der Quellchipkarte und Secure Messaging Schlüssel der Zielchipkarte) und Aufbau eines Secure Messaging Kanals und (6) gegenseitige symmetrische Authentisierung mit Aushandlung eines Sessionkey (Trusted Channel Schlüssel der Quellchipkarte und Secure Messaging Schlüssel der Zielchipkarte) und Aufbau eines Secure Messaging Kanals. wobei der Konnektor nur die Varianten (1) und (5) umsetzt. Die Authentisierung von Chipkarten eGK, HBA und SMC-B gegenüber dem EVG schließt immer ein (a) die Prüfung des CVC der Chipkarte, aus der die Authentisierungsreferenzdaten (öffentlicher Schlüssel) und die Rolle der Chipkarte hervorgeht, und (b) das Kommando INTERNAL AUTHENTICATE an diese Chipkarte, deren Returncode durch den EVG geprüft wird. Die CVC für die Authentisierung sind für die a) die eGK in EF.C.eGK.AUT_CVC, b) den HBA in EF.C.HPC.AUTR_CVC und EF.C.HPC.AUTD_SUK_CVC, c) die gSMC-KT in EF.C.SMC.AUTD_RPS_CVC.E256 bzw. EF.C.SMC.AUTD_RPS_CVC.E384, d) die SMC-B in EF.C.SMC. AUTD_RPE_CVC.E256 enthalten. Die Unterstützung der gegenseitigen Authentisierung der gSMC-KT als PIN-Sender und des HBA bzw. der SMC-B als PIN-Empfänger in einem Remote-PIN-Prozess umfasst die Steuerung und die Kontrolle der gegenseitigen Authentisierung zur Aushandlung und Nutzung des Secure Messaging Kanals zwischen gSMC-KT und HBA bzw. SMC-B. Das Kommando INTERNAL AUTHENTICATE kann dabei im Rahmen einer einseitigen oder gegenseitigen Authentisierung ausgeführt werden. Nur die Authentisierung durch Secure Messaging authentisiert über die unmittelbare Authentisierung durch INTERNAL AUTHENTICATE hinaus 277 Refinement: (7) + (8) Security Target secunet konnektor 2.1.0 secunet Seite 223 von 424 (fortgesetzt) jedes Kommando und jede Antwort der Chipkarte. Im Fall der Einfachsignatur mit dem HBA im SE#1 ist der HBA unter Kontrolle des Benutzers lokal in PIN-Terminal gesteckt. Wenn die PIN-Eingabe und die Erstellung der digitalen Signatur zeitlich unmittelbar aufeinander folgen, genügt für diese Einfachsignatur eine einmalige (einseitige, symmetrische) Authentisierung des HBA als QSEE. FIA_API.1/AK Authentication Proof of Identity Hierarchical to: No other components. Dependencies: No dependencies. FIA_API.1.1/AK The TSF shall provide a card-to-card authentication mechanism with key derivation for secure messaging278 to prove the identity of the “SAK”279 . Anwendungshinweis 151: Diese SFR ergibt sich aus der TR-03114 [21] und den Zugriffsbedingungen des HBA, die für eine Stapelsignatur die Authentisierung der Identität „SAK“ gegenüber dem HBA und die Übermittlung der DTBS mit Secure Messaging erfordern. Der EVG muss dafür über ein CVC mit der CHAT für die Identität „SAK“ (vergl. C.SAK.AUTD_CVC in [33]) und die gSMC-K über den dazugehörigen privaten Schlüssel PrK.SAK.AUTD_CVC verfügen. Für eine Beschreibung des externen Verhaltens des EVG im Authentisierungsprotokoll mit dem HBA wird auf [21], [31], [35] und [33] verwiesen. Bei Aktivierung der Komfortsignatur ist die Authentisierung der Identität „SAK“ gegenüber dem HBA, sowie bei der Durchführung von Komfortsignaturen die Übermittlung der DTBS mit Secure Messaging erforderlich (A_19258). 6.3.3. Klasse FDP: Schutz der Benutzerdaten 6.3.3.1. Zugriffskontrolldienst Die Bezeichnungen TAB_KON_507 bis TAB_KON_514 beziehen sich auf Tabellen im Abschnitt 9.1 der vorliegenden Sicherheitsvorgaben, bzw. des zugrundeliegenden Schutzprofils. FDP_ACC.1/AK.Infomod Subset access control / Informationsmodell Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.1.1/AK.Infomod The TSF shall enforce the Infomodell-SFP280 on the subject S_Clientsystem, the objects as in TAB_KON_507, and the operation: 278 [assignment: authentication mechanism] 279 [assignment: identity or role] 280 [assignment: access control SFP] Security Target secunet konnektor 2.1.0 Seite 224 von 424 secunet  usage of the resource (the object) in a technical use case 281 . FDP_ACF.1/AK.Infomod Security attribute based access control / Informationsmodell Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation FDP_ACF.1.1/AK.Infomod The TSF shall enforce the Infomodell-SFP282 to objects based on the following: the subject S_Clientsystem with its associated security attributes defined in Tabelle 14, and the objects with their associated security attributes defined in TAB_KON_508 and TAB_KON_509283 . FDP_ACF.1.2/AK.Infomod The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: TAB_KON_511, TAB_KON_512, TAB_KON_513 and TAB_KON_514.284 FDP_ACF.1.3/AK.Infomod The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none285 . FDP_ACF.1.4/AK.Infomod The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none286 . FMT_MSA.1/AK.Infomod Management of security attributes / Informationsmodell Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles 281 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 282 [assignment: access control SFP] 283 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes] 284 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects]. 285 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] 286 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] Security Target secunet konnektor 2.1.0 secunet Seite 225 von 424 FMT_SMF.1 Specification of Management Functions. FMT_MSA.1.1/AK.Infomod The TSF shall enforce the Infomodell-SFP287 to restrict the ability to modify, delete, create288 the security attributes persistent entities and entity-connections defined in TAB_KON_507, TAB_KON_508, TAB_KON_509 according to the contraints in TAB_KON_510289 to S_Administrator290 . FMT_MSA.3/AK.Infomod Static attribute initialisation / Informationsmodell Hierarchical to: No other components. Dependencies: FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1/AK.Infomod The TSF shall enforce the Infomodell-SFP291 to provide [restrictive] 292 default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2/AK.Infomod The TSF shall allow the [no role]293 to specify alternative initial values to override the default values when an object or information is created. 6.3.3.2. Kartenterminaldienst FDP_ACC.1/AK.eHKT Subset access control / Kartenterminaldienst Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control 287 [assignment: access control SFP(s), information flow control SFP(s)] 288 [selection: change_default, , query, modify, delete, [assignment: other operations]] 289 [assignment: list of security attributes] 290 [assignment: the authorised identified roles] 291 [assignment: access control SFP, information flow control SFP] 292 [selection, choose one of: restrictive, permissive, [assignment: other property]] 293 [Selection: S_Administrator, no role] (the selection was assigned in the PP) Security Target secunet konnektor 2.1.0 Seite 226 von 424 secunet FDP_ACC.1.1/AK.eHKT The TSF shall enforce the Kartenterminaldienst-SFP294 on subjects: (1) S_Kartenterminaldienst, (2) S_Chipkartendienst, (3) S_Signaturdienst, (4) S_Verschlüsselungsdienst, (5) S_AK, (6) S_eHKT, (7) S_Fachmodul, (8) S_Clientsystem; objects: (1) eHealth-Kartenterminal, (2) TLS-Kanal, (3) SICCT-Kommando, (4) Antwort auf SICCT-Kommando, (5) Eingeschränkter Text; operations: (1) TLS-Kanal aufbauen, (2) TLS-Kanal abbauen, (3) Senden eines SICCT-Kommando anfordern, (4) SICCT-Kommando senden. (5) Antwort auf SICCT-Kommando empfangen; 295 . Operation Beschreibung Anmerkung TLS-Kanal aufbauen Aufbau des TLS-Kanals gemäß FTP_ITC.1/AK.eHKT mit gegenseitiger Authentisierung gemäß FIA_UAU.5/AK, Vereinbarung und Nutzung symmetrischer Schlüssel für Verschlüsselung AES und HMAC Die TLS-Kanäle sind in [27] und [38] beschrieben. Die gesamte Kommunikation des Konnektors mit den eHealth-Kartenterminals erfolgt über die TLS-Kanäle des Kartenterminaldienstes. 294 [assignment: access control SFP] 295 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] Security Target secunet konnektor 2.1.0 secunet Seite 227 von 424 Operation Beschreibung Anmerkung FCS_COP.1/NK.HMA C. TLS-Kanal abbauen Freigabe der Resourcen des TLS-Kanals gemäß FDP_RIP.1/AK und Löschen der symmetrischen Schlüssel gemäß FCS_CKM.4/AK Die eHealth-Kartenterminals setzen die gesteckten Chipkarten bei Abbau des TLS-Kanals zurück. Senden eines SICCT- Kommando anfordern Übergabe eines SICCT- Kommandos zur Übermittlung an eHealth- Kartenterminals SICCT-Kommando senden Übermittlung eines SICCT-Kommandos gemäß [42] und [38]über den TLS-Kanal an ein eHealth- Kartenterminal,das durch den Chipkartendienst selbst erzeugt oder an den Kartenterminaldienst übergeben wurde Die SICCT-Kommandos dienen [38] [42] - der Steuerung des eHealth- Kartenterminals, insbesondere zur Kommunikation mit dem Konnektor, Kom- mandoabarbeitung und Konfiguration der eHealth- Kartenterminals, - dem Zugriff auf die sichere Anzeige (Display und Anzeige des gesicherten PIN-Modus), und die Tastatur sowie ggf. dem Tongeber, - der Kontrolle, Aktivierung, Deaktivierung und Status- abfrage des elektrischen Zustands von Chipkarten- kontaktiereinheiten und der Kommunikation mit Chipkarten in den Chipkartenslots, und - die Auslösung der Prozesse zur PIN-Eingabe und dem PIN- Wechsel im gesicherten Modus. Antwort auf SICCT- Kommando empfangen Empfangen der Antworten auf ein selbst gebildetes oder übergebenes SICCT- Kommando Tabelle 17: Operationen zur Zugriffskontrolle des Chipkartendienstes Security Target secunet konnektor 2.1.0 Seite 228 von 424 secunet FDP_ACF.1/AK.eHKT Security attribute based access control / Kartenterminaldienst Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation FDP_ACF.1.1/AK.eHKT The TSF shall enforce the Kartenterminaldienst-SFP296 to objects based on the following: list of subjects, objects and security attributes: subjects: (1) S_Kartenterminaldienst, (2) S_Chipkartendienst, (3) S_Signaturdienst, (4) S_Verschlüsselungsdienst, (5) S_AK with the security attributes: a. “Aufrufender: Clientsystem”, b. “Aufrufender: Fachmodul” (6) S_eHKT, (7) S_Fachmodul, (8) S_Clientsystem; objects: (1) eHealth-Kartenterminal with security attribute „Arbeitsplatz“, (2) TLS-Kanal, (3) SICCT-Kommando with security attribute „Typ des SICCT- Kommandos“ , (4) Antwort auf SICCT-Kommando 297 . FDP_ACF.1.2/AK.eHKT The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: (1) Only the Kartenterminaldienst may establish TLS-Kanäle to paired eHealth-Kartenterminals with mutual authentication. (2) Only the Kartenterminaldienst may shutdown TLS-Kanäle to eHealth-Kartenterminals. This is only allowed in case that communication errors have been detected. 296 [assignment: access control SFP] 297 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes] Security Target secunet konnektor 2.1.0 secunet Seite 229 von 424 (3) Only the Kartenterminaldienst may send SICCT-Kommandos and receive the associated reponses, which are used to control the eHealth-Kartenterminals (eHKT-Steuerungskommando). (4) Only the Kartenterminaldienst and the Chipkartendienst may send SICCT-Kommandos and receive the associated reponses, which are used to access the secure display and the PIN pad of the eHealth-Kartenterminals (Benutzerkommuikations- kommando). (5) The subject S_AK, calling subject = Fachmodul may - pass SICCT-Kommandos to the Kartenterminaldienst which are used to display eingeschränkten Text on a identified eHealth-Kartenterminal and - receive the associated reponses to the SICCT-Kommandos from the Chipkartendienst. (6) Only the Chipkartendienst, the Signaturdienst and the Verschlüsselungsdienst may send SICCT-Kommandos via the TLS-Kanäle of the Kartenterminaldienst and receive the associated reponses, which are used to access inserted smart cards (Chipkartenkommando). (7) Only the Chipkartendienst may send SICCT-Kommandos and receive the associated reponses, which are used for PIN entry, PUK entry and PIN change use cases in secure mode at the eHealth-Kartenterminals (PIN-Prozesskommando). (8) Fachmodule and Clientsysteme may register themselves for the events „smart card inserted“ and „smart card removed“, to be notified if the events occur. . 298 FDP_ACF.1.3/AK.eHKT The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: The S_Kartenterminal- dienst may establish a communication channel to an unpaired eHealth-Kartenterminal for the purpose of setup and pairing.299 FDP_ACF.1.4/AK.eHKT The TSF shall explicitly deny access of subjects to objects based on the following additional rules: (1) Only the subject S_Chipkartendienst may send a SICCT- Kommando via the TLS-Kanal of the TOE to the eHealth- Kartenterminal, which is used to display the messages „Signatur PIN“, „Signatur PUK“, „Freigabe PIN“, „Praxis PIN“, „Freigabe PUK“ oder „Praxis PUK“ at the eHealth- Kartenterminals. 298 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects]. 299 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] Security Target secunet konnektor 2.1.0 Seite 230 von 424 secunet (2) [none] 300 301 Die Zugriffskontrolle für die PIN-Authentisierung innerhalb eines logischen Kanals wird durch FDP_ACC.1/AK.PIN und FDP_ACF.1/AK.PIN beschrieben. FDP_UCT.1/AK.TLS Basic data exchange confidentiality Hierarchical to: No other components. Dependencies: [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FDP_UCT.1.1/AK.TLS The TSF shall enforce the Kartenterminaldienst-SFP302 to transmit and receive303 user data objects in a manner protected from unauthorised disclosure. FDP_UIT.1/AK.TLS Data exchange integrity Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] FDP_UIT.1.1/AK.TLS The TSF shall enforce the Kartenterminaldienst-SFP304 to transmit and receive305 user data in a manner protected from modification, deletion, insertion, replay306 errors. FDP_UIT.1.2/AK.TLS The TSF shall be able to determine on receipt of user data, whether modification, deletion, insertion, replay307 has occurred. FMT_MTD.1/AK.eHKT_Abf Management of TSF data / eHealth-Kartenterminal Abfrage Hierarchical to: No other components. 300 [assignment: additional rules, based on security attributes, that explicitly deny access of subjects to objects] 301 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] 302 [assignment: access control SFP(s) and/or information flow control SFP(s)] 303 [selection: transmit, receive] 304 [assignment: access control SFP(s) and/or information flow control SFP(s)] 305 [selection: transmit, receive] 306 [selection: modification, deletion, insertion, replay] 307 [selection: modification, deletion, insertion, replay] Security Target secunet konnektor 2.1.0 secunet Seite 231 von 424 Dependencies: FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions FMT_MTD.1.1/AK.eHKT_Abf The TSF shall restrict the ability to query and export308 the Arbeitsplatzkonfigurationsdaten: (1) Name eines zugelassenen eHealth-Kartenterminals, (2) Statische IP-Adresse eines zugelassenen eHealth- Kartenterminals, (3) Konfiguration des SICCT-Kommandointerpreter Ports eines eHealth-Kartenterminals, (4) Authentisierungsreferenzdaten mit Identität und Zertifikat der zugelassenen eHealth-Kartenterminals, (5) Zuordnung eines eHealth-Kartenterminals zum Arbeitsplatz, (6) Export von eHealth-Kartenterminal-Informationen .309 to S_AK and S_Administrator310 . Pairing-Geheimnisse dürfen nur unter Wahrung der Vertraulichkeit exportiert und dürfen nicht abgefragt werden. FMT_MTD.1/AK.eHKT_Mod Management of TSF data / eHealth-Kartenterminal Modifikation Hierarchical to: No other components. Dependencies: FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions FMT_MTD.1.1/AK.eHKT_Mod The TSF shall restrict the ability to modify, delete and import311 the Arbeitsplatzkonfigurationsdaten: (1) Name eines zugelassenen eHealth-Kartenterminals, (2) Statische IP-Adresse eines zugelassenen eHealth- Kartenterminals, (3) Konfiguration des SICCT-Kommandointerpreter Ports eines eHealth-Kartenterminals, 308 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 309 [assignment: list of TSF data] 310 [assignment: the authorised identified roles] 311 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] Security Target secunet konnektor 2.1.0 Seite 232 von 424 secunet (4) Authentisierungsreferenzdaten mit Identität und Zertifikat der zugelassenen eHealth-Kartenterminals, (5) Zuordnung eines eHealth-Kartenterminals zum Arbeitsplatz (6) Import von eHealth-Kartenterminal-Informationen nach Anzeige und Bestätigung .312 to S_Administrator313 . Anwendungshinweis 152: Die Iteration differenziert die Zugriffsbedingungen für das Management der Konfigurationsdaten nach Zugriffsarten und Rollen. Das Management der Kartenterminals ist in [27] beschrieben. FMT_MTD.1/eHKT_Abf definiert Sicherheitsanforderungen für den Export und FMT_MTD.1/eHKT_Mod für den Import von eHealth-Kartenterminal-Informationen wie in der Spezifikation Konnektor [27], Kap 4.3.3, beschrieben. 6.3.3.3. Chipkartendienst FDP_ACC.1/AK.KD Subset access control / Chipkartendienst Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.1.1/AK.KD The TSF shall enforce the Chipkartendienst-SFP314 on subjects: (1) S_Chipkartendienst, (2) S_Signaturdienst, (3) S_Verschlüsselungsdienst, (4) S_AK, (5) S_Fachmodul, (6) S_Clientsystem; objects: (1) Chipkarte, (2) Logischer Kanal einer Chipkarte, (3) SICCT-Kommando with security attribute „Chipkartenkommando”; operations: (1) Kartenhandle ausgeben, (2) logischen Kanal anfordern, (3) logischen Kanal öffnen, (4) logischen Kanal schließen, 312 [assignment: list of TSF data] 313 [assignment: the authorised identified roles] 314 [assignment: access control SFP] Security Target secunet konnektor 2.1.0 secunet Seite 233 von 424 (5) die Card-to-card-Authentisierung anfordern, (6) die Card-to-card-Authentisierung durchführen, (7) Digitale Signatur erstellen, (8) Chiffrate entschlüsseln, (9) auf Kartenobjekte zugreifen, (10) Chipkartenkommando übertragen und Antwort empfangen, (11) Benutzerauthentisierung anfordern .315 Operation Beschreibung Anmerkung Kartenhandle ausgeben Für eine neu gesteckte Chipkarte wird ein eindeutiges Kartenhandle gebildet und an den EVG ausgegeben. Die mit dem Kartenhandle verknüpften Informationen können folgende Sicherheits- attribute der Chipkarte enthalten: Identität des Kartenslots, Identität des eHealth-Kartenterminals, Identität des Arbeitsplatzes, dem das eHealth- Kartenterminal zugeordnet ist. Logischen Kanal anfordern Für eine mit dem Kartenhandle identifizierte Chipkarte wird ein logischer Kanal angefordert. Der EVG kann mit einem Kartenhandle einen neuen logischen Kanal anfordern. Logischen Kanal öffnen Für eine mit dem Kartenhandle identifizierte Chipkarte wird ein logischer Kanal 1, 2 oder 3 geöffnet (Chipkartenkommando MANAGE CHANNEL). Der EVG kann mit einem Kartenhandle einen neuen logischen Kanal anfordern. Logichen Kanal schließen Wenn der identifizierte logische Kanal der Kanal 0 ist, so ist der Sicherheitszustand dieses logischen Kanals zurückzusetzen. Wenn der identifizierte logische Kanal ein Kanal 1, 2 oder 3 ist, so ist der logische Kanal zu schließen (Chip kartenkommando MANAGE CHANNEL). 315 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] Security Target secunet konnektor 2.1.0 Seite 234 von 424 secunet Card-to-card- Authentisierung anfordern Der EVG oder ein EVG-interner Dienst fordert die Card-to-Card- Authentisierung für zwei logische Kanäle verschiedener Chipkarten an Card-to-card- Authentisierung durchführen Der EVG steuert die Card-to-card- Authentisierung für zwei logische Kanäle verschiedener Chipkarten. Digitale Signatur erstellen Erstellen digitaler Signturen mit privaten Signaturschlüsseln und den Chipkartenkommandos MANAGE SECURITY ENVIRONMENT und PSO: COMPUTE DIGITAL SIGNATURE. Die Zugriffsregeln der Chipkarten entscheiden, ob das Kommando PSO: COMPUTE DIGITAL SIGNATURE für den kryptographischen Schlüssel zulässig ist. Chiffrate entschlüsseln Entschlüsseln von Chiffraten mit privaten Entschlüsselungsschlüsseln und den Chipkartenkommandos MANAGE SECURITY ENVIRONMENT und PSO DECIPHER. Die Zugriffsregeln der Chipkarten entscheiden, ob das Kommando PSO DECIPHER für den kryptographischen Schlüssel zulässig ist. Auf Kartenobjekte zugreifen Zugriff auf Datenobjekte der Chipkarten. Es wird zwischen lesendem und schreibenden Zugriff auf eine Datei bzw. Record, der Suche und dem Hinzufügen von Records unterschieden. Die Chipkarten außer KVK verfügen über eine eigene Zugriffskontrolle auf Kartenobjekte. Chipkarten- kommando übertragen und Antwort empfangen Übertragung von Chipkarten- kommandos und das Empfangen von Antworten innerhalb von SICCT- Kommandos des Kartenterminal- dienstes Benutzerauthentisie rung anfordern Anforderung von Benutzerinteraktionen zur PIN- Authentisierung, PIN-Änderung, PIN-Entsperren, der Freischaltung einer SM-B durch einen HBA und die Abfrage des PIN-Status auslösen und die Rückantwort der Chipkarten zurückerhalten. Tabelle 18: Operationen zur Zugriffskontrolle des Chipkartendienstes Security Target secunet konnektor 2.1.0 secunet Seite 235 von 424 FDP_ACF.1/AK.KD Security attribute based access control / Chipkartendienst Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation FDP_ACF.1.1/AK.KD The TSF shall enforce the Chipkartendienst-SFP316 to objects based on the following: list of subjects, objects and security attributes: subjects: (1) S_Chipkartendienst, (2) S_Signaturdienst, (3) S_Verschlüsselungsdienst, (4) S_AK, (5) S_Fachmodul, (6) S_Clientsystem objects: (1) Chipkarte with security attributes: (a)„Kartentyp“, (b)„Kartenhandle“, (2) Logischer Kanal einer Chipkarte with security attribute „Sicherheitszustand“, (3) SICCT-Kommando with security attribute „Chipkartenkommando” .317 FDP_ACF.1.2/AK.KD The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: (1) Der S_Chipkartendienst erzeugt für jede neu gesteckte Chipkarte ein Kartenhandle und übergibt für identifizierte eGK, SMC-B und HBA den im gespeicherten X.509 angegeben Namen des Kartenhalters an das Subjekt S_AK. (2) Die Subjekte S_AK und S_Fachmodul dürfen einen neu zuöffnenden logischen Kanal einer mit dem Kartenhandle identifizierten Chipkarte mit ggf. identifizierten User-ID, Clientsystem-ID, Arbeitsplatz anfordern. Wenn die übergebenen Identitäten mit der 316 [assignment: access control SFP] 317 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes] Security Target secunet konnektor 2.1.0 Seite 236 von 424 secunet Arbeitsplatzkonfiguration konsistent sind und die identifizierte Chipkarte einen logischen Kanal bereitstellt, öffnet der Chipkartendienst einen solchen logischen Kanal und erlaubt den Zugriff auf die Chipkarte, wenn dem keine andere Zugriffsregel widerspricht (3) Der Signaturdienst und der Verschlüsselungsdienst dürfen einen neu zu öffnenden logischen Kanal einer mit dem Kartenhandle identifizierten Chipkarte anfordern. Wenn die die identifizierte Chipkarte einen logischen Kanal bereitstellt, öffnet der Chipkartendienst einen solchen logischen Kanal. (4) Nur die Subjekte S_AK, S_Signaturdienst und S_Fachmodul dürfen die Card-to-Card- Authentisierung zwischen zwei logischen Kanäle verschiedener Chipkarten anfordern. Nur das Subjekt Chipkartendienst darf die Card-to-Card- Authentisierung für einen logische Kanäle durchführen. (5) Nur der Signaturdienst darf mit den Chipkarten digitale Signaturen für QES und non-QES mit den Kommandos MANAGE SECURITY ENVIRONMENT und PSO COMPUTE DIGITAL SIGNATURE erzeugen. (6) Nur der Verschlüsselungsdienst darf mit den Chipkarten Kommandos MANAGE SECURITY ENVIRONMENT und PSO DECIPHER auf Chipkarten zugreifen. (7) Das Subjekt S_AK darf mit den Chipkartenkommandos MANAGE SECURITY ENVIRONMENT, INTERNAL AUTHENTICATE, PSO COMPUTE DIGITAL SIGNATURE und GENERATE ASYMMETRIC KEY PAIR P1=‘81’ auf den Schlüssel PrK.HCI.AUT zugreifen, wenn der Zugriff zu einem logischen Kanal einer SM-B gehört (8) Nur der Chipkartendienst, der Signaturdienst, und der Verschlüsselungsdienst dürfen über einen logischen Kanal zu einer Chipkarte die Chipkartenkommandos MANAGE CHANNEL, MANAGE SECURITY ENVIRONMENT, EXTERNAL AUTHENTICATE, GENERAL AUTHENTICATE, INTERNAL AUTHENTICATE und MUTUAL AUTHENTICATE absetzen. (9) Die Subjekte S_AK und S_Fachmodul, dürfen die Schließung des vom jeweiligen Subjekt angeforderten Security Target secunet konnektor 2.1.0 secunet Seite 237 von 424 logischen Kanals anfordern. Der Chipkartendienst setzt den Sicherheitsstatus des logischen Kanals zurück. (10) Der Chipkartendienst löscht das Kartenhandle, wenn die betreffende Chipkarte gezogen wird. (11) Fachmodule und Clientsysteme können sich für die Ereignisse „CARD INSERTED“, „CARD REMOVED“, „CARD PIN VERIFY_STARTED“, „CARD PIN VERIFY_FINISHED“, „CARD PIN CHANGE_STARTED“, „CARD PIN CHANGE_FINISHED“, "CARD PIN ENABLE_STARTED", "CARD PIN ENABLE_FINISHED", "CARD PIN DISABLE_STARTED" und "CARD PIN DISABLE_FINISHED" registrieren, um bei Eintritt der Ereignisse informiert zu werden. (12) Das Clientssystem darf eine Benutzerauthentisierung anfordern.318 FDP_ACF.1.3/AK.KD The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none319 FDP_ACF.1.4/AK.KD The TSF shall explicitly deny access of subjects to objects based on the following additional rules: (1) Kein Subjekt darf, wenn nicht ausdrücklich durch die Regeln in FDP_ACF.1.2 erlaubt, auf private und symmetrische Schlüssel der Chipkarten mit den Chipkartenkommandos MANAGE CHANNEL, MANAGE SECURITY ENVIRONMENT, EXTERNAL AUTHENTICATE, GENERAL AUTHENTICATE, INTERNAL AUTHENTICATE oder MUTUAL AUTHENTICATE zugreifen. (2) Kein Subjekt darf auf DF.KT einer gSMC-KT zugreifen. (3) Der EVG verhindert schreibenden Zugriff auf Kartenobjekte der KVK. (4) [none] 320 .321 318 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects]. 319 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] 320 [assignment: additional rules, based on security attributes, that explicitly deny access of subjects to objects] 321 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] Security Target secunet konnektor 2.1.0 Seite 238 von 424 secunet Anwendungshinweis 153: Die Zugriffskontrolle für die PIN-Authentisierung innerhalb eines logischen Kanals wird durch FDP_ACC.1/AK.PIN und FDP_ACF.1/AK.PIN beschrieben. Die für die Fachmodule zulässigen Kommandos sind in der Spezifikation Konnektor [27], Kap. 4.1.5.4, definiert. FDP_ACC.1/AK.PIN Subset access control / PIN Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.1.1/AK.PIN The TSF shall enforce the VAD-SFP322 on subjects (1) S_Chipkartendienst, (2) S_Signaturdienst, (3) S_Benutzer_Clientsystem, (4) PIN-Terminal, (5) S_eHKT, (6) S_eGK, (7) S_HBA, (8) S_HBAx, (9) S_gSMC-KT (10) S_SMC-B, objects: (1) Authentisierungsverifikationsdaten (VAD) as plaintext, (2) Authentisierungsverifikationsdaten (VAD) as ciphertext, (3) SICCT-Kommando operations: (1) lokale PIN-Eingabe anfordern, (2) lokale PIN-Eingabe durchführen, (3) entfernte PIN-Eingabe anfordern, (4) entfernte PIN-Eingabe durchführen, (5) VAD an Chipkarten senden, (6) VAD als Klartext verarbeiten, (7) VAD als Geheimtext verarbeiten, (8) VAD im Geheimtext ausgeben, (9) SICCT-Kommandos übertragen .323 322 [assignment: access control SFP] 323 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] Security Target secunet konnektor 2.1.0 secunet Seite 239 von 424 Operation Beschreibung Anmerkung Lokale PIN-Eingabe anfordern Anforderung der lokalen PIN- Eingabe unter Angabe der Chipkarte, der Funktion PIN- Prüfung, PIN-Wechsel oder PIN- Entsperren und der zu verwendende PIN- bzw. PUK- Referenz.. Der Begriff PIN-Eingabe kann die Eingabe der PIN, einer neuen Pin oder der PUK erfordern. Lokale PIN-Eingabe durchführen Steuern der lokalen PIN-Eingabe mit dem sicheren PIN-Modus des PIN-Terminals für eine gesteckte Chipkarte, der zu verwendende PIN-Referenz und der Funktion gemäß der Anforderung. Die an den äußeren Schnittstellen sichtbaren Prozesse der lokalen PIN- Eingabe sind in [27], Kap. 4.1.5, beschrieben. Für HBA-VK wird nur die lokale PIN-Eingabe unterstützt. Entfernte PIN-Eingabe anfordern Anforderung der entfernten PIN- Eingabe unter Angabe des Arbeitsplatzes, der zu verwendenden Chipkarte, der Funktion PIN-Prüfung, PIN- Wechsel oder Anwendung der PUK und der zu verwendende PIN- bzw. PUK-Referenz. Der Begriff PIN-Eingabe kann die Eingabe der PIN, einer neuen PIN oder der PUK erfordern. Entfernte PIN-Eingabe durchführen Steuern der entfernten PIN- Eingabe mit dem sicheren PIN- Modus des PIN-Terminals mit einer dort gesteckten gSMC-KT für eine Chipkarte in einem entfernten Chipkarten-Terminal, der zu verwendende PIN- Referenz, der Jobnummer zur Identifizierung des Signaturauftrags und des zu benutzenden PIN- Kartenterminals und der Funktion gemäß der Anforderung. Die an den äußeren Schnittstellen sichtbaren Prozesse der entfernten PIN-Eingabe sind in [27], Kap. 4.1.5, und [21] beschrieben. Die entfernte PIN-Eingabe wird durch HBA-VK (HBAx mit dem Sicherheitsattribut HBA- VK) nicht unterstützt. VAD an Chipkarte senden Senden von SICCT-Kommandos an eHealth-Kartenterminals die VAD in den Chipkartenkommandos VERIFY, CHANGE REFERENCE DATA, DISABLE VERIFICATION REQUIREMENT, ENABLE Security Target secunet konnektor 2.1.0 Seite 240 von 424 secunet VERIFICATION REQUIREMENT und RESET RETRY COUNTER enthalten. VAD im Klartext verarbeiten Lesen, Verarbeiten oder Ausgeben von unverschlüsselten VAD VAD im Geheimtext verarbeiten Lesen, Verarbeiten oder Ausgeben von verschlüsselten VAD. VAD im Geheimtext ausgeben Ausgeben von verschlüsselten VAD über die LAN-Schnittstelle. SICCT-Kommandos übertragen Ein Subjekt sendet ein selbst gebildetes order entgegengenommenes (z. B. vom EVG zur Übertragung übergebenes) SICCT-Kommando an ein eHealth-Kartenterminal und verarbeitet die Antwort selbst oder gibt die Antwort an den Aufrufenden zurück. Die SICCT-Kommandos sind in [42] und [38] beschrieben. Tabelle 19: Operationen zur PIN-Eingabe FDP_ACF.1/AK.PIN Security attribute based access control / PIN Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation FDP_ACF.1.1/AK.PIN The TSF shall enforce the VAD-SFP324 to objects based on the following: list of subjects, objects and security attributes: subjects: (1) S_Chipkartendienst, (2) S_Signaturdienst, (3) S_Fachmodul, (4) S_AK, (5) S_Benutzer_Clientsystem with security attribute Authorisierungsstatus, (6) PIN-Terminal with security attribute Authorisierungsstatus, (7) S_eHKT with security attribute Authorisierungsstatus, 324 [assignment: access control SFP] Security Target secunet konnektor 2.1.0 secunet Seite 241 von 424 (8) S_eGK mit dem Sicherheitsattribut CVC mit CHA, bzw. CHAT eGK, (9) S_HBA mit dem Sicherheitsattribut CVC mit CHAT “PIN- Empfänger”, (10) S_HBAx mit Sicherheitsattribut „HBA“ bzw. „HBA-VK“, (11) S_SMC-B mit dem Sicherheitsattribut CVC mit CHAT “PIN- Empfänger”; objects: (1) Authentisierungsverifikationsdaten (VAD) as plaintext, (2) Authentisierungsverifikationsdaten (VAD) as ciphertext, (3) SICCT-Kommando .325 FDP_ACF.1.2/AK.PIN The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: (1) Das Subjekt S_AK, Fachmodule und das Clientsystem dürfen die lokale PIN-Eingabe und die entfernte PIN-Eingabe mit PIN- Referenz mit Ausnahme der Signatur-PIN und der Signatur-PUK für einen logischen Kanal einer Chipkarte beim Chipkartendienst anfordern. (2) Das Subjekt „identifizierte Benutzer des Clientsystems“ darf für die Signatur-PIN die lokale und entfernte PIN-Eingabe an seinem Arbeitsplatz für eine authentisierte Chipkarte zur PIN- Prüfung, zum PIN-Wechsel und zum Entsperren der PIN mit einer PUK anfordern. (3) Das Subjekt Chipkartendienst darf die lokale PIN-Eingabe an authentisierten PIN-Terminal für jede identifizierte Chipkarte für alle PIN und PUK mit Ausnahme der Signatur-PIN und der Signatur-PUK durchführen. (4) Das Subjekt Chipkartendienst darf die entfernte PIN-Eingabe an authentisierten PIN-Terminal mit einer authentisierten gSMC- KT als PIN-Sender für eine als PIN-Empfänger authentisierten HBA oder als PIN-Empfänger authentisierte SMC-B in einem authentisierten Chipkarten-Terminal für alle PIN und PUK mit Ausnahme der Signatur-PIN und der Signatur-PUK durchführen. (5) Das Subjekt Signaturdienst darf die lokale PIN-Eingabe mit Signatur-PIN und Signatur-PUK am authentisierten PIN- Terminal für einen HBAx oder eine SMC-B für die PIN-Prüfung, den PIN-Wechsel oder PIN-Entsperren durchführen. 325 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes] Security Target secunet konnektor 2.1.0 Seite 242 von 424 secunet (6) Das Subjekt Signaturdienst darf die entfernte PIN-Eingabe mit der Signatur-PIN und der Signatur-PUK an authentisierten PIN- Terminals mit einer authentisierten gSMC-KT als PIN-Sender für eine als PIN-Empfänger authentisierten HBA oder als PIN- Empfänger authentisierte SMC-B in einem authentisierten Chipkarten-Terminal für die PIN-Prüfung, den PIN-Wechsel oder PIN-Entsperren durchführen. (7) Die TSF steuert die PIN-Eingabe, so dass (a) wenn das PIN-Terminal und das Chipkarten-Terminal verschieden sind, (i) ein gesicherter Kanal zwischen der gSMC-KT als PIN- Sender im PIN-Terminal und der Chipkarte als PIN- Empfänger im Chipkartenterminal vor der PIN-Eingabe aufgebaut wird, (ii) das PIN-Terminal die eingegebene VAD im Klartext nur zum Verschlüsseln an die als PIN-Sender authentisierte gSMC-KT übergibt und nur die verschlüsselte VAD innerhalb des TLS-Kanals an den Konnektor übermittelt, (iii)das Chipkartenterminal die verschlüsselte VAD nur für die PIN-Prüfung, das PIN-Entsperren oder den PIN-Wechsel dem als PIN-Empfänger authentisierten Heilberufsausweis oder der als PIN-Empfänger authentisierten SMC-B übergibt; (b) wenn das PIN-Terminal und das Chipkarten-Terminal identisch sind, das PIN-Terminal die eingegebene VAD im Klartext nur für die PIN-Prüfung, PIN-Aktivierung, PIN- Deaktivierung, das PIN-Entsperren oder den PIN-Wechsel an die authentisierte eGK, den Heilberufsausweis und die SMC-B übergibt, (c) die PIN-Eingabe am PIN-Terminal nur im gesicherten Mode erfolgt.326 FDP_ACF.1.3/AK.PIN The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [none] 327 FDP_ACF.1.4/AK.PIN The TSF shall explicitly deny access of subjects to objects based on the following additional rules: (1) Kein Subjekt außer dem Chipkartendienst darf über den TLS- Kanal des EVG zu den eHealth-Kartenterminals SICCT- Kommandos mit dem Chipkartenkommando VERIFY, RESET RETRY COUNTER, DISABLE VERIFICATION 326 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects]. 327 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] Security Target secunet konnektor 2.1.0 secunet Seite 243 von 424 REQUIREMENT, ENABLE VERIFICATION REQUIREMENT oder CHANGE REFERENCE DATA absetzen. (2) Kein Subjekt außer S_Fachmodul darf eine PIN-Eingabe zur PIN-Prüfung für eine eGK bei S_Chipkartendienst anfordern (3) [none] 328 329 Die durch FDP_ACC.1/AK.PIN und FDP_ACF.1/AK.PIN verwendeten Operationen sind in Tabelle 19 definiert. Anwendungshinweis 154: Regel (2) in FDP_ACF.1.4/AK.PIN ist auch erfüllt, wenn der Aufruf nur indirekt über das Fachmodul erfolgt, also der direkte Aufruf bspw. vom Verschlüsselungs- oder Signaturdienst erfolgt, der Ursprung des Anwendungsfalls jedoch ein Fachmodul ist. Insbesondere die Abfrage der PIN der eGK über die Außenschnittstelle VerifyPin (vgl. [27]) durch das Clientsystem ist nicht gestattet. 6.3.3.4. Signaturdienst FIA_SOS.2/AK.Jobnummer TSF Generation of secrets / Jobnummer Hierarchical to: No other components. Dependencies: No dependencies. FIA_SOS.2.1/AK.Jobnummer The TSF shall provide a mechanism to generate sechsstellige Jobnummern secrets that meet aus 3 zufälligen Großbuchstaben und 3 zufälligen Ziffern zu bestehen, wobei jedes Zeichen jeden Wert mit gleicher Wahrscheinlichkeit annimmt. Die TSF müssen sicherstellen, dass die letzten 1.000 vom EVG generierten Jobnummern einmalig sind 330 . FIA_SOS.2.2/AK.Jobnummer The TSF shall be able to enforce the use of TSF generated sechsstellige Jobnummern secrets for Übergabe der Jobnummern ans Clientsystem 331 . 328 [assignment: additional rules, based on security attributes, that explicitly deny access of subjects to objects] 329 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] 330 [assignment: a defined quality metric] 331 [assignment: list of TSF functions] Security Target secunet konnektor 2.1.0 Seite 244 von 424 secunet Anwendungshinweis 155: Die Verfeinerung von „Geheimnisse“ zu „sechsstellige Jobnummern“ ist notwendig, um den Ablauf der PIN-Eingabe zu konkretisieren. Die Jobnummer wird nach ISO646 DE aus den Bytes 0x30 bis x39 und x41 bis x5A angezeigt (s. [27], Kap. 4.1.8.1.3). Dies entspricht 7 1,76 10  möglichen Jobnummern. Laut [27] wird die Jobnummer vom Konnektor erzeugt und kann durch Clientsysteme abgerufen werden. Der Konnektor soll jedoch laut [27] keine Verbindung zwischen erzeugten und verwendeten Jobnummern herstellen. Die TSF sollen also nicht prüfen, ob nur Nummern verwendet werden, die vorher vom EVG erzeugt wurden, oder ob alle Nummern verwendet werden, die vom EVG erzeugt wurden. FDP_ACC.1/AK.Sgen Subset access control / Signaturerstellung Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.1.1/AK.Sgen The TSF shall enforce the Signaturerstellung-SFP332 on subjects: (1) S_AK, (2) S_Signaturdienst, (3) S_Benutzer_Clientsystem; objects: (1) Zu signierende Dokumente, (2) Signaturstapel, (3) Signierte Dokumente; (4) Zu signierender Bitstring, (5) Signierter Bitstring; operations: (1) Signatur erstellen, (2) Signierte Dokumente erstellen, (3) Signatur mit der Signaturkarte erstellen, (4) Signaturvorgang abbrechen, (5) Signierte Dokumente zurückgeben, (6) Authentisierungsstatus der Signaturkarte zurücksetzen .333 Operation Beschreibung Anmerkung 332 [assignment: access control SFP] 333 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] Security Target secunet konnektor 2.1.0 secunet Seite 245 von 424 Signatur erstellen Hashwerte zu signierender Dokumente berechnen, an die Signaturkarte zur Berechnung der digitalen Signatur senden und bei Empfang der digitalen Signatur von der Signaturkarte wird diese geprüft Die Prüfung der digitalen Signatur stellt fest, ob die digitale Signatur für den übersandten Haswert und den vorgesehenen Signatur- schlüssel erzeugt wurde. Bei Übereinstimmung sind die Dokumente gültig signiert, sonst sind sie ungültig signiert. Signierte Dokumente erstellen Erzeugen einer oder mehrer signierter Dokumente gemäß FDP_DAU.2/QES Für qualifizierte Signaturen erlaubt. Signatur mit der Signaturkarte erstellen Die DTBS wird an die Signaturkarte zur Berechnung der digitalen Signatur übergeben. Signaturvorgang abbrechen Diese Operation unterbricht die Signatur eines Dokumentenstapels. Der Konnektor MUSS jede Signaturerstellung für ein Dokumentenstapel unterbrechen können. Signierte Dokumente zurückgeben Die signierten Dokumente weden vom Signaturdienst an den Benutzer S_AK zur weiteren Verabeitung übergeben. Authentisierungsstatus der Signaturkarte zurücksetzen Der Authentisierungsstatus der Signaturkarte wird zurücksetzt. Nach Abarbeitung des Stapels, bei Abbbruch des Signaturvorgangs und bei festgestellten ungültig signierten Dokumente wird der Signatur-PIN- Authentisierungsstatus der Signaturkarte zurücksetzen. Tabelle 20: Operationen zur Signaturerstellung FDP_ACF.1/AK.Sgen Security attribute based access control / Signaturerstellung Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation Security Target secunet konnektor 2.1.0 Seite 246 von 424 secunet FDP_ACF.1.1/AK.Sgen The TSF shall enforce the Signaturerstellung-SFP334 to objects based on the following list of subjects, objects and security attributes: subjects: (1) S_AK, (2) S_Signaturdienst, (3) S_Benutzer_Clientsystem with security attributes: (a) „Identität des Benutzers“, (b) „Authorisierungsstatus (HBA)“, objects: (1) Zu signierende Dokumente with security attributes: (a)Authorisierungsstatus: „nicht autorisiert“, (b)Authorisierungsstatus: „autorisiert“, (c)Signaturrichtlinie, (2) Signaturstapel, (3) Signaturschlüssel externer Signaturchipkarten, (4) Signierte Dokumente with security attributes: (a)„ordnungsgemäß“ (b)„ungültig“ (5) Zu signierender Bitstring, (6) Signierter Bitstring, (7) Authentisierungsschlüssel von HBAx oder SM-B. . 335 FDP_ACF.1.2/AK.Sgen The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: (1) Das Subjekt S_AK darf nur nicht autorisierte zu signierende Dokumente an das Subjekt Signaturdienst übergeben und die zu verwendende Signaturrichtlinie, den Signierenden, den Arbeitsplatz und die Signaturkarte identifizieren. (2) Nur das Subjekt S_Signaturdienst steuert den Signaturprozess des identifizierten Arbeitsplatzes. (3) Das Subjekt S_Signaturdienst darf nur dann die zu signierenden Dokumente signieren, wenn (a) der Sicherheitsstatus der Signaturchipkarte die Erzeugung der digitalen Signatur erlaubt. 334 [assignment: access control SFP] 335 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes] Security Target secunet konnektor 2.1.0 secunet Seite 247 von 424 (4) Wenn die identifizierte Signaturrichtlinie die Erzeugung einer qualifizierte elektronische Signatur fordert, dann (a) muss das Subjekt S_AK den Signierenden und den Arbeitsplatz identifizieren, (b) muss die identifizierte Signaturrichtlinie für eine qualifizierte elektronische Signatur geeignet sein, (c) muss das Subjekt S_Signaturdienst für die Einfachsignatur die lokale Eingabe der QES-PIN an HBAx oder die entfernte Eingabe der QES-PIN an HBA steuern und für die Stapelsignatur die lokale oder entfernte PIN-Eingabe für HBA steuern, (d) darf das Subjekt S_Signaturdienst nur für durch den HBA „autorisierten Benutzer des Clientsystems“ zu signierenden Dokumente Signaturen mit der Signaturkarte erstellen, Signaturen ungültig signierter Dokumente sind zu löschen, (e) das Subjekt S_Benutzer_Clientsystem darf den Signaturvorgang für die autorisierten zu signierenden Dokumente abbrechen, (f) der S_Signaturdienst darf nur ordnungsgemäß signierte Dokumente an den S_AK zurückgeben, (g) das Subjekt S_Signaturdienst muss nach Abarbeitung des Stapels, bei Abbbruch des Signaturvorgangs durch das Subjekt S_Benutzer_Clientsystem und bei festgestellten ungültig signierten Dokumente den Signatur-PIN-Authentisierungsstatus der Signaturkarte HBA zurücksetzen. (h) das Subjekt S_Signaturdienst muss bei aktivierter Komfortsignatur nach Ablauf des Zählers SAK_COMFORT_SIGNATURE_MAX oder nach Ablauf der Zeit SAK_COMFORT_SIGNATURE_TIMER den Authentisierungsstatus der jeweiligen HBA- Kartensitzung zurücksetzten und bei Deaktivierung des Komfortsignatur-Modus SAK_COMFORT_SIGNATURE und bei Deaktivierung der Komfortsignatur durch die Operation DeactivtaeComfortSignature den Signatur-PIN-Authentisierungsstatus aller HBA- Kartensitzungen zurücksetzen. (5) Wenn die gültige Signaturrichtlinie die Erstellung einer qualifizierten elektronischen Signatur verlangt, darf das Subjekt S_Signaturdienst nur ordnungsgemäße qualifizierte elektronische Signaturen an den S_AK zurück geben. Security Target secunet konnektor 2.1.0 Seite 248 von 424 secunet (6) Das Subjekt S_AK darf dem S_Signaturdienst Binärstrings mit der maximalen Länge von 512 Bit nur336 zur Erstellung digitaler Signaturen mit Authentisierungsschlüsseln von HBAx oder SM-B übergeben und die von HBAx bzw. der SM-B signierte Binärstrings vom S_Signaturdienst empfangen. 337 FDP_ACF.1.3/AK.Sgen The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [none]338 . FDP_ACF.1.4/AK.Sgen The TSF shall explicitly deny access of subjects to objects based on the following additional rules: (1) Das Subjekt S_Signaturdienst muss die Erstellung der Signatur für zu signierenden Dokumente verweigern, wenn der S_AK für die zu signierenden Dokumente eine Signaturrichtlinie zur Erstellung qualifizierter elektronische Signatur identifiziert, aber (a) der Signierende keine qualifizierte elektronische Signatur erzeugen kann oder (b) die Autorisierung des S_Benutzer_Clientsystem fehlschlägt. (2) Das Subjekt S_Signaturdienst muss die Erstellung der Signatur für zu signierenden Dokumente verweigern, wenn für diese zu signierenden Dokumente und den Signierenden die identifizierte Signaturrichtlinie ungültig ist. (3) Das Subjekt S_Signaturdienst muss die Erstellung der Signatur für den Signaturstapel verweigern und alle für zu signierende Dokumente des Signaturstapels bereits erzeugten Signaturen löschen, wenn die Überprüfung der Signatur wenigstens einer signierten Datei des Signaturstapels fehlschlägt. (4) Außer dem S_Signaturdienst darf kein Subjekt auf (a) das Verzeichnis DF.QES des HBA, (b) den Schlüssel PrK.HCI.OSIG der SMC-B, (c) [none]339 zugreifen. 336 [refinement: nur] 337 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects]. 338 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]. 339 [assignment: weitere Signaturschlüssel externer Signaturchipkarten] Security Target secunet konnektor 2.1.0 secunet Seite 249 von 424 (5) [none]340 . .341 Anwendungshinweis 156: Die Spezifikation Konnektor beschreibt die Schnittstelle zwischen dem Clientsystem und dem Konnektor zur Signaturerstellung und die Kartenhandle zur Identifikation einer gesteckten Chipklarte in Verbindung mit einem Arbeitsplatz des Benutzers. Der EVG kann die Signaturkarte des Signierenden mittels Kartenhandle identifizieren. Der EVG kann den Signierenden und den zu benutzenden Arbeitsplatz identifizieren. Anwendungshinweis 157: Die Bedingungen für die Sicherheitsattribute signierter Dateien „ordungsgemäß“ und „ungültig“ sind durch FMT_MSA.4/AK festgelegt. 340 [assignment: additional rules, based on security attributes, that explicitly deny access of subjects to objects] 341 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] Security Target secunet konnektor 2.1.0 Seite 250 von 424 secunet Anwendungshinweis 158: In PP-0098 wird das SFR FDP_ACF.1/AK.Sgen für die in dem PP beschriebenen Signaturarten „Einzelsignatur“ und „Stapelsignatur“ modelliert. Der EVG unterstützt zusätzlich die „Komfortsignatur“. Der Anwendungshinweis 158 des PP erlaubt ausdrücklich, dass für weitere Signaturarten teilweise von der Definition der SFR abgewichen werden kann. Insbesondere wird dabei FDP_ACF.1.2/AK.Sgen Regel (4)(g) genannt. Der EVG unterstützt zusätzlich die „Komfortsignatur“. Entsprechend wurde FDP_ACF.1/AK.Sgen um Regel (4)(f) erweitert. Die Komfortsignatur wird wie folgt umgesetzt (A_19102-04 und A_19103-06): Wenn die Komfortsignatur für eine HBA-Kartensitzung aktiviert ist (SAK_COMFORT_SIGNATURE=enabled und Komfortsignatur-Modus aktiv) , wird der Authentisierungssatus der HBA-Kartensitzung erst dann zurückgesetzt, wenn eine konfigurierte Anzahl an einzelnen Signaturoperation durchgeführt wurde (SAK_COMFORT_SIGNATURE_MAX, Default=100, A_19100) oder ein konfigurierter Zeitwert abgelaufen ist (SAK_COMFORT_SIGNATURE_TIMER, Default=6h, A_18686-01). Der secunet konnektor 2.1.0 unterstützt bis zu zwei parallele HBA- Kartensitzungen für die Komfortsignatur. Die globalen Konfigurationswerte für das Aktivieren der Komfortsignatur-Funktionalität, für den Timer und für den Zähler können nur vom Administrator verwaltet werden (TIP1-A_4680-03). Für jede Kartensitzung werden vom Konnektor entsprechend der konfigurierten Werte für SAK_COMFORT_SIGNATURE_MAX und SAK_COMFORT_SIGNATURE_TIMER unabhängige Zähler und Timer verwaltet. Zudem wird der Authentisierungssatus aller HBAs bzw. HBA- Kartensitzungen bei Deaktivierung durch die Operation DeactiveComfortSignature oder direkt durch Deaktivierung des Komfortsignatur-Modus in der Managementoberfläche (SAK_COMFORT_SIGNATURE=disabled) zurückgesetzt. Zudem wird bei Aktivierung der Komfortsignatur die übermittelte UserID auf Eindeutigkeit in Bezug auf die letzten 1000 Aufrufe (A_20074) und auf korrekte Länge (128 Bit) und Format RFC4122 geprüft (A_20073-01). Diese UserID ist als Authentisierungsgeheimnis zu behandeln und wird nicht vom Konnektor ausgegeben. Der TOE setzt entsprechend FDP_ACF.1.2/AK.Infomod (TIP1-A_4524-02) durch die Prüfung des Aufrufkontext durch, dass nur der Nutzer Komfortsignatur-Aufträge auslösen kann (SignDocument und TUC_KON_170), der die selbe UserID präsentiert, wie diese beim Aktivieren des Komfortsignatur-Modus für diese HBA- Kartensitzung (ActivateComfortSignature) präsentiert wurde. Schlägt die Prüfung fehl, wird die Operation abgebrochen. Die eigentliche Authentifizierung des Nutzers beim Auslösen der Komfortsignatur erfolgt außerhalb des TOE im Clientsystem. Es erfolgt ein entsprechender Hinweis im Handbuch bezüglich der Notwendigkeit und Bedeutung der Nutzer- Authentisierung, A_19101. Weitere Signaturarten werden nicht im EVG umgesetzt. FDP_ACC.1/AK.SigPr Subset access control / Signature verification Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control Security Target secunet konnektor 2.1.0 secunet Seite 251 von 424 FDP_ACC.1.1/AK.SigPr The TSF shall enforce the Signature verification-SFP342 on subjects: (1) S_AK, (2) S_Signaturdienst, (3) S_Benutzer_Clientsystem; objects: (1) Signierte Dokumente, (2) Signaturprüfungsergebnis; operations: (1) Signatur prüfen, (2) Festlegen des angegebenen Zeitpunkts 343 . Operation Beschreibung Anmerkung Signatur prüfen Prüfung der digitalen Signatur mit Rückgabe der Prüfungsergebnisse and die aufrufende Instanz. Festlegen des angegebenen Zeitpunkts Angabe des Zeitpunkts, der der Prüfung einer digitalen Signatur zugrundegelegt wird, wenn dieser in den signierten Dokumente fehlt oder von diesem abweichen soll. Dies ist für die Prüfung qualifizierte elektronische Signaturen gefordert. Tabelle 21: Operationen zur Signaturprüfung FDP_ACF.1/AK.SigPr Security attribute based access control/ Signature verification Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation FDP_ACF.1.1/AK.SigPr The TSF shall enforce the Signature verification-SFP344 to objects based on the following list of subjects, objects and security attributes: subjects: 342 [assignment: access control SFP] 343 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 344 [assignment: access control SFP] Security Target secunet konnektor 2.1.0 Seite 252 von 424 secunet (1) S_AK, (2) S_Signaturdienst, (3) S_Benutzer_Clientsystem; objects: (1) Signierte Dokumente with the security attributes (a)Signaturrichtlinie, (b)Angegebener Zeitpunkt, (2) Signaturprüfungsergebnis .345 FDP_ACF.1.2/AK.SigPr The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: (1) Das Subjekt S_AK darf signierte Dokumente an das Subjekt S_Signaturdienst zur Signaturprüfung übergeben und die Signaturrichtlinie identifizieren. (2) Der Signaturdienst darf das Ergebnis der Signaturprüfung an das Subjekt S_AK zurückgeben. 346 . FDP_ACF.1.3/AK.SigPr The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [none]347 . FDP_ACF.1.4/AK.SigPr The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [none]348 . Anwendungshinweis 159: Die signierten Daten enthalten in der Regel die Identität der Signaturrichtlinie und einen Zeitpunkt der Signaturerstellung. Die Signaturprüfung erfolgt nach der in den signierten Daten identifizierten Signaturrichtlinie. Die Auswahl des für die Signaturprüfung anzunehmenden Signaturzeitpunkts erfolgt entsprechend [27] hierarchisch:  Für die QES-Signaturprüfung: o falls vorhanden Benutzerdefinierter_Zeitpunkt, sonst o falls vorhanden Ermittelter_Signaturzeitpunkt_Eingebettet, sonst o Ermittelter_Signaturzeitpunkt_System  Für die nonQES-Signaturprüfung: o falls vorhanden Benutzerdefinierter_Zeitpunkt, sonst 345 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes] 346 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects]. 347 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]. 348 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]. Security Target secunet konnektor 2.1.0 secunet Seite 253 von 424 o falls vorhanden Ermittelter_Signaturzeitpunkt_Eingebettet, sonst o Ermittelter_Signaturzeitpunkt_System. Bei der QES-Signaturprüfung ist die Auswertung von qualifizierten Zeitstempeln (Ermittelter_Signaturzeitpunkt_Qualifiziert) nach [27] optional. Ein gegebenenfalls vorhandener qualifizierter Zeitstempel wird vom Konnektor vollständig ignoriert. FDP_DAU.2/AK.QES Data Authentication with Identity of Guarantor / Qualifizierte elektronische Signatur Hierarchical to: FDP_DAU.1 Einfache Datenauthentisierung Dependencies: FIA_UID.1 Timing of identification FDP_DAU.2.1/AK.QES The TSF shall provide a capability to generate evidence that can be used as a guarantee of the validity of data to be signed349 durch qualifizierte elektronische Signatur gemäß gültiger Signaturrichtlinie mit Hilfe der qualifizierten Signaturerstellungseinheit (QSEE) zur Erzeugung der digitalen Signatur. Es sind die Dokumentenformate zu signierender Daten (1) Text-Dateien (UTF-8 [95] oder ISO-8859-15 [93]), (2) TIFF-Dateien [94], (3) Adobe Portable Document Format (PDF/A) [96] [97], (4) XML-Dateien [98] [83] und die Formate signierter Daten (1) PAdES [86] [89] für PDF/A-Dokumente, (2) CadES [85] [88] für XML, PDF/A, Text und TIFF Dokumente, (3) XAdES [82] [87] für XML-Dokumente mit den Signaturvarianten (1) enveloped signature, (2) enveloping signature, (3) detached signature zu unterstützen. FDP_DAU.2.2/AK.QES The TSF shall provide S_Benutzern350 with the ability to verify evidence of the validity of the indicated information and the identity of the user that generated the evidence durch qualifizierte elektronische Signatur in den in FDP_DAU.2.1/QES genannten Formaten sowie den Verfahren ECDSA [2] und PKCS#1 RSASSA-PSS und RSASSA-PKCS1-v.5 [90]. 349 [assignment: list of objects or information types] 350 [assignment: list of subjects] Security Target secunet konnektor 2.1.0 Seite 254 von 424 secunet Dies sind im einzelnen: (1) ob die signierten Daten unverändert sind, d. h. das Ergebnis der Korrektheitsprüfung der digitalen Signatur über die signierten Daten, (2) der der Signatur zuzuordnende Signaturschlüssel-Inhaber, (3) die Inhalte des Zertifikates, auf dem die Signatur beruht, (4) das Ergebnis der Nachprüfung der Zertifikate nach dem Kettenmodell, d. h. die Gültigkeit der Zertifikate zum angegebenen Zeitpunkt, a. der angenommene Signaturerstellungszeitpunkt, wobei gegen folgende Zeitpunkte zu prüfen ist, sofern die Voraussetzungen durch die zu prüfenden Daten erfüllt sind: i. vom Benutzer definierter Zeitpunkt, sonst ii. in der Signatur eingebetteter Zeitpunkt, sonst iii. [none], iv. bzw. wenn diese nicht vorliegen der Jetzt- Zeitpunkt; b. das Vorhandensein des Zertifikats des VDA, der das Signaturzertifikat ausgestellt hat, in der BNetzA-VL. c. die Korrektheit der digitalen Signatur des Signaturzertifikats, d. die Anforderung von OCSP-Anfragen und die Auswertung von OCSP-Antworten, ob das nachgeprüfte qualifizierte Signaturzertifikat im jeweiligen Zertifikatsverzeichnis zum angegebenen Zeitpunkt vorhanden und nicht gesperrt war. (5) Für jedes Ergebnis der Korrektheitsprüfung einer digitalen Signatur ist anzugeben, ob a. die kryptographische Prüfung der digitalen Signatur mit dem dazugehörigen öffentlichen Schlüssel deren Korrektheit bestätigt hat oder nicht, b. die für die Erstellung der Signatur verwendeten kryptographischen Algorithmen und Parameter zum angegeben Signaturerstellungszeitpunkt geeignet waren, wenn dies nicht der Fall ist, liegt keine qualifizierte elektronische Signatur vor; c. die für die Erstellung der Signatur verwendeten kryptographischen Algorithmen und Parameter zum Signaturprüfzeitpunkt geeignet sind; wenn dies nicht der Fall ist, ist eine Information zum verminderten Beweiswert der qualifizierte elektronischen Signatur zurückzugeben. Security Target secunet konnektor 2.1.0 secunet Seite 255 von 424 (6) [none]351 . Anwendungshinweis 160: Für den allgemeinen Begriff der Signaturrichtlinie sei auf die Ausführungen in Abschnitt 1.3.5.2 verwiesen. Die Verfeinerung des Elements FDP_DAU.2.1/QES durch die Ergänzung „mit Hilfe der qualifizierten Signaturerstellungseinheit zur Erzeugung der digitalen Signatur“ ist notwendig, da die digitale Signatur durch die qualifizierte Signaturerstellungseinheit (z. B. den HBA) erstellt wird. Die Spezifikation Konnektor [27] schränkt die zu unterstützenden Kombinationen der Dokumentenfromate, Formate signierter Daten und Signaturvarianten ein. Diese Einschränkungen gelten auch FDP_DAU.2.1. Die für die Prüfung der qualifizierten elektronischen Signatur notwendigen Angaben (wie z.B. Angaben zu dem der qualifizierten elektronischen Signatur zugrunde liegenden Zertifikat) werden durch den EVG mit Hilfe der PKI-Dienste erstellt. Die Identität des Benutzers, der den Nachweis generiert hat, wird aus dem der qualifizierten elektronischen Signatur zugrunde liegenden Zertifikat abgeleitet. Dies kann ein Pseudonym sein. Anwendungshinweis 161: Für die Prüfung der Zertifikate, der OCSP-Antworten und der OCSP- Zertifikate werden im QES-Bereich die selben Verfahren wie für die Prüfung der qualifizierten Dokumentensignaturen unterstützt. Anwendungshinweis 162: Die Informationen aus dem OCSP-Dienst können eine gewisse Zeit in einem Cache gepuffert und verwendet werden. Dabei ist zu beachten, dass der verwendete Zeitpunkt der aus dem Cache entnommenen Prüfergebnisse nicht älter ist als der zu prüfende Signaturerstellungszeitpunkt. Der maximale Zeitraum der Verwendung des OCSP Cache kann vom Administrator vorgegeben werden. Anwendungshinweis 163: Der Konnektor unterstützt die Signaturvariante „detached signature“. FDP_DAU.2/AK.Sig Data Authentication with Identity of Guarantor / NonQES Hierarchical to: FDP_DAU.1 Einfache Datenauthentisierung Dependencies: FIA_UID.1 Timing of identification FDP_DAU.2.1/AK.Sig The TSF shall provide a capability to generate evidence that can be used as a guarantee of the validity of zu signierenden Daten352 durch nicht-qualifizierte elektronische Signatur gemäß gültiger Signaturrichtlinie mit Hilfe der Chipkarten. Es sind die Dokumentenformate zu signierender Daten (1) Text-Dateien (UTF-8 [95] oder ISO-8859-15 [93]), (2) TIFF-Dateien[94], (3) Adobe Portable Document Format (PDF/A) [96], (4) XML-Dateien [98] [83], 351 [assignment: andere Form von Nachweisen] 352 [assignment: list of objects or information types] Security Target secunet konnektor 2.1.0 Seite 256 von 424 secunet (5) Binärdokument, und die Formate signierter Daten (1) PAdES [86] [89] für PDF/A-Dokumente, (2) CadES [85] [88] für Text, TIFF, Adobe Portable Document Format (PDF/A) und XML Dokumente sowie Binärdokumente, (3) mit den Signaturvarianten (1) enveloped signature, (2) enveloping signature, (3) detached signature zu unterstützen. FDP_DAU.2.2/AK.Sig The TSF shall provide S_Benutzern353 with the ability to verify evidence of the validity of the indicated information and the identity of the user that generated the evidence durch nicht-qualifizierte elektronische Signatur in den in FDP_DAU.2.1/Sig genannten Formaten sowie den Verfahren ECDSA [3], PKCS#1 RSASSA- PSS und RSASSA-PKCS1-v.5 [90] gemäß gültiger Signaturrichtlinie. Dies sind im einzelnen: (1) ob die signierten Daten unverändert sind, d. h. das Ergebnis der Korrektheitsprüfung der Signatur, (2) der Signatur zuzuordnende Signaturschlüssel-Inhaber, (3) die Inhalte des Zertifikates, auf dem die Signatur beruht, (4) das Ergebnis der Nachprüfung von Zertifikaten in der Zertifikatskette, (5) die Anforderung von OCSP-Anfragen und die Auswertung von OCSP-Antworten, [none]354 . 353 [assignment: list of subjects] 354 [assignment: andere Form von Nachweisen] Security Target secunet konnektor 2.1.0 secunet Seite 257 von 424 Anwendungshinweis 164: Der EVG unterstützt die Erzeugung und die Prüfung von nicht- qualifizierten elektronischen Signaturen. Dies können fortgeschrittene elektronische Signaturen oder digitale Signaturen sein. In beiden Fällen muss aber eine gültige Signaturrichtlinie vorliegen. Für Binärdokumente und Binärstrings werden keine Formatanforderungen gestellt. Die Verfeinerung des Elements FDP_DAU.2/AK.Sig durch die Ergänzung „mit Hilfe der Chipkarten“ ist notwendig, da die digitale Signatur durch eine nicht zum EVG gehörige Chipkarte (z. B. eine SMC-B) erstellt wird. Die anderen für die Prüfung der elektronischen Signatur oder einer digitalen Signatur notwendigen Angaben (wie z.B. Angaben zu dem der elektronischen Signatur zugrunde liegenden Zertifikat) werden durch den EVG erstellt. Zum Nachweis der erfolgreichen Prüfung werdendie für die Gültigkeitsprüfung benutzten OCSP-Antworten mit einem Zeitstempel versehen und dem Nutzer zugänglich gemacht. Es werden neben der NFDM-Signaturrichtlinie und dem in FDP_DAU.2/AK.Sig und im PP [15], Kapitel 1.3.5.2 beschriebenen Standardablauf zur Signaturprüfung keine weiteren Signaturrichtlinien unterstützt.. Anwendungshinweis 165: Die Informationen aus dem OCSP-Dienst können eine gewisse Zeit in einem Cache gepuffert und verwendet werden. Dabei ist zu beachten, dass der verwendete Zeitpunkt der aus dem Cache entnommenen Prüfergebnisse nicht älter ist als der zu prüfende Signaturerstellungszeitpunkt. Der maximale Zeitraum der Verwendung des OCSP Cache kann vom Administrator vorgegeben werden. Anwendungshinweis 166: Das Verfahren sha256withRSAEncryption (OID 1.2.840.113549.1.1.11) wird im nonQES-Bereich nur für die Prüfung der Zertifikate, der OCSP-Antworten und der OCSP-Zertifikate unterstützt, nicht jedoch für nicht-qualifizierte Dokumentensignaturen. Für die Prüfung der Zertifikate, der OCSP-Antworten und der OCSP-Zertifikate werden im nonQES-Bereich zudem die selben Verfahren wie für die Prüfung der nicht-qualifizierten Dokumentensignaturen unterstützt. FDP_DAU.2/AK.Cert Data Authentication with Identity of Guarantor / Überprüfung von Zertifikaten Hierarchical to: FDP_DAU.1 Einfache Datenauthentisierung Dependencies: FIA_UID.1 Timing of identification FDP_DAU.2.1/AK.Cert The TSF shall provide a capability to generate evidence that can be used as a guarantee of the validity of Signaturen355 . FDP_DAU.2.2/AK.Cert The TSF shall provide S_Benutzern356 with the ability to verify evidence of the validity of the indicated Zertifikatsprüfung, einschließlich Zertifikatsinhalt information and the identity of the user that generated the evidence. Dies sind im einzelnen: (1) der Inhalt des Zertifikats, auf dem die Signatur beruht, (2) die zugehörigen Attribut-Zertifikate, (3) der der Signatur zuzuordnende Signaturschlüssel-Inhaber, 355 [assignment: list of objects or information types] 356 [assignment: list of subjects] Security Target secunet konnektor 2.1.0 Seite 258 von 424 secunet (4) die Gültigkeit der Zertifikate zum angegebenen Zeitpunkt, (5) das Ergebnis der Korrektheitsprüfung der Signatur, (6) die Daten, auf die sich die Signatur bezieht, (7) ob die signierten Daten unverändert sind, (8) die Anforderung von OCSP-Anfragen und die Auswertung von OCSP-Antworten, (9) die Anforderung von CRL-Anfragen und die Auswertung von CRL, (10) [none]357 . Anwendungshinweis 167: Die Informationen aus dem OCSP-Dienst können eine gewisse Zeit in einem Cache gepuffert und verwendet werden. Dabei ist zu beachten, dass der verwendete Zeitpunkt der aus dem Cache entnommenen Prüfergebnisse nicht älter ist als der zu prüfende Signaturerstellungszeitpunkt. Der maximale Zeitraum der Verwendung des OCSP Cache kann vom Administrator vorgegeben werden. Anwendungshinweis 168: Für die Prüfung der Zertifikate, der OCSP-Antworten und der OCSP- Zertifikate werden alle Verahren entsprechend Anwendungshinweis 161 und Anwendungshinweis 166 unterstützt. FDP_ITC.2/AK.Sig Import of user data with security attributes / Signaturdienst Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] FPT_TDC.1 Inter-TSF basic TSF data consistency FDP_ITC.2.1/AK.Sig The TSF shall enforce the Signaturerstellung-SFP und Signaturprüfung-SFP358 when importing user data, controlled under the SFP, from outside of the TOE. FDP_ITC.2.2/AK.Sig The TSF shall use the security attributes associated with the imported user data. FDP_ITC.2.3/AK.Sig The TSF shall ensure that the protocol used provides for the unambiguous association between the security attributes and the user data received. FDP_ITC.2.4/AK.Sig The TSF shall ensure that interpretation of the security attributes of the imported user data is as intended by the source of the user data. 357 [assignment: andere Form von Nachweisen] 358 [assignment: access control SFP(s) and/or information flow control SFP(s)] Security Target secunet konnektor 2.1.0 secunet Seite 259 von 424 FDP_ITC.2.5/AK.Sig The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TOE: (1) Die TSF importiert zu signierende Daten mit dem Sicherheitsattribut „Signaturrichtlinie“ nur nach erfolgreicher Prüfung der Zulässigkeit der Signaturrichtlinie. (2) Die TSF importiert zu prüfende signierte Daten mit dem Sicherheitsattribut „Signaturrichtlinie“ nur nach erfolgreicher Prüfung der Zulässigkeit der Signaturrichtlinie. (3) Eine Signaturrichtlinie für qualifizierte elektronische Signaturen ist zulässig, wenn (a) für die Erzeugung einer qualifizierten elektronischen Signatur eine Benutzersteuerung festgelegt ist, (b) die Signaturprüfung mit anzeigbarem erzeugtem Prüfprotokoll erfolgt, (c) die Signaturrichtlinie auf die zu signierenden Daten durch den EVG anwendbar ist. (4) Die TSF weist importierten zu signierenden Daten das Sicherheitsattribut „nicht autorisiert“ zu .359 FMT_MSA.3/AK.Sig Static attribute initialisation / Signatur Hierarchical to: No other components. Dependencies: FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1/AK.Sig The TSF shall enforce the Signaturerstellung-SFP und die Signaturprüfung-SFP360 to provide restrictive361 default values for security attributes zulässige Signaturrichtlinie that are used to enforce the SFP. FMT_MSA.3.2/AK.Sig The TSF shall allow the Administrator362 to specify alternative initial values to override the default values when an object or information is created. Anwendungshinweis 169: Es sei darauf hingewiesen, dass Signaturrichtlinien in diesem Dokument weiter gefasst sind, s. Abschnitt 1.3.5.2. Diese und ggf. weitere Signaturpolicies können im EVG dauerhaft gespeichert sein. FDP_SDI.2/AK Stored data integrity monitoring and action Hierarchical to: FDP_SDI.1 Stored data integrity monitoring 359 [assignment: additional importation control rules] 360 [assignment: access control SFP, information flow control SFP] 361 [selection, choose one of: restrictive, permissive, [assignment: other property]] 362 [assignment: the authorised identified roles] Security Target secunet konnektor 2.1.0 Seite 260 von 424 secunet Dependencies: No dependencies. FDP_SDI.2.1/AK The TSF shall monitor user data zu signierende Daten stored in containers controlled by the TSF for Veränderung363 on all objects, based on the following attributes: [Signatur über die zu signierenden Daten ]. FDP_SDI.2.2/AK Upon detection of a data integrity error, the TSF shall (1) Die Erstellung der digitalen Signatur für die zu signierenden Daten verweigern und den Benutzer des Clientsystems über den Datenintegritätsfehler informieren, (2) [Nachdem die von der Chipkarte erzeugte Signatur über die zu signierenden Daten zurück an den Konnektor gesendet wurde, muss diese vom Konnektor erneut auf mathematische Korrektheit geprüft werden, bevor das Ergebnis an das Clientsystem ausgegeben werden darf.] 364 . Anwendungshinweis 170: Die Verfeinerung des Elements FDP_SDI.2/AK.1 durch ersetzen von „Benutzerdaten“ durch „zu signierenden Daten“ präzisiert den besonderen Schutz dieser Daten. Die Zuweisung im Element FDP_SDI.2/AK wurde so gewählt, dass Veränderungen an den zu signierenden Daten ab der Übergabe durch den EVG bei Aufruf des Signierdienstes bis zur Rückgabe der signierten Daten an den EVG festgestellt werden können. FMT_MSA.1/AK.U ser Management of security attributes / Clientsystem-Benutzer Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions. FMT_MSA.1.1/AK. User The TSF shall enforce the Signaturerstellung-SFP und die Signaturprüfung-SFP365 to restrict the ability to (1) Modify366 the security attribute Autorisierungsstatus zu signierender Daten, 367 363 [assignment: integrity errors] 364 [assignment: action to be taken] 365 [assignment: access control SFP(s), information flow control SFP(s)] 366 [selection: change_default, query, modify, delete, [assignment: other operations]] 367 [assignment: list of security attributes] Security Target secunet konnektor 2.1.0 secunet Seite 261 von 424 (2) Select368 the security attribute gültige Signaturrichtlinie für zu signierende Daten, 369 (3) Modify370 the security attributes angegebener Zeitpunkt signierter Daten für die Signaturprüfung371 to S_Benutzer_Clientsystem372 . Anwendungshinweis 171: Die Operationen wurden zusammen mit den Sicherheitsattributen aufgelistet, um eine kompaktere Darstellung zu erreichen. Für den Autorisierungsstatus zu signierender Daten gilt die Regel (1) in FMT_MSA.1/AK.User in Verbindung mit den Regeln (1) und (2) in FMT_MSA.4/AK.1. Die Auswahl der Signaturrichtlinie entsprechend Regel (2) sowie die Modifikation des angegebenen Zeitpunkts für die Signaturprüfung entsprechend Regel (3) erfolgt durch den S_Benutzer_Clientsystem über die Parametrisierung des Aufrufes der Entsprechenden Operationen der Signaturschnittstelle des EVG FTP_ITC.1/AK.QSEE Inter-TSF trusted channel / QSEE Hierarchical to: No other components. Dependencies: No dependencies. FTP_ITC.1.1/AK.QSEE The TSF shall provide a communication channel between itself and another trusted IT product der qualifizierten Signaturerstellungseinheit that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification and or disclosure. FTP_ITC.1.2/AK.QSEE The TSF shall permit the TSF373 to initiate communication via the trusted channel. FTP_ITC.1.3/AK.QSEE The TSF shall initiate communication via the trusted channel for Senden der zu signierende Daten an die qualifizierte Signaturerstellungseinheit374 . Anwendungshinweis 172: Die Verfeinerung des Elementes FTP_ITC.1/AK.QSEE konkretisiert den Signaturablauf. Die allgemeine Formulierung „einem anderen vertrauenswürdigen IT- Produkt“ wurde durch „der qualifizierten Signaturerstellungseinheit“ verfeinert. FTA_TAB.1/AK.Jobnummer Default TOE access banners / Jobnummer 368 [selection: change_default, query, modify, delete, [assignment: other operations]] 369 [assignment: list of security attributes] 370 [selection: change_default, query, modify, delete, [assignment: other operations]] 371 [assignment: list of security attributes] 372 [assignment: the authorised identified roles] 373 [selection: the TSF, another trusted IT product] 374 [assignment: list of functions for which a trusted channel is required] Security Target secunet konnektor 2.1.0 Seite 262 von 424 secunet Hierarchical to: No other components. Dependencies: No dependencies. FTA_TAB.1.1/AK.Jobnummer Before entfernter Eingabe von PIN und PUK an eHealth- Kartenterminals establishing a user session, the TSF shall display die vom Clientsystem übergebene und vom EVG geprüfte Jobnummer an eHealth-Kartenterminal an advisory warning message regarding nichtbeabsichtigten unauthorised use of the TOE. Anwendungshinweis 173: Die Verfeinerungen des Elements FTA_TAB.1/AK.Jobnummer präzisieren die Nutzung der Jobnummer. Die Benutzersitzung dieses Elements bezieht sich nur auf die „Eingabe von PIN oder PUK an den eHealth-Kartenterminals“ unter Steuerung des EVG und ist Teil einer Sitzung am Arbeitsplatz zur Signaturerstellung oder Entschlüsselung. Die Anzeige der „Jobnummern“ ist notwendig, um die korrekte Zuordnung zwischen der Sitzung am Clientsystems des Arbeitsplatzes und dem durch den EVG ausgewählten eHealth-Kartenterminal für die entfernte PIN-Eingabe zu ermöglichen. FTA_TAB.1/AK.SP Default TOE access banners / Fehler des Signaturprozesses Hierarchical to: No other components. Dependencies: No dependencies. FTA_TAB.1.1/AK.SP Before establishing a user session Bei Feststellung ungültig erzeugter Signaturen, the TSF shall display an advisorywarning message regarding unauthorised use of the TOE to S_Benutzer_Clientsystem via the standard interface. Anwendungshinweis 174: Die Verfeinerung des Elements FTA_TAB.1/AK.SP warnt den Benutzer bei festgestellten Fehlern des Signaturprozesses, wenn ungültig signierte Dateien festgestellt wurden über die Standard-Schnittstelle des Clientsystems. Die Bedingungen für ungültig signierte Dateien sind in FMT_MSA.4/AK festgelegt 6.3.3.5. Software-Update FDP_ACC.1/AK.Update Subset access control / Update Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.1.1/AK.Update The TSF shall enforce the Update-SFP375 on subjects: (1) S_Administrator, (2) S_AK, (3) S_NK; objects: 375 [assignment: access control SFP] Security Target secunet konnektor 2.1.0 secunet Seite 263 von 424 (1) Update-Pakete; operations: (1) Importieren (2) Verwenden , 376 Operation Beschreibung Anmerkung Importieren Einlesen von bereitgestellten Update-Paketen und Aktualisieren der Komponenten des EVG Der Download kann automatisch erfolgen. Verwenden Die Update-Pakete werden zum Update der TSF-Daten, zum Update des EVG zu einem neuen EVG oder zum Update anderer externer Komponenten (eHealth-Kartenterminal) verwendet. Das Installieren (Verwenden) des Updates kann automatisch erfolgen. Tabelle 22: Operationen für Software-Update FDP_ACF.1/AK.Update Security attribute based access control / Update Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation FDP_ACF.1.1/AK.Update The TSF shall enforce the Update-SFP 377 to objects based on the following: subjects: (1) S_Administrator (2) S_AK, (3) S_NK objects: (1) Update-Pakete with security attributes: a. Signatur, b. Zulässige Software-Versionen . 376 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 377 [assignment: access control SFP] Security Target secunet konnektor 2.1.0 Seite 264 von 424 secunet FDP_ACF.1.2/AK.Update The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: (1) Das Subjekt S_AK oder S_NK darf nur Update-Pakete importieren, deren Signatur erfolgreich geprüft wurde. (2) Die Subjekte S_Administrator, S_AK und S_NK dürfen nur Update-Pakete verwenden, die einer Firmwaregruppe angehören, die gleich oder höher der gegenwärtig installierten Firmwaregruppe ist. .378 FDP_ACF.1.3/AK.Update The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [none]379 . FDP_ACF.1.4/AK.Update The TSF shall explicitly deny access of subjects to objects based on the following additional rules: 1. S_AK und S_NK dürfen Update-Pakete nicht automatisch anwenden, wenn die automatische Aktualisierung der Firmware durch S_Administrator deaktiviert wurde. 2. Wenn MGM_LU_ONLINE=Disabled gesetzt ist, so darf die TSF keine Kommunikation mit dem Update-Server (KSR) herstellen. .380 . Anwendungshinweis 175: Die Liste der zulässigen Software-Versionen wird in der Spezifikation Übergreifende Spezifikation: Operations und Maintenance [gemSpec_OM] mit “Firmware-Gruppe” bezeichnet [43]. Diese ist als versionierte Liste zulässiger Firmware- Versionen für Software-Updates in jede Konnektor-Software integriert werden. FDP_UIT.1/AK.Update Data exchange integrity / Update Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] 378 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects]. 379 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] 380 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] Security Target secunet konnektor 2.1.0 secunet Seite 265 von 424 FDP_UIT.1.1/AK.Update The TSF shall enforce the Update-SFP381 to receive382 user data in a manner protected from modification, deletion, insertion errors.383 . FDP_UIT.1.2/AK.Update The TSF shall be able to determine on receipt of user data, whether modification, deletion, insertion384 has occurred. 6.3.3.6. Verschlüsselungsdienst FDP_ACC.1/AK.Enc Subset access control / Verschlüsselung Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.1.1/AK.Enc The TSF shall enforce the Verschlüsselung-SFP385 on subjects: (1) S_AK, (2) S_Verschlüsselungsdienst; objects: (1) Zu verschlüsselnde Daten, (2) Verschlüsselte Daten, (3) Zu entschlüsselnde Daten, (4) Entschlüsselte Daten; operations: (1) Verschlüsseln, (2) Entschlüsseln, (3) Festlegen der vorgesehenen Empfänger386 Operation Beschreibung Anmerkung Verschlüsseln Hybridverschlüsselung von XML-Dokumenten gemäß FCS_COP.1/AK.XML.Ver und beliebige Datendateien nach FCS_COP.1/AK.CMS.Ver oder symmetrische Verschlüsselung von Daten gemäß FCS_COP.1/AK.AES Entschlüsseln Hybridentschlüsselung von XML-Dokumenten mit Unterstützung der Chipkarte für die asymmetrische 381 [assignment: access control SFP(s) and/or information flow control SFP(s)] 382 [selection: transmit, receive] 383 [selection: modification, deletion, insertion, replay] 384 [selection: modification, deletion, insertion, replay] 385 [assignment: access control SFP] 386 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] Security Target secunet konnektor 2.1.0 Seite 266 von 424 secunet Entschlüsselung gemäß FCS_COP.1/AK.XML.Ent und beliebige CMS-Datendateien nach FCS_COP.1/AK.CMS.Ent oder symmetrische Entschlüsselung von Daten gemäß FCS_COP.1/AK.AES Festlegen der vorgesehenen Empfänger Durch S_AK werden die zu verschlüsselnde Daten an das Subjekt S_Verschlüsselungsdienst mit der Identität der vorgeschlagenen Empfängern übergeben. Tabelle 23: Operationen des Verschlüsselungsdienstes FDP_ACF.1/AK.Enc Security attribute based access control / Verschlüsselung Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation FDP_ACF.1.1/AK.Enc The TSF shall enforce the Verschlüsselung-SFP 387 to objects based on the following: subjects: (1) S_AK, (2) S_Verschlüsselungsdienst; objects: (1) Zu verschlüsselnde Daten with security attributes: (a)Verschlüsselungsrichtlinie, (b)Vorgeschlagene Empfänger, (c)Objekt-ID, (2) verschlüsselte Daten with security attributes: (a)Verschlüsselungsrichtlinie, (b)Vorgeschlagene Empfänger, (c)Ordnungsgemäss verschlüsselt, (3) Zu entschlüsselnde Daten with security attributes: (a)Verschlüsselungsrichtlinie, (b)Vorgeschlagene Empfänger (4) Entschlüsselte Daten .388 FDP_ACF.1.2/AK.Enc The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: 387 [assignment: access control SFP] 388 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes] Security Target secunet konnektor 2.1.0 secunet Seite 267 von 424 (1) Das Subjekt S_AK muss zu verschlüsselnde Daten an das Subjekt Verschlüsselungsdienst mit der Objekt-ID, der Identität der Verschlüsselungsrichtlinie und der Identität der vorgeschlagenen Empfängern übergeben. (2) Das Subjekt Verschlüsselungsdienst darf nur ordnungsgemäß verschlüsselte Daten oder Statusmeldungen an das Subjekt S_AK zurückgeben. (3) Das Subjekt Verschlüsselungsdienst darf nur dann die zu verschlüsselnden Daten für die identifizierten vorgeschlagenen Empfänger automatisch verschlüsseln, wenn (a) die identifizierte Verschlüsselungsrichtlinie für die übergebenen zu verschlüsselnden Daten zulässig ist, (b) die identifizierte Verschlüsselungsrichtlinie die automatische Verschlüsselung erlaubt, (c) die Verschlüsselungszertifikate der vorgeschlagenen Empfänger gültig sind. (4) Das Subjekt S_AK darf zu entschlüsselnde Daten an das Subjekt Verschlüsselungsdienst nur mit Identität eines vorgesehenen Empfängers, dessen Chipkarte für die Entschlüsselung benutzt werden soll, und der Identität der zum Entschlüsseln zu verwendenden Verschlüsselungsrichtlinie an das Subjekt Verschlüsselungsdienst übergeben. (5) Das Subjekt Verschlüsselungsdienst darf nur dann die verschlüsselten Daten automatisch für die identifizierten vorgesehenen Empfänger entschlüsseln und die entschlüsselten Daten an die Subjekt S_AK zurückgeben, wenn (a) die identifizierte Verschlüsselungsrichtlinie für die übergebenen zu verschlüsselten Daten zulässig ist, (b) die identifizierte Verschlüsselungsrichtlinie die automatische Entschlüsselung erlaubt, (c) der Sicherheitsstatus der Chipkarte des identifizierten vorgesehenen Empfängers das Entschlüsseln des Dateischlüssels erlaubt. .389 FDP_ACF.1.3/AK.Enc The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [none]390 . FDP_ACF.1.4/AK.Enc The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [none]391 . 389 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects]. 390 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]. 391 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]. Security Target secunet konnektor 2.1.0 Seite 268 von 424 secunet Anwendungshinweis 176: Alle Verschlüsselungsrichtlinie für Konnektoren erlauben das automatische Verschlüsseln und Entschlüsseln von Daten. Die zum Entschlüsseln zu verwendende Chipkarte hängt von dem identifizierten vorgesehenen Empfänger und der auszuführenden Anwenungen ab. FDP_ITC.2/AK.Enc Import of user data with security attributes / Verschlüsselungsdienst Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] FPT_TDC.1 Inter-TSF basic TSF data consistency FDP_ITC.2.1/AK.Enc The TSF shall enforce the Verschüsselungs-SFP392 when importing user data, controlled under the SFP, from outside of the TOE. FDP_ITC.2.2/AK.Enc The TSF shall use the security attributes associated with the imported user data. FDP_ITC.2.3/AK.Enc The TSF shall ensure that the protocol used provides for the unambiguous association between the security attributes and the user data received. FDP_ITC.2.4/AK.Enc The TSF shall ensure that interpretation of the security attributes of the imported user data is as intended by the source of the user data. FDP_ITC.2.5/AK.Enc The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TOE: (1) Die TSF importiert zu verschlüsselnde Daten mit dem Sicherheitsattribut „Verschlüsselungsrichtlinie“ nur für die identifizierten Fachanwendungen bzw. Anwendungsfälle und implementierten Verschlüsselungsrichtlinien. (2) Die TSF importiert Verschlüsselungszertifikate und zu verschlüsselnde Daten mit dem Sicherheitsattribut „vorgeschlagene Empfänger“ nur nach erfolgreicher Prüfung der Gültigkeit der Verschlüsselungszertifikate der vorgesehenen Empfänger. (3) Die TSF importiert TI-fremde X.509 CA-Zertifikate durch den Administrator über die Management-Schnittstelle .393 392 [assignment: access control SFP(s) and/or information flow control SFP(s)] 393 [assignment: additional importation control rules] Security Target secunet konnektor 2.1.0 secunet Seite 269 von 424 Anwendungshinweis 177: Die Verschlüsselungsrichtlinie ist eindeutig durch die Fachanwendung bzw. innerhalb der Fachanwendung durch den Anwendungsfalls festgelegt und muss dem Verschlüsselungs- dienst für die übergebenen Daten angezeigt werden. Ein Verschlüsselungszertifikat ist gültig, wenn  Entweder (i) seine Integrität durch eine Zertifikatskette bis zu einer Instanz aus der TSL mit als authentisch bekannten öffentlichen Schlüssel erfolgreich geprüft wurde und (ii) das Verschlüsselungszertifikat nicht gesperrt ist (Prüfung mittels OCSP-Abfrage),  oder seine Integrität durch eine Zertifikatskette bis zu einer Instanz aus der Liste der TI- fremden CA-Zertifikate für die hybride Verschlüsselung (CERT_IMPORTED_CA_LIST) mit als authentisch bekannten öffentlichen Schlüssel erfolgreich geprüft wurde. FDP_ETC.2/AK.Enc Export of user data with security attributes / Verschlüsselungsdienst Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FDP_ETC.2.1/AK.Enc The TSF shall enforce the Verschüsselungs-SFP394 when exporting user data, controlled under the SFP(s), outside of the TOE. FDP_ETC.2.2/AK.Enc The TSF shall export the user data with the user data's associated security attributes FDP_ETC.2.3/AK.Enc The TSF shall ensure that the security attributes, when exported outside the TOE, are unambiguously associated with the exported user data. FDP_ETC.2.4/AK.Enc The TSF shall enforce the following rules when user data is exported from the TOE: (1) Die TSF exportieren verschlüsselte Daten mit der Identität des vorgesehenen Empfängers bzw. den Identitäten der vorgesehenen Empfänger und der Identität der verwendeten Verschlüsselungsrichtlinie. (2) Die TSF exportieren entschlüsselte Daten mit der Identität des vorgesehenen Empfängers, dessen Chipkarte zum Entschlüsseln benutzt wurde. (3) [none] 395 . .396 6.3.3.7. TLS-Kanäle Dieses Kapitel beschreibt die Anforderungen, die an die TLS-Kanäle des EVG gestellt werden, die durch den TLS-Dienst für die Kommunikationsverbindungen: 394 [assignment: access control SFP(s) and/or information flow control SFP(s)] 395 [assignment: additional exportation control rules] 396 [assignment: additional exportation control rules] Security Target secunet konnektor 2.1.0 Seite 270 von 424 secunet - Von Fachmodulen zu den Fachdiensten - Von Clientsystemen mit dem EVG Konnektor - EVG zum Verzeichnisdienst - EVG zum Konfigurationsdienst - EVG zum TSL-Dienst für den Download der BNetzA-VL und deren Hash-Wert genutzt werden. Gemäß TIP1-A_7254 in [27] muss der EVG bei einem Aufbau von TLS-gesicherten Verbindungen zu einem zentralen Dienst der TI-Plattform oder zu einem fachanwendungsspezifischen Dienst bei folgenden OCSP-Antworten, die der EVG entsprechend FTP_ITC.1/NK.TLS ermittelt, mit einem Abbruch des Verbindungsaufbaus reagieren: •CERT_REVOKED; •CERT_UNKNOWN; •OCSP_CHECK_REVOCATION_FAILED. Die Behandlung anderer etwaiger Fehlerfälle bei einem TLS-Verbindungsaufbau bleiben dadurch unberührt. Die genannte Verschärfung wurde in diesen Sicherheitsvorgaben dadurch berücksichtigt, dass in FDP_ACF.1/AK.TLS, Fußnote 266, eine explizit verbietende Regel für die Zuweisung, die BSI CC PP 0098 vorsieht, eingesetzt wurde. FDP_ACC.1/AK.TLS Subset access control / TLS-Kanäle Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.1.1/AK.TLS The TSF shall enforce the AK-TLS-SFP397 on subjects: (1) S_AK, (2) S_NK (3) S_Clientsystem, (4) S_Fachmodul, (5) S_ Fachdienst, (6) S_Verzeichnisdienst (VZD), (7) S_KSR (8) S_TSL_Dienst (9) S_Administrator objects: (1) Zu sendende Daten, 397 [assignment: access control SFP] Security Target secunet konnektor 2.1.0 secunet Seite 271 von 424 (2) Empfangene Daten, (3) TLS-Kanal operations: (1) Aufbau des TLS-Kanals, (2) Abbau des TLS-Kanals (3) Unterbrechen und Wiederaufnahme der TLS-Verbindung mit Session ID (nur VSDM), (4) Anfordern zur Wiederaufnahme einer TLS- Verbindung mit Session ID (nur VSDM), (5) senden (6) empfangen 398 . Operation Beschreibung Anmerkung Aufbau des TLS- Kanals Vor Beginn der geschützten Datenübertragung wird ein TLS- Kanal zum Kommunikationspartner aufgebaut: (1) Bei der Kommunikation des EVG mit S_Verzeichnisdienst (VZD), S_KSR oder S_TSL_Dienst wird eine einseitige (Server) Authentifizierung (Identität C.ZD.TLS-S) durch den EVG durchgeführt. (2) Bei der Kommunikation des EVG mit S_ Fachdienst findet je nach Aufruf durch S_ Fachdienst eine einseitige (Server) oder beidseitige Authentisierung statt. Der EVG nutzt bei der beidseitigen Authentisierung die C.HCI.AUT Identität des X.509 Zertifikats auf der SMC-B für die Client-Authentisierung. S_ Fachdienst nutzt stets das X.509 Zertifikat C.FD.TLS-S für die Server-Authentisierung. Algorithmen und Schlüssel für die Kanalverschlüsselung werden mit dem Kommunika- tionspartner ausgehandelt. Dem TLS-Kanal wird ein TLSConnectionIdentifier zugeordnet. 398 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] Security Target secunet konnektor 2.1.0 Seite 272 von 424 secunet Operation Beschreibung Anmerkung (3) Bei der Kommunikation des EVG mit S_Clientsystem muss der Konnektor als TLS-Server die Authentifizierung des Client- systems mit den Verfahren Basic Authentication (Username/ Pass- word) [RFC2617] über http/TLS [RFC2818] und zertifikatsbasierte Client- Authentifizierung (X.509) [gemSpec_PKI#8.3.1.4] über TLS anbieten (vergl. [27], Kap. 3.4). Der EVG nutzt in diesem Fall das Schlüsselmaterial der Identität des X.509 Zertifikats C.AK.AUT der gSMC-K oder ein X.509 Zertifikats das entsprechend FCS_CKM.1/NK.Zert erzeugt bzw. entsprechend FDP_ITC.2/NK.TLS importiert wurde (ID.AK.AUT). (4) Bei der Kommunikation des EVG mit gepaarten Kartenterminals findet eine beidseitige Authentisierung statt. Das Kartenterminal nutzt hier das Schlüsselmaterial des C.SMKT_AUT Zertifikates. Der EVG verwendet das Schlüsselmaterial der Identität ID.SAK.AUT. Abbau des TLS- Kanals Nach Ende der Kommunikation wird der TLS-Kanal abgebaut. Die Schlüssel werden sicher gelöscht und die Ressourcen werden freigegeben. Unterbrechen und Wiederaufnahme der TLS- Verbindung mit Session ID (nur VSDM) Unterbrechen und Wiederaufnahme einer TLS-Verbindung zwischen S_Fachmodul (VSDM) und Intermediär durch TLS Session Resumption mittels Session-ID gemäß RFC 5246. TLS Session Resumption ist nur zulässig, wenn das Schlüssel- material nicht älter als 24 Stunden ist. Anfordern zur Wiederaufnahme Das S_Fachmodul (VSDM) fordert die Wiederaufnahme der Sitzung des Der Intermediär VSDM kann die Wiederaufnahme der Sitzung Security Target secunet konnektor 2.1.0 secunet Seite 273 von 424 Operation Beschreibung Anmerkung einer TLS- Verbindung (nur VSDM) Kanals unter Verwendung des Session-ID gemäß RFC 5246, Kap. 7.3, beim Intermediär VSDM an. des Kanals mit Session-ID akzeptieren oder ablehnen. Senden Die zu übertragenden Daten werden vor Übertragung verschlüsselt und integritätsgeschützt Die beim Kanal-Aufbau ausgehandelten Algorithmen und Sitzungs-Schlüssel werden verwendet. Empfangen Die empfangenen Daten werden entschlüsselt und integritätsgeprüft. Es werden unverfälscht empfangene Daten ausgegeben. Die beim Kanal-Aufbau ausgehandelten Algorithmen und Sitzungs-Schlüssel werden verwendet. Tabelle 24: Operationen der TLS-Kanäle FDP_ACF.1/AK.TLS Security attribute based access control / TLS-Kanäle Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation FDP_ACF.1.1/AK.TLS The TSF shall enforce the AK-TLS-SFP399 to objects based on the following: subjects: (1) S_AK, (2) S_NK (3) S_Clientsystem, (4) S_Fachmodul with or without the security attribute “VSDM (VSDM-Fachmodul)”, (5) S_ Fachdienst with or without the security attribute “Intermediär VSDM (Intermediär VSDM)”, (6) S_Verzeichnisdienst (VZD), (7) S_KSR (8) S_TSL_Dienst objects: (1) Zu sendende Daten, (2) Empfangene Daten, 399 [assignment: access control SFP] Security Target secunet konnektor 2.1.0 Seite 274 von 424 secunet (3) TLS-Kanal with the security attribute „Anfordernder TLS- Client“ .400 FDP_ACF.1.2/AK.TLS The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: (1) Das S_AK baut auf Anforderung des Fachmoduls die TLS- Verbindung zum Fachdienst (TLS Server) auf und gibt den TLSConnectionIdentifier an den Aufrufenden zurück. (2) Auf Anforderung des Clientsystems (als TLS Client) baut das S_AK (als TLS-Server) ein TLS-Kanal zum Clientsystem auf. (3) Nur der anfordernde TLS-Client darf unter Angabe des TLSConnectionIdentifiers zu sendende Daten an das S_AK zur Übertragung im TLS-Kanal übergeben. (4) Das S_AK darf über den TLS-Kanal empfangene Daten nur an den anfordernden TLS-Client übergeben. (5) Nur der anfordernde TLS-Client darf den S-AK zum Abbau des TLS-Kanals auffordern. (6) Wenn MGM_LU_ONLINE=Enabled darf das S_AK ein SessionID des Intermediär VSDM empfangen und dem TLSConnectionIdentifier zuordnen. Das S_AK darf auf Anforderung des VSDM-Fachmoduls die unterbrochene Sitzung des TLS-Kanals zum Intermediär VSDM mit dem SessionID wiederaufnehmen, wenn das über den Diffie-Hellman- Schlüsselaustausch ausgehandelte Schlüsselmaterial und alles davon abgeleitete Schlüsselmaterial nicht älter als 24 Stunden ist. (7) Wenn MGM_LU_ONLINE=Enabled und MGM_LOGICAL_SEPARATION=Disabled dann baut das S_AK mit dem LDAP-Proxy auf Anforderung des Clientsystems oder eines Fachmoduls (Search Request) eine LDAPv3 Verbindung zum VZD auf. (8) Wenn MGM_LU_ONLINE=Enabled und MGM_LOGICAL_SEPARATION=Disabled dann baut das S_AK mit dem LDAP-Proxy auf Anforderung des Clientsystems oder eines Fachmoduls (Unbind Request) eine LDAPv3 Verbindung zum VZD ab. (9) Wenn ANCL_TLS_MANDATORY = Enabled so nimmt S_AK die Aufforderung des Clientsystems zum Aufbau eines TLS-Kanals entgegen und darf nur über diesen Kanal mit Clientsystemen 400 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes] Security Target secunet konnektor 2.1.0 secunet Seite 275 von 424 kommunizieren. Ausgenommen ist die Kommunikation mit Dienstverzeichnisdienst bei gesetzter Variable ANCL_DVD_OPEN = Enabled. (10) Die Subjekte S_NK und S_AK dürfen für den Download von Firmware-Update-Paketen einen TLS-Kanal zum S_KSR aufbauen. (11) Das S_AK baut für den Download der BNetzA-VL und deren Hash-Wert und TSL-Hash-Werte einen TLS-Kanal zum TSL-Dienst auf. (12) [none]401 . 402 . FDP_ACF.1.3/AK.TLS The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [none]403 . FDP_ACF.1.4/AK.TLS The TSF shall explicitly deny access of subjects to objects based on the following additional rules: (1) Wenn MGM_LU_ONLINE = “Disabled“, DARF der Basisdienst TLS-Dienst nach dem Bootup NICHT TLS-Kanäle zur Verfügung stellen. (2) Der Intermediär VSDM kann die Nutzung der SessionID zur Wiederaufnahme der TLS-Verbindung ablehnen und den Aufbau einer TLS-Verbindung verlangen. (3) Wenn MGM_LU_ONLINE = “Disabled“ oder MGM_LOGICAL_SEPARATION=Enabled, DARF die Verzeichnisverwaltung NICHT TLS-Kanäle zum VZD zur Verfügung stellen. (4) The TSF shall perform den Kanal zum VZD 15 Minuten nach der letzten vom VZD empfangenen oder von der Verzeichnisverwaltung des EVG gesendeten Daten abbauen. (5) [Falls bei einer Verbindung zu einem der Subjekte S_ Fachdienst, S_TSL_Dienst, S_KSR, S_VSDD_Fachdienst oder S_Verzeichnisdienst (VZD) die OCSP-Antwort  CERT_REVOKED, oder  CERT_UNKNOWN, oder  OCSP_CHECK_REVOCATION_FAILED lautet, so muss der EVG den Verbindungsaufbau abbrechen] 404 401 [assignment: additional rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects]. 402 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects]. 403 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]. 404 [assignment: additional rules, based on security attributes, that explicitly deny access of subjects to objects] Security Target secunet konnektor 2.1.0 Seite 276 von 424 secunet 405 . Anwendungshinweis 178: [30] bestimmt in GS-A_5322, dass der EVG im Rahmen von TLS-Session- Resumption mittels SessionID (vgl. [RFC-5246, Abschnitt 7.4.1.2]) nach spätestens 24 Stunden das über den Diffie-Hellman-Schlüsselaustausch ausgehandelte Schlüsselmaterial und alles davon abgeleitete Schlüsselmaterial (vgl. [RFC-5246, Abschnitt 8.1 und 6.3]) sowie damit verbundene SessionIDs sicher gelöscht werden. Das Fachmodul VSDM und der Intermediär VSDM müssen für die Verbindung zwischen Fachmodul und Intermediär TLS Session Resumption mittels Session-ID gemäß RFC 5246 nutzen, um für den wiederholten Aufbau von TLS-Verbindungen die bereits ausgehandelten Session- Parameter zu nutzen. Anwendungshinweis 179: Der Konnektor muss beim TLS-Verbindungsaufbau den OCSP-Status des TLS-Serverzertifikates gemäß TIP1-A_7254 [27] beachten. FMT_MSA.1/AK.TLS Management of security attributes / TLS-Kanäle Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions. FMT_MSA.1.1/AK.TL S The TSF shall enforce the AK-TLS-SFP406 to restrict the ability to change_default, query, modify, delete, [no other operations]407 the security attributes [Authentisierungsmechanismus]408 to S_Administrator409 . Änderungen der Konfiguration müssen unmittelbar durchgesetzt werden. Anwendungshinweis 180: Die in FMT_MSA.1/AK.TLS definierte Verfeinerung bezieht sich insbesondere auf solche Konfigurationen, die die Art der akzeptierten Authentisierungsmechanismen betreffen, etwa ANCL_CAUT_MODE [27]. 405 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] 406 [assignment: access control SFP(s), information flow control SFP(s)] 407 [assignment: other operations], (die Auswahl wurde im PP vorgenommen, alle 4 vordefinierten Werte wurden ausgewählt, außerdem wurde die Möglichkeit, andere Optionen zuzuweisen, ebenfalls zugelassen) 408 [assignment: list of security attributes] 409 [assignment: the authorised identified roles] Security Target secunet konnektor 2.1.0 secunet Seite 277 von 424 FMT_MSA.3/AK.TLS Static attribute initialisation / TLS-Kanäle Hierarchical to: No other components. Dependencies: FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1/AK.TLS The TSF shall enforce the AK-TLS-SFP410 to provide [restrictive]411 default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2/AK.TLS The TSF shall allow the S_Administrator412 to specify alternative initial values to override the default values when an object or information is created. FTP_ITC.1/AK.FD Inter-TSF trusted channel / Zum Fachdienst Hierarchical to: No other components. Dependencies: No dependencies. FTP_ITC.1.1/AK.FD The TSF shall provide a communication channel between itself and a S_ Fachdienst another trusted IT product that is logically distinct from other communication channels and provides assured identification of S_ Fachdienst mit dem Zertifikat C.FD.TLS-S gegenüber dem EVG und EVG mit dem Zertifikat C.HCI.AUT gegenüber S_Fachdienst wenn von S_Fachmodul gefordert its end points and protection of the channel data from modification and or disclosure. FTP_ITC.1.2/AK.FD The TSF shall permit the TSF413 to initiate communication via the trusted channel FTP_ITC.1.3/AK.FD The TSF shall initiate communication via the trusted channel for die Bearbeitung von fachlichen Anwendungsfällen, die eine Online- Kommunikation mit Fachdiensten erfordern414 Anwendungshinweis 181: Die Verfeinerung des Elementes FTP_ITC.1/AK.FD konkretisiert das vertrauenswürdige Produkt. Die allgemeine Formulierung „einem anderen vertrauenswürdigen IT-Produkt“ wurde durch „Fachdienst“ verfeinert. Die TSF baut vertrauenswürdige Kanäle zu dem Fachdienst auf, wobei die Authentisierung der Endpunkte je nach Aufruf durch das Fachmodul beidseitig ist oder auf den Fachdienst eingeschränkt wird. FTP_ITC.1/AK.VZD Inter-TSF trusted channel / Zum zentralen Verzeichnisdienst 410 [assignment: access control SFP, information flow control SFP] 411 [selection, choose one of: restrictive, permissive, [assignment: other property]] 412 [assignment: the authorised identified roles] 413 [selection: the TSF, another trusted IT product] 414 [assignment: list of functions for which a trusted channel is required] Security Target secunet konnektor 2.1.0 Seite 278 von 424 secunet Hierarchical to: No other components. Dependencies: No dependencies. FTP_ITC.1.1/AK.VZD The TSF shall provide a communication channel between itself and S_Verzeichnisdienst (VZD) another trusted IT product that is logically distinct from other communication channels and provides assured identification of S_Verzeichnisdienst (VZD) mit dem Zertifikat C.ZD.TLS-S gegenüber dem EVG its end points and protection of the channel data from modification and or disclosure. FTP_ITC.1.2/AK.VZD The TSF shall permit the TSF415 to initiate communication via the trusted channel. FTP_ITC.1.3/AK.VZD The TSF shall initiate communication via the trusted channel for MGM_LU_ONLINE=Enabled und MGM_LOGICAL_SEPARATION=Disabled des TUC_KON_290 „LDAP-Verbindung aufbauen“416 . Anwendungshinweis 182: Die Verfeinerung des Elementes FTP_ITC.1/VZD konkretisiert das vertrauenswürdige Produkt. Die allgemeine Formulierung „einem anderen vertrauenswürdigen IT-Produkt“ wurde durch „zentralen Verzeichnisdienst“ verfeinert. Die TSF baut vertrauenswürdige Kanäle zu dem zentralen Verzeichnisdienst (VZD) auf, wobei die Authentisierung der Endpunkte auf den VZD eingeschränkt wird. Gemäß OE.Fachdienste können nur verrauenswprdige Entitäten auf den VZD zugreifen. FTP_ITC.1/AK.KSR Inter-TSF trusted channel / Zum KSR (Update-Server) Hierarchical to: No other components. Dependencies: No dependencies. FTP_ITC.1.1/AK.KSR The TSF shall provide a communication channel between itself and S_KSR another trusted IT product that is logically distinct from other communication channels and provides assured identification of S_KSR mit dem Zertifikat C.ZD.TLS-S gegenüber dem EVG its end points and protection of the channel data from modification and or disclosure.. FTP_ITC.1.2/AK.KSR The TSF shall permit the TSF417 to initiate communication via the trusted channel. FTP_ITC.1.3/AK.KSR The TSF shall initiate communication via the trusted channel for Prüfung auf neue Firmware-Update-Pakete und Download neuer Firmware-Update-Pakete418 . 415 [selection: the TSF, another trusted IT product] 416 [assignment: list of functions for which a trusted channel is required] 417 [selection: the TSF, another trusted IT product] 418 [assignment: list of functions for which a trusted channel is required] Security Target secunet konnektor 2.1.0 secunet Seite 279 von 424 Anwendungshinweis 183: Die Verfeinerung des Elementes FTP_ITC.1/KSR konkretisiert das vertrauenswürdige Produkt. Die allgemeine Formulierung „einem anderen vertrauenswürdigen IT-Produkt“ wurde durch „KSR“ verfeinert. Die TSF baut vertrauenswürdige Kanäle zu dem KSR (Update-Server) auf, wobei die Authentisierung der Endpunkte auf den KSR eingeschränkt wird. FTP_ITC.1/AK.TSL Inter-TSF trusted channel / Zum TSL-Dienst Hierarchical to: No other components. Dependencies: No dependencies. FTP_ITC.1.1/AK.TSL The TSF shall provide a communication channel between itself and S_TSL_Dienst another trusted IT product that is logically distinct from other communication channels and provides assured identification of S_TSL_Dienst mit dem Zertifikat C.ZD.TLS-S gegenüber dem EVG its end points and protection of the channel data from modification and or disclosure.. FTP_ITC.1.2/AK.TSL The TSF shall permit the TSF419 to initiate communication via the trusted channel. FTP_ITC.1.3/AK.TSL The TSF shall initiate communication via the trusted channel for Download des TSL-Hashwertes, BNetzA-VL Hashwerts und Download der BNetzA-VL420 . Anwendungshinweis 184: Die Verfeinerung des Elementes FTP_ITC.1/TSL konkretisiert das vertrauenswürdige Produkt. Die allgemeine Formulierung „einem anderen vertrauenswürdigen IT-Produkt“ wurde durch „TSL-Dienst“ verfeinert. Die TSF baut vertrauenswürdige Kanäle zu dem TSL-Dienst auf, wobei die Authentisierung der Endpunkte auf den TSL-Dienst eingeschränkt wird. 419 [selection: the TSF, another trusted IT product] 420 [assignment: list of functions for which a trusted channel is required] Security Target secunet konnektor 2.1.0 Seite 280 von 424 secunet FTP_ITC.1/AK.CS Inter-TSF trusted channel / Clientsystem Hierarchical to: No other components. Dependencies: No dependencies. FTP_ITC.1.1/AK.CS The TSF shall provide a communication channel between itself and a Clientsystem in the LAN another trusted IT product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification and or disclosure. FTP_ITC.1.2/AK.CS The TSF shall permit the Clientsystem421 to initiate communication via the trusted channel. FTP_ITC.1.3/AK.CS The TSF shall initiate communication via the trusted channel for ANCL_TLS_MANDATORY = Enabled422 to the Clientsystem and reject or cancel a communication with the Clientsystem outside the TLS channel. This includes access to the service directory service. A communication with the service directory service outside the TLS channel is only permitted if ANCL_DVD_OPEN is set to “Enabled”. Anwendungshinweis 185: Die Verfeinerung des Elementes FTP_ITC.1/AK.CS konkretisiert das vertrauenswürdige Produkt. Die allgemeine Formulierung „einem anderen vertrauenswürdigen IT-Produkt“ wurde durch „Clientsystem im LAN“ verfeinert. Die Verfeinerung im Element FTP_ITC.1.3/CS soll klar stellen, dass in der speziellen Konfiguration der TSF ANCL_TLS_MANDATORY = Enabled die TLS-Kommunikation mit Ausnahme des Dienstverzeichnisdienstes erzwungen wird, während sie für ANCL_TLS_MANDATORY = Disabled auch Kommunikation außerhalb TLS erlaubt ist. Der Dienstverzeichnisdienst ist innerhalb des TLS-Kanals und im Fall ANCL_DVD_OPEN = Enabled auch außerhalb des TLS-Kanals erreichbar (s. [27], Kapitel 3.4.1). Da der TLS-Kanal einen Schutz des EVG gegen Missbrauch bietet, sollte die ungeschützte offene Kommunikation auf den Dienstverzeichnisdienst begrenzt werden. FTP_ITC.1/AK.eHKT Inter-TSF trusted channel / eHKT Hierarchical to: No other components. Dependencies: No dependencies. FTP_ITC.1.1/AK.eHKT The TSF shall provide a communication channel between itself and another eHealth-Kartenterminal trusted IT product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification and or disclosure. Die TSF muss einen Keep-Alive-Mechanismus der TLS- Verbindung zu den eHealth-Kartenterminals implementieren. 421 [selection: the TSF, another trusted IT product] 422 [assignment: list of functions for which a trusted channel is required] Security Target secunet konnektor 2.1.0 secunet Seite 281 von 424 FTP_ITC.1.2/AK.eHKT The TSF shall permit another trusted IT product423 eHealth- Kartenterminal to initiate communication via the trusted channel FTP_ITC.1.3/AK.eHKT The TSF shall initiate communication via the trusted channel for Senden von SICCT-Kommandos an eHealth-Kartenterminals und Empfangen von SICCT-Antworten der eHealth-Kartenterminals an den EVG424 . Anwendungshinweis 186: Die Verfeinerung des Elementes FTP_ITC.1/AK.eHKT konkretisiert das vertrauenswürdige Produkt. Die allgemeine Formulierung „einem anderen vertrauenswürdigen IT-Produkt“ wurde durch „eHealth-Kartenterminal“ verfeinert. 6.3.3.8. Sicherer Datenspeicher FDP_ACC.1/AK.SDS Subset access control / Sicherer Datenspeicher Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.1.1/AK.SDS The TSF shall enforce the SDS-SFP425 on subjects: (1) S_AK, (2) S_Fachmodul, (3) S_Administrator objects: (1) Schlüssel für sicheren Datenspeicher, (2) Datenobjekte des sicheren Datenspeichers, operations: (1) lesen (2) schreiben .426 Operation Beschreibung Anmerkung Lesen Für den Zugriff auf den Inhalt des sicheren (geschützten) Datenspeichers durch den Konnektor ist die Nutzung des Der sichere Datenspeicher muss während der gesamten Betriebszeit des Konnektors zur Verfügung 423 [selection: the TSF, another trusted IT product] 424 [assignment: list of functions for which a trusted channel is required] 425 [assignment: access control SFP] 426 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] Security Target secunet konnektor 2.1.0 Seite 282 von 424 secunet Schlüsselmaterials erforderlich. Dazu muss dieser gelesen werden können. stehen, so dass das Lesen des Schlüsselmaterials jeweils zu Beginn des Betriebes erfolgen soll. Schreiben Der Schreibzugriff auf das Schlüsselmaterial ist zur Erstellung und Änderung des Schlüssels erforderlich. Die Erstellung der Schlüssel sollte einmalig durch den Administrator erfolgen. Optional kann ein Schlüsselwechsel durch den Administrator vorgesehen werden. Tabelle 25: Operationen zum Zugriff auf die eGK im Rahmen von VSDM FDP_ACF.1/AK.SDS Security attribute based access control / Sicherer Datenspeicher Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation FDP_ACF.1.1/AK.SDS The TSF shall enforce the SDS-SFP427 to objects based on the following: subjects: (1) S_AK, (3) S_Fachmodul, (4) S_Administrator objects: (1) Datenobjekte des sicheren Datenspeichers, (2) Datenobjekte des sicheren Datenspeichers with security attribute Administratorobjekt.428 FDP_ACF.1.2/AK.SDS The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: (1) Das S_AK darf Datenobjekte im sicheren Datenspeicher nur verschlüsselt speichern. (2) Das S_AK darf nach Inbetriebnahme des Konnektors die Datenobjekte des SDS mit dem Sicherheitsattribut „allgemeines Datenobjekt“ lesen, entschlüsseln und außerhalb des sicheren Datenspeichers nur temporär speichern, 427 [assignment: access control SFP] 428 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes] Security Target secunet konnektor 2.1.0 secunet Seite 283 von 424 (3) Das S_Fachmodul darf Daten an den S_AK übergeben und vom S_AK empfangen, die der S_AK als Datenobjekte des SDS mit dem Sicherheitsattribut „allgemeines Datenobjekt“ speichert, (4) Datenobjekte des SDS mit dem Sicherherheitsattribut „Adminstratorobjekt“ darf nur innerhalb einer Administratorsitzung entschlüsselt und gelesen und verschlüsselt und geschrieben werden, aber nicht außerhalb der Administratorsitzung gespeichert werden, (5) [no additional rules] 429 . 430 FDP_ACF.1.3/AK.SDS The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [none] 431 . FDP_ACF.1.4/AK.SDS The TSF shall explicitly deny access of subjects to objects based on the following additional rules: (1) Das S_AK darf Datenobjekte des SDS mit dem Sicherherheitsattribut „Adminstratorobjekt“ weder lesen noch entschlüsseln. (2) Das S_AK darf keine Datenobjekte des SDS mit dem Sicherherheitsattribut „Adminstratorobjekt“ speichern oder modifizieren. (3) [no additional rules,] 432 . 433 Anwendungshinweis 187: Der sichere Datenspeicher ist in Form einer transparenten Speicherverschlüsselung (CFS) realisiert. Temporär gespeicherte Datenobjekte aus dem sicheren Datenspeicher sind im abgeschalteten Zustand des Konnektors nicht zugänglich. Für den Zugriff auf die dazu nötigen Schlüssel wird die gSMC-K (als Speicherort) verwendet. Anwendungshinweis 188: Das CFS setzt eine transparente Speicherverschlüsselung um. Klartextdaten werden dabei in den temporären Speicher geladen (volatile memory). Bei ausgeschaltetem Konnektor ist der temporäre Speicher leer und die Inhalte des sicheren Datenspeichers liegen nur noch in vereschlüsselter Form im CFS. Das CFS wird im Rahmen des sicheren Bootvorgangs initialisiert. Der verschlüsselt im Konnektor abgelegte CFS-Schlüssel wird durch den in der gSMC-K sicher gespeicherten asymmetrischen Schlüssel entschlüsselt. Anwendungshinweis 189: Datenobjekte des SDS mit dem Sicherherheitsattribut „Adminstratorobjekt“ werden vom Konnektor nicht unterstützt. 429 [assignment: additional rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects]. 430 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects]. 431 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]. 432 [assignment: additional rules, based on security attributes, that explicitly deny access of subjects to objects]. 433 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]. Security Target secunet konnektor 2.1.0 Seite 284 von 424 secunet 6.3.3.9. Fachmodule FDP_ACC.1/AK.VSDM Subset access control / VSDM Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.1.1/AK.VSDM The TSF shall enforce the VSDM-SFP434 on subjects: (1) S_AK, (2) S_VSDM_Fachmodul, (3) S_VSDM_Intermediär, (4) S_VSDD_Fachdienst, (5) S_CMS, (6) S_eGK (7) S_Administrator; objecte: (1) Daten der Chipkarten (Versichertenstammdaten), (2) Objektsystem der Chipkarte (eGK); operations: (1) Lesen der Versichertenstammdaten, (2) Schreiben der Versichertenstammdaten, (3) Ergänzen des Objektsystems .435 Operation Beschreibung Anmerkung Lesen der Versichertenstammdaten Lesen der Versicherten- stammdaten der eGK Diese Operation kann die Kartenkommandos SELECT, SEARCH BINARY, READ BINARY, SEARCH RECORD, READ RECORD erfordern Schreiben der Versichertenstammdaten Schreiben oder Modifizieren der Diese Operation kann die Kartenkommandos SELECT, ERASE BINARY, , UPDATE BINARY, WRITE BINARY, 434 [assignment: access control SFP] 435 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] Security Target secunet konnektor 2.1.0 secunet Seite 285 von 424 Versicherten- stammdaten der eGK APPEND RECORD, ERASE RECORD, UPDATE RECORD, WRITE RECORD erfordern Ergänzen des Objektsystems Anlegen neuer Objekte des Objektsystems der eGK Diese Operation erfordert die Kartenkommandos SELECT und LOAD APPLICATION. Tabelle 26: Operationen zum Zugriff auf die eHK im Rahmen von VSDM FDP_ACF.1/AK.VSDM Security attribute based access control / VSDM Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation FDP_ACF.1.1/AK.VSDM The TSF shall enforce VSDM-SFP436 to objects based on the following: subjects: (1) S_AK, (2) S_VSDM_Fachmodul, (3) S_VSDM_Intermediär, (4) S_VSDD_Fachdienst, (5) S_CMS, (6) S_eGK; objects: (1) Daten der Chipkarten (Versichertenstammdaten) with the security attribute: a. „geschützt“ b. „ungeschützt“ (2) Objektsystem der Chipkarte (eGK) .437 FDP_ACF.1.2/AK.VSDM The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: (1) Der S_VSDM_Fachmodul kommuniziert mit dem VSDD und dem CMS über den VSDM_Intermediär und fordert dafür die 436 [assignment: access control SFP] 437 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes] Security Target secunet konnektor 2.1.0 Seite 286 von 424 secunet Bereitstellung eines TLS-Kanals mit gegenseitiger Authentisierung gemäß FTP_ITC.1/AK.FD durch S_AK an. (2) Bei Zugriff des VSDD_Fachdienst oder des CMS auf die eGK ermöglicht S_VSDM_Fachmodul den Aufbau eines Secure Messaging Kanals zwischen VSDD_Fachdienst bzw. CMS und der eGK. (3) Zugriffe auf S_eGK durch S_VSDD_Fachdienst werden vom S_AK (Chipkartendienst) auf dem Objektsystem der eGK protokolliert. (4) [none]438 .439 FDP_ACF.1.3/AK.VSDM The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [none]440 . FDP_ACF.1.4/AK.VSDM The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [none]441 . Anwendungshinweis 190: Das Subjekt S_VSDD_Fachdienst vermittelt die Kommunikation des VSDD über den TLS-Kanal zwischen S_AK und VSDM-Intermediär. Das Subjekt S_CMS vermittelt die Kommunikation des CMS über den TLS-Kanal zwischen S_AK und VSDM- Intermediär. FMT_MSA.1/AK.VSDM Management of security attributes / VSDM Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions. FMT_MSA.1.1/AK.VSDM The TSF shall enforce the VSDM-SFP442 to restrict the ability to [change_default, query, modify]443 the security attributes 438 [assignment: additional rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects] 439 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects]. 440 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] 441 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] 442 [assignment: access control SFP(s), information flow control SFP(s)] 443 [selection: change_default, query, modify, delete, [assignment: other operations]] Security Target secunet konnektor 2.1.0 secunet Seite 287 von 424 [Konfigurationsparamter nach Tab_FM_VSDM_14 in [37]] to S_Administrator.444 FMT_MSA.3/AK.VSDM Static attribute initialisation / VSDM Hierarchical to: No other components. Dependencies: FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1/AK.VSDM The TSF shall enforce the VSDM-SFP445 to provide restrictive446 default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2/AK.VSDM The TSF shall allow the S_Administrator447 to specify alternative initial values to override the default values when an object or information is created. 444 [assignment: the authorised identified roles] 445 [assignment: access control SFP, information flow control SFP] 446 [selection, choose one of: restrictive, permissive, [assignment: other property]] 447 [assignment: the authorised identified roles] Security Target secunet konnektor 2.1.0 Seite 288 von 424 secunet 6.3.3.10. Übergreifende Sicherheitsanforderungen FMT_MSA.4/AK Security attribute value inheritance Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_MSA.4.1/AK The TSF shall use the following rules to set the value of security attributes: (1) Der Chipkartendienst erzeugt für jede neu gesteckte Chipkarte (a) für identifizierte KVK, (b) für identifizierte eGK, SMC und HBA ein Kartenhandle und übergibt das Kartenhandle und die damit verknüpften Informationen an das Subjekt S_AK. (2) Der Chipkartendienst öffnet auf Anforderung des Subjekts S_AK für eine mit dem Kartenhandle identifizierten Chipkarte einen logischen Kanal. (3) Die TSF weisen (a) vom EVG importierten zu signierenden Daten, (b) vom EVG importierten zu verschlüsselnden Daten, (c) vom EVG zu entschlüsselnden Daten, (d) dem vom EVG identifizierten Subjekt „S_Benutzer_Clientsystem“ die vom EVG übergebene Identität und den Autorisierungsstatus „nicht autorisiert“ zu. (4) Die TSF weisen nach erfolgreicher Prüfung der Signatur-PIN der Signaturchipkarte des identifizierten Benutzers des Clientsystems dem Autorisierungsstatus des Subjektes S_Benutzer_Clientsystem den Wert „autorisiert“ zu. (5) Die TSF weisen den zu signierenden Daten einer Liste nach erfolgreicher Prüfung der Signatur-PIN der Signaturchipkarte des S_Benutzer_Clientsystem den Autorisierungsstatus „autorisiert“ zu. (6) Der AK setzt den Wert des Sicherheitsattributes „Ordnungsgemäßigkeit der Signatur“ aller signierten Daten eines autorisierten Signaturstapels, der von der QSEE gesendet wird, auf „ordnungsgemäß“, falls folgendes gilt: (a) Das S_Benutzer_Clientsystem hat während der Signaturerstellung keinen Abbruch der Signatur gefordert. (b) Die TSF empfangen für jedes Kommando zur Signaturerzeugung einen erfolgreichen Rückkehrcode der QSEE. Security Target secunet konnektor 2.1.0 secunet Seite 289 von 424 (c) Die Anzahl der signierten Dokumente entspricht der Anzahl der zum Signieren übersandten Dokumente des autorisierten Stapels. (d) Die qualifizierten elektronischen Signaturen für alle Elemente des autorisierten Signaturstapels werden vom EVG erfolgreich mit dem zum festgelegten Zeitpunkt gültigen qualifizierten Zertifikat des Benutzers des Clientsystems verifiziert. (e) Die qualifizierten elektronischen Signaturen beziehen sich auf den vorher identifizierten Benutzer des Clientsystems und die Daten des autorisierten Signaturstapels. (f) Die Freischaltung der QSEE für die Erstellung von qualifizierten elektronischen Signaturen wurde von dem EVG erfolgreich zurückgesetzt falls nicht die Komfortsignatur- Funktion verwendet wird.448 Sollte einer dieser Punkte nicht erfüllt sein, erhalten alle signierten Dokumente, die durch die aktuelle Signatur-PIN-Eingabe autorisiert wurden, das Attribut „ungültig“. (7) Der EVG weist den Wert des Sicherheitsattributes „Ordnungsgemäss verschlüsselt“ verschlüsselter Daten nur dann auf „ordnungsgemäß“, wenn (d) die identifizierte Verschlüsselungsrichtlinie für die zu verschlüsselnden Daten gültig ist, (e) zu den vorgesehenen Empfängern gültige Verschlüs- selungszertifikate existieren und für die Verschlüsselung des symmetrischen Schlüssels verwendet wurden, (f) die durch den Xpath-Ausdruck selektierten zu verschlüsselnden Daten vollständig verschlüsselt wurden und (g) keine Fehler auftraten. .449 Anwendungshinweis 191: Die Zuweisung in der Regel (5) erfolgt in Übereinstimmung mit den Zugriffsregeln der qualifizierten Signaturerstellungseinheit. Für die Stapelsignatur nach TR-03114 [21] ist es notwendig, dass - die QSEE nach einmaliger erfolgreicher Authentisierung des Signaturschlüssel- Inhabers die Erzeugung einer begrenzten Anzahl n ( 1 n ) Signaturen erlaubt (mehrfachsignaturfähige QSEE), - der EVG die berechtigt signierende Person durch die QSEE authentisiert und für das Signieren eines Stapels von m (1 m n   ) durch die QSEE autorisiert, 448 Refinement: falls nicht die Komfortsignatur-Funktion verwendet wird 449 [assignment: rules for setting the values of security attributes] Security Target secunet konnektor 2.1.0 Seite 290 von 424 secunet - der EVG nur die von der berechtigt signierenden Person übergebenen Dateien (Stapel) zeitlich zusammenhängend der QSEE zuführt und - der EVG die Autorisierung des Signaturschlüssel-Inhabers nach dem Signieren dieses Stapels zurücksetzt. Wenn die Anzahl der zu signierenden Daten größer ist als die zulässige Anzahl der nach einer Authentisierung mit der PIN.QES durch den HBA erstellbaren Signaturen, d.h. m n  , so soll der EVG den Benutzer Clientsystem zu erneuten Signatur-PIN-Eingabe für die nächsten maximal n zu signierenden Dateien auffordern bis der Stapel abgearbeitet ist. Die Signaturerstellung für die zu signierenden Daten eines autorisierten Stapels ist damit ein zeitlich zusammenhängender Prozess. Die Regel (6) des Elements FMT_MSA.4/AK.1 setzt die Forderung der TR-03114 [21], Schritt 4, dadurch um, dass in den aufgeführten Fällen alle bisher erstellen Signaturen des autorisierten Stapels verworfen und der Signaturprozess abgebrochen werden muss. Wenn der Benutzer einen Abbruch des Signaturvorganges anfordert, so werden die vorher für den autorisierten (Teil-) Signaturstapel erstellten Signaturen verworfen und gelöscht und die Erzeugung der noch ausstehenden Signaturen wird abgebrochen. Wenn bei einer erneuten Signatur-PIN-Eingabe des Stapels ein Fehler auftritt (z. B. die zulässige Zeit für die PIN-Eingabe überschritten wird oder die PIN-Eingabe falsch ist), so soll dies wie ein vom Benutzer geforderter Abbruch behandelt werden. In PP-0098 wird das SFR FMT_MSA.4/AK für die in dem PP beschriebenen Signaturarten „Einzelsignatur“ und „Stapelsignatur“ modelliert. Der EVG unterstützt zusätzlich die „Komfortsignatur“. Der Anwendungshinweis 191 des PP erlaubt ausdrücklich, dass für weitere Signaturarten teilweise von der Definition der SFR abgewichen werden kann. Insbesondere wird dabei FMT_MSA.4./AK Regel (6)(f) genannt. Die Komforsignatur setzt diese Regel wie folgt um: Bei aktivierter Komfortsignatur wird die Zurücksetztung der Freischaltung des QSEE nicht durchgeführt. Die Komfortsignatur ist per Default auf „Disabled“ (SAK_COMFORT_SIGNATURE=Disabled) gesetzt. Bevor die Komfortsignaturfunktion eingeschaltet werden kann müssen die Werte ANCL_TLS_MANDATORY und ANCL_CAUT_MANDATORY beide auf „Enabled“ stehen (TIP1-A4680-03). Bei der Komfortsignatur wird zwingend eine SecureMessaging (gSMC-K <-> HBA) benutzt (siehe FIA_UAU.5.2/AK (8) und und FIA_API.1/AK) (A_19258). Die Komfortsignaturfunktion kann durch den Befehl DeactiveComfortSignature oder durch das setzen von SAK_COMFORT_SIGNATURE auf „Disable“ global deaktiviert werden. Dadurch wird auch der Status aller HBAs bzw. HBA-Kartensitzungen zurückgesetzt (A_19105). Es werden vom EVG keine weiteren Signaturarten umgesetzt. FDP_RIP.1/AK Subset residual information protection Hierarchical to: No other components. Dependencies: No dependencies. FDP_RIP.1.1/AK The TSF shall ensure that any previous information content of a resource is made unavailable upon the deallocation of the resource from450 the following objects: 450 [selection: allocation of the resource to, deallocation of the resource from] Security Target secunet konnektor 2.1.0 secunet Seite 291 von 424 (1) geheime kryptographische Schlüssel, (2) zu signierende Daten, (3) signierte Daten (nach der Ausgabe), (4) zu verschlüsselnde Daten (nach der Verschlüsselung), (5) verschlüsselte Daten (nach der Ausgabe), (6) vorgeschlagene Empfänger, (7) entschlüsselte Daten (nach der Ausgabe), (8) Benutzerdaten, die über den TLS-Kanal zwischen EVG und eHealth-Kartenterminals übermittelt wurden .451 Daten einer eGK dürfen nicht über den Steckzyklus der Karte hinaus im EVG gespeichert werden. Daten von HBA und SM-B dürfen nicht länger als 24 Stunden im EVG zwischengespeichert werden. Die sensitiven Daten müssen mit konstanten oder zufälligen Werten überschrieben werden, sobald sie nicht mehr verwendet werden. In jedem Fall müssen die sensitiven Daten vor dem Herunterfahren bzw. wenn möglich vor Reset, überschrieben werden. Anwendungshinweis 192: Beim Ziehen einer Chipkarte sowie beim Entfernen eines Kartenterminals werden eventuell vorhandene Puffer-Inhalte (Cache) sicher gelöscht. 6.3.4. Klasse FMT: Sicherheitsmanagement FMT_SMR.1/AK Security roles Hierarchical to: No other components. Dependencies: FIA_UID.1 Timing of identification FMT_SMR.1.1/AK The TSF shall maintain the roles (1) Administrator, (2) Benutzer des Clientsystems, (3) HBA, (4) gSMC-KT, PIN-Sender, (5) SMC-B, (6) eGK, (7) Kartenterminal, (8) CMS of the gSMC-K , (9) Clientsystem, (10) Fachmodul, (11) Fachdienst 451 [assignment: list of objects] Security Target secunet konnektor 2.1.0 Seite 292 von 424 secunet 452 . FMT_SMR.1.2/AK The TSF shall be able to associate users with roles. FMT_SMF.1/AK Specification of Management Functions Hierarchical to: No other components. Dependencies: No dependencies.. FMT_SMF.1.1/AK The TSF shall be capable of performing the following management functions: (1) Manage eHealth-Kartenterminals according to FMT_MTD.1/AK.eHKT_Abf and FMT_MTD.1/AK.eHKT_Mod, (2) Manage Arbeitsplatzkonfiguration with assigned Clientsystems and eHealth-Kartenterminals according to FMT_MTD.1/AK.Admin, (3) Manage Signaturrichtlinien according to FMT_MSA.3/AK.Sig, (4) Manage TLS-Kanäle according to FMT_MSA.3/AK.TLS, (5) Manage Cross-CVC according to FMT_MTD.1/AK.Zert, (6) Management of TSF functions according to FMT_MOF.1/AK (7) Manage configuration parameters of Fachmodule .453 FMT_MOF.1/AK Management of security functions behaviour Hierarchical to: No other components. Dependencies: FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions FMT_MOF.1.1/AK The TSF shall restrict the ability to disable and enable454 the functions Online Kommunikation, Signaturdienst und Logische Trennung455 to Administrator456 . The following rules apply: 452 [assignment: the authorised identified roles] 453 [assignment: list of management functions to be provided by the] 454 [selection: determine the behaviour of, disable, enable, modify the behaviour of] 455 [assignment:list of functions] 456 [assignment: the authorised identified roles] Security Target secunet konnektor 2.1.0 secunet Seite 293 von 424 1. If the attribute MGM_LU_ONLINE is set to “Disabled”, the Konnektor never establishes an online connection. This means, the following services are deactivated in this case: (1) Zertifikatsdienst: The TSL will be activated without evaluation of the revocation status (see FPT_TDC.1/AK). (2) TLS connection for Fachdienste: no TLS communication according to FTP_ITC.1/AK.FD. (3) Zeitdienst: time synchronization according to FPT_STM.1/NK. (4) Software-Aktualisierungsdienst: no communication with the update server according to FDP_ACF.1.4/Update. 2. If the attribute MGM_LU_SAK is set to “Disabled”, the Signaturdienst for QES according to the chapters 6.3.1.3 and 6.3.3.4 is deactivated. 3. If the logical separation is activated (attribute MGM_LOGICAL_SEPARATION set to “Enabled”), the following rules apply: (1) If invoked from an external interface, the Verschlüsselungsdienst of the Konnektor must not check the revocation status of certificates. (2) If invoked from an external interface, the Signaturdienst of the Konnektor must not check the revocation status of certificates. (3) IF MGM_LU_ONLINE is not enabled, the NTP server of the Konnektor must be deactivated. (4) If MGM_LU_ONLINE is set to “Enabled”, the Konnektor may only resolve the namespace „TI (*.DNS_TOP_LEVEL_DOMAIN_TI) “ for internal services and internal Fachanwendungen and must not resolve this namespace for requests originatred from the LAN. (5) The Konnektor must block all communication on its external interfaces with the following systems: a. with systems in the network segment ANLW_AKTIVE_BESTANDSNETZE initiated by „Aktive Komponenten“, b. with the Internet via SIS and IAG. Anwendungshinweis 193: Wenn MGM_LU_ONLINE=Disabled gesetzt ist, so baut der Konnektor grundsätzlich keine Online-Verbindungen zum WAN auf und beendet bestehende Kommunikation einschließlich VNP-Client, vergl. FMT_MSA.1/NK. Wenn MGM_LU_ONLINE=Enabled, aber MGM_LOGICAL_SEPARATION=Enabled, dann verhalten sich definierte Teile des Konnektors analog zu einer Auftrennung der Online- Verbindungen. Security Target secunet konnektor 2.1.0 Seite 294 von 424 secunet Anmerkung 9. Der EVG setzt die Funktionalität der logischen Separierung nicht um. Der EVG verhält sich dauerhaft wie ein Konnektor im Zustand MGM_LOGICAL_SEPARATION=disabled. FMT_MTD.1/AK.Admin Management of TSF data / Adminstration Hierarchical to: No other components. Dependencies: FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions FMT_MTD.1.1/AK.Admin The TSF shall restrict the ability to (1) set, query, modify and delete457 the roles from other users458 , (2) set, modify and delete459 the authentication credentials for administrators460, (3) set and modify461 the Arbeitsplatzkonfiguration with assigned Clientsystem and eHealth-Kartenterminals462, (4) set and modify463 the Zeitpunkten und Gültigkeitsdauer der Prüfungsergebnisse zur Gültigkeit qualifizierter Zertifikate für die Erzeugung ordnungsgemäßer qualifizierten elektronischen Signaturen464, (5) change_default465 of the gültigen Signaturrichtlinie für Signaturerzeugung466, (6) change_default467 of the gültigen Signaturrichtlinie für Signaturprüfung468, (7) modify469 the configuration parameter to activate or deactivate the automatic installation of software updates470, 457 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 458 [assignment: list of TSF data] 459 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 460 [assignment: list of TSF data] 461 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 462 [assignment: list of TSF data] 463 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 464 [assignment: list of TSF data] 465 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 466 [assignment: list of TSF data] 467 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 468 [assignment: list of TSF data] 469 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 470 [assignment: list of TSF data] Security Target secunet konnektor 2.1.0 secunet Seite 295 von 424 (8) import471 the update data for Karten-Terminals and execute the update472, (9) configure473 the loggable system events474, (10) export and import475 the configuration data of the TOE476, (11) set and modify477 the maximum lifetime of OCSP cache entries478 (12) set and modify479 the keys of the sicheren Datenspeichers480, (13) set and import481 the X.509 certificates of Clientsystemen482, (14) reset to factory settings483 of the all TSF data (factory reset)484, (15) import485 the CA certificates of an encryption PKI486, (16) generate, set, import, export and modify the used Konnektor certificate for client system TLS communication487 to administrator488 . Für den Fall, dass die Remote-Managementschnittstelle verwendet wird, sind die Einschränkungen der Rechte aus TAB_KON_655 und TAB_KON_851 in [27] zu berücksichtigen. Insbesondere können die Funktionen (1), 471 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 472 [assignment: list of TSF data] 473 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 474 [assignment: list of TSF data] 475 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 476 [assignment: list of TSF data] 477 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 478 [assignment: list of TSF data] 479 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 480 [assignment: list of TSF data] 481 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 482 [assignment: list of TSF data] 483 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 484 [assignment: list of TSF data] 485 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 486 [assignment: list of TSF data] 487 Refinement: (16) … 488 [assignment: the authorised identified roles] Security Target secunet konnektor 2.1.0 Seite 296 von 424 secunet (2), (9), (10), (11), (12), (13), (14) und (15) nicht aufgerufen werden. Anwendungshinweis 194: Der EVG authentisiert nur menschliche Benutzer in der Administrator- Rolle. Die TSF unterstützen das Erzeugen und den Export selbsterstellter X.509- Zertifikaten für Clientsysteme (s. FCS_CKM.1/NK.Zert) und den Import nicht durch die TSF erzeugter X.509-Zertifiakte für die Clientsysteme zur Kommunikation über einen TLS-Kanal (s. FTP_ITC.1/CS). Nach [110] sollen aber nur vom EVG erzeugte X.509- Zertifikaten für Clientsysteme verwendet werden. Im Rahmen der interne Generierung oder Import eines Zertifikates/Schlüsselpaares für den EVG gibt es die Möglichkeit für den Adminstrator zwischen diesen Zertifikaten (C.AK.AUT, ID.AK.AUT, und auch dem ursprünglichen auf der gSMC.K) zu wechseln. Bei der Erstellung eines Schlüsselpaars und des X.509 Zertifikates hat der Administrator die Möglichkeit die kryptographischen Verfahren RSA-2048 oder ECC-256 auszuwählen (A_21699). Bei EVG Zertifikaten hat der Administrator auch die Möglichkeit den Hostnamen des Konnektors im Zertifikat zu vergeben. Ein in erneuertes C.AK.AUT wird nicht automatisch vom EVG verwendet (A_21759). Anwendungshinweis 195: Regel (7) von FMT_MTD.1.1/AK.Admin wird duch die Auto-Update Funktion unterstützt. FMT_MTD.1/AK.Zert Management of TSF data / Zertifikatsmanagement Hierarchical to: No other components. Dependencies: FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions FMT_MTD.1.1/AK.Zert The TSF shall restrict the ability to (1) delete489 the public keys of the CVC root CA490 to the CMS of the gSMC-K491 , (2) import and permanently store492 the public keys of the CVC root CA by the use of cross CVC493 to S_AK494. 6.3.5. Klasse FPT: Schutz der TSF FPT_TDC.1/AK Inter-TSF basic TSF data consistency Hierarchical to: No other components. Dependencies: No dependencies. 489 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 490 [assignment: list of TSF data] 491 [assignment: the authorised identified roles] 492 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 493 [assignment: list of TSF data] 494 [assignment: the authorised identified roles] Security Target secunet konnektor 2.1.0 secunet Seite 297 von 424 FPT_TDC.1.1/AK The TSF shall provide the capability to consistently interpret (1) Zertifikate für die Prüfung qualifizierter elektronischer Signaturen, (2) nicht-qualifizierter X.509-Signaturzertifikate, (3) X.509-Verschlüsselungszertifikate, (4) CV-Zertifikate, (5) Trust-service Status Listen und TSL Hash-Werte, (6) Certificate Revocation Listen, (7) BNetzA-VL und BNetzA-VL Hashwerten, (8) Zulässigkeit importierter zu signierenden bzw. zu prüfender signierten Daten gemäß implementierten Signaturrichtlinien, (9) [NFDM Signaturrichtlinie] 495 when shared between the TSF and another trusted IT product. FPT_TDC.1.2/AK The TSF shall use the following rules (1) Zertifikate für die qualifizierte elektronische Signatur müssen erfolgreich gemäß Kettenmodell bis zur bekannten und verifizierten BNetzA-VL erfolgreich geprüft sein. (2) Die digitale Signatur der BNetzA-VL muss erfolgreich mit dem in der TSL enthaltenen öffentlichen Schlüssel zur Prüfung der BNetzA-VL geprüft sein und ist nur im angegebenen Gültigkeitszeitraum anwendbar. Die zeitliche Gültigkeit der BNetzA-VL muss erfolgreich geprüft werden. (3) Die Gültigkeit der X.509-Signaturzertifikate der SMC-B gemäß [36] muss gemäß Schalenmodell bis zu einem gültige CA-Zertifikat der ausstellenden (zugelassenen) CA, das in einer gültigen TSL enthalten ist, erfolgreich geprüft sein. (4) Die Gültigkeit der X.509-Verschlüsselungszertifikate gemäß Schalenmodell bis zu einem gültige CA-Zertifikat der ausstellenden (zugelassenen) CA, das in einer gültigen TSL enthalten ist, erfolgreich geprüft sein. (5) Die Gültigkeit der CVC gemäß [15] muss nach dem Schalenmodell bis zu einer bekannten Wurzelinstanz erfolgreich geprüft sein. (6) Die digitale Signatur über der TSL muss erfolgreich mit dem öffentlichen Schlüssel zur Prüfung von TSL erfolgreich geprüft sein und ist nur im angegebenen Gültigkeitszeitraum anwendbar. Sollte die TSL über das Internet geladen werden muss der Konnektor zunächst die detachted-Signatur der TSL prüfen, einschließlich vollständiger Prüfung der Zertifikatskette bis zum TI-Vertrauensanker. 496 495 [assignment: list of TSF data types] 496 Refinement: Sollte die TSL … Security Target secunet konnektor 2.1.0 Seite 298 von 424 secunet (7) Die digitale Signatur über der Certificate Revocation List muss mit dem öffentlichen Schlüssel zur Prüfung von CRL erfolgreich geprüft sein. (8) Ein neuer öffentlicher Schlüssel zur Prüfung von TSL, CRL und BNetzA-VL darf nur durch eine gültige TSL verteilt werden. (9) [für NFDM Signaturrichtlinie die Kette der Signaturen bis zu einem bekannten Vertrauensanker und die Vereinbarkeit mit den Regeln für qualifizierte elektronische Signaturen prüfen]. 497 when interpreting the TSF data from another trusted IT product. Anwendungshinweis 196: Die Vertrauenswürdigkeit des IT-Produktes, von dem TSF-Daten importiert werden, ergibt sich aus einer gültigen digitalen Signatur, die mit den im EVG vorhandenen öffentlichen Schlüsseln der bekannten Vertrauensanker ggf. in einer Zertifikatskette erfolgreich geprüft werden konnte. Die „Vereinbarkeit mit den Regeln für qualifizierte elektronische Signaturen prüfen“ ist gegeben, wenn (i) die Signaturrichtlinie keine qualifizierte elektronische Signatur fordert, oder (ii) die Signaturrichtlinie eine qualifizierte elektronische Signatur und die in diesem ST für qualifizierte elektronische Signaturen definierten Regeln gemäß FDP_ACF.1/AK.Sgen, FDP_ACF.1/AK.SigPr, FDP_DAU.2/AK.QES und FDP_DAU.2/AK.Cert einhält. Die in der letzten Regeln von FPT_TDC.1.2 genannten Signatursrichtlinien (zu unterstützende Dokumenten- / Signatur-formate und XML-Daten- Interpretationsvorschriften) werden im Zuge von Updates des EVG (z. B. beim Einbringen neuer Fachmodule) importiert. Die Signaturprüfung erfolgt dann implizit durch die Signaturprüfung des Update-Pakets entsprechend FDP_ACF.1/AK.Update. Anwendungshinweis 197: Die BNetzA-VL wird gemäß Anforderung A_6730 der Konnektor- Spezifikation [27] im Online-Modus mindestens einmal täglich auf Aktualität überprüft. Der EVG interpretiert den Hash-Wert der BNetzA-VL gemäß Use Case TUC_KON_031 der Konnektor-Spezifikation [27]. Anmerkung 10. Der Konnektor ermöglicht den Import des TSL-Signer-CA Cross- Zertifikats auch, wenn er sich im kritischen Betriebszustand EC_TSL_Out_Of_Date_Beyond_Grace_Period befindet (A_17549-01). Um auf Basis des bereits etablierten Vertrauensankers (RSA) in den Vertrauensraum (ECC-RSA) zu wechseln verwendet der Konnektor bei der Initialisierung des neuen Vertrauensankers (ECC-RSA) Cross-Zertifikate. Das Ergebnis ist ein neuer etablierter TI-Vertrauensanker (ECC-RSA) (A_17837-01), der im sicheren Speicher abgelegt wird (A_17548-01). Es wird vom Konnektor ein Vergleich des PublicKey im Cross-Zertifikat mit dem PublicKey im CA-Zertifikat des neuen Vertrauensankers (TSL-Signer-CA) durchgeführt. Dabei wird eine Signatur-Prüfung des Cross-Zertifikates gegen den alten 497 [assignment: list of interpretation rules to be applied by the TSF] Security Target secunet konnektor 2.1.0 secunet Seite 299 von 424 Vertrauensanker im System (TSL-Signer-CA) durchgeführt analog zu TUC_PKI_004. Die neue TSL (passend zum Vertrauensanker TSL-Signer-CA) wird analog zu GS-A_4748 eingebracht und danach das Element TSLSequenceNumber ausgelesen. Falls für den TSLSequenceNumber-Nummernkreis der neu eingebrachten TSL eine TSLSequenceNumber im sicheren Speicher vorliegt, dann muss die TSLSequenceNumber der neu eingebachten TSL höher sein, als dieser Wert. Wenn einer der Schritte fehlschlägt, wird der Vertrauensraum-Wechsel-Prozess abgebrochen und der alte Vertrauensanker (TSL-Signer-CA) verbleibt im Konnektor. (A_17821) Der Konnektor sichert für den Download der Hash-Datei der TSL(ECC-RSA) die Verbindung zum TSL-Dienst durch TLS ab. Der Konnektor prüft das vom TSL-Dienst beim TLS-Verbindungsaufbau präsentierte Zertifikat C.ZD.TLS-S. Die Prüfung erfolgt durch Aufruf von TUC_KON_037 „Zertifikat prüfen“ { certificate = C.ZD.TLS-S; qualifiedCheck = not_required; offlineAllowNoCheck = true; policyList = oid_zd_tls_s; intendedKeyUsage = intendedKeyUsage(C.ZD.TLS-S); intendedExtendedKeyUsage = id-kp-serverAuth; validationMode = OCSP } . Falls Fehler im TLS-Verbindungsaufbau bzw. bei der Zertifikatsprüfung auftreten MUSS der Konnektor den TLS-Verbindungsaufbau mit Fehlercode 4235 gemäß TAB_KON_825 abbrechen (A_17661). Der Konnektor muss für die Prüfung der Signatur der TSL(ECC-RSA) das Signaturverfahren ECDSA auf Basis der Domainparameter brainpoolP256r1 verwenden mit dem XMLDSig-Identifier „ http://www.w3.org/2001/04/xmldsig- more#ecdsa-sha256“ mit entsprechenden TSL-Signer-CA-Zertifikat (ECDSA) (A_17688). Als Hashfunktion (Messagedigest) wird SHA-256 verwendet (A_17205). Die TSL kann auch direkt aus dem Internet geladen werden, wenn sie in der TI nicht verfügbar ist (TIP1-A_4736-02). Hierbei wird zusätzlich die detachted Signature der TSL übertragen. Im Internet sind die TSL-Downloadpunkt des TSL Diensteservers erreichbar, siehe auch FDP_IFC.1/NK.PF (TIP1-A_4693-02). FPT_FLS.1/AK Failure with preservation of secure state Hierarchical to: No other components. Dependencies: No dependencies. FPT_FLS.1.1/AK The TSF shall preserve a secure state according to TAB_KON_504 [27] when the following types of failures occur: (1) according to TAB_KON_503 [27] with type „SEC“ and severity „fatal“. (2) [Error Condition EC_FW_Not_ Valid_Status_ Blocked according to [27]] 498 499 . 498 [assignment: list of additional types of failures in the TSF] 499 [assignment: list of types of failures in the TSF] Security Target secunet konnektor 2.1.0 Seite 300 von 424 secunet Failures occured during the self test of the TOE (see FPT_TST.1/AK.Run-Time and FPT_TST.1/AK.Out-Of-Band) must trigger a blockage of the affected parts of the TSF. Anwendungshinweis 198: Für dedizierte Fehlerarten unterbindet der EVG bestimmte weitere Funktionalität. Diese Fehlerarten und die erlaubten bzw. verbotenen Dienste sind in Tabelle TAB_KON_504 in [27] definiert. Insbesondere wird für Error Condition EC_FW_Not_ Valid_Status_ Blocked TIP1-A_6025 nach [27] umgesetzt. Im Fehlerfall EC_Firewall_Not_Reliable deaktiviert der EVG die LAN- und WAN-Schnittstelle und lässt insbesondere keine administrativen Funktionen an diesen Schnittstellen zu. Anwendungshinweis 199: Sonstige Fehlerzustände des EVG, die an dessen äußeren Schnittstellen auftreten, obliegen den funktionalen Tests zur Zulassung. FPT_TEE.1/AK Testing of external entities Hierarchical to: No other components. Dependencies: No dependencies. FPT_TEE.1.1/AK The TSF shall run a suite of tests (1) beim Herstellen einer Kommunikation mit einem Gerät, das vorgibt, ein eHealth-Kartenterminal zu sein500 to check the fulfillment of das Gerät ist dem EVG als zulässiges eHealth- Kartenterminal im LAN des Leistungsrbringers bekannt, d. h. ein eHealth-Kartenterminal mit dem Pairing-Geheimnis und der beim Pairing gesteckten gültigen gSMC-KT.501 (2) bei der Meldung eines eHealth-Kartenterminals über das Stecken einer Chipkarte502 to check the fulfillment of: (a) die gesteckte Chipkarte ist eine KVK. (b) Die Chipkarte ist eine Chipkarte des identifizierten Kartentyps eGK, HBA, gSMC-KT oder SMC-B und keine KVK. 503 (3) bei entfernter Eingabe von PIN- oder PUK504 to check the fulfillment of: (a) Zulässigkeit mit dem CVC mit Flag ’54’ für die Nutzung einer gSMC-KT als PIN-Sender für die entfernte PIN- Eingabe. (b) Zulässigkeit für einen HBA oder einer SMC-B mit dem 500 [selection: selection: during initial start-up, periodically during normal operation, at the request of an authorised user, [assignment: other conditions]] 501 [assignment: List of properties of the external entities] 502 [selection: selection: during initial start-up, periodically during normal operation, at the request of an authorised user, [assignment: other conditions]] 503 [assignment: List of properties of the external entities] 504 [selection: selection: during initial start-up, periodically during normal operation, at the request of an authorised user, [assignment: other conditions]] Security Target secunet konnektor 2.1.0 secunet Seite 301 von 424 CVC Flag ’55’ für die Nutzung einer Chipkarte als PIN- Empfänger für die entfernte PIN-Eingabe. . 505 FPT_TEE.1.2/AK If the test fails, the TSF shall (1) keine weitere Kommunikation mit dem Gerät aufzunehmen und eine Fehlermeldung an den EVG zu geben. (2) wenn für eine Chipkarte die Testfolge des identifizierten Kartentyps, der keine KVK ist, fehlschlägt, ist der angeforderte Prozess abzubrechen und eine Fehlermeldung an den EVG zu geben. (3) wenn die gesteckte Chipkarte nicht als KVK, eGK, HBA, gSMC-KT oder SMC-B identifiziert werden kann, soll die TSF [den angeforderten Prozess auf der Chipkarte abbrechen und eine Fehlermeldung zurück geben] 506 . 507 Anwendungshinweis 200: Wenn keine weiteren Chipkarten unterstützt werden, ist eine Fehlermeldung an den EVG über einen unbekannten Kartentyp zu übergeben. Die Testfolge für ein eHealth-Kartenterminal besteht in dem Aufbau eines TLS-Kanals mit Prüfung des Zertifkats einer gültigen gSMC und des Pairing-Geheimnis (s. [38]). Die Testfolge für eine KVK besteht im Lesen und Auswerten des ATR der Chipkarte. Die Testfolge für Chipkarten des Kartentyps eGK, HBA, gSMC-KT und SMC-B umfasst die sichere Bestimmung der Karte und des Kartentyps. FPT_TST.1/AK.Run- Time TSF testing / Normalbetrieb Hierarchical to: No other components. Dependencies: No dependencies. FPT_TST.1.1/AK.Run- Time The TSF shall run a suite of self tests beim Anlauf und regelmäßig während des Normalbetriebs508 to demonstrate the correct operation of [TLS, AES]509 . FPT_TST.1.2/AK.Run- Time The TSF shall provide authorised users with the capability to verify the integrity of [the following parts of TSF data: 505 [assignment: list of properties of the external entities] 506 [assignment: action(s)] 507 [assignment: action for unknown smart card] 508 [selection: during initial start-up, periodically during normal operation, at the request of the authorised user, at the conditions [assignment: conditions under which self test should occur]] 509 [selection: [assignment: parts of TSF], TSF] Security Target secunet konnektor 2.1.0 Seite 302 von 424 secunet  CRL]510 . FPT_TST.1.3/AK.Run- Time The TSF shall provide authorised users with the capability to verify the integrity of [TLS, AES]511 . Anwendungshinweis 201: Die Komponente FPT_TST.1.1/Run-Time fordert den Selbsttest des EVG unter normalen Betriebsbedingungen, d. h. beim Anlauf (z. B. Einschalten des Konnektors) und während des Normalbetriebs. Die Selbsttests zu AES beinhalten Tests zum korrekten Aufruf der AES Routinen des Kernels. Wenn AES-NI aktiviert ist, wird entsprechend der HW-Aufruf des AES-Algorithmus von den Selbsttests geprüft. Für die TLS Selbstests wird ein TLS Server und ein TLS Client initialisiert und daraufhin mit verschiedenen Cipher Suites ein TLS Handshake ohne Authentisierung des TLS Clients untereinander durchgeführt. Die Integrität der CRL wird beim Anlauf und während des Normalbetriebs vor jeder Verwendung geprüft. FPT_TST.1/AK.Out- Of-Band TSF testing / Out-Of-Band Hierarchical to: No other components. Dependencies: No dependencies. FPT_TST.1.1/AK.Out- Of-Band The TSF shall run a suite of self tests durch TSF-Komponenten mit integritätsgeschützt gespeichertem Code beim Erstanlauf und auf Anforderung eines autorisierten Benutzers512 to demonstrate the correct operation of the TSF513 . FPT_TST.1.2/AK.Out- Of-Band The TSF shall provide authorised users with the capability to verify the integrity of TSF data514 . FPT_TST.1.3/AK.Out- Of-Band The TSF shall provide authorised users with the capability to verify the integrity des gespeicherten ausführbaren Codes of [none]515 . Anwendungshinweis 202: Dieses SFR wird durch den Sicheren Start-Up umgesetzt, siehe 7.1.5 NK.Selbstschutz. Der Vertrauensanker ist Intergritätsgeschützt im BIOS abgelegt. Durch Neustart kann der Benutzer den Selbstest jederzeit anstossen. FPT_STM.1/AK Reliable time stamps Hierarchical to: No other components. Dependencies: No dependencies. 510 [selection: [assignment: parts of TSF data], TSF data] 511 [selection: [assignment: parts of TSF], TSF] 512 [selection: during initial start-up, periodically during normal operation, at the request of the authorised user, at the conditions [assignment: conditions under which self test should occur]] 513 [selection: [assignment: parts of TSF], TSF] 514 [selection: [assignment: parts of TSF data], TSF data] 515 [assignment: parts of TSF mit gespeichertem ausführbarem TSF-Code] Security Target secunet konnektor 2.1.0 secunet Seite 303 von 424 FPT_STM.1.1/AK The TSF shall be able to provide reliable time stamps für vom AK erzeugte Protokolleinträge (gemäß FAU_GEN.1/AK). Der AK greift auf die Echtzeituhr zurück, die in regelmäßigen Abständen und auf Anforderung des Administrators vom NK mit einem vertrauenswürdigen Zeitdienst synchronisiert wird. EVG Ausstrahlung Maßnahmen zur Verhinderung von kompromittierenden Informationen in Signalen über die äußeren Schnittstellen des EVG sind einerseits in FPT_EMS.1/NK gefordert. Darüber hinaus werden sie als Bestandteil der Sicherheitsarchitektur des EVG (vgl. die Vertrauenswürdigkeitskomponente ADV_ARC.1) angesehen. Die Sicherheitsarchitekturbeschreibung beschreibt bzw. demonstriert, durch welche Maßnahmen der Selbstschutz, die Domain-Separierung und die Nichtumgehbarkeit der Sicherheitsfunktionalität realisiert ist [6]. 6.3.6. Klasse FAU: Sicherheitsprotokollierung FAU_GEN.1/AK Audit data generation Hierarchical to: No other components. Dependencies: FPT_STM.1 Reliable time stamps FAU_GEN.1.1/AK The TSF shall be able to generate an audit record of the following auditable events des Anwendungskonnektors: a) Start-up and shutdown of the audit functions des Anwendungskonnektors; b) All auditable events for the [not specified]516 level of audit; and c) The following specified security-relevant auditable events:  Power on / Shut down (einschließlich der Art der ausgelösten Aktion, z. B. Reboot) des Anwendungskonnektors,  Durchführung von Softwareupdates einschließlich nicht erfolgreicher Versuche des Anwendungskonnektors,  Zeitpunkt von Änderungen der Konfigurationseinstellungen und Export/Import von Konfigurationsdaten des Anwendungskonnektors,  kritische Betriebszustände wie in der Tabelle in FPT_FLS.1/AK aufgelistet des Anwendungskonnektors,  Ereignisse vom Typ „Sec“ des Anwendungskonnektors,  [none]517 518 . 516 [selection, choose one of: minimum, basic, detailed, not specified] 517 [assignment: additional events] 518 [assignment: other specifically defined auditable events] Security Target secunet konnektor 2.1.0 Seite 304 von 424 secunet FAU_GEN.1.2/AK The TSF shall record within each audit record at least the following information: a) Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and b) For each specified audit event type, based on the auditable event definitions of the functional components included in the PP/ST, [no other audit relevant information]519 . Anwendungshinweis 203: FAU_GEN.1/AK beschreibt die Protokollfunktionen des Anwendungs- konnektors in Ergänzung zu FAU_GEN.1/NK.SecLog. Die Protokoll-Daten dürfen keine personenbezogenen oder medizinischen Daten enthalten. Die Spezifikation Konnektor [27] gibt im Anhang F eine Übersicht der Ereignisse (Events) und im Anhang G eine Übersicht der Fehlercodes, wobei nur die Beschreibungen der Ereignisse und Fehlercodes für die jeweiligen Technischen Anwendungsfälle (TUC) verbindlich sind. FAU_SAR.1/AK Audit review Hierarchical to: No other components. Dependencies: FAU_GEN.1 Audit data generation FAU_SAR.1.1/AK The TSF shall provide [the administrator]520 with the capability to read [audit data according to FAU_GEN.1.1/NK and FAU_GEN.1.1/AK]521 from the audit records. FAU_SAR.1.2/AK The TSF shall provide the audit records in a manner suitable for the user to interpret the information. FAU_STG.1/AK Protected audit trail storage Hierarchical to: No other components. Dependencies: FAU_GEN.1 Audit data generation FAU_STG.1.1/AK The TSF shall protect the stored audit records in the audit trail from unauthorised deletion. FAU_STG.1.2/AK The TSF shall be able to prevent522 unauthorised modifications to the stored audit records in the audit trail. Anwendungshinweis 204: Entsprechend [27] ist kein Nutzer befugt, Modifizierungen der Protokoll- aufzeichnungen vorzunehmen. Der Protokollspeicher kann weit über 10.000 Einträge aufnehmen; ältere Einträge werden rollierend überschrieben. 519 [assignment: other audit relevant information] 520 [assignment: authorised users] 521 [assignment: list of audit information] 522 [selection, choose one of: prevent, detect] Security Target secunet konnektor 2.1.0 secunet Seite 305 von 424 FAU_STG.4/AK Prevention of audit data loss Hierarchical to: FAU_STG.3 Action in case of possible audit data loss Dependencies: FAU_GEN.1 Audit data generation FAU_STG.4.1/AK The TSF shall overwrite the oldest stored audit records523 and [raise Error Condition EC_LOG_OVERFLOW according to TAB_KON_503 [27]]524 if the audit trail is full. 523 [selection, choose one of: “ignore audited events”, “prevent audited events, except those taken by the authorised user with special rights”, “overwrite the oldest stored audit records”] 524 [assignment: other actions to be taken in case of audit storage failure] Security Target secunet konnektor 2.1.0 Seite 306 von 424 secunet 6.3.7. Sicherheitsanforderungen für die ePA Fachanwendung (PTV4) 6.3.7.1. VAU-Kanäle unter Nutzung sicherer kryptographischer Algorithmen Anmerkung 11. Zur Absicherung der Kommunikation zwischen der VAU des ePA Aktensystems und dem Client (Konnektor mit ePA Fachmodul) wird das in [30], Kapitel 6, spezifizierte Kommunikationsprotokoll umgesetzt. FTP_ITC.1/VAU Inter-TSF trusted channel VAU Hierarchical to: No other components. Dependencies: No dependencies. FTP_ITC.1.1/VAU The TSF shall provide a communication channel between itself and another trusted IT product der Vertrauenswürdigen Ausführungsumgebung (VAU)525 that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification and526 disclosure. FTP_ITC.1.2/VAU The TSF shall permit the TSF527 to initiate communication via the trusted channel. FTP_ITC.1.3/VAU The TSF shall initiate communication via the trusted channel for communication required by the ePA architecture for exchange of messages with the VAU528 . 525 refinement 526 refinement (or  and) 527 [selection: the TSF, another trusted IT-Product] 528 [assignment: list of functions for which a trusted channel is required] Security Target secunet konnektor 2.1.0 secunet Seite 307 von 424 Refinement: Die Anforderung „protection of the channel data from modification and disclosure“ ist zu verstehen als Schutz der Integrität und der Vertraulichkeit (der Kanal muss beides leisten). Dabei umfasst hier „integrity“ außer der Verhinderung unbefugter Modifikation auch Verhinderung von Wiedereinspielen von Daten während der Kommunikation. Der Trusted Channel muss als „leichtgewichtige Sicherungsschicht“ innerhalb eines TLS-Kanals aufgebaut werden (siehe gemSpec_Krypt [30] Kapitel 6). Die folgende Cipher Suite muss unterstützt werden: AES-256-GCM-BrainpoolP256r1-SHA-256, mit ECDH zum Schlüsselaustausch. Der Anwendungskonnektor startet die Kommunikation mit VAUClientHello Nachricht und kann die Endstelle in Abhängigkeit von dem Serverzertifikat und der ServerHello Nachricht authentifizieren. Anmerkung 12. Der Anwendungskonnektor muss die Regeln durchsetzen, die gemäß [30], Kapitel 6, für die vom Konnektor initiierten VAU-Verbindungen gefordert werden. Die Nachrichten werden entsprechend A_16884 per HTTP mit dem Content-Type 'application/json' oder 'application/octet-stream' übermittelt. Der Konnektor führt einen unsigned 64-Bit-Nachrichtenzähler, der bei jeder abgeschickten Nachricht (siehe A_16945-02) um zwei erhöht wird und einen KeyID-Zählerwert, welcher bei jeder erfolgreichen Nachricht um eins erhöht wird. Das komplette VAU Protokoll mit VAUClientHello (A_16903), VAUClientSigFin (A_17070-02, A_17071), VAUServerFin (A_17084) und VAUServerHelloData (A_16903, A_16941-01) ist aufgebaut wie beschreiben in A_16900 und folgende. Bei jeder VAU-Verbindung vom Anwendungskonnetor stellt der Anwendungskonnetor sicher, dass:  die Authentizierung für jeden Endpunkt durchgeführt wird.  nur der Konnektor die VAU-Verbindung beginnen kann und bei der Verbinung eine VAUClientHello Nachricht laut A_16883-01 geschickt wird.  zusätzliche (i. S. v. ihm unbekannte) Datenfelder (Key-Value-Paare) in JSON-Objekten (Typ-(1)-Nachrichten und "Data"-Feldern darin) im Rahmen des VAU-Protokolls werden vom Konnektor ignoriert. (A_17074)  neue symmetrische Schlüssel generiert werden, wenn der unsigned 64- bit Zähler möglicherweise überläuft oder nach 24 Stunden.  die Verbindung terminiert wird, wenn das Zertifikat nicht die OID oid_epa_vau (nach [50]) hat. Security Target secunet konnektor 2.1.0 Seite 308 von 424 secunet  Die Verbindung terminiert wird wenn die Abbruchbendingungen nach A_17084, A_16957-01, A_16900, A_16903 oder A_16941-01 gelten FCS_CKM.1/VAU Cryptographic key generation / VAU Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation] hier erfüllt durch: FCS_COP.1/VAU.AES und FCS_COP.1/VAU.Auth [FCS_CKM.4 Cryptographic key destruction] hier erfüllt durch FCS_CKM.4/AK FCS_CKM.1.1/VAU The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm VAU key agreement with ECDH and AES-256-GCM-BrainpoolP256r1-SHA-256.529 and specified cryptographic key sizes 256 bit for AES-256, 256 for ECDH530 that meet the following: [30] (A_16943-01), FIPS PUB 180- 4 [54], RFC-5869 [103], RFC 5639 [101].531 529 [assignment: cryptographic key generation algorithm] 530 [assignment: cryptographic key sizes] 531 [assignment: list of standards] Security Target secunet konnektor 2.1.0 secunet Seite 309 von 424 FCS_COP.1/VAU.AES Cryptographic operation for VAU Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] hier erfüllt durch: FCS_CKM.1/VAU FCS_CKM.4 Cryptographic key destruction hier erfüllt durch: FCS_CKM.4/AK FCS_COP.1.1/VAU.AES The TSF shall perform symmetric authenticated encryption and decryption532 in accordance with a specified cryptographic algorithm AES-256 in GCM Mode with authentication tag length of 128 bit 533 and cryptographic key sizes 256 bit for AES-256534 that meet the following: FIPS 197 [55], NIST 800-38D [99], RFC 5116 [104], specification [30] 535 . Anmerkung 13. Es gilt Anwendungshinweis 109. Der IV für den GCM Mode muss zufällig gewählt werden 532 [assignment: list of cryptographic operations] 533 [assignment: cryptographic algorithm] 534 [assignment: cryptographic key sizes] 535 [assignment: list of standards] Security Target secunet konnektor 2.1.0 Seite 310 von 424 secunet FCS_COP.1/VAU.Auth Cryptographic operation for VAU Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] Die hier genannten Abhängigkeiten werden nicht erfüllt. Begründung: Die signature creation wird von der SMC-B oder eGK durchgeführt. Der verwendete private Schlüssel verbleibt dabei immer innerhalb der Karte. Daher ist auch keine Funktionalität zum Import bzw. zur Generierung des kryptographischen Schlüssels erforderlich. Die verification of digital signatures kann auch im EVG durchgeführt werden. Die entsprechenden öffentlichen Schlüsselobjekte werden durch den Import von Zertifikaten in den EVG eingebracht, die Abhängigkeit wird inhaltlich durch FPT_TDC.1/SGDVAU erfüllt. FCS_CKM.4 Cryptographic key destruction hier erfüllt durch: FCS_CKM.4/AK für die öffentlichen Schlüsselobjekte zur verification of digital signatures im EVG. FCS_COP.1.1/VAU.Auth The TSF shall perform a) verification of digital signatures and b) signature creation with support of eGK, SMC-B storing the signing key and performing the ECC operation 536 in accordance with a specified cryptographic algorithm ECDSA- with-Sha256 OID 1.2.840.10045.4.3.2 with curve brainpoolP256r1537 and cryptographic key sizes 256 bit538 that meet the following: TR-03111 [23], RFC 5639 [101], FIPS PUB 180-4 [54]539 . Anmerkung 14. Die Signaturberechnung gemäß FCS_COP.1/VAU.Auth wird für die Berechnung digitaler Signaturen zur Authentisierung bei der VAU verwendet. Der EVG nutzt dafür bei Verbindungen zur VAU die AUT-Identity der SMC-B oder eGK. Der dafür benötigt asymmetrische Schlüssel kann während der Produktion der Chipkarte importiert oder generiert werden. Es werden deshalb keine spezifischen Anforderungen an die Quelle dieses Schlüssels gestellt. 536 [assignment: list of cryptographic operations] 537 [assignment: cryptographic algorithm] 538 [assignment: cryptographic key sizes] 539 [assignment: list of standards] Security Target secunet konnektor 2.1.0 secunet Seite 311 von 424 6.3.7.2. SGD-Kanäle unter Nutzung sicherer kryptographischer Algorithmen Anmerkung 15. Zur Absicherung der Kommunikation zwischen den Schlüsselgenerierungsdiensten der ePA Fachanwendung (SGD1 und SGD2) und dem Client (Konnektor mit ePA Fachmodul) werden über das HTTPS-Interface Datenpakete ausgetauscht. Einzelne darin enthaltene Datenfelder, die direkt für das HSM des jeweiligen SGD bestimmt sind, werden durch ECIES-Verschlüsselung gesichert. Dabei handelt es sich nicht um einen Kommunikationskanal im eigentlichen Sinne. Dennoch wird der gesicherte Anteil der Kommunikation als „Kanal“ zwichen Client und SGD-HSM aufgefasst und im folgenden mit FTP_ITC.1/SGD (Analog zum VAU Kanal FTP_ITC.1/VAU) als trusted channel modelliert. So können gezielte Anforderungen an diese Kommunikation gestellt werden, siehe Refinement und Anmerkung zum SFR. FTP_ITC.1/SGD Inter-TSF trusted channel SGD Hierarchical to: No other components. Dependencies: No dependencies. FTP_ITC.1.1/SGD The TSF shall provide a communication channel between itself and another trusted IT product dem Schlüsselgenerierungsdienst (SGD)540 that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification and541 disclosure. FTP_ITC.1.2/SGD The TSF shall permit the TSF542 to initiate communication via the trusted channel. FTP_ITC.1.3/SGD The TSF shall initiate communication via the trusted channel for communication required by the ePA architecture for exchange of messages with the SGD 543 . 540 refinement 541 refinement (or  and) 542 [selection: the TSF, another trusted IT-Product] 543 [assignment: list of functions for which a trusted channel is required] Security Target secunet konnektor 2.1.0 Seite 312 von 424 secunet Refinement: Die Anforderung „protection of the channel data from modification and disclosure“ ist zu verstehen als Schutz der Integrität und der Vertraulichkeit (der Kanal muss beides leisten). Dabei umfasst hier „integrity“ außer der Verhinderung unbefugter Modifikation auch Verhinderung von Wiedereinspielen von Daten während der Kommunikation. Der Trusted Channel muss auf Basis des ECIES- Protokolls aufgebaut werden (siehe Spezifikation Schlüsselgenerierungsdienst ePA [48], Kapitel 9). Die folgenden kryptographischen Algorithmen MÜSSEN unterstützt werden: BrainpoolP256r1, SHA-256 und AES-256-GCM für ECIES, ECDSA für die Signatur. Das ECIES-Schlüsselmaterial für den Kanal muss kryptographisch frisch sein und damit nach jedem erfolgreichen Kanal neu erzeugt werden, siehe A_18005. Anmerkung 16. Der Anwendungskonnektor muss die Regeln durchsetzen, die gemäß der Spezifikationen [30] und [48] für die vom Konnektor initierten SGD- Verbindungen gefordert werden. Wenn der EVG unbekannte Key-Value Paare in JSON Nachrichten erhält, müssen diese in der Kommunikation ignoriert werden. Bei dem SGD Protokoll wird eine zufällige Challenge vom EVG erstellt, welche bei der Rückantwort auf Korrektheit geprüft wird. Bei jeder SGD-Verbindung vom Anwendungskonnetor stellt der Anwendungskonnetor sicher, dass:  die Authentizierung für jeden Endpunkt (SGD-HSM 1 und SGD-HSM 2) durchgeführt wird. Hierbei wird GetPublicKey (A_17897 und A_17899) als Funktion genutzt.  nur der Konnektor die SGD-Verbindung beginnen kann.  neue symmetrische Schlüssel für jeden Schlüsselableitungsrequest generiert werden (A_18005).  die Kodierung des Chiffrat entsprechend A_17902 durchgeführt wird.  die Anfragen sind entsprechend A_17924-01 aufgebaut.  der Konnektor nimmt bei der zweiten Verschlüsselungsschicht die Associated Data (AD) der ersten Schicht (AD 1) im AD der zweiten Schicht (AD 2) mit auf. Der Konnektor führt zunächst AD 1 und dann AD 2 auf und trennt beide durch mindestens ein Leerzeichen. Die GMAC-Berechnung erfolgt bei der zweiten Verschlüsselung über beide AD (AD1 und AD2) (AD1 + AD2 bilden die AD für den AES-GCM). (A_17930) Security Target secunet konnektor 2.1.0 secunet Seite 313 von 424  eine Prüfung der Telematik-ID wird laut A_18003 durchgeführt.  die Variable KVNR wird vom Konnektor laut A_18006 interpretiert.  der Konnektor prüft die Antwort auf eine „KeyDerivation“ entsprechend A_18031-01 und A_20977.  die Verbindung terminiert wird, wenn das Zertifikat nicht die OID oid_SGD{1/2}_hsm (siehe A_17848 und [50]) und die korrekte Servicetypkennung („http://uri.etsi.org/TrstSvc/Svctype/unspecified“, siehe A_17847) hat. Bei der Prüfung des SGD-HSM-ECIES-Schlüssel gelten die Regeln für Abbrüche laut A_18024.  die Schlüsselableitung laut A_17888 und A_17898 durchgeführt wird für SGD ePA unter Nutzung des zuvor erhaltenen Authentisierungstoken (Prüfung der Antwort des SGD auf GetAuthenticationToken entsprechend A_18028).  der Konnektor prüft, ob im HTTP-Response-Header einer Antwortnachricht eine HTTP-Variable Namens "SGD-Userpseudonym" enthalten ist. Wenn dies der Fall ist führt der Konnektor diese Variable inkl. Wert unverändert im nächsten Request an den SGD im HTTP- Request-Header auf. Security Target secunet konnektor 2.1.0 Seite 314 von 424 secunet FCS_COP.1/SGD.ECIES Cryptographic operation for VAU Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] hier erfüllt durch: FDP_ITC.2/SGD FCS_CKM.4 Cryptographic key destruction hier erfüllt durch: FCS_CKM.4/AK FCS_COP.1.1/SGD.ECIES The TSF shall perform ECIES based authenticated hybrid encryption and decryption with ECC key pair generation544 in accordance with a specified cryptographic algorithm ECIES with brainpoolP256r1, HKDF with SHA-256 and AES-256 in GCM Mode with authentication tag length of 128 bit 545 and cryptographic key sizes 256 bit for AES-256546 that meet the following: SEC1-2009 [102], NIST-800-56-A [105], RFC 5639 [101], FIPS PUB 180-4 [54], RFC-5869 [103], FIPS 197 [55], NIST 800-38D [99], RFC 5116 [104], gemSpec_Krypt [30] 547 . Anmerkung 17. Die Kodierung des "PublicKeyECIES" muss wie in A_17900 beschrieben geschehen. Die Behandlung der Signatur muss nach A_17901 geschehen. Der Konnektor prüft, ob der erhaltetene ephemeren ECC-Punkt auf der elliptischen Kurve liegt (A_17903). Die Anfrage „GetAuthenticationToken“ wird mit einer 256 bit Zufallszahl (extern erzeugt) sowie eines „H-Wert“ (SHA-256 Hash über Client-ECIES-Schlüssel und AUT-Zertifikat) codiert wie in A_18025-01 beschrieben. Das erhaltene Chiffrat wird laut A_17902 kodiert und bei „GetAuthenticationToken“ (A_18021) verwendet. Die Erzeugung der Anfrage „KeyDerivation“ wird entsprechend zu A_18029 vom Konnektor durchgeführt. Anmerkung 18. Es gilt Anwendungshinweis 109. Der IV für den GCM Mode muss zufällig gewählt werden. Ein Chiffrat muss laut A_18004 kodiert werden. 544 [assignment: list of cryptographic operations] 545 [assignment: cryptographic algorithm] 546 [assignment: cryptographic key sizes] 547 [assignment: list of standards] Security Target secunet konnektor 2.1.0 secunet Seite 315 von 424 FCS_COP.1/SGD.Auth Cryptographic operation for SGD Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] Die hier genannten Abhängigkeiten werden nicht erfüllt. Begründung: Die signature creation wird von der SMC-B oder eGK durchgeführt. Der verwendete private Schlüssel verbleibt dabei immer innerhalb der Karte. Daher ist auch keine Funktionalität zum Import bzw. zur Generierung des kryptographischen Schlüssels erforderlich. Die verification of digital signatures kann auch im EVG durchgeführt werden. Die entsprechenden öffentlichen Schlüsselobjekte werden durch den Import von Zertifikaten in den EVG eingebracht, die Abhängigkeit wird inhaltlich durch FPT_TDC.1/SGDVAU erfüllt. FCS_CKM.4 Cryptographic key destruction hier erfüllt durch: FCS_CKM.4/AK für die öffentlichen Schlüsselobjekte zur verification of digital signatures im EVG. FCS_COP.1.1/SGD.Auth The TSF shall perform a) verification of digital signatures and b) signature creation with support of SMC-B or eGK storing the signing key and performing the ECC operation 548 in accordance with a specified cryptographic algorithm ECDSA- with-Sha256 OID 1.2.840.10045.4.3.2549 and cryptographic key sizes 256 bit550 that meet the following: TR-03111 [23], RFC 5639 [101], FIPS PUB 180-4 [54]551 . Anmerkung 19. Die Signaturberechnung gemäß FCS_COP.1/SGD.Auth wird für die Berechnung der digitaler Signaturen zur Authentisierung des eigenen ephemeren öffentlichen Schlüssels beim SGD verwendet (A_17900, A_17901 in [48] und A_17874 in [30]). Der EVG nutzt dafür bei Verbindungen zum SGD die SMC-B oder 548 [assignment: list of cryptographic operations] 549 [assignment: cryptographic algorithm] 550 [assignment: cryptographic key sizes] 551 [assignment: list of standards] Security Target secunet konnektor 2.1.0 Seite 316 von 424 secunet die eGK (bei Kontoeröffnung und Berechtigungsvergabe). Der Konnektor unterstützt auch G2.0 Karten bei denen ausschließlich RSA-Signatur-Verfahren möglich sind. Für G2.0 Karten wird das Signatur-Verfahren RSASSA-PSS mit SHA256 ([53]) für die Authentisierung des eigenen ephemeren öffentlichen Schlüssels beim SGD verwendet. Für Karten, die ECDSA- und RSA- Verfahren unterstützen (ab G2.1) wird vom Konnektor immer ECDSA für die Berechnung der Signaturen verwendet. FDP_ITC.2/SGD Import of user data with security attributes / SGD-Client Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] hier erfüllt durch: FDP_ACC.1/SGD [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] hier erfüllt durch: FTP_ITC.1/SGD FPT_TDC.1 Inter-TSF basic TSF data consistency hier erfüllt durch: FPT_TDC.1/SGDVAU FDP_ITC.2.1/SGD The TSF shall enforce the SGD-SFP552 when importing user data, controlled under the SFP, from outside of the TOE. FDP_ITC.2.2/SGD The TSF shall use the security attributes associated with the imported user data. FDP_ITC.2.3/SGD The TSF shall ensure that the protocol used provides for the unambiguous association between the security attributes and the user data received. FDP_ITC.2.4/SGD The TSF shall ensure that interpretation of the security attributes of the imported user data is as intended by the source of the user data. FDP_ITC.2.5/SGD The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TOE: (1) Die TSF importiert über die Operation GetPublicKey den öffentlichen ECIES-Schlüssel eines SGD-HSMs.553 FDP_ACC.1/SGD Subset access control / SGD-Client Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control hier erfüllt durch: FDP_ACF.1/SGD FDP_ACC.1.1/SGD The TSF shall enforce the SGD-SFP554 on 552 [assignment: access control SFP(s) and/or information flow control SFP(s)] 553 [assignment: additional importation control rules] 554 [assignment: access control SFP] Security Target secunet konnektor 2.1.0 secunet Seite 317 von 424 the subject:  SGD-Client, the object:  öffentlicher ECIES-Schlüssel eines SGD-HSMs, and the operation:  ECIES-Encryption entsprechend FCS_COP.1/SGD.ECIES FDP_ACF.1/SGD Security attribute based access control / SGD-Client Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control hier erfüllt durch: FDP_ACC.1/SGD FMT_MSA.3 Static attribute initialisation nicht erfüllt mit folgender Begründung: Für das Datenobjekt öffentlicher ECIES-Schlüssel eines SGD-HSMs findet keine Initialisierung von Sicherheitsattributen im Sinne von FMT_MSA.3 statt: ECIES-Schlüssel, Signatur und Zertifikat können nicht sinnvoll vom EVG mit Default Werten initialisiert werden. FDP_ACF.1.1/SGD The TSF shall enforce the SGD-SFP555 to objects based on the following: subject:  SGD-Client objects:  öffentlicher ECIES-Schlüssel eines SGD-HSMs with the security attribute: a. Signatur b. Zertifikat FDP_ACF.1.2/SGD The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: Der SGD-Client darf den öffentlicher ECIES-Schlüssel eines SGD- HSMs für ECIES-Encryption entsprechend FCS_COP.1/SGD.ECIES verwenden wenn die folgenden Bedingungen erfüllt sind (A_18024): (1) Das erhaltene Zertifikat des SGD-HSMs muss gemäß A_17847 gültig sein. (2) Das erhaltene Zertifikat des SGD-HSMs muss so wie vom Client erwartet entweder von einem SGD 1 oder von einem SGD 2 gemäß A_17848 sein. 555 [assignment: access control SFP] Security Target secunet konnektor 2.1.0 Seite 318 von 424 secunet (3) Das erhaltene Zertifikat des SGD-HSMs muss zeitlich gültig sein. (4) Die Signatur muss eine kryptographisch korrekte Signatur, die auf den EE-Schlüssel des erhaltene Zertifikat rückführbar ist sein..556 FDP_ACF.1.3/SGD The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none557 . FDP_ACF.1.4/SGD The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none558 . Anmerkung 20. Der „öffentlicher ECIES-Schlüssel eines SGD-HSMs“ und die entsprechenden Sicherheitsattribute „Signatur“ und „Zertifikat“ werden in der Response zum GetPublicKey-Request an den SGD-Client übermittels (A_17895-01 und A_17894-01) FPT_TDC.1/SGDVAU Inter-TSF basic TSF data consistency Hierarchical to: No other components. Dependencies: No dependencies. FPT_TDC.1.1/ SGDVAU The TSF shall provide the capability to consistently interpret (1) X.509-Zertifikate für VAU-Verbindungen und X.509-Zertifikate für SGD-Verbindungen559 (2) öffentlicher ECIES-Schlüssel eines SGD-HSMs when shared between the TSF and another trusted IT product. FPT_TDC.1.2/ SGDVAU The TSF shall use the following rules (1) Für X.509-Zertifikate für VAU-Verbindungen und X.509- Zertifikate für SGD-Verbindungen müssen die „interpretation rules“ nach FPT_TDC.1/NK.TLS.Zert umgesetzt werden. (2) Das VAU Zertifikat muss die OID oid_epa_vau ([50]) haben. (3) Das SGD Zertifikat muss die OID oid_SGD{1/2}_hsm (siehe A_17848 und [50]) und die korrekte Servicetypkennung („http://uri.etsi.org/TrstSvc/Svctype/unspecified“, siehe A_17847) haben. 560 (4) Der öffentliche ECIES-Schlüssel eines SGD-HSMs muss die Kodierung nach A_17894-01 aufweisen. when interpreting the TSF data from another trusted IT product. 556 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects]. 557 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] 558 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] 559 [assignment: list of TSF data types] 560 [assignment: list of interpretation rules to be applied by the TSF] Security Target secunet konnektor 2.1.0 secunet Seite 319 von 424 Security Target secunet konnektor 2.1.0 Seite 320 von 424 secunet 6.4. Sicherheitsanforderungen an die Vertrauenswürdigkeit des EVG Es wird die Vertrauenswürdigkeitsstufe EAL3 erweitert um ADV_FSP.4, ADV_TDS.3, ADV_IMP.1, ALC_TAT.1, AVA_VAN.3 und ALC_FLR.2 gefordert. Daraus ergibt sich eine Resistenz gegen „Enhanced Basic“ Angriffspotential. Eine Erklärung für die gewählte EAL- Stufe findet sich in Abschnitt 6.5.7. Einige Anforderungen an die Vertrauenswürdigkeit (Assurance) werden wie in den folgenden Unterabschnitten beschrieben verfeinert. 6.4.1. Verfeinerungen entsprechend Schutzprofil 6.4.1.1. Verfeinerung zur Vertrauenswürdigkeitskomponente ADV_ARC.1 In Hinblick auf den EVG-Teil Netzkonnektor gilt die folgende Verfeinerung: Die Sicherheitsarchitektur muss beschreiben, wie der EVG Daten, Kommunikationspfade und Zugriffe der unterschiedlichen Dienste und Anwendungen separiert. Der Hersteller muss die Sicherheitsarchitektur beschreiben. Die Beschreibung der Sicherheitsarchitektur muss zeigen, auf welche Weise die Sicherheitsarchitektur des EVGs die Separation der unterschiedlichen Dienste und Anwendungen (zwischen LAN und WAN sowie zwischen den Updatemechanismen und dem Datenfluss im Normalbetrieb) sicherstellt. Der Evaluator muss die Beschreibung analysieren (examine), um festzustellen, dass sie beschreibt, auf welche Weise die Sicherheitsarchitektur des EVGs die Separation der unterschiedlichen Dienste und Anwendungen sicherstellt. In Hinblick auf den EVG-Teil Anwendungskonnektor gilt die folgende Verfeinerung: Das Element ADV_ARC.1.4C wird durch den Zusatz verfeinert: Die Sicherheitsarchitekturbeschreibung muss den Selbstschutz (1) vor Missbrauch der TSF durch Verwendung des EVT_MONITOR_OPERATIONS [27], (2) der Vertraulichkeit und der Integrität der TSF-Daten (s. TIP1-A_4813 Persistieren der Konfigurationsdaten [27]), (3) vor Entnahme der gSMC-K und Kompromittierung der Kommunikation der gSMC-K mit dem EVG beschreiben. 6.4.1.2. Verfeinerung zur Vertrauenswürdigkeitskomponente Betriebsdokumentation AGD_OPE.1 zu Signaturrichtlinien In Hinblick auf den EVG-Teil Netzkonnektor gilt die folgende Verfeinerung: Security Target secunet konnektor 2.1.0 secunet Seite 321 von 424 AGD_OPE.1 wird bzgl. der Inbetriebnahme wie folgt verfeinert: Das Verfahren zur Inbetriebnahme muss Schutz gegen das In-Umlauf-Bringen gefälschter Konnektoren bieten (sowohl während der Erstauslieferung als auch bedingt durch unbemerkten Austausch), siehe O.NK.EVG_Authenticity. Dies unterstützt die Verwendung der (in EAL3 bereits enthaltenen) Komponente AGD_OPE.1. Das Verfahren zur Inbetriebnahme muss so ausgestaltet werden, dass das Ziel O.NK.EVG_Authenticity erfüllt wird. Der Hersteller muss in seiner Benutzerdokumentation das Verfahren zur Inbetriebnahme des EVGs beschreiben. Diese Beschreibung muss zeigen, auf welche Weise das Verfahren zur Inbetriebnahme (in Verbindung mit dem Auslieferungsverfahren) sicherstellt, dass nur authentische EVGs in Umlauf gebracht werden können. Der Evaluator muss die Beschreibung analysieren (examine), um festzustellen, dass sie beschreibt, auf welche Weise das Verfahren zur Inbetriebnahme (in Verbindung mit dem Auslieferungsverfahren) sicherstellt, dass nur authentische EVGs in Umlauf gebracht werden können. AGD_OPE.1 wird bzgl. der Administration der Paketfilter-Regeln wie folgt verfeinert: Die Benutzerdokumentation muss für den Administrator verständlich beschreiben, welche Paketfilter-Regeln er administrieren kann. Die Benutzerdokumentation muss den Administrator befähigen, die von ihm administrierbaren Paketfilter- Regeln in sicherer Art und Weise zu konfigurieren. Für die von ihm administrierbaren Paketfilter-Regeln muss er in die Lage versetzt werden, geeignete Regelsätze aufzustellen. Der Hersteller muss in seiner Benutzerdokumentation beschreiben, welche Paketfilter-Regeln der Administrator administrieren kann. Die Benutzerdokumentation muss den Administrator befähigen, die von ihm administrierbaren Paketfilter-Regeln in sicherer Art und Weise zu konfigurieren. Für die von ihm administrierbaren Paketfilter-Regeln muss er in die Lage versetzt werden, geeignete Regelsätze aufzustellen. Der Evaluator muss die Benutzerdokumentation analysieren (examine), um festzustellen, dass sie beschreibt, welche Paketfilter-Regeln der Administrator administrieren kann, und dass sie den Administrator befähigt, die von ihm administrierbaren Paketfilter-Regeln in sicherer Art und Weise zu konfigurieren (für die von ihm administrierbaren Paketfilter-Regeln muss der Administrator in die Lage versetzt werden, geeignete Regelsätze aufzustellen). AGD_OPE.1 wird bzgl. der Internet-Anbindung wie folgt verfeinert: Die Benutzerdokumentation muss die Benutzer und Betreiber des Konnektors über die Risiken aufklären, die entstehen, wenn neben dem EVG eine weitere Anbindung des lokalen Netzwerks des Leistungserbringers an das Transportnetz bzw. das Internet erfolgt. Security Target secunet konnektor 2.1.0 Seite 322 von 424 secunet Der Hersteller muss in der Benutzerdokumentation die Benutzer und Betreiber des Konnektors über die Risiken aufklären, die entstehen, wenn neben dem EVG eine weitere Anbindung des lokalen Netzwerks des Leistungserbringers an das Transportnetz bzw. Internet erfolgt. Zudem muss der Hersteller in der Benutzerdokumentation verständlich darauf hinweisen, dass auch Angriffe aus dem Internet über SIS nicht auszuschließen sind. Das Client-System muss entsprechende Sicherheitsmaßnahmen besitzen. Der Evaluator muss die Benutzerdokumentation analysieren (examine), um festzustellen, dass sie die Benutzer und Betreiber des Konnektors hinreichend gut (verständlich und vollständig) über die Risiken aufklärt, die entstehen, wenn neben dem EVG eine weitere Anbindung des lokalen Netzwerks des Leistungserbringers an das Transportnetz bzw. Internet erfolgt. In Hinblick auf den EVG-Teil Anwendungskonnektor gilt die folgende Verfeinerung: Das Element AGD_OPE.1.1C wird durch den Zusatz verfeinert: Die Benutzerdokumentation muss alle im EVG implementierten Signaturrichtlinien und Verschlüsselungsrichtlinien beschreiben und Informationen zu deren Anwendung bereitstellen. Für jede implementierte Signaturrichtlinie muss die Benutzerdokumentation beschreiben:  den Namen der Signaturrichtlinie  die Signaturart, d. h. qualifizierte elektronische Signatur, fortgeschrittene oder digitale Signatur,  die gemäß dieser Signaturrichtlinie signierten Daten. Für jede implementierte Verschlüsselungsrichtlinie muss die Benutzerdokumentation beschreiben:  den Namen der Verschlüsselungsrichtlinie  die gemäß dieser Verschlüsselungsrichtlinie verschlüsselten Daten.  die unter dieser Verschlüsselungsrichtlinie erlaubten Empfänger der Daten. 6.4.1.3. Verfeinerung zur Vertrauenswürdigkeitskomponente Betriebsdokumentation AGD_PRE.1 In Hinblick auf den EVG-Teil Anwendungskonnektor gilt die folgende Verfeinerung: Das Element AGD_PRE.1.1C wird durch den Zusatz verfeinert: Der Hersteller muss beschreiben, auf welche Weise das Verfahren zur Inbetriebnahme (in Verbindung mit dem Auslieferungsverfahren gemäß ALC_DEL.1.1C) sicherstellt, dass nur authentische EVGs in Umlauf gebracht werden können. Das Element AGD_PRE.1.2C wird durch den Zusatz verfeinert: Security Target secunet konnektor 2.1.0 secunet Seite 323 von 424 Der Hersteller muss die Installation von Updates gemäß [27], Kapitel 4.3.9, und das Verfahren zur Inbetriebnahme von Updates des EVGs in der Benutzerdokumentation beschreiben. Das Element AGD_PRE.1.1E wird durch den Zusatz verfeinert: Der Evaluator muss die Beschreibung analysieren (examine), um festzustellen, dass sie beschreibt, auf welche Weise das Verfahren zur Inbetriebnahme (in Verbindung mit dem Auslieferungsverfahren) sicherstellt, dass nur authentische EVGs und zulässige Updates in Umlauf gebracht werden können. 6.4.1.4. Verfeinerung von ALC_DEL.1 Für den EVG gilt die folgende Verfeinerung: ALC_DEL.1 wird wie folgt verfeinert: Das Auslieferungsverfahren muss Schutz gegen das In-Umlauf-Bringen gefälschter Konnektoren bieten (sowohl während der Erstauslieferung als auch bedingt durch unbemerkten Austausch), siehe O.NK.EVG_Authenticity. Dies unterstützt die Verwendung der (in EAL3 bereits enthaltenen) Komponente ALC_DEL.1. Das Auslieferungsverfahren muss so ausgestaltet werden, dass das Ziel O.NK.EVG_Authenticity erfüllt wird. Der Hersteller muss das Auslieferungsverfahren beschreiben. Die Beschreibung des Auslieferungsverfahrens muss zeigen, auf welche Weise das Auslieferungsverfahren (in Verbindung mit den Verfahren zur Inbetriebnahme) des EVGs sicherstellt, dass nur authentische EVGs in Umlauf gebracht werden können. Der Evaluator muss die Beschreibung analysieren (examine), um festzustellen, dass sie beschreibt, auf welche Weise das Auslieferungsverfahren (in Verbindung mit den Verfahren zur Inbetriebnahme) des EVGs sicherstellt, dass nur authentische EVGs in Umlauf gebracht werden können. 6.4.2. Verfeinerungen hinsichtlich der Fachmodule NFDM, AMTS und ePA Im folgenden sind zusärtzliche Prüfanforderungen an die Fachmodule des Konnektors formuliert. Siehe dazu auch die „Erweiterungen für unterstützte Fachmodule“ in Kapitel 8.2. Das Fachmodul VSDM ist integraler Bestandteil des Anwendungskonnektors und wurde vollständig in den Sicherheitsanforderungen des zugrundeleigenenden Schutzprofils und dieser Sicherheitsvorgaben berücksichtigt. Der secunet konnektor 2.1.0 enthält in seiner Ausbaustufe PTV5 WR1 neben dem VSDM Fachmodul die modular integrierten Fachmodule ePA (nach [49]), NFDM (nach [44]) und AMTS (nach [45]). Security Target secunet konnektor 2.1.0 Seite 324 von 424 secunet Entsprechend der Technischen Richtlinien TR-03154 ([24]) und TR-03155 ([25]), Kapitel 3.3.2 sollen …für das Fachmodul relevante Sicherheitseigenschaften des Konnektors zusätzlich in dessen Security Target aufgenommen und Common Criteria-zertifiziert werden, wenn diese im [PP0098] nicht enthalten sind. In der TR-03157 ([26]), Kapitel 3.2.2, wird entsprechend gefordert: Die Anforderungen aus dem Produkttypsteckbrief müssen daher zusätzlich zum PP im Konnektor-ST aufgenommen und mitzertifiziert werden. und Schnittstellen die eine Sicherheitsleistung für das Fachmodul erbringen, müssen im Rahmen der CC-Zertifizierung mit geprüft werden. Die jeweils relevanten Sicherheitseigenschaften sowie die vom jeweiligen Fachmodul aufgerufene TUCs nach [27] werden in Kapitel 3.3.2 bzw. 3.2.2 der Technischen Richtlinien aufgeführt. Um sicherzustellen, dass im Rahmen der Evaluierung nach Common Criteria diese Sicherheitseigenschaften hinreichend berücksichtigt werden, sind die folgenden Anforderungen an die Vertrauenswürdigkeit (Assurance) entsprechend verfeinert: Für den EVG gelten die folgende Verfeinerungen: ASE_TSS.1 wird wie folgt verfeinert: Der Konnektor unterstützt die Fachmodule ePA, NFDM und AMTS. In den Technischen Richtlinien TR-03154 ([24]) und TR-03155 ([25]), Kapitel 3.3.2 bzw. TR-03157 ([26]), Kapitel 3.2.2, werden Anforderungen an den Konnektor gestellt, die im Rahmen der CC-Zertifizierung berücksichtigt werden müssen. Die für die Fachmodule ePA, NFDM und AMTS relevanten Sicherheitseigenschaften des Konnektors müssen zusätzlich im Security Target des Konnektors aufgenommen werden. Der Hersteller muss im Security Target beschreiben, dass der Konnektor die nach TR-03154 ([24]) und TR-03155 ([25]), Kapitel 3.3.2 bzw. TR-03157 ([26]), Kapitel 3.2.2, relevanten Sicherheitseigenschaften des Konnektors umsetzt. Der Evaluator muss prüfen, ob die nach TR-03154 ([24]) und TR-03155 ([25]), Kapitel 3.3.2 bzw. TR-03157 ([26]), Kapitel 3.2.2, relevanten Sicherheitseigenschaften des Konnektors vollständig im Security Target berücksichtigt sind. ADV_FSP.4 wird wie folgt verfeinert: Der Konnektor unterstützt die Fachmodule ePA, NFDM und AMTS. In den Technischen Richtlinien TR-03154 ([24]) und TR-03155 ([25]), Kapitel 3.3.2 bzw. TR-03157 ([26]), Kapitel 3.2.2, werden Anforderungen an den Konnektor gestellt, die im Rahmen der CC-Zertifizierung berücksichtigt werden müssen. Die dabei von Security Target secunet konnektor 2.1.0 secunet Seite 325 von 424 den Fachmodulen aufgerufenen Schnittstellen des Anwendungskonnektors müssen beschrieben werden. Der Hersteller muss eine Beschreibung der Schnittstellen des Anwendungskonnektors bereitstellen, an denen die relevanten Sicherheitseigenschaften des Konnektors umgesetzt werden. Der Evaluator muss die Beschreibung der Schnittstellen des Anwendungskonnektors, an denen die relevanten Sicherheitseigenschaften des Konnektors umgesetzt werden auf Vollständigkeit hinsichtlich der Vorgaben in den Technischen Richtlinien prüfen. Die Prüfung der sicheren und korrekten Implementierung der von den Schnittstellen bereitgestellten relevanten Sicherheitseigenschaften des Konnektors wird durch die Verfeinerung von ADV_TDS gefordert. ADV_TDS.3 wird wie folgt verfeinert: Der Konnektor unterstützt die Fachmodule ePA, NFDM und AMTS. In den Technischen Richtlinien TR-03154 ([24]) und TR-03155 ([25]), Kapitel 3.3.2 bzw. TR-03157 ([26]), Kapitel 3.2.2, werden Anforderungen an den Konnektor gestellt, die im Rahmen der CC-Zertifizierung berücksichtigt werden müssen. Die sichere und korrekte Umsetzung der relevanten Sicherheitseigenschaften muss geprüft werden. Der Hersteller muss ausreichende Nachweise bereitstellen, die es erlauben die sichere und korrekte Umsetzung der relevanten Sicherheitseigenschaften zu prüfen. Der Evaluator muss die sichere und korrekte Umsetzung der relevanten Sicherheitseigenschaften prüfen. Die Nachweise des Herstellers können zum Beispiel eine Beschreibung der von den Fachmodulen aufgerufenen Schnittstellen und die Abbildung der relevanten TUCs auf den Source Code enthalten. Im Rahmen der Evaluierung kann auch auf andere Prüfaspekte, wie zum Beispiel ADV_FSP, ADV_IMP oder ATE verwiesen werden, wenn darin entsprechende Prüfnachweise erbracht wurden. Security Target secunet konnektor 2.1.0 Seite 326 von 424 secunet 6.5. Erklärung der Sicherheitsanforderungen 6.5.1. Erklärung der Abhängigkeiten der funktionalen Sicherheitsanforderungen des Netzkonnektors Die Abhängigkeiten für die SFRs des Netzkonnektors sind bei deren Formulierung in Abschnitt 6.2 aufgelöst. 6.5.2. Erklärung der Abhängigkeiten der funktionalen Sicherheitsanforderungen des Anwendungskonnektors Die Abhängigkeiten für die SFRs des Anwendungskonnektors werden im Schutzprofil [16], Tabelle 25, aufgelöst und gelten unverändert auch für diese Sicherheitsvorgaben. Es wurden keine SFRs des Anwednungskonnekors aus [16] in diesen Sicherheitsvorgaben weggelassen oder darüber hinaus hinzugefügt. Die Abhängigkeiten für die zusätzlichen SFRs der ePA Fachanwendung in Abschnitt 6.3.7 sind bei deren Formulierung aufgelöst 6.5.3. Überblick der Abdeckung von Sicherheitszielen des Netzkonnektors durch SFRs des Netzkonnektors Tabelle 27 stellt die Abbildung der Sicherheitsziele des Netzkonnektors auf Sicherheitsanforderungen des Netzkonnektors zunächst tabellarisch im Überblick dar. In Abschnitt 6.5.5 wird die Abbildung erläutert und die Erfüllung der Sicherheitsziele durch die Anforderungen begründet. Sicherheitsanforderung an den EVG O.NK.TLS_Krypto O.NK.Schutz O.NK.EVG_Authenticity O.NK.Admin_EVG O.NK.Protokoll O.NK.Zeitdienst O.NK.Update O.NK.Admin_Auth O.NK.VPN_Auth O.NK.Zert_Prüf O.NK.VPN_Vertraul O.NK.VPN_Integrität O.NK.PF_WAN O.NK.PF_LAN O.NK.Stateful FTP_ITC.1/NK.VPN_TI X X X FTP_ITC.1/NK.VPN_SIS X X X FDP_IFC.1/NK.PF X X X FDP_IFF.1/NK.PF X X X FMT_MSA.3/NK.PF X X FPT_STM.1/NK X X FPT_TDC.1/NK.Zert X FDP_RIP.1/NK X FPT_TST.1/NK X FPT_EMS.1/NK X X X FAU_GEN.1/NK.SecLog X FAU_GEN.2/NK.SecLog X FMT_SMR.1./NK X X X X Security Target secunet konnektor 2.1.0 secunet Seite 327 von 424 Sicherheitsanforderung an den EVG O.NK.TLS_Krypto O.NK.Schutz O.NK.EVG_Authenticity O.NK.Admin_EVG O.NK.Protokoll O.NK.Zeitdienst O.NK.Update O.NK.Admin_Auth O.NK.VPN_Auth O.NK.Zert_Prüf O.NK.VPN_Vertraul O.NK.VPN_Integrität O.NK.PF_WAN O.NK.PF_LAN O.NK.Stateful FMT_MTD.1/NK X FIA_UID.1/NK.SMR X FIA_UAU.1/NK.SMR X X FTP_TRP.1/NK.Admin X X X FMT_SMF.1/NK X X X X FMT_MSA.1/NK.PF X X X FCS_COP.1/NK.Hash X X FCS_COP.1/NK.HMAC X FCS_COP.1/NK.Auth X X FCS_COP.1/NK.ESP X FCS_COP.1/NK.IPsec X FCS_CKM.1/NK X X X X X FCS_CKM.2/NK.IKE X X X FCS_CKM.4/NK X X X X X X FTP_ITC.1/NK.TLS X X FPT_TDC.1/NK.TLS.Zert X FCS_CKM.1/NK.TLS X FCS_COP.1/NK.TLS.HMAC X FCS_COP.1/NK.TLS.AES X FCS_COP.1/NK.TLS.Auth X FCS_CKM.1/NK.Zert X FDP_ITC.2/NK.TLS X FDP_ETC.2/NK.TLS X FMT_MOF.1/NK.TLS X FDP_ACC.1/NK.Update X FDP_ACF.1/NK.Update X FDP_ITC.1/NK.Update X FDP_UIT.1/NK.Update X Tabelle 27: Abbildung der EVG-Ziele auf Sicherheitsanforderungen Security Target secunet konnektor 2.1.0 Seite 328 von 424 secunet 6.5.4. Überblick der Abdeckung von Sicherheitszielen des Konnektors durch SFRs des Netzkonnektors und des Anwendungskonnektors Funktionale Sicherheits- anforderung (SFR) O.AK.Basis_Krypto O.AK.Admin O.AK.IFD-Komm O.AK.Chipkartendienst O.AK.EVG_Modifikation O.AK.VAD O.AK.Enc O.AK.Dec O.AK.Sig.exklusivZugriff O.AK.Sig.SignQES O.AK.Sig.SignNonQES O.AK.Sig.Einfachsignatur O.AK.Sig.Stapelsignatur O.AK.Sig.Komfortsignatur O.AK.Sig.PrüfungZertifikat O.AK.Sig.Schlüsselinhaber O.AK.Sig.SignaturVerifizierung O.AK.Selbsttest O.AK.LAN O.AK.WAN O.AK.Protokoll O.AK.Zeit O.AK.Update O.AK.exklusivZugriff O.AK.PinManagement O.AK.Infomodell O.AK.VSDM O.AK.VZD FCS_CKM.1/NK.TLS X X X FCS_COP.1/NK.TLS.HMAC X X X X FCS_COP.1/NK.TLS.AES X X X X FCS_COP.1/NK.TLS.Auth X X X X FCS_CKM.1/NK.Zert X FDP_ETC.2/NK.TLS X FDP_ITC.2/NK.TLS X FTP_TRP.1/NK.Admin X FAU_GEN.1/AK X X FAU_SAR.1/AK X X FAU_STG.1/AK X X FAU_STG.4/AK X X FCS_CKM.1/AK.AES X X X FCS_CKM.4/AK X X X X FCS_COP.1/AK.AES X X X FCS_COP.1/AK.CMS.Ent X X FCS_COP.1/AK.CMS.SigPr X X FCS_COP.1/AK.CMS.Sign X X X FCS_COP.1/AK.CMS.Ver X X FCS_COP.1/AK.PDF.SigPr X X FCS_COP.1/AK.PDF.Sign X X X FCS_COP.1/AK.SigVer.ECD SA X FCS_COP.1/AK.SigVer.PSS X X X FCS_COP.1/AK.SigVer.SSA X X X FCS_COP.1/AK.SHA X X X X X FCS_COP.1/AK.XML.Ent X X FCS_COP.1/AK.XML.Sign X X FCS_COP.1/AK.XML.SigPr X X FCS_COP.1/AK.XML.Ver X X FDP_ACC.1/AK.eHKT X Security Target secunet konnektor 2.1.0 secunet Seite 329 von 424 Funktionale Sicherheits- anforderung (SFR) O.AK.Basis_Krypto O.AK.Admin O.AK.IFD-Komm O.AK.Chipkartendienst O.AK.EVG_Modifikation O.AK.VAD O.AK.Enc O.AK.Dec O.AK.Sig.exklusivZugriff O.AK.Sig.SignQES O.AK.Sig.SignNonQES O.AK.Sig.Einfachsignatur O.AK.Sig.Stapelsignatur O.AK.Sig.Komfortsignatur O.AK.Sig.PrüfungZertifikat O.AK.Sig.Schlüsselinhaber O.AK.Sig.SignaturVerifizierung O.AK.Selbsttest O.AK.LAN O.AK.WAN O.AK.Protokoll O.AK.Zeit O.AK.Update O.AK.exklusivZugriff O.AK.PinManagement O.AK.Infomodell O.AK.VSDM O.AK.VZD FDP_ACC.1/AK.Enc X X FDP_ACC.1/AK.Infomod X X FDP_ACC.1/AK.KD X FDP_ACC.1/AK.PIN X X X FDP_ACC.1/AK.Sgen X X X X X X FDP_ACC.1/AK.SigPr X X X FDP_ACC.1/AK.TLS X X X X FDP_ACC.1/AK.SDS X FDP_ACC.1/AK.Update X FDP_ACC.1/AK.VSDM X FDP_ACF.1/AK.eHKT X FDP_ACF.1/AK.Enc X X FDP_ACF.1/AK.Infomod X X FDP_ACF.1/AK.KD X X FDP_ACF.1/AK.PIN X X X FDP_ACF.1/AK.Sgen X X X X X X FDP_ACF.1/AK.SigPr X X X FDP_ACF.1/AK.TLS X X X X FDP_ACF.1/AK.SDS X FDP_ACF.1/AK.Update X FDP_ACF.1/AK.VSDM X FDP_DAU.2/AK.Cert X X X X FDP_DAU.2/AK.QES X X X X FDP_DAU.2/AK.Sig X X X X FDP_ETC.2/AK.Enc X X FDP_ITC.2/AK.Enc X X FDP_ITC.2/AK.Sig X FDP_RIP.1/AK X X X X X FDP_SDI.2/AK X FDP_UCT.1/AK.TLS X FDP_UIT.1/AK.TLS X FDP_UIT.1/AK.Update X FIA_API.1/AK X X FIA_SOS.1/AK.Passwörter X X Security Target secunet konnektor 2.1.0 Seite 330 von 424 secunet Funktionale Sicherheits- anforderung (SFR) O.AK.Basis_Krypto O.AK.Admin O.AK.IFD-Komm O.AK.Chipkartendienst O.AK.EVG_Modifikation O.AK.VAD O.AK.Enc O.AK.Dec O.AK.Sig.exklusivZugriff O.AK.Sig.SignQES O.AK.Sig.SignNonQES O.AK.Sig.Einfachsignatur O.AK.Sig.Stapelsignatur O.AK.Sig.Komfortsignatur O.AK.Sig.PrüfungZertifikat O.AK.Sig.Schlüsselinhaber O.AK.Sig.SignaturVerifizierung O.AK.Selbsttest O.AK.LAN O.AK.WAN O.AK.Protokoll O.AK.Zeit O.AK.Update O.AK.exklusivZugriff O.AK.PinManagement O.AK.Infomodell O.AK.VSDM O.AK.VZD FIA_SOS.2/AK.Jobnummer X X FIA_SOS.2/AK.PairG X FIA_UAU.1/AK X X X X X X FIA_UAU.5/AK X X X X X X X X FIA_UID.1/AK X FMT_MSA.1/AK.User X FMT_MSA.1/AK.Infomod X FMT_MSA.3/AK.Infomod X FMT_MSA.1/AK.TLS X X X X X FMT_MSA.3/AK.TLS X X X X X FMT_MSA.1/AK.VSDM X FMT_MSA.3/AK.VSDM X FMT_MSA.3/AK.Sig X X FMT_MSA.4/AK X X X FMT_MOF.1/AK X FMT_MTD.1/AK.Admin X X X X FMT_MTD.1/AK.Zert X X FMT_MTD.1/AK.eHKT_Ab f X X FMT_MTD.1/AK.eHKT_Mo d X X FMT_SMF.1/AK X X X X X FMT_SMR.1/AK X X X X X FPT_FLS.1/AK X X X X FPT_STM.1/AK X FPT_TDC.1/AK X X X X X X X FPT_TEE.1/AK X X X FPT_TST.1/AK.Out-Of- Band X X FPT_TST.1/AK.Run-Time X X FTA_TAB.1/AK.Jobnummer X X FTA_TAB.1/AK.SP X X FTP_ITC.1/AK.CS X FTP_ITC.1/AK.eHKT X Security Target secunet konnektor 2.1.0 secunet Seite 331 von 424 Funktionale Sicherheits- anforderung (SFR) O.AK.Basis_Krypto O.AK.Admin O.AK.IFD-Komm O.AK.Chipkartendienst O.AK.EVG_Modifikation O.AK.VAD O.AK.Enc O.AK.Dec O.AK.Sig.exklusivZugriff O.AK.Sig.SignQES O.AK.Sig.SignNonQES O.AK.Sig.Einfachsignatur O.AK.Sig.Stapelsignatur O.AK.Sig.Komfortsignatur O.AK.Sig.PrüfungZertifikat O.AK.Sig.Schlüsselinhaber O.AK.Sig.SignaturVerifizierung O.AK.Selbsttest O.AK.LAN O.AK.WAN O.AK.Protokoll O.AK.Zeit O.AK.Update O.AK.exklusivZugriff O.AK.PinManagement O.AK.Infomodell O.AK.VSDM O.AK.VZD FTP_ITC.1/AK.FD X X FTP_ITC.1/AK.QSEE X X X FTP_ITC.1/AK.VZD X FTP_ITC.1/AK.KSR X FTP_ITC.1/AK.TSL X Tabelle 28: Abdeckung der Sicherheitsziele des EVG durch Sicherheitsanforderungen Sicherheitsanforderung an den EVG O.AK.VAUSGD (Anteil VAU) O.AK.VAUSGD (Anteil SGD) FTP_ITC.1/VAU X FCS_CKM.1/VAU X FCS_COP.1/VAU.AES X FCS_COP.1/VAU.Auth X FTP_ITC.1/SGD X FCS_COP.1/SGD.ECIES X FCS_COP.1/SGD.Auth X FDP_ITC.2/SGD X FDP_ACC.1/SGD X FDP_ACF.1/SGD X FPT_TDC.1/SGDVAU X X FCS_CKM.4/AK X X Tabelle 29: Abdeckung der Sicherheitsziele der ePA Fachanwendung durch Sicherheitsanforderungen Security Target secunet konnektor 2.1.0 Seite 332 von 424 secunet 6.5.5. Detaillierte Erklärung für die Sicherheitsziele des Netzkonnektors In diesem Abschnitt wird erklärt, warum die Kombination der individuellen funktionalen Sicherheitsanforderungen (SFR) und Anforderungen an die Vertrauenswürdigkeit (SAR) für den EVG gemeinsam die formulierten Sicherheitsziele erfüllen. Dazu wird in der folgenden Tabelle 30 jedes EVG-Ziel in einzelne Teilaspekte zerlegt, die dann auf Sicherheitsanforderungen abgebildet werden.561 Um die Abbildung zu erklären (im Sinne des von Common Criteria geforderten Erklärungsteils / Rationale), wird in der Tabelle zu jeder solchen Abbildung eines Aspekts in der folgenden Zeile eine Begründung gegeben. Die Begründung zitiert, wo dies möglich ist, Sätze aus dem entsprechenden EVG-Ziel. Solche Zitate sind durch Anführungszeichen und Kursivschrift gekennzeichnet. Grundsätzlich gilt, dass die korrekte Umsetzung eines Ziel in Sicherheitsanforderungen durch die im CC Teil 2 [5] aufgeführten Abhängigkeiten zwischen funktionalen Sicherheits- anforderungen (SFRs) unterstützt wird: Häufig lässt sich leicht ein SFR finden, welches wesentliche Aspekte des EVG-Ziels umsetzt. Betrachtet man alle Abhängigkeiten, so ergibt sich eine vollständige Abdeckung des EVG-Ziels. In der folgenden Tabelle werden daher abhängige SFRs ebenfalls mit aufgelistet. Dabei wird davon ausgegangen, dass die Abhängigkeit selbst nicht gesondert erläutert werden muss. EVG-Ziel Aspekt des Ziels SFR, SAR (vgl. Abschnitt 6.2 oder 6.4) O.NK.TLS_Krypto TLS-Kanäle FTP_ITC.1/NK.TLS FMT_MOF.1/NK.TLS FMT_SMR.1./NK FMT_SMF.1/NK FPT_TDC.1/NK.TLS.Zert Begründung: In O.NK.TLS_Krypto wird gefordert: „Der EVG stellt TLS-Kanäle zur sicheren Kommunikation mit anderen IT-Produkten zur Verfügung“ Genau dies leistet FTP_ITC.1/NK.TLS. Mit FMT_MOF.1/NK.TLS wird der Rolle Anwendungskonnektor die Möglichkeit gegeben die TLS-Verbindungen zu Managen und je nach Anwendungsfall einzurichten. FMT_SMF.1/NK definiert diese Funktionalität und FMT_SMR.1./NK definiert diese Rolle (Anwendungskonnektor). Zertifikate die im Rahmen von TLS- Verbindungen zum Einsatz kommen werden nach den Vorgaben in FPT_TDC.1/NK.TLS.Zert interpretiert. Kommunikation mit anderen IT- Produkten FCS_CKM.1/NK.Zert FCS_CKM.4/NK FDP_ITC.2/NK.TLS 561 Hinweis: Common Criteria fordert nur eine Abbildung der EVG-Ziele auf funktionale Sicherheitsanforderungen (SFRs). Es zeigte sich aber, dass auch Anforderungen an die Vertrauenswürdigkeit (SARs) bzw. deren Verfeinerungen einen Beitrag zum Erreichen der Sicherheitsziele leisten Security Target secunet konnektor 2.1.0 secunet Seite 333 von 424 EVG-Ziel Aspekt des Ziels SFR, SAR (vgl. Abschnitt 6.2 oder 6.4) Gültigkeitsprüfung von Zertifikaten FTP_TRP.1/NK.Admin FDP_ETC.2/NK.TLS FPT_TDC.1/NK.TLS.Zert Begründung: Für die Einrichtung einer sicheren TLS-Verbindung zwischen Konnektor und Clientsystemen ermöglicht der EVG das exportieren von X.509 Zertifikate für Clientsysteme und die zugehörigen privaten Schlüssel durch den Administrator über die Management-Schnittstelle (FDP_ETC.2/NK.TLS). Entsprechende Zertifikate können vom EVG durch die in FCS_CKM.1/NK.Zert geforderten Mechanismen erzeugt werden, FCS_CKM.4/NK unterstützt als abhängige Komponente. Zertifikate für Clientsysteme können auch vom EVG gemäß FDP_ITC.2/NK.TLS über die gesicherte Management-Schnittstelle durch den Administrator importiert werden (FTP_TRP.1/NK.Admin), um ggf. benötigte Betriebszustände wiederherzustellen. Die importierten Zertifikate werden nach den Vorgaben in FPT_TDC.1/NK.TLS.Zert interpretiert. Dabei wird auch eine Gültigkeitsprüfung der Zertifikate durchgeführt. sichere kryptographische Algorithmen und Protokolle FCS_CKM.1/NK.TLS FCS_COP.1/NK.TLS.HMAC FCS_COP.1/NK.TLS.AES FCS_COP.1/NK.TLS.Auth FCS_CKM.4/NK Begründung: Für die TLS-Kanäle sind nach O.NK.TLS_Krypto nur „sichere kryptographische Algorithmen und Protokolle gemäß [19] mit den Einschränkungen der gematik Spezifikation für Kryptoalgorithmen [30]“ zugelassen. FCS_COP.1/NK.TLS.Auth die unterstützt die Authentisierung im Rahmen des TLS-Verbindungsaufbaus, indem der dazu zu verwendende Algorithmus spezifiziert wird. FCS_COP.1/NK.TLS.HMAC spezifiziert die HMAC Algorithmen, die im Rahmen des TLS-Verbindungsaufbaus zum Einsatz kommen. Nach erfolgreichem Verbindungsaufbau wird die Kommunikation mit AES gemäß FCS_COP.1/NK.TLS.AES abgesichert. FCS_CKM.1/NK.TLS fordert, dass entsprechendes Schlüsselmaterial generiert wird, FCS_CKM.4/NK unterstützt als abhängige Komponente. O.NK.Schutz Speicheraufbereitung: temporäre Kopien nicht mehr benötigter Geheimnisse werden unmittelbar nach Gebrauch aktiv überschrieben FDP_RIP.1/NK Security Target secunet konnektor 2.1.0 Seite 334 von 424 secunet EVG-Ziel Aspekt des Ziels SFR, SAR (vgl. Abschnitt 6.2 oder 6.4) Begründung: In O.NK.Schutz wird gefordert: „Der EVG löscht temporäre Kopien nicht mehr benötigter Geheimnisse (z. B. Schlüssel) vollständig durch aktives Überschreiben. Das Überschreiben erfolgt unmittelbar zu dem Zeitpunkt, an dem die Geheimnisse nicht mehr benötigt werden.“ Genau dies leistet FDP_RIP.1/NK. Auch die Zuweisung „upon the deallocation of the resource from“ passt zur Forderung in O.NK.Schutz. Die „Geheimnisse (z. B. Schlüssel)“ werden im SFR durch die Zuweisung präzisiert. Selbsttests, Schutz gegen sicherheitstechnische Veränderungen FPT_TST.1/NK Begründung: „Der EVG schützt sich selbst und die ihm anvertrauten Benutzerdaten:“  ist als Erläuterung für die Begriffsbildung O.NK.Schutzund als Oberbegriff für die weiteren Teilaspekte zu verstehen. „Der EVG schützt sich selbst gegen sicherheitstechnische Veränderungen an den äußeren logischen Schnittstellen bzw. erkennt diese oder macht diese erkennbar. Der EVG erkennt bereits Versuche, sicherheitstechnische Veränderungen durchzuführen, sofern diese über die äußeren Schnittstellen des EVGs erfolgen (mit den unter OE.NK.phys_Schutz formulierten Einschränkungen). Der EVG führt beim Start-up und bei Bedarf Selbsttests durch.“  Das Erkennen bzw. Erkennbarmachen sicherheitstechnischer Veränderungen erfolgt durch den von FPT_TST.1/NK geforderten Selbsttest. Im Rahmen der Integritätsprüfungen werden Hashwerte wie von FCS_COP.1/NK.Hash gefordert verwendet. Dieses SFR hat die formalen Abhängigkeiten FCS_CKM.4/NK und FCS_CKM.1/NK, wobei FCS_CKM.4/NK nicht erfüllt werden muss, sofern im Rahmen der Hashwertberechnung keine geheimen Schlüssel verwendet werden. FCS_CKM.1/NK fordert, dass das Schlüsselmaterial (z. B. Integritätsprüfschlüssel) generiert wird. Anmerkung: Alternativ könnte ein Hersteller diese Schlüssel auch importieren; dazu wäre dann zusätzlich FDP_ITC.1 oder FDP_ITC.2 aufzunehmen. Schutz gegen unbefugte Kenntnis- nahme (Side Channel-Analysen) FPT_EMS.1/NK Begründung: „Der EVG schützt sich selbst und die ihm anvertrauten Benutzerdaten.“ Um den Aspekt „die ihm anvertrauten Benutzerdaten“ vollständig abzudecken, wurde die explizite Komponente FPT_EMS.1/NK Security Target secunet konnektor 2.1.0 secunet Seite 335 von 424 EVG-Ziel Aspekt des Ziels SFR, SAR (vgl. Abschnitt 6.2 oder 6.4) ergänzt. Dieses SFR fordert genau die Analyse, ob andere Möglichkeiten zur unbefugten Kenntnisnahme bestehen. O.NK.Stateful dynamischer Paketfilter implementiert zustandsgesteuerte Filterung (stateful packet inspection) FDP_IFC.1/NK.PF  FDP_IFF.1/NK.PF Begründung: „Der EVG implementiert zustandsgesteuerte Filterung (stateful packet inspection) mindestens für den WAN-seitigen dynamischen Paketfilter.“ Diese Paketfilterung wurde als Informationsflusskontrolle modelliert (FDP_IFC.1/NK.PF, FDP_IFF.1/NK.PF). Die zustandsgesteuerte Filterung wurde in den Operationen und im Refinement zu FDP_IFF.1/NK.PF modelliert. O.NK.EVG_Authent icity Auslieferungsverfahren: Nur authentische EVGs können in Umlauf gebracht werden FCS_COP.1/NK.Auth FCS_CKM.1/NK FCS_CKM.4/NK Begründung: „Das Auslieferungsverfahren und die Verfahren zur Inbetriebnahme des EVGs stellen sicher, dass nur authentische EVGs in Umlauf gebracht werden können. Gefälschte EVGs müssen vom VPN-Konzentrator sicher erkannt werden können. Der EVG muss auf Anforderung mit Unterstützung der SM NK einen Nachweis seiner Authentizität ermöglichen.“  Die Authentisierung wird mit Kryptoalgorithmen erbracht, die durch FCS_COP.1/NK.Auth spezifiziert werden. FCS_CKM.1/NK fordert eine Generierung des für den Nachweis der Authentizität des EVGs erforderlichen Schlüsselmaterials; FCS_CKM.4/NK unterstützt als abhängige Komponenten dabei. O.NK.Admin_EVG rollenbasierte Zugriffskontrolle für administrative Funktionen, Liste dieser administrativen Funktionen Identifikation / Autorisierung des Administrators sicherer Pfad Beschränkung der Administration der Firewall-Regeln FMT_MTD.1/NK FMT_SMR.1./NK FMT_SMF.1/NK FIA_UID.1/NK.SMR FIA_UAU.1/NK.SMR FTP_TRP.1/NK.Admin FMT_MSA.1/NK.PF Begründung: „Der EVG setzt eine Zugriffskontrolle für administrative Funktionen um: Nur Administratoren dürfen administrative Funktionen ausführen.“  FMT_MTD.1/NK beschränkt den Zugriff wie vom Ziel gefordert auf die Rolle Administrator. FMT_SMR.1./NK modelliert als abhängige Security Target secunet konnektor 2.1.0 Seite 336 von 424 secunet EVG-Ziel Aspekt des Ziels SFR, SAR (vgl. Abschnitt 6.2 oder 6.4) Komponente diese Rolle (Administrator). FIA_UID.1/NK.SMR erfordert eine Identifikation des Benutzers vor jeglichem Zugriff auf administrative Funktionalität. Die Menge der administrativen Funktionen wird in FMT_SMF.1/NK aufgelistet. „Dazu ermöglicht der EVG die sichere Identifikation und Autorisierung eines Administrators, welcher die lokale und entfernte Administration des EVG durchführen kann.“  Die Authentisierung des Administrators erfolgt durch den EVG. Die dabei anzuwendenden Regeln wurden in FIA_UAU.1/NK.SMR modelliert. „Die Administration erfolgt rollenbasiert.“  FMT_SMR.1./NK modelliert die Rolle Administrator. „Weil die Administration über Netzverbindungen (lokal über PS2 oder zentral über PS3) erfolgt, sind die Vertraulichkeit und Integrität des für die Administration verwendeten Kanals sowie die Authentizität seiner Endstellen zu sichern (Administration über einen sicheren logischen Kanal).“  FTP_TRP.1/NK.Admin fordert genau diesen sicheren logischen Kanal zum Benutzer (trusted path). „Der EVG verhindert die Administration folgender Firewall-Regeln: …“  Dieser Aspekt wird durch das Refinement zu FMT_MSA.1/NK.PF abgebildet. Schließlich unterstützt die Benutzerdokumentation (AGD_OPE.1) bei der Administration der Paketfilter-Regeln. O.NK.Protokoll EVG protokolliert sicherheitsrelevante Ereignisse mit Daten und Zeitstempel FAU_GEN.1/NK.SecLog FAU_GEN.2/NK.SecLog FPT_STM.1/NK Begründung: „Der EVG protokolliert sicherheitsrelevante Ereignisse und stellt die erforderlichen Daten bereit.“  FAU_GEN.1/NK.SecLog fordert eine Protokollierung für die in der Operation explizit aufgelisteten Ereignisse und stellt Anforderungen an den Inhalt der einzelnen Log-Einträge. FAU_GEN.2/NK.SecLog fordert, dass die Benutzeridentitäten mit protokolliert werden. FPT_STM.1/NK stellt den Zeitstempel bereit. O.NK.Zeitdienst regelmäßige Zeitsynchronisation FPT_STM.1/NK Begründung: „Der EVG synchronisiert die Echtzeituhr gemäß OE.NK.Echtzeituhr in regelmäßigen Abständen über einen sicheren Kanal mit einem vertrauenswürdigen Zeitdienst (siehe OE.NK.Zeitsynchro).“  (Refinement zu) FPT_STM.1/NK: Synchronisation mindestens einmal innerhalb von 24 Stunden; Information, falls die Synchronisierung nicht erfolgreich durchgeführt werden konnte Security Target secunet konnektor 2.1.0 secunet Seite 337 von 424 EVG-Ziel Aspekt des Ziels SFR, SAR (vgl. Abschnitt 6.2 oder 6.4) O.NK.Update Software Update FDP_ACC.1/NK.Update FDP_ACC.1/NK.Update FDP_ITC.1/NK.Update FDP_UIT.1/NK.Update Begründung: Das Sicherheitsziel O.NK.Update „Software Update“ fordert vom EVG die Aktualisierung von Software-Komponenten sowie deren Prüfung auf Integrität. FDP_ACC.1/NK.Update führt die Update-SFP für den Software-Update ein und FDP_ACC.1/NK.Update definiert die Regeln für den Umgang mit dem Software-Update beim Import. Die Anforderung FDP_ITC.1/NK.Update fordert die Fähigkeit des EVG zum Import der Software-Komponenten von ausserhalb des EVG und FDP_UIT.1/NK.Update fordert die Prüfung der Integrität dieser Daten vor dem Update. O.NK.Admin_Auth Authentisierung des Administrators FTP_TRP.1/NK.Admin FIA_UAU.1/NK.SMR FTP_ITC.1/NK.TLS Begründung: FTP_TRP.1/NK.Admin fordert einen sicheren Kommunikationskanal zwischen EVG und Administrator. FTP_ITC.1/NK.TLS fordert dazu einen TLS-Kanal für lokale und entfernte Administrierung. Erst nach erfolgreicher Authentisierung können adminstrative Funktionen aufgerufen werden (FIA_UAU.1/NK.SMR). O.NK.VPN_Auth gegenseitige Authentisierung mit VPN-Konzentrator (Telematikinfrastruktur-Netz) FTP_ITC.1/NK.VPN_TI FTP_ITC.1/NK.VPN_SIS FCS_COP.1/NK.Auth  FCS_CKM.1/NK  FCS_CKM.2/NK.IKE  FCS_CKM.4/NK Begründung: FCS_COP.1/NK.Auth setzt direkt die Anforderung nach einer Authentisierung des EVGs gegenüber dem VPN-Konzentrator um, indem es die dazu zu verwendenden Algorithmen spezifiziert. FTP_ITC.1/NK.VPN_TI und FTP_ITC.1/NK.VPN_SIS fordern die sicheren Kanäle mit gegenseitiger Authentifizierung („ … provides assured identification of its end points …“) zu den VPN- Konzentratoren in die Telematikinfrastruktur bzw. ins Internet. FTP_ITC.1/NK.VPN_TI, FTP_ITC.1/NK.VPN_SIS (IPsec) und FCS_CKM.2/NK.IKE (IKE) legen fest, welche Protokolle im Rahmen des Kanalaufbaus verwendet werden sollen. Zwar geht es in Security Target secunet konnektor 2.1.0 Seite 338 von 424 secunet EVG-Ziel Aspekt des Ziels SFR, SAR (vgl. Abschnitt 6.2 oder 6.4) FCS_CKM.2/NK.IKE vorrangig um die Schlüsselableitung, diese ist aber mit der Authentisierung kombiniert. FCS_CKM.1/NK fordert, dass entsprechendes Schlüsselmaterial für die Authentisierung generiert wird (evtl. unter Rückgriff auf eine gSMC-K, welches in den EVG eingebracht wird). FCS_CKM.4/NK unterstützt als abhängige Komponente. O.NK.Zert_Prüf Gültigkeitsprüfung von Zertifikaten mit Hilfe von TSL und der CRL FPT_TDC.1/NK.Zert Begründung: Zertifikatsprüfung: „Der EVG führt im Rahmen der Authentisierung eines VPN-Konzentrators eine Gültigkeitsprüfung der Zertifikate, die zum Aufbau des VPN-Tunnels verwendet werden, durch. Die zur Prüfung der Zertifikate erforderlichen Informationen werden dem Konnektor in Form einer zugehörigen CRL und einer TSL bereitgestellt.“ FPT_TDC.1/NK.Zert fordert, dass der EVG Informationen über die Gültigkeit von Zertifikaten korrekt interpretiert. In der Zuweisung wurden TSL und CRL explizit erwähnt: „The TSF shall provide the capability to consistently interpret information – distributed in the form of a TSL (Trust-Service Status List) or CRL (Certificate Revocation List) information …“ Die Zertifikatsprüfung wird für VPN-Konzentratoren der Telematikinfrastruktur-Netzes bzw. des Sicheren Internet Service durchgeführt. FPT_TDC.1/NK.Zert fordert ferner explizit, dass der EVG Informationen „about the domain (Telematikinfrastruktur) to which the VPN concentrator with a given certificate connects” interpretiert. O.NK.VPN_Vertrau l Vertraulichkeit der Nutzdaten im VPN (Telematikinfrastruktur-Netz) IPsec-Kanal: Ableitung von session keys, AES-Verschlüsselung mit den session keys , Zerstörung der session keys nach Verwendung, Geheimhaltung der session keys FTP_ITC.1/NK.VPN_TI FTP_ITC.1/NK.VPN_SIS FCS_COP.1/NK.IPsec,  FCS_CKM.1/NK  FCS_CKM.2/NK.IKE  FCS_COP.1/NK.ESP  FCS_CKM.4/NK FPT_EMS.1/NK Begründung: „Der EVG schützt die Vertraulichkeit der Nutzdaten bei der Übertragung von und zu den VPN-Konzentratoren. Bei der Übertragung der Nutzdaten zwischen EVG und entfernten VPN- Security Target secunet konnektor 2.1.0 secunet Seite 339 von 424 EVG-Ziel Aspekt des Ziels SFR, SAR (vgl. Abschnitt 6.2 oder 6.4) Konzentratoren verschlüsselt (vor dem Versand) bzw. entschlüsselt (nach dem Empfang) der Konnektor die Nutzdaten; dies wird durch die Verwendung des IPsec-Protokolls erreicht.“  Die Verschlüsselung wird durch FTP_ITC.1/NK.VPN_TI (im Fall der Telematikinfrastruktur) bzw. FTP_ITC.1/NK.VPN_SIS (im Fall des Sicheren Internet Service) gefordert („…protection of the channel data from modification and disclosure“, man beachte das Refinement von „or“ zu „and“). FCS_COP.1/NK.IPsec ermöglicht die Definition der zu verwendenden Verschlüsselungsalgorithmen, hier AES gemäß FCS_COP.1/NK.ESP. FCS_CKM.4/NK unterstützt als abhängige Komponente ebenfalls. Für einzelne Verbindungen werden jeweils eigene session keys im Rahmen des Diffie-Hellman-Keyexchange-Protocols abgeleitet. FCS_CKM.1/NK fordert eine solche Generierung von session keys. „Während der gegenseitigen Authentisierung erfolgt die Aushandlung eines Session Keys.“  Mittels FCS_CKM.2/NK.IKE (IKE) werden die abgeleiteten Sitzungsschlüssel, die für die Verschlüsselung verwendet werden, mit der die Vertraulichkeit der Nutzdaten sichergestellt wird, mit der Gegenstelle ausgetauscht. Die Nutzdaten werden mit AES gemäß FCS_COP.1/NK.ESP verschlüsselt. FPT_EMS.1/NK sorgt dafür, dass die session keys, welche im Rahmen der gegenseitigen Authentisierung abgeleitet werden, auch von Angreifern mit hohem Angriffspotential nicht in Erfahrung gebracht werden können. Diese session keys sichern die Vertraulichkeit der nachfolgenden Kommunikation. O.NK.VPN_Integrit ät Integrität der Nutzdaten im VPN, (Telematikinfrastruktur-Netz) Ableitung von session keys, Austausch der session keys mit Gegenstelle, Zerstörung der session keys nach Verwendung Integritätssicherung bei IKE und IPsec Ableitung von session keys, Zerstörung der session keys nach Verwendung Geheimhaltung der session keys FTP_ITC.1/NK.VPN_TI FTP_ITC.1/NK.VPN_SIS FCS_COP.1/NK.Hash  FCS_CKM.1/NK  FCS_CKM.2/NK.IKE  FCS_CKM.4/NK FCS_COP.1/NK.HMAC  FCS_CKM.1/NK  FCS_CKM.4/NK FPT_EMS.1/NK Begründung: „Der EVG schützt die Integrität der Nutzdaten bei der Übertragung von und zu den VPN-Konzentratoren. Bei der Übertragung der Security Target secunet konnektor 2.1.0 Seite 340 von 424 secunet EVG-Ziel Aspekt des Ziels SFR, SAR (vgl. Abschnitt 6.2 oder 6.4) Nutzdaten zwischen EVG und entfernten VPN-Konzentratoren sichert (vor dem Versand) bzw. prüft (nach dem Empfang) der Konnektor die Integrität der Nutzdaten; dies wird durch die Verwendung des IPsec- Protokolls erreicht.“  Die Integritätssicherung wird durch FTP_ITC.1/NK.VPN_TI und FTP_ITC.1/NK.VPN_SIS gefordert („…protection of the channel data from modification and disclosure“, man beachte das Refinement von „or“ zu „and“). FCS_COP.1/NK.Hash spezifiziert die Hashalgorithmen, die im Rahmen der Integritätssicherung zum Einsatz kommen. Hier ist anzumerken, dass der Schutz der Integrität im Rahmen von IPsec durch das Protokoll IP Encapsulating Security Payload (ESP) (RFC 4303 (ESP), [59]) erfolgt. erfolgt, wobei die Authentizitätsdaten (authentication data) den Wert des Integritätstests (integrity check value) enthalten, der sich wiederum aus einem Hash über den ESP Header und den verschlüsselten Nutzdaten des Paketes ergibt. Insofern ist eine Hashfunktion erforderlich. Weiterhin ist im IPSec sowie in IKE Standard die Verwendung von HMAC Algorithmen enthalten ([62], [63], [60]). Dies wird durch FCS_COP.1/NK.HMAC erreicht. Für einzelne Verbindungen werden jeweils eigene session keys im Rahmen des Diffie-Hellman-Keyexchange-Protocols abgeleitet (FCS_CKM.1/NK) und mit der Gegenstelle ausgetauscht (FCS_CKM.2/NK.IKE). FCS_CKM.4/NK unterstützt als abhängige Komponente. FPT_EMS.1/NK sorgt dafür, dass die session keys, welche im Rahmen der gegenseitigen Authentisierung abgeleitet werden, auch von Angreifern mit hohem Angriffspotential nicht in Erfahrung gebracht werden können. Diese session keys sichern die Vertraulichkeit der nachfolgenden Kommunikation. O.NK.PF_WAN dynamischer Paketfilter zum WAN FDP_IFC.1/NK.PF, FDP_IFF.1/NK.PF, FMT_MSA.3/NK.PF, FMT_MSA.1/NK.PF, FMT_SMR.1./NK FMT_SMF.1/NK AVA_VAN.5 (hohes Angriffspotential) Begründung: „Der EVG schützt sich selbst, andere Konnektorteile und die Clientsysteme vor Missbrauch und Manipulation aus dem Transportnetz (dynamische Paketfilter-Funktionalität, Schutz vor Angriffen aus dem WAN).“  Der Schutz wurde als Informationsflusskontrolle modelliert (FDP_IFC.1/NK.PF): „The TSF Security Target secunet konnektor 2.1.0 secunet Seite 341 von 424 EVG-Ziel Aspekt des Ziels SFR, SAR (vgl. Abschnitt 6.2 oder 6.4) shall enforce the packet filtering SFP (PF SFP) on the subjects VPN concentrator and attacker communicating with the TOE from its WAN interface (PS3) …“ FDP_IFF.1/NK.PF modelliert einen Paketfilter („…the decision shall be based on the following security attributes: IP address, port number, and protocol type.“, „For every operation (…) the TOE shall maintain a set of packet filtering rules …“). Der dynamische Aspekt wird durch FDP_IFF.1.4/NK.PF (Stateful Packet Inspection) abgebildet und durch ein Refinement präzisiert. Der Paketfilter ist als Sicherheitsfunktion nur dann wirksam, wenn er auf Basis geeigneter Filterregeln arbeitet. Dem tragen die folgenden Komponenten FMT_MSA.3/NK.PF und FMT_MSA.1/NK.PF (für die Paketfilterregeln im Allgemeinen). Rechnung: FMT_MSA.3/NK.PF trägt als von FDP_IFF.1/NK.PF abhängige Komponente zur Sicherheit bei, indem sie restriktive Voreinstellungen für die Filterregeln fordert. FMT_MSA.1/NK.PF beschränkt die Möglichkeiten zur Administration der Filterregeln auf gewisse Rollen (z. B Administrator) und verhindert so unbefugte Veränderungen an den sicherheitsrelevanten Filterregeln. FMT_SMR.1./NK wiederum listet alle Rollen auf, die der EVG kennt, und fordert so die Modellierung der Rollen durch EVG. FMT_SMF.1/NK (als von FMT_MSA.1/NK.PF abhängige Komponente) listet alle administrativen Funktionen auf. O.NK.PF_LAN dynamischer Paketfilter zum LAN, regelbasierte Informationsflusskontrolle FDP_IFC.1/NK.PF, FDP_IFF.1/NK.PF, FMT_MSA.3/NK.PF, FMT_MSA.1/NK.PF, FMT_SMR.1./NK FMT_SMF.1/NK FDP_IFF.1/NK.PF Begründung: „Der EVG schützt sich selbst und den Anwendungskonnektor vor Missbrauch und Manipulation aus möglicherweise kompromittierten lokalen Netzen der Leistungserbringer (dynamische Paketfilter- Funktionalität, Schutz vor Angriffen aus dem LAN).“  Der Schutz wurde als Informationsflusskontrolle modelliert (FDP_IFC.1/NK.PF): „The TSF shall enforce the packet filtering SFP (PF SFP) on the subjects … and the subjects application connector and workstation (German: Clientsystem) communicating with the TOE from its LAN interface (PS2) …“ FDP_IFF.1/NK.PF modelliert einen Paketfilter („…the decision shall be based on the following security attributes: IP address, port Security Target secunet konnektor 2.1.0 Seite 342 von 424 secunet EVG-Ziel Aspekt des Ziels SFR, SAR (vgl. Abschnitt 6.2 oder 6.4) number, and protocol type.“, „For every operation (…) the TOE shall maintain a set of packet filtering rules …“). Der dynamische Aspekt wird durch FDP_IFF.1.4/NK.PF (Stateful Packet Inspection) abgebildet und durch das folgende Refinement präzisiert. Der Paketfilter ist als Sicherheitsfunktion nur dann wirksam, wenn er auf Basis geeigneter Filterregeln arbeitet. Dem tragen die folgenden Komponenten FMT_MSA.3/NK.PF und FMT_MSA.1/NK.PF Rechnung: FMT_MSA.3/NK.PF trägt als von FDP_IFF.1/NK.PF abhängige Komponente zur Sicherheit bei, indem sie restriktive Voreinstellungen für die Filterregeln fordert. FMT_MSA.1/NK.PF beschränkt die Möglichkeiten zur Administration der Filterregeln auf gewisse Rollen. FMT_SMR.1./NK wiederum listet alle Rollen auf, die der EVG kennt, und fordert so die Modellierung der Rollen durch EVG. FMT_SMF.1/NK (als von FMT_MSA.1/NK.PF abhängige Komponente) listet alle administrativen Funktionen auf. „Für zu schützende Daten der TI und der Bestandsnetze sowie zu schützende Nutzerdaten bei Internet-Zugriff über den SIS erzwingt der EVG die Nutzung eines VPN-Tunnels. Ungeschützter Zugriff von IT- Systemen aus dem LAN (z. B. von Clientsystemen) auf das Transportnetz wird durch den EVG unterbunden: IT-Systeme im LAN können nur unter der Kontrolle des EVG und im Einklang mit der Sicherheitspolitik des EVG zugreifen.“  Dies wurde teilweise durch FDP_IFF.1.3/NK.PF modelliert (zwangsweise Nutzung des VPN-Tunnels). Ferner ist die Sicherheitsleistung des Paketfilters natürlich abhängig von den verwendeten Paketfilterregeln. Daher beschränkt der EVG die Administration gewisser grundlegender Paketfilterregeln; siehe dazu das Refinement zu FMT_MSA.1/NK.PF. Für die Paketfilterregeln, die der Administrator administrieren darf, informiert ihn die Benutzerdokumentation hinreichend; siehe dazu das Refinement zu AGD_OPE.1 (Administration der Paketfilter-Regeln) in Abschnitt 6.2.8. Tabelle 30: Abbildung der EVG-Ziele auf Anforderungen Anwendungshinweis 205: Hinweis zu O.NK.VPN_Integrität: Zur Erfüllung der Anforderungen aus FCS_COP.1/NK.Hash wird eine Hashfunktion verwendet, die nicht auf einem symmetrischen Verschlüsselungsalgorithmus beruht, es sind daher keine entsprechenden geheimzuhaltenden Schlüssel erforderlich. 6.5.6. Detaillierte Erklärung für die Sicherheitsziele des Anwendungskonnektors O.AK.Basis_Krypto Das Sicherheitsziel O.AK.Basis_Krypto “Kryptographische Algorithmen“ fordert die Verwendung von sicheren kryptographischen Algorithmen und Protokollen im gesamten EVG, Security Target secunet konnektor 2.1.0 secunet Seite 343 von 424 die den normativen Anforderungen gemäß [12] für Signaturen und [19] bzw. [30] für Kryptoalgorithmen entsprechen. Dies ist in den folgenden SFRs umgesetzt: - FCS_CKM.1/AK.AES fordert die kryptographische Schlüsselgenerierung von 128 und 256 Bit Schlüsseln gemäß [19]. - FCS_CKM.1/NK.TLS fordert die kryptographische Schlüsselgenerierung von 128 und 256 Bit Schlüsseln gemäß [30]. - FCS_CKM.4/AK fordert die Zerstörung von kryptographischen Schlüsseln. - FCS_COP.1/AK.AES fordert die Verwendung von AES -256 zur symmetrischen Verschlüsselung und die Verwendung von AES-128 , AES-192 und AES-256 zur symmetrischen Entschlüsselung. - FCS_COP.1/AK.CMS.Ent fordert die symmetrische Entschlüsselung von Dokumenten mit AES-256. - FCS_COP.1/AK.CMS.SigPr fordert die Verwendung der Algorithmen CAdES, SHA-2 und RSA zur Verwendung bei der Prüfung signierter CMS-Dokumente. - FCS_COP.1/AK.CMS.Sign fordert die Verwendung der Algorithmen CAdES und SHA-2 zur Verwendung bei der Erzeugung elektronischer Signaturen von Dokumenten. - FCS_COP.1/AK.CMS.Ver fordert die Verwendung der Algorithmen AES-256 sowie RSA zur hybriden Verschlüsselung von Dokumenten. - FCS_COP.1/NK.TLS.HMAC fordert die Verwendung des HMAC Verfahrens mit SHA-1 zum Berechnen und Prüfen von HMACs. - FCS_COP.1/AK.PDF.SigPr und FCS_COP.1/AK.PDF.Sign fordern die Verwendung der Algorithmen PAdES, SHA-2 und RSA zur Prüfung und Erzeugung von signierten PDF-A Dokumenten. - FCS_COP.1/AK.SigVer.PSS und FCS_COP.1/AK.SigVer.SSA fordern die Verwendung des Algorithmus RSA zur Prüfung digitaler Signaturen. - FCS_COP.1/AK.SHA fordert die Verwendung des Algorithmus SHA-2 zur Berechnung von Hash-Werten. - FCS_COP.1/NK.TLS.HMAC, FCS_COP.1/NK.TLS.AES und FCS_COP.1/NK.TLS.Auth fordern die Verwendung der Algorithmen ECC, RSA, AES und SHA für die Absicherung der TLS-Kanäle. - FCS_COP.1/AK.XML.Ent fordert die Verwendung der Algorithmen AES-256 zur symmetrischen Entschlüsselung von XML-Dokumenten. - FCS_COP.1/AK.XML.Sign fordert die Verwendung der Algorithmen XAdES sowie SHA-2 im Zusammenwirken mit Signatur-Chipkarten zur Erzeugung von XML- Signaturen. - FCS_COP.1/AK.XML.SigPr fordert die Verwendung der Algorithmen XAdES sowie SHA-2 und RSA zur Prüfung von XML-Signaturen. - FCS_COP.1/AK.XML.Ver fordert die Verwendung der Algorithmen AES-256 sowie RSA für die hybride Verschlüsselung von XML-Dokumenten. Security Target secunet konnektor 2.1.0 Seite 344 von 424 secunet O.AK.Admin Das Sicherheitsziel O.AK.Admin „Administration“ fordert die Einschränkung administrativer Funktionen auf besonders berechtigte Administratoren, insbesondere für das Management der eHealth-Kartenterminals und der Arbeitsplätze. Dies ist durch folgende SFR umgesetzt: - FMT_SMR.1/AK listet die bekannten Rollen, darunter die Administrator-Rolle. - FMT_SMF.1/AK listet die administrativen Funktionen, die alle in O.Admin gelisteten Bereiche erfassen. - FMT_MOF.1/AK begrenzt die Aktivierung und Deaktivierung der Online Kommunikation, des Signaturdienstes und der Logischen Separation auf den Administrator. - FIA_UAU.1/AK verbietet die Ausführung administrativer Funktionen vor erfolgreicher Authentisierung. - FIA_UAU.5/AK fordert einen Passwort-Authentisierungsmechanismus für Administratoren. - FDP_ACC.1/AK.SDS beschreibt die Zugriffskontrolle auf den sicheren Datenspeicher. Dabei bildet der Administrator ein Subjekt, das auf Daten oder Schlüssel dieses Datenspeichers zugreift. - FDP_ACF.1/AK.SDS definiert die Zugriffskontrolle für den sicheren Datenspeicher. - FIA_SOS.1/AK.Passwörter setzt eine Qualitätsmetrik für die Passwörter der Administratoren durch. - FMT_MSA.1/AK.TLS beschreibt die Einschränkungen beim Verwalten von Sicherheitsattribute für TLS Kanälen. FMT_MSA.3/AK.TLS beschreibt den Umgang mit Standardwerten für Sicherheitsattribute von TLS-Kanälen. - FMT_MTD.1/AK.Zert beschreibt und begrenzt die administrativen Funktionen für das CVC-Management auf den berechtigte Benutzer. - FMT_MTD.1/AK.eHKT_Abf beschreibt und begrenzt die administrativen Funktionen für die Abfrage der Konfigurationsdaten der eHealth-Kartenterminals auf den S_AK und Administrator. - FMT_MTD.1/AK.eHKT_Mod beschreibt und begrenzt die administrativen Funktionen für die Modifikation der Konfigurationsdaten der eHealth-Kartenterminals auf den Administrator. - FMT_MTD.1/AK.Admin beschreibt und begrenzt die administrativen Funktionen für die Modifikation von Rollen, Konfigurationsdaten, zu protokollierende Ereignisse und Standardvorgaben für Signaturvorgänge sowie für das Modifizieren von EVG-Software und den Export und Import von Konfigurationsdaten auf den Administrator. - FAU_GEN.1/AK erzeugt Protokolldaten über die Verschlüsselung von Dateien nach Verschlüsselungsrichtlinie, - FAU_SAR.1/AK ermöglicht autorisierten Benutzern die Protokollaufzeichnungen in geeigneter Weise zu lesen. - FAU_STG.1/AK schützt die Protokollaufzeichnungen gegen nichtautorisiertes Löschen und Modifizieren. - FAU_STG.4/AK überschreibt die ältesten Protokolleinträge, wenn der Protokollspeicher voll ist. Security Target secunet konnektor 2.1.0 secunet Seite 345 von 424 O.AK.EVG_Modifikation Das Sicherheitsziel O.AK.EVG_Modifikation „Schutz vor Veränderungen“ fordert vom EVG dem Nutzer zur Laufzeit sicherheitstechnische Veränderungen anzuzeigen und dauerhaft gespeicherte geheime kryptographische Schlüssel vor Kompromittierung durch physische und logische Angriffe zu schützen. Dies ist durch folgende SFR umgesetzt: - FIA_UID.1/AK erlaubt den Selbsttest gemäß FPT_TST.1/Out-Of-Band vor der Identifizierung eines Benutzers. - FPT_TST.1/AK.Out-Of-Band fordert, dass die TSF auf Anforderung eines autorisierten Benutzers eine Testfolge als Nachweis für den korrekten Betrieb der TSF durchführen muss. - FPT_TST.1/AK.Run-Time fordert, dass die TSF auf regelmäßig während des Normalbetriebs eine Testfolge als Nachweis für den korrekten Betrieb der TSF durchführen muss. - FPT_FLS.1/AK fordert den Übergang in einen sicheren Zustand, wenn Fehler erkannt wurden. - FDP_RIP.1/AK fordert, dass die TSF sicherstellen muss, dass der frühere Informationsinhalt einer Ressource mit geheimen kryptographischen Schlüsseln bei Wiederfreigabe einer Ressource nicht verfügbar ist. O.AK.IFD-Komm Das Sicherheitsziel O.AK.IFD-Komm “Schutz der Kommunikation mit den eHealth- Kartenterminals“ fordert von dem EVG, die eHealth-Kartenterminals, mit denen er gepaart ist, zu authentisieren und die Vertraulichkeit und Integrität seiner Kommunikation mit den eHealth- Kartenterminals durch einen entsprechend gesicherten Kanal zu schützen. Der EVG verwendet selbst nur sichere kryptographische Algorithmen gemäß [19] für die TLS-Kanäle. Dieser Teil des Sicherheitsziels ist durch folgende SFR umgesetzt: - FTP_ITC.1/AK.eHKT fordert die Einrichtung eines vertrauenswürdigen Kanals zwischen dem EVG und der sichere Signaturerstellungseinheit, der gemäß FDP_UCT.1/AK.TLS die Vertraulichkeit und gemäß FDP_UIT.1/AK.TLS die Integrität des Datenaustausches zu gewährleisten hat. - FCS_CKM.1/NK.TLS fordert die Generierung kryptographischer Schlüssel nach Normen für TLS-Kanäle, insbesondere die Schlüsselgenerierung von AES-Schlüsseln, für die die Einsatzumgebung die benötigten Zufallszahlen erzeugt. - Das Schlüsselmanagement muss die sichere Zerstörung der kryptographischen Schlüssel gemäß FCS_CKM.4/AK implementieren. - Die kryptographischen Operationen des TLS-Kanals müssen gemäß FCS_COP.1/NK.TLS.HMAC, FCS_COP.1/NK.TLS.AES und FCS_COP.1/NK.TLS.Auth mit den dort geforderten Algorithmen erfolgen. - FPT_TEE.1/AK fordert bei der Herstellung einer Kommunikation mit einem Gerät, das vorgibt, ein eHealth-Kartenterminal zu sein, zu prüfen, ob das Gerät tatsächlich über Security Target secunet konnektor 2.1.0 Seite 346 von 424 secunet eine gesteckte gültige gSMC-KT verfügt, und das eHealth-Kartenterminal dem EVG als zulässiges Kartenterminal im LAN des Leistungserbringers bekannt ist. - Diese Prüfung bei Verbindungsaufnahme zwischen dem EVG und den eHealth- Kartenterminals schließt eine Authentisierung nach TLS-Protokoll mit Pairing- Geheimnis gemäß FIA_UAU.5/AK. Die dafür präsentierten CV-Zertifikate werden gemäß FPT_TDC.1/AK auf Gültigkeit für gSMC-KT geprüft. Das Pairing-Geheimnis wird gemäß FIA_SOS.2/AK.PairG erzeugt. - Die Ressourcen, die geheime kryptographische Schlüssel oder Benutzerdaten enthielten, die über den TLS-Kanal zwischen EVG und eHealth-Kartenterminals übermittelt wurden, müssen gemäß FDP_RIP.1/AK bei der Wiederfreigabe aufbereitet werden. - FMT_MTD.1/AK.eHKT_Abf, FMT_MTD.1/AK.eHKT_Mod und FMT_MTD.1/AK.Admin fordern die Einrichtung administrativer Funktionen zur Verwaltung der eHealth-Kartenterminals auf den Administrator zu beschränken. - Die Rolle des Administrators ist durch FMT_SMR.1/AK und die Managementfunktionen für die eHealth-Kartenterminals sind durch FMT_SMF.1/AK gefordert. O.AK.IFD-Komm Das Sicherheitsziel O.AK.IFD-Komm sieht weiterhin vor, dass der EVG einen hinsichtlich Vertraulichkeit und Integrität geschützten Kanal zum Kartenterminal bereitstellt und dessen Nutzung kontrolliert. Dieser Teil des Sicherheitsziels ist durch folgende SFR umgesetzt: - FDP_ACC.1/AK.eHKT führt die Kartenterminal SFP ein, die die Nutzung des TLS- Kanals zwischen dem EVG und den eHealth-Kartenterminals durch SICCT- Kommandos adressiert. - FDP_ACF.1/AK.eHKT fordert eine Zugriffskontrolle für die Verwendung von SICCT- Kommandos, die die Nutzung kryptographischer Schlüssel auf Dienste des EVG und Anzeigen zur QES. O.AK.Chipkartendienst Das Sicherheitsziel O.AK.Chipkartendienst “Chipkartendienste des EVG“ fordert, Chipkarten an der ICCSN und den in den Chipkarten enthaltenen Angaben zu identifizieren, Chipkarten (außer KVK) mit Hilfe der Zertifikate auf der Chipkarte zu authentisieren, und einen Sicherheitsdienst zur gegenseitigen Authentisierung zwischen Chipkarten (Card-to-Card- Authentisierung) in den angeschlossenen eHealth-Kartenterminals bereit zu stellen. - FPT_TEE.1/AK fordert bei Stecken einer Chipkarte, die vorgibt, ein HBA, eine gSMC- KT, eine SMC-B oder eine eGK zu sein, zu prüfen, ob sie tatsächlich eine solche Chipkarte ist. Die dafür präsentierten CV-Zertifikate werden gemäß FPT_TDC.1/AK auf Gültigkeit für HBA, SMC (gSMC-KT oder SMC-B) und eGK geprüft. - FIA_UAU.5/AK fordert die Unterstützung der Authentisierung von Chipkarten auf der Basis von CV-Zertifikate, deren Gültigkeit gemäß FPT_TDC.1/AK zu prüfen sind, und die Authentisierung von SMC und HBA in der jeweils benötigten Rolle. Security Target secunet konnektor 2.1.0 secunet Seite 347 von 424 - Der EVG muss Funktionen zur Administration der Arbeitsplatzkonfiguration gemäß FMT_MTD.1/AK.Admin und der für die Chipkartenauthentisierung benutzten CV- Zertifikate gemäß FMT_MTD.1/AK.Zert bereitstellen. - Die Rolle des Administrators ist durch FMT_SMR.1/AK und die Managementfunktionen für die Cross-CVC sind durch FMT_SMF.1/AK gefordert. Der EVG gewährt den Zugriff auf Chipkarten in Abhängigkeit von deren Sicherheitszustand und der Sicherheitspolitik des Anwendungsfalls. - Der EVG kontrolliert den Zugriff auf Chipkartenkommandos der Chipkarten (außer PIN-Kommandos und kryptographische Schlüssel) über den Chipkartendienst gemäß FDP_ACC.1/AK.KD und FDP_ACF.1/AK.KD. - Der EVG kontrolliert den Zugriff auf PIN-Kommandos der Chipkarten über den Chipkartendienst gemäß FDP_ACC.1/AK.PIN und FDP_ACF.1/AK.PIN. O.AK.VAD Das Sicherheitsziel O.AK.VAD “Schutz der Authentisierungsverifikationsdaten“ definiert die Aufgaben des EVG bei der Steuerung und Zugriffskontrolle für die lokale und entfernte Eingabe von Authentisierungsverifikationsdaten der Benutzer der Chipkarten. Insbesondere fordert es, dass der EVG den Benutzer der entfernten Eingabe bei der Identifizierung des zu benutzenden PIN-Terminals durch die sichere Bereitstellung einer hinreichend eindeutigen Jobnummer für das Clientsystem und der späteren Anzeige der vom Clientsystem übergebenen Jobnummer am PIN-Terminal, die dem identifizierten Arbeitsplatz zugeordnet ist. - Die Erzeugung der Jobnummer ist durch FIA_SOS.2/AK.Jobnummer und deren Anzeige durch FTA_TAB.1/AK.Jobnummer gefordert. Der EVG initiiert die Eingabe der Signatur-PIN und Signatur-PUK der Signaturschlüssel- Inhabers bzw. der Kartenhalter-PIN und Kartenhalter-PUK des Kartenhalters im sicheren PIN- Modus am PIN-Terminal und deren vertrauliche und integritätsgeschützte Übermittlung im Secure Messaging Kanal zwischen der SMC im PIN-Terminal zur VAD-empfangenden Chipkarte im Chipkarten-Terminal. - Die Zugriffskontrolle für die lokale und entfernte PIN- und PUK-Eingabe ist durch FDP_ACC.1/AK.PIN und FDP_ACF.1/AK.PIN gefordert. - FPT_TEE.1/AK fordert bei der Herstellung einer Kommunikation mit einem Gerät, das vorgibt, ein eHealth-Kartenterminal zu sein, zu prüfen, ob das Gerät tatsächlich über eine gültige gSMC-KT verfügt, und das eHealth-Kartenterminal dem EVG als zulässiges Kartenterminal im LAN des Leistungserbringers bekannt ist. FPT_TEE.1/AK fordert weiterhin, dass bei Stecken einer Chipkarte in ein eHealth- Kartenterminals, der Chipkartentyp als HBA, eine SMC, oder eGK und die CHA des CV-Zertifikats zu prüfen ist. Dadurch werden die Voraussetzungen für eine sichere lokale und entfernte PIN- und PUK-Eingabe sichergestellt. Security Target secunet konnektor 2.1.0 Seite 348 von 424 secunet - Die Rolle des Administrators ist durch FMT_SMR.1/AK und die Managementfunktionen für die Cross-CV-Zertifikat sind durch FMT_SMF.1/AK gefordert. - FIA_UAU.5/AK fordert Authentisierungsmechanismen für Chipkarten als PIN-Sender und PIN-Empfängen. - FMT_MTD.1/AK.Admin fordert das Management der Arbeitsplatzkonfiguration, die das zugeordnete Clientsystem und eHealth-Kartenterminals einschließt, auf die Rolle des Administrators zu begrenzen. O.AK.Enc Das Sicherheitsziel O.AK.Enc “Verschlüsselung von Daten“ fordert von dem EVG die automatische Verschlüsselung von Daten. Diese Regeln werden durch den EVG gemäß folgender SFR umgesetzt: - Verschlüsselung von Daten erfordert nach FIA_UAU.1/AK keine Benutzerauthentisierung. - Die Zugriffskontrolle in Abhängigkeit von den Sicherheitsattributen der zu verschlüsselnden Daten wurde gemäß FDP_ACC.1/AK.Enc und FDP_ACF.1/AK.Enc durchgesetzt. - Vor dem Verschlüsseln werden gemäß FDP_ITC.2/AK.Enc die Gültigkeit der Verschlüsselungsrichtlinie und der Zertifikate der Empfänger geprüft. Die CA- Zertifikate können durch den Administrator importiert werden. - Für die Verschlüsselung selbst fordern die SFRs FCS_COP.1/AK.AES und FCS_COP.1/AK.CMS.Ver die Verwendung der Algorithmen AES bzw. AES mit RSA für Hybrid-Verschlüsselung. Ferner fordert FCS_COP.1/AK.XML.Ver die hybride Verschlüsselung von XML Dokumenten. - Verschlüsselte Daten werden gemäß FDP_ETC.2/AK.Enc nur mit der Identität der vorgesehenen Empfänger und der Identität der verwendeten Verschlüsselungsrichtlinie ausgegeben. - FDP_RIP.1/AK schützt zu verschlüsselnde Daten bei Wiederfreigabe einer Ressource. - Die Gültigkeit der X.509-Verschlüsselungszertifikate wird gemäß FPT_TDC.1/AK geprüft. Der EVG verwendet selbst nur sichere kryptographische Algorithmen gemäß [19] für die Verschlüsselung von Dokumenten, wobei - FCS_CKM.1/AK.AES die Erzeugung der AES-Schlüssel fordert. - FCS_CKM.4/AK die Bereitstellung von Verfahren zur sicheren Löschung der verwendeten Schlüssel und FDP_RIP.1/AK die Löschung zu verschlüsseln Dateien bei der Wiederfreigabe der Ressourcen fordern. Security Target secunet konnektor 2.1.0 secunet Seite 349 von 424 O.AK.Dec Das Sicherheitsziel O.AK.Dec “Entschlüsselung von Daten“ erlaubt dem EVG, Daten automatisch zu entschlüsseln, wenn dies die gültigen Verschlüsselungspolicy und der Sicherheitszustand der Chipkarten erlauben. Diese Regeln werden durch den EVG gemäß folgender SFR umgesetzt: - Entschlüsselung von Daten erfordert nach FIA_UAU.1/AK keine Benutzerauthentisierung. - Die Zugriffskontrolle in Abhängigkeit von den Sicherheitsattributen der zu entschlüsselnden Daten wurde gemäß FDP_ACC.1/AK.Enc und FDP_ACF.1/AK.Enc durchgesetzt. - Zu entschlüsselnde Daten werden gemäß FDP_ITC.2/AK.Enc nur nach Prüfung der Gültigkeit der Verschlüsselungspolicy importiert. - Für die Entschlüsselung selbst fordern die SFRs FCS_COP.1/AK.AES und FCS_COP.1/AK.CMS.Ent die Verwendung der Algorithmen AES bzw. AES mit RSA für Hybrid-Verschlüsselung. Ferner fordert FCS_COP.1/AK.XML.Ent die hybride Entschlüsselung von XML Dokumenten. - Entschlüsselte Daten werden gemäß FDP_ETC.2/AK.Enc nur mit der Identität der vorgesehenen Empfänger, dessen Chipkarte zum Entschlüsseln benutzt wurde, ausgegeben. - FDP_RIP.1/AK schützt entschlüsselte Daten bei Wiederfreigabe einer Ressource. Der EVG unterstützt selbst nur sichere kryptographische Algorithmen gemäß [19] für die Entschlüsselung von Dokumenten, wobei - FCS_COP.1/AK.XML.Ent die Entschlüsselung von XML-Dokumenten fordert, und - FCS_CKM.4/AK die Bereitstellung von Verfahren zur sicheren Löschung der verwendeten Schlüssel und FDP_RIP.1/AK die Löschung entschlüsselten Dateien bei der Wiederfreigabe der Ressourcen fordern. O.AK.Protokoll Das Sicherheitsziel O.AK.Protokoll “Sicherheitsprotokoll mit Zeitstempel” fordert die Protokollierung sicherheitsrelevanter Ereignisse durch den EVG. Der EVG protokolliert gemäß den folgenden SFR: - FAU_GEN.1/AK erzeugt Protokolldaten über sicherheitsrelevante Ereignisse (bei solchen Ereignissen verbleibt der EVG aufgrund der SFR FPT_FLS.1/AK stets in einem sichern Zustand), - FAU_SAR.1/AK ermöglicht autorisierten Benutzern die Protokollaufzeichnungen in geeigneter Weise zu lesen. - FAU_STG.1/AK schützt die Protokollaufzeichnungen gegen nichtautorisiertes Löschen und Modifizieren. - FAU_STG.4/AK überschreibt ältere Protokolleinträge, wenn das Protokoll voll ist. Security Target secunet konnektor 2.1.0 Seite 350 von 424 secunet O.AK.Sig.SignQES Das Sicherheitsziel O.AK.Sig.SignQES “Signaturrichtlinie für qualifizierte elektronische Signaturen“ fordert von dem EVG in Abhängigkeit von der gültigen Signaturrichtlinie die Erzeugung qualifizierter elektronischer Signaturen für bestimmte Datenformate nach Überprüfung der Wohlgeformtheit dieser zu signierenden Daten. Dieses Sicherheitsziel wird durch folgende SFR umgesetzt: - FDP_ACC.1/AK.Sgen führt die Signaturerstellungs-SFP ein und FDP_ACF.1/AK.Sgen setzt sie in Abhängigkeit von der Signaturrichtlinie um. - FDP_DAU.2/AK.QES fordert von der TSF, die Fähigkeit zur Erstellung signierter Daten mit qualifizierten elektronischen Signaturen mit Hilfe der sicheren Signaturerstel- lungseinheit bereitzustellen. - FDP_DAU.2/AK.Cert fordert von der TSF, die Fähigkeit zur Erstellung von Nachweisen zur Gültigkeit von qualifizierten elektronischen Signaturen mit Hilfe von Zertifikaten bereitzustellen. - FDP_ITC.2/AK.Sig fordert der TSF, zu signierende Daten und zu prüfende signierte Daten nur nach erfolgreicher Prüfung der Zulässigkeit der Signaturrichtlinie zu importieren. - FPT_TDC.1/AK fordert die Unterstützung der Verteilung neuer öffentlicher Schlüssel über Trust--service Status Listen. - FMT_MSA.3/AK.Sig schränkt das Management der Signaturrichtlinie auf den Administrator ein. - Die TSF muss die Qualität des Administratorpasswortes gemäß FIA_SOS.1/AK.Passwörter und die Authentisierung des Administrators gemäß FIA_UAU.5/AK durchsetzen. - FCS_COP.1/AK.SHA, FCS_COP.1/AK.XML.Sign, FCS_COP.1/AK.CMS.Sign und FCS_COP.1/AK.PDF.Sign fordern von der TSF, sichere kryptographische Algorithmen gemäß [19] für die Signaturerstellung zu implementieren. O.AK.Sig.SignNonQES Das Sicherheitsziel O.AK.Sig.SignNonQES “Signaturrichtlinie für nichtqualifizierte elektronische Signaturen” fordert von dem EVG die Erzeugung nichtqualifizierter elektronische Signaturen für bestimmte Datenformate nach Überprüfung der Wohlgeformtheit dieser zu signierender Daten. Dieses Sicherheitsziel wird durch folgende SFR umgesetzt: - FDP_ACC.1/AK.Sgen führt die Signaturerstellungs-SFP ein und FDP_ACF.1/AK.Sgen setzt sie in Abhängigkeit von der Signaturrichtlinie um. - FDP_DAU.2/AK.Sig fordert von der TSF, die Fähigkeit zur Erstellung signierter Daten mit nichtqualifizierten elektronischen Signaturen mit Hilfe der Chipkarten bereitzustellen. - FCS_COP.1/AK.SHA, FCS_COP.1/AK.CMS.Sign und FCS_COP.1/AK.PDF.Sign fordern von der TSF sichere kryptographische Algorithmen gemäß [19] für die Signaturerstellung zu implementieren. Security Target secunet konnektor 2.1.0 secunet Seite 351 von 424 O.AK.Sig.exklusivZugriff Das Sicherheitsziel O.AK.Sig.exklusivZugriff “Unterstützung bei alleiniger Kontrolle“ fordert von dem EVG Methoden zur Verfügung zu stellen, die es dem Signaturschlüssel-Inhaber ermöglichen, die alleinige Kontrolle über die QSEE auszuüben. Diese Forderung ist durch FDP_ACC.1/AK.Sgen und FDP_ACF.1/AK.Sgen umgesetzt Zusätzlich unterstützen die folgenden SFRs die Umsetzung des Sicherheitszieles: - Gemäß FDP_ACF.1/AK.Sgen und FMT_MSA.4/AK werden die Authentisierung des Signaturschlüsselinhabers gegenüber der sicheren Signaturerstellungseinheit und die Autorisierung des Signaturvorgangs für die angezeigten zu signierenden Daten erzwungen und die TSF darf nur für solche Dateien und Heilberufsausweise den Signaturprozess auslösen, die von dem autorisierten Benutzer des Clientsystems ausgewählt wurden. Außerdem überprüft die TSF, ob für diese Daten ordnungsgemäße qualifizierte elektronische Signaturen erstellt wurden. - FMT_MSA.1/AK.User begrenzt das Recht zur Modifikation des Autorisierungsstatus zu signierender Dateien auf den Benutzer des Clientsystems. - Die Zuordnung von Benutzer des Clientsystems und Signaturschlüssel-Inhaber wird durch FIA_SOS.2/AK.Jobnummer und FTA_TAB.1/AK.Jobnummer unterstützt. - Die TSF muss die Integrität der zum Signieren vom EVG übergebenen Daten gemäß FDP_SDI.2/AK überwachen. - FDP_RIP.1/AK fordert, zu signierende Daten und signierte Daten nach der Ausgabe bei Wiederfreigabe der Ressourcen zu löschen. - FTP_ITC.1/AK.QSEE fordert die Einrichtung eines vertrauenwürdigen Kanals zwischen EVG und QSEE zum Schutz der zu signierenden Daten. - Die Rolle des Administrators ist durch FMT_SMR.1/AK und die Managementfunktionen für die Signaturrichtlinein sind durch FMT_SMF.1/AK gefordert. - Die Rolle des Administrators ist durch FMT_SMR.1/AK und die Managementfunktionen des EVG, insbesondere das Management der eHealth- Kartenterminals und der Arbeitsplätze, sind durch FMT_SMF.1/AK gefordert. O.AK.Sig.Einfachsignatur Das Sicherheitsziel O.AK.Sig.Einfachsignatur „Einfachsignatur“ fordert von dem EVG die Unterstützung der Einfachsignatur. Dieses Sicherheitsziel wird durch folgende SFR umgesetzt: - FDP_ACC.1/AK.Sgen identifiziert die Signaturerstellungs-SFP, - FDP_ACF.1/AK.Sgen beschreibt Regeln für die Einfachsignatur, - FIA_UAU.5/AK beschreibt die Forderung der Authentisierung des HBA vor Ausführung einer Einfachsignatur. Security Target secunet konnektor 2.1.0 Seite 352 von 424 secunet O.AK.Sig.Stapelsignatur Das Sicherheitsziel O.AK.Sig.Stapelsignatur “Stapelsignatur“ fordert von dem EVG die Unterstützung der Stapelsignatur gemäß [21]. Die Forderungen aus [21] werden insbesondere durch folgende SFR umgesetzt. - FIA_API.1/AK fordert, dass die TSF sich gegenüber der QSEE für die Stapelsignatur authentisiert. - FIA_UAU.5/AK beschreibt die Forderung der Authentisierung des HBA vor Ausführung einer Stapelsignatur, und außerdem den Schutz von Vertraulichkeit und Integrität der Kommunikation (insbesondere mit der QSEE) zu schützen. - FDP_ACF.1/AK.Sgen und FMT_MSA.4/AK fordern von der TSF zu überprüfen, ob für die Daten des Stapels ordnungsgemäße qualifizierte elektronische Signaturen erstellt wurden. Bei festgestellten Abweichungen sind alle durch die aktuelle Signtaur-PIN- Eingabe autorisierte Signaturen zu verwerfen. FDP_ACC.1/AK.Sgen identifiziert die Signaturerstellungs-SFP. - FDP_ACF.1/AK.Sgen fordert von der TSF, den Sicherheitszustand der QSEE, der nach erfolgreicher Authentisierung des Signaturschlüssel-Inhabers erlangt wurde, nach der Abarbeitung des Stapels zurückzusetzen. - Das Clientsystem ist über festgestellte Abweichungen beim Signaturprozess über die Schnittstelle gemäß FTA_TAB.1/AK.SP zu informieren. - FTP_ITC.1/AK.QSEE fordert die Einrichtung eines vertrauenwürdigen Kanals zwischen EVG und QSEE zum Schutz der zu signierenden Daten. O.AK.Sig.Komfortsignatur Das Sicherheitsziel O.AK.Sig.Komfortsignatur “Komfortsignatur“ fordert von dem EVG die Unterstützung der Komfortsignatur. Dieses Sicherheitsziel wird durch folgende SFR umgesetzt: - FIA_API.1/AK fordert, dass die TSF sich gegenüber der QSEE für die Komfortsignatur authentisiert. - FIA_UAU.5/AK beschreibt die Forderung der Authentisierung des HBA vor Aktivierung der Komfortsignatur und außerdem den Schutz von Vertraulichkeit und Integrität der Kommunikation (insbesondere mit der QSEE) zu schützen. Zudem fordert FIA_UAU.5/AK die Authentisierung des Clientsystems vor Durchführung einer Komfortsignatur. - FDP_ACF.1/AK.Sgen und FMT_MSA.4/AK fordern von der TSF, den Sicherheitszustand der QSEE, der nach erfolgreicher Authentisierung des Signaturschlüssel-Inhabers bei Aktivierung der Komfortsignatur erlangt wurde, für eine HBA-Kartensitzung erst nach Ablauf eines Zählers oder Zeitwertes zurückzusetzen oder für alle HBAs bzw. HBA-Kartensitzungen bei expliziter Deaktivierung der Komfortsignatur. - Das Clientsystem ist über festgestellte Abweichungen beim Signaturprozess über die Schnittstelle gemäß FTA_TAB.1/AK.SP zu informieren. Security Target secunet konnektor 2.1.0 secunet Seite 353 von 424 - FTP_ITC.1/AK.QSEE fordert die Einrichtung eines vertrauenwürdigen Kanals zwischen EVG und QSEE zum Schutz der zu signierenden Daten. O.AK.Sig.PrüfungZertifikat Das Sicherheitsziel O.AK.Sig.PrüfungZertifikat “Prüfung des Signatur-Zertifikates“ fordert vom EVG, dass er die Gültigkeit dieser Zertifikate, auf denen die Signatur beruht, prüft. Diese Prüfung umfasst den Abgleich, ob die zum Signaturprüfungszeitpunkt verwendeten Signaturalgorithmen für qualifizierte Zertifikate gemäß [19] als kryptografisch sicher gelten bzw. galten. Das Ergebnis der Prüfung wird an der Schnittstelle zum Clientsystem zur Verfügung gestellt. Dieses Sicherheitsziel wird durch folgende SFR umgesetzt: - FDP_DAU.2/AK.QES fordert die Prüfung der qualifizierten Zertifikate nach dem Kettenmodell. - FDP_DAU.2/AK.Cert fordert die einzelnen für Zertifikate zu prüfenden Aspekte bei der Prüfung digitaler Signaturen. - FDP_DAU.2/AK.Sig fordert die Prüfung nichtqualifizierter elektronischer Signaturen für die Benutzer gemäß gültiger Signaturrichtlinien bereitzustellen. - FPT_TDC.1/AK fordert eine konsistente Interpretation der Zertifikate für die Prüfung qualifizierter elektronischer Signaturen bis zu einer bekannten Wurzel und nicht- qualifizierter X.509-Signaturzertifikate. - Für die Prüfung der digitalen Signaturen der Zertifikate muss die TSF die kryptographischen Operationen gemäß FCS_COP.1/AK.SHA, FCS_COP.1/AK.SigVer.PSS und FCS_COP.1/AK.SigVer.SSA implementieren. - FIA_UAU.1/AK und FDP_ACF.1/AK.SigPr erlauben gemäß FDP_ACC.1/AK.SigPr eingeführter Signaturprüfung-SFP die Signaturprüfung durch nichtauthentisierte Benutzer. - FMT_MSA.3/AK.Sig schränkt das Management der Signaturrichtlinie, die insbesondere die Prüfung der Zertifikate bestimmt, auf den Administrator ein. O.AK.Sig.Schlüsselinhaber Das Sicherheitsziel O.AK.Sig.Schlüsselinhaber “Zuordnung des Signaturschlüssel-Inhabers“ fordert vom EVG, bei der Überprüfung der signierten Daten anzuzeigen, welchem Signaturschlüssel-Inhaber die Signatur zuzuordnen ist. Dieses Sicherheitsziel wird durch folgende SFR umgesetzt: - FDP_DAU.2/AK.QES, FDP_DAU.2/AK.Sig und FDP_DAU.2/AK.Cert fordern die Fähigkeit der TSF zur Bereitstellung des Signaturschlüssel-Inhabers über die Schnittstelle des Clientsystems für qualifizierte und nichtqualifizierte elektronische Signaturen sowie für Signaturen in elektronischen Zertifikaten. - FPT_TDC.1/AK fordert eine konsistente Interpretation der Zertifikate (die den Signaturschlüssel-Inhaber identifizieren) für die Prüfung qualifizierter elektronischer Signaturen und nicht-qualifizierter X.509-Signaturzertifikate sowie deren Prüfung bis zu einer bekannten Wurzel. Security Target secunet konnektor 2.1.0 Seite 354 von 424 secunet - FIA_UAU.1/AK und FDP_ACF.1/AK.SigPr erlauben gemäß FDP_ACC.1/AK.SigPr eingeführter Signaturprüfung-SFP die Signaturprüfung durch nichtauthentisierte Benutzer. O.AK.Sig.SignaturVerifizierung Das Sicherheitsziel O.AK.Sig.SignaturVerifizierung “Verifizierung der Signatur“ fordert vom EVG die Korrektheit einer digitalen Signatur zuverlässig zu prüfen und das Ergebnis der Prüfung an der Schnittstelle zum Clientsystem zur Verfügung zu stellen. Bei der Überprüfung der signierten Daten zeigt der EVG an, ob die signierten Daten unverändert sind. Dieses Sicherheitsziel wird durch folgende SFR umgesetzt: - FDP_DAU.2/AK.QES fordert die Prüfung der qualifizierten elektronischen Signaturen, hier speziell der signierten Daten, nach dem Kettenmodell. - FDP_DAU.2/AK.Cert fordert die einzelnen für die signierten Daten zu prüfenden Aspekte bei der Prüfung digitaler Signaturen. - FDP_DAU.2/AK.Sig fordert die Prüfung nichtqualifizierter elektronischer Signaturen für die Benutzer gemäß gültiger Signaturrichtlinien bereitzustellen. - Für die Prüfung der digitalen Signaturen der signierten Daten muss die TSF die kryptographischen Operationen gemäß FCS_COP.1/AK.SHA, FCS_COP.1/AK.SigVer.PSS, , FCS_COP.1/AK.SigVer.ECDSA und FCS_COP.1/AK.SigVer.SSA implementieren. - Für die Prüfung der XML-kodierten signierten Daten muss die TSF FCS_COP.1/AK.XML.SigPr implementieren. Für CMS bzw. PKCS#1 kodierte signierte Dokumente ist dies entsprechend in FCS_COP.1/AK.CMS.SigPr gefordert. Für die Prüfung signierter PDF-Dokumente muss die TSF FCS_COP.1/AK.PDF.SigPr implementieren. - FIA_UAU.1/AK und FDP_ACF.1/AK.SigPr erlauben gemäß FDP_ACC.1/AK.SigPr eingeführter Signaturprüfung-SFP die Signaturprüfung durch nichtauthentisierte Benutzer. O.AK.Selbsttest Das Sicherheitsziel O.AK.Selbsttest „Selbsttests“ fordert vom EVG die Durchführung von Selbsttests beim Start-up und bei Bedarf. FPT_TST.1/AK.Run-Time fordert die Durchführung einer Testfolge beim Erstanlauf und regelmäßig während des Normalbetriebes des EVG. Ferner fordert FPT_TST.1/AK.Out-Of-Band die Durchführung einer Testfolge auf Anforderung durch den Benutzer. Dadurch kann die Integrität der TSF-Daten überprüft werden. Bei gefundenen Fehlerzuständen verbleibt der EVG aufgrund FPT_FLS.1/AK stets in einem sicheren Zustand. O.AK.LAN Das Sicherheitsziel O.AK.LAN „gesicherte Kommunikation im LAN der Leistungserbringer“ fordert vom EVG die Möglichkeit einer bezüglich Integrität, Authentizität und Vertraulichkeit Security Target secunet konnektor 2.1.0 secunet Seite 355 von 424 gesicherten Verbindung zwischen EVG und Clientsystemen. Dieses Sicherheitsziel wird durch folgende SFR umgesetzt: - FTP_ITC.1/AK.CS fordert einen vertrauenswürdigen Kanal zwischen dem EVG und Clientsystemen. - Die kryptographischen Operationen des TLS-Kanals müssen gemäß FCS_COP.1/NK.TLS.HMAC, FCS_COP.1/NK.TLS.AES und FCS_COP.1/NK.TLS.Auth mit den dort geforderten Algorithmen erfolgen. - FCS_CKM.1/NK.TLS fordert die kryptographische Schlüsselgenerierung von 128 und 256 Bit Schlüsseln gemäß [68] und [19]. - FDP_ACC.1/AK.TLS führt die TLS-SFP ein und FDP_ACF.1/AK.TLS definiert die Regeln des Zugriffs auf TLS Kanäle und die damit transportierten Daten. - FMT_MSA.1/AK.TLS beschreibt die Einschränkungen beim Verwalten von Sicherheitsattribute für TLS Kanälen. FMT_MSA.3/AK.TLS beschreibt den Umgang mit Standardwerten für Sicherheitsattribute von TLS-Kanälen. - FCS_CKM.1/NK.Zert fordert die Erzeugung von X.509 Zertifikaten von Clientsystemen zur Absicherung der TLS-Verbindungen. Diese können mittels FDP_ETC.2/NK.TLS zur Verwendung in Clientsystemen exportiert werden. FDP_ITC.2/NK.TLS ermöglicht dem Import von X.509 Zertifikaten von Clientsystemen. O.AK.WAN Das Sicherheitsziel O.AK.WAN „gesicherte Kommunikation zwischen EVG und Fachdiensten“ fordert vom EVG die Möglichkeit einer bezüglich Integrität, Authentizität und Vertraulichkeit gesicherten Verbindung zwischen EVG und Fachdiensten. Dieses Sicherheitsziel wird durch folgende SFR umgesetzt: - FTP_ITC.1/AK.FD fordert einen vertrauenswürdigen Kanal zwischen dem EVG und Fachdiensten. - Die kryptographischen Operationen des TLS-Kanals müssen gemäß FCS_COP.1/NK.TLS.HMAC, FCS_COP.1/NK.TLS.AES und FCS_COP.1/NK.TLS.Auth mit den dort geforderten Algorithmen erfolgen. - FDP_ACC.1/AK.TLS führt die TLS-SFP ein und FDP_ACF.1/AK.TLS definiert die Regeln des Zugriffs auf TLS Kanäle und die damit transportierten Daten. - FMT_MSA.1/AK.TLS beschreibt die Einschränkungen beim Verwalten von Sicherheitsattributen für TLS Kanälen. FMT_MSA.3/AK.TLS beschreibt den Umgang mit Standardwerten für Sicherheitsattribute von TLS-Kanälen. O.AK.Zeit Das Sicherheitsziel O.AK.Zeit „Systemzeit“ fordert vom EVG die Bereitstellung einer sicheren Systemzeit, die in regelmäßigen Abständen (vom Netzkonnektor) mit einem vertrauenswürdigen Zeitdienst synchronisiert wird. FPT_STM.1/AK fordert die Bereitstellung Security Target secunet konnektor 2.1.0 Seite 356 von 424 secunet eines verlässlichen Zeitstempels. Details zur Synchronisation der Systemzeit sind Aufgabe des Netzkonnektors und in dessen Schutzprofil [17] definiert. O.AK.Update Das Sicherheitsziel O.AK.Update „Software Update und Update von TSL, CRL und BNetzA- VL“ fordert vom EVG die Aktualisierung von Software-Komponenten und von TSL, BNetzA- VL und CRL, deren Prüfung auf Integrität, sowie die Übertragung der BNetzA-VL, deren Hash und von Firmware-Update-Paketen über einen sicheren Kanal. FDP_ACC.1/AK.Update führt die Update-SFP für den Software-Update ein und FDP_ACF.1/AK.Update definiert die Regeln für den Umgang mit dem Software-Update beim Import. Die Anforderung FDP_UIT.1/AK.Update fordert den Empfang der Software-Update-Daten und die Prüfung der Integrität dieser Daten vor dem Update. Die Anforderungen FTP_ITC.1/AK.KSR und FTP_TRP.1/NK.Admin fordern einen gesicherten Kanal für den Empfang der Software- Update-Daten aus der TI bzw. lokal über die Management-Schnittstelle. FPT_TDC.1/AK fordert die Fähigkeit des EVG zur Interpretation, und damit dem Import und die Aktualisierung von TSL und CRL nach erfolgreicher Prüfung der entsprechenden Signaturen und Zertifikate. FTP_ITC.1/AK.KSR und FTP_ITC.1/AK.TSL fordern den Aufbau eines sicheren Kanals für den Download von Firmware-Update-Paketen bzw. der BNetzA-VL und deren Hash-Wert. O.AK.exklusivZugriff Das Sicherheitsziel O.AK.exklusivZugriff „Alleinige Kontrolle von Terminal und Karte“ fordert vom EVG die Bereitstellung von Methoden, die es dem Benutzer ermöglichen, die alleinige Kontrolle über die verwendeten Kartenterminals und die verwendeten Chipkarten auszuüben. FDP_ACC.1/AK.Infomod führt die Infomodell-SFP ein und FDP_ACF.1/AK.Infomod definiert die Regeln des Zugriffs auf Kartenterminals und Kartensitzungen. Ferner werden in FDP_ACF.1/AK.KD Regeln zur Zugriffskontrolle auf Chipkarten und Kommunikationskanäle mit Chipkarten definiert. O.AK.PinManagement Das Sicherheitsziel O.AK.PinManagement „Management von Chipkarten-PINs“ fordert vom EVG die Möglichkeit zum Ändern, Aktivieren und Deaktivieren von PINs der Chipkarten, das Abfragen der Status von PINs der Chipkarten sowie das Entsperren gesperrter Chipkarten-PINs. FDP_ACC.1/AK.PIN führt die VAD-SFP ein und FDP_ACF.1/AK.PIN definiert die Regeln für den Umgang, die Eingabe und dem Wechsel mit Chipkarten-PINs. O.AK.Infomodell Das Sicherheitsziel O.AK.Infomodell „Umsetzung des Informationsmodells durch den EVG“ fordert vom EVG die persistente Zuordnung von Mandanten, Clientsystemen, Arbeitsplätzen und Kartenterminals sowie die transiente Zuordnung von Benutzern zu Arbeitsplätzen. Ferner fordert es die Verwaltung in Kartenterminals gesteckter Chipkarten und Kartensitzungen zur Security Target secunet konnektor 2.1.0 secunet Seite 357 von 424 Durchsetzung einer Zugriffskontrolle über die den Mandanten zugeordneten Ressourcen, die Chipkarten der Benutzer der Arbeitsplätze und die Chipkarten in Übereinstimmung der für die Kartensitzung erreichten Sicherheitszustände. Dieses Sicherheitsziel wird durch folgende SFR umgesetzt: - FDP_ACC.1/AK.Infomod führt die Infomodell-SFP ein und FDP_ACF.1/AK.Infomod definiert die Regeln für den Zugriff und die Verwaltung von Kartenterminals, Kartensitzungen, Karten, Arbeitsplätzen, Mandanten und Clientsystemen. - FMT_MSA.1/AK.Infomod beschreibt die Einschränkungen beim Verwalten von persistenten Sicherheitsattributen im Informationsmodell des Konnektors. FMT_MSA.3/AK.Infomod beschreibt den Umgang mit Standardwerten für Sicherheitsattribute im Informationsmodell des Konnektors. Sollte dennoch der EVG durch einen festgestellten Verstoß gegen das Infomodell in einen Fehlerzustand gelangen, so verbleibt der EVG aufgrund des SFR FPT_FLS.1/AK stets in einem sicheren Zustand. O.AK.VSDM Das Sicherheitsziel O.AK.VSDM „Versichertenstammdatenmanagement“ enthält Anforderungen an den EVG zum Verhalten des VSDM Fachmodules und zur Kommunikation mit dem VSDD Fachdienst. Diese werden durch die SFRs FDP_ACC.1/AK.VSDM und FDP_ACF.1/AK.VSDM umgesetzt: FDP_ACC.1/AK.VSDM führt die VSDM-SFP für den Zugriff auf Versichertenstammdaten ein und FDP_ACF.1/AK.VSDM definiert die Regeln für den Zugriff auf Versichertenstammdaten und für die Kommunikation mit dem VSDD Fachdienst; das Management der Sicherheitsattribute von FDP_ACF.1/AK.VSDM geschieht über FMT_MSA.1/AK.VSDM und FMT_MSA.3/AK.VSDM. Die TLS-Verbindung zwischen VSDM-Fachmodul und VSDD Fachdienst gemäß FTP_ITC.1/AK.FD unterliegt der Zugriffskontrolle gemäß FDP_ACC.1/AK.TLS und FDP_ACF.1/AK.TLS sowie dem Management gemäß FMT_MSA.1/AK.TLS und FMT_MSA.3/AK.TLS. O.AK.VZD Das Sicherheitsziel O.AK.VZD „Kommunikation mit dem zentralen Verzeichnisdienst“ werden gesicherte Kanäle zwischen dem LDAP-Proxy und dem VZD bereit gestellt. Diese TLS-Kanäle werden gemäß SFR FTP_ITC.1/AK.VZD implementiert und unterliegen der Zugriffskontrolle gemäß FDP_ACC.1/AK.TLS und FDP_ACF.1/AK.TLS sowie dem Management gemäß FMT_MSA.1/AK.TLS und FMT_MSA.3/AK.TLS. O.AK.VAUSGD Das Sicherheitsziel O.AK.VAUSGD (Anteil VAU) stellt VAU-Kanäle zur sicheren Kommunikation mit der Vertrauenswürdigen Ausführungsumgebung (VAU) der ePA Security Target secunet konnektor 2.1.0 Seite 358 von 424 secunet Fachanwendung zur Verfügung. Diese VAU-Kanäle werden gemäß SFR FTP_ITC.1/VAU implementiert. Das VAU-Protokoll ist dabei eine entsprechend FCS_CKM.1/VAU, FCS_COP.1/VAU.AES und FCS_CKM.4/AK modellierte Sicherungsschicht innerhalb eines TLS-Kanals. Die Authentisierung ist zertifikatsbasiert (FCS_COP.1/VAU.Auth) und folgt den Regeln in FPT_TDC.1/SGDVAU. Das Sicherheitsziel O.AK.VAUSGD (Anteil SGD) stellt eine Ende zu Ende Verschlüsselung von SGD-Client und den SGD-HSMs der Schlüsselgenerierungsdienste SGD1 und SGD2 der ePA Fachanwendung dar. Dabei werden einzelne Nachrichtenteile des SGD-Protokolls so verschlüsselt, dass sie nur vom jeweiligen HSM entschlüsselt werden können. Dieser gesicherte Anteil der Kommunikation wird entsprechend dem SFR FTP_ITC.1/SGD als SGD-Kanal aufgefasst. Der SGD-Kanal ist dabei entsprechend FCS_COP.1/SGD.ECIES und FCS_CKM.4/AK modelliert und setzt auf ECIES-Verschlüsselung auf. Der öffentliche ECIES- Schlüssel des HSM wird dazu zusammen mit seiner Signatur und dem entsprechenden Zertifikat mittels GetPublicKey Operation eingebracht (FDP_ITC.2/SGD). Die Verwendung des Schlüssels ist nur erlaubt, wenn die Prüfung der Signatur und des Zertifikates erfolgreich sind (FDP_ACC.1/SGD, FDP_ACF.1/SGD). Die Authentisierung ist zertifikatsbasiert (FCS_COP.1/SGD.Auth) und folgt den Regeln in FPT_TDC.1/SGDVAU. 6.5.7. Erklärung für die Vertrauenswürdigkeitsanforderungen Der Schutz der Benutzerdaten durch Verschlüsselung erfordert einen Schutz gegen ein Angriffspotential „Enhanced Basic“. Für CC Version 3.1 ist folglich eine Erweiterung der gewählten EAL-Stufe EAL3 um AVA_VAN.3 notwendig. Daraus ergeben sich Abhängigkeiten gem. [6], die mit den zusätzlichen Erweiterung um ADV_FSP.4, ADV_TDS.3, ADV_IMP.1 und ALC_TAT.1 aufgelöst werden. Anmerkung: Die in CC Teil 3 [6] angegebenen Abhängigkeiten von AVA_VAN.3 sind leider nicht vollständig aufgelöst: ADV_IMP.1 impliziert zusätzlich ALC_TAT.1. Die Komponente ALC_FLR.2 wurde gewählt, um Prozeduren zur Beseitigung von festgestellten Sicherheitsproblemen und Verbesserungen des EVG auf der Grundlage von Informationen der Anwender reagieren zu können und zur Verbesserung des EVG beizutragen. ALC_FLR.2 besitzt keine weiteren Abhängigkeiten. Die EAL-Stufe an sich ist in sich konsistent und erfüllt alle Abhängigkeiten. Security Target secunet konnektor 2.1.0 secunet Seite 359 von 424 7. Zusammenfassung der EVG Sicherheitsfunktionalität 7.1. Sicherheitsfunktionen des Netzkonnektors Die funktionalen Sicherheitsanforderungen werden im Folgenden nach funktionalen Gruppen gegliedert. Die funktionalen Gruppen orientieren sich an den in Abschnitt 1.3.5 beschriebenen Sicherheitsdiensten (hier nur kurz in Stichworten rekapituliert): - VPN-Client: gegenseitige Authentisierung, Vertraulichkeit, Datenintegrität, Informationsflusskontrolle (erzwungene VPN-Nutzung für sensitive Daten); - Dynamischer Paketfilter: sowohl für WAN als auch für LAN; - Netzdienste: Zeitsynchronisation über sicheren Kanal, Zertifikatsprüfung mittels Sperrlisten; - Stateful Packet Inspection: Generierung von Audit-Daten für spätere zustandsgesteuerte Filterung; - Selbstschutz: Speicheraufbereitung, Selbsttests, sicherer Schlüsselspeicher, Schutz von Geheimnissen, optional sichere Kanäle zu anderen Komponenten des Konnektors, Protokollierung Sicherheits-Log; - Administration: Möglichkeit zur Wartung, erzwungene Authentisierung des Administrators, eingeschränkte Möglichkeit der Administration von Firewall-Regeln, Software Update. - Kryptografische Basisdienste - TLS-Kanäle unter Nutzung sicherer kryptographischer Algorithmen 7.1.1. NK.VPN-Client VPN Der EVG stellt einen sicheren Kanal zur zentralen Telematikinfrastruktur-Plattform (TI- Plattform) sowie zum Sicheren Internet Service bereit, der nach gegenseitiger Authentisierung die Vertraulichkeit und Datenintegrität der Nutzdaten sicherstellt (Bei Verbindungen zum VPN- Konzentrator der Telematikinfrastruktur siehe FTP_ITC.1/NK.VPN_TI und bei Verbindungen zum Sicheren Internet Service (SIS) siehe FTP_ITC.1/NK.VPN_SIS). Der Trusted Channel wird auf Basis des IPsec-Protokolls aufgebaut. Dabei wird IKEv2 unterstützt. Informationsflusskontrolle Regelbasiert nutzen alle schützenswerten Informationsflüsse die etablierten VPN-Tunnel. Nur Informationsflüsse, die vom Konnektor initiiert wurden sowie Informationsflüsse von Clientsystemen in Bestandsnetze dürfen den VPN-Tunnel in die Telematikinfrastruktur benutzen und erhalten damit überhaupt erst Zugriff auf die zentrale Telematikinfrastruktur- Plattform. Andere Informationsflüsse, die den Zugriff auf Internet-Dienste aus den lokalen Security Target secunet konnektor 2.1.0 Seite 360 von 424 secunet Netzen der Leistungserbringer betreffen, nutzen den VPN-Tunnel zum Sicheren Internet Service. Diese Aspekte ergeben sich aus der Betrachtung der VPN-Kanäle. Sie werden aber im Hinblick auf ihre Realisierung der Anforderung nach Informationsflusskontrolle mittels einem dynamischen Paketfilter (FDP_IFC.1/NK.PF, FDP_IFF.1/NK.PF, siehe Abschnitt 6.2.2) zugeordnet. Durch FDP_IFF.1.2/NK.PF wird eine VPN-Nutzung für zu schützende Daten der TI und der Bestandsnetze und für zu schützende Nutzerdaten (im Sinne des Abschnitts 3.1) gefordert, sofern die Paketfilter-Regeln geeignet gesetzt sind. Dies wird durch die Administratordokumentation (siehe das Refinement zu AGD_OPE.1 in Abschnitt 6.2.8) sichergestellt. 7.1.2. NK.Dynamischer Paketfilter Dynamischer Paketfilter mit zustandsgesteuerter Filterung Der EVG implementiert einen dynamischen Paketfilter. Diese Anforderung wird als Informationsflusskontrolle modelliert (siehe FDP_IFC.1/NK.PF und FDP_IFF.1/NK.PF). Zur zustandsgesteuerten Filterung siehe auch Abschnitt 7.1.4 Stateful Packet Inspection. Die von FDP_IFF.1.2/NK.PF geforderten Filterregeln (packet filtering rules) sind mit geeigneten Default-Werten vorbelegt (siehe FMT_MSA.3/NK.PF) und können vom Administrator verwaltet werden (siehe FMT_MSA.1/NK.PF, vgl. Abschnitt 6.2.6 Administration). 7.1.3. NK.Netzdienste Zeitsynchronisation Der EVG führt in regelmäßigen Abständen eine Zeitsynchronisation mit Zeitservern durch. Siehe auch Sicherheitsdienst Zeitdienst (siehe FPT_STM.1/NK). Der EVG unterstützt eine Signaleinrichtung in Form von Status-LEDs, welche den Betriebszustand an der Außenhaut des Konnektors anzeigt, um die Anforderung gemäß Konnektor-Spezifikation [27], Abschnitt 3.3 Betriebszustand umzusetzen, siehe LS14 und PS5 in Kapitel 1.3.3 sowie die Anforderungen an die Konnektor Hardware in Kapitel 1.3.6. Zertifikatsprüfung Der EVG überprüft die Gültigkeit der Zertifikate, die für den Aufbau der VPN-Kanäle verwendet werden. Die erforderlichen Informationen zur Prüfung der Gerätezertifikate werden dem EVG in Form einer (signierten) Trust-service Status List (TSL) und einer Sperrliste (CRL) bereitgestellt. Der EVG prüft die Zertifikate kryptographisch mittels der aktuell gültigen TSL und CRL (siehe FPT_TDC.1/NK.Zert). Security Target secunet konnektor 2.1.0 secunet Seite 361 von 424 7.1.4. NK.Stateful Packet Inspection Der EVG kann nicht wohlgeformte IP-Pakete erkennen und verwirft diese. Er implementiert eine sogenannte „zustandsgesteuerte Filterung“ (engl. „stateful packet inspection“ oder auch „stateful inspection“ genannt). Dies ist eine dynamische Paketfiltertechnik, bei der jedes Datenpaket einer aktiven Session zugeordnet und der Verbindungsstatus in die Entscheidung über die Zulässigkeit eines Informationsflusses einbezogen wird. Der Aspekt der Stateful Packet Inspection wird durch FDP_IFF.1.4/NK.PF modelliert. 7.1.5. NK.Selbstschutz Der EVG schützt sich selbst und die ihm anvertrauten Daten durch zusätzliche Mechanismen, die Manipulationen und Angriffe erschweren. Versuche, den ausführbaren Code zu verändern werden durch Prüfung der Integrität der installierten SW Images bei jedem Start (Secure Boot) gewährleistet (siehe Selbsttests). Speicheraufbereitung Der EVG löscht nicht mehr benötigte kryptographische Schlüssel (insbesondere session keys für die VPN-Verbindung) nach ihrer Verwendung durch aktives Überschreiben mit Nullen (siehe FDP_RIP.1/NK). Der EVG speichert medizinische Daten nicht dauerhaft. Ausnahmen sind die Speicherung von Daten während ihrer Ver- und Entschlüsselung; auch diese werden sobald wie möglich nach ihrer Verwendung gelöscht. Selbsttests Der EVG bietet seinen Benutzern eine Möglichkeit, die eigene Integrität zu überprüfen (siehe FPT_TST.1/NK). Es wird bei Programmstart eine Prüfung der Integrität der installierten ausführbaren Dateien und sonstigen sicherheitsrelevanten Dateien (Konfigurationsdateien, TSF-Daten) durch Verifikation von Signaturen durchgeführt (unter Verwendung von RSA 2048 und SHA 256, siehe FCS_COP.1/NK.Auth). Dazu verifiziert der UEFI BIOS die Signatur des Bootloaders. Dieser verifiziert die Signatur über den Betriebssystemkernel und die initial ramdisk. In der initial ramdisk ist das Root Dateisystem enthalten. Die öffentlichen Prüfschlüssel zur Verifikation der Integrität sind jeweils in den Prüfenden Komponenten hinterlegt (initialer Boot Schlüssel des UEFI im Secure ROM, Boot Schlüssel des Bootloaders im Drive Security Sector). Die Selbsttest-Funktion (Secure Boot) kann nicht deaktiviert bzw. manipuliert werden. Die jeweiligen Prüfroutinen werden durch die sichere Bootchain, angefangen mit dem UEFI BIOS abgesichert. Damit ist auch die Integrität der Implementierung kryptographischer Verfahren sichergestellt. Der EVG nutzt den physikalischen Zufallszahlengenerator der gSMC-K als Seed Quelle für den Zufallszahlengenerator des Betriebssystems. Dieser ist durch die Prüfung der Integrität ebenfalls vor Manipulationen abgesichert. Der Benutzer kann die Selbsttests durch Neustart des EVGs selbst anstoßen. Schlägt die Prüfung der Integrität fehl, so wird ein Neustart des EVG durchgeführt. Dies führt dann bei manipulierten Komponenten zu einem „Endless Loop“ Security Target secunet konnektor 2.1.0 Seite 362 von 424 secunet Im Falle einer Software-Aktualisierung wird dieselbe Bootchain abgelaufen, aber vom Bootloader das neue SW Image geprüft und geladen. Schlägt die Prüfung der Integrität fehl, so wird ein Neustart des EVG durchgeführt und dann das ursprüngliche SW Image geladen. Schutz von Geheimnissen, Seitenkanalresistenz Der EVG schützt Geheimnisse während ihrer Verarbeitung gegen unbefugte Kenntnisnahme einschließlich der Kenntnisnahme nach Angriffen durch Seitenkanal-Analysen (side channel analysis), siehe FPT_EMS.1/NK. Dies gilt grundsätzlich für kryptographisches Schlüsselmaterial (siehe Tabelle 4: Sekundäre Werte in Abschnitt 3.1.1.1). Der private Authentisierungsschlüssel für das VPN wird bereits durch das gSMC-K und dessen Resistenz gegen Seitenkanalangriffe geschützt. Der EVG verhindert darüber hinaus den Abfluss von geheimen Informationen wirkungsvoll, etwa die Session Keys der VPN- Verbindung oder zu schützende Daten der TI und der Bestandsnetze. Sicherheits-Log Der EVG führt ein Sicherheits-Log gemäß Konnektor-Spezifikation [27], Abschnitt 4.1.10 wie unter Sicherheitsdienst Protokollierung in Abschnitt 1.3.5 beschrieben. Diese Funktionalität ist mit FAU_GEN.1/NK.SecLog und FAU_GEN.2/NK.SecLog modelliert. 7.1.6. NK.Administration Administrator-Rollen, Management-Funktionen, Authentisierung der Administratoren, gesicherte Wartung Der EVG verwaltet eine Administrator-Rolle (FMT_SMR.1./NK). Der Administrator muss autorisiert sein (FIA_UID.1/NK.SMR, FMT_SMR.1./NK und FIA_UAU.1/NK.SMR), bevor er administrative Tätigkeiten bzw. Wartungstätigkeiten ausführen darf (FMT_MTD.1/NK). Die Authentisierung erfolgt dabei durch den Netzkonnektor selbst, siehe O.NK.Admin_Auth. Die Wartung selbst erfolgt unter der Annahme, dass der Administrator über Netzwerkverbindungen (z. B. LAN, WAN) zugreift, stets über eine sichere TLS Verbindung (siehe FTP_TRP.1/NK.Admin bzw. FTP_ITC.1/NK.TLS). Die administrativen Tätigkeiten bzw. Wartungstätigkeiten werden in FMT_SMF.1/NK aufgelistet. Dazu gehören die Verwaltung der Filterregeln für den dynamischen Paketfilter sowie das Aktivieren und Deaktivieren des VPN-Tunnels. Die Administration der Filterregeln für den dynamischen Paketfilter (siehe: FDP_IFC.1/NK.PF) ist den Administratoren vorbehalten (FMT_MSA.1/NK.PF). Software Update Signierte Update-Pakete werden importiert (FDP_ITC.1/NK.Update) und im Datenspeicher des EVG abgelegt. Sobald ein Update-Paket zur Verfügung steht signalisiert der TOE das ein Software Update zur Verfügung steht. Der Administrator kann die Version des Update-Paketes Security Target secunet konnektor 2.1.0 secunet Seite 363 von 424 prüfen und den Updateprozess anstoßen (FDP_ACC.1/NK.Update. Automatische Installation von Software Updates wird vom EVG ebenfalls unterstützt (FDP_ACF.1/NK.Update). Im Falle einer Software-Aktualisierung wird der EVG neu gestartet und dieselbe Bootchain wie in der Sicherheitsfunktion „NK.Selbstschutz“ beschrieben abgelaufen, aber vom Bootloader wird das neue Update-Paket auf Integrität geprüft und bei erfolgreicher Prüfung geladen. Das alte Image wird vom EVG verworfen. Schlägt die Prüfung der Integrität fehl, so wird das Update-Paket verworfen und ein Neustart des EVG durchgeführt mit dem das ursprüngliche SW Image geladen wird. Durch die Prüfung des Update-Pakets analog zum regulären Boot Prozess wird verhindert, dass manipulierte Update-Pakete eingespielt werden können (FDP_UIT.1/NK.Update). 7.1.7. NK.Kryptographische Basisdienste Der Konnektor implementiert gemäß der Vorgaben des Dokuments „Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur [gemSpec_Krypt]“ [30] die im Folgenden aufgelistete kryptographischen Primitive.  Hash-Berechnung, siehe FCS_COP.1/NK.Hash  HMAC-Berechnung, siehe FCS_COP.1/NK.HMAC  Prüfung und Erzeugung von digitalen Signaturen (basierend auf SHA-256 und RSA bzw. ECDSA Algorithmus) zur Unterstützung von Authentisierungsmechanismen, siehe FCS_COP.1/NK.Auth  Ver- und Entschlüsselung mittels symmetrischer Algorithmen (AES im CBC Modus mit 256bit Schlüssellänge oder AES im GCM Modus mit 128bit und 256bit Schlüssellänge) zur Unterstützung der Absicherung des IPsec-Tunnels, siehe FCS_COP.1/NK.ESP  VPN Kommunikationsprotokoll zur Absicherung des IPsec-Tunnel, siehe FCS_COP.1/NK.IPsec  Erzeugung von Schlüsseln für die VPN-Kanäle mit hoher Qualität für alle oben benannten kryptographischen Algorithmen (FCS_COP.1/NK.HMAC, FCS_COP.1/NK.Auth, FCS_COP.1/NK.ESP, FCS_COP.1/NK.IPsec)  Schlüsselaustausch (IPsec IKEv2) zum Aufbau von VPN-Tunnel, siehe FCS_CKM.2/NK.IKE  Schlüsselvernichtung für nicht mehr benötigte Schlüssel durch Überschreiben mit Nullen, siehe FCS_CKM.4/NK Die kryptographischen Basisdienste (z.B. Hash-Berechnung, AES Ver-/Entschlüsselung) des Netzkonnektors werden nicht direkt nach außen zur Verfügung gestellt, sondern können nur indirekt aufgerufen werden (z.B. Einrichtung und Verwendung des VPN Kanals). Security Target secunet konnektor 2.1.0 Seite 364 von 424 secunet 7.1.8. NK.TLS-Kanäle unter Nutzung sicherer kryptographischer Algorithmen Der Netzkonnektor stellt dem Anwendungskonnektor die Dienste zum Aufbau eines TLS Kanals zur Verfügung FTP_ITC.1/NK.TLS. TLS wird auch zur Absicherung der Administrator-Schnittstelle verwendet. Dabei werden nur die folgenden Cipher Suites unterstützt: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Der Netzkonnektor implementiert entsprechend die im Folgenden aufgelisteten kryptographischen Primitiven für TLS.  HMAC-Berechnung, siehe FCS_COP.1/NK.TLS.HMAC  Prüfung und Erzeugung von digitalen Signaturen (basierend auf SHA-256, ECDSA und RSA Algorithmus) zur Unterstützung von Authentisierungsmechanismen, siehe FCS_COP.1/NK.TLS.Auth  Ver- und Entschlüsselung mittels symmetrischer Algorithmen (AES im CBC und GCM Modus mit 128 bit und 256 bit Schlüssellänge) zur Unterstützung der Absicherung des TLS-Kanals, siehe FCS_COP.1/NK.TLS.AES  Erzeugung von Schlüsseln für die TLS-Kanäle mit hoher Qualität für alle oben benannten kryptographischen Algorithmen (FCS_COP.1/NK.TLS.HMAC, FCS_COP.1/NK.TLS.Auth, FCS_COP.1/NK.TLS.AES), siehe FCS_CKM.1/NK.TLS  Schlüsselvernichtung für nicht mehr benötigte Schlüssel durch Überschreiben mit Nullen, siehe FCS_CKM.4/NK Die kryptographischen Basisdienste für TLS (z.B. HMAC-Berechnung, AES Ver- /Entschlüsselung) des Netzkonnektors werden nicht direkt nach außen zur Verfügung gestellt, sondern können nur indirekt aufgerufen werden (z.B. Einrichtung und Verwendung des TLS Kanals). Zertifikate die im Rahmen des TLS-Verbindungsaufbaus zum Einsatz kommen werden vom Netzkonnektor entsprechend den Vorgaben aus FPT_TDC.1/NK.TLS.Zert interpretiert. Der EVG prüft insbesondere, ob die Gültigkeitsdauer eines Zertifikates überschritten ist und ob ein Zertifikat in einer Whitelist enthalten ist. Für die Einrichtung einer sicheren TLS-Verbindung zwischen Konnektor und Clientsystemen werden X.509 Zertifikate verwendet. Entsprechende Zertifikate für die Kommunikation mit Security Target secunet konnektor 2.1.0 secunet Seite 365 von 424 Clientsystemen können vom EVG erzeugt werden (FCS_CKM.1/NK.Zert). Der EVG bietet dem Administrator eine sichere Schnittstelle zum exportieren dieser X.509 Zertifikate für Clientsysteme und die zugehörigen privaten Schlüssel (FDP_ETC.2/NK.TLS). Bei Zertifikaten für Serversysteme werden die zugehörigen privaten Schlüssel nicht exportiert. Zertifikate für die Kommunikation mit Clientsystemen können auch vom EVG gemäß FDP_ITC.2/NK.TLS über die gesicherte Management-Schnittstelle durch den Administrator importiert werden (FTP_TRP.1/NK.Admin), um ggf. benötigte Betriebszustände wiederherzustellen. Die importierten Zertifikate werden ebenfalls nach den Vorgaben in FPT_TDC.1/NK.TLS.Zert interpretiert. Die TLS-Verbindungen werden vom Anwendungskonnektor gemanagt und je nach Anwendungsfall eingerichtet (FMT_MOF.1/NK.TLS, FMT_SMR.1./NK). 7.2. Sicherheitsfunktionen des Anwendungskonnektors Die funktionalen Sicherheitsanforderungen werden im Folgenden nach funktionalen Gruppen gegliedert. Die funktionalen Gruppen orientieren sich an den in Abschnitt 6.3 beschriebenen Sicherheitsanforderungen, insbesondere der in Kapitel 6.3.3 definierten Dienste (hier nur kurz in Stichworten rekapituliert): - AK.Identifikation und Authentisierung: Der Konnektor setzt unterschiedliche Mechanismen zur Identifikation und Authentisierung von Benutzern um. - AK.Zugriffskontrolldienst: Durch den Zugriffskontrolldienst wird eine Prüfung auf Zugriffsberechtigung für die angeforderten Ressourcen durchgeführt. - AK.Kartenterminaldienst: Der Kartenterminaldienst managt alle vom Konnektor adressierbaren Kartenterminals. - AK.Chipkartendienst: Der Chipkartendienst managt alle in den angeschlossenen Kartenterminals gesteckten Karten. - AK.Signaturdienst: Der Signaturdienst bietet Clientsystemen und Fachmodulen eine Schnittstelle zum Signieren von Dokumenten und Prüfen von Dokumentensignaturen. - AK.Software-Update: Der Konnektor ermöglicht das Einspielen von Software Updates - AK.Verschlüsselungsdienst: Der Verschlüsselungsdienst bietet Schnittstellen zum hybriden und symmetrischen Ver- und Entschlüsseln von Dokumenten an - AK.TLS-Kanäle: Der Netzkonnektor stellt dem Anwendungskonnektor TLS-Kanäle zur Verfügung. Die Verwaltung von TLS-Kanälen wird durch den Anwendungskonnektor durchgeführt. - AK.Sicherer Datenspeicher: Der Konnektor stellt ein Datenspeicher zur Verfügung, in welchem der alle sicherheitskritischen, veränderlichen Daten dauerhaft speichert werden, die für seinen Betrieb relevant sind - AK.Fachmodul VSDM: Das Versicherten Stammdaten Management Fachmodul ermöglicht es Versichertenstammdaten der eGK zu verwalten. - AK.Sicherheitsmanagement: Über die Managementschnittstelle kann der Konnektor administriert werden. Security Target secunet konnektor 2.1.0 Seite 366 von 424 secunet - AK.Schutz der TSF: Der Konnektor setzt verschiedene Mechanismen zum Schutz der TSF um. - AK.Sicherheitsprotokollierung: Der Konnektor führt eine Protokollierung im Sicherheits-Log. 7.2.1. AK.Identifikation und Authentisierung Der Konnektor setzt unterschiedliche Mechanismen zur Identifikation und Authentisierung von Benutzern um (FIA_UAU.5/AK). Funktionalität des Konnektors die vor der Identifikation und Authentisierung von Benutzern ausgeführt werden kann ist sind in FIA_UAU.1/AK und FIA_UID.1/AK definiert Die Management-Schnittstelle des Konnektors durch Passworteingabe vor unautorisiertem Zugriff geschützt (FIA_SOS.1/AK.Passwörter) Die folgenden Anforderungen nach [27], TIP1- A_4808 werden vom Konnektor an die Administrator Passwörter gestellt: Für die Passworterstellung setzt der Konnektor folgende Anforderungen um:  dem Benutzer ist es möglich sein, die Zeichen eines Passworts aus den Zeichenklassen Großbuchstaben, Kleinbuchstaben, Sonderzeichen und Ziffern zu wählen. Ein Passwort muss Zeichen aus mindestens drei dieser Zeichenklassen enthalten.  ein Passwort muss mindestens 8 Zeichen lang sein  ein Passwort darf nicht die zugehörige Benutzerkennung enthalten (weder vorwärts noch rückwärts, bei Vergleich unter Ignorierung der Groß- und Kleinschreibung)  die Wiederholung alter Passwörter beim Passwortwechsel durch den Benutzer selbst wird vom Konnektor verhindert (Passworthistorie). Dazu erkennt der Konnektor die letzten drei Passwörter eines Benutzers bei der Passwortneuvergabe und lehnt diese als neues Passwort ab. Für die Passwortverarbeitung setzt der Konnektor folgende Anforderungen um:  für die Erstanmeldung neuer Benutzer werden Einmalpasswörter vergeben, also Passwörter, die nach einmaligem Gebrauch gewechselt werden müssen. Gleiches gilt, wenn ein Passwort eines Benutzers vom Super-Admin zurückgesetzt wird.  jeder Benutzer kann sein eigenes Passwort jederzeit ändern  bei der Eingabe wird das Passwort nicht im Klartext auf dem Bildschirm angezeigt  die Passwörter werden im Konnektor zugriffssicher gespeichert  der Konnektor initiiert nach einem durch den Super-Admin konfigurierbaren Zeitraum (Voreinstellung: 120 Tage) einen Passwortwechsel beim nächsten Login  erfolglose Anmeldeversuche werden mit einer Fehlermeldung ohne Angabe von näheren Einzelheiten abgelehnt. Insbesondere wird bei erfolglosen Anmeldeversuchen nicht erkennbar, ob der eingegebene Benutzername oder das eingegebene Passwort (oder beides) falsch ist.  Nach einer Fehleingabe des Passworts erfolgt eine Verzögerung bis zur nächsten Eingabemöglichkeit des Passworts für dieselbe Benutzerkennung. Die Verzögerung beträgt 3 Sekunden. Security Target secunet konnektor 2.1.0 secunet Seite 367 von 424 Im Rahmen des Pairing eines eHealth Kartenterminals generiert der Konnektor das „pairing secret“ mit hinreichend großer Entropie (FIA_SOS.2/AK.PairG). Wird ein angeschlossenes Kartenterminal für Stapelsignaturen verwendet fordert der Konnektor die Übertragung der DTBS über einen sicheren Kanal der mittels card-to-card authentication mit dem HBA ausgehandelt wird (FIA_API.1/AK). 7.2.2. AK.Zugriffsberechtigungsdienst Der Zugriffsberechtigungsdienst (oder Zugriffskontrolldienst) ist ein interner Dienst des Konnektors der automatisch bei Aufruf einer Operation des Konnektors durch das Clientsystem umgesetzt wird. Durch den Zugriffskontrolldienst wird eine Prüfung auf Zugriffsberechtigung für die angeforderten Ressourcen durchgeführt. Die erlaubten Zugriffsmöglichkeiten werden über ein Informationsmodell (kurz Infomodell) definiert (FDP_ACC.1/AK.Infomod FDP_ACF.1/AK.Infomod). Durch das Infomodell werden Mandanten definiert und Clientsysteme sowie die vom Konnektor verwalteten externen Ressourcen (Kartenterminal mit Slots, Arbeitsplatz, SMC-Bs) zugeordnet. Die entsprechenden Zuordnungen werden durch einen Administrator eingestellt (FMT_MSA.3/AK.Infomod, FMT_MSA.1/AK.Infomod) und beinhalten die erlaubten Zugriffswege vom Clientsystem über Arbeitsplatz zum Kartenterminal und dessen Slots. 7.2.3. AK.Kartenterminaldienst Die Aufgabe des Kartenterminaldienstes ist das Management aller vom Konnektor adressierbaren Kartenterminals. Dabei kapselt der Kartenterminaldienst die Zugriffe auf Kartenterminals durch Basisdienste und Fachmodule (FDP_ACC.1/AK.eHKT, FDP_ACF.1/AK.eHKT). Über den Kartenterminaldienst können TLS Kanale zu den KTs auf und abgebaut werden sowie SICCT- Kommandos gesendet und empfangen werden. Der Anwendungskonnektor kommuniziert mit den konfigurierten eHealth-Kartenterminals über TLS-Kanäle (FDP_UCT.1/AK.TLS, FDP_UIT.1/AK.TLS). Der Netzkonnektor stellt diese Kommunikationskanäle kontrolliert dem Anwendungskonnektor zur Verfügung. Informationen über die Arbeitsplatzkonfiguration eines angeschlossenen Kartenterminals können vom Kartenterminaldienst ausgegeben werden (FMT_MTD.1/AK.eHKT_Abf) Nur der Administrator darf diese Daten auch verändern(FMT_MTD.1/AK.eHKT_Mod). 7.2.4. AK.Kartendienst Die eHealth-Kartenterminals unter der Steuerung des Anwendungskonnektors können verschiedene Chipkarten, KVK, eGK, SMC-B und HBA aufnehmen. Die in den eHealth- Kartenterminals eines Arbeitsplatzes gesteckten Chipkarten mit ihren logischen Kanälen bilden einen dynamischen Kontext (s. [27]). Die Identifikation dieser Chipkarten erfolgt durch Kartenhandles. Der EVG stellt Sicherheitsfunktionen des Chipkartendienstes anderen Diensten, dem Clientsystembereit oder Fachmodulen bereit (FDP_ACC.1/AK.KD). Dazu gehören der Aufbau und die Verwaltung logischer Kanäle und die Kommunikation mit der Karte via Chipkartenkommandos. Der Chipkartendienst regelt dabei den Zugriff auf die Chipkarten für die verschiedenen Dienste und Anwender (FDP_ACF.1/AK.KD). Zudem wird durch den Chipkartendienst die lokale und entfernet PIN Eingabe an den Kartenterminals umgesetzt (FDP_ACC.1/AK.PIN) und die unterschiedlichen Anforderungen an lokale und entfernet PIN Security Target secunet konnektor 2.1.0 Seite 368 von 424 secunet Eingabe und der damit verbundene Umgang mit den Authentisierungsverifikationsdaten (VAD) geregelt (FDP_ACF.1/AK.PIN). In FMT_MSA.4/AK werden übergreifende Anforderungen an den Chipkartendienst definiert. Daten einer eGK werden nicht über den Steckzyklus der Karte hinaus im EVG gespeichert. Daten von HBA und SM-B werden nicht länger als 24 Stunden im EVG zwischengespeichert. Dabei werden sensitive Daten mit konstanten oder zufälligen Werten überschrieben, sobald sie nicht mehr verwendet werden (FDP_RIP.1/AK) 7.2.5. AK.Signaturdienst Der Signaturdienst bietet Clientsystemen und Fachmodulen eine Schnittstelle zum Signieren von Dokumenten (FDP_ACC.1/AK.Sgen, FDP_ACF.1/AK.Sgen) und Prüfen von Dokumentensignaturen (FDP_ACC.1/AK.SigPr, FDP_ACF.1/AK.SigPr). Die zu signierenden oder zu prüfenden Daten werden vom Konnektor entsprechend der referenzierten Signaturrichtlinie behandelt. Dabei wird bei Import dieser Daten die angegebene Signaturrichtlinie auf Zulässigkeit geprüft (FDP_ITC.2/AK.Sig, FMT_MSA.3/AK.Sig). Die Plattform des Konnektors stellt selbst keine Signaturrichtlinien bereit. Das unterstützte Fachmodul NFDM bringt eine entsprechende Signaturrichtlinie in den Konnektor ein. In FMT_MSA.4/AK werden übergreifende Anforderungen an den Signaturdienst definiert. Der Signaturdienst umfasst die Funktionalität der nicht-qualifizierten elektronischen Signatur (nonQES) gemäß gültiger Signaturrichtlinie mit Hilfe der vom Chipkartendienst verwalteten Chipkarten. (FDP_DAU.2/AK.Sig). Zudem können qualifizierte elektronische Signaturen (QES) mit Hilfe der qualifizierten Signaturerstellungseinheit (QSEE) erzeugt werden (FDP_DAU.2/AK.QES). Der HBA (bzw. HBA-Vorläuferkarten) als Teil der QSEE wird vom Chipkartendienst verwalteten. Die zu signierenden Daten werden vom Konnektor an die entsprechende Chipkarte übertragen (FTP_ITC.1/AK.QSEE). Veränderungen an den zu signierenden Daten ab der Übergabe durch den EVG bei Aufruf des Signierdienstes bis zur Rückgabe der signierten Daten an den EVG können durch eine Gegenprüfung der erhaltenen Signatur durch den EVG festgestellt werden (FDP_SDI.2/AK). Der EVG unterstützt die „Komfortsignatur“. Diese Funktionalität wird wie folgt umgesetzt (A_19102-04 und A_19103-06): Wenn die Komfortsignatur für eine HBA-Kartensitzung aktiviert ist (SAK_COMFORT_SIGNATURE=enabled und Komfortsignatur-Modus aktiv) , wird der Authentisierungssatus der HBA-Kartensitzung erst dann zurückgesetzt, wenn eine konfigurierte Anzahl an einzelnen Signaturoperation durchgeführt wurde (SAK_COMFORT_SIGNATURE_MAX, Default=100, A_19100) oder ein konfigurierter Zeitwert abgelaufen ist (SAK_COMFORT_SIGNATURE_TIMER, Default=6h, A_18686-01). Die Konfigurationswerte für das Aktivieren der Komfortsignatur-Funktionalität, für den Timer und für den Zähler können nur vom Administrator verwaltet werden (TIP1-A_4680-03). Zudem wird der Authentisierungssatus aller HBAs bzw. HBA-Kartensitzungen bei Deaktivierung durch die Operation DeactiveComfortSignature oder direkt durch Deaktivierung des Komfortsignatur-Modus in der Managementoberfläche (SAK_COMFORT_SIGNATURE=disabled) zurückgesetzt. Zudem wird bei Aktivierung der Komfortsignatur die übermittelte UserID auf Eindeutigkeit in Bezug auf die letzten 1000 Aufrufe (A_20074) und auf korrekte Länge (128 Bit) und Format Security Target secunet konnektor 2.1.0 secunet Seite 369 von 424 RFC4122 geprüft (A_20073-01). Diese UserID ist als Authentisierungsgeheimnis zu behandeln und wird nicht vom Konnektor ausgegeben. Der TOE setzt entsprechend FDP_ACF.1.2/AK.Infomod (TIP1-A_4524-02) durch die Prüfung des Aufrufkontext durch, dass nur der Nutzer Komfortsignatur-Aufträge auslösen kann (SignDocument und TUC_KON_170), der die selbe UserID präsentiert, wie diese beim Aktivieren des Komfortsignatur-Modus für diese HBA-Kartensitzung (ActivateComfortSignature) präsentiert wurde. Schlägt die Prüfung fehl, wird die Operation abgebrochen. Die eigentliche Authentifizierung des Nutzers beim Auslösen der Komfortsignatur erfolgt außerhalb des TOE im Clientsystem. Es erfolgt ein entsprechender Hinweis im Handbuch bezüglich der Notwendigkeit und Bedeutung der Nutzer-Authentisierung, A_19101. Der Signaturdienst unterstützt die folgenden Signaturformate für nonQES und QES:  XAdES für XML Dokumente (Nur QES mit NFDM-Signaturrichtlinie),  CAdES für XML, PDF/A, Text und TIFF Dokumente  PAdES für PDF/A Dokumente. Darüber hinaus wird für nonQES das folgende Signaturformat unterstützt  CAdES für Binärdokumente Zudem wird für nonQES und QES PKCS#1 ECDSA, RSASSA-PSS und RSASSA-PKCS1-v.5 unterstützt. Das Prüfen von Dokumentensignaturen erfolgt anhand von Zertifikaten (FDP_DAU.2/AK.Cert). Bei Feststellung ungültig erzeugter Signaturen wird der Benutzer entsprechend durch eine Warnmeldung benachrichtigt (FTA_TAB.1/AK.SP) Der Benutzer des Clientsystems muss seine Signatur-PIN an einem Kartenterminal eingeben. Über das Clientsystem wird die gültige Signaturrichtlinie für zu signierende Daten und der angegebener Zeitpunkt signierter Daten für die Signaturprüfung über die Aufruf-Parameter der Entsprechenden Operationen an der Schnittstelle des EVG übergeben (FMT_MSA.1/AK.User) Der Konnektor generiert bei bestimmten PIN-Verifikationen vor der Aufforderung zur PIN- Eingabe an einem eHealth-Kartenterminal eine eindeutige sechsstellige Jobnummer (FIA_SOS.2/AK.Jobnummer), welche den Auftrag kennzeichnet, für dessen Verarbeitung die PIN-Eingabe erfolgen soll. Diese Jobnummer wird vom Konnektor im Display des eHealth- Kartenterminals neben der PIN-Eingabeaufforderung angezeigt (FTA_TAB.1/AK.Jobnummer). Im Folgenden werden die für Signatur-Erstellung und Verifikation verwendeten Algorithmen angegeben: Erzeugung der DTBS:  SHA-256, SHA-384 und SHA-512 (FCS_COP.1/AK.SHA) Signatur Verifikation:  RSASSA-PKCS1-v1_5 signature verification mit 1976 Bit bis 4096 Bit (FCS_COP.1/AK.SigVer.SSA)  RSASSA-PSS signature verification 1976 Bit bis 4096 Bit (FCS_COP.1/AK.SigVer.PSS) Security Target secunet konnektor 2.1.0 Seite 370 von 424 secunet  ECDSA mit 256 bit (FCS_COP.1/AK.SigVer.ECDSA) Erzeugung von Dokumenten-Signaturen:  XAdES with SHA-256 (FCS_COP.1/AK.XML.Sign)  CAdES with SHA-256 (FCS_COP.1/AK.CMS.Sign)  PAdES (PDF/A) with SHA-256 (FCS_COP.1/AK.PDF.Sign) Dokumentensignaturen werden mit Unterstützung der Signatur Smartcards (z.B. HBA) erzeugt. Die DTBS wird mit SHA-256 vom EVG erzeugt. Die Signaturberechnung wird von der Signaturkarte durch RSA mit PKCS#1v2.2 PSS erzeugt. Verifikation von Dokumenten-Signaturen:  XAdES (FCS_COP.1/AK.XML.SigPr)  CAdES (FCS_COP.1/AK.CMS.SigPr)  PAdES (FCS_COP.1/AK.PDF.SigPr jeweils mit  SHA-256, SHA-384 oder SHA-512 für RSASSA-PKCS1-v1_5 oder RSASSA-PSS mit1976 Bit bis 4096 Bit Schlüssellänge  SHA-256 für ECDSA mit 256 Bit Schlüssellänge Geheime Kryptographische Schlüssel, zu signierende Daten und signierte Daten werden nach Verwendung durch den Konnektor unzugänglich gemacht (FDP_RIP.1/AK) 7.2.6. AK.Software-Update Signierte Update-Pakete werden importiert und im Datenspeicher des EVG abgelegt. Sobald ein Update-Paket zur Verfügung steht signalisiert der TOE das ein Software Update zur Verfügung steht. Der Administrator kann die Version des Update-Paketes prüfen und den Updateprozess anstoßen (FDP_ACC.1/AK.Update). Automatische Installation von Software Updates wird vom EVG unterstützt. Zudem dürfen von Anwendungskonnektor und Netzkonnektor nur Update-Pakete übernommen werden, deren Signatur erfolgreich geprüft wurde. Die Firmwaregruppe des Updates muss gleich oder höher der gegenwärtig installierten Firmwaregruppe sein (FDP_ACF.1/AK.Update). Der Updateprozess verhindert, dass manipulierte Update-Pakete eingespielt werden können (FDP_UIT.1/AK.Update), siehe auch „Software Update“ in Kapitel 7.1.6. Fachmodule können nur im Rahmen von Software-Updates des Konnektors aktualisiert oder eingebracht werden. 7.2.7. AK.Verschlüsselungsdienst Der Verschlüsselungsdienst bietet Schnittstellen zum hybriden und symmetrischen Ver- und Entschlüsseln von Dokumenten an (FDP_ACC.1/AK.Enc, FDP_ACF.1/AK.Enc). In Security Target secunet konnektor 2.1.0 secunet Seite 371 von 424 FMT_MSA.4/AK werden übergreifende Anforderungen an den Verschlüsselungsdienst definiert. Der Verschlüsselungsdienst bietet für XML, PDF/A, Text, TIFF und Binärdaten die hybride Ver- /Entschlüsselung nach dem CMS Standard [RFC5652] bzw. die symmetrische Ver- /Entschlüsselung mittels AES-GCM an. Zudem wird für XML-Dokumente die hybride Ver- /Entschlüsselung nach [XMLEnc] unterstützt. Dem Konnektor werden durch das Clientsystem die zu verschlüsselnden und zu entschlüsselnden Dokumente übergeben, die zu verwendende Verschlüsselungsrichtlinie durch den Fachdienst bzw. den Anwendungsfall identifiziert und beim Verschlüsseln eines Dokuments die vorgeschlagenen Empfänger des Dokuments angegeben. Vor dem Verschlüsseln eines Dokuments wird die Gültigkeit der zu benutzenden Verschlüsselungszertifikate geprüft. (FDP_ITC.2/AK.Enc, FDP_ETC.2/AK.Enc). Im Folgenden werden die für die Ver- und Entschlüsselung verwendeten Algorithmen angegeben: Symmetrische Ver- und Entschlüsselung:  AES-GCM mit 128 bit, 192 bit and 256 bit (FCS_COP.1/AK.AES) Hybride Ver- und Entschlüsselung:  XML-Dokumente: RSAOAEP mit 2048 Bit Schlüssellänge oder ECIES mit 256 Bit Schlüssellänge und AES-GCM mit 128 Bit, 192 Bit und 256 Bit Schlüssellänge und 128 Bit GMAC (FCS_COP.1/AK.XML.Ver, FCS_COP.1/AK.XML.Ent)  XML, PDF/A, Text, TIFF und Binärdaten: RSAOAEP mit 2048 Bit Schlüssellänge oder ECIES mit 256 Bit Schlüssellänge und AES-GCM mit 128 Bit, 192 Bit und 256 Bit Schlüssellänge und 128 Bit (FCS_COP.1/AK.CMS.Ver, FCS_COP.1/AK.CMS.Ent) Dabei wird die hybride Verschlüsselung auf AES-GCM mit 256 Bit Schlüssellänge beschränkt. Für die Entschlüsselung wird AES-GCM mit 128 Bit, 192 Bit und 256 Bit Schlüssellänge unterstützt. Der EVG erzeugt die AES Schlüssel (FCS_CKM.1/AK.AES) und löscht diese nach Verwendung sicher (FCS_CKM.4/AK). Geheime Kryptographische Schlüssel, zu verschlüsselnde Daten, verschlüsselte Daten, vorgeschlagene Empfänger und entschlüsselte Daten werden nach Verwendung durch den Konnektor unzugänglich gemacht (FDP_RIP.1/AK) 7.2.8. AK.TLS-Kanäle Der Netzkonnektor stellt dem Anwendungskonnektor TLS-Kanäle zur Verfügung, siehe 7.1.8 NK.TLS-Kanäle unter Nutzung sicherer kryptographischer Algorithmen. Die Verwaltung von TLS-Kanälen wird duch den Anwendungskonnektor durchgeführt. Security Target secunet konnektor 2.1.0 Seite 372 von 424 secunet Der Anwendungskonnektor initiiert dabei entsprechende der Vorgaben in Tabelle 24 den Auf- und Abbau der TLS-Kanäle und stellt den Endpunkt für das Senden und Empfangen der Nutzdaten dar (FDP_ACC.1/AK.TLS, FDP_ACF.1/AK.TLS). Für das VSDM Fachmodul wird zudem TLS Session Resumption unterstützt. Der Administrator kann konfigurieren, ob für Verbindungen zum Clientsystem TLS-Kanäle verwendet werden müssen (ANCL_TLS_MANDATORY, ANCL_CAUT_MANDATORY) und einen Zertifikatsbasierten oder Passwortbasierten Authentisierungsmechanismus (ANCL_CAUT_MODE) festlegen. (FMT_MSA.1/AK.TLS, FMT_MSA.3/AK.TLS). Für den Dienstverzeichnisdienst kann die explizit die verpflichtende Nutzung von TLS deaktiviert werden (ANCL_DVD_OPEN). TLS Kanäle werden für die Kommunikation mit Fachdiensten (FTP_ITC.1/AK.FD), mit dem zentralen Verzeichnisdienst (FTP_ITC.1/AK.VZD), dem KSR (FTP_ITC.1/AK.KSR), dem TSL-Dienst (FTP_ITC.1/AK.TSL), bei ANCL_TLS_MANDATORY = Enabled mit den Clientsystemen im LAN (FTP_ITC.1/AK.CS) und mit den angebundene eHealth Kartenterminals (FTP_ITC.1/AK.eHKT) verwendet. Benutzerdaten, die über den TLS-Kanal zwischen EVG und eHealth-Kartenterminals übermittelt wurden, werden nach Verwendung durch den Konnektor unzugänglich gemacht (FDP_RIP.1/AK). 7.2.9. AK.Sicherer Datenspeicher Der Konnektor stellt einen Datenspeicher zur Verfügung, in welchem er alle sicherheitskritischen, veränderlichen Daten dauerhaft speichert, die für seinen Betrieb relevant sind (FDP_ACC.1/AK.SDS, FDP_ACF.1/AK.SDS). Dieser Datenspeicher sichert die Integrität, Authentizität und Vertraulichkeit der in ihm hinterlegten Daten bzw. der aus ihm entnommenen Daten. Der Konnektor stellt den in ihm laufenden Fachmodulen ebenfalls eine Nutzung dieses Datenspeichers für ihre sensiblen Daten zur Verfügung. Es werden keine Datenobjekte mit dem Sicherheitsattribut „Administratorobjekt“ verwaltet. 7.2.10. AK.Fachmodul VSDM Das Versicherten Stammdaten Management (VSDM) Fachmodul ist fester Bestandteil des EVGs und ermöglicht es, Versichertenstammdaten einer eGK zu lesen, zu schreiben oder um neue Einträge zu ergänzen (FDP_ACC.1/AK.VSDM, FDP_ACF.1/AK.VSDM). Die eGK wird dabei über AK.Kartenterminaldienst und AK.Kartendienst angesprochen. Das VSDM Fachmodul kann über die Management-Oberfläche administriert werden (FMT_MSA.1/AK.VSDM, FMT_MSA.3/AK.VSDM). 7.2.11. AK.Sicherheitsmanagement Der Konnektor verwaltet verschiedene Rollen, wie Administrator, Clientsystem, Kartenterminals und Chipkarten (FMT_SMR.1/AK). Auf die Management Schnittstelle hat nur ein autorisierter Administrator Zugriff. Dieser kann zum Beispiel Kartenterminals managen, Arbeitsplätze konfigurieren, Sicherheitsrichtlinien und TLS-Kanäle verwalten (FMT_SMF.1/AK). Dazu gehört auch das Verwalten von Software Updates für EVG und Security Target secunet konnektor 2.1.0 secunet Seite 373 von 424 angebundene Kartenterminals, Verwalten von Zertifikaten und Durchführen eines Werksreset (FMT_MTD.1/AK.Admin). Insbesondere kann der Administrator die Online-Anbindung des Konnektors im Netz des Leistungserbringers konfigurieren (MGM_LU_ONLINE) und die QES Funktionalität des Signaturdienst de- und aktivieren (MGM_LU_SAK), (FMT_MOF.1/AK). Über die öffentlichen Schlüssel der CVC root CA sind in der gSMC-K gespeichert und können nur durch das CMS System der gSMC-K gelöscht werden. Über cross CVC Zertifikate können durch den Anwendungskonnektor aber weitere öffentlichen Schlüssel der CVC root CA eingebracht werden (FMT_MTD.1/AK.Zert). 7.2.12. AK.Schutz der TSF Der Konnektor kann die für QES und nonQES benötigten Zertifikate interpretieren, sowie Verschlüsselungszertifikat und CV-Zertifikate. Zudem werden Information gültiger TSL und CRL Listen in die Prüfungen einbezogen sowie BNetzA-VL bzw. die entsprechenden Hashwerte (FPT_TDC.1/AK). Die Zulässigkeit importierter zu signierenden bzw. zu prüfender signierten Daten wird gemäß implementierten Signaturrichtlinien geprüft. Durch das Fachmodul NFDM wird eine entsprechende Signaturrichtlinie in den Konnektor eingebracht. Der Konnektor setzt die in [gemSpec_Kon], TAB_KON_503 definierten Fehlbetriebszustände um (Error Condition). Wird ein sicherheitsrelevanter Betriebszustand erreicht, schränkt der Konnektor seine Funktionalität gemäß [gemSpec_Kon], TAB_KON_504 ein (FPT_FLS.1/AK). Vor der regulären Kommunikation mit einem eHealth Kartenterminal wird geprüft, ob dieses gepairt ist und im Infomodell des Konnektors korrekt zugeordnet wurde. Ebenso werden gesteckte Chipkarten identifiziert und auf Gültigkeit geprüft. Bei entfernter PIN-Eingabe wird geprüft ob Kartenterminal und HBA für diesen Verwendungsfall zugelassen sind (FPT_TEE.1/AK), Der Konnektor führt beim Anlauf und regelmäßig während des Normalbetriebs Selbsttests durch (FPT_TST.1/AK.Run-Time), siehe dazu auch „Selbsttests“ in 7.1.5 NK.Selbstschutz. Neben Selbsttests im Rahmen des sicheren Start-Up Prozesse wird insbesondere auch die Implementierung der Trusted Channels (VPN und TLS) beim Hochfahren getestet. Im Normalbetrieb wird regelmäßig der AES und TLS (wie beschrieben in FPT_TST.1/AK.Run- Time) getestet. Durch den sicheren Start-Up Prozesse wird die Integrität des TOEs auf einen sicheren Vertrauensanker im BIOS zurückgeführt. Durch Neustart des Konnektors können die damit verbundenen Prüfungen durch einen Benutzer jederzeit wiederholt werden (FPT_TST.1/AK.Out-Of-Band). Die vom Anwendungskonnektor erzeugten Protokolleinträge des Sicherheitsprotokolls werden mit einem zuverlässigen Zeitstempel versehen (FPT_STM.1/AK). Der Anwendungskonnektor greift dabei auf die Echtzeituhr zurück, die in regelmäßigen Abständen und auf Anforderung des Administrators vom Netzkonnektor mit einem vertrauenswürdigen Zeitdienst synchronisiert wird, siehe auch „Zeitsynchronisation“ in 7.1.3 NK.Netzdienste. 7.2.13. AK.Sicherheitsprotokollierung Der EVG führt ein Sicherheits-Log gemäß Konnektor-Spezifikation [27], Abschnitt 4.1.10, siehe auch „Sicherheits-Log“ in 7.1.5 NK.Selbstschutz. Diese Funktionalität wird vom Security Target secunet konnektor 2.1.0 Seite 374 von 424 secunet Anwendungskonnektor mit FAU_GEN.1/AK umgesetzt. Nur der Administrator kann Protokolleinträge einsehen (FAU_SAR.1/AK). Protokolleinträge können nicht verändert werden und nicht explizit gelöscht werden (FAU_STG.1/AK). Ältere Einträge werden rollierend überschrieben (FAU_STG.4/AK). 7.3. Sicherheitsfunktionen für die ePA Fachanwendung (PTV4) 7.3.1. VAU-Kanal In O.AK.VAUSGD wird gefordert: „Der EVG bietet eine gesicherte Kommunikationsverbindung mittels „VAU-Protokoll“ in die VAU-Instanz des ePA- Aktensystems […], sodass das Abhören von Daten für diese Kommunikation unterbunden ist.“. Genau dies leistet FTP_ITC.1/VAU. Um diesen Trusted Channel sicher aufzubauen, werden Schlüssel von FCS_CKM.1/VAU erzeugt. Die SFR FCS_COP.1/VAU.AES übernimmt die Inhaltsdatenverschlüsselung und FCS_COP.1/VAU.Auth die Authentifikation der Gegenseite für den Kanal. Das SFR FPT_TDC.1/SGDVAU sichert die Authenfizierung mit X.509 Zertifikaten ab. Geheime Schlüssel werden entsprechend FCS_CKM.4/AK gelöscht. 7.3.2. SGD-Kanal In O.AK.VAUSGD wird gefordert: „Der EVG bietet eine gesicherte Kommunikationsverbindung […] mittels „SGD-Protokoll“ in das SGD-HSM des Schlüsselgenerierungsdienst an, sodass das Abhören von Daten für diese Kommunikation unterbunden ist.“. Genau dies leistet FTP_ITC.1/SGD. Der Trusted Channel wird durch die ECIES-Verschlüsselung nach FCS_COP.1/SGD.ECIES umgesetzt. Der öffentliche ECIES- Schlüssel des HSM wird dazu zusammen mit seiner Signatur und dem entsprechenden Zertifikat mittels GetPublicKey Operation eingebracht (FDP_ITC.2/SGD). Die Verwendung des Schlüssels ist nur erlaubt, wenn die Prüfung der Signatur und des Zertifikates erfolgreich sind (FDP_ACC.1/SGD, FDP_ACF.1/SGD). FCS_COP.1/SGD.Auth fordert die Authentifikation der Gegenseite für den Kanal. Das SFR FPT_TDC.1/SGDVAU sichert die Authenfizierung mit X.509 Zertifikaten ab. Geheime Schlüssel werden entsprechend FCS_CKM.4/AK gelöscht. 7.4. Abbildung der Sicherheitsfunktionalität auf Sicherheitsanforderungen Tabelle 31 und Tabelle 32 im folgenden Abschnitt 7.4.1 stellen die Abbildung der Sicherheitfunktionlität auf Sicherheitsanforderungen zunächst tabellarisch im Überblick dar. In Abschnitt 7.4.2 wird die Abbildung erläutert und die Umsetzung der Anforderungen durch die Sicherheitsfunktionalität begründet. Security Target secunet konnektor 2.1.0 secunet Seite 375 von 424 7.4.1. Überblick Sicherheitsanforderung des Netzkonnektors an den EVG 7.1.1 NK.VPN-Client 7.1.2 NK.Dynamischer Paketfilter 7.1.3 NK.Netzdienste 7.1.4 NK.Stateful Packet Inspection 7.1.5 NK.Selbstschutz 7.1.6 NK.Administration 7.1.7 NK.Kryptographische Basisdienste 7.1.8 NK.TLS-Kanäle unter Nutzung sicherer kryptographischer FTP_ITC.1/NK.VPN_TI X FTP_ITC.1/NK.VPN_SIS X FDP_IFC.1/NK.PF X FDP_IFF.1/NK.PF X X FMT_MSA.3/NK.PF X FMT_MSA.1/NK.PF X FPT_STM.1/NK X FPT_TDC.1/NK.Zert X FDP_RIP.1/NK X FPT_TST.1/NK X FPT_EMS.1/NK X FAU_GEN.1/NK.SecLog X FAU_GEN.2/NK.SecLog X FMT_SMR.1./NK X FMT_MTD.1/NK X FIA_UID.1/NK.SMR X FIA_UAU.1/NK.SMR X FTP_TRP.1/NK.Admin X FMT_SMF.1/NK X FCS_COP.1/NK.Hash X FCS_COP.1/NK.HMAC X FCS_COP.1/NK.Auth X FCS_COP.1/NK.ESP X FCS_COP.1/NK.IPsec X FCS_CKM.1/NK X FCS_CKM.2/NK.IKE X FCS_CKM.4/NK X FDP_ACC.1/NK.Update X FDP_ACF.1/NK.Update X FDP_ITC.1/NK.Update X FDP_UIT.1/NK.Update X FTP_ITC.1/NK.TLS X FPT_TDC.1/NK.TLS.Zert X FCS_CKM.1/NK.TLS X FCS_COP.1/NK.TLS.HMAC X FCS_COP.1/NK.TLS.AES X FCS_COP.1/NK.TLS.Auth X Security Target secunet konnektor 2.1.0 Seite 376 von 424 secunet Sicherheitsanforderung des Netzkonnektors an den EVG 7.1.1 NK.VPN-Client 7.1.2 NK.Dynamischer Paketfilter 7.1.3 NK.Netzdienste 7.1.4 NK.Stateful Packet Inspection 7.1.5 NK.Selbstschutz 7.1.6 NK.Administration 7.1.7 NK.Kryptographische Basisdienste 7.1.8 NK.TLS-Kanäle unter Nutzung sicherer kryptographischer FCS_CKM.1/NK.Zert X FDP_ITC.2/NK.TLS X FDP_ETC.2/AK.Enc X FMT_MOF.1/NK.TLS X Tabelle 31: Abbildung der Sicherheitsfunktionalität auf Sicherheitsanforderungen des Netzkonnektors Sicherheitsanforderung des Anwendungskonnektors an den EVG 7.2.1 AK.Identifikation und Authentisierung 7.2.2 AK.Zugriffsberechtigungsdienst 7.2.3 AK.Kartenterminaldienst 7.2.4 AK.Kartendienst 7.2.5 AK.Signaturdienst 7.2.6 AK.Software-Update 7.2.7 AK.Verschlüsselungsdienst 7.2.8 AK.TLS-Kanäle 7.2.9 AK.Sicherer Datenspeicher 7.2.10 AK.Fachmodul VSDM 7.2.11 AK.Sicherheitsmanagement 7.2.12 AK.Schutz der TSF 7.2.13 AK.Sicherheitsprotokollierung FAU_GEN.1/AK X FAU_SAR.1/AK X FAU_STG.1/AK X FAU_STG.4/AK X FCS_CKM.1/AK.AES X FCS_CKM.4/AK X FCS_COP.1/AK.AES X FCS_COP.1/AK.CMS.Ent X FCS_COP.1/AK.CMS.SigPr X FCS_COP.1/AK.CMS.Sign X FCS_COP.1/AK.CMS.Ver X FCS_COP.1/AK.PDF.SigPr X FCS_COP.1/AK.PDF.Sign X FCS_COP.1/AK.SigVer.ECDSA X FCS_COP.1/AK.SigVer.PSS X FCS_COP.1/AK.SigVer.SSA X FCS_COP.1/AK.SHA X Fehler! Verweisquelle konnte nicht gefunden werden. X Fehler! Verweisquelle konnte nicht gefunden werden. X Security Target secunet konnektor 2.1.0 secunet Seite 377 von 424 Sicherheitsanforderung des Anwendungskonnektors an den EVG 7.2.1 AK.Identifikation und Authentisierung 7.2.2 AK.Zugriffsberechtigungsdienst 7.2.3 AK.Kartenterminaldienst 7.2.4 AK.Kartendienst 7.2.5 AK.Signaturdienst 7.2.6 AK.Software-Update 7.2.7 AK.Verschlüsselungsdienst 7.2.8 AK.TLS-Kanäle 7.2.9 AK.Sicherer Datenspeicher 7.2.10 AK.Fachmodul VSDM 7.2.11 AK.Sicherheitsmanagement 7.2.12 AK.Schutz der TSF 7.2.13 AK.Sicherheitsprotokollierung FCS_COP.1/AK.XML.Ent X FCS_COP.1/AK.XML.Sign X FCS_COP.1/AK.XML.SigPr X FCS_COP.1/AK.XML.Ver X FDP_ACC.1/AK.eHKT X FDP_ACC.1/AK.Enc X FDP_ACC.1/AK.Infomod X FDP_ACC.1/AK.KD X FDP_ACC.1/AK.PIN X FDP_ACC.1/AK.Sgen X FDP_ACC.1/AK.SigPr X FDP_ACC.1/AK.TLS X FDP_ACC.1/AK.SDS X FDP_ACC.1/AK.Update X FDP_ACC.1/AK.VSDM X FDP_ACF.1/AK.eHKT X FDP_ACF.1/AK.Enc X FDP_ACF.1/AK.Infomod X FDP_ACF.1/AK.KD X FDP_ACF.1/AK.PIN X FDP_ACF.1/AK.Sgen X FDP_ACF.1/AK.SigPr X FDP_ACF.1/AK.TLS X FDP_ACF.1/AK.SDS X FDP_ACF.1/AK.Update X FDP_ACF.1/AK.VSDM X FDP_DAU.2/AK.Cert X FDP_DAU.2/AK.QES X FDP_DAU.2/AK.Sig X FDP_ETC.2/AK.Enc X FDP_ITC.2/AK.Enc X FDP_ITC.2/AK.Sig X FDP_RIP.1/AK X X X X FDP_SDI.2/AK X FDP_UCT.1/AK.TLS X Security Target secunet konnektor 2.1.0 Seite 378 von 424 secunet Sicherheitsanforderung des Anwendungskonnektors an den EVG 7.2.1 AK.Identifikation und Authentisierung 7.2.2 AK.Zugriffsberechtigungsdienst 7.2.3 AK.Kartenterminaldienst 7.2.4 AK.Kartendienst 7.2.5 AK.Signaturdienst 7.2.6 AK.Software-Update 7.2.7 AK.Verschlüsselungsdienst 7.2.8 AK.TLS-Kanäle 7.2.9 AK.Sicherer Datenspeicher 7.2.10 AK.Fachmodul VSDM 7.2.11 AK.Sicherheitsmanagement 7.2.12 AK.Schutz der TSF 7.2.13 AK.Sicherheitsprotokollierung FDP_UIT.1/AK.TLS X FDP_UIT.1/AK.Update X FIA_API.1/AK X FIA_SOS.1/AK.Passwörter X FIA_SOS.2/AK.Jobnummer X FIA_SOS.2/AK.PairG X FIA_UAU.1/AK X FIA_UAU.5/AK X FIA_UID.1/AK X FMT_MSA.1/AK.User X FMT_MSA.1/AK.Infomod X FMT_MSA.3/AK.Infomod X FMT_MSA.1/AK.TLS X FMT_MSA.3/AK.TLS X FMT_MSA.1/AK.VSDM X FMT_MSA.3/AK.VSDM X FMT_MSA.3/AK.Sig X FMT_MSA.4/AK X X X FMT_MOF.1/AK X FMT_MTD.1/AK.Admin X FMT_MTD.1/AK.Zert X FMT_MTD.1/AK.eHKT_Abf X FMT_MTD.1/AK.eHKT_Mod X FMT_SMF.1/AK X FMT_SMR.1/AK X FPT_FLS.1/AK X FPT_STM.1/AK X FPT_TDC.1/AK X FPT_TEE.1/AK X FPT_TST.1/AK.Out-Of-Band X FPT_TST.1/AK.Run-Time X FTA_TAB.1/AK.Jobnummer X FTA_TAB.1/AK.SP X FTP_ITC.1/AK.CS X FTP_ITC.1/AK.eHKT X Security Target secunet konnektor 2.1.0 secunet Seite 379 von 424 Sicherheitsanforderung des Anwendungskonnektors an den EVG 7.2.1 AK.Identifikation und Authentisierung 7.2.2 AK.Zugriffsberechtigungsdienst 7.2.3 AK.Kartenterminaldienst 7.2.4 AK.Kartendienst 7.2.5 AK.Signaturdienst 7.2.6 AK.Software-Update 7.2.7 AK.Verschlüsselungsdienst 7.2.8 AK.TLS-Kanäle 7.2.9 AK.Sicherer Datenspeicher 7.2.10 AK.Fachmodul VSDM 7.2.11 AK.Sicherheitsmanagement 7.2.12 AK.Schutz der TSF 7.2.13 AK.Sicherheitsprotokollierung FTP_ITC.1/AK.FD X FTP_ITC.1/AK.QSEE X FTP_ITC.1/AK.VZD X FTP_ITC.1/AK.KSR X FTP_ITC.1/AK.TSL X Tabelle 32: Abbildung der Sicherheitsfunktionalität auf Sicherheitsanforderungen des Anwendungskonnektors Sicherheitsanforderung für die ePA Fachanwendung an den EVG 7.3.1 VAU-Kanal 7.3.2 SGD-Kanal FTP_ITC.1/VAU X FCS_CKM.1/VAU X FCS_COP.1/VAU.AES X FCS_COP.1/VAU.Auth X FTP_ITC.1/SGD X FCS_COP.1/SGD.ECIES X FCS_COP.1/SGD.Auth X FDP_ITC.2/SGD X FDP_ACC.1/SGD X FDP_ACF.1/SGD X FPT_TDC.1/SGDVAU X X FCS_CKM.4/AK X X Tabelle 33: Abbildung der Sicherheitsfunktionalität auf Sicherheitsanforderungen der ePA Fachanwendung Security Target secunet konnektor 2.1.0 Seite 380 von 424 secunet 7.4.2. Erfüllung der funktionalen Sicherheitsanforderungen Wie aus Tabelle 31, Tabelle 32 und Tabelle 33 ersichtlich, wird jede Sicherheitsanforderung gemäß Kapitel 6.2 bzw. 6.3 durch die Sicherheitsfunktionen in Kapitel 7.1, 7.2 oder 7.3 umgesetzt. Die Beschreibung der Sicherheitsfunktionen in den Kapiteln 7.1.1-7.1.8 und 7.2.1- 7.2.13 sowie 7.3.1-7.3.2 nutzen direkte Referenzen auf die entsprechenden implementierten Sicherheitsfunktionen in Kapiteln 6.2.1-6.2.8 bzw. orientieren sich an der Unterteilung der Kapitel 6.3.1-6.3.7, Insbesondere werden die Dienste aus Kapitel 6.3.3 als Sicherheitsfunktionen modelliert. Die Sicherheitsfunktionen sind damit direkt aus der Unterteilung der Sicherheitsfunktionen des Gesamtkonnektors im Konnektor PP [16] sowie der Erweiterung zu PTV4 abgeleitet. Security Target secunet konnektor 2.1.0 secunet Seite 381 von 424 8. ST-Erweiterung 8.1. Erweiterungen für PTV3, PTV4 und PTV5 Das Protection Profile BSI-CC-PP-0098 [16], das diesem Security Target zugrunde liegt, erfasst alle Sicherheitsanforderungen, die für PTV2 des Konnektors vorgesehen sind. Der EVG setzt jedoch die Anforderungen nach PTV3, PTV4 und PTV5 um (siehe [28]). Da das Protection Profile [16] nicht alle Inhalte aus [28] abdeckt, wurde das vorliegende ST entsprechend erweitert. Die folgenden Tabellen erfassen diese zusätzlichen Sicherheitseigenschaften und gibt eine Erläuterung, wie diese im vorliegenden Security Target erfasst sind. Anforderung aus [28] i.V.m. [27] Zusammenfassung der Anforderung Umsetzung im ST TIP1-A_4710 Medizinische Daten oder personenbezogene Daten (darunter KVNR, ICCSN und CardHolderName) dürfen nicht in Protokolleinträge geschrieben werden. In Anwendungshinweis 203: erfasst. Bereits in BSI-CC-PP-0098 [16] umgesetzt, keine besondere Anpassung in diesem Security Target. TIP1-A_5482 Prüfung von CV-Zertifikaten nach dem Schalenmodell In FPT_TDC.1/AK, Element 1.2, Regel (5), erfasst. Bereits in BSI-CC-PP-0098 [16] umgesetzt, keine besondere Anpassung in diesem Security Target. TIP1-A_5484 Der Konnektor MUSS den Fachmodulen die Möglichkeit bereitstellen, die in den Fachmodulspezifikationen gekennzeichneten Konfigurationsdaten persistent zu speichern, auszulesen und zu löschen. Je Fachmodul muss ein exklusiv durch das Fachmodul nutzbarer Speicherbereich verwendet werden. Seit Version 1.1 der Technischen Richtlinien für die jeweiligen Fachmodule gibt es keine Sicherheitsanforderung bezüglich der Konfigurationsparameter mehr. Das Speichern, Auslesen und löschen von Daten wird durch die Sicherheitsfunktion AK.Sicherer Datenspeicher umgesetzt, TIP1-A_5486 Aktivieren/Deaktivieren des PIN- Schutzes Bereits im BSI-CC-PP-0098 ab Version 1.4 ungesetzt, keine besondere Anpassung in diesem Security Target. Security Target secunet konnektor 2.1.0 Seite 382 von 424 secunet TIP1-A_5505 Kryptographische Prüfung der XML- Dokumentensignatur gemäß TUC_KON_162 Siehe Tabelle 38, TUC_KON_162 TIP1-A_5538 Signaturrichtlinien bei QES für XML-Dokumentenformate In FPT_TDC.1.2/AK (9) wurde die Auswahl „Signaturrichtlinie“ eingeschlossen. Außerdem: Anwendungshinweis 46: und Hinweis darunter. TIP1-A_6025 Zugang zur TI sperren, wenn Deadline für kritische FW-Updates erreicht ist. In FPT_FLS.1.1/AK aufgenommen: Im Fehlerfall EC_FW_Not_Valid_Status_Block ed ist gemäß TAB_KON_504 vorzugehen. TIP1-A_7254 Reaktion auf OCSP-Abfrage beim TLS-Verbindungsaufbau Bemerkung zu Beginn von Abschnitt 6.3.3.7. Siehe auch die Verweise dort. TIP1-A_7255 Anzeige von Fachmodulversionen Siehe Tabelle 39. TIP1-A_7277 Authentifizierung des Remote- Management-Systems Siehe Anwendungshinweis 102: und FIA_UAU.5/AK. TIP1-A_7278 Authentisierung des Konnektors gegenüber Remote-Management- System Der Konnektor authentisiert sich gegenüber dem Remote- Management-System mittels validierten TLS-Zertifikat. TIP1-A_7279 Authentifizierung des Remote- Administrators Siehe FIA_UAU.5/AK. Der Remote Administrator muss sich mittels Username und Password Authentifizieren. TIP1-A_7280 Einschränkung der Rechte des Remote-Administrators Refinement von FMT_MTD.1/AK.Admin GS-A_5484 (gemSpec_PKI ) Aktualisierung der BNetzA-VL Entspricht TIP1-A_6729 von [27] und war schon in PTV2 der CC- Evaluierung zugerechnet. Umgesetzt in BSI-CC-PP-0098. A_16203 Nutzbarkeit im Zustand EC_FIREWALL_NOT_RELIABLE Siehe Anwendungshinweis 198:. GS-A_5081 (gemSpec_Kry pt) Signaturen von PDF/A-Dokumenten (BSI Hinweise: “Nutzung von SHA- 256 statt SHA-1”) Seit Version 2.4.0 (mit Version 0.8 dieses Dokuments ist 2.11.0 der gemSpec_Krypt aktuell) sieht gemSpec_Krypt an dieser Stelle Security Target secunet konnektor 2.1.0 secunet Seite 383 von 424 vor, dass mind. SHA-256 verwendet wird. Daher wird kein Anpassungsbedarf gesehen. Der Wegfall von ISO9796-2 DS2 ist bereits in der Version 1.4 des PP durchgeführt. Tabelle 34: ST-Erweiterung für PTV3 Anforderung aus [28] i.V.m. [27] Zusammenfassung der Anforderung Umsetzung im ST A_17225-01 Aufbau einer sicheren Verbindung zur Vertrauenswürdige Ausführungsumgebung (VAU) Durch O.AK.VAUSGD (Anteil VAU) umgesetzt. A_17548-01 TSL-Signer-CA Zertifikat sicher speichern (ECC-Migration) Siehe Anmerkung 10 A_17549-01 TSL-Signer-CA Cross-Zertifikat im kritischen Betriebszustand (ECC- Migration) Siehe Anmerkung 10 A_17661 Gesicherte Übertragung der Hash- Datei für TSL (ECC-Migration) Siehe Anmerkung 10 und FDP_ACF.1.2/AK.TLS FTP_ITC.1.3/AK.TSL FPT_TDC.1.1/AK (5) A_17746 Einsatzbereich und Vorgaben für Ver- und Entschlüsselung (ECC- Migration) Die kryptographischen SFRs müssen immer den korrekten Algorithmus auswählen, siehe Anmerkung 7. A_17768 Zertifikate und Schlüssel für Signaturerstellung und Signaturprüfung (QES und nonQES) Die kryptographischen SFRs müssen immer den korrekten Algorithmus auswählen, siehe Anmerkung 8. A_17777 sicherheitstechnische Festlegungen zum Abruf von kryptographischen Schlüsseln von einem Schlüsselgenerierungsdienst Durch O.AK.VAUSGD (Anteil SGD) umgesetzt A_17837−01 Nutzung von Cross-Zertifikaten für Vertrauensraum-Wechsel nach ECC- RSA (ECC-Migration) FMT_MTD.1/AK.Zert beschreibt die Nutzung von Cross- Zertifikaten. Das SFR gilt auch für den Vertrauensraum-Wechsel nach ECC-RSA. A_18001 TUC_KON_075 „Symmetrisch verschlüsseln” SFR FCS_COP.1/AK.AES beschreibt die symmetrische Verschlüsslung. Security Target secunet konnektor 2.1.0 Seite 384 von 424 secunet A_18002 TUC_KON_076 „Symmetrisch entschlüsseln” SFR FCS_COP.1/AK.AES beschreibt die symmetrische Entschlüsslung. TIP1−A_4510− 04 Sicherheitskritische Fehlerzustände Abgedeckt durch FPT_FLS.1/AK und dem folgenden Anwendungshinweis 198: TIP1−A_4569− 02 TUC_KON_021 „PIN entsperren“ Ist durchgesetzt durch FDP_ACF.1/AK.PIN. TIP1−A_4616− 02 TUC_KON_070 „Daten hybrid verschlüsseln” Schon durch SFRs für hybride Entschlüsselung umgesetzt. ECC wird unterstützt. TIP1−A_4617− 02 TUC_KON_071 „Daten hybrid entschlüsseln“ Schon durch SFRs für hybride Entschlüsselung umgesetzt. ECC wird unterstützt. TIP1−A_4646− 02 ab PTV4: TUC_KON_155 „Dokumente zur Signatur vorbereiten“ Keine Auswirkung auf die ST Version, da schon in PTV3 umgesetzt TIP1−A_4653− 02 ab PTV4: TUC_KON_160 „Dokumente nonQES signieren“ Schon durch SFRs für Signaturerstellung umgesetzt und ECC wird unterstützt. TIP1−A_4654− 03 TUC_KON_161 „nonQES Dokumentsignatur prüfen” Keine Auswirkung auf die ST Version, da schon in PTV3 umgesetzt TIP1−A_4672− 02 TUC_KON_151 „QES- Dokumentensignatur prüfen“ Keine Auswirkung auf die ST Version, da schon in PTV3 umgesetzt TIP1−A_4785− 03 Konfigurationsparameter VPN- Client Keine Auswirkung auf die ST Version, da schon in PTV3 umgesetzt TIP1−A_4832− 02 TUC_KON_280 „Konnektoraktualisierung durchführen“ Die SFRs FDP_ACC.1/AK.Update und FDP_ACF.1/AK.Update bilden das Update ab. TIP1−A_4839− 01 Festlegung der durchzuführenden Updates Die SFRs FDP_ACC.1/AK.Update und FDP_ACF.1/AK.Update bilden das Update ab. TIP1−A_4840− 01 Manuelles Auslösen der durchzuführenden Updates Die SFRs FDP_ACC.1/AK.Update und FDP_ACF.1/AK.Update bilden das Update ab. TIP1−A_5540− 01 QES-Signaturprüfergebnis bezogen auf Signaturzeitpunkt Siehe Anwendungshinweis 159: TIP1−A_5541− 01 Referenzen in Dokumenten nicht dynamisch auflösen Keine Auswirkung auf die ST Version TIP1−A_5657− 02 Freischaltung von Softwareupdates Die SFRs FDP_ACC.1/AK.Update und FDP_ACF.1/AK.Update bilden Security Target secunet konnektor 2.1.0 secunet Seite 385 von 424 das manuelle und automatische Update ab. A_15549 VAU-Client: Kommunikation zwischen VAU-Client und VAU FTP_ITC.1/VAU setzt die Anforderung um. A_15561 AES-NI Siehe Anwendungshinweis 201: A_16849 VAU-Protokoll: Aktionen bei Protokollabbruch Durch FCS_CKM.4/AK abgedeckt A_16852−01 VAU-Protokoll: ECDH durchführen FTP_ITC.1/VAU gibt explizit die Brainpool Kurve als einzige möglich Kurve an. A_16883−01 VAU-Protokoll: Aufbau VAUClientHello-Nachricht FTP_ITC.1/VAU beschreibt die Initierung des VAU Protokols. A_16884 VAU-Protokoll: Nachrichtentypen und HTTP-Content-Type FTP_ITC.1/VAU mit Anmerkung 12 A_16900 VAU-Protokoll: Client, Behandlung von Fehlernachrichten FTP_ITC.1/VAU mit Anmerkung 12 erklärt, dass unter bestimmten Bedingungen die Verbindung abgebrochen wird A_16903 VAU-Protokoll: Client, Prüfung des VAUClientHelloDataHash-Werts (aus VAUServerHelloData) FTP_ITC.1/VAU mit Anmerkung 12 erklärt, dass unter bestimmten Bedingungen die Verbindung abgebrochen wird A_16941−01 VAU-Protokoll: Client, Prüfung der Signatur der VAUServerHelloData FTP_ITC.1/VAU mit Anmerkung 12 erklärt, dass unter bestimmten Bedingungen die Verbindung abgebrochen wird A_16943−01 VAU-Protokoll: Schlüsselableitung (HKDF) FCS_CKM.1/VAU für Schlüsselableitungen/- generierungen A_16945−02 VAU-Protokoll: Client, verschlüsselte Kommunikation (1) FTP_ITC.1/VAU mit mit Anmerkung 12 A_16957-01 VAU-Protokoll: Client, verschlüsselte Kommunikation (2) FTP_ITC.1/VAU mit mit Anmerkung 12 A_17069 VAU-Protokoll: Client Zählerüberlauf FTP_ITC.1/VAU mit mit Anmerkung 12 A_17070−02 VAU-Protokoll: Aufbau der VAUClientSigFin-Nachricht FCS_COP.1/VAU.Auth beschreibt die Signaturprüfung mit Anmerkung 12 A_17071 VAU-Protokoll: Versand der VAUClientSigFin-Nachricht FCS_COP.1/VAU.Auth beschreibt die Signaturprüfung mit Anmerkung 12 A_17074 VAU-Protokoll: Ignorieren von zusätzlichen Datenfeldern in Protokoll-Nachrichten FTP_ITC.1/VAU mit Anmerkung 12 gibt das an. A_17081 VAUProtokoll: zu verwendende Signaturschlüssel FCS_COP.1/VAU.Auth beschreibt die Signaturschlüsselhandhabung Security Target secunet konnektor 2.1.0 Seite 386 von 424 secunet A_17084 VAU-Protokoll: Empfang der VAUServerFin-Nachricht FTP_ITC.1/VAU mit mit Anmerkung 12 A_17094 TLS-Verbindungen Konnektor (ECC-Migration) FTP_ITC.1/NK.TLS A_17205 Signatur der TSL: Signieren und Prüfen (ECC-Migration) Siehe Anmerkung 10. A_17206 XML-Signaturen (ECC-Migration) FDP_DAU.2/AK.Sig, FDP_DAU.2/AK.QES, FCS_COP.1/AK.XML.SigPr und FCS_COP.1/AK.XML.Sign führen ECDSA als Algorithmus aus. A_17207 Signaturen binärer Daten (ECC- Migration) Bereits mit SFRs FCS_COP.1/AK.CMS.Sign und FCS_COP.1/AK.CMS.SigPr umgesetzt A_17208 Signaturen von PDF/A-Dokumenten (ECC-Migration) FCS_COP.1/AK.PDF.SigPr und FCS_COP.1/AK.PDF.Sign führen ECDSA als Algorithmus aus. A_17209 Signaturverfahren für externe Authentisierung (ECC-Migration) Der Konnektor unterstützt ECDSA FCS_COP.1/AK.SigVer.ECDSA. A_17210 Konnektor, IKE- Schlüsselaushandlung Fallback (ECC-Migration) IKE ECC Unterstützung wird in PTV4 nicht umgesetzt. A_17220 Verschlüsselung binärer Daten (ECIES) (ECC-Migration) FCS_COP.1/AK.CMS.Ver und FCS_COP.1/AK.CMS.Ent wurden um ECIES erweitert. A_17221-01 XML-Verschlüsselung (ECIES) (ECC-Migration) FCS_COP.1/AK.XML.Ent und FCS_COP.1/AK.XML.Ver wurden um ECIES erweitert. A_17322 TLS-Verbindungen nur zulässige Ciphersuiten und TLS-Versionen (ECC-Migration) FCS_CKM.1/NK.TLS Siehe auch A_17124 in Tabelle 37. A_17359 Signaturen binärer Daten (Dokumente) (ECC-Migration) Bereits mit FCS_COP.1/AK.CM.SigPr umgesetzt A_17360 XML-Signaturen (Dokumente) (ECC-Migration) FCS_COP.1/AK.XML.SigPr und FCS_COP.1/AK.XML.Sign führen ECDSA als Algorithmus aus. A_17874 SGD-Client, Client-authentisiertes ECIES-Schlüsselpaar FTP_ITC.1/SGD beschreibt die Kurve und die Verwendung von ECDSA. A_17875 ECIES-verschlüsselter Nachrichtenversand zwischen SGD- Client und SGD-HSM FTP_ITC.1/SGD, FCS_COP.1/SGD.ECIES, FCS_COP.1/SGD.Auth Security Target secunet konnektor 2.1.0 secunet Seite 387 von 424 beschreiben die kryptograhischen Verfahren. A_18004 Vorgaben für die Kodierung von Chiffraten (innerhalb von ePA) FCS_COP.1/SGD.ECIES mit Anmerkung 18 beschreibt den IV A_18464 TLS-Verbindungen, nicht Version 1.1 Anwendungshinweis 113: beschreibt, dass TLS Version 1.2 unterstützt wird. Insbesondere werden keine niedrigeren TLS Versionen unterstützt. A_18467 TLS-Verbindungen, Version 1.3 Version 1.3 wird nicht unterstützt. A_18624 Konnektor, IPsec/IKE: optionale ECC-Unterstützung ECC für VPN wird nicht umgesetzt. GS−A_4376−0 2 XML-Verschlüsselung – Hybrid, Schlüsseltransport RSAES-OAEP FCS_COP.1/AK.XML.Ver und der Anwendungshinweis 142: darunter beschreibt diesen Algorithmus. A_17688 Nutzung des ECC-RSA- Vertrauensraumes (ECC-Migration) Siehe Anmerkung 10 A_17690 Nutzung der Hash-Datei für TSL (ECC-Migration) Optionale Anforderung hat keine Auswirkung auf das ST. A_17821 Wechsel des Vertrauensraumes mittels Cross-Zertifikaten (ECC- Migration) Siehe Anmerkung 10 A_17847 Prüfung eines SGD-HSM-Zertifikats (1/2) FTP_ITC.1/SGD A_17848 Prüfung eines SGD-HSM-Zertifikats (2/2) FTP_ITC.1/SGD A_17888 SGD, KeyDerivation (Client) Anmerkung 16 A_17892 Aufwärtskompatibilität JSON- Requests und -Responses FTP_ITC.1/SGD mit der Anmerkung beschreibt das Verhalten A_17897 SGD-Client, Anfrage GetPublicKey (Client) Anmerkung 16 A_17899 SGD-Clients, Auswertung der Kodierung des öffentlichen ECIES- Schlüssels eines SGD-HSMs FTP_ITC.1/SGD mit der Anmerkung 16 beschreibt das Verhalten A_17900 SGD-Clients, Kodierung des eigenen kurzlebigen ECIES-Schlüssels FCS_COP.1/SGD.ECIES und Anmerkung 17 erklärt die Schlüsselhandhabung A_17901 SGD-Clients, Kodierung der Signatur des eigenen ECIES- Schlüssels FCS_COP.1/SGD.ECIES und Anmerkung 17 erklärt die Schlüsselhandhabung A_17902 Kontext SGD, Chiffrat-Kodierung beim Nachrichtentransport FTP_ITC.1/SGD mit der Anmerkung 16 beschreibt die Nachrichten. Security Target secunet konnektor 2.1.0 Seite 388 von 424 secunet A_17903 Kontext SGD, Prüfung der ephemeren ECC-Schlüssel des Senders beim ECIES-Verfahren FCS_COP.1/SGD.ECIES und Anmerkung 17 beschreibt die Brainpool Kurve A_17924−01 Anfragen an das SGD-HSM (Client) FTP_ITC.1/SGD mit der Anmerkung 16 beschreibt dies. A_17930 interoperables Austauschformat Schlüsselableitungsfunktionalität ePA FTP_ITC.1/SGD mit der Anmerkung 16 beschreibt dies. A_18003 SGD-Client, Prüfung der Telematik- ID bei Berechtigungsvergabe FTP_ITC.1/SGD mit der Anmerkung 16 beschreibt dies. A_18005 SGD-Client, nur Einmalverwendung des kurzlebigen ECIES-Client- Schlüsselpaars FTP_ITC.1/SGD A_18006 SGD-Client, KVNR FTP_ITC.1/SGD beschreibt den Kanal und Anmerkung 16 gibt genauere Informationen A_18024 SGD-Client, Prüfung SGD-HSM- ECIES-Schlüssel FTP_ITC.1/SGD beschreibt den Kanal und Anmerkung 16 gibt genauere Informationen A_18025-01 SGD-Client, Anfrage GetAuthenticationToken FCS_COP.1/SGD.ECIES und die Zufallszahlen werden extern erzeugt A_18028 SGD-Client, Auswertung der Anfrage GetAuthenticationToken FTP_ITC.1/SGD beschreibt den Kanal und Anmerkung 16 gibt genauere Informationen A_18029 SGD-Client, Anfrage KeyDerivation FCS_COP.1/SGD.ECIES beschreibt den Algorithmus für die Ableitung A_18031−01 SGD-Client, Auswertung der Anfrage KeyDerivation FTP_ITC.1/SGD beschreibt den Kanal und Anmerkung 16 gibt genauere Informationen A_18032 SGD-Client, kurzlebigen ECIES- Client-Schlüsselpaar FTP_ITC.1/SGD A_20478 Zusätzliche Dokumentformate für nonQES-Signatur Umgesetzt in FCS_COP.1/AK.XML.Sign A_20977 SGD-Client, Auswertung der Anfrage KeyDerivation FTP_ITC.1/SGD beschreibt den Kanal und Anmerkung 16 gibt genauere Informationen Tabelle 35: ST-Erweiterung für PTV4 Afo-Liste [gemSpec_Kon _KomfSig] Zusammenfassung der Anforderung Umsetzung Security Target secunet konnektor 2.1.0 secunet Seite 389 von 424 A_18686-01 Komfortsignatur-Timer FDP_ACF.1/AK.Sgen, siehe auch Anwendungshinweis 158: A_19100-01 Komfortsignatur-Zähler FDP_ACF.1/AK.Sgen, siehe auch Anwendungshinweis 158: A_19101 Handbuch-Hinweis zu Nutzerauthentisierung am Clientsystem bei Komfortsignatur Siehe Handbuch [110] und Anwendungshinweis 158: A_19102-04 TUC_KON_158 „Komfortsignaturen erstellen“ FDP_ACF.1/AK.Sgen, siehe auch Anwendungshinweis 158: Der Hinweis beschreibt wie die Komfortsignatur funktioniert. A_19103-06 TUC_KON_170 "Dokumente mit Komfort signieren" FDP_ACF.1/AK.Sgen, siehe auch Anwendungshinweis 158: Der Hinweis beschreibt wie die Komfortsignatur funktioniert. A_19104−04 TUC_KON_171 „Komfortsignatur einschalten“ FIA_UAU.5/AK, siehe auch Anwendungshinweis 191: A_19105 TUC_KON_172 „Komfortsignatur ausschalten“ FDP_ACF.1/AK.Sgen, siehe auch Anwendungshinweis 191: A_19258 Secure Messaging bei Komfortsignatur FIA_UAU.5/AK, FIA_API.1/AK, siehe auch Anwendungshinweis 191: A_20073-01 Prüfung der Länge der UserId FIA_UAU.5/AK, siehe auch Anwendungshinweis 158: A_20074 UserId über 1.000 Vorgänge eindeutig FIA_UAU.5/AK, siehe auch Anwendungshinweis 158: TIP1-A_4524- 02 TUC_KON_000 „Prüfe Zugriffsberechtigung” Regel R9 Die Regel R9 steht in TAB_KON_514 welche durch FDP_ACF.1.2/AK.Infomod umgesetzt wird. TIP1−A_4680− 03 Konfigurationswerte des Signaturdienstes FDP_ACF.1/AK.Sgen, siehe auch Anwendungshinweis 158: A_22344 Mindestens zwei parallele Komfortsignatursessions für einen HBA FDP_ACF.1/AK.Sgen und Anwendungshinweis 158: Security Target secunet konnektor 2.1.0 Seite 390 von 424 secunet A_22352 Unabhängige Komfortsignatur-Timer bei parallelen Komfortsignatursessions FDP_ACF.1/AK.Sgen und Anwendungshinweis 158: A_22459 Unabhängige Komfortsignatur- Zähler bei parallelen Komfortsignatursessions FDP_ACF.1/AK.Sgen und Anwendungshinweis 158: Tabelle 36: ST-Erweiterung für PTV5 (Anteil PTV4Plus - Komfortsignatur) Afo-Liste [gemSpec_Kon ] PTV5 Zusammenfassung der Anforderung Umsetzung A_19738 Optionaler Import von Konfigurationsdaten durch lokalen Administrator FMT_MTD.1/AK.Admin A_19945 Unterstützte Signaturvarianten bei Komfortsignatur FDP_DAU.2/AK.QES, FDP_DAU.2/AK.Sig TIP1−A_5437− 02 Signaturverfahren für externe Authentisierung Anwendungshinweis 135: GS−A_5071−0 1 kryptographische Vorgaben für eine Signaturprüfung in der SAK- Konnektor 6.3.1.3 GS−A_4865 Versionierte Liste zulässiger Firmware-Versionen FDP_ACF.1/AK.Update GS−A_4866 Integritäts- und Authentizitätsschutz der Firmware-Versionsinformationen FDP_ACF.1/AK.Update GS−A_4867 Übernahme Firmware-Gruppe FDP_ACF.1/AK.Update GS−A_4868 Aufsteigende Nummerierung der Firmware-Gruppen Die Nummerierung wird in der Umgebung (den Hersteller) sichergestellt. GS−A_4869 Firmware-Gruppe mindestens eine Firmware-Version Die Nummerierung wird in der Umgebung (den Hersteller) sichergestellt. GS−A_4870 Wechsel zu jeder Firmware-Version der aktuellen Firmware-Gruppe FDP_ACF.1/AK.Update Security Target secunet konnektor 2.1.0 secunet Seite 391 von 424 GS−A_4871 Upgrade nur auf höhere Firmware- Gruppen-Version FDP_ACF.1/AK.Update GS−A_4872 Kein Downgrade der Firmware- Gruppe FDP_ACF.1/AK.Update GS−A_4873 Speicherung der Firmware-Gruppe FDP_ACC.1/AK.Update Signatur des Firmware Pakets ist integraler Teil des Firmware Pakets GS−A_4874 Firmware-Gruppen-Updates nur über herstellereigenen Update- Mechanismus FDP_ACF.1/AK.Update GS−A_4941 Betriebsdokumentation der dezentralen Produkte der TI- Plattform Ist eine Anforderung für die Guidance und nicht das ST. A_17124 TLS-Verbindungen (ECC-Migration) FCS_CKM.1/NK.TLS, FCS_COP.1/NK.TLS.Auth, Anwendungshinweis 116: A_17125 IKE-Schlüsselaushandlung für IPsec (ECC-Migration) FCS_COP.1/NK.Auth und FCS_CKM.1/NK (Anwendungshinweis 110:) A_17126 IPsec-Kontext -- Verschlüsselte Kommunikation (ECC-Migration) FCS_COP.1/NK.ESP A_21185 Prüfung der detached Signatur der TSL bei Download aus dem Internet FPT_TDC.1.2/AK, TIP1−A_4693− 02 TUC_KON_032 „TSL aktualisieren” FPT_TDC.1.2/AK TIP1−A_4736− 02 Kommunikation mit dem Internet (via IAG) FDP_IFF.1/NK.PF A_19052 Vorgaben für Dokumentformate und Nachrichten Siehe „Gültiges XML-Schema“ Kapitel 9.3 A_19971 SGD und SGD-Client, Hashfunktion für Signaturerstellung und -prüfung FCS_COP.1/SGD.Auth beschränkt sich auf SHA-256. A_21275-01 TLS-Verbindungen, zulässige Hashfunktionen bei Signaturen im TLS-Handshake FCS_COP.1/NK.TLS.Auth zeigt die verwendeten TLS Algorithmen Security Target secunet konnektor 2.1.0 Seite 392 von 424 secunet A_21697 Schlüsselpaar und dazugehöriges X.509-Zertifikat für Authentisierung des Konnektors gegenüber Clientsystemen importieren Siehe Anwendungshinweis 119: A_21698 Importiertes Schlüsselpaar und dazugehöriges X.509-Zertifikat für Authentisierung des Konnektors gegenüber Clientsystemen verwenden Siehe FMT_MTD.1/AK.Admin A_21699 Schlüssel und X.509-Zertifikate für Authentisierung des Konnektors gegenüber Clientsystemen erzeugen Siehe Anwendungshinweis 194: A_21701 Schlüssel und X.509-Zertifikate für Authentisierung des Konnektors gegenüber Clientsystemen exportieren FDP_ETC.2/NK.TLS regelt den Export A_21702 Intern generierte Schlüssel und X.509-Zertifikate für Authentisierung des Konnektors gegenüber Clientsystemen verwenden Siehe Anwendungshinweis 194: A_21759 Aufgefrischte ID.AK.AUT für Authentisierung des Konnektors gegenüber Clientsystemen verwenden Siehe Anwendungshinweis 194: A_21760 ID.AK.AUT auf gSMC-K für Authentisierung des Konnektors gegenüber Clientsystemen verwenden Siehe FMT_MTD.1/AK.Admin A_22494 SGD-Client, HTTP-Variable SGD- Userpseudonym FTP_ITC.1/SGD beschreibt den Kanal und Anmerkung 16 gibt genauere Informationen. Tabelle 37: ST-Erweiterung für PTV5 (Weitere Anteile) Security Target secunet konnektor 2.1.0 secunet Seite 393 von 424 8.2. Erweiterungen für unterstützte Fachmodule Der secunet konnektor 2.1.0 unterstützt die Fachmodule ePA (nach [49]), NFDM (nach [44]) und AMTS (nach [45]). Entsprechend der Technischen Richtlinien TR-03154 ([24]) und TR-03155 ([25]), Kapitel 3.3.2 und TR-03157, Kapitel 3.2.2, gelten Anforderungen an den Konnektor die im Rahmen der CC Evaluierung betrachtet werden müssen. Diese werden im Folgenden zusammengefasst. Der Anwendungskonnektor stellt den Fachmodulen ePA, NFDM und AMTS bestimmte Funktionen der Basisdienste zur Verfügung, die von den Fachmodulen über entsprechende Schnittstellen zum Konnektor aufgerufen werden können. In Tabelle 38 werden die nach TR- 03157, TR-03154 und TR-03155 sicherheitsrelevanten Funktionen der Basisdienste anhand der in [27] definierten Technical Use Cases (TUC) aufgelisteten und die jeweilige dem Fachmodul angebotene Schnittstelle angegeben. Dienst nach [27] TUC nach [27] Konnektor-Schnittstelle zum Fachmodul Fach- module Zugriffsberechtigun gsdienst TUC_KON_000 „Prüfe Zugriffsberechtigung“ [Fachmodul-API] NFDM, AMTS, ePA Dokumentenvalidie rungsdienst TUC_KON_080 „Dokument validieren“ (indirekt) [Fachmodul-API] NFDM Für Schlüsselerzeugung TUC_KON_072 „Daten symmetrisch verschlüsseln“ [Fachmodul-API] ePA Kartendienst TUC_KON_005 „Card-to-Card authentisieren“ [Fachmodul-API] NFDM, AMTS, ePA Kartendienst TUC_KON_006 „Datenzugriffsaudit eGK schreiben“ [Fachmodul-API] NFDM, AMTS Kartendienst TUC_KON_012 „PIN verifizieren“ [Fachmodul-API] NFDM, AMTS, ePA Kartendienst TUC_KON_018 „eGK-Sperrung prüfen“ [Fachmodul-API] NFDM, AMTS, ePA Kartendienst TUC_KON_022 „Liefere PIN-Status“ [Fachmodul-API] NFDM, AMTS, ePA Kartendienst TUC_KON_023 „Karte reservieren“ [Fachmodul-API] NFDM, AMTS, ePA Kartendienst TUC_KON_026 „Liefere CardSession“ [Fachmodul-API] NFDM, AMTS, ePA Kartendienst TUC_KON_036 „Liefere Fachliche Rolle“ [Fachmodul-API] NFDM, AMTS Kartendienst TUC_KON_041 „Einbringen der Endpunktinformationen während der Bootup-Phase“ [Fachmodul-API] NFDM, AMTS Kartendienst TUC_KON_202 „Lese Datei“ [Fachmodul-API] NFDM, AMTS Security Target secunet konnektor 2.1.0 Seite 394 von 424 secunet Kartendienst TUC_KON_203 „Schreibe Datei“ [Fachmodul-API] NFDM, AMTS Kartendienst TUC_KON_204 „Lösche Datei Inhalt“ [Fachmodul-API] NFDM, AMTS Kartenterminaldien st TUC_KON_051 „Mit Anwender über Kartenterminal interagieren“ [Fachmodul-API] NFDM, AMTS Namensdienst TUC_KON_361 „DNS-Namen auflösen“ [Fachmodul-API] ePA Namensdienst TUC_KON_362 „Liste der Dienste abrufen“ [Fachmodul-API] ePA Namensdienst TUC_KON_363 „Dienstdetails abrufen“ [Fachmodul-API] ePA Signaturdienst TUC_KON_151 „QES Dokumentensignatur prüfen“ [Fachmodul-API] NFDM Signaturdienst TUC_KON_160 „Dokumente nonQES signieren“ [Fachmodul-API] ePA Signaturdienst TUC_KON_162 „Kryptographische Prüfung der XML- Dokumentensignatur“ [Fachmodul-API] NFDM Systeminformations dienst TUC_KON_254 „Liefere Ressourcendetails“ [Fachmodul-API] NFDM, AMTS, ePA TLS-Dienst TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen“ [Fachmodul-API] ePA TLS-Dienst TUC_KON_111 „Kartenbasierte TLS-Verbindung abbauen“ [Fachmodul-API] ePA Protokollierungsdie nst TUC_KON_271 „Schreibe Protokolleintrag“ [Fachmodul-API] NFDM, AMTS, ePA Verschlüsselungdie nst TUC_KON_075 „Symmetrisch verschlüsseln” [Fachmodul-API] ePA Verschlüsselungdie nst TUC_KON_076 „Symmetrisch entschlüsseln” [Fachmodul-API] ePA Zeitdienst TUC_KON_351 „Liefere Systemzeit“ [Fachmodul-API] NFDM, AMTS, ePA Zertifikatsdienst TUC_KON_034 „Zertifikatsinformationen extrahieren“ [Fachmodul-API] NFDM, ePA Zertifikatsdienst TUC_KON_037 „Zertifikat prüfen“ [Fachmodul-API] ePA Für leichtgewichtige Sicherungsschicht Interne Schnittstellen zum Client für leichtgewichtige Sicherungsschicht auf Anwendungsebene [Fachmodul-API] ePA Client für beidseitig authentisierten Ende-zu-Ende- verschlüsselten Kanal mit SGD- HSDM Interne Schnittstellen für die ECIES-basierte Kommunikation zwischen Konnektor Basisfunktionalität und zwei SGD-HSMs gemäß [Fachmodul-API] ePA Tabelle 38: Sicherheitsrelevante Schnittstellen zu den Fachmodulen Die Prüfung der korrekten Nutzung der Schnittstellen durch die Fachmodule ist Gegenstand der TR-Zertifizierung nach den Technischen Richtlinien TR-03157, TR-03154 und TR-03155. Im Security Target secunet konnektor 2.1.0 secunet Seite 395 von 424 Rahmen der CC-Zertifizierung wird die korrekte und sichere Umsetzung der Funktionalität durch den Konnektor geprüft, siehe dazu auch 6.4.2, Verfeinerungen hinsichtlich der Fachmodule NFDM, AMTS. Darüber hinaus werden in den Technischen Richtlinien zur Prüfung der Fachmodule weitere Sicherheitsanforderungen an den Konnektor gestellt, die im Rahmen der CC-Zertifizierung betrachtet werden müssen. Diese werden in der folgenden Tabelle diskutiert: Anforderungen aus TR Umsetzung durch den Konnektor (Nur NFDM) Signaturdienst – QES-Prüfung von XML-detached Signaturen (nach vorheriger Prüfung gemäß gematik Signaturrichlinie für gematik- vorgegebenem XML Schema) Die QES-Prüfung von XML-detached Signaturen ist Sicherheitsfunktionalität des Konnektors und Gegenstand der Zertifizierung. Das Fachmodul NFDM stellt dem Konnektor eine Signaturrichtlinie mit dem gematik-vorgegebenem XML Schema zur Verfügung. Im SFR FPT_TDC.1/AK wurden die Interpretation der Signaturrichtlinien des NFDM Fachmoduls entsprechend berücksichtigt und ist damit Sicherheitsfunktionalität des EVGs. Entsprechend O.AK.Sig.SignQES wird die Wohlgeformtheit der zu signierenden Dokumente gegen die entsprechende Format- Spezifikation geprüft. Das beinhaltet für Fachmodule die Prüfung gegen das in der Signaturrichtline festgelegte XML Schema. Gültigkeitsprüfung der eGK Die Gültigkeitsprüfung der eGK wird durch das Sicherheitsziel O.AK.Chipkartendienst umgesetzt und ist damit Sicherheitsfunktionalität des EVGs: FPT_TEE.1/AK fordert bei Stecken einer Chipkarte, die vorgibt, ein HBA, eine gSMC- KT, eine SMC-B oder eine eGK zu sein, zu prüfen, ob sie tatsächlich eine solche Chipkarte ist. Die dafür präsentierten CV- Zertifikate werden gemäß FPT_TDC.1/AK auf Gültigkeit für HBA, SMC (gSMC-KT oder SMC-B) und eGK geprüft. Funktionalität des Konnektors zur Transportsicherung zwischen Konnektor und Clientsystem Die Transportsicherung zwischen Konnektor und Clientsystem wird durch die Sicherheitsfunktionen NK.TLS-Kanäle unter Nutzung sicherer kryptographischer Algorithmen und AK.TLS-Kanäle umgesetzt und ist damit Sicherheitsfunktionalität des EVGs Security Target secunet konnektor 2.1.0 Seite 396 von 424 secunet Auslesbare, eindeutige Version des Konnektors sowie des Fachmoduls NFDM und AMTS. Die Version der Fachmodule lässt sich über die Management-Schnittstelle des Konnektors auslesen. Im Benutzerhandbuch findet sich die entsprechende Beschreibung. (Nur ePA) Rollenprüfung im TLS-Dienst Das Fachmodul ePA definiert beim Verbindungsaufbau für das TLS-Zertifikat der Gegenstelle eine zulässige Rolle. Werden die Anforderungen des Fachmoduls an das Zertifikat der Gegenstelle nicht erfüllt, MUSS der Konnektor die Verbindung abbrechen. Die Rollenprüfung von Zertifikaten wird mit TUC_KON_036 umgesetzt. (Nur ePA) Rollenprüfung in der Basisfunktionalität ‚leichtgewichtige Sicherungsschicht zur VAU‘ Weist das Zertifikat der VAU nicht die Rolle oid_epa_vau (nach [50]) auf, MUSS der Konnektor die Verbindung abbrechen. Dies ist umgesetzt in FTP_ITC.1/VAU. Tabelle 39: Weitere Anforderungen an den Konnektor Security Target secunet konnektor 2.1.0 secunet Seite 397 von 424 8.3. Informationen zur Signaturdirektive Der Konnektor setzt im Signaturdienst (siehe Kapitel AK.Signaturdienst) verschiedene Signaturtypen und Signaturvarianten um und erlaubt es, optional sogenannte Signaturrichtlinien in Operationsaufruf anzugeben, die sicherstellen, dass entsprechend erzeugte Dokumenten-Siganturen einem vorgegebenen Schema folgen. Dabei wird der Begriff „Signaturrichtlinie“ in Rahmen der Konnektorevaluierung unterschiedlich verwendet: a) Signaturrichtlinie als im Operationsaufruf angegebene Richtlinie für genau diese Dokumenten-Signatur. Das entspricht der Auffassung einer Signaturrichtlinie nach [gemSpec_Kon] b) Signaturrichtlinie als allgemeine funktionale Einschränkung der Konnektor- Schnittstelle. Bei der NFDM-Signaturrichtlinie [46] handelt es sich zum Beispiel um eine Signaturrichtlinie nach erster Definition. Zur Abgrenzung der Begrifflichkeiten wird bei einer Signaturrichtlinie nach zweiter Definition von einer Signaturdirektive gesprochen. Im Dokument [113] wird die Signaturdirektive des secunet konnektor 2.1.0 beschrieben. Die Härtung der entsprechenden Schnittstellen (z.B. Härtung des XML-Parsers) wird im Dokument [114] beschrieben. Security Target secunet konnektor 2.1.0 Seite 398 von 424 secunet 8.4. Informationen zur Verschlüsselungsdirektive Der Konnektor bietet durch den Verschlüsselungsdienst den Clientsystemen die Möglichkeit Dokumente hybrid zu ver- und entschlüsseln. Analog zur „Signaturrichtlinie“ des Signaturdienstes wird der Begriff „Verschlüsselungsrichtlinie“ in Rahmen der Konnektorevaluierung unterschiedlich verwendet: a) Verschlüsselungsrichtlinie als im Operationsaufruf angegebene Richtlinie für genau diese Dokumenten-Verschlüsselung. b) Verschlüsselungsrichtlinie als allgemeine funktionale Einschränkung der Konnektor- Schnittstelle. Eine Verschlüsselungsrichtlinie nach a) ist in [gemSpec_Kon] nicht spezifiziert und wird von Konnektor nicht unterstützt. Es können keine solche Verschlüsselungsrichtlinien im Operationsaufruf angegeben werden. Zur Abgrenzung der Begrifflichkeiten wird bei einer Verschlüsselungsrichtlinie nach Definition b) von einer Verschlüsselungsdirektive gesprochen. Im Dokument [115] wird die Verschlüsselungsdirektive des secunet konnektor 2.1.0 beschrieben. Die Härtung der entsprechenden Schnittstellen (z.B. Härtung des XML-Parsers) wird im Dokument [114] beschrieben. Security Target secunet konnektor 2.1.0 secunet Seite 399 von 424 9. Anhang 9.1. Auszüge aus der Konnektorspezifikation [27] zum Zugriffs- berechtigungsdienst Siehe die folgenden Tabellen in Kapitel 7.1 des Protection Profiles [16]:  Tabelle 29: TAB_KON_507 Informationsmodell Entitäten aus [27]  Tabelle 30: TAB_KON_508 Informationsmodell Attribute aus [27]  Tabelle 31: TAB_KON_509 Informationsmodell Entitätenbeziehungen aus [27]  Tabelle 32: TAB_KON_510 Informationsmodell Constraints aus [27]  Tabelle 33: TAB_KON_511 – TUC_KON_000 „Prüfe Zugriffsberechtigung“ aus [27]  Tabelle 34: TAB_KON_512 Zugriffsregeln Beschreibung  Tabelle 35: TAB_KON_513 Zugriffsregeln Regelzuordnung aus [27]  Tabelle 36: TAB_KON_514 Zugriffsregeln Definition aus [27] Security Target secunet konnektor 2.1.0 Seite 400 von 424 secunet 9.2. Abkürzungsverzeichnis Abkürzung Bedeutung AK Anwendungskonnektor ECIES Elliptic Curve Integrated Encryption Scheme EVG Evaluierungsgegenstand AP Arbeitsplatz (entspricht dem Clientsystem) BSI Bundesamt für Sicherheit in der Informationstechnik BnetzA-VL Vertrauensliste der Bundesnetzagentur CHA Card holder autorization, Rechte, die ein Zertifikatsinhaber besitzt CHAT Card Holder Authorization Table, Liste der Zugriffsrechte (Flaglist) des Karteninhabers CA Certification Authority, Zertifizierungsinstanz CadES CMS Advanced Electronic Signature: Standard (RFC 5126) zur Definition von Profilen für CMS signierte Daten CMS im Kontext von Fachanwendungen: Card Management System, Kartenmanagementsystem im Kontext digitaler Signaturen: Cryptographic Message Syntax CORS Cross-origin Resource Sharing CRL Certificate Revocation List CVC Card verifiable certificate, kartenverifizierbares Zertifikat DTBS data 400ob e signed (zu signierende Daten) EAL Evaluation Assurance Level (vordefinierte Vertrauenswürdigkeitsstufe in den CC) eGK, eHC elektronische Gesundheitskarte (Englisch: eHC, electronic Health Card) Security Target secunet konnektor 2.1.0 secunet Seite 401 von 424 eIDAS eIDAS-Verordnung (electronic identification and trust services for electronic transactions) EVG Evaluierungsgegenstand (Prüfgegenstand der Evaluierung), engl: target of evaluation (TOE) gematik gematik GmbH, siehe www.gematik.de HBA Heilberufsausweis, Englisch: Health Professional Card (HPC) HBAx Bezeichnung für Chipkarten des Typs HBA, HBA-qSig und ZOD-2.0 HKDF HMAC-based Key Derivation Function HSM Hardware Security Module HSM-B Eine HSM-Variante einer Institutionskarte Typ B (Secure Module Card). Das SM-B wird in dieser Fassung als virtuelle Karte verstanden, welches in einem virtuellen Kartenterminal steckt. HW Hardware IAG Internetzugangspunkt des Leistungserbringers JSON JavaScript Object Notation KT Kartenterminal, Englisch: Cardterminal (CT) KV Krankenversicherung KVK Krankenversichertenkarte LAN local area network (lokales Netzwerk) LE Leistungserbringer LE-LAN lokales Netz der Leistungserbringer MAC Message Authentication Code NK Netzkonnektor OCSP Online Certificate Status Protocol, siehe RFC 2560 Security Target secunet konnektor 2.1.0 Seite 402 von 424 secunet PAdES PDF Advanced Electronic Signature: ETSI Standard zur Signatur von PDF Dokumenten PIN Persönliche Identifikationsnummer PKI Public Key Infrastructure PP Protection Profile (Schutzprofil) PUK PIN unblock code zum Rücksetzen des Fehlbedienungszählers des Heilberufsausweises. PVS Praxisverwaltungssystem RAD reference authorisation data (Authentisierungsreferenzdaten) SE Security environment SAK Bezeichnung einer Identität des Konnektors; steht für Signaturanwendungs- komponente, einem Begriff aus dem SigG. Um Missverständnissen vorzubeugen, wurde im Rahmen der Aktualisierung dieses PPs aufgrund der eIDAS Verordnung der Begriff SAK durch SCaVA ersetzt. SCA Signature Creation Application SVA Signature Validation Application SCaVA Signature Creation Application and Signature Validation Application SCD signature creation data (Signaturschlüssel) SICCT Secure Interoperable Chip Card Terminal SigG Deutsches Signaturgesetz SigV Deutsche Signaturverordnung SIS Sicherer Internet Service SM secure messaging (sicherer logischer Kanal) Security Target secunet konnektor 2.1.0 secunet Seite 403 von 424 SMC-B Secure Module Card, Type B (Institutskarte): Schlüsselspeicher für den privaten Schlüssel, mit dessen Hilfe eine Einheit oder Organisation des Gesundheitswesens authentisiert werden kann SM-B Zusammenfassung der Chipkarten SMC-B und HSM-B SM-K Sicherheitsmodul für den Konnektor (kann gSMC-K beinhalten) gSMC-K Sicherheitsmodul für den Konnektor gSMC-KT Sicherheitsmodul für das eHealth-Kartenterminal QES qualifizierte elektronische Signatur QSCD Englisch: qualified signature-creation device, siehe QSEE QSEE qualifizierte elektronische Signaturerstellungseinheit SVAD Signatory Verification Authentication Data (Authentisierungsverifikations- daten des Signaturschlüsselinhabers) SVD signature verification data (Signaturprüfschlüssel) SW Software TCL Trusted Component List TI Telematikinfrastruktur TLS Transport layer security, standardisiertes sicheres Kommunikationsprotokoll TSL Trust-service Status List TSP Trusted Service Provider VDA Vertrauensdiensteanbieter VSD Versichertenstammdaten VSDM Versichertenstammdatenmanagement, siehe auch Fachmodul VSDD Versichertenstammdatendienst, siehe auch Fachdienst XAdES XML Advanced Electronic Signature: ETSI Standard zur Signatur von XML Dokumenten Security Target secunet konnektor 2.1.0 Seite 404 von 424 secunet XAdES-X XAdES extended: ein Profil von XAdES xTV Veraltete Bezeichnung eines Teils einer SAK gemäß SigG/SigV. Extended Trusted Viewer (erweiterte sichere Anzeige) als Teil des Konnektors, ausgelagert auf den Arbeitsplatz des Benutzers. Diese Funktionalität kann nun von einer Clientsoftware umgesetzt werden und gehört nicht zum EVG. Tabelle 40: Abkürzungsverzeichnis 9.3. Glossar Begriff Definition Ablauflogik Der Begriff Ablauflogik bezeichnet die Möglichkeit, erlaubte Reihenfolgen von Basisdiensten und Fachdiensten vorzugeben. Welche Abläufe dies im Einzelnen sind, hängt von den konkreten fachlichen Anwendungsfällen ab. Die Ablauflogik kann außerhalb der TSF liegen, die Ablaufkontrolle ist Teil der TSF. Häufig wird der Begriff Ablauflogik auch synonym zum Begriff Fachlogik verwendet. Anwendungs- konnektor Der Teil des Konnektors [27], der dem Clientsystem die Schnittstellen zu den Fachdienstmodulen (VSDD, AMTS etc.) und Basisdienste (Sicherheitsdienste, Chipkartendienste, Kartenterminaldienste, Hilfsdienste) zur Verfügung stellt und die dafür notwendigen Managementdienste implementiert. Authentisierungs- referenzdaten Daten, die zur Prüfung der Authentisierungsdaten benutzt werden. Die Integrität dieser Authentisierungsreferenzdaten ist zu schützen. Englisch: authentication reference data, abgekürzt RAD. Authentisierungs- verifikationsdaten Daten, die vom Benutzer zum Nachweis seiner Identität gegenüber dem Kartenterminal präsentiert werden, z.B. eine PIN oder biometrische Merkmalsdaten. Englisch: authentication verification data, abgekürzt SVAD. Autorisierter Benutzer des Clientsystems Ein Benutzer des Clientsystems ist dann für die Auslösung des Signaturprozesses autorisiert, wenn der Benutzer durch den EVG identifiziert wurde, sich für den Vorgang, der durch die am eHealth- Kartenterminal angezeigte Jobnummer identifiziert wurde, gegenüber dem zugeordneten Heilberufsausweis erfolgreich mit der PIN.QES authentisiert hat (vergl. [21]). Autorisierter Signaturstapel Derjenige Teil eines Stapels zu signierender Daten (s.u.), der nach erfolgreicher Authentisierung des Signaturschlüsselinhabers mit der Security Target secunet konnektor 2.1.0 secunet Seite 405 von 424 Signatur-PIN gegenüber der Signaturchipkarte durch den Signatur- dienst an die Signaturkarte zum Signieren gesendet wird. Umfasst der Stapel zu signierender Daten mehr Daten als durch die Zugriffsbedingung der Signaturkarte nach eine Authentisierung mit der Signatur-PIN zulässig sind, ist die Authentisierung mit der Signtaur-PIN zu wiederholen oder Prozess der Signaturerstellung abzubrechen (s.a. Anwendungshinweis 191:). Bestandsnetz Bereits vor Einführung der Telematikinfrastruktur bestehende Netze deren Anwednungen durch Leistungserbringer genutzt werden und über die Telematikinfrastruktur zugänglich sind. Kartenhandle (BKH) Handle zur Identifizierung einer Chipkarte, die in einem eHealth- Kartenterminal steckt. Mit diesem BKH sind folgende Informationen verknüpft (s. [27], Kap. 4.1.1.1): (i) Chipkartentyp KVK, bzw. HBA, SMC oder eGK, (ii) ICCSN, (iii) Identität des Kartenterminals, in dem die Chipkarte gesteckt ist und (iv) Zeitpunkt, zu dem die Chipkarte erkannt wurde. Card-to-Card- Authentisierung Card-to-Card-Authentisierung umfasst (s. [27], Kap. 4.1.5.4.7): (1) einseitige asymmetrische Authentisierung ohne Aushandlung eines Sessionkey, (2) einseitige symmetrische Authentisierung ohne Aushandlung eines Sessionkey, (3) gegenseitige asymmetrische Authentisierung ohne Aushandlung eines Sessionkey, (4) gegenseitige symmetrische Authentisierung ohne Aushandlung eines Sessionkey, (5) gegenseitige asymmetrische Authentisierung mit Aushandlung eines Sessionkey (Trusted Channel Schlüssel der Quellchipkarte und Secure Messaging Schlüssel der Zielchipkarte) und Aufbau eines Secure Messaging Kanals, (6) gegenseitige symmetrische Authentisierung mit Aushandlung eines Sessionkey (Trusted Channel Schlüssel der Quellchipkarte und Secure Messaging Schlüssel der Zielchipkarte) und Aufbau eines Secure Messaging Kanals. Die externe Authentisierung mit Ausnahme von (5) verändert den Authentisierungsstatus der prüfenden Chipkarte. Chipkarte In diesem Schutzprofil: der Heilberufsausweis (HBA), SMC-Typ B, eGK und KVK. CRL Download Server Ein von der PKI der TI bereitgestellter Downloadpunkt im Internet, von dem der Konnektor die aktuelle CRL erhalten kann. Digitale Signaturen Asymmetrischer kryptographischer Mechanismus bei dem für Daten („Nachricht“) ein Datum („Signatur“) mit Hilfe eines geheimen Security Target secunet konnektor 2.1.0 Seite 406 von 424 secunet Signaturschlüssels („Signaturerstellungsdaten“) berechnet und der Nachricht zugeordnet werden, und diese Zuordnung bei Kenntnis der Nachricht und der Signatur mit dem zum Signaturschlüssel zugehörigen öffentlichen Signaturprüfschlüssel geprüft werden kann. eIDAS-Verordnung VERORDNUNG (EU) Nr. 910/2014 DES EUROPÄISCHEN PARLAMENTS UND DES RATES vom 23. Juli 2014 über elektronische Identifizierung und Vertrauensdienste für elektronische Transaktionen im Binnenmarkt und zur Aufhebung der Richtlinie 1999/93/EG [12]. eingeschränkter Text Text, der keine unerlaubten Zeichenketten enthält, die den Benutzer des Kartenterminals zur Eingabe einer PIN oder PUK im ungeschützten Mode verleiten könnte. eHealth- Kartenterminal Kartenterminal gemäß Spezifikation [38], evaluiert gemäß [22] und als Signaturprodukt zugelassen. Einfachsignatur Die qualifizierte Signaturerstellungseinheit (QSEE) erlaubt nach einmaliger erfolgreicher Authentisierung des Signaturschlüssel- Inhabers die Erzeugung höchstens 1 Signatur. Elektronische Signaturen Daten in elektronischer Form, die anderen elektronischen Daten beigefügt oder logisch mit ihnen verbunden werden und die der Unterzeichner zum Unterzeichnen verwendet, vergl. eIDAS [12] Artikel 3, Punkt 10. Entfernte PIN-Eingabe Prozess der eine Eingabe der PIN (oder PUK) an einem eHealth- Kartenterminal (PIN-Terminal) und geschützte Übertragung durch eine gSMC-KT (PIN-Sender) an eine Chipkarte (PIN-Empfänger) in einem anderen Chipkarten-Terminal unter Steuerung der AK (s. [21], Kap. 2.1.2, und [27], Kap. 4.1.5.5.1). Die entfernte PIN-Eingabe muss den sicheren Eingabe-Modus der eHealth-Kartenterminals und die Jobnummer nutzen und die PIN verschlüsselt an den PIN-Empfänger übergeben. Die Prozeduren der entfernten PIN- oder PUK-Eingabe können auch für eine lokale PIN- oder PUK-Eingabe genutzt werden (d.h. ein einziges eHealth-Kartenterminal dient der PIN-Eingabe und enthält gesteckten PIN-Sender und PIN-Empfänger). Fachanwendung Anwendung die durch Fachmodul und Fachdienst realisiert wird. Gelegentlich wird aber auch allgemeiner eine fachliche Anwendung darunter verstanden wie in § 291 a SGB V [14], definiert (Abs. (2): Pflichtanwendungen, Abs. (3): freiwillige Anwendungen):  Übermittlung ärztlicher Verordnungen (Verordnungsdaten- management, VODM),  Berechtigungsnachweis zur Inanspruchnahme von Leistungen (Versichertenstammdatenmanagement, VSDM), Security Target secunet konnektor 2.1.0 secunet Seite 407 von 424  Notfallversorgung (Notfalldatenmanagement, NFDM),  Arztbrief  Arzneimitteltherapiesicherheit  elektronische Patientenakte  Versichertendaten  in Anspruch genommene Leistungen und deren vorläufige Kosten Siehe auch Fachdienst und Basisanwendung. Fachdienst der Teil einer fachlichen Anwendung (siehe auch Fachliche Anwendungsfälle), der entfernt abläuft – in Abgrenzung zu Fachmodul (im Konnektor) und Fachanwendung (auf dem Clientsystem). Für Online-Rollout Stufe 1 gibt es nur den Fachdienst VSDM (Versichertenstammdatenmanagement). Fachliche Anwendungsfälle einzelne Anwendungsfälle (Use Cases) innerhalb einer Fachanwendung (siehe auch Fachanwendung). In Dokumenten zur Facharchitektur (von Fachanwendungen) werden solche fachlichen Anwendungsfälle auch als fachliche Use Cases bezeichnet. Die fachlichen Use Cases werden durch technische Use Cases umgesetzt. Technische Use Cases werden auch als Abläufe bezeichnet. Fachmodul der Teil einer fachlichen Anwendung (siehe auch Fachliche Anwendungsfälle), der auf dem Konnektor abläuft – in Abgrenzung zu Fachanwendung (auf dem Clientsystem) und Fachdienst. Siehe auch Ablauflogik Fortgeschrittene elektronische Signaturen elektronische Signatur, die die folgenden Anforderungen erfüllt: a) Sie ist eindeutig dem Unterzeichner zugeordnet. b) Sie ermöglicht die Identifizierung des Unterzeichners. c) Sie wird unter Verwendung elektronischer Signaturerstellungsdaten erstellt, die der Unterzeichner mit einem hohen Maß an Vertrauen unter seiner alleinigen Kontrolle verwenden kann. d) Sie ist so mit den auf diese Weise unterzeichneten Daten verbunden, dass eine nachträgliche Veränderung der Daten erkannt werden kann. vergl. eIDAS [12] Artikel 3, Punkt 11 und Artikel 26 Gültige Verschlüsselungs- richtlinie Eine zulässige Verschlüsselungsrichtlinie ist gültig, wenn sie durch den autorisierten Benutzer für die zu verschlüsselnden oder zu entschlüsselnde Daten bestätigt oder durch die Nutzung der Fachanwendung bzw. des Anwendungsfalls festgelegt wurde. Security Target secunet konnektor 2.1.0 Seite 408 von 424 secunet Gültiges qualifiziertes Signaturzertifikat Die Gültigkeit eines qualifizierten Zertifikates erfordert die Erfüllung der Aspekte im Zertifikatsverzeichnis vorhanden, zeitliche Gültigkeit und Revocation-Status: Gültige Zertifikate müssen im Zertifikatsverzeichnis des ausstellenden qualifizierter Vertrauens- diensteanbieters vorhanden sein. Der Vertrauensdiensteanbieter ist nach eIDAS [12] Artikel 24, Absatz 4 verpflichtet, Informationen über den Gültigkeits- oder Widerrufsstatus der von ihnen ausgestellten qualifizierten Zertifikate zumindest auf Zertifikatsbasis jederzeit und über die Gültigkeitsdauer des Zertifikats hinaus automatisch auf zuverlässige, kostenlose und effiziente Weise bereitzustellen. Die zeitliche Gültigkeit liegt dann vor, wenn der zu dem der Prüfung zugrundeliegende Referenzzeitpunkt innerhalb des im Zertifikat angegebenen Gültigkeitszeitraum liegt. Der Revocation Status ist gültig, wenn das Zertifikat zu dem der Prüfung zugrundeliegende Referenzzeitpunkt nicht gesperrt ist. Gültiges Zertifikat Die Gültigkeit eines Zertifikats kann unter Verwendung einer Zertifikatspolicy und im Fall eines qualifizierten Zertifikats einer OCSP-Anfrage festgestellt werden. Gültiges XML- Schema Ein im EVG fest kodiertes oder mit gültiger Signatur importiertes XML-Schema, siehe auch A_19052. Gültiges Verschlüsselungs- zertifikat der TI Ein Verschlüsselungszertifikat ist gültig, wenn (i) seine Integrität durch eine Zertifikatskette bis zu einem authentisch bekannten öffentlichem Schlüssel erfolgreich geprüft wurde und (ii) das Verschlüsselungszertifikat nicht gesperrt ist. Für ein Verschlüsselungszertifikat eines Versicherten, das von einer aktuell gesteckten eGK gelesen wird, kann explizit angenommen werden, dass es nicht gesperrt ist. Eine Sperrung anderer Verschlüsselungszertifikate ist mittels OCSP-Abfrage zu prüfen. hash&URL server Der hash&URL-Server ist ein http-Server, der die zur gegenseitigen Authentifizierung von Konnektoren und VPN-Konzentratoren genutzten Zertifikate gemäß [RFC7296] zum Download bereitstellt. Heilberufsausweis (HBA) Chipkarte gemäß Spezifikation [31] und [35], dessen Betriebssystem nach PP COS G2 [15] und dessen Objektssystem nach BSI TR-03144 zertifiziert wurden. HBA-Vorläuferkarten (HBA-VK) Adressiert die HBA-Vorläuferkarten HBA-qSig und ZOD_2.0. Wird dieser Referenzbezeichner verwendet, gelten die zugehörigen Aussagen und Festlegungen für beide Kartentypen. (vergl. [27], TAB_KON_500 Wertetabelle Kartentypen). Security Target secunet konnektor 2.1.0 secunet Seite 409 von 424 HBAx Adressiert sowohl den HBA, als auch die HBA-Vorläuferkarten (HBA-VK). Wird dieser Referenzbezeichner verwendet, gelten die zugehörigen Aussagen und Festlegungen für alle drei Kartentypen. ICCSN Seriennummer des Chipkartenchips (engl. ICC Serial Number) Intermediär Vermittler zwischen zwei Systemen, wobei beide Systeme jeweils dem Intermediär vertrauen, nicht jedoch zwangsweise einander. Konnektor dezentrale Komponente zur sicheren Anbindung von Clientsystemen der Leistungserbringer an die Telematikinfrastruktur und Steuerung der eHealth-Kartenterminals im LAN des Leistungserbringers gemäß [27]. Krankenversicherten- karte (KVK) Chipkarte mit eingeschränkter Funktionalität, die die Identität des Versicherten speichert. Die KVK besitzt kein EF.ATR, EF.GDO und EF.DIR und kann keine PIN-Authentisierung, Card-to-Card- Authentisierung und keine Zugriffskontrolle durchführen. Leistungserbringer Verantwortlicher für die Einsatzumgebung der dezentralen Komponenten Konnektor, eHealth-Kartenterminal und SMC Typ B sowie der Clientsysteme und des lokalen Netzes. lokale PIN-Eingabe Die PIN-Eingabe erfolgt an dem Chipkartenterminal, in welchem sich die Chipkarte befindet, die die PIN prüfen soll. Die lokale PIN- Eingabe nutzt den sicheren Eingabe-Modus der eHealth- Kartenterminals und darf die PIN sowohl unverschlüsselt als auch mit den Prozeduren der entfernten PIN-Eingabe verschlüsselt an den PIN- Empfänger übergeben. Managementschnitt- stelle (herstellerspezifische) äußere logische Schnittstelle für alle Managementfunktionen einschließlich Administratorfunktionen. Ordnungsgemäße qualifizierte elektronische Signaturen eines Signaturstapel Ordnungsgemäße qualifizierte elektronische Signaturen sind solche fortgeschrittene elektronische Signaturen, die zu den Daten des Signaturstapels mit dem Signaturschlüssel des Heilberufsausweises des autorisierten Benutzers des Clientsystems erzeugt wurden und zu dessen Signaturprüfschlüssel zum für die Signatur festgelegten Zeitpunkt ein gültiges qualifiziertes Zertifikat existiert. PIN-Empfänger Chipkarte, die eine verschlüsselte PIN oder PUK verschlüsselt für die PIN-Prüfung oder den PIN-Wechsel oder das Entblockieren einer PIN empfängt. Ein PIN-Empfänger ist ein HBA oder eine SMC-B (oder ein RFID-Token für die Komfortsignatur, wenn der EVG Komfortsignatur mit derartigen Token unterstützt). Security Target secunet konnektor 2.1.0 Seite 410 von 424 secunet PIN-Sender Chipkarte, die eine PIN oder PUK unverschlüsselt empfängt und verschlüsselt für die Übertragung an den PIN-Empfänger ausgibt. Ein PIN-Sender ist eine gSMC-KT. Clientsystem Komponente mit einem Benutzerinterface für fachliche Funktionalität. Die Clientsysteme der Leistungserbringer umfassen die Praxisverwaltungssysteme, für Ärzte und Zahnärzte, die Krankenhausinformationssysteme der Krankenhäuser und die Apothekenverwaltungssysteme der Apotheker und stellen die Anwendungsprogramme für die Leistungserbringer und Versicherten zur Verfügung. Sie sind über das LAN des Leistungserbringers mit dem Konnektor verbunden. qualifizierte elektronische Signaturen Fortgeschrittene elektronische Signatur, die von einer qualifizierten elektronischen Signaturerstellungseinheit erstellt wurde und auf einem qualifizierten Zertifikat für elektronische Signaturen beruht, vgl. eIDAS [12] Artikel 3 Punkt 12. Abgekürzt QES. qualifizierter elektronischer Zeitstempel Ein elektronischer Zeitstempel, der Datum und Zeit so mit Daten verknüpft, dass die Möglichkeit der unbemerkten Veränderung der Daten nach vernünftigem Ermessen ausgeschlossen ist, vgl. eIDAS [12] Artikel 3 Punkt 34 und Artikel 42. qualifiziertes Zertifikat Ein: „Qualifiziertes Zertifikat für elektronische Signaturen“ ist ein von einem qualifizierter Vertrauensdiensteanbieter ausgestelltes Zertifikat für elektronische Signaturen, das die Anforderungen aus eIDAS [12] Anhang I erfüllt. qualifizierter Vertrauensdienste- anbieter „Qualifizierter Vertrauensdiensteanbieter“ ist ein Vertrauensdiensteanbieter, der einen oder mehrere qualifizierte Vertrauensdienste erbringt und dem von der Aufsichtsstelle der Status eines qualifizierten Anbieters verliehen wurde vgl. eIDAS [12] Artikel 3 Punkt 20. Registration server of the VPN network provider Der Registrierungsserver ist ein http-Server, welcher Anfragen des Konnektors zur Registrierung des Konnektors durch den berechtigten Teilnehmer beim Anbieter entgegennimmt und bearbeitet. remote management server Management-Gegenstelle für das Remote-Management des Konnektors (sofern dieses angeboten wird). Security environment SE#1 und SE#2 Security environment sind spezielle Sicherheitszustände des HBA, die Zugriffsregeln für die Erzeugung digitaler Signaturen für qualifizierte elektronische Signaturen setzen (s. [35], Kap. 9). qualifizierte elektronische Signaturerstellungs- einheit Konfigurierte Software oder Hardware, die zum Erstellen einer elektronischen Signatur verwendet wird und die Anforderungen aus eIDAS [12] Anhang II erfüllt; Abkürzung: QSEE. Englisch:QSCD. Security Target secunet konnektor 2.1.0 secunet Seite 411 von 424 Sicherer PIN-Modus Tastatureingabemodus des eHealth-Kartenterminals gemäß [38], in dem das eHealth-Kartenterminal durch ein SICCT-Kommando [42] angewiesen wird, die Tastatureingabedaten in einem angegebenen Chipkartenkommando an eine Chipkarte in einem angegebenen Chipkartensteckplatz zu senden und die Antwort der Chipkarte zurückzugeben. Der sichere PIN-Modus ist dem Benutzer anzuzeigen und muss die Vertraulichkeit der Tastatureingabedaten schützen. Signaturanwendungs- komponenten Software- und Hardwareprodukte, die dazu bestimmt sind, a) Daten dem Prozess der Erzeugung oder Prüfung qualifizierter elektronischer Signaturen zuzuführen oder b) qualifizierte elektronische Signaturen zu prüfen oder qualifizierte Zertifikate Englisch: SCA und SVA, hier als SCaVA abgekürzt. Signaturattribute Dieser Begriff wird hier verwendet, um die Arten der Signaturen „einfache Dokumentensignatur“, „Parallelsignatur“ und „Gegensignatur“ zu unterscheiden. Sicherheitsattribute sind Bestandteil der Signaturrichtlinie. Signaturchipkarte Chipkarte mit privaten Schlüsseln zur Erstellung digitaler Signaturen einer elektronischen Signatur. Dies sind gegenwärtig der HBA mit dem privaten Schlüssel PrK.HP.QES, die SMC Typ B mit dem privaten Schlüssel PrK.HI.OSIG und die eGK mit dem privaten Schlüssel PrK.CH.QES. Signaturrichtlinie Die Signaturrichtlinie (Profilierung der Signaturformate) identifiziert - den Typ der Signatur als nicht-qualifizierte oder qualifizierte elektronische Signatur, und kann weitere Informationen umfassen (s. [27], Anhang B) wie z.B. - Anforderungen an Zertifikatsreferenzen - Anforderungen an die Position der Signatur im Dokument - Signaturattribute: Anforderungen bei u.a. Parallelsignatur, dokumentexkludierende Gegensignatur und dokumentinkludierende Gegensignatur für die i.A. spezifizierten unterschiedlichen Signaturformate XAdES, CadES und PAdES. - Bitstrings bei PKCS#7 - U.a. Signaturprüfschlüssel elektronische Daten wie öffentliche kryptographische Schlüssel, die zur Überprüfung einer elektronischen Signatur verwendet werden, Englisch: signature-verification data, abgekürzt SVD. Security Target secunet konnektor 2.1.0 Seite 412 von 424 secunet Signaturschlüssel einmalige elektronische Daten wie private kryptographische Schlüssel, die zur Erstellung einer elektronischen Signatur verwendet werden, Englisch: signature-creation data, abgekürzt SCD. Signaturschlüssel- Inhaber natürliche Personen, die Signaturschlüssel besitzen; bei qualifizierten elektronischen Signaturen müssen ihnen die zugehörigen Signaturprüfschlüssel durch qualifizierte Zertifikate zugeordnet sein. Signaturzertifikate elektronische Bescheinigungen, mit denen Signaturprüfschlüssel einer Person zugeordnet werden und die Identität dieser Person bestätigt wird. Signierte Daten Daten auf die sich eine digitale Signatur einer elektronischen Signatur bezieht. Signature Creation Application Begriff aus den ETSI Standards. Bezeichnet eine Komponente, die Signaturen (auch) gemäß eIDAS erzeugt. Abgekürzt SCA. Signature Validation Application Begriff aus den ETSI Standards. Bezeichnet eine Komponente, die Signaturen (auch) gemäß eIDAS validiert/verifiziert. Abgekürzt SVA. SM-B Oberbegriff von SMC-B und einem HSM mit Funktionen oder Teilfunktionen einer SMC-B. SMC Sicherheitsmodul-Karte. Sammelbegriff für gSMC-K, SMC-B und gSMC-KT. SMC Typ B (SMC-B) Chipkarte gemäß Spezifikation [31] und [36], dessen Betriebssystem nach PP COS G2 [15] und dessen Objektssystem nach BSI TR-03144 zertifiziert wurden. SMC Typ KT (gSMC-KT) Sicherheitsmodul des Kartenterminals. Chipkarte gemäß Spezifikation [31] und [34], dessen Betriebssystem nach PP COS G2 [15] und dessen Objektssystem nach BSI TR-03144 zertifiziert wurden. gSMC-K Sicherheitsmodul des Konnektors. Teil des EVG mit denjenigen Schlüsseln und diejenige Funktionalität, die für die Aufgaben des EVG wie die Authentisierung und Secure messaging mit der Identität „SAK“ gegenüber dem HBA benötigt werden. Chipkarte gemäß Spezifikation [31] und [33], die durch die gematik zugelassen wurden. Stapel zu signierender Daten Liste zu signierender Daten, die durch den Benutzer des Clientsystems ausgewählt wurden und über das Clientsystem an den EVG gesendet wurden. Security Target secunet konnektor 2.1.0 secunet Seite 413 von 424 Stapelsignatur Erstellung einer begrenzten Anzahl Signaturen nach den zeitlich unmittelbar aufeinander folgenden Prozessen der Übergabe der zu signierenden Daten an den EVG über das Clientsystem und der einmaligen Authentisierung des Signaturschlüssel-Inhabers gegenüber der QSEE. stateful packet inspection, stateful inspection dynamische Paketfiltertechnik, bei der (sofern es die Systemressourcen zulassen; im Fall eines denial-of-service-Angriffs müssen Datenpakete verworfen werden) jedes Datenpaket einer bestimmten aktiven Session zugeordnet wird; der Verbindungsstatus eines Datenpakets wird in die Entscheidung einbezogen, ob ein Informationsfluss zulässig ist oder nicht Statusmeldungen Durch den EVG generierte Meldungen an Benutzer zu Fehlern bei der Erfüllung angeforderter Sicherheitsdienst (z. B. nicht gefundene oder ungültige Zertifikate vorgesehener Empfänger zu verschlüsselnder Daten). Telematikinfrastruktur (TI) Die Telematikinfrastruktur ist die bevorzugte Informations-, Kommunikations- und Sicherheitsinfrastruktur des deutschen Gesundheitswesens mit allen technischen und organisatorischen Anteilen. Die Telematikinfrastruktur vernetzt alle Akteure und Institutionen des Gesundheitswesens miteinander und ermöglicht dadurch einen organisationsübergreifenden Datenaustausch innerhalb des Gesundheitswesens. TI Services zentrale Dienste und Fachdienste der Telematikinfrastruktur Trust-Service Status List (TSL) Die Trust-service Status List enthält die öffentlichen Schlüssel aller vertrauenswürdigen CAs, die Information über den für diese CA akkreditierten Zertifikatstyp sowie die Adresse der Zertifikats Status Services (OCSP-Responder und CRL Provider). Sie ist durch gematik TSL Serviceprovider signiert. Trusted Service Provider (TSP) TSPs sind Stellen, die innerhalb oder im Auftrag der Teilnehmerorganisationen Zertifikate für natürliche oder juristische Personen oder technische Komponenten ausstellen und/oder Verzeichnisdienste betreiben. Update-Daten Update-Daten bestehen aus Updateinformation und Updatepaket, die gesondert integritätsgeschützt sind. Verschlüsselungs- richtlinie Verschlüsselungsrichtlinie, die beschreibt  das Verschlüsselungsformat (EncryptionType): Cryptographic Message Syntax [78] oder XML-Encryption [79]  für XML-Encryption: - XML-Schema: beschreibt die zu verschlüsselnden bzw. zu entschlüsselnden Daten, Security Target secunet konnektor 2.1.0 Seite 414 von 424 secunet - Option: KeyInfo im XML-Dokument oder nicht  Herausgeber der Verschlüsselungsrichtlinie. Vertrauensanker Öffentlicher Schlüssel oder Zertifikat (in dem sich ein öffentlicher Schlüssel befindet), das als letzte Instanz bei der Prüfung einer Zertifikatskette in einer PKI zum Einsatz kommt. Dies kann bspw. der öffentliche Schlüssel eines Wurzel-Zertifikats (Root-CA) oder ein Signer-Zertifikat einer Liste von CAs (bspw. BnetzA-VL oder TSL) sein. Vertrauensliste der Bundesnetzagentur (BnetzA-VL) Vertrauensliste der Bundesnetzagentur mit Angaben zu den qualifizierten Vertrauensdiensteanbietern, die von der Bundesrepublik Deutschland beaufsichtigt werden, sowie mit Angaben zu den von ihnen angebotenen qualifizierten Vertrauensdiensten, vgl. eIDAS Artikel 22. Vertrauensdienste- anbieter „Vertrauensdiensteanbieter“ ist eine natürliche oder juristische Person, die einen oder mehrere Vertrauensdienste als qualifizierter oder nichtqualifizierter Vertrauensdiensteanbieter erbringt, vgl. eIDAS [12] Artikel 3, Punkt 19. VPN concentrator VPN-Konzentrator VPN-Konzentrator für den Zugang zur Telematikinfrastruktur VPN-Konzentrator, welcher einen Zugang zur Telematikinfrastruktur bereitstellt – und damit auch einen Zugang für Dienste gemäß § 291 a SGB V (Pflichtanwendungen und freiwillige Anwendungen) Zertifikat Zertifikate sind elektronische Bescheinigungen, die von einer Zertifizierungsinstanz ausgestellt (signiert) werden, mit denen dem Zertifikatsinhaber bestimmte Informationen zugeordnet werden. zu signierende Daten Die Daten, deren Authentizität durch die elektronische Signatur geschützt werden soll und die von der SCaVA an die Signaturerstellungseinheit übergeben werden. Die Integrität der zu signierenden Daten ist zu schützen. Englisch: data to be signed, abgekürzt DTBS. Zulässige Signaturrichtlinie Eine Signaturrichtlinie ist zulässig, wenn sie für die Erzeugung qualifizierter elektronischer Signaturen die Benutzerinteraktion fordert und auf die zu signierenden Daten durch den EVG anwendbar ist. Die Installation der Signaturrichtlinie erfolgt mit der Installation oder Update des EVG oder der Fachanwendung, die diese Signaturrichtlinie implementiert. Zulässige Verschlüs- selungsrichtlinie Eine Verschlüsselungsrichtlinie ist zulässig, wenn die Regeln auf die zu verschlüsselnden oder zu entschlüsselnde Daten anwendbar sind. Die Installation der Verschlüsselungsrichtlinie erfolgt mit der Installation oder Update des EVG oder der Fachanwendung, die diese Verschlüsselungsrichtlinie implementiert. Security Target secunet konnektor 2.1.0 secunet Seite 415 von 424 Tabelle 41: Glossar 9.4. Abbildungsverzeichnis Abbildung 1: Funktionsblöcke des Konnektors........................................................................15 Abbildung 2: Einsatzumgebung des Konnektors (Einbox-Lösung).........................................21 Abbildung 3: Konnektor: externe, physische und logische Schnittstellen ...............................25 Abbildung 4: Konnektor Architekturkonzept (schematisch)....................................................26 Abbildung 5: Konnektor Architektur Komponentenansicht (schematisch)..............................26 Abbildung 6: Netzkonnektor Komponenten (Der TLS-Basisdienst wird im Anwendungskonnektor umgesetzt, ist aber formal dem Netzkonnektor zugeordnet)..27 Abbildung 7: Anwendungskonnektor Komponenten (Der Sichere Datenspeicher wird im Netzkonnektor umgesetzt, ist aber formal dem Anwendungskonnektor zugeordnet)..27 9.5. Tabellenverzeichnis Tabelle 1: Komponenten der Einbox-Lösung...........................................................................14 Tabelle 2: Mindestanforderungen für Komponenten der Einbox-Konnektor Hardware..........40 Tabelle 3: Primäre Werte..........................................................................................................45 Tabelle 4: Sekundäre Werte......................................................................................................47 Tabelle 5: primäre Werte des Anwendungskonnektors............................................................49 Tabelle 6: sekundäre Werte des Anwendungskonnektors ........................................................51 Tabelle 7: Benutzer des Netzkonnektors ..................................................................................52 Tabelle 8: Benutzer des Anwendungskonnektors.....................................................................59 Tabelle 9: Benutzer anderer Komponenten in der IT-Umgebung ............................................60 Tabelle 10: Umgang mit Umgebungszielen des NK im EVG................................................108 Tabelle 11: Abbildung der Sicherheitsziele auf Bedrohungen und Annahmen......................117 Tabelle 12: Abbildung der Sicherheitsziele des EVG auf Bedrohungen und OSPs...............119 Tabelle 13: Abbildung der Sicherheitsziele der Umgebung auf Bedrohungen, OSPs und Annahmen...................................................................................................................121 Tabelle 14: Subjekte ...............................................................................................................148 Tabelle 15: zusätzliche Objekte..............................................................................................159 Tabelle 16: Übersicht über TSF Daten ...................................................................................161 Tabelle 17: Operationen zur Zugriffskontrolle des Chipkartendienstes.................................227 Tabelle 18: Operationen zur Zugriffskontrolle des Chipkartendienstes.................................234 Tabelle 19: Operationen zur PIN-Eingabe..............................................................................240 Security Target secunet konnektor 2.1.0 Seite 416 von 424 secunet Tabelle 20: Operationen zur Signaturerstellung .....................................................................245 Tabelle 21: Operationen zur Signaturprüfung ........................................................................251 Tabelle 22: Operationen für Software-Update........................................................................263 Tabelle 23: Operationen des Verschlüsselungsdienstes .........................................................266 Tabelle 24: Operationen der TLS-Kanäle...............................................................................273 Tabelle 25: Operationen zum Zugriff auf die eGK im Rahmen von VSDM..........................282 Tabelle 26: Operationen zum Zugriff auf die eHK im Rahmen von VSDM..........................285 Tabelle 27: Abbildung der EVG-Ziele auf Sicherheitsanforderungen ...................................327 Tabelle 28: Abdeckung der Sicherheitsziele des EVG durch Sicherheitsanforderungen.......331 Tabelle 29: Abdeckung der Sicherheitsziele der ePA Fachanwendung durch Sicherheitsanforderungen ...........................................................................................331 Tabelle 30: Abbildung der EVG-Ziele auf Anforderungen....................................................342 Tabelle 31: Abbildung der Sicherheitsfunktionalität auf Sicherheitsanforderungen des Netzkonnektors ...........................................................................................................376 Tabelle 32: Abbildung der Sicherheitsfunktionalität auf Sicherheitsanforderungen des Anwendungskonnektors..............................................................................................379 Tabelle 33: Abbildung der Sicherheitsfunktionalität auf Sicherheitsanforderungen der ePA Fachanwendung ..........................................................................................................379 Tabelle 34: ST-Erweiterung für PTV3 ...................................................................................383 Tabelle 35: ST-Erweiterung für PTV4 ...................................................................................388 Tabelle 36: ST-Erweiterung für PTV5 (Anteil PTV4Plus - Komfortsignatur) ......................390 Tabelle 37: ST-Erweiterung für PTV5 (Weitere Anteile) ......................................................392 Tabelle 38: Sicherheitsrelevante Schnittstellen zu den Fachmodulen....................................394 Tabelle 39: Weitere Anforderungen an den Konnektor..........................................................396 Tabelle 40: Abkürzungsverzeichnis........................................................................................404 Tabelle 41: Glossar .................................................................................................................415 9.6. Literaturverzeichnis 9.6.1. Kriterien [4] Common Criteria for Information Technology Security Evaluation – Part 1: Introduction and general model, Version 3.1 Revision 5, April 2017, CCMB-2017-04- 001 [5] Common Criteria for Information Technology Security Evaluation – Part 2: Security functional components, Version 3.1 Revision 5, April 2017, CCMB-2017-04-002 Security Target secunet konnektor 2.1.0 secunet Seite 417 von 424 [6] Common Criteria for Information Technology Security Evaluation – Part 3: Security assurance components, Version 3.1 Revision 5, April 2017, CCMB-2017-04-003 [7] Common Methodology for Information Technology Security Evaluation, Evaluation methodology (CEM), Version 3.1 Revision 5, April 2017, CCMB-2017-04-004 [8] Anwendungshinweise und Interpretationen zum Schema, AIS20: Funktionalitätsklassen und Evaluationsmethodologie für deterministische Zufallszahlengeneratoren, Version 3, 15.05.2013, Bundesamt für Sicherheit in der Informationstechnik [9] Anwendungshinweise und Interpretationen zum Schema, AIS31: Funktionalitätsklassen und Evaluationsmethodologie für physikalische Zufallszahlengeneratoren, Version 3, 15.05.2013, Bundesamt für Sicherheit in der Informationstechnik [10] Joint Interprtation Library, Composite evaluation of Smart Cards and similar devices, January 2012, Version 1.2 [11] W. Killmann, W. Schindler: A proposal for: Functionality classes for random number generators. Version 2.0, September 2011 9.6.2. Gesetze und Verordnungen [12] VERORDNUNG (EU) Nr. 910/2014 DES EUROPÄISCHEN PARLAMENTS UND DES RATES vom 23. Juli 2014 über elektronische Identifizierung und Vertrauensdienste für elektronische Transaktionen im Binnenmarkt und zur Aufhebung der Richtlinie 1999/93/EG eIDAS-VO 2014 [13] SOG-IS Crypto Evaluation Scheme – Agreed Cryptographic Mechanisms Version 1.2 vom Januar 2020 https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed- Cryptographic-Mechanisms-1.2.pdf [14] Fünftes Buch Sozialgesetzbuch (SGB V) - Gesetzliche Krankenversicherung - (Artikel 1 des Gesetzes vom 20. Dezember 1988, BGBl. I S. 2477), zuletzt geändert durch Artikel 6 des Gesetzes vom 28. Mai 2008 (BGBl. I S. 874) 9.6.3. Schutzprofile und Technische Richtlinien [15] Common Criteria Protection Profile: Card Operating System (PP COS G2), BSI-CC- PP-0082-V4-2019, 10.07.2019 und jede darauf angewandte Maintenance und Rezertifizierung, Bundesamt für Sicherheit in der Informationstechnik (BSI) [16] Common Criteria Schutzprofil (Protection Profile), Schutzprofil 2: Anforderungen an den Konnektor, BSI-CC-PP-0098, Version 1.6 vom 30.03.2022, Bundesamt für Sicherheit in der Informationstechnik (BSI) [17] Common Criteria Schutzprofil (Protection Profile), Schutzprofil 1: Anforderungen an den Netzkonnektor, BSI-CC-PP-0097, Version 1.6.6 vom 15.04.2021, Bundesamt für Sicherheit in der Informationstechnik (BSI) Security Target secunet konnektor 2.1.0 Seite 418 von 424 secunet [18] Technische Richtlinie TR-02102-3 Kryptographische Verfahren:Empfehlungen und Schlüssellängen, Teil 3 – Verwendung von Internet Protocol Security (IPsec) und Internet Key Exchange (IKEv2), Bundesamt für Sicherheit in der Informationstechnik, Version 2021-01 [19] Technische Richtlinie BSI TR-03116-1, Kryptographische Vorgaben für Projekte für der Bundesregierung, Teil 1: Telematikinfrastruktur, Bundesamt für Sicherheit in der Informationstechnik, Version 3.20, 21.09.2018, Technische Arbeitsgruppe TR-03116- 1 [20] Technische Richtlinie BSI TR-03144, eHealth – Konformitätsnachweis für Karten- Produkte der Kartengeneration G2, Bundesamt für Sicherheit in der Informationstechnik, Version 1.2, 27.07.2017, Bundesamt für Sicherheit in der Informationstechnik [21] BSI TR-03114 Technische Richtlinie für die Stapelsignatur mit dem Heilberufsausweis, Version 2.0, 22.10.2007, Bundesamt für Sicherheit in der Informationstechnik (BSI) [22] Protection Profile Electronic Health Card Terminal, BSI-PP-0032, Bundesamt für Sicherheit in der Informationstechnik (BSI), Version 2.10, 19.4.2013 [23] Technical Guideline TR-03111 Elliptic Curve Cryptography, TR-03111, Version 2.10, 01.06.2018, Bundesamt für Sicherheit in der Informationstechnik (BSI) [24] Technische Richtlinie BSI TR-03154, Konnektor – Prüfspezifikation für das Fachmodul NFDM, Version 1.1, 15.04.2019, Bundesamt für Sicherheit in der Informationstechnik [25] Technische Richtlinie BSI TR-03155, Konnektor – Prüfspezifikation für das Fachmodul AMTS, Version 1.1, 15.04.2019, Bundesamt für Sicherheit in der Informationstechnik [26] Technische Richtlinie BSI TR-03157, Konnektor – Prüfspezifikation für das Fachmodul ePA, Version 2.0.8, 02.05.2022, Bundesamt für Sicherheit in der Informationstechnik 9.6.4. Spezifikationen [27] Elektronische Gesundheitskarte und Telematikinfrastruktur: Spezifikation Konnektor [gemSpec_Kon], PTV5: Version 5.15.0, 31.01.2022, gematik GmbH [28] Elektronische Gesundheitskarte und Telematikinfrastruktur: Produkttypsteckbrief Konnektor [gemProdT_Kon_PTV5], Produkttyp Version: 5.1.0-0, Version 1.0.1, 10.02.2022, gematik GmbH [29] Elektronische Gesundheitskarte und Telematikinfrastruktur: Übergreifende Spezifikation: Spezifikation Netzwerk [gemSpec_Net], gematik GmbH, Version 1.21.0, 21.01.2022 Security Target secunet konnektor 2.1.0 secunet Seite 419 von 424 [30] Elektronische Gesundheitskarte und Telematikinfrastruktur - Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur [gemSpec_Krypt], gematik GmbH, Version 2.21.0, 31.01.2022 [31] Elektronische Gesundheitskarte und Telematikinfrastruktur: Spezifikation des Card Operating System (COS) Elektrische Schnittstelle [gemSpec_COS], Version 3.13.1, 01.11.2019, gematik GmbH [32] Elektronische Gesundheitskarte und Telematikinfrastruktur: Spezifikation der elektronischen Gesundheitskarte – eGK-Objektsystem [gemSpec_eGK_ObjSys], Version 3.13.0, 30.06.2021, gematik GmbH [33] Elektronische Gesundheitskarte und Telematikinfrastruktur: Spezifikation der gSMC- K / Objektsystem [gemSpec_gSMC-K_ObjSys], Version 3.13.0, 30.06.2021, gematik GmbH [34] Elektronische Gesundheitskarte und Telematikinfrastruktur. Spezifikation der gSMC- KT – Objektsystem [gemSpec_gSMC-KT_ObjSys], Version 4.2.0, 14.05.2018, gematik GmbH [35] Elektronische Gesundheitskarte und Telematikinfrastruktur: Spezifikation des elektronischen Heilberufsausweises – HBA-Objektsystem [gemSpec_HBA_ObjSys], Version 5.0.0, 10.09.2020, gematik GmbH [36] Elektronische Gesundheitskarte und Telematikinfrastruktur. Spezifikation der Security Module Card SMC-B Objektsystem [gemSpec_SMCB_ObjSys], Version 5.0.0, 10.09.2020, gematik GmbH [37] Elektronische Gesundheitskarte und Telematikinfrastruktur: Spezifikation Fachmodul VSDM [gemSpec_FM_VSDM], Version 2.6.0, 12.11.2020, gematik GmbH [38] Elektronische Gesundheitskarte und Telematikinfrastruktur. Spezifikation eHealth- Kartenterminal [gemSpec_KT], Version: 3.14.0, Stand: 31.01.2022, gematik GmbH [39] gestrichen [40] Elektronische Gesundheitskarte und Telematikinfrastruktur. Spezifikation TSL-Dienst [gemSpec_TSL]. Version 1.19.2, Stand 21.01.2022, gematik GmbH [41] Elektronsiche Gesundheitskarte und Telematikinfrastruktur. Spezifikation Verzeichnisdienst [gemSpec_VZD]. Version 1.14.0, Stand 31.01.2022, gematik GmbH [42] TeleTrusT: SICCT Secure Interoperable ChipCard Terminal, Version: 1.2.1, Date: 19.12.2010 mit ERRATA, Stand 12.9.2014, Version 1.0 Revision 1 [43] Elektronische Gesundheitskarte und Telematikinfrastruktur. Übergreifende Spezifikation: Operations und Maintenance [gemSpec_OM]. Version 1.14.0, Stand 26.06.2020, gematik GmbH Security Target secunet konnektor 2.1.0 Seite 420 von 424 secunet [44] Einführung der Gesundheitskarte: Übergreifende Spezifikation: Fachmodul NFDM [gemSpec_FM_NFDM], gematik GmbH, Version 1.6.2, 30.06.2021 [45] Einführung der Gesundheitskarte: Übergreifende Spezifikation: Fachmodul AMTS [gemSpec_FM_AMTS], gematik GmbH, Version 1.4.0, 15.05.2019 [46] Signaturrichtlinie QES, Notfalldaten-Management (NFDM) [gemRL_QES_NFDM], gematik GmbH, Version 1.4.1, 02.03.2020 [47] Informationsmodell Notfalldaten-Management (NFDM) [gemSpec_InfoNFDM], gematik GmbH, Version 1.6.0, 02.03.2020 [48] Spezifikation Schlüsselgenerierungsdienst ePA [gemSpec_SGD_ePA], gematik GmbH, Version 1.4.2, 19.02.2021 [49] Spezifikation Fachmodul ePA [gemSpec_FM_ePA], gematik GmbH, Version 1.11.0, 31.01.2022 [50] Spezifikation Festlegung von OIDs [gemSpec_OID], gematik GmbH, Version 3.10.0, 19.02.2021 9.6.5. Standards [51] D. Mills, U.Delaware, J. Martin, J.Burbank, W.Kasch: Network Time Protocol Version 4: Protocol and Algorithms Specification, June 2010, RFC 5905 (NTPv4), http://www.ietf.org/rfc/rfc5905.txt [52] J. Schaad, B. Kaliski, R. Housley: Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. June 2005, RFC 4055, http://www.rfc- editor.org/rfc/rfc4055.txt [53] K. Moriarty, B. Kaliski, J. Jonsson, A. Rusch: PKCS #1: RSA Cryptography Specifications Version 2.2. November 2016. RFC 8017, http://www.rfc- editor.org/rfc/rfc8017.txt [54] NIST: FIPS PUB 180-4 Secure Hash Signature Standard (SHS), March 2012 [55] NIST FIPS 197: Advanced Encryption Standard (AES). November 2001 [56] S. Kent, K. Seo: Security Architecture for the Internet Protocol, December 2005, RFC 4301 (IPsec), http://www.ietf.org/rfc/rfc4301.txt [57] S. Kent: IP Authentication Header, December 2005, RFC 4302 (AH), http://www.ietf.org/rfc/rfc4302.txt [58] S. Kent, R. Atkinson: IP Encapsulating Security Payload (ESP), November 1998, RFC 2406 (ESP), http://www.ietf.org/rfc/rfc2406.txt Security Target secunet konnektor 2.1.0 secunet Seite 421 von 424 [59] S. Kent: IP Encapsulating Security Payload (ESP), December 2005, RFC 4303 (ESP), http://www.ietf.org/rfc/rfc4303.txt [60] C. Kaufman, P.Hoffman, Y.Nir, P.Eronen, T. Kivinen: Internet Key Exchange Protocol Version 2 (IKEv2), October 2014, RFC 7296 (IKEv2), http://www.ietf.org/rfc/rfc7296.txt [61] S .Frankel, R. Glenn, S. Kelly: The AES-CBC Cipher Algorithm and Its Use with IPsec. September 2003, RFC 3602, http://www.rfc-editor.org/rfc/rfc3602.txt [62] C. Madson, R. Glenn: Use of HMAC-SHA-1-96 within ESP and AH, November 1998, RFC 2404, http://www.rfc-editor.org/rfc/rfc2404.txt [63] S. Kelly, S. Frankel: Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec. May 2007, RFC 4868, http://www.rfc-editor.org/rfc/rfc4868.txt [64] T. Kivinen, M.Kojo: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE). May 2003, RFC 3526, http://www.rfc- editor.org/rfc/rfc3526.txt [65] J. Viega, D. McGrew: The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP). June 2005, RFC 4106, http://www.rfc- editor.org/rfc/rfc4106.txt [66] R. Droms: Dynamic Host Configuration Protocol. March 1997, RFC 2131, http://www.ietf.org/rfc/rfc2131.txt [67] S. Alexandwer, R. Droms: DHCP Options and BOOTP Vendor Extensions. March 1997, RFC 2132, http://www.ietf.org/rfc/rfc2132.txt [68] RFC 8446 (August 2018): The Transport Layer Security (TLS) Protocol, Version 1.3 [69] RFC 5246 T. Dierks: The Transport Layer Security (TLS) Protocol, Version 1.2, August 2008 [70] Chown, P., Advanced Encryption Standard (AES) Cipher suites for Transport Layer Security (TLS), RFC 3268, June 2002 [71] Blake-Wilson, et al., Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS), RFC 4492, May 2006 [72] E. Rescorla, TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM), RFC 5289, August 2008 [73] R. Housley: Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type, RFC 5083, November 2007, https://tools.ietf.org/html/rfc5083 [74] R. Housley: Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS), RFC 5084, November 2007, https://tools.ietf.org/html/rfc5084 Security Target secunet konnektor 2.1.0 Seite 422 von 424 secunet [75] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997 [76] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 5280 (May 2008), http://www.ietf.org/rfc/rfc5280.txt [77] PKCS #12 v1.0: Personal Information Exchange Syntax. June 1999, RSA Laboratories [78] RFC 5652 (September 2009): Cryptographic Message Syntax (CMS), http://www.ietf.org/rfc/rfc5652.txt [79] XML Encryption Syntax and Processing, Version 1.1 W3C Recommendation, 11 April 2013, https://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/ [80] XML Signature Syntax and Processing (Second Edition), W3C Recommendation 10 June 2008, https://www.w3.org/TR/2008/REC-xmldsig-core-20080610/ [81] XML Path Language (XPath) 2.0 (Second Edition), W3C Recommendation, 14 December 2010, https://www.w3.org/TR/2010/REC-xpath20-20101214/ [82] XML Advanced Electronic Signatures (XAdES), European Telecommunications Standards Institute (ETSI): Technical Specication XML Advanced Electronic Signatures (XAdES). ETSI Technical Specication TS 101 903, Version 1.4.2, 2010/ [83] XSL Transformations (XSLT) Version 2.0, W3C Recommendation, 23 January 2007, https://www.w3.org/TR/2007/REC-xslt20-20070123/ [84] gestrichen [85] ETSI: Electronic Signature Formats, Electronic Signatures and Infrastructures (ESI) – Technical Specification, ETSI TS 101 733 V1.7.4, 2008-07, via http://www.etsi.org [86] European Telecommunications Standards Institute (ETSI): Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles; Part 3: PAdES Part 3: PAdES Enhanced – PAdES-BES and PAdES-EPES Profiles, ETSI TS 102 778-3 V1.1.2, Technical Specification, 2009 2009 [87] European Telecommunications Standards Institute (ETSI): Electronic Signatures and Infrastructure (ESI); XAdES Baseline Profile; ETSI Technical Specification TS 103 171, Version 2.1.1, 2012-03 [88] European Telecommunications Standards Institute (ETSI): Electronic Signatures and Infrastructure (ESI); CAdES Baseline Profile; ETSI Technical Specification TS 103 173, Version 2.1.1, 2012-03 [89] European Telecommunications Standards Institute (ETSI): Electronic Signatures and Infrastructure (ESI); PAdES Baseline Profile; ETSI Technical Specification TS 103 172, Version 2.1.1, 2012-03 Security Target secunet konnektor 2.1.0 secunet Seite 423 von 424 [90] K. Moriarty, B. Kaliski, J. Jonsson, A. Rusch: PKCS #1: RSA Cryptography Specifications Version 2.2, November 2016. RFC 8017, http://www.ietf.org/rfc/rfc8017.txt [91] NIST SP 800-38A: Recommendation for Block Cipher Modes of Operation: Methods and Techniques. December 2001 [92] NIST SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. November 2007 [93] ISO/IEC 8859-15:1998 - 8-bit single-byte coded graphic character sets, Part 15: Latin alphabet No. 9, published March 15, 1999 [94] TIFF Revision 6.0, http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf [95] Unicode Standard Version 6.2.0. http://www.unicode.org/versions/Unicode6.2.0/ [96] ISO 19005 – Document management – Electronic document file format for long-term preservation [97] ISO 19005-2:2011 – Document management – Electronic document file format for long-term preservation – Part 2: Use of ISO 32000-1 (PDF/A-2) [98] Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation 26 November 2008, https://www.w3.org/TR/xml/ [99] NIST 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, November 2007 [100] RFC 8422 (August 2018): Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier [101] RFC 5639 (March 2020): Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation, https://tools.ietf.org/html/rfc5639 [102] Standards for Efficient Cryptography, SEC 1: Elliptic Curve Cryptography, Certicom Research, Contact: Daniel R. L. Brown (dbrown@certicom.com), May 21, 2009, Version 2.0 https://www.secg.org/sec1-v2.pdf [103] RFC 5869 (May 2010): HMAC-based Extract-and-Expand Key Derivation Function (HKDF), https://tools.ietf.org/html/rfc5869 [104] RFC 5116 (January 2008): An Interface and Algorithms for Authenticated Encryption, https://tools.ietf.org/html/rfc5116 [105] NIST 800-56A: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, April 2018 [106] Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 http://docs.oasis-open.org/security/saml/v2.0/ Security Target secunet konnektor 2.1.0 Seite 424 von 424 secunet [107] RFC 4122 (July 2005): A Universally Unique IDentifier (UUID) URN Namespace, https://tools.ietf.org/html/rfc4122 [108] NIST: FIPS PUB 186-4, Digital Signature Standard (DSS), July 2013 [109] RFC 7027 (October 2013): Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS), http://www.ietf.org/rfc/rfc7027.txt 9.6.6. Dokumentation [110] secunet konnektor, Modularer Konnektor Version 2.0.0 und 2.1.0, Bedienungsanleitung, Für Administratoren und Benutzer, Version 6.1, Secunet Security Networks AG secunet konnektor, Modularer Konnektor Version 2.0.0 und 2.1.0, Bedienungsanleitung, Für Administratoren und Benutzer, Version 6.1, Errata der Bedienungsanleitung, Version 1.0, 27.06.2022, Secunet Security Networks AG [111] secunet konnektor, Modularer Konnektor Version 2.0.0 und 2.1.0, Hinweise und Prüfpunkte für Endnutzer, Version 1.8, Secunet Security Networks AG [112] secunet konnektor, Modularer Konnektor Version 2.0.0 und 2.1.0, Konnektor Management API-Dokumentation, Version 5.0.0, eHealth Experts GmbH [113] secunet konnektor, Signaturdirektive, Secunet Security Networks AG, Version 1.50, 24.06.2022 [114] secunet konnektor, Dokumentensicherheit, Secunet Security Networks AG, Version 1.21, 17.05.2022 [115] secunet konnektor, Verschlüsselungsdirektive, Secunet Security Networks AG, Version 2.0, 21.06.2022 [116] secunet konnektor, Security Guidance Fachmodulentwicklung, Version 1.5, eHealth Experts GmbH