BSI-DSZ-CC-1174-2021 zu secunet konnektor 2.1.0, Version 4.1.3:2.1.0 der secunet Security Networks AG BSI - Bundesamt für Sicherheit in der Informationstechnik, Postfach 20 03 63, D-53133 Bonn Phone +49 (0)228 99 9582-0, Fax +49 (0)228 9582-5477, Infoline +49 (0)228 99 9582-111 Zertifizierungsreport V1.0 CC-Zert-328 V1.7 BSI-DSZ-CC-1174-2021 (*) secunet konnektor 2.1.0 Version 4.1.3:2.1.0 von secunet Security Networks AG PP-Konformität: Common Criteria Schutzprofil (Protection Profile) Schutzprofil 2: Anforderungen an den Konnektor, Version 1.5.9, BSI-CC-PP-0098-V3-2021 vom 15.04.2021 Funktionalität: PP konform plus produktspezifische Ergänzungen Common Criteria Teil 2 erweitert Vertrauenswürdigkeit: Common Criteria Teil 3 konform EAL 3 mit Zusatz von ADV_FSP.4, ADV_TDS.3, ADV_IMP.1, ALC_TAT.1, AVA_VAN.3 und ALC_FLR.2 Das in diesem Zertifikat genannte IT-Produkt wurde von einer anerkannten Prüfstelle nach der Gemeinsamen Evaluationsmethodologie für die Prüfung und Bewertung der Sicherheit von Informationstechnik (CEM), Version 3.1 ergänzt um Interpretationen des Zertifizierungsschemas unter Nutzung der Gemeinsamen Kriterien für die Prüfung und Bewertung der Sicherheit von Informationstechnik, Version 3.1 (CC) evaluiert. CC und CEM sind ebenso als Norm ISO/IEC 15408 und ISO/IEC 18045 veröffentlicht. (*) Dieses Zertifikat gilt nur für die angegebene Version des Produktes in der evaluierten Konfiguration und nur in Verbindung mit dem vollständigen Zertifizierungsreport und - bescheid. Details zur Gültigkeit sind dem Zertifizierungsreport Teil A, Kap. 5 zu entnehmen. Die Evaluation wurde in Übereinstimmung mit den Bestimmungen des Zertifizierungsschemas des Bundesamtes für Sicherheit in der Informationstechnik durchgeführt. Die im Evaluationsbericht enthaltenen Schlussfolgerungen der Prüfstelle sind in Einklang mit den erbrachten Nachweisen. Dieses Zertifikat ist keine generelle Empfehlung des IT-Produktes durch das Bundesamt für Sicherheit in der Informationstechnik oder eine andere Organisation, die dieses Zertifikat anerkennt oder darauf Einfluss hatte. Eine Gewährleistung für das IT-Produkt durch das Bundesamt für Sicherheit in der Informationstechnik oder eine andere Organisation, die dieses Zertifikat anerkennt oder darauf Einfluss hatte, ist weder enthalten noch zum Ausdruck gebracht. Bonn, 16. Juli 2021 Bundesamt für Sicherheit in der Informationstechnik Im Auftrag Joachim Weber L.S. Fachbereichsleiter Bundesamt für Sicherheit in der Informationstechnik Godesberger Allee 185-189 - D-53175 Bonn - Postfach 20 03 63 - D-53133 Bonn Phone +49 (0)228 99 9582-0 - Fax +49 (0)228 9582-5477 - Infoline +49 (0)228 99 9582-111 SOGIS Recognition Agreement Common Criteria Recognition Arrangement Anerkennung nur für Komponenten bis EAL 2 und ALC_FLR Zertifizierungsreport BSI-DSZ-CC-1174-2021 Dies ist eine eingefügte Leerseite. 4 / 43 BSI-DSZ-CC-1174-2021 Zertifizierungsreport Gliederung A. Zertifizierung....................................................................................................................7 1. Vorbemerkung..............................................................................................................7 2. Grundlagen des Zertifizierungsverfahrens...................................................................7 3. Anerkennungsvereinbarungen.....................................................................................8 4. Durchführung der Evaluierung und Zertifizierung........................................................9 5. Gültigkeit des Zertifizierungsergebnisses....................................................................9 6. Veröffentlichung..........................................................................................................10 B. Zertifizierungsbericht......................................................................................................11 1. Zusammenfassung.....................................................................................................12 2. Identifikation des EVG................................................................................................19 3. Sicherheitspolitik.........................................................................................................21 4. Annahmen und Klärung des Einsatzbereiches..........................................................21 5. Informationen zur Architektur.....................................................................................22 6. Dokumentation...........................................................................................................23 7. Testverfahren..............................................................................................................23 8. Evaluierte Konfiguration.............................................................................................25 9. Ergebnis der Evaluierung...........................................................................................26 10. Auflagen und Hinweise zur Benutzung des EVG.....................................................35 11. Sicherheitsvorgaben.................................................................................................36 12. Definitionen...............................................................................................................36 13. Literaturangaben......................................................................................................38 C. Auszüge aus den Kriterien............................................................................................42 D. Anhänge........................................................................................................................43 5 / 43 Zertifizierungsreport BSI-DSZ-CC-1174-2021 A. Zertifizierung 1. Vorbemerkung Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat gemäß BSIG1 die Aufgabe, für Produkte (Systeme oder Komponenten) der Informationstechnik, Sicherheitszertifikate zu erteilen. Die Zertifizierung eines Produktes wird auf Veranlassung des Herstellers oder eines Vertreibers - im folgenden Antragsteller genannt - durchgeführt. Bestandteil des Verfahrens ist die technische Prüfung (Evaluierung) des Produktes gemäß den vom BSI öffentlich bekannt gemachten oder allgemein anerkannten Sicherheitskriterien. Die Prüfung wird in der Regel von einer vom BSI anerkannten Prüfstelle oder vom BSI selbst durchgeführt. Das Ergebnis des Zertifizierungsverfahrens ist der vorliegende Zertifizierungsreport. Hierin enthalten sind u. a. das Sicherheitszertifikat (zusammenfassende Bewertung) und der detaillierte Zertifizierungsbericht. Der Zertifizierungsbericht enthält die sicherheitstechnische Beschreibung des zertifizierten Produktes, die Einzelheiten der Bewertung und Hinweise für den Anwender. 2. Grundlagen des Zertifizierungsverfahrens Die Zertifizierungsstelle führt das Verfahren nach Maßgabe der folgenden Vorgaben durch: ● BSI-Gesetz1 ● BSI-Zertifizierungs- und - Anerkennungsverordnung2 ● Besondere Gebührenverordnung BMI (BMIBGebV)3 ● besondere Erlasse des Bundesministeriums des Innern ● die Norm DIN EN ISO/IEC 17065 ● BSI-Zertifizierung: Verfahrensdokumentation zum Zertifizierungsprozess (CC-Produkte) [3] ● BSI Zertifizierung: Verfahrensdokumentation zu Anforderungen an Prüfstellen, deren Anerkennung und Lizenzierung (CC-Stellen) [3] ● Gemeinsame Kriterien für die Prüfung und Bewertung der Sicherheit von Informationstechnik (Common Criteria for Information Technology Security Evaluation/CC), Version 3.14 [1], auch als Norm ISO/IEC 15408 veröffentlicht. 1 Gesetz über das Bundesamt für Sicherheit in der Informationstechnik (BSI-Gesetz – BSIG) vom 14. August 2009, Bundesgesetzblatt I S. 2821 2 Verordnung über das Verfahren der Erteilung von Sicherheitszertifikaten und Anerkennungen durch das Bundesamt für Sicherheit in der Informationstechnik (BSI-Zertifizierungs- und - Anerkennungsverordnung - BSIZertV) vom 17. Dezember 2014, Bundesgesetzblatt Jahrgang 2014 Teil I, Nr. 61, S. 2231 3 Besondere Gebührenverordnung des BMI für individuell zurechenbare öffentliche Leistungen indessen Zuständigkeitsbereich (BMIBGebV), Abschnitt 7 (BSI-Gesetz) vom 2. September 2019,Bundesgesetzblatt I S. 1365 4 Bekanntmachung des Bundesministeriums des Innern vom 12. Februar 2007 im Bundesanzeiger, datiert 23. Februar 2007, S. 1941 6 / 43 BSI-DSZ-CC-1174-2021 Zertifizierungsreport ● Gemeinsame Evaluationsmethodologie für die Prüfung und Bewertung der Sicherheit von Informationstechnik (Common Methodology for Information Technology Security Evaluation/CEM), Version 3.1 [2] auch als Norm ISO/IEC 18045 veröffentlicht. ● BSI-Zertifizierung: Anwendungshinweise und Interpretationen zum Schema (AIS) [4] 3. Anerkennungsvereinbarungen Um die Mehrfach-Zertifizierung des gleichen Produktes in verschiedenen Staaten zu vermeiden, wurde eine gegenseitige Anerkennung von IT-Sicherheitszertifikaten - sofern sie auf ITSEC oder Common Criteria (CC) beruhen - unter gewissen Bedingungen vereinbart. 3.1. Europäische Anerkennung von CC – Zertifikaten (SOGIS-MRA) Das SOGIS-Anerkennungsabkommen (SOGIS-MRA) Version 3 ist im April 2010 in Kraft getreten. Es legt die Anerkennung von Zertifikaten für IT-Produkte auf einer Basisanerkennungsstufe und zusätzlich für IT-Produkte aus bestimmten Technischen Bereichen (SOGIS Technical Domain) auf höheren Anerkennungsstufen fest. Die Basisanerkennungsstufe schließt die Common Criteria (CC) Vertrauenswürdigkeitsstufen EAL 1 bis EAL 4 ein. Für Produkte im technischen Bereich "smartcard and similar devices" ist eine SOGIS Technical Domain festgelegt. Für Produkte im technischen Bereich "HW Devices with Security Boxes" ist ebenfalls eine SOGIS Technical Domain festgelegt. Des Weiteren erfasst das Anerkennungsabkommen auch erteilte Zertifikate für Schutzprofile (Protection Profiles) basierend auf den Common Criteria. Eine aktuelle Liste der Unterzeichnerstaaten bzw. der anerkannten Zertifizierungsstellen, Details zur Anerkennung sowie zur Historie des Abkommens können auf der Internetseite https://www.sogis.eu eingesehen werden. Das SOGIS-MRA-Logo auf dem Zertifikat zeigt, dass das Zertifikat unter den Bedingungen des Abkommens von den jeweiligen Stellen der Unterzeichnerstaaten als gleichwertig anerkannt wird. Ein Hinweis unter dem Logo weist auf einen spezifischen Umfang der Anerkennung hin. Dieses Zertifikat fällt mit allen ausgewählten Vertrauenswürdigkeitskomponenten unter die Anerkennung nach SOGIS-MRA. 3.2. Internationale Anerkennung von CC - Zertifikaten Das internationale Abkommen zur gegenseitigen Anerkennung von Zertifikaten basierend auf CC (Common Criteria Recognition Arrangement, CCRA-2014) wurde am 8. September 2014 ratifiziert. Es deckt CC-Zertifikate ab, die auf sog. collaborative Protection Profiles (cPP) (exact use) basieren, CC-Zertifikate, die auf Vertrauenswürdigkeitsstufen bis einschließlich EAL 2 oder die Vertrauenswürdigkeitsfamilie Fehlerbehebung (Flaw Remediation, ALC_FLR) basieren und CC Zertifikate für Schutzprofile (Protection Profiles) und für collaborative Protection Profiles (cPP). Eine aktuelle Liste der Unterzeichnerstaaten bzw. der anerkannten Zertifizierungsstellen kann auf der Internetseite https://www.commoncriteriaportal.org eingesehen werden. Das CCRA-Logo auf dem Zertifikat zeigt, dass das Zertifikat unter den Bedingungen des Abkommens von den jeweiligen Stellen der Unterzeichnerstaaten als gleichwertig 7 / 43 Zertifizierungsreport BSI-DSZ-CC-1174-2021 anerkannt wird. Ein Hinweis unter dem Logo weist auf einen spezifischen Umfang der Anerkennung hin. Dieses Zertifikat fällt unter die Anerkennungsregeln des CCRA-2014, d.h. Anerkennung bis einschließlich CC Teil 3 EAL 2+ ALC_FLR Komponenten. 4. Durchführung der Evaluierung und Zertifizierung Die Zertifizierungsstelle führt für jede einzelne Evaluierung eine Prüfbegleitung durch, um einheitliches Vorgehen, einheitliche Interpretation der Kriterienwerke und einheitliche Bewertungen sicherzustellen. Das Produkt secunet konnektor 2.1.0, Version 4.1.3:2.1.0 hat das Zertifizierungsverfahren beim BSI durchlaufen. Die Evaluation des Produkts secunet konnektor 2.1.0, Version 4.1.3:2.1.0 wurde von SRC Security Research & Consulting GmbH durchgeführt. Die Evaluierung wurde am 27. Mai 2021 abgeschlossen. Das Prüflabor SRC Security Research & Consulting GmbH ist eine vom BSI anerkannte Prüfstelle (ITSEF)5. Der Sponsor und Antragsteller ist: secunet Security Networks AG. Das Produkt wurde entwickelt von: secunet Security Networks AG. Die Zertifizierung wurde damit beendet, dass das BSI die Übereinstimmung mit den Kriterien überprüft und den vorliegenden Zertifizierungsreport erstellt hat. 5. Gültigkeit des Zertifizierungsergebnisses Dieser Zertifizierungsreport bezieht sich nur auf die angegebene Version des Produktes. Das Produkt ist unter den folgenden Bedingungen konform zu den bestätigten Vertrauenswürdigkeitskomponenten: ● alle Auflagen hinsichtlich der Generierung, der Konfiguration und dem Einsatz des EVG, die in diesem Report gestellt werden, werden beachtet. ● das Produkt wird in der Umgebung betrieben, die in diesem Report und in den Sicherheitsvorgaben beschrieben ist. Die Bedeutung der Vertrauenswürdigkeitskomponenten und -stufen kann direkt den CC entnommen werden. Detaillierte Referenzen sind in Teil C dieses Reportes aufgelistet. Das Zertifikat bestätigt die Vertrauenswürdigkeit des Produktes gemäß den Sicherheitsvorgaben zum Zeitpunkt der Ausstellung. Da sich Angriffsmethoden im Laufe der Zeit fortentwickeln, ist es erforderlich, die Widerstandsfähigkeit des Produktes regelmäßig überprüfen zu lassen. Aus diesem Grunde sollte der Hersteller das zertifizierte Produkt im Rahmen des Assurance Continuity-Programms des BSI überwachen lassen (z.B. durch eine Neubewertung oder eine Re-Zertifizierung). Insbesondere wenn Ergebnisse aus dem Zertifizierungsverfahren in einem nachfolgenden Evaluierung- und Zertifizierungsverfahren oder in einer Systemintegration verwendet werden oder wenn das Risikomanagement eines Anwenders eine regelmäßige Aktualisierung verlangt, wird empfohlen, die Neubewertung der Widerstandsfähigkeit regelmäßig, z.B. jährlich vorzunehmen. 5 Information Technology Security Evaluation Facility 8 / 43 BSI-DSZ-CC-1174-2021 Zertifizierungsreport Um in Anbetracht der sich weiter entwickelnden Angriffsmethoden eine unbefristete Anwendung des Zertifikates trotz der Erfordernis nach einer Neubewertung nach den Stand der Technik zu verhindern, wurde die maximale Gültigkeit des Zertifikates begrenzt. Dieses Zertifikat, erteilt am 16. Juli 2021, ist gültig bis 15 Juli 2026. Die Gültigkeit kann im Rahmen einer Re-Zertifizierung erneuert werden. Der Inhaber des Zertifikates ist verpflichtet, 1. bei der Bewerbung des Zertifikates oder der Tatsache der Zertifizierung des Produktes auf den Zertifizierungsreport hinzuweisen sowie jedem Anwender des Produktes den Zertifizierungsreport und die darin referenzierten Sicherheitsvorgaben und Benutzerdokumentation für den Einsatz oder die Verwendung des zertifizierten Produktes zur Verfügung zu stellen, 2. die Zertifizierungsstelle des BSI unverzüglich über Schwachstellen des Produktes zu informieren, die nach dem Zeitpunkt der Zertifizierung durch Sie oder Dritte festgestellt wurden, 3. die Zertifizierungsstelle des BSI unverzüglich zu informieren, wenn sich sicherheitsrelevante Änderungen am geprüften Lebenszyklus, z. B. an Standorten oder Prozessen ergeben oder die Vertraulichkeit von Unterlagen und Informationen zum Evaluierungsgegenstand oder aus dem Evaluierungs- und Zertifizierungsprozess, bei denen die Zertifizierung des Produktes aber von der Aufrechterhaltung der Vertraulichkeit für den Bestand des Zertifikates ausgegangen ist, nicht mehr gegeben ist. Insbesondere ist vor Herausgabe von vertraulichen Unterlagen oder Informationen zum Evaluierungsgegenstand oder aus dem Evaluierungs- und Zertifizierungsprozess, die nicht zum Lieferumfang gemäß Zertifizierungsreport Teil B gehören oder für die keine Weitergaberegelung vereinbart ist, an Dritte, die Zertifizierungsstelle des BSI zu informieren. Bei Änderungen am Produkt kann die Gültigkeit des Zertifikats auf neue Versionen ausgedehnt werden. Voraussetzung dafür ist, dass der Antragsteller die Aufrechterhaltung der Vertrauenswürdigkeit (d.h. eine Re-Zertifizierung oder ein Maintenance Verfahren) in Übereinstimmung mit den entsprechenden Regeln beantragt und die Evaluierung keine Schwächen aufdeckt. 6. Veröffentlichung Das Produkt secunet konnektor 2.1.0, Version 4.1.3:2.1.0 ist in die BSI-Liste der zertifizierten Produkte, die regelmäßig veröffentlicht wird, aufgenommen worden (siehe auch Internet: https://www.bsi.bund.de und [5]). Nähere Informationen sind über die BSI- Infoline 0228/9582-111 zu erhalten. Weitere Exemplare des vorliegenden Zertifizierungsreports können beim Hersteller des Produktes angefordert werden6 . Der Zertifizierungsreport kann ebenso in elektronischer Form von der oben angegebenen Internetadresse heruntergeladen werden. 6 secunet Security Networks AG Kurfürstenstraße 58 45138 Essen Deutschland 9 / 43 Zertifizierungsreport BSI-DSZ-CC-1174-2021 B. Zertifizierungsbericht Der nachfolgende Bericht ist eine Zusammenfassung aus ● den Sicherheitsvorgaben des Antragstellers für den Evaluationsgegenstand, ● den entsprechenden Prüfergebnissen des Prüflabors und ● ergänzenden Hinweisen und Auflagen der Zertifizierungsstelle. 10 / 43 BSI-DSZ-CC-1174-2021 Zertifizierungsreport 1. Zusammenfassung Der Evaluierungsgegenstand (EVG) ist ein Softwareprodukt, bestehend aus dem Netzkonnektor und dem Anwendungskonnektor nach dem Protection Profile [8]. Der Netzkonnektor umfasst die Sicherheitsfunktionen einer Firewall und eines VPN- Clients, NTP-Servers Namens- (DNS) und DHCP-Dienstes. Er enthält auch die Grundfunktionen zum Aufbau sicherer TLS-Verbindungen zu anderen IT-Produkten. Die Sicherheitsfunktionalität des Anwendungskonnektors umfasst die Signaturanwendung, die Verschlüsselung und Entschlüsselung von Dokumenten, den Kartenterminaldienst und den Chipkartendienst. Zusammen mit dem Netzkonnektor ermöglicht der Anwendungskonnektor zudem die gesicherte Kommunikation zwischen dem Konnektor und dem Clientsystem sowie zwischen Fachmodulen und Fachdiensten. Insbesondere setzt der Konnektor Kommunikationsprotokolle für die sichere Anbindung an das ePA- Aktensystem der Telematikinfrastruktur um. Die Sicherheitsvorgaben [6] stellen die Grundlage für die Zertifizierung dar. Sie basieren auf dem zertifizierten Protection Profile [8]. Die Vertrauenswürdigkeitskomponenten (Security Assurance Requirements SAR) sind dem Teil 3 der Common Criteria entnommen (siehe Teil C oder [1], Teil 3). Der EVG erfüllt die Anforderungen der Vertrauenswürdigkeitsstufe EAL 3 mit Zusatz von ADV_FSP.4, ADV_TDS.3, ADV_IMP.1, ALC_TAT.1, AVA_VAN.3 und ALC_FLR.2. Die funktionalen Sicherheitsanforderungen (Security Functional Requirements SFR) an den EVG werden in den Sicherheitsvorgaben [6] Kapitel 6 beschrieben. Sie wurden dem Teil 2 der Common Criteria entnommen und durch neu definierte funktionale Sicherheitsanforderungen ergänzt. Der EVG ist daher gekennzeichnet als CC Teil 2 erweitert. Die funktionalen Sicherheitsanforderungen werden durch die folgende Sicherheitsfunktionalität des EVG umgesetzt: Sicherheits- funktionalität des EVG Thema Sicherheitsfunktionalität des NK als Teil des EVG VPN-Client Der EVG stellt einen sicheren Kanal zur zentralen Telematikinfrastruktur-Plattform (TI-Plattform) sowie zum Sicheren Internet Service (SIS) bereit, der nach gegenseitiger Authentisierung die Vertraulichkeit und Datenintegrität der Nutzdaten sicherstellt. Der Trusted Channel wird auf Basis des IPsec-Protokolls aufgebaut, hierbei wird IKEv2 unterstützt. Informationsfluss- kontrolle Regelbasiert nutzen alle schützenswerten Informationsflüsse die etablierten VPN- Tunnel. Nur Informationsflüsse, die vom Konnektor initiiert wurden sowie Informationsflüsse von Clientsystemen in Bestandsnetze dürfen den VPN-Tunnel in die Telematikinfrastruktur benutzen und erhalten damit überhaupt erst Zugriff auf die zentrale TI-Plattform. Andere Informationsflüsse, die den Zugriff auf Internet- Dienste aus den lokalen Netzen der Leistungserbringer betreffen, nutzen den VPN-Tunnel zum Sicheren Internet Service (SIS). Dynamischer Paketfilter Der EVG implementiert einen dynamischen Paketfilter. Diese Anforderung wird als Informationsflusskontrolle modelliert. 11 / 43 Zertifizierungsreport BSI-DSZ-CC-1174-2021 Sicherheits- funktionalität des EVG Thema Die Filterregeln (packet filtering rules) sind mit geeigneten Default-Werten vorbelegt und können vom Administrator für den SIS verwaltet werden. Netzdienste: Zeitsynchronisation Der EVG führt bei bestehender Verbindung zur TI in regelmäßigen Abständen eine Zeitsynchronisation mit Zeitservern durch. Der EVG unterstützt eine Signaleinrichtung in Form von Status-LEDs, welche den Betriebszustand am Gehäuse des Konnektors anzeigt. Netzdienste: Zertifikatsprüfung Der EVG überprüft die Gültigkeit der Zertifikate, die für den Aufbau der VPN- Kanäle verwendet werden. Die erforderlichen Informationen zur Prüfung der Gerätezertifikate werden dem EVG in Form einer (signierten) Trust-service Status List (TSL) und einer Sperrliste (CRL) bereitgestellt. Der EVG prüft die Zertifikate kryptographisch mittels der aktuell gültigen TSL und CRL. Stateful Packet Inspection Der EVG kann nicht wohlgeformte IP-Pakete erkennen und verwirft diese. Er implementiert eine sogenannte „zustandsgesteuerte Filterung“. Dies ist eine dynamische Paketfiltertechnik, bei der jedes Datenpaket einer aktiven Session zugeordnet und der Verbindungsstatus in die Entscheidung über die Zulässigkeit eines Informationsflusses einbezogen wird. Selbstschutz: Speicheraufbereitung Der EVG löscht nicht mehr benötigte kryptographische Schlüssel (insbesondere session-keys für die VPN-Verbindung) nach ihrer Verwendung durch aktives Überschreiben mit Nullen. Der EVG speichert medizinische Daten nicht dauerhaft. Ausnahmen sind die Speicherung von Daten während ihrer Ver- und Entschlüsselung; auch diese werden sobald wie möglich nach ihrer Verwendung gelöscht. Selbstschutz: Selbsttests Der EVG bietet seinen Benutzern die Möglichkeit zur Integritätsprüfung. Es wird bei Programmstart eine Prüfung der Integrität der installierten ausführbaren Dateien und sonstigen sicherheitsrelevanten Dateien (Konfigurationsdateien, TSF- Daten) durch Verifikation von Signaturen durchgeführt. Dies wird durch eine sichere Bootkette umgesetzt. Die Selbsttest-Funktion (Secure Boot) kann nicht deaktiviert bzw. manipuliert werden. Im Falle einer Software-Aktualisierung wird dieselbe Bootkette durchlaufen. Das neue SW-Image wird vom Bootloader geprüft und geladen. Schlägt die Prüfung der Integrität fehl, so wird ein Neustart des EVG durchgeführt und anschließend wird das ursprüngliche SW-Image geladen. Selbstschutz: Schutz von Geheimnissen, Seitenkanalresistenz Der EVG schützt Geheimnisse während ihrer Verarbeitung gegen unbefugte Kenntnisnahme. Dies gilt grundsätzlich für kryptographisches Schlüsselmaterial. Der private Authentisierungsschlüssel für das VPN wird bereits durch die gSMC-K und dessen Resistenz gegen Seitenkanalangriffe geschützt. Der EVG verhindert darüber hinaus den Abfluss von geheimen Informationen wirkungsvoll, etwa die session-keys der VPN-Verbindung oder zu schützende Daten der TI und der Bestandsnetze. Selbstschutz: Sicherheits-Log Der EVG führt ein Sicherheits-Log gemäß Konnektor-Spezifikation. 12 / 43 BSI-DSZ-CC-1174-2021 Zertifizierungsreport Sicherheits- funktionalität des EVG Thema Administration Der EVG setzt Lokales und Remote Management um. Der Administrator muss autorisiert sein, bevor er administrative Tätigkeiten bzw. Wartungstätigkeiten ausführen darf. Die Authentisierung erfolgt dabei durch den Netzkonnektor selbst. Zu den administrativen Tätigkeiten bzw. Wartungstätigkeiten gehören neben der Konfiguration des Konnektors u.a. die Verwaltung der Filterregeln für den dynamischen Paketfilter sowie das Aktivieren und Deaktivieren des VPN-Tunnels. Die Administration der Filterregeln für den dynamischen Paketfilter ist den Administratoren vorbehalten. Software Update Signierte Update-Pakete werden importiert und im Datenspeicher des EVG abgelegt. Sobald ein Update-Paket zur Verfügung steht signalisiert der TOE dass ein Software Update-Paket zur Verfügung steht. Der Administrator kann die Version des Update-Paketes prüfen und den Updateprozess anstoßen. Die Automatische Installation von Software Updates wird vom EVG nicht unterstützt. Im Falle einer Software-Aktualisierung wird der EVG neu gestartet und dieselbe Bootkette, wie in der Sicherheitsfunktion „Selbstschutz“ beschrieben, abgelaufen. Das neue Update-Paket wird vom Bootloader auf Integrität geprüft und bei erfolgreicher Prüfung geladen. Das alte Image wird vom EVG verworfen. Schlägt die Prüfung der Integrität fehl, so wird das Update-Paket verworfen und ein Neustart des EVG durchgeführt mit dem das ursprüngliche SW Image geladen wird. Durch die Prüfung des Update-Pakets analog zum regulären Boot-Prozess wird verhindert, dass manipulierte Update-Pakete eingespielt werden können. Kryptographische Basisdienste Der Konnektor implementiert Kryptographische Basisdienste für den Aufbau von sicheren VPN-Verbindungen zu den VPN-Konzentratoren der TI und des SIS. TLS-Kanäle unter Nutzung sicherer kryptographischer Algorithmen Der Netzkonnektor stellt dem Anwendungskonnektor die Dienste zum Aufbau eines TLS-Kanals zur Verfügung. TLS wird auch zur Absicherung der Administratorschnittstelle verwendet. Die kryptographischen Basisdienste für TLS des Netzkonnektors werden nicht direkt nach außen zur Verfügung gestellt, sondern können nur indirekt aufgerufen werden (z.B. Einrichtung und Verwendung des TLS-Kanals). Zertifikate die im Rahmen des TLS-Verbindungsaufbaus zum Einsatz kommen, werden vom Netzkonnektor entsprechend den Anforderungen in [13] [gemSpec_Kon] interpretiert. Der EVG prüft insbesondere, ob die Gültigkeitsdauer eines Zertifikates überschritten ist und ob ein Zertifikat in einer Whitelist enthalten ist. Für die Einrichtung einer sicheren TLS-Verbindung zwischen Konnektor und Clientsystemen werden X.509-Zertifikate verwendet. Entsprechende Zertifikate für das Clientsystem können vom EVG erzeugt werden. Der EVG bietet dem Administrator eine sichere Schnittstelle zum exportieren dieser X.509-Zertifikate für Clientsysteme und die zugehörigen privaten Schlüssel. Zertifikate für Clientsysteme können auch vom EVG über die gesicherte Management- Schnittstelle durch den Administrator importiert werden, um ggfls. benötigte Betriebszustände wiederherzustellen. Die TLS-Verbindungen werden vom Anwendungskonnektor gemanagt und je nach Anwendungsfall eingerichtet. Sicherheitsfunktionalität des AK als Teil des EVG 13 / 43 Zertifizierungsreport BSI-DSZ-CC-1174-2021 Sicherheits- funktionalität des EVG Thema Identifikation und Authentisierung Der Konnektor setzt unterschiedliche Mechanismen zur Identifikation und Authentisierung von Benutzern um. Die Management-Schnittstelle des Konnektors ist durch Passworteingabe vor unautorisiertem Zugriff geschützt. Dabei gelten die folgenden Anforderungen nach [13] [gemSpec_Kon], TIP1-A_4808 an die Administrator Passwörter. Im Rahmen des Pairing eines eHealth-Kartenterminals generiert der Konnektor das „pairing secret“ mit hinreichend großer Entropie. Wird ein angeschlossenes Kartenterminal für Stapelsignaturen verwendet, so fordert der Konnektor die Übertragung der DTBS über einen sicheren Kanal der mittels card-to-card authentication mit dem HBA ausgehandelt wird. Zugriffsberechtigungs- dienst Der Zugriffsberechtigungsdienst (oder Zugriffskontrolldienst) ist ein interner Dienst des Konnektors der automatisch bei Aufruf einer Operation des Konnektors durch das Clientsystem umgesetzt wird. Durch den Zugriffskontrolldienst wird eine Prüfung auf Zugriffsberechtigung für die an-geforderten Ressourcen durchgeführt. Die erlaubten Zugriffsmöglichkeiten werden über ein Informationsmodell (kurz Infomodell) definiert. Durch das Infomodell werden Mandanten definiert und Clientsysteme sowie die vom Konnektor verwalteten externen Ressourcen (Kartenterminal mit Slots, Arbeitsplatz, SMC-Bs) zugeordnet. Die entsprechenden Zuordnungen werden durch einen Administrator eingestellt und beinhalten die erlaubten Zugriffswege vom Clientsystem über Arbeitsplatz zum Kartenterminal und dessen Slots. Kartenterminaldienst Die Aufgabe des Kartenterminaldienstes ist das Management aller vom Konnektor adressierbaren Kartenterminals (KT). Dabei kapselt der Kartenterminaldienst die Zugriffe auf Kartenterminals durch Basisdienste und Fachmodule. Über den Kartenterminaldienst können TLS-Kanäle zu den KTs auf- und abgebaut, sowie SICCT-Kommandos gesendet und empfangen werden. Der Anwendungskonnektor kommuniziert mit den konfigurierten eHealth- Kartenterminals über TLS-Kanäle. Der Netzkonnektor stellt diese Kommunikationskanäle kontrolliert dem Anwendungskonnektor zur Verfügung. Informationen über die Arbeitsplatzkonfiguration eines angeschlossenen Kartenterminals können vom Kartenterminaldienst ausgegeben werden. Nur der Administrator darf diese Daten auch verändern. Kartendienst Die eHealth-Kartenterminals unter der Steuerung des Anwendungskonnektors können verschiedene Chipkarten (KVK, eGK, SMC-B und HBA) aufnehmen. Die in den eHealth-Kartenterminals eines Arbeitsplatzes gesteckten Chipkarten mit ihren logischen Kanälen bilden einen dynamischen Kontext (s. [13] [gemSpec_Kon]). Die Identifikation dieser Chipkarten erfolgt durch Kartenhandles. Der EVG stellt Sicherheitsfunktionen des Chipkartendienstes anderen Diensten, dem Clientsystem oder den Fachmodulen, bereit. Dazu gehören der Aufbau und die Verwaltung logischer Kanäle und die Kommunikation mit der Karte via Chipkartenkommandos. Der Chipkartendienst regelt dabei den Zugriff auf die Chipkarten für die verschiedenen Dienste und Anwender. Zudem wird durch den Chipkartendienst die lokale und entfernte PIN-Eingabe an den Kartenterminals umgesetzt und die unterschiedlichen Anforderungen an lokale und entfernte PIN- Eingabe und der damit verbundene Umgang mit den so genannten Authentisierungsverifikationsdaten (VAD) geregelt. 14 / 43 BSI-DSZ-CC-1174-2021 Zertifizierungsreport Sicherheits- funktionalität des EVG Thema Signaturdienst Der Signaturdienst bietet Clientsystemen und Fachmodulen eine Schnittstelle zum Signieren von Dokumenten und Prüfen von Dokumentensignaturen an. Die zu signierenden oder zu prüfenden Daten können vom Konnektor bei Bedarf entsprechend der referenzierten NFDM Signaturrichtlinie behandelt werden. Der Signaturdienst unterstützt nicht-qualifizierte elektronische Signaturen (nonQES) sowie qualifizierte elektronische Signaturen (QES), die mit Hilfe der vom Chipkartendienst verwalteten Chipkarten erzeugt werden. Der Signaturdienst unterstützt die folgenden Signaturformate für nonQES und QES: • XAdES für XML Dokumente (Nur QES mit NFDM-Signaturrichtlinie), • CAdES für XML, PDF/A, Text und TIFF Dokumente • PAdES für PDF/A Dokumente. Darüber hinaus werden für nonQES die folgenden Signaturformate unterstützt: • CAdES für Binärdokumente • S/MIME für Multipurpose Internet Mail Extensions, Zudem wird für nonQES und QES PKCS#1 RSASSA-PSS und RSASSA-PKCS1- v.5 unterstützt. Das Prüfen von Dokumentensignaturen erfolgt anhand von Zertifikaten. Bei Feststellung ungültig erzeugter Signaturen wird der Benutzer entsprechend durch eine Warnmeldung benachrichtigt. Der Benutzer des Clientsystems muss seine Signatur-PIN an einem angeschlossenen eHealth-Kartenterminal eingeben. Software-Update Signierte Update-Pakete werden importiert und im Datenspeicher des EVG abgelegt. Sobald ein Update-Paket zur Verfügung steht, signalisiert der TOE, dass ein Software Update zur Verfügung steht. Der Administrator kann die Version des Update-Paketes prüfen und den Updateprozess anstoßen. Es können von Anwendungskonnektor und Netzkonnektor nur Update-Pakete erfolgreich installiert werden, deren Signatur erfolgreich geprüft wurde. Die Firmwaregruppe des Updates muss gleich oder höher der gegenwärtig installierten Firmwaregruppe sein. Der Updateprozess verhindert, dass manipulierte Update-Pakete eingespielt werden. Fachmodule können nur im Rahmen von Software-Updates des Konnektors aktualisiert oder eingebracht werden. Verschlüsselungsdienst Der Verschlüsselungsdienst bietet Schnittstellen zum hybriden und symmetrischen Ver- und Entschlüsseln von Dokumenten an. Der Verschlüsselungsdienst bietet für XML, PDF/A, Text, TIFF und Binärdaten die hybride Ver- und Entschlüsselung nach dem CMS-Standard [12] [RFC5652] bzw. die symmetrische Ver- und Entschlüsselung mittels AES-GCM an. Zudem wird für XML-Dokumente die hybride Ver- und Entschlüsselung nach [12] [XMLEnc] unterstützt und für MIME-Dokumente die hybride Ver-/Entschlüsselung nach [12] [S/MIME] unterstützt. Dem Konnektor werden durch das Clientsystem die zu verschlüsselnden und zu entschlüsselnden Dokumente übergeben und beim Verschlüsseln eines Dokuments die vorgeschlagenen Empfänger des Dokuments angegeben. Vor dem Verschlüsseln eines Dokuments wird die Gültigkeit der zu benutzenden Verschlüsselungszertifikate geprüft. 15 / 43 Zertifizierungsreport BSI-DSZ-CC-1174-2021 Sicherheits- funktionalität des EVG Thema TLS-Kanäle Der Netzkonnektor stellt dem Anwendungskonnektor TLS-Kanäle zur Verfügung. Die Verwaltung von TLS-Kanälen wird duch den Anwendungskonnektor durchgeführt. Der Anwendungskonnektor initiiert dabei den Auf- und Abbau der TLS-Kanäle und stellt den Endpunkt für das Senden und Empfangen der Nutzdaten dar. Für das VSDM Fachmodul wird zudem TLS Session Resumption unterstützt. Der Administrator kann konfigurieren, ob für Verbindungen zum Clientsystem TLS- Kanäle verwendet werden müssen (ANCL_TLS_MANDATORY, ANCL_CAUT_MANDATORY) und einen zertifikats oder passwortbasierten Authentisierungsmechanismus (ANCL_CAUT_MODE) festlegen. Für den Dienstverzeichnisdienst kann explizit die verpflichtende Nutzung von TLS deaktiviert werden (ANCL_DVD_OPEN). TLS-Kanäle werden unter anderem für die Kommunikation mit Fachdiensten, mit dem zentralen Verzeichnisdienst, dem KSR, dem TSL-Dienst, bei ANCL_TLS_MANDATORY = Enabled mit den Clientsystemen im LAN und mit den angebundenen eHealth-Kartenterminals verwendet. Sicherer Datenspeicher Der Konnektor stellt einen Datenspeicher zur Verfügung, in welchem er alle sicherheitskritischen, veränderlichen Daten dauerhaft speichert, die für seinen Betrieb relevant sind. Dieser Datenspeicher sichert die Vertraulichkeit der in ihm hinterlegten Daten bzw. der aus ihm entnommenen Daten. Der Konnektor stellt den in ihm laufenden Fachmodulen ebenfalls eine Nutzung dieses Datenspeichers für deren sensible Daten zur Verfügung. Fachmodul VSDM Das Fachmodul Versicherten Stammdaten Management (VSDM) ist fester Bestandteil des EVG und ermöglicht es, Versichertenstammdaten einer eGK zu lesen, zu schreiben oder um neue Einträge zu ergänzen. Die eGK wird dabei über den Kartenterminaldienst und den Kartendienst angesprochen. Das VSDM- Fachmodul kann über die Management-Oberfläche administriert werden. Sicherheitsmanageme nt Der Konnektor verwaltet verschiedene Rollen, wie Administrator, Clientsystem, Kartenterminals und Chipkarten. Auf die Management-Schnittstelle hat nur ein autorisierter Administrator Zugriff. Dieser kann zum Beispiel Kartenterminals managen, Arbeitsplätze konfigurieren, Sicherheitsrichtlinien und TLS-Kanäle verwalten. Dazu gehört auch das Verwalten von Software Updates für den EVG und angebundene Kartenterminals, Verwalten von Zertifikaten und Durchführen eines Werksresets. Insbesondere kann der Administrator die Online-Anbindung des Konnektors im Netz des Leistungserbringers konfigurieren (MGM_LU_ONLINE) und die QES-Funktionalität des Signaturdienstes de/- aktivieren (MGM_LU_SAK). Die öffentlichen Schlüssel der CVC root CA sind in der gSMC-K gespeichert und können nur durch das CMS System der gSMC-K gelöscht werden. Über Cross-CVC-Zertifikate können durch den Anwendungskonnektor aber weitere öffentliche Schlüssel der CVC root CA eingebracht werden. 16 / 43 BSI-DSZ-CC-1174-2021 Zertifizierungsreport Sicherheits- funktionalität des EVG Thema Schutz der TSF Der Konnektor kann die für QES und nonQES benötigten Zertifikate interpretieren, sowie Verschlüsselungszertifikat und CV-Zertifikate. Zudem werden Informationen gültiger TSL- und CRL-Listen in die Prüfungen einbezogen sowie BNetzA-VL bzw. die entsprechenden Hashwerte. Die Zulässigkeit importierter zu signierender bzw. zu prüfender signierten Daten wird bei Bedarf gemäß NFDM-Signaturrichtlinie geprüft. Der Konnektor setzt die in [13] [gemSpec_Kon], TAB_KON_503, definierten Fehlbetriebszustände um (Error Condition). Wird ein sicherheitsrelevanter Betriebszustand erreicht, schränkt der Konnektor seine Funktionalität gemäß [13] [gemSpec_Kon], TAB_KON_504, ein. Vor der regulären Kommunikation mit einem eHealth-Kartenterminal wird geprüft, ob dieses gepairt ist und im Infomodell des Konnektors korrekt zugeordnet wurde. Ebenso werden gesteckte Chipkarten identifiziert und auf Gültigkeit geprüft. Bei entfernter PIN-Eingabe wird geprüft ob Kartenterminal und HBA für diesen Verwendungsfall zugelassen sind, Der Konnektor führt beim Anlauf und regelmäßig während des Normalbetriebs Selbsttests durch. Neben Selbsttests im Rahmen des sicheren Start-Up- Prozesses wird insbesondere auch die Implementierung der Trusted Channels (VPN und TLS) beim Hochfahren getestet. Im Normalbetrieb werden regelmäßig die Funktionalitäten AES und TLS getestet. Durch den sicheren Start-Up-Prozess wird die Integrität des TOEs auf einen sicheren Vertrauensanker im BIOS zurückgeführt. Durch Neustart des Konnektors können die damit verbundenen Prüfungen durch einen Benutzer jederzeit wiederholt werden. Die vom Anwendungskonnektor erzeugten Protokolleinträge des Sicherheitsprotokolls werden mit einem zuverlässigen Zeitstempel versehen. Der Anwendungskonnektor greift dabei auf die Echtzeituhr zurück, die in regelmäßigen Abständen und auf Anforderung des Administrators mit einem vertrauenswürdigen Zeitdienst synchronisiert wird. Sicherheits- protokollierung Der EVG führt ein Sicherheits-Log gemäß Konnektor-Spezifikation [13] [gemSpec_Kon]. Nur der Administrator kann Protokolleinträge einsehen. Protokolleinträge können nicht verändert werden und nicht explizit gelöscht werden. Ältere Einträge werden rollierend überschrieben. VAU-Kanal Der Konnektor unterstützt das ePA Fachmodul mit dem Aufbau einer sicheren Verbindung zur Vertrauenswürdigen Ausführungsumgebung (VAU) gemäß VAU- Kommunikationsprotokoll. Dabei wird ein sicherer Kanal auf HTTP- Anwendungsschicht zwischen dem Client und der VAU (Server) aufgebaut. SGD-Kanal Der Konnektor unterstützt das ePA-Fachmodul bei der Nutzung der Schlüsselableitungsfunktionalität im Zusammenhang der ePA Fachanwendung. Der Gesamtablauf der Schlüsselableitungsfunktionalität für den Konnektor als Client ist aufgeteilt zwischen Basiskonnektor und Fachmodul. Die kryptographischen Vorgaben (u.a. Durchführung des ECDH, Schlüsselerzeugung, Ver- und Entschlüsselung, Signaturerzeugung und -prüfung) werden dabei durch den Konnektor realisiert. Tabelle 1: Sicherheitsfunktionalität des EVG Mehr Details sind in den Sicherheitsvorgaben [6] Kapitel 7 dargestellt. Die Werte, die durch den EVG geschützt werden, sind in den Sicherheitsvorgaben [6], Kapitel 3.1, definiert. Basierend auf diesen Werten stellen die Sicherheitsvorgaben die 17 / 43 Zertifizierungsreport BSI-DSZ-CC-1174-2021 Sicherheitsumgebung in Form von Annahmen, Bedrohungen und organisatorischen Sicherheitspolitiken in Kapitel 3.2, 3.3 und 3.4 dar. Dieses Zertifikat umfasst die in Kapitel 8 beschriebene Konfigurationen des EVG. Die Ergebnisse der Schwachstellenanalyse, wie in diesem Zertifikat bestätigt, erfolgte ohne Einbeziehung der für die Ver- und Entschlüsselung eingesetzten krypthographischen Algorithmen (vgl. §9 Abs. 4 Nr. 2 BSIG). Für Details siehe Kap. 9 dieses Berichtes. Dieses Zertifikat gilt nur für die angegebene Version des Produktes in der evaluierten Konfiguration und nur in Verbindung mit dem vollständigen Zertifizierungsreport. Dieses Zertifikat ist keine generelle Empfehlung des IT-Produktes durch das Bundesamt für Sicherheit in der Informationstechnik oder eine andere Organisation, die dieses Zertifikat anerkennt oder darauf Einfluss hatte. Eine Gewährleistung für das IT-Produkt durch das Bundesamt für Sicherheit in der Informationstechnik oder eine andere Organisation, die dieses Zertifikat anerkennt oder darauf Einfluss hatte, ist weder enthalten noch zum Ausdruck gebracht. 2. Identifikation des EVG Der Evaluierungsgegenstand (EVG) heisst: secunet konnektor 2.1.0, Version 4.1.3:2.1.0 Die folgende Tabelle beschreibt den Auslieferungsumfang: Nr Typ Identifier Version Auslieferungsart 1. HW secunet konnektor 2.1.0 Hardware für RZK (nicht Teil des EVG) Hardware Version: 2.1.0 (RZK7 ) BIOS FW Version: CSASR009, CSASR011 Das Gerät wird über eine sichere Lieferkette dem Endkunden zugestellt. 2. HW gSMC-Ks (nicht Teil des EVG) STARCOS 3.6 Health SMCK R1 oder TCOS Security Module Card - K Version 2.0 Release 1 Die gSMC-Ks sind in der Konnektor-Hardware verbaut. 3. SW secunet konnektor 2.1.0 Firmware TOE Version: 4.1.3:2.1.0 bestehend aus Netzkonnektor-Version: 4.1.38 Anwendungskonnektor-Version: 3.1.5 Die Software wird im Zuge der Fertigung auf die Hardware gebracht und über eine sichere Lieferkette ausgeliefert. Es besteht zusätzlich die Möglichkeit, dass die Software als Software- Update-Paket über KSR verteilt werden kann. 7 Bei der Variante Rechenzentrumskonnektor handelt es sich um zwei Einbox-Konnektoren, die (ohne Einbox-Gehäuse) in einem 19 Zoll Gehäuse mit einer Höheneinheit verbaut sind. 8 Die Angabe gilt als Gesamtversion der Firmware, d.h. inkludiert die Anwendungskonnektor-Version. 18 / 43 BSI-DSZ-CC-1174-2021 Zertifizierungsreport Nr Typ Identifier Version Auslieferungsart 4. SW AMTS, NFDM und ePA Fachmodul Firmware (nicht Teil des EVG) NFDM-Fachmodul: secunet Fachmodul NFDM 2.1.2 AMTS-Fachmodul: secunet Fachmodul AMTS 2.1.2 ePA-Fachmodul: secunet Fachmodul ePA 3.1.5 Die Fachmodule sind integraler Bestandteil des Anwendungskonnektor- Image. 5. DOC Associated guidance documentation secunet(konnektor, Modularer Konnektor Version 2.0.0 und 2.1.0, Bedienungsanleitung, Für Administratoren und Benutzer, Version 3.0, 22.04.2021, Secunet Security Networks AG SHA256: AEA5D6ECBD25AAC76E97303A8B7647E3 FD78D17AB3C4FB2285C1491CE9295995 Errata Version 1.0, 06.05.2021, Errata der Bedienungsanleitung Version 3.0, Produkttypversion: 4.8.2-0 (PTV4) Firmwareversion: 4.1.3, secunet Konnektor 2.0.0 und 2.1.0 SHA256: 8A9CA5FB0CFA99320C3DF20EF7D1B89A 1AB25A41CF6FE99292A36E696910969E Die Handbücher können auf der Herstellerwebseite heruntergeladen werden. secunet(konnektor v2.0.0, Sichere Lieferkette – Hinweise und Prüfpunkte für Endnutzer, secunet Security Networks AG, Version 1.8, 31.10.2019 SHA256: 5D7B1F22E54EC1C59D1E74A3EDC0D820 7C919576F54B9EBF7BF360B9D39E5F8E Konnektor Management API- Dokumentation, eHealthExperts, Version 3.0.2, Stand 21.01.2021 SHA256: 5392C0D794F9FEB43C36A269CBA791F5 B4F5EB4894C30053E6DEBD10ED5E531A Die REST-API Spezifikation der Management-Schnittstelle wird im Handbuch erwähnt und nur auf Anfrage durch den Hersteller gezielt ausgeliefert. Security Guidance Fachmodulentwicklung; eHealthExperts; v.1.5; 19.04.2021 SHA256: 8CF0B092EC51D3CAC35C8A7B36FFB810 CD4F618309B79281295153C2FEF61F77 Die Security Guidance Fachmodulentwicklung wird nur intern den Fachmodul-Entwicklern zur Verfügung gestellt. Tabelle 2: Auslieferungsumfang des EVG Die sichere Lieferkette wird in den folgenden Dokumenten [9] und [10] [b] beschrieben. Die Anweisungen an den Nutzer, wie die Einhaltung der sicheren Lieferkette überprüft werden kann, sind in [10] [b] beschrieben. Das Gerät, das den EVG beinhaltet, ist in einem Gehäuse untergebracht, und verfügt über die Hardwareanschlüsse, die für den Betrieb des Konnektors nötig sind. Die gSMC-Ks befinden sich ebenfalls in diesem Gehäuse. 19 / 43 Zertifizierungsreport BSI-DSZ-CC-1174-2021 Die Version des EVG kann über die grafische Benutzeroberfläche ermittelt werden. Eine Beschreibung dazu findet sich in [10] [a], Kapitel 9.5.6. Im Bereich “Version” werden Produktdaten und Versionsangaben angezeigt, wie zum Beispiel Firmware Version (EVG Version), die Hardware Version der unterliegenden Hardware sowie die Seriennummer des Geräts. Mit “Details” können weitere Einzelheiten zum System angezeigt werden, wie zum Beispiel die Version der Anwendungskonnektor Komponente. Die im Konnektor verbaute gSMC-Ks können anhand der Identifikationsnummer (ICCSN) ermittelt werden, siehe [10] [a], Kapitel 9.3.1. Die ICCSN der Karte besteht aus 20 Stellen. Die elfte Stelle der ICCSN gibt dabei an, ob im secunet konnektor 2.1.0 gSMC-Ks vom Typ STARCOS (Wert 0 oder 2) oder TCOS (Wert 1) verbaut sind (siehe [10] [a], Tabelle 19 bzw. [10] [a], Tabelle 21). 3. Sicherheitspolitik Die Sicherheitspolitik wird durch die funktionalen Sicherheitsanforderungen ausgedrückt und durch die Sicherheitsfunktionalität des EVG umgesetzt. Sie behandelt die folgenden Sachverhalte: Der EVG implementiert logische Sicherheitsfunktionalität, um schützenswerte Daten, die vom EVG gespeichert und verarbeitet werden, während des Betriebs in einer sicheren Einsatzumgebung zu schützen. So erhält der EVG die Integrität gespeicherter Daten durch seine Möglichkeiten zur Konfiguration, Speicherzugriff und seiner umgesetzten Sicherheitsfunktionen. Daher setzt der EVG um, dass Sicherheitsfehlfunktionen unterbleiben und schützenswerte Daten nicht abfließen. Weitere Details hierzu können den Sicherheitsvorgaben, [6], Abschnitt 6, entnommen werden. 4. Annahmen und Klärung des Einsatzbereiches Die in den Sicherheitsvorgaben definierten Annahmen sowie Teile der Bedrohungen und organisatorischen Sicherheitspolitiken werden nicht durch den EVG selbst abgedeckt. Diese Aspekte führen zu Sicherheitszielen, die durch die EVG-Einsatzumgebung erfüllt werden müssen. Hierbei sind die folgenden Punkte relevant: ● OE.NK.CS: Korrekte Nutzung des Konnektors durch Clientsysteme und andere aktive Komponenten im LAN ● OE.NK.Admin_EVG: Sichere Administration des Netzkonnektors ● OE.NK.phys_Schutz: Physischer Schutz des EVG ● OE.NK.Betrieb_CS: Sicherer Betrieb der Clientsysteme ● OE.AK.sichere_TI: Sichere Telematikinfrastruktur-Plattform ● OE.AK.Admin_EVG: Sichere Administration des Anwendungskonnektors ● OE.AK.Plattform: Sichere Plattform ● OE.AK.PKI: PKI für Signaturdienste, Verschlüsselung und technische Komponenten ● OE.AK.Clientsystem: Sichere Clientsysteme ● OE.AK.SW-Update: Prozesse für sicheres Software-Update Details finden sich in den Sicherheitsvorgaben [6], Kapitel 4.3 und 4.4. 20 / 43 BSI-DSZ-CC-1174-2021 Zertifizierungsreport 5. Informationen zur Architektur Der EVG ist ein Softwareprodukt, das auf dem Betriebssystem Linux basiert. Dieser Abschnitt liefert eine Übersicht über die Subsysteme des EVG und die entsprechenden TSF, die Gegenstand dieser Evaluierung waren. Die Sicherheitsfunktionen des EVG sind: Netzkonnektor: ● VPN-Client ● Dynamischer Paketfilter mit zustandsgesteuerter Filterung ● Netzdienste (Zeitsynchronisation und Zertifikatsprüfung) ● Stateful Packet Inspection ● Selbstschutz (Speicheraufbereitung, Selbsttests, Schutz von Geheimnissen und Seitenkanalresistenz, Sicherheits-Log) ● Administration (Administrator-Rollen, Management-Funktionen, Authentisierung der Administratoren, gesicherte Wartung und Software Update) ● Kryptographische Basisdienste ● TLS-Kanäle unter Nutzung sicherer kryptographischer Algorithmen Anwendungskonnektor: ● Identifikation und Authentisierung ● Zugriffsberechtigungsdienst ● Kartenterminaldienst ● Kartendienst ● Signaturdienst ● Software-Update ● Verschlüsselungsdienst ● TLS-Kanäle ● Sicherer Datenspeicher ● Fachmodul VSDM ● Sicherheitsmanagement ● Schutz der TSF ● Sicherheitsprotokollierung ● VAU-Kanal ● SGD-Kanal Entsprechend dem TOE Design werden diese Sicherheitsfunktionen von folgenden Subsystemen umgesetzt: ● Konnektor-Basissystem ● Subsystem VPN ● TLS-Basis Subsystem ● Konnektormanagement Subsystem 21 / 43 Zertifizierungsreport BSI-DSZ-CC-1174-2021 ● Laufzeitumgebung Subsystem ● Fachmodul-VSDM Subsystem ● Subsystem Anwendungskonnektor PTV3 ● Subsystem Anwendungskonnektor PTV4 6. Dokumentation Die evaluierte Dokumentation, die in Tabelle 2 aufgeführt ist, wird zusammen mit dem Produkt zur Verfügung gestellt. Hier sind die Informationen enthalten, die zum sicheren Umgang mit dem EVG in Übereinstimmung mit den Sicherheitsvorgaben benötigt werden. Zusätzliche Hinweise und Auflagen zum sicheren Gebrauch des EVG, die im Kapitel 10 enthalten sind, müssen befolgt werden. 7. Testverfahren Zur Bestätigung aller Sicherheitsfunktionen des EVG wurden folgende Methoden angewendet: ● automatisiertes Testen aller TSFI ● manuelles Testen aller TSFI ● Sourcecode-Reviews ● Netzwerktests einschließlich gezielter Tests der Protokolle IPsec und TLS Für das Testen durch die Prüfstelle wurden sowohl die Ausprägungen “Release” als auch “Extended Release” verwendet. Diese Ausprägungen sind konsistent mit den Angaben im Security Target. Bei Tests und Schwachstellenanalyse wurde systematisch das Angreiferpotential “Enhanced-Basic” (AVA_VAN.3) unterstellt. Die tatsächlichen Ergebnisse des Testens entsprachen den erwarteten und spezifizierten Ergebnissen. Bei der Schwachstellenanalyse wurden zuerst veröffentlichte Schwachstellen auf ihre Relevanz in der Einsatzumgebung des EVG untersucht und ggf. weiteren Tests und Analysen unterzogen. Es wurde unter Berücksichtigung des unterstellten Angriffsniveau keine ausnutzbare Schwachstelle identifiziert. In den Fällen, bei denen die Tests nicht an der finalen Version, sondern an anderen Versionen durchgeführt wurden, haben die Evaluatoren eine Analyse der Änderungen des EVG zwischen getesteter und finaler Version anhand der bereitgestellten Beschreibungen des Herstellers und insbesondere des Source-Codes durchgeführt. Die Evaluatoren kamen dabei zu dem Schluss, dass eine Wiederholung der Tests an der aktuellen EVG Version nicht notwendig ist, da die jeweils getestete Sicherheitsfunktion sich nicht geändert hat und durch die anderen Änderungen am EVG nicht beeinflusst wird. Die an den jeweiligen Vorversionen erhaltenen Testergebnisse sind vollständig auf die finale Version 4.1.3 übertragbar. Herstellertests 22 / 43 BSI-DSZ-CC-1174-2021 Zertifizierungsreport Der Hersteller hat zwei verschiedene Testumgebungen bereitgestellt, die im Folgenden beschrieben werden. Die meisten Tests wurden dabei an der Testumgebung „ANKE“ durchgeführt. Die Sicherheitsvorgaben [6] beschreiben nur eine einzelne Konfiguration für den EVG. In [6], Abschnitt 1.3.2 wird die sogenannte "Einbox-Lösung" als einzige Konfiguration des Evaluierungsgegenstandes angegeben. Bei der Variante Rechenzentrumskonnektor handelt es sich um zwei Einbox-Konnektoren, die (ohne Einbox-Gehäuse) in einem 19 Zoll Gehäuse mit einer Höheneinheit verbaut sind. Testansatz des Herstellers Der Testansatz des Herstellers ist das direkte Testen der SFRs. Diese SFRs sind wiederum auf die sicherheitsrelevanten Schnittstellen (TSFIs) des EVGs abgebildet. Die einzelnen Testfälle sind direkt aus den Anforderungen in [13] abgeleitet. Zusätzlich wurden weitere Testfälle durch den Hersteller implementiert, die nicht direkt auf Anforderungen der gematik Spezifikation zurückzuführen sind, aber Sicherheitsfunktionen adressieren, die in den Sicherheitsvorgaben [6] definiert sind. Alle relevanten Testfälle wurden auf SFRs abgebildet und jedes SFR ist von mindestens einem Testfall abgedeckt, In Einzelfällen wurde begründet, wie die korrekte Umsetzung der Sicherheitsfunktion bereits auf andere Weise verifiziert wird (z. B. durch Source Code Analyse). Um sicherzustellen, dass die Sicherheitsfunktionalität, wie sie in der Funktionalen Spezifikation beschrieben ist, vollständig durch Testfälle abgedeckt wird, hat der Hersteller eine Abdeckungsanalyse aller SFRs durch TSFIs und umgekehrt durchgeführt. Jedes TSFI wird durch Testfälle abgedeckt. Testumgebung ANKE Für jeden Test existiert eine XML Datei, in der die notwendigen Informationen enthalten sind, um den Testfall auszuführen; unter anderem die von der Testumgebung aus- zuführenden Test-Module, deren Parameter und die Test-Evaluatoren. Die Test-Engine und die entsprechenden Test-Module sind in der Programmiersprache Java implementiert und verwenden die Java-Laufzeitumgebung (JRE) inklusive deren Netzwerkfunktionalität. Die Testlogik ist in einzelnen Test-Modulen enthalten, die für die jeweiligen Testfälle mit unterschiedlichen Parametern aufgerufen und kombiniert werden können. Dabei können Test-Module für beliebige Testfälle wiederverwendet werden. Das Testergebnis einzelner Testfälle wird durch separate Evaluator-Module bewertet, die ebenfalls bei der Zusammenstellung der einzelnen Testfälle mehrfach verwendet werden. Die Schnittstellen werden durch Test-Module getestet, die in der Testumgebung des Herstellers eingebaut sind. Jedes Test-Modul testet dabei eine definierte Funktionalität. Testumgebung NWTU Der Hersteller hat neben der oben beschriebenen Testumgebung eine weitere Testumgebung für die Ausführung bestimmter Testfälle bereitgestellt. Diese alternative Netzwerktestumgebung wurde für Testszenarien, die auf das Testen von Netzwerk- funktionen abzielen und nicht ohne erheblichen Aufwand mit der anderen Testumgebung umgesetzt werden können, entwickelt. Die Testfälle sind als Unix Shell Scripts implementiert. Nach jeder Testausführung wird eine Logdatei erstellt, die das jeweilige Testergebnis PASSED, FAILED oder ABORTED enthält. 23 / 43 Zertifizierungsreport BSI-DSZ-CC-1174-2021 Die AK-Funktionalität wurde hauptsächlich mit der Test-Engine ConCuTE (ANKE) getestet. Der NK-Teil wurde mit der Test-Engine cons10t (ANKE) und in der Testumgebung NWTU geprüft. Testergebnisse Es wurden keine Abweichungen zwischen erwartetem und tatsächlichem Verhalten des EVG festgestellt. Unabhängige Tests der Prüfstelle Die unabhängigen Evaluatortests wurden mit den Testumgebungen des Herstellers durchgeführt. Zudem kamen weitere Testwerkzeuge der Prüfstelle zum Einsatz, z. B. Tools zum Versenden und Empfangen von REST-Befehlen. Für Testzwecke wurde der Prüfstelle die sogenannte "Extended Release" Variante des EVG zur Verfügung gestellt. Dadurch wurden Untersuchungen des EVG insbesondere für den AVA-Aspekt vereinfacht und zum Teil überhaupt erst möglich gemacht (z. B. durch Zugriff auf das Betriebssystem). Die Extended Release Variante soll dabei neben den nötigen Anpassungen möglichst gering von der finalen Produktversion abweichen. Die Unterschiede zwischen EVG und Extended Release Variante wurden im Rahmen der Evaluierung untersucht. Weiterhin wurden alle automatisierten Testfälle der Herstellertestumgebung wiederholt. Testergebnisse Insgesamt wurden keine Abweichungen zwischen erwarteten und tatsächlichen Testergebnissen festgestellt. Penetrationstests der Prüfstelle Alle Konfigurationen des EVG, die von dieser Evaluierung abgedeckt sind, wurden getestet. Testergebnisse Insgesamt wurden keine Abweichungen zwischen erwarteten und tatsächlichen Testergebnisse festgestellt. Es war kein Angriffsszenario, welches einen Angreifer mit Angriffspotential Enhanced-Basic voraussetzt, in der Betriebsumgebung, wie sie im Schutzziel [6] definiert ist, erfolgreich durchführbar. Diese gilt unter der Annahme, dass alle Maßnahmen die vom Hersteller an den sicheren Betrieb gestellt sind auch umgesetzt werden. 8. Evaluierte Konfiguration Dieses Zertifikat bezieht sich auf die Konfiguration „Einbox-Lösung“9 als einzige Konfiguration des EVG (siehe [6], Kapitel 1.3). Der Administrator kann über die Benutzeroberfläche die Version des EVG auslesen. 9 Konkret: Bei der Variante Rechenzentrumskonnektor handelt es sich um zwei Einbox-Konnektoren, die (ohne Einbox-Gehäuse) in einem 19 Zoll Gehäuse mit einer Höheneinheit verbaut sind. 24 / 43 BSI-DSZ-CC-1174-2021 Zertifizierungsreport 9. Ergebnis der Evaluierung 9.1. CC spezifische Ergebnisse Der Evaluierungsbericht (Evaluation Technical Report, ETR) [7] wurde von der Prüfstelle gemäß den Gemeinsamen Kriterien [1], der Methodologie [2], den Anforderungen des Schemas [3] und allen Anwendungshinweisen und Interpretationen des Schemas (AIS) [4] erstellt, die für den EVG relevant sind. Die Evaluierungsmethodologie CEM [2] wurde verwendet. Für die Analyse des Zufallszahlengenerators wurde AIS 20 verwendet (siehe [4]). Die Verfeinerungen der Anforderungen an die Vertrauenswürdigkeit, wie sie in den Sicherheitsvorgaben beschrieben sind, wurden im Verlauf der Evaluation beachtet. Das Urteil PASS der Evaluierung wird für die folgenden Vertrauenswürdigkeitskomponenten bestätigt: ● Alle Komponenten der Vertrauenswürdigkeitsstufe EAL 3 der CC (siehe auch Teil C des Zertifizierungsreports) ● Die zusätzlichen Komponenten ADV_FSP.4, ADV_TDS.3, ADV_IMP.1, ALC_TAT.1, AVA_VAN.3 und ALC_FLR.2 Die Evaluierung hat gezeigt: ● PP Konformität: Common Criteria Schutzprofil (Protection Profile) Schutzprofil 2: Anforderungen an den Konnektor, Version 1.5.9, BSI-CC-PP-0098-V3-2021 vom 15.04.2021 [8] ● Funktionalität: PP konform plus produktspezifische Ergänzungen Common Criteria Teil 2 erweitert ● Vertrauenswürdigkeit: Common Criteria Teil 3 konform EAL 3 mit Zusatz von ADV_FSP.4, ADV_TDS.3, ADV_IMP.1, ALC_TAT.1, AVA_VAN.3 und ALC_FLR.2 Die Ergebnisse der Evaluierung gelten nur für den EVG gemäß Kapitel 2 und für die Konfigurationen, die in Kapitel 8 aufgeführt sind. 9.2. Ergebnis der kryptographischen Bewertung Die folgende Tabelle gibt einen Überblick über die zur Durchsetzung der Sicherheitspolitik im EVG enthaltenen kryptographischen Funktionalitäten und verweist auf den jeweiligen Anwendungsstandard in dem die Eignung festgestellt ist. # Zweck Kryptographischer Mechanismus Implementier ungsstandar d Schlüssellänge in Bit Anwendun gsstandard Kommentar 1 Authentizität RSA Verifikation von Signaturen für VPN und TLS sha256withRSAEnc ryption (OID 1.2.840.113549.1.1. [RFC-8017] (PKCS#1) [FIPS 180-4] (SHA) 2048 Bit [gemSpec _Krypt] Kap. 3.3.1 und Kap. 3.3.2 FPT_TDC.1/NK.Zert FPT_TDC.1/ NK.TLS.Zert 25 / 43 Zertifizierungsreport BSI-DSZ-CC-1174-2021 11) 2 ECDSA Verifikation von Signaturen für VAU Protokoll ecdsa-with-Sha256 (OID 1.2.840.10045.4.3.2 ) [gemSpec_K rypt], Kap. 6 (VAU) [TR-03111] ECDSA [RFC-5639] brainpool [FIPS 180-4] (SHA-256) Schlüssellänge entsprechend der verwendeten elliptischen Kurve brainpoolP256r1 ([RFC5639]) [gemSpec _Krypt], Kap. 6 FPT_TDC.1/SGDVAU 3 ECDSA Signatur Erzeugung mit Unterstützung der SMC-B oder eGK und Verifikation für den SGD Klient ecdsa-with-Sha256 (OID 1.2.840.10045.4.3.2 ) [TR-03111] ECDSA [RFC-5639] brainpool [FIPS 180-4] (SHA-256) Schlüssellänge entsprechend der verwendeten elliptischen Kurve brainpoolP256r1 ([RFC5639]) [gemSpec _Krypt], Kap. 3.15 (SGD) FPT_TDC.1/SGDVAU FCS_COP.1.1/SGD.Auth Anmerkung: Im SGD Protokoll findet nur Authentifizierung und keine Authentisierung statt, da der zu signierende Inhalt vom SGD-Client gewählt wird oder bekannt ist. Im VAU Protokoll Authentisiert sich der Client durch die Signatur über die „VAUServerHelloData“, siehe Tabellenzeile 9. 4 Verifikation von Signaturen der TSL mit RSASSA-PSS [RFC-8017] (PKCS#1) [FIPS 180-4] (SHA) [RFC-6931] (XMLDSig) 2048 Bit [gemSpec _Krypt], Kap. 3.14 FPT_TDC.1/NK.Zert FPT_TDC.1/ NK.TLS.Zert FPT_TDC.1/AK 5 Verifikation von Signaturen der CRL mit RSASSA- PKCS1-v1_5 sha256WithRSAEn cryption [RFC-8017] (PKCS#1) [FIPS 180-4] (SHA) 2048 Bit [gemSpec _Krypt], Kap. 3.14 FPT_TDC.1/NK.Zert FPT_TDC.1/ NK.TLS.Zert FPT_TDC.1/AK 6 Verifikation von Signaturen der BNetzA-VL RSASSA-PSS mit Hash Funktion SHA-{256, 512} und ECDSA mit Hash Funktion SHA-{256,384,512} [RFC 8017] (PKCS#1) [TR-03111] (ECDSA) [FIPS 180-4] (SHA) 2048 - 8192 Bit für RSA Für ECDSA: Schlüssellänge entsprechend der verwendeten elliptischen Kurvenbrainpool P{256,384,512}r 1 ([RFC7027]) NIST P- {256,384,521} ([FIPS186-4]) FRP256v1 [ANSSI-0241] [gemSpec _PKI], Kap. 8.5.2 [ETSI_TS_ 119_612] FPT_TDC.1/AK 7 Verifikation von [TR-03111] Schlüssellänge [gemSpec FPT_TDC.1/NK.Zert 26 / 43 BSI-DSZ-CC-1174-2021 Zertifizierungsreport Signaturen der TSL und CRL mit ECDSA ecdsa-with-SHA256 ECDSA [RFC-5639] brainpool [FIPS 180-4] (SHA-256) entsprechend der verwendeten elliptischen Kurve brainpoolP256r1 ([RFC5639]) _Krypt], Kap. 5.3 FPT_TDC.1/ NK.TLS.Zert FPT_TDC.1/AK 8 Authentisieru ng RSA Signatur Erzeugung mit Unterstützung der gSMC-K und Verifikation für VPN und TLS sha256withRSAEnc ryption (OID 1.2.840.113549.1.1. 11) sha384withRSAEnc ryption (OID 1.2.840.113549.1.1. 12) (für TLS) sha512withRSAEnc ryption (OID 1.2.840.113549.1.1. 13) (für TLS) [RFC-8017] (RSASSA- PKCS1- v1_5) [FIPS 180-4] (SHA) 2048 Bit [gemSpec _Krypt], Kap. 3.3.1 FCS_COP.1/NK.Auth FCS_COP.1/ NK.TLS.Auth 9 ECDSA Signatur Erzeugung mit Unterstützung der SMC-B oder eGK und Verifikation für das VAU Protokoll ecdsa-with-Sha256 (OID 1.2.840.10045.4.3.2 ) [gemSpec_K rypt], Kap. 6 (VAU) [TR-03111] ECDSA [RFC-5639] brainpool [FIPS 180-4] (SHA-256) Schlüssellänge entsprechend der verwendeten elliptischen Kurve brainpoolP256r1 ([RFC5639]) [gemSpec _Krypt], Kap. 6 FCS_COP.1.1/VAU.Auth 10 Schlüsselaus handlung Diffie-Hellman Schlüsselaushandlu ng (DH) für VPN (IPsec IKEv2, diffie- hellman group 14) [HaC] (DH) [RFC-3526] (DH Group) [RFC-7296] (IKEv2) DH: Gruppe 14 2048 Bit Exponentenläng e 2047 Bits [gemSpec _Krypt], Kap. 3.3.1 FCS_CKM.2/NK.IKE 11 Diffie-Hellman Schlüsselaushandlu ng (DH) und Elliptic Curve Diffie- Hellman Schlüsselaushandlu ng (ECDH) für TLS [HaC] (DH) [SEC1] (ECDH), [RFC-5246] (TLS v1.2) [RFC-3268] (DHE_RSA) [RFC-4492] (ECDHE_RS A) [RFC-3526] (DH Gruppe 14) DH: Gruppe 14 2048 Bit Exponentenläng e = 2048 Bits ECDH: Schlüssellänge entsprechend der verwendeten elliptischen Kurven P- {256,384} ([FIPS186-4]) und [gemSpec _Krypt], Kap. 3.3.2 FCS_CKM.1/NK.TLS 27 / 43 Zertifizierungsreport BSI-DSZ-CC-1174-2021 brainpoolP{256, 384}r1 ([RFC7027]) 12 Elliptic Curve Diffie- Hellman Schlüsselaushandlu ng (ECDH) für VAU Protokoll [gemSpec_K rypt], Kap. 6 (VAU) [NIST-800- 56- A#5.7.1.2] (ECDH) [RFC-5639] (brainpool) Schlüssellänge entsprechend der verwendeten elliptischen Kurve brainpoolP256r1 ([RFC5639]) [gemSpec _Krypt], Kap. 6 FCS_CKM.1/VAU 13 Schlüsselabl eitung HMAC Berechnung für VPN (PRF) PRF-HMAC-SHA-1, PRF-HMAC-SHA- 256 [IANA] mit [RFC- 8247#2.2] [FIPS 180-4] (SHA) [RFC-2404] (HMAC) [RFC-7296] (IKEv2) 128 Bit und 256 Bit [gemSpec _Krypt], Kap. 3.3.1 FCS_COP.1/NK.HMAC 14 Schlüsselableitung für TLS 1.2 [RFC-5246] (TLS v1.2) [FIPS-180-4] (SHA), [RFC-2104] (HMAC) 128 Bit und 256 Bit [gemSpec _Krypt], Kap. 3.3.2 FCS_CKM.1/NK.TLS 15 Schlüsselableitung mit HKDF für das VAU Protokoll [gemSpec_K rypt], Kap. 6 (VAU) [FIPS 180-4] (SHA) [RFC-5869] (HKDF) 256 Bit [gemSpec _Krypt], Kap. 6 (VAU) FCS_CKM.1/VAU 16 Schlüsselgen erierung RSA Schlüssel generierung im X.509 und PKCS#12 Format [RFC4055] (sup. [RFC5280]), [RFC7292] (PKCS#12) [FIPS186-4] (Method B.3.3) 2048 Bit TR 03116- 1 FCS_CKM.1/NK.Zert 17 Integrity HMAC Berechnung und Prüfung für VPN HMAC mit SHA-1, SHA-256 [FIPS 180-4] (SHA) [RFC-2104] (HMAC) [RFC-2404] (HMAC- SHA-1 mit ESP) [RFC-4868] (HMAC- SHA-2 mit 160 Bit und 256 Bit [gemSpec _Krypt], Kap. 3.3.1 FCS_COP.1/NK.HMAC 28 / 43 BSI-DSZ-CC-1174-2021 Zertifizierungsreport IPsec) [RFC-7296] (IKEv2) 18 HMAC Berechnung und Prüfung für TLS HMAC mit SHA-1, SHA-256 und SHA- 384 [FIPS 180-4] (SHA) [RFC-2104] (HMAC) [RFC-5246] (TLS v1.2) 160 Bit, 256 Bit und 384 Bit [gemSpec _Krypt], Kap. 3.3.2 FCS_COP.1/ NK.TLS.HMAC 19 Vertraulichkei t Symmetrische Verschlüsselung und Entschlüsselung mittels ESP für VPN Kommunikation AES-CBC (OID 2.16.840.1.101.3.4. 1.42) [FIPS 197] (AES) [RFC-3602] (AES-CBC) [RFC-4303] (ESP) [RFC-4301] (IPsec) 256 Bit [gemSpec _Krypt], Kap. 3.3.1 FCS_COP.1/NK.IPsec FCS_COP.1/NK.ESP 20 Symmetrische Verschlüsselung und Entschlüsselung für TLS v1.2 AES-128 und AES- 256 in CBC [FIPS 197] (AES) [RFC-3602] (AES-CBC) [RFC-3268] (AES-TLS mit DH) [RFC-4492] (AES-TLS mit ECDH) 128 Bit und 256 Bit [gemSpec _Krypt], Kap. 3.3.2 FCS_COP.1/ NK.TLS.AES 21 Vertraulichkei t mit Nachrichtena uthentizität (Authenticate d Encryption) AES-128 und AES- 256 in GCM Mode für TLS 1.2 [FIPS 197] (AES) [RFC-3268] (AES-TLS) [SP 800- 38D] (GCM) [RFC-5289] (AES-GCM- TLS) [RFC-5116] (AEAD) 128 Bit und 256 Bit [gemSpec _Krypt], Kap. 3.3.2 FCS_COP.1/ NK.TLS.AES 22 AES-256 in GCM Mode für VAU Kommunikation [gemSpec_K rypt], Kap. 6 (VAU) [FIPS 197] (AES) [SP 800- 38D] (GCM) [RFC-5116] (AEAD) 256 Bit und 128 Bit Tag länge [gemSpec _Krypt], Kap. 6 FCS_COP.1/VAU.AES 23 ECIES basierte hybride Verschlüsselung und [gemSpec_K rypt], Kap. 3.15 (SGD) [SEC1-2009] ECDH: Schlüssellänge entsprechend der verwendeten [gemSpec _Krypt], Khap. 3.15 FCS_COP.1/ SGD.ECIES 29 / 43 Zertifizierungsreport BSI-DSZ-CC-1174-2021 Entschlüsselung mit Nachrichtenauthenti zität und ECC Schlüsselgenerieru ng mittels ECIES mit brainpoolP256r1, HKDF mit SHA-256 und AES-256 in GCM Mode (ECIES) [NIST-800- 56- A#5.7.1.2] (ECDH) [RFC-5639] (brainpool) [FIPS 180-4] (SHA) [RFC-5869] (HKDF) [FIPS 197] (AES) [SP 800- 38D] (GCM) [RFC-5116] (AEAD) elliptischen Kurve brainpoolP256r1 ([RFC5639]) AES-GCM: 256 Bit AES und 128 Bit Tag länge 24 Sichere Kanäle TLS v1.2 [RFC-5246] (TLS v1.2) [SMD3_AK] [SMD3_MS_ AK] - [gemSpec _Krypt], Kap. 3.3.2 FTP_ITC.1/NK.TLS FTP_TRP.1/NK.Admin 25 VPN IPsec (IKEv2) mit Zertifikatbasierter Authentisierung [RFC-4301] (IPsec) [RFC-4303] (ESP) [RFC-7296] (IKEv2) [SMD3_NK] [SMD3_MS] - [gemSpec _Krypt], Kap. 3.3.1 FTP_ITC.1/NK.VPN_TI FTP_ITC.1/NK.VPN_SIS 26 VAU Protokoll Kommunikation entsprechend der Vorgaben des ePA- Aktensystems für den Austausch von Nachrichtenmit der VAU [gemSpec_K rypt], Kap. 6 (VAU) - [gemSpec _Krypt], Kap. 6 FTP_ITC.1/VAU 27 SGD Protokoll (ECIES) Kommunikation entsprechend der Vorgaben des ePA- Aktensystems für den Austausch von Nachrichten mit dem SGD-HSM [gemSpec_K rypt], Kap. 3.15 (SGD) - [gemSpec _Krypt], Kap. 3.15 FTP_ITC.1/SGD Anmerkung: Die abgesicherte Kommunikation zwischen SGD-Klient und SGD-HSM wird als Sicherer Kanal (trusted channel) im [ST] modelliert. 28 Authentizität PAdES basierte Signaturerzeugung mit SHA-256 und Unterstützungvon [RFC-8017] (PKCS#1) [TR-03111] ECDSA [RFC-5639] RSA: 1976 Bit bis 4096 Bit ECC: Schlüssellänge [gemSpec _Krypt], Kap. 3.12 [gemSpec _Krypt], Signatur Verifikation: FDP_DAU.2/AK.Sig FDP_DAU.2/AK.QES FCS_COP.1/ 30 / 43 BSI-DSZ-CC-1174-2021 Zertifizierungsreport HBA oder SMC-B und Verifikation mit SHA-{256, 384, 512} im Format RSASSA-PKCS1- v1_5 RSASSA-PSS und ECDSA (nur für SHA-256) brainpool [PAdES] [PAdES_BP] [FIPS 180-4] (SHA) entsprechend der verwendeten elliptischen Kurve brainpoolP256r1 ([RFC5639]) Kap. 3.8 AK.SigVer.SSA FCS_COP.1/ AK.SigVer.PSS FCS_COP.1/ AK.SigVer.ECDSA FCS_COP.1/ AK.PDF.SigPr Hash: FCS_COP.1/AK.SHA Generierung des signierten Dokumentes: FCS_COP.1/ AK.PDF.Sign Die digitalen Signaturen werden durch die Chipkarten erzeugt. 29 CAdES basierte Signaturerzeugung mit SHA-256 und Unterstützung von HBA oder SMC-B und Verifikation mit SHA-{256, 384, 512} im Format RSASSA-PKCS1- v1_5 RSASSA-PSS und ECDSA (nur für SHA-256) [RFC-8017] (PKCS#1) [TR-03111] ECDSA [RFC-5639] brainpool RFC-5652] (CMS) [CAdES] [CADES_BP ] [FIPS 180-4] (SHA) RSA: 1976 Bit bis 4096 Bit ECC: Schlüssellänge entsprechend der verwendeten elliptischen Kurve brainpoolP256r1 ([RFC5639]) [gemSpec _Krypt], Kap. 3.12 [gemSpec _Krypt], Kap. 3.7 Signatur Verifikation: FDP_DAU.2/AK.Sig FDP_DAU.2/AK.QES FCS_COP.1/ AK.SigVer.SSA FCS_COP.1/ AK.SigVer.PSS FCS_COP.1/ AK.SigVer.ECDSA FCS_COP.1/ AK.CMS.SigPr Hash: FCS_COP.1/AK.SHA Generierung des signierten Dokumentes: FCS_COP.1/ AK.CMS.Sign Die digitalen Signaturen werden durch die Chipkarten erzeugt. 30 XAdES basierte Signaturerzeugung mit SHA-256 und Unterstützung von HBA oder SMC-B und Verifikation mit SHA-{256, 384, 512} im Format RSASSA-PKCS1- v1_5 RSASSA-PSS und [RFC-8017] (PKCS#1) [TR-03111] ECDSA [RFC-5639] brainpool [XMLSig] [XAdES] [XAdES_BP] [FIPS 180-4] (SHA) RSA: 1976 Bit bis 4096 Bit ECC: Schlüssellänge entsprechend der verwendeten elliptischen Kurve brainpoolP256r1 ([RFC5639]) [gemSpec _Krypt], Kap. 3.12 [gemSpec _Krypt], Kap. 3.1 Signatur Verifikation: FDP_DAU.2/AK.QES FCS_COP.1/ AK.SigVer.SSA FCS_COP.1/ AK.SigVer.PSS FCS_COP.1/ AK.SigVer.ECDSA FCS_COP.1/ AK.XML.SigPr Hash: FCS_COP.1/AK.SHA 31 / 43 Zertifizierungsreport BSI-DSZ-CC-1174-2021 ECDSA (nur für SHA-256) Generierung des signierten Dokumentes: FCS_COP.1/ AK.XMLS.Sign Die digitalen Signaturen werden durch die Chipkarten erzeugt. 31 Vertraulichkei t mit Nachrichtena uthentizität (Authenticate d Encryption) Hybride Dokumenten Ver- und Entschlüsselung (XML, MIME, CMS) mit RSAES-OAEP und AES-GCM [FIPS 197] (AES) [SP 800- 38D] (AES GCM) [RFC-8017] (RSAOAEP) [XMLEnc] (XML) [RFC-5751] (S/MIME) with [RFC-5083] (CMS Authenticate d- Enveloped- Data Content Type) [RFC-5084] (AES-GCM in CMS) [RFC-5652] (CMS) RSA ENC: 2048 Bit (RSAOAEP) AES-GCM-ENC: 256 Bit AES-GCM-DEC: 128, 192, 256 Bit [gemSpec _Krypt], Kap. 3.1.5 und 3.5 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 Asymmetrische Entschlüsselung des AES Schlüssels wird durch die Chipkarten durchgeführt (HBA, SMC-B oder eGK) 32 Hybride Dokumenten Ver- und Entschlüsselung (XML, CMS) mit ECIES und AES-GCM für Dokument Ver- und Entschlüsselung [gemSpec_C OS] Kapitel 6.8.1.4 (ECIES) [RFC-5639] (brainpool) [FIPS 197] (AES) [SP 800- 38D] (AES GCM) [XMLEnc] (XML) [RFC-5652] (CMS) ECC: Schlüssellänge entsprechend der verwendeten elliptischen Kurve brainpoolP256r1 ([RFC5639]) AES-GCM-ENC: 256 Bit AES-GCM-DEC: 128, 192, 256 Bit [gemSpec _Krypt], chap. 5.7 FCS_COP.1/AK.AES FCS_COP.1/ AK.XML.Ver FCS_COP.1/ AK.XML.Ent FCS_COP.1/ AK.CMS.Ver FCS_COP.1/ AK.CMS.Ent ECIES Entschlüsselung wird mit Unterstützung der Chipkarten durchgeführt (HBA, SMC-B oder eGK) 33 Schlüsselerz eugung AES Schlüsselerzeugung für Hybride Verschlüsselung durch Verwendung sicherer Zufallszahlen [SP800-133], Kap. 6.1 (Schlüsseler zeugung) 256 Bit [gemSpec _Krypt], Kap. 3.1.5 und 3.5 Erzeugung von AES Schlüsseln: FCS_CKM.1/AK.AES Tabelle 3: kryptografische Funktionen des EVG 32 / 43 BSI-DSZ-CC-1174-2021 Zertifizierungsreport Gemäß [gemSpec_Krypt] und [TR03116-1] sind die Algorithmen geeignet für den jeweiligen Zweck. Die kryptografische Stärke dieser Algorithmen wurde in diesem Zertifizierungsverfahren nicht bewertet (siehe BSIG §9, Abs. 4, 2). Jedoch können kryptografische Funktionen mit einem Sicherheitsniveau unterhalb von 100 Bit nicht länger als sicher angesehen werden, ohne den Anwendungskontext zu beachten. Deswegen muss geprüft werden, ob diese kryptografischen Funktionen für den vorgesehenen Verwendungszweck angemessen sind. Weitere Hinweise und Anleitungen können der 'Technischen Richtline BSI TR-02102' (https://www.bsi.bund.de) entnommen werden. Die folgende Tabelle gibt einen Überblick über die zur Durchsetzung der Sicherheitspolitik im EVG enthaltenen kryptographischen Funktionalitäten und legt deren Bewertung des Sicherheitsniveaus aus kryptographischer Sicht dar. Jede kryptografische Funktion, die in der Spalte 'Sicherheitsniveau mehr als 100 Bit' ein 'Nein' enthält, erreicht nur ein Sicherheitsniveau unterhalb von 100 Bit (im allgemeinen Anwendungsfall). # Zweck Kryptographischer Mechanismus Implementier ungsstandar d Schlüsselläng e in Bit Sicherheits niveau über 100 Bit Kommentar 1 Authentizität GPG RSA Signatur Verifikation mit RSASSA-PKCS1- 1.5 und SHA-512 [RFC-4880] (OpenPGP) [RFC-8017] (RSA), [FIPS 180-4] (SHA) 2048 Bit Ja Signature Verifikation des Firmware Updates FDP_ITC.1/NK.Update FDP_UIT.1/NK.Update 2 RSA Signatur Verifikation mit RSASSA-PSS und SHA-256 [RFC-8017] (RSA), [FIPS 180-4] (SHA) 4096 Bit Ja Signatur Verifikation von UpdateInfo.xml und FirmwareGroupInfo.xml FDP_ITC.1/NK.Update FDP_UIT.1/NK.Update 3 Schlüsselerze ugung Schlüsselerzeugun g für die Backup- Verschlüsselung mit sicheren Zufallszahlen [ARC_AK] [SP800-133] 256 Bit Ja FMT_MTD.1/ AK.eHKT_Abf 4 Vertraulichkeit mit Nachrichtena uthentizität (Authenticate d Encryption) Hybride Verschlüsselung der Backup-Daten mit RSAOAEP und AES-GCM Passwortbasierte Verschlüsselung des Backup- Schlüssels mit AES-ECB [RFC-8017] (RSAOAEP) [FIPS 197] (AES) [NIST-SP- 800-38A] (AES ECB) [NIST-SP- 800-38D] (AES GCM) [RFC-8018] (PBE) [ARC_AK] RSA: 2048 Bit AES-GCM: 256 Passwort: >120 Bit Ja FMT_MTD.1/ AK.eHKT_Abf Tabelle 4: Kryptografische Funktionen des EVG (Update-Mechanismus) 33 / 43 Zertifizierungsreport BSI-DSZ-CC-1174-2021 10. Auflagen und Hinweise zur Benutzung des EVG Die in Tabelle 2 genannte Betriebsdokumentation enthält die notwendigen Informationen zur Anwendung des EVG und alle darin enthaltenen Sicherheitshinweise sind zu beachten. Zusätzlich sind alle Aspekte der Annahmen, Bedrohungen und Politiken wie in den Sicherheitsvorgaben dargelegt, die nicht durch den EVG selbst, sondern durch die Einsatzumgebung erbracht werden müssen, zu berücksichtigen. Der Anwender des Produktes muss die Ergebnisse dieser Zertifizierung in seinem Risikomanagementprozess berücksichtigen. Um die Fortentwicklung der Angriffsmethoden und -techniken zu berücksichtigen, sollte er ein Zeitintervall definieren, in dem eine Neubewertung des EVG erforderlich ist und vom Inhaber dieses Zertifikates verlangt wird. Die Begrenzung der Gültigkeit der Verwendung der kryptographischen Algorithmen wie in Kapitel 9 dargelegt muss ebenso durch den Anwender und seinen Risikomanagementprozess für das IT-System berücksichtigt werden. Zertifizierte Aktualisierungen des EVG, die die Vertrauenswürdigkeit betreffen, sollten verwendet werden, sofern sie zur Verfügung stehen. Stehen nicht zertifizierte Aktualisierungen oder Patches zur Verfügung, sollte er den Inhaber dieses Zertifikates auffordern, für diese eine Re-Zertifizierung bereitzustellen. In der Zwischenzeit sollte der Risikomanagementprozess für das IT-System, in dem der EVG eingesetzt wird, prüfen und entscheiden, ob noch nicht zertifizierte Aktualisierungen und Patches zu verwenden sind oder zusätzliche Maßnahmen getroffen werden müssen, um die Systemsicherheit aufrecht zu erhalten. Zusätzlich sind die folgenden Auflagen und Hinweise zu beachten: Der EVG kann seine Sicherheitsleistung nur unter den folgenden Bedingungen erbringen: ● Die EVG-Konfiguration sieht eine verpflichtende Nutzung von TLS sowie eine verpflichtende Client-System-Authentisierung vor. ● Die angeschlossenen Client-Systeme verifizieren die Authentizität des Konnektors, wenn sie dessen Dienste nutzen oder Ereignisse empfangen. ● Der Benutzer ist in der Lage zu identifizieren, dass die Verbindung zu einem Client- System sicher ist. Der EVG-Benutzer soll (shall) den EVG nur dann betreiben, wenn die oben genannten Bedingungen erfüllt sind. Ein Verstoß oder eine Nichterfüllung dieser Bedingungen wird als eine Schwachstelle des EVG bezüglich der Einsatzumgebung verstanden. In diesem Fall ist der EVG-Benutzer dafür verantwortlich Gegenmaßnahmen gegen diese Schwachstelle zu ergreifen. Der EVG unterstützt unterschiedliche Betriebskonfigurationen. Die wesentlichen Konfigurationen sind: „Parallel”-, „inReihe”- und „Offline“-Modus. Die empfohlene Konfiguration ist der Konfigurationsmodus „inReihe”, da dieser eine höhere Sicherheit der angeschlossenen LAN-seitigen Netzwerke bietet, siehe Bedienhandbuch [10] [a], Kapitel 10.2.1.2. Für aktive VPN-Verbindungen, die IPSec nutzen, sind im EVG keine Gegenmaßnahmen gegen die statistische Datenverkehrsanalyse implementiert. 34 / 43 BSI-DSZ-CC-1174-2021 Zertifizierungsreport 11. Sicherheitsvorgaben Die Sicherheitsvorgaben [6] werden zur Veröffentlichung in einem separaten Dokument im Anhang A bereitgestellt. 12. Definitionen 12.1. Abkürzungen AIS Anwendungshinweise und Interpretationen zum Schema BSI Bundesamt für Sicherheit in der Informationstechnik / Federal Office for Information Security, Bonn, Germany BSIG BSI-Gesetz / Act on the Federal Office for Information Security CCRA Common Criteria Recognition Arrangement CC Common Criteria for IT Security Evaluation - Gemeinsame Kriterien für die Prüfung und Bewertung der Sicherheit von Informationstechnik CEM Common Methodology for Information Technology Security Evaluation - Gemeinsame Evaluationsmethodologie für die Prüfung und Bewertung der Sicherheit von Informationstechnik cPP Collaborative Protection Profile EAL Evaluation Assurance Level – Vertrauenswürdigkeitsstufe eGK Elektronische Gesundheitskarte ESP Encapsulating Security Payload ETR Evaluation Technical Report EVG Evaluierungsgegenstand gSMC-K Sicherheitsmodul für den Konnektor HBA Heilberufsausweis HMAC Keyed-Hash Message Authentication Code IKE Internet Key Exchange Protocol IP Internet Protocol IPSec Internet Protocol Security IT Information Technology - Informationstechnologie ITSEF Information Technology Security Evaluation Facility - Prüfstelle für IT- Sicherheit KSR Konfigurations- und Software-Repository LAN Local Area Network NK Network connector nonQES Nicht-Qualifizierte elektronische Signatur PKI Public Key Infrastructure PP Protection Profile – Schutzprofil 35 / 43 Zertifizierungsreport BSI-DSZ-CC-1174-2021 QES Qualifizierte elektronische Signatur SAK Signaturanwendungskomponente SAR Security Assurance Requirement – Vertrauenswürdigkeitsanforderungen SHA Secure Hash Algorithm SF Security Function - Sicherheitsfunktion SFP Security Function Policy - Politik der Sicherheitsfunktion SFR Security Functional Requirement - Funktionale Sicherheitsanforderungen SIS Secure Internet Service ST Security Target – Sicherheitsvorgaben TI Telematikinfrastruktur TLS Transport Layer Security TOE Target of Evaluation - Evaluierungsgegenstand TSC TSF Scope of Control - Anwendungsbereich der TSF-Kontrolle TSF TOE Security Functionality – EVG-Sicherheitsfunktionalität TSL Trust-service Status List VPN Virtual Private Network WAN Wide Area Network 12.2. Glossar Erweiterung - Das Hinzufügen von funktionalen Anforderungen, die nicht in Teil 2 enthalten sind, und/oder von Vertrauenswürdigkeitsanforderungen, die nicht in Teil 3 enthalten sind. Evaluationsgegenstand – Software, Firmware und / oder Hardware und zugehörige Handbücher. EVG-Sicherheitsfunktionalität - Eine Menge, die die gesamte Hardware, Software, und Firmware des EVG umfasst, auf die Verlass sein muss, um die SFR durchzusetzen. Formal - Ausgedrückt in einer Sprache mit beschränkter Syntax und festgelegter Semantik, die auf bewährten mathematischen Konzepten basiert. Informell - Ausgedrückt in natürlicher Sprache. Objekt - Eine passive Einheit im EVG, die Informationen enthält oder empfängt und mit der Subjekte Operationen ausführen. Schutzprofil - Eine implementierungsunabhängige Menge von Sicherheitsanforderungen für eine Kategorie von EVG. Semiformal - Ausgedrückt in einer Sprache mit beschränkter Syntax und festgelegter Semantik. Sicherheitsfunktion - Ein Teil oder Teile eines EVG, auf die zur Durchsetzung einer hierzu in enger Beziehung stehenden Teilmenge der Regeln der EVG-Sicherheitspolitik Verlass sein muss. 36 / 43 BSI-DSZ-CC-1174-2021 Zertifizierungsreport Sicherheitsvorgaben - Eine implementierungsabhängige Menge von Sicherheitsanforderungen für eine Kategorie von EVG. Subjekt - Eine aktive Einheit innerhalb des EVG, die die Ausführung von Operationen auf Objekten bewirkt. Zusatz - Das Hinzufügen einer oder mehrerer Anforderungen zu einem Paket. 13. Literaturangaben [1] Gemeinsame Kriterien für die Prüfung und Bewertung der Sicherheit von Informationstechnik (Common Criteria for Information Technology Security Evaluation/CC), Version 3.1 Part 1: Introduction and general model, Revision 5, April 2017 Part 2: Security functional components, Revision 5, April 2017 Part 3: Security assurance components, Revision 5, April 2017 https://www.commoncriteriaportal.org [2] Gemeinsame Evaluationsmethodologie für die Prüfung und Bewertung der Sicherheit von Informationstechnik (Common Methodology for Information Technology Security Evaluation (CEM), Evaluation Methodology, Version 3.1, Rev. 5, April 2017, https://www.commoncriteriaportal.org [3] BSI-Zertifizierung: Verfahrendokumentation zum Zertifizierungsprozess (CC- Produkte) und Verfahrensdokumentation zu Anforderungen an Prüfstellen, die Anerkennung und Lizenzierung (CC-Stellen), https://www.bsi.bund.de/zertifizierung [4] Anwendungshinweise und Interpretationen zum Schema (AIS), die für den EVG relevant sind10 https://www.bsi.bund.de/AIS [5] Deutsche IT-Sicherheitszertifikate (BSI 7148), periodisch aktualisierte Liste, die auch auf der Internet-Seite des BSI veröffentlicht wird, https://www.bsi.bund.de/zertifizierungsreporte [6] Sicherheitsvorgaben BSI-DSZ-CC-1174-2021, Version 1.3, 07.05.2021, Security Target für secunet konnektor 2.1.0 (eHealth Konnektor PTV4), secunet Security Networks AG [7] Evaluierungsbericht, Version 1.2, 27.05.2021, Evaluation Report - Evaluation Technical Report (ETR), SRC Security Research & Consulting GmbH, Dateiname: 1163_1174_ETR_210527_v12.docx (vertrauliches Dokument) [8] Common Criteria Schutzprofil (Protection Profile), Schutzprofil 2: Anforderungen an den Konnektor, BSI-CC-PP-0098, Version 1.5.9 vom 15.04.2021, Bundesamt für Sicherheit in der Informationstechnik (BSI) [9] Dokument zur sicheren Lieferkette: secunet(konnektor Version 2.0.0 und 2.1.0, Hinweise zur sicheren Lagerung und Lieferkette, Version 1.9, 04.11.2019 10 insbesondere • AIS 20, Version 3, Funktionalitätsklassen und Evaluationsmethodologie für deterministische Zufallszahlengeneratoren • AIS 32, Version 7, CC-Interpretationen im deutschen Zertifizierungsschema • AIS 34, Version 3, Evaluation Methodology for CC Assurance Classes for EAL 5+ (CCv2.3 & CCv3.1) and EAL 6 (CCv3.1) 37 / 43 Zertifizierungsreport BSI-DSZ-CC-1174-2021 [10] EVG-Handbücher: [a] secunet(konnektor, Modularer Konnektor Version 2.0.0 und 2.1.0, Bedienungsanleitung, Für Administratoren und Benutzer, Version 3.0, 22.04.2021, Secunet Security Networks AG Inklusive Errata Version 1.0, 06.05.2021, Errata der Bedienungsanleitung Version 3.0, Produkttypversion: 4.8.2-0 (PTV4) Firm-wareversion: 4.1.3, secunet Konnektor 2.0.0 und 2.1.0 [b] secunet(konnektor v2.0.0, Sichere Lieferkette – Hinweise und Prüfpunkte für Endnutzer, secunet Security Networks AG, Version 1.8, 31.10.2019 [c] Konnektor Management API-Dokumentation, eHealthExperts, Version 3.0.2, Stand 21.01.2021 [d] Security Guidance Fachmodulentwicklung; eHealthExperts; v.1.5; 19.04.2021 [11] Konfigurationsliste für den EVG (vertrauliche Dokumente) 210322_ALC_CMS_Modularar-Konnektor_NK-Implementierung_v2.4 1163_1044-V4_1174_1128-V3_References_secunet_konnektor v2.4.pdf Konfigurationsliste (ALC_CMS.4), Version 5.4, Datei: ALC_CMS_eHX_v5.4.xls Konfigurationsliste (ALC_CMS), Regulatory Affairs Document, S.I.E, Rev# 4.00, 01.07.2020 [12] Referenzen von Implementierungsstandards: [HaC] A. Menezes, P. van Oorschot und O. Vanstone. Handbook of Applied Cryptography. CRCPress, 1996. [FIPS180-4] NIST: FIPS PUB 180-4 Secure Hash Signature Standard (SHS), March 2012 [FIPS186-4] FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION 186-4: Digital Signature Standard (DSS); National Institute of Standards and Technology, July 2013 [FIPS197] Federal Information Processing Standards Publication 197: ADVANCED ENCRYPTION STANDARD (AES), NIST, November 2001 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997 [RFC2404] The Use of HMAC-SHA-1-96 within ESP and AH, Network Working Group, November 1998 [RFC3268] Chown, P., Advanced Encryption Standard (AES) Cipher suites for Transport Layer Security (TLS), RFC 3268, June 2002 [RFC3526] T. Kivinen, M.Kojo: More Modular Exponential (MODP) Diffie- Hellman groups for Internet Key Exchange (IKE). May 2003 [RFC3602] S .Frankel, R. Glenn, S. Kelly: The AES-CBC Cipher Algorithm and Its Use with IPsec. September 2003 [RFC4301] S. Kent, K. Seo: Security Architecture for the Internet Protocol, December 2005 [RFC4303] S. Kent: IP Encapsulating Security Payload (ESP), December 2005 38 / 43 BSI-DSZ-CC-1174-2021 Zertifizierungsreport [RFC4346] T. Dierks: The Transport Layer Security (TLS) Protocol, Version 1.1, April 2006 [RCF4492] Blake-Wilson, et al.: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS), May 2006 [RFC4868] S. Kelly, S. Frankel: Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec, May 2007 [RFC4880] J. Callas, L. Donnerhacke, H. Finney, D. Shaw, R. Thayer: OpenPGP Message Format, November 2007 [RFC5246] T. Dierks: The Transport Layer Security (TLS) Protocol, Version 1.2, August 2008 [RFC5289] E. Rescorla, TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM), August 2008 [RFC5996] C. Kaufman, P.Hoffman, Y.Nir, P.Eronen: Internet Key Exchange (IKEv2) Protocol, September 2010 [RFC7027] J. Merkle, M. Lochter, Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS), October 2013 [RFC7296] C. Kaufman, P.Hoffman, Y.Nir, P.Eronen, T. Kivinen: Internet Key Exchange Protocol Version 2 (IKEv2), October 2014 [RFC8017] K. Moriarty, B. Kaliski, J. Jonsson, A. Rusch: PKCS #1: RSA Cryptography Specifications Version 2.2. November 2016 [SMD3_AK] RFC-Analyse AK-TLS, Anwendungskonnektor, Version 1.0, 15.06.2020 [SMD3_MS_AK] Nachweis TLS Security, Version 1.0, 15.06.2020, TLSv12_MAY+SHOULD_v1.0.xlsx [SMD3_NK] secunet(konnektor Version 2.0.0, VPN-Analyse, Anforderungen an kryptographisch gesicherte VPN-Kanäle / Trusted Channels im deutschen CC- Zertifizierungsschema, Version 1.01, 24.07.2020 [SMD3_MS] IPsec-RFCs - MAY_SHOULD Anforderungen, secunet(konnektor, Ver-sion 0.99, 24.07.2020 [SP800-38D] NIST Special Publication 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, November, 2007 [13] Referenzen auf Anwendungsstandards: [gemSpec_Kon] Einführung der Gesundheitskarte: Konnektorspezifikation [gemSpec_Kon], gematik Gesellschaft für Telematikanwendungen der Gesundheitskarte mbH, Version 5.9.5, 04.12.2020 [gemSpec_Krypt] Einführung der Gesundheitskarte - Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur [gemSpec_Krypt], gematik Ge-sellschaft für Telematikanwendungen der Gesundheitskarte mbH, Ver-sion 2.16.2, 05.11.2020 [gemSpec_Net] Einführung der Gesundheitskarte: Übergreifende Spezifikation: Spezifikation Netzwerk [gemSpec_Net], gematik Gesellschaft für Telemati-kanwendungen der Gesundheitskarte mbH, Version 1.17.2, 04.12.2020 39 / 43 Zertifizierungsreport BSI-DSZ-CC-1174-2021 [gemProdT_Kon_PTV4] Produkttypsteckbrief Prüfvorschrift Konnektor gem- ProdT_Kon_PTV4_4.8.2-0_V1.0.0 [TR03116-1] Technische Richtlinie BSI TR-03116-1, Kryptographische Vorgaben für Projekte für der Bundesregierung, Teil 1: Telematikinfrastruktur, Version 3.20, 21.09.2018, Technische Arbeitsgruppe TR-03116 [14] [ARC_AK] eHealthExperts EHX Group, Security Architecture (ADV_ARC), Anwendungskonnektor, Version 2.5, 12.05.2020 40 / 43 BSI-DSZ-CC-1174-2021 Zertifizierungsreport C. Auszüge aus den Kriterien Die Bedeutung der Vertrauenswürdigkeitskomponenten und -stufen kann direkt den Common Criteria entnommen werden. Folgende Referenzen zu den CC können dazu genutzt werden: • Definition und Beschreibung zu Conformance Claims: CC Teil 1 Kapitel 10.5 • Zum Konzept der Vertrauenswürdigkeitsklassen, -familien und -kompomenten: CC Teil 3 Kapitel 7.1 • Zum Konzept der vordefinierten Vertrauenswürdigkeitsstufen (evaluation assurance levels - EAL): CC Teil 3 Kapitel 7.2 und 8 • Definition und Beschreibung der Vertrauenswürdigkeitsklasse ASE für Sicherheitsvorgaben / Security Target Evaluierung: CC Teil 3 Kapitel 12 • Zu detaillierten Definitionen der Vertrauenswürdigkeitskomponenten für die Evaluierung eines Evaluierungsgegenstandes: CC Teil 3 Kapitel 13 bis 17 • Die Tabelle in CC Teil 3 Anhang E fasst die Beziehung zwischen den Vertrauenswürdigkeitsstufen (EAL) und den Vertrauenswürdigkeitsklassen, -familien und -komponenten zusammen. Die Common Criteria sind unter https://www.commoncriteriaportal.org/cc/ veröffentlicht. 41 / 43 Zertifizierungsreport BSI-DSZ-CC-1174-2021 D. Anhänge Liste der Anhänge zu diesem Zertifizierungsreport Anhang A: Die Sicherheitsvorgaben werden in einem eigenen Dokument zur Verfügung gestellt. 42 / 43 BSI-DSZ-CC-1174-2021 Zertifizierungsreport Bemerkung: Ende des Reportes 43 / 43