BSI-DSZ-CC-1044-V8-2025
zu
secunet konnektor 2.0.0 und 2.1.0,
Version 5.70.4:2.0.0 und 5.70.4: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.94
BSI-DSZ-CC-1044-V8-2025 (*)
Gesundheitswesen: Konnektoren
secunet konnektor 2.0.0 und 2.1.0, Version 5.70.4:2.0.0 und 5.70.4:2.1.0
von secunet Security Networks AG
PP-Konformität: Common Criteria Schutzprofil (Protection Profile),
Schutzprofil 1: Anforderungen an den Netzkonnektor,
BSI-CC-PP-0097-V2-2020-MA-02, Version 1.6.7,
15.03.2023, Bundesamt für Sicherheit in der
Informationstechnik (BSI)
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_IMP.1,
ADV_TDS.3, ALC_TAT.1, AVA_VAN.5 und ALC_FLR.2
Gültig bis: 09. Juni 2030
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 und Anweisungen der Zertifizierungsstelle für Komponenten oberhalb
von EAL 5 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, 10. Juni 2025
Bundesamt für Sicherheit in der Informationstechnik
Im Auftrag
Fabian Hodouschek L.S.
Fachbereichsleiter
Bundesamt für Sicherheit in der Informationstechnik
Godesberger Allee 87 - 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
für Komponenten bis
EAL 4
Common Criteria
Recognition Arrangement
Anerkennung nur für
Komponenten bis EAL 2
und ALC_FLR
Zertifizierungsreport BSI-DSZ-CC-1044-V8-2025
Dies ist eine eingefügte Leerseite.
4 / 36
BSI-DSZ-CC-1044-V8-2025 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.....................................................................................................12
1. Zusammenfassung....................................................................................................13
2. Identifikation des EVG...............................................................................................16
3. Sicherheitspolitik........................................................................................................18
4. Annahmen und Klärung des Einsatzbereiches..........................................................18
5. Informationen zur Architektur.....................................................................................18
6. Dokumentation...........................................................................................................18
7. Testverfahren.............................................................................................................18
8. Evaluierte Konfiguration.............................................................................................21
9. Ergebnis der Evaluierung...........................................................................................21
10. Auflagen und Hinweise zur Benutzung des EVG.....................................................27
11. Sicherheitsvorgaben................................................................................................28
12. Definitionen..............................................................................................................28
13. Literaturangaben......................................................................................................31
C. Auszüge aus den Kriterien............................................................................................35
D. Anhänge........................................................................................................................ 36
5 / 36
BSI-DSZ-CC-1044-V8-2025 Zertifizierungsreport
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 und für Heimat
● 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]
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
7 / 36
Zertifizierungsreport BSI-DSZ-CC-1044-V8-2025
● 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
● 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 unter die Anerkennung nach den Regeln des SOGIS-MRA, d.h. bis
einschließlich der Komponenten nach CC Teil 3 EAL 4. Die Evaluierung beinhaltete die
Komponente AVA_VAN.5, die nicht nach den Regelungen des SOGIS-MRA anerkannt ist.
Für die Anerkennung ist hier die entsprechende EAL 4 Komponente maßgeblich.
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
4
Bekanntmachung des Bundesministeriums des Innern und für Heimat vom 12. Februar 2007 im
Bundesanzeiger, datiert 23. Februar 2007, S. 1941
8 / 36
BSI-DSZ-CC-1044-V8-2025 Zertifizierungsreport
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
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 und 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.0.0 und 2.1.0, Version 5.70.4:2.0.0 und 5.70.4:2.1.0 hat
das Zertifizierungsverfahren beim BSI durchlaufen. Es handelt sich um eine Re-
Zertifizierung basierend auf BSI-DSZ-CC-1044-V7-2023. Für diese Evaluierung wurden
bestimmte Ergebnisse aus dem Evaluierungsprozess BSI-DSZ-CC-1044-V7-
2023 wiederverwendet.
Die Evaluation des Produkts secunet konnektor 2.0.0 und 2.1.0, Version 5.70.4:2.0.0 und
5.70.4:2.1.0 wurde von SRC Security Research & Consulting GmbH durchgeführt. Die
Evaluierung wurde am 11. April 2025 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
5
Information Technology Security Evaluation Facility
9 / 36
Zertifizierungsreport BSI-DSZ-CC-1044-V8-2025
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.
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 10. Juni 2025, ist gültig bis 09. Juni 2030. 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.0.0 und 2.1.0, Version 5.70.4:2.0.0 und 5.70.4: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.
10 / 36
BSI-DSZ-CC-1044-V8-2025 Zertifizierungsreport
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
11 / 36
Zertifizierungsreport BSI-DSZ-CC-1044-V8-2025
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.
12 / 36
BSI-DSZ-CC-1044-V8-2025 Zertifizierungsreport
1. Zusammenfassung
Der Evaluierungsgegenstand (EVG) ist das Softwareprodukt Netzkonnektor, welcher die
Sicherheitsfunktionen einer Firewall, eines VPN-Clients, eines NTP-Servers, eines
Namensdienstes (DNS) und eines DHCP-Dienstes umfasst. Er enthält auch die
Grundfunktionen zum Aufbau sicherer TLS-Verbindungen zu anderen IT-Produkten. Der
Konnektor wird als Einboxkonnektor (EBK) oder als Rechenzentrumskonnektor (RZK) in
Form einer komplett geschlossenen Appliance umgesetzt.
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_IMP.1, ADV_TDS.3, ALC_TAT.1, AVA_VAN.5 und ALC_FLR.2.
Die funktionalen Sicherheitsanforderungen (Security Functional Requirements SFR) an
den EVG werden in den Sicherheitsvorgaben [6] Kapitel 6.2 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:
Sicherheitsfunktiona-
lität des EVG
Thema
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.
Informationsflusskon-
trolle
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 Paketfil-
ter
Der EVG implementiert einen dynamischen Paketfilter. Diese Anforderung wird als
Informationsflusskontrolle modelliert.
Die Filterregeln (packet filtering rules) sind mit geeigneten Default-Werten
vorbelegt und können vom Administrator für den SIS verwaltet werden.
Netzdienste: Zeitsyn-
chronisation
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 am Gehäuse
des Konnektors, u.a. auch für die Anzeige der Verbindung zur TI.
Netzdienste: Zertifikats-
prüfung
Der EVG überprüft die Gültigkeit der Zertifikate, die für den Aufbau der VPN-
Tunnel verwendet werden. Die erforderlichen Informationen zur Prüfung der
Gerätezertifikate werden dem EVG in Form einer (signierten) Trust-service Status
13 / 36
Zertifizierungsreport BSI-DSZ-CC-1044-V8-2025
Sicherheitsfunktiona-
lität des EVG
Thema
List (TSL) und einer Sperrliste (CRL) bereitgestellt. Der EVG prüft die Zertifikate
kryptographisch mittels der aktuell gültigen TSL und CRL.
Stateful Packet Inspec-
tion
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 Sitzung
zugeordnet und der Verbindungsstatus in die Entscheidung über die Zulässigkeit
eines Informationsflusses einbezogen wird.
Selbstschutz: Speicher-
aufbereitung
Der EVG löscht nicht mehr benötigte kryptographische Schlüssel (insbesondere
Sitzungsschlüssel 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: Selbst-
tests
Der EVG bietet seinen Benutzern die Möglichkeit, die eigene Integrität zu
überprüfen. 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 (u.a. 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 deren Resistenz gegen Seitenkanalangriffe geschützt. Der EVG verhindert
darüber hinaus den Abfluss von geheimen Informationen wirkungsvoll, etwa die
Sitzungsschlüssel der VPN-Verbindung oder zu schützende Daten der TI und der
Bestandsnetze.
Selbstschutz: Sicher-
heits-Log
Der EVG führt ein Sicherheits-Log gemäß Konnektorspezifikation [13],
[gemSpec_Kon].
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 EVG 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.
14 / 36
BSI-DSZ-CC-1044-V8-2025 Zertifizierungsreport
Sicherheitsfunktiona-
lität des EVG
Thema
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 Ba-
sisdienste
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 Nut-
zung sicherer krypto-
graphischer Algorith-
men
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 der
Konnektorspezifikation [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.
Tabelle 1: Sicherheitsfunktionalität des EVG
Mehr Details sind in den Sicherheitsvorgaben [6] Kapitel 6 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
Sicherheitsumgebung in Form von Annahmen, Bedrohungen und organisatorischen
Sicherheitspolitiken in den Kapiteln 3.5, 3.3 und 3.4 dar.
Dieses Zertifikat umfasst die in Kapitel 8 beschriebenen 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 kryptographischen
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
15 / 36
Zertifizierungsreport BSI-DSZ-CC-1044-V8-2025
dieses Zertifikat anerkennt oder darauf Einfluss hatte, ist weder enthalten noch zum
Ausdruck gebracht.
2. Identifikation des EVG
Der Evaluierungsgegenstand (EVG) heißt:
secunet konnektor 2.0.0 und 2.1.0, Version 5.70.4:2.0.0 und 5.70.4:2.1.0
Die folgende Tabelle beschreibt den Auslieferungsumfang:
Typ Identifikator Version Auslieferungsart
HW secunet konnektor 2.0.0 und
2.1.0 Hardware für Einbox-
Konnektor (EBK) oder
Rechenzentrumskonnektor
(RZK)
(nicht Teil des EVG)
Hardware Version:
2.0.0 (EBK)
2.1.0 (RZK)
BIOS FW Version: CSASR007 (nur
EBK), CSASR009, CSASR011
Das Gerät wird über eine
sichere Lieferkette dem
Endkunden zugestellt.
HW gSMC-Ks
(nicht Teil des EVG)
Kartentypen7
:
● STARCOS 3.6 Health SMCK R1
● TCOS Security Module Card – K
Version 2.0 Release 1
● STARCOS 3.7 gSMC-K R1
● TCOS Security Module Card – K
Version 2.0 Release 2
Die gSMC-Ks sind in der
Konnektor-Hardware
verbaut.
SW secunet konnektor 2.0.0 und
2.0.1 Firmware
EVG-Version:
5.70.4:2.0.0 (EBK)
5.70.4:2.1.0 (RZK)
jeweils bestehend aus:
Netzkonnektor-Version: 5.70.48
Anwendungskonnektor-Version: 5.70.3
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.
SW AMTS, NFDM und ePA
Fachmodul Firmware
(nicht Teil des EVG)
NFDM-Fachmodul: secunet Fachmodul
NFDM 5.1.1
AMTS-Fachmodul: secunet Fachmodul
AMTS 5.50.0
ePA-Fachmodul: secunet Fachmodul
ePA 5.70.0
Die Fachmodule sind
integraler Bestandteil des
Anwendungskonnektor-
Image.
7
Je Konnektor sind immer identische gSMC-Ks eines der hier genannten Kartentypen verbaut, die anhand
der Identifikationsnummer (ICCSN) ermittelt werden können, siehe Handbuch [10] [a].
8
Die Angabe gilt als Gesamtversion der Firmware, d.h. inkludiert die Version des Anwendungskonnektors.
16 / 36
BSI-DSZ-CC-1044-V8-2025 Zertifizierungsreport
Typ Identifikator Version Auslieferungsart
DOC Zugehörige Handbücher secunet(konnektor, Modularer
Konnektor Version 2.0.0 und 2.1.0,
Bedienungsanleitung, Für
Administratoren und Benutzer, Version
6.8.5, 10.04.2025, secunet Security
Networks AG
SHA256:
927c6d212e5fbfaf4426ecc274a938560
ac28f6b9f460e70a9ca917177ac3661
Die Handbücher können
auf der Herstellerwebseite
heruntergeladen werden.
DOC secunet(konnektor v2.0.0, 2.0.1 und
2.1.0, Sichere Lieferkette – Hinweise
und Prüfpunkte für Endnutzer, secunet
Security Networks AG, Version 2.0,
11.05.2023
SHA256:
ae467b545732b0f0814a3ff2c6771badb
b5f3d2dced8851bdfe4161f03f890e3
DOC Konnektor Management API-
Dokumentation, eHealth Experts
GmbH, Version 5.1.1, 07.08.2024
SHA256:
03a1b2946a61682d91f74e2974d2884c
e77978c280f9ba000fe22c71f64db522
Die REST-API
Spezifikation der
Management-Schnitt-
stelle wird im Handbuch
[10] [a], Kap. 8, erwähnt
und nur auf Anfrage durch
den Hersteller gezielt
ausgeliefert.
DOC Security Guidance
Fachmodulentwicklung; eHealth
Experts GmbH; v.1.6; 07.07.2023
SHA256:
ce65032c4d13467f3ea693c8a56913bc
3fdb6b4b4f2b3839d2c1eced686d0352
Die Security Guidance
Fachmodulentwicklung
wird nur intern den
Fachmodul-Entwicklern
zur Verfügung gestellt.
Tabelle 2: Auslieferungsumfang des EVG
Die sichere Lieferkette wird in [9] beschrieben. Die Anweisungen an den Nutzer, wie die
Einhaltung der sicheren Lieferkette überprüft werden kann, sind in [10] [b] beschrieben.
Das Gerät, welches den EVG beinhaltet, ist in einem Gehäuse untergebracht, und verfügt
über die Hardwareanschlüsse, die für den Betrieb des EVG notwendig sind. Die gSMC-Ks
befinden sich ebenfalls in diesem Gehäuse.
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 verbauten 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, welcher Typ der gSMC-Ks im Konnektor verbaut
ist, siehe [10] [a], Tabelle 20 und Kapitel 9.3.1.
17 / 36
Zertifizierungsreport BSI-DSZ-CC-1044-V8-2025
3. Sicherheitspolitik
Die Sicherheitspolitik wird durch die funktionalen Sicherheitsanforderungen ausgedrückt
und durch die Sicherheitsfunktionalität des EVG umgesetzt. Die durchgesetzte
Sicherheitspolitik ist durch eine ausgewählte Menge an SFRs definiert und wird vom EVG
umgesetzt. 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. Weitere Details hierzu können dem Security Target,
[6], Kap. 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. Insbesondere 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
Details und weitere Punkte finden sich in den Sicherheitsvorgaben [6], Kapitel 4.2.
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. Für die Sicherheitsfunktionen des EVG
siehe obige Tabelle 1: Sicherheitsfunktionalität des EVG.
Entsprechend dem EVG-Design werden diese Sicherheitsfunktionen unter anderem von
folgenden Subsystemen umgesetzt: Konnektor-Basissystem und VPN.
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
18 / 36
BSI-DSZ-CC-1044-V8-2025 Zertifizierungsreport
● 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
In den Fällen, bei denen die Tests nicht an der finalen Version, sondern an anderen
Versionen durchgeführt wurden, wurde eine Analyse der Änderungen am EVG zwischen
getesteter und finaler Version anhand der bereitgestellten Beschreibungen des Herstellers
und insbesondere des Source-Codes durchgeführt. Dabei konnte festgestellt werden, dass
eine Wiederholung der Tests an der finalen EVG-Version nicht notwendig ist, da die jeweils
getestete Sicherheitsfunktion sich nicht geändert hat und durch die Änderungen am EVG
nicht beeinflusst wird. Die an den jeweiligen Vorversionen erhaltenen Testergebnisse sind
somit vollständig auf die finale EVG-Version übertragbar.
Bei Tests und Schwachstellenanalyse wurde systematisch das Angriffspotential “High”
(AVA_VAN.5) 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 Angriffsniveaus keine ausnutzbare
Schwachstelle identifiziert.
Herstellertests
Der Hersteller hat zwei verschiedene Testumgebungen bereitgestellt, die im Folgenden
beschrieben werden. Die meisten Tests wurden dabei an der Testumgebung „ANKE“
durchgeführt.
Testumgebung ANKE
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-
19 / 36
Zertifizierungsreport BSI-DSZ-CC-1044-V8-2025
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.
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.
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.
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 und dabei
konnte festgestellt werden, dass diese Unterschiede keinen Einfluss auf die damit
erhaltenen Testergebnisse haben, insbesondere nicht auf die funktionalen Tests.
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
Die Konfiguration des EVG, die von dieser Evaluierung abgedeckt ist, wurde getestet.
Testergebnisse
20 / 36
BSI-DSZ-CC-1044-V8-2025 Zertifizierungsreport
Insgesamt wurden keine Abweichungen zwischen erwarteten und tatsächlichen
Testergebnisse festgestellt. Es war kein Angriffsszenario, welches einen Angreifer mit
hohem Angriffspotential (high attack potential) voraussetzt, in der Betriebsumgebung, wie
sie in den Sicherheitsvorgaben [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
Die evaluierte Konfiguration des EVG ist durch folgende Festlegungen definiert:
● secunet konnektor 2.0.0 und 2.1.0
◦ Vollständige Versionsangabe EBK: 5.70.4:2.0.0
◦ Vollständige Versionsangabe RZK: 5.70.4:2.1.0
● Zugehörige Dokumente:
◦ secunet(konnektor, Bedienungsanleitung, Für Administratoren und Benutzer,
Version 6.8.5, 10.04.2025, secunet Security Networks AG
◦ Konnektor Management API-Dokumentation, eHealthExperts, Version 5.1.1,
Stand 07.08.2024
◦ Security Guidance Fachmodulentwicklung; eHealthExperts; v1.6; 07.07.2023
◦ secunet(konnektor v2.0.0, 2.0.1 und 2.1.0, Sichere Lieferkette – Hinweise und
Prüfpunkte für Endnutzer, secunet Security Networks AG, Version
2.0,11.05.2023
Über die Benutzeroberfläche kann der Administrator die Version des EVG auslesen.
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 für die Komponenten bis zur
Vertrauenswürdigkeitsstufe 5 verwendet. Darüber hinaus wurde die in der AIS 34 [4]
definierte Methodologie 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 [6] Kap. 6.3 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)
21 / 36
Zertifizierungsreport BSI-DSZ-CC-1044-V8-2025
● Die zusätzlichen Komponenten
ADV_FSP.4, ADV_IMP.1, ADV_TDS.3, ALC_TAT.1, AVA_VAN.5 und ALC_FLR.2
Da die Evaluierung eine Re-Evaluierung zum Zertifikat BSI-DSZ-CC-1044-V7-2023
darstellt, konnten bestimmte Evaluierungsergebnisse wiederverwendet werden. Diese Re-
Evaluierung konzentrierte sich insbesondere auf folgende Bereiche: Neuer
deterministischer Zufallszahlengenerator (DRNG), welcher durch die verbaute gSMC-K
geseedet wird, Anpassung der Schlüsselgenerierung für die Software-Server- und
Clientsystem-Zertifikate und die Aktualisierung von Komponenten.
Die Evaluierung hat gezeigt:
● PP Konformität: Common Criteria Schutzprofil (Protection Profile), Schutzprofil
1: Anforderungen an den Netzkonnektor, BSI-CC-PP-0097-V2-2020-MA-02, Version
1.6.7, 15.03.2023, Bundesamt für Sicherheit in der Informationstechnik (BSI) [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_IMP.1, ADV_TDS.3, ALC_TAT.1, AVA_VAN.5
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 Kryptografische Funktion Implementie-
rungsstan-
dard
Schlüsselgröße in
Bit
Anwendungs-
standard
1. Authentizität RSA Verifikation von Signaturen
für VPN und TLS
sha256withRSAEncryption (OID
1.2.840.113549.1.1.11)
[RFC8017]
(PKCS#1)
[FIPS180-4]
(SHA)
VPN: 2048 bit
TLS: 2048 und 3072
bit
[gemSpec_Kry
pt] Kap. 3.3.1
und 3.3.2
2. ECDSA Verifikation von
Signaturen für TLS
ecdsa-with-SHA256 (OID
1.2.840.10045.4.3.2)
[FIPS 180-4]
(SHA-256)
[TR-03111]
(ECDSA)
[RFC-5639]
(brainpool)
Schlüssellänge ent-
sprechend der ver-
wendeten elliptischen
Kurven für brainpool-
P256r1 und NIST
P-256 ([FIPS186-4])
[gemSpec_Kry
pt] Kap. 3.3.1
und Kap. 3.3.2
3. ECDSA Verifikation von
Signaturen für VPN ecdsa-with-
SHA256 (OID
1.2.840.10045.4.3.2)
[FIPS 180-4]
(SHA-256)
[TR-03111]
(ECDSA)
[RFC-5639]
(brainpool)
Schlüssellänge ent-
sprechend der ver-
wendeten elliptischen
Kurven für brainpool-
P256r1 ([RFC5639])
[gemSpec
Krypt] Kap.
3.3.1 und Kap.
5.5
4. Verifikation von Signaturen der [RFC-8017] 2048 [gemSpec_Kry
22 / 36
BSI-DSZ-CC-1044-V8-2025 Zertifizierungsreport
# Zweck Kryptografische Funktion Implementie-
rungsstan-
dard
Schlüsselgröße in
Bit
Anwendungs-
standard
TSL mit RSASSA-PSS (PKCS#1)
[FIPS 180-4]
(SHA)
[RFC-6931]
(XMLDSig)
pt], Kap. 3.14
5. Verifikation von Signaturen der
CRL mit RSASSA-PKCS1-v1_5
sha256WithRSAEncryption
[RFC-8017]
(PKCS#1)
[FIPS 180-4]
(SHA)
2048 [gemSpec_Kry
pt], Kap. 3.14
6. Authentisie-
rung
RSA Signatur-Erzeugung mit
Unterstützung der gSMC-K und
-Verifikation für VPN und TLS
sha256withRSAEncryption (OID
1.2.840.113549.1.1.11)
sha384withRSAEncryption (OID
1.2.840.113549.1.1.12) (für
TLS) sha512withRSAEncryption
(OID 1.2.840.113549.1.1.13) (für
TLS)
[RFC8017]
(RSASSA-
PKCS1-v1_5)
[FIPS180-4]
(SHA)
VPN: 2048 bit
TLS: 2048 und 3072
bit
[gemSpec_Kry
pt] Kap. 3.3.1
7. ECDSA Signatur Erzeugung mit
Unterstützung der gSMC-K und
Verifikation für TLS
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 ent-
sprechend der ver-
wendeten elliptischen
Kurven brainpool-
P256r1 und NIST
P-256 ([FIPS186-4])
[gemSpec_Kry
pt], Kap. 3.3.2
8. ECDSA und RSA Signatur
Erzeugung mit Softwarezertifikat
für TLS
ecdsa-with-SHA256 (OID
1.2.840.10045.4.3.2)
sha256withRSAEncryption (OID
1.2.840.113549.1.1.11)
[TR-03111]
(ECDSA)
[RFC-5639]
(brainpool)
[FIPS 180-4]
(SHA-256)
[RFC-8017]
(RSASSA-
PKCS1-v1_5)
RSA: 2048 und 3072
Bit
ECDSA: Schlüssel-
länge entsprechend
der verwendeten ellip-
tischen Kurven brain-
poolP256r1 und NIST
P-256 ([FIPS186-4])
[gemSpec_Kry
pt], Kap. 3.3.2
9. ECDSA Signatur Erzeugung mit
Unterstützung der gSMC-K und
Verifikation für VPN 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 ent-
sprechend der ver-
wendeten elliptischen
Kurve brainpool-
P256r1 ([RFC5639])
[gemSpec_Kry
pt], Kap. 3.3.1
und 5.5
10. Schlüsse-
laushand-
lung
Diffie-Hellman
Schlüsselaushandlung (DH) für
VPN (IPsec IKEv2, diffie-
[HaC] (DH)
[RFC3526]
DH:
Gruppe 14,
[gemSpec_Kry
pt], Kap. 3.3.1
23 / 36
Zertifizierungsreport BSI-DSZ-CC-1044-V8-2025
# Zweck Kryptografische Funktion Implementie-
rungsstan-
dard
Schlüsselgröße in
Bit
Anwendungs-
standard
hellman group 14) (DH Group)
[RFC7296]
(IKEv2)
Siehe
Abweichunge
n [14], Kap. 4
2048 Bit
Exponenten-Länge
2047 Bit
11. Elliptic Curve Diffie-Hellman
Schlüsselaushandlung (ECDH)
für VPN
[SEC1]
(ECDH)
[RFC-7296]
(IKEv2)
[RFC-6954]
(ECC curves
for IKEv2)
Schlüssellänge ent-
sprechend der ver-
wendeten elliptischen
Kurven brainpool-
P256r1 ([RFC-6954])
[gemSpec_Kry
pt], Kap. 3.3.1
und Kap. 5.5
12. Diffie-Hellman Schlüsselaus-
handlung (DH) und Elliptic Cur-
ve Diffie-Hellman Schlüsselaus-
handlung (ECDH) für TLS
[HaC] (DH)
[SEC1]
(ECDH)
[RFC-5246]
(TLS v1.2)
[RFC-3268]
(DHE_RSA)
[RFC-4492]
(EC-
DHE_RSA)
[RFC-3526]
(DH Gruppe
14)
Siehe
Abweichunge
n [14], Kap. 4
DH:
Gruppe 14,
2048 Bit,
Exponentenlänge =
2048 Bit
ECDH:
Schlüssellängen ent-
sprechend der ver-
wendeten elliptischen
Kurven P-{256,384}
[FIPS 186-4] und
brainpoolP{256, 384}
r1 [RFC 7027]
[gemSpec_Kry
pt], Kap. 3.3.2
13. Schlüssela-
bleitung
HMAC Berechnung für VPN
(PRF)
PRF-HMAC-SHA-256
[IANA] mit
[RFC-8247],
#2.2
[FIPS 180-4]
(SHA)
[RFC-2404]
(HMAC)
[RFC7296]
(IKEv2)
256 [gemSpec_Kry
pt], Kap. 3.3.1
14. Schlüsselableitung für
TLS v1.2
[RFC-5246]
(TLS v1.2)
[FIPS-180-4]
(SHA)
[RFC-2104]
(HMAC)
128, 256 [gemSpec_Kry
pt], Kap. 3.3.2
24 / 36
BSI-DSZ-CC-1044-V8-2025 Zertifizierungsreport
# Zweck Kryptografische Funktion Implementie-
rungsstan-
dard
Schlüsselgröße in
Bit
Anwendungs-
standard
15. Schlüsselge-
nerierung
RSA Schlüsselgenerierung im
X.509- und PKCS#12-Format
[RFC4055]
(sup.
[RFC5280])
[RFC7292]
(PKCS#12)
[FIPS186-4]
(Method
B.3.3)
Siehe
Abweichunge
n [14], Kap. 4
3072 TR 03116-1
16. ECC Schlüsselgenerierung im
X.509 Format Elliptic Kurve Key
Pair Generation
[TR-03111]
(ECKeyPair)
Schlüssellänge ent-
sprechend der ver-
wendeten elliptischen
Kurve NIST P-256
([FIPS186-4])
TR 03116-1
17. Integrität HMAC Berechnung und Prüfung
für VPN
HMAC mit SHA-256
[FIPS180-4]
(SHA)
[RFC-2104]
(HMAC)
[RFC-4868]
(HMAC-
SHA-2 mit
IPsec)
[RFC-7296]
(IKEv2)
256 [gemSpec_Kry
pt], Kap. 3.3.1
18. HMAC Berechnung und Prüfung
für TLS
HMAC mit SHA-1, SHA-256 und
SHA-384
[FIPS180-4]
(SHA)
[RFC-2104]
(HMAC)
[RFC-5246]
(TLSv1.2)
160, 256, 384 [gemSpec_Kry
pt], Kap. 3.3.2
19. Vertraulich-
keit
Symmetrische Ver- 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, IPSec)
[RFC-4301]
(IPsec)
256 [gemSpec_Kry
pt], Kap. 3.3.1
20. Symmetrische Ver- und
Entschlüsselung für
TLS v1.2
AES-128 und AES-256 in CBC
[FIPS 197]
(AES)
[RFC-3602]
(AES-CBC)
128, 256 [gemSpec_Kry
pt], Kap. 3.3.2
25 / 36
Zertifizierungsreport BSI-DSZ-CC-1044-V8-2025
# Zweck Kryptografische Funktion Implementie-
rungsstan-
dard
Schlüsselgröße in
Bit
Anwendungs-
standard
[RFC-3268]
(AES-TLS mit
DH)
[RFC-4492]
(AES-TLS mit
ECDH)
21. Vertraulich-
keit mit
Nachrichten-
authentizität
(Authentica-
ted Encrypti-
on)
AES-{128, 256} in GCM Mode
für TLS v1.2
[FIPS 197]
(AES)
[RFC-3268]
(AES-TLS)
[SP800-38D]
(GCM)
[RFC-5289]
(AES-GCM-
TLS)
[RFC-5116]
(AEAD)
128, 256 [gemSpec_Kry
pt], Kap. 3.3.2
22. Symmetrische Verschlüsselung
und Entschlüsselung bei IKE
und ESP für VPN Kommunikati-
on
AES-GCM-128 und AES-
GCM-256 mit 12 und 16 Byte
großem ICV
[FIPS 197]
(AES)
[RFC-4303]
(ESP)
[RFC-4301]
(IPsec)
[RFC-4106]
(AES-GCM)
AES-GCM: 128 und
256 Bit mit 128 Bit
Tag-Länge
[gemSpec_Kry
pt], Kap. 3.3.1
und Kap. 5.5
23. Sichere
Kanäle
TLS v1.2 [RFC-5246]
(TLS v1.2)
[SMD3_AK]
[SMD3_MS_
AK]
- [gemSpec_Kry
pt], Kap. 3.3.2
24. VPN (IKEv2) mit
zertifikatbasierter
Authentisierung
[RFC-4301]
(IPsec)
[RFC-4303]
(ESP)
[RFC-7296]
(IKEv2)
[SMD3_NK]
[SMD3_MS]
- [gemSpec_Kry
pt], Kap. 3.3.1
Tabelle 3: kryptografische Funktionen des EVG
Die kryptografische Stärke dieser Algorithmen wurde in diesem Zertifizierungsverfahren
nicht bewertet (siehe BSIG §9, Abs. 4, 2).
26 / 36
BSI-DSZ-CC-1044-V8-2025 Zertifizierungsreport
Gemäß [13] sind die Algorithmen geeignet für den jeweiligen Zweck. Eine ausdrückliche
Gültigkeitsdauer ist nicht vorgegeben.
Die folgende Tabelle gibt einen Überblick über die zur Durchsetzung der Sicherheitspolitik
im EVG enthaltenen kryptographischen Funktionalitäten, für die im EVG enthaltene
Update-Funktionalität, und legt deren Bewertung des Sicherheitsniveaus aus
kryptographischer Sicht dar. Jede kryptografische Funktion, die in der Spalte
'Sicherheitsniveau mehr als 120 Bit' ein 'Nein' enthält erreicht nur ein Sicherheitsniveau
unterhalb von 120 Bit (im allgemeinen Anwendungsfall). Zu beachten ist, dass sich die
Spalte "Sicherheitsniveau" in Tabelle 7 nur auf die rein kryptographische (mathematische)
Stärke bezieht, und keinerlei eventuell ausnutzbare Schwäche bedingt durch Seitenkanal-
Leckinformation, physikalische Attacken, oder Implementierungsfehler jedweder Art
berücksichtigt.
Zweck Kryptografische
Funktion
Implementie-
rungsstandard
Schlüs-
selgröße
in Bit
Sicherheits-
niveau mehr
als 120 Bit
Bemerkungen
Authentizität GPG RSA Signaturve-
rifikation mittels
RSASSA-PKCS1-1.5
unter Anwendung von
SHA-512
[RFC-4880]
(OpenPGP)
[RFC-8017]
(RSA)
[FIPS 180-4]
(SHA)
2048 Nein,
Sicherheitsniv
eau >= 100
Bit
Signaturverifikation des
Firmware-Updates
FDP_ITC.1/NK.Update
FDP_UIT.1/NK.Update
RSA Signaturverifikati-
on mittels RSASSA-
PSS unter Anwendung
von SHA-256
[RFC-8017]
(RSA)
[FIPS 180-4]
(SHA)
4096 Ja Signaturverifikation der
UpdateInfo.xml und
FirmwareGroupInfo.xml
FDP_ITC.1/NK.Update
FDP_UIT.1/NK.Update
Tabelle 4: Kryptografische Funktionen des EVG (Update-Mechanismus)
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 120 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.
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.
27 / 36
Zertifizierungsreport BSI-DSZ-CC-1044-V8-2025
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 Anbindungsmodus.
Für aktive VPN-Verbindungen, die IPSec nutzen, sind im EVG keine Gegenmaßnahmen
gegen die statistische Datenverkehrsanalyse implementiert.
11. Sicherheitsvorgaben
Die Sicherheitsvorgaben [6] werden zur Veröffentlichung in einem separaten Dokument im
Anhang A bereitgestellt.
12. Definitionen
12.1. Abkürzungen
AES Advanced Encryption Standard
AIS Anwendungshinweise und Interpretationen zum Schema
AMTS Arzneimitteltherapiesicherheit
BIOS Basic Input/Output System
28 / 36
BSI-DSZ-CC-1044-V8-2025 Zertifizierungsreport
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
CRL Certificate Revocation List
CVC Card Verifiable Certificate
DHCP Dynamic Host Configuration Protocol
DNS Domain Name System
DTBS Data To Be Signed
EAL Evaluation Assurance Level – Vertrauenswürdigkeitsstufe
EBK Einboxkonnektor
eGK Elektronische Gesundheitskarte
ESP Encapsulating Security Payload
ETR Evaluation Technical Report
EVG Evaluierungsgegenstand – Target of Evaluation (TOE)
GCM Galois/Counter Mode
gSMC-K Sicherheitsmodul für den Konnektor
HBA Heilberufsausweis
HMAC Keyed-Hash Message Authentication Code
ICCSN Integrated Circuit Card Serial Number
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
NFDM Notfalldatenmanagement
NK Netzkonnektor
NTP Network Time Protocol
29 / 36
Zertifizierungsreport BSI-DSZ-CC-1044-V8-2025
PKI Public Key Infrastructure
PP Protection Profile – Schutzprofi
PTV Produkttyp Version
QES Qualifizierte Elektronische Signatur
REST-API Representational State Transfer - Application Program Interface
RZK Rechenzentrumskonnektor
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
SICCT Secure Interoperable Chip Card Terminal
SIS Secure Internet Service
ST Security Target – Sicherheitsvorgaben
TI Telematikinfrastruktur
TLS Transport Layer Security
TOE Target of Evaluation – Evaluierungsgegenstand (EVG)
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
VSDM Versichertenstammdatenmanagement
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.
30 / 36
BSI-DSZ-CC-1044-V8-2025 Zertifizierungsreport
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.
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 sind9
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-1044-V8-2024, Version 2.5, 10.04.2025, Security
Target für secunet konnektor 2.0.0 und secunet konnektor 2.1.0, secunet Security
Networks AG
9
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)
31 / 36
Zertifizierungsreport BSI-DSZ-CC-1044-V8-2025
[7] Evaluierungsbericht für BSI-DSZ-CC-1044-V8, Version 2.2, 10.04.2025, Evaluation
Report - Evaluation Technical Report (ETR), SRC Security Research & Consulting
GmbH (vertrauliches Dokument)
[8] Common Criteria Schutzprofil (Protection Profile), Schutzprofil 1: Anforderungen an
den Netzkonnektor, BSI-CC-PP-0097-2021, Version 1.6.7, 15.03.2023, Bundesamt
für Sicherheit in der Informationstechnik (BSI)
[9] Dokument zur sicheren Lieferkette:
secunet(konnektor Version 2.0.0, 2.0.1 und 2.1.0, Hinweise zur sicheren
Lagerung und Lieferkette, Version 2.1, 11.05.2023, secunet Security Networks
AG
[10] EVG-Handbücher:
[a] secunet(konnektor, Bedienungsanleitung, Für Administratoren und Benutzer,
Version 6.8.5, 10.04.2025, secunet Security Networks AG
[b] secunet(konnektor v2.0.0, 2.01 und 2.1.0, Sichere Lieferkette – Hinweise und
Prüfpunkte für Endnutzer, Version 2.0, 11.05.2023, secunet Security Networks
AG
[c] Konnektor Management API-Dokumentation, Version 5.1.1, 07.08.2024,
eHealth Experts GmbH
[d] Security Guidance Fachmodulentwicklung, Version 1.6, 07.07.2023, eHealth
Experts GmbH
[11] Konfigurationsliste für den EVG (vertrauliche Dokumente)
connector-all-components.csv
konnektor-alc_cms.csv
1209-V2_1044-V8_References_secunet_konnektor v1.18.pdf
Konfigurationsliste (ALC_CMS.4), Version 11.1, Datei:
ALC_CMS_eHX_v11.1.xlsx
Konfigurationsliste (ALC_CMS), Regulatory Affairs Document, S.I.E, Rev# 5.0.0,
24.03.2023
[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
[IANA] Internet Key Exchange Version 2 (IKEv2) Parameters, iana
https://www.iana.org/assignments/ikev2-parameters/ikev2-
parameters.xhtml#ikev2-parameters-6
32 / 36
BSI-DSZ-CC-1044-V8-2025 Zertifizierungsreport
[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
[RFC4106] J. Viega, D. McGrew: The Use of Galois/Counter Mode (GCM) in
IPsec Encapsulating Security Payload (ESP), June 2005
[RFC4301] S. Kent, K. Seo: Security Architecture for the Internet Protocol,
December 2005
[RFC4303] S. Kent: IP Encapsulating Security Payload (ESP), December 2005
[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
[RFC8247] Y. Nir, T. Kivinen, P. Wouters, D. Migault: Algorithm Implementation
Requirements and Usage Guidance for the Internet Key Exchange Protocol
Version 2 (IKEv2), September 2017
[SEC1] Certicom Research: Standards for Efficient Cryptography, SEC 1: Elliptic
Curve Cryptography, Version 2.0, 21 May 2009
[SMD3_AK] RFC-Analyse AK-TLS, Anwendungskonnektor, Version 1.1, 26.
Oktober 2018
33 / 36
Zertifizierungsreport BSI-DSZ-CC-1044-V8-2025
[SMD3_MS_AK] Nachweis TLS Security, Version 0.9, 26. April 2018,
TLSv11_MAY+SHOULD_26.04_final.xlsx
[SMD3_NK] secunet(konnektor Version 2.0.0, VPN-Analyse, Anforderungen an
kryptographisch gesicherte VPN-Kanäle / Trusted Channels im deut-schen CC-
Zertifizierungsschema, Version 0.97, 16. August 2018
[SMD3_MS] IPsec-RFCs - MAY_SHOULD Anforderungen, secunet(konnektor,
Version 0.95, 22.07.2018
[SP800-38D] NIST Special Publication 800-38D, Recommendation for Block
Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC,
November 2007
[GCM] D. McGrew, J. Viega: The Galois/Counter Mode of Operation (GCM),
https://csrc.nist.rip/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-
spec.pdf, January 2004
[13] Referenzen auf Anwendungsstandards:
[gemSpec_Kon] Einführung der Gesundheitskarte: Konnektorspezifikation,
Version 5.20.0, 05.05.2023, gematik Gesellschaft für Telematikanwendungen
der Gesundheitskarte mbH
[gemSpec_Krypt] Einführung der Gesundheitskarte - Verwendung
kryptographischer Algorithmen in der Telematikinfrastruktur, gematik
Gesellschaft für Telematikanwendungen der Gesundheitskarte mbH, Version
2.27.0, 14.04.2023
[gemSpec_Net] Einführung der Gesundheitskarte: Übergreifende Spezifikation:
Spezifikation Netzwerk, gematik Gesellschaft für Telematikanwendungen der
Gesundheitskarte mbH, Version 1.23.0, 16.12.2022
[TR-03111] Technical Guideline TR-03111 Elliptic Curve Cryptography,
TR-03111, Version 2.10, 01.06.2018, Bundesamt für Sicherheit in der
Informationstechnik (BSI)
[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
[TR-03154] Konnektor – Prüfspezifikation für das Fachmodul NFDM, Technische
Richtlinie BSI TR-03154, Version 1.1, 15.04.2019
[TR-03155] Konnektor – Prüfspezifikation für das Fachmodul AMTS, Technische
Richtlinie BSI TR-03155, Version 1.1, 15.04.2019
[TR-03157] BSI TR-03157 Konnektor – Prüfspezifikation für das Fachmodul
ePA, Technische Richtlinie BSI TR-03157, Version 1.2, 24.07.2019
[14] Cryptographic conformity assessment - Kryptographische Mechanismen des
secunet eHealth konnektor 2.0.0 und 2.1.0 (PTV5 WR1), Version 1.0, 23.01.2025,
SRC Security Research & Consulting GmbH (vertrauliches Dokument)
34 / 36
BSI-DSZ-CC-1044-V8-2025 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.
35 / 36
Zertifizierungsreport BSI-DSZ-CC-1044-V8-2025
D. Anhänge
Liste der Anhänge zu diesem Zertifizierungsreport
Anhang A: Die Sicherheitsvorgaben werden in einem eigenen Dokument zur Verfügung
gestellt.
Bemerkung: Ende des Reportes
36 / 36