latest
Elektronische Gesundheitskarte und Telematikinfrastruktur
Spezifikation
HSM-B
Version | 1.2.4 |
Revision | 548770 |
Stand | 19.07.2017 |
Status | in Bearbeitung |
Klassifizierung | nicht öffentlich |
Referenzierung | gemSpec_HSM-B |
Dokumentinformationen
Änderungen zur Vorversion
Gegenüber der Vorversion wurden die Änderungen gemäß der Dokumentenhistorie für die Version 1.2.4 vorgenommen und gelb markiert.
Dokumentenhistorie
Version |
Stand |
Kap./ Seite |
Grund der Änderung, besondere Hinweise |
Bearbeitung |
---|---|---|---|---|
0.0.1 |
27.06.14 |
Initiale Erstellung |
Dr. Osman Ugus |
|
0.0.2 |
06.08.14 |
alle |
Bearbeitung der Kommentare zur Zwischenlieferung |
Dr. Osman Ugus |
0.0.3 |
14.08.14 |
alle |
Kap. 2.4: Erweiterung der übergreifenden Sicherheitsanforderungen Kap. 4.2: Formulierungen für Speicherung der Schlüssel/Zertifikate wurden entsprechend der Kommentare der gematik angepasst. Kap. 4.4.2: Unterstützung für „Externe Authentisierung mit RSA-Schlüssel“ wurde entfernt. Kap. 4.5: Bearbeitung und Erweiterung der Anforderungen Kap. 4.6.1: Unterstützung für „sign9796_2_DS2“ wurde entfernt Kap. 5.2: Erweiterung der Anforderungen an die Personalisierungsschnittstelle Alle: Entfernung der nicht-erlaubten Schlüsselwörter aus der Anforderungen Alle: Anpassung der Tabellenbreite für TUCs |
Dr. Osman Ugus |
0.0.4 |
15.08.14 |
alle |
Editorial QS |
Michael Voucko |
0.0.5 |
04.11.14 |
alle |
alle: Fehlerkorrekturen, Entfernen der mehreren Schlüsselwörter aus Anforderungen Kap. 4.4.3.1: Entfernen der redundanten und zur Vollständigkeit nicht notwendigen Beschreibungen Kap. 4: Bearbeitung der Abbildungen und Tabellen entsprechend der Kommentaren der gematik Kap. 4.6.2: Unterstützung für Entschlüsselung mittels ELC-Schlüssel wurde hinzugefügt Kap.3 und 4: Aktualisierung der Fehlercode-Tabellen der TUCs Kap. 3.2: Beschreibung des Pairings mit Konnektor wurde hinzugefügt. Kap. 3.1: Anzahl der virtuellen Kartenslots eines vKTs maximal auf 14 begrenzt Kap. 3.2: TUC für das Kommando „EHEALTH TERMINAL AUTHENTICATE“ wurde hinzugefügt |
Dr. Osman Ugus |
0.0.6 |
05.11.14 |
Kap. 3.2 – 3.2.3 |
Editorial QS |
Michael Voucko |
0.0.7 |
17.02.15 |
alle |
Fehlerkorrekturen |
Dr. Osman Ugus Devran Ölcer |
0.0.8 |
19.02.15 |
Kap. 5.1 |
Anforderungen zur Eingabe der ICCSN für vKTs und vSMC-Bs eingefügt |
Dr. Osman Ugus |
0.0.9 |
12.03.15 |
alle |
Synchronisation mit dem Sicherheitskonzept – HSM-B |
Dr. Osman Ugus |
0.1.1 |
21.04.15 |
alle |
Kap.2 Allgemeine Anforderungen wurde hinzugefügt Kap. 4.2: Zertifikate und Schlüsselobjekte der vKTs wurden in einem separaten Kapital beschrieben und spezifiziert Kap. 6.2.1: Verwaltung der Zertifikate und Schlüsselobjekte der vKTs und vSMC-Bs wurden getrennt beschrieben und spezifiziert Kap. 6.4: Firmware Update wurde hinzugefügt Kap. 6.5: Produkttypversion und Selbstauskunft wurde hinzugefügt Kap. 7: Rollen, die an der Managementschnittstelle vorgesehen sind, und deren Berechtigungen wurden hinzugefügt Alle: Bearbeitung der Kommentare zur Zwischenlieferung (Version 0.0.9) |
Dr. Osman Ugus |
1.0.0 |
06.07.15 |
alle |
Editorial QS |
Michael Voucko Alfonso Concellón |
1.1.0 |
03.08.15 |
Alle: Fehler Korrekturen: MSE-Variante „externen, asymmetrischen Authentisierung“ wurde hinzugefügt Einarbeitung der Kommentare der gematik zur Lieferung (Version 1.0.0) |
Dr. Osman Ugus |
|
1.2.0 |
06.12.16 |
alle |
Allgemein: Klarstellungen, Detailierungen Redundante Kommandobeschreibungen für COS und SICCT entfernt Unterstüzung von SE-Identifiern und DFspecificPasswordList nicht notwendig SICCT Errate 1.0.2 berücksichtigt CVC-Root-CA wird nicht personalisiert Kein Import von C.SMKT.CA.R2048, stattdessen import der CA-Zertifikate der Komponenten-PKI Rolle Personalisierer zu Security Administraor geändert Rollenaufgaben überarbeitet Kap.4.6 Kommando Get Random hinzugefügt Kap. 5. AFO für pointInTime Kap. 5 EF.DIR und EF.Version2 aufgenommenKap. 5.7 COS-Kommandos Read Record und Search Record aufgenommen Kap. 6.1 AFOs für das Löschen von vKTs, vSMC-Bs aufgenommen |
Andreas Kotte |
1.2.1 |
16.02.17 |
Anpassung der Anforderungen entsprechend dem Anforderungsmanagement der gematik. Formale Qualitätssicherung, Anpassung verschiedener Formatierungen, Verwendung von Formatvorlagen, Korrektur von Verweisen. |
gematik |
|
1.2.2 |
4.1 6.1.1 4.6.1 5.1.2 |
Mengengerüst eindeutiger formuliert Möglichkeit der Änderung von Sicherheitsprotokolleinstellungen entfernt TIP1-A_6212 entfernt, da für ein vKT der Konnektor einfach nur ein Client ist, dessen interne Verwaltung ein Implementierungsdetail ist. Funktionalität von GET SECURITY STATUS KEY beschränkt auf die unterstützten Schlüssel. Redundante Beschreibungen entfernt, die in anderen Spezifikationen bereits enthalten sind. Zusammenfassung von AFOs im Bereich Kommandobeschreibungen, entfernen von redundanten AFOs. Es entfallen folgenden AFOs TIP1_A_6190, 6193, 6216, 6224, 6226, 6227, 6234, 6242, 6245, 6248, 6251, 6254, 6263, 6266, 6269, 6272, 6275, 6278, 62816284, 6288, 6289, 6292, 7010, 7012 Unterstützung PuK.RCA.CS.R2048 und Import von RSA-CV-Zertifikaten entfernt. Aktualisierung von Zertikaten entfernt PSO_ComputeDigitalSignature muss rsaClientAuthentication unterstützen Folgende AFOs aufgenommen
Trennung Beschreibung Objektsystem, COS-Funktionalität AFOs bzgl. Behandlung von ICCSN in ein eigenes Kapitel „Prozesse“ verschoben zusammen mit den Rollenbeschreibungen |
Andreas Kotte |
|
1.2.3 |
03.05.17 |
Temoräre AFO-Nummern [TIP1-A_???x] durch richtige ersetzt |
Andreas Kotte |
|
1.2.4 |
19.07.17 |
Service Discovery [TIP1-A_6189] und Referenced Coding [TIP1-A_6173] sind nicht mehr optional Einarbeitung Kommentare zu Version 1.2.3 |
Andreas Kotte |
Inhaltsverzeichnis
1 Einordnung des Dokumentes
1.1 Zielsetzung
Diese Spezifikation definiert die Anforderungen an
- das funktionale Verhalten und
- das Objektsystem
des Produkttyps HSM-B sowie die durch es bereitgestellten Schnittstellen.
1.2 Zielgruppe
Dieses Dokument richtet sich an HSM-B-Hersteller sowie Hersteller und Anbieter von Produkttypen, die hierzu eine Schnittstelle besitzen.
1.3 Geltungsbereich
Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z.B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.
Schutzrechts-/Patentrechtshinweis
Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.
1.4 Abgrenzung
Dieses Dokument spezifiziert das Verhalten und Schnittstellen des HSM-B. Dieses Dokument spezifiziert NICHT die Architektur des HSM-B. Als Grundlage dieser Spezifikation gelten die folgenden Spezifikationen:
- Secure Interoperable ChipCard Terminal [SICCT] der TeleTrust
- eHealth-Kartenterminal [gemSpec_KT] der gematik
- Security Module Card SMC-B Objektsystem [gemSpec_SMC-B_ObjSys] der gematik
- gSMC-KT Objektsystem [gemSpec_gSMC-KT_ObjSys] der gematik
- Card Operating System (COS) [gemSpec_COS] der gematik
- Konnektor [gemSpec_Kon] der gematik
- Konzept Architektur der TI-Plattform [gemKPT_Arch_TIP] der gematik.
1.5 Methodik
Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworten MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.
Sie werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]
Dabei umfasst die Anforderung sämtliche innerhalb der Textmarken angeführten Inhalte.
1.6 Rollen: Security Administrator und Administrator
In dieser Spezifikation werden die Begriffe „Administrator“ und „Security Administrator“ verwendet. Sie sind keine Berufsbezeichnungen, sondern die Rollen, welche zur Verwaltung des HSM-B besondere Rechte und Aufgaben haben. Darüber, welche Personen diese Rollen ausfüllen, werden keine Vorgaben gemacht.
2 Allgemeine Anforderungen
2.1 Physikalische Anforderungen (normativ)
2.1.1 Klima und Vibration (normativ)
TIP1-A_6137 - Anforderungen an Klima
Der Hersteller des HSM-B MUSS in der Produktspezifikation die optimalen klimatischen Bedingungen für die Betriebsumgebung des HSM-B angeben.
[<=]TIP1-A_6138 - Anforderungen an Belastbarkeit für Vibrationen
Der Hersteller des HSM-B MUSS in der Produktspezifikation Angaben über die Belastbarkeit des HSM-B bezüglich Vibrationen und mechanische Schockbelastungen bereitstellen.
[<=]TIP1-A_6139 - Gewährleistung der optimalen Betriebsbedingungen für physikalische Umgebung/Betriebsumfeld des HSM-B
Der Hersteller des HSM-B MUSS den Betreiber in der Dokumentation darauf hinweisen, dass das HSM-B nur in einer Betriebsumgebung betrieben werden darf, die die Vorgaben an
Klima aus [TIP1-A_6137]
Vibrationen und mechanische Schockbelastungen aus [TIP1-A_6138]
erfüllt.
[<=]2.2 Performanz (normativ)
TIP1-A_6140 - Angaben über die Performanz des HSM-B
Der Hersteller des HSM-B MUSS in der Produktspezifikation Angaben über die Performanz der durch das HSM-B virtualisierten Kartenterminals (vKTs) und Karten (vSMC-Bs) bereitstellen.
[<=]
3 Systemüberblick
3.1 Logischer Aufbau (informativ)
Der logische Aufbau des HSM-B ist in Abbildung 1 dargestellt. Diese Darstellung ist informativ. Der Hersteller kann den internen Aufbau seines HSM-B frei wählen. Lediglich das Verhalten an den Außenschnittstellen (siehe [0]) ist normativ.
Das HSM-B für den Einsatz im deutschen Gesundheitswesen dient als Ersatz einer oder mehrerer SMC-Bs. Die logische Komponente, die die Funktionalität einer SMC-B anbietet, wird in dieser Spezifikation als „virtuelle SMC-B (vSMC-B)“ bezeichnet (siehe [5]). Das HSM-B kann über mehrere vSMC-B verfügen.
Die vSMC-Bs müssen von dem Konnektor angesprochen werden können. Die Anbindung eines HSM-B an einen Konnektor sollte aus Sicht des Konnektors möglichst transparent sein. Die logische Komponente, die eine solche völlig transparente Anbindung an den Konnektor ermöglicht, wird in dieser Spezifikation als „virtuelles Kartenterminal (vKT)“ bezeichnet (siehe [4]). Das HSM-B kann über mehrere vKTs verfügen.
Die Komponente „HSM-B Management“ (siehe [6]) bietet die Funktionalität für die administrative Verwaltung des HSM-B. 1.2.4
3.2 Schnittstellen (normativ)
Die normativen Außenschnittstellen des HSM-B sind in [Abb_HSM-B_002] dargestellt.
Die Schnittstellen zum Konnektor werden in [3.1.1] beschrieben. Die Managementschnittstelle für die Verwaltung des HSM-B wird in [3.1.2] beschrieben.
TIP1-A_6141 - Transparente Anbindung an den Konnektor
Die Anbindung eines HSM-B an einen Konnektor MUSS aus Sicht des Konnektors kommunikationstechnisch völlig transparent sein.
[<=]TIP1-A_6142 - Virtualisierung von KT und Karte gegenüber Konnektor
Das HSM-B MUSS die durch es virtualisierten Kartenterminals und Karten so implementieren, dass sie sich gegenüber dem Konnektor funktional wie reale eHealth-Kartenterminals und SMC-Bs verhalten.
[<=]3.2.1 Schnittstellen zum Konnektor
Die Außenschnittstellen des HSM-B zum Konnektor sind „I_HSM_Operations“ und „I_Poll_System_Information“ (siehe [gemKPT_Arch_TIP#5.3.4]). Zudem muss das HSM-B die Außenschnittstelle „I_Notification“ des Konnektors verwenden.
Die Schnittstelle „I_HSM_Operations“ entspricht funktional den Schnittstellen
- I_KT_Communication
- I_Smartcard_Operations
eines eHealth-Kartenterminals bzw. einer SMC-B.
Das HSM-B muss die Schnittstelle „I_KT_Communication“ implementieren, um eine aus der Sicht des Konnektors transparente Kommunikation entsprechend der Anforderung [TIP1-A_6141] zu ermöglichen.
Das HSM-B muss die Schnittstelle „I_Smartcard_Operations“ implementieren, um alle Funktionen einer oder mehrerer SMC-Bs entsprechend der Anforderung [gemKPT_Arch_TIP#TIP-A_2499] ersetzen zu können.
Das HSM-B muss die Schnittstelle „I_Poll_System_Information“ implementieren, um vom Konnektor Informationen über die abgebildeten (v)SMC-Bs abfragen zu können.
Das HSM-B muss die Schnittstelle „I_Notification“ verwenden, um Informationen über die Slotstatusänderungen seiner (v)KTs (z.B. Karte entfernt, Karte gesteckt, etc.) zum Konnektor entsprechend [SICCT#6.1.4.4] melden zu können.
Das HSM-B muss die Schnittstelle „Service Discovery“ implementieren, um das dynamische Auffinden von vKTs des HSM-B durch Konnektoren entsprechend [SICCT#6.1.3.1] und [gemSpec_KT#3.7.8] zu unterstützen.
Eine Zuordnung zwischen den zu implementierenden Außenschnittstellen sowie den verwendeten Schnittstellen und deren technischer Ausprägung in diesem Dokument ist informativ in Tabelle 1 dargestellt.
Schnittstelle |
Zu implementierende Operation |
Technische Ausprägung in diesem Dokument |
---|---|---|
I_KT_Communication |
perform_Command |
|
transfer_APDU |
|
|
I_Poll_System_Information |
get_Resource_List |
|
I_Smartcard_Operations |
process_Command |
|
I_Notification |
notify |
|
Service Discovery |
Dienstbeschreibungspaket senden |
|
I_HSM_Management |
herstellerspezifisch |
Erfolgt implizit durch die Umsetzung der Anforderungen in [6] |
TIP1-A_6143 - Schnittstelle „I_HSM_Operations“ zum Konnektor
Das HSM-B MUSS über eine Schnittstelle „I_HSM_Operations“ zum Konnektor verfügen.
[<=]TIP1-A_6144 - Unterstützung der Schnittstelle „I_KT_Communication“
Die Schnittstelle „I_HSM_Operations“ des HSM-B MUSS die logischen Operationen
perform_Command
transfer_APDU
der Schnittstelle „I_KT_Communication“ entsprechend den Anforderungen [TIP-A_2350] und [TIP-A_2351] der Spezifikation [gemKPT_Arch_TIP#5.5.2.5.2] implementieren.
[<=]TIP1-A_6145 - Unterstützung der Schnittstelle „I_Smartcard_Operations“
Die Schnittstelle „I_HSM_Operations“ des HSM-B MUSS die logische Operation
process_Command
der Schnittstelle „I_Smartcard_Operations“, die die Bearbeitung eines Kartenkommandos gemäß [gemSpec_COS] ermöglicht, implementieren.
[<=]TIP1-A_6146 - Unterstützung der Schnittstelle „I_Poll_System_Information“
Die Schnittstelle „I_HSM_Operations“ des HSM-B MUSS die logische Operation
get_Resource_List
der Schnittstelle „I_Poll_System_Information“ entsprechend der Anforderung [TIP-A_2265] der Spezifikation [gemKPT_Arch_TIP#5.5.2.5.2] implementieren.
Das HSM-B KANN weitere logische Operationen der Schnittstelle „I_Poll_System_Information“ aus der Spezifikation [gemKPT_Arch_TIP#5.5.1.4] unterstützen.
[<=]TIP1-A_6147 - Unterstützung der Ereignismeldung über die Schnittstelle „I_Notification“
Das HSM-B MUSS die SICCT-spezifischen Ereignisse gemäß [SICCT#6.1.4.4], die an seinen vKTs auftreten, über die Schnittstelle „I_Notification“ gemäß [gemKPT_Arch_TIP#5.5.1.4.2] zum Konnektor melden.
[<=]3.2.2 Managementschnittstelle
Die Außenschnittstelle „I_HSM_Management“ (siehe Abb_HSM-B_002) wird verwendet, um das HSM-B zu konfigurieren und zu verwalten.
TIP1-A_6148 - Managementschnittstelle
Das HSM-B MUSS für die Verwaltung des HSM-B über eine Managementschnittstelle „I_HSM_Management“ verfügen.
[<=]Die Umsetzung dieser Managementschnittstelle ist herstellerspezifisch. Der Hersteller kann die Technologien zur Umsetzung dieser Schnittstelle frei wählen. Normativ ist die Funktionalität, die diese Schnittstelle anbieten muss. Sie wird in [6] beschrieben.
TIP1-A_6149 - Außenschnittstellen HSM-B
Außer den Schnittstellen
I_HSM_Operations
I_Poll_System_Information
I_Notification
zur Kommunikation mit einem Konnektor und
der optionalen Schnittstelle (Service Discovery) zum Empfangen von Dienstanfragenachrichten aus einem Konnektor und zum Senden von Dienstbeschreibungsnachrichten zu einem Konnektor
und der Schnittstelle
I_HSM_Management
zur Verwaltung des HSM-B DARF das HSM-B über weitere Außenschnittstellen NICHT verfügen.
[<=]3.3 Kommunikation (normativ)
Das HSM-B muss mit dem Konnektor über sein LAN-seitiges Ethernet-Interface über das SICCT-Protokoll mit den eHealth-Erweiterungen gemäß [gemSpec_KT] kommunizieren.
TIP1-A_6150 - Unterstützung von IPv4
Das HSM-B MUSS IPv4 unterstützen.
[<=]TIP1-A_6151 - Unterstützung von IPv6
Die Hardware des HSM-B MUSS für den Einsatz von IPv4 und IPv6 im Dual-Stack-Mode geeignet sein.
[<=]TIP1-A_6152 - Verwerfen von IPv6-Paketen im IPv4-Betrieb
Das HSM-B MUSS bis zu einer Migration von IPv4 auf IPv6 sämtliche empfangene IP-Pakete der Version 6 (IPv6) verwerfen.
[<=]TIP1-A_6153 - Unterstützung von SICCT mit eHealth-Erweiterungen
Das HSM-B MUSS das SICCT Command Set gemäß [SICCT#5, #Anhang C] und die SICCT Schnittstellenbeschreibung zum Host gemäß [SICCT#6.1, #6.3] mit den korrespondierenden eHealth-Erweiterungen zum Command Set gemäß [gemSpec_KT#3.7] umsetzen, mit den Ergänzungen aus Kapitel 4 dieser Spezifikation [gemSpec_HSM-B].
[<=]TIP1-A_6154 - Keine Verwendung des Auto-IP-Protokolls
Das HSM-B DARF abweichend von den Regelungen in [SICCT#6.1.2] das Auto-IP-Protokoll gemäß [RFC3927] NICHT verwenden.
[<=]3.4 Übergreifende Sicherheitsanforderungen (normativ)
TIP1-A_6155 - Unterstützung von TLS
Das HSM-B MUSS an dem TCP-Port jedes vKTs jeweils eine eigene SICCT-spezifische TLS-Verbindung unterstützen, die die Vorgaben aus
[gemSpec_Krypt#GS-A_4384] und [gemSpec_Krypt#GS-A_5035] für die TLS-Implementierung und
[gemSpec_Krypt#GS-A_4385], [gemSpec_Krypt#GS-A_4386] und [gemSpec_Krypt#GS-A_4387] für TLS-Versionen und
[gemSpec_Krypt#GS-A_5322] für weitere Sicherheitsaspekte für TLS-Verbindungen
erfüllen.
[<=]TIP1-A_6156 - TLS-gesicherte Kommunikation mit dem Konnektor
Das HSM-B MUSS sicherstellen, dass bis auf die
Dienstanfragenachrichten, die vom Konnektor erhalten werden
Dienstbeschreibungsnachrichten, die zum Konnektor gesendet werden
die gesamte Kommunikation mit einem Konnektor über den TCP-Port eines vKTs durch eine SICCT-spezifische TLS-Verbindung gemäß [TIP1-A_6155] gesichert ist.
[<=]TIP1-A_6157 - X.509-Identität eines vKTs
Das HSM-B MUSS sicherstellen, dass jedes vKT jeweils das eigene X.509-Zertifikat C.SMKT.AUT.R2048 und den zugehörigen privaten Schlüssel PrK.SMKT.AUT.R2048 verwendet, die gemäß [TIP1-A_6156] während des Aufbaus der SICCT-spezifischen TLS-Verbindung mit einem Konnektor für sichere Identifikation und Authentisierung dieses vKTs benötigt werden.
[<=]TIP1-A_6158 - Gesicherte Kommunikation über die Managementschnittstelle
Das HSM-B MUSS sicherstellen, dass die
Vertraulichkeit
Integrität
Authentizität
der gesamten Kommunikation über die Managementschnittstelle „I_HSM_Management“ zu jedem Zeitpunkt gewährleistet wird.
Der Hersteller des HSM-B MUSS zwingend in einem entsprechenden Dokument beschreiben, wie die Sicherung der Managementschnittstelle „I_HSM_Management“ umgesetzt wird.
[<=]TIP1-A_6159 - Benutzerauthentifizierung bei der Verwaltung des HSM-B
Das HSM-B MUSS sicherstellen, dass Zuordnung einer in [TIP1-A_6355] gelisteten Rolle zu einem Benutzer nur nach einer erfolgreichen Benutzerauthentifizierung erfolgt.
Der Hersteller des HSM-B MUSS zwingend in einem entsprechenden Dokument beschreiben, wie die Benutzerauthentifizierung umgesetzt wird.
[<=]TIP1-A_6160 - Vier-Augen-Prinzip bei der Personalisierung des HSM-B
Das HSM-B MUSS sicherstellen, dass bei der Personalisierung zusätzlich zur Benutzerauthentifizierung gemäß [TIP1-A_6159] durchgängig das Vier-Augen-Prinzip umgesetzt wird.
Der Hersteller des HSM-B MUSS zwingend in einem entsprechenden Dokument beschreiben, wie das Vier-Augen-Prinzip umgesetzt wird.
[<=]TIP1-A_6163 - Auswahl der Schlüssellängen
Bezüglich der Auswahl der Schlüssellängen MUSS das HSM-B die normativen Vorgaben aus [gemSpec_SMC-B_ObjSys] und [gemSpec_Krypt] erfüllen.
[<=]TIP1-A_6164 - Erforderliches Sicherheitsniveau für das HSM-B
Das HSM-B MUSS die Sicherheitsanforderungen für ein HSM mindestens für Prüftiefe
Common Criteria EAL4+ oder
FIPS 140-2 Level 3 oder
ITSEC E3
erfüllen. Erfüllt das HSM-B das erforderliche Sicherheitsniveau nicht, MUSS der Betreiber des HSM-Bs Angriffe, die aufgrund des fehlenden Sicherheitsniveaus nicht ausgeschlossen werden können, mit zusätzlichen organisatorischen und/oder physischen Sicherheitsmaßnahmen in der Einsatzumgebung ausschließen.
[<=]TIP1-A_6165 - Beschreibung der erforderlichen zusätzlichen Sicherheitsmaßnahmen
Der Hersteller des HSM-B MUSS die organisatorischen und/oder physischen Sicherheitsmaßnahmen zwingend in einem entsprechenden Betriebshandbuch beschreiben, falls gemäß [TIP1-A_6164] zusätzliche Maßnahmen aufgrund des fehlenden Sicherheitsniveaus des HSM-B in der Einsatzumgebung durch den Betreiber des HSM-B eingesetzt werden müssen.
[<=]TIP1-A_6166 - Nachweis der Erfüllung des erforderlichen Sicherheitsniveaus für das HSM-B
Der Hersteller des HSM-B MUSS im Rahmen der Zulassung durch eine erfolgreiche Zertifizierung beim BSI [BSI] nachweisen, dass das erforderliche Sicherheitsniveau für das HSM-B gemäß [TIP1-A_6164] durch
die Sicherheit des HSM-B selbst zusammen mit
der Umsetzung der Sicherheitsmaßnahmen in der Betriebsumgebung gemäß [TIP1-A_6165]
als Gesamtpaket erfüllt wird.
[<=]TIP1-A_6167 - Verwendung von Standards und „Best Practices“
Der Hersteller des HSM-B MUSS bei dem Design und der Implementierung des HSM-B die Vorgaben aus
ISO27001 Standard - Abschnitt 12.2 [ISO27001] zur korrekten Verarbeitung in Anwendungen
Secure Coding Guidelines gemäß Common Criteria for Information Technology Security Evaluation, Version 3.1 bei der Entwicklung von Software
berücksichtigen.
[<=]TIP1-A_6168 - Verwendung eines BSI-konformen Zufallszahlengenerators
Das HSM-B MUSS einen Zufallszahlengenerator verwenden, der die Anforderungen aus [BSI-TR-03116-1#3.4] Erzeugung von Zufallszahlen] erfüllt.
[<=]TIP1-A_6169 - Gewährleistung der Einhaltung der Sicherheitsanforderungen für die Betriebsumgebung des HSM-B
Der Hersteller des HSM-B MUSS den Betreiber in der Dokumentation darauf hinweisen, dass das HSM-B in einer Betriebsumgebung betrieben werden muss, die die Vorgaben an
Sicherheit aus [TIP1-A_6166]
erfüllt.
[<=]
4 Virtuelles Kartenterminal
Die Komponente „virtuelles Kartenterminal (vKT)“ implementiert die Schnittstellen
- I_KT_Communication [TIP1-A_6144]
- I_Poll_System_Information [TIP1-A_6146]
- I_Notification [TIP1-A_6147]
(siehe [3.1.1]). Eine Zuordnung zwischen diesen Schnittstellen und deren technischer Ausprägung sind informativ in Tabelle 1 dargestellt.
Das HSM-B kann über mehrere vKTs verfügen. Jedes vKT hat die folgenden Aufgaben:
- Bereitstellung einer SICCT-Kommunikationsschnittstelle (mit den eHealth-Erweiterungen gemäß [gemSpec_KT]) zum Konnektor
- Bereitstellung des Zugriffs auf einen oder mehrere virtuelle Kartenslots und darin gesteckte vSMC-Bs
- Eine eindeutige Adressierbarkeit jedes virtuellen Kartenslots
- Meldung der Slotereignisse über die Statusänderungen in seinen virtuellen Kartenslots wie „Karte wurde eingesteckt, Karte wurde entfernt“ über einen Eventmechanismus entsprechend [SICCT#6.1.4.4] an den Konnektor.
Die Ereignisse „Karte wurde eingesteckt“ bzw. „Karte wurde entfernt“ aus einem virtuellen Kartenslot besagen die Verfügbarmachung bzw. Nicht-Verfügbarmachung einer vSMC-B an diesem virtuellen Kartenslot durch ein berechtigtes Personal (siehe [TIP1-A_6309] und [TIP1-A_6310]).
Hinweis: Ein vKT enthält nicht wie ein physikalisches Terminal eine gSMC-KT, auch nicht in virtualisierter Form. Einzig der Schlüssel PrK.SMKT.AUT.R2048 mit dem dazugehörigen Zertifikat C.SMKT.AUT.R2048 ist einem vKT zugeordnet. Diese Objekte sind nicht über Kommandos eines COS zugänglich.
4.1 Funktionsmerkmalweite Aspekte (normativ)
TIP1-A_6170 - Anzahl virtueller Kartenterminals
Das HSM-B MUSS mindestens 16 aktive virtuelle Kartenterminals (vKT) verwalten können.
[<=]TIP1-A_6171 - Anzahl virtueller Kartenslots
Ein vKT MUSS mindestens über 1 (virtuellen) Kartenslot verfügen.
[<=]Falls nur Direct Coding gemäß [SICCT#5.5.9.3] unterstützt wird ist die maximale Anzahl an adressierbaren virtuellen Kartenslots auf 14 begrenzt.
TIP1-A_6172 - Angaben zum Mengengerüst des HSM-B
Der Hersteller des HSM-B MUSS für den Anwender in der Anwenderdokumentation Informationen über das Mengengerüst des HSM-B bereitstellen, welche
Angaben zur Anzahl der durch das HSM-B unterstützten vKTs
Angaben zur Anzahl der durch das HSM-B unterstützten vSMC-Bs
enthält.
[<=]TIP1-A_7026 - Unterstützung vom Direct Coding
Das HSM-B MUSS das Direct Coding gemäß [SICCT#5.5.9.3] unterstützen.
[<=]TIP1-A_6173 - Optionale Unterstützung vom Referenced Coding
Das HSM-B KANN MUSS das Referenced Coding gemäß [SICCT#5.5.9.4] unterstützen.
[<=]DISCLAIMER: Umsetzung in Abhängigkeit eines noch zu verhandelnden Change Requests, der zum Ziel hat mehr als 14 vSMC-B pro Konnektor zur Verfügung zustellen. Hierbei könnte auch eine andere Lösung als die Unterstützung des Referenced Coding möglich sein.
TIP1-A_7027 - Eindeutige Adressierbarkeit eine vKT
Ein vKT muss vom Client eindeutig über IP-Adresse und Port adressiert werden können.
[<=]Hinweis: Da ein HSM-B im Normalfall nur eine IP-Adresse hat ist einer Unterscheidung verschiednener vKTs nur über verschiedene Ports möglich.
TIP1-A_7028 - Unterstützung mehrer Clients
Ein HSM-B muss mehrere Clients (Konnektoren) bedienen können. Bei Unterstützung gleichzeitiger Verbindungen ist jede Art von Ressourcenkonflikten zu verhindern.
[<=]TIP1-A_6174 - Warten auf eingehende Dienstanfragen (optional)
Das HSM-B KANN MUSS auf eingehende Dienstanfragepakete (von Konnektoren) auf dem UDP Port jedes vKTs warten und auf erhaltene Dienstanfragepakete gemäß [TIP1-A_6189] reagieren.
[<=]TIP1-A_6175 - Sicherheitsprotokoll des Dienstbeschreibungspakets
Ergänzend zur [SICCT] MUSS das HSM-B das Datenfeld "Sicherheitsprotokoll" der Dienstbeschreibungspakete gemäß [gemSpec_KT#TIP1-A_3265] implementieren.
[<=]TIP1-A_6176 - Warten auf eingehende Clientverbindungen
Das HSM-B MUSS auf eingehende Clientverbindungen (von Konnektoren) auf dem TCP Port jedes vKTs warten und auf erhaltene Verbindungsversuche gemäß [TIP1-A_6191] reagieren.
[<=]TIP1-A_6177 - Eine Verbindung zu jedem vKT
Zu einem Zeitpunkt MUSS das HSM-B zu jedem SICCT-Kommandointerpreter-Port (vKT) jeweils nur eine SICCT-spezifische TLS-Verbindung gemäß [TIP1-A_6155] unterstützen. Bei Unterstützung mehrerer Verbindungen ist jede Art von Ressourcenkonflikten vom HSM-B selbst zu verhindern.
[<=]TIP1-A_6178 - Robuste HSM Dienste
Eine Fehlersituation während einer Operation in einem vKT oder einer vSMC-B DARF NICHT dazu führen, dass legitime Operationen in restlichen vKTs und vSMC-Bs nicht weiter genutzt werden können.
[<=]TIP1-A_6179 - Nicht-unterstützte SICCT Kommandos
Abweichend vom eHealth-Kartenterminal [gemSpec_KT] SOLL das HSM-B die SICCT Kommandos
SICCT SELECT CT MODE
SICCT COMFORT AUTHENTICATION
SICCT COMFORT ENROLL
SICCT DOWNLOAD INIT
SICCT DOWNLOAD DATA
SICCT DOWNLOAD FINISH
SICCT CONTROL COMMAND
SICCT INPUT
SICCT OUTPUT
SICCT PERFORM VERIFICATION
SICCT MODIFY VERIFICATION DATA
NICHT unterstützen.
Empfängt das HSM-B eines der obengenannten Kommandos in einer virtuellen Kartenterminalsession, MUSS das HSM-B mit einer Response-APDU, die aus einem leeren „Body“ und einem Statuswort „SW1SW2“ gemäß Tab_HSM-B_003 besteht, antworten.
[<=]SICCT Command |
Statuswort (SW1SW2) |
Bedeutung |
---|---|---|
SICCT SELECT CT MODE |
6D00 |
Wrong Instruction |
SICCT COMFORT AUTHENTICATION |
6D00 |
Wrong Instruction |
SICCT COMFORT ENROLL |
6D00 |
Wrong Instruction |
SICCT DOWNLOAD INIT |
6D00 |
Wrong Instruction |
SICCT DOWNLOAD DATA |
6D00 |
Wrong Instruction |
SICCT DOWNLOAD FINISH |
6D00 |
Wrong Instruction |
SICCT SET STATUS |
6D00 |
Wrong Instruction |
SICCT CONTROL COMMAND |
6200 |
Specified command not found |
SICCT INPUT |
6940 |
Command with display not supported |
SICCT OUTPUT |
6940 |
Command with display not supported |
SICCT PERFORM VERIFICATION |
6940 |
Command with display not supported |
SICCT MODIFY VERIFICATION DATA |
6940 |
Command with display not supported |
TIP1-A_6180 - Keine CT Admin Rolle
Das HSM-B DARF abweichend von den Regelungen in [SICCT#3.6] die Rolle CT Admin NICHT umsetzen.
[<=]TIP1-A_6997 - Behandlung CA-Zertifikate der Komponenten PKI
Das HSM-B MUSS CA-Zertikate der Komponenten-PKI entsprechend den Anforderungen aus [gemSpec_KT#3.11] einbringen, speichern und aktualisieren.
[<=]4.2 Zertifikate und Schlüsselobjekte (normativ)
4.2.1 X.509-Objekte der vKTs (normativ)
TIP1-A_6181 - Verfügbarkeit der X.509-Zertifikate der Kartenterminalanwendung im HSM-B
Das HSM-B MUSS sicherstellen, dass jedem vKT jeweils die X.509-Zertifikate
CA Zertifikate der Komponenten-PKI (C.CA.KOMP)
C.SMKT.AUT.R2048
durchgehend zur Verfügung stehen.
[<=]TIP1-A_6182 - X.509-Zertifikate, die exklusiv zu einem vKT gehören
Das HSM-B MUSS das X.509-Zertifikat
C.SMKT.AUT.R2048
aus [TIP1-A_6181] so zur Verfügung stellen, dass dieses X.509-Zertifikat nur durch das zugehörige vKT genutzt werden kann.
[<=]TIP1-A_6183 - Gemeinsame Nutzung der CA-Zertifikate zwischen vKTs
Das HSM-B KANN die CA-Zertifikate aus [TIP1-A_6181] so zur Verfügung stellen, dass diese durch alle vKTs gemeinsam genutzt werden können.
[<=]TIP1-A_6184 - Verfügbarkeit der privaten X.509-Schlüsselobjekte der Kartenterminalanwendung im HSM-B
Analog zur Kartenterminalanwendung einer gSMC-KT (siehe [gemSpec_gSMC-KT_ObjSys#Abb_gSMC-KT-ObjSys_002]) MUSS das HSM-B sicherstellen, dass jedem vKT jeweils eine exklusive Instanz des privaten X.509-Schlüsselobjekts
PrK.SMKT.AUT.R2048
durchgehend zur Verfügung steht.
[<=]TIP1-A_6185 - Private X.509-Schlüsselobjekte, die exklusiv zu einem vKT gehören
Das HSM-B MUSS das private X.509-Schlüsselobjekt aus [TIP1-A_6184] so zur Verfügung stellen, dass dieses private X.509-Schlüsselobjekt nur durch das zugehörige vKT genutzt werden kann.
[<=]4.3 Pairing mit Konnektor (normativ)
Im Gegensatz zum eHealth-Kartenterminal ist kein Pairing zwischen Konnektor und einem virtuellen Kartenterminal (vKT) zur Authentisierung notwendig.
Das Pairing zwischen Konnektor und eHealth-Kartenterminal wird verwendet, um Spoofing-Angriffe zu verhindern; Das eHealth-Kartenterminal verwendet das Schlüsselmaterial, das in einer gSMC-KT gespeichert ist, um sich gegenüber dem Konnektor während des Aufbaus einer SICCT-spezifischen TLS-Verbindung zu authentisieren. Weil eine gSMC-KT aus einem Kartenterminal entfernt und unbefugt in einem anderen Terminal genutzt werden kann, ist die Sicherheit einer solchen Authentisierung, die lediglich auf den Besitzt einer gSMC-KT basiert, aus Sicht des Konnektors nicht ausreichend. Daher verifiziert der Konnektor die Authentizität eines eHealth-Kartenterminals zusätzlich mit einer Kennung, die im eHealth-Kartenterminal gespeichert wird und die er selbst generiert hat. Das Verfahren, das zum Aushandeln sowie zum Verifizieren dieser Kennung verwendet wird, wird als Pairing bezeichnet (siehe [gemSpec_KT#2.5.2]).
Anders als ein eHealth-Kartenterminal verwendet ein vKT das Schlüsselmaterial PuK_SMKT_AUT_R2048, PrK_SMKT_AUT_R2048, um sich gegenüber dem Konnektor während des Aufbaus der SICCT-spezifischen TLS-Verbindung zu authentisieren. Daher muss ein Angreifer mindestens einen der folgenden Angriffe durchführen, um die Identität eines vKTs erfolgreich „Spoofen“ zu können:
- Das Auslesen des privaten Authentisierungsschlüssels PrK_SMKT_AUT_R2048 aus dem HSM-B
- Das Deduzieren des privaten Authentisierungsschlüssels PrK_SMKT_AUT_R2048 aus öffentlichen Protokolldaten, die während der Etablierung der TLS-Verbindung ausgetauscht werden.
Angenommen, dass das HSM-B die übergreifenden Sicherheitsanforderungen aus dem Kapitel 0 und die Anforderungen aus dem Kapitel 0 erfüllt, ist die Wahrscheinlichkeit, dass ein Angreifer den privaten Authentisierungsschlüssel PrK_SMKT_AUT_R2048 aus dem HSM-B erfolgreich auslesen kann, vernachlässigbar gering.
Angenommen, dass das HSM-B die Anforderungen aus dem Kapitel 0 und [TIP1-A_6334] sowie die normativen Vorgaben aus [gemSpec_Krypt] erfüllt, ist die Wahrscheinlichkeit, dass ein Angreifer aus öffentlichen Protokolldaten, wie z.B. PuK_SMKT_AUT_R2048, den privaten Schlüsselobjekt PrK_SMKT_AUT_R2048 deduzieren kann, vernachlässigbar gering.
Daher ist die Sicherheit einer solchen Authentifizierung gegen die Spoofing-Angriffe, die auf den Besitzt der Schlüsselmaterial im HSM basiert, aus Sicht des Konnektors ausreichend. Jedoch muss das HSM-B aus Kompatibilitätsgründen die Pairing-Abläufe
- Initiales Pairing,
- Überprüfung der Pairing-Informationen und
- Wartungs-Pairing
unterstützen (siehe [gemSpec_KT#2.5.2]).
TIP1-A_6186 - Unterstützung von Pairing
Das HSM-B MUSS für jedes vKT die normativen Vorgaben aus gemSpec_KT für
Initiales Pairing
Überprüfung der Pairing-Informationen
Wartungs-Pairing
erfüllen.
[<=]TIP1-A_6187 - Unterstützung von Kommando „EHEALTH TERMINAL AUTHENTICATE“
Das HSM-B MUSS für jedes vKT die „EHEALTH TERMINAL AUTHENTICATE“-Varianten
CREATE (P2=’01’) [gemSpec_KT#TIP1-A_3125]
VALIDATE (P2=‘02‘) [gemSpec_KT#TIP1-A_3126]
ADD (P2=‘03‘ und P2=‘04‘) [gemSpec_KT#TIP1-A_3127 und TIP1-A_3128]
mit der Änderung gemäß [TIP1-A_6998] umsetzen.
[<=]TIP1-A_6998 - „EHEALTH TERMINAL AUTHENTICATE“ Ausführung ohne Display / Keypad
Virtuelle Kartenterminals verfügen über keine Anzeigeeinheit (Display) oder ein Keypad. Daher wird KANN die Ausführung dieses Kommandos von [gemSpec_KT#SEQ_KT_0001] abweichen; Steuerung des „initialen Pairings-Prozesses“ durch eine Anzeigeeinheit (Display) und ein Keypad werden nicht unterstützt. Daher entfällt die Ausgabe der Nachrichten auf einem Display immer. Die Bestätigungsanforderung über das Keypad wird durch explizites vorheriges Setzen der Bestätigungsanforderung im vKT ersetzt (siehe [gemSpec_KT#SEQ_KT_0001] Schritt 5 und [TIP1-A_6299])
Entsprechende Optionen der C-APDU für Displaymessage bzw. Eingabeanforderung KÖNNEN werden ignoriert werden.
[<=]4.4 Reaktionen auf Ereignisse (normativ)
Das HSM-B muss auf
- Dienstanfragen eines Konnektors gemäß den Angaben aus [4.1.2]
- Verbindungsversuche eines Konnektors gemäß den Angaben aus [4.1.3]
- empfangene Kommandos eines Konnektors gemäß den Angaben aus [4.1.4]
- Ereignisse von Managementaktionen gemäß den Angaben aus [4.1.5]
reagieren.
4.4.1 Reaktion auf Dienstanfragen
TIP1-A_6189 - Reaktion auf Dienstanfragen (optional)
Ein aktives vKT KANN MUSS Dienstanfragen (Service Discovery), die den Clients (Konnektoren) das Auffinden von Kartenterminals ermöglichen, entsprechend [SICCT#6.1.3.1] und [gemSpec_KT#3.7.9] unterstützen. [<=]
DISCLAIMER: Umsetzung in Abhängigkeit eines noch zu verhandelnden Change Requests
4.4.2 Reaktion auf Verbindungsversuche
TIP1-A_6191 - Reaktion auf eingehende Verbindungsversuche
Das HSM-B MUSS für jedes aktive vKT den Aufbau einer SICCT-konformen TLS-Verbindung mit einem Client (Konnektor) gemäß [gemSpec_KT] unterstützen.
[<=]
4.4.3 Reaktion auf eingehende SICCT Kommandos
TIP1-A_6192 - Reaktion auf die eingehenden SICCT Kommandos
Das HSM-B MUSS SICCT Kommandos gemäß [SICCT#5.5.7] unterstützen mit den Einschränkungen gemäß.
[<=]
4.4.4 Reaktion auf Ereignisse aus Managementaktionen
TIP1-A_6197 - Ereignisnachricht senden
Das HSM-B MUSS das Senden von Statusänderungen auf Grund von empfangenen
über die Schnittstelle „I_Notification“ [3.1.1] zum Konnektor entsprechend der Anforderung [TIP1-A_6147] unterstützen.
[<=]
TIP1-A_6194 - Wird ein aktives vKT deaktiviert (siehe [TIP1-A_6297), so MUSS das HSM-B: * Eine...
Wird ein aktives vKT deaktiviert (siehe [TIP1-A_6297), so MUSS das HSM-B:
- Eine Ereignisnachricht mit Tag = ´81´ an den mit diesem vKT verbundenen Client senden.
TIP1-A_6195 - Reaktion auf Ereignis – virtuelle Karte eingesteckt
Wird eine vSMC-B in ein aktives vKT gesteckt (siehe [TIP1-A_6309], so MUSS das HSM-B:
die FU-Nummer des betroffenen Slots gemäß [SICCT#5.5.9.2] berechnen;
Eine Ereignisnachricht mit Tag = ´84´ und FU-Nummer des Slots an den mit diesem vKT verbundenen Client senden.
TIP1-A_6196 - Reaktion auf Ereignis – virtuelle Karte entfernt
Wird eine vSMC-B aus einem aktiven vKT entfernt (siehe [TIP1-A_6310], so MUSS das HSM-B:
die FU-Nummer des betroffenen Slots gemäß [SICCT#5.5.9.2] berechnen;
Eine Ereignisnachricht mit Tag = ´85´ und FU-Nummer des Slots an den mit diesem vKT verbundenen Client senden.
4.5 Kartenterminalkommandos (normativ)
Das HSM-B muss die Kartenterminalkommandos, die aus dem Konnektor über die Schnittstelle „I_HSM-Operations“ empfangen werden, gemäß [SICCT] bearbeiten.
4.5.1 Kartenterminal-Session öffnen
SICCT-Kartenterminalkommandos dürfen nur in einer geöffneten Kartenterminal-Session verarbeiten werden [SICCT#5.10]. Eine Kartenterminal-Session wird durch das Kommando „SICCT INIT CT SESSION“ geöffnet.
TIP1-A_6198 - Umsetzung des Kommandos „SICCT INIT CT SESSION“
Das HSM-B MUSS das Kommando „SICCT INIT CT SESSION“ gemäß [SICCT#5.10] und [gemSpec_KT#3.7.9] umsetzen.
[<=]
4.5.2 Kartenterminal-Session schließen
SICCT Kartenterminal-Sessions in einem Kartenterminal dürfen nicht parallel geöffnet werden [SICCT#6.1.4.3]. Eine neue Kartenterminal-Session kann nur dann geöffnet werden, wenn keine andere geöffnet ist. Eine bestehende Kartenterminal-Session wird durch das Kommando „SICCT CLOSE CT SESSION“ geschlossen.
TIP1-A_6200 - Umsetzung des Kommandos „SICCT CLOSE CT SESSION“
Das HSM-B MUSS das Kommando „SICCT CLOSE CT SESSION“ gemäß [SICCT#5.11] umsetzen, mit den Ergänzungen gemäß
TIP1-A_6180.
Hinweis: Da entsprechend TIP1-A_6180 die Rolle CT Admin nicht umgesetzt wird, ist der Sonderfall „Beenden einer CT-Session durch den Administrator“ nicht möglich.
4.5.3 Kartenterminal-Status liefern
Statusinformationen über ein Kartenterminal bzw. seine adressierbaren Funktionseinheiten müssen abgefragt werden können [SICCT#5.15.1]. Der Status eines Kartenterminals oder seiner Funktionseinheiten werden durch das Kommando „SICCT GET STATUS“ abgefragt.
TIP1-A_6202 - Umsetzung des Kommandos „SICCT GET STATUS“
Das HSM-B MUSS das Kommando „SICCT GET STATUS“ gemäß [SICCT#5.15] umsetzen, mit den Ergänzungen gemäß
TIP1-A_6203
TIP1-A_6204
TIP1-A_6205
TIP1-A_6999
TIP1-A_6203 - Implementierung CTM DO gemäß eHealth-Kartenterminal
Das HSM-B MUSS das „Card Terminal Manufacturer Data Object (CTM DO)“ gemäß [gemSpec_KT#3.7.7] implementieren.
[<=]TIP1-A_6204 - Festlegung „ICC Status Byte“ für das HSM-B
Abweichend von [SICCT#5.5.10.7] MUSS das HSM-B zur Darstellung von Betriebsstatus seiner virtuellen Kartenterminals nur die Kodierungen für die folgenden Statuswerte verwenden:
CC Absent
CC Swallowed
CC Powered
CC Unknown.
Das HSM-B KANN die Kodierung für weitere Betriebsstatus aus der Spezifikation [SICCT#5.5.10.7] unterstützen.
[<=]TIP1-A_6205 - Implementierung „INTFC DO“ für das HSM-B
Das HSM-B MUSS das „ICC Interface Capabilities Data Objects (INTFC DO)“ gemäß Tab_HSM-B_014 implementieren.
[<=]
ICC Interface Capabilities Data Object (INTFC DO) |
|||
---|---|---|---|
TAG |
gemäß [SICCT#5.5.10.16] |
||
LEN |
gemäß [SICCT#5.5.10.16] |
||
VALUE |
Interface Device Protocol Options |
||
Tag |
Len |
Value |
|
gemäß [SICCT#5.5.10.16] |
Supported Card Size |
||
´03´ |
|||
gemäß [SICCT#5.5.10.16] |
Supported / available Mechanical Attributes |
||
´1F´ |
|||
gemäß [SICCT#5.5.10.16] |
Supported / available Card Contacts |
||
´01110111´ |
|||
gemäß [SICCT#5.5.10.16] |
Supported Card Types |
||
´07´ |
|||
gemäß [SICCT#5.5.10.16] |
Supported Asynchr. Protocols |
||
´02´ |
|||
gemäß [SICCT#5.5.10.16] |
Supported Synchr. Protocols |
||
´0F´ |
|||
gemäß [SICCT#5.5.10.16] |
Supported Wireless ISO 14443-Protocols |
||
´00´ |
|||
gemäß [SICCT#5.5.10.16] |
Extended Length Indication |
||
gemäß [SICCT#5.5.10.16] |
|||
TIP1-A_6999 - „SICCT GET STATUS“ Unterstützte DOs
Wenn der Command Qualifier nicht aus der Menge [CTM DO, ICCS DO, FU DO FU_NAME DO, INTFC DO, CTS DO} kommt, dann MUSS antwortet das Kommando mit dem Statuswort „Wrong parameters P1, P2“ gemäß [SICCT#5.15.6] antworten.
[<=]4.5.4 Kartenterminal zurücksetzen
Ein Kartenterminal oder seine adressierbaren Funktionseinheiten müssen logisch in einen definierten initialen Zustand gesetzt werden können [SICCT#5.12]. Ein Kartenterminal oder seine adressierbaren Funktionseinheiten werden durch das Kommando „SICCT RESET ICC/CT“ logisch in einen definierten initialen Zustand gesetzt.
TIP1-A_6207 - Umsetzung des Kommandos „SICCT RESET CT“
Das HSM-B MUSS das Kommando „SICCT RESET CT“ gemäß [SICCT#5.12] umsetzen.
[<=]4.5.5 Karte aktivieren
(Virtuelle) Karten an adressierbaren Funktionseinheiten eines (virtuellen) Kartenterminals müssen aktiviert werden können [SICCT#5.13]. Eine (virtuelle) Karte an einer adressierbaren Funktionseinheit eines (virtuellen) Kartenterminals wird durch das Kommando „SICCT REQUEST ICC“ aktiviert.
TIP1-A_6209 - Umsetzung des Kommandos „SICCT REQUEST ICC“
Das HSM-B MUSS das Kommando „SICCT REQUEST ICC“ gemäß [SICCT#5.13] umsetzen, mit der Ergänzung gemäß
TIP1-A_7000
TIP1-A_7000 - „SICCT REQUEST ICC“ Ausführung ohne Display / Keypad
Die Steuerung der Aktivierungsprozesse durch eine Anzeigeeinheit (Display) oder ein Keypad werden nicht unterstützt. Daher entfällt die Ausgabe der Nachrichten auf einem Display immer. Die Optionen der C-APDU für die Eingabeanforderung KÖNNEN werden ignoriert werden.
[<=]4.5.6 Karte deaktivieren
(Virtuelle) Karten an adressierbaren Funktionseinheiten eines (virtuellen) Kartenterminals müssen deaktiviert werden können [SICCT#5.14]. Eine (virtuelle) Karte an einer adressierbaren Funktionseinheit eines (virtuellen) Kartenterminals wird durch das Kommando „SICCT EJECT ICC“ deaktiviert.
TIP1-A_7001 - „SICCT EJECT ICC“ Auswurf der Karte
Das HSM-B MUSS das Kommando „SICCT REQUEST ICC“ gemäß [SICCT#5.14] umsetzen, mit der Ergänzung gemäß
TIP1-A_7002
Das Statuswort wird wie folgt gesetzt
´9001´ wenn “bit2” des Command Qualifier ´0´ (Auswurf der Karte) ist
´9000´ wenn “bit2” des Command Qualifier ´1´ (Kein Auswurf der Karte) ist.
TIP1-A_7002 - „SICCT EJECT ICC“ Ausführung ohne Display / Keypad
Die Steuerung der Aktivierungsprozesse durch eine Anzeigeeinheit (Display) oder ein Keypad werden nicht unterstützt. Die Nachrichten/Signale (akustische/optische Signale so wie mechanischer Entwurf der Karte) werden daher nicht zur Anzeige gebracht. Die entsprechenden Optionen der C-APDU KÖNNEN werden ignoriert werden.
[<=]
5 Virtuelle SMC-B
Die Komponente „virtuelle SMC-B (vSMC-B)“ implementiert die Schnittstelle
- I_Smartcard_Operations [TIP1-A_6145]
(siehe [3.1.1]). Eine Zuordnung zwischen dieser Schnittstelle und deren technischer Ausprägung in dieser Komponente sind informativ in Tabelle 1 dargestellt.
Das HSM-B kann über mehrere vSMC-Bs verfügen. Jede vSMC-B hat die Aufgabe, das funktionale Verhalten einer SMC-B zu ersetzen. Die vSMC-B muss die Funktionalität einer SMC-B soweit implementieren, dass eine vSMC-B für die Anwendungen, die sie nutzen, wie eine SMC-B aussieht. Das Objektsystem der vSMC-Bs basiert auf der Spezifikation des SMC-B Objektsystem [gemSpec_SMC-B_ObjSys].
Da wie oben beschrieben, eine vSMC-B nur die Funktionalität implementieren muss, die die Anwendung, die sie nutzt (also der Konnektor), benötigt, kann die Funktionalität einer vSMC-B gegenüber einer SMC-B eingeschränkt sein. Dies betrifft sowohl die Funktionalität des COS als auch das Objektsystem einer SMC-B. Einschränkungen sind in diesem Kapitel dokumentiert.
5.1 Card Operating System (normativ)
TIP1-A_7029 - Unterstützung COS-Funktionalität
Eine vSMC-B MUSS die Funktionalität eines COS entsprechechend gemSpec_COS unterstützen mit den Optionen gemäß gemSpec_SMC-B_ObjSys und den Beschränkungen, Erweiterungen gemäß:
- TIP1-A_7003
- TIP1-A_7004
- TIP1-A_7005
- TIP1-A_7006
- TIP1-A_7007
- TIP1-A_7008
[<=]
TIP1-A_7003 - Das Attribut pointInTime KANN vom verschiedenen vSMC-Bs gemeinsam genutzt. In di...
Das Attribut pointInTime KANN vom verschiedenen vSMC-Bs gemeinsam genutzt. In diesem Fall wird im Zuge der Personalisierung der Wert von pointInTime aktualisiert, wenn CED eines Endnutzerzertifikats größer als der aktuelle Wert von pointInTime ist
[<=]
Die folgenden Anforderungen ergeben sich daraus, dass das Objektsystem einer vSMC-B nicht die volle Funktionalität eines COS gemäß [gemSpec_COS] benötigt.
TIP1-A_7004 - Nicht unterstützte COS Kommandos
Das HSM-B MUSS folgende normative Kommandos gemäß [gemSpec_COS#14] NICHT unterstützen.
EraseBinary, UpdateBinary, WriteBinary, SetLogicalEndOfFile
AppendRecord, DeleteRecord, UpdateRecord
LoadApplication, Delete
PSO Transcipher
GenerateAsymmetricKeyPair
Fingerprint
Empfängt eine vSMC-B eines der oben genannten Kommandos MUSS die vSMC-B das Statuswort InstructionNotSupported (‚6D00‘) zurücksenden.
[<=]TIP1-A_7005 - Keine Unterstützung von verschiedenen Security Environments
Das HSM-B MUSS nur das SE#1 unterstützen. Siehe [gemSpec_SMC-B_ObjSys# Card-G2-A_2135]
[<=]TIP1-A_7006 - Keine Unterstützung dfSpecificSecurityList
Das HSM-B MUSS eine dfSpecificSecurityList gemäß [gemSpec_COS#12.1] NICHT unterstützen.
[<=]TIP1-A_7007 - Keine Unterstützung dfSpecificPasswordList
Das HSM-B MUSS eine dfSpecificPassword gemäß [gemSpec_COS#12.1] NICHT unterstützen.
[<=]TIP1-A_7008 - Keine Unterstützung von DF-spezifischen Passwörtern
Das HSM-B MUSS DF-spezifische Passwörter und deren Suche gemäß [gemSpec_COS#9.2.2] NICHT unterstützen.
[<=]5.1.1 Secure Messaging (normativ)
TIP1-A_6233 - Unterstützung von „Sessionkey-Ableitung“
Das HSM-B MUSS die Ableitung von Sessionkeys gemäß [gemSpec_COS#13.1.1] in der Variante
Aushandlung mittels asymmetrischer Schlüssel [gemSpec_COS#(N031.500)]
unterstützen.
Das HSM-B KANN weitere Sessionkey-Ableitung-Varianten aus der Spezifikation [gemSpec_COS#13.1.1] unterstützen.
[<=]Hinweis: Da eine vSMC-B keine RSA-Schlüssel zur Sessionkey-Aushandlung enthält, muss nur die Aushandlung von AES-Schlüsseln unterstützt werden
TIP1-A_6235 - Verwendungszweck der Sessionkeys
Das HSM-B MUSS die „Sessionkeys“ nur im Rahmen von
Secure Messaging [gemSpec_COS#(N031.520)]
einsetzen.
Das HSM-B KANN weitere Verwendungszwecke (z.B. Trusted Channels [gemSpec_COS#(031.522)] unterstützen.
[<=]TIP1-A_6237 - Umsetzung “Bearbeitung einer per Secure Messaging gesicherten Kommando-APDU”
Das HSM-B MUSS die Bearbeitung einer per Secure Messaging gesicherten Kommando-APDU gemäß [gemSpec_COS#13.1.2] und [gemSpec_COS#13.2] umsetzen
[<=]TIP1-A_6239 - Umsetzung “Sicherung einer ungesicherten Antwort-APDU”
Das HSM-B MUSS die Sicherung einer ungesicherten Antwort-APDU gemäß [gemSpec_COS#13.1.2] und [gemSpec_COS#13.3] umsetzen.
[<=]
5.1.2 Kommandos C2C-Authentisierung (normativ)
TIP1-A_6241 - Umsetzung des Kommandos „Internal Authenticate“
Das HSM-B MUSS das Kommando „INTERNAL AUTHENTICATE“ gemäß [gemSpec_COS#14.7.4] in der Variante
Interne Authentisierung mit den AlgorithmenIdentifier elcRoleAuthentication, rsaRoleAuthentication, rsaClientAuthentication, signPKCS1_V1_5
unterstützen.
[<=]TIP1-A_6244 - Umsetzung des Kommandos „External Authenticate“
Das HSM-B MUSS das Kommando „EXTERNAL AUTHENTICATE“ gemäß [gemSpec_COS#14.7.1] in der Variante
Externe Authentisierung ohne Antwortdaten [gemSpec_COS#14.7.1.1] mit dem AlgorithmenIdentifier elcRoleCheck
unterstützen.
Das HSM-B KANN weitere „EXTERNAL AUTHENTICATE“-Varianten aus der Spezifikation [gemSpec_COS#14.7.1] unterstützen.
[<=]TIP1-A_6247 - Umsetzung des Kommandos „Get Challenge“
Das HSM-B MUSS das Kommando „GET CHALLENGE“ gemäß [gemSpec_COS#14.9.4] in der Variante
Zufallszahl für AES oder ELC Authentisierung [gemSpec_COS#14.9.4.2]
unterstützen.
Das HSM-B KANN weitere „GET CHALLENGE“-Varianten aus der Spezifikation [gemSpec_COS#14.9.4] unterstützen.
[<=]TIP1-A_6250 - Umsetzung des Kommandos „General Authenticate“
Das HSM-B MUSS das Kartenkommando „GENERAL AUTHENTICATE“ gemäß [gemSpec_COS#14.7.2] in der Variante
Gegenseitige Authentisierung mit Sessionkey-Aushandlung mittels ELC Schlüssel [gemSpec_COS#14.7.2.2]
unterstützen.
Das HSM-B KANN weitere „GENERAL AUTHENTICATE“-Varianten aus der Spezifikation [gemSpec_COS#14.7.2] unterstützen.
[<=]TIP1-A_6253 - Umsetzung des Kommandos „Get Security Status Key“
Das HSM-B MUSS das Kartenkommando „GET SECURITY STATUS KEY“ gemäß [gemSpec_COS#14.7.3] in der Variante
Auslesen des Sicherheitsstatus einer Bitliste [gemSpec_COS#14.7.3.3]
unterstützen.
Das HSM-B KANN weitere „GET SECURITY STATUS KEY“-Varianten aus der Spezifikation [gemSpec_COS#14.7.3] unterstützen.
[<=]Hinweis: Da eine vSMC-B keine symmetrischen bzw. öffentlichen RSA Authentisierungsschlüssel enthält und diese auch nicht importiert werden können, können die hierfür benötigten Varianten des Kommandos entfallen.
5.1.3 Kommandos Benutzerverifikation (normativ)
Hinweis: Die Zugriffsregel für die PIN.SMC wurde entsprechend TIP1-A_7032 dahingegehend geändert, dass die Kommandos zur Benutzerverifikation nur mit dem RemotePin-Verfahren möglich sind.
TIP1-A_6262 - Umsetzung des Kommandos „Verify“
Das HSM-B MUSS das Kommando „VERIFY“ gemäß [gemSpec_COS#14.6.6] in der Variante
Vergleich eines Benutzergeheimnisses [gemSpec_COS#14.6.6.1]
unterstützen.
[<=]TIP1-A_6265 - Umsetzung des Kommandos „Change Reference Data“
Das HSM-B MUSS das Kartenkommando „CHANGE REFERENCE DATA“ gemäß [gemSpec_COS#14.6.1] in der Variante
Ändern eines Benutzergeheimnisses [gemSpec_COS#14.6.1.1]
unterstützen.
Das HSM-B KANN weitere „CHANGE REFERENCE DATA“-Varianten aus der Spezifikation [gemSpec_COS#14.6.1] unterstützen.
[<=]TIP1-A_6268 - Umsetzung des Kommandos „Reset Retry Counter“
Das HSM-B MUSS das Kartenkommando „RESET RETRY COUNTER“ gemäß [gemSpec_COS#14.6.5] in den Varianten
Entsperren mit PUK, mit neuem Geheimnis [gemSpec_COS#14.6.5.1]
Entsperren mit PUK, ohne neues Geheimnis [gemSpec_COS#14.6.5.2]
unterstützen.
Das HSM-B KANN weitere „RESET RETRY COUNTER“-Varianten aus der Spezifikation [gemSpec_COS#14.6.5] unterstützen.
[<=]
TIP1-A_6271 - Umsetzung des Kommandos „Get PIN Status“
Das HSM-B MUSS das Kartenkommando „GET PIN STATUS“ gemäß [gemSpec_COS#14.6.4] in der Variante
Auslesen des Status eines Passwortobjektes [gemSpec_COS#14.6.4.1]
unterstützen.
[<=]5.1.4 Kommandos Kryptobox (normativ)
TIP1-A_6225 - Umsetzung des Kommandos „PSO Verify Certificate“
Das HSM-B MUSS das Kommando „PSO Verify Certificate“ gemäß [gemSpec_COS#14.8.7] in der Variante
Import eines ELC-Schlüssels mittels Zertifikat [gemSpec_COS#14.8.7.2]
umsetzen.
Das HSM-B KANN weitere „PSO VERIFY CERTIFICATE“-Varianten aus der Spezifikation [gemSpec_COS#14.8.7] unterstützen
[<=]TIP1-A_6274 - Umsetzung des Kommandos „PSO Compute Digital Signature“
Das HSM-B MUSS das Kommando „PSO Compute Digital Signature“ gemäß [gemSpec_COS#14.8.2] in der Variante
Signieren des Datenfeldes ohne „Message Recovery“ [gemSpec_COS#14.8.2.1], mit den AlgorithmenIdentifiern rsaClientAuthenticate, signPKCS1_V1_5, signPSS
unterstützen.
Das HSM-B KANN weitere „PSO Compute Digital Signature“-Varianten aus der Spezifikation [gemSpec_COS#14.8.2] unterstützen.
[<=]TIP1-A_6277 - Umsetzung des Kommandos „PSO Decipher“
Das HSM-B MUSS das Kommando „PSO Decipher“ gemäß [gemSpec_COS#14.8.3] in der Variante
Entschlüsseln mittels RSA [gemSpec_COS#14.8.3.1]
unterstützen.
Das HSM-B KANN weitere „PSO Decipher“-Varianten aus der Spezifikation [gemSpec_COS#14.8.3] unterstützen.
[<=]5.1.5 Kommandos Datenzugriff (normativ)
TIP1-A_6280 - Umsetzung des Kommandos „Read Binary“
Das HSM-B MUSS das Kommando „READ BINARY“ gemäß [gemSpec_COS#14.3.2] in den Varianten
Lesen ohne shortFileIdentifier [gemSpec_COS#14.3.2.1]
Lesen mit shortFileIdentifier [gemSpec_COS#14.3.2.2]
umsetzen.
[<=]TIP1-A_7009 - Umsetzung des Kommandos „Read Record“
Das HSM-B MUSS das Kommando „READ RECORD“ gemäß [gemSpec_COS#14.4.6] in den Varianten
Lesen ohne shortFileIdentifier [gemSpec_COS#14.4.6.1]
Lesen mit shortFileIdentifier [gemSpec_COS#14.4.6.2]
umsetzen.
[<=]TIP1-A_7011 - Umsetzung des Kommandos „Search Record“
Das HSM-B MUSS das Kommando „SEARCH RECORD“ gemäß [gemSpec_COS#14.4.7] in den Varianten
Suchen ohne shortFileIdentifier [gemSpec_COS#14.4.7.1]
Suchen mit shortFileIdentifier [gemSpec_COS#14.4.7.2]
umsetzen.
[<=]5.1.6 Kommandos Verschiedenes (normativ)
TIP1-A_6283 - Umsetzung des Kommandos „Manage Security Environment“
Das HSM-B MUSS das Kommando „MANAGE SECURITY ENVIRONMENT“ gemäß [gemSpec_COS#14.9.9] in den Varianten
Schlüsselauswahl zur internen, asymmetrischen Authentisierung [gemSpec_COS#14.9.9.3]
Schlüsselauswahl zur externen, asymmetrischen Authentisierung [gemSpec_COS#14.9.9.5]
Schlüsselauswahl für Signierschlüssel [gemSpec_COS#14.9.9.9]
Schlüsselauswahl zum Prüfen von CV-Zertifikaten [gemSpec_COS#14.9.9.10]
Schlüsselauswahl zur Datenentschlüsselung [gemSpec_COS#14.9.9.11]
unterstützen.
Das HSM-B KANN weitere „MSE“-Varianten aus der Spezifikation [gemSpec_COS#14.9.9] unterstützen.
[<=]TIP1-A_6287 - Umsetzung des Kommandos „Manage Channel“
Das HSM-B MUSS das Kartenkommando „MANAGE CHANNEL“ gemäß [gemSpec_COS#14.9.8] in den Varianten
Öffnen eines logischen Channels [gemSpec_COS#14.9.8.1]
Schließen eines logischen Channels [gemSpec_COS#14.9.8.2]
Zurücksetzen eines logischen Channels [gemSpec_COS#14.9.8.3]
Logischer Reset der Applikationsebene [gemSpec_COS#14.9.8.4]
unterstützen.
[<=]TIP1-A_6291 - Umsetzung des Kommandos „Select“
Das HSM-B MUSS das Kommando „SELECT“ gemäß [gemSpec_COS#14.2.6] in den Varianten
Selektieren ohne AID, first, keine Antwortdaten [gemSpec_COS#14.2.6.1]
Selektieren ohne AID, first, Antwortdaten mit FCP [gemSpec_COS#14.2.6.2]
Selektieren per AID, first, keine Antwortdaten [gemSpec_COS#14.2.6.5]
Selektieren per AID, first, Antwortdaten mit FCP [gemSpec_COS#14.2.6.6]
Selektieren, DF oder ADF, keine Antwortdaten [gemSpec_COS#14.2.6.9]
Selektieren, DF oder ADF, Antwortdaten mit FCP [gemSpec_COS#14.2.6.10]
Selektieren übergeordnetes Verzeichnis ohne FCP [gemSpec_COS#14.2.6.11]
Selektieren übergeordnetes Verzeichnis mit FCP [gemSpec_COS#14.2.6.12]
Selektieren einer Datei, keine Antwortdaten [gemSpec_COS#14.2.6.13]
Selektieren einer Datei, Antwortdaten mit FCP [gemSpec_COS#14.2.6.14]
unterstützen.
Das HSM-B KANN weitere „Select“-Varianten aus der Spezifikation [gemSpec_COS#14.2.6] unterstützen.
[<=]TIP1-A_7013 - Umsetzung des Kommandos „Get Random“
Das HSM-B MUSS das Kommando „GET RANDOM“ gemäß [gemSpec_COS#14.9.5] in der Variante
Erzeugen kryptographisch sicherer Zufallszahl [gemSpec_COS#14.0.5.1]
umsetzen.
[<=]Hinweis: Das Kommando GET RANDOM ist laut aktuellen Spezifikationen für eine SMC-B optional, soll jedoch verpflichtend werden. Daher ist dieses Kommando auch für ein HSM-B verpflichtend.
5.2 vSMC-B Objektsystem
TIP1-A_6213 - vSMC-B Objektsystem
Die vSMC-B MUSS die Spezifikation des SMC-B Objektsystems [gemSpec_SMC-B_ObjSys] umsetzen, mit den Änderungen, Ergänzungen gemäß
TIP1-A_7021 Beschränkte Unterstützung des Objektsystems
TIP1-A_7030 Zugriffsregel für nicht unterstützte Kommandos
TIP1-A_7031 Unterstützte Algorithmen
TIP1-A_7032 Zugriffregel PIN.SMC
TIP1-A_7021 - Beschränkte Unterstützung des Objektsystems
Das HSM-B MUSS folgende normative Objekte gemäß [gemSpec_SMC-B_ObjSys] NICHT unterstützen.
DF.SMA inklusive aller Unterobjekte
PuK.RCA.CS.R2048
TIP1-A_7030 - Unterstützte Algorithmen
Nicht unterstützte Alogrithmen KÖNNEN aus listAlgorithmIdentifier entfernt werden
[<=]TIP1-A_7031 - Zugriffsregel für nicht unterstützte Kommandos
Die Zugriffsregel für nicht unterstüzte Kommandos KANN bei betroffenen Objekten entfernt werden
[<=]5.2.1 PIN.SMC
TIP1-A_7032 - Zugriffregel PIN.SMC
Die Zugriffregel für die PIN.SMC MUSS für die Kommandos VERIFY, CHANGE REFERENCE DATA und RESET RETRY COUNTER wie folgt geändert werden:
SmMac(flagTI.54) AND SmCmdEnc (Remote-Pin_Sender)
Hintergrund: Da das HSM-B weder über Display noch Tastatur verfügt, darf ein Zugriff auf die PIN.SMC nur über das Remote-Pin Verfahren erfolgen.
TIP1-A_6256 - Speicherung das Passwortobjekt „PIN.SMC“
Das HSM-B MUSS sicherstellen, dass jeder vSMC-B jeweils eine exklusive Instanz des Passwortobjekts
PIN.SMC
durchgehend zur Verfügung steht.
[<=]TIP1-A_6257 - Zuordnung des Passwortobjekts zu vSMC-Bs
Das HSM-B MUSS sicherstellen, dass ein Passwortobjekt genau nur einer vSMC-B zugeordnet wird.
[<=]TIP1-A_6258 - Freischaltung der vSMC-B nur mit eigener PIN
Das HSM-B MUSS sicherstellen, dass mit einer PIN, die gemäß [TIP1-A_6256] einer vSMC-B exklusiv zugeordnet ist, nur diese vSMC-B freigeschaltet werden kann.
[<=]5.2.2 CV-Zertifikate der vSMC-Bs (normativ)
Die Hinterlegung eines öffentlichen CV-Schlüsselobjektes erfolgt stets in Form eines CV-Zertifikates [gemSpec_PKI#6]. Eine Ausnahme dafür ist das öffentliche Schlüsselobjekt der CVC-Root-CA. Das öffentliche Schlüsselobjekt der CVC-Root-CA wird direkt als öffentliches CV-Schlüsselobjekt hinterlegt [gemSpec_PKI#6.1]
TIP1-A_6217 - Verfügbarkeit der öffentlichen Schlüssel der CVC-Root-CA im HSM-B
Das HSM-B MUSS sicherstellen, dass das öffentlichen Schlüsselobjekt
PuK_RCA_CS_E256
der CVC-Root-CA jeder vSMC-B durchgehend zur Verfügung stehen.
[<=]TIP1-A_6218 - Gemeinsame Nutzung der öffentlichen CVC-Root-CA-Schlüssel
Das HSM-B KANN die öffentlichen Schlüsselobjekte der CVC-Root-CA aus [TIP1-A_6217] so zur Verfügung stellen, dass diese durch alle vSMC-Bs gemeinsam genutzt werden können.
[<=]TIP1-A_6219 - Verfügbarkeit der CV-Zertifikate im HSM-B
Das HSM-B MUSS sicherstellen, dass jeder vSMC-B jeweils die CV-Zertifikate
C.CA_SMC.CS.R2048
C.CA_SMC.CS.E256
C.SMC.AUTR_CVC.R2048
C.SMC.AUTR_CVC.E256
C.SMC.AUTD_RPE_CVC.E256.
durchgehend zur Verfügung stehen.
[<=]TIP1-A_6220 - CV-Zertifikate, die exklusiv zu einer vSMC-B gehören
Das HSM-B MUSS die CV-Zertifikate
C.SMC.AUTR_CVC.R2048
C.SMC.AUTR_CVC.E256
C.SMC.AUTD_RPE_CVC.E256
so zur Verfügung stellen, dass diese CV-Zertifikate nur durch die zugehörige vSMC-B genutzt werden können.
[<=]TIP1-A_6221 - Gemeinsame Nutzung der CV-Zertifikate der CVC-SMC-CA
Das HSM-B KANN die CV-Zertifikate
C.CA_SMC.CS.R2048
C.CA_SMC.CS.E256
so zur Verfügung stellen, dass diese CV-Zertifikate durch alle vSMC-B gemeinsam genutzt werden können.
[<=]TIP1-A_6222 - Verfügbarkeit der privaten CV-Schlüsselobjekte
Das HSM-B MUSS sicherstellen, dass jeder vSMC-B jeweils eine exklusive Instanz der privaten CV-Schlüsselobjekte
PrK.SMC.AUTR_CVC.R2048
PrK.SMC.AUTR_CVC.E256
PrK.SMC.AUTD_RPE_CVC.E256.
durchgehend zur Verfügung steht.
[<=]TIP1-A_6223 - CV-Schlüsselobjekte, die exklusiv zu einer vSMC-B gehören
Das HSM-B MUSS die Schlüsselobjekte aus [TIP1-A_6222] so zur Verfügung stellen, dass diese nur durch die zugehörige vSMC-B genutzt werden können.
[<=]5.2.3 Objekte der ESIGN-Anwendung der vSMC-Bs (normativ)
TIP1-A_6229 - Verfügbarkeit der X.509-Zertifikate der ESIGN-Anwendung
Das HSM-B MUSS sicherstellen, dass jeder vSMC-B jeweils eine exklusive Instanz der folgenden X.509-Zertifikate der ESIGN-Anwendung
C.HCI.OSIG.R2048
C.HCI.AUT.R2048
C.HCI.ENC.R2048
durchgehend zur Verfügung steht.
[<=]TIP1-A_6230 - X.509-Zertifikate der ESIGN-Anwendung, die exklusiv zu einer vSMC-B gehören
Das HSM-B MUSS die X.509-Zertifikate aus [TIP1-A_6229] so zur Verfügung stellen, dass diese X.509-Zertifikate nur durch die zugeordnete vSMC-B genutzt werden können.
[<=]TIP1-A_6231 - Verfügbarkeit der privaten X.509-Schlüsselobjekte der ESIGN-Anwendung
Das HSM-B MUSS sicherstellen, dass jeder vSMC-B jeweils eine exklusive Instanz der folgenden privaten X.509-Schlüsselobjekte der ESIGN-Anwendung
PrK.HCI.OSIG.R2048
PrK.HCI.AUT.R2048
PrK.HCI.ENC.R2048
durchgehend zur Verfügung steht.
[<=]TIP1-A_6232 - X.509-Schlüsselobjekte, die exklusiv zu einer vSMC-B gehören
Das HSM-B MUSS die privaten X.509-Schlüsselobjekte aus [TIP1-A_6231] so zur Verfügung stellen, dass diese X.509-Zertifikate nur durch die zugeordnete vSMC-B genutzt werden können.
[<=]
6 HSM-B Management
Die Komponente „HSM-B Management“ implementiert die Schnittstelle
- I_HSM_Management [TIP1-A_6148]
(siehe [3.1.2] und Abb_HSM-B_002).
Das HSM-B wird über diese Schnittstelle konfiguriert und verwaltet werden. Daher muss die Managementschnittstelle „I_HSM-Management“ den dazu berechtigten Personen
- Verwaltung [0]
- Personalisierung [0]
- Fehleranalyse [0]
- Firmware Update [0]
- Rückgabe der Selbstauskunft [0]
des HSM-B ermöglichen.
Die logischen Operationen, die durch die Managementschnittstelle bereitgestellt sind, müssen vor unberechtigtem Zugriff geschützt werden. Der Zugriff darf nur Authorized-Personal und entsprechend der in [TIP1-A_6355] vorgesehenen Rollen und in [TIP1-A_6357] vorgegebenen Berechtigungen geregelt werden.
TIP1-A_6293 - Managementschnittstelle gemäß [SICCT]
Die Schnittstelle „I_HSM-Management“ des HSM-B MUSS die logischen Operationen implementieren, die den gemäß [TIP1-A_6357] dazu berechtigten Personen mindestens Ausführung der obligatorischen web-basierten Managementaktionen gemäß [SICCT#Tabelle 15 (2)] ermöglichen.
[<=]6.1 Verwaltung (normativ)
Die Schnittstelle „I_HSM_Management“ des HSM-B muss die logischen Operationen implementieren, die
- Verwaltung von virtuellen Kartenterminals [6.1.1]
- Verwaltung von virtuellen SMC-Bs [6.1.2]
ermöglichen.
6.1.1 Verwaltung von virtuellen Kartenterminals (normativ)
Zusätzlich zur obligatorischen Managementaktionen gemäß [TIP1-A_6293] gehören zur Verwaltung von virtuellen Kartenterminals die folgenden Aktionen:
- Erstellen und Löschen von vKTs
- Aktivieren und Deaktivieren von vKTs.
Deaktivierung eines vKT wird vor Änderung der Einstellungen des vKT oder HSM-B, die die vorhandenen Komandointerpreterverbindungen beeinflussen, notwendig sein. Beispiele solcher Einstellungsänderungen sind [SICCT]:
- Ändern der IP Adresse des HSM-B
- Ändern des Hostnamens der virtuellen Kartenterminals
- Ändern des SICCT Kommandointerpreter Ports der virtuellen Kartenterminals
Aktivierung eines vKT wird notwendig sein, um beispielweise ein deaktiviertes vKT wieder in Betrieb zu setzen.
TIP1-A_6294 - Logische Operationen zur Verwaltung von vKTs
Zusätzlich zur Implementierung von obligatorischen Operationen gemäß [TIP1-A_6293], MUSS die Schnittstelle „I_HSM-Management“ des HSM-B die logischen Operationen implementieren, die den gemäß [TIP1-A_6357] dazu berechtigten Personen das
-
Erstellen von vKTs
Löschen von vKTs
Aktivieren von vKTs
Deaktivieren von vKTs
Initiale Pairing von vKTs
Auslesen von Fingerprints der TLS-Zertifikate der vKTs
Verwaltung von Pairing-Informationen der vKTs
ermöglichen.
[<=]TIP1-A_6295 - ICCSN-Eingabe während der Erstellung von vKTs
Wird ein vKT Objekt durch die gemäß [TIP1-A_6294] bereitgestellten logischen Operation erstellt, MUSS die ICCSN des vKT während der Erstellung dieses vKT durch die gemäß [TIP1-A_6357] dazu berechtigte Person eingegeben werden.
[<=]TIP1-A_6296 - Aktivieren von vKTs
Wird ein vKT Objekt durch die gemäß [TIP1-A_6294] bereitgestellten logischen Operation aktiviert, MUSS das HSM-B sicherstellen, dass das vKT bereit ist für Verbindungsversuche [TIP1-A_6191].
[<=]TIP1-A_6297 - Deaktivieren von vKTs
Wird ein vKT Objekt durch die gemäß [TIP1-A_6294] bereitgestellten logischen Operation deaktiviert, MUSS das HSM-B sicherstellen, dass
das Ereignis SIGN_OFF_REQUIRED ausgelöst wird, damit, falls vorhanden, alle aktiven Verbindungen auf diesem vKT gemäß [TIP1-A_6196] abgebaut werden,
das deaktivierte vKT keine Verbindungsaufbauversuche mehr akzeptiert.
TIP1-A_6298 - Benennen von FUs der vKTs
Der logische Name einer FU eines vKT Objektes KANN durch die gemäß [TIP1-A_6355] bereitgestellten logischen Operation geändert werden.
[<=]TIP1-A_6299 - Initiales Pairing von vKTs
Die gemäß [TIP1-A_6294] bereitgestellten logischen Operation, die das initiale Pairing von vKTs ermöglicht, MUSS der gemäß [TIP1-A_6357] dazu berechtigten Person mindestens
das Setzen der Bestätigungsanforderung des vKT, das gepairt wird
ermöglichen.
[<=]TIP1-A_6300 - Auslesen des Fingerprints der TLS-Zertifikate der vKTs
Die gemäß [TIP1-A_6294] bereitgestellten logischen Operation, die das Auslesen des Fingerprints der TLS-Zertifikate von vKTs ermöglicht, MUSS der gemäß [TIP1-A_6357] dazu berechtigten Person mindestens
das Auslesen vom SHA-256-Hash-Wert des X.509-Zertifikats C.SMKT.AUT.R2048 des vKTs, das gepairt wird, ermöglichen.
Die Berechnung des SHA-256-Hash-Wertes MUSS gemäß [gemSpec_COS#N001.300)] implementiert werden.
[<=]TIP1-A_6301 - Löschen von Pairing-Informationen der vKTs
Die gemäß [TIP1-A_6294] bereitgestellten logischen Operation, die Verwaltung von Pairing-Information der vKTs ermöglichen, MUSS der gemäß [TIP1-A_6357] dazu berechtigten Person mindestens das Löschen von
einzelnen öffentlichen Schlüsseln der Konnektoren
ganzen Pairing-Blöcken
ermöglichen.
[<=]TIP1-A_7014 - Löschen eines vKT
Wird ein vKT durch die gemäß [TIP1-A_6294] bereitgestellten logischen Operation gelöscht, MUSS das HSM-B sicherstellen, dass
das vKT nicht mehr aktiviert werden kann
alle Schlüssel des vKT nicht mehr verwendet werden können
alle Pairing Daten gelöscht werden
alle gesteckten vSMC-B entfernt werden
6.1.2 Verwaltung von virtuellen SMC-Bs (normativ)
Zur Verwaltung von virtuellen SMC-Bs gehören zumindest
- Erstellen, Löschen von vSMC-Bs
- Aktivieren und Deaktivieren von vSMC-Bs.
Aktivieren einer vSMC-B simuliert das (virtuelle) Einstecken dieser vSMC-B in einen Kartenterminal-Slot. Deaktivieren einer vSMC-B simuliert das (virtuelle) Entfernen dieser vSMC-B aus einem Kartenterminal-Slot. In dieser Spezifikation werden die Bezeichnungen „virtuelles Einstecken“ und „virtuelles Entfernen“ verwendet, um möglichst mit der Standard-Terminologie konform zu bleiben.
TIP1-A_6302 - Logische Operationen zur Verwaltung von vSMC-Bs
Die Schnittstelle „I_HSM-Management“ des HSM-B MUSS die logischen Operationen implementieren, die den gemäß [TIP1-A_6357] dazu berechtigten Personen mindestens
-
Erstellen von vSMC-Bs
Löschen von vSMC-Bs
virtuelles Einstecken von vSMC-Bs
virtuelles Entfernen von vSMC-Bs
ermöglicht.
[<=]TIP1-A_6303 - ICCSN-Eingabe während der Erstellung von vSMC-Bs
Wird ein vSMC-B Objekt durch die gemäß [TIP1-A_6302] bereitgestellten logischen Operation erstellt, MUSS der Wert der ICCSN der vSMC-B während der Erstellung dieser vSMC-B durch die gemäß [TIP1-A_6357] dazu berechtigte Person eingegeben werden.
[<=]TIP1-A_6308 - Zuordnung von vSMC-Bs zu vKTs
Die gemäß [TIP1-A_6302] bereitgestellte logische Operation, die virtuelles Einstecken von vSMC-Bs ermöglicht, MUSS das Einstecken einer vSMC-B in einen freien SLOT eines beliebigen vKTs erlauben.
[<=]TIP1-A_6309 - Einstecken einer vSMC-B
Wird eine vSMC-B durch die gemäß [TIP1-A_6308] bereitgestellten logischen Operation in den SLOT eines vKT eingesteckt, MUSS das HSM-B sicherstellen, dass
der Client (Konnektor), der mit dem vKT verbunden ist, gemäß [TIP1-A_6195] benachrichtigt wird.
TIP1-A_6310 - Entfernen einer vSMC-B
Wird eine vSMC-B durch die gemäß [TIP1-A_6302] bereitgestellten logischen Operation aus dem SLOT eines vKT entfernt, MUSS das HSM-B sicherstellen, dass
der Client (Konnektor), der mit dem vKT verbunden ist, gemäß [TIP1-A_6196] benachrichtigt wird.
TIP1-A_7015 - Löschen einer vSMC-B
Wird eine vSMC-B durch die gemäß [TIP1-A_6302] bereitgestellten logischen Operation gelöscht, MUSS das HSM-B sicherstellen, dass
die vSMC-B nicht mehr aktiviert werden kann
alle Schlüssel der vSMC-B nicht mehr verwendet werden können
Hinweis: Falls die vSMC-B noch in einem vKT gesteckt ist, muss vor dem Löschen die vSMC-B ausgeworfen werden. Dies kann automatisch geschehen oder die Operation kann abgelehnt werden, solange die vSMC-B gesteckt ist.
6.2 Personalisierung (normativ)
Die Schnittstelle „I_HSM-Management“ des HSM-B muss die logischen Operationen implementieren, die
- Verwaltung von Zertifikaten [6.1.3]
- Verwaltung von kryptographischen Schlüsseln [6.1.4]
ermöglichen.
6.2.1 Verwaltung von Zertifikaten (normativ)
Bei dem Prozess für die Personalisierung des HSM-B müssen Hersteller des HSM-B, berechtigter Zertifikatsantragsteller und Trust Service Provider (TSP) zusammenarbeiten. Der Hersteller des HSM-B in einem Betriebshandbuch die Prozesse bzw. Schnittstellen beschreiben und ggf. bereitstellen, welche für die Beantragung der Zertifikate des HSM-B durch den Betreiber etabliert bzw. integriert werden müssen.
TIP1-A_6311 - Beschreibung/Bereitstellung der Prozesse bzw. Schnittstellen für Beantragung von Zertifikaten für HSM-B
Der Hersteller des HSM-B MUSS in einem Betriebshandbuch die Prozesse bzw. Schnittstellen beschreiben und ggf. bereitstellen, welche für die Beantragung von Zertifikaten der vKTs und vSMC-Bs durch den Betreiber des HSM-B etabliert bzw. integriert werden müssen.
[<=]TIP1-A_6312 - Schnittstellenspezifikation konform zu Vorgaben der TI
Der Hersteller des HSM-B MUSS sicherstellen, dass die gemäß [TIP1-A_6311] beschriebenen Prozesse und Schnittstellen zu den Schnittstellen und Prozessen der gematik zugelassenen Trust Service Providers (TSPs) konform sind, die zur Erstellung von Zertifikaten für vKTs und vSMC-Bs des HSM-B vorgesehen sind.
[<=]Die CV- und X.509-Zertifikate, die jeder vSMC-B zur Verfügung stehen müssen, sind in den Anforderungen [TIP1-A_6219] und [TIP1-A_6229] gelistet. Die X.509-Zertifikate, die jedem vKT zur Verfügung stehen müssen, sind in der Anforderung [TIP1-A_6181] gelistet.
Die CV-Zertifikate C.CA_SMC.CS.R2048 und C.CA_SMC.CS.E256 enthalten öffentliche Schlüsselobjekte der CVC-SMC-CA, die für die Prüfung der EE-CV-Zertifikate der vSMC-Bs im Rahmen von C2C-Authentisierung notwendig sind. Diese CV-Sub-CA-Zertifikate müssen während der Personalisierung des HSM-B über die „I_HSM-Management“ bereitgestellte Schnittstelle durch die gemäß [TIP1-A_6357] dazu berechtigten Personen ins HSM-B importiert werden.
Die EE-CV-Zertifikate C.SMC.AUTR_CVC.R2048 C.SMC.AUTR_CVC.E256 und C.SMC.AUTD_RPE_CVC.E256 enthalten die vSMC-B spezifischen öffentlichen Schlüsselobjekte. Diese vSMC-B spezifischen öffentlichen Schlüsselobjekte zusammen mit zugehörigen privaten Teilen müssen im HSM-B als Schlüsselpaar generiert werden (siehe [6.1.4]). Die zugehörigen Zertifikate für die öffentlichen Teile dieser Schlüsselpaare müssen über die gemäß [TIP1-A_6311] definierte Schnittstelle durch den dazu berechtigten Zertifikatsantragsteller beantragt und die empfangenen Zertifikate durch die gemäß [TIP1-A_6357] dazu berechtigten Personen ins HSM-B importiert werden.
Ähnlich wie für EE-CV-Zertifikate müssen auch die vSMC-B- und vKT spezifischen öffentlichen Schlüsselobjekte für X.509 Zertifikate (siehe [TIP1-A_6229] und [TIP1-A_6182]) im HSM-B als Schlüsselpaar generiert, zugehörige Zertifikate über die gemäß [TIP1-A_6311] definierte Schnittstelle durch den dazu berechtigten Zertifikatsantragsteller beantragt und die empfangenen Zertifikate durch die dazu berechtigten Personen ins HSM-B importiert werden.
Daher muss die Schnittstelle „I_HSM-Management“ des HSM-B zur Verwaltung von Zertifikaten die logischen Operationen implementieren, die den gemäß [TIP1-A_6357] dazu berechtigten Personen zumindest das
- Importieren
von Zertifikaten der vSMC-Bs und vKTs ermöglicht.
Die logische Operation „Importieren von Zertifikaten“ ist notwendig, um die Zertifikate einer CA oder die personalisierten Zertifikate (X.509 oder CVC), die aus dem SPOC des TSP empfangen wurden, ins HSM-B laden zu können.
Die Aktualisierung von Zertifikaten ist nicht notwendig. Falls die Gültigkeit von Zertifikaten abgelaufen ist, muss eine eine neue vSMC-B bzw ein neues vKT erstellt werden.
6.2.1.1 Verwaltung von Zertifikaten der vKTs (normativ)
TIP1-A_6313 - Logische Operationen zur Verwaltung von CA-Zertifikaten der vKTs
Die Schnittstelle „I_HSM-Management“ des HSM-B MUSS die logischen Operationen implementieren, die den gemäß [TIP1-A_6357] dazu berechtigten Personen das
-
Importieren
von den in [TIP1-A_6183] gelisteten Zertifikaten ermöglicht.
[<=]TIP1-A_6314 - Logische Operationen zur Verwaltung von X.509-Zertifikaten, die exlusiv zu einem vKT gehören
Die Schnittstelle „I_HSM-Management“ des HSM-B MUSS die logischen Operationen implementieren, die den gemäß [TIP1-A_6357] dazu berechtigten Personen das
-
Importieren
von den in [TIP1-A_6182] gelisteten Zertifikaten ermöglicht.
[<=]TIP1-A_6315 - Prüfung der Korrektheit eines X.509-Zertifikatsantrags für ein vKT
Wird eins der in [TIP1-A_6182] gelisteten X.509-Zertifikate durch die gemäß [TIP1-A_6311] bereitgestellte Schnittstelle beantragt, MUSS die gemäß [TIP1-A_6357] dazu berechtigte Person die Korrektheit der im Zertifikatsantrag vorhandenen ICCSN gemäß [TIP1-A_6316] prüfen.
[<=]TIP1-A_6316 - Korrekte ICCSN eines X.509-Zertifikats, das exklusiv zu einem vKT gehört
Das Feld „commonName“ jedes der in [TIP1-A_6182] gelisteten X.509-Zertifikate MUSS den Wert der ICCSN des vKT enthalten.
[<=]Aus sicherheitstechnischer Sicht ist die Sicherstellung der Authentizität der Zertifikate notwendig, die ins HSM-B eingebracht werden. Die Authentizität der Zertifikate, die von einer CA herausgegeben sind, können mit dem öffentlichen Schlüssel dieser CA geprüft werden. Damit der öffentliche Schlüssel einer CA, welcher in der Regel in einem Zertifikat enthalten ist, den Vertrauensanker für weitere Zertifikate darstellen kann, muss seine Authentizität ebenso sichergestellt werden. Das kann man durch eine Kombination aus technischen und nicht-technische Maßnahmen sicherstellen.
TIP1-A_6317 - Prüfung der Korrektheit eines ins HSM-B zu importierenden X.509-Zertifikats eines vKTs
Wird eines der in [TIP1-A_6182] gelisteten X.509-Zertifikate durch die gemäß [TIP1-A_6314] bereitgestellte logische Operation ins HSM-B importiert, MUSS das HSM-B sicherstellen, dass
die Signatur des Zertifikates C.SMKT.AUT.R2048, von einer CA der Komponenten-PKI erstellt wurde,
der zugehörige private Schlüssel im HSM-B gemäß [TIP1-A_6318] existiert
TIP1-A_6318 - Prüfung des zugehörigen privaten Schlüssels zu einem importierenden Zertifikat eines vKTs
Das HSM-B MUSS sicherstellen, dass zu jedem importierten
X.509-Zertifikat, das in [TIP1-A_6182] gelistet ist, ein zugehöriger privater Schlüssel
bereits im HSM-B existiert.
[<=]TIP1-A_6319 - Bereitstellung der importieren X.509-Zertifikate eines vKTs
Ist eines der in [TIP1-A_6181] gelisteten X.509-Zertifikate durch die gemäß [TIP1-A_6313] oder [TIP1-A_6314] bereitgestellte logische Operation ins HSM-B gemäß [TIP1-A_6317] erfolgreich importiert worden, MUSS das HSM-B sicherstellen, dass
die X.509-CA-Zertifikate der Komponenten-PKI in die Liste vCT_CA_CERT_LIST
das X.509-Zertifikat C.SMKT.AUT.R2048 in vCT_TLS_CERT
des vKTs eingefügt wird.
[<=]6.2.1.2 Verwaltung von Zertifikaten der vSMC-Bs (normativ)
TIP1-A_6320 - Logische Operationen zur Verwaltung von CVC-SMC-CA Zertifikaten der vSMC-Bs
Die Schnittstelle „I_HSM-Management“ des HSM-B MUSS die logischen Operationen implementieren, die den gemäß [TIP1-A_6357] dazu berechtigten Personen das
Importieren
von den in [TIP1-A_6221] gelisteten Zertifikaten ermöglicht.
[<=]TIP1-A_6321 - Logische Operationen zur Verwaltung von CV- und X.509-Zertifikaten, die exklusiv zu einer vSMC-B gehören
Die Schnittstelle „I_HSM-Management“ des HSM-B MUSS die logischen Operationen implementieren, die den gemäß [TIP1-A_6357] dazu berechtigten Personen das
Importieren
von den in [TIP1-A_6220] und [TIP1-A_6229] gelisteten Zertifikaten ermöglicht.
[<=]TIP1-A_6322 - Schnittstellenimplementierung konform zu Vorgaben der TSPs
Die Schnittstelle „I_HSM-Management“ des HSM-B MUSS die logischen Operationen aus [TIP1-A_6320], [TIP1-A_6313], [TIP1-A_6321] und [TIP1-A_6314] so implementieren, dass die Formate der Export- bzw. Importdaten mit den Schnittstellen der gematik zugelassenen Trust Service Providers (TSPs) konform sind.
[<=]TIP1-A_6323 - Prüfung der Korrektheit eines CV-Zertifikatsantrags für eine vSMC-B
Wird ein der in [TIP1-A_6220] gelisteten CV-Zertifikate durch die gemäß [TIP1-A_6311] bereitgestellte Schnittstelle beantragt, MUSS die gemäß [TIP1-A_6357] dazu berechtigte Person die Korrektheit
der im Zertifikatsantrag vorhandenen ICCSN gemäß [TIP1-A_6324],
des im Zertifikatsantrag vorhandenen Zugriffsprofils für eine
Rollenauthentisierung gemäß [GS-A_4621],
Gerätauthentisierung gemäß [GS-A_4624],
der Telematik-ID gemäß [GS-A_4587] und [GS-A_4710] und [GS-A_4711],
des Typs der Organisation/Einrichtung des Gesundheitswesens für SMC-B gemäß [GS-A_4585],
prüfen.
[<=]TIP1-A_6324 - Korrekte ICCSN eines CV-Zertifikats, das exlusiv zu einer vSMC-B gehört
Die CHR jedes der in [TIP1-A_6220] gelisteten CV-Zertifikate MUSS den Wert der ICCSN der vSMCB als ICCSN enthalten.
[<=]TIP1-A_6325 - Prüfung der Korrektheit eines ins HSM-B zu importierenden CV-Zertifikats einer vSMC-B
Wird eines der in [TIP1-A_6219] gelisteten CV-Zertifikate durch die gemäß [TIP1-A_6320] oder [TIP1-A_6321] bereitgestellte logische Operation ins HSM-B importiert, MUSS das HSM-B sicherstellen, dass
die mathematische Korrektheit
des CV-Zertifikates der Generation 1 gemäß [GS-A_4668],
des CV-Zertifikates der Generation 2 gemäß [GS-A_5009]
die Gültigkeit
des CV-Zertifikates der Generation 2 gemäß [GS-A_5012]
die Existenz des zugehörigen privaten Schlüssels im HSM-B gemäß [TIP1-A_6327]
im HSM-B geprüft wird.
[<=]TIP1-A_6326 - Prüfung der Korrektheit eines ins HSM-B zu importierenden X.509-Zertifikats einer vSMC-B
Wird eines der in [TIP1-A_6229] gelisteten X.509-Zertifikate durch die gemäß [TIP1-A_6321] bereitgestellte logische Operation ins HSM-B importiert, MUSS das HSM-B sicherstellen, dass
die Existenz des zugehörigen privaten Schlüssels im HSM-B gemäß [TIP1-A_6327]
im HSM-B geprüft wird.
[<=]TIP1-A_6327 - Prüfung des zugehörigen privaten Schlüssels zu einem importierenden Zertifikat einer vSMC-B
Das HSM-B MUSS sicherstellen, dass zu jedem importierten
CV-Zertifikat, das in [TIP1-A_6220] gelistet ist, ein zugehöriger privater Schlüsse,
X.509-Zertifikat, das in [TIP1-A_6229] gelistet ist, ein zugehöriger privater Schlüssel
bereits im HSM-B existiert.
[<=]TIP1-A_6328 - Bereitstellung der importierten CV-Zertifikate einer vSMC-B
Ist eines der in [TIP1-A_6219] gelisteten CV-Zertifikate durch die gemäß [TIP1-A_6320] oder [TIP1-A_6321] bereitgestellte logische Operation ins HSM-B gemäß [TIP1-A_6325] erfolgreich importiert worden, MUSS das HSM-B sicherstellen, dass das importierte CV-Zertifikat der vSMC-B für weitere Operationen zur Verfügung steht
[<=]TIP1-A_6329 - Bereitstellung der importieren X.509-Zertifikate einer vSMC-B
Ist eines der in [TIP1-A_6229] gelisteten X.509-Zertifikate durch die gemäß [TIP1-A_6321] bereitgestellte logische Operation erfolgreich ins HSM-B gemäß [TIP1-A_6326] importiert worden, MUSS das HSM-B sicherstellen, dass dieses Zertifikat der vSMC-B zur Verfügung steht.
[<=]TIP1-A_6330 - Sichere Aufbewahrung der importierten Zertifikate der vSMC-Bs und vKTs
Das HSM-B MUSS die Authentizität und die Integrität
der importierten X.509- und CV-Zertifikate
der zugehörigen öffentlichen Schlüssel
falls vorhanden, der zugehörigen privaten Schlüssel und deren Vertraulichkeit
im dafür vorgesehenen Speichermedium des HSM-B zu jedem Zeitpunkt sicherstellen.
[<=]6.2.2 Verwaltung von kryptographischen Schlüsseln (normativ)
Das HSM-B muss sowohl öffentliche Schlüsselobjekte als auch private Schlüsselobjekte zur Verfügung stellen.
Der öffentliche Schlüssel der CVC-Root-CA entsprechend [TIP1-A_6217] ist gemäß gemSpec_SMC-B_ObjSys nicht personalisierbar und bereits in der HSM-B Firmware enthalten.
Die CV-Zertifikate der CVC-SMC-CA, die in [TIP1-A_6221] gelistet sind, und das X.509-CA-Zertifikat, welches in der Anforderung [TIP1-A_6183] gelistet ist, müssen während der Personalisierung der vSMC-Bs oder vKTs über die „I_HSM-Management“ bereitgestellten Schnittstellen ins HSM-B importiert werden.
Davor müssen die Schlüsselpaare der vSMC-Bs oder vKTs während der Personalisierung über die „I_HSM-Management“ breitgestellte Schnittstelle erzeugt werden. Der öffentliche Teil dieser Schlüsselpaare muss jeweils aus dem HSM-B exportiert und über die gemäß [TIP1-A_6311] bereitgestellte Schnittstelle das zugehörige Zertifikat beantragt werden.
Daher muss die Schnittstelle „I_HSM-Management“ des HSM-B zur Verwaltung von Schlüsseln die logischen Operationen implementieren, die den gemäß [TIP1-A_6357] dazu berechtigten Personen zumindest ermöglichen,
- Schlüsselpaare zu generieren
- öffentliche Schlüsselobjekte zu exportieren
- öffentliche Schlüsselobjekte zu importieren
- öffentliche Schlüsselobjekte zu aktualisieren.
Die logische Operation „Importieren von öffentlichen Schlüsselobjekten“ ist notwendig, um die öffentlichen CV-Schlüsselobjekte der Root CA Link Zertifikate ins HSM-B zu laden.
Die logische Operation „Exportieren von öffentlichen Schlüsselobjekten“ ist notwendig, um den öffentlichen Teil der im HSM-B erzeugten Schlüsselpaare aus dem HSM-B zum Beantragen von zugehörigen Zertifikaten (X.509 und CVC) gemäß [TIP1-A_6311] zu exportieren.
Aktualisieren von Schlüsselobjekten ist notwendig, um die Schlüsselobjekte, beispielweise wenn deren Gültigkeitsdatum abgelaufen ist, zu erneuern.
TIP1-A_6331 - Logische Operationen zur Verwaltung von öffentlichen CVC-Root-CA Schlüsseln
Die Schnittstelle „I_HSM-Management“ des HSM-B MUSS die logischen Operationen implementieren, die den gemäß [TIP1-A_6357] dazu berechtigten Personen das
-
Importieren
Aktualisieren
von den in [TIP1-A_6217] gelisteten öffentlichen CVC-Root-CA Schlüsseln ermöglicht.
[<=]TIP1-A_6332 - Importieren von öffentlichen CVC-Root-CA Schlüsseln
Wird ein öffentlicher CVC-Root-CA Schlüssel durch die gemäß [TIP1-A_6331] bereitgestellten logischen Operation ins HSM-B erfolgreich importiert, MUSS das HSM-B sicherstellen, dass dieser Schlüssel der vSMC-B zur Verfügung steht.
[<=]TIP1-A_6333 - Generieren von Schlüsseln
Die Schnittstelle „I_HSM-Management“ des HSM-B MUSS die logischen Operationen implementieren, die den gemäß [TIP1-A_6357] dazu berechtigten Personen das Erzeugen von
RSA Schlüsseln,
ELC Schlüsseln,
gemäß [GS-A_4368] und [GS-A_5021] im HSM-B ermöglicht.
[<=]TIP1-A_6334 - Schlüsselerzeugung mit einem BSI-konformen Zufallszahlengenerator
Das HSM-B MUSS die Zufallszahlen, die bei der
Generierung der Schlüsselpaare
Durchführung kryptographischer Operationen
benötigt werden, nur durch einen eigenen Zufallszahlengenerator, der gemäß BSI-konform ist, und nur im HSM-B erzeugen.
[<=]TIP1-A_6335 - Exportieren von öffentlichen Schlüsselobjekten
Die Schnittstelle „I_HSM-Management“ des HSM-B MUSS die logischen Operationen implementieren, die der gemäß [TIP1-A_6357] dazu berechtigten Person das Exportieren von öffentlichen Schlüsselobjekten ermöglichen, die zum Beantragen von zugehörigen Zertifikaten durch die Schnittstelle gemäß [TIP1-A_6322] benötigt werden.
[<=]TIP1-A_6336 - Exportieren von privaten Schlüsselobjekten
Die Schnittstelle „I_HSM-Management“ des HSM-B DARF die logischen Operationen zur Schlüsselverwaltung NICHT implementieren, die das Exportieren von privaten Schlüsselobjekten im Klartext aus dem HSM-B ermöglichen.
[<=]TIP1-A_6337 - Zuordnung des privaten Schlüssels zu Identitäten im HSM-B
Das HSM-B MUSS sicherstellen, dass ein privater Schlüssel genau nur eine Identität zugeordnet wird.
[<=]TIP1-A_6338 - Verwendung eines Backup-HSM-B
Der Hersteller des HSM-B MUSS den Betreiber in der Dokumentation darauf hinweisen, dass ein Backup-HSM vorgehalten werden muss.
[<=]TIP1-A_6339 - Sicherer Schlüsseltransport auf ein Backup-HSM-B
Der Anbieter des HSM-B MUSS zur Übertragung von Schlüsselmaterial auf ein Backup-HSM-B (siehe [TIP1-A_6338]) sicherstellen, dass die
Integrität
Authentizität
des übertragenen Schlüssels zu jedem Zeitpunkt gewährleistet wird.
Ist der zu übertragenden Schlüssel ein privater Schlüssel, MUSS der Anbieter zusätzlich zu den oben genannten Schutzzielen die
Vertraulichkeit
des übertragenen Schlüssels zu jedem Zeitpunkt sicherstellen.
[<=]6.3 Fehleranalyse (normativ)
TIP1-A_6340 - Logische Operationen zur Abfrage von Systeminformationen
Die Schnittstelle „I_HSM-Management“ des HSM-B MUSS die logischen Operationen implementieren, die der gemäß [TIP1-A_6357] dazu berechtigten Person das Abfragen von zur Fehleranalyse notwendigen Informationen ermöglichen.
[<=]TIP1-A_6341 - Systeminformationen mit Daten ohne Personenbezug
Die zur Fehleranalyse notwendigen Informationen, die gemäß [TIP1-A_6340] über die Schnittstelle „I_HSM-Management“ abfragbar sind, DÜRFEN nur solche Daten enthalten, die gemäß [gemMeth_Schutzbed] zur Datenklasse „Daten ohne Personenbezug“ zugehören.
[<=]6.4 Firmware Update (normativ)
Das HSM-B muss über eine gesicherte Update-Möglichkeit der Firmware verfügen.
TIP1-A_6342 - Sicherer Firmware-Update-Mechanismus
Die Schnittstelle „I_HSM-Management“ des HSM-B MUSS die logischen Operationen implementieren, die den gemäß [TIP1-A_6357] dazu berechtigten Personen ein sicheres Update der Firmware des HSM-B ermöglichen.
[<=]TIP1-A_6343 - Zulässige kryptographische Verfahren zur Sicherung des Firmware Updates
Das HSM-B MUSS sicherstellen, dass die
Authentizität
Integrität
des Firmware Updates mittels asymmetrischer kryptographischer Verfahren geschützt wird.
[<=]TIP1-A_6344 - Erkennung von Übertragungsfehlern und nicht authentischen Übertragungen während eines Firmware Updates
Das HSM-B MUSS im Zuge eines Firmware Updates gemäß [TIP1-A_6342] selbständig Übertragungsfehler und nicht authentische Übertragungen erkennen.
[<=]TIP1-A_6345 - Manipulationsgeschützte Speicherung des Sicherheitsattributes für die Sicherung des Firmware Updates
Das HSM-B MUSS die gemäß [TIP1-A_6344] für die authentische Übertragung und zur Erkennung von Übertragungsfehlern eines Firmware Updates notwendigen Sicherheitsattribute in einem manipulationsgeschützten Bereich des HSM-B ablegen.
[<=]TIP1-A_6346 - Verantwortlichkeit der Prüfung der neuen Firmware
Das HSM-B MUSS sicherstellen, dass die aktive Firmware, die gemäß [TIP1-A_6343] auch die notwendigen Sicherheitsattribute für die Prüfung der Integrität/Authentizität der neuen Firmware enthält MUSS, die einzuspielende Firmware prüft.
[<=]TIP1-A_6347 - Sicherstellung von Authentizität und Integrität eines neuen Firmware Updates
Das HSM-B MUSS sicherstellen, dass nur nach erfolgreicher Prüfung der Integrität und Authentizität der zu installierenden Firmware ein Einspielen möglich ist.
[<=]TIP1-A_6348 - Fehlerhafte oder nicht authentische Übertragung abweisen
Das HSM-B MUSS den Firmware-Download bei einer fehlerhaften oder nicht authentischen Übertragung abweisen.
[<=]TIP1-A_6349 - Keine Veränderung bei fehlerhafter oder nicht authentischer Übertragung
Das HSM-B DARF eine Veränderung an der aktuellen, zertifizierten und installierten Firmware-Version bei einer fehlerhaften oder nicht authentischen Übertragung einer anderen Firmware-Version NICHT vornehmen.
[<=]TIP1-A_6350 - Übernahme als aktive Firmware
Das HSM-B MUSS sicherstellen, dass eine Firmware nur dann als aktive Firmware übernommen wird, nachdem sie vollständig und korrekt in den Speicher übernommen wurde.
[<=]TIP1-A_6351 - Versionierung der Firmware
Das HSM-B MUSS für jede Firmware-Version des HSM-B über eine Versionsnummer gemäß [gemSpec_OM#2] verfügen.
[<=]TIP1-A_6352 - Erhaltung Konfigurationen nach Update
Das HSM-B MUSS nach einem Firmware-Update sämtliche Konfigurationen, vKTs, vSMC-Bserhalten.
[<=]6.4.1 Firmware-Gruppen (normativ)
Das Konzept der Firmwaregruppen wird in [gemSpec_OM] beschrieben.
6.5 Produkttypversion und Selbstauskunft (normativ)
TIP1-A_6353 - Selbstauskunft HSM-B: Produkt-Versionsstand
Die Schnittstelle „I_HSM-Management“ des HSM-B MUSS die logischen Operationen implementieren, die den gemäß [TIP1-A_6357] dazu berechtigten Personen die Rückgabe der Selbstauskunft ermöglichen, die die entsprechenden Vorgaben aus [gemSpec_OM#2.4] erfüllen.
[<=]TIP1-A_6354 - Selbstauskunft HSM-B: Firmware-Gruppen-Version
Das HSM-B MUSS im Zuge der Selbstauskunft gemäß [TIP1-A_6353] die aktuell installierte Firmware-Gruppen-Version darstellen.
[<=]
7 Prozesse
Hinweis: Die Prozesse für den Einsatz eines HSM-B sind nicht final abgestimmt. Daher sind in diesem Kapitel Änderungen zu erwarten.
7.1 ICCSN
TIP1-A_6304 - Herausgabe der ICCSN für vKTs und vSMC-Bs
Eine ICCSN, die durch
die gemäß [TIP1-A_6295] bereitgestellten logischen Operation zu einem vKT zugeordnet wird,
die gemäß [TIP1-A_6303] bereitgestellten logischen Operation zu einer vSMC-B zugeordnet wird,
MUSS durch den Hersteller des HSM-B zur Verfügung gestellt werden.
[<=]TIP1-A_6305 - Prüfung der Korrektheit der ICCSN für vKTs und vSMC-Bs
Eine ICCSN, die durch den Hersteller des HSM-B zur Verfügung gestellt wird, MUSS erst nach einer erfolgreichen Prüfung seiner Korrektheit und Authentizität durch die
gemäß [TIP1-A_6295] bereitgestellte logische Operation zu einem vKT
gemäß [TIP1-A_6303] bereitgestellte logische Operation zu einer vSMC-B
zugeordnet werden.
Der Hersteller des HSM-B MUSS zwingend in einem entsprechenden Betriebshandbuch beschreiben, wie die die Korrektheit und die Authentizität der ICCSN geprüft und diese ins HSM-B eingebracht werden muss.
[<=]TIP1-A_6306 - Eindeutige Zuordnung von ICCSNs zu vKTs und vSMC-Bs
Das HSM-B MUSS sicherstellen, dass eine ICCSN, die durch den Hersteller des HSM-B zur Verfügung gestellt wird, durch die
gemäß [TIP1-A_6295] bereitgestellte logische Operation nur zu einem einzigen vKT
gemäß [TIP1-A_6303] bereitgestellte logische Operation zu einer einzigen vSMC-B
zugeordnet wird.
[<=]TIP1-A_6307 - Sicherstellung der weltweiten Eindeutigkeit der ICCSNs für vSMC-Bs und vKTs
Der Hersteller des HSM-B MUSS sicherstellen, dass die durch ihn herausgegebenen ICCSNs weltweit eindeutig sind.
[<=]
7.2 Rollen und Berechtigungen (normativ)
Der Zugriff auf die Schnittstelle „I_HSM_Management“ muss durch eine Kombination aus physischen und/oder technischen und/oder organisatorischen Maßnahmen geregelt werden. Der Zugriff auf diese Schnittstelle darf nur berechtigtem Personal (z.B. Administrator oder Security Administrator des HSM-B) erlaubt werden. Der Nachweis des Sicherheitsniveaus, welches durch die Rollentrennung und umgesetzten Sicherheitsmaßnahmen erzielt wird, muss im Rahmen der Zertifizierung durch das BSI [BSI] evaluiert und bestätigt werden.
TIP1-A_6355 - Die Rollen, die an der Managementschnittstelle vorgesehen werden müssen
Das HSM-B MUSS an der Managementschnittstelle „I_HSM_Management“, die gemäß [TIP1-A_6148] implementiert wird, die Rollen
Security Administrator: Personalisierung und weitere sicherheitskritische administrative Aufgaben
Administrator: Verwaltung der vKTs, vSMC-Bs
vorsehen.
[<=]TIP1-A_6356 - Schutz vor unberechtigtem Zugriff auf die Managementschnittstelle
Das HSM-B DARF den Zugriff auf die Managementschnittstelle „I_HSM_Management“ NICHT einer anderen als der in [TIP1-A_6355] gelisteten Rollen erlauben.
[<=]TIP1-A_6357 - Zuordnung der Berechtigungen zu Rollen
Das HSM-B MUSS sicherstellen, dass Zuordnung der Berechtigungen für die Ausführung der durch die Managementschnittstelle bereitgestellten logischen Operationen zu Rollen gemäß Tabelle „Tab_HSM-B_097“ erfolgt.
[<=]
Logische Operation |
Rolle |
|
---|---|---|
Security Administrator |
Administrator |
|
Erstellen von vKTs [TIP1-A_6294] |
X |
|
Aktivieren von vKTs [TIP1-A_6296] |
X |
|
Deaktivieren von vKTs [TIP1-A_6297] |
X |
|
Benennen von FUs der vKTs [TIP1-A_6298] |
X |
|
Initales Pairing von vKTs [TIP1-A_6299] |
X |
|
Auslesen des Fingerprints der TLS-Zertifikate der vKTs [TIP1-A_6300] |
X |
X |
Löschen von Pairing-Informationen der vKTs [TIP1-A_6301] |
X |
|
Erstellen von vSMC-Bs [TIP1-A_6302] |
X |
|
ICCSN-Eingabe während der Erstellung von vKTs [TIP1-A_6295] |
X |
|
ICCSN-Eingabe während der Erstellung von vSMC-Bs [TIP1-A_6303] |
X |
|
Einstecken einer vSMC-B [TIP1-A_6309] |
X |
|
Entfernen einer vSMC-B [TIP1-A_6310] |
X |
|
Logische Operationen zur Verwaltung von CA-Zertifikaten der vKTs [TIP1-A_6313] |
X |
|
Logische Operationen zur Verwaltung von X.509-Zertifikaten, die exlusiv zu einem vKT gehören [TIP1-A_6314] |
X |
|
Logische Operationen zur Verwaltung von CVC-SMC-CA Zertifikaten der vSMC-Bs [TIP1-A_6320] |
X |
|
Logische Operationen zur Verwaltung von CV- und X.509-Zertifikaten, die exlusiv zu einer vSMC-B gehören [TIP1-A_6321] |
X |
|
Prüfung der Korrektheit eines CV-Zertifikatsantrags für eine vSMC-B [TIP1-A_6323] |
X |
|
Prüfung der Korrektheit eines X.509-Zertifikatsantrags für ein vKT [TIP1-A_6315] |
X |
|
Logische Operationen zur Verwaltung von öffentlichen CVC-Root-CA Schlüsseln [TIP1-A_6331] |
X |
|
Importieren von öffentlichen CVC-Root-CA Schlüsseln [TIP1-A_6332] |
X |
|
Generieren von Schlüsseln [TIP1-A_6333] |
X |
|
Exportieren von öffentlichen Schlüsselobjekten [TIP1-A_6335] |
X |
|
Logische Operationen zur Abfrage von Systeminformationen [TIP1-A_6340] |
X |
X |
Sicherer Firmware-Update-Mechanismus [TIP1-A_6342] |
X |
|
Selbstauskunft HSM-B: Produkt-Versionsstand [TIP1-A_6352] |
X |
X |
X: Besitzer der Rolle ist berechtigt, um die Logische Operation auszuführen |
8 Anhang A – Verzeichnisse
8.1 A1 – Abkürzungen
Kürzel |
Erläuterung |
---|---|
AUT |
Authentisierung (Authentication) |
BSI |
Bundesamt für Sicherheit in der Informationstechnik |
CA |
Certification Authority |
EE |
End Entity |
eGK |
Elektronische Gesundheitskarte |
ENC |
Verschlüsselung (Encryption) |
gSMC |
Gerätebezogene Security Module Card |
HBA |
Heilberufsausweis |
HCI |
Health Care Institution |
HP |
Health Professional |
HPC |
Health Professional Card |
HSM |
Hardware Security Module |
HTTP |
Hypertext Transfer Protocol |
ICCSN |
ICC Serial Number |
ID |
Identität (Identity) |
KT |
Kartenterminal |
vKT |
Virtuelles Kartenterminal |
OID |
Object Identifier |
OSIG |
Organizational Signature |
PKI |
Public Key Infrastructure |
PrK |
Private Key |
PuK |
Public Key |
RCA |
Root-CA |
RFC |
Request For Comment |
SHA |
Secure Hash Algorithm |
SIG |
Elektronische Signatur |
SM |
Security Module |
SM-B |
Adressiert sowohl eine echte SMC-B als auch eine in einem HSM-B enthaltene virtuelle SMC-B. |
SMC-B |
Sicherheitsmodul vom Typ B <medizinische Institution> |
vSMC-B |
Virtuelle SMC-B |
SMC |
Security Module Card |
gSMC-K |
Security Module Card Konnektor als <holder> |
SM-K |
Sicherheitsmodul für Konnektoren |
gSMC-KT |
Security Module Kartenterminal als <holder> |
SM-KT-Zertifikat |
X.509-Komponentenzertifikat zu einem SM-KT |
SubjectDN |
Subject Distinguished Name |
TI |
Telematikinfrastruktur |
TLS |
Transport Layer Security |
8.2 A2 – Glossar
Das Glossar wird als eigenständiges Dokument, vgl. [gemGlossar] zur Verfügung gestellt.
8.3 A3 – Abbildungsverzeichnis
8.4 A4 – Tabellenverzeichnis
8.5 A5 – Referenzierte Dokumente
8.5.1 A5.1 – Dokumente der gematik
Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert, Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument passende jeweils gültige Versionsnummer sind in der aktuellsten, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.
[Quelle] |
Herausgeber: Titel |
---|---|
[gemSpec_KT] |
gematik: Spezifikation eHealth-Kartenterminal |
[gemSpec_SMC-B_ObjSys] |
gematik: Spezifikation der Security Module Card SMC-B Objektsystem |
[gemSpec_gSMC-KT_ObjSys] |
gematik: Spezifikation der gSMC-KT Objektsystem |
[gemSpec_gSMC-K_ObjSys] |
gematik: Spezifikation der gSMC-K Objektsystem |
[gemSpec_COS] |
gematik: Spezifikation des Card Operating System (COS) |
[gemSpec_Kon] |
gematik: Spezifikation Konnektor |
[gemGlossar] |
gematik: Glossar |
[gemKPT_Arch_TIP] |
gematik: Konzept Architektur der TI-Plattform |
[gemKPT_PKI_TIP] |
gematik: Konzept PKI der TI-Plattform |
[gemRL_TSL_SP_CP] |
gematik: Certificate Policy Gemeinsame Zertifizierungsrichtlinie für Teilnehmer der gematik-TSL |
[gemSpec_CVC_TSP] |
gematik: Spezifikation Trust Service Provider CVC |
[gemSpec_Krypt] |
gematik: Verwendung kryptographischer Algorithmen in der Telematikinfrastrukur |
[gemSpec_OID] |
gematik: Spezifikation OID |
[gemSpec_Perf] |
gematik: Performance und Mengengerüst TI-Plattform |
[gemSpec_PKI] |
gematik: Spezifikation PKI |
[gemSpec_OM] |
gematik: Übergreifende Spezifikation Operations und Maintenance |
8.5.2 A5.2 – Weitere Dokumente
[Quelle] |
Herausgeber (Erscheinungsdatum): Titel |
---|---|
[SICCT] |
SICCT Secure Interoperable ChipCard Terminal, Version: 1.21 mit Errata 1.0.2 |
[HPC-CP] |
Bundesapothekerkammer, Bundesärztekammer, Bundespsychotherapeutenkammer, Bundeszahnärztekammer, Kassenzahnärztliche Bundesvereinigung Gemeinsame Policy für die Ausgabe der HPC, Zertifikatsrichtlinie HPC, Version: 1.0.0, 08.06.2009 |
[HPC002] |
Schnittstellen- und Prozessspezifikation TSP X509 und CVC HPC-TSP T-Systems, Version 0.9.1 |
[RFC2119] |
RFC 2119 (März 1997): Key words for use in RFCs to Indicate Requirement Levels S. Bradner, http://www.ietf.org/rfc/rfc2119.txt |
[RFC3927] |
Dynamic Configuration of IPv4 Link-Local Addresses, http://www.ietf.org/rfc/rfc3927.txt |
8.6 A6 – Klärungsbedarf
Kap. |
Offener Punkt |
Zuständig |
---|---|---|
9 Aus Contour importierte Anforderungen, da nicht im Dokument
TIP1-A_6161 - Prüfung der Korrektheit des zu importierenden CVC-Root-CA Schlüssels
Der Hersteller des HSM-B MUSS zwingend in einem entsprechenden Betriebshandbuch beschreiben, wie die Korrektheit und die Authentizität des CVC-Root-CA-Schlüssels durch die gemäß [TIP1-A_6357] dazu berechtigten Personen geprüft und dieser nach positiver Prüfung ins HSM-B eingebracht werden muss. [<=]
TIP1-A_6162 - Prüfung der Korrektheit des zu importierenden Zertifikats „C.SMKT.CA.R2048“
Der Hersteller des HSM-B MUSS zwingend in einem entsprechenden Betriebshandbuch beschreiben, wie die Korrektheit und die Authentizität des Zertifikates „C.SMKT.CA.R2048“ durch die gemäß [TIP1-A_6357] dazu berechtigten Personen geprüft und dieser nach positiver Prüfung ins HSM-B eingebracht werden muss. [<=]
TIP1-A_6188 - TUC_HSM-B_030 „EHEALTH TERMINAL AUTHENTICATE“
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_030 „EHEALTH TERMINAL AUTHENTICATE“ gemäß Tab_HSM-B_095 umsetzen. [<=]
TIP1-A_6190 - TUC_HSM-B_001 „Dienstbeschreibungspaket senden"
Das HSM-B KANN optional den technischen Use Case TUC_HSM-B_001 “Dienstbeschreibungspaket senden“ gemäß Tab_HSM-B_004 umsetzen. [<=]
TIP1-A_6193 - TUC_HSM-B_004 „Kommando ausführen"
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_004 “Kommando ausführen“ gemäß Tab_HSM-B_006 umsetzen. [<=]
TIP1-A_6199 - TUC_HSM-B_005 „SICCT INIT CT SESSION"
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_005 “SICCT INIT CT SESSION“ gemäß Tab_HSM-B_010 umsetzen. [<=]
TIP1-A_6201 - TUC_HSM-B_006 „SICCT CLOSE CT SESSION"
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_006 “SICCT CLOSE CT SESSION“ gemäß Tab_HSM-B_012 umsetzen. [<=]
TIP1-A_6206 - TUC_HSM-B_007 „SICCT GET STATUS"
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_007 “SICCT GET STATUS“ gemäß Tab_HSM-B_015 umsetzen. [<=]
TIP1-A_6208 - TUC_HSM-B_009 „SICCT RESET CT"
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_009 “SICCT RESET CT“ gemäß Tab_HSM-B_019 umsetzen. [<=]
TIP1-A_6210 - TUC_HSM-B_010 „SICCT REQUEST ICC"
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_010 “SICCT REQUEST ICC“ gemäß Tab_HSM-B_021 umsetzen. [<=]
TIP1-A_6211 - TUC_HSM-B_011 „SICCT EJECT ICC"
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_011 “SICCT EJECT ICC“ gemäß Tab_HSM-B_023 umsetzen. [<=]
TIP1-A_6212 - TUC_HSM-B_002 „Konnektor hinzufügen"
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_002 “Konnektor hinzufügen“ gemäß Tab_HSM-B_025 umsetzen. [<=]
TIP1-A_6214 - Zugriffsregeln für das vSMC-B Objektsystem
Das HSM-B MUSS die Zugriffsregeln für das vSMC-B Objektsystem gemäß [gemSpec_SMC-B_ObjSys] auswerten. [<=]
TIP1-A_6215 - Zugriffsregeln für die Kartenkommandos
Das HSM-B MUSS die Zugriffsregeln für die Kartenkommandos gemäß [gemSpec_SMC-B_ObjSys] auswerten. [<=]
TIP1-A_6216 - Keine Unterstützung von „Option_Kryptobox“
Das HSM-B SOLL die „Option_Kryptobox“ gemäß [gemSpec_COS] NICHT unterstützen. [<=]
TIP1-A_6224 - Speicherung der optionalen Schlüsselobjekte
Das HSM-B KANN die öffentlichen und symmetrischen Schlüsselobjekte, - PuK.ADMIN.CMS.CS.E256 - SK.CMS.AES128 - SK.CMS.AES256 - SK.CUP.AES128 - SK.CUP.AES256 die gemäß [gemSpec_SMC-B_ObjSys] optional sind, jeder vSMC-B zur Verfügung stellen. [<=]
TIP1-A_6226 - Unterstützte „PSO Verify Certificate“-Varianten
Das HSM-B MUSS die „PSO Verify Certificate“-Varianten - Import eines RSA-Schlüssels mittels Zertifikat [gemSpec_COS#14.8.7.1] - Import eines ELC-Schlüssels mittels Zertifikat [gemSpec_COS#14.8.7.2] unterstützen. Das HSM-B KANN weitere „PSO Verify Certificate“-Varianten aus der Spezifikation [gemSpec_COS#14.8.7] unterstützen. [<=]
TIP1-A_6227 - Unterstützte Kurvenparameter für CV-Zertifikate
Das HSM-B MUSS alle Kombinationen von Domainparametern gemäß [gemSpec_COS#(N095.410)] in CV-Zertifikaten unterstützen. [<=]
TIP1-A_6228 - TUC_HSM-B_013 „PSO Verify Certificate“
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_013 “PSO Verify Certificate“ gemäß Tab_HSM-B_036 umsetzen. [<=]
TIP1-A_6234 - Unterstützte „Aushandlungsschlüssel“-Varianten
Das HSM-B MUSS nur die „Aushandlungsschlüssel“-Variante - Aushandlung mittels asymmetrischer Schlüssel [gemSpec_COS#(N031.500)] unterstützen. Das HSM-B KANN weitere Sessionkey-Ableitung-Varianten aus der Spezifikation [gemSpec_COS#13.1.1] unterstützen. [<=]
TIP1-A_6236 - TUC_HSM-B_014 „Sessionkeys ableiten"
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_014 “Sessionkeys ableiten“ gemäß Tab_HSM-B_048 umsetzen. [<=]
TIP1-A_6238 - TUC_HSM-B_015 „SM-CAPDU auspacken“
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_015 “SM-CAPDU auspacken“ gemäß Tab_HSM-B_050 umsetzen. [<=]
TIP1-A_6240 - TUC_HSM-B_016 „RAPDU-per-SM sichern“
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_016 “RAPDU-per-SM sichern“ gemäß Tab_HSM-B_052 umsetzen. [<=]
TIP1-A_6242 - Unterstützte „Internal Authenticate“-Varianten
Das HSM-B MUSS die „INTERNAL AUTHENTICATE“-Variante gemäß [gemSpec_COS#14.7.4.1] unterstützen. Das HSM-B KANN weitere „INTERNAL AUTHENTICATE“-Varianten aus der Spezifikation [gemSpec_COS#14.7.4] unterstützen. [<=]
TIP1-A_6243 - TUC_HSM-B_017 „Internal Authenticate“
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_017 “Internal Authenticate“ gemäß Tab_HSM-B_055 umsetzen. [<=]
TIP1-A_6245 - Unterstützte „External Authenticate“-Varianten
Im Gegensatz zu [gemSpec_COS#(N084.000)] MUSS das HSM-B nur die „EXTERNAL AUTHENTICATE“-Variante - Externe Authentisierung ohne Antwortdaten [gemSpec_COS#14.7.1.1] unterstützen. Das HSM-B KANN weitere „EXTERNAL AUTHENTICATE“-Varianten aus der Spezifikation [gemSpec_COS#14.7.1] unterstützen. [<=]
TIP1-A_6246 - TUC_HSM-B_018 „External Authenticate“
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_018 “External Authenticate“ gemäß Tab_HSM-B_058 umsetzen. [<=]
TIP1-A_6248 - Unterstützte „Get Challenge“-Varianten
Das HSM-B MUSS die „GET CHALLENGE“-Varianten - Zufallszahl für DES oder RSA Authentisierung [gemSpec_COS#14.9.4.1] - Zufallszahl für AES oder ELC Authentisierung [gemSpec_COS#14.9.4.2] unterstützen. Das HSM-B KANN weitere „GET CHALLENGE“-Varianten aus der Spezifikation [gemSpec_COS#14.9.4] unterstützen. [<=]
TIP1-A_6249 - TUC_HSM-B_019 „Get Challenge“
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_019 “Get Challenge“ gemäß Tab_HSM-B_060 umsetzen. [<=]
TIP1-A_6251 - Unterstützte „General Authenticate“-Varianten
Im Gegensatz zu [gemSpec_COS#(N085.050)] MUSS das HSM-B nur die „GENERAL AUTHENTICATE“-Varianten - Gegenseitige Authentisierung mit Sessionkey-Aushandlung mittels ELC Schlüssel [gemSpec_COS#14.7.2.2] unterstützen. Das HSM-B KANN weitere „GENERAL AUTHENTICATE“-Varianten aus der Spezifikation [gemSpec_COS#14.7.2] unterstützen. [<=]
TIP1-A_6252 - TUC_HSM-B_020 „General Authenticate“
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_020 “General Authenticate“ gemäß Tab_HSM-B_063 umsetzen. [<=]
TIP1-A_6254 - Unterstützte „Get Security Status Key“-Varianten
Das HSM-B MUSS die „GET SECURITY STATUS KEY“-Varianten - Auslesen Sicherheitsstatus eines symmetrischen Schlüssels [gemSpec_COS#14.7.3.1] - Auslesen des Sicherheitsstatus einer Rolle [gemSpec_COS#14.7.3.2] - Auslesen des Sicherheitsstatus einer Bitliste [gemSpec_COS#14.7.3.3] unterstützen. Das HSM-B KANN weitere „GET SECURITY STATUS KEY“-Varianten aus der Spezifikation [gemSpec_COS#14.7.3] unterstützen. [<=]
TIP1-A_6255 - TUC_HSM-B_021 „Get Security Status Key“
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_021 “Get Security Status Key“ gemäß Tab_HSM-B_065 umsetzen. [<=]
TIP1-A_6259 - Die Länge der PIN/PUK der vSMC-Bs
Das HSM-B MUSS sicherstellen, dass die PIN einer vSMC-B, die gemäß [TIP1-A_6256] im Passwortobjekt dieser vSMC-B enthalten ist, entsprechend [gemSpec_SMC-B_ObjSys#Tab_SMC-B_ObjSys_020] mindestens 6 und maximum 8 Ziffern und der PUK für diese PIN genau 8 Ziffern besitzt. [<=]
TIP1-A_6260 - Remote-PIN nur mit Secure Messaging
Das HSM-B DARF die Kommandos - „VERIFY“ gemäß [gemSpec_COS#14.6.6] - „CHANGE REFERENCE DATA“ gemäß [gemSpec_COS#14.6.1] - „RESET RETRY COUNTER“ gemäß [gemSpec_COS#14.6.5.1] die im Rahmen des Remote-PIN Verfahrens erhalten werden und die nicht mit Secure Messaging gesichert sind, NICHT bearbeiten. [<=]
TIP1-A_6261 - Sperrung eine vSMC-B durch Nutzung der PUK
Das HSM-B MUSS sicherstellen, dass jede vSMC-B nach zehnmaliger Nutzung (unabhängig von richtiger oder falscher Eingabe) ihrer PUK gesperrt bleibt. [<=]
TIP1-A_6263 - Unterstützte „Verify“-Varianten
Das HSM-B MUSS die „VERIFY“-Variante - Vergleich eines Benutzergeheimnisses [gemSpec_COS#14.6.6.1] unterstützen. Das HSM-B KANN weitere „VERIFY“-Varianten aus der Spezifikation [gemSpec_COS#14.6.6] unterstützen. [<=]
TIP1-A_6264 - TUC_HSM-B_022 „Verify“
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_022 “Verify“ gemäß Tab_HSM-B_067 umsetzen. [<=]
TIP1-A_6266 - Unterstützte „Change Reference Data“-Varianten
Das HSM-B MUSS die „CHANGE REFERENCE DATA“-Varianten - Ändern eines Benutzergeheimnisses [gemSpec_COS#14.6.1.1] unterstützen. Das HSM-B KANN weitere „CHANGE REFERENCE DATA“-Varianten aus der Spezifikation [gemSpec_COS#14.6.1] unterstützen. [<=]
TIP1-A_6267 - TUC_HSM-B_023 „Change Reference Data“
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_023 “Change Reference Data“ gemäß Tab_HSM-B_069 umsetzen. [<=]
TIP1-A_6269 - Unterstützte „Reset Retry Counter“-Varianten
Das HSM-B MUSS die „RESET RETRY COUNTER“-Varianten - Entsperren mit PUK, mit neuem Geheimnis [gemSpec_COS#14.6.5.1] - Entsperren mit PUK, ohne neues Geheimnis [gemSpec_COS#14.6.5.2] unterstützen. Das HSM-B KANN weitere „RESET RETRY COUNTER“-Varianten aus der Spezifikation [gemSpec_COS#14.6.5] unterstützen. [<=]
TIP1-A_6270 - TUC_HSM-B_024 „Reset Retry Counter“
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_024 “Reset Retry Counter“ gemäß Tab_HSM-B_071 umsetzen. [<=]
TIP1-A_6272 - Unterstützte „Get PIN Status“-Varianten
Das HSM-B MUSS die „GET PIN STATUS“-Variante - Auslesen des Status eines Passwortobjektes [gemSpec_COS#14.6.4.1] unterstützen. Das HSM-B KANN weitere „GET PIN STATUS“-Varianten aus der Spezifikation [gemSpec_COS#14.6.4] unterstützen. [<=]
TIP1-A_6273 - TUC_HSM-B_025 „Get PIN Status“
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_025 “Get PIN Status“ gemäß Tab_HSM-B_073 umsetzen. [<=]
TIP1-A_6275 - Unterstützte „PSO Compute Digital Signature“-Varianten
Das HSM-B MUSS die „PSO Compute Digital Signature“-Varianten - Signieren des Datenfeldes ohne „Message Recovery“ [gemSpec_COS#14.8.2.1] unterstützen. Das HSM-B KANN weitere „PSO Compute Digital Signature“-Varianten aus der Spezifikation [gemSpec_COS#14.8.2] unterstützen. [<=]
TIP1-A_6276 - TUC_HSM-B_026 „PSO Compute Digital Signature“
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_026 “PSO Compute Digital Signature“ gemäß Tab_HSM-B_076 umsetzen. [<=]
TIP1-A_6278 - Unterstützte „PSO Decipher“-Varianten
Das HSM-B MUSS die „PSO Decipher“-Variante - Entschlüsseln mittels RSA [gemSpec_COS#14.8.3.1] unterstützen. Das HSM-B KANN weitere „PSO Decipher“-Varianten aus der Spezifikation [gemSpec_COS#14.8.3] unterstützen. [<=]
TIP1-A_6279 - TUC_HSM-B_022 „PSO Decipher“
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_079 “PSO Decipher“ gemäß Tab_HSM-B_079 umsetzen. [<=]
TIP1-A_6281 - Unterstützte „Read Binary“-Varianten
Das HSM-B MUSS die „READ BINARY“-Varianten - Lesen ohne shortFileIdentifier [gemSpec_COS#14.3.2.1] - Lesen mit shortFileIdentifier [gemSpec_COS#14.3.2.2] (optional) unterstützen. Das HSM-B KANN weitere „READ BINARY“-Varianten aus der Spezifikation [gemSpec_COS#14.3.2] unterstützen. [<=]
TIP1-A_6282 - TUC_HSM-B_028 „Read Binary“
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_028 “Read Binary“ gemäß Tab_HSM-B_081 umsetzen. [<=]
TIP1-A_6284 - Unterstützte „Manage Security Environment“-Varianten
Im Gegensatz zu [gemSpec_COS#(N014.000)] MUSS das HSM-B nur die „MANAGE SECURITY ENVIRONMENT“-Varianten - Ändern des SE-Identifiers [gemSpec_COS#14.9.9.1] - Schlüsselauswahl zur internen, asymmetrischen Authentisierung [gemSpec_COS#14.9.9.3] - Schlüsselauswahl zur externen, asymmetrischen Authentisierung [gemSpec_COS#14.9.9.5] - Schlüsselauswahl für Signierschlüssel [gemSpec_COS#14.9.9.9] - Schlüsselauswahl zum Prüfen von CV-Zertifikaten [gemSpec_COS#14.9.9.10] - Schlüsselauswahl zur Datenentschlüsselung [gemSpec_COS#14.9.9.11] unterstützen. Das HSM-B KANN weitere „MSE“-Varianten aus der Spezifikation [gemSpec_COS#14.9.9] unterstützen. [<=]
TIP1-A_6285 - Unterstützung der Schlüsselsuche
Das HSM-B KANN nach einem Schlüssel mittels SearchKey() gemäß [gemSpec_COS#(N014.300)] suchen. [<=]
TIP1-A_6286 - TUC_HSM-B_033 „Manage Security Environment“
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_033 “Manage Security Environment“ gemäß Tab_HSM-B_091 umsetzen. [<=]
TIP1-A_6288 - Unterstützte „Manage Channel“-Varianten
Das HSM-B MUSS die „MANAGE CHANNEL“-Varianten - Öffnen eines logischen Channels [gemSpec_COS#14.9.8.1] - Schließen eines logischen Channels [gemSpec_COS#14.9.8.2] - Zurücksetzen eines logischen Channels [gemSpec_COS#14.9.8.3] - Logischer Reset der Applikationsebene [gemSpec_COS#14.9.8.4] unterstützen. Das HSM-B KANN weitere „MANAGE CHANNEL“-Varianten aus der Spezifikation [gemSpec_COS#14.9.8] unterstützen. [<=]
TIP1-A_6289 - Zugriffregeln für das Kommando „Manage Channel“
Im Gegensatz zu [gemSpec_COS#(N099.545)] MUSS das HSM-B als Zugriffsbedingung für das Kommando „MANAGE CHANNEL“ ALWAYS verwenden, unabhängig vom lifeCycleStatus und unabhängig vom aktuellen Security Environment. [<=]
TIP1-A_6290 - TUC_HSM-B_034 „Manage Channel“
Das HSM-B MUSS den technischen Use Case TUC_HSM-B_034 “Manage Channel“ gemäß Tab_HSM-B_093 umsetzen. [<=]
TIP1-A_6292 - Unterstützte „Select“-Varianten
Das HSM-B MUSS alle „SELECT“-Varianten aus [gemSpec_COS#14.2.6] unterstützen. [<=]