gemSpec_Basis_KTR_Consumer_V1.9.0_Aend

 

 

 

 

 

Elektronische Gesundheitskarte und Telematikinfrastruktur

 

 

 

 

Spezifikation

Basis- und KTR-Consumer

 

 

 

   

Version	1.89.0
Revision	965902966835
Stand	1214.08.2024
Status	freigegeben
Klassifizierung	öffentlich
Referenzierung	gemSpec_Basis_KTR_Consumer

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

Dokumentinformationen

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

1.2 Zielgruppe

1.3 Geltungsbereich

1.4 Abgrenzungen

1.5 Methodik

2 Systemüberblick

3 Systemkontext

4 Zerlegung der Produkttypen

4.1 Basisfunktionen

4.2 LDAP-Proxy

4.3 Clientmodul KOM-LE

5 Übergreifende Festlegungen

5.1 Anschluss an die TI

5.1.1 Anbindung per LAN/WAN

5.1.1.1 Funktionsmerkmalweite Aspekte

5.1.1.1.1 Netzwerksegmentierung

5.1.1.2 Durch Ereignisse ausgelöste Reaktionen

5.1.2 Zeitdienst

5.1.3 Namensdienst und Dienstlokalisierung

5.1.3.1 Funktionsmerkmalweite Aspekte

5.1.3.2 Interne TUCs, auch durch Fachmodule nutzbar

5.1.3.2.1 TUC_CON_362 „Liste der Dienste abrufen“

5.1.3.3 Operationen an der Clientsystemschnittstelle

5.1.3.4 Betriebsaspekte

5.2 Sicherheit

5.3 Identitäten

5.4 Schnittstellen

6 Funktionsmerkmale

6.1 Verschlüsselungsdienst

6.1.1 Durch Module nutzbare TUCs

6.1.2 Operationen an der Clientsystemschnittstelle

6.1.2.1 EncryptDocument

6.1.2.2 DecryptDocument

6.2 Signaturdienst

6.2.1 Durch Module nutzbare TUCs

6.2.2 Operationen an der Clientsystemschnittstelle

6.2.2.1 SignDocument

6.2.2.2 VerifyDocument

6.2.2.3 ExternalAuthenticate

6.3 Zertifikatsdienst

6.3.1 Durch Module nutzbare TUCs

6.3.2 Operationen an der Clientsystemschnittstelle

6.3.2.1 ReadCertificate

6.3.2.2 VerifyCertificate

6.4 LDAP-Proxy

6.4.1 Durch Module nutzbare TUCs

6.4.2 Unterstützte LDAPv3-Operationen an der Clientsystemschnittstelle

6.5 Clientmodul KOM-LE

6.5.1 Allgemeine Anforderungen

6.5.2 Senden von Nachrichten1.1 Eingeschaltete ECC-preferred-Funktionalität

6.5.3 Empfangen von Nachrichten1.2 Ausgeschaltete ECC-preferred-Funktionalität

6.6 Realisierung der Leistungen der TI-Plattform5.2 Senden von Nachrichten

6.65.1 Schnittstelle für Kartenkommandos3 Empfangen von Nachrichten

6.6.2 Schnittstelle für PIN-Operationen und Anbindung der Karten der TI Realisierung der Leistungen der TI-Plattform

7 Anhang A - Verzeichnisse6.6.1 Schnittstelle für Kartenkommandos

76.1 Abkürzungen6.2 Schnittstelle für PIN-Operationen und Anbindung der Karten der TI

7.2 Glossar Anhang A - Verzeichnisse

7.3 Abbildungsverzeichnis1 Abkürzungen

7.4 Tabellenverzeichnis2 Glossar

7.5 Referenzierte Dokumente3 Abbildungsverzeichnis

7.5.1 Dokumente der gematik4 Tabellenverzeichnis

7.5.2 Weitere Referenzierte Dokumente

8 Anhang B – Übersicht über die verwendeten Versionen7.5.1 Dokumente der gematik

9 Anhang C – Übersicht der genutzten Systemprozesse7.5.2 Weitere Dokumente

8 Anhang B – Übersicht über die verwendeten Versionen

9 Anhang C – Übersicht der genutzten Systemprozesse

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen an Herstellung, Test und Betrieb der beiden Produkttypen Basis-Consumer und KTR-Consumer.

Der Basis-Consumer und der KTR-Consumer sind Produkttypen der TI-Plattform, die in der Rolle eines Consumers mit der Telematikinfrastruktur (TI) interagieren und dabei sowohl Anteile der TI-Plattform als auch Anteile des sicheren Übermittlungsverfahrens KOM-LE (beim Basis-Consumer) enthalten. Der KTR-Consumer enthält darüber hinaus auch Fachmodule, die einem Nutzerkreis „Kostenträger“ die Teilnahme an den dafür vorgesehenen Fachanwendungen der Telematikinfrastruktur ermöglichen.

1.2 Zielgruppe

Das Dokument ist maßgeblich für Anbieter und Hersteller des Produkttyps Basis- und KTR-Consumer sowie für Anbieter und Hersteller von Produkten, die die Schnittstellen des Produkttyps Basis- und KTR-Consumer nutzen.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z.B. gemPTV_ATV_Festlegungen, Produkttypsteckbrief, Leistungsbeschreibung) fest­gelegt und bekannt gegeben.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzungen

Spezifiziert werden in dem Dokument die von den Produkttypen Basis- und KTR-Consumer  bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe auch Anhang A5).

Die vollständige Anforderungslage für die Produkttypen ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in den Produkttypsteckbriefen des Produkttyps Basis- bzw. KTR-Consumer verzeichnet.

1.5 Methodik

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 zwischen der ID und der Textmarke angeführten Inhalte.

2 Systemüberblick

Die Produkttypen Basis- und KTR-Consumer sind beides Realisierungen des konzeptionellen Konstrukts „RZ-Consumer“ aus [gemKPT_Arch_TIP]. D.h., sie agieren als Consumer in der Telematikinfrastruktur (TI), nutzen dabei zentrale Dienste, die Dienste des sicheren Übermittlungsverfahrens und ggf. fachanwendungsspezifische Dienste und werden in einem Rechenzentrum entsprechend den Vorgaben der TI betrieben. Beide Produkttypen bieten für externe Clients eine Menge von Basisfunktionen (z.B. kryptographische Operationen), ermöglichen den Zugriff auf weitere Anwendungen des Gesundheitswesens und die Nutzung des sicheren Übermittlungsverfahrens KOM-LE (beim Basis-Consumer).

Der Basis-Consumer ermöglicht es den berechtigten Organisationen des Gesundheitswesens an der KIM-Kommunikation in der TI teilzunehmen. Der Zugriff auf Fachanwendungen der TI ist dieser Nutzergruppe nicht gestattet. Der Produkttyp enthält demnach zwar keine Fachmodule, aber ein Clientmodul KOM-LE zur Nutzung des sicheren Übermittlungsverfahrens. Auf technischer Ebene wird die jeweilige Nutzergruppe durch die kryptographische Identität der SMC-B Org oder SMC-B KTR (jeweils auf Basis oid_kostenträger) identifiziert, die in einem HSM oder auf einer Karte gespeichert wird.

Der KTR-Consumer ermöglicht es Kostenträgern, als Nutzer an der TI teilzunehmen. Durch enthaltene Fachmodule können dabei Fachanwendungen, bei der die Kostenträger als berechtigte Nutzer festgelegt sind (mit Ausnahme von VSDM), und die weiteren Anwendungen des Gesundheitswesens genutzt werden. Auf technischer Ebene wird die Nutzergruppe durch kryptographische Identitäten der SMC-B KTR (auf Basis oid_kostenträger und oid_epa_ktr) identifiziert, die in einem HSM gespeichert werden.

3 Systemkontext

Nachfolgend wird angelehnt an den Systemüberblick aus [gemKPT_Arch_TIP] die Einbettung der Produkttypen Basis-Consumer und KTR-Consumer in das System der TI dargestellt. Die Darstellung ist reduziert auf die Produkttypen der TI sowie Clients und Anwendungen außerhalb der TI, mit denen potentiell eine Interaktion stattfindet. Die Festlegungen des vorliegenden Dokuments beziehen sich auf die Produkttypen Basis-Consumer und KTR-Consumer als Ganzes und das logische Konstrukt des Consumer-Adapters aus [gemKPT_Arch_TIP], das den Umfang der Basisfunktionen der Produkttypen festlegt.

Unter "SM-B Basis-Consumer" wird in der Abbildung 1 eine Identität verstanden, die Zertifikate gemäß [gemSpec_PKI] enthält.
Unter "SM-B KTR-Consumer" wird in der Abbildung 1 eine Identität verstanden, die Zertifikate gemäß [gemSpec_PKI] mit der OID <oid_epa_ktr> gemäß [gemSpec_OID#GS-A_4443-01] im Feld "extensions -> Admission -> professionOID" enthält.

Abbildung 1: Systemkontext für Basis- und KTR-Consumer

4 Zerlegung der Produkttypen

Der Produkttyp Basis-Consumer teilt sich in die folgenden Bestandteile auf:

• Basisfunktionen,
• LDAP-Proxy und
• Clientmodul KOM-LE

Der Produkttyp KTR-Consumer teilt sich in die folgenden Bestandteile auf:

• Fachmodul ePA im KTR-Consumer,
• Basisfunktionen (optional) und
• LDAP-Proxy (optional)

Die Festlegungen der vorliegenden Dokuments beziehen sich auf die Produkttypen Basis-Consumer und KTR-Consumer als Ganzes sowie deren oben aufgeführten Bestandteile, mit Ausnahme des Fachmoduls ePA und des Clientmoduls KOM-LE, welche in [gemSpec_FM_ePA_KTR_Consumer], bzw. [gemSpec_CM_KOMLE], beschrieben sind. Das logische Konstrukt des Consumer-Adapters aus [gemKPT_Arch_TIP], wird durch die Basisfunktionen und den LDAP-Proxy in dem für die Produkttypen benötigten Umfang umgesetzt.

Einige Anforderungen des vorliegenden Dokuments, sowie der Spezifikationen des Clientmoduls und des Fachmoduls, sind nur in Abhängigkeit einer konkreten Produktausprägung verpflichtend umzusetzen. Die Kennzeichnung dieser Anforderungen ist Bestandteil der jeweiligen Produtkttypsteckbriefe des Basis- oder KTR-Consumers.

4.1 Basisfunktionen

Die Basisfunktionen enthalten:

• den Verschlüsselungsdienst zum Ver- und Entschlüsseln von Dokumenten
• den Signaturdienst zum Signieren und Signaturprüfen
• den Zertifikatsdienst, um Zertifikate zu überprüfen
• netztechnische Anbindung an die Telematikinfrastruktur (Interface, Firewall und DNS)

4.2 LDAP-Proxy

Der Basis- und KTR-Consumer ermöglicht es Clientsystemen und Clientmodulen durch Nutzung des LDAP-Proxies Daten aus dem Verzeichnisdienst der TI-Plattform (VZD) abzufragen. Die Kommunikation erfolgt über das LDAPv3-Protokoll.

4.3 Clientmodul KOM-LE

Der Basis-Consumer enthält ein Clientmodul KOM-LE, um das sichere Übermittlungsverfahren KOM-LE nutzen zu können. Es werden die Anwendungsfälle „Senden und Empfangen von Nachrichten“ unterstützt. Die Spezifikation [gemSpec_CM_KOMLE] gilt in großen Teilen auch für den Basis-Consumer. Es gibt aber verschiedene Bereiche, in denen eine Anpassung für den Basis-Consumer erforderlich ist. Für diese Bereiche werden neue Anforderungen aufgenommen, die statt der bestehenden Anforderungen aus [gemSpec_CM_KOMLE] zu verwenden sind. Die Bereiche sind:

• Nutzung des Basis-Consumers
  Die Spezifikation des Clientmoduls [gemSpec_CM_KOMLE] schreibt an einigen Stellen die Nutzung des  Konnektors für Signatur/Signaturprüfung und Ver-/Entschlüsselung vor.  Diese Anforderungen werden ersetzt durch Anforderungen, die die Nutzung der Systemprozesse im Basis-Consumer vorschreiben.
• Clientsystemschnittstelle des Moduls
  Die SMTP/POP3-Schnittstelle des Clientmoduls soll beibehalten werden. Abweichend von [gemSpec_CM_KOMLE] werden die Informationen bzgl. der Adresse und des Ports des Mail Transfer Agents (MTA, KOM-LE Fachdienst) und die Informationen des Aufrufkontext nicht beim Aufruf mitgegeben, sondern im Basis-Consumer lokal konfiguriert.

5 Übergreifende Festlegungen

5.1 Anschluss an die TI

5.1.1 Anbindung per LAN/WAN

Unter Anbindung per LAN/WAN werden die Mechanismen beschrieben, mit denen der Basis- und KTR-Consumer auf der einen Seite in das lokale Netz der Einsatzumgebung und auf der anderen Seite in die zentrale TI sowie WANDA Basic und die WANDA Smart angebunden wird. Diese wesentlichen Aspekte betreffen Routing und Firewall.

5.1.1.1 Funktionsmerkmalweite Aspekte

A_17396 - Verhalten als IPv4-Router

Der Basis- und KTR-Consumer MUSS sich nach den in [RFC1812#1.1.3] definierten Rahmenbedingungen als IP-Version-4-(IPv4)-Router verhalten. Die in [RFC2644] geforderten Aktualisierungen zum [RFC1812] MÜSSEN umgesetzt werden. [<=]

A_17397-01 - IP-Pakete mit Source Route Option

Der Basis- und KTR-Consumer als Produkt oder dessen Anbieter über die Betriebsumgebung MUSS durchsetzen, dass keine IP-Pakete mit gesetzter Source Route Option gemäß [RFC791] erzeugt oder weitergeleitet werden. In beiden Sicherheitsnachweisen muss klar dargestellt werden, wo die Sicherheitsleistung umgesetzt ist. [<=]

A_17400-02 - NAT-Umsetzung

Der Basis- und KTR-Consumer als Produkt oder dessen Anbieter über die Betriebsumgebung MUSS für die Kommunikation mit Adressbereichen der TI sowie WANDA Basic und WANDA Smart eine Network Address Translation (NAT) 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 verwendete IP-Adresse aus dem vom Anbieter Zentrale Plattform Dienste (AZPD) bereitgestellten Adress-Pool entnommen werden und als Global Address genutzt werden. [<=]

A_17405-01 - Nur IPv4. IPv6 nur hardwareseitig vorbereitet

Der Basis- und KTR-Consumer als Produkt oder dessen Anbieter über die Betriebsumgebung MUSS die IP Version 4 (IPv4) für alle seine IP-Schnittstellen unterstützen. Die eingesetzte Hardware 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 Basis- und KTR-Consumer als Produkt oder dessen Anbieter über die Betriebsumgebung sämtliche empfangenen IP-Pakete der Version 6 (IPv6) verwerfen. In beiden Sicherheitsnachweisen muss klar dargestellt werden, wo die Sicherheitsleistung umgesetzt ist. [<=]

Die Anbindung des Basis- und KTR-Consumers an die zentrale TI erfolgt über einen Sicheren Zentralen Zugangspunkt (SZZP), siehe [gemSpec_Net#3.1.1]. Dieser Produkttyp unterstützt kein dynamisches Routing.

A_17406-01 - Kein dynamisches Routing

Basis- und KTR-Consumer als Produkt oder dessen Anbieter über die Betriebsumgebung MUSS durchsetzen, dass nicht Dynamische Routing-Protokolle eingesetzt werden. In beiden Sicherheitsnachweisen muss klar dargestellt werden, wo die Sicherheitsleistung umgesetzt ist.  [<=]

5.1.1.1.1 Netzwerksegmentierung

In Anlehnung an die in der [gemSpec_Net#2.3.3] definierten Netzwerksegmente werden in der Basis- und KTR-Consumerspezifikation die folgenden Bezeichner verwendet:

Tabelle 1: Mapping der Netzwerksegmente

ReferenzID im Basis- und KTR-Consumer	Adressbereich für die TI-Produktivumgebung	Adressbereich für die TI-Testumgebung	Adressbereich für die TI-Referenzumgebung
NET_TI_ ZENTRAL	TI_Zentral - Zentrale Dienste	TI_Test_Zentral - Zentrale Dienste	Ist durch den Testbetriebsverantwortlichen zu definieren.
NET_TI_ GESICHERTE_ FD	TI_Fachdienste - Gesicherte Fachdienste	TI_Test_Fachdienste - Gesicherte Fachdienste	Ist durch den Testbetriebsverantwortlichen zu definieren.
NET_TI_OFFENE_FD	TI_Fachdienste - Offene Fachdienste	TI_Test_Fachdienste - Offene Fachdienste	Ist durch den Testbetriebsverantwortlichen zu definieren.
NET_WANDA_Smart	WANDA Smart	WANDA Smart	WANDA Smart
NET_CONSUMER	Liste der Netzwerke die in der Einsatzumgebung über den Basis- und KTR-Consumer erreichbar sind. Ein Eintrag der Liste enthält die Netzwerkadresse und den Netzwerkpräfix.
NET_WANDA_Basic	WANDA Basic	WANDA Basic	WANDA Basic

A_17411-01 - Kommunikation mit NET_TI_Offene_FD

Der Basis- und KTR-Consumer als Produkt oder dessen Anbieter über die Betriebsumgebung MUSS sicherstellen, dass IP-Pakete mit dem Ziel NET_TI_Offene_FD und NET_WANDA_Smart weitergeleitet werden. [<=]

A_17514-01 - Kommunikation mit NET_TI_Gesicherte_FD

Der KTR-Consumer als Produkt oder dessen Anbieter über die Betriebsumgebung MUSS sicherstellen, dass IP-Pakete mit dem Ziel NET_TI_Gesicherte_FD nur durch das im KTR-Consumer vorhandene jeweilige Fachmodul in Richtung TI mit dem Ziel NET_TI_Gesicherte_FD weitergeleitet werden. In beiden Sicherheitsnachweisen muss klar dargestellt werden, wo die Sicherheitsleistung umgesetzt ist. [<=]

A_17415-01 - Kommunikation mit NET_TI_ZENTRAL

Der Basis- und KTR-Consumer als Produkt oder dessen Anbieter über die Betriebsumgebung MUSS sicherstellen, dass IP-Pakete in Richtung NET_TI_ZENTRAL ausschließlich vom Basis- und KTR-Consumer ausgehen. In beiden Sicherheitsnachweisen muss klar dargestellt werden, wo die Sicherheitsleistung umgesetzt ist. [<=]

A_21998-01 - Kommunikation mit NET_WANDA_Basic

Der Basis- und KTR-Consumer als Produkt oder dessen Anbieter über die Betriebsumgebung MUSS sicherstellen, dass IP-Pakete mit dem Ziel NET_WANDA_Basic weitergeleitet werden. [<=]

A_17417-01 - Einschränkung von nicht genehmigten Traffic

Der Basis- und KTR-Consumer als Produkt oder dessen Anbieter über die Betriebsumgebung MUSS nicht genehmigten Traffic blockieren und dabei folgendes umsetzen:

• "default deny"
• Einschränkung auf IP-Protokolle 1 (ICMP; eingeschränkt auf Typ 8 und Typ 0 und ausschließlich für, per Anforderung genehmigten, Traffic), 17 (UDP) und 6 (TCP)
• Einschränkung auf genau nur die Ports die für den Betrieb unerlässlich sind
• abgelehnten IP-Pakete verwerfen (DROP), ohne ein ICMP-Destination-Unreachable (Type 3) zu schicken
• Maßnahmen zur Erkennung und Behebung unberechtigter oder verdächtiger Netzwerkaktivitäten (bspw. über Korrelation und Auswertung von Log-Daten).

In beiden Sicherheitsnachweisen muss klar dargestellt werden, wo die Sicherheitsleistung umgesetzt ist.
[<=]

Umsetzungshinweis für den Hersteller: Es können zwei getrennten Firewall-Regelsets für den LAN- bzw. für den WAN-Adapter verwendet werden.

A_17424-01 - Firewall-Protokollierung

Der Basis- und KTR-Consumer als Produkt oder dessen Anbieter über die Betriebsumgebung MUSS an der Firewall folgende Aktivitäten nachvollziehbar protokollieren:

• Konfigurationsänderungen der Firewall

• Zeitstempel, Aktion (Add/Delete/Change), Details (Beschreibung der Änderung), Auslöser (Prozess/User).

• von der Firewall verworfene IP-Pakete, wobei Layer 3 Broadcasts von der Protokollierung ausgenommen werden können

In beiden Sicherheitsnachweisen muss klar dargestellt werden, wo die Sicherheitsleistung umgesetzt ist. [<=]

5.1.1.2 Durch Ereignisse ausgelöste Reaktionen

A_17425 - Reagiere auf LAN_IP_Changed

Wurde die IP Adresse des LAN Interfaces geändert oder hat, bei aktiven DHCP Client, ein erfolgreiches DHCP_RENEW stattgefunden MUSS der Basis- und KTR-Consumer den LAN-Adapter initialisieren. [<=]

A_17426 - Reagiere auf WAN_IP_Changed

Wurde die IP Adresse des WAN Interfaces geändert oder hat, bei aktiven DHCP Client, ein erfolgreiches DHCP_RENEW stattgefunden MUSS der Basis- und KTR-Consumer den WAN-Adapter initialisieren. [<=]

A_17430 - Netzwerk-Routen einrichten

Der Basis- und KTR-Consumer MUSS die Konfiguration aller notwendigen Netzwerk-Routen ermöglichen. [<=]

A_17474-01 - Anzeige IP-Routinginformationen

Der Basis- und KTR-Consumer MUSS über eine Schnittstelle die konfigurierten IP-Routen und die aktuelle IP-Routingtabelle mit mindestens folgenden Informationen anzeigen:

• Forwarding Status
• Zieladresse/Präfix
• Gateway (Next-Hop)
• Routing Typ
• Routing Preference.

[<=]

Zur Bekanntmachung von Änderungen und Neuanschlüssen zu den, an die TI angeschlossenen, weiteren Anwendungen des Gesundheitswesens für den Datenaustausch (WANDA Smart) wird tagesaktuell eine Datei mit dem Namen "Bestandsnetze.xml" bereitgestellt (siehe dazu [gemSpec_KSR#9/Anhang C]). Die Datei liefert für alle angeschlossenen WANDA Smart einen Namen/ID, Netzwerkinformationen (IP-Adressen) und den für dieses Netz zu verwendenden DNS Server welcher dem DNS Forwarder des Basis- und KTR-Konsumer übergeben wird.

A_17576 - KSR lokalisieren

Der Basis- und KTR-Consumer MUSS für die Lokalisierung des Konfigurationsdienstes der TI (KSR) die Möglichkeit der Lokalisierung des KSR durch DNS-Anfragen an den DNS-Forwarder DNS_SERVERS_TI zur Auflösung der SRV-RR und TXT-RR mit den Bezeichnern „_ksrkonfig._tcp.ksr.<TOP_LEVEL_DOMAIN_TI>“ vorsehen.
Der Basis- und KTR-Consumer erhält damit URLs der Downloadpunkte des KSR für Konfigurationsdaten (MGM_KSR_KONFIG_URL). [<=]

A_17574 - Infrastruktur Konfiguration aktualisieren

Der Basis- und KTR-Consumer MUSS täglich seine Infrastruktur Konfiguration aktualisieren.
Der Basis- und KTR-Consumer MUSS dazu eine TLS-Verbindung zum Konfigurationsdienst der TI aufbauen. Dabei MUSS er das durch den Server präsentierte Zertifikat prüfen.
Das Herunterladen der Konfigurationsdaten erfolgt mittels I_KSRS_Download::get_Ext_Net_Config (MGM_KSR_KONFIG_URL, „Bestandsnetze.xml“.) [<=]

5.1.2 Zeitdienst

Der Zeitdienst schafft die Grundlage einer gleichen Systemzeit für alle in der TI einzusetzenden Produkttypen. Innerhalb des Basis- und KTR-Consumers ist dafür ein NTP-Client erforderlich, welcher die Zeitangaben des Zeitdienstes der zentralen TI abfragt und verwendet. Die in [gemSpec_Net#6.2.2] „Nutzung“ getroffenen Anforderungen werden durch dieses Kapitel erweitert.

A_17485 - Maximale Zeitabweichung

Der Basis- und KTR-Consumer MUSS sicherstellen, 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. [<=]

5.1.3 Namensdienst und Dienstlokalisierung

5.1.3.1 Funktionsmerkmalweite Aspekte

A_17498 - Grundlagen des Namensdienstes

Der Basis- und KTR-Consumer MUSS die Funktion eines Recursive Caching Nameservers zur Auflösung von DNS-Anfragen anbieten. (Im Folgenden kurz DNS-Server genannt).
Der Caching-Nameserver des Basis- und KTR-Consumer MUSS für Clientsysteme aus dem lokalen Netzwerk der Einsatzumgebung erreichbar sein.
Der Caching Nameserver des Basis- und KTR-Consumer MUSS einen sinnvollen Timeout für die Bearbeitung von DNS-Abfragen beachten. Konnte eine DNS-Abfrage nicht durchgeführt werden, MUSS die Bearbeitung abgebrochen werden.  [<=]

A_17499 - DNS-Forwards des DNS-Servers

Der DNS-Server des Basis- und KTR-Consumer MUSS die folgenden DNS-Forwards durchführen:
 

Tabelle 2 : TAB_CONS_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.
Namensraum angeschlossene Netze des Gesundheitswesens mit WANDA Basic (Domainnamen von angeschlossenen Netzen des Gesundheitswesens mit WANDA Basic gemäß Bestandsnetze.xml)	DNS_SERVERS_BESTANDSNETZE (Je Domainnamen eines angeschlossenen Netzes des Gesundheitswesens mit WANDA Basic alle zugehörigen DNS-Server IP-Adressen gemäß Bestandsnetze.xml)	Je angeschlossenem Netz des Gesundheitswesens mit WANDA Basic in NLW_AKTIVE_BESTANDSNETZE wird eine DNS Forward Rule zur Auflösung von DNS-Namen innerhalb dieses Netzes verwendet.
Namensraum lokale Einsatzumgebung	DNS_SERVERS_CONSUMER	DNS Forward Rule zur Auflösung aller DNS-Namen innerhalb der DNS-Domain im LAN des Consumer

[<=]

A_17500 - DNS Stub-Resolver

Der Basis- und KTR-Consumer MUSS von allen internen Diensten zur Namensauflösung genutzt werden.
Der Stub-Resolver im Basis- und KTR-Consumer MUSS immer den Caching Nameserver im Basis- und KTR-Consumer anfragen. [<=]

5.1.3.2 Interne TUCs, auch durch Fachmodule nutzbar

5.1.3.2.1 TUC_CON_362 „Liste der Dienste abrufen“

A_17502 - TUC_CON_362 „Liste der Dienste abrufen“

Der Basis- und KTR-Consumer MUSS den technischen Use Case TUC_CONS_362 „Liste der Dienste abrufen“ umsetzen.
 

Tabelle 3: TAB_CONS_648 – TUC_CONS_362 „Liste der Dienste abrufen“

[<=]

5.1.3.3 Operationen an der Clientsystemschnittstelle

A_17509 - Basisanwendung Namensdienst

Der Basis- und KTR-Consumer MUSS für Clients  in der Einsatzumgebung und den Fachmodulen im jeweiligen Consumer eine Basisanwendung Namensdienst, mit der Funktion Namensauflösung und Dienstlokalisierung anbieten.
 

Tabelle 4: Basisanwendung Namensdienst

Name	Namensdienst
Version	wird im Produktsteckbrief des Basis- und KTR-Consumer 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

[<=]

5.1.3.4 Betriebsaspekte

A_17512-01 - Initialisierung „Namensdienst und Dienstlokalisierung“

DerBasis- und KTR-Consumer MUSS in der Bootup-Phase zur Initialisierung des Funktionsmerkmals „Namensdienst und Dienstlokalisierung“ den Caching-Nameserver starten.
[<=]

A_17513-01 - Konfigurationsparameter Namensdienst und Dienstlokalisierung

Der Administrator des Basis- und KTR-Consumer MUSS die aufgelisteten Parameter in Tabelle 5 über eine Schnittstelle konfigurieren und die aufgelisteten Parameter in Tabelle 6 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 5: Konfigurationsparameter Namensdienst

ReferenzID	Belegung	Bedeutung und Administrator-Interaktion
DNS_SERVERS_ CONSUMER	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_CONSUMER 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_ CONSUMER	DNS Domainname	DNS Domainname, der von einem DNS-Server der Einsatzumgebung aufgelöst wird. Der Name DARF NICHT mit einem „.“ beginnen.

Tabelle 6: 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_TOP_LEVEL_ DOMAIN_TI	DNS Domainname	Top Level Domain des Namensraumes TI

[<=]

5.2 Sicherheit

Die Sicherheits- und Datenschutzanforderungen sind abgedeckt durch die übergreifenden Sicherheits- und Datenschutzanforderungen an Hersteller und Anbieter [gemSpec_DS_Hersteller], [gemSpec_DS_Anbieter], die spezifischen Sicherheits- und Datenschutzanforderungen des Clientmoduls KOM-LE im Basis-Consumer [gemSpec_CM_KOMLE] und des Fachmoduls ePA im KTR-Consumer [gemSpec_FM_ePA_KTR_Consumer] sowie die spezifischen Sicherheits- und Datenschutzanforderungen der Systemprozesse der dezentralen TI [gemSpec_Systemprozesse_dezTI].

5.3 Identitäten

In diesem Dokument werden kryptographische Identitäten entsprechend ihrer Bezeichner im Objektsystem der SMC-B referenziert. Dies dient der Eindeutigkeit der Referenz und bedeutet nicht, dass die Strukturen des Objektsystems der SMC-B in einem HSM nachgebildet werden müssen.

Im KTR-Consumer werden private Schlüssel der SMC-B in einem HSM gespeichert. Im Basis-Consumer werden private Schlüssel der SMC-B in einem HSM oder auf einer SMC-B in Kartenform gespeichert. Das Schlüsselmaterial des KOM-LE-Clientmoduls hingegen wird auch hier in einem HSM gespeichert.

Nachfolgend wird festgelegt, welche Qualitäten dabei erreicht werden müssen und was bei der Personalisierung zu beachten ist.

A_17598 - Qualität des HSM

Die Basis- und KTR-Consumer MÜSSEN privates Schlüsselmaterial zu Zertifikaten der Telematikinfrastruktur in einem HSM, dessen Eignung durch eine erfolgreiche Evaluierung nachgewiesen wurde, integritätsgeschützt und vertraulich speichern. Als Evaluierungsschema kommen dabei Common Criteria oder Federal Information Processing Standard (FIPS) in Frage. Die Prüftiefe MUSS mindestens (a) FIPS 140-2 Level 3, oder (b) Common Criteria EAL 4 entsprechen. [<=]

A_24024 - HSM - Sicherer Zugriff auf Identitäten

Der Basis- und KTR-Consumer MUSS private Schlüssel der TI-Identitäten der Nutzer des Consumers im HSM eindeutig referenzieren und durchsetzen, dass Nutzer des Consumers jeweils genau nur Ihre Identitäten (private Schlüssel) verwenden können. [<=]

A_24025 - Authentisierte, vertrauliche und integritätsgeschützte Kommunikation

Der Basis- und KTR-Consumer MUSS durchsetzen, dass Operationsaufrufe zu einem HSM nur nach Authentisierung gegenüber dem HSM und unter Wahrung von Vertraulichkeit und Integrität stattfinden, sodass Unberechtigte weder Schlüssel auf dem HSM nutzen können, noch die Kommunikation mit dem HSM abhören oder manipulieren können. Die Maßnahmen dienen primär dem sicheren Betrieb des HSMs, MÜSSEN aber ebenso eine sichere Personalisierung (A_17599*) ermöglichen bzw. unterstützen. [<=]

A_18195 - Basis-Consumer mit SMC-B

Der Basis-Consumer KANN privates Schlüsselmaterial einer SMC-B in Kartenform nutzen. [<=]

Tabelle 7: Tab_Personalisierung_HSM – Personalisierung des HSM

Aspekt	Beschreibung
Schlüsselmaterial der SMC-B	Das Schlüsselmaterial wird sicher im HSM erzeugt. Das private Schlüsselmaterial verlässt das HSM nicht oder nur zum Zwecke eines Backups auf einem Backup-HSM, wobei die Übertragung hinsichtlich Vertraulichkeit geschützt sein muss.
Zertifikatsrequest	Die benötigten Zertifikatsrequests werden im HSM erzeugt und exportiert. Die Zertifikatsrequests werden unter Wahrung der Authentizität und Integrität dem TSP übermittelt.
Zertifikat	Das Zertifikat wird vom TSP zum Betreiber übermittelt.

Hinweis:

• Ein Basis-Consumer verwendet SM(C)-B-ORG-Schlüsselmaterial gemäß [gemSpec_PKI#10.6] mit Ausnahme des Basis-Consumers für Kostenträger, der SM(C)-B-KTR Schlüsselmaterial gemäß [gemSpec_PKI#10.4] mit der ProfessionOID „oid_kostentraeger“ verwendet.
• Ein Basis-Consumer für Kostenträger verwendet SMC-B-KTR Schlüsselmaterial gemäß [gemSpec_PKI#10.4]. Dieses kann in den Ausprägungen oid_kostentraeger oder oid_ombudsstelle auftreten.
• Ein KTR-Consumer verwendet SM(C)-B-KTR Schlüsselmaterial gemäß [gemSpec_PKI#10.4] mit der ProfessionOID „oid_epa_ktr“.
• Ein KTR-Consumer benötigt das Schlüsselmaterial der ProfessionOID „oid_kostentraeger“ nicht.

A_17599 - Personalisierung des HSM

Der Anbieter des Basis- oder KTR-Consumers MUSS einen sicheren Prozess zur Personalisierung des HSMs definieren und etablieren, der die in Tab_Personalisierung_HSM genannten Aspekte beinhaltet. [<=]

A_24026 - Der Anbieter des Basis- oder KTR-Consumers SOLL private Schlüssel für KIM-CM-TLS...

Der Anbieter des Basis- oder KTR-Consumers SOLL private Schlüssel für KIM-CM-TLS-Zertifikate vor unberechtigtem Zugriff geschützt im HSM (siehe A_17598*) speichern, nachdem er sie vom KIM-Anbieter erhalten hat.
[<=]

Eine Abweichung von Anforderung A_24026* ist gestattet für den Fall, dass entsprechend A_18195* kein HSM eingesetzt wird.

A_18196 - Personalisierung des HSM beim Basis-Consumer

Der Anbieter eines Basis-Consumers, der ausschließlich mit SMC-Bs in Kartenform arbeitet, KANN auf einen Prozess zur Personalisierung der Identitäten der SMC-B im HSM verzichten. [<=]

A_25030 - Informierte Identitätswahl bei Nutzung von Operationen mit CardHandle Parameter

Der Anbieter des Basis- und KTR-Consumer MUSS sicherstellen, dass dem clientseitigen Nutzer jederzeit die Möglichkeit zur Verfügung gestellt wird zu wählen, mit welcher der ihm zugeordneten Identitäten die Consumer Operationen aufgerufen werden. Dabei MÜSSEN dem Nutzer eindeutig für jede Identität die in TAB_CardHandle_Map enthaltenen Informationen zugeordnet werden.
Ungültige oder vom Identitätsträger (HSM) entfernte Identitäten DÜRFEN dem Nutzer dabei NICHT zur Verfügung gestellt werden.

Tabelle 8: TAB_CardHandle_Map

Information	Beschreibung
CardHandle	Handle, mit dem die Identität in Folgeaufrufen adressiert werden kann. Der Anbieter garantiert, dass dieses Handle die Identität eindeutig identifiziert und bei Entfernen der Identität vom Identitätsträger (HSM) ungültig wird.
Typ der Identität	Mögliche Werte sind: SM-B-KTR SM-B-ORG SMC-B-KTR SMC-B-ORG
Name des Identitätsinhabers bzw. der Institution/Organisation	subject.commonName aus [gemSpec_OID#10.10] bzw. [gemSpec_OID#10.4]
Profession OID	professionOID nach [gemSpec_OID#10.10] bzw. [gemSpec_OID#10.4] (extensions.admission.professionOID)
Telematik-ID	Telematik-ID nach [gemSpec_OID#10.10] bzw. Telematik-ID nach [gemSpec_OID#10.4] (extensions.admission.registrationNumber)

[<=]

5.4 Schnittstellen

Für den Basis- und KTR-Consumer werden einheitliche Schnittstellen definiert und im Rahmen des Zulassungstests genutzt. Für eine bessere Integrationsfähigkeit ist es aber erlaubt, dass zusätzlich zu den definierten Schnittstellen auch weitere Schnittstellentechnologien genutzt werden können, über welche die festgelegten Operationen angesprochen werden können.

A_17712 - Zusätzlich alternative Schnittstellentechnologien

Der Basis- und KTR-Consumer KANN zusätzlich zu den in den Spezifikationen festgelegten Schnittstellen zusätzlich weitere Schnittstellentechnologien anbieten, über welche die festgelegten Operationen angesprochen werden können. [<=]

6 Funktionsmerkmale

6.1 Verschlüsselungsdienst

6.1.1 Durch Module nutzbare TUCs

A_17466 - Systemprozess PL_TUC_HYBRID_ENCIPHER

Der Basis- und KTR-Consumer MUSS den Systemprozess PL_TUC_HYBRID_ENCIPHER implementieren und bereitstellen. [<=]

A_17467 - Systemprozess PL_TUC_HYBRID_DECIPHER

Der Basis- und KTR-Consumer MUSS den Systemprozess PL_TUC_HYBRID_DECIPHER implementieren und bereitstellen. [<=]

6.1.2 Operationen an der Clientsystemschnittstelle

A_17477 - Basisdienst Verschlüsselungsdienst

Der Basis- und KTR-Consumer MUSS für Clients einen Basisdienst Verschlüsselungsdienst anbieten.
 

Tabelle 9: Tab_Verschlüsselungsdienst

Name	EncryptionService
Version	Siehe Anhang
Namensraum	Siehe Anhang
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
Schema	EncryptionService.xsd

[<=]

6.1.2.1 EncryptDocument

A_17510-05 - Basis- und KTR-Consumer, Operation EncryptDocument

Der Verschlüsselungsdienst des Basis- und KTR-Consumer MUSS an der Clientsystemschnittstelle eine Operation EncryptDocument anbieten.
 

Tabelle 10: Tab_Operation_EncryptDocument

Name	EncryptDocument
Beschreibung	Diese Operation verschlüsselt ein übergebenes Dokument hybrid. Der Dokumententyp XML wird gesondert behandelt. Alle anderen Dokumententypen nutzen die binäre Verschlüsselung. Für die hybride Verschlüsselung wird ein asymmetrischer Schlüssel aus einem X.509v3-Zertifikat genutzt. Dieses Zertifikat wird als Parameter übergeben oder auf dem HSM referenziert. Pro Operationsaufruf können mehrere Hybridschlüssel erzeugt werden. Durch das Zertifikat wird festgelegt, ob RSA oder ECC basierte Hybridschlüssel erzeugt werden. Bei Angabe der Zertifikate über CertificateOnCard (Referenz auf HSM) wird ausschließlich das Verschlüsselungsverfahren ECC über die KeyReference EF.C.HCI.ENC.E256 verwendet. Für alle Dokumententypen wird immer das gesamte Dokument verschlüsselt.
Aufrufparameter
	RecipientKeys	Identifiziert die Empfänger der zu verschlüsselnden Nachricht über X.509-Zertifikate (öffentliche Schlüssel). Quelle für die Zertifikate kann eine Karte sein, die per CertificateOnCard-Element referenziert wird, oder der Aufrufer, der X.509-Zertifikate im Certificate-Element übergibt.
	CardHandle	Identifiziert die zu verwendende Karte mit dem (öffentlichen) Schlüssel. Ist das Element nicht vorhanden, so werden nur Zertifikate per Element Certificate übergeben.
	Crypt	Der Parameter wird nicht ausgewertet - Optional;
	Certificate	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. Dieses Element kann leer sein, wenn ausschließlich Zertifikate verwendet werden sollen, die über CertificateOnCard angegeben werden.
	CONSUMER: Document	Dieses entsprechend [OASIS-DSS] Section 2.4.2 spezifizierte Element enthält das zu verschlüsselnde Dokument, wobei das Kindelement dss:Base64Data oder CONSUMER:Base64XML verwendet wird. Das zugeordnete Verschlüsselungsverfahren ist XMLEnc: „http://www.w3.org/TR/xmlenc-core/" für CONSUMER:Base64XML CMS: „urn:ietf:rfc:5652“ für dss:Base64Data
	CRYPT: Optional Inputs	Enthält die optionalen Parameter CRYPT:UnprotectedProperties und CRYPT:EncryptionType.
	Encryption Type	Dieses optionale Element bestimmt das Verschlüsselungsverfahren. Es MUSS das Verfahren XMLEnc: „http://www.w3.org/TR/xmlenc-core/" unterstützt werden, wenn das Dokument in CONSUMER:Base64XML übergeben wird und  CMS: „urn:ietf:rfc:5652“, wenn das Dokument in dss:Base64Data übergeben wird. Die Verwendung dieses Elements ist aufgrund der impliziten Zuordnung der Verschlüsselungsverfahren zur Methode der Dokumentübergabe nicht erforderlich.
	CRYPT: Unprotected Properties		Dieses optionale Element wird nur für das Verschlüsselungsverfahren CMS ausgewertet (zu verschlüsselndes Dokument ist in dss:Base64Data vorhanden). 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.
	Document	Enthält das verschlüsselte Dokument in Base64-codierter Form, wenn die Verschlüsselung erfolgreich durchgeführt wurde. Im Fall XMLEnc wird das verschlüsselte XML-Dokument in CONSUMER:Document/CONSUMER:Base64XML zurückgegeben. Im Fall CMS wird das verschlüsselte Dokument in CONSUMER:Docum ent/dss:Base64data zurückgegeben.
Vorbe-dingungen	Keine
Nachbe-dingungen	Keine

Vor der Verwendung für die Verschlüsselung MÜSSEN Zertifikate durch den Aufruf von PL_TUC_PKI_VERIFY_CERTIFICATE auf ihre Gültigkeit geprüft werden.
Abgelaufene oder gesperrte Zertifikate MÜSSEN von der Verwendung ausgeschlossen werden.

Das Verschlüsseln erfolgt durch Aufruf von PL_TUC_HYBRID_ENCIPHER {
   Doc, das zu verschlüsselnde Dokument = CONSUMER:Document;
   {Cert(i)}, „Menge der Empfänger-/Ziel-Zertifikate“ = RecipientKeys;
    Attribute, optionale, zusätzliche Attribute = UnprotectedProperties;
}
Wird ein Zertifikat per CertificateOnCard-Element referenziert, ist dieses vorher durch den HSMProxy zu extrahieren [<=]

6.1.2.2 DecryptDocument

A_17515-03 - Basis- und KTR-Consumer, Operation DecryptDocument

Der Verschlüsselungsdienst des Basis- und KTR-Consumer MUSS an der Clientsystemschnittstelle eine Operation DecryptDocument anbieten.

 

Tabelle 11: Tab_Operation_DecryptDocument

Das Entschlüsseln erfolgt durch Aufruf von PL_TUC_HYBRID_DECIPHER {
   D, "das verschlüsselte Dokument =CONSUMER:Document;
   Id, "(Identität des) Empfänger" = PrivateKeyOnCard;
}
[<=]

6.2 Signaturdienst

A_23999 - Ergebnis der Signaturprüfung einer KOM-LE-Nachricht

Der Basis Consumer KANN als Ergebnis der Signaturprüfung der KOM-LE-Nachricht eine Datei mit einem detaillierten Signaturprüfungsbericht als Anhang in die Nachricht einfügen. Der Name der Datei MUSS sich aus dem Wort "Signaturpruefungsbericht" und dem aktuellen minutengenauen Zeitstempel zusammensetzen. Es ist folgendes Format des Dateinamens gemäß ISO 8601 anzuwenden: Signaturpruefungsbericht_JJJJMMTT_hhmm. [<=]

6.2.1 Durch Module nutzbare TUCs

A_17517 - Systemprozess PL_TUC_SIGN_DOCUMENT_nonQES

Der Basis- und KTR-Consumer MUSS den Systemprozess PL_TUC_SIGN_DOCUMENT_nonQES implementieren und bereitstellen. [<=]

A_17518 - Systemprozess PL_TUC_SIGN_HASH_nonQES

Der Basis- und KTR-Consumer MUSS den Systemprozess PL_TUC_SIGN_HASH_nonQES implementieren und bereitstellen. [<=]

A_17577 - Systemprozess PL_TUC_VERIFY_DOCUMENT_nonQES

Der Basis- und KTR-Consumer MUSS den Systemprozess PL_TUC_VERIFY_DOCUMENT_nonQES implementieren und bereitstellen.
[<=]

6.2.2 Operationen an der Clientsystemschnittstelle

A_17523 - Basisdienst Signaturdienst

Der Basis- und KTR-Consumer MUSS Clientsystemen einen Basisdienst Signaturdienst (nonQES) anbieten.

Tabelle 12: Tab_Signaturdienst

[<=]

6.2.2.1 SignDocument

A_17525-04 - Basis- und KTR-Consumer, Operation SignDocument

Der Signaturdienst des Basis- und KTR-Consumer MUSS an der Clientsystemschnittstelle eine an [OASIS-DSS] angelehnte Operation SignDocument wie in Tabelle Tab_Operation_SignDocument beschrieben anbieten.
 

Tabelle 13: Tab_Operation_SignDocument

Das Signieren erfolgt durch Aufruf von PL_TUC_SIGN_DOCUMENT_nonQES {
   IDENTIFIKATOR = PrivateKeyOnCard;
   DOKUMENT = SIG:Document;
   DOKUMENTTYPE = dss:SignatureType;
}

[<=]

6.2.2.2 VerifyDocument

A_17526-03 - Basis- und KTR-Consumer, Operation VerifyDocument

Der Signaturdienst des Basis- und KTR-Consumer MUSS an der Clientsystemschnittstelle eine Operation VerifyDocument wie in Tabelle Tab_Operation_VerifyDocument beschrieben anbieten.
 

Tabelle 14: Tab_Operation_VerifyDocument

SigningTime ist der zu prüfende Signaturzeitpunkt. Dieser ergibt sich wie folgt:

1. SigningTime = Benutzerdefinierter_Zeitpunkt, wenn SIG:UseVerificationTime Angaben enthält, sonst
2. SigningTime = Ermittelter_Signaturzeitpunkt_Eingebettet wenn die Signatur einen Signaturzeitpunkt enthält, sonst
3. SigningTime = Ermittelter_Signaturzeitpunkt_System, die Systemzeit.

Das Verifizieren erfolgt durch Aufruf von PL_TUC_VERIFY_DOCUMENT_nonQES {
   SIGNED_DOCUMENT = SIG:Document;
  CERTIFICATE = extrahiert aus SIG:Document;
  SIGNATURE = dss: SignatureObject ;
  TIME_REFERENCE = SigningTime;
}.
[<=]

6.2.2.3 ExternalAuthenticate

A_17578-04 - Basis- und KTR-Consumer, Operation ExternalAuthenticate

Der Signaturdienst des Basis- und KTR-Consumer MUSS an der Client-Systemschnittstelle die Operation ExternalAuthenticate wie in Tabelle Tab_Operation_ExternalAuthenticate beschrieben anbieten.

Tabelle 15: Tab_Operation_ExternalAuthenticate

Name	ExternalAuthenticate
Beschrei bung	Diese Operation versieht einen Binärstring der maximalen Länge 256 Bit mit einer nicht-qualifizierten elektronischen Signatur (nonQES). Dazu wird das Signaturverfahren ECDSA verwendet.
Aufruf parameter
	Name		Beschreibung
	CONSUMER: CardHandle		Identifiziert die zu verwendende Signaturquelle. Die Operation unterstützt nur Identitäten gem. Hinweis unter Tabelle 7 Tab_Personalisierung_HSM.
	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 256 Bit entsprechend der maximal zu erwartenden Hash-Größe. Als Signaturverfahren wird ausschließlich ECDSA unterstützt. Für die Signaturerstellung gilt: Es erfolgt die Signaturerstellung gemäß [BSI-TR-03111]#4.2.1. Als Eingangsparameter wird der Hash vom Aufrufer in SIG: BinaryString übergeben.
Rückgabe
	CONSUMER: 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. Das XML-Attribut dss:SignatureObject/dss:Base64Signature/@Type kennzeichnet durch den Wert: urn:bsi:tr:03111:ecdsa den Signatur-Typ ECDSA. Die XML-Elemente 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

Der Ablauf der Operation ExternalAuthenticate ist in Tabelle Tab_Ablauf_ExternalAuthenticate beschrieben:

Tabelle 16: Tab_Ablauf_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.	Signiere	Das Signieren erfolgt durch Aufruf von PL_TUC_SIGN_HASH_nonQES {    IDENTIFIKATOR = CardHandle;    SIGNATURVERFAHREN = ECDSA mit SHA-256;    HASHWERT = SIG:BinaryString; } Tritt hierbei ein Fehler auf, so bricht die Operation mit Fehler 4123 ab.

Tabelle 17: Tab_Fehler_ExternalAuthenticate

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen TUCs können folgende weitere Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler
4123	Technical	Error	Fehler bei Signaturerstellung

Der zulässige private Schlüssel für die Nutzung durch die Operation ExternalAuthenticate ist für SM-B PrK.HCI.AUT in DF.ESIGN.
[<=]

6.3 Zertifikatsdienst

6.3.1 Durch Module nutzbare TUCs

A_17401 - Systemprozess PL_TUC_PKI_VERIFY_CERTIFICATE

Der Basis- und KTR-Consumer MUSS den Systemprozess PL_TUC_PKI_VERIFY_CERTIFICATE implementieren und bereitstellen. [<=]

6.3.2 Operationen an der Clientsystemschnittstelle

A_17408 - Basisdienst Zertifikatsdienst

Der Basis- und KTR-Consumer MUSS Clientsystemen einen Basisdienst Zertifikatsdienst zur Verfügung stellen.

Tabelle 18: Tab_Zertifikatsdienst

Name	CertificateService
Version	Siehe Anhang B
Namensraum	Siehe Anhang B
Namensraum-Kürzel	CERT für Schema und CERTW für WSDL
Operationen	Name	Kurzbeschreibung
	VerifyCertificate	Prüfung des Status eines Zertifikats
WSDL	CertificateService.wsdl
Schema	CertificateService.xsd

[<=]

6.3.2.1 ReadCertificate

A_24782 - Basis- und KTR-Consumer, Operation ReadCertificate

Die Basisanwendung Zertifikatsdienst des Basis- und KTR-Consumer MUSS an der Client-Schnittstelle eine Operation ReadCertificate wie in Tabelle Tab_Operation_ReadCertificate beschrieben anbieten.

 

Tabelle 19: Tab_Operation_ReadCertificate

Name	ReadCertificate
Beschreibung	Liest X.509-Zertifikate von einem Identitätsträger.
Aufruf parameter
	Name	Beschreibung
	CardHandle	Gibt die Quelle an, von der das Zertifikat gelesen werden soll. Die Operation unterstützt nur Identitäten gem. Hinweis unter Tabelle 7 Tab_Personalisierung_HSM. Die Operation ReadCertificate DARF das Lesen von Zertifikaten der eGK oder HBAx (HBA, HBA-VK) NICHT unterstützen.
	CertRefList	Gibt an, welche(s) Zertifikat(e) gelesen werden soll. Mögliche Werte für CertRef sind: C.AUT
	Crypt	Optional; Default: ECC Gibt den kryptographischen Algorithmus vor, für den das Zertifikat ermittelt werden soll. Wertebereich: RSA, ECC RSA: Zertifikat für RSA-2048 ECC: Zertifikat für ECC-256
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.
Vorbeding ungen	Keine
Nachbeding ungen	Keine

 

Der Ablauf der Operation ReadCertificate ist in Tabelle Tab_Ablauf_ReadCertificate beschrieben:
 

Tabelle 20: Tab_Ablauf_ReadCertificate

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 im CardHandle eine eGK oder HBAx (HBA, HBA-VK) übergeben, wird Fehlercode 4090 zurückgeliefert.
2.	getEF	Für jedes Paar von CertRef und CardHandle wird in Abhängigkeit des Parameters Crypt gemäß Tabelle Tab_IdentityObjekte_ReadCertificate das zu lesende File (EF) bestimmt: Ist die übergebene Zertifikatsreferenz ungültig, wird Fehlercode 4149 zurückgegeben. Das Lesen von Zertifikaten der eGK oder HBAx (HBA, HBA-VK) ist aus Sicherheitsgründen für Clientsysteme nicht zulässig.
3.	Lese Zertifikate	Für jedes Paar von CardHandle und EF wird nun das Zertifikat vom Identitätsträger (HSM) ausgelesen. Falls das File (EF) nicht vorhanden ist, wird die Operation abgebrochen und Fehler 4258 zurückgegeben. Das Zertifikat KANN vom Consumer gecached werden, sofern sichergestellt wird, das der Cache invalidiert wird, sobald sich die Identität des gecacheten Zertifikats auf dem Identitätsträger (HSM) ändert. Das Zertifikat KANN vom Consumer von einer auf dem lokalen und nur durch die Consumer Instanz zugänglichen Filesystem abgelegten Kopie zurückgegeben werden, sofern sichergestellt ist, das diese Kopie zu jederzeit identisch mit dem Zertifikat auf dem Identitätsträger gehalten wird, sobald sich die Identität auf dem Identitätsträger (HSM) ändert.
4.	Zertifikatsattribute extrahieren	Aus jedem Zertifikat werden die zu liefernden Attribute extrahiert. Die Ergebnisstruktur wird mit den erhaltenen Rückgabewerten gefüllt.

 

Tabelle 21: Tab_Fehler_ReadCertificate

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 Identität nicht gestattet
4258	Technical	Error	Zertifikate nicht vorhanden auf Identität: <CardHandle>

Das konkrete Zertifikatsobjekt eines Identitätsträgers ist abhängig vom Typ und dem gewählten kryptographischen Verfahren. Die folgende Tabelle führt auf, welche Zertifikatsobjekte eines Identitätsträgers in Abhängigkeit vom kryptographischen Verfahren für die jeweilige Zertifikatsreferenz ausgewählt werden.

Tabelle 22: Tab_IdentityObjekte_ReadCertificate Kartenobjekt in Abhängigkeit vom kryptographischen Verfahren

Identität	CertRef (Wert)	Objekt der Karte (in DF.ESIGN)
		Crypt == RSA	Crypt == ECC
SM-B (KTR/Org)	C.AUT	EF.C.HCI.AUT	EF.C.HCI.AUT.E256

Hinweis:

• Beim Aufrufparameter CertRefList gibt es zwar nur eine Auswahlmöglichkeit, aber dies sorgt für zukünftige Erweiterbarkeit analog zur äquivalenten Schnittstelle ReadCardCertificate, definiert in [#gemSpec_Kon].

[<=]

6.3.2.2 VerifyCertificate

A_17429-02 - Basis- und KTR-Consumer, Operation VerifyCertificate

Der Zertifikatsdienst des Basis- und KTR-Consumer MUSS an der Clientsystemschnittstelle eine Operation VerifyCertificate wie in Tabelle Tab_Operation_VerifyCertificate beschrieben anbieten.

Tabelle 23: Tab_Operation_VerifyCertificate

Der Ablauf der Operation VerifyCertificate ist in Tabelle Tab_Ablauf_VerifyCertificate beschrieben:

Tabelle 24: Tab_Ablauf_VerifyCertificate

 

Tabelle 25: Tab_Übersicht_VerificationResult_VerifyCertificate

[<=]

6.4 LDAP-Proxy

6.4.1 Durch Module nutzbare TUCs

A_17343 - Basis- und KTR-Consumer, LDAPv3 Operationen für interne Module

Der Basis- und KTR-Consumer MUSS für die in Tab_Ldap_TUC_Mapping aufgelisteten Systemprozesse die entsprechenden LDAP-Operationen implementieren und zur Nutzung durch interne Module zur Verfügung stellen.

Tabelle 26: Tab_Ldap_TUC_Mapping

LDAPv3-Operation	Systemprozess
Bind	PL_TUC_VZD_BIND
Unbind	PL_TUC_VZD_UNBIND
Search	PL_TUC_VZD_SEARCH
Abandon	PL_TUC_VZD_ABANDON

[<=]

6.4.2 Unterstützte LDAPv3-Operationen an der Clientsystemschnittstelle

A_17341-01 - Basis- und KTR-Consumer, LDAPv3-Operationen an der Clientsystemschnittstelle

Der Basis- und KTR-Consumer MUSS an der Clientsystemschnittstelle die folgenden LDAPv3-Operationen für den Zugriff auf den Verzeichnisdienst der TI gemäß [RFC4511] anbieten.
 

• Bind Operation
• Unbind Operation
• Search Operation
• Abandon Operation

Andere LDAPv3-Operationen MÜSSEN mit dem LDAP-Fehler unwillingToPerform (53) beantwortet werden.
Fehler MÜSSEN gemäß [RFC4511]#Appendix A behandelt werden. [<=]

6.5 Clientmodul KOM-LE

6.5.1 Allgemeine Anforderungen

A_17298 - Synchronisation mit der Systemzeit der zentralen TI-Plattform

Das KOM-LE-Clientmodul MUSS sich unter Verwendung des Systemprozesses PL_TUC_NET_SYNC_TIME mit der Systemzeit des Zeitservers der zentralen TI-Plattform synchronisieren. [<=]

A_17299-02 - Konfigurationsparameter

Das KOM-LE-Clientmodul MUSS die in Tabelle [gemSpec_CM_KOMLE#Tab_Konf_Param] aufgelisteten Parameter, bis auf die Parameter TLS_AUTH_KONNEKTOR, KONNEKTOR_TIMEOUT und KONNEKTOR_URI, über eine Managementoberfläche oder eine Konfigurationsdatei konfigurierbar gestalten und mit einer Standardkonfiguration entsprechend den Defaultwerten ausliefern.

 

[<=]

A_17503 - Prüfung von TLS-Server-Zertifikaten

Das KOM-LE-Clientmodul MUSS für die Prüfung von TLS-Server-Zertifikaten der KOM-LE-Fachdienste den Systemprozess PL_TUC_PKI_VERIFY_CERTIFICATE des Basis- und KTR-Consumer benutzen. 
[<=]

A_22664 - Basis-Consumer - Prüfung der verwendeten Clientmodul-Version beim Senden

Das KIM-Clientmodul des Basis-Consumers MUSS vor dem Versenden einer Nachricht die KIM-Version des Absenders mittels des LDAP-Directory Attributs: komLeData aus dem Verzeichnisdienst [gemSpec_VZD#5] abfragen. Ist die KIM-Version des Clientmoduls kleiner als die im Verzeichnisdienst eingetragene, so MUSS das Clientmodul den Absender mit einer E-Mail darüber informieren. Aus dem Inhalt der E-Mail MUSS hervorgehen, dass die verwendete Clientmodul-Version veraltet ist. Die E-Mail ist weder zu signieren noch zu verschlüsseln und entspricht der Delivery Status Notification gemäß [RFC3461-3464]. Ist die KIM-Version des Clientmoduls größer als die im Verzeichnisdienst abgefragte Version KANN das Clientmodul des Basis-Consumers das LDAP-Directory Attribut: komLeData für den Absender mit der neuen Versionen überschreiben. [<=]

Es wird dem Empfänger von E-Mails die Entscheidung ermöglicht, ob er sich mit komLeData 1.5 im Verzeichnisdienst einträgt, oder es bei der 1.0 belässt und damit keine E-Mails mit Anhängen > 25 MB empfangen kann. A_26447 - ECC-preferred-Funktionalität ein- und ausschaltbar

Der Consumer MUSS die ECC-preferred-Funktionalität, wie sie in den Anforderungen TIP1-A_6984-*, A_17525-* und KOM-LE-A_2022-* gefordert wird, ein- und ausschaltbar gestalten. Welche Anforderungen dabei in welchem Zustand vom Consumer funktional aktiv bereitgestellt werden müssen und welche nicht, ist in Tabelle "Tab_ECC-preferred-Funktionalität" festgelegt.

Tabelle 27: Tab_ECC-preferred-Funktionalität

Anforderung	Zustand "ECC-preferred-Funktionalität eingeschaltet"	Zustand: "ECC-preferred-Funktionalität ausgeschaltet" (Default-Zustand)
TIP1-A_6984-03	MUSS funktional aktiv sein	DARF NICHT funktional aktiv sein
A_17525-04	MUSS funktional aktiv sein	DARF NICHT funktional aktiv sein
KOM-LE-A_2022-01	MUSS funktional aktiv sein	DARF NICHT funktional aktiv sein
TIP1-A_6984-02	DARF NICHT funktional aktiv sein	MUSS funktional aktiv sein
A_17525-03	DARF NICHT funktional aktiv sein	MUSS funktional aktiv sein
KOM-LE-A_2022	DARF NICHT funktional aktiv sein	MUSS funktional aktiv sein

Im Default-Zustand MUSS die ECC-preferred-Funktionalität ausgeschaltet sein. [<=]

A_26448 - Ein- und Ausschalten der ECC-preferred-Funktionalität

Der Anbieter des Consumers MUSS die ECC-preferred-Funktionalität, wie sie in der Anforderung A_26447-* definiert wird, jederzeit auf Weisung der gematik über einen abgesicherten Prozess für alle bei ihm in Betrieb befindlichen Instanzen ein- und ausschalten können. [<=]

Es steht dem Hersteller des Consumers frei, wie die Schalter aus A_26447-* umgesetzt werden. Beispielsweise sind die Realisierung über eine Konfigurationsdatei oder auch ein zur Laufzeit der Consumer-Instanz schaltbare Konfiguration über Management-UI möglich. Weiterhin sei auch vermerkt, dass zum Umschalten der Zustände gem. A_26448-* Consumer-Instanzen neu gestartet werden dürfen.

6.5.1.1 Eingeschaltete ECC-preferred-Funktionalität

Um die Umschaltung der ECC-preferred-Funktionalität gemäß A_26447-* und A_26448-* umsetzen zu können, werden Anforderungen benötigt, die die ECC-preferred-Funktionalität im eingeschalteten Zustand definieren.

In diesem Kapitel werden Anforderungen aufgelistet, die sonst in keinen anderen Dokumenten zu finden sind.

KOM-LE-A_2022-01 - Verschlüsseln der Nachricht mit den Verschlüsselungszertifikaten C.HCI.ENC bzw. C.HP.ENC

Das Clientmodul MUSS vom Clientsystem erhaltene E-Mail-Nachrichten sowohl für jeden in den RCPT-Kommandos angegebenen Empfänger als auch für den Sender aus dem from bzw. sender Header-Element der Nachricht mit Verschlüsselungszertifikaten (C.HCI.ENC für eine Institution oder C.HP.ENC für einen Leistungserbringer) verschlüsseln. Falls dem Sender bzw. Empfänger sowohl ein ECC- als auch RSA-Zertifikat zugeordnet ist, MUSS für die Verschlüsselung ausschließlich das ECC-Zertifikat verwendet werden. In diesem Fall DARF das RSA-Zertifikat NICHT verwendet werden.
[<=]

6.5.1.2 Ausgeschaltete ECC-preferred-Funktionalität

Um die Umschaltung der ECC-preferred-Funktionalität gemäß A_26447-* und A_26448-* umsetzen zu können, werden Anforderungen benötigt, die die ECC-preferred-Funktionalität im ausgeschalteten Zustand definieren.

In diesem Kapitel werden diese Anforderungen für bessere Lesbarkeit aufgelistet, auch wenn sie sonst in anderen Dokumenten zu finden sind.

KOM-LE-A_2022 - Verschlüsseln der Nachricht mit den Verschlüsselungszertifikaten C.HCI.ENC bzw. C.HP.ENC

Das Clientmodul MUSS vom Clientsystem erhaltene E-Mail-Nachrichten sowohl für jeden in den RCPT-Kommandos angegeben Empfänger als auch für den Sender aus dem from bzw. sender Header-Element der Nachricht mit allen dem Sender bzw. Empfängern zugeordneten Verschlüsselungszertifikaten (C.HCI.ENC für eine Institution oder C.HP.ENC für einen Leistungserbringer) verschlüsseln.
[<=]

TIP1-A_6984-02 - Ablauf der hybriden Verschlüsselung eines Dokuments

Produkttypen und Dienste der TI, die eine Plattformleistung PL_TUC_HYBRID_ENCYPHER umsetzen, MÜSSEN die Schritte zum Verschlüsseln eines gegebenen Dokuments in der angegebenen Reihenfolge durchführen:

	Teilschritt der hybriden Verschlüsselung	Teilergebnis
1	Erzeugung eines symmetrischen Schlüssels gemäß BSI-TR-03116-1#3.5 Schlüsselerzeugung] und den Festlegungen in [gemSpec_Krypt#3.5.1 Hybride Verschlüsselung] ->Ssymm	Symmetrischer Schlüssel Falls Symmetrischer Schlüssel nicht erzeugt werden kann => Fehler
2	Dokument Doc mit symmetrischem Schlüssel Ssymm verschlüsseln -> Docenc Falls Doc ein XML-Dokument/Fragment ist: XMLEnc: Es MÜSSEN die Vorgaben aus [gemSpec_Krypt#3.1.4] beachtet werden. Sonst: CMS Es MÜSSEN die Vorgaben aus [gemSpec_Krypt#3.5.1] beachtet werden.	symmetrisch verschlüsseltes Dokument
3	Für jedes Empfängerzertifikat Cert(i) Schlüssel Ssymm mit öffentlichem Schlüssel Spublic der Empfängeridentität (liegt in Zertifikat Cert(i)) gemäß Vorgaben aus gemSpec_Krypt#3.1.5] (XML, RSA) bzw. [gemSpec_Krypt#3.5.2] (CMS, RSA) oder gemäß Vorgaben aus [gemSpec_Krypt#5.7] (XML/CMS, ECC)  verschlüsseln -> (Ssymm)enc(i)	pro Empfängerzertifikat: mit öffentlichem Schlüssel der Empfängeridentität verschlüsselter symmetrischer Schlüssel
4a	XMLEnc: Alle verschlüsselten Dokumentenschlüssel {(Ssymm)enc(i)} als EncryptedKey und mit dem verschlüsselten Dokument Docenc zu einem EncryptedData-Element gemäß [XML-Enc 1.1] zusammenfügen: Docenc + {(Ssymm)enc(i)} + Attribute -> D Pro Empfängerzertifikat wird ein Element EncryptedKey/KeyInfo/X509Data/X509Certificate base64-kodiert und darin DER-kodiert abgelegt.	zusammengefügtes XML-ENC-EncryptedData-Element
4b	CMS: Alle verschlüsselten Dokumentenschlüssel {(Ssymm)enc(i)} und das verschlüsselte Dokument sind in einem Authenticated-Enveloped-Data Content Type gemäß [RFC-5083] und [RFC-5084] zusammenzuführen: Docenc + {(Ssymm)enc(i)} + Attribute -> D Bei Verschlüsselung des „content-encryption key“ wird „key transport“ verwendet Pro Empfängerzertifikat wird eine KeyTransRecipientInfo erzeugt, für RecipientIdentifier wird die Option IssuerAndSerialNumber verwendet ContentType = OID {… authEnvelopedData}                       = 1.2.840.113549.1.9.16.1.23	zusammengefügtes CMS-Dokument
5	Rückmeldung an den Aufrufenden, entweder 1. OK + verschlüsseltes Dokument D oder 2. Fehler

[<=]

A_17525-03 - Basis- und KTR-Consumer, Operation SignDocument

Der Signaturdienst des Basis- und KTR-Consumer MUSS an der Clientsystemschnittstelle eine an [OASIS-DSS] angelehnte Operation SignDocument wie in Tabelle Tab_Operation_SignDocument beschrieben anbieten.

 

Tabelle 28: Tab_Operation_SignDocument

Das Signieren erfolgt durch Aufruf von PL_TUC_SIGN_DOCUMENT_nonQES {
   IDENTIFIKATOR = PrivateKeyOnCard;
   DOKUMENT = SIG:Document;
   DOKUMENTTYPE = dss:SignatureType;
}

Die folgende Tabelle führt die zulässigen Zertifikate und Schlüssel für die nonQES auf: 

Tabelle 29: Tab_Zertifikate_für_Sign/VerifyDocument(nonQeS)

[<=]

6.5.2 Senden von Nachrichten

A_17300 - Initialer SMTP-Dialog

Das KOM-LE-Clientmodul MUSS, nachdem die SMTP-Verbindung zwischen dem Clientsystem und dem Clientmodul aufgebaut wird und bis zum Punkt an dem das Clientsystem die Bestätigung des Erfolgs oder Misserfolgs seiner Authentifizierung erwartet, einen SMTP-Dialog entsprechend der Tabelle Tab_SMTP_Ant_Init mit dem Clientsystem führen.

Tabelle 2730: Tab_SMTP_Ant_Init Antworten Clientmodul im CONNECT-Zustand

SMTP-Kommando (Clientsystem -> Clientmodul)	SMTP-Antwortcode (Clientmodul -> Clientsystem)
HELO	“250 OK” Antwortcode
EHLO	“250 OK” Antwortcode mit folgenden EHLO-Kennworten: SIZE <size> AUTH LOGIN PLAIN 8BITMIME ENHANCEDSTATUSCODES DSN und <size> gleich oder großer als 35882577
AUTH	Anmeldungsdaten erhalten und Verbindungsaufbau mit dem MTA beginnen
RSET, NOOP	„250 OK“ Antwortcode
MAIL, RCPT, DATA	„530 5.7.0“ Antwortcode (Authentication required)
QUIT	„221 OK“ Antwortcode senden und die Verbindung mit dem Clientsystem schließen
Andere Meldungen	„502  5.5.1“ Antwortcode (Invalid command)

[<=]

A_17302 - Authentisierung gegenüber dem SMTP-Server mit Benutzernamen und Passwort

Das KOM-LE-Clientmodul MUSS den Benutzernamen und das Passwort, die es vom Clientsystem erhalten hat, für die Authentisierung gegenüber dem SMTP-Server verwenden. [<=]

A_17303 - Ergebnis des Verbindungsaufbaus mit dem SMTP-Server

Das KOM-LE-Clientmodul MUSS das Clientsystem über das Ergebnis des Verbindungsaufbaus mit dem MTA mit den in Tabelle Tab_SMTP_Verbindung beschriebenen SMTP-Antwortcodes informieren.

Tabelle 2831: Tab_SMTP_Verbindung SMTP-Antwortcodes für MTA-Verbindungsaufbau

[<=]

A_17305 - Verwenden von PL_TUC_SIGN_DOCUMENT_nonQES und PL_TUC_HYBRID_ENCIPHER

Das KOM-LE-Clientmodul MUSS für das Signieren und Verschlüsseln der Nachrichten entsprechend dem KOM-LE-S/MIME-Profil die Systemprozesse PL_TUC_SIGN_DOCUMENT_nonQES und PL_TUC_HYBRID_ENCIPHER des Basis- und KTR-Consumers verwenden. [<=]

A_17306 - Vorgehen bei Signatur und Verschlüsselung einer KOM-LE Nachricht

Das KOM-LE-Clientmodul MUSS zur Signatur und Verschlüsselung von KOM-LE Nachrichten das folgende Vorgehen umsetzen:

1. Unter Verwendung des Systemprozesses PL_TUC_SIGN_DOCUMENT_nonQES des Basis- und KTR-Consumers erzeugt das Clientmodul KOM-LE einen binären Opak-signierten CMS-Container entsprechend dem KOM-LE-S/MIME-Profil.
2. Der binäre CMS-Container mit der signierten Nachricht wird als „application/pkcs7-mime“ MIME-Einheit vom smime-type „signed-data“ mit dem Content-Transfer-Encoding „binary“ verpackt.
3. Zur CMS-Verschlüsselung übergibt das KOM-LE-Clientmodul beim Aufruf des Systemprozesses PL_TUC_HYBRID_ENCIPHER die in Schritt zwei erzeugte Nachricht als binär-Dokument. Als Antwort erhält das KOM-LE-Clientmodul einen binären CMS-Container zurück.
4. Der aus der Verschlüsselung resultierende CMS-Container wird in eine „application/pkcs7-mime“ MIME-Einheit vom smime-type „authenticated-enveloped-data“ mit dem Content-Transfer-Encoding „base64“ verpackt.

[<=]

A_17327 - Signieren der Nachricht mit dem Schlüssel Prk.HCI.OSIG

Das KOM-LE-Clientmodul MUSS für das Signieren einer KOM-LE-Nachricht den privaten Schlüssel PrK.HCI.OSIG.R2048 der SM-B der jeweiligen Organisation (Kostenträger oder Leistungserbringerorganisation) verwenden.
[<=]

6.5.3 Empfangen von Nachrichten

A_17328 - POP3-Dialog zur Authentifizierung

Das KOM-LE-Clientmodul MUSS, nachdem die POP3-Verbindung zwischen dem Clientsystem und dem Clientmodul aufgebaut wurde und bis zu dem Punkt an dem das Clientsystem die Bestätigung des Erfolgs oder Misserfolgs seiner Authentifizierung erwartet, einen POP3-Dialog entsprechend Tabelle Tab_POP3_Ant_Init mit dem Clientsystem führen.

Tabelle 2932: Tab_POP3_Ant_Init Antworten Clientmodul im CONNECT-Zustand

Clientsystem -> Clientmodul	Clientmodul -> Clientsystem
CAPA	“+OK” Antwortcode mit folgenden CAPA Kennworten: TOP USER SASL PLAIN UIDL
USER, AUTH	Anmeldungsdaten erhalten und Verbindungsaufbau mit dem POP3-Server fortsetzen
QUIT	„+ OK“ Antwortcode senden und die Verbindung mit dem Clientsystem schließen
Andere Meldungen	„-ERR“ Antwortcode

[<=]

A_17330 - Authentifizierung gegenüber POP3-Server mit Benutzernamen und Passwort

Das KOM-LE-Clientmodul MUSS den Benutzernamen und das Passwort,die es vom Clientsystem erhalten hat, für die Authentifizierung gegenüber dem POP3-Server verwenden. [<=]

A_17331 - Ergebnis des Verbindungsaufbaus mit dem POP3-Server

Das KOM-LE-Clientmodul MUSS das Clientsystem über das Ergebnis des Verbindungsaufbaus mit dem POP3-Server mit den in der Tabelle Tab_POP3_Verbindung beschriebenen POP3-Antwortcodes informieren.

Tabelle 3033: Tab_POP3_Verbindung Antwortcodes für POP3-Server-Verbindungsaufbau

[<=]

A_17333 - E-Mail-Adresse des den Abholvorgang auslösenden Nutzers

Das KOM-LE-Clientmodul MUSS den vom Clientsystem erhaltenen POP3-Usernamen als die E-Mail-Adresse des den Abholvorgang auslösenden Nutzers betrachten. [<=]

A_17504 - Verwenden von PL_TUC_VERIFY_DOCUMENT_nonQES und PL_TUC_HYBRID_DECIPHER

Das KOM-LE-Clientmodul MUSS für das Entschlüsseln und die Signaturprüfung der Nachrichten die Systemprozesse PL_TUC_VERIFY_DOCUMENT_nonQES und PL_TUC_HYBRID_DECIPHER des Basis- und KTR-Consumers verwenden.
[<=]

A_17337 - Abbrechen des Entschlüsseln, wenn die erforderliche SM-B nicht verfügbar ist

Das KOM-LE-Clientmodul MUSS die Entschlüsselung einer Nachricht abbrechen, wenn die für die Entschlüsselung erforderliche SM-B nicht verfügbar ist. [<=]

A_17338 - Abbrechen des Entschlüsseln, wenn Freischaltung der erforderlichen SM-B fehlschlägt

Das KOM-LE-Clientmodul MUSS die Entschlüsselung einer Nachricht abbrechen, wenn die Freischaltung der für die Entschlüsselung erforderlichen SM-B fehlschlägt. [<=]

6.6 Realisierung der Leistungen der TI-Plattform

A_18130 - Nutzung von PL_TUC_CARD Systemprozessen

Der Basis-Consumer MUSS für den Zugriff auf Smartcards die in TAB_Systemprozesse mit PL_TUC_CARD_* bezeichneten Systemprozesse benutzen.
[<=]

6.6.1 Schnittstelle für Kartenkommandos

Wenn der Basis-Consumer Smartcards unterstützt, muss er eine Schnittstelle zu Karten der TI über ein Kartenterminal herstellen. Diese Schnittstelle muss die von den Plattformprozessen erzeugten, kartenverständlichen APDUs an die Karte übertragen. Neben proprietären Schnittstellentreibern von Kartenterminalherstellern existiert eine Reihe standardisierter Schnittstellen, die auch von verschiedenen Betriebssystemen zur Anbindung handelsüblicher Kartenterminals unterstützt werden.

Die folgenden Anforderungen betreffen die gemäß [gemSpec_Systemprozesse_dezTI#ENV_TUC_CARD_APDU_TRANSPORT] zu beschreibende Schnittstelle.

A_18166 - Vertrauliche und integritätsgeschützte Kommunikation mit KT

Wenn der Basis-Consumer Smartcards unterstützt, MUSS der Basis-Consumer mit dem Kartenterminal ausschließlich über eine vertrauliche, integritätsgeschützte Verbindung kommunizieren. [<=]

A_18097-01 - Schnittstelle für Kartenkommandos

Wenn der Basis-Consumer Smartcards unterstützt, MUSS er eine sichere Schnittstelle für die Übertragung von Smartcard-APDUs gemäß [CT-API] implementieren.
[<=]

A_18100-01 - Ergänzende Standards für Kartenkommandos

Der Basis-Consumer KANN eine Schnittstelle für die Übertragung von SmartCard-APDUs auf Basis des SICCT-Protokolls gemäß [CCID] und unter Verwendung der vom Hersteller des Kartenterminals ggf. bereitgestellten Hardwaretreiber implementieren.
[<=]

A_18163 - Kartenterminal für Basis-Consumer

Wenn der Basis-Consumer Smartcards unterstützt, MUSS er mindestens ein Kartenterminal enthalten.
[<=]

A_18102 - PIN-Eingabe nicht speichern

Der Basis-Consumer DARF ein eingegebenes PIN-Geheimnis NICHT speichern. [<=]

A_18103 - PIN-Geheimnis ausschließlich an Karte übermitteln

Der Basis-Consumer MUSS sicherstellen, dass das eingegebene PIN-Geheimnis ausschließlich an die Karte und nicht an andere Adressaten übermittelt wird.
[<=]

6.6.2 Schnittstelle für PIN-Operationen und Anbindung der Karten der TI

Anwendungsfälle zur PIN-Verwaltung, zur Kartenfreischaltung oder weiterer Fachanwendungen können die Eingabe eines PIN- oder PUK-Geheimnisses erfordern. Der Zugriff auf Karten der TI erfolgt über die Systemprozesse PL_TUC_CARD_*. Der Basis-Consumer als Realisierungsumgebung der Systemprozesse muss seinerseits die von der Plattform geforderten Schnittstellen gemäß [gemSpec_Systemprozesse_dezTI#ENV_TUC_CARD_SECRET_INPUT] implementieren, um die Kommunikation der Plattform mit dem Benutzer zu ermöglichen.

Die Schnittstelle für den Transport von Kartenkommandos ist in Kapitel 6.6.1 beschrieben und umfasst das Kartenterminal, Eingabemedium und Hinweistexte an den Benutzer. Diese kann je nach Konfiguration an einem Gerät als Kartenterminal oder auch eine Kombination aus Bildschirmausgabe, Kartenterminal-PIN-Pad und/oder Tastatureingabe erfolgen.

A_18107-01 - Schnittstelle zur Eingabe des PIN/PUK-Geheimnisses

Wenn der Basis-Consumer Smartcards unterstützt, MUSS er eine Operation gemäß [gemSpec_Systemprozesse_dezTI#ENV_TUC_CARD_SECRET_INPUT] zur Eingabe eines PIN/PUK-Geheimnisses und Weiterleitung an eine Smartcard mit folgenden Parametern implementieren:
Eingabeparameter:

• Identifikator
• Aktion
• minLength
• maxLength
• commandApduPart

Rückgabewerte

• responseApdu

[<=]

A_18108-01 - Umsetzung ENV_TUC_CARD_SECRET_INPUT

Wenn der Basis-Consumer Smartcards unterstützt, MUSS er die Abbildung der Eingabeparameter auf die Rückgabewerte der Operation ENV_TUC_SECRET_INPUT derart umsetzen, dass
 

• die Eingabeparameter Identifikator und Aktion für einen Hinweistext an den Benutzer verwendet werden, welche Aktion auf welchem konkreten Kartenobjekt (z.B. Name einer PIN) durchgeführt wird,
• der commandApduPart um das Benutzergeheimnis ergänzt wird,
• der commandApduPart über die Schnittstelle für Kartenkommandos an die Karte gesendet wird

und die Antwortnachricht der Karte als responseApdu an den Aufrufer zur Auswertung zurückgegeben wird.
[<=]

A_18109 - Minimalprinzip Karteninteraktion

Der Basis-Consumer DARF ein Kartenkommando NICHT an eine angebundene Karte weiterleiten, wenn dies nicht explizit im Kontext eines Anwendungsfalls (intendierte Kartenoperationen und Erhöhen des Sicherheitszustands der Karte, falls erforderlich) erforderlich ist. [<=]

7 Anhang A - Verzeichnisse

7.1 Abkürzungen

7.2 Glossar

Das Glossar wird als eigenständiges Dokument, vgl. [gemGlossar] zur Verfügung gestellt.

7.3 Abbildungsverzeichnis

Abbildung 1: Systemkontext für Basis- und KTR-Consumer

7.4 Tabellenverzeichnis

Tabelle 1: Mapping der Netzwerksegmente

Tabelle 2 : TAB_CONS_687 DNS-Forwards des DNS-Servers

Tabelle 3: TAB_CONS_648 – TUC_CONS_362 „Liste der Dienste abrufen“

Tabelle 4: Basisanwendung Namensdienst

Tabelle 5: Konfigurationsparameter Namensdienst

Tabelle 6: Einsehbare Konfigurationsparameter Namensdienst

Tabelle 7: Tab_Personalisierung_HSM – Personalisierung des HSM

Tabelle 8: TAB_CardHandle_Map

Tabelle 9: Tab_Verschlüsselungsdienst

Tabelle 10: Tab_Operation_EncryptDocument

Tabelle 11: Tab_Operation_DecryptDocument

Tabelle 12: Tab_Signaturdienst

Tabelle 13: Tab_Operation_SignDocument

Tabelle 14: Tab_Operation_VerifyDocument

Tabelle 15: Tab_Operation_ExternalAuthenticate

Tabelle 16: Tab_Ablauf_ExternalAuthenticate

Tabelle 17: Tab_Fehler_ExternalAuthenticate

Tabelle 18: Tab_Zertifikatsdienst

Tabelle 19: Tab_Operation_ReadCertificate

Tabelle 20: Tab_Ablauf_ReadCertificate

Tabelle 21: Tab_Fehler_ReadCertificate

Tabelle 22: Tab_IdentityObjekte_ReadCertificate Kartenobjekt in Abhängigkeit vom kryptographischen Verfahren

Tabelle 23: Tab_Operation_VerifyCertificate

Tabelle 24: Tab_Ablauf_VerifyCertificate

Tabelle 25: Tab_Übersicht_VerificationResult_VerifyCertificate

Tabelle 26: Tab_Ldap_TUC_Mapping

Tabelle 27: Tab_SMTP_Ant_Init Antworten Clientmodul im CONNECT-ZustandECC-preferred-Funktionalität

Tabelle 28: Tab_SMTP_Verbindung SMTP-Antwortcodes für MTA-VerbindungsaufbauOperation_SignDocument

Tabelle 29: Tab_POP3_Ant_Init Antworten Clientmodul im CONNECT-ZustandZertifikate_für_Sign/VerifyDocument(nonQeS)

Tabelle 30: Tab_POP3_Verbindung Antwortcodes für POP3-Server-VerbindungsaufbauSMTP_Ant_Init Antworten Clientmodul im CONNECT-Zustand

Tabelle 31: Tab_Schema_Versionen Versionen der Schemas aus dem Namensraum des Basis- und KTR-ConsumersSMTP_Verbindung SMTP-Antwortcodes für MTA-Verbindungsaufbau

Tabelle 32: TAB_Systemprozesse – Verwendete PlattformleistungenTab_POP3_Ant_Init Antworten Clientmodul im CONNECT-Zustand

Tabelle 33: Tab_POP3_Verbindung Antwortcodes für POP3-Server-Verbindungsaufbau

Tabelle 34: Tab_Schema_Versionen Versionen der Schemas aus dem Namensraum des Basis- und KTR-Consumers

Tabelle 35: TAB_Systemprozesse – Verwendete Plattformleistungen

7.5 Referenzierte Dokumente

7.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.

7.5.2 Weitere Dokumente

8 Anhang B – Übersicht über die verwendeten Versionen

Für den Fall, dass Schnittstellenversionen unterstützt werden müssen, die den gleichen TargetNamespace nutzen, kann der Basis- und KTR-Consumer zu diesen Schnittstellenversionen einheitlich einen SOAP-Endpunkt anbieten, der die höchste der Schnittstellenversionen implementiert.

Tabelle 3134: Tab_Schema_Versionen Versionen der Schemas aus dem Namensraum des Basis- und KTR-Consumers

Schemas aus dem Namensraum des Basis- und KTR-Consumer „http://ws.gematik.de/consumer“
Name	Version	TargetNamespace
CertificateService.wsdl	3.0.0	http://ws.gematik.de/consumer/CertificateService/WSDL/v3.0
CertificateService.xsd	3.0.0	http://ws.gematik.de/consumer/CertificateService/v3.0
CertificateServiceCommon.xsd	2.0.0	http://ws.gematik.de/consumer/CertificateServiceCommon/v2.0
ConsumerCommon.xsd	2.0.0	http://ws.gematik.de/consumer/ConsumerCommon/v2.0
EncryptionService.wsdl	3.0.1	http://ws.gematik.de/consumer/EncryptionService/WSDL/v3.0
EncryptionService.xsd	3.0.1	http://ws.gematik.de/consumer/EncryptionService/v3.0
SignatureService.wsdl	3.1.0	http://ws.gematik.de/consumer/SignatureService/WSDL/v3.1
SignatureService.xsd	3.1.0	http://ws.gematik.de/consumer/SignatureService/v3.1

9 Anhang C – Übersicht der genutzten Systemprozesse

Der Basis- und KTR-Consumer verwendet u.a. die in Tabelle TAB_Systemprozesse dargestellten Plattformleistungen aus [gemSpec_Systemprozesse_dezTI].

Tabelle 3235: TAB_Systemprozesse – Verwendete Plattformleistungen