gemSpec_Kon_V5.22.0
Elektronische Gesundheitskarte und Telematikinfrastruktur
Spezifikation
Konnektor
Version | 5.22.0 |
Revision | 930629 |
Stand | 13.06.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.2017 |
Initialversion Online-Produktivbetrieb (Stufe 2.1) |
gematik |
|
5.2.0 |
18.12.2017 |
Einarbeitung Erratas 1.6.4-1 bis 1.6.4-3, P15.1 |
gematik |
|
5.3.0 |
14.05.2018 |
Einarbeitung P15.2, P15.4 und P15.5 |
gematik |
|
5.4.0 |
26.10.2018 |
Einarbeitung P15.8 und P15.9 |
gematik |
|
5.5.0 |
18.12.2018 |
Einarbeitung P17.1 |
gematik |
|
5.6.0 | 15.05.2019 | Einarbeitung P18.1 |
gematik |
|
5.7.0 | 28.06.2019 | Einarbeitung P19.1 |
gematik |
|
5.8.0 | 02.10.2019 | Einarbeitung P20.1/2 | gematik | |
5.9.0 | 02.03.2020 | Einarbeitung P21.1 | gematik | |
5.9.1 | 26.06.2020 | Einarbeitung P21.3 | gematik | |
5.9.2 | 27.08.2020 | Einarbeitung P21.4 | gematik | |
5.9.3 | 21.09.2020 | Einarbeitung P21.5 | gematik | |
5.9.4 | 05.11.2020 | Einarbeitung P21.6 | gematik | |
5.10.0 | 30.06.2020 | Einarbeitung P22.1 | gematik | |
5.11.0 | 12.11.2020 | Einarbeitung Scope-Themen zu R4.0.1 | gematik |
|
5.12.0 | 09.12.2020 | Einarbeitung P22.5 | gematik |
|
5.13.0 | 30.06.2021 | Einarbeitung Konn_Maintenance_21.1, _21.2, _21.3 und gemF_gSMC-K_Laufzeitverlängerung | gematik | |
5.14.0 | 02.09.2021 | Umbenennung der Begriffe "aAdG-NetG" in "WANDA Basic", "aAdG" und "aAdG-NetG-TI" in"WANDA Smart" |
gematik | |
5.15.0 | 31.01.2022 | 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.2022 | Einarbeitung Konn_Maintenance_22.1 (mit Ausbau der Änderungen aus gemF_gSMC-K_Laufzeitverlängerung) | gematik | |
5.17.0 | 30.06.2022 | Einarbeitung Konn_Maintenance_22.3 | gematik | |
5.18.0 | 28.11.2022 | Einarbeitung Konn_Maintenance_22.4, _22.5, _22.6, redaktionell: diskriminierungsfreie Sprache (Black-/Whitelist in Deny-/Allowlist) | gematik | |
5.19.0 | 14.04.2023 | Einarbeitung Konn_Maintenance_23.1 und gemF_gSMC-K_Laufzeitverlängerung | gematik | |
5.20.0 | 05.05.2023 | Einarbeitung Konn_Maintenance_23.2 | gematik | |
5.21.0 | 23.02.2024 | Einarbeitung TI-Gateway_Maintenance_23.1 | gematik | |
5.22.0 | 13.06.2024 | Änderungsliste HSK_Maintenance_24.1 |
Inhaltsverzeichnis
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:
Die XYZ müssen noch definiert werden. |
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:
- Funktionsmerkmalweite Aspekte
- Durch Ereignisse ausgelöste Reaktionen
- Interne TUCs, nicht durch Fachmodule nutzbar
- Interne TUCs, auch durch Fachmodule nutzbar
- Operationen an der Außenschnittstelle
- 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 |
|
Ausgangsdaten |
|
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
Fehlercode | ErrorType | Severity | Fehlertext |
---|---|---|---|
4280 | Security | Error | Dimensionierung des Dokuments nicht unterstützt |
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
Fehlercode | ErrorType | Severity | Fehlertext |
---|---|---|---|
4281 | Security | Error | Dokument enthält unzulässige Inhalte |
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
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
Identifier |
Verzeichnis |
Objekt der gSMC-K in Abhängikeit vom kryptographischen Verfahren | |
---|---|---|---|
RSA | ECC | ||
ID.NK.VPN | MF/DF.NK | EF.C.NK.VPN.R2048 | EF.C.NK.VPN2.XXXX |
ID.AK.AUT | MF/DF.AK | EF.C.AK.AUT.R2048 | EF.C.AK.AUT2.XXXX |
ID.SAK.AUT | MF/DF.SAK | EF.C.SAK.AUT.R2048 | EF.C.SAK.AUT2.XXXX |
C.SAK.AUTD_CVC | MF/DF.SAK | - | EF.C.SAK.AUTD_CVC.E256 |
[<=]
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“
Element |
Beschreibung |
---|---|
Name |
TUC_KON_410 "gSMC-K-Zertifikate aktualisieren" |
Beschreibung |
Dieser TUC bezieht neue gSMC-K-Zertifikate vom Downloadpunkt des TSP X.509 nonQES für Komponenten, oder diese werden vom Administrator übergeben. |
Auslöser |
A_21744, Administrator |
Vorbedingungen |
Automatische Aktualisierung:
|
Eingangsdaten |
Manuelle Aktualisierung:
|
Komponenten |
Konnektor, TSP Komponenten |
Ausgangsdaten |
Keine |
Standardablauf |
Automatische Aktualisierung:
eventType = Op; severity = Info; parameters = „$Parameters“; doLog = true; doDisp = true } |
Varianten/Alternativen |
(->3d,e) Es kann auch eine vollständige Zertifikatsprüfung gemäß
TUC_KON_037 „Zertifikat prüfen“{
certificate = Zertifikatsreferenz; qualifiedCheck = not_required; offlineAllowNoCheck = true; validationMode = OCSP} erfolgen. Manuelle Aktualisierung: (->1) Die Files mit den neuen Zertifikaten werden vom Administrator in den Konnektor importiert. (->2) Herstellerspezifisch, je nach Dateiformat (->3d) Die OCSP-Abfrage erfolgt nur wenn
|
Fehlerfälle |
(->1) Fehler beim Download: TUC_KON_256 { topic = „SMC_K/DOWNLOAD/ERROR“; eventType = Op; severity = Error; parameters = „$Parameters“; doLog = true; doDisp = true } (->2a) Wenn nicht alle erwarteten Zertifikate in der zip-Datei vorhanden sind oder ein Zertifikat nicht dekodiert werden kann: Fail=Incomplete Wenn eine der folgenden Prüfungen fehlschlägt, wird das bezogene Zertifikat verworfen und mit dem nächsten fortgesetzt: (->2a.i) Wenn C.SAK.AUTD_CVC nicht dem Profil CHAT.51 entspricht: Fail=Profile (->3a) ICCSN nicht gleich: Fail=Iccsn (->3b) Neues Ablaufdatum nicht später als altes Ablaufdatum: Fail=Date (->3c) Öffentlicher Schlüssel passt nicht zum privaten Schlüssel: Fail=Crypt (->3d) Zertifikat gesperrt oder unknown: Fail=Ocsp (->3e,f) Signaturprüfung fehlgeschlagen: Fail=Signature Bei automatischer Aktualisierung ab Schritt 2 bei jedem gefundenen Fehler: TUC_KON_256 { topic = „SMC_K/UPDATE/ERROR“; eventType = Op; severity = Error; parameters = „$Parameters“; doLog = true; doDisp = true } |
Nichtfunktionale Anforderungen | Keine |
Zugehörige Diagramme |
Keine |
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
- über einen Zugriffsschutz verfügt, sodass nur Berechtigte Schlüssel darauf nutzen können,
- in einem zutrittsgeschützten Bereich aufbewahrt wird und
- mindestens nach FIPS 140-2 Level 3 oder [COS-G2] (CC-zertifizierte Chipkarte der TI) zertifiziert ist.
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:
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
Ü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 |
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)“.
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
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
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 Clientsystem 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
- 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
Bei der Authentisierung des Clientsystems geht es um eine Authentisierung in zwei Richtungen:
- Authentisierung des Clientsystems in der Rolle eines Clients gegenüber dem Konnektor für die Übertragung von SOAP-Requests.
- 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:
- 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
- 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
[<=]
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 |
[<=]
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
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
Betriebs umgebung |
Konfigurations parameter |
Konfigurations wert |
Beschreibung |
---|---|---|---|
PU |
NET_TI_ ZENTRAL |
siehe [gemSpec_Net#Tab_ Adrkonzept_Produktiv] |
Siehe TAB_KON_680. Dieser Wert MUSS für den Administrator über die Managementschnittstelle einsehbar, DARF aber NICHT änderbar sein. |
NET_TI_ GESICHERTE_FD |
siehe [gemSpec_Net#Tab_ Adrkonzept_Produktiv] |
Siehe TAB_KON_680. Dieser Wert MUSS für den Administrator über die Managementschnittstelle einsehbar, DARF aber NICHT änderbar sein. |
|
NET_TI_ OFFENE_FD |
siehe [gemSpec_Net#Tab_ Adrkonzept_Produktiv] |
Siehe TAB_KON_680. Dieser Wert MUSS für den Administrator über die Managementschnittstelle einsehbar, DARF aber NICHT änderbar sein. |
|
DNS_TOP_ LEVEL_DOMAIN_TI |
telematik. |
Siehe TAB_KON_731. Dieser Wert MUSS für den Administrator über die Managementschnittstelle einsehbar, DARF aber NICHT änderbar sein. |
|
RU/TU |
NET_TI_ ZENTRAL |
siehe [gemSpec_Net# Tab_Adrkonzept_Test] |
Siehe TAB_KON_680. Dieser Wert MUSS für den Administrator über die Managementschnittstelle mit dem Konfigurationswert voreingestellt und änderbar sein. |
NET_TI_ GESICHERTE_FD |
siehe [gemSpec_Net# Tab_Adrkonzept_Test] |
Siehe TAB_KON_680. Dieser Wert MUSS für den Administrator über die Managementschnittstelle mit dem Konfigurationswert voreingestellt und änderbar sein. |
|
NET_TI_ OFFENE_FD |
siehe [gemSpec_Net# Tab_Adrkonzept_Test] |
Siehe TAB_KON_680. Dieser Wert MUSS für den Administrator über die Managementschnittstelle mit dem Konfigurationswert voreingestellt und änderbar sein. |
|
DNS_TOP_ LEVEL_ DOMAIN_TI |
telematik-test. |
Siehe TAB_KON_731. Dieser Wert MUSS für den Administrator über die Managementschnittstelle einsehbar, aber nicht änderbar sein. |
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 |
|
Komponenten |
Konnektor |
Ausgangsdaten |
|
Nachbedingungen |
|
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 |
|
Vorbedingungen |
keine |
Eingangsdaten |
|
Komponenten |
Konnektor |
Ausgangsdaten |
|
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:
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 |
|
Komponenten |
Konnektor, Fachmodule |
Ausgangsdaten |
|
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 |
|
Rückgabe |
Das Antwortdokument ist in der Schemadatei ServiceDirectory.xsd beschrieben. |
|
ConnectorServices |
||
Name |
Beschreibung |
|
ProductInformation |
Kurzbeschreibung des Konnektormodells |
|
ServiceInformation |
Beschreibung der Dienste |
|
ProductInformation: |
||
TLS-Mandatory: Boolean Wert der festlegt, ob die Verwendung eines TLS-Kanals für Dienstaufrufe verpflichtend ist. |
||
ServiceInformation: |
||
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:
|
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 }
rufenTUC_KON_256 {
topic = „CT/DISCONNECTED“;
eventType = Op;
severity = Info;
parameters = („CtID=$CT.CTID, Hostname=$CT.HOSTNAME“) }
auslösenCT.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“
Element |
Beschreibung |
---|---|
Name |
TUC_KON_050 „Beginne Kartenterminalsitzung“ |
Beschreibung |
TUC_KON_050 baut eine TLS-Verbindung vom Konnektor zum Kartenterminal auf und beginnt eine SICCT-Sitzung. Anschließend erfolgt die 2. Authentifizierung des Kartenterminals (Prüfung SharedSecret). |
Auslöser |
|
Vorbedingungen |
ctId ist in CTM_CT_LIST vorhanden |
Eingangsdaten |
|
Komponenten |
Konnektor, Kartenterminal |
Ausgangsdaten |
keine |
Nachbedingungen |
|
Standardablauf |
Setze CT = CTM_CT_LIST(ctId) 1. Wenn CT.IS_PHYSICAL = Nein: prüfen, ob role = „User“ Wenn CT.CONNECTED = Ja: TUC endet erfolgreich Nein: - Verbindung zu HSM in Slot 1 aufbauen - weiter mit Schritt 9 2. Wenn CT.CONNECTED = Ja prüfen, ob CT.ACTIVEROLE = role Ja: TUC endet erfolgreich Nein: - Schließen der Cardterminal Session mit dem Kartenterminalkommando SICCT CLOSE CT SESSION, - weiter ab Schritt 6 (halten der TLS-Verbindung und nur Wechsel der Session) 3. Aufbau einer TLS-Verbindung mit dem Kartenterminal unter Verwendung von ID.SAK.AUT. Dabei 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 } 4. Wenn CT.CORRELATION <=„zugewiesen“: a. Öffne eine Cardterminal Session mit dem Kartenterminalkommando SICCT INIT CT SESSION (siehe [SICCT#5.10]) mit leerem Username, Password und Session ID b. Nur Verbindung in niedriger Korrelation, daher setze CT.CONNECTED = Nein, um fachliche Nutzung des KT zu verhindert c. beende TUC erfolgreich 5. Prüfe, ob das Zertifikat aus der TLS-Verbindung mit den zum Kartenterminal gespeicherten Referenzdaten (CT.SMKT_AUT) übereinstimmt. a. Läuft das Zertifikat CT.SMKT_AUT (oder C.SMKT.AUT, sie müssen hier identisch sein) in weniger als 35 Tagen ab, so geht der Konnektor in den Betriebszustand EC_CardTerminal_gSMC-KT_Certificate_Expires_Soon (ctId) über. 6. Parallelisierung a. Generierung eines zufälligen Werts (Challenge) mit mindestens 16 Byte Länge gemäß [gemSpec_Krypt#2.2] (siehe [gemSpec_KT#DO_KT_0004]), b. Öffnen einer Cardterminal Session mit dem Kartenterminalkommando SICCT INIT CT SESSION (siehe [SICCT#5.10]) mit - ctId als Adressat - Wenn role = User dann mit leerem Username, Password und Session ID Wenn role = „Admin dann mit leerer Session ID aber mit CT.ADMIN_USERNAME und CT.ADMIN_PASSWORD 7. Senden der Challenge mittels Kartenterminalkommando EHEALTH TERMINAL AUTHENTICATE (siehe [gemSpec_KT#3.7.2]) in der Ausprägung VALIDATE mit: - Kartenterminal als Empfänger - und mit der in Schritt 6a generierten Challenge im Shared Secret Challenge DO 8. Prüfe Antwort des Kartenterminals, ob sie einen korrekten Hashwert über Challenge und angehängtes CT.SHARED_SECRET gemäß [gemSpec_KT#SEQ_KT_0002] Schritt 4-5 enthält 9. Setze: a. CT.ACTIVEROLE = $role b. CT.CONNECTED = Ja 10 . Wenn TLS-Verbindung neu aufgebaut werden musste, rufe TUC_KON_256 { topic = „CT/CONNECTED“; eventType = „Op“; severity = Info; parameters = („CtID=$CT.CTID, Hostname=$CT.HOSTNAME“) } 11. Ermittle alle im KT gesteckten Karten und befülle entsprechend CT.SLOTS_USED Für jeden in CT.SLOTS_USED gelisteten Slot X zur weiteren internen Bearbeitung TUC_KON_256{ topic = „CT/SLOT_IN_USE“; eventType = Op; severity = Info; parameters = („CtID=$CT.CTID, SlotNo=$CT.SLOTS_USED[X]“); doLog = false; doDisp = false } rufen. |
Varianten/ Alternativen |
Keine. |
Fehlerfälle |
Fehler in den folgenden Schritten des Ablaufs führen zu: Aufruf von TUC_KON_256 { topic = "CT/TLS_ESTABLISHMENT_FAILURE"; eventType = $ErrorType; severity = $Severity; parameters = („CtID=$CT.ID, Name=$CT.HOSTNAME, Error=$Fehlercode, Bedeutung=$Fehlertext“) } Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes (1): Admin-Rolle für logische KTs nicht möglich (hätte bei korrekter Implementierung nicht stattfinden dürfen), Fehlercode: 4032 (1): Verbindungsaufbau zu HSM fehlgeschlagen, Fehlercode: 4032 (3): Fehler im TLS-Verbindungsaufbau bzw. Zertifikatsprüfung, Fehlercode: 4028 und setze CT.CONNECTED auf „Nein“ (3): TLS-Verbindung konnte nicht innerhalb von CTM_TLS_HS_TIMEOUT Sekunden aufgebaut werden , Fehlercode: 4028 und setze CT.CONNECTED auf „Nein“ (5): Präsentiertes Zertifikat nicht das aus dem Pairing, Fehlercode: 4029 und setze CT.CORRELATION auf „gepairt“ und setze CT.CONNECTED auf „Nein“ und terminiere TLS-Verbindung (6b): Hinterlegte KT-Admin-Credentials fehlerhaft, Fehlercode: 4030 und in die User-Session zurückzuwechseln (damit das KT für den normalen Fachbetrieb weiterhin zur Verfügung steht) (8): Prüfung auf Nachweis SharedSecret fehlgeschlagen, Fehlercode 4029 und setze CT.CORRELATION auf „gepairt“ und setze CT.CONNECTED auf „Nein“ und terminiere TLS-Verbindung |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
Abbildung PIC_KON_110 Aktivitätsdiagramm zu „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 |
|
Vorbedingungen |
|
Eingangsdaten |
|
Komponenten |
Konnektor, Kartenterminal |
Ausgangsdaten |
|
Nachbedingungen |
|
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 |
|
Eingangsdaten |
|
Komponenten |
Konnektor, Kartenterminal |
Ausgangsdaten |
|
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 |
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 |
|
Vorbedingungen |
|
Eingangsdaten |
|
Komponenten |
Konnektor, Kartenterminal |
Ausgangsdaten |
|
Nachbedingungen |
|
Standardablauf |
Setze CT = CTM_CT_LIST(ctId)
zur dritten Stelle im gefundenen Eintrag: >=: Setze Result = True <: Setze Result = False Kein Eintrag gefunden: Setze Result = False
|
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 |
|
Eingangsdaten |
|
Komponenten |
Konnektor, Kartenterminal |
Ausgangsdaten |
|
Nachbedingungen |
Wenn Mode=OutputKeep bleibt Data auf dem Display des KT stehen |
Standardablauf |
Setze CT = CTM_CT_LIST(ctId)
|
Varianten/ Alternativen |
|
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 |
|
Nachbedingungen |
Im Erfolgsfall enthält die CM_CARD_LIST ein neues CARD-Objekt des geforderten Typs. |
Standardablauf |
Setze CT = CTM_CT_LIST(ctId)
In allen Fällen liegt in CM_CARD_LIST ein neues CARD-Objekt vor.
|
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 |
|
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)
|
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 |
|
Komponenten |
Konnektor |
Ausgangsdaten |
CT.DISPLAY_CAPABILITIES |
Nachbedingungen |
Keine |
Standardablauf |
Setze CT = CTM_CT_LIST(ctId)
|
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 |
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. |
Tabelle 56: TAB_KON_720 Ablauf EjectCard
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“ |
Ist $cardHandle vorgegeben, so wird $ctId als Id des Kartenterminals bestimmt, in dem die Karte steckt. Prüfung der Zugriffsberechtigung durch den Aufruf TUC_KON_000 { mandantId = $Context.MandantId; clientSystemId = $Context.ClientSystemId; workplaceId = $Context.WorkplaceId; ctId = $Slot.CtId bzw. ctId = CM_CARD_LIST($CardHandle).CTID; 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_057 „Karte auswerfen“ |
Wurde EjectCard mit dem Parameter Slot aufgerufen: Veranlassen des Kartenauswurfs am Kartenterminal durch Aufruf TUC_KON_057 { ctId = $Slot.CtId; slotId = $Slot.Slotid; displayMessage = $DisplayMsg; $timeOut } Wurde EjectCard mit dem Parameter CardHandle aufgerufen: Veranlassen des Kartenauswurfs am Kartenterminal durch Aufruf TUC_KON_057 { ctId = CM_CARD_LIST($CardHandle).CTID; slotId = CM_CARD_LIST ($CardHandle).SLOTNO; ; displayMessage = $DisplayMsg; $timeOut } |
Tabelle 57: TAB_KON_721 Fehlercodes Operation „EjectCard“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4000 |
Technical |
Error |
Syntaxfehler |
4203 |
Technical |
Error |
Karte deaktiviert, aber nicht entnommen |
4101 |
Technical |
Error |
Karten-Handle ungültig |
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:
- die zugehörigen Attribute CT.SLOTS_USED, CT.VALID_VERSION und ggf. (bei dynamischer Adressvergabe) CT.IP_ADRESS aktualisieren
- für jedes CT mit CT.CORRELATION = „aktiv“:
- Wenn CT.VALID_VERSION = True: TUC_KON_050 „Beginne Kartenterminalsitzung“ {ctId=CT.CtID; role=„User“} aufrufen
- 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:
|
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)
[<=]
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:
- Events (Topic Ebene 1): „CARD“
- 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
|
|
CARD. CERTOCSPRESPONSE |
OCSP-Response (TUC_KON_037) für
|
|
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
[<=]
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:
- das über die im Ereignis gemeldeten Parameter CtID und SlotNo in CM_CARD_LIST adressierte CardObject CARD identifizieren
- 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: -
- „CardHandle=$CARD.CARDHANDLE,
- Type=$CARD.TYP,
- CardVersion=$CARD.VER,
- ICCSN=$CARD.ICCSN,
- CtID=$CARD.CTID,
- SlotID=$CARD.SLOTID,
- InsertTime=$CARD.INSERTTIME,
- CardHolderName=$CARD.CARDHOLDERNAME,
- KVNR=$CARD.KVNR“
- „CardHandle=$CARD.CARDHANDLE,
- 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-01 - 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 = not_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“ {
eventType = Op;
severity = Warning;
parameters = („CARD_TYPE=$Type,
ICCSN=$ICCSN,
CARD_HANDLE=$CardHandle,
CardHolderName=$CardHolderName,
CertName=$Name von certificate,
ExpirationDate=$validity“
doDisp = true }
- Wenn MGM_LU_ONLINE= "Disabled",
TUC_KON_037 „Zertifikat prüfen“{
certificate = C.HCI.OSIG;
qualifiedCheck = not_required;
offlineAllowNoCheck = true;
validationMode = NONE }
und Systemereignis senden(SMC-B Status not available") TUC_KON_256 „Systemereignis absetzen“ {
eventType = Op;
severity = Warning;
parameters = („CARD_TYPE=$Type,
ICCSN=$ICCSN,
CARD_HANDLE=$CardHandle,
CardHolderName=$CardHolderName,
CertName=$Name von certificate,
ExpirationDate=$validity“,
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“ {
eventType = Op;
severity = Warning;
parameters = („CARD_TYPE=$Type,
ICCSN=$ICCSN,
CARD_HANDLE=$CardHandle,
CardHolderName=$CardHolderName,
CertName=$Name von certificate,
ExpirationDate=$validity“
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“ {
eventType = Op;
severity = Warning;
parameters = („CARD_TYPE=$Type,
ICCSN=$ICCSN,
CARD_HANDLE=$CardHandle,
CardHolderName=$CardHolderName,
CertName=$Name von certificate,
ExpirationDate=$validity“,
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 |
|
Eingangsdaten |
|
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 |
|
Vorbedingungen |
Keine |
Eingangsdaten |
|
Komponenten |
Konnektor |
Ausgangsdaten |
|
Standardablauf |
|
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 |
|
Vorbedingungen |
Karte unterstützt die übergebene pinRef |
Eingangsdaten |
|
Komponenten |
Karte, Kartenterminal, Konnektor |
Ausgangsdaten |
|
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 |
|
Vorbedingungen |
Karte unterstützt die übergebene pinRef |
Eingangsdaten |
|
Komponenten |
Karte, Kartenterminal, Konnektor |
Ausgangsdaten |
|
Standardablauf |
|
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 |
|
Vorbedingungen |
Karte unterstützt die übergebene pinRef |
Eingangsdaten |
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 |
|
Standardablauf |
|
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 |
|
Vorbedingungen |
Karte unterstützt die übergebene pinRef |
Eingangsdaten |
|
Komponenten |
Karte, Kartenterminal, Konnektor |
Ausgangsdaten |
|
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:
|
Auslöser |
|
Vorbedingungen |
Karte unterstützt die übergebene pinRef |
Eingangsdaten |
|
Komponenten |
Konnektor |
Ausgangsdaten |
|
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
pinRef |
ANW (max. 16 Zeichen) |
---|---|
MRPIN.NFD |
Notfalldaten |
MRPIN.DPE |
Pers.Erklärungen |
MRPIN.AMTS |
Medikationsdaten |
MRPIN.GDD |
PIN•GDD |
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 |
|
Vorbedingungen |
Keine |
Eingangsdaten |
|
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 |
|
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 |
|
Komponenten |
Karten, Konnektor, Kartenterminal |
Ausgangsdaten |
Keine |
Standardablauf |
|
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 |
|
Vorbedingungen |
Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen |
Eingangsdaten |
|
Komponenten |
Karte, Kartenterminal, Konnektor |
Ausgangsdaten |
|
Standardablauf |
|
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 |
|
Vorbedingungen |
Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen. |
Eingangsdaten |
|
Komponenten |
Karte, Kartenterminal, Konnektor |
Ausgangsdaten |
Keine |
Standardablauf |
|
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 |
|
Vorbedingungen |
Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen |
Eingangsdaten |
|
Komponenten |
Karte, Kartenterminal, Konnektor |
Ausgangsdaten |
keine |
Standardablauf |
|
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 |
|
Vorbedingungen |
Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen |
Eingangsdaten |
|
Komponenten |
Karte, Kartenterminal, Konnektor |
Ausgangsdaten |
|
Standardablauf |
|
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 |
|
Vorbedingungen |
Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen |
Eingangsdaten |
|
Komponenten |
Karte, Kartenterminal, Konnektor |
Ausgangsdaten |
keine |
Standardablauf |
|
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“
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 |
4088 |
Technical |
Error |
Datensatz zu groß |
4093 |
Technical |
Error |
Karte wird in einer anderen Kartensitzung exklusiv verwendet |
4094 |
Technical |
Error |
Timeout beim Kartenzugriff aufgetreten |
[<=]
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 |
|
Vorbedingungen |
Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen |
Eingangsdaten |
|
Komponenten |
Karte, Kartenterminal, Konnektor |
Ausgangsdaten |
keine |
Standardablauf |
|
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 |
|
Vorbedingungen |
Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen |
Eingangsdaten |
|
Komponenten |
Karte, Kartenterminal, Konnektor |
Ausgangsdaten |
keine |
Standardablauf |
|
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 |
|
Vorbedingungen |
Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen |
Eingangsdaten |
|
Komponenten |
Karte, Kartenterminal, Konnektor |
Ausgangsdaten |
|
Standardablauf |
|
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 |
|
Komponenten |
Konnektor, Kartenterminal, eGK |
Ausgangsdaten |
|
Standardablauf |
|
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“
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 |
[<=]
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 |
|
Komponenten |
eGK, HBA/SMC, Konnektor, Kartenterminal |
Ausgangsdaten |
Keine |
Standardablauf |
|
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 |
|
Vorbedingungen |
Zugriffsbedingung für referenzierten Schlüssel MUSS erfüllt sein |
Eingangsdaten |
|
Komponenten |
Karte, Kartenterminal, Konnektor |
Ausgangsdaten |
|
Standardablauf |
|
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 |
|
Vorbedingungen |
Zugriffsbedingung für referenzierten Schlüssel muss erfüllt sein |
Eingangsdaten |
|
Komponenten |
Karte(n), Kartenterminal, Konnektor |
Ausgangsdaten |
|
Standardablauf |
|
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 |
|
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 |
|
Komponenten |
Karte(n), Kartenterminal, Konnektor |
Ausgangsdaten |
|
Standardablauf |
A. cardSession ist gegeben
|
Varianten/Alternativen |
|
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 |
|
Komponenten |
Karte, Kartenterminal, Konnektor |
Ausgangsdaten |
Keine |
Standardablauf |
|
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“
Element |
Beschreibung |
---|---|
Name | TUC_KON_216 „LeseZertifikat“ |
Beschreibung | Dieser Use Case beschreibt das Lesen eines Zertifikates von einer Karte |
Auslöser |
|
Vorbedingungen | Keine |
Eingangsdaten |
|
Komponenten | Karte, Kartenterminal, Konnektor |
Ausgangsdaten |
|
Standardablauf |
|
Varianten/ Alternativen |
Keine |
Fehlerfälle | (2) Karte ist fremd reserviert, Fehlercode 4093 (->4) Es wurde versucht, ein Zertifikat von der Karte zu lesen, welches auf der Karte nicht vorhanden ist (Fehlercode 4256). Hierbei kann es sich um ein fehlendes Zertifikatsobjekt (z.B. adressiertes ECC-Zertifikat auf HBA G2.0) oder ein leeres Zertifikatsobjekt (z.B. adressiertes ECC-Zertifikat auf gSMC-K G2.0, welches aber nicht personalisiert wurde) handeln. |
Nichtfunktionale Anforderungen | Keine |
Zugehörige Diagramme | Keine |
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 |
|
Vorbedingungen |
Keine |
Eingangsdaten |
|
Komponenten |
Konnektor, Karte |
Ausgangsdaten |
|
Nachbedingungen |
Keine |
Standardablauf |
|
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“
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 |
4094 |
Technical |
Error |
Timeout beim Kartenzugriff aufgetreten |
4210 |
Technical |
Error |
ProfessionOIDs nicht eindeutig auf eine Rolle abbildbar |
[<=]
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:
|
||
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 |
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:
|
||
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:
|
|||
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:
|
||
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:
|
||
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 |
|
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:
- CARD.CTID
- CT(CARD.CTID).HOSTNAME
- CARD.SLOTNO
- CARD.TYPE
- CARD.INSERTTIME
- CARD.CARDHOLDERNAME
- 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“
[<=]
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. |
|
---|---|---|
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:
der EventType daraus abgeleitet. Typ des Events: Op = Operation, Sec = Security, Infra = Infrastructure)
|
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 |
|
Komponenten |
Konnektor, Kartenterminal |
Ausgangsdaten |
|
Nachbedingungen |
|
Standardablauf |
|
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 |
|
Komponenten |
Konnektor, Kartenterminal, Karte |
Ausgangsdaten |
|
Nachbedingungen |
|
Standardablauf |
|
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 |
|
Komponenten |
Konnektor, Kartenterminal, Karte, HSM |
Ausgangsdaten |
|
Nachbedingungen |
|
Standardablauf |
|
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. |
||
Context |
Aufrufkontext |
||
Rückgabe |
|||
Name |
Beschreibung |
||
Status |
Ergebnis der Operation |
||
|
|||
Name |
Beschreibung |
||
Product |
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 |
||
Connected |
Zeigt an, ob dieses Kartenterminal aktuell verfügbar ist. |
||
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 |
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. |
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. |
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 } |
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 |
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. |
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 |
||
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. |
||
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 |
3. |
saveSubscription |
Die Anmeldung wird im Konnektor hinterlegt. Vorgehalten werden folgende Daten:
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 |
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 |
Der Identifikator, der bei der Subscribe-Operation geliefert wurde. |
||
Rückgabe |
|||
Name |
Beschreibung |
||
Status |
Ergebnis der Operation |
||
Subscription |
Ein Identifikator, der die Anmeldung für die Topics eindeutig identifiziert. Bei den Operationen Unsubscribe, GetSubscription und RenewSubsriptions MUSS diese SubscriptionID angegeben werden. |
||
Termination |
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 |
3. |
renewSubscriptions |
Es wird eine neue SubscribeRenewals-Liste angelegt. |
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. |
|
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/ |
Identifikator der Subscription |
|
Subscription/ |
Maximaler Gültigkeitszeitpunkt der Subscription. |
|
Subscription/ |
URL des Endpunkts, wo die Ereignisse zugestellt werden sollen (Ereignissenke) |
|
Subscription/ |
Angemeldeter Topic |
|
Subscription/ |
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 |
3. |
getSubscriptions |
Rückgabe der Subscription, die durch SubscriptionId identifiziert wird. |
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
Typname |
Werteliste |
Defaultwert |
Bedeutung |
---|---|---|---|
ENC_CRYPT |
RSA ECC RSA_ECC |
RSA |
Werteliste des Parameters crypt bei der hybriden Verschlüsselung RSA: Es wird RSA-2048 basiert verschlüsselt. ECC: Es wird ECC-256 basiert verschlüsselt. RSA_ECC: Es wird dual RSA-2048 basiert und ECC-256 basiert verschlüsselt. Es wird als Fehlerfall gewertet, wenn weder RSA- noch ECC-Zertifikat von der Karte geladen werden konnten, und als Warnung, wenn nur ein Zertifikat geladen werden konnte. |
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:
|
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 |
|
Komponenten |
Konnektor, Kartenterminal, Karte |
Ausgangsdaten |
|
Standardablauf |
|
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:
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]
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. |
Abbildung 13: PIC_KON_058 Aktivitätsdiagramm „Daten hybrid verschlüsseln“
Tabelle 172: TAB_KON_073 Vorgaben zum Format verschlüsselter XML-Dokumente
# |
Beschreibung |
---|---|
xenc:EncryptedData MUSS ein ds:KeyInfo Element enthalten, welches wiederum ein xenc:EncryptedKey Element enthält. |
|
Der xenc:EncryptedKey MUSS [XMLEnc] konform sein. |
|
Die xenc:EncryptionMethod für den Schlüssel MUSS gemäß [gemSpec_Krypt#3.1.5] gewählt werden |
|
Der xenc:EncryptedKey MUSS ein ds:KeyInfo Element mit ds:X509Data und ds:X509Certificate Subelement enthalten, in dem das X.509-Zertifikat hinterlegt wird. |
Tabelle 173: TAB_KON_740 Fehlercodes TUC_KON_070 „Daten hybrid verschlüsseln“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4103 |
Technical |
Error |
XML-Element nicht gefunden |
4104 |
Technical |
Error |
XML-Element nicht eindeutig identifiziert. (Überschneidung) |
4105 |
Technical |
Error |
hybride Verschlüsselung konnte nicht durchgeführt werden |
4200 |
Security |
Error |
Schlüssel erlaubt keinen zugelassenen Verschlüsselungsalgorithmus |
4259 | Technical | Warning | Verschlüsselung für Zertifikat <Zertifikat> nicht möglich |
4282 | Technical | Error | Maximalanzahl von Empfängerzertifikaten überschritten |
[<=]
4.1.7.4.2 TUC_KON_071 „Daten hybrid entschlüsseln”
TIP1-A_4617-02 - TUC_KON_071 „Daten hybrid entschlüsseln“
Der Konnektor MUSS den technischen Use Case TUC_KON_071 „Daten hybrid entschlüsseln” umsetzen.
Tabelle 174: TAB_KON_140 – TUC_KON_071 „Daten hybrid entschlüsseln“
Element | Beschreibung |
---|---|
Name |
TUC_KON_071 „Daten hybrid entschlüsseln“ |
Beschreibung |
Ein hybrid verschlüsseltes Dokument, das konform zu TUC_KON_070 erstellt wurde, wird entschlüsselt. Es muss eine asymmetrische Verschlüsselung vorliegen, zu der der Schlüssel auf einer Karte vorliegt. |
Auslöser |
Aufruf in einem fachlichen Use Case oder des Verschlüsselungsbasisdienstes. |
Vorbedingungen |
Die Karte mit dem privaten Schlüssel muss gesteckt sein und der Sicherheitszustand zur Nutzung des privaten Schlüssels muss gesetzt sein. Ein konform zu TUC_KON_070 hybrid verschlüsseltes Dokument liegt vor. Bei XML-Dokumenten: Das Dokument enthält EncryptedData Elemente. Falls mehrere Elemente des Dokumentes zu entschlüsseln sind, müssen diese alle mit demselben symmetrischen Schlüssel verschlüsselt sein. |
Eingangsdaten |
|
Komponenten |
Konnektor, Kartenterminal, Karte |
Ausgangsdaten |
|
Standardablauf |
|
Varianten/Alterna- tiven |
Zu 6.: Zur Unterstützung von Bestandssystemen werden, neben den für den symmetrischen Teil der hybriden Verschlüsselung vorgeschriebenen kryptographischen Algorithmen, für den symmetrischen Teil der hybriden Entschlüsselung auch folgende Algorithmen unterstützt (siehe [gemSpec_Krypt#3.5.1]):
Wenn sowohl ein RSA- als auch ein ECC-basierter Hybridschlüssel vorliegen, muss zuerst die Entschlüsselung des ECC-basierten Hybridschlüssels erfolgen. Falls dabei ein Fehler auftritt, muss der Fehler protokolliert werden, und dann - ohne Abbruch - mit der Entschlüsselung des RSA-basierten Hybridschlüssels fortgefahren werden. |
Fehlerfälle |
Siehe Tabelle TAB_KON_142 Fehlercodes TUC_KON_071 „Daten hybrid entschlüsseln“. Wenn im Ablauf des TUCs ein anderer Fehler als die in Tabelle TAB_KON_142 Fehlercodes TUC_KON_071 „Daten hybrid entschlüsseln“ beschriebenen Fehler auftritt, wird Fehler 4107 gemeldet. |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
Abbildung PIC_KON_059 Aktivitätsdiagramm „Daten hybrid entschlüsseln“ |
Abbildung 14: PIC_KON_059 Aktivitätsdiagramm „Daten hybrid entschlüsseln“
Tabelle 175: TAB_KON_142 Fehlercodes TUC_KON_071 „Daten hybrid entschlüsseln“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4106 |
Technical |
Error |
falscher Schlüssel |
4107 |
Technical |
Error |
hybride Entschlüsselung konnte nicht durchgeführt werden |
4103 |
Technical |
Error |
XML-Element nicht gefunden |
4104 |
Technical |
Error |
XML-Element nicht eindeutig identifiziert |
4201 |
Technical |
Error |
kryptographischer Algorithmus vom Konnektor nicht unterstützt |
[<=]
4.1.7.4.3 TUC_KON_072 „Daten symmetrisch verschlüsseln”
TIP1-A_4618 - TUC_KON_072 „Daten symmetrisch verschlüsseln”
Der Konnektor MUSS den technischen Use Case TUC_KON_072 „Daten symmetrisch verschlüsseln“ umsetzen.
Tabelle 176: TAB_KON_741 – TUC_KON_072 „Daten symmetrisch verschlüsseln“
Element |
Beschreibung |
Name |
TUC_KON_072 „Daten symmetrisch verschlüsseln“ |
Beschreibung |
Es wird ein Dokument symmetrisch verschlüsselt. Dabei kann der zu verwendende symmetrische Schlüssel optional übergeben werden. |
Auslöser |
Aufruf durch ein Fachmodul in einem fachlichen Use Case |
Vorbedingungen |
keine |
Eingangsdaten |
|
Komponenten |
Konnektor |
Ausgangsdaten |
|
Standardablauf |
|
Varianten/Alternativen |
keine |
Fehlerfälle |
Siehe Standardablauf. |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
Tabelle 177: TAB_KON_742 Fehlercodes TUC_KON_072 „Daten symmetrisch verschlüsseln“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4108 |
Technical |
Error |
Symmetrische Verschlüsselung konnte nicht durchgeführt werden |
[<=]
4.1.7.4.4 TUC_KON_073 „Daten symmetrisch entschlüsseln”
TIP1-A_4619 - TUC_KON_073 „Daten symmetrisch entschlüsseln”
Der Konnektor MUSS den technischen Use Case TUC_KON_073 „Daten symmetrisch entschlüsseln“ umsetzen.
Tabelle 178: TAB_KON_743 - TUC_KON_073 „Daten symmetrisch entschlüsseln“
Element |
Beschreibung |
Name |
TUC_KON_073 „Daten symmetrisch entschlüsseln” |
Beschreibung |
Es wird ein Dokument symmetrisch entschlüsselt. Der zu verwendende symmetrische Schlüssel wird übergeben. |
Auslöser |
Aufruf durch ein Fachmodul in einem fachlichen Use Case |
Vorbedingungen |
keine |
Eingangsdaten |
|
Komponenten |
Konnektor |
Ausgangsdaten |
|
Standardablauf |
Das verschlüsselte Dokument wird mit dem symmetrischen Schlüssel entschlüsselt. Als Verfahren zum Entschlüsseln wird CMS gewählt ([RFC5652]). Das entschlüsselte Dokument wird zurückgeliefert. |
Varianten/Alterna-tiven |
keine |
Fehlerfälle |
Bei Auftreten eines Fehlers im Standardablauf wird Fehlercode 4109 gemeldet. |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
Tabelle 179: TAB_KON_744 Fehlercodes TUC_KON_073 „Daten symmetrisch entschlüsseln“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4109 |
Technical |
Error |
symmetrische Entschlüsselung konnte nicht durchgeführt werden |
[<=]
4.1.7.4.5 TUC_KON_075 „Symmetrisch verschlüsseln“
A_18001 - TUC_KON_075 „Symmetrisch verschlüsseln”
Der Konnektor MUSS den technischen Use Case TUC_KON_075 „Symmetrisch verschlüsseln“ umsetzen.
Tabelle 180: TAB_KON_860 – TUC_KON_075 „Symmetrisch verschlüsseln“
Element |
Beschreibung |
Name |
TUC_KON_075 „Symmetrisch verschlüsseln“ |
Beschreibung |
Es werden binäre Daten symmetrisch verschlüsselt. Optional können der zu verwendende symmetrische Schlüssel und AssociatedData für Authenticated Encryption with Associated Data (AEAD) übergeben werden. |
Auslöser |
Aufruf durch ein Fachmodul in einem fachlichen Use Case |
Vorbedingungen |
keine |
Eingangsdaten |
|
Komponenten |
Konnektor |
Ausgangsdaten |
|
Standardablauf |
|
Varianten/Alternativen |
keine |
Fehlerfälle |
-> 2: Falls die Verschlüsselung fehlschlägt, wird Fehler 4108 gemäß TAB_KON_742 gemeldet. |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
4.1.7.4.6 TUC_KON_076 „Symmetrisch entschlüsseln“
A_18002 - TUC_KON_076 „Symmetrisch entschlüsseln”
Der Konnektor MUSS den technischen Use Case TUC_KON_076 „Symmetrisch entschlüsseln“ umsetzen.
Tabelle 181: TAB_KON_861 - TUC_KON_076 „Symmetrisch entschlüsseln“
Element |
Beschreibung |
Name |
TUC_KON_076 „Symmetrisch entschlüsseln” |
Beschreibung |
Es werden verschlüsselte Daten symmetrisch entschlüsselt. Für Authenticated Encryption with Associated Data (AEAD) kann AssociatedData optional übergeben werden. Der zu verwendende symmetrische Schlüssel wird übergeben. |
Auslöser |
Aufruf durch ein Fachmodul in einem fachlichen Use Case |
Vorbedingungen |
keine |
Eingangsdaten |
|
Komponenten |
Konnektor |
Ausgangsdaten |
|
Standardablauf |
Das verschlüsselte Dokument wird mit dem symmetrischen Schlüssel und associatedData unter Verwendung der kryptographischen Verfahren aus A_17872 entschlüsselt. Die entschlüsselten Daten werden zurückgeliefert. |
Varianten/Alterna-tiven |
keine |
Fehlerfälle |
Bei Auftreten eines Fehlers im Standardablauf wird Fehlercode 4109 gemäß TAB_KON_744 gemeldet. |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
4.1.7.5 Operationen an der Außenschnittstelle
TIP1-A_4620-03 - Basisdienst Verschlüsselungsdienst
Der Konnektor MUSS für Clients einen Basisdienst Verschlüsselungsdienst anbieten.
Tabelle 182: TAB_KON_745 Basisdienst Verschlüsselungsdienst
Name |
EncryptionService |
|
---|---|---|
Version (KDV) |
6.1.0 (WSDL-Version), 6.1.1 (XSD-Version) 6.1.1 (WSDL-Version), 6.1.2 (XSD-Version) |
|
Namensraum |
Siehe GitHub |
|
Namensraum-Kürzel |
CRYPT für Schema und CRYPTW für WSDL |
|
Operationen |
Name |
Kurzbeschreibung |
EncryptDocument |
Dokument hybrid verschlüsseln |
|
DecryptDocument |
Dokument hybrid entschlüsseln |
|
WSDL |
EncryptionService.wsdl (WSDL-Version 6.1.0) EncryptionService_v6_1_1.wsdl |
|
Schema |
EncryptionService.xsd (XSD-Version 6.1.1) EncryptionService_v6_1_2.xsd |
[<=]
4.1.7.5.1 EncryptDocument
TIP1-A_4621-05 - Operation EncryptDocument
Der Basisdienst Verschlüsselungsdienst des Konnektors MUSS an der Clientschnittstelle eine Operation EncryptDocument anbieten.
Tabelle 183: TAB_KON_071 Operation EncryptDocument
Name |
EncryptDocument |
||
---|---|---|---|
Beschreibung |
Diese Operation verschlüsselt ein übergebenes Dokument hybrid. Es werden die Dokumententypen Alle_DocFormate unterstützt. Für die hybride Verschlüsselung wird ein asymmetrischer Schlüssel aus einem X.509v3-Zertifikat genutzt. Dieses Zertifikat kann von einer Karte kommen oder als Parameter übergeben werden. Pro Operationsaufruf können mehrere Hybridschlüssel erzeugt werden. Übergibt der Aufrufer die Zertifikate beim Aufruf, steuert er durch die Wahl der Zertifikate, ob RSA-basierte oder ECC-basierte Hybridschlüssel erzeugt werden. Wenn das Verschlüsselungszertifikat von einer Karte kommt, kann der Aufrufer durch Angabe des Kryptoverfahrens crypt steuern, ob Hybridschlüssel für RSA oder für ECC oder beide erzeugt werden. Das Defaultverhalten ist die Hybridschlüsselerzeugung für RSA und entspricht dem Verhalten aus der Version 6.1.0 der Schnittstelle. Es werden die folgenden Karten unterstützt: HBAx und SM-B. Die Operation EncryptDocument DARF das Verschlüsseln mit der eGK NICHT unterstützen. Für alle Dokumenttypen wird immer das gesamte Dokument verschlüsselt. Vom Konnektor zu verschlüsselnde Dokumente müssen konform zu den Anforderungen in Kapitel 3.1.1 "Dokumentformate" sein. |
||
Name |
Beschreibung |
||
Context |
Aufrufkontext:
|
||
Das RecipientKeys-Element identifiziert die Empfänger der zu verschlüsselnden Nachricht über X.509-Zertifikate (öffentliche Schlüssel). Quelle für die Zertifikate kann eine gesteckte Karte sein, die per CertificateOnCard-Element referenziert wird, oder der Aufrufer, der X.509-Zertifikate im Certificate-Element übergibt. |
|||
Card Handle |
Identifiziert die zu verwendende Karte mit dem (öffentlichen) Schlüssel. Ist das Element nicht vorhanden, so werden nur Zertifikate per Element Certificate übergeben. |
||
KeyRef erence |
Der Wert dieses Parameters ist in Tabelle TAB_KON_747 KeyReference für Encrypt-/DecryptDocument spezifiziert. Ist der Parameter nicht angegeben, gilt der Default-Wert C.ENC. |
||
Crypt |
Optional; Default: siehe TAB_KON_859 Wertebereich: [ENC_CRYPT] Gibt den Typ von Zertifikaten vor, die von der per CardHandle referenzierten Karte für die Erzeugung der Hybridschlüssel gemäß Tabelle TAB_KON_747 verwendet werden. |
||
Certifi cate |
Certificate ist ein Base64-kodiertes XML-Element, in dem das Zertifikat, das den asymmetrischen Schlüssel enthält (öffentlicher Schlüssel), DER-kodiert übergeben wird. Es kann eine Liste von Zertifikaten übergeben werden. Der Konnektor MUSS eine Liste von mindestens 1000 Zertifikaten unterstützen. Kommt das Zertifikat ausschließlich von einer Karte, dann kann dieser Parameter weggelassen werden. |
||
CONN: Document |
Dieses entsprechend [OASIS-DSS] Section 2.4.2 spezifizierte Element enthält das zu verschlüsselnde Dokument, wobei die Kindelemente CONN:Base64XML und dss:Base64Data verwendet werden. Im Fall dss:Base64Data wird ein etwaig übergebenes MIME-Type-Attribut nicht ausgewertet. |
||
CRYPT: Optional Inputs |
Enthält eine Auswahl der folgenden unten näher erläuterten (optionalen) Eingabeparameter: |
||
Encryption Type |
Zu wählendes Verschlüsselungsverfahren, wobei folgende URI vorgesehen sind:
In den Fällen CMS und S/MIME wird ein Base64-codiertes Binär-Dokument im Element CONN:Document/dss:Base64Data übergeben . Ist der Parameter EncryptionType nicht gesetzt, dann gilt folgendes Default-Verhalten: Für ein im Element CONN:Document/CONN:Base64XML übergebenes XML-Dokument wird als Verschlüsselungsverfahren [XMLEnc] angewandt, und für ein im Element CONN:Document/dss:Base64Data übergebenes Dokument wird das Verschlüsselungsverfahren CMS angewandt. XML-Documente werden nach Type=http://www.w3.org/2001/04/xmlenc#Element verschlüsselt. Im Fall S/MIME ist das in CONN:Document/dss:Base64Data übergebene Dokument eine MIME-Nachricht. Der Konnektor KANN die Operation im Fall S/MIME mit Fehlercode 4279 beenden. |
||
Element |
Der Parameter wird nicht ausgewertet. |
||
CRYPT: Unprotected Properties |
Dieses optionale Element wird im CMS-Fall (EncryptionType = urn:ietf:rfc:5652) ausgewertet. Die Elemente ./UnprotectedProperties/Property/Value/CMSAttribute müssen base64/DER-kodiert ein vollständiges ASN.1-Attribute enthalten, definiert in [CMS# 9.1.AuthenticatedData Type]. Es muss bei der Erstellung des CMS-Containers unter "unauthAttrs" aufgenommen werden. Das zugehörige Element ./UnprotectedProperties/Property/Identifier wird nicht ausgewertet. |
||
Rückgabe |
|||
Status |
Enthält den Ausführungsstatus der Operation. |
||
CRYPT: Optional Outputs |
Kann – in zukünftigen Versionen der Spezifikation – optionale Ausgabeparameter enthalten. | ||
CONN: Document |
Enthält das verschlüsselte Dokument in base64-codierter Form, wenn die Verschlüsselung erfolgreich durchgeführt wurde. Im Fall XMLEnc wird das Base64-codierte verschlüsselte XML-Dokument im Element CONN:Document/CONN:Base64XML zurückgegeben. Im Fall CMS wird das Base64-codierte Binär-Dokument im Element CONN:Document/dss:Base64Data zurückgegeben. Im Fall S/MIME wird die Base64-codierte S/MIME-Nachricht im Element CONN:Document/dss:Base64Data zurückgegeben. Das Attribut CONN:Document/dss:Base64Data/@MimeType wird auf „application/pkcs7-mime“ gesetzt. Die S/MIME-Nachricht hat Content-Transfer-Encoding: base64. |
||
Fehler |
Bei Auftreten eines Fehlers im Standardablauf werden Fehlercodes entsprechend TAB_KON_141 gemeldet. | ||
Vorbe-dingungen |
Keine | ||
Nachbe-dingungen |
Keine |
Tabelle 184: TAB_KON_746 Ablauf EncryptDocument
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. | checkDocumentFormat | Der Konnektor prüft für das zu verschlüsselnde Dokument, ob die Vorgaben aus Kapitel 3.1.1 eingehalten sind. Bei Verletzung einer Vorgabe bricht der Konnektor die Verarbeitung mit einem entsprechenden Fehlercode ab. |
3. |
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; userId = $context.userId; cardHandle = $cardHandle } Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab. |
4. |
TUC_KON_026 „Liefere CardSession“ |
Ermittle CardSession über TUC_KON_026 { mandatId =$context..mandantId; clientSystemId = $context.clientSystemId; cardHandle = $context..cardHandle; userId = $context.userId } |
5. |
TUC_KON_070 „Daten hybrid verschlüsseln“ |
Die hybride Verschlüsselung wird durchgeführt. Tritt hierbei ein Fehler auf, bricht die Operation ab. Die KeyInfo, d.h. die Liste der Hybridschlüssel inklusive des bei ihrer Erzeugung verwendeten Zertifikates, sind dabei in das Dokument einzubetten. |
Tabelle 185: TAB_KON_141 Fehlercodes „EncryptDocument“
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: |
|||
4000 |
Technical |
Error |
Syntaxfehler |
4001 |
Security |
Error |
Interner Fehler |
4058 |
Security |
Error |
Aufruf nicht zulässig |
4279 | Technical | Error | S/MIME-Funktionalität nicht unterstützt" |
4283 | Technical | Error | Dokument zu groß |
4.1.7.5.2 DecryptDocument
TIP1-A_4622-05 - Operation DecryptDocument
Der Basisdienst Verschlüsselungsdienst des Konnektors MUSS an der Clientschnittstelle eine Operation DecryptDocument anbieten.
Tabelle 186: TAB_KON_075 Operation DecryptDocument
Name |
DecryptDocument |
|
---|---|---|
Beschreibung |
Die Operation entschlüsselt alle hybrid verschlüsselten Dokumente, die mit der Operation EncryptDocument erzeugt wurden. Es werden die Dokumententypen Alle_DocFormate unterstützt. Für die Entschlüsselung wird ein asymmetrischer Schlüssel zu einem X.509v3-Zertifikat genutzt. Dieses Zertifikat und der Schlüssel müssen von einer Karte kommen. Das bei der Entschlüsselung verwendete Kryptoverfahren (RSA oder ECC) wird durch den Hybridschlüssel bestimmt, der durch die Karte entschlüsselt werden soll. Sind sowohl RSA- als auch ECC-Hybridschlüssel für die referenzierte Karte vorhanden, versucht der Konnektor die Entschlüsselung des ECC-Hybridschlüssels, und wenn das nicht erfolgreich war, die Entschlüsselung des RSA-Hybridschlüssels. Vom Konnektor zu entschlüsselnde Dokumente müssen konform zu den Anforderungen in Kapitel 3.1.1 "Dokumentformate" sein. |
|
Aufrufparameter |
||
Name |
Beschreibung |
|
Context |
Aufrufkontext:
|
|
PrivateKey OnCard |
Identifiziert die zu verwendende Karte mit dem (privaten) Schlüssel. Es werden die folgenden Karten unterstützt: HBAx und SM-B. Die Operation DecryptDocument DARF das Entschlüsseln mit der eGK NICHT unterstützen. |
|
CardHandle |
Identifiziert die gesteckte Karte. |
|
KeyReference |
Der Wert dieses Parameters ist in der Tabelle TAB_KON_747 KeyReference für Encrypt-/DecryptDocument spezifiziert. Ist der Parameter nicht angegeben, gilt der Default-Wert C.ENC. |
|
Crypt |
Ist nicht enthalten. |
|
CONN: Document |
Enthält das base64-codierte Dokument, das entschlüsselt werden soll. |
|
CRYPT: OptionalInputs |
Kann – in zukünftigen Versionen der Spezifikation – optionale Aufrufparameter enthalten. |
|
Rückgabe |
||
Status |
Enthält den Ausführungsstatus der Operation. |
|
CRYPT: OptionalOutputs |
Kann – in zukünftigen Versionen der Spezifikation – optionale Ausgabeparameter enthalten. |
|
CONN:Document |
Enthält das entschlüsselte Dokument in base64-codierter Form |
|
Fehler |
Bei Auftreten eines Fehlers im Standardablauf werden Fehlercodes entsprechend TAB_KON_145 gemeldet. |
|
Vorbe-dingungen |
Keine |
|
Nachbe-dingungen |
Keine |
Der Ablauf der Operation DecryptDocument ist in Tabelle TAB_KON_076 Ablauf DecryptDocument beschrieben:
Tabelle 187: TAB_KON_076 Ablauf DecryptDocument
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“ |
Die Prüfung erfolgt durch den Aufruf TUC_KON_000 { mandantId = $context.mandantId; clientsystemId = $context.clientsystemId; workplaceId = $context.workplaceId; userId = $context.userId; cardHandle = $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 026 { mandatId =$context.mandantId; clientsystemId = $context.clientsystemId; cardHandle = $context.cardHandle; userId = $context.userId } |
4. |
TUC_KON_071 Daten hybrid entschlüsseln |
Die Entschlüsselung wird durchgeführt. Im Fall eines XML-Dokuments mit mehreren verschlüsselten Elementen sind alle mit dem angegebenen Schlüssel entschlüsselbaren Elemente zu entschlüsseln. Wenn für das entschlüsselte Dokument Vorgaben aus Kapitel 3.1.1 nicht eingehalten sind, bricht der Konnektor die Verarbeitung mit einem entsprechenden Fehlercode ab. Im Fall eines MIME-Dokuments KANN der Konnektor die Operation mit Fehlercode 4279 beenden. |
Tabelle 188: TAB_KON_145 Fehlercodes „DecryptDocument“
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: |
|||
4000 |
Technical |
Error |
Syntaxfehler |
4001 |
Security |
Error |
interner Fehler |
4058 |
Security |
Error |
Aufruf nicht zulässig |
4279 | Technical | Error | S/MIME-Funktionalität nicht unterstützt |
4283 | Technical | Error | Dokument zu groß |
4.1.7.6 Betriebsaspekte
keine
4.1.8 Signaturdienst
Der Signaturdienst bietet Clientsystemen und Fachmodulen eine Schnittstelle zum Signieren von Dokumenten und Prüfen von Dokumentensignaturen
Innerhalb des Signaturdienstes werden folgende Präfixe für Bezeichner verwendet:
- Events (Topic Ebene 1): keine Events vorhanden
- Konfigurationsparameter: „SAK_“
4.1.8.1 Funktionsmerkmalweite Aspekte
4.1.8.1.1 Dokumentensignatur
Der Signaturdienst umfasst die Funktionalität der nicht-qualifizierten elektronischen Signatur (nonQES) mit der SM-B, sowie die qualifizierte elektronische Signatur (QES) mit dem HBA und den HBA-Vorläuferkarten HBA-qSig und ZOD_2.0 (=HBAx).
In der Abbildung fachlicher Abläufe kann es nötig sein, ein Dokument mehrfach parallel zu signieren, oder existierende Signaturen gegenzusignieren. Der Konnektor unterstützt parallele Signaturen (QES und nonQES). Ebenso unterstützt er Gegensignaturen (QES und nonQES), die jeweils alle bestehenden Signaturen gegensignieren. Die angebotene Möglichkeit des Gegensignierens bezieht sich dabei auf das Signieren aller vorhandenen parallelen Signaturen, während ein Gegensignieren von Gegensignaturen nicht angeboten wird. Der Konnektor unterstützt ausschließlich eine dokumentexkludierende Gegensignatur, bei der alle Signaturen gegensigniert werden, aber nicht der fachliche Inhalt des Dokumentes selbst.
TIP1-A_4623-02 - Unterstützte Signaturverfahren nonQES
Der Signaturdienst MUSS für die Erstellung und Prüfung von nicht-qualifizierten elektronischen Signaturen (nonQES) für die nonQES_DocFormate die Signaturverfahren entsprechend Tabelle TAB_KON_582 – Signaturverfahren unterstützen.
[<=]
TIP1-A_4627 - Unterstützte Signaturverfahren QES
Der Signaturdienst MUSS für die Erstellung und Prüfung von qualifizierten elektronischen Signaturen (QES) für die QES_DocFormate die Signaturverfahren entsprechend Tabelle TAB_KON_582 – Signaturverfahren unterstützen.
[<=]
Tabelle 189: TAB_KON_582 – Signaturverfahren Dokumentensignatur
Signaturformat |
Standard |
Dokumentformate |
QES/ nonQES |
Bemerkung |
---|---|---|---|---|
XMLDSig (XAdES) |
[RFC3275] [XMLDSig] [XAdES] [RFC6931] |
XML |
QES, nonQES |
Hierdurch können abgesetzte (detached), umschließende (enveloping) und eingebettete (enveloped) Signaturen erzeugt werden. |
CMS (CAdES) |
[RFC5652] [CAdES] |
QES_DocFormate nonQES_DocFormate |
QES, nonQES |
Hierdurch können abgesetzte (detached) und umschließende (enveloping) Signaturen erzeugt werden. |
PDF/A (PAdES) |
[PAdES-3] |
PDF/A |
QES, nonQES |
Hierdurch können CMS-basierte Signaturen in PDF/A-Dokumente eingefügt und dadurch eingebettete Signaturen erzeugt werden. |
S/MIME (optional) |
[RFC5751] |
nonQES_DocFormate |
nonQES |
Optional wird die Signatur und Signaturprüfung von MIME-Nachrichten unterstützt. Der Konnektor soll, wenn er die S/MIME-Signatur unterstützt, auch die S/MIME-Signaturprüfung unterstützen. |
Zu den Begriffen detached, enveloping und enveloped Signaturen siehe beispielsweise auch [HüKo06#Abs. 4.3.3. und 4.3.1.5].
TIP1-A_5447 - Einsatzbereich der Signaturvarianten
Der Signaturdienst MUSS für die Erstellung und Prüfung von nicht-qualifizierten elektronischen Signaturen (nonQES) und qualifizierten elektronischen Signaturen (QES) die Vorgaben zum Einsatzbereich gemäß Tabelle TAB_KON_778 umsetzen.
Tabelle 190: TAB_KON_778 – Einsatzbereich der Signaturvarianten für XAdES, CAdES und PAdES
Signaturvarianten |
Einsatzbereich |
|||||
---|---|---|---|---|---|---|
Signatur verfahren |
Signatur- variante |
WAS wird signiert? |
WO wird die Signatur abgelegt? |
nonQES |
QES Außen- schnittstelle |
QES Fachmodul- schnittstelle |
XAdES |
detached |
beliebiges (Binär)-Dokument |
außerhalb des Dokuments in der SignResponse |
Nein |
Nein |
Nein |
XAdES |
detached |
gesamtes Input XML-Dokument (= Root-Element mit Subelementen) |
außerhalb des Dokuments in der SignResponse |
Nein |
Nein |
Nein |
XAdES |
detached |
ausgewähltes nicht Root-Element mit Subelementen im Input XML-Dokument |
außerhalb des Dokuments in der SignResponse |
Nein |
Nein |
Nein |
XAdES |
detached |
ausgewähltes nicht Root-Element mit Subelementen im Input XML-Dokument |
Innerhalb des Dokuments, aber außerhalb des signierten Subbaums |
Nein |
Bedingt |
Bedingt |
XAdES |
enveloped |
gesamtes Input XML-Dokument (= Root-Element mit Subelementen) |
Als direktes Child des Root-Elements |
Ja |
Bedingt |
Bedingt |
XAdES |
enveloped |
ausgewähltes nicht Root-Element mit Subelementen im Input XML-Dokument |
Als direktes Child des ausgewählten Elements |
Nein |
Nein |
Bedingt |
XAdES |
enveloping |
gesamtes Input XML-Dokument (= Root-Element mit Subelementen) |
Im Dokument, das Root-Element umschließend |
Ja |
Bedingt |
Bedingt |
XAdES |
enveloping |
ausgewähltes nicht Root-Element mit Subelementen im Input XML-Dokument |
Im Dokument, das ausgewählte Element umschließend |
Nein |
Nein |
Nein |
CAdES |
detached |
gesamtes Binärdokument |
außerhalb des Dokuments in der SignResponse |
Ja |
Ja |
Ja |
CAdES |
enveloping |
gesamtes Binär-Dokument |
innerhalb des CMS-Dokuments |
Ja |
Ja |
Ja |
PAdES |
- |
gesamtes PDF-Dokument |
Im PDF-Dokument |
Ja |
Ja |
Ja |
Ja: Die Signaturvariante ist für den Einsatzbereich erlaubt.
Nein: Die Signaturvariante ist für den Einsatzbereich nicht erlaubt.
Bedingt: Die Signaturvariante ist für den Einsatzbereich nicht erlaubt, es sei denn es wird durch eine im Konnektor integrierte Signaturrichtlinie explizit gefordert.
Die Spalten mit gelber Kopfzeile definieren die Signaturvarianten, die mit grauer, den Einsatzbereich. Beim Einsatzbereich wird zwischen nonQES und QES unterschieden und im Fall QES nach der Bereitstellung an der Außenschnittstelle oder intern für Fachmodule.
Die benötigten Signaturvarianten werden für XAdES über die Aufrufparameter IncludeObject und SignaturePlacement gemäß [OASIS-DSS] gesteuert.
Für CAdES erfolgt die Steuerung welche Signaturvariante gewählt wird, über den Aufrufparameter IncludeEContent.
[<=]
A_18756 - Optionalität von nonQES-XAdES Signatur
Der Konnektor KANN alle Aufrufe zu Signaturerstellung einer nonQES-XAdES Signatur mit Fehler 4111 und alle Aufrufe zur Signaturprüfung einer nonQES-XAdES Signatur mit Fehler 4112 beantworten. Die Signaturvarianten aus TAB_KON_778 werden damit weiter eingeschränkt. Wird die nonQES-XAdES Signatur umgesetzt, so ist diese in der Sicherheitszertifizierung zu betrachten. [<=]
TIP1-A_5402 - Baseline-Profilierung der AdES-EPES-Profile
Der Konnektor MUSS von den AdES-Profilen die AdES-EPES-Profile umsetzen, ergänzt um
RevocationValues gemäß AdES-X-L,
SignatureTimeStamp (für Signaturprüfung, nicht für Signaturerstellung) gemäß AdES-T
Dabei MUSS der Konnektor die Baseline-Profilierung gemäß Kapitel 6 in [XAdES Baseline Profile] für XAdES, Kapitel 6 in [CAdES Baseline Profile] für CAdES und Kapitel 6 in [PAdES Baseline Profile] für PAdES umsetzen.
[<=]Durch die Baseline-Profilierung der AdES-BES-Profile wird festgelegt, wie der Signaturzeitpunkt, gemessen als Systemzeit des Konnektors, in die Signatur eingebracht wird.
TIP1-A_5403 - Common PKI konforme Profile
Der Konnektor SOLL die signierten Dokumente konform zu [COMMON_PKI#Part 3] und [COMMON_PKI#Part 8] erstellen.
[<=]TIP1-A_4624 - Default-Signaturverfahren nonQES
Bei fehlender expliziter Angabe durch den Aufrufer MUSS der Signaturdienst bei der Erstellung von nicht-qualifizierten elektronischen Signaturen (nonQES) die Default-Signaturverfahren entsprechend TAB_KON_583 Default-Signaturverfahren wählen.
[<=]TIP1-A_4628 - Default-Signaturverfahren QES
Bei fehlender expliziter Angabe durch den Aufrufer MUSS der Signaturdienst bei der Erstellung von qualifizierten elektronischen Signaturen (QES) die Default-Signaturverfahren entsprechend TAB_KON_583 – Default-Signaturverfahren wählen.
[<=]Tabelle 191: TAB_KON_583 – Default-Signaturverfahren
Dokument-Format |
Signaturverfahren (und -variante) |
|||
---|---|---|---|---|
Signaturverfahren |
Signaturvariante |
WAS wird signiert? |
WO wird die Signatur abgelegt? |
|
XML |
XAdES
|
enveloped
|
gesamtes Input XML-Dokument
(= Root-Element mit Subelementen) |
als direktes Child des Root-Elements
|
PDF/A |
PAdES
|
-
|
gesamtes PDF-Dokument
|
im PDF-Dokument
|
alle anderen |
CAdES
|
detached
|
gesamtes Binärdokument
|
außerhalb des Dokuments in der SignResponse
|
TIP1-A_5387 - Erweiterte Nutzung der AdES-Profile
Der Konnektor MUSS auf eine vollständige Nutzung der AdES-Profile erweiterbar sein.
[<=]TIP1-A_5033 - Missbrauchserkennung Signaturdienst (nonQES)
Der Konnektor MUSS zur Unterstützung von Missbrauchserkennungen die in Tabelle TAB_KON_584 gelisteten Operationen als Einträge in EVT_MONITOR_OPERATIONS berücksichtigen.
Tabelle 192: TAB_KON_584 nonQES-Operationen für EVT_MONITOR_OPERATIONS
Operationsname |
OK_Val |
NOK_Val |
Alarmwert (Default-Grenzwert 10 Minuten-Σ) |
---|---|---|---|
SignDocument (nonQES) |
1 |
5 |
41 |
VerifyDocument (nonQES) |
1 |
5 |
61 |
[<=]
TIP1-A_4629 - Unterstützte Karten QES-Erstellung
Der Signaturdienst MUSS für die QES-Erstellung die Kartentypen HBA, HBA-qSig und ZOD_2.0 unterstützen.
[<=]TIP1-A_5436 - XML Dokument nach Entfernen der Signatur unverändert
Der Konnektor MUSS die Operation SignDocument für XML-Dokumente so implementieren, dass das Dokument nach Entfernen der Signatur, insbesondere auch einer Teilsignatur, als Ganzes unverändert ist, wobei zwei XML-Dokumente als identisch zu betrachten sind, wenn sie gemäß Canonical XML 1.1 gleich sind [CanonXML1.1].
[<=]TIP1-A_5682 - XML Nicht geeignete Algorithmen im VerificationReport
Der Konnektor MUSS im VerificationReport einer QES-Signaturprüfung ausweisen, wenn die für die Signatur verwendeten Algorithmen nach dem Algorithmenkatalog [ALGCAT] als nicht geeignet eingestuft werden.
[<=]
A_17768 - Zertifikate und Schlüssel für Signaturerstellung und Signaturprüfung (QES und nonQES)
Der Konnektor MUSS bei der Signaturerstellung und Signaturprüfung (QES und nonQES) die Zertifikate und Schlüssel gemäß den Vorgaben in TAB_KON_900 ermitteln.
Tabelle 193: TAB_KON_900 Zertifikate und private Schlüssel für Signaturerstellung und Signaturprüfung (QES und nonQES)
Karte |
Crypt |
Zertifikat (Verify) |
Schlüssel (Sign) |
Einsatzbereich | |
---|---|---|---|---|---|
Außen-schnittstelle | Fachmodul-schnittstelle | ||||
QES | ...in DF.QES | ||||
HBA | RSA | EF.C.HP.QES.R2048 | PrK.HP.QES.R2048 | ja | ja |
ECC | EF.C.HP.QES.E256 | PrK.HP.QES.E256 | ja | ja | |
RSA_ECC | [ab G2.1]: EF.C.HP.QES.E256 [G2.0]: EF.C.HP.QES.R2048 |
[ab G2.1]: PrK.HP.QES.E256 [G2.0]: PrK.HP.QES.R2048 |
ja | ja | |
HBA-VK | RSA | EF.C.HP.QES | PrK.HP.QES | ja | ja |
nonQES | ...in DF.ESIGN | ||||
SM-B | RSA | EF.C.HCI.OSIG.R2048 | PrK.HCI.OSIG.R2048 | ja | ja |
ECC | EF.C.HCI.OSIG.E256 | PrK.HCI.OSIG.E256 | ja | ja | |
RSA_ECC | [ab G2.1]: EF.C.HCI.OSIG.E256 [G2.0]: EF.C.HCI.OSIG.R2048 |
[ab G2.1]: PrK.HCI.OSIG.E256 [G2.0]: PrK.HCI.OSIG.R2048 |
ja | ja | |
eGK | RSA | EF.C.CH.AUT.R2048 | PrK.CH.AUT.R2048 | nein | ja |
ECC | EF.C.CH.AUT.E256 | PrK.CH.AUT.E256 | nein | ja | |
RSA_ECC | [ab G2.1]: EF.C.CH.AUT.E256 [G2.0]: EF.C.CH.AUT.R2048 |
[ab G2.1]: PrK.CH.AUT.E256 [G2.0]: PrK.CH.AUT.R2048 |
nein | ja |
Tabelle 194: TAB_KON_862-01 Werteliste und Defaultwert des Parameters crypt bei QES-Erzeugung
Typname |
Werteliste |
Defaultwert |
Bedeutung |
---|---|---|---|
SIG_CRYPT_QES |
RSA ECC RSA_ECC |
RSA |
Werteliste des Parameters crypt bei der bei der Erzeugung einer QES-Signatur RSA: Es wird eine RSA-2048 Signatur erzeugt. ECC: Es wird eine ECC-256 Signatur erzeugt. RSA_ECC: In Abhängigkeit von der Kartengeneration wird eine RSA-2048 bzw. eine ECC-256 Signatur erzeugt (siehe TAB_KON_900). |
Tabelle 195: TAB_KON_863 Werteliste und Defaultwert des Parameters crypt bei nonQES-Erzeugung
Typname |
Werteliste |
Defaultwert |
Bedeutung |
---|---|---|---|
SIG_CRYPT_nonQES |
RSA ECC RSA_ECC |
RSA |
Werteliste des Parameters crypt bei der bei der Erzeugung einer nonQES-Signatur RSA: Es wird eine RSA-2048 Signatur erzeugt. ECC: Es wird eine ECC-256 Signatur erzeugt. RSA_ECC: In Abhängigkeit von der Kartengeneration wird eine RSA-2048 bzw. eine ECC-256 Signatur erzeugt (siehe TAB_KON_900). |
4.1.8.1.2 Signaturrichtlinien
Signaturrichtlinien dienen der Profilierung von Signaturerstellung und -prüfung. Beim Aufruf der Operation SignDocument kann eine URI übergeben werden, die eine im Konnektor hinterlegte Signaturrichtlinie referenziert. Die Plattform des Konnektors stellt selbst keine Signaturrichtlinien bereit. Fachanwendungen, die Signaturrichtlinien erfordern, definieren diese im Fachmodul des Konnektors. Für XML-Dokumentenformate aus der Menge von QES_DocFormate können die nachfolgenden Aspekte über eine Signaturrichtlinie gekapselt festgelegt werden:
- XML-Schemas für die Typkonformitätsprüfung (im Konnektor zu hinterlegen)
- Constraints für den Aufruf der Schnittstelle SignDocument und VerifyDocument, die zur Profilierung der Schnittstelle dienen.
TIP1-A_5538 - Signaturrichtlinien bei QES für XML-Dokumentenformate
Der Konnektor MUSS Signaturrichtlinien für XML-Dokumentenformate aus der Menge von QES_DocFormate bei die Signaturerstellung und -prüfung umsetzen.
Der Konnektor MUSS den für jede Signaturrichtlinie definierten Bezeichner (URI) bei der Signatur als SigPolicyId im Feld SignaturePolicyIdentifier einbetten. Bei der Signaturprüfung MUSS der Konnektor über eine etwaig vorhandene SigPolicyId die Signaturrrichtlinie identifizieren.
Die gemäß AdES erforderliche Hash-Referenz über die Policy (SigPolicyHash) MUSS Schema-konform leer gelassen werden. Bei der Signaturprüfung DARF die Hash-Referenz über die Policy NICHT geprüft werden.
[<=]4.1.8.1.3 Signaturzeitpunkt
Bezogen auf den vom Konnektor für die Signaturprüfung anzunehmenden Signaturerstellungszeitpunkt werden in dieser Spezifikation die Bezeichner Ermittelter_Signaturzeitpunkt und Benutzerdefinierter_Zeitpunkt verwendet.
Ermittelter_Signaturzeitpunkt: Vom Konnektor ermittelter Zeitpunkt, zu dem eine Signatur geprüft wird. Es werden folgende Signaturzeitpunkte ermittelt:
- Ermittelter_Signaturzeitpunkt_Eingebettet:
in der Signatur eingebetteter Zeitpunkt (falls vorhanden) - Ermittelter_Signaturzeitpunkt_System:
Systemzeit des Konnektors bei Signaturprüfung
Anmerkung: Bei vom Konnektor selbst erstellten Signaturen ist immer ein in der Signatur eingebetteter Zeitpunkt vorhanden, jedoch kein qualifizierter Zeitstempel, da in der TI keine qualifizierten Zeitstempel ausgestellt werden. Sollte ein Dokument mit einem qualifizierten Zeitstempel versehen sein, so wird dieser nicht für die Ermittlung des Signaturzeitpunktes herangezogen.
Benutzerdefinierter_Zeitpunkt: Vom Benutzer beim Aufruf der Signaturprüfoperation als Parameter an den Konnektor übergebener Zeitpunkt, zu dem eine Signatur geprüft werden soll.
4.1.8.1.4 Jobnummer
Da die eHealth-Kartenterminals dezentral über eine Netzwerkschnittstelle am Konnektor betrieben werden, fehlt die Möglichkeit zur direkten physischen und vom Anwender kontrollierbaren Zuordnung eines solchen Terminals zu einem Arbeitsplatz, auf dem sich das Clientsystem befindet.
Daher ist es bei einer fehlerhaften Zuordnung eines eHealth-Kartenterminals zu einem Arbeitsplatz möglich, dass die PIN-Eingabeaufforderung – beispielsweise zu einem Signaturauftrag – an ein entferntes Kartenterminal weitergeleitet wird. Diese fehlerhafte Zuordnung kann durch einen Fehler des Clientsystems oder den Versuch eines Angriffes hervorgerufen werden.
Die Jobnummern werden vom Konnektor erzeugt und können durch Clientsystem abgerufen werden. Der Konnektor stellt jedoch keine Verbindung zwischen erzeugten und verwendeten Jobnummern her. Es wird also nicht geprüft, ob nur Jobnummern verwendet werden, die vorher vom Konnektor erzeugt wurden, oder ob alle Jobnummern verwendet werden, die vom Konnektor erzeugt wurden.
TIP1-A_4639 - Generierung von Jobnummern für PIN-Eingaben
Um Fehler- und Angriffsmöglichkeiten auszuschließen, MUSS der Konnektor bei bestimmten PIN-Verifikationen vor der Aufforderung zur PIN-Eingabe an einem eHealth-Kartenterminal eine hinreichend eindeutige Nummer – die Jobnummer – generieren, welche den Auftrag kennzeichnet, für dessen Verarbeitung die PIN-Eingabe erfolgen soll. Bei welchen PIN-Verifikationen dies der Fall ist, kann den PIN-Prompts in TAB_KON_090 Terminalanzeigen beim Eingeben der PIN am Kartenterminal entnommen werden.
[<=]
TIP1-A_4640 - Anzeige der Jobnummern für PIN-Eingaben
Diese Jobnummer MUSS vom Konnektor im Display des eHealth-Kartenterminals neben der PIN-Eingabeaufforderung angezeigt werden.
[<=]TIP1-A_4992-02 - Guidance zur Jobnummer
Das Handbuch des Konnektors MUSS den Benutzer über den korrekten Gebrauch der Jobnummer informieren. Es MUSS ihm verdeutlichen, dass er seine PIN über die Tastatur des eHealth-Kartenterminals nur eingeben darf, wenn am Primärsystem und am Display des Kartenterminals die gleiche Jobnummer angezeigt wird. Stimmen die beiden Nummern nicht überein, so soll der Benutzer seine PIN nicht eingeben und stattdessen weitergehende Schritte zur Klärung des aufgetretenen Fehlverhaltens einleiten.
[<=]
TIP1-A_4642 - Ableitung der Jobnummer von einem Zufallswert
Zur hinreichend eindeutigen Kennzeichnung des Vorganges MUSS eine Jobnummer von einem Zufallswert abgeleitet sein, wobei die Vorgaben an einen solchen Zufallswert beachtet werden MÜSSEN [gemSpec_Krypt#2.2].
[<=]TIP1-A_4643 - Beschaffenheit der Jobnummer
Zur Wahrung der Benutzerfreundlichkeit MUSS eine Reduzierung der Jobnummer auf eine Länge von sechs Zeichen erfolgen. Diese sechs Zeichen MÜSSEN in zwei Zeichengruppen mit je drei Zeichen, getrennt durch einen Bindestrich (0x2D), dargestellt werden. Die erste Zeichengruppe MUSS ausschließlich die Zeichen "A-Z" beinhalten, die zweite Zeichengruppe MUSS aus Ziffern "0-9" bestehen. Die Länge der resultierenden, reduzierten Jobnummer ist sieben und wird durch den Umfang der darstellbaren Zeichen auf dem Display des eHealth-Kartenterminals beschränkt.
[<=]
TIP1-A_4644 - Jobnummer über 1.000 Vorgänge eindeutig
Der Konnektor MUSS die Eindeutigkeit einer Jobnummer sicherstellen:
- Bei Aufruf der Operation GetJobnumber MUSS der Konnektor innerhalb von 1000 Aufrufen eine eindeutige Jobnummer generieren. Die Zählung der Aufrufe erfolgt dabei unabhängig vom Aufrufkontext.
- Wird die Operation SignDocument mit einer Jobnummer aufgerufen, die innerhalb der vorangegangenen 1.000 Vorgänge verwendet wurde, so MUSS der Konnektor die Bearbeitung mit dem Fehler 4252 abbrechen. Die Zählung der Aufrufe erfolgt dabei unabhängig vom Aufrufkontext.
TIP1-A_4645 - Zeichen der Jobnummer
Die einzelnen Zeichen der Jobnummer MÜSSEN für die Anzeige am Kartenterminal gemäß dem Zeichensatz ISO 646DE/DIN66003, bzw. ISO 646 US codiert werden. Aus diesem Zeichensatz dürfen nur die Zeichen „A-Z“ (0x41 bis 0x5A) und die Ziffern „0-9“ (0x30 bis 0x39) für die Anzeige der Jobnummer verwendet werden.
[<=]
Beispiele für eine Jobnummer sind ABC-475 und HZF-696.
Die Einbettung der Jobnummer in den Nachrichtentext für den Bildschirm des Kartenlesers wird in TAB_KON_090 Terminalanzeigen beim Eingeben der PIN am Kartenterminal beschrieben.
4.1.8.1.5 Komfortsignatur
Für die QES unterstützt der Konnektor die Komfortsignaturfunktion. In diesem Modus können für ein- und denselben HBA mehrere vom Clientsystem initiierte Signaturaufträge (Einzel- oder Stapelsignatur) abgearbeitet werden, ohne dass der Inhaber des HBA für jeden einzelnen dieser Signaturaufträge die PIN.QES am Kartenterminal eingegeben muss.
Im Auslieferungszustand ist die Komfortsignaturfunktion ausgeschaltet (SAK_COMFORT_SIGNATURE = Disabled), d. h. mit dem Konnektor können zunächst keine Komfortsignaturen durchgeführt werden. Die Komfortsignaturfunktion kann vom Administrator eingeschaltet werden. Dies ist nur möglich, wenn an der Clientsystemschnittstelle des Konnektors verpflichtend TLS mit Clientauthentisierung (Konfigurationsvariante SOAP1 und SOAP2 in TAB_KON_852) konfiguriert ist. Das Einschalten der Komfortsignaturfunktion im Konnektor hat zur Folge, dass alle Operationen an der Clientsystemschnittstelle nur über TLS mit Clientauthentisierung angesprochen werden können (außer ggf. Dienstverzeichnisdienst).
Bei eingeschalteter Komfortsignaturfunktion können potentiell alle HBAs in der Umgebung, in der der Konnektor eingesetzt ist, Komfortsignaturen durchführen. Die eigentliche Aktivierung der Komfortsignatur muss separat für jede einzelne HBA-CardSession erfolgen.
Durch Aufruf der Operation ActivateComfortSignature des Konnektors durch das Primärsystem wird die Nutzung der Komfortsignatur für eine HBA-CardSession (Komfortsignaturmodus) aktiviert. Dazu muss der HBA-Inhaber die PIN.QES eingeben.
Der Konnektor merkt sich für die Cardsession des HBA, dass die Komfortsignatur aktiviert wurde. Bei den folgenden Aufrufen von SignDocumentwerden dann Komfortsignaturen ausgeführt, solange bis eines der folgenden Abbruchkriterien eintritt:
· Die vom HBA (entsprechend Personalisierung) oder die vom Konnektor (entsprechend Konfiguration SAK_COMFORT_SIGNATURE_MAX) durchgesetzte maximale Anzahl von Signaturen wurde erreicht.
· Das konfigurierte Zeitintervall für die Komfortsignatur (entsprechend Konfiguration SAK_COMFORT_SIGNATURE_TIMER) ist für die Cardsession abgelaufen.
· Der Komfortsignaturmodus wurde für die betroffene Cardsession deaktiviert.
· Der HBA wurde gezogen.
· Der Sicherheitszustand des HBA wurde zurückgesetzt.
· Die Komfortsignaturfunktion wurde für den Konnektor durch den Administrator deaktiviert.
A_19945 - Unterstützte Signaturvarianten bei Komfortsignatur
Der Signaturdienst MUSS bei der Komfortsignatur die Signaturvarianten für die QES gemäß TAB_KON_778 unterstützen. [<=]
A_18597 - Sicherheitszustand der PIN.QES bei Komfortsignatur
Bei der Komfortsignatur DARF der Konnektor den Sicherheitszustand der PIN.QES NICHT selbsttätig zurücksetzen, außer wenn dies explizit spezifikatorisch gefordert wird. [<=]
A_18597 kann z. B. umgesetzt werden, indem
· ein dedizierter logischer Kanal des HBA für die Komfortsignatur verwendet wird und
· im dedizierten logischen Kanal des HBA die Selektion von DF.QES solange beibehalten wird, bis ein Verlassen von DF.QES durch die Spezifikation explizit gefordert wird.
A_18686-01 - Komfortsignatur-Timer
Der Konnektor MUSS für jede HBA-Kartensitzung mit eingeschalteter Komfortsignatur einen Komfortsignatur-Timer gemäß konfiguriertem Zeitintervall SAK_COMFORT_SIGNATURE_TIMER einrichten.
Der Konnektor DARF nach Erreichen des Maximalwerts des Timers NICHT weitere Signaturaufträge annehmen.
Der Konnektor MUSS den Sicherheitszustand des HBA nach Erreichen des Maximalwertes des Timers zurücksetzen, nachdem Signaturaufträge, die bis zu diesem Zeitpunkt bereits zur Bearbeitung angenommen wurden, vollständig abgearbeitet wurden.
[<=]
A_19100-01 - Komfortsignatur-Zähler
Der Konnektor MUSS für jede HBA-Kartensitzung mit eingeschalteter Komfortsignatur die an die Karte gesendeten Signaturaufträge zählen und nach Erreichen von SAK_COMFORT_SIGNATURE_MAX den Sicherheitszustand des HBA zurücksetzen.
[<=]
A_19258 - Secure Messaging bei Komfortsignatur
Bei der Komfortsignatur MUSS der Signaturdienst die zu signierenden Daten (DTBS) über Secure Messaging vom Konnektor zum HBA übertragen. Dieser Secure Messaging-Kanal MUSS über die gSMC-K zum HBA mittels C.SAK.AUTD_CVC aufgebaut werden. [<=]
A_20073-01 - Prüfung der Länge der UserId
Der Konnektor MUSS die beim Aktivieren des Komfortsignaturmodus vom PS übermittelte UserId für die Kartensitzung des HBA, für den der Modus aktiviert wird, auf die ausreichende Länge von 128 Bit im Format einer UUID nach RFC4122 prüfen und die Aktivierung mit Fehler 4272 ablehnen, wenn die UserId nicht ausreichend lang ist. [<=]
A_20074 - UserId über 1.000 Vorgänge eindeutig
Der Konnektor MUSS die Eindeutigkeit der UserId sicherstellen. Wird die Operation ActivateComfortSignature mit einer UserId im Aufrufkontext aufgerufen, die innerhalb der vorangegangenen 1.000 Vorgänge bereits verwendet wurde, so MUSS der Konnektor die Bearbeitung mit dem Fehler 4270 abbrechen. Die Zählung der Aufrufe erfolgt dabei unabhängig vom Aufrufkontext. [<=]
A_19101 - Handbuch-Hinweis zu Nutzerauthentisierung am Clientsystem bei Komfortsignatur
Das Handbuch des Konnektors MUSS einen Hinweis enthalten, dass die Authentifizierung des HBA-Inhabers für die Komfortsignatur vom Clientsystem vorgenommen wird und dass die Authentifizierung des Nutzers am Clientsystem einen unverzichtbaren Beitrag zur Sicherheit der Lösung leistet. [<=]
A_22344 - Mindestens zwei parallele Komfortsignatursessions für einen HBA
Der Konnektor MUSS mindestens zwei parallele Komfortsignatursessions für ein- und denselben HBA unterstützen.
[<=]
Es kann davon ausgegangen werden, dass in den Einsatzumgebungen des Konnektors fachlicher Bedarf an mehr als zwei parallelen Komfortsignatursessions besteht. Daher wird empfohlen, mehr als zwei Sessions zu unterstützen.
Um pro Session die maximal erlaubte Anzahl von Signaturen (SAK_COMFORT_SIGNATURE_MAX) ausschöpfen zu können, sollen für parallele Komfortsignatursessions nach Möglichkeit mehrere logische Kanäle des HBA verwendet werden.
Der Konnektor soll sich robust verhalten, wenn zu einem HBA Signaturaufträge von unterschiedlichen Clientsystemen aus eintreffen, während vorherige Signaturaufträge noch nicht vollständig abgearbeitet sind. Nach Möglichkeit sollen gleichzeitig eintreffende Signaturaufträge angenommen und abgearbeitet werden.
A_22352 - Unabhängige Komfortsignatur-Timer bei parallelen Komfortsignatursessions
Der Konnektor SOLL die Komfortsignatur-Timer paralleler Komfortsignatursessions für ein- und denselben HBA so umsetzen, dass diese unabhängig voneinander wirken. [<=]
A_22459 - Unabhängige Komfortsignatur-Zähler bei parallelen Komfortsignatursessions
Der Konnektor SOLL die Komfortsignatur-Zähler paralleler Komfortsignatursessions für ein- und denselben HBA so umsetzen, dass diese unter Berücksichtigung der Limitierungen der Karte unabhängig voneinander wirken. [<=]
4.1.8.2 Durch Ereignisse ausgelöste Reaktionen
keine
4.1.8.3 Interne TUCs, nicht durch Fachmodule nutzbar
Abbildung PIC_KON_103 Use Case Diagramm Signaturdienst (nonQES) beschreibt die Aufrufbeziehungen der nonQES-TUCs des Signaturdienstes. Die TUCs des Signaturdienstes sind weiß dargestellt. Genutzte TUCs anderer Basisdienste sind grau hinterlegt.
Abbildung 15: PIC_KON_103 Use Case Diagramm Signaturdienst (nonQES)
Abbildung PIC_KON_104 Use Case Diagramm Signaturdienst (QES) beschreibt die Aufrufbeziehungen der QES-TUCs des Signaturdienstes.
Abbildung 16: PIC_KON_104 Use Case Diagramm Signaturdienst (QES)
Abbildung PIC_KON_102 Use Case Diagramm Signaturdienst (Komfortsignatur) beschreibt die Aufrufbeziehungen der TUCs des Signaturdienstes für die Komfortsignatur.
Abbildung 17: PIC_KON_102 Use Case Diagramm Signaturdienst (Komfortsignatur)
4.1.8.3.1 TUC_KON_155 „Dokumente zur Signatur vorbereiten”
TIP1-A_4646-06 - TUC_KON_155 „Dokumente zur Signatur vorbereiten“
Der Konnektor MUSS den technischen Use Case TUC_KON_155 „Dokumente zur Signatur vorbereiten” umsetzen.
Tabelle 196: TAB_KON_748 - TUC_KON_155 „Dokumente zur Signatur vorbereiten“
Element |
Beschreibung |
Name |
TUC_KON_155 ”Dokumente zur Signatur vorbereiten” |
Beschreibung |
Die zu signierenden Dokumente werden entsprechend den Erfordernissen der Signaturverfahren für die QES oder nonQES vorbereitet. |
Anwendungsumfeld |
Erstellung von qualifizierten elektronischen Signaturen (QES) und nicht-qualifizierten elektronischen Signaturen (nonQES) |
Auslöser |
Aufruf durch TUC_KON_150 „Dokumente QES signieren“ oder TUC_KON_160 „Dokumente nonQES signieren“ |
Vorbedingungen |
keine |
Eingangsdaten |
- signatureMode (Signaturart: QES | nonQES) - documentsToBeSigned (Zu signierendes Dokument bzw. zu signierende Dokumente) und pro Dokument: - documentFormat (Formatangabe für das zu signierende Dokument) - optionalInputs (weitere optionale Eingabeparameter zur Steuerung der Details bei der zu erstellenden Signatur (siehe Operation SignDocument, Parameter dss:OptionalInputs), darin u.a. -signatureType (URI für den Signaturtyp XML-, CMS-, S/MIME-o PDF-Signatur) - certificate (Signaturzertifikat) |
Komponenten |
Konnektor |
Ausgangsdaten |
|
Standardablauf |
signatureType = XMLDSig (XAdES) Entsprechend den Regeln für die QES und die nonQES werden zunächst weitere Signatureigenschaften zum jeweiligen Dokument in Form von QualifyingProperties (siehe [XAdES]) hinzugefügt. Die Systemzeit des Anwendungskonnektors muss in das XML-Element SigningTime (siehe [XAdES]) eingetragen werden. Die Signatur wird anschließend entsprechend [XMLDSig] vorbereitet. D. h., es wird je Dokument nach Erzeugung der Reference Elemente das SignedInfo Element aufgebaut. Dessen Inhalt ergibt dann nach erfolgter XML-Kanonisierung und Hashing die DTBS (Data To Be Signed), die später zur Karte gesendet werden. certificate wird im Element ds:KeyInfo/ds:X509Data gespeichert. Im Fall signatureMode = QES können neben den reinen Nutzdaten auch alle weiteren Elemente in die Signatur einbezogen werden, die für die Rekonstruktion der ursprünglich dargestellten Daten in der sicheren Anzeige erforderlich sind. Für XML-Dokumente sind das, falls vorhanden, das/die XML-Schema(ta). Für diese werden Referenzen (Hash + URI) in die Signatur eingebettet. Die URI ist im Fall übergebener XML-Schemata der übergebene signatureType - Parameter. Die URI ist im Fall der im Konnektor im Rahmen einer Signaturrichtlinie hinterlegten XML-Schemata/XSL- Stylesheets die URI der Signaturrichtlinie, ergänzt um den Dateinamen mit Pfad, wie in der Signaturrichtlinie festgelegt. (Beispiel: URI für Schemadatei NFD_Document.xsd der Signaturrichtlinie SR_DF_NFDM_NOTFALLDATEN lautet: urn:gematik:fa:sak:nfdm:r1:v1:NFD_Document.xsd) Das Einbetten der Referenzen erfolgt über das XML-Element ds:object/ds:manifest (XMLDSig) mit eingebetteten XML-Elementen ds:Reference, die eine URI (RefURI) als Identifier für die jeweilige Datei und einen Hash über die jeweilige Resource enthalten. Der ShortTextClientsystem muss in die Signatur in das DataObjectFormat/Description-Element gemäß [XAdES] (Abschnitt 7.2.5) eingebettet werden. signatureType = CMS (CAdES) Etwaig einzubettende XML-Schemata werden zunächst wie für XAdES definiert in ein ds:manifest-Element eingebettet. Die so erzeugte Zeichenkette wird als genau ein ASN.1 Character String vom Typ UTF8String verpackt. Dieser wird als contentDescription in einen Content-Hints Attributwert vom Typ ContentHints verpackt, wobei der contentType=id-data gemäß [CAdES]. Der ShortTextClientsystem muss in die Signatur in das content- hints.ContentDescription-Attribut gemäß [CAdES] (Abschnitt 5.10.3) eingebettet werden. signatureType = PDF/A (PAdES) Der ShortTextClientsystem muss bei einer PDF-Signatur in das Reason-Feld eingebettet werden. Es sind die Vorgaben zum Signaturprofil gemäß Tabelle TAB_KON_779-01 „Profilierung der Signaturformate“ zu erfüllen. Die aufbereiteten zu signierenden Dokumente werden an den Aufrufer zurückgegeben. |
Varianten/ Alternativen |
keine |
Fehlerfälle |
Das Verhalten des TUCs bei einem Fehlerfall ist in TAB_KON_586 Fehlercodes TUC_KON_155 „Dokumente zur Signatur vorbereiten“ „PDF/A (PAdES)“ Es ist nicht genügend Speicherplatz im PDF-Dokument verfügbar: 4205 |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
Tabelle 197: TAB_KON_586 Fehlercodes TUC_KON_155 „Dokumente zur Signatur vorbereiten“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
4205 |
Technical |
Error |
Es ist nicht genügend Speicherplatz im PDF-Dokument verfügbar. |
4.1.8.3.2 TUC_KON_165 „Signaturvoraussetzungen für nonQES prüfen“
TIP1-A_4647-03 - TUC_KON 165 „Signaturvoraussetzungen für nonQES prüfen“
Der Konnektor MUSS den technischen Use Case „Signaturvoraussetzungen für nonQES prüfen” umsetzen.
Tabelle 198: TAB_KON_749 – TUC_KON_165 „Signaturvoraussetzungen für nonQES prüfen“
Element |
Beschreibung |
Name |
TUC_KON_165 „Signaturvoraussetzungen für nonQES prüfen“ |
Beschreibung |
Es werden die Voraussetzungen an die zu signierenden Dokumente und das Signaturzertifikat geprüft. Es werden die nonQES_DocFormate unterstützt. |
Auslöser |
TUC_KON_160 „Dokumente nonQES signieren“ |
Vorbedingungen |
keine |
Eingangsdaten |
|
Komponenten |
Konnektor, Kartenterminal, Signaturkarte |
Ausgangsdaten |
|
Standardablauf |
|
Varianten/Alterna-tiven |
(->2,3) Es dürfen alternativ die vollständigen cached Zertifikatsprüfungsdaten ohne Aufruf von TUC_KON_216 und TUC_KON_037 verwendet werden. |
Fehlerfälle |
Keine |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
Tabelle 199: TAB_KON_587 Fehlercodes TUC_KON_165 „Signaturvoraussetzungen für nonQES prüfen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können keine weiteren Fehlercodes auftreten. |
4.1.8.3.3 TUC_KON_166 „nonQES Signaturen erstellen“
TIP1-A_4648 - TUC_KON_166 „nonQES Signaturen erstellen“
Der Konnektor MUSS den technischen Use Case TUC_KON_166 „nonQES Signaturen erstellen” umsetzen.
Tabelle 200: TAB_KON_750 – TUC_KON_166 „nonQES Signaturen erstellen“
Element |
Beschreibung |
Name |
TUC_KON_166 „nonQES Signaturen erstellen“ |
Beschreibung |
Die Data To Be Signed (DTBS) werden erzeugt, an die Signaturkarte gesendet und dort signiert. |
Auslöser |
TUC_KON_160 „Dokumente nonQES signieren“ |
Vorbedingungen |
keine |
Eingangsdaten |
|
Komponenten |
Konnektor, Kartenterminal, Signaturkarte |
Ausgangsdaten |
|
Standardablauf |
Die folgenden Schritte werden für jedes Dokument der Liste durchgeführt.
|
Varianten/Alternativen |
keine |
Fehlerfälle |
Fehler in den folgenden Schritten des Standardablaufs führen zum Abbruch mit den ausgewiesenen Fehlercodes: (3) Fehlgeschlagene mathematische Prüfung der Signatur: 4120 |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
Tabelle 201: TAB_KON_120 Fehlercodes TUC_KON_166 „nonQES Signaturen erstellen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4120 |
Security |
Error |
Kartenfehler |
[<=]
4.1.8.3.4 TUC_KON_152 "Signaturvoraussetzungen für QES prüfen"
TIP1-A_4649-02 - TUC_KON_152 „Signaturvoraussetzungen für QES prüfen“
Der Konnektor MUSS den technischen Use Case TUC_KON_152 „Signaturvoraussetzungen für QES prüfen” umsetzen.
Tabelle 202: TAB_KON_751 – TUC_KON_152 „Signaturvoraussetzungen für QES prüfen“
Element |
Beschreibung |
Name |
TUC_KON_152 „Signaturvoraussetzungen für QES prüfen“ |
Beschreibung |
Es werden die Voraussetzungen an die zu signierenden Dokumente und das Signaturzertifikat geprüft. Es werden die QES_DocFormate unterstützt. |
Auslöser |
TUC_KON_150 „Dokumente QES signieren“ |
Vorbedingungen |
keine |
Eingangsdaten |
|
Komponenten |
Konnektor, Kartenterminal, Signaturkarte |
Ausgangsdaten |
|
Standardablauf |
|
Varianten/Alternativen |
(->2,3) Es dürfen alternativ die vollständigen cached Zertifikatsprüfungsdaten ohne Aufruf von TUC_KON_216 und TUC_KON_037 verwendet werden. |
Fehlerfälle |
(->3) Für MGM_LU_ONLINE=Enabled gilt: Liefert die Zertifikatsprüfung (OCSP-Abfrage) die Warnung CERT_REVOKED oder CERT_UNKNOWN gemäß [gemSpec_PKI#Tab_PKI_274], dann wird der TUC mit Fehler 4123 abgebrochen. |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
Tabelle 203: TAB_KON_588 Fehlercodes TUC_KON_152 „Signaturvoraussetzungen für QES prüfen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können keine weiteren Fehlercodes auftreten. |
[<=]
4.1.8.3.5 TUC_KON_154 "QES Signaturen erstellen"
Der TUC_KON_154 stellt den Standardsignaturfall in der TI, die Stapelsignatur dar (auch für Stapel der Größe 1). Da die Stapelsignatur auf der Zielkarte passende CVC voraussetzt, die auf den HBA-Vorläuferkarten nicht vorhanden sind, kann dieser TUC nur den HBA unterstützen. Für HBA-Vorläuferkarten kann TUC_KON_168 verwendet werden.
TIP1-A_4651-02 - TUC_KON_154 „QES Signaturen erstellen“
Der Konnektor MUSS den technischen Use Case TUC_KON_154 „QES Signaturen erstellen” umsetzen.
Tabelle 204: TAB_KON_752 – TUC_KON_154 „QES Signaturen erstellen"
Element |
Beschreibung |
---|---|
Name |
TUC_KON_154 „QES Signaturen erstellen“ |
Beschreibung |
Die Data To Be Signed (DTBS) werden erzeugt, an die Signaturkarte gesendet und dort signiert. |
Auslöser |
TUC_KON_150 „Dokumente QES signieren“ |
Vorbedingungen |
Die Ressourcen Signaturkarte und Kartenterminal sind für den Vorgang reserviert. DF.QES ist selektiert. PIN.QES ist initial verifiziert |
Eingangsdaten |
|
Komponenten |
Konnektor, Kartenterminal, Signaturkarte (HBA) |
Ausgangsdaten |
|
Standardablauf |
Basierend auf SAK.AUTD_CVC und HPC.AUTD_SUK_CVC und den zugehörigen privaten Schlüsseln wird ein sicherer Kanal zwischen der gSMC-K des Konnektors und dem HBA aufgebaut mittels Aufruf TUC_KON_005 „Card-to-Card authentisieren“ { sourceCardSession = gSMC-K; targetCardSession = CardSession; authMode = „gegenseitig+TC“} Die folgenden Schritte werden für jedes Dokument des Stapels durchgeführt.
|
Varianten/ Alternativen |
Alternativ zum Standardablauf kann zu Beginn die maximal erlaubte Stapelgröße SSEC durch Auslesen von EF.SSEC ermittelt werden. Der zu signierende Dokumentenstapel wird in Teilstapel von maximaler Größe SSEC zerlegt. Für jeden Teilstapel wird die PIN.QES verifiziert. Die Dokumente des Teilstapels werden wie im Standardablauf beschrieben signiert. Der Nutzer kann den Vorgang der PIN-Eingabe abbrechen. |
Fehlerfälle |
(->2) Fehler im Signaturvorgang führen zum Abbruch des gesamten Signaturvorgangs, Fehlercode 4123 (->3) Fehler bei der PIN-Eingabe führen zum Abbruch des Signaturvorgangs (->4) Fehler in mathematischer Prüfung der Signatur führen zum Abbruch des Signaturvorgangs, Fehlercode 4120 Das Verhalten des TUCs bei einem Fehlerfall, einem Timeout der PIN-Eingabe oder beim Abbruch durch den Benutzer ist in Tabelle TAB_KON_192 Verhalten des Konnektors beim Abbruch einer Stapelsignatur beschrieben. |
Sicherheitsanforderungen |
Zum Aufbau des sicheren Kanals bzw. zur Aushandlung des symmetrischen Schlüssels DARF DF.QES NICHT verlassen werden. Benötigte CVCs des HBA MÜSSEN also bereits vor dem Signaturvorgang eingelesen und gecacht werden. Dies KANN bereits beim Stecken des HBA geschehen. Die in [gemSpec_Krypt#3.1.2] angegebenen Festlegungen der zu unterstützenden Algorithmen MÜSSEN berücksichtigt werden. |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
Abbildung PIC_KON_113 Aktivitätsdiagramm zu „QES Signaturen erstellen“ Das Diagramm dient nur der Veranschaulichung und ist nicht vollständig. Beispielsweise enthält es nicht die Steuerung durch den Parameter crypt. |
Abbildung 18: PIC_KON_113 Aktivitätsdiagramm zu „QES Signaturen erstellen“
Tabelle 205: TAB_KON_126 Fehlercodes TUC_KON_154 „QES Signaturen erstellen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4120 |
Security |
Error |
Kartenfehler |
4123 |
Security |
Error |
Fehler bei Signaturerstellung |
4.1.8.3.6 TUC_KON_168 „Einzelsignatur QES erstellen“
TIP1-A_4652-02 - TUC_KON_168 „Einzelsignatur QES erstellen“
Der Konnektor MUSS den technischen Use Case TUC_KON_168 „Einzelsignatur QES erstellen“ umsetzen.
Tabelle 206: TAB_KON_293 - TUC_KON_168 „Einzelsignatur QES erstellen“
Element |
Beschreibung |
Name |
TUC_KON_168 ”Einzelsignatur QES erstellen” |
Beschreibung |
Es wird ein Dokument technisch mit einer Signatur versehen. Im Gegensatz zum TUC_KON_154 „QES Signaturen erstellen“ wird hier nur eine einzelne Signatur ohne vorhergehendes C2C erstellt. Die Übertragung der DTBS erfolgt ohne Secure Messaging. |
Auslöser |
TUC_KON_150 Dokumente QES signieren |
Vorbedingungen |
Die Ressourcen Signaturkarte und Kartenterminal sind für den Vorgang reserviert. DF.QES ist selektiert. |
Eingangsdaten |
|
Komponenten |
Konnektor, Kartenterminal, Signaturkarte (HBAx) |
Ausgangsdaten |
|
Standardablauf |
|
Varianten/ Alternativen |
keine |
Fehlerfälle |
Das Verhalten des TUCs bei einem Fehlerfall, einem Timeout der PIN-Eingabe oder beim Abbruch durch den Benutzer ist in Tabelle TAB_KON_192 Verhalten des Konnektors beim Abbruch einer Stapelsignatur beschrieben. (3) Fehler in mathematischer Prüfung der Signatur: Abbruch mit 4120 |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
Tabelle 207: TAB_KON_590 Fehlercodes TUC_KON_168 „Einzelsignatur QES erstellen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
|
---|---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten. |
||||
4120 |
Security |
Error |
Kartenfehler |
[<=]
4.1.8.3.7 TUC_KON_158 "Komfortsignaturen erstellen"
Der TUC_KON_158 führt die Komfortsignatur für ein Dokument oder mehrere Dokumente eines Stapels aus. Da die Komfortsignatur auf der Zielkarte passende CVC voraussetzt, die auf den HBA-Vorläuferkarten nicht vorhanden sind, unterstützt dieser TUC nur den HBA.
A_19102-04 - TUC_KON_158 „Komfortsignaturen erstellen“
Der Konnektor MUSS den technischen Use Case TUC_KON_158 „Komfortsignaturen erstellen” umsetzen.
Tabelle 208: TAB_KON_870 – TUC_KON_158 „Komfortsignaturen erstellen"
Element |
Beschreibung |
Name |
TUC_KON_158 „Komfortsignaturen erstellen“ |
Beschreibung |
Die Data To Be Signed (DTBS) werden erzeugt, an die Signaturkarte gesendet und dort signiert. Die Übertragung der DTBS erfolgt mit Secure Messaging. Die Abarbeitung der Signatur erfolgt im SE#2. |
Auslöser |
TUC_KON_170 „Dokumente mit Komfort signieren“ |
Vorbedingungen |
Die Ressource Signaturkarte ist für den Vorgang reserviert. DF.QES ist selektiert. PIN.QES ist initial verifiziert |
Eingangsdaten |
·
Zu signierendes Dokument bzw. zu signierende Dokumente
·
cardSession (nur HBA erlaubt)
·
zu verwendende Identität (Zertifikatsreferenz)
·
crypt [SIG_CRYPT_QES] -
optional
;
default und Wertebereich: siehe TAB_KON_862-01 (Dieser Parameter steuert, ob RSA-basierte oder ECC-basierte Signaturen erzeugt werden.)
·
WorkplaceId
|
Komponenten |
Konnektor, Kartenterminal, Signaturkarte (HBA) |
Ausgangsdaten |
·
Signierte Dokumente
|
Standardablauf |
1.
Wenn noch nicht erfolgt, wird basierend auf SAK.AUTD_CVC und HPC.AUTD_SUK_CVC und den zugehörigen privaten Schlüsseln ein sicherer Kanal zwischen der gSMC-K des Konnektors und dem HBA aufgebaut mittels Aufruf TUC_KON_005 „Card-to-Card authentisieren“ {
sourceCardSession = gSMC-K; targetCardSession = CardSession; authMode = „gegenseitig+TC“} Die folgenden Schritte werden für jedes Dokument des Stapels durchgeführt.
2. Das zu signierende Dokument wird, soweit noch nicht erfolgt, für die Signatur gemäß des entsprechenden Formats vorbereitet. Ein Ergebnis dieser Vorbereitung sind die Data To Be Signed (DTBS): der Hash-Wert (Digest des SignedInfo-Elementes), der zur Signatur an die Karte gesendet werden soll.
3. Es wird geprüft, ob der Komfortsignatur-Zähler der cardSession den Wert SAK_COMFORT_SIGNATURE_MAX überschritten hat .
4. Für das zu signierende Dokument werden die DTBS zur Signatur im sicheren Kanal an den HBA übermittelt (Aufruf TUC_KON_218 „Signiere“). Dabei werden der Schlüssel und der Algorithmusidentifier über die Tabelle TAB_KON_900 bestimmt.
5. Der Komfortsignatur-Zähler der cardSession wird um 1 erhöht.
6. Die erstellte Signatur wird mathematisch geprüft.
7. Der ermittelte Signaturwert wird in den zuvor vorbereiteten Signaturprototypen eingefügt.
8.
Der Konnektor löst TUC_KON_256 {"SIG/SIGNDOC/NEXT_SUCCESSFUL"; Op; Info; „$Jobnummer"; noLog; $doInformClients } aus.
|
Varianten/ Alternatien |
Keine |
Fehlerfälle |
In den Fehlerfällen, die zum Abbruch des Komfortsignaturmodus mit Fehlercode 4271 führen, wird vor dem Abbruch TUC_KON_172 für das cardHandle des HBA ausgeführt. (->3) Der Komfortsignatur-Zähler der cardSession hat den Maximalwert überschritten: Fehlercode 4271 (->4) Der PIN.QES-Nutzungszähler der Karte ist abgelaufen (erkennbar z. B. daran, dass die Karte einen Autorisierungsfehler zurückmeldet): Fehlercode 4271 (->4) Fehler im Signaturvorgang führen zum Abbruch des gesamten Signaturvorgangs: Fehlercode 4123 (->6) Fehler in mathematischer Prüfung der Signatur führen zum Abbruch des Signaturvorgangs: Fehlercode 4120 Das weitere Verhalten des TUCs bei einem Fehlerfall oder beim Abbruch durch den Benutzer ist in TAB_KON_192, Verhalten des Konnektors beim Abbruch einer Stapelsignatur, beschrieben. |
Sicherheitsanforderungen |
Zum Aufbau des sicheren Kanals bzw. zur Aushandlung des symmetrischen Schlüssels DARF DF.QES NICHT verlassen werden. Benötigte CVCs des HBA MÜSSEN also bereits vor dem Signaturvorgang eingelesen und gecached werden. Dies KANN bereits beim Stecken des HBA geschehen. Komfortsignaturen MÜSSEN im SE#2 abgearbeitet werden. Die in [gemSpec_Krypt] angegebenen Festlegungen der zu unterstützenden Algorithmen MÜSSEN berücksichtigt werden. |
Tabelle 209: TAB_KON_873 Fehlercodes TUC_KON_158 „Komfortsignaturen erstellen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4120 |
Security |
Error |
Kartenfehler |
4123 |
Security |
Error |
Fehler bei Signaturerstellung |
4.1.8.3.8 TUC_KON_159 "Signaturdatenelemente nachbereiten"
A_23536 - TUC_KON_159 - "Signaturdatenelemente nachbereiten"
Der Konnektor MUSS den technischen Use Case TUC_KON_159 "Signaturdatenelemente nachbereiten" umsetzen.
Tabelle 210 : TAB_KON_892 – TUC_KON_159 „Signaturdatenelemente nachbereiten"
Element |
Beschreibung |
Name |
TUC_KON_159 „Signaturdatenelemente nachbereiten“ |
Beschreibung |
Es wird für das verwendete Signaturzertifikat die Statusauskunft eingeholt, überprüft und falls gefordert, in die vorab erstellte Signatur eingebettet. |
Auslöser |
TUC_KON_150 „Dokumente QES signieren“, TUC_KON_170 Dokumente mit Komfort signieren", TUC_KON_160 „Dokumente nonQES signieren“ |
Vorbedingungen |
keine |
Eingangsdaten |
•
signatureMode (Signaturart: QES | nonQES)
•
Signierte Dokumente / signiertes Dokument
•
signatureType
(URI für den Signaturtyp XML-, CMS-, S/MIME- oder PDF-Signatur)
•
Zertifikatsreferenz (zu verwendende Signatur-Identität)
•
includeRevocationInfo [Boolean] - optional; Default: true
(Dieser Parameter steuert die Einbettung von OCSP-Responses in die Signatur. true: Die Sperrinformationen werden in die Signatur eingebettet.) |
Komponenten |
Konnektor, Kartenterminal, Signaturkarte |
Ausgangsdaten |
•
Prüfergebnis für das Zertifikat
•
Signiertes Dokument/ Dokumente mit eingebetteter OCSP-Antwort
optional/nur wenn includeRevocationInfo = true |
Standardablauf |
1.
Das Signaturzertifikat wird durch Aufruf von TUC_KON_037 „Zertifikat prüfen“{
certificate = Zertifikatsreferenz; qualifiedCheck = required; offlineAllowNoCheck = true; validationMode = OCSP; getOCSPResponses = includeRevocationInfo} geprüft.
2.
Falls includeRevocationInfo== true wird die OCSP-Antwort gemäß des signatureType in die Signatur für jedes Dokument eingebettet.
signatureType = XMLDSig (XAdES) Einbettung der OCSP-Response im Sinne vom AdES-X-L; die base-64 kodierte OCSP-Response wird im Feld QualifyingProperties/UnsignedProperties /UnsignedSignatureProperties/RevocationValues /OCSPValues/EncapsulatedOCSPValue (selbst DER-kodiert) gespeichert. signatureType = CMS (CAdES) Ist die Einbettung von OCSP-Responses gefordert, wird die für die Offline-Prüfung notwendige OCSP-Antwort des EE-Zertifikats im Attribut SignedData.crls.other abgelegt. signatureType = PDF/A (PAdES) OCSP-Responses werden bei PAdES nicht eingebettet. |
Varianten/Alternativen |
keine |
Fehlerfälle |
(->1) Für MGM_LU_ONLINE=Enabled gilt: Liefert die Zertifikatsprüfung (OCSP-Abfrage) die Warnung CERT_REVOKED oder CERT_UNKNOWN gemäß [gemSpec_PKI#Tab_PKI_274], dann wird der TUC mit Fehler 4123 abgebrochen. |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
Tabelle 211 : TAB_KON_893 Fehlercodes TUC_KON_159 „Signaturdatenelemente nachbereiten
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4123 |
Security |
Error |
Fehler bei Signaturerstellung |
[<=]
4.1.8.4 Interne TUCs, auch durch Fachmodule nutzbar
A_20478 - Zusätzliche Dokumentformate für nonQES-Signatur
Der Konnektor KANN für die nonQES-Signaturerstellung an der Schnittstelle zu Fachmodulen zusätzliche Dokumentformate unterstützen. [<=]
Die in der obigen Anforderung benannten Signaturen von Dokumentenformaten umfassen beispielsweise die Signatur von Token nach SAML2 für das Fachmodul ePA entsprechend [gemSpec_FM_ePA#A_14927].
4.1.8.4.1 TUC_KON_160 „Dokumente nonQES signieren”
TIP1-A_4653-03 - TUC_KON_160 „Dokumente nonQES signieren“
Der Konnektor MUSS den technischen Use Case TUC_KON_160 „Dokumente nonQES signieren” umsetzen.
Tabelle 212: TAB_KON_753 – TUC_KON_160 „Dokumente nonQES signieren“
Element |
Beschreibung |
Name |
TUC_KON_160 „Dokumente nonQES signieren“ |
Beschreibung |
Im Rahmen von Fachanwendungen werden ein oder mehrere Dokumente mit einer nicht-qualifizierten elektronischen Signatur (nonQES) versehen. Es werden die nonQES_DocFormate unterstützt. |
Auslöser |
Aufruf durch ein Clientsystem (Operation SignDocument) oder ein Fachmodul. |
Vorbedingungen |
Die Signaturkarte muss gesteckt sein. |
Eingangsdaten |
|
Komponenten |
Konnektor, Kartenterminal, Signaturkarte bzw. HSM-B |
Ausgangsdaten |
|
Standardablauf |
Der Konnektor KANN die Schritte 1 bis 4 in einer beliebigen Reihenfolge durchführen.
|
Varianten/ Alternativen |
Im Fall signatureType=S/MIME-Signatur wird der Standardablauf des CMS Signaturverfahrens 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], Kapitel 3.1, auf die nachfolgende CMS-Signatur durch eine Kanonisierung für Text [S/MIME], Kapitel 3.1.1, vor. Eine weitere Kanonisierung oder eine Anpassung des Transfer Encodings [S/MIME], Kapitel 3.1.2, erfolgt nicht. Im S/MIME-Nachbereitungsschritt wird das im Standardablauf erzeugte 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. "MIME-Version: 1.0" MUSS definiert sein. Das Feld "Content-Type:" ist als "application/pkcs7-mime" zu definieren. Die weiteren Attribute dieses Feldes sind:
Das Feld "Content-Disposition" definiert den Inhalt der Nachricht als Dateianhang: "Content-Disposition: attachment; filename=$dateiname" |
Fehlerfälle |
Fehler in den folgenden Schritten des Standardablaufs führen zum Abbruch mit den ausgewiesenen Fehlercodes: (2) Ungültige Angabe des Signaturverfahrens: Fehlercode 4111 Übergabe eines für die nonQES nicht unterstützten Dokumentformats: Fehlercode 4110 (3) Kartentyp nicht zulässig für Signatur: Fehlercode 4126 (-> 5a) Liefert der Aufruf von TUC_KON_159 einen Fehler, werden die erstellten Signaturen verworfen. |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
Tabelle 213: TAB_KON_127 Fehlercodes TUC_KON_160 „Dokumente nonQES signieren“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4110 |
Technical |
Error |
ungültiges Dokumentformat (%Format%) Der Parameter Format enthält das übergebene Dokumentformat. |
4111 |
Technical |
Error |
ungültiger Signaturtyp oder Signaturvariante |
4126 |
Security |
Error |
Kartentyp nicht zulässig für Signatur |
Die zulässigen Zertifikate und Schlüssel sind in TAB_KON_900 aufgelistet. [<=]
4.1.8.4.2 TUC_KON_161 „nonQES Dokumentsignatur prüfen”
TIP1-A_4654-05 - TUC_KON_161 „nonQES Dokumentsignatur prüfen”
Der Konnektor MUSS den technischen Use Case TUC_KON_161 „nonQES Dokumentsignatur prüfen” umsetzen.
Tabelle 214: TAB_KON_121 - TUC_KON_161 „nonQES Dokumentsignatur prüfen“
Element |
Beschreibung |
---|---|
Name |
TUC_KON_161 „nonQES Dokumentsignatur prüfen” |
Beschreibung |
Es wird die nicht-qualifizierte elektronische Signatur (nonQES) eines Dokuments geprüft. Dabei werden die Signaturverfahren laut Tabelle TAB_KON_582 – Signaturverfahren unterstützt. Sind mehrere Signaturen vorhanden, so werden alle geprüft. Auch Parallel- und Gegensignaturen MÜSSEN unterstützt werden. Die unterstützten Zertifikatstyp-OIDs sind in der Tabelle TAB_KON_786 aufgelistet. |
Auslöser |
Aufruf durch ein Clientsystem (Operation VerifyDocument) oder ein Fachmodul |
Vorbedingungen |
keine |
Eingangsdaten |
(OCSP-Grace Period: maximal zulässiger Zeitraum, den die letzte OCSP-Antwort aus dem Cache bezüglich des Referenzzeitpunkts zurückliegen darf)
|
Komponenten |
Konnektor |
Ausgangsdaten |
|
Standardablauf |
XML-Signatur:
Die Core Validation erfolgt entsprechend [XMLDSig] Kapitel 3.2 Core Validation. CMS-Signatur: Die Core Validation erfolgt entsprechend Cryptographic Message Syntax (CMS) Kapitel 5.6 Signature Verification Process [RFC5652]. PDF-Signatur: Die Core Validation erfolgt entsprechend [PAdES-3] Kapitel 4.6 Signature Validation aus PAdES-BES Part 3. Auch wenn die Validierung fehlschlägt, werden die folgenden Prüfschritte durchgeführt, so dass ein vollständiges Prüfprotokoll erstellt werden kann.
Teil 1: Signaturzertifikat ermitteln
XML-Signatur: Das Signaturzertifikat ist im XMLDSig Element ds:KeyInfo/ds:X509Data gespeichert [XMLDSig] oder wird als Eingangsparameter übergeben. CMS-Signatur: Das Signaturzertifikat für CAdES ist im Feld certificates im SignedData Container gespeichert [CAdES] oder wird als Eingangsparameter übergeben. PDF-Signatur: Das PDF Signaturzertifikat für PAdES ist im Feld SignedData.certificates entsprechend Kapitel 6.1.1 „Placements of the signing certificate“ [PAdES Baseline Profile] gespeichert oder wird als Eingangsparameter übergeben.
Teil 2: Signaturzeitpunkt bestimmen
Der Signaturzeitpunkt Ermittelter_Signaturzeitpunkt_Eingebettet wird wie folgt selektiert: XML-Signatur:
Das XML element SigningTime spezifiziert den
Signaturzeitpunkt entsprechend Kapitel 7.2.1 XAdES
[XAdES].
CMS-Signatur:
Das Attribut SigningTime spezifiziert den
Signaturzeitpunkt entsprechend Kapitel 11.3 CMS [CMS].
PDF-Signatur:
Der Signaturzeitpunkt kann dem M Eintrag des Signature
Dictionary entnommen werden [PAdES Baseline Profile]
Kapitel 6.2.1 Signing time.
Der Signaturzeitpunkt
Benutzerdefinierter_Zeitpunkt liegt gegebenenfalls als Aufrufparameter vor. Der Signaturzeitpunkt
Ermittelter_Signaturzeitpunkt_System wird ermittelt.
Teil 3: Signaturzertifikatsprüfung:
Bei der folgenden Signaturzertifikatsprüfung sind die Signaturzeitpunkte gemäß [TIP1-A_5545] zu berücksichtigen.
Die Signaturzertifikatsprüfung erfolgt durch Aufruf von TUC_KON_037 „Zertifikat prüfen“.
Die Parameter im Aufruf von TUC_KON_037 „Zertifikat prüfen“ werden wie folgt gesetzt
In Abhängigkeit von der policyList gemäß Tabelle TAB_KON_786 gesetzte Parameter:
Sind OCSP-Responses in der Signatur eingebettet, ist die jüngste OCSP-Response, die für die Zertifikatsprüfung notwendig ist, beim Aufruf von TUC_KON_037 zu übergeben.
Sofern der Aufruf von TUC_KON_037 ocspResponsesRenewed zurückgibt, wird die Liste der OCSP-Responses in die Signatur eingebettet.
Die Warnung PROVIDED_OCSP_RESPONSE_NOT_VALID wird
nicht an den Aufrufer zurückgemeldet.
Auch wenn die Zertifikatsprüfung fehlschlägt, werden die folgenden Prüfungen durchgeführt.
In diesem Schritt wird das signierte Dokument entsprechend der Profilierung der Signaturformate (siehe Anhang B.2) geprüft.
Es sind die Vorgaben für die Prüfung von Signaturen aus den Standards für AdES [XAdES], [XAdES Baseline], [CAdES], [CAdES Baseline], [PAdES-3] und [PAdES Baseline] umzusetzen. Dabei sind die Vorgaben aus Tabelle TAB_KON_779-01 „Profilierung der Signaturformate“ und Tabelle TAB_KON_778 „Einsatzbereich der Signaturvarianten“ zu erfüllen. Auch wenn nicht alle Anforderungen an das Format des signierten Dokuments erfüllt werden, wird die Prüfung mit den folgenden Schritten fortgesetzt, um ein vollständiges Prüfungsprotokoll zu erhalten.
|
Varianten/ Alternativen |
Im Fall, dass die Online-Prüfung des Sperrzustands des Signaturzertifikats nicht möglich ist und eine möglicherweise gecachte OCSP-Response nicht vorhanden ist oder nicht mehr verwendet werden darf, wird das Prüfergebnis mit der entsprechenden Warnung zurückgegeben. Im Fall einer PKCS#1-Signatur ist das verwendete Signaturverfahren, RSASSA-PSS bzw. RSASSA-PKCS1-v1_5, aus der Signatur zu bestimmen. |
Fehlerfälle |
Das Verhalten des TUCs bei einem Fehlerfall ist in TAB_KON_124 Fehlercodes TUC_KON_161 „nonQES Dokumentensignatur prüfen“ beschrieben. (->1) keine Signatur in signedDocument und signature vorhanden: 4253 (2 „CoreValidation“) Interner Fehler: 4001, Signatur des Dokument ungültig: 4115. Signatur umfasst nicht das gesamte Dokument: 4262. (3 „CheckSignatureCertificate“) Interner Fehler: 4001, Signaturzertifikat ermitteln fehlgeschlagen: 4206. (4 „CheckPolicyConstraints“) Interner Fehler: 4001, Dokument nicht konform zu Regeln für nonQES: 4112. |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
Tabelle 215: TAB_KON_124 Fehlercodes TUC_KON_161 „nonQES Dokumentensignatur prüfen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weiteren Fehlercodes auftreten. |
|||
4001 |
Technical |
Error |
Interner Fehler |
4206 |
Technical |
Error |
Signaturzertifikat ermitteln ist fehlgeschlagen |
4112 |
Technical |
Error |
Dokument nicht konform zu Regeln für nonQES |
4115 |
Security |
Error |
Signatur des Dokuments ungültig. Der SignatureValue des Dokuments ist falsch oder für mindestens eine Reference ist der DigestValue falsch. |
4253 |
Technical |
Error |
Keine Signatur im Aufruf |
4262 | Technical | Error | Signatur umfasst nicht das gesamte Dokument |
4264 | Technical | Warning | Ein oder mehrere Zertifikate ignoriert |
Tabelle 216: TAB_KON_754 Übersicht Status für Prüfung einer Dokumentensignatur
VerificationResult für gesamtes Dokument (VerificationResult/HighLevelResult) |
|
---|---|
Wert |
Bedeutung |
VALID |
Wenn VerificationResult für alle Signaturen zum Dokument VALID |
INVALID |
Wenn VerificationResult für eine Signatur zum Dokument INVALID |
INCONCLUSIVE |
in allen anderen Fällen |
VerificationResult pro Signatur (VerificationReport/IndividualReport/Result) |
|
Wert |
Bedeutung mögliche Ausprägungen im VerificationReport |
VALID |
Die Signatur wurde gemäß den Regeln für die nonQES geprüft und für gültig befunden. |
ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:Success ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:OnAllDocuments |
|
ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:Success ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:HasManifestResults |
|
INVALID |
Die Signatur ist ungültig oder aufgrund eines Fehlers konnte die Signaturprüfung nicht durchgeführt werden. |
ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:Success ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:invalid:IncorrectSignature |
|
ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:Success ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:InvalidSignatureTimestamp |
|
ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:RequesterError |
|
ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:ResponderError |
|
ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:InsufficientInformation ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:invalid:IncorrectSignature |
|
ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:InsufficientInformation ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:CertificateChainNotComplete |
|
INCONCLUSIVE |
Die Signatur wurde gemäß den Regeln für die nonQES geprüft. Allerdings konnten eine oder mehrere Prüfungen nicht vollständig durchgeführt werden. Einzelheiten finden sich in Result-Detail. Die Prüfungen, die durchgeführt werden konnten, waren erfolgreich. |
ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:InsufficientInformation ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:OcspNotAvailiable Hinweis: Das Erreichen dieses Zustandes hängt davon ab, ob eine OCSP-Abfrage nicht durchgeführt werden konnte, unabhängig davon, ob die Ursache dafür die Offlineschaltung des Konnektors (MGM_LU_ONLINE = Disabled) oder die Nichterreichbarkeit des OCSP-Responders im Online-Betrieb (MGM_LU_ONLINE = Enabled) ist. |
Tabelle 217: TAB_KON_786 Übersicht unterstützte Zertifikatstyp-OIDs
policyList | intendedKeyUsage | intendedExtendedKeyUsage | |
---|---|---|---|
X.509-Zertifikat einer eGK | oid_egk_aut | intendedKeyUsage(C.CH.AUT) | id-kp-clientAuth |
X.509-Zertifikat einer eGK | oid_egk_autn | intendedKeyUsage(C.CH.AUTN) | id-kp-clientAuth |
X.509-Zertifikat der SM-B | oid_smc_b_osig | intendedKeyUsage(C.HCI.OSIG) | - |
X.509-Zertifikat eines fachanwendungsspezifischen Dienstes | oid_fd_sig | intendedKeyUsage(C.FD.SIG) | - |
X.509-Zertifikat eines fachanwendungsspezifischen Dienstes (nonRepudiation) | oid_fd_osig | intendedKeyUsage(C.FD.OSIG) | - |
X.509-Zertifikat eines zentralen Dienstes (nonRepudiation) | oid_zd_sig | intendedKeyUsage(C.ZD.SIG) | - |
TIP1-A_5545 - nonQES-Signaturprüfergebnis bezogen auf Signaturzeitpunkt
Der Konnektor MUSS zur nonQES-Signaturprüfung ein Prüfergebnis das sich auf genau einen angenommenen Signaturzeitpunkt bezieht, an den Aufrufer zurückgeben.
Die Auswahl des angenommenen Signaturzeitpunkts, auf den sich das Signaturergebnis bezieht, erfolgt hierarchisch:
- Benutzerdefinierter_Zeitpunkt
falls vorhanden, sonst
- Ermittelter_Signaturzeitpunkt_Eingebettet
falls vorhanden, sonst
- Ermittelter_Signaturzeitpunkt_System
4.1.8.4.3 TUC_KON_162 „Kryptographische Prüfung der XML-Dokumentensignatur”
TIP1-A_5505 - TUC_KON_162 „Kryptographische Prüfung der XML-Dokumentensignatur”
Der Konnektor MUSS den technischen Use Case TUC_KON_162 „Kryptographische Prüfung der XML-Dokumentensignatur” umsetzen.
Tabelle 218: TAB_KON_430 – TUC_KON_162 „Kryptographische Prüfung der XML-Dokumentensignatur“
Element |
Beschreibung |
Name |
TUC_KON_162 „Kryptographische Prüfung der XML-Dokumentensignatur” |
Beschreibung |
Es wird die mathematische Korrektheit der elektronischen Signatur eines XML-Dokuments geprüft. Sind mehrere Signaturen vorhanden, so werden alle geprüft. |
Auslöser |
Aufruf durch ein Fachmodul |
Vorbedingungen |
|
Eingangsdaten |
|
Komponenten |
Konnektor |
Ausgangsdaten |
|
Standardablauf |
„CoreValidation“: Es erfolgt die mathematische Prüfung der Signatur, bestehend aus der Prüfung der Hash-Kette bis zum signierten Hashwert und der Prüfung der kryptographischen Signatur unter Verwendung des öffentlichen Schlüssels aus dem Zertifikat, des Signaturwertes und des signierten Hashwertes. XML-Signatur: Die Core Validation erfolgt entsprechend [XMLDSig] Kapitel 3.2 Core Validation. a) CoreValidation erfolgreich -> result = true b) CoreValidation fehlerhaft -> result = false |
Varianten/Alternativen |
keine |
Fehlerfälle |
Fehler in den folgenden Schritten des Standardablaufs führen zu den ausgewiesenen Fehlercodes: Interner Fehler: 4001 |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
Tabelle 219: TAB_KON_431 Fehlercodes TUC_KON_162 „Kryptographische Prüfung der XML-Dokumentensignatur“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
|
---|---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weiteren Fehlercodes auftreten. |
||||
4001 |
Technical |
Error |
Interner Fehler |
[<=]
4.1.8.4.4 TUC_KON_150 „Dokumente QES signieren”
TIP1-A_4655-03 - TUC_KON_150 „Dokument QES signieren"
Der Konnektor MUSS den technischen Use Case TUC_KON_150 „Dokumente QES signieren” umsetzen.
Tabelle 220: TAB_KON_755 – TUC_KON_150 „Dokumente QES signieren“
Element |
Beschreibung |
---|---|
Name |
TUC_KON_150 ”Dokumente QES signieren” |
Beschreibung |
Im Rahmen von Fachanwendungen werden ein oder mehrere Dokumente mit einer qualifizierten elektronischen Signatur versehen. Es werden die QES_DocFormate unterstützt. |
Auslöser |
Aufruf durch ein Clientsystem (Operation SignDocument) oder ein Fachmodul. |
Vorbedingungen |
Die Signaturkarte muss gesteckt sein. |
Eingangsdaten |
|
Komponenten |
Konnektor, Kartenterminal, Signaturkarte (HBAx) |
Ausgangsdaten |
|
Standardablauf |
Der Konnektor KANN die Schritte 1 bis 4 in einer beliebigen Reihenfolge durchführen.
|
Varianten/ Alternativen |
Der Nutzer kann den Vorgang bei der Autorisierung (Schritt 6) abbrechen. Hierbei sind die gleichen Regeln anzuwenden wie im Fehlerfall (s. Fehlerfälle). |
Fehlerfälle |
Fehler in den folgenden Schritten des Standardablaufs führen zum Abbruch mit den ausgewiesenen Fehlercodes: (->1) Ungültige Angabe des Signaturtyps oder Signaturvariante: Fehlercode 4111 Übergabe eines für die QES nicht unterstützten Dokumentformats: Fehlercode 4110 (->2) Kartentyp nicht zulässig für Signatur: Fehlercode 4126 (->5) Fehler bei der Reservierung von Ressourcen: Fehlercode 4060 (->7b) Karte ist kein HBA, sondern HBA-Vorläuferkarte: Fehlercode 4118 (->10) Liefert der Aufruf von TUC_KON_159 den Fehler 4123, werden die erstellten Signaturen verworfen. Im Fehlerfall, inklusive Timeout bei der PIN-Eingabe, oder bei Abbruch durch den Benutzer (Fehler 4049): a) … MUSS DF.QES verlassen werden b) … MÜSSEN alle reservierten Ressourcen freigegeben werden c) … MUSS der Fehler immer an das Clientsystem zurückgemeldet werden |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
Abbildung PIC_KON_114 Aktivitätsdiagramm zu „Dokument QES signieren“ |
Abbildung 19: PIC_KON_114 Aktivitätsdiagramm zu „Dokument QES signieren“
Tabelle 221: TAB_KON_128 Fehlercodes TUC_KON_150 „Dokument QES signieren“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4060 |
Technical |
Error |
Ressource belegt |
4110 |
Technical |
Error |
ungültiges Dokumentformat (%Format%) Der Parameter Format enthält das übergebene Dokumentformat. |
4111 |
Technical |
Error |
ungültiger Signaturtyp oder Signaturvariante |
4118 |
Technical |
Error |
Stapelsignaturen werden nur für den HBA unterstützt. Mit HBA-Vorläuferkarten sind nur Einzelsignaturen möglich. |
4126 |
Security |
Error |
Kartentyp nicht zulässig für Signatur |
4049 |
Technical |
Error |
Abbruch durch den Benutzer |
4.1.8.4.5 Anforderungen an die Stapelsignatur
Eine Stapelsignatur definiert sich als „Erstellung einer begrenzten Anzahl Signaturen nach den zeitlich unmittelbar aufeinander folgenden Prozessen der Anzeige der zu signierenden Daten und der einmaligen Authentisierung des Signaturschlüssel-Inhabers gegenüber der qualifizierten elektronischen Signaturerstellungseinheit“ (siehe [BSI-TR03114]).
TIP1-A_4669 - QES-Stapelsignatur
Der Signaturdienst MUSS die Möglichkeit bieten, Dokumente eines Stapels einzeln qualifiziert elektronisch zu signieren. Der Signaturdienst MUSS als qualifizierte elektronische Signaturerstellungseinheit für die Stapelsignatur den HBA unterstützen.
[<=]TIP1-A_5664 - Reihenfolge der Dokumente bei Stapelsignatur
Die zu signierenden Dokumente einer Stapelsignatur MÜSSEN vom Signaturdienst im Konnektor in derselben Reihenfolge signiert, in der sie im Signaturauftrag vom Clientsystem geschickt werden.
[<=]TIP1-A_4670 - Secure Messaging für die DTBS
Bei der Stapelsignatur MUSS der Signaturdienst die zu signierenden Daten (DTBS) über Secure Messaging vom Konnektor zum HBA übertragen. Dieser Secure Messaging-Kanal MUSS über die gSMC-K zum HBA mittels C.SAK.AUTD_CVC aufgebaut werden.
[<=]TIP1-A_4671 - Verhalten des Konnektors beim Abbruch einer Stapelsignatur
Der Signaturdienst MUSS dem Benutzer während und nach einer PIN-Eingabe die Möglichkeit zum Abbruch einer Stapelsignatur anbieten.
Das geforderte Verhalten des Konnektors beim Abbruch einer Stapelsignatur wird in der folgenden Tabelle beschrieben. Hierbei werden die beiden Punkte „Abbruch, während die erneute PIN-Eingabe angefordert wird“ (Nummer 1 bis 4) und „Abbruch, während der Vorgang der Signaturerstellung läuft“ (Nummer 5 bis 6) unterschieden. Zeile Nummer 7 beschreibt alle sonstigen Fehlerfälle.
Ein Teilstapel einer Stapelsignatur ist durch die maximale Anzahl der Dokumente definiert, welche nach der Eingabe der Signatur-PIN durch den Signaturschlüssel-Inhaber signiert werden kann.
Tabelle 222: TAB_KON_192 Verhalten des Konnektors beim Abbruch einer Stapelsignatur
Nummer |
Problem/Fehler/Ereignis |
Verhalten des Konnektors |
|
---|---|---|---|
Während die erneute PIN-Eingabe angefordert wird |
1 |
Timeout bei der PIN-Eingabe am KT |
Der Signaturvorgang (Stapel) wird beendet: Kein „Fehler“ Die Signaturen des/der vorherigen Teilstapel(s) bleiben erhalten und werden an das Clientsystem zurückgegeben. Keine weiteren Signaturen des neuen Teilstapels werden erstellt. (Die Weiterverarbeitung bereits erstellter Signaturen des letzten Teilstapels (sofern vorhanden) wird noch abgeschlossen). |
2 |
PIN gesperrt (nach mehrfacher Fehleingabe) |
Siehe Verhalten unter Nummer 1 |
|
3 |
Abbruchkommando „StopSignature“ zur Jobnummer wird empfangen |
Der Signaturvorgang (Stapel) wird beendet. Kein „Fehler“ Keine weiteren Signaturen des neuen Teilstapels werden erstellt. (Die Weiterverarbeitung bereits erstellter Signaturen des letzten Teilstapels (sofern vorhanden) wird noch abgeschlossen). |
|
4 |
Abbruchtaste am Kartenterminal wird gedrückt |
Siehe Verhalten unter Nummer 1 |
|
während der Vorgang der Signaturerstellung läuft |
5 |
Abbruchkommando „StopSignature“ zur Jobnummer wird empfangen |
Signaturvorgang (Stapel) wird abgebrochen. Kein „Fehler“ Keine weiteren Signaturen des Stapels werden erstellt. Keine weiteren Signaturen des Teilstapels werden erstellt. Bisher erstellte Signaturen des aktuellen Teilstapels werden verworfen. |
6 |
Abbruchtaste am Kartenterminal wird gedrückt. |
Die „Abbruch“-Taste wird nicht vom Signaturdienst fortlaufend überwacht Keine Aktion seitens des Signaturdienstes. |
|
7 |
Bei allen anderen Fehlerfällen (z. B.: es kommen zu viele Signaturen zurück, der Hash-Wert einer der Signaturen stimmt nicht, Karte gezogen, etc) |
Signaturvorgang (Stapel) wird abgebrochen. Schwerer Fehler. Keine weiteren Signaturen des Stapels werden erstellt. Keine weiteren Signaturen des aktuellen Teilstapels werden erstellt. Bisher erstellte Signaturen aller Teilstapel werden verworfen. Es handelt sich um Probleme/Fehlerfälle, die bei typischen Angriffen auftreten können. |
[<=]
4.1.8.4.6 TUC_KON_151 „QES Dokumentensignatur prüfen“
TIP1-A_4672-05 - TUC_KON_151 „QES-Dokumentensignatur prüfen“
Der Konnektor MUSS den technischen Use Case TUC_KON_151 „QES-Dokumentensignatur prüfen” umsetzen.
Tabelle 223: TAB_KON_591 - TUC_KON_151 „QES-Dokumentensignatur prüfen“
Element |
Beschreibung |
Name |
TUC_KON_151 „QES-Dokumentensignatur prüfen” |
Beschreibung |
Es wird die QES eines Dokuments geprüft. Dabei werden die Signaturverfahren laut Tabelle TAB_KON_582 – Signaturverfahren unterstützt. Sind mehrere Signaturen vorhanden, so werden alle geprüft. Auch Parallel- und Gegensignaturen MÜSSEN unterstützt werden. |
Eingangsanforderung |
keine |
Auslöser |
Aufruf durch ein Clientsystem (Operation VerifyDocument) oder durch ein Fachmodul im Konnektor |
Vorbedingungen |
keine |
Eingangsdaten |
|
Komponenten |
Konnektor |
Ausgangsdaten |
|
Standardablauf |
1. „DocumentValidation“: Das signierte Dokument wird validiert mit Aufruf TUC_KON_080 „Dokument validieren“{ … }.
Treten Fehler bei der Validierung der Typkonformität auf, wenn die Signatur im Dokument eingebettet ist, wird die Prüfung mit einem Fehler abgebrochen.
Treten bei der Typkonformität, wenn die Signatur nicht im Dokument eingebettet ist, Fehler auf, so bricht der TUC nicht ab, sondern führt die folgenden Schritte soweit sinnvoll möglich durch. (Die Entscheidung über das sinnvoll Durchführbare liegt beim Hersteller des Konnektors.)
2. „CoreValidation“:
Es erfolgt die mathematische Prüfung der Signatur, bestehend aus der Prüfung der Hash-Kette bis zum signierten Hashwert und der Prüfung der Signatur unter Verwendung des öffentlichen Schlüssels, des Signaturwertes und des signierten Hashwertes.
XML-Signatur: Die Core Validation erfolgt entsprechend [XMLDSig] Kapitel 3.2 Core Validation. CMS-Signatur: Die Core Validation erfolgt entsprechend Cryptographic Message Syntax (CMS) Kapitel 5.6 Signature Verification Process [RFC5652]. PDF-Signatur: Die Core Validation erfolgt entsprechend [PAdES-3] Kapitel 4.6 Signature Validation aus PAdES-BES Part 3. Auch wenn die Validierung fehlschlägt, werden die folgenden Prüfschritte durchgeführt, so dass ein vollständiges Prüfprotokoll erstellt werden kann.
3. „CheckSignatureCertificate“: Teil 1: Signaturzertifikat ermitteln XML-Signatur: Das Signaturzertifikat ist im XMLDSig Element ds:KeyInfo/ds:X509Data gespeichert [XMLDSig] oder wird als Eingangsparameter übergeben. CMS-Signatur: Das Signaturzertifikat für CAdES ist im Feld certificates im SignedData Container gespeichert [CAdES] oder wird als Eingangsparameter übergeben. PDF-Signatur: Das PDF Signaturzertifikat für PAdES ist im Feld SignedData.certificates entsprechend Kapitel 6.1.1 „Placements of the signing certificate“ [PAdES Baseline Profile] gespeichert oder wird als Eingangsparameter übergeben. Teil 2: Signaturzeitpunkt bestimmen Der Signaturzeitpunkt Ermittelter_Signaturzeitpunkt_Eingebettet wird wie folgt selektiert: XML-Signatur: Das XML element SigningTime spezifiziert den Signaturzeitpunkt entsprechend Kapitel 7.2.1 XAdES [XAdES]. CMS-Signatur: Das Attribut SigningTime spezifiziert den Signaturzeitpunkt entsprechend Kapitel 11.3 CMS [CMS]. PDF-Signatur: Der Signaturzeitpunkt kann dem M Eintrag des Signature Dictionary entnommen werden [PAdES Baseline Profile] Kapitel 6.2.1 Signing time. Der Signaturzeitpunkt Benutzerdefinierter_Zeitpunkt liegt gegebenenfalls als Aufrufparameter vor. Der Signaturzeitpunkt Ermittelter_Signaturzeitpunkt_System wird ermittelt. Teil 3: Signaturzertifikatsprüfung: Bei der folgenden Signaturzertifikatsprüfung sind die Signaturzeitpunkte gemäß [TIP1-A_5540] zu berücksichtigen. Die Signaturzertifikatsprüfung erfolgt durch Aufruf von TUC_KON_037 „Zertifikat prüfen“ { certificate = C.HP.QES; qualifiedCheck = required; baseTime = Signaturzeitpunkt; offlineAllowNoCheck = true; validationMode = OCSP; ocspResponses = OCSP-Response; getOCSPResponses = includeRevocationInfo }. Sind OCSP-Responses in der Signatur eingebettet, ist die jüngste OCSP-Response des EE-Zertifikats, die für die Zertifikatsprüfung notwendig ist, beim Aufruf von TUC_KON_037 zu übergeben. Sofern der Aufruf von TUC_KON_037 ocspResponses zurückgibt, wird die OCSP-Response des EE-Zertifikats in die Signatur eingebettet. Die Warnung PROVIDED_OCSP_RESPONSE_NOT_VALID wird nicht an den Aufrufer zurückgemeldet. Auch wenn die Zertifikatsprüfung fehlschlägt, werden die folgenden Prüfungen durchgeführt.
4. „CheckPolicyConstraints“:
In diesem Schritt wird das signierte Dokument entsprechend der Profilierung der Signaturformate (siehe Anhang B.2) geprüft. Es sind die Vorgaben für die Prüfung von Signaturen aus den Standards für AdES [XAdES], [XAdES Baseline], [CAdES], [CAdES Baseline], [PAdES-3] und [PAdES Baseline] umzusetzen. Dabei sind die Vorgaben aus Tabelle TAB_KON_779-01
"Profilierung der Signaturformate“ und Tabelle TAB_KON_778 „Einsatzbereich der Signaturvarianten“ zu erfüllen. Auch wenn nicht alle Anforderungen an das Format des signierten Dokuments erfüllt werden, wird die Prüfung mit den folgenden Schritten fortgesetzt, um ein vollständiges Prüfungsprotokoll zu erhalten.
5. Das Prüfergebnis (VerificationResult, OptionalOutput) wird an den Aufrufer zurückgegeben (siehe TAB_KON_593 Übersicht Status für Prüfung einer Dokumentensignatur).
|
Varianten/Alternativen |
Keine |
Fehlerfälle |
Das Verhalten des TUCs bei einem Fehlerfall ist in TAB_KON_592 Fehlercodes TUC_KON_151 „QES Dokumentensignatur prüfen“ beschrieben. (->1) keine Signatur in signedDocument und signatureObject vorhanden: 4253. ( 2 „CoreValidation“) Interner Fehler: 4001, Signatur des Dokuments ungültig: 4115, Signatur umfasst nicht das gesamte Dokument: 4262 (3 „CheckSignatureCertificate“) Interner Fehler: 4001, Signaturzertifikat ermitteln ist fehlgeschlagen: 4206. (4 „CheckPolicyConstraints“) Interner Fehler: 4001, Dokument nicht konform zu Regeln für QES: 4124, Dokument nicht konform zu Profilierung der Signaturformate: 4208. |
Nichtfunktionale Anforderungen |
Keine |
Zugehörige Diagramme |
keine |
Tabelle 224: TAB_KON_592 Fehlercodes TUC_KON_151 „QES Dokumentensignatur prüfen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4001 |
Technical |
Error |
interner Fehler |
4115 |
Security |
Error |
Signatur des Dokuments ungültig. Prüfung der Hashwertkette bzw. Prüfung der kryptographischen Signatur fehlgeschlagen. |
4124 |
Technical |
Error |
Dokument nicht konform zu Regeln für QES |
4206 |
Technical |
Error |
Signaturzertifikat ermitteln ist fehlgeschlagen |
4208 |
Technical |
Error |
Dokument nicht konform zu Profilierung der Signaturformate |
4253 | Technical | Error | Keine Signatur im Aufruf |
4262 | Technical | Error | Signatur umfasst nicht das gesamte Dokument |
4264 | Technical | Warning | Ein oder mehrere Zertifikate ignoriert |
aller Prüfungsschritte in einem einzelnen Statuswert zusammen.
Tabelle 225: TAB_KON_593 Übersicht Status für Prüfung einer Dokumentensignatur
VerificationResult für gesamtes Dokument (VerificationResult/HighLevelResult) |
|||
---|---|---|---|
Wert |
Bedeutung |
||
VALID |
Wenn VerificationResult für alle Signaturen zum Dokument VALID |
||
INVALID |
Wenn VerificationResult für eine Signatur zum Dokument INVALID |
||
INCONCLUSIVE |
in allen anderen Fällen |
||
VerificationResult pro Signatur (VerificationReport/IndividualReport/Result) | |||
Wert | Bedeutung mögliche Ausprägungen im VerificationReport |
||
VALID | Die Signatur wurde gemäß den Regeln für die QES geprüft und für gültig befunden. | ||
ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:Success ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:OnAllDocuments |
|||
ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:Success ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:HasManifestResults |
|||
INVALID | Die Signatur ist ungültig oder aufgrund eines Fehlers konnte die Signaturprüfung nicht durchgeführt werden. | ||
ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:Success ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:invalid:IncorrectSignature |
|||
ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:RequesterError | |||
ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:ResponderError | |||
ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:InsufficientInformation ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:invalid:IncorrectSignature |
|||
ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:InsufficientInformation ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:CertificateChainNotComplete |
|||
INCONCLUSIVE | Die Signatur wurde gemäß den Regeln für die QES geprüft. Allerdings konnten eine oder mehrere Prüfungen nicht vollständig durchgeführt werden. Einzelheiten finden sich in Result-Detail. Die Prüfungen, die durchgeführt werden konnten, waren erfolgreich. |
||
ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:InsufficientInformation ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:OcspNotAvailiable Hinweis: Das Erreichen dieses Zustandes hängt davon ab, ob eine OCSP-Abfrage nicht durchgeführt werden konnte, unabhängig davon, ob die Ursache dafür die Offlineschaltung des Konnektors (MGM_LU_ONLINE = Disabled) oder die Nichterreichbarkeit des OCSP-Responders im Online-Betrieb (MGM_LU_ONLINE = Enabled) ist. |
TIP1-A_5540-01 - QES-Signaturprüfergebnis bezogen auf Signaturzeitpunkt
Der Konnektor MUSS zur QES-Signaturprüfung ein Prüfergebnis, das sich auf genau einen angenommenen Signaturzeitpunkt bezieht, an den Aufrufer zurückgeben.
Die Auswahl des angenommenen Signaturzeitpunkts, auf den sich das Signaturergebnis bezieht, erfolgt hierarchisch:
- Benutzerdefinierter_Zeitpunkt
falls vorhanden, sonst
- Ermittelter_Signaturzeitpunkt_Eingebettet
falls vorhanden, sonst - Ermittelter_Signaturzeitpunkt_System
4.1.8.4.7 TUC_KON_170 „Dokumente mit Komfort signieren”
A_19103-07 - TUC_KON_170 "Dokumente mit Komfort signieren"
Der Konnektor MUSS den technischen Use Case TUC_KON_170 „Dokumente mit Komfort signieren” umsetzen.
Tabelle 226: TAB_KON_871 – TUC_KON_170 „Dokumente mit Komfort signieren“
Element |
Beschreibung |
Name |
TUC_KON_170 ”Dokumente mit Komfort signieren” |
Beschreibung |
Im Rahmen von Fachanwendungen werden ein oder mehrere Dokumente mit einer Komfortsignatur versehen. Es werden die QES_DocFormate unterstützt. |
Auslöser |
Aufruf durch ein Clientsystem (Operation SignDocument) oder ein Fachmodul. |
Vorbedingungen |
Die Signaturkarte muss gesteckt sein. |
Eingangsdaten |
·
signRequests
(Liste von Signaturaufträgen) Jeder Signaturauftrag (SignRequest) kapselt:
•
documentsToBeSigned
(Zu signierendes Dokument bzw. zu signierende Dokumente); darin u.a. documentFormat (Formatangabe für das zu signierende Dokument)
•
optionalInputs
(weitere optionale Eingabeparameter zur Steuerung der Details bei der zu erstellenden Signatur, siehe Operation SignDocument, Parameter dss:OptionalInputs); darin u.a. signatureType (URI für den Signaturtyp XML-, CMS-, PDF-Signatur)
•
includeRevocationInfo [Boolean]: – optional; Default: true
(Dieser optionale Parameter steuert die Einbettung von OCSP Antworten in die Signatur; siehe Operation SignDocument, Parameter SIG:IncludeRevocationInfo)
·
cardSession
(Kartensitzung. Unterstützte Kartentypen: HBA)
·
crypt [SIG_CRYPT_QES] -
optional
;
default und Wertebereich: siehe TAB_KON_862-01 (Dieser Parameter steuert, ob RSA-basierte oder ECC-basierte Signaturen erzeugt werden.)
·
workplaceId
|
Komponenten |
Konnektor, Kartenterminal, Signaturkarte (HBA) |
Ausgangsdaten |
·
signedDocuments
(Liste der signierten Dokumente) |
Standardablauf |
Der Konnektor KANN die Schritte 1 bis 5 in einer beliebigen Reihenfolge durchführen.
1. Prüfe
SAK_COMFORT_SIGNATURE = Enabled
2. Prüfe, ob der Komfortsignatur-Timer der cardSession (SAK_COMFORT_SIGNATURE_TIMER) abgelaufen ist.
3. Der Signaturtyp und die Signaturvariante werden für jedes Dokument der Liste entsprechend signatureType und SignatureVariant festgelegt (ggf. in optionalInputs enthalten). Wenn SignatureType oder SignatureVariant nicht übergeben wurden, wird das dem Dokumentformat entsprechende Default-Verfahren gewählt (siehe TAB_KON_583 – Default-Signaturverfahren).
4. Für alle Dokumente des Stapels wird die Zulässigkeit des Kartentyps geprüft. Das für die Signatur zu nutzende Zertifikat wird anhand des Kartentyps und des Parameters crypt ausgewählt.
5. Es werden die Voraussetzungen für die Signatur geprüft. Dies erfolgt im TUC_KON_152 „Signaturvoraussetzungen für QES prüfen“.
6. Die am Signaturvorgang beteiligte RessourceSignaturkarte wird für die exklusive Nutzung durch diesen Signaturvorgang reserviert. Die Reservierung der Signaturkarte erfolgt durch Aufruf von
TUC_KON_023 „Karte reservieren“ { cardSession; doLock = true }.
7. Zum Vorbereiten der Dokumente für die Signatur wird TUC_KON_155 „Dokumente zur Signatur vorbereiten“ aufgerufen.
Die Zugriffe auf die Signaturkarte im Schritt 8 müssen im DF.QES erfolgen. DF.QES darf am Ende des TUCs nicht verlassen werden.
8. Die Signaturen werden erstellt. Dies erfolgt gemäß TUC_KON_158 „Komfortsignaturen erstellen“.
9. Die reservierte Ressource Signaturkarte wird wieder freigegeben. Zur Freigabe der Signaturkarte wird TUC_KON_023 „Karte reservieren“
cardSession; doLock = false } aufgerufen.
10. Es wird eine Statusprüfung des Signaturzertifikats eingeholt und (je nach includeRevocationInfo) in die Signaturen eingebettet. Dies geschieht durch Aufruf von TUC_KON_159 "Signaturdatenelemente nachbereiten" 11. Die signierten Dokumente werden an den Aufrufer zurückgegeben. |
Varianten/ Alternativen |
keine |
Fehlerfälle |
Fehler in den folgenden Schritten des Standardablaufs führen zum Abbruch mit den ausgewiesenen Fehlercodes. In den Fehlerfällen, die zum Abbruch des Komfortsignaturmodus mit Fehlercode 4271 führen, wird vor dem Abbruch TUC_KON_172 für das cardHandle des HBA ausgeführt. (->1) Komfortsignaturfunktion im Konnektor nicht aktiviert: Fehlercode 4263 (->2) Der Komfortsignatur-Timer der cardSession ist abgelaufen: Fehlercode 4271 (->3) Ungültige Angabe des Signaturtyps oder Signaturvariante: Fehlercode 4111 Übergabe eines für die QES nicht unterstützten Dokumentformats: Fehlercode 4110 (->4) Kartentyp nicht zulässig für Signatur: Fehlercode 4126 (->6) Fehler bei der Reservierung der Signaturkarte: Fehlercode 4060 (->8) Karte ist kein HBA, sondern HBA-Vorläuferkarte: Fehlercode 4274 (->10) Liefert der Aufruf von TUC_KON_159 den Fehler 4123, werden die erstellten Signaturen verworfen. Im Fehlerfall: a) … DARF DF.QES NICHT verlassen werden b) … MÜSSEN alle reservierten Ressourcen freigegeben werden c) … MUSS der Fehler immer an das Clientsystem zurückgemeldet werden |
Sicherheits-anforderungen |
Der Konnektor MUSS sicherstellen, dass der erhöhte Sicherheitszustand der PIN.QES nur für die Komfortsignatur mittels TUC_KON_170 innerhalb einer Kartensitzung nachgenutzt werden darf. |
Tabelle 227: TAB_KON_872 Fehlercodes TUC_KON_170 „Dokumente mit Komfort signieren“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4060 |
Technical |
Error |
Ressource belegt |
4110 |
Technical |
Error |
ungültiges Dokumentformat (%Format%) Der Parameter Format enthält das übergebene Dokumentformat. |
4111 |
Technical |
Error |
ungültiger Signaturtyp oder Signaturvariante |
4126 |
Security |
Error |
Kartentyp nicht zulässig für Signatur |
4049 |
Technical |
Error |
Abbruch durch den Benutzer |
4263 |
Technical |
Error |
Komfortsignaturfunktion nicht aktiviert |
4271 | Technical | Error | Komfortsignaturmodus abgebrochen |
4274 | Technical | Error | Komfortsignaturen werden nur für den HBA unterstützt |
4.1.8.4.8 TUC_KON_171 „Komfortsignatur einschalten”
A_19104-04 - TUC_KON_171 „Komfortsignatur einschalten“
Der Konnektor MUSS den technischen Use Case TUC_KON_171 „Komfortsignatur einschalten“ umsetzen.
Tabelle 228: TAB_KON_883 – TUC_KON_171 „Komfortsignatur einschalten“
Element |
Beschreibung |
Name |
TUC_KON_171 „Komfortsignatur einschalten“ |
Beschreibung |
Zum Einschalten des Komfortsignaturmodus wird die PIN.QES verifiziert und der Signaturmodus „Comfort“ für die cardSession gesetzt. |
Auslöser |
·
Operation ActivateComfortSignature
·
Aufruf durch ein Fachmodul
|
Vorbedingungen |
Der Karte muss gesteckt sein. |
Eingangsdaten |
·
cardSession (nur HBA erlaubt)
|
Komponenten |
Konnektor, Kartenterminal, Karte (HBA) |
Ausgangsdaten |
·
signatureMode
|
Standardablauf |
1. Prüfe
SAK_COMFORT_SIGNATURE = Enabled
2. Die am Vorgang beteiligten Ressourcen (Karte sowie PIN-Pad und Display des PIN-Eingabe-Kartenterminals) werden für die exklusive Nutzung durch diesen Vorgang reserviert. Die Reservierung der Karte erfolgt durch Aufruf von Der Zugriff auf die Karte im Schritt 3 muss im DF.QES erfolgen. Das DF.QES darf danach nicht verlassen werden, damit der PIN-Status der PIN.QES erhalten bleibt.TUC_KON_023 „Karte reservieren“ { cardSession; doLock = true }
3. Die Einschaltung der Komfortsignatur wird durch den Anwender autorisiert. Dies erfolgt durch Aufruf von TUC_KON_012 „PIN verifizieren“ { cardSession;
workplaceId; pinRef = PIN.QES; verificationType = Mandatorisch } Für die Anzeige am Kartenterminal ist die Displaymessage für „Komfortsignatur aktivieren“ aus TAB_KON_090 zu verwenden.
4. Setze
CARDSESSION.SIGNMODE
= Comfort
5. Starte Komfortsignatur-Timer für die cardSession bei „0“
6. Die reservierten Ressourcen (Karte sowie PIN-Pad und Display des PIN-Eingabe-Kartenterminals) werden wieder freigegeben. Zur Freigabe der Karte wird TUC_KON_023 „Karte reservieren“ cardSession; doLock = false } aufgerufen. |
Varianten/ Alternativen |
Keine |
Fehlerfälle |
Fehler in den folgenden Schritten des Standardablaufs führen zum Abbruch mit den ausgewiesenen Fehlercodes: (->1) Komfortsignaturfunktion im Konnektor nicht aktiviert: Fehlercode 4263 (->) Keine Komfortsignatursession für den HBA aktivierbar, da Maximalzahl an parallelen Komfortsignatursessions erschöpft: Fehlercode 4278 (->2) Fehler bei der Reservierung von Ressourcen: Fehlercode 4060 (->3) Karte ist kein HBA, sondern HBA-Vorläuferkarte: Fehlercode 4274 (->3) pinResult = BLOCKED: Fehlercode 4275 (->3) pinResult = REJECTED: Fehlercode 4276 (->4) Fehler beim Setzen des Signaturmodus: Fehlercode 4267 (->5) Fehler beim Starten des Komfortsignatur-Timers: Fehlercode 4267 Im Fehlerfall, inklusive Timeout bei der PIN-Eingabe, oder bei Abbruch durch den Benutzer (Fehler 4049): a) … MUSS (ab Schritt 5) CARDSESSION.SIGNMODE = PIN gesetzt werden b) … MUSS (ab Schritt 3) DF.QES verlassen werden c) … MÜSSEN alle reservierten Ressourcen freigegeben werden d) … MUSS der Fehler immer an das Clientsystem zurückgemeldet werden |
Tabelle 229: TAB_KON_886 Fehlercodes TUC_KON_171 „Komfortsignatur einschalten“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4049 |
Technical |
Error |
Abbruch durch den Benutzer |
4060 |
Technical |
Error |
Ressource belegt |
4263 |
Technical |
Error |
Komfortsignaturfunktion nicht aktiviert |
4267 |
Technical |
Error |
Fehler beim Aktivieren des Komfortsignaturmodus <cardHandle> |
4274 | Technical | Error | Komfortsignaturen werden nur für den HBA unterstützt |
4275 | Technical | Error | Security Error PIN jetzt gesperrt (BLOCKED) |
4276 | Technical | Error | Security Error PIN falsch (REJECTED) |
4278 | Technical | Error | Keine Komfortsignatursession mehr verfügbar |
4.1.8.4.9 TUC_KON_172 „Komfortsignatur ausschalten”
A_19105 - TUC_KON_172 „Komfortsignatur ausschalten“
Der Konnektor MUSS den technischen Use Case TUC_KON_172 „Komfortsignatur ausschalten“ umsetzen.
Tabelle 230: TAB_KON_884 – TUC_KON_172 „Komfortsignatur ausschalten“
Element |
Beschreibung |
Name |
TUC_KON_172 „Komfortsignatur ausschalten“ |
Beschreibung |
Zum Ausschalten des Komfortsignaturmodus werden die Sicherheitszustände der Karte(n), die im Konnektor verwalteten Sicherheitszustände und der Signaturmodus der cardSession(s) zurückgesetzt. |
Auslöser |
·
Operation DeactivateComfortSignature
·
TUC_KON_158
·
Der Administrator setzt SAK_COMFORT_SIGNATURE = Disabled
·
Aufruf durch ein Fachmodul
|
Vorbedingungen |
Die Karten müssen gesteckt sein. |
Eingangsdaten |
Bei Auslösen des TUCs durch den Administrator:
·
Keine
Ansonsten:
·
cardHandles : Liste von cardHandles (nur HBA erlaubt)
|
Komponenten |
Konnektor, Kartenterminal, Karte (HBA) |
Ausgangsdaten |
Keine |
Standardablauf |
1. Wenn der TUC nicht durch den Administrator ausgelöst wurde:
Prüfe SAK_COMFORT_SIGNATURE = Enabled
2. Wenn der TUC durch den Administrator ausgelöst wurde: Ermittle die cardHandles aller gesteckten HBA.
3. Für jedes übergebene bzw. ermittelte cardHandle:
4. Ermittle cardSessions zu cardHandle
5. Für jede ermittelte cardSession:
a. Setze den PIN-Status der PIN.QES zurück (z. B. durch Verlassen von DF.QES für alle logischen Kanäle der Karte)
b. Lösche den im Konnektor verwalteten Sicherheitszustand aus
CARDSESSION.AUTHSTATE (PINRef=PIN.QES)
c. Setze
CARDSESSION.SIGNMODE = PIN
d. Stoppe Komfortsignatur-Timer für die cardSession
|
Varianten/ Alternativen |
Keine |
Fehlerfälle |
(->1) Komfortsignaturfunktion im Konnektor nicht aktiviert: Fehlercode 4263 Fehler und Warnungen in den folgenden Schritten werden über alle cardHandle akkumuliert und die <komma-separierte Liste von cardHandle> für den jeweiligen Fehlertext erzeugt. (->3) Bei einem ungültigen cardHandle wird mit dem nächsten cardHandle aus cardHandles fortgesetzt. Fehlercode 4265 (->4) Ist zu einem cardHandle keine cardSession vorhanden wird mit dem nächsten cardHandle fortgesetzt. Fehlercode 4266 (->5) Tritt in Schritt 4 ein Fehler auf wird mit dem nächsten cardHandle fortgesetzt. Fehlercode 4268 |
Tabelle 231: TAB_KON_887 Fehlercodes TUC_KON_172 „Komfortsignatur ausschalten“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
4263 |
Technical |
Fehler |
Komfortsignaturfunktion nicht aktiviert |
4265 |
Technical |
Warning |
Karten-Handle ungültig <komma-separierte Liste von cardHandle> |
4266 |
Technical |
Warning |
Keine Kartensitzung vorhanden <komma-separierte Liste von cardHandle> |
4268 |
Technical |
Fehler |
Fehler beim Deaktivieren des Komfortsignaturmodus <komma-separierte Liste von cardHandle> |
4.1.8.4.10 TUC_KON_173 „Liefere Signaturmodus”
A_19106-02 - TUC_KON_173 „Liefere Signaturmodus“
Der Konnektor MUSS den technischen Use Case TUC_KON_173 „Liefere Signaturmodus“ umsetzen.
Tabelle 232: TAB_KON_885 – TUC_KON_173 „Liefere Signaturmodus“
Element |
Beschreibung |
Name |
TUC_KON_173 „Liefere Signaturmodus“ |
Beschreibung |
Der aktuell konfigurierte Status der Komfortsignaturfunktion im Konnektor und Informationen zur Komfortsignatursession werden ermittelt und an den Aufrufer zurückgegeben. |
Auslöser |
·
Operation GetSignatureMode
·
Aufruf durch ein Fachmodul
|
Vorbedingungen |
Keine |
Eingangsdaten |
·
cardSession (Kartensitzung. Unterstützte Kartentypen: HBA) |
Komponenten |
Konnektor, Kartenterminal, Signaturkarte (HBA) |
Ausgangsdaten |
·
comfortSignatureStatus
·
comfortSignatureMax
·
comfortSignatureTimer
·
sessionInfo (optional): Struktur aus
signatureMode, countRemaining, timeRemaining
|
Standardablauf |
|
Varianten/ Alternativen |
(->4b) Der Rückgabewert für countRemaining muss für jede Komfortsignatursession den aktuellen Stand zur Anzahl verbleibender Komfortsignaturen wiedergeben unter Einbezug a) ggf. parallel existierender Sessions auf ein und demselben logischen Kanal des HBA, b) der maximal durch die Karte in diesem logischen Kanal erlaubten Komfortsignaturen (laut [gemSpec_HBA_ObjSys*] 250) und c) der konfigurierten maximal erlaubten Anzahl an Komfortsignaturen für die betreffende Session (SAK_COMFORT_SIGNATURE_MAX). |
Fehlerfälle |
Wenn im Standardablauf ein Fehler auftritt, wird mit Fehler 4269 abgebrochen. |
Tabelle 233: TAB_KON_888 Fehlercodes TUC_KON_173 „Liefere Signaturmodus“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
4269 |
Technical |
Error |
Fehler beim Ermitteln des Signaturmodus <cardHandle> |
4.1.8.5 Operationen an der Außenschnittstelle
TIP1-A_4676-09 - Basisdienst Signaturdienst (nonQES und QES)
Der Konnektor MUSS Clientsystemen den Basisdienst Signaturdienst (nonQES und QES) anbieten.
Tabelle 234: TAB_KON_197 Basisdienst Signaturdienst (nonQES und QES)
Name |
SignatureService |
|
---|---|---|
Version (KDV) |
7.4.0 (WSDL-Version), 7.4.2 (XSD-Version) 7.4.2 (WSDL-Version), 7.4.4 (XSD-Version) 7.5.5 (WSDL- und XSD-Version) 7.5.6 (WSDL- und XSD-Version) |
|
Namensraum |
Siehe GitHub |
|
Namensraum-Kürzel |
SIG für Schema und SIGW für WSDL |
|
Operationen |
Name |
Kurzbeschreibung |
SignDocument |
Dokument signieren |
|
VerifyDocument |
Signatur verifizieren |
|
StopSignature |
Signieren eines Dokumentenstapels abbrechen |
|
GetJobNumber |
Liefert eine Jobnummer für den nächsten Signiervorgang |
|
ActivateComfortSignature | Aktiviert die Komfortsignatur für einen HBA | |
DeactivateComfortSignature | Deaktiviert die Komfortsignatur für einen oder mehrere HBA | |
GetSignatureMode | Liefert den Status der Komfortsignaturfunktion und Informationen zur Komfortsignatursession eines HBA | |
WSDL |
SignatureService_V7_5_6.wsdl SignatureService_V7_5_5.wsdl SignatureService_V7_4_2.wsdl SignatureService.wsdl (WSDL-Version 7.4.0) |
|
Schema |
SignatureService_V7_5_6.xsd SignatureService_V7_5_5.xsd SignatureService_V7_4_4.xsd SignatureService.xsd (XSD-Version 7.4.2) |
4.1.8.5.1 SignDocument (nonQES und QES)
TIP1-A_5010-10 - Operation SignDocument (nonQES und QES)
Der Signaturdienst des Konnektors MUSS an der Clientschnittstelle eine an [OASIS-DSS] angelehnte Operation SignDocument anbieten.
Tabelle 235: TAB_KON_065 Operation SignDocument (nonQES und QES)
Name |
SignDocument |
|
---|---|---|
Beschreibung |
Diese Operation lehnt sich an [OASIS-DSS] an. Sie enthält voneinander unabhängige SignRequests. Jeder SignRequest erzeugt eine Signatur für ein Dokument. Für die qualifizierte elektronische Signatur (QES) werden die QES_DocFormate unterstützt. Für nicht-qualifizierte elektronische Signaturen (nonQES) werden die nonQES_DocFormate unterstützt. Zur Signaturerzeugung werden Schlüssel und Zertifikate einer Chipkarte benutzt. Unterstützte Karten sind für die QES der HBAx mit dem QES-Zertifikat. Für die nonQES wird für die Signaturtypen „XML-Signatur, CMS-Signatur, PDF-Signatur, S/MIME-Signatur“ die SM-B mit dem OSIG–Zertifikat unterstützt. Bei der Erstellung von XML-Signaturen MUSS Canonical XML 1.1 verwendet werden [CanonXML1.1]. Es soll der Common-PKI-Standard eingesetzt werden, siehe [Common-PKI]. In Summe für die Größe der Dokumente in allen SignRequests innerhalb einer SignDocument-Anfrage MUSS der Konnektor eine Gesamtgröße von <= 250 MB unterstützen. |
|
Aufruf-parameter |
||
Name |
Beschreibung |
|
CONN: Card Handle |
Identifiziert die zu verwendende Signaturkarte. Die Operation DARF die Signatur mit der eGK NICHT unterstützen. Wird die Operation mit einem nicht unterstützten Kartentypen aufgerufen, so MUSS der Konnektor die Bearbeitung mit dem Fehler 4126 abbrechen. |
|
SIG: Crypt |
Der Parameter crypt steuert die Auswahl der Zertifikate und Schlüssel für die Signaturerstellung abhängig von der durch cardHandle adressierten Karte gemäß TAB_KON_900. Defaultwert:
|
|
CCTX: Context |
Aufrufkontext QES mit HBAx: MandantId, ClientSystemId, WorkplaceId, UserId verpflichtend Aufrufkontext nonQES mit SM-B: MandantId, ClientSystemId, WorkplaceId verpflichtend; UserId nicht ausgewertet |
|
TvMode |
Der Parameter wird im Konnektor nicht ausgewertet. |
|
SIG: JobNumber |
Die Nummer des Jobs, unter der der nächste Signaturvorgang gestartet wird. Parameter ist verpflichtend. |
|
SIG: Sign Request |
Ein SignRequest kapselt den Signaturauftrag für ein Dokument. Das verpflichtende XML-Attribut RequestID identifiziert einen SignRequest innerhalb eines Stapels von SignRequests eindeutig. Es dient der Zuordnung der SignResponse zum jeweiligen SignRequest. Enthält der Aufruf mehr als die unterstützte Anzahl von SignRequests, bricht die Operation mit Fehler 4000 ab. Es sind mindestens 50 SignRequests zu unterstützen. |
|
SIG: Optional Inputs |
Enthält optionale Eingangsparameter (angelehnt an dss:OptionalInputs gemäß [OASIS-DSS] Section 2.7): |
|
SIG: Document |
Dieses an das dss:Document Element aus [OASIS-DSS] Section 2.4.2 angelehnte Element enthält das zu signierende Dokument, wobei die Kindelemente CONN:Base64XML und dss:Base64Data auftreten können. Bei den als dss:Base64Data übergebenen Dokumenten werden folgende (Klassen von) MIME-Types unterschieden:
Das Element enthält ein Attribut ShortText. Es muss für QES-Signaturen bei jedem Aufruf vom Clientsystem übergeben werden, für nonQES-Signaturen ist es optional. Über das Attribut RefURI kann gemäß [OASIS-DSS] (Abschnitt 2.4.1) ein zu signierender Teilbaum eines XML-Dokuments ausgewählt werden. Wenn die Signatur eines Teilbaums für die Signaturvariante nicht unterstützt wird, muss der Signaturauftrag mit Fehler 4111 abgelehnt werden. |
|
SIG: Include Revocation Info |
Durch diesen verpflichtenden Schalter kann der Aufrufer die Einbettung von Sperrinformationen, die unmittelbar nach dem Zeitpunkt der Signaturerstellung eingeholt wurden, anfordern. Es wird ausschließlich die zu erstellende Signatur betrachtet, d.h. es erfolgt keine Einbettung von Sperrinformationen für bereits enthaltene Signaturen. Für PDF-Signaturen werden keine Sperrinformationen eingebettet. |
|
dss: Signature Type |
Durch dieses in [OASIS-DSS] (Abschnitt 3.5.1) beschriebene Element kann der generelle Typ der zu erzeugenden Signaturen spezifiziert werden. Hierbei MÜSSEN folgende Signaturtypen unterstützt werden:
Andere SignatureType-Angaben führen zu einer Fehlermeldung 4111 (Ungültiger Signaturtyp oder Signaturvariante). Die Signaturtypen „XML-Signatur, CMS-Signatur, PDF-Signatur, S/MIME-Signatur“ DÜRFEN für QES der HBAx nur mit dem QES-Zertifikat erfolgen, für nonQES nur mit dem OSIG-Zertifikat der SM-B. In jedem diese Anforderung verletzenden Fall MUSS der Fehler 4058 (Aufruf nicht zulässig) zurückgeliefert werden. Fehlt dieses Element, so wird der Signaturtyp gemäß TAB_KON_583 – Default-Signaturverfahren aus dem Dokumententyp abgeleitet. |
|
dss: Properties |
Durch dieses in [OASIS-DSS] (Abschnitt 3.5.5) definierte Element können zusätzliche signierte und unsignierte Eigenschaften (Properties) bzw. Attribute in die Signatur eingefügt werden. Unterstützt werden genau folgende Attribute: Im CMS-Fall (SignatureType = urn:ietf:rfc:5652) kann es XML-Elemente ./SignedProperties/Property/Value/CMSAttribute und ./UnsignedProperties/Property/Value /CMSAttribute enthalten. Ein solches XML-Element CMSAttribute muss ein vollständiges, base64/DER-kodiertes ASN.1-Attribute enthalten, definiert in [CMS#5.3.SignerInfo Type]. Es muss bei der Erstellung des CMS-Containers unverändert unter SignedAttributes bzw. UnsignedAttributes aufgenommen werden. Die Übergabe der Attribute
|
|
SIG: Include EContent |
Durch dieses in [OASIS-DSS] (Abschnitt 3.5.7), definierte Element kann bei einer CMS-basierten Signatur das Einfügen des signierten Dokumentes in die Signatur angefordert werden. Die Verwendung dieses Parameters bei anderen Signaturtypen führt zu einem Fehler 4111 (Ungültiger Signaturtyp oder Signaturvariante). |
|
SIG: Include Object |
Dieses Element enthält zum Anfordern einer Enveloping XML Signatur ein dss:IncludeObject-Element gemäß [OASIS-DSS] (Abschnitt 3.5.6). Ist das Element vorhanden und ein anderer Signaturtyp als eine XML-Signatur angefordert, so wird der Fehler 4111 (Ungültiger Signaturtyp oder Signaturvariante) zurückgeliefert. |
|
dss: Signature Placement |
Durch dieses in [OASIS-DSS] (Abschnitt 3.5.8) definierte Element kann bei XML-basierten Signaturen gemäß [RFC3275] die Platzierung der Signatur im Dokument angegeben werden. Die in [OASIS-DSS] (Abschnitt 2.5, XPath c) beschriebene Deklaration von Namespace-Prefixes im dss:SignaturePlacement-Element muss nicht unterstützt werden. Bei anderen Signaturtypen wird das Element ignoriert und eine Warnung (Fehlercode 4197, Parameter SignaturePlacement wurde ignoriert) zurückgeliefert. dss:SignaturePlacement darf nur zusammen mit einer unterstützten Signaturrichtlinie verwendet werden (sp:SignaturePolicyIdentifier muss entsprechend gesetzt sein). |
|
dss: Return Updated Signature |
Durch dieses in [OASIS-DSS] (Abschnitt 4.5.8) definierte Element kann eine übergegebene XML- oder CMS-Signatur mit zusätzlichen Informationen und Signaturen (Parallel- und Gegensignaturen) versehen werden. Hierbei sind folgende Ausprägungen für das Type-Attribut vorgesehen:
|
|
dss: Schemas |
Durch das in [OASIS-DSS] (Abschnitt 2.8.5) definierte Element können eine Menge von XML-Schemata übergeben werden, die zur Validierung der übergebenen XML-Dokumente verwendet werden können. |
|
dss:Schema |
Dieses Element enthält ein XML-Schema zur Validierung des übergebenen XML-Dokuments. Das Attribut RefURI ist verpflichtend. Es kennzeichnet dabei den Namensraum des XML-Schemas entsprechend [OASIS-DSS] (Abschnitt 2.8.5). |
|
sp: Generate Under Signature Policy |
Über dieses in [OASIS-SP], Kapitel 2.2.1.1.1.1 Optional Input <GenerateUnderSignaturePolicy>, definierte Element wird die erforderliche Singnaturrichlinie ausgewählt. Die im Element sp:SignaturePolicyIdentifier übergebene URI identifiziert die Signaturrichtlinie. Die XML-Elemente SignaturePolicyLocation DigestAndAlgorithm werden nicht verwendet. Wenn eine nach TAB_KON_778 notwendige Signaturrichtlinie fehlt oder die übergebene Signaturrichtlinie unbekannt ist, wird Fehler 4111 zurückgeliefert. |
|
SIG: Viewer Info |
Enthält optional die vom Konnektor in die Signatur einzubeziehende Referenzen für die Stylesheets zur Anzeige. |
|
Rückgabe |
||
SIG:SignResponse |
Eine SignResponse kapselt den ausgeführten Signaturauftrag pro Dokument. Die Zuordnung zwischen SignRequest und SignResponse erfolgt über die RequestID. |
|
CONN:Status | Enthält den Status der ausgeführten Operation pro SignRequest. | |
SIG: Optional Outputs |
Enthält (angelehnt an dss:OptionalOutputs) optionale Ausgangsparameter: |
|
SIG: Document With Signature |
Pro SignResponse wird ein Element SIG:DocumentWithSignature gemäß [OASIS-DSS] (Abschnitt 3.5.8) zurückgeliefert, in dem das Dokument mit Signatur enthalten ist. Dabei werden die XML-Attribute des Elements SIG:Document auf dem zugehörigen SignRequest übernommen. Ist die Signatur nicht im Dokument enthalten, wird ein leeres Element Base64XML oder Base64Data zurückgegeben. Die Signatur wird dann im Element dss:SignatureObject abgelegt. Wenn die Signatur im Dokument enthalten ist, wird das signierte Dokument im Feld Base64XML bzw. Base64Data zurückgeliefert. In diesem Fall MUSS die dss:SignaturePtr-Alternative in dss:SignatureObject (vgl. [OASIS-DSS] Abschnitt 2.5) dazu genutzt werden, auf die in den Dokumenten enthaltenen Signaturen zu verweisen. |
|
vr: VerificationReport |
Vom Konnektor nicht befüllt. | |
dss: SignatureObject |
Enthält im Erfolgsfall die erzeugte Signatur pro SignRequest in Form eines dss:SignatureObject-Elementes gemäß [OASIS-DSS] (Abschnitt 3.2). | |
Vorbe-dingungen | Keine | |
Nachbe-dingungen | Keine |
Tabelle 236: TAB_KON_756 Ablauf Operation SignDocument (nonQES und QES)
Nr.
|
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1. |
checkArguments |
Anhand des Kartentyps wird ermittelt, ob eine QES oder eine nonQES erzeugt werden soll. Alle übergebenen Parameterwerte 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; userId = $context.userId; cardHandle = $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; cardHandle = $context.cardHandle; userId = $context.userId } |
Im Fall QES wird Schritt 4 ausgeführt. Im Fall nonQES wird Schritt 5 ausgeführt. |
||
4a) |
Prüfe Signaturdienst-Modul |
Prüfe, ob MGM_LU_SAK=Enabled. Ist dies nicht der Fall, so bricht die Operation mit Fehler 4125 ab. |
Wenn für die CardSession die Komfortsignatur aktiviert ist (CARDSESSION.SIGNMODE = Comfort) wird Schritt 4 c) ausgeführt. Andernfalls wird Schritt 4 b) ausgeführt. | ||
4b) |
TUC_KON_150 „Dokumente QES signieren“ |
Die QES wird erzeugt. Tritt hierbei ein Fehler auf, bricht die Operation ab. |
4c) | TUC_KON_170 „Dokumente mit Komfort signieren“ | Eine Komfortsignatur wird erzeugt. Tritt hierbei ein Fehler auf, bricht die Operation ab. |
5) |
TUC_KON_160 „Dokumente nonQES signieren“ |
Die nonQES wird erzeugt. Tritt hierbei ein Fehler auf, bricht die Operation ab. |
Tabelle 237: TAB_KON_757 Fehlercodes „SignDocument (nonQES und QES)“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen TUCs können folgende weiteren Fehlercodes auftreten: |
|||
4000 |
Technical |
Error |
Syntaxfehler |
4111 | Technical | Error | ungültiger Signaturtyp oder Signaturvariante |
4126 |
Security |
Error |
Kartentyp nicht zulässig für Signatur |
4125 |
Technical |
Error |
LU_SAK nicht aktiviert |
4197 |
Technical |
Warning |
Parameter SignaturePlacement wurde ignoriert |
4252 | Technical | Error |
Jobnummer wurde in den letzten 1.000 Aufrufen bereits verwendet und ist nicht zulässig |
4273 | Technical | Warning | Attribute im Parameter dss:Properties wurden ignoriert |
4279 | Technical | Error | S/MIME-Funktionalität nicht unterstützt |
4283 | Technical | Error | Dokument zu groß |
Die zulässigen Zertifikate und Schlüssel sind in TAB_KON_900 aufgelistet.
[<=]
4.1.8.5.2 VerifyDocument (nonQES und QES)
TIP1-A_5034-06 - Operation VerifyDocument (nonQES und QES)
Der Signaturdienst des Konnektors MUSS an der Clientschnittstelle eine an [OASIS-DSS] angelehnte Operation VerifyDocument (nonQES und QES) anbieten.
Tabelle 238: TAB_KON_066 Operation VerifyDocument (nonQES und QES)
Name |
VerifyDocument |
||
---|---|---|---|
Beschreibung |
Diese Operation verifiziert die Signatur eines Dokumentes. Der Konnektor MUSS jede konform zur Außenschnittstelle SignDocument erzeugte Signatur durch VerifyDocument prüfen können. Das Ergebnis der Prüfung wird, wenn gefordert, in Form eines standardisierten Prüfberichts in einer VerificationReport-Struktur gemäß [OASIS-VR] zurückgeliefert. |
||
Aufruf-parameter |
|||
Name |
Beschreibung |
||
CCTX: Context |
MandantId, ClientSystemId, WorkplaceId verpflichtend; UserId nicht ausgewertet |
||
TvMode |
Der Parameter wird im Konnektor nicht ausgewertet. |
||
SIG: Optional Inputs |
Enthält optionale Eingabeparameter (angelehnt an dss:OptionalInputs gemäß [OASIS-DSS] Section 2.7): Die zulässigen optionalen Eingabeparameter sind unten erläutert. |
||
SIG: Document |
Enthält im Fall der Prüfung von detached oder enveloped Signaturen das zur Signatur gehörende bzw. das diese umschließende Dokument (siehe [OASIS-DSS] Section 2.4.2 und oben). |
||
dss: Signa ture Object |
Enthält die zu prüfende Signatur, wenn sie nicht im Dokument selbst eingebettet ist ([OASIS-DSS] Kapitel 4.1). Hierbei werden XML-Signaturen als ds:Signature Element und alle anderen Signaturen als dss:Base64Signature mit entsprechend gesetztem Type-Attribut (siehe SignatureType, Operation SignDocument) übergeben, wobei die nachfolgenden Werte unterstützt werden MÜSSEN:
|
||
SIG: Include Revocat ionInfo |
Durch diesen verpflichtenden Schalter kann der Aufrufer die Einbettung von zum Zeitpunkt der Signaturprüfung vorliegenden Sperrinformationen anfordern. Ist bereits eine Sperrinformation eingebettet, so wird die neue Sperrinformation zusätzlich eingebettet. Für in einer Gegensignatur enthaltene Signaturen erfolgt keine Einbettung von Sperrinformationen. Für PDF-Signaturen erfolgt keine Einbettung von Sperrinformationen. Der Konnektor nimmt die Warnung 4261 in die Antwort auf. |
||
SIG: Verify Mani fests |
Durch das in [OASIS-DSS] (Abschnitt 4.5.1) definierte Element kann die Prüfung eines ggf. vorhandenen Manifests angefordert werden. |
||
SIG: Use Verifi cation Time |
Durch das in [OASIS-DSS] (Abschnitt 4.5.2) spezifizierte Element kann die Prüfung der Signatur bezüglich eines durch den Aufrufer bestimmten Zeitpunktes (Benutzerdefinierter_Zeitpunkt) erfolgen. |
||
dss: Addit ional KeyInfo |
Durch das in [OASIS-DSS] (Abschnitt 4.5.4) spezifizierte Element kann zusätzliches, für die Prüfung benötigtes, Schlüsselmaterial übergeben werden. |
||
vr: Return Verifi cation Report |
Durch dieses in [OASIS-VR] spezifizierte Element kann die Erstellung eines ausführlichen Prüfberichtes angefordert werden. Der Konnektor MUSS die Anforderungen der Konformitätsstufe 2 („Comprehensive“) erfüllen und die Profilierung aus Anhang B3 beachten. |
||
dss: Schemas |
Durch das in [OASIS-DSS] (Abschnitt 2.8.5) definierte Element können eine Menge von XML-Schematas übergeben werden, die zur Validierung des übergebenen XML-Dokumentes verwendet werden können. Zur Struktur dieses Elements siehe Beschreibung des Parameters dss:Schemas der Operation SignDocument. |
||
SIG: Viewer Info |
Der Parameter wird im Konnektor nicht ausgewertet. |
||
Rückgabe |
|||
Status |
Enthält den Ausführungsstatus der Operation. |
||
SIG: Verifi cation Result |
Das Element Sig:VerificationResult enthält das Ergebnis der Prüfung als Ampel, den Typ des zugehörigen angenommenen Signaturzeitpunkts und der angenommene Signaturzeitpunkt selbst. |
||
SIG: High Level Result |
Das Ergebnis der Prüfung (Ampelschaltung) mit folgenden Werten:
|
||
SIG: Time stamp Type |
Der Typ des angenommenen Signaturzeitpunkts mit folgenden Werten:
|
||
SIG: Time stamp |
Im Element SIG:Timestamp wird der zu SIG:TimestampType gehörende Zeitstempel zurückgegeben. |
||
SIG: Optio nal Outputs |
Enthält (angelehnt an dss:OptionalOutputs, wie in Abschnitt 2.7 von [OASIS-DSS] beschrieben) optionale Ausgangselemente: |
||
dss: Verify Manifest Results |
Dieses in Abschnitt 4.5.1 von [OASIS-DSS] definierte Element enthält Informationen zur Prüfung eines ggf. vorhandenen Signaturmanifests und wird zurückgeliefert, sofern beim Aufruf das dss:VerifyManifest-Element, aber nicht das RequestVerificationReport als optionales Eingabeelement übergeben wurde. |
||
SIG: Document With Signa ture |
Dieses in Abschnitt 4.5.8 von [OASIS-DSS] spezifizierte Element wird zurückgeliefert, falls eine in dem Dokument enthaltene Signatur (Enveloped Signature) in Verbindung mit dem SIG:IncludeRevocationInfo-Element geprüft wurde. |
||
dss: Updated Signa ture |
Dieses in Abschnitt 4.5.8 von [OASIS-DSS] spezifizierte Element wird zurückgeliefert, falls eine abgesetzte (Detached Signature) oder umschließende (Enveloping Signature) in Verbindung mit dem SIG:IncludeRevocationInfo- Element geprüft wurde. |
||
vr: Verifi cation Report |
Dieses in [OASIS-VR] spezifizierte Element wird zurückgeliefert, falls das ReturnVerificationReport-Element als Eingabeparameter verwendet wurde. Die Profilierung von Anhang B3 MUSS beachtet werden. |
||
Vorbe-dingungen |
Keine |
||
Nachbe-dingungen |
Keine |
Tabelle 239: TAB_KON_760 Ablauf Operation VerifyDocument (nonQES und QES)
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; } Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab. |
3. |
prüfe, ob QES oder nonQES |
Ist im jeweiligen Signaturzertifikat mindestens ein QCStatement mit dem OID id-etsi-qcs-QcCompliance (0.4.0.1862.1.1) enthalten, handelt es sich um eine QES-Signatur, andernfalls liegt eine nonQES-Signatur vor. |
Für QES-Signaturen wird Schritt 4 ausgeführt. Für nonQES-Signaturen wird Schritt 5 ausgeführt. Im Fall eines S/MIME-Dokuments KANN der Konnektor die Operation mit Fehlercode 4279 beenden. |
||
4.a |
Prüfe Signaturdienst-Modul |
Prüfe, ob MGM_LU_SAK=Enabled. Ist dies nicht der Fall, so bricht die Operation mit Fehler 4125 ab. |
4.b |
TUC_KON_151 „QES Dokumentensignatur prüfen“ |
Die QES wird geprüft. Tritt hierbei ein Fehler auf, bricht die Operation ab. |
5. |
TUC_KON_161 „nonQES Dokumentensignatur prüfen“ |
Die nonQES wird geprüft. Tritt hierbei ein Fehler auf, bricht die Operation ab. |
Tabelle 240: TAB_KON_761 Fehlercodes „VerifyDocument (nonQES und QES)“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen TUCs (siehe Tabelle TAB_KON_760 Ablauf Operation VerifyDocument) können folgende weiteren Fehlercodes auftreten: |
|||
4000 |
Technical |
Error |
Syntaxfehler |
4261 | Technical | Warning | Einbettung von Revocation-Informationen nicht unterstützt |
4125 |
Technical |
Error |
LU_SAK nicht aktiviert |
4279 | Technical | Error | S/MIME-Funktionalität nicht unterstützt |
4283 | Technical | Error | Dokument zu groß |
4.1.8.5.3 StopSignature
TIP1-A_5666-02 - Operation StopSignature (nonQES und QES)
Der Signaturdienst des Konnektors MUSS an der Clientschnittstelle eine Operation StopSignature anbieten.
Tabelle 241: TAB_KON_840 Operation StopSignature
Name |
StopSignature |
||
---|---|---|---|
Beschreibung |
Diese Operation unterbricht die Signatur eines Dokumentenstapels. Der Konnektor MUSS jede Signaturerstellung für ein Dokumentenstapel unterbrechen können. |
||
Aufrufparameter |
|||
Name |
Beschreibung |
||
CCTX:Context |
MandantId, ClientSystemId, WorkplaceId verpflichtend; UserId nicht ausgewertet |
||
SIG: JobNumber |
Die Nummer des Jobs, der gestoppt werden soll. |
||
Rückgabe |
|||
CONN:Status |
Enthält den Ausführungsstatus der Operation. |
||
Vorbedingungen |
Keine |
||
Nachbedingungen |
Keine |
Tabelle 242: TAB_KON_841 Ablauf Operation StopSignature
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1. |
checkArguments | Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Dabei wird auch das CardHandle zu der übergebenen JobNumber ermittelt und dieses CardHandle zusammen mit dem übergebenen Context einer Berechtigungsprüfung unterworfen. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab. |
2. | Stoppe die Stapelsignaturverarbeitung |
Die Verarbeitung der Stapelsignatur wird abgebrochen |
Tabelle 243: TAB_KON_842 Fehlercodes „StopSignature“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Folgende Fehlercodes können auftreten: |
|||
4000 |
Technical |
Error |
Syntaxfehler |
4243 |
Technical |
Error |
Jobnummer unbekannt |
4.1.8.5.4 GetJobNumber
TIP1-A_5667 - Operation GetJobNumber
Tabelle 244: TAB_KON_843 Operation GetJobNumber
Name |
GetJobNumber |
||
---|---|---|---|
Beschreibung |
Diese Operation liefert eine Jobnummer zur Verwendung in der Operation SignDocument. Die Jobnummer MUSS nach den Vorgaben von Kapitel 4.1.8.1.4 erstellt werden. |
||
Aufrufparameter |
|||
Name |
Beschreibung |
||
CCTX:Context |
MandantId, ClientSystemId, WorkplaceId verpflichtend; UserId nicht ausgewertet |
||
Rückgabe |
|||
SIG: JobNumber |
Jobnummer zur Verwendung in „SignDocument“ |
||
Vorbedingungen |
Keine |
||
Nachbedingungen |
Keine |
Tabelle 245: TAB_KON_844 Ablauf Operation GetJobNumber
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. |
Generiere und liefere eine Jobnummer |
Eine innerhalb von 1000 Aufrufen eindeutige Jobnummer wird generiert und geliefert. Die Zählung der Aufrufe erfolgt dabei unabhängig vom Aufrufkontext. |
Tabelle 246: TAB_KON_845 Fehlercodes „GetJobNumber“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Folgende Fehlercodes können auftreten: |
|||
4000 |
Technical |
Error |
Syntaxfehler |
[<=]
4.1.8.5.5 ActivateComfortSignature
A_19107 - Operation ActivateComfortSignature
Der Signaturdienst des Konnektors MUSS an der Clientschnittstelle eine Operation ActivateComfortSignature anbieten.
Tabelle 247: TAB_KON_874 ActivateComfortSignature
Name |
ActivateComfortSignature |
|
Beschreibung |
Diese Operation aktiviert die Komfortsignatur für einen HBA bezogen auf einen Aufrufkontext. |
|
Aufrufparameter |
|
|
Name |
Beschreibung |
|
CONN: Card Handle |
Identifiziert die zu adressierende Karte. Es wird nur der HBA unterstützt. |
|
CCTX:Context |
MandantId, ClientSystemId, WorkplaceId, UserId verpflichtend zu übergeben; MandantId, WorkplaceId nicht ausgewertet |
|
Rückgabe |
||
CONN:Status |
Enthält den Ausführungsstatus der Operation. |
|
SIG: SignatureMode |
Signaturmodus des HBA Enthält bei erfolgreicher Ausführung der Operation den Wert „COMFORT“ |
|
Vorbedingungen |
Keine |
|
Nachbedingungen |
Keine |
Tabelle 248: TAB_KON_877 Ablauf ActivateComfortSignature
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; userId = $context.userId; cardHandle = $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; cardHandle = $context.cardHandle; userId = $context.userId } |
4. |
TUC_KON_171 „Komfortsignatur einschalten“ |
Der Komfortsignaturmodus wird für das Tupel (CardHandle, CardSession) eingeschaltet. Tritt hierbei ein Fehler auf, bricht die Operation ab. |
Tabelle 249: TAB_KON_879 Fehlercodes ActivateComfortSignature
Fehlercode |
ErrorType |
Severity |
Fehlertext |
Neben den Fehlercodes der aufgerufenen TUCs können folgende weiteren Fehlercodes auftreten: |
|||
4000 |
Technical |
Error |
Syntaxfehler |
4270 |
Technical |
Error |
UserId wurde in den letzten 1.000 Vorgängen bereits verwendet |
4272 |
Technical |
Error |
UserId nicht zulässig |
4.1.8.5.6 DeactivateComfortSignature
A_19108 - Operation DeactivateComfortSignature
Der Signaturdienst des Konnektors MUSS an der Clientschnittstelle eine Operation DeactivateComfortSignature anbieten.
Tabelle 250: TAB_KON_875 DeactivateComfortSignature
Name |
DeactivateComfortSignature |
||
Beschreibung |
Diese Operation deaktiviert die Komfortsignatur für einen oder mehrere HBA. |
||
Aufrufparameter |
|
||
Name |
Beschreibung |
||
CONN: Card Handle |
Identifiziert die zu adressierende Karte. Es wird nur der HBA unterstützt. |
||
Rückgabe |
|||
CONN:Status |
Enthält den Ausführungsstatus der Operation. |
||
Vorbedingungen |
Keine |
||
Nachbedingungen |
Keine |
||
Tabelle 251: TAB_KON_878 Ablauf DeactivateComfortSignature
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_172 „Komfortsignatur ausschalten“ |
Der Komfortsignaturmodus wird für alle Karten aus der CardHandle-Liste ausgeschaltet. |
Tabelle 252: TAB_KON_880 Fehlercodes DeactivateComfortSignature
Fehlercode |
ErrorType |
Severity |
Fehlertext |
Neben den Fehlercodes der aufgerufenen TUCs können folgende weiteren Fehlercodes auftreten: |
|||
4000 |
Technical |
Error |
Syntaxfehler |
4.1.8.5.7 GetSignatureMode
A_19109-02 - Operation GetSignatureMode
Der Signaturdienst des Konnektors MUSS an der Clientschnittstelle eine Operation GetSignatureMode anbieten.
Tabelle 253: TAB_KON_876 GetSignatureMode
Name |
GetSignatureMode |
||
---|---|---|---|
Beschreibung |
Diese Operation liefert den aktuell konfigurierten Status der Komfortsignaturfunktion im Konnektor und Session-Informationen zur Kartensitzung für das CardHandle und den Aufrufkontext, falls sich die Kartensitzung im Komfortsignaturmodus befindet. |
||
Aufrufparameter |
|
||
Name |
Beschreibung |
||
CONN:CardHandle |
Identifiziert die zu adressierende Karte. Es wird nur der HBA unterstützt. |
||
CCTX:Context | MandantId, ClientSystemId, WorkplaceId, UserId verpflichtend zu übergeben | ||
Rückgabe |
|||
CONN:Status | Enthält den Ausführungsstatus der Operation. | ||
|
SIG: ComfortSignatureStatus |
Komfortsignatur-Konfigurationsstatus des Konnektors |
|
|
SIG:ComfortSignatureMax |
Im Konnektor konfigurierte Anzahl von Komfortsignaturen, die ohne erneute PIN-Eingabe ausgeführt werden dürfen |
|
|
SIG: ComfortSignatureTimer |
Im Konnektor konfiguriertes Zeitintervall, in dem Komfortsignaturen ohne erneute PIN-Eingabe ausgeführt werden dürfen, Format: "PTnHnMnS" (gemäß Datenttyp xsd:duration) |
|
|
SIG:SessionInfo | Falls vorhanden, Session-Informationen zur Komfortsignatursession für das CardHandle und den Aufrufkontext |
|
|
SIG:SignatureMode | Signaturmodus der Komfortsignatursession (="COMFORT") | |
|
SIG:CountRemaining |
Verbleibende Anzahl von Komfortsignaturen, die ohne erneute PIN-Eingabe ausgeführt werden dürfen |
|
SIG:TimeRemaining | Verbleibende Zeit, in der Komfortsignaturen ohne erneute PIN-Eingabe ausgeführt werden dürfen Format: "PTnHnMnS" (gemäß Datenttyp xsd:duration) |
||
Vorbedingungen |
Keine |
||
Nachbedingungen |
Keine |
Tabelle 254: TAB_KON_882 Ablauf GetSignatureMode
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; userId = $context.userId; cardHandle = $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; cardHandle = $context.cardHandle; userId = $context.userId } |
4. |
TUC_KON_173 „Liefere Signaturmodus“ |
Der Komfortsignatur-Konfigurationsstatus des Konnektors und, falls vorhanden, Session-Informationen zur Komfortsignatursession für das CardHandle und den Aufrufkontext werden zurückgeliefert. |
Tabelle 255: TAB_KON_881 Fehlercodes GetSignatureMode
Fehlercode |
ErrorType |
Severity |
Fehlertext |
Folgende Fehlercodes können auftreten: |
|||
4000 |
Technical |
Error |
Syntaxfehler |
4.1.8.6 Betriebsaspekte
TIP1-A_4680-03 - Konfigurationswerte des Signaturdienstes
Die Managementschnittstelle MUSS es einem Administrator ermöglichen Konfigurationsänderungen gemäß Tabelle TAB_KON_596 vorzunehmen:
Tabelle 256: TAB_KON_596 Konfigurationswerte des Signaturdienstes (Administrator)
ReferenzID |
Belegung |
Bedeutung und Administrator-Interaktion |
---|---|---|
SAK_SIMPLE_ SIGNATURE_ MODE |
SE#1 SE#2 |
Aktivierung/Deaktivierung des „Einfachsignaturmodus“ für alle HBAx für die Durchführung von Einfachsignaturen im SecurityEnvironment #1 (SE#1) für Dokumentenstapel der Größe 1 anstelle der Verwendung des SE#2. Default-Wert = SE#1 |
SAK_COMFORT_ SIGNATURE |
Enabled/ Disabled |
Aktivierung/Deaktivierung der Komfortsignaturfunktion im Konnektor Default-Wert = Disabled Die Komfortsignaturfunktion darf nur aktiviert sein, wenn ANCL_TLS_MANDATORY = Enabled und ANCL_CAUT_MANDATORY = Enabled |
SAK_COMFORT_ SIGNATURE_MAX |
[1 - 250] | Anzahl von Komfortsignaturen, die ohne erneute PIN-Eingabe ausgeführt werden dürfen Default-Wert = 100 Der Parameter ist nur relevant, wenn die Komfortsignaturfunktion aktiviert ist (SAK_COMFORT_SIGNATURE = Enabled). |
SAK_COMFORT_ SIGNATURE_TIMER |
[1 – 24 h] | Zeitintervall, in dem Komfortsignaturen ohne erneute PIN-Eingabe ausgeführt werden dürfen Der Timer startet mit Eingabe der PIN.QES für die Komfortsignatur. Default-Wert = 6 h Der Parameter ist nur relevant, wenn die Komfortsignaturfunktion aktiviert ist (SAK_COMFORT_SIGNATURE = Enabled). |
[<=]
4.1.9 Zertifikatsdienst
Der Zertifikatsdienst bietet eine Schnittstelle zur Überprüfung der Gültigkeit von Zertifikaten an. Dies geschieht auf Grundlage des durch den Vertrauensanker (TSL-CA-Signer-Zertifikat und eine aktuelle, gültige TSL aufgespannten Vertrauensraums sowie unter Berücksichtigung von aktuellen Statusinformationen (OCSP, CRL). Die Zertifikatsprüfung wird sowohl für nonQES- als auch für QES-Zertifikate unterstützt.
Die für die QES-Zertifikatsprüfung notwendigen QES-Signer-Zertifikate werden durch die Vertrauensliste der Bundesnetzagentur (BNetzA-VL) bereitgestellt. Das Signer-Zertifikat der BNetzA-VL ist in der TSL enthalten.
Im Rahmen der ECC-Migration muss der Konnektor neben RSA auch ECC unterstützen. Hierfür wird eine TSL bereitgestellt, die sowohl die neuen ECC-basierten Zertifikate als auch aus Rückwärtskompatibilitätsgründen die weiterhin benötigten RSA-basierten Zertifikate enthält. Diese neue TSL wird auch als „TSL(ECC-RSA)“ bezeichnet. In dieser Spezifikation wird außerhalb der Regelungen zur ECC-Migration nicht zwischen „TSL(ECC-RSA)" und „TSL(RSA)" unterschieden, da die Anforderungslage keine Unterscheidung erfordert.
Innerhalb des Zertifikatsdienstes werden folgende Präfixe für Bezeichner verwendet:
- Events (Topic Ebene 1): „CERT“
- Konfigurationsparameter: „CERT_“
4.1.9.1 Funktionsmerkmalweite Aspekte
Bei der Zertifikatsprüfung wird im Rahmen eines Anwendungsfalls u.a. auch der Verwendungszweck des Zertifikats geprüft. Der Verwendungszweck (intendedKeyUsage) wird als Parameter an TUC_KON_037 übergeben. Der konkrete Wert von intendedKeyUsage ist abhängig vom kryptographischen Verfahren, auf welchem das Zertifikat basiert. Die Parametrisierung von intendedKeyUsage wird in TAB_KON_853 in Abhängigkeit vom zu prüfenden Zertifikat, dem Anwendungsfall und dem kryptographischen Verfahren definiert.
A_17295-01 - Verwendung der intendedKeyUsage bei der Zertifikatsprüfung (ECC-Migration)
Der Konnektor MUSS bei der Zertifikatsprüfung die intendedKeyUsage in Abhängigkeit vom zu prüfenden Zertifikat, dem Anwendungsfall und dem kryptographischen Verfahren gemäß TAB_KON_853 prüfen.
Tabelle 257: TAB_KON_853- intendedKeyUsage bei Zertifikatsprüfung
Zertifikat | Anwendungsfall | intendedKeyUsage bei | |
---|---|---|---|
RSA | ECC | ||
C.SMKT.AUT | TUC_KON_050 „Beginne Kartenterminalsitzung“ TUC_KON_053 „Paire Kartenterminal“ |
digitalSignature &keyEncipherment |
digitalSignature |
C.CH.AUT C.CH.AUTN |
TUC_KON_161 „nonQES Dokumentsignatur prüfen” | digitalSignature &keyEncipherment |
digitalSignature |
C.CH.ENC C.CH.ENCV C.HCI.ENC C.HP.ENC Zertifikate aus CERT_IMPORTED_CA_LIST |
TUC_KON_070 „Daten hybrid verschlüsseln“ | keyEncipherment | keyAgreement |
C.HCI.OSIG | TUC_KON_161 „nonQES Dokumentsignatur prüfen” | nonRepudiation | nonRepudiation |
C.FD.TLS-S | TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen“ |
digitalSignature&keyEncipherment | digitalSignature |
C.ZD.TLS-S | TUC_KON_290 „LDAP-Verbindung aufbauen“ | digitalSignature | digitalSignature |
C.ZD.TLS-S | TIP1-A_5662 - Gesicherte Übertragung von BNetzA-VL und Hashwert TUC_KON_282 „UpdateInformationen beziehen“ TUC_KON_283 Infrastruktur Konfiguration aktualisieren TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“ TUC_KON_286 „Paket für Fachmodul laden“ |
digitalSignature&keyEncipherment | digitalSignature |
C.FD.AUT | A_17225-* | digitalSignature&keyEncipherment | digitalSignature |
C.FD.SIG | TUC_KON_161 „nonQES Dokumentsignatur prüfen” | digitalSignature | digitalSignature |
C.FD.OSIG | TUC_KON_161 „nonQES Dokumentsignatur prüfen” | nonRepudiation | nonRepudiation |
C.ZD.SIG | TUC_KON_161 „nonQES Dokumentsignatur prüfen” | nonRepudiation | nonRepudiation |
Bei der Zertifikatsprüfung wird ein übergebenes Zertifikat oder ein Zertifikat einer referenzierten Karte geprüft. Das konkrete Zertifikatsobjekt einer Karte ist abhängig vom Kartentyp und dem gewählten kryptographischen Verfahren. Die folgende Tabelle führt auf, welche Zertifikatsobjekte einer Karte in Abhängigkeit vom kryptographischen Verfahren für die jeweilige Zertifikatsreferenz ausgewählt werden.
Tabelle 258: TAB_KON_858 Kartenobjekt in Abhängigkeit vom kryptographischen Verfahren
CertRef |
Kartentyp |
Objekt der Karte in Abhängigkeit vom kryptographischen Verfahren (Crypt) |
|
---|---|---|---|
RSA |
ECC |
||
C.AUT |
HBA-VK |
EF.C.HP.AUT |
- |
HBA |
EF.C.HP.AUT.R2048 |
EF.C.HP.AUT.E256 |
|
SM-B |
EF.C.HCI.AUT |
EF.C.HCI.AUT.E256 |
|
eGK G2 |
EF.C.CH.AUT.R2048 |
EF.C.CH.AUT.E256 |
|
C.ENC |
HBA-VK |
EF.C.HP.ENC |
- |
HBA |
EF.C.HP.ENC.2048 |
EF.C.HP.ENC.E256 |
|
SM-B |
EF.C.HCI.ENC.R2048 |
EF.C.HCI.ENC.E256 |
|
C.SIG |
SM-B |
EF.C.HCI.OSIG.R2048 |
EF.C.HCI.OSIG.E256 |
C.QES |
HBA-VK |
EF.C.HP.QES |
- |
HBA |
EF.C.HP.QES.R2048 |
EF.C.HP.QES.E256 |
TIP1-A_4682 - Sicheres Einbringen des TI-Vertrauensankers
Der Vertrauensanker der TI MUSS zum Auslieferungszeitpunkt des Konnektors integritätsgeschützt im Konnektor hinterlegt sein. Zur Sicherstellung dieser Integrität MUSS die Dateiablage EF.C.TSL.CA_1 der Anwendung DF.Sicherheitsanker der gSMC-K [gemSpec_gSMC-K_ObjSys#5.7.2] verwendet werden.
[<=]TIP1-A_4684 - Regelmäßige Aktualisierung der CRL und der TSL
Falls Parameter MGM_LU_ONLINE=Enabled, MUSS der Zertifikatsdienst einmal täglich die Aktualisierung der TSL durch Aufruf von TUC_KON_032 „TSL aktualisieren“ durchführen und anschließend TUC_KON_040 „CRL aktualisieren“ aufrufen.
[<=]
TIP1-A_4685 - Vermeidung von Spitzenlasten bei TSL- und CRL-Download
Der Konnektor MUSS Spitzenlasten durch paralleles Herunterladen der TSL und der CRL vermeiden. Dazu MÜSSEN die im Einsatz befindlichen Konnektoren eines Herstellers ihre Download-Versuche gleichmäßig über den Tag verteilen.
[<=]Dadurch wird gleichzeitig die Spitzenlast bei OCSP-Anfragen begrenzt.
A_17572 - Nutzung der Hash-Datei für TSL (ECC-Migration)
Falls die TSL(ECC-RSA) verwendet wird, MUSS der Konnektor vor deren Aktualisierung mit TUC_KON_032 „TSL aktualisieren“ die Hash-Datei der TSL(ECC-RSA) herunterladen, um zu prüfen, ob die am TSL-Downloadpunkt verfügbare TSL(ECC-RSA) eine andere ist, als die schon zuvor heruntergeladene und bereits ausgewertete TSL(ECC-RSA). Entspricht der Hash-Wert am Download-Punkt der bereits heruntergeladenen und ausgewerteten TSL(ECC-RSA), MUSS der Konnektor auf den Download verzichten. [<=]
A_17661 - Gesicherte Übertragung der Hash-Datei für TSL (ECC-Migration)
Der Konnektor MUSS für den Download der Hash-Datei der TSL(ECC-RSA) die Verbindung zum TSL-Dienst durch TLS absichern. Der Konnektor MUSS das vom TSL-Dienst beim TLS-Verbindungsaufbau präsentierte Zertifikat C.ZD.TLS-S prüfen. Die Prüfung erfolgt durch Aufruf von TUC_KON_037 „Zertifikat prüfen“ {
qualifiedCheck = not_required;
offlineAllowNoCheck = true;
policyList = oid_zd_tls_s;
intendedKeyUsage = intendedKeyUsage(C.ZD.TLS-S);
intendedExtendedKeyUsage = id-kp-serverAuth;
validationMode = OCSP } .
[<=]
A_17781 - Aktualisierung der TSL ohne Hash-Datei für TSL (ECC-Migration)
Falls im Rahmen der TSL-Aktualisierung beim Download der Hash-Datei der TSL(ECC-RSA) ein Fehler auftritt MUSS der Konnektor die Aktualisierung der TSL mit TUC_KON_032 „TSL aktualisieren“ ohne einen ermittelten Hashwert aufrufen. [<=]
TIP1-A_6730 - Regelmäßige Aktualisierung der BNetzA-VL
Falls Parameter MGM_LU_ONLINE=Enabled, MUSS der Zertifikatsdienst die Aktualisierung der BNetzA-VL im Zeitintervall CERT_BNETZA_VL_UPDATE_INTERVAL durch Aufruf von TUC_KON_031 „BNetzA-VL aktualisieren“ durchführen.
[<=]TIP1-A_6731 - Regelmäßige Prüfung der BNetzA-VL
Der Zertifikatsdienst MUSS einmal täglich die zeitliche Gültigkeit der BNetzA-VL prüfen. Wenn das Element NextUpdate in der Vergangenheit liegt MUSS der Konnektor den Betriebszustand EC_ BNetzA_VL_not_valid auslösen.
[<=]TIP1-A_6732 - Vermeidung von Spitzenlasten bei BNetzA-VL-Download
Der Konnektor MUSS Spitzenlasten durch Herunterladen der BNetzA-VL vermeiden. Dazu MÜSSEN die im Einsatz befindlichen Konnektoren den Zeitpunkt für den Download zufällig wählen unter Beachtung des konfigurierten Zeitintervalls CERT_BNETZA_VL_UPDATE_INTERVAL.
[<=]TIP1-A_5662 - Gesicherte Übertragung von BNetzA-VL und Hashwert
Der Konnektor MUSS für den Download der BNetzA-VL und deren Hashwert die Verbindung zum TSL-Dienst durch TLS absichern. Der Konnektor MUSS das vom TSL-Dienst beim TLS-Verbindungsaufbau präsentierte Zertifikat ID.ZD.TLS_S prüfen. Die Prüfung erfolgt durch Aufruf von TUC_KON_037 „Zertifikat prüfen“ {
qualifiedCheck = not_required;
offlineAllowNoCheck = true;
policyList = oid_zd_tls_s;
intendedKeyUsage = intendedKeyUsage(C.ZD.TLS-S);
intendedExtendedKeyUsage = id-kp-serverAuth;
validationMode = OCSP } .
Tabelle 259: TAB_KON_825 Fehlercodes „TLS-Verbindungsaufbau zum TSL-Dienst“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4235 |
Security |
Error |
TSL-Dienst konnte bei TLS-Verbindungsaufbau nicht authentisiert werden |
[<=]
TIP1-A_5663 - Prüfung der technischen Rolle bei TLS-Verbindungsaufbau zum TSL-Dienst
Der Konnektor MUSS beim TLS-Verbindungsaufbau zum TSL-Dienst prüfen, dass die vom TSL-Dienst in ID.ZD.TLS_S übergebene technische Rolle gemäß [gemSpec_OID#GS-A_4446] dem Wert „oid_tsl_ti“ entspricht.
Ein Fehler bei der Prüfung der techischen Rolle führt zum Abbruch des TLS-Verbindungsaufbaus mit Fehlercode 4236 gemäß TAB_KON_826.
Tabelle 260: TAB_KON_826 Fehlercodes „TLS-Verbindungsaufbau zum TSL-Dienst bei Prüfung der technischen Rolle“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
4236 |
Security |
Error |
Rollenprüfung bei TLS-Verbindungsaufbau zum TSL-Dienst fehlgeschlagen |
TIP1-A_4686 - Warnung vor und bei Ablauf der TSL
Steht der Ablauf der TSL innerhalb von 7 Tagen an, MUSS der Konnektor den Betriebszustand EC_TSL_Expiring annehmen.
Mit Ablauf der Gültigkeit der TSL MUSS der Konnektor den Betriebszustand EC_TSL_Out_Of_Date_Within_Grace_Period annehmen.
Mit Ablauf der Graceperiod der TSL MUSS der Konnektor den kritischen Betriebszustand EC_TSL_Out_Of_Date_Beyond_Grace_Period annehmen.
[<=]TIP1-A_4687 - Warnung vor und bei Ablauf des TI-Vertrauensankers
Steht der Ablauf der Gültigkeit des TI-Vertrauensankers innerhalb von 30 Tagen an, MUSS der Konnektor den Betriebszustand EC_TSL_Trust_Anchor_Expiring annehmen.
Mit Ablauf der Gültigkeit des Vertrauensankers MUSS der Konnektor den kritischen Betriebszustand EC_TSL_Trust_Anchor_Out_Of_Date annehmen.
[<=]TIP1-A_4994 - Warnung vor und bei Ablauf der CRL
Steht der Ablauf der Gültigkeit der CRL innerhalb von 3 Tagen an, MUSS der Konnektor den Betriebszustand EC_CRL_Expiring annehmen.
Mit Ablauf der Gültigkeit der CRL MUSS der Konnektor den kritischen Betriebszustand EC_CRL_Out_Of_Date annehmen.
[<=]TIP1-A_4688 - OCSP-Forwarding
Der Konnektor MUSS alle OCSP-Anfragen über den OCSP-Forwarder (HTTP-Proxy) des Zugangsdienst-Providers schicken, der durch die Konfigurationswerte (CERT_OCSP_FORWARDER_ADDRESS, CERT_OCSP_FORWARDER_PORT) festgelegt ist.
[<=]TIP1-A_4689 - Caching von OCSP-Antworten
Der Zertifikatsdienst MUSS erhaltene OCSP-Antworten für eine durch CERT_OCSP_DEFAULT_GRACE_PERIOD_NONQES angegebene Anzahl an Minuten (nonQES-Zertifikate) zwischenspeichern.
[<=]TIP1-A_4690 - Timeout und Graceperiod für OCSP-Anfragen
Bei Ausführung von TUC_PKI_006 „OCSP-Abfrage“ [gemSpec_PKI#8.3.2.2] MÜSSEN folgende Parameter verwendet werden:
OCSP-Graceperiod =
CERT_OCSP_DEFAULT_GRACE_PERIOD_NONQES
- Timeout-Parameter =
CERT_OCSP_TIMEOUT_NONQES bzw.
CERT_OCSP_TIMEOUT_QES
TIP1-A_4691 - Ablauf der gSMC-K und der gesteckten Karten regelmäßig prüfen
Für die gSMC-K sowie für jede gesteckte Karte außer eGK MUSS der Konnektor im Intervall CERT_EXPIRATION_CARD_CHECK_DAYS genau einmal TUC_KON_033 aufrufen.
Der Konnektor MUSS die Gültigkeitsdauer der Zertifikate prüfen mittels Aufruf von:
für gSMC-K
TUC_KON_033{checkSMCK; doInformClients=Ja; crypt = ECC}
TUC_KON_033{checkSMCK; doInformClients=Ja; crypt = RSA}
für jede gesteckte G2.0 Karte außer eGK und außer gSMC-K
TUC_KON_033{cardSession; doInformClients=Ja; crypt = RSA}
für jede gesteckte ab G2.1 Karte außer eGK
TUC_KON_033{cardSession; doInformClients=Ja; crypt = ECC}
TUC_KON_033{cardSession; doInformClients=Ja; crypt = RSA}
[<=]
TIP1-A_4692 - Missbrauchserkennung, zu kontrollierende Operationen
Der Konnektor MUSS zur Unterstützung von Missbrauchserkennungen die in Tabelle TAB_KON_597 gelisteten Operationen als Einträge in EVT_MONITOR_OPERATIONS berücksichtigen.
Tabelle 261: TAB_KON_597 Operationen in EVT_MONITOR_OPERATIONS
Operationsname |
OK_Val |
NOK_Val |
Alarmwert (Default-Grenzwert 10 Minuten- Σ) |
---|---|---|---|
VerifyCertificate |
1 |
5 |
401 |
[<=]
A_23274 - Starten des Downloads der CRL und der TSL
Der Konnektor SOLL dem Administrator an der Management-Oberfläche die Aktualisierung der TSL und CRL per Download ermöglichen. Dabei wird TUC_KON_032 „TSL aktualisieren“ und anschließend TUC_KON_040 „CRL aktualisieren“ aufgerufen. [<=]
4.1.9.2 Durch Ereignisse ausgelöste Reaktionen
Keine.
4.1.9.3 Interne TUCs, nicht durch Fachmodule nutzbar
4.1.9.3.1 TUC_KON_032 „TSL aktualisieren“
TIP1-A_4693-02 - TUC_KON_032 „TSL aktualisieren”
Der Konnektor MUSS den technischen Use Case TUC_KON_032 „TSL aktualisieren“ umsetzen.
Tabelle 262: TAB_KON_766 TUC_KON_032 „TSL aktualisieren“
Element |
Beschreibung |
Name |
TUC_KON_032 „TSL aktualisieren“ |
Beschreibung |
Dieser TUC prüft die Aktualität der TSL und initialisiert ggf. den TSL-spezifischen Bereich des TrustStores neu. Zusätzlich wird bei einem Wechsel des TI-Vertrauensankers das neue TSL-Signer-CA-Zertifikat in einem sicheren Speicherort im Konnektor hinterlegt. Im Fall der Veröffentlichung eines CVC-Root-CA-Zertifikats werden das CVC-Root-CA-Zertifikat und die Cross-CV-Zertifikate aus der TSL in den Truststore eingestellt. |
Auslöser |
|
Vorbedingungen |
|
Eingangsdaten |
|
Komponenten |
Konnektor |
Ausgangsdaten |
|
Nachbedingungen |
|
Standardablauf |
|
Varianten/ Alternativen |
(-> 1) Wenn der Download der TSL aus der TI fehlschlägt oder wenn der Konnektor im Fall onlineMode = ENABLED keine Verbindung zur TI hat, muss der Konnektor die TSL vom Download-Punkt im Internet (CERT_TSL_DOWNLOAD_ADDRESS_INTERNET) gemäß [gemSpec_TSL#A_21182] beziehen. Im Fall onlineMode = DISABLED wird abgebrochen. Wenn kein aktiver VPN-Tunnel SIS vorhanden ist, muss der Konnektor den Downloadversuch der TSL aus dem Internet direkt über das IAG initiieren, auch wenn ANLW_INTERNET_MODUS=SIS konfiguriert ist. Im Fall ANLW_INTERNET_MODUS=KEINER wird abgebrochen. Wenn die Namensauflösung für CERT_TSL_DOWNLOAD_ADDRESS_INTERNET fehlschlägt, muss der Konnektor die TSL über CERT_TSL_IP_ADDRESS_INTERNET beziehen. Wenn keiner der vorigen Downloadversuche erfolgreich war, muss der Konnektor die TSL von der konfigurierbaren Adresse CERT_TSL_DOWNLOAD_ADDRESS_INTERNET_BU beziehen. Wenn die Namensauflösung für CERT_TSL_DOWNLOAD_ADDRESS_INTERNET_BU fehlschlägt, muss der Konnektor die TSL über CERT_TSL_IP_ADDRESS_INTERNET_BU beziehen. Für eine aus dem Internet bezogene TSL muss der Konnektor auch die vom TSL-Dienst gemäß [gemSpec_TSL#A_21182] bereitgestellte detached-Signatur der TSL herunterladen. Der Konnektor muss dann immer zunächst die detached-Signatur der TSL prüfen, einschließlich vollständiger Prüfung der Zertifikatskette bis zum TI-Vertrauensanker. Die kryptographische Prüfung der Signatur muss entsprechend A_21185 durchgeführt werden. Bezüglich der Prüfung des Sperrstatus des TSL-Signer-Zertifikats muss der Konnektor eines der folgenden Verfahren umsetzen:
(1) Falls onlineMode = DISABLED, kann der Sperrstatus des TSL-Signer-Zertifikats nicht überprüft werden. In diesem Fall wird die Aktivierung der importedTSL auch ohne Prüfung des Sperrstatus durchgeführt. (1) Wird durch den von TUC_PKI_001 aufgerufenen TUC_PKI_013 „Import neuer Vertrauensanker“ ein neuer TI-Vertrauensanker (ein neues TSL-Signer-CA-Zertifikat) in der importedTSL gefunden, so wird dieser, wie dort beschrieben, extrahiert und in einem sicheren Speicherort gespeichert. Vor Erreichen des Aktivierungsdatums werden die TSLs ausschließlich mit dem alten TSL-Signer-Zertifikat signiert. Ab dem Aktivierungsdatum werden die TSLs mit einem TSL-Signer-Zertifikat signiert, das von der neuen TSL-Signer-CA ausgestellt wurde. |
Fehlerfälle |
(1) Tritt beim manuellen Import der Datei ein Fehler auf, wird TUC_KON_256 { topic = „CERT/TSL/IMPORT“; eventType = Op; severity = Error; parameters = „$Fehlerbeschreibung“; doLog = true; doDisp = false } ausgelöst. Fehlercode 4128. (1) Tritt beim periodischen Update der TSL beim Aufruf des TUC_PKI_001 oder eines durch ihn aufgerufenen TUCs ein Fehler auf, geht der Konnektor in den Betriebszustand EC_TSL_Update_Not_Successful. Der Konnektor geht erst in den Betriebszustand EC_TSL_Update_Not_Successful, wenn weder der Downloadversuch aus der TI noch der Downloadversuch aus dem Internet erfolgreich war. Die vorhandenen TSL-Vertrauensanker werden weiter verwendet. Fehlercode 4127. |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
Tabelle 263: TAB_KON_598 Fehlercodes TUC_KON_032 „TSL aktualisieren“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4127 |
Security |
Error |
Import der TSL-Datei fehlgeschlagen |
4128 |
Technical |
Error |
der manuelle Import der TSL-Datei schlägt fehl |
[<=]
Für den Download der TSL über einen HTTP-Server im Internet wird zusätzlich zu der bereits mit einer XML-Signatur versehenen TSL eine detached-Signatur als separate Datei auf dem Download-Punkt zur Verfügung gestellt. Diese detached-Signatur umfasst die TSL in ihrerer Gänze, das heißt die TSL-XML-Datei wird inkl. der dort bereits enthaltenen XML-Signatur nochmal durch den TSL-Signer signiert. Ein Konnektor verwendet dann bei der Signaturprüfung einer TSL, die über das Internet bezogen wurde, die detached-Signatur für die Signaturprüfung. Hintergrund ist die aus Sicherheitsperspektive einfachere, im Sinne von sicherer prüfbare detached-Signatur. Das heißt, die TSL muss nicht als XML-File verarbeitet und die relativ komplexe XML-Signatur - die potentiell von einem Angreifer modifiziert sein könnte - nicht ausgewertet werden. Deshalb wird der Weg gewählt, der auch für die Signatur von X.509-Zertifikaten und OCSP-Responses verwendet wird.
A_21185 - Prüfung der detached Signatur der TSL bei Download aus dem Internet
Der Konnektor MUSS beim Download der TSL aus dem Internet ebenfalls deren detached-Signatur (vgl. [gemSpec_TSL#A_21182]) mit herunterladen und immer zunächst folgende Prüfungen durchführen:
- Prüfung, dass die heruntergeladene detached-Signatur-Datei den folgenden Aufbau aufweist:
Sequence aus drei Elementen:
SEQUENCE {
a
b
c}
Mit a, b und c wie folgt: -
- OID für den Signaturtyp, bestehend aus
-
- im Falle ECDSA:
SEQUENCE {OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2)} - im Falle RSASSA-PSS:
SEQUENCE {OBJECT IDENTIFIER rsaPSS (1 2 840 113549 1 1 10)
SEQUENCE {
[0] {SEQUENCE {OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)}}
[1] {SEQUENCE {
OBJECT IDENTIFIER pkcs1-MGF (1 2 840 113549 1 1 8)
SEQUENCE {OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)}}}
[2] {INTEGER 32}}}
- im Falle ECDSA:
- Kryptographische Signatur
-
- im Falle ECDSA:
einer ECDSA-Signatur nach [BSI-TR-03111#5.2.2.] - im Falle RSASSA-PSS:
eine RSASSA-PSS-Signatur nach [RFC-8017] (reiner ASN.1-kodierter Signaturwert – die OID ist schon in Teil a.ii. aufgeführt)
- im Falle ECDSA:
- Zertifikat des Signierenden (TSL-Signer)
-
- im Falle ECDSA:
genau nur das ECC-TSL-Signer-Zertifikat - im Falle RSASSA-PSS:
genau nur das RSA-TSL-Signer-Zertifikat
- im Falle ECDSA:
- Prüfung der Signatur (1b) gegen das TSL-Signer-Zertifikat (1c).
Ist die Prüfung erfolgreich, KANN die Prüfung der XML-Signatur der TSL im weiteren fachlichen Ablauf der TSL-Aktualisierung entfallen.
[<=]
Eine erweiterte Übersicht zum Aufbau der detached-Signatur-Datei inkl. Beispiel finden sie unter [gemGitHub_tslSig].
A_20750 - Hinweis auf Betreiber-Verantwortung bei automatischer TSL-Aktualisierung
Der Hersteller des Konnektors MUSS den Betreiber des Konnektors in geeigneter Weise (mindestens per Handbuch-Eintrag und per Hinweis innerhalb der UpdateInformation eines FirmwareUpdates am KSR) darüber informieren, dass im Fall, dass eine TSL-Aktualisierung innerhalb der TI fehlschlägt, automatisch versucht wird, eine TSL-Aktualisierung aus dem Internet vorzunehmen. [<=]
4.1.9.3.2 TUC_KON_031 „BNetzA-VL aktualisieren“
TIP1-A_6729 - TUC_KON_031 „BNetzA-VL aktualisieren”
Der Konnektor MUSS den technischen Use Case TUC_KON_031 „BNetzA-VL aktualisieren“ umsetzen.
Tabelle 264: TAB_KON_618 TUC_KON_031 „BNetzA-VL aktualisieren“
Element |
Beschreibung |
Name |
TUC_KON_031 „BNetzA-VL aktualisieren” |
Beschreibung |
Dieser TUC prüft die Aktualität der BNetzA-VL. Wenn eine neuere BNetzA-VL vorliegt, wird diese heruntergeladen, geprüft und im Truststore gespeichert. |
Auslöser |
|
Vorbedingungen |
|
Eingangsdaten |
|
Komponenten |
Konnektor |
Ausgangsdaten |
|
Nachbedingungen |
|
Standardablauf |
|
Varianten/Alternativen |
(1) Wird eine zu importierende BNetzA-VL manuell übergeben (in den Eingangsdaten), so wird diese statt des Downloads verwendet und an TUC_PKI_036 {BNetzA-VL Datei} übergeben. Innerhalb der PKI TUCs findet dann kein Download der BNetzA-VL statt. (1) Ist MGM_LU_SAK=disabled, so wird der TUC ohne Fehler beendet. |
Fehlerfälle |
(1) Tritt beim manuellen Import der Datei ein Fehler auf, wird TUC_KON_256 {„CERT/BNETZA_VL/IMPORT“; Op; Error; „$Fehlerbeschreibung“; doLog = true; doDisp = false} ausgelöst. Fehlercode 4129. (1) Tritt beim periodischen Update der BNetzA-VL beim Aufruf des TUC_PKI_036 oder eines durch ihn aufgerufenen TUCs ein Fehler auf, geht der Konnektor in den Betriebszustand EC_BNetzA_VL_Update_Not_Successful. Fehlercode 4133. In beiden Fällen wird eine vorhandene gültige BNetzA-VL weiter verwendet. |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
Tabelle 265: TAB_KON_619 Fehlercodes TUC_KON_031 „BNetzA-VL aktualisieren“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4129 |
Technical |
Error |
der manuelle Import der BNetzA-Vertrauensliste schlägt fehl |
4133 |
Security |
Error |
Import der BNetzA-Vertrauensliste fehlgeschlagen |
[<=]
4.1.9.3.3 TUC_KON_040 „CRL aktualisieren“
TIP1-A_4694 - TUC_KON_040 „CRL aktualisieren“
Der Konnektor MUSS den technischen Use Case TUC_KON_040 „CRL aktualisieren“ umsetzen.
Tabelle 266: TAB_KON_767 TUC_KON_040 „CRL aktualisieren“
Element |
Beschreibung |
Name |
TUC_KON_040 „CRL aktualisieren“ |
Beschreibung |
Dieser TUC aktualisiert die CRL |
Auslöser |
|
Vorbedingungen |
|
Eingangsdaten |
|
Komponenten |
Konnektor |
Ausgangsdaten |
Keine |
Nachbedingungen |
|
Standardablauf |
topic = „CERT/CRL/UPDATED“;
eventType = Op; severity = Error; parameters = „„; doLog = true; doDisp=false} aus.
|
Varianten/ Alternativen |
(1) Wird eine manuell importierte CRL übergeben, so wird diese verwendet. |
Fehlerfälle |
(1) Tritt beim manuellen Import der Datei ein Fehler auf, wird TUC_KON_256 { topic = „CERT/CRL/IMPORT“; eventType = Op; severity = Error; parameters = „${Fehlerbeschreibung}“; doLog = true; doDisp=false} ausgelöst. (2) Signaturprüfung der CRL fehlgeschlagen: Fehlercode 4130 |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
Tabelle 267: TAB_KON_599 Fehlercodes TUC_KON_040 „CRL aktualisieren“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4130 |
Security |
Error |
Signatur- oder Gültigkeitsprüfung der CRL fehlgeschlagen |
[<=]
4.1.9.3.4 TUC_KON_033 „Zertifikatsablauf prüfen“
TIP1-A_4695 - TUC_KON_033 „Zertifikatsablauf prüfen“
Der Konnektor MUSS den technischen Use Case TUC_KON_033 „Zertifikatsablauf prüfen” umsetzen.
Tabelle 268: TAB_KON_768 TUC_KON_033 „Zertifikatsablauf prüfen“
Element |
Beschreibung |
Name |
TUC_KON_033 „Zertifikatsablauf prüfen“ |
Beschreibung |
Dieser TUC prüft und meldet das zeitliche Ablaufen eines X.509-Zertifikats einer Karte. |
Auslöser |
|
Vorbedingungen |
Keine |
Eingangsdaten |
|
Komponenten |
Konnektor |
Ausgangsdaten |
|
Standardablauf |
1. TUC_KON_216 „LeseZertifikat“ für:
3. Falls das Zertifikat abgelaufen ist, Systemereignis absetzen:
|
Varianten/ Alternativen |
Keine |
Fehlerfälle |
(1) Zur angegebenen CardSession keine Karte gefunden: Fehlercode 4131. (1) Für eGK, HBA, SM-B gilt: Wenn crypt=ECC und Kartengeneration<G2.1, bricht der TUC mit Warnung 4257 ab. (1) Für gSMC-K gilt: Wenn crypt=ECC und beim Aufruf von TUC_KON_216 wird die Warnung 4256 zurückgegeben, dann wird der TUC nach Schritt 1 beendet und die Warnung 4257 an den Aufrufer zurückgegeben. (2) Extraktion des Ablaufsdatums fehlgeschlagen: Fehlercode 4132. |
Nichtfunktionale Anforderungen |
Keine |
Zugehörige Diagramme |
Keine |
Tabelle 269: TAB_KON_600 Fehlercodes TUC_KON_033 „Zertifikatsablauf prüfen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4131 |
Technical |
Error |
Zum angegebenen CardHandle keine Karte gefunden. |
4132 |
Security |
Error |
Extraktion des Ablaufsdatums fehlgeschlagen |
4257 | Technical | Warning | ECC-Zertifikate nicht vorhanden auf Karte: <cardHandle> |
[<=]
4.1.9.4 Interne TUCs, auch durch Fachmodule nutzbar
4.1.9.4.1 TUC_KON_037 „Zertifikat prüfen"
TIP1-A_4696-03 - TUC_KON_037 „Zertifikat prüfen“
Der Konnektor MUSS den technischen Use Case „Zertifikat prüfen“ gemäß TUC_KON_037 „Zertifikat prüfen“ umsetzen.
Tabelle 270: TAB_KON_769 TUC_KON_037 „Zertifikat prüfen“
Element |
Beschreibung |
---|---|
Name |
TUC_KON_037 „Zertifikat prüfen“ |
Beschreibung |
Der TUC beschreibt
|
Auslöser |
|
Vorbedingungen |
|
Eingangsdaten |
|
Komponenten |
Konnektor |
Ausgangsdaten |
|
Standardablauf |
Als Timeout wird beim Aufruf von TUC_PKI_018 der Wert von CERT_OCSP_TIMEOUT_NONQES bzw. beim Aufruf von TUC_PKI_030 der Wert von CERT_OCSP_TIMEOUT_QES übergeben (siehe auch Eingangsdaten von diesen TUCs in [gemSpec_PKI]).
Für die QES-Zertifikatsprüfung wird das zu prüfende QES-Zertifikat an TUC_PKI_030 „QES-Zertifikatsprüfung“ übergeben.
Wird im Aufruf der Eingangsparameter getOCSPResponses = false mit übergeben, wird keine OCSP-Response an den Aufrufer zurückgegeben.
Wird von TUC_PKI_030 mit dem Result "Valid" die Warnung "PROVIDED_OCSP_RESPONSE_NOT_VALID" zurückgemeldet, so wird die von TUC_PKI_030 zurückgemeldete OCSP-Response unabhängig von getOCSPResponses an den Aufrufer zurückgemeldet.
Als TOLERATE_OCSP_FAILURE wird beim Aufruf von TUC_PKI_018 offlineAllowNoCheck verwendet.
Wenn der Eingangsparameter validationMode („Prüfmodus“) den Wert NONE hat, werden die TUC_PKI_018-Eingangsparameter
|
Varianten/ Alternativen |
|
Fehlerfälle |
TUC_KON_037 im kritischen Betriebszustand EC_TSL_Out_Of_Date_Beyond_Grace_Period aufgerufen: Fehlercode 4002. -> 2a) certificate ist nicht in der TSL enthalten |
Nichtfunktionale Anforderungen |
Der Konnektor MUSS unter Einhaltung aller anderen Anforderungen an die Zertifikatsprüfung die Anzahl der OCSP-Abfragen minimieren. Dies MUSS durch Caching (unter Berücksichtigung der Grace Period) und DARF NICHT durch Bündelung von OCSP-Anfragen geschehen. |
Zugehörige Diagramme |
keine |
Tabelle 271: TAB_KON_601 Fehlercodes TUC_KON_037 „Zertifikat prüfen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases treten folgende Fehlercodes auf. |
|||
4002 |
Security |
Fatal |
Der Konnektor befindet sich in einem kritischen Betriebszustand |
4260 | Security | Error | Zertifikat nicht vorhanden in TSL |
4.1.9.4.2 TUC_KON_042 „CV-Zertifikat prüfen“
TIP1-A_5482-01 - TUC_KON_042 „CV-Zertifikat prüfen“
Der Konnektor MUSS den technischen Use Case „CV-Zertifikat prüfen“ gemäß TUC_KON_042 „CV-Zertifikat prüfen“ umsetzen.
Tabelle 272: TAB_KON_818 TUC_KON_042 „CV-Zertifikat prüfen“
Element |
Beschreibung |
---|---|
Name |
TUC_KON_042 „CV-Zertifikat prüfen“ |
Beschreibung |
Die Gültigkeit eines (EndEntity-)CV-Zertifikats wird geprüft. Es werden folgende Prüfungen durchgeführt: Kryptographische Prüfung der Signaturen des End-Entity-CV-Zertifikats und des CVC-CA-Zertifikats
|
Auslöser |
|
Vorbedingungen |
|
Eingangsdaten |
|
Komponenten |
Konnektor |
Ausgangsdaten |
|
Standardablauf |
1. Prüfung von CV-Zertifikaten der Generation 2: Die CVC-Prüfung setzt sich gemäß GS-A_5009, … GS-A_5012 [gemSpec_PKI#8.8] aus folgenden Schritten zusammen: i. Prüfe die kryptographische Korrektheit der Signatur des CA-Zertifikats caCertificate mit dem öffentlichen Root- Schlüssel der ausstellenden CVC-Root-CA. Der benötigte Root-Key befindet sich im Truststore des Konnektors. ii. Prüfe die kryptographische Korrektheit der Signatur des (EndEntity-)CV-Zertifikats certificate mit dem öffentlichen Schlüssel der ausstellenden CVC-CA (aus dem CVC-CA- Zertifikat extrahiert). iii. Prüfe die zeitliche Gültigkeit des (EndEntity-)CV-Zertifikates, des CVC-CA-Zertifikates und CVC-Root-CA-Zertifikates nach dem Schalenmodell. 2. Der Status status der Prüfung wird zurückgegeben. |
Varianten/Alternativen |
( i) Mathematische Korrektheitsprüfung CV-Zertifikate mit Cross-CV-Zertifikat (vgl. Varianten/Alternativen von TUC_KON_005) |
Fehlerfälle |
( i) das benötigte Cross-CV-Zertifikat ist nicht vorhanden, Fehlercode 4228 ( i) kryptographische (mathematische) Prüfung des CVC-CA-Zertifikats fehlgeschlagen, Fehlercode 4196. ( ii) kryptographische Prüfung des (EndEntity-)CV-Zertifikats fehlgeschlagen, Fehlercode 4196. ( iii) zeitliche Gültigkeit eines der CV-Zertifikate ist abgelaufen, Fehlercode 4196. |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
Tabelle 273: TAB_KON_819 Fehlercodes TUC_KON_042 „CV-Zertifikat prüfen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4196 |
Technical |
Error |
Fehler bei der CV-Zertifikatsprüfung |
4228 |
Technical |
Error |
das benötigte Cross-CV-Zertifikat ist nicht vorhanden |
4.1.9.4.3 TUC_KON_034 „Zertifikatsinformationen extrahieren“
TIP1-A_4697 - TUC_KON_034 „Zertifikatsinformationen extrahieren”
Der Konnektor MUSS den technischen Use Case TUC_KON_034 „Zertifikatsinformationen extrahieren” umsetzen.
Tabelle 274: TAB_KON_770 TUC_KON_034 „Zertifikatsinformationen extrahieren“
Element |
Beschreibung |
Name |
TUC_KON_034 „Zertifikatsinformationen extrahieren“ |
Beschreibung |
Dieser TUC beschreibt die Extraktion der fachlich zentralen Informationen aus bestimmten Zertifikaten einer gesteckten Karte eines Mandanten. |
Auslöser |
|
Vorbedingungen |
Keine |
Eingangsdaten |
|
Komponenten |
Konnektor |
Ausgangsdaten |
|
Nachbedingungen |
Keine |
Standardablauf |
|
Varianten/Alternativen |
Keine |
Fehlerfälle |
(1) Wenn im Aufrufkontext (also erreichbar durch den Mandanten) zum angegebenen CardHandle keine Karte gefunden werden kann, bricht der TUC mit Fehlercode 4146 ab. (1b) Ist bei Angabe von QES=true auf der Karte keine QES-Identität zu finden, bricht der TUC mit Fehlercode 4147 ab. Für die Kombination QES=true mit einer eGK bricht der TUC mit Fehlercode 4148 ab (QES-Zertifikate der eGK werden noch nicht unterstützt). (1) Für eGK, HBA, SM-B gilt: Wenn crypt=ECC und Karte vom Typ <G2.1, bricht der TUC mit Warnung 4257 ab. (1) Für gSMC-K gilt: Wenn crypt=ECC und TUC_KON_216 Warnung 4256 liefert, bricht der TUC mit Warnung 4257 ab. (1) Wenn aus anderen Gründen die Extraktion der Zertifikatsinformationen fehlschlägt, bricht der TUC mit Fehlercode 4148 ab. |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
Tabelle 275: TAB_KON_602 Fehlercodes TUC_KON_034 „Zertifikatsinformationen extrahieren“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4146 |
Technical |
Error |
Kartenhandle existiert nicht |
4147 |
Technical |
Error |
Zertifikat nicht vorhanden (z. B. kein QES-Zertifikat in SM-B) |
4148 |
Technical |
Error |
Fehler beim Extrahieren von Zertifikatsinformationen |
4257 | Technical | Warning | ECC-Zertifikate nicht vorhanden auf Karte: <cardHandle> |
[<=]
4.1.9.5 Operationen an der Außenschnittstelle
TIP1-A_4698-03 - Basisanwendung Zertifikatsdienst
Der Konnektor MUSS Clientsystemen eine Basisanwendung Zertifikatsdienst zur Verfügung stellen
Tabelle 276: TAB_KON_771 Basisanwendung Zertifikatsdienst
Name |
CertificateService |
|
---|---|---|
Version (KDV) |
6.0.0 (WSDL-Version), 6.0.1 (XSD-Version) 6.0.1 (WSDL-Version), 6.0.2 (XSD-Version) |
|
Namensraum |
Siehe GitHub |
|
Namensraum-Kürzel |
CERT für Schema und CERTW für WSDL |
|
Operationen |
Name |
Kurzbeschreibung |
ReadCardCertificate |
Zertifikat von einer Karte lesen |
|
CheckCertificateExpiration |
Ablaufdatum von Zertifikaten erfragen |
|
VerifyCertificate |
Prüfung des Status eines Zertifikats |
|
WSDL |
CertificateService.wsdl (WSDL-Verion 6.0.0) CertificateService_v6_0_1.wsdl |
|
Schema |
CertificateService.xsd (XSD-Version 6.0.1) CertificateService_v6_0_2.xsd |
[<=]
4.1.9.5.1 CheckCertificateExpiration
TIP1-A_4699-04 - Operation CheckCertificateExpiration
Die Basisanwendung Zertifikatsdienst des Konnektors MUSS an der Clientschnittstelle eine Operation CheckCertificateExpiration anbieten.
Tabelle 277: TAB_KON_676 Operation CheckCertificateExpiration
Name |
CheckCertificateExpiration |
|
---|---|---|
Beschreibung |
Gibt das Datum des Ablaufs eines bestimmten Zertifikats oder gesammelt des Zertifikats der gSMC-K, der gSMC-KT's sowie aller gesteckten HBAx und SM-B des Mandanten zurück. |
|
Aufruf-parameter |
||
Name |
Beschreibung |
|
CardHandle |
Optional. Identifiziert die Karte, deren Zertifikate geprüft werden sollen. Wird der Parameter nicht angegeben, so werden alle für den Konnektor erreichbaren Karten (inkl. gSMC-K und aller gSMC-KT's), die zum Mandanten passen, berücksichtigt. Die Operation CheckCertificateExpiration DARF das Lesen von Zertifikaten der eGK NICHT unterstützen. |
|
Context |
MandantId, CsId, WorkplaceId verpflichtend; UserId optional |
|
Crypt | Optional; Default: RSA Gibt den kryptopraphischen Algorithmus vor, für den das Zertifikat ermittelt werden soll. Wertebereich: RSA, ECC
|
|
Rückgabe |
||
Status |
Enthält den Ausführungsstatus der Operation. |
|
CertificateExpiration |
Eine Liste von Tupeln aus (CtID, CardHandle, ICCSN, subject.CommonName, serialNumber, validity) der Zertifikate der Karten. Für die gSMC-K soll in CertificateExpiration/CtID und CertificateExpiration/CardHandle jeweils ein Leerstring zurückgegeben werden. |
|
Vorbe-dingungen |
Keine |
|
Nachbe-dingungen |
Keine |
Tabelle 278: TAB_KON_677 Ablauf CheckCertificateExpiration
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 Zugriffsberechtigung“ |
Die Prüfung erfolgt durch den Aufruf TUC_KON_000 { mandantId = $context.mandantId; clientSystemId = $context.clientsystemId; workplaceId = $context.workplaceId; userId = $context.userId; cardHandle = $cardHandle; allWorkplaces=true, wenn cardHandle nicht angegeben, ansonsten false } Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab. |
3. |
enumerateCardHandles |
Wenn der Parameter CardHandle übergeben wurde, wird dieser als einziges Element in eine Liste gepackt. Wenn der Parameter CardHandle leer war, wird eine Liste der CardHandles aller für den Konnektor erreichbaren Karten (inkl. gSMC-K und gSMC-KT's), die zum Mandanten passen, erstellt. |
Für jedes CardHandle der in Schritt 3 erzeugten Liste werden folgende Schritte ausgeführt, für die gSMC-Ks die Schritte 5 und 6: Falls Schritt 5 der TUC_KON_033 die Warnung 4257 zurückgibt, wird Schritt 6 nicht ausgeführt und die Schritte für das CardHandle der in Schritt 3 erzeugten Liste weiter ausgeführt. Die Warnung 4257 wird über alle CardHandle akkumuliert und <komma-separierte List von cardHandle> für den Fehlertext erzeugt. |
||
4. |
TUC_KON_026 „Liefere CardSession“ |
Ermittle CardSession über TUC_KON_026 { mandatId =MandantId; clientSystemId = ClientSystemId; cardHandle = CardHandle; userId = UserId } |
5. |
TUC_KON_033 „Zertifikatsablauf prüfen“ |
Das Gültigkeitsdatum des Zertifikats wird geprüft mit TUC_KON_033 { cardSession; doInformClients = false; Crypt; } bzw. TUC_KON_033 { checkSMCK = true; doInformClients = false; Crypt; } |
6. |
TUC_KON_034 „Zertifikatsinformationen extrahieren” |
Beim Aufruf des TUC_KON_034 ist der Parameter qes = false zu setzen. Aus den jeweiligen Rückgabewerten entsteht eine Liste aus Tupeln (CtID, CardHandle, ICCSN, subject.CommonName, serialNumber, validity). Diese wird von der Operation zurückgegeben. |
Tabelle 279: TAB_KON_603 Fehlercodes „CheckCertificateExpiration“
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 |
4257 | Technical | Warning | ECC-Zertifikate nicht vorhanden auf Karte: <komma-separierte List von cardHandle> |
4.1.9.5.2 ReadCardCertificate
TIP1-A_4700 - Operation ReadCardCertificate
Die Basisanwendung Zertifikatsdienst des Konnektors MUSS an der Clientschnittstelle eine Operation ReadCardCertificate wie in Tabelle TAB_KON_678 Operation ReadCardCertificate beschrieben anbieten.
Tabelle 280: TAB_KON_678 Operation ReadCardCertificate
Name |
ReadCardCertificate |
||
---|---|---|---|
Beschreibung |
Liest X.509-Zertifikate von einer Karte. |
||
Aufruf-parameter |
|||
Name |
Beschreibung |
||
CardHandle |
Gibt die Karte an, von der das Zertifikat gelesen werden soll. Es können Zertifikate von HBAx (HBA, HBA-VK), SM-B ausgelesen werden. Die Operation ReadCardCertificate DARF das Lesen von Zertifikaten der eGK NICHT unterstützen. |
||
Context |
Aufrufkontext (Mandant) |
||
CertRefList |
Gibt an, welche(s) Zertifikat(e) gelesen werden soll. Mögliche Werte für CertRef sind: C.AUT, C.ENC, C.SIG, C.QES |
||
Crypt | Optional; Default: RSA Gibt den kryptographischen Algorithmus vor, für den das Zertifikat ermittelt werden soll. Wertebereich: RSA, ECC
|
||
Rückgabe |
|||
Status |
Enthält den Ausführungsstatus der Operation. |
||
CertRef |
Dieses Element beinhaltet die Referenz des Zertifikats, welches bei der Anfrage übergeben wurde. |
||
X509Data |
Inhalt des über die CertRef referenzierten Zertifikats. Ist das referenzierte Zertifikat nicht vorhanden, so wird dieses Element nicht vom Konnektor gefüllt. |
||
X509Issuer Name |
Enthält den Issuer-Name des Zertifikats. Bezüglich des Encodings sind die in [XMLDSig#4.4.4.4.1] angegebenen Regeln zu beachten (Escaping von Sonderzeichen etc.) |
||
X509Serial Number |
Enthält die serialNumber des Zertifikats. |
||
X509Subject Name |
Enthält das Feld subject.CommonName. Bezüglich des Encodings sind die in [XML DSig#4.4.4.4.1] angegebenen Regeln zu beachten (Escaping von Sonderzeichen etc.) |
||
X509 Certificate |
Enthält das base64-codierte Zertifikat, dessen Binärstruktur wiederum ASN.1-codiert (gemäß [COMMON_PKI]) vorliegt. |
||
Vorbe-dingungen |
Keine |
||
Nachbe-dingungen |
Keine |
Tabelle 281: TAB_KON_679 Ablauf ReadCardCertificate
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. Wurde als Zielkarte eine eGK adressiert, wird Fehlercode 4090 zurückgeliefert. |
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; userId = $context.userId; cardHandle = $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; cardHandle = $context.cardHandle; userId = $context.userId } |
4. |
getEF |
Für jedes Paar von CertRef und CardHandle wird in Abhängigkeit des Parameters Crypt gemäß Tabelle TAB_KON_858 das zu lesende File (EF) bestimmt: Ist die übergebene Zertifikatsreferenz ungültig, wird Fehlercode 4149 zurückgegeben. Das Lesen von Zertifikaten der eGK ist aus Sicherheitsgründen für Clientsysteme nicht zulässig. |
TUC_KON_216 „LeseZertifikat“ |
Für jedes Paar von CardHandle und EF wird nun durch Aufruf von TUC_KON_216 „LeseZertifikat“ das Zertifikat ausgelesen. Falls TUC_KON_216 die Warnung 4256 zurückgibt, wird die Operation abgebrochen und Fehler 4258 zurückgegeben. |
|
6. |
Zertifikatsattribute extrahieren |
Aus jedem Zertifikat werden die zu liefernden Attribute extrahiert. Die Ergebnisstruktur wird mit den erhaltenen Rückgabewerten gefüllt. |
Tabelle 282: TAB_KON_604 Fehlercodes „ReadCardCertificate“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4000 |
Technical |
Error |
Syntaxfehler |
4149 |
Technical |
Error |
Ungültige Zertifikatsreferenz |
4090 |
Security |
Error |
Zugriff auf eGK nicht gestattet |
4258 | Technical | Error | ECC-Zertifikate nicht vorhanden auf Karte: <cardHandle> |
[<=]
4.1.9.5.3 VerifyCertificate
TIP1-A_5449 - Operation VerifyCertificate
Die Basisanwendung Zertifikatsdienst des Konnektors MUSS an der Clientschnittstelle eine Operation VerifyCertificate wie in Tabelle TAB_KON_795 Operation VerifyCertificate beschrieben anbieten.
Tabelle 283: TAB_KON_795 Operation VerifyCertificate
Name |
VerifyCertificate |
||
---|---|---|---|
Beschreibung |
Prüft den Status eines Zertifikats. |
||
Aufruf-parameter |
|||
Name |
Beschreibung |
||
CCTX:Context |
Aufrufkontext (Mandant) |
||
CERTCMN: |
Zu prüfendes Zertifikat (base64 kodiert), wie in Response zur Operation ReadCardCertificate enthalten. |
||
CERT: |
Der für die Prüfung zu verwendende Referenzzeitpunkt. Falls der Parameter nicht angegeben ist, wird als Referenzzeitpunkt die Systemzeit verwendet. |
||
Rückgabe |
|||
CONN:Status |
Enthält den Ausführungsstatus der Operation. |
||
CERT: |
Enthält eines der drei möglichen Prüfungsergebnisse in CERT:VerificationResult
sowie weiter Details zu den Zuständen „INCONCLUSIVE“ und „INVALID“ in GERROR:Error. |
||
CERT:RoleList |
OIDs der im Zertifikat gespeicherten Rollen. |
||
Vorbe-dingungen |
Keine |
||
Nachbe-dingungen |
Keine |
Der Ablauf der Operation VerifyCertificate ist in Tabelle TAB_KON_797 Ablauf VerifyCertificate beschrieben:
Tabelle 284: TAB_KON_797 Ablauf VerifyCertificate
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_037 „Zertifikat prüfen“ |
Die Zertifikatsprüfung erfolgt durch Aufruf von TUC_KON_037. Als Parameter des TUC-Aufrufs gilt für Zertifikate aus CERT_IMPORTED_CA_LIST: { |
3. |
Wenn der Prüfprozess fehlerhaft war und nicht zu einem Ergebnis im Sinne eines VerificationResult führt, wird eine FaultMessage erzeugt. |
Tabelle 285: TAB_KON_800 Fehlercodes „VerifyCertificate“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4000 |
Technical |
Error |
Syntaxfehler |
4.1.9.6 Betriebsaspekte
4.1.9.6.1 TUC_KON_035 „Zertifikatsdienst initialisieren“
TIP1-A_4701 - TUC_KON_035 „Zertifikatsdienst initialisieren“
In der Bootup-Phase MUSS der Konnektor den Zertifikatsdienst durch Aufruf des TUC_KON_035 „Zertifikatsdienst initialisieren“ initialisieren.
Tabelle 286: TAB_KON_772 TUC_KON_035 „Zertifikatsdienst initialisieren“
Element |
Beschreibung |
Name |
TUC_KON_035 „Zertifikatsdienst initialisieren“ |
Beschreibung |
Der TUC beschreibt den gesamten Ablauf der Initialisierung des TrustStore im Rahmen der betrieblichen Prozesse: Prüfung der Aktualität, Integrität und Authentizität der Einträge im TrustStore. |
Auslöser |
|
Vorbedingungen |
keine |
Eingangsdaten |
keine |
Komponenten |
Konnektor |
Ausgangsdaten |
|
Nachbedingungen |
Keine |
Standardablauf |
Für den übergebenen Status der Initialisierung des TrustStore werden folgende Schritte durchgeführt:
|
Varianten/ Alternativen |
Keine |
Fehlerfälle |
Keine |
Nichtfunktionale Anforderungen |
Keine |
Zugehörige Diagramme |
Keine |
Tabelle 287: TAB_KON_605 Fehlercodes TUC_KON_035 „Zertifikatsdienst initialisieren“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können keine weiteren Fehlercodes auftreten. |
[<=]
TIP1-A_4702-04 - Konfigurierbarkeit des Zertifikatsdienstes
Der Administrator MUSS die in TAB_KON_606 aufgelisteten Parameter über die Managementschnittstelle konfigurieren und die in TAB_KON_733 aufgelisteten Parameter ausschließlich einsehen können.
Tabelle 288: TAB_KON_606 Konfiguration des Zertifikatsdienstes
ReferenzID |
Belegung |
Bedeutung |
---|---|---|
CERT_TSL_DEFAULT_ GRACE_PERIOD_DAYS |
X Tage |
Default Grace Period TSL in Tagen Gibt an, wie viele Tage der Konnektor mit einer zeitlich abgelaufenen TSL weiter betrieben werden kann. Der Wert MUSS zwischen 1 und 30 Tagen liegen. Default-Wert = 30 Tage Hinweis: Vor dem zeitlichen Ablauf einer TSL wird mit ausreichendem Vorlauf eine neue TSL verteilt. Sollte die TSL dennoch ablaufen und der Konfigurationswert überschritten werden, kann eine neue TSL immer noch lokal geladen werden (TIP1-A_4705 „TSL manuell importieren“). |
CERT_OCSP_DEFAULT_ GRACE_PERIOD_ NONQES |
X Minuten |
Default Grace Period OCSP für nonQES in Minuten. Der Wert MUSS zwischen 0 und 20 Minuten liegen. Default-Wert = 10 Minuten |
CERT_OCSP_TIMEOUT_ NONQES |
X Sekunden |
Timeout für OCSP-Abfragen bei der Prüfung von nonQES-Zertifikaten. Der Wert MUSS zwischen 1 und 120 Sekunden liegen. Default-Wert = 10 Sekunden |
CERT_OCSP_TIMEOUT_ QES |
X Sekunden |
Timeout für OCSP-Abfragen bei der Prüfung von QES-Zertifikaten. Der Wert muss zwischen 1 und 120 Sekunden liegen. Default-Wert = 10 Sekunden |
CERT_EXPIRATION_ WARN_DAYS |
X Tag(e) |
Warnung X Tage vor Ablauf von Zertifikaten im Managementinterface und per Ereignis. Der Wert muss zwischen 0 und 180 Tagen (0=keine Warnung) liegen. Default-Wert = 90 Tage |
CERT_EXPIRATION_ CARD_CHECK_DAYS |
X Tag(e) |
Alle X Tage wird der Ablauf aller gesteckten Karten überprüft. Der Wert muss zwischen 0 und 365 liegen (0=kein Check). Default-Wert = 1 Tag |
CERT_IMPORTED_ CA_LIST |
Liste von manuell importierten CA-Zertifikaten |
Der Administrator MUSS CA-Zertifikate importieren, anzeigen und löschen können. Der Konnektor DARF CA-Zertifikate zur Ableitung von QES-Zertifikaten NICHT importieren. Default-Wert = leere Liste |
CERT_BNETZA_VL_ UPDATE_INTERVAL |
X Stunden |
Intervall, in dem die BNetzA VL auf Aktualität geprüft werden muss. Der Wert MUSS zwischen 1 Stunde und 168 Stunden (7 Tage) liegen. Default-Wert = 24 Stunden |
CERT_TSL_DOWNLOAD_ADDRESS_INTERNET_BU | 1 URI | Konfigurierbare Backup Adresse der TSL im Internet |
CERT_TSL_IP_ADDRESS_INTERNET_BU | 1 URI |
Konfigurierbare Backup Adresse der TSL im Internet (enthält IP-Adresse des Hosts statt FQDN). Wird verwendet, falls Auflösen der FQDN mittels DNS bei CERT_TSL_DOWNLOAD_ADDRESS_INTERNET_BU fehlschlägt. |
Tabelle 289: TAB_KON_733 Einsehbare Konfigurationsparameter des Zertifikatsdienstes
ReferenzID |
Belegung |
Bedeutung |
---|---|---|
CERT_CRL_DOWNLOAD_ADDRESS |
2 URIs |
Download-Adressen für die CRL |
CERT_OCSP_FORWARDER_ADDRESS |
2 FQDNs |
Adressen der OCSP-Forwarder (HTTPS-Proxy) beim Zugangsdienstprovider Der Administrator muss in geeigneter Weise einen Test auslösen können, ob einer der Server per ICMP-Echo (ping) erreichbar ist und ob ein (beliebiger) OCSP-Request zu einer erhaltenen OCSP-Antwort führt. |
CERT_OCSP_FORWARDER_PORT |
TCP-Port |
TCP-Port des OCSP-Forwarders (HTTPS-Proxy) beim Zugangsdienstprovider |
CERT_TSL_DOWNLOAD_ADDRESS_INTERNET | 1 URI | Adresse der TSL im Internet gemäß gemSpec_TSL |
CERT_TSL_IP_ADDRESS_INTERNET | 1 URI |
Adresse der TSL im Internet gemäß gemSpec_TSL (enthält IP-Adresse des Hosts statt FQDN). Wird verwendet, falls Auflösen der FQDN mittels DNS bei CERT_TSL_DOWNLOAD_ADDRESS_INTERNET fehlschlägt. |
[<=]
TIP1-A_4703-02 - Vertrauensraumstatus anzeigen
Das Managementinterface des Konnektors MUSS einem authentisierten Administrator die Anzeige des Status des Vertrauensraums in Form folgender Daten anbieten:
- (zur TSL) Sequenznummer der aktuellen TSL, StatusStartingTime (des TSPService (TSL-Signer-CA-Dienst) zum aktuell gültigen, aktiven TI-Vertrauensanker), NextUpdate, Gültigkeit der TSL, Typ der TSL (RSA oder ECC-RSA))
- für den aktiven TI-Vertrauensanker den Namen und die Gültigkeit ("notAfter") des TSL-Signer-CA-Zertifikats
- sowie optional für den Administrator einsehbar der Fingerprint des TSL-Signer-Zertifikats.
Der Typ der TSL liefert dem Administrator die Information, ob es sich um eine TSL handelt, die den TI-Vertrauensraum ausschließlich für Zertifikate mit kryptographischen Verfahren nach RSA-2048 (TSL(RSA)) oder für Zertifikate mit kryptographischen Verfahren nach RSA-2048 und ECC-256 (TSL(ECC-RSA)) bereitstellt. Die Information kann aus der Signatur der TSL ermittelt werden.
TIP1-A_6733 - Aktive BNetzA-VL anzeigen
Das Managementinterface des Konnektors MUSS einem authentisierten Administrator die Anzeige des Status der BNetzA-VL in Form folgender Daten anbieten: Sequenznummer, NextUpdate, Gültigkeitsstatus und Zeitpunkt der letzten Prüfung der Aktualität durch TUC_KON_031.
[<=]
TIP1-A_4704 - Zertifikatsablauf anzeigen
Der Administrator MUSS einen Prüflauf auf den innerhalb von CERT_EXPIRATION_WARN_DAYS Tagen bevorstehenden Ablauf von Zertifikaten aller für den Konnektor erreichbaren Karten (inkl. gSMC-K) an zentraler Stelle in der Managementschnittstelle auslösen können und das Ergebnis angezeigt bekommen.
Der Konnektor MUSS die Gültigkeitsdauer der Zertifikate aller gesteckten Karten (inkl. gSMC-K) prüfen mittels Aufruf von:
für gSMC-K
TUC_KON_033{checkSMCK; doInformClients=Nein; crypt = ECC}
TUC_KON_033{checkSMCK; doInformClients=Nein; crypt = RSA}
für jede gesteckte G2.0 Karte außer gSMC-K
TUC_KON_033{cardSession; doInformClients=Nein; crypt = RSA}
für jede gesteckte ab G2.1 Karte außer gSMC-K
TUC_KON_033{cardSession; doInformClients=Nein; crypt = ECC}
TUC_KON_033{cardSession; doInformClients=Nein; crypt = RSA} [<=]
A_18931 - Anzeige Personalisierungs-Status gSMC-K-X.509-Zertifikate
Der Konnektor MUSS dem Administrator die X.509-Zertifikate der verbauten gSMC-Ks gemäß TIP1-A_4506 anzeigen. Aus der Anzeige MUSS der Personalisierungs-Status der X.509-Zertifikate ersichtlich sein (dual RSA- und ECC-personalisiert oder nur RSA-personalisiert).
[<=]
TIP1-A_4705 - TSL manuell importieren
Der Konnektor MUSS den manuellen Import einer TSL auch ermöglichen, wenn er sich im kritischen Betriebszustand EC_TSL_Out_Of_Date_Beyond_Grace_Period befindet.
Der Konnektor MUSS den manuellen Import einer zeitlich abgelaufenen TSL zulassen.
Auch im Fall des automatischen Imports der TSL muss dies im kritischen Betriebszustand EC_TSL_Out_Of_Date_Beyond_Grace_Period unterstützt werden.
A_20536 - TSL im kritischen Betriebszustand
Der Konnektor MUSS den automatischen Import einer TSL auch ermöglichen, wenn er sich im kritischen Betriebszustand EC_TSL_Out_Of_Date_Beyond_Grace_Period befindet. [<=]
A_20748 - Automatischer TSL Download im kritischen Zustand
Falls der Konnektor im kritischen Betriebszustand EC_TSL_Out_Of_Date_Beyond_Grace_Period ist, und falls onlineMode = ENABLED ist, MUSS der Konnektor periodisch und in der BootUp Phase die TSL aktualisieren. [<=]
TIP1-A_6728 - BNetzA-VL manuell importieren
Der Konnektor MUSS es dem Administrator ermöglichen, die BNetzA-VL manuell von lokaler Datenquelle einzuspielen. Dabei MUSS der Konnektor TUC_KON_031{BNetzA-VL-Datei} mit der manuell importierten BNetzA-VL-Datei aufrufen.
[<=]
TIP1-A_4706 - CRL manuell importieren
Der Konnektor SOLL es dem Administrator ermöglichen, eine CRL manuell von einer lokalen Datenquelle einzuspielen. In dem Fall MUSS der Konnektor TUC_KON_040{CRL-Datei} mit der manuell importierten CRL aufrufen. [<=]
Für die ECC-Migration ist es notwendig den ECC-RSA-Vertrauensraum zu etablieren. Dies erfolgt durch das Einspielen eines TSL-Signer-CA Cross-Zertifikats und das neue TSL-Signer-CA-Zertifikat, wodurch der ECC-Vertrauensanker im Konnektor im sicheren Datenspeicher gespeichert wird. Die Prüfung des Cross-Zertifikats erfolgt durch A_17821 - Wechsel des Vertrauensraumes mittels Cross-Zertifikaten (ECC-Migration). Danach kann die TSL(ECC-RSA) importiert werden. Das Ergebnis ist ein etablierter TI-Vertrauensraum für ECC und RSA.
Konnektoren müssen den ECC-Vertrauensraum automatisiert und im Rahmen des Upgrades auf PTV4 etablieren. Manuelle Schritte durch den Administrator sind für den Regelfall zu vermeiden und sollten nur im Fehlerfall nötig werden. Als Fallback-Lösung muss das manuelle Verfahren dennoch unterstützt werden.
A_20469-02 - Automatisierte Etablierung des ECC-RSA-Vertrauensraums (ECC-Migration)
In der BootUp-Phase MUSS ein Konnektor, der den RSA-Vertrauensraum (RSA) verwendet, überprüfen, ob die TSL(ECC-RSA) und die entsprechenden TSL-Signer-CA Cross-Zertifikate sowie TSL-Signer-CA-Zertifikate verfügbar sind und MUSS sie im positiven Fall automatisiert herunterladen, nach erfolgreicher Prüfung verwenden und dadurch den ECC-Vertrauensraum (ECC-RSA) etablieren.
Der Konnektor MUSS hierzu die Downloadpunkte, die mit A_17680-01 in [gemSpec_TSL#6.3.1.2] definiert sind, verwenden.
Falls beim Wechsel auf den ECC-RSA Vertrauensraum ein Fehler auftritt, MUSS der Konnektor weiterhin den RSA-Vertrauensraum (RSA) verwenden. [<=]
A_20508-01 - Protokollierung der Etablierung des ECC-RSA-Vertrauensraums (ECC-Migration)
Der Konnektor MUSS alle Schritte, die er zur Etablierung des ECC-RSA-Vertrauensraums durchläuft, im Systemprotokoll des Konnektors mit dem Log-Level "Warning" protokollieren. [<=]
A_17345 - TSL-Signer-CA Cross-Zertifikat manuell importieren (ECC-Migration)
Der Konnektor MUSS es dem Administrator ermöglichen, ein TSL-Signer-CA Cross-Zertifikat und das TSL-Signer-CA-Zertifikat für den neuen TI-Vertrauensanker manuell von lokaler Datenquelle einzuspielen. [<=]
A_17837-01 - Nutzung von Cross-Zertifikaten für Vertrauensraum-Wechsel nach ECC-RSA (ECC-Migration)
Um auf Basis des bereits etablierten Vertrauensankers (RSA) in den Vertrauensraum (ECC-RSA) zu wechseln MUSS der Konnektor bei der Initialisierung des neuen Vertrauensankers (ECC-RSA) Cross-Zertifikate verwenden. Das Ergebnis ist ein neuer etablierter TI-Vertrauensanker (ECC-RSA). [<=]
A_17548-01 - TSL-Signer-CA Zertifikat sicher speichern (ECC-Migration)
Der Konnektor MUSS den neuen TI-Vertrauensanker im sicheren Datenspeicher speichern. [<=]
A_17549-01 - TSL-Signer-CA Cross-Zertifikat im kritischen Betriebszustand (ECC-Migration)
Der Konnektor MUSS den Import des TSL-Signer-CA Cross-Zertifikats auch ermöglichen, wenn er sich im kritischen Betriebszustand EC_TSL_Out_Of_Date_Beyond_Grace_Period befindet. [<=]
A_17550-01 - TSL-Signer-CA Cross-Zertifikat importieren - Fehler (ECC-Migration)
Falls der Import des TSL-Signer-CA Cross-Zertifikats nicht erfolgreich durchgeführt werden konnte, MUSS der Konnektor den Vorgang abbrechen und einen Fehler gemäß TAB_KON_857 dem Administrator zur Anzeige bringen und protokollieren.
Tabelle 290: TAB_KON_857 - Fehlercodes beim Import des Cross-Zertifikats für TI-Vertrauensanker ECC
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
4255 |
Security |
Error |
Fehler beim Import des TSL-Signer-CA Cross-Zertifikats |
TIP1-A_5700 - Ereignisbasiert http-Forwarder Adressen ermitteln
Beim Auftreten des Events NETWORK/VPN_TI/UP MUSS der Konnektor über DNS die Adressen des http-Forwarders des VPN-Zugangsdienststandortes ermitteln (SRV-RR mit Bezeichner "_ocsp._tcp.<DOMAIN_SRVZONE_TI>).
[<=]
A_21158 - Mindestanzahl von CV-Crosszertifikaten
Der Konnektor MUSS mindestens 20 CV-Crosszertifikate verwalten und verarbeiten können. [<=]
4.1.10 Protokollierungsdienst
Der Protokollierungsdienst protokolliert system- und sicherheitsrelevante Ereignisse, sowie Ereignisse im Kontext der Performancemessung (siehe [gemSpec_Perf#4.1.2), innerhalb des Konnektors. Auch Ereignisse von Fachmodulen können protokolliert werden. Im Sicherheitsprotokoll werden alle Ereignisse eingetragen, die Auswirkungen auf Sicherheitsmerkmale des Konnektors haben können (Änderungen an der Firewall-Konfiguration, Authentisierungsfehler etc.). Ereignisse im Kontext der Performancemessung innerhalb des Konnektors werden in das Konnektor-Performanceprotokoll geschrieben. Ereignisse im Kontext der Performancemessung von Fachmodulen werden in das Fachmodul-Performanceprotokoll geschrieben. Alle anderen Ereignisse werden in das Systemprotokoll oder die Fachmodulprotokolle geschrieben (grundsätzlich trifft die Entscheidung über den zu verwendenden Protokollspeicher der Aufrufer des Protokolldienstes).
Die Protokolle werden persistiert.
Hinweis:
Ereignisse im Protokollierungsdienst adressieren nicht nur zu protokollierende Events im Sinne des Systeminformationsdienstes sondern alles, was zu einem Protokolleintrag führen soll (z.B. Fehler, Informationen zu Ablauf, Debug, Performance).
Innerhalb des Protokollierungsdienstes werden folgende Präfixe für Bezeichner verwendet:
- Events (Topic Ebene 1): „LOG“
- Konfigurationsparameter: „LOG_“
4.1.10.1 Funktionsmerkmalweite Aspekte
TIP1-A_4708 - Protokollierungsfunktion
Der Konnektor MUSS einen Protokollierungsdienst anbieten. Dabei MUSS der Konnektor zwischen System- und Sicherheitsprotokoll, sowie Fachmodulprotokollen unterscheiden. Je Fachmodul MUSS ein getrenntes Protokoll vorhanden sein.
Die Protokolleinträge MÜSSEN durch den Konnektor lokal persistiert werden.
[<=]TIP1-A_5654 - Sicherheits-Protokollierung
Der Konnektor MUSS herstellerspezifische Fehler, die Auswirkungen auf Sicherheitsmerkmale des Konnektors haben, in das Sicherheitsprotokoll schreiben.
[<=]TIP1-A_4709 - Integrität des Sicherheitsprotokolls
Der Konnektor MUSS sicherstellen, dass Einträge in das Sicherheitsprotokoll nicht von außen und nicht durch den Administrator verändert und gelöscht werden können.
[<=]TIP1-A_4710-02 - Keine Protokollierung personenbezogener und medizinischer Daten
Der Konnektor DARF sowohl medizinische als auch personenbezogene Daten NICHT in die Protokolldateien schreiben.
Unter anderem der Versichertenanteil der KVNR und der ICCSN sowie der CardHolderName und Zertifikatsseriennummern MÜSSEN als personenbezogene Daten behandelt werden.
Daten der Gerätekarten gSMC-K und gSMC-KT müssen nicht als personenbezogene Daten gewertet werden.
[<=]
TIP1-A_6479 - Keine Protokollierung vertraulicher Daten
Der Konnektor DARF vertrauliche Daten NICHT in die Protokolldateien schreiben.
[<=]TIP1-A_4711 - Kapazität der Protokolldateien
Der Konnektor MUSS über eine Speichergröße für Protokolldateien verfügen, so dass Einträge (protokollierte Ereignisse ab der Schwere „Warning“) über einen Zeitraum von bis zu einem Jahr darin vorgehalten werden können.
[<=]Da sich die Menge an Einträgen nach der Größe der Einsatzumgebung richtet, ist die Speichergröße nach den in [gemSpec_Perf#3.1.1] beschriebenen Einsatzumgebungen (LE-Ux, x=1,2,3,4) ausreichend zu wählen.
TIP1-A_4712 - Protokollierung erfolgreicher Kryptooperationen
Wenn LOG_SUCCESSFUL_CRYPTO_OPS = Enabled MUSS der Konnektor die folgenden erfolgreich durchlaufenen Außenoperationen protokollieren:
- SignDocument,
- VerifyDocument,
- ExternalAuthenticate,
- EncryptDocument,
- DecryptDocument.
Dazu MUSS er
TUC_KON_256 {
topic = „LOG/CRYPTO_OP“;
eventType = Sec;
severity = Info;
parameters = („Operation=$Operationsname,
<für alle betroffenen Schlüssel:>
Karte=$ICCSN,
Keyref=<Referenz auf den Schlüssel>,
CARD_HANDLE=$CardHandle,
CardHolderName=$CardHolderName“);
doDisp = false}
aufrufen.
[<=]
TIP1-A_4713 - Herstellerspezifische Systemprotokollierung
Wenn LOG_LEVEL_SYSLOG = Info MUSS der Konnektor herstellerspezifische Informationen über den laufenden Betrieb in das Systemprotokoll eintragen, um im Bedarfsfall das Verhalten des Konnektors analysieren zu können (Unterstützung der Fehlersuche etc.).
Die Häufigkeit und der Inhalt der protokollierten Informationen sind herstellerspezifisch.
[<=]TIP1-A_4714 - Art der Protokollierung
Der Konnektor MUSS Protokolleinträge so anlegen, dass eine Analyse der Einträge unterstützt wird:
- Die Protokolleinträge MÜSSEN eine patternbasierte Filterung unterstützen. Protokollwert/-texte sowie Attribute MÜSSEN in ihren Namensstrukturen hierauf abgestimmt sein.
- „;“ MUSS als Trennzeichen zwischen Key/Value-Paaren verwendet werden.
- „=“ MUSS als Trennzeichen zwischen Key und Value in einem Key/Value-Paar verwendet werden.
- Es MUSS durchgängig dasselbe Zeitstempelformat verwendet werden, entweder
„timestamp=%d{dd.MM.yyyy HH:mm:ss.SSS}“ (Beispiel „30.08.2017 13:44:12.436“) und als Wert die gesetzliche Zeit (§4 EinhZeitG)
oder
„timestamp=%d{dd.MM.yyyy HH:mm:ss.SSSZ}“, wobei „Z“ die Zeitzonenangabe nach RFC 822 mit ("+" / "-") 4DIGIT bezeichnet (Beispiel „30.08.2017 13:44:12.436+0200“).
4.1.10.2 Durch Ereignisse ausgelöste Reaktionen
Keine.
4.1.10.3 Interne TUCs, nicht durch Fachmodule nutzbar
Keine.
4.1.10.4 Interne TUCs, auch durch Fachmodule nutzbar
4.1.10.4.1 TUC_KON_271 „Schreibe Protokolleintrag“
TIP1-A_4715 - TUC_KON_271 „Schreibe Protokolleintrag”
Der Konnektor MUSS den technischen Use Case TUC_KON_271 „Schreibe Protokolleintrag” umsetzen.
Tabelle 291: TAB_KON_607 – TUC_KON_271 „Schreibe Protokolleintrag“
Element |
Beschreibung |
Name |
TUC_KON_271 „Schreibe Protokolleintrag“ |
Beschreibung |
Dieser TUC schreibt einen Eintrag in ein Protokoll. |
Auslöser |
Aufruf durch Basisdienst, Fachmodul oder TUC_KON_256 „Systemereignis absetzen“ |
Vorbedingungen |
Im Fall eines zu protokollierenden Ereignisses des Systeminformationsdienstes wird
|
Eingangs anforderung |
Keine |
Eingangsdaten |
|
Komponenten |
Konnektor |
Ausgangsdaten |
Keine |
Nachbedingungen |
|
Standardablauf |
1. Wenn eventType = Sec, so wird das Ereignis in das Sicherheitsprotokoll geschrieben. Falls fmName angegeben ist, wird er dem Eintrag hinzugefügt. 2. fmName ist angegeben (durch ein Fachmodul aufgerufen) und eventType = „Op“, so wird das Ereignis in das zugehörige Fachmodulprotokoll geschrieben. a. Gemäß den Festlegungen in den jeweiligen Fachmodulspezifikationen (FM_<fmName>_LOG_LEVEL), werden nur Ereignisse in das Fachmodulprotokoll geschrieben, deren severity mindestens dem jeweils dort festgelegten Wert entsprechen. 3. fmName ist nicht angegeben (Aufruf durch ein Fachmodul) und eventType = „Op“, dann wird das Ereignis in das Systemprotokoll geschrieben. a. Gemäß den Festlegungen in LOG_LEVEL_SYSLOG werden nur Ereignisse in das Systemprotokoll geschrieben, deren Schwere mindestens dem Wert von LOG_LEVEL_SYSLOG entsprechen. 4. Wurde der TUC durch ein Fachmodul aufgerufen (fmName ist angegeben) und ist eventType = Perf, so wird das Ereignis in das zugehörige Fachmodul-Performanceprotokoll geschrieben. 5. Wurde der TUC nicht durch ein Fachmodul aufgerufen (fmName ist nicht angegeben) und ist eventType = Perf, so wird das Ereignis in das Konnektor-Performanceprotokoll geschrieben. Die geschriebenen Protokolleinträge MÜSSEN mindestens folgende Attribute beinhalten:
Übersteigt die Anzahl der Einträge im Sicherheitsprotokoll SECURITY_LOG_SIZE, so werden ältere Einträge überschrieben. Für die anderen Protokolle beginnt das Überschreiben, wenn der jeweilige Speicherplatz für das Protokoll erschöpft ist. Dabei werden die nach der Reihenfolge der Erstellung ältesten Einträge überschrieben, unabhängig vom Zeitstempel des Logeintrags. Ist der Zeitstempel eines überschriebenen Logeintrags jünger als LOG_DAYS bzw. FM_<fmName>_LOG_DAYS bzw. SECURITY_LOG_DAYS, so wird der Fehlerzustand EC_LOG_OVERFLOW ausgelöst. |
Fehlerfälle |
Fehler in den folgenden Schritten des Standardablaufs führen zu: a) Aufruf von TUC_KON_256 { topic = „LOG/ERROR“; eventType = $ErrorType; severity = $Severity; parameters = („Error=$Fehlercode, Bedeutung=$Fehlertext“); doLog = false } b) Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes (1) In das Sicherheitsprotokoll kann nicht geschrieben werden: Fehlercode: 4152 (2) In das Fachmodulprotokoll kann nicht geschrieben werden: Fehlercode: 4151 (3) In das Systemprotokoll kann nicht geschrieben werden: Fehlercode: 4150 (4) In das Fachmodul-Performanceprotokoll kann nicht geschrieben werden: Fehlercode: 4217 (5) In das Konnektor-Performanceprotokoll kann nicht geschrieben werden: Fehlercode: 4216 |
Nichtfunktionale Anforderungen |
Keine |
Zugehörige Diagramme |
Keine |
Tabelle 292: TAB_KON_608 Fehlercodes TUC_KON_271 „Schreibe Protokolleintrag“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4150 |
Technical |
Fatal |
Fehler beim Schreiben des Systemprotokolls |
4151 |
Technical |
Fatal |
Fehler beim Schreiben eines Fachmodulprotokolls |
4152 |
Security |
Error |
Fehler beim Schreiben des Sicherheitsprotokolls |
4216 |
Technical |
Fatal |
Fehler beim Schreiben des Konnektor-Performanceprotokolls |
4217 |
Technical |
Fatal |
Fehler beim Schreiben eines Fachmodul-Performanceprotokolls |
[<=]
Die Darstellung PIC_KON_118 veranschaulicht den Aufbau der Protokolle für Plattform und Fachmodule und die Steuerung der Protokolleinträge in TUC_KON_271 „Schreibe Protokolleintrag“.
Abbildung 20: PIC_KON_118 Aufbau und Struktur der Protokolldateien für Plattform und Fachmodule
4.1.10.5 Operationen an der Außenschnittstelle
Keine
4.1.10.6 Betriebsaspekte
TIP1-A_4716 - Einsichtnahme und Veränderung der Protokolle
Der Administrator MUSS die durch den Protokollierungsdienst geschriebenen Protokolle über die Managementschnittstelle einsehen können.
Eine Veränderung des Sicherheitsprotokolls DARF für den Administrator NICHT möglich sein.
Das Löschen folgender Protokolle MUSS für den Administrator möglich sein:
Systemprotokoll
das jeweils durch <fmName> spezifizierte Fachmodulprotokoll
Konnektor-Performanceprotokoll
das jeweils durch <fmName> spezifizierte Fachmodul-Performanceprotokoll
Der Konnektor MUSS den Export von Protokolleinträgen oder ganzen Protokolldateien unterstützen.
Der Konnektor SOLL das Sortieren und Filtern der Protokolleinträge sowie das Suchen in den Protokolleinträgen unterstützen.
[<=]TIP1-A_4996 - Hinweis auf neue Sicherheitsprotokolleinträge
Nachdem sich der Administrator an der Managementschnittstelle angemeldet hat, MUSS der Konnektor ihn automatisch auf Sicherheitsprotokolleinträge hinweisen, die seit dem Ausloggen dieses Administrator aufgelaufen sind.
[<=]TIP1-A_4717 - Konfigurationswerte des Protokollierungsdienstes
Die Managementschnittstelle MUSS es einem Administrator ermöglichen Konfigurationsänderungen gemäß Tabelle TAB_KON_609 vorzunehmen:
Tabelle 293: TAB_KON_609 Konfigurationswerte des Protokollierungsdienstes (Administrator)
ReferenzID |
Belegung |
Bedeutung und Administrator-Interaktion |
---|---|---|
LOG_LEVEL_ SYSLOG |
Info, Warning, Error, Fatal |
Der Administrator MUSS den Detaillierungsgrad des Systemprotokolls durch Festlegung der Mindest-Schwere zu protokollierender Einträge festlegen können. Default-Wert: Warning |
FM_<fmName>_ LOG_LEVEL |
Debug, Info, Warning, Error, Fatal |
Der Administrator MUSS den Detaillierungsgrad des Fachmodulprotokolls durch Festlegung der Mindest-Schwere zu protokollierender Einträge festlegen können. Default-Wert: Warning |
SECURITY_LOG_SIZE | X Einträge | Der Administrator MUSS die Größe des Sicherheitsprotokolls angeben können (Anzahl der Einträge im Ringbuffer). Mindestgröße: >= 10.000 Maximalgröße: herstellerspezifisch Default-Wert: >= 50.000 |
SECURITY_LOG_DAYS | X Tage | Der Administrator MUSS die erwartete Anzahl der im Sicherheitsprotokoll gespeicherten Tage im Bereich 10 bis 365 konfigurieren können. Default-Wert: 180 |
LOG_DAYS |
X Tage |
Der Administrator MUSS die Anzahl der gespeicherten Tage für das Systemprotokoll und das Performanceprotokoll festlegen können. Der Konnektor kann Protokolleinträge, die älter als LOG_DAYS sind, zyklisch löschen. Dabei DARF der eingestellte Wert NICHT unter der Mindestgröße von 10 Tagen oder über der Maximalgröße von einem Jahr (365 Tage) liegen. Default-Wert: 180 |
FM_<fmName>_ LOG_DAYS |
X Tage |
Der Administrator MUSS die Anzahl der gespeicherten Tage für die fachmodulspezifischen Protokolle festlegen können. Es kann je Fachmodul einen Konfigurationsparameter für LOG_DAYS geben, der gemeinsam für das Fachmodulprotokoll und das Fachmodul-Performanceprotokoll gilt. Der Konnektor kann Protokolleinträge, die älter als FM_<fmName>LOG_DAYS sind, zyklisch löschen. Dabei DARF der eingestellte Wert NICHT unter der Mindestgröße von 10 Tagen oder über der Maximalgröße von einem Jahr (365 Tage) liegen. Default-Wert: 180 Die Definition des fachmodulspezifischen Konfigurationswertes ist Bestandteil der entsprechenden Fachmodulspezifikation. Ist kein fachmodulspezifischer Konfigurationsparameter spezifiziert, dann gilt LOG_DAYS. |
LOG_SUCCESSFUL_ CRYPTO_OPS |
Enabled/Disabled |
Der Administrator MUSS festlegen können, ob auch erfolgreich ausgeführte Kryptooperationen im Sicherheitslog protokolliert werden sollen. Default-Wert: Disabled |
[<=]
4.1.10.6.1 TUC_KON_272 „Initialisierung Protokollierungsdienst
TIP1-A_4718 - TUC_KON_272 „Initialisierung Protokollierungsdienst”
Der Konnektor MUSS den technischen Use Case TUC_KON_272 „Initialisierung Protokollierungsdienst” umsetzen.
Tabelle 294: TAB_KON_610 – TUC_KON_272 „Initialisierung Protokollierungsdienst“
Element |
Beschreibung |
Name |
TUC_KON_272 „Initialisierung Protokollierungsdienst” |
Beschreibung |
Der Konnektor muss zum Bootup den Protokollierungsdienst starten und die Existenz und Schreibbarkeit der Protokolle sicherstellen. |
Eingangs anforderung |
Keine |
Auslöser und Vorbedingungen |
Bootup |
Eingangsdaten |
Keine |
Komponenten |
Konnektor |
Ausgangsdaten |
Keine |
Standardablauf |
|
Varianten/ Alternativen |
Keine |
Fehlerfälle |
Fehler in den folgenden Schritten des Standardablaufs führen zu: a) Aufruf von TUC_KON_256 mit folgenden Parametern { topic = „LOG/ERROR“; eventType = $ErrorType; severity = $Severity; parameters = („Error=$Fehlercode, Bedeutung=$Fehlertext“); doLog = false } b) Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes (1) Zugriff nicht möglich: Fehlercode: 4153 (2) Zugriff nicht möglich: Fehlercode: 4154 (3) Zugriff nicht möglich: Fehlercode: 4155 (4) Zugriff nicht möglich: Fehlercode: 4218 (5) Zugriff nicht möglich: Fehlercode: 4219 |
Nichtfunktionale Anforderungen |
Keine |
Zugehörige Diagramme |
Keine |
Tabelle 295: TAB_KON_611 Fehlercodes TUC_KON_272 „Initialisiere Protokollierungsdienst“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4153 |
Technical |
Fatal |
Zugriff auf Sicherheitsprotokoll nicht möglich |
4154 |
Technical |
Fatal |
Zugriff auf Systemprotokoll nicht möglich |
4155 |
Technical |
Fatal |
Zugriff auf Fachmodulprotokolle nicht möglich |
4218 |
Technical |
Fatal |
Zugriff auf Konnektor-Performanceprotokoll nicht möglich |
4219 |
Technical |
Fatal |
Zugriff auf Fachmodul-Performanceprotokoll nicht möglich |
[<=]
4.1.11 TLS-Dienst
Fachmodule müssen gesicherte Verbindungen zu Fachdiensten in der TI aufbauen können. Dabei sollen sie sich mit einer Organisationsidentität (einer SM-B) authentisieren können. Der TLS-Dienst stellt hierfür TUCs für einen TLS-Verbindungsaufbau und -Verbindungsabbau zur Verfügung. Die gesicherte Kommunikation selbst erfolgt dann durch das Fachmodul unter Nutzung der etablierten Verbindung.
Die Funktionalität steht nur zur Verfügung, wenn MGM_LU_ONLINE aktiv ist (siehe Kapitel 4.3.6)
4.1.11.1 Funktionsmerkmalweite Aspekte
4.1.11.2 Durch Ereignisse ausgelöste Reaktionen
TIP1-A_4719 - TLS-Dienst reagiert auf Veränderung LU_ONLINE
Tritt das Ereignis „MGM/LU_CHANGED/LU_ONLINE“ ein, so MUSS
- wenn „Active=Enabled“ der Dienst bereitgestellt werden
- wenn „Active=Disabled“ der Dienst gestoppt werden.
Sind TLS-Verbindungen aktiv, so MUSS für jede TUC_KON_111 "Kartenbasierte TLS-Verbindung abbauen" gerufen werden.
4.1.11.3 Interne TUCs, nicht durch Fachmodule nutzbar
Keine.
4.1.11.4 Interne TUCs, auch durch Fachmodule nutzbar
4.1.11.4.1 TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen“
TIP1-A_4720-02 - TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen“
Der Konnektor MUSS den technischen Use Case "Kartenbasierte TLS-Verbindung aufbauen" gemäß TUC_KON_110 umsetzen.
Tabelle 296: TAB_KON_773 – TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen“
Element |
Beschreibung |
Name |
TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen“ |
Beschreibung |
Der TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen“ baut eine TLS-Verbindung zur angegebenen Zieladresse auf. Dabei kann für eine gegenseitige Authentisierung eine SM-B verwendet werden. |
Auslöser |
Aufruf durch ein Fachmodul |
Vorbedingungen |
Die für die Authentisierung adressierte Karte muss freigeschaltet sein |
Eingangsdaten |
|
Komponenten |
Konnektor, eHealth-Kartenterminal, Karte, Server des Fachdienstes |
Ausgangsdaten |
|
Standardablauf |
Der Konnektor MUSS folgende Schritte durchlaufen: 1. Auflösen des FQDN im targetUri per 'TUC_KON_361 „DNS Namen auflösen“ 2. TLS-Verbindung mit ermittelter Adresse aufbauen: a) Prüfe Server-Zertifikat mittels TUC_KON_037 „Zertifikat prüfen“ { certificate = C.FD.TLS-S; qualifiedCheck = not_required; offlineAllowNoCheck = true; policyList = oid_fd_tls_s; intendedKeyUsage= intendedKeyUsage(C.FD.TLS-S); intendedExtendedKeyUsage = id-kp-serverAuth; validationMode = OCSP} Das Server-Zertifikat MUSS C.FD.TLS-S sein b) Prüfe in a) zurückgegebene Rolle („ermittelte Rolle“) == roleToMatch c) Wenn cardSession übergeben: Clientauthentisierung mittels ID.HCI.AUT. Der Konnektor darf nur dann das ECC-Zertifikat von der SMC-B auswählen, wenn auch das Serverzertifikat ein ECC-Zertifikat ist. 3. tlsConnectiontId der erzeugten Verbindung zurückgeben |
Varianten/ Alternativen |
|
Fehlerfälle |
Fehler in den folgenden Schritten des Ablaufs führen zu einem Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes (1) Der Name der Gegenstelle kann nicht aufgelöst werden (2b) Rollenprüfung fehlgeschlagen: Fehlercode 4220 (2) Server konnte nicht authentisiert werden: Fehlercode 4156 (2) Clientauthentisierung fehlgeschlagen: Fehlercode 4157 |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
Tabelle 297: TAB_KON_612 Fehlercodes TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4156 |
Security |
Error |
Server konnte bei TLS-Verbindungsaufbau nicht authentisiert werden |
4157 |
Security |
Error |
Clientauthentisierung bei TLS-Verbindungsaufbau fehlgeschlagen |
4220 |
Security |
Error |
Rollenprüfung bei TLS-Verbindungsaufbau fehlgeschlagen |
[<=]
4.1.11.4.2 TUC_KON_111 „Kartenbasierte TLS-Verbindung abbauen“
TIP1-A_4721 - TUC_KON_111 „Kartenbasierte TLS-Verbindung abbauen“
Der Konnektor MUSS den technischen Use Case "Kartenbasierte TLS-Verbindung abbauen" gemäß TUC_KON_111 umsetzen.
Tabelle 298: TAB_KON_774 - TUC_KON_111 „Kartenbasierte TLS-Verbindung abbauen“
Element |
Beschreibung |
Name |
TUC_KON_111 „Kartenbasierte TLS-Verbindung abbauen“ |
Beschreibung |
Der TUC_KON_111 „Kartenbasierte TLS-Verbindung abbauen“ dient der geregelten Beendigung einer TLS-Verbindung, die zuvor über TUC_KON_110 aufgebaut wurde. |
Auslöser |
Aufruf durch ein Fachmodul |
Vorbedingungen |
Mittels TUC_KON_110 wurde eine TLS-Verbindung aufgebaut |
Eingangsdaten |
|
Komponenten |
Konnektor, Server des Fachdienstes |
Ausgangsdaten |
Keine |
Standardablauf |
Der Konnektor MUSS folgende Schritte durchlaufen:
|
Varianten/ Alternativen |
keine |
Fehlerfälle |
Fehler in den folgenden Schritten des Ablaufs führen zu einem Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes: (1) Keine Verbindung mit angegebenem TLSConnectionIdentifier vorhanden: Fehlercode 4158 |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
Tabelle 299: TAB_KON_613 Fehlercodes TUC_KON_111 „Kartenbasierte TLS-Verbindung abbauen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4158 |
Technical |
Error |
Adressierte TLS-Verbindung nicht vorhanden |
[<=]
4.1.11.5 Operationen an der Außenschnittstelle
Keine.
4.1.11.6 Betriebsaspekte
TIP1-A_4722 - TLS-Dienst initialisieren
Wenn MGM_LU_ONLINE = „Enabled“, MUSS der Basisdienst TLS-Dienst nach dem Bootup zur Nutzung zur Verfügung stehen.
Wenn MGM_LU_ONLINE = „Disabled“, DARF der Basisdienst TLS-Dienst nach dem Bootup NICHT zur Nutzung zur Verfügung stehen.
[<=]4.1.12 LDAP-Proxy
Der Konnektor ermöglicht es Clientsystemen und Fachmodulen durch Nutzung des LDAP-Proxies Daten aus dem Verzeichnisdienst der TI-Plattform (VZD) abzufragen. Die Kommunikation erfolgt über das LDAPv3 Protokoll.
Die Funktionalität steht nur zur Verfügung, wenn MGM_LU_ONLINE=Enabled ist (siehe Kapitel 4.3.6)
4.1.12.1 Funktionsmerkmalweite Aspekte
Keine.
4.1.12.2 Durch Ereignisse ausgelöste Reaktionen
TIP1-A_5516 - LDAP-Proxy reagiert auf Veränderung LU_ONLINE
Tritt das Ereignis „MGM/LU_CHANGED/LU_ONLINE“ ein, so MUSS
- wenn „Active=Enabled“ der Dienst bereitgestellt werden
- wenn „Active=Disabled“ der Dienst gestoppt werden.
Ist eine Verbindung zum VZD aktiv, so MUSS diese abgebaut werden.
4.1.12.3 Interne TUCs, nicht durch Fachmodule nutzbar
Keine.
4.1.12.4 Interne TUCs, auch durch Fachmodule nutzbar
4.1.12.4.1 TUC_KON_290 „LDAP-Verbindung aufbauen“
TIP1-A_5517-02 - Konnektor, TUC_KON_290 „LDAP-Verbindung aufbauen“
Der Konnektor MUSS den technischen Use Case TUC_KON_290 „LDAP-Verbindung aufbauen“ gemäß TAB_KON_805 umsetzen.
Tabelle 300: TAB_KON_805 - TUC_KON_290 „LDAP-Verbindung aufbauen“
Element |
Beschreibung |
Name |
TUC_KON_290 „LDAP-Verbindung aufbauen“ |
Beschreibung |
Initiiert durch einen Verbindungsaufbau des LDAP-Clients zum Konnektor baut der Konnektor eine TLS-gesicherte Verbindung zum VZD auf. |
Auslöser |
LDAP (oder LDAPS wenn ANCL_TLS_MANDATORY=Enabled) Verbindungsaufbau von einem Fachmodul oder einem Clientsystem ist abgeschlossen. Bei Verwendung von LDAPS authentisiert sich der Konnektor beim LDAP-Client mit der Identität ID.AK.AUT. |
Vorbedingungen |
|
Eingangsdaten |
keine |
Komponenten |
Konnektor, VZD |
Ausgangsdaten |
keine |
Standardablauf |
|
Varianten/Alternativen |
keine |
Fehlerfälle |
|
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
[<=]
4.1.12.4.2 TUC_KON_291 „Verzeichnis abfragen“
TIP1-A_5518 - Konnektor, TUC_KON_291 „Verzeichnis abfragen“
Der Konnektor MUSS den technischen Use Case TUC_KON_291 „Verzeichnis abfragen“ gemäß TAB_KON_815 umsetzen.
Tabelle 301: TAB_KON_815 – TUC_KON_291 „Verzeichnis abfragen“
Element |
Beschreibung |
Name |
TUC_KON_291 „Verzeichnis abfragen“ |
Beschreibung |
Der Konnektor leitet als LDAP-Proxy einen Search Request des LDAP-Clients an den VZD weiter. Vom VZD empfängt der Konnektor eine Search Response und leitet diese an den LDAP-Client weiter. |
Auslöser |
Aufruf durch einen LDAPv3 Search Request von einen Fachmodul-TUC oder einem Clientsystem |
Vorbedingungen |
|
Eingangsdaten |
|
Komponenten |
Konnektor, VZD |
Ausgangsdaten |
|
Standardablauf |
|
Varianten/Alternativen |
keine |
Fehlerfälle |
Auftretende Fehler werden gemäß [RFC4511]# Appendix A behandelt. |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
4.1.12.4.3 TUC_KON_292 „LDAP-Verbindung trennen"
TIP1-A_5519 - Konnektor, TUC_KON_292 „LDAP-Verbindung trennen"
Der Konnektor MUSS den technischen Use Case „LDAP-Verbindung trennen" gemäß TAB_KON_816 umsetzen.
Tabelle 302: TAB_KON_816 – TUC_KON_292 „LDAP-Verbindung trennen"
Element |
Beschreibung |
Name |
TUC_KON_292 „LDAP-Verbindung trennen" |
Beschreibung |
Der Konnektor beendet die Verbindung zum VZD und zum LDAP-Client. |
Auslöser |
Aufruf durch einen LDAPv3 Unbind Request von einen Fachmodul-TUC oder einem Clientsystem |
Vorbedingungen |
|
Eingangsdaten |
keine |
Komponenten |
Konnektor, VZD |
Ausgangsdaten |
keine |
Standardablauf |
|
Varianten/Alternativen |
keine |
Fehlerfälle |
Auftretende Fehler werden gemäß [RFC4511]# Appendix A behandelt. |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
[<=]
4.1.12.4.4 TUC_KON_293 „Verzeichnisabfrage abbrechen"
TIP1-A_5520 - Konnektor, TUC_KON_293 „Verzeichnisabfrage abbrechen"
Der Konnektor MUSS den technischen Use Case TUC_KON_293 „Verzeichnisabfrage abbrechen" gemäß TAB_KON_817 umsetzen.
Tabelle 303: TAB_KON_817 – TUC_KON_293 „Verzeichnisabfrage abbrechen“
Element |
Beschreibung |
Name |
TUC_KON_293 „Verzeichnisabfrage abbrechen" |
Beschreibung |
Der Konnektor bricht einen unbeantworteten Search Request ab. |
Auslöser |
Aufruf durch einen LDAPv3 Abandon Request von einen Fachmodul-TUC oder einem Clientsystem |
Vorbedingungen |
|
Eingangsdaten |
keine |
Komponenten |
Konnektor, VZD |
Ausgangsdaten |
keine |
Standardablauf |
|
Varianten/Alternativen |
keine |
Fehlerfälle |
Auftretende Fehler werden gemäß [RFC4511]# Appendix A behandelt. |
Nichtfunktionale Anforderungen |
keine |
Zugehörige Diagramme |
keine |
[<=]
4.1.12.5 Operationen an der Außenschnittstelle
4.1.12.5.1 Unterstützte LDAPv3 Operationen
TIP1-A_5521 - Konnektor, LDAPv3 Operationen
Der Konnektor MUSS an der Client-Schnittstelle die folgenden LDAPv3 Operationen gemäß [RFC4511] anbieten.
- Bind Operation
- Unbind Operation
- Search Operation
- Abandon Operation
Wenn ANCL_TLS_MANDATORY=Enabled, muss der Konnektor sicherstellen, dass nur über eine LDAPS-Verbindung (Voreinstellung TCP Port 636) Daten abgefragt werden können.
Wenn ANCL_TLS_MANDATORY=Disabled, muss der Konnektor sicherstellen, dass über eine LDAP-Verbindung (Voreinstellung TCP Port 389) und über eine LDAPS-Verbindung (Voreinstellung TCP Port 636) Daten abgefragt werden können.
Fehler müssen gemäß [RFC4511]#Appendix A behandelt werden.
[<=]
4.1.12.6 Betriebsaspekte
keine
4.1.13 Authentifizierungsdienst
Der Authentifizierungsdienst bietet Clientsystemen und Fachmodulen eine Schnittstelle zum Signieren von Binärstrings zum Zweck der externen Authentisierung.
Innerhalb des Authentifizierungsdienstes werden folgende Präfixe für Bezeichner verwendet:
- Events (Topic Ebene 1): keine Events vorhanden
- Konfigurationsparameter: keine Konfigurationsparameter vorhanden
Eine Prüfung der Signatur bietet der Konnektor nicht an.
4.1.13.1 Funktionsmerkmalweite Aspekte
4.1.13.1.1 Externe Authentisierung
TIP1-A_5437-02 - Signaturverfahren für externe Authentisierung
Der Signaturdienst MUSS für die Operation ExternalAuthenticate die Signaturverfahren entsprechend TAB_KON_780 – Signaturverfahren Externe Authentisierung unterstützen.
Tabelle 304: TAB_KON_780 – Signaturverfahren Externe Authentisierung
Signaturformat |
Standard |
Dokument formate |
QES/ nonQES |
Bemerkung |
---|---|---|---|---|
PKCS#1 (V2.1) |
[RFC3447] |
Binär |
nonQES |
Die Low-Level-Signatur von Bitstrings DARF NUR in Verbindung mit dem zur Authentisierung vorgesehenen Schlüssel des HBAx und des SM-B genutzt werden. Die Nutzung ist auf Bitstrings (Hash-Werte) von maximal 512 bit Länge beschränkt. |
ECDSA | [BSI-TR-03111] | Binär | nonQES |
[<=]
TIP1-A_5149-01 - ExternalAuthenticate nur für Authentisierung mit HBAx und SM-B nutzen
Der Hersteller des Konnektors MUSS den Anwender (Clientsystem) im Handbuch des Konnektors geeignet und ausreichend darüber informieren, dass die Operation ExternalAuthenticate nur zu Authentisierungszwecken mit dem Authentisierungsschlüssel des HBAx und des SM-B verwendet werden darf. [<=]
4.1.13.2 Durch Ereignisse ausgelöste Reaktionen
keine
4.1.13.3 Interne TUCs
keine
4.1.13.4 Operationen an der Außenschnittstelle
TIP1-A_5665-03 - Basisdienst Authentifizierungsdienst
Der Konnektor MUSS Clientsystemen den Basisdienst Authentifizierungsdienst anbieten.
Tabelle 305: TAB_KON_839 Basisdienst Authentifizierungsdienst
Name |
AuthSignatureService |
|
---|---|---|
Version (KDV) |
7.4.0 (WSDL-Version) 7.4.1 (WSDL-Version) |
|
Namensraum |
Siehe GitHub |
|
Namensraum-Kürzel |
SIG für Schema und SIGW für WSDL |
|
Operationen |
Name |
Kurzbeschreibung |
ExternalAuthenticate |
Binärstring signieren (nonQES) |
|
WSDL |
AuthSignatureService_V7_4_1.wsdl AuthSignatureService.wsdl (WSDL-Version 7.4.0) |
|
Schema |
Kein |
[<=]
4.1.13.4.1 ExternalAuthenticate
TIP1-A_5439 - Operation ExternalAuthenticate
Der Authentifizierungsdienst des Konnektors MUSS an der Clientschnittstelle eine Operation ExternalAuthenticate anbieten.
Tabelle 306: TAB_KON_781 Operation ExternalAuthenticate
Name |
ExternalAuthenticate |
||
---|---|---|---|
Beschrei bung |
Diese Operation versieht einen Binärstring der maximalen Länge 512 Bit mit einer nicht-qualifizierten elektronischen Signatur (nonQES). Dazu wird das Signaturverfahren PKCS#1 oder ECDSA verwendet. Das AUT-Zertifikat der SM-B und das AUT-Zertifikat des HBAx werden unterstützt. |
||
Aufruf parameter |
|||
Name |
Beschreibung |
||
CONN: CardHandle |
Identifiziert die zu verwendende Signaturkarte. Die Operation unterstützt HBAx und SM-B. |
||
CCTX: Context |
Aufrufkontext für HBAx: MandantId, ClientSystemId, WorkplaceId, UserId verpflichtend Aufrufkontext für SM-B: MandantId, ClientSystemId, WorkplaceId verpflichtend; UserId nicht ausgewertet |
||
SIG: Optional Inputs |
Enthält optionale Eingangsparameter: |
||
SIG: Binary String |
Dieses Element enthält im Kindelement dss:Base64Data den zu signierenden Binärstring. Das XML Attribut SIG:BinaryString/dss:Base64Data/@MimeType MUSS den Wert "application/octet-stream" haben. Die maximale Länge des Binärstrings beträgt 512 Bit entsprechend der maximal zu erwartenden Hash-Größe. Aus der Länge des Binärstrings wird auf das verwendete Hashverfahren geschlossen. Es werden folgende Längen unterstützt:
Im Falle des Signaturverfahrens RSASSA-PSS wird SHA-256 unterstützt. Im Falle des Signaturverfahrens ECDSA wird SHA-256 unterstützt. Für die Signaturerstellung gilt:
|
||
dss: Signature Type |
Durch dieses in [OASIS-DSS] (Abschnitt 3.5.1) beschriebene Element wird der Typ der zu erzeugenden Signatur bestimmt. Als Signaturtyp wird unterstützt :
Fehlt dieses Element, so wird ebenfalls der Signaturtyp PKCS#1-Signatur verwendet. |
||
SIG: Signature Schemes |
Durch dieses Element wird für PKCS#1-Signaturen zwischen den folgenden SignatureScheme-Optionen unterschieden:
|
||
Rückgabe |
|||
CONN: Status |
Enthält den Status der ausgeführten Operation. |
||
dss: Signature Object |
Enthält im Erfolgsfall die erzeugte Signatur in Form eines dss:SignatureObject-Elements gemäß [OASIS-DSS] (Abschnitt 3.2). Der Signaturwert wird im XML-Element dss:SignatureObject/dss:Base64Signature übergeben. Die Signatur wird binär gemäß [BSI-TR-03111]#5.2.2 in der ASN.1 Struktur ECDSA-Sig-Value zurückgegeben. Das XML-Attribut dss:SignatureObject/dss:Base64Signature/@Type kennzeichnet durch den Wert:
dss:SignatureObject/ds:Signature dss:SignatureObject/dss:Timestamp dss:SignatureObject/dss:SignaturePtr dss:SignatureObject/dss:Other werden nicht verwendet. |
||
Vorbeding ungen |
Keine |
||
Nachbeding ungen |
Keine |
Tabelle 307: TAB_KON_782 Ablauf Operation ExternalAuthenticate
Nr. |
Aufruf Technischer Use Case oder Interne Operation |
Beschreibung |
---|---|---|
1.
|
checkArguments |
Alle übergebenen Parameterwerte 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 {$context.mandantId; $context.clientsystemId; $context.workplaceId; $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, CsId, CardHandle, UserId } |
4.
|
TUC_KON_218 „Signiere“ |
Signaturberechnung durch Aufruf des TUC_KON_218 { PinRef = PIN.CH bzw. PIN.SMC; KeyRef = PrK.HP.AUT bzw. PrK.HCI.AUT; AlgorithmusID = signPKCS1_V1_5 oder signPSS oder signECDSA; DTBS = Binärstring } |
Tabelle 308: TAB_KON_783 Übersicht Fehler Operation ExternalAuthenticate
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen TUCs können folgende weitere Fehlercodes auftreten: |
|||
4000 |
Technical |
Error |
Syntaxfehler |
4058 |
Security |
Error |
Aufruf nicht zulässig |
Tabelle 309: TAB_KON_784 Privater Schlüssel je Karte für ExternalAuthenticate
Karte |
Schlüssel |
---|---|
SM-B |
PrK.HCI.AUT in DF.ESIGN |
HBAx |
PrK.HP.AUT in DF.ESIGN |
4.1.13.5 Betriebsaspekte
Keine
4.1.14 Betriebsdatenmeldedienst
A_21136 - Konnektor:Betriebsdaten - Nutzung der Operation I_Registration_Service#sendData
Der Konnektor MUSS die Operation I_Registration_Service#sendData benutzen, um die Betriebsdaten täglich zu versenden.
[<=]
A_21137 - Konnektor:Betriebsdaten - Formatierung der Betriebsdaten
Der Konnektor MUSS die Betriebsdaten als XML-Dokument gemäß dem Schema „conn/OperatingData.xsd“ mit
- dem MimeType "text/xml" und
- dem Type "OperatingDataConnector"
A_21225 - Konnektor:Betriebsdaten - Annotations im XML-Schema
Der Konnektor MUSS die XML Elemente der Betriebsdaten gemäß der Annotations im Schema OperatingData.xsd befüllen. [<=]
A_21138 - Konnektor:Betriebsdaten - Fehlerbehandlung
Liefert I_Registration_Service einen Fehler, MUSS der Konnektor das Senden der Betriebsdaten 3 Mal im Abstand von 5 Minuten erneut versuchen. [<=]
A_21139 - Konnektor:Betriebsdaten - Soap Operation sendData nicht vorhanden
Meldet I_Registration_Service, dass die Soap Operation sendData nicht vorhanden ist, DARF der Konnektor die Operation NICHT sofort wiederholen. Erst zum nächsten regulären Termin soll wieder gesendet werden. [<=]
A_21140 - Konnektor:Betriebsdaten - Keine personenbezogenen und medizinischen Daten senden
Der Konnektor DARF NICHT personenbezogene, personenbeziehbare oder medizinische Daten senden. [<=]
A_23275 - Konnektor: Betriebsdaten - Manuelles Versenden der Betriebsdaten
Der Konnektor SOLL dem Administrator an der Management-Oberfläche ein manuelles Versenden der Betriebsdaten ermöglichen. Dabei wird die Operation I_Registration_Service#sendData aufgerufen. [<=]
4.2 Netzkonnektor
4.2.1 Anbindung LAN/WAN
Unter Anbindung LAN/WAN werden die Mechanismen beschrieben, mit denen der Konnektor auf der einen Seite in das lokale Netz der Einsatzumgebung, auf der anderen Seite in die TI bzw. die Bestandsnetze angebunden wird. Diese wesentlichen Aspekte betreffen Routing und Firewall.
Innerhalb des Kapitels Anbindung LAN/WAN werden folgende Präfixe für Bezeichner verwendet:
- Events (Topic Ebene 1): „ANLW“
- Konfigurationsparameter: „ANLW_“
4.2.1.1 Funktionsmerkmalweite Aspekte
TIP1-A_4723 - Verhalten als IPv4 Router
Der Konnektor MUSS sich nach den in [RFC1812#1.1.3] definierten Rahmenbedingungen als IP Version 4 (IPv4) Router verhalten.
Hiervon ausgenommen sind die in den folgenden Kapiteln aufgeführten Anforderungen des [RFC1812]:
- 7.2 INTERIOR GATEWAY PROTOCOLS
- 7.3 EXTERIOR GATEWAY PROTOCOLS
- 7.5 FILTERING OF ROUTING INFORMATION
- 7.6 INTER-ROUTING-PROTOCOL INFORMATION EXCHANGE
- 8. APPLICATION LAYER - NETWORK MANAGEMENT PROTOCOLS
- 9. APPLICATION LAYER - MISCELLANEOUS PROTOCOLS
- 10. OPERATIONS AND MAINTENANCE
[<=]
TIP1-A_5406 - IP-Pakete mit Source Route Option
Der Konnektor DARF NICHT IP-Pakete mit gesetzter Source Route Option gemäß [RFC791] erzeugen oder weiterleiten.
[<=]In der folgenden Anforderung wird die Terminologie gemäß [RFC2663] verwendet.
TIP1-A_5407 - NAT-Umsetzung im Konnektor
Der Konnektor MUSS für die Kommunikation aus den Adressbereichen NET_LEKTR-Umgebung mit den Adressbereichen NET_TI_OFFENE_FD und ANLW_BESTANDSNETZE eine Network Address Port Translation (NAPT) gemäß [RFC3022#2.2, 3, 4.1-4.3] vornehmen.
Für die Umsetzung der Private Local Address aus den Adressbereichen der Einsatzumgebung MUSS die IP-Adresse VPN_TUNNEL_TI_INNER_IP als Global Address genutzt werden.
Der Konnektor MUSS für die Kommunikation aus den Adressbereichen der NET_LEKTR-Umgebung mit dem Internet über den VPN-Tunnel SIS eine Network Address Port Translation (NAPT) gemäß RFC3022#2.2, 3, 4.1-4.3 vornehmen. Für die Umsetzung der Local Address MUSS die IP-Adresse VPN_TUNNEL_SIS_INNER_IP als Global Address genutzt werden.
[<=]
TIP1-A_4724 - LAN-Adapter
Der Konnektor MUSS sicherstellen, dass nur über den LAN-Adapter (Adressen aus ANLW_LAN_NETWORK_SEGMENT oder Adressen aus einem der Netzwerksegmente in ANLW_LEKTR_INTRANET_ROUTES) mit den Clientsystemen und den Kartenterminals kommuniziert werden kann.
[<=]
TIP1-A_4725 - WAN-Adapter
Für den Betrieb in Reihe (ANLW_ANBINDUNGS_MODUS=InReihe) MUSS der Konnektor den WAN-Adapter für den Zugang zum Internet über das IAG der Einsatzumgebung verwenden.
[<=]TIP1-A_4726 - Internet Anbindung nur bei MGM_LU_ONLINE
Der Hersteller des Konnektors MUSS sicherstellen, dass eine Anbindung an das Transportnetz/Internet nur möglich ist, wenn (MGM_LU_ONLINE=Enabled) gesetzt ist.
[<=]
TIP1-A_4728 - Nur IPv4. IPv6 nur hardwareseitig vorbereitet
Der Konnektor MUSS IP Version 4 (IPv4) für alle seine IP-Schnittstellen unterstützen.
Die Hardware des Konnektors MUSS für den Einsatz von IPv4 und IPv6 im Dual-Stack-Mode geeignet sein.
Bis zu einer Migration von IPv4 auf IPv6 MUSS der Konnektor sämtliche empfangene IP-Pakete der Version 6 (IPv6) verwerfen.
[<=]
TIP1-A_4728-01 - IPv4 und IPv6 (Option IPv6)
Der Konnektor MUSS IP Version 4 (IPv4) und IP Version 6 (IPv6) für alle seine physikalischen Adapter unterstützen.
Die Hardware des Konnektors MUSS für den Einsatz von IPv4 und IPv6 im Dual-Stack-Mode geeignet sein.
[<=]
TIP1-A_4729 - Es darf kein dynamisches Routing verwendet werden
Dynamische Routing-Protokolle dürfen vom Konnektor nicht eingesetzt werden. Wird in einem der an den Konnektor angeschlossenen Netzwerke ein dynamisches Routing genutzt, so DÜRFEN Routing Updates vom Konnektor NICHT akzeptiert werden und keine Routen eingetragen werden.
[<=]TIP1-A_5152 - Aktualisieren der Infrastrukturinformationen aus der TI
Falls Parameter MGM_LU_ONLINE=Enabled, MUSS der Konnektor einmal täglich TUC_KON_283 „Infrastruktur Konfiguration aktualisieren“ aufrufen.
[<=]4.2.1.1.1 Netzwerksegmentierung
In Anlehnung an die in der [gemSpec_Net#2.3.3] definierten Netzwerksegmente werden in der Konnektorspezifikation die folgenden Bezeichner verwendet:
Tabelle 310: TAB_KON_680 Mapping der Netzwerksegmente
ReferenzID im Konnektor |
Adressbereich für die TI-Produktivumgebung |
Adressbereich für die TI-Testumgebung |
Adressbereich für die TI-Referenzumgebung |
---|---|---|---|
NET_SIS |
TI_Dezentral_SIS - Konnektoren |
TI_Test_Dezentral_SIS - Konnektoren |
Ist durch den Testbetriebsverantwortlichen zu definieren. |
NET_TI_ DEZENTRAL |
TI_Dezentral - Konnektoren |
TI_Test_Dezentral - Konnektoren |
Ist durch den Testbetriebsverantwortlichen zu definieren. |
NET_TI_ ZENTRAL |
TI_Zentral - Zentrale Dienste |
TI_Test_Zentral - Zentrale Dienste |
Ist durch den Testbetriebsverantwortlichen zu definieren. |
NET_TI_ OFFENE_FD |
Anwendungsdienste - Offene Fachdienste - WANDA Smart - WANDA Basic |
Test_Anwendungsdienste - Offene Fachdienste - WANDA Smart - WANDA Basic |
Ist durch den Testbetriebsverantwortlichen zu definieren. |
NET_TI_ GESICHERTE_ FD |
Anwendungsdienste - Gesicherte Fachdienste |
Test_Anwendungsdienste - Gesicherte Fachdienste |
Ist durch den Testbetriebsverantwortlichen zu definieren. |
NET_LEKTR |
Liste der Netzwerke die in der Einsatzumgebung über den Konnektor erreichbar sind. Ein Eintrag der Liste enthält die Netzwerkadresse und den Netzwerkprefix. |
||
ANLW_ BESTANDS NETZE |
Liste der an die TI angeschlossenen Bestandsnetze (u. a. das Sichere Netz der KVen). Ein Eintrag der Liste enthält die Netzwerkadresse und den Netzwerkprefix. |
||
ANLW_ AKTIVE_ BESTANDS NETZE |
Liste der an die TI angeschlossenen und aktivierten Bestandsnetze |
Tabelle 311: TAB_KON_681 Definition der vom Konnektor verwendeten VPN-Tunnel
ReferenzID |
Bedeutung/Belegung |
---|---|
VPN_TI |
Logischer Adapter des VPN-Tunnel zur TI mit dessen VPN_TUNNEL_TI_INNER_IP aus dem Adresssegment NET_TI_DEZENTRAL |
VPN_SIS |
Logischer Adapter des VPN-Tunnel zur SIS mit dessen VPN_TUNNEL_SIS_INNER_IP aus dem Addresssegment NET_SIS |
Tabelle 312: TAB_KON_682 Definition der Konnektor IP-Adressen
ReferenzID |
Bedeutung/Belegung |
---|---|
ANLW_LAN_IP_ADDRESS |
Dies ist die IP-Adresse des LAN-Adapters. Aus dem Netz der Einsatzumgebung (ANLW_LAN_NETWORK_SEGMENT) die vom Konnektor verwendete IP-Adresse. Unter dieser Adresse werden die Dienste des Konnektor im lokalen Netzwerk bereitgestellt. Diese Adresse entspricht dem in Tabelle TAB_KON_683 LAN-Adapter IP-Konfiguration definierten Parameter ANLW_LAN_IP_ADDRESS. |
ANLW_WAN_IP_ADDRESS |
Dies ist die IP-Adresse des WAN-Adapters. |
4.2.1.1.2 Routing und Firewall
Darstellung der Kommunikationsregeln des Konnektors
Diese Abbildung dient der Veranschaulichung der im Konnektor verwendeten Kommunikationsregeln welche in den nachfolgenden Afo definiert werden.
Abbildung 21: PIC_KON_115 Kommunikationsregeln Konnektor
TIP1-A_4730 - Kommunikation mit NET_TI_GESICHERTE_FD
Der Konnektor MUSS sicherstellen, dass IP-Pakete mit einer Absenderadresse aus dem Adressbereich NET_TI_GESICHERTE_FD verworfen werden, wenn sie nicht aus dem VPN-Tunnel der TI (VPN_TI) stammen.
Der Konnektor MUSS die Kommunikation mit Systemen des Netzwerksegments NET_TI_GESICHERTE_FD für folgende Fälle unterstützen:
- [1] vom Konnektor kommend
- [37] wenn (MGM_LU_ONLINE=Enabled) vom Fachmodul kommend
- [2] von „Aktive Komponenten“ kommend
- [3] in Richtung Konnektor gehend
[<=]
TIP1-A_5530 - Kommunikation mit NET_TI_OFFENE_FD
Der Konnektor MUSS sicherstellen, dass IP-Pakete mit einer Absenderadresse aus dem Adressbereich NET_TI_OFFENE_FD verworfen werden, wenn sie nicht aus dem VPN-Tunnel der TI (VPN_TI) stammen.
Der Konnektor MUSS die Kommunikation mit Systemen des Netzwerksegments NET_TI_OFFENE_FD für folgende Fälle unterstützen:
- [33] von „Aktive Komponenten“ kommend
- [36] vom Fachmodul kommend
- [34] vom Konnektor kommend
- [35] in Richtung Konnektor gehend
[<=]
TIP1-A_4731 - Kommunikation mit NET_TI_ZENTRAL
Der Konnektor MUSS sicherstellen, dass IP-Pakete mit einer Absenderadresse aus dem Adressbereich NET_TI_ZENTRAL verworfen werden, wenn sie nicht aus dem VPN-Tunnel der TI (VPN_TI) stammen.
Der Konnektor MUSS die Kommunikation mit Systemen des Netzwerksegments NET_TI_ZENTRAL für folgende Fälle unterstützen:
[4] vom Konnektor kommend
Der Konnektor MUSS insbesondere die Kommunikation an seinen Außenschnittstellen mit Systemen des Netzwerksegments NET_TI_ZENTRAL für folgende Fälle blockieren:
[5] von „Aktive Komponenten“ kommend
[6] in Richtung Konnektor gehend
Der Konnektor MUSS sicherstellen, dass die aus einer unterstützten Kommunikation mit Systemen aus dem Netzwerksegment NET_TI_ZENTRAL bestimmten IP-Pakete ausschließlich in den VPN-Tunnel der TI (VPN_TI) geleitet werden.
[<=]TIP1-A_4732 - Kommunikation mit NET_TI_DEZENTRAL
Der Konnektor MUSS sicherstellen, dass die Adressen aus dem Adressbereich NET_TI_DEZENTRAL nur für die Kommunikation mit der TI/den weiteren Anwendungen des Gesundheitswesens in Form der inner IP (VPN_TUNNEL_TI_INNER_IP) des VPN-Tunnel der TI (VPN_TI) verwendet wird.
Der Konnektor MUSS die Kommunikation mit Systemen des Netzwerksegments NET_TI_DEZENTRAL für folgende Fälle unterstützen:
- keine
- [7] vom Konnektor kommend (zur Verhinderung des Zugriffs auf fremde Konnektoren)
- [8] von „Aktive Komponenten“
- [9] in Richtung Konnektor gehend
TIP1-A_4733 - Kommunikation mit ANLW_AKTIVE_BESTANDSNETZE
Der Konnektor MUSS sicherstellen, dass IP-Pakete mit einer Absenderadresse aus dem Adressbereich ANLW_AKTIVE_BESTANDSNETZE verworfen werden, wenn sie nicht aus dem VPN-Tunnel der TI (VPN_TI) stammen.
Der Konnektor MUSS die Kommunikation mit Systemen des Netzwerksegments ANLW_AKTIVE_BESTANDSNETZE für folgende Fälle unterstützen:
- [10] wenn (MGM_LU_ONLINE=Enabled ) vom Konnektor kommend nur für die DNS-Namensauflösung mittels DNS_SERVERS_BESTANDSNETZE
- [11b] wenn (MGM_LU_ONLINE=Enabled) von „Aktive Komponenten“ kommend
- [11a] für nicht freigegebene angeschlossene Netze des Gesundheitswesens mit WANDA Basic (ANLW_BESTANDSNETZE abzüglich ANLW_AKTIVE_BESTANDSNETZE) von „Aktive Komponenten“ kommend;
- [12] in Richtung Konnektor gehend (und den dahinterliegenden „Aktive Komponenten“)
[<=]
TIP1-A_4734 - Kommunikation mit NET_SIS
Der Konnektor MUSS sicherstellen, dass eine Adresse aus dem Adressbereich NET_SIS nur für die Kommunikation mit dem Internet (via SIS) in Form der inner IP (VPN_TUNNEL_SIS_INNER_IP) des VPN-Tunnel der SIS (VPN_SIS) verwendet wird.
Der Konnektor MUSS insbesondere die Kommunikation mit Systemen des Netzwerksegments NET_SIS für folgende Fälle unterstützen:
keine
Der Konnektor MUSS die Kommunikation an seinen Außenschnittstellen mit NET_SIS für folgende Fälle blockieren:
[13] vom Konnektor kommend
[14] von „Aktive Komponenten“ kommend
[15] in Richtung Konnektor gehend (und den dahinterliegenden „Aktiven Komponenten“)
TIP1-A_4735 - Kommunikation mit dem Internet (via SIS)
Der Konnektor MUSS sicherstellen, dass IP-Pakete mit einer Absenderadresse aus dem Adressbereich NET_TI_ZENTRAL, NET_TI_GESICHERTE_FD; NET_TI_OFFENE_FD, NET_TI_DEZENTRAL, ANLW_AKTIVE_BESTANDSNETZE, ANLW_LAN_ADDRESS_SEGMENT, aus einem der Netzwerksegmente in ANLW_LEKTR_INTRANET_ROUTES oder ANLW_WAN_NETWORK_SEGMENT verworfen werden, wenn sie aus dem VPN-Tunnel der SIS (VPN_SIS) stammen.
Der Konnektor MUSS die Kommunikation mit Systemen des Netzwerksegments Internet (via SIS) für folgende Fälle unterstützen:
[16] wenn (MGM_LU_ONLINE=Enabled und ANLW_INTERNET_MODUS=SIS) vom Konnektor kommend
[17c] wenn (MGM_LU_ONLINE=Enabled und ANLW_INTERNET_MODUS=SIS) von „Aktive Komponenten“ kommend
Der Konnektor MUSS insbesondere die Kommunikation an seinen Außenschnittstellen mit Internet (via SIS) für folgende Fälle blockieren oder umleiten:
[17a] blockieren, wenn (MGM_LU_ONLINE=Enabled und ANLW_INTERNET_MODUS=KEINER) von „Aktive Komponenten“ kommend
[17b] umleiten, wenn (MGM_LU_ONLINE=Enabled und ANLW_INTERNET_MODUS=IAG) von „Aktive Komponenten“ kommend;
Der Konnektor MUSS an Hosts im Internet gerichtete IP-Pakete gemäß [RFC792] umleiten (ICMP Redirect).[18] blockieren, wenn von SIS kommend in Richtung Konnektor (und die dahinterliegenden „Aktive Komponenten“)
Der Konnektor MUSS sicherstellen, dass die für die Kommunikation mit dem Internet (via SIS) bestimmten IP-Pakete ausschließlich in den VPN-Tunnel des SIS (VPN_SIS) geleitet werden.
[<=]TIP1-A_4736-02 - Kommunikation mit dem Internet (via IAG)
Der Konnektor MUSS sicherstellen, dass eingehende IP-Pakete von der Kommunikation mit dem Internet mit der Empfängeradresse ungleich (ANLW_LAN_IP_ADDRESS oder aus einem der Netzwerksegmente in ANLW_LEKTR_INTRANET_ROUTES wenn ANLW_WAN_ADAPTER_MODUS=DISABLED) oder (ANLW_WAN_IP_ADDRESS wenn ANLW_WAN_ADAPTER_MODUS=ENABLED) verworfen werden.
Der Konnektor MUSS sicherstellen, dass ausgehende IP-Pakete für die Kommunikation mit dem Internet mit der Absenderadresse ungleich (ANLW_LAN_IP_ADDRESS oder aus einem der Netzwerksegmente in ANLW_LEKTR_INTRANET_ROUTES wenn ANLW_WAN_ADAPTER_MODUS=DISABLED) oder (ANLW_WAN_IP_ADDRESS wenn ANLW_WAN_ADAPTER_MODUS=ENABLED) verworfen werden.
Der Konnektor MUSS die Kommunikation mit Systemen des Netzwerksegments Internet (via IAG) für folgende Fälle unterstützen:
- [19] vom Konnektor kommend zu den folgenden Systemen für das Protokoll IPsec
-
- VPN_KONZENTRATOR_TI_IP_ADDRESS
- VPN_KONZENTRATOR_SIS_IP_ADDRESS
- VPN_KONZENTRATOR_TI_IP_ADDRESS
- [19] vom Konnektor kommend zu den folgenden Systemen für HTTP und HTTPS
-
- CERT_CRL_DOWNLOAD_ADDRESS
- TSL-Download-Punkt des TSL-Dienstes
- hash&URL-Server
- Registrierungsserver
- Remote-Managementserver
- DNS_ROOT_ANCHOR_URL (benötigte IP-Adressen um den DNSSEC Trust Anchor im Namensraum Internet zu verifizieren)
- [19] vom Konnektor kommend zu den folgenden Systemen für das Protokoll DNS
-
- beliebige Hosts
- beliebige Hosts
- [20a] blockieren, wenn (ANLW_INTERNET_MODUS=KEINER oder MGM_LU_ONLINE=Disabled ) von „Aktive Komponenten“ kommend
- [20b] mittels ICMP Redirect gemäß [RFC792] zum Default Gateway umleiten, wenn die Zieladresse des IP-Pakets nicht innerhalb der Adressbereiche (NET_TI_ZENTRAL, NET_TI_OFFENE_FD, NET_TI_GESICHERTE_FD und ANLW_AKTIVE_BESTANDSNETZE) ist und ANLW_INTERNET_MODUS=IAG und von „Aktive Komponenten“ kommend.
- [21] blockieren, wenn von IAG kommend in Richtung Konnektor (und die dahinterliegenden „Aktive Komponenten“)
TIP1-A_4737 - Kommunikation mit „Aktive Komponenten“
Der Konnektor MUSS sicherstellen, dass ausgehende IP-Pakete für die Kommunikation mit „Aktive Komponenten“ mit einer Absenderadresse ungleich ANLW_LAN_IP_ADDRESS, einer Adresse aus einem Netzwerksegment in ANLW_LEKTR_INTRANET_ROUTES oder 0.0.0.0 verworfen werden.
Der Konnektor MUSS die Kommunikation mit „Aktive Komponenten“ für folgende Fälle unterstützen:
[22] auf den Konnektor (mittels der Schnittstelle Basisdienste)
[24] vom Konnektor kommend
Der Konnektor MUSS insbesondere die Kommunikation an seinen Außenschnittstellen mit „Aktive Komponenten“ für folgende Fälle blockieren:
[23] zum Konnektor eingehend (direkt – ohne eine der Schnittstellen Fachmodule oder Basisdienste zu nutzen)
TIP1-A_4738 - Route zum IAG
Der Konnektor MUSS die Kommunikation mit dem IAG der Einsatzumgebung für folgende Fälle unterstützen:
[26] wenn (ANLW_WAN_ADAPTER_MODUS=ENABLED) vom WAN-Adapter kommend
[27] wenn (ANLW_WAN_ADAPTER_MODUS=DISABLED) vom LAN-Adapter kommend
Der Konnektor MUSS insbesondere die Kommunikation an seinen Außenschnittstellen mit dem IAG der Einsatzumgebung für folgende Fälle blockieren:
[25] wenn (ANLW_WAN_ADAPTER_MODUS=ENABLED) zum WAN-Adapter eingehend
[28] wenn (ANLW_WAN_ADAPTER_MODUS=DISABLED) zum LAN-Adapter eingehend
TIP1-A_4740 - Admin Defined Firewall Rules
Die Firewall des Konnektor MUSS alle vom Administrator in ANLW_FW_SIS_ADMIN_RULES definierten Firewall-Regeln als zusätzliche Einschränkung übernehmen.
[<=]TIP1-A_4741 - Kommunikation mit dem Intranet
Der Konnektor MUSS die Kommunikation mit Systemen aus einem Intranet-VPN (einem der Netzwerksegmente ANLW_LEKTR_INTRANET_ROUTES) für folgende Fälle unterstützen:
[22] wenn von Aktive Komponenten aus dem Netzwerksegment ANLW_LEKTR_INTRANET_ROUTES kommend zum Konnektor mittels der Schnittstelle Basisdienste
[24] wenn vom Konnektor kommend zu ANLW_LEKTR_INTRANET_ROUTES
Der Konnektor MUSS insbesondere die Kommunikation an seinen Außenschnittstellen mit einem der Intranet Netzwerksegmente für folgende Fälle blockieren bzw. umleiten:
[29a] blockieren, wenn (ANLW_INTRANET_ROUTES_MODUS=BLOCK) vom „Aktive Komponenten“ kommend;
[29b] umleiten, wenn (ANLW_INTRANET_ROUTES_MODUS=REDIRECT) vom „Aktive Komponenten“ kommend;
Der Konnektor MUSS an ANLW_LEKTR_INTRANET_ROUTES gerichtete IP-Pakete gemäß [RFC792] umleiten (ICMP Redirect).
TIP1-A_4742 - Kommunikation mit den Fachmodulen
Der Konnektor MUSS die Kommunikation mit den Fachmodulen für folgende Fälle unterstützen:
[30] von „Aktive Komponenten“ über Schnittstelle Fachmodule
Der Konnektor MUSS insbesondere die Kommunikation an seinen Außenschnittstellen mit den Fachmodulen für folgende Fälle blockieren:
[31] zu „Aktive Komponenten“
[32] zu den Netzwerksegmenten, NET_TI_ZENTRAL, NET_TI_DEZENTRAL, ANLW_AKTIVE_BESTANDSNETZE, Internet (via SIS), Internet (via IAG) und Intranet
TIP1-A_4744 - Firewall - Drop statt Reject
Die Firewall des Konnektor MUSS alle abgelehnten IP-Pakete verwerfen (DROP) ohne ein ICMP-Destination-Unreachable (Type 3) zu schicken.
[<=]TIP1-A_4746 - Firewall – Abwehr von IP-Spoofing, DoS/DDoS-Angriffe und Martian Packets
Der Konnektor MUSS geeignete technische Funktionen zur Abwehr von IP-Spoofing und DoS/DDoS-Angriffen implementieren.
Der Konnektor MUSS Martian Packets (Absender– oder Empfängeradressen aus den von der IETF als Special-Purpose definierten Netzbereichen), mindestens jedoch aus folgenden Netzbereichen 0.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, 192.0.0.0/24, 192.0.2.0/24, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24, 224.0.0.0/4, 240.0.0.0/4 verwerfen. Die in [RFC1918] und [RFC 6598] definierten Netzbereiche sind hiervon ausgenommen.
[<=]TIP1-A_4745 - Eingeschränkte Nutzung von „Ping“
Die Firewall des Konnektor MUSS TCP-Port-7(Echo)-Pakete verwerfen.
Die Firewall des Konnektor MUSS ICMP-Echo-Request (Typ 8) und ICMP-Echo-Response (Typ 0) ausschließlich für die folgenden Kommunikationen zulassen:
- vom Konnektor zu den VPN-Konzentratoren für SIS und TI über das Transportnetz (via IAG)
- vom Konnektor zu dem CRL-Webservern (im Transportnetz) über das Internet (via SIS) und das Transportnetz (via IAG)
- vom Konnektor zu dem IAG der Einsatzumgebung
- vom Konnektor zu NET_TI_ZENTRAL
- vom Konnektor zu NET_TI_GESICHERTE_FD
- vom Konnektor zu NET_TI_OFFENE_FD
- vom Konnektor zum lokalen Netzwerk (Adressen aus ANLW_LAN_NETWORK_SEGMENT oder Adressen aus einem der Netzwerksegmente in ANLW_LEKTR_INTRANET_ROUTES)
- vom lokalen Netzwerk (Adressen aus ANLW_LAN_NETWORK_SEGMENT (jedoch ohne die ANLW_LAN_IP_ADDRESS) oder Adressen aus einem der Netzwerksegmente in ANLW_LEKTR_INTRANET_ROUTES) zum Konnektor
- vom lokalen Netzwerk in ANLW_AKTIVE_BESTANDSNETZE (die freigegebenen angeschlossenen Netze des Gesundheitswesens mit WANDA Basic)
- vom lokalen Netzwerk in das Internet (via SIS)
TIP1-A_4747 - Firewall – Einschränkungen der IP-Protokolle
Der Konnektor MUSS alle IP-Protokolle außer 1 (ICMP), 4 (IP in IP (encapsulation)), 17 (UDP), 6 (TCP), 50 (ESP) und 108 (IPComp) für alle ein- oder ausgehenden Pakete an allen seinen Adaptern verwerfen.
[<=]TIP1-A_4748 - Firewall – Routing-Regeln
Der Konnektor DARF seine Routing-Regeln NICHT durch IP-Kommunikation beeinflussen lassen, weder mittels eines Routing-Protokolls (wie BGP oder RIP) noch mittels ICMP-Kommandos (wie Redirect (5), Router Advertisement (9/10) oder auch Mobile Host Redirect (32)) sondern MUSS diese ausschließlich durch TUC_KON_304 „Netzwerk-Routen einrichten“ setzen.
Die Firewall des Konnektor MUSS alle aus einem der Tunnel (VPN_TI oder VPN_SIS) kommenden DHCP-Pakete verwerfen.
Die Firewall des Konnektors MUSS an den Konnektor gerichtete IPsec-Pakete (IKE, ESP und IPsec NAT-T) verwerfen, sofern sie nicht einer vom Konnektor initiierten IPsec-Verbindung (VPN_TI und VPN_SIS) zugeordnet werden können.
[<=]TIP1-A_4749 - Firewall Restart
Der Konnektor MUSS gewährleisten, dass unmittelbar nach einer Änderung der Parameter eines Adapters (LAN-Adapter, WAN-Adapter, virtueller Adapter VPN_TI oder virtueller Adapter VPN_SIS) die Firewall des Konnektor neu erstellt und geladen wird.
Wenn der WAN-Adapter verwendet wird (ANLW_WAN_ADAPTER_MODUS=ENABLED) DARF die Firewall des Konnektor bei einer Änderung der ANLW_WAN_IP_ADDRESS NICHT die Verbindungen über den LAN-Adapter durch einen Restart der Firewall beeinflussen.
Wenn der WAN-Adapter verwendet wird (ANLW_WAN_ADAPTER_MODUS=ENABLED), DARF die Firewall des Konnektor bei einer Änderung der ANLW_LAN_IP_ADDRESS NICHT die Verbindungen über die Adapter WAN, VPN_TI oder VPN_SIS durch einen Restart der Firewall beeinflussen.
[<=]Umsetzungshinweis für den Hersteller: Es können zwei getrennten Firewall-Regelsets für den LAN- bzw. für den WAN-Adapter verwendet werden.
TIP1-A_4750 - Firewall-Protokollierung
Der Konnektor MUSS bei Start und Stopp der Firewall einen Protokolleintrag mit der Schwere „Warning“ und dem Typ „Operations“ sowie mindestens folgenden Informationen generieren:
Zeitstempel, Aktion (Start/Stop), Ergebnis (Erfolg/Fehler), Auslöser (Prozess/User)
Der Konnektor MUSS bei Konfigurationsänderungen der Firewall einen Protokolleintrag mit der Schwere „Warning“ und dem Typ „Operations“ sowie mindestens folgenden Informationen generieren:
Zeitstempel, Aktion (Add/Delete/Change), Details (Beschreibung der Änderung), Auslöser (Prozess/User)
Der Konnektor MUSS für alle vom Konnektor ausgehenden, nicht zugelassenen Kommunikationsversuche einen Protokolleintrag mit der Schwere „Warning“ und dem Typ „Security“ sowie mindestens folgenden Informationen generieren:
Zeitstempel, Aktion (Drop, Reject), Absender-IP-Adresse, Empfänger-IP-Adresse, Protokoll, Absender-Port und Empfänger-Port, Interface über das das Paket empfangen wurde
Der Konnektor MUSS für alle verworfenen IP-Spoofing- und Martian-Packets einen Protokolleintrag mit der Schwere „Warning“ und dem Typ „Security“ sowie mindestens folgenden Informationen generieren:
Zeitstempel, Aktion (Drop, Reject), Absender-IP-Adresse, Empfänger-IP-Adresse, Protokoll, Absender-Port und Empfänger-Port, Interface über das das Paket empfangen wurde
Der Konnektor MUSS für alle von der Firewall verworfenen IP-Pakete einen Protokolleintrag mit der Schwere „Info“ und dem Typ „Security“ sowie mindestens folgenden Informationen generieren, wobei Layer 3 Broadcasts von der Protokollierung ausgenommen werden können:
Zeitstempel, Aktion (Drop, Reject), Absender-IP-Adresse, Empfänger-IP-Adresse, Protokoll, Absender-Port und Empfänger-Port, Interface über das das Paket empfangen wurde
Der Konnektor MUSS für die Firewall-Protokollierung den TUC_KON_271 „Schreibe Protokolleintrag“ nutzen.
[<=]4.2.1.2 Durch Ereignisse ausgelöste Reaktionen
TIP1-A_4751 - Reagiere auf LAN_IP_Changed
Beim Auftreten eines der nachfolgenden Events MUSS der Konnektor den TUC_KON_305 „LAN-Adapter initialisieren“ starten.
Event ANLW/LAN/IP_CHANGED
Event DHCP/LAN_CLIENT/RENEW
TIP1-A_4752 - Reagiere auf WAN_IP_Changed
Beim Auftreten eines der nachfolgenden Events MUSS der Konnektor TUC_KON_306 „WAN-Adapter initialisieren“ starten.
- Event ANLW/WAN/IP_CHANGED
- Event DHCP/WAN_CLIENT/RENEW
TIP1-A_4753 - Ereignisbasiert Netzwerkrouten einrichten
Beim Auftreten eines der nachfolgenden Events MUSS der Konnektor den TUC_KON_304 „Netzwerk-Routen einrichten“ aufrufen.
Event NETWORK/VPN_TI/UP
Event NETWORK/VPN_TI/DOWN
Event NETWORK/VPN_SIS/UP
Event NETWORK/VPN_SIS/DOWN
Event MGM/LU_CHANGED/LU_ONLINE
4.2.1.3 Interne TUCs, nicht durch Fachmodule nutzbar
4.2.1.3.1 TUC_KON_305 „LAN-Adapter initialisieren“
TIP1-A_4754 - TUC_KON_305 „LAN-Adapter initialisieren“
Der Konnektor MUSS den technischen Use Case TUC_KON_305 „LAN-Adapter initialisieren“ umsetzen.
Tabelle 313: TAB_KON_614 - TUC_KON_305 „LAN-Adapter initialisieren“
Element |
Beschreibung |
---|---|
Name |
TUC_KON_305 LAN-Adapter initialisieren |
Beschreibung |
Initialisieren der LAN-Netzwerkschnittstelle |
Auslöser |
|
Vorbedingungen |
|
Eingangsdaten |
Keine |
Komponenten |
Konnektor |
Ausgangsdaten |
Keine |
Standardablauf |
1) Die in „Tabelle TAB_KON_683 LAN-Adapter IP-Konfiguration„ und „Tabelle TAB_KON_684 LAN-Adapter Erweiterte Parameter „ gesetzten Werte sind zur Konfiguration des LAN-Adapter zu verwenden. 2) Rufe TUC_KON_304 „Netzwerk-Routen einrichten“ 3) Wenn (ANLW_WAN_ADAPTER_MODUS = DISABLED) und MGM_LU_ONLINE = ENABLED:
|
Varianten/ Alternativen |
Keine |
Fehlerfälle |
( 1) Fehlerhafte LAN IP-Konfiguration; 4162 ( 4) Beim Aktualisieren oder Aktivieren der Firewall-Regeln ist es zu einem Fehler gekommen; 4164 |
Nichtfunktionale Anforderungen |
Keine |
Zugehörige Diagramme |
Keine |
Tabelle 314: TAB_KON_615 Fehlercodes TUC_KON_305 „LAN-Adapter initialisieren“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4162 |
Technical |
Error |
Es liegt eine fehlerhafte LAN IP-Konfiguration vor. |
4164 |
Technical |
Fatal |
Beim Aktualisieren oder Aktivieren der Firewall-Regeln ist es zu einem Fehler gekommen. |
4.2.1.3.2 TUC_KON_306 „WAN-Adapter initialisieren“
TIP1-A_4755 - TUC_KON_306 „WAN-Adapter initialisieren“
Der Konnektor MUSS den technischen Use Case TUC_KON_306 „WAN-Adapter initialisieren“ umsetzen.
Tabelle 315: TAB_KON_616 - TUC_KON_306 „WAN-Adapter initialisieren“
Element |
Beschreibung |
---|---|
Name |
TUC_KON_306 WAN-Adapter initialisieren |
Beschreibung |
Initialisieren der WAN-Netzwerkschnittstelle |
Auslöser |
|
Vorbedingungen | |
Eingangsdaten |
Keine |
Komponenten |
Konnektor |
Ausgangsdaten |
Keine |
Standardablauf |
1) Wenn ANLW_WAN_ADAPTER_MODUS = DISABLED oder MGM_LU_ONLINE = Disabled: a) Aktive VPN-Tunnel TI oder SIS (VPN_TI oder VPN_SIS) müssen gestoppt werden, 2) Wenn ANLW_WAN_ADAPTER_MODUS = ENABLED und MGM_LU_ONLINE = ENABLED: a) Der WAN-Adapter wird abhängig von DHCP_CLIENT_WAN_STATE statisch oder dynamisch über DHCP konfiguriert. Die in „Tabelle TAB_KON_685 WAN-Adapter IP-Konfiguration„ und „Tabelle TAB_KON_686 WAN-Adapter Erweiterte Parameter„ gesetzten Werte sind zur Konfiguration des WAN-Adapter zu verwenden. b) Rufe TUC_KON_304 „Netzwerk-Routen einrichten“ c) Rufe TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen“. d) Rufe TUC_KON_322 „Verbindung zu dem VPN-Konzentrator des SIS aufbauen“ e) Firewall-Regeln aktualisieren und aktivieren. Tritt der Fehler 4164 auf, geht der Konnektor in den Betriebszustand EC_Firewall_Not_Reliable über. |
Varianten/ Alternativen |
Keine |
Fehlerfälle |
( 1) Fehlerhafte WAN IP-Konfiguration; 4163 ( 2) Beim Aktualisieren oder Aktivieren der Firewall-Regeln ist es zu einem Fehler gekommen; 4164 |
Nichtfunktionale Anforderungen |
Keine |
Tabelle 316: TAB_KON_617 Fehlercodes TUC_KON_306 „WAN-Adapter initialisieren“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4163 |
Technical |
Error |
Es liegt eine fehlerhafte WAN-IP-Konfiguration vor. |
4164 |
Technical |
Fatal |
Beim Aktualisieren oder Aktivieren der Firewall-Regeln ist es zu einem Fehler gekommen. |
4.2.1.3.3 TUC_KON_304 „Netzwerk-Routen einrichten“
TIP1-A_4758 - TUC_KON_304 „Netzwerk-Routen einrichten“
Der Konnektor MUSS den technischen Use Case TUC_KON_304 „Netzwerk-Routen einrichten“ umsetzen.
Tabelle 317: TAB_KON_622 - TUC_KON_304 „Netzwerk-Routen einrichten“
Element |
Beschreibung |
Name |
TUC_KON_304 Netzwerk-Routen einrichten |
Beschreibung |
Anpassen der Routing-Tabelle |
Auslöser |
|
Vorbedingungen |
keine |
Eingangsdaten |
|
Komponenten |
Konnektor |
Ausgangsdaten |
Keine |
Nachbedingungen |
|
Standardablau |
Alle bestehenden Routen MÜSSEN vollständig durch die in diesem TUC ermittelten Routen ersetzt werden. 1) Wenn (MGM_LU_ONLINE=Enabled) Der Konnektor MUSS die nachfolgenden Routen bereitstellen i. Ziel: Lokale Netze der Einsatzumgebung gemäß ANLW_LEKTR_INTRANET_ROUTES Next Hop: gemäß ANLW_LEKTR_INTRANET_ROUTES b) Wenn die VPN-Tunnel zur TI und zum SIS nicht aufgebaut sind: i. Ziel: Default Route Next Hop: ANLW_IAG_ADDRESS c) Wenn der VPN-Tunnel zur TI aufgebaut und der VPN-Tunnel zum SIS nicht aufgebaut sind: i. Ziel: Default Route Next Hop: ANLW_IAG_ADDRESS ii. Ziel: TI (NET_TI_OFFENE_FD, NET_TI_GESICHERTE_FD und NET_TI_ZENTRAL) Next Hop: Innere Tunnel IP-Adresse des VPN- Konzentrators TI iii. Ziel: ANLW_AKTIVE_BESTANDSNETZE Next Hop: Innere Tunnel IP-Adresse des VPN- Konzentrators TI iv. Ziel: VPN-Konzentrator TI Next Hop: ANLW_IAG_ADDRESS aufgebaut sind: i. Ziel: Default Route Next Hop: Innere Tunnel IP-Adresse des VPN- Konzentrators SIS ii. Ziel: TI (NET_TI_OFFENE_FD, NET_TI_GESICHERTE_FD und NET_TI_ZENTRAL) Next Hop: Innere Tunnel IP-Adresse des VPN- Konzentrators TI iii. Ziel: ANLW_AKTIVE_BESTANDSNETZE Next Hop: Innere Tunnel IP-Adresse des VPN- Konzentrators TI iv. Ziel: VPN-Konzentrator TI Next Hop: ANLW_IAG_ADDRESS v. Ziel: VPN-Konzentrator SIS Next Hop: ANLW_IAG_ADDRESS Hinweis: Wenn der VPN-Tunnel zur TI nicht existiert, kann auch kein VPN-Tunnel zum SIS existieren, da die Default Route zum IAG zeigen muss, um einen VPN-Tunnel zur TI aufbauen zu können. 2) Wenn (MGM_LU_ONLINE=Disabled) 1. Der Konnektor MUSS die nachfolgenden Routen bereitstellen. i. Ziel: Lokale Netze der Einsatzumgebung gemäß ANLW_LEKTR_INTRANET_ROUTES Next Hop: gemäß ANLW_LEKTR_INTRANET_ROUTES 3) Firewall aktualisieren: Die Firewall des Konnektors MUSS die neu eingerichteten Routen berücksichtigen und seine Regeln entsprechend aktualisieren und aktivieren. Tritt der Fehler 4164 auf, geht der Konnektor in den Betriebszustand EC_Firewall_Not_Reliable über. |
Varianten/Alternativen |
Keine |
Fehlerfälle |
( 1-2) Eine oder mehrere Variablen enthalten eine ungültige oder keine IP; 4167 ( 3) Beim Aktualisieren oder Aktivieren der Firewall-Regeln ist es zu einem Fehler gekommen; 4164 |
Nichtfunktionale Anforderungen |
Keine |
Zugehörige Diagramme |
Keine |
Tabelle 318: TAB_KON_623 Fehlercodes TUC_KON_304 „Netzwerk-Routen einrichten“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4167 |
Technical |
Fatal |
CreateRoutes: Ein oder mehrere Adressen sind ungültig. |
4164 |
Technical |
Fatal |
Beim Aktualisieren oder Aktivieren der Firewall-Regeln ist es zu einem Fehler gekommen. |
[<=]
4.2.1.4 Interne TUCs, auch durch Fachmodule nutzbar
Keine.
4.2.1.5 Operationen an der Außenschnittstelle
Keine
4.2.1.6 Betriebsaspekte
TIP1-A_5414 - Initialisierung „Anbindung LAN/WAN“
Der Konnektor MUSS in der Bootup-Phase zur Initialisierung des Funktionsmerkmals „Anbindung LAN/WAN“:
-
den LAN-Adapter initialisieren (TUC_KON_305)
den WAN-Adapter initialisieren (TUC_KON_306)
die Infrastrukturdaten vom KSR einlesen (TUC_KON_283)
TIP1-A_4759 - Konfiguration LAN-Interface
Der Konnektor MUSS gewährleisten, dass die Konfiguration nur dann gespeichert wird, wenn alle Parameter der nachfolgenden Tabellen den dazugehörigen Bedingungen entsprechen, sowie grundsätzlich zulässige Werte darstellen (gemäß RFCs).
Wenn die Konfiguration per Managementschnittstelle geändert wurde, MUSS das folgende Systemereignis ausgelöst werden:
TUC_KON_256 {
topic = "ANLW/LAN/IP_CHANGED";
eventType = Op;
severity = Info;
parameters = („IP=$dieNeueIP”);
doDisp = false}
Wenn (DHCP_CLIENT_LAN_STATE=Disabled) gesetzt ist, MUSS der Administrator des Konnektor die Werte der folgenden Tabelle über die Managementschnittstelle setzen können.
Wenn (DHCP_CLIENT_LAN_STATE=Enabled) gesetzt ist, MUSS der Administrator des Konnektor die Werte der folgenden Tabelle angezeigt bekommen, kann diese jedoch nicht ändern.
Tabelle 319: TAB_KON_683 LAN-Adapter IP-Konfiguration
ReferenzID |
Belegung |
Bedeutung und Administrator-Interaktion |
---|---|---|
ANLW_LAN_IP_ ADDRESS |
IP-Adresse |
Dies ist die IP-Adresse des LAN-Adapters. Nur wenn DHCP_CLIENT_LAN_STATE=Disabled MUSS der Administrator die LAN-seitige IP-Adresse des Konnektors setzen können. Diese IP-Adresse MUSS innerhalb des ANLW_LAN_NETWORK_SEGMENT liegen. |
ANLW_LAN_ SUBNETMASK |
Subnetzmaske |
Dies ist die zu ANLW_LAN_IP_ADDRESS gehörende Subnetzmaske. Der Administrator MUSS die Subnetzmaske setzen können. Der Konnektor MUSS gewährleisten das nur eine gültige Subnetzmaske gespeichert werden kann. |
ANLW_LAN_ NETWORK_ SEGMENT |
IP-Adresse / Subnetzmaske |
ANLW_LAN_NETWORK_SEGMENT ist ein Zustandswert, der sich aus den Werten von ANLW_LAN_IP_ADDRESS und ANLW_LAN_SUBNETMASK ergibt. Der Wert bezeichnet ein lokales Netzwerk in der Umgebung des Anwenders an das der LAN-Adapter des Konnektors angeschlossen ist. Der Konnektor MUSS gewährleisten, das das Netzwerksegment NICHT mit einem der folgenden Netzwerksegmente überlappt: 1. NET_TI_DEZENTRAL 2. NET_TI_ZENTRAL 3. NET_TI_OFFENE_FD 4. NET_TI_GESICHERTE_FD 5. NET_SIS 6. ANLW_BESTANDSNETZE 7. ANLW_AKTIVE_BESTANDSNETZE 8. ANLW_WAN_NETWORK_SEGMENT 9. ANLW_LEKTR_INTRANET_ROUTES |
Tabelle 320: TAB_KON_684 LAN-Adapter Erweiterte Parameter
ReferenzID |
Belegung |
Bedeutung und Administrator-Interaktion |
---|---|---|
ANLW_LAN_MTU |
Nummer |
Der Administrator MUSS Maximum Transmission Unit (MTU) setzen können. Der Konnektor MUSS sicherstellen, das der konfigurierte Wert in den Grenzen von 576 bis 9000 liegt. Default-Wert: 1400 |
ANLW_LAN_PARAMETER |
Liste von IP, UDP und/oder TCP Parametern |
Der Administrator SOLL weitere Konfigurationsparameter gemäß [gemSpec_Net#2.2.2.1,2.5] konfigurieren können. |
[<=]
TIP1-A_4760 - Konfiguration WAN-Interface
Der Konnektor MUSS gewährleisten, dass die Konfiguration nur dann gespeichert wird, wenn alle Parameter der nachfolgenden Tabellen den dazugehörigen Bedingungen entsprechen.
Wenn die Konfiguration per Managementschnittstelle geändert wurde, MUSS das folgende Systemereignis ausgelöst werden:
TUC_KON_256 {
topic = "ANLW/WAN/IP_CHANGED";
eventType = Op;
severity = Info;
parameters = („IP=$dieNeueIP“);
doDisp = false}
Wenn (DHCP_CLIENT_WAN_STATE=Disabled) gesetzt ist, MUSS der Administrator des Konnektors die Werte der folgenden Tabelle über die Managementschnittstelle setzen können.
Wenn (DHCP_CLIENT_WAN_STATE=Enabled) gesetzt ist, MUSS der Administrator des Konnektors die Werte der folgenden Tabelle angezeigt bekommen, kann diese jedoch nicht ändern.
Tabelle 321: TAB_KON_685 WAN-Adapter IP-Konfiguration
ReferenzID |
Belegung |
Bedeutung und Administrator-Interaktion |
---|---|---|
ANLW_WAN_ IP_ADDRESS |
IP-Adresse |
Dies ist die IP-Adresse des WAN-Adapters. Nur wenn DHCP_CLIENT_WAN_STATE=Disabled und ANLW_WAN_ADAPTER_MODUS=ENABLED MUSS der Administrator die WAN-seitige IP-Adresse des Konnektors setzen können. Diese IP-Adresse MUSS innerhalb des ANLW_WAN_NETWORK_SEGMENT liegen. |
ANLW_WAN_ SUBNETMASK |
Subnetzmaske |
Dies ist die zu ANLW_WAN_IP_ADDRESS gehörende Subnetzmaske. Der Administrator MUSS die Subnetzmaske setzen können. Der Konnektor MUSS gewährleisten, dass nur eine gültige Subnetzmaske gespeichert werden kann. |
ANLW_WAN_ NETWORK_ SEGMENT |
IP-Adresse / Subnetzmaske |
ANLW_WAN_NETWORK_SEGMENT ist ein Zustandswert, der sich aus den Werten von ANLW_WAN_IP_ADDRESS und ANLW_WAN_SUBNETMASK ergibt. Der Wert bezeichnet ein lokales Netzwerk in der Umgebung des Anwenders an das der WAN-Adapter des Konnektors angeschlossen ist. Der Konnektor MUSS gewährleisten, dass das Netzwerksegment nicht mit einem der folgenden Netzwerksegmente überlappt: 1. NET_TI_DEZENTRAL 2. NET_TI_ZENTRAL 3. NET_TI_OFFENE_FD 4. NET_TI_GESICHERTE_FD 5. NET_SIS 6. ANLW_ BESTANDSNETZE 7. ANLW_AKTIVE_BESTANDSNETZE 8. ANLW_LAN_NETWORK_SEGMENT 9. ANLW_LEKTR_INTRANET_ROUTES |
Tabelle 322: TAB_KON_686 WAN-Adapter Erweiterte Parameter
ReferenzID |
Belegung |
Bedeutung und Administrator-Interaktion |
---|---|---|
ANLW_WAN_MTU |
Nummer |
Der Administrator MUSS Maximum Transmission Unit (MTU) setzen können. Der Konnektor MUSS sicherstellen, das der konfigurierte Wert in den Grenzen von 576 bis 9000 liegt. Default-Wert: 1400 |
ANLW_WAN_PARAMETER |
Liste von IP, UDP und/oder TCP Parametern |
Der Administrator SOLL weitere Konfigurationsparameter gemäß [gemSpec_Net#2.2.2.1,2.5] konfigurieren können. |
[<=]
TIP1-A_4761 - Konfiguration Anbindung LAN/WAN
Die Managementschnittstelle MUSS es einem Administrator ermöglichen Konfigurationsänderungen gemäß Tabelle TAB_KON_624 – „Konfigurationsparameter der Anbindung LAN/WAN vorzunehmen.
Wenn (ANLW_INTRANET_ROUTES_MODUS = REDIRECT) gesetzt ist, MUSS der Konnektor jedes Paket aus einem konfigurierten Intranet mit einem ICMP-Redirect mit dem hinterlegten Next Hop beantworten und der Konnektor MUSS gewährleisten, dass keine IP-Pakete in eines oder mehrere der konfigurierten Intranet geroutet werden.
Wenn (ANLW_INTRANET_ROUTES_MODUS = BLOCK) gesetzt ist, MUSS der Konnektor alle IP-Pakete für ein Intranet (gemäß ANLW_LEKTR_INTRANET_ROUTES) ablehnen.
Tabelle 323: TAB_KON_624 – „Konfigurationsparameter der Anbindung LAN/WAN“
ReferenzID |
Belegung |
Bedeutung und Administrator-Interaktion |
---|---|---|
ANLW_ ANBINDUNGS_ MODUS |
InReihe |
Der Konnektor ist in Reihe zu dem IAG der Einsatzumgebung geschaltet. Wenn ANLW_WAN_ADAPTER_MODUS= ENABLED befindet sich der Konnektor in diesem Anbindungsmodus. Der Administrator MUSS diesen Wert einsehen und DARF ihn NICHT ändern können. |
Parallel |
Der Konnektor ist parallel (zu allen bestehenden Systemen) ins Netzwerk der Einsatzumgebung angebunden. Wenn ANLW_WAN_ADAPTER_MODUS= DISABLED befindet sich der Konnektor in diesem Anbindungsmodus. Der Administrator MUSS diesen Wert einsehen und DARF ihn NICHT ändern können. |
|
ANLW_ INTERNET_ MODUS |
SIS |
Der (am Konnektor LAN-seitig ankommende) Internet-Traffic wird per VPN an den SIS geschickt. |
IAG |
Bei Anfragen ins Internet wird der Aufrufer per ICMP-Redirect (Type 5) auf die Route zum IAG verwiesen. Wenn (ANLW_ANBINDUNGS_MODUS = InReihe) DARF dieser Wert NICHT auswählbar sein - statt dessen MUSS dann der Wert SIS verwendet werden. |
|
KEINER |
Es wird kein Traffic ins Internet geroutet |
|
ANLW_ INTRANET_ ROUTES_ MODUS |
REDIRECT |
Der Konnektor MUSS sicherstellen, dass dieser Wert nur gesetzt werden kann, wenn der Administrator zuvor ein oder mehrere Intranet (ANLW_LEKTR_INTRANET_ROUTES) definiert hat. |
BLOCK |
Der Konnektor MUSS alle IP-Pakete für ein Intranet (gemäß ANLW_LEKTR_INTRANET_ROUTES) ablehnen. |
|
ANLW_WAN_ ADAPTER_ MODUS |
ENABLED |
Dieser Parameter ändert den Interface-Status des WAN-Adapters. Der Administrator MUSS diesen Wert einsehen können. Der Administrator MUSS diesen Wert ändern können. |
DISABLED |
Dieser Parameter ändert den Interface-Status des WAN-Adapters. Der Administrator MUSS diesen Wert einsehen können. Der Administrator MUSS diesen Wert ändern können. |
|
ANLW_ LEKTR_ INTRANET_ ROUTES |
Tupel aus Netzwerksegment und dazugehörigem Next-Hop |
Der Administrator MUSS in diese Liste Einträge hinzufügen, editieren und löschen können. Liste von Routen zur Erreichung der Clientsysteme und Kartenterminals vom Konnektor; jeweils mit IP-Netzwerk dazugehörigem Next Hop. Die Netzwerksegmente DÜRFEN NICHT mit den Netzbereichen
|
ANLW_IAG_ ADDRESS |
IP Adresse |
ANLW_IAG_ADDRESS ist die Adresse des Default Gateways. Diese IP-Adresse MUSS innerhalb des ANLW_WAN_NETWORK_SEGMENT liegen. Die Adresse wird entweder über DHCP automatisch (DHCP_CLIENT_WAN_STATE=ENABLED oder DHCP_CLIENT_LAN_STATE=ENABLED) oder anderenfalls manuell durch den Administrator konfiguriert. Bei automatischer Konfiguration per DHCP MUSS der Administrator den Wert von ANLW_IAG_ADDRESS ausschließlich einsehen können. |
ANLW_ AKTIVE_ BESTANDS NETZE |
Liste von IP-Address-Segmenten |
Der Administrator MUSS manuell aus der empfangenen Liste der zur Verfügung stehenden angeschlossene Netze des Gesundheitswesens mit WANDA Basic (gemäß TUC_KON_283 „Infrastruktur Konfiguration aktualisieren“) einzelne deaktivieren, bzw. nach vorheriger Deaktivierung, freischalten können. Nur die freigegeben Netze werden in dieser Variablen erfasst und sind aus den Netzwerken der Einsatzumgebung erreichbar. Wird eine Änderung an der Liste der freigegebenen Netze vorgenommen, so MUSS der Konnektor für jedes dieser freigegebenen Netz in DNS_SERVERS_BESTANDSNETZE ein DNS-Referer-Eintrag für jede der dazugehörigen Domains mit allen zugehörigen DNS-Servern im Konnektor hinterlegen. Die Werte hierzu werden der via TUC_KON_283 aktualisierten Bestandsnetze.xml entnommen. Für hier „nicht freigegebene“ oder zwischenzeitlich gelöschte Netze DARF der Konnektor NICHT Referer-Einträge in DNS_SERVERS_BESTANDSNETZE enthalten. Die Einträge in DHCP_AKTIVE_BESTANDSNETZE_ROUTES sind entsprechend zu aktualisieren. Der Konnektor MUSS nach jeder Änderung dieser Variablen durch den Administrator den TUC_KON_304 „Netzwerk-Routen einrichten“ aufrufen. |
ANLW_ IA_ BESTANDSNETZE |
AN |
Der Konnektor MUSS alle über TUC_KON_283 übermittelten angeschlossenen Netze des Gesundheitswesens mit WANDA Basic aktivieren. Eine spätere manuelle Deaktivierung über das Management-Interface durch den Administrator ist möglich. Dieses Verhalten ist als Standardverhalten zu konfigurieren. |
AUS |
Der Konnektor MUSS alle über TUC_KON_283 übermittelten angeschlossenen Netze des Gesundheitswesens mit WANDA Basic anbieten, diese aber nicht aktivieren. Eine spätere manuelle Aktivierung erfolgt über das Mangement-Interface durch den Administrator. |
[<=]
TIP1-A_5537 - Anzeige IP-Routinginformationen
Der Konnektor MUSS über die Managmentschnittstelle die konfigurierten IP-Routen und die aktuelle IP-Routingtabelle mit mindestens folgenden Informationen anzeigen:
Forwarding Status
Zieladresse/Prefix
Gateway (Next-Hop)
Routing Typ
Routing Protocol
Routing Preference.
TIP1-A_4762 - Konfigurationsparameter Firewall-Schnittstelle
Im Anschluss an eine Anpassung der ANLW_FW_SIS_ADMIN_RULES MUSS der Konnektor die Firewall neu erstellen und laden.
Tabelle 324: TAB_KON_625 - Konfigurationsparameter Firewall-Schnittstelle
ReferenzID |
Belegung |
Bedeutung und Administrator-Interaktion |
---|---|---|
ANLW_FW_SIS_ ADMIN_RULES |
Firewall Regelset |
Der Administrator MUSS Firewall-Regeln (für den einschränkenden Zugriff auf die SIS), auf Grundlage der Parameter Absender-IP-Adresse, Empfänger-IP-Adresse, Protokoll (ggf. mit Absender-Port und Empfänger-Port) und Verbindungsrichtung, einfügen, editieren und löschen können. |
[<=]
4.2.2 DHCP-Server
Innerhalb des Kapitels DHCP-Servers werden folgende Präfixe für Bezeichner verwendet:
- Events (Topic Ebene 1): „DHCP“
- Konfigurationsparameter: „DHCP_SERVER_“
4.2.2.1 Funktionsmerkmalweite Aspekte
TIP1-A_4763 - DHCP-Server des Konnektors
Der Konnektor MUSS an seiner LAN-Schnittstelle einen DHCP-Server gemäß [RFC2131] und [RFC2132] anbieten.
[<=]4.2.2.2 Durch Ereignisse ausgelöste Reaktionen
Keine.
4.2.2.3 Interne TUCs, nicht durch Fachmodule nutzbar
Keine.
4.2.2.4 Interne TUCs, auch durch Fachmodule nutzbar
Keine.
4.2.2.5 Operationen an der Außenschnittstelle
4.2.2.5.1 Liefere Netzwerkinformationen über DHCP
TIP1-A_4765 - Liefere Netzwerkinformationen über DHCP
Der DHCP-Server des Konnektors MUSS an der Client-Schnittstelle eine Operation zur Lieferung von Netzwerkinformationen über DHCP anbieten.
Tabelle 325: TAB_KON_626 „Liefere Netzwerkinformationen über DHCP“
Name |
Liefere Netzwerkinformationen über DHCP |
---|---|
Beschreibung |
Der Konnektor MUSS anfragenden Clients per DHCP die konfigurierten Netwerkinformationen liefern (siehe Tabelle TAB_KON_628 und Tabelle TAB_KON_629). |
Aufrufparameter | gemäß [RFC2131], [RFC2132] |
Rückgabe | gemäß [RFC2131], [RFC2132] |
Standardablauf |
Die an den aufrufenden Client zu übergebenden Parameter ergeben sich aus Tabelle TAB_KON_628 und Tabelle TAB_KON_629: Falls DHCP_SERVER_STATE = Enabled:
|
Fehlercodes |
Vgl. [RFC2131], [RFC2132] |
Vorbedingungen |
Der DHCP-Server des Konnektors MUSS aktiviert und konfiguriert sein. |
Nachbedingungen |
Der DHCP-Server MUSS die DHCP-Antwort geliefert haben. Die Statusinformationen (z.B. Client Lease) müssen gemäß [RFC2131] gespeichert werden. |
Hinweise |
Keine |
[<=]
4.2.2.6 Betriebsaspekte
TIP1-A_4766 - Deaktivierbarkeit des DHCP-Servers
Der DHCP- Server des Konnektors MUSS durch den Administrator über die Managementschnittstelle aktivierbar und deaktivierbar sein (gemäß TAB_KON_627). Der DHCP-Server MUSS bei der Auslieferung deaktiviert sein.
Bei der Aktivierung MUSS der Konnektor den TUC_KON_343 "Initialisierung DHCP-Server" durchlaufen.
Sobald DHCP_SERVER_STATE geändert wurde, muss TUC_KON_256{"DHCP/SERVER/STATECHANGED"; Op; Info; "STATE=$DHCP_SERVER_STATE "} aufgerufen werden.
Tabelle 326: TAB_KON_627 „Aktivierung des DHCP-Servers“
Referenz ID |
Belegung |
Bedeutung |
---|---|---|
DHCP_SERVER_STATE |
Enabled / Disabled |
Der DHCP-Server MUSS durch den Administrator aktivierbar und deaktivierbar sein. |
TIP1-A_4767 - Konfiguration des DHCP-Servers
Der Konnektor MUSS die Möglichkeit bieten die in Tabelle TAB_KON_628 und Tabelle TAB_KON_629 beschriebenen Parameter des DHCP-Servers über die Managementschnittstelle zu konfigurieren.
Tabelle 327: TAB_KON_628 „Basiskonfiguration des DHCP-Servers“
Referenz ID |
Belegung |
Bedeutung |
---|---|---|
DHCP_SERVER_NETWORK |
IP-Adresse |
IP-Netzwerk der Einsatzumgebung. |
DHCP_SERVER_BROADCAST |
IP-Adresse |
Die Broadcast-Adresse des Konnektors am LAN-Interface |
DHCP_SERVER_ DYNAMIC_RANGE |
von – bis IP-Adresse |
Adressbereich für Adressen die dynamisch vergeben werden dürfen. |
DHCP_SERVER_ CLIENTGROUPS |
Name der Clientgruppe; Liste an MAC-Adressen |
Der Konnektor MUSS dem Administrator über die Managementschnittstelle die Möglichkeit bieten mindestens zwei Client-Gruppen zu verwalten. |
DHCP_SERVER_ DEFAULT_CLIENTGROUP |
Client-Gruppe |
Standardmäßig eingestellte Client-Gruppe. Wird verwendet falls DHCP-Anfrage keiner anderen Client-Gruppe zugeordnet werden kann. |
Tabelle 328: TAB_KON_629 „Client-Gruppenspezifische Konfigurationsoptionen des Konnektor-DHCP-Servers“
ReferenzID |
Belegung |
Bedeutung |
---|---|---|
Die gesamte Parameterliste ist für jede Client-Gruppe getrennt konfigurierbar |
||
DHCP_ OWNDNS_ ENABLED |
Enabled/Disabled |
Der Administrator MUSS konfigurieren können, ob der konnektoreigene DNS-Server als Parameter übergeben wird. Default-Wert: Disabled |
DHCP_DNS_ ADDR |
IP-Adressen der DNS-Server |
Falls der konnektoreigene DNS-Server nicht übergeben werden soll, müssen die Adressen externer aus dem Netz der Einsatzumgebung erreichbaren DNS-Server als Parameter übergeben werden. Der Administrator MUSS diese Adressen konfigurieren können. |
DHCP_NTP |
Enabled/Disabled |
Der Administrator MUSS konfigurieren können, ob der Konnektor die Adresse des Konnektor internen NTP-Servers per DHCP an die Clients sendet. Default-Wert: Enabled |
DHCP_ OWNDGW_ ENABLED |
Enabled/Disabled |
Der Administrator MUSS konfigurieren können, ob der Konnektor beim Client als Default-Gateway gesetzt werden soll. Default-Wert: Disabled |
DHCP_DGW_ ADDR |
IP-Adresse des DGW |
Falls der Konnektor nicht als Default Gateway gesetzt werden soll, muss die Adresse des zu verwendenden DGW als Parameter übergeben werden. Der Administrator MUSS die Adresse des DGW konfigurieren können. |
DHCP_IP_ NETMASK |
Netzmaske |
Der Administrator MUSS die Netmask des Clients konfigurieren können. |
DHCP_ DOMAINNAME |
Domainname |
Der Administrator MUSS den Domainnamen des Clients konfigurieren können. |
DHCP_ HOSTNAME |
Liste von Tupel aus Hostname und Mac-Adresse |
Der Administrator MUSS eine Liste von Hostname der Clients konfigurieren können (Einträge einfügen, ändern, löschen). |
DHCP_ STATIC_LEASE |
Liste von Tupel aus IP- und Mac-Adresse |
Der Administrator MUSS für jede MAC-Adresse Static Lease konfigurieren können. |
DHCP_ LEASE_TTL |
X Minuten |
Der Administrator MUSS Lease-Dauer der dynamischen Adressen konfigurieren können. |
DHCP_ AKTIVE_ BESTANDS NETZE_ ROUTES |
Liste von Tupel: Netzwerksegment je INTRANET und Adresse für Next Hop je freigegebenem angeschlossenen Netze des Gesundheitswesens mit WANDA Basic |
Der Administrator MUSS je freigegebenem angeschlossenen Netze des Gesundheitswesens mit WANDA Basic (aus ANLW_AKTIVE_BESTANDSNETZE) den an den Client zu übermittelnden Routen-Eintrag aktivieren oder deaktivieren können. |
DHCP_ INTRANET_ ROUTES |
Liste von Tupel: Netzwerksegment je INTRANET und Adresse für Next Hop in die definierten Intranets |
Der Administrator MUSS je Intranet-Tupel (aus ANLW_LEKTR_INTRANET_ROUTES) den an den Client zu übermittelnden Routen-Eintrag aktivieren oder deaktivieren können. |
DHCP_ ROUTES |
Tupel Netzwerksegment und Adresse für Next Hop |
Der Administrator MUSS Routen zur Verteilung an die Clients frei konfigurieren können. Der Konnektor MUSS sicherstellen, diese Listeneinträge keine Überschneidungen mit folgenden Netzsegmenten haben: - dem Netzwerksegment ANLW_LAN_NETWORK_SEGMENT - dem Netzwerksegment ANLW_WAN_NETWORK_SEGMENT - jedes Netzsegmente in ANLW_BESTANDSNETZE ANLW_AKTIVE_BESTANDSNETZE ANLW_LEKTR_INTRANET_ROUTES Die Routen SOLLEN über DHCP Option 121 (Windows Vista oder höher) bzw. DHCP Option 249 (Windows XP und darunter) verteilt werden. |
DHCP_ OPTIONS |
Liste an weiteren DHCP-Optionen. |
Vom Administrator konfigurierbare Liste an weiteren DHCP-Options gemäß [RFC2132]. Die Umsetzung dieser Konfigurationsmöglichkeit KANN entfallen. |
[<=]
4.2.2.6.1 TUC_KON_343 „Initialisierung DHCP-Server“
TIP1-A_4768 - TUC_KON_343 „Initialisierung DHCP-Server“
Der Konnektor MUSS in der Bootup-Phase TUC_KON_343 "Initialisierung DHCP-Server" durchlaufen.
Tabelle 329: TAB_KON_630 - TUC_KON_343 „Initialisierung DHCP-Server“
Element |
Beschreibung |
Name |
TUC_KON_343 ”Initialisierung DHCP-Server” |
Beschreibung |
Falls DHCP-Server Konfiguration aktiv ist, muss der Konnektor in der Bootup-Phase oder bei einer Aktivierung des Servers den DHCP-Server starten. |
Anwendungsumfeld |
Bereitstellen der Netzwerkkonfiguration für den Betrieb |
Eingangsanforderung | Keine |
Auslöser und Vorbedingungen |
Bootup oder Ereignis DHCP/SERVER/STATECHANGED |
Eingangsdaten |
Keine |
Komponenten |
Konnektor |
Ausgangsdaten | Keine |
Standardablauf |
Falls DHCP_SERVER_STATE = enabled - den DHCP-Server starten Falls DHCP_SERVER_STATE = disabled - den DHCP-Server stoppen |
Varianten/Alternativen | Keine |
Fehlerfälle |
4168: DHCP-Server konnte nicht gestartet werden |
Nichtfunktionale Anforderungen |
Keine |
Zugehörige Diagramme |
Keine |
Tabelle 330: TAB_KON_631 Fehlercodes TUC_KON_343 „Initialisierung DHCP-Server“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
4168 |
Technical |
Error |
Der DHCP-Server des Konnektors konnte nicht gestartet werden. |
[<=]
4.2.3 DHCP-Client
Innerhalb des Kapitels DHCP-Client werden folgende Präfixe für Bezeichner verwendet:
- Events (Topic Ebene 1): „DHCP“
- Konfigurationsparameter: „DHCP_CLIENT_“
4.2.3.1 Funktionsmerkmalweite Aspekte
TIP1-A_4769 - DHCP Client Funktionalität des Konnektors
Der Konnektor MUSS an seiner LAN- und WAN-Schnittstelle die Möglichkeit bieten jeweils DHCP zu nutzen.
Der DHCP-Client des Konnektors MUSS die empfangenen Parameter wie folgt verwenden:
- Die IP-Adresse und Subnetzmaske müssen dem Interface zugewiesen und in den Variablen ANLW_LAN_IP_ADDRESS bzw. ANLW_WAN_IP_ADDRESS und ANLW_LAN_SUBNETMASK gespeichert werden.
- Der für das Interface, auf Anfrage, gelieferte Wert der MTU Size KANN übernommen werden.
- Das Default Gateway (DGW) muss in der Variable ANLW_IAG_ADDRESS gespeichert werden.
- DNS-Server muss in der Variable DNS_SERVERS_INT gespeichert werden.
[<=]
4.2.3.2 Durch Ereignisse ausgelöste Reaktionen
TIP1-A_4771 - Reagieren auf DHCP/LAN_CLIENT/ STATECHANGED- und DHCP/WAN_CLIENT/ STATECHANGED-Ereignisse
Wenn das Ereignis DHCP/LAN_CLIENT/STATECHANGED oder DHCP/WAN_CLIENT/STATECHANGED empfangen wird, MUSS TUC_KON_341 „DHCP-Informationen beziehen“ aufgerufen werden.
[<=]4.2.3.3 Interne TUCs, nicht durch Fachmodule nutzbar
4.2.3.3.1 TUC_KON_341 „DHCP-Informationen beziehen“
TIP1-A_4772 - TUC_KON_341 „DHCP-Informationen beziehen“
Der Konnektor MUSS den technischen Use Case TUC_KON_341 „DHCP-Informationen beziehen“ umsetzen.
Tabelle 331: TAB_KON_632 – TUC_KON_341 „DHCP Informationen beziehen“
Element |
Beschreibung |
Name |
TUC_KON_341 DHCP-Informationen beziehen |
Beschreibung |
Der Konnektor muss seine WAN- und/oder LAN-Schnittstelle individuell über einen DHCP-Server aus dem Netz der Einsatzumgebung beziehen können. |
Anwendungsumfeld |
Netzwerkkonfiguration für den Betrieb des Konnektors |
Eingangsanforderung |
Der Konnektor muss zur Netzwerk-Interface-Konfiguration DHCP nutzen sofern keine statischen Informationen vorhanden sind. |
Auslöser |
Bootup, Ablauf einer DHCP-Lease, manuell angestoßenes DHCP-Renew, Aktivierung der DHCP-Client-Funktionalität. |
Vorbedingung |
aktivierte DHCP-Client Funktion über die Variablen DHCP_CLIENT_LAN_STATE bzw. DHCP_CLIENT_WAN_STATE |
Eingangsdaten |
Netzwerk-Adapter (LAN oder WAN) für den DHCP-Informationen bezogen werden sollen |
Komponenten |
Konnektor |
Ausgangsdaten |
DHCP-Informationen vom DHCP-Server der Einsatzumgebung |
Standardablauf |
|
Varianten/Alternativen |
Keine |
Fehlerfälle |
4169: Konnektor erhält keine DHCP-Informationen 4170: Konnektor besitzt identische IP-Adressen am WAN- und LAN-Interface |
Nichtfunktionale Anforderungen |
Keine |
Zugehörige Diagramme |
Keine |
Tabelle 332: TAB_KON_633 Fehlercodes TUC_KON_341 „DHCP-Informationen beziehen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
4169 |
Technical |
Error |
Konnektor erhält keine DHCP-Informationen. |
4170 |
Technical |
Error |
Konnektor besitzt identische IP-Adressen am WAN und LAN |
[<=]
4.2.3.4 Interne TUCs, auch durch Fachmodule nutzbar
Keine.
4.2.3.5 Operationen an der Außenschnittstelle
Keine.
4.2.3.6 Betriebsaspekte
TIP1-A_4773 - Konfiguration des DHCP-Clients
Die DHCP-Client Funktionalität MUSS für LAN- und WAN-Interface vom Administrator getrennt aktivierbar und deaktivierbar sein (gemäß TAB_KON_634). Falls der DHCP-Client nicht verwendet wird MUSS sichergestellt werden, dass eine statische Konfiguration, für den LAN-Adapter gemäß Tabelle TAB_KON_683 LAN-Adapter IP-Konfiguration bzw. für den WAN-Adapter gemäß Tabelle TAB_KON_685 WAN-Adapter IP-Konfiguration, existiert bevor die Netzwerkeinstellungen übernommen werden.
Sobald Parameter geändert wurden, MUSS TUC_KON_256 „Systemereignis absetzen“ je nachdem auf welchem Interface der Client aktiviert oder deaktiviert wurde mit folgenden Parameter aufgerufen werden:
TUC_KON_256{"DHCP/LAN_CLIENT/STATECHANGED"; Op; Info;
"STATE=$DHCP_CLIENT_LAN_STATE"; doDisp = false}
oder
TUC_KON_256{"DHCP/WAN_CLIENT/STATECHANGED "; Op; Info;
"STATE=$DHCP_CLIENT_WAN_STATE "; doDisp = false}
Tabelle 333: TAB_KON_634 „Konfiguration des DHCP-Clients“
ReferenzID |
Belegung |
Bedeutung |
---|---|---|
DHCP_CLIENT_ LAN_STATE |
Enabled/Disabled |
Der Administrator muss den DHCP-Client an der LAN-Schnittstelle aktivieren oder deaktivieren können. |
DHCP_CLIENT_ WAN_STATE |
Enabled/Disabled |
Der Administrator muss den DHCP-Client an der WAN-Schnittstelle aktivieren oder deaktivieren können. |
[<=]
TIP1-A_4774 - Manuelles anstoßen eines DHCP-Lease-Renew
Der Administrator MUSS die Möglichkeit haben die DHCP-Lease des Konnektors für jedes Interface getrennt zu erneuern.
[<=]
TIP1-A_4776 - Setzen der IP-Adresse nach Timeout
Falls der DHCP-Client auf der LAN-Seite nach einem Timeout von 30s keine IP-Adresse bezogen hat, MUSS gemäß [RFC3927] eine Default-Adresse aus 169.254/16 vergeben werden.
[<=]
4.2.4 VPN-Client
Der VPN-Client beschreibt die Absicherung der Anbindung des Konnektors an die TI und die Bestandsnetze. Während der technische Kern dieser Funktion, der Aufbau der VPN- Kanäle zu den Konzentratoren, in [gemSpec_VPN_ZugD#TUC_VPN-ZD_0001] und [gemSpec_VPN_ZugD#TUC_VPN-ZD_0002] beschrieben wird, regelt dieses Kapitel die Interaktion, sowie die Konfiguration des VPN-Clients innerhalb des Konnektors.
Innerhalb des Kapitels VPN-Client werden folgende Präfixe für Bezeichner verwendet:
- Events (Topic Ebene 1): „NETWORK“
- Konfigurationsparameter: „VPN_“
4.2.4.1 Funktionsmerkmalweite Aspekte
TIP1-A_4778 - Anforderungen an den VPN-Client
Der Konnektor MUSS sich im Rahmen des IPsec-Verbindungsaufbaus gegenüber den VPN-Konzentratoren mit seiner Identität ID.NK.VPN ausweisen.
Der VPN-Client im Konnektor MUSS das folgende Event generieren, sobald der VPN-Tunnel zur TI nicht mehr zur Verfügung steht:
Rufe TUC_KON_256 {"NETWORK/VPN_TI/DOWN"; Op; Warning;}
Der VPN-Client im Konnektor MUSS das folgende Event generieren, sobald der VPN-Tunnel zum SIS nicht mehr zur Verfügung steht:
Rufe TUC_KON_256 {"NETWORKVPN_SIS/DOWN"; Op; Warning;}
Der Hersteller des Konnektor MUSS sicherstellen, dass eine Anbindung an einen Konzentrator ausschließlich dann möglich ist, wenn (MGM_LU_ONLINE = Enabled) gesetzt ist.
Der Administrator des Konnektor MUSS durch die Managementschnittstelle manuell einen Verbindungsaufbau und einen Verbindungsabbau eines VPN-Tunnel zur TI (VPN_TI) oder zu den SIS (VPN_SIS) initiieren können.
[<=]TIP1-A_4779 - Wiederholte Fehler beim VPN-Verbindungsaufbau
Der Konnektor MUSS gewährleisten, dass nach einem Fehler beim VPN-Verbindungsaufbau nicht unmittelbar ein weiterer Versuch des Verbindungsaufbaus durchgeführt wird.
Hierzu MUSS der Hersteller ein inkrementelles (schrittweise anwachsend) Verfahren wählen, welcher den zeitlichen Abstand zwischen einzelnen Versuchen des VPN-Verbindungsaufbau definiert. Dieser Abstand MUSS maximal fünf Minuten betragen. (Diese Pause soll es dem Konnektor ermöglichen, noch ausreichend Ressourcen für die verbleibenden Services zur Verfügung zu stellen).
[<=]4.2.4.2 Durch Ereignisse ausgelöste Reaktionen
TIP1-A_4780 - TI VPN-Client Start Events
Beim Auftreten einer der nachfolgenden Events MUSS der Konnektor den TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen“ starten, sofern auch MGM_LU_ONLINE = Enabled.
Event NETWORKVPN_TI/DOWN
Event MGM/LU_CHANGED/LU_ONLINE
TIP1-A_4781 - SIS VPN-Client Start Events
Beim Auftreten einer der nachfolgenden Events MUSS der Konnektor den TUC_KON_322 „Verbindung zu dem VPN-Konzentrator des SIS aufbauen“ starten, sofern ANLW_INTERNET_MODUS = SIS, MGM_LU_ONLINE = Enabled und die Verbindung VPN-Konzentrator TI aufgebaut ist:
Event NETWORKVPN_SIS/DOWN
TIP1-A_5417 - TI VPN-Client Stop Events
Beim Auftreten einer der nachfolgenden Events MUSS der Konnektor den VPN-Tunnel zur TI beenden:
MGM/LU_CHANGED/LU_ONLINE mit (Active=Disabled)
TIP1-A_4782 - SIS VPN-Client Stop Events
Beim Auftreten einer der nachfolgenden Events MUSS der Konnektor den VPN-Tunnel zum SIS beenden:
- MGM/LU_CHANGED/LU_ONLINE mit (Active=Disabled)
Hinweis: Wenn der IPsec-Tunnel VPN_SIS aufgebaut ist, zeigt die Default Route im Konnektor auf die innere Tunnel-IP-Adresse des VPN-Konzentrators SIS. Dies ist bei einer Trennung und dem Wiederaufbau der Verbindung VPN_TI zu beachten.
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“
TIP1-A_4783 - TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen“
Der Konnektor MUSS den technischen Use Case TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen“ umsetzen.
Tabelle 334: TAB_KON_635 – TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen“
Element |
Beschreibung |
Name |
TUC_KON_321 Verbindung zu dem VPN-Konzentrator der TI aufbauen |
Beschreibung |
Es wird ein IPsec-Tunnel zum VPN-Konzentrator der TI aufgebaut werden. Über den erfolgreichen Aufbau wird per Event informiert. |
Auslöser |
Bootup-Phase TUC_KON_305 „LAN-Adapter initialisieren“ TUC_KON_306 „WAN-Adapter initialisieren“ Event MGM/LU_CHANGED/LU_ONLINE Event NETWORK/VPN/CONFIG_CHANGED Optional: Änderungen ANLW_AKTIVE_BESTANDSNETZE Manueller Aufruf über Managementschnittstelle |
Vorbedingungen |
Der TUC_KON_304 „Netzwerk-Routen einrichten“ MUSS fehlerfrei durchgelaufen sein. |
Eingangsdaten |
|
Komponenten |
Konnektor |
Ausgangsdaten |
Der virtuelle Adapter VPN_TI mit der IP-Adresse VPN_TUNNEL_TI_INNER_IP des Konnektors wurde zur Verfügung gestellt.
|
Standardablauf |
1) Wenn der Auslöser = Event NETWORK/VPN/CONFIG_CHANGED oder eine Änderung von ANLW_AKTIVE_BESTANDSNETZE ist, muss der VPN-Tunnel TI abgebaut werden. 2) Wenn der VPN-Tunnel TI noch aktiv ist, ist der Ablauf abgeschlossen. Anderenfalls ist mit Ablaufschritt 3) fortzufahren. 3) Prüfen, MGM_LU_ONLINE = Enabled, falls nicht ist der TUC ohne Ausgabe einer Fehlermeldung zu beenden. 4) Prüfen, ob die im Konnektor hinterlegte CRL noch gültig ist. falls nicht, muss der TUC_KON_040 „CRL aktualisieren“ aufgerufen werden, Anschließend erneut prüfen, ob die im Konnektor hinterlegte CRL nun gültig ist. Falls die CRL nicht gültig ist, ist der TUC mit Fehler zu beenden. 5) Aufrufen von TUC_VPN-ZD_0001 „IPsec Tunnel TI aufbauen” Die folgenden Rückgabewerte des TUC_VPN-ZD_0001 „IPsec Tunnel TI aufbauen” sind in die laufende Konfiguration des Konnektors zu übernehmen:
Sobald der Tunnel erfolgreich aufgebaut wurde, ist der folgende Event zu generieren: TUC_KON_256 {"NETWORK/VPN_TI/UP"; Op; Info;IP= $VPN_TUNNEL_TI_INNER_IP} |
Varianten/Alternativen |
Keine |
Fehlerfälle |
(4) CRL ist abgelaufen (outdated);
Herstellerspezifisch kann entweder (4a) oder (4b) umgesetzt werden:
(4a) Kritischer Fehlerzustand EC_CRL_Out_Of_Date wurde noch nicht festgestellt:
4173
(4b) kritischer Fehlerzustand EC_CRL_Out_Of_Date wurde bereits festgestellt: 4002 (->4) Wenn Fehler 4173 bzw. 4002 nicht zutreffen, ist ein herstellerspezifischer Fehler zu verwenden.(5) VPN-Tunnel konnte nicht aufgebaut werden; Fehlercode: 4174 |
Nichtfunktionale Anforderungen |
Keine |
Zugehörige Diagramme |
Keine |
Tabelle 335: TAB_KON_636 Fehlercodes TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4002 | Security | Fatal | Der Konnektor befindet sich in einem kritischen Betriebszustand |
4172 |
Technical |
Fatal |
Es ist keine Online-Verbindung zulässig. |
4173 |
Technical |
Fatal |
Die CRL ist nicht mehr gültig (outdated). |
4174 |
Technical |
Fatal |
TI-VPN-Tunnel: Verbindung konnte nicht aufgebaut werden |
[<=]
4.2.4.3.2 TUC_KON_322 „Verbindung zu dem VPN-Konzentrator des SIS aufbauen“
TIP1-A_4784 - TUC_KON_322 „Verbindung zu dem VPN-Konzentrator des SIS aufbauen“
Der Konnektor MUSS den technischen Use Case TUC_KON_322 „Verbindung zu dem VPN-Konzentrator der SIS aufbauen“ umsetzen.
Tabelle 336: TAB_KON_637 – TUC_KON_322 „Verbindung zu dem VPN-Konzentrator der SIS aufbauen“
Element |
Beschreibung |
Name |
TUC_KON_322 Verbindung zu dem VPN-Konzentrator der SIS aufbauen |
Beschreibung |
Es muss ein IPsec-Tunnel zum VPN-Konzentrator der SIS aufgebaut werden |
Auslöser |
Bootup-Phase TUC_KON_305 „LAN-Adapter initialisieren TUC_KON_306 „WAN-Adapter initialisieren Event NETWORK/VPN/CONFIG_CHANGED Optional: Event MGM/LU_CHANGED/LU_ONLINE Manueller Aufruf über Managementschnittstelle |
Vorbedingungen |
ANLW_INTERNET_MODUS = SIS Die Verbindung VPN-Konzentrator TI ist aufgebaut. Der TUC_KON_304 „Netzwerk-Routen einrichten“ muss erfolgreich durchgeführt worden sein. |
Eingangsdaten |
Keine |
Komponenten |
Konnektor |
Ausgangsdaten |
Der virtuelle Adapter VPN_SIS mit der IP-Adresse VPN_TUNNEL_SIS_INNER_IP wurde zur Verfügung gestellt.
|
Standardablauf |
1) Wenn der Auslöser Event NETWORK/VPN/CONFIG_CHANGED ist, muss der VPN-Tunnel SIS abgebaut werden. 2) Wenn der VPN-Tunnel SIS noch aktiv ist, ist der Ablauf abgeschlossen. Anderenfalls ist mit Ablaufschritt 3) fortzufahren. 3) Prüfen, ob (MGM_LU_ONLINE=Enabled). falls nicht ist der TUC ohne Ausgabe einer Fehlermeldung zu beenden. 4) entfällt 5) Prüfen, ob die im Konnektor hinterlegte CRL noch gültig ist. falls nicht, MUSS der TUC_KON_040 „CRL aktualisieren“ aufgerufen werden, Anschließend erneut prüfen, ob die im Konnektor hinterlegte CRL nun gültig ist. Falls die CRL nicht gültig ist, ist der TUC mit Fehler zu beenden. 6) Aufrufen von TUC_VPN-ZD_0002 „IPsec Tunnel SIS aufbauen” 7) Aufrufen von TUC_KON_304 „Netzwerk-Routen einrichten“ Sobald der Tunnel erfolgreich aufgebaut wurde, ist der folgende Event zu generieren: TUC_KON_256 {"NETWORK/VPN_SIS/UP"; Op; Info;IP= $VPN_TUNNEL_SIS_INNER_IP} |
Varianten/Alternativen |
Keine |
Fehlerfälle |
(3) Keine Online-Verbindung zulässig; 4172 (5) CRL ist abgelaufen (outdated);
Herstellerspezifisch kann entweder (5a) oder (5b) umgesetzt werden:
(5a) Kritischer Fehlerzustand EC_CRL_Out_Of_Date wurde noch nicht festgestellt: 4173
(5b) kritischer Fehlerzustand EC_CRL_Out_Of_Date wurde bereits festgestellt: 4002
(->5) Wenn Fehler 4173 bzw. 4002 nicht zutreffen, ist ein herstellerspezifischer Fehler zu verwenden.(6) VPN Tunnel konnte nicht aufgebaut werden; Fehlercode: 4176 |
Nichtfunktionale Anforderungen |
Keine |
Zugehörige Diagramme |
Keine |
Tabelle 337: TAB_KON_638 Fehlercodes TUC_KON_322 „Verbindung zu dem VPN-Konzentrator der SIS aufbauen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4002 | Security | Fatal | Der Konnektor befindet sich in einem kritischen Betriebszustand |
4172 |
Technical |
Fatal |
Es ist keine Online-Verbindung zulässig. |
4173 |
Technical |
Fatal |
Die CRL ist nicht mehr gültig (outdated). |
4176 |
Technical |
Fatal |
SIS-VPN-Tunnel: Verbindung konnte nicht aufgebaut werden |
[<=]
4.2.4.4 Interne TUCs, auch durch Fachmodule nutzbar
Keine
4.2.4.5 Operationen an der Außenschnittstelle
Keine
4.2.4.6 Betriebsaspekte
TIP1-A_5415 - Initialisierung „VPN-Client“
Der Konnektor MUSS in der Bootup-Phase zur Initialisierung des Funktionsmerkmals „VPN-Client“:
die Verbindung zum VPN-Konzentrator TI aufbauen (TUC_KON_321)
die Verbindung zum VPN-Konzentrator SIS aufbauen (TUC_KON_322)
TIP1-A_4785-03 - Konfigurationsparameter VPN-Client
Die Managementschnittstelle MUSS es einem Administrator ermöglichen Konfigurationsänderungen am VPN-Client gemäß Tabelle TAB_KON_639 vorzunehmen.
Der Konnektor MUSS bei einer Änderung der Konfigurationswerte den folgenden Event auslösen:
Rufe TUC_KON_256 {"NETWORK/VPN/CONFIG_CHANGED"; Op; Info;; doDisp = false}
Tabelle 338: TAB_KON_639 – Konfigurationsparameter VPN-Client
ReferenzID |
Belegung |
Bedeutung und Administrator-Interaktion |
---|---|---|
IKE_ KEEPALIVE_ MODUS |
Enabled/Disabled |
Der Administrator MUSS einstellen können, ob IKE Keep-Alive-Pakete gesendet werden. Ein Hinweis MUSS ausgegeben werden, dass dies bei Nutzung von Dial-Up-Verbindungen nicht zu empfehlen ist. Dies dient der Vermeidung von Kosten bei Nutzung eines Internetzugangs ohne Flatrate. Default-Wert: Enabled |
IKE_ KEEPALIVE_ INTERVAL |
X Sekunden |
Der Administrator MUSS die Zeit in Sekunden angeben können, nach der ein neues IKE Keep-Alive-Paket gesendet wird. Default-Wert: 30 |
IKE_ KEEPALIVE_ RETRY |
X |
Der Administrator MUSS angeben können, nach wie vielen IKE Keep-Alive-Paketen ohne Acknowledge Message die Verbindung beendet wird. Default-Wert: 3 |
VPN_IDLE_ TIMEOUT_ MODUS |
Enabled/Disabled |
Der Administrator MUSS einstellen können, ob nach Inaktivität die VPN-Verbindung automatisch abgebaut werden soll. Ein Hinweis MUSS ausgegeben werden, dass dies insbesondere bei Nutzung von Dial-Up-Verbindungen Enabled werden sollte. Default-Wert: Disabled |
VPN_IDLE_ TIMEOUT |
X Sekunden |
Der Administrator MUSS die Zeit in Sekunden angeben können, nach der eine inaktive VPN-Verbindung zu einem Abbau der Verbindung führt. Default-Wert: 600 |
NAT_ KEEPALIVE_ MODUS |
Enabled/Disabled |
Der Administrator MUSS einstellen können, ob NAT Keep-Alive-Pakete gesendet werden. Ein Hinweis MUSS ausgegeben werden, dass dies insbesondere bei Nutzung von Dial-Up-Verbindungen nicht zu empfehlen ist. Default-Wert: Enabled |
NAT_ KEEPALIVE_ INTERVAL |
X Sekunden |
Der Administrator MUSS die Zeit in Sekunden angeben können, nach der ein neues NAT Keep-Alive-Paket gesendet wird. Default-Wert: 20 |
VPN_ KONZENTRATOR_ TI_IP_ADDRESS |
IP-Adresse |
IP-Adresse des VPN-Konzentrators TI im Transportnetz zu dem der IPsec-Tunnel VPN_TI aufgebaut wird. Der Wert kann vom Administrator nur eingesehen werden. |
VPN_ KONZENTRATOR_ SIS_IP_ADDRESS |
IP-Adresse |
IP-Adresse des VPN-Konzentrators SIS im Transportnetz zu dem der IPsec-Tunnel VPN_SIS aufgebaut wird. Der Wert kann vom Administrator nur eingesehen werden. |
VPN_TI_MTU |
Paketgröße in Byte |
Der Administrator MUSS die MTU für ESP-Pakete zur TI (excl. ESP-Header-Size) in den Grenzen von 576 bis 8076 konfigurieren können. Default-Wert: 1318 |
VPN_SIS_MTU |
Paketgröße in Byte |
Der Administrator MUSS die MTU für ESP Pakete zum SIS (excl. ESP-Header-Size) in den Grenzen von 576 bis 8076 konfigurieren können. Default-Wert: 1318 |
HASH_AND_URL |
Enabled/Disabled |
Der Administrator MUSS die Nutzung des hash&URL-Verfahrens zum Zertifikatsaustausch konfigurieren können. Wenn HASH_AND_URL = Enabled gesetzt ist, wird die URL für das hash&URL-Verfahren automatisch durch DNS SRV- und TXT-Anfragen mit Owner „_hashandurl._tcp.<DNS_DOMAIN_VPN_ZUGD_INT>„ ermittelt. Default-Wert: Disabled |
4.2.5 Zeitdienst
Der Zeitdienst schafft die Grundlage einer gleichen Systemzeit für alle in der TI einzusetzenden Produkttypen. Grundsätzlich ist ein NTP-Server der Stratum-3-Ebene innerhalb des Konnektors erforderlich, welcher die Zeitangaben eines NTP-Servers Stratum-2-Ebene abfragt (GS-A_3942). Die in [gemSpec_Net#5.1] „NTP-Topologie“ getroffenen Anforderungen werden durch dieses Kapitel erweitert.
Innerhalb des Zeitdienstes werden folgende Präfixe für Bezeichner verwendet:
- Events (Topic Ebene 1): „NTP“
- Konfigurationsparameter: „NTP_“
4.2.5.1 Funktionsmerkmalweite Aspekte
TIP1-A_4786 - Maximale Zeitabweichung
Falls der Leistungsumfang Online nicht aktiviert ist (MGM_LU_ONLINE=Disabled), MUSS sichergestellt werden, dass der maximale zulässige Fehler von +/- 20ppm (part per million) gegenüber einer Referenzuhr nicht überschritten wird. Dies entspricht einer maximalen Abweichung im Freilauf von +/- 34,56 Sekunden über 20 Tage.
[<=]TIP1-A_4787 - Konfigurationsabhängige Funktionsweise
Der NTP-Server des Konnektors MUSS deaktiviert sein, falls der Konnektor Leistungsumfang Online nicht aktiviert ist (MGM_LU_ONLINE=Disabled.
[<=]Falls die Systemzeit des Konnektors zu stark von der Zeit der zentralen TI-Plattform abweicht, deutet dies auf ein schwerwiegendes Problem im Konnektor oder der Umgebung hin, da dies im ordnungsgemäßen Betrieb nicht auftreten sollte.
TIP1-A_4788 - Verhalten bei Abweichung zwischen lokaler Zeit und erhaltenen Zeit
Der Konnektor DARF die im Konnektor vorgehaltene Systemzeit im Rahmen einer automatisierten Synchronisation NICHT aktualisieren, wenn die lokale Zeit von der im Rahmen der Synchronisation erhaltenen Zeit um mehr als NTP_MAX_TIMEDIFFERENCE abweicht. Dies betrifft NICHT Änderungen in der Darstellung der Systemzeit, die zeitzonenbedingt sind (MEZ -> MESZ -> MEZ), da die Zeitsynchronisation grundsätzlich UTC berücksichtigt. Bei einer erstmaligen Synchronisierung nach dem Boot-Vorgang oder bei einer erstmaligen Synchronisierung bei der Inbetriebnahme des Konnektors darf eine Synchronisation trotz einer Zeitabweichung größer einer Stunde durchgeführt werden. Daher MUSS der Konnektor bei einer Abweichung von mehr als einer Stunde in den kritischen Betriebszustand EC_TIME_DIFFERENCE_INTOLERABLE übergehen, ein weiterer fachlicher Betrieb des Konnektors DARF NICHT mehr erfolgen.
[<=]Der kritische Betriebszustand kann anschließend über einen manuellen Eingriff (z. B. Reboot) behoben werden (siehe 3.3 Betriebszustand).
TIP1-A_4789 - Zustandsvariablen des Konnektor Zeitdiensts
TAB_KON_640 listet die zu verwendenden Zustandsvariablen des Konnektor NTP-Servers. Diese Werte DÜRFEN NICHT durch den Administrator geändert werden.
Tabelle 339: TAB_KON_640 Zustandswerte für Konnektor NTP-Server
ReferenzID |
Belegung |
Zustandswerte |
---|---|---|
NTP_WARN_PERIOD |
30 |
Anzahl an Tagen nach der ersten erfolglosen Zeitsynchronisierung nach der eine Warnung an den Betreiber erfolgen soll |
NTP_GRACE_PERIOD |
50 |
Anzahl an Tagen nach der ersten erfolglosen Zeitsynchronisierung nach welcher der Konnektor in einen kritischen Betriebszustand übergehen muss. Dieser Parameter wirkt nur bei MGM_LU_ONLINE = Enabled. |
NTP_MAX_ TIMEDIFFERENCE |
3600 |
Maximale Zeitabweichung in Sekunden zwischen Systemzeit und Zeit des Stratum-2-Zeitservers zum Zeitpunkt der Zeitsynchronisierung. Dieser Parameter wirkt nur bei MGM_LU_ONLINE = Enabled. |
[<=]
4.2.5.2 Durch Ereignisse ausgelöste Reaktionen
Keine.
4.2.5.3 Interne TUCs, nicht durch Fachmodule nutzbar
Keine.
4.2.5.4 Interne TUCs, auch durch Fachmodule nutzbar
4.2.5.4.1 TUC_KON_351 “Liefere Systemzeit”
TIP1-A_4790 - TUC_KON_351 „Liefere Systemzeit“
Der Konnektor MUSS den technischen Use Case TUC_KON_351 „Liefere Systemzeit“ umsetzen.
Tabelle 340: TAB_KON_776 TUC_KON_351 „Liefere Systemzeit“
Element |
Beschreibung |
Name |
TUC_KON_351 „Liefere Systemzeit” |
Beschreibung |
Der Konnektor MUSS die Systemzeit auf Anforderung an Fachmodule liefern können. |
Anwendungsumfeld |
Den Fachanwendungen ist die Systemzeit zu liefern. |
Eingangsanforderung |
Die Echtzeituhr des Konnektors wurde gemäß den geforderten Synchronisationsintervallen aktualisiert (bei MGM_LU_ONLINE=Enabled) oder manuell gesetzt (bei MGM_LU_ONLINE=Disabled) |
Auslöser und Vorbedingungen |
Fachmodule benötigen die aktuelle Systemzeit des Konnektors. |
Eingangsdaten |
Echtzeituhr des Konnektors |
Komponenten |
Konnektor, Fachmodule |
Ausgangsdaten |
Systemzeit des Konnektors |
Standardablauf |
Siehe [gemSpec_Net] |
Varianten/Alternativen |
Keine |
Fehlerfälle |
4178: Konnektor retourniert keine Systemzeit |
Nichtfunktionale Anforderungen |
Keine |
Zugehörige Diagramme |
Keine |
Tabelle 341: TAB_KON_641 Fehlercodes TUC_KON_351 „Liefere Systemzeit“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
4178 |
Technical |
Error |
Das Fachmodul konnte die aktuelle Systemzeit des Konnektors nicht abrufen |
[<=]
4.2.5.5 Operationen an der Außenschnittstelle
4.2.5.5.1 Sync_Time
TIP1-A_4791 - Operation sync_Time
Der NTP-Server des Konnektors MUSS an der Client-Schnittstelle eine Operation sync_Time anbieten.
Tabelle 342: TAB_KON_642 Operation sync_Time
Name |
I_NTP_Time_Information:sync_Time |
---|---|
Beschreibung |
Der Konnektor MUSS anfragenden Clients (z.B. Ärztearbeitsplatz) per NTP-Version 4 die Systemzeit liefern |
Aufrufparameter | Vgl. [NTPv4] |
Rückgabe | Vgl. [NTPv4] |
Vorbedingungen |
MGM_LU_ONLINE=Enabled |
Nachbedingungen |
Der anfragende Client hat die korrekte Zeit geliefert bekommen. |
Hinweise |
Keine |
Fehler |
Der Aufruf schlägt fehl (bleibt unbeantwortet), wenn MGM_LU_ONLINE=Disabled |
[<=]
4.2.5.6 Betriebsaspekte
TIP1-A_4792 - Explizites Anstoßen der Zeitsynchronisierung
Der Konnektor MUSS dem Administrator die Möglichkeit bieten, eine Synchronisation mit dem zentralen Zeitdienst explizit anzustoßen.
[<=]TIP1-A_4793 - Konfigurierbarkeit des Konnektor NTP-Servers
Der Administrator MUSS die in TAB_KON_643 aufgelisteten Parameter über die Managementschnittstelle konfigurieren und die in TAB_KON_730 aufgelisteten Parameter ausschließlich einsehen können.
Tabelle 343: TAB_KON_643 Konfiguration des Konnektor NTP-Servers
ReferenzID |
Belegung |
Bedeutung |
---|---|---|
NTP_TIMEZONE |
Zeitzone |
Der Administrator MUSS die Zeitzone des Konnektors einstellen können. Default-Wert: Central European Time/Mitteleuropäische Zeit (CET/MEZ) |
NTP_TIME |
Zeit |
Der Administrator MUSS die Zeit des Konnektors (NTP_TIME) über die Managementschnittstelle manuell einstellen können. |
Tabelle 344: TAB_KON_730 Einsehbare Konfigurationsparameter des Konnektor NTP-Servers
ReferenzID |
Belegung |
Bedeutung |
---|---|---|
NTP_SERVER_ ADDR |
IP-Adressen |
Die Adressen des primären und sekundären Stratum-2-Zeitserver der zentralen TI-Plattform für die Synchronisation mit dem NTP-Server des Konnektors. |
[<=]
TIP1-A_4794 - Warnung und Übergang in kritischen Betriebszustand bei nichterfolgter Zeitsynchronisierung
Befindet sich der Konnektor im Zustand EC_TIME_SYNC_PENDING_CRITICAL oder EC_Time_Difference_Intolerable, MUSS der Administrator eine Korrektur oder Bestätigung der Systemzeit vornehmen können. Anschließend MUSS der Konnektor wie nach einer erfolgreichen Zeitsynchronisation verfahren, d. h. der Tagezähler wird auf 0 zurückgesetzt.
[<=]4.2.5.6.1 TUC_KON_352 Initialisierung Zeitdienst
TIP1-A_4795 - TUC_KON_352 „Initialisierung Zeitdienst“
Der Konnektor MUSS in der Bootup-Phase TUC_KON_352 "Initialisierung Zeitdienst" durchlaufen.
Tabelle 345: TAB_KON_644 – TUC_KON_352 „Initialisierung Zeitdienst“
Element |
Beschreibung |
Name |
TUC_KON_352 „Initialisierung Zeitdienst“ |
Beschreibung |
Der Konnektor muss zum Bootup den konnektoreigenen NTP-Server mit einem NTP-Server der zentralen TI-Plattform synchronisieren falls MGM_LU_ONLINE=Enabled. |
Anwendungsumfeld |
Synchronisierung der Systemzeit zur Startzeit |
Eingangsanforderung |
Keine |
Auslöser |
|
Vorbedingungen |
Verbindung zum VPN-Konzentrator TI muss aufgebaut sein |
Eingangsdaten |
NTP-Server der zentralen TI-Plattform |
Komponenten |
Konnektor |
Ausgangsdaten |
Keine |
Standardablauf |
Falls MGM_LU_ONLINE=Enabled:
|
Varianten/Alternativen |
Keine |
Fehlerfälle |
4177: Der NTP-Server des Konnektors empfängt keine Systemzeit |
Nichtfunktionale Anforderungen |
Keine |
Zugehörige Diagramme |
Keine |
Tabelle 346: TAB_KON_645 Fehlercodes TUC_KON_352 „Initialisierung Zeitdienst“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
4177 |
Technical |
Warning |
Der NTP-Server des Konnektors konnte nicht synchronisiert werden. |
[<=]
4.2.6 Namensdienst und Dienstlokalisierung
Innerhalb des Namensdienstes werden folgende Präfixe für Bezeichner verwendet:
- Events (Topic Ebene 1): keine Events vorhanden
- Konfigurationsparameter: „DNS_“
4.2.6.1 Funktionsmerkmalweite Aspekte
TIP1-A_4796 - Grundlagen des Namensdienstes
Der Konnektor MUSS einen Recursive Caching Nameserver zur Auflösung von DNS-Anfragen sowie einen autoritativen Nameserver zur Verwaltung der Zone „konlan.“ bereitstellen.
Der Caching-Nameserver des Konnektors MUSS für Clientsysteme aus dem lokalen Netzwerk (ANLW_LAN_NETWORK_SEGMENT oder ANLW_LEKTR_INTRANET_ROUTES) erreichbar sein.
Der Caching-Nameserver des Konnektors MUSS einen Timeout für die Bearbeitung von DNS-Abfragen beachten. Konnte eine DNS-Abfrage nicht durchgeführt werden, MUSS die Bearbeitung abgebrochen werden.
[<=]
TIP1-A_6480 - Resource Records der Zone konlan.
Der Konnektor MUSS in der Zone „konlan.“ die folgenden Resource Records bereitstellen:
-
label: „konnektor.konlan.“, ttl: <Time To Live>, class: IN, type: A, rdata: <LAN-seitige IP-Adresse des Konnektors>
Die in spitzen Klammern angegebenen Werte müssen implementierungs- und konfigurationsabhängig vergeben werden.
[<=]TIP1-A_4797 - DNS-Forwards des DNS-Servers
Der DNS-Server des Konnektors MUSS die folgenden DNS-Forwards durchführen:
Tabelle 347: TAB_KON_687 DNS-Forwards des DNS-Servers
Domain |
Forwarders |
Bemerkungen |
---|---|---|
Namensraum TI, *.DNS_TOP_ LEVEL_DOMAIN_TI |
DNS_SERVERS_TI |
DNS Forward Rule zur Auflösung aller DNS-Namen innerhalb des Namensraums der TI mit der Top Level Domain telematik (für die PU) und telematik-test (für die RU und TU). |
Namensraum TI, Top Level Domain ti-wa (PU) und ti-wa-test (RU und TU). | DNS_SERVERS_TI | DNS Forward Rule zur Auflösung aller DNS-Namen innerhalb des Namensraums der TI mit der Top Level Domain ti-wa (für die PU) und ti-wa-test (für die RU und TU). |
Namensraum angeschlossene Netze des Gesundheitswesens mit WANDA Basic (Domainnamen von angeschlossenen Netzen des Gesundheitswesens mit WANDA Basic gemäß Bestandsnetze.xml) |
DNS_ SERVERS_ BESTANDS NETZE (Je Domainnamen eines angeschlossenen Netzes des Gesundheitswesens mit WANDA Basic alle zugehörigen DNS-Server IP-Adressen gemäß Bestandsnetze.xml) |
Je angeschlossenes Netz des Gesundheitswesens mit WANDA Basic in ANLW_AKTIVE_BESTANDSNETZE wird eine DNS Forward Rule zur Auflösung von DNS-Namen innerhalb dieses Netzes verwendet. |
Namensraum lokale Einsatzumgebung (DNS_DOMAIN_ LEKTR) |
DNS_ SERVERS_ LEKTR |
DNS Forward Rule zur Auflösung aller DNS-Namen innerhalb der DNS-Domain DNS_DOMAIN_LEKTR |
Namensraum Internet |
DNS_ SERVERS_ SIS |
Wenn der VPN-Tunnel SIS aktiv ist, muss eine Forward Rule für den Namensraum Internet über die DNS_SERVERS_SIS existieren. |
Namensraum Internet |
DNS_ SERVERS_ INT |
Wenn der VPN-Tunnel SIS nicht aktiv ist, muss eine Forward Rule für den Namensraum Internet über die DNS_SERVERS_INT existieren |
Lokale Zone „konlan.“ |
autoritativer Nameserver des Konnektors |
DNS Forward Rule zur Auflösung aller DNS-Namen innerhalb der Zone „konlan.“ |
[<=]
TIP1-A_4798 - DNS Stub-Resolver
Der Stub-Resolver im Konnektor MUSS von allen internen Diensten zur Namensauflösung genutzt werden.
Der Stub-Resolver im Konnektor MUSS immer den Caching-Nameserver im Konnektor anfragen.
[<=]TIP1-A_4799 - Aktualität der DNS-Vertrauensanker sicherstellen
Der Konnektor, der einen Caching Nameserver als Validating Resolver umsetzt, MUSS den DNSSEC-Vertrauensanker der TI aus dem Zertifikatspeicher in den Caching-Nameserver übernehmen, wenn ein Fehler bei der Validierung der Namensauflösung der TI aufgetreten ist. [<=]
4.2.6.2 Durch Ereignisse ausgelöste Reaktionen
Keine.
4.2.6.3 Interne TUCs, nicht durch Fachmodule nutzbar
Keine.
4.2.6.4 Interne TUCs, auch durch Fachmodule nutzbar
4.2.6.4.1 TUC_KON_361 „DNS-Namen auflösen“
TIP1-A_4801 - TUC_KON_361 „DNS-Namen auflösen“
Der Konnektor MUSS den technischen Use Case TUC_KON_361 „DNS-Namen auflösen“ umsetzen.
Tabelle 348: TAB_KON_646 – TUC_KON_361 „DNS-Namen auflösen“
Element |
Beschreibung |
Name |
TUC_KON_361 „DNS-Namen auflösen“ |
Beschreibung |
Ein FQDN wird in ein oder mehrere IPs aufgelöst |
Auslöser |
interne Anfrage (Basisdienst oder Fachmodul) |
Vorbedingungen |
Die vom Konnektor zu verwendenden DNS-Server (DNS_SERVERS_INT, DNS_SERVERS_TI, DNS_SERVERS_SIS, DNS_SERVERS_BESTANDSNETZE) müssen konfiguriert sein. |
Eingangsdaten |
FQDN (Name, für den die IP-Adressen ermittelt werden sollen) |
Komponenten |
Konnektor |
Ausgangsdaten |
LIST_OF_IP_ADDRESSES |
Standardablauf |
1) Mit dem FQDN wird eine Anfrage an den Stub-Resolver des Konnektors (Typ A und AAAA) durchgeführt. Für alle ermittelten IPv4-Adressen und IPv6-Adressen werden als LIST_OF_IP_ADDRESSES zurückgeliefert. Da IPv6 nicht produktiv eingesetzt wird muss die aufrufende Instanz die IPv6-Adressen ignorieren. Falls keine IP-Adressen ermittelt werden konnten, wird eine leere Liste zurückgeliefert. |
Varianten/Alternativen |
Keine |
Fehlerfälle |
( 1) Timeout der Anfrage; Fehlercode 4179 ( 1) DNS-Fehler; Fehlercode 4180 |
Nichtfunktionale Anforderungen |
Keine |
Zugehörige Diagramme |
Keine |
Tabelle 349: TAB_KON_647 Fehlercodes TUC_KON_361 „DNS Namen auflösen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4179 |
Technical |
Error |
„DNS: Anfrage wurde wegen Timeout abgebrochen.” |
4180 |
Technical |
Fatal |
„DNS: Es ist ein Fehler bei der Namensauflösung aufgetreten“ Die Fehlerdetails sind gemäß DNS-Protokoll zu ergänzen. |
TIP1-A_4801-02 - ab PTV4: TUC_KON_361 „DNS-Namen auflösen“
Der Konnektor MUSS den technischen Use Case TUC_KON_361 „DNS-Namen auflösen“ umsetzen.
Tabelle 350: TAB_KON_646 – TUC_KON_361 „DNS-Namen auflösen“
Element |
Beschreibung |
Name |
TUC_KON_361 „DNS-Namen auflösen“ |
Beschreibung |
Ein FQDN wird in ein oder mehrere IPs aufgelöst |
Auslöser |
interne Anfrage (Basisdienst oder Fachmodul) |
Vorbedingungen |
Die vom Konnektor zu verwendenden DNS-Server (DNS_SERVERS_INT, DNS_SERVERS_TI, DNS_SERVERS_SIS, DNS_SERVERS_BESTANDSNETZE) müssen konfiguriert sein. |
Eingangsdaten |
FQDN (Name, für den die IP-Adressen ermittelt werden sollen) |
Komponenten |
Konnektor |
Ausgangsdaten |
LIST_OF_IP_ADDRESSES |
Standardablauf |
1) Mit dem FQDN wird eine Anfrage an den Stub-Resolver des Konnektors (Typ A und AAAA) durchgeführt. Für alle ermittelten IPv4-Adressen und IPv6-Adressen werden als LIST_OF_IP_ADDRESSES zurückgeliefert. Wird IPv6 nicht produktiv eingesetzt, muss die aufrufende Instanz die IPv6-Adressen ignorieren. Falls keine IP-Adressen ermittelt werden konnten, wird eine leere Liste zurückgeliefert. |
Varianten/Alternativen |
Keine |
Fehlerfälle |
( 1) Timeout der Anfrage; Fehlercode 4179 ( 1) DNS-Fehler; Fehlercode 4180 |
Nichtfunktionale Anforderungen |
Keine |
Zugehörige Diagramme |
Keine |
Tabelle 351: TAB_KON_647 Fehlercodes TUC_KON_361 „DNS Namen auflösen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4179 |
Technical |
Error |
„DNS: Anfrage wurde wegen Timeout abgebrochen.” |
4180 |
Technical |
Fatal |
„DNS: Es ist ein Fehler bei der Namensauflösung aufgetreten“ Die Fehlerdetails sind gemäß DNS-Protokoll zu ergänzen. |
[<=]
4.2.6.4.2 TUC_KON_362 „Liste der Dienste abrufen“
TIP1-A_4802 - TUC_KON_362 „Liste der Dienste abrufen“
Der Konnektor MUSS den technischen Use Case TUC_KON_362 „Liste der Dienste abrufen“ umsetzen.
Tabelle 352: TAB_KON_648 – TUC_KON_362 „Liste der Dienste abrufen“
Element |
Beschreibung |
Name |
TUC_KON_362 „Liste der Dienste abrufen“ |
Beschreibung |
Ermittlung aller zu einer DNS-SD-Gruppe gehörenden DNS-Namen. |
Auslöser |
interne Anfrage (Basisdienst oder Fachmodul) |
Vorbedingungen |
Die vom Konnektor zu verwendenden DNS-Server müssen konfiguriert sein. |
Eingangsdaten |
FQDN des PTR Resource Records |
Komponenten |
Konnektor |
Ausgangsdaten |
LIST_OF_SRV_ENTITIES |
Standardablauf |
Mit dem FQDN wird eine Typ „PTR“ Anfrage an den Stub-Resolver des Konnektor gestellt. |
Varianten/Alternativen |
Keine |
Fehlerfälle |
( 1) Timeout der Anfrage; Fehlercode 4179 ( 1) DNS-Fehler; Fehlercode 4180 |
Nichtfunktionale Anforderungen |
Keine |
Zugehörige Diagramme |
Keine |
Tabelle 353: TAB_KON_649 Fehlercodes TUC_KON_362 „Liste der Dienste abrufen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4179 |
Technical |
Error |
„DNS: Anfrage wurde wegen Timeout abgebrochen.” |
4180 |
Technical |
Fatal |
„DNS: Es ist ein Fehler bei der Namensauflösung aufgetreten“ Die Fehlerdetails sind gemäß [gemSpec_Net] zu ergänzen. |
[<=]
4.2.6.4.3 TUC_KON_363 „Dienstdetails abrufen“
TIP1-A_4803 - TUC_KON_363 „Dienstdetails abrufen“
Der Konnektor MUSS den technischen Use Case TUC_KON_363 „Dienstdetails abrufen“ umsetzen.
Tabelle 354: TAB_KON_650 - TUC_KON_363 „Dienstdetails abrufen“
Element |
Beschreibung |
Name |
TUC_KON_363 Dienstdetails abrufen |
Beschreibung |
Ermitteln aller DNS-SD-Details zu einem vollqualifizierten DNS-Namen. |
Auslöser |
interne Anfrage (Basisdienst oder Fachmodul) |
Vorbedingungen |
Die vom Konnektor zu verwendenden DNS-Server müssen konfiguriert sein. |
Eingangsdaten |
FQDN (der Name eines DNS-SD-Elements) |
Komponenten |
Konnektor |
Ausgangsdaten |
LIST_OF_SRV_ENTRIES LIST_OF_SRV_DETAILS |
Standardablauf |
1) Mit dem FQDN wird eine Typ-„SRV“-Anfrage an den Stub-Resolver des Konnektors gestellt. Die vom DNS-Server zurück gelieferten SRV-Einträge werden als LIST_OF_SRV_ENTRIES (bestehend aus TTL, Priority, Weight, Port, Target) zurückgeliefert. Wenn kein Eintrag gefunden werden konnte, wird eine leere Liste LIST_OF_SRV_ENTRIES zurückgeliefert. 2) Mit dem FQDN wird zusätzlich eine Typ-„TXT“-Anfrage an den Stub-Resolver des Konnektors gestellt. Wenn ein oder mehrere entsprechende Einträge gefunden werden konnten, werden diese in einer gemeinsamen Liste LIST_OF_SRV_DETAILS (bestehend aus TTL und TXT) zusammengefasst. Wenn kein Eintrag gefunden werden konnte, wird eine leere Liste LIST_OF_SRV_DETAILS zurückgeliefert. Falls keine FQDN ermittelt werden konnten, wird je eine leere Liste LIST_OF_SRV_ENTRIES und LIST_OF_SRV_DETAILS zurückgeliefert. |
Varianten/Alternativen |
Keine |
Fehlerfälle |
( 1-2) Timeout der Anfrage; Fehlercode 4179 ( 1-2) DNS Fehler; Fehlercode 4180 |
Nichtfunktionale Anforderungen |
Keine |
Zugehörige Diagramme |
Keine |
Tabelle 355: TAB_KON_651 Fehlercodes TUC_KON_363 „Dienstdetails abrufen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4179 |
Technical |
Error |
„DNS: Anfrage wurde wegen Timeout abgebrochen.” |
4180 |
Technical |
Fatal |
„DNS: Es ist ein Fehler bei der Namensauflösung aufgetreten“ Die Fehlerdetails sind gemäß [gemSpec_Net] zu ergänzen. |
[<=]
4.2.6.5 Operationen an der Außenschnittstelle
TIP1-A_4804 - Basisanwendung Namensdienst
Der Konnektor MUSS für Clients eine Basisanwendung Namensdienst anbieten.
Tabelle 356: TAB_KON_652 Basisanwendung Namensdienst
Name |
Namendienst |
|
---|---|---|
Version |
wird im Produktsteckbrief des Konnektors definiert |
|
Namensraum |
Keiner |
|
Namensraum-Kürzel |
Keiner |
|
Operationen |
Name |
Kurzbeschreibung |
GetIPAddress |
Diese Operation ermöglicht die Auflösung von FQDNs in IP-Adressen |
|
WSDL |
Keines |
|
Schema |
Keines |
[<=]
4.2.6.5.1 GetIPAddress
TIP1-A_5035 - Operation GetIPAddress
Der Namensdienst des Konnektors MUSS an der Client-Schnittstelle eine Operation GetIPAddress anbieten.
Tabelle 357: TAB_KON_653 Operation GetIPAddress
Name |
GetIPAddress |
Beschreibung |
Diese Operation ermöglicht die Auflösung von FQDN in IP-Adressen. (DNS-Forwarder Abfrage ohne Cache) |
Aufrufparameter |
Address (FQDN) DNSSECValidation (Boolean) |
Rückgabe |
IPAddr (IPAddress) DNSSECValidated (Boolean) |
Vorbedingungen |
Der DNS-Server im Konnektor muss aktiv sein. Die Forward Nameserver (DNS_SERVERS_TI, DNS_SERVERS_SIS, DNS_SERVERS_BESTANDSNETZE) müssen konfiguriert sein. |
Nachbedingungen |
Keine |
Standardablauf |
Für Details zu DNS Namensauflösung wird auf [gemSpec_Net] verweisen. |
[<=]
4.2.6.6 Betriebsaspekte
TIP1-A_5416 - Initialisierung „Namensdienst und Dienstlokalisierung“
Der Konnektor MUSS in der Bootup-Phase zur Initialisierung des Funktionsmerkmals „Namensdienst und Dienstlokalisierung“:
-
den autoritativen Nameserver starten
den Caching-Nameserver starten.
TIP1-A_4805 - Konfigurationsparameter Namensdienst und Dienstlokalisierung
Der Administrator MUSS die in TAB_KON_654 aufgelisteten Parameter über die Managementschnittstelle konfigurieren und die in TAB_KON_731 aufgelisteten Parameter ausschließlich einsehen können.
Nach jeder Änderung MUSS sichergestellt werden, dass die Änderungen sofort am autoritativen bzw. am Caching-Nameserver zur Verfügung stehen.
Tabelle 358: TAB_KON_654 - Konfigurationsparameter Namensdienst
ReferenzID |
Belegung |
Bedeutung und Administrator-Interaktion |
---|---|---|
DNS_SERVERS_INT |
Liste von IP-Adressen der DNS-Server |
Liste von DNS-Servern für das Transportnetz. Die IP-Adressen KÖNNEN auf einen öffentlich zugänglichen Adressbereich eingeschränkt sein. |
DNS_DOMAIN_ VPN_ZUGD_INT |
DNS Domainname |
DNS-Domainname für die Service Discovery der VPN-Konzentratoren des VPN-Zugangsdienstes |
DNS_SERVERS_ LEKTR |
Liste von IP-Adressen der DNS-Server |
Liste von DNS-Servern, die zur Namensauflösung von Namensräumen in der Einsatzumgebung verwendet werden. Der Administrator MUSS die Liste von DNS-Servern, die die DNS_DOMAIN_LEKTR auflösen, bearbeiten können. Die IP-Adressen der DNS-Server KÖNNEN auf den Adressbereich der ANLW_LAN_IP_ADDRESS eingeschränkt sein. |
DNS_DOMAIN_ LEKTR |
DNS Domainname |
DNS Domainname, der von einem DNS-Server der Einsatzumgebung aufgelöst wird. Der Name DARF NICHT mit einem „.“ beginnen und nicht mit einem „.“ enden. |
DNS_TA_CONFIG |
Ist abhängig von der gewählten Umsetzung |
Wenn der Konnektor als Validating Resolver für den Namensraum Internet implementiert ist gilt: Der Administrator MUSS die aktuellen DNSSEC Trustanchor für den Namensraum Internet auf geeignetem Weg in den Konnektor übernehmen können. |
Tabelle 359: TAB_KON_731 Einsehbare Konfigurationsparameter Namensdienst
ReferenzID |
Belegung |
Bedeutung |
---|---|---|
DNS_SERVERS_TI |
Liste von IP-Adressen der DNS-Server |
Liste von DNS-Servern, die zur Namensauflösung des Namensraums der TI verwendet werden |
DNS_SERVERS_SIS |
Liste von IP-Adressen der DNS-Server |
Liste von DNS-Servern, die zur Namensauflösung des Namensraums Internet bei Nutzung des SIS verwendet werden |
DNS_SERVERS_ BESTANDSNETZE |
Liste von IP-Adressen der DNS-Servern je Domäne je freigegebenem angeschlossenen Netz des Gesundheitswesens mit WANDA Basic |
Liste von DNS-Servern je Domain eines dieser freigegebenen Netze. |
DNS_TOP_LEVEL_ DOMAIN_TI |
DNS Domainname |
Top Level Domain des Namensraumes TI |
4.2.7 Optionale Verwendung von IPv6
Der Konnektor kann zusätzlich eine IPv6-Adresse an den Netzwerkschnittstellen zum Transportnetz implementieren. Entscheidet sich der Hersteller für den parallelen Einsatz von IPv4 und IPv6 (Dual-Stack-Mode), sind die nachfolgenden Anforderungen dieses Kapitels umzusetzen. Einhergehend mit der Entscheidung, IPv6 an diesem Interface zu konfigurieren, ist der spätere VPN-Tunnelaufbau zur TI und SIS über das IPv6 Interface möglich. Die durch den jeweiligen IPv6-Tunnel zu transportierenden IP-Pakete sind IPv4 adressierte Pakete.
A_17199 - IPv6 - Adressierung der Schnittstelle zum Internet (Option IPv6)
Der Konnektor MUSS bei Verwendung von IPv6 für den VPN-Tunnelaufbau zur TI und SIS auf geeignete Weise (z.B. DHCP vom IAG) mit einer IPv6-Adresse auf dem physikalischen Interface in Richtung Internet konfiguriert werden (Dual-Stack-Mode). [<=]
A_17200 - IPv6 - Fragmentierung der IKEv2-Nachrichten (Option IPv6)
Der Konnektor MUSS bei Verwendung von IPv6 für den VPN-Tunnelaufbau zur TI und SIS die Fragmentierung von IKEv2 Nachrichten gemäß [RFC7383] unterstützen. [<=]
A_17201 - IPv6 - Verhalten als IPv6 Router (Option IPv6)
Der Konnektor MUSS bei Verwendung von IPv6 für den VPN-Tunnelaufbau zur TI und SIS die notwendige Route für das Erreichen des Internets bereitstellen. [<=]
4.3 Konnektormanagement
Das Konnektormanagement dient ausschließlich Betriebsaspekten des Konnektors. Daher wird in diesem Kapitel weitestgehend auf die übliche Strukturierung nach TUCs (intern/für Fachmodule), Außenoperationen und Betriebsaspekten verzichtet. Lediglich der KSR-Client verwendet diese Kapitelstruktur.
Innerhalb des Konnektormanagements werden vorrangig folgende Präfixe für Bezeichner verwendet:
- Events (Topic Ebene 1): „MGM“
- Konfigurationsparameter: „MGM_“
Eine Ausnahme hiervon bildet der Anteil der Software-Aktualisierung (KSR-Client). Dieser verwendet folgende Präfixe für Bezeichner:
- Events (Topic Ebene 1): „KSR“
- Konfigurationsparameter: „MGM_“
TIP1-A_4806-01 - Verpflichtende Managementschnittstelle
Der Konnektor MUSS LAN-seitig über eine Managementschnittstelle für Konfiguration und Diagnose verfügen.
Die Ausführung der Schnittstelle ist herstellerspezifisch, MUSS aber entweder als Konfigurations-Frontend im Sinne einer eigenständigen Client-Applikation oder als Web-Oberfläche ausgeprägt sein.
Wenn die Schnittstelle als Web-Oberfläche ausgeprägt ist, MUSS im Handbuch beschrieben sein, wo angegeben ist, welche Browser-Versionen für welche Betriebssysteme unterstützt werden (bspw. im Handbuch selbst oder über einen Link auf eine Web-Seite des Herstellers), und wo diese als installierbares Softwarepaket oder direkt ausführbare Datei bezogen werden können.
Die Verbindung zur Managementschnittstelle MUSS zur Sicherung der Vertraulichkeit, Integrität und Authentizität mittels TLS abgesichert sein und dabei MUSS mindestens eins der kryptographischen Verfahren gemäß Tabelle TAB_KON_866 verwendet und dabei die Vorgaben aus gemSpec_Krypt durchgesetzt werden.
Die Managementschnittstelle MUSS in thematisch gegliederte Konfigurationsbereiche unterteilt sein. Die konkrete Gliederung selbst ist herstellerspezifisch.
Die Managementschnittstelle KANN einen Managementbereich aufweisen, der nur für autorisierte Techniker des Herstellers zugänglich ist. Ein Zugriff auf diesen Bereich MUSS durch eine eigene Authentisierungsfunktion geschützt werden (z. B. durch Passwortschutz).
[<=]
Die über die Managementschnittstelle zu erreichenden und zu verändernden Inhalte werden erhoben in:
- diesem Kapitel
- in allen Betriebsaspektekapiteln der Funktionsmerkmale, sowie der Übergreifenden Festlegungen
- den Fachmodulspezifikationen der Fachanwendungen (siehe Kapitel 4.3.4).
- Den übergreifenden Spezifikationen [gemSpec_Net] und [gemSpec_PKI]
Eine Ergänzung um weitere, herstellerspezifische Konfigurationsinhalte ist möglich.
TIP1-A_5661 - Automatisierung Managementschnittstelle
Der Konnektor MUSS für die Automatisierung von Konnektor-Tests alle Funktionen, die über die Managementschnittstelle bereitgestellt werden, über eine LAN-seitige Schnittstelle ohne graphische Benutzerführung bereitstellen.
Der Konnektorhersteller MUSS eine Dokumentation der Schnittstelle bereitstellen, welche die Nutzung so beschreibt, dass die Schnittstelle von der gematik in vollem Umfang genutzt werden kann. Die Dokumentation MUSS der gematik im Regelfall zwei Wochen vor Einreichung des Zulassungsobjekts bereitgestellt werden. Von diesem Regelfall KANN in Abstimmung mit der gematik abgewichen werden.
Die Schnittstelle SOLL mittels JSON [RFC7159] bereitgestellt werden. Wenn die Bereitstellung nicht mittels JSON erfolgt, MUSS sie über eine vergleichbare Technologie erfolgen.
Der Zugriff auf die Schnittstelle MUSS in RU/TU erlaubt sein. Falls der Zugriff in der PU erlaubt ist, MUSS er dort ebenso wie die Managementschnittstelle abgesichert sein:
-
Die Verbindung zu dieser Schnittstelle MUSS zur Sicherung der Vertraulichkeit, Integrität und Authentizität durch Nutzung eines kryptographischen Verfahrens gemäß [gemSpec_Krypt] abgesichert werden, falls die Sicherheit der übertragenen Daten nicht auf andere Weise erreicht wird. Die Absicherung der Daten kann z. B. durch Nutzung von TLS unter Berücksichtigung der in [gemSpec_Krypt] angegebenen Algorithmen und Schlüssellängen geschehen.
Der Konnektor MUSS die Schnittstelle mittels Benutzername und Passwort oder einem mindestens gleich starken Mechanismus vor unberechtigtem Zugang schützen.
Ansonsten DARF der Zugriff in der PU NICHT möglich sein.
[<=]TIP1-A_4807 - Mandantenübergreifende Managementschnittstelle
Das Management des Konnektors MUSS über die Managementschnittstelle mandantenübergreifend erfolgen. Dies bedeutet insbesondere, dass ein Administrator (gemäß seiner Zugriffsberechtigungen) in einer Management-Session alle Einstellungen einsehen und verändern können MUSS, egal welchem Mandanten diese Werte zugeordnet sind.
[<=]TIP1-A_5658 - Konnektor, rollenspezifische Endpunkte der Managementschnittstelle
Der Konnektor MUSS die Managementschnittstelle mit zwei getrennten Endpunkten implementieren. Der Konnektor MUSS sicherstellen, dass auf den einen Endpunkt nur Nutzer mit der Rolle Lokaler-Administrator oder Super-Administrator zugreifen können, und auf den anderen Endpunkt nur Nutzer mit der Rolle Remote-Administrator.
[<=]TIP1-A_5005 - Protokollierung in der Managementschnittstelle
Jede Änderung, die ein Administrator vornimmt, MUSS protokolliert werden durch TUC_KON_271 „Schreibe Protokolleintrag“ {
topic=„MGM/ADMINCHANGES“;
eventType=Op;
severity=Info;
parameters =(„User=$AdminUsername,
RefID=$ReferenzID,
NewVal=$NeuEingestellterWert“)}
Der hier geforderte Logging-Level gilt, wenn nicht an anderer Stelle eine abweichende Regelung spezifiziert ist.
Wenn die Änderung über ein Remote-Management-System durchgeführt wird, ohne dass ein Remote-Administrator im Konnektor konfiguriert ist, so MUSS als User eine Referenz auf das Remote-Management-System verwendet werden.
Passwörter DÜRFEN NICHT in den Protokolleinträgen geschrieben werden.
[<=]
4.3.1 Zugang und Benutzerverwaltung des Konnektormanagements
Der Konnektor verfügt über keine Verwaltung der fachlichen Nutzer, wohl aber über eine Verwaltung der Nutzer, die in der Rolle eines Administrators den Konnektor konfigurieren und die Protokolle einsehen dürfen. Dabei werden drei Administrator-Rollen unterschieden:
- Lokaler-Administrator: zur Konfiguration des Konnektors über die lokale Managementschnittstelle
- Remote-Administrator: zur Konfiguration des Konnektors über die remote Managementschnittstelle.
- Super-Administrator: zur Verwaltung von Benutzerkonten und zur Konfiguration des Konnektors über die lokale Managementschnittstelle
TIP1-A_4808-01 - Zugangsschutz der Managementschnittstelle
Der Konnektor MUSS sicherstellen, dass die Managementschnittstelle vor unberechtigtem Zugang geschützt ist. Die Managementschnittstelle MUSS durch eine Kombination aus Benutzername und Passwort oder einen mindestens gleich starken Mechanismus vor unberechtigtem Zugang geschützt sein.
Für die Passworterstellung MUSS der Konnektor mindestens folgende Aspekte berücksichtigen:
- dem Benutzer muss es möglich sein, die Zeichen eines Passworts aus den Zeichenklassen Großbuchstaben, Kleinbuchstaben, Sonderzeichen und Ziffern zu wählen. Ein Passwort muss Zeichen aus mindestens drei dieser Zeichenklassen enthalten.
- ein Passwort muss mindestens 8 Zeichen lang sein
- ein Passwort darf nicht die zugehörige Benutzerkennung enthalten (weder vorwärts noch rückwärts, bei Vergleich unter Ignorierung der Groß- und Kleinschreibung)
- die Wiederholung alter Passwörter beim Passwortwechsel durch den Benutzer selbst muss vom Konnektor verhindert werden (Passworthistorie). Dazu muss der Konnektor mindestens die letzten drei Passwörter eines Benutzers bei der Passwortneuvergabe erkennen und als neues Passwort ablehnen.
- für die Erstanmeldung neuer Benutzer müssen Einmalpasswörter vergeben werden, also Passwörter, die nach einmaligem Gebrauch gewechselt werden müssen. Gleiches gilt, wenn ein Passwort eines Benutzers vom Super-Admin zurückgesetzt wird.
- jeder Benutzer muss sein eigenes Passwort jederzeit ändern können
- bei der Eingabe darf das Passwort nicht im Klartext auf dem Bildschirm angezeigt werden
- die Passwörter müssen im Konnektor zugriffssicher gespeichert werden
- der Konnektor muss nach einem durch den Super-Admin konfigurierbaren Zeitraum (Voreinstellung: 120 Tage) einen Passwortwechsel beim nächsten Login initiieren
- erfolglose Anmeldeversuche müssen mit einer kurzen Fehlermeldung ohne Angabe von näheren Einzelheiten abgelehnt werden. Insbesondere darf bei erfolglosen Anmeldeversuchen nicht erkennbar sein, ob der eingegebene Benutzername oder das eingegebene Passwort (oder beides) falsch ist.
- Nach einer Fehleingabe des Passworts muss eine Verzögerung bis zur nächsten Eingabemöglichkeit des Passworts für dieselbe Benutzerkennung erfolgen. Die Verzögerung soll 3 Sekunden betragen.
Näheres hierzu regeln die Schutzprofile des Konnektors.
TIP1-A_4810 - Benutzerverwaltung der Managementschnittstelle
Der Konnektor MUSS eine Benutzerverwaltung für die Managementschnittstelle enthalten, in der anmeldeberechtigte Administratoren-Benutzer definiert werden können.
Die Benutzerverwaltung MUSS die Administrator-Rollen Lokaler-Administrator, Remote-Administrator und Super-Administrator unterstützen.
Den Administrator-Rollen MÜSSEN folgende Rechte zugewiesen sein:
- Lokaler-Administrator:
- ausschließlicher Zugriff über lokalen Endpunkt der Managementschnittstelle
- Verwaltung aller Konfigurationsdaten und Durchführung aller Administratoraktionen mit Ausnahme von:
- Benutzerverwaltung gemäß Tabelle TAB_KON_655
- Remote-Administrator:
- ausschließlicher Zugriff über remote-Endpunkt der Managementschnittstelle
- Verwaltung aller Konfigurationsdaten und Durchführung aller Administratoraktionen mit Ausnahme von:
- Benutzerverwaltung gemäß Tabelle TAB_KON_655
- Konfigurationseinstellungen und Administratoraktionen gemäß Tabelle TAB_KON_851
- Super-Administrator:
- ausschließlicher Zugriff über lokalen Endpunkt der Managementschnittstelle
- Benutzerverwaltung gemäß Tabelle TAB_KON_655
- Verwaltung aller Konfigurationsdaten und Durchführung aller Administratoraktionen
Tabelle 360: TAB_KON_655 Konfigurationen der Benutzerverwaltung (Super-Administrator)
ReferenzID |
Belegung |
Bedeutung und Administrator-Interaktion |
---|---|---|
MGM_USER_LIST |
Liste von Benutzernamen und deren Kontaktdaten |
Liste von Benutzern und deren Kontaktdaten. Benutzerkonten MÜSSEN angelegt, geändert und gelöscht werden können. Das Passwort eines Benutzerkontos MUSS neu gesetzt werden können. |
MGM_ADMIN _RIGHTS |
Liste von Zugriffsrechten eines Benutzers |
i. Eindeutige Zuordnung eines Benutzerkontos zu einer Rolle. Die Benutzerverwaltung MUSS sicherstellen, dass zu jeder Zeit mindestens ein Benutzerkonto mit der Rolle Super- Administrator vorhanden ist. Gewähren/Entziehen von Rechten für Benutzerkonten: ii. Zugriffsrechte bezüglich der Konfigurationsbereiche. iii. Recht zum Aufbau einer Remote- Management-Session und/oder zur Konfiguration des Remote-Management gemäß TAB_KON_663 (USER_INIT_REMOTESESSION). iv. Recht für einen Werksreset (USER_RESET_PERMISSION) |
Tabelle 361: TAB_KON_656 Konfigurationen der Benutzerverwaltung
ReferenzID |
Belegung |
Bedeutung und Administrator-Interaktion |
---|---|---|
MGM_USER_INFO |
Kontaktdaten |
Der angemeldete Benutzer MUSS seine Kontaktdaten ändern können. Der Benutzername DARF NICHT änderbar sein. |
[<=]
4.3.2 Konnektorname und Versionsinformationen
TIP1-A_4811 - Festlegung des Konnektornamens
Der Konnektor MUSS die Konfiguration und Nutzung eines sprechenden Konnektornamens unterstützen, der identisch zum Hostnamen des Konnektors ist. Der Konnektorname MUSS dauerhaft an der Managementschnittstelle angezeigt werden.
Die Managementschnittstelle MUSS es einem Administrator ermöglichen Konfigurationsänderungen gemäß Tabelle TAB_KON_657 vorzunehmen:
Tabelle 362: TAB_KON_657 Konfigurationsparameter des Konnektornamens
ReferenzID |
Belegung |
Bedeutung und Administrator-Interaktion |
---|---|---|
MGM_KONN_ HOSTNAME |
12 Zeichen |
Der Konnektorname MUSS folgende Anforderungen erfüllen (in Anlehnung an die Definition eines „Labels“ in [RFC1034]): • Verwendung der Buchstaben „A bis Z“ und „a bis z“, • Verwendung der Ziffern „0 bis 9“, • als Sonderzeichen „–“ (Minus), sowie • eine maximale Länge von 12 Zeichen, Die Verwendung weiterer Sonderzeichen sowie des Leerzeichens DARF NICHT möglich sein. |
[<=]
TIP1-A_4812 - Anzeige der Versionsinformationen (Selbstauskunft)
Der Administrator MUSS die Versionsinformationen des Konnektors einsehen können. Dabei MÜSSEN alle über ProductInformation.xsd definierten Elemente verständlich angezeigt werden.
Ferner MUSS der Administrator dabei die aktuelle Firmware-Gruppenversion des Konnektors einsehen können.
[<=]
A_18929 - Sichtbarkeit der ECC-Vorbereitung an der Managementschnittstelle
Der Hersteller MUSS die ECC-Vorbereitung der gSMC-K durch die Bezeichnung „ECC-Vorbereitet“ zusammen mit den Versionsinformationen des Konnektors an der Managementschnittstelle sichtbar machen.
[<=]
TIP1-A_7255 - Anzeige von Fachmodulversionen
Der Administrator MUSS die Versionen der in der Firmware des Konnektors enthaltenen Fachmodule einsehen können.
[<=]
Fachmodulversionsinformationen sind nicht Bestandteil der Selbstauskunft gemäß ProductInformation.xsd.
4.3.3 Konfigurationsdaten: Persistieren sowie Export-Import
TIP1-A_4813 - Persistieren der Konfigurationsdaten
Der Konnektor MUSS die Konfigurationsdaten nach Änderung persistieren. Dabei MÜSSEN Integrität, Authentizität und Vertraulichkeit der Konfigurationsdaten gewährt sein. Der Mechanismus hierfür ist herstellerspezifisch.
Der Konnektor MUSS sicherstellen, dass immer ein integerer Konfigurationssatz persistiert ist.
Bei der Konnektorinitialisierung MÜSSEN die persistierten Konfigurationsdaten eingelesen werden.
Die Verpflichtung zur Persistierung gilt für alle innerhalb der Konnektor- und Fachmodul-Spezifikationen erhobenen Konfigurationsdaten.
[<=]
TIP1-A_4814 - Export- Import von Konfigurationsdaten
Der Administrator MUSS die gesamten Konfigurationsdaten des Konnektors ex- und importieren können. Dazu gehören die Konfigurationsparameter des Konnektors, die persistenten Daten wie im Informationsmodell des Konnektors (Tabelle TAB_KON_507 Informationsmodell Entitäten) definiert und die Pairing Informationen der Kartenterminals.
Die Konfigurationsdaten des Anwendungs- und Netzkonnektors KÖNNEN gemeinsam oder getrennt exportiert bzw. importiert werden. Das Format der Konfigurationsdaten ist herstellerspezifisch.
Auf hardwareseitig baugleichen Geräten:
- MUSS der Import von Konfigurationsdateien möglich sein, die unter der gleichen oder einer früheren Firmwareversion exportiert wurden
- SOLL der Import von Konfigurationsdateien möglich sein, die unter einer neueren Firmwareversion exportiert wurd
(für Fachmodule siehe Kapitel 4.3.4)
Der Konnektor MUSS sicherstellen, dass der Exportvorgang nur von einem am Konnektor angemeldeten User mit mindestens der Rolle Administrator ausgelöst werden kann.
Der Konnektor MUSS sicherstellen, dass der Importvorgang nur von einem am Konnektor angemeldeten User mit der Rolle Super-Administrator ausgelöst werden kann.
Sowohl Ex- als auch Import MÜSSEN protokolliert werden durch TUC_KON_271 „Schreibe Protokolleintrag“ {
topic = „MGM/CONFIG_EXIMPORT“;
eventType = Op;
severity = Info;
parameters = („User=$AdminUsername,
Mode=[Export/Import]“)}.
[<=]
A_19738 - Optionaler Import von Konfigurationsdaten durch lokalen Administrator
Der Konnektor KANN einem am Konnektor angemeldeten User mit der Rolle Lokaler-Administrator erlauben, den Importvorgang von Konfigurationsdateien auszulösen, wenn in den Konfigurationsdaten keine Benutzerdaten gemäß Tabelle TAB_KON_655 enthalten sind. [<=]
Nähere Vorgaben zum Ablauf des Imports der Kartenterminalinformationen finden sich im Kapitel 4.1.4.6.3.
TIP1-A_4815 - Export: Schutz der Integrität, Authentizität und Nichtabstreitbarkeit
Die Integrität, Authentizität und Nichtabstreitbarkeit der exportierten Daten MUSS sichergestellt werden. Dies MUSS durch eine Signatur mit der OSIG-Identität der SM-B oder mit einem herstellerspezifischen Schlüsselpaar realisiert werden. In die zu signierenden Daten MUSS eine Zeitangabe zum Signaturzeitpunkt integriert werden. Beim Import MUSS die Signatur vor der Übernahme der Daten erfolgreich verifiziert worden sein. Im Laufe des Importvorgangs MUSS dem Administrator das zur Signatur zugehörige Zertifikat (oder der herstellerspezifische öffentliche Schlüssel) sowie die Zeitangabe zum Signaturzeitpunkt der exportierten Konfiguration angezeigt werden, und der Administrator MUSS explizit bestätigen, dass er die zu dem angezeigten Zeitpunkt gehörige Konfiguration importieren will.
Wird die SM-B zur Signatur eingesetzt, so MUSS die Prüfung des genutzten Signaturzertifikats anhand von TUC_KON_037 erfolgen. Das Zertifikat der OSIG-Identität, mit dem die Daten signiert wurden, MUSS zusammen mit den exportierten Daten gespeichert werden, um eine Verifikation der Signatur auf neuen Konnektoren auch ohne Zugriff auf die entsprechende SM-B zu ermöglichen.
Da Konfigurationsdaten mit einem Schutzbedarf von mindestens „Hoch“ für Authentizität und Nichtabstreitbarkeit exportiert werden (z. B. Pairing-Geheimnisse (ShS.KT.AUT) der Kartenterminals), MUSS durch geeignete Maßnahmen sichergestellt werden, dass der Zugriff auf die Daten auf eine natürliche Person rückführbar ist. Dies kann organisatorisch (durch Einträge des Administrators in ein Betriebsführungs-Handbuch beim Nutzer) technisch (durch eine personenbezogene Administratorenverwaltung) oder äquivalent herstellerspezifisch erreicht werden.
[<=]TIP1-A_4816 - Export: Schutz der Vertraulichkeit
Zum Schutz der Vertraulichkeit der exportierten Daten MÜSSEN die Daten vor dem Export verschlüsselt werden. Dies kann durch asymmetrische oder symmetrische Verschlüsselungsverfahren nach [gemSpec_Krypt] realisiert werden.
Wird ein rein symmetrisches Verfahren eingesetzt, so MUSS als Mindestanforderung eine Passphrase einer Mindestlänge von 16 Zeichen (Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen) zur Verschlüsselung der Daten eingesetzt werden. Diese Passphrase MUSS dabei vom Konnektor zufällig generiert werden und aus einer Kombination von Buchstaben und Ziffern bestehen. Diese Passphrase MUSS dem Administrator anschließend angezeigt werden.
[<=]4.3.4 Administration von Fachmodulen
Die Konfiguration von Fachmodulen ist innerhalb der Managementschnittstelle des Konnektors von der Konfiguration der Plattformanteile des Konnektors logisch entkoppelt. Die Festlegungen, welche Konfigurationsparameter und welche zusätzlichen administrativen Funktionen für ein Fachmodul benötigt werden, werden in den jeweiligen Fachmodulspezifikationen getroffen. Der Konnektor muss aber für jedes Fachmodul hinsichtlich der Administrierbarkeit des Fachmoduls die folgende Basisfunktionalität zur Verfügung stellen:
TIP1-A_4818 - Konfigurieren von Fachmodulen
Neben den Konfigurationsbereichen der Plattformanteile des Konnektors, MUSS die Managementschnittstelle auch die Konfiguration der im Konnektor enthaltenen Fachmodule unterstützen.
Ein Administrator MUSS die in den Fachmodulspezifikationen enthaltenen Konfigurationsparameter ändern und die dort definierten Informationen einsehen können.
Der Konnektor MUSS die Konfigurationsdaten von Fachmodulen nach deren Änderung persistieren, sowie bei einem Neustart eines Fachmoduls die Fachmodul-Konfigurationsdaten vor der Initialisierung des Fachmoduls einlesen.
Die persistierten Fachmodulkonfigurationsdaten MÜSSEN ebenso wie die plattformeigenen Konfigurationsdaten hinsichtlich ihrer Integrität und Authentizität sowie ihrer Vertraulichkeit geschützt werden.
Der Ex- und Import von Fachmodulkonfigurationen MUSS äquivalent zum Ex- und Import der Plattformanteile für den Administrator möglich sein (siehe 4.3.3). Die Konfigurationsdaten der Fachmodule KÖNNEN dabei in der Gesamt Export-Datei des Konnektors enthalten sein oder separat exportiert und importiert werden.
[<=]TIP1-A_5484 - Persistente Speicherung von Konfigurationsdaten der Fachmodule
Der Konnektor MUSS den Fachmodulen die Möglichkeit bereitstellen, die in den Fachmodulspezifikationen gekennzeichneten Konfigurationsdaten persistent zu speichern, auszulesen und zu löschen. Je Fachmodul muss ein exklusiv durch das Fachmodul nutzbarer Speicherbereich verwendet werden.
Namenskonvention zur Kennzeichnung der Konfigurationsdaten der Fachmodule für persistent zu speichernde Daten:
FM_<fmName>_<fmDataName>
Tabelle 363: TAB_KON_833 Bezeichner für persistente Konfigurationsdaten für Fachmodule
Bezeichner |
Bedeutung |
---|---|
FM |
fester Namensbestandteil zur Kennzeichnung von persistenten fachmodulspezifischen Konfigurationsdaten |
_ |
Trennzeichen |
<fmName> |
Name des Fachmoduls (innerhalb eines Fachmoduls konstanter Bezeichner) |
_ |
Trennzeichen |
<fmDataName> |
Name der persistent zu speichernden fachmodulspezifischen Konfigurationsdaten |
[<=]
4.3.5 Neustart und Werksreset
A_21743 - Laufzeitverlängerung gSMC-K: Erneuerte Zertifikate nach Werksreset verwenden
Der Konnektor, dessen gSMC-K-Zertifikate erneuert wurden, MUSS auch nach einem Werksreset die erneuerten Zertifikate verwenden. [<=]
TIP1-A_4819 - Auslösen eines Konnektorneustarts
Der Administrator MUSS einen Neustart des Konnektors auslösen können.
[<=]TIP1-A_4820 - Werksreset des Konnektors
Ein Administrator mit USER_RESET_PERMISSION MUSS einen Werksreset des Konnektors auslösen können.
Zur Durchführung des Werksreset MUSS der Administrator nach Funktionsaufruf per Sicherheitsabfrage zur Bestätigung des Werksresets aufgefordert werden. Nach bestätigter Sicherheitsabfrage MUSS der Konnektor die gesamte Konfiguration des Konnektors und alle internen Speicher, mit Ausnahme des aktuellen Vertrauensraums sowie der Sicherheitsprotokolle und der installierten Firmware, auf den Auslieferungszustand zurücksetzen. Die in CERT_IMPORTED_CA_LIST enthaltenen Zertifikate MÜSSEN aus dem aktuellen Vertrauensraum gelöscht werden.
Die Durchführung des Werksresets MUSS protokolliert werden durch TUC_KON_271 „Schreibe Protokolleintrag“ {
topic = „MGM/FACTORYSETTINGS“;
eventType = Op;
severity = Info;
parameters = „User=$AdminUsername“}.
Dieser Protokolleintrag DARF NICHT durch einen erfolgreichen Werksreset verloren gehen.
Der Hersteller MUSS ferner einen alternativen, herstellerspezifischen Weg zum Auslösen des Werksresets vorsehen, welcher die Arbeitsabläufe beim Nutzer nur minimal unterbricht. Auch für diesen zusätzlichen Weg MUSS zuvor eine Authentisierung durch eine Kombination aus Benutzername und Passwort oder einem mindestens gleich starken Mechanismus erfolgen. Der Mechanismus MUSS auch dann funktionieren, wenn sich keiner der in der Benutzerverwaltung definierten Administratoren mehr erfolgreichen anmelden kann.
[<=]
4.3.6 Leistungsumfänge und Standalone-Szenarios
Obgleich der Konnektor in seinem Auslieferungszustand alle Leistungsmerkmale aufweisen muss, die gemäß Produkttypssteckbrief gefordert werden, so soll es dem Administrator doch ermöglicht werden grundsätzliche Leistungsumfänge gezielt deaktivieren zu können, um den Konnektor so besser in die organisatorische/technische Struktur der Betriebsstätte eingliedern zu können.
TIP1-A_4821-02 - Aktivieren/Deaktivieren von Leistungsumfängen
Die Managementschnittstelle MUSS es einem Administrator ermöglichen Konfigurationsänderungen gemäß Tabelle TAB_KON_658 vorzunehmen:
Tabelle 364: TAB_KON_658 Aktivieren/Deaktivieren von Leistungsumfängen
ReferenzID |
Belegung |
Bedeutung und Administrator-Interaktion |
---|---|---|
MGM_LU_ONLINE |
Enabled/ Disabled |
Der Administrator MUSS den „Leistungsumfang Online“ aktivieren und deaktivieren können. Bei Veränderung MUSS TUC_KON_256 gerufen werden { topic = „MGM/LU_CHANGED/LU_ONLINE“; eventType = Op; severity = Info; parameters = „Active=$MGM_LU_ONLINE“} |
MGM_LU_SAK |
Enabled/ Disabled |
Der Administrator MUSS den „Leistungsumfang Signaturanwendungskomponente“ aktivieren und deaktivieren können. Default-Wert: Enabled Bei Veränderung MUSS TUC_KON_256 gerufen werden { topic = „MGM/LU_CHANGED/LU_SAK“; eventType = Op; severity = Info; parameters = „Active=$MGM_LU_SAK“} |
Der Konfigurationsparameter MGM_LU_SAK wirkt hauptsächlich in dem Funktionsmerkmal „Signaturdienst“ (siehe Kapitel 4.1.8).
Ist MGM_LU_ONLINE Disabled, so baut der Konnektor grundsätzlich keine Online-Verbindungen auf (weder zur TI, noch zum SIS). Der Parameter wirkt hauptsächlich in den Funktionsmerkmalen:
- „Zertifikatsdienst“ (Kapitel 4.1.9)
- „TLS-Dienst“ (Kapitel 4.1.11)
- „Anbindung LAN/WAN“ (Kapitel 4.2.1)
- „VPN-Client“ (Kapitel 4.2.4)
- „Zeitdienst“ (Kapitel 4.2.5)
- „Software-Aktualisierungsdienst (KSR-Client)“ (Kapitel 4.3.9)
- „LDAP-Proxy" (Kapitel 4.1.12)
Ob es sich bei einem Konnektor um den losgelöst (stand alone) vom Netz der Einsatzumgebung betriebenen handelt, also einen Konnektor, auf welchen kein Clientsystem zugreift, muss diesem mitgeteilt werden:
TIP1-A_4822 - Konnektor Standalone einsetzen
Die Managementschnittstelle MUSS es einem Administrator ermöglichen Konfigurationsänderungen gemäß Tabelle TAB_KON_659 vorzunehmen:
Tabelle 365: TAB_KON_659 Konnektor Standalone einsetzen
ReferenzID |
Belegung |
Bedeutung und Administrator-Interaktion |
---|---|---|
MGM_STANDALONE _KON |
Enabled/ |
Der Administrator MUSS den Konnektor als alleinstehend konfigurieren können. |
Das Setzen von MGM_STANDALONE_KON auf Enabled dient dem Konnektor als Anzeige, dass dieser ohne angeschlossenes Clientsystem (Primärsystem) betrieben wird. Diese Information kann seitens der Fachmodule verwendet werden, damit diese sich im Standalone-Fall anders als im Normalfall verhalten.
4.3.7 Online-Anbindung verwalten
Um Zugang zur TI erlangen zu können, muss der Betriebsstättenverantwortliche einen Vertrag mit einem Zugangsdienstprovider (ZGDP) abgeschlossen haben. Von diesem erhält er eine ContractID. Der Administrator muss den Konnektor (genauer das NK-Zertifikat C.NK.VPN) mit dieser Information unter Nutzung einer SM-B über den Registrierungsdienst des ZGDP bei diesem freischalten.
Die Berechtigung zur Einwahl in die TI ist von der Gültigkeit der beiden bei der Freischaltung übermittelten Zertifikate abhängig (C.NK.VPN und C.HCI.OSIG). Die Berechtigung zur Einwahl in die TI wird verweigert, bzw. eine bestehende Verbindung zur TI wird beendet, wenn ein Zertifikat abgelaufen oder gesperrt ist. Aus diesem Grund muss der Administrator vor Ablauf eines der beiden Zertifikate eine wiederholte Registrierung mit neuem Netzkonnektorzertifikat bzw. neuer SM-B beim ZGDP durchführen. (Hinweis: neue NK-Zertifikate werden erst mit Etablierung der Nachladefunktionalität für gSMC-K verfügbar sein.)
Soll ein Konnektor außer Betrieb genommen werden oder wird der Vertrag mit einem ZGDP gekündigt, muss der Administrator den Konnektor über den Registrierungsdienst des ZGDP abmelden.
TIP1-A_4824 - Freischaltdaten des Konnektors bearbeiten
Der Administrator MUSS die in TAB_KON_661 aufgelisteten Parameter über die Managementschnittstelle konfigurieren und die in TAB_KON_732 aufgelisteten Parameter ausschließlich einsehen können.
Tabelle 366: TAB_KON_661 Konfigurationsparameter der Konnektorfreischaltung
ReferenzID |
Belegung |
Bedeutung und Administrator-Interaktion |
---|---|---|
MGM_ZGDP_ |
String |
Der Administrator MUSS die vom Zugangsdienstprovider für die Freischaltung des Konnektors erhaltene ContractID eingeben können. |
MGM_ZGDP_ |
ICCSN |
Der Administrator MUSS die zur Freischaltung zu verwendende SM-B aus der Liste der verwalteten SM-Bs auswählen können. |
Tabelle 367: TAB_KON_732 Einsehbare Konfigurationsparameter der Konnektorfreischaltung
ReferenzID |
Belegung |
Bedeutung und Administrator-Interaktion |
---|---|---|
MGM_ZGDP_ |
URI |
URI des Registrierungsservers des Zugangsdienstproviders |
Den Zustand der Freischaltung verwaltet der Konnektor gemäß Tabelle TAB_KON_662 Zustandswerte der Konnektorfreischaltung.
Im Auslieferungszustand MUSS MGM_TI_ACCESS_GRANTED=Disabled belegt sein.
Tabelle 368: TAB_KON_662 Zustandswerte der Konnektorfreischaltung
ReferenzID |
Belegung |
Zustandswerte |
---|---|---|
MGM_TI_ |
Enabled/ |
Status der Freischaltung des Konnektors: |
TIP1-A_4825 - Konnektor zur Nutzung (wiederholt) freischalten
Der Administrator MUSS den Konnektor über folgenden Mechanismus zur Nutzung freischalten bzw. eine vorhandene Freischaltung mit einer neuen SM-B aktualisieren können (Voraussetzung ist eine korrekte Konfiguration aller für einen Online-Zugang erforderlicher Parameter):
- Der Konnektor MUSS eine registerKonnektorRequest-Struktur gemäß ProvisioningService.xsd [gemSpec_VPN_ZugD] erstellen und mit den entsprechenden Parametern befüllen (aktuelles Datum/Uhrzeit, C.NK.VPN, MGM_ ZGDP_CONTRACTID). Der Konnektor MUSS die Request-Nachricht mittels der ausgewählten SM-B (ID.HCI.OSIG von MGM_ZGDP_SMCB) im Element registerKonnektorRequest/Signature signieren und das SM-B-Zertifikat im Element X509Data ablegen.
Ist der nötige Sicherheitszustand für den privaten Schlüssel der SM-B nicht gesetzt, MUSS der Konnektor zur PIN-Verifikation an dem Kartenterminal auffordern, in dem die SM-B steckt.
- Der Konnektor ermittelt die URI des Registrierungsservers (MGM_ZGDP_REGSERVER) durch eine DNS-Anfrage nach dem SRV und TXT Resource Record „_regserver._tcp.<DNS_DOMAIN_VPN_ZUGD_INT>„
- Der Konnektor ruft unter Verwendung der erzeugten Request-Nachricht die in [gemSpec_VPN_ZugD#Tab_ZD_registerKonnektor] definierte Operation I_Registration_Service::registerKonnektor mit der Zieladresse MGM_ZGDP_REGSERVER auf.
- Der Konnektor zeigt dem Administrator den Inhalt von registerKonnektorResponse/AdditionalInformation und /Status an
- Der Response der Operation wird verarbeitet:
- Setze MGM_TI_ACCESS_GRANTED auf
- Enabled, wenn /RegistrationStatus = „Registriert“
- Disabled, wenn /RegistrationStatus = „Nicht registriert“
- Persistiere diese Zustandsinformation zusammen mit dem VPN:ContractStatus
- Verteile das folgende interne Ereignis über TUC_KON_256 {
topic = ”MGM/TI_ACCESS_GRANTED“;
eventType = Op;
severity = Info;
parameters = „Active=$MGM_TI_ACCESS_GRANTED“;
doDisp = false }
Wenn eine Reregistrierung mit einer neuen SMC-B fehlschlägt (Request wird mit einem SOAP-Error beantwortet ) dann ist der Konnektor nicht registriert (MGM_TI_ACCESS_GRANTED = Disabled).
[<=]
TIP1-A_4826-01 - Status Konnektorfreischaltung einsehen
Der Administrator MUSS über die Managementschnittstelle den aktuellen Freischaltstatus einsehen können (MGM_TI_ACCESS_GRANTED). Ist der Konnektor aktuell freigeschaltet, so MÜSSEN der VPN:ContractStatus, die für die Freischaltung verwendete(n) SMC-B und die verwendeten C.NK.VPN-Zertifikate angezeigt werden (RSA und/oder ECC).
[<=]
Möchte ein Konnektoreigentümer das Gerät weiterveräußern oder vollständig außer Betrieb nehmen, so sollte er eine vorhandene Freischaltung zuvor rückgängig machen.
TIP1-A_4827 - Konnektorfreischaltung zurücknehmen
Ist MGM_TI_ACCESS_GRANTED=Enabled, dann MUSS der Administrator über die Managementschnittstelle des Konnektors die Freischaltung über den folgenden Mechanismus zurücknehmen können:
- Der Administrator MUSS eine Sicherheitsabfrage zur Zurücknahme der Freischaltung bestätigen
- Der Konnektor MUSS eine deRegisterKonnektorRequest-Struktur gemäß [gemSpec_VPN_ZugD] erstellen und mit den entsprechenden Parametern befüllen (aktuelles Datum/Uhrzeit, C.NK.VPN, MGM_ ZGDP_CONTRACTID)
- Der Konnektor MUSS die Request-Nachricht mittels einer verfügbaren SM-B (ID.HCI.OSIG) im Element deRegisterKonnektorRequest/Signature signieren. (MGM_ ZGDP_SMCB ist zu bevorzugen, es kann aber auch jede andere SM-B verwendet werden)
Ist der nötige Sicherheitszustand für den privaten Schlüssel der SM-B nicht gesetzt, MUSS der Konnektor zur PIN-Verifikation an dem Kartenterminal auffordern, in dem die SM-B steckt.
- Der Konnektor ermittelt die URI des Registrierungsservers (MGM_ZGDP_REGSERVER) durch eine DNS-Anfrage nach dem SRV und TXT Resource Record „_regserver._tcp.<DNS_DOMAIN_VPN_ZUGD_INT>„
- Der Konnektor ruft unter Verwendung der erzeugten Request-Nachricht die in [gemSpec_VPN_ZugD#Tab_ZD_deregisterKonnektor] definierte Operation I_Registration_Service::deRegisterKonnektor mit der Zieladresse MGM_ZGDP_REGSERVER auf.
- Der Konnektor zeigt dem Administrator den Inhalt von deregisterKonnektorResponse/AdditionalInformation /ContractStatus und /RegistrationStatus an
- Der Response der Operation wird verarbeitet:
- Setze MGM_TI_ACCESS_GRANTED auf
- Enabled, wenn /RegistrationStatus = „Registriert“
- Disabled, wenn /RegistrationStatus = „Nicht registriert“
- Persistiere diese Zustandsinformation zusammen mit dem Zeitpunkt
- Verteile das folgende interne Ereignis über TUC_KON_256: {
topic = ”MGM/TI_ACCESS_GRANTED“;
eventType = Op;
severity = Info;
parameters = „Active=$MGM_TI_ACCESS_GRANTED“;
doDisp=false }
Wenn eine Deregistrierung mit einer neuen SMC-B fehlschlägt (Request wird mit einem SOAP-Error beantwortet) dann ist der Konnektor weiterhin registriert (MGM_TI_ACCESS_GRANTED = Enabled).
[<=]
TIP1-A_5655 - Deregistrierung bei Außerbetriebnahme
Der Hersteller des Konnektors MUSS im Handbuch den Administrator darüber informieren, dass der Konnektor bei dauerhafter Außerbetriebnahme (z. B. Verkauf, Schenkung, Entsorgung) beim Zugangsdienstprovider deregistriert werden muss.
[<=]A_23120 - Beschränkung der Anfragen zur Re-Registrierung (ECC-Migration)
Der Konnektor DARF die automatische Re-Registrierung mit seinem ECC-NK-Zertifikat NICHT öfter als einmal am Tag versuchen. [<=]
A_23150 - Konnektor (wiederholt) manuell registrieren
Der Konnektor MUSS dem Administrator über den Mechanismus in TUC_KON_411 ermöglichen, den Konnektor zu registrieren bzw. eine vorhandene Registrierung zu aktualisieren. Dabei MUSS der Administrator das für die Registrierung zu verwendende NK-Zertifikat (RSA oder ECC) und die zu verwendende SMC-B auswählen können.
[<=]
A_23122 - Konfigurationsschalter für automatische Re-Registrierung (ECC-Migration)
Der Konnektor MUSS dem Administrator ermöglichen, die automatische Re-Registrierung mit dem ECC-NK-Zertifikat ein- und auszuschalten. Im Auslieferungszustand muss die automatische Re-Registrierung eingeschaltet sein. [<=]
A_23121 - Konfigurationsschalter für Verwendung von ECC bei IPsec/IKE (ECC-Migration)
Der Konnektor MUSS dem Administrator ermöglichen, die Verwendung von ECC bei IPsec/IKE-Verbindungen ein- und auszuschalten. Die Verwendung von ECC darf nur eingeschaltet werden, wenn der Konnektor mit seinem ECC-NK-Zertifikat beim VPN-Zugangsdienst registriert ist. Die Verwendung von ECC darf nur ausgeschaltet werden, wenn der Konnektor mit seinem RSA-NK-Zertifikat beim VPN-Zugangsdienst registriert ist.
Im eingeschalteten Zustand MUSS der Konnektor die Vorgaben in A_17125 umsetzen. Im ausgeschalteten Zustand MUSS der Konnektor die Vorgaben in GS-A_4382 umsetzen.
[<=]
A_23149 - Konfigurationsschalter für Verwendung von ECC bei TLS (ECC-Migration)
Der Konnektor MUSS dem Administrator ermöglichen, die Verwendung von ECDSA-basierten Ciphersuiten bei TLS-Verbindungen ein- und auszuschalten. Im ausgeschalteten Zustand DARF der Konnektor ECDSA-basierte Ciphersuiten NICHT anbieten (Rolle TLS-Client) und NICHT auswählen (Rolle TLS-Server). Ebenfalls DARF der Konnektor dann NICHT während des TLS-Verbindungsaufbaus (genauer bei der Signatur der ephemeren (EC)DH-Schlüssel) mit ECDSA-basierten Zertifikaten bzw. deren privaten ECC-Schlüsselmaterial Daten authentisieren. [<=]
Es können separate Konfigurationsschalter für einzelne TLS-Strecken umgesetzt werden.
Es gelten darüber hinaus:
- A_22457 und A_22458 für die Auswahl der Ciphersuiten und Authentisierungsalgorithmen für die TLS-Verbindung zum eHealth-Kartenterminal
- A_21760-01 für die Auswahl der Zertifikate für die TLS-Server-Authentisierung (SOAP) und TLS-Client-Authentisierung (CETP) des Konnektors an der Clientsystemschnittstelle
4.3.8 Re-Registrierung des Konnektors mit weiterem NK-Zertifikat
Eine Re-Registrierung eines Konnektors am VPN-Zugangsdienst mit einem neuen NK-Zertifikat wird im Rahmen der ECC-Migration der IPsec-Kommunikation zum VPN-Zugangsdienst mit einem ECC-Zertifikat notwendig
A_21745-01 - Re-Registrierung mit neuem NK-Zertifikat automatisch durchführen
Nach einer vollständigen erfolgreichen automatischen Zertifikatserneuerung über TUC_KON_410 MUSS der Konnektor eine Re-Registrierung mit dem neuen Zertifikat beim Registrierungsdienst des VPN-Zugangsdienstes durchführen. Solange nach Bezug eines neuen C.NK.VPN-Zertifikats noch keine erfolgreiche Re-Registrierung durchgeführt wurde, MUSS der Konnektor genau einmal täglich TUC_KON_411 aufrufen. [<=]
A_21881 - Re-Registrierung mit neuem NK-Zertifikat manuell durchführen
Der Konnektor MUSS die manuelle Re-Registrierung mittels TUC_KON_411 durch den Administrator auch im kritischen Betriebszustand EC_NK_Certificate_Expired ermöglichen. [<=]
A_22332-01 - Re-Registrierung mit ECC-NK-Zertifikat automatisch durchführen (ECC-Migration)
Solange der Konnektor nur mit einem RSA-Zertifikat am VPN-Zugangsdienst registriert ist, MUSS er mindestens einmal wöchentlich die Re-Registrierung mit seinem ECC-NK-Zertifikat beim Registrierungsdienst durchführen. [<=]
A_21758-06 - TUC_KON_411 „Konnektor mit neuem NK-Zertifikat registrieren“
Der Konnektor MUSS den technischen Use Case TUC_KON_411 "Konnektor mit neuem NK-Zertifikat registrieren" umsetzen.
Tabelle 369: TAB_KON_932 – TUC_KON_411 „Konnektor mit neuem NK-Zertifikat registrieren“
Element |
Beschreibung |
---|---|
Name |
TUC_KON_411 "Konnektor mit neuem NK-Zertifikat registrieren" |
Beschreibung | Dieser TUC führt eine Neuregistrierung mit einem neuen (ECC) NK-Zertifikat durch. |
Auslöser |
A_22332, A_21745, Administrator |
Vorbedingungen |
|
Eingangsdaten |
Keine |
Komponenten |
Konnektor, VPN-ZugD |
Ausgangsdaten |
Keine |
Standardablauf |
|
Varianten/Alternativen |
Manuelle Registrierung: (->2) Der Administrator soll die zu verwendende SM-B auswählen können. |
Fehlerfälle |
( 2) Es konnte keine freigeschaltete SM-B ausgewählt werden: Fail=No_Smcb (->2,3) Im Fehlerfall TUC_KON_256 { topic = „SMC_K/REGISTER/ERROR“; eventType = Op; severity = Error; parameters = „$Parameters“; doLog = true; doDisp = true } Die Registrierung soll herstellerspezifisch erneut mehrmals versucht werden. Bei allen Fehlerfällen, die zum Abbruch führen: TUC_KON_256 { topic = „SMC_K/REGISTER/ERROR“; eventType = Op; severity = Error; parameters = „$Parameters“; doLog = true; doDisp = true } |
Nichtfunktionale Anforderungen | Keine |
Zugehörige Diagramme |
Keine |
Tabelle 370: Tab_Kon_933 Fehlercodes TUC_KON_411 "Konnektor mit neuem NK-Zertifikat registrieren"
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
herstellerspezifisch |
A_21781 - Nutzerhinweis bezüglich Fehler bei Re-Registrierung
Der Hersteller des Konnektors MUSS in seinem Handbuch den Nutzer/Administrator darauf hinweisen, dass das Ereignis mit dem Topic=SMC_K/REGISTER/ERROR dringend durch das Primärsystem abonniert werden sollte. Bei Auftreten des Fehlers mit Fail=No_Smcb muss in der Leistungserbringerumgebung dafür gesorgt werden, dass eine freigeschaltete SMC-B verfügbar ist, die der Konnektor beim nächsten Re-Registrierungsversuch verwenden kann. [<=]
4.3.9 Remote Management (Optional)
Im Betreibermodell der TI wird unter Remote Management ein delegierter Betrieb dezentraler Produkte durch einen durch den Anwender beauftragten Servicepartner verstanden. Der Servicepartner stellt als Vertragsbestandteil bevollmächtigte Personen zur Verfügung, die sich ständig um die Betriebs- und Datensicherheit der dezentralen Produkte im Rahmen eines Remote Managements kümmern.
Voraussetzung für die Etablierung dieses Bestandteils des Betreibermodells der TI ist, dass ein dezentrales Produkt ein Remote Management technisch unterstützt. Die nachfolgend aufgeführten Anforderungen bilden die Grundlage für die Nutzung von Remote Management am Konnektor.
Zum Remote Management gehören die Verwaltung von Konfigurationsdaten und die Durchführung weiterer Administratoraktionen wie z. B. die Aktualisierung der Software des Konnektors. Im Rahmen des Remote Managements kann der Konnektor Remote Monitoring unterstützen. Dazu übermittelt der Konnektor Betriebszustandsdaten an das Remote- Management-System.
TIP1-A_7276-01 - Remote Management Konnektor
Der Konnektor KANN Remote Management technisch unterstützen.
Falls der Konnektor das Remote Management technisch unterstützt, MUSS der Konnektor alle Anforderungen, die das Remote Management (z.B. auch Remote-Administrator) betreffen, umsetzen.
Andernfalls sind die Anforderungen, die das Remote Management (z.B. auch Remote-Administrator) betreffen, für den Konnektor nicht relevant. [<=]
TIP1-A_5647 - Remote Management Konnektor: Personenbezogene Daten
Der Konnektor DARF über die Remote-Managementschnittstelle KEINE personenbezogenen Daten übertragen oder darstellen.
[<=]TIP1-A_5648 - Remote Management Konnektor: Offene Schnittstelle
Der Hersteller des Konnektors MUSS die zur Nutzung der Remote-Managemenschnittstelle notwendigen Informationen offenlegen. Der Hersteller des Konnektors MUSS die Remote-Managementschnittstelle so spezifizieren und implementieren, dass diese auch für Dritte (z.B. einen durch den Anwender beauftragten Servicepartner) nutzbar ist.
[<=]TIP1-A_5649 - Remote Management Konnektor: Standardbasierte Protokolle
Der Hersteller des Konnektors SOLL für die Implementierung der Remote-Managementschnittstelle standardbasierte Verfahren und Protokolle einsetzen.
[<=]TIP1-A_5650 - Remote Management Konnektor: Aufbau der Verbindung
Der Konnektor MUSS sicherstellen, dass die Initiierung einer Remote-Managementverbindung im Sinne des Verbindungsaufbaus immer vom Konnektor ausgeht.
[<=]
TIP1-A_5651 - Remote Management Konnektor: Absicherung der Verbindung
Der Konnektor MUSS die Remote-Management-Verbindung durch Nutzung eines kryptographischen Verfahrens gemäß [gemSpec_Krypt] hinsichtlich Vertraulichkeit, Integrität und Authentizität absichern.
[<=]
Das Remote-Management-System authentisiert sich auf Transportebene zertifikatsbasiert gegenüber dem Konnektor.
TIP1-A_7277 - Authentifizierung des Remote-Management-Systems
Der Konnektor MUSS eine zertifikatsbasierte Authentifizierung des Remote-Management-Systems auf Transportebene durchführen. [<=]
TIP1-A_7278 - Authentisierung des Konnektors gegenüber Remote-Management-System
Der Konnektor MUSS sich gegenüber dem Remote-Management-System zertifikatsbasiert oder mittels Username/Password authentisieren. [<=]
TIP1-A_7281 - Authentifizierung des Konnektors durch das Remote-Management-System
Das Remote-Management-System MUSS eine Authentifizierung des Konnektors durchführen. [<=]
Die Authentifizierung des Remote-Management-Systems durch den Konnektor auf Transportebene ist verpflichtend gefordert.
Darüber hinaus können optional Remote-Administratoren in der Benutzerverwaltung des Konnektors konfiguriert werden. Wenn Remote-Administratoren in der Benutzerverwaltung konfiguriert sind, muss der Konnektor diese verpflichtend auf Anwendungsebene authentifizieren.
Wenn kein Remote-Administrator konfiguriert ist, vertraut der Konnektor der Benutzerverwaltung des Remote-Management-Systems. Auch wenn die Verwaltung von Remote-Administratoren an das Remote-Management-System delegiert ist, werden alle Zugriffe über das Remote-Management-System auf den Konnektor mit der Rolle Remote-Administrator ausgeführt. Das Remote-Management-System muss die Authentisierung der Remote-Administratoren und die Nachvollziehbarkeit der Zugriffe sicherstellen.
TIP1-A_7279 - Authentifizierung des Remote-Administrators
Wenn in der Benutzerverwaltung des Konnektors Administratoren mit der Administrator-Rolle Remote-Administrator konfiguriert sind, MUSS der Konnektor diese gemäß TIP1-A_4808 authentifizieren. [<=]
TIP1-A_7280 - Einschränkung der Rechte des Remote-Administrators
Der Konnektor DARF Remote-Administratoren Rechte gemäß TAB_KON_851 und TAB_KON_655 NICHT gewähren. [<=]
Tabelle 371: TAB_KON_851 Einschränkung der Rechte des Remote-Administrators (Denylist)
Fachliche Anbindung der Clientsysteme |
||
---|---|---|
TIP1-A_4517 |
Schlüssel und X.509-Zertifikate für die Authentisierung des Clientsystems erzeugen und exportieren sowie X.509-Zertifikate importieren |
|
TIP1-A_4518 |
Konfiguration der Anbindung Clientsysteme |
|
Kartendienst |
||
TIP1-A_5110 |
Übersicht über alle verfügbaren Karten |
Karten vom Typ eGK und HBA DÜRFEN dem Remote-Administrator NICHT angezeigt werden |
TIP1-A_5111 |
PIN-Management der SM-Bs für den Administrator |
|
Zertifikatsdienst |
||
TIP1-A_4704 |
Zertifikatsablauf anzeigen |
Zertifikate von Karten vom Typ eGK und HBA DÜRFEN dem Remote-Administrator NICHT angezeigt werden |
Protokollierungsdienst |
||
TIP1-A_4716 |
Einsichtnahme und Veränderung der Protokolle |
Personenbezogene Daten DARF der Remote-Administrator NICHT einsehen und exportieren. Fachmodulprotokolle müssen daher entweder gesperrt, oder die personenbezogenen Daten aus diesen für den Remote-Administrator gefiltert werden. |
TIP1-A_4814 |
Export- Import von Konfigurationsdaten |
|
Neustart und Werksreset |
||
TIP1-A_4820 |
Werksreset des Konnektors |
|
TIP1-A_5652 - Remote Management Konnektor: Konfiguration Remote Management
Der Konnektor MUSS sicherstellen, dass es ausschließlich einem Administrator mit einer der Rollen {Lokaler Administrator; Super-Administrator} und dem Recht USER_INIT_REMOTESESSION möglich ist, Konfigurationsänderungen gemäß TAB_KON_663 vorzunehmen.
Tabelle 372: TAB_KON_663 Konfigurationen des Remote Managements
ReferenzID |
Belegung |
Bedeutung und Administrator-Interaktion |
---|---|---|
MGM_REMOTE_ |
Enabled/ |
Der Administrator MUSS einstellen können, ob der |
MGM_REMOTE_MONITORING_ALLOWED |
Enabled / Disabled |
Der Konnektor KANN Remote-Monitoring unterstützen. |
Der Konnektor SOLL die Konfiguration der URL des Remote-Management-Systems, der Zertifikatsinformationen zur Authentisierung des Remote-Management-Systems und der Credentials für die Authentisierung des Konnektors beim Remote-Management-System ermöglichen. |
TIP1-A_5653 - Remote Management Konnektor: Protokollierung Remote Management
Der Konnektor MUSS im Rahmen des Remote-Managements folgende Aktionen protokollieren:
- Beginn einer Remote-Session durch
TUC_KON_271 „Schreibe Protokolleintrag“ {
topic = „MGM/REMOTE_SESSION“;
eventType = Op;
severity = Info;
parameters = („InitUser=$AdminUsername,
RemoteID=<Kennung der Gegenstelle>,
Mode=[InitSuccess/InitFail]“)}
- Verbindungsabbau Remote-Session durch
TUC_KON_271 „Schreibe Protokolleintrag“ {
topic = „MGM/REMOTE_SESSION“;
eventType = Op;
severity = Info;
parameters = („InitUser=$AdminUsername,
RemoteID=<Kennung der Gegenstelle>,
Mode=Exit“}
Die Protokollierungspflicht gilt nicht für das Remote Monitoring.
Wenn ein remote-Zugriff erfolgt, ohne dass ein Remote-Administrator im Konnektor konfiguriert ist, so MUSS als InitUser eine Referenz auf das Remote-Management-System verwendet werden.
Ein Softwareupdate gemäß TIP1-A_5657 kann auch über das Remote Management initiiert, aktiviert und freigeschaltet werden.
4.3.10 Software- und Konfigurationsaktualisierung (KSR-Client)
Die Umsetzung des KSR-Clients bezüglich des Mechanismus zur Durchführung der Aktualisierungen, sowie die Art der Darstellung an der Managementschnittstelle sind herstellerspezifisch.
Innerhalb der Software- und Konfigurationsaktualisierung (KSR-Client) werden folgende Präfixe für Bezeichner verwendet:
- Events (Topic Ebene 1):„KSR“
- Konfigurationsparameter: „MGM_“
4.3.10.1 Funktionsmerkmalweite Aspekte
Der Konnektor muss einen KSR-Client bereitstellen, über den der Administrator sowohl den Konnektor selbst als auch die vom Konnektor verwalteten Kartenterminals (CT-Objects in CTM_CT_LIST mit CT.CORRELATION>=„gepairt“ und CT.VALID_VERSION=True und CT.IS_PHYSICAL = Ja) softwareseitig aktualisieren kann.
Weiterhin muss über den KSR-Client eine Aktualisierung von ausgewählten Konfigurationsdaten möglich sein.
TIP1-A_4829 - Vollständige Aktualisierbarkeit des Konnektors
Die Software-Aktualisierung des Konnektor SOLL sicherstellen, dass alle Software-Bestandteile des Konnektors aktualisiert werden können, damit eine ungehinderte Nachnutzung der Hardware-Basis im Feld mit neuen Funktionalitäten nicht durch nichtaktualisierbare Software-Bestandteile gefährdet wird. Weicht ein Hersteller für sein Konnektormodell von dieser Forderung in Teilen ab, so MUSS er im Rahmen der Zulassung nachweisen, dass dies auf Grund von Sicherheitsaspekten für sein eingereichtes Konnektormodell zwingend erforderlich ist.
[<=]TIP1-A_5657-02 - Freischaltung von Softwareupdates
Der Konnektor MUSS die Möglichkeit bieten, dass Softwareupdates durch den Nutzer bzw. einen von ihm beauftragten Administrator einzeln freigeschaltet werden.
[<=]
A_18387 - Automatische Softwareupdates
Der Konnektor MUSS die Möglichkeit bieten, die automatische Installation von Softwareupdates pro Gerät (Konnektor und Kartenterminals) ein- und auszuschalten. [<=]
A_18389 - Nur Nutzung von zugelassenen Versionen
Der Hersteller des Konnektors MUSS in seinem Handbuch den Nutzer darauf hinweisen, dass er sich bei der Arbeit mit dem Konnektor vergewissern muss, dass er mit einer zugelassenen Version arbeitet und beschreiben, wie der Nutzer diese Information mittels seines Primärsystems erhalten kann.
[<=]
TIP1-A_6476 - Lieferung von Softwareupdates
Der Hersteller des Konnektors MUSS jede zugelassene Firmware-Version umgehend als Update-Paket über die in [gemSpec_KSR] definierte Schnittstelle P_KSRS_Upload im Konfigurationsdienst (KSR) ablegen.
Der Hersteller des Konnektors MUSS in den jeweiligen UpdateInformation/Firmware/FirmwareReleaseNotes eine Internet-URL zum Download des FW-Updates bereitstellen.
[<=]
TIP1-A_6026 - Anzeige URL zum Download des FW-Updates an der Managementschnittstelle
Das Managementinterface des Konnektors MUSS einem authentisierten Administrator die Internet-URL zum Download des FW-Updates anzeigen.
[<=]
4.3.10.2 Durch Ereignisse ausgelöste Reaktionen
TIP1-A_4831 - KT-Update nach Wiedererreichbarkeit erneut anstoßen
Wenn aus (TIP1-A_4840 Auslösen der durchzuführenden Updates) heraus für ein Kartenterminal noch ein ausstehendes Updates vorhanden ist, dessen Ausführungszeitpunkt nicht gesetzt oder überschritten ist, und für dieses Kartenterminal das Ereignis „CT/CONNECTED“ eintritt, so MUSS TUC_KON_281 „Kartenterminalaktualisierung anstoßen“ für dieses KT gerufen werden.
[<=]4.3.10.3 Interne TUCs, nicht durch Fachmodule nutzbar
4.3.10.3.1 TUC_KON_280 „Konnektoraktualisierung durchführen“
TIP1-A_4832-02 - TUC_KON_280 „Konnektoraktualisierung durchführen“
Der Konnektor MUSS den technischen Use Case TUC_KON_280 „Konnektoraktualisierung durchführen“ umsetzen.
Tabelle 373: TAB_KON_664 – TUC_KON_280 „Konnektoraktualisierung durchführen“
Element |
Beschreibung |
---|---|
Name |
TUC_KON_280 „Konnektoraktualisierung durchführen“ |
Beschreibung |
Dieser TUC aktualisiert den Konnektor mit einem Update, dessen Update-Dateien entweder direkt übergeben oder per UpdateInformation (vom KSRS bezogen) referenziert werden |
Auslöser |
|
Vorbedingungen |
|
Eingangsdaten |
|
Komponenten |
Konnektor, Konfigurationsdienst |
Ausgangsdaten |
Keine |
Nachbedingungen |
Der Konnektor arbeitet basierend auf der übergebenen, im Updatepaket enthaltenen neuen Version. |
Standardablauf |
Der Konnektor MUSS die zur Anwendung übergebene UpdateInformation wie folgt anwenden:
Der TUC endet in jedem Fall mit:
TUC_KON_256 {
topic = „KSR/UPDATE/END“; eventType = Sec; severity = Info; parameters = („Target=Konnektor, Name=$MGM_KONN_HOSTNAME“) } (betroffene Fachmodule und Basisdienste reagieren und starten sich) |
Varianten/Alternativen |
Sofern direkt ein Updatepaket (mit enthaltenen FirmwareFiles) übergeben wurde beginnt der Ablauf ab Nummer 4 mit der Integritätsprüfung des Updatepakets |
Fehlerfälle |
Fehler in den folgenden Schritten des Ablaufs führen zu: a) Aufruf von TUC_KON_256 { topic = „KSR/ERROR“; eventType = $ErrorType; severity = $Severity; parameters = („Target=Konnektor, Name= $MGM_KONN_HOSTNAME, Error=$Fehlercode, Bedeutung=$Fehlertext“) } b) Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes (1) Integritätsprüfung UpdateInformation fehlgeschlagen, Fehlercode: 4181 (2) Fehler bei der Downloaddurchführung, Fehlercode: 4182 (3) Integritätsprüfung eines FirmwareFiles fehlgeschlagen, Fehlercode: 4183 ( 4) Firmwaregruppenprüfung fehlgeschlagen, Fehlercode: 4185 (5b) Interne Aktualisierung fehlgeschlagen, dann: 1. Rollback auf vorherige Version 2. Abbruch mit Fehlercode: 4184 |
Nichtfunktionale Anforderungen |
Der laufende Updatevorgang MUSS in der Managementschnittstelle ausgewiesen und der Fortschritt mindestens für die Schritte 1-5b dargestellt werden. |
Zugehörige Diagramme |
Abbildung PIC_KON_105 Aktivitätsdiagramm Konnektoraktualisierung durchführen |
Tabelle 374: TAB_KON_665 Fehlercodes TUC_KON_280 „Konnektoraktualisierung durchführen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4181 |
Security |
Error |
Integritätsprüfung UpdateInformation fehlgeschlagen. |
4182 |
Security |
Error |
Download nicht aller UpdateFiles möglich. |
4183 |
Security |
Error |
Integritätsprüfung UpdateFiles fehlgeschlagen. |
4184 |
Security |
Error |
Anwendung der UpdateFiles fehlgeschlagen (<Details>). |
4185 |
Security |
Error |
Firmware-Version liegt außerhalb der gültigen Firmware-Gruppe |
Abbildung 22: PIC_KON_105 Aktivitätsdiagramm Konnektoraktualisierung durchführen
[<=]4.3.10.3.2 TUC_KON_281 „Kartenterminalaktualisierung anstoßen“
Im Vergleich zur Durchführung des Konnektor-Update (TUC_KON_280), werden die Updates der Kartenterminals nur durch den Konnektor initiiert. Der Konnektor liefert dem Kartenterminal das Updatefile, der eigentliche Updatevorgang (inklusive der Prüfung des Updatepakets auf Integrität und Authentizität) erfolgt ausschließlich und eigenverantwortlich auf Seiten des Kartenterminals.
TIP1-A_4833-02 - TUC_KON_281 „Kartenterminalaktualisierung anstoßen“
Der Konnektor MUSS den technischen Use Case TUC_KON_281 „Kartenterminalaktualisierung anstoßen“ umsetzen.
Tabelle 375: TAB_KON_666 – TUC_KON_281 „Kartenterminalaktualisierung anstoßen“
Element |
Beschreibung |
Name |
TUC_KON_281 „Kartenterminalaktualisierung anstoßen“ |
Beschreibung |
Dieser TUC fordert ein Kartenterminal auf einen Update durchzuführen, dessen Update-Dateien entweder direkt übergeben oder per UpdateInformation (vom KSRS bezogen) referenziert werden |
Auslöser |
|
Vorbedingungen |
|
Eingangsdaten |
|
Komponenten |
Konnektor, Kartenterminal |
Ausgangsdaten |
Keine |
Nachbedingungen |
Das Kartenterminal arbeitet basierend auf der übergebenen, im Updatepaket enthaltenen neuen Version. |
Standardablauf |
Der Konnektor MUSS die zur Anwendung übergebene UpdateInformation wie folgt anwenden:
„Beginne Kartenterminalsitzung“{role=„Admin“; ctId} b) Senden der SICCT Kommandos: SICCT CT Download INIT, SICCT CT Download DATA (Übermittlung des UpdateFiles) und SICCT CT Download FINISH an ctId c) TUC_KON_256{ topic = „KSR/UPDATE/SUCCESS”; eventType = Sec; severity = Info; parameters = („Target=KT, Name= $CT.HOSTNAME, CtID =$ctId, NewFirmwareversion = <UpdateInformation.FirmwareVersion>„} Der TUC endet in jedem Fall mit:
|
Varianten/Alternativen |
Sofern direkt ein Updatepaket (mit enthaltenem FirmwareFile) übergeben wurde beginnt der Ablauf ab Nummer 2 mit Signalisierung des Beginns des KT-Updates |
Fehlerfälle |
Fehler in den folgenden Schritten des Ablaufs führen zu: a) Aufruf von TUC_KON_256 { topic = „KSR/ERROR”; eventType = $ErrorType; severity = $Severity; parameters = („Target=KT, Name=$CT.HOSTNAME, CtID =$ctId, Error=$Fehlercode, Bedeutung=$Fehlertext“) } b) Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes (1) Download fehlgeschlagen, Fehlercode: 4186 (3b) SICCT-Download fehlgeschlagen, Fehlercode: 4187 |
Nichtfunktionale Anforderungen |
Die Durchführung eines KT-Updates DARF die weitere Operation des Konnektors NICHT behindern (weder auf Schnittstellenebene noch in der Managementschnittstelle). Der laufende Updatevorgang eines KT MUSS in der Managementschnittstelle ausgewiesen und der Fortschritt dargestellt werden. Der Konnektor MUSS mindestens 5 Kartenterminal-Updates parallel durchführen können. |
Zugehörige Diagramme |
keine |
Tabelle 376: TAB_KON_667 Fehlercodes TUC_KON_281 „Kartenterminalaktualisierung anstoßen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4186 |
Security |
Error |
Download nicht aller UpdateFiles möglich. |
4187 |
Security |
Error |
KT-Update fehlgeschlagen (<Fehlerinfo gemäß SICCT>) |
4.3.10.3.3 TUC_KON_282 „UpdateInformationen beziehen“
TIP1-A_4834 - TUC_KON_282 „UpdateInformationen beziehen“
Der Konnektor MUSS den technischen Use Case TUC_KON_282 „UpdateInformationen beziehen“ umsetzen.
Tabelle 377: TAB_KON_668 – TUC_KON_282 „UpdateInformationen beziehen“
Element |
Beschreibung |
Name |
TUC_KON_282 „UpdateInformationen beziehen“ |
Beschreibung |
Dieser TUC ermittelt vom zentralen Konfigurationsdienst sowohl für den Konnektor als auch für alle durch ihn verwalteten Kartenterminals die verfügbaren UpdateInformationen |
Auslöser |
|
Vorbedingungen |
Keine |
Eingangsdaten |
Keine |
Komponenten |
Konnektor, Konfigurationsdienst |
Ausgangsdaten |
Keine |
Nachbedingungen |
Der Konnektor verfügt über alle aktuellen UpdateInformationen |
Standardablauf |
Der Konnektor MUSS folgende Schritte durchlaufen:
|
Varianten/Alternativen |
Keine |
Fehlerfälle |
Fehler in den folgenden Schritten des Ablaufs führen zu: a) Aufruf von TUC_KON_256 { topic = „KSR/ERROR“; eventType = $ErrorType; severity = $Severity; parameters = („Error=$Fehlercode; Bedeutung=$Fehlertext“)} b) Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes (1) Konfigurationsdienst nicht erreichbar, Fehlercode: 4188 (1) Serverzertifikat ist nicht C.ZD.TLS_S, Fehlercode: 4189 (2b) Fehler beim Beziehen der Updatelisten, Fehlercode: 4190 |
Nichtfunktionale Anforderungen |
Der Konnektor muss die Vorgaben aus [gemSpec_Krypt#3.3.2] für TLS-Verbindungen und hinsichtlich ECC-Migration die Vorgaben aus [gemSpec_Krypt#5] befolgen. |
Zugehörige Diagramme |
keine |
Tabelle 378: TAB_KON_669 Fehlercodes TUC_KON_282 „UpdateInformationen beziehen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases, sowie der Fehlercodes von „I_KSRS_Download::listUpdates Response“ können folgende weitere Fehlercodes auftreten: |
|||
4188 |
Technical |
Error |
Konfigurationsdienst nicht erreichbar, konfigurierte Adresse kontrollieren. |
4189 |
Security |
Fatal |
Konfigurationsdienst liefert falsches Zertifikat |
4190 |
Technical |
Error |
Fehler beim Beziehen der Updatelisten |
[<=]
4.3.10.3.4 TUC_KON_283 „Infrastruktur Konfiguration aktualisieren“
TIP1-A_5153 - TUC_Kon_283 „Infrastruktur Konfiguration aktualisieren“
Der Konnektor MUSS den technischen Use Case TUC_Kon_283 „Infrastruktur Konfiguration aktualisieren“ umsetzen.
Tabelle 379: TAB_KON_799 – TUC_KON_283 „Infrastruktur Konfiguration aktualisieren“
Element |
Beschreibung |
---|---|
Name |
TUC_KON_283 Infrastruktur Konfiguration aktualisieren |
Beschreibung |
Dieser TUC liest die Infrastrukturdaten vom KSR ein. |
Auslöser |
Automatisch einmal täglich; BOOTUP, Administrator |
Vorbedingungen | Der TUC_KON_304 „Netzwerk-Routen einrichten“ MUSS fehlerfrei durchgelaufen sein. Der TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen“ MUSS fehlerfrei durchgelaufen sein. |
Eingangsdaten |
Keine |
Komponenten |
Konnektor, Konfigurationsdienst |
Ausgangsdaten |
Keine |
Standardablauf |
Der Konnektor MUSS folgende Schritte durchlaufen:
|
Varianten/Alternativen |
Keine |
Fehlerfälle |
( 1-5) Es ist ein unerwarteter Fehler aufgetreten; Fehlercode: 4198 |
Nichtfunktionale Anforderungen | Keine |
Zugehörige Diagramme |
Keine |
Tabelle 380: Tab_Kon_726 Fehlercodes TUC_KON_283 „Infrastruktur Konfiguration aktualisieren“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4198 |
Technical |
Error |
Beim Übernehmen der angeschlossenen Netze des Gesundheitswesens mit WANDA Basic ist ein Fehler aufgetreten. |
4.3.10.4 Interne TUCs, auch durch Fachmodule nutzbar
4.3.10.4.1 TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“
TIP1-A_6018 - TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“
Der Konnektor MUSS den technischen Use Case TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“ umsetzen.
Tabelle 381: TAB_KON_833 – TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“
Element |
Beschreibung |
Name |
TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“ |
Beschreibung |
Dieser TUC ermittelt vom zentralen Konfigurationsdienst für ein Fachmodul die verfügbaren UpdateInformationen eines angegebenen SW-Pakets. |
Auslöser |
|
Vorbedingungen |
|
Eingangsdaten |
|
Komponenten |
Konnektor, Konfigurationsdienst |
Ausgangsdaten |
|
Nachbedingungen |
keine |
Standardablauf |
Der Konnektor MUSS folgende Schritte durchlaufen:
|
Varianten/Alternativen |
Keine |
Fehlerfälle |
Fehler in den folgenden Schritten des Ablaufs führen zu: (1) Konfigurationsdienst nicht erreichbar, Fehlercode: 4188 (1) Serverzertifikat ist nicht C.ZD.TLS_S, Fehlercode: 4189 (3) Fehler beim Beziehen der Updatelisten, Fehlercode: 4190 |
Nichtfunktionale Anforderungen |
Der Konnektor muss die Vorgaben aus [gemSpec_Krypt#3.3.2] für TLS-Verbindungen und hinsichtlich ECC-Migration die Vorgaben aus [gemSpec_Krypt#5] befolgen. |
Zugehörige Diagramme |
keine |
Tabelle 382: TAB_KON_834 Fehlercodes TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases, sowie der Fehlercodes von „I_KSRS_Download::listUpdates Response“ können folgende weitere Fehlercodes auftreten: |
|||
4188 |
Technical |
Error |
Konfigurationsdienst nicht erreichbar, konfigurierte Adresse kontrollieren. |
4189 |
Security |
Fatal |
Konfigurationsdienst liefert falsches Zertifikat |
4190 |
Technical |
Error |
Fehler beim Beziehen der Updatelisten |
[<=]
4.3.10.4.2 TUC_KON_286 „Paket für Fachmodul laden“
TIP1-A_6019 - TUC_KON_286 „Paket für Fachmodul laden“
Der Konnektor MUSS den technischen Use Case TUC_KON_286 „Paket für Fachmodul laden“ umsetzen.
Tabelle 383: TAB_KON_835 – TUC_KON_286 „Paket für Fachmodul laden“
Element |
Beschreibung |
Name |
TUC_KON_286 „Paket für Fachmodul laden“ |
Beschreibung |
Dieser TUC lädt ein bestimmtes SW-Paket für ein Fachmodul vom zentralen Konfigurationsdienst. |
Auslöser |
Aufruf durch Fachmodul |
Vorbedingungen |
|
Eingangsdaten |
|
Komponenten |
Konnektor, Konfigurationsdienst |
Ausgangsdaten |
|
Nachbedingungen |
keine |
Standardablauf |
|
Varianten/Alternativen |
keine |
Fehlerfälle |
( 1) Verbindung zum KSR konnte nicht aufgebaut werden; Fehlercode: 4188 ( 1) Serverzertifikat ist nicht C.ZD.TLS_S, Fehlercode: 4189 ( 2) Wenn Größe des Pakets größer als 25MB, Fehlercode: 4242 ( 2) Sonstige Fehler beim Download: Das Paket konnte nicht geladen werden, Fehlercode: 4238 |
Nichtfunktionale Anforderungen |
Keine |
Zugehörige Diagramme |
Keine |
Tabelle 384: TAB_KON_836 Fehlercodes TUC_KON_286 „Paket für Fachmodul laden“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten: |
|||
4188 |
Technical |
Error |
Konfigurationsdienst nicht erreichbar, konfigurierte Adresse kontrollieren. |
4189 |
Security |
Fatal |
Konfigurationsdienst liefert falsches Zertifikat |
4238 |
Technical |
Error |
Der Download des Pakets vom KSR ist fehlgeschlagen. |
4242 |
Technical |
Error |
Der Download des Pakets vom KSR ist fehlgeschlagen. Das Paket ist größer als 25MB. |
[<=]
4.3.10.5 Operationen an der Außenschnittstelle
Keine.
4.3.10.6 Betriebsaspekte
A_21899 - Kein Restart des Konnektors nach Aktualisierung der Bestandsnetze.xml
Der Konnektor DARF NICHT nach einer Aktualisierung der Datei Bestandsnetze.xml einen Restart durchführen.
[<=]
A_21900 - Minimale Anzahl von Reboots
Der Konnektor MUSS die Anzahl der Reboots minimieren. [<=]
4.3.10.6.1 TUC_KON_284 KSR-Client initialisieren
TIP1-A_5938 - TUC_KON_284 „KSR-Client initialisieren“
Der Konnektor MUSS in der Bootup-Phase TUC_KON_284 „KSR-Client initialisieren“ durchlaufen.
Tabelle 385: TAB_KON_864 – TUC_KON_284 „KSR-Client initialisieren“
Element |
Beschreibung |
Name |
TUC_KON_284 ”KSR-Client initialisieren” |
Beschreibung |
Der Konnektor muss während des Bootups die Downloadpunkte für Konfigurationsdaten und Firmware ermitteln. |
Eingangsanforderung |
Keine |
Auslöser und Vorbedingungen |
Bootup Verbindung zum VPN-Konzentrator TI muss aufgebaut sein |
Eingangsdaten |
Keine |
Komponenten |
Konnektor |
Ausgangsdaten |
|
Standardablauf |
- Falls MGM_LU_ONLINE=Enabled: - Durch DNS-Anfragen an den DNS-Forwarder zur Auflösung der SRV-RR und TXT-RR mit den Bezeichnern „_ksrkonfig._tcp.ksr.<TOP_LEVEL_DOMAIN_TI>„ und „_ksrfirmware._tcp.ksr.<TOP_LEVEL_DOMAIN_TI>„ erhält der Konnektor URLs der Downloadpunkte des KSR für Konfigurationsdaten (MGM_KSR_KONFIG_URL) und für Firmware (MGM_KSR_FIRMWARE_URL). |
Varianten/Alternativen |
Keine |
Fehlerfälle |
Keine |
Nichtfunktionale Anforderungen |
Keine |
Zugehörige Diagramme |
Keine |
Tabelle 386: TAB_KON_822 Fehlercodes TUC_KON_284 „KSR-Client initialisieren“
Fehlercode |
ErrorType |
Severity |
Fehlertext |
---|---|---|---|
Neben den Fehlercodes der aufgerufenen technischen Use Cases können keine weiteren Fehlercodes auftreten. |
[<=]
TIP1-A_4835-02 - Konfigurationswerte des KSR-Client
Der Administrator MUSS die in TAB_KON_670 aufgelisteten Parameter über die Managementschnittstelle konfigurieren und die in TAB_KON_820 aufgelisteten Parameter ausschließlich einsehen können.
Tabelle 387: TAB_KON_670 Konfigurationsparameter der Software-Aktualisierung
ReferenzID |
Belegung |
Bedeutung und Administrator-Interaktion |
---|---|---|
MGM_KSR_ AUTODOWNLOAD |
Enabled/ Disabled |
Der Administrator MUSS den automatischen Download verfügbarer Update-Pakete über den Konfigurationsparameter MGM_KSR_AUTODOWNLOAD an- und abschalten können. Default-Wert: Enabled |
MGM_KSR_SHOW_ TRIAL_UPDATES |
Enabled / Disabled |
Der Administrator MUSS einschalten können, dass zusätzlich zur Anzeige von Update-Paketen für den Online-Produktivbetrieb auch die Anzeige von Erprobungs-Update-Paketen erfolgt. Wenn MGM_KSR_SHOW_TRIAL_UPDATES von Disabled auf Enabled gesetzt wird, muss ein Warnhinweis angezeigt werden, dass die Installation von Erprobungs-Update-Paketen nur für Teilnehmer der Erprobungen vorgesehen ist. Default-Wert: Disabled |
MGM_KSR_AUTO_UPDATE | Enabled / Disabled | Der Administrator MUSS pro Gerät (Konnektor und Kartenterminals) das automatische Softwareupdate ein- und ausschalten können. Default-Wert: Enabled Falls MGM_KSR_AUTO_UPDATE=Enabled wird MGM_KSR_ AUTODOWNLOAD=Enabled gesetzt. |
MGM_KSR_AUTO_ UPDATE_TIME |
Wochentag / Uhrzeit Oder täglich / Uhrzeit |
Der Administrator MUSS den Wochentag und die Uhrzeit einstellen können, wann automatische Softwareupdates durchgeführt werden. Als Wochentag MUSS es neben den einzelnen Wochentagen auch einen Wert für eine tägliche Prüfung auf Aktualität und gegebenenfalls Durchführung von Softwareupdates geben. Default-Wert: Montag / 1:00 Uhr |
Tabelle 388: TAB_KON_820 Einsehbare Konfigurationsparameter der Software-Aktualisierung
ReferenzID |
Belegung |
Bedeutung und Administrator-Interaktion |
---|---|---|
MGM_KSR_ KONFIG_URL |
URL |
SOAP-Endpunkt des Konfigurationsdienstes zum Download von Konfigurationsdaten |
MGM_KSR_ FIRMWARE_URL |
URL |
SOAP-Endpunkt des Konfigurationsdienstes zum Download der Firmware |
Hinweis: Die Adressen des Konfigurationsdienstes werden im Rahmen des VPN-Verbindungsaufbaus ermittelt (siehe [gemSpec_VPN_ZugD#5.1.1.2 TUC_VPN-ZD_0001])
TIP1-A_6025 - Zugang zur TI sperren, wenn Deadline für kritische FW-Updates erreicht
Der Konnektor MUSS täglich überprüfen, ob unter den auf die aktuelle Konnektor-Firmware anwendbaren Updates ein Update mit FWPriority = „Kritisch“ ist, dessen Deadline (entspricht UpdateInformation/DeploymentInformation/Deadline) abgelaufen ist, d.h. Deadline <= Systemzeit. In diesem Fall MUSS der Konnektor den Verbindungsaufbau zur TI Plattform verhindern, bestehende Verbindungen in die TI abbauen und den kritischen Betriebszustand EC_FW_Not_Valid_Status_Blocked annehmen.
[<=]
TIP1-A_4836 - Automatische Prüfung und Download von Update-Paketen
Der Konnektor MUSS täglich die folgenden Schritte durchführen:
- TUC_KON_282 „UpdateInformationen beziehen“ aufrufen.
- pro zurück geliefertem Listeneintrag prüfen, ob eine neuere Version enthalten ist, als auf dem zugehörigen Gerät (Konnektor selbst oder Kartenterminal) vorhanden
- Ist für wenigstens ein Gerät eine neuere Version vorhanden, MUSS der Konnektor darüber via
TUC_KON_256 „Systemereignis absetzen“ {
topic = „KSR/UPDATES_AVAILABLE“;
eventType = Op;
severity = Info;
parameters = (<Param>);
doLog=false }
informieren. Je gefundenem Update MUSS <Param> mit folgenden Werten belegt sein:
<Param> = „ProductVendorID= $UpdateInformation/ProductVendorID;
ProductCode= $UpdateInformation/ProductCode;
ProductName=$UpdateInformation/ProductName;
FirmwareVersion=$UpdateInformation/FirmwareVersion;
Deadline=$UpdateInformation/DeploymentInformation/Deadline;
FWPriority=$UpdateInformation/Firmware/FWPriority;
FirmwareReleaseNotes=
$UpdateInformation/Firmware/FirmwareReleaseNotes“ - Die listUpdateResponse mit neueren Firmwareversionen MÜSSEN für eine spätere Einsichtnahme durch den Administrator bereitgehalten werden (via (TIP1-A_4837) „Übersichtsseite des KSR-Client). Ein neuerlicher Abruf dieser Informationen DARF NICHT erforderlich sein.
- Sofern ein Update-Paket für den Konnektor vorliegt, MUSS der Konnektor die mit diesem Paket gelieferten Parameter Priority (entspricht UpdateInformation/Firmware/FWPriority) und Deadline (entspricht UpdateInformation/DeploymentInformation/Deadline) auswerten und bei KSR:Priority=Kritisch persistent ablegen.
- Sofern MGM_KSR_AUTODOWNLOAD = Enabled, MUSS der Konnektor bei Update-Paketen, die den Konnektor selbst betreffen, das Update-Paket mit der höchsten FirmwareVersion über I_KSRS_Download::get_Updates herunterladen.
- Ist der Download von Update-Paketen für den Konnektor abgeschlossen, MUSS der Konnektor darüber via
topic = „KSR/UPDATE/KONNEKTOR_DOWNLOAD_END“;
eventType = Op;
severity = Info;
parameters = (<Param>)}
informieren. Je heruntergeladenem FW-Paket MUSS <Param> mit folgenden Werten belegt sein:
<Param> = „ProductVendorID= $UpdateInformation/ProductVendorID;
ProductCode= $UpdateInformation/ProductCode;
ProductName=$UpdateInformation/ProductName;
FirmwareVersion=$UpdateInformation/Firmware/FWVersion;
Deadline=$UpdateInformation/DeploymentInformation/Deadline;
=$UpdateInformation/Firmware/FirmwareReleaseNotes“
- Sofern MGM_KSR_AUTODOWNLOAD = Enabled, SOLL der Konnektor bei Update-Paketen, die Kartenterminals betreffen, pro KT-Modell das Update-Paket mit der höchsten FirmwareVersion über I_KSRS_Download::get_Updates herunterladen.
Der Konnektor MUSS immer nur die neusten Update-Pakete für eine Nutzung vorhalten. Eventuell vorhandene ältere, nicht genutzte Update-Pakete KÖNNEN überschrieben werden. [<=]
TIP1-A_4836-02 - ab PTV4: Automatische Prüfung und Download von Update-Paketen
Der Konnektor MUSS täglich die folgenden Schritte durchführen:
- TUC_KON_282 „UpdateInformationen beziehen“ aufrufen.
- pro zurück geliefertem Listeneintrag prüfen, ob eine neuere Version enthalten ist, als auf dem zugehörigen Gerät (Konnektor selbst oder Kartenterminal) vorhanden
- Ist für wenigstens ein Gerät eine neuere Version vorhanden, MUSS der Konnektor darüber via
TUC_KON_256 „Systemereignis absetzen“ {
topic = „KSR/UPDATES_AVAILABLE“;
eventType = Op;
severity = Info;
parameters = (<Param>);
doLog=false }
informieren. Je gefundenem Update MUSS <Param> mit folgenden Werten belegt sein:
<Param> = „ProductVendorID= $UpdateInformation/ProductVendorID;
ProductCode= $UpdateInformation/ProductCode;
ProductName=$UpdateInformation/ProductName;
FirmwareVersion=$UpdateInformation/FirmwareVersion;
Deadline=$UpdateInformation/DeploymentInformation/Deadline;
FWPriority=$UpdateInformation/Firmware/FWPriority;
FirmwareReleaseNotes=
$UpdateInformation/Firmware/FirmwareReleaseNotes“
- Ist für wenigstens ein Gerät eine neuere Version vorhanden, MUSS der Konnektor in den Betriebszustand EC_FW_Update_Available übergehen.
- Die listUpdateResponse mit neueren Firmwareversionen MÜSSEN für eine spätere Einsichtnahme durch den Administrator bereitgehalten werden (via (TIP1-A_4837) „Übersichtsseite des KSR-Client). Ein neuerlicher Abruf dieser Informationen DARF NICHT erforderlich sein.
- Sofern ein Update-Paket für den Konnektor selbst vorliegt, MUSS der Konnektor die mit diesem Paket gelieferten Parameter Priority (entspricht UpdateInformation/Firmware/FWPriority) und Deadline (entspricht UpdateInformation/DeploymentInformation/Deadline) auswerten und bei KSR:Priority=Kritisch persistent ablegen.
- Sofern MGM_KSR_AUTODOWNLOAD = Enabled, MUSS der Konnektor bei Update-Paketen, die den Konnektor selbst betreffen, das Updatepaket mit der höchsten FirmwareVersion über I_KSRS_Download::get_Updates herunterladen, falls das Update-Paket nicht bereits von einem vorherigen Download auf dem Konnektor vorhanden ist.
- Sofern I_KSRS_Download::get_Updates den http Status Code 503 Server Unavailable zurückgibt, MUSS der Konnektor die Informationen aus dem zurückgegebenen Retry-After Header nutzen, um den Zeitpunkt des Retry zu bestimmen.
- Ist der Download von Update-Paketen für den Konnektor abgeschlossen, MUSS der Konnektor darüber via
topic = „KSR/UPDATE/KONNEKTOR_DOWNLOAD_END“;
eventType = Op;
severity = Info;
parameters = (<Param>)}
informieren. Je heruntergeladenem FW-Paket MUSS <Param> mit folgenden Werten belegt sein:
<Param> = „ProductVendorID= $UpdateInformation/ProductVendorID;
ProductCode= $UpdateInformation/ProductCode;
ProductName=$UpdateInformation/ProductName;
FirmwareVersion=$UpdateInformation/Firmware/FWVersion;
Deadline=$UpdateInformation/DeploymentInformation/Deadline;
=$UpdateInformation/Firmware/FirmwareReleaseNotes“
- Sofern MGM_KSR_AUTODOWNLOAD = Enabled, SOLL der Konnektor bei Update-Paketen, die Kartenterminals betreffen, pro KT-Modell das Updatepaket mit der höchsten FirmwareVersion über I_KSRS_Download::get_Updates herunterladen, falls das Update-Paket nicht bereits von einem vorherigen Download auf dem Konnektor vorhanden ist.
- Sofern I_KSRS_Download::get_Updates den http Status Code 503 Server Unavailable zurückgibt, MUSS der Konnektor die Informationen aus dem zurückgegebenen Retry-After Header nutzen, um den Zeitpunkt des Retry zu bestimmen.
Der Konnektor MUSS immer nur die neusten Update-Pakete für eine Nutzung vorhalten. Eventuell vorhandene ältere, nicht genutzte Update-Pakete KÖNNEN überschrieben werden.
Nach einem erfolgreichen Download DÜRFEN die Namen der Dateien eines Update-Paketes beim Abspeichern NICHT verändert werden. [<=]
TIP1-A_7220 - Konnektoraktualisierung File Transfer Ranges
Der Konnektor KANN für den Download von Update-Paketen über I_KSRS_Download::get_Updates die Option Range Requests [RFC7233#3.1] zur Fortsetzung von unterbrochenen Transfers nutzen. [<=]
TIP1-A_4837 - Übersichtsseite des KSR-Client
Die Administrationsoberfläche des KSR-Clients MUSS dem Administrator eine Übersichtseite anbieten, die einen Geräteeintrag für den Konnektor selbst, sowie eine Liste von Geräteeinträgen für jedes Kartenterminal (CT) aus CTM_CT_LIST mit CT.IS_PHYSICAL=Ja und CT.CORRELATION>=„gepairt“ enthält.
Der Administrator MUSS die Liste der Kartenterminals nach Kartenterminalmodellen gruppieren können (gleiche Werte für ProductVendorID, ProductCode, HardwareVersion und FirmwareVersion).
Je Geräteeintrag MÜSSEN die über „Automatische Prüfung und Download von Update-Paketen“ ermittelten listUpdatesResponse bereitstehen.
Je Geräteeintrag MUSS die Version der aktuell installierten Software dargestellt werden. Sind Bestandteile der installierten Software unabhängig aktualisierbar, so MUSS für jedes der Bestandteile die Version angezeigt werden.
Der Administrator MUSS eine Aktualisierung aller listUpdatesResponse über TUC_KON_282 „UpdateInformationen beziehen“ auslösen können.
Geräteeinträge, die über listUpdatesResponse mit neuerer Firmwareversion als das zugehörige Gerät verfügen, MÜSSEN hervorgehoben werden.
Je Geräteeintrag MUSS die Zugehörigkeit der installierten Software und der Software-Updates zum Online-Produktivbetrieb oder zu einer Erprobung (inklusive Name der Erprobung) dargestellt werden.
[<=]TIP1-A_4838 - Einsichtnahme in Update-Informationen
Für alle Geräteeinträge MUSS der Administrator zu den listUpdatesResponse sowohl die FirmwareGroupReleaseNotes als auch jedes enthaltene UpdateInformation-Element einsehen können. Dazu MUSS der Konnektor
alle Felder der Struktur verständlich umsetzen und strukturiert anzeigen (inkl. der Notes für jedes Firmwarefiles- und Documentationsfiles-Element)
jedes über das Documentationfiles-Element erreichbare Dokument auf Anforderung des Administrator herunterladen und anzeigen. Es MÜSSEN dabei mindestens die folgenden Dokumentenformate zur Anzeige gebracht werden können: Text, PDF, JPEG, TIFF
TIP1-A_4839-01 - Festlegung der durchzuführenden Updates
Der Administrator MUSS in der Übersichtsliste einzelne Geräteeinträge bzw. Gruppen mit der jeweils anzuwendenden UpdateInformation für die Durchführung eines Updates markieren können.
Alternativ MUSS der Administrator neben der Markierung je Geräteeintrag bzw. Gruppe Update-Pakete lokal einspielen können (etwa durch ein Upload- bzw. Download-Interface in der Administrationsoberfläche).
Je Geräteeintrag MUSS der Administrator einen individuellen Ausführungszeitpunkt für die Durchführung des Updates einstellen können.
Der Administrator MUSS für den Geräteeintrag Konnektor festlegen können, ob dieses Update erst gestartet werden darf, wenn zuvor alle festgelegten KT-Updates erfolgreich durchlaufen wurden.
Der Administrator MUSS zu jeder Zeit die gerätebezogene Festlegung für ein Update ändern bzw. löschen können, sofern dieses konkrete Update noch nicht begonnen wurde.
Je Geräteeintrag MUSS der Administrator automatische Softwareupdates aktivieren und deaktivieren können.
[<=]
TIP1-A_4840-01 - Manuelles Auslösen der durchzuführenden Updates
Der Administrator MUSS für die Liste der markierten Geräteeinträge ein gesammeltes Update auslösen können. Dieses MUSS nach folgendem Muster ablaufen:
- Alle Kartenterminaleinträge abarbeiten. Pro markiertem Kartenterminal:
- Wenn Ausführungszeitpunkt nicht gesetzt:
Anwenden des definierten Updates mittels TUC_KON_281 „Kartenterminalaktualisierung anstoßen“
- Wenn Ausführungszeitpunkt gesetzt:
Anwenden des definierten Updates mittels TUC_KON_281 sobald der Ausführungszeitpunkt erreicht ist oder, sofern der Konnektor zum Ausführungszeitpunkt nicht in Betrieb war, überschritten wurde. Konnte das Kartenterminal nicht erreicht werden, so MUSS das gesetzte Update im KSR-Client für eine spätere Anwendung erhalten bleiben (wird ereignisgesteuert neu ausgelöst).
- Sofern die KonnektorUpdate-Abhängigkeit von KT-Updates nicht gesetzt wurde oder wenn alle vorgesehenen Kartenterminal-Updates durchgeführt wurden, MUSS das Konnektor-Updates mittels TUC_KON_280 „Konnektoraktualisierung durchführen“ wie folgt begonnen werden:
- wenn Ausführungszeitpunkt nicht gesetzt: TUC-Aufruf direkt
- wenn Ausführungszeitpunkt gesetzt: TUC-Aufruf direkt sobald der Ausführungszeitpunkt erreicht ist oder, sofern der Konnektor zum Ausführungszeitpunkt nicht in Betrieb war, überschritten wurde
- dass es sich um ein Erprobungs-Update handelt,
- für welche Erprobung es vorgesehen ist,
- dass das Update-Paket nur installiert werden sollte, wenn die Institution oder Organisation des Gesundheitswesens an der Erprobung teilnimmt,
A_18390 - Automatisches Auslösen der durchzuführenden Updates
Wenn für mindestens ein Gerät das automatische Softwareupdate aktiviert ist, MUSS der Konnektor zur MGM_KSR_AUTO_UPDATE_TIME die Updates nach folgendem Muster durchführen:
- Alle Geräte (Kartenterminals und Konnektor), für die MGM_KSR_AUTO_UPDATE=Enabled ist, werden markiert
- Alle Kartenterminaleinträge abarbeiten
- Pro markiertem Kartenterminal: Anwenden des automatischen Updates mittels TUC_KON_281 „Kartenterminalaktualisierung anstoßen"
- Sofern die Konnektorupdate-Abhängigkeit von KT-Updates nicht gesetzt wurde oder wenn alle vorgesehenen Kartenterminal-Updates durchgeführt wurden, MUSS für einen markierten Konnektor das Konnektor-Update mittels TUC_KON_280 „Konnektoraktualisierung durchführen“ begonnen werden.
A_18391 - Automatisches Updates nicht nachholen
Sofern der Konnektor zu MGM_KSR_AUTO_UPDATE_TIME nicht in Betrieb war, DÜRFEN die automatischen Updates später NICHT nachgeholt werden. [<=]
A_18779 - Hinweise in KSR Update Paket zu Auto-Update
Wenn mit einem Update erstmalig MGM_KSR_AUTO_UPDATE=Enabled aktiv wird, MUSS der Konnektorhersteller über das entsprechende KSR-Paket den Admin an der Konnektor Oberfläche darauf hinweisen, dass mit diesem Update der automatische Softwareupdate aktiv wird.
[<=]
A_20531 - Größe der Bestandsnetze.xml
Der Konnektor MUSS eine Bestandsnetze.xml mit einer Größe von mindestens 3 MByte und 2000 Netzen (XML Element <Network>) verarbeiten können. [<=]
4.3.11 Konnektorstatus
TIP1-A_5542 - Konnektor, Funktion zur Prüfung der Erreichbarkeit von Systemen
Der Konnektor MUSS an der Managementschnittstelle eine Funktion anbieten, die es ermöglicht die Erreichbarkeit von Systemen durch Eingabe der IP-Adresse oder des FQDN zu prüfen. Das Ergebnis des Tests MUSS angezeigt werden.
[<=]A_23276 - Konnektor, automatische Prüfung der Erreichbarkeit von Systemen
Der Konnektor MUSS dem Administrator an der Management-Oberfläche automatisch die Erreichbarkeit und die FQDNs von folgenden Systemen und ggf. ihren Backupservern anzeigen:
- CRL
- OCSP-Forwarder
- TSL
- BNetzA-VL
- KSR
- VZD
- Intermediaer VSDM
- SGD
- alle erreichbaren Aktensysteme
4.4 Hardware-Merkmale des Konnektors
TIP1-A_4841 - Hardware für Dauerbetrieb
Der Konnektor MUSS sowohl in seiner Stromversorgung als auch in seinen restlichen Hardwarekomponenten auf einen 24x7-Dauerbetrieb ausgelegt sein.
Der Hersteller DARF NICHT davon ausgehen oder gar in seiner Guidance darauf verweisen, dass der Konnektor mehrere Stunden am Tag nicht betrieben wird.
[<=]Diese Anforderung verlangt keinen Schutz gegen Stromausfall in den Betriebsräumen.
TIP1-A_4842 - Gehäuseversiegelung
Jeder Konnektor, der als Appliance (dezidierte, geschlossene Kombination aus spezifischer Hard- und Software) ausgeprägt ist, MUSS über eine fälschungssichere Gehäuseversiegelung verfügen. Die Versiegelung MUSS so angebracht werden, dass eine Öffnung des Gehäuses nicht ohne Beschädigung des Siegels erfolgen kann.
Der Konnektor MUSS die Umsetzung entsprechend der Festlegungen für das Kartenterminal nach der TR-03120 [BSI TR-03120], Kapitel bzgl. Gehäuseversiegelung 9 vornehmen.
Die optische Gestaltung der Siegel ist herstellerspezifisch.
[<=]Die Prüfung auf Einhaltung der Versiegelungsvorgaben erfolgt nicht im Rahmen der CC-Evaluierung, sondern im Zuge der Prüfung auf funktionale Eignung.
TIP1-A_4843 - Zustandsanzeige
Im Betrieb MUSS der Zustand des Konnektors erkennbar sein. Zur Anzeige des Betriebszustandes des Konnektors SOLL es eine Signaleinrichtung (z. B. über Status-LEDs) am Konnektor geben. Falls keine Signalvorrichtung am Konnektorgehäuse verwendet wird MUSS es eine softwareseitige Lösung über das Managementinterface geben. Bei verbauter Hardware-Signalgebung KANN eine softwareseitige Lösung zusätzlich angeboten werden.
Es MÜSSEN mindestens folgende angezeigt werden:
- Power ON,
- Link Status pro physischer Netzwerkschnittstelle
- Fehler/Kritischer Betriebszustand gemäß Kapitel 3.3
- Status pro IPsec-Verbindung
TIP1-A_4844-02 - Ethernet-Schnittstellen
Der Konnektor MUSS mindestens zwei Ethernetinterfaces nach [IEEE802.3] als physikalische Schnittstellen zur Verfügung stellen.
[<=]
TIP1-A_4845 - Verwendungsumgebung - Klima
Als normaler Einsatzort wird für den Konnektor ein Büroraum angenommen. Der Konnektor MUSS die in Tabelle TAB_KON_671 aufgeführten Anforderungen erfüllen, welche unter der Annahme des normalen Einsatzortes erhoben werden.
Tabelle 389: TAB_KON_671 Anforderungen Klima
Prüfung Klima |
Trockene Wärme (Dry Heat) nach DIN EN 60068-2-2 Methode Bb wird für die Bedingungen als obere Lagertemperatur von 55°C und einer Beanspruchungsdauer von 16 h geprüft und die Funktionsfähigkeit MUSS bestätigt werden. |
Kälte (Cold) nach DIN EN 60068-2-1 Methode Ab wird für die Bedingungen als untere Lagertemperatur von -10°C und einer Beanspruchungsdauer von 16 h geprüft und die Funktionsfähigkeit MUSS bestätigt werden. |
Nach den beiden oben genannten Belastungen durch extreme Lagertemperaturen und der Nachbehandlungsdauer von 1 h MUSS die Funktionsfähigkeit des Konnektors gewährleistet sein, was durch Funktionsprüfungen nachzuweisen ist. |
Die Funktionsfähigkeit im Betrieb MUSS bei einer oberen Temperatur von 40°C über eine Dauer von 24 h gewährleistet sein. Dies wird für den Konnektor durch Prüfung nach DIN EN 60068-2-2 Methode Bb bei gleichzeitigen Funktionsprüfungen nachgewiesen. |
[<=]
TIP1-A_4846 - Verwendungsumgebung – Vibration
Die durch Vibrationen und mechanische Schockbelastungen auftretenden Belastungen MÜSSEN vom Konnektor schadensfrei gemäß IEC 68-2 Methode nach den Anforderungen aus TAB_KON_672 absolviert, geprüft und nachgewiesen werden.
Tabelle 390: TAB_KON_672 Anforderungen Vibration
Prüfung Vibration |
Sinusförmige Schwingungstests (Vibration, sinusoidal) nach DIN EN 60068-2-6 Methode Fc in drei senkrecht stehenden Achsen in einem Frequenzbereich von 2 Hz bis 200 Hz üblicherweise 1 h je Achse MÜSSEN erfolgreich nachgewiesen werden. Bis zu einer Frequenz von 9 Hz wird dabei mit einer konstanten Amplitude von 1,5 mm belastet, darüber bis zur oberen Frequenz wird mit einer konstanten Beschleunigung von 5 m/s2 (0,5 g) belastet. |
Es MÜSSEN mechanische Schockprüfungen (Shock) nach DIN EN 60068-2-27 Methode Ea in drei senkrecht stehenden Achsen (sechs Richtungen) erfolgreich nachgewiesen werden. Es wird dabei für jede Achse mit 3 positiven und 3 negativen Schocks mit 150 m/s2 (15 g) Amplitude und einer Dauer von 11 ms belastet. |
Dauerschocktests (Bump) nach DIN EN 60068-2-29 Methode Eb in drei senkrecht stehenden Achsen mit halbsinusförmigen Schocks MÜSSEN erfolgreich nachgewiesen werden. Es wird dabei für jede Achse mit 1000 positiven und 1000 negativen Schocks mit 100 m/s2 (10 g) Amplitude und einer Dauer von 16 ms belastet. |
[<=]
TIP1-A_4846-02 - ab PTV4: Verwendungsumgebung – Vibration
Die durch Vibrationen und mechanische Schockbelastungen auftretenden Belastungen MÜSSEN vom Konnektor schadensfrei gemäß IEC 68-2 Methode nach den Anforderungen aus TAB_KON_672 absolviert, geprüft und nachgewiesen werden.
Tabelle 391: TAB_KON_672 Anforderungen Vibration
Prüfung Vibration |
Sinusförmige Schwingungstests (Vibration, sinusoidal) nach DIN EN 60068-2-6 Methode Fc in drei senkrecht stehenden Achsen in einem Frequenzbereich von 2 Hz bis 200 Hz üblicherweise 1 h je Achse MÜSSEN erfolgreich nachgewiesen werden. Bis zu einer Frequenz von 9 Hz wird dabei mit einer konstanten Amplitude von 1,5 mm belastet, darüber bis zur oberen Frequenz wird mit einer konstanten Beschleunigung von 5 m/s2 (0,5 g) belastet. |
Es MÜSSEN mechanische Schockprüfungen (Shock) nach DIN EN 60068-2-27 Methode Ea in drei senkrecht stehenden Achsen (sechs Richtungen) erfolgreich nachgewiesen werden. Es wird dabei für jede Achse mit 3 positiven und 3 negativen Schocks mit 150 m/s2 (15 g) Amplitude und einer Dauer von 11 ms belastet. |
Dauerschocktests (Bump) nach DIN EN 60068-2-27 Methode Eb in drei senkrecht stehenden Achsen mit halbsinusförmigen Schocks MÜSSEN erfolgreich nachgewiesen werden. Es wird dabei für jede Achse mit 1000 positiven und 1000 negativen Schocks mit 100 m/s2 (10 g) Amplitude und einer Dauer von 16 ms belastet. |
[<=]
5 Anhang A – Verzeichnisse
5.1 Abkürzungen
Kürzel |
Erläuterung |
---|---|
AMTS |
Arzneimitteltherapiesicherheit |
APPL DO |
Application Label Data Object |
CC |
Common Criteria |
DHCP |
Dynamic Host Configuration Protocol |
DNS |
Domain Name Service |
DO |
Datenobjekt |
DSL |
Digital Subscriber Line |
ECC |
Elliptic Curve Cryptography |
EVG |
Evaluierungsgegenstand |
gSMC-K |
Security Module Card Typ K (Konnektor) |
gSMC-KT |
Security Module Card Typ KT (Kartenterminal) |
HBA |
Heilberufsausweis |
HSM-B |
Hardware Security Module Typ B |
IAG |
Internet Access Gateway |
ID |
Identifier |
ISP |
Internet Service Provider |
KT |
Kartenterminal |
KVK |
Krankenversichertenkarte |
LAN |
Local Area Network |
MTOM |
Message Transmission Optimization Mechanism |
NFDM |
Notfalldatenmanagement |
NK |
Netzkonnektor |
NTP |
Netzwork Time Protokoll |
OCSP |
Online Certificate Status Protocol |
OID |
Object Identifier |
PIN |
Personal |
PKI |
Public Key Infrastructure |
PP |
Protection Profile |
PU |
Produktivumgebung |
PUK |
Personal Unblocking Key |
QES |
Qualifizierte elektronische Signatur |
RU |
Referenzumgebung |
SIS |
Secure Internet Service |
SMC-B |
Security Module Card Typ B |
SMTBD DO |
SICCT Message-To-Be-Displayed Data Object |
SOAP |
Standard für die Kommunikation innerhalb der WEB-Services |
TI |
Telematikinfrastruktur |
TLS |
Transport Layer Security |
TSF |
TOE Security Functionality |
TU |
Testumgebung |
TUC |
Technischer Use Case |
URL |
Uniform Resource Locator |
VPN |
Virtual Private Network |
VSDM |
Versichertenstammdatenmanagement |
VZD |
Verzeichnisdienst |
WAN |
Wide Area Network |
WANDA Basic | Weitere Anwendungen für den Datenaustausch ohne Nutzung der TI oder derer kryptografischen Identitäten |
WANDA Smart | Weitere Anwendungen für den Datenaustausch mit Nutzung der TI oder derer kryptografischen Identitäten für eigene Anwendungszwecke |
XML |
Extensible Markup Language |
ZD |
Zertifizierungsdienst |
ZOD 2.0 |
Zahnärzte Online Deutschland 2.0 |
5.2 Glossar
Begriff |
Erläuterung |
---|---|
Funktionsmerkmal |
Der Begriff beschreibt eine Funktion oder auch einzelne, eine logische Einheit bildende Teilfunktionen der TI im Rahmen der funktionalen Zerlegung des Systems. |
Das Glossar wird als eigenständiges Dokument, vgl. [gemGlossar] zur Verfügung gestellt.
5.3 Abbildungsverzeichnis
- Abbildung 1: PIC_KON_116 Schnittstellen des Konnektors von und zu anderen Produkttypen
- Abbildung 2: PIC_KON_117 Logische Zerlegung des Konnektors in Anwendungs- und Netzkonnektor
- Abbildung 3: PIC_KON_107 XML-Struktur des Status-Elements einer SOAP-Antwort
- Abbildung 4: PIC_Kon_100 Informationsmodell des Konnektors
- Abbildung 5: PIC_KON_101 Aufrufkontext der Operation
- Abbildung 6: PIC_KON_118 Aktivitätsdiagramm zu „TUC_KON_000 Prüfe Zugriffsberechtigung“
- Abbildung 7: PIC_KON_071 Korrelationszustände eines eHealth-KT
- Abbildung 8: PIC_KON_110 Aktivitätsdiagramm zu „Beginne Kartenterminalsitzung“
- Abbildung 9: PIC_KON_057 Aktivitätsdiagramm zu „PaireKartenterminal“
- Abbildung 10: PIC_KON_111 Aktivitätsdiagramm zu „PIN verifizieren“
- Abbildung 11: PIC_KON_022 Grundsätzlicher Aufbau der Ereignisnachricht
- Abbildung 12: PIC_KON_112 Aktivitätsdiagramm zu „Systemereignis absetzen“
- Abbildung 13: PIC_KON_058 Aktivitätsdiagramm „Daten hybrid verschlüsseln“
- Abbildung 14: PIC_KON_059 Aktivitätsdiagramm „Daten hybrid entschlüsseln“
- Abbildung 15: PIC_KON_103 Use Case Diagramm Signaturdienst (nonQES)
- Abbildung 16: PIC_KON_104 Use Case Diagramm Signaturdienst (QES)
- Abbildung 17: PIC_KON_102 Use Case Diagramm Signaturdienst (Komfortsignatur)
- Abbildung 18: PIC_KON_113 Aktivitätsdiagramm zu „QES Signaturen erstellen“
- Abbildung 19: PIC_KON_114 Aktivitätsdiagramm zu „Dokument QES signieren“
- Abbildung 20: PIC_KON_118 Aufbau und Struktur der Protokolldateien für Plattform und Fachmodule
- Abbildung 21: PIC_KON_115 Kommunikationsregeln Konnektor
- Abbildung 22: PIC_KON_105 Aktivitätsdiagramm Konnektoraktualisierung durchführen
- Abbildung 23: PIC_KON_120 Abbildung von CardSessions auf logische Kanäle
- Abbildung 24: Szenario einer einfachen Installation
- Abbildung 25: Szenario einer Installation mit mehreren Behandlungsräumen
- Abbildung 26: Szenario einer Integration der TI Produkte in eine bestehende Infrastruktur
- Abbildung 27: Szenario einer Integration der TI Produkte in eine bestehende Infrastruktur mit existierendem Router
- Abbildung 28: Szenario mit zentral gesteckten HBA und SMC-B
- Abbildung 29: Szenario mit zentralem Primärsystem als Clientsystem
- Abbildung 30: Szenario für den Zugriff
- Abbildung 31: Standalone-Szenario mit physischer Trennung im Konnektor
5.4 Tabellenverzeichnis
- Tabelle 1 Fehlercodes TAB_KON_890 Mindestanforderungen an Dokumente und Nachrichten
- Tabelle 2 Fehlercodes TAB_KON_891 Unerlaubte Inhalte in Dokumenten und Nachrichten
- Tabelle 3: TAB_KON_500 Wertetabelle Kartentypen
- Tabelle 4: TAB_KON_856: Identitäten des Konnektors auf der gSMC-K
- Tabelle 5: TAB_KON_930 – TUC_KON_410 „Zertifikate aktualisieren“
- Tabelle 6: Tab_Kon_931 Fehlercodes TUC_KON_410 „gSMC-K-Zertifikate aktualisieren“
- Tabelle 7: TAB_KON_503 Betriebszustand_Fehlerzustandsliste
- Tabelle 8: TAB_KON_504-01 Ausführungserlaubnis für Dienste in kritischen Fehlerzuständen
- Tabelle 9: TAB_KON_502 Fehlercodes „Betriebszustand“
- 10
- Tabelle 11: TAB_KON_852 Konfigurationsvarianten der Verbindungen zwischen Konnektor und Clientsystemen
- Tabelle 12: TAB_KON_865-01 Konfigurationsvarianten der Verbindungen zwischen Konnektor und Clientsystemen bei LDAP
- Tabelle 13: TAB_KON_506-01 Konfigurationsparameter der Clientsystem-Authentisierung
- Tabelle 14 : TAB_KON_866 Unterstützte Verfahren für generierte und importierte Schlüssel und Zertifikate
- Tabelle 15: TAB_KON_812 Umgebungsabhängige Konfigurationsparameter
- Tabelle 16: TAB_KON_507 Informationsmodell Entitäten
- Tabelle 17: TAB_KON_508 Informationsmodell Attribute
- Tabelle 18: TAB_KON_509 Informationsmodell Entitätenbeziehungen
- Tabelle 19: TAB_KON_510 Informationsmodell Constraints
- Tabelle 20: TAB_KON_511-01 – TUC_KON_000 „Prüfe Zugriffsberechtigung“
- Tabelle 21: TAB_KON_512 Zugriffsregeln Beschreibung
- Tabelle 22: TAB_KON_513 Zugriffsregeln Regelzuordnung
- Tabelle 23: TAB_KON_514-01 Zugriffsregeln Definition
- Tabelle 24: TAB_KON_515 Fehlercodes TUC_KON_000 „Prüfe Zugriffsberechtigung“
- Tabelle 25: TAB_KON_143 – TUC_KON_080 „Dokument validieren“
- Tabelle 26: TAB_KON_144 Fehlercodes TUC_KON_080 „Dokument validieren“
- Tabelle 27: TAB_KON_516 Basisanwendung Dienstverzeichnisdienst
- Tabelle 28: TAB_KON_517 Schemabeschreibung Produktinformation (ProductInformation.xsd)
- Tabelle 29: TAB_KON_518 Schemabeschreibung Serviceinformation (Serviceinformation.xsd)
- Tabelle 30: TAB_KON_519 - TUC_KON_041 „Einbringen der Endpunktinformationen während der Bootup-Phase“
- Tabelle 31: TAB_KON_520 Fehlercodes TUC_KON_041 „Einbringen der Endpunktinformationen während der Bootup-Phase“
- Tabelle 32: TAB_KON_521 Schnittstelle der Basisanwendung Dienstverzeichnisdienst
- Tabelle 33: TAB_KON_522 Parameterübersicht des Kartenterminaldienstes
- Tabelle 34: TAB_KON_785 Erlaubte SICCT-Kommandos bei CT.CONNECTED=Nein
- Tabelle 35: TAB_KON_727 Terminalanzeigen beim Anfordern und Auswerfen von Karten
- Tabelle 36: TAB_KON_039 – TUC_KON_050 „Beginne Kartenterminalsitzung“
- Tabelle 37: TAB_KON_523 Fehlercodes TUC_KON_050 „Beginne Kartenterminalsitzung“
- Tabelle 38: TAB_KON_524 – TUC_KON_054 „Kartenterminal hinzufügen“
- Tabelle 39: TAB_KON_525 Fehlercodes TUC_KON_054 „Kartenterminal hinzufügen“
- Tabelle 40: TAB_KON_041 – TUC_KON_053 „Paire Kartenterminal“
- Tabelle 41: TAB_KON_113 Fehlercodes TUC_KON_053 „Paire Kartenterminal“
- Tabelle 42: TAB_KON_526 – TUC_KON_055 „Befülle CT-Object“
- Tabelle 43: TAB_KON_112 – TUC_KON_051 „Mit Anwender über Kartenterminal interagieren“
- Tabelle 44: TAB_KON_114 Fehlercodes TUC_KON_051 „Mit Anwender über Kartenterminal interagieren“
- Tabelle 45: TAB_KON_723 - TUC_KON_056 „Karte anfordern“
- Tabelle 46: TAB_KON_724 Fehlercodes TUC_KON_056 „Karte anfordern“
- Tabelle 47: TAB_KON_725 – TUC_KON_057 „Karte auswerfen“
- Tabelle 48: TAB_KON_796 Fehlercodes TUC_KON_057 „Karte auswerfen“
- Tabelle 49: TAB_KON_854 – TUC_KON_058 „Displaygröße ermitteln“
- Tabelle 50: TAB_KON_855 Fehlercodes TUC_KON_058 „Displaygröße ermitteln“
- Tabelle 51: TAB_KON_722 Basisdienst Kartenterminaldienst
- Tabelle 52: TAB_KON_716 Operation RequestCard
- Tabelle 53: TAB_KON_717 Ablauf RequestCard
- Tabelle 54: TAB_KON_718 Fehlercodes „RequestCard“
- Tabelle 55: TAB_KON_719 Operation EjectCard
- Tabelle 56: TAB_KON_720 Ablauf EjectCard
- Tabelle 57: TAB_KON_721 Fehlercodes Operation „EjectCard“
- Tabelle 58: TAB_KON_527 Konfigurationswerte eines Kartenterminalobjekts
- Tabelle 59: TAB_KON_528 Informationsparamter des Kartenterminaldienstes
- Tabelle 60: TAB_KON_529 Anzeigewerte zu einem Kartenterminalobjekt
- Tabelle 61: TAB_KON_530 Konfigurationswerte eines Kartenterminalobjekts
- Tabelle 62: TAB_KON_531 Parameterübersicht des Kartendienstes
- Tabelle 63: TAB_KON_090 Terminalanzeigen beim Eingeben der PIN am Kartenterminal
- Tabelle 64: TAB_KON_734 – TUC_KON_001 „Karte öffnen“
- Tabelle 65: TAB_KON_735 - TUC_KON_026
- Tabelle 66: TAB_KON_824 Fehlercodes TUC_KON_026 „Liefere CardSession“
- Tabelle 67: TAB_KON_087 – TUC_KON_012 „PIN verifizieren“
- Tabelle 68: TAB_KON_089 Fehlercodes TUC_KON_012 „PIN verifizieren“
- Tabelle 69: TAB_KON_736 – TUC_KON_019 „PIN ändern“
- Tabelle 70: TAB_KON_093 Fehlercodes TUC_KON_019 „PIN ändern“
- Tabelle 71: TAB_KON_236 – TUC_KON_021 „PIN entsperren“
- Tabelle 72: TAB_KON_193 Fehlercodes TUC_KON_021 „PIN entsperren“
- Tabelle 73 TAB_KON_532 – TUC_KON_022 „Liefere PIN-Status“
- Tabelle 74: TAB_KON_091 Fehlercodes TUC_KON_022 „Liefere PIN-Status“
- Tabelle 75: TAB_KON_240 - TUC_KON_027 „PIN-Schutz ein-/ausschalten”
- Tabelle 76: TAB_KON_838 Mapping von pinRef auf ANW
- Tabelle 77: TAB_KON_241 Fehlercodes TUC_KON_027 „PIN-Schutz ein/ausschalten“
- Tabelle 78: TAB_KON_533 - TUC_KON_023 „Karte reservieren”
- Tabelle 79: TAB_KON_534 Fehlercodes TUC_KON_023 „Karte reservieren“
- Tabelle 80: TAB_KON_096 – TUC_KON_005 „Card-to-Card authentisieren”
- Tabelle 81: TAB_KON_673 AuthMode für C2C
- Tabelle 82: TAB_KON_674 Erlaubte Parameterkombinationen und resultierende CV-Zertifikate für C2C
- Tabelle 83: TAB_KON_535 Fehlercodes TUC_KON_005 „Card-to-Card authentisieren“
- Tabelle 84: TAB_KON_218 – TUC_KON_202 „LeseDatei“
- Tabelle 85: TAB_KON_536 Fehlercodes TUC_KON_202 „LeseDatei“
- Tabelle 86: TAB_KON_219 – TUC_KON_203 „SchreibeDatei“
- Tabelle 87: TAB_KON_537 Fehlercodes TUC_KON_203 „Schreibe Datei“
- Tabelle 88: TAB_KON_204 – TUC_KON_204 „LöscheDateiInhalt“
- Tabelle 89: TAB_KON_785 Fehlercodes TUC_KON_204 „LöscheDateiInhalt“
- Tabelle 90: TAB_KON_538 – TUC_KON_209 „LeseRecord“
- Tabelle 91: TAB_KON_539 Fehlercodes TUC_KON_209 „LeseRecord“
- Tabelle 92: TAB_KON_224 – TUC_KON_210 „SchreibeRecord“
- Tabelle 93: TAB_KON_540 Fehlercodes TUC_KON_210 „SchreibeRecord“
- Tabelle 94: TAB_KON_211 – TUC_KON_211 „LöscheRecordInhalt“
- Tabelle 95: TAB_KON_786 Fehlercodes TUC_KON_211 „LöscheRecordInhalt“
- Tabelle 96: TAB_KON_228 – TUC_KON_214 „FügeHinzuRecord“
- Tabelle 97: TAB_KON_541 Fehlercodes TUC_KON_214 „FügeHinzuRecord“
- Tabelle 98: TAB_KON_229 – TUC_KON_215 „SucheRecord“
- Tabelle 99: TAB_KON_542 Fehlercodes TUC_KON_215 „SucheRecord“
- Tabelle 100: TAB_KON_110 - TUC_KON_018 „eGK-Sperrung prüfen“
- Tabelle 101: TAB_KON_239 Fehlercodes TUC_KON_018 „eGK-Sperrung prüfen“
- Tabelle 102: TAB_KON_108 - TUC_KON_006 „Datenzugriffsaudit eGK schreiben“
- Tabelle 103: TAB_KON_238 Fehlercodes TUC_KON_006 „Datenzugriffsaudit eGK schreiben“
- Tabelle 104: TAB_KON_231 – TUC_KON_218 „Signiere“
- Tabelle 105: TAB_KON_543 Fehlercodes TUC_KON_218 „Signiere“
- Tabelle 106: TAB_KON_232 – TUC_KON_219 „Entschlüssele“
- Tabelle 107: TAB_KON_210 Fehlercodes TUC_KON_219 „Entschlüssele“
- Tabelle 108: TAB_KON_215 TUC_KON_200 „SendeAPDU“
- Tabelle 109: TAB_KON_216 Fehlercodes TUC_KON_200 „SendeAPDU“
- Tabelle 110: TAB_KON_737 – TUC_KON_024 „Karte zurücksetzen“
- Tabelle 111: TAB_KON_544 Fehlercodes TUC_KON_024 „Karte zurücksetzen“
- Tabelle 112: TAB_KON_230 – TUC_KON_216 „LeseZertifikat“
- Tabelle 113: TAB_KON_209 Fehlercodes TUC_KON_216 „LeseZertifikat“
- Tabelle 114: TAB_KON_827 TUC_KON_036 „LiefereFachlicheRolle“
- Tabelle 115: TAB_KON_829 Fehlercodes TUC_KON_036 „LiefereFachlicheRolle“
- Tabelle 116: TAB_KON_038 Basisanwendung Karten- und Kartenterminaldienst
- Tabelle 117: TAB_KON_047 Operation VerifyPin
- Tabelle 118: TAB_KON_738 Ablauf VerifyPin
- Tabelle 119: TAB_KON_545 Fehlercodes „VerifyPin“
- Tabelle 120: TAB_KON_049 Operation ChangePin
- Tabelle 121: TAB_KON_546 Ablauf ChangePin
- Tabelle 122: TAB_KON_547 Fehlercodes „ChangePin“
- Tabelle 123: TAB_KON_051 Operation GetPinStatus
- Tabelle 124: TAB_KON_548 Ablauf GetPinStatus
- Tabelle 125: TAB_KON_549 Fehlercodes „GetPinStatus“
- Tabelle 126: TAB_KON_053 Operation UnblockPin
- Tabelle 127: TAB_KON_550 Ablauf UnblockPIN
- Tabelle 128: TAB_KON_551 Fehlercodes „UnblockPin“
- Tabelle 129: TAB_KON_242 Operation EnablePin
- Tabelle 130: TAB_KON_243 Ablauf EnablePin
- Tabelle 131: TAB_KON_244 Fehlercodes „EnablePin“
- Tabelle 132: TAB_KON_245 Operation DisablePin
- Tabelle 133: TAB_KON_246 Ablauf DisablePin
- Tabelle 134: TAB_KON_247 Fehlercodes „DisablePin“
- Tabelle 135: TAB_KON_554 Konfiguration des Kartendienstes
- Tabelle 136: TAB_KON_555 - TUC_KON_025 „Initialisierung Kartendienst“
- Tabelle 137: TAB_KON_030 Ereignisnachricht
- Tabelle 138: TAB_KON_556 - TUC_KON_256 „Systemereignis absetzen“
- Tabelle 139: TAB_KON_557 Fehlercodes TUC_KON_256 „Systemereignis absetzen“
- Tabelle 140: TAB_KON_558 – TUC_KON_252 „Liefere KT_Liste“
- Tabelle 141: TAB_KON_559 – TUC_KON_253 „Liefere Karten_Liste“
- Tabelle 142: TAB_KON_560 Fehlercodes TUC_KON_253 „Liefere Karten_Liste“
- Tabelle 143: TAB_KON_561 - TUC_KON_254 „Liefere Ressourcendetails“
- Tabelle 144: TAB_KON_562 Fehlercodes TUC_KON_254 „Liefere Ressourcendetails“
- Tabelle 145 TAB_KON_029 Basisanwendung Systeminformationsdienst
- Tabelle 146: TAB_KON_563 Operation GetCardTerminals
- Tabelle 147: TAB_KON_564 Ablauf GetCardTerminals
- Tabelle 148: TAB_KON_823 Fehlercodes „GetCardTerminals“
- Tabelle 149: TAB_KON_565 Operation GetCards
- Tabelle 150: TAB_KON_566 Ablauf GetCards
- Tabelle 151: TAB_KON_567 Fehlercodes „GetCards“
- Tabelle 152: TAB_KON_568 Operation GetResourceInformation
- Tabelle 153: TAB_KON_569 Ablauf GetResourceInformation
- Tabelle 154: TAB_KON_570 Fehlercodes „GetResourceInformation“
- Tabelle 155: TAB_KON_571 Operation Subscribe
- Tabelle 156: TAB_KON_572 Ablauf Subscribe
- Tabelle 157 TAB_KON_573 Fehlercodes „Subscribe“
- Tabelle 158: TAB_KON_574 Operation Unsubscribe
- Tabelle 159: TAB_KON_575 Ablauf Unsubscribe
- Tabelle 160: TAB_KON_576 Fehlercodes „Unsubscribe“
- Tabelle 161: TAB_KON_792 Operation RenewSubscriptions
- Tabelle 162: TAB_KON_793 Ablauf RenewSubscriptions
- Tabelle 163: TAB_KON_794 Fehlercodes „RenewSubscriptions“
- Tabelle 164: TAB_KON_577 Operation GetSubscription
- Tabelle 165: TAB_KON_578 Ablauf GetSubscription
- Tabelle 166: TAB_KON_579 Fehlercodes „GetSubscription“
- 167
- 168
- Tabelle 169: TAB_KON_747 KeyReference für Encrypt-/DecryptDocument
- Tabelle 170: TAB_KON_859 Werteliste und Defaultwert des Parameters crypt bei hybrider Verschlüsselung
- Tabelle 171: TAB_KON_739 - TUC_KON_070 „Daten hybrid verschlüsseln“
- Tabelle 172: TAB_KON_073 Vorgaben zum Format verschlüsselter XML-Dokumente
- Tabelle 173: TAB_KON_740 Fehlercodes TUC_KON_070 „Daten hybrid verschlüsseln“
- Tabelle 174: TAB_KON_140 – TUC_KON_071 „Daten hybrid entschlüsseln“
- Tabelle 175: TAB_KON_142 Fehlercodes TUC_KON_071 „Daten hybrid entschlüsseln“
- Tabelle 176: TAB_KON_741 – TUC_KON_072 „Daten symmetrisch verschlüsseln“
- Tabelle 177: TAB_KON_742 Fehlercodes TUC_KON_072 „Daten symmetrisch verschlüsseln“
- Tabelle 178: TAB_KON_743 - TUC_KON_073 „Daten symmetrisch entschlüsseln“
- Tabelle 179: TAB_KON_744 Fehlercodes TUC_KON_073 „Daten symmetrisch entschlüsseln“
- Tabelle 180: TAB_KON_860 – TUC_KON_075 „Symmetrisch verschlüsseln“
- Tabelle 181: TAB_KON_861 - TUC_KON_076 „Symmetrisch entschlüsseln“
- Tabelle 182: TAB_KON_745 Basisdienst Verschlüsselungsdienst
- Tabelle 183: TAB_KON_071 Operation EncryptDocument
- Tabelle 184: TAB_KON_746 Ablauf EncryptDocument
- Tabelle 185: TAB_KON_141 Fehlercodes „EncryptDocument“
- Tabelle 186: TAB_KON_075 Operation DecryptDocument
- Tabelle 187: TAB_KON_076 Ablauf DecryptDocument
- Tabelle 188: TAB_KON_145 Fehlercodes „DecryptDocument“
- Tabelle 189: TAB_KON_582 – Signaturverfahren Dokumentensignatur
- Tabelle 190: TAB_KON_778 – Einsatzbereich der Signaturvarianten für XAdES, CAdES und PAdES
- Tabelle 191: TAB_KON_583 – Default-Signaturverfahren
- Tabelle 192: TAB_KON_584 nonQES-Operationen für EVT_MONITOR_OPERATIONS
- Tabelle 193: TAB_KON_900 Zertifikate und private Schlüssel für Signaturerstellung und Signaturprüfung (QES und nonQES)
- Tabelle 194: TAB_KON_862-01 Werteliste und Defaultwert des Parameters crypt bei QES-Erzeugung
- Tabelle 195: TAB_KON_863 Werteliste und Defaultwert des Parameters crypt bei nonQES-Erzeugung
- Tabelle 196: TAB_KON_748 - TUC_KON_155 „Dokumente zur Signatur vorbereiten“
- Tabelle 197: TAB_KON_586 Fehlercodes TUC_KON_155 „Dokumente zur Signatur vorbereiten“
- Tabelle 198: TAB_KON_749 – TUC_KON_165 „Signaturvoraussetzungen für nonQES prüfen“
- Tabelle 199: TAB_KON_587 Fehlercodes TUC_KON_165 „Signaturvoraussetzungen für nonQES prüfen“
- Tabelle 200: TAB_KON_750 – TUC_KON_166 „nonQES Signaturen erstellen“
- Tabelle 201: TAB_KON_120 Fehlercodes TUC_KON_166 „nonQES Signaturen erstellen“
- Tabelle 202: TAB_KON_751 – TUC_KON_152 „Signaturvoraussetzungen für QES prüfen“
- Tabelle 203: TAB_KON_588 Fehlercodes TUC_KON_152 „Signaturvoraussetzungen für QES prüfen“
- Tabelle 204: TAB_KON_752 – TUC_KON_154 „QES Signaturen erstellen"
- Tabelle 205: TAB_KON_126 Fehlercodes TUC_KON_154 „QES Signaturen erstellen“
- Tabelle 206: TAB_KON_293 - TUC_KON_168 „Einzelsignatur QES erstellen“
- Tabelle 207: TAB_KON_590 Fehlercodes TUC_KON_168 „Einzelsignatur QES erstellen“
- Tabelle 208: TAB_KON_870 – TUC_KON_158 „Komfortsignaturen erstellen"
- Tabelle 209: TAB_KON_873 Fehlercodes TUC_KON_158 „Komfortsignaturen erstellen“
- Tabelle 210 : TAB_KON_892 – TUC_KON_159 „Signaturdatenelemente nachbereiten"
- Tabelle 211 : TAB_KON_893 Fehlercodes TUC_KON_159 „Signaturdatenelemente nachbereiten
- Tabelle 212: TAB_KON_753 – TUC_KON_160 „Dokumente nonQES signieren“
- Tabelle 213: TAB_KON_127 Fehlercodes TUC_KON_160 „Dokumente nonQES signieren“
- Tabelle 214: TAB_KON_121 - TUC_KON_161 „nonQES Dokumentsignatur prüfen“
- Tabelle 215: TAB_KON_124 Fehlercodes TUC_KON_161 „nonQES Dokumentensignatur prüfen“
- Tabelle 216: TAB_KON_754 Übersicht Status für Prüfung einer Dokumentensignatur
- Tabelle 217: TAB_KON_786 Übersicht unterstützte Zertifikatstyp-OIDs
- Tabelle 218: TAB_KON_430 – TUC_KON_162 „Kryptographische Prüfung der XML-Dokumentensignatur“
- Tabelle 219: TAB_KON_431 Fehlercodes TUC_KON_162 „Kryptographische Prüfung der XML-Dokumentensignatur“
- Tabelle 220: TAB_KON_755 – TUC_KON_150 „Dokumente QES signieren“
- Tabelle 221: TAB_KON_128 Fehlercodes TUC_KON_150 „Dokument QES signieren“
- Tabelle 222: TAB_KON_192 Verhalten des Konnektors beim Abbruch einer Stapelsignatur
- Tabelle 223: TAB_KON_591 - TUC_KON_151 „QES-Dokumentensignatur prüfen“
- Tabelle 224: TAB_KON_592 Fehlercodes TUC_KON_151 „QES Dokumentensignatur prüfen“
- Tabelle 225: TAB_KON_593 Übersicht Status für Prüfung einer Dokumentensignatur
- Tabelle 226: TAB_KON_871 – TUC_KON_170 „Dokumente mit Komfort signieren“
- Tabelle 227: TAB_KON_872 Fehlercodes TUC_KON_170 „Dokumente mit Komfort signieren“
- Tabelle 228: TAB_KON_883 – TUC_KON_171 „Komfortsignatur einschalten“
- Tabelle 229: TAB_KON_886 Fehlercodes TUC_KON_171 „Komfortsignatur einschalten“
- Tabelle 230: TAB_KON_884 – TUC_KON_172 „Komfortsignatur ausschalten“
- Tabelle 231: TAB_KON_887 Fehlercodes TUC_KON_172 „Komfortsignatur ausschalten“
- Tabelle 232: TAB_KON_885 – TUC_KON_173 „Liefere Signaturmodus“
- Tabelle 233: TAB_KON_888 Fehlercodes TUC_KON_173 „Liefere Signaturmodus“
- Tabelle 234: TAB_KON_197 Basisdienst Signaturdienst (nonQES und QES)
- Tabelle 235: TAB_KON_065 Operation SignDocument (nonQES und QES)
- Tabelle 236: TAB_KON_756 Ablauf Operation SignDocument (nonQES und QES)
- Tabelle 237: TAB_KON_757 Fehlercodes „SignDocument (nonQES und QES)“
- Tabelle 238: TAB_KON_066 Operation VerifyDocument (nonQES und QES)
- Tabelle 239: TAB_KON_760 Ablauf Operation VerifyDocument (nonQES und QES)
- Tabelle 240: TAB_KON_761 Fehlercodes „VerifyDocument (nonQES und QES)“
- Tabelle 241: TAB_KON_840 Operation StopSignature
- Tabelle 242: TAB_KON_841 Ablauf Operation StopSignature
- Tabelle 243: TAB_KON_842 Fehlercodes „StopSignature“
- Tabelle 244: TAB_KON_843 Operation GetJobNumber
- Tabelle 245: TAB_KON_844 Ablauf Operation GetJobNumber
- Tabelle 246: TAB_KON_845 Fehlercodes „GetJobNumber“
- Tabelle 247: TAB_KON_874 ActivateComfortSignature
- Tabelle 248: TAB_KON_877 Ablauf ActivateComfortSignature
- Tabelle 249: TAB_KON_879 Fehlercodes ActivateComfortSignature
- Tabelle 250: TAB_KON_875 DeactivateComfortSignature
- Tabelle 251: TAB_KON_878 Ablauf DeactivateComfortSignature
- Tabelle 252: TAB_KON_880 Fehlercodes DeactivateComfortSignature
- Tabelle 253: TAB_KON_876 GetSignatureMode
- Tabelle 254: TAB_KON_882 Ablauf GetSignatureMode
- Tabelle 255: TAB_KON_881 Fehlercodes GetSignatureMode
- Tabelle 256: TAB_KON_596 Konfigurationswerte des Signaturdienstes (Administrator)
- Tabelle 257: TAB_KON_853- intendedKeyUsage bei Zertifikatsprüfung
- Tabelle 258: TAB_KON_858 Kartenobjekt in Abhängigkeit vom kryptographischen Verfahren
- Tabelle 259: TAB_KON_825 Fehlercodes „TLS-Verbindungsaufbau zum TSL-Dienst“
- 260
- Tabelle 261: TAB_KON_597 Operationen in EVT_MONITOR_OPERATIONS
- Tabelle 262: TAB_KON_766 TUC_KON_032 „TSL aktualisieren“
- Tabelle 263: TAB_KON_598 Fehlercodes TUC_KON_032 „TSL aktualisieren“
- Tabelle 264: TAB_KON_618 TUC_KON_031 „BNetzA-VL aktualisieren“
- Tabelle 265: TAB_KON_619 Fehlercodes TUC_KON_031 „BNetzA-VL aktualisieren“
- Tabelle 266: TAB_KON_767 TUC_KON_040 „CRL aktualisieren“
- Tabelle 267: TAB_KON_599 Fehlercodes TUC_KON_040 „CRL aktualisieren“
- Tabelle 268: TAB_KON_768 TUC_KON_033 „Zertifikatsablauf prüfen“
- Tabelle 269: TAB_KON_600 Fehlercodes TUC_KON_033 „Zertifikatsablauf prüfen“
- Tabelle 270: TAB_KON_769 TUC_KON_037 „Zertifikat prüfen“
- Tabelle 271: TAB_KON_601 Fehlercodes TUC_KON_037 „Zertifikat prüfen“
- Tabelle 272: TAB_KON_818 TUC_KON_042 „CV-Zertifikat prüfen“
- Tabelle 273: TAB_KON_819 Fehlercodes TUC_KON_042 „CV-Zertifikat prüfen“
- Tabelle 274: TAB_KON_770 TUC_KON_034 „Zertifikatsinformationen extrahieren“
- Tabelle 275: TAB_KON_602 Fehlercodes TUC_KON_034 „Zertifikatsinformationen extrahieren“
- Tabelle 276: TAB_KON_771 Basisanwendung Zertifikatsdienst
- Tabelle 277: TAB_KON_676 Operation CheckCertificateExpiration
- Tabelle 278: TAB_KON_677 Ablauf CheckCertificateExpiration
- Tabelle 279: TAB_KON_603 Fehlercodes „CheckCertificateExpiration“
- Tabelle 280: TAB_KON_678 Operation ReadCardCertificate
- Tabelle 281: TAB_KON_679 Ablauf ReadCardCertificate
- Tabelle 282: TAB_KON_604 Fehlercodes „ReadCardCertificate“
- Tabelle 283: TAB_KON_795 Operation VerifyCertificate
- Tabelle 284: TAB_KON_797 Ablauf VerifyCertificate
- Tabelle 285: TAB_KON_800 Fehlercodes „VerifyCertificate“
- Tabelle 286: TAB_KON_772 TUC_KON_035 „Zertifikatsdienst initialisieren“
- Tabelle 287: TAB_KON_605 Fehlercodes TUC_KON_035 „Zertifikatsdienst initialisieren“
- Tabelle 288: TAB_KON_606 Konfiguration des Zertifikatsdienstes
- Tabelle 289: TAB_KON_733 Einsehbare Konfigurationsparameter des Zertifikatsdienstes
- Tabelle 290: TAB_KON_857 - Fehlercodes beim Import des Cross-Zertifikats für TI-Vertrauensanker ECC
- Tabelle 291: TAB_KON_607 – TUC_KON_271 „Schreibe Protokolleintrag“
- Tabelle 292: TAB_KON_608 Fehlercodes TUC_KON_271 „Schreibe Protokolleintrag“
- Tabelle 293: TAB_KON_609 Konfigurationswerte des Protokollierungsdienstes (Administrator)
- Tabelle 294: TAB_KON_610 – TUC_KON_272 „Initialisierung Protokollierungsdienst“
- Tabelle 295: TAB_KON_611 Fehlercodes TUC_KON_272 „Initialisiere Protokollierungsdienst“
- Tabelle 296: TAB_KON_773 – TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen“
- Tabelle 297: TAB_KON_612 Fehlercodes TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen“
- Tabelle 298: TAB_KON_774 - TUC_KON_111 „Kartenbasierte TLS-Verbindung abbauen“
- Tabelle 299: TAB_KON_613 Fehlercodes TUC_KON_111 „Kartenbasierte TLS-Verbindung abbauen“
- Tabelle 300: TAB_KON_805 - TUC_KON_290 „LDAP-Verbindung aufbauen“
- Tabelle 301: TAB_KON_815 – TUC_KON_291 „Verzeichnis abfragen“
- Tabelle 302: TAB_KON_816 – TUC_KON_292 „LDAP-Verbindung trennen"
- Tabelle 303: TAB_KON_817 – TUC_KON_293 „Verzeichnisabfrage abbrechen“
- Tabelle 304: TAB_KON_780 – Signaturverfahren Externe Authentisierung
- Tabelle 305: TAB_KON_839 Basisdienst Authentifizierungsdienst
- Tabelle 306: TAB_KON_781 Operation ExternalAuthenticate
- Tabelle 307: TAB_KON_782 Ablauf Operation ExternalAuthenticate
- Tabelle 308: TAB_KON_783 Übersicht Fehler Operation ExternalAuthenticate
- Tabelle 309: TAB_KON_784 Privater Schlüssel je Karte für ExternalAuthenticate
- Tabelle 310: TAB_KON_680 Mapping der Netzwerksegmente
- Tabelle 311: TAB_KON_681 Definition der vom Konnektor verwendeten VPN-Tunnel
- Tabelle 312: TAB_KON_682 Definition der Konnektor IP-Adressen
- Tabelle 313: TAB_KON_614 - TUC_KON_305 „LAN-Adapter initialisieren“
- Tabelle 314: TAB_KON_615 Fehlercodes TUC_KON_305 „LAN-Adapter initialisieren“
- Tabelle 315: TAB_KON_616 - TUC_KON_306 „WAN-Adapter initialisieren“
- Tabelle 316: TAB_KON_617 Fehlercodes TUC_KON_306 „WAN-Adapter initialisieren“
- Tabelle 317: TAB_KON_622 - TUC_KON_304 „Netzwerk-Routen einrichten“
- Tabelle 318: TAB_KON_623 Fehlercodes TUC_KON_304 „Netzwerk-Routen einrichten“
- Tabelle 319: TAB_KON_683 LAN-Adapter IP-Konfiguration
- Tabelle 320: TAB_KON_684 LAN-Adapter Erweiterte Parameter
- Tabelle 321: TAB_KON_685 WAN-Adapter IP-Konfiguration
- Tabelle 322: TAB_KON_686 WAN-Adapter Erweiterte Parameter
- Tabelle 323: TAB_KON_624 – „Konfigurationsparameter der Anbindung LAN/WAN“
- Tabelle 324: TAB_KON_625 - Konfigurationsparameter Firewall-Schnittstelle
- Tabelle 325: TAB_KON_626 „Liefere Netzwerkinformationen über DHCP“
- 326
- Tabelle 327: TAB_KON_628 „Basiskonfiguration des DHCP-Servers“
- Tabelle 328: TAB_KON_629 „Client-Gruppenspezifische Konfigurationsoptionen des Konnektor-DHCP-Servers“
- Tabelle 329: TAB_KON_630 - TUC_KON_343 „Initialisierung DHCP-Server“
- Tabelle 330: TAB_KON_631 Fehlercodes TUC_KON_343 „Initialisierung DHCP-Server“
- Tabelle 331: TAB_KON_632 – TUC_KON_341 „DHCP Informationen beziehen“
- Tabelle 332: TAB_KON_633 Fehlercodes TUC_KON_341 „DHCP-Informationen beziehen“
- Tabelle 333: TAB_KON_634 „Konfiguration des DHCP-Clients“
- Tabelle 334: TAB_KON_635 – TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen“
- Tabelle 335: TAB_KON_636 Fehlercodes TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen“
- Tabelle 336: TAB_KON_637 – TUC_KON_322 „Verbindung zu dem VPN-Konzentrator der SIS aufbauen“
- Tabelle 337: TAB_KON_638 Fehlercodes TUC_KON_322 „Verbindung zu dem VPN-Konzentrator der SIS aufbauen“
- Tabelle 338: TAB_KON_639 – Konfigurationsparameter VPN-Client
- Tabelle 339: TAB_KON_640 Zustandswerte für Konnektor NTP-Server
- Tabelle 340: TAB_KON_776 TUC_KON_351 „Liefere Systemzeit“
- Tabelle 341: TAB_KON_641 Fehlercodes TUC_KON_351 „Liefere Systemzeit“
- Tabelle 342: TAB_KON_642 Operation sync_Time
- Tabelle 343: TAB_KON_643 Konfiguration des Konnektor NTP-Servers
- Tabelle 344: TAB_KON_730 Einsehbare Konfigurationsparameter des Konnektor NTP-Servers
- Tabelle 345: TAB_KON_644 – TUC_KON_352 „Initialisierung Zeitdienst“
- Tabelle 346: TAB_KON_645 Fehlercodes TUC_KON_352 „Initialisierung Zeitdienst“
- Tabelle 347: TAB_KON_687 DNS-Forwards des DNS-Servers
- Tabelle 348: TAB_KON_646 – TUC_KON_361 „DNS-Namen auflösen“
- Tabelle 349: TAB_KON_647 Fehlercodes TUC_KON_361 „DNS Namen auflösen“
- Tabelle 350: TAB_KON_646 – TUC_KON_361 „DNS-Namen auflösen“
- Tabelle 351: TAB_KON_647 Fehlercodes TUC_KON_361 „DNS Namen auflösen“
- Tabelle 352: TAB_KON_648 – TUC_KON_362 „Liste der Dienste abrufen“
- Tabelle 353: TAB_KON_649 Fehlercodes TUC_KON_362 „Liste der Dienste abrufen“
- Tabelle 354: TAB_KON_650 - TUC_KON_363 „Dienstdetails abrufen“
- Tabelle 355: TAB_KON_651 Fehlercodes TUC_KON_363 „Dienstdetails abrufen“
- Tabelle 356: TAB_KON_652 Basisanwendung Namensdienst
- Tabelle 357: TAB_KON_653 Operation GetIPAddress
- Tabelle 358: TAB_KON_654 - Konfigurationsparameter Namensdienst
- Tabelle 359: TAB_KON_731 Einsehbare Konfigurationsparameter Namensdienst
- Tabelle 360: TAB_KON_655 Konfigurationen der Benutzerverwaltung (Super-Administrator)
- Tabelle 361: TAB_KON_656 Konfigurationen der Benutzerverwaltung
- Tabelle 362: TAB_KON_657 Konfigurationsparameter des Konnektornamens
- Tabelle 363: TAB_KON_833 Bezeichner für persistente Konfigurationsdaten für Fachmodule
- Tabelle 364: TAB_KON_658 Aktivieren/Deaktivieren von Leistungsumfängen
- Tabelle 365: TAB_KON_659 Konnektor Standalone einsetzen
- Tabelle 366: TAB_KON_661 Konfigurationsparameter der Konnektorfreischaltung
- Tabelle 367: TAB_KON_732 Einsehbare Konfigurationsparameter der Konnektorfreischaltung
- Tabelle 368: TAB_KON_662 Zustandswerte der Konnektorfreischaltung
- Tabelle 369: TAB_KON_932 – TUC_KON_411 „Konnektor mit neuem NK-Zertifikat registrieren“
- Tabelle 370: Tab_Kon_933 Fehlercodes TUC_KON_411 "Konnektor mit neuem NK-Zertifikat registrieren"
- Tabelle 371: TAB_KON_851 Einschränkung der Rechte des Remote-Administrators (Denylist)
- Tabelle 372: TAB_KON_663 Konfigurationen des Remote Managements
- Tabelle 373: TAB_KON_664 – TUC_KON_280 „Konnektoraktualisierung durchführen“
- Tabelle 374: TAB_KON_665 Fehlercodes TUC_KON_280 „Konnektoraktualisierung durchführen“
- Tabelle 375: TAB_KON_666 – TUC_KON_281 „Kartenterminalaktualisierung anstoßen“
- Tabelle 376: TAB_KON_667 Fehlercodes TUC_KON_281 „Kartenterminalaktualisierung anstoßen“
- Tabelle 377: TAB_KON_668 – TUC_KON_282 „UpdateInformationen beziehen“
- Tabelle 378: TAB_KON_669 Fehlercodes TUC_KON_282 „UpdateInformationen beziehen“
- Tabelle 379: TAB_KON_799 – TUC_KON_283 „Infrastruktur Konfiguration aktualisieren“
- Tabelle 380: Tab_Kon_726 Fehlercodes TUC_KON_283 „Infrastruktur Konfiguration aktualisieren“
- Tabelle 381: TAB_KON_833 – TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“
- Tabelle 382: TAB_KON_834 Fehlercodes TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“
- Tabelle 383: TAB_KON_835 – TUC_KON_286 „Paket für Fachmodul laden“
- Tabelle 384: TAB_KON_836 Fehlercodes TUC_KON_286 „Paket für Fachmodul laden“
- Tabelle 385: TAB_KON_864 – TUC_KON_284 „KSR-Client initialisieren“
- Tabelle 386: TAB_KON_822 Fehlercodes TUC_KON_284 „KSR-Client initialisieren“
- Tabelle 387: TAB_KON_670 Konfigurationsparameter der Software-Aktualisierung
- Tabelle 388: TAB_KON_820 Einsehbare Konfigurationsparameter der Software-Aktualisierung
- Tabelle 389: TAB_KON_671 Anforderungen Klima
- Tabelle 390: TAB_KON_672 Anforderungen Vibration
- Tabelle 391: TAB_KON_672 Anforderungen Vibration
- Tabelle 392: TAB_KON_779-01 „Profilierung der Signaturformate“
- Tabelle 393: TAB_KON_775 „Mindestanforderungen an Dimensionierung von Dokumenten und Nachrichten“
- Tabelle 394: TAB_KON_889 „Unerlaubte Inhalte in Dokumenten und Nachrichten“
- Tabelle 395: TAB_KON_777 Events Interne Mechanismen
- Tabelle 396: TAB_KON_711 Architektur der TI-Plattform, Berechtigt Fachmodule
- Tabelle 397: TAB_KON_712 Architektur der TI-Plattform, Berechtigt Clientsysteme
- Tabelle 398: TAB_KON_713 Architektur der TI-Plattform, Berechtigt eHealth-KT
- Tabelle 399: TAB_KON_714 Architektur der TI-Plattform, Berechtigt Administrator
- Tabelle 400: Aufzähltypen
5.5 Referenzierte Dokumente
5.5.1 Dokumente der gematik
Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert, Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument passende jeweils gültige Versionsnummer sind in der aktuellsten, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.
[Quelle] |
Herausgeber: Titel |
---|---|
[gemGlossar] |
gematik: Glossar |
[gemKPT_Arch_TIP] |
gematik: Konzept Architektur der TI-Plattform |
[gemKPT_Sich_Kon] |
gematik: Sicherheitskonzept Konnektor |
[gemKPT_Test] |
gematik: Testkonzept |
[gemSpec_COS] |
gematik: Spezifikation des Card Operating System (COS) – Elektrische Schnittstelle |
[gemSpec_Karten_Fach_TIP] |
gematik: Befüllvorschriften für die Plattformanteile der Karten der TI |
[gemSpec_eGK_ObjSys] |
gematik: Spezifikation der elektronischen Gesundheitskarte eGK-Objektsystem - für Karten der Generation 2 |
[gemSpec_eGK_ObjSys_G2.1] |
gematik: Spezifikation der elektronischen Gesundheitskarte eGK-Objektsystem - für Karten der Generation 2.1 |
[gemSpec_eGK_P1] |
gematik: Die Spezifikation der elektronische Gesundheitskarte; Teil 1 – Spezifikation der elektrischen Schnittstelle - für Karten der Generation 1+ |
[gemSpec_eGK_P2] |
gematik: Die Spezifikation der elektronische Gesundheitskarte; Teil 2 – Grundlegende Applikationen - für Karten der Generation 1+ |
[gemSpec_gSMC-K_ObjSys] |
gematik: Spezifikation der gSMC-K Objektsystem |
[gemSpec_gSMC-KT_ObjSys] |
gematik: Spezifikation gSMC-KT Objektsystem |
[gemSpec_HBA_ObjSys] |
gematik: Spezifikation HBA Objektsystem |
[gemSpec_Krypt] |
gematik: Übergreifende Spezifikation Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur |
[gemSpec_KSR] |
gematik: Spezifikation Konfigurationsdienst |
[gemSpec_KT] |
gematik: Spezifikation eHealth-Kartenterminal |
[gemSpec_Net] |
gematik: Spezifikation Netzwerk |
[gemSpec_OID] |
gematik: Spezifikation OID |
[gemSpec_OM] |
gematik: Übergreifende Spezifikation Operations und Maintenance |
[gemSpec_Perf] |
gematik: Performance und Mengengerüst TI-Plattform |
[gemSpec_PKI] |
gematik: Spezifikation PKI |
[gemSpec_SMC-B_ObjSys] |
gematik: Spezifikation SMC-B Objektsystem |
[gemSpec_VPN_ZugD] |
gematik: Spezifikation VPN-Zugangsdienst |
[gemSpec_VZD] |
gematik: Spezifikation Verzeichnisdienst |
[gemGitHub_tslSig] | https://github.com/gematik/examples-TelematikInterfaces/tree/master/tslService/detachedSignature |
5.5.2 Weitere Dokumente
[Quelle] |
Herausgeber (Erscheinungsdatum): Titel |
---|---|
[7816–4] |
ISO/IEC 7816-4: 2005 (2nd edition) Identification cards — Integrated circuit cards - Part 4: Organization, security and commands for interchange |
[ALGCAT] |
SOG-IS Crypto Evaluation Scheme - Agreed Cryptographic Mechanisms, Version 1.2, Januar 2020. |
[Basic Profile1.2] |
Basic Profile Version 1.2 http://www.ws-i.org/Profiles/BasicProfile-1.2-2010-11-09.html |
[Basic Profile2.0] |
Basic Profile Version 2.0 http://www.ws-i.org/Profiles/BasicProfile-2.0-2010-11-09.html |
[BSI-TR-03111] |
Technical Guideline BSI TR-03111 Elliptic Curve Cryptography, Version 2.10, Date: 2018-06-01 https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03111/BSI-TR-03111_V-2-1_pdf.pdf?__blob=publicationFile&v=2 |
[BSI-TR03114] |
BSI (22.10.2007): Technische Richtlinie – Stapelsignatur mit dem Heilberufsausweis; Version 2.0 https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/ Publikationen/TechnischeRichtlinien/TR03114/BSI-TR-03114.pdf? __blob=publicationFile&v=1 |
[BSI TR-03120] |
BSI (23.10.2007): BSI - Technische Richtlinie – Sichere Kartenterminalidentität (Betriebskonzept); Version 1.0 https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/ Publikationen/TechnischeRichtlinien/TR03120/BSI-TR-03120.pdf? __blob=publicationFile&v=1 |
[CAdES] |
ETSI: Electronic Signature Formats, Electronic Signatures and Infrastructures (ESI) – Technical Specification, ETSI TS 101 733 V2.2.1, via http://www.etsi.org |
[Canon XML1.1] |
Canonical XML Version 1.1 http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/ |
[CDA] |
ISO/HL7 27932:2009 Data Exchange Standards -- HL7 Clinical Document Architecture, Release 2 |
[CDA-Sig] |
Erstellung von XML-Signaturen für Dokumente nach Clinical Documents Architecture – R2, Elektronische Signatur von Arztbriefen, Ärztekammern in NRW im Auftrag der Bundesärztekammer, Version 1.6 vom 19.04.2010 |
[COMMON_PKI] |
Common PKI Specifications for Interoperable Applications Version 2.0, 20 January 2009 http://www.t7ev.org/themen/entwickler/common-pki-v20-spezifikation.html ISIS-MTT Core Specification, 2004, Version 1.1 https://www.teletrust.de/fileadmin/files/ ISIS-MTT_Profile_SigGOptions_v1.1.pdf |
[CMS] |
Cryptographic Message Syntax (CMS), September 2009 https://datatracker.ietf.org/doc/html/rfc5652 |
[DIN 66003] |
DIN 66003:1999 Informationsverarbeitung; 7-Bit-Code |
[HPC-P1] |
Spezifikation des elektronischen Heilberufsausweises Version 2.3.2, 05.08.2009, Teil I: Kommandos, Algorithmen und Funktionen der COS Plattform |
[HPC-P2] |
Spezifikation des elektronischen Heilberufsausweises Version 2.3.2, 05.08.2009, Teil II: HPC - Anwendungen und Funktionen |
[HPC-P3] |
Spezifikation des elektronischen Heilberufsausweises Version 2.3.2, 05.08.2009, Teil III: SMC - Anwendungen und Funktionen |
[HüKo06] |
BSI (2006): Hühnlein, Detlef/Korte, Ulrike:Grundlagen der elektronischen Signatur |
[IEEE 802.3] |
Technical Committee Computer Communications of the IEEE Computer Society, USA (1985): IEEE standards for local area networks: carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications ISBN: 0-7381-4253-0 |
[ISO 8601] |
International Organization for Standardization (2006-09): Data elements and interchange formats -- Information interchange -- Representation of dates and times |
[KVK] |
Spitzenverbände der Krankenkassen, Kassenärztliche Bundesvereinigung und Kassenzahnärztlichen Bundesvereinigung (gültig ab 25. November 2009): Technische Spezifikation der Versichertenkarte Version: 2.08 |
[MIME] |
RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049 |
[NTPv4] |
Internet Engineering Task Force (IETF) (06/2010): Network Time Protocol Version 4: Protocol and Algorithms Specification https://datatracker.ietf.org/doc/html/rfc5905 |
[OASIS- AdES] |
OASIS: Advanced Electronic Signature Profiles of the OASIS Digital Signature Service Version 1.0, OASIS Standard, http://docs.oasis-open.org/dss/v1.0/oasis-dss-profiles-AdES-spec-v1.0-os.pdf |
[OASIS-DSS] |
OASIS: Digital Signature Service Core Protocols, Elements, and Bindings, Version 1.0, OASIS Standard, via http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.pdf |
[OASIS-SP] |
OASIS: Signature Policy Profile of the OASIS Digital Signature Services Version 1.0, Committee Draft 01, 18 May 2009, http://docs.oasis-open.org/dss-x/profiles/sigpolicy/oasis-dssx-1.0-profiles-sigpolicy-cd01.pdf |
[OASIS-VR] |
OASIS: Profile for comprehensive multi-signature verification reports for OASIS Digital Signature Services Version 1.0, Committee Specification 01, 12 November 2010, http://docs.oasis-open.org/dss-x/profiles/verificationreport/oasis-dssx-1.0-profiles-vr-cs01.pdf |
[PAdES-1] |
European Telecommunications Standards Institute (ETSI): Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles; Part 1: PAdES Overview – a framework document for PAdES, ETSI TS 102 778-1 V1.1.1, Technical Specification, 2009 |
[PAdES-3] |
European Telecommunications Standards Institute (ETSI): Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles; Part 3: PAdES Enhanced – PAdES-BES and PAdES-EPES Profiles, ETSI TS 102 778-3 V1.1.2, Technical Specification, 2009 |
[PAdES-4] |
European Telecommunications Standards Institute (ETSI): Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles; Part 4: PAdES Long Term – PAdES-LTV Profile, ETSI TS 102 778-4 V1.1.2, Technical Specification, 2009 |
[ISO 19005] |
ISO 19005 – Document management – Electronic document file format for long-term preservation |
[PDF/A-2] |
ISO 19005-2:2011 – Document management – Electronic document file format for long-term preservation – Part 2: Use of ISO 32000-1 (PDF/A-2) |
[PP_NK] |
Common Criteria Schutzprofil (Protection Profile) Schutzprofil 1: Anforderungen an den Netzkonnektor BSI-CC-PP-0097 |
[PP_KON] |
Common Criteria Schutzprofil (Protection Profile) Schutzprofil 2: Anforderungen an den Konnektor: BSI-CC-PP-0098 |
[RFC792] |
IETF (September 1981) INTERNET CONTROL MESSAGE PROTOCOL https://datatracker.ietf.org/doc/html/rfc792 |
[RFC1034] |
RFC 1034 (November 1987): Domain Names – Concepts and Facilities https://datatracker.ietf.org/doc/html/rfc1034 |
[RFC1122] |
RFC 1122 (Oktober 1989): Requirements for Internet Hosts -- Communication Layers https://datatracker.ietf.org/doc/html/rfc1122 |
[RFC1812] |
F. Baker (ed.): Requirements for IP Version 4 Routers, IETF RFC 1812 https://datatracker.ietf.org/doc/html/rfc1812 |
[RFC1918] |
RFC1918 (Februar 1996): Address Allocation for Private Internets https://datatracker.ietf.org/doc/html/rfc1918 |
[RFC2119] |
RFC 2119 (März 1997): Key words for use in RFCs to Indicate Requirement Levels S. Bradner https://datatracker.ietf.org/doc/html/rfc2119 |
[RFC2131] |
Network Working Group (03/1997): Dynamic Host Configuration Protocol https://datatracker.ietf.org/doc/html/rfc2131 |
[RFC2132] |
Network Working Group (03/1997): DHCP Options and BOOTP Vendor Extensions https://datatracker.ietf.org/doc/html/rfc2132 |
[RFC2616] |
Network Working Group (06/1999): Hypertext Transfer Protocol -- HTTP/1.1 https://datatracker.ietf.org/doc/html/rfc2616 |
[RFC2617] |
Network Working Group (06/1999): HTTP Authentication: Basic and Digest Access Authentication https://datatracker.ietf.org/doc/html/rfc2617 |
[RFC2644] |
D. Senie: Changing the Default for Directed Broadcasts in Routers, IETF RFC 2644, https://datatracker.ietf.org/doc/html/rfc2644 |
[RFC2663] |
P. Srisuresh, M. Holdrege: IP Network Address Translator (NAT) Terminology and Considerations, IETF RFC 2663, https://datatracker.ietf.org/doc/html/rfc2663 |
[RFC2818] |
Network Working Group (05/2000): HTTP Over TLS https://datatracker.ietf.org/doc/html/rfc2818 |
[RFC3022] |
RFC 3022 (Januar 2001): Traditional IP Network Address Translator (Traditional NAT) https://datatracker.ietf.org/doc/html/rfc3022 |
[RFC3275] |
D. Eastlage, J. Reagle, D. Solo: (Extensible Markup Language) XMLSignature Syntax and Processing, IETF RFC 3275, https://datatracker.ietf.org/doc/html/rfc3275 |
[RFC3279] |
W, Polk, R. Hously, L. Bassham: Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, IETF RFC 3279, https://datatracker.ietf.org/doc/html/rfc3279 |
[RFC3447] |
B. Kaliski:_PKCS #1: RSA Encryption, Version 2.1 https://datatracker.ietf.org/doc/html/rfc3447 |
[RFC3629] |
Network Working Group (11/2003): UTF-8, a transformation format of ISO 10646 https://datatracker.ietf.org/doc/html/rfc3629 |
[RFC3927] |
Network Working Group (05/2005): Dynamic Configuration of IPv4 Link-Local Addresses https://datatracker.ietf.org/doc/html/rfc3927 |
[RFC3986] |
Network Working Group (01/2005): Uniform Resource Identifier (URI): Generic Syntax |
[RFC4122] |
RFC 4122 (July 2005): A Universelly Unique Identifier UUID URN Namspace https://datatracker.ietf.org/doc/html/rfc4122 |
[RFC4511] | RFC 4511 (June 2006): Lightweight Directory Access Protocol (LDAP): The Protocol https://datatracker.ietf.org/doc/html/rfc4511 |
[RFC4632] |
Network Working Group (08/2006): Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan https://datatracker.ietf.org/doc/html/rfc4632 |
[RFC5246] |
RFC 5246 (August 2008): The Transport Layer Security (TLS) Protocol Version 1.2; https://datatracker.ietf.org/doc/html/rfc5246 |
[RFC5652] |
R. Housley: Cryptographic Message Syntax (CMS), RFC 5652 (September 2009) https://datatracker.ietf.org/doc/html/rfc5652 |
[RFC 6598] |
RFC 6598 (April 2012): IANA-Reserved IPv4 Prefix for Shared Address Space https://datatracker.ietf.org/doc/html/rfc6598 |
[RFC6931] |
RFC 6931 (April 2013): Additional XML Security Uniform Resource Identifiers (URIs) https://datatracker.ietf.org/doc/html/rfc6931 |
[RFC7159] |
RFC 7159 (March 2014): The JavaScript Object Notation (JSON) Data Interchange Format https://datatracker.ietf.org/doc/html/rfc7159 |
[S/MIME] |
RFC 5751 (Januar 2010): Secure/Multipurpose Internet Mail Extensions (S/MIME), Version 3.2, Message Specification https://datatracker.ietf.org/doc/html/rfc5751 |
[SOAP1.1] |
Simple Object Access Protocol (SOAP) 1.1 W3C Note (08 May 2000) https://www.w3.org/TR/2000/NOTE-SOAP-20000508/ |
[SOAP1.2] |
SOAP Version 1.2 Part 1: Messaging Framework (Second Edition) W3C Recommendation (27 April 2007) http://www.w3.org/TR/2007/REC-soap12-part1-20070427/ |
[SICCT] |
TeleTrusT (17.12.2010): SICCT Secure Interoperable ChipCard Terminal, Version 1.21 https://www.teletrust.de/fileadmin/docs/projekte/sicct/SICCT-Spezifikation-1.21.pdf |
[TIFF6] |
TIFF Revision 6.0 (Final, June 3, 1992) https://www.adobe.io/open/standards/TIFF/_jcr_content/ contentbody/download/file.res/TIFF6.pdf.html |
[WSDL1.1] |
W3C Note (15.03.2001): Web Services Description Language (WSDL) 1.1 http://www.w3.org/TR/wsdl |
[XAdES] |
European Telecommunications Standards Institute (ETSI): Technical Specication XML Advanced Electronic Signatures (XAdES). ETSI Technical Specication TS 101 903, Version 1.4.2, 2010 |
[XMLDSig] |
W3C Recommendation (06.2008): XML-Signature Syntax and Processing http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/ |
[XMLEnc] |
XML Encryption Syntax and Processing W3C Recommendation 11 April 2013 http://www.w3.org/TR/xmlenc-core1/ |
[XPATH] |
W3C Recommendation (14 December 2010) XML Path Language (XPath) 2.0 (Second Edition) http://www.w3.org/TR/2010/REC-xpath20-20101214/ |
[XSLT] |
W3C Recommendation (23 January 2007) XSL Transformations (XSLT) Version 2.0 http://www.w3.org/TR/2007/REC-xslt20-20070123/ |
[XAdES Baseline Profile] |
European Telecommunications Standards Institute (ETSI): Electronic Signatures and Infrastructure (ESI); XAdES Baseline Profile; ETSI Technical Specification TS 103 171, Version 2.1.1, 2012-03 |
[CAdES Baseline Profile] |
European Telecommunications Standards Institute (ETSI): Electronic Signatures and Infrastructure (ESI); CAdES Baseline Profile; ETSI Technical Specification TS 103 173, Version 2.1.1, 2013-04 |
[PAdES Baseline Profile] |
European Telecommunications Standards Institute (ETSI): Electronic Signatures and Infrastructure (ESI); PAdES Baseline Profile; ETSI Technical Specification TS 103 172, Version 2.2.2, (2013-04) |
[XSL] |
W3C Recommendation (05.12.2006): Extensible Stylesheet language (XSL) Version1.1 http://www.w3.org/TR/2006/REC-xsl11-20061205/ |
[MTOM] |
SOAP Message Transmission Optimization Mechanism W3C Recommendation 25 January 2005 http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/ |
[MTOM-SOAP1.1] |
W3C Member Submission 05 April 2006 SOAP 1.1 Binding for MTOM 1.0 https://www.w3.org/Submission/soap11mtom10/ |
[WS-MTOM Policy] |
W3C Member Submission 18 November 2007 MTOM Serialization Policy Assertion 1.1 |
[COS-G2] |
Common Criteria Protection Profile, Card Operating System Generation 2, (PP COS G2), BSI-CC-PP-0082-V2 |
6 Anhang B – Profilierung der Signatur- und Verschlüsselungsformate (normativ)
6.1 Profilierung der Verschlüsselungsformate
6.2 Profilierung der Signaturformate
Tabelle 392: TAB_KON_779-01 „Profilierung der Signaturformate“
Aspekt (QES/nonQES) |
Festlegung (XML-Signatur/CMS-Signatur/PDF-Signatur) |
---|---|
Zertifikatsreferenz (QES und nonQES) |
XML-Signatur Bei der Signaturerstellung ist das XML-Element SigningCertificate gemäß den Vorgaben aus XAdES Kapitel 7.2.2 „The SigningCertificate element“ anzulegen. Bei der Signaturprüfung ist es gemäß XAdES Kapitel G.2.2.5 „Verification technical rules” [XAdES] zu prüfen. Grundsätzlich sind auch Signaturen zu prüfen, die keine Zertifikatsreferenz enthalten. Das Prüfergebnis muss dann widerspiegeln, dass diese Sicherheitsfunktion nicht enthalten war. CMS-Signatur Bei der Signaturerstellung ist das Attribut signing certificate reference gemäß CAdES Kapitel 5.7.3 „Signing Certificate Reference Attributes“ [CAdES] anzulegen. Bei der Signaturprüfung ist es gemäß CAdES Kapitel 5.6.3 „Message signature verification process“ [CAdES] zu prüfen. Grundsätzlich sind auch Signaturen zu prüfen, die keine Zertifikatsreferenz enthalten. Das Prüfergebnis muss dann widerspiegeln, dass diese Sicherheitsfunktion nicht enthalten war. PDF-Signatur Bei der Signaturerstellung ist das Attribut signing certificate reference gemäß den Vorgaben aus [PAdES-3] Kapitel 4.4.3 „Signing Certificate Reference Attribute“ anzulegen. Bei der Signaturprüfung ist es gemäß [PAdES-3]Kapitel 4.6.1 „Signing Certificate Reference Validation“ zu prüfen. Grundsätzlich sind auch Signaturen zu prüfen, die keine Zertifikatsreferenz enthalten. Das Prüfergebnis muss dann widerspiegeln, dass diese Sicherheitsfunktion nicht enthalten war. |
Signaturablage | PDF-Signatur Sie Signatur wird als Incremental Update gemäß [PDF/A-2] Kapitel 7.5.6 an das Dokument angefügt. |
Parallelsignatur (QES und nonQES) |
XML-Signatur Parallele Signaturen werden durch je ein ds:signature-Element pro Signatur abgebildet. Für die Signaturvariante „enveloping“ werden parallele Signaturen nicht angeboten. CMS-Signatur: Parallele Signaturen werden durch je einen SignerInfo-Container pro Signatur realisiert. PDF-Signatur: Parallele Signaturen werden nicht angeboten. |
Dokumentexkludierende Gegensignatur (QES und nonQES) |
XML-Signatur Die Implementierung erfolgt mittels Countersignature gemäß [XAdES], Kapitel 7.2.4. Jede vorhandene Parallel-Signatur wird gegensigniert. CMS-Signatur: Die Implementierung erfolgt mittels der Countersignature gemäß CMS-Spezifikation [RFC5652]. Jede vorhandene Parallel-Signatur wird gegensigniert. PDF-Signatur: Dokumentexkludierende Gegensignaturen werden nicht angeboten. |
Referenzierung (QES und nonQES) |
XML-Signatur Bei der Signaturerzeugung verwendet der Konnektor in der Signatur nur ID-basierte Referenzen. Bei der Signaturprüfung reagiert der Konnektor bei Abweichungen hiervon mit Fehler 4208. |
XML-Signatur / CMS-Signatur Bei XML-Dokumenten und XML-Signaturen kann die Referenzierung von Objekten auf zwei Arten erfolgen: – Ist kein XML-Schema vorhanden, so werden die Werte des ID-Attributs des referenzierten Elements verwendet. – Wird ein XML-Schema übergeben, so muss dieses die ID-Attribute zur Referenzierung festlegen. Bei Abweichungen reagiert der Konnektor mit Fehlercode 4115. |
|
Anzahl unterstützter Signaturen (QES und nonQES) |
XML-Signatur / CMS-Signatur / PDF-Signatur Es müssen mindestens 20 Signaturen pro Dokument unterstützt werden. Sind mehr als die unterstützte Anzahl von Signaturen in einem Dokument enthalten, wird die Operation mit Fehler 4280 abgebrochen. |
6.3 Profilierung VerificationReport
Anforderung eines ausführlichen Prüfberichts
Folgende Aufrufparameter müssen unterstützt werden:
<ReturnVerificationReport
xmlns="urn:oasis:names:tc:dss-x:1.0:profiles:verificationreport:schema#" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation="urn:oasis:names:tc:dss-x:1.0:profiles:verificationreport:schema#
oasis-dssx-1.0-profiles-vr-cd1.xsd">
<IncludeVerifier>false</IncludeVerifier>
<IncludeCertificateValues>true</IncludeCertificateValues>
<IncludeRevocationValues>true</IncludeRevocationValues>
<ExpandBinaryValues>false</ExpandBinaryValues>
<ReportDetailLevel>
urn:oasis:names:tc:dss-x:1.0:profiles:verificationreport:reportdetail:allDetails
</ReportDetailLevel>
</ReturnVerificationReport>
Verwendung des erzeugten VerificationReport
Für die folgenden Inhalte müssen die angegebenen Strukturen benutzt werden. Im Standard angegebene Pflichtfelder von erzeugten Strukturen müssen ggf. zusätzlich gefüllt werden:
- Prüfzeitpunkt (Systemzeit des Konnektors zum Zeitpunkt der Prüfung)
/VerificationReport/
dss:VerificationTimeInfo/
dss:VerificationTime
- Signaturzeitpunkt(Ermittelter_Signaturzeitpunkt_Eingebettet)
/VerificationReport/
IndividualReport/
SignedObjectIdentifier/
SignedProperties/
SignedSignatureProperties/
XAdES:SigningTime
Die Signierzeit SigningTime ist nicht nur für XAdES-Signaturen, sondern allgemein für Signaturen gemäß AdES-Baseline-Profilierung, also auch für CAdES und PAdES zu füllen.
- Angenommener Signaturzeitpunkt gemäß TIP1-A_5540-* (QES) und TIP1-A_5545 (nonQES)
/VerificationReport/
IndividualReport/
Details/
dss:VerificationTimeInfo/
dss:VerificationTime
- der binäre Wert der Signatur
/VerificationReport/
IndividualReport/
SignedObjectIdentifier/
SignatureValue
- Kurztext
Der signierte Kurztext wird in folgendem XML-Element zurückgegeben:
/VerificationReport/
IndividualReport/
SignedObjectIdentifier/
SignedProperties/
Other/
SIG:ShortText
Die ungültigen Zeichen müssen aus dem ShortText entfern werden und der ShortText wird gekürzt, wenn er nicht den Längenvorgaben des Schemas entspricht.
- Das folgende Element mit den Werten true/false gibt an, ob eine Zertifikatsreferenz gemäß Anhang B2 vorhanden ist (true) oder nicht (false):
/VerificationReport/
IndividualReport/
SignedObjectIdentifier/
SignedProperties/
Other/
SIG:ReferenceToSignerCertificate
- Sämtliche signierte Attribute, deren Rückgabe nicht explizit über andere Elemente geregelt ist, werden als direkt anzeigbare Key/Value-Paare zurückgeben. Dabei sind sowohl Key und Value bereits für die Anzeige formatiert. Der Key wird in einer Zeile dargestellt. Der Value wird in mehreren Zeilen dargestellt, wobei ein Zeilenumbruch durch 'CARRIAGE RETURN (CR)' 'LINE FEED (LF)' erzeugt wird und keine weiteren Steuerzeichen erlaubt sind.
/VerificationReport/
IndividualReport/
SignedObjectIdentifier/
SignedProperties/
Other/
SIG:DisplayableAttributes
- das Ergebnis der Signaturprüfung
/VerificationReport/
IndividualReport/
Result
- handelt es sich bei der Signatur um eine Gegensignatur wird diese als solche markiert
/DetailedSignatureReport/
Properties/
UnsignedProperties/
Other/
SIG:CounterSignatureMarker
und mit
/DetailedSignatureReport/
Properties/
UnsignedProperties/
Other/
SIG:CounterSignatureMarker/
SignatureValueReference/
@IdRef
auf jede (eine oder mehrere) gegensignierte Signaturen verwiesen. Dabei zeigt IdRef auf den jeweiligen gegensignierten Signaturwert
/VerificationReport/
IndividualReport/
SignedObjectIdentifier/
ds:SignatureValue/
@Id
- das Ergebnis der Zertifikatsprüfung,
/VerificationReport/
IndividualReport/
Details/
DetailedSignatureReport/
CertificatePathValidity/
PathValiditySummary/
ResultMajor
- Inhalt des Zertifikates, auf dem beruhend signiert wurde
/VerificationReport/
IndividualReport/
Details/
DetailedSignatureReport/
CertificatePathValidity/
PathValidityDetail/
CertificateValidity/
CertificateValue
- den Signaturalgorithmus der Dokumentensignatur (URI, angelehnt an den Wertebereich des Feldes ds:SignatureMethod),
/VerificationReport/
IndividualReport/
Details/
DetailedSignatureReport/
SignatureOK/
SignatureAlgorithm
- aussagekräftiger Hinweis zum verminderten Beweiswert hinsichtlich Authentizität und Integrität der Signatur, wenn einer der bei der Signaturprüfung identifizierten und unterstützten Algorithmen zum Zeitpunkt der Signaturprüfung nicht mehr laut Algorithmenkatalog [ALGCAT] als geeignet eingestuft wird. Auszuwerten sind die Festlegungen des ALGCAT sowohl bezogen auf die Vergangenheit als auch auf die Zukunft.
Für alle geprüften Zertifikate:
../
vr:CertificateValidity/
vr:SignatureOK/
vr:SignatureAlgorithm/
vr:Suitability/
./ResultMajor= urn:oasis:names:tc:dss:1.0:detail:invalid
./ResultMessage=“Algorithmen seit <Jahr> als unsicher eingestuft“
- PathValidity bis zur TrustAnchor-TSL
//CertificateValidity/ChainingOK/ResultMajor (ab dem zweiten Zertifikat in der Kette)
//CertificateValidity/CertificateStatus/CertStatusOK/ResultMajor
//CertificateValidity/CertificateValue
Für das Feld TrustAnchor ist
“urn:oasis:names:tc:dss-x:1.0:profiles:verificationreport:trustanchor:certDataBase”
zu verwenden.
- Prüfergebnis des Gültigkeitszeitraums
/VerificationReport/
IndividualReport/
Details/
DetailedSignatureReport/
CertificatePathValidity/
PathValidityDetail/
CertificateValidity/
ValidityPeriodOK/
ResultMajor
- Prüfung der Extensions
/VerificationReport/
IndividualReport/
Details/
DetailedSignatureReport/
CertificatePathValidity/
PathValidityDetail/
CertificateValidity/
ExtensionsOK/
ResultMajor
- Zeitstempel und Herkunft der OCSP-Antwort für das Signaturzertifikat
/VerificationReport/
IndividualReport/
Details/
DetailedSignatureReport/
CertificatePathValidity/
PathValidityDetail/
CertificateValidity/
CertificateStatus/
RevocationEvidence/
OCSPValidity/
OCSPIdentifier/
./XAdES:ResponderID/XAdES:ByName
./XAdES:ProducedAt
- OCSP Antwort für das Signaturzertifikats
/VerificationReport/
IndividualReport/
Details/
/vr:DetailedSignatureReport/
vr:CertificatePathValidity/
vr:PathValidityDetail/
vr:CertificateValidity/
vr:CertificateStatus/
vr:RevocationEvidence/
vr:OCSPValidity/
vr:OCSPValue
Sonderfälle:
Dokument mit parallelen Signaturen
Für jede Signatur wird ein IndividualReport erzeugt.
Dokument mit Signatur und Gegensignatur
Für jede Signatur wird ein IndividualReport erzeugt.
6.4 Profilierung der Dokumentenformate und Nachrichten
Tabelle 393: TAB_KON_775 „Mindestanforderungen an Dimensionierung von Dokumenten und Nachrichten“
Dokument / Nachricht | Mindestanforderung |
---|---|
XML-Dokument | Hierarchietiefe des Dokumentenbaums: 30 Ebenen |
Anzahl von XML-Elementen im Dokument: 30.000 | |
Anzahl von XML-Attributen je XML-Element: 20 | |
Anzahl von direkten Kindern eines XML-Elements: 50 | |
Länge von XML-Bezeichnern (z. B. Elementnamen, Attributnamen, Namespace-Präfixes, usw.): 200 | |
Gesamtanzahl von Transformationen im Dokument: 64 | |
Anzahl von Transformationen pro Reference-Element: 10 | |
Element-Größe pro Einzelknoten im Base64-codierten Dokument: 30 MB |
Tabelle 394: TAB_KON_889 „Unerlaubte Inhalte in Dokumenten und Nachrichten“
Dokument / Nachricht | Unerlaubte Inhalte |
---|---|
XML-Dokument | Es dürfen keine ENTITY-Deklarationen im XML-Dokument vorkommen. |
Zu verifizierende XML-Dokumente dürfen im <Transforms>-Teil ihrer Referenzen weder XPath-Ausdrücke noch XSL-Transformationen enthalten. | |
Bei Referenzen (ReferenceType) darf das optionale URI-Attribut keine "xpointer()"-Ausdrücke enthalten. | |
XInclude-Mechanismen dürfen nicht verwendet werden. Elemente aus dem Namensraum http://www.w3.org/2001/XInclude dürfen in XML-Dokumenten nicht enthalten sein. | |
7 Anhang F – Übersicht Events
Tabelle 395: TAB_KON_777 Events Interne Mechanismen
Topic Ebene1 /Topic Ebene2 /Topic Ebene3 |
Typ |
Schw ere |
Pr ot |
An Cli en ts |
Parameter |
Bedeutung |
Auslöser (TUC/Op) |
---|---|---|---|---|---|---|---|
Interne Mechanismen |
|||||||
BOOTUP /BOOTUP_COMPLETE |
Op |
Info |
x |
x |
Änderung des Betriebszustandes |
||
OPERATIONAL_STATE /EC_CardTerminal_Software_Out_Of_Date ($ctId) |
Op |
Info |
x |
x |
Value=true/ false; CtID=$ctId; Bedeutung= $EC.description |
Änderung des Betriebszustandes durch Änderung im Fehlerzustand (Änderung im Value). |
|
OPERATIONAL_STATE /EC_CardTerminal_gSMC-KT_Certificate_Expires_Soon($ctId) |
Op | Info | x | x | Value=true/ false; CtID=$ctId; Bedeutung= $EC.description |
Änderung des Betriebszustandes durch Änderung im Fehlerzustand (Änderung im Value). |
TUC_KON_050 |
OPERATIONAL_STATE /EC_Connector_Software_Out_Of_Date |
Op |
Info |
x |
x |
Value=true/ false; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_FW_Not_Valid_Status_Blocked |
Sec |
Fatal |
x |
x |
Value=true/ false; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_Time_Sync_Not_Successful |
Op |
Info |
x |
x |
Value=true/ false; LastSyncAttempt= $lastSyncAttempt Timestamp; LastSyncSuccess= $lastSyncSuccess Timestamp; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_TSL_Update_Not_Successful |
Op |
Info |
x |
x |
Value=true/ false; Bedeutung= $EC.description; LastUpdateTSL= $lastUpdate TSLTimestamp |
" |
|
OPERATIONAL_STATE /EC_TSL_Expiring |
Sec |
Info |
x |
x |
Value=true/ false; NextUpdateTSL= $NextUpdate- Element der TSL; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_TSL_Trust_Anchor_Expiring |
Sec |
Info |
x |
x |
Value=true/ false; ExpiringDate TrustAnchor= Ablaufdatum der Vertrauens ankergültigkeit; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_LOG_OVERFLOW |
Op |
Warning |
x |
x |
Value=true/ false; Protokoll=$Protokoll; Bedeutung= $EC.description |
" |
TUC_KON_271 |
OPERATIONAL_STATE /EC_CRL_Expiring |
Sec |
Warning |
x |
x |
Value=true/ false; NextUpdateTSL= $NextUpdate- Element der TSL; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_Time_Sync_Pending_Warning |
Sec |
Warning |
x |
x |
Value=true/ false; LastSyncSuccess= $lastSyncSuccess Timestamp; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_TSL_Out_Of_Date_Within_Grace_Period |
Sec |
Warning |
x |
x |
Value=true/ false; NextUpdateTSL= $NextUpdate- Element der TSL; GracePeriodTSL= CERT_TSL_ DEFAULT_GRACE_ PERIOD_DAYS; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_CardTerminal_Not_Available($ctId) |
Op |
Error |
x |
x |
Value=true/ false; CtID=$ctId; Bedeutung =$EC.description |
" |
|
OPERATIONAL_STATE /EC_No_VPN_TI_Connection |
Op |
Error |
x |
x |
Value=true/ false; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_No_VPN_SIS_Connection |
Op |
Error |
x |
x |
Value=true/ false; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_No_Online_Connection |
Op |
Error |
x |
x |
Value=true/ false; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_IP_Adresses_Not_Available |
Sec |
Error |
x |
x |
Value=true/ false; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_CRL_Out_Of_Date |
Sec |
Fatal |
x |
x |
Value=true/ false; NextUpdateCRL= $NextUpdate der CRL; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_Firewall_Not_Reliable |
Sec |
Fatal |
x |
x |
Value=true/ false; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_Random_Generator_Not_Reliable |
Sec |
Fatal |
x |
x |
Value=true/ false; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_Secure_KeyStore_Not_Available |
Sec |
Fatal |
x |
x |
Value=true/ false; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_Security_Log_Not_Writable |
Op |
Fatal |
x |
x |
Value=true/ false; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_Software_Integrity_Check_Failed |
Sec |
Fatal |
x |
x |
Value=true/ false; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_Time_Difference_Intolerable |
Sec |
Fatal |
x |
x |
Value=true/ false; Bedeutung= $EC.description; NtpTimedifference= Zeitabweichung; NtpMaxAllowedTime difference= NTP_MAX_TIMEDIF FERENCE; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_Time_Sync_Pending_Critical |
Sec |
Fatal |
x |
x |
Value=true/ false; LastSyncSuccess= $lastSyncSuccess Timestamp; NtpGracePeriod= NTP_GRACE_PERIOD; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_TSL_Trust_Anchor_Out_Of_Date |
Sec |
Fatal |
x |
x |
Value=true/ false; ExpiringDate TrustAnchor= Ablaufdatum der Vertrauensanker gültigkeit; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_TSL_Out_Of_Date_Beyond_Grace_Period |
Sec |
Fatal |
x |
x |
Value=true/ false; Next UpdateTSL= $NextUpdate-Element der TSL; GracePeriodTSL= CERT_TSL_ DEFAULT_ GRACE_PERIOD_DAYS; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_CRYPTOPERATION_ALARM |
Sec |
Warning |
x |
x |
Value=true/ false; Operation= $Operationsname; Count=$Summenwert; Arbeitsplatz =$<Liste operations-aufrufenden workplace IDs>; Meldung=’ Auffällige Häufung von Operationsaufrufen in den letzten 10 Minuten’ |
" |
|
OPERATIONAL_STATE /EC_OTHER_ERROR_STATE($no) |
$Type |
$Seve rity |
x |
x |
Value=true/ false; Bedeutung= $EC.description |
" |
|
OPERATIONAL_STATE /EC_BNetzA_VL_Update_Not_Successful |
Op |
Info |
x |
x |
Value=true/ false; LastUpdate BNetzAVL= $lastUpdateBNetzAVL Timestamp; Bedeutung= $EC.description; |
" |
|
OPERATIONAL_STATE /EC_BNetzA_VL_not_valid |
Sec |
Warning |
x |
x |
Value=true/ false; NextUpdate BNetzAVL= $NextUpdate-Element der BNetzA-VL; Bedeutung= $EC.description; |
" |
|
OPERATIONAL_STATE /EC_FW_Update_Available |
Op | Info | x | x | Bedeutung= $EC.description |
I_KSRS_Download::list_ Updates liefert mindestens eine UpdateInformation mit einer UpdateInformation/Firmware/ FWVersion > aktuelle Version der Konnektor- oder Kartenterminalsoftware |
|
OPERATIONAL_STATE/EC_NK_Certificate_Expiring | Sec | Warning | x | x | Iccsn=$Iccsn; Serial=$Serialnumber; Bedeutung= $EC.description |
Das C.NK.VPN-Zertifikat läuft bald ab. Systemzeit t > (Ablaufdatum von C.NK.VPN – 180 Tage) |
|
OPERATIONAL_STATE /EC_NK_Certificate_Expired |
Sec | Fatal | x | x | Iccsn=$Iccsn; Serial=$Serialnumber; Bedeutung= $EC.description |
Das C.NK.VPN-Zertifikat ist abgelaufen. Systemzeit t > Ablaufdatum von C.NK.VPN |
|
OPERATIONAL_STATE /EC_TLS_Client_Certificate_Security |
Sec | Info | x | x | Bedeutung= $EC.description |
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. | |
Zugriffsberechtigungsdienst |
|||||||
Dokumentvalidierungsdienst |
|||||||
Dienstverzeichnisdienst |
|||||||
Kartenterminaldienst |
|||||||
CT /ERROR |
$Error Type |
$Seve rity |
x |
x |
CtID=$CT.ID; Name=$CT.HOSTNAME; Error=$Fehlercode; Bedeutung= $Fehlertext |
Bei der Kommunikation mitdem KT ist ein Fehler aufgetreten |
TUC_KON_051 TUC_KON_053 |
CT /CONNECTED |
Op |
Info |
x |
x |
CtID=$CT.CTID; Hostname= $CT.HOSTNAME |
Die Verbindung zu einem Kartenterminal wurde hergestellt |
|
CT /DISCONNECTED |
Op |
Info |
x |
x |
CtID=$CT.CTID; Hostname= $CT.HOSTNAME |
Die Verbindung zu einem Kartenterminal wurde unterbrochen |
|
CT /TLS_ESTABLISHMENT_FAILURE |
$Error Type |
$Seve rity |
x |
x |
CtID = $CT.ID; Name=$CT. HOSTNAME; Error=$Fehlercode; Bedeutung= $Fehlertext |
Im Rahmen des Verbindungsaufbaus sind Fehler aufgetreten |
TUC_KON_050 |
CT /CT_ADDING_ERROR |
$Error Type |
$Seve rity |
x |
x |
IP=$IP-Adresse; Name=$Hostname; Error=$Fehlercode; Bedeutung= $Fehlertext |
Bei dem Versuch ein KT der Verwaltung zuzufügen ist ein Fehler aufgetreten |
TUC_KON_054 |
CT /SLOT_FREE |
Op |
Info |
- |
- |
CtID=$CT.CTID; SlotNo= $CT.SLOTS_USED[X] |
Internes Event von Kartenterminaldienst --> Kartendienst. Informiert, dass ein Slot frei wurde. Wird im Kartendienst ausgewertet und verursacht dort CARD/REMOVED |
|
CT /SLOT_IN_USE |
Op |
Info |
- |
- |
CtID=$CT.CTID; SlotNo=<FU-Nummer aus Ereignisnachricht> |
Internes Event von Kartenterminaldienst --> Kartendienst. Informiert, dass ein Slot belegt wurde. Wird im Kartendienst ausgewertet und verursacht dort CARD/INSERTED |
|
Kartendienst |
|||||||
CARD /INSERTED |
Op |
Info |
x |
x |
CardHandle= $CARD.CARDHANDLE; CardType=$CARD.TYP; CardVersion= $CARD.VER; ICCSN=$CARD.ICCSN; CtID=$CARD.CTID; SlotID= $CARD.SLOTID; InsertTime= $CARD.INSERTTIME; CardHolderName= $CARD.CARD HOLDERNAME; KVNR=$CARD.KVNR |
Eine Karte wurde gesteckt |
TUC_KON_001 (als Reaktion auf CTM /SLOT_IN_USE) |
CARD /REMOVED |
Op |
Info |
x |
x |
CardHandle= $CARD.CARDHANDLE; CardType=$CARD.TYP; CardVersion= $CARD.VER; ICCSN=$CARD.ICCSN; CtID=$CARD.CTID; SlotID= $CARD.SLOTID; InsertTime= $CARD.INSERTTIME; CardHolderName= $CARD.CARDHOLDER NAME; KVNR=$CARD.KVNR |
Eine Karte wurde gezogen |
Reaktion auf CTM/SLOT_FREE |
CARD /PIN /VERIFY_STARTED |
Op |
Info |
- |
x |
|||
CARD /PIN /VERIFY_FINISHED |
Op |
Info |
- |
x |
|||
CARD /PIN /CHANGE_STARTED |
Op |
Info |
- |
x |
|||
CARD /PIN /CHANGE_FINISHED |
Op |
Info |
- |
x |
|||
CARD /PIN /ENABLE_STARTED |
Op |
Info |
- |
x |
CardHandle=$; CardType=$; ICCSN=$; CtID=$; SlotID=$; PinRef=$PinRef; PinInputCtID =$PinInputKT |
PIN-Schutz anschalten beginnt |
TUC_KON_027 |
CARD /PIN /ENABLE_FINISHED |
Op |
Info |
- |
x |
CardHandle=$; CardType=$; ICCSN=$; CtID=$; SlotID=$; PinRef=$PinRef; PinInputCtID =$PinInputKT |
PIN-Schutz anschalten wurde beendet |
TUC_KON_027 |
CARD /PIN /DISABLE_STARTED |
Op |
Info |
- |
x |
CardHandle=$; CardType=$; ICCSN=$; CtID=$; SlotID=$; PinRef=$PinRef; PinInputCtID =$PinInputKT |
PIN-Schutz ausschalten beginnt |
TUC_KON_027 |
CARD /PIN /DISABLE_FINISHED |
Op |
Info |
- |
x |
CardHandle=$; CardType=$; ICCSN=$; CtID=$; SlotID=$; PinRef=$PinRef; PinInputCtID =$PinInputKT |
PIN-Schutz ausschalten wurde beendet |
TUC_KON_027 |
Systeminformationsdienst |
|||||||
Verschlüsselungsdienst |
|||||||
Signaturdienst |
|||||||
SIG /SIGNDOC /NEXT_SUCCESSFUL |
Op |
Info |
- |
X |
$Jobnummer |
Die nächste Signatur aus einem Signaturstapel wurde erfolgreich erstellt. |
TUC_KON_166 „nonQES Signaturen erstellen“ TUC_KON_154 „QES Signaturen erstellen“ |
Zertifikatsdienst |
|||||||
CERT /TSL /IMPORT |
Op |
Error |
x |
- |
$Fehlerbeschreibung |
Manueller Import der TSL fehlgeschlagen |
TUC_KON_032 "TSL aktualisieren" |
CERT /TSL /UPDATED |
Op |
Info |
x |
- |
Eine neue TSL wurde erfolgreich in den TrustStore eingespielt |
TUC_KON_032 "TSL aktualisieren" |
|
CERT /CRL /INVALID |
Op |
Error |
x |
- |
Prüfung der Signatur der CRL fehlgeschlagen |
TUC_KON_040 "CRL aktualisieren" |
|
CERT /CRL /IMPORT |
Op |
Error |
x |
- |
$Fehlerbeschreibung |
Manueller Import der CRL fehlgeschlagen |
TUC_KON_040 "CRL aktualisieren" |
CERT /CRL /UPDATED |
Op |
Info |
x |
- |
Die CRL wurde erfolgreich aktualisiert |
TUC_KON_040 "CRL aktualisieren" |
|
CERT /CARD /EXPIRATION |
Op |
Warning |
x |
x |
CARD_TYPE=gSMC-K; ICCSN=$ICCSN; Konnektor= $MGM_KONN_HOSTNAME; ZertName=<Name des Zertifikatsobjekts>; Expiration Date=$validity |
gSMC-K abgelaufen |
TUC_KON_033 "Zertifikatsablauf prüfen" |
CERT /CARD /EXPIRATION |
Op |
Warning |
- |
x |
CARD_TYPE=$Type; ICCSN=$ICCSN; CARD_HANDLE= $CardHandle; CardHolderName= $CardHolderName; ZertName=<Name des Zertifikatsobjekts>; ExpirationDate= $validity |
Sonstige Karte abgelaufen |
TUC_KON_033 "Zertifikatsablauf prüfen" |
CERT /CARD /EXPIRATION |
Op |
Info |
- |
x |
CARD_TYPE=gSMC-K; ICCSN=$ICCSN; Konnektor= $MGM_KONN_HOSTNAME; ZertName=<Name des Zertifikatsobjekts>; ExpirationDate= $validity; DAYS_LEFT= $validity-$Today |
gSMC-K läuft innerhalb von DAYS_LEFT Tagen ab |
TUC_KON_033 "Zertifikatsablauf prüfen" |
CERT /CARD /EXPIRATION |
Op |
Info |
- |
x |
CARD_TYPE=$Type; ICCSN=$ICCSN; CARD_HANDLE= $CardHandle; CardHolderName= $CardHolderName; ZertName=<Name des Zertifikatsobjekts>; ExpirationDate= $validity; DAYS_LEFT= $validity-$Today |
Sonstige Karte läuft innerhalb von DAYS_LEFT Tagen ab |
TUC_KON_033 "Zertifikatsablauf prüfen" |
CERT /CARD /STATUS |
Op | Warning | - | x | CARD_TYPE=$Type; ICCSN=$ICCSN; CARD_HANDLE=$CardHandle;CardHolderName=$CardHolderName; ZertName=<Name des Zertifikatsobjekts>; ExpirationDate=$validity“ CARD_CERTSTATUS= $CARD.CERTSTATUS| NotAvailable |
||
CERT /BNETZA_VL /UPDATED |
Op |
Info |
x |
- |
Eine neue BNetzA-VL wurde erfolgreich in den TrustStore eingespielt |
TUC_KON_031 " BNetzA-VL aktualisieren" |
|
CERT /BNETZA_VL /IMPORT |
Op |
Error |
x |
- |
$Fehlerbeschreibung |
Manueller Import der BNetzA-VL fehlgeschlagen |
TUC_KON_031 " BNetzA-VL aktualisieren" |
Protokollierungsdienst |
|||||||
LOG /ERROR |
$Error Type |
$Seve rity |
- |
- |
Error=$Fehlercode |
Im Protokollierungsdienst auftretende Fehler werden verteilt | TUC_KON_271 |
LOG /CRYPTO_OP |
Sec |
Info |
x |
- |
Operation= $Operationsname; <für alle betroffenen Schlüssel:> Karte=$ICCSN; Keyref=<Referenz auf den Schlüssel>; CARD_HANDLE= $CardHandle; CardHolderName= $CardHolderName |
||
TLS-Dienst |
|||||||
MGM /TLS_CERT |
Op | Info | x | x | Interface=CS_ITF; Fingerprint=<Fingerprint des an der Clientsystemschnittstelle aktiven TLS-Zertifikats> |
Neues TLS-Zertifikat wurde aktiviert, mit dem der Konnektor sich an der Clientsystemschnittstelle authentisiert |
A_24485 |
Anbindung LAN/WAN |
|||||||
ANLW /LAN /IP_CHANGED |
Op |
Warning |
x |
- |
IP=$dieNeueIP |
Wenn der LAN-Adapter eine neue IP oder Netzwerk bekommen hat |
DHCP, Management schnittstelle |
ANLW /WAN /IP_CHANGED |
Op |
Info |
x |
- |
IP=$dieNeueIP |
Wenn der WAN-Adapter eine neue IP oder Netzwerk bekommen hat |
DHCP, Management schnittstelle |
DHCP-Server |
|||||||
DHCP /SERVER /STATECHANGED |
Op |
Info |
x |
x |
STATE= $DHCP_SERVER_STATE |
Administrator |
|
DHCP Client |
|||||||
DHCP /LAN_CLIENT /RENEW |
Op |
Info |
x |
x |
IP_ADDRESS= <Belegung> |
TUC_KON_341 |
|
DHCP /WAN_CLIENT /RENEW |
Op |
Info |
x |
x |
IP_ADDRESS= <Belegung> |
TUC_KON_341 |
|
DHCP /LAN_CLIENT /STATECHANGED |
Op |
Info |
x |
x |
STATE= $DHCP_CLIENT_ LAN_STATE |
||
DHCP /WAN_CLIENT /STATECHANGED |
Op |
Info |
x |
x |
STATE= $DHCP_CLIENT_ WAN_STATE |
||
VPN-Client |
|||||||
NETWORK /VPN_TI /UP |
Op |
Info |
x |
x |
Wenn der VPN-Tunnel zur TI erfolgreich aufgebaut worden ist. |
||
NETWORK /VPN_TI /DOWN |
Op |
Info |
x |
x |
Wenn der VPN-Tunnel zur TI nicht mehr zur Verfügung steht. |
AFO |
|
NETWORK /VPN /CONFIG_CHANGED |
Op |
Info |
x |
- |
Wenn die Konfiguration des VPN-Clients angepasst wurde. |
Management schnittstelle |
|
NETWORK /VPN_SIS /UP |
Op |
Info |
x |
x |
Wenn der VPN-Tunnel zum SIS erfolgreich aufgebaut worden ist. |
||
NETWORK /VPN_SIS /DOWN |
Op |
Info |
x |
x |
Wenn der VPN-Tunnel zum SIS nicht mehr zur Verfügung steht. |
AFO |
|
Zeitdienst |
|||||||
NTP /ENTERCRITICALSTATE |
Op |
FATAL |
x |
- |
MESSAGE= „CRITICALTIME DEVIATION” |
Zeitabweichung von mehr als einer Stunde entdeckt |
|
Namensdienst und Dienstlokalisierung |
|||||||
Leistungsumfänge und Standalone-Szenarios |
|||||||
MGM /ADMINCHANGES |
Op |
Info |
x |
- |
User= $AdminUsername; RefID=$ReferenzID; NewVal= $NeuEingestellter Wert“ |
Änderungen die der Admin vornimmt werden protokolliert |
|
MGM /CONFIG_EXIMPORT |
Op |
Info |
x |
- |
User= $AdminUsername; Mode= [Export/Import] |
Dokumentiert (via Mode), dass die Konnektor konfiguration exportiert oder importiert wurde. |
|
MGM /FACTORYSETTINGS |
Op |
Info |
x |
- |
User= $AdminUsername |
Ein ausgelöster Werksreset wird protokolliert |
|
MGM /REMOTE_SESSION |
Op |
Info |
x |
- |
InitUser= $AdminUsername; RemoteID=<Kennung der Gegenstelle>; Mode= [InitSuccess/ InitFail/Exit] |
Protokollierung des Versuchs, des Beginns und des Endes einer Remote- Management Session |
|
MGM /LU_CHANGED /LU_ONLINE |
Op |
Info |
x |
x |
Active= $MGM_LU_ONLINE |
Leistungsumfang Online wurde aktiviert/ deaktiviert |
Administrator |
MGM /LU_CHANGED /LU_SAK |
Op |
Info |
x |
x |
Active= $MGM_LU_SAK |
Leistungsumfang Signatur anwendungs komponente wurde aktiviert/deaktiviert |
Administrator |
MGM /STANDALONE_CHANGED |
Op |
Info |
x |
x |
Active= $MGM_STANDALONE_KON |
Festlegung des Konnektors als "Alleinstehend" wurde geändert |
Administrator |
In- und Außerbetriebnahme, Registrierung, Laufzeitverlängerung |
|||||||
MGM /TI_ACCESS_GRANTED |
Op |
Info |
x |
x |
Active= $MGM_TI_ACCESS_ GRANTED |
Der Konnektor wurde erfolgreich freigeschaltet |
Administrator TUC_KON_411 |
SMC_K/REGISTER/ERROR | Op | Error | x | x | Iccsn=$Iccsn; Serial=$SerialnumberNK; Operation=Register | Deregister; Fail=No_Smcb | Other |
Fehler bei Registrierung | TUC_KON_411 |
SMC_K/UPDATE/SUCCESS | Op | Info | x | x | Zertifikate erfolgreich erneuert | TUC_KON_410 | |
SMC_K/DOWNLOAD/ERROR | Op | Error | x | x | Fehler beim Zertifikatsdownload | TUC_KON_410 | |
SMC_K/UPDATE/ERROR | Op | Error | x | x | Iccsn=$Iccsn; Profile=$CertProfile; Serial=$Serialnumber; Fail=Incomplete | Iccsn | Date | Crypt | Ocsp | Profile | Signature | Other |
Prüffehler bei Zertigfikatsupdate | TUC_KON_410 Hinweise: - Es sollen die Parameter des neuen Zertifikats ins Event geschrieben werden, wenn es bekannt ist. Sonst sollen die Parameter des alten Zertifikats verwendet werden. - $CertProfile - Verwendung der Zertifikatsbezeichner aus gemSpec_gSMC-K_ObjSys |
Software- Aktualisierungsdienst (KSR-Client) |
|||||||
KSR /ERROR |
$Error Type |
$Seve rity |
x |
x |
Target=Konnektor; Name= <MGM_KONN_HOSTNAME>; Error=$Fehlercode; Bedeutung= $Fehlertext |
Während der Konnektor aktualisierung ist ein Fehler aufgetreten |
TUC_KON_280 |
KSR /ERROR |
$Error Type |
$Seve rity |
x |
x |
Target=KT; Name= <KT-Friendly Name>; CtID=$ctID; Error=$Fehlercode; Bedeutung= $Fehlertext |
Während einer Kartenterminal aktualisierung ist ein Fehler aufgetreten |
TUC_KON_281 |
KSR /ERROR |
$Error Type |
$Seve rity |
x |
x |
Error=$Fehlercode; Bedeutung= $Fehlertext |
Im KSR-Client ist ein Fehler aufgetreten |
TUC_KON_282 |
KSR /UPDATE /START |
Sec |
Info |
x |
x |
für TUC_KON_280 Target=Konnektor; Name= <MGM_KONN_HOSTNAME> für TUC_KON_281 Target=KT; CtID=$CtID |
Ein Updateprozess im Konnektor wird gestartet, Ziel Konnektor oder Kartenterminal |
TUC_KON_280 TUC_KON_281 |
KSR /UPDATE /SUCCESS |
Sec |
Info |
x |
x |
für TUC_KON_280 Target=Konnektor; Name= <MGM_KONN_HOSTNAME>; NewFirmwareversion= <UpdateInformation. FirmwareVersion>; ConfigurationChanged =<Ja/Nein>; ManualInputNeeded= <Ja/Nein> für TUC_KON_281 Target=KT; Name= <KT-FriendlyName>; CtID=$ctID; NewFirmwareversion= <UpdateInformation. FirmwareVersion> |
Die Firmware des Konnektors/ eines Kartenterminals wurde erfolgreich aktualisiert |
TUC_KON_280 TUC_KON_281 |
KSR /UPDATE /END |
Sec |
Info |
x |
x |
für TUC_KON_280 Target=Konnektor; Name= <MGM_KONN_HOSTNAME> für TUC_KON_281 Target=KT; CtID=$CtID |
Ein Updateprozess im Konnektor wurde beendet |
TUC_KON_280 TUC_KON_281 |
KSR /UPDATE /KONNEKTOR_DOWNLOAD_END |
Op |
Info |
x |
x |
Je heruntergeladenem FW-Paket: ProductVendorID= $UpdateInformation/ ProductVendorID; ProductCode= $UpdateInformation/ ProductCode; ProductName= $UpdateInformation/ ProductName; FirmwareVersion= $UpdateInformation/ Firmware/FWVersion; Deadline= $UpdateInformation/ DeploymentInformation/ Deadline; FWPriority= $UpdateInformation/ Firmware/FWPriority; FirmwareReleaseNotes= $UpdateInformation/ Firmware/ FirmwareReleaseNotes |
Download der Konnektor Firmware abgeschlossen |
TIP1-A_6025 |
KSR /UPDATES_AVAILABLE |
Op |
Info |
- |
x |
Je gefundenem FW-Paket: ProductVendorID= $UpdateInformation/ ProductVendorID; ProductCode= $UpdateInformation/ ProductCode; ProductName= $UpdateInformation/ ProductName; FirmwareVersion= $UpdateInformation/ FirmwareVersion; Deadline= $UpdateInformation/ DeploymentInformation/ Deadline; FWPriority= $UpdateInformation/ Firmware/FWPriority; FirmwareReleaseNotes= $UpdateInformation/ Firmware/ FirmwareReleaseNotes |
Ein oder mehrere Updates auf neuere Versionen sind verfügbar |
TIP1-A_4836 |
KSR /UPDATE_KONFIG |
Op |
Info |
x |
- |
AlteVersion, NeueVersion |
Aktualisierung Bestandsnetze |
TUC_KON_283 |
Die Abbildungsvorschrift von Fehler- auf Event-Type lautet:
- Security → Security,
- Technical → Operation,
- Infrastructure → Infrastructure,
- Business → Business,
- Other → Other
8 Anhang H – Mapping von „Architektur der TI-Plattform“ auf Konnektorspezifikation
Tabelle 396: TAB_KON_711 Architektur der TI-Plattform, Berechtigt Fachmodule
Interface |
Operation |
→ |
Funktionsmerkmal |
Interface |
---|---|---|---|---|
I_Cert_Verification |
verify_Certificate |
→ |
Zertifikatsdienst |
TUC_KON_037 "Zertifikat prüfen" |
I_Crypt_Operations |
decrypt_Document |
→ |
Verschlüsselungsdienst |
TUC_KON_071 "Daten hybrid entschlüsseln" |
encrypt_Document |
→ |
TUC_KON_070 "Daten hybrid verschlüsseln" |
||
I_DNS_Name_Information |
get_FQDN |
→ |
Namensdienst und Dienstlokalisierung |
TUC_KON_364 „DNS Reverse Lookup durchführen“ |
get_IP_Address |
→ |
TUC_KON_361 „DNS Namen auflösen“ |
||
get_Service_Information |
→ |
Namensdienst und Dienstlokalisierung |
TUC_KON_362 „Liste der Dienste abrufen“ TUC_KON_363 „Dienstdetails abrufen“ |
|
I_IP_Transport |
send_Data_TI |
→ |
||
I_KT_Operations |
interact_with_User |
→ |
Kartenterminaldienst |
TUC_KON_051 "Mit Anwender über Kartenterminal interagieren" |
I_KV_Card_Handling |
discard_Card_Usage_Reference |
→ |
--- |
--- keine Umsetzung notwendig. Erfolgt implizit |
get_Card_Usage_Reference |
→ |
--- |
--- keine Umsetzung notwendig. Erfolgt implizit |
|
I_KV_Card_Operations |
decrypt_Data |
→ |
Kartendienst |
TUC_KON_219 "Entschlüssele" |
do_Reset |
→ |
TUC_KON_024 "Karte zurücksetzen" |
||
erase_Card_Data |
→ |
TUC_KON_211 „LöscheRecordInhalt“ TUC_KON_204 „LöscheDateiInhalt“ |
||
extract_card_data |
→ |
Zertifikatsdienst |
TUC_KON_034 "Zertifikatsinformationen extrahieren" |
|
read_Card_Data |
→ |
Kartendienst |
TUC_KON_202 "LeseDatei" |
|
→ |
TUC_KON_209 "LeseRecord" |
|||
→ |
TUC_KON_215 "SucheRecord" |
|||
read_KVK |
→ |
TUC_KON_202 "Lese Datei" |
||
send_APDU |
→ |
TUC_KON_200 "SendeAPDU" |
||
sign_Data |
→ |
TUC_KON_218 "Signiere" |
||
verify_eGK |
→ |
TUC_KON_018 "eGK-Sperrung prüfen" |
||
write_Card_Data |
→ |
TUC_KON_203 "SchreibeDatei" |
||
→ |
TUC_KON_210 "SchreibeRecord" |
|||
→ |
TUC_KON_214 "FügeHinzuRecord" |
|||
write_eGK_Protocol |
→ |
TUC_KON_006 "Datenzugriffsaudit eGK schreiben" |
||
I_KV_Card_Reservation |
handle_Session |
→ |
Kartendienst |
TUC_KON_023 "Karte reservieren" |
I_KV_Card_Unlocking |
authorize_Card |
→ |
Kartendienst |
TUC_KON_005 "Card-to-Card authentisieren" |
change_PIN |
→ |
TUC_KON_019 "PIN ändern" |
||
enable_PIN disable_PIN |
→ |
TUC_KON_027 „PIN-Schutz ein-/ ausschalten” |
||
do_C2C |
→ |
TUC_KON_005 "Card-to-Card authentisieren" |
||
get_PIN_Status |
→ |
TUC_KON_022 "Liefere PIN-Status" |
||
initialize_PIN |
→ |
TUC_KON_019 "PIN ändern" |
||
unblock_PIN |
→ |
TUC_KON_021 "PIN entsperren" |
||
verify_PIN |
→ |
TUC_KON_012 "PIN verifizieren" |
||
I_Notification_From_FM |
notify |
→ |
Systeminformationsdienst |
TUC_KON_256 "Systemereignis absetzen" |
I_Local_Storage |
write_Data read_Data erase_Data |
→ |
Konnektormanagement |
TIP1-A_5484 |
I_Poll_System_Information |
get_Ressource_Information |
→ |
Systeminformationsdienst |
TUC_KON_254 "Liefere Ressourcendetails" |
get_Ressource_List |
→ |
TUC_KON_252 "Liefere KT_Liste" |
||
get_Ressource_List |
→ |
TUC_KON_253 "Liefere Karten_Liste" |
||
I_Reg_Notification |
register_for_Notifications |
→ |
--- |
--- keine Umsetzung notwendig. Erfolgt implizit |
I_Role_Information |
get_Role |
→ |
Kartendienst |
TUC_KON_036 „LiefereFachlicheRolle“ |
I_SAK_Operations |
sign_Document_QES |
→ |
Signaturdienst |
TUC_KON_150 „Dokumente QES signieren“ |
verify_Document_QES |
→ |
TUC_KON_151 "QES Dokumentensignatur prüfen" |
||
I_Sign_Operations |
sign_Document |
→ |
Signaturdienst |
TUC_KON_160 „Dokumente nonQES signieren“ |
external_Authenticate |
→ |
TUC_KON_160 „Dokumente nonQES signieren“ |
||
verify_Document |
→ |
TUC_KON_161 „nonQES Dokumentsignatur prüfen“ |
||
get_Certificate |
→ |
Kartendienst |
TUC_KON_216 „LeseZertifikat“ |
|
I_Symm_Crypt_Operations |
decrypt_Document_Symmetric |
→ |
Verschlüsselungsdienst |
TUC_KON_073 "Daten symmetrisch entschlüsseln" |
encrypt_Document_Symmetric |
→ |
TUC_KON_072 "Daten symmetrisch verschlüsseln" |
||
I_Synchronised_System_Time |
get_Time |
→ |
Zeitdienst |
TUC_KON_351 "Liefere Systemzeit" |
I_TLS_Client |
send_Secure |
→ |
TLS-Dienst |
TUC_KON_110 "Kartenbasierte TLS-Verbindung aufbauen" |
→ |
TUC_KON_111 "Kartenbasierte TLS-Verbindung abbauen" |
|||
→ |
Anbindung LAN/WAN |
AFOs: Routing der IP-Pakete von Fachmodul (=Konnektor intern) --> VPN_TI |
||
I_Directory_Query |
search_Directory |
→ |
LDAP-Proxy |
TUC_KON_290 „LDAP-Verbindung aufbauen“ |
→ |
TUC_KON_291 „Verzeichnis abfragen“ |
|||
→ |
TUC_KON_292 „LDAP-Verbindung trennen" |
|||
→ |
TUC_KON_293 „Verzeichnisabfrage abbrechen" |
|||
I_KSRC_FM_Support |
list_available_Packages |
→ |
Software-Aktualisierung (KSR-Client) |
TUC_KON_285 „UpdateInformationen für Fachmodul beziehen" |
load_Package |
→ |
TUC_KON_286 „Paket für Fachmodul laden“ |
Tabelle 397: TAB_KON_712 Architektur der TI-Plattform, Berechtigt Clientsysteme
Interface |
Operation |
→ |
Funktionsmerkmal |
Interface:Operation |
---|---|---|---|---|
I_Crypt_Operations |
decrypt_Document |
→ |
Verschlüsselungsdienst |
EncryptionService :DecryptDocument |
encrypt_Document |
→ |
EncryptionService :EncryptDocument |
||
I_DNS_Name_Resolution |
get_FQDN |
→ |
Namensdienst und Dienstlokalisierung |
GetFQDN |
get_IP_Address |
→ |
GetIPAddress |
||
I_IP_Transport |
send_Data_External |
→ |
Anbindung LAN/WAN |
AFOs: Routing der IP-Pakete von Client --> VPN_SIS |
I_KV_Card_Handling |
discard_Card_Usage_Reference |
→ |
--- |
--- keine Umsetzung notwendig. Erfolgt implizit |
get_Card_Usage_Reference |
→ |
--- |
--- keine Umsetzung notwendig. Erfolgt implizit |
|
I_KV_Card_Unlocking |
change_PIN |
→ |
Kartendienst |
CardService :ChangePin |
disable_PIN |
→ |
CardService :EnablePin |
||
enable_PIN |
→ |
CardService :DisablePin |
||
get_PIN_Status |
→ |
CardService :GetPinStatus |
||
initialize_PIN |
→ |
CardService :ChangePin |
||
unblock_PIN |
→ |
CardService :UnblockPin |
||
verify_PIN |
→ |
CardService :VerifyPin |
||
I_Poll_System_Information |
get_Ressource_Information |
→ |
Systeminformationsdienst |
EventService :GetResourceInformation |
get_Ressource_List |
→ |
EventService :GetCardTerminals |
||
get_Ressource_List |
→ |
EventService :GetCards |
||
I_Reg_Notification |
register_for_Notifications |
→ |
Systeminformationsdienst |
EventService :Subscribe |
→ |
EventService :Unsubscribe |
|||
→ |
EventService :GetSubscription |
|||
I_SAK_Operations |
sign_Document_QES |
→ |
Signaturdienst |
SignatureService :SignDocument |
verify_Document_QES |
→ |
SignatureService :VerifyDocument |
||
I_Sign_Operations |
sign_Document |
→ |
Signaturdienst |
SignatureService :SignDocument |
verify_Document |
→ |
SignatureService :VerifyDocument |
||
external_Authenticate |
→ |
Authentifizierungsdienst |
AuthSignatureService :ExternalAuthenticate |
|
get_Certificate |
→ |
Zertifikatsdienst |
CertificateService :ReadCardCertificate |
|
I_NTP_Time_Information |
sync_Time |
→ |
Zeitdienst |
I_NTP_Time_Information :sync_Time |
I_Directory_Query |
search_Directory |
→ |
LDAP-Proxy |
LDAP-Operation (TIP1-A_5521) |
Tabelle 398: TAB_KON_713 Architektur der TI-Plattform, Berechtigt eHealth-KT
Interface |
Operation |
→ |
Funktionsmerkmal |
Interface:Operation |
---|---|---|---|---|
I_Notification |
notify |
→ |
SICCT |
Ereignisdienst :SICCT-Ereignisnachrichten |
→ |
SICCT |
Ereignisdienst :ServiceAnnouncement |
Tabelle 399: TAB_KON_714 Architektur der TI-Plattform, Berechtigt Administrator
Interface |
Operation |
-> |
Funktionsmerkmal |
Interface:Operation |
---|---|---|---|---|
I_Change_System_Time |
set_System_Time |
-> |
Zeitdienst |
TIP1-A_4793 Konfigurierbarkeit des Konnektor NTP-Servers |
I_Facade_Access_Configuration |
add_Clientsystem |
-> |
Fachliche Anbindung der Clientsysteme |
TIP1-A_4518 Konfiguration der Anbindung Clientsysteme |
remove_Clientsystem |
||||
set_CS_Access_Mode |
||||
I_KSRC_Local_Management |
do_local_Update |
-> |
Software-Aktualisierung (KSR-Client) |
TUC_KON_280 "Konnektoraktualisierung durchführen" |
I_KSRC_Management |
do_Update |
-> |
Software-Aktualisierung (KSR-Client) |
TUC_KON_280 "Konnektoraktualisierung durchführen" |
TUC_KON_281 "Kartenterminalaktualisierung anstoßen" |
||||
list_available_Updates |
TUC_KON_282 "Update Informationen beziehen" |
|||
I_KTV_Management |
configure_KTs |
-> |
Kartenterminalverwaltung |
Managementschnittstelle :TIP1-A_4555 Manuelles Hinzufügen eines Kartenterminals |
Managementschnittstelle :TIP1-A_4540 Reaktion auf KT Service Announcement |
||||
Managementschnittstelle :TIP1-A_4556 Pairing mit Kartenterminal durchführen |
||||
Managementschnittstelle :TIP1-A_4557 Ändern der Korrelationswerte eines Kartenterminals |
9 Anhang I – Umsetzungshinweise (informativ)
In diesem Anhang finden sich Darstellungen und Informationen, die ein Konnektorhersteller zur Umsetzung der normativen Anforderungen in ein konkretes Produkt berücksichtigen kann. Sie wurden im Rahmen der Erhebung der normativen Anforderungen erarbeitet, um die Umsetzbarkeit der Anforderungen zu bestätigen.
Dieser Anhang soll als Unterstützung für eine Umsetzung verstanden werden und erhebt keinen Anspruch auf Korrektheit und Vollständigkeit.
9.1 Systemüberblick
9.1.1 – Hinweise zur Sicherheitsevaluierung nach Common Criteria
Gemäß dem Sicherheitskonzept des Konnektors [gemKPT_Sich_Kon] muss die Software des Konnektors nach Common Criteria (CC) evaluiert und geprüft werden.
Diese Software erbringt Sicherheitsleistungen in zwei wesentlichen Funktionsblöcken. Durch diese Aufteilung ist es möglich, dass die einzelnen Funktionsblöcke zeitlich voneinander unabhängig bzw. sogar von unterschiedlichen Herstellern implementiert, evaluiert und geprüft werden können. Es werden zwei Schutzprofile (Protection Profile) für die Funktionsblöcke des Konnektors erstellt. Es handelt sich dabei um die Schutzprofile des Netzkonnektors (KONN.NK) sowie des Anwendungskonnektors (KONN.AK) inklusive der Signaturanwendungskomponente. Das Schutzprofil des Sicherheitsmoduls für den Konnektor (SM-K) wird in diesem Kapitel nicht betrachtet.
Diese Schutzprofile definieren eine implementierungsunabhängige Menge von Sicherheitsanforderungen für die einzelnen Konnektorfunktionsblöcke bzw. Konnektorbestandteile. Anhand dieser Schutzprofile werden von den Herstellern der Konnektoren die Sicherheitsvorgaben (Security Targets) für die konkreten Umgebungen erstellt, welche als Eingangsdokumente für den Zertifizierungsprozess der jeweiligen konkreten Komponenten eingesetzt werden. Diese zu evaluierenden Komponenten werden als Evaluierungsgegenstand (EVG) bezeichnet.
9.1.1.1 Separationsmechanismen des Konnektors
Damit es nach einer erfolgreichen Evaluierung eines Konnektors auch weiterhin möglich bleibt, Software oder Daten, die keinen direkten Einfluss auf Sicherheitsfunktionen der EVGs aufweisen, ohne eine Re-Evaluierung definiert auszutauschen, hinzuzufügen oder zu erweitern, ist eine Separation der Komponenten des EVG dringend anzuraten.
Implementiert der Hersteller keine bzw. nicht ausreichende Separationsmechanismen, so ist bei bestimmten Update-Arten von einer aufwändigen Re-Evaluierung des entsprechenden EVGs auszugehen. Die Separation dient also der Trennung zwischen ausführbarem Code des EVG, welcher Sicherheitsfunktionen umsetzt, und zusätzlichem ausführbarem Code auf dem Konnektor, welcher keine Sicherheitsfunktionen umsetzt.
Die Wahl der Separationsmechanismen steht dem Hersteller frei und muss in den Sicherheitsvorgaben für den EVG beschrieben und als solcher evaluiert werden. Aus diesen Sicherheitsvorgaben ergibt sich auch, welche Update-Arten bei welchen Separationsmechanismen eine Re-Evaluierung des EVG erfordern und wie aufwendig diese Re-Evaluierung ausfällt.
Unter diese Update-Arten können beispielsweise – je nach Konnektorarchitektur, CC-Dokumentation oder Konnektorimplementierung – Bestandteile des unter dem Konnektor arbeitenden Betriebsystems, die Installation dezentraler Komponenten von Fachlogik oder Konfigurationsdaten des Konnektors fallen.
Als Beispiel für Separationsmechanismen sei auf die folgende informative Aufzählung verwiesen, welche jedoch keinen Anspruch auf Vollständigkeit besitzen kann und nur mögliche Alternativen aufzeigt:
- Java-Sandbox-Konzept,
- Interpreter mit restriktiver Laufzeitprüfung,
- vom Betriebssystem bereitgestellte Prozess- und Speichertrennung,
- virtuelle Maschinen,
- physische Trennung durch separierte Hardware.
Je nach gewähltem Architekturansatz des Herstellers sind nicht alle hier genannten Alternativen für die Separation des EVG auf dem Konnektor anwendbar.
Insbesondere sollte der Hersteller den eigentlichen Update-Prozess und die dafür verantwortliche Komponente mit besonderer Sorgfalt beschreiben, spezifizieren und implementieren. Bei einer fehlerhaften Implementierung dieser Komponente besteht die Gefahr einer Schwächung oder des Ausschaltens von Sicherheitsfunktionen des EVG. Die Update-Komponente muss eine sichere Zuweisung der Updates zu den separierten Bestandteilen des EVGs gewährleisten. Auch ist zu betonen, dass der EVG immer die Integrität der Daten des Updates und die Authentizität des Absenders prüfen muss, bevor ein Update akzeptiert wird. Der Update-Komponente muss somit besondere Beachtung geschenkt werden.
9.1.1.2 Granularität der TSF
Die TSF (TOE Security Functionality) eines EVG besteht aus Subsystemen und Modulen, wobei ein Modul die genaueste Beschreibung einer Funktionalität darstellt und unterhalb der Subsysteme angesiedelt ist. Subsysteme beschreiben das Design des EVG und können wiederum – je nach Komplexität eines EVGs – aus weiteren Subsystemen bestehen. Ein Entwickler sollte außer der Modulbeschreibung keine weiteren Informationen zur Implementierung der dort beschriebenen Funktionalität benötigen.
Die Subsysteme und Module der TSF gliedern sich in drei Klassen:
(a) SFR-Enforcing Subsysteme und Module. Hierunter fallen die Subsysteme und
Module, welche eine funktionale Sicherheitsanforderung direkt durchsetzen.
(b) SFR-Supporting Subsysteme und Module. Hierunter fallen die Subsysteme und
Module, welche bei der Durchsetzung einer funktionalen Sicherheitsanforderung
unterstützend wirken.
(c) SFR-Non-Interfering Subsysteme und Module. Hierunter fallen die Subsysteme
und Module, welche keine Leistung bei der Erfüllung einer funktionalen
Sicherheitsanforderung erbringen.
Sollte nach einer erfolgreichen CC-Evaluierung eines Konnektors die Notwendigkeit zur Änderung der Software des Konnektors gegeben sein, so ist unter Umständen eine Re-Evaluierung des EVG erforderlich. Diese Notwendigkeit kann sich aus der Behebung von nachträglich erkannten Fehlern, aufgetretenen Sicherheitslücken, Schwächen eines Standardverfahrens oder einer erforderlichen Erweiterung der Funktionalität ergeben.
Im Rahmen der Aufzählung der Anforderungen an die Beschreibung des EVG-Design (ADV_TDS) wird bereits die Aufteilung der TSF auf Subsysteme und Module beschrieben. Trotzdem soll hiermit ausdrücklich geraten werden, die Aufteilung der TSF auf die Subsysteme und Module selbst und die Aufteilung der Subsysteme und Module auf die drei o. g. Klassen möglichst feingranular durchzuführen.
Denn so
- können einfacher umfassende Tests durchgeführt und die Testabdeckung sichergestellt werden,
- kann bei der Veränderung von Programmcode der Evaluator die Auswirkungen auf SFR-Enforcing, Supporting oder Non-Interfering SFRs einfacher herausfinden und damit die Kosten und den zeitlichen Aufwand einer Re-Evaluierung senken.
- kann bei der Veränderung von Programmcode, welcher als SFR-Non-Interfering eingestuft wird, das Maintenance-Verfahren anstelle einer Re-Evaluierung angewandt werden, welches einen erheblichen zeitlichen und damit auch monetären Vorteil gegenüber dem Re-Evaluierungsverfahren darstellt.
9.2 Übergreifende Festlegungen
9.2.1 Interne Mechanismen
9.2.1.1 Zufallszahlen und Schlüssel
Der Konnektor kann zur Erzeugung von Zufallszahlen und Einmalschlüsseln einen Hardware- oder Software-Generator verwenden. Als Quelle für Zufallszahlen kann der Konnektor die gSMC-K verwenden.
9.3 Funktionsmerkmale
9.3.1 Anwendungskonnektor
9.3.1.1 Administration des Informationsmodells
Wie die Administration der persistenten Entitäten und Beziehungen des Informationsmodells im Detail über die bereitzustellende Administrationsoberfläche erfolgt, entscheidet der Hersteller.
Es wird folgende Reihenfolge für die Pflege des Informationsmodells empfohlen.
- Mandantenübergreifende Administration:
- Es werden die Entitäten Arbeitsplätze, Clientsysteme mit Authentifizierungsmerkmalen CS-AuthMerkmal und SMC-B_Verwaltet erfasst.
Die Eingabe der Kartenterminals erfolgt über die Kartenterminalverwaltung. - Es wird die Beziehungen zwischen Arbeitsplatz und Kartenterminals „lokal“ und „entfernt (zentral)“ eingepflegt.
- Mandantenbezogene Administration:
- Die Definition bzw. Auswahl eines Mandanten bildet den Einstiegpunkt.
- Pro Mandanten werden aus den bereits eingepflegten Entitäten „Kartenterminal“, „Arbeitsplatz“, „Clientsystem“, „SMC-B_Verwaltet“ die für den Mandanten im Zugriff erlaubten zugeordnet.
- Pro Mandant erfolgt eine Zuordnung der Arbeitsplätze zu Clientsystemen.
- Pro Mandant erfolgt eine Zuordnung der lokalen Kartenterminals, über die jeweils pro Arbeitsplatz die Eingabe der Remote-PIN erfolgen darf.
9.3.1.2 Vorgehensvariante für das Handling von CardSessions
Das in der [TIP1-A_4560] „Rahmenbedingungen für Kartensitzungen“ geforderte Verhalten, ließe sich über folgenden Mechanismus umsetzen:
Verschiedene Clientsystem (oder verschiedene Nutzer an einem Clientsystem) möchten auf Daten der über CardHandle adressierten Smartcard zugreifen.
Für die Zugriffe müssen, je nach Definition der Zugriffsbedingung in der Zielkarte, bestimmte Sicherheitszustände erreicht werden (durch Verifikation einer PIN oder durch C2C). Diese erreichten Sicherheitszustände werden innerhalb einer Karte jeweils an einen logischen Kanäle (bzw. den Basiskanal) gebunden, d. h., das Erhöhen oder Absenken eines Sicherheitszustands wirkt nicht außerhalb des logischen Kanals, in dem die Veränderung verursacht wurde.
Finden nun Clientsystemzugriffe in unterschiedlichen Kontexten (Mandant, Clientsystem, Arbeitsplatz und Nutzer verschieden) auf die gleiche Karte statt, so muss sichergestellt sein, dass PIN-Eingaben und durchgeführte C2C nur für den Kontext wirksam sind, in welchem sie durchgeführt wurden. Dies ließe sich erreichen, wenn jeder Kontext auf einen eigenen logischen Kanal der Karte abgebildet würde. Leider unterstützen der HBA und die SMC-B nur vier, die eGK nur einen logischen Kanal. Mehrere gleichzeitige unterschiedliche Kontexte wären somit nicht möglich.
Eine mögliche Lösung für beliebig viele gleichzeitige Kontexte:
Abbildung 23: PIC_KON_120 Abbildung von CardSessions auf logische Kanäle
Der Kartendienst fungiert als Multiplexer. Er spiegelt die Zugriffsrechte der Karte und wendet deren Regeln selbständig gegen die unterschiedlichen Zugriffe durch Clientsysteme an.
Für jedes Card-Objekt wird „in Richtung Clientsystem“ pro Kontext genau eine CardSession erzeugt und verwaltet. Zugriffe des Clientsystems erfolgen somit „im Kontext“ einer CardSession.
In Richtung Karte verwendet das Card-Object genau zwei Kanäle (zwei logische oder einen logischen und einen Basiskanal):
- Einen Datenkanal, über den die Datenbewegungen und kryptographischen Operationen laufen und
- Einen Verifikationskanal, der ausschließlich für Authentisierungszwecke verwendet wird
In jeder CardSession werden die in ihrem Kontext erreichten Sicherheitszustände vermerkt. Das Vorgehen für die Durchführung der Verifikationen und des Vermerkens der erreichten Sicherheitszustände, sowie der Datenzugriffe folgt folgenden Regeln (hier für PIN-Verifikation, sinngleich auch für C2C):
- Soll über eine CardSession eine PIN-Verifikation für PinRef_A gegen eine Karte durchgeführt werden und der erhöhte Sicherheitszustand für PinRef_A ist noch nicht erreicht (bsp. direkt nach einem Karten-Reset), dann leite die Verifikation über den Datenkanal (initiale Freischaltung des Datenkanals für folgende Datenzugriffe).
- Soll über eine CardSession eine PIN-Verifikation für PinRef_A gegen eine Karte durchgeführt werden und der erhöhte Sicherheitszustand für PinRef_A ist auf dem Datenkanal bereits erreicht, dann leite die Verifikation über den Verifikationskanal.
- Wurde durch eine CardSession eine Verifikation für PinRef_A erfolgreich durchgeführt, wird dieser erreichte Sicherheitszustand für PinRef_A in der zugreifenden CardSession vermerkt
- Datenzugriffe auf oder Kryptooperationen mit Karten werden durch den Kartendienst nur zugelassen, wenn die zugreifende CardSession über einen für diese Zugriffe benötigten erhöhten Sicherheitszustand verfügt. Ist der benötigte Vermerk für die zugreifende CardSession nicht vorhanden, beantwortet der Kartendienst die Anfrage mit der passenden Kartenfehlermeldung. Es erfolgt keine Interaktion mit der Karte.
Diese Regeln führen dazu, dass eine durch CardSession Y fehlgeschlagene Verifikation für PinRef_A die zuvor erfolgreich durch CardSession X durchgeführt Verifikation nicht beeinflusst. Kartenzugriffe auf dem Datenkanal sind für CardSession X weiterhin möglich, da der Verlust des erhöhten Sicherheitszustands durch fehlerhafte Verifikation immer nur im Verifikationskanal erfolgt.
Dieser Mechanismus funktioniert mit zwei Kanälen zu einer Karte für beliebig viele CardSessions.
9.3.1.3 Darstellung von Terminal-Anzeigen auf einem Kartenterminal
Hiweise für die korrekte Verwendung der zur Verfügung stehenden Datenobjekte (DO) zur Darstellung von Terminal-Anzeigen an einem Kartenterminal finden sich in SICCT- (insbesondere in [SICCT#5.5.10.19] und [SICCT#5.5.10.21]) und eHealth-Kartenterminal-Spezifikationen.
10 Anhang K – Szenarien im dezentralen Umfeld
Die folgenden Szenarien für den Einsatz der Produkte der Telematikinfrastruktur beschreiben informativ Varianten und Optionen, die durch die Spezifikationen abgedeckt werden.
Die vorliegenden Abbildungen in diesem Anhang fokussieren auf das dezentrale Umfeld und verzichten daher auf die Darstellung der zentralen Anteile, wie das zentrale Netzwerk der Telematikinfrastruktur, welches über den „VPN-Konzentrator TI“ erreichbar ist.
Der Konnektor, sowie die Netzwerkkomponenten Switch und IAG (Internet Access Gateway) sind in den folgenden Szenarien zum Schutz vor unerlaubtem Zugriff gemäß den Annahmen des Sicherheitskonzeptes vor unbefugten physischen Zugriffen geschützt installiert.
Die folgenden Abschnitte stellen jeweils ein Szenario in der Übersicht als Diagramm, eine Beschreibung sowie eine kurze Auflistung der Voraussetzungen und Auswirkungen dar.
10.1 Szenario 1: Einfache Installation ohne spezielle Anforderungen und ohne bestehende Infrastruktur
Abbildung 24: Szenario einer einfachen Installation
10.1.1 Beschreibung des Szenarios
Abbildung 25 zeigt ein einfaches Szenario für das dezentrale Umfeld. Es wird der Konnektor als Default-Gateway für jegliche IP-Kommunikation aus dem LAN in das WAN eingesetzt. Dabei übernimmt der Konnektor das Routing der Kommunikation in das Internet über den SIS (Secure Internet Service) und in die an die TI angeschlossenen Bestandsnetze. Die Bezeichnung IAG (Internet Access Gateway) steht für die Geräte, die den Internetzugang ermöglichen und typischerweise vom Internet Service Provider (ISP) zur Verfügung gestellt werden (z.B. DSL Router und DSL Modem).
Ein oder mehrere Clientsysteme können über den Konnektor Anwendungsfälle der Telematikinfrastruktur initiieren und über den Konnektor und die zentrale TI-Plattform in Bestandsnetze kommunizieren (rote gestrichelte Linie). Dabei ist die Nutzung der Anwendungsfälle der Telematikinfrastruktur je nach Konfiguration des Konnektors entweder nur authentifizierten Clients möglich oder beliebigen Clients.
In diesem einfachen Szenario werden über ein einziges Kartenterminal die SMC-B, der HBA und auch die eGK des Versicherten gelesen, es können dazu alternativ auch mehrere Kartenterminals genutzt werden.
Darüber hinaus können die Clientsysteme über den SIS (Secure Internet Service) auf Dienste des Internets zugreifen.
10.1.2 Voraussetzungen
- Anbindung der bestehenden Clientsysteme an ein zum Konnektor kompatibles LAN muss möglich sein.
- Konfiguration des Konnektors als Default-Gateway in den Clientsystemen und Konfiguration der notwendigen VPN-Tunnel im Konnektor, um in die verschiedenen Netze zu routen.
- Verfügbarkeit einer SMC-B
10.1.3 Auswirkungen
- Die Clientsysteme können über den Konnektor Anwendungsfälle der TI initiieren
- Die Clientsysteme können über den Konnektor auf das Internet und Bestandsnetze zugreifen
10.2 Szenario 2: Installation mit mehreren Behandlungsräumen
Abbildung 25: Szenario einer Installation mit mehreren Behandlungsräumen
10.2.1 Beschreibung des Szenarios
Mit der in Szenario 1 skizzierten Topologie kann auch ein Szenario bedient werden, bei dem mehrere Behandlungsräume unterstützt werden (siehe Abbildung 26). Dabei ist in jedem Behandlungsraum mindestens ein Kartenterminal vorzusehen, so dass die eGK gelesen werden kann.
Auf die Darstellung der Kommunikationswege in zentrale Netze wurde in Abbildung 26 verzichtet, da sich hier keine Änderung gegenüber Szenario 1 ergibt.
Durch die Ressourcenverwaltung des Konnektors wird sichergestellt, dass bei Anwendungsfällen diejenigen Kartenterminals angesprochen werden, welche dem Arbeitsplatz zugeordnet sind, von dem aus der Anwendungsfall initiiert wurde.
10.2.2 Voraussetzungen
- Anbindung der bestehenden Clientsysteme an ein zum Konnektor kompatibles LAN muss möglich sein.
- Konfiguration des Konnektors als Default-Gateway in den Clientsystemen und Einrichtung der notwendigen VPN-Tunnel im Konnektor, um in die verschiedenen Netze zu routen.
- Verfügbarkeit einer SMC-B und mehrerer Kartenterminals und Clientsysteme
- Die Clientsysteme und Kartenterminals und deren Relationen sind dem Konnektor über Konfiguration bekannt gemacht worden.
10.2.3 Auswirkungen
- Die Clientsysteme können über den Konnektor Anwendungsfälle der TI initiieren
- Die Clientsysteme können über den Konnektor auf das Internet (über den SIS) und Bestandsnetze zugreifen
- Der HBA-Inhaber muss seinen HBA mit sich führen und kann diesen in den einzelnen Kartenterminals der Behandlungsräume nutzen.
10.3 Szenario 3: Integration in bestehende Infrastruktur ohne Netzsegmentierung
Abbildung 26: Szenario einer Integration der TI Produkte in eine bestehende Infrastruktur
10.3.1 Beschreibung des Szenarios
Im Falle einer bereits vorhandenen Infrastruktur im dezentralen Bereich können die Produkte der TI, insbesondere der Konnektor, so in die Infrastruktur integriert werden, dass Bestandsanwendungen bereits erprobte Kommunikationswege weiter nutzen können.
Wie in Abbildung 27 beispielhaft dargestellt, existiert bereits eine Infrastruktur, die sowohl einen Internetzugang für die Arbeitsplätze ermöglicht (gestrichelte Linie in türkis), als auch eine Nebenstelle über VPN anbindet (gestrichelte Linie in blau). In diesem Fall wird der Konnektor als zusätzliches Gerät an das bestehende Netzwerk angeschlossen und nutzt den bereits vorhandenen Internetanschluss zur Kommunikation in die TI.
Für die Clientsysteme muss in diesem Szenario je nach individuellem Anforderungsprofil entschieden werden, ob das jeweilige Clientsystem über die Telematikinfrastruktur kommunizieren können soll und den gesicherten Internetzugang (SIS) nutzen soll oder nicht.
Soll ein Clientsysteme nicht über die Telematikinfrastruktur kommunizieren, bleibt der IAG als Default-Gateway dieses Clientsystems konfiguriert. In diesem Fall routet der IAG die eingehenden IP-Pakete mit öffentlichen Zieladressen weiter in das Internet. Die gestrichelte Linie in türkis zeigt beispielhaft einen Zugriff in das Internet.
Soll ein Clientsystem über die Telematikinfrastruktur kommunizieren oder den gesicherten Internetzugang (SIS) nutzen, muss der Konnektor als Default-Gateway konfiguriert werden. In diesem Fall routet der Konnektor die eingehenden IP-Pakete, die nicht für ihn bestimmt sind, entweder durch den VPN-Tunnel der TI über die Telematikinfrastruktur in ein angeschlossenes Bestandsnetz, (gestrichelte Linie in rot) oder durch den VPN-Tunnel zum SIS (Secure Internet Service) in das Internet (gestrichelte Linie in grün). Sollte kein sicherer Internetzugang konfiguriert sein, so würde der Konnektor den Traffic verwerfen und ggf. per ICMP dem Client eine anderes Gateway (IAG) vorschlagen. Alternativ können die von den Clients benötigten Routing-Informationen manuell oder per DHCP konfiguriert werden.
10.3.2 Voraussetzungen
- Konnektor ist kompatibel zur bestehenden Infrastruktur (Vernetzung)
- Die bestehende Infrastruktur verfügt über einen Internetzugang
- Verfügbarkeit einer SMC-B und mehrerer Kartenterminals
- Die Clientsysteme und Kartenterminals und deren Relationen sind dem Konnektor über Konfiguration bekannt gemacht worden.
10.3.3 Auswirkungen
- Produkte der Telematik können „minimal-invasiv“ in die bestehende Infrastruktur integriert werden. Bestehende Kommunikationswege können weiter genutzt werden.
- Für Clients kann je nach individuellen Anforderungsprofil der sichere Internetzugang über den Konnektor genutzt werden oder der direkte Internetzugang über den bestehenden IAG
10.4 Szenario 4: Integration in bestehende Infrastruktur mit Netzsegmentierung
Abbildung 27: Szenario einer Integration der TI Produkte in eine bestehende Infrastruktur mit existierendem Router
10.4.1 Beschreibung des Szenarios
Das vorliegende Szenario skizziert eine etwas komplexere dezentrale Umgebung, in der das Netzwerk segmentiert ist und dedizierte Router als Default-Gateway für die Clientsysteme genutzt werden. In diesem Fall kann die Konfiguration der Clients unverändert bleiben und der Konnektor wird als zusätzliches Gerät in das Netzwerk integriert und dem Router bekanntgemacht als Gateway für den sicheren Internetzugang und den Zugang zu den an die Telematikinfrastruktur angeschlossenen Bestandsnetze.
10.4.2 Voraussetzungen
- Konnektor ist kompatibel zur bestehenden Infrastruktur (Vernetzung)
- Verfügbarkeit einer SMC-B und mehrerer Kartenterminals
- Der Konnektor ist dem bestehenden Router als Gateway bekannt gemacht.
10.4.3 Auswirkungen
- Produkte der Telematik können „minimal-invasiv“ in die bestehende Infrastruktur integriert werden. Bestehende Kommunikationswege können weiter genutzt werden.
- Die Default-Gateway-Konfiguration der Clients muss nicht geändert werden.
10.5 Szenario 5: Zentral gesteckter HBA
Abbildung 28: Szenario mit zentral gesteckten HBA und SMC-B
10.5.1 Beschreibung des Szenarios
Dieses Szenario zeichnet sich dadurch aus dass ein HBA nicht durch seinen Inhaber mitgeführt und am Arbeitsplatz gesteckt wird, sondern zentral und geschützt vor unbefugten physischen Zugriffen gesteckt bleibt.
Der HBA-Inhaber greift über jeden konfigurierten Arbeitsplatz auf seinen HBA zu. Die Remote-PIN-Eingabe erfolgt unter Verwendung des lokal am Arbeitsplatz vorhandenen eHealth-Kartenterminals.
Die Mechanismen zum Zugriff auf eine zentral gesteckte SMC-B funktionieren analog zum HBA.
10.5.2 Voraussetzungen
Folgende zusätzliche Punkte müssen erfüllt sein, um dieses Szenario umzusetzen:
- Stecken der zentral gesteckten Karten HBA und SMC-B (ohne direkte Aufsicht) und Sicherstellung des Schutzes vor unbefugtem physischen Zugriff
- Konfiguration im Konnektor: Lokales eHealth-Kartenterminals als lokales eHealth-Kartenterminal für eine Remote-PIN-Eingabe eines bestimmten Arbeitsplatzes.
Im abgebildeten Beispiel KT-1 für Arbeitsplatz A und KT-2 für Arbeitsplatz B. - Konfiguration im Konnektor: Assoziation der gewünschten Arbeitsplätze zum jeweiligen Kartenterminal mit zentral gesteckter Karte.
Im abgebildeten Beispiel Arbeitsplatz A assoziiert mit dem eHealth-Kartenterminal des HBAs und Arbeitsplatz B mit eHealth-Kartenterminal des HBAs und dem eHealth-Kartenterminal der SMC-B.
10.5.3 Auswirkung
- HBA muss nicht mehr durch seinen Inhaber mitgeführt werden
- SMC-B muss nicht mehr unter ständiger Aufsicht eines Mitarbeiters einer Organisation des Gesundheitswesens sein.
10.6 Szenario 6: Installation mit zentralem PS
Abbildung 29: Szenario mit zentralem Primärsystem als Clientsystem
10.6.1 Beschreibung des Szenarios
Das Szenario skizziert eine dezentrale Konfiguration, bei der das Primärsystem aus einem Serveranteil „PS Server“ und mehreren Clientanteilen „PS Client“ besteht. Die Anbindung zwischen dem „PS Server“ und den „PS Clients“ ist herstellerspezifisch. Der „PS Server“ fungiert als ein einziges Clientsystem gegenüber der TI bzw. dem Konnektor (z.B. als Terminalserver). Die Clientsystemschnittstelle des Konnektors wird ausschließlich vom „PS Server“ genutzt. Der „PS Server“ muss bei der Kommunikation mit dem Konnektor eine Übersetzung der zugreifenden „PS Clients“ auf die entsprechende Entität „Arbeitsplatz“ des Konnektors durchführen
Beispielhaft zeigt das Szenario zwei Arbeitsplätze mit jeweils einem Kartenterminal für die eGK sowie zentral gesteckte SMC-B und HBAs. Alternativ sind auch lokal am Arbeitsplatz gesteckte HBAs möglich.
10.6.2 Voraussetzungen
- Netzanbindung aller Komponenten (u. a. KT, PS Client, PS Server, Konnektor) in der dezentralen Umgebung bis einschließlich zur Netzwerkschicht (IP-Ebene)
- Konfiguration des Primärsystems mit seinen Anteilen „PS Server“ und ggf. mehreren „PS Clients“ passend zum Informationsmodell des Konnektors (herstellerspezifisch).
- Konfiguration des Konnektors. U. a.:
- Informationsmodel:
Beim Beispielszenario u.a Entitäten „Clientsystem“ für „PS Server“, „Arbeitsplatz“ für „Arbeitsplatz 1“ und Arbeitsplatz 2“, „Kartenterminal“ und „KT-Slot“ für „KT 1“ – „KT 5“, „Mandat“ für die vorgesehene Anzahl von Mandaten, „SM-B_Verwaltet“ sowie entsprechende Entitätenbeziehungen. - Anbindung PS Server (ggf. über TLS)
- Pairing der Kartenterminals
- Gesteckte Karten (SMC-B, HBA, eGK)
- Anmeldung Nutzer am „PS Client“
10.6.3 Auswirkungen
- An den verschiedenen Arbeitsplätzen können für die definierten Mandaten und Nutzer Anwendungsfälle der TI initiiert werden.
- HBA-Inhaber müssen entsprechen der gewählten HBA-Deployment-Varianten
- ihren HBA zentral stecken und über das Remote-PIN-Verfahren zugreifen
- ihren HBA mit sich führen und lokal in Kartenterminal der Arbeitplätze stecken
10.7 Szenario 7: Mehrere Mandanten
Abbildung 30: Szenario für den Zugriff
10.7.1 Beschreibung des Szenarios
Das Szenario skizziert eine dezentrale Konfiguration, bei der mehrere Mandanten vorhanden sind, wobei jedem Mandant eine eigene SMC-B zugeordnet ist. Die SMC-Bs sind zentral zusammen mit dem Konnektor geschützt vor unbefugten physischen Zugriffen installiert. Die Komponenten Arbeitplätze, Clientsysteme und Kartenterminals müssen eine Zuordnung zum Mandanten haben, wobei Zuordnungen zu mehreren Mandaten möglich sind. Das Beispiel zeigt einen Arbeitplatz mit „Clientsystem 1“ und „KT 1“, der zu unterschiedlichen Zeiten durch verschiedene Mandaten verwendet wird. Zum Zeitpunkt T=t1 greift ein Anwender 1 mit HBA 1 über einen Anwendungsfall im Kontext Mandat 1 auf die TI zu, wobei der Versicherte 1 mit eGK 1 am Anwendungsfall beteiligt ist. Zum Zeitpunkt T=t2 wird ein anderer Anwendungsfall im Kontext von Mandat 2 durch einen Anwender 2 ohne HBA initiiert, wobei der Versicherte 2 mit eGK 2 am Anwendungsfall beteiligt ist. Das Clientsystem stellt hierbei den Mandantenbezug sowie die Nutzer Authentisierung sicher. Als Variante können auch mehrere Mandanten eine Zuordnung zu einer einzelnen SMC-B haben. Weiterhin können auch in diesem Szenario HBAs zentral gesteckt werden.
10.7.2 Voraussetzungen
- Netzwerkanbindung aller Komponenten (u. a. KT, Clientsystem, Konnektor) in der dezentralen Umgebung bis einschließlich zur Netzwerkschicht (IP-Ebene)
- Konfiguration der Clientsysteme („Clientsystem 1“), passend zum Informationsmodell des Konnektors (herstellerspezifisch).
- Konfiguration des Konnektors. U. a.:
- Konfiguration Konnektor:
Beim Beispielszenario u.a Entitäten „Clientsystem“ für „Clientsystem 1“, „Arbeitsplatz“ für „Arbeitsplatz 1“, „Kartenterminal“ und „KT-Slot“ für „KT 1“ – „KT 4“, „Mandat“ für „Mandant 1“ und „Mandant 2“, „SM-B_Verwaltet“ für „SMC-B 1“ und SMC-B 2“ sowie entsprechende Entitätenbeziehungen - Anbindung „Clientsystem 1“ (ggf. über TLS)
- Pairing der Kartenterminals
- Gesteckte Karten (SMC-B 1, SMC-B 2, HBA 1, eGK 1, eGK 2)
- Anmeldung eines Anwenders mit Mandantenbezug am Clientsystem
10.7.3 Auswirkungen
- An den verschiedenen Arbeitsplätzen können für die definierten Mandaten und Anwender Anwendungsfälle der TI initiiert werden.
- HBA-Inhaber müssen entsprechen der gewählten HBA-Deployment-Varianten
- ihren HBA zentral stecken und über das Remote-PIN-Verfahren zugreifen
- ihren HBA mit sich führen und lokal in Kartenterminal der Arbeitplätze stecken
10.8 Szenario 9: Standalone Konnektor - Physische Trennung
Abbildung 31: Standalone-Szenario mit physischer Trennung im Konnektor
10.8.1 Beschreibung des Szenarios
Dieses Szenario stellt eine Variante des Standalone-Szenarios dar, bei dem eine physische Trennung der Konnektoren eingesetzt wurde.
Im Standalone-Szenario besteht eine Trennung zwischen den Praxissystemen der dezentralen Umgebung, welche offline (also, ohne Anbindung an die zentrale TI-Plattform) betrieben werden und den für das Update der eGK durch die Fachanwendung VSDM notwendigen Komponenten, welche online (also, mit Verbindung in die zentrale TI-Plattform) betrieben werden.
Die physische Trennung im Standalone-Szenario zeichnet sich dadurch aus, dass getrennte Komponenten zum Einsatz kommen. Der Online-Konnektor ist mit der zentralen TI-Plattform verbunden und ermöglicht das VSDM Update der eGKs. Ein am Online-Konnektor angebundener Kommunikations-PC kann darüber hinaus über den sicheren Internetzugang der TI auf das Internet und über den VPN-Konzentrator TI auf Bestandsnetze zugreifen.
Sollten die Online-/Offline-Systeme nicht netztechnisch voneinander getrennt sein, so obliegt es dem Administrator der Praxissysteme sicherzustellen, dass die netztechnische Verbindung keine Gefährdung für die Praxissysteme zur Folge hat.
Im Offline-Konnektor sind einzelne Funktionen nicht verfügbar, andere haben einen eingeschränkten Funktionsumfang. So kann z.B. eine QES erzeugt oder geprüft aber dabei keine aktuelle Statusauskunft (OCSP-Response) für die eingesetzten Zertifikate eingeholt werden. Dies hat zur Folge, dass bei Erzeugung einer QES keine Statusauskunft für das Signaturzertifikat in die Signatur eingebettet werden kann und bei einer Prüfung der QES nur eine eventuell in die Signatur eingebettet Statusauskunft des Zertifikats berücksichtigt werden kann.
Der Nutzer muss in diesem Fall selber entscheiden ob der gebotene Funktionsumfang für seinen Anwendungsfall ausreichend ist.
10.8.2 Voraussetzungen
Folgende zusätzliche Punkte müssen erfüllt sein, um dieses Szenario umzusetzen:
- Konfiguration im Konnektor: Es muss konfiguriert werden, welche Komponenten von welchem Konnektor (online/offline) verwendet werden dürfen.
- Ein eHealth-Kartenterminal oder ein Arbeitsplatz darf immer nur mit einem der Konnektoren verbunden sein.
- Konfiguration im Konnektor: Im Offline-Konnektor wird kein VPN-Kanal konfiguriert.
- Clients bzw. Kommunikations-PC müssen sicherstellen, dass sie nur den jeweils richtigen Konnektor ansprechen.
- Es sollte eine netztechnische Trennung des Online- und Offline-Segmentes erfolgen. Wird dies nicht umgesetzt, dann obliegt es dem Administrator der Praxissysteme sicherzustellen, dass die netztechnische Verbindung keine Gefährdung für die Praxissysteme zur Folge hat.
Sollte keine netztechnische Trennung erfolgen, so kann nur einer der Konnektoren als DHCP-Server agieren. Es wird empfohlen hier den Offline-Konnektor zu verwenden, da dort tendenziell mehr Systeme angeschlossen sind. Die am Online-Konnektor angeschlossenen Systeme müssen dann direkt konfiguriert werden.
10.8.3 Auswirkung
- Erhöhter Aufwand durch separate Konnektoren und separate eHealth-Kartenterminals.
- Trennung der Praxissysteme von der zentralen TI-Plattform ist für den Leistungserbringer nachweislich sichergestellt.
- Eingeschränkte Funktionalität der TI für Praxissysteme (nur Offline-Funktionalität)
- Notwendige Prüfung des Leistungserbringers, ob eingeschränkte Funktionalität (insbesondere bei Sicherheitsfunktionen) akzeptabel ist.
- Sicherer Internetzugang der TI nur über den Kommunikations-PC nutzbar.
- Zugang zu Bestandsnetzen über den VPN-Konzentrator TI nur über den Kommunikations-PC nutzbar
11 Anhang L – Datentypen von Eingangs- und Ausgangsdaten
Tabelle 400: Aufzähltypen
Typname |
Werteliste |
---|---|
[Boolean] |
{true | false} |
[EncryptionType] |
{CMS | XMLEnc | S/MIME} |
[EventType] |
{Op | Sec | Perf} |
[EventSeverity] |
{Debug | Info | Warn | Err | Fatal} |
[KtOutputMode] |
{Input | OutputWait | OutputConfirm | OutputKeep | OutputErase} |
[PinStatus] |
{VERIFIED | VERIFYABLE | BLOCKED | TRANSPORT_PIN | EMPTY_PIN | DISABLED} |
[PinResult] |
{OK | REJECTED | BLOCKED | ERROR} |
[PukResult] |
{OK | REJECTED | BLOCKED | ERROR} |
[VerificationResult] |
{VALID | INVALID | INCONCLUSIVE} |