gemSpec_Kon_V5.21.0_Aend

 

 

 

Elektronische Gesundheitskarte und Telematikinfrastruktur

 

 

 

Spezifikation

Konnektor

 

 

   

Version	5.2021.0
Revision	792991850863
Stand	05.05.202323.02.2024
Status	freigegeben
Klassifizierung	öffentlich
Referenzierung	gemSpec_Kon

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Version	Stand	Kap./ Seite	Grund der Änderung, besondere Hinweise	Bearbeitung
5.1.0	05.10.17		Initialversion Online-Produktivbetrieb (Stufe 2.1)	gematik
5.2.0	18.12.17		Einarbeitung Erratas 1.6.4-1 bis 1.6.4-3, P15.1	gematik
5.3.0	14.05.18		Einarbeitung P15.2, P15.4 und P15.5	gematik
5.4.0	26.10.18		Einarbeitung P15.8 und P15.9	gematik
5.5.0	18.12.18		Einarbeitung P17.1	gematik
5.6.0	15.05.19		Einarbeitung P18.1	gematik
5.7.0	28.06.19		Einarbeitung P19.1	gematik
5.8.0	02.10.19		Einarbeitung P20.1/2	gematik
5.9.0	02.03.20		Einarbeitung P21.1	gematik
5.9.1	26.06.20		Einarbeitung P21.3	gematik
5.9.2	27.08.20		Einarbeitung P21.4	gematik
5.9.3	21.09.20		Einarbeitung P21.5	gematik
5.9.4	05.11.20		Einarbeitung P21.6	gematik
5.10.0	30.06.20		Einarbeitung P22.1	gematik
5.11.0	12.11.20		Einarbeitung Scope-Themen zu R4.0.1	gematik
5.12.0	09.12.20		Einarbeitung P22.5	gematik
5.13.0	30.06.21		Einarbeitung Konn_Maintenance_21.1, _21.2, _21.3 und gemF_gSMC-K_Laufzeitverlängerung	gematik
5.14.0	02.09.21		Umbenennung der Begriffe "aAdG-NetG" in "WANDA Basic", "aAdG" und "aAdG-NetG-TI" in"WANDA Smart"	gematik
5.15.0	31.01.22		Einarbeitung Konn_Maintenance_21.6, Einarbeitung CI_Maintenance_21.2: Ergänzung der Tabelle 3 im Kap. 4.2.1.1.1 um "WANDA Basic"	gematik
5.16.0	02.05.22		Einarbeitung Konn_Maintenance_22.1 (mit Ausbau der Änderungen aus gemF_gSMC-K_Laufzeitverlängerung)	gematik
5.17.0	30.06.22		Einarbeitung Konn_Maintenance_22.3	gematik
5.18.0	28.11.22		Einarbeitung Konn_Maintenance_22.4, _22.5, _22.6, redaktionell: diskriminierungsfreie Sprache (Black-/Whitelist in Deny-/Allowlist)	gematik
5.19.0	14.04.23		Einarbeitung Konn_Maintenance_23.1 und gemF_gSMC-K_Laufzeitverlängerung	gematik
5.20.0	05.05.23		Einarbeitung Konn_Maintenance_23.2	gematik
5.21.0	23.02.24		Einarbeitung TI-Gateway_Maintenance_23.1	gematik

Inhaltsverzeichnis

Dokumentinformationen

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

1.2 Zielgruppe

1.3 Geltungsbereich

1.4 Abgrenzung des Dokuments

1.5 Methodik

1.5.1 Anforderungen

1.5.2 Offene Punkte

1.5.3 Erläuterungen zur Spezifikation des Außenverhaltens

1.5.4 Erläuterungen zur Dokumentenstruktur und „Dokumentenmechanismen“

1.5.4.1 Modulare Spezifikation über Funktionsmerkmale

1.5.4.2 Technische Use Cases - TUCs

1.5.4.3 Event-Mechanismus

1.5.4.4 Konfigurationsparameter und Zustandswerte

2 Systemüberblick

2.1 Logische Struktur

2.2 Sicherer Datenspeicher

2.3 Überblick Konnektoridentität

2.4 Mandantenfähigkeit

2.5 Versionierung

2.6 Fachanwendungen

2.7 Netzseitige Einsatzszenarien

2.7.1 Parameter ANLW_ANBINDUNGS_MODUS

2.7.2 Parameter ANLW_INTERNET_MODUS

2.8 Lokale und entfernte Kartenterminals

2.9 Standalone-Szenario

3 Übergreifende Festlegungen

3.1 Allgemeine übergreifende Festlegungen

3.1.1 Dokumentformate

3.1.2 Kartentypen

3.1.3 Übergreifende Festlegungen zum Aufbau von sicheren Verbindungen

3.2 Konnektoridentität und gSMC-K

3.2.1 Erneuerung der Zertifikate der gSMC-K

3.2.2 Organisatorische Anforderungen und Sperrprozesse

3.3 Bootup-Phase

3.4 Betriebszustand

3.4.1 Betriebsaspekte

3.5 Fachliche Anbindung der Clientsysteme

3.5.1 Betriebsaspekte

3.6 Clientsystemschnittstelle

3.6.1 SOAP-Schnittstelle

3.6.2 Statusrückmeldung und Fehlerbehandlung

3.6.3 Transport großer Dokumente

3.7 Verwendung manuell importierter CA-Zertifikate

3.8 Testunterstützung

4 Funktionsmerkmale

4.1 Anwendungskonnektor

4.1.1 Zugriffsberechtigungsdienst

4.1.1.1 Funktionsmerkmalweite Aspekte

4.1.1.2 Durch Ereignisse ausgelöste Reaktionen

4.1.1.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.1.1.4 Interne TUCs, auch durch Fachmodule nutzbar

4.1.1.4.1 TUC_KON_000 „Prüfe Zugriffsberechtigung“

4.1.1.5 Operationen an der Außenschnittstelle

4.1.1.6 Betriebsaspekte

4.1.2 Dokumentvalidierungsdienst

4.1.2.1 Funktionsmerkmalweite Aspekte

4.1.2.2 Durch Ereignisse ausgelöste Reaktionen

4.1.2.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.1.2.4 Interne TUCs, auch durch Fachmodule nutzbar

4.1.2.4.1 TUC_KON_080 „Dokument validieren”

4.1.2.5 Operationen an der Außenschnittstelle

4.1.2.6 Betriebsaspekte

4.1.3 Dienstverzeichnisdienst

4.1.3.1 Funktionsmerkmalweite Aspekte

4.1.3.2 Durch Ereignisse ausgelöste Reaktionen

4.1.3.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.1.3.4 Interne TUCs, auch durch Fachmodule nutzbar

4.1.3.4.1 TUC_KON_041 „Einbringen der Endpunktinformationen während der Bootup-Phase“

4.1.3.5 Operationen an der Außenschnittstelle

4.1.3.6 Betriebsaspekte

4.1.4 Kartenterminaldienst

4.1.4.1 Funktionsmerkmalweite Aspekte

4.1.4.2 Durch Ereignisse ausgelöste Reaktionen

4.1.4.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.1.4.3.1 TUC_KON_050 „Beginne Kartenterminalsitzung“

4.1.4.3.2 TUC_KON_054 „Kartenterminal hinzufügen“

4.1.4.3.3 TUC_KON_053 „Paire Kartenterminal“

4.1.4.3.4 TUC_KON_055 „Befülle CT-Object“

4.1.4.4 Interne TUCs, auch durch Fachmodule nutzbar

4.1.4.4.1 TUC_KON_051 „Mit Anwender über Kartenterminal interagieren“

4.1.4.4.2 TUC_KON_056 „Karte anfordern“

4.1.4.4.3 TUC_KON_057 „Karte auswerfen“

4.1.4.4.4 TUC_KON_058 „Displaygröße ermitteln“

4.1.4.5 Operationen an der Außenschnittstelle

4.1.4.5.1 RequestCard

4.1.4.5.2 EjectCard

4.1.4.6 Betriebsaspekte

4.1.4.6.1 Allgemeine Betriebsaspekte

4.1.4.6.2 Kartenterminals pflegen

4.1.4.6.3 Import der Kartenterminal-Informationen

4.1.5 Kartendienst

4.1.5.1 Funktionsmerkmalweite Aspekte

4.1.5.2 Durch Ereignisse ausgelöste Reaktionen

4.1.5.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.1.5.3.1 TUC_KON_001 „Karte öffnen“

4.1.5.4 Interne TUCs, auch durch Fachmodule nutzbar

4.1.5.4.1 TUC_KON_026 „Liefere CardSession“

4.1.5.4.2 TUC_KON_012 „PIN verifizieren“

4.1.5.4.3 TUC_KON_019 „PIN ändern“

4.1.5.4.4 TUC_KON_021 „PIN entsperren“

4.1.5.4.5 TUC_KON_022 „Liefere PIN-Status“

4.1.5.4.6 TUC_KON_027 „PIN-Schutz ein-/ausschalten“

4.1.5.4.7 TUC_KON_023 „Karte reservieren“

4.1.5.4.8 TUC_KON_005 „Card-to-Card authentisieren“

4.1.5.4.9 TUC_KON_202 „LeseDatei“

4.1.5.4.10 TUC_KON_203 „SchreibeDatei“

4.1.5.4.11 TUC_KON_204 „LöscheDateiInhalt“

4.1.5.4.12 TUC_KON_209 „LeseRecord“

4.1.5.4.13 TUC_KON_210 „SchreibeRecord“

4.1.5.4.14 TUC_KON_211 „LöscheRecordInhalt“

4.1.5.4.15 TUC_KON_214 „FügeHinzuRecord“

4.1.5.4.16 TUC_KON_215 „SucheRecord“

4.1.5.4.17 TUC_KON_018 „eGK-Sperrung prüfen“

4.1.5.4.18 TUC_KON_006 „Datenzugriffsaudit eGK schreiben“

4.1.5.4.19 TUC_KON_218 „Signiere“

4.1.5.4.20 TUC_KON_219 „Entschlüssele“

4.1.5.4.21 TUC_KON_200 „SendeAPDU“

4.1.5.4.22 TUC_KON_024 „Karte zurücksetzen“

4.1.5.4.23 TUC_KON_216 „LeseZertifikat“

4.1.5.4.24 TUC_KON_036 „LiefereFachlicheRolle“

4.1.5.5 Operationen an der Außenschnittstelle

4.1.5.5.1 VerifyPin

4.1.5.5.2 ChangePin

4.1.5.5.3 GetPinStatus

4.1.5.5.4 UnblockPin

4.1.5.5.5 EnablePin

4.1.5.5.6 DisablePin

4.1.5.6 Betriebsaspekte

4.1.5.6.1 TUC_KON_025 "Initialisierung Kartendienst"

4.1.5.6.2 Kartenübersicht und PIN-Management

4.1.6 Systeminformationsdienst

4.1.6.1 Funktionsmerkmalweite Aspekte

4.1.6.2 Durch Ereignisse ausgelöste Reaktionen

4.1.6.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.1.6.4 Interne TUCs, auch durch Fachmodule nutzbar

4.1.6.4.1 TUC_KON_256 „Systemereignis absetzen“

4.1.6.4.2 TUC_KON_252 „Liefere KT_Liste“

4.1.6.4.3 TUC_KON_253 „Liefere Karten_Liste“

4.1.6.4.4 TUC_KON_254 „Liefere Ressourcendetails“

4.1.6.5 Operationen an der Außenschnittstelle

4.1.6.5.1 GetCardTerminals

4.1.6.5.2 GetCards

4.1.6.5.3 GetResourceInformation

4.1.6.5.4 Subscribe

4.1.6.5.5 Unsubscribe

4.1.6.5.6 RenewSubscriptions

4.1.6.5.7 GetSubscription

4.1.6.6 Betriebsaspekte

4.1.7 Verschlüsselungsdienst

4.1.7.1 Funktionsmerkmalweite Aspekte

4.1.7.2 Durch Ereignisse ausgelöste Reaktionen

4.1.7.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.1.7.4 Interne TUCs, auch durch Fachmodule nutzbar

4.1.7.4.1 TUC_KON_070 „Daten hybrid verschlüsseln”

4.1.7.4.2 TUC_KON_071 „Daten hybrid entschlüsseln”

4.1.7.4.3 TUC_KON_072 „Daten symmetrisch verschlüsseln”

4.1.7.4.4 TUC_KON_073 „Daten symmetrisch entschlüsseln”

4.1.7.4.5 TUC_KON_075 „Symmetrisch verschlüsseln“

4.1.7.4.6 TUC_KON_076 „Symmetrisch entschlüsseln“

4.1.7.5 Operationen an der Außenschnittstelle

4.1.7.5.1 EncryptDocument

4.1.7.5.2 DecryptDocument

4.1.7.6 Betriebsaspekte

4.1.8 Signaturdienst

4.1.8.1 Funktionsmerkmalweite Aspekte

4.1.8.1.1 Dokumentensignatur

4.1.8.1.2 Signaturrichtlinien

4.1.8.1.3 Signaturzeitpunkt

4.1.8.1.4 Jobnummer

4.1.8.1.5 Komfortsignatur

4.1.8.2 Durch Ereignisse ausgelöste Reaktionen

4.1.8.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.1.8.3.1 TUC_KON_155 „Dokumente zur Signatur vorbereiten”

4.1.8.3.2 TUC_KON_165 „Signaturvoraussetzungen für nonQES prüfen“

4.1.8.3.3 TUC_KON_166 „nonQES Signaturen erstellen“

4.1.8.3.4 TUC_KON_152 "Signaturvoraussetzungen für QES prüfen"

4.1.8.3.5 TUC_KON_154 "QES Signaturen erstellen"

4.1.8.3.6 TUC_KON_168 „Einzelsignatur QES erstellen“

4.1.8.3.7 TUC_KON_158 "Komfortsignaturen erstellen"

4.1.8.3.8 TUC_KON_159 "Signaturdatenelemente nachbereiten"

4.1.8.4 Interne TUCs, auch durch Fachmodule nutzbar

4.1.8.4.1 TUC_KON_160 „Dokumente nonQES signieren”

4.1.8.4.2 TUC_KON_161 „nonQES Dokumentsignatur prüfen”

4.1.8.4.3 TUC_KON_162 „Kryptographische Prüfung der XML-Dokumentensignatur”

4.1.8.4.4 TUC_KON_150 „Dokumente QES signieren”

4.1.8.4.5 Anforderungen an die Stapelsignatur

4.1.8.4.6 TUC_KON_151 „QES Dokumentensignatur prüfen“

4.1.8.4.7 TUC_KON_170 „Dokumente mit Komfort signieren”

4.1.8.4.8 TUC_KON_171 „Komfortsignatur einschalten”

4.1.8.4.9 TUC_KON_172 „Komfortsignatur ausschalten”

4.1.8.4.10 TUC_KON_173 „Liefere Signaturmodus”

4.1.8.5 Operationen an der Außenschnittstelle

4.1.8.5.1 SignDocument (nonQES und QES)

4.1.8.5.2 VerifyDocument (nonQES und QES)

4.1.8.5.3 StopSignature

4.1.8.5.4 GetJobNumber

4.1.8.5.5 ActivateComfortSignature

4.1.8.5.6 DeactivateComfortSignature

4.1.8.5.7 GetSignatureMode

4.1.8.6 Betriebsaspekte

4.1.9 Zertifikatsdienst

4.1.9.1 Funktionsmerkmalweite Aspekte

4.1.9.2 Durch Ereignisse ausgelöste Reaktionen

4.1.9.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.1.9.3.1 TUC_KON_032 „TSL aktualisieren“

4.1.9.3.2 TUC_KON_031 „BNetzA-VL aktualisieren“

4.1.9.3.3 TUC_KON_040 „CRL aktualisieren“

4.1.9.3.4 TUC_KON_033 „Zertifikatsablauf prüfen“

4.1.9.4 Interne TUCs, auch durch Fachmodule nutzbar

4.1.9.4.1 TUC_KON_037 „Zertifikat prüfen"

4.1.9.4.2 TUC_KON_042 „CV-Zertifikat prüfen“

4.1.9.4.3 TUC_KON_034 „Zertifikatsinformationen extrahieren“

4.1.9.5 Operationen an der Außenschnittstelle

4.1.9.5.1 CheckCertificateExpiration

4.1.9.5.2 ReadCardCertificate

4.1.9.5.3 VerifyCertificate

4.1.9.6 Betriebsaspekte

4.1.9.6.1 TUC_KON_035 „Zertifikatsdienst initialisieren“

4.1.10 Protokollierungsdienst

4.1.10.1 Funktionsmerkmalweite Aspekte

4.1.10.2 Durch Ereignisse ausgelöste Reaktionen

4.1.10.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.1.10.4 Interne TUCs, auch durch Fachmodule nutzbar

4.1.10.4.1 TUC_KON_271 „Schreibe Protokolleintrag“

4.1.10.5 Operationen an der Außenschnittstelle

4.1.10.6 Betriebsaspekte

4.1.10.6.1 TUC_KON_272 „Initialisierung Protokollierungsdienst

4.1.11 TLS-Dienst

4.1.11.1 Funktionsmerkmalweite Aspekte

4.1.11.2 Durch Ereignisse ausgelöste Reaktionen

4.1.11.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.1.11.4 Interne TUCs, auch durch Fachmodule nutzbar

4.1.11.4.1 TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen“

4.1.11.4.2 TUC_KON_111 „Kartenbasierte TLS-Verbindung abbauen“

4.1.11.5 Operationen an der Außenschnittstelle

4.1.11.6 Betriebsaspekte

4.1.12 LDAP-Proxy

4.1.12.1 Funktionsmerkmalweite Aspekte

4.1.12.2 Durch Ereignisse ausgelöste Reaktionen

4.1.12.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.1.12.4 Interne TUCs, auch durch Fachmodule nutzbar

4.1.12.4.1 TUC_KON_290 „LDAP-Verbindung aufbauen“

4.1.12.4.2 TUC_KON_291 „Verzeichnis abfragen“

4.1.12.4.3 TUC_KON_292 „LDAP-Verbindung trennen"

4.1.12.4.4 TUC_KON_293 „Verzeichnisabfrage abbrechen"

4.1.12.5 Operationen an der Außenschnittstelle

4.1.12.5.1 Unterstützte LDAPv3 Operationen

4.1.12.6 Betriebsaspekte

4.1.13 Authentifizierungsdienst

4.1.13.1 Funktionsmerkmalweite Aspekte

4.1.13.1.1 Externe Authentisierung

4.1.13.2 Durch Ereignisse ausgelöste Reaktionen

4.1.13.3 Interne TUCs

4.1.13.4 Operationen an der Außenschnittstelle

4.1.13.4.1 ExternalAuthenticate

4.1.13.5 Betriebsaspekte

4.1.14 Betriebsdatenmeldedienst

4.2 Netzkonnektor

4.2.1 Anbindung LAN/WAN

4.2.1.1 Funktionsmerkmalweite Aspekte

4.2.1.1.1 Netzwerksegmentierung

4.2.1.1.2 Routing und Firewall

4.2.1.2 Durch Ereignisse ausgelöste Reaktionen

4.2.1.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.2.1.3.1 TUC_KON_305 „LAN-Adapter initialisieren“

4.2.1.3.2 TUC_KON_306 „WAN-Adapter initialisieren“

4.2.1.3.3 TUC_KON_304 „Netzwerk-Routen einrichten“

4.2.1.4 Interne TUCs, auch durch Fachmodule nutzbar

4.2.1.5 Operationen an der Außenschnittstelle

4.2.1.6 Betriebsaspekte

4.2.2 DHCP-Server

4.2.2.1 Funktionsmerkmalweite Aspekte

4.2.2.2 Durch Ereignisse ausgelöste Reaktionen

4.2.2.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.2.2.4 Interne TUCs, auch durch Fachmodule nutzbar

4.2.2.5 Operationen an der Außenschnittstelle

4.2.2.5.1 Liefere Netzwerkinformationen über DHCP

4.2.2.6 Betriebsaspekte

4.2.2.6.1 TUC_KON_343 „Initialisierung DHCP-Server“

4.2.3 DHCP-Client

4.2.3.1 Funktionsmerkmalweite Aspekte

4.2.3.2 Durch Ereignisse ausgelöste Reaktionen

4.2.3.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.2.3.3.1 TUC_KON_341 „DHCP-Informationen beziehen“

4.2.3.4 Interne TUCs, auch durch Fachmodule nutzbar

4.2.3.5 Operationen an der Außenschnittstelle

4.2.3.6 Betriebsaspekte

4.2.4 VPN-Client

4.2.4.1 Funktionsmerkmalweite Aspekte

4.2.4.2 Durch Ereignisse ausgelöste Reaktionen

4.2.4.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.2.4.3.1 TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen“

4.2.4.3.2 TUC_KON_322 „Verbindung zu dem VPN-Konzentrator des SIS aufbauen“

4.2.4.4 Interne TUCs, auch durch Fachmodule nutzbar

4.2.4.5 Operationen an der Außenschnittstelle

4.2.4.6 Betriebsaspekte

4.2.5 Zeitdienst

4.2.5.1 Funktionsmerkmalweite Aspekte

4.2.5.2 Durch Ereignisse ausgelöste Reaktionen

4.2.5.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.2.5.4 Interne TUCs, auch durch Fachmodule nutzbar

4.2.5.4.1 TUC_KON_351 “Liefere Systemzeit”

4.2.5.5 Operationen an der Außenschnittstelle

4.2.5.5.1 Sync_Time

4.2.5.6 Betriebsaspekte

4.2.5.6.1 TUC_KON_352 Initialisierung Zeitdienst

4.2.6 Namensdienst und Dienstlokalisierung

4.2.6.1 Funktionsmerkmalweite Aspekte

4.2.6.2 Durch Ereignisse ausgelöste Reaktionen

4.2.6.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.2.6.4 Interne TUCs, auch durch Fachmodule nutzbar

4.2.6.4.1 TUC_KON_361 „DNS-Namen auflösen“

4.2.6.4.2 TUC_KON_362 „Liste der Dienste abrufen“

4.2.6.4.3 TUC_KON_363 „Dienstdetails abrufen“

4.2.6.5 Operationen an der Außenschnittstelle

4.2.6.5.1 GetIPAddress

4.2.6.6 Betriebsaspekte

4.2.7 Optionale Verwendung von IPv6

4.3 Konnektormanagement

4.3.1 Zugang und Benutzerverwaltung des Konnektormanagements

4.3.2 Konnektorname und Versionsinformationen

4.3.3 Konfigurationsdaten: Persistieren sowie Export-Import

4.3.4 Administration von Fachmodulen

4.3.5 Neustart und Werksreset

4.3.6 Leistungsumfänge und Standalone-Szenarios

4.3.7 Online-Anbindung verwalten

4.3.8 Re-Registrierung des Konnektors mit weiterem NK-Zertifikat

4.3.9 Remote Management (Optional)

4.3.10 Software- und Konfigurationsaktualisierung (KSR-Client)

4.3.10.1 Funktionsmerkmalweite Aspekte

4.3.10.2 Durch Ereignisse ausgelöste Reaktionen

4.3.10.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.3.10.3.1 TUC_KON_280 „Konnektoraktualisierung durchführen“

4.3.10.3.2 TUC_KON_281 „Kartenterminalaktualisierung anstoßen“

4.3.10.3.3 TUC_KON_282 „UpdateInformationen beziehen“

4.3.10.3.4 TUC_KON_283 „Infrastruktur Konfiguration aktualisieren“

4.3.10.4 Interne TUCs, auch durch Fachmodule nutzbar

4.3.10.4.1 TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“

4.3.10.4.2 TUC_KON_286 „Paket für Fachmodul laden“

4.3.10.5 Operationen an der Außenschnittstelle

4.3.10.6 Betriebsaspekte

4.3.10.6.1 TUC_KON_284 KSR-Client initialisieren

4.3.11 Konnektorstatus

4.4 Hardware-Merkmale des Konnektors

5 Anhang A – Verzeichnisse

5.1 Abkürzungen

5.2 Glossar

5.3 Abbildungsverzeichnis

5.4 Tabellenverzeichnis

5.5 Referenzierte Dokumente

5.5.1 Dokumente der gematik

5.5.2 Weitere Dokumente

6 Anhang B – Profilierung der Signatur- und Verschlüsselungsformate (normativ)

6.1 Profilierung der Verschlüsselungsformate

6.2 Profilierung der Signaturformate

6.3 Profilierung VerificationReport

6.4 Profilierung der Dokumentenformate und Nachrichten

7 Anhang F – Übersicht Events

8 Anhang H – Mapping von „Architektur der TI-Plattform“ auf Konnektorspezifikation

9 Anhang I – Umsetzungshinweise (informativ)

9.1 Systemüberblick

9.1.1 – Hinweise zur Sicherheitsevaluierung nach Common Criteria

9.1.1.1 Separationsmechanismen des Konnektors

9.1.1.2 Granularität der TSF

9.2 Übergreifende Festlegungen

9.2.1 Interne Mechanismen

9.2.1.1 Zufallszahlen und Schlüssel

9.3 Funktionsmerkmale

9.3.1 Anwendungskonnektor

9.3.1.1 Administration des Informationsmodells

9.3.1.2 Vorgehensvariante für das Handling von CardSessions

9.3.1.3 Darstellung von Terminal-Anzeigen auf einem Kartenterminal

10 Anhang K – Szenarien im dezentralen Umfeld

10.1 Szenario 1: Einfache Installation ohne spezielle Anforderungen und ohne bestehende Infrastruktur

10.1.1 Beschreibung des Szenarios

10.1.2 Voraussetzungen

10.1.3 Auswirkungen

10.2 Szenario 2: Installation mit mehreren Behandlungsräumen

10.2.1 Beschreibung des Szenarios

10.2.2 Voraussetzungen

10.2.3 Auswirkungen

10.3 Szenario 3: Integration in bestehende Infrastruktur ohne Netzsegmentierung

10.3.1 Beschreibung des Szenarios

10.3.2 Voraussetzungen

10.3.3 Auswirkungen

10.4 Szenario 4: Integration in bestehende Infrastruktur mit Netzsegmentierung

10.4.1 Beschreibung des Szenarios

10.4.2 Voraussetzungen

10.4.3 Auswirkungen

10.5 Szenario 5: Zentral gesteckter HBA

10.5.1 Beschreibung des Szenarios

10.5.2 Voraussetzungen

10.5.3 Auswirkung

10.6 Szenario 6: Installation mit zentralem PS

10.6.1 Beschreibung des Szenarios

10.6.2 Voraussetzungen

10.6.3 Auswirkungen

10.7 Szenario 7: Mehrere Mandanten

10.7.1 Beschreibung des Szenarios

10.7.2 Voraussetzungen

10.7.3 Auswirkungen

10.8 Szenario 9: Standalone Konnektor - Physische Trennung

10.8.1 Beschreibung des Szenarios

10.8.2 Voraussetzungen

10.8.3 Auswirkung

11 Anhang L – Datentypen von Eingangs- und Ausgangsdaten

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb des Produkttyps Konnektor.

Dieses Dokument beschreibt die dezentrale Komponente zur sicheren Anbindung von Clientsystemen der Institutionen und Organisationen des Gesundheitswesens an die Telematikinfrastruktur – den Konnektor. Der Konnektor ist einerseits verantwortlich für den Zugriff auf die in der Einsatzumgebung befindlichen Kartenterminals sowie Karten und andererseits für die Kommunikation mit den zentralen Diensten der TI-Plattform und fachanwendungsspezifischen Diensten. Aus den Kommunikationsbeziehungen mit Clientsystem, Kartenterminals, Karten und zentralen Diensten der TI-Plattform und fachanwendungsspezifischen Diensten resultieren vom Konnektor anzubietende Schnittstellen, die gemeinsam in diesem Dokument sowie den fachanwendungsspezifischen Fachmodulspezifikationen normativ geregelt werden. Vom Konnektor genutzte Schnittstellen liegen zumeist in anderen Verantwortungsbereichen (zentrale TI-Plattform aber auch Schnittstellen der Kartenterminals und Karten). Diese werden in den übergreifenden Spezifikationen der TI sowie den Produkttypspezifikationen definiert.

Dieses Dokument regelt somit nur einen Teil des Konnektors (wenngleich auch den Wesentlichen). Für die Implementierung eines Konnektors ist entsprechend die Kenntnis aller weiteren Spezifikationen erforderlich. Die Gesamtheit aller für den Konnektor relevanten Dokumente wird im Produkttypsteckbrief des Konnektors erhoben.

1.2 Zielgruppe

Das Dokument richtet sich an Konnektorhersteller sowie Hersteller und Anbieter von Produkttypen (dies beinhaltet auch die Anbieter zur G2-Ausschreibung), 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 Zulassungsverfahren werden durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Wichtiger 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 des Dokuments

Spezifiziert werden in dem Dokument die von dem Produkttyp bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert.

Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps Konnektor verzeichnet.

1.5 Methodik

1.5.1 Anforderungen

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte 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 Afo-ID und der Textmarke angeführten Inhalte.

<AFO-ID> - *

Das Zeichen '*' steht hierbei für den Suffix der Anforderung. Es gilt der im Dokumentenpaket gültige Suffix.

1.5.2 Offene Punkte

Zum Zeitpunkt der Spezifikationserstellung konnten nicht alle Details abschließend geklärt werden, insbesondere, da Abstimmungsbedarf mit der umsetzenden Industrie besteht. Details, die keine produkttypübergreifenden Auswirkungen haben und die im Rahmen des Verhandlungsverfahrens mit der Industrie besprochen werden müssen, werden als „Offene Punkte“ ausgewiesen und wie folgt im Dokument kenntlich gemacht:

1.5.3 Erläuterungen zur Spezifikation des Außenverhaltens

Der Konnektor stellt einen vergleichsweise komplexen Produkttyp dar, dessen Beschreibung eine Herausforderung darstellt und somit in vielen verschiedenen Varianten möglich wäre. An dieser Stelle folgen daher wesentliche Informationen, die das korrekte Verstehen der Spezifikation fördern:

Die Spezifikation des Konnektors ist eine Black-Box-Spezifikation, das heißt alle Festlegungen dienen ausschließlich der Beschreibung des von der Komponente verlangten Verhaltens an der Außenschnittstelle.

Normative Festlegungen, die eine Festlegung des inneren Verhalten vermuten lassen (beispielsweise die Definitionen der Technischen Use Cases - TUCs) sind nur in so weit normativ, wie ihre Festlegungen auf die Außenschnittstelle wirken. Sie legen explizit nicht die intern zu verwendende Implementierung fest. Die Notwendigkeit für diese Art der „scheinbaren internen Beschreibung“ ergibt sich aus der Komplexität der Gesamtkomponente, sowie dem Bedarf, wiederholt ähnlich Verhaltensweisen in Außenschnittstellen darstellen zu müssen. In diesem Fall werden die sich wiederholenden Verhaltensanteile in internen TUCs zur editoriellen Wiederverwendung gekapselt. Die konkrete konnektorinterne Modularisierung bleibt dem Hersteller freigestellt. Insbesondere bleibt es dem Hersteller freigestellt, intern bereits Mechanismen für kommende Releases zu realisieren, sofern diese an der Außenschnittstelle keine Auswirkung zeigen.

Die einzige Abweichung von dieser Vorgehensweise ergibt sich für Sicherheitsaspekte. Hier können interne Vorgänge normativ gefordert sein, die sich an der Außenschnittstelle nicht manifestieren (Beispiel „Verpflichtung auf sicheres Löschen eines temporären Schlüssels nach Gebrauch“). In diesem Fall erfolgt die Überprüfung der Einhaltung dieser Anforderungen im Rahmen der CC-Evaluierung.

1.5.4 Erläuterungen zur Dokumentenstruktur und „Dokumentenmechanismen“

1.5.4.1 Modulare Spezifikation über Funktionsmerkmale

Die Beschreibung des Konnektors erfolgt soweit wie möglich modular, d. h. alle Aspekte, die für einen logischen Bereich relevant sind, werden in einem Kapitel beschrieben. Diese logischen Bereiche werden als Funktionsmerkmal bezeichnet.

Funktionsmerkmale kennzeichnet ein eigener Verantwortungsbereich. In diesen Verantwortungsbereich greifen keine anderen Funktionsmerkmale ein. So kann ein logischer Bereich vollständig durchdrungen werden, ohne dass in anderen Kapiteln Anforderungen zu erwarten wären, die das Verhalten des Funktionsmerkmals beeinflussen. Da zwischen Funktionsmerkmalen Wechselwirkungen bestehen (Die Erkennung einer gesteckten Karte im Kartenterminaldienst löst eine Reaktion im Kartendienst aus), wurden zur „dokumententechnischen Interaktion“ zwischen Funktionsmerkmalen ein interner Event-Mechanismus sowie Konfigurationsparameter und Zustandswerte eingeführt (siehe Folgekapitel).

Funktionsmerkmale bestehen (bis auf wenige Ausnahmen) immer aus folgenden Unterkapiteln:

1. Funktionsmerkmalweite Aspekte
2. Durch Ereignisse ausgelöste Reaktionen
3. Interne TUCs, nicht durch Fachmodule nutzbar
4. Interne TUCs, auch durch Fachmodule nutzbar
5. Operationen an der Außenschnittstelle
6. Betriebsaspekte

Die Unterkapitel 1-5 dienen der funktionalen Beschreibung des Funktionsmerkmals.

Punkte, die zum Funktionieren des Funktionsmerkmals relevant sind: Initialisierungsaspekte, durch den Administrator festzulegenden Konfigurationsparameter etc., werden im Unterkapitel Betriebsaspekte erfasst.

In jedem Funktionsmerkmal sind immer alle Unterkapitel enthalten, auch wenn es im konkreten Einzelfall dort keine Inhalte gibt. Diese feste Struktur innerhalb der Funktionsmerkmale erleichtert die Orientierung und erhöht somit die Lesbarkeit.

1.5.4.2 Technische Use Cases - TUCs

Innerhalb der Funktionsmerkmale in Kapitel 4 erfolgt eine Unterscheidung der TUCs in solche, die nur durch die Basisdienste des Konnektors aufgerufen werden dürfen (rein interne TUCs) und solche die neben den Basisdiensten auch durch Fachmodule genutzt werden dürfen. Diese Unterteilung ergibt sich ausschließlich aus dem Bedarf der editoriellen Steuerung der verschiedenen Spezifikationen (Konnektor- und Fachmodulspezifikationen). Es besteht im Rahmen der Implementierung des Konnektors keine Anforderung diese Trennung intern durchzusetzen.

Die Beschreibung der TUCs erfolgt nach folgendem Muster:

• TUC-Tabelle
• Aktivitäts- oder Sequenzdiagramm (optional)
• Fehlercodetabelle

Dabei wird innerhalb der TUC-Tabelle in der Zeile „Standardablauf“ ausschließlich der Gut-Durchlauf beschrieben. Fehler, die innerhalb dieses Ablaufs auftreten können, werden in der Zeile „Fehlerfälle“ erhoben. Dabei wird auf die jeweilige Schrittnummer innerhalb des Ablaufs referenziert. In dieser Tabellenzeile werden nur Fehlercodes erhoben, die im jeweiligen Fehlerfall geworfen werden müssen. Die genauen Festlegungen zu den Fehlern, neben Fehlercode auch: ErrorType, Severity und Fehlertext, werden in der Fehlercodetabelle festgelegt.    

Die Spezifikation, in der ein TUC definiert wird, ist an den mittleren drei Buchstaben der TUC-Referenz zu erkennen:

• TUC_KON_xxx entsprechend in dieser Konnektorspezifikation
• TUC_PKI_xxx in der PKI-Spezifikation [gemSpec_PKI]
• TUC_VPN_ZD-xxxx in der Spezifikation des VPN-Zugangsdienstes [gemSpec_VPN_ZugD]
• TUC_VZD_xxx in der Spezifikation des Verzeichnisdienstes [gemSpec_VZD]

Festlegungen zur Schreibweise von Eingangs- und Ausgangsdaten von TUCs

a) Eingangs- und Ausgangsparameter werden in TUC-Tabellen wie folgt beschrieben:

Name des Eingangs- bzw. Ausgangsparameters

gefolgt von (falls definiert):[Datentyp]

gefolgt von (falls zutreffend):

- optional; default: <Defaultwert> bzw.

- optional;/<erklärender Text>  

Hierbei bedeuten:

- optional; kennzeichnet optionale Ein- und Ausgangsparameter

default: <Defaultwert> definiert den Defaultwert für den Fall, dass der Eingangsparameter leer ist bzw. nicht übergeben wurde

/ <erklärender Text> beschreibt Bedingungen, unter denen der Eingangsparameter optional ist

     gefolgt von (falls vorhanden):(<erklärender Text>)

b) Namen mit kleinem Anfangsbuchstaben bezeichnen Ein- und Ausgangsparameter; Namen mit großem Anfangsbuchstaben bezeichnen Datentypen.

Beispiel:

Eingangsdaten	mandantId allWorkplaces [Boolean] – optional; default: false (Dieser Schalter gibt an, ob eine mandantenweite Zugriffsberechtigung zum Tragen kommt…) userId - optional/verpflichtend, wenn cardType = HBAx
Ausgangsdaten	pinStatus [PinStatus] leftTries – optional/verpflichtend, wenn pinStatus = VERIFYABLE (Anzahl der verbleibenden Versuche für die Verifikation der PIN)

 

Die im Dokument verwendeten Datentypen sind definiert in [Anhang L – Datentypen von Eingangs- und Ausgangsdaten].

Festlegungen zur Schreibweise des Aufrufs von TUCs

Ein TUC-Aufruf erfolgt nach folgendem Muster:

<TUC-Bezeichner> {

   <TUC-Eingangsparameter Name> = <TUC Eingangsparameter Wert>;

   … }

Beispiel:

TUC_KON_256 {
    topic = „CT/DISCONNECTED“;
    eventType = Op;
    severity = Info;
    parameters = („CtID=$CT.CTID, Hostname=$CT.HOSTNAME“) }

Vereinfachung:

Ist <TUC-Eingangsparameter Name> des aufzurufenden TUCs gleich der Variablen, die als < TUC Eingangsparameter Wert> gesetzt wird, so kann dieser Bezeichner ohne Zuweisung geschrieben werden.

Beispiel: (cardSession und pinRef sind Eingangsdaten des aufrufenden TUCs):

TUC_KON_022 „Liefere PIN-Status“ {cardSession=cardSession; pinRef=pinRef}

vereinfachte Schreibweise:

TUC_KON_022 „Liefere PIN-Status“ {cardSession; pinRef}

1.5.4.3 Event-Mechanismus

Der in Kapitel 4.1.6 spezifizierte Event-Mechanismus zur Unterrichtung von Clientsystemen wird innerhalb dieser Spezifikation auch zur internen Verzahnung der einzelnen Funktionsmerkmale eingesetzt. So wird ein Ereignis, das in der Managementschnittstelle durch Änderung eines Konfigurationsparameters ausgelöst wird, innerhalb des DHCP-Kapitels als Trigger für eine Lease-Erneuerung verwendet. Dies bedeutet nicht, dass im Rahmen der Implementierung intern ein Event-Mechanismus zwischen den Modulen verwendet werden muss. Auch hier dient die Form der Darstellung (Events) lediglich der editoriellen Kopplung verschiedener Verhaltensbeschreibungen.

Um den Ursprung eines Events erkennen zu können, verwenden alle Events ein Haupt-Topic passend zum Funktionsmerkmal: „DHCP/LAN_CLIENT/RENEW” wird im Funktionsmerkmal DHCP ausgelöst, „CARD/INSERTED” wird im Funktionsmerkmal Kartendienst ausgelöst usw.     

1.5.4.4 Konfigurationsparameter und Zustandswerte

Werte die der Administrator des Konnektors einsehen oder verändern können muss, werden zusätzlich zu den Festlegungen in Kapitel 4.3 Konnektormanagement auch pro Funktionsmerkmal in den jeweiligen Unterkapiteln „Betriebsaspekte“ erhoben. Diese Konfigurationsparameter werden über eine ReferenzID definiert. Definierte Konfigurationsparameter können in allen Kapiteln der Spezifikation referenziert werden. Den Ort, an welchem ein solcher Konfigurationsparameter definiert/erhoben und somit dessen Bedeutung beschrieben wird, lässt sich über den Präfix der ReferenzID erkennen: CERT_CRL_DOWNLOAD_ADDRESS (also „Cert“) wird im Zertifikatsdienst definiert, MGM_LU_ONLINE (also „MGM“) wird im Konnektormanagement definiert usw.

Die ReferenzIDs der Konfigurationsparameter besitzen in ihrer Schreibweise nur innerhalb des Dokuments Gültigkeit. In der Umsetzung können für die Konfigurationswerte herstellerspezifische Beschreibungen und Labels verwendet werden.

Vergleichbar zu diesen Konfigurationsparametern, sind Zustandswerte. Auch diese werden über ReferenzIDs definiert, nur können sie nicht durch den Administrator verändert oder eingesehen werden. Sie finden nur konnektorintern Verwendung und sind für die Beschreibung der Verhaltensweise notwendig, Beispiele sind CTM_CT_LIST für die Liste der durch den Konnektor verwalteten Kartenterminals oder CM_CARD_LIST für die Liste der aktuell erreichbaren Karten. Zustandswerte verwenden die gleichen Präfixe wie Konfigurationsparameter.

2 Systemüberblick

Der Konnektor ist ein Produkttyp der TI gemäß [gemKPT_Arch_TIP#5.3.9].

Er bietet seine Basisdienste sowohl intern den in ihm laufenden Fachmodulen an, als auch externen Clientsystemen über die Konnektoraußenschnittstellen.

Im lokalen Netz der Einsatzumgebung kommuniziert das Clientsystem mit dem Konnektor über dessen LAN-seitiges Ethernet-Interface. Alleinig der Konnektor kommuniziert mit den in lokalen Netzen angeschlossenen Kartenterminals und Karten. Auch die Kommunikation mit den zentralen Diensten der TI-Plattform und fachanwendungsspezifischen Diensten erfolgt ausschließlich über den Konnektor über dessen WAN-seitiges Ethernet-Interface.

Abbildung PIC_KON_116 stellt die Schnittstellen im Umfeld des Konnektors dar.

 

Abbildung 1: PIC_KON_116 Schnittstellen des Konnektors von und zu anderen Produkttypen 

Die logischen Außenschnittstellen aus [gemKPT_Arch_TIP] werden im Konnektor technisch vorrangig als SOAP-Schnittstellen ausgeprägt. Von dieser Regel wird insbesondere bei Netzwerkschnittstellen abgewichen, wenn bereits etablierte Schnittstellenstandards für Basisdienste existieren (IPsec, TLS, NTP, DNS etc.). Eine Übersicht der Zuordnung „logische Schnittstellen à→ technische Schnittstellen“ findet sich in Anhang H.

Zum Nachweis der Sicherheit müssen Konnektoren im Rahmen der Zulassung nach Common Criteria gegen die Schutzprofile [PP_NK] und [PP_KON] evaluiert und zertifiziert werden.

Die zu verwendenden kryptographischen Verfahren und zugehörige Parameter (z. B. Schlüssellängen) für alle kryptographischen Operationen innerhalb der Telematikinfrastruktur, werden durch das Dokument „Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur“ [gemSpec_Krypt] normativ geregelt.

2.1 Logische Struktur

Der Produkttyp Konnektor besitzt eine Vielzahl verschiedenster Operationen und Verhaltensweisen an seiner Außenschnittstelle. Um sein komplexes Gesamtverhalten sinnvoll beschreiben zu können, wird der Konnektor innerhalb dieser Spezifikation logisch unterteilt und strukturiert. Es wird primär zwischen Anwendungs- und Netzkonnektor unterschieden, begleitet von Mechanismen, die blockübergreifend beschrieben werden.

Der logische Aufbau des Konnektors ist in Abbildung PIC_KON_117 dargestellt.

• Der Anwendungskonnektor bietet anwendungsnahe Basisdienste (inklusive Signaturdienst) und Fachmodule zur Nutzung durch ein Clientsystem an. 
• Der Netzkonnektor bietet transportnahe Basisdienste und verbindet das lokale Netz der Nutzer mit der zentralen TI-Plattform.
• Die gSMC-K ist zwar ein eigenständiger Produkttyp innerhalb der TI, wird im Konnektor jedoch als Verbaukomponente betrachtet. Sie enthält die kryptographischen Identitäten des Konnektors, sowie Steuerdaten (Umgebungsinformationen TU/RU/PU, zugehörige Adressbereiche, herstellerspezifische Konfigurationsdaten), die aus Sicherheitsgründen unveränderlich in den Konnektor eingebracht werden müssen.
• Das Konnektormanagement dient der administrativen Verwaltung und Steuerung des gesamten Konnektors.
• Der Sichere Datenspeicher dient der integeren, vertraulichen und authentischen Persistierung von veränderlichen Daten (siehe auch Kapitel 2.2).

Abbildung 2: PIC_KON_117 Logische Zerlegung des Konnektors in Anwendungs- und Netzkonnektor 

Diese logische Unterteilung schreibt in keiner Art und Weise die spätere Implementierung durch den Hersteller vor. Der Hersteller kann seine interne Modularisierung des Konnektors frei wählen. Normativ wirksam ist ausschließlich das durch die Detailfestlegungen in Summe beschriebene Verhalten an den Außenschnittstellen des Konnektors als Ganzes.

2.2 Sicherer Datenspeicher

Wie im vorherigen Kapitel dargestellt, wird für den Konnektor ein Datenspeicher angenommen, in welchem der Konnektor alle sicherheitskritischen, veränderlichen Daten dauerhaft speichert, die für seinen Betrieb relevant sind. Dieser Datenspeicher sichert die Integrität, Authentizität und Vertraulichkeit der in ihm hinterlegten Daten bzw. der aus ihm entnommenen Daten. Alleinig der Konnektor hat auf diesen Datenspeicher Zugriff. Für folgende, im weiteren Verlauf der Spezifikation anfallende Daten wird angenommen, dass diese im Sicheren Datenspeicher persistiert werden:

• Der Trust Store des Zertifikatsdienstes
• Die Konfigurationsdaten des Konnektormanagements
• Die Konfigurationsdaten aller Funktionsmerkmale

Ferner stellt der Konnektor den in ihm laufenden Fachmodulen ebenfalls eine Nutzung dieses Datenspeichers für ihre sensiblen Daten zur Verfügung.

Da es sich bei dem Sicheren Datenspeicher um ein internes Modul handelt, welches an der Außenschnittstelle nicht testbar ist, werden an dieses Modul im Rahmen dieser Spezifikation keine Anforderungen erhoben. Da dieses logische Modul aber essenzielle Sicherheitsfunktionen bietet, ohne die ein Konnektor nicht sicher betrieben werden kann, werden die Funktionen, die ein Hersteller für sein Konnektormodell real umsetzt, um die notwendigen sicheren Speicherfunktionen zu realisieren, im Rahmen der CC-Evaluierung geprüft werden. Näheres hierzu regeln die Schutzprofile des Konnektors.

2.3 Überblick Konnektoridentität

Die Geräteidentität des Konnektors (Konnektoridentität) teilt sich in drei Identitäten auf:

• ID.NK.VPN für den Netzkonnektor    
  Die Identität des Netzkonnektors dient der Authentisierung gegenüber den zentralen Netzwerkdiensten und wird für die Anmeldung an den VPN-Konzentrator genutzt.
• ID.AK.AUT für den Anwendungskonnektor    
  Die Identität des Anwendungskonnektors dient der Authentisierung gegenüber den Clientsystemen im Rahmen von TLS-Verbindungen.
• ID.SAK.AUT für die im Anwendungskonnektor enthaltene Signaturanwendungskomponente
  Die Identität des Signaturdienstes dient zur Authentisierung gegenüber den Kartenterminals. Darüber hinaus muss sich der Signaturdienst des Konnektors gegenüber dem Heilberufsausweis mittels eines kartenverifizierbaren Zertifikats (C.SAK.AUTD_CVC) mit entsprechendem Profil ausweisen, um Stapelsignaturen durchführen zu können.  

In der Regel ergibt sich aus dem Kontext, welche Identität gemeint ist, sodass in diesen Fällen nur kurz von der Konnektoridentität geschrieben wird.

Die Geräteidentitäten werden durch asymmetrische Schlüssel und X.509-Zertifikate umgesetzt. In Abhängigkeit vom gewählten kryptographischen Verfahren werden RSA-Schlüssel bzw. ECC-Schlüssel verwendet.

2.4 Mandantenfähigkeit

Den Anforderungen aus [gemKPT_Arch_TIP#TIP1-A_2200] folgend, wird die Mandantenfähigkeit innerhalb des Konnektors nicht durch eine einzelne Funktion, sondern durch Berücksichtigung in einer Reihe von Funktionsmerkmalen umgesetzt.

Die Mandantenfähigkeit wirkt dabei auf:

• Zugriffsberechtigungsdienst: Kapitel 4.1.1    
  (und über diesen auf alle Karten- und Kartenterminaloperationen)
• Systeminformationsdienst: Kapitel 4.1.6

2.5 Versionierung

Gemäß [gemSpec_OM] müssen Konnektor und Kartenterminals über eine Versionierung verfügen. Die relevanten Versionsinformationen sind durch das O&M-Schema ProductInformation.xsd definiert. Ferner definiert [gemSpec_OM], dass Konnektor und Kartenterminal das Konzept der Firmware-Gruppe verwenden müssen. Daher verfügen die beiden Produkttypen auch über eine aktuelle Firmware-Gruppenversion.

Versionsinformationen werden innerhalb des Konnektor an folgenden Stellen ver- und bearbeitet:

• Dienstverzeichnisdienst (Kapitel 4.1.3): Ausgabe der Konnektorversion über SOAP
• Kartenterminaldienst (Kapitel 4.1.4): Anzeige der Versionsinformationen der verwalteten Kartenterminals
• Konnektormanagement (Kapitel 4.3):
  • Anzeige der Versionsinformationen des Konnektors (Kapitel 4.3.2)
  • Software-Aktualisierung (KSR-Client) für Konnektor und Kartenterminals (Kapitel 4.3.9)

2.6 Fachanwendungen

Der Konnektor ist als Plattformkomponente der TI für die Erbringung von Basisdiensten verantwortlich. Fachliche Funktionalitäten werden über die Fachmodule bereitgestellt.

Das Fachmodul wird dabei als integraler Bestandteil des Konnektors verstanden (Konnektor als Monolith), d. h., die Spezifikationen zu Konnektor (als Plattformkomponente) und dem Fachmodul sind zwar getrennt, werden aber von einem Hersteller in einer Gesamtkomponente umgesetzt. Die inneren Schnittstellen zwischen Fachmodul und Konnektor sind von außen nicht erkennbar.

In dieser Ausbaustufe unterstützt der Konnektor die Fachanwendungen VSDM, AMTS, NFDM und ePA über jeweils ein Fachmodul.

Neben Fachanwendungen, die über ihr Fachmodul mit einem gesicherten Fachdienst kommunizieren, unterstützt der Konnektor einen Zugriff von Clientsystemen auf offene Fachdienste.

2.7 Netzseitige Einsatzszenarien

Der Konnektor unterstützt unterschiedliche netzseitige Einsatzszenarien, die in Anhang K beispielhaft dargestellt sind.

Der Konnektor bietet hierzu Konfigurations-Parameter, die je nach netzseitigem Einsatzszenario konfiguriert werden müssen.

2.7.1 Parameter ANLW_ANBINDUNGS_MODUS

Konfiguration 1: Konnektor als Gateway (ANLW_ANBINDUNGS_MODUS = InReihe):
Diese Konfiguration ist geeignet für Szenarien, in denen der Konnektor zwischen das lokale Netz und das Internet Access Gateway (IAG) (z. B. Router mit DSL-/Kabelmodem) geschaltet wird. (vgl. Anhang K, Szenario 1)

Konfiguration 2: Konnektor eingebettet in existierende Infrastruktur (ANLW_ANBINDUNGS_MODUS = Parallel): Diese Konfiguration ist geeignet für Szenarien, in denen der Konnektor als weiteres Gerät in die bestehende Netzwerkinfrastruktur integriert wird. (vgl. Anhang K, Szenario 3)

Aus Sicherheitsgründen soll die Kommunikation der Clientsysteme mit dem Konnektor hierbei verschlüsselt erfolgen (ANCL_TLS_MANDATORY=Enabled). Falls diese Kommunikation unverschlüsselt erfolgt (ANCL_TLS_MANDATORY=Disabled), übernimmt der Nutzer die Verantwortung für die Sicherstellung der vertraulichen Übertragung.

Für den Einsatz und die Nutzung von DHCP gibt es im Zusammenhang mit diesem Konfigurationsparameter folgende Möglichkeiten:

• Die Netzwerkinfrastruktur der Einsatzumgebung verwendet den DHCP-Server des Konnektors (siehe Kap. 4.2.2).
• Ein bestehender DHCP-Server im Netz der Einsatzumgebung wird weiter verwendet und derart konfiguriert, dass als Default Gateway und DNS-Server entweder bestehende Infrastruktur oder der Konnektor verwendet wird.
• Es kommt kein DHCP-Server zum Einsatz. Bei allen Clients im Netz der Einsatzumgebung werden das Default Gateway und der DNS-Server statisch auf den Konnektor gesetzt.

Die DHCP-Konfiguration ist in Konfiguration 1 in aller Regel die folgende: Die WAN-Seite des Konnektors verwendet den DHCP-Server des bestehenden IAG. An der LAN-Seite stellt der Konnektor einen DHCP-Server für alle Clients zur Verfügung.

2.7.2 Parameter ANLW_INTERNET_MODUS

Grundsätzlich routet der Konnektor im Modus ANLW_INTERNET_MODUS=SIS alle für das Internet bestimmten Pakete von Clients, die ihn als Default Gateway verwenden, in den VPN-Tunnel zum SIS, während er im Modus ANLW_INTERNET_MODUS=Keiner diese Pakete verwirft.

Im Unterschied zu (ANLW_ANBINDUNGS_MODUS = InReihe) ist die Nutzung des SIS bei (ANLW_ANBINDUNGS_MODUS = Parallel) optional. Alternativ können auch die Clients, die den Konnektor als Default Gateway verwenden, per Redirect direkt ins Internet verwiesen werden (ANLW_INTERNET_MODUS=IAG).

2.8 Lokale und entfernte Kartenterminals

Gemäß [gemKPT_Arch_TIP] ermöglicht die Telematikinfrastruktur dem Anwender die PIN-Eingabe zur Freischaltung eines HBAs oder einer SMC-B wahlweise lokal oder über das Remote-PIN-Eingabeverfahren durchzuführen. Deshalb unterscheidet auch der Konnektor zwischen einem lokalen Kartenterminal – räumlich („in Sichtweite“) dem Arbeitsplatz zugeordnet – und einem entfernten Kartenterminal.

Ein lokales Kartenterminal befindet sich lokal an einem Arbeitsplatz und kann von diesem aus genutzt werden. Hingegen ist das entfernte Kartenterminal einem entfernten oder auch – für zentral steckende Karten – keinem Arbeitsplatz fest zugewiesen. Ein lokales Kartenterminal kann als sogenanntes Remote-PIN-KT verwendet werden, um die PIN für eine in einem entfernten Kartenterminal steckende Karte einzugeben.

2.9 Standalone-Szenario

Gemäß § 291 Absatz 2b SGB V müssen „Diese Dienste [zur Online-Aktualisierung der Versichertendaten auf der eGK] […] auch ohne Netzanbindung an die Praxisverwaltungssysteme der Leistungserbringer online genutzt werden können.“

Dies bedeutet, dass der Konnektor ohne ein steuerndes Clientsystem ereignisgetrieben Fachanwendungen ausführen können muss. Aus Fachsicht „steht der Konnektor alleine“, ohne Clientsysteme. Die konkreten Aktionen, die Fachanwendungen in diesen Fällen ausführen, sowie deren Auslöser werden in den jeweiligen Fachmodulspezifikationen beschrieben.

Ein solcher alleinstehender Konnektor mit Zugang zur TI muss zur Durchführung der Fachanwendungen durch einen weiteren Konnektor unterstützt werden, der in direkter Verbindung zum Clientsystem steht, selbst aber keine Online-Anbindung besitzt.

3 Übergreifende Festlegungen

Für die folgenden Inhalte bitte die Hinweise in Kapitel 1.5.3 „Erläuterungen zur Spezifikation des Außenverhaltens" sowie Kapitel 1.5.4 Erläuterungen zur Dokumentenstruktur und „Dokumentenmechanismen“ beachten.

In diesem Kapitel werden die Aspekte des Konnektors behandelt, die Funktionsmerkmalübergreifend geregelt werden müssen.

Die Managementschnittelle/Administrationsoberfläche des Konnektors wird dabei nicht als übergreifender Aspekt, sondern als eigenes Funktionsmerkmal gewertet. Die Festlegungen hierzu finden sich entsprechend in Kapitel 4.3.

3.1 Allgemeine übergreifende Festlegungen

3.1.1 Dokumentformate

Mit dem Aufruf einer Operation, die Dokumente verarbeitet, muss durch den Aufrufer festgelegt werden können, um welches Dokumentenformat es sich handelt, damit die unterschiedlichen Formate zur Verarbeitung und etwaigen Anzeige unterschieden werden können. Die nicht-XML-Formate werden dabei nach MIME-Typ-Klassen unterschieden:

• „PDF/A” für MIME-Typ „application/pdf-a” gemäß [ISO 19005],
• „Text” für MIME-Typ „text/plain”,
• „TIFF“ für MIME-Typ „image/tiff” gemäß [TIFF6]
• „Binär“ für alle übrigen MIME-Typen.

Folgende Bezeichner werden verwendet:

Alle_DocFormate:      XML, PDF/A, Text, TIFF, Binär

nonQES_DocFormate:    XML, PDF/A, Text, TIFF, Binär

QES_DocFormate:        XML, PDF/A, Text, TIFF

Für nonQES_DocFormate wird, trotz Gleichheit zu Alle_DocFormate, ein eigener Referenzbezeichner verwendet, da sich diese Liste noch ändern könnte. TIFF wird durch [gemKPT_Arch_TIP] nicht für die nonQES verlangt. Die Unterstützung dieses Formats für nonQES bedeutet jedoch keinen Mehraufwand, da die Routinen durch QES bereits implementiert sind und nachgenutzt werden können.

TIP1-A_4500-02 - Dokumentgrößen von 25 MB

Der Konnektor MUSS für alle Außenschnittstellen, in denen ein Dokument verarbeitet wird, Dokumente mit einer Größe <= 25 MB (26.214.400 Byte) unterstützen. Der Konnektor DARF NICHT Dokumente mit einer Größe > 25 MB (26.214.400 Byte) unterstützen. [<=]

A_19052-01 - Mindestanforderungen an Dokumente und Nachrichten

Der Konnektor MUSS bei der Verarbeitung von Dokumenten und Nachrichten die Mindestanforderungen aus TAB_KON_775 erfüllen. Wenn vom Aufrufer übergebene Dokumente oder Nachrichten die vom Konnektor unterstützte Dimensionierung überschreiten, MUSS der Konnektor die Verarbeitung mit Fehler 4280 abweisen.
 

Tabelle 1 Fehlercodes TAB_KON_890 Mindestanforderungen an Dokumente und Nachrichten

[<=]

A_22673 - Unerlaubte Inhalte in Dokumenten und Nachrichten

Der Konnektor MUSS bei der Verarbeitung von Dokumenten und Nachrichten die Einhaltung der Vorgaben aus TAB_KON_889 sicherstellen. Wenn vom Aufrufer an den Konnektor übergebene Dokumente oder Nachrichten gegen Vorgaben aus TAB_KON_889 verstoßen, MUSS der Konnektor die Verarbeitung mit Fehler 4281 abbrechen.
 

Tabelle 2 Fehlercodes TAB_KON_891 Unerlaubte Inhalte in Dokumenten und Nachrichten

[<=]

A_22923 - XML-Attribute schemaLocation und noNamespaceSchemaLocation nicht auswerten

Der Konnektor DARF in XML-Dokumenten- und Nachrichten enthaltene Attribute schemaLocation und noNamespaceSchemaLocation NICHT auswerten. [<=]

TIP1-A_4502 - Zeichensatzcodierungen UTF-8 und ISO-8859-15

Der Konnektor MUSS bei der Verarbeitung von Dokumenten der Formate XML und Text die Zeichensatzkodierungen UTF-8 und ISO-8859-15 unterstützen. Das verarbeitete Dokument MUSS der Konnektor mit demselben Zeichensatz kodieren, in dem das Eingangsdokument kodiert war. [<=]

TIP1-A_5541-01 - Referenzen in Dokumenten nicht dynamisch auflösen

Der Konnektor DARF in Dokumenten eventuell vorhandene Referenzen auf externe Ressourcen NICHT auflösen, es sei denn es sind Verweise auf im Konnektor sicher eingebrachte vorliegende Schemata oder dies wird im Einzelfall normativ gefordert. [<=]

3.1.2 Kartentypen

Der Konnektor unterstützt eine Reihe von Kartentypen. Die folgende Tabelle enthält die Liste der Referenzbezeichner für die verschiedenen Kartentypen, wie sie im weiteren Verlauf verwendet werden. Die Unterstützung von Karten der Generation 2 (G2.x: G2.0, G2.1 und höher) beschränkt sich bei diesen auf die Datenstrukturen und Schlüssel, die aus Gründen der Abwärtskompatibilität zu den Karten der Generation 1+ vorhanden sind. Eine Ausnahme hiervon bilden die Geräte-CVCs, die bereits für dieses Release basierend auf ECC verwendet werden.

Tabelle 3: TAB_KON_500 Wertetabelle Kartentypen 

ReferenzID Kartentyp	Karten- generation	Beschreibung
EGK	G1+	Die elektronische Gesundheitskarte gemäß [gemSpec_eGK_P1] und [gemSpec_eGK_P2]
EGK	G2	Die elektronische Gesundheitskarte gemäß [gemSpec_COS] und [gemSpec_eGK_ObjSys] bzw. [gemSpec_eGK_ObjSys_G2.1]
HBA-qSig	-	HBA-Vorläuferkarte gemäß [HPC-P1] und [HPC-P2]
HBA	G2	Der elektronische Heilberufsausweis (HBA) gemäß [gemSpec_COS] und [gemSpec_HBA_ObjSys]
SMC-B	G2	Die Institutionskarte Typ B (Secure Module Card) gemäß [gemSpec_COS] und [gemSpec_SMC-B_ObjSys]
HSM-B		HSM-Variante einer SM-B. Das HSM-B wird in dieser Fassung als ein oder mehrere virtuelle Kartenterminals verstanden, in denen virtuelle Karten stecken.
SMC-KT	G2	Die Karte Typ KT (Secure Module Card) gemäß [gemSpec_COS] und [gemSpec_gSMC-KT_ObjSys]
KVK	-	Die Krankenversichertenkarte gemäß der Spezifikation [KVK]
ZOD_2.0	-	HBA-Vorläuferkarte gemäß [HPC-P1] und [HPC-P2]
UNKNOWN		Eine nicht erkannte Karte oder nicht lesbare Karte
		Zusammenfassende ReferenzIDs
HBA-VK		Adressiert die HBA-Vorläuferkarten HBA-qSig und ZOD_2.0. Wird dieser Referenzbezeichner verwendet, gelten die zugehörigen Aussagen und Festlegungen für beide Kartentypen.
HBAx		Adressiert sowohl den HBA, als auch die HBA-Vorläuferkarten (HBA-VK) Wird dieser Referenzbezeichner verwendet, gelten die zugehörigen Aussagen und Festlegungen für alle drei Kartentypen.
SM-B		Adressiert sowohl eine echte SMC-B als auch eine in einem HSM-B enthaltene virtuelle SMC-B. Wird dieser Referenzbezeichner verwendet, gelten die zugehörigen Aussagen und Festlegungen für beide Typen.

3.1.3 Übergreifende Festlegungen zum Aufbau von sicheren Verbindungen

TIP1-A_7254 - Reaktion auf OCSP-Abfrage beim TLS-Verbindungsaufbau

Der Konnektor MUSS beim Aufbau von TLS-gesicherten Verbindungen zu einem zentralen Dienst der TI-Plattform oder zu einem fachanwendungsspezifischen Dienst, bei denen eine OCSP-Abfrage des Serverzertifikats nach TUC_PKI_006 erfolgt, neben Fehlerfällen bei folgenden Warnungen gemäß [gemSpec_PKI#Tab_PKI_274]

• CERT_REVOKED
• CERT_UNKNOWN
• OCSP_CHECK_REVOCATION_FAILED

mit Abbruch des Verbindungsaufbaus reagieren. [<=]

In [gemSpec_Krypt#6] wird das Kommunikationsprotokoll zwischen einem Client und einer Vertrauenswürdigen Ausführungsumgebung (VAU) spezifiziert. Dabei wird ein sicherer Kanal auf HTTP-Anwendungsschicht zwischen dem Client und der VAU (Server) aufgebaut. Der Client ist hier ein Fachmodul des Konnektors; der Server ist ein Fachdienst.

A_17225-01 - Aufbau einer sicheren Verbindung zur Vertrauenswürdige Ausführungsumgebung (VAU)

Der Konnektor MUSS für Fachmodule den Aufbau einer sicheren Verbindung zur Vertrauenswürdigen Ausführungsumgebung (VAU) gemäß Kommunikationsprotokoll [gemSpec_Krypt#6] unterstützen und das vom Server übergebene Zertifikat wie folgt prüfen:
TUC_KON_037 „Zertifikat prüfen“  {
       certificate = C.FD.AUT;
       qualifiedCheck = not_required;
       offlineAllowNoCheck = false;
       policyList  = oid_fd_aut;
       intendedKeyUsage= intendedKeyUsage(C.FD.AUT);
       validationMode  = OCSP}
Der Konnektor MUSS die vom Fachmodul übergebene Rolle gegen die aus dem Zertifikat ermittelte Rolle prüfen.   [<=]

A_17777 - sicherheitstechnische Festlegungen zum Abruf von kryptographischen Schlüsseln von einem Schlüsselgenerierungsdienst

Der Konnektor MUSS für Fachmodule für die Nutzung der Schlüsselableitungsfunktionalität die sicherheitstechnischen Festlegungen gemäß [gemSpec_Krypt#3.15.5 Schlüsselableitungsfunktionalität ePA] und [gemSpec_SGD] bereitstellen. [<=]

Der Gesamtablauf der Schlüsselableitungsfunktionalität gemäß [gemSpec_SGD#2.3] für den Konnektor als Client ist aufgeteilt zwischen Basiskonnektor und Fachmodul. Die kryptographischen Vorgaben (u.a. Durchführung des ECDH, Schlüsselerzeugung, Ver- und Entschlüsselung, Signaturerzeugung und -prüfung) werden dabei durch den Basiskonnektor realisiert.

3.2 Konnektoridentität und gSMC-K

TIP1-A_4503 - Verpflichtung zur Nutzung von gSMC-K

Der Konnektor MUSS das geheime Schlüsselmaterial zur Geräteidentität (ID.NK.VPN, ID.AK.AUT, ID.SAK.AUT) und der Rolle SAK (C.SAK.AUTD_CVC) über Smartcards des Typs gSMC-K gemäß [gemSpec_gSMC-K_ObjSys] nutzen. Der Konnektor MUSS mit einer gSMC-K bestückt sein. Er KANN mit mehr als einer gSMC-K bestückt sein.

[<=]

Die Notwendigkeit, den Konnektor mit mehr als einer gSMC-K zu bestücken, kann sich aus den Lastanforderungen aus [gemSpec_Perf#4.1.2] ergeben.

TIP1-A_4504 - Keine Administratorinteraktion bei Einsatz mehrerer gSMC-Ks

Verwendet der Konnektor mehrere gSMC-Ks, DARF eine Administratorinteraktion für diese Belange NICHT erforderlich sein.

[<=]

TIP1-A_5543 - Keine manuelle PIN-Eingabe für gSMC-K

Der Konnektor DARF Anwender und Administratoren außer bei der Inbetriebnahme (erstmalig oder nach Werksreset) NICHT auffordern, eine PIN für eine gSMC-K einzugeben.

[<=]

TIP1-A_4505 - Schutz vor physischer Manipulation gSMC-K (Sichere Verbundenheit der gSMC-K)

Die gSMC-K des Konnektors MÜSSEN durch den Einsatz physikalischer Sperren oder manipulationssicherer Siegel so mit dem Konnektor verbunden sein, dass physischer Missbrauch oder physische Manipulation erkennbar ist.

[<=]

gSMC-Ks gemäß [gemSpec_gSMC-K_ObjSys] verfügen über die Möglichkeit zur nachträglichen Generierung von Schlüsselpaaren und dem Nachladen der zugehörigen Zertifikate. Dieser Mechanismus wird erst in kommenden Releases durch den Konnektor unterstützt. Initial sind alle Identitäten bereits einmal auf der gSMC-K vorhanden.

TIP1-A_4506 - Initiale Identitäten der gSMC-K

In Abhängigkeit vom kryptographischen Verfahren MUSS der Konnektor folgende Objekte der gSMC-K als Quelle seiner Identitäten verwenden:

Tabelle 4: TAB_KON_856: Identitäten des Konnektors auf der gSMC-K 

[<=]

A_21849 - Anzeige verwendeter Zertifikate

Der Konnektor MUSS dem Administrator anzeigen, welche Zertifikate aktuell verwendet werden. Dies gilt für diese Strecken bzw. Anwendungsfälle: VPN-Tunnel (C.NK.VPN), TLS zum PS (C.AK.AUT oder lokales Zertifikat), TLS zum KT (C.SAK.AUT) und C2C für SUK (C.SAK.AUTD_CVC und C.CA_SAK.CS). [<=]

3.2.1 Erneuerung der Zertifikate der gSMC-K

A_21736 - Verwendung erneuerter Zertifikate

Nach erfolgreicher Zertifikatserneuerung MUSS der Konnektor vor Ablauf der alten Zertifikate an allen Stellen, wo er die Zertifikate C.NK.VPN, C.AK.AUT, C.SAK.AUT, C.SAK.AUTD_CVC und C.CA_SAK.CS verarbeitet, die neuen Zertifikate verwenden, es sei denn die Spezifikation trifft andere Festlegungen. [<=]

Es werden keine expliziten Festlegungen zu herstellerspezifisch verwendetem Material auf der gSMC-K getroffen. Es liegt in der Verantwortung des Konnektor-Herstellers, dafür zu sorgen, dass der Konnektor nach Erneuerung und Aktivierung der spezifizierten Zertifikate insgesamt fehlerfrei lauffähig ist.

A_21744 - Zertifikate regelmäßig erneuern

Der Konnektor MUSS die Zertifikate C.NK.VPN, C.AK.AUT, C.SAK.AUT, C.SAK.AUTD_CVC und C.CA_SAK.CS regelmäßig erneuern. Der Konnektor MUSS 180 Tage vor Ablauf des aktuell verwendeten C.NK.VPN-Zertifikats den Zertifikatserneuerungsprozess anstoßen. Solange die Zertifikate noch nicht vollständig erfolgreich erneuert wurden, MUSS der Konnektor genau einmal täglich durch Aufruf von TUC_KON_410 neue Zertifikate beziehen. [<=]

A_21879 - Erneuerte Zertifikate der gSMC-K manuell importieren

Der Konnektor MUSS es dem Administrator ermöglichen, erneuerte Zertifikate C.NK.VPN, C.AK.AUT, C.SAK.AUT, C.SAK.AUTD_CVC und C.CA_SAK.CS manuell von lokaler Datenquelle einzuspielen.
Der Konnektor MUSS dies auch im kritischen Betriebszustand EC_NK_Certificate_Expired ermöglichen. [<=]

A_21749-03 - TUC_KON_410 „gSMC-K-Zertifikate aktualisieren“

Der Konnektor MUSS den technischen Use Case TUC_KON_410 „gSMC-K-Zertifikate aktualisieren“ umsetzen.
 

Tabelle 5: TAB_KON_930 – TUC_KON_410 „Zertifikate aktualisieren“ 

Tabelle 6: Tab_Kon_931 Fehlercodes TUC_KON_410 „gSMC-K-Zertifikate aktualisieren“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
herstellerspezifisch

[<=]

A_21780 - Nutzerhinweis bezüglich Fehler bei Zertifikatserneuerung

Der Hersteller des Konnektors MUSS in seinem Handbuch den Nutzer/Administrator darauf hinweisen, dass die Ereignisse mit dem Topic=SMC_K/UPDATE/ERROR und dem Topic=SMC_K/DOWNLOAD/ERROR dringend durch das Primärsystem abonniert werden sollten und dass der Nutzer/Administrator sich bei Auftreten des Fehlers unverzüglich mit dem Hersteller in Verbindung setzen muss.
[<=]

3.2.2 Organisatorische Anforderungen und Sperrprozesse

TIP1-A_5392 - gSMC-K-Verantwortung durch den Hersteller des Konnektors

Der Hersteller des Konnektors MUSS die Rolle des Kartenherausgebers für in seinen Konnektoren verbauten gSMC-Ks einnehmen.

Der Hersteller des Konnektors KANN die von ihm verantwortete Personalisierung der gSMC-K durch einen von ihm zu beauftragenden Dienstleister in seinem Namen vornehmen lassen.

[<=]

TIP1-A_5696 - Prüfung der personalisierten gSMC-K

Der Hersteller des Konnektors MUSS sich von der korrekten Personalisierung der herausgegebenen gSMC-K überzeugen.

[<=]

A_18928 - Ausstattung mit dual-personalisierten gSMC-K-X.509-Zertifikaten

Der Hersteller des Konnektors MUSS die Konnektoren mit einer gSMC-K mit personalisierten RSA- und ECC-Zertifikaten gemäß TAB_KON_856 ausstatten. [<=]

A_18930 - Unterstützung von gSMC-K Personalisierungsvarianten

Der Konnektor MUSS unterschiedliche gSMC-K-Personalisierungsvarianten sowohl mit als auch ohne ECC-Zertifikate für ID.NK.VPN, ID.AK.AUT und ID.SAK.AUT unterstützen. [<=]

Die Anforderung ist für die Anwendungsfälle Registrierung, IPsec-Authentisierung und Autorisierung beim VPN-Zugangsdienst, TLS-Authentisierung zum eHealth-Kartenterminal, TLS-Authentisierung zum Primärsystem nachzuweisen. Wenn RSA-2048 in der TI abgekündigt wird, entfällt dadurch die Anforderung.

TIP1-A_5393 - Dokumentation der Konnektorzertifikatszuordnungen

Der Hersteller des Konnektors MUSS die Zuordnung von Konnektor und jeweils eingebrachtem C.NK.VPN-Zertifikat mit dem Ziel dokumentieren, anhand eines Sperrauftrages für einen Konnektor, das zu sperrende C.NK.VPN-Zertifikat identifizieren zu können.

[<=]

Das bedeutet, dass der Konnektorhersteller je Konnektor die für die Identifikation des C.NK.VPN-Zertifikates relevanten Daten wie z. B. Seriennummer des Konnektors und Art der verbauten Komponenten, Seriennummer der gSMC-K, etc. für seinen Sperrprozesse dokumentieren muss.

TIP1-A_5394 - Bereitstellen eines Konnektorsperrprozesses

Der Hersteller des Konnektors MUSS für die von ihm verantworteten Konnektoren einen Sperrprozess etablieren, unterhalten und der gematik zugänglich machen.

Der Hersteller des Konnektors KANN die operative Durchführung des Sperrprozesses an Dritte delegieren.

[<=]

Sperrberechtigt ist die gematik im Rahmen des Change-Verfahrens (siehe [gemRL_Betr_TI#5.4).

TIP1-A_5395 - Sperrberechtigung der gematik gegenüber Konnektorhersteller

Der Hersteller des Konnektors MUSS im Rahmen der Change-Durchführung erteilte Sperraufträge der gematik fristgemäß (gemäß Change-Auftrag) bei dem TSP X.509 nonQES (Zertifikatsaussteller) umsetzen.

[<=]

Dazu bedient er die standardmäßige Schnittstelle zum TSP (siehe [gemSpec_X.509_TSP#TIP1-A_3643]).

TIP1-A_5396 - Prüfung des Sperrauftrages für Konnektoren

Der Hersteller des Konnektors MUSS vor der Umsetzung des Sperrauftrages für einen Konnektor die Sperrberechtigung des Beauftragenden prüfen und verhindern, dass Konnektoren missbräuchlich gesperrt werden.

[<=]

TIP1-A_5397 - Umsetzung von Sperraufträgen für Konnektoren

Der Hersteller des Konnektors MUSS nach erfolgreicher Prüfung der Sperrberechtigung des Beauftragenden die Sperrung der entsprechenden C.NK.VPN-Zertifikate unverzüglich bei dem TSP X.509 nonQES (Zertifikatsaussteller) beauftragen.

[<=]

TIP1-A_5398 - Beschränkung der Sperrberechtigung des Konnektorherstellers

Der Hersteller des Konnektors DARF NICHT die Sperrung von C.NK.VPN-Zertifikaten bei dem TSP X.509 nonQES (Zertifikatsaussteller) beauftragen, wenn er nicht durch einen für den Konnektor Sperrberechtigten dazu beauftragt wurde.

[<=]

TIP1-A_5399 - Protokollierung der Sperrung von Konnektoren

Der Hersteller des Konnektors MUSS die Durchführung der Sperrung eines Konnektors protokollieren und der gematik auf Anfrage übermitteln.
Dabei MÜSSEN folgende Informationen protokolliert werden:

• Zeitpunkt der Beantragung und Umsetzung der Sperrung
• Grund der Sperrung
• Konnektoridentifikation

[<=]

Der Hersteller des Konnektors übernimmt im Rahmen der organisatorischen Sperrung die Aufgabe der Anwenderkommunikation gegenüber den betroffenen Anwendern. Die Eckpunkte zur Kommunikation sind Bestandteil des Beschlusses zur Außerbetriebnahme einer Konnektor-Baureihe und im Rahmen des Change-Verfahrens zwischen den Beteiligten abgestimmt.

TIP1-A_5400 - Fortführen des Konnektor-Sperrprozesses

Der Hersteller des Konnektors MUSS die Fortführung des Sperrprozesses über die Einstellung seiner Geschäftstätigkeit hinaus gewährleisten.

[<=]

Dies kann bspw. durch Übertragung der Aufgabe an einen Dritten realisiert werden. Dabei sind die Zuordnungen Konnektor zu Zertifikat gemäß Anforderung „Dokumentation der Konnektorzertifikatszuordnungen“ zur Verfügung zu stellen.

Bei der Schlüsselerzeugung für die gSMC-K muss insbesondere auch mit technischen Maßnahmen die Vertraulichkeit der relevanten Schlüssel sichergestellt werden:

TIP1-A_7225 - Schlüsselerzeugung bei einer Schlüsselspeicherpersonalisierung

Der Hersteller des Konnektors, der Schlüssel für die gSMC-K erzeugt, MUSS diese Schlüssel mittels eines technischen Sicherheitsmoduls (HSM, Chipkarte, TPM etc.) erzeugen, welches

1. über einen Zugriffsschutz verfügt, sodass nur Berechtigte Schlüssel darauf nutzen können,
2. in einem zutrittsgeschützten Bereich aufbewahrt wird und
3. mindestens nach FIPS 140-2 Level 3 oder [COS-G2] (CC-zertifizierte Chipkarte der TI) zertifiziert ist.

Wird für die Schlüsselerzeugung eine Schlüsselableitung verwendet, so MUSS die Schlüsselableitung die fachlichen Anforderungen aus GS-A_5386 erfüllen.
Es ist zulässig, dass asymmetrische Schlüssel bei der Personalisierung auf der gSMC-K selbst erzeugt werden und symmetrische Schlüssel mittels einer Schlüsselableitung erzeugt werden, bei dem sich der Ableitungsschlüssel (Masterkey) innerhalb eines nach 3. zulässigen Hardwaresicherheitsmoduls befindet.
Es ist zulässig, sicherheitstechnisch geeignete Maßnahmen zur Sicherstellung der Verfügbarkeit der Ableitungsschlüssel (Masterkey) umzusetzen (bspw. Shamir Secret-Sharing-Verfahren).
Der Hersteller des Konnektors MUSS die Schlüsselerzeugung und die Schlüsselverwaltung in einem Konzept darstellen, das die technischen und organisatorischen Maßnahmen beschreibt, die den Schutzbedarf der verarbeiteten Informationsobjekte befriedigen. Der Hersteller des Konnektors MUSS dieses Konzept der gematik zur Verfügung stellen. [<=]

TIP1-A_5703 - Geschützte Übertragung von Daten zum Kartenpersonalisierer

Der Hersteller des Konnektors, der Daten für die gSMC-K erzeugt (bspw. Schlüssel), MUSS diese Daten bei der Übertragung zum Kartenpersonalisierer hinsichtlich Vertraulichkeit, Authentizität und Integrität mit einem Verfahren nach [gemSpec_Krypt] schützen.

[<=]

3.3 Bootup-Phase

TIP1-A_4507 - Isolation während der Bootup-Phase

Da während der Bootup-Phase des Konnektors noch nicht alle Sicherheitsmechanismen ihre Leistung erbringen können, DÜRFEN die Dienste des Konnektors während dem Bootup über physikalische Schnittstellen von außen NICHT erreichbar sein.

[<=]

TIP1-A_4508 - Konnektorzustand nach Bootup

Der Konnektor MUSS nach Beendigung der Bootup-Phase die Initialisierung der Funktionsmerkmale durchlaufen haben. Die Startreihenfolge der Funktionsmerkmale kann unter Berücksichtigung von TIP1-A_4507 herstellerspezifisch gestaltet werden.
Im Rahmen der Bootup-Phase MÜSSEN folgende TUCs ausgeführt werden: TUC_KON_025, TUC_KON_035, TUC_KON_272, TUC_KON_341, TUC_KON_343, TUC_KON_352 (die Reihenfolge der TUC-Ausführung ist herstellerspezifisch).
Treten während der Bootup-Phase Fehler auf, so MUSS die Bootup-Phase, sofern möglich, abgeschlossen werden.
Sobald die Bootup-Phase abgeschlossen ist, MUSS TUC_KON_256 „Systemereignis absetzen“ mit folgenden Parameter aufgerufen werden:
TUC_KON_256 {
    topic = "BOOTUP/BOOTUP_COMPLETE";
    eventType = Op;
    severity = Info;
    }
[<=]

Die hier gelisteten TUCs bilden nicht die abschließende Menge der während der Bootup-Phase zu erfüllenden Anforderungen. In den einzelnen Funktionsmerkmalen werden weitere Einzelanforderungen erhoben, die als Ausführungszeitpunkt die Bootup-Phase benennen (siehe Unterkapitel „Betriebsaspekte“ der einzelnen Funktionsmerkmal-Kapiteln, sowie Kapitel 4.3 Konnektormanagement).

3.4 Betriebszustand

TIP1-A_4509 - Betriebszustand erfassen

Der Konnektor MUSS seinen Betriebszustand gemäß Tabelle TAB_KON_503 Betriebszustand_Fehlerzustandsliste über Fehlerzustände $EC erfassen.

Tritt die in Spalte „Beschreibung“ charakterisierte Fehlersituation eines Fehlerzustandes $EC ein, wird sein Wert $EC.value = true. Sobald die Fehlersituation beendet ist, springt der Wert auf $EC.value = false. Die Fehlerzustände müssen dabei innerhalb der „max. Feststellungszeit“ (Tabellenspalte) erfasst werden. Eine maximale Feststellungszeit von einen Tag (1 day) verlangt, dass einmal am Tag der Zustand geprüft werden muss, unabhängig davon, welche TUCs aufgerufen werden. Eine maximale Feststellungszeit von 1 sec, 10 sec, 1 min und 300 sec verlangt, dass nach der Feststellung einer Fehlfunktion innerhalb eines TUCs die Zustandsänderung innerhalb der angegebenen Zeit stattfinden muss.

Nach Abschluss des Boot-Vorgangs müssen sämtliche Fehlerzustände mit einer „max. Feststellungszeit“ von „1 day“ erfasst worden sein.

[<=]

TIP1-A_4597 - Unterstützung von Missbrauchserkennungen

Der Konnektor MUSS zur Unterstützung von Missbrauchserkennungen für alle Operationen, die in EVT_MONITOR_OPERATIONS gelistet sind und deren Alarmwert > 0 ist, kontinuierlich folgende Aktivitäten durchlaufen:

1. Minütlich gleitende 10-Minuten-Summe je in EVT_MONITOR_OPERATIONS gelistete Operation berechnen. Dazu gehen
   • erfolgreiche Abschlüsse der Operation mit dem OK_Val der Operation ein
   • eine fehlerhaft beendete Operation mit dem NOK_Val der Operation ein
2. Überschreitet der gleitende 10-Minuten-Summenwert einer in EVT_MONITOR_OPERATIONS gelisteten Operation den zugehörigen Alarmwert, so setze EC_CRYPTOPERATION_ALARM auf True.

[<=]

Erklärung „Minütlich gleitende 10-Minuten-Summe“: Für die jeweilige Operation wird die Summe aller OK_Val und NOK_Val der letzten 10 Minuten gebildet. Diese Summe wird jede Minute neu berechnet.

TIP1-A_4512-05 - Ereignis bei Änderung des Betriebszustandes

Der Konnektor MUSS per Ereignisdienst TUC_KON_256 über Änderungen des Betriebszustandes (Tabelle TAB_KON_503 Betriebszustand_Fehlerzustandsliste) informieren.
Der Konnektor muss dazu für jeden Fehlerzustand $EC mit Error Condition $EC.errorcondition mit verändertem Wert $EC.value den technischen Anwendungsfall TUC_KON_256 „Systemereignis absetzen“ mit folgenden Parametern aufrufen:
TUC_KON_256 {    
    topic = "OPERATIONAL_STATE/$EC.errorcondition";
    eventType = $EC.type;
    severity = $EC.severity;
    parameters = („Value=$EC.value, $EC.parameterlist”)
}
 

Tabelle 7: TAB_KON_503 Betriebszustand_Fehlerzustandsliste

ErrorCondition (siehe Hinweis 1)	Beschreibung	Type	Seve rity	max. Fest stell ungs- zeit	Parameterlist (siehe Hinweis 2)
EC_CardTerminal_ Software_Out_Of_ Date ($ctId)	Software auf Kartenterminal($ctId) ist nicht aktuell	Op	Info	1 day	CtID=$ctId; Bedeutung= $EC.description
EC_CardTerminal_ gSMC-KT_Certificate_ Expires_Soon ($ctId)	Das Zertifikat der gSMC-KT im Kartenterminal($ctId) läuft in weniger als 5 Wochen ab	Op	Info	7 days	CtID=$ctId; Bedeutung= $EC.description
EC_Connector_ Software_Out_ Of_Date	I_KSRS_Download::list_ Updates liefert mindestens eine UpdateInformation mit einer UpdateInformation/Firmware/ FWVersion > aktuelle Version der Konnektorsoftware, deren UpdateInformation/Firmware/ FWPriority = „Kritisch“	Op	Info	1 day	Bedeutung= $EC.description
EC_FW_Update_Available	I_KSRS_Download::list_ Updates liefert mindestens eine UpdateInformation mit einer UpdateInformation/Firmware/ FWVersion > aktuelle Version der Konnektor- oder Kartenterminalsoftware	Op	Info	1 day	Bedeutung= $EC.description
EC_FW_Not_ Valid_Status_ Blocked	Konnektor Firmware muss aktualisiert werden. Zugang zur TI momentan nicht erlaubt.	Sec	Fatal	1 day	Bedeutung= $EC.description
EC_Time_Sync_ Not_Successful	der letzte Synchronisationsversuch der Systemzeit war nicht erfolgreich.	Op	Info	1 sec	LastSyncAttempt= $lastSyncAttempt Timestamp; LastSyncSuccess =$lastSyncSuccess Timestamp; Bedeutung= $EC.description
EC_TSL_Update_ Not_Successful	das letzte Update der TSL war nicht erfolgreich.	Op	Info	1 sec	Bedeutung= $EC.description; LastUpdateTSL= $lastUpdateTSL Timestamp
EC_TSL_Expiring	Systemzeit t mit t > NextUpdate-Element der TSL – 7 Tage und t <= NextUpdate-Element der TSL	Sec	Info	1 day	NextUpdateTSL =$NextUpdate- Element der TSL; Bedeutung= $EC.description
EC_BNetzA_VL_ Update_ Not_Successful	Das letzte Update der BNetzA-VL war nicht erfolgreich	Op	Info	1 sec	LastUpdateBNetz AVL= $lastUpdateBNetz AVLTimestamp; Bedeutung= $EC.description
EC_ BNetzA_VL_ not_valid	Systemzeit t mit t > NextUpdate-Element der BNetzA-VL	Sec	War ning	1 day	NextUpdateBNetz AVL =$NextUpdate- Element der BNetzA-VL; Bedeutung= $EC.description
EC_TSL_Trust_ Anchor_Expiring	Gültigkeit des Vertrauensankers ist noch nicht abgelaufen, läuft aber innerhalb von 30 Tagen ab.	Sec	Info	1 day	ExpiringDateTrust Anchor= Ablaufdatum der Vertrauensanker gültigkeit; Bedeutung= $EC.description
EC_LOG_ OVERFLOW	Wenn im Rahmen der Regeln für die rollierende Speicherung von Logging-Einträgen Einträge gelöscht werden, die nicht älter als SECURITY_LOG_DAYS,  LOG_DAYS bzw. FM_ <fmName>_LOG_DAYS sind, tritt der Fehlerzustand ein. Der Fehlerzustand kann nur durch einen Administrator wieder zurückgesetzt werden. Unter Protokoll wird die Liste der auslösenden Protokolle angegeben.	Op	War ning	1 sec	Protokoll=$Protokoll; Bedeutung= $EC.description
EC_CRL_Expiring	Systemzeit t > NextUpdate der CRL – 3 Tage	Sec	War ning	1 day	ExpiringDateCRL= NextUpdate der CRL; Bedeutung= $EC.description
EC_Time_Sync_ Pending_Warning	MGM_LU_ONLINE=Enabled und keine erfolgreiche Synchronisation der Systemzeit seit d Tagen und d > NTP_WARN_PERIOD und d <= NTP_GRACE_PERIOD. Nach einer Korrektur oder Bestätigung der Systemzeit durch einen Administrator muss der Konnektor wie nach einer erfolgreichen Zeitsynchronisation verfahren, d.h., der Tagezähler wird auf 0 zurückgesetzt.	Sec	War ning	1 day	LastSyncSuccess= $lastSyncSuccess Timestamp; Bedeutung= $EC.description
EC_TSL_Out_ Of_Date_Within_ Grace_Period	Systemzeit t mit t > NextUpdate-Element der TSL und t <= NextUpdate-Element der TSL + CERT_TSL_ DEFAULT_GRACE_ PERIOD_DAYS und eine neue TSL ist nicht verfügbar	Sec	War ning	1 day	NextUpdateTSL =$NextUpdate- Element der TSL; GracePeriodTSL =CERT_TSL_ DEFAULT_ GRACE_PERIOD_ DAYS; Bedeutung= $EC.description
EC_CardTerminal_ Not_Available ($ctId)	Kartenterminal($ctId) ist nicht verfügbar. Dieser Betriebszustand bezieht sich auf die als „aktiv“ gekennzeichneten KTs.	Op	Error	1 sec	CtID=$ctId; Bedeutung= $EC.description
EC_No_VPN_TI_ Connection	Kein sicherer Kanal (VPN) in die Telematikinfrastruktur aufgebaut. Der Wert 300 sec ist abgeleitet aus der maximalen Verbindungsaufbauzeit bei einem Standortausfall des VPN-Zugangsdienstes.	Op	Error	300 sec	Bedeutung= $EC.description
EC_No_VPN_ SIS_Connection	Kein sicherer Kanal (VPN) zu den Sicheren Internet Services aufgebaut. Der Wert 300 sec ist abgeleitet aus der maximalen Verbindungsaufbauzeit bei einem Standortausfall des VPN-Zugangsdienstes.	Op	Error	300 sec	Bedeutung= $EC.description
EC_No_Online_ Connection	Konnektor kann Dienste im Transportnetz nicht erreichen.	Op	Error	10 sec	Bedeutung= $EC.description
EC_IP_Adresses_ Not_Available	Die IP-Adressen des Netzkonnektors sind nicht oder falsch gesetzt.	Sec	Error	1 sec	Bedeutung= $EC.description
EC_CRL_Out_Of_ Date	Systemzeit t > Next Update der CRL	Sec	Fatal	1 day	NextUpdateCRL= $NextUpdate der CRL; Bedeutung= $EC.description
EC_Firewall_Not_ Reliable	Firewall-Regeln konnten nicht fehlerfrei generiert werden oder beim Laden der Firewall-Regeln ist ein Fehler aufgetreten.	Sec	Fatal	1 sec	Bedeutung= $EC.description
EC_Random_ Generator_ Not_Reliable	Der Zufallszahlengenerator kann die Anforderungen an die zu erzeugende Entropie nicht erfüllen.	Sec	Fatal	1 sec	Bedeutung= $EC.description
EC_Secure_ KeyStore_ Not_Available	Sicherer Zertifikats- und Schlüsselspeicher des Konnektors (gSMC-K oder Truststore) nicht verfügbar	Sec	Fatal	1 sec	Bedeutung= $EC.description
EC_Security_ Log_ Not_Writable	Das Sicherheitslog kann nicht geschrieben werden.	Op	Fatal	1 sec	Bedeutung= $EC.description
EC_Software_ Integrity_ Check_Failed	Eine oder mehrere konnektorinterne Integritätsprüfungen der aktiven Konnektorbestandteile sind fehlgeschlagen.	Sec	Fatal	1 day	Bedeutung= $EC.description
EC_Time_ Difference_ Intolerable	Abweichung zwischen der lokalen Zeit und der per NTP empfangenen Zeit bei der Zeitsynchronisation größer als NTP_MAX_ TIMEDIFFERENCE. Nach einer Korrektur oder Bestätigung der Systemzeit durch einen Administrator muss der Konnektor den Fehlerzustand zurücksetzen.	Sec	Fatal	1 sec	NtpTimedifference= Zeitabweichung; NtpMaxAllowed Timedifference =NTP_MAX_ TIMEDIFFERENCE; Bedeutung= $EC.description
EC_Time_Sync_ Pending_Critical	MGM_LU_ONLINE= Enabled und keine erfolgreiche Synchronisation der Systemzeit seit d Tagen und d > NTP_GRACE_PERIOD Nach einer Korrektur oder Bestätigung der Systemzeit durch einen Administrator muss der Konnektor wie nach einer erfolgreichen Zeitsynchronisation verfahren, d.h., der Tagezähler wird auf 0 zurückgesetzt.	Sec	Fatal	1 day	LastSyncSuccess =$lastSync SuccessTimestamp; NtpGracePeriod= NTP_GRACE_ PERIOD; Bedeutung= $EC.description
EC_TSL_Trust_ Anchor_ Out_Of_Date	Gültigkeit des Vertrauensankers ist abgelaufen	Sec	Fatal	1 day	ExpiringDateTrust Anchor= Ablaufdatum der Vertrauensanker gültigkeit; Bedeutung= $EC.description
EC_TSL_Out_ Of_Date_ Beyond_Grace_ Period	Systemzeit t mit t > NextUpdate-Element der TSL + CERT_TSL_DEFAULT_ GRACE_ PERIOD_DAYS und eine neue TSL ist nicht verfügbar	Sec	Fatal	1 day	NextUpdateTSL =$NextUpdate- Element der TSL; GracePeriodTSL =CERT_TSL_ DEFAULT_ GRACE_PERIOD_ DAYS; Bedeutung= $EC.description
EC_ CRYPTOP ERATION_ ALARM	Gemäß TIP1-A_4597 wurde ein potentieller Missbrauch einer Kryptooperation erkannt. Nur der Administrator kann die Alarmmeldung zurücksetzen.	Sec	War ning	1 min	Operation= $Operationsname; Count=$Summenwert; Arbeitsplatz= $<Liste operationsaufrufenden workplaceIDs>;     Meldung= ’Auffällige Häufung von Operationsaufrufen in den letzten 10 Minuten’
EC_OTHER_ ERROR_ STATE($no)	Herstellerspezifische Fehlerzustände, die per $no (von 1 aufsteigend nummeriert) identifiziert werden. $Type, $Severity und $ParameterList legt der Hersteller nach Bedarf fest.	$Type	$Sev erity	<= 1 day	Bedeutung= $EC.description
EC_NK_Certificate_Expiring	Das C.NK.VPN-Zertifikat läuft bald ab.  Systemzeit t > (Ablaufdatum von C.NK.VPN – 180 Tage)	Sec	Warning	1 day	Iccsn=$Iccsn; Serial=$Serialnumber; Bedeutung= $EC.description
EC_NK_Certificate_Expired	Das C.NK.VPN-Zertifikat ist abgelaufen. Systemzeit t > Ablaufdatum von C.NK.VPN	Sec	Fatal	1 day	Iccsn=$Iccsn; Serial=$Serialnumber; Bedeutung= $EC.description
EC_TLS_Client_Certificate_Security	Das für die Authentifizierung gegenüber dem Clientsystem konfigurierte Zertifikat hat ein Sicherheitsniveau von weniger als 120bit. Zu verwenden ist ein RSA -Zertifikat mit mindestens 3000 bit Schlüssellänge oder ein ECC Zertifikat.	Sec	Info	1 day	Bedeutung= $EC.description

Erläuterungen zu TAB_KON_503:

Hinweis 1:
Jeder Fehlerzustand wird durch einen eindeutigen ErrorCondition identifiziert. Dieser kann einen Parameter enthalten. Sind etwa die Kartenterminals mit ctId=47 und das mit ctId=93 nicht erreichbar, so lauten die ErrorCondition „EC_CardTerminal_Not_Available(47)“ und „EC_CardTerminal_Not_Available(93)“.

Hinweis 2:
EC.description referenziert den Text, der in der Spalte „Beschreibung“ des Zustandes spezifiziert wurde.
Hinweis 3:
Beim Absetzen und Subskribieren folgender EventTopics gelten zusätzliche Vorgaben:
- EC_CardTerminal_Software_Out_Of_Date ($ctId)
- EC_CardTerminal_gSMC-KT_Certificate_Expires_Soon ($ctId)
- EC_CardTerminal_Not_Available ($ctId)
- EC_OTHER_ERROR_STATE($no)
Beim Absetzen des Systemereignises muss die Schreibweise der obigen EventTopics hinsichtlich der Position der Klammer strikt den Vorgaben aus der Tabelle TAB_KON_503 entsprechen.
Beim Subskribieren der Systemereignisse bei obigen EventTopics muss beliebige Schreibweise im Bezug auf Whitespaces vor und nach den Klammern vom Konnektor toleriert werden.
Wenn obige EventTopics ohne Parameter in Klammern subskribiert werden, so muss der Konnektor das Systemereignis an den Client für jede $ctId bzw. $no absetzen.

[<=]

Unter „kartenbasiert“ sind nicht nur Lösungen mit Smartcards sondern auch solche mit HSMs (Hardware Security Modules) zu verstehen.

A_17085 - Bedingung für den Fehlerzustand EC_No_VPN_TI_Connection

Wenn MGM_LU_ONLINE=Enabled nicht erfüllt ist, DARF der Konnektor den Zustand EC_No_VPN_TI_Connection NICHT annehmen. [<=]

A_17086 - Bedingung für den Fehlerzustand EC_No_VPN_SIS_Connection

Wenn MGM_LU_ONLINE=Enabled oder ANLW_INTERNET_MODUS=SIS nicht erfüllt ist, DARF der Konnektor den Zustand EC_No_VPN_SIS_Connection NICHT annehmen. [<=]

A_17087 - Bedingung für den Fehlerzustand EC_No_Online_Connection

Wenn MGM_LU_ONLINE=Enabled nicht erfüllt ist, DARF der Konnektor den Zustand EC_No_Online_Connection NICHT annehmen. [<=]

A_22970 - Bedingung für den Betriebszustand EC_NK_Certificate_Expiring

Der Konnektor MUSS 180 Tage vor Ablauf des aktuell verwendeten C.NK.VPN-Zertifikats in den Zustand EC_NK_Certificate_Expiring wechseln.
[<=]

A_22971 - Bedingung für den Betriebszustand EC_NK_Certificate_Expired

Der Konnektor MUSS mit dem Ablauf des aktuell verwendeten C.NK.VPN-Zertifikats in den Zustand EC_NK_Certificate_Expired wechseln.
[<=]

Tabelle 8: TAB_KON_504-01 Ausführungserlaubnis für Dienste in kritischen Fehlerzuständen 

EC_ Software_ Integrity_ Check_ Failed

EC_ Random_ Generator_ Not_ Reliable

EC_ Security_ Log_ Not_ Writable

EC_ Time_ Sync_ Pending_ Critical

EC_ Time_ Diffe rence_ Intoler able

EC_ CRL_ Out_ Of_ Date

EC_ TSL_ Out_ Of_ Date_ Beyond_ Grace_ Period

EC_ TSL_ Trust_ Anchor_ Out_ Of_ Date

EC_ Secure_ KeyStore_ Not_ Available

EC_ FW_ Not_ Valid_ Status_ Blocked

EC_ NK_ Certificate_ Expired

Technische Use Cases (TUCs) der Basisdienste relevant für Fachanwendung und die Kommunikation mit Weiteren Anwendungen und SIS

Zugriffsberechtigungsdienst

TUC_KON_000 Prüfe Zugriffsberechtigung

-

x

x

x

x

x

x

x

x

x

x

Dienstverzeichnisdienst

TUC_KON_041 Einbringen der Endpunktinformationen während der Bootup-Phase

-

-

-

x

x

x

x

x

x

x

x

Kartenterminaldienst

TUC_KON_051 Mit Anwender über Kartenterminal interagieren

-

-

-

-

-

x

x

x

-

x

-

Kartendienst

TUC_KON_005 Card-to-Card authentisieren

-

-

-

-

-

x

x

x

-

x

-

TUC_KON_006 Datenzugriffsaudit eGK schreiben

-

-

-

-

-

x

x

x

-

x

-

TUC_KON_018 eGK-Sperrung prüfen

-

-

-

-

-

x

x

x

-

x

-

TUC_KON_024 Karte zurücksetzen

-

-

-

-

-

x

x

x

-

x

-

TUC_kON_026 Liefere CardSession

-

-

-

-

-

x

-

x

-

-

-

TUC_KON_200 SendeAPDU

-

-

-

-

-

x

x

x

-

x

-

TUC_KON_202 LeseDatei

-

-

-

-

-

x

x

x

-

x

-

TUC_KON_203 SchreibeDatei

-

-

-

-

-

x

x

x

-

x

-

TUC_KON_209 LeseRecord

-

-

-

-

-

x

x

x

-

x

-

Systeminformationsdienst

TUC_KON_256 Systemereignis absetzen

-

x

x

x

x

x

x

x

x

x

x

Verschlüsselungsdienst

TUC_KON_072 Daten symmetrisch verschlüsseln

-

-

-

x

x

x

x

x

-

x

-

TUC_KON_073 Daten symmetrisch entschlüsseln

-

-

-

x

x

x

x

x

-

x

-

Zertifikatsdienst

TUC_KON_034 Zertifikatsinformationen extrahieren

-

-

-

x

x

x

x

x

-

x

x

Protokollierungsdienst

TUC_KON_271 Schreibe Protokolleintrag

-

x

x

x

x

x

x

x

x

x

x

TLS-Dienst

TUC_KON_110 Kartenbasierte TLS-Verbindung aufbauen

-

-

-

-

-

-

-

-

-

-

-

Verbindung zum VPN-Konzentrator

TUC_VPN-ZD_0001 „IPsec Tunnel TI aufbauen”

-

-

-

-

-

-

-

-

-

-

-

TUC_VPN-ZD_0002 „IPsec Tunnel SIS aufbauen”

-

-

-

-

-

-

-

-

-

-

-

Laufzeitverlängerung gSMC-K)

TUC_KON_410 „gSMC-K-Zertifikate aktualisieren (automatisch)

-

-

-

-

-

-

-

-

-

-

-

TUC_KON_410 „gSMC-K-Zertifikate aktualisieren (manuell)

-

-

-

-

-

-

-

-

-

-

x

TUC_KON_411 „Konnektor mit neuem NK-Zertifikat registrieren (automatisch)

-

-

-

-

-

-

-

-

-

-

-

TUC_KON_411 „Konnektor mit neuem NK-Zertifikat registrieren (manuell)

-

-

-

-

-

-

-

-

-

-

x

Operationen der Basisdienste

Kartendienst

VerifyPin

-

-

-

-

-

x

x

x

-

x

-

UnblockPin

-

-

-

-

-

x

x

x

-

x

-

ChangePin

-

-

-

-

-

x

x

x

-

x

-

GetPinStatus

-

-

-

-

-

x

x

x

-

x

-

Systeminformationsdienst

Schnittstelle der Ereignissenke

-

x

x

x

x

x

x

x

x

x

x

GetCardTerminals

-

x

x

x

x

x

x

x

x

x

-

GetCards

-

x

x

x

x

x

x

x

x

x

-

GetResourceInformation

-

x

x

x

x

x

x

x

x

x

-

Subscribe

-

x

x

x

x

x

x

x

x

x

-

RenewSubscription

-

x

x

x

x

x

x

x

x

x

-

Unsubscribe

-

x

x

x

x

x

x

x

x

x

-

GetSubscription

-

x

x

x

x

x

x

x

x

x

-

Verschlüsselungsdienst

EncryptDocument

-

-

-

-

-

x

x

x

-

x

-

DecryptDocument

-

-

-

-

-

x

x

x

-

x

-

Signaturdienst

SignDocument

-

-

-

-

-

x

x

x

-

x

-

VerifyDocument

-

-

-

-

-

x

x

x

-

x

-

GetJobNumber

-

-

-

-

-

x

x

x

-

x

-

StopSignature

-

-

-

-

-

x

x

x

-

x

-

ActivateComfortSignature

-

-

-

-

-

x

x

x

-

x

-

DeactivateComfortSignature

-

-

-

-

-

x

x

x

-

x

-

GetSignatureMode

-

-

-

-

-

x

x

x

-

x

-

Authentifizierungsdienst

ExternalAuthenticate

-

-

-

-

-

x

x

x

-

x

-

Zertifikatsdienst

ReadCardCertificate

-

-

-

-

-

x

x

x

x

x

-

CheckCertificateExpiration

-

-

-

-

-

x

x

x

x

x

-

VerifyCertificate

-

-

-

-

-

x

-

x

x

x

-

Zeitdienst

I_NTP_Time_Information

-

-

-

-

-

x

x

x

x

-

-

Konnektormanagement

Softwareaktualisierung

x

x

x

x

x

x

x

x

x

x

x

Protokolleinsicht

x

x

x

x

x

x

x

x

x

x

x

Werksreset

x

x

x

x

x

x

x

x

x

x

x

Sonstiges

-

x

x

x

x

x

x

x

x

x

x

In den kritischen Fehlerzuständen, in denen keine TLS-Verbindung ins LAN aufgebaut werden (EC_Random_Generator_Not_Reliable, EC_Software_Integrity_Check_Failed, EC_Security_Log_Not_Writable, EC_Time_Sync_Pending_Critical, EC_Time_Difference_Intolerable, EC_NK_Certificate_Expired), kann keine Verbindung zu den Kartenterminals aufgebaut werden. Infolge sind hier keine Kartenoperationen zugelassen.

Wenn keine Verbindung zum VPN-Konzentrator des SIS aufgebaut werden kann, ist dadurch das Internet nicht über den Konnektor erreichbar. Wenn keine Verbindung zum VPN-Konzentrator der TI aufgebaut werden kann, sind Bestandsnetze nicht erreichbar.

Bezüglich der Administration des Konnektors im Zustand EC_FIREWALL_NOT_RELIABLE ist eine Abstimmung mit der Prüfstelle und der Zertifizierungsstelle notwendig.

A_16203 - Nutzbarkeit im Zustand EC_FIREWALL_NOT_RELIABLE

Im Zustand EC_Firewall_Not_Reliable DARF der Konnektor NICHT nutzbar sein. Möglichkeiten zur Behebung des Zustandes EC_Firewall_Not_Reliable sind mit dem CC - Evaluierer und Zertifizierer abzustimmen. [<=]

Die Architektur der TI ist so angelegt, dass die Fehlerzustände mit Severity=Fatal in den Tabellen TAB_KON_504 und TAB_KON_503 mit vernachlässigbarer Wahrscheinlichkeit von externen Einflüssen abhängen. Die SLAs für Dienste der zentralen TI-Plattform sind so gefasst, dass diese schwerwiegend verletzt werden müssten, um dadurch einen Konnektor in einen solchen kritischen Zustand zu bringen (externer Fehler aus Sicht des Konnektors). Dass beispielsweise der TSL-Dienst über den Zeitraum der Grace-Period-TSL (typisch: 7 Tage) nicht erreichbar ist (ErrorCondition EC_TSL_Out_Of_Date _Beyond_Grace_Period), kann nur bei massiver Verletzung der für zentrale Dienste festgelegten SLAs eintreten.

Um die konnektorinternen Fehlerquellen zu erfassen, die dazu führen, dass ein Fehlerzustand mit Severity=Fatal eintritt oder ein anderer Zustand, in dem der Konnektor nicht verwendbar ist, wird Folgendes gefordert:

TIP1-A_5148 - Performance - Konnektor - Mittlerer Abstand zwischen Ausfällen

Der Konnektorhersteller MUSS den mittleren Zeitabstand zwischen Ausfällen (MTBF) als Produkteigenschaft ausweisen. Der Konnektor soll einen mittleren Zeitabstand zwischen Ausfällen (MTBF) von mindestens 50 Jahren haben.

Ein „Ausfall“ gilt dann als eingetreten, wenn

• der Konnektor nicht mehr gebootet werden kann, d. h. kein „BOOTUP/BOOTUP_COMPLETE“ Event ausgelöst wird, und dies nicht auf einen externen Fehler zurückzuführen ist,
• oder sich der Konnektor in einem Fehlerzustand mit Severity=Fatal befindet, der nicht auf einen externen Fehler zurückzuführen ist,
• oder Funktionen des Konnektors ausgefallen sind, ohne dass dies auf externe Fehler zurückzuführen ist.

[<=]

Bei einem mittleren Zeitabstand zwischen Ausfällen (MTBF) von 50 Jahren ist die Wahrscheinlichkeit, dass ein Fehlerzustand mit Severity=Fatal auftritt, kleiner 2 % pro Jahr.

TIP1-A_4510-05 - Sicherheitskritische Fehlerzustände

Der Konnektor MUSS bei eingetretenem Fehlerzustand aus Tabelle Tab_ Kon_503 Betriebszustand_Fehlerzustandsliste mit Severity=Fatal dafür sorgen, dass von den Operationen der Basisdienste und Technische Use Cases (TUCs) der Basisdienste, die relevant für Fachanwendungen sind, nur erlaubte Operationen und TUCs gestartet und ausgeführt werden.
Welche Operationen und TUCs je eingetretenem Fehlerzustand ausgeführt werden dürfen, legt Tabelle „TAB_KON_504-01 Ausführungserlaubnis für Dienste in kritischen Fehlerzuständen“ fest: Jede Erlaubnis ist dort durch ein „x“ definiert.
Abweichend zu Angaben in der Tabelle TAB_KON_504-01 DÜRFEN folgende Operationen und TUCs NICHT im Zustand EC_Firewall_Not_Reliable ausgeführt werden:

• TUC_KON_000 PrüfeAufrufkontext
• TUC_KON_041 Einbringen der Endpunktinformationen während der Bootup-Phase
• GetCardTerminals
• GetCards
• GetResourceInformation
• Subscribe
• RenewSubscription
• Unsubscribe
• GetSubscription
• ReadCardCertificate
• CheckCertificateExpiration
• VerifyCertificate

Sind mehrere Fehlerzustände gleichzeitig eingetreten, dürfen nur die Operationen und TUCs ausgeführt werden, die für alle eingetretenen Fehlerzustände erlaubt sind. Der Konnektor MUSS Anfragen, die auf Grund eines kritischen Fehlerzustandes nicht ausgeführt oder abgebrochen werden, mit einem Fehler (Fehlercode 4002) beantworten.
 

Tabelle 9: TAB_KON_502 Fehlercodes „Betriebszustand“

Fehlercode	ErrorType	Severity	Fehlertext
4002	Security	Fatal	Der Konnektor befindet sich in einem kritischen Betriebszustand

[<=]

3.4.1 Betriebsaspekte

Der Konnektor soll per Signaleinrichtung am Konnektor die Fehlerzustände mit Severity „Error“ und „Fatal“ anzeigen (siehe [TIP1-A_4843]).

TIP1-A_4513 - Betriebszustände anzeigen und Fehlerzustände zurücksetzen

Der Konnektor MUSS es dem Administrator ermöglichen, den aktuellen Betriebszustand einzusehen und Fehlerzustände zurückzusetzen, soweit diese Möglichkeit in Tabelle „TAB_KON_503 Betriebszustand_Fehlerzustandsliste“ für den jeweiligen Fehlerzustand festgelegt ist.

Ferner MUSS es die Managementschnittstelle dem Administrator ermöglichen, Konfigurationsänderungen gemäß Tabelle TAB_KON_505 vorzunehmen:

Tabelle 10: TAB_KON_505 Konfigurationswerte Missbrauchserkennung

ReferenzID	Belegung	Bedeutung und Administrator-Interaktion
EVT_MONITOR_OPERATIONS	Liste von: - Operationsname - OK_Val (Nummer) - NOK_Val (Nummer) - Alarmwert (Nummer)	Der Administrator MUSS in der Liste der zur Missbrauchserkennung überwachbaren Operationen alle Listeneinträge einsehen können. Er MUSS den jeweiligen Alarmwert editieren können (0-9999, 0=deaktiviert). OK_VAL und NOK_VAL DÜRFEN durch den Administrator NICHT veränderbar sein.

 

[<=]

A_21759 - Erneuerte ID.AK.AUT für Authentisierung des Konnektors gegenüber Clientsystemen verwenden

Der Konnektor MUSS dem Administrator das Einschalten der Verwendung von erneuerten C.AK.AUT für die Authentisierung des Konnektors gegenüber den Clientsystemen über das Managementinterface ermöglichen. 
Der Konnektor DARF ein erneuertes C.AK.AUT NICHT automatisch verwenden. [<=]

3.5 Fachliche Anbindung der Clientsysteme

Für die Schnittstellen des Konnektors zu den Clientsystemen kann gesteuert werden:

• ob die Kommunikation zwischen Konnektor und Clientsystemen hinsichtlich Vertraulichkeit, Integrität und Authentizität zwingend durch TLS gesichert werden muss
• ob sich Clientsysteme zwingend authentisieren müssen
• welche Clientsysteme auf den Konnektor zugreifen dürfen

Dabei werden die folgenden zwei Nutzungsszenarien nicht unterschieden:

• Nutzung von Fachanwendungen (in Form von Fachmodulen)
• Nutzung von Basisdiensten des Konnektors

Sowohl die Anbindung zur Administration des Konnektors, als auch die Anbindung zur Nutzung von Bestandsnetzen oder dem gesicherten Internetzugang sind nicht Gegenstand dieser Schnittstellenfestlegungen. Für die Anbindung zu Administration wird diese im Kapitel Konnektormanagement beschrieben, für die Anbindung von Bestandsnetzen bzw. dem gesicherten Internetzugang ist diese Art der Regelung nicht erforderlich, da es sich dort um Routing-Funktionen handelt.

Die seitens des Administrators einstellbaren Werte und Listen sind, der allgemeinen Struktur dieses Dokuments folgend, im Unterkapitel 3.4.1 Betriebsaspekte beschrieben.

TIP1-A_4514-01 - Verfügbarkeit einer TLS-Schnittstelle

Der Konnektor MUSS TLS in Richtung der Clientsysteme für alle Außenschnittstellen der Basisdienste:

• Dienstverzeichnisdienst
• Kartenterminaldienst
• Systeminformationsdienst
• Verschlüsselungsdienst
• Signaturdienst 
• Zertifikatsdienst 
• Kartendienst
• LDAP-Proxy

unterstützen.
Ferner MUSS der Konnektor für die SOAP-Endpunkte der Fachmodule TLS unterstützen.
Der Konnektor MUSS sich mittels ID.AK.AUT oder dem gemäß A_21699-* erzeugten oder dem gemäß A_21697-* importierten Zertifikat gegenüber dem ClientClientsystem authentisieren.
[<=]

TIP1-A_4515 - Verpflichtung zur Nutzung der TLS-Verbindung

Der Konnektor MUSS immer TLS-Verbindungsanfragen von Clientsystemen annehmen.

Der Konnektor MUSS bei gesetzter Variable ANCL_TLS_MANDATORY = Enabled den Verbindungsversuch von Clientsystemen ohne TLS ablehnen. Ausgenommen hiervon sind Anfragen an den Dienstverzeichnisdienst bei gesetzter Variable ANCL_DVD_OPEN = Enabled.

[<=]

TIP1-A_4516 - Authentifizierung der Clients über Basic-Auth und X.509-Zertifikate

Der Konnektor MUSS zur Client-Authentifizierung die Verfahren Basic Authentication (Username/Password) [RFC2617] über HTTP/TLS [RFC2818] und zertifikatsbasierte Client-Authentifizierung (X.509) [gemSpec_PKI#8.3.1.4] über TLS anbieten.
Dabei MUSS für eine erfolgreiche Prüfung bei Basic Authentication:

• das seitens des Clientsystems präsentierte Credential in ANCL_CUP_LIST enthalten sein

Für eine erfolgreiche Prüfung mit zertifikatsbasierter Client-Authentifizierung MUSS:

• das seitens des Clientsystems präsentierte Zertifikat in ANCL_CCERT_LIST enthalten sein
• die Zertifikatsprüfung (nur Prüfung auf „mathematische Korrektheit“ und „Gültigkeit nicht abgelaufen“) erfolgreich durchlaufen werden

Schlägt die Prüfung fehl, MUSS der Verbindungsversuch des Clientsystem abgelehnt werden. [<=]

Bei der Authentisierung des Clientsystems geht es um eine Authentisierung in zwei Richtungen:

1. Authentisierung des Clientsystems in der Rolle eines Clients gegenüber dem Konnektor für die Übertragung von SOAP-Requests.
2. Authentisierung des Clientsystems in der Rolle eines Servers gegenüber dem Konnektor zum Empfang von CETP-Ereignismitteillungen des Systeminformationsdienstes.

Für beide Richtungen kann das Clientsystem dasselbe Zertifikat verwenden.

TIP1-A_5009 - Authentifizierungsvarianten für Verbindungen zwischen Konnektor und Clientsystemen

Der Konnektor MUSS für Verbindungen zu Clientsystemen als Authentifizierungsmethode ausschließlich folgende Varianten erlauben:

1. Für Verbindungen mit dem Konnektor in der Rolle des Servers (SOAP-Requests):
   • TLS-Server-Authentifizierung des Konnektors und TLS-Client-Authentifizierung des Clientsystems
   • TLS-Server-Authentifizierung des Konnektors und BasicAuthentifizierung des Clientsystems
   • TLS-Server-Authentifizierung des Konnektors ohne TLS-Client-Authentifizierung des Clientsystems
   • Keine Authentifizierung des Konnektors und des Clientsystems

1. Für Verbindungen mit dem Konnektor in der Rolle des Clients (CETP-Protokoll):
   • TLS-Server-Authentifizierung des Clientsystems und TLS-Client-Authentifizierung des Konnektors
   • TLS-Server-Authentifizierung des Clientsystems ohne TLS-Client-Authentifizierung des Konnektors
   • Keine Authentifizierung des Konnektors und des Clientsystems

Alle anderen Verbindungsversuche von Clientsystemen MÜSSEN vom Konnektor abgelehnt werden.
[<=]

Für die Anbindung der Clientsysteme ergeben sich verschiedene Konfigurationsvarianten bezüglich der Absicherung der Verbindungen zwischen Konnektor und Clientsystemen. Tabelle TAB_KON_852 listet die Varianten für die Verbindungen zum Aufruf der WebService-Schnittstellen (Varianten SOAP1 bis SOAP4), für die Verbindungen zum Senden von Events (Varianten CETP1 und CETP2) und für Verbindungen zum Abruf des Dienstverzeichnisses (Varianten DVD1, DVD2 und DVD3).

Tabelle 11: TAB_KON_852 Konfigurationsvarianten der Verbindungen zwischen Konnektor und Clientsystemen 

Konfigu- rations- variante	ANCL_ TLS_ MAN- DATORY	ANCL_ CAUT_ MAN- DATORY	ANCL_ CAUT_ MODE	ANCL_ DVD_ OPEN	Bedeutung
CETP1	Enabled	Irrelevant	Irrelevant	Irrelevant	Der Konnektor sendet Events ausschließlich über TLS. Er authentisiert sich, wenn ihn das Clientsystem im Rahmen des TLS-Handshakes dazu auffordert.
CETP2	Disabled	Irrelevant	Irrelevant	Irrelevant	Der Konnektor sendet Events immer über eine TCP-Verbindung ohne TLS.
SOAP1	Enabled	Enabled	CERTIFICATE	Irrelevant	Der Konnektor akzeptiert vom Clientsystem nur Aufrufe über TLS. Der Konnektor verlangt beim TLS-Handshake die Authentisierung des Clientsystems per Zertifikat.
SOAP2	Enabled	Enabled	PASSWORD	Irrelevant	Der Konnektor akzeptiert vom Clientsystem nur Aufrufe über TLS.  Der Konnektor prüft auf Anwendungsebene, dass Aufrufer sich per Username/Password  [RFC2617] authentisieren.
SOAP3	Enabled	Disabled	Irrelevant	Irrelevant	Der Konnektor akzeptiert vom Clientsystem nur Aufrufe über TLS.  Der Konnektor nimmt keine Clientauthentifizierung vor.
SOAP4	Disabled	Irrelevant	Irrelevant	Irrelevant	Der Konnektor akzeptiert vom Clientsystem sowohl Aufrufe ohne TLS als auch über TLS. Im zweiten Fall sollte der Konnektor das Clientsystem nicht authentifizieren, wenn er es aber für den Sonderfall ANCL_CAUT_MANDATORY=Enabled aktuell tut, sehen wir das nicht als Fehler.
DVD1	Irrelevant	Irrelevant	Irrelevant	Enabled	Zugriff auf Dienstverzeichnisdienst kann über HTTP und HTTPS erfolgen.
DVD2	Enabled	*	*	Disabled	Zugriff auf Dienstverzeichnisdienst kann nur über HTTPS erfolgen. *) Bzgl. Clientauthentisierung wirken die Schalter wie in SOAP 1, SOAP 2, SOAP 3
DVD3	Disabled	Irrelevant	Irrelevant	Disabled	Zugriff auf Dienstverzeichnisdienst kann über HTTP und HTTPS erfolgen.

Client-Authentisierung bei Nutzung des LDAP-Proxy

Für die Nutzung des LDAP-Proxy gelten abweichende Festlegungen, da viele Standard LDAP- / Mail-Clients grundsätzlich keine Funktion zur Client-Authentisierung anbieten. Um die Nutzung des LDAP-Proxy und somit des VZD der TI dennoch zu ermöglichen, ohne dabei auf eine verpflichtende Client-Authentisierung für SOAP-Aufrufe zu verzichten, werden für LDAP gesonderte Regelungen getroffen.

A_21224-01 - Authentifizierung für Verbindungen zwischen Konnektor und Clientsystemen bei LDAP

Bei der Verwendung  des LDAP-Proxies im Konnektor, MUSS sich der Konnektor abhängig von der Stellung der Schalter ANCL_TLS_MANDATORY, ANCL_CAUT_MANDATORY, ANCL_CAUT_MODE und ANCL_CAUT_LDAP gemäß der Tabelle TAB_KON_865-* verhalten.

Tabelle 12: TAB_KON_865-01 Konfigurationsvarianten der Verbindungen zwischen Konnektor und Clientsystemen bei LDAP 

Konfigu- rations- variante	ANCL_ TLS_ MAN- DATORY	ANCL_ CAUT_ MAN- DATORY	ANCL_ CAUT_ MODE	ANCL_ CAUT_ LDAP	Bedeutung
LDAP1	Enabled	Enabled	Irrelevant	CERTIFICATE	Der Konnektor akzeptiert vom Clientsystem nur Aufrufe über TLS. Der Konnektor verlangt beim TLS-Handshake bei Nutzung des LDAP-Proxy die Authentisierung des Clientsystems per Zertifikat.
LDAP2	Enabled	Enabled	Irrelevant	None	Der Konnektor akzeptiert vom Clientsystem nur Aufrufe über TLS.  Der Konnektor nimmt bei Nutzung des LDAP-Proxy keine Clientauthentifizierung vor.
LDAP3	Enabled	Disabled	Irrelevant	Irrelevant	Der Konnektor akzeptiert vom Clientsystem nur Aufrufe über TLS.  Der Konnektor nimmt keine Clientauthentifizierung vor.
LDAP4	Disabled	Irrelevant	Irrelevant	Irrelevant	Der Konnektor akzeptiert vom Clientsystem sowohl Aufrufe ohne TLS als auch über TLS. Im zweiten Fall sollte der Konnektor das Clientsystem nicht authentifizieren, wenn er es aber für den Sonderfall ANCL_CAUT_MANDATORY=Enabled, ANCL_CAUT_LDAP=CERTIFICATE aktuell tut, sehen wir das nicht als Fehler.

[<=]

Aus A_21224 resultiert direkt, dass als Client-Authentisierung für LDAPS nur Client-Zertifikate unterstützt werden müssen. Die Authentisierung mit Username/Passwort wird bei LDAPS nicht unterstützt.

Es sei noch einmal betont, dass TIP1-A_5009 sich nur auf SOAP und CETP bezieht und TIP1-A_4516 das Basic-Authentication Verfahren nur für HTTP fordert.

3.5.1 Betriebsaspekte

Damit sich ein Clientsystem mittels X.509 authentisieren kann, muss es über ein entsprechendes Zertifikat verfügen. Diese Zertifikate kann der Administrator entweder mit seinen lokalen Mitteln selbst oder mittels des Konnektors erzeugen. In beiden Fällen müssen diese Zertifikate sowohl im Clientsystemen (hier zusammen mit ihren privaten Schlüsseln), als auch im Konnektor vorhanden sein.

Da es sich um eine lokal begrenzte Authentisierung im Verantwortungsbereich des Betreibers des lokalen Netzes handelt, werden keine weiteren Vorgaben zu den Schlüsselspeichern auf Clientsystemseite erhoben. Auch hinsichtlich der außerhalb des Konnektors erzeugten Zertifikate gelten keine weiteren Vorgaben. Ferner ist eine Online-Prüfung dieser Zertifikate nicht erforderlich.

TIP1-A_4517-02 - Schlüssel und X.509-Zertifikate für die Authentisierung des Clientsystems erzeugen und exportieren sowie X.509-Zertifikate importieren

Der Konnektor MUSS die Erstellung und den Export von X.509-Zertifikaten für Clientsysteme und der zugehörigen privaten Schlüssel durch den Administrator über das Managementinterface ermöglichen. Hierbei MUSS der Konnektor dem Administrator die Möglichkeit geben, das kryptographische Verfahren gemäß Tabelle TAB_KON_866 auszuwählen. Als Exportformat MUSS PKCS#12 verwendet werden. Die so erstellten Zertifikate werden zu ANCL_CCERT_LIST angefügt. 
Der Konnektor MUSS dem Administrator ferner den Import von konnektorfremden X.509-Zertifikaten für Clientsysteme über das Managementinterface ermöglichen. Die so importierten Zertifikate werden zu ANCL_CCERT_LIST angefügt. [<=]

Hinweis: In Bezug auf die Kodierung von ECC-Schlüsseln vgl. [gemSpec_Krypt#A_23511].

TIP1-A_4518-02 - Konfiguration der Anbindung Clientsysteme

Der Administrator MUSS in der Managementoberfläche die in TAB_KON_506 genannten Parameter im Managementinterface konfigurieren können.
Wird ANCL_TLS_MANDATORY auf ENABLED gewechselt, MÜSSEN alle nicht per TLS gesicherten http-Verbindungen geschlossen werden, sobald die in den Verbindungen jeweils aktuell laufenden Außenschnittstelle-Operationen abgeschlossen wurden, mit Ausnahme von http-Verbindungen zum Dienstverzeichnisdienst.
Der Konnektor MUSS den Administrator geeignet und verständlich auf seine Verantwortung für die Sicherung der Kommunikation hinweisen.

Tabelle 13: TAB_KON_506-01 Konfigurationsparameter der Clientsystem-Authentisierung 

ReferenzID	Belegung	Bedeutung und Administrator-Interaktion
ANCL_TLS_MANDATORY	Enabled/Disabled	Der Administrator MUSS die verpflichtende Verwendung eines TLS gesicherten Kanals an- und abschalten können. Wenn ANLW_ANBINDUNGS_MODUS = Parallel MUSS der Administrator vor dem Disablen von ANCL_TLS_MANDATORY einen Warnhinweis bestätigen, der ihn über die mit der Abschaltung verbundenen Risiken informiert und darlegt, dass in diesem Fall der Nutzer die Verantwortung für die Sicherstellung der vertraulichen Übertragung übernimmt. Default-Wert: Enabled
ANCL_CAUT_MANDATORY	Enabled/Disabled	Der Administrator MUSS die verpflichtende Authentifizierung der Clientsysteme an- und abschalten können. Default-Wert: Enabled
ANCL_CAUT_MODE	CERTIFICATE / PASSWORD	Der Administrator MUSS konfigurieren können, welcher Client Authentifizierungsmodus genutzt werden kann bzw. genutzt werden muss. Default-Wert: CERTIFICATE
ANCL_CAUT_LDAP	Enabled/Disabled	Der Administrator MUSS die verpflichtende Authentifizierung der Clientsysteme für die Nutzung des LDAP-Proxy an- und abschalten können. Default-Wert: Enabled
ANCL_CCERT_LIST	Liste von X.509-Zertifikaten zugeordnet zu ClientID	Liste von importierten oder vom Konnektor erzeugten X.509-Zertifikaten und dazugehörenden Clientsystem IDs. Der Administrator MUSS die Liste der Zertifikate und den zugehörenden Clientsystemen verwalten können, der Inhalt der Zertifikate MUSS menschlich lesbar dargestellt werden. Es muss für den Administrator erkennbar sein, welches kryptographische Verfahren (RSA-2048 oder ECC -256) dem jeweiligen Zertifikat zugrunde liegt.
ANCL_CUP_LIST	Liste von Benutzer/Passwort Kombinationen, zugeordnet zu ClientID	Liste von UserCredentials und dazugehörenden Clientsystem IDs. Der Administrator MUSS eine Liste von Credentials und zugehörendem Clientsystem verwalten können. Bei diesen Benutzer-/Passwortkombinationen handelt es sich nicht um personenbezogene Credentials, sondern um clientbezogene.
ANCL_DVD_OPEN	Enabled/Disabled	Der Administrator MUSS konfigurieren können, ob der Zugriff auf den Dienstverzeichnisdienst auch dann über einen ungesicherten http-Kanal erfolgen kann (ENABLED), wenn ANCL_TLS_MANDATORY = ENABLED ist. Default-Wert: Enabled

[<=]

Damit sich der Konnektor mittels X.509 gegenüber Clientsystemen authentisieren kann, muss er über ein entsprechendes Zertifikat und dazu passendes Schlüsselmaterial verfügen. Dieses Zertifikat und Schlüsselmaterial befinden sich auf der gSMC-K (ID.AK.AUT). Der Administrator hat neben der Konfiguration zur Nutzung des erneuerten C.AK.AUT , welches vom Konnektor heruntergeladen wurde, auch mehrere Möglichkeiten, die ID.AK.AUT von der gSMC-K für die Authentisierung gegenüber den Clientsystemen zu ersetzen:

• er kann ein Zertifikat und das dazugehörige Schlüsselmaterial Konnektor-extern mit seinen lokalen Mitteln erzeugen und in den Konnektor importieren oder
• er kann ein Zertifikat und das dazugehörige Schlüsselmaterial im Konnektor erzeugen und das Zertifikat ggf. aus dem Konnektor exportieren.

Da es sich um eine lokal begrenzte Authentisierung im Verantwortungsbereich des Betreibers des lokalen Netzes handelt, werden keine weiteren Vorgaben zur Erstellung und Handhabung in der LE-Umgebung der außerhalb des Konnektors erzeugten Zertifikate und Schlüssel erhoben. Eine Online-Status-Prüfung dieser Zertifikate ist nicht erforderlich und nicht vorgesehen.

A_21697-01 - Schlüsselpaar und dazugehöriges X.509-Zertifikat für Authentisierung des Konnektors gegenüber Clientsystemen importieren

Der Konnektor MUSS dem Administrator den Import eines extern generierten Schlüsselpaars und des dazugehörigen X.509-Zertifikats gemäß Tabelle TAB_KON_866 für die Authentisierung des Konnektors im Rahmen von TLS-Verbindungen gegenüber Clientsystemen über das Managementinterface ermöglichen.
[<=]

A_21811-03 - Vorgaben für generierte und importierte Schlüssel und Zertifikate

Der Konnektor MUSS bezüglich selbst generierter und importierter Schlüssel und Zertifikate für die TLS-Authentisierung gegenüber Primärsystemen und für die Authentisierung des Clientsystems sowie für die Absicherung der Managementschnittstelle die kryptographischen Vorgaben aus [gemSpec_Krypt] durchsetzen und die Verfahren gemäß Tabelle TAB_KON_866 unterstützen.

Tabelle 14 : TAB_KON_866 Unterstützte Verfahren für generierte und importierte Schlüssel und Zertifikate

Verfahren	Unterstützung
RSA-2048	KANN unterstützt werden
RSA-3072	MUSS unterstützt werden
ECC-256 mit NIST-Kurven	MUSS unterstützt werden
ECC-256 mit brainpool-Kurven	DARF NICHT unterstützt werden

Die [gemSpec_Krypt] führt RSA-3072 nicht auf, macht jedoch allgemeine Vorgaben für RSA, die analog auf RSA-3072 anzuwenden sind.
[<=]

A_24483 - 5 Jahre Laufzeit für erzeugte TLS-Zertifikate

Der Konnektor MUSS selbst erzeugte TLS-Server- und TLS-Client-Zertifikate mit einer Laufzeit von 5 Jahren versehen. [<=]

A_24484 - Anzeige Fingerprint des Konnektor-TLS-Zertifikats

Der Konnektor MUSS an der Managementschnittstelle den Fingerprint des aktiven, an der Clientsystemschnittstelle verwendeten TLS-Zertifikats des Konnektors anzeigen. Werden unterschiedliche Zertifikate für die fachliche Clientsystemschnittstelle (SOAP, LDAP, CETP) und die Managementschnittstelle verwendet, MÜSSEN beide Fingerprints angezeigt werden, wobei klar erkenntlich sein MUSS, für welche Schnittstelle der jeweilige Fingerprint gilt. [<=]

A_24794 - Anzeige Fingerprint des Konnektor-TLS-Zertifikats - einheitliche Darstellung

Der Konnektor MUSS für einen einfachen manuellen Abgleich des angezeigten Zertifikats-Fingerprints, diesen wie folgt darstellen:

• 4x4 Blöcke aus je 4 Hexadezimalzahlen
• Großbuchstaben
• Monospace-Schrift

Beispieldarstellung: 
BBBB D1C3 B327 6F64
BD7A 333F A758 6C0A
BEBB 2370 CDC8 EAE1
C005 0D2C 7415 82E9

Der Konnektor KANN zusätzlich weitere Darstellungen des Fingerprints anzeigen (bspw. als Kette). [<=]

Damit Clientsysteme einem neuen TLS-Zertifikat des Konnektors automatisch vertrauen können, muss der Konnektor den Fingerprint des neu erzeugten oder importierten Serverzertifikats an das Clientsystem melden.

A_24485 - Zertifikats-Fingerprint über Event-Service bekanntmachen

Der Konnektor MUSS beim Aktivieren eines an der Clientsystemschnittstelle verwendeten TLS-Zertifikats den Fingerprint (SHA-256 Hashwert) des neu konfigurierten Zertifikats mit folgendem Event verfügbar machen:
    topic=„MGM/TLS_CERT“;
    eventType=Op;
    severity=Info;
    parameters =(„Interface=CS_ITF; Fingerprint=$Fingerprint des TLS-Zertifikats“)
Dies gilt auch für die Aktivierung eines im Zuge der Laufzeitverlängerung heruntergeladenen erneuerten C.AK.AUT-Zertifikats.
[<=]

Damit der Betreiber und die gematik einen Einblick in die Konfiguration haben, werden die Betriebsdaten um folgende Werte erweitert:

A_24486 - Betriebsdaten für Quelle des TLS-Zertifikats des Konnektors an der Clientsystemschnittstelle

Der Konnektor MUSS über die Betriebsdaten die Quelle des aktiven TLS-Zertifikats des Konnektors an der Clientsystemschnittstelle übermitteln:
//OperatingData/Configuration/ClientConnectionMode/TlsCertSource=[SMC-K_ORIGINAL, SMC-K_RENEWED, SELFSIGNED, IMPORTED] [<=]

A_24487 - Betriebsdaten für Kryptografie des TLS-Zertifikats des Konnektors an der Clientsystemschnittstelle

Der Konnektor MUSS über die Betriebsdaten den kryptografischen Algorithmus des öffentlichen Schlüssels im aktiven TLS-Zertifikat des Konnektors an der Clientsystemschnittstelle übermitteln: 
//OperatingData/Configuration/ClientConnectionMode/TlsKeyCrypt/Algorithm= [RSA, ECC-NIST, ECC-BRAINPOOL]
//OperatingData/Configuration/ClientConnectionMode/TlsKeyCrypt/KeyLength= [256, 384, 2048, 3072] [<=]

A_21698 - Importiertes Schlüsselpaar und dazugehöriges X.509-Zertifikat für Authentisierung des Konnektors gegenüber Clientsystemen verwenden

Der Konnektor MUSS dem Administrator das Einschalten der Verwendung von importiertem Schlüsselpaar und dazugehörigem X.509-Zertifikat für die Authentisierung des Konnektors gegenüber Clientsystemen über das Managementinterface ermöglichen. [<=]

A_21699-02 - Schlüssel und X.509-Zertifikate für Authentisierung des Konnektors gegenüber Clientsystemen erzeugen

Der Konnektor MUSS die Erstellung eines Schlüsselpaars und eines dazugehörigen X.509-Zertifikats für die Authentisierung des Konnektors im Rahmen von TLS-Verbindungen gegenüber den Clientsystemen durch den Administrator über das Managementinterface ermöglichen. Hierbei MUSS der Konnektor dem Administrator die Möglichkeit geben, das kryptographische Verfahren gemäß Tabelle TAB_KON_866 auszuwählen. Ferner MUSS der Konnektor dem Administrator die Möglichkeit geben, den Hostnamen des Konnektors im Zertifikat zu vergeben.
[<=]

A_21701 - X.509-Zertifikate für Authentisierung des Konnektors gegenüber Clientsystemen exportieren

Der Konnektor MUSS dem Administrator den Export von intern generierten X.509-Zertifikaten, die für die Authentisierung des Konnektors im Rahmen von TLS-Verbindungen gegenüber den Clientsystemen verwendet werden,  über das Managementinterface ermöglichen. Der private Schlüssel verbleibt im Konnektor. [<=]

A_21702 - Intern generierte Schlüssel und X.509-Zertifikate für Authentisierung des Konnektors gegenüber Clientsystemen verwenden

Der Konnektor MUSS dem Administrator das Einschalten der Verwendung von intern generierten Schlüsseln und X.509-Zertifikaten für die Authentisierung des Konnektors gegenüber den Clientsystemen über das Managementinterface ermöglichen. [<=]

A_21760-01 - ID.AK.AUT auf gSMC-K für Authentisierung des Konnektors gegenüber Clientsystemen verwenden

Der Konnektor MUSS dem Administrator das Einschalten der Verwendung von ID.AK.AUT auf der gSMC-K für die Authentisierung des Konnektors gegenüber den Clientsystemen über das Managementinterface ermöglichen. Der Konnektor MUSS dabei zur Auswahl das RSA-Zertifikat C.AK.AUT.R2048 und (falls personalisiert) das ECC-Zertifikat C.AK.AUT2.XXXX anbieten. Das ausgewählte Zertifikat MUSS sowohl für die Serveridentität an der SOAP-Schnittstelle als auch für die Clientidentität an der CETP-Schnittstelle verwendet werden.
[<=]

A_22894-01 - Handbuch Erläuterungen zur Zertifikatsauswahl

Der Hersteller des Konnektors MUSS im Administratorhandbuch erläutern, welche Abhängigkeiten die unterschiedlichen Konfigurationen zur Zertifikatsauswahl (importierte oder exportierte Zertifikate, Verwendung von ID.AK.AUT) zur Authentisierung gegenüber den Clientsystemen zu beachten sind. [<=]

A_23549 - Unterstützung der importierten TI-Zertifikate

Der Konnektor MUSS für die Authentifizierung von Clientsystemen im Rahmen des TLS-Verbindungsaufbaus auch Zertifikate aus dem TI-Vertrauensraum für Clients akzeptieren und importieren und diese für diesen Anwendungsfall analog zu lokal im Konnektor erzeugten oder importierten Nicht-TI-Zertifikaten behandeln. [<=]

Hinweis: Der letzte Teilsatz bezieht sich auf die Prüfung der Zertifikate, die in diesem konkreten Anwendungsfall nicht vollständig entsprechend TUC_KON_037 stattfinden muss, nur weil es sich um ein Zertifikat aus der TI-PKI handelt.

3.6 Clientsystemschnittstelle

TIP1-A_5401 - Parallele Nutzbarkeit Clientsystemschnittstelle

Alle Schnittstellen, die der Konnektor den Clientsystemen zur Verfügung stellt, MÜSSEN parallel durch mehrere Aufrufer nutzbar sein.
[<=]

3.6.1 SOAP-Schnittstelle

Für die Beschreibung der SOAP-Schnittstelle zum Clientsystem wird in dieser Spezifikation WSDL Version 1.1 [WSDL1.1] eingesetzt. Die Interoperabilität zwischen verschiedenen SOAP-Implementierungen wird durch die Vorgaben des WS-I Basic Profile erreicht.

A_15601 - SOAP für Web-Services der Basisdienste

Der Konnektor MUSS für die an der Clientsystemschnittstelle definierten Web-Services der Basisdienste [SOAP1.1] verwenden. [<=]

TIP1-A_4519 - Web-Services konform zu [BasicProfile1.2]

Der Konnektor MUSS die für die Clientsystemschnittstelle definierten Web-Services konform zu [BasicProfile1.2] anbieten.
Abweichend von R1012 in [BasicProfile1.2] MUSS der Konnektor nur das Character Encoding UTF-8 unterstützen. Andere Kodierungen MUSS der Konnektor mit einem Fehler beantworten.

[<=]

TIP1-A_4519-01 - ab PTV4: Web-Services konform zu [BasicProfile1.2]

Der Konnektor MUSS die für die Clientsystemschnittstelle definierten Web-Services der Basisdienste konform zu [BasicProfile1.2] anbieten.

[<=]

A_15606 - Character Encoding für Web-Services

Abweichend von R1012 in [BasicProfile1.2] und [BasicProfile2.0] MUSS der Konnektor nur das Character Encoding UTF-8 unterstützen. Andere Kodierungen MUSS der Konnektor mit einem Fehler beantworten.

[<=]

Da der Konnektor UTF-16 nicht unterstützt, muss das Clientsystem den Request in UTF-8 kodieren. Diese Festlegungen gelten nur für die eigentliche SOAP-Nachricht. Sind in der SOAP-Nachricht base64-encodierte XML-Elemente vorhanden, so können diese XML-Elemente andere Zeichencodierungen aufweisen.

Fachmodule

Fachmodule können für Web-Services, die Clientsystemen bereitgestellt werden, entweder [SOAP1.1] mit [BasicProfile1.2] oder [SOAP1.2] mit [BasicProfile2.0] verwenden. Die genaue Ausprägung erfolgt in der jeweiligen Interfacebeschreibung des Web-Services für das Fachmodul.

A_15607 - SOAP für Web-Services der Fachmodule

Der Konnektor MUSS für die an der Clientsystemschnittstelle definierten Web-Services der Fachmodule [SOAP1.1] und [SOAP1.2] unterstützen. Die SOAP-Version pro Web-Service Endpunkt wird durch die WSDL des jeweiligen Web-Service definiert. [<=]

A_15608 - Web-Services der Fachmodule konform zu [BasicProfile1.2]

Der Konnektor MUSS für die an der Clientsystemschnittstelle definierten Web-Services der Fachmodule bei [SOAP1.1] die Profilierung konform zu [BasicProfile1.2] anbieten. [<=]

A_15609 - Web-Services der Fachmodule konform zu [BasicProfile2.0]

Der Konnektor MUSS für die an der Clientsystemschnittstelle definierten Web-Services der Fachmodule bei [SOAP1.2] die Profilierung konform zu [BasicProfile2.0]  anbieten. [<=]

3.6.2 Statusrückmeldung und Fehlerbehandlung

Der Konnektor bietet Operationen an der Außenschnittstelle über SOAP-Webservices an. Treten bei der Ausführung einer Operation Fehler auf, so werden diese an das aufrufende System gemeldet. Die von den Basisdiensten des Konnektors angebotenen SOAP-Webservices melden Fehler, die bei der Ausführung einer Operation auftreten, über eine SOAP-Fault-Nachricht (siehe auch [gemSpec_OM#3.2.3]).

TIP1-A_5058 - Fehlerübermittlung durch gematik-SOAP-Fault

Der Konnektor MUSS Fehlermeldungen, die im Rahmen einer über die Außenschnittstelle aufgerufenen Operation auftreten, an das Clientsystem mittels gematik-SOAP-Faults melden.
[<=]

TIP1-A_5058-01 - ab PTV4: Fehlerübermittlung durch gematik-SOAP-Fault

Der Konnektor MUSS Fehlermeldungen, die im Rahmen einer über die Außenschnittstelle aufgerufenen Operation eines Basisdienst-SOAP-Webservices auftreten, an das Clientsystem mittels gematik-SOAP-Faults melden.
[<=]

Treten bei konnektorinternen Operationen (TUCs) Fehler auf, so werden diese an den Aufrufer (aufrufender TUC oder aufrufende Operation) zurückgegeben. Der Aufrufer kann den aufgetretenen Fehler in seinem Kontext neu interpretieren. Das bedeutet insbesondere, dass ein Error eines aufgerufenen TUCs nicht zwingend zum Abbruch des aufrufenden TUCs bzw. der aufrufenden Operation führen muss. So ist es dem Aufrufer möglich, einen Error als Warnung zu interpretieren und an den eigenen internen oder externen Aufrufer zurückzumelden. Diese dabei erzeugte Fehlerkette wird in Form einer Fehler-Trace-Struktur abgebildet, um eine Nachverfolgung von Fehlern zu ermöglichen.

Operationen an der Außenschnittstelle können die Fehlerkette zu Informationszwecken in der SOAP-Antwort an das Clientsystem senden. Dazu enthält jede SOAP-Antwort das Element Status, dass gemäß dem XML-Schema [ConnectorCommon.xsd] aufgebaut ist (siehe auch Abbildung PIC_KON_107 XML-Struktur des Status-Elements einer SOAP-Antwort).

 

Abbildung 3: PIC_KON_107 XML-Struktur des Status-Elements einer SOAP-Antwort 

Schlägt eine Operation fehl, so wird eine SOAP-Fault-Meldung an das Clientsystem versendet. Im Erfolgsfall wird das Status-Element in die Antwortnachricht an das Clientsystem aufgenommen. Ist der Fehler-Trace leer (Element GERROR:Error ist nicht vorhanden), so wird CONN:Result auf OK gesetzt. Andernfalls, d. h. wenn in GERROR:Trace Fehler der Schwere Info oder Warning (zu Informationszwecken) enthalten sind, wird CONN:Result auf Warning gesetzt.

TIP1-A_4521 - Protokollierung von Fehlern inkl. Trace-Struktur

Der Konnektor MUSS Fehler protokollieren, die in fachlichen und technischen Abläufen von der gematik spezifiziert oder herstellerspezifisch definiert sind und den Schweregrad (Severity) Warning, Error oder Fatal haben. Zur Nachvollziehbarkeit des Fehlers MÜSSEN Fehlerursache, fachliche und technische Auslöser des Fehlverhaltens aus den Protokolleinträgen erkennbar sein. 
[<=]

A_14159 - Rückgabe von Fehlermeldungen an der Außenschnittstelle

Der Konnektor MUSS bei der Rückgabe von Fehlermeldungen an der Außenschnittstelle sicherstellen, dass im letzten“ GERROR:Trace“-Element der GERROR-Struktur ein von der gematik spezifizierter Fehler steht. Die GERROR-Struktur kann weitere gematik- und herstellerspezifische Fehler enthalten.
[<=]

In der Regel ist es ausreichend, wenn die GERROR-Struktur an der Außenschnittstelle nur ein Element „GERROR:Trace“ mit einem gematik-Fehler enthält.

Wenn für eine Fehlersituation kein Fehlercode spezifiziert ist, kann ein herstellerspezifischer Fehler zur Detaillierung verwendet werden. In diesem Fall muss ein passender gematik-Fehler als letztes GERROR:Trace-Element gewählt werden.  Bei Fehlern in technischen Abläufen kann Fehlercode 4001 als letztes GERROR:Trace-Element verwendet werden. Die Wahl des letzten GERROR:Trace-Elements ist mit der gematik abzustimmen.

Zur Struktur von Fehlermeldungen siehe auch [gemSpec_OM#GS-A_3856-*].

3.6.3 Transport großer Dokumente

SOAP Message Transmission Optimization Mechanism (MTOM) ermöglicht den direkten Transport von binären Daten in Webservices, d.h. ohne dass eine zur Laufzeit aufwändige Verpackung der binären Daten in ein Base64-XML-Element notwendig wird. Auf die Definition der Webservices und ihre Funktionalität hat dieser Optimierungsmechanismus keinen Einfluss. Der Einsatz von MTOM dient der Verbesserung des Performance-Verhaltens für große Dokumente.

Das Clientsystem kann die Optimierung des Transports großer Dokumente per SOAP Message Transmission Optimization Mechanism (MTOM) anstoßen. In den WSDL-Dateien werden keine MTOM Serialization Policy Assertion [WS-MTOMPolicy] eingebettet.

TIP1-A_5694 - SOAP Message Transmission Optimization Mechanism für Basisdienste

Der Konnektor KANN SOAP Message Transmission Optimization Mechanism (MTOM) gemäß [MTOM] unterstützen.
Wenn der Konnektor MTOM unterstützt, MUSS er MTOM für Signatur- und Verschlüsselungsdienst unterstützen, DARF aber NICHT MTOM für andere Dienste unterstützen.
Wenn der Konnektor MTOM unterstützt, MUSS er, vergleichbar dem Einsatz des Attributs wsp:Optional="true" einer MTOM Serialization Policy Assertion [WS-MTOMPolicy], genau dann MTOM für die Antwortnachricht verwenden, wenn entweder

• die Aufrufnachricht eine application/xop+xml Nachricht ist
• oder der Accept HTTP header der Aufrufnachricht folgenden Wert hat:
  multipart/related; type=application/xop+xml

[<=]

TIP1-A_5694-02 - ab PTV4: SOAP Message Transmission Optimization Mechanism für Basisdienste

Der Konnektor KANN SOAP Message Transmission Optimization Mechanism (MTOM) gemäß [MTOM-SOAP1.1] für Basisdienste unterstützen. [<=]

TIP1-A_5694-03 - ab PTV5: SOAP Message Transmission Optimization Mechanism für Basisdienste

Der Konnektor MUSS SOAP Message Transmission Optimization Mechanism (MTOM) gemäß [MTOM-SOAP1.1] für Basisdienste unterstützen.
[<=]

A_15786 - SOAP Message Transmission Optimization Mechanism für Basisdienste - Einschränkung

Wenn der Konnektor MTOM für Basisdienste unterstützt, MUSS er MTOM für Signatur- und Verschlüsselungsdienst unterstützen, DARF aber NICHT MTOM für andere Dienste unterstützen. [<=]

A_15610 - Verwendung von MTOM für Antwortnachricht

Wenn der Konnektor MTOM unterstützt, MUSS er, vergleichbar dem Einsatz des Attributs wsp:Optional="true" einer MTOM Serialization Policy Assertion [WS-MTOMPolicy], genau dann MTOM für die Antwortnachricht verwenden, wenn entweder

• die Aufrufnachricht eine application/xop+xml Nachricht ist
• oder der Accept HTTP header der Aufrufnachricht folgenden Wert hat:
  multipart/related; type=application/xop+xml.

[<=]

A_15611 - SOAP Message Transmission Optimization Mechanism für Fachmodule

Der Konnektor MUSS SOAP Message Transmission Optimization Mechanism (MTOM) gemäß [MTOM] für Fachmodule unterstützen, wenn es in der Schnittstellenbeschreibung des Fachmodules explizit gefordert wird. [<=]

3.7 Verwendung manuell importierter CA-Zertifikate

TI-fremde X.509-Zertifikate werden im Rahmen des Verschlüsselungsdienstes verwendet. Um den Vertrauensraum für diese Zertifikate abzubilden, erlaubt der Konnektor, X.509-CA-Zertifikate zu diesen TI-fremden X.509-Zertifikaten in eine interne Liste (CERT_IMPORTED_CA_LIST) zu importieren.

Der Konnektor kann dann im Rahmen der Hybridverschlüsselung den symmetrischen Schlüssel empfängerspezifisch mit dessem TI-fremden X.509-Zertifikat verschlüsseln. Die TI-fremden Zertifikate dürfen nicht zu einem anderen Zweck als diesem eingesetzt werden.

TIP1-A_5433 - Manuell importierte X.509-CA-Zertifikate nur für hybride Verschlüsselung

Der Konnektor DARF End-Entity-Zertifikate, die lediglich gegen manuell importierte X.509-CA-Zertifikate geprüft werden, die von CAs außerhalb der TI stammen (CERT_IMPORTED_CA_LIST), NICHT für andere Zwecke als zur hybriden Verschlüsselung von Dokumenten verwenden.

[<=]

Die Berücksichtigung der CA-Zertifikate aus CERT_IMPORTED_CA_LIST muss auf folgende Anwendungsfälle beschränkt werden:

1. Prüfung eines Zertifikates im Rahmen der hybriden Verschlüsselung

2. Prüfung eines Zertifikates im Rahmen eines Aufrufes der Operation "VerifyCertificate"

TIP1-A_5660 - Hinweise im Handbuch für manuell importierte X.509-CA-Zertifikate

Das Handbuch des Konnektors MUSS sinngemäß folgende Hinweise enthalten:

• Der Administrator übernimmt die Verantwortung für die Verlässlichkeit der importierten CA-Zertifikate.
• Der Administrator kann sich bei seiner Entscheidung für einen Import von CA-Zertifikaten auf die Informationen der gematik stützen.
• Die gematik veröffentlicht dazu Informationen über CA-Betreiber, welche die Erfüllung der Sicherheitsanforderungen der gematik nachgewiesen haben.

[<=]

3.8 Testunterstützung

Gemäß Testkonzept der TI [gemKPT_Test#TIP1-A_6526] muss ein Hersteller eines Konnektors seine Modelle in verschiedenen Ausführungen vorsehen: für Testumgebung, für die Referenzumgebung und für die Produktivumgebung.
Damit trotz dieser Forderung die Firmware je Konnektorversion für alle Umgebungen identisch ist, wird die Erkennung der Umgebung an die gSMC-K gebunden. Die Konnektor-Firmware muss zwischen den Umgebungen PU und RU/TU unterscheiden. Die gSMC-K besitzt hierzu den Datencontainer MF/EF.EnvironmentSettings, der die jeweilige Umgebungskennung enthält (PU bzw. TU/RU). Die Umgebungskennung wird read-only auf der gSMC-K gespeichert.

TIP1-A_4981 - Steuerung der Betriebsumgebung via gSMC-K

Der Produkttyp Konnektor MUSS sowohl in der Testumgebung (TU), der Referenzumgebung (RU) wie auch der Produktivumgebung (PU) betreibbar sein.
Die Information, ob eine Konnektorinstanz in der TU/RU oder PU betrieben wird, MUSS der Konnektor dem File MF/EF.EnvironmentSettings der gSMC-K entnehmen.
Abhängig von der ermittelten Betriebsumgebung MÜSSEN die Konfigurationswerte gemäß Tabelle TAB_KON_812 verwendet werden.
 

Tabelle 15: TAB_KON_812 Umgebungsabhängige Konfigurationsparameter 

[<=]

TIP1-A_4707 - Betrieb in Test- und Referenzumgebung

Der Produkttyp Konnektor MUSS auch in der Test- und Referenzumgebung betrieben werden können. Dafür MUSS der Vertrauensanker des Konnektors für diese Umgebung ausgetauscht werden können. Dies KANN durch Lieferung eines neuen Konnektors oder durch Austausch der gSMC-K durch den Hersteller ermöglicht werden. Der Hersteller MUSS sicherstellen, dass Konnektoren ausschließlich mit den zu ihrer Einsatzumgebung gehörenden Vertrauensankern ausgestattet werden.

[<=]

TIP1-A_4982 - Anzeige von TU/RU in der Managementschnittstelle

Die Administrationsoberfläche MUSS, wenn der Konnektor in der Testumgebung (TU) oder Referenzumgebung (RU) betrieben wird, die Umgebungsbezeichnung zu jeder Zeit erkennbar in der Managementschnittstelle anzeigen.

Die Anzeige eines Betriebs in der Produktivumgebung DARF NICHT explizit angezeigt werden.

[<=]

4 Funktionsmerkmale

Für die folgenden Inhalte bitte die Hinweise in Kapitel 1.5.3 „Erläuterungen zur Spezifikation des Außenverhaltens„ sowie Kapitel 1.5.4 Erläuterungen zur Dokumentenstruktur und „Dokumentenmechanismen“ beachten.

4.1 Anwendungskonnektor

4.1.1 Zugriffsberechtigungsdienst

Der Zugriffsberechtigungsdienst ist ein interner Dienst. Er ermöglicht es Operationen eine Prüfung auf Zugriffsberechtigung für die von ihnen benötigten Ressourcen durchzuführen. Die Prüfung erfolgt direkt nach Aufruf einer Operation des Konnektors durch das Clientsystem und basiert auf den im Clientaufruf enthaltenen Parametern.

Der Zugriffsberechtigungsdienst definiert über ein Informationsmodell die erlaubten Zugriffsmöglichkeiten. Um dies zu erreichen, modelliert es Mandanten und ordnet ihnen Clientsysteme sowie die vom Konnektor verwalteten externen Ressourcen (Kartenterminal mit Slots, Arbeitsplatz mit SMC-Bs) zu. Diese durch einen Administrator persistent zu modellierenden Entitäten und Beziehungen beinhalten die erlaubten Zugriffswege vom Clientsystem über Arbeitsplatz zum Kartenterminal und dessen Slots. Sie werden im Konnektor administrativ konfiguriert.

Neben diesen persistenten Entitäten und Beziehungen bildet das Modell auch die in den Slots temporär gesteckten Karten und die zugehörigen Kartensitzungen als transiente Entitäten und Beziehungen ab.

Abbildung PIC_Kon_100 stellt das Informationsmodell dar. Die persistenten Entitäten haben einen grünen Hintergrund, die transienten einen weißen.

Tabelle TAB_KON_507 beschreibt die Entitäten und legt ihren Identitätsschlüssel fest. Tabelle TAB_KON_508 beschreibt die Attribute. Tabelle TAB_KON_509 beschreibt die Entitätsbeziehungen und referenziert dabei die in Abbildung PIC_Kon_100 durch Zahlen in eckigen Klammern markierten Beziehungen. Tabelle TAB_KON_510 definiert Constraints, die zusätzlich zu den in Abbildung PIC_Kon_100 definierten Kardinalitäten gelten. Die Constraints werden mittels Object Constraint Language (OCL) definiert.

4.1.1.1 Funktionsmerkmalweite Aspekte

TIP1-A_4522 - Zugriffsberechtigungs-Informationsmodell des Konnektors

Der Konnektor MUSS die Entitäten, Attribute und Beziehungen des Informationsmodells intern vorhalten, dabei für die Einhaltung der definierten Constraints sorgen und die persistenten Entitäten und Beziehungen dauerhaft speichern. Der Konnektor MUSS dabei eine Mindestanzahl von 999 Mandanten unterstützen.

Das Informationsmodell ist definiert durch das UML-Diagramm „PIC_Kon_100 Informationsmodell des Konnektors„ und die Tabelle „TAB_KON_510 Informationsmodell Constraints“. Der Konnektor darf nur Daten in sein Informationsmodell übernehmen, die alle Eigenschaften des Informationsmodells, insbesondere die Constraints, erfüllen.

Die Entitäten werden in Tabelle „TAB_KON_507 Informationsmodell Entitäten“ beschrieben, die Attribute in Tabelle „TAB_KON_508 Informationsmodell Attribute“ und die Beziehungen in Tabelle „TAB_KON_509 Informationsmodell Entitätenbeziehungen“.

[<=]

Hinweis zu den Bezeichnern der Entitäten und ihrer Attribute: Im Folgenden beginnen Entitäten mit einem Großbuchstaben, Attribute mit einem Kleinbuchstaben. Werden die Entitäten und Attribute in XML-Dokumenten verwendet, so beginnen die zugeordneten XML-Elementbezeichner grundsätzlich mit einem Großbuchstaben und verwenden den englischen Begriff, der im Folgenden in Klammern angegeben ist, wenn zur besseren Lesbarkeit im Modell ein deutscher Begriff verwendet wird.

 

Abbildung 4: PIC_Kon_100 Informationsmodell des Konnektors 

Tabelle 16: TAB_KON_507 Informationsmodell Entitäten 

Entität	persistent/ transient	Identitätsschlüssel	Beschreibung
Mandant	persistent	mandantId	Zu Mandanten und Mandantenfähigkeit siehe Kapitel Mandantenfähigkeit.
Clientsystem	persistent	clientSystemId	Unter einem Clientsystem wird hier ein einzelnes oder eine Gruppe von Systemen verstanden, welche im LAN der Einsatzumgebung auf die Clientsystem-Schnittstelle des Konnektors zugreifen.
CS-AuthMerkmal (CS-AuthProperty)	persistent	csAuthId	Das Authentifizierungsmerkmal dient der Authentifizierung, wenn sich das Clientsystem gegenüber dem Konnektor authentisiert. Der Identitätsschlüssel csAuthId wird bei der Administration vergeben
Arbeitsplatz (Workplace)	persistent	workplaceId	alle dem Konnektor bekannten Arbeitsplätze
Kartenterminal (CardTerminal)	persistent	ctId	alle dem Konnektor bekannten Kartenterminals.
KT-Slot (CT-Slot)	persistent	ctId, slotNo	Die sich in den Kartenterminals befindenden Chipkartenslots (Functional Unit Type 00)
Karte (Card)	transient	cardHandle oder iccsn	Die in den Kartenterminals steckenden Smartcards des Gesundheitswesens, die persönliche Identitäten oder Rollen repräsentieren (eGK, HBA, SMC-B). Karten, die nur Geräteidentitäten tragen (gSMC-K, gSMC-KT) werden in diesem Modell nicht betrachtet. Karten im Sinne dieses Informationsmodells existieren maximal so lange, wie sie im Kartenterminal stecken. Die aktuell im System steckenden Karten werden vom Clientsystem über das cardHandle adressiert. Die iccsn erlaubt eine dauerhafte Adressierung einer Karte. Für den Kartentyp „SM-B“ kann hier auch eine in einem HSM-B enthaltene virtuelle SMC-B abgebildet werden.
Kartensitzung (CardSession)	transient	siehe konkrete Kartensitzungen	Kartensitzungen stellen ein wesentliches Konzept im Sicherheitsmodell des Konnektors dar. Eine Kartensitzung verwaltet einen aktuellen logischen Sicherheitsstatus einer Karte. Die Kartensitzungen sind einer Karte fest zugewiesen. Zu einer Karte kann es mehrere Kartensitzungen geben, die voneinander logisch unabhängige Sicherheitsstatus einer Karte verwalten. Der Konnektor führt alle Zugriffe auf eine Karte im Kontext einer Kartensitzung zu dieser Karte aus. Das Attribut logischerKanal bezeichnet den logischen Kanal zur Karte, der im Rahmen der Kartensitzung verwendet wird (gemäß Standard [7816–4]).
Kartensitzung_eGK (CardSession_eGK)	transient	cardHandle	Kartensitzung für eine eGK. Die KVK ist im Modell nicht explizit dargestellt. Soweit anwendbar, gelten für die KVK die gleichen Aussagen wie für die eGK.
Kartensitzung_SM-B (CardSession_SM-B)	transient	cardHandle, mandantId	Kartensitzung für eine SM-B
Kartensitzung_HBAx (CardSession_HBAx)	transient	cardHandle, clientSystemId, userId	Kartensitzung für einen HBAx. Unter dem Typ „HBAx“ sind auch die Vorläuferkarten wie „HBA-qSig” und „ZOD_2.0“ inkludiert.
SM-B_Verwaltet (SM-B_managed)	persistent	iccsn	SM-Bs müssen im Gegensatz zu den übrigen Karten im Konnektor vor ihrer Verwendung persistent im Informationsmodell als „SM-B_Verwaltet“ per Administration aufgenommen werden. Dies gilt auch für die in einem HSM-B enthaltenen virtuellen SMC-Bs. Fachmodule können die mit einem Mandanten konfigurierten SM-B_managed.telematikId abfragen.
CS_AP	persistent	mandantId, clientSystemId, workplaceId	CS_AP legt die von einem Clientsystem pro Mandanten nutzbaren Arbeitsplätze fest. Ein Clientsystem kann dabei mehrere Arbeitsplätze bedienen. Ebenso können Arbeitsplätze von mehreren Clientsystemen, auch gleichzeitig, genutzt werden, z. B. bei zwei unterschiedlichen, voneinander unabhängigen Praxisprogrammen.
Remote-PIN-KT	persistent	mandantId, workplaceId, ctId	Remote-PIN-KT legt pro Mandant und Arbeitsplatz fest, über welches Kartenterminal eine Remote PIN-Eingabe erfolgen soll, wenn an diesem Arbeitsplatz die PIN-Eingabe für eine Karte erforderlich ist, die nicht in einem dem Arbeitsplatz lokal zugeordneten Kartenterminal steckt.
AuthState	transient	cardHandle, (clientSystemId), (userId), ref	Zu einer Kartensitzung gibt es höhere AuthorizationStates, die durch (type =C2C) Freischaltung oder durch PIN-Eingabe (type=CHV) erreicht werden können. Für eGK G2.0 wird der Zustand der MRPINs nicht in AuthState gespeichert.

 

Tabelle 17: TAB_KON_508 Informationsmodell Attribute 

Attribut	Beschreibung
cardHandle	Das Identifikationsmerkmal einer Karte für die Dauer eines Steckzyklusses. Es wird mit dem Entfernen der Karte aus dem Kartenterminal ungültig. Es wird automatisch vom Konnektor vergeben.
clientSystemId	Das Identifikationsmerkmal eines Clientsystems. Es wird per Administration dem Mandanten im Clientsystem und im Konnektor zugeordnet.
csAuthId	Das Identifikationsmerkmal eines Authentifizierungsmerkmals.
ctId	Das Identifikationsmerkmal eines Terminals. Es ist eine fixe Eigenschaft des Kartenterminals.
iccsn	Die Seriennummer einer Karte. Sie identifiziert eine Karte dauerhaft.
isHSM	Attribut der Entitäten Karte und SM-B_Verwaltet. Es ist false, wenn eine echte Smardcard abgebildet wird und true, wenn es sich um eine virtuelle SMC-B handelt, die in einem HSM-B enthalten ist.
isPhysical	Attribut des Kartenterminals das den Wert „Ja“ hat, wenn es sich um ein tatsächlich existierendes Kartenterminal handelt. Ist der Wert „Nein“, dann handelt es sich um ein logisches Kartenterminal im Zusammenhang mit einem HSM-B.
logicalChannel	Referenz auf ein Objekt, das einen logischen Kanal repräsentiert.
mandantId	Das Identifikationsmerkmal eines Mandanten. Es wird per Administration dem Mandanten im Clientsystem und im Konnektor zugeordnet.
ref	Das Identifikationsmerkmal eines AuthState zu einer gegebenen Kartensitzung. Im Falle C2C handelt es sich um die KeyRef (mit einer bestimmten Rolle) und in Falle CHV um eine referenzierte PIN.
slotNo	Das Identifikationsmerkmal eines Slot für ein bestimmtes Kartenterminal. Diese fortlaufende Nummer ist eine fixe Eigenschaft des Kartenterminals. Sie beginnt bei 1.
telematikId	Die Telematik-ID wird in den AUT-Zertifikaten von SM-B unter Admission.RegistrationNumber kodiert.
type	Als Kartenattribut: Typ einer Karte. Im Folgenden berücksichtigte Werte: „HBAx“, „SM-B“, „EGK“. Als Attribute eines AuthState: Typ des AuthState. „C2C“ steht für gegenseitige Kartenauthentisierung. „CHV“ steht für Card Holder Verification per PIN-Eingabe.
userId	Das Identifikationsmerkmal des Nutzers im Clientsystem (Die userId wird durch das Clientsystem vergeben und verwaltet). Die userId wird im Kontext eine Kartensitzung_HBAx vom Konnektor verwendet, um als Bestandteil des Identitätsschlüssels die Kartensitzung_HBAx zu identifizieren.
workplaceId	Das Identifikationsmerkmal eines Arbeitsplatzes. Es wird per Administration dem Mandanten im Clientsystem und im Konnektor zugeordnet.

Tabelle 18: TAB_KON_509 Informationsmodell Entitätenbeziehungen 

Entitätenbeziehung	persistent/ transient	Beschreibung
Authentifikationsmerkmale des Clientsystems [1]	persistent	Diese Relation legt für jedes Clientsystem eine Menge von Authentisierungsmerkmalen fest. Mit einem dieser Authentisierungsmerkmale muss sich ein Client gegenüber dem Konnektor authentisiert haben, um als das entsprechende Clientsystem vom Konnektor akzeptiert zu werden.
Clientsysteme des Mandanten [2]	persistent	Diese Relation weist Clientsystemen Mandanten zu.
Arbeitsplätze des Mandanten [3]	persistent	Diese Relation weist Arbeitsplätze Mandanten zu. Arbeitsplätze können von mehreren Mandanten genutzt werden. Z. B. kann ein von mehreren Mandanten genutzter gemeinsamer Empfang als ein Arbeitsplatz modelliert werden.
Kartenterminals des Mandanten [5]	persistent	Diese Relation weist Kartenterminals Mandanten zu.
Lokale Kartenterminals [6]	persistent	Diese Relation erfasst die Kartenterminals, die sich lokal an einem Arbeitsplatz befinden und von diesem genutzt werden können. Die Modellierung lässt es zu, dass Kartenterminals mehreren Arbeitsplätzen lokal zugewiesen werden. Jeder an der TI teilnehmende Arbeitsplatz wird in der Regel mindestens ein lokales Kartenterminal benötigen.
Entfernte Kartenterminals [7]	persistent	Diese Relation beschreibt, auf welche Kartenterminals Arbeitsplätze (remote) zugreifen dürfen. Dies ist für zentral steckende Karten vorgesehen.
Slot eines Kartenterminals [8]	persistent	Die Zuordnung von Slots zu einem Kartenterminal ergibt sich automatisch aus den Eigenschaften des Kartenterminals.
SM-B_Verwaltet eines Mandanten [9]	persistent	Diese Relation legt fest, welche verwalteten SM-Bs einem Mandanten zugeordnet sind.
Kartenterminal-Slot, in dem eine Karte steckt [10]	transient	Sobald eine Karte in ein Kartenterminal gesteckt wird, ergibt sich implizit eine Relation der Karte zu dem Slot, in dem sie steckt, [6] und indirekt über [4] zum Kartenterminal.
Mandant der Kartensitzung SM-B [11]	transient	Beim Anlegen einer Kartensitzung SM-B wird diese immer dem zugreifenden Mandanten zugeordnet.
Arbeitsplatz der Kartensitzung eGK [12]	transient	Eine Kartensitzung eGK ist immer einem Arbeitsplatz zugeordnet.
Karte einer Kartensitzung [13]	transient	Jeder Kartensitzung ist genau einer Karte zugeordnet.
Gesteckte SM-B [14]	transient	Wird eine SM-B gesteckt und handelt es sich um eine verwaltete SM-B, ergibt sich über die iccsn die Zuordnung.
Freischaltung einer Karte [15]	transient	Diese Relation erfasst die Freischaltung einer Karte durch eine andere Karte.
Bindung der Kartensitzung_HBAx an Clientsystem [16]	transient	Kartensitzungen HBAx sind einem Clientsystem zugeordnet.
AuthState pro Kartensitzung [17]	transient	Eine Kartensitzung kann erhöhte Sicherheitszustände (Authorization State) haben.

Tabelle 19: TAB_KON_510 Informationsmodell Constraints 

#	Beschreibung	Definition mittels OCL (Die Constraints werden im UML ergänzenden Standard OCL definiert.)
C1	Eine eGK muss eine oder keine Kartensitzung haben.	context Karte inv: self.type = "eGK" implies   self.kartensitzung.size() <= 1
C2	Wenn zwei Kartensitzungen einer HBAx dem gleichen Clientsystem zugeordnet sind und ihre userIds gleich sind, dann müssen die beiden Kartensitzungen identisch sein.	context Kartensitzung-HBAx inv: forAll(k1, k2 : Kartensitzung-HBAx |   k1.karte = k2.karte     and k1.clientsystem = k2.clientsystem     and k1.userId = k2.userId     implies   k1 = k2)
C3	Wenn zwei SM-B-Kartensitzungen einer Karte dem gleichen Mandanten zugeordnet sind, dann müssen die beiden Kartensitzungen identisch sein.	context Kartensitzung-SM-B inv: forAll(k1, k2 : Kartensitzung-SM-B |   k1.karte = k2.karte     and k1.mandant = k2.mandant implies   k1 = k2)
C4	Die Seriennummer iccsn einer Karte muss eindeutig sein.	context Karte inv: Karte.allInstances ->      isUnique(iccsn)
C5	Die Seriennummer iccsn einer Karte muss für die vom Konnektor verwalteten SM-Bs eindeutig sein.	context SM-B_Verwaltet inv: SM-B_Verwaltet.allInstances ->        isUnique(iccsn)
C6	Das CardHandle einer Karte muss eindeutig sein.	context Karte inv: Karte.allInstances ->      isUnique(cardHandle)
C7	Die Identifikationsnummer des Clientsystems muss eindeutig sein.	context Clientsystem inv: Clientsystem.allInstances ->      isUnique(clientSystemId)
C8	Die Identifikationsnummer des Mandanten muss eindeutig sein.	context Mandant inv: Mandant.allInstances ->      isUnique(mandantId)
C9	Die Identifikationsnummer des Arbeitsplatzes muss eindeutig sein.	context Arbeitsplatz inv: Arbeitsplatz.allInstances ->      isUnique(workplaceId)
C10	Die Identifikationsnummer des Kartenterminals muss eindeutig sein.	context Kartenterminal inv: Kartenterminal.allInstances ->      isUnique(ctId)
C11	Die Identifikationsnummer (slotNo) des Kartenterminal-Slots für ein gegebenes Kartenterminal muss eindeutig sein.	context Kartenterminal inv: self.kT-Slot ->      isUnique(slotNo)
C12	Es muss gewährleistet sein, dass nur Arbeitsplätze und Clientsysteme einander im Rahmen eines Mandanten zugeordnet werden, die diesem Mandanten selbst zugeordnet sind.	context CS-AP inv: self.arbeitsplatz.mandant.includes(                 self.mandant) inv: self.clientsystem.mandant.includes(                 self.mandant)
C13	Es muss gewährleistet sein, dass nur Kartenterminals und Arbeitsplätze einander im Rahmen eines Mandanten zur Remote-PIN-Eingabe zugeordnet werden, die diesem Mandanten selbst zugeordnet sind.	context Remote-PIN-KT inv: self.arbeitsplatz.mandant.includes(                 self.mandant) inv: self.kartenterminal.mandant.includes(                 self.mandant)
C14	Zur Remote-PIN-Eingabe muss ein lokales Kartenterminal ausgewählt sein.	context Remote-PIN-KT inv: self.arbeitsplatz      .localKartenterminal      .includes(self.kartenterminal) inv: not self.arbeitsplatz      .entferntKartenterminal      .includes(self.kartenterminal)
C15	Zur Remote-PIN-Eingabe darf pro Mandanten und Arbeitsplatz nicht mehr als ein Kartenterminal ausgewählt werden.	context Remote-PIN-KT inv: forAll(r1, r2 : Remote-PIN-KT |   r1.arbeitsplatz = r2.arbeitsplatz     and r1.mandant = r2.mandant implies   r1 = r2)
C16	Eine Kartensitzung-HBAx muss immer eine zugehörige userId haben.	context Kartensitzung-HBAx inv: self.userId <> null

Hinweis zur Remote-PIN-Eingabe: Constraints C14 und C15 legen fest, dass auch im Fall mehrerer lokaler Kartenterminals an einem Arbeitsplatz nur eines (oder keines) dieser Kartenterminals pro Mandant für die Remote-PIN-Eingabe im Informationsmodell konfiguriert wird.

TIP1-A_4523 - Sicherung der Aktualität des Informationsmodells Zugriffsberechtigungsdienst

Der Konnektor MUSS seine Entscheidungen zur Zugriffsberechtigung basierend auf den aktuellen, realen statischen wie transienten Entitäten und Beziehungen des Informationsmodells treffen. Veränderungen an der statischen Definition (durch den Administrator), sowie Veränderungen an den Entitäten (Änderung der Verfügbarkeit und Zustandsänderung von Karten, Kartenterminals und Clientsystemen) MÜSSEN bei Zugriffsanfragen unmittelbare Auswirkung auf die Entscheidung des Zugriffsberechtigungsdienstes zur Folge haben.

[<=]

4.1.1.2 Durch Ereignisse ausgelöste Reaktionen

Keine.

4.1.1.3 Interne TUCs, nicht durch Fachmodule nutzbar

Keine.

4.1.1.4 Interne TUCs, auch durch Fachmodule nutzbar

4.1.1.4.1 TUC_KON_000 „Prüfe Zugriffsberechtigung“

Vor Ausführung jeder Operation an der Außenschnittstelle muss der Konnektor prüfen, ob die Operation ausgeführt werden darf (Autorisierung). Diese Prüfung auf Zugriffsberechtigung wird in TUC_KON_000 „Prüfe Zugriffsberechtigung“ gekapselt.

TUC_KON_000 „Prüfe Zugriffsberechtigung“ hat als Aufrufparameter den Aufrufkontext der Operation (siehe Abbildung PIC_KON_101), optional das cardHandle einer Karte, optional eine Kartenterminal-ID ctId und optional die Steuerungsparameter „needCardSession“ sowie „allWorkplaces“. Über den Steuerungsparameter „needCardSession“ wird festgelegt, ob zu den CardHandles im Rahmen der Operationsausführung eine Kartensitzung benötigt wird. Über den Steuerungsparameter „allWorkplaces“. wird festgelegt, ob die Auswertung im Rahmen der Operation arbeitsplatzübergreifend für alle vom Mandanten für das angegebene Clientsystem erreichbaren Kartenterminals erfolgen soll.

 

Abbildung 5: PIC_KON_101 Aufrufkontext der Operation 

TIP1-A_4524-03 - TUC_KON_000 „Prüfe Zugriffsberechtigung”

Der Konnektor MUSS den technischen Use Case TUC_KON_000 „Prüfe Zugriffsberechtigung“ umsetzen.
 

Tabelle 20: TAB_KON_511-01 – TUC_KON_000 „Prüfe Zugriffsberechtigung“

Element	Beschreibung
Name	TUC_KON_000 ”Prüfe Zugriffsberechtigung”
Beschreibung	Es wird geprüft, ob eine Autorisierung im Rahmen der angegebenen Eingangsdaten erteilt wird. Die Autorisierung wurde erteilt, wenn der TUC erfolgreich durchlaufen wurde (kein Abbruch durch Fehlermeldung).“
Eingangs- anforderungen	keine
Auslöser und Vorbedingungen	Aufruf einer Operation des Konnektors durch das Clientsystem.
Eingangsdaten	mandantId clientSystemId workplaceId userId - optional ctId - optional (Kartenterminalidentifikator) cardHandle - optional needCardSession [Boolean] – optional; default: true   („needCardSession“=true; „doNotNeedCardSession“=false)   Dieser Schalter gibt an, ob eine Kartensitzung benötigt wird   - true, der aufrufende TUC verwendet eine Kartensitzung   - false, der aufrufende TUC verwendet keine Kartensitzung   Die Berechtigungsprüfung geht im Default-Fall, davon aus, dass eine    Kartensitzung benötigt wird, und prüft für diesen Fall die Berechtigung mit. allWorkplaces [Boolean] – optional; default: false Dieser Schalter gibt an, ob eine mandantenweite Zugriffsberechtigung   gemeint ist.   Dieser Parameter muss dann (true) gesetzt werden, wenn die Berechtigungsprüfung nicht auf die vom angegebenen Arbeitsplatz erreichbaren Kartenterminals beschränkt ist, sondern sich auf alle vom Clientsystem (clientSystemId) und dem Mandant (mandantId) insgesamt erreichbaren Kartenterminals beziehen soll. Ist dieser Schalter gleich true, wird die Berechtigung unabhängig vom Eingangsparameter workplaceId geprüft.
Komponenten	Konnektor
Ausgangsdaten	keine
Nachbedingungen	Autorisierung erteilt
Standardablauf	1. Prüfe, ob die Pflichtparameter (mandantId, clientSystemId, workplaceId)      vollständig gesetzt sind.  2. Falls ANCL_CAUT_MANDATORY = Enabled, dann prüfe, ob die gemäß      [TIP1-A_4516] unter Berücksichtigung von [TIP1-A_5009] und [A_21224] durchgeführte             Authentifizierung über ein dem Clientsystem zugeordnetes CS-AuthMerkmal erfolgte.  3. Ermittle Zugriffsregel R zu den Aufrufparametern: 3.1.     Falls der Parameter cardHandle nicht null ist, muss das Kartenobjekt      des Informationsmodells Karte(cardHandle) ermittelt werden. 3.2.     Zu den Parametern (ctId, cardHandle, needCardSession,     allWorkplaces) muss mittels Tabelle „TAB_KON_513 Zugriffsregeln     Regelzuordnung“ die Zugriffsregel R ermittelt werden.  4. Prüfe die Bedingungen der in Schritt 3 ermittelten Regel R: 4.1.     Zur Regel R muss die relevante Spalte in Tabelle „TAB_KON_514       Zugriffsregeln Definition“ ermittelt werden. 4.2.     Jede Zeile, die in der Spalte R ein „x“ hat, muss geprüft werden:     4.2.1     Prüfe, ob die in Spalte „Bedingung“ mittels OCL formulierte              Bedingung für die Eingangsdaten erfüllt ist.
Varianten/ Alternativen	2. Bei einem Aufruf mit einem cardHandle zu den Kartentypen SMC-KT und UNKNOWN wird Schritt 3 in folgender Variante durchlaufen: Ermittle Zugriffsregel R zu den Aufrufparametern: 3.1.    ctId wird zum cardHandle bestimmt   Zu den Parametern (         ctId,         cardHandle = null,         needCardSession = false,         allWorkplaces = false) muss mittels Tabelle „TAB_KON_513 Zugriffsregeln Regelzuordnung“ die Zugriffsregel R ermittelt werden.
Fehlerfälle	Fehler im Ablauf (Standardablauf oder Varianten) führen in den folgend ausgewiesenen Schritten zu einem Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes: (1)       Es sind nicht alle Pflichtparameter gesetzt,                Fehlercode: 4021 (2)       Clientsystem aus dem Aufrufkontext nicht authentifiziert,                Fehlercode: 4204 (3.1)    Karte nicht als gesteckt identifiziert,                Fehlercode: 4008 (3.2)    Zu den Parametern konnte keine Regel ermittelt werden,                Fehlercode: 4019 (4.2.1) Bedingung nicht erfüllt                Fehlercode: wie in Spalte „ErrorCode“ der geprüften Zeile aus                Tabelle „TAB_KON_514-01 Zugriffsregeln Definition“
Nichtfunktionale Anforderungen	keine
Zugehörige Diagramme	PIC_KON_118 Aktivitätsdiagramm zu „TUC_KON_000 Prüfe Zugriffsberechtigung“

[<=]

Eine Beschreibung aller Zugriffsregeln gibt Tabelle TAB_KON_512.

Tabelle 21: TAB_KON_512 Zugriffsregeln Beschreibung 

Regel	Beschreibung
R1	Innerhalb des Mandanten m darf das Clientsystem cs verwendet werden.
R2	Innerhalb des Mandanten m darf das Clientsystem cs auf das Kartenterminal kt zugreifen.
R3	Innerhalb des Mandanten m darf das Clientsystem cs den Arbeitsplatz ap nutzen.
R4	Innerhalb des Mandanten m darf das Clientsystem cs über den Arbeitsplatz ap auf das Kartenterminal kt zugreifen.
R5	Innerhalb des Mandanten m darf das Clientsystem cs über den Arbeitsplatz ap auf die lokal gesteckte eGK zugreifen. Eine Kartensitzung wird nicht benötigt.
R6	Innerhalb des Mandanten m darf das Clientsystem cs über den Arbeitsplatz ap auf die lokal gesteckte eGK zugreifen. Eine Kartensitzung wird benötigt. Wenn bereits eine Kartensitzung besteht, ist sichergestellt, dass sie vom Arbeitsplatz ap gestartet wurde.
R7	Innerhalb des Mandanten m darf das Clientsystem cs über den Arbeitsplatz ap auf die SM-B zugreifen. Es wird dabei sichergestellt, dass es sich um eine im Mandanten verwaltete SM-B handelt.
R8	Innerhalb des Mandanten m darf das Clientsystem cs auf den HBAx zugreifen. Eine Kartensitzung wird nicht benötigt.
R9	Innerhalb des Mandanten m darf das Clientsystem cs auf den HBAx zugreifen. Eine Kartensitzung wird benötigt. Wenn bereits Kartensitzungen zum HBAx bestehen, wird der Zugriff auf den HBAx verhindert, wenn es eine Kartensitzung zum selben Clientsystem, aber einer anderen UserId gibt, deren Sicherheitszustand erhöht ist.

 

Abbildung 6: PIC_KON_118 Aktivitätsdiagramm zu „TUC_KON_000 Prüfe Zugriffsberechtigung“ 

Welche Zugriffsregel für einen gegebenen Satz an Aufrufparametern anzuwenden ist, wird in Tabelle TAB_KON_513 ermittelt. Die Pflichtfelder mandantId, clientSystemId und workplaceId und das optionale Feld userId sind zwar für die Auswertung der Regeln wichtig, tragen aber nicht zur Auswahl der Regel bei und sind daher in der Tabelle nicht vorhanden. Zur Auswahl einer Regel ist relevant,

• ob ctId bzw. cardHandle als Aufrufparameter gesetzt sind (not null) oder leer sind (null),
• von welchem Typ eine Karte ist, falls der Aufrufparameter cardHandle gesetzt ist,
• und welchen Wert die Aufrufparameter „needCardSession“ und „allWorkplaces“ annehmen.

Tabelle 22: TAB_KON_513 Zugriffsregeln Regelzuordnung 

Parameter	R1	R2	R3	R4	R5	R6	R7	R8	R9
ctId	null	not null	null	not null
cardHandle	null	null	null	null	not null	not null	not null	not null	not null
Karte(cardHandle).type					eGK oder KVK	eGK oder KVK
Karte(cardHandle).type							SM-B
Karte(cardHandle).type								HBAx	HBAx
needCardSession	false	false	false	false	false	true	true oder false	false	true
allWorkplaces	true	true	false	false	false	false	false	false	false

Tabelle TAB_KON_514 definiert einzelne Bedingungen, ordnet sie den Regeln zu und definiert ErrorCodes für den Fall, dass eine Bedingung nicht erfüllt ist.

Die Bedingungen in Tabelle TAB_KON_514 sind wie folgt gruppiert:

• Entitäten: Hier wird geprüft, ob die Entitäten, die mit den Aufrufparametern adressiert werden, im Informationsmodell existieren.
• Mandantenbezug: Hier wird geprüft, ob die adressierten Entitäten im Informationsmodell dem adressierten Mandanten zugeordnet sind.
• Relationen: Hier wird geprüft, ob die benötigen Zugriffbeziehungen zum Zugriff auf die adressierten Entitäten im Informationsmodell existieren.
• Kartensitzungen: Hier wird geprüft, ob die benötigte Kartensitzung im Rahmen der bereits existierenden Kartenbeziehungen existieren darf.

Die Fehlercodes mit Beschreibung, ErrorType und Severity Tabelle TAB_KON_515.

Tabelle 23: TAB_KON_514-01 Zugriffsregeln Definition 

	Bedingung (siehe Hinweis 1)	R1	R2	R3	R4	R5	R6	R7	R8	R9	Error Code
Entität (siehe Hinweis 2)	inv : userId <> null									x	4003
	let m : Mandant = Mandant(mandantId) inv : m <> null	x	x	x	x	x	x	x	x	x	4021 an der Außenschnittstelle 4004 im Protokoll (siehe Hinweis 3)
	let cs : Clientsystem     = Clientsystem (clientSystemId) inv : cs <> null	x	x	x	x	x	x	x	x	x	4021 an der Außenschnittstelle 4005 im Protokoll (siehe Hinweis 3)
	let ap : Arbeitsplatz     = Arbeitsplatz (workplaceId) inv : ap <> null			x	x	x	x	x	x	x	4021 an der Außenschnittstelle 4006 im Protokoll (siehe Hinweis 3)
	let kt : Kartenterminal     = Kartenterminal (ctId) inv : kt <> null		x		x						4007
	let k : Karte = Karte (cardHandle) inv :  k <> null					x	x	x	x	x	4008
Mandant bezug	let m : Mandant = Mandant(mandantId) let cs : Clientsystem     = Clientsystem (clientSystemId) inv : cs.mandant. includes(m)	x	x	x	x	x	x	x	x	x	4010
	let m : Mandant = Mandant(mandantId) let ap : Arbeitsplatz     = Arbeitsplatz (workplaceId) inv :  ap.mandant. includes(m)			x	x	x	x	x	x	x	4011
	let m : Mandant = Mandant(mandantId) let kt : Kartenterminal   = Kartenterminal(ctId) inv : kt.mandant. includes(m)		x		x						4012
	let m : Mandant = Mandant(mandantId) let k : Karte = Karte(cardHandle) inv : k.kT-Slot. kartenterminal.mandant        .includes(m)					x	x	x	x	x	4012
Relation	let k : Karte = Karte(cardHandle) inv : k.SM-B_Verwaltet <> null							x			4009
	let m : Mandant = Mandant(mandantId) let k : Karte = Karte(cardHandle) inv : k.SM-B_Verwaltet .mandant       -> includes(m)							x			4013
	let m : Mandant = Mandant(mandantId) let cs : Clientsystem     = Clientsystem (clientSystemId) let ap : Arbeitsplatz     = Arbeitsplatz (workplaceId) inv : CS_AP.allInstances -> exists(c : CS_AP |           c.mandant = m           and c.arbeitsplatz = ap           and c.clientsystem = cs)			x	x	x	x	x	x	x	4014
	let ap : Arbeitsplatz     = Arbeitsplatz (workplaceId) let kt : Kartenterminal     = Kartenterminal (ctId) inv :   ap.lokalKartenterminal .includes(kt) or      ap.entferntKarten terminal .includes(kt)				x						4015
	let ap : Arbeitsplatz     = Arbeitsplatz (workplaceId) let kt : Kartenterminal = Karte(cardHandle).kT-Slot.kartenterminal inv :   ap.lokalKartenterminal .includes(kt) or      ap.entferntKarten terminal .includes(kt)							x	x	x	4015
	let m : Mandant = Mandant (mandantId) let kt : Kartenterminal     = Kartenterminal(ctId) let cs : Clientsystem = Clientsystem (clientSystemId) inv : CS_AP.allInstances -> exists(c : CS_AP | c.arbeitsplatz .lokalKartenterminal    .includes(kt) or c.arbeitsplatz .entferntKartenterminal    .includes(kt) and c.mandant = m and c.arbeitsplatz.mandant .includes(m) and c.clientsystem = cs)		x								4020
	let ap : Arbeitsplatz     = Arbeitsplatz (workplaceId) let kt : Kartenterminal = Karte(cardHandle).kT-Slot.kartenterminal inv : ap.lokalKartenterminal .includes(kt)					x	x				4016
Karten sitzungen	let ap : Arbeitsplatz     = Arbeitsplatz (workplaceId) let k : Karte = Karte(cardHandle) inv : k.kartensitzung       -> not exists(ks : Kartensitzung |            ks.arbeitsplatz <> ap)						x				4017
	let k : Karte = Karte (cardHandle) let cs : Clientsystem     = Clientsystem (clientSystemId) inv : k.kartensitzung     ->  not exists (ks : Kartensitzung |               ks .clientsystem = cs and             ks .userId <> userId and             ks .authState.size() > 0       )									x	4018

Erläuterungen zu TAB_KON_514-01:

Hinweis 1:
Jede Bedingung ist als Constraint mittels OCL definiert, ist einzeln prüfbar und hat als Eingangsparameter mandantId, clientSystemId, workplaceId, ctId, cardHandle und userId.

Hinweis 2:
Zur Bezeichnung einer Objektinstanz, die im Informationsmodell vorhanden ist, wird die Notation <<Entitätsbezeichner>>(<<Komma separierte Liste der Identitätsschlüssel>> verwendet.

Hinweis 3:
Bei manchen Bedingungen gibt es unterschiedliche Fehlermeldungen für die Außenschnittstelle und für die interne Protokollierung. Dann wird folgende Notation in Spalte "Error Code" verwendet:

"<<Fehlercode>> an der Außenschnittstelle" für den Fehlercode, der über die Außenschnittstelle zurückgegeben werden muss

"<<Fehlercode>> im Protokoll" für den Fehlercode, der für die interne Protokollierung verwendet werden muss. 

Tabelle 24: TAB_KON_515 Fehlercodes TUC_KON_000 „Prüfe Zugriffsberechtigung“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4003	Technical	Error	Keine User-ID angegeben, die zur Identifikation der Kartensitzung_HBAx benötigt wird.
4004	Technical	Error	Ungültige Mandanten-ID
4005	Technical	Error	Ungültige Clientsystem-ID
4006	Technical	Error	Ungültige Arbeitsplatz-ID
4007	Technical	Error	Ungültige Kartenterminal-ID
4008	Technical	Error	Karte nicht als gesteckt identifiziert
4009	Security	Error	SM-B ist dem Konnektor nicht als SM-B_Verwaltet bekannt
4010	Security	Error	Clientsystem ist dem Mandanten nicht zugeordnet
4011	Security	Error	Arbeitsplatz ist dem Mandanten nicht zugeordnet
4012	Security	Error	Kartenterminal ist dem Mandanten nicht zugeordnet
4013	Security	Error	SM-B_Verwaltet ist dem Mandanten nicht zugeordnet
4014	Security	Error	Für den Mandanten ist der Arbeitsplatz nicht dem Clientsystem zugeordnet
4015	Security	Error	Kartenterminal ist weder lokal noch entfernt vom Arbeitsplatz aus zugreifbar
4016	Security	Error	Kartenterminal ist nicht lokal vom Arbeitsplatz aus zugreifbar
4017	Security	Error	Die eGK hat bereits eine Kartensitzung, die einem anderen Arbeitsplatz zugeordnet ist.
4018	Security	Error	Der HBAx hat mindestens eine Kartensitzung zu einer anderen UserId, deren Sicherheitszustand erhöht ist.(Sicherheitszustand wird bei PIN-Eingabe erhöht.)
4019	Technical	Error	Zu den Parametern konnte keine Regel ermittelt werden.
4020	Security	Error	Kartenterminal ist weder lokal noch entfernt über irgendeinen dem Clientsystem zugeordneten Arbeitsplatz aus zugreifbar
4021	Technical	Error	Es sind nicht alle Pflichtparameter mandantId, clientSystemId, workplaceId gefüllt.
4204	Security	Error	Clientsystem aus dem Aufrufkontext konnte nicht authentifiziert werden.

Hinweis zu Fehler 4018: Sicherheitszustand wird bei PIN-Eingabe erhöht.

4.1.1.5 Operationen an der Außenschnittstelle

Keine

4.1.1.6 Betriebsaspekte

TIP1-A_4525 - Initialisierung Zugriffsberechtigungsdienst

Der Konnektor MUSS mit Abschluss der Bootup-Phase den Ist-Zustand transienter Entitäten und Beziehungen des Informationsmodells erfasst haben.

[<=]

TIP1-A_4526 - Bearbeitung Informationsmodell Zugriffsberechtigungsdienst

Für die Administration MUSS der Konnektor eine Administrationsoberfläche zur Pflege des Informationsmodells zur Verfügung stellen. Die Oberfläche muss es ermöglichen, sämtliche persistente Entitäten und Beziehungen des durch Abbildung „PIC_Kon_100 Informationsmodell des Konnektors“ und Tabelle „TAB_KON_510 Informationsmodell Constraints“ definierten Informationsmodells initial anzulegen, zu ändern und zu löschen.

[<=]

A_23545 - Anzeige von Telematik-ID bei Auswahl der SMC-B

Der Konnektor MUSS für die Konfiguration der SM-B_Verwaltet in der Auswahl der verfügbaren SMC-B die ICCSN, den OrganizationName und die Telematik-ID aus dem C.HCI.AUT anzeigen. [<=]

A_23546 - Warnung bei unterschiedlichen Telematik-ID in einem Mandanten

Der Konnektor MUSS beim Speichern einer SM-B_Verwaltet-Zuordnung prüfen, ob alle diesem Mandanten zugeordneten SM-B die gleiche Telematik-ID tragen. Bei unterschiedlichen Telematik-ID MUSS dem Administrator eine Warnung angezeigt werden, dass eine ePA-Nutzung mit unterschiedlichen Telematik-ID innerhalb eines Mandanten nicht möglich ist. Der Konnektor MUSS die Telematik-ID im Informationsmodell persistieren. [<=]

Im Anhang I „Umsetzungshinweise“ werden Empfehlungen zur Umsetzung der Administration des Informationsmodells gegeben.

4.1.2 Dokumentvalidierungsdienst

Der Dokumentvalidierungsdienst ist ein Dienst, der nur intern genutzt wird, d. h., dass dessen definierte Verhaltensweisen nur in anderen TUCs des Konnektors nachgenutzt werden. Er bietet Schnittstellen zum Validieren von Dokumenten an. Dabei werden diejenigen spezifischen Dokumentformate unterstützt, die an den Außenschnittstellen anderer Dienste wie Signatur- und Verschlüsselungsdienst auftreten können (Alle_DocFormate gemäß Kapitel 3).

Die jeweils gültigen XML-Schemas der Fachmodule werden den Herstellern von der gematik bereitgestellt.

4.1.2.1 Funktionsmerkmalweite Aspekte

A_18780 - PDF/A-3 DARF NICHT unterstützt werden

Der Konnektor DARF Dokumente im PDF/A-3 Format NICHT unterstützen.
[<=]

4.1.2.2 Durch Ereignisse ausgelöste Reaktionen

Keine.

4.1.2.3 Interne TUCs, nicht durch Fachmodule nutzbar

Keine

4.1.2.4 Interne TUCs, auch durch Fachmodule nutzbar

4.1.2.4.1 TUC_KON_080 „Dokument validieren”

TIP1-A_4527-04 - TUC_KON_080 „Dokument validieren”

Der Konnektor MUSS den technischen Use Case TUC_KON_080 „Dokument validieren” umsetzen.
 

Tabelle 25: TAB_KON_143 – TUC_KON_080 „Dokument validieren“

Element	Beschreibung
Name	TUC_KON_080 „Dokument validieren“
Beschreibung	Dieser TUC prüft das Format eines Dokuments und führt dokumententyp-spezifische Validierungen durch. Unterstützt werden Alle_DocFormate(außer „Binär“).
Auslöser	Aufruf durch Fachmodul Aufruf durch Basisdienst
Vorbedingungen	keine
Eingangsdaten	documentToBeValidated (Zu validierendes Dokument.)  documentFormat (mögliche Werte siehe Definition Alle_DocFormate; Formatangabe für das Dokument) Optional für XML-Dokumente:  xmlSchemas – optional/nur für XML-Dokumente (XML-Schema und ggf. weitere vom Hauptschema benutzte Schemata)  signaturePolicyIdentifier – optional/nur für  XML-Formate gemäß einer referenzierten Signaturrichtlinie (URI identifiziert die Signaturrichtlinie)
Komponenten	Konnektor
Ausgangsdaten	documentValidationProtocol (Prüfprotokoll) Die Ausprägung dieses Konnektor-internen Parameters erfolgt herstellerspezifisch.
Nachbedingungen	Keine
Standardablauf	Validierung der Dokumente auf Typkonformität Der Konnektor führt je nach Format des Dokuments (documentFormat) eine der folgenden Prüfungen durch: A) XML-Dokumentvalidierung Im Fall eines XML-Dokuments prüft der Konnektor: Prüfe die XML-Wohlgeformtheit des Dokumentes (documentToBeValidated) Wenn signaturePolicyIdentifier vorhanden ist, dann ermittle das xmlSchema aus der referenzierten Signaturrichtlinie und prüfe die Validität von documentToBeValidated in Bezug auf das hinterlegte XML-Schema. Der Eingangsparameter xmlSchemas wird ignoriert. Wenn signaturePolicyIdentifier nicht vorhanden ist und xmlSchemas übergeben wurden, dann prüfe die Wohlgeformtheit von xmlSchemas und die Validität von documentToBeValidated in Bezug auf xmlSchemas. Wenn nicht durch Prüfung gegen XML-Schema bereits erfolgt, dann prüfe die Eindeutigkeit der ID-Attributwerte im XML-Dokument.   B) PDF/A-Dokumentvalidierung PDF/A-Dokumente werden geprüft, ob sie sich als PDF/A Dokumente in ihren PDF/A-Metadaten ausweisen. Es werden alle PDF/A-1 und PDF/A-2 konformen Dokumente unterstützt, einschließlich PDF/A-1A, PDF/A-1B, PDF/A-2A, PDF/A-2B, PDF/A-2U. Beispiele: <pdfaid:part xmlns:pdfaid="http://www.aiim.org/pdfa/ns/id/">1</pdfaid:part> <rdf:Description rdf:about="" xmlns:pdfaid="http://www.aiim.org/pdfa/ns/id/" pdfaid:part="1" pdfaid:conformance="B"/> C) TIFF-Dokumentvalidierung Der Konnektor prüft, ob das Dokument an Hand seiner ersten 8 Byte als TIFF-Dokument [TIFF6] zu identifizieren ist. D) MIME-Dokumentvalidierung Die Struktur von MIME-Dokumenten wird entsprechend [MIME] validiert. E) Text-Dokumentvalidierung Der Konnektor prüft die Konformität zum im Dokumentenformat vorgegebenen Character-Encoding. Für Binärdokumente findet keine Validierung statt. Hinweis: Byte-order-marks (BOM) sind im Rahmen von UTF-8 kodierten Dokumenten gemäß UTF8 Standard ([RFC3629], Kapitel 6) erlaubt, aber nicht notwendigerweise im Dokument vorhanden. Validierung der Dokumentformate Der Konnektor prüft für das Dokument, ob die Vorgaben zu Dokumenten aus Kapitel 3.1.1 "Dokumentformate" eingehalten sind.
Varianten/ Alternativen	keine
Fehlerfälle	Standardablauf: Bei der Dokumentenvalidierung protokolliert der TUC alle aufgetretenen Fehler im Rückgabewert documentValidationProtocol. Validierung der Dokumente auf Typkonformität (A) Fehlerfälle bei XML-Dokumentvalidierung Wenn keine Schemata übergeben wurden (xmlSchemas oder signaturePolicyIdentifier nicht vorhanden): Fehlercode 4193 Wenn eines der übergebenen Schemata selbst nicht wohlgeformt oder invalide ist, wird Fehlercode 4026 gemeldet. Wenn das XML-Dokument nicht wohlgeformt ist, wird Fehlercode 4022 gemeldet. Das XML-Dokument ist nicht valide in Bezug auf das zur Validierung benutzte Schema (xmlSchemas bzw. signaturePolicyIdentifier): Fehlercode 4023. (B) Fehlerfälle bei PDF/A-Dokumentvalidierung Bei fehlgeschlagener Validierung: Fehlercode 4024, Dokumentformat = PDF/A (C) Fehlerfälle bei TIFF-Dokumentvalidierung Bei fehlgeschlagener Validierung: Fehlercode 4024, Dokumentformat = TIFF (D) Fehlerfälle bei MIME-Dokumentvalidierung Bei fehlgeschlagener Validierung: Fehlercode 4024, Dokumentformat = MIME (E) Fehlerfälle bei Text-Dokumentvalidierung Bei fehlgeschlagener Validierung: Fehlercode 4024, Dokumentformat = Text Validierung der Dokumentformate Bei Verletzung einer Vorgabe aus Kapitel 3.1.1 bricht der Konnektor die Verarbeitung mit einem entsprechenden Fehlercode ab.
Nichtfunktionale Anforderungen	keine
Zugehörige Diagramme	keine

 

Tabelle 26: TAB_KON_144 Fehlercodes TUC_KON_080 „Dokument validieren“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases und Fehlercodes aus Kapitel 3.1.1  können folgende weitere Fehlercodes auftreten:
4022	Security	Error	XML-Dokument nicht wohlgeformt
4023	Security	Error	XML-Dokument nicht valide in Bezug auf XML-Schema
4024	Security	Error	Formatvalidierung fehlgeschlagen (<Dokumentformat>) Der Parameter Dokumentformat kann die Werte XML, PDF/A, TIFF, MIME und Text annehmen.
4026	Security	Error	XML-Schema nicht valide
4193	Security	Warning	kein XML-Schema für XML-Dokument vorhanden

[<=]

4.1.2.5 Operationen an der Außenschnittstelle

Keine

4.1.2.6 Betriebsaspekte

Keine

4.1.3 Dienstverzeichnisdienst

Der Dienstverzeichnisdienst liefert dem aufrufenden Clientsystem sowohl Informationen über die Version und Produktkenndaten des Konnektors, als auch die SOAP-Endpunkte, über die das Clientsystem die einzelnen Dienstoperationen erreichen kann.

4.1.3.1 Funktionsmerkmalweite Aspekte

Die Endpunkte der Basisdienste werden in WSDL spezifiziert. Diese Endpunkte und weitere konnektormodellspezifische Informationen werden dem Clientsystem in Form eines Dienstverzeichnisdienstes gesammelt angeboten.

Der prinzipielle Ablauf sieht dabei folgendermaßen aus:

Das Clientsystem ruft beim Initialisieren des Systems mit HTTP-GET die vordefinierte URL:     https://<ANLW_LAN_IP_ADDRESS oder     MGM_KONN_HOSTNAME>/connector.sds oderhttp://<ANLW_LAN_IP_ADDRESS oder MGM_KONN_HOSTNAME>/connector.sds des Konnektors auf.

Der Konnektor stellt die Liste der Dienste, der Versionen und die Endpunkte der Dienste in einem XML-Dokument zusammen. Jeder über SOAP erreichbare Basisdienst des Konnektors wird in dieser Liste geführt. Ferner können Fachmodule ihre eigenen Endpunkte über TUC_KON_041 „Einbringen der Endpunktinformationen während der Bootup-Phase“ einbringen. Die so erstellte Liste der Dienste wird als Antwort an das Clientsystem übergeben.

Das Clientsystem prüft, ob die gewünschten Dienste und Versionen unterstützt werden und merkt sich die Endpunkte der Dienste für die späteren Aufrufe. Danach kann das Clientsystem diese Dienstendpunkte nach Bedarf aufrufen.

TIP1-A_4528 - Bereitstellen des Dienstverzeichnisdienst

Der Konnektor MUSS den Dienstverzeichnisdienst anbieten. Dieser Dienst veröffentlicht auf:     https://$ANLW_LAN_IP_ADDRESS oder $MGM_KONN_HOSTNAME>/connector.sds oder     http://$ANLW_LAN_IP_ADDRESS oder $MGM_KONN_HOSTNAME>/connector.sds.

Die Datei MUSS über https erreichbar sein.

Wenn (ANCL_DVD_OPEN = Enabled) oder (ANCL_TLS_MANDATORY = Disabled) MUSS die Datei auch über http erreichbar sein.

[<=]

TIP1-A_4529-02 - Formatierung der Ausgabedatei

Das XML-Dokument, welches als „connector.sds“ dem Aufrufer zurückgeliefert wird, MUSS gemäß dem Schema „conn/ServiceDirectory.xsd“ formatiert sein. conn/ServiceDirectory.xsd referenziert die Schemata „tel/version/ProductInformation.xsd“ (siehe [gemSpec_OM]) und „conn/ServiceInformation.xsd“.
TAB_KON_516, TAB_KON_517 und TAB_KON_518 beschreiben die Elemente der zu verwendenden Schemastruktur.
 

Tabelle 27: TAB_KON_516 Basisanwendung Dienstverzeichnisdienst 

Name	ConnectorServiceDirectory
Version	3.1.0 (XSD-Version)
Namensraum	Siehe GitHub
Namensraum-Kürzel	CONN
Operationen	Lesen der vom Konnektor unterstützten Dienste
WSDL	Keine
Schema	ServiceDirectory.xsd

Tabelle 28: TAB_KON_517 Schemabeschreibung Produktinformation (ProductInformation.xsd) 

 

Element	Bedeutung
ProductInformation/InformationDate	Datum der Informationsabfrage über das Produkt
ProductInformation/ProductTypeInformation/ ProductType	Produkttyp (Konnektor)
ProductInformation/ProductTypeInformation/ ProductTypeVersion	Produkttypversion des Konnektormodells
ProductInformation/ProductIdentification/ ProductVendorID	ID des Konnektorherstellers
ProductInformation/ProductIdentification/ ProductCode	Produktkürzel
ProductInformation/ProductIdentification/ ProductVersion/Local/HWVersion	Hardwareversion des Konnektormodells
ProductInformation/ProductIdentification/ ProductVersion/Local/FWVersion	Firmwareversion des Konnektormodells
ProductInformation/ProductMiscellaneous/ ProductVendorName	Name des Konnektorherstellers
ProductInformation/ProductMiscellaneous/ ProductName	Produktname

Tabelle 29: TAB_KON_518 Schemabeschreibung Serviceinformation (Serviceinformation.xsd) 

Element	Bedeutung
ServiceInformation/Service	Element beschreibt einen Dienst oder ein Fachmodul
ServiceInformation/Service/@Name	Name des Dienstes. Dieser Wert korrespondiert mit dem Feld „Name“ aus der jeweiligen Basisanwendung/Dienstbeschreibung (englischer Dienstname in Tabelle TAB_KON_798).
ServiceInformation/Service/Abstract	eine kurze textuelle Beschreibung des Dienstes/Fachmoduls
ServiceInformation/Service/Versions	die Liste der unterstützten Versionen
ServiceInformation/Service/Versions/Version	Beschreibung der Dienstversion/Fachmodulversion
ServiceInformation/ Service/Versions/Version/@TargetNamespace	der Namensraum der Dienst-/Fachmodulversion
ServiceInformation/Service/Versions/Version/@Version	Vollständige Versionsnummer (Konnektordienstversion) des Dienstes/Fachmoduls. Dieser Wert entspricht dem Wert „WSDL-Version“ des jeweiligen Dienstes in Tabelle TAB_KON_798.
ServiceInformation/Service/Versions/Version/Abstract	Eine kurze textuelle Beschreibung dieser Version des Dienstes/Fachmoduls
ServiceInformation/ Service/Versions/Version/EndpointTLS/@Location	Absoluter URL des über TLS erreichbaren Dienstes.
ServiceInformation/ Service/Versions/Version/Endpoint/@Location	Absoluter URL des erreichbaren Dienstes (ohne TLS).
ServiceInformation/ Service/Versions/Version/WSDL/@Location	(optional) Absoluter URL der WSDL-Beschreibung

[<=]

TIP1-A_4530 - Aufbau Dienst URLs

Die URLs der Dienste KÖNNEN herstellerspezifisch aufgebaut werden.

[<=]

4.1.3.2 Durch Ereignisse ausgelöste Reaktionen

Keine.

4.1.3.3 Interne TUCs, nicht durch Fachmodule nutzbar

Keine

4.1.3.4 Interne TUCs, auch durch Fachmodule nutzbar

Da der Konnektor als Black-Box mit inkludierten Fachmodulen ohne erkennbare Innenschnittstellen spezifiziert wird, stellt der folgende TUC lediglich einen Mechanismus zur editoriellen Kopplung der Fachmodulspezifikationen mit der Konnektorspezifikation dar:

4.1.3.4.1 TUC_KON_041 „Einbringen der Endpunktinformationen während der Bootup-Phase“

TIP1-A_4531 - TUC_KON_041 „Einbringen der Endpunktinformationen während der Bootup-Phase“

Der Dienstverzeichnisdienst des Konnektors MUSS es den Fachmodulen ermöglichen, die zum jeweiligen Fachmodul gehörenden Endpunkte während der Bootup-Phase des Konnektors in den Dienstverzeichnisdienst einzubringen.
 

Tabelle 30: TAB_KON_519 - TUC_KON_041 „Einbringen der Endpunktinformationen während der Bootup-Phase“ 

Element	Beschreibung
Name	TUC_KON_041 „Einbringen der Endpunktinformationen während der Bootup-Phase“
Beschreibung	Fachmodule MÜSSEN ihre Endpunktinformationen während der Bootup-Phase in den Dienstverzeichnisdienst einbringen können.
Auslöser und Vorbedingungen	Keine
Eingangsdaten	serviceInformation (Ein XML-Dokument mit dem Wurzelelement „ServiceInformation“ gemäß dem Schema „Serviceinformation.xsd“. Eine Beschreibung des Schemas befindet sich in TAB_KON_518.)
Komponenten	Konnektor, Fachmodule
Ausgangsdaten	Keine
Standardablauf	Die übergebenen Serviceinformationen des Fachmoduls werden in die Gesamtstruktur „connector.sds“ aufgenommen. Falls beim Speichern der eingebrachten Endpunktinformationen ein Fehler auftritt, wird Fehler 4027 ausgelöst.
Varianten/Alternativen	Keine
Fehlerfälle	4027: Die Endpunktinformationen konnten nicht übernommen werden.
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	Keine

 

Tabelle 31: TAB_KON_520 Fehlercodes TUC_KON_041 „Einbringen der Endpunktinformationen während der Bootup-Phase“ 

Fehlercode	ErrorType	Severity	Fehlertext
4027	Technical	Error	Die Endpunktinformationen konnten nicht übernommen werden.

[<=]

4.1.3.5 Operationen an der Außenschnittstelle

TIP1-A_4532 - Schnittstelle der Basisanwendung Dienstverzeichnisdienst

Der Dienstverzeichnisdienst des Konnektors MUSS die in Tabelle TAB_KON_521 Schnittstelle der Basisanwendung Dienstverzeichnisdienst beschriebene Schnittstelle anbieten.

Tabelle 32: TAB_KON_521 Schnittstelle der Basisanwendung Dienstverzeichnisdienst

Dienstname	ConnectorServiceDirectory
Beschreibung	Der Aufruf liefert Angaben über den Hersteller, über das Konnektormodell und die Liste der Dienste, Konnektordienstversionen (KDV) und Endpunkte der Dienste.
Aufruf	GET /connector.sds HTTP/1.1 Host: ANLW_LAN_IP_ADDRESS oder MGM_KONN_HOSTNAME
Rückgabe	Das Antwortdokument ist in der Schemadatei ServiceDirectory.xsd beschrieben.
	ConnectorServices
	Name	Beschreibung
	ProductInformation	Kurzbeschreibung des Konnektormodells
	ServiceInformation	Beschreibung der Dienste
	ProductInformation: Das Schema wird in TAB_KON_517 beschrieben. Die Felder sind gemäß [gemSpec_OM] zu befüllen und gemäß dem Schema „ProductInformation.xsd“ zu formatieren.
	TLS-Mandatory: Boolean Wert der festlegt, ob die Verwendung eines TLS-Kanals für Dienstaufrufe verpflichtend ist. Definierende Variable ist: ANCL_TLS_MANDATORY ClientAutMandatory: Boolean Wert der festlegt, ob Client Authentifizierung verpflichtend ist. Definierende Variable ist: ANCL_CAUT_MANDATORY.
	ServiceInformation: Das Schema wird in TAB_KON_518 beschrieben. Die Felder sind gemäß dem Schema ServiceInformation.xsd zu formatieren. Falls (ANCL_CAUT_MANDATORY = Enabled) oder (ANCL_TLS_MANDATORY = Enabled), MUSS die Rückgabedatei ausschließlich https-Endpunkte enthalten.
Fehlercodes	Die Standard HTTP1.1 Fehlercodes [RFC2616]
Vorbedingungen	Keine
Nachbedingungen	Keine
Hinweise	Keine

​​

[<=]

4.1.3.6 Betriebsaspekte

TIP1-A_4533 - Dienstverzeichnisdienst initialisieren.

Mit Abschluss der Bootup-Phase MUSS der Dienstverzeichnisdienst an der Außenschnittstelle die vollständige Liste aller Services bereitstellen, die der Anwendungskonnektor den Clientsystemen anbietet, inklusive der Services der Fachmodule.

[<=]

4.1.4 Kartenterminaldienst

Die Aufgabe des Kartenterminaldienstes ist das Management aller vom Konnektor adressierbaren Kartenterminals. Dies umfasst alle administrativen Prozesse (insbesondere das Pairing, vgl. [gemSpec_KT#2.5.2]). Ferner kapselt der Kartenterminaldienst die Zugriffe auf Kartenterminals durch Basisdienste und Fachmodule.

Für die TLS-Verbindungen zu den Kartenterminals muss der Konnektor die Vorgaben aus [gemSpec_Krypt#3.3.2] und hinsichtlich ECC-Migration die Vorgaben aus [gemSpec_Krypt#5] befolgen.

Innerhalb des Kartenterminaldienstes werden folgende Präfixe für Bezeichner verwendet:

• Events (Topic Ebene 1):    „CT“
• Konfigurationsparameter:    „CTM_“

Der Kartenterminaldienst verwaltet hinsichtlich der Kartenterminals mindestens die in der informativen Tabelle TAB_KON_522 Parameterübersicht des Kartenterminaldienstes ausgewiesenen Parameter, weitere herstellerspezifische Parameter sind möglich. Die normative Festlegung wann welche Parameter mit welchen Werten belegt werden, erfolgt in den folgenden Abschnitten und Unterkapiteln.

Dabei beschrieben CTM_xyz-Bezeichner Parameter, die den Dienst als Ganzes betreffen. Zu jedem Kartenterminal selbst werden dessen Parameter in einem CT-Object gekapselt. Die folgende Tabelle zeigt die Attribute der jeweiligen CT-Objekte über Punktschreibweise.

Tabelle 33: TAB_KON_522 Parameterübersicht des Kartenterminaldienstes 

ReferenzID	Belegung	Zustandswerte
CTM_CT_LIST	Liste von CT-Objekten	Eine Liste von Repräsentanzen (CT-Objects) der dem Konnektor bekannten Kartenterminals.
Pro CTM_CT_LIST Eintrag:
Gerätekenndaten
CT.CTID	Identifier	Eindeutige, statische Identifikation des Kartenterminals
CT.IS_PHYSICAL	Ja/Nein	Kennzeichnung, ob es sich um ein physisches oder logisches Kartenterminal handelt, zur Unterscheidung von eHealth-Kartenterminals und HSM-Bs. Da dieser Unterschied gemäß der aktuellen HSM-B-Lösung für den Konnektor transparent ist, wird der Parameter in dieser Spezifikation immer auf „Ja“ gesetzt. Der Parameterwert „Nein“ ist für zukünftige Nutzung vorgesehen.
CT.MAC_ADRESS	MAC-Adresse	Die MAC-Adresse des Kartenterminals
CT.HOSTNAME	String	SICCT-Terminalname des Kartenterminals, auch als FriendlyName bezeichnet
CT.IP_ADRESS	IP-Adresse	Die IP-Adresse des Kartenterminals
CT.TCP_PORT	Portnummer	Der TCP-Port des SICCT-Kommandointerpreters des Kartenterminals
CT.SLOTCOUNT	Nummer	Anzahl der Slots des Kartenterminals
CT.SLOTS_USED	Liste	Liste der aktuell mit Karten belegten Slots
CT.PRODUCT INFORMATION	Inhalt ProductIn formation.xsd	Die Herstellerinformationen zum Kartenterminal gemäß [gemSpec_OM]
CT.EHEALTH_ INTERFACE_VERSION	Version	Die EHEALTH-Interface-Version des Kartenterminals, die mittels GET STATUS aus dem Element VER des Discretionary Data Objects ermittelt wurde.
CT.VALID_VERSION	Boolean	True, wenn die Version des Kartenterminals (CT.EHEALTH_INTERFACE_VERSION) durch den Konnektor unterstützt wird, d.h. zu den in CTM_SUPPORTED_KT_VERSIONS passt Default-Wert = false
CT.DISPLAY_CAPABILITIES	Datenstruktur	Displayeigenschaften wie in der Struktur Display Capabilities Data Object in [SICCT#5.5.10.17] beschrieben
Pairingdaten
CT.SMKT_AUT	X.509-Cert	C.SMKT.AUT-Zertifikat des Kartenterminals, gespeichert im Rahmen des Pairings
CT.SHARED_SECRET		ShS.KT.AUT, gespeichert im Rahmen des Pairings
Verbindungsdaten
CT.CORRELATION	bekannt zugewiesen gepairt aktiv aktualisierend	Der Korrelationsstatus zum Konnektor: bekannt (über Service Announcement/Service Discovery gelernte Kartenterminals), zugewiesen (durch den Administrator aus dem Bereich der bekannten Kartenterminals oder manuell konfigurierte Kartenterminals), gepairt (Pairing erfolgreich aber noch nicht zum Verbindungsaufbau freigegeben) aktiv (durch Administrator zum Verbindungsaufbau freigegeben), aktualisierend (ein laufender Updatevorgang, ausgelöst durch den Konnektor; Der Zustand tritt ein, wenn der Kartenterminaldienst das Event „KSR/UPDATE/START" fängt und endet mit dem Event „KSR/UPDATE/END")
CT.CONNECTED	Ja/Nein	Der Verfügbarkeitsstatus des Kartenterminals (Ja = nach Aufbau der TLS-Verbindung und erfolgter zweiter Authentifizierung)
CT.ACTIVEROLE	User/Admin	Benutzerrolle, die für die aktuelle Session verwendet wird
KT-Admin-Credentials
CT.ADMIN_USERNAME	String	Username des Administrators am KT
CT.ADMIN_PASSWORD	String	Password des Administrators am KT

Zum besseren Verständnis sind die Zustände, die ein Kartenterminal einnehmen kann, im nachfolgenden Zustandsdiagramm PIC_KON_071 dargestellt.

Abbildung 7: PIC_KON_071 Korrelationszustände eines eHealth-KT 

4.1.4.1 Funktionsmerkmalweite Aspekte

TIP1-A_4534 - Kartenterminals nach eHealth-KT-Spezifikation

Der Kartenterminaldienst MUSS Kartenterminals nach der eHealth-Kartenterminal Spezifikation [gemSpec_KT] unterstützen.

[<=]

Zur Unterstützung von HSM-Bs benötigt der Konnektor virtuelle Kartenterminals (CT.IS_PHYSICAL=Nein), in denen virtuelle SMC-Bs „stecken“ können (siehe Kapitel 4.1.4). Diese Kartenterminals werden innerhalb des Zugriffsberechtigungsdienstes sowie des Systeminformationsdienstes wie normale Kartenterminals berücksichtigt. Weitere Details zu den logischen Kartenterminals finden sich im Kapitel Betriebsaspekte.

TIP1-A_4535 - Unterstützung logischer Kartenterminals für HSMs

Der Kartenterminaldienst MUSS logische Kartenterminals mit logischen Slots unterstützen. Zu jedem verwalteten HSM (siehe Kartendienst) MUSS der Konnektor ein oder mehrere logische Kartenterminal mit folgenden Bedingungen vorhalten:

• Jedes logische KT MUSS als CT-Object mit eindeutiger CTID in CTM_CT_LIST enthalten sein
• Die CT-Attribute MÜSSEN gemäß TAB_KON_522 Parameterübersicht des Kartenterminaldienstes gesetzt werden.

[<=]

TIP1-A_4536 - TLS-Verbindung zu Kartenterminals halten

Der Kartenterminaldienst MUSS jede mit einem Kartenterminal etablierte Verbindung durch Nutzung des in [SICCT#6.1.4.5] definierten Keep-Alive Mechanismus halten. Der Konnektor MUSS für das Heartbeat-Interval gemäß [SICCT#6.1.4.5] den Wert CTM_KEEP_ALIVE_INTERVAL verwenden und beim Ausbleiben von Terminal-Antworten eines Kartenterminals nach der Anzahl von  CTM_KEEP_ALIVE_TRY_COUNT Versuchen die Netzwerkverbindung zu diesem Kartenterminal beenden.

[<=]

TIP1-A_6725 - Lebensdauer von Textanzeigen am Kartenterminal

Der Konnektor MUSS steuern, dass Textanzeigen am Kartenterminal nur so lange angezeigt werden, wie sie im jeweiligen Anwendungskontext benötigt werden.

[<=]

Ziel der Textanzeigen am Kartenterminal ist die Kommunikation mit dem Benutzer zur Unterstützung der Anwendungsfälle. Die Anzeige am Kartenterminal muss daher einen engen zeitlichen Bezug zum jeweiligen Anwendungskontext haben.

Nachrichten, deren Anwendungskontext mit einem Event beendet werden, wie etwa die Aufforderung zum Stecken der Karte im Kontext von TUC_KON_056, deren inhaltliche Berechtigung mit dem Stecken der Karte erlischt, (ebenso zum Ziehen der Karte im Rahmen von TUC_KON_057) müssen sofort gelöscht werden, wenn das Event eintritt.  

Nachrichten, deren Lebensdauer nicht durch ein natürliches Event beendet wird, müssen eine vordefinierte Lebensdauer erhalten, die per Konfiguration an die Bedürfnisse der Leistungserbringer anpassbar sein sollte. Das gilt für Ergebnisanzeigen oder Anzeigen von Fehlern.

TIP1-A_4537 - KT-Statusanpassung bei Beendigung oder Timeout einer Netzwerkverbindung

Tritt ein Timeout ein oder wird eine Netzwerkverbindung zu einem Kartenterminal (oder zu einem HSM, welches einem logischen Kartenterminal zugeordnet ist) beendet oder zurückgesetzt und ist CT.CONNECTED = Ja, so MUSS der Konnektor:

• CT.CONNECTED für das Kartenterminal auf „Nein“ setzen
• Für jeden in CT.SLOTS_USED gelisteten Slot X zur weiteren internen Bearbeitung TUC_KON_256 {
      topic = „CT/SLOT_FREE“;
      eventType = Op;
      severity = Info;
      parameters = („CtID=$CT.CTID, SlotNo=$X“);
      doLog = false;
      doDisp = false }
  rufen
• TUC_KON_256 {
      topic = „CT/DISCONNECTED“;
      eventType = Op;
      severity = Info;
      parameters = („CtID=$CT.CTID,    Hostname=$CT.HOSTNAME“) }
  auslösen
• CT.SLOTS_USED leeren

[<=]

TIP1-A_4538 - Wiederholter Verbindungsversuch zu den KTs

Sind in CTM_CT_LIST Kartenterminals mit CT.CONNECTED=Nein und CT.VALID_VERSION = True und CT.CORRELATION = „aktiv“ und ist CTM_SERVICE_DISCOVERY_CYCLE>0, MUSS der Konnektor im Zeitabstand CTM_SERVICE_DISCOVERY_CYCLE-Minuten entweder eine Service Discovery-Nachricht an alle KTs als Broadcast oder an jedes einzelne dieser unverbundenen KTs als Unicast senden.
[<=]

TIP1-A_4538-02 - ab PTV4: Wiederholter Verbindungsversuch zu den KTs

Sind in CTM_CT_LIST Kartenterminals mit CT.CONNECTED=Nein und CT.VALID_VERSION = True und CT.CORRELATION = „aktiv“ und ist CTM_SERVICE_DISCOVERY_CYCLE>0, MUSS der Konnektor im Zeitabstand CTM_SERVICE_DISCOVERY_CYCLE-Minuten an jedes einzelne dieser unverbundenen KTs eine Service-Discovery-Nachricht als Unicast senden.
[<=]

TIP1-A_6478 - Erlaubte SICCT-Kommandos bei CT.CONNECTED=Nein

Der Kartenterminaldienst DARF SICCT-bzw. EHEALTH-Kommandos NICHT an ein Kartenterminal senden, wenn für dieses Kartenterminal CT.CONNECTED=Nein gesetzt ist. Ausgenommen hiervon sind die in TAB_KON_785 gelisteten EHEALTH- bzw. SICCT-Kommandos.

[<=]

Tabelle 34: TAB_KON_785 Erlaubte SICCT-Kommandos bei CT.CONNECTED=Nein 

SICCT-Kommando

SICCT CT INIT CT SESSION

SICCT CT CLOSE SESSION

SICCT GET STATUS

SICCT SET STATUS

SICCT CT DOWNLOAD INIT

SICCT CT DOWNLOAD DATA

SICCT CT DOWNLOAD FINISH

EHEALTH TERMINAL AUTHENTICATE

TIP1-A_4539 - Robuster Kartenterminaldienst

Das Ziehen einer Karte während einer Kartenaktion DARF NICHT dazu führen, dass das verwaltete Kartenterminal im Anschluss durch den Konnektor nicht weiter genutzt werden kann. Die entsprechende Ressource MUSS nach Erkennung der Fehlersituation freigegeben werden. Ein manuelles Eingreifen DARF NICHT erforderlich sein.

[<=]

TIP1-A_5408 - Terminal-Anzeigen beim Anfordern und Auswerfen von Karten

Der Konnektor MUSS beim Anfordern und Auswerfen von Karten die folgenden Display-Nachrichten für die Anzeige im Kartenterminal verwenden, wenn der Aufrufer keine konkrete Display-Nachricht übergeben hat. Der Verweis auf den Kartenterminal-Slot SOLL in der Display-Nachricht entfallen, wenn es keine Slot-Auswahl am Kartenterminal gibt.
 

Tabelle 35: TAB_KON_727 Terminalanzeigen beim Anfordern und Auswerfen von Karten 

Kontext	Kartentyp	Terminal-Anzeige
Karte anfordern	EGK	Bitte•0x0BeGK•0x0Bin •0x0BSLOT X•0x0Bstecken
	HBA, HBAx, HBA-qSig	Bitte•0x0BHBA•0x0Bin •0x0BSLOT X•0x0Bstecken
	SMC-B	Bitte•0x0BSMC-B•0x0Bin •0x0BSLOT X•0x0Bstecken
	sonstiger Kartentyp oder kein explizit angegebener Kartentyp	Bitte•0x0BKarte•0x0Bin •0x0BSLOT X•0x0Bstecken
Karte auswerfen	EGK	Bitte•0x0BeGK•0x0Baus •0x0BSLOT X•0x0Bentnehmen
	HBA, HBAx, HBA-qSig	Bitte•0x0BHBA•0x0Baus •0x0BSLOT X•0x0Bentnehmen
	SMC-B	Bitte•0x0BSMC-B•0x0Baus •0x0BSLOT X•0x0Bentnehmen
	sonstiger Kartentyp oder kein explizit angegebener Kartentyp	Bitte•0x0BKarte•0x0Bentnehmen

[<=]

4.1.4.2 Durch Ereignisse ausgelöste Reaktionen

TIP1-A_4540 - Reaktion auf Dienstbeschreibungspakete

Der Konnektor MUSS Service Announcement für das Auffinden von Kartenterminals entsprechend [SICCT] und [gemSpec_KT] unterstützen. Der Konnektor MUSS Dienstbeschreibungspakete auf UDP Port CTM_SERVICE_ANNOUNCEMENT_PORT entgegennehmen.

Erhält er ein solches Dienstbeschreibungspaket, MUSS er

• TUC_KON_054 mit Mode=AutoAdded und IP-Adresse; TCP-Port; MAC-Adresse; Hostname aus dem Dienstbeschreibungspaket, aufrufen
• für das mit der MAC-Adressen in CTM_CT_LIST korrelierende CT-Object, wenn CT.CORRELATION > "bekannt" und CT.VALID_VERSION = true ist, TUC_KON_050 { ctId = CT.CtID; role = „User“} aufrufen.

[<=]

TIP1-A_4541 - Reaktion auf KT-Slot-Ereignis – Karte eingesteckt

Der Kartenterminaldienst MUSS auf SICCT-Ereignisnachrichten „Slot-Ereignis – Karte eingesteckt“ ([SICCT#6.1.4.4], TAG ‚84’) wie folgt reagieren:

• das meldende Kartenterminal CT in CTM_CT_LIST ermitteln,
• den in der Ereignisnachricht benannten Slot (FU-Nummer) in CT.SLOTS_USED aufnehmen,
• zur weiteren internen Bearbeitung rufe TUC_KON_256 {
      topic = „CT/SLOT_IN_USE“;
      eventType = Op;
      severity = Info;
      parameters = („CtID=$CT.CTID,
          SlotNo=<FU-Nummer aus Ereignisnachricht>„);
      doLog = false;
      doDisp = false } auf.

[<=]

TIP1-A_4542 - Reaktion auf KT-Slot-Ereignis – Karte entfernt

Der Kartenterminaldienst MUSS auf SICCT-Ereignisnachrichten „Slot-Ereignis – Karte entfernt“ ([SICCT#6.1.4.4], TAG ‚85’) wie folgt reagieren:

• das meldende Kartenterminal CT in CTM_CT_LIST ermitteln,
• den in der Ereignisnachricht benannten Slot (FU-Nummer) aus CT.SLOTS_USED entfernen,
• zur weiteren internen Bearbeitung rufe TUC_KON_256 {
      topic = „CT/SLOT_FREE“;
      eventType = Op;
      severity = Info;
      parameters = („CtID=$CT.CTID,
          SlotNo==<FU-Nummer aus Ereignisnachricht>„„);
      doLog = false;
      doDisp = false }
  auf.

[<=]

TIP1-A_4543 - KT-Statusanpassung bei Beginn eines Updatevorgangs

Tritt der Event "KSR/UPDATE/START" mit „Target=KT“ ein, MUSS der Konnektor:

• Setze CT = CTM_CT_LIST(CTID-Parameter des Ereignisses)
• CT.CORRELATION für das Kartenterminal merken und auf „aktualisierend“ setzen
• Für jeden in CT.SLOTS_USED gelisteten Slot X zur weiteren internen Bearbeitung TUC_KON_256 {
      topic = „CT/SLOT_FREE“;
      eventType = Op;
      severity = Info;
      parameters = („CtID=$CT.CTID, SlotNo=$CT.SLOTS_USED[X]“);
      doLog = false;
      doDisp = false
  } aufrufen

[<=]

TIP1-A_4544 - KT-Statusanpassung bei Ende eines Updatevorgangs

Tritt der Event "KSR/UPDATE/END" mit „Target=KT“ ein, MUSS der Konnektor:

• Setze CT = CTM_CT_LIST(CTID-Parameter des Ereignisses)
• CT.CORRELATION auf den beim „KSR/UPDATE/START“ gemerkten Wert setzen
• Aktualisiere Gerätedaten durch Aufruf TUC_KON_055 „Befülle CT-Object“ { ctId = CTID}
• Wenn CT.VALID_VERSION = true, Rufe TUC_KON_050 „Beginne Kartenterminalsitzung“ { ctId = CTID; role = „User“}
• Wenn CT.VALID_VERSION = false und CT.CORRELATION = „aktiv“, setze CT.CORRELATION=„gepairt“

[<=]

4.1.4.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.1.4.3.1 TUC_KON_050 „Beginne Kartenterminalsitzung“

TIP1-A_4545-03 - TUC_KON_050 „Beginne Kartenterminalsitzung“

Der Konnektor MUSS den technischen Use Case „Beginne Kartenterminalsitzung” gemäß TUC_KON_050 umsetzen.
 

Tabelle 36: TAB_KON_039 – TUC_KON_050 „Beginne Kartenterminalsitzung“ 

Abbildung 8: PIC_KON_110 Aktivitätsdiagramm zu „Beginne Kartenterminalsitzung“ 

Tabelle 37: TAB_KON_523 Fehlercodes TUC_KON_050 „Beginne Kartenterminalsitzung“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4028	Technical	Error	Fehler beim Versuch eines Verbindungsaufbaus zu KT
4029	Security	Error	Fehler bei der KT-Authentisierung. KT möglicherweise manipuliert
4030	Security	Error	Admin-Werte für KT fehlerhaft
4032	Technical	Error	Verbindung zu HSM konnte nicht aufgebaut werden

[<=]

4.1.4.3.2 TUC_KON_054 „Kartenterminal hinzufügen“

TIP1-A_4546 - TUC_KON_054 „Kartenterminal hinzufügen“

Der Konnektor MUSS den technischen Use Case TUC_KON_054 „Kartenterminal hinzufügen“ umsetzen.

Tabelle 38: TAB_KON_524 – TUC_KON_054 „Kartenterminal hinzufügen“ 

Element	Beschreibung
Name	TUC_KON_054 „Kartenterminal hinzufügen“
Beschreibung	Dieser TUC nimmt ein neues Kartenterminal in die zentrale Verwaltung auf (CTM_CT_LIST) oder aktualisiert die Einträge zu einem bereits erfassten Kartenterminal.
Auslöser	ein empfangenes Dienstbeschreibungspaket ohne vorheriges Service Discovery manuelles Hinzufügen eines KT-Eintrags ein empfangenes Dienstbeschreibungspaket nach vorherigem Auslösen eines manuellen Service Discovery
Vorbedingungen	entweder ist das KT noch nicht in CTM_CT_LIST enthalten     oder das KT ist unter anderer IP/anderem Hostnamen schon gelistet
Eingangsdaten	Mode (AutoAdded, ManuallyAdded, ManuallyModified)     IP-Adresse (IPv4)     TCP-Port (optional)     MAC-Adresse (optional)     Hostname (optional)
Komponenten	Konnektor, Kartenterminal
Ausgangsdaten	keine
Nachbedingungen	Das Kartenterminal ist mit allen Gerätekenndaten in CTM_CT_LIST vorhanden
Standardablauf	1.   Sofern optionale Parameter nicht übergeben wurden oder       Mode<>AutoAdded, ermittle Port, MAC und Hostname via Service       Discovery als UDP/IP-Unicast an IP-Adresse und Port       CTM_SERVICE_DISCOVERY_PORT 2.   Finde CT in CTM_CT_LIST über MAC-Adresse 3.   Wenn MAC-Adresse nicht in CTM_CT_LIST: a)         Erzeuge neuen CT-Object-Eintrag in CTM_CT_LIST und               -                Generiere eindeutige CT.CTID               -                setzte CT.MAC_ADRESS auf MAC-Adresse               -                Setze CT.CORRELATION =„bekannt“               -                Setze CT.CONNECTED = „Nein“ b)         Wenn Mode= ManuallyAdded setze CT.CORRELATION        =„zugewiesen“ 4.   Wenn CT.CONNECTED = Ja und (IP-Adresse <> CT.IP_ADRESS       oder TCP-Port <> CT.TCP_PORT),       beende TLS-Verbindung und setze CT.CONNECTED = „Nein“ 5.  Befülle: CT.IP_ADRESS, CT.Hostname, CT.TCP_PORT 6.  Wenn CT.CORRELATION>=„zugewiesen“ rufe TUC_KON_055      „Befülle CT-Object“
Varianten/ Alternativen	Keine
Fehlerfälle	Fehler im Ablauf (Standardablauf oder Varianten) führen in den folgend ausgewiesenen Schritten zu einem Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes: (1)  Keine Antwort innerhalb CTM_SERVICE_DISCOVERY_TIMEOUT,           Fehlercode: 4033 (1)  Ermittelte MAC-Adresse weicht von übergebener MAC-Adresse           ab, Fehlercode: 4035 (1)  Ermittelter Hostname-Adresse weicht von übergebenem Hostname          ab, Fehlercode: 4036 (2)  Wenn Mode=ManuallyModified und nicht gefunden, Fehlercode:           4037 Zusätzlich im Abbruchfall: -        Aufruf von TUC_KON_256 {          topic = "CT/CT_ADDING_ERROR";           eventType = $ErrorType;          severity = $Severity;          parameters = („IP=$IP-Adresse, Name=$HOSTNAME,             Error=$Fehlercode, Bedeutung=$Fehlertext“) } -        Keine Veränderung an CTM_CT_LIST
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	keine

Tabelle 39: TAB_KON_525 Fehlercodes TUC_KON_054 „Kartenterminal hinzufügen“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4033	Technical	Error	Kartenterminal antwortet nicht, Zufügen fehlgeschlagen
4035	Technical	Error	Angegebener IP-Adresse gehört zu einer anderen MAC-Adresse als die, die übergeben wurde. Angaben zur MAC prüfen
4036	Technical	Error	Angegebener IP-Adresse gehört zu einem anderen Hostname als der, der übergeben wurde. Angaben zum Hostname prüfen
4037	Technical	Error	Verwaltung der Kartenterminals inkonsistent

[<=]

4.1.4.3.3 TUC_KON_053 „Paire Kartenterminal“

TIP1-A_4548-02 - TUC_KON_053 „Paire Kartenterminal“

Der Konnektor MUSS den technischen Use Case „Paire Kartenterminal” gemäß TUC_KON_053 umsetzen.

Tabelle 40: TAB_KON_041 – TUC_KON_053 „Paire Kartenterminal“ 

Element	Beschreibung
Name	TUC_KON_053 „Paire Kartenterminal“
Beschreibung	TUC_KON_053 führt das Pairing zwischen dem Konnektor und einem eHealth-Kartenterminal durch.
Auslöser	Dialoge zur Administration des Konnektors. Der Administrator hat ein Kartenterminal im Dialog der Managementschnittstelle ausgewählt und das Pairing aufgerufen.
Vorbedingungen	KT ist in CTM_CT_LIST vorhanden CT.CORRELATION = „zugewiesen“ CT.IS_PHYSICAL = Ja
Eingangsdaten	ctId
Komponenten	Konnektor, Kartenterminal
Ausgangsdaten	Keine
Nachbedingungen	-  CT.CORRELATION = „aktiv“, wenn Pairing erfolgreich   - CT.CORRELATION = „zugewiesen“, wenn Pairing nicht erfolgreich  -  CT.CONNECTED = „Ja“, wenn Pairing erfolgreich
Standardablauf	Setze CT = CTM_CT_LIST(ctId) 1.   Prüfe CT.VALID_VERSION = true 2.   Aufbau einer TLS-Verbindung mit dem Kartenterminal unter       Verwendung von ID.SAK.AUT. Dabei:   a.           Speichern des präsentierten KT-Zertifikats in         CT.SMKT_AUT   b.           Prüfung des KT-Zertifikats mittels TUC_KON_037{                    certificate = C.SMKT.AUT;                    qualifiedCheck = not_required;                    offlineAllowNoCheck = true;                    policyList = oid _smkt_aut;                    intendedKeyUsage= intendedKeyUsage(C.SMKT.AUT);                    intendedExtendedKeyUsage = id-kp-serverAuth;                    validationMode = NONE } 3.   Der Konnektor entnimmt den Fingerprint dem KT-Zertifikat und stellt       dies dem Administrator im Dialog der Managementschnittstelle dar.       Der Konnektor fordert den Administrator auf, den Fingerprint zu       akzeptieren oder zurückzuweisen. 4.  Wenn der Administrator den Fingerprint bestätigt,         a.             generiert der Konnektor einen neuen Schlüssel, das               Shared Secret ShS.KT.AUT gemäß [gemSpec_Krypt#2.2]               (siehe [gemSpec_KT#3.7]) und speichert es in               CT.SHARED_SECRET         b.            und eröffnet der Konnektor mit dem               Kartenterminalkommando SICCT INIT CT SESSION (siehe               [SICCT#5.10]) mit                        -             ctId als Adressat                        -             und mit leerem Username, Password und                          Session ID              eine Cardterminal Session. 5.   Der Konnektor sendet mittels Kartenterminalkommando EHEALTH       TERMINAL AUTHENTICATE (siehe [gemSpec_KT#3.7.2]) in der       Ausprägung CREATE mit          -           ctId als Empfänger          -           und mit dem in Schritt 4.a generierten Schlüssel im             Shared Secret DO und der Display Message             „KT:$CT.MAC_ADRESS MIT       KON:$MGM_KONN_HOSTNAME PAIREN OK?“, wobei die              MAC-Adresse mit Trenner im folgenden Format dargestellt              werden MUSS: „AABBCC:DDEEFF“  das Shared Secret an das Kartenterminal. 6.   Der Konnektor prüft ob in der Antwort des Kartenterminals eine       korrekte Signatur des Shared Secrets gemäß      [gemSpec_KT#SEQ_KT_0001] Schritt 7, ausgeführt mit dem      Schlüssel zum Zertifikat CT.SMKT_AUT vorliegt. 7.  CT.CORRELATION wird auf „gepairt“ gesetzt 8.   TLS-Verbindung, die zum Pairen diente, beenden und zuvor das       Kartenterminalkommando SICCT CLOSE CT SESSION mit ctId als       Adressat senden 9.   Automatischer Zustandsübergang CT.CORRELATION = „gepairt“       nach „aktiv“ (implizite Aktion des Administrators durch Aufruf von      TUC_KON_053). 10. „Arbeits“-TLS-Verbindung neu aufbauen durch Aufruf       TUC_KON_050 { ctId; role = „User“}
Varianten/ Alternativen	(4): weist der Administrator den Fingerprint in Schritt 3 ab, wird         TUC_KON_053 nach Ausführung folgender Aktivitäten beendet:    4.1.a)    Löschen von CT.SMKT_AUT    4.1.b)    Abbau der TLS-Verbindung, Setzen von CT.CONNECTED                 auf „Nein“
Fehlerfälle	Fehler in den folgenden Schritten des Ablaufs führen zu:   a)             Aufruf von TUC_KON_256 {                    topic = "CT/ERROR";                    eventType = $ErrorType;                    severity = $Severity;                    parameters = („CtID=$ctId, Name=$CT.HOSTNAME,                       Error=$Fehlercode,                       Bedeutung=$Fehlertext“);                    doDisp = false }   b)              Löschen von CT.SMKT_AUT, CT.SHARED_SECRET   c)              Direkte Anzeige der Fehlermeldung für den Administrator   d)              Abbruch der Verarbeitung mit den ausgewiesenen          Fehlercodes (1) Version des KT wird nicht unterstützt, Fehlercode: 4042 (2b) Zertifikat ist zeitlich nicht gültig,          Fehlercode: 1021 (CERTIFICATE_NOT_VALID_TIME) (2) Fehler im TLS Verbindungsaufbau bzw. Zertifikatsprüfung,          Fehlercode: 4040 (4b) Fehler in SICCT INIT CT SESSION, Fehlercode: 4041 mit         Angabe des SICCT-Fehlers (5) Fehler in EHEALTH TERMINAL AUTHENTICATE, Fehlercode:          4041 mit Angabe des SICCT-Fehlers (6) Signaturprüfung fehlgeschlagen, Fehlercode: 4041
Zugehörige Diagramme	Siehe PIC_KON_057

Tabelle 41: TAB_KON_113 Fehlercodes TUC_KON_053 „Paire Kartenterminal“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4040	Security	Error	Fehler beim Versuch eines Verbindungsaufbaus zum KT
4041	Technical	Error	Fehler im Pairing, SICCT-Fehler(Nur wenn dieser Fehler wegen eines Fehlers auf der SICCT-Schnittstelle auftritt, ist der SICCT-Fehlercode mit anzugeben.): <SICCT-Fehler>
4042	Technical	Error	Die Version des Kartenterminals wird nicht unterstützt

Hinweis zu Fehler 4041:
Nur wenn dieser Fehler wegen eines Fehlers auf der SICCT-Schnittstelle auftritt, ist der SICCT-Fehlercode mit anzugeben.

 

Abbildung 9: PIC_KON_057 Aktivitätsdiagramm zu „PaireKartenterminal“ 

[<=]

4.1.4.3.4 TUC_KON_055 „Befülle CT-Object“

TIP1-A_4985 - TUC_KON_055 „Befülle CT-Object“

Der Konnektor MUSS den technischen Use Case TUC_KON_055 „Befülle CT-Object“ umsetzen.
 

Tabelle 42: TAB_KON_526 – TUC_KON_055 „Befülle CT-Object“ 

Element	Beschreibung
Name	TUC_KON_055 „Befülle CT-Object“
Beschreibung	Dieser TUC befüllt ein vorhandenes CT-Object aus CTM_CT_LIST mit den aktuellen Produktinformationen, die vom Kartenterminal bezogen werden und prüft, ob die Version des Kartenterminals unterstützt wird.
Auslöser	TUC_KON_054 Ereignis „KSR/UPDATE/END“ mit „Target=KT“ Verändern von CT.CORRELATION auf „zugewiesen“ Administratoraktion
Vorbedingungen	ctId ist in CTM_CT_LIST vorhanden
Eingangsdaten	ctId
Komponenten	Konnektor, Kartenterminal
Ausgangsdaten	Supported (Boolean, True, wenn die Version des KT unterstützt wird)
Nachbedingungen	Die Gerätekenndaten des Kartenterminals in CTM_CT_LIST sind aktualisiert
Standardablauf	Setze CT = CTM_CT_LIST(ctId) Wenn CT.CONNECTED=Nein: Rufe TUC_KON_050 {     ctId,     role = „User” } Folgende CT.Werte via SICCT GET STATUS ermitteln und befüllen:    CT.SLOTCOUNT     CT.PRODUCTINFORMATION    CT.EHEALTH_INTERFACE_VERSION (Element VER aus Discretionary Data Data Object (DD DO))    CT.DISPLAY_CAPABILITIES (aus Display Capabilities Data Object in [SICCT#5.5.10.17]) Finde Eintrag in CTM_SUPPORTED_KT_VERSIONS anhand der ersten beiden Stellen (Haupt- und Nebenversionsnummer) aus CT.EHEALTH_INTERFACE_VERSION     Eintrag gefunden:         Die dritte Stelle der KT-Version ist im Vergleich                                          zur dritten Stelle im gefundenen Eintrag:                                               >=:    Setze Result = True                                               <:    Setze Result = False     Kein Eintrag gefunden: Setze Result = False Setze CT.VALID_VERSION auf Result Wenn Verbindung in (1) aufgebaut wurde, trenne Verbindung Liefere Result zurück
Varianten/ Alternativen	(->5) Wenn CT.CORRELATION="aktiv", kann die in (1) aufgebaute Verbindung bestehen bleiben.
Fehlerfälle	-> 2) Kartenterminal antwortet mit einer spezifischen Fehlermeldung, Fehlercode <gemäß [SICCT]>
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	keine

[<=]

4.1.4.4 Interne TUCs, auch durch Fachmodule nutzbar

4.1.4.4.1 TUC_KON_051 „Mit Anwender über Kartenterminal interagieren“

TIP1-A_4547 - TUC_KON_051 „Mit Anwender über Kartenterminal interagieren“

Der Konnektor MUSS den technischen Use Case „Mit Anwender über Kartenterminal interagieren” gemäß TUC_KON_051 umsetzen.
 

Tabelle 43: TAB_KON_112 – TUC_KON_051 „Mit Anwender über Kartenterminal interagieren“ 

Element	Beschreibung
Name	TUC_KON_051 „Mit Anwender über Kartenterminal interagieren“
Beschreibung	Der TUC ermöglicht es, Meldungen an das Display eines Kartenterminals zu senden oder Eingaben vom Benutzer über das PIN-Pad eines Kartenterminals abzufragen (unter Anzeige einer Meldung).
Auslöser	Fachmodul im Konnektor oder anderer technischer Use Case ruft diesen Use Case auf.
Vorbedingungen	KT ist in CTM_CT_LIST vorhanden                     CT.CORRELATION = „aktiv“                     CT.CONNECTED = Ja                     CT.IS_PHYSICAL = Ja
Eingangsdaten	ctId (Kartenterminalidentifikator) displayMessage – optional/nicht erforderlich bei opmode=  OutputErase, sonst mandatory (Text zur Darstellung am KT, Länge durch KT begrenzt); opMode [KtOutputMode] (Kommando-Modus) inputLength – optional/nur bei opMode=Input (erwartete Eingabelänge, 0 für „beliebig“ lang) waitTimer – optional/nur bei opMode=OutputWait (Wartezeit bis zur ersten Eingabe in Sekunden)
Komponenten	Konnektor, Kartenterminal
Ausgangsdaten	opResult [OK | ABBRUCH ] – optional/verpflichtend, wenn opMode=Input oder opMode=OutputConfirm (Nutzertastendruck) inputData – optional/nur bei opMode = Input (Zifferneingabe des Benutzers)
Nachbedingungen	Wenn Mode=OutputKeep bleibt Data auf dem Display des KT stehen
Standardablauf	Setze CT = CTM_CT_LIST(ctId) opMode=           Input: Der Konnektor MUSS via SICCT INPUT am CT zur Eingabe auffordern. Dabei MUSS die KT-Ansteuerung so erfolgen, dass: displayMessage zur Anzeige gebracht wird maximal inputLength Ziffern akzeptiert werden. Bei inputLength=0 werden 1-n Zeichen akzeptiert (n=Maximalwert, definiert durch KT) die eingegebenen Zeichen am Display angezeigt werden die Eingabe explizit mit OK oder ABBRUCH beendet werden muss           OutputWait: Der Konnektor MUSS via SICCT OUTPUT am CT displayMessage zur Anzeige bringen. Nach einer Wartezeit von waitTimer Sekunden MUSS der Konnektor die Anzeige des KT leeren.           OutputConfirm: Der Konnektor MUSS via SICCT INPUT am CT displayMessage zur Anzeige bringen und auf eine Bestätigung durch den Nutzer warten (zulässig: OK, ABBRUCH)           OutputKeep: Der Konnektor MUSS via SICCT OUTPUT am CT displayMessage zur Anzeige bringen. Die Anzeige bleibt erhalten, bis das KT neue Informationen am Display darstellen muss/soll.           OutputErase: Der Konnektor MUSS via SICCT OUTPUT am CT die Anzeige leeren.
Varianten/ Alternativen	Ist das Kartenterminal-Display durch einen anderen, zeitgleich im Konnektor ablaufenden Vorgang reserviert, so muss der Konnektor zunächst maximal 10 Sekunden lang versuchen, Zugriff auf das Display zu erhalten (und somit parallele Zugriffe auf das Display zu serialisieren). Erst nach Ablauf der Wartezeit wird Fehler 4039 geworfen.
Fehlerfälle	Fehler in den folgenden Schritten des Ablaufs führen zum Aufruf von TUC_KON_256 {       topic = "CT/ERROR";       eventType = $ErrorType;       severity = $Severity;       parameters = („CtID=$ctId, Name=$CT.HOSTNAME,                             Error=$Fehlercode, Bedeutung=$Fehlertext“) } (1) Display und PinPad des Kartenterminals sind aktuell belegt (PIN,         Eingabe, andere Ausgabe etc.), Fehlercode: 4039 (1) Kartenterminal antwortet mit einer spezifischen Fehlermeldung,          Fehlercode <gemäß [SICCT]>
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	Keine

 

Tabelle 44: TAB_KON_114 Fehlercodes TUC_KON_051 „Mit Anwender über Kartenterminal interagieren“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4039	Technical	Error	Kartenterminal durch andere Nutzung aktuell belegt

[<=]

4.1.4.4.2 TUC_KON_056 „Karte anfordern“

TIP1-A_5409 - TUC_KON_056 „Karte anfordern“

Der Konnektor MUSS den technischen Use Case „Karte anfordern” gemäß TUC_KON_056 umsetzen.
 

Tabelle 45: TAB_KON_723 - TUC_KON_056 „Karte anfordern“ 

Element	Beschreibung
Name	TUC_KON_056 „Karte anfordern“
Beschreibung	Der TUC ermöglicht es, die Aufforderung zum Karte-Stecken an das Kartenterminal zu senden und dabei eine Meldung zum Anzeigen im Display des Kartenterminals mitzugeben.
Auslöser	Fachmodul im Konnektor oder Operation RequestCard ruft diesen Use Case auf.
Vorbedingungen
Eingangsdaten	-      ctId      (Kartenterminalidentifikator) - slotId     (Nummer des Kartenslots)   -   cardType - optional - displayMessage – optional       (Text zur Darstellung am Kartenterminal, Länge durch KT begrenzt) -     timeOut     (Wartezeit in Sekunden)
Komponenten	Konnektor, Kartenterminal
Ausgangsdaten	cardObject (Informationsobjekt der Karte)
Nachbedingungen	Im Erfolgsfall enthält die CM_CARD_LIST ein neues CARD-Objekt des geforderten Typs.
Standardablauf	Setze CT = CTM_CT_LIST(ctId)      Falls displayMessage nicht explizit angegeben ist, MUSS sie gemäß Anforderung [TIP1-A_5408] erstellt werden.      Der Konnektor MUSS das Kommando SICCT REQUEST ICC an das Kartenterminal CT senden. Die verfügbaren Optionen (Optical Signal, Acoustic Signal) können herstellerspezifisch sein bzw. über die Konfigurationsschnittstelle des Konnektors eingestellt werden. displayMessage wird als Eingabeaufforderung mitgegeben. Der übergebene timeOut-Wert wird dem SICCT-Kommando als Parameter übergeben.      Falls die Karte noch nicht gesteckt war, wird durch das Stecken der Karte das Ereignis „Karte gesteckt“ ausgelöst, worauf der Konnektor reagiert [TIP1-A_4563].      Die Verarbeitung wird fortgesetzt, wenn eines der Ereignisse eingetreten ist:        SICCT REQUEST ICC kehrt mit '6201' zurück (eine aktivierte Karte steckte bereits)       SICCT REQUEST ICC kehrt mit '9000' oder '9001' zurück und das Ereignis "Karte gesteckt" wurde gemäß [TIP1-A_4563] verarbeitet       SICCT REQUEST ICC kehrt mit '9000' oder '9001' zurück und das Ereignis "Karte gesteckt" wurde nicht empfangen (eine deaktivierte Karte steckte bereits), die Karte wurde durch       Rufe TUC_KON_001 {             ctId; slotId } geöffnet. In allen Fällen liegt in CM_CARD_LIST ein neues CARD-Objekt vor.      Falls cardType angegeben ist, wird nach erfolgreicher Ausführung von SICCT REQUEST ICC der AID des MF der gesteckten Karte gelesen und mit dem gewünschten Kartentyp in cardType verglichen. Bei fehlender Übereinstimmung wird der Ablauf mit dem Fehler 4051 abgebrochen.      Es wird cardObject (ein Informationsobjekt der Karte, die sich in dem Slot mit der Nummer slotId befindet) zurückgegeben.
Varianten/ Alternativen	Die Ausgabe einer Display-Nachricht entfällt, wenn der adressierte Slot bereits eine gesteckte Karte enthält.
Fehlerfälle	Fehler in den folgenden Schritten des Ablaufs führen zu Aufruf von TUC_KON_256 {       topic = "CT/ERROR";       eventType = $ErrorType;       severity = $Severity;       parameters = („CtID=$ctId, Name=$CT.HOSTNAME,                                Error=$Fehlercode, Bedeutung=$Fehlertext“) } (2)    Display des Kartenterminals ist aktuell belegt, Fehlercode: 4039 (2)    Fehler beim Zugriff auf das Kartenterminal, Fehlercode: 4044 (2)    Ungültige Kartenterminal-ID: Fehlercode: 4007 (2)    Ungültige Kartenslot-ID: Fehlercode: 4097 (2)    Kartenterminal nicht aktiv, Fehlercode: 4221 (2)    Kartenterminal ist nicht verbunden, Fehlercode: 4222 (2)    Kartenterminal antwortet mit einer spezifischen Fehlermeldung,            Fehlercode <gemäß [SICCT]> (4)    Timeout. Es wurde keine Karte innerhalb der angegebenen            Zeitspanne gesteckt, Fehlercode: 4202 (5)    Falscher Kartentyp, Fehlercode: 4051
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	Keine

 

Tabelle 46: TAB_KON_724 Fehlercodes TUC_KON_056 „Karte anfordern“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4039	Technical	Error	Kartenterminal durch andere Nutzung aktuell belegt
4044	Technical	Error	Fehler beim Zugriff auf das Kartenterminal
4051	Technical	Error	Falscher Kartentyp
4007	Technical	Error	Ungültige Kartenterminal-ID
4097	Technical	Error	Ungültige Kartenslot-ID
4202	Technical	Error	Timeout. Es wurde keine Karte innerhalb der angegebenen Zeitspanne gesteckt.
4221	Technical	Error	Kartenterminal nicht aktiv
4222	Technical	Error	Kartenterminal ist nicht verbunden

[<=]

4.1.4.4.3 TUC_KON_057 „Karte auswerfen“

TIP1-A_5410 - TUC_KON_057 „Karte auswerfen“

Der Konnektor MUSS den technischen Use Case „Karte auswerfen” gemäß TUC_KON_057 umsetzen.
 

Tabelle 47: TAB_KON_725 – TUC_KON_057 „Karte auswerfen“ 

Element	Beschreibung
Name	TUC_KON_057 „Karte auswerfen“
Beschreibung	Der TUC ermöglicht es, das SICCT-Kommando zum Auswerfen der Karte an das Kartenterminal zu senden und dabei eine Meldung zum Anzeigen im Display des Kartenterminals mitzugeben, die den Benutzer zum Entnehmen der Karte auffordert.
Auslöser	Fachmodul im Konnektor oder Operation EjectCard ruft diesen Use Case auf.
Vorbedingungen
Eingangsdaten	ctId (Kartenterminalidentifikator)                     slotId (Nummer des Kartenslots)                     displayMessage – optional   (Text zur Darstellung am Kartenterminal, Länge durch KT begrenzt)                     timeOut (Wartezeit in Sekunden)
Komponenten	Konnektor, Kartenterminal
Ausgangsdaten	keine
Nachbedingungen	Durch das Entfernen der Karte wird das Ereignis „Karte entfernt“ ausgelöst, worauf der Konnektor reagiert [TIP1-A_4562].
Standardablauf	Setze CT = CTM_CT_LIST(ctId)      Der Konnektor prüft, dass entweder die Karte nicht reserviert ist oder der Aufrufer im Besitz des Karten-Locks ist.      Falls displayMessage nicht explizit angegeben ist, MUSS sie gemäß Anforderung [TIP1-A_5408] erstellt werden.      Der Konnektor MUSS das Kommando SICCT EJECT ICC an das Kartenterminal CT senden. Der Aufruf MUSS mit der Option „Delivery: Mechanical Throwout“ erfolgen. Die anderen Optionen (Optical Signal, Acoustic Signal) können herstellerspezifisch eingestellt werden bzw. können über die Konfigurationsschnittstelle des Konnektors eingestellt werden. Der übergebene Wert timeOut wird dem SICCT-Kommando als Parameter übergeben.
Varianten/ Alternativen	Auch im Falle, dass nach der internen Buchführung des Konnektors in dem angegebenen Slot des Kartenterminals keine Karte steckt, MUSS der Konnektor das SICCT-Kommando SICCT EJECT ICC an das Kartenterminal senden. Meldet das Kartenterminal keinen Fehler, so meldet auch der Konnektor keinen Fehler und es kann davon ausgegangen werden, dass sich keine Karte mehr in dem Slot befindet.
Fehlerfälle	Fehler in den folgenden Schritten des Ablaufs führen zu Aufruf von TUC_KON_256 {       topic = "CT/ERROR";       eventType = $ErrorType;       severity = $Severity;       parameters = („CtID=$CtID, Name=$CT.HOSTNAME,                                Error=$Fehlercode, Bedeutung=$Fehlertext“) } (1) Die Karte ist fremdreserviert, Fehlercode 4093 (3) Display des Kartenterminals ist aktuell belegt, Fehlercode: 4039 (3) Fehler beim Zugriff auf das Kartenterminal, Fehlercode: 4044 (3) Karte deaktiviert, aber nicht entnommen, Fehlercode: 4203 (3) Ungültige Kartenterminal-ID: Fehlercode: 4007 (3) Ungültige Kartenslot-ID: Fehlercode: 4097 (3) Kartenterminal nicht aktiv, Fehlercode: 4221 (3) Kartenterminal ist nicht verbunden, Fehlercode: 4222 (3) Kartenterminal antwortet mit einer spezifischen Fehlermeldung,         Fehlercode <gemäß [SICCT]>
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	Keine

 

Tabelle 48: TAB_KON_796 Fehlercodes TUC_KON_057 „Karte auswerfen“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4039	Technical	Error	Kartenterminal durch andere Nutzung aktuell belegt
4044	Technical	Error	Fehler beim Zugriff auf das Kartenterminal
4203	Technical	Error	Karte deaktiviert, aber nicht entnommen
4093	Technical	Error	Karte wird in einer anderen Kartensitzung exklusiv verwendet
4007	Technical	Error	Ungültige Kartenterminal-ID
4097	Technical	Error	Ungültige Kartenslot-ID
4221	Technical	Error	Kartenterminal nicht aktiv
4222	Technical	Error	Kartenterminal ist nicht verbunden

[<=]

4.1.4.4.4 TUC_KON_058 „Displaygröße ermitteln“

A_17473 - TUC_KON_058 „Displaygröße ermitteln“

Der Konnektor MUSS den technischen Use Case „Displaygröße ermitteln“ gemäß TUC_KON_058 umsetzen.

Tabelle 49: TAB_KON_854 – TUC_KON_058 „Displaygröße ermitteln“ 

Element	Beschreibung
Name	TUC_KON_058 „Displaygröße ermitteln“
Beschreibung	Der TUC liefert den Inhalt der Variable CT.DISPLAY_CAPABILITIES zurück.
Auslöser	Fachmodul im Konnektor ruft diesen Use Case auf.
Vorbedingungen
Eingangsdaten	ctId (Kartenterminalidentifikator)
Komponenten	Konnektor
Ausgangsdaten	CT.DISPLAY_CAPABILITIES
Nachbedingungen	Keine
Standardablauf	Setze CT = CTM_CT_LIST(ctId)      Der Konnektor prüft, ob CT.DISPLAY_CAPABILITIES belegt ist.      Falls CT.DISPLAY_CAPABILITIES belegt ist, wird der Inhalt der Variable zurückgegeben.
Varianten/ Alternativen	Keine
Fehlerfälle	Fehler in den folgenden Schritten des Ablaufs führen zu Aufruf von TUC_KON_256 {       topic = "CT/ERROR";       eventType = $ErrorType;       severity = $Severity;       parameters = („CtID=$CtID, Name=$CT.HOSTNAME,                                Error=$Fehlercode, Bedeutung=$Fehlertext“) } (2) CT.DISPLAY_CAPABILITIES ist nicht belegt, Fehlercode 4254
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	Keine

Tabelle 50: TAB_KON_855 Fehlercodes TUC_KON_058 „Displaygröße ermitteln“ 

Fehlercode	ErrorType	Severity	Fehlertext
4254	Technical	Error	Keine Displaygröße für das Kartenterminal definiert

[<=]

4.1.4.5 Operationen an der Außenschnittstelle

TIP1-A_5411-02 - Basisdienst Kartenterminaldienst

Der Konnektor MUSS Clientsystemen den Basisdienst Kartenterminaldienst anbieten.
 

Tabelle 51: TAB_KON_722 Basisdienst Kartenterminaldienst 

Name	CardTerminalService
Version (KDV)	1.1.0 (WSDL-Version) 1.1.2 (XSD-Version)
Namensraum	Siehe GitHub
Namensraum-Kürzel	CT für Schema und CTW für WSDL
Operationen	Name	Kurzbeschreibung
	RequestCard	Karte anfordern
	EjectCard	Karte auswerfen
WSDL	CardTerminalService.wsdl
Schema	CardTerminalService.xsd

[<=]

4.1.4.5.1 RequestCard

TIP1-A_5412 - Operation RequestCard

Der Konnektor MUSS an der Außenschnittstelle eine Operation RequestCard, wie in Tabelle TAB_KON_716 Operation RequestCard beschrieben, anbieten.
 

Tabelle 52: TAB_KON_716 Operation RequestCard 

Name	RequestCard
Beschreibung	Liefert die Information zu einer Karte, die in dem Slot eines Kartenterminals steckt oder innerhalb einer bestimmten Zeit (Timeout) gesteckt wird.
Aufruf-parameter
	Name	Beschreibung
	CCTX:Context	MandantId, CsId, WorkplaceId verpflichtend
	CT:Slot	Adressiert den Slot eines Kartenterminals über die Identifikation des Kartenterminal CARDCMN:CtId und die Nummer des Slots CARDCMN:SlotId
	CARDCMN: CardType	Ein Kartentyp aus {EGK, KVK, HBAx, SM-B} als optionaler Filter. Wenn angegeben, werden nur Karten vom spezifizierten Typ zurückgegeben.
	CT:DisplayMsg	Diese Nachricht wird am Display des Kartenterminals angezeigt, um den Nutzer zum Stecken der Karte aufzufordern.
	CT:TimeOut	Die Zeit in sec, die maximal gewartet wird bis zum Stecken einer Karte. Wird dieser Parameter nicht übergeben, SOLL der Konnektor den Wert 20 sec verwenden. Optional KANN dieser Default-Wert im Konnektor konfigurierbar sein.
Rückgabe
	Name	Beschreibung
	CONN:Status	Enthält den Ausführungsstatus der Operation (siehe 3.5.2)
	CT:AlreadyInserted	Dieses optionale Flag gibt an, ob die Karte bereits vor der Anfrage steckte (Wert true) oder erst auf Anforderung dieses Aufrufs gesteckt wurde (Wert false oder Element nicht vorhanden).
	CARD:Card	Falls eine Karte gesteckt ist, werden Information zur Karte zurückgegeben (siehe 4.1.6.5.2)
Vorbedingung	keine
Nachbedingung	keine

Der Ablauf der Operation RequestCard ist in Tabelle TAB_KON_717 Ablauf RequestCard beschrieben.
 

Tabelle 53: TAB_KON_717 Ablauf RequestCard 

Nr.	Aufruf Technischer Use Case oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab. Wird die Operation für einen nicht unterstützten Kartentypen aufgerufen, so bricht die Operation mit Fehler 4058 ab.
2.	TUC_KON_000 „Prüfe Zugriffs-berechtigung“	Prüfung der Zugriffsberechtigung durch den Aufruf TUC_KON_000 {       mandantId = $context.mandantId;       clientSystemId = $context.clientsystemId;       workplaceId = $context.workplaceId;       ctId = $Slot.CtId;       needCardSession=false;       allWorkplaces=false } Tritt bei der Prüfung ein Fehler auf, so bricht die Operation mit dem Fehlercode aus TUC_KON_000 ab.
3.	TUC_KON_056 „Karte anfordern“	Anforderung der Karte vom Kartenterminal durch Aufruf TUC_KON_056(       ctId = $Slot.CtId;       slotId = $Slot.SlotId;       $cardType;       displayMessage = $DisplayMsg;       $timeOut)

Tabelle 54: TAB_KON_718 Fehlercodes „RequestCard“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler
4058	Security	Error	Aufruf nicht zulässig

[<=]

4.1.4.5.2 EjectCard

TIP1-A_5413 - Operation EjectCard

Der Konnektor MUSS an der Außenschnittstelle eine Operation EjectCard, wie in Tabelle TAB_KON_719 Operation EjectCard beschrieben, anbieten.
 

Tabelle 55: TAB_KON_719 Operation EjectCard 

Name	EjectCard
Beschreibung	Beendet die Kommunikation mit der Karte und wirft sie aus, falls das Kartenterminal eine solche mechanische Funktion hat.
Aufruf-parameter
	Name	Beschreibung
	Context	MandantId, CsId, WorkplaceId verpflichtend
	CONN: CardHandle	Adressiert die Karte, die ausgeworfen werden soll.
	CT:Slot	Adressiert alternativ den Slot eines Kartenterminals, aus dem die Karte ausgeworfen werden soll. Die Adressierung erfolgt über die Identifikation des Kartenterminal CARDCMN:CtId und die Nummer des Slots CARDCMN:SlotId.
	CT: DisplayMsg	Diese Nachricht wird am Display des Kartenterminals angezeigt, um den Nutzer zum entnehmen der Karte aufzufordern.
	CT:TimeOut	Die Zeit in msec, die maximal gewartet wird bis eine Karte gezogen ist. Wird dieser Parameter nicht übergeben, SOLL der Konnektor den Wert 20 sec verwenden. Optional KANN dieser Default-Wert im Konnektor konfigurierbar sein.
Rückgabe
	Name	Beschreibung
	Status	Enthält den Ausführungsstatus der Operation (siehe 3.5.2)
Vorbedingung	keine.
Nachbedingung	keine.

Der Ablauf der Operation EjectCard ist in Tabelle TAB_KON_720 Ablauf EjectCard beschrieben.
 

Tabelle 56: TAB_KON_720 Ablauf EjectCard 

Tabelle 57: TAB_KON_721 Fehlercodes Operation „EjectCard“ 

[<=]

4.1.4.6 Betriebsaspekte

4.1.4.6.1 Allgemeine Betriebsaspekte

TIP1-A_4549 - Initialisierung Kartenterminaldienst

Während des Bootvorgangs, nach dem Einlesen der persistierten Informationen des Kartenterminaldienstes MUSS der Konnektor für jedes Kartenterminal CT in CTM_CT_LIST:

1.                     die zugehörigen Attribute CT.SLOTS_USED, CT.VALID_VERSION und ggf. (bei dynamischer Adressvergabe) CT.IP_ADRESS aktualisieren
2.                     für jedes CT mit CT.CORRELATION = „aktiv“:
   1.                      Wenn CT.VALID_VERSION = True: TUC_KON_050 „Beginne Kartenterminalsitzung“ {ctId=CT.CtID; role=„User“} aufrufen
   2.                     Wenn CT.VALID_VERSION = False: CT.CORRELATION=„gepairt“ setzen

[<=]

Hinweis: Bei der Initialiserung des Kartenterminaldienstes liest der Konnektor noch nicht die Karten, um zu ermitteln, welche Karten gesteckt sind. Dies erfolgt erst bei Initialisierung des Kartendienstes.

TIP1-A_4550 - Konfigurationsparameter des Kartenterminaldienstes

Die Managementschnittstelle MUSS es einem Administrator ermöglichen Konfigurationsänderungen gemäß Tabelle TAB_KON_527 vorzunehmen:
 

Tabelle 58: TAB_KON_527 Konfigurationswerte eines Kartenterminalobjekts 

ReferenzID	Belegung	Bedeutung und Administrator-Interaktion
CTM_SERVICE_DISCO VERY_PORT	Portnummer	Der Administrator MUSS die Portnummer eingeben können, auf der die KTs im lokalen Netz auf Dienstanfragen hören. Default-Wert=4742
CTM_SERVICE_DISCO VERY_TIMEOUT	X Sekunden	Der Administrator MUSS die Anzahl Sekunden eingeben können, die der Konnektor auf Antworten zu Service-Discovery-Anfragen wartet. Default-Wert=3
CTM_SERVICE_ANNOU NCEMENT_PORT	Portnummer	Der Administrator MUSS die Portnummer eingeben können, auf der der Konnektor auf Dienstbeschreibungspakete hört. Default-Wert=4742
CTM_SERVICE_DISCO VERY_CYCLE	X Minuten	Der Administrator MUSS die Anzahl Minuten einstellen können, in denen der Konnektor wiederholt Service Discovery Nachrichten absetzt. Default-Wert=10, 0=Deaktiviert
CTM_KEEP_ALIVE_IN TERVAL	X Sekunden	Intervall in Sekunden in den Keep-Alive-Nachrichten an das Kartenterminal gesendet werden Der Administrator MUSS diesen Wert im vorgegebenen Bereich anpassen können. Wertebereich:1-10 Default-Wert=10
CTM_KEEP_ALIVE_TR Y_COUNT	Anzahl der Versuche	Anzahl von aufeinander folgenden, nicht beantworteten Keep-Alive-Nachrichten, nach denen ein Timeout der TLS-Verbindung festgestellt wird Der Administrator MUSS diesen Wert im vorgegebenen Bereich anpassen können. Wertebereich:3-10 Default-Wert=3
CTM_TLS_HS_TIMEOUT	X Sekunden	Der Administrator MUSS die Anzahl Sekunden eingeben können, die der Konnektor auf den TLS-Verbindungsaufbau zum Kartenterminal wartet (Handshake-Timeout). Wertebereich:1-60 Default-Wert=10

[<=]

TIP1-A_4986 - Informationsparameter des Kartenterminaldienstes

Die Managementschnittstelle MUSS es einem Administrator ermöglichen die Informationsparameter gemäß Tabelle TAB_KON_528 einzusehen:
 

Tabelle 59: TAB_KON_528 Informationsparamter des Kartenterminaldienstes 

ReferenzID	Belegung	Bedeutung und Administrator-Interaktion
CTM_SUPPORTED_KT_ VERSIONS	Liste von EHEALTH-Interface-Versionen	Der Administrator MUSS die Liste der vom Konnektor unterstützten modellunabhängigen EHEALTH-Interface-Versionen einsehen können.

[<=]

4.1.4.6.2 Kartenterminals pflegen

Im Folgenden werden die Administratorinteraktionen beschrieben, die zum Hinzufügen, Pairen, Bearbeiten und Löschen von Kartenterminals innerhalb der CTM_CT_LIST angeboten werden müssen. Eine Aktualisierung der Kartenterminals mit neuer Firmware wird in Kapitel 4.3.9 beschrieben.

TIP1-A_4551 - Einsichtnahme von Kartenterminaleinträgen

Die Managementschnittstelle MUSS es einem Administrator ermöglichen die Liste der verwalteten und neu entdeckten Kartenterminals einzusehen (CTM_CT_LIST).

[<=]

TIP1-A_4552 - Manueller Verbindungsversuch zu Kartenterminals

Die Managementschnittstelle MUSS es einem Administrator ermöglichen zu jedem CT-Object-Eintrag in CTM_CT_LIST mit CT.CONNECTED=Nein und CT.CORRELATION=aktiv einen manuellen Verbindungsaufbau über TUC_KON_050 {ctId=CtID; role=„User“} auszulösen.

[<=]

TIP1-A_4553 - Einsichtnahme in und Aktualisierung der Kartenterminaleinträge

Die Managementschnittstelle MUSS es einem Administrator ermöglichen zu jedem CT-Object-Eintrag in CTM_CT_LIST die Werte gemäß Tabelle TAB_KON_529 einsehen zu können:
Zu jedem Eintrag MUSS der Administrator TUC_KON_055 „Befülle CT-Object“ auslösen können.
 

Tabelle 60: TAB_KON_529 Anzeigewerte zu einem Kartenterminalobjekt 

ReferenzID	Belegung	Bedeutung und Administrator-Interaktion
Geräte kenndaten
CT.CTID	Identifier	Eindeutige, statische Identifikation des Kartenterminals
CT.IS_PHYSICAL	Ja/Nein	Kennzeichnung, ob es sich um ein logisches oder physisches Kartenterminal handelt (siehe auch TAB_KON_522 Parameterübersicht des Kartenterminaldienstes)
CT.MAC_ADRESS	MAC-Adresse	die MAC-Adresse des Kartenterminals
CT.HOSTNAME	String	SICCT-Terminalname des Kartenterminals, auch als FriendlyName bezeichnet
CT.IP_ADRESS	IP-Adresse	die IP-Adresse des Kartenterminals
CT.TCP_PORT	Portnummer	der TCP-Port des SICCT-Kommandointerpreters des Kartenterminals
CT.SLOTCOUNT	Nummer	Anzahl der Slots des Kartenterminals
CT.SLOTS_USED	Liste	Liste der mit Karten belegten Slots
CT.PRODUCT INFORMATION	Inhalt Product Information.xsd	die Herstellerinformationen zum Kartenterminal gemäß [gemSpec_OM]
CT.EHEALTH_ INTERFACE_ VERSION	Version	Die EHEALTH-Interface-Version des Kartenterminals, die mittels des SICCT-Kommandos GET STATUS aus dem Element VER des Discretionary Data Objects ermittelt wurde
CT.VALID_ VERSION	Boolean	True, wenn die Version des Kartenterminals (CT.EHEALTH_INTERFACE_VERSION) durch den Konnektor unterstützt wird, d.h. zu den in CTM_SUPPORTED_KT_VERSIONS passt
Pairingdaten
CT.SMKT_AUT	X.509-Cert	C.SMKT.AUT-Zertifikat des Kartenterminals, gespeichert im Rahmen des Pairings
Verbindungs daten
CT. CORRELATION	bekannt zugewiesen gepairt aktiv aktualisierend	Der Korrelationsstatus zum Konnektor: bekannt (über Service Announcement/Service Discovery gelernte Kartenterminals), zugewiesen (durch den Administrator aus dem Bereich der bekannten Kartenterminals oder manuell konfigurierte Kartenterminals), gepairt (Pairing erfolgreich aber noch nicht zum Verbindungsaufbau freigegeben) aktiv (durch Administrator zum Verbindungsaufbau freigegeben), aktualisierend (ein laufender Updatevorgang, ausgelöst durch den Konnektor; Der Zustand tritt ein, wenn der Kartenterminaldienst das Event „KSR/UPDATE/START" fängt und endet mit dem Event „KSR/UPDATE/END"),
CT.CONNECTED	Ja/Nein	Der Verfügbarkeitsstatus des Kartenterminals (Ja = nach Aufbau der TLS-Verbindung und erfolgter zweiter Authentifizierung)
CT.ACTIVEROLE	User/Admin	Benutzerrolle, die für die aktuelle Session verwendet wird
KT-Admin-Credentials
CT.ADMIN_ USERNAME	String	Username des Administrators am KT

[<=]

TIP1-A_4554 - Bearbeitung von Kartenterminaleinträgen

Die Managementschnittstelle MUSS es einem Administrator ermöglichen zu jedem CT-Object-Eintrag in CTM_CT_LIST die Werte gemäß Tabelle TAB_KON_530 ändern zu können:
Zur Überprüfung der veränderten Parameter auf Korrektheit MUSS nach Änderung von CT.IP_ADRESS, TCP_PORT oder HOSTNAME TUC_KON_054 mit Mode= ManuallyModified und allen vorhandenen CT-Parametern aufgerufen werden. Endet der Aufruf von TUC_KON_054 mit einem Fehler, MUSS der Konnektor die geänderten Konfigurationswerte auf ihren Ausgangswert zurücksetzen.
 

Tabelle 61: TAB_KON_530 Konfigurationswerte eines Kartenterminalobjekts 

ReferenzID	Belegung	Bedeutung und Administrator-Interaktion
CT.IP_ADRESS	IP-Adresse	Der Administrator MUSS für KTs mit CT.IS_PHYSICAL=Ja die IPv4-Adresse des Kartenterminals eingeben können.
CT.TCP_PORT	Portnummer	Der Administrator MUSS für KTs mit CT.IS_PHYSICAL=Ja den TCP-Port des SICCT-Kommandointerpreters des Kartenterminals eingeben können.
CT.HOSTNAME	String	Der Administrator MUSS den SICCT-Terminalnamen (Hostname) - auch als FriendlyName bezeichnet - des Kartenterminals eingeben können.
CT.ADMIN_USERNAME	String	Der Administrator MUSS für KTs mit CT.IS_PHYSICAL=Ja den Username des KT-Administrators des Kartenterminals eingeben können.
CT.ADMIN_PASSWORD	String	Der Administrator MUSS für KTs mit CT.IS_PHYSICAL=Ja das Password des KT-Administrators des Kartenterminals eingeben können.

[<=]

TIP1-A_6477 - Manuelles Service Discovery

Die Managementschnittstelle MUSS es einem Administrator ermöglichen, ein Service Discovery entsprechend [SICCT] auszulösen, um neue Kartenterminals hinzuzufügen.

[<=]

TIP1-A_4555 - Manuelles Hinzufügen eines Kartenterminals

Die Managementschnittstelle MUSS es einem Administrator ermöglichen für neue Kartenterminals CT-Objects manuell in CTM_CT_LIST aufzunehmen.
Hierzu MUSS der Administrator für das neue Kartenterminal folgende Werte eingeben können:

• IP-Adresse (Eingabe verpflichtend)
• TCP-Port (Eingabe optional)
• MAC-Adresse (Eingabe optional)
• Hostname (Eingabe optional)

Bestätigt der Administrator seine Eingaben, MUSS TUC_KON_054 mit Mode=ManuallyAdded und allen eingegebenen Parametern aufgerufen werden.
[<=]

Als Sicherung gegen den unbemerkten Austausch von Kartenterminals oder deren Identitäten wird das gSMC-KT über den Konnektor logisch an das eHealth-Kartenterminal gebunden. Dieser Vorgang wird als Pairing von Kartenterminal und gSMC-KT bezeichnet und ist ausführlich in [gemSpec_KT] beschrieben.

TIP1-A_4556 - Pairing mit Kartenterminal durchführen

Die Managementschnittstelle MUSS es einem Administrator ermöglichen alle Kartenterminals mit CT.CORRELATION = „zugewiesen“ in einer Liste einzusehen und für einen ausgewählten Eintrag mit CT.VALID_VERSION=True TUC_KON_053 auslösen zu können.

[<=]

TIP1-A_4557 - Ändern der Korrelationswerte eines Kartenterminals

Die Managementschnittstelle MUSS es einem Administrator ermöglichen zu einem Kartenterminal aus CTM_CT_LIST für KTs mit CT.IS_PHYSICAL=Ja den Wert für CT.CORRELATION nach folgenden Mustern zu ändern:

• CT.CORRELATION = „bekannt“
  Das Kartenterminal gilt als nicht durch den Konnektor verwaltet.
•  „zugewiesen“:
  Ein (per Service Announcement entdecktes) Kartenterminal dem Konnektor
  zuweisen.
  Folgende Schritte MUSS der Konnektor für diesen Zustandswechsel zuvor
  erfolgreich durchlaufen:
                     -     Rufe TUC_KON_055 „Befülle CT-Object“
                     -     Prüfen, ob CT.HOSTNAME bereits für ein anderes
                           Kartenterminal in CTM_CT_LIST verwendet wird. Wenn ja
                           MUSS dieser Änderungsversuch fehlschlagen (Prinzip der
                           Eindeutigkeit verletzt). Der Administrator MUSS eine
                           entsprechende Fehlermeldung erhalten.
• CT.CORRELATION = „zugewiesen“
  Das Kartenterminal gilt als durch den Konnektor verwaltet.
  •  „bekannt“
  •  „gepairt“:
    Das Pairing wurde erfolgreich durchgeführt; die Werte
    CT.SMKT_AUT, CT.SHARED_SECRET sind im CT-Objekt
    eingetragen.
• CT.CORRELATION = „gepairt“ 
  Verbundenheit zwischen Kartenterminal und gesteckter gSMC-KT wurde
  nachgewiesen
  •  „zugewiesen“:
    Die Werte CT.SMKT_AUT, CT.SHARED_SECRET werden gelöscht
  •  „aktiv“:  
    Wechsel nur möglich, wenn CT.VALID_VERSION=True. Dann Aufruf
    von TUC_KON_050 „Beginne Kartenterminalsitzung“ {ctId=CT.CtID;
    role=„User“}
• CT.CORRELATION = „aktiv"
  Das Kartenterminal kann fachlich genutzt werden
  •  „gepairt“:   
    Eventuelle TLS-Verbindung wird beendet, CT.CONNECTED auf Nein
    gesetzt.

[<=]

TIP1-A_5698 - Löschen von Kartenterminaleinträgen

Die Managementschnittstelle MUSS einem Administrator die Möglichkeit bieten, Kartenterminals aus der Liste der Kartenterminals (CTM_CT_LIST) zu entfernen.
[<=]

4.1.4.6.3 Import der Kartenterminal-Informationen

Im Rahmen des Konnektormanagements müssen die Konfigurationsdaten des Konnektors ex- und importiert werden können (siehe Kapitel 4.3.3). Eine Sonderstellung nimmt dabei der Import von Kartenterminalinformationen ein, da hier im Rahmen des Imports folgende Interaktion mit dem Administrator erforderlich ist:

TIP1-A_5011 - Import von Kartenterminal-Informationen

Der Konnektor MUSS vor der endgültigen Aktivierung der importierten Kartenterminalkonfiguration folgende zusätzliche Schritte ausführen:

• Die Liste der zu importierenden Kartenterminals MUSS dem Administrator angezeigt werden. Er MUSS die Möglichkeit erhalten, einzelne Kartenterminals aus dieser Liste zu löschen.
• Erst nach Bestätigung durch den Administrator werden die Kartenterminalinformationen in die Kartenterminalverwaltung übernommen.
• Sofern die Kartenterminal-Konfiguration in einen Konnektor mit neuer Identität importiert werden soll (neuer Konnektor oder neuer privater Schlüssel und neues Zertifikat C.SAK.AUT auf der gSMC-K), muss die neue Identität des Konnektors allen importierten Kartenterminals bekannt gemacht werden (Wartungs-Pairing, siehe auch [gemSpec_KT#2.5.2.4]).
  • Dazu baut der Konnektor unter der Nutzung von C.SAK.AUT eine temporäre TLS-Verbindung auf und sendet das eHealth-Kartenterminal-Kommando EHEALTH TERMINAL AUTHENTICATE in der Variante „ADD” an jedes in der Liste aufgeführte Kartenterminal. Mit dem Kommando und P2=03 holt sich der Konnektor eine Challenge.
  • Der eigentliche Austausch bzw. die Aufnahme des neuen Zertifikates erfolgt im KT erst, nachdem diese Challenge mit dem Kommando EHEALTH TERMINAL AUTHENTICATE im Modus P2=04 vom Konnektor korrekt beantwortet wurde. Dieses Kommando sowie die Erzeugung der Challenge-Antwort wird in [gemSpec_KT#3.7.2.4] und [gemSpec_KT#3.7.2] beschrieben.
  • Nach erfolgreicher Abarbeitung des Kommandos wird der Eintrag in die interne Liste der gepairten Kartenterminals übernommen und die temporäre Verbindung zum Kartenterminal abgebaut. Kann ein Kartenterminal nicht erreicht werden, so MUSS die Befehlskette nachgeholt werden, sobald das Kartenterminal vom Konnektor wieder als verfügbar erkannt wird.
• Zur abschließenden Kontrolle und zur weiteren fachlichen Nutzung baut der Konnektor zu jedem der neu konfigurierten und aktiv gesetzten Kartenterminals via TUC_KON_050 eine Verbindung auf.

[<=]

4.1.5 Kartendienst

Innerhalb des Kartendienstes werden folgende Präfixe für Bezeichner verwendet:

1.                     Events (Topic Ebene 1):    „CARD“
2.                     Konfigurationsparameter:    „CM_“

Der Konnektor verwaltet eine Liste aller Karten (CM_CARD_LIST), die in die vom Konnektor verwalteten Kartenterminals gesteckt sind (CTM_CT_LIST). Alle Ereignisse und Operationen, die sich auf Karten beziehen, werden durch diesen Basisdienst gekapselt.

Für jede gesteckte Karte vergibt er einen eindeutigen Identifikator (im weiteren Text CardHandle bezeichnet), mit dem diese Karte adressiert werden kann, um zu diesen oder mit diesen Karten Operationen auszuführen. Dieses Handle ist gültig bis zum Entfernen der Karte aus dem Kartenterminal.

Um die in [gemSpec_Perf] geforderten Zeiten für kartenbezogene Operationen erreichen zu können, kann es erforderlich sein, dass der Konnektor möglichst viele Informationen der Karten cached. Hierzu gehören Steuerdaten wie Extended Length, Version etc. aber auch Zertifikate der Karte (X.509 und CVC). Da es sich bei Caching um einen internen Mechanismus handelt, der sich nicht auf das funktionale Außenverhalten von TUCs oder Operationen auswirkt, wird das Caching nicht weiter beschrieben oder explizit gefordert. Es kann aber Anforderungen aus Sicherheitssicht bezüglich des Cachings geben (insbesondere hinsichtlich der erlaubten Caching-Dauer). Die Einhaltung dieser Vorgaben wird im Rahmen der CC-Evaluierung geprüft werden.

Der Kartendienst verwaltet mindestens die in der informativen Tabelle TAB_KON_531 ausgewiesenen Parameter, weitere herstellerspezifische Parameter sind möglich. Die normative Festlegung wann welche Parameter wie belegt werden, erfolgt in den folgenden Abschnitten und Unterkapiteln.

Tabelle 62: TAB_KON_531 Parameterübersicht des Kartendienstes 

ReferenzID	Belegung	Zustandswerte
CM_CARD_LIST	Liste von Card-Objekten	Eine Liste von Repräsentanzen (CardObjects) der dem Konnektor bekannten Karten. Die Attribute der Card-Objekte sind im Folgenden gelistet.
CARD.CARDHANDLE		vom Konnektor vergebenen eindeutigen Identifikator (Handle).
CARD.CTID		Kartenterminal, in dem die Karte steckt
CARD.SLOTNO		Slot, in dem die Karte steckt
CARD.ICCSN		ICCSN der Karte (sofern auslesbar),
CARD.TYPE		Typ der Karte gemäß Tabelle TAB_KON_500 Wertetabelle Kartentypen
CARD.CARDVERSION		die Versionsinformationen zum Produkttyp der Karte und den gespeicherten Datenstrukturen gemäß [gemSpec_Karten_Fach_TIP].
CARD.CARDVERSION. COSVERSION		Produkttypversion des COS
CARD.CARDVERSION. OBJECTSYSTEMVERSION		Produkttypversion des Objektsystems
CARD.CARDVERSION. CARDPTPERSVERSION		Produkttypversion der Karte bei Personalisierung
CARD.CARDVERSION. DATASTRUCTUREVERSION		Version der Speicherstrukturen (aus EF.Version)
CARD.CARDVERSION. LOGGINGVERSION		Version der Befüllvorschrift für EF.Logging
CARD.CARDVERSION. ATRVERSION		Version der Befüllvorschrift für EF.ATR
CARD.CARDVERSION. GDOVERSION		Version der Befüllvorschrift für EF.GDO
CARD.CARDVERSION. KEYINFOVERSION		Version der Befüllvorschrift für KeyInfo
CARD.INSERTTIME	Timestamp	Zeitpunkt, an dem die Karte gesteckt wurde
CARD.CARDHOLDERNAME	String	Name des Karteninhabers bzw. der Institution/Organisation (subject.commonName)
CARD.KVNR	String	Versicherten-ID (unveränderbarer Teil der KVNR)
CARD. CERTEXPIRATIONDATE		Ablaufdatum des AUT-Zertifikats der Karte
CARD. CERTSTATUS		Prüfungsergebnis aus TUC_KON_037 für  C.HCI.OSIG von SMC-B C.HP.QES von HBAx
CARD. CERTOCSPRESPONSE		OCSP-Response (TUC_KON_037) für C.HCI.OSIG von SMC-B C.HP.QES von HBAx
CARD.CARDSESSION_ LIST	Liste von CardSession-Objekten	Eine Liste von Repräsentanzen (CardSession-Objects) der pro Karte vorhandenen Kartensitzungen. Die Attribute der CardSession-Objekte sind im Folgenden gelistet. Das Tripel aus MandantID, CSID und UserID bildet den Kontext ab, in welchem diese Kartensitzung initiiert wurde.
CARDSESSION. AUTHSTATE	Liste von Einträgen aus a)C2C:KeyRef, Role oder b) CHV: PINRef	Liste von erreichten Sicherheitszuständen. Jeder einzelne Sicherheitszustand kann entweder über C2C gegen KeyRef (mit einer bestimmten Rolle gemäß [gemSpec_PKI_TI#Tab_PKI_918]) oder Card Holder Verification (CHV) gegen eine referenzierte PIN erreicht worden sein. Für eGK G2.0 wird der Zustand der MRPINs nicht in AuthState gespeichert.
CARDSESSION. MANDANTID		Mandant-ID
CARDSESSION.CSID		Clientsystem-ID
CARDSESSION.USERID		Nutzer-ID
CARDSESSION.AUTHBY	Referenz auf CardSession	Kartensitzung, über die diese Karte freigeschaltet wurde (nur für eGK belegt)
CARDSESSION. SIGNMODE	„PIN“ oder „Comfort“	Signaturmodus „PIN“: Komfortsignaturmodus ist für die CardSession ausgeschaltet "Comfort“: Komfortsignaturmodus ist für die CardSession eingeschaltet Default-Wert=“PIN“ Nur relevant für den HBA Eine HBA-CardSession mit eingeschaltetem Komfortsignaturmodus wird im Folgenden als Komfortsignatursession bezeichnet.

4.1.5.1 Funktionsmerkmalweite Aspekte

TIP1-A_4988-02 - Unterstützung von Kartengenerationen

Der Konnektor MUSS für eGK, HBA, SMC-B, gSMC-KT und gSMC-K Karten der Generation 2 unterstützen. Karten der Generation 2 sind alle Karten, deren Version des dem aktiven Objektsystem zugrundeliegenden Produkttyps (Tag ‘C1‘ in EF.Version2) den Wert 4.x.y hat, wobei x,y in {0, …, 255}.
Der Konnektor DARF eGKs der Generation < 2 (also 1 und 1+) NICHT unterstützen. eGKs der Generation < 2 werden im Konnektor als CARD.TYPE = UNKNOWN geführt.
Bei Karten der Generation 2

• MUSS der Konnektor die RSA-basierten Geräte-CV-Zertifikate unterstützen,
• MUSS der Konnektor die ECC-basierten Geräte-CV-Zertifikate unterstützen. 

[<=]

Es kann notwendig sein, Karten der Generation 2 (G2) näher zu bezeichnen. In diesem Fall wird in G2.0- und G2.1-Karten unterschieden. Wird von Karten der Generation 2 gesprochen, so gilt die Festlegung für G2.x (G2.0, G2.1 und höher) des betrachteten Kartentyps.

TIP1-A_4558 - Caching-Dauer von Kartendaten im Konnektor

Sofern der Konnektor Daten gesteckter Karten cached, so DÜRFEN diese Daten von HBAx und SM-B NICHT länger als 24 Stunden gecached werden.

Der Konnektor DARF Daten der eGK NICHT über den Steckzyklus der Karte hinaus cachen.
Ausnahme: Eine Cachingdauer über den Steckzyklus der eGK hinaus wird von einer Fachanwendung gefordert und durch die Fachmodulspezifikation dieser Fachanwendung definiert.

[<=]

TIP1-A_6031 - Kein selbsttätiges Zurücksetzen der SM-B

Der Konnektor DARF NICHT selbsttätig die SM-B und deren Sicherheitszustände zurücksetzen, auch nicht, wenn die Daten der SM-B nach Ablauf der 24-Stunden-Frist neu in den Cache eingelesen werden.

[<=]

TIP1-A_4559 - Konnektorzugriffsverbot auf DF.KT

Der Konnektor DARF NICHT auf das DF.KT einer gSMC-KT zugreifen.

[<=]

TIP1-A_4560 - Rahmenbedingungen für Kartensitzungen

Der Konnektor MUSS alle Zugriffe auf Karten aus CM_CARD_LIST, die den Sicherheitszustand der Karte erhöhen können oder einen erhöhten Sicherheitszustand der Karte voraussetzen, im Kontext einer Kartensitzung zu dieser Karte durchführen (CARD.CARDSESSION). Ausgenommen hiervon ist der Zugriff durch das CMS (bzw. VSDD) auf die eGK.

Der Konnektor MUSS sicherstellen, dass in einer Kartensitzung nur dann auf einen erhöhten Sicherheitszustand einer Karte zugegriffen werden kann, wenn die zur Erreichung dieses Sicherheitszustandes erforderlichen Authentisierungen (PIN-Verifikation, C2C-Rollen-Authentisierung etc.) in dieser verwendeten Kartensitzung erfolgreich durchgeführt wurden.

Der Konnektor MUSS Authentisierungen in einer Kartensitzung so durchführen, dass in anderen Kartensitzungen vorhandene Sicherheitszustände nicht beeinflusst werden. (Eine falsche PIN-Eingabe in einer Kartensitzung darf den erhöhten Sicherheitszustand einer anderen Sitzung nicht zurücksetzen etc.).

Der Konnektor SOLL die Verwaltung der Sicherheitsstatus der Kartensitzungen so über die Nutzung logischer Kartenkanäle umsetzen, dass PIN-Verifikationen, die für die Dauer der Kartensitzung Gültigkeit haben, nicht unnötig wiederholt werden müssen.

[<=]

Für die TUCs zur PIN-Eingabe, Änderung und Entsperrung sind Festlegungen hinsichtlich der auf dem Kartenterminal anzuzeigenden Meldungen erforderlich. Die folgende Tabelle definiert diese Terminalanzeigen gemäß [SICCT#5.5.10.19].

TIP1-A_4561-02 - Terminal-Anzeigen für PIN-Operationen

Der Konnektor MUSS im Rahmen des interaktiven PIN-Handlings die folgenden Displaymessages für die Anzeige im Kartenterminal verwenden:

Tabelle 63: TAB_KON_090 Terminalanzeigen beim Eingeben der PIN am Kartenterminal 

Karte/ Kontext	PIN-Referenz	I/O	Terminal-Anzeige	ANW (max.Anz. Zeichen)
eGK /PIN-Eingabe für Vertreter-PIN	PIN.AMTS_REP	I	Vertreter-PIN•0x0Bfür•0x0BANW 0x0FVertr-PIN:	22
eGK /PIN-Eingabe für Vertreter-PIN ändern	PIN.AMTS_REP	I	Vertreter-PIN•0x0Bändern 0x0FPIN.eGK:
eGK /PIN-Eingabe für Vertreter-PIN entsperren	PIN.AMTS_REP	I	Vertreter-PIN•0x0entsperren 0x0FPIN.eGK:
eGK /PIN-Eingabe für PIN-Schutz einschalten	MRPIN.NFD, MRPIN.DPE, MRPIN.AMTS, MRPIN.GDD	I	PIN-Schutz•0x0BANW•0x0Beinschalten 0x0FPIN.eGK:	16
eGK /PIN-Eingabe für PIN-Schutz abschalten	MRPIN.NFD, MRPIN.DPE, MRPIN.AMTS, MRPIN.GDD	I	PIN-Schutz•0x0BANW•0x0Babschalten 0x0FPIN.eGK:	16
eGK /Sonstige	ALLE (außer PIN.AMTS_REP)	I	PIN•0x0Bfür•0x0BANW 0x0FPIN.eGK:	32
HBAx	PIN.CH	I	Eingabe•0x0BFreigabe-PIN•0x0BHBA 0x0FPIN.HBA:
	PIN.QES (Signatur auslösen)	I	#UVW-XYZ•0x0BEingabe•0x0BSignatur- PIN•0x0BHBA 0x0FPIN.QES:
HBA	PIN.QES (Komfortsignatur aktivieren)	I	Komfortsignatur•0x0Baktivieren•0x0BHBA  0x0FPIN.QES:
SMC-B	PIN.SMC	I	Eingabe•0x0BPIN•SMC-B•0x0BSLOT:X 0x0FPIN.SMC:
ANDERE	BELIEBIG	I	Herstellerspezifisch
Erfolgreiche PIN-Eingabe	ALLE	O	PIN•0x0Berfolgreich•0x0Bverifiziert!
Fehlerhafte PIN-Eingabe	ALLE	O	PIN•0x0Bfalsch•0x0Boder•0x0Bgesperrt!
PUK-Eingabe	eGK PUK.CH	I	Eingabe•0x0BVersicherten-0x0BPUK 0x0FPUK.eGK:
	HBAx PUK.CH	I	Eingabe•0x0BFreigabe-PUK•0x0BHBA 0x0FPUK.HBA:
	HBAx PUK.QES	I	Eingabe•0x0BSignatur-PUK•0x0BHBA 0x0FPUK.QES:
	SMC-B PUK.SMC	I	Eingabe•0x0BPUK•SMC-B•0x0BSLOT:X 0x0FPUK.SMC:
Erfolgreiche PUK-Eingabe	ALLE	O	PIN•0x0Berfolgreich•0x0Bentsperrt!
Fehlerhafte PUK-Eingabe	ALLE	O	PUK•0x0Bfalsch•0x0Boder•0x0Bgesperrt!
Eingabe einer neuen PIN	eGK ALLE (außer PIN.AMTS_REP)	I	Eingabe• 0x0Bneue•0x0BVersicherten-0x0BPIN• 0x0B(6-8•Ziffern) 0x0FPIN.eGK:
	eGK PIN.AMTS_REP	I	Eingabe• 0x0Bneue•0x0BVertreter-PIN• 0x0B(6-8•Ziffern) 0x0FVertr-PIN:
	HBAx PIN.CH	I	Eingabe•0x0Bneue•0x0BFreigabe-PIN•0x0BHBA•0x0B(6-8•Ziffern) 0x0FPIN.HBA:
	HBAx PIN.QES	I	Eingabe• 0x0Bneue•0x0BSignatur-PIN•0x0BHBA•0x0B(6-8•Ziffern) 0x0FPIN.QES:
	SMC-B PIN.SMC	I	Eingabe•0x0Bneue•0x0BPIN•SMC-B• 0x0BSLOT:X•0x0B(6-8•Ziffern) 0x0FPIN.SMC:
Eingabe einer Transport-PIN	eGK PIN.CH	I	Eingabe•0x0BTransport-0x0BVersicherten-0x0BPIN 0x0FT-PIN.eGK:
	HBAx PIN.CH	I	Eingabe•0x0BTransport-0x0BPIN•0x0BHBA 0x0FT-PIN.HBA:
	HBAx PIN.QES	I	Eingabe•0x0BTransport-0x0BPIN•0x0BHBA 0x0FT-PIN.QES:
	SMC-B PIN.SMC	I	Eingabe•0x0BTransport-0x0BPIN•SMC-B•0x0BSLOT:X 0x0FT-PIN.SMC:
Wieder-holung einer neuen PIN	eGK PIN.CH	I	Eingabe•0x0BVersicherten-0x0BPIN•0x0B wiederholen! 0x0FPIN.eGK:
	eGK PIN.AMTS_REP	I	Eingabe• 0x0Bneue•0x0BVertreter-PIN• 0x0B wiederholen! 0x0FVertr-PIN:
	HBAx PIN.CH	I	Eingabe•0x0Bfür•HBA•0x0Bwiederholen! 0x0FPIN.HBA:
	HBAx PIN.QES	I	Eingabe•0x0Bfür•HBA•0x0Bwiederholen! 0x0FPIN.QES:
	SMC-B PIN.SMC	I	Eingabe•0x0BPIN.SMC•0x0BSLOT:X• 0x0Bwiederholen! 0x0FPIN.SMC:
Ungleichheit bei der Wieder-holung der Eingabe der neuen PIN	ALLE	O	PINs•0x0B nicht•0x0Bidentisch!•0x0BAbbruch!
Erfolgreiche PIN-Änderung	ALLE	O	PIN•0x0Berfolgreich•0x0Bgeändert!
Anzeigen am lokalen Terminal beim Remote-PIN-Verfahren für das Ergebnis der Verschlüsselung durch die gSMC-KT
Erfolgreiche Verschlüsselung	ALLE	O	Eingabe•0x0Bwird•0x0Bbearbeitet.
Fehler bei der Verschlüsselung	ALLE	O	Eingabe•0x0Bfehlgeschlagen.

[<=]

Hinweise zu den Terminalanzeigen bei PIN-Eingaben und zu obiger Tabelle:

• ANW kennzeichnet den Anwendungsfall und wird durch den vom Aufrufer übergebenen String ersetzt (siehe z. B. TUC_KON_012 „PIN verifizieren“)
• Zu PIN.SMC: "Slot:X" im PIN-Prompt gibt die Slot-Nummer im Kartenterminal an, in der die SMC steckt, da in einem Kartenterminal mehr als eine SMC stecken kann.
• Variable Teile der Terminalanzeige (Job- und Slot-Nummer) sind kursiv formatiert.
• Zeichensatz gemäß ISO 646DE-/DIN 66003-Codierung
• max. 48 Zeichen Text + 10 Zeichen PIN-Prompt bei Input
• max. 48 Zeichen bei Output
• Leerzeichen werden als "•" dargestellt
• UVW-XYZ: zeigt die Jobnummer an (siehe Kapitel 4.1.8.1.4)
• #: Beginn der Jobnummer zur Verifizierung des korrekten Kartenterminals
• Weitere Details zur Gestaltung der Jobnummer finden sich im Kapitel 4.1.8.1.4.
• Die Zeilenumbrüche in der Spalte "Terminal-Anzeige" sind editorisch bedingt.
• 0x0B und 0x0F (Sollbruchstellen bzw. Trennung zwischen Nachricht und PIN-Prompt) sind Trennzeichen gemäß [SICCT#5.6.1].

In den Technischen Use Cases TUC_KON_012 „PIN verifizieren“, TUC_KON_019 „PIN ändern“, TUC_KON_021 „PIN entsperren“ wird das Remote-PIN-Verfahren verwendet, sofern die Zielkarte in einem als für den Arbeitsplatz entfernt definiertem Kartenterminal steckt (siehe Kap. 4.1.1.1, Relation [7]). In diesem Fall erfolgt die Nutzerinteraktion am Remote-PIN-KT von workplaceId (PinInputKT). Dabei wendet der Konnektor das folgende Verfahren an:

TIP1-A_5012 - Remote-PIN-Verfahren

Der Konnektor MUSS das Remote-PIN Verfahren im Sinne der BSI TR-03114 unterstützen. Abweichend von der TR-03114 MUSS statt der SMC-A eine gSMC-KT verwendet werden.
Der Konnektor MUSS für die PIN-Objekte: HBA.PIN.CH, HBA.PUK.CH, HBA.PIN.QES, HBA.PUK.QES, SM-B.PIN.SMC und SM-B.PUK.SMC das Remote-PIN Verfahren unterstützen. Für alle anderen Karten und PIN-Objekte DARF das Verfahren NICHT verwendet werden.
Für die Interaktion mit dem Anwender MÜSSEN die Display Messages entsprechend TAB_KON_090 Terminalanzeigen beim Eingeben der PIN am Kartenterminal verwendet werden.
Der Ablauf für eine PIN-Operation gegen eine Zielkarte MUSS in diesen logischen Schritten erfolgen:

•      Aufruf TUC_KON_005 „Card-to-Card authentisieren“ mit eigens für diesen Zweck erzeugten Cardsession sowohl für die „Sendekarte“ im PinInputKT (gSMC-KT) sowie der Zielkarte. AuthMode ist „gegenseitig+TC“
•      Der Benutzer wird mit dem SICCT-Kommando PERFORM VERIFICATION bzw. MODIFY VERIFICATION DATA zur Eingabe der PIN am PinInputKT aufgefordert. Als Display Messages für die erfolgreiche Bearbeitung bzw. Fehler in der Bearbeitung dieser Kommandos müssen die Texte mitgesendet werden, die in TAB_KON_090 für die Ergebnisse der Verschlüsselung durch die gSMC-KT festgelegt sind.
•      Im PinInputKT verschlüsselt die gSMC-KT die eingegebene PIN mit dem zuvor erzeugten Sessionkey.
•      Die verschlüsselte PIN wird in das zur intendierten PIN-Operation passende Kommando eingebettet (PIN verifizieren, ändern oder entsperren - wird durch den eigentlichen PIN-TUC festgelegt) und das Kommando vom Konnektor an die Zielkarte zur Entschlüsselung und Verifikation übergeben. Dabei MUSS die Übertragung im gleichen Logischen Kanal wie die SM Vereinbarung erfolgen.
•      Der Konnektor zeigt das Resultat der Zielkarte mittels SICCT OUTPUT am lokalen Kartenterminal an. Er verwendet dabei den in TAB_KON_090 für die aktuelle PIN-Operation spezifizierten Ausgabetexte.
•      Das Result der Zielkarte wird an den Aufrufer zurückgegeben

Fehlermeldung: Ein Fehler in der Verarbeitung führt zum Abbruch mit Fehlercode 4053 „Remote-PIN nicht möglich“ (Security, Error).
[<=]

Hinweis: Derzeit schlägt die Freischaltung der SMC-B durch Card-2-Card-Authentisierung ohne Fehlermeldung fehl. Der Sicherheitszustand der SMC-B wird nicht verändert. Diese Einschränkung betrifft TUC_KON_005 „Card-to-Card authentisieren“ (TAB_KON_096).

4.1.5.2 Durch Ereignisse ausgelöste Reaktionen

TIP1-A_4562 - Reaktion auf „Karte entfernt“

Empfängt der Kartendienst das Ereignis „CT/SLOT_FREE“, so MUSS der Konnektor:

1.                      das über die im Ereignis gemeldeten Parameter CtID und SlotNo in CM_CARD_LIST adressierte CardObject CARD identifizieren
2.                      für dieses CardObject folgendes Ereignis absetzen:    
   TUC_KON_256{
         topic = „CARD/REMOVED“;
         eventType = Op;
         Severity = Info;
         parameters = <Params>}
   wobei <Params> mit folgenden Werten belegt werden MUSS:
   1.                             „CardHandle=$CARD.CARDHANDLE,
   2.                             Type=$CARD.TYP,
   3.                             CardVersion=$CARD.VER,
   4.                             ICCSN=$CARD.ICCSN,
   5.                             CtID=$CARD.CTID,
   6.                             SlotID=$CARD.SLOTID,
   7.                             InsertTime=$CARD.INSERTTIME,
   8.                             CardHolderName=$CARD.CARDHOLDERNAME,
   9.                             KVNR=$CARD.KVNR“
3.                      das zugehörige CardObject aus CM_CARD_LIST entfernen.

[<=]

TIP1-A_4563 - Reaktion auf „Karte gesteckt“

Empfängt der Kartendienst das Ereignis „CT/SLOT_IN_USE“, so MUSS der Konnektor für die Karte, die über die im Ereignis gemeldeten Parameter CtID und SlotNo adressiert ist, über TUC_KON_001 ein neues CardObject in CM_CARD_LIST anlegen.

[<=]

A_23614 - SMC-B Prüfung bei Steckvorgang

Wenn der Konnektor einen Steckvorgang für eine SMC-B erkennt, MUSS der Konnektor - im Anschluss an die in TUC_KON_001 geforderten Aktionen- das Signaturzertifikat der SMC-B wie folgt prüfen:

• Wenn MGM_LU_ONLINE= "Enabled"
  
  TUC_KON_037 „Zertifikat prüfen“{
     certificate = C.HCI.OSIG;
     qualifiedCheck = required;
     offlineAllowNoCheck = true;
     validationMode = OCSP;
     getOCSPResponses = includeRevocationInfo}

• Ist das Ergebnis der Statusprüfung "good", MUSS die OCSP-Response im Konnektor gespeichert werden.
  Die maximale Dauer der Speicherung von SMC-B-Informationen im Konnektor ist in TIP1-A_4558 festgelegt.

• Ist das Ergebnis der Statusprüfung nicht "good" MUSS der Konnektor ein Event auslösen: ("SMC-B Status not good") TUC_KON_256 „Systemereignis absetzen“ {

      topic = „CERT/CARD/STATUS”;
      eventType = Op;
      severity = Warning;
      parameters = („CARD_TYPE=$Type,
          ICCSN=$ICCSN,
          CARD_HANDLE=$CardHandle,
          CardHolderName=$CardHolderName,
           CertName=$Name von certificate,
          ExpirationDate=$validity“

CARD_CERTSTATUS= $CARD.CERTSTATUS

      doLog=false;
      doDisp = true }

 

• Wenn MGM_LU_ONLINE= "Disabled",
  
  TUC_KON_037 „Zertifikat prüfen“{
     certificate = C.HCI.OSIG;
     qualifiedCheck = required;
     offlineAllowNoCheck = true;
     validationMode = NONE }
  
  
  und Systemereignis senden

(SMC-B Status not available") TUC_KON_256 „Systemereignis absetzen“ {

      topic = „CERT/CARD/STATUS”;
      eventType = Op;
      severity = Warning;
      parameters = („CARD_TYPE=$Type,
          ICCSN=$ICCSN,
          CARD_HANDLE=$CardHandle,
          CardHolderName=$CardHolderName,
           CertName=$Name von certificate,
          ExpirationDate=$validity“,

CARD_CERTSTATUS= "NotAvailable")

      doLog=false;
      doDisp = true }

Außerdem MUSS der Konnektor für das AUT-Zertifikat der SMC-B (C.HCI.AUT) den Zertifikatsablauf wie folgt prüfen:
TUC_KON_033 „Zertifikatsablauf prüfen“ {
    cardSession;
    doInformClients = true } [<=]

A_23311 - HBA Prüfung bei Steckvorgang

Wenn der Konnektor einen Steckvorgang für einen HBAx erkennt, MUSS der Konnektor - im Anschluss an die in TUC_KON_001 geforderten Aktionen- das Signaturzertifikat des HBAx wie folgt prüfen:

• Wenn MGM_LU_ONLINE= "Enabled" und die Verbindung zum VPN-Konzentrator TI aufgebaut ist
  
  TUC_KON_037 „Zertifikat prüfen“{
     certificate = C.HP.QES;
     qualifiedCheck = required;
     offlineAllowNoCheck = true;
     validationMode = OCSP;
     getOCSPResponses = includeRevocationInfo}

• Ist das Ergebnis der Statusprüfung "good", MUSS die OCSP-Response im Konnektor gespeichert werden.
  Die maximale Dauer der Speicherung von HBA-Informationen im Konnektor ist in TIP1-A_4558 festgelegt.

• Ist das Ergebnis der Statusprüfung nicht "good" MUSS der Konnektor ein Event auslösen: ("HBA Status not good") TUC_KON_256 „Systemereignis absetzen“ {

      topic = „CERT/CARD/STATUS”;
      eventType = Op;
      severity = Warning;
      parameters = („CARD_TYPE=$Type,
          ICCSN=$ICCSN,
          CARD_HANDLE=$CardHandle,
          CardHolderName=$CardHolderName,
          CertName=$Name von certificate,
          ExpirationDate=$validity“

CARD_CERTSTATUS= $CARD.CERTSTATUS

      doLog=false;
      doDisp = true }

 

• Wenn MGM_LU_ONLINE= "Disabled",
  
  TUC_KON_037 „Zertifikat prüfen“{
     certificate = C.HP.QES;
     qualifiedCheck = required;
     offlineAllowNoCheck = true;
     validationMode = NONE }
  
  
  und Systemereignis senden

(HBA Status not available") TUC_KON_256 „Systemereignis absetzen“ {

      topic = „CERT/CARD/STATUS”;
      eventType = Op;
      severity = Warning;
      parameters = („CARD_TYPE=$Type,
          ICCSN=$ICCSN,
          CARD_HANDLE=$CardHandle,
          CardHolderName=$CardHolderName,
           CertName=$Name von certificate,
          ExpirationDate=$validity“,

CARD_CERTSTATUS= "NotAvailable")

      doLog=false;
      doDisp = true }

 

Außerdem MUSS der Konnektor für das AUT-Zertifikat des HBAx (C.HP.AUT) den Zertifikatsablauf wie folgt prüfen:
TUC_KON_033 „Zertifikatsablauf prüfen“ {
    cardSession;
    doInformClients = true }



[<=]

A_23702 - Keine Verzögerungen durch Prüfungen bei Steckvorgang

Der Konnektor SOLL die gemäß A_23311 für HBAx und A_23614 für SMC-B geforderten Prüfungen asynchron durchführen und die Verfügbarkeit der Karten für die fachliche Verwendung nicht verzögern. [<=]

4.1.5.3 Interne TUCs, nicht durch Fachmodule nutzbar

4.1.5.3.1 TUC_KON_001 „Karte öffnen“

TIP1-A_4565 - TUC_KON_001 „Karte öffnen“

Der Konnektor MUSS den technischen Use Case „Karte öffnen“ gemäß TUC_KON_001 umsetzen.
 

Tabelle 64: TAB_KON_734 – TUC_KON_001 „Karte öffnen“ 

Element	Beschreibung
Name	TUC_KON_001 „Karte öffnen“
Beschreibung	Der TUC initialisiert ein Card-Object basierend auf einer physikalischen Karte und fügt es CM_CARD_LIST zu. Die Karte kann erst im Anschluss unter Verwendung des erzeugten CardHandles verwendet werden.
Auslöser	Der Kartenterminaldienst meldet das Belegen eines KT-Slots
Vorbedingungen	In ctId/slotId steckt eine Karte
Eingangsdaten	ctId (Kartenterminalidentifikator)      slotId (Nummer des Kartenslots)
Komponenten	Karte, Kartenterminal, Konnektor
Ausgangsdaten	Keine
Standardablauf	1. Prüfe, ob unter ctId und slotId ein Eintrag in CM_CARD_LIST     vorhanden ist. Wenn bereits ein Eintrag vorhanden ist, lösche diesen. 2. Erzeuge neuen Card-Object-Eintrag in CM_CARD_LIST und a)      Generiere CARD.CARDHANDLE. mit folgenden Anforderungen:             -               Das CardHandle MUSS innerhalb CM_CARD_LIST                  eindeutig sein.             -               Ein ungültig gewordenes CardHandle DARF innerhalb                  von 48h NICHT als neues CardHandle vergeben werden. b)      Befülle CARD.CTID und CARD.SLOTNO mit den Eingangsdaten c)      Ermittle und befülle (soweit durch Karte unterstützt) die folgenden      Daten:             -               CARD.ICCSN             -               CARD.TYPE (mögliche Werte siehe Tabelle                  TAB_KON_500 Wertetabelle Kartentypen)             -               CARD.CARDVERSION             -               CARD.INSERTTIME (=aktuelle Systemzeit)             -               CARD.CARDHOLDERNAME (aus X.509-AUT-                   Zertifikat)             -               CARD.KVNR (nur für eGK, aus C.CH.AUT:                   unveränderbarer Teil der KVNR)             -               CARD.CERTEXPIRATIONDATE (=validity aus X.509-                   AUT-Zertifikat) X.509-AUT-Zertifikat bezeichnet für eGK das C.CH.AUT-Zertifikat, für HBAx das C.HP.AUT-Zertifikat und für SMC-B das C.HCI.AUT-Zertifikat. 3. Rufe TUC_KON_256{            topic = „CARD/INSERTED“;            eventType = Op;            severity = Info;            parameters = <Params>}      mit <Params> belegt aus dem CARD-Object: „CardHandle=$, CardType=$, CardVersion=$, ICCSN=$,CtID=$, SlotID=$, InsertTime=$, CardHolderName=$, KVNR=$, CertExpirationDate=$“ In CardVersion sind die Werte    - COSVERSION und    - OBJECTSYSTEMVERSION aus CARD.CARDVERSION einzutragen. Für eGK G1+ ist zusätzlich die    - DATASTRUCTUREVERSION aus CARD.CARDVERSION einzutragen. CardVersion kann weitere Werte aus CARD.CARDVERSION enthalten.
Varianten/ Alternativen	Im Falle der KVK gibt es kein EF.ATR, EF.GDO und EF.DIR. Es wird daher   lediglich der ATR ausgewertet, den das Kartenterminal beim Stecken der   Karte liefert.
Fehlerfälle	(-> 2c) Karte/Kartenterminal antwortet mit einer spezifischen Fehlermeldung, Fehlercode <gemäß [gemSpec_COS]/[SICCT]> Auch im Fehlerfall wird Schritt 3 durchlaufen. Wenn nicht alle zu einem Kartentyp notwendigen Daten von der Karte gelesen werden konnten, dann wird Schritt 3 mit CardType=UNKNOWN ausgeführt. Auch im Fehlerfall wird Schritt 3 durchlaufen. Wenn nicht alle zu einem Kartentyp notwendigen Daten von der Karte gelesen werden konnten, dann wird Schritt 3 mit CardType=UNKNOWN ausgeführt.
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	Keine

[<=]

4.1.5.4 Interne TUCs, auch durch Fachmodule nutzbar

4.1.5.4.1 TUC_KON_026 „Liefere CardSession“

TIP1-A_4566 - TUC_KON_026 „Liefere CardSession“

Der Konnektor MUSS den technischen Use Case „Liefere CardSession“ gemäß TUC_KON_26 umsetzen.

Tabelle 65: TAB_KON_735 - TUC_KON_026 

Element	Beschreibung
Name	TUC_KON_026 „Liefere CardSession“
Beschreibung	Dieser Use Case gibt auf Grund der übergebenen Parameter die zugehörige CardSession zurück. Ist für die Parameterkombination noch keine CardSession vorhanden, wird eine neue erzeugt und im zugehörigen Card-Object hinterlegt.
Auslöser	Indirekter Aufruf über durch Clientsysteme ausgeführte Operationen.     Aufruf durch Fachmodul
Vorbedingungen	Keine
Eingangsdaten	mandantId clientSystemId cardHandle userId - optional/verpflichtend, wenn cardType = HBAx
Komponenten	Konnektor
Ausgangsdaten	cardSession
Standardablauf	Ermittle Card in CM_CARD_LIST über cardHandle    Prüfe dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.    Ermittle cardSession in Card.CARDSESSION_LIST über mandantId, clientSystemId und userId
Varianten/ Alternativen	(3) Wenn keine CardSession für diese Parameter vorhanden:  1.                    erzeuge neue CardSession in Card.         CARDSESSION_LIST  2.                    Befülle CARDSESSION.MANDANTID, .CSID und         .USERID mit Übergabeparametern
Fehlerfälle	(2) Karte bereits reserviert, Fehlercode 4093
Nichtfunktionale Anforderungen	keine
Zugehörige Diagramme	keine

Tabelle 66: TAB_KON_824 Fehlercodes TUC_KON_026 „Liefere CardSession“ 

Fehlercode	ErrorType	Severity	Fehlertext
4093	Technical	Error	Karte wird in einer anderen Kartensitzung exklusiv verwendet

[<=]

Hinweis zu TAB_KON_735 - TUC_KON_026: Die WorkplaceId wird als Eingangsparameter nicht benötigt. Bereits TUC_KON_000 stellt sicher, dass eine eGK jeweils nur von einem einzigen Arbeitsplatz aus angesprochen werden kann.

4.1.5.4.2 TUC_KON_012 „PIN verifizieren“

TIP1-A_4567 - TUC_KON_012 „PIN verifizieren”

Der Konnektor MUSS den technischen Use Case „PIN verifizieren“ gemäß TUC_KON_012 umsetzen.
 

Tabelle 67: TAB_KON_087 – TUC_KON_012 „PIN verifizieren“ 

Element	Beschreibung
Name	TUC_KON_012 „PIN verifizieren“
Beschreibung	Dieser Use Case führt die Verifikation einer PIN einer Karte durch. Dabei wird der Anwender am Display des Kartenterminals aufgefordert, die PIN einzugeben. Dies erfolgt am PIN-Pad des Kartenterminals. Remote-PIN-Eingabe wird dabei automatisch unterstützt.
Auslöser	Aufruf des Use Case durch Basisdienste des Konnektors                         Aufruf des Use Cases durch ein Fachmodul im Konnektor                         Aufruf der Operation VerifyPin des CardService (siehe 4.1.5.5.1) durch das Clientsystem.
Vorbedingungen	Karte unterstützt die übergebene pinRef
Eingangsdaten	cardSession (Kartensitzung der Karte, deren PIN verifiziert werden soll) workplaceId pinRef (Referenz auf die zu verifizierende PIN, gemäß der Objektsystem-Spezifikation des jeweiligen Kartentyps.) actionName – optional/verpflichtend, wenn cardType = eGK (Zeichenkette, max. 32 bzw. 22 Zeichen PIN.AMTS_REP mit dem Namen der zugreifenden Fachanwendung bzw. des zu nutzenden Datenobjekts und der Zugriffsart, die mit dieser PIN freigeschaltet werden soll, z. B. für MRPIN.NFD: actionName  = „Notfalldaten schreiben“; Positionen in der Zeichenkette, an denen ein Zeilenumbruch bei der Ausgabe am Kartenterminal erlaubt ist, werden mit `0x0B` gekennzeichnet. `0x0B` zählt bei der Länge der Zeichenkette nicht.) verificationType [Mandatorisch | Sitzung] (Art der PIN-Verifikation:          Mandatorisch: PIN wird immer verifiziert.          Sitzung: PIN wird nicht erneut verifiziert, falls dies für die cardSession zuvor bereits geschehen ist und der dadurch erreichte Sicherheitszustand nicht zurückgesetzt wurde.)
Komponenten	Karte, Kartenterminal, Konnektor
Ausgangsdaten	pinResult [PinResult] (Ergebnis der PIN-Verifikation) leftTries – optional/verpflichtend, wenn pinResult = REJECTED (Anzahl der verbleibenden Versuche)
Standardablauf	1.         Ermittle Card = CM_CARD_LIST(CardSession) 2.         Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder      der Aufrufer das Karten-Lock besitzt. 3.         Wenn PinTyp(pinRef) = PIN.QES oder      VerificationType = Mandatorisch 6. 4.         Wenn pinRef in CARDSESSION.AUTHSTATE vorhanden:         pinResult = OK; 5.         Prüfe TUC_KON_022 „Liefere PIN-Status“         a.        „VERIFYABLE“;          b.        „DISABLED“: pinResult = OK; 6.         Ermittle PinInputKT: Wenn Card.ctId ein dem      Arbeitsplatz(workplaceId) lokal zugeordnetes Kartenterminal ist      (siehe Relation [6], Kapitel 4.1.1.1)         a.            Setze PinInputKT = Card.CtID         b.            sonst „lokales Kartenterminal, das für die Remote-PIN-                Eingabe zu verwenden ist“: PinInputKT =                Arbeitsplatz(workplaceId).remote-PIN-KT(mandantId) 7.         Atomare Operation: PIN verifizieren inkl. Eventing und      Ergebnisvermerk      a.             Rufe TUC_KON_256 {                topic = „CARD/PIN/VERIFY_STARTED“;                eventType = Op;                severity =Info;                parameters = („CardHandle=$, CardType=$,                          ICCSN=$, CtID=$, SlotID=$,                          PinRef=$, PinInputCtID=$PinInputKT“,                doLog=false)}      b.             Pin-Verifikation über „Perform Verification“ ([SICCT]) mit          Display Messages gemäß Kontext in TAB_KON_090           Terminalanzeigen beim Eingeben der PIN am Kartenterminal, bei           eGK ersetze „ANW“ durch actionName in Display Message.           Wenn PinInputKT=Card.CtID dann PIN Verifikation direkt an           Card.CtID, ansonsten Remote-PIN-Eingabe gemäß (TIP1-           A_5012)      c.             Setze pinResult in Abhängigkeit von Ergebnis Perform           Verification:                 -         pinResult = OK für erfolgreiche Prüfung                 -         pinResult = ERROR für Nutzer-Abbruch oder                   Bearbeitungsfehler (siehe Fehlerfälle)            -              pinResult = REJECTED für falsche PIN;                   leftTries = x (bei Kartenantwort ´63 Cx´, x > 0)                 -         pinResult = BLOCKED für gesperrte PIN (bei                   Kartenantwort ´63 C0´)      d.            Rufe TUC_KON_256 {               topic = „CARD/PIN/VERIFY_FINISHED“;               eventType = Op;               severity = Info;               parameters = („CardHandle=$, CardType=$,                          ICCSN=$, CtID=$, SlotID=$, PinRef=$,                          PinInputCtID=$PinInputKT, Result=$pinResult“);               doLog = false }     e.             befülle CARDSESSION.AUTHSTATE mit pinRef und           Ergebnis der PIN-Prüfung 8.         Liefere pinResult zurück
Varianten/ Alternativen	Schritt 7e: Für eGK G2.0 wird der Zustand der MRPINs nicht in AuthState gespeichert.
Fehlerfälle	Schritt 7 wird mit allen Teilschritten durchlaufen. Ein als Fehler ausgewiesener Zustand führt erst nach Schritt 7e zum Abbruch des TUCs. Fehleingaben zählen explizit nicht zu den Fehlerzuständen, sondern werden auf das Ergebnis REJECTED oder BLOCKED abgebildet.     * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD           Sekunden, Fehlercode 4094   (2) Karte ist fremd reserviert, Fehlercode 4093   (5) Rückgabewert=           - VERIFIED, Fehlercode 4001           - TRANSPORT_PIN oder EMPTY_PIN, Fehlercode 4065           - BLOCKED, Fehlercode 4063   (6b) kein Remote-PIN-KT zugeordnet, Fehlercode 4092   (->6b) Card.TYP=eGK und Card.CtID ist nicht dem durch workplaceId           bezeichneten Arbeitsplatz lokal zugeordnet: Fehlercode 4053   (7) Timeout bei PIN Eingabe: Fehlercode 4043   (7) Abbruch durch Nutzer: Fehlercode 4049   (7) Sind das für die PIN-Eingabe benötigte Kartenterminal oder           benötigte Teile davon (PIN Pad, Display) durch einen anderen           zeitgleich im Konnektor ablaufenden Vorgang reserviert, so bricht           der Use Case mit Fehler 4060 ab.   (7) Rückgabewert=          - transportgeschützt (Transport-PIN oder Leer-PIN), Fehlercode          4065   (7b) Ungültige PIN-Referenz; Fehlercode 4072   (7b) Karte/Kartenterminal antwortet mit einer spezifischen          Fehlermeldung, Fehlercode <gemäß [gemSpec_COS]/[SICCT]> Zusätzliche Fehlerfälle ergeben sich aus der Remote-PIN-Eingabe gemäß (TIP1-A_5012)
Nichtfunktionale Anforderungen
Zugehörige  Diagramme	Abbildung PIC_KON_111 Aktivitätsdiagramm zu „PIN verifizieren“

 

 

Abbildung 10: PIC_KON_111 Aktivitätsdiagramm zu „PIN verifizieren“ 

Tabelle 68: TAB_KON_089 Fehlercodes TUC_KON_012 „PIN verifizieren“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4001	Technical	Error	Interner Fehler
4043	Technical	Warning	Timeout bei der PIN-Eingabe
4049	Technical	Error	Abbruch durch den Benutzer
4053	Security	Error	Remote-PIN nicht möglich
4060	Technical	Error	Ressource belegt
4063	Security	Error	PIN bereits gesperrt (BLOCKED)
4065	Technical	Warning	PIN ist transportgeschützt, Änderung erforderlich
4072	Technical	Error	Ungültige PIN-Referenz PinRef
4092	Technical	Error	Remote-PIN-KT benötigt aber für diesen Arbeitsplatz nicht definiert
4093	Technical	Error	Karte wird in einer anderen Kartensitzung exklusiv verwendet
4094	Technical	Error	Timeout beim Kartenzugriff aufgetreten

[<=]

4.1.5.4.3 TUC_KON_019 „PIN ändern“

TIP1-A_4568 - TUC_KON_019 „PIN ändern”

Der Konnektor MUSS den technischen Use Case „PIN ändern“ gemäß TUC_KON_019 umsetzen.
 

Tabelle 69: TAB_KON_736 – TUC_KON_019 „PIN ändern“ 

Element	Beschreibung
Name	TUC_KON_019 „PIN ändern“
Beschreibung	Dieser Use Case führt die Änderung einer PIN einer Karte durch. Dabei wird der Anwender am Display des Kartenterminals aufgefordert, alte und neue PIN einzugeben. Remote-PIN-Eingabe wird dabei automatisch unterstützt.
Auslöser	Aufruf der Operation ChangePin des CardService (siehe 4.1.5.5.2) durch das Clientsystem.       Aufruf durch Fachmodul
Vorbedingungen	Karte unterstützt die übergebene pinRef
Eingangsdaten	cardSession       workplaceId (Arbeitsplatz-Identifikator)       pinRef (Referenz auf die zu ändernde PIN, gemäß der Objektsystem-Spezifikation des jeweiligen Kartentyps)       sourceCardSession – optional/verpflichtend, wenn C2C erforderlich ist (CardSession der Karte, die für die Card-to-Card-Authentisierung bei Änderung der PIN einer eGK der Generation 1+ verwendet werden soll.)
Komponenten	Karte, Kartenterminal, Konnektor
Ausgangsdaten	pinResult [PinResult] (Ergebnis der PIN-Verifikation)       leftTries – optional/verpflichtend, wenn pinStatus = REJECTED (verbleibende Versuche)
Standardablauf	Ermittle Card = CM_CARD_LIST(CardSession) Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt. Prüfe TUC_KON_022 „Liefere PIN-Status“ {cardSession; pinRef}<>BLOCKED Wenn pinRef=PIN.AMTS_REP,  dann rufe TUC_KON_012 „PIN verifizieren“ {   cardSession;   workplaceId;     pinRef=PIN.CH;   actionName= „”;   mandatorisch} Wenn Card.TYP=eGK UND Card.Version=Generation1+, dann Aufruf TUC_KON_005 „Card-to-Card authentisieren“{      sourceCardSession;      targetCardSession=cardSession;      AuthMode =einseitig}. Falls keine sourceCardSession angegeben ist, kann die CardSession der für den Mandanten verwalteten SMC-B verwendet werden.   Ermittle PinInputKT: Wenn Card.ctId ein dem Arbeitsplatz (workplaceId) lokal zugeordnetes Kartenterminal ist (siehe Relation [6], Kapitel 4.1.1.1) Setze PinInputKT = Card.CtID sonst „lokales Kartenterminal, das für die Remote-PIN-Eingabe zu verwenden ist“: PinInputKT = Arbeitsplatz(workplaceId).remote-PIN-KT(mandantId) Atomare Operation: PIN ändern inkl. Eventing und Ergebnisvermerk Rufe TUC_KON_256 {     topic = „CARD/PIN/CHANGE_STARTED“;     eventType = Op;     severity = Info;     parameters = („CardHandle=$, CardType=$,                 ICCSN=$, CtID=$, SlotID=$, PinRef=$,                 PinInputCtID=$PinInputKT“);     doLog = false } Pin-Änderung über „MODIFY VERIFICATION DATA“ ([SICCT]) mit Display Messages entsprechend TAB_KON_090 Terminalanzeigen beim Eingeben der PIN am Kartenterminal.     Bei Änderung der Versicherten-PIN der  eGK ist dabei der Platzhalter „ANW“ durch den String „Änderung“ zu ersetzen. Der Platzhalter "#UVW-XYZ" entfällt für die PIN.QES des HBA. Wenn PinInputKT=Card.CtID, dann PIN-Änderung direkt an Card.CtID, ansonsten Remote-PIN-Eingabe gemäß (TIP1-A_5012)     Dabei sowohl Unterstützung normaler PIN-Änderung als auch Umsetzens eines Transportschutzes (alle Varianten gemäß Kartenspec sind zu unterstützen) Setze pinResult in Abhängigkeit von Ergebnis MODIFY VERIFICATION DATA: -    pinResult = OK für erfolgreiche Änderung -    pinResult = ERROR für Nutzer-Abbruch oder                            Bearbeitungsfehler (siehe Fehlerfälle)     pinResult = REJECTED für falsche PIN-Eingaben;                          leftTries = x                          (bei Kartenantwort ´63 Cx´, x > 0) -    pinResult = BLOCKED für gesperrte PIN (bei Kartenantwort ´63 C0´) Rufe TUC_KON_256 {     topic = „CARD/PIN/CHANGE_FINISHED“;     eventType = Op;     severity = Info;     parameters = („CardHandle=$, CardType=$,                 ICCSN=$;CtID=$, SlotID=$, PinRef=$,                 PinInputCtID=$PinInputKT, Result=pinStatus“);     doLog = false} Wenn Result = REJECTED oder BLOCKED , dann entferne PinRef aus CARDSESSION.AUTHSTATE Liefere pinResult und ggf. leftTries zurück
Varianten/ Alternativen	Schritt 4: Für eGK G2.0 gilt:     Wenn pinRef=PIN.AMTS_REP, dann        rufe TUC_KON_012 „PIN verifizieren“ {               cardSession;               workplaceId;               pinRef=MRPIN.AMTS;               actionName= „”;               mandatorisch} Schritt 7e: Für eGK G2.0 wird der Zustand der MRPINs nicht in AuthState gespeichert.
Fehlerfälle	Schritt 7 wird mit allen Teilschritten durchlaufen. Ein als Fehler ausgewiesener Zustand führt erst nach Schritt 7e zum Abbruch des TUCs. * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden,    Fehlercode 4094 (2) Karte ist fremd reserviert, Fehlercode 4093        (3) pinStatus=BLOCKED: Fehlercode 4063 (5) sourceCardSession benötigt aber leer, Fehlercode 4071 (6b) kein Remote-PIN-KT zugeordnet, Fehlercode 4092 (->6b) Card.TYP=eGK und Card.CtID ist nicht dem durch workplaceId       bezeichneten Arbeitsplatz lokal zugeordnet: Fehlercode 4053 (7b) neue PIN zu kurz/lang: Fehlercode 4068 (7b) zweite neue PIN<> erste neue PIN: Fehlercode 4067        (7b) Timeout bei PIN-Eingabe: Fehlercode 4043. (7b) Abbruch durch Nutzer: Fehlercode 4049. (7b) Ist das Kartenterminal oder Teile davon (PIN-Pad, Display) durch       einen anderen Vorgang reserviert: Fehlercode 4060 (7b) kein PIN-Pad am Kartenterminal verfügbar: Fehlercode 4066 (7b) Ungültige PIN-Referenz; Fehlercode 4072 (7b) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode       <Kartenfehlercode gemäß [gemSpec_COS]> Zusätzliche Fehlerfälle ergeben sich aus der Remote-PIN-Eingabe gemäß (TIP1-A_5012)
Nichtfunktionale Anforderungen	keine
Zugehörige Diagramme	keine

Tabelle 70: TAB_KON_093 Fehlercodes TUC_KON_019 „PIN ändern“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4043	Technical	Warning	Timeout bei der PIN-Eingabe
4049	Technical	Error	Abbruch durch den Benutzer
4053	Security	Error	Remote-PIN nicht möglich
4060	Technical	Error	Ressource belegt
4063	Security	Error	PIN bereits blockiert (BLOCKED)
4066	Technical	Error	PIN Pad nicht verfügbar
4067	Security	Error	neue PIN nicht identisch
4068	Security	Error	neue PIN zu kurz/zu lang
4071	Technical	Error	keine Karte für C2C-Auth gesetzt
4072	Technical	Error	ungültige PIN-Referenz PinRef
4092	Technical	Error	Remote-PIN-KT benötigt aber für diesen Arbeitsplatz nicht definiert
4093	Technical	Error	Karte wird in einer anderen Kartensitzung exklusiv verwendet
4094	Technical	Error	Timeout beim Kartenzugriff aufgetreten

[<=]

4.1.5.4.4 TUC_KON_021 „PIN entsperren“

TIP1-A_4569-02 - TUC_KON_021 „PIN entsperren“

Der Konnektor MUSS den technischen Use Case „PIN entsperren“ gemäß TUC_KON_021 umsetzen.
 

Tabelle 71: TAB_KON_236 – TUC_KON_021 „PIN entsperren“ 

Element	Beschreibung
Name	TUC_KON_021 „PIN entsperren“
Beschreibung	Dieser Use Case setzt den Fehlbedienungszähler für diese PIN in der Karte auf seinen Anfangswert zurück und es wird optional eine neue PIN gesetzt. Remote-PIN-Eingabe wird dabei automatisch unterstützt.
Auslöser	Aufruf der Operation UnblockPin des CardService (siehe 4.1.5.5.4) durch das Clientsystem.
Vorbedingungen	Karte unterstützt die übergebene pinRef
Eingangsdaten	cardSession CardSession der Karte, deren PIN entsperrt werden soll) workplaceId pinRef (Referenz auf die zu entsperrende PIN, gemäß der Objektsystem-Spezifikation des jeweiligen Kartentyps) setNewPin (true/false) - Angabe, ob eine neue PIN gesetzt oder die aktuelle weiterverwendet werden soll. Default = false sourceCardSession - optional/wenn eGK G1+ (CardSession der Karte, die für die Card-to-Card-Authentisierung bei Entsperrung der PIN einer eGK der Generation 1+ verwendet werden soll)
Komponenten	Karte, Kartenterminal, Konnektor
Ausgangsdaten	result [PukResult]) (Ergebnis der PIN-Entsperrung durch PUK-Eingabe) leftTries – optional/verpflichtend, wenn pukStatus = REJECTED (verbleibende Versuche des PUKs)
Standardablauf	Ermittle Card = CM_CARD_LIST(Target.CardHandle)       Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.       Wenn TUC_KON_022 „Liefere PIN-Status“ {     cardSession;     pinRef } <>( „BLOCKED“ oder "TRANSPORT_PIN" )  dann beende TUC erfolgreich.       Wenn pinRef=PIN.AMTS_REP,  dann             setNewPin = true             rufe TUC_KON_012 „PIN verifizieren“ {     cardSession;     workplaceId;       pinRef=PIN.CH;     actionName= „”;     mandatorisch}       Wenn Card.TYP=eGK UND Card.Version=Generation1+, dann Aufruf TUC_KON_005 „Card-to-Card authentisieren“ {    sourceCardSession;    targetCardSession=cardSession;    AuthMode =einseitig }. Falls keine sourceCardSession angegeben ist, kann die CardSession der für den Mandanten verwalteten SMC-B verwendet werden.       Ermittle PinInputKT: Wenn Card.ctId ein dem Arbeitsplatz(workplaceId) lokal zugeordnetes Kartenterminal ist (siehe Relation [6], Kapitel 4.1.1.1)             Setze PinInputKT = Card.CtID             sonst „lokales Kartenterminal, das für die Remote-PIN-Eingabe zu verwenden ist“: PinInputKT = Arbeitsplatz(workplaceId).remote-PIN-KT(mandantId)       Atomare Operation: PIN entsperren inkl. Eventing und Ergebnisvermerk             Rufe TUC_KON_256 {     topic = „CARD/PIN/CHANGE_STARTED“;     eventType = Op;     severity = Info;     parameters = („CardHandle=$, CardType=$,                 ICCSN=$, CtID=$; SlotID=$, PinRef=$,                 PinInputCtID=$PinInputKT“);     doLog=false}             PIN-Entsperrung mit Display Messages entsprechend TAB_KON_090 Terminalanzeigen beim Eingeben der PIN am Kartenterminal.     Wenn PinInputKT=Card.CtID, dann PIN-Änderung direkt an Card.CtID, ansonsten Remote-PIN-Eingabe gemäß (TIP1-A_5012)     Für pinRef == PIN.QES über „PERFORM VERIFICATION“ [SICCT] mit dem eingebetteten Kommando Reset Retry Counter in der Variante P1=1 (keine neue PIN setzen).     Für pinRef<>PIN.QES wenn setNewPin = false,     dann über PERFORM VERIFICATION“ [SICCT], sonst über „MODIFY VERIFICATION DATA“ [SICCT]. Das mit dem SICCT-Kommando als Command-To-Perform mitgesandte „Reset Retry Counter“ wird entsprechend dem Wert von setNewPIN parametrisiert.             Setze result in Abhängigkeit von Ergebnis Perform Verification bzw. Modify VerificationData: result = OK für erfolgreiche Entsperrung result = ERROR für Nutzer-Abbruch oder Bearbeitungsfehler (siehe Fehlerfälle) result = REJECTED für falsche PUK; result = BLOCKED für gesperrte PUK; (bei Kartenantwort ´63 C0´)             Rufe TUC_KON_256 {   topic=„CARD/PIN/CHANGE_FINISHED“;   eventType=Op; severity=Info;   parameters = („CardHandle=$; CardType=$; ICCSN=$;CtID=$; SlotID=$; PinRef=$; PinInputCtID=$PinInputKT; Result=$“); doLog=false }       Liefere result und ggf. leftTries zurück
Varianten/ Alternativen	Schritt 4: Für eGK G2.0 gilt:     Wenn pinRef=PIN.AMTS_REP,  dann        rufe TUC_KON_012 „PIN verifizieren“ {               cardSession;               workplaceId;               pinRef=MRPIN.AMTS;               actionName= „”;               mandatorisch}
Fehlerfälle	Schritt 7 wird mit allen Teilschritten durchlaufen. Ein als Fehler ausgewiesener Zustand führt erst nach Schritt 7d zum Abbruch des TUCs.   * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD          Sekunden, Fehlercode 4094   (2) Karte wird in einer anderen Kartensitzung exklusiv          verwendet, Fehlercode 4093   (5) sourceCardSession benötigt aber leer, Fehlercode 4071     (6b) kein Remote-PIN-KT zugeordnet, Fehlercode 4092   (6b) Card.TYP=eGK und Card.CtID ist nicht dem durch workplaceId          bezeichneten Arbeitsplatz lokal zugeordnet: Fehlercode 4053   (7b) blockierte PUK: Fehlercode 4064   (7b) neue PIN zu kurz/lang: Fehlercode 4068   (7b) zweite neue PIN<> erste neue PIN: Fehlercode 4067   (7b) Timeout bei PIN Eingabe: Fehlercode 4043.   (7b) Abbruch durch Nutzer: Fehlercode 4049.   (7b) Ist das Kartenterminal oder Teile davon (PIN-Pad, Display) durch         einen anderen Vorgang reserviert: Fehlercode 4060   (7b) Karte/Kartenterminal antwortet mit einer spezifischen         Fehlermeldung, Fehlercode <gemäß [gemSpec_COS]/[SICCT]>   (7b) Ungültige PIN-Referenz; Fehlercode 4072. Zusätzliche Fehlerfälle ergeben sich aus der Remote-PIN-Eingabe gemäß (TIP1-A_5012)
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	Keine

Tabelle 72: TAB_KON_193 Fehlercodes TUC_KON_021 „PIN entsperren“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4043	Technical	Warning	Timeout bei der PIN-Eingabe
4049	Technical	Error	Abbruch durch den Benutzer
4053	Security	Error	Remote-PIN nicht möglich
4060	Technical	Error	Ressource belegt
4064	Security	Error	alte PIN bereits blockiert (hier: PUK)
4067	Security	Error	neue PIN nicht identisch
4068	Security	Error	neue PIN zu kurz/zu lang
4072	Technical	Error	ungültige PIN-Referenz PinRef
4092	Technical	Error	Remote-PIN-KT benötigt aber für diesen Arbeitsplatz nicht definiert
4093	Technical	Error	Karte wird in einer anderen Kartensitzung exklusiv verwendet
4094	Technical	Error	Timeout beim Kartenzugriff aufgetreten

[<=]

4.1.5.4.5 TUC_KON_022 „Liefere PIN-Status“

TIP1-A_4570 - TUC_KON_022 „Liefere PIN-Status“

Der Konnektor MUSS den technischen Use Case „Liefere PIN-Status“ gemäß TUC_KON_022 umsetzen.

Tabelle 73 TAB_KON_532 – TUC_KON_022 „Liefere PIN-Status“ 

Element	Beschreibung
Name	TUC_KON_022 „Liefere PIN-Status“
Beschreibung	Dieser Use Case prüft den Zustand eines PIN-Objekts einer Karte im Kontext einer CardSession.
Auslöser	Aufruf des Use Case im Rahmen von technischen Use Cases der Basisdienste des Konnektors                     Aufruf des Use Cases durch ein Fachmodul im Konnektor                     Aufruf der Operation GetPinStatus des CardService (siehe 4.1.5.5.1) durch das Clientsystem.
Vorbedingungen	Karte unterstützt die übergebene pinRef
Eingangsdaten	cardSession pinRef (Pin-Referenz der angefragten PIN, gemäß der Objektsystem-Spezifikation des jeweiligen Kartentyps)
Komponenten	Karte, Kartenterminal, Konnektor
Ausgangsdaten	pinStatus [PinStatus] leftTries – optional/verpflichtend, wenn pinStatus = VERIFYABLE (Anzahl der verbleibenden Versuche für die Verifikation der PIN)
Standardablauf	1.         Ermittle Card = CM_CARD_LIST(cardSession)  2.         Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der        Aufrufer das Karten-Lock besitzt.  3.         pinRef in CardSession.AUTHSTATE vorhanden:    a) Ja:    Setze pinStatus = VERIFIED oder DISABLED (wie in                 AUTHSTATE)    b) Nein:Aufruf der Kartenoperation „GET PIN STATUS“, Antwort der                 Karte wird ausgewertet:                 a.             ´90 00´ (NoError: Verifiziert ): pinStatus =                      VERIFYABLE  (da nicht in dieser CardSession verifiziert)                 b.             ´62 C1´: pinStatus = TRANSPORT_PIN                 c.             ´62 C7´: pinStatus = EMPTY_PIN (Leer-PIN)                 d.             ´63 Cx´: pinStatus = VERIFYABLE  (mit 1<= x <= 3);                     LeftTries=x                 e.             ´63 C0´: pinStatus = BLOCKED; leftTries=0                 f.              ´62 D0´: pinStatus = DISABLED (Verifikation nicht                     erforderlich, da PIN-Schutz ausgeschaltet);                     cardSession.AUTHSTATE aktualisieren                 g.              Antwortet die Karte mit einer Fehlermeldung, bricht                     der TUC ab. Liefere leftTries nur in den Fällen d und e zurück.
Varianten/ Alternativen
Fehlerfälle	* Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden,        Fehlercode 4094 (3b) pinRef nicht gefunden: Fehlercode 4072
Zugehörige Diagramme	keine

 

Tabelle 74: TAB_KON_091 Fehlercodes TUC_KON_022 „Liefere PIN-Status“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4072	Technical	Error	ungültige PIN-Referenz PinRef
4094	Technical	Error	Timeout beim Kartenzugriff aufgetreten

[<=]

4.1.5.4.6 TUC_KON_027 „PIN-Schutz ein-/ausschalten“

TIP1-A_5486 - TUC_KON_027 „PIN-Schutz ein-/ausschalten"

Der Konnektor MUSS den technischen Use Case TUC_KON_027 „PIN-Schutz ein-/ausschalten“ umsetzen.

Tabelle 75: TAB_KON_240 - TUC_KON_027 „PIN-Schutz ein-/ausschalten” 

Element	Beschreibung
Name	TUC_KON_027 „PIN-Schutz ein-/ausschalten”
Beschreibung	Schaltet das Erfordernis, die PIN zu verifizieren, ein bzw. aus. Diese Operation wird nur unterstützt für PINs der EGK G2 gemäß [gemSpec_eGK_ObjSys]; für sie können folgende Kommandos auf das Passwortobjekt angewendet werden:       DISABLE VERIFICATION REQUIREMENT       ENABLE VERIFICATION REQUIREMENT
Auslöser	Aufruf durch ein Fachmodul       Aufruf der Operationen EnablePin und DisablePin des CardService durch das Clientsystem.
Vorbedingungen	Karte unterstützt die übergebene pinRef
Eingangsdaten	cardSession (CardSession einer EGK G2)       pinRef (PIN-Referenz der ab-/anzuschaltenden PIN, gemäß der Objektsystem-Spezifikation des jeweiligen Kartentyps)       enable [Boolean] (enable = true:  Erfordernis der Benutzerverifikation einschalten; enable = false: Erfordernis der Benutzerverifikation abschalten)
Komponenten	Konnektor
Ausgangsdaten	pinResult [PinResult] (Ergebnis von PIN-Schutz ein-/ausschalten durch PIN-Eingabe)       leftTries – optional/verpflichtend nach fehlerhafter PIN (verbleibende Versuche)
Standardablauf	1. Ermittle Card = CM_CARD_LIST(cardSession)  2. Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der      Aufrufer im Besitz des Karten-Locks ist.  3. Prüfe Card.Type = EGK und Generation ≥ 2  4. Prüfe pinRef = MRPIN.AMTS und Card.Type = EGK                und Generation > 2.0  5. Wenn enable A: =true:         Atomare Operation: PIN bearbeiten inkl. Eventing und         Ergebnisvermerk          a.            Rufe TUC_KON_256 {                    topic = „CARD/PIN/ENABLE_STARTED“;                    eventType = Op;                    severity = Info;                    parameters = („CardHandle=$, CardType=$,                               ICCSN=$, CtID=$, SlotID=$, PinRef=$,                               PinInputCtID=$PinInputKT“);                    doLog = false }          b.            Aufruf des Kartenterminalkommandos „SICCT PERFORM              VERIFICATION“ mit der Kartenoperation „ENABLE              VERIFICATION REQUIREMENT” als Command-To-Perform. Es               ist der Parameter P1=’00’ (mit Benutzerverifikation) zu              verwenden. Die Anzeige am KT erfolgt entsprechend              TAB_KON_090 Terminalanzeigen beim Eingeben der PIN am               Kartenterminal. Ersetze in displayMessage „ANW“ entsprechend              ANW(pinRef) gemäß Tabelle TAB_KON_838.           c.           Setze pinResult in Abhängigkeit von Ergebnis Perform              Verification:                     -          pinResult = OK für erfolgreiche Änderung                     -          pinResult = ERROR für Nutzer-Abbruch oder                      Bearbeitungsfehler (siehe Fehlerfälle)                 -              pinResult = REJECTED für falsche PIN;                      leftTries = x (bei Kartenantwort ´63 Cx´, x > 0)                 -              pinResult = BLOCKED für gesperrte PIN (bei                      Kartenantwort ´63 C0´)          d.           Rufe TUC_KON_256 {                    topic =„CARD/PIN/ENABLE_FINISHED“;                    eventType = Op;                    severity = Info;                    parameters = („CardHandle=$, CardType=$,                            ICCSN=$, CtID=$, SlotID=$, PinRef=$,                            PinInputCtID=$PinInputKT”);                    doLog = false } B: =false:           Atomare Operation: PIN bearbeiten inkl. Eventing und          Ergebnisvermerk          a.             Rufe TUC_KON_256 {                    topic = „CARD/PIN/DISABLE_STARTED“;                    eventType = Op;                    severity = Info;                    parameters = („CardHandle=$, CardType=$,                            ICCSN=$, CtID=$, SlotID=$, PinRef=$,                            PinInputCtID=$PinInputKT“);                    doLog = false }          b.             Aufruf des Kartenterminalkommandos „SICCT PERFORM             VERIFICATION“ mit der Kartenoperation „DISABLE             VERIFICATION REQUIREMENT” als Command-To-Perform. Es             ist der Parameter P1=’00’ (mit Benutzerverifikation) zu             verwenden. Die Anzeige am KT erfolgt entsprechend             TAB_KON_090 Terminalanzeigen beim Eingeben der PIN am             Kartenterminal. Ersetze in displayMessage „ANW“ entsprechend             ANW(pinRef) gemäß Tabelle TAB_KON_838.          c.             Setze pinResult in Abhängigkeit von Ergebnis Perform               Verification:                      -             pinResult = OK für erfolgreiche Änderung                      -             pinResult = ERROR für Nutzer-Abbruch oder                        Bearbeitungsfehler (siehe Fehlerfälle)                 -                  pinResult = REJECTED für falsche PIN;                        leftTries = x (bei Kartenantwort ´63 Cx´, x > 0)                 -                  pinResult = BLOCKED für gesperrte PIN          d.            Rufe TUC_KON_256 {                topic = „CARD/PIN/DISABLE_FINISHED“;                eventType = Op;                severity = Info;                parameters = („CardHandle=$, CardType=$,                       ICCSN=$;CtID=$, SlotID=$, PinRef=$,                       PinInputCtID=$PinInputKT”);                         doLog=false} 6. Liefere pinResult und leftTries zurück
Varianten/ Alternativen	(->3) zur Optimierung kann vor Schritt 5 der PIN-Schutz geprüft werden:  a.         pinStatus=TUC_KON_022 „Liefere PIN-Status“ { cardSession;        pinRef }  b.         Wenn pinStatus<>DISABLED und enable=true, dann         pinResult=OK und -> weiter in Schritt 6  c.         Wenn pinStatus=DISABLED und enable=false, dann        pinResult=OK und -> weiter in Schritt 6
Fehlerfälle	(2) Karte ist fremd reserviert: Fehlercode 4093 (3) Karte ist keine eGK der Generation 2 oder höher: Fehlercode 4209 (4) PIN nicht gefunden; Karte ist eGK G2.0: Die Operation „PIN-Schutz ein-/ausschalten“ wird für MRPIN.AMTS nicht unterstützt: Fehlercode 4072 (5) Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden: Fehlercode 4094 (5) PIN nicht gefunden: Fehlercode 4072 (5) PIN gesperrt: Fehlercode 4063 (5) Zugriffsbedingung nicht erfüllt (PIN nicht abschaltbar): Fehlercode 4085
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	keine

Tabelle 76: TAB_KON_838 Mapping von pinRef auf ANW 

Hinweis zu TAB_KON_838: Leerzeichen werden als "•" dargestellt.

Tabelle 77: TAB_KON_241 Fehlercodes TUC_KON_027 „PIN-Schutz ein/ausschalten“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4063	Security	Error	PIN bereits blockiert (BLOCKED)
4072	Technical	Error	ungültige PIN-Referenz PinRef
4085	Security	Error	Zugriffsbedingung nicht erfüllt
4093	Technical	Error	Karte wird in einer anderen Kartensitzung exklusiv verwendet
4094	Technical	Error	Timeout beim Kartenzugriff aufgetreten
4209	Technical	Error	Kartentyp %CardType% wird durch diese Operation nicht unterstützt.

[<=]

4.1.5.4.7 TUC_KON_023 „Karte reservieren“

TIP1-A_4571 - TUC_KON_023 „Karte reservieren“

Der Konnektor MUSS den technischen Use Case „Karte reservieren“ gemäß TUC_KON_023 umsetzen.
 

Tabelle 78: TAB_KON_533 - TUC_KON_023 „Karte reservieren” 

Element	Beschreibung
Name	TUC_KON_023 „Karte reservieren” Dem Aufrufer des TUC_KON_023 wird beim Reservieren (DoLock=Ja) der Karte zur ausschließlichen Nutzung ein Lock zugeordnet. Wird der TUC-KON_023 mit diesem Lock zum Freigeben der Reservierung (DoLock=Nein) aufgerufen, dann erlischt das Lock und die ausschließliche Nutzung wird beendet. Der Scope der Kartenreservierung wird vom Aufrufer des TUC_KON_023 gesteuert. Das Lock ist Konnektor-intern. Es darf nicht außerhalb des Konnektors referenzierbar sein. Zwei verschiedene Operationsaufrufe am Konnektor dürfen nie ein identisches Lock haben. Der Konnektor MUSS sicherstellen, dass auch im Fehlerfall die Reservierung zu einem Lock aufgehoben wird. Ein Lock darf nicht dauerhaft bestehen.
Beschreibung	Reservierung der Karte
Auslöser	Aufruf des Use Case im Rahmen von technischen Use Cases der Basisdienste des Konnektors Aufruf des Use Cases durch ein Fachmodul im Konnektor
Vorbedingungen	Keine
Eingangsdaten	cardSession doLock [Boolean] (Zielzustand der Karte; true = reserviert, false = freigegeben)
Komponenten	Konnektor
Ausgangsdaten	Keine
Standardablauf	1. Ermittle Card = CM_CARD_LIST(cardSession)  2. Wenn doLock A: = true:        i.            Prüfe, dass der zur cardSession gehörenden Karte kein            Lock zugeordnet ist        ii.           Dem Aufrufer wird ein Lock auf die zur cardSession            gehörende Karte zugeordnet. Es wird nicht explizit als            Ausgangsdatum modelliert, sondern der Aufrufer hat das Lock            durch die Zuordnung, muss es aber nicht verwalten. B: = false:        i.            Prüfe, dass der Aufrufer für die zur cardSession gehörende            Karte ein Lock hat.        ii.           Das der Karte zugeordnete Lock wird gelöscht.
Varianten/ Alternativen	Keine
Fehlerfälle	(2Ai) Karte bereits reserviert, Fehlercode 4093 (2Bi) Karte nicht durch Aufrufer reserviert, Fehlercode 4001
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	Keine

 

Tabelle 79: TAB_KON_534 Fehlercodes TUC_KON_023 „Karte reservieren“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4001	Technical	Error	interner Fehler
4093	Technical	Error	Karte bereits reserviert

[<=]

4.1.5.4.8 TUC_KON_005 „Card-to-Card authentisieren“

Die C2C-Authentisierung erfolgt konform zu den in [gemSpec_COS#15] festgelegten Authentisierungsprotokollen.

Definition Quellkarte/Zielkarte:

Bei einseitiger Card-to-Card-Authentisierung ohne Aushandlung eines Session Key ist die Quellkarte diejenige, die die Rolle des Karteninhabers bzw. der Organisation gemäß [gemSpec_PKI_TI#Tab_PKI_254] gegenüber der anderen Karte nachweist, z. B. der HBA bei der Freischaltung einer eGK.

Bei gegenseitiger Card-to-Card-Authentisierung ohne Aushandlung eines Session Key erfolgen nach einander zwei einseitige Card-to-Card-Authentisierungen mit vertauschten Rollen. Quell- und Zielkarte habe daher für den Gesamtablauf keine nähere Bedeutung.

Bei Card-to-Card-Authentisierung mit Aushandlung eines Session Key ist die Quellkarte diejenige, die die SM-APDUs produzieren kann, also die SMC (-KT oder -K).

Die Zielkarte ist jeweils die Karte, die nicht die Quellkarte ist.

TIP1-A_4572 - TUC_KON_005 „Card-to-Card authentisieren“

Der Konnektor MUSS den technischen Use Case „Card-to-Card authentisieren“ gemäß TUC_KON_005 umsetzen.
Die Card-to-Card-Authentisierung zwischen zwei Karten, bei der eine Karte der Generation 1+ angehört MUSS das RSA-Verfahren verwenden.
Die Card-to-Card-Authentisierung zwischen zwei Karten der Generation 2 MUSS das Verfahren der elliptischen Kurven verwenden.

 

Tabelle 80: TAB_KON_096 – TUC_KON_005 „Card-to-Card authentisieren” 

Element	Beschreibung
Name	TUC_KON_005 „Card-to-Card authentisieren“
Beschreibung	Durchführung einer Card-to-Card-Authentisierung
Auslöser	Aufruf des Use Case im Rahmen von technischen Use Cases der Basisdienste des Konnektors Aufruf des Use Cases durch ein Fachmodul im Konnektor
Vorbedingungen	Wert von Source_CARDSESSION.AUTHSTATE: wenn Quellkarte a) ein HBA ist: CHV; PIN.CH, verifiziert b) eine SMC-B ist: CHV; PIN.SMC verifiziert
Eingangsdaten	sourceCardSession (Quellkarte) targetCardSession (Zielkarte) authMode (gemäß Tabelle TAB_KON_673)
Komponenten	Karten, Konnektor, Kartenterminal
Ausgangsdaten	Keine
Standardablauf	Ermittle sCard = CM_CARD_LIST(sourceCardSession)     Ermittle tCard = CM_CARD_LIST(targetCardSession)     Prüfe, dass der Quellkarte entweder kein Lock zugeordnet ist oder der Aufrufer im Besitz auf das Lock der Quellkarte ist. Prüfe, dass der Zielkarte entweder kein Lock zugeordnet ist oder der Aufrufer im Besitz auf das Lock der Zielkarte ist.     Prüfe Aufrufparameter auf erlaubte Kombination gemäß Tabelle TAB_KON_674     Wenn das zu verwendende CV-Zertifikat der Quellkarte ein CV-Zertifikat der Generation 2 oder höher ist, dann prüfe sein  Ausstellungsdatum (CED) gegen die aktuelle Zeit     Wenn Card.TYP=eGK UND Card.Version=Generation1+, dann prüfe, ob aktuelles System-Datum < 01.01.2019 ist     Wähle Key-Referenzen gemäß Tabelle TAB_KON_674     Prüfe pinRef/keyRef in sCard.CARDSESSION.AUTHSTATE und tCard.CARDSESSION.AUTHSTATE für adressierte Schlüssel wie in Zugriffsbedingung der Karten definiert vorhanden     Durchführung der Authentisierung gemäß Tabelle TAB_KON_673 mit Key-Referenzen gemäß Tabelle TAB_KON_674     Ergänze targetCardSession.AUTHSTATE mit tKeyRef und Rolle aus sKeyRef (CHA bzw. CHAT aus dem EndEntity-CV-Zertifikat der Quellkarte)
Varianten/ Alternativen	(9) Wenn der für die CA-Zertifikatsprüfung zu selektierende CVC-Root-Key auf der Zielkarte nicht vorhanden ist (Returncode des Kartenkommandos „MANAGE SECURITY ENVIRONMENT“ ist ’6A 88’), dann muss der Konnektor:  a)      das oder die passenden Cross-CV-Zertifikate aus dem Truststore     auswählen  b)      mit dem Kartenkommando „PSO Verify Certificate“ jedes     ausgewählte Cross-CV-Zertifikat durch die Zielkarte prüfen lassen.      Dadurch wird der im Cross-CV-Zertifikat enthaltene öffentliche      Schlüssel an die Zielkarte übertragen. Die Zielkarte speichert den     darin enthaltenen neuen CVC-Root-Key.  c)      den neuen CVC-Root-Key auf der Zielkarte selektieren  d)      den Standardablauf der C2C-Authentisierung fortsetzen (9) Wenn tCard.TYPE=EGK und AuthMode=gegenseitig,       dann Echtheitsprüfung der eGK durch den Konnektor:  a)      Freischaltung der EGK durch den HBA/die SMC-B:      Durchführen der Authentisierung gemäß Tabelle TAB_KON_673 mit Key-Referenzen gemäß Tabelle TAB_KON_674 aber mit AuthMode=einseitig  b)      Konnektor liest das CA-Zertifikat EF.C.CA_eGK.CS (G1+) bzw.      C.CA_eGK.CS.E256 (G2)  c)      Konnektor liest das End-Entity-Zertifikat der EGK     EF.C.eGK.AUT_CVC (G1+) bzw. EF.C.eGK.AUT_CVC.E256 (G2)  d)      Konnektor prüft das CVC-EE-Zertifikat mit TUC_KON_042 „CV-     Zertifikat prüfen“ {          certificate = C.eGK.AUT_CVC/C.eGK.AUT_CVC.E256;          caCertificate  = C.CA_eGK.CS/C.CA_eGK.CS.E256 }  e)      Konnektor erzeugt Zufallszahl  f)       Konnektor selektiert den PrK.eGK.AUT_CVC (G1+) bzw.   PrK.eGK.AUT_CVC.E256 (G2) und stellt abhängig von der Version    der eGK den Algorithmus auf der eGK ein (MSE Set)  g)      Konnektor sendet Konkatenation aus Zufallszahl und    CARD.ICCSN mit dem Befehl „INTERNAL AUTHENTICATE“ an die    eGK  h)      Konnektor wertet das von der Karte erhaltene Chiffrat aus
Fehlerfälle	* Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094 (3) Eine Karte ist fremd reserviert, Fehlercode 4093 (5) Zertifikat der Quellkarte fehlerhaft. Ausstellungsdatum liegt in der Zukunft; Fehlercode 4233 (6) eGK G1+ ausgealtert, Fehlercode 4192 (8) Nötige PIN, bzw. KeyRef ist nicht verifiziert, Fehlercode 4085 (9) Je nachdem, welche Karte den Fehler verursachte, wird zum ursprünglichen Fehler (Fehlercode gemäß [gemSpec_COS]) im Error-Trace (welcher an erster Stelle im Falle des HBA z. B. bereits ein Fehler bezüglich PIN-Verifikation enthalten kann) noch ein weiterer mit Code 4056 oder 4057 hinzugefügt. Kann der Fehler nicht eindeutig einer der beiden Karten zugeordnet so wird Error-Code 4048 verwendet.
Nichtfunktionale Anforderungen	keine
Zugehörige Diagramme	Keine

 

Tabelle 81: TAB_KON_673 AuthMode für C2C 

AuthMode	Definition des Ablaufs
einseitig	Externe oder Interne Authentisierung ([gemSpec_COS#15.1] oder [gemSpec_COS#15.2], passend zu den Zugriffsregeln der beteiligten CVC)
gegenseitig	Card-2-Card-Authentisierung ohne Sessionkey-Aushandlung ([gemSpec_COS#15.3])
gegenseitig+TC	Card-2-Card-Authentisierung mit Sessionkey-Aushandlung zur Etablierung eines Trusted Channels ([gemSpec_COS#15.4])

 

Tabelle 82: TAB_KON_674 Erlaubte Parameterkombinationen und resultierende CV-Zertifikate für C2C 

Quellkarte	Zielkarte	AuthMode	sKeyRef	tKeyRef	Fachlicher UseCase
HBA oder SM-B	eGK G1+	einseitig	{HPC.AUTR_ CVC.R2048 | SMC.AUTR_ CVC.R2048}		Freischaltung eGK
HBA oder SM-B	eGK G1+	gegen seitig	{HPC.AUTR_ CVC.R2048 | SMC.AUTR_ CVC.R2048}	eGK.AUT_ CVC.R2048	Freischaltung eGK mit Echtheits prüfung eGK
HBA oder SM-B	eGK G2	einseitig	{HPC.AUTR_ CVC.E256 | SMC.AUTR_ CVC.E256}		Freischaltung eGK
HBA oder SM-B	eGK G2	gegen seitig	{HPC.AUTR_ CVC.E256 | SMC.AUTR_ CVC.E256}	eGK.AUT_ CVC.E256	Freischaltung eGK mit Echtheits prüfung eGK
SMC-K	HBA	gegen seitig+TC	SAK.AUTD_ CVC.E256	HPC.AUTD_ SUK_CVC.E256	DTBS- Übertragung bei QES
SMC-KT	HBA	gegen seitig+TC	SMC.AUTD_ RPS_CVC.E256	HPC.AUTD_ SUK_CVC.E256	Remote-PIN
SMC-KT	SM-B	gegen seitig+TC	SMC.AUTD_ RPS_CVC.E256	SMC.AUTD_ RPE_CVC.E256	Remote-PIN

 

Tabelle 83: TAB_KON_535 Fehlercodes TUC_KON_005 „Card-to-Card authentisieren“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4048	Technical	Error	Fehler bei der C2C-Authentisierung
4056	Technical	Error	Fehler bei der C2C-Authentisierung, Quellkarte
4057	Technical	Error	Fehler bei der C2C-Authentisierung, Zielkarte
4085	Security	Error	Zugriffsbedingungen nicht erfüllt
4093	Technical	Error	Karte wird in einer anderen Kartensitzung exklusiv verwendet
4094	Technical	Error	Timeout beim Kartenzugriff aufgetreten
4192	Security	Error	C2C mit eGK G1+ ab 01.01.2019  nicht mehr gestattet
4233	Security	Error	Ausstellungsdatum des Zertifikats liegt in der Zukunft;

[<=]

4.1.5.4.9 TUC_KON_202 „LeseDatei“

TIP1-A_4573 - TUC_KON_202 „LeseDatei”

Der Konnektor MUSS den technischen Use Case „LeseDatei“ gemäß TUC_KON_202 umsetzen.
 

Tabelle 84: TAB_KON_218 – TUC_KON_202 „LeseDatei“ 

Element	Beschreibung
Name	TUC_KON_202 „LeseDatei“
Beschreibung	Transparente Datei oder Teile davon lesen
Auslöser	Aufruf des Use Case im Rahmen von technischen Use Cases der Basisdienste des Konnektors                     Aufruf des Use Cases durch ein Fachmodul im Konnektor
Vorbedingungen	Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen
Eingangsdaten	cardSession fileIdentifier – optional/verpflichtend, wenn kein sfid angegeben ist (FID der zu lesenden Datei) sfid– optional/verpflichtend, wenn kein fileIdentifier angegeben ist (Short File Identifier der zu lesenden Datei) folder (Verzeichnis/Applikation auf der Karte, in dem sich die Datei befindet) offset – optional/nur verwendbar, wenn fileIdentifier angegeben ist (Startposition innerhalb der Datei) length – optional (Längenangabe, um den Zugriff auf Teile einer Datei einzuschränken)
Komponenten	Karte, Kartenterminal, Konnektor
Ausgangsdaten	content (Gelesene Daten)
Standardablauf	Ermittle Card = CM_CARD_LIST(cardSession) Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt. Prüfe PinRef/KeyRef in CARDSESSION.AUTHSTATE für adressierte Datei wie in Zugriffsbedingung der Karte definiert vorhanden Selektiere Verzeichnis und Datei Lies Daten über Kartenkommando „READ BINARY“ unter Berücksichtigung von Offset- und Längenangaben Die gelesenen Daten werden an den Aufrufer zurückgegeben
Varianten/ Alternativen	Wenn Card.TYPE = KVK, sendet der Konnektor in diesem Fall ein "Read Binary" im Sinne von SICCT 1.2.1, 5.5.8.1 "Kommandos für synchrone Chipkarten".
Fehlerfälle	* Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094 (2) Karte ist fremd reserviert, Fehlercode 4093 (3) Nötige PIN ist nicht verifiziert, Fehlercode 4085 (5) Verzeichnis deaktiviert, Fehlercode 4086 (4-5) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	Keine

Tabelle 85: TAB_KON_536 Fehlercodes TUC_KON_202 „LeseDatei“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4085	Security	Error	Zugriffsbedingungen nicht erfüllt
4086	Technical	Error	Verzeichnis deaktiviert
4093	Technical	Error	Karte wird in einer anderen Kartensitzung exklusiv verwendet
4094	Technical	Error	Timeout beim Kartenzugriff aufgetreten

[<=]

4.1.5.4.10 TUC_KON_203 „SchreibeDatei“

TIP1-A_4574 - TUC_KON_203 „SchreibeDatei„

Der Konnektor MUSS den technischen Use Case „SchreibeDatei“ gemäß TUC_KON_203 umsetzen.
 

Tabelle 86: TAB_KON_219 – TUC_KON_203 „SchreibeDatei“ 

Element	Beschreibung
Name	TUC_KON_203 „SchreibeDatei“
Beschreibung	Daten in transparente Datei schreiben
Auslöser	Aufruf durch Fachmodul
Vorbedingungen	Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen.
Eingangsdaten	cardSession fileIdentifier – optional/verpflichtend, wenn kein sfid angegeben ist (FID der zu lesenden Datei) sfid– optional/verpflichtend, wenn kein fileIdentifier angegeben ist (Short File Identifier der zu lesenden Datei) folder (Verzeichnis/Applikation auf der Karte, in dem sich die Datei befindet) offset– optional (Startposition innerhalb der Datei, default: 0)   length – optional (Längenangabe, um den Zugriff auf Teile einer Datei einzuschränken; default: alles ab offset) dataToBeWritten (Zu schreibende Daten)
Komponenten	Karte, Kartenterminal, Konnektor
Ausgangsdaten	Keine
Standardablauf	Ermittle Card = CM_CARD_LIST(cardSession)      Prüfe Card.TYPE <> KVK      Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.      Prüfe PinRef/KeyRef in CARDSESSION.AUTHSTATE für adressierte Datei wie in Zugriffsbedingung der Karte definiert vorhanden      Selektiere Verzeichnis      Selektiere Datei mittels SELECT mit P2=‘04‘ (Selektieren einer Datei, Antwortdaten mit FCP)      Ermittle size (Größe der selektierten Datei in Byte) mit size = numberOfOctet aus FCP      Wenn size – offset  >= Größe von dataToBeWritten in Byte, dann schreibe dataToBeWritten mittels Kartenkommando “UPDATE BINARY“ unter Berücksichtigung von Offset- und Längenangaben
Varianten/ Alternativen	keine
Fehlerfälle	* Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094 (2) Schreibzugriff auf KVK nicht gestattet, Fehlercode 4085 (3) Karte ist fremd reserviert, Fehlercode 4093 (4) Nötige PIN ist nicht verifiziert, Fehlercode 4085 (5) Verzeichnis oder Datei existiert nicht, Fehlercode 4087 (4-5) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]> (6) Ausgewählte Datei ist nicht transparent, Fehlercode 4089 (6) Verzeichnis deaktiviert, Fehlercode 4086 (8) dataToBeWritten sind größer als der zur Verfügung stehende Speicherplatz, Fehlercode 4247
Nichtfunktionale Anforderungen	keine
Zugehörige Diagramme	keine

Tabelle 87: TAB_KON_537 Fehlercodes TUC_KON_203 „Schreibe Datei“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4085	Security	Error	Zugriffsbedingungen nicht erfüllt
4086	Technical	Error	Verzeichnis deaktiviert
4087	Technical	Error	Datei nicht vorhanden
4089	Technical	Error	Datei ist vom falschen Typ
4093	Technical	Error	Karte wird in einer anderen Kartensitzung exklusiv verwendet
4094	Technical	Error	Timeout beim Kartenzugriff aufgetreten
4247	Technical	Error	Speicherplatz auf der Karte nicht ausreichend

[<=]

4.1.5.4.11 TUC_KON_204 „LöscheDateiInhalt“

TIP1-A_5476 - TUC_KON_204 „LöscheDateiInhalt”

Der Konnektor MUSS den technischen Use Case „LöscheDateiInhalt“ gemäß TUC_KON_204 umsetzen.
 

Tabelle 88: TAB_KON_204 – TUC_KON_204 „LöscheDateiInhalt“ 

Element	Beschreibung
Name	TUC_KON_204 „LöscheDateiInhalt“
Beschreibung	Inhalt einer transparenten Datei löschen
Auslöser	Aufruf des Use Cases durch ein Fachmodul im Konnektor
Vorbedingungen	Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen
Eingangsdaten	cardSession fileIdentifier – optional/verpflichtend, wenn kein sfid angegeben ist (FID der zu bearbeitenden Datei) sfid– optional/verpflichtend, wenn kein fileIdentifier angegeben ist (Short File Identifier der zu bearbeitenden Datei) folder (Verzeichnis/Applikation auf der Karte, in dem sich die Datei befindet) offset – optional (Position, ab der der Inhalt gelöscht werden soll. Default: 0)
Komponenten	Karte, Kartenterminal, Konnektor
Ausgangsdaten	keine
Standardablauf	Ermittle Card = CM_CARD_LIST(cardSession)      Prüfe Card.TYPE <> KVK      Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer im Besitz des Karten-Locks ist.      Prüfe PinRef/KeyRef in CARDSESSION.AUTHSTATE für adressierte Datei wie in Zugriffsbedingung der Karte definiert vorhanden      Selektiere Verzeichnis und Datei      Lösche Inhalt der selektierten Datei über Kartenkommando „ERASE BINARY“, ggf. ab angegebenem Offset, sonst ab Anfang
Varianten/ Alternativen	keine
Fehlerfälle	* Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094 (2) Karte ist keine eGK der Generation 2 oder höher: Fehlercode 4209 (3) Karte ist fremd reserviert, Fehlercode 4093 (4) Nötige PIN ist nicht verifiziert, Fehlercode 4085 (5) Verzeichnis oder Datei existiert nicht, Fehlercode 4087 (6) Ausgewählte Datei ist nicht transparent, Fehlercode 4089 (6) Verzeichnis deaktiviert, Fehlercode 4086 (5-6) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	Keine

Tabelle 89: TAB_KON_785 Fehlercodes TUC_KON_204 „LöscheDateiInhalt“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4085	Security	Error	Zugriffsbedingungen nicht erfüllt
4086	Technical	Error	Verzeichnis deaktiviert
4087	Technical	Error	Datei nicht vorhanden
4089	Technical	Error	Datei ist vom falschen Typ
4093	Technical	Error	Karte wird in einer anderen Kartensitzung exklusiv verwendet
4094	Technical	Error	Timeout beim Kartenzugriff aufgetreten
4209	Technical	Error	Kartentyp %CardType% wird durch diese Operation nicht unterstützt.

[<=]

4.1.5.4.12 TUC_KON_209 „LeseRecord“

TIP1-A_4575 - TUC_KON_209 „LeseRecord”

Der Konnektor MUSS den technischen Use Case „LeseRecord“ gemäß TUC_KON_209 umsetzen.
 

Tabelle 90: TAB_KON_538 – TUC_KON_209 „LeseRecord“ 

Element	Beschreibung
Name	TUC_KON_209 „LeseRecord"
Beschreibung	Daten aus strukturierter Datei lesen
Auslöser	Aufruf durch Fachmodul
Vorbedingungen	Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen
Eingangsdaten	cardSession fileIdentifier – optional/verpflichtend, wenn kein sfid angegeben ist (FID der zu lesenden Datei) sfid– optional/verpflichtend, wenn kein fileIdentifier angegeben ist (Short File Identifier der zu lesenden Datei) folder (Verzeichnis/Applikation auf der Karte, in dem sich die Datei befindet) recordNumber
Komponenten	Karte, Kartenterminal, Konnektor
Ausgangsdaten	content (Inhalt des Records)
Standardablauf	Ermittle Card = CM_CARD_LIST(cardSession) Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt Prüfe PinRef/KeyRef in CARDSESSION.AUTHSTATE für adressierte Datei wie in Zugriffsbedingung der Karte definiert vorhanden Selektiere Verzeichnis und ggf. Datei Lies Daten über Kartenkommando „READ RECORD“ unter Berücksichtigung von recordNumber Rückgabe der Daten an den Aufrufer
Varianten/ Alternativen	keine
Fehlerfälle	* Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094 (2) Karte ist fremd reserviert, Fehlercode 4093 (3) Nötige PIN ist nicht verifiziert, Fehlercode 4085 (4) Verzeichnis oder Datei oder Record existiert nicht, Fehlercode 4087 (5) Wenn Karte WrongFileType liefert, Fehlercode 4089 (5) Verzeichnis deaktiviert, Fehlercode 4086 (4-5) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>.
Nichtfunktionale Anforderungen	keine
Zugehörige Diagramme	keine

Tabelle 91: TAB_KON_539 Fehlercodes TUC_KON_209 „LeseRecord“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4085	Security	Error	Zugriffsbedingungen nicht erfüllt
4086	Technical	Error	Verzeichnis deaktiviert
4087	Technical	Error	Datei nicht vorhanden
4089	Technical	Error	Datei ist vom falschen Typ
4093	Technical	Error	Karte wird in einer anderen Kartensitzung exklusiv verwendet
4094	Technical	Error	Timeout beim Kartenzugriff aufgetreten

[<=]

4.1.5.4.13 TUC_KON_210 „SchreibeRecord“

TIP1-A_4576 - TUC_KON_210 „SchreibeRecord“

Der Konnektor MUSS den technischen Use Case „SchreibeRecord“ gemäß TUC_KON_210 umsetzen.
 

Tabelle 92: TAB_KON_224 – TUC_KON_210 „SchreibeRecord“ 

Element	Beschreibung
Name	TUC_KON_210 „SchreibeRecord"
Beschreibung	Daten in lineare Datei schreiben
Auslöser	Aufruf durch Fachmodul
Vorbedingungen	Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen
Eingangsdaten	cardSession fileIdentifier – optional/verpflichtend, wenn kein sfid angegeben ist (FID der zu bearbeitenden Datei) sfid– optional/verpflichtend, wenn kein fileIdentifier angegeben ist (Short File Identifier der zu bearbeitenden Datei) folder (Verzeichnis/Applikation auf der Karte, in dem sich die Datei befindet) recordNumber dataToBeWritten (Zu schreibende Daten)
Komponenten	Karte, Kartenterminal, Konnektor
Ausgangsdaten	keine
Standardablauf	Ermittle Card = CM_CARD_LIST(cardSession) Prüfe Card.TYPE <> KVK Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt. Prüfe PinRef/KeyRef in CARDSESSION.AUTHSTATE für adressierte Datei wie in Zugriffsbedingung der Karte definiert vorhanden Selektiere Verzeichnis und ggf. Datei Schreibe Daten über Kartenkommando „UPDATE RECORD“ unter Berücksichtigung von recordNummer
Varianten/ Alternativen	keine
Fehlerfälle	* Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094 (2) Schreibzugriff auf KVK nicht gestattet, Fehlercode 4085 (3) Karte ist fremd reserviert, Fehlercode 4093 (4) Nötige PIN ist nicht verifiziert, Fehlercode 4085 (5) Verzeichnis, Datei existiert nicht, Fehlercode 4087 (5-6) Verzeichnis deaktiviert, Fehlercode 4086 (4-6) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
Nichtfunktionale Anforderungen	keine
Zugehörige Diagramme	keine

Tabelle 93: TAB_KON_540 Fehlercodes TUC_KON_210 „SchreibeRecord“ 

[<=]

4.1.5.4.14 TUC_KON_211 „LöscheRecordInhalt“

TIP1-A_5477 - TUC_KON_211 „LöscheRecordInhalt“

Der Konnektor MUSS den technischen Use Case „LöscheRecordInhalt“ gemäß TUC_KON_211 umsetzen.
 

Tabelle 94: TAB_KON_211 – TUC_KON_211 „LöscheRecordInhalt“ 

Element	Beschreibung
Name	TUC_KON_211 „LöscheRecordInhalt“
Beschreibung	Inhalt eines Records einer strukturierten Datei löschen
Auslöser	Aufruf des Use Case im Rahmen von technischen Use Cases der Basisdienste des Konnektors                       Aufruf des Use Cases durch ein Fachmodul im Konnektor
Vorbedingungen	Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen
Eingangsdaten	cardSession fileIdentifier – optional/verpflichtend, wenn kein sfid angegeben ist (FID der zu bearbeitenden Datei) sfid– optional/verpflichtend, wenn kein fileIdentifier angegeben ist (Short File Identifier der zu bearbeitenden Datei) folder (Verzeichnis/Applikation auf der Karte, in dem sich die Datei befindet) recordNumber
Komponenten	Karte, Kartenterminal, Konnektor
Ausgangsdaten	keine
Standardablauf	Ermittle Card = CM_CARD_LIST(cardSession) Prüfe Card.TYPE <> KVK Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer im Besitz des Karten-Locks  ist. Prüfe PinRef/KeyRef in CARDSESSION.AUTHSTATE für adressierte Datei wie in Zugriffsbedingung der Karte definiert vorhanden Selektiere Verzeichnis und Datei Lösche Recordinhalt (identifiziert durch recordNumber) der selektierten Datei über Kartenkommando „ ERASE RECORD“
Varianten/ Alternativen	keine
Fehlerfälle	* Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094 (2) Karte ist keine eGK der Generation 2 oder höher: Fehlercode 4209 (3) Karte ist fremd reserviert, Fehlercode 4093 (4) Nötige PIN ist nicht verifiziert, Fehlercode 4085 (5) Verzeichnis, Datei oder Record existiert nicht, Fehlercode 4087 (6) Verzeichnis deaktiviert, Fehlercode 4086 (6) Record nicht vorhanden, Fehlercode 4091 (5-6) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	Keine

Tabelle 95: TAB_KON_786 Fehlercodes TUC_KON_211 „LöscheRecordInhalt“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4085	Security	Error	Zugriffsbedingungen nicht erfüllt
4086	Technical	Error	Verzeichnis deaktiviert
4087	Technical	Error	Datei nicht vorhanden
4091	Technical	Error	Record nicht vorhanden
4093	Technical	Error	Karte wird in einer anderen Kartensitzung exklusiv verwendet
4094	Technical	Error	Timeout beim Kartenzugriff aufgetreten
4209	Technical	Error	Kartentyp %CardType% wird durch diese Operation nicht unterstützt.

[<=]

4.1.5.4.15 TUC_KON_214 „FügeHinzuRecord“

TIP1-A_4577 - TUC_KON_214 „FügeHinzuRecord”

Der Konnektor MUSS den technischen Use Case „FügeHinzuRecord“ gemäß TUC_KON_214 umsetzen.
 

Tabelle 96: TAB_KON_228 – TUC_KON_214 „FügeHinzuRecord“ 

Element	Beschreibung
Name	TUC_KON_214 „FuegeHinzuRecord"
Beschreibung	Daten in lineare Datei anfügen
Auslöser	Aufruf durch Fachmodul                     TUC_KON_006
Vorbedingungen	Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen
Eingangsdaten	cardSession fileIdentifier – optional/verpflichtend, wenn kein sfid angegeben ist (FID der zu bearbeitenden Datei) sfid– optional/verpflichtend, wenn kein fileIdentifier angegeben ist (Short File Identifier der zu bearbeitenden Datei) folder (Verzeichnis/Applikation auf der Karte, in dem sich die Datei befindet) dataToBeWritten (Zu schreibende Daten)
Komponenten	Karte, Kartenterminal, Konnektor
Ausgangsdaten	keine
Standardablauf	Ermittle Card = CM_CARD_LIST(cardSession)      Prüfe Card.TYPE <> KVK      Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.      Prüfe PinRef/KeyRef in CARDSESSION.AUTHSTATE für adressierte Datei wie in Zugriffsbedingung der Karte definiert vorhanden      Selektiere Verzeichnis und ggf. Datei      Schreibe Daten über Kartenkommando „APPEND RECORD“
Varianten/ Alternativen	keine
Fehlerfälle	* Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094 (2) Schreibzugriff auf KVK nicht gestattet, Fehlercode 4085 (3) Karte ist fremd reserviert, Fehlercode 4093 (4) Nötige PIN ist nicht verifiziert, Fehlercode 4085 (5-6) Verzeichnis, Datei existiert nicht, Fehlercode 4087 (6) Verzeichnis deaktiviert, Fehlercode 4086 (5-6) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
Nichtfunktionale Anforderungen	keine
Zugehörige Diagramme	keine

Tabelle 97: TAB_KON_541 Fehlercodes TUC_KON_214 „FügeHinzuRecord“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4085	Security	Error	Zugriffsbedingungen nicht erfüllt
4086	Technical	Error	Verzeichnis deaktiviert
4087	Technical	Error	Datei nicht vorhanden
4093	Technical	Error	Karte wird in einer anderen Kartensitzung exklusiv verwendet
4094	Technical	Error	Timeout beim Kartenzugriff aufgetreten

[<=]

4.1.5.4.16 TUC_KON_215 „SucheRecord“

TIP1-A_4578 - TUC_KON_215 „SucheRecord“

Der Konnektor MUSS den technischen Use Case „SucheRecord“ gemäß TUC_KON_215 umsetzen.
 

Tabelle 98: TAB_KON_229 – TUC_KON_215 „SucheRecord“ 

Element	Beschreibung
Name	TUC_KON_215 „SucheRecord"
Beschreibung	Daten in linearer Datei suchen
Auslöser	Aufruf durch Fachmodul
Vorbedingungen	Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen
Eingangsdaten	cardSession fileIdentifier – optional/verpflichtend, wenn kein sfid angegeben ist (FID der zu bearbeitenden Datei) sfid– optional/verpflichtend, wenn kein fileIdentifier angegeben ist (Short File Identifier der zu bearbeitenden Datei) folder (Verzeichnis/Applikation auf der Karte, in dem sich die Datei befindet) pattern (SuchMuster) recordNumber – optional; default = 1 (Recordnummer, bei der Suche beginnen soll) ()
Komponenten	Karte, Kartenterminal, Konnektor
Ausgangsdaten	numbersFound (Liste: Nummern der Records, die dem SuchMuster entsprechen)
Standardablauf	Ermittle Card = CM_CARD_LIST(cardSession)      Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.      Prüfe PinRef/KeyRef in CARDSESSION.AUTHSTATE für adressierte Datei wie in Zugriffsbedingung der Karte definiert vorhanden      Selektiere Verzeichnis und ggf. Datei      Sende Kartenkommando „SEARCH RECORD“ mit SuchMuster pattern unter Berücksichtigung von recordNumber      Liefere Antwort der Karte zurück
Varianten/ Alternativen	Keine
Fehlerfälle	* Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD-Sekunden, Fehlercode 4094 (2) Karte ist fremd reserviert, Fehlercode 4093 (3) Nötige PIN ist nicht verifiziert, Fehlercode 4085 (4-5) Verzeichnis, Datei existiert nicht, Fehlercode 4087 (5) Verzeichnis deaktiviert, Fehlercode 4086 (4-5) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
Nichtfunktionale Anforderungen	keine
Zugehörige Diagramme	keine

Tabelle 99: TAB_KON_542 Fehlercodes TUC_KON_215 „SucheRecord“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4085	Security	Error	Zugriffsbedingungen nicht erfüllt
4086	Technical	Error	Verzeichnis deaktiviert
4087	Technical	Error	Datei nicht vorhanden
4093	Technical	Error	Karte wird in einer anderen Kartensitzung exklusiv verwendet
4094	Technical	Error	Timeout beim Kartenzugriff aufgetreten

[<=]

4.1.5.4.17 TUC_KON_018 „eGK-Sperrung prüfen“

TIP1-A_4579 - TUC_KON_018 „eGK-Sperrung prüfen“

Der Konnektor MUSS den technischen Use Case „eGK-Sperrung prüfen“ gemäß TUC_KON_018 umsetzen.
 

Tabelle 100: TAB_KON_110 - TUC_KON_018 „eGK-Sperrung prüfen“ 

Element	Beschreibung
Name	TUC_KON_018 „eGK-Sperrung prüfen“
Beschreibung	Es wird geprüft, dass DF.HCA (Health Care Application) der eGK nicht gesperrt ist und optional, dass das AUT-Zertifikat im DF.ESIGN gültig ist. Für eine Karte ab der Generation G2.1 wird das AUT-Zertifikat (ECC) geprüft. Für eine Karte der Generation G2.0 wird das AUT-Zertifikat (RSA) geprüft.
Auslöser	Aufruf durch Fachmodul im Konnektor
Vorbedingungen	keine
Eingangsdaten	cardSession                     checkHcaOnly [Boolean] - optional; default = false (Prüfung auf die Frage beschränken, ob auf DF.HCA zugegriffen werden kann)
Komponenten	Konnektor, Kartenterminal, eGK
Ausgangsdaten	Karte gesperrt: true | false Status – optional/wenn checkHcaOnly = false DF.HCA gesperrt: true | false Ergebnis der Offline-Prüfung des C.CH.AUT-Zertifikats: gültig | ungültig Sperrstatus des C.CH.AUT-Zertifikats: gut | gesperrt | nicht ermittelbar
Standardablauf	Ermittle Card = CM_CARD_LIST(cardSession) Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt. Selektiere DF.HCA : Wenn die Karte ’90 00’ zurückmeldet, war das Selektieren möglich: DF.HCA gesperrt = false In allen anderen Fällen war das Selektieren nicht fehlerfrei möglich: DF.HCA gesperrt = true Wenn checkHcaOnly = true Beende TUC, liefere Status. Ermittle Zertifikatsobjekt (fileIdentifier und folder) für C.AUT der Karte unter Berücksichtigung des kryptographischen Verfahrens crypt gemäß TAB_KON_858.  Für eine Karte ab der Generation G2.1 setze crypt=ECC. Für eine Karte der Generation G2.0 setze crypt=RSA. Rufe Cert = TUC_KON_216 „LeseZertifikat“ {cardSession; fileIdentifier; folder} Bestimme per Aufruf von TUC_KON_037 „Zertifikat prüfen“ das Ergebnis der Offline-Prüfung des C.CH.AUT-Zertifikats (gültig | ungültig) sowie den Sperrstatus des C.CH.AUT-Zertifkats (gut | gesperrt | nicht ermittelbar). Die Karte ist gesperrt = true, wenn DF.HCA gesperrt = true oder Ergebnis der Offline-Prüfung des C.CH.AUT-Zertifikats = ungültig oder Sperrstatus des C.CH.AUT-Zertifkats = gesperrt.     In allen anderen Fällen ist die Karte gesperrt = false.
Varianten/ Alternativen	keine
Fehlerfälle	(2) Karte ist fremd reserviert, Fehlercode 4093
Nichtfunktionale Anforderungen	keine
Zugehörige Diagramme	keine

 

Tabelle 101: TAB_KON_239 Fehlercodes TUC_KON_018 „eGK-Sperrung prüfen“ 

[<=]

4.1.5.4.18 TUC_KON_006 „Datenzugriffsaudit eGK schreiben“

TIP1-A_4580 - TUC_KON_006 „Datenzugriffsaudit eGK schreiben“

Der Konnektor MUSS den technischen Use Case „Datenzugriffsaudit eGK schreiben“ gemäß TUC_KON_006 umsetzen.
 

Tabelle 102: TAB_KON_108 - TUC_KON_006 „Datenzugriffsaudit eGK schreiben“ 

Element	Beschreibung
Name	TUC_KON_006 „Datenzugriffsaudit eGK schreiben“
Beschreibung	Zugriff auf eGK in EF.Logging protokollieren.
Auslöser	Aufruf durch ein Fachmodul
Vorbedingungen	Keine
Eingangsdaten	cardSession (CardSession einer eGK)                     sourceCardSession (HBA/SMC-B, der/die für den eGK-Zugriff verwendet wird)                     dataType (zugreifende Anwendung, siehe [gem_Spec_Karten_Fach_TIP#4.1 – Tabelle Tab_Karten_Fach_TIP_010 _StrukturEF.Logging – Struktur der Rekords der Datei EF.Logging]                     accessType (Zugriffsart, siehe ebenda)
Komponenten	eGK, HBA/SMC, Konnektor, Kartenterminal
Ausgangsdaten	Keine
Standardablauf	Ermittle Card = CM_CARD_LIST(cardSession)      Prüfe Card.TYPE = EGK      Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.      Wenn KeyRef in CARDSESSION.AUTHSTATE für DF.HCA.EF.LOGGING nicht mit passender Rolle vorhanden: Rufe TUC_CON_005 „Card-to-Card authentisieren“ {    sourceCardSession;    targetCardSession = cardSession;    authMode = einseitig}      Erzeuge Loggingdaten gemäß [gem_Spec_Karten_Fach_TIP#4.1 – Tabelle Tab_Karten_Fach_TIP_010_StrukturEF.Logging – Struktur der Rekords der Datei EF.Logging]      Rufe TUC_KON_214 „FügeHinzuRecord“ {     cardSession =$cardSession;     folder = MF;     fileIdentifier = DF.HCA/EF.Logging;     dataToBeWritten = Loggingdaten }
Varianten/ Alternativen	Keine
Fehlerfälle	(2) Protokoll nur für eGK gestattet, Fehlercode 4251 (3) Karte ist fremd reserviert, Fehlercode 4093
Nichtfunktionale Anforderungen	keine
Zugehörige Diagramme	keine

 

Tabelle 103: TAB_KON_238 Fehlercodes TUC_KON_006 „Datenzugriffsaudit eGK schreiben“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4093	Technical	Error	Karte wird in einer anderen Kartensitzung exklusiv verwendet
4251	Technical	Error	Protokoll nur für eGK gestattet

[<=]

4.1.5.4.19 TUC_KON_218 „Signiere“

TIP1-A_4581 - TUC_KON_218 „Signiere“

Der Konnektor MUSS den technischen Use Case „Signiere“ gemäß TUC_KON_218 umsetzen.
 

Tabelle 104: TAB_KON_231 – TUC_KON_218 „Signiere“ 

Element	Beschreibung
Name	TUC_KON_218 „Signiere“
Beschreibung	Dieser Use Case beschreibt das Anwenden eines privaten Schlüssels einer Karte zur Signatur oder Authentisierung.
Auslöser	Aufruf einer der Operationen SignDocument des Signaturdienstes oder ExternalAuthenticate des Authentifizierungsdienstes durch das Clientsystem.                     Aufruf durch Fachmodul
Vorbedingungen	Zugriffsbedingung für referenzierten Schlüssel MUSS erfüllt sein
Eingangsdaten	cardSession pinRef (PIN-Referenz, gemäß der Objektsystem-Spezifikation des jeweiligen Kartentyps) keyRef (Referenz auf den privaten Schlüssel, mit dem signiert werden soll, gemäß der Objektsystem-Spezifikation des jeweiligen Kartentyps) algorithmusId (einer der laut Objektspezifikation für diesen Schlüssel zulässigen algorithmIdentifier) dataToBeSigned (Zu signierende Daten, Hashwert)
Komponenten	Karte, Kartenterminal, Konnektor
Ausgangsdaten	chiffrat (Signatur)
Standardablauf	Ermittle Card = CM_CARD_LIST(cardSession)      Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.      Prüfe pinRef in CARDSESSION.AUTHSTATE vorhanden:      Setze keyRef und algorithmusId der Karte      Sende „PSO: COMPUTE DS“ mit dataToBeSigned an Karte      Gib chiffrat an den Aufrufer zurück
Varianten/ Alternativen	Keine
Fehlerfälle	* Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094 (2) Karte ist fremd reserviert, Fehlercode 4093 (3) Nötige PIN ist nicht verifiziert, Fehlercode 4085 (5) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	Keine

Tabelle 105: TAB_KON_543 Fehlercodes TUC_KON_218 „Signiere“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4085	Security	Error	Zugriffsbedingungen nicht erfüllt
4093	Technical	Error	Karte wird in einer anderen Kartensitzung exklusiv verwendet
4094	Technical	Error	Timeout beim Kartenzugriff aufgetreten

[<=]

4.1.5.4.20 TUC_KON_219 „Entschlüssele“

TIP1-A_4582 - TUC_KON_219 „Entschlüssele“

Der Konnektor MUSS den technischen Use Case „Entschlüssele“ gemäß TUC_KON_219 umsetzen.

Tabelle 106: TAB_KON_232 – TUC_KON_219 „Entschlüssele“ 

Element	Beschreibung
Name	TUC_KON_219 „Entschlüssele“
Beschreibung	Dieser Use Case beschreibt das Anwenden eines privaten Schlüssels einer Karte zur Entschlüsselung.
Auslöser	Aufruf durch Fachmodul
Vorbedingungen	Zugriffsbedingung für referenzierten Schlüssel muss erfüllt sein
Eingangsdaten	cardSession pinRef (Referenz auf die PIN, mit der der Entschlüsselungsschlüssel freigeschaltet werden kann, gemäß der Objektsystem-Spezifikation des jeweiligen Kartentyps) keyRef (Referenz auf den privaten Schlüssel, mit dem entschlüsselt werden soll, gemäß der Objektsystem-Spezifikation des jeweiligen Kartentyps.) algorithmusId (einer der für diesen Schlüssel zulässigen algorithmIdentifier) encryptedData (Zu entschlüsselnde Daten, Chiffrat)
Komponenten	Karte(n), Kartenterminal, Konnektor
Ausgangsdaten	plainData (Entschlüsselte Daten)
Standardablauf	Ermittle Card = CM_CARD_LIST(cardSession)      Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.      Prüfe pinRef in CARDSESSION.AUTHSTATE vorhanden:      Selektiere DF, in dem der private Schlüssel (keyRef) liegt, falls er noch nicht selektiert ist.      Setze Schlüssel (keyRef) und algorithmusId.      Sende encryptedData mittels Kommandos PSO: DECIPHER.      gib plainData an den Aufrufer zurück
Varianten/ Alternativen	Keine
Fehlerfälle	* Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094 (2) Karte ist fremd reserviert, Fehlercode 4093 (3) Nötige PIN ist nicht verifiziert, Fehlercode 4085 (5) Schlüssel nicht vorhanden, Fehlercode 4079 (6) Fehler im Chiffrat: Fehlercode 4069 (4, 6) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
Varianten/ Alternativen	Keine
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	Keine

Tabelle 107: TAB_KON_210 Fehlercodes TUC_KON_219 „Entschlüssele“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4069	Technical	Error	korruptes Chiffrat bei asymmetrischer Entschlüsselung
4079	Technical	Error	Schlüsseldaten fehlen
4085	Security	Error	Zugriffsbedingungen nicht erfüllt
4093	Technical	Error	Karte wird in einer anderen Kartensitzung exklusiv verwendet
4094	Technical	Error	Timeout beim Kartenzugriff aufgetreten

[<=]

4.1.5.4.21 TUC_KON_200 „SendeAPDU“

TIP1-A_4583 - TUC_KON_200 „SendeAPDU“

Der Konnektor MUSS den technischen Use Case „SendeAPDU“ gemäß TUC_KON_200 umsetzen.
 

Tabelle 108: TAB_KON_215 TUC_KON_200 „SendeAPDU“ 

Element	Beschreibung
Name	TUC_KON_200 „SendeAPDU“
Beschreibung	Dieser Use Case beschreibt das Senden einer APDU an eine Chipkarte bzw. an ein Kartenterminal und das Empfangen der Antwort.
Auslöser	Aufruf durch Fachmodul
Vorbedingungen	Zugriffsbedingungen für das Kommando müssen in der Karte erfüllt sein und Karte muss für exklusiven Zugriff reserviert worden sein
Eingangsdaten	cardSession – optional/verpflichtend, wenn die APDU an die Karte gerichtet ist ctId – optional/verpflichtend, wenn die APDU an das Kartenterminal gerichtet ist (Kartenterminalidentifikator für Kommandos an das Kartenterminal) commandAPDU (versandfertige APDU (Bytefolge), in dem die Parameter {CLA, INS, P1,P2, Data (optional) Le(optional) } gesetzt sind.)
Komponenten	Karte(n), Kartenterminal, Konnektor
Ausgangsdaten	responseAPDU (Antwort der Chipkarte oder des Kartenterminals, Bytefolge)
Standardablauf	A. cardSession ist gegeben      Ermittle Card = CM_CARD_LIST(cardSession)      Prüfe, dass der Aufrufer für die zur cardSession gehörenden Karte ein Lock hat.      commandAPDU wird über das Kartenterminal an die Zielkarte gesendet      die Antwort (responseAPDU) der Zielkarte wird an den Aufrufer zurückgegeben. B. ctId ist gegeben      Sende commandAPDU an das Kartenterminal ctId      gib die Antwort responseAPDU des Kartenterminals an den Aufrufer zurück
Varianten/Alternativen	Soll Secure Messaging verwendet werden, MUSS vorher TUC_KON_023 „Karte reservieren“ aufgerufen werden
Fehlerfälle	* Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094 (2) Der Aufrufer ist nicht im Besitz des Karten-Locks, Fehlercode 4232 (3) Kommunikationsfehler mit dem Kartenterminal: Fehlercode 4044. (3) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
Nichtfunktionale Anforderungen	keine
Zugehörige Diagramme	keine

 

Tabelle 109: TAB_KON_216 Fehlercodes TUC_KON_200 „SendeAPDU“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4044	Technical	Error	Fehler beim Zugriff auf das Kartenterminal
4094	Technical	Error	Timeout beim Kartenzugriff aufgetreten
4232	Technical	Error	der Aufrufer besitzt nicht das Karten-Lock

[<=]

4.1.5.4.22 TUC_KON_024 „Karte zurücksetzen“

TIP1-A_4584 - TUC_KON_024 „Karte zurücksetzen“

Der Konnektor MUSS den technischen Use Case „Karte zurücksetzen“ gemäß TUC_KON_024 umsetzen.
 

Tabelle 110: TAB_KON_737 – TUC_KON_024 „Karte zurücksetzen“ 

Element	Beschreibung
Name	TUC_KON_024 „Karte zurücksetzen“
Beschreibung	Der technische Use Case setzt die gewählte Karte zurück (alle erreichten Sicherheitszustände werden auf der Karte und in der Verwaltung des Konnektors zurückgesetzt; auf der Karte wird MF selektiert). Ein eventuell laufendes C2C wird dabei abgebrochen.
Auslöser	Fachmodul
Vorbedingungen	keine
Eingangsdaten	ctId – optional/verpflichtend, wenn keine cardSession angegeben ist (Kartenterminalidentifikator) slotId – optional/verpflichtend, wenn keine cardSession angegeben ist (Nummer des Slots, in dem die Karte steckt) cardSession – optional/verpflichtend, wenn ctId und slotId nicht angegeben sind (Angabe der CardSession alternativ zur Angabe von ctId und slotId)
Komponenten	Karte, Kartenterminal, Konnektor
Ausgangsdaten	Keine
Standardablauf	Wenn cardSession gegeben, dann ermittle ctId und slotId      Der Konnektor prüft, dass entweder die Karte nicht reserviert ist oder der Aufrufer im Besitz des Karten-Locks ist.      Brich eventuell parallel laufenden TUC_KON_005 ab      Sende SICCT RESET ICC für slotId an das Kartenterminal CtID, um einen Warm Reset auszulösen      Lösche alle Sicherheitszustände aus CARDSESSION.AUTHSTATE und den Inhalt von CARDSESSION.AUTHBY.
Varianten/ Alternativen	Keine
Fehlerfälle	* Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094 (2) Der Aufrufer ist nicht im Besitz des Karten-Locks, Fehlercode 4232 (4) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	Keine

 

Tabelle 111: TAB_KON_544 Fehlercodes TUC_KON_024 „Karte zurücksetzen“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4094	Technical	Error	Timeout beim Kartenzugriff aufgetreten
4232	Technical	Error	der Aufrufer ist nicht im Besitz des Karten-Locks

[<=]

4.1.5.4.23 TUC_KON_216 „LeseZertifikat“

TIP1-A_4585 - TUC_KON_216 „LeseZertifikat“

Der Konnektor MUSS den technischen Use Case „LeseZertifikat“ gemäß TUC_KON_216 umsetzen.
 

Tabelle 112: TAB_KON_230 – TUC_KON_216 „LeseZertifikat“ 

 

Tabelle 113: TAB_KON_209 Fehlercodes TUC_KON_216 „LeseZertifikat“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4093	Technical	Error	Karte wird in einer anderen Kartensitzung exklusiv verwendet
4256	Technical	Warning	Zertifikat auf Karte nicht vorhanden

[<=]

4.1.5.4.24 TUC_KON_036 „LiefereFachlicheRolle“

TIP1-A_5478 - TUC_KON_036 „LiefereFachlicheRolle“

Der Konnektor MUSS den technischen Use Case TUC_KON_036 „LiefereFachlicheRolle” umsetzen.
 

Tabelle 114: TAB_KON_827 TUC_KON_036 „LiefereFachlicheRolle“ 

Element	Beschreibung
Name	TUC_KON_036 „LiefereFachlicheRolle“
Beschreibung	Dieser TUC liefert die fachliche Rolle, die der OID aus dem X.509Zertifikat der gesteckten Karte zugeordnet ist. Es werden nur folgende Karten unterstützt: HBAx, SM-B, EGK, KVK Es werden nur die AUT-Zertifikate ausgelesen. Für eine Karte ab der Generation G2.1 wird das AUT-Zertifikat (ECC) geprüft. Für eine Karte der Generation G2.0 wird das AUT-Zertifikat (RSA) geprüft.
Auslöser	Aufruf durch ein Fachmodul oder eine Basisanwendung des Konnektors
Vorbedingungen	Keine
Eingangsdaten	cardSession
Komponenten	Konnektor, Karte
Ausgangsdaten	role (fachliche Rolle gemäß [gemSpec_PKI#Tab_PKI_254 Zugriffsprofile für eine Rollenauthentisierung]
Nachbedingungen	Keine
Standardablauf	Ermittle Card = CM_CARD_LIST(cardSession) Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer im Besitz des Karten-Locks ist. Wenn CARD.TYPE = KVK, dann setze fachliche Rolle = „Versicherter“ und springe zu Schritt 8. Ermittle fileIdentifier und folder des C.AUT-Zertifikates unter Berücksichtigung des kryptographischen Algorithmus crypt für die Karte, die durch die cardSession referenziert wird. Für eine Karte ab der Generation G2.1 setze crypt=ECC. Für eine Karte der Generation G2.0 setze crypt=RSA. Welches Zertifikat gelesen wird, ist in TAB_KON_858 beschrieben. Lies Zertifikat: Rufe TUC_KON_216 "LeseZertifikat" {     cardSession;     fileIdentifier = fileIdentifier (AUT-Zertifikat);     folder = folder(AUT-Zertifikat)} Ermittle ProfessionOIDs aus Extension Admission des Zertifikates: Rufe TUC_PKI_009 „Rollenermittlung” {certificate} Ermittle die fachliche Rolle, die den ProfessionOIDs entspricht, gemäß [gemSpec_PKI# Tab_PKI_254 Zugriffsprofile für eine Rollenauthentisierung]. Rückgabe $role (fachliche Rolle) an den Aufrufer
Varianten/ Alternativen	Keine
Fehlerfälle	* Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094 (2) Karte ist fremd reserviert, Fehlercode 4093 (7) ProfessionOIDs mappen nicht auf die gleiche Rolle, Fehlercode 4210
Nichtfunktionale Anforderungen	keine
Zugehörige Diagramme	keine

 

Tabelle 115: TAB_KON_829 Fehlercodes TUC_KON_036 „LiefereFachlicheRolle“ 

[<=]

4.1.5.5 Operationen an der Außenschnittstelle

TIP1-A_4586-03 - Basisanwendung Kartendienst

Der Konnektor MUSS für Clients eine Basisanwendung Kartendienst mit den Operationen VerifyPin, ChangePin, UnblockPin, GetPinStatus an der Außenschnittstelle anbieten.
 

Tabelle 116: TAB_KON_038 Basisanwendung Karten- und Kartenterminaldienst 

Name	CardService
Version (KDV)	8.1.0 (WSDL- und XSD-Version) 8.1.1 (WSDL- und XSD-Version) 8.1.2 (WSDL-Version) 8.1.3 (XSD-Version)
Namensraum	Siehe GitHub
Namensraum-Kürzel	CARD für Schema und CARDW für WSDL
Operationen	Name	Kurzbeschreibung
	VerifyPin	PIN prüfen
	ChangePin	PIN ändern
	UnblockPin	PIN entsperren
	GetPinStatus	PIN-Status ermitteln
	EnablePin	Erfordernis der PIN-Verifikation einschalten
	DisablePin	Erfordernis der PIN-Verifikation abschalten
WSDL	CardService.wsdl (WSDL-Version 8.1.0) CardService_v8_1_1.wsdl CardService_v8_1_2.wsdl
Schema	CardService.xsd (XSD-Version 8.1.0) CardService_v8_1_1.xsd CardService_v8_1_3.xsd

[<=]

4.1.5.5.1 VerifyPin

TIP1-A_4587 - Operation VerifyPin

Der Konnektor MUSS an der Außenschnittstelle eine Operation VerifyPin, wie in Tabelle TAB_KON_047 Operation VerifyPin beschrieben, anbieten.
 

Tabelle 117: TAB_KON_047 Operation VerifyPin 

Name	VerifyPin
Beschreibung	Stößt die sichere Eingabe einer PIN am PIN-Pad des Kartenterminals für eine Karte an. Das Ergebnis der PIN-Prüfung gibt Auskunft darüber, ob die PIN richtig oder falsch war oder aufgrund zu vieler Fehlversuche blockiert ist. Eine Karte kann potentiell mehrere PINs haben. Insbesondere für die qualifizierte elektronische Signatur existiert eine separate PIN. Diese PIN darf nur über das PIN-Pad eingegeben werden. Die PIN-Verifikation und die damit verbundene Änderung des Sicherheitsstatus der Karte erfolgt nur für die durch den Aufrufkontext adressierte Kartensitzung. Falls die Karte in einem zentralen Kartenterminal steckt, auf das der Arbeitsplatz Zugriff hat, erfolgt eine Remote-PIN-Eingabe. Das Kartenterminal für die PIN-Eingabe ergibt sich dabei aus der im Aufrufkontext angegebenen Mandanten-ID und Arbeitsplatz-ID Diese Operation entspricht dem Aufruf von TUC_KON_012 „PIN verifizieren“. Dort sind auch die Display Messages definiert, die bei PIN-Eingabe am Kartenterminal anzuzeigen sind (TAB_KON_090 Terminalanzeigen beim Eingeben der PIN am Kartenterminal). Die beim Aufruf von TUC_KON_012 anzugebende PIN-Art lautet „mandatorisch“. Die PIN-Verifikation wird also unabhängig vom erreichten Sicherheitsstatus in der Karte immer durchgeführt.
Aufrufparameter
	Name	Beschreibung
	Context	MandantId, CsId, WorkplaceId verpflichtend; UserId verpflichtend für HBAx
	CardHandle	Adressiert die Karte, für die die PIN verifiziert werden soll. Die Operation DARF die PIN-Verifikation mit der eGK NICHT unterstützen. Unterstützt werden die Kartentypen HBAx und SM-B. Wird die Operation mit einem nicht unterstützten Kartentypen aufgerufen, so MUSS der Konnektor die Bearbeitung mit dem Fehler 4209 abbrechen.
	PinTyp	Gibt an, welche PIN der Karte verifiziert werden soll. Erlaubte Belegung von PinTyp in Abhängigkeit der durch Cardhandle referenzierten Karte:                     HBAx: PIN.CH                     SM-B: PIN.SMC
Rückgabe
	Name	Beschreibung
	Status	Enthält den Ausführungsstatus der Operation (siehe 3.5.2)
	PinResult	Wert	Bedeutung
		OK	Prüfung war erfolgreich
		REJECTED	PIN war falsch. Die Anzahl der verbleibenden Versuche ist im Element LeftTries
		ERROR	Ein Bearbeitungsfehler ist aufgetreten. Fehlerursache im Feld Error
		WASBLOCKED	PIN war zum Aufrufzeitpunkt bereits gesperrt
		NOWBLOCKED	PIN ist durch aktuellen Fehlversuch gesperrt
		TRANSPORT _PIN	PIN ist mit Transportschutz versehen
	LeftTries	Im Falle von Result=REJECTED wird hier die Anzahl der verbleibenden möglichen Versuche zurückgegeben.
Vorbedingung	Keine
Nachbedingung	keine

Der Ablauf der Operation VerifyPin ist in Tabelle TAB_KON_738 Ablauf VerifyPin beschrieben.
 

Tabelle 118: TAB_KON_738 Ablauf VerifyPin 

Nr.	Aufruf Technischer Use Case oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
2.	TUC_KON_000 „Prüfe Zugriffs-berechtigung“	Prüfung der Zugriffsberechtigung durch den Aufruf TUC_KON_000 {     mandantId = $context.mandantId;     clientSystemId = $context.clientsystemId;     workplaceId = $context.workplaceId;     userId = $context.userId;     cardHandle } Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.
3.	TUC_KON_026 „Liefere CardSession“	Ermittle cardSession über TUC_KON_026 {     mandatId =$context.mandantId;     clientsystemId  = $context.clientsystemId;     userId = $context.userId;     cardHandle }
4.	TUC_KON_012 „PIN verifizieren“	Verifiziere PIN über TUC_KON_012 {     cardSession;     workplaceId = $context.workplaceId;     pinRef = PinRef(PinTyp);     appName = „” (Leerstring);     verificationType = Mandatorisch }
5.	Verifikationsergebnis auswerten	Wenn TUC_KON_012 mit Fehler 4065 abbricht, wird dies als erfolgreicher Operationsdurchlauf mit PinResult= TRANSPORT_PIN abgefangen. Wenn TUC_KON_012 den Returncode BLOCKED liefert, wird dies als erfolgreicher Operationsdurchlauf mit PinResult= NOWBLOCKED zurückgegeben. Wenn TUC_KON_012 mit Fehler 4063 abbricht, wird dies als erfolgreicher Operationsdurchlauf mit PinResult= WASBLOCKED zurückgegeben

Tabelle 119: TAB_KON_545 Fehlercodes „VerifyPin“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler
4078	Security	Error	PIN-Eingabe über das Clientsystem ist nicht zugelassen
4209	Technical	Error	Kartentyp %CardType% wird durch diese Operation nicht unterstützt.

[<=]

4.1.5.5.2 ChangePin

TIP1-A_4588 - Operation ChangePin

Der Konnektor MUSS an der Außenschnittstelle eine Operation ChangePin, wie in Tabelle TAB_KON_049 Operation ChangePin beschrieben, anbieten.

Tabelle 120: TAB_KON_049 Operation ChangePin 

Name	ChangePin
Beschreibung	Ändert eine PIN einer Karte. Alte und neue PIN werden dabei am PIN-Pad des Kartenterminals eingegeben. Falls die Karte in einem zentralen Kartenterminal steckt, auf das der im Aufrufkontext angegebene Arbeitsplatz Zugriff hat, erfolgt eine Remote-PIN-Eingabe. Diese Operation entspricht dem Aufruf TUC_KON_019 „PIN ändern“ .
Aufrufparameter
	Name	Beschreibung
	Context	MandantId, CsId, WorkplaceId verpflichtend; UserId optional (verpflichtend beim HBA)
	CardHandle	Adressiert die Karte, für die die PIN geändert werden soll. Unterstützt werden die Kartentypen EGK, HBAx und SM-B. Wird die Operation mit einem nicht unterstützten Kartentypen aufgerufen, so MUSS der Konnektor die Bearbeitung mit dem Fehler 4209 abbrechen.
	PinTyp	Gibt an, welche PIN der Karte geändert werden soll. Erlaubte Belegung von PinTyp in Abhängigkeit der durch CardHandle referenzierten Karte: eGK G1+: PIN.CH, eGK G2: PIN.CH,   MRPIN.NFD, MRPIN.NFD_READ, MRPIN.DPE, MRPIN.GDD, MRPIN.OSE, MRPIN.AMTS, PIN.AMTS_REP zusätzlich eGK G2.0: MRPIN.DPE_READ HBAx: PIN.CH, PIN.QES SM-B: PIN.SMC
Rückgabe
	Name	Beschreibung
	LeftTries	Im Falle von REJECTED wird hier die Anzahl der verbleibenden möglichen Versuche zurückgegeben.
	Status	Enthält den Ausführungsstatus der Operation, siehe 3.5.2
	PinResult	Wert	Bedeutung
		OK	PIN-Änderung war erfolgreich
		ERROR	Ein Bearbeitungsfehler ist aufgetreten. Fehlerursache im Feld Error
		REJECTED	OldPIN war falsch Die Anzahl der verbleibenden Versuche ist im Element LeftTries
		WASBLOCKED	PIN war zum Aufrufzeitpunkt bereits gesperrt
		NOWBLOCKED	PIN ist durch aktuellen Fehlversuch gesperrt
Vorbedingung	Keine
Nachbedingung	keine

Tabelle 121: TAB_KON_546 Ablauf ChangePin 

Nr.	Aufruf Technischer Use Case oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
2.	TUC_KON_000 „Prüfe Zugriffs-berechtigung“	Prüfung der Zugriffsberechtigung durch den Aufruf TUC_KON_000 {     mandantId = $context.mandantId;     clientSystemId = $context.clientsystemId;     workplaceId = $context.workplaceId;     userId = $context.userId;     cardHandle } Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.
3.	TUC_KON_026 „Liefere CardSession“	Ermittle cardSession über TUC_KON_026 {     mandantId =$context.mandantId;     clientsystemId  = $context.clientsystemId;     cardHandle;     userId = $context.userId }
4.	TUC_KON_019 „PIN ändern“	Ändere PIN über TUC_KON_019 {     cardSession;     workplaceId = $context.workplaceId;     pinRef = PinRef(PinTyp) }
5.	Verifikationsergebnis auswerten	Wenn TUC_KON_019 den Returncode BLOCKED liefert, wird dies als erfolgreicher Operationsdurchlauf mit PinResult= NOWBLOCKED zurückgegeben. Wenn TUC_KON_019 mit Fehler 4063 abbricht, wird dies als erfolgreicher Operationsdurchlauf mit PinResult= WASBLOCKED zurückgegeben.

Tabelle 122: TAB_KON_547 Fehlercodes „ChangePin“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler
4072	Technical	Error	Ungültige PIN-Referenz PinRef
4209	Technical	Error	Kartentyp %CardType% wird durch diese Operation nicht unterstützt.

[<=]

4.1.5.5.3 GetPinStatus

TIP1-A_4589 - Operation GetPinStatus

Der Konnektor MUSS an der Außenschnittstelle eine Operation GetPinStatus, wie in Tabelle TAB_KON_051 Operation GetPinStatus beschrieben, anbieten.
 

Tabelle 123: TAB_KON_051 Operation GetPinStatus 

Name	GetPinStatus
Beschreibung	Diese Operation gibt Auskunft über den PIN-Zustand einer Karte. Für transportgeschützte PIN gibt die Operation die Art des Transportschutzes an. Für Echt-PINs kann mit dieser Operation die Anzahl der noch verbleibenden Versuche für PIN-Verifikationen ermittelt werden oder ob die PIN bereits verifiziert wurde.
Aufruf-parameter
	Name		Beschreibung
	Context		MandantId, CsId, WorkplaceId; UserId
	CardHandle		Adressiert die Karte, für die der PIN-Status ermittelt werden soll. Unterstützt werden die Kartentypen EGK, HBAx und SM-B. Eine KVK ist nicht zulässig. Wird die Operation mit einem nicht unterstützten Kartentypen aufgerufen, so MUSS der Konnektor die Bearbeitung mit dem Fehler 4209 abbrechen.
	PinTyp		Gibt an, für welche PIN der Karte der PIN-Status ermittelt werden soll. Erlaubte Belegung von PinTyp in Abhängigkeit der durch Cardhandle referenzierten Karte: eGK G1+: PIN.CH eGK G2: PIN.CH, MRPIN.NFD, MRPIN.NFD_READ, MRPIN.DPE,  MRPIN.GDD, MRPIN.OSE, MRPIN.AMTS, PIN.AMTS_REP zusätzlich eGK G2.0: MRPIN.DPE_READ HBAx: PIN.CH, PIN.QES SM-B: PIN.SMC
Rückgabe
	Name	Beschreibung
	Status	Enthält den Ausführungsstatus der Operation siehe 3.5.2
	PinStatus	Status der PIN. Die folgenden Werte sind verpflichtend:
		Wert		Bedeutung
		VERIFIED		Bereits verifiziert (in CARDSESSION.AUTHSTATE vorhanden)
		TRANSPORT_PIN		Transport-PIN
		EMPTY_PIN		Leer-PIN
		BLOCKED		gesperrt
		VERIFIABLE		Echt-PIN, noch nicht verifiziert
		DISABLED		PIN-Schutz ausgeschaltet (Verifikation nicht erforderlich)
	LeftTries	Bei einer Echt-PIN wird hier bei PinStatus = VERIFIABLE die Anzahl der verbleibenden möglichen Versuche für die Verifikation der PIN zurückgegeben, bei einer gesperrten PIN 0.
Vorbedingung	keine
Nachbe-dingung	keine

Tabelle 124: TAB_KON_548 Ablauf GetPinStatus 

Nr .	Aufruf Technischer Use Case oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
2.	TUC_KON_000 „Prüfe Zugriffs- berechtigung“	Prüfung der Zugriffsberechtigung durch den Aufruf TUC_KON_000 {     mandantId = $context.mandantId;     clientSystemId = $context.clientsystemId;     workplaceId = $context.workplaceId;     userId = $context.userId;  // falls angegeben     cardHandle } Tritt bei der Prüfung ein Fehler auf, so bricht die Operation mit dem Fehlercode aus TUC_KON_000 ab.
3.	TUC_KON_026 „Liefere CardSession“	Ermittle cardSession über TUC_KON_026 {     mandantId = $context.mandantId;     clientSystemId = $context.clientsystemId;     userId = $context.userId;  // falls angegeben ;     cardHandle }
4.	TUC_KON_022 „Liefere PIN-Status“	Ermittle PinStatus über TUC_KON_022 {     cardSession;     pinRef = PinRef(PinTyp) }

Tabelle 125: TAB_KON_549 Fehlercodes „GetPinStatus“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler
4001	Technical	Error	interner Fehler
4072	Technical	Error	ungültige PIN-Referenz PinRef
4209	Technical	Error	Kartentyp %CardType% wird durch diese Operation nicht unterstützt.

[<=]

4.1.5.5.4 UnblockPin

TIP1-A_4590 - Operation UnblockPin

Der Konnektor MUSS an der Außenschnittstelle eine Operation UnblockPin, wie in Tabelle TAB_KON_053 Operation UnblockPin beschrieben, anbieten.
 

Tabelle 126: TAB_KON_053 Operation UnblockPin 

Name	UnblockPin
Beschreibung	Mit diesem Kommando kann eine blockierte PIN wieder freigeschaltet werden. Dabei wird der Wiederholungszähler für diese PIN in der Karte auf seinen Anfangswert zurückgesetzt und es KANN eine neue PIN gesetzt werden. Um diese Aktion durchführen zu können, muss eine PUK (auch als Resetting Code bezeichnet) präsentiert werden. PIN und PUK werden am PIN-Pad des Kartenterminals eingegeben. Falls die Karte in einem zentralen Kartenterminal steckt, auf das der im Aufrufkontext angegebene Arbeitsplatz Zugriff hat, erfolgt eine Remote-PIN-Eingabe. Das Kartenterminal für die PIN-Eingabe ergibt sich dabei aus der im Aufrufkontext angegebenen Mandanten-ID und Arbeitsplatz-ID. Diese Operation entspricht dem Aufruf von TUC_KON_021 „PIN entsperren“.
Aufruf-parameter
	Name	Beschreibung
	Context	MandantId, CsId, WorkplaceId verpflichtend; UserId (optional, für HBA verpflichtend)
	CardHandle	Adressiert die Karte, für die die Blockierung der PIN aufgehoben werden soll. Unterstützt werden die Kartentypen EGK, HBAx und SM-B. Wird die Operation mit einem nicht unterstützten Kartentypen aufgerufen, so MUSS der Konnektor die Bearbeitung mit dem Fehler 4209 abbrechen.
	PinTyp	Gibt an, für welche PIN der Karte die Blockierung aufgehoben werden soll. Erlaubte Belegung von PinTyp in Abhängigkeit der durch Cardhandle referenzierten Karte:   -   eGK G1+: PIN.CH  -   eGK G2: PIN.CH,  MRPIN.NFD, MRPIN.NFD_READ,     MRPIN.DPE, MRPIN.GDD, MRPIN.OSE, MRPIN.AMTS,    PIN.AMTS_REP    - zusätzlich eGK G2.0: MRPIN.DPE_READ  -    HBAx: PIN.CH, PIN.QES  -    SM-B: PIN.SMC
	SetNewPin	Dieses Flag zeigt an, ob eine neue PIN gesetzt werden soll. Wird dieses Flag nicht angegeben, so wird FALSE angenommen. Das Flag ist notwendig, um bei Eingabe am PIN-Pad eindeutig festzulegen, ob eine neue PIN gesetzt werden soll.
Rückgabe
	Name	Beschreibung
	LeftTries	Im Falle von REJECTED wird hier die Anzahl der verbleibenden möglichen Versuche für die Eingabe der PUK zurückgegeben.
	Status	Enthält den Ausführungsstatus der Operation siehe 3.5.2
	PinResult	Wert	Bedeutung
		OK	Prüfung war erfolgreich.
		ERROR	Ein Bearbeitungsfehler ist aufgetreten. Fehlerursache im Feld Error.
		REJECTED	PUK war falsch. Die Anzahl der verbleibenden Versuche ist im Element LeftTries.
		WASBLOCKED	PUK war zum Aufrufzeitpunkt bereits gesperrt
		NOWBLOCKED	PUK ist durch aktuellen Fehlversuch gesperrt
Vorbe-dingungen	keine
Nachbe-dingungen	keine

Tabelle 127: TAB_KON_550 Ablauf UnblockPIN 

Nr.	Aufruf Technischer Use Case oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
2.	TUC_KON_000 „Prüfe Zugriffs-berechtigung“	Prüfung der Zugriffsberechtigung durch den Aufruf TUC_KON_000 {     mandantId = $context.mandantId;     clientSystemId = $context.clientsystemId;     workplaceId = $context.workplaceId;     userId = $context.userId; // falls angegeben     cardHandle }
3.	TUC_KON_026 „Liefere CardSession“	Ermittle cardSession über TUC_KON_026 {     mandantId = $context.mandantId;     clientSystemId = $context.clientsystemId;     userId = $context.userId;  // falls angegeben     cardHandle }
4.	TUC_KON_021 „PIN entsperren“	Rücksetzen des Fehlbedienungszählers über TUC_KON_021 {     cardSession;     workplaceId = $context.workplaceId;     pinRef = pinRef(PinTyp);     setNewPIN = SetNewPIN }
5.	Verifikationsergebnis auswerten	Wenn TUC_KON_021 den Returncode BLOCKED liefert, wird dies als erfolgreicher Operationsdurchlauf mit PinResult= NOWBLOCKED zurückgegeben. Wenn TUC_KON_021 mit dem Fehlercode 4064 abbricht, wird dies als erfolgreicher Operationsdurchlauf mit PinResult= WASBLOCKED zurückgegeben.

Tabelle 128: TAB_KON_551 Fehlercodes „UnblockPin“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler
4209	Technical	Error	Kartentyp %CardType% wird durch diese Operation nicht unterstützt.

[<=]

4.1.5.5.5 EnablePin

TIP1-A_5487 - Operation EnablePin

Der Konnektor MUSS an der Außenschnittstelle eine Operation EnablePin, wie in Tabelle TAB_KON_242 Operation EnablePin beschrieben, anbieten.

Tabelle 129: TAB_KON_242 Operation EnablePin 

Name	EnablePin
Beschreibung	Schaltet für eine Multireferenz-PIN das Erfordernis, das Nutzergeheimnis zu verifizieren, ein, so dass der Sicherheitszustand nur durch eine erfolgreiche Benutzerverifikation gesetzt werden kann.
Aufrufparameter
	Name	Beschreibung
	Context	MandantId, ClientSystemId, WorkplaceId verpflichtend;
	CardHandle	Adressiert die Karte, deren MRPIN bearbeitet werden soll. Es werden nur eGKs ab Generation 2 unterstützt.
	PinTyp	Gibt an, auf welche MRPIN der Karte die Operation angewendet werden soll. Erlaubte Werte: eGK G2: MRPIN.NFD, MRPIN.DPE, MRPIN.GDD zusätzlich ab eGK G2.1: MRPIN.AMTS
Rückgabe
	Name	Beschreibung
	Status	Enthält den Ausführungsstatus der Operation, siehe 3.5.2
	PinResult	Wert	Bedeutung
		OK	Aktivierung war erfolgreich
		REJECTED	PIN war falsch. Die Anzahl der verbleibenden Versuche ist im Element LeftTries
		ERROR	Ein Bearbeitungsfehler ist aufgetreten. Fehlerursache im Feld Error
		WASBLOCKED	PIN war zum Aufrufzeitpunkt bereits gesperrt
		NOWBLOCKED	PIN ist durch aktuellen Fehlversuch gesperrt
		TRANSPORT_PIN	Dieser Wert wird nicht verwendet
	LeftTries	Im Falle von Result=REJECTED wird hier die Anzahl der verbleibenden möglichen Versuche zurückgegeben.
Vorbedingung	keine
Nachbedingung	Für das Erreichen des Sicherheitszustands der MRPIN ist eine Nutzereingabe erforderlich

 

Tabelle 130: TAB_KON_243 Ablauf EnablePin 

Nr.	Aufruf Technischer Use Case oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
2.	TUC_KON_000 „Prüfe Zugriffs- berechtigung“	Prüfung der Zugriffsberechtigung durch den Aufruf TUC_KON_000 {     mandantId = $context.mandantId;     clientSystemId = $context.clientsystemId;     workplaceId = $context.workplaceId;     userId = $context.userId;     cardHandle } Tritt bei der Prüfung ein Fehler auf, so bricht die Operation mit dem Fehlercode aus TUC_KON_000 ab.
3.	TUC_KON_026 „Liefere CardSession“	Ermittle cardSession über TUC_KON_026 {     mandantId = $context.mandantId;     clientSystemId = $context.clientsystemId;     userId = $context.userId;     cardHandle }
4.	TUC_KON_027 „PIN-Schutz ein-/ausschalten“	Aktiviere das Erfordernis der Benutzerverifikation der MRPIN durch Aufruf des TUC_KON_027 „PIN-Schutz ein-/ausschalten“ {     cardSession;     pinRef  =   PinRef(PinType);     enable = true}
5.	Verifikationsergebnis auswerten	Als erfolgreicher Operationsdurchlauf wird nur PinResult=OK gewertet. Alle anderen Resultate sind Fehlerfälle, und neben dem Status ist auch PinResult entsprechend zu setzen. Dabei gelten folgende Regeln: Wenn TUC_KON_027 den PIN-Status BLOCKED liefert, wird auf PinResult=NOWBLOCKED abgebildet. Wenn TUC_KON_027 mit Fehler 4063 abbricht, wird dies auf PinResult=WASBLOCKED abgebildet.

 

Tabelle 131: TAB_KON_244 Fehlercodes „EnablePin“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler
4072	Technical	Error	Ungültige PIN-Referenz PinRef
4209	Technical	Error	Kartentyp %CardType% wird durch diese Operation nicht unterstützt.

[<=]

4.1.5.5.6 DisablePin

TIP1-A_5488 - Operation DisablePin

Der Konnektor MUSS an der Außenschnittstelle eine Operation DisablePin, wie in Tabelle TAB_KON_245 Operation DisablePin beschrieben, anbieten.

Tabelle 132: TAB_KON_245 Operation DisablePin 

Name	DisablePin
Beschreibung	Schaltet für eine Multireferenz-PIN das Erfordernis, das Nutzergeheimnis zu verifizieren, ab. Die MRPIN verhält sich danach bei allen Zugriffen auf die durch sie geschützten Objekte, als wäre sie freigeschaltet.
Aufrufparameter
	Name	Beschreibung
	Context	MandantId, ClientSystemId, WorkplaceId verpflichtend;
	CardHandle	Adressiert die Karte, deren MRPIN bearbeitet werden soll. Es werden nur eGKs ab Generation 2 unterstützt.
	PinTyp	Gibt an, auf welche MRPIN der Karte die Operation angewendet werden soll. Erlaubte Werte: eGK G2: MRPIN.NFD, MRPIN.DPE, MRPIN.GDD zusätzlich ab eGK G2.1: MRPIN.AMTS
Rückgabe
	Name	Beschreibung
	Status	Enthält den Ausführungsstatus der Operation siehe 3.5.2
	PinResult	Wert	Bedeutung
		OK	Aktivierung war erfolgreich
		REJECTED	PIN war falsch. Die Anzahl der verbleibenden Versuche ist im Element LeftTries
		ERROR	Ein Bearbeitungsfehler ist aufgetreten. Fehlerursache im Feld Error
		WASBLOCKED	PIN war zum Aufrufzeitpunkt bereits gesperrt
		NOWBLOCKED	PIN ist durch aktuellen Fehlversuch gesperrt
		TRANSPORT_PIN	Dieser Wert wird nicht verwendet
	LeftTries	Im Falle von Result=REJECTED wird hier die Anzahl der verbleibenden möglichen Versuche zurückgegeben.
Vorbedingung	keine
Nachbedingung	Der Sicherheitszustand der PIN ist dauerhaft (bis zur expliten Aktivierung mit EnablePin) gesetzt, ohne dass eine Nutzereingabe erforderlich wäre

Tabelle 133: TAB_KON_246 Ablauf DisablePin 

Nr.	Aufruf Technischer Use Case oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
2.	TUC_KON_000 „Prüfe Zugriffs- berechtigung“	Prüfung der Zugriffsberechtigung durch den Aufruf TUC_KON_000 {     mandantId = $context.mandantId;     clientSystemId = $context.clientsystemId;     workplaceId = $context.workplaceId;     userId = $context.userId;     cardHandle } Tritt bei der Prüfung ein Fehler auf, so bricht die Operation mit dem Fehlercode aus TUC_KON_000 ab.
3.	TUC_KON_026 „Liefere CardSession“	Ermittle cardSession über TUC_KON_026 {     mandantId = $context.mandantId;     clientSystemId = $context.clientSystemId;     userId = $context.userId;     cardHandle }
4.	TUC_KON_027 „PIN-Schutz ein-/ausschalten“	Deaktiviere das Erfordernis der Benutzerverifikation der MRPIN durch Aufruf des TUC_KON_027 „PIN-Schutz ein-/ausschalten“ {     cardSession;     pinRef  =   PinRef(PinType);     enable = false}
5.	Verifikations-ergebnis auswerten	Als erfolgreicher Operationsdurchlauf wird nur PinResult=OK gewertet. Alle anderen Resultate sind Fehlerfälle, und neben dem Status ist auch PinResult entsprechend zu setzen. Dabei gelten folgende Regeln: Wenn TUC_KON_027 den PIN-Status BLOCKED liefert, wird auf PinResult=NOWBLOCKED abgebildet. Wenn TUC_KON_027 mit Fehler 4063 abbricht, wird dies auf PinResult=WASBLOCKED abgebildet.

 

Tabelle 134: TAB_KON_247 Fehlercodes „DisablePin“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler
4072	Technical	Error	ungültige PIN-Referenz PinRef
4209	Technical	Error	Kartentyp %CardType% wird durch diese Operation nicht unterstützt.

[<=]

4.1.5.6 Betriebsaspekte

TIP1-A_4592 - Konfigurationswerte des Kartendienstes

Der Konnektor MUSS es einem Administrator ermöglichen, Konfigurationsänderungen gemäß Tabelle TAB_KON_554 vorzunehmen.
 

Tabelle 135: TAB_KON_554 Konfiguration des Kartendienstes 

ReferenzID	Belegung	Bedeutung
CARD_TIMEOUT_CARD	Sekunden	Maximale Zeit, die ein Aufruf einer Kartenoperation dauern darf, bevor der Aufruf abgebrochen wird. Der Konnektor MUSS sicherstellen, dass dieser Parameter einen Wert besitzt, mit dem ein reibungsloser Betrieb gewährleistet ist, und MUSS dem Administrator die Möglichkeit bieten, diesen Parameter zu konfigurieren.

[<=]

4.1.5.6.1 TUC_KON_025 "Initialisierung Kartendienst"

TIP1-A_4593 - TUC_KON_025 „Initialisierung Kartendienst“

Der Konnektor MUSS den technischen Use Case „Initialisierung Kartendienst“ gemäß TUC_KON_025 umsetzen.

Tabelle 136: TAB_KON_555 - TUC_KON_025 „Initialisierung Kartendienst“ 

Element	Beschreibung
Name	TUC_KON_025 „Initialisierung Kartendienst“
Beschreibung	Nach dem Start des Kartendienstes MUSS der Konnektor für alle gesteckten Karten den TUC_KON_001 {ctId, slotId } aufrufen und CM_CARD_LIST befüllen.
Auslöser	der Kartendienst wird gestartet
Vorbedingungen	Kartenterminaldienst wurde gestartet
Eingangsdaten	CTM_CT_LIST
Komponenten	Karte, Kartenterminal, Konnektor
Ausgangsdaten	Aktuelle CM_CARD_LIST
Standardablauf	Rufe TUC_KON_001 „Karte öffnen“ Wiederhole, bis für alle gesteckten Karten ein Eintrag in CM_CARD_LIST existiert.
Varianten/Alternativen	keine
Fehlerfälle	keine
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	Keine

[<=]

4.1.5.6.2 Kartenübersicht und PIN-Management

TIP1-A_5110-02 - Übersicht über alle verfügbaren Karten

Die Administrationsoberfläche MUSS dem Administrator eine Übersichtsseite anbieten, die alle in CM_CARD_LIST enthaltenen Karten listet.
In dieser Übersichtsseite muss zu jeder Karte dargestellt werden:
 

1.        CARD.CTID
2.        CT(CARD.CTID).HOSTNAME
3.        CARD.SLOTNO
4.        CARD.TYPE
5.        CARD.INSERTTIME
6.        CARD.CARDHOLDERNAME

Ferner MÜSSEN auf Verlangen des Administrators zu jeder Karte neben den obigen Informationen auch folgende Details angezeigt werden:

• CARD.ICCSN
• CARD.CARDVERSION
• CARD.CERTEXPIRATIONDATE
• CARD.CERTSTATUS

[<=]

TIP1-A_5111 - PIN-Management der SM-Bs für den Administrator

Über die Administrationsoberfläche MUSS der Administrator für jede in der Übersichtsseite angezeigte Karte vom Typ SM-B die folgenden TUCs für die PIN.SMC auslösen können.
Für diese MUSS er einen der gemäß Kapitel 4.1.1.6 [TIP1-A_4526] definierten Mandanten auswählen können:

• TUC_KON_012 „PIN verifizieren“
• TUC_KON_019 „PIN ändern“
• TUC_KON_021 „PIN entsperren“
• TUC_KON 022 „Liefere PIN-Status“

Die Eingabe der PIN SOLL von jedem vom Informationsmodell her zulässigen Kartenterminal aus möglich sein.
[<=]

Der Konnektor kann den Administrator zur Laufzeit entscheiden lassen, an welchem Kartenterminal die PIN eingegeben werden soll, indem er ihn wählen lässt, ob er die PIN am Kartenterminal eingibt, in dem die betroffene SM-B steckt, oder ihn den Arbeitsplatz wählen lässt, von dem aus er die Remote-PIN eingibt.

4.1.6 Systeminformationsdienst

Der Systeminformationsdienst stellt Basisdiensten, Fachmodulen und Clientsystemen sowohl aktiv (Push-Mechanismus) wie passiv (Pull-Mechanismus) Informationen zur Verfügung. Dabei erhebt er selbst keine Daten, sondern dient nur als zentraler Mechanismus, der von anderen Basisdiensten und Fachmodulen zur Verteilung und Bereitstellung derer Informationen verwendet werden kann.

Innerhalb des Systeminformationsdienstes werden folgende Präfixe für Bezeichner verwendet:

• Events (Topic Ebene 1):    „EVT“
• Konfigurationsparameter:    „EVT_“

Push-Mechanismus

Der Push-Mechanismus des Systeminformationsdienstes hat die Aufgabe, Ereignisse von internen Ereignisquellen im Konnektor (z. B. von anderen Basisdiensten wie Kartendienst, Kartenterminaldienst oder Fachmodulen) an alle Basisdienste und Fachmodule sowie an die bei ihm registrierten Ereignisempfänger (Clientsysteme) weiterzuleiten.

Die Namen der Ereignisse, die Topics, sind als Baumstruktur organisiert und werden mittels „/“-getrennter Liste angegeben (z. B. „Auslöser/Ereigniskategorie1/…/Ereignis1“). Die konkreten Topics werden innerhalb der einzelnen Funktionsmerkmale kontextbezogen definiert und im Anhang in einer zentralen Liste übersichtlich dargestellt.

Clientsysteme können sich für den Empfang bestimmter Ereigniskategorien (Topics) anmelden. Der Systeminformationsdienst übernimmt dementsprechend bei der Verteilung der Ereignisse auch eine Filterfunktion für die weiterzuleitenden Ereignisse.

Die Zustellung der Ereignisse erfolgt unidirektional über eine Netzschnittstelle, deren Kommunikationsendpunkt („Ereignissenke“) vom Clientsystem realisiert werden muss. Zur Übertragung der Daten wird ein konnektoreigenes Protokoll cetp (Connector Event Transport Protocol) verwendet.

Pull-Mechanismus

Der Pull-Mechanismus des Systeminformationsdienstes hat die Aufgabe sowohl Zustandswerte als auch statische Informationen des Konnektors selbst als auch von den über ihn verwalteten Ressourcen durch Fachmodule und Clientsysteme abrufbar zu machen. Dabei können entweder Listen von Ressourcen oder Details zu einzelnen Ressourcen abgerufen werden.

Die folgenden Unterkapitel regeln:

• Das Kommunikationsprotokoll cetp
• Die Struktur der Ereignisnachricht
• Die TUCs für die Ereignisverteilung (PUSH)
• Die TUCs und Operationen der Außenschnittstelle für den Abruf von Informationen (PULL)
• Einstellungen, die der Administrator zur Steuerung des Verhaltens vornehmen kann.

4.1.6.1 Funktionsmerkmalweite Aspekte

TIP1-A_4594 - Richtung bei Verbindungsaufbau des Systeminformationsdienstes

Der Konnektors MUSS zur Übertragung von Ereignissen eine cetp-Verbindung zu der Ereignissenke des Clientsystems aufbauen, die das Clientsystem beim Operationsaufruf Subscribe per EventTo angegeben hatte.

[<=]

TIP1-A_5536 - Connector Event Transport Protocol über TCP

Der Konnektor MUSS das Anwendungsprotokoll cetp (Connector Event Transport Protocol) ausschließlich über das Transportprotokoll TCP (gebenenfalls TLS gesichert) anbieten.

[<=]

TIP1-A_4595 - Gesicherte Übertragung von Ereignissen

Der Konnektor MUSS zur Übertragung der Ereignisse eine gesicherte Verbindung (TLS) verwenden, die vom Konnektor als TLS-Client initiiert wurde, wenn ANCL_TLS_MANDATORY=Enabled.
Der Konnektor muss sich beim Aufbau der TLS-Sitzung gegenüber dem Clientsystem authentisieren, wenn dieses eine Authentisierung im Rahmen des TLS-Handshakes anfordert.
Die Schalter ANCL_CAUT_MODE und ANCL_CAUT_MANDATORY wirken für die Übertragung der Ereignisse nicht.
[<=]

Für die Übermittlung der Ereignisse wurde ein leichtgewichtiges Protokoll gewählt, da vom Clientsystem keine Antwort auf Anwendungsebene erwartet wird.

TIP1-A_4596 - Nachrichtenaufbau und -kodierung des Systeminformationsdienstes

Der Konnektors MUSS Ereignisse an Ereignissenken mittels Nachrichten verteilen, die gemäß TAB_KON_030 „Ereignisnachricht“ aufgebaut sind. Der Konnektor MUSS die Nachrichten mit der Zeichenkette „CETP“ beginnen, gefolgt von der Länge der folgenden Ereignisnachricht in Anzahl Bytes. Das vier Byte lange Längenfeld MUSS in der Byte-Reihenfolge Big-Endian codiert werden (das hochwertigste Byte wird als erstes übertragen).

 

Abbildung 11: PIC_KON_022 Grundsätzlicher Aufbau der Ereignisnachricht

Tabelle 137: TAB_KON_030 Ereignisnachricht

Beschreibung	Die Ereignisnachricht, die zur Ereignissenke gesendet wird, ist ein XML-Dokument. Die Ereignisnachricht wird in den „Umschlag“ Event gepackt. Wenn ein mandantenfähiges Clientsystem mehrere Anwendungskonnektoren verwendet, dann kann es die erhaltenen Ereignisbenachrichtigungen anhand der Subscription-ID einem Mandanten zuordnen.
	Topic	Topic der Ereignisnachricht
	Type	Typ der Ereignisnachricht (Security, Operation, Infrastructure)
	Severity	Schwere der Ereignisnachricht (Info, Warning, Error, Fatal)
	SubscriptionID	Identifikator der Anmeldung, der vom Konnektor bei der Operation Subscribe für die Anmeldung des jeweiligen Clientsystems vergeben wurde.
	Message	Dieses Element enthält die Ereignisnachricht. Der Inhalt ist abhängig vom Topic und wird mittels „Key-Value“-Parametern übertragen.
	Message/Parameter/Key	Name des Parameters (String), case sensitiv
	Message/Parameter/Value	Wert des Parameters (String)
Hinweise	Das XML-Dokument MUSS UTF-8-codiert sein.

​​

[<=]

4.1.6.2 Durch Ereignisse ausgelöste Reaktionen

Keine.

4.1.6.3 Interne TUCs, nicht durch Fachmodule nutzbar

Keine.

4.1.6.4 Interne TUCs, auch durch Fachmodule nutzbar

4.1.6.4.1 TUC_KON_256 „Systemereignis absetzen“

TIP1-A_4598-02 - TUC_KON_256 „Systemereignis absetzen“

Der Konnektor MUSS für den PUSH-Mechanismus des Systeminformationsdienstes den technischen Use Case TUC_KON_256 „Systemereignis absetzen” umsetzen.
 

Tabelle 138: TAB_KON_556 - TUC_KON_256 „Systemereignis absetzen“ 

Element	Beschreibung
Name	TUC_KON_256 „Systemereignis absetzen“
Beschreibung	Dieser TUC verteilt ein Ereignis im Konnektor intern (d.h. an Basisdienste und Fachmodule) sowie an Clientsysteme, die sich für den Empfang angemeldet haben (Operation Subscribe). Zusätzlich wird, bei gesetztem Flag, das Ereignis durch den Protokollierungsdienst protokolliert.
Auslöser	Aufruf durch Basisdienst oder Fachmodul
Vorbedingungen	Fall Topic = „BOOTUP/BOOTUP_COMPLETE": Zu allen URLs von clientseitigen Endpunkten, wie sie bei der Subscribe-Operation angegeben wurden, ist in der Subscription-Verwaltung des Konnektors eine TerminationTime gespeichert. Sie wird jeweils auf den Wert der TerminationTime der am längsten gültigen Subscription zu dem jeweiligen Endpunkt gesetzt. Die URLs von clientseitigen Endpunkten müssen bis zum Ablauf  ihrer TerminationTime auch über Bootups hinweg gespeichert werden. Vor dem Versenden des BOOTUP_COMPLETE-Events werden sämtliche Subscriptions, jedoch nicht die URLs gelöscht.  Bei Ablauf ihrer TerminationTime werden nach dem Versenden des BOOTUP_COMPLETE-Events auch die URLs gelöscht.
Eingangsdaten	Attribute des zu versendenden Ereignisses:        topic (Name des Ereignisses)        eventType [EventType]       (Wenn statt eines EventType ein ErrorType übergeben wird, so wird       der EventType daraus abgeleitet.       Typ des Events: Op = Operation, Sec = Security, Infra = Infrastructure)        severity [EventSeverity] (Schwere des Ereignisses: Info = Information, Warn = Warning, Err = Error, Fatal)        parameters (weitere Parameter als key-value-Paare)        Arbeitsanweisungen:        doLog [Boolean] – optional; default = true (Schalter „Schreibe Protokolleintrag“)        doDisp [Boolean] – optional; default = true (Schalter „An Clientsysteme versenden“) Die Bezeichnungen Op, Sec, Infra, Info, Warning, Err, Fatal werden nur in diesem Dokument verwendet und sind als Abkürzungen für die Werte Operation, Security, Infrastructure, Information, Warning, Error, Fatal in den jeweiligen Ereignisnachrichten gemäß Schema EventService.xsd zu verstehen.
Komponenten	Konnektor
Ausgangsdaten	Keine
Nachbedingungen
Standardablauf	Für das übergebene Ereignis werden folgende Schritte durchgeführt:   1. Das Ereignis wird an alle Basisdienste und Fachmodule des        Konnektors gesendet.   2. Wenn doLog = true, erfolgt der Aufruf von TUC_KON_271 {              eventType = $Event.eventType                 (mit eventType = „Op“, wenn $Event.eventType in {„Op“, „Infra“}                  mit eventType = „Sec“, wenn $Event.eventType gleich "Sec")             severity=$Event. severity;             parameters= ($Event.topic, $Event.parameters) }        Die Einschränkungen zur Protokollierung personenbezogener Daten        gemäß TIP1-A_4710 müssen beim Aufruf von TUC_KON_271        beachtet werden.   3. Falls doDisp = false ist, wird an dieser Stelle abgebrochen.   4. Das für den Versand an Clientsysteme benötigte XML-Dokument des         Ereignisses wird aufgebaut (Element „Event“ gemäß         EventService.XSD).   5. Setze $subscriptionList = Liste der Clientsystem-Abonnements, die         durch die Operationen Subscribe/Unsubscribe gepflegt werden und         deren TerminationTime > Systemzeit.         Im Folgenden durchläuft diese Liste der Reihe nach drei Filter. Nach        dem letzten Filterschritt enthält $subscriptionList nur noch die         Abonnements, an die das Ereignis versendet werden soll.   a.             Filtern nach Topics:         für jede $subscription in $subscriptionList {              wenn $event.topic nicht mit $subscription.topic beginnt                     oder übereinstimmt (case insensitiver Vergleich),              dann entferne $subscription aus $subscriptionList         }   b.            Filtern nach Zugriffsberechtigung:         für jede $subscription in $subscriptionList {               wenn TUC_KON_000 mit einem Fehler abgeschlossen                wird,  dann entferne $subscription aus $subscriptionList.            Wenn CardHandle bzw. CARD_HANDLE in parameters übergeben wurde, dann                 TUC_KON_000 {                      mandantId = $subscription.context.mandantId;                      clientSystemId = $subscription.context.clientsystemId;                      workplaceId = $subscription.context.workplaceId;                      ctId = $parameters.value                              für $parameters.key = „ctId“                      cardHandle = $parameters.value                                         für $parameters.key = [„cardHandle“ | "CARD_HANDLE"];                      needCardSession = false;                      allWorkplaces = false                 }              oder im Fall nicht gegebenes CardHandle bzw. CARD_HANLDE                 TUC_KON_000 {                     mandantId = $subscription.context.mandantId;                     clientSystemId = $subscription.context.clientsystemId;                     workplaceId = $subscription.context.workplaceId;                     ctId = $parameters.value                             für $parameters.key = „ctId“                     needCardSession = false;                     allWorkplaces = false                 }    }   c.           Filtern nach XPath-Filter in Subscription ([XPATH]):        für jede $subscription in $subscriptionList {             wenn der XPath-Ausdruck $subscription.filter                  angewandt auf das als XML-Dokument dargestellte                  Ereignis                  ein leeres Ergebnis liefert,             dann entferne $subscription aus $subscriptionList        } 6. Versenden:    für jede $subscription in $subscriptionList {       versende das Ereignis an $subscription.eventTo     } Für das versendete Ereignis wird keine Antwort durch das Clientsystem erwartet.
Varianten/ Alternativen	Fall Topic = „BOOTUP/BOOTUP_COMPLETE": 4.        Das für den Versand an Clientsysteme benötigte XML-Dokument     des Ereignisses wird aufgebaut (Element „Event“ gemäß     EventService.XSD, SubscriptionID als leeres Element). 5.        Setze $urlList = Liste der URLs von clientseitigen Endpunkten, wie     sie bei der Subscribe-Operation angegeben wurden. Clientsysteme,     deren Subscription-URL beim Einschalten des Konnektors noch nicht     gelöscht waren, müssen benachrichtigt werden, auch wenn dann     bereits deren TerminationTime < Systemzeit ist. Versenden: für jede $url in $urlList {    versende das Ereignis an $url } Für das versendete Ereignis wird keine Antwort durch das Clientsystem erwartet. Dadurch wird bei einer Nichtzustellung auch kein erneuter Versand des Ereignisses angestoßen, da der Konnektor keine Kenntnis über den Erfolg einer Ereignisübermittlung hat.
Fehlerfälle	Fehler in den folgenden Schritten des Standardablaufs führen zum Abbruch mit den ausgewiesenen Fehlercodes:   (5c)    Fehler bei der Auswertung des XPath-Ausdrucks:                 Fehlercode: 4095, nur für die jeweilige Abonnement-Prüfung.
Fachliche Fehlermeldung	Keine
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	Abbildung PIC_KON_112 Aktivitätsdiagramm zu „Systemereignis absetzen“

Abbildung 12: PIC_KON_112 Aktivitätsdiagramm zu „Systemereignis absetzen“ 

Tabelle 139: TAB_KON_557 Fehlercodes TUC_KON_256 „Systemereignis absetzen“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4095	Technical	Error	Fehler bei der Auswertung eines XPath-Ausdruck

[<=]

4.1.6.4.2 TUC_KON_252 „Liefere KT_Liste“

TIP1-A_4599 - TUC_KON_252 „Liefere KT_Liste”

Der Konnektor MUSS den technischen Use Case TUC_KON_252 „Liefere KT_Liste” umsetzen.
 

Tabelle 140: TAB_KON_558 – TUC_KON_252 „Liefere KT_Liste“ 

Element	Beschreibung
Name	TUC_KON_252 „Liefere KT_Liste“
Beschreibung	Dieser TUC liefert eine Liste der Kartenterminals, die unter Beachtung der Eingangsdaten verfügbar/erreichbar sind.
Auslöser	Aufruf durch ein Clientsystem (Operation GetCardTerminals) oder ein Fachmodul
Vorbedingungen	Keine
Eingangsdaten	workplaceId - optional (Arbeitsplatz ID) clientSystemId (Clientystem ID) mandantId (Mandanten ID)
Komponenten	Konnektor, Kartenterminal
Ausgangsdaten	cardTerminals (Liste der Kartenterminals, die den angegebenen Arbeitsplätzen, Mandanten und Clientsystemen zugeordnet sind bzw. auf die diese zugreifen dürfen (siehe Zugriffsberechtigungsdienst), sowie deren aktuelle Verfügbarkeit. Verfügbarkeit bedeutet im Falle eines eHealth-Kartenterminals, dass der Konnektor eine Verbindung zum Kartenterminal aktuell hält.)
Nachbedingungen	Der Zustand der Kartenterminals bleibt unverändert
Standardablauf	Erstellen der Liste aller Kartenterminals, auf die der angegebene Mandant und das angegebene Clientsystem zugreifen dürfen (siehe Zugriffsberechtigungsdienst)          Wurde der optionale Parameter workplaceId ID übergeben, so werden nur die Kartenterminals in die Liste aufgenommen, die diesem Arbeitsplatz zugeordnet sind (siehe Zugriffsberechtigungsdienst). Dazu zählen insbesondere nicht die als entfernte Kartenterminals bezeichneten KT.          Fehlt dieser Parameter, so werden alle Kartenterminals in die Liste aufgenommen, die sowohl dem Clientsystem als auch dem Mandanten zugeordnet sind. Rückgabe der Liste cardTerminals (der in Schritt 1 erstellten Liste) mit Angaben zu jedem Kartenterminal gemäß Schema „Eventservice.xsd“.
Varianten/Alternativen	Keine
Fehlerfälle	Keine
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	Keine

[<=]

4.1.6.4.3 TUC_KON_253 „Liefere Karten_Liste“

TIP1-A_4600 - TUC_KON_253 „Liefere Karten_Liste”

Der Konnektor MUSS den technischen Use Case TUC_KON_253 „Liefere Karten_Liste” umsetzen.
 

Tabelle 141: TAB_KON_559 – TUC_KON_253 „Liefere Karten_Liste“ 

Element	Beschreibung
Name	TUC_KON_253 „Liefere Karten_Liste“
Beschreibung	Dieser TUC liefert eine Liste der gesteckten Karten, die unter Beachtung der Eingangsdaten verfügbar/erreichbar sind.
Auslöser	Aufruf durch ein Clientsystem (Operation GetCards) oder ein Fachmodul
Vorbedingungen	Keine
Eingangsanforderung	Keine
Eingangsdaten	workplaceId – optional (Arbeitsplatz-ID)                     clientSystemId (Clientystem ID)                     cardTerminalId - optional; verpflichtend, wenn slotId übergeben wird (Kartenterminalidentifikator)                     slotId – optional (Nummer des Slots, beginnend bei 1)                     mandantId (Mandanten ID)                     cardType – optional (Kartentyp gemäß Tabelle TAB_KON_500)
Komponenten	Konnektor, Kartenterminal, Karte
Ausgangsdaten	cards (Liste der gesteckten Karten einschließlich der Informationen für CARD:card, auf die der Mandant und das Clientsystem von dem Arbeitsplatz aus zugreifen dürfen (siehe Zugriffsberechtigungsdienst)). Wird workplaceId nicht übergeben, so werden alle vom Clientsystem und dem Mandant erreichbaren Kartenterminals in die Liste aufgenommen. Die Eingangsdaten dienen als Filter, welche Karten in cards zurückgegeben werden. Beispiel: Falls cardTerminalId angegeben ist, werden nur Karten in die Liste aufgenommen, die im entsprechenden Kartenterminal stecken.)
Nachbedingungen	Der Zustand der Kartenterminals und der Karten bleibt unverändert
Standardablauf	Erstellen der Liste aller Karten, auf die der angegebene Mandant und das angegebene Clientsystem zugreifen dürfen (siehe Zugriffsberechtigungsdienst).         Wurde cardTerminalId übergeben, dann nur Karten berücksichtigen, die dem dadurch referenziertem Kartenterminal zugeordnet sind.         Wurde außer cardTerminalId auch slotId übergeben, so ist nur die Karte zu berücksichtigen, die in dem angegebenen Slot steckt.         Wurde workplaceId übergeben, so werden nur die Karten in die Liste aufgenommen, auf die von diesem Arbeitsplatz aus zugegriffen werden darf (siehe „Zugriffsberechtigung Ressourcen“).         Wurde cardType übergeben, so werden nur die Karten in die Liste aufgenommen, die dem Kartentyp in CardType entsprechen. Rückgabe cards, der in Schritt 1 erstellten Liste mit Angaben zu jeder Karte gemäß Schema „Eventservice.xsd“.
Varianten/ Alternativen	Keine
Fehlerfälle	Fehler in den folgenden Schritten des Standardablaufs führen zum Abbruch mit den ausgewiesenen Fehlercodes: (1 a)    Ungültige Kartenterminal-ID: Fehlercode: 4007
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	Keine

 

Tabelle 142: TAB_KON_560 Fehlercodes TUC_KON_253 „Liefere Karten_Liste“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4007	Technical	Error	ungültige Kartenterminal-ID

[<=]

4.1.6.4.4 TUC_KON_254 „Liefere Ressourcendetails“

TIP1-A_4602 - TUC_KON_254 „Liefere Ressourcendetails”

Der Konnektor MUSS den technischen Use Case TUC_KON_254 „Liefere Ressourcendetails” umsetzen.
 

Tabelle 143: TAB_KON_561 - TUC_KON_254 „Liefere Ressourcendetails“ 

Element	Beschreibung
Name	TUC_KON_254 „Liefere Ressourcendetails“
Beschreibung	Dieser TUC liefert Detailinformationen zu einer Ressource (KT, Karte) oder dem Konnektor
Auslöser	Aufruf durch ein Clientsystem (Operation GetResourceInformation) oder ein Fachmodul
Vorbedingungen	Keine
Eingangsanforderung	Keine
Eingangsdaten	clientSystemId (Clientsystem ID)                     mandantId (Mandanten ID)                     workplaceId – optional (Arbeitsplatz ID)                     cardTerminalId – optional (Kartenterminal ID)                     slotId – optional/zulässig nur, wenn auch cardTerminalId angegeben ist (Kartenslot-Nummer)                     cardHandle – optional                     iccsn – optional
Komponenten	Konnektor, Kartenterminal, Karte, HSM
Ausgangsdaten	resource (Informationsobjekt einer Ressource (Kartenterminal, Karte, HSM))
Nachbedingungen	Der Zustand der Kartenterminals, Karten und HSM bleibt unverändert
Standardablauf	Falls cardTerminalId und slotId übergeben wurde oder in den Eingangsparametern iccsn oder cardHandle enthalten ist, wird ein Informationsobjekt der Karte, die sich in dem angegebenen Slot befindet bzw. die über die Iccsn oder das CardHandle identifiziert werden kann, zurückgegeben. Falls cardTerminalId, aber keine slotId übergeben wurde, wird ein Informationsobjekt des Kartenterminals zurückgegeben. Wurde weder iccsn, cardHandle, cardTerminalId noch eine slotId übergeben, so wird ein Informationsobjekt des Konnektors zurückgegeben. Für das Element ErrorCondition ist aus der Tabelle TAB_KON_503 Betriebszustand_Fehlerzustandsliste der Text aus der Spalte ErrorCondition zu übernehmen, ggf. mit den in dieser Spalte angegebenen Parameterwerten. Vor der Rückgabe der Informationen über eine Ressource wird geprüft, ob der angegebene Mandant und das angegebene Clientsystem darauf zugreifen dürfen (siehe Zugriffsberechtigungsdienst). Wurde zusätzlich der optionale Parameter workplaceId übergeben, so wird auch geprüft, ob die Ressource diesem Arbeitsplatz zugeordnet ist. Die Rückgabe der Informationen erfolgt gemäß dem Schema „Eventservice.xsd“.
Varianten/ Alternativen	Keine
Fehlerfälle	Fehler in den folgenden Schritten des Standardablaufs führen zum Abbruch mit den ausgewiesenen Fehlercodes: (1)    Ungültige Kartenterminal-ID: Fehlercode: 4007 (1)    Ungültige Kartenslot-ID: Fehlercode: 4097 (1)    Keine Karte im angegebenen Slot: Fehlercode: 4098 (1)    Keine Karte mit angegebener Iccsn gefunden: Fehlercode: 4099 (1)    Karten-Handle ungültig: Fehlercode: 4101 (2)    Ungültige Kartenterminal-ID: Fehlercode: 4007
Nichtfunktionale Anforderungen	Keine
Zugehörige Diagramme	Keine

 

Tabelle 144: TAB_KON_562 Fehlercodes TUC_KON_254 „Liefere Ressourcendetails“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4007	Technical	Error	ungültige Kartenterminal-ID
4097	Technical	Error	ungültige Kartenslot-ID
4098	Technical	Error	keine Karte im angegebenen Slot gefunden
4099	Technical	Error	keine Karte zur angegebenen Iccsn gefunden
4101	Technical	Error	Karten-Handle ungültig

[<=]

4.1.6.5 Operationen an der Außenschnittstelle

TIP1-A_4603-02 - Basisanwendung Systeminformationsdienst

Der Konnektor MUSS für Clients eine Basisanwendung Systeminformationsdienst anbieten.
 

Tabelle 145 TAB_KON_029 Basisanwendung Systeminformationsdienst 

Name	EventService
Version	7.2.0 (WSDL-Version) 7.2.1 (XSD-Version)
Namensraum	Siehe GitHub
Namensraum-Kürzel	EVT für Schema und EVTW für WSDL
Operationen	Name	Kurzbeschreibung
	GetCardTerminals	Auflistung der verfügbaren Kartenterminals
	GetCards	Auflistung der gesteckten Karten
	GetResourceInformation	Liefert Details zu einer Ressource (Kartenterminal, Karte, HSM)
	Subscribe	Anmeldung der Zustellung von Ereignissen
	Unsubsribe	Abmelden von der Zustellung von Ereignissen
	RenewSubscriptions	Gültigkeit bestehender Subscriptions verlängern
	GetSubscriptions	Abfrage der angemeldeten Zustellungen von Ereignissen
WSDL	EventService.wsdl
Schema	EventService.xsd

[<=]

4.1.6.5.1 GetCardTerminals

TIP1-A_4604 - Operation GetCardTerminals

Der Konnektors MUSS an der Außenschnittstelle eine Operation GetCardTerminals, wie in Tabelle TAB_KON_563 „Operation GetCardTerminals“ beschrieben, anbieten.

Tabelle 146: TAB_KON_563 Operation GetCardTerminals

Name	GetCardTerminals
Beschrei-bung	Liefert die Liste der Kartenterminals, auf die der aufrufende Mandant und das aufrufende Clientsystem zugreifen dürfen (siehe Zugriffsberechtigungsdienst) sowie deren aktuelle Verfügbarkeit. Verfügbarkeit bedeutet im Falle eines eHealth-Kartenterminals, dass der Konnektor eine Verbindung zum Kartenterminal aktuell hält.
Aufruf-parameter
	Name		Beschreibung
	@mandant-wide		Wenn „true“, werden alle Kartenterminals zurückgegeben, auf die der Mandant und das aufrufende Clientsystem zugreifen dürfen. Wenn „false“ (Standardbelegung), werden nur Kartenterminals zurückgegeben, auf die von dem im Aufrufkontext spezifizierten Arbeitsplatz zugegriffen werden darf.
	Context		Aufrufkontext
Rückgabe
	Name		Beschreibung
	Status		Ergebnis der Operation
	Die Liste der Kartenterminals
	Name	Beschreibung
	Product Information	Produktinformationen gemäß [gemSpec_OM] und dem Schema „ProductInformation.xsd“ zu formatieren.
	CtId	Eineindeutige Identifikation des Kartenterminals
	WorkplaceIds	Die Liste der Arbeitsplätze, denen das Kartenterminal als lokales Kartenterminal zugeordnet ist. Insbesondere für Entfernte Kartenterminals kann diese Liste leer sein (siehe TUC_KON_252).
	Name	Sprechender Name des Kartenterminals
	MacAddress	MAC-Adresse des Kartenterminals
	IPAddress	IP-Adresse des Kartenterminals
	Slots	Anzahl der Slots des Kartenterminals
	IS_PHYSICAL	Attribut des Kartenterminals das anzeigt ob es sich um ein physisches oder logisches Kartenterminal handelt (siehe auch TAB_KON_522 Parameterübersicht des Kartenterminaldienstes)
	Connected	Zeigt an, ob dieses Kartenterminal aktuell verfügbar ist. TRUE – ist verfügbar FALSE – ist nicht verfügbar
Vorbedingungen	Keine
Nachbedingungen	Der Zustand der Kartenterminals bleibt unverändert.
Hinweise	Der Aufruf DARF nur den im Konnektor verwalteten, aktuellen Zustand des Kartenterminals liefern und DARF NICHT Abfragen an die Kartenterminals absetzen.

Der Ablauf der Operation GetCardTerminals ist in Tabelle TAB_KON_564 Ablauf GetCardTerminals beschrieben:

Tabelle 147: TAB_KON_564 Ablauf GetCardTerminals

Nr.	Aufruf Technischer Use Case oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
2.	TUC_KON_000 „Prüfe Zugriffs- berechtigung“	Prüfung der Zugriffsberechtigung durch den Aufruf TUC_KON_000 {       mandantId = $context.mandantId;       clientSystemId = $context.clientsystemId;       workplaceId = $context.workplaceId;       needCardSession = false;       allWorkplaces = @mandant-wide } Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.
3.	TUC_KON_252 „Liefere KT_Liste“	Die Liste der Kartenterminals wird erstellt und zurückgegeben. Tritt hierbei ein Fehler auf, so bricht die Operation mit dem Fehler des TUCs ab. Wenn @mandant-wide=true dann ermittle die Liste der Kartenterminals für alle Arbeitsplätze des Mandanten für das angegebene Clientsystem durch den Aufruf von TUC_KON_252{     clientSystemId = $context.ClientSystemId;     mandantId = $context.mandantId } Wenn @mandant-wide=false dann ermittle die Liste der Kartenterminals für den Arbeitsplatz des Mandanten für das angegebene Clientsystem entsprechend $context durch den Aufruf von TUC_KON_252{     workplaceId = $context.workplaceId;     clientSystemId = $context.ClientSystemId;     mandantId = $context.mandantId }

 

Tabelle 148: TAB_KON_823 Fehlercodes „GetCardTerminals“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler

​​

[<=]

4.1.6.5.2 GetCards

TIP1-A_4605 - Operation GetCards

Der Konnektors MUSS an der Außenschnittstelle eine Operation GetCards, wie in Tabelle TAB_KON_565 „Operation GetCards“ beschrieben, anbieten und MUSS dabei Kartentypen aus Tabelle TAB_KON_500 Wertetabelle Kartentypen unterscheiden.

Tabelle 149: TAB_KON_565 Operation GetCards 

Name	GetCards
Beschreibung	Liefert Informationen zu den in den Kartenterminals verfügbaren Karten zurück, die in Kartenterminals stecken, auf die Mandant und Clientsystem zugreifen dürfen. Insbesondere umfasst die Information die sog. Karten-Handles. Die Karten-Handles können bei anderen Konnektoraufrufen zur Adressierung von Karten genutzt werden.
Aufrufparameter
	Name	Beschreibung
	@mandant- wide	Wenn „true“, werden alle Karten zurückgegeben, auf die der Mandant und das aufrufende Clientsystem zugreifen dürfen. Wenn „false“ (Standardbelegung), werden nur Karten zurückgegeben, auf die von dem im Aufrufkontext spezifizierten Arbeitsplatz zugegriffen werden darf.
	Context	Aufrufkontext
	CtId	Identifikation des Kartenterminals. Wenn angegeben, werden nur die Karten zurückgeliefert, die in diesem Kartenterminal verfügbar sind.
	SlotId	Nummer des Slots, beginnend bei 1. Wird zusätzlich zur CtId auch SlotId übergeben, so wird die Karte zurückgegeben, die in dem angegebenen Slot des mit CtId adressierten Kartenterminals steckt.
	CardType	Ein Kartentyp gemäß Tabelle TAB_KON_500 „Wertetabelle Kartentypen“ als optionaler Filter. Wenn angegeben, werden nur Karten vom spezifizierten Typ zurückgegeben. Unterstützt werden die Kartentypen EGK, KVK, HBAx, SM-B, SMC-KT und UNKNOWN.
Antwort
	Name	Beschreibung
	Status	Ergebnis der Operation
	Im Element Cards wird die Liste der gesteckten Karten zurückgegeben. Für jede Karte wird dabei ein Card-Element angegeben. Leere Slots der Kartenterminals sind in dieser Liste nicht enthalten.
	Name		Beschreibung
	Card Handle		Handle, mit dem die Karte in Folgeaufrufen adressiert werden kann. Der Konnektor garantiert, dass dieses Handle die gesteckte Karte eindeutig identifiziert und bei Entfernen der Karte aus dem Kartenterminal ungültig wird. Auch für nicht erkannte Karten (z. B. bei falscher Steckrichtung der Karte) SOLL der Konnektor gültige Handles liefern (sofern das Kartenterminal in diesem Fall in der Lage ist, das entsprechende Ereignis „Karte wurde gesteckt“ zu liefern), damit diese Karten z. B. zum Auswurf adressiert werden können.
	CardType		Erkannter Typ der Karte. Siehe Tabelle TAB_KON_500 Wertetabelle Kartentypen,
	Card Version		Der Konnektor MUSS in CardVersion bei eGK, HBA und SM-B/SMC-KT der Generation 2 die Versionsinformationen gemäß [gemSpec_Karten_Fach_TIP] übergeben, für G1+ aus /MF/EF.Version. Bei KVK, HBA-VK und unbekannten Karten MUSS das Element weggelassen werden.
	Iccsn		Falls auslesbar, die ICC-Serial-Number der Karte. Im Fall der KVK wird das optionale Element Iccsn nicht zurückgegeben.
	CtId		Identifikation des Kartenterminals, in dem die Karte steckt.
	SlotId		Nummer des Slots (beginnend bei 1), in dem die Karte steckt.
	InsertTime		Gibt den Zeitpunkt an, zu dem der Konnektor die Karte erkannt hat. Die Zeit wird mit dem Datentyp DateTime in folgendem Format angegeben: yyyy-mm-ddThh:mm:ss+hh:mm Es ist also – gemäß ISO 8601 [ISO8601] – die lokale Zeit und die Differenz zur UTC anzugeben.
	CardHolder Name		Name des Karteninhabers bzw. der Institution/Organisation (subject.commonName). Bei KVK und unbekannten Karten MUSS das Element weggelassen werden.
	Kvnr		KVNR (Unveränderbarer Teil) MUSS bei eGK belegt werden. Bei allen anderen Karten MUSS das Element weggelassen werden.
	Certificate Expiration Date		Ablaufdatum des Zertifikates (AUT bzw. OSIG). Bei KVK und unbekannten Karten MUSS das Element weggelassen werden.
Vorbedingungen	Keine.
Nachbedingungen	Der Zustand der Karten und der Kartenterminals bleibt unverändert.
Hinweise	Der Aufruf darf nur den im Konnektor verwalteten aktuellen Zustand der Karte liefern und keine Abfragen an die Kartenterminals absetzen.

Der Ablauf der Operation GetCards ist in Tabelle TAB_KON_566 Ablauf GetCards beschrieben:
 

Tabelle 150: TAB_KON_566 Ablauf GetCards 

Nr.	Aufruf Technischer Use Case oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
2.	TUC_KON_000 „Prüfe Zugriffsberechtigung“	Die Prüfung erfolgt durch den Aufruf TUC_KON_000 {       mandantId = $context.mandantId;       clientSystemId = $context.clientsystemId;       workplaceId = $context.workplaceId;       needCardSession = false;       allWorkplaces = @mandant-wide} Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.
3.	TUC_KON_253 „Liefere Karten_Liste“	Die Liste der Karten wird erstellt und zurückgegeben. Tritt hierbei ein Fehler auf, so bricht die Operation mit dem Fehler des TUCs ab. Wenn @mandant-wide=true dann ermittle die Liste der Karten für alle Arbeitsplätze des Mandanten für das angegebene Clientsystem durch den Aufruf TUC_KON_253 „Liefere Karten_Liste“ {     clientSystemId = $context.clientsystemId;     cardTerminalId = CtId;     slotId = SlotId;     mandantId = $context.mandantId;     cardType = CardType } Wenn @mandant-wide=false dann ermittle die Liste der Karten für den Arbeitsplatz des Mandanten für das angegebene Clientsystem entsprechend $context durch den Aufruf TUC_KON_253 „Liefere Karten_Liste“ {     workplaceId= $context.workplaceId;     clientSystemId = $context.clientsystemId;     cardTerminalId = CtId;     slotId = SlotId;     mandantId = $context.mandantId;     cardType = CardType }

Die Fehlerfälle der Operation GetCards sind in Tabelle TAB_KON_567 Fehlercodes „GetCards dargestellt:
 

Tabelle 151: TAB_KON_567 Fehlercodes „GetCards“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weiteren Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler

[<=]

4.1.6.5.3 GetResourceInformation

TIP1-A_4607 - Operation GetResourceInformation

Der Konnektors MUSS an der Außenschnittstelle eine Operation GetResourceInformation, wie in Tabelle TAB_KON_568 „Operation GetResourceInformation“ beschrieben, anbieten.
 

Tabelle 152: TAB_KON_568 Operation GetResourceInformation 

Name	GetResourceInformation
Beschreibung	Gibt Informationen zu einer Ressource (Karte, KT) oder dem Konnektor selbst zurück
Aufrufparameter
	Name	Beschreibung
	Context	Aufrufkontext
	CtId	Identifikator eines Kartenterminals
	SlotId	Kartenslot-Nummer (in Kombination mit CtId)
	Iccsn	Iccsn einer Karte
	CardHandle	CardHandle einer Karte. Unterstützt werden die Kartentypen EGK, KVK, HBAx, SM-B, SMC-KT und UNKNOWN.
	Wurde keines der Elemente CtId, SlotId, Iccsn übergeben, so wird davon ausgegangen, dass der Aufrufer Informationen zum Konnektor selbst abfragen möchte.
Rückgabe
	Name	Beschreibung
	Status	Ergebnis der Operation
	Card	Informationen einer Karte (siehe GetCards)
	CardTerminal	Informationen eines Kartenterminals (siehe GetCardTerminals)
	Connector	Informationen zum Konnektor
	VPNTIStatus
	VPNTIStatus/ ConnectionStatus	Status der VPN-Verbindung zur TI (Online oder Offline)
	VPNTIStatus/ Timestamp	Zeitstempel der letzten Statusänderung
	VPNSISSTatus
	VPNSISStatus/ ConnectionStatus	Status der VPN-Verbindung des SIS (Online oder Offline)
	VPNSISStatus/ Timestamp	Zeitstempel der letzten Statusänderung
	OperatingState	Betriebszustand (siehe Kapitel 3.3)
	OperatingState/ ErrorState	Eine Zeile der Fehlerzustandsliste gemäß Tabelle TAB_KON_503 Betriebszustand_Fehlerzustandsliste
	OperatingState/ ErrorState/ ErrorCondition	ErrorCondition gemäß Tabelle TAB_KON_503 Betriebszustand_Fehlerzustandsliste
	OperatingState/ ErrorState/Severity	Schwere des Fehlerzustandes gemäß Tabelle TAB_KON_503 Betriebszustand_Fehlerzustandsliste
	OperatingState/ ErrorState/Type	Fehlertyp gemäß Tabelle TAB_KON_503 Betriebszustand_Fehlerzustandsliste
	OperatingState/ ErrorState/Value	Fehlerzustandswert
	OperatingState/ ErrorState/ValidFrom	Zeitstempel der letzten Änderung des Fehlerzustands
Vorbedingung
Nachbedingung	Der Zustand der Ressource bleibt unverändert.
Hinweise

Der Ablauf der Operation GetResourceInformation ist in Tabelle TAB_KON_569 Ablauf GetResourceInformation beschrieben:
 

Tabelle 153: TAB_KON_569 Ablauf GetResourceInformation 

Nr.	Aufruf Technischer Use Case oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Insbesondere wird geprüft, dass eine SlotId nur in Verbindung mit einer CtId übergeben werden kann (Abfrage einer Karte). Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
2.	TUC_KON_000 „Prüfe Zugriffs- berechtigung“	Die Prüfung erfolgt, falls die Ressource der Konnektor ist, durch den Aufruf TUC_KON_000 {     mandantId = $context.mandantId;     clientSystemId = $context.clientsystemId;     workplaceId = $context.workplaceId;     ctId = null;     cardHandle = null;     needCardSession = false;     allWorkplaces = true } falls die Ressource ein Kartenterminal ist, durch den Aufruf TUC_KON_000 {     mandantId = $context.mandantId;     clientSystemId = $context.clientsystemId;     workplaceId = $context.workplaceId;     ctId = $ctId;     cardHandle = null;     needCardSession = false;     allWorkplaces = true } falls die Ressource eine Karte ist, durch den Aufruf TUC_KON_000 {     mandantId = $context.mandantId;     clientSystemId = $context.clientsystemId;     workplaceId = $context.workplaceId;     ctId = null;     cardHandle = $cardHandle;     needCardSession = false;     allWorkplaces = false } Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.
3.	TUC_KON_254 „Liefere Ressourcendetails“	Die Informationen zu der Ressource werden zusammengetragen und zurückgegeben. Tritt hierbei ein Fehler auf, so bricht die Operation mit dem Fehler des TUCs ab.

Die Fehlerfälle der Operation GetResourceInformation sind in Tabelle TAB_KON_570 Fehlercodes „GetResourceInformation dargestellt:
 

Tabelle 154: TAB_KON_570 Fehlercodes „GetResourceInformation“ 

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weiteren Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler

[<=]

4.1.6.5.4 Subscribe

TIP1-A_4608 - Operation Subscribe

Der Konnektors MUSS an der Außenschnittstelle eine Operation Subscribe, wie in Tabelle TAB_KON_571 Operation Subscribe beschrieben, anbieten.

Tabelle 155: TAB_KON_571 Operation Subscribe

Name	Subscribe
Beschreibung	Clientsysteme melden mit dieser Operation ihr Interesse an bestimmten Topics (Ereignissen) an.
Aufrufparameter
	Name		Beschreibung
	Context		Aufrufkontext
	SubscriptionID		Darf nicht verwendet werden
	TerminationTime		Darf nicht verwendet werden
	EventTo		URL des Endpunkts, wo die Ereignisse zugestellt werden sollen. Syntax: cetp://host:port host: IP-Adresse oder FQDN des Clientsystems. port: Portnummer des Kommunikationsendpunkts, an dem das Clientsystem auf die Zustellung der Ereignisse wartet.
	Topic		Ein Topic, für das das Clientsystem sein Interesse anmeldet.
	Filter		Filter für die Ereignisnachricht (X-Path Ausdruck im Kontext mit Default Namespace gleich "http://ws.gematik.de/conn/EventService/v7.2" ohne Verwendung eines Namespace-Präfixes sowie Namensraum mit Präfix EVT gleich "http://ws.gematik.de/conn/EventService/v7.2", der beim Versand von Ereignissen in TUC_KON_256 ausgewertet wird. Ermöglicht die Filterung auf Basis der Elemente einer XML-Ereignisnachricht)
Rückgabe
	Name	Beschreibung
	Status	Ergebnis der Operation
	SubscriptionID	Ein Identifikator, der die Anmeldung für die Topics eindeutig identifiziert. Bei den Operationen Unsubscribe, GetSubscription und RenewSubsriptions MUSS dieser SubscriptionID angegeben werden.
	TerminationTime	Maximaler Gültigkeitszeitpunkt der Subscription. Sie MUSS auf Systemzeit + 25 h gesetzt werden.
Vorbedingung	Das Clientsystem muss die Ereignissenke realisieren.
Nachbedingung	Nach erfolgreicher Anmeldung vermerkt der Konnektor das angemeldete Topic unter dem SubscriptionID. Der Konnektor muss die Anmeldungen so lange als gültig behandeln, bis entweder das Clientsystem diese explizit abmeldet oder der Konnektor das Clientsystem als nicht mehr erreichbar erkennt (siehe nächsten Punkt) oder der Konnektor neu gestartet oder ausgeschaltet wird oder die TerminationTime kleiner als die Systemzeit ist. Der Konnektor muss die Anmeldung aus seiner Verwaltung entfernen („Auto-Unsubscribe“), wenn EVT_MAX_TRY Verbindungsaufbauversuche oder zählbare Zustellungsversuche (z.B. durch Zählung beim Absenden der Zustellversuche) in Folge fehlgeschlagen sind. Wenn die Ereignissenke Zustellungen grundsätzlich nicht beantwortet, so sind nur die Verbindungsaufbauversuche zu zählen.
Hinweise

Der Ablauf der Operation Subscribe ist in Tabelle TAB_KON_572 Ablauf Subscribe beschrieben:

Tabelle 156: TAB_KON_572 Ablauf Subscribe

Nr.	Aufruf Technischer Use Case oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
2.	TUC_KON_000 „Prüfe Zugriffs- berechtigung“	Die Prüfung erfolgt durch den Aufruf TUC_KON_000 _000 {     mandantId = $context.mandantId;     clientsystemId  = $context.clientsystemId;     workplaceId = $context.workplaceId;     needCardSession = false;     allWorkplaces = true } Tritt bei der Prüfung ein Fehler auf, so bricht die Operation mit dem Fehlercode aus TUC_KON_000 ab.
3.	saveSubscription	Die Anmeldung wird im Konnektor hinterlegt. Vorgehalten werden folgende Daten:                     SubscriptionId (wird generiert)                     TerminationTime (Systemzeit + 25h)                     MandantId                     ClientsystemId                     WorkplaceId                     Ereignissenke (Feld EventTo)                     Abonnierter Topic (Feld Topic)                     Filterausdruck (Feld Filter) Bei der Übernahme wird eine eindeutige SubscriptionId generiert, die dem aufrufenden System zurückgegeben wird, falls die Subscription noch nicht existiert. Existiert sie bereits, wird die bestehende SubscriptionID zurückgegeben.

Die Fehlerfälle der Operation Subscribe sind in Tabelle TAB_KON_573 Fehlercodes „Subscribe dargestellt:

Tabelle 157 TAB_KON_573 Fehlercodes „Subscribe“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weiteren Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler

​​

[<=]

4.1.6.5.5 Unsubscribe

TIP1-A_4609 - Operation Unsubscribe

Der Konnektors MUSS an der Außenschnittstelle eine Operation Unsubscribe, wie in Tabelle TAB_KON_574 Operation Unsubscribe beschrieben, anbieten.

Tabelle 158: TAB_KON_574 Operation Unsubscribe

Name	Unsubscribe
Beschreibung	Löscht eine Anmeldung mit dem angegebenen SubscriptionID oder alle Anmeldungen zu einem Endpunkt EventTo.
Aufrufparameter
	Name		Beschreibung
	Context		Aufrufkontext
	SubscriptionID		Der Identifikator, der bei der Subscribe-Operation geliefert wurde.
	EventTo		URL des clientseitigen Endpunkts, wie er bei der Subscribe-Operation angegeben wurde.
Rückgabe
	Name	Beschreibung
	Status	Ergebnis der Operation
Vorbedingung	Die Anmeldung Subscribe muss vor dieser Operation aufgerufen worden sein.
Nachbedingung	Der Konnektor entfernt aus seiner Verwaltung die Subscription zur Subscription-ID bzw. alle Subscriptions zur clientseitigen URL des Endpunkts EventTo.
Hinweise	Keine

Der Ablauf der Operation Unsubscribe ist in Tabelle TAB_KON_575 Ablauf Unsubscribe beschrieben:

Tabelle 159: TAB_KON_575 Ablauf Unsubscribe

Nr.	Aufruf Technischer Use Case oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
2.	TUC_KON_000 „Prüfe Zugriffs- berechtigung“	Die Prüfung erfolgt durch den Aufruf TUC_KON_000 {       mandantId = $context.mandantId;       clientsystemId  = $context.clientsystemId;       workplaceId = $context.workplaceId;       needCardSession = false;       allWorkplaces = true } Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.
3.	removeSubscription	Entfernen der Subscriptions aus der Liste aller Subscriptions.

Die Fehlerfälle der Operation Unsubscribe sind in Tabelle TAB_KON_576 Fehlercodes „Unsubscribe dargestellt:

Tabelle 160: TAB_KON_576 Fehlercodes „Unsubscribe“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weiteren Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler
4102	Technical	Error	ungültige SubscriptionId

​​

[<=]

4.1.6.5.6 RenewSubscriptions

TIP1-A_5112 - Operation RenewSubscriptions

Der Konnektors MUSS an der Außenschnittstelle eine Operation RenewSubscriptions, wie in Tabelle TAB_KON_792 Operation RenewSubscriptions beschrieben, anbieten.

Tabelle 161: TAB_KON_792 Operation RenewSubscriptions

Name	RenewSubscriptions
Beschreibung	Verlängert die Gültigkeit einer Liste von Anmeldungen, die jeweils per SubscriptionID identifiziert werden.
Aufrufparameter
	Name		Beschreibung
	Context		Aufrufkontext
	Subscription ID		Der Identifikator, der bei der Subscribe-Operation geliefert wurde.
Rückgabe
	Name	Beschreibung
	Status	Ergebnis der Operation
	Subscription ID	Ein Identifikator, der die Anmeldung für die Topics eindeutig identifiziert. Bei den Operationen Unsubscribe, GetSubscription und RenewSubsriptions MUSS diese SubscriptionID angegeben werden.
	Termination Time	Maximaler Gültigkeitszeitpunkt der Subscription. Sie MUSS auf Systemzeit + 25 h gesetzt werden.
Vorbedingung
Nachbedingung	Der Konnektor speichert jede neu vergebene TerminationTime in seiner Verwaltung der Subscriptions.
Hinweise	Keine

Der Ablauf der Operation RenewSubscriptions ist in Tabelle TAB_KON_793 Ablauf RenewSubscriptions beschrieben:

Tabelle 162: TAB_KON_793 Ablauf RenewSubscriptions

Nr.	Aufruf Technischer Use Case oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
2.	TUC_KON_000 „Prüfe Zugriffs- berechtigung“	Die Prüfung erfolgt durch den Aufruf TUC_KON_000 {       mandantId = $context.mandantId;       clientsystemId  = $context.clientsystemId;       workplaceId = $context.workplaceId;       needCardSession = false;       allWorkplaces = true } Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.
3.	renewSubscriptions	Es wird eine neue SubscribeRenewals-Liste angelegt. Alle Subscriptions, deren TerminationTime kleiner als die Systemzeit sind, muss der Konnektor aus der Verwaltung entfernen. Für jede SubscriptionID, die in der Verwaltung der Subscriptions existiert und deren TerminationTime größer als die Systemzeit ist, wird eine neue TerminationTime = Systemzeit + 25h bestimmt. Diese wird zusammen mit der SubscriptionID als SubscribeRenewal der SubscribeRenewals-Liste hinzugefügt. Kommt es zu keiner Subscription-Verlängerung, weil nur ungültige SubscriptionIDs im Aufruf angegeben waren, wird der Fehler 4102 zurückgeliefert. Kommt es zu mindestens einer Subscription-Verlängerung, sind aber auch ungültige SubscriptionIDs im Aufruf, wird eine RenewSubscriptionsResponse zurückgeliefert, mit CONN:Status/CONN:Result = "Warning", GERROR:Trace mit {Fehlercode: 4102, ErrorType: Technical, Severity: Error, Fehlertext: "Ungültige SubscriptionId"}, und der Information, welche SubscriptionsIDs ungültig waren.

Die Fehlerfälle der Operation RenewSubscriptions sind in Tabelle TAB_KON_794 Fehlercodes „RenewSubscriptions dargestellt:

Tabelle 163: TAB_KON_794 Fehlercodes „RenewSubscriptions“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weiteren Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler
4102	Technical	Error	Ungültige SubscriptionId

​​

[<=]

4.1.6.5.7 GetSubscription

TIP1-A_4610 - Operation GetSubscription

Der Konnektor MUSS an der Außenschnittstelle eine Operation GetSubscription, wie in Tabelle TAB_KON_577 Operation GetSubscription beschrieben, anbieten.

Tabelle 164: TAB_KON_577 Operation GetSubscription

Name	GetSubscription
Beschreibung	Gibt die Liste der angemeldeten Topics zurück
Aufrufparameter
	Name	Beschreibung
	@mandant-wide	Wenn „true“, werden alle Subscriptions zurückgegeben, die Mandant und Clientsystem zugeordnet sind. Wenn „false“ (Standardbelegung) werden alle Subscriptions zurückgegeben, die dem im Aufrufkontext spezifizierten Tripel aus Clientsystem, Mandanten und  Arbeitsplatz zugeordnet sind.
	Context	Aufrufkontext
	SubscriptionID	Der Identifikator, der bei der Subscribe-Operation geliefert wurde.
Rückgabe
	Name	Beschreibung
	Status	Ergebnis der Operation
	Subscriptions	Die Liste Subscriptions (vgl. Operation Subscribe)
	Subscription	Angefordertes Subscription-Element
	Subscription/ SubscriptionID	Identifikator der Subscription
	Subscription/ TerminationTime	Maximaler Gültigkeitszeitpunkt der Subscription.
	Subscription/ EventTo	URL des Endpunkts, wo die Ereignisse zugestellt werden sollen (Ereignissenke)
	Subscription/ Topic	Angemeldeter Topic
	Subscription/ Filter	Filterausdruck (falls vorhanden)
Vorbedingung	Keine
Nachbedingung	Die Liste der Subscriptions bliebt unverändert
Hinweise	Keine

Der Ablauf der Operation GetSubscription ist in Tabelle TAB_KON_578 Ablauf GetSubscription beschrieben:

Tabelle 165: TAB_KON_578 Ablauf GetSubscription

Nr.	Aufruf Technischer Use Case oder Interne Operation	Beschreibung
1.	checkArguments	Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
2.	TUC_KON_000 „Prüfe Zugriffs- berechtigung“	Die Prüfung erfolgt durch den Aufruf TUC_KON_000 {     mandantId = $context.mandantId;     clientsystemId  = $context.clientsystemId;     workplaceId = $context.workplaceId;     needCardSession = false;     allWorkplaces = @mandant-wide } Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.
3.	getSubscriptions	Rückgabe der Subscription, die durch SubscriptionId identifiziert wird. Wurde keine SubscriptionId angegeben und @mandant-wide="true", werden alle Subscriptions zurückgegeben, die dem angegebenen Clientsystem und Mandanten zugeordnet werden können. Wurde keine SubscriptionId angegeben und @mandant-wide="false", werden alle Subscriptions zurückgegeben, die dem angegebenen Clientsystem, Mandanten und Arbeitsplatz zugeordnet werden können.

Die Fehlerfälle der Operation GetSubscription sind in Tabelle TAB_KON_579 Fehlercodes „GetSubscription dargestellt:

Tabelle 166: TAB_KON_579 Fehlercodes „GetSubscription“

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weiteren Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler
4102	Technical	Error	ungültige SubscriptionId

​​

[<=]

4.1.6.6 Betriebsaspekte

TIP1-A_4611 - Konfigurationswerte des Systeminformationsdienstes

Die Managementschnittstelle MUSS es einem Administrator ermöglichen Konfigurationsänderungen gemäß Tabelle TAB_KON_580 vorzunehmen:

 

Tabelle 167: TAB_KON_580 Konfigurationswerte des Systeminformationsdienstes (Administrator)

ReferenzID	Belegung	Bedeutung und Administrator-Interaktion
EVT_MAX_TRY	Nummer	Der Administrator MUSS über diesen Konfigurationsparameter die Anzahl der Fehlversuche bzgl. Verbindungsversuche bzw. Ereigniszustellungen festlegen können.   Ist diese maximal zulässige Anzahl der Fehlversuche überschritten, muss der Konnektor automatisch ein „Auto-Unsubscribe“ (analog Operation „Unsubscribe“ mit „EventTo gleich der URL des clientseitigen Endpunkts“) durchführen.

 

[<=]

TIP1-A_4612 - Maximale Anzahl an Subscriptions

Der Konnektor MUSS eine Mindestmenge von 999 Subscriptions insgesamt unterstützen. Der Konnektorhersteller kann jedoch die Anzahl der maximal möglichen Subscriptions (insgesamt und/oder pro Ziel) festlegen.

[<=]

TIP1-A_4613 - Initialisierung Subscriptions-Liste beim Bootup

Der Konnektor MUSS beim Bootup mit einer leeren Liste an Subscriptions starten.

[<=]

4.1.7 Verschlüsselungsdienst

Der Verschlüsselungsdienst bietet Schnittstellen zum hybriden und symmetrischen Ver- und Entschlüsseln von Dokumenten an.

Der Verschlüsselungsdienst bietet für alle Alle_DocFormate die hybride und symmetrische Ver- und Entschlüsselung nach dem Cryptographic Message Syntax (CMS) Standard an [RFC5652].

Darüber hinaus werden folgende formaterhaltende Ver-/Entschlüsselungsmechanismen unterstützt:

• hybride Ver-/Entschlüsselung von XML-Dokumenten nach der W3C Recommendation „XML Encryption Syntax and Processing“ [XMLEnc]

Der Konnektor kann optional folgende formaterhaltende Ver-/Entschlüsselungsmechanismen unterstützen:

• hybride Ver-/Entschlüsselung von MIME-Dokumenten nach dem S/MIME-Standard [S/MIME]

Dabei soll der Konnektor, wenn er die S/MIME-Verschlüsselung unterstützt, auch die S/MIME-Entschlüsselung unterstützen.

Der Konnektor muss bezüglich der zur Ver- und Entschlüsselung von Dokumenten verwendeten Verfahren und Algorithmen die Vorgaben in [gemSpec_Krypt#3.1.4] sowie in [gemSpec_Krypt#3.1.5] und hinsichtlich ECC-Migration die Vorgaben aus [gemSpec_Krypt#5] erfüllen.

4.1.7.1 Funktionsmerkmalweite Aspekte

TIP1-A_4614 - Missbrauchserkennung Verschlüsselungsdienst

Der Konnektors MUSS zur Unterstützung von Missbrauchserkennungen die in Tabelle TAB_KON_581 gelisteten Operationen als Einträge in EVT_MONITOR_OPERATIONS berücksichtigen.

 

Tabelle 168: TAB_KON_581 Verschlüsselungsdienst-Operationen für EVT_MONITOR_OPERATIONS

Operationsname	OK_Val	NOK_Val	Alarmwert (Default-Grenzwert 10 Minuten-Σ)
EncryptDocument	1	5	101
DecryptDocument	1	5	101

 

[<=]

TIP1-A_5434 - Verschlüsselung/Entschlüsselung eines XML Dokuments ergibt unverändertes XML-Dokument

Der Konnektor MUSS das Operationspaar Verschlüsselung/Entschlüsselung so implementieren, dass Dokumente vom Typ XML unverändert bleiben, wobei zwei XML-Dokumente als identisch zu betrachten sind, wenn sie gemäß Canonical XML 1.1 gleich sind [CanonXML1.1]. [<=]

A_17746 - Einsatzbereich und Vorgaben für Ver- und Entschlüsselung (ECC-Migration)

Der Konnektor MUSS für die kartenbasierte Ver- und Entschlüsselung die Zertifikate und Schlüssel in Abhängigkeit vom kryptographischen Verfahren unter Berücksichtigung des Einsatzbereiches aus TAB_KON_747 ermitteln. [<=]

Tabelle 169: TAB_KON_747 KeyReference für Encrypt-/DecryptDocument 

Karte	KeyReference	Crypt	Zertifikat (Encrypt) ...in DF.ESIGN	Schlüssel (Decrypt) ...in DF.ESIGN	Einsatzbereich
					Außen-schnittstelle	Fachmodul-schnittstelle
HBA	C.ENC	RSA_ECC	EF.C.HP.ENC.R2048 EF.C.HP.ENC.E256	PrK.HP.ENC.R2048 PrK.HP.ENC.E256	Ja	Ja
		ECC	EF.C.HP.ENC.E256	PrK.HP.ENC.E256	Ja	Ja
		RSA	EF.C.HP.ENC.R2048	PrK.HP.ENC.R2048	Ja	Ja
SM-B	C.ENC	RSA_ECC	EF.C.HCI.ENC.R2048 EF.C.HCI.ENC.E256	PrK.HCI.ENC.R2048 PrK.HP.ENC.E256	Ja	Ja
		ECC	EF.C.HCI.ENC.E256	PrK.HP.ENC.E256	Ja	Ja
		RSA	EF.C.HCI.ENC.R2048	PrK.HCI.ENC.R2048	Ja	Ja
HBA-VK	C.ENC	RSA_ECC RSA	EF.C.HP.ENC	PrK.HP.ENC	Ja	Ja
eGK	C.ENC	ECC	C.CH.ENC.E256	PrK.CH.ENC.E256	Nein	Ja
	C.ENC	RSA	C.CH.ENC.R2048	PrK.CH.ENC.R2048	Nein	Ja

Tabelle 170: TAB_KON_859 Werteliste und Defaultwert des Parameters crypt bei hybrider Verschlüsselung 

4.1.7.2 Durch Ereignisse ausgelöste Reaktionen

Keine.

4.1.7.3 Interne TUCs, nicht durch Fachmodule nutzbar

Keine.

4.1.7.4 Interne TUCs, auch durch Fachmodule nutzbar

Die in diesem Kapitel beschriebenen TUCs zur hybriden Ver- und Entschlüsselung werden den Fachmodulen und Außenoperationen angeboten. Die TUCs zur symmetrischen Ver-/Entschlüsselung werden den Fachmodulen angeboten. Es gibt keine Aufrufhierarchie innerhalb der hier beschriebenen TUCs zur hybriden und symmetrischen Ver-/Entschlüsselung.

4.1.7.4.1 TUC_KON_070 „Daten hybrid verschlüsseln”

TIP1-A_4616-03 - TUC_KON_070 „Daten hybrid verschlüsseln”

Der Konnektor MUSS den technischen Use Case TUC_KON_070 „Daten hybrid verschlüsseln” umsetzen.
 

Tabelle 171: TAB_KON_739 - TUC_KON_070 „Daten hybrid verschlüsseln“ 

Element	Beschreibung
Name	TUC_KON_070 „Daten hybrid verschlüsseln“
Beschreibung	Dieser TUC verschlüsselt ein Dokument oder Teile eines Dokumentes. Die Verschlüsselung erfolgt zweistufig, d. h. die Daten werden symmetrisch mit einem generierten Schlüssel verschlüsselt und anschließend wird dieser Schlüssel mit einem asymmetrischen Verfahren verschlüsselt. Die asymmetrische Verschlüsselung des symmetrischen Schlüssels kann für mehrere Identitäten, repräsentiert durch X.509-Zertifikate oder öffentliche Schlüssel, erfolgen. Das Ergebnis sind entsprechend viele Verschlüsselungen desselben symmetrischen Schlüssels. Es werden die folgenden formaterhaltenden Verschlüsselungsverfahren für die genannten Dokumententypen unterstützt: XML mit [XMLEnc] MIME mit [S/MIME] Des Weiteren ist für alle unterstützten Dokumentformate (Alle_DocFormate) die Verschlüsselung mit CMS [RFC5652] möglich.
Auslöser	Aufruf durch einen Fachmodul-TUC oder durch die Operation EncryptDocument des Verschlüsselungsbasisdienstes
Vorbedingungen	Falls mit einem öffentlichen Schlüssel auf einer Karte verschlüsselt werden soll, muss die Karte gesteckt sein.
Eingangsdaten	documentToBeEncrypted (Zu verschlüsselndes Dokument ) encryptionCertificates – optional/entfällt, wenn encryptionKeys übergeben wird (X.509v3-Zertifikate) encryptionKeys – optional/entfällt, wenn encryptionCertificates übergeben wird (öffentliche Schlüssel; unterstützte Karten sind SM-B, HBAx und eGK) encryptionType [EncryptionType] (Angaben zum einzusetzenden Verschlüsselungsverfahren (CMS, XMLEnc oder S/MIME)). cardSession – optional/verpflichtend, wenn ein Zertifikat von einer Karte gelesen werden soll (Kartensitzung; unterstützte Karten sind SM-B, HBAx und eGK.) certificateReference – optional/verpflichtend, wenn ein Zertifikat von einer Karte gelesen werden soll (Zertifikatsreferenz; unterstützte Karten sind SM-B, HBAx und eGK). crypt [ENC_CRYPT] - optional; default und Wertebereich siehe TAB_KON_859 (Wenn das Verschlüsselungszertifikat von einer Karte kommt, steuert crypt, mit welchen kryptographischen Verfahren die Verschlüsselung der Hybridschlüssel erfolgt.) xmlElements – optional/verpflichtend, wenn encryptionType  = XMLEnc (Festlegung der zu verschlüsselnden Teile des Dokumentes durch Spezifikation eines Xpath-Ausdruckes (XML-Elements). keyInfoMode [embedded | separate] – optional/verpflichtend, wenn encryptionType = XMLEnc (Angabe, ob die KeyInfo in das XML-Dokument eingebettet oder separat an den Aufrufer zurückgegeben werden soll)
Komponenten	Konnektor, Kartenterminal, Karte
Ausgangsdaten	encryptedDocument (Verschlüsseltes Dokument) encryptedKeys – optional/verpflichtend, wenn diese nicht im verschlüsselten Dokument enthalten sind (Verschlüsselte symmetrische Schlüssel) keyInfo – optional/verpflichtend, wenn encryptionType = XMLEnc  und keyInfoMode = separate (KeyInfo, falls nicht ins Dokument eingebettet)
Standardablauf	Es wird geprüft, ob encryptionCertificates die maximal unterstützte Anzahl überschreitet. Das Verschlüsselungsverfahren wird anhand des Eingangsparameters EncryptionType gewählt. Nur für XMLEnc: Die zu verschlüsselnden XML-Elemente werden lokalisiert. Falls kein zu verschlüsselndes XML-Element gefunden wurde, wird Fehler 4103 gemeldet. Die zu verschlüsselnden XML-Elemente dürfen nicht ineinander verschachtelt sein. Sind die zu verschlüsselnden XML-Elemente ineinander verschachtelt, so wird Fehler 4104 gemeldet. Für jedes von der Karte zu lesende Zertifikat, wird TUC_KON_216 „Lese Zertifikat” aufgerufen. Welches Zertifikat von der Karte gelesen werden soll, wird durch den Parameter crypt über Tabelle TAB_KON_747 gesteuert. In den Fällen crypt = RSA und crypt = ECC bricht der TUC ab, wenn dabei ein Fehler auftritt. Im Fall crypt = RSA_ECC bricht der TUC im Fehlerfall dann ab, wenn weder RSA- noch ECC-Zertifikat geladen werden konnte, und läuft mit einer Warnung durch, wenn nur ein Zertifikat geladen werden konnte. Falls Zertifikate übergeben oder von der Karte gelesen wurden, werden diese durch Aufruf von TUC_KON_037 „Zertifikat prüfen“ geprüft. Als Parameter des TUC-Aufrufs gilt für Zertifikate, die mit Zertifikaten  aus CERT_IMPORTED_CA_LIST geprüft werden: TUC_KON_037 „Zertifikat prüfen“ {     certificate =Zertifikat;     qualifiedCheck = not_required;     offlineAllowNoCheck = true;    intendedKeyUsage= intendedKeyUsage(Zertifikate  aus CERT_IMPORTED_CA_LIST);     validationMode = NONE } Für alle anderen Zertifikate gilt: {     certificate = [C.CH.ENC];     qualifiedCheck=not_required;     offlineAllowNoCheck=false;     policyList =[ oid_egk_enc];     intendedKeyUsage= intendedKeyUsage(C.CH.ENC);     validationMode=OCSP }   oder {     certificate = [C.CH.ENCV];     qualifiedCheck=not_required;     offlineAllowNoCheck=false;     policyList =[ oid_egk_encv ];     intendedKeyUsage= intendedKeyUsage(C.CH.ENCV);     validationMode=OCSP } oder {     certificate = [C.HCI.ENC];     qualifiedCheck=not_required;     offlineAllowNoCheck=false;     policyList =[ oid_smc_b_enc ];     intendedKeyUsage= intendedKeyUsage(C.HCI.ENC);     validationMode=OCSP } oder {     certificate = [C.HP.ENC];     qualifiedCheck=not_required;     offlineAllowNoCheck=false;     policyList =[ oid_hba_enc, oid_vk_pt_enc, oid_vk_eaa_enc ];     intendedKeyUsage= intendedKeyUsage(C.HP.ENC);     validationMode=OCSP } Die öffentlichen Schlüssel werden aus den Zertifikaten extrahiert, falls sie nicht direkt übergeben wurden. Falls ein Schlüssel keinen der zugelassenen Verschlüsselungsalgorithmen gemäß [gemSpec_Krypt#3.5.2] bzw. [gemSpec_Krypt#5.8] erlaubt, wird Fehler 4200 gemeldet. Der Konnektor generiert einen symmetrischen Schlüssel. Dabei muss der symmetrische Schlüssel den Kriterien aus [gemSpec_Krypt#2.4] entsprechen. Der Konnektor verschlüsselt das Dokument oder Teile des Dokuments mit dem generierten symmetrischen Schlüssel.         CMS: Es MÜSSEN die Vorgaben aus [gemSpec_Krypt#3.5.1] beachtet werden.         XMLEnc: Alle zu verschlüsselnden XML-Elemente werden mit demselben symmetrischen Schlüssel verschlüsselt. Dabei MÜSSEN die Vorgaben aus [gemSpec_Krypt#3.1.4] beachtet werden. Der symmetrische Schlüssel wird asymmetrisch für die einzelnen Identitäten verschlüsselt. Dabei müssen die Vorgaben aus [gemSpec_Krypt#3.1.5; 3.5.2; 5.8] beachtet werden. Das Zieldokument wird erstellt. XMLEnc Format und Inhalt des verschlüsselten Dokuments SOLLEN dem XML Encryption Format in [COMMON_PKI#Part 8] folgen. Zum Format des verschlüsselten XML-Dokumentes siehe auch Tabelle TAB_KON_073 Vorgaben zum Format verschlüsselter XML-Dokumente. Die verschlüsselten Datenelemente (EncryptedData) werden erstellt. EncryptedData ersetzt jeweils das zu verschlüsselnde Element des XML-Dokuments. In [COMMON_PKI] wird die Verwendung des Attributs Type in EncryptedData ausgeschlossen; diese Spezifikation sieht jedoch dessen Verwendung für verschlüsselte XML-Bestandteile (element, content) wie in [XMLEnc] beschrieben vor. Der Namespace von EncryptedData ist als http://www.w3.org/2001/04/xmlenc# anzugeben. Für das Element EncryptedData wird das Sub-Element EncryptionMethod mit Angaben zum Verschlüsselungsalgorithmus als obligatorisch vorgegeben, ebenso die Elemente KeyInfo und CipherData. Das Element EncryptedData/KeyInfo hat den Namespace "http://www.w3.org/2000/09/xmldsig#". Es muss pro Hybridschlüssel ein Element EncryptedKey enthalten. In jedem EncryptedKey-Element wird neben dem eigentlichen Hybridschlüssel ein Element zur EncryptionMethod der asymmetrischen Verschlüsselung und ein KeyInfo-Element mit dem Zertifikat angelegt, das für die Verschlüsselung des symmetrischen Schlüssels verwendete wurde. Das Zertifikat wird jeweils im Element EncryptedKey/KeyInfo/X509Data/X509Certificate base64-kodiert und darin DER-kodiert abgelegt. Hybridschlüssel (RSA): Das Element EncryptedData/KeyInfo/EncryptedKey muss die Verschlüsselungsmethode im Element EncryptionMethod angeben, den hybridSchlüssel im Element CipherData speichern und das Zertifikat, mit dem der symmetrische Schlüssel zum Hybridschlüssel verschlüsselt wurde, im Element EncryptedKey/KeyInfo/X509Data/X509Certificate base64-kodiert und darin DER-kodiert ablegen. Hybridschlüssel  (ECC): Es gelten die Vorgaben aus [gemSpec_Krypt#5.8] CMS: Es ist CMS mit Authenticated-Enveloped-Data Content Type gemäß [RFC-5083] und der AES-GCM-Encryption gemäß [RFC-5084] zu verwenden. Bei der Verschlüsselung des „content-encryption key“ wird die Technik „key transport“ eingesetzt. Pro Empfänger wird eine Instanz vom Typ KeyTransRecipientInfo erzeugt. Dabei ist für RecipientIdentifier die Option IssuerAndSerialNumber zu wählen. ContentType = OID {… authEnvelopedData}                     = 1.2.840.113549.1.9.16.1.23 Im Fall ECC sind die Vorgaben aus [gemSpec_Krypt#5.8] zur Erzeugung des Hybridschlüssels zu beachten. Im Fall RSA sind die Vorgaben aus [gemSpec_Krypt#3.5.2] zur Erzeugung des Hybridschlüssels zu beachten. Der symmetrische Schlüssel wird aktiv gelöscht (überschrieben).
Varianten/ Alternativen	Zur Rückgabe der Hybridschlüssel MUSS auch die Variante vorgesehen werden, dass die Hybridschlüssel („KeyInfo“) nicht eingebettet im Zieldokument zurückgegeben werden, sondern separat. Im Fall des Verschlüsselungsverfahrens S/MIME wird der Standardablauf des CMS Verschlüsselungsverfahrens durch einen vorgelagerten S/MIME-Vorbereitungsschritt und einen nachgelagerten S/MIME-Nachbereitungsschritt ergänzt. Das S/MIME-Verfahren MUSS konform [S/MIME] und SOLL konform [COMMON_PKI#Part 3] erfolgen. Der S/MIME-Vorbereitungsschritt bereitet das übergebene MIME-Dokument gemäß [S/MIME#3.1] auf die nachfolgende CMS-Verschlüsselung durch eine Kanonisierung für Text [S/MIME#3.1.1] vor. Eine weitere Kanonisierung oder eine Anpassung des Transfer Encodings [S/MIME#3.1.2] erfolgt nicht. Im S/MIME-Nachbereitungsschritt wird das im Standardablauf erzeugt CMS-Objekt in eine MIME-Nachricht vom Typ „application/pkcs7-mime“ eingebettet. Sämtliche Header-Felder der Nachricht MÜSSEN in die Header-Felder der S/MIME-Nachricht übernommen werden. Die im Folgenden explizit zu setzenden Header-Felder überschreiben die betroffenen Header-Felder. Es MUSS ein neues message-id Element für den S/MIME-Header generiert werden. "MIME-Version: 1.0" MUSS definiert sein. Das Feld "Subject" MUSS mit "Subject: Verschlüsselte Nachricht" überschrieben werden. Die Codierung des verschlüsselten Inhalts der Nachricht MUSS in "base64" erfolgen. Entsprechend ist das zugehörige Header-Feld zu füllen: "Content-Transfer-Encoding: base64". Das Feld "Content-Type:" ist als "application/pkcs7-mime" zu definieren. Die weiteren Attribute dieses Feldes sind:                     "smime-type=enveloped-data;"                     "name=$dateiname", wobei $dateiname auf ".p7m" endet. Das Feld "Content-Disposition" definiert den Inhalt der Nachricht als Dateianhang: "Content-Disposition: attachment; filename=$dateiname" Zu Schritten 6 und 9 für TI-fremde X.509-Zertifikate Der Konnektor MUSS beim asymmetrischen Anteil der hybriden Verschlüsselung auch TI-fremde X.509-Zertifikate unterstützen, wenn diese von einem CA-Zertifikat aus CERT_IMPORTED_CA_LIST ausgestellt wurden und die kryptographischen Vorgaben aus Tabelle  [gemSpec_Krypt#Tab_KRYPT_002] erfüllen. Der Konnektor MUSS Anfragen zur Hybridverschlüsselung mit einer Fehlermeldung (Fehler 4200) abweisen, wenn hierfür TI-fremde X509-Zertifikate vorgegeben werden, die nicht die kryptographischen Vorgaben aus Tabelle  [gemSpec_Krypt#Tab_KRYPT_002] oder [gemSpec_Krypt#Tab_KRYPT_002a] erfüllen.
Fehlerfälle	Siehe Tabelle TAB_KON_740 Fehlercodes TUC_KON_070 „Daten hybrid verschlüsseln“. Wenn im Ablauf des TUCs ein anderer Fehler als die in Tabelle TAB_KON_740 beschriebenen Fehler auftritt, wird Fehler 4105 gemeldet. (->1) maximale Anzahl von Empfängern überschritten: Fehlercode 4282 (->5) Schritt 5 – Zertifikatsprüfung „für alle anderen Zertifikate“ Für MGM_LU_ONLINE=Enabled gilt: Liefert die Zertifikatsprüfung (OCSP-Abfrage) mdt. eine der folgenden Warnungen gemäß [gemSpec_PKI#Tab_PKI_274] CERT_REVOKED CERT_UNKNOWN dann wird der TUC mit Fehler 4105 abgebrochen, Ausnahme: Falls im Falle crypt=RSA_ECC der Hybridschlüssel nur für eines der beiden Zertifikate erzeugt werden konnte, dann wird die Warnung 4259 mit <Zertifikat> gemäß TAB_KON_747 in der Response zurückgegeben.
Nichtfunktionale Anforderungen	keine
Zugehörige Diagramme	Abbildung PIC_KON_058 Aktivitätsdiagramm „Daten hybrid verschlüsseln“ Das Diagramm dient nur der Veranschaulichung und ist nicht vollständig. Beispielsweise enthält es nicht die Steuerung durch den Parameter crypt.