Common Criteria Certification BSI-DSZ-CC-1068 BSI-CC-PP-0098 Security Target Konnektor KoCoBox MED+ OPB 2.1 Konnektor Version 2.3.24 KoCo Connector GmbH Dessauer Str. 28/29 10963 Berlin info@kococonnector.com Dokumentversion 1.27 2020-07-16 Vorwort Anmerkungen zur CC Zertifizierung Die vorliegende KoCoBox MED+ wird in zwei Verfahren zertifiziert: Das umfassende Verfahren nach [BSI-CC-PP-0098] beschreibt die gesamte Firmware des Konnektors. Dieses Schutzprofil fordert ei- ne Evaluierung nach AVA_VAN.3. Zusätzlich dazu gibt es ein zweites, spezialisiertes Verfahren, in dem die Anforderungen an die Komponente „Netzkonnektor“ spezifiziert werden. Dieses Verfahren wird nach den Vorgaben des Schutzprofils [BSI-CC-PP-0097] durchgeführt, das eine Evaluierung nach AVA_VAN.5 vorsieht. Das Schutzprofil [BSI-CC-PP-0097] stellt eine Teilmenge des Schutzprofils [BSI-CC-PP-0098] dar. Abbildung 0.1 zeigt schematisch, welche Teile des Konnektors von welchem Schutzprofil beschrieben werden und wie sich die Schutzprofile zueinander verhalten. Zur Vereinfachung der beiden Verfahren folgen die Security Targets der Struktur der Schutzprofile: Das Security Target für den Gesamtkonnektor [KoCo ASE_ST-98] enthält auch den gesamten Inhalt des Security Targets für den Netzkonnektor [KoCo ASE_ST-97]. Bis auf minimale orthographisch bedingte Abweichungen sind die Texte strukturell identisch. Lediglich an den Stellen, an denen auf den jeweiligen TOE Bezug genommen wird, weichen die Texte voneinander ab. Das Security Target des Netzkonnektors bezieht sich bei allen Bedrohungen, Annahmen, Sicherheits- zielen und Anforderungen auf (a) das Schutzprofil des Netzkonnektors und (b) auf genau die Teile des Schutzprofiles des Gesamtkonnektors, die sich auf den Netzkonnektor beziehen. Dieser doppelte Bezug wird angenommen, ohne eine formale Übereinstimmung zu behaupten. Das Security Target des Gesamtkonnektors hingegen bezieht sich an allen Stellen, die auch in [KoCo ASE_ST-97] beschrieben sind, ebenfalls auf beide Schutzprofile. Ziel dieser Maßnahme ist, dass ein Evaluator lediglich die Dokumente für den Gesamtkonnektor [KoCo ASE_ST-98] zugrunde legen muss, um den vorliegenden Evaluierungsgegenstand nach beiden Schutzprofilen, bzw. Security Targets bewerten zu können. Diese Einführung mit der Abgrenzung gegenüber den Schutzprofilen ersetzt nicht die formale Be- hauptung der Konformität zu einem Schutzprofil. Diese geht aus den Ausführungen in Kapitel 2 hervor. Anmerkungen zur TR Zertifizierung Die KoCoBox MED+ dient als Ablaufplattform für die Fachmodule NFDM und AMTS [gem- Spec_FM_NFDM; gemSpec_FM_AMTS]. Diese Fachmodule sind nicht Teil der Common Criteria Zertifizierung des Gesamtkonnektors. Stattdessen werden sie nach den Technischen Richtlinien Kon- nektor – Prüfspezifikation für das Fachmodul NFDM und Konnektor – Prüfspezifikation für das Fachmo- dul AMTS zertifiziert [TR-03154; TR-03155]. Die TR stellen Anforderungen an die CC-Zertifizierung des Konnektors: Der Konnektor muss bestimmte Eigenschaften aufweisen. Es ist Aufgabe des CC- Zertifzierers, die Erfüllung dieser Anforderungen zu bestätigen. 2 Obwohl keine formale Übereinstimmung mit den TR behauptet wird, spielen die TR eine wichti- ge Rolle für die CC-Zertifzierung. Das drückt sich in diesem Security Target dadurch aus, dass die Konformitätserklärung in Kapitel 2 um einen Abschnitt erweitert wurde. Weiterhin wird in Kapitel 8 beschrieben, wie die KoCoBox MED+ die Anforderungen erfüllt. Anmerkungen zur Spezifikationslage Die KoCoBox MED+ wurde nach der Spezifikation der gematik entwickelt. Dabei gelten die Spezifi- kationsdokumente in Tabelle 0.1. Dokument Version Datum Referenz Produkttypsteckbrief Konnektor, Produkttyp Version PTV3 3.6.0-2 1.0.0 4. März 2020 [gemProdT_Kon_PTV3_3.6.0-2] Spezifikation Konnektor 5.4.0 26. Okt. 2018 [gemSpec_Kon] Errata 1 zum Konnektor PTV 3 (eMP/AMTS, NFDM) 1.0.1 6. Feb. 2019 [gemErrata_1_Kon_PTV3] Errata 2 zum Konnektor PTV 3 (eMP/AMTS, NFDM) 1.0.0 6. Juni 2019 [gemErrata_2_Kon_PTV3] Errata 3 zum Konnektor PTV 3 (eMP/AMTS, NFDM) 1.0.0 2. Okt. 2019 [gemErrata_3_Kon_PTV3] Errata 4 zum Konnektor PTV 3 (eMP/AMTS, NFDM) 1.0.1 27. Nov. 2019 [gemErrata_4_Kon_PTV3] Errata 5 zum Konnektor PTV 3 (eMP/AMTS, NFDM) 1.0.0 4. Feb. 2020 [gemErrata_5_Kon_PTV3] Errata 6 zum Konnektor PTV 3 (eMP/AMTS, NFDM) 1.0.0 4. März 2020 [gemErrata_6_Kon_PTV3] Tabelle 0.1.: Spezifikationsdokumente der KoCoBox MED+ 3 KoCoBox MED+ Hardware gSMC-K#1, #2, #3 JVM der Fachmodule TSF nach BSI-CC-PP-0098 TSF nach BSI-CC-PP-0097 TOE nach BSI-CC-PP-0097 und BSI-CC-PP-0098 non-TSF JVM des Anwendungs- konnektors Kernel, non-Java Anteile des NK non- TSF JVM des Netzkonnektors non- TSF Abbildung 0.1.: Abgrenzung der Verfahren zu BSI-CC-PP-0097 und BSI-CC-PP-0098 4 Inhaltsverzeichnis 1. Einführung in das Security Target 11 1.1. ST Referenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2. TOE Referenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.3. Überblick über den TOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.3.1. TOE Typ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.3.2. Verwendung und Hauptfunktionalität des TOE . . . . . . . . . . . . . . . . 12 1.3.3. Erforderliche Non-TOE Hardware/Software/Firmware . . . . . . . . . . . . 12 1.4. Beschreibung des TOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.4.1. Hauptziele des TOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.4.2. Aufbau des TOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.4.3. Einsatzumgebung des TOE . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.4.4. Hardware der KoCoBox MED+ . . . . . . . . . . . . . . . . . . . . . . . 16 1.4.5. Schnittstellen des Konnektors . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.4.6. Aufbau und physische Abgrenzung des Konnektors OPB 2.1 . . . . . . . . . 23 1.4.7. Logische Abgrenzung: Vom TOE erbrachte Sicherheitsdienste . . . . . . . . 24 1.4.8. Physischer Umfang des TOE . . . . . . . . . . . . . . . . . . . . . . . . . 26 2. Postulat der Übereinstimmung 28 2.1. Konformität zu Common Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2. Konformität zu Schutzprofilen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.3. Konformität zu Paketen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.4. Erklärung der Konformität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.5. Konformität zu Technischen Richtlinien für Fachmodule . . . . . . . . . . . . . . . 29 3. Definition des Sicherheitsproblems 30 3.1. Werte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.1.1. Zu Schützende Werte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.1.2. Benutzer des TOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.2. Bedrohungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3. Organisatorische Sicherheitspolitiken des Netzkonnektors . . . . . . . . . . . . . . 30 3.4. Organisatorische Sicherheitspolitiken des Anwendungskonnektors . . . . . . . . . . 31 3.5. Annahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4. Sicherheitsziele 32 4.1. Sicherheitsziele für den Netzkonnektor . . . . . . . . . . . . . . . . . . . . . . . . 32 4.1.1. Allgemeine Ziele: Schutz und Administration . . . . . . . . . . . . . . . . 32 4.1.2. Ziele für die VPN Funktionalität . . . . . . . . . . . . . . . . . . . . . . . 33 4.1.3. Ziele für die Paketfilter-Funktionalität . . . . . . . . . . . . . . . . . . . . 33 5 4.2. Sicherheitsziele für den Anwendungskonnektor . . . . . . . . . . . . . . . . . . . . 33 4.2.1. Allgemeine Sicherheitsziele . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2.2. Signaturdienst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.2.3. Gesicherte Kommunikation / TLS Proxy . . . . . . . . . . . . . . . . . . . 35 4.2.4. Terminal- und Chipkartendienst . . . . . . . . . . . . . . . . . . . . . . . 35 4.2.5. Verschlüsselungsdienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.2.6. Fachmodul VSDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3. Sicherheitsziele für die Umgebung des Netzkonnektors . . . . . . . . . . . . . . . . 36 4.4. Sicherheitsziele für die Umgebung des Anwendungskonnektors . . . . . . . . . . . . 37 4.5. Erklärung der Sicherheitsziele des Netzkonnektors . . . . . . . . . . . . . . . . . . 39 4.5.1. Abbildung der Bedrohungen, OSPs und Annahmen auf Ziele . . . . . . . . 39 4.6. Erklärung der Sicherheitsziele des Anwendungskonnektors . . . . . . . . . . . . . . 41 5. Definition der erweiterten Komponenten 42 5.1. Definition der erweiterten Familie FCS_RNG . . . . . . . . . . . . . . . . . . . . . 42 5.2. Definition der erweiterten Familie FPT_EMS . . . . . . . . . . . . . . . . . . . . . 43 5.3. Definition der erweiterten Familie FIA_API . . . . . . . . . . . . . . . . . . . . . . 43 6. Sicherheitsanforderungen 44 6.1. Hinweise und Definitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 6.1.1. Hinweise zur Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 6.1.2. Modellierung von Subjekten, Objekten, Attributen und Operationen . . . . . 44 6.2. Funktionale Sicherheitsanforderungen des Netzkonnektors . . . . . . . . . . . . . . 46 6.2.1. VPN Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 6.2.2. Dynamischer Paketfilter mit zustandsgesteuerter Filterung . . . . . . . . . . 46 6.2.3. Netzdienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.2.4. Stateful Packet Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.2.5. Selbstschutz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.2.6. Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.2.7. Kryptographische Basisdienste . . . . . . . . . . . . . . . . . . . . . . . . 55 6.2.8. TLS-Kanäle unter Nutzung sicherer kryptographischer Algorithmen . . . . . 57 6.2.9. Zusätzliche Sicherheitsanforderungen . . . . . . . . . . . . . . . . . . . . . 62 6.3. Funktionale Sicherheitsanforderungen des Anwendungskonnektors . . . . . . . . . . 64 6.3.1. Klasse FCS: Kryptographische Unterstützung . . . . . . . . . . . . . . . . . 64 6.3.2. Klasse FIA: Identifikation und Autorisierung . . . . . . . . . . . . . . . . . 68 6.3.3. Klasse FDP: Schutz der Benutzerdaten . . . . . . . . . . . . . . . . . . . . 71 6.3.4. Klasse FMT: Sicherheitsmanagement . . . . . . . . . . . . . . . . . . . . . 96 6.3.5. Klasse FPT: Schutz der TSF . . . . . . . . . . . . . . . . . . . . . . . . . . 98 6.3.6. Klasse FAU: Sicherheitsprotokollierung . . . . . . . . . . . . . . . . . . . . 101 6.4. Sicherheitsanforderungen an die Vertrauenswürdigkeit des EVG . . . . . . . . . . . 104 6.4.1. Verfeinerung zur Vertrauenswürdigkeitskomponente ADV_ARC.1 . . . . . . . 104 6.4.2. Verfeinerung zur Vertrauenswürdigkeitskomponente AGD_OPE.1 . . . . . . 104 6.4.3. Verfeinerung zur Vertrauenswürdigkeitskomponente ALC_DEL.1 . . . . . . . 104 6.4.4. Verfeinerung zur Vertrauenswürdigkeitskomponente AGD_PRE.1 . . . . . . . 104 6.4.5. Verfeinerung für die Integration der Fachmodule NFDM und AMTS . . . . 104 6 6.5. Erklärung der Sicherheitsanforderungen . . . . . . . . . . . . . . . . . . . . . . . . 105 6.5.1. Erklärung der Abhängigkeiten der SFR des Netzkonnektors . . . . . . . . . 105 6.5.2. Überblick der Abdeckung von Sicherheitszielen des Netzkonnektors . . . . . 106 6.5.3. Detaillierte Erklärung für die Sicherheitsziele des Netzkonnektors . . . . . . 106 6.5.4. Erklärung der Abhängigkeiten der SFR des Anwendungskonnektors . . . . . 108 6.5.5. Überblick der Abdeckung von Sicherheitszielen des Anwendungskonnektors 108 6.5.6. Detaillierte Erklärung für die Sicherheitsziele des Anwendungskonnektors . . 108 6.6. Erklärung für Erweiterung der Sicherheitsanforderungen . . . . . . . . . . . . . . . 108 6.7. Erklärung für die gewählte EAL-Stufe . . . . . . . . . . . . . . . . . . . . . . . . 109 7. ASE_TSS: Basiskonnektor 110 7.1. TOE Sicherheitsfunktionen des Netzkonnektors . . . . . . . . . . . . . . . . . . . . 110 7.1.1. VPN-Client (SF.VPN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 7.1.2. Dynamischer Paketfilter (SF.DynamicPacketFilter) . . . . . . . . . . . . . 111 7.1.3. Netzbasierte Sicherheitsfunktionen (SF.NetworkServices) . . . . . . . . . 113 7.1.4. Selbstschutz (SF.SelfProtection/NK) . . . . . . . . . . . . . . . . . . . . 113 7.1.5. Protokollierungsdienst/NK (SF.Audit/NK) . . . . . . . . . . . . . . . . . . 115 7.1.6. Administration/NK (SF.Administration/NK) . . . . . . . . . . . . . . . . 115 7.1.7. Kryptografische Dienste/NK (SF.CryptographicServices/NK) . . . . . . . . 116 7.2. TOE Sicherheitsfunktionen des Konnektors . . . . . . . . . . . . . . . . . . . . . . 119 7.2.1. Kryptografische Dienste/AK (SF.CryptographicServices/AK) . . . . . . . . 119 7.2.2. TLS Protokoll (SF.TLS) . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 7.2.3. Authentisierung (SF.Authentication) . . . . . . . . . . . . . . . . . . . . 120 7.2.4. Zugriffssteuerung (SF.AccessControl) . . . . . . . . . . . . . . . . . . . . 121 7.2.5. Management der eHealth-Kartenterminals (SF.CardTerminalMgmt) . . . . 122 7.2.6. Management der Smart Cards (SF.SmartCardMgmt) . . . . . . . . . . . . 123 7.2.7. Signaturdienst (SF.SignatureService) . . . . . . . . . . . . . . . . . . . . 124 7.2.8. Verschlüsselungsdienst (SF.EncryptionService) . . . . . . . . . . . . . . . 128 7.2.9. Sicherer Speicher (SF.SecureStorage) . . . . . . . . . . . . . . . . . . . . 129 7.2.10. Versichertenstammdatenmanagement (SF.VSDM) . . . . . . . . . . . . . . 130 7.2.11. Administration/AK (SF.Administration/AK) . . . . . . . . . . . . . . . . . 130 7.2.12. Selbstschutz (SF.SelfProtection/AK) . . . . . . . . . . . . . . . . . . . . . 131 7.2.13. Protokollierungsdienst/AK (SF.Audit/AK) . . . . . . . . . . . . . . . . . . 133 7.3. Verhältnis von SFR zu SF des Netzkonnektors . . . . . . . . . . . . . . . . . . . . 134 7.4. Verhältnis von SFR zu SF des Konnektors . . . . . . . . . . . . . . . . . . . . . . 136 8. ASE_TSS: Fachmodule 139 8.1. Erklärung der Konformität zu Technischen Richtlinien . . . . . . . . . . . . . . . . 139 8.1.1. Fachmodule NFDM und AMTS / OPB 2.1 . . . . . . . . . . . . . . . . . . 139 8.2. Umsetzung der TUCs an LS.FM im Basiskonnektor . . . . . . . . . . . . . . . . . 140 A. Erklärung der tabellarischen Darstellung 146 B. TLS Verbindungen 147 C. Composition Requirements für Fachmodule 150 7 D. Anforderungen zur sicherheitstechnischen Eignung 152 8 Tabellenverzeichnis 0.1. Spezifikationsdokumente der KoCoBox MED+ . . . . . . . . . . . . . . . . . . . . 3 1.1. Logische Schnittstellen an LS.LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.2. Logische Schnittstellen an LS.WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.3. Logische Schnittstellen an LS.VPN_TI . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.4. Logische Schnittstellen an LS.VPN_SIS . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.5. Logische Schnittstellen an LS.FM . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 1.6. Physischer Umfang des TOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.1. Ergänzungen zur Vertrauenswürdigkeit EAL3 . . . . . . . . . . . . . . . . . . . . . 28 4.1. Abbildung der Sicherheitsziele des Netzkonnektors auf Bedrohungen und Annahmen 40 6.1. Typographische Konventionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 6.2. Algorithms, Key sizes and Purposes of Signature Verification . . . . . . . . . . . . 63 6.3. Abbildung der Sicherheitsziele des NK auf Sicherheitsanforderungen . . . . . . . . . 108 7.1. Signaturvarianten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 7.2. Abbildung der SFR des NK auf Sicherheitsfunktionalität . . . . . . . . . . . . . . . 135 7.3. Abbildung der SFR des AK auf Sicherheitsfunktionalität . . . . . . . . . . . . . . . 138 8.1. Umsetzung der TUCs für Fachmodule . . . . . . . . . . . . . . . . . . . . . . . . 141 8.2. Funktionen des Basiskonnektors für die Fachmodule . . . . . . . . . . . . . . . . . 145 A.1. Legende der Abbildungstabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 B.1. Cipher Suites der TLS Verbindungen des Konnektors . . . . . . . . . . . . . . . . . 147 B.2. Elliptische Kurven für die TLS Verbindungen des Konnektors . . . . . . . . . . . . 147 B.3. Legende zu den TLS Verbindungen . . . . . . . . . . . . . . . . . . . . . . . . . . 148 B.4. TLS Verbindungen der KoCoBox MED+ . . . . . . . . . . . . . . . . . . . . . . . 149 D.1. Erweiterung des ST durch neue Anforderungen aus PTV3 . . . . . . . . . . . . . . 152 9 Abbildungsverzeichnis 0.1. Abgrenzung der Verfahren zu BSI-CC-PP-0097 und BSI-CC-PP-0098 . . . . . . . 4 1.1. Gehäuse der KoCoBox MED+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2. Einsatzumgebung der KoCoBox MED+ . . . . . . . . . . . . . . . . . . . . . . . . 15 1.3. Hardware-Komponenten der KoCoBox MED+ . . . . . . . . . . . . . . . . . . . . 17 10 1. Einführung in das Security Target Der TOE, der in diesem Dokument beschrieben wird, ist der KoCoBox MED+ OPB 2.1 Konnektor. Der TOE ist eine sichere Komponente, die im Kontext der Telematikinfrastruktur als Konnektor eingesetzt wird. Dieses Dokument ist das Security Target, in dem die funktionalen und organisatorischen Sicherheits- anforderungen des TOE und seiner Einsatzumgebung beschrieben werden. Dieses Dokument findet seine formale Grundlage in: • Schutzprofil 2: Anforderungen an den Konnektor [BSI-CC-PP-0098] Darüber hinaus gibt es – wie im Vorwort beschrieben – eine enge Verwandtschaft zum Dokument Schutzprofil 1: Anforderungen an den Netzkonnektor [BSI-CC-PP-0097]. 1.1. ST Referenz Titel des Dokuments Security Target / Konnektor Version des Dokuments 1.27 Datum des Dokuments 16.07.2020 Allgemeiner Status: Verfeinerung nach der Einreichung für den Antrag des Zertifizie- rungsverfahrens Autor KoCo Connector GmbH Editor n-design GmbH, OS-Cillation GmbH 1.2. TOE Referenz Evaluierungsgegenstand KoCoBox MED+ OPB 2.1 Konnektor Version des EVG 2.3.24 Hersteller KoCo Connector GmbH Vertrauenswürdigkeitsstufe EAL3 erweitert um AVA_VAN.3, ADV_IMP.1, ADV_TDS.3, ADV_FSP.4, ALC_TAT.1, and ALC_FLR.2 (Kurzbezeichnung „EAL3+“) CC Version 3.1 Release 5 11 1.3. Überblick über den TOE Der Evaluierungsgegenstand ist der Konnektor für den Online Produktivbetrieb Stufe 2.1. Der TOE umfasst folgende Komponenten: • den Netzkonnektor • den Anwendungskonnektor • das Fachmodul „Versichertenstammdatenmanagement“ (VSDM) Der Lieferumfang des TOE umfasst ebenfalls die Betriebsdokumentation für den Konnektor. Somit entspricht der TOE dem im Schutzprofil [BSI-CC-PP-0098] genannten Umfang und Aufbau.1 Darüber hinaus entspricht der TOE auch dem im Schutzprofil für den Netzkonnektor definierten Funktionsum- fang [BSI-CC-PP-0097]. 1.3.1. TOE Typ Die KoCoBox MED+ implementiert – konform zu [BSI-CC-PP-0098; BSI-CC-PP-0097] – den Pro- dukttyp Konnektor. 1.3.2. Verwendung und Hauptfunktionalität des TOE Der TOE ist eine sichere Komponente, die in der Telematikinfrastrukur als Konnektor eingesetzt wird. Die Funktionalität der KoCoBox MED+ geht aus der Konnektor-Spezifikation der gematik [gemSpec_Kon] hervor. Darüber hinaus finden weitere Spezifikationen der gematik Beachtung [gem- Spec_Krypt]. Die Sicherheitsanforderungen spezifiziert das BSI in [BSI-CC-PP-0098; BSI-CC-PP- 0097]. Die KoCoBox MED+ besteht aus ihrer Firmware (inklusive Betriebssystem und Anwendungssoft- ware) und der Hardwareplattform, einem herstellerspezifischen Design. Für die Zertifizierung wird nur die Firmware der KoCoBox MED+ betrachtet. Die KoCoBox MED+ ist speziell entwickelt für Anwendungsfälle niedergelassener Ärzte, Kliniken und Apotheken.2 Sie kann in IT-Umgebungen eingesetzt werden, die weitgehend ohne Administrator auskommen. 1.3.3. Erforderliche Non-TOE Hardware/Software/Firmware Der TOE benötigt für den Betrieb verschiedene Komponenten. Als reiner Software-TOE muss die pas- sende Hardware vorhanden sein. Der TOE ist auf die herstellereigene Hardware der KoCoBox MED+ angewiesen und kann nicht auf generischer Hardware betrieben werden. Die kryptographischen Identitäten des Konnektors werden durch drei Smart Card basierte Sicher- heitsmodule (gSMC-K) bereitgestellt, die in den internen Kartensteckplätzen des Konnektors installiert sind. Diese Smart Cards werden im Produktionsprozess eingebaut und sind nicht austauschbar. Weder Endbenutzer noch geschultes Service-Personal können die gSMC-K ersetzen. Die Manipulation oder das Entfernen der Smart Cards führt zur Außerbetriebssetzung des Geräts. Die Smart Cards sind nicht 1 Allerdings sieht das Schutzprofil den Online-Rollout (Stufe 1) vor. Der TOE setzt einen neuen Stand der Spezifikation um. 2 Im folgenden wird der Einfachheit halber angenommen, dass die Einsatzumgebung eine Arztpraxis ist. 12 Teil des TOE, sondern gehören zur Einsatzumgebung. Sie werden separat zertifiziert, vgl. [BSI-CC- PP-0082-2] und im Rahmen dieses Dokuments nicht weiter bewertet. Sowohl die Hardware als auch die gSMC-K gehören zum Lieferumfang der KoCoBox MED+. 1.4. Beschreibung des TOE 1.4.1. Hauptziele des TOE Der Konnektor wurde als Bindeglied zwischen den Praxisverwaltungssystemen im LAN des Leistungs- erbringers und der Telematikinfrastruktur entwickelt. Der Konnektor setzt zwei Hauptziele um: Erstens stellt er eine sichere Verbindung zwischen den dezentralen und den zentralen Komponenten der Tele- matikinfrastruktur bereit; zweitens kontrolliert er die eHealth-Kartenterminals und Smart Cards, die eine fundamentale Rolle im Sicherheitskonzept der Telematikinfrastruktur spielen. Darüber hinaus im- plementiert der TOE verschiedene Fachanwendungen und eine Signaturanwendung. Der vorliegende TOE setzt alle diese Ziele um. Sichere Verbindung in die Telematikinfrastruktur Das erste Ziel ist, eine sichere Verbindung zur Telematikinfrastruktur bereitzustellen, die durch dyna- mische Paketfilter und Smart Card basiertes VPN abgesichert ist. Der Konnektor schützt sich selbst und die Telematikinfrastruktur vor Angriffen aus dem LAN des Leistungserbringers. Weiterhin schützt er die Komponenten im LAN vor Angriffen aus dem WAN. Darüber hinaus stellt der Konnektor einen VPN-Tunnel zu einem sicheren Internetgateway (Secure Internet Service, SIS) zur Verfügung. Über diesen abgesicherten Internetzugang haben die Kompo- nenten im LAN des Leistungserbringers einen abgesicherten und kontrollierten Zugang zum Internet, unter Umgehung des direkten WAN Zugangs über den DSL-Anschluss3 der Praxis. Kontrolle von Kartenterminals und Smart Cards Das zweite Hauptziel ist, eine kontrollierte Verwendung der Aktoren im Umfeld der Telematikinfra- struktur zu ermöglichen. Die Aktoren in diesem Fall sind u. a. der Heilberufeausweis (HBA), die Institutionskarte (Smart Module Card-B, SMC-B) und die elektronische Gesundheitskarte (eGK). Doch auch die Smart Cards des Konnektors (vom Typ gSMC-K) enthalten kryptographische Iden- titäten für die Authentisierung und Identifikation gegenüber anderen Teilen der Infrastruktur: z. B. den VPN-Konzentratoren, eHealth-Kartenterminals und Clientsystemen. Darüber hinaus werden die Smart Cards auch zur Verschlüsselung und für Signaturen verwendet. Signaturkomponente und Dokumentenverschlüsselung Zusätzlich zu diesen Hauptzielen stellt der Konnektor noch eine Signaturerstellungskomponente bereit. Diese Komponente kann qualifizierte und nicht-qualifizierte elektronische Signaturen sowohl erzeugen als auch verifizieren. Der im Konnektor vorhandene Verschlüsselungsdienst kann von Produkten im LAN des Leistungserbringers verwendet werden, um Dokumente zu ver- und zu entschlüsseln. Das kryptographische Material, das in diese Prozesse eingeht, stammt von den Smart Cards, die der Kon- nektor kontrolliert. 3 oder eine andere Zugangstechnologie 13 Abbildung 1.1.: Gehäuse der KoCoBox MED+ 1.4.2. Aufbau des TOE Der TOE ist ein reines Softwareprodukt. Er besteht aus der Firmware der KoCoBox MED+. Der Konnektor ist logisch aufgeteilt in zwei Bestandteile: Den Netzkonnektor (NK) und den Anwendungs- konnektor (AK). Der Anwendungskonnektor enthält das Fachmodul VSDM. Die KoCoBox MED+ ist als eine Ein-Box Lösung ausgelegt. In der Spezifikation des Konnektors bezeichnet dieser Begriff ein Gerät, bei dem alle relevanten Komponenten in einem einzigen Gehäuse untergebracht sind. Das Ge- häuse enthält sowohl den Netz-, als auch den Anwendungskonnektor. Das Gehäuse ist in Abbildung 1.1 dargestellt. Das Gerät besteht neben der Software, die den TOE ausmacht, noch aus der Hardware. Die Hard- ware ist herstellerspezifisch. Die Software, die den TOE ausmacht, muss auf genau dieser Hardware betrieben werden. Der TOE benutzt die Hardware als Einsatzumgebung. Ebenso zur Einsatzumgebung gehören die drei im Gehäuse vorhandenen Smart Cards vom Typ gSMC-K. Die drei Secure Module Cards sind nicht Teil des TOE. Sie werden in diesem Security Target nicht beschrieben. Das Betriebssystem der KoCoBox MED+ ist GNU/Linux. Teile des Betriebssystems setzen Sicher- heitsanforderungen an den TOE um und sind somit SFR-enforcing. Das betrifft vor allem den TCP/IP- Stack, den Netfilter und das IPsec Protokoll. Der TOE ist in verschiedenen Programmiersprachen implementiert: C/C++, Shell-Skripte und Java. Der Produkttyp und die Aufteilung der Funktionalität auf die einzelnen Systemkomponenten und 14 Abbildung 1.2.: Einsatzumgebung der KoCoBox MED+ die Funktionsblöcke werden in [BSI-CC-PP-0097; BSI-CC-PP-0098, Abschnitt 1.3.1] beschrieben. 1.4.3. Einsatzumgebung des TOE Die Einsatzumgebung des TOE wird im Schutzprofil definiert [BSI-CC-PP-0098, Abschnitt 1.3.2]. Die dort gemachten Aussagen gelten ohne Anpassung für dieses Security Target. Die aus dem Schutzprofil übernommene Abbildung 1.2 zeigt die Einsatzumgebung des Konnektors. Um die Telematikinfrastruktur gegen Angriffe aus dem LAN zu schützen, implementiert der TOE einen dynamischen Paketfilter, der auf beiden Ethernetschnittstellen (LAN und WAN) die ein- und aus- gehenden Pakete überwacht. Derselbe Paketfilter schützt auch den TOE selbst, ebenfalls vor Angriffen aus dem LAN oder WAN. Der Konnektor verbindet das LAN mit potenziell unsicheren Netzwerken wie dem Internet, die über das WAN Interface erreichbar sind. Der Konnektor stellt folglich das einzige Gateway des LAN ins WAN dar. 4 Die Verbindung zwischen dem Konnektor und den gekoppelten eHealth Kartenterminals ist eine durch gegenseitige Authentisierung abgesicherte Verbindung. Komponenten der Einsatzumgebung Das sichere Funktionieren des Konnektors hängt vom Vorhandensein bestimmter Komponenten in der Einsatzumgebung ab. Solche Komponenten sind Hardware, Software und andere vertrauenswürdige IT-Produkte: KoCoBox MED+ Hardware Der TOE als reines Softwareprodukt benötigt eine Hardware- Laufzeitumgebung, innerhalb derer die Programme des TOE ausgeführt werden können. 3 × STARCOS 3.6 Health SMCK R1 Vertrauenswürdige Smart Cards vom Typ gSMC-K mit der Zertifizierungs-ID BSI-DSZ-CC-0916-2015. Der Konnektor unterstützt drei Karten dieser Art, um die Performance bei kryptographischen Operationen zu steigern. Telematikinfrastruktur Die TI wird von der gematik bereitgestellt. Sie ist für den TOE über das WAN Interface erreichbar. Die TI wird über die gematik Spezifikation „OPB 2.1“ definiert. 4 Ausnahmen hiervon werden in der Konnektorspezifikation beschrieben [gemSpec_Kon, Anhang K]. In solchen Situationen – wie dort in Szenario 3 beschrieben – muss sichergestellt sein, dass das vorhandene Gateway abgesichert ist und nicht kompromittiert werden kann. 15 SIS Der sichere Internet-Service ist ein dedizierter VPN-Konzentrator, der über das WAN Interface des Konnektors erreichbar ist. Der SIS wird über die gematik Spezifikation „OPB 2.1“ definiert. Web-Browser Der Konnektor wird über eine Web-Anwendung administriert. Diese Administrator- schnittstelle erlaubt authentisierten Benutzern, verschiedene Management-Aufgaben zu erledi- gen. Diese Aufgaben sind z. B. das Einspielen aktueller Firmware, Anpassung der Konfigurati- onsparametern, und das Auslesen diagnostischer Informationen. Der Browser des Administrators gehört zur Einsatzumgebung und wird hier nicht bewertet. Die Verbindung eines Administrator- Arbeitsplatzes zu der Web-Anwendung ist immer über HTTPS abgesichert. Clientsysteme Praxisverwaltungssysteme, die die Funktionen des Konnektors nutzen, müssen die Programmierschnittstellen des Konnektors befolgen [gemWSDL]. Die Anwendung dieser for- malen Definition ist im Implementierungsleitfaden der gematik für Clientsysteme beschrieben [gemILF_PS]. Anforderungen an die Sicherheit der Einsatzumgebung Der Konnektor soll in einem zutrittsgeschützten Bereich der Praxis betrieben werden und nur von vertrauenswürdigem und geschulten Personal benutzt werden. Daraus folgen einige Sicherheitsanfor- derungen an die Einsatzumgebung: Identifikation eines physischen Angriffs Die Einsatzumgebung muss in der Lage sein, den Zugang eines Angreifers und die Manipulation an der Hardware des Geräts zu identifizieren. Geschützter Betrieb Wenn das Gerät gestartet und betriebsbereit ist, muss die Einsatzumgebung den Zugang zum Konnektor verhindern. Das kann durch organisatorische, aber auch durch tech- nische Maßnahmen erfolgen. Organisatorische Maßnahmen sind z. B. die regelmäßige Prüfung der Unversehrtheit des Betriebsraums; technische Maßnahmen sind z. B. die Installation einer Alarmanlage. Befolgen anerkannter Sicherheitsregeln Regeln, die im IT-Grundschutz [BSI-GS] oder den Richtlinien der BÄK [BÄK-DV] formuliert sind, müssen angewendet werden. 1.4.4. Hardware der KoCoBox MED+ Abbildung 1.3 auf Seite 17 zeigt die Hardware-Komponenten, aus denen sich die Laufzeitumgebung des TOE zusammensetzt. Alle Teile des TOE werden durch die CPU des System-on-a-chip ausgeführt. Der TOE kann nicht auf anderen Hardware-Plattformen betrieben werden. Die logischen Schnittstellen des TOE sind in dem Diagramm als von außen an die Systemkompo- nenten heranreichende Pfeile repräsentiert. Die entsprechenden physischen Schnittstellen sind in den äußeren Komponenten eingetragen. Die Real-Time-Clock (RTC) wird vom TOE verwendet, um zu- verlässige Zeitstempel zu erzeugen. Die Uhr ist batteriegepuffert, um die korrekte Uhrzeit zu erhalten, wenn die KoCoBox MED+ vom Strom getrennt ist. Die 2 GB RAM bilden den flüchtigen Arbeitsspeicher. Der persistente NAND-Flash Speicher befin- det sich auf einer Speicherkarte (embedded Multimedia Card eMMC). Dieser Speicher ist 4 GB groß. Der 4 MB große NOR-Flash enthält den Bootloader. Der duale Ethernet-Controller unterscheidet zwischen den zwei physischen Schnittstellen für das LAN (PS.LAN) und das WAN (PS.WAN). Für jede Schnittstelle wird ein eigener Port an der Außenseite 16 Abbildung 1.3.: Hardware-Komponenten der KoCoBox MED+ des Geräts angeboten. Jeder Port hat seine eigene MAC-Adresse. Der Controller erhält die Ethernet- Frames und ordnet die Frames dem jeweiligen Port zu. Der Controller stellt sicher, dass Frames nicht zwischen den Ports ausgetauscht weden. Basierend auf Port und MAC-Adresse bietet der TOE eindeu- tige Schnittstellen für jeden Port. Die Tasten und das Display werden verwendet um Statusinformationen über die KoCoBox MED+ abzurufen. Weiterhin kann hierüber ein Neustart des Geräts ausgelöst werden. Der Mini-USB Anschluss (USB On-the-Go, OTG) wird verwendet, um im Produktionsprozess die Firmware des Bootloader in die KoCoBox MED+ einzubringen. Für diesen Vorgang muss der SoC Pin für das Booten von USB-Medien während des Resets verbunden sein. Nur in diesem Fall handelt das SoC als ein USB-Gerät, sodass neue Firmware in den NOR-Flash Speicher geladen werden kann. Danach kann der Konnektor mit dem neuen Bootloader neugestartet werden. Der Pin am SoC ist ei- ne interne Schnittstelle, deren Benutzung direkten Zugriff auf die Platine benötigt. Dieser Weg eine Firmware einzuspielen wird nur in der Fertigung verwendet und im Verlauf der Fertigung durch Fuses in der Hardware komplett deaktiviert. Somit ist sie während des Betriebs der KoCoBox MED+ nicht erreichbar. Als zusätzliche Schutzmaßnahme prüft der SoC vor dem Start die Signatur des Bootloader (High Assurance Boot, HAB). Danach werden durch weitere Verifizierungen von Signaturen zuerst der Kernel und das Initramfs und dann im Initramfs alle anderen Firmwareanteile auf ihre Integrität geprüft. 17 Der Micro SD-Kartenslot ist für zukünftige Anwendungszwecke vorgesehen. Er wird in der zertifi- zierten Konfiguration des TOE als alternatives Bootmedium verwendet. Der Kartenslot ist außerhalb des Geräts nicht zu erreichen. Die UART-Schnittstelle zum Anschluss einer seriellen Konsole wird nicht benutzt. Sie ist über Soft- ware deaktiviert, sodass weder Eingaben noch Ausgaben darüber möglich sind. 1.4.5. Schnittstellen des Konnektors 1.4.5.1. Physische Schnittstellen Alle Schnittstellen des Konnektors sind physisch am Gehäuse des Geräts untergebracht. Die folgen- de Liste bezieht sich auf die Liste der Schnittstellen, wie sie im Schutzprofil des Gesamtkonnektors [BSI-CC-PP-0098, Abschnitt 1.3.3.1] angegeben ist. Die Schnittstellen sind im Kontext der Systemar- chitektur in Abbildung 1.3 aufgeführt, die außen sichtbaren Schnittstellen sind auf dem Foto des TOE in Abbildung 1.1 zu erkennen (vgl. Anwendungshinweis 5 des Schutzprofils). Die Schnittstelle PS.DISPLAY ist zusätzlich aufgenommen. Hier erneut der Hinweis, dass der Evaluie- rungsgegenstand ein reines Softwareprodukt ist. Dennoch weist das Schutzprofil an, dass die physischen Außenschnittstellen des Geräts beschrieben werden sollen. PS.LAN ist die Schnittstelle ins LAN und zu den Clientsystemen. Obwohl der Netzkonnektor selbst nicht direkt mit den Clientsystemen kommuniziert, stellt er die LAN-Schnittstelle zur Verfügung, die wiederum von Anwendungskonnektor verwendet wird, um mit Infrastruktur-Komponenten im LAN zu kommunizieren. Diese Schnittstelle stellt abhängig von der Konfiguration die Kon- nektivität für die VPN-Verbindungen in die TI und zum SIS zur Verfügung. Die Schnittstelle wird durch den Paketfilter des Netzkonnektors geschützt. PS.WAN ist die Schnittstelle ins WAN. Diese Schnittstelle stellt abhängig von der Konfiguration die Konnektivität für die VPN-Verbindungen in die TI und zum SIS zur Verfügung. Die Schnittstelle wird durch den Paketfilter des Netzkonnektors geschützt. PS.SMC ist die Schnittstelle zu den Smart Cards vom Typ gSMC-K, die im Konnektor fest verbaut sind. Die Schnittstelle verfügt über drei Steckplätze. Die Verwendung der jeweiligen Karten wird in Abschnitt 1.4.3 beschrieben. PS.DISPLAY repräsentiert das Display und die Tasten an der Außenseite des Geräts. Das Display wird verwendet, um den Administrator über kritische Betriebszustände und den Verbindungsstatus zur TI und zum SIS zu informieren. Über die Tasten kann der Administrator durch ein Menü navigieren, um z. B. die Netzwerkparameter für das LAN abzulesen (keine Änderungsmöglich- keit) oder einen Neustart des Geräts auszulösen. 1.4.5.2. Logische Schnittstellen Der TOE verfügt über die logischen Schnittstellen, die das Schutzprofil des Gesamtkonnektors [BSI- CC-PP-0098, Abschnitt 1.3.3.2] in beschreibt. Diese werden hier der besseren Lesbarkeit halber wie- derholt. LS.LAN ist die Schnittstelle ins lokale Netzwerk des Leistungserbringers. Zusätzlich zu den im Schutz- profil genannten Schnittstellen werden hier weitere protokollspezifische Schnittstellen definiert. Tabelle 1.1 listet diese Logischen Schnittstellen. 18 LS.WAN ist die Schnittstelle des TOE zum Internet Access Gateway (IAG). Verschiedene Protokolle implementieren weitere Logische Schnittstellen in Richtung des WAN. Tabelle 1.2 listet diese Logischen Schnittstellen. LS.VPN_TI ist die Schnittstelle des TOE zu den zentralen Komponenten der Telematikinfrastruktur. Die Kommunikation erfolgt über einen VPN-Kanal, der über die WAN-Schnittstelle PS.WAN läuft. Ggf. läuft der VPN-Kanal alternativ über die Schnittstelle PS.LAN, falls WAN und LAN nicht getrennt sind. Verschiedene Protokolle implementieren weitere Logische Schnittstellen in Richtung des VPN_TI. Tabelle 1.3 listet diese Logischen Schnittstellen. LS.VPN_SIS ist die Schnittstelle zum sicheren Internet Service SIS. Die Kommunikation erfolgt über einen VPN-Kanal, der über die WAN-Schnittstelle PS.WAN läuft. Ggf. läuft der VPN-Kanal al- ternativ über die Schnittstelle PS.LAN, falls WAN und LAN durch die Konfiguration des Konnek- tors über dieselbe Schnittstelle erreicht werden. Verschiedene Protokolle implementieren weitere Logische Schnittstellen in Richtung des VPN_SIS. Tabelle 1.4 listet diese Logischen Schnittstel- len. LS.SMC repräsentiert die logische Schnittstelle zum Sicherheitsmodul (gSMC-K) des Konnektors. Die Schnittstelle läuft über PS.SMC. LS.DISPLAY repräsentiert die logische Schnittstelle zum Display und den Bedienknöpfen über PS.DIS- PLAY. LS.FM ist die Schnittstelle zwischen dem Anwendungskonnektor und den Fachmodulen, die innerhalb des Konnektors laufen5. Verschiedene Protokolle implementieren weitere Logische Schnittstel- len in Richtung der Fachmodule. Tabelle 1.5 listet diese Logischen Schnittstellen. Die Funktionalität der Schnittstelle LS.FM.RMI wird detailreicher in Abschnitt 8.2 beschrieben. 5 Das Fachmodul VSDM ist Teil des Anwendungskonnektors und verwendet diese Schnittstelle nicht. 19 Bezeichner Rolle Zweck der Schnittstelle LS.LAN.CETP Client Übertragung von Systemereignissen an Clientsysteme LS.LAN.DHCP Server Adressvergabe im LAN LS.LAN.DNS Server Auflösung von Hostnamen im LAN LS.LAN.Ether — Protokoll auf Zugangsschicht LS.LAN.HTTP Server HTTP Zugriff auf Basisdienste LS.LAN.HTTP_Client Client CRL Download LS.LAN.HTTP.DVD Server Abruf des Dienstverzeichnis LS.LAN.HTTP_MGMT Server HTTP-Zugriff auf Managementschnittstelle LS.LAN.IP — Zugang zur Internet-Schicht LS.LAN.IPsec Client Verbindung zu VPN-Konzentratoren, inkl. der Protokolle für Schlüsselaustausch und Verschlüsselung der Inhalts- daten LS.LAN.LDAP Server Zugriff auf den LDAP-Proxy LS.LAN.NTP Server Abruf der Uhrzeit LS.LAN.SICCT Client Kommunikation mit den eHealth-Kartenterminals LS.LAN.SOAP Server SOAP Kommunikation mit den Basisdiensten LS.LAN.SOAP.AuthSignatureService Server Zugriff auf den Authentisierungsdienst LS.LAN.SOAP.CardService Server Zugriff auf den Kartendienst LS.LAN.SOAP.CertificateService Server Zugriff auf den Zertifikatsdienst LS.LAN.SOAP.CTService Server Zugriff auf den Kartenterminaldienst LS.LAN.SOAP.EncryptionService Server Zugriff auf den Verschlüsselungsdienst LS.LAN.SOAP.SignatureService Server Zugriff auf den Signaturdienst LS.LAN.SOAP.SysInfService Server Zugriff auf den Systeminformationsdienst LS.LAN.SOAP.VSDM Server Zugriff auf das Versichertenstammdatenmanagement LS.LAN.SOAP.FM Server Zugriff auf die Fachmodule des Konnektors LS.LAN.TCP — Zugang zur Transportschicht LS.LAN.TLS beide Sicherung der Verbindung mit TLS 1.2 LS.LAN.UDP — Zugang zur Transportschicht Tabelle 1.1.: Logische Schnittstellen an LS.LAN 20 Bezeichner Rolle Zweck der Schnittstelle LS.WAN.DHCP Client Adressbezug im WAN LS.WAN.DNS Client Auflösung von Hostnamen im WAN LS.WAN.Ether — Protokoll auf Zugangsschicht LS.WAN.HTTP_Client Client CRL Download LS.WAN.IP — Zugang zur Internet-Schicht LS.WAN.IPsec Client Verbindung zu VPN-Konzentratoren, inkl. der Protokolle für Schlüsselaustausch und Verschlüsselung der Inhaltsdaten LS.WAN.SOAP Client SOAP Kommunikation mit dem Registrierungsdienst LS.WAN.SOAP.RegService Client Registrieren des Konnektors am Registrierungsdienst LS.WAN.TCP — Zugang zur Transportschicht LS.WAN.TLS Client Sicherung der Verbindung mit TLS 1.2 LS.WAN.UDP — Zugang zur Transportschicht Tabelle 1.2.: Logische Schnittstellen an LS.WAN Bezeichner Rolle Zweck der Schnittstelle LS.VPN_TI.DNS Client Auflösung von Hostnamen im WAN LS.VPN_TI.HTTP Client HTTP Zugriff auf Fachdienste, Download der Updatepakete LS.VPN_TI.HTTP_TSL Client TSL/CRL Download, OCSP Abfragen LS.VPN_TI.IP — Zugang zur Internet-Schicht LS.VPN_TI.LDAP Client Zugriff auf den Verzeichnisdienst der TI LS.VPN_TI.SOAP Client SOAP Kommunikation mit den Fachdiensten VSDM LS.VPN_TI.SOAP.VSDM Client Kommunikation mit den Fachdiensten VSDM LS.VPN_TI.TCP — Zugang zur Transportschicht LS.VPN_TI.TLS Client Sicherung der Verbindung mit TLS 1.2 LS.VPN_TI.UDP — Zugang zur Transportschicht Tabelle 1.3.: Logische Schnittstellen an LS.VPN_TI Bezeichner Rolle Zweck der Schnittstelle LS.VPN_SIS.HTTP_Client Client TSL/CRL Download, HTTP Zugriff auf Fachdienste LS.VPN_SIS.IP — Zugang zur Internet-Schicht LS.VPN_SIS.TCP — Zugang zur Transportschicht LS.VPN_SIS.UDP — Zugang zur Transportschicht Tabelle 1.4.: Logische Schnittstellen an LS.VPN_SIS 21 Bezeichner Rolle Zweck der Schnittstelle LS.FM.RMI Server RMI-Zugriffe der Fachmodule auf den Basiskonnektor LS.FM.HTTP Client Durchleitung der HTTP-Zugriffe (SOAP-Requests) von Clientsyste- men an die Fachmodule LS.FM.HTTP_MGMT Client Durchleitung der HTTP-Zugriffe (Administration der Fachmodule) vom Browser des Administrators an die Fachmodule Tabelle 1.5.: Logische Schnittstellen an LS.FM 22 1.4.6. Aufbau und physische Abgrenzung des Konnektors OPB 2.1 Das Schutzprofil verweist in [BSI-CC-PP-0098, Abschnitt 1.3.4] auf die Konzeption zur Architektur der TI-Plattform [gemKPT_Arch]. Das Betriebssystem, das der TOE bereit stellt, ist ein GNU/Linux System. Das im TOE verbaute Linux ist gegenüber der Basis-Distribution deutlich angepasst worden, sodass hier von einer eigenen Distribution gesprochen werden muss. Die Java-Anwendungen des TOE stellen die fachlichen Funk- tionen bereit. Der TOE besteht aus folgenden Subsystemen: Bootloader Stellt die Integrität des Kernels und des Initramfs sicher; bootet den Kernel. Kernel Der Kernel abstrahiert in Richtung der Anwendungen die Hardware und stellt Mechanismen für das Managemnt der Prozesse zur Verfügung. Der Kernel bietet Sicherheitsfunktionalität für den Paketfilter, die IPsec Kanäle und kryptographische Algorithmen. Initramfs Enthält das initiale Dateisystem mit Tools und Skripten, die gebraucht werden, um nach dem Boot des Kernels das Root-Dateisystem zu laden. Systemdienste in Form von Dämonen bieten Basisdienste, die von anderen Subsystemen des TOE ge- nutzt werden. Systembibliotheken und Werkzeuge Bietet Bibliotheken im User Space, Programme und Kommando- zeilenwerkzeuge. Auch die Java Virtual Machine, in deren Instanzen der NK und der AK laufen, stammt aus diesem Subsystem. Programme im User Space tragen fachliche Funktionen wie Ver- und Entschlüsselung zum Gesamtsystem bei. Skripte werden vor allem während des Systemstarts verwendet, um Systemdienste zu starten und den TOE zu konfigurieren. JavaModule des NK Der in Java implementierte Teil des Netzkonnektors, der den TOE konfiguriert und anderen Teilen des TOE Dienste anbietet. CertificateService Stellt anderen Subsystemen Funktionen zur Verifikation von Zertifikaten zur Verfü- gung. RMIBridge Ermöglicht Funktionsaufrufe zwischen den beiden Java Virtual Machines des NK und des AK. Die Kommunikation kann in beide Richtungen erfolgen. EventService Fungiert als eine interne Zentrale für die Verteilung von Ereignissen an andere Subsyste- me und deren Module. PCSCService Ermöglicht dem Anwendungskonnektor den Zugriff auf die im Konnektor verbauten Smart Cards vom Typ gSMC-K. Facade Bildet aus Sicht der fachlich orientierten Subsysteme die technische Außenschnittstelle des Web-Servers ab. FM_VSDM Dieses Subsystem stellt die Funktionen für das Versichertenstammdatenmanagemt bereit. SystemInformationService Bietet Informationen über den Konnektor an. Nutzer sind sowohl interne Subsysteme (über ein Request-Reply Pattern), als auch Komponenten der Einsatzumgebung wie Clientsysteme (über ein Publish-Subscribe Pattern). 23 EncryptionService Bietet Ver- und Entschlüsselungsdienste für Clientsysteme und andere Subsysteme. AdminService Enthält die Web-Application der Management-Schnittstelle und Basisdienste wie das User-Management und den Export/Import der Systemkonfiguration. SignatureService Stellt Funktionen zum Signieren von Dokumenten und zur Verfikation von Signaturen zur Verfügung. AccessAuthorizationService Setzt die Anforderungen an den Zugriffsschutz für Subsysteme des Anwen- dungskonnektors und das Informationsmodell um. CardService Kapselt den Zugriff auf Smart Cards und eHealth-Kartenterminals; stellt anderen Subsys- temen den Zugriff auf diese Entitäten zur Verfügung. Tools.AK Bietet ein Sammelbecken für Programme, Werkzeuge und Frameworks, die von anderen Subsystemen herangezogen werden. Die prominentesten Vertreter sind das OSGi Framework als Modularisierungsplattform für Java-Anwendungen und das Krypto-Framework BouncyCastle. LDAPProxy Stellt Funktionen bereit, damit Clientsysteme auf den Verzeichnisdienst der TI zugreifen können. Wird für die Kommunikation zwischen den Leistungserbringern verwendet. AuthenticationService Bietet Authentisierungsmechanismen für Clientsysteme auf Basis der gematik Spezifikation zur Tokenbasierten Authentisierung [gemSpec_Kon_TBAuth] Alle anderen Teile der KoCoBox MED+ gehören nicht zum TOE. 1.4.7. Logische Abgrenzung: Vom TOE erbrachte Sicherheitsdienste 1.4.7.1. Sicherheitsdienste des Netzkonnektors Der Konnektor erfüllt alle Anforderungen an Sicherheitsdienste, die in [BSI-CC-PP-0098, Abschnitt 1.3.5.1] definiert werden. Die folgende Liste fasst die Sicherheitsdienste zusammen. VPN Client um den Anwendungskonnektor mit den den zentralen Diensten der Telematikinfrastruk- tur und dem Sicheren Internet Service zu verbinden. Dabei werden insbesondere die im Folgen- den dargestellten Funktionen umgesetzt 1. Erzwingen der Authentisierung des VPN Konzentrators. Der NK unterstützt IKEv2 gemäß [RFC 7296]. 2. Schutz der Integrität und der Vertraulichkeit der übertragenen Daten. 3. Regelbasierte Informationsflusskontrolle. Dynamischer Paketfilter Ein regelbasierter Paketfilter, der in der Lage ist, Angriffe mit hohem Potenzial aus LAN und WAN abzuwehren. TLS-Basisdienst Die Java Virtual Machine, die Teil des Netzkonnektors ist, setzt über ihr Frame- work JSSE das TLS Protokoll im geforderten Maße um. Der TOE wird so konfiguriert, dass lediglich die in der gematik-Spezifikation genannten Ciphersuiten und Sicherheitsparameter ver- wendet werden können, vgl. [gemSpec_Krypt, Abschnitt 3.3.2]. 24 Zeitdienst Bereitstellung eines NTP-Servers für Konnektor-interne Anwendungen wie das Audit- Log und für externe Komponenten wie Clientsysteme. Der NTP-Server synchronisiert sich mit den zentralen NTP-Servern der Telematikinfrastruktur. Der NTP-Server prüft die erhaltenen Zeitinformationen auf Plausibilität und erlaubt keine Zeit- abweichung über 3600 Sekunden hinaus. DHCP-Dienst Systeme im LAN des Leistungserbringers können den DHCP-Server des Konnektors gemäß [RFC 2131; RFC 2132] nutzen. DNS-Dienst Systeme im LAN des Leistungserbringers und der Anwendungskonnektor können den DNS-Server des Konnektors gemäß [RFC 4035] nutzen. Gültigkeitsprüfung von Zertifikaten Der Konnektor validiert die Gültigkeit der Zertifikate, die von externen Entitäten wie den VPN-Konzentratoren zur Authentisierung präsentiert werden. Die Vertrauensanker für diese Prüfung werden aus der aktuell installierten TSL entnommen. Die verwendeten Algorithmen sind in der Firmware des Konnektors definiert und können durch Software-Updates aktualisiert werden. Stateful Packet Inspection Der dynamische Paketfilter ist in der Lage, nicht-wohlgeformte IP- Pakete zu erkennen und entsprechend zu agieren. Selbstschutz Der Konnektor schützt Geheimnisse gegen Manipulationen und Preisgabe. Speicheraufbereitung Unmittelbar nach Abbau von TLS- und VPN-Verbindungen wird das Schlüsselmaterial durch aktives Überschreiben mit Null-Bytes vernichtet. Selbsttests Neben dem beim Systemstart ausgeführten Selbsttest haben Administratoren jederzeit die Möglichkeit, den Selbsttest des Konnektors über die Management-Anwendung zu starten. Protokollierung Der TOE reserviert Platz im nicht-flüchtigen Speicher für die Ablage eines Audit- Logs. Weder normale Benutzer noch Administratoren können das Audit-Log modifizieren oder löschen. Wenn der reservierte Speicherplatz erschöpft ist, wird der älteste Eintrag überschrieben. Neben den in [BSI-CC-PP-0098, Abschnitt 6.2.5] beschriebenen Anforderungen werden noch die Anforderungen aus FAU_GEN.1/AK erfüllt. Der TOE implementiert Mechanismen zum Selbstschutz gegen Angriffe, die das Audit-Log mit Einträgen zu überschwemmen versuchen, um Spuren eines Angriffs zu vertuschen. Bei einem Füllstand von 80% des Audit-Logs wird der Administrator über ein spezielles Audit-Event be- nachrichtigt. Eine Auswertung des Audit-Logs ist Aufgabe des Administrators. Administration Der TOE bietet eine web-basierte Management-Anwendung, die ausschließlich über eine TLS-gesicherte Verbindung erreichbar ist und die Authentisierung des Administra- tors über Benutzernamen/Passwort erzwingt. Diese Anwendung stellt der Anwendungskonnek- tor bereit. Die über die Management-Anwendung übergebenen Konfigurationswerte werden vom Netzkonnektor persistiert und angewendet. Die Konfigurationsmöglichkeiten sind auf solche Werte beschränkt, die nicht die Sicherheitsan- forderungen an den TOE gefährden. Die Sicherheit des TOE kann nicht durch Konfiguration in der Management-Anwendung kompromittiert werden. 25 Über die Management-Anwendung kann ein Administrator ein Firmware-Update initiieren. Eine Fernwartung gemäß [gemSpec_Kon, Abschnitt 4.3] ist nicht möglich. 1.4.7.2. Sicherheitsdienste des Anwendungskonnektors Die in [BSI-CC-PP-0098, Abschnitt 1.3.5.2] aufgeführten Sicherheitsdienste setzt der Anwendungs- konnektor um. Für spezielle Sicherheitsdienste müssen die Anforderungen hier präzisiert werden: Gesicherte Kommunikation Der Begriff „externes Managementsystem“ aus dem vierten Spie- gelstrich wird hier als ein Signaturproxy interpretiert, der zwischen dem Clientsystem und dem TOE in der Einsatzumgebung vorhanden sein kann und über LS.LAN mit dem Konnektor kom- muniziert. TLS Dienst Die Anforderung Dazu dient der EVG als Proxy, der jeweils TLS-Kanäle zu Fachmodulen und zu Fach- diensten bzw. den vorgelagerten Intermediäre verwaltet [BSI-CC-PP-0098, S. 39] wird in der vorliegenden Architektur nicht umgesetzt. Ein zentraler Dienst für die Verwaltung von TLS-Verbindungen existiert nicht. Jeder Nutzer einer TLS-Verbindung ist dafür verantwort- lich, die Verbindung selbst auf- und wieder abzubauen. Das Framework JSSE stellt zwar alle Mechanismen für den Auf- und Abbau und für die Aufrechterhaltung einer TLS-Verbindung zur Verfügung, fungiert jedoch nicht als Manager der Verbindungen. 1.4.8. Physischer Umfang des TOE Der physische Umfang des TOE umfasst die in Tabelle 1.6 aufgelisteten Komponenten. 26 Komponente Beschreibung Version Firmware Image Die Firmware und der Boot Loader des TOE. Die Firmware umfasst den Netzkonnektor, den Anwendungskonnek- tor, das Fachmodul NFDM (in Versi- on 1.0.13) und das Fachmodul AMTS (Version 1.0.13) 2.3.24 Guidance Documentation („Admi- nistratorhandbuch KoCoBox MED+ Version 2.3“) Die Guidance Documentation beschreibt die sichere Verwendung des TOE [KoCo AGD_ADM] 2.3 (14.7.2020) Guidance Documentation („Ergän- zungen zum Administratorhandbuch KoCoBox MED+ Version 2.x“) Zielgruppe dieser Ergänzungen zum Handbuch sind Administratoren und Integratoren der KoCoBox MED+ sowie Hersteller von Primärsystemen, die für den Einsatz mit der KoCoBox MED+ vor- gesehen sind. [KoCo AGD_ADM-Erg] 1.1.1 Benutzerhandbuch („Allgemeine Ge- brauchsanleitung KoCoBox MED+“) Das Benutzerhandbuch beschreibt die all- gemeine Verwendung des Konnektors, so- wohl dessen TOE Anteile als auch die nicht-TOE Anteile 1.3.8 Entwicklerhandbuch („JSON- Managementschnittstelle der KoCo- Box MED+“) Anleitung für die Benutzung der API von LS.LAN.HTTP_MGMT. 2.22 Konnektor Security Guidance Fachmodu- le NFDM und AMTS Die Anleitung zur Verwendung des Kon- nektors für die Autoren von Fachmodulen AMTS und NFDM [KoCo AGD_Kon- Sec] 1.15 Konnektor API für Fachmodule Javadoc API-Beschreibung der Funktionen des Ba- siskonnektors für Fachmodule 2.3.24 Tabelle 1.6.: Physischer Umfang des TOE 27 2. Postulat der Übereinstimmung 2.1. Konformität zu Common Criteria Das Security Target wurde gemäß Common Criteria, Version 3.1, Revision 5, erstellt und ist • CC Part 2 [CC Part 2] erweitert (extended) und • CC Part 3 [CC Part 3] konform (conformant). 2.2. Konformität zu Schutzprofilen Dieses Security Target behauptet strikte Konformität zu: • „Schutzprofil 2: Anforderungen an den Konnektor“ [BSI-CC-PP-0098] Dieses Security Target behauptet keine Konformität zu weiteren Schutzprofilen. 2.3. Konformität zu Paketen Das Schutzprofil fordert die Vertrauenswürdigkeitsstufe EAL3, erweitert um die Komponenten in Ta- belle 2.1. Dieses Security Target behauptet Konformität zu genau diesen Paketen. Diese Konformität wird als „EAL3+“ bezeichnet und ist somit „package-augmented“ gegenüber EAL3. Paket Erläuterung 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 ALC_FLR.2 Verfahren für Problemreports Tabelle 2.1.: Ergänzungen zur Vertrauenswürdigkeit EAL3 2.4. Erklärung der Konformität Dieses Security Target behauptet strikte Konformität zu [BSI-CC-PP-0098]. Durch diese Feststellung sind Widersprüche und Inkonsistenzen zu anderen Schutzprofilen ausgeschlossen. Diese Behauptung basiert auf der Betrachtung des TOE Typs, der Definition des Sicherheitsproblems und schließlich 28 der Sicherheitsziele sowie der Sicherheitsanforderungen. Weiterhin behauptet dieses Security Target Konformität zu allen Security Assurance Requirements (SARs), die von [BSI-CC-PP-0098] gefordert werden. TOE Typ Das Schutzprofil fordert, dass der TOE ein Konnektor gemäß der Spezifikation der gematik ist [gemSpec_Kon]. Der TOE, der in diesem Security Target beschrieben wird, ist ein solcher Konnektor. Er besteht aus dem Netzkonnektor, dem Anwendungskonnektor und dem Fachmodul „Versichertenstammdatenmanagement“. Definition des Sicherheitsproblems Die Definition des Sicherheitsproblems, d. h. die Bedro- hungen, Annahmen und die organisatorischen Sicherheitspolitiken sind direkt aus dem Schutz- profil [BSI-CC-PP-0098] übernommen. Sicherheitsziele und Sicherheitsanforderungen Die Sicherheitsziele und Sicherheitsanfor- derungen sind dem Schutzprofil [BSI-CC-PP-0098] entnommen. Die Operationen an den SFR sind deutlich gekennzeichnet. Kapitel 5 bescheibt die über CC Teil 2 [CC Part 2] hinausgehenden funktionalen Anforderungen an die Vertrauenswürdigkeit. Es werden keine Anforderungen definiert, die über CC Teil 3 [CC Part 3] hinausgehen. 2.5. Konformität zu Technischen Richtlinien für Fachmodule Dieses Security Target ist weiterhin konform zu den Anforderungen, die folgende Technische Richtli- nien an einen CC-zertifizierten Konnektor stellen: • „Konnektor – Prüfspezifikation für das Fachmodul NFDM“ [TR-03154, Abschnitt 3.3.2] • „Konnektor – Prüfspezifikation für das Fachmodul AMTS“ [TR-03155, Abschnitt 3.3.2] Die Konformitätserklärung zu den Technischen Richtlinien bedeutet nicht, dass der Konnektor die gesamte TR umsetzt. Sie bezieht sich ausschließlich auf die Anforderungen an die CC-Zertifizierung in den angegebenen Abschnitten der Technischen Richtlinien. Die Erklärung der Konformität folgt in Kapitel 8. 29 3. Definition des Sicherheitsproblems In diesem Abschnitt wird zunächst beschrieben, welche Werte der TOE schützen muss, welche exter- nen Einheiten mit ihm interagieren und welche Objekte von Bedeutung sind. Auf dieser Basis wird danach beschrieben, welche Bedrohungen der TOE abwehren muss, welche organisatorischen Sicher- heitspolitiken zu beachten sind und welche Annahmen an seine Einsatzumgebung getroffen werden können. Für die Bezüge auf Schutzprofile sind die Hinweise im Abschnitt „Anmerkungen zur CC Zertifizie- rung“ im Vorwort dieses Security Targets zu beachten. 3.1. Werte 3.1.1. Zu Schützende Werte Die zu schützenden Werte – also Ressourcen und Daten, die der TOE schützt – werden in [BSI-CC-PP- 0097] und [BSI-CC-PP-0098] beschrieben. Die dort beschriebenen Werte gelten bezüglich des TOE Scopes ohne Anpassung, vgl. hierzu auch die Anmerkungen im Vorwort dieses Security Targets. 3.1.2. Benutzer des TOE Die externen Entitäten, Subjekte und Objekte des TOE werden in [BSI-CC-PP-0097] und [BSI-CC- PP-0098] beschrieben. Die Benutzer des Anwendungskonnektors werden in [BSI-CC-PP-0098, Ab- schnitt 3.1.1] beschrieben. Diese Beschreibung gilt ohne Anpassung. Die Subjekte, die im Auftrag des Benutzers agieren, werden in [BSI-CC-PP-0098, Abschnitt 6.1.2] modelliert. Auch diese Darstellung wird ohne Anpassung in das Security Target übernommen. 3.2. Bedrohungen Die in [BSI-CC-PP-0097] und in den [BSI-CC-PP-0098] aufgelisteten und angenommenen Bedrohun- gen gelten bezüglich des TOE Scopes ohne Anpassung, vgl. hierzu auch die Anmerkungen im Vorwort dieses Security Targets. 3.3. Organisatorische Sicherheitspolitiken des Netzkonnektors OSP.NK.Zeitdienst (Zeitdienst) Die in Abschnitt 3.4 von [BSI-CC-PP-0097] und Abschnitt 3.3.1 von [BSI-CC-PP-0098] beschriebene organisatorische Sicherheitspolitik OSP.NK.Zeitdienst gilt ohne Anpassung. OSP.NK.SIS (Sicherer Internet Service) Die in Abschnitt 3.4 von [BSI-CC-PP-0097] und Abschnitt 3.3.1 von [BSI-CC-PP-0098] beschriebene organisatorische Sicherheitspolitik OSP.NK.SIS gilt ohne Anpassung. 30 OSP.NK.BOF (Kommunikation mit Bestandsnetzen und offenen Fachdiensten) Die in Abschnitt 3.4 von [BSI-CC-PP-0097] und Abschnitt 3.3.1 von [BSI-CC-PP-0098] beschriebene organisatorische Sicherheitspolitik OSP.NK.BOF gilt ohne Anpassung. OSP.NK.TLS (TLS-Kanäle mit sicheren kryptographische Algorithmen) Die in Abschnitt 3.4 von [BSI-CC-PP-0097] und Abschnitt 3.3.1 von [BSI-CC-PP-0098] beschriebene organisatorische Sicherheitspolitik OSP.NK.TLS gilt ohne Anpassung. 3.4. Organisatorische Sicherheitspolitiken des Anwendungskonnektors Die in [BSI-CC-PP-0098, Abschnitt 3.3] aufgelisteten organisatorischen Sicherheitspolitiken gelten oh- ne Anpassung. 3.5. Annahmen Die in [BSI-CC-PP-0097] und [BSI-CC-PP-0098] getroffenen Annahmen gelten bezüglich des TOE Scopes ohne Anpassung, vgl. hierzu auch die Anmerkungen im Vorwort dieses Security Targets. Für A.NK.AK und A.NK.CS wird der ST-Autor über Anwendungshinweise Nr. 28 und 29 aufgefordert, die Funktionalität des Netzkonnektors und die dafür erforderlichen Separationsmechanismen zu er- klären. Zwar gehen die beiden Annahmen davon aus, dass sowohl der Anwendungskonnektor als auch die Clientsysteme die Sicherheitsdienste des Netzkonnektors automatisch nutzen. Doch muss auch aus dem LAN des Leistungserbringers mit Angriffen gerechnet werden, da möglicherweise Schadsoftware im LAN existiert. Dies leitet sich aus zwei Bedrohungen her, denen das Schutzprofil verschiedene An- griffspfade zuordnet [BSI-CC-PP-0098, Abschnitt 3.2.1.2]. T.NK.local_EVG_LAN Die in Angriffspfad 1 skizzierte Gefahr kann für den Konnektor ausgeschlossen werden. Der Konnektor verwendet an der LAN Schnittstelle einen Paketfilter, der nicht umgan- gen werden kann. Außer den definierten Schnittstellen sind keine Ports am Konnektor geöffnet. Daher gelten hier die üblichen Schutzmaßnahmen wie der Integritätsschutz. Die im Konnektor eingetragenen Routing-Tabellen sorgen dafür, dass Clientsysteme direkt mit den angeschlossenen Netzen des Gesundheitswesens („offene Bestandsnetze“) kommunizieren dürfen. T.NK.remote_EVG_LAN Der Paketfilter separiert auch die Schnittstellen LS.LAN und LS.WAN voneinan- der. Weiterhin haben LAN- und WAN-Interfaces unterschiedliche IP-Adressen. Sie arbeiten in unterschiedlichen Subnetzen, diese dürfen sich nicht überschneiden. Folglich separiert auch das Routing die beiden Netze. Damit ist der Angriffspfad 3.1 abgewehrt. Der Angriffspfad 3.2 muss durch das Clientsystem abgewehrt werden. In beiden Fällen werden vor allem Inhalte der Kommunikation nicht ausgewertet: Der Konnektor ist ja nur angreifbar, wenn auf dem Konnektor irgendetwas zur Auswertung ankommt. Firewall und Routing selber werten ja nur die Pakete auf IP/TCP/UDP Ebene aus. Der Konnektor fungiert in diesem Fall lediglich als Router, der weder den Anspruch erhebt, noch in der Lage ist, den von ihm an die Clientsysteme vermittelten Datenverkehr zu überwachen und zu filtern. Dienste auf dem Konnektor selber sind erreichbar und müssen sich selber schützen bzw sind auf anderen Ebenen separiert. 31 4. Sicherheitsziele 4.1. Sicherheitsziele für den Netzkonnektor 4.1.1. Allgemeine Ziele: Schutz und Administration O.NK.TLS_Krypto (TLS-Kanäle mit sicheren kryptographische Algorithmen) Das in Abschnitt 4.1.1 von [BSI-CC-PP-0097] und Abschnitt 4.1.1 von [BSI-CC-PP-0098] beschrie- bene Sicherheitsziel O.NK.TLS_Krypto muss erfüllt werden. O.NK.Schutz (Selbstschutz, Selbsttest und Schutz von Benutzerdaten) Das in Abschnitt 4.1.1 von [BSI-CC-PP-0097] und Abschnitt 4.1.1 von [BSI-CC-PP-0098] beschrie- bene Sicherheitsziel O.NK.Schutz muss erfüllt werden. O.NK.EVG_Authenticity (Authentizität des EVG) Das in Abschnitt 4.1.1 von [BSI-CC-PP-0097] und Abschnitt 4.1.1 von [BSI-CC-PP-0098] beschrie- bene Sicherheitsziel O.NK.EVG_Authenticity muss erfüllt werden. Einen hinreichenden Schutz gegen Angreifer, welche gefälschte Konnektoren in Umlauf bringen, stellen ein geeignetes Auslieferungsverfahren (ALC_DEL.1) sowie sichere Verfahren zur Inbetrieb- nahme (AGD_OPE.1) dar, sofern sie mit weiteren Maßnahmen kombiniert werden, welche spätere Veränderungen am Konnektor mit Sicherheit ausschließen oder hinreichend erkennbar machen, z. .B. Aufbewahrung in einem gesicherten Bereich (siehe Abschnitt 4.1.1). Der Konnektor wird über ein sicheres Auslieferungsverfahren an den Bestimmungsort transportiert und dort dem Leistungserbringer übergeben. Die Eigenschaften des sicheren Auslieferungsprozess sind in [KoCo ALC_DEL] beschrieben. Das Administratorhandbuch listet in Abschnitt 4.2 die Art und die Plazierung der verschiedenen Siegel auf dem Gehäuse des Konnektors auf [KoCo AGD_ADM]. An- hand der Unversehrtheit der Siegel ist für den Leistungserbringer erkennbar, ob das Gerät manipuliert wurde. Der Konnektor implementiert das IPSec-Protokoll, das eine zertifikatsbasierte Authentisierung vor- sieht. Das Zertifikat bezieht der Konnektor von der gSMC-K#1. Diese Karte ist im Konnektor verbaut und kann nicht entfernt werden, ohne die Integrität des Konnektors zu zerstören. O.NK.Admin_EVG (Administration nur nach Autorisierung und über sicheren Kanal) Das in Abschnitt 4.1.1 von [BSI-CC-PP-0097] und Abschnitt 4.1.1 von [BSI-CC-PP-0098] beschrie- bene Sicherheitsziel O.NK.Admin_EVG muss erfüllt werden. Das Administrationskonzept des Konnektors ist rollenbasiert, doch jeder Benutzer mit der Berech- tigung, die Administrationsschnittstelle zu benutzen, wird in diesem Security Target als Administrator bezeichnet – unabhängig von den konfigurierten Berechtigungen der spezifischen Rolle. Das Rollen- modell des Konnektors weist weitere Rollen auf (SuperAdmin, Admin etc., vgl. [KoCo AGD_ADM]), die mit verschiedenen Rechten versehen sind und durch Einzelvergabe individuell konfiguriert werden können. Aus Sicht dieses Security Targets werden die Inhaber dieser Rollen alle als „Administrator“ bezeichnet. 32 O.NK.Protokoll (Protokollierung mit Zeitstempel) Das in Abschnitt 4.1.1 von [BSI-CC-PP-0097] und Abschnitt 4.1.1 von [BSI-CC-PP-0098] beschrie- bene Sicherheitsziel O.NK.Protokoll muss erfüllt werden. O.NK.Zeitdienst (Zeitdienst) Das in Abschnitt 4.1.1 von [BSI-CC-PP-0097] und Abschnitt 4.1.1 von [BSI-CC-PP-0098] beschrie- bene Sicherheitsziel O.NK.Zeitdienst muss erfüllt werden. 4.1.2. Ziele für die VPN Funktionalität O.NK.VPN_Auth (Gegenseitige Authentisierung im VPN-Tunnel) Das in Abschnitt 4.1.2 von [BSI-CC-PP-0097] und Abschnitt 4.1.2 von [BSI-CC-PP-0098] beschrie- bene Sicherheitsziel O.NK.VPN_Auth muss erfüllt werden. O.NK.Zert_Prüf (Gültigkeitsprüfung für VPN-Zertifikate) Das in Abschnitt 4.1.2 von [BSI-CC-PP-0097] und Abschnitt 4.1.2 von [BSI-CC-PP-0098] beschrie- bene Sicherheitsziel O.NK.Zert_Prüf muss erfüllt werden. O.NK.VPN_Vertraul (Schutz der Vertraulichkeit von Daten im VPN-Tunnel) Das in Abschnitt 4.1.2 von [BSI-CC-PP-0097] und Abschnitt 4.1.2 von [BSI-CC-PP-0098] beschrie- bene Sicherheitsziel O.NK.VPN_Vertraul muss erfüllt werden. O.NK.VPN_Integrität (Integritätsschutz von Daten im VPN-Tunnel) Das in Abschnitt 4.1.2 von [BSI-CC-PP-0097] und Abschnitt 4.1.2 von [BSI-CC-PP-0098] beschrie- bene Sicherheitsziel O.NK.VPN_Integrität muss erfüllt werden. 4.1.3. Ziele für die Paketfilter-Funktionalität O.NK.PF_WAN (Dynamischer Paketfilter zum WAN) Das in Abschnitt 4.1.3 von [BSI-CC-PP-0097] und Abschnitt 4.1.3 von [BSI-CC-PP-0098] beschrie- bene Sicherheitsziel O.NK.PF_WAN muss erfüllt werden. O.NK.PF_LAN (Dynamischer Paketfilter zum LAN) Das in Abschnitt 4.1.3 von [BSI-CC-PP-0097] und Abschnitt 4.1.3 von [BSI-CC-PP-0098] beschrie- bene Sicherheitsziel O.NK.PF_LAN muss erfüllt werden. O.NK.Stateful (Stateful Packet Inspection (zustandsgesteuerte Filterung)) Das in Abschnitt 4.1.3 von [BSI-CC-PP-0097] und Abschnitt 4.1.3 von [BSI-CC-PP-0098] beschrie- bene Sicherheitsziel O.NK.Stateful muss erfüllt werden. 4.2. Sicherheitsziele für den Anwendungskonnektor 4.2.1. Allgemeine Sicherheitsziele O.AK.Basis_Crypto (Kryptographische Algorithmen) Das in Abschnitt 4.2.1 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.Basis_Crypto muss erfüllt werden. 33 O.AK.Admin (Administration) Das in Abschnitt 4.2.1 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.Admin muss erfüllt werden. O.AK.EVG_Modifikation (Schutz vor Veränderungen) Das in Abschnitt 4.2.1 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.EVG_Modifikation muss erfüllt werden. O.AK.Selbsttest (Selbsttests) Das in Abschnitt 4.2.1 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.Selbsttest muss erfüllt werden. O.AK.Protokoll (Sicherheitsprotokoll mit Zeitstempel) Das in Abschnitt 4.2.1 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.Protokoll muss erfüllt werden. O.AK.Zeit (Systemzeit) Das in Abschnitt 4.2.1 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.Zeit muss erfüllt wer- den. O.AK.Infomodell (Umsetzung des Informationsmodells durch den EVG) Das in Abschnitt 4.2.1 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.Infomodell muss er- füllt werden. O.AK.Update (Software Update und Update von TSL, CRL und BNetzA-VL) Das in Abschnitt 4.2.1 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.Update muss erfüllt werden. 4.2.2. Signaturdienst O.AK.Sig.SignQES (Signaturrichtlinie für qualifizierte elektronische Signaturen) Das in Abschnitt 4.2.2 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.Sig.SignQES muss er- füllt werden. O.AK.Sig.SignNonQES (Signaturrichtlinie für nichtqualifizierte elektronische Signaturen) Das in Abschnitt 4.2.2 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.Sig.SignNonQES muss erfüllt werden. O.AK.Sig.exklusivZugriff (Unterstützung bei alleiniger Kontrolle) Das in Abschnitt 4.2.2 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.Sig.exklusivZugriff muss erfüllt werden. O.AK.Sig.Einfachsignatur (Einfachsignatur) Das in Abschnitt 4.2.2 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.Sig.Einfachsignatur muss erfüllt werden. O.AK.Sig.Stapelsignatur (Stapelsignatur) Das in Abschnitt 4.2.2 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.Sig.Stapelsignatur muss erfüllt werden. 34 O.AK.Sig.Schlüsselinhaber (Zuordnung des Signaturschlüssel-Inhabers) Das in Abschnitt 4.2.2 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.Sig.Schlüsselinhaber muss erfüllt werden. O.AK.Sig.SignaturVerifizierung (Verifizierung der Signatur) Das in Abschnitt 4.2.2 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.Sig.SignaturVerifizie- rung muss erfüllt werden. O.AK.Sig.PrüfungZertifikat (Prüfung des Signatur-Zertifikates) Das in Abschnitt 4.2.2 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.Sig.PrüfungZertifikat muss erfüllt werden. 4.2.3. Gesicherte Kommunikation / TLS Proxy O.AK.LAN (gesicherte Kommunikation im LAN der Leistungserbringer) Das in Abschnitt 4.2.3 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.LAN muss erfüllt wer- den. O.AK.WAN (gesicherte Kommunikation zwischen EVG und Fachdiensten) Das in Abschnitt 4.2.3 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.WAN muss erfüllt werden. 4.2.4. Terminal- und Chipkartendienst O.AK.exklusivZugriff (Alleinige Kontrolle von Terminal und Karte) Das in Abschnitt 4.2.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.exklusivZugriff muss erfüllt werden. O.AK.PinManagement (Management von Chipkarten-PINs) Das in Abschnitt 4.2.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.PinManagement muss erfüllt werden. O.AK.IFD-Komm (Schutz der Kommunikation mit den eHealth-Kartenterminals) Das in Abschnitt 4.2.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.IFD-Komm muss erfüllt werden. O.AK.Chipkartendienst (Chipkartendienste des EVG) Das in Abschnitt 4.2.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.Chipkartendienst muss erfüllt werden. O.AK.VAD (Schutz der Authentisierungsverifikationsdaten) Das in Abschnitt 4.2.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.VAD muss erfüllt wer- den. 4.2.5. Verschlüsselungsdienste O.AK.Enc (Verschlüsselung von Daten) Das in Abschnitt 4.2.5 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.Enc muss erfüllt wer- den. 35 O.AK.Dec (Entschlüsselung von Daten) Das in Abschnitt 4.2.5 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.Dec muss erfüllt wer- den. O.AK.VZD (Kommunikation mit dem zentralen Verzeichnisdienst) Das in Abschnitt 4.2.5 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.VZD muss erfüllt wer- den. 4.2.6. Fachmodul VSDM O.AK.VSDM (Versichertenstammdatenmanagement) Das in Abschnitt 4.2.5 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel O.AK.VSDM muss erfüllt werden. 4.3. Sicherheitsziele für die Umgebung des Netzkonnektors OE.NK.RNG (Externer Zufallszahlengenerator) Das in Abschnitt 4.2 von [BSI-CC-PP-0097] und Abschnitt 4.3 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.NK.RNG muss erfüllt werden. OE.NK.Echtzeituhr (Echtzeituhr) Das in Abschnitt 4.2 von [BSI-CC-PP-0097] und Abschnitt 4.3 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.NK.Echtzeituhr muss erfüllt werden. OE.NK.Zeitsynchro (Zeitsynchronisation) Das in Abschnitt 4.2 von [BSI-CC-PP-0097] und Abschnitt 4.3 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.NK.Zeitsynchro muss erfüllt werden. OE.NK.gSMC-K (Sicherheitsmodul gSMC-K) Das in Abschnitt 4.2 von [BSI-CC-PP-0097] und Abschnitt 4.3 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.NK.gSMC-K muss erfüllt werden. OE.NK.KeyStorage (Sicherer Schlüsselspeicher) Das in Abschnitt 4.2 von [BSI-CC-PP-0097] und Abschnitt 4.3 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.NK.KeyStorage muss erfüllt werden. OE.NK.AK (Korrekte Nutzung des EVG durch Anwendungskonnektor) Das in Abschnitt 4.2 von [BSI-CC-PP-0097] und Abschnitt 4.3 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.NK.AK muss erfüllt werden. OE.NK.CS (Korrekte Nutzung des Konnektors durch Clientsysteme (oder weitere Systeme im LAN)) Das in Abschnitt 4.2 von [BSI-CC-PP-0097] und Abschnitt 4.3 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.NK.CS muss erfüllt werden. OE.NK.Admin_EVG (Sichere Administration des EVG) Das in Abschnitt 4.2 von [BSI-CC-PP-0097] und Abschnitt 4.3 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.NK.Admin_EVG muss erfüllt werden. 36 OE.NK.Admin_Auth (Authentisierung des Administrators) Das in Abschnitt 4.2 von [BSI-CC-PP-0097] und Abschnitt 4.3 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.NK.Admin_Auth muss erfüllt werden. OE.NK.PKI (Betrieb einer Public-Key-Infrastruktur und Verteilung der TSL) Das in Abschnitt 4.2 von [BSI-CC-PP-0097] und Abschnitt 4.3 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.NK.PKI muss erfüllt werden. OE.NK.phys_Schutz (Physischer Schutz des EVG) Das in Abschnitt 4.2 von [BSI-CC-PP-0097] und Abschnitt 4.3 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.NK.phys_Schutz muss erfüllt werden. OE.NK.sichere_TI (Sichere Telematikinfrastruktur Platform) Das in Abschnitt 4.2 von [BSI-CC-PP-0097] und Abschnitt 4.3 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.NK.sichere_TI muss erfüllt werden. OE.NK.kein_DoS (Keine Denial Of Service Angriffe) Das in Abschnitt 4.2 von [BSI-CC-PP-0097] und Abschnitt 4.3 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.NK.kein_DoS muss erfüllt werden. OE.NK.Betrieb_AK (Sicherer Betrieb des Anwendungskonnektors) Das in Abschnitt 4.2 von [BSI-CC-PP-0097] und Abschnitt 4.3 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.NK.Betrieb_AK muss erfüllt werden. OE.NK.Betrieb_CS (Sicherer Betrieb der Clientsysteme) Das in Abschnitt 4.2 von [BSI-CC-PP-0097] und Abschnitt 4.3 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.NK.Betrieb_CS muss erfüllt werden. OE.NK.Ersatzverfahren (Sichere Ersatzverfahren bei Ausfall der Infrastruktur) Das in Abschnitt 4.2 von [BSI-CC-PP-0097] und Abschnitt 4.3 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.NK.Ersatzverfahren muss erfüllt werden. OE.NK.SIS (Sicherer Internet Service) Das in Abschnitt 4.2 von [BSI-CC-PP-0097] und Abschnitt 4.3 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.NK.SIS muss erfüllt werden. 4.4. Sicherheitsziele für die Umgebung des Anwendungskonnektors OE.AK.Versicherter (Sorgfaltspflichten des Versicherten) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.Versicherter muss er- füllt werden. OE.AK.HBA-Inhaber (Vertrauenswürdigkeit und Sorgfaltspflichten des HBA-Inhabers) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.HBA-Inhaber muss er- füllt werden. 37 OE.AK.SMC-B-PIN (Freischaltung der SMC-B) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.SMC-B-PIN muss erfüllt werden. OE.AK.sichere_TI (Sichere Telematikinfrastruktur-Plattform) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.sichere_TI muss erfüllt werden. OE.AK.Fachdienste (Vertrauenswürdige Fachdienste und zentrale Dienste der TI-Plattform) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.Fachdienste muss er- füllt werden. OE.AK.Admin_EVG (Sichere Administration des Konnektors) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.Admin_EVG muss er- füllt werden. OE.AK.Admin_Konsole (Sichere Administratorkonsole) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.Admin_Konsole muss erfüllt werden. OE.AK.Kartenterminal (Sicheres Kartenterminal) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.Kartenterminal muss erfüllt werden. OE.AK.Plattform (Sichere Plattform) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.Plattform muss erfüllt werden. OE.AK.SecAuthData (Schutz der Authentisierungsdaten) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.SecAuthData muss er- füllt werden. OE.AK.phys_Schutz (Physischer Schutz des EVG) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.phys_Schutz muss er- füllt werden. OE.AK.Personal (Qualifiziertes und vertrauenswürdiges Personal) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.Personal muss erfüllt werden. OE.AK.SMC (Nutzung geeigneter SMC) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.SMC muss erfüllt wer- den. OE.AK.gSMC-K (Nutzung einer gSMC-K) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.gSMC-K muss erfüllt werden. OE.AK.eGK (Nutzung geeigneter eGK) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.eGK muss erfüllt wer- den. 38 OE.AK.HBA (Nutzung einer sicheren Signaturerstellungseinheit) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.HBA muss erfüllt wer- den. OE.AK.PKI (PKI für Signaturdienste, Verschlüsselung und technische Komponenten) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.PKI muss erfüllt wer- den. OE.AK.Clientsystem (Sichere Clientsysteme) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.Clientsystem muss er- füllt werden. OE.AK.ClientsystemKorrekt (Clientsysteme arbeiten korrekt und unterstützen das Informationsmodell) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.ClientsystemKorrekt muss erfüllt werden. OE.AK.Benutzer_Signatur (Prüfung zu signierender und zu prüfender Dokumente vor der Übermittlung an den EVG) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.Benutzer_Signatur muss erfüllt werden. OE.AK.SW-Update (Prozesse für sicheres Software-Update) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.SW-Update muss erfüllt werden. OE.AK.Echtzeituhr (Bereitstellung einer Echtzeituhr) Das in Abschnitt 4.4 von [BSI-CC-PP-0098] beschriebene Sicherheitsziel OE.AK.Echtzeituhr muss er- füllt werden. 4.5. Erklärung der Sicherheitsziele des Netzkonnektors 4.5.1. Abbildung der Bedrohungen, OSPs und Annahmen auf Ziele Die Abbildung der Bedrohungen, organisatorischen Sicherheitspolitiken und Annahmen auf Sicher- heitsziele für den TOE entspricht den in [BSI-CC-PP-0098; BSI-CC-PP-0097] beschriebenen Re- lationen. Tabelle 4.1 entspricht der Übersicht im Schutzprofil. Tabelle A.1 zeigt die in Tabelle 4.1 verwendeten Symbole. Das Schutzprofil beschreibt darüber hinaus, dass einige Bedrohungen durch Assurance- Komponenten der CC abgewehrt werden. Diese zusätzliche Sicherung gilt auch für dieses Security Target. 4.5.1.1. Abwehr der Bedrohungen durch die Sicherheitsziele Die Verteidigung gegen Bedrohungen, die im Schutzprofil definiert werden, werden unverändert aus dem Schutzprofil übernommen. 39 O.NK.TLS_Krypto O.NK.Schutz O.NK.EVG_Authenticity O.NK.Admin_EVG O.NK.Protokoll O.NK.Zeitdienst 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.Admin_Auth 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 T.NK.Local_EVG_LAN . X . . X X . . . . . X – . X X . X . . . . . . . . . . . . T.NK.remote_EVG_WAN . X . . X X X X . X X . X X X X X X . . . . X . X . . . X . T.NK.remote_EVG_LAN . X . . X X X X . X X X X X X X X X . . . . X . X . . X X X T.NK.remote_VPN_Data . . . – X X X X X . . . X X X X X X X . . . X . X . X X X X T.NK.local_admin_LAN . X . X X X . . . . . – – X X X . X . . X X – – . . . . – . T.NK.remote_admin_WAN . 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 . T.NK.TimeSync . . . . – 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 4.1.: Abbildung der Sicherheitsziele des Netzkonnektors auf Bedrohungen und Annahmen 40 4.5.1.2. Abbildung der organisatorischen Sicherheitspolitiken auf Sicherheitsziele Die Abbildungen der organisatorischen Sicherheitspolitiken OSP.NK.Zeitdienst, OSP.NK.SIS, OSP.NK.BOF und OSP.NK.TLS auf Sicherheitsziele wird unverändert aus dem Schutzprofil übernommen. 4.5.1.3. Abbildung der Annahmen auf Sicherheitsziele für die Umgebung Die Abbildung der Annahmen auf Sicherheitsziele der Umgebung wird unverändert aus dem Schutz- profil übernommen. 4.6. Erklärung der Sicherheitsziele des Anwendungskonnektors Die Erklärung der Sicherheitsziele und die Zuordnung zu Bedrohungen, Sicherheitspolitiken und An- nahmen wird ohne Änderung aus dem Schutzprofil übernommen [BSI-CC-PP-0098, Abschnitt 4.5]. 41 5. Definition der erweiterten Komponenten 5.1. Definition der erweiterten Familie FCS_RNG Familienverhalten Diese Familie definiert Anforderungen an die Erzeugung von Zufallszahlen, die für kryptographische Anwendungen vorgesehen sind. Komponentenabstufung FCS_RNG Zufallszahlenerzeugung 1 FCS_RNG.1 „Zufallszahlenerzeugung“ erfordert die Identifizierung des Typs des verwendeten Zufalls- zahlengenerators und eine Auflistung seiner Sicherheitsmerkmale. Für die erzeugten Zufallszahlen ist eine Qualitätsmetrik anzugeben, auf die sich ihre nachfolgende Verarbeitung und Bewertung abstützen kann. Management: FCS_RNG.1 Für diese Komponente sind keine Management-Aktivitäten vorgesehen. Protokollierung: FCS_RNG.1 Es sind keine Ereignisse identifiziert, die protokollierbar sein sollen, wenn FAU_GEN Generierung der Sicherheitsprotokolldaten Bestandteil des PP/des ST ist. FCS_RNG.1 Zufallszahlenerzeugung Hierarchical to: Keine andere Komponente Dependencies: Keine Abhängigkeiten FCS_RNG.1.1 The TSF shall provide a [selection: physical, non-physical true, deter- ministic, hybrid physical, hybrid deterministic] random number ge- nerator that implements: [assignment: list of security capabilities]. FCS_RNG.1.2 The TSF shall provide random numbers that meet [assignment: a de- fined quality metric]. Erklärung für die Einführung der erweiterten Familie Laut der Definition von OE.NK.RNG in [BSI-CC-PP-0098; BSI-CC-PP-0097] ist die Umgebung des Konnektors für die Zulieferung von Zufallszahlen verantwortlich. Dabei wird nahegelegt, dass die gSMC-K verwendet werden soll: Es ist vorgesehen, den Zufallszahlengenerator der gSMC-K als physikalischen Zufallszah- lengenerator der Klasse PTG.2 zu nutzen. 42 Die KoCoBox MED+ verwendet den Zufallsgenerator der gSMC-K; allerdings wird er genutzt, um einen eigenen Zufallsgenerator Hash_DRBG nach [NIST SP 800-90A, Sect. 10.1.1] in regelmäßigen Abständen mit Zufallszahlen zu initialisieren. Um die Sicherheitseigenschaften dieser eigenen Imple- mentierung beschreiben zu können, wird hier die Familie FCS_RNG eingeführt. Deren SFR werden später benutzt, um Anforderungen an den Zufallsgenerator des TOE zu stellen. 5.2. Definition der erweiterten Familie FPT_EMS Die Definitionen der Familie FPT_EMS und der Sicherheitsanforderung FPT_EMS.1 werden ohne Ände- rung aus [BSI-CC-PP-0097] und [BSI-CC-PP-0098] übernommen. 5.3. Definition der erweiterten Familie FIA_API Die Definitionen der Familie FIA_API und der Sicherheitsanforderung fia_api.1/ak werden ohne Ände- rung aus [BSI-CC-PP-0098] übernommen. 43 6. Sicherheitsanforderungen 6.1. Hinweise und Definitionen Der größte Teil der Sicherheitsanforderungen wird ohne Anpassungen aus dem Schutzprofil übernom- men. Anpassungen werden kenntlich gemacht. Bei denjenigen SFR, die das Schutzprofil bereits vor- sieht, wird in diesem Security Target darauf verzichtet, die Hierarchie der Komponenten sowie deren Abhängigkeiten zu wiederholen. Diese Informationen sind dem Schutzprofil [BSI-CC-PP-0098] zu entnehmen. Bei Sicherheitsanforderungen, die durch das Security Target hinzugefügt werden, sind die Hierarchie- und Abhängigkeitsinformationen aufgeführt. 6.1.1. Hinweise zur Notation Die typographischen Auszeichnungen für die Operationen an den SFR sind in Tabelle 6.1 beschrie- ben. Die Anpassungen der Formatierungen gegenüber dem Schutzprofil [BSI-CC-PP-0097] dienen der Vereinheitlichung zwischen den Schutzprofilen [BSI-CC-PP-0097] und [BSI-CC-PP-0098]. ST-seitige Löschungen werden immer von einem Hinweis begleitet, wie die Löschung motiviert ist. Quelle Art der Anpassung Typographische Eigenschaften PP Zuweisung (Assignment) Zuweisungen sind unterstrichen gesetzt. Auswahl (Selection) Auswahlen sind kursiv und unterstrichen gesetzt. Verfeinerung (Refinement) Verfeinerungen sind fett gesetzt. Löschung (Deletion) Löschungen sind fett und durchgestrichen gesetzt. ST Zuweisung (Assignment) Zuweisungen sind in blauer Schrift gesetzt. Auswahl (Selection) Auswahlen sind in blauer Schrift und kursiv gesetzt. Verfeinerung (Refinement) Verfeinerungen sind in blauer Schrift und fett gesetzt. Löschung (Deletion) Löschungen sind in blauer Schrift, fett und durchgestrichen gesetzt. Tabelle 6.1.: Typographische Konventionen 6.1.2. Modellierung von Subjekten, Objekten, Attributen und Operationen 6.1.2.1. Hinweise zu Übernahmen aus dem Schutzprofil Die Modellierungen des Schutzprofils [BSI-CC-PP-0098] gelten auch für dieses Security Target. Die Architektur des TOE mit seinen Java Virtual Machines ist monolithischer als es die Definitio- nen der Subjekte im Schutzprofil suggerieren. Die dort definierten Subjekte wie S_AK, S_Signaturdienst, S_Chipkartendienst etc. sind grundsätzlich auch für die KoCoBox MED+ anwendbar. Jedoch manifes- tieren sie sich nicht in der Implementierung in Form von separaten Prozessen. Alle diese Subjekte 44 existieren in der JVM des Anwendungskonnektors. Innerhalb der JVM sind die Subjekte nicht phy- sisch voneinander abgegrenzt. Das hat Implikationen auf die Sicherheitsanforderungen in den Famili- en FDP_ACC und FDP_ACF. Anforderungen wie „Nur der Chipkartendienst darf…“ werden nicht durch Kontrollmechanismen umgesetzt, sondern dadurch, dass aus der Implementierung heraus ersichtlich ist, dass keine Aufrufe stattfinden, die nicht in der Sicherheitsarchitektur vorgesehen sind. 45 6.2. Funktionale Sicherheitsanforderungen des Netzkonnektors 6.2.1. VPN Client FTP_ITC.1/NK.VPN_TI Inter-TSF trusted channel FTP_ITC.1.1/NK.VPN_TI Die in [BSI-CC-PP-0097, Abschnitt 6.2.1] und [BSI-CC-PP-0098, Abschnitt 6.2.1] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FTP_ITC.1.2/NK.VPN_TI Die in [BSI-CC-PP-0097, Abschnitt 6.2.1] und [BSI-CC-PP-0098, Abschnitt 6.2.1] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FTP_ITC.1.3/NK.VPN_TI Die in [BSI-CC-PP-0097, Abschnitt 6.2.1] und [BSI-CC-PP-0098, Abschnitt 6.2.1] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FTP_ITC.1/NK.VPN_SIS Inter-TSF trusted Channel FTP_ITC.1.1/NK.VPN_SIS Die in [BSI-CC-PP-0097, Abschnitt 6.2.1] und [BSI-CC-PP-0098, Abschnitt 6.2.1] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FTP_ITC.1.2/NK.VPN_SIS Die in [BSI-CC-PP-0097, Abschnitt 6.2.1] und [BSI-CC-PP-0098, Abschnitt 6.2.1] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FTP_ITC.1.3/NK.VPN_SIS Die in [BSI-CC-PP-0097, Abschnitt 6.2.1] und [BSI-CC-PP-0098, Abschnitt 6.2.1] formulierten Sicherheitsanforderungen gelten ohne Anpassung. 6.2.2. Dynamischer Paketfilter mit zustandsgesteuerter Filterung FDP_IFC.1/NK.PF Subset information flow control FDP_IFC.1.1/NK.PF Die in [BSI-CC-PP-0097, Abschnitt 6.2.2] und [BSI-CC-PP-0098, Abschnitt 6.2.2] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FDP_IFF.1/NK.PF Simple security attributes FDP_IFF.1.1/NK.PF The TSF shall enforce the PF SFP based on the following types of subject and information security attributes: 46 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 IP traffic), (5) interface (inbound and outbound traffic). The subject active entity in the LAN has the security attribute IP address within ANLW_LAN_NETWORK_SEGMENT or ANLW_LEKTR_INTRANET_ROUTES. FDP_IFF.1.2/NK.PF Die in [BSI-CC-PP-0097, Abschnitt 6.2.2] und [BSI-CC-PP-0098, Abschnitt 6.2.2] formulierten Sicherheitsanforderungen gelten ohne Anpassung. The usage of a VPN connection for security relevant data shall be enforced by using an appropriate set of policies of the network subsystem that demand data from the application connector to be routed into the VPN. ST-Anwendungshinweis 1 Die Unterpunkte FDP_IFF.1.2/NK.PF(8), (11), (12) und (13) referenzieren den Betriebsmodus MGM_LOGICAL_SEPARATION, der in der Konnektor- Spezifikation entfallen ist [gemSpec_Kon]. Die logische Trennung ist nicht im TOE implementiert ist. Daher ist es nicht möglich, die Aus- wahl „logische Trennung“ zu aktivieren, somit gilt MGM_LOGICAL_SE- PARATION=Disabled. Dieser Hinweis gilt auch für alle weiteren Vor- kommen von MGM_LOGICAL_SEPARATION. FDP_IFF.1.3/NK.PF Die in [BSI-CC-PP-0097, Abschnitt 6.2.2] und [BSI-CC-PP-0098, Abschnitt 6.2.2] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FDP_IFF.1.4/NK.PF The TSF shall explicitly authorise an information flow based on the following rules: Stateful Packet Inspection, none1. FDP_IFF.1.5/NK.PF The TSF shall explicitly deny an information flow based on the fol- lowing 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. 1 Assignment: rules, based on security attributes, that explicitly authorise information flow 47 (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_BESTANDS- NETZE but outside ANLW_AKTIVE_BESTANDSNETZE. (5) The TSF prevents communication of service modules with NET_TI_ZENTRAL, NET_TI_DEZENTRAL, ANLW_AKTIVE_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_OFFENE_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_ZEN- TRAL, NET_TI_GESICHERTE_FD, NET_TI_DE- ZENTRAL, ANLW_AKTIVE_BESTANDSNET- ZE, ANLW_LAN_ADDRESS_SEGMENT, AN- LW_LEKTR_INTRANET_ROUTES and AN- LW_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_LOGI- CAL_SEPARATION=Disabled and ANLW_INTER- NET_MODUS=KEINER). (9) The TSF prevents inbound packets of the VPN channels from SIS with destination address in the inner header outside 1. ANLW_LAN_IP_ADDRESS or 2. ANLW_LEKTR_INTRANET_ROUTES if ANLW_WAN_ADAPTER_MODUS=DISABLED or 3. ANLW_WAN_IP_ADDRESS if ANLW_WAN_ADAPTER_MODUS=ACTIVE 48 (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) All firewall rules defined in [gemSpec_Kon, Ab- schnitt 4.2.1.1.2] that call for traffic to be dropped.2 ST-Anwendungshinweis 2 Die [gemSpec_Kon] gibt sämtliche Paketfilterregeln vor. Damit sind auch die erlaubten Protokolle durch [gemSpec_Kon, TIP1-A_4747] festgelegt: ICMP, IP in IP, UDP, TCP, ESP und IPComp. Da die Nutzung von IPComp insgesamt optional ist, lehnt der TOE das IP- Comp und das nur dann benötigte IP in IP Protokoll zusätzlich ab. Für das Protokoll ICMP gelten für die einzelnen ICMP-Typen die Bestimmungen aus [gemSpec_Kon] und [gemSpec_Net] ST-Anwendungshinweis 3 Das Fachmodul VSDM ist Teil des Anwendungskonnektors, somit gelten auch die Firewallregeln des Anwendungskonnektors. Hintergrund: Das Fachmodul VSDM wird – anders als andere Fach- module der Ausbaustufe OPB 2.1 – nicht nach Technischer Richt- linie, sondern nach Common Criteria zertifiziert, im selben Verfah- ren wie der Anwendungskonnektor. Das Schutzprofil [BSI-CC-PP- 0098] formuliert die Sicherheitsanforderungen FDP_ACC.1/AK.VSDM und FDP_ACF.1/AK.VSDM an das Fachmodul. Dies verdeutlicht die ar- chitekturelle Einheit zwischen FM VSDM und Anwendungskonnek- tor. FMT_MSA.3/NK.PF Static attribute initialisation FMT_MSA.3.1/NK.PF Die in [BSI-CC-PP-0097, Abschnitt 6.2.2] und [BSI-CC-PP-0098, Abschnitt 6.2.2] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FMT_MSA.3.2/NK.PF The TSF shall allow the3 nobody4 to specify alternative initial values to override the default values when an object or information is created. 6.2.3. Netzdienste FPT_STM.1/NK Reliable time stamps FPT_STM.1.1/NK Die in [BSI-CC-PP-0097, Abschnitt 6.2.3] und [BSI-CC-PP-0098, Abschnitt 6.2.3] formulierten Sicherheitsanforderungen gelten ohne 2 Assignment: Additional rules, based on security attributes, that explicitly deny information flows 3 Deletion: Editorielle Anpassung 4 Assignment: the authorised identified roles 49 Anpassung. Refinement: Die Zuverlässigkeit (reliable) des Zeitstempels wird durch Zeitsyn- chronisation der Echtzeituhr (gemäß OE.NK.Echtzeituhr) mit Zeit- servern (vgl. OE.NK.Zeitsynchro) unter Verwendung des Protokolls NTPv4 [RFC 5905] 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. Befin- det sich der EVG im Online-Modus, muss er die Zeitsynchronisa- tion mindestens bei Start-up, einmal innerhalb von 24 Stunden und auf Anforderung durch den Administrator durchführen. Die verteilte Zeitinformation weicht nicht mehr als 3600 Sekunden5 von der Zeit- information der darüber liegenden Stratum-Ebene ab. ST-Anwendungshinweis 4 Der TOE benachrichtigt Benutzer auf seinem Display über kritische Betriebszustände. Das Display entspricht der „Signaleinrichtung“ des Konnektors, wie die Spezifikation sie fordert [gemSpec_Kon, TIP1- A_4843]. Der Netzkonnektor steuert das Display über die logische Schnittstelle LS.DISPLAY an. Das Schutzprofil fordert in Anwendungs- hinweis 87, dass die „Korrektheit der Kommunikation zwischen dem NK und anderen Konnektorteilen“ im Rahmen der Prüfung von FPT_STM.1/NK evaluiert wird. Aus diesem Grund werden Module der Subsysteme EventService und RMIBridge diesem SFR zugeordnet, auch wenn diese Subsysteme ursprünglich nicht im Zusammenhang mit der Zeitsynchronisation stehen. FPT_TDC.1/NK.Zert Inter-TSF basic TSF data consistency FPT_TDC.1.1/NK.Zert Die in [BSI-CC-PP-0097, Abschnitt 6.2.3] und [BSI-CC-PP-0098, Abschnitt 6.2.3] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FPT_TDC.1.2/NK.Zert The TSF shall use interpretation rules when interpreting the TSF data from another trusted IT product. The interpretation rules are defined in TUC_PKI_018 „Zertifikats- prüfung in der TI“ considering the verification mode „CRL“ [gemSpec_PKI, Abschnitt 8.3.1.1]. ST-Anwendungshinweis 5 Das Refinement des Schutzprofils zu FPT_TDC.1/NK.Zert verpflichtet den TOE zu prüfen, „dass […] sowohl TSL als auch CRL aktuell sind“. Dieses Refinement wird gemäß GS-A_4898 ergänzt durch den Verweis auf Tab_PKI_294, in der die Gültigkeit der TSL präzisiert wird. 5 Selection: nicht mehr als 330ms, [Zuweisung: andere Zeit] 50 6.2.4. Stateful Packet Inspection (This section intentionally left blank.) 6.2.5. Selbstschutz FDP_RIP.1/NK Subset residual information protection FDP_RIP.1.1/NK The TSF shall ensure that any previous informati- on content of a resource is made unavailable upon the deallocation of the resource from the following objects: cryptographic keys (and session keys) used for the VPN or for TLS-connections, sensitive user data (zu schützende Daten der TI und der Bestandsnetze and zu schützende Nutzerdaten), no other objects6. Refinement: Die sensitive 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. These sensitive objects are overwritten with constant or pseudo- random values. FPT_TST.1/NK TSF testing FPT_TST.1.1/NK The TSF shall run a suite of self tests during initial start-up, periodi- cally during normal operation, at the request of the authorised user7 to demonstrate the correct operation of stored TSF executable code8. FPT_TST.1.2/NK The TSF shall provide authorised users with the capability to verify the integrity of TSF data. FPT_TST.1.3/NK The TSF shall provide authorised users with the capability to verify the integrity of stored TSF executable code9. ST-Anwendungshinweis 6 The „stored TSF executable code“ comprises not only strictly the code, but all parts of the firmware such as XML schema files. 6 Assignment: list of objects 7 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] 8 Selection: [assignment: parts of TSF], the TSF 9 Selection: [assignment: parts of TSF], the TSF 51 FPT_EMS.1/NK Emanation of TSF and User data 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) in excess of limits that ensure that no leakage of this sensitive data occurs enabling access to (1) session keys derived in course of the Diffie-Hellman Keyexchange Protocol, (2) key material used to verify the TOE’s integrity during self tests10, (3) key material used to verify the integrity and authenticity of soft- ware updates11, (4) none12, (5) key material used for authentication of administrative users13, (6) none14 and (7) data to be protected (“zu schützende Daten der TI und der Bestandsnetze”) (8) none15. FPT_EMS.1.2/NK Die in [BSI-CC-PP-0097, Abschnitt 6.2.5] und [BSI-CC-PP-0098, Abschnitt 6.2.5] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FAU_GEN.1/NK.SecLog Audit data generation FAU_GEN.1.1/NK.SecLog The TSF shall be able to generate an audit record of the following auditable events: a) Removed by refinement in [BSI-CC-PP-0098] b) All auditable events for the not specified16 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, 10 Selection: none, key material used to verify the TOE’s integrity during self tests 11 Selection: none, key material used to verify the integrity and authenticity of software updates 12 Selection: none, key material used to decrypt encrypted software updates (if applicable) 13 Selection: none, key material used for authentication of administrative users (if applicable) 14 Assignment: list of other types of TSF data (may be empty) 15 Assignment: list of types of user data (may be empty) 16 Selection: choose one of: minimum, basic, detailed, not specified 52 • IP addresses of the TOE are undefined or wrong, • TOE could not perform system time synchronization within the last 30 days, • during time synchronization, 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 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 defini- tions of the functional components included in the PP/ST, and no other audit relevant information17. The TOE shall implement countermeasures against attacks at- tempting to flood the audit log in order to use the limited size of the audit log memory and the process of cyclically overwriting log memory to overwrite log entries that provide evidence of the attacker’s activity. ST-Anwendungshinweis 7 Die zu loggenden „auditable events“ wurden mit der Zertifizierungs- stelle und den Evaluatoren abgeglichen und die Konformität zu [gem- Spec_Kon] wurde sichergestellt. FAU_GEN.2/NK.SecLog User identity association FAU_GEN.2.1/NK.SecLog Die in [BSI-CC-PP-0097, Abschnitt 6.2.5] und [BSI-CC-PP-0098, Abschnitt 6.2.5] formulierten Sicherheitsanforderungen gelten ohne Anpassung. 6.2.6. Administration FMT_SMR.1/NK Security roles FMT_SMR.1.1/NK Die in [BSI-CC-PP-0097, Abschnitt 6.2.6] und [BSI-CC-PP-0098, Abschnitt 6.2.6] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FMT_SMR.1.2/NK Die in [BSI-CC-PP-0097, Abschnitt 6.2.6] und [BSI-CC-PP-0098, Abschnitt 6.2.6] formulierten Sicherheitsanforderungen gelten ohne Anpassung. 17 Assignment: other audit relevant information 53 FMT_MTD.1/NK Management of TSF data FMT_MTD.1.1/NK The TSF shall restrict the ability to perform the operations in the „Ope- ration“ column of the following table on18 the real time clock, packet filtering rules and other TSF data named in the „Object“ column of the following table19 to the role Administrator. Operation Object Modify System time20 Create, Modify, Delete Packet filtering rules Perform Self-tests Perform Software update Perform Activation and deactivation of VPN connections21 FIA_UID.1/NK.SMR Timing of identification FIA_UID.1.1/NK.SMR Die in [BSI-CC-PP-0097, Abschnitt 6.2.6] und [BSI-CC-PP-0098, Abschnitt 6.2.6] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FIA_UID.1.2/NK.SMR Die in [BSI-CC-PP-0097, Abschnitt 6.2.6] und [BSI-CC-PP-0098, Abschnitt 6.2.6] formulierten Sicherheitsanforderungen gelten ohne Anpassung. Refinement: Additionally, the TOE prevents the following TSF-mediated ac- tions on behalf of the user before the user is identified: • All operations stated in FMT_MTD.1.1/NK. FTP_TRP.1/NK.Admin Trusted path FTP_TRP.1.1/NK.Admin The TSF shall provide a communication path between itself and lo- cal22 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, disclosure23. FTP_TRP.1.2/NK.Admin The TSF shall permit local users24 to initiate communication via the trusted path. 18 Selection: change_default, query, modify, delete, clear, [assignment: other operations] 19 Assignment: list of other TSF data (may be empty) 20 Only available in offline mode, when there is no connection to the NTP servers. 21 Please note that deactivation of a VPN connection also ensures that any network traffic which should be routed via the VPN is not possible at all. 22 Selection: remote, local 23 Selection: modification, disclosure, [assignment: other types of integrity or confidentiality violation] 24 Selection: the TSF, local users, remote users 54 FTP_TRP.1.3/NK.Admin Die in [BSI-CC-PP-0097, Abschnitt 6.2.6] und [BSI-CC-PP-0098, Abschnitt 6.2.6] formulierten Sicherheitsanforderungen gelten ohne Anpassung. ST-Anwendungshinweis 8 Der TOE setzt die Funktionalität für das Remote Management nicht um. FMT_SMF.1/NK Specification of Management Functions FMT_SMF.1.1/NK Die in [BSI-CC-PP-0097, Abschnitt 6.2.6] und [BSI-CC-PP-0098, Abschnitt 6.2.6] formulierten Sicherheitsanforderungen gelten ohne Anpassung. The TOE shall be capable of performing all security manage- ment functions stated in FMT_MTD.1/NK. FMT_MSA.1/NK.PF Management of security attributes FMT_MSA.1.1/NK.PF The TSF shall enforce the PF SFP to restrict the ability to query, modify, delete25 the security attributes packet filtering rules to the roles „Administrator“, no other role26. The refinement from [BSI-CC-PP-0097] applies without modificati- on. ST-Anwendungshinweis 9 Die Firewallregeln sind fester Bestandteil des TOE und lassen sich somit nur durch ein Update des gesamten TOE aktualisieren. FMT_MSA.4/NK Security attribute value inheritance FMT_MSA.4.1/NK Die in [BSI-CC-PP-0097, Abschnitt 6.2.6] und [BSI-CC-PP-0098, Abschnitt 6.2.6] formulierten Sicherheitsanforderungen gelten ohne Anpassung. 6.2.7. Kryptographische Basisdienste FCS_COP.1/NK.Hash Cryptographic operation FCS_COP.1.1/NK.Hash The TSF shall perform hash value calculation in accordance with a specified cryptographic algorithm SHA-1, SHA-256, SHA-51227 and cryptographic key sizes none that meet the following: FIPS PUB 180-4 [FIPS PUB 180-4]. 25 Selection: query, modify, delete, [assignment: other operations] 26 Assignment: (may be empty): other authorised identified roles 27 Assignment: list of SHA-2 Algorithms with more than 256 bit size 55 FCS_COP.1/NK.HMAC Cryptographic operation FCS_COP.1.1/NK.HMAC The TSF shall perform HMAC value generation and verification in accordance with a specified cryptographic algorithm HMAC with SHA-1, SHA-25628 and cryptographic key sizes 160 and 256 bit29 that meet the following: FIPS PUB 180-4 [FIPS PUB 180-4], RFC 2404 [RFC 2404], RFC 4868 [RFC 4868], RFC 7296 [RFC 7296]. FCS_COP.1/NK.Auth Cryptographic operation FCS_COP.1.1/NK.Auth Die in [BSI-CC-PP-0097, Abschnitt 6.2.7] und [BSI-CC-PP-0098, Abschnitt 6.2.7] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FCS_COP.1/NK.ESP Cryptographic operation FCS_COP.1.1/NK.ESP Die in [BSI-CC-PP-0097, Abschnitt 6.2.7] und [BSI-CC-PP-0098, Abschnitt 6.2.7] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FCS_COP.1/NK.IPsec Cryptographic operation FCS_COP.1.1/NK.IPsec Die in [BSI-CC-PP-0097, Abschnitt 6.2.7] und [BSI-CC-PP-0098, Abschnitt 6.2.7] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FCS_CKM.1/NK Cryptographic key generation FCS_CKM.1.1/NK The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm PRF-HMAC- SHA1, PRF-HMAC-SHA25630 and specified cryptographic key si- zes 256 bit31 that meet the following: specification [gemSpec_Krypt], TR-03116 [TR-03116-1]. 28 Assignment: list of SHA-2 Algorithms with 256bit size or more 29 Assignment: cryptographic key sizes 30 Assignment: cryptographic key generation algorithm 31 Assignment: cryptographic key sizes 56 FCS_CKM.2/NK.IKE Cryptographic key distribution FCS_CKM.2.1/NK.IKE Die in [BSI-CC-PP-0097, Abschnitt 6.2.7] und [BSI-CC-PP-0098, Abschnitt 6.2.7] formulierten Sicherheitsanforderungen gelten ohne Anpassung. The following algorithms and preferences are supported for IKEv2 connections: • Diffie-Hellman Group 14 • DH exponent minimum length: 384 bits • Forward secrecy: yes • Encryption: AES-256-CBC • Authentication: HMAC-SHA-1-96, HMAC-SHA-256-128 • PRF: PRF-HMAC-SHA1, PRF-HMAC-SHA-256 • Rekeying: IKE lifetime limited to 161 hours, IPsec SA life- time limited to 23 hours • Peer authentication: X.509 certificate with RSA 2048 bit keys FCS_CKM.4/NK Cryptographic key destruction FCS_CKM.4.1/NK The TSF shall destroy cryptographic keys in accordance with a spe- cified cryptographic key destruction method by overwriting with ze- ros32 that meets the following: none33. 6.2.8. TLS-Kanäle unter Nutzung sicherer kryptographischer Algorithmen FTP_ITC.1/NK.TLS Inter-TSF trusted channel FTP_ITC.1.1/NK.TLS Die in [BSI-CC-PP-0097, Abschnitt 6.2.8] und [BSI-CC-PP-0098, Abschnitt 6.2.8] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FTP_ITC.1.2/NK.TLS Die in [BSI-CC-PP-0097, Abschnitt 6.2.8] und [BSI-CC-PP-0098, Abschnitt 6.2.8] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FTP_ITC.1.3/NK.TLS The TSF shall initiate communication via the trusted channel for communication required by the Anwendungskonnektor, any connec- tion specified in Table B.4.34 32 Assignment: cryptographic key destruction method 33 Assignment: list of standards 34 Assignment: list of other functions for which a trusted channel is required 57 Refinement: Das Refinement im Schutzprofil [BSI-CC-PP-0098] gilt ohne Ein- schränkungen. Die umgesetzten Cipher Suiten aus dem Schutzprofil und der gematik Spezifikation [gemSpec_Krypt] werden in Tabel- le B.1 auf Seite 147 wiederholt. FPT_TDC.1/NK.TLS.Zert Inter-TSF basic TSF data consistency 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) (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 other data types35 when shared between the TSF and another trusted IT product. FPT_TDC.1.2/NK.TLS.Zert The TSF shall use interpretation rules36 when interpreting the TSF data from another trusted IT product. The interpretation rules are defined in TUC_PKI_018 „Zertifikats- prüfung in der TI“ [gemSpec_PKI, Abschnitt 8.3.1.1]. The para- meters for certificate validation are specified in GS-A_4663 [gem- Spec_PKI, Abschnitt 8.4.1].37 Furthermore, GS-A_5215 [gemSpec_PKI, Abschnitt 9.1.2.2] de- fines rules for the interpretation of time stamps embedded in OCSP responses, which have to be taken into account when in- terpreting TSF data.38 FCS_CKM.1/NK.TLS Cryptographic key generation / TLS FCS_CKM.1.1/NK.TLS Die in [BSI-CC-PP-0097, Abschnitt 6.2.8] und [BSI-CC-PP-0098, Abschnitt 6.2.8] formulierten Sicherheitsanforderungen gelten ohne Anpassung. The following algorithms and preferences are supported for TLS key negotiation39 35 Assignment: additional list of data types 36 Assignment: list of interpretation rules to be applied by the TSF 37 Refinement: Präzisierung der Interpretationsregeln 38 Refinement: Ergänzt gemäß Anforderungen aus GS-A_5215, vgl. Anhang D 39 Refinement: Ergänzt gemäß Anforderungen aus GS-A_4384, vgl. Anhang D 58 • Diffie-Hellman Group 14 according to RFC 3526 [RFC 3526] for key establishment during TLS • DH exponent shall have a minimum length of 384 bits • Forward secrecy shall be provided • Ephemeral elliptic curve DH key exchange supports the P-256 and the P-384 curves according to FIPS186-4 [FIPS PUB 186-2] as well as the brainpoolP256r1 and the brain- poolP384r1 curves according to RFC 5639 and RFC 7027 [RFC 5639; RFC 7027] • Peer authentication (if required): X.509 certificate with RSA 2048 bit keys FCS_COP.1/NK.TLS.HMAC Cryptographic operation / HMAC for TLS FCS_COP.1.1/NK.TLS.HMAC Die in [BSI-CC-PP-0097, Abschnitt 6.2.8] und [BSI-CC-PP-0098, Abschnitt 6.2.8] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FCS_COP.1/NK.TLS.AES Cryptographic operation FCS_COP.1.1/NK.TLS.AES Die in [BSI-CC-PP-0097, Abschnitt 6.2.8] und [BSI-CC-PP-0098, Abschnitt 6.2.8] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FCS_COP.1/NK.TLS.Auth Cryptographic operation for TLS FCS_COP.1.1/NK.TLS.Auth Die in [BSI-CC-PP-0097, Abschnitt 6.2.8] und [BSI-CC-PP-0098, Abschnitt 6.2.8] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FCS_CKM.1/NK.Zert Cryptographic key generation / Certificates FCS_CKM.1.1/NK.Zert The TSF shall generate cryptographic keys in accordance with a spe- cified cryptographic key generation algorithm RSA (using the ran- dom number generator specified by FCS_RNG.1/Hash_DRBG)40 and specified cryptographic key sizes 2048 bit that meet the following: Standard OID 1.2.840.113549.1.1.11, RFC 4055 [RFC 4055], BSI TR-03116-1 [TR-03116-1]. The TSF shall 40 Assignment: Algorithm for cryptographic key generation of key pairs 59 (1) create a valid X.509 certificate [RFC 5280] with the gene- rated RSA key pair and (2) create a PKCS#12 file [RFC 7292]41 with the created cer- tificate and the associated private key. FDP_ITC.2/NK.TLS Import of user data with security attributes FDP_ITC.2.1/NK.TLS Die in [BSI-CC-PP-0097, Abschnitt 6.2.8] und [BSI-CC-PP-0098, Abschnitt 6.2.8] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FDP_ITC.2.2/NK.TLS Die in [BSI-CC-PP-0097, Abschnitt 6.2.8] und [BSI-CC-PP-0098, Abschnitt 6.2.8] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FDP_ITC.2.3/NK.TLS Die in [BSI-CC-PP-0097, Abschnitt 6.2.8] und [BSI-CC-PP-0098, Abschnitt 6.2.8] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FDP_ITC.2.4/NK.TLS Die in [BSI-CC-PP-0097, Abschnitt 6.2.8] und [BSI-CC-PP-0098, Abschnitt 6.2.8] formulierten Sicherheitsanforderungen gelten ohne Anpassung. 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) No further rule42 FDP_ETC.2/NK.TLS Export of user data with security attributes FDP_ETC.2.1/NK.TLS Die in [BSI-CC-PP-0097, Abschnitt 6.2.8] und [BSI-CC-PP-0098, Abschnitt 6.2.8] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FDP_ETC.2.2/NK.TLS Die in [BSI-CC-PP-0097, Abschnitt 6.2.8] und [BSI-CC-PP-0098, Abschnitt 6.2.8] formulierten Sicherheitsanforderungen gelten ohne Anpassung. FDP_ETC.2.3/NK.TLS Die in [BSI-CC-PP-0097, Abschnitt 6.2.8] und [BSI-CC-PP-0098, Abschnitt 6.2.8] formulierten Sicherheitsanforderungen gelten ohne Anpassung. 41 Refinement: Die Quelle für den PKCS#12 Standard wurde gegenüber dem Schutzprofil aktualisiert. 42 Assignment: additional importation control rules 60 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 Administrator über die Management-Schnittstelle. Als Exportformat wird PKCS#12 verwendet. (2) No further rule43 FMT_MOF.1/NK.TLS Management of security functions behaviour FMT_MOF.1.1/NK.TLS The TSF shall restrict the ability to determine the behaviour of the functions Management of TLS-Connections required by the Anwendungskonnektor to Anwendungskonnektor. 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 me- chanism 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 connec- tion. (5) Which data can or must be transmitted via each TLS- Connection. (6) Whether the validity of the certificate of a remote IT- Pro- duct 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 im- ported. (10) No further rule44 43 Assignment: additional exportation control rules 44 Assignment: additional rules 61 If one or more of these rules are managed by the EVG itself, this shall also be interpreted as a fullfillment of this SFR. ST-Anwendungshinweis 10 Gemäß C_6968 und der daraus resultierenden Anforderung A_18464 darf TLS 1.1 nicht mehr verwendet werden. Der TOE setzt diese An- forderung um und unterstützt TLS 1.1 nicht mehr. ST-Anwendungshinweis 11 TLS wird vom Konnektor von JSSE implementiert. Jeder in Java im- plementierte Teil des TOE kann prinzipiell eine TLS-Verbindung er- öffnen. Es gibt keine Kontrollinstanz, die die Einhaltung der oben ge- nannten Konfigurationsparameter einer TLS-Verbindung erzwingt. 6.2.9. Zusätzliche Sicherheitsanforderungen Dieser Abschnitt enthält Sicherheitsanforderungen, die zusätzlich zu denen des Schutzprofils definiert werden. Die Anforderungen an den Netzkonnektor werden hier um die in Kapitel 5.1 definierte Anfor- derung FCS_RNG.1/Hash_DRBG erweitert. Weiterhin werden Anforderungen definiert, deren Umsetzung notwendig für den sicheren Datenspeicher ist. Zwar ist der sichere Datenspeicher Teil des Gesamtkon- nektors, dennoch werden bereits hier Aspekte berücksichtigt, die für die Speicherung des Sicherheits- protokolls relevant sind. FCS_RNG.1/Hash_DRBG Zufallszahlenerzeugung Hierarchical to: No other components Dependencies: No dependencies FCS_RNG.1.1/Hash_DRBG The TSF shall provide a deterministic45 random number generator that implements: 46 (1) If initialized with a random seed using PTRNG of class PTG.2 as random source, the internal state of the RNG shall have at least 100 bits min-entropy. (2) The RNG provides forward secrecy. (3) The RNG provides backward secrecy even if the current inter- nal state is known. FCS_RNG.1.2/Hash_DRBG The TSF shall provide random numbers that meet: 47 (1) The RNG gets initialized during every startup and after 2048 requests with a random seed of minimal 384 bits using a PT- RNG of class PTG.2. The RNG generates output for which more than 234 strings of bit length 128 are mutually different with probability w > 1 − 2(−16). 45 Selection: physical, non-physical true, deterministic, hybrid physical, hybrid deterministic 46 Assignment: list of security capabilities 47 Assignment: a defined quality metric 62 (2) Statistical test suites cannot practically distinguish the random numbers from output sequences of an ideal RNG. The random numbers must pass test procedure A. ST-Anwendungshinweis 12 FCS_RNG.1/Hash_DRBG is implemented by Hash_DRBG with SHA- 256 according to [NIST SP 800-90A, Sect. 10.1.1]. It is used for ge- neration of ephemeral keys for Diffie-Hellman and nonces in the TLS protocol. FCS_COP.1/Sign Cryptographic Operation / Signature Verfication 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) not fulfilled in this ST as no keys have to be generated for signature verification. The key pair for signature generation/verification is stored on the gSMC-K and has been created during production. FCS_CKM.4 Cryptographic key destruction is not fulfilled in this ST as only public keys are used for this operation. FCS_COP.1.1/Sign The TSF shall perform signature verification48 in accordance with a specified cryptographic algorithm according to Tabelle 6.249 and cryptographic key sizes according to Tabelle 6.250 that meet the fol- lowing: PKCS#1 [RFC 8017] and FIPS180-4 [FIPS PUB 180-4]51. Algorithm Key size (bits) Purpose: Verification of… RSASSA-PSS with SHA-256 2048 Signatures of TSL and CRL RSASSA-PSS with SHA-512 2048 Firmware update signatures RSASSA-PKCS1-1.5 with SHA-256 2048 Signatures of BNetzA-VL RSASSA-PSS with SHA-256 4096 Signatures for X.509 certificates during the firmware update process Tabelle 6.2.: Algorithms, Key sizes and Purposes of Signature Verification 48 Assignment: list of cryptographic operations 49 Assignment: cryptographic algorithm 50 Assignment: cryptographic key sizes 51 Assignment: list of standards 63 FCS_COP.1/Storage.AES Cryptographic Operation / Secure Storage AES 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) not fulfilled by the TOE. The sym- metric key is generated by the gSMC-K. FCS_CKM.4 Cryptographic key destruction fulfilled by FCS_CKM.4/NK FCS_COP.1.1/Storage.AES The TSF shall perform symmetric encryption/decryption52 in ac- cordance with a specified cryptographic algorithm AES CBC with ESSIV53 and cryptographic key sizes 256 bit54 that meet the fol- lowing: FIPS197 [FIPS PUB 197], SP800-38A [NIST SP 800-38A], and ESSIV [ESSIV]55. 6.3. Funktionale Sicherheitsanforderungen des Anwendungskonnektors 6.3.1. Klasse FCS: Kryptographische Unterstützung 6.3.1.1. Basisalgorithmen Der Konnektor nutzt kryptographische Dienste der gSMC-K in der Einsatzumgebung. Das Schutzprofil COS [BSI-CC-PP-0082-2] fordert die Evaluierung der kryptographischen Funktionen des Betriebssys- tems der gSMC-K, die durch das Objektsystem der gSMC-K ausgewählt werden. 6.3.1.2. Schlüsselerzeugung und Schlüssellöschung FCS_COP.1/AK.SHA Cryptographic operation / hash value calculation AK FCS_COP.1.1/AK.SHA Die in [BSI-CC-PP-0098, Abschnitt 6.3.1.2] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FCS_CKM.1/AK.AES Cryptographic key generation / AES keys FCS_CKM.1.1/AK.AES The TSF shall generate cryptographic keys in accordance with a spe- cified cryptographic key generation algorithm randomly created ac- cording to FCS_RNG.1/Hash_DRBG56 and specified cryptographic key 52 Assignment: list of cryptographic operations 53 Assignment: cryptographic algorithm 54 Assignment: cryptographic key sizes 55 Assignment: list of standards 56 Assignment: Algorithm for cryptographic key generation of AES keys 64 sizes 128 bit and 256 bit that meet the following: NISTSP800-133 [NIST SP 800-133, Section 6.1]57. FCS_CKM.4/AK Cryptographic key destruction FCS_CKM.4.1/AK The TSF shall destroy cryptographic keys in accordance with a spe- cified cryptographic key destruction method overwrite with zeros58 that meet the following none59. 6.3.1.3. Signaturerzeugung und Signaturprüfung FCS_COP.1/AK.SigVer.SSA Cryptographic operation / Signature verification PKCS#1 SSA FCS_COP.1.1/AK.SigVer.SSA Die in [BSI-CC-PP-0098, Abschnitt 6.3.1.3] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FCS_COP.1/AK.SigVer.PSS Cryptographic operation / Signature verification PKCS#1 PSS FCS_COP.1.1/AK.SigVer.PSS Die in [BSI-CC-PP-0098, Abschnitt 6.3.1.3] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FCS_COP.1/AK.SigVer.ECDSA Cryptographic operation / Signature verification ECDSA FCS_COP.1.1/AK.SigVer.ECDSA Die in [BSI-CC-PP-0098, Abschnitt 6.3.1.3] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FCS_COP.1/AK.XML.Sign Cryptographic operation / XML signature generation FCS_COP.1.1/AK.XML.Sign Die in [BSI-CC-PP-0098, Abschnitt 6.3.1.3] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FCS_COP.1/AK.CMS.Sign Cryptographic operation / CMS signature generation FCS_COP.1.1/AK.CMS.Sign Die in [BSI-CC-PP-0098, Abschnitt 6.3.1.3] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 57 Assignment: list of standards 58 Assignment: cryptographic key destruction method 59 Assignment: list of standards 65 FCS_COP.1/AK.PDF.Sign Cryptographic operation / PDF signature generation FCS_COP.1.1/AK.PDF.Sign Die in [BSI-CC-PP-0098, Abschnitt 6.3.1.3] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FCS_COP.1/AK.XML.SigPr Cryptographic operation / XML Signature verification FCS_COP.1.1/AK.XML.SigPr Die in [BSI-CC-PP-0098, Abschnitt 6.3.1.3] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FCS_COP.1/AK.CMS.SigPr Cryptographic operation / CMS Signature verification FCS_COP.1.1/AK.CMS.SigPr Die in [BSI-CC-PP-0098, Abschnitt 6.3.1.3] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FCS_COP.1/AK.PDF.SigPr Cryptographic operation / PDF Signature verification FCS_COP.1.1/AK.PDF.SigPr Die in [BSI-CC-PP-0098, Abschnitt 6.3.1.3] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FCS_COP.1/AK.PKCS.SigPr Cryptographic operation / PKCS Signature verification FCS_COP.1.1/AK.PKCS.SigPr The TSF shall perform verify signed binary data with a specified cryp- tographic algorithm (1) PKCS#1v2.2 RSASSA-PKCS1-v1_5, (2) PKCS#1v2.2 RSASSA-PSS, (3) SHA-256 according to FCS_COP.1/AK.SHA for the creation of the DTBS and cryptographic key sizes 1976 bit to 4096 bit60 that meet the following: RFC 8017 [RFC 8017] and FIPS PUB 180-4 [FIPS PUB 180-4] 6.3.1.4. Ver- und Entschlüsselung von Dokumenten FCS_COP.1/AK.AES Cryptographic operation / AES encryption and decryption FCS_COP.1.1/AK.AES Die in [BSI-CC-PP-0098, Abschnitt 6.3.1.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 60 Assignment: cryptographic key sizes 66 FCS_COP.1/AK.XML.Ver Cryptographic operation / XML encryption FCS_COP.1.1/AK.XML.Ver Die in [BSI-CC-PP-0098, Abschnitt 6.3.1.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FCS_COP.1/AK.XML.Ent Cryptographic operation / XML decryption FCS_COP.1.1/AK.XML.Ent The TSF shall perform decryption of XML documents in a hybrid cryptosystem in accordance with a specified cryptographic algorithm RSAOAEP61 and AES-GCM with authentication tag length of 128 bit and cryptographic key sizes 128 bit, 192 bit and 256 bit that meet the following: Standards NIST-SP-800-38D [NIST SP 800-38D], FIPS 197 [FIPS PUB 197] and XMLEnc [XMLEnc] FCS_COP.1/AK.MIME.Ver Cryptographic operation / MIME encryption FCS_COP.1.1/AK.MIME.Ver Die in [BSI-CC-PP-0098, Abschnitt 6.3.1.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FCS_COP.1/AK.MIME.Ent Cryptographic operation / MIME decryption FCS_COP.1.1/AK.MIME.Ent The TSF shall perform decryption of MIME documents in a hybrid cryptosystem in accordance with a specified cryptographic algorithm RSAOAEP62 and AES-GCM with authentication tag length of 128 bit and cryptographic key si- zes 128 bit, 192 bit and 256 bit that meet the following: Standards NIST-SP-800-38D [NIST SP 800-38D], PKCS#1 [RFC 8017], FIPS 197 [FIPS PUB 197] and RFC 5751 [RFC 5751] FCS_COP.1/AK.CMS.Ver Cryptographic operation / CMS encryption FCS_COP.1.1/AK.CMS.Ver Die in [BSI-CC-PP-0098, Abschnitt 6.3.1.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FCS_COP.1/AK.CMS.Ent Cryptographic operation / CMS decryption FCS_COP.1.1/AK.CMS.Ent The TSF shall perform decryption of documents in accordance with a specified cryptographic algorithm RSAOAEP63 and AES-GCM with authentication tag length of 128 bit and cryptographic key 61 Selection: RSA RSAES-PKCS1-v1_5, RSAOAEP 62 Selection: RSA RSAES-PKCS1-v1_5, RSAOAEP 63 Selection: RSA RSAES-PKCS1-v1_5, RSAOAEP 67 sizes 128 bit, 192 bit and 256 bit that meet the following: Standards NIST-SP-800-38D [NIST SP 800-38D], PKCS#1 [RFC 8017], FIPS 197 [FIPS PUB 197] and CMS [RFC 5652] 6.3.2. Klasse FIA: Identifikation und Autorisierung FIA_SOS.1/AK.Passwörter Verification of secrets / Passwords FIA_SOS.1.1/AK.Passwörter The TSF shall provide a mechanism to verify that administrator passwords meet the following criteria:64 • A password consists of the following character classes: upper- case letters, lowercase letters, special characters and numbers. • A password must contain at least one character of three of the aforementioned character classes. • A password must consist of at least 8 characters. • A password must not contain the user’s user ID, neither forward nor backward, in neither lowercase nor uppercase characters. • Upon password change, the TSF must consider previously ente- red passwords. At least the three most recently used passwords in the user’s password history must be rejected when changing the password. ST-Anwendungshinweis 13 Die Zuweisungen in diesem SFR setzen die Anforderungen aus TIP1- A_4808 um. FIA_SOS.1/AK.CS.Passwörter Verification of secrets / Passwords for client systems FIA_SOS.1.1/AK.CS.Passwörter The TSF shall provide a mechanism to verify that passwords for client systems meet the following criteria:65 • A password consists of the following character classes: upper- case letters, lowercase letters, numbers, space, dot, hyphen and underscore. ST-Anwendungshinweis 14 Das verfügbare Alphabet umfasst 66 Zeichen. Bei einer Länge von 17 Zeichen ergibt sich eine Entropie von 102 Bit. Der Hersteller sieht dies als ausreichend sicher an. Um die Interoperabilität mit Clientsys- temen zu wahren, werden auch Passwörter mit mindestens 6 Zeichen Länge akzeptiert. Wenn das Passwort kürzer als 17 Zeichen und län- ger als 6 Zeichen ist, erscheint eine Warnung. Darüber hinaus erhält der Dialog die Möglichkeit zur Generierung eines sicheren Passworts mit mindestens 17 Zeichen. Als Quelle für dieses Passwort wird der gSMC-K-basierte Zufallsgenerator herangezogen. 64 Assignment: a defined quality metric 65 Assignment: a defined quality metric 68 FIA_SOS.2/AK.PairG Generation of pairing secrets FIA_SOS.2.1/AK.PairG Die in [BSI-CC-PP-0098, Abschnitt 6.3.2] formulierten Sicherheits- anforderungen gelten ohne Anpassung. FIA_SOS.2.2/AK.PairG Die in [BSI-CC-PP-0098, Abschnitt 6.3.2] formulierten Sicherheits- anforderungen gelten ohne Anpassung. FIA_UID.1/AK Timing of identification FIA_UID.1.1/AK The TSF shall allow (1) Self test according to FPT_TST.1/AK.Out-Of-Band, (2) (no further action).66 on behalf of the user to be performed before the user is identified. FIA_UID.1.2/AK Die in [BSI-CC-PP-0098, Abschnitt 6.3.2] formulierten Sicherheits- anforderungen gelten ohne Anpassung. FIA_UAU.1/AK Timing of authentication 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 card and 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) no further action.67 on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2/AK Die in [BSI-CC-PP-0098, Abschnitt 6.3.2] formulierten Sicherheits- anforderungen gelten ohne Anpassung. FIA_UAU.5/AK Multiple authentication mechanisms FIA_UAU.5.1/AK The TSF shall provide (1) password based authentication mechanism68 for administrator users, 66 Assignment: list of TSF-mediated actions 67 Assignment: list of TSF mediated actions 68 Selection: password based authentication mechanism, [another authentication mechanism] 69 (2) TLS authentication with a pairing secret for eHKT [gemSpec_Kon], 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 channel, (5) password based and certificate based authentication me- chanisms for client systems69 to support user authentication. ST-Anwendungshinweis 15 Unterpunkt (2) muss interpretiert werden: Die Formulierung „TLS authentication with a pairing secret“ legt nahe, dass das Pairing- Geheimnis für die gegenseitige Authentisierung im Rahmen des TLS- Handshakes verwendet werden soll. TLS-Handshake und Verwendung des Pairing-Geheimnisses gesche- hen jedoch auf unterschiedlichen Ebenen. Zuerst findet ein proto- kollkonformer TLS-Handshake statt, um eine beidseitig authentisier- te TLS-Verbindung zu initiieren. Für diesen Handshake spielt das Pairing-Geheimnis keine Rolle. Die SICCT-Authentisierung findet auf der Ebene des Anwendungsprotokolls statt und ist – aus Sicht des Protokollstapels – oberhalb des TLS-Protokolls. ST-Anwendungshinweis 16 Unterpunkt (5) bezieht sich auf die Anforderung TIP1-A_4516 in der Konnektor-Spezifikation, in der die Authentisierungsverfahren für Clientsystem beschrieben sind. FIA_UAU.5.2/AK Die in [BSI-CC-PP-0098, Abschnitt 6.3.2] formulierten Sicherheits- anforderungen gelten ohne Anpassung. FIA_API.1/AK Authentication Proof of Identity FIA_API.1.1/AK Die in [BSI-CC-PP-0098, Abschnitt 6.3.2] formulierten Sicherheits- anforderungen gelten ohne Anpassung. FIA_API.1/AK.TLS Authentication Proof of Identity / TLS FIA_API.1.1/TLS The TSF shall provide a TLS authentication mechanism using AK.AUT certificate70 to prove the identity of the TOE71. ST-Anwendungshinweis 17 Eigenes SFR hinzugefügt auf Basis der Anforderung GS-A_4384. 69 Refinement: Ergänzt gemäß Anforderungen aus TIP1-A_4516, vgl. Anhang D 70 Assignment: authentication mechanism 71 Assignment: identity or role 70 6.3.3. Klasse FDP: Schutz der Benutzerdaten Die in den FDP_ACC/FDP_ACF-Anforderungen verwendeten Dienste-Bezeichnungen sind nur eine Ori- entierung und keine verbindlichen Dienste. Diese SFR stellen keine Anforderungen an die Architektur des TOE. Die Subjekte aus den SFR sind beispielhaft zu verstehen und dienen zum besseren Verständ- nis der funktionalen Anforderungen. Sie können je nach Umsetzung angepasst (z. B. zusammengefasst oder interpretiert) werden. Diese Annahme gilt für alle im Folgenden beschriebenen SFR. Durch die Modellierung der Subjekte und Objekte im Schutzprofil besteht zumindest die Interpre- tationsmöglichkeit, dass das Schutzprofil Architekturblöcke definiert. Die Architektur des vorliegen- den TOE fasst im Schutzprofil definierte Subjekte und Objekte zusammen, sodass in der vorliegenden Implementierung die geforderten Abgrenzungen zwischen den Diensten per Konvention durchgesetzt werden. 6.3.3.1. Zugriffskontrolldienst FDP_ACC.1/AK.Infomod Subset access control / Informationsmodell FDP_ACC.1.1/AK.Infomod Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.1] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1/AK.Infomod Security attribute based access control / Informationsmodell FDP_ACF.1.1/AK.Infomod Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.1] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1.2/AK.Infomod Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.1] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1.3/AK.Infomod Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.1] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1.4/AK.Infomod Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.1] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FMT_MSA.1/AK.Infomod Management of security attributes / Informationsmodell FMT_MSA.1.1/AK.Infomod Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.1] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FMT_MSA.3/AK.Infomod Static attribute initialization / Informationsmodell FMT_MSA.3.1/AK.Infomod The TSF shall enforce the Infomodell-SFP to provide no72 default values for security attributes that are used to enforce the SFP. 72 Selection: selection, choose one of: restrictive, permissive, [assignment: other property] 71 FMT_MSA.3.2/AK.Infomod The TSF shall allow the no role73 to specify alternative initial values to override the default values when an object or information is created. ST-Anwendungshinweis 18 Es gibt keine vom Administrator überschreibbaren Konfigurations- werte. Folglich gibt es auch keine alternativen Anfangswerte. Die An- forderung ist implizit erfüllt. 6.3.3.2. Kartenterminaldienst FDP_ACC.1/AK.eHKT Subset access control / Kartenterminaldienst FDP_ACC.1.1/AK.eHKT Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.2] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1/AK.eHKT Security attribute based access control / Kartenterminaldienst FDP_ACF.1.1/AK.eHKT Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.2] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1.2/AK.eHKT Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.2] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1.3/AK.eHKT Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.2] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 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. (2) The subject S_Kartenterminaldienst must not send SICCT or EHEALTH-Commands to a card terminal for which CT.CON- NECTED=Nein is set, with the exception of the commands listed in TAB_KON_785 [gemSpec_Kon].74 ST-Anwendungshinweis 19 Die zusätzliche Regel in FDP_ACF.1.4/AK.eHKT(2) greift die Anforde- rung TIP1-A_6478 der Konnektor-Spezifikation auf. 73 Selection: S_Administrator, no role 74 Assignment: additional rules, based on security attributes, that explicitly deny access of subjects to objects 72 FDP_UCT.1/AK.TLS Basic data exchange confidentiality FDP_UCT.1.1/AK.TLS Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.2] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_UIT.1/AK.TLS Basic data exchange integrity FDP_UIT.1.1/AK.TLS Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.2] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_UIT.1.2/AK.TLS Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.2] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FMT_MTD.1/AK.eHKT_Abf Management of TSF data / eHealth-Kartenterminal Abfrage FMT_MTD.1.1/AK.eHKT_Abf Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.2] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FMT_MTD.1/AK.eHKT_Mod Management of TSF data / eHealth-Kartenterminal Modifikation FMT_MTD.1.1/AK.eHKT_Mod Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.2] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 6.3.3.3. Chipkartendienst FDP_ACC.1/AK.KD Subset access control / Chipkartendienst FDP_ACC.1.1/AK.KD Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.3] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1/AK.KD Security attribute based access control / Chipkartendienst FDP_ACF.1.1/AK.KD Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.3] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1.2/AK.KD Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.3] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. ST-Anwendungshinweis 20 Die Anforderung aus FDP_ACF.1.2/AK.KD(1) muss in Bezug auf das Caching der Daten präzisiert werden: Alle zwischengespeicherten Daten, die über das Kartenhandle mit der Karte assoziiert werden, werden – sofern die Karte noch nicht ent- fernt wurde – nach 24 Stunden gelöscht und neu erzeugt. Für eGK, HBAx gilt zusätzlich, dass die existierenden Kartensitzungen gelöscht werden (vgl. auch TIP1-A_4558, bzw. TIP1-A_6031.) 73 FDP_ACF.1.3/AK.KD Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.3] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 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/AK.KD erlaubt, auf private und symmetrische Schlüssel der Chipkarten mit den Chipkartenkommandos MANAGE CHANNEL, MANAGE SECURITY ENVI- RONMENT, 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) No further rule.75 FDP_ACC.1/AK.PIN Subset access control / PIN FDP_ACC.1.1/AK.PIN Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.3] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1/AK.PIN Security attribute based access control / PIN FDP_ACF.1.1/AK.PIN Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.3] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1.2/AK.PIN Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.3] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1.3/AK.PIN The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none76. 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 DISABLE VERIFICATION REQUIREMENT, ENABLE VERIFICATION REQUIREMENT, VERIFY, RESET RETRY COUNTER, DISABLE VERIFICATION RE- QUIREMENT, ENABLE VERIFICATION REQUIRE- MENT oder CHANGE REFERENCE DATA absetzen. 75 Assignment: additional rules, based on security attributes, that explicitly deny access of subjects to objects 76 Assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects 74 (2) Kein Subjekt außer S_Fachmodul darf eine PIN-Eingabe zur PIN-Prüfung für eine eGK bei S_Chipkartendienst anfordern. (3) no further rule77. 6.3.3.4. Signaturdienst FIA_SOS.2/AK.Jobnummer TSF generation of secrets / Jobnummer FIA_SOS.2.1/AK.Jobnummer Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FIA_SOS.2.2/AK.Jobnummer Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACC.1/AK.Sgen Subset access control / Signaturerstellung FDP_ACC.1.1/AK.Sgen Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1/AK.Sgen Security attribute based access control / Signaturerstellung FDP_ACF.1.1/AK.Sgen Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1.2/AK.Sgen Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1.3/AK.Sgen The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none78. 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. 77 Assignment: additional rules, based on security attributes, that explicitly deny access of subjects to objects 78 Assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects 75 (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) keine weiteren Einschränkungen79 zugreifen. (5) no further rule80. FDP_ACC.1/AK.SigPr Subset access control / Signature verification FDP_ACC.1.1/AK.SigPr Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1/AK.SigPr Security attribute based access control / Signature verification FDP_ACF.1.1/AK.SigPr Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1.2/AK.SigPr Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1.3/AK.SigPr The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none81. FDP_ACF.1.4/AK.SigPr The TSF shall explicitly deny access of subjects to objects based on the following additional rules: no further rule82. 79 Assignment: weitere Signaturschlüssel externer Signaturchipkarten 80 Assignment: additional rules, based on security attributes, that explicitly deny access of subjects to objects 81 Assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects 82 Assignment: additional rules, based on security attributes, that explicitly deny access of subjects to objects 76 FDP_DAU.2/AK.QES Data Authentication with Identity of Guarantor / Qualifizierte elektronische Signatur 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 signed durch qualifi- zierte elektronische Signatur gemäß gültiger Signaturrichtlinie mit Hilfe der qualifizierten Signaturerstellungseinheit (QSEE) zur Erzeugung der digitalen Signatur. Es sind die Dokumen- tenformate zu signierender Daten (1) Text-Dateien (UTF-8 [Unicode] oder ISO-8859-15 [ISO 8859-15]), (2) TIFF-Dateien [TIFF], (3) Adobe Portable Document Format (PDF/A) [ISO 19005; ISO 19005-1], (4) XML-Dateien [XML; XSLT] und die Formate signierter Daten (1) PAdES [PAdES; PAdES-BL] für PDF/A-Dokumente, (2) CAdES [CAdES; CAdES-BL] für XML, PDF/A, Text und TIFF Dokumente, (3) XAdES [XAdES; XAdES-BL] für XML-Dokumente mit den Signaturvarianten (1) enveloped signature, (2) enveloping signature, (3) detached signature83 zu unterstützen. ST-Anwendungshinweis 21 Anwendungshinweis 160 des Schutzprofils eröffnet dem Hersteller die Möglichkeit, auch detached signatures zu verwenden, falls ein Fachmodul dies erfordert. Das Fachmodul NFDM (OPB 2.1) benö- tigt eine solche Signatur. Der TOE stellt diese bereit. Die Möglich- keit der detached signature gilt ausschließlich im Kontext von XML- Signaturen. ST-Anwendungshinweis 22 Die Konnektorspezifikation schränkt die Kombinationsmöglichkeiten von Dokumentformaten, Signaturformaten und Signaturvarianten in TAB_KON_778 deutlich ein. Der TOE folgt der Konnektorspezifikation und setzt die Kombinationsmöglichkeiten entsprechend TAB_KON_778 um. 83 Refinement: vgl. ST-Anwendungshinweis 21 77 FDP_DAU.2.2/AK.QES The TSF shall provide S_Benutzern 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 Si- gnatur in den in FDP_DAU.2.1/AK.QES genannten Formaten sowie PKCS#1 RSASSA-PSS und RSASSA-PKCS1-v.5 [RFC 8017] Dies sind im einzelnen: (1) ob die signierten Daten unverändert sind, d. h. das Ergeb- nis 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 an- gegebenen Zeitpunkt, a. der angenommene Signaturerstellungszeitpunkt, wo- bei 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. none84, 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 Zertifikats mit Ausnahme des Wurzelzertifikats, d. die Anforderung von OCSP-Anfragen und die Aus- wertung von OSCP-Antworten, ob das nachgeprüfte qualifizierte Signaturzertifikat im jeweiligen Zertifi- katsverzeichnis zum angegebenen Zeitpunkt vorhan- den und nicht gesperrt war. (5) Für jedes Ergebnis der Korrektheitsprüfung einer digita- len 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, 84 Selection: none, qualifizierter Zeitstempel über die Signatur 78 b. die für Erstellung der Signatur verwendeten krypto- graphischen Algorithmen und Parameter zum ange- geben Signaturerstellungszeitpunkt geeignet waren, wenn dies nicht der Fall ist, liegt keine qualifizierte elektronische Signatur vor; c. die für die Erstellung der Signatur verwendeten kryp- tographischen Algorithmen und Parameter zum Si- gnaturprüfzeitpunkt geeignet sind; wenn dies nicht der Fall ist, ist eine Information zum verminderten Beweiswert der qualifizierte elektronischen Signatur zurückzugeben. (6) keine weiteren Nachweise85. FDP_DAU.2/AK.Sig Data Authentication with Identity of Guarantor / NonQES FDP_DAU.2.1/AK.Sig Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. ST-Anwendungshinweis 23 Die Konnektorspezifikation schränkt die Kombinationsmöglichkeiten von Dokumentformaten, Signaturformaten und Signaturvarianten in TAB_KON_778 deutlich ein. Der TOE folgt der Konnektorspezifikation und setzt die Kombinationsmöglichkeiten entsprechend TAB_KON_778 um. FDP_DAU.2.2/AK.Sig The TSF shall provide S_Benutzern with the ability to verify evi- dence 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/AK.Sig genannten Formaten sowie PKCS#1 RSASSA-PSS und RSASSA-PKCS1- v.5 [RFC 8017] gemäß gültiger Signaturrichtlinie bereitstellen. Dies sind im einzelnen: (1) ob die signierten Daten unverändert sind, d. h. das Ergeb- nis 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 Auswer- tung von OSCP-Antworten, (6) keine weiteren Nachweise86. 85 Assignment: andere Form von Nachweisen 86 Assignment: andere Form von Nachweisen 79 FDP_DAU.2/AK.Cert Data Authentication with Identity of Guarantor / Überprüfung von Zertifikaten FDP_DAU.2.1/AK.Cert Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_DAU.2.2/AK.Cert The TSF shall provide S_Benutzern 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 ge- nerated 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, (4) die Gültigkeit der Zertifikate zum angegebenen Zeit- punkt, (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 Auswer- tung von OSCP-Antworten, (9) die Anforderung von CRL-Anfragen und die Auswertung von CRL, (10) keine weiteren Nachweise.87 FDP_ITC.2/AK.Sig Import of user data / Signaturdienst FDP_ITC.2.1/AK.Sig Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ITC.2.2/AK.Sig Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ITC.2.3/AK.Sig Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ITC.2.4/AK.Sig Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ITC.2.5/AK.Sig Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 87 Assignment: andere Form von Nachweisen 80 FMT_MSA.3/AK.Sig Static attribute initialization / Signatur FMT_MSA.3.1/AK.Sig Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FMT_MSA.3.2/AK.Sig Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. ST-Anwendungshinweis 24 Es gibt keine vom Administrator überschreibbaren Konfigurations- werte. Folglich gibt es auch keine alternativen Anfangswerte. Die An- forderung ist implizit erfüllt. FDP_SDI.2/AK Stored data integrity monitoring and action FDP_SDI.2.1/AK The TSF shall monitor user data zu signierende Daten stored in containers controlled by the TSF for Veränderung on all objects, ba- sed on the following attributes: SHA-256 hash of the data88. 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) keine weiteren Aktionen ausführen.89 FMT_MSA.1/AK.User Management of security attributes / Clientsystem-Benutzer FMT_MSA.1.1/AK.User Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. ST-Anwendungshinweis 25 Da der Begriff Signaturrichtlinie im PP abstrakt alle Input- Parameter einer Signaturerstellung oder -prüfung umfasst, wird FMT_MSA.1.1/AK.User(2) dahingehend interpretiert, dass die Auswahl von Parametern durch den Benutzer des Clientsystems durchge- führt wird, vgl. auch die Beschreibung zu SF.SignatureService in Ab- schnitt 7.2.7. FTP_ITC.1/AK.QSEE Inter-TSF trusted channel / QSEE FTP_ITC.1.1/AK.QSEE Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 88 Assignment: user data attributes 89 Assignment: weitere auszuführende Aktion 81 FTP_ITC.1.2/AK.QSEE Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FTP_ITC.1.3/AK.QSEE Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. ST-Anwendungshinweis 26 FTP_ITC.1.3/AK.QSEE bezieht sich auf die Stapelsignatur. Für eine Ein- fachsignatur ist die Nutzung von Secure Messaging nicht erforderlich (vgl. [gemSpec_Kon, TIP1-A_4670]. FTA_TAB.1/AK.Jobnummer TOE access warning / Jobnummer FTA_TAB.1.1/AK.Jobnummer Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FTA_TAB.1/AK.SP TOE access warning / Fehler des Signaturprozesses FTA_TAB.1.1/AK.SP Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.4] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. ST-Anwendungshinweis 27 Die Kommunikation zwischen TOE und S_Benutzer_Clientsystem erfolgt über SOAP-Nachrichten und deren Interpretation durch die Benutzerschnittstelle des Clientsystemems. Der TOE hat selbst kei- ne visuelle Benutzerschnittstelle zum Subjekt S_Benutzer_Clientsys- tem, über die die Warnung ausgegeben werden kann. Folglich wird das Refinement so interpretiert, dass die geforderte advisory warning message über die Antwort zum SOAP-Request übermittelt wird. 6.3.3.5. Software-Update FDP_ACC.1/AK.Update Subset access control / Update FDP_ACC.1.1/AK.Update Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.5] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1/AK.Update Security attribute based access control / Update FDP_ACF.1.1/AK.Update Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.5] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1.2/AK.Update Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.5] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 82 FDP_ACF.1.3/AK.Update The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none90. 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. (3) Wenn ein Update-Paket mit FWPriority=Kritisch vorhanden ist, dessen Deadline abgelaufen ist, so darf die TSF kei- ne Kommunikation mit der TI Plattform herstellen und muss bestehende Verbindungen zur TI Plattform abbau- en.91 ST-Anwendungshinweis 28 Der TOE unterstützt die automatische Anwendung von Update- Paketen nicht. ST-Anwendungshinweis 29 TIP1-A_6025 wird umgesetzt durch Unterpunkt FDP_ACF.1.1/AK.Up- date(3). FDP_UIT.1/AK.Update Data exchange integrity / Update FDP_UIT.1.1/AK.Update Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.5] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_UIT.1.2/AK.Update Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.5] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 6.3.3.6. Verschlüsselungsdienst FDP_ACC.1/AK.Enc Subset access control / Verschlüsselung FDP_ACC.1.1/AK.Enc Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.6] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 90 Assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects 91 Refinement: Ergänzt gemäß Anforderungen aus TIP1-A_6025, vgl. Anhang D 83 FDP_ACF.1/AK.Enc Security attribute based access control / Verschlüsselung FDP_ACF.1.1/AK.Enc Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.6] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 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: (1) Das Subjekt S_AK muss zu verschlüsselnde Daten an das Subjekt S_Verschlüsselungsdienst mit der Objekt-ID, der Identität der Verschlüsselungsrichtlinie und der Identität der vorgeschlagenen Empfängern übergeben. Der Verschlüsselungsdienst darf Requests zur Verschlüs- selung nur akzeptieren, wenn sie konform zur gema- tik Spezifikation sind, vgl. [gemSpec_Kon, TAB_KON_739, TUC_KON_070].92 (2) Das Subjekt S_Verschlüsselungsdienst darf nur ordnungsgemäß verschlüsselte Daten oder Statusmeldungen an das Subjekt S_AK zurückgeben. (3) Das Subjekt S_Verschlüsselungsdienst darf nur dann die zu verschlüsselnden Daten für die identifizierten vorgeschlagenen Empfänger automatisch verschlüsseln, wenn 1. die identifizierte Verschlüsselungsrichtlinie für die übergebenen zu verschlüsselnden Daten zulässig ist, 2. die identifizierte Verschlüsselungsrichtlinie die automatische Verschlüsselung erlaubt, 3. die Verschlüsselungszertifikate der vorgeschlagenen Empfänger gültig sind. (4) Das Subjekt S_AK darf zu entschlüsselnde Daten an das Subjekt S_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 übergeben. Der Verschlüsselungsdienst darf Requests zur Entschlüs- selung nur akzeptieren, wenn sie konform zur Gema- tik Spezifikation sind, vgl. [gemSpec_Kon, TAB_KON_140 TUC_KON_071].93 (5) Das Subjekt S_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 92 Refinement: vgl. ST-Anwendungshinweis 30 93 Refinement: vgl. ST-Anwendungshinweis 30 84 1. die identifizierte Verschlüsselungsrichtlinie für die übergebenen zu verschlüsselten Daten zulässig ist, 2. die identifizierte Verschlüsselungsrichtlinie die automatische Entschlüsselung erlaubt, 3. der Sicherheitsstatus der Chipkarte des identifizierten vorgesehenen Empfängers das Entschlüsseln des Dateischlüssels erlaubt. FDP_ACF.1.3/AK.Enc The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none94. FDP_ACF.1.4/AK.Enc The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none95. ST-Anwendungshinweis 30 Der Begriff „Verschlüsselungsrichtlinie“ muss interpretiert werden. Im PP wird der Begriff im Glossar definiert. Er umfasst im wesent- lichen das Verschlüsselungsformat (CMS oder XMLSec), den Her- ausgeber der Verschlüsselungsrichtlinie und – im Fall von XMLSec – das XML-Schema und die Information, ob der Schlüssel im Do- kument steht. Die gematik Spezifikation verwendet den Begriff der Verschlüsselungsrichtlinie nicht, definiert aber dei Aufrufparameter für die Operationen EncryptDocument und DecryptDocument. Die ge- matik Spezifikation ist damit deutlich präziser als das Schutzprofil. Daher gilt für dieses Security Target die folgende Interpretation. Die Forderung nach einer zulässigen Verschlüsselungsrichtlinie wird so interpretiert, dass die gegebene Kombination von Aufrufparame- tern im Rahmen des spezifizierten Regelwerkes als gültig bewertet wird. Für den TOE werden die Vorgaben der Konnektor Spezifi- kation als Regelwerk angenommen. Die Eingangsdaten der TUCs TUC_KON_070 und TUC_KON_071 liefern sehr präzise Vorgaben für die Parameter. Die Interpretation gilt nicht nur hier, sondern auch für al- le weiteren Vorkommen von „Verschlüsselungsrichtlinie“ in diesem Security Target. Weiterhin legt die Formulierung „Identität der Verschlüsselungsricht- linie“ nahe, dass es eine Sammlung benannter (und damit referenzier- barer) Verschlüsselungsrichtlinien gibt. Das ist ein historisches Re- likt, das sich aus der gematik Spezifikation nicht herleiten lässt und im vorliegenden TOE nicht umgesetzt ist. FDP_ITC.2/AK.Enc Import of user data with security attributes / Verschlüsselungsdienst FDP_ITC.2.1/AK.Enc Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.6] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 94 Assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects 95 Assignment: rules, based on security attributes, that explicitly deny access of subjects to objects 85 FDP_ITC.2.2/AK.Enc Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.6] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ITC.2.3/AK.Enc Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.6] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ITC.2.4/AK.Enc Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.6] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ITC.2.5/AK.Enc Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.6] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. ST-Anwendungshinweis 31 Die Anforderung FDP_ITC.2.5/AK.Enc(2) wird so interpretiert, dass die Prüfung der Gültigkeit der Verschlüsselungszertifikate vor deren Ver- wendung zur Verschlüsselung eines Dokuments erfolgen muss. FDP_ETC.2/AK.Enc Export of user data with security attributes / Verschlüsselungsdienst FDP_ETC.2.1/AK.Enc Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.6] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ETC.2.2/AK.Enc Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.6] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ETC.2.3/AK.Enc Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.6] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 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) No further rules96. ST-Anwendungshinweis 32 Die Anforderung FDP_ETC.2.4/AK.Enc(2) wird so interpretiert, dass die entschlüsselten Daten ausschließlich an den vorgesehenen Empfän- ger ausgeliefert werden. Die Identität des Empfängers manifestiert sich nicht in der Datenstruktur der Ausgabe der Operation. Die Spe- zifikation der gematik gibt ein solches Identifizierungsmerkmal nicht 96 Assignment: additional exportation control rules 86 her97. In der vorliegenden Implementierung werden die entschlüs- selten Daten in genau der HTTP-Response übertragen, die zu dem Request gehört, über den die zu entschlüsselnden Daten in den TOE importiert wurden. Damit ist die eindeutige Zuordnung des Empfän- gers gewährleistet. 6.3.3.7. TLS-Kanäle FDP_ACC.1/AK.TLS Subset access control / TLS-Kanäle FDP_ACC.1.1/AK.TLS Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.7] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. ST-Anwendungshinweis 33 Der Begriff „TLSConnectionIdentifier“ wird hier ausschließlich als Maßnahme zur Unterscheidung verschiedener TLS-Verbindungen betrachtet. Diese Maßnahme wird nicht notwendigerweise durch ein Sicherheitsattribut umgesetzt. Im TOE wird die Separation der TLS- Verbindungen durch Socket-Abstracktionen und die darauf basie- renden Objektreferenzen umgesetzt, die vom Framework JSSE im- plementiert werden. Die Objektreferenzen sind als private gekenn- zeichnet oder lokale Variablen, sind also nur innerhalb des aktuellen Threads erreichbar. Weiterhin setzt der TOE kein Subjekt S_TLS_Dienst um. Die Gematik-Spezifikation [gemSpec_Kon] sieht keinen zentralen Dienst für das Erstellen, die Verwaltung oder den Abbau von TLS- Verbindungen vor. FDP_ACF.1/AK.TLS Security attribute based access control / TLS-Kanäle FDP_ACF.1.1/AK.TLS Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.7] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 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) einen TLS-Kanal zum Clientsystem auf. 97 TAB_KON_140 definiert als „Ausgangsdaten“ des TUC_KON_071 „Daten hybrid entschlüsseln“ lediglich: „plainDocument (Un- verschlüsseltes Dokument. Bei XML-Dokumenten: Das EncryptedData-Element ist durch das entschlüsselte ersetzt.)“ Die Ausgangsdaten des TUC sehen die Übergabe der Identität des Empfängers nicht vor. 87 (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 eine SessionID des Intermediär VSDM empfangen und dem TLSConnectionIdentifier zuordnen. Das S_AK darf auf Anforderung des VSDM-Fachmoduls die un- terbrochene Sitzung des TLS-Kanals zum Intermediär VSDM mit der 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_LOG- ICAL_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_LOG- ICAL_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 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 einen TLS-Kanal zum TSL-Dienst auf. (12) Keine weiteren Regeln98 FDP_ACF.1.3/AK.TLS The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none99. 98 Assignment: additional rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects 99 Assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects 88 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) no further rules100 FMT_MSA.1/AK.TLS Management of security attributes / TLS-Kanäle FMT_MSA.1.1/AK.TLS The TSF shall enforce the AK-TLS-SFP to restrict the ability to change_default, query, modify, delete, none101 the security attribu- tes Authentisierungsmechanismus102 to S_Administrator. Änderungen der Konfiguration müssen unmittelbar durchge- setzt werden. ST-Anwendungshinweis 34 Die Konnektor-Spezifikation definiert in TAB_KON_852 zu TIP1-A_5009 die Zugriffsregeln, die sich aus den Kombinationen der Konfigurati- onswerte ergeben. Das Assignment „Authentisierungsmechanismus“ schließt diese Konfigurationswerte ein. FMT_MSA.3/AK.TLS Static attribute initialization / TLS-Kanäle FMT_MSA.3.1/AK.TLS The TSF shall enforce the AK-TLS-SFP to provide unmodifiable103 default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2/AK.TLS Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.7] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 100 Assignment: additional rules, based on security attributes, that explicitly deny access of subjects to objects 101 Assignment: other operations 102 Assignment: Authentisierungsmechanismus, list of additional security attributes 103 Selection: choose one of: restrictive, permissive, [assignment: other property] 89 ST-Anwendungshinweis 35 Es gibt keine vom Administrator konfigurierbaren Anfangswerte für TLS-Verbindungen. Alle Konfigurationswerte für TLS Verbindun- gen sind durch [gemSpec_Krypt] vorgegeben und hart verdrahtet, vgl. die Darstellungen in Anhang B. Somit ist die Anforderung FMT_MSA.3.2/AK.TLS implizit erfüllt. FTP_ITC.1/AK.FD Inter-TSF trusted channel / Zum Fachdienst 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 identifica- tion of S_Fachdienst mit dem Zertifikat C.FD.TLS-S mit dem Sperrstatus (OCSP) „good“104 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 Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.7] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FTP_ITC.1.3/AK.FD Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.7] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. ST-Anwendungshinweis 36 „Fachdienst“ beinhaltet in diesem Zusammenhang auch den Inter- mediär, da der TOE keine unmittelbare Verbindung zum Fachdienst aufbaut. ST-Anwendungshinweis 37 TIP1-A_7254 wird umgesetzt durch das Refinement in FTP_ITC.1.1/AK.FD. FTP_ITC.1/AK.VZD Inter-TSF trusted channel / Zum zentralen Verzeichnisdienst 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 lo- gically distinct from other communication channels and provides as- sured identification of S_Verzeichnisdienst (VZD) mit dem Zer- tifikat C.ZD.TLS-S mit dem Sperrstatus (OCSP) „good“105 ge- genüber dem EVG its end points and protection of the channel data from modification and or disclosure. FTP_ITC.1.2/AK.VZD Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.7] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 104 Refinement: Vgl. ST-Anwendungshinweis 37 105 Refinement: Vgl. ST-Anwendungshinweis 37 90 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“ ST-Anwendungshinweis 38 TIP1-A_7254 wird umgesetzt durch das Refinement in FTP_ITC.1.1/AK.VZD. FTP_ITC.1/AK.KSR Inter-TSF trusted channel / Zum KSR (Update-Server) FTP_ITC.1.1/AK.KSR Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.7] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FTP_ITC.1.2/AK.KSR Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.7] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FTP_ITC.1.3/AK.KSR Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.7] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FTP_ITC.1/AK.TSL Inter-TSF trusted channel / Zum TSL-Dienst FTP_ITC.1.1/AK.TSL Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.7] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FTP_ITC.1.2/AK.TSL Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.7] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FTP_ITC.1.3/AK.TSL Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.7] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FTP_ITC.1/AK.CS Inter-TSF trusted channel / Clientsystem FTP_ITC.1.1/AK.CS Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.7] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FTP_ITC.1.2/AK.CS Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.7] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FTP_ITC.1.3/AK.CS Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.7] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 91 FTP_ITC.1/AK.eHKT Inter-TSF trusted channel / eHKT FTP_ITC.1.1/AK.eHKT Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.7] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FTP_ITC.1.2/AK.eHKT Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.7] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FTP_ITC.1.3/AK.eHKT Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.7] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 6.3.3.8. Sicherer Datenspeicher FDP_ACC.1/AK.SDS Subset access control / Sicherer Datenspeicher FDP_ACC.1.1/AK.SDS Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.8] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1/AK.SDS Security attribute based access control / Sicherer Datenspeicher FDP_ACF.1.1/AK.SDS Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.8] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 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, (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 Sicherheitsattribut „Administratorobjekt“ darf nur innerhalb einer Administratorsitzung entschlüsselt und gelesen und verschlüsselt und geschrieben werden, aber nicht außerhalb der Administratorsitzung gespeichert werden, (5) Keine weiteren Regeln106. 106 Assignment: additional rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects 92 ST-Anwendungshinweis 39 TIP1-A_5484 wird umgesetzt durch Unterpunkt FDP_ACF.1.1/AK.SDS(3) in Kombination mit KoCoBox MED+ OPB 2.1 Konnektor [KoCo AGD_Kon-Sec, Abschnitt 3.4]. FDP_ACF.1.3/AK.SDS The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none107. 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 Sicherheitsattribut „Adminstratorobjekt“ weder lesen noch entschlüsseln. (2) Das S_AK darf keine Datenobjekte des SDS mit dem Sicherheitsattribut „Adminstratorobjekt“ speichern oder modifizieren. (3) none108. ST-Anwendungshinweis 40 Das Schutzprofil fordert die Modellierung eines Sicherheitsattributs zur Abgrenzung „allgemeiner Datenobjekte“ (die vom Anwendungs- konnektor gelesen/geschrieben werden dürfen) und „Administrator- objekte“ (die nur im Kontext einer „Administratorsitzung“ gelesen/- geschrieben werden dürfen). Die KoCoBox MED+ setzt dieses Kon- zept so um, dass ausschließlich „allgemeine Datenobjekte“ existieren. Folglich gibt es kein Sicherheitsattribut, um Datenobjekte voneinan- der abzugrenzen. Auch Konfigurationsdaten, die im Rahmen einer Administratorsitzung geschrieben werden, gelten als „allgemeine Da- tenobjekte“. Hintergrund dafür ist die in FDP_ACF.1.4/AK.SDS(1) formulierte Zu- griffsregel. Diese verbietet dem Anwendungskonnektor explizit, „Ad- ministratorobjekte“ zu lesen. Die Dienste, die die Konfiguration an- wenden müssen, sind jedoch Teil des Anwendungskonnektors, unter- liegen also den Modellierungsregeln für S_AK und dürfen folglich die Daten gar nicht anwenden. Der TOE ließe sich nicht ohne einen angemeldeten Administrator starten. Anwendungshinweis 188 des Schutzprofils fordert eine Darstellung, wie der Inhalt des sicheren Datenspeichers bei ausgeschaltetem Kon- nektor geschützt wird und wie die Initialisierung des sicheren Daten- speichers erfolgt. Der sichere Datenspeicher ist nach FCS_COP.1/Storage.AES transparent verschlüsselt und nach FCS_COP.1/Sign durch Signaturen in der Inte- grität geschützt. Siehe auch SF.SecureStorage und SF.CryptographicSer- vices/NK. 107 Assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects 108 Assignment: rules, based on security attributes, that explicitly deny access of subjects to objects 93 Das benötigte Schlüsselmaterial wird mit Hilfe der gSMC-K erzeugt oder ist auf der jeweils genutzten gSMC-K vorhanden. Der sichere Datenspeicher wird bei Erstinitiliasierung bereits in der Produktion durch den TOE eingerichtet. 6.3.3.9. Fachmodule FDP_ACC.1/AK.VSDM Subset access control / VSDM FDP_ACC.1.1/AK.VSDM Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.9] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FDP_ACF.1/AK.VSDM Security attribute based access control / VSDM FDP_ACF.1.1/AK.VSDM Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.9] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 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 den 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) Keine weiteren Regeln.109 FDP_ACF.1.3/AK.VSDM The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: None110. FDP_ACF.1.4/AK.VSDM The TSF shall explicitly deny access of subjects to objects based on the following additional rules: None111. 109 Assignment: additional rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects 110 Assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects 111 Assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects 94 FMT_MSA.1/AK.VSDM Management of security attributes / VSDM FMT_MSA.1.1/AK.VSDM The TSF shall enforce the VSDM-SFP to restrict the ability to no operation112 the security attributes none113 to S_Administrator. ST-Anwendungshinweis 41 Das PP definiert für das Subjekt S_VSDM_Fachmodul lediglich die Identität – also den eindeutigen Namen des Fachmoduls – als Sicher- heitsattribut (vgl. [BSI-CC-PP-0098, Tabelle 12]). Neben der Iden- tität werden keine weiteren Sicherheitsattribute für das Fachmodul VSDM definiert, die durch einen Administrator geändert werden kön- nen. Daher werden hier keine Operationen und keine Sicherheitsat- tribute operationalisiert. FMT_MSA.3/AK.VSDM Static attribute initialization / VSDM FMT_MSA.3.1/AK.VSDM Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.9] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. FMT_MSA.3.2/AK.VSDM Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.9] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. ST-Anwendungshinweis 42 Es gibt keine vom Administrator änderbaren Konfigurationswerte. Folglich können keine alternativen Anfangswerte definiert werden. Somit ist die Anforderung implizit erfüllt. 6.3.3.10. Übergreifende Sicherheitsanforderungen FMT_MSA.4/AK Security attribute value inheritance FMT_MSA.4.1/AK Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.10] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. ST-Anwendungshinweis 43 Zur Interpretation des Begriffs „Verschlüsselungsrichtlinie“ vgl. ST- Anwendungshinweis 30 auf Seite 85. FDP_RIP.1/AK Subset residual information protection FDP_RIP.1.1/AK Die in [BSI-CC-PP-0098, Abschnitt 6.3.3.10] formulierten Sicher- heitsanforderungen gelten ohne Anpassung. 112 Selection: create, change_default, query, modify, delete, [assignment: other operations] 113 Assignment: list of security attributes 95 6.3.4. Klasse FMT: Sicherheitsmanagement FMT_SMR.1/AK Security roles FMT_SMR.1.1/AK Die in [BSI-CC-PP-0098, Abschnitt 6.3.4] formulierten Sicherheits- anforderungen gelten ohne Anpassung. FMT_SMR.1.2/AK Die in [BSI-CC-PP-0098, Abschnitt 6.3.4] formulierten Sicherheits- anforderungen gelten ohne Anpassung. FMT_SMF.1/AK Specification of Management Functions FMT_SMF.1.1/AK Die in [BSI-CC-PP-0098, Abschnitt 6.3.4] formulierten Sicherheits- anforderungen gelten ohne Anpassung. FMT_MOF.1/AK Management of security functions behaviour FMT_MOF.1.1/AK Die in [BSI-CC-PP-0098, Abschnitt 6.3.4] formulierten Sicherheits- anforderungen gelten ohne Anpassung. ST-Anwendungshinweis 44 Die gematik Spezifikation sieht die Betriebseigenschaft MGM_LOGI- CAL_SEPARATION nicht länger vor [gemSpec_Kon]. Die logische Tren- nung ist nicht im TOE implementiert ist. Daher ist es nicht möglich, die Auswahl „logische Trennung“ zu aktivieren. FMT_MTD.1/AK.Admin Management of TSF data / Administration FMT_MTD.1.1/AK.Admin The TSF shall restrict the ability to (1) set, query, modify and delete the roles from other users, (2) set, modify and delete the authentication credentials for administrators, (3) set and modify the Arbeitsplatzkonfiguration with assigned Clientsystem and eHealth-Kartenterminals, (4) set and modify the Zeitpunkten und Gültigkeitsdauer der Prüfungsergebnisse zur Gültigkeit qualifizierter Zertifikate für die Erzeugung ordnungsgemäßer qualifizierten elektronischen Signaturen, (5) change_default of the gültigen Signaturrichtlinie für automatische Signaturerzeugung, (6) change_default of the gültigen Signaturrichtlinie für automatische Signaturprüfung, 96 (7) modify the configuration parameter to activate or deactivate the automatic installation of software updates, (8) import the update data for Karten-Terminals and execute the update, (9) configure the loggable system events, (10) export and import the configuration data of the TOE, (11) set and modify the maximum lifetime of OCSP cache entries, (12) set and modify the keys of the sicheren Datenspeichers, (13) set and import and export the X.509 certificates of Clientsystemen, (14) reset to factory settings of the all TSF data (factory reset), (15) import the CA certificates of an encryption PKI, (16) query the version information of Fachmodule, (17) modify the connection parameters of Clientsysteme, (18) query the available smart cards of types eGK and HBA, (19) query the expiry date of certificates on smart cards of ty- pes eGK and HBA, (20) modify the PIN management parameters of SMC-B to administrator. ST-Anwendungshinweis 45 FMT_MTD.1.1/AK.Admin(5), (6) kommt in der Architektur des vorlie- genden TOE nicht zum Tragen, vgl. FMT_MSA.3/AK.Sig. ST-Anwendungshinweis 46 Der TOE unterstützt die automatische Anwendung von Update- Paketen nicht. ST-Anwendungshinweis 47 FMT_MTD.1.1/AK.Admin(12): Die Schlüssel des sicheren Datenspei- chers werden beim ersten Start des Geräts – noch in der Fertigungs- straße – erzeugt und können ausschließlich im Rahmen des Werksre- sets neu generiert werden. Der TOE stellt kein Schlüsselzugriffsinter- face bereit. Ein Werksreset wiederum kann nur vom Administrator ausgelöst werden. Somit ist (12) durch (14) implizit erfüllt. ST-Anwendungshinweis 48 TIP1-A_7255 wird von FMT_MTD.1.1/AK.Admin(16) umgesetzt. 97 FMT_MTD.1/AK.Zert Management of TSF data / Zertifikatsmanagement FMT_MTD.1.1/AK.Zert Die in [BSI-CC-PP-0098, Abschnitt 6.3.4] formulierten Sicherheits- anforderungen gelten ohne Anpassung. ST-Anwendungshinweis 49 (1) Der TOE löscht keine öffentlichen Schlüssel der CVC Root CA auf der gSMC-K. Der TOE initiiert die Übernahme öf- fentlicher Schlüssel der CVC Root CA aus übergebenen Cross- CV-Zertifikaten durch die gSMC-K. Wenn der für die CA-Zertifikatsprüfung zu selektierende CVC-Root-Key auf der gSMC-K nicht vorhanden ist, wer- den mit dem Kartenkommando PSO VERIFY CERTIFI- CATE ausgewählte Cross-CV-Zertifikate zur Prüfung an die gSMC-K gesendet. Dadurch wird jeweils der im Cross- CV-Zertifikat enthaltene öffentliche CVC-Root-Key an die gSMC-K übertragen. Die gSMC-K verwaltet den erforderli- chen Speicherplatz auf der Karte selbst und entfernt „unwich- tige“ Einträge falls die Menge an importierten Schlüsseln die Kapazität der Karte übersteigt. (2) Im TOE erfolgt ein Import, aber keine permanente Speiche- rung der öffentlichen Schlüssel der CVC Root CA. Die Schlüs- sel werden nur temporär im Rahmen der Zertifikatsprüfung verwendet. 6.3.5. Klasse FPT: Schutz der TSF FPT_TDC.1/AK Inter-TSF basic TSF data consistency FPT_TDC.1.1/AK The TSF shall provide the capability to consistently interpret (1) Zertifikaten für die Prüfung qualifizierter elektronischer Signaturen, (2) nicht-qualifizierter X.509-Signaturzertifikaten, (3) X.509-Verschlüsselungszertifikaten, (4) CV-Zertifikate, (5) Trust-service Status Listen, (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) Signaturrichtlinie114 114 Selection: Signaturrichtlinie, Verschlüsselungsrichtlinie 98 when shared between the TSF and another trusted IT product. ST-Anwendungshinweis 50 TIP1-A_5482 wird umgesetzt durch Unterpunkt FPT_TDC.1.1/AK(4). 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. (3) Die Gültigkeit der X.509-Signaturzertifikate der SMC-B gemäß [gemSpec_SMC-B_ObjSys] 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äß [BSI-CC-PP-0082-2] 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. (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 und CRL darf nur durch eine gültige TSL verteilt werden. (9) für Signaturrichtlinie die Kette der Signaturen bis zu einer be- kannten Wurzelinstanz und die Vereinbarkeit mit den Regeln für qualifizierte elektronische Signaturen prüfen115. 115 Selection: für Signaturrichtlinie die Kette der Signaturen bis zu einem bekannten Vertrauensanker und die Vereinbarkeit mit den Regeln für qualifizierte elektronische Signaturen prüfen, für Verschlüsselungsrichtlinie die Kette der Signaturen bis zu einem bekannten Vertrauensanker und die Zulässigkeit prüfen, weitere einschränkende Regeln für nicht-qualifizierte elektronische Signaturen 99 (10) Falls bei einer Zertifikatsprüfung OCSP-Abfragen ver- wendet werden, muss die Festlegung zeitlicher Toleran- zen in einer OCSP-Response, definiert in GS-A_5215 [gem- Spec_PKI, Abschnitt 9.1.2.2], bei der Interpretation ver- wendet werden.116 when interpreting the TSF data from another trusted IT product. FPT_FLS.1/AK Failure with preservation of secure state FPT_FLS.1.1/AK The TSF shall preserve a secure state according to [gemSpec_Kon, TAB_KON_504] when the following types of failures occur: (1) according to [gemSpec_Kon, TAB_KON_503] with type „SEC“ and severity „fatal“. (2) Keine weiteren Fehlerarten117 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. FPT_TEE.1/AK Testing of external entities FPT_TEE.1.1/AK Die in [BSI-CC-PP-0098, Abschnitt 6.3.5] formulierten Sicherheits- anforderungen gelten ohne Anpassung. 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, und der geforderten Rolle 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 die unbekannte Karte kennzeichnen und weitere Aktionen mit dieser Karte verbieten118. 116 Refinement: Anforderung aus GS-A_5215 in Anhang D 117 Assignment: list of additional types of failures in the TSF 118 Assignment: action for unknown smart cards 100 FPT_TST.1/AK.Run-time TSF testing / Normalbetrieb FPT_TST.1.1/AK.Run-time The TSF shall run a suite of self tests beim Anlauf und regelmäßig während des Normalbetriebs to demonstrate the correct operation of stored TSF executable code119. FPT_TST.1.2/AK.Run-time The TSF shall provide authorised users with the capability to verify the integrity of stored TSF configuration data120. FPT_TST.1.3/AK.Run-time The TSF shall provide authorised users with the capability to verify the integrity of stored TSF executable code121. ST-Anwendungshinweis 51 Die Sicherheitsanforderung FPT_TST.1 existiert bereits in einer Itera- tion für den Netzkonnektor, vgl. FPT_TST.1/NK. FPT_TST.1/AK.Out-Of-Band TSF testing / Out-Of-Band FPT_TST.1.1/AK.Out-Of-Band Die in [BSI-CC-PP-0098, Abschnitt 6.3.5] formulierten Sicherheits- anforderungen gelten ohne Anpassung. FPT_TST.1.2/AK.Out-Of-Band Die in [BSI-CC-PP-0098, Abschnitt 6.3.5] formulierten Sicherheits- anforderungen gelten ohne Anpassung. 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 the whole TSF122. FPT_STM.1/AK Reliable time stamps FPT_STM.1.1/AK Die in [BSI-CC-PP-0098, Abschnitt 6.3.5] formulierten Sicherheits- anforderungen gelten ohne Anpassung. 6.3.6. Klasse FAU: Sicherheitsprotokollierung FAU_GEN.1/AK Audit data generation 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 Anwen- dungskonnektors; 119 Assignment: parts of TSF 120 Assignment: parts of TSF data 121 Assignment: parts of TSF 122 Assignment: parts of TSF mit gespeichertem ausführbarem TSF-Code 101 b) All auditable events for the not specified123 level of audit; and c) The following specified security-relevant auditable events: • Power on / Shut down (einschließlich der Art der ausge- lösten Aktion, z. B. Reboot) des Anwendungskonnektors, • Durchführung von Softwareupdates einschließlich nicht erfolgreicher Versuche des Anwendungskonnektors, • Zeitpunkt von Änderungen der Konfigurationseinstel- lungen 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, • Ereignisse vom Typ „Sec“ der Fachmodule124. 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 further information125. ST-Anwendungshinweis 52 Anwendungshinweis 203 des Schutzprofils bildet die Brücke zu TIP1- A_4710. Diese Anforderung bestimmt, dass keine persönlichen oder medizinischen Daten protokolliert werden dürfen. Der Anwendungshinweis wird um die Nennung von „Schlüsselmate- rial“ verfeinert, um die Anforderung VSDM-A_2789 zu erfüllen: FAU_GEN.1/AK beschreibt die Protokollfunktionen des An- wendungskonnektors in Ergänzung zu FAU_GEN.1/NK.Se- cLog. Die Protokoll-Daten dürfen keine personenbezo- genen oder medizinischen Daten oder Schlüsselmateri- al enthalten. Zum Nachweis dieser Anforderung für die Produktzulassung sind alle möglichen Protokoll-Einträge zu dokumentieren. Die Spezifikation Konnektor [gem- Spec_Kon] gibt im Anhang F eine Übersicht der Ereignis- se (Events), wobei nur die Beschreibungen der Ereignisse für die jeweiligen Technischen Anwendungsfülle (TUC) verbindlich sind. 123 Selection: choose one of: minimum, basic, detailed, not specified 124 Assignment: additional events 125 Assignment: other audit relevant information 102 FAU_SAR.1/AK Audit review FAU_SAR.1.1/AK The TSF shall provide administrators126 with the capability to read the system log and the security log127 from the audit records. FAU_SAR.1.2/AK Die in [BSI-CC-PP-0098, Abschnitt 6.3.6] formulierten Sicherheits- anforderungen gelten ohne Anpassung. FAU_STG.1/AK Protected audit trail storage Hierarchical to: No other components Dependencies: FAU_GEN.1 fulfilled in this Security Target by FAU_GEN.1/NK.SecLog FAU_STG.1.1/AK Die in [BSI-CC-PP-0098, Abschnitt 6.3.6] formulierten Sicherheits- anforderungen gelten ohne Anpassung. FAU_STG.1.2/AK Die in [BSI-CC-PP-0098, Abschnitt 6.3.6] formulierten Sicherheits- anforderungen gelten ohne Anpassung. FAU_STG.4/AK Prevention of audit data loss Hierarchical to: FAU_STG.3 Dependencies: FAU_STG.1 fulfilled in this Security Target by FAU_STG.1/AK FAU_STG.4.1/AK The TSF shall overwrite the oldest stored audit records and take no further action128 if the audit trail is full. The TOE reserves memory in the non-volatile NAND flash for the event log. If the size of the log exceeds 80% of the reserved memory, the TOE shall inform the administrator via the display. ST-Anwendungshinweis 53 Das Überschreiben des ältesten Log-Eintrags aus dem PP- Assignment wird durch die Konfigurationsparameter LOG_DAYS (für den Basiskonnektor) und FM__LOG_DAYS (für Fachmodule) gesteuert. Die Parameter geben an, nach wievielen Tagen Logein- träge frühestens überschrieben werden können. Sollte die diese Grenze an Tagen noch nicht erreicht sein und das Protokoll trotzdem voll sein, werden die ältesten Einträge gelöscht und der Konnektor wird spezifikationskonform in den Fehlerzustand EC_LOG_OVERFLOW versetzt. 126 Assignment: authorised users 127 Assignment: list of audit information 128 Assignment: other actions to be taken in case of audit storage failure 103 6.4. Sicherheitsanforderungen an die Vertrauenswürdigkeit des EVG Die Sicherheitsanforderungen an die Vertrauenswürdigkeit für dieses Security Target entsprechen de- nen, die in [BSI-CC-PP-0097] und [BSI-CC-PP-0098] definiert sind. 6.4.1. Verfeinerung zur Vertrauenswürdigkeitskomponente ADV_ARC.1 Die Verfeinerungen in [BSI-CC-PP-0098; BSI-CC-PP-0097] gelten ohne Anpassung. 6.4.2. Verfeinerung zur Vertrauenswürdigkeitskomponente AGD_OPE.1 Die Verfeinerungen in [BSI-CC-PP-0098; BSI-CC-PP-0097] gelten ohne Anpassung. 6.4.3. Verfeinerung zur Vertrauenswürdigkeitskomponente ALC_DEL.1 Die Verfeinerungen in [BSI-CC-PP-0098; BSI-CC-PP-0097] gelten ohne Anpassung. 6.4.4. Verfeinerung zur Vertrauenswürdigkeitskomponente AGD_PRE.1 Die Verfeinerungen in [BSI-CC-PP-0098; BSI-CC-PP-0097] gelten ohne Anpassung. 6.4.5. Verfeinerung für die Integration der Fachmodule NFDM und AMTS Der Konnektor berherbergt die Fachmodule NFDM und AMTS, die nicht im Rahmen der CC- Zertifizierung betrachtet, sondern nach Technischen Richtlinien zertifziert werden. Dennoch haben diese Fachmodule Auswirkungen auf den Gesamtkonnektor, indem Sie Forderungen an Eigenschaften des Konnektors stellen. Der zertifizierte Konnektor muss diese Eigenschaften aufweisen. Um sicherzu- stellen, dass die Zertifizierung des Konnektors diese Eigenschaften berücksichtigt, gelten die folgende Verfeinerungen. ASE_TSS wird wie folgt verfeinert: Der Konnektor unterstützt die Fachmodule NFDM und AMTS. In den Technischen Richtlinien TR-03154 [TR-03154] und TR-03155 [TR-03155], Kapitel 3.3.2 werden Anforderungen an den Konnektor gestellt, die im Rahmen der CC-Zertifizierung berücksichtigt werden müssen. Die für die Fachmodule NFDM und AMTS relevan- ten 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] und TR-03155 [TR-03155], Kapitel 3.3.2 relevanten Sicherheitseigen- schaften des Konnektors umsetzt. Der Evaluator muss prüfen, ob die nach [TR-03154] und TR-03155 [TR-03155], Ka- pitel 3.3.2 relevanten Sicherheitseigenschaften des Konnektors vollständig im Secu- rity Target berücksichtigt sind. ADV_FSP wird wie folgt verfeinert: 104 Der Konnektor unterstützt die Fachmodule NFDM und AMTS. In den Technischen Richtlinien TR-03154 [TR-03154] und TR-03155 [TR-03155], Kapitel 3.3.2 werden Anforderungen an den Konnektor gestellt, die im Rahmen der CC-Zertifizierung berücksichtigt werden müssen. Die dabei von den Fachmodulen aufgerufenen Schnittstellen des Anwendungskonnektors müssen beschrieben werden. Der Hersteller muss eine Beschreibung der Schnittstellen des Anwendungskonnek- tors bereitstellen, an denen die relevanten Sicherheitseigenschaften des Konnektors umgesetzt werden. Der Evaluator muss die Beschreibung der Schnittstellen des Anwendungskonnek- tors, an denen die relevanten Sicherheitseigenschaften des Konnektors umgesetzt werden auf Vollständigkeit hinsichtlich der Vorgaben in den Technischen Richtli- nien 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 gefor- dert. ADV_TDS wird wie folgt verfeinert: Der Konnektor unterstützt die Fachmodule NFDM und AMTS. In den Technischen Richtlinien TR-03154 [TR-03154] und TR-03155 [TR-03155], Kapitel 3.3.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 siche- re und korrekte Umsetzung der relevanten Sicherheitseigenschaften zu prüfen. Der Evaluator muss die sichere und korrekte Umsetzung der relevanten Sicherheits- eigenschaften 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 6.5. Erklärung der Sicherheitsanforderungen 6.5.1. Erklärung der Abhängigkeiten der SFR des Netzkonnektors Die Abhängigkeiten der in Abschnitt 6.2 aufgestellten funktionalen Sicherheitsanforderungen sind er- füllt. Es gelten dieselben Auflösungen von Abhängigkeiten, wie sie im Schutzprofil [BSI-CC-PP-0097, Abschnitt 6.4.2] beschrieben sind. Die Abhängigkeiten der aus dem Schutzprofil des Gesamtkonnektors [BSI-CC-PP-0098] übernom- menen Sicherheitsanforderungen sind dem Schutzprofil zu entnehmen. Die Abhängigkeiten der über die Schutzprofile hinaus aufgenommenen Sicherheitsanforderungen sind bei der Definition des jeweiligen SFR notiert. Die zusätzlich aufgenommenen SFR sind Iterationen bestehender Komponenten, sodass sich durch diese keine neuen Abhängigkeiten ergeben. Die in Abschnitt 5.1 neu eingeführte Komponente FCS_RNG.1 hat keine Abhängigkeiten, die aufgelöst werden müssen. 105 6.5.2. Überblick der Abdeckung von Sicherheitszielen des Netzkonnektors Die Zuordnung von Sicherheitszielen zu Sicherheitsanforderungen entspricht weitestgehend der Zuord- nung, die in [BSI-CC-PP-0098; BSI-CC-PP-0097] getroffen wurde. Die in diesem Security Target neu hinzugefügten Sicherheitsziele werden ebenfalls auf die Sicher- heitsanforderungen abgebildet. Gleiches gilt für die neu eingeführten Sicherheitsanforderungen, die den Sicherheitszielen zugeordnet werden müssen. Tabelle 6.3 auf Seite 108 ordnet diese neuen Abbildun- gen in den Kontext der im Schutzprofil vorgenommenen Zuordnungen ein. Dabei ist die Legende aus Tabelle A.1 (auf Seite 146) zu verwenden. Die Einführung der zusätzlichen Sicherheitsanforderungen wird wie folgt begründet: FCS_COP.1/Sign wurde hinzugefügt, um die Algorithmen des TOE zur Signaturerstellung und - verifikation zu repräsentieren. Die Algorithmen tragen dazu bei, die Schutzziele O.NK.Schutz, O.NK.EVG_Authenticity und O.NK.VPN_Auth zu erfüllen, indem sie für die Prüfung der Integrität von Hashes, der Integrität der TSL/CRL und der VPN-Vertrauensanker herangezogen werden. FCS_COP.1/Storage.AES helfen, die Benutzerdaten und den TOE selbst zu schützen, wie von O.NK.Schutz vorgesehen. FCS_RNG.1/Hash_DRBG trägt dazu bei, dass beim TLS-Verbindungsaufbau sichere Zufallszahlen ver- wendet werden. Dadurch wird das Schutzziel O.NK.TLS_Krypto erfüllt. 6.5.3. Detaillierte Erklärung für die Sicherheitsziele des Netzkonnektors Die detaillierte Erklärung der Sicherheitsziele des Netzkonnektors wird unverändert aus [BSI-CC-PP- 0098; BSI-CC-PP-0097] übernommen. 106 O.NK.TLS_Krypto O.NK.Schutz O.NK.EVG_Authenticity O.NK.Admin_EVG O.NK.Protokoll O.NK.Zeitdienst 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 . FMT_MTD.1/NK . . . X . . . . . . . . . FIA_UID.1/NK.SMR . . . X . . . . . . . . . FTP_TRP.1/NK.Admin X . . X . . . . . . . . . FMT_SMF.1/NK X . . X . . . . . . X X . FMT_MSA.1/NK.PF . . . X . . . . . . X X . FMT_MSA.4/NK . . . 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 . . . . . . . . . . . . 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 . . . . . . . . . . . . Abbildung der Sicherheitsziele des NK auf Sicherheitsanforderungen 107 O.NK.TLS_Krypto O.NK.Schutz O.NK.EVG_Authenticity O.NK.Admin_EVG O.NK.Protokoll O.NK.Zeitdienst 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 FDP_ACF.1/AK.TLS X . . . . . . . . . . . . FCS_RNG.1/Hash_DRBG X . . . . . . . . . . . . FCS_COP.1/Storage.AES . X . . . . . . . . . . . FCS_COP.1/Sign . X X . . . X . . . . . . Tabelle 6.3.: Abbildung der Sicherheitsziele des NK auf Sicherheitsanforderungen 6.5.4. Erklärung der Abhängigkeiten der SFR des Anwendungskonnektors Die Abhängigkeiten der in Abschnitt 6.3 aufgestellten funktionalen Sicherheitsanforderungen sind er- füllt. Es gelten dieselben Auflösungen von Abhängigkeiten, wie sie im Schutzprofil [BSI-CC-PP-0098, Abschnitt 6.5.2] beschrieben sind. 6.5.5. Überblick der Abdeckung von Sicherheitszielen des Anwendungskonnektors Die Zuordnung von Sicherheitszielen zu Sicherheitsanforderungen des Anwendungskonnektors ent- spricht der Zuordnung, die im Schutzprofil getroffen wurde [BSI-CC-PP-0098, Abschnitt 6.5.4]. 6.5.6. Detaillierte Erklärung für die Sicherheitsziele des Anwendungskonnektors Die detaillierte Erklärung der Sicherheitsziele des Anwendungskonnektors wird unverändert aus [BSI- CC-PP-0098] übernommen. 6.6. Erklärung für Erweiterung der Sicherheitsanforderungen FCS_RNG.1/Hash_DRBG Die Sicherheitsanforderung FCS_RNG.1/Hash_DRBG wurde eingeführt, um die Anforderungen der eben- falls eingeführten Komponente FCS_RNG.1 zu präzisieren. Die Erklärung für die Einführung der Familie FCS_RNG in Abschnitt 5.1 gilt auch für das resultierende SFR FCS_RNG.1/Hash_DRBG. Die Sicherheits- anforderung erfüllt das Sicherheitsziel O.NK.TLS_Krypto, vgl. auch Abschnitt 6.5.1. FIA_API.1/AK.TLS Die Sicherheitsanforderung FIA_API.1/AK.TLS wurde eingeführt, um die Anforderung gs-a_4384 zu er- füllen, die fordert, dass der Konnektor sich mit einem X.509 Zertifikat identifizieren muss, wenn er Server in einer TLS-Verbindung ist. Die Sicherheitsanforderung erfüllt das Sicherheitsziel O.AK.LAN. 108 FIA_SOS.1/AK.CS.Passwörter Die Sicherheitsanforderung FIA_SOS.1/AK.CS.Passwörter wurde eingeführt, da die Qualitätsmetriken für Passwörter an der Clientsystemschnittstelle unterschiedlich sind und sich FIA_SOS.1/AK.Passwörter ex- plizit auf die Passwörter an der Managementschnittstelle bezieht. Die Sicherheitsanforderung erfüllt das Sicherheitsziel O.AK.LAN. 6.7. Erklärung für die gewählte EAL-Stufe Die Erklärung der gewählten EAL-Stufe wird unverändert aus dem Schutzprofil [BSI-CC-PP-0098] übernommen. 109 7. ASE_TSS: Basiskonnektor Dieses Kapitel vermittelt einen Überblick über die IT-Sicherheitsfunktionen des TOE, wie sie in der funktionalen Spezifikation beschrieben sind. Es enthält Beschreibungen der allgemeinen technischen Verfahren, die der TOE anwendet, um die Sicherheitsanforderungen zu erfüllen. Das Kapitel ist gegliedert in Funktionen, die vom Netzkonnektor (Abschnitt 7.1) und Funktionen, die vom Anwendungskonnektor erbracht werden. Der Abschnitt über die Funktionen des Netzkonnektors ist dessen Security Target [KoCo ASE_ST-97] entnommen. Die beiden Abschnitte 7.3 und 7.4 zeigen tabellarisch die Zusammenhänge zwischen den Sicherheits- funktionen des TOE und den Sicherheitsanforderungen, die dieses Security Target in den Abschnitten 6.2 (für den Netzkonnektor) und 6.3 (für den Anwendungskonnektor) aufstellt. Auch hier sind die NK-spezifischen Angaben aus dem Security Target des NK übernommen. Dieses Kapitel beschreibt die Funktionalität des Basiskonnektors. Das Folgekapitel setzt ASE_TSS fort, indem die Anforderungen der Fachmodule an den TOE beschrieben werden und aufgelistet wird, wie der TOE diese Anforderungen erfüllt. Das Folgekapitel gehört somit formal zum zu prüfenden Umfang des Security Targets. 7.1. TOE Sicherheitsfunktionen des Netzkonnektors 7.1.1. VPN-Client (SF.VPN) Die Sicherheitsfunktion SF.VPN erstellt sichere Kommunikationskanäle zwischen dem TOE und einem entfernten, vertrauenswürdigen IT-Produkt. Dazu wird eine IKEv2 Implementierung verwendet. Diese Kanäle sind logisch von anderen Kommunikationskanälen separiert. Sie bieten gesicherte Identifizie- rung der Endpunkte und Schutz der über den Kanal übertragenen Daten vor Manipulation und Preis- gabe. Solche Kanäle werden vom Konnektor für Verbindungen in die Telematikinfrastruktur und zum SIS verwendet. Der TOE verwendet die Identität auf der gSMC-K#1, um sich gegnüber den entfernten VPN-Konzentratoren zu authentisieren. Umgesetzte SFR FTP_ITC.1/NK.VPN_SIS FTP_ITC.1/NK.VPN_TI Zertifikate werden sowohl mathematisch geprüft, als auch gegen eine TSL und eine CRL geprüft. Die Signaturen der TSL und der CRL werden ebenfalls vom TOE geprüft. Beide Listen werden alle 24 Stunden über einen HTTP-Download aktualisiert. Darüberhinaus verfolgt der TOE die Ablaufdaten kryptographischer Algorithmen. Wenn die Al- gorithmen ablaufen, wird der TOE seine Operation einstellen und nicht mehr funktional sein. Die Ablaufdaten und die Algorithmen sind ausschließlich über Software-Updates möglich. Die vorliegende Implementierung unterstützt IPsec, wie von [gemSpec_Kon] gefordert: IKEv2 [RFC 7296] ohne herstellerspezifische Erweiterungen und Main Mode Exchange wird verwendet. NAT Traversierung wird unterstützt. 110 Umgesetzte SFR FPT_TDC.1/NK.Zert Wenn der TOE konfiguriert ist, sich mit der Telematikinfrastruktur zu verbinden, wird dise Ver- bindung automatisch aufgebaut, wenn dies technisch möglich ist (d.h. wenn der VPN-Konzentrator erreicht werden kann). Im Fehlerfall werden erneute Versuche verzögert, um nicht das Sicherheitspro- tokoll mit Einträgen zu fluten. Wenn der TOE nicht für eine automatische Verbindung mit der Tele- matikinfrastruktur konfiguriert ist, wird keine Verbindung aufgebaut. Der Auf- und der Abbau einer VPN-Verbindung wird im Sicherheitslog protokolliert. Um die zentrale Telematikinfrastruktur vor Angriffen zu schützen, ist die Kommunikation über den VPN-Kanal spezifischen Komponenten vorbehalten (durch SF.DynamicPacketFilter). Die einzigen Kom- ponenten, denen der Datentransfer in die TI gestattet ist, sind der Anwendungskonnektor, Fachdienste, Clientsysteme und Dienste für Namensauflösung (DNS), Zeitabgleich (NTP) und der Download von TSL, CRL und BNetzAVL. 7.1.2. Dynamischer Paketfilter (SF.DynamicPacketFilter) Die Sicherheitsfunktion SF.DynamicPacketFilter stellt eine Firewall (regelbasierten, dynamischen Paket- filter) für Netzwerkverbindungen über die LAN- und WAN-Schnittstellen des Konnektors zur Verfü- gung. Die Firewall kann über Regeln konfiguriert werden, die Pakete filtern. Filterkriterien sind: • IP Adressen (Quelle und Ziel), • Portnummern (Quelle und Ziel), • Protokolltypen, • physische Schnittstellen (Quelle oder Ziel), • die Netzwerkschnittstellen für Eintritt und Austritt der Daten (LAN, WAN, VPN), • Verbindungsstatus Umgesetzte SFR FDP_IFC.1/NK.PF FDP_IFF.1/NK.PF Das Standard-Regelset ist so gestaltet, dass es maximalen Schutz bietet. Dazu werden nur notwendi- ge Verbindungen erlaubt. Um absichtliches und unabsichtliches Untergraben der TOE Sicherheitsmaß- nahmen zu verhindern, dürfen ausschließlich Administratoren Firewallregeln hinzufügen. Auch hier sind die Möglichkeiten stark eingeschränkt. Der Administrator darf lediglich solche Regeln hinzufü- gen, die Kommunikation zwischen dem LAN und dem WAN erlauben. Es ist nicht möglich, Regeln einzuführen, die explizite Verbotsregeln des Standard-Regelsets aufheben. Die vom Administrator ein- gegebenen Regeln werden nach den Regeln des Standard-Regelsets bewertet. Neue Regeln werden über die Schnittstelle zum Anwendungskonnektor gesetzt. Umgesetzte SFR FMT_MSA.3/NK.PF FDP_IFC.1/NK.PF 111 Es ist möglich einen von zwei Betriebsmodi auszuwählen, für die unterschiedliche Regelsets definiert sind: Serieller/Gateway Modus Der Konnektor wird zwischen dem lokalen Netzwerk und dem Internet-Gateway installiert. Der Zugang zum Internet wird in diesem Fall über das WAN- Interface PS.WAN bereitgestellt (ANLW_ANBINDUNGS_MODUS = InReihe). Paralleler Modus Der Konnektor wird gemeinsam mit dem Internet-Gateway, den Clientsystemen und anderen Geräten als Teil des lokalen Netzwerks installiert. Der Zugang zum Internet wird in diesem Fall über das LAN-Interface PS.LAN bereit gestellt. Das WAN-Interface bleibt in diesem Fall ungenutzt (ANLW_ANBINDUNGS_MODUS = Parallel). Darüber hinaus kann der Administrator auswählen, ob. bzw. wie den Clientsystemen der Zugang zum Internet ermöglicht werden soll. Es stehen drei Möglichkeiten zur Verfügung: SIS Verkehr aus dem LAN wird über VPN SIS ins Internet geleitet (ANLW_INTERNET_MODUS = SIS) IAG Verkehr aus dem LAN wird über das Internet Access Gateway ins Internet geleitet. Bedingt, dass der serielle/Gateway Modus aktiv ist (ANLW_INTERNET_MODUS = IAG). Keiner Verkehr aus dem LAN wird nicht ins Internet geleitet (ANLW_INTERNET_MODUS = Keiner). Die vordefinierten Sets an Filterregeln können nicht modifiziert oder entfernt werden, außer wenn die Policies durch ein Firmware-Update in den Konnektor eingebracht werden. Umgesetzte SFR FMT_MSA.1/NK.PF Die vordefinierten Regelsets setzen die Anforderungen der Konnektor-Spezifikation um [gem- Spec_Kon, Abschnitt 4.2.1.1.2]. Explizit erlaubt sind alle Verbindungen, von denen die Spezifikation fordert, dass der Konnektor sie erlauben muss. Explizit verboten sind alle Verbindungen, von denen die Spezifikation fordert, dass der Konnektor sie unterbinden muss. Die Firewall-Regeln stellen sicher, dass nur die Protokolle IPv4, ICMP (Netzwerkebene), TCP, UDP, ESP (Transportebene) für die Kommunikation mit der Telematikinfrastruktur erlaubt sind. Die Routing-Tabellen des TOE stellen sicher, dass ausgehender Verkehr nur über LS.VPN_TI in die TI geleitet wird, wenn die Zieladresse Teil eines Subnetzes der TI oder Teil eines Bestandsnetzes ist. Jeglicher anderer Verkehr wird über LS.VPN_SIS, bzw. LS.LAN geleitet. Der dynamische Paketfilter erlaubt dem TOE ebenfalls, Netzwerkpakete zu identifizieren, die weder zu einer bereits aufegebauten, noch zu einer im Aufbau befindlichen Verbindung gehören. Solche nicht- wohlgeformeten Pakete werden verworfen. Der TOE führt Buch über den Status aller seiner Netzwerkverbindungen, sowie über deren relevante Informationen. Dafür setzt der TOE den Netfilter des Linux Kernels ein. 112 Das Hoch- und Herunterfahren des Paketfilters wird im Audit-Log des Konnektors protokolliert. Ebenso werden Informationen protokolliert, die für Basic Intrusion Prevention benötigt werden. Vor- sichtsmaßnahmen sind implementiert, um zu verhindern, dass das Audit-Log mit speziell gefertigten Nachrichten geflutet wird. So könnte ein Angreifer versuchen, wichtige Nachrichten im Log zu über- schreiben. Umgesetzte SFR FDP_IFF.1/NK.PF 7.1.3. Netzbasierte Sicherheitsfunktionen (SF.NetworkServices) Die Sicherheitsfunktion SF.NetworkServices stellt dem TOE zuverlässige Zeitstempel zur Verfügung. Eine Referenzzeit wird über den VPN-Kanal von einem vertrauenswürdigen NTP-Server in der Tele- matikinfrastruktur bezogen. Dabei wird NTP in Version 4 verwendet [RFC 5905]. Die Abweichung zwischen der Netzwerkzeit und der lokalen Zeit im TOE darf maximal 1 Stunde betragen. Der TOE verwendet die Uhrzeit hauptsächlich, um die Gültigkeit von Zertifikaten zu prüfen und um Protokoll- einträge mit Zeitstempel schreiben zu können. Die Synchronisation der Zeit mit dem NTP-Server findet nach dem Boot-Vorgang kontinuierlich statt. Die Intervalle zwischen den Synchronisationsabrufen be- tragen zwischen 64 und 1024 Sekunden, wie im NTP-Protokoll vorgesehen. Umgesetzte SFR FPT_STM.1/NK Alle Anwendungen im TOE können über SF.NetworkServices die aktuelle Zeit erfragen. Der TOE stellt die Uhrzeit auch über seinen Zeitdienst an der Schnittstelle LS.LAN zur Verfügung (ebenfalls mit NTPv4). Cliensysteme und andere Nutzer im LAN des Leistungserbringers können den Zeitdienst verwenden. Der TOE bietet weitere Netzwerkdienste für die Clientsysteme im LAN an: • DHCP Server für die Konfiguration von Systemen mit IP-Adressen und Netzwerkparametern • DNS Server für die Namensauflösung 7.1.4. Selbstschutz (SF.SelfProtection/NK) Die Sicherheitsfunktion SF.SelfProtection/NK ist dafür verantwortlich, den TOE und die Daten, die er verarbeitet, vor Angriffen und Manipulation zu schützen. Sensible Daten werden aus dem Arbeitsspeicher gelöscht, sobald sie nicht mehr verwendet werden. Das umfasst kryptographische Schlüssel, Session Keys, kurzlebige Schlüssel während des Ver- und Entschlüsselungsvorgangs, aber auch sensible Benutzerddaten. Das Löschen wird durch aktives Über- schreiben der entsprechenden Speicherbereiche mit einer Konstante oder pseudo-zufälligen Werten umgesetzt. Umgesetzte SFR FCS_CKM.4/NK FDP_RIP.1/NK 113 Der TOE kann eine Reihe von Selbsttests ausführen, um seine Integrität und die Funktionsfähigkeit seiner eigenen Sicherheitsfunktionen und Komponenten zu beweisen. Abhängig von deren Ausprägung werden die Selbsttests entweder beim Systemstart, während des normalen Betriebs oder zu beiden Ge- legenheiten ausgeführt. Der Administrator kann die Selbsttests ebenfalls starten. Folgende Selbsttests sind umgesetzt: • Prüfung auf Integrität des sicheren Datenspeichers • Prüfung auf Integrität des ausführbaren Codes der TOE Sicherheitsfunktionen. Der sichere Datenspeicher speichert die Konfiguration des TOE in einem verschlüsselten Dateisys- tem. Die Integrität des sicheren Datenspeichers wird sichergestellt, indem für jede Datei des Datei- systems ein SHA-256 Hash berechnet, signiert und separat abgespeichert wird. Für die Signatur wird ein privater Schlüssel der gSMC-K verwendet. Beim Systemstart werden alle Hashwerte neu berechnet und mit den abgespeicherten Werten verglichen. Zusätzlich werden die Pfade und Namen aller Daten- und Signaturdateien in einem Journal abgelegt. Das Journal selbst wird ebenfalls signiert und mit ei- ner Signaturdatei ergänzt. Die Signaturdateien für die Datendateien stellen sicher, das die Datendateien nicht manipuliert worden sind; das Journal stellt sicher, dass keine Daten entfernt oder hinzugefügt wor- den sind. Die Prüfung der Integrität der TSF kann ebenfalls vom Administrator durchgeführt werden. Weiterhin testet der TOE seine Integrität alle 24 Stunden selbst. ST-Anwendungshinweis 6 erweitert die Prüfung, sodass nicht nur ausführbare Dateien getestet werden, sondern auch alle anderen Teil der Firmware. Die Integrität des Root-Dateisystems im NAND-Flash (Teil der TSF) wird sichergestellt, indem ein einzelner SHA-512 Hash über einer Hash-Datenbank verglichen wird. Die Hash-Datenbank wird beim Systemstart erstellt und enthält die Dateinamen und Hashes aller Daten im Root-Dateisystem. Wenn der Hash über der erstellten Datenbank mit einem abgespeicherten und signierten Hash übereinstimmt, gilt der Test als erfolgreich. Der Referenz-Hash wird mit einem dedizierten privaten Schlüssel signiert, der aus der PKI des Herstellers stammt. Die Signatur wird mit dem passenden öffentlichen Schlüssel mittels RSASSA-PSS verifiziert. Der Test wird während des Systemstarts und im laufenden Betrieb ausgeführt. Schlägt der Test während des Systemstarts fehl, bricht der TOE den Systemstart ab und hält an. Im Normalbetrieb führt der fehlschlagende Test dazu, dass der TOE seinen Dienst bis auf bestimmte Administrationsfunktionen einstellt. Die Tests werden von Skripten ausgeführt, die zweimal im System vorhanden sind: Für die Tests während des Systemstarts werden die Skripte aus dem Initramfs geladen, während des Normalbetriebs liegen sie im Root-Dateisystem. Die Integrität des Linux Kernels und des Initramfs (Teile der TSF) wird durch den Boot-Loader sichergestellt. Der TOE verifiziert eine RSASSA-PKCS1-1.5 Signatur und prüft, dass die SHA-256 Hashes für den Kernel und das Initramfs mit den signierten Hashes korrespondieren. Der öffentliche Schlüssel für die Signaturverifikation ist im Boot-Loader abgespeichert. Umgesetzte SFR FPT_TST.1/NK Der Boot-Loader (Teil der TSF) wird durch einen SHA-256 Hash und eine Signatur abgesichert, die vom SoC (Teil der Betriebsumgebung) verifiziert werden. Der öffentliche Schlüssel ist im Boot-Loader abgespeichert. Ein Hash des öffentlichen Schlüssels ist in einem einmalig beschreibbaren Speicherbe- reich des SoC gespeichert. Der Schlüssel wird im Produktionsprozess des Konnektors dort abgelegt. Dieser Hash wird ebenfalls verifiziert. 114 Für die Erstellung der Signaturen, die in den Integritätsprüfungen verwendet werden, setzt der TOE die gSMC-K ein. Die Operationen und logischen Eigenschaften des TOE sind so implementiert, dass sie Seitenkanal- attacken widerstehen. Der TOE stellt sicher, dass keine Informationen über die Netzwerkschnittstellen abfließen kann. Im Besonderen gilt dies für VPN-Sitzungsschlüssel, jegliches verwendete oder abge- speicherte Schlüsselmaterial und zu schützende Daten der TI und der Bestandsnetze. Der TOE verwendet SELinux Policys, um zusätzlichen, verpflichtenden Zugriffsschutz (mandatory access control, MAC) für Ressourcen wie Dateien, Verzeichnisse, Sockets und Geräte zu erzwingen. Der TOE nutzt zusätzlich Code aus dem linux-hardened Project, um das System weiter zu härten (Verfeinerung von ADV_ARC.1). Der TOE stellt sicher, dass der sichere Datenspeicher automatisch verschlüsselt wird (vgl. SF.Crypto- graphicServices/NK). Zusätzlich prüft der TOE permanent die Zeitabweichung von maximal 1 Stunde zur Netzwerkzeit (vgl. SF.NetworkServices). Umgesetzte SFR FPT_EMS.1/NK 7.1.5. Protokollierungsdienst/NK (SF.Audit/NK) Der TOE erzeugt Protokolleinträge für Ereignisse, die in FAU_GEN.1/NK.SecLog spezifiziert sind. Pro- tokolleinträge enthalten die folgenden Informationen: • Thema (Topic) des Ereignisses • Datum und Uhrzeit des Ereignisses • Art des Ereignisses • Schweregrad • Identität des auslösenden Subjekts (System oder die ID des korrespondierenden Fachmoduls) • Ausgang (Erfolg oder Fehler) des Ereignisses, falls relevant • Bei Konfigurationsänderungen: Benutzername des Administrators Umgesetzte SFR FAU_GEN.1/NK.SecLog FAU_GEN.2/NK.SecLog 7.1.6. Administration/NK (SF.Administration/NK) Die Sicherheitsfunktionen des TOE definieren eine Rolle „Administrator“. Benutzer greifen zur Ver- waltung des TOE über eine TLS-Verbindung auf den TOE zu und werden dabei vom Anwendungs- konnektor authentisiert. Die TLS-Verbindung wird von der Funktion SF.CryptographicServices/NK bereit gestellt. Ist ein Administrator authentisiert, ist er autorisiert, verschiedene TSF-Parameter zu konfigu- rieren und folgende TSF-bezogene Operationen durchzuführen: • Die Systemzeit/Echtzeituhr modifizieren 115 • Die Regeln des dynamischen Paketfilters anpassen (vgl. SF.DynamicPacketFilter und FMT_MSA.1/NK.PF) • Das Sicherheitsprotokoll abfragen • Die Selbsttests des Konnektors auslösen (vgl. SF.SelfProtection/NK) Es ist zu beachten, dass die Web-Anwendung in der Umgebung des Konnektors ausgeführt wird. Die Sicherheitsleistungen werden von der Schnittstelle LS.LAN.HTTP_MGMT erbracht, die den Authen- tisierungsstatus des Administrators prüft. Der TOE informiert den Administrator über kritische Betriebszustände über das Display an der Gehäusefront des Konnektors (PS.DISPLAY). Umgesetzte SFR FMT_SMR.1/NK FMT_MTD.1/NK FMT_SMF.1/NK FIA_UID.1/NK.SMR FTP_TRP.1/NK.Admin Administratoren müssen sich authentisieren, bevor sie die Konfigurationsdienste des TOE verwenden können. Die lokale Administration ist aus dem LAN des Leistungserbringers über die Schnittstelle LS.LAN.HTTP_MGMT erreichbar. Zu diesem Zweck verfügt der TOE über einen TLS-Server, der einsei- tige Authentisierung des Servers vorsieht. Nach dem Aufbau der TLS-Verbindung muss der Benutzer sich gegenüber der Web-Anwendung mit Benutzername und Passwort als Administrator authentisieren. Bei dieser Verbindung ist der TOE Server, der Browser des Administrators ist Client. Der TLS-Server des TOE unterstützt TLS 1.2. Umgesetzte SFR FMT_SMR.1/NK FIA_UID.1/NK.SMR FMT_MSA.4/NK FTP_TRP.1/NK.Admin Alle Aktionen, die über die Management-Anwendung durchgeführt werden (login, logout, Konfigu- rationsänderungen) werden im Sicherheitsprotokoll gespeichert. Diese Sicherheitsfunktion bietet eine Komponente, mit der die Firmware der KoCoBox MED+ – inklusive dem Bootloader – sicher aktualisiert werden kann. Mit Hilfe dieser Funktion werden alle Komponenten des Konnektors aktualisiert: sowohl der Netz- als auch der Anwendungskonnektor. Al- lerdings beschränkt sich die Sicherheitsfunktion auf das Prüfen und Aktualisieren der Firmware. Der Import der Firmware (Upload über die Management-Anwendung oder Download vom KSR-Server) wird nicht vom Netzkonnektor erbracht, sondern von Teilen des Anwendungskonnektors. 7.1.7. Kryptografische Dienste/NK (SF.CryptographicServices/NK) Die Sicherheitsfunktion SF.CryptographicServices/NK stellt Implementierungen verschiedener kryptogra- phischer Basisalgorithmen zur Verfügung, die von anderen Sicherheitsfunktionen des Konnektors ver- wendet werden können. 116 Zufallszahlen Der TOE enthält einen DRNG nach FCS_RNG.1/Hash_DRBG, um Zufallszahlen hoher Qualität zu er- zeugen. Der nach [NIST SP 800-90A] umgesetzte DRNG wird in regelmäßigen Abständen (alle 2.048 Zugriffe) mit 32 Bytes aus dem Zufallsgenerator der gSMC-K#2 initialisiert. Die so erzeug- ten Zufallszahlen werden für verschiedene Zwecke verwendet, u.a. beim TLS-Verbindungsaufbau (FCS_CKM.1/NK.TLS und FCS_COP.1/NK.TLS.AES) Umgesetzte SFR FCS_RNG.1/Hash_DRBG Hash-Algorithmen Die Funktion bietet Implementierungen für die Hash-Algorithmen SHA-1, SHA-256 und SHA-512. Im Kontext von TLS implementiert der TOE außerdem SHA-384 für bestimmte Cipher Suites. Umgesetzte SFR FCS_COP.1/NK.Hash, FCS_CKM.1/NK.TLS HMAC Generierung Die Funktion bietet darüber hinaus Algorithmen für die HMAC-Generierung, wobei die genannten Hash-Algorithmen zum Tragen kommen: HMAC-SHA-1(-96), HMAC-SHA-256(-128). Umgesetzte SFR FCS_COP.1/NK.HMAC, FCS_COP.1/NK.TLS.HMAC Signaturverifikation Die Sicherheitsfunktion SF.CryptographicServices/NK bietet Algorithmen zur Verifikation von Signa- turen. X.509-Zertifikate werden unter Verwendung des RSA-PKCS1-v1.5- bzw RSASSA-PSS- Algorithmus geprüft. Zur Verifikation der Signatur der BNetzA-VL muss aktuell noch das Schema RSA-PKCS1-v1.5 verwendet werden. Das Schema RSASSA-PSS wird auch zur Verifikation von Si- gnaturen der Software Updates, der TSL und der CRL verwendet. Zusätzlich werden damit die Hashes des sicheren Datenspeichers und die Integrität der TSF geprüft. Die Hashes des sicheren Datenspeichers wird nicht vom TOE signiert, sondern von der gSMC-K in der Betriebsumgebung des Konnektors. Die Generierung von Hashes und Zufallszahlen wird vom TOE durchgeführt. Umgesetzte SFR FCS_COP.1.1/NK.Auth IPsec Der TOE setzt das IPsec Protokoll um und verifiziert beim IKEv2 Schlüsselaustausch die Signaturen für die Authentisierung von VPN-Konzentratoren. Dabei wird RSA PKCS#1 1.5 verwendet. Während des Schlüsselaustausches wird mit dem Diffie- Hellman Verfahren ein gemeinsames Geheimnis etabliert [RFC 7296]. Auf der Basis des ausgehan- delten Geheimnisses wird mit PRF-HMAC-SHA-256 Schlüsselmaterial für den Integritätsschutz und Verschlüsselung während IKE und ESP generiert [RFC 7296, Abschnitt 2.14]. Der VPN-Verkehr wird mit ESP und den zuvor generierten Schlüsseln verschlüsselt. Die Integrität des VPN-Verkehrs wird über die Berechnung von HMACs mit dediziert generierten Schlüsseln sichergestellt. Schlüssel, die nicht mehr verwendet werden, werden durch das Überschreiben mit einer Konstanten sicher gelöscht. 117 Umgesetzte SFR FCS_COP.1/NK.IPsec FCS_COP.1/NK.Auth FCS_COP.1/NK.ESP FCS_CKM.2/NK.IKE FCS_CKM.1/NK FCS_CKM.4/NK FCS_COP.1/NK.HMAC AES / Sicherer Datenspeicher Der TOE legt seine Logdateien und den sicheren Datenspeicher im persistenten Speicher ab. Sowohl die Logdateien als auch der sichere Datenspeicher liegen auf Dateisystemen, die mit AES im CBC Modus und 256 Bit langen Schlüsseln verschlüsselt sind. Um unvorhersagbare Initialisierungsvektoren für CBC zu erlangen, wird das Encrypted Salt-Sector IV (ESSIV) Verfahren verwendet. Die AES- Schlüssel werden beim initialien Start des TOE von der gSMC-K#1 generiert und in dieser abgelegt. Die Erzeugung der Schlüssel wird von der gSMC-K umgesetzt. Die Schlüssel werden durch das Überschreiben mit konstanten oder pseudozufälligen Werten sicher aus dem Speicher entfernt. Umgesetzte SFR FCS_COP.1/Storage.AES FCS_CKM.4/NK TLS Der TOE stellt die Umsetzung des TLS-Protokolls in der Version 1.2 bereit. Dabei kann der TOE so- wohl Client als auch Server sein. Die Funktion stellt die Integrität und Vertraulichkeit der Verbindun- gen zu anderen vertrauenswürdigen IT-Systemen, aber auch zum Web-Browswer des Administrators sicher. Der Netzkonnektor stellt die technischen Grundlagen für TLS bereit. Die genaue Verwendung der TLS-Verbindungen und eine Auflistung der Kommunikationspartner befindet sich in Tabelle B.4 auf Seite 149. Der Anwendungskonnektor ist dafür verantwortlich, die TLS-Verbindungen so zu kon- figurieren, dass die zweckangemessen parametrisiert sind. Umgesetzte SFR FCS_CKM.1/NK.TLS FMT_MOF.1/NK.TLS Für die Generierung von Nonces und Schlüsseln verwendet der TOE den Hash_DRBG Zufallsge- nerator nach FCS_RNG.1/Hash_DRBG [NIST SP 800-90A], der durch die gSMC-K#2 geseedet wird. Session Keys werden durch das Überschreiben mit konstanten oder pseudozufälligen Werten sicher aus dem Speicher entfernt. Umgesetzte SFR FCS_CKM.1/NK.TLS FCS_CKM.4/NK FCS_COP.1/NK.TLS.HMAC FCS_COP.1/NK.TLS.AES FCS_COP.1/NK.TLS.Auth JSSE erlaubt die Wiederaufnahme bestehender Sessions. Durch eine Anpassung an der JRE wurde die maximale Zeitspanne für eine Wiederaufnahme auf 24 Stunden begrenzt. Die JRE beherrscht von sich aus die session renegotiation nach [RFC 5746]. Die weiteren SFR aus Abschnitt 6.2.8 werden nicht von JSSE umgesetzt. Im Fall einer zertifikatsba- sierten Authentisierung kann der TOE X.509 Zertifikate importieren oder selbst erzeugen und an den Benutzer ausliefern. 118 Umgesetzte SFR FDP_ITC.2/NK.TLS FCS_CKM.1/NK.Zert FPT_TDC.1/NK.TLS.Zert FDP_ETC.2/NK.TLS 7.2. TOE Sicherheitsfunktionen des Konnektors 7.2.1. Kryptografische Dienste/AK (SF.CryptographicServices/AK) Die Sicherheitsanforderung FCS_COP.1/AK.SHA fordert die Umsetzung sicherer Hash-Algorithmen. Der TOE bietet Funktionen zur Berechnung von Hashwerten nach den Algorithmen SHA-256, SHA- 512/256, SHA-384 und SHA-512. Umgesetzte SFR FCS_COP.1/AK.SHA Die Sicherheitsfunktionalität ist ebenfalls dafür zuständig, die AES-Schlüssel für den Verschlüsse- lungsdienst und die Administrationsfunktionen des TOE (für den Export der Konfiguration) zu erstel- len. Die Zufallszahlen, die hierfür benötigt werden, stammen von SF.CryptographicServices/NK. Umgesetzte SFR FCS_CKM.4/AK FCS_CKM.1/AK.AES 7.2.2. TLS Protokoll (SF.TLS) Der TOE nutzt TLS zur Kommunikation mit anderen IT-Systemen sowohl in der Telematikinfrastruk- tur, im Internet als auch im LAN des Leistungserbringers. Tabelle B.4 zeigt die TLS-Verbindungen der KoCoBox MED+. Die Sicherheitsanforderungen an verschiedene Verbindungen des TOE mit anderen IT-Produkten werden durch die Sicherheitsfunktion SF.TLS umgesetzt. Bei diesen Sicherheitsanforderungen geht es primär um die logische Separation der Verbindung von anderen Kommunikationskanälen, sowie die Forderung von Integrität und Authentizität der Verbindung. Die Sicherheitsfunktion regelt auch, mit welchem Zertifikat sich der TOE gegenüber den Kommunikationspartnern authentisiert. Umgesetzte SFR FDP_ACC.1/AK.TLS FDP_ACF.1/AK.TLS FDP_UIT.1/AK.TLS FDP_UCT.1/AK.TLS FTP_ITC.1/AK.VZD FTP_ITC.1/AK.eHKT FTP_ITC.1/AK.CS FTP_ITC.1/AK.FD FTP_ITC.1/AK.KSR FTP_ITC.1/AK.TSL FIA_API.1/AK.TLS Das TLS Protokoll wird im TOE von den Java Secure Socket Extension (JSSE) implementiert, das Teil der Java-Laufzeitumgebung ist. JSSE wird durch Konfigurationsvorgaben und eigene Anpassungen so gehärtet, dass die Anforderungen des Schutzprofils umgesetzt werden. Die kryptographischen Ei- genschaften der TLS Verbindungen werden durch die Sicherheitsfunktion SF.CryptographicServices/NK des Netzkonnektor festgelegt und umgesetzt. 119 Die AK-TLS-SFP sieht in ihrer Sicherheitsanforderung FDP_ACF.1/AK.TLS an verschiedenen Stellen einen TLSConnectionIdentifier vor, auf den Bezug genommen werden muss, um eine TLS Verbin- dung nutzen zu können. Dieser TLSConnectionIdentifier manifestiert sich nicht in der vorliegenden Implementierung. Das Framework JSSE exponiert einen solchen Identifier nicht, sondern sorgt mit Hilfe von Objekt-Referenzen und Socket-Abstraktionen für die Separation der TLS-Verbindungen des Konnektors. 7.2.3. Authentisierung (SF.Authentication) Zusätzlich zur Authentisierung mit kryptographischen Zertifikaten ist der TOE in der Lage, Authenti- sierungen anhand von Passwörtern oder zuvor ausgehandelten Geheimnissen (preshared secrets) durch- zuführen. Die Sicherheitsanforderung FIA_UAU.5/AK formuliert die Authentisierungsverfahren für Ad- ministratoren, Clientsysteme, Smart Cards und für eHealth-Kartenterminals. Management-Schnittstelle Für die Authentisierung von Administratoren an der Management-Schnittstelle der KoCoBox MED+ werden Passwörter verwendet, die über die Management-Schnittstelle vergeben werden. Diese Pass- wörter unterliegen Beschränkungen, die in FIA_SOS.1/AK.Passwörter formuliert sind. Passwörter werden im TOE verschlüsselt abgespeichert. Wenn bei der Authentisierung eine ungültige Kombination aus Benutzernamen und Passwort eingegeben wird, erzwingt der TOE eine dreisekündige Pause vor der nächsten Eingabemöglichkeit. Diese Zwangspause erstreckt sich nicht auf eine Netzwerkverbindung, sondern auf den übermittelten Benutzernamen. Clientsysteme Abhängig von der Konfiguration des Konnektors kann sich ein Clientsytem anhand eines X.509 Zertifi- kats oder anhand eines Passworts authentisieren (FMT_MSA.1/AK.TLS, FMT_MSA.3/AK.TLS). Die Regeln für die Passwörter für Clientsysteme sind in FIA_SOS.1/AK.CS.Passwörter beschrieben. Hierbei ist be- sonders ST-Anwendungshinweis 14 zu beachten. Administratoren können Zertifikate für Clientsyste- me entweder importieren oder vom Konnektor erzeugen lassen. Erzeugte Zertifikate werden in einem passwortgeschützten PKCS12-Container ausgeliefert. Kartenterminals Die Authentisierung von eHealth-Kartenterminals erfolgt in zwei Stufen: Zuerst wird das Kartentermi- nal im Rahmen des TLS-Handshakes anhand eines X.509 Zertifikats authentisiert, das von der SMC- KT des eHealth-Kartenterminals stammt1. In der zweiten Stufe wird ein Challenge-Response basiertes Verfahren verwendet. Der Konnektor sendet das Kommando EHEALTH TERMINAL AUTHENTI- CATE an das Kartenterminal (FIA_SOS.2/AK.PairG). Kartenbasierte Authentisierung Im Kontext der Smart Card basierten Operationen ist es notwendig, dass der Konnektor die gegenseitige Authentisierung von Smart Cards ermöglicht. Dieses Verfahren wird Card to Card (C2C) Authentisie- rung genannt. Der Konnektor unterstützt drei Varianten dieses Verfahrens: einseitige Authentisierung, gegenseitige Authentisierung und gegenseitige Authentisierung mit Ableitung eines kryptographischen Schlüssels (FIA_UAU.5/AK und FIA_API.1/AK). 1 Die Formulierung in FIA_UAU.5/AK kann missverstanden werden, dass das Pairing-Geheimnis in die Authentisierung des TLS-Kanals eingeht. Dort kommen aber ausschließlich X.509 Zertifikate zum Einsatz, vgl. ST-Anwendungshinweis 15. 120 Bei Stapelsignaturen muss sich der TOE gegenüber der QSEE (also dem HBAx) authentisieren; dazu wird das Card2Card-Verfahren angewendet. Der Konnektor weist sich gegenüber dem HBAx mit der gSMC-K#3 aus. aufgerufen. Die zur Authentisierung verwendete gSMC-K ist nicht konfigurierbar, der Ablauf der Authentisierung selbst wird von den beiden Karten bestimmt, sodass der TOE keinen Einfluss darauf hat. Der TOE unterstützt die einseitige und gegenseitige asymmetrische Authentisierung von Chipkar- ten (Card2Card), die gegenseitige Authentisierung auch mit Ableitung eines symmetrischen Schlüssels und Etablierung eines sicheren Kommunikationskanals (Trusted Channel). Weiterhin unterstützt der TOE die gegenseitige symmetrische Authentisierung mit einer Chipkarte einschließlich Aushandlung symmetrischer Schlüssel für einen Secure Messaging Kanal. Die Implementierung des Card2Card Me- chanismus bildet streng die Spezifikationslage ab, wie in TUC_KON_005 [gemSpec_Kon] beschrieben. Die Funktionalität wird im Rahmen unterschiedlicher UseCases genutzt, eine detaillierte Auflistung hierzu findet sich ebenfalls in TUC_KON_005. Die Funktionalität zur Erstellung einer qualifizierten Signatur wird durch den Signaturdienst über eine definierte Schnittstelle zur Verfügung gestellt. Wird die Erstellung einer qualifizierten Signatur über diese Schnittstelle angestoßen, prüft die Anwendungslogik die relevante Konfiguration und Para- metrisierung daraufhin, ob die Nutzung eines sicheren Kanals zwischen TOE (gSMC-K#3) und HBA (QSEE) notwendig ist. Wenn es sich um einen HBA als Signaturerstellungseinheit handelt und außer- dem entweder das SecurityEnvironment SE_2 gesetzt ist oder es sich um eine Stapelsignatur handelt, wird der Aufbau des sicheren Kanals (C2C MUTUAL+TC) angestoßen. Nur wenn der Kanal sicher aufgebaut werden konnte, wird die Signaturerstellung fortgesetzt. Kommt es zu Fehlern beim Aufbau des sicheren Kanals, wird die Signaturerstellung abgebrochen und eine Exception erzeugt, die im weiteren Workflow in einen SOAPFault umgewandelt wird. In einem CV-Zertifikat einer Chipkarte ist das Zugriffsprofil dieser Chipkarte enthalten. Bei der gegenseitigen Authentisierung von Chipkarten wird dieses Zugriffsprofil ausgewertet. Die KoCoBox MED+ führt beim Systemstart automatisierte Prozesse durch, bspw. den Selbst- test. Dies erfordert, dass bestimmte Aktionen bereits zugelassen sind, bevor ein Benutzer authenti- siert ist. Solche Aktionen werden zu einem späteren Zeitpunkt wieder eingeschränkt (FIA_UID.1/AK, FIA_UAU.1/AK). Umgesetzte SFR FIA_UAU.1/AK FIA_UID.1/AK FIA_SOS.2/AK.PairG FIA_UAU.5/AK FIA_API.1/AK FIA_SOS.1/AK.Passwörter FMT_MSA.1/AK.TLS FMT_MSA.3/AK.TLS FIA_SOS.1/AK.CS.Passwörter 7.2.4. Zugriffssteuerung (SF.AccessControl) Eingehende Requests von Clientsytemen werden vom TOE anhand eines Regelwerks zugelassen oder abgelehnt. Die Datengrundlage für dieses Regelwerk ist das Informationsmodell des Konnektors. Ein eingehender Request enthält die IDs des Mandanten, des Clientsystems und des Arbeitsplatzes, von dem aus der Request generiert wurde. Diese Angaben bilden den Kontext des Requests. Das Infor- mationsmodell definiert die Ressourcen, die vom Konnektor verwaltet werden. Es enthält transiente und persistente Objekte, aber auch Beschreibungen der Relationen zwischen dieses Objekten. Das Re- gelwerk, das auf Basis der Daten des Informationsmodells die Zugriffe erlaubt, nutzt die Daten des Kontexts des Requests als Eingangsdaten für die Regeln (FDP_ACC.1/AK.Infomod und FDP_ACF.1/AK.In- fomod). 121 Die transienten Objekte des Informationsmodells werden erzeugt, wenn dem Konnektor Ressour- cen zugeordnet werden. Solche Objekte werden automatisch wieder gelöscht, wenn die Ressourcen entfernt werden. Die persistenten Objekte des Informationsmodells hingegen werden von einem Be- nutzer mit der Rolle Administrator verwaltet (FMT_MSA.1/AK.Infomod). Default-Werte (Standardvorga- ben) existieren im Informationsmodell des Konnektors nicht. Somit kann ein Administrator auch keine abweichenden Default-Werte spezifizieren (FMT_MSA.3/AK.Infomod). Die Sicherheitsfunktionalität SF.AccessControl setzt den TUC_KON_000 („Prüfe Zugriffsberechtigung“) um. Umgesetzte SFR FDP_ACC.1/AK.Infomod FDP_ACF.1/AK.Infomod FMT_MSA.1/AK.Infomod FMT_MSA.3/AK.Infomod 7.2.5. Management der eHealth-Kartenterminals (SF.CardTerminalMgmt) Der Kartenterminaldienst des TOE folgt den Spezifikationen der gematik in [gemSpec_Kon]. Seine Aufgabe ist es, die Kartenterminals und die Verbindungen zu den Kartenterminals zu managen. Ein dem Konnektor bekanntes Kartenterminal befindet sich aus Sicht des Konnektors ein einem von vier Zuständen: bekannt, zugewiesen, gepairt und aktiv. Im Zustand aktiv gibt es zwei Varianten: Das Karten- terminal ist entweder verbunden oder nicht. Ein Kartenterminal kann vom Konnektor nur in technischen Use Cases (TUC) verwendet werden, wenn es im Zustand aktiv/verbunden ist. Den Clientsystemen und internen Benutzern stellt der Kartenterminaldienst Funktionen zur Interak- tion mit dem Kartenterminal zur Verfügung: • Anfordern einer Karte • Auswerfen einer Karte Dies sind die einzig möglichen Interaktionen von außen. Interne Benutzer können darüber hinaus eine weitere Funktion nutzen: • Darstellen von Texten auf dem Display des Kartenterminals Die Funktionalitäten des Kartenterminaldienstes und des Kartendienstes (zur Kommunikation mit den Karten selbst, in Abgrenzung zur Kommunikation mit den Kartenterminals) bilden ein gemeinsa- mes logisches Subsystem. Ausschließlich dieses Subsystem sendet APDUs an Karten oder Kartenter- minals, wodurch die Vorgaben der Anforderungen FDP_ACC.1/AK.eHKT und FDP_ACF.1/AK.eHKT umge- setzt werden. Die Kommunikation mit den Kartenterminals erfordert stets eine gegenseitig authentisierte TLS- Verbindung, die gemäß den Sicherheitsattributen in SF.TLS konfiguriert ist (FDP_UCT.1/AK.TLS, FDP_UIT.1/AK.TLS, FTP_ITC.1/AK.eHKT und FPT_TEE.1/AK). Diejenigen Attribute der Kartenterminals, die dem TOE bekannt sind, stellen einen Teil der Konfi- gurationsdaten des Konnektors dar und können folglich nur von einem Benutzer mit der Rolle Admi- nistrator administriert und exportiert werden (FMT_MTD.1/AK.eHKT_Abf, FMT_MTD.1/AK.eHKT_Mod). Ein Kartenterminal ist im Konnektor unter seinem SICCT-Terminalnamen bekannt. Der Name wird in der Spezifikation auch als FriendlyName bezeichnet. Für den FriendlyName gelten Einschränkungen in Bezug auf die Länge und den Zeichensatz: Er darf zwischen 1 und 32 Zeichen lang sein und Zeichen 122 aus der Menge a-z, A-Z, 0-9 sowie den Bindestrich „-“ enthalten. Kartenterminals, die bei einem Broadcast gefunden werden und deren Name nicht diesen Vorgaben entspricht, werden nicht angezeigt und können nicht gepairt werden. Wenn bestehende Kartenterminals ungültige Zeichen im Namen ha- ben, werden diese Kartenterminals nach Aktualisierung gelöscht und anschließend über den CT/ERROR 20080 im Sicherheitsprotokoll protokolliert. Umgesetzte SFR FDP_ACC.1/AK.eHKT FDP_ACF.1/AK.eHKT FTP_ITC.1/AK.eHKT FDP_UCT.1/AK.TLS FDP_UIT.1/AK.TLS FPT_TEE.1/AK FMT_MTD.1/AK.eHKT_Abf FMT_MTD.1/AK.eHKT_Mod 7.2.6. Management der Smart Cards (SF.SmartCardMgmt) Die unter SF.SmartCardMgmt zusammengefassten Sicherheitsfunktionen beschreiben die Verfahren zum Umgang des Konnektors mit Smart Cards der Typen HBA, SMC-B, eGK und KVK, die in ein vom Konnektor kontrolliertes e-Health Kartenterminal eingesteckt werden. Wenn eine Smart Card in ein solches Kartenterminal eingesteckt wird, werden Typ und Version der Karte identifiziert. Wenn die Karte keinem der bekannten Typen entspricht, wird sie als unbekannt markiert und kann nicht für weitere Operationen verwendet werden. Gehört die Karte zu einem der bekannten Typen, erstellt der Kartendienst ein Objekt für diese Karte und weist diesem ein Karten- handle zu, sodass die Karte referenziert werden kann. Das Kartenhandle ist solange gültig, bis die Karte aus dem Kartenterminal herausgezogen wird. Andere Dienste des Konnektors können die Karte ver- wenden. Externen Entitäten wie Clientsytemen und Fachdiensten dürfen die Karte nur eingeschränkt verwenden. „Verwenden“ bedeutet hier, dass die Karte über den Kartendienst referenziert werden kann. Der direkte Zugriff auf die Karte und das Versenden von Kartenkommandos ist dem Kartendienst vor- behalten, vgl. Abschnitt 7.2.5. Kartenbasierte Operationen werden im Kontext von Kartensitzungen (card session) ausgeführt. Diese Kartensitzungen werden vom Konnektor kontrolliert und laufen isoliert voneinander. Die Sicherheits- zustände der Karten sind an Kartensitzungen gekoppelt und somit streng separiert. Der Sicherheitszu- stand einer Kartensitzung kann durch Interaktion mit dem Benutzer (durch Eingabe einer PIN) oder durch Card-to-Card-Authentisierung verändert werden. Bei einer PIN-Authentisierung gibt der Benutzer seine PIN am Kartenterminal ein, in dem Karte steckt. Es ist auch möglich, die PIN an einem entfernten Kartenterminal einzugeben, wenn dieses ent- sprechend konfiguriert ist. In diesem Fall sorgt der Konnektor für den Aufbau eines sicheren Kanals (secure messaging channel), der durch das kryptographische Material der beteiligten Karten abgesi- chert wird. Bei einer Card-to-card-Authentisierung steuert der Konnektor den Prozess, in dem eine Smart Card sich gegenüber einer anderen Karte im Rahmen eines challenge-response Verfahrens authentisiert. Auch hier wird kryptographisches Material verwendet, das sicher auf den Karten abgelegt sind – in diesem Fall die card verification certificates (CVC). Die privaten Schlüssel der vom Konnektor kontrollierten Smart Cards werden für digitale Signaturen und Entschlüsselung verwendet. Darüber hinaus bieten die Karten noch begrenzten Speicherplatz für Benutzerdaten. Die vorliegende Implementierung weicht architekturell von den Subjekten ab, die im Schutzprofil definiert werden. Die Sicherheitsanforderung FDP_ACF.1.2/AK.KD macht präzise Aussagen, welche Tei- le des TOE welche Aufgaben in Bezug auf Chipkarten haben. Die KoCoBox MED+ ist so aufgebaut, 123 dass ausschließlich der Kartendienst Chipkartenkommandos an die Karte absetzt. In Abgrenzung da- zu kommunizieren weder der Verschlüsselungs- noch der Signaturdienst mit der Karte. Dies ist zu berücksichtigen, wenn die Architektur bewertet wird. Umgesetzte SFR FDP_ACC.1/AK.KD FDP_ACC.1/AK.PIN FPT_TEE.1/AK FDP_ACF.1/AK.KD FDP_ACF.1/AK.PIN FMT_MSA.4/AK FMT_MTD.1/AK.Zert 7.2.7. Signaturdienst (SF.SignatureService) Der TOE enthält eine Signaturerstellungs- und Verifikationsanwendung (SCaVA). Diese Funktionen werden vom Signaturdienst bereitgestellt und stehen internen Benutzern und den Clientsytemen zur Verfügung. Die SCaVA kann sowohl qualifizierte als auch nicht-qualifizierte elektronische Signaturen erstellen und verifizieren. Die unterstützten Dateiformate sind: Für nonQES PDF/A, Text, TIFF und Binärdaten Für QES XML, PDF/A, Text, TIFF Die Konnektorspezifikation definiert in den übergreifenden Festlegungen die Begriffe nonQES_Doc- Formate und QES_DocFormate um die Dateiformate zu referenzieren. Der Signaturdienst des TOE unter- stützt bei der Verifkation von Signaturen verschiedene Verfahren: • PKCS#1 RSASSA-PSS • PKCS#1 RSASSA-PKCS1-v1_5 • Elliptic Curve Digital Signature Algorithm (ECDSA) Die Sicherheitsfunktion SF.SignatureService erfüllt die Anforderungen, die durch die SFR aus der Familie FCS_COP aufgestellt werden. Umgesetzte SFR FCS_COP.1/AK.XML.Sign FCS_COP.1/AK.CMS.Sign FCS_COP.1/AK.PDF.Sign FCS_COP.1/AK.XML.SigPr FCS_COP.1/AK.CMS.SigPr FCS_COP.1/AK.PDF.SigPr FCS_COP.1/AK.PKCS.SigPr FCS_COP.1/AK.SigVer.SSA FCS_COP.1/AK.SigVer.PSS FCS_COP.1/AK.SigVer.ECDSA Die Nutzung des Signaturdienstes wird durch SFR gesteuert, die in den Signaturerstellung-SFP und Signature Verification-SFP des Schutzprofils definiert werden. Nicht nur die Nutzung des Signatur- dienstes, sondern auch die inneren Abläufe unterliegen den SFR. Umgesetzte SFR FDP_ACC.1/AK.Sgen FDP_ACC.1/AK.SigPr FDP_ITC.2/AK.Sig FDP_ACF.1/AK.Sgen FDP_ACF.1/AK.SigPr FMT_MSA.3/AK.Sig 124 Signaturen werden von den beteiligten Smart Cards erzeugt, die unter der Kontrolle des Karten- dienstes stehen. Der Signaturdienst verhält sich unterschiedlich, je nachdem ob qualifizierte oder nicht- qualifizierte Signaturen verarbeitet werden sollen. Wenn ein Dokumentenstapel mit einer qualifizierten Signatur versehen wird, sind besondere Maßnahmen erforderlich. FIA_UAU.5.2/AK(4) fordert, dass die TSF den HBA authentisieren: Als QSEE wird der HBA authentisiert, wenn beim Stecken der Karte der richtige Typ gemäß [gem- Spec_COS] und [gemSpec_HBA_ObjSys] vorhanden ist. Das CardHandle wird als Merkmal verwendet, um die Karte später zu identifizieren und mit einem Signatur-Request zu assoziieren. Als Empfänger der DTBS und der PIN wird der HBA authentisiert, wenn beim Card2Card Schlüssel ausgehandelt werden. Fortlaufend während des Signaturprozesses wird der HBA authentisiert durch den Aufbau eines Trusted Channel zwischen der gSMC-K#3 und dem HBA. Umgesetzte SFR FTP_ITC.1/AK.QSEE FIA_UAU.5.2/AK Wenn eine qualifizierte Signatur erstellt wird, wird der Benutzer durch die Eingabe der PIN.QES der HBAx Smart Card authentisiert. Diese Eingabe kann entweder an dem lokalen Kartenterminal er- folgen, in dem auch der HBAx gesteckt ist, oder aber an einem entfernten Kartenterminal (über das Remote PIN Verfahren). In diesem Fall steckt der HBAx in einem zentralen Kartenterminal, das nicht am Arbeitsplatz des Benutzers steht. Der Benutzer gibt die PIN am Kartenterminal seines Arbeits- platzes ein (das als remote Kartenterminal konfiguriert sein muss). Es besteht eine sichere Verbindung (secure messaging) zwischen dem Kartenterminal am Arbeitsplatz und dem Kartenterminal, das den HBAx enthält. Der Benutzer kann anhand der Jobnummer, die auf dem Display des Kartenterminals an seinem Arbeitsplatz angezeigt wird, feststellen, ob die PIN für den von ihm initiierten Signaturvorgang abgefragt wird. Umgesetzte SFR FTA_TAB.1/AK.Jobnummer FMT_MSA.4/AK FIA_SOS.2/AK.Jobnummer FTA_TAB.1/AK.SP Der Benutzer des TOE soll der Authentizität der Signaturen (für QES und nonQES) und Zertifikate versichert sein. Die Sicherheitsfunktion SF.SignatureService stellt die Nachweise bereit, um diese Ver- sicherung zu gewährleisten. Diese Nachweise stehen in Form von Verification Reports zur Verfügung, wie sie von der Konnektorspezifikation in TAB_KON_066 gefordert und profiliert werden [gemSpec_Kon, Abschnitt 4.1.8.5.2]. Dokumente und zu signierende Daten (DTBS) werden niemals permanent im TOE gespeichert, so- dass eine Überwachung der DTBS zur Sicherstellung der Integrität in der vorliegenden Architektur nicht umgesetzt ist. Die Integrität der zu signierenden Daten, die von FDP_SDI.2/AK gefordert wird, setzt der TOE um, indem die von der Karte berechnete Signatur gegen den Hashwert der zu signierenden Daten geprüft wird. Umgesetzte SFR FDP_DAU.2/AK.Cert FDP_SDI.2/AK 125 Signaturrichtlinien Eine besondere Bedeutung kommt im Kontext des Signaturdienstes den Signaturrichtlinien zu. Diese Richtlinien profilieren das Signieren von Dokumenten und das Verifizieren von Signaturen. Leider ist der Begriff „Signaturrichtlinie“ im Kontext des Konnektors nicht eindeutig gefasst. Schutzprofil und Konnektorspezifikation interpretieren den Begriff unterschiedlich. Im Folgenden werden die Interpre- tationen beschrieben und die für dieses Dokument angenommene Interpretation dargelegt. Schutzprofil Das Schutzprofil interpretiert „Signaturrichtlinie“ bewusst weit. Im Glossar in [BSI- CC-PP-0098] wird der Begriff als „Profilierung der Signaturformate“ definiert. Er dient z. B. zur Unterscheidung zwischen qualifizierten und nicht-qualifizierten Signaturen. FDP_DAU.2.1/AK.QES und FDP_DAU.2.1/AK.Sig listen die vom Konnektor zu unterstützenden Dokumentformate, Si- gnaturformate und Signaturvarianten auf; sie machen jedoch keine Aussagen darüber, welche Elemente technisch und fachlich sinnvoll verknüpfbar sind. Darüber hinaus führt das Glossar noch die zulässige Signaturrichtlinie auf, die u. a. auf die An- wendbarkeit der zu signierenden Daten durch den EVG abstellt. Dies kann als Einschränkung der Kombinationsmöglichkeiten aus FDP_DAU.2.1/AK.QES verstanden werden. Gestützt wird diese Annahme durch die Anforderung aus FMT_MSA.1.1/AK.User(2)2, die die Auswahl der Signatur- richtlinie den Benutzern des Clientsystems vorbehält. Konnektorspezifikation Die Konnektorspezifikation interpretiert „Signaturrichtlinie“ enger als das Schutzprofil. Signaturrichtlinien im Sinne der Spezifikation profilieren die Signaturerstel- lung und -prüfung. Sie werden über eine URI referenziert. Der Konnektor selbst stellt keine Signaturrichtlinie zur Verfügung, es obliegt den Fachmodulen, eigene Richtlinien zu definieren [gemSpec_Kon, Abschnitt 4.1.8.1.2]. Das ist das Vorgehen im Fachmodul NFDM. Legt man diese Interpretation zugrunde, so gibt es in OPB 2.1 genau eine Signaturrichtlinie. Für dieses Security Target ist es nicht zweckdienlich, sich ausschließlich einer der beiden Interpre- tationen zu verschreiben und die andere nicht zu beachten. Stattdessen wird in diesem Security Target eine Interpretation angenommen, die der Obermenge der Interpretationen des Schutzprofils und der Konnektorspezifikation entspricht: Wir nehmen die Auflistungen der Elemente aus FDP_DAU.2.1/AK.QES und FDP_DAU.2.1/AK.Sig an, beschränken jedoch die Kombinierbarkeit anhand der in TAB_KON_778 vor- gegebenen Einsatzbereiche. Tabelle 7.1 zeigt die verschiedenen Signaturverfahren in Bezug auf die Signatureigenschaften Gegensignatur, Parallelsignatur und OCSP-Einbettung. Zusätzlich gelten Ein- schränkungen bei der Verwendung von Signaturverfahren: XAdES / QES Der Konnektor unterstützt qualifizierte Signaturen auf XML-Dokumenten ausschließ- lich in Verbindung mit einer benannten Signaturrichtlinie. In OPB 2.1 wird die in der Firm- ware des TOE verankerte Signaturrichtlinie des Fachmodul NFDM [gemRL_QES_NFDM, Ab- schnitt 3.] berücksichtigt, andere Signaturrichtlinien für QES werden nicht akzeptiert. Mit dieser Einschränkung setzt das Security Target die Anforderung aus TIP1-A_5538 um. Die möglichen Transformationen bei der Erzeugung und Verifikation von XA- dES Signaturen wurde stark eingeschränkt. Die einzig erlaubte Transformation ist http://www.w3.org/2006/12/xml-c14n11 (ohne Kommentare) zur Kanonisierung der 2 Allerdings gilt diese Annahme nur, wenn man die Begriffe „zulässige Signaturrichtlinie“ (aus dem Glossar) und „gülti- ge Signaturrichtlinie“ (aus dem SFR) synonym betrachtet (Hervorhebungen in den Zitaten durch den ST-Autor). Das Schutzprofil bleibt hier vage. 126 XML-Daten. Durch die Beschränkung auf Detached Signaturen sind keine Transformationen zum Ausschneiden der Signatur notwendig. XAdES / nonQES Der Konnektor unterstützt keine nicht-qualifizierten Signaturen auf XML- Dokumenten. PAdES PAdES Signaturen, die nicht das gesamte Dokument umfassen, werden als ungültig gewertet. Weiterhin werden keine Updates auf einem bereits signierten Dokument unterstützt: • Es können keine OCSP-Responses in den Document Security Store eingebettet werden. • Dokumentinkludierende Gegensignaturen in Form von PDF Serial Signatures werden nicht unterstützt. Herstellerspezifische Signaturrichtlinien Fast alle ursprünglich vom Hersteller ergänzten Si- gnaturrichtlinien sind inzwischen durch die Spezifikationen der gematik oder das Protection Profile vorgegeben. Folgende Vorgaben/Anpassungen können darüber hinaus als herstellerspe- zifische Signaturrichtlinien angesehen werden: • Sichere Ermittlung des signierten Bereichs von PDF-Signaturen nach dem Algorithmus gemäß Vulnerability Report der Ruhr-Universität Bochum. Hierdurch wird eine Härtung gegen Universal Signature Forgery (USF), Incremental Saving Attack (ISA) und Signature Wrapping Attack (SWA) erreicht. • Härtung der zur Erstellung und Prüfung von XML-Signaturen verwendeten XML-Schemas gegen Signature Wrapping Angriffe gemäß Empfehlungen in [RUB-XML]. • Härtung der XML-Verarbeitung (Schnittstellen und Parser) gemäß OWASP. • Verbot mehrerer identischer ID-Attribute in einem XML-Dokument. Die Signaturerstel- lung und -prüfung muss mit einer Fehlermeldung abgebrochen werden, wenn ID-Attribute nicht eindeutig sind. Folgt man dieser Interpretation, ist auch FMT_MSA.1/AK.User umzusetzen. Damit obliegt es der Ver- antwortung des Benutzers des Clientsystems, über eine entsprechende Auswahl im Clientsystem die für den speziellen Anwendungszweck angemessene Signaturrichtlinie auszuwählen. Umgesetzte SFR FDP_DAU.2/AK.Sig FDP_DAU.2/AK.QES FMT_MSA.1/AK.User External Authenticate Der Konnektor bietet an der Außenschnittstelle die Operation ExternalAuthenticate an. Diese Operati- on signiert einen max. 512 Byte langen Binärstring, den das Clientsystem bereitstellt. Der Konnektor verwendet ausschließlich die SMC-B oder den HBA, um Signaturen für diese Operation zu erzeugen. Der Umfang der Schnittstelle ist in TIP1-A_5439 der Konnektorspezifikation definiert [gemSpec_Kon, Abschnitt 4.1.13.4.1]. Der TOE unterstützt an dieser Schnittstelle das im Schutzprofil geforderte Ver- fahren PKCS#1 (RSASSA-PKCS1-v1_5, RSASSA-PSS). Umgesetzte SFR FDP_ACF.1.2/AK.Sgen(6) 127 Parallelsignatur Gegensignatur OCSP-Einb. Anz. Signat. Erstellen Prüfen Erstellen Prüfen Erstellen Prüfen nonQES CAdES∗ X X X X X1 X2 unbeg. PAdES† . . . . . . 1 XAdES× – – – – – – – QES CAdES∗ X X X X X X unbeg. PAdES† . . . . . . 1 XAdES‡ . . . . X X 1 ∗ Für Detached und Enveloping Signaturen † Speichern der Signatur als Incremental Update × nonQES XAdES wird vom Konnektor nicht angeboten. ‡ Für Detached Signaturen bei NFDM 1 Nur bei der Erstellung von Gegensignaturen 2 Nur bei der Prüfung von Parallelsignaturen bei der Erstellung von Gegensignaturen Tabelle 7.1.: Signaturvarianten 7.2.8. Verschlüsselungsdienst (SF.EncryptionService) Der Konnektor ver- und entschlüsselt über seinen Verschlüsselungsdienst Dokumente hybrid und sym- metrisch. Dabei wird zwischen den Datenformaten XML, PDF/A, Text, Tiff und Binärdaten unter- schieden. Darüber hinaus können MIME Dokumente nach S/MIME und XML Dokumente nach der W3C Recommendation „XML Encryption Syntax and Processing“ [XMLEnc] ver- und entschlüsselt werden. Der symmetrische Teil der Verschlüsselung folgt AES/GCM mit Schlüssellängen von 128 Bit und 256 Bit. Der asymmetrische Teil unterstützt RSAOAEP mit Schlüssellänge 2048 Bit. Die Sicherheits- funktion setzt die Anforderungen aus der Familie FCS_COP um. Die Konnektorspezifikation wurde durch den Change C_7076 in Bezug auf die Anforderungen TIP1-A_4617, GS-A_4375 und GS-A_4376 so er- setzt, dass das Verfahren RSA RSAES-PKCS1-v1_5 nur noch optional ist [gemErrata_4_Kon_PTV3]. Gemäß dieser Anpassungen unterstützt der Konnektor ausschließlich RSAOAEP. Umgesetzte SFR FCS_COP.1/AK.AES FCS_COP.1/AK.XML.Ver FCS_COP.1/AK.XML.Ent FCS_COP.1/AK.MIME.Ver FCS_COP.1/AK.MIME.Ent FCS_COP.1/AK.CMS.Ver FCS_COP.1/AK.CMS.Ent Die Verwendung der Sicherheitsfunktion unterliegt Regeln, die in weiteren Anforderungen formu- liert sind. Dort ist auch beschrieben, wie der TOE mit den zu verschlüsselnden und den verschlüsselten Daten umzugehen hat. Umgesetzte SFR FDP_ACC.1/AK.Enc FDP_ACF.1/AK.Enc FDP_ITC.2/AK.Enc FDP_ETC.2/AK.Enc 128 Verschlüsselungsrichtlinien Der Verschlüsselungsdienst ist nach den Vorgaben der gematik implementiert. Korrespondierend zu den Operationen und TUCs in [gemSpec_Kon] gibt es keine expliziten oder identifizierbaren Ver- schlüsselungsrichtlinien. Die Vorgaben in SFRs, die auf solche Richtlinien Bezug nehmen, werden als eine Referenz auf die [gemSpec_Kon] interpretiert, um eine spezifiktionskonforme Implementierung zu gewährleisten. Der TOE verwendet die herstellereigene Verschlüsselungsrichtlinie, dass bei XML- Verschlüsselung ausschließlich das Gesamtdokument verschlüsselt wird. Das Ver- und Entschlüsseln von Teilbäumen wird nicht unterstützt. Als Empfängerzertifikate werden zugelassen: Zum Referenzzeitpunkt (Zeitpunkt der Verschlüsselung) zeitlich gültige Zertifikate mit der KeyUsage keyEncipherment und deren Signatur mit einem zum Referenzzeitpunkt zulässigen Algorithmus erfolgt ist – sowie: 1. deren CA sich in der Liste der importierten CAs befindet – oder 2. deren CA in der TSL aktiv ist, das ENC-Zertifikat zum Referenzzeitpunkt nicht widerrufen war und die mindestens eine der folgenden Policies enthält: a) OID_EGK_ENC (1.2.276.0.76.4.68) b) OID_EGK_ENCV (1.2.276.0.76.4.69) c) OID_HBA_ENC (1.2.276.0.76.4.74) d) OID_SMCB_ENC (1.2.276.0.76.4.76) Dem Betreiber des EVG bleibt es unbenommen, CAs für Zertifikate, die den Anforderungen aus b) nicht (mehr) genügen in die unter (1) genannte Liste einzutragen um die strikten Prüfungen unter (2) zu vermeiden. 7.2.9. Sicherer Speicher (SF.SecureStorage) Der Konnektor verfügt über einen sicheren internen Datenspeicher, um Daten verschlüsselt und signiert abzulegen. Die Verschlüsselung ist symmetrisch und für den Benutzer transparent. Der symmetrische Schlüssel für diese Daten liegt im Netzkonnektor und ist nicht von außen manipulierbar. Jede Datei, die im sicheren Datenspeicher abgelegt ist, wird einzeln signiert. Beim Lesezugriff auf diese Datei wird die Signatur geprüft. Eine invalide Signatur versetzt den TOE in einen kritischen Betriebszustand, der den Funktionsumfang des Konnektors stark einschränkt. Umgesetzte SFR FDP_ACC.1/AK.SDS FDP_ACF.1/AK.SDS Die kryptographischen Funktionen des sicheren Datenspeichers werden von der Sicherheitsfunktion SF.CryptographicServices/NK umgesetzt, vgl. Abschnitt 7.1.7, Unterabschnitt „AES / Sicherer Datenspei- cher“. 129 7.2.10. Versichertenstammdatenmanagement (SF.VSDM) Das Fachmodul VSDM des Konnektors liest die Versichertenstammdaten (VSD) von den elektroni- schen Gesundheitskarte des Patienten ein und übermittelt sie an das Praxisverwaltungssystem. Darüber hinaus können die Stammdaten auf der eGK aktualisiert werden: Der Konnektor prüft auf dem Update Flag Service der Telematikinfrastruktur, ob eine Aktualisierung für die Daten vorliegt. Ist das der Fall, vermittelt der Konnektor einen sicheren Kanal zwischen dem Versichertenstammdatendienst der TI (VSDD) und der eGK des Patienten. Wenn dieser Kanal aufgebaut ist, sind die Daten zwischen den Kommunikationspartner Ende-zu-Ende verschlüsselt. Der Konnektor leitet den verschlüsselten Daten- strom weiter, kann die Daten aber nicht selbst lesen. Zusätzlich zur Aktualisierung der VSD kann derselbe Mechanismus verwendet werden, um das Ob- jektsystem der eGK zu aktualisieren. Hierbei ist jedoch der Card Management Service der TI (CMS) der Kommunikationspartner der Karte, nicht der VSDD). Der Kommunikationsablauf wird nicht von Betriebsparametern beeinflusst, die der Administrator verändern kann. Somit gibt es auch keine Standardwerte, die der Administrator mit alternativen Werten belegen kann. Umgesetzte SFR FDP_ACC.1/AK.VSDM FDP_ACF.1/AK.VSDM FMT_MSA.3/AK.VSDM FMT_MSA.1/AK.VSDM 7.2.11. Administration/AK (SF.Administration/AK) Der Konnektor enthält eine Management-Schnittstelle, die von einem Administrator über eine Web- Anwendung benutzt werden kann. Ein authentisierter Benutzer mit der Rolle Administrator kann die Verwaltungsoperationen vornehmen, die in [gemSpec_Kon] definiert sind. Unter anderem können so die Konfigurationsdaten der Konnektor Services angepasst werden. Jeder Service definiert seine eige- ne, begrenzte Menge an Konfigurationsdaten. Der Management Service selbst definiert übergreifende Konfigurationselemente. Die Sicherheitsfunktionalität SF.Administration/AK ist ebenfalls dafür verantwortlich, die Konfigura- tionsparameter der Fachmodule des Konnektors zu managen. Auch für die Konfigurationsparameter der Fachmodule wird die Managementschnittstelle des Konnektors verwendet. Die Web Application zur Administration unterstützt dies ebenfalls. Die Validierung und Prüfung der Konfigurationspara- meter für ein Fachmodul erledigt allerdings nicht der Anwendungskonnektor, sondern das Fachmodul selbst. Der Anwendungskonnektor reicht die Konfigurationsparameter an das Fachmodul weiter. Das Fachmodul prüft die Parameter und ruft die TUCs an LS.FM.RMI auf, um sie dem Anwendungskonnek- tor zum Persistieren zurückzugeben. Die Konnektor Security Guidance erklärt den Vorgang genauer [KoCo AGD_Kon-Sec, Abschnitt 3.4.]. Über die Managementanwendung kann auch die Konfiguration des TOE sicher exportiert werden. Die Konfigurationsdaten werden dabei symmetrisch verschlüsselt. Umgesetzte SFR FMT_SMR.1/AK FMT_SMF.1/AK FMT_MOF.1/AK FMT_MTD.1/AK.Admin FMT_MSA.1/AK.TLS FMT_MSA.3/AK.TLS Die Managementanwendung stellt Funktionen zur Administration des Gesamtkonnektors, z. B. die Downloads der Updates vom KSR-Server oder die Anpassung des Funktionsumfangs des Konnektors 130 zur Verfügung. Das Schutzprofil räumt die Möglichkeit ein, dass der TOE automatische Updates seiner Firmware durchführt, wenn ein Administrator die Funktion an der Management-Schnittstelle aktiviert. Die KoCoBox MED+ setzt diese Funktionalität nicht um. Das Herunterladen und Anwendungen von Update-Paketen muss vom Administrator explizit angefordert werden. Ein Updatepaket für den Konnektor enthält die Firmware für den Basiskonnektor und die Fach- module. Eine Aktualisierung des Basiskonnektors enthält immer auch eine Aktualisierung der Fach- module, diese Updates sind nicht separat voneinander einspielbar. Umgekehrt gilt, dass Fachmodule immer nur im Kontext der Updates des Basiskonnektors aktualisiert werden können. Tabelle 1.6 zeigt die Versionsnummern des TOE und der Fachmodule. Auf Anforderung des Administrators verifiziert die Update-Komponente des TOE die Integrität und Authentizität des Update Image, indem sie einen SHA-512 Hash über das Image berechnet und dessen kryptographische Signatur mittels RSASSA-PSS und des öffentlichen Signer-Zertifikats des Herstel- lers überprüft. Das Zertifikat selbst wird gegen ein CA-Zertifikat geprüft, das im Root-Filesystem auf dem NAND-Flash verankert ist. Darüberhinaus wird die Firmware nur dann installiert, wenn die Ver- sionsnummer des Update-Images in einer Liste gültiger Versionsnummern – der sogenannten Firm- waregruppe – enthalten ist. Diese Liste ist Teil des TOE und wird bei jedem Update aktualisiert. Bei einem Firmware-Update wird immer die gesamte Systempartition (inklusive dem AK und mög- licher zukünftiger Teile des Konnektors) aktualisiert. Zuerst wird die neue Firmware auf die alternative Partition des Flash-Speichers (eMMC) aufgespielt. Nach dem erfolgreichen Aufspielen wird die aktua- lisierte Partition als aktive Partition festgelegt und der Konnektor neu gestartet. Der Konnektor startet nur dann von der aktualisierten Partition, wenn das Update erfolgreich war. So wird garantiert, dass das Gerät auf einen konsistenten und sicheren Softwarestand zurückfällt, falls die Validierung vorher fehlgeschlagen ist, oder die neue Firmware nicht aufgespielt werden konnte. Die Inhalte des sicheren Datenspeichers – besonders die Konfigurationsdaten und die Logfiles – werden vom Updateprozess nicht berührt und bleiben erhalten. Umgesetzte SFR FDP_ACC.1/AK.Update FDP_ACF.1/AK.Update FDP_UIT.1/AK.Update 7.2.12. Selbstschutz (SF.SelfProtection/AK) Der Konnektor verfügt über Schutzmechanismen, um sich selbst und die verarbeiteten Daten zu schüt- zen. Die verschiedenen Mechanismen werden in diesem Abschnitt beschrieben. Der TOE verwendet in verschiedenen Use Cases kryptographische Zertifikate und entsprechende Validierungsverfahren, Die konkreten Schritte zur Validierung eines Zertifikats hängen von der Art des Zertifikats ab. Dabei werden CVC und X.509 Zertifikate unterschiedlich behandelt. Innerhalb der X.509 Zertifikate wird zwischen qualifizierten und nicht-qualifizierten Zertifikaten unterschieden. Bei den nicht-qualifizierten Zertifikaten wiederum macht es einen Unterschied, ob ein Zertifikat aus dem Vertrauensraum der gematik oder aus dem herstellerspezifischen Vertrauensraum der KoCo PKI stammt. Somit ergeben sich vier verschiedene Kategorien von Zertifikaten. Wenn man Sonderfälle und Ausnahmen der X.509 Zertifikate für den Moment außer Betracht lässt, verläuft eine Validierung entlang folgender Linie: Schritt 1 Prüfung der zeitlichen Gültigkeit Schritt 2 Prüfung der mathematischen Korrektheit 131 Schritt 3 Prüfung des Vertrauensstatus: Zertifikate aus dem Vertrauensraum der gematik werden ge- gen die Trust Service List (TSL) der gematik geprüft. Schritt 4 Zertifikate aus dem Vertrauensraum der gematik werden auf Widerruf geprüft. Im Normal- fall geschieht dies online mittels OCSP. Die Zertifikate der VPN-Konzentratoren werden gegen eine Widerrufsliste (CRL) geprüft. Der TOE überprüft ebenfalls die Signaturen der TSL und der CRL. Beide Listen werden automatisch alle 24 Stunden durch einen HTTP-Aufruf heruntergeladen und aktualisiert. Umgesetzte SFR FPT_TDC.1/AK Der Betriebszustand des TOE wird während des gesamten Betriebsablaufs überwacht. Wenn ein Modul oder ein Dienst einen relevanten3 Fehler feststellt, wird ein interner Ereignisdienst aufgerufen, um alle anderen Dienste und registrierte Nachrichtenempfänger darüber zu informieren. Die Module entscheiden nach dem Empfang einer Nachricht, ob sie ihre Ausführung unterbrechen, solange der Feh- lerzustand besteht. Diese Entscheidung wird anhand der Regeln aus der Spezifikation [gemSpec_Kon, TAB_KON_504] getroffen. Umgesetzte SFR FPT_FLS.1/AK Der Konnektor führt beim Systemstart einen Selbsttest durch. Der Administrator kann den Selbsttest während der Laufzeit erneut starten. Der Selbsttest findet auch alle 24 Stunden statt (vgl. das entspre- chende SFR des Netzkonnektors FPT_TST.1/NK). Der ST-Anwendungshinweis dort gilt entsprechend auch für den AK. Die Prüfung bezieht sich nicht streng auf ausführbare Dateien, sondern auch alle an- deren Teil der Firmware. Damit gilt der Integritätsschutz auch für die XML-Schemadateien, aus denen sich die Signaturrichtlinien zusammensetzen. Umgesetzte SFR FPT_TST.1/AK.Run-time FPT_TST.1/AK.Out-Of-Band Das im TOE verwendete Java Runtime Environment ist speziell für die Belange des Konnektors gehärtet worden. Es wird dafür gesorgt, dass nicht mehr benötigte kryptographische Schlüssel unmit- telbar nach der Verwendung sicher gelöscht werden. Dabei werden die Speicherbereiche, in den die Schlüssel lagen, mit Nullen überschrieben. Der Garbage Collector der JRE wurde so angepasst, dass keine Schattenkopien mehr im Speicher verbleiben. Umgesetzte SFR FCS_CKM.4/AK FDP_RIP.1/AK Die kryptographische Identität des Konnektors ist auf einer gSMC-K gespeichert. Diese Smart Card erfüllt die Anforderungen des Schutzprofils [BSI-CC-PP-0082-2] und gehört zur Einsatzumgebung. Die Schutzmechanismen werden hier nicht weiter betrachtet. 3 Die gematik Spezifikation definiert die kritischen Fehlerzustände, vgl. [gemSpec_Kon, Abschnitt 3.3, TAB_KON_503] 132 7.2.13. Protokollierungsdienst/AK (SF.Audit/AK) Sicherheitsrelevante Ereignisse des Konnektors und der Fachmodule werden in einem Protokoll per- manent gespeichert. Der Speicherplatz für dieses Protokoll ist mit 900 MB angemessen groß. Beim Überlauf des Protokollspeichers werden alte Protokolleinträge zyklisch überschrieben, also die ältesten Einträge zuerst. Es gibt keinen anderen Mechanismus zum Löschen oder Ändern von Protokolleinträ- gen. Zum Schutz der Log-Einträge geben die Konfigurationsparameter LOG_DAYS (für den Basiskonnek- tor) und FM__LOG_DAYS (für Fachmodule) an, nach wievielen Tagen Logeinträge frühestens überschrieben werden können [gemSpec_Kon, TAB_KON_609]. Die Konfigurationsparameter LOG_LEVEL FM__LOG_LEVEL legt die Mindest-Schwere zu protokollierender Einträge fest. Umgesetzte SFR FAU_STG.4/AK FAU_STG.1/AK Der TOE ist gegen Überlauf seines Protokollspeichers geschützt. Extern ausgelöste Audit-Ereignisse werden direkt abgespeichert, falls dasselbe Ereignis nicht bereits innerhalb der letzten zwei Sekunden aufgetreten ist. Trat das Ereignis bereits in den letzten zwei Sekunden auf, wird nur der Zähler erhöht. Wenn das Ereignis danach innerhalb von zwei Sekunden nicht erneut auftritt, wird es aus der Liste entfernt und beim nächsten Auftreten als ein neues Ereignis behandelt. Wenn ein Ereignis mehrfach auftritt und der Zähler mehrfach inkrementiert wird, wird das Ereignis nach 20 Sekunden (maximale Höhe des Zählers) erneut protokolliert. Die Logs werden in einer Datenbank gespeichert und automa- tisch verschlüsselt (vgl. SF.CryptographicServices/NK). Wenn der Protokollspeicher des TOE zu mehr als 80% gefüllt ist, informiert der TOE den Admi- nistrator über das Display am Gehäuse des Konnektors. Der Protokollspeicher kann nur vom zentralen Protokollierungsdienst, nicht aber von externen Enti- täten, ausgelesen werden. Zum Betrachten der Protokolleinträge greift der Administrator auf Funktio- nen der Managementschnittstelle zurück, die die zu präsentierenden Einträge beim Protokollierungs- dienst anfordert. Umgesetzte SFR FAU_GEN.1/AK FAU_SAR.1/AK FPT_STM.1/AK 133 7.3. Verhältnis von SFR zu SF des Netzkonnektors Tabelle 7.2 zeigt, in welchem Verhältnis die im Abschnitt 6.2 definierten Sicherheitsanforderungen an den Netzkonnektors zu den in Abschnitt 7.1 beschriebenen Sicherheitsfunktionen des NK stehen. Die verwendeten Symbole sind in der Legende in Tabelle A.1 beschrieben. SF.VPN SF.DynamicPacketFilter SF.NetworkServices SF.SelfProtection/NK SF.Audit/NK SF.Administration/NK SF.CryptographicServices/NK FAU_GEN.1/NK.SecLog . . . . X . . FAU_GEN.2/NK.SecLog . . . . X . . FCS_CKM.1/NK.TLS . . . . . . X FCS_CKM.1/NK.Zert . . . . . . X FCS_CKM.1/NK . . . . . . X FCS_CKM.2/NK.IKE . . . . . . X FCS_CKM.4/NK . . . . . . X FCS_COP.1/NK.Auth . . . . . . X FCS_COP.1/NK.ESP . . . . . . X FCS_COP.1/NK.Hash . . . . . . X FCS_COP.1/NK.HMAC . . . . . . X FCS_COP.1/NK.IPsec . . . . . . X FCS_COP.1/NK.TLS.AES . . . . . . X FCS_COP.1/NK.TLS.Auth . . . . . . X FCS_COP.1/NK.TLS.HMAC . . . . . . X FCS_COP.1/Sign . . . . . . X FCS_COP.1/Storage.AES . . . . . . X FCS_RNG.1/Hash_DRBG . . . . . . X FDP_ETC.2/NK.TLS . . . . . . X FDP_IFC.1/NK.PF . X . . . . . FDP_IFF.1/NK.PF . X . . . . . FDP_ITC.2/NK.TLS . . . . . . X FDP_RIP.1/NK . . . X . . . FIA_UID.1/NK.SMR . . . . . X . FMT_MOF.1/NK.TLS . . . . . . X FMT_MSA.1/NK.PF . . . . . X . FMT_MSA.3/NK.PF . X . . . . . FMT_MSA.4/NK . . . . . X . FMT_MTD.1/NK . . . . . X . FMT_SMF.1/NK . . . . . X . FMT_SMR.1/NK . . . . . X . FPT_EMS.1/NK . . . X . . . 134 SF.VPN SF.DynamicPacketFilter SF.NetworkServices SF.SelfProtection/NK SF.Audit/NK SF.Administration/NK SF.CryptographicServices/NK FPT_STM.1/NK . . X . . X . FPT_TDC.1/NK.TLS.Zert . . . . . . X FPT_TDC.1/NK.Zert X . . . . . . FPT_TST.1/NK . . . X . . . FTP_ITC.1/NK.TLS . . . . . . X FTP_ITC.1/NK.VPN_SIS X . . . . . . FTP_ITC.1/NK.VPN_TI X . . . . . . FTP_TRP.1/NK.Admin . . . . . X . Tabelle 7.2.: Abbildung der SFR des NK auf Sicherheitsfunktionalität 135 7.4. Verhältnis von SFR zu SF des Konnektors Tabelle 7.3 zeigt, in welchem Verhältnis die im Abschnitt 6.3 definierten Sicherheitsanforderungen an den Anwendungskonnektors zu den in Abschnitt 7.2 beschriebenen Sicherheitsfunktionen des AK stehen. Die verwendeten Symbole sind in der Legende in Tabelle A.1 beschrieben. SF.CryptographicServices/AK SF.TLS SF.Authentication SF.AccessControl SF.CardTerminalMgmt SF.SmartCardMgmt SF.SignatureService SF.EncryptionService SF.SecureStorage SF.VSDM SF.Administration/AK SF.SelfProtection/AK SF.Audit/AK 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 . . . . . . . . . . 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.PKCS.SigPr . . . . . . 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 . . . . . . . . . . . . FCS_COP.1/AK.MIME.Ent . . . . . . . X . . . . . FCS_COP.1/AK.MIME.Ver . . . . . . . X . . . . . 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 . . . . . . . . . . . 136 SF.CryptographicServices/AK SF.TLS SF.Authentication SF.AccessControl SF.CardTerminalMgmt SF.SmartCardMgmt SF.SignatureService SF.EncryptionService SF.SecureStorage SF.VSDM SF.Administration/AK SF.SelfProtection/AK SF.Audit/AK 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 . . FDP_SDI.2/AK . . . . . . X . . . . . . FDP_UCT.1/AK.TLS . X . . X . . . . . . . . FDP_UIT.1/AK.TLS . X . . X . . . . . . . . FDP_UIT.1/AK.Update . . . . . . . . . . X . . FIA_API.1/AK . . X . . . . . . . . . . FIA_API.1/AK.TLS . X . . . . . . . . . . . FIA_SOS.1/AK.Passwörter . . X . . . . . . . . . . FIA_SOS.1/AK.CS.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.Infomod . . . X . . . . . . . . . FMT_MSA.1/AK.TLS . . X . . . . . . . X . . FMT_MSA.1/AK.User . . . . . . X . . . . . . 137 SF.CryptographicServices/AK SF.TLS SF.Authentication SF.AccessControl SF.CardTerminalMgmt SF.SmartCardMgmt SF.SignatureService SF.EncryptionService SF.SecureStorage SF.VSDM SF.Administration/AK SF.SelfProtection/AK SF.Audit/AK FMT_MSA.1/AK.VSDM . . . . . . . . . X . . . FMT_MSA.3/AK.Infomod . . . X . . . . . . . . . FMT_MSA.3/AK.TLS . . X . . . . . . . X . . FMT_MSA.3/AK.Sig . . . . . . X . . . . . . FMT_MSA.3/AK.VSDM . . . . . . . . . X . . . FMT_MSA.4/AK . . . . . 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 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 . . X . . . . . . . . FTP_ITC.1/AK.FD . X . . . . . . . . . . . FTP_ITC.1/AK.KSR . X . . . . . . . . . . . FTP_ITC.1/AK.TSL . X . . . . . . . . . . . FTP_ITC.1/AK.QSEE . . . . . . X . . . . . . FTP_ITC.1/AK.VZD . X . . . . . . . . . . . Tabelle 7.3.: Abbildung der SFR des AK auf Sicherheitsfunktionalität 138 8. ASE_TSS: Fachmodule Dieses Kapitel erfüllt die Anforderung des Refinements für ASE_TSS an den Hersteller, die in Ab- schnitt 6.4.5 erhoben wird. Konnektoren dienen als Ablaufplattform für Fachmodule. Die gematik Spezifikation bezeichnet ein Fachmodul als „integrale[n] Bestandteil des Konnektors“. Daraus ergeben sich gegenseitige Anforde- rungen zwischen Basiskonnektor und den Fachmodulen. Dieses Kapitel geht auf die Anforderungen ein und zeigt, auf welche Weise der Basiskonnektor die Forderungen der Fachmodule umsetzt und welche Funktionen den Fachmodulen zur Verfügung gestellt werden. Fachmodule unterliegen im Konnektor Restriktionen und Auflagen. Diese werden in der Konnektor Security Guidance beschrieben [KoCo AGD_Kon-Sec]. Die dort beschriebenen Composition Requi- rements müssen vom Entwickler eines Fachmoduls eingehalten werden, um die Funktionsfähigkeit des Gesamtkonnektors nicht zu gefährden. Zur besseren Lesbarkeit werden die Composition Requirements in Anhang C wiederholt. 8.1. Erklärung der Konformität zu Technischen Richtlinien 8.1.1. Fachmodule NFDM und AMTS / OPB 2.1 Die Technischen Richtlinien der Fachmodule NFDM und AMTS fordern, dass die CC-Zertifizierung des Konnektors bestimmte Eigenschaften des Konnektors umfassen muss [TR-03154; TR-03155, Ab- schnitt 3.3.2]. Dieses Security Target ist konform zu diesen Anforderungen, vgl. Abschnitt 2.5. Dies sind – neben den TUCs für die Fachmodule (vgl. Abschnitt 8.2) – allgemeiner formulierte Funktiona- litäten. Die folgenden Unterabschnitte benennen diese Funktionalitäten und erklären, wie das Security Target die geforderten Eigenschaften sicherstellt. Konfigurationsparameter Der Basiskonnektor schützt die Konfigurationsparameter von Fachmodulen vor unbefugter Modifika- tion. Um dies sicherzustellen, setzt das Security Target folgende Maßnahme um: Die Sicherheitsfunk- tion SF.Administration/AK managt die Konfigurationsparameter der Fachmodule. Die Benutzung dieser Funktion wird in der Konnektor Security Guidance erklärt und dort durch Composition Requirements formalisiert [KoCo AGD_Kon-Sec]. Protokollierungsdienst Fachmodule können den Basiskonnektor aufrufen, um Log-Nachrichten zu persistieren. Jedes Fach- modul erhält einen eigenen Namensraum, sodass die Nachrichten pro Fachmodul separiert werden. Der Konnektor speichert die Lognachrichten in derselben Datenbank wie sein eigenes Log. Benutzer der Fachmodule können über die Funktionen der Managementschnittstelle das Log auslesen. Maßnah- men des Security Targets stellen sicher, dass die Anforderungen der Fachmodule an den Konnektor umgesetzt werden: 139 • ST-Anwendungshinweis 53 zu FAU_STG.4/AK präzisiert die Behandlung des Parameters FM__LOG_DAYS, der vorgibt, wie lange die Mindestdauer für das Vorhalten von Protokollein- trägen ist [gemSpec_Kon, TAB_KON_609]. Die Konnektor Security Guidance definiert das Com- position Requirement COMP-REQ-7, das beschreibt, wie der Entwickler der Fachmodule mit Kon- figurationsdaten umgehen muss. • Die Zuweisung an FAU_GEN.1.1/AK sichert zu, dass die Security-relevanten Ereignisse des Fach- moduls vom Protokollierungsdienst des Konnektors erfasst und behandelt werden. Signaturdienst (nur für NFDM) Fachmodule können den Signaturdienst des Basiskonnektors nutzen, um QES-Prüfungen von XML- detached Signaturen durchzuführen. Das Security Target stellt dies sicher durch die SFR in Ab- schnitt 6.3.3.4, insbesondere FDP_DAU.2.2/AK.QES(1), (2), (4), (5). Gültigkeitsprüfung der eGK Der Basiskonnektor prüft die Gültigkeit einer eGK. Dies wird erreicht durch die Erfüllung der Sicher- heitsanforderung FPT_TEE.1/AK. Die Erläuterung des Sicherheitsziels O.AK.Chipkartendienst im Schutz- profil präzisiert dieses SFR [BSI-CC-PP-0098, S. 316] und macht deutlich, welche Aspekte des SFR hier einschlägig sind. Die Sicherheitsfunktionalität SF.SmartCardMgmt setzt das SFR um (vgl. Ab- schnitt 7.2.6). Transportsicherung zwischen Konnektor und Clientsystem Der Konnektor sichert die Verbindungen zu den Clientsystemen durch TLS ab1. Dies wird auf zwei Ebenen erreicht: • Die Sicherheitsfunktionalität SF.CryptographicServices/NK und die damit assoziierten SFR FTP_ITC.1/NK.TLS, FPT_TDC.1/NK.TLS.Zert, 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.1/NK.Zert, FDP_ITC.2/NK.TLS und FDP_ETC.2/NK.TLS stellen die kryptographischen Eigenschaften der TLS-Verbindungen bereit. • Die Sicherheitsfunktionalität SF.TLS managt die Verwendung der TLS-Verbindungen und re- agiert auf die entsprechenden Konfigurationsparameter (vgl. Abschnitt 7.2.2). Zusätzlich trägt FMT_MOF.1/NK.TLS auch noch Anforderungen an das Management von TLS-Verbindungen bei. Auslesbarkeit der Version des Konnektors Die Technischen Richtlinien fordern ein „auslesbare, eindeutige Version des Konnektors sowie des Fachmoduls“. Die Auslesbarkeit ist gegeben über die Managementschnittstelle des TOE. Die Details sind dem Administratorhandbuch zu entnehmen [KoCo AGD_ADM, Abschnitte 7.4.1, 7.7.3, 7.7.4]. 8.2. Umsetzung der TUCs an LS.FM im Basiskonnektor Die Technischen Richtlinien fordern die Umsetzung von TUCs aus der Konnektor Spezifikation [gem- Spec_Kon]. Tabelle 8.1 zeigt, welche SFR des Konnektors welchen TUC umsetzen und welches der Fachmodule die TUCs nutzt. Dies geschieht hier bewusst auf einer abstrakten Ebene. Tabelle 8.2 geht genauer auf die API-Funktionen ein. 1 Die Verwendung von TLS für die Verbindung zu den Clientsystemen kann abgeschaltet werden. In diesem Fall geht die Verantwortlichkeit für die Sicherstellung der Vertraulichkeit, der Integrität und der Authentizität auf den Leistungser- bringer über, vgl. [KoCo AGD_ADM, Abschnitt 7.5.1, S. 88ff]. 140 TUC Beschreibung SFR N F D M A M T S TUC_KON_000 Prüfe Zugriffsberechtigung FDP_ACC.1/AK.Infomod, FDP_ACF.1/AK.Infomod X X TUC_KON_080 Dokument validieren (wird implizit aufgerufen) FDP_ITC.2/AK.Sig, FMT_MSA.1/AK.User X . TUC_KON_005 Card-to-Card authentisieren FDP_ACC.1/AK.KD, FDP_ACF.1/AK.KD, FIA_UAU.5/AK, FMT_MTD.1.1/AK.Zert, FMT_MTD.1/AK.Zert X X TUC_KON_006 Datenzugriffsaudit eGK schreiben FDP_ACC.1/AK.KD, FDP_ACF.1/AK.KD X X TUC_KON_012 PIN verifizieren FDP_ACC.1/AK.PIN, FDP_ACF.1/AK.PIN X X TUC_KON_018 eGK-Sperrung prüfen FPT_TEE.1/AK X X TUC_KON_022 Liefere PIN-Status FDP_ACC.1/AK.KD, FDP_ACF.1/AK.KD X X TUC_KON_026 Liefere CardSession FDP_ACC.1/AK.Infomod, FDP_ACC.1/AK.KD, FDP_ACF.1/AK.KD, FDP_ACF.1/AK.Infomod X X TUC_KON_036 Liefere Fachliche Rolle FDP_ACC.1/AK.KD, FDP_ACF.1/AK.KD X X TUC_KON_202 Lese Datei FDP_ACC.1/AK.KD, FDP_ACF.1/AK.KD X X TUC_KON_203 Schreibe Datei FDP_ACC.1/AK.KD, FDP_ACF.1/AK.KD X X TUC_KON_204 Lösche Datei Inhalt FDP_ACC.1/AK.KD, FDP_ACF.1/AK.KD X X TUC_KON_051 Mit Anwender über Kartenterminal interagieren FDP_ACC.1/AK.eHKT, FDP_ACF.1/AK.eHKT X X TUC_KON_151 QES-Dokumentensignatur prüfen FDP_ACC.1/AK.SigPr, FDP_ACF.1/AK.SigPr, FDP_DAU.2/AK.QES X . TUC_KON_162 Kryptographische Prüfung der XML-Dokumentensignatur FCS_COP.1/AK.XML.SigPr X . TUC_KON_254 Liefere Ressourcendetails FDP_ACC.1/AK.Infomod, FDP_ACF.1/AK.Infomod X X TUC_KON_271 Schreibe Protokolleintrag FAU_GEN.1/NK.SecLog X X TUC_KON_351 Liefere Systemzeit FPT_STM.1/AK, FPT_STM.1/NK X X TUC_KON_034 Zertifikatsinformationen extrahieren FDP_ACC.1/AK.KD, FDP_ACF.1/AK.KD X . Tabelle 8.1.: Umsetzung der TUCs für Fachmodule 141 Die gematik Spezifikation für den Konnektor [gemSpec_Kon] regelt, welche TUCs der Basiskon- nektor den Fachmodulen zur Verfügung stellen muss. Tabelle 8.2 führt diese TUCs auf und bildet sie auf die Funktionen der Schnittstelle LS.FM.RMI ab. Anmerkungen zur Tabelle Folgende Punkte müssen bei der Interpretation der Tabelle in Betracht gezogen werden. • Nicht alle von der Spezifikation genannnten TUCs werden in der gegenwärtigen Version des Konnektors für die Fachmodule angeboten. TUCs, bei denen die Felder „Java-Interface“ und „Methode“ nicht befüllt sind („—“), können nicht von den Fachmodulen aufgerufen werden. • Über die von der Spezifikation geforderten TUCs hinaus gibt es Funktionen, die Fachmodu- le am Basiskonnektor aufrufen können. Solche Funktionen sind in der Spalte „TUC“ mit „—“ gekennzeichnet. • Die Interfaces liegen im Package de.koco.konnektor.ndesign.rmi.api. • Die Tabelle bildet lediglich die TUCs auf Methodenaufrufe ab. Die Aufrufparameter der Java- Interfaces sind in der API dokumentiert. 142 Basisdienst TUC Name des TUC Interface Methode Zugriffsberechtigungs- dienst TUC_KON_000 Prüfe Zugriffsberechtigung IAccessAuthorizatonServiceRemote checkAccessAuthorization() Dienstverzeichnis- dienst TUC_KON_041 Einbringen der Endpunktinformationen wäh- rend der Bootup-Phase IFachmodulRegistrationRemote registerFM() Kartenterminaldienst TUC_KON_051 Mit Anwender über Kartenterminal interagie- ren ICardterminalInfoServiceRemote interact() TUC_KON_056 Karte anfordern CardTerminalServiceInternRemote karteAnfordern() TUC_KON_057 Karte auswerfen CardTerminalServiceInternRemote karteAuswerfen() Kartendienst TUC_KON_026 Liefere CardSession ICardServiceRemote deliverCardSession() TUC_KON_012 PIN verifizieren ICardServiceRemote verifyPin() TUC_KON_019 PIN ändern ICardServiceRemote changePin() TUC_KON_021 PIN entsperren ICardServiceRemote unblockPin() TUC_KON_022 Liefere PIN-Status ICardServiceRemote getPinStatus() TUC_KON_027 PIN-Schutz ein-/ausschalten ICardServiceRemote toggleVerificationRequirement() TUC_KON_023 Karte reservieren ICardServiceRemote reserveCard() TUC_KON_005 Card-to-Card authentisieren ICardServiceRemote cardToCard() TUC_KON_202 Lese Datei ICardServiceRemote readFile() TUC_KON_203 Schreibe Datei ICardServiceRemote writeFile() TUC_KON_204 Lösche Datei Inhalt ICardServiceRemote deleteFileContent() TUC_KON_209 Lese Record ICardServiceRemote readRecord() TUC_KON_210 Schreibe Record ICardServiceRemote writeRecord() TUC_KON_211 Lösche Record Inhalt ICardServiceRemote eraseRecord() TUC_KON_214 Füge Hinzu Record ICardServiceRemote addRecord() TUC_KON_215 Suche Record ICardServiceRemote searchRecord() TUC_KON_018 eGK-Sperrung prüfen ICardServiceRemote checkEGKLock() TUC_KON_006 Datenzugriffsaudit eGK schreiben ICardServiceRemote writeAccessAudit() TUC_KON_218 Signiere ICardServiceRemote signPKCS1V15() TUC_KON_218 Signiere ICardServiceRemote signPSS() Funktionen des Basiskonnektors für die Fachmodule 143 Basisdienst TUC Name des TUC Interface Methode TUC_KON_219 Entschlüssele ICardServiceRemote decrypt() TUC_KON_200 SendeAPDU ICardServiceRemote sendAPDU() TUC_KON_024 Karte zurücksetzen ICardServiceRemote resetCard() TUC_KON_216 Lese Zertifikat ICardServiceRemote readCertificate() TUC_KON_036 Liefere Fachliche Rolle ICardServiceRemote getProfessions() Systeminform.-dienst TUC_KON_256 Systemereignis absetzen INotificationRemote notify() TUC_KON_252 Liefere KT_Liste ISystemInformationServiceRemote getCardTerminalsFacade() TUC_KON_253 Liefere Karten_Liste ISystemInformationServiceRemote getCardsFacade() TUC_KON_254 Liefere Ressourcendetails ISystemInformationServiceRemote getResourceInformationFacade() Verschlüsselungsdienst TUC_KON_070 Daten hybrid verschlüsseln IEncryptionServiceRemote encryptDocument() TUC_KON_071 Daten hybrid entschlüsseln IEncryptionServiceRemote decryptDocument() TUC_KON_072 Daten symmetrisch verschlüsseln IEncryptionServiceRemote encryptDocument() TUC_KON_073 Daten symmetrisch entschlüsseln IEncryptionServiceRemote decryptDocument() Signaturdienst TUC_KON_160 Dokumente nonQES signieren ISignserviceRemote signNonQESDocument() TUC_KON_161 nonQES Dokumentsignatur prüfen ISignserviceRemote verifyDocument() TUC_KON_162 Kryptographische Prüfung der XML- Dokumentensignatur ISignserviceRemote verifyXMLDocumentSignature() TUC_KON_150 Dokument QES signieren ISignserviceRemote signQESDocument() TUC_KON_151 QES-Dokumentensignatur prüfen ISignserviceRemote verifyDocument() Zertifikatsdienst TUC_KON_037 Zertifikat prüfen ICertificateServiceRemote verifyCertificateX509NonQES() TUC_KON_037 Zertifikat prüfen ICertificateServiceQESRemote verifyCertificateX509QES() TUC_KON_042 CV-Zertifikat prüfen ICertificateServiceRemote verifyCertificate() TUC_KON_034 Zertifikatsinformationen extrahieren ICertificateServiceRemote extractCertificateInformation() TLS-Dienst TUC_KON_110 TLS-Verbindung aufbauen (kartenbas.) — — TUC_KON_111 Kartenbasierte TLS-Verbindung abbauen — — LDAP-Proxy TUC_KON_290 LDAP-Verbindung aufbauen — — Funktionen des Basiskonnektors für die Fachmodule 144 Basisdienst TUC Name des TUC Interface Methode TUC_KON_291 Verzeichnis abfragen — — TUC_KON_292 LDAP-Verbindung trennen — — TUC_KON_293 Verzeichnisabfrage abbrechen — — Protokollierungsdienst TUC_KON_271 Schreibe Protokolleintrag ILoggingServiceRemote log() — Auslesen der Log-Konfiguration ILoggingServiceRemote getConfiguration() — Schreiben der Log-Konfiguration ILoggingServiceRemote setConfiguration() Namensdienst TUC_KON_361 DNS-Namen auflösen IDNSServiceRemote resolveFQDN() TUC_KON_362 Liste der Dienste abrufen IDNSServiceRemote listServiceNames() TUC_KON_363 Dienstdetails abrufen IDNSServiceRemote listServiceDetails() Zeitdienst TUC_KON_351 Liefere Systemzeit INTPServiceRemote getSystemTime() StorageService — Löschen einer Datei IStorageServiceRemote deleteFile() — Verzeichnis lesen IStorageServiceRemote listFiles() — Datei lesen IStorageServiceRemote loadFile() — Objekt lesen IStorageServiceRemote loadObject() — Datei speichern IStorageServiceRemote storeFile() — Objekt speichern IStorageServiceRemote storeObject() Benachricht.-dienst — Versenden eines Events an den AK IEventhandlerRemote notify() — EventHandler registrieren IEventHandlerRegistrarRemote registerEventHandler() — EventHandler deregistrieren IEventHandlerRegistrarRemote unregisterEventHandler() Tabelle 8.2.: Funktionen des Basiskonnektors für die Fachmodule 145 A. Erklärung der tabellarischen Darstellung Tabelle A.1 zeigt die in den Tabellen dieses Dokuments verwendeten Symbole. Diese kommen in allen Tabellen zum Einsatz, in denen Entitäten der Common Criteria aufeinander abgebildet werden. Symbol Beschreibung X Vom Schutzprofil vorgesehene Beziehung / vorgesehenes SFR – Nicht umgesetzte, vom Schutzprofil als optional vorgesehene Beziehung / vorgesehenes SFR X Vom Security Target zusätzlich angenommene Beziehung / zu- sätzlich angenommenes SFR Tabelle A.1.: Legende der Abbildungstabellen 146 B. TLS Verbindungen Für die TLS-Verbindungen werden die im Schutzprofil und der gematik-Spezifikation [gem- Spec_Krypt, Abschnitt 3.3.2] genannten Cipher Suiten verwendet. Der TOE beherrscht genau diese Cipher Suiten und keine darüber hinaus. Tabelle B.1 listet diese Cipher Suiten auf. Tabelle B.2 zeigt die elliptischen Kurven, die beim ECDHE Schlüsselaustausch zur Anwendung kommen. Algorithmen / Cipher Suite IANA ID TLS 1.2 [RFC 5246] TLS_DHE_RSA_WITH_AES_128_CBC_SHA 0x00, 0x33 X TLS_DHE_RSA_WITH_AES_256_CBC_SHA 0x00, 0x39 X TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 0xc0, 0x13 X TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 0xc0, 0x14 X TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 0xc0, 0x27 X TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 0xc0, 0x28 X TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 0xc0, 0x2f X TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 0xc0, 0x30 X Tabelle B.1.: Cipher Suites der TLS Verbindungen des Konnektors Elliptische Kurve IANA ID Standard secp256r1 (P-256) 23 [RFC 8422; ANSI X9.62] secp384r1 (P-384) 24 [RFC 8422; ANSI X9.62] brainpoolP256r1 26 [RFC 7027] brainpoolP384r1 27 [RFC 7027] Tabelle B.2.: Elliptische Kurven für die TLS Verbindungen des Konnektors Der TOE kommuniziert mit anderen vertrauenswürdigen IT-Produkten über gesicherte Verbindun- gen. Die Integrität und die Vertrauenswürdigkeit der Verbindungen wird durch die Verwendung von TLS in der Version 1.2 und die in Tabelle B.1 genannten Algorithmen und Cipher Suiten sichergestellt. Tabelle B.4 listet die Verbindungen auf, die der Konnektor eingeht. Die Spalten dieser Tabelle werden in Tabelle B.3 beschrieben. 147 Spalte Beschreibung ID Symbolischer Name der Verbindung Schnittstelle Logische Schnittstelle, deren Kommunikation abge- sichert wird. Rolle Beschreibt, ob der Konnektor in dieser Verbindung Client oder Server ist. Peer Beschreibung des Partners in der TLS-Verbindung Protokoll Anwendungsprotokoll, das für die Verbindung ge- nutzt wird. Subsystem::Modul Name des Subsystems und des Moduls, von dem die Verbindung ausgeht, bzw. das die Verbindung emp- fängt und behandelt. Port Port, den der TOE öffnet, um die Verbindung auf- zubauen. Für Verbindungen, bei denen der Konnek- tor Server ist, steht hier eine Portnummer. Wenn der TOE Client ist, steht „dyn.“ für die ephemerische Portvergabe bei TCP-Verbindungen. „konfig.“ steht dafür, dass der Zielport konfigurierbar ist. Schnittstelle Logische Schnittstelle des TOE , über die die Verbin- dung läuft. Identität des TOE Zertifikat, mit dem sich der TOE gegenüber dem Peer authentisiert. Identität des Peer Zertifikat/Verfahren, mit dem sich der Peer gegen- über dem TOE authentisiert. Authentifizierung des Peer durch Verfahren, Datenquelle oder Subsystem/Modul, mit dem der TOE die Identität des Peers verifiziert. Tabelle B.3.: Legende zu den TLS Verbindungen 148 ID Schnittstelle (Proto- koll) Rolle Peer Subsystem::Modul Port Identität des TOE Identität des Peer Authentifizierung des Peer durch TLS.1 LS.LAN.HTTP_MGMT Server Browser Facade::Jetty-Configu- ration 9443 gSMC-K#2: EF.C.AK.AUT.R2048 Benutzername/Pass- wort Benutzerverwaltung im TOE TLS.2 LS.LAN.SOAP Server Clientsystem Facade::Jetty-Configu- ration 443 gSMC-K#2: EF.C.AK.AUT.R2048 X.509 Zertifikate server_truststore.jks TLS.3 LS.LAN.SOAP Server Clientsystem Facade::Jetty-Configu- ration 443 gSMC-K#2: EF.C.AK.AUT.R2048 HTTP Basic Authen- tication Clientsystemverwal- tung im TOE TLS.4 LS.LAN.LDAP Server Clientsystem LDAPProxy::Core 636 gSMC-K#2: EF.C.AK.AUT.R2048 X.509 Zertifikate server_truststore.jks TLS.5 LS.LAN.CETP Client Clientsystem SystemInformation- Service::Core konfig. gSMC-K#2: EF.C.AK.AUT.R2048 X509 Zertifikate server_truststore.jks TLS.6 LS.LAN.SICCT Client eHealth Karten- terminal CardService::de.nde- sign.koco.ifd.sicct 4742 gSMC-K#2: EF.C.SAK.AUT.R2048 SMC-KT: ID.SMKT.AUT CertificateService::Core TLS.7 LS.WAN.SOAP Client Registrierungs- dienst AdminService::Regis- trationService 8443 SMC-B: EF.C.HCI.AUT.R2048 C.ZD.TLS-S, 1.2.276.0.76.4.161 CertificateService::Core TLS.8 LS.VPN_TI.LDAP Client Verzeichnis- dienst LDAPProxy::Core Dyn. n/a C.ZD.TLS-S, 1.2.276.0.76.4.171 CertificateService::Core TLS.9 LS.VPN_TI.HTTP Client BNetzAVL- Downloaddienst CertificateService::- BNetzAVLService Dyn. n/a C.ZD.TLS-S, 1.2.276.0.76.4.189 CertificateService::Core TLS.10 LS.VPN_TI.SOAP Client Intermediär VSDM FM_VSDM::TLS Dyn. SMC-B: EF.C.HCI.AUT.R2048 C.FD.TLS-S, 1.2.276.0.76.4.159 CertificateService::Core TLS.11 LS.VPN_TI.HTTP Client KSR Update Server AdminService::- KSR_CS_Core Dyn. n/a C.ZD.TLS-S, 1.2.276.0.76.4.160 CertificateService::Core Tabelle B.4.: TLS Verbindungen der KoCoBox MED+ 149 C. Composition Requirements für Fachmodule Fachmodule unterliegen im Konnektor Restriktionen und Auflagen. Diese werden in der Konnektor Security Guidance beschrieben [KoCo AGD_Kon-Sec]. Die dort beschriebenen Composition Requi- rements müssen vom Entwickler eines Fachmoduls eingehalten werden, um die Funktionsfähigkeit des Gesamtkonnektors nicht zu gefährden. Zur besseren Lesbarkeit werden die Composition Requirements hier wiederholt1. Einen präziseren Einblick mit mehr Erklärungen liefert die Konnektor Security Gui- dance. COMP-REQ-1 Korrekte Benutzung des Konnektors Das Fachmodul MUSS den Basiskonnektor entsprechend der vorliegenden Dokumentation und der Spezifikation der gematik benutzen. Das Fachmodul DARF NICHT die Sicherheitsfunktionen des Konnektors beeinträchtigen oder missbrauchen. COMP-REQ-2 Auslieferungsformat Das Fachmodul MUSS als Web-Anwendung entwickelt und als Web Application Archive ausgeliefert werden. COMP-REQ-3 Registrierung am Basiskonnektor Das Fachmodul MUSS sich gemäß TUC_KON_041 mit IFachmodulRegistration- Remote.registerFM() am Basiskonnektor registrieren. COMP-REQ-4 Signaturrichtlinien Das Fachmodul KANN während der Registrierung eigene Signaturrichtlinien in den Basiskonnektor einbringen. Das Fachmodul DARF NICHT andere Signaturrichtlinien verwenden. COMP-REQ-5 Aufrufe des Basiskonnektors Das Fachmodul KANN die in Tabelle 8.2 angegebenen Aufrufe des Basiskonnektors verwenden. Das Fachmodul MUSS die Schnittstelle LS.FM.RMI gemäß der Dokumentation der Java-API verwenden. Das Fachmodul DARF NICHT andere Funktionen des Basiskonnektors aufrufen. COMP-REQ-6 Separation der Bibliotheken Das Fachmodul MUSS Bibliotheken aus seinem eigenen Class-Loader verwenden. Es DARF NICHT auf die Bibliotheken und Klassen im Class-Loader anderer Fachmodule zugreifen. COMP-REQ-7 Konfigurationsparameter für Logging Das Fachmodul KANN während der Registrierung Konfigurationsfelder für Loggingparameter an den Basiskonnektor übergeben. Das Fachmodul MUSS die Konfigurationsparameter mit der Funktion ILoggingServiceRe- mote.setConfiguration() des Basiskonnektors persistieren. 1 Referenzen werden angepasst, um auf das Security Target statt auf die Konnektor Security Guidance zu verweisen. 150 COMP-REQ-8 Konfigurationsparameter Das Fachmodul KANN während der Registrierung Konfigurationsfelder für Konfigurationsparameter an den Basiskonnektor übergeben. Vom Basiskonnektor an das Fachmodul übergebene Konfigurationswerte MUSS das Fachmodul ge- mäß den Vorgaben der entsprechenden Spezifikation prüfen. Das Fachmodul MUSS die geprüften Konfigurationsparameter mit Funktionsaufrufen des Basiskonnektors persistieren. COMP-REQ-9 Logging Das Fachmodul KANN Meldungen in das Fachmodulprotokoll des Konnektors schreiben. Dafür MUSS sich das Fachmodul beim Basiskonnektor authentisieren. COMP-REQ-10 gematik Schnittstellendefinitionen Das Fachmodul KANN die Schnittstellendefinitionsdateien der gematik, die der Basiskonnektor be- reitstellt, verwenden. COMP-REQ-11 Keine Außenschnittstellen Das Fachmodul DARF NICHT eigene Außenschnittstellen anbieten. Es MUSS zur Kommunktion mit den Clientsystemen SOAP-Verbindungen nutzen, die vom Proxy-Server des Basiskonnektors vermittelt werden. COMP-REQ-12 Validierung der Eingabedaten Das Fachmodul MUSS die vom Basiskonnektor übergebenen Eingabedaten selbst prüfen und validie- ren, um sich vor Angriffen von Clientsystemen zu schützen. COMP-REQ-13 Verbindungen zu Drittsystemen Das Fachmodul in der Ausbaustufe OPB 2.1 DARF NICHT unkontrollierte Verbindungen zu Dritt- systemen aufbauen. 151 D. Anforderungen zur sicherheitstechnischen Eignung in Abschnitt 3.2.1 des Produkttypsteckbrief Konnektor listet die gematik Anforderungen zur sicherheits- technischen Eignung des Konnektors auf, die durch die CC-Evaluierung abgedeckt werden müssen. Im Folgenden werden die dort gelisteten Anforderungen auf die SFR des Schutzprofils abgebildet. Gege- benenfalls wird durch Erklärungen oder Refinements gezeigt, wie diese Relation interpretiert wird. Die gematik fordert den Hersteller dazu auf, die Teile des Security Targets zu markieren, bei de- nen das Security Target die Anforderungen der Schutzprofile [BSI-CC-PP-0097; BSI-CC-PP-0098] erweitert. Diese Erweiterungen sind notwendig, da das Schutzprofil nicht alle Anforderungen der ge- matik Spezifikation abdeckt. Sie beziehen sich explizit auf die Differenz zwischen den Anforderungen aus dem Produkttypsteckbrief PTV2 [gemProdT_Kon_PTV2] und dem Produkttypsteckbrief PTV3 [gemProdT_Kon_PTV3_3.6.0-2]. Diese Differenz besteht aus 14 SFR, die – der besseren Übersicht- lichkeit halber – in Tabelle D.1 aufgeführt werden, bevor in den Folgeabschnitten auf die einzelnen SFR aus PTV3 eingegangen wird. Anforderung SFR Ergänzende Kommentare in TIP1-A_4710 FAU_GEN.1/AK ST-Anwendungshinweis 52 TIP1-A_5482 FPT_TDC.1/AK ST-Anwendungshinweis 50 TIP1-A_5484 FDP_ACF.1/AK.SDS ST-Anwendungshinweis 39 TIP1-A_5486 FDP_ACC.1/AK.PIN, FDP_ACF.1/AK.KD (Umgesetzt durch PP-Anpassung) TIP1-A_5505 FDP_DAU.2/AK.QES, FDP_DAU.2/AK.Sig SF.SignatureService (Abschnitt 7.2.7) TIP1-A_5538 FPT_TDC.1.2/AK, FDP_ITC.2/AK.Sig SF.SignatureService (Abschnitt 7.2.7) TIP1-A_6025 FDP_ACF.1/AK.Update, FPT_FLS.1/AK ST-Anwendungshinweis 29 TIP1-A_7254 FTP_ITC.1.1/AK.FD, FTP_ITC.1.1/AK.VZD ST-Anwendungshinweise 37, 38 TIP1-A_7255 FMT_MTD.1/AK.Admin ST-Anwendungshinweis 48 TIP1-A_7277 — Optionale Funktionalität entfällt. TIP1-A_7278 — Optionale Funktionalität entfällt. TIP1-A_7279 — Optionale Funktionalität entfällt. TIP1-A_7280 — Optionale Funktionalität entfällt. GS-A_5484 FTP_ITC.1/AK.TSL, FPT_TDC.1/AK (Umgesetzt durch PP-Anpassung) Tabelle D.1.: Erweiterung des ST durch neue Anforderungen aus PTV3 TIP1-A_4710 Protokollierung personenbezogener und medizinischer Daten Die Anforderung TIP1-A_4710 wird erfüllt durch: FAU_GEN.1/AK und die Präzisierung in Anwen- dungshinweis 203 des Schutzprofils. TIP1-A_5482 TUC_KON_042 „CV-Zertifikat prüfen“ Die Anforderung TIP1-A_5482 wird erfüllt durch: FPT_TDC.1/AK 152 TIP1-A_5484 Persistente Speicherung von Konfigurationsdaten der Fachmodule Die Anforderung TIP1-A_5484 wird erfüllt durch: FDP_ACF.1/AK.SDS, vgl. auch die Konnektor Se- curity Guidance [KoCo AGD_Kon-Sec, Abschnitt 3.4]. TIP1-A_5486 TUC_KON_027 „PIN-Schutz ein-/ausschalten“ Die Anforderung TIP1-A_5486 wird erfüllt durch: FDP_ACC.1/AK.PIN, FDP_ACF.1/AK.KD TIP1-A_5505 TUC_KON_162 „Kryptographische Prüfung der XML-Dokumentensignatur“ Die Anforderung TIP1-A_5505 wird erfüllt durch: FDP_DAU.2/AK.QES, FDP_DAU.2/AK.Sig TIP1-A_5538 Signaturrichtlinien bei QES für XML-Dokumentenformate Die Anforderung wird durch den neu eingefügten Unterpunkt (7) zu FDP_DAU.2/AK.QES umge- setzt. TIP1-A_6025 Zugang zur TI sperren, wenn Deadline für kritische FW- Updates erreicht Die Anforderung TIP1-A_6025 wird erfüllt durch: FDP_ACF.1/AK.Update, FPT_FLS.1/AK. Das Refine- ment in FDP_ACF.1.4/AK.Update nimmt konkreten Bezug auf die Anforderung TIP1-A_6025. TIP1-A_7255 Anzeige von Fachmodulversionen Die Anforderung wird durch das Refinement an FMT_MTD.1.1/AK.Admin umgesetzt. Das Refine- ment fordert, dass die Versionsinformation eines Fachmoduls vom Administrator einsehbar ist. GS-A_5484 TUC_PKI_036 „BNetzA-VL-Aktualisierung“ Die Anforderung GS-A_5484 wird erfüllt durch: FTP_ITC.1/AK.TSL, FPT_TDC.1/AK 153 Literatur Schutzprofile und Technische Richtlinien [BSI-CC-PP-0082-2] Bundesamt für Sicherheit in der Informationstechnik. Card Ope- rating System Generation 2 (PP COS GEN2). BSI-CC-PP-0082. Common Criteria Schutzprofil (Protection Profile). Version 1.9. Bundesamt für Sicherheit in der Informationstechnik (BSI), 18. Nov. 2014. [BSI-CC-PP-0097] Bundesamt für Sicherheit in der Informationstechnik. Schutzprofil 1: Anforderungen an den Netzkonnektor. BSI-CC-PP-0097. Com- mon Criteria Schutzprofil (Protection Profile). Version 1.6.4. Bun- desamt für Sicherheit in der Informationstechnik (BSI), 17. März 2020. [BSI-CC-PP-0098] Bundesamt für Sicherheit in der Informationstechnik. Schutzpro- fil 2: Anforderungen an den Konnektor. BSI-CC-PP-0098. Com- mon Criteria Schutzprofil (Protection Profile). Version 1.5.4. Bun- desamt für Sicherheit in der Informationstechnik (BSI), 17. März 2020. [TR-03116-1] Bundesamt für Sicherheit in der Informationstechnik. Kryptogra- phische Vorgaben für Projekte der Bundesregierung. Teil 1: Tele- matikinfrastruktur. Technische Richtlinie BSI TR-03116-1. Tech- nical Guideline. Version 3.20. Bundesamt für Sicherheit in der In- formationstechnik (BSI), 21. Sep. 2018. url: https://www.bsi. bund . de / DE / Publikationen / TechnischeRichtlinien / tr03116/index_htm.html. [TR-03154] Bundesamt für Sicherheit in der Informationstechnik. Konnektor – Prüfspezifikation für das Fachmodul NFDM. Technische Richtli- nie BSI TR-03154. Technical Guideline. Version 1.1. Bundesamt für Sicherheit in der Informationstechnik (BSI), 15. Apr. 2019. [TR-03155] Bundesamt für Sicherheit in der Informationstechnik. Konnektor – Prüfspezifikation für das Fachmodul AMTS. Technische Richtlinie BSI TR-03155. Technical Guideline. Version 1.1. Bundesamt für Sicherheit in der Informationstechnik (BSI), 15. Apr. 2019. Herstellerdokumente [KoCo AGD_ADM-Erg] KoCo Connector GmbH. Ergänzungen zum Administratorhand- buch KoCoBox MED+ Version 2.x. Common Criteria Komponen- 154 te AGD_ADM. Version 1.1.1. Vorgelegt im Verfahren BSI-DSC- CC-1068 zu BSI-CC-PP-0098. 2020. [KoCo AGD_ADM] KoCo Connector GmbH. Administratorhandbuch KoCo- Box MED+ Version 2.3. Common Criteria Komponente AGD_ADM. Version 2.3. Vorgelegt im Verfahren BSI-DSC- CC-1068 zu BSI-CC-PP-0098. 14. Juli 2020. [KoCo AGD_JSON] KoCo Connector GmbH. JSON-Managementschnittstelle der Ko- CoBox MED+. Dokumentation. Version 2.22. Vorgelegt im Ver- fahren BSI-DSC-CC-1068 zu BSI-CC-PP-0098. 2020. [KoCo AGD_Kon-Sec] KoCo Connector GmbH. KoCoBox MED+ OPB 2.1 Konnektor. Konnektor Security Guidance Fachmodule NFDM und AMTS. Pro- grammierrichtlinien für die Entwickler von Fachmodulen. Vor- gelegt im Verfahren BSI-DSC-CC-1068 zu BSI-CC-PP-0098. 2020. [KoCo ALC_DEL] KoCo Connector GmbH. KoCoBox MED+ OPB 2.1 Konnektor. Delivery Procedures (ALC_DEL). Common Criteria Komponente ALC_DEL. Version 1.1.9. Vorgelegt im Verfahren BSI-DSC-CC- 1068 zu BSI-CC-PP-0098. 2020. [KoCo ASE_ST-97] KoCo Connector GmbH. KoCoBox MED+ Netzkonnektor. Securi- ty Target. Common Criteria Komponente ASE_ST. Vorgelegt im Verfahren BSI-DSC-CC-1067 zu BSI-CC-PP-0097. 2020. [KoCo ASE_ST-98] KoCo Connector GmbH. KoCoBox MED+ OPB 2.1 Konnektor. Security Target. Common Criteria Komponente ASE_ST. Vor- gelegt im Verfahren BSI-DSC-CC-1068 zu BSI-CC-PP-0098. 2020. [KoCo FM-API] KoCo Connector GmbH. KoCoBox MED+ OPB 2.1 Konnektor. Konnektor API für Fachmodule Javadoc. Common Criteria Kom- ponente AGD. Vorgelegt im Verfahren BSI-DSC-CC-1068 zu BSI-CC-PP-0098. 2020. Spezifikationen [CAdES-BL] European Telecommunications Standards Institute. Electronic Si- gnatures and Infrastructures (ESI). CAdES Baseline Profile. ETSI Technical Specification. Version 2.1.1. ETSI, März 2012. url: https : / / www . etsi . org / deliver / etsi _ ts / 103100 _ 103199/103173/02.01.01_60/ts_103173v020101p.pdf. [CAdES] European Telecommunications Standards Institute. Electronic Si- gnatures and Infrastructures (ESI). CMS Advanced Electronic Si- gnatures (CAdES). ETSI Technical Specification. Version 2.2.1. ETSI, Apr. 2013. url: http : / / www . etsi . org / deliver / etsi _ ts / 101700 _ 101799 / 101733 / 02 . 02 . 01 _ 60 / ts _ 101733v020201p.pdf. 155 [PAdES-BL] European Telecommunications Standards Institute. Electronic Si- gnatures and Infrastructures (ESI). PAdES Baseline Profile. ETSI Technical Specification. Version 2.2.2. ETSI, Apr. 2013. url: http://www.etsi.org/deliver/etsi_ts/103100_103199/ 103172/02.02.02_60/ts_103172v020202p.pdf. [PAdES] European Telecommunications Standards Institute. Electronic Si- gnatures and Infrastructures (ESI). PDF Advanced Electronic Signature Profiles. Part 3: PAdES Enhanced – PAdES-BES and PAdES-EPES Profiles. ETSI Technical Specification. Ver- sion 1.2.1. ETSI, Juli 2010. url: http : / / www . etsi . org / deliver/etsi_ts/102700_102799/10277803/01.02.01_ 60/ts_10277803v010201p.pdf. [TIFF] Adobe Developers Association, Hrsg. TIFF. Revision 6.0. Versi- on 6.0. 3. Juni 1992. url: https://www.adobe.io/open/ standards/TIFF.html. [XAdES-BL] European Telecommunications Standards Institute. Electronic Si- gnatures and Infrastructures (ESI). XAdES Baseline Profile. ETSI Technical Specification. Version 2.1.1. ETSI, März 2012. url: http://www.etsi.org/deliver/etsi_ts/103100_103199/ 103171/02.01.01_60/ts_103171v020101p.pdf. [XAdES] European Telecommunications Standards Institute. Electronic Si- gnatures and Infrastructures (ESI). XML Advanced Electronic Si- gnatures (XAdES). ETSI Technical Specification. Version 1.4.2. ETSI, Dez. 2010. url: http : / / www . etsi . org / deliver / etsi _ ts / 101900 _ 101999 / 101903 / 01 . 04 . 02 _ 60 / ts _ 101903v010402p.pdf. [XML] Tim Bray u. a. Extensible Markup Language (XML). W3C Recom- mendation. http://www.w3.org/TR/xml. W3C, Nov. 2008. [XMLEnc] Frederick Hirsch u. a. XML Encryption Syntax and Proces- sing Version 1.1. W3C Recommendation. http://www.w3.org/- TR/2013/REC-xmlenc-core1-20130411/. W3C, Apr. 2013. [XSLT] Michael Kay. XSL Transformations (XSLT). W3C Recommen- dation. Version 2.0. http://www.w3.org/TR/2007/REC-xslt20- 20070123/. W3C, Jan. 2007. gematik Spezifikationen [gemErrata_1_Kon_PTV3] gematik GmbH. Errata 1 zum Konnektor PTV 3 (eMP/AMTS, NFDM). Version 1.0.1., 6. Feb. 2019. [gemErrata_2_Kon_PTV3] gematik GmbH. Errata 2 zum Konnektor PTV 3 (eMP/AMTS, NFDM). Version 1.0.0., 6. Juni 2019. [gemErrata_3_Kon_PTV3] gematik GmbH. Errata 3 zum Konnektor PTV 3 (eMP/AMTS, NFDM). Version 1.0.0., 2. Okt. 2019. 156 [gemErrata_4_Kon_PTV3] gematik GmbH. Errata 4 zum Konnektor PTV 3 (eMP/AMTS, NFDM). Version 1.0.1., 27. Nov. 2019. [gemErrata_5_Kon_PTV3] gematik GmbH. Errata 5 zum Konnektor PTV 3 (eMP/AMTS, NFDM). Version 1.0.0., 4. Feb. 2020. [gemErrata_6_Kon_PTV3] gematik GmbH. Errata 6 zum Konnektor PTV 3 (eMP/AMTS, NFDM). Version 1.0.0., 4. März 2020. [gemILF_PS] gematik GmbH. Implementierungsleitfaden Primärsysteme – Te- lematikinfrastruktur (TI). einschließlich VSDM, QES, KOM-LE. Version 2.3.0. Revision 55792., 26. Okt. 2018. [gemKPT_Arch] gematik GmbH. Konzept. Architektur der TI-Plattform. Versi- on 2.5.0. Revision 58160., 26. Okt. 2018. [gemProdT_Kon_PTV2] gematik GmbH. Produkttypsteckbrief Konnektor. Prüfvorschrift. Produkttyp Version PTV2 2.12.0-0. Version 1.0.0., 14. Mai 2018. [gemProdT_Kon_PTV3_3.6.0-2] gematik GmbH. Produkttypsteckbrief Konnektor. Prüfvorschrift. Produkttyp Version PTV3 3.6.0-2. Version 1.0.0. Revisi- on 61976., 4. März 2020. [gemRL_QES_NFDM] gematik GmbH. Signaturrichtlinie QES. Notfalldaten-Management (NFDM). Version 1.4.0. Revision 17752., 28. Juni 2019. [gemSpec_COS] gematik GmbH. Spezifikation des Card Operating System (COS). Version 3.11.0., 14. Mai 2018. [gemSpec_FM_AMTS] gematik GmbH. Spezifikation Fachmodul AMTS. Version 1.3.0. Revision 57164., 26. Okt. 2018. [gemSpec_FM_NFDM] gematik GmbH. Spezifikation Fachmodul NFDM. Version 1.4.0. Revision 57194., 26. Okt. 2018. [gemSpec_HBA_ObjSys] gematik GmbH. Spezifikation des elektronischen Heilberufsauswei- ses HBA-Objektsystem. Version 3.11.0. Revision 19010., 14. Mai 2018. [gemSpec_Kon_TBAuth] gematik GmbH. Spezifikation Konnektor. Basisdienst Tokenbasier- te Authentisierung. Version 1.2.0. Revision 19021., 14. Mai 2018. [gemSpec_Kon] gematik GmbH. Spezifikation Konnektor. Version 5.4.0., 26. Okt. 2018. [gemSpec_Krypt] gematik GmbH. Übergreifende Spezifikation Verwendung kryp- tographischer Algorithmen in der Telematikinfrastruktur. Versi- on 2.11.0. Revision 58823., 29. Okt. 2018. [gemSpec_Net] gematik GmbH. Übergreifende Spezifikation Netzwerk. Versi- on 1.14.0. Revision 58088., 26. Okt. 2018. [gemSpec_PKI] gematik GmbH. Übergreifende Spezifikation PKI. Version 2.3.0. Revision 58259., 26. Okt. 2018. [gemSpec_SMC-B_ObjSys] gematik GmbH. Spezifikation der Security Module Card SMC-B Objektsystem. Version 3.11.0. Revision 19706., 26. Okt. 2018. 157 [gemWSDL] gematik GmbH. Schnittstellendefinitionen im XSD- und WSDL- Format. Gültig ab 01.01.2019. 2019. url: https : / / fachportal . gematik . de / fileadmin / user _ upload / fachportal/files/Spezifikationen/Produktivbetrieb/ Schemata_WDSL/OPB3.1_Schemadateien_R3.1.2_Kon_ PTV3_20191002.zip. Standards [ANSI X9.62] Accredited Standards Committee X9. ANSI X9.62, Public Key Cryptography For The Financial Services Industry: The Ellip- tic Curve Digital Signature Algorithm (ECDSA). Standard. ANSI, 16. Nov. 2005. [CC Part 2] The Common Criteria Recognition Agreement Members. Com- mon Criteria for Information Technology Security Evaluation. Part 2: Security functional components. Common Criteria. Ver- sion 3.1R5. Common Criteria Portal, Apr. 2017. url: http:// www.commoncriteriaportal.org/thecc.html. [CC Part 3] The Common Criteria Recognition Agreement Members. Com- mon Criteria for Information Technology Security Evaluation. Part 3: Security assurance components. Common Criteria. Versi- on 3.1R5. Common Criteria Portal, Apr. 2017. url: http:// www.commoncriteriaportal.org/thecc.html. [FIPS PUB 180-4] National Institute of Standards und Technology. Secure Hash Stan- dard (SHS). Federal Information Processing Standards Publicati- on. Information Technology Laboratory, Aug. 2015. url: http: //dx.doi.org/10.6028/NIST.FIPS.180-4. [FIPS PUB 186-2] National Institute of Standards und Technology. Digital Signa- ture Standard (DSS). Federal Information Processing Standards Publication. Information Technology Laboratory, Juli 2013. url: http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS. 186-4.pdf. [FIPS PUB 197] National Institute of Standards und Technology. Advanced En- cryption Standard (AES). Federal Information Processing Stan- dards Publication. Information Technology Laboratory, Nov. 2001. url: http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.197.pdf. [ISO 19005-1] ISO. Document management – Electronic document file format for long-term preservation. Part 1: Use of PDF 1.4 (PDF/A-1). Inter- national Standard. International Organization for Standardization, 28. Sep. 2005. 158 [ISO 19005] ISO. Document management – Electronic document file format for long-term preservation. International Standard. International Or- ganization for Standardization, 2005. [ISO 8859-15] ISO. Information technology – 8-bit single-byte coded graphic cha- racter sets. Part 15: Latin alphabet No. 9. International Standard. International Organization for Standardization, 12. Feb. 2004. [NIST SP 800-133] Elaine Barker und Allen Roginsky. Recommendation for Cryp- tographic Key Generation. NIST Special Publication 800-133. National Institute of Standards und Technology, Dez. 2012. url: https : / / nvlpubs . nist . gov / nistpubs / SpecialPublications/NIST.SP.800-133.pdf. [NIST SP 800-38A] Morris Dworkin. Recommendation for Block Cipher Modes of Operation. Methods and Techniques. NIST Special Publication 800-38A. National Institute of Standards und Technology, Dez. 2001. url: http://nvlpubs.nist.gov/nistpubs/Legacy/ SP/nistspecialpublication800-38a.pdf. [NIST SP 800-38D] Morris Dworkin. Recommendation for Block Cipher Modes of Operation. Galois/Counter Mode (GCM) and GMAC. NIST Special Publication 800-38D. National Institute of Standards und Techno- logy, Nov. 2007. url: http://nvlpubs.nist.gov/nistpubs/ Legacy/SP/nistspecialpublication800-38d.pdf. [NIST SP 800-90A] Elaine Barker und John Kelsey. Recommendation for Random Number Generation Using Deterministic Random Bit Generators. National Industrial Security Program Operating Manual. NIST Special Publication. Version Revision 1. National Institute of Stan- dards und Technology, Juni 2015. url: http://dx.doi.org/ 10.6028/NIST.SP.800-90Ar1. [Unicode] The Unicode Consortium. The Unicode Standard. Core Specificati- on. Version 6.2. Hrsg. von Julie D. Allen u. a. Mountain View, CA, 2012. ısbn: 978-1-936213-07-8. url: http://www.unicode. org/versions/Unicode6.2.0. RFC [RFC 2131] R. Droms. Dynamic Host Configuration Protocol. RFC 2131 (Draft Standard). RFC. Updated by RFCs 3396, 4361, 5494, 6842. Fremont, CA, USA: RFC Editor, März 1997. doı: 10 . 17487/RFC2131. url: https://www.rfc-editor.org/rfc/ rfc2131.txt. 159 [RFC 2132] S. Alexander und R. Droms. DHCP Options and BOOTP Vendor Extensions. RFC 2132 (Draft Standard). RFC. Updated by RFCs 3442, 3942, 4361, 4833, 5494. Fremont, CA, USA: RFC Editor, März 1997. doı: 10.17487/RFC2132. url: https://www.rfc- editor.org/rfc/rfc2132.txt. [RFC 2404] C. Madson und R. Glenn. The Use of HMAC-SHA-1-96 within ESP and AH. RFC 2404 (Proposed Standard). RFC. Fremont, CA, USA: RFC Editor, Nov. 1998. doı: 10.17487/RFC2404. url: https://www.rfc-editor.org/rfc/rfc2404.txt. [RFC 3526] T. Kivinen und M. Kojo. More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE). RFC 3526 (Proposed Standard). RFC. Fremont, CA, USA: RFC Editor, Mai 2003. doı: 10 . 17487 / RFC3526. url: https : / / www . rfc - editor.org/rfc/rfc3526.txt. [RFC 4035] R. Arends u. a. Protocol Modifications for the DNS Security Exten- sions. RFC 4035 (Proposed Standard). RFC. Updated by RFCs 4470, 6014, 6840. Fremont, CA, USA: RFC Editor, März 2005. doı: 10.17487/RFC4035. url: https://www.rfc-editor. org/rfc/rfc4035.txt. [RFC 4055] J. Schaad, B. Kaliski und R. Housley. Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Pu- blic Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 4055 (Proposed Standard). RFC. Updated by RFC 5756. Fremont, CA, USA: RFC Editor, Juni 2005. doı: 10.17487/RFC4055. url: https://www.rfc-editor.org/ rfc/rfc4055.txt. [RFC 4868] S. Kelly und S. Frankel. Using HMAC-SHA-256, HMAC-SHA- 384, and HMAC-SHA-512 with IPsec. RFC 4868 (Proposed Stan- dard). RFC. Fremont, CA, USA: RFC Editor, Mai 2007. doı: 10.17487/RFC4868. url: https://www.rfc-editor.org/ rfc/rfc4868.txt. [RFC 5246] T. Dierks und E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.2. RFC 5246 (Proposed Standard). RFC. Up- dated by RFCs 5746, 5878, 6176, 7465, 7507, 7568, 7627, 7685, 7905, 7919. Fremont, CA, USA: RFC Editor, Aug. 2008. doı: 10.17487/RFC5246. url: https://www.rfc-editor.org/ rfc/rfc5246.txt. [RFC 5280] D. Cooper u. a. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 5280 (Propo- sed Standard). RFC. Updated by RFC 6818. Fremont, CA, USA: RFC Editor, Mai 2008. doı: 10.17487/RFC5280. url: https: //www.rfc-editor.org/rfc/rfc5280.txt. 160 [RFC 5639] M. Lochter und J. Merkle. Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation. RFC 5639 (In- formational). RFC. Fremont, CA, USA: RFC Editor, März 2010. doı: 10.17487/RFC5639. url: https://www.rfc-editor. org/rfc/rfc5639.txt. [RFC 5652] R. Housley. Cryptographic Message Syntax (CMS). RFC 5652 (In- ternet Standard). RFC. Fremont, CA, USA: RFC Editor, Sep. 2009. doı: 10 . 17487 / RFC5652. url: https : / / www . rfc - editor.org/rfc/rfc5652.txt. [RFC 5746] E. Rescorla u. a. Transport Layer Security (TLS) Renegotiation In- dication Extension. RFC 5746 (Proposed Standard). RFC. Fre- mont, CA, USA: RFC Editor, Feb. 2010. doı: 10 . 17487 / RFC5746. url: https://www.rfc-editor.org/rfc/rfc5746. txt. [RFC 5751] B. Ramsdell und S. Turner. Secure/Multipurpose Internet Mail Ex- tensions (S/MIME) Version 3.2 Message Specification. RFC 5751 (Proposed Standard). RFC. Fremont, CA, USA: RFC Editor, Jan. 2010. doı: 10 . 17487 / RFC5751. url: https : / / www . rfc - editor.org/rfc/rfc5751.txt. [RFC 5905] D. Mills u. a. Network Time Protocol Version 4: Protocol and Al- gorithms Specification. RFC 5905 (Proposed Standard). RFC. Up- dated by RFC 7822. Fremont, CA, USA: RFC Editor, Juni 2010. doı: 10.17487/RFC5905. url: https://www.rfc-editor. org/rfc/rfc5905.txt. [RFC 7027] J. Merkle und M. Lochter. Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS). RFC 7027 (Informational). RFC. Fremont, CA, USA: RFC Editor, Okt. 2013. doı: 10 . 17487 / RFC7027. url: https : / / www . rfc - editor.org/rfc/rfc7027.txt. [RFC 7292] K. Moriarty u. a. PKCS #12: Personal Information Exchange Syn- tax v1.1. RFC 7292 (Informational). RFC. Fremont, CA, USA: RFC Editor, Juli 2014. doı: 10.17487/RFC7292. url: https: //www.rfc-editor.org/rfc/rfc7292.txt. [RFC 7296] C. Kaufman u. a. Internet Key Exchange Protocol Version 2 (IKEv2). RFC 7296 (Internet Standard). RFC. Updated by RFCs 7427, 7670. Fremont, CA, USA: RFC Editor, Okt. 2014. doı: 10.17487/RFC7296. url: https://www.rfc-editor.org/ rfc/rfc7296.txt. [RFC 8017] K. Moriarty (Ed.) u. a. PKCS #1: RSA Cryptography Specificati- ons Version 2.2. RFC 8017 (Informational). RFC. Fremont, CA, USA: RFC Editor, Nov. 2016. doı: 10.17487/RFC8017. url: https://www.rfc-editor.org/rfc/rfc8017.txt. 161 [RFC 8422] Y. Nir, S. Josefsson und M. Pegourie-Gonnard. Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier. RFC 8422 (Proposed Standard). RFC. Fremont, CA, USA: RFC Editor, Aug. 2018. doı: 10 . 17487/RFC8422. url: https://www.rfc-editor.org/rfc/ rfc8422.txt. Andere [BÄK-DV] Bundesärztekammer. „Empfehlungen zur ärztlichen Schweige- pflicht, Datenschutz und Datenverarbeitung in der Arztpraxis“. In: Deutsches Ärzteblatt 111.21 (23. Mai 2014). url: http : / / www . bundesaerztekammer . de / fileadmin / user _ upload/downloads/Schweigepflicht_2014.pdf (besucht am 04. 07. 2017). [BSI-GS] Bundesamt für Sicherheit in der Informationstechnik. IT- Grundschutz-Kataloge. 2017. url: https://www.bsi.bund. de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/ itgrundschutzkataloge_node.html. [ESSIV] Clemens Fruwirth. New Methods in Hard Disk Encryption. 18. Ju- li 2005. url: http : / / clemens . endorphin . org / nmihde / nmihde-A4-os.pdf. [RUB-XML] Meiko Jensen u. a. „On the Effectiveness of XML Schema Valida- tionfor Countering XML Signature Wrapping Attacks“. In: XML Schema Validation 7.1 (1. Jan. 2013). url: https://www.nds. ruhr-uni-bochum.de/media/nds/veroeffentlichungen/ 2013/03/25/paper.pdf (besucht am 18. 12. 2019). 162 Verzeichnis der ST-Anwendungshinweise 1 FDP_IFF.1.2/NK.PF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2 FDP_IFF.1.5/NK.PF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3 FDP_IFF.1.5/NK.PF(5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4 FPT_STM.1.1/NK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5 FPT_TDC.1/NK.Zert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6 FPT_TST.1/NK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 7 FAU_GEN.1.2/NK.SecLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 8 FTP_TRP.1.1/NK.Admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 9 FMT_MSA.1/NK.PF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 10 FMT_MOF.1.1/NK.TLS(3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 11 FMT_MOF.1/NK.TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 12 FCS_RNG.1/Hash_DRBG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 13 FIA_SOS.1/AK.Passwörter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 14 FIA_SOS.1/AK.CS.Passwörter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 15 FIA_UAU.5.1/AK(2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 16 FIA_UAU.5.1/AK(5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 17 FIA_API.1/AK.TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 18 FMT_MSA.3/AK.Infomod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 19 FDP_ACF.1.4/AK.eHKT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 20 FDP_ACF.1.2/AK.KD(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 21 FDP_DAU.2.1/AK.QES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 22 FDP_DAU.2.1/AK.QES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 23 FDP_DAU.2.1/AK.Sig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 24 FMT_MSA.3/AK.Sig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 25 FMT_MSA.1/AK.User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 26 FTP_ITC.1.3/AK.QSEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 27 FTA_TAB.1/AK.SP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 28 FDP_ACF.1.4/AK.Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 29 FDP_ACF.1.1/AK.Update (für TIP1-A_6025) . . . . . . . . . . . . . . . . . . . . . . . . 83 30 FDP_ACF.1/AK.Enc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 31 FDP_ITC.2.5/AK.Enc(2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 32 FDP_ETC.2.4/AK.Enc(2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 33 FDP_ACC.1/AK.TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 34 FMT_MSA.1/AK.TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 35 FMT_MSA.3.2/AK.TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 36 FTP_ITC.1/AK.FD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 37 FTP_ITC.1.1/AK.FD (für TIP1-A_7254) . . . . . . . . . . . . . . . . . . . . . . . . . . 90 38 FTP_ITC.1.1/AK.VZD (für TIP1-A_7254) . . . . . . . . . . . . . . . . . . . . . . . . . . 91 39 FDP_ACF.1.1/AK.SDS(3) (für TIP1-A_5484) . . . . . . . . . . . . . . . . . . . . . . . . 93 163 40 FDP_ACF.1.4/AK.SDS(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 41 FMT_MSA.1/AK.VSDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 42 FMT_MSA.3/AK.VSDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 43 FMT_MSA.4.1/AK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 44 FMT_MOF.1.1/AK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 45 FMT_MTD.1.1/AK.Admin(5), (6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 46 FMT_MTD.1.1/AK.Admin(7) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 47 FMT_MTD.1.1/AK.Admin(12) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 48 FMT_MTD.1.1/AK.Admin(16) (für TIP1-A_7255) . . . . . . . . . . . . . . . . . . . . . . 97 49 FMT_MTD.1/AK.Zert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 50 FPT_TDC.1.1/AK (für TIP1-A_5482) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 51 FPT_TST.1.3/AK.Run-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 52 FAU_GEN.1/AK (für TIP1-A_4710), (für VSDM-A_2789) . . . . . . . . . . . . . . . . . . 102 53 FAU_STG.4.1/AK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 164 Index der SFR FAU_GEN.1/AK . . . . . . . . . . . . . . . . 101, 133, 140 FAU_GEN.1/NK.SecLog . . . . . . 52, 102, 115, 141 FAU_GEN.2/NK.SecLog . . . . . . . . . . . . . . . 53, 115 FAU_SAR.1/AK . . . . . . . . . . . . . . . . . . . . . 102, 133 FAU_STG.1/AK . . . . . . . . . . . . . . . . . . . . . 103, 133 FAU_STG.4/AK . . . . . . . . . . . . . . . . 103, 133, 140 FCS_CKM.1/AK.AES. . . . . . . . . . . . . . . . . .64, 119 FCS_CKM.1/NK . . . . . . . . . . . . . . . . . . . . . 56, 118 FCS_CKM.1/NK.TLS. . . . . . . . .58, 117, 118, 140 FCS_CKM.1/NK.Zert . . . . . . . . . . . . . 59, 119, 140 FCS_CKM.2/NK.IKE . . . . . . . . . . . . . . . . . . 56, 118 FCS_CKM.4/AK . . . . . . . . . . . . . . . . . 65, 119, 132 FCS_CKM.4/NK . . . . . . . . . . . . . . . . . 57, 113, 118 FCS_COP.1/AK.AES . . . . . . . . . . . . . . . . . . 66, 128 FCS_COP.1/AK.CMS.Ent. . . . . . . . . . . . . . .67, 128 FCS_COP.1/AK.CMS.Sign. . . . . . . . . . . . . .65, 124 FCS_COP.1/AK.CMS.SigPr . . . . . . . . . . . . . 66, 124 FCS_COP.1/AK.CMS.Ver. . . . . . . . . . . . . . .67, 128 FCS_COP.1/AK.MIME.Ent . . . . . . . . . . . . . .67, 128 FCS_COP.1/AK.MIME.Ver. . . . . . . . . . . . . .67, 128 FCS_COP.1/AK.PDF.Sign . . . . . . . . . . . . . . 65, 124 FCS_COP.1/AK.PDF.SigPr. . . . . . . . . . . . . .66, 124 FCS_COP.1/AK.PKCS.SigPr . . . . . . . . . . . . 66, 124 FCS_COP.1/AK.SHA. . . . . . . . . . . . . . .64, 66, 119 FCS_COP.1/AK.SigVer.ECDSA . . . . . . . . . . 65, 124 FCS_COP.1/AK.SigVer.PSS. . . . . . . . . . . . .65, 124 FCS_COP.1/AK.SigVer.SSA. . . . . . . . . . . . .65, 124 FCS_COP.1/AK.XML.Ent . . . . . . . . . . . . . . .67, 128 FCS_COP.1/AK.XML.Sign . . . . . . . . . . . . . . 65, 124 FCS_COP.1/AK.XML.SigPr . . . . . . . . 66, 124, 141 FCS_COP.1/AK.XML.Ver. . . . . . . . . . . . . . .66, 128 FCS_COP.1/NK.Auth . . . . . . . . . . . . . 56, 117, 118 FCS_COP.1/NK.ESP . . . . . . . . . . . . . . . . . . 56, 118 FCS_COP.1/NK.Hash . . . . . . . . . . . . . . . . . 55, 117 FCS_COP.1/NK.HMAC . . . . . . . . . . . .55, 117, 118 FCS_COP.1/NK.IPsec . . . . . . . . . . . . . . . . . 56, 118 FCS_COP.1/NK.TLS.AES . . . . . 59, 117, 118, 140 FCS_COP.1/NK.TLS.Auth . . . . . . . . . 59, 118, 140 FCS_COP.1/NK.TLS.HMAC. . . .59, 117, 118, 140 FCS_COP.1/Sign . . . . . . . . . . . . . . . . . 63, 93, 106 FCS_COP.1/Storage.AES . . . . . . 63, 93, 106, 118 FCS_RNG.1/Hash_DRBG . . 59, 62, 64, 106, 108, 117, 118 FDP_ACC.1/AK.eHKT. . . . . . . .72, 122, 123, 141 FDP_ACC.1/AK.Enc . . . . . . . . . . . . . . . . . . 83, 128 FDP_ACC.1/AK.Infomod . . . . . 71, 121, 122, 141 FDP_ACC.1/AK.KD . . . . . . . . . . . . . . 73, 124, 141 FDP_ACC.1/AK.PIN . . . . . . . . . . . . . .74, 124, 141 FDP_ACC.1/AK.SDS . . . . . . . . . . . . . . . . . . 92, 129 FDP_ACC.1/AK.Sgen . . . . . . . . . . . . . . . . . 75, 124 FDP_ACC.1/AK.SigPr . . . . . . . . . . . . 76, 124, 141 FDP_ACC.1/AK.TLS . . . . . . . . . . . . . . . . . . 87, 119 FDP_ACC.1/AK.Update . . . . . . . . . . . . . . . 82, 131 FDP_ACC.1/AK.VSDM . . . . . . . . . . . . . 49, 94, 130 FDP_ACF.1/AK.eHKT . . . . . . . . 72, 122, 123, 141 FDP_ACF.1/AK.Enc . . . . . . . . . . . . . . . 69, 83, 128 FDP_ACF.1/AK.Infomod . . . . . .71, 121, 122, 141 FDP_ACF.1/AK.KD . . . . . . . . . . . 73, 74, 124, 141 FDP_ACF.1/AK.PIN . . . . . . . . . . . . . . 74, 124, 141 FDP_ACF.1/AK.SDS . . . . . . . . . . . . . . . . . . 92, 129 FDP_ACF.1/AK.Sgen . . . . . . . . . . . . . 75, 124, 127 FDP_ACF.1/AK.SigPr . . . . . . . . . 69, 76, 124, 141 FDP_ACF.1/AK.TLS . . . . . . . . . . . . . . 87, 119, 120 FDP_ACF.1/AK.Update . . . . . . . . . . . 82, 131, 153 FDP_ACF.1/AK.VSDM . . . . . . . . . . . . . 49, 94, 130 FDP_DAU.2/AK.Cert . . . . . . . . . . . . . . . . . . 79, 125 FDP_DAU.2/AK.QES . . . . 76, 126, 127, 140, 141 FDP_DAU.2/AK.Sig . . . . . . . . . . . . . . 79, 126, 127 FDP_ETC.2/AK.Enc. . . . . . . . . . . . . . . . . . .86, 128 FDP_ETC.2/NK.TLS . . . . . . . . . . . . . .60, 119, 140 FDP_IFC.1/NK.PF . . . . . . . . . . . . . . . . 46, 47, 111 FDP_IFF.1/NK.PF . . . . . . . . . . . . . . . .46, 111, 113 FDP_ITC.2/AK.Enc . . . . . . . . . . . . . . . . . . . 85, 128 FDP_ITC.2/AK.Sig . . . . . . . . . . . . . . . 80, 124, 141 FDP_ITC.2/NK.TLS . . . . . . . . . . . . . . 60, 119, 140 FDP_RIP.1/AK . . . . . . . . . . . . . . . . . . . . . . . 95, 132 FDP_RIP.1/NK . . . . . . . . . . . . . . . . . . . . . . . 51, 113 FDP_SDI.2/AK. . . . . . . . . . . . . . . . . . . . . . .81, 125 165 FDP_UCT.1/AK.TLS . . . . . . . . . 72, 119, 122, 123 FDP_UIT.1/AK.TLS . . . . . . . . . . 73, 119, 122, 123 FDP_UIT.1/AK.Update . . . . . . . . . . . . . . . . 83, 131 FIA_API.1/AK. . . . . . . . . . . . . . . . . . .70, 120, 121 FIA_API.1/AK.TLS . . . . . . . . . . . . . . . 70, 108, 119 FIA_SOS.1/AK.CS.Passwörter . 68, 109, 120, 121 FIA_SOS.1/AK.Passwörter. . . .68, 109, 120, 121 FIA_SOS.2/AK.Jobnummer . . . . . . . . . . . . 75, 125 FIA_SOS.2/AK.PairG . . . . . . . . . . . . . 68, 120, 121 FIA_UAU.1/AK . . . . . . . . . . . . . . . . . . . . . . 69, 121 FIA_UAU.5/AK . . . . . . . . . 69, 120, 121, 125, 141 FIA_UID.1/AK . . . . . . . . . . . . . . . . . . . . . . . 69, 121 FIA_UID.1/NK.SMR . . . . . . . . . . . . . . . . . . . 54, 116 FMT_MOF.1/AK . . . . . . . . . . . . . . . . . . . . . 96, 130 FMT_MOF.1/NK.TLS . . . . . . . . . . . . . 61, 118, 140 FMT_MSA.1/AK.Infomod . . . . . . . . . . . . . . 71, 122 FMT_MSA.1/AK.TLS . . . . . . . . 89, 120, 121, 130 FMT_MSA.1/AK.User . . . . . . . . 81, 126, 127, 141 FMT_MSA.1/AK.VSDM. . . . . . . . . . . . . . . .94, 130 FMT_MSA.1/NK.PF . . . . . . . . . . . . . . 55, 112, 116 FMT_MSA.3/AK.Infomod . . . . . . . . . . . . . . 71, 122 FMT_MSA.3/AK.Sig. . . . . . . . . . . . . . .80, 97, 124 FMT_MSA.3/AK.TLS . . . . . . . . 89, 120, 121, 130 FMT_MSA.3/AK.VSDM. . . . . . . . . . . . . . . .95, 130 FMT_MSA.3/NK.PF . . . . . . . . . . . . . . . . . . 49, 111 FMT_MSA.4/AK. . . . . . . . . . . . . . . . .95, 124, 125 FMT_MSA.4/NK . . . . . . . . . . . . . . . . . . . . . 55, 116 FMT_MTD.1/AK.Admin . . . . . . . . . . . 96, 130, 153 FMT_MTD.1/AK.eHKT_Abf . . . . . . . . 73, 122, 123 FMT_MTD.1/AK.eHKT_Mod . . . . . . . 73, 122, 123 FMT_MTD.1/AK.Zert . . . . . . . . . . . . . 97, 124, 141 FMT_MTD.1/NK . . . . . . . . . . . . . . . . . . . . . 53, 116 FMT_SMF.1/AK. . . . . . . . . . . . . . . . . . . . . .96, 130 FMT_SMF.1/NK. . . . . . . . . . . . . . . . . . . . . .55, 116 FMT_SMR.1/AK . . . . . . . . . . . . . . . . . . . . . 96, 130 FMT_SMR.1/NK . . . . . . . . . . . . . . . . . . . . . 53, 116 FPT_EMS.1/NK. . . . . . . . . . . . . . . . . . . . . .51, 115 FPT_FLS.1/AK. . . . . . . . . . . . . . . . .100, 102, 132 FPT_STM.1/AK . . . . . . . . . . . . . . . . 101, 133, 141 FPT_STM.1/NK. . . . . . . . . . . . . .49, 53, 113, 141 FPT_TDC.1/AK . . . . . . . . . . . . . . . . . . . . . . 98, 132 FPT_TDC.1/NK.TLS.Zert . . . . . . . . . . 58, 119, 140 FPT_TDC.1/NK.Zert . . . . . . . . . . . . . . . . . . 50, 111 FPT_TEE.1/AK. . . . . . . .100, 122–124, 140, 141 FPT_TST.1/AK.Out-Of-Band . . . . . . . . . . . 101, 132 FPT_TST.1/AK.Run-time. . . . . . . . . . . . . .100, 132 FPT_TST.1/NK . . . . . . . . . . . . . . . . . . . . . . 51, 114 FTA_TAB.1/AK.Jobnummer . . . . . . . . . . . . 82, 125 FTA_TAB.1/AK.SP . . . . . . . . . . . . . . . . . . . 82, 125 FTP_ITC.1/AK.CS . . . . . . . . . . . . . . . . . . . . 91, 119 FTP_ITC.1/AK.eHKT. . . . . . . . .91, 119, 122, 123 FTP_ITC.1/AK.FD. . . . . . . . . . . . . . . . .90, 94, 119 FTP_ITC.1/AK.KSR . . . . . . . . . . . . . . . . . . . 91, 119 FTP_ITC.1/AK.QSEE . . . . . . . . . . . . . . . . . . 81, 125 FTP_ITC.1/AK.TSL . . . . . . . . . . . . . . . . . . . 91, 119 FTP_ITC.1/AK.VZD . . . . . . . . . . . . . . . . . . .90, 119 FTP_ITC.1/NK.TLS. . . . . . . . . . . . . . . .57, 61, 140 FTP_ITC.1/NK.VPN_SIS . . . . . . . . . . . . . . . 46, 110 FTP_ITC.1/NK.VPN_TI . . . . . . . . . . . . . . . . 46, 110 FTP_TRP.1/NK.Admin . . . . . . . . . . . . . . . . 54, 116 166