Telematikinfrastruktur 2.0

Spezifikation

Proof of Patient Presence (PoPP)-Service

    

     

      
Version
      
1.0.0_CC
     
     

      
Revision
      
1106020
     
     

      
Stand
      
20.01.2025
     
     

      
Status
      
zur Abstimmung freigegeben
     
     

      
Klassifizierung
      
öffentlich_Entwurf
     
     

      
Referenzierung
      
gemSpec_PoPP_Service
     
    

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen an die Herstellung, den Test und den Betrieb des Produkttyps PoPP-Service. Diese Anforderungen basieren auf einem von der gematik erarbeiteten technischen Konzept einer PoPP-Lösung sowie auf fortlaufenden Abstimmungen mit den Gesellschaftern der gematik, insbesondere in Bezug auf die Nutzung der GesundheitsID. 

Der PoPP-Service ist der Serveranteil der PoPP-Lösung, wobei PoPP für "Proof of Patient Presence" steht. Der PoPP-Service erzeugt die Bestätigung eines Versorgungskontextes in Form eines kryptographisch gesicherten PoPP-Token. Dieses Token bestätigt, dass ein bestimmter Versicherter mit einer bestimmten Leistungserbringerinstitution (LEI) zusammengekommen ist. Dieser Versorgungskontext wird beim Zugriff von Leistungserbringern (LE) auf TI-Fachdienste (FD), wie bspw. VSDM 2.0, "ePA für alle" oder E-Rezept, in Form eines PoPP-Token an diese übermittelt. 

Neben dem PoPP-Service, der als Plattformdienst der Telematikinfrastruktur (TI) 2.0 betrieben wird, tragen weitere Komponenten zur PoPP-Lösung bei:

• PoPP-Clients, die als Teil der Primärsysteme (PS) implementiert werden,
• PoPP-Module, das als Teil von von Versicherten genutzte Anwendungen implementiert werden, welche bei der mobilen Nutzung der eGK oder bei Nutzung der GesundheitsID in die Kommunikation zur Erstellung von PoPP-Token eingebunden sind.

Die Spezifikation oder Beschreibung dieser weiteren Komponenten erfolgt in anderen Dokumenten.

1.2 Zielgruppe

Das Dokument richtet sich an:

• Hersteller und Anbieter des PoPP-Service,
• Hersteller von Produkttypen oder Komponenten, die eine Schnittstelle zum PoPP-Service besitzen,
• Hersteller und Anbieter von FD, die einen PoPP-Token nutzen.
  

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur TI des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (bspw. gemPTV_ATV_Festlegungen, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekanntgegeben.

1.4 Abgrenzungen

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 (siehe auch Anhang A – Verzeichnisse).

Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps PoPP-Service [gemProdT_PoPP_Service_PTV] verzeichnet. Für den Anbieter des PoPP-Service ist auch der Anbietertypsteckbrief für den PoPP-Service [gemAnbT_PoPP_Service_ATV] relevant.

Nicht Bestandteil des vorliegenden Dokumentes sind die Festlegungen zum Themenbereich PoPP-Client, PoPP-Modul oder App-Anforderungen zur PoPP-Token Kommunikation.

1.5 Methodik

Anwendungsfälle und Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID,
Anforderungen zusätzlich durch die dem [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Da in dem Beispielsatz "Eine leere Liste DARF NICHT ein Element besitzen." die Phrase "DARF NICHT" semantisch irreführend wäre (wenn nicht ein, dann vielleicht zwei?), wird in diesem Dokument stattdessen "Eine leere Liste DARF KEIN Element besitzen." verwendet. Die Schlüsselworte werden außerdem um Pronomen in Großbuchstaben ergänzt, wenn dies den Sprachfluss verbessert oder die Semantik verdeutlicht.

Anwendungsfälle und Anforderungen werden im Dokument wie folgt dargestellt:
<AF-ID> - <Titel des Anwendungsfalles>
Text/Beschreibung
[<=]

bzw.

<AFO-ID> - <Titel der Afo>
Text/Beschreibung
[<=]

Dabei umfasst der Anwendungsfall bzw. die Anforderung sämtliche zwischen ID und Textmarke [<=] angeführten Inhalte.

Hinweis auf offene Punkte

2 Systemüberblick

In diesem Kapitel wird ein einführender Überblick über die PoPP-Lösung gegeben.

Abbildung 1: Einfacher Systemüberblick

Proof of Patient Presence (PoPP) ist ein Nachweis, der belegt, dass sich ein Versicherter zu einem bestimmten Zeitpunkt in einem Versorgungskontext mit einer bestimmten LEI befindet. Im kryptographisch gesicherten PoPP-Token sind somit Informationen über die LEI und über den Versicherten zusammengeführt. Dabei ist es die Aufgabe der PoPP-Lösung, die Authentifizierung der LEI durchzuführen und durch Authentifizierung des Versicherten per GesundheitsID oder Authentifizierung der elektronischen Gesundheitskarte (eGK) eines Versicherten den Versorgungskontext zu bestätigen. Das Ergebnis ist das PoPP-Token, das der LEI zur Autorisierung für den Zugriff auf die Daten des Versicherten in Diensten der TI dient.

Die Lösung besteht aus dem zentralen Server und verschiedenen Client Komponenten:

1. PoPP-Service - der als zentraler Dienst PoPP-Token für LEI erstellt. Ein Versicherter authentisiert sich dabei entweder mit seiner eGK oder seiner GesundheitsID.
2. Primärsystem (PS) der LEI - als Host der Client-Seite. Das PS besteht aus:
   
1. Basis-PS - enthält die bisherige Funktionalität inklusive der Verwaltung von Patientenstammdaten (PVS/KIS), sowie eine neue Businesslogik, die für die Steuerung der Praxisabläufe bei der Erstellung eines PoPP-Token benötigt wird.
   
2. PoPP-Client - enthält die Funktionalität für die Kommunikation des Basis-PS mit dem PoPP-Service. Dazu gehören die Anfrage zur Erzeugung von PoPP-Token für den eGK- und den GesundheitsID-Pfad und die Bereitstellung des PoPP-Token durch den PoPP-Service.
   Die Beschreibung und Anforderungen an den PoPP-Client finden sich in [gemILF_PoPP_Client],
3. ZETA Client - enthält die Funktionalität zur Erzeugung und Management der für den Zero Trust Ablauf notwendigen Identitäten und Abläufe gemäß [gemSpec_ZETA],
4. Anwendungs-Module zur Verwendung und Steuerung von TI-Anwendungen von (VSDM 2.0, ePA, E-Rezept).
3. PoPP-Modul für Versicherte (PoPP-Modul) - ist ein integriertes Anwendungsmodul, mittels dessen ein Versicherter das Check-in bei einer LEI mit seiner GesundheitsID starten kann. Die Beschreibung und Anforderungen an das PoPP-Modul finden sich in [gemSpec_PoPP_Modul]. Es ist denkbar, dass so ein PoPP-Modul von einer Kasse oder von einem weiteren Anbieter (bspw. Apotheken-App oder Videosprechstunden-App) für das Smartphone/Endgerät eines Versicherten, als Browser-Anwendung oder als Desktop-Anwendung bereitgestellt wird.

2.1 Überblick zum Ablauf eGK und GesundheitsID

Der Nachweis des Versorgungskontextes (PoPP-Token) erfordert die Authentifizierung von LEI und Versicherten. Die LEI authentifiziert sich mit ihrer SMC-B. Der Versicherte hat die Wahl und authentifiziert sich entweder mittels GesundheitsID oder seine eGK wird authentifiziert. Dieser Authentifizierungsprozess wird als Check-in bezeichnet.

Der Versicherte hat zudem die Wahl den Check-in von einer LEI durchführen zu lassen (dazu übergibt er die eGK und alles weitere führt der PoPP-Client durch) oder er initiiert den Check-in selbst mittels eines Smartphones, Laptops oder PCs (mobiler Check-in). Beim mobilen Check-in kommt auf dem Gerät des Versicherten das PoPP-Modul zum Einsatz. Der mobile Check-in ist für alle Versorgungskontexte verfügbar. Beispielsweise für Videosprechstunden-Anwendungen ist der mobile Check-in die einzig Möglichkeit, die den Versicherten für einen Check-in zur Verfügung steht.

Führt der Versicherte einen mobilen Check-in durch, dann werden dabei TAN erzeugt. Die TAN werden später in der LEI zur Herstellung des Versorgungskontextes verwendet. Dabei wird zwischen folgenden Typen von TAN unterschieden:

1. Die "lange" TAN (mit viel Entropie) ist dazu gedacht, mittels QR-Code Scanner von einem Primärsystem entgegengenommen zu werden. Eine "lange" TAN ist niemals an eine bestimmte LEI gebunden. Deshalb ist es möglich eine "lange" TAN in jeder LEI zur Erzeugung eines PoPP-Token zu verwenden
2. Die "kurze" TAN (kurze numerische Zeichenkette) ist dazu gedacht,  manuell ins System eingegeben zu werden. Eine kurze TAN ist stets an eine bestimmte LEI gebunden und es ist nur in dieser LEI möglich die "kurze" TAN erfolgreich zur Erzeugung eines PoPP-Token zu verwenden.

Technologieoffenheit

In diesem Dokument wird als kleinster gemeinsamer Nenner und zur Sicherstellung der Interoperabilität für die Übermittlung "langer" TAN mittels QR-Code beschrieben. Weil die gematik Technologieoffenheit unterstützt, steht die gematik weiteren Übertragungsverfahren offen gegenüber, bspw. NFC.

2.2 Überblick der Anwendungsfälle für die Ausstellung des PoPP-Token

Die in diesem Kapitel aufgeführten Anwendungsfälle schildern die Absichten des Nutzers in Verbindung mit dem Primärsystem und dienen als Lesehilfe zu den fachlichen Anwendungsfällen. Die Anwendungsfälle erheben keinen Anspruch auf Vollständigkeit.

Bei den Anwendungsfällen wird seitens der Versicherten die Verwendung der eGK oder der GesundheitsID unterschieden. Seitens der LEI wird unterschieden, ob der Versorgungskontext entsteht während Versicherter und LEI physisch gemeinsam anwesend sind (Praxisbesuch, Hausbesuch), oder ob die LEI virtuell anwesend ist, wie bspw. bei einer Videosprechstunde.

Tabelle 1: PoPP-Use Cases (Business Sicht)

Hinweis: Das vom PoPP-Service erstellte PoPP-Token enthält die Information, mit welcher Methode (siehe proofMethod im [Kapitel ]) der Versorgungskontext nachgewiesen wurde. Somit ist es den PoPP-Token nutzenden Anwendungen und Diensten möglich, in ihrem Anwendungs- oder Dienstkontext Autorisierungsentscheidungen aufgrund der Prüfmethode zu treffen. So kann beispielsweise aufgrund der Prüfmethode "healthid" eine Anwendung nur einen Teil, während aufgrund der Prüfmethode "ehc-practitioner" die Anwendungen alle Anwendungsfälle autorisiert.

2.3 Akteure und Rollen

Der PoPP-Service wird vom Anbieter PoPP-Service im Internet betrieben. Es müssen für die verschiedenen Betriebsumgebungen (Produktivumgebung (PU), Referenzumgebung(RU) und nach Bedarf die gemäß [gemKPT_Test] geforderten Test- und Referenzumgebungen (TU und RU DEV) jeweils voneinander unabhängige Instanzen betrieben werden. Für die Absicherung gegenüber dem Internet wird der von der gematik beigestellte ZETA Guard verwendet.

2.3.1 Herstellung und Betrieb

Folgende Rollen und Akteure kommen bei Herstellung und Betrieb des PoPP-Service vor.

Abbildung 2: Rollen und Akteure bei Herstellung und Betrieb des PoPP-Service

2.3.1.1 Hersteller PoPP-Service

Der Hersteller des PoPP-Service implementiert und entwickelt den PoPP-Service gemäß den Vorgaben der gematik. Er erwirkt eine Produktzulassung für den PoPP-Service.

2.3.1.2 Anbieter PoPP-Service

Der Anbieter PoPP-Service verantwortet und betreibt den zugelassenen PoPP-Service gemäß den Vorgaben der gematik. Dabei muss er für die Verbindungen ins Internet, den von der gematik beigestellten ZETA Guard verwenden.
Neben dem Betrieb von Instanzen für den Produktivbetrieb müssen weitere Instanzen für den Testbetrieb gemäß gemKPT_Test betrieben werden. 

2.3.1.3 gematik

Die gematik spezifiziert den PoPP-Service und schreibt die Entwicklung und den Produktivbetrieb des PoPP-Service aus.
Die gematik unterstützt den Hersteller PoPP-Service durch die Beistellung des ZETA Guard.
Darüber hinaus betreibt die gematik die Zero Trust Komponenten Policy Information Point (PIP) und Policy Administration Point (PAP): ZETA PIP und PAP Service. 

2.3.1.4 Primärsystem-Hersteller

PS-Hersteller setzen die PoPP-Client- und Trust Client-Funktionalität um. Sie nutzen den vom Anbieter in der RU bereitgestellten PoPP-Service, um ihre jeweilige Umsetzung zu testen.

2.3.1.5 Hersteller PoPP-Modul

Das PoPP-Modul ist eine Frontend-Komponente, über die Versicherte mit dem PoPP-Service interagieren und das für den mobilen Check-in verwendet wird. Das PoPP-Modul kann als Modul in einer Kassen-App oder in einer Drittanbieter-App integriert sein. Je nach Ausprägung sind Anforderungen an das PoPP-Modul zu erfüllen [gemSpec_PoPP_Modul]. 

2.3.1.6 Hersteller App

App Hersteller integrieren das PoPP-Modul eines PoPP-Modul Hersteller für einen mobilen Check-in Prozess. Sie entwickeln Funktionalität für die Präsentation und Übertragung von TAN aus dem Check-in Prozess an eine LEI. Sie nutzen den PoPP-Service in der RU, um die Funktionalität zu testen. Apps, welche ein PoPP-Modul integrieren, müssen sich die korrekte Implementierung durch die gematik bestätigen lassen (Bestätigungsverfahren).

2.3.1.7 Kostenträger (KTR)

Kostenträger übermitteln (oder beauftragen die Übermittlung von) Informationen zum Befüllen einer Datenbank an den PoPP-Service (siehe [Kapitel ]). Diese Informationen vereinfachen die kontaktlose Verwendung einer eGK im PoPP-Kontext. 

2.3.2 Nutzer

Folgende Rollen und Akteure kommen im Betrieb der Anwendung des PoPP-Service vor.

2.3.2.1 Leistungserbringerinstitution (LEI)

Die LEI nutzen den PoPP-Service, um eine Zugriffsberechtigung (PoPP-Token) bspw. für den Abruf von Daten eines Versicherten aus seiner ePA erzeugen zu lassen.   Dabei benutzt die LEI ein für die PoPP-Lösung angepasstes PS, in dem PoPP-Client-Funktionalität, Trust Client-Funktionalität und Funktionalität für eine Fachanwendung, die das PoPP-Token verwendet, implementiert ist.

2.3.2.2 Versicherte

Versicherte nutzen den PoPP-Service indirekt, wenn sie sich bei einer LEI einchecken oder auf andere Art und Weise bei der Erstellung des Versorgungskontext zwischen LEI und Versicherten mitwirken. Die Versicherten steuern ihre Krankenversichertennummer (KVNR) bei, indem sie sich:

1. über ihre GesundheitsID authentisieren,
2. oder sich mit ihrer eGK in der LEI vorstellen (Nutzung der Praxis Hardware für die Prüfung der eGK auf Authentizität),
3. oder sich per eGK mobil bei der LEI anmelden.
4. oder sich ein Vertreter per eGK mobil bei der LEI anmeldet. 

3 Systemkontext PoPP-Service

In diesem Kapitel findet sich die logische Zerlegung des Produkttyps Proof of Patient Presence (PoPP)-Service anhand eines Komponenten-Diagramms, die Beschreibung des Systemkontexts mit allen bereitstellenden Außenschnittstellen des PoPP-Service sowie die Auflistung und kurze Beschreibung der Nachbarsysteme. 

3.1 Produkt-Zerlegung und Außenschnittstellen

Der Produkttyp PoPP-Service besteht aus mehreren Komponenten. Die Komponenten für die Erstellung des PoPP-Token sind in PoPP-Service Resource Server zusammengefasst. Die Kommunikation zwischen LEI und PoPP-Service wird durch ein Zero Trust Access (ZETA) Guard abgesichert. Für die Kommunikationswege zwischen einem Versicherten und dem PoPP-Service wird ein weiterer Autorisierungsdienst, der PoPP-Service Authorization Server, benötigt, solange ein ZETA Guard diese Funktionalität noch nicht übernimmt.

Der PoPP-Service Resource Server besteht aus mehreren Komponenten für die Bearbeitung von Token Requests, bei denen die elektronische Gesundheitskarte (eGK) verwendet wird (eGK-Kommunikation, eGK-Hash-Datenbank, für den Support von kontaktlos angebunden eGK) und solchen, bei denen Versicherte die GesundheitsID verwenden (GesundheitsID-Flow, GesundheitsID-Session). 

Die Komponenten für die abschließende Token-Erstellung und Versichertenstammdatenmanagement-Prüfungsnachweis (VSDM-PN Erstellung) sowie der sichere Schlüsselspeicher gehören ebenfalls zum Produkttyp. Ferner gehören betriebliche Komponenten für die Erfassung und Aufbereitung von Monitoring Daten für die gematik Betriebsdatenerfassung (BDE) und ein Security Monitoring dazu.

Abbildung 3: Produkttypzerlegung 

Der PoPP-Service stellt folgende Außenschnittstellen bereit:

• I_PoPP_Token_Generation wird vom Primärsystem einer LEI verwendet um vom PoPP-Service ein PoPP-Token und ein VSDM-PN zu erlangen.

• I_PoPP_CheckIn_AuthorizationServer wird vom Versicherten für ein mobilen Check-in verwendet um vom PoPP-Service ein Access Token zu erlangen. Das Access Token wird für benötigt um den Resource Server des PoPP-Service nutzen zu können.

• I_PoPP_CheckIn_ResourceServer wird vom Versicherten verwendet. Der PoPP-Service Resource Server verlangt ein Access Token und liefert ein TAN-Set.
  

• I_PoPP_EHC_CertHash_Import wird von den TSPs der Kassen aufgerufen und dient der Befüllung der CertHash-Datenbank, mittels derer das Mapping von CV-Zertifikaten zu X.509-Zertifikaten von eGKs erreicht wird. Dies dient der Unterstützung von Anwendungsfällen bei denen der Versicherte die eGK mit einem kontaktlosen Kartenlesegerät der LEI verwendet.

Der PoPP-Service benutzt die folgenden Schnittstellen:

• IDP: Versicherten Authentisierung (sektorale IDPs)
  Wird im Anwendungsfall GesundheitsID für die Authentisierung der Versicherten vom PoPP-Service Authorization Server genutzt. Details siehe [gemSpec_IDP_Sek].
• ZETA PIP/PAP: GET/latest (update policies) (gematik)
  Wird vom ZETA Guard für die Versorgung mit den stets aktuellen Zugriffs-Policies und weiteren Konfigurationsdaten genutzt (Details siehe [gemSpec_ZETA]).
• I_OCSP_Status_Information:
  Wird vom PoPP-Service für die Statusabfragen für eGK (PoPP-Service Resource), für SM(C)-B (ZETA Guard), für die eigenen TI 1.0 PoPP-Token-Signatur-Identität und das eigene Internet-TLS-Server-Zertifikat verwendet.
• I_OpsData_Update:
  Wird vom PoPP-Service für die Lieferung von Betriebsdaten verwendet.

Für den PoPP-Service Anbieter wird eine interne Schnittstelle angeboten:

• PoPP-Service Anbieter Konfig-Schnittstelle
  Interne Schnittstellen, die vom PoPP-Service Anbieter genutzt wird um den PoPP-Service zu konfigurieren 

3.2 Systemkontext

Ein Systemkontext beschreibt die Umgebung, in der ein System operiert, und die Interaktionen zwischen dem System und externen Entitäten. 

Abbildung 4: Systemkontext PoPP-Lösung

Die obige Abbildung zeigt die vom PoPP-Service Anbieter verantworteten Komponenten und Interaktionen. Die zum ZETA Guard gehörenden Komponenten sind in orange dargestellt, die Komponenten, welche die PoPP Businesslogik implementieren sind in grün dargestellt. Dargestellt sind zusätzlich heute bereits vorhandene und genutzte Komponenten und Dienste, die für die Nutzerauthentisierung (bspw. eGK und IDP) bzw. die Betriebsüberwachung (bspw. mittels Betriebsdatenerfassung - kurz BDE) in Anwendungsfällen der TI 2.0 weitergenutzt werden können (grau). 

Das PS mit den beiden integrierten Modulen PoPP-Client und Trust Client triggert über verschiedene Aufrufwege die Anwendungsfälle (1), (2) und (3), nachdem bspw. eine LEI einen Check-in-Vorgang für einen Patienten initiiert hat. Die PoPP-Client Funktionalität verantwortet die fachlichen Abläufe zur PoPP-Token-Erstellung.

Die ZETA Client Funktionalität verantwortet die für Zero Trust relevante Kommunikation mit dem PoPP-Service. Dabei greift sie auf eine freigeschaltete SM(C)-B zu und benutzt diese zur Authentifizierung für die Registrierung (x.1) und Anmeldung (x.2) im Policy Decision Point (PDP) des ZETA Guard. Dabei wird ein PoPP-Client Access Token erzeugt, das für die weiteren Business-Logik Aufrufe (PoPP-Client Funktionalität) verwendet wird. Diese erfolgen dann über den Policy Enforcement Point (PEP) des ZETA Guard.

Tabelle 2: Kurzbeschreibung der Komponenten in der PoPP-Lösung

3.3 Nachbarsysteme

In der Abbildung "Systemkontext PoPP-Lösung" sind die Nachbarsysteme des PoPP-Service dargestellt: 

• Sektoraler IDP:
  verantwortlich für die Authentisierung eines Versicherten mit GesundheitsID, 
• OCSP-Responder des TSP für SM-B:
  im Internet verfügbar für die OCSP-Prüfung von SM-B durch den ZETA Guard,
• OCSP-Responder des TSP für eGK:
  im Internet verfügbar für die OCSP-Prüfung von eGK durch den PoPP-Service,
• OCSP-Responder des TSP für Komponenten PKI:
  im Internet verfügbar für die OCSP-Prüfung des TI 1.0 Komponenten Zertifikats der PoPP-Service Identität, verwendet bei der Signatur der Application Protocol Data Units (APDU) im eGK-Ablauf,
• OCSP-Responder Internet-CA:
  im Internet verfügbar für die OCSP-Prüfung des TLS-Internet-Zertifikats des PoPP-Service (für die Client-Schnittstelle)
• die gematik stellt folgende Dienste bereit:
  PIP und PAP Service für Zero Trust, git-Repository für die ZETA Guard Images, Überwachung und Betriebsdatenerfassung: BDE und Telematikinfrastruktur Security Information and Event Management (TI-SIEM).

In der Abbildung "Systemkontext PoPP-Lösung" sind folgende nutzende Systeme nicht dargestellt:

• Fachanwendungen und FD im Internet, sowie Dienste und Komponenten, die noch in der TI 1.0 verortet sind, wie E-Rezept-FD, ePA < 3.x:
• VSDM 2.0,
• "ePA für alle": Kann PoPP-Token oder VSDM-PN nutzen, abhängig von der ePA-Entwicklungsstufe,
• E-Rezept: Kann ebenfalls PoPP-Token oder VSDM-PN nutzen, abhängig von der eRp-FD- Entwicklungsstufe.

Außerdem sind die App-Backend-Systeme der nicht abgebildet.

4 Funktionale Anwendungsfälle des PoPP-Service

In diesem Kapitel werden die Anwendungsfälle beschrieben, die von der Proof of Patient Presence (PoPP)-Lösung abgedeckt werden. Die Anwendungsfälle zum mobilen Check-in mit elektronischer Gesundheitskarte (eGK) oder GesundheitsID resultieren in einer Transaktionsnummer (TAN), welche in einem weiteren Anwendungsfall in ein PoPP-Token eingetauscht werden kann. Der Anwendungsfall eines Check-in mit eGK direkt bei der Leistungserbringerinstitution (LEI) führt hingegen direkt zur Ausstellung einen PoPP-Token für die LEI. 

Neben der Erstellung eines PoPP-Token wird auch die Registrierung und Anmeldung der LEI betrachtet. Ausgangspunkt sind die PoPP-Use Cases aus Tabelle "PoPP-Use Cases (Business Sicht)".

4.1 Übersicht der Systemanwendungsfälle für die Ausstellung des PoPP-Token

Die Anwendungsfälle für die Ausstellung eines PoPP-Token lassen sich in drei Gruppen einteilen:

• Anwendungsfälle zur Authentisierung einer LEI,
• Anwendungsfälle, wie sich ein Versicherter für die Ausstellung des PoPP-Token authentisiert,
• Anwendungsfälle, die beschreiben, wie die Ausgabe des PoPP-Token an das PS einer LEI erfolgt.

Abbildung 5: Anwendungsfälle zur Attestierung des Versorgungskontextes

Zur Umsetzung der in der Tabelle "PoPP-Use Cases (Business Sicht)" dargestellten Use Cases ist der Ablauf folgender Anwendungsfall-Ketten erforderlich:

Tabelle 3: Zuordnung der Anwendungsfälle zu den Use Cases

Nach dem mobilen Check-in stehen den Versicherten im PoPP-Modul seiner App TANs zur Verfügung.

Bei den Use-Cases  UC_PoPP_1a, UC_PoPP_2a, UC_PoPP_3a und UC_PoPP_3c sind im PoPP-Modul mehrere "lange" TAN in einem TAN-Set verfügbar.

Bei den Use-Cases  UC_PoPP_1b, UC_PoPP_2b, UC_PoPP_3b und UC_PoPP_3d  ist im PoPP-Modul nur eine einzelne "kurze" TAN verfügbar, die ist stets nur von genau einer LEI gegen ein PoPP-Token einlösbar ist. 

Der Use-Case UC_PoPP_1a deckt auch den Sachverhalt ab, wenn ein Versicherter bspw. in einem Ärztehaus mehrere LEI aufsucht.

Der Use-Case UC_PoPP_2a deckt auch den Sachverhalt ab, dass beispielsweise ein Versicherter nacheinander von mehreren Leistungserbringern zu Hause besucht wird. 

Der Use-Case UC_PoPP_3a deckt auch den Sachverhalt ab, dass beispielsweise ein Versicherter nacheinander bei mehreren LEIs in einer Videosprechstunde vorspricht.

Die benannten Anwendungsfälle werden in den nachfolgenden Kapiteln beschrieben. Anwendungsfälle werden wie Anforderungen behandelt, das heißt, die beschriebenen Sequenzen und Abläufe sind normativ.

4.2 Leistungserbringerinstitution (LEI) am PoPP-Service registrieren und anmelden

Um mit dem PoPP-Service arbeiten zu können, muss sich das PS einer LEI am PoPP-Service registrieren und anmelden. Die Registrierung erfolgt einmalig mit dem ZETA Client im PS unter Verwendung des Zero Trust Access (ZETA) Guard des PoPP-Service. 
Die Anmeldung für registrierte PS erfolgt über seine Authentifizierung gemäß [gemSpec_ZETA] mindestens einmal täglich.

Die Registrierung und die Anmeldung der LEI erfolgen implizit bei der Verwendung des PoPP-Service zur Erstellung eines PoPP-Token. Seitens der LEI ist eine freigeschaltete SM(C)-B erforderlich. Sind diese Voraussetzungen gegeben, kann beim Check-in von Versicherten in der LEI dann der Versorgungskontext mit einem PoPP-Token attestiert werden.

Die Anforderungen und Abläufe für die Registrierung der LEI sind in [gemSpec_ZETA#Kap. Ablauf der SM-B Authentifizierung mit DPoP] beschrieben. Im Ergebnis der LEI-Registrierung und -Anmeldung liegt im PS ein Access Token mit Demonstrating Proof of Possession (DPoP) Bindung vor, mit welchem der funktionale Zugriff des PS auf den PoPP-Service erlaubt wird.

Sobald ein PS am PoPP-Service erfolgreich registriert wurde und angemeldet ist, kann es PoPP-Token erzeugen lassen bzw. abrufen.

4.3 Mobiler Check-in und Ausgabe des PoPP-Token

Versicherte haben die Möglichkeit, sich unabhängig vom Ort für eine Leistungserbringung anzumelden (mobiler Check-in). Der mobile Check-in erfolgt dabei unter Verwendung einer Anwendung, die ein PoPP-Modul integriert (siehe [gemSpec_PoPP_Modul]). Als Ergebnis einer Autorisierungsanfrage des PoPP-Moduls an den PoPP-Service Authorization Server kann das PoPP-Modul die Ausstellung einer TAN beim PoPP-Service selbst beantragen. Die Konstellation für die Ausstellung einer TAN unterscheiden sich in den Punkten:

• Hat die App mit integrierte PoPP-Modul das Bestätigungsverfahren erfolgreich durchlaufen?
• Handelt es sich um ein virtuelles Anwendungsszenario wie Videosprechstunde oder Online-Apotheke oder ist der mobile Check-in die Vorbereitung einer Vorstellung am Ort der Leistungserbringung (Praxis, Klinik)?
• Ist die LEI zum Zeitpunkt des Check-in bekannt?
• Welche Übertragungskanäle bietet die LEI für eine Übertragung einer TAN an?

Starten die Versicherten den Check-in-Prozess über das in eine App integrierte PoPP-Modul, so ist sowohl eine Authentisierung mit GesundheitsID als auch mit eGK (mobil) über direktes Auslesen durch den PoPP-Service Resource Server möglich.

Nach erfolgreicher Authentisierung mit GesundheitsID oder eGK (mobil) werden vom PoPP-Service Authorization Server Access Token erstellt, mit denen autorisierte Zugriffe auf die Schnittstellen des PoPP-Service Resource Server durch das PoPP-Modul durchgeführt werden.

Reicht das PoPP-Modul ein Access Token für eine Authentifizierung der eGK (mobil) beim PoPP-Service Resource Server ein ("card-check" Access Token), so führt dieser eine Kartenprüfung durch Ansprechen der eGK-Schnittstellen durch und entnimmt die notwendigen Daten des Versicherten aus der eGK.

Reicht das PoPP-Modul ein Access Token nach erfolgreicher Authentisierung mit GesundheitsID beim PoPP-Service Resource Server ein ("eHealth-ID-check" Access Token), so enthält des Access Token bereits die Daten zum Versicherten aus dem vom sektoralen Identity Provider (sektoralen IDP) ausgestellten ID Token (siehe [gemSpec_IDP_Sek]).

Über das in eine App integrierte PoPP-Modul ist es möglich ein TAN-Set mit "langen" TAN vom PoPP-Service ohne Kenntnis der LEI zu beziehen, bei der die TAN später eingesetzt werden sollen. Ebenso ist eine Auswahl einer LEI direkt beim Check-in möglich. Das PoPP-Modul erhält dann einen "kurze" TAN vom PoPP-Service Resource Server, welche nur bei dieser LEI einlösbar ist. 

Die folgende Abbildung zeigt die Abläufe je nach Konstellation des PoPP-Modul.

Abbildung 6: Abläufe Check-in für unterschiedliche Konstellationen  

In den folgenden Abschnitten werden die Anwendungsfälle und detaillierten Abläufe beschrieben.

4.3.1 Mobiler Check-in mit GesundheitsID

Ein Versicherter kann die Authentisierung mit seiner GesundheitsID nutzen, um sich in einer LEI oder außerhalb einer LEI (bspw. für eine Videosprechstunde) anzumelden. Zum Zeitpunkt der Anmeldung muss der Versicherte nicht notwendigerweise Informationen über die LEI zur Verfügung haben. Vielmehr wird ihm im Zuge der Anmeldung eine TAN oder ein TAN-Set  bestehend aus mehreren TAN (TAN Repräsentation in Form eines QR-Code oder einer Zeichenkette) übermittelt, welches er anschließend bei einer LEI vor Ort oder virtuell -bspw. für eine Videosprechstunde- einlösen kann.

Vor der Ausstellung einer TAN bzw. eines TAN-Sets muss sich der Versicherte authentifizieren. Als Ergebnis einer erfolgreichen Authentifizierung wird ein vom PoPP-Service Authorization Server ein "eHealth-ID-check" Access Token ausgegeben, mit dem das integrierte PoPP-Modul die Ausstellung einer TAN beim PoPP-Service einfordern kann.

Abbildung 7: Ausstellen und Einlösen eines "eHealth-ID-check" Access Token 

4.3.2 Mobiler Check-in mit eGK

Ein Versicherter mit eGK befindet sich außerhalb einer LEI (bspw. für eine Videosprechstunde) und nutzt die eGK mit seinem Smartphone, um sich anzumelden. Zum Zeitpunkt der Anmeldung muss der Versicherte nicht notwendigerweise Informationen über die LEI zur Verfügung haben.  Vielmehr wird ihm im Zuge der Anmeldung je nach Anfrageinhalten des PoPP-Modul eine "kurze" TAN oder ein TAN-Set bestehend aus mehreren "langen" TAN übermittelt. Die TAN können in Form eines QR-Code oder einer Zeichenkette im PoPP-Modul präsentiert werden.  

Abbildung 8: Ausstellen und Einlösen eines "card-check" Access Token 

4.3.3 PoPP-Token mittels TAN, lokal

Abbildung 9: Ausstellung PoPP-Token durch LEI über Einlösen einer TAN durch Versicherten am Ort der Leistungserbringung

4.3.4 PoPP-Token mittels TAN, mobil

Der Anwendungsfall zum Einlösen einer TAN und Ausstellen eines PoPP-Token für eine Videosprechstunde ist exemplarisch für den Fall, dass der LE, bzw. die LEI nicht physisch mit dem Versicherten in Kontakt ist, sondern die Kommunikation virtuell erfolgt.
Hier wird der Ablauf beschrieben, wenn eine App (z.B. Videosprechstunde) ein PoPP-Modul für den Check-in für die Versicherten anbietet und die TAN über angebotene Kommunikationskanäle an einen PoPP-Client übertrgt.

Abbildung 10: Ausstellung PoPP-Token durch LEI über Einlösen einer TAN durch Versicherten mobil (Videosprechstunde, Apotheken)

4.4 Check-in in einer LEI mit eGK und Ausgabe des PoPP-Token

Bevor der PoPP-Service für eine LEI ein PoPP-Token erstellt, ist es erforderlich, dass sich die LEI mit Hilfe der SM-B beim PoPP-Service authentisiert. Des Weiteren ist es erforderlich die Anwesenheit einer eGK nachzuweisen. Der dazu verwendete PoPP-Client ist Bestandteil des PS.

Abbildung 11: Ausstellung PoPP-Token nach Stecken der eGK in LEI

5 Übergreifende Festlegungen

5.1 PoPP-Token: Nachweis des Versorgungskontextes

Die Funktionalität "PoPP-Token: Nachweis des Versorgungskontextes" stellt auf Anforderung von PoPP-Clients ein PoPP-Token sowie einen Datensatz "Prüfungsnachweis" gemäß der VSDM-Spezifikation bereit ("VSDM+"). Das PoPP-Token ist ein kryptografisch gesicherter Nachweis eines Versorgungskontextes über zwei Identitäten des Gesundheitswesens (Versicherte und LEI). Der VSDM-Prüfungsnachweis (VSDM-PN) ist ein kryptografischer Nachweis ausschließlich über eine Versichertenidentität und wird lediglich für eine Übergangszeit zusätzlich ausgestellt, um Fachdiensten der TI die Migration vom VSDM-Prüfungsnachweis hin zum PoPP-Token zu erleichtern.

Damit ist die zentrale Businesslogik des PoPP-Service beschrieben. Die weiteren Funktionsmerkmale, die für die Erstellung eines PoPP-Token in den unterschiedlichen Konstellationen benötigt werden, sind logisch in den Kapiteln für den PoPP-Resource Server gefasst.

5.1.1 PoPP-Token-Erstellung

In diesem Kapitel sind die Anforderungen an den PoPP-Service zusammengefasst, die für das Erstellen eines PoPP-Token notwendig sind. Für die Bedingungen, unter denen der PoPP-Service einen PoPP-Token ausstellt, siehe [Kapitel ].

Tabelle 4: PoPP-Token Claims (informativ)

Tabelle 5: PoPP-Token Header (informativ)

Informatives Beispiel für einen PoPP-Token: 

{
  "typ": "vnd.telematik.popp+jwt",
  "alg": "ES256",
  "kid": "x_vW4LVDipvu8iUQ5alKsZLWtH6jh4eJ4c5offXtMV0"
} 
.
{
  "iat": 1722593256,
  "iss": "https://popp.example.com",
  "proofMethod": "ehc-practitioner-trustedchannel-read-x509",
  "patientProofTime": 1722593255,
  "patientId": "X123456789",
  "insurerId": "123456789",
  "actorId": "1-2012345678",
  "actorProfessionOid": "1.2.276.0.76.4.50"
}

(Signatur vernachlässigt)

Informatives Beispiel für einen PoPP JWK-Set

{
  keys: [
    {
      "kid": "DCHf2-6iG5gC5cPxrMKtfZgolieCU_RBZfvwREKPdWc",
      "use": "sig",
      "kty": "EC",
      "crv": "P-256",
      "x": "C3Q12wBw1K49LCeJBjDNhT_0TmWe6zZ_8pUNLF7IEfE",
      "y": "5CNecFczEOzRPhsuXeDXxJyFjGOvfIgcXqKkst6csto",
      "alg": "ES256",
      "x5c": [
        "MIICBzCCAa6gAwI..."
      ]
    }
  ]
}

 Hinweis: Siehe auch Tabelle "Entity Statement des PoPP-Service als Protected Resource" im Anhang.

Hinweis: siehe auch [jwk-set+jwt].

5.1.2 PoPP-Token Prüfung

Das Kapitel enthält die Anforderungen an die Systeme, die PoPP-Token verifizieren und verarbeiten. Dabei sind zwei Wege der Verifikation möglich: via Entity Statement, welches auf den Vertrauensanker des Federation Masters rückführbar ist und via TI-PKI mit der TSL als Vertrauensanker. Dienste die einen PoPP-Token verifizieren, werden im Folgenden als "PoPP-Verifier" bezeichnet.

Hinweis: Der OCSP-Responder ist im Internet erreichbar. Die Adresse des OCSP-Responders ist dem Authority Information Access (AIA) des Zertifikats zu entnehmen.

Hinweis: Die Liste der registrierten TI-Teilnehmer kann unter [https://app.federationmaster.de/federation/list] abgerufen werden.

Hinweis: Die vollständige Liste der Claims und ihrer Ausprägung sind in [A_26431*] spezifiziert.

Ab diesem Punkt kann das PoPP-Token fachlich verarbeitet werden. Die Informationen aus dem PoPP-Token, insbesondere die Patienten- und Leistungserbringer-Identifikation, können zur Autorisierung von Zugriffen auf medizinische Daten verwendet werden.

5.1.3 Ersatz-Prüfungsnachweis (VSDM-PN)

Es kann der Fall eintreten, dass Fachdienste, die heute eine Zugriffsautorisierung via VSDM-Prüfungsnachweis ("VSDM+") durchführen (E-Rezept und ePA-für-Alle), nicht unmittelbar auf die Nutzung von PoPP-Token umschwenken können (bspw. auf Grund der notwendigen Anpassungsbedarfe in den Diensten und den sich anschließenden Nachweis- und Zulassungsverfahren). Wenn dann die Fachdienste des VSDM ihren Betrieb einstellen, stünde für den E-Rezept und die ePA-für-Alle Fachdienste kein Mechanismus zur Zugriffsautorisierung zur Verfügung.

Deshalb soll für die Zeit der Migration von der Zugriffautorisierung via "VSDM+" auf PoPP-Token für eine Übergangszeit auch vom PoPP-Service zusätzlich noch ein VSDM-Prüfungsnachweis (identisch zu dem von den VSDM-Fachdiensten ausgestellten Prüfungsnachweis, "VSDM+") erzeugt werden. Dieser Ersatz-Prüfungsnachweis wird im Folgenden mit VSDM-PN bezeichnet. Dieses Migrationsverfahren tritt nur temporär in Kraft und nur für den Zeitraum zwischen Start der Verfügbarkeit von PoPP-Service inklusive VSDM 2.0 und der Bereitstellung der Zugriffsautorisierung mittels PoPP-Token bei E-Rezept und ePA-für-Alle. Sobald also diese Fachdienste den Abruf mittels PoPP-Token produktiv anbietet, wird dieses Verfahren (zusätzliche Bereitstellung VSDM-PN) ersatzlos eingestellt.

Zur Funktionsweise:

Der PoPP-Service wird vorübergehend unter Ersatzvornahme für einen VSDM-Betreiber die Prüfziffer im Kontext der TI 2.0 erstellen. Dazu wird er als weiterer Betreiber einen HMAC-Schlüssel generieren und dem E-Rezept-FD, bzw. den ePA-Aktensystemen zur Verfügung stellen. Siehe [Kapitel ].

Der PoPP-Service erzeugt bei der Token-Erstellung zusätzlich gemäß [A_26368*] mittels des ihm vorliegenden HMAC-Schlüssels eine gültige Prüfziffer für seine eigene Betreiberkennung und daraus einen VSDM-Prüfungsnachweis.

Dieser Prüfungsnachweis wird analog zum PoPP-Token an das aufrufende Primärsystem (PoPP-Client) übertragen. Das PS ist dadurch in der Lage, mit dem strukturierten Prüfungsnachweis des PoPP-Service beispielsweise einen E-Rezept-Abruf auszuführen, auch wenn der E-Rezept-Fachdienst PoPP noch nicht unterstützt.

Zu Rahmenbedingungen:

Sobald der Anbieter des PoPP-Service diese Funktionalität bereitstellt, gelten für ihn ebenfalls die Anforderungen zur sicheren Aufbewahrung, Übermittlung und Verarbeitung des HMAC-Schlüssels. Siehe auch in [gemSpec_Krypt#A_23460*, A_23461*, A_23463*].

Die Bereitstellung dieser Funktionalität ist temporär begrenzt und endet, sobald die Vornahme des E-Rezept-Abrufs mittels PoPP-Token erfolgen kann, die ePA-Aktensysteme vollständig umgestellt sind und der Rollout der angepassten PS abgeschlossen ist.

Die Nutzung des Ersatznachweises soll LEIs ausschließlich zur fachlichen Nutzung von E-Rezept und ePA-für-Alle zur Verfügung stehen, damit die Versorgungsqualität in der Migrationsphase von VSDM 1.0 zu VSDM 2.0 nicht beeinträchtigt wird. 

Die Nutzung des Ersatznachweises VSDM-PN als Abrechnungsnachweis ist nicht erlaubt. Die Durchsetzung des Verbotes erfolgt durch organisatorische Maßnahmen der KTR.

5.1.3.1 Aufbau des VSDM-PN

Es wird für den Aufbau der Prüfziffer und des VSDM-PN der aus den VSDM1.0-Dokumenten hervorgehende Aufbau nachgenutzt. Dabei werden zum Teil aber feste Werte vorgegeben für Felder, die im VSDM1.0-Fall vom VSDM-Fachdienst oder VSDM-Fachmodul dynamisch vergeben werden.

Für die Erzeugung des VSDM-PN gelten entsprechend die folgenden Festlegungen, wobei die beim VSDM1.0 getrennt von Fachdienst und Fachmodul durchzuführenden Tätigkeiten zusammengefasst wurden.

Beispiel für einen Prüfungsnachweis aus dem E-Rezept-Kontext, bei dem in der Prüfziffer die Betreiberkennung "T" verwendet wurde:

H4sIAAAAAAAAAB2N3U6DMABGX4X01khbCM6YtssiNf5RRFiXeGPAdghbC1pk4tPb7Oa7OMl3Dln/mmMw62/XDZYCHCIQaPsxqM62FGyru8trELiptqo+DlZTsGgH1oy8iMAfraPgc5rGGwhPLmy1qafuECoN9zWcnTJwtCc4n6W3afYu+Wv5kItzxjNGqpJFKIpRgq/QCsV4RaBHhLOIQO4jb0ymGyR6jrK+SPKKR3laLFm/wXmlpEzvHy+K7V+72zX78qkZXaKbRfAvYw5KPsf4J6MEeokfwf4Bl4Neo+oAAAA=

5.1.3.2 Vorgaben zum VSDM-PN-HMAC-Sicherungsschlüssel

In diesem Kapitel sind die Vorgaben zur Erzeugung und Verteilung des HMAC-Sicherungsschlüssels für die Prüfziffer innerhalb des VSDM-PN zusammengefasst.

Hinweis: Weitere Vorgaben zum HMAC-Schlüssel befinden sich in [gemSpec_Krypt#Kapitel HMAC-Sicherung der Prüfziffer VSDM].

Hinweis: Zwischen Erzeugung und Verwendung vergeht eine gewisse Zeit, bis der neue VSDM-PN-HMAC-Schlüssel bei allen Fachdiensten importiert wurde. Erst wenn alle Fachdienste den erfolgreichen Import gemeldet haben, kann der neue Schlüssel verwendet werden.

Hinweis: Im Export-Paket wird das Ablaufdatum (exp) des VSDM-PN-HMAC-Schlüssels angegeben, während als Schlüsselattribut das Erzeugungsdatum gespeichert wird. Da der Schlüsseltausch jährlich erfolgen muss, wird als Ablaufdatum das Datum der Erzeugung plus ein Jahr verwendet.

Hinweis: Wenn nach einem VSDM-PN-HMAC-Schlüsselwechsel in einem FD dieser neue VSDM-PN-HMAC-Schlüssel eingebracht worden ist und der alte VSDM-PN-HMAC-Schlüssel im FD gelöscht wurde, dann haben alte VSDM-PN-HMAC-Schlüssel keinen Schutzbedarf bezüglich Vertraulichkeit mehr.

Hinweis: Vergleiche auch [A_26960*] bzgl. Einbindung der Zertifikate in das VAU-Image.

Hinweis: Die gematik stellt Beispiel-Code für die Erzeugung eines Export-Pakets bereit. Für die Übermittlung und Verarbeitung des VSDM-PN-HMAC-Schlüssels gelten in der [gemSpec_Krypt#A_23460*, A_23461*, A_23463*].

5.2 Datenschutz und Sicherheit

Der PoPP-Service ist frei im Internet erreichbar und muss entsprechend seine Außenschnittstellen vor Angriffen und unberechtigten Zugriffen schützen. Dies geschieht im Sinne der TI 2.0 über die Zero Trust Mechanismen bzw. konkret durch das Einbinden des von der gematik bereitgestellten ZETA Guard.
Der PoPP-Service verarbeitet Daten, aus denen genau nachvollziehbar ist, welche Versicherten bei welchen LEI in Behandlung sind. Bereits im Einzelnen, insbesondere aber in der Summe mehrerer solcher Daten pro Versicherten (Profilbildung) sind damit Rückschlüsse auf medizinische Sachverhalte möglich. Daher sind die vom PoPP-Service verarbeiteten Daten, als personenbezogene medizinische Daten zu bewerten. Zudem hat der PoPP-Service Zugriff auf den privaten Signaturschlüssel um PoPP-Token zu erstellen, über die wiederum Zugriffe auf medizinische Daten der Versicherten möglich werden. Daher müssen Zugriffe des Betreibers auf diese Daten mit technischen Mittel verhindert werden, weshalb der PoPP-Service innerhalb einer VAU laufen muss.
Da der ZETA Guard die von den LEI eingehenden TLS-Verbindungen terminieren muss, um die eingehenden Daten analysieren zu können, hat er rein technisch Zugriff auf alle übertragenen Daten im Klartext. Daher muss der ZETA Guard innerhalb der VAU laufen (vgl. [gemSpec_ZETA#A_25608]).

Hinweis: Der ZETA Guard führt bereits eine gewisse Angriffserkennung durch, jedoch kann er die eingehenden Daten nicht entsprechend den erwarteten Schemata/Mustern bewerten, da diese nur dem PoPP-Service bekannt sind (siehe Kommentar zu in [gemSpec_ZETA#A_25406*]). Zudem werden Anfragen von Versicherten über ein PoPP-Modul nicht über den ZETA Guard geleitet, sondern direkt vom Authorization Server des PoPP-Service entgegen genommen.
Es sind [A_25421*] und [A_26612*] zu berücksichtigen.

Hinweis: Somit können von einer LEI maximal 100 Aufrufe mit falschen TAN pro Stunde getätigt werden.

Hinweis: Bzgl. verschlüsselter Speicherung inkl. Integritätsschutz siehe [A_26603*, A_26604*, A_26605*]. Bzgl. Einträgen in die eGK-Hash-Datenbank siehe Absatz [Kapitel ]. Von [A_26472*] ausgenommen ist zum einen für die Funktionalität notwendiges Schlüsselmaterial und zum anderen Monitoring-Daten, die durch andere Anforderungen gefordert werden.

5.2.1 Vertrauenswürdige Ausführungsumgebung (VAU)

5.2.1.1 Allgemein

Der PoPP-Service wir innerhalb einer Vertrauenswürdigen Ausführungsumgebung (VAU) betrieben. Dies betrifft alle Komponenten des PoPP-Service: ZETA Guard, PoPP-Service Authorization Server und PoPP-Service Resource Server.
Die VAU besteht aus der Summe von Maßnahmen in Software und Hardware, die den Schutz vor unberechtigten Zugriffen des Anbieters/Betreibers eines TI-Dienstes auf schützenswerte Daten und Schlüssel gewährleisten. Die Software besteht aus dem VAU-Image, das vom Hersteller bereitgestellt wird und aus dem die Verarbeitungskontexte der VAU im Betrieb gestartet werden. Innerhalb eines gestarteten Verarbeitungskontextes werden dann die schützenswerten Daten verarbeitet bzw. kann aus diesem Verarbeitungskontext auf schützenswerte Schlüssel zugegriffen werden. Diese schützenswerten Schlüssel werden in einem Hardware Security Module HSM gespeichert und ebenso werden im HSM Prüfungen zur Validierung von VAU-Images durchgeführt.

Die Sicherheitsleistung beruht u. a. auch auf der Nutzung Hardware (HW)-naher Funktionen, weshalb auch die zugrundeliegende Hardware zur VAU gehört und somit Teil des Produkts ist.

Hinweis: Die Spezifikation fordert gewisse Konfigurations- und Import-Möglichkeiten an der VAU für den Anbieter.
Der Schutz vor Angriffen an den Außenschnittstellen erfolgt zum Teil über den ZTC und ist zudem in [A_26470*] geregelt.

5.2.1.2 Einbinden des ZETA Guard der gematik

Der PoPP-Service verwendet als TI 2.0-Service die Mechanismen des Zero Trusts für die Zugriffskontrolle. Dazu wird von der gematik zentral ein Software-Image für den ZETA Guard bereitgestellt, der von den Diensten der TI 2.0 eingebunden wird.

Für die Funktionsfähigkeit des ZETA Guard muss dieser den TLS-Kanal terminieren um die notwendigen Daten für die Zugriffsentscheidung zu erhalten und auswerten zu können. Bei PoPP fungiert TLS als VAU-Kanal, muss also innerhalb eines Verarbeitungskontextes (VK) der VAU terminieren. Entsprechend muss der ZETA Guard ebenso als Verarbeitungskontext (entweder als eigener VK oder als Teil eines Gesamt-VK mit der PoPP-Logik zusammen) in der VAU betrieben werden.

Da der von der gematik bereitgestellte ZETA Guard ein reines Docker-Image ist, muss es vom Hersteller PoPP in die Lage versetzt werden, als VAU-Image in der VAU des PoPP-Service importiert werden zu können und dort lauffähig zu sein.

Der ZETA Guard ist also so im Build-Prozess zu berücksichtigen, dass dieser ohne manuelle Anpassungen am Code automatisiert integriert werden kann. Da häufige Updates des ZETA Guard zu erwarten sind (insbesondere schnelle Patches bei neuen, relevanten CVE), ist ein manueller Anpassungsprozess zur Herstellung der Kompatibilität des ZETA Guard zur VAU des PoPP-Service inakzeptabel.

Im Folgenden wird das System, dass den Prozess zur Erzeugung von VAU-Images umsetzt und dabei automatisiert den ZETA Guard einbindet VAU-Image-Build-Pipeline genannt.

Hinweis: Der in der zweiten Variante ("oder") genannte Vertrauensanker wird bei der gegenseitigen Authentifizierung bei der Kommunikation Verarbeitungskontext-zu-Verarbeitungskontext verwendet. Die Identitäten des jeweiligen Verarbeitungskontextes und die ausstellende CA sind auf dem HSM der VAU gespeichert [A_26610*] und werden bei der initialen Zeremonie [A_26623*] erzeugt. Dabei wird der öffentliche Schlüssel der CA exportiert, der dann als Vertrauensanker in die VAU-Images eingebracht wird. Die Authentifizierung eines anderen Verarbeitungskontext ist in ersterer Variante ("entweder") nicht notwendig, da die Kommunikation ZETA Guard<=>PoPP-Service-Logik dort innerhalb des Verarbeitungskontext stattfindet.

Ggf. ist zudem der Import eines Vertrauensankers für die Kommunikation zum HSM (Authentifizierung des HSM durch den Verarbeitungskontext) notwendig. Es kann hier dieselbe CA verwendet werden (so ist es im Hinweis unter [A_26623*] beschrieben). Grundsätzlich sind aber auch andere Methoden zur Etablierung eines beidseitig authentisierten Kanals zwischen Verarbeitungskontext und HSM möglich, solange der Verarbeitungskontext das HSM eindeutig authentifizieren kann.

Die VAU-Image-Build-Pipeline muss im Rahmen der Produkt-Begutachtung des PoPP-Service geprüft werden. Der ZETA Guard selbst hat einen von der gematik abgenommenen Sicherheitsnachweis (Produktgutachten). Daher muss dieser bei dem beschriebenen Vorgehen nicht noch einmal sicherheitstechnisch betrachtet werden.

5.2.1.3 Informative Erläuterung zu den Zielen der VAU und den konkreten Umsetzungshinweisen

Das Ziel der VAU ist der Ausschluss unberechtigter Zugriffe des Anbieters/Betreibers des Dienstes auf schützenswerte Daten und Schlüssel. Darüber hinaus sind die Sicherheitsanforderungen an die VAU und die Anforderungen an die Qualität der sicherheitstechnischen Begutachtung der genutzten Hardware und Software geeignet, auch gegen unberechtigte Zugriff anderer Angreifer zu schützen.

Bei PoPP sind die zu schützenden Daten zum einen die Information, welche Versicherten zu welchem Zeitpunkt welche LEI aufsuchen, woraus ein detailliertes Profil mit Rückschlüssen auf medizinische Daten des Versicherten erstellt werden kann. Zum anderen ist dies der PoPP-Token-Signaturschlüssel, mit dem PoPP-Token erzeugt werden können, die wiederum für den Zugriff auf medizinische Daten von Versicherten autorisieren.

Die zu berücksichtigen Angriffsszenarien schließen auch Zugriffe durch einzelne Innentäter beim Betriebspersonal ein. Personen aus diesem Kreis haben aufgrund Ihrer Position erhöhte Rechte und bessere Möglichkeiten grundsätzlich auf Daten zuzugreifen. Unabhängig von diesbezüglich getroffenen organisatorischen Maßnahmen sind zusätzliche technische Maßnahmen notwendig, um auch Angriffe von solchen Innentätern abzuwehren.

Ziel der VAU ist aber auch, trotz des umzusetzenden Betreiberausschlusses bei den Maßnahmen eine gute Balance zwischen Sicherheit und Betreibbarkeit zu finden. Insbesondere soll vermieden werden, dass das Einspielen von Updates jedes Mal mit aufwändigen Prozessen und der Beteiligung verschiedener Rollen verbunden ist. Im Gegensatz dazu ist ein aufwändiger Prozess unter Beteiligung mehrerer Rollen bei einer einmaligen oder zumindest sehr seltenen Zeremonie zur Inbetriebnahme vertretbar.

Entsprechend wird im Folgenden (vorrangig über Hinweise zu den Anforderungen) eine Umsetzung beschrieben, die sowohl die hier gestellten Anforderungen an die VAU erfüllt, als aber auch einen geringen Aufwand beim Einspielen von Updates im Betrieb erzeugt. Durch eine technisch durchgesetzte und geschützte Protokollierung sind dennoch jederzeit unberechtigte Veränderungen durch Dritte (gematik) eindeutig nachvollziehbar. In solchen Fällen werden dann entsprechende Maßnahmen zur Klärung und Behebung unternommen. Somit kann der Anbieter bzw. ein etwaige Innentäter auch ohne eine direktes Mehr-Augen-Prinzip nicht unbemerkt handeln.

Als Sicherheitsanker muss immer ein HSM zum Einsatz kommen, wobei durch die vorgeschlagene Umsetzung Firmwareanpassungen in Form eines HSM-Moduls notwendig werden. Auch diese Aufwände wirken sich nicht negativ auf den Betrieb aus, sondern fallen nur vor der Inbetriebnahme an.

Der kurz zusammengefasste Umsetzungsansatz
Der Anbieter kann eigenständig VAU-Images (PoPP und ZETA Guard) im HSM als Hashwert bekannt machen und das Image in die VAU einspielen. Das HSM prüft bei der Bekanntmachung, dass der Hashwert vom Hersteller signiert ist. Nach Übernahme eines Hashwerts protokolliert das HSM diesen und signiert das Protokoll, mit Schlüsseln, auf die nur das HSM zugreifen kann. Das Protokoll kann exportiert werden. Der Prüfschlüssel für die Protokollsignatur liegt der gematik vor. Da die gematik jedes VAU-Update vom Hersteller gemeldet bekommt und in diesem Zuge auch den Hashwert des fertigen VAU-Images erhält, kann jederzeit über das Protokoll aus dem HSM nachvollzogen werden, dass vom Anbieter nur die VAU-Images bekannt gemacht wurden, die auch vom Hersteller gemeldet worden sind. Ein aus einem VAU-Image gestarteter Verarbeitungskontext muss über Mittel der VAU attestiert werden und nur mit gültigen Attestierungsinformationen kann der Verarbeitungskontext auf Schlüssel im HSM zugreifen bzw. diese dort erzeugen lassen und exportieren. Das HSM erkennt zulässige Verarbeitungskontexte am Hashwert des VAU-Images, aus dem der Verarbeitungskontext gestartet wurde, da dieser Teil der Attestierungsinformationen ist und gegen die im HSM hinterlegten Hashwerte abgeglichen werden kann. Die Attestierungsinformationen sind von sicher in der VAU gespeicherten Schlüsseln signiert, sodass das HSM die Validität der präsentierten Informationen prüfen kann (wenn es zuvor die öffentlichen Prüfschlüssel für die sicher in der VAU gespeicherten Signatur-Schlüssel erhalten hat).

Ebenso wie VAU-Images bzw. deren Hashwert können dann auch erzeugte Schlüssel (bzw. deren öffentlicher Teil) protokolliert werden. Somit ist auch eine Verifikation möglich, dass für die verschiedenen Identitäten des PoPP-Service (bspw. für TLS) auch tatsächlich nur Schlüssel verwendet werden, die ausschließlich durch einen Verarbeitungskontext der VAU genutzt werden können.

Für das Vorgehen ist eine initial sichere Zeremonie notwendig, bei der u. a. alle notwendigen Prüfschlüssel in das HSM importiert werden und der Protokollprüfschlüssel exportiert wird. Zudem wird der Anbieter von allen Zugriffen auf das HSM ausgeschlossen, die nicht absolut notwendig sind (bspw. der Import signierter VAU-Image-Hashwerte ist für den Anbieter möglich).

In den Hinweisen zu einem Teil der Anforderungen wird im Folgenden dieses Vorgehen detailliert.

5.2.1.4 Lifecycle eines Verarbeitungskontextes

Hinweis: Eine technische Umsetzung von [A_26593*] ist die Ermittlung des Hashwerts des zu startenden VAU-Images durch die VAU und die Signatur dieses Hashwerts mit einem sicher gespeicherten (bspw. in einem TPM) Signaturschlüssel des Herstellers der HW-Plattform (Chip-Hersteller) oder des Herstellers des PoPP-Service. Diese Attestierungsinformation kann dann an prüfende Systeme, wie bspw. das HSM übermittelt werden, wobei das verwendete Protokoll vor Replay-Attacken schützen muss (das HSM muss erkennen können, dass die Attestierungsinformationen frisch für das HSM erzeugt wurden). Dem HSM müssen entsprechend über einen sicheren Prozess zum einen die Prüfschlüssel des Chip-Herstellers bzw. PoPP-Service-Herstellers und zum anderen die zulässigen Hashwerte von VAU-Images bekannt gemacht werden. Um einen späteren Rollback zu verhindern wird immer genau nur gegen den letzten hinzugefügten also den aktuellen Hashwert eines jeweiligen VAU-Images geprüft bzw. ist nur kurzzeitig nach dem Einspielen die Möglichkeit eines Rollback auf das letzte davor verwendete Image möglich (siehe A_27373*).

Hinweis: Nach Einspielen eines neuen Hashwerts ins HSM akzeptiert dieses somit für zwei Tage auch Verarbeitungskontexte, die in ihren Attestierungsinformationen den zweit jüngsten im HSM vorliegenden Hashwert vorweisen. Dies dient der Möglichkeit eines schnellen Rollback, falls nach Einspielen und Inbetriebnahme einer neuen Version massive Fehler im Betrieb auftreten.

Hinweis: Es wird davon ausgegangen, dass die VAU es leistet, dass mehrere Verarbeitungskontexte parallel ausführbar sind.

Hinweis: Bei den in [A_26596*] genannten Dritten handelt es sich beispielsweise um die gematik, Systeme beim Anbieter PoPP-Service (bspw. andere Verarbeitungskontexte) oder auf den PoPP-Service zugreifende Clients.

Hinweis: Es ist zulässig, dass physische Schutzmaßnahmen in der Hardware der VAU umgesetzt werden (bspw. in etwa im Ansatz vergleichbar mit denen eines HSMs) und/oder in zusätzlicher vom Anbieter bereitgestellter Hardware (bspw. durch einen mit zusätzlichem Zutrittsschutz ausgestatteten Serverchrank). In jedem Fall besteht eine Kopplung dieser physischen Schutzmaßnahmen zur VAU-Software, damit bei durch diese Schutzmaßnahmen erkannten Zugriffen eine Reaktion der VAU stattfindet, so dass Verarbeitungskontexte geschlossen und somit alle flüchtigen Daten aus dem System entfernt werden.

5.2.1.5 Anforderungen an das HSM

Hinweis: Eine valide technische Umsetzung ist ein HSM-Modul, welches:

1. Prüfschlüssel importieren und an bestimmte Zwecke/Anwendungsfälle binden kann,
2. Schlüsselpaare erzeugen und diese an bestimmte Zwecke/Anwendungsfälle bzw. an bestimmte authentisierte Nutzer (ZETA Guard- und PoPP-Verarbeitungskontexte) des HSM binden kann,
3. autorisierte VAU-Images in Form von signierten Hashwerten dieser Images importieren kann und dabei die Signatur gegen zuvor importierte Prüfschlüssel prüft, bevor Hashwerte übernommen werden,
4. eine beidseitig authentisierte, verschlüsselte und integritätsgeschützte Verbindung zu Verarbeitungskontexten aufbauen kann,
5. Attestierungsprotokolle mit Schutz vor Replay-Attacken unterstützt und somit:
1. frische Attestierungsinformationen von Verarbeitungskontexten entgegennehmen kann, deren Signatur gegen zuvor importierte Prüfschlüssel prüft,
2. die Attestierungsinformation (Hashwert) gegen die aktuell als autorisiert hinterlegten Hashwerte von VAU-Images validiert,
3. ggf. die Art von VAU-Image detektiert (falls PoPP-VAU- oder ZETA Guard-Image getrennt sind)
   und nur im Erfolgsfall
1. private Schlüssel zur Nutzung für genau den attestierten Verarbeitungskontext freigibt, wobei nur die für diese Art von Verarbeitungskontext zulässigen Schlüssel freigegeben (Unterscheidung PoPP-Logik und ZETA-Logik sofern verschiedene Kontexte) werden und
2. Schlüsselpaare für den attestierten Verarbeitungskontext erzeugt und an diesen übergibt
6. die Anmeldung von Benutzern am HSM/HSM-Modul zur Erzeugung von Schlüsseln (abgesehen von etwaigen spezifizierten Ausnahmen) und zum Import von Prüfschlüsseln nur über sichere Authentisierungsmittel, die zwischen mehreren Rollen aufgeteilt werden können, ermöglicht. 

5.2.1.6 Schlüsselnutzung direkt im Verarbeitungskontext

Der PoPP-Service verfügt über ein oder mehrere HSMs, welche sowohl die sichere Nutzung und Speicherung von Schlüsseln gewährleisten als auch eine performante Nutzung der Schlüssel ermöglichen. Nichtsdestotrotz ist die Nutzung von Schlüsseln im HSM weniger performant, als für Schlüssel die direkt im Verarbeitungskontext der VAU verfügbar sind. Dies liegt u.a. auch am Overhead für die sichere Kommunikation mit dem HSM, die bei jeder Nutzung eines Schlüssels im HSM anfällt.

Um Performanceprobleme beim PoPP-Service zu vermeiden soll daher die Anzahl der HSM-Zugriffe, die für die jeweiligen Anwendungsfälle notwendig sind gering gehalten werden. Da die VAU und deren Verarbeitungskontexte gerade für die Verarbeitung vertraulicher Daten konzipiert und implementiert wird, ist es sicherheitstechnisch grundsätzlich denkbar Schlüssel direkt im Verabeitungskontext zu nutzen, statt sie im HSM zu speichern. Dabei muss der Zweck des Schlüssels und auch die Laufzeit betrachtet werden, da die Speicherung außerhalb des HSM ein leicht erhöhtes Restrisiko der Offenbarung des Schlüssel hervorruft und dessen Eintrittswahrscheinlichkeit mit der Zeit, in der der Schlüssel genutzt wird, steigt.

Entsprechend dieser Betrachtungen wird der private Schlüssel für die Signatur von PoPP-Token im HSM gespeichert und Schlüssel für TLS-Identitäten dürfen zwar außerhalb des HSM direkt vom Verarbeitungskontext der VAU verarbeitet, jedoch nicht länger drei Monate genutzt werden.

Hinweis: Für die TLS-Client-Identität (Richtung sektoralem IDP) ist ggf. kein CSR notwendig, da nicht zwingend ein Zertifikat erforderlich ist. Die Nachvollziehbarkeit, dass die genannten Schlüssel im HSM erzeugt wurden, ist entsprechend der Hinweise zur Umsetzung für die gematik über das signierte und exportierbare Protokoll des HSM möglich. Dafür wird im Rahmen der initialen Zeremonie ein Protokoll-Signatur-Schlüsselpaar erzeugt und von der gematik der öffentliche Signaturprüfschlüssel exportiert. In diesem Protokoll werden - neben den Hashwerten der importierten VAU-Images - die öffentlichen Schlüssel der in [A_26687*] genannten Schlüsselpaare unter Angabe des Zwecks bzw. der zugehörigen Identität protokolliert.
Neu erzeugte Schlüsselpaare sind nicht automatisch aktiv, da für einige Identitäten zunächst Zertifikate durch den Anbieter bezogen werden müssen und / oder öffentliche Schlüssel in JWKSs / Entity Statements veröffentlicht werden müssen, bevor die Identität einsatzbereit ist und aktiviert werden kann.

Hinweis: Es ist aktuell nicht vorgesehen einmal deaktivierte Schlüssel reaktivieren zu können (Status "inaktiv" > "aktiv").

5.2.1.7 Speicherung von Daten

5.2.1.8 Transport von Daten und Authentisierung/Authentifizierung bei Kommunikation

Hinweis: Für PoPP wird der VAU-Kanal somit durch TLS realisiert. Der von VAU-Clients etablierte TLS-Kanal endet im PEP des ZETA Guard, der in einem Verarbeitungskontext läuft. Der TLS-Kanal zum sektoralen IDP wird aus einem Verarbeitungskontext des PoPP-Service aufgebaut.

Hinweis: Vorgaben zum TLS-Zertifikat werden in [A_26497*] definiert.

Hinweis: Weitere Vorgaben zur TLS-Client-Authentisierung von Relying Parties ggü. dem sektoralen IDP werden in [gemSpec_IDP_FD#A_23183*, A_23185*,A_23196*] getroffen.

Hinweis: Eine technische Umsetzung des Aspekts "Verarbeitungskontext ist Instanz eines bekannten VAU-Images" ist die Bekanntmachung des vom Dienst-Hersteller signierten Hashwerts eines VAU-Images ggü. dem HSM. Das HSM kann die Signatur gegen Prüfschlüssel verifizieren, die über sichere Prozesse ins HSM eingebracht wurden. Im Zuge des Zugriffs eines Verarbeitungskontext auf das HSM lässt dieses den Verarbeitungskontext von der VAU attestieren und kann die wiederum signierten Attestierungsinformationen (Quote) gegen den ebenfalls vorab eingebrachten Prüfschlüssel verifizieren. Die Attestierung muss Übergabe und Prüfung einer Challenge umfassen, um Replay-Attacken auszuschließen.

5.2.1.9 Protokollierung und Monitoring

Hinweis: Eine technische Umsetzung ist die Signatur des Protokolls mit einem Protokoll-Signatur-Schlüssel, der über sichere Prozesse im Rahmen der Inbetriebnahme im HSM erzeugt wurde, ausschließlich vom HSM selbst genutzt werden kann und dessen öffentlicher Schlüssel der gematik bekannt ist.

5.2.1.10 Konfigurierbarkeit

Hinweis: VAU-Images werden entsprechend der Hinweise zur Umsetzung nur nach erfolgreicher Prüfung der Signatur übernommen und werden nur ausgeführt bzw. können nur auf die relevanten Schlüssel zugreifen, wenn diese vom HSM über entsprechende Attestierungsinformationen der VAU als autorisierte Images verifiziert werden. Die dafür notwendigen Hashwerte von Images kann der Anbieter ebenfalls eigenständig ins HSM importieren und auch diese werden nur übernommen, wenn sie vom Hersteller signiert wurden.

5.2.1.11 Anforderungen an den Hersteller

Hinweis: Vergleich Absatz [Kapitel ] und dort [A_26959*].

Hinweis: Vergleich Absatz [Kapitel ].

Bei der Verwendung von Attestierungsmechanismen der Chip-Plattform wird entsprechend Schlüsselmaterial verwendet, was von den Herstellern der Chips (also bspw. Intel oder AMD) sicher erzeugt und sicher in die Plattform eingebracht wird. Der Hersteller des PoPP-Service hat darauf keinen Einfluss, muss aber dann entsprechend diese Mechanismen sicher verwenden.

Verwendet der Hersteller des PoPP-Service andere Mechanismen muss er selber Schlüsselmaterial, was im Zuge der Attestierung verwendet wird (Attestierungs-Schlüssel), erzeugen und speichern. Die in den folgenden Anforderungen gemachten Vorgaben bzgl. Attestierungs-Schlüsseln beziehen sich auf dieses Szenario.

Hinweis: Die Bereitstellung von Attestierungs-Prüfschlüsseln an die gematik erfolgt für den Fall, dass der Hersteller diese selbst verwaltet, beim Hersteller vor Ort im Rahmen der gemeinsamen Einbringung der Attestierungs-Schlüssel in die VAU (vgl. A_26618*).

Hinweis: Eine technische Umsetzung ist die Erzeugung des Hashwerts des VAU-Images und die Signatur mit dem privaten Autorisierungsschlüssel.

Hinweis: Eine technische Umsetzung der Bereitstellung an die gematik ist die Übermittlung des signierten Hashwerts an die gematik. 

5.2.1.12 Anforderungen an den Anbieter

Hinweis: Eine Zeremonie, die die folgenden Punkte berücksichtigt, setzt die Anforderung um:

1. Das HSM befindet sich im Auslieferungszustand.
2. Auf dem HSM wird das HSM-Modul des Herstellers des PoPP-Service installiert.
3. Der Zugang zum HSM wird so konfiguriert, dass der Anbieter:
   
1. neue signierte Hashwerte von VAU-Images ins HSM importieren kann,
2. Schlüssel für TLS-Server- und TLS-Client-Identität erzeugen und dazugehörige CSRs exportieren kann,
3. Schlüssel für die ID Token-Verschlüsselung (durch den sektoralen IDP) erzeugen kann,
4. Schlüssel für die Access Token-Signatur (durch PoPP AuthZ) erzeugen kann,
5. Schlüssel für die Access Token-Ver-/Entschlüsselung (durch AuthZ bzw. Resource Server) erzeugen kann,
6. darüber hinaus keine anderen Schlüssel erzeugen, exportieren oder nutzen sowie keine Prüfschlüssel importieren kann, sondern dies nur im Vier-Augen-Prinzip mit der gematik möglich ist.
   (Der Export öffentlicher Schlüssel kann und muss immer möglich sein.)
4. Auf dem HSM werden Schlüssel für die folgenden Identitäten bzw. Zwecke erzeugt:
1. Identität PoPP-Token-Signatur,
2. CA-Schlüsselpaar zur Ableitung von Identitäts-Schlüsselpaaren ("CA-Ident."),
3. Identität HSM für Verarbeitungskontext-zu-HSM-Kommunikation (aus CA-Ident.),
4. Identität PoPP-Verarbeitungskontext (aus CA-Ident.),
5. Identität ZETA Guard-Verarbeitungskontext (aus CA-Ident.),
6. Protokoll-Signatur-Schlüssel (Signatur des Protokolls der VAU-Image-Hashwerte und öffentlichen Schlüssel von im HSM erzeugten Identitäten).
5. Aus dem HSM werden die öffentlichen Schlüssel für PoPP-Token-Signatur, CA-Ident. und Protokoll-Signatur exportiert.
6. Der öffentliche Schlüssel für die PoPP-Token-Signatur-Identität geht:
1. an den Anbieter zur Bekanntmachung via Entity Statement und zur Beantragung der TI-Identität (der Export eines mit dem privaten Schlüssel signierten CSR muss möglich sein) und
2. an die gematik, um diesen später gegen den im Entity Statement und im TI-Zertifikat enthaltenen Schlüssel abgleichen zu können.
7. Der öffentliche Schlüssel der CA-Ident. geht an den Hersteller, der diese über die VAU-Image-Build-Pipeline [A_26468*] in die VAU-Images einbindet.
8. Der öffentliche Protokoll-Signatur-Schlüssel geht an die gematik zur späteren Prüfung der vom Anbieter übertragenen Protokolle. 
9. In das HSM werden die folgenden Prüfschlüssel - gebunden an den jeweiligen Zweck - importiert, nachdem sie vorab zwischen Hersteller, Anbieter und gematik nochmals abgeglichen wurden:
1. Prüfschlüssel zur Signatur der Attestierungsinformationen (vom Hersteller; geht bei Eigenverwaltung dieser Schlüssel durch den Hersteller in einer vorgelagerten Zeremonie - zur Einbringung der Attestierungs-Schlüssel in die VAU - an die gematik),
2. Prüfschlüssel zur Signatur von VAU-Image-Hashwerten (vom Hersteller).

Hinweis: Da von den in das HSM importierten Vertrauensanker ggf. nicht alle unter der Kontrolle des Herstellers des PoPP-Service stehen, ist ein Wechsel oder Hinzufügen eines Vertrauensankers bereits deutlich vor Ablauf von zwei Jahren nicht auszuschließen.

Hinweis: Der Schutz der Schlüssel wird entsprechend der Anforderungslage technisch vom Produkt durchgesetzt. Schlüssel werden entweder innerhalb der initialen Zeremonie gemeinsam mit Hersteller und gematik erzeugt oder deren Erzeugung wird vom Anbieter über entsprechende Schnittstellen der VAU ausgelöst. Ausnahmen bilden die Signaturschlüssel für Attestierungsinformationen die in der Hardware der VAU (bspw. TPM) sicher gespeichert sind. Der Anbieter erzeugt nicht selber Schlüssel. Explizit davon ausgenommen und hier in den Anforderungen nicht erwähnt sind die Schlüssel zum Signieren des Entity Statements des PoPP-Service. Diese können unter der Hoheit des Anbieters stehen. Die gematik ist über die Zeremonie zur HSM-Einrichtung und über das vom HSM signierte Protokoll jederzeit in der Lage, die Authentizität der in Entity Statements und Zertifikaten veröffentlichten Schlüssel zu verifizieren.

Hinweis: Entsprechend [A_27039*] wird die maximale Laufzeit der im ersten Punkt genannten Schlüssel technisch von der VAU durchgesetzt. Entsprechend den Vorgaben der TI-PKI ist die Laufzeit fünf Jahre für die im zweiten Punkt genannten Zertifikate, wobei die Schlüssel abweichend davon nur zwei Jahre genutzt werden sollen. Für die Erneuerung der PoPP-Token-Signatur-Identität ist ein Mehraugenprinzip mit der gematik notwendig. Vergleiche dazu auch [A_26968*] weiter oben.

Hinweis: Die Einrichtung des HSM findet innerhalb der initialen Zeremonie mit der gematik statt. Durch die beschriebene Umsetzung, bei der neue VAU-Images über den Import von signierten Hashwerten der Images im HSM bekannt gemacht werden, ergibt sich keine Abhängigkeit des Anbieters zur gematik im Regelbetrieb, da dieser Import durch den Anbieter eigenständig vorgenommen werden kann.

Hinweis: Die Anforderung besteht für den Anbieter zusätzlich zum in [A_26598*] geforderten Schutz.

Hinweis: Die Anforderung besteht für den Anbieter zusätzlich zum in [A_26598*] und [A_26597*] geforderten Schutz.

5.2.1.13 Bereitstellung durch die gematik

Die gematik stellt den ZETA Guard als Docker-Container-Image und eine dazugehörige Signatur bereit.

Die gematik stellt den Prüfschlüssel für die Prüfung der Signatur des ZETA Guard bereit.

5.3 Identitäten und Zertifikate PoPP-Service

5.3.1 Überblick

Die folgende Tabelle gibt einen Überblick über die verwendeten Schlüssel, wo sie erzeugt werden und wo der private bzw. geheime Schlüssel gespeichert und verwendet wird. Öffentliche Schlüssel die als Prüfschlüssel/Vertrauensanker dienen, sind nicht mit aufgeführt. (VK = Verarbeitungskontext) 

Tabelle 6: Übersicht über die im PoPP-Service verwendeten Schlüssel

*sofern getrennte VAU-Images und somit VK verwendet werden

5.3.2 Algorithmus für Schlüsselpaare

5.3.3 Entity Statement

5.3.4 Token-Signaturen

Hinweis: Für den Token-Signatur-Schlüssel wird zusätzlich zur Veröffentlichung via Entity Statement/JWKS (siehe [A_ 26434*] und [A_26533*]) ein Zertifikat mit entsprechender Rolle aus der Komponenten-PKI der TI ausgestellt und in die PoPP-Token eingebettet. Somit können FD entscheiden, ob sie die Token über den vom Federation Master oder den von der TI-PKI aufgespannten Vertrauensraum prüfen. Der Hersteller benötigt das Zertifikat um das Einbetten dieses Zertifikats in die PoPP-Token umsetzen zu können.

Hinweis: Der Hersteller benötigt die Information zum Signaturzertifikat um die Erzeugung des Requests für die im Folgenden geforderte OCSP-Abfrage umsetzen zu können.

Hinweis: Die Grace-Period für OCSP-Antworten im Konnektor ab PTV6 beträgt 24h. Der OCSP-Responder ist im Internet erreichbar. Die Adresse des OCSP-Responders ist dem Authority Information Access (AIA) des Zertifikats zu entnehmen.

5.3.5 TLS

Hinweis: Anforderungen zu Schlüsseln/Zertifikaten bei der TLS-Client-Authentisierung bei der Verbindung zum sektoralen IDP finden sich in gemSpec_IDP_FD, wobei der PoPP-Service die dort genannte Rolle Authorization Server/Anbieter von FD einnimmt.

Hinweis: Die OCSP-ADresse ist im "Authority Information Access" (AIA) des Zertifikats zu finden.

5.3.6 CV-Zertifikat

Für die Verifikation der Versichertenidentität via kontaktbehaftet angebundener eGK benötigt der PoPP-Service ein CV-Zertifikat aus der TI-CVC-PKI.

Hinweis: Die erste CHR ist in A_26499 mit '0000 80 987 00000 0000000001' spezifiziert. Diese CHR enthält mit KeyID='0000' einen Wert, der in keiner Smartcard verwendet wird. Der Anfang des ICCSN-Teils der CHR wiest mit dem Wert '80' auf das Gesundheitswesen hin. Die folgenden drei Stellen '987' stehen als CountryCode zur applikationsspezifischen Verfügung und werden im Regelungsbereich der gematik für TI-interne Zwecke verwendet. Die folgenden fünf Zeichen '00000' stehen in einer ICCSN für den Herausgeber und codieren in der TI den PoPP-Service.

5.3.7 TSL-Handling

Für die Prüfung von eGK-CV- und X.509-Zertifikaten benötigt der PoPP-Service eine aktuelle TSL.

Hinweis: Der OCSP-Responder des TSL-Dienstes ist im Internet erreichbar. Die Adresse des OCSP-Responders ist dem Authority Information Access (AIA) des Signaturzertifikats zu entnehmen.

Hinweis: Das SOLL in [A_27202] ermöglicht auf einen solchen Proxy zu verzichten, wenn stets nur ein oder sehr wenige Verarbeitungskontexte des PoPP-Service laufen. Der Verzicht auf die Umsetzung ist mit der gematik abzustimmen.

5.4 ZETA Guard im PoPP-Service

Der ZETA Guard im PoPP-Service übernimmt wesentliche Sicherheitsleistungen für den Zugang zum PoPP-Service und erfüllt folgende Aufgaben. Das Gegenstück zum ZETA Guard des PoPP-Service ist der ZETA Client, der - wie der PoPP-Client - Teil des PS ist.

Die Policy-basierte Zugriffskontrolle stellt sicher, dass alle Zugriffe auf den PoPP-Service sicher und autorisiert sind, indem er kontinuierlich die Aktivitäten überwacht und analysiert. Solange der ZETA Guard noch keine Versicherten Clients unterstützt (Stufe 2) werden lediglich die PoPP Schnittstellen I_PoPP_Token_Generation durch den ZETA Guard abgesichert. Über diese findet die fachliche Kommunikation zwischen PoPP-Service und PS statt. 

Die LEI-Authentifizierung mittels SM-B erfolgt automatisch bei freigeschalteter SM(C)-B, indem das PS ein Client Assertion JWT erstellt und mit der SM(C)-B signiert. Dieses JWT nutzt DPoP, um sicherzustellen, dass die Anfragen vom autorisierten PS stammen und Replay-Attacken verhindert werden.

Das Session Management für den PoPP-Service im ZETA Guard verwendet OAuth2, wobei Access- und Refresh-Token sicher verwaltet und bei Bedarf erneuert werden. Die Token sind durch DPoP an spezifische Client-Instanzen (sprich PS Instanzen) gebunden, um sicherzustellen, dass nur autorisierte Clients Zugriff haben. Bei abgelaufenen Sessions ist eine erneute Authentifizierung erforderlich.

Der PoPP-Service Anbieter verwendet den von der gematik bereitgestellten ZETA Guard, der gemäß [gemSpec_ZETA] implementiert ist. Die Beschreibung des ZETA Guard sowie Anforderungen an PoPP-Service und PoPP-Service Anbieter rund um die Einbindung und Verwendung des ZETA Guard finden sich in [gemSpec_ZETA].
In diesem Dokument sind PoPP-Service spezifische Anforderungen und Hinweise rund um das ZETA Guard enthalten (dieses Kapitel und [Kapitel ]).

Alle konkreten Informationen und Regelungen zu Bereitstellung, Konfiguration und Verwendung des ZETA Guard sind dem Betriebshandbuch des ZETA Guard-Herstellers zu entnehmen.

5.4.1 Bereitstellung, Konfiguration und Verwendung vom ZETA Guard

Zusätzlich zu den Anforderungen aus [gemSpec_ZETA] insbesondere [A_25773*] und [A_25776*], gelten für den PoPP-Service Anbieter die folgenden Anforderungen.

Hinweis: Die Gültigkeitsdauern für Access Token und Refresh Token werden über die PoPP-Service Policy gesteuert. 

Hinweis: Der Zugriff auf den PIP/ PAP-Server erfolgt über die in [A_25670*] festgelegte URL; für den PoPP-Service unter dem application Endpunkt popp.
Die URL inklusive Endpunkt für den PoPP-Service für das Zero Trust git-repository der gematik wird organisatorisch übermittelt

5.5 Vertrauenswürdige Uhrzeit im PoPP-Service

Mit der Einführung der Telematikinfrastruktur TI1.0 wurde ein zentraler Zeitdienst eingeführt, mit dem sich alle zentralen Komponenten sowie Konnektoren regelmäßig synchronisieren müssen. Im Rahmen des Sicherheitskonzepts der TI1.0 - als geschlossenes System bekannter Nutzer - wird diese Uhrzeit als vertrauenswürdig angenommen. 

Der PoPP-Service stellt für verschiedene (aktuelle und zukünftige) Anwendungsfälle ein Zeugnis über einen real existierenden Versorgungskontext zentral aus. Da der Dienst über das Internet angesprochen wird und Clientsysteme und ein PoPP-Token-nachnutzendes System (PoPP-Verifier) sich mit unterschiedlichen Zeit-Servern synchronisieren könnten als der PoPP-Service, muss die Uhrzeit des PoPP-Service vertrauenswürdig sein.

Hinweis 1: Das PoPP-Token muss in der Signatur nicht über einen qualifizierten Zeitstempel verfügen, weil das PoPP-Token auch im ersten Anwendungsfall des VSDM 2.0 keine Rolle in den abrechnungsbegründeten Informationen spielt. Durch den sicheren Betrieb des PoPP-Service und die Prüfung dieser Afo im Zulassungsverfahren des PoPP-Service kann die Uhrzeit eines ausgestellten PoPP-Token als zuverlässig betrachtet werden.

Hinweis 2: Die Bundesnetzagentur listet unter [AnbieterVZeitD] verschiedene Anbieter für qualifizierte Zeitstempel.

5.6 Federation Entity Statement

Der PoPP-Service  stellt Kommunikationspartnern notwendige Informationen bereit, indem er ein Entity Statement gemäß [OpenID Federation 1.0] unter <Identifier-URL>/.well-known/openid-federation verfügbar macht.

Das Entity Statement beauskunftet allgemeine Informationen wie:

1. Identifier (iss),
2. Schlüssel, mit denen das Entity Statement signiert wird (jwks),
3. Ausstellungszeitpunkt (iat),

und Metadaten Informationen zur Konfiguration als:

1. OAuth Authorization Server (oauth_authorization_server),
2. Relying Party (openid_relying_party),
3. OAuth Protected Resource (oauth_resource),
4. Teilnehmer der TI-Föderation (federation_entity).

Die Metadaten enthalten u. a. die Endpunkte, unter denen der PoPP-Service Authorization Server erreichbar ist und Informationen zu Signatur- und Verschlüsselungsschlüssel. Die Tabelle "Entity Statement des PoPP-Service" im Anhang stellt das Entity Statement des PoPP-Service Authorization Server exemplarisch dar.

Hinweis: Anforderungen an die Erstellung und Pflege des Entity Statements als Relying Party der TI-Föderation finden sich in [gemSpec_IDP_FD#Kapitel Entity Statements]. Die Tabelle "Entity Statement des PoPP-Service" im Anhang stellt das Entity Statement des PoPP-Service Authorization Server exemplarisch dar.

6 Funktionsmerkmale

6.1 PoPP-Service - Authorization Server

Der PoPP-Service Authorization Server schützt den PoPP-Service Resource Server vor unberechtigten Zugriffen von unbekannten Clients aus dem Internet. Auf Basis des OAuth Framework [RFC6749] stellt er Access Tokens für in der Föderation registrierte Clients aus.

Schnittstellen des PoPP-Service, die eine Nutzeridentifikation benötigen, werden vom PoPP-Service Authorization Server mit Access Token versorgt. Der PoPP-Service Authorization Server in seiner Rolle als Relying Party der Identitätsföderation delegiert dabei die Nutzerauthentifizierung an einen geeigneten sektoralen IDP. In Nutzungsszenarien mit eGK (ohne Verwendung der GesundheitsID) werden diese Identitätsinformationen vom PoPP-Service auf sichere Art und Weise aus der eGK ausgelesen.

6.1.1 Standard Authorization Server mit Versicherten Authentisierung

Da der von der gematik bereitgestellte ZETA Guard in der ersten Stufe noch keine Authentisierung von Versicherten unterstützt, wird diese Funktion übergangsweise von einem separaten PoPP-Service Authorization Server übernommen. Dieser muss vom Hersteller des PoPP-Service umgesetzt und in den PoPP-Service integriert werden.

Die Anforderungen an einen PoPP-Service Authorization Server für die Nutzung sektoraler Identity Provider (IDP), sind in [gemSpec_IDP_FD] beschrieben. Das vorliegende Dokument enthält lediglich einen kurzen Überblick und abweichende oder zusätzliche Anforderungen an einen PoPP-Service Authorization Server.

Der PoPP-Service Authorization Server erfüllt im Kontext der Nutzerauthentisierung mit GesundheitsID die Funktionen:

1. eines OAuth Server für Client-Registrierung einer Anwendung, welche ein PoPP-Modul integriert und
2. eines OAuth Server für Autorisierungsanfragen eines registrierten Clients und
3. einer Relying Party in der TI-Föderation.

Die Abbildung "Komponentendiagramm PoPP-Service Authorization Server bei Authentifizierung mit GesundheitsID" veranschaulicht die Komponenten des PoPP-Service in diesem Kontext. Das in eine App integrierte PoPP-Modul ist der OAuth Client, mit welchem der Versicherte interagiert. Der PoPP-Service Authorization Server in seiner Funktion als OAuth Server stellt dem OAuth Client nach erfolgreicher Nutzerauthentisierung mit GesundheitsID ein "eHealth-ID-check" Access Token aus. Mit diesem "eHealth-ID-check" Access Token kann der OAuth Client dann auf die OAuth Protected Resource - den PoPP-Service - zugreifen.

Abbildung 12: Komponentendiagramm PoPP-Service Authorization Server bei Authentifizierung mit GesundheitsID

Zur Nutzer-Authentisierung verwendet der Versicherte die Authenticator-Funktionalität der GesundheitsID in der Kassen-App oder, wenn dort nicht integriert, eine separate Authenticator-App. Das Authenticator-Modul ist die Frontend-Komponente des sektoralen IDP der Krankenkasse, also eines in der TI-Föderation registrierten OpenID-Providers.

Der PoPP-Service Authorization Server ist zur Durchführung der Authentifizierung der Versicherten als Relying Party in der TI-Föderation registriert. Weitere Informationen zur TI-Föderation sind unter [IDP-Wissensdatenbank] zu finden.

Zur Bestätigung valider Client-Instanzen durchläuft jede Anwendung mit integriertem PoPP-Modul, die den PoPP-Service nutzen möchte, eine organisatorische Client-Registrierung im Registrierungsprozess der gematik für den PoPP-Service Authorization Server - ähnlich, wie es heute bereits beim E-Rezept Fachdienst Authorization Server praktiziert wird. Dabei wird der Anwendung im Registrierungsprozess eine Client-ID zugewiesen und ein API-Key - beide Parameter sind in Autorisierungsanfragen der Client-Instanzen mitzusenden. Anfragen nicht-registrierter Anwendungen werden vom PoPP-Service Authorization Server abgewiesen. 

6.1.2 Authorization Server Zusatzfunktion Authentifizierung eGK mobil

Neben den Funktionen zur Authentifizierung des Versicherten mit seiner GesundheitsID (OAuth Server, Relying Party) bietet der PoPP-Service Authorization Server eine weitere Funktionalität an: die Authentifizierung der an das Mobilgerät des Versicherten angebundenen eGK (eGK mobil). Dies ist für den PoPP-Service - neben GesundheitsID und Nutzung der eGK in einer LEI - ein alternativer Weg die Informationen zur Versichertenidentität zu erhalten.

Abbildung 13: Komponentendiagramm PoPP-Service Authorization Server bei Authentifizierung einer eGK mobil

Eine App (etwa Videosprechstunde, Apotheken) implementiert für die Authentifizierung der eGK des Nutzers ein PoPP-Modul und einen eGK-Reader (beispielsweise auf Basis der NFC-Funktionalität des Mobilgeräts des Versicherten). Das PoPP-Modul ist auch hier der OAuth Client zum PoPP-Service Authorization Server. Ist das PoPP-Modul ein OAuth Client, der dem PoPP-OAuth Server bekannt ist (registrierter OAuth Client), so stellt dieser dem OAuth Client "card-check" Access Token aus. Mit diesem "card-check" Access Token kann der OAuth Client dann auf die OAuth Protected Resource - den PoPP-Service Resource Server - zugreifen. Der PoPP-Service Resource Server tauscht mit der eGK dann direkt Daten aus, über die der PoPP-Service die eGK authentfiziert.

6.1.3 Anforderungen an den PoPP-Service Authorization Server in der Funktion OAuth Server

6.1.3.1.1 Service Discovery

Der PoPP-Service Authorization Server stellt Kommunikationspartnern notwendige Informationen im Metadatenblock openid_relying_party im Entity Statement des PoPP-Service gemäß [OpenID Federation 1.0] bereit.

Die Metadaten enthalten u. a. die Endpunkte, unter denen der PoPP-Service Authorization Server erreichbar ist und Informationen zu Signatur- und Verschlüsselungsschlüssel. Die Tabelle "Entity Statement des PoPP-Service" im Anhang stellt den Metadatenblock im Entity Statement des PoPP-Service exemplarisch dar.

6.1.3.1.2 Client Registrierung

6.1.3.2 Ausstellung eines "eHealth-ID-check" Access Token

Hinweis: Anforderungen an die Signaturschlüssel sind in [gemSpec_IDP_FD#Kapitel Entity Statements] beschrieben.

6.1.3.3 Ausstellung eines "card-check" Access Token

6.1.4 Mobile Verfahren zur Bestätigung der Versicherten-Identität

Für die Erstellung des PoPP-Token ist es möglich, dass der Versicherte seine Identität bestätigt, indem er sich mit seiner GesundheitsID gegen den sektoralen IDP seiner Krankenversicherung authentifiziert. Der Ablauf der eigentlichen Authentisierung aus dem Frontend ist für den Versicherten für jeden TI-Fachdienst (E-Rezept, Patientenakte, PoPP) immer gleich.

Über die Benutzeroberfläche löst der Versicherte die gewünschte Funktion aus. Das Frontend sendet daraufhin einen Request an den Authorization Server des jeweiligen Fachdienst. Dieser stellt daraufhin eine Autorisierungsanfrage (Pushed Authorization Request) an den sektoralen IDP, welcher die Identitätsdaten des Versicherten hält.

Der Versicherte muss sich dann geeignet authentisieren. Dazu hat entweder die Kassen-App ein integriertes Authenticator-Modul oder es ist eine zusätzliche Authentisierungs-App auf dem Gerät des Versicherten installiert. Nach erfolgreicher Authentisierung erhält der Versicherte Zugang zu den eigentlichen Funktionen des TI-Fachdienstes.

Der PoPP-Service ist in diesem Kontext der TI-Fachdienst. Dem Versicherten zum "Check-in" wird für eine Behandlung (bspw. in einer Praxis) ein Frontend, das PoPP-Modul, angeboten. Technisch muss der PoPP-Service neben der Benutzeroberfläche, also dem in eine App integrierten PoPP-Modul, auch einen PoPP-Service Authorization Server bereitstellen.

Neben der Authentisierung mittels GesundheitsID ist auch die mobile Authentisierung der eGK möglich. Die Authentisierung der eGK erfolgt durch das Senden von APDU-Commands vom PoPP-Service Resource Server direkt an eGK.  

Nach erfolgreicher Authentisierung mit GesundheitsID oder eGK erhält das PoPP-Modul, je nach Konstellation und Konfiguration, ein TAN-Set mit "langen" TAN oder eine "kurze" TAN. Diese können dann je nach Anwendungsfall in Form eines QR-Code oder als Zahlenwert (bei "kurze" TAN) im PoPP-Modul angezeigt werden kann.

Die folgende Abbildung zeigt den Ablauf zur Erlangung einer TAN durch das PoPP-Modul für die beiden unterscheidlichen Check-in Prozesse.

Abbildung 14: Sequenzdiagramm Nutzer Authentisierung mit GesundheitsID oder eGK und die Erlangung einer TAN oder eines TAN-Sets über ein PoPP-Modul

Unabhängig von der Wahl des mobilen Check-in Prozesses über GesundheitsID oder mit eGK hat der Versicherte die Möglichkeit eine LEI (und damit eine Telematik-ID) auszuwählen, zu der eine "kurze" TAN generiert werden soll. Wird keine LEI ausgewählt, so wird ein TAN-Set mit "langen" TAN ohne LEI-Bezug generiert.

Nach Auswahl des Check-in Prozess unterscheiden sich die Abläufe jedoch. Die folgende Tabelle zeigt die Schritte im Ablauf, wenn der Check-in über die Authentisierung des Versicherten mit GesundheitsID erfolgt.

Tabelle 14: Kurzbeschreibung des Ablaufs der Nutzerauthentisierung mit GesundheitsID für die Erlangung einer TAN oder eines TAN-Sets über ein PoPP-Modul

Der Ablauf bei der Verfizierung der eGK läuft etwas anders ab. Die folgende Tabelle beschreibt die Schritte nach der optionalen Auswahl einer LEI und der Auswahl "eGK(mobil)" für den Check-in Prozess.

Tabelle 15 : Kurzbeschreibung des Ablaufs der Authentifizierung der eGK für die Erlangung einer TAN oder eines TAN-Sets über ein PoPP-Modul

Nach der Authentisierung mit GesundheitsID oder eGK liegen im PoPP-Service Resource Server alle Information gesichert vor, um die TAN-Generierung durchzuführen. Dabei werden noch folgende Schritte durchlaufen.

Tabelle 16 : Kurzbeschreibung des Ablaufs nach Authetifizierung mit GesundheitsID oder eGK für die Erstellung einer TAN oder eines TAN-Sets und Übergabe an das PoPP-Modul

Hinweis: Die Anforderungen an einen FD als Relying Party in der TI-Föderation sind in [gemSpec_IDP_FD] beschrieben.

Hinweis: Der Scope urn:telematik:versicherter enthält als Claim die KVNR des Versicherten (siehe auch [gemSpec_IDP_Sek#Kapitel Token-Endpunkt Ausgangsdaten]).

6.1.5 Schnittstellen

Die Schnittstellenbeschreibung für die Erlangung eines Access Token, um auf den PoPP-Service zugreifen zu können, ist als OpenAPI-Dokumentation in [I_PoPP_Checkin_AuthorizationServer.yaml] hinterlegt. Die relevanten Anforderungen verweisen auf die dort dokumentierte Schnittstellendefinition.

6.2 PoPP-Service - Resource Server

Innerhalb des PoPP-Service Resource Server sind die Komponenten und Funktionalitäten zusammengefasst, die zur Erstellung der PoPP-Token als Nachweis des Versorgungskontextes beitragen. 
Im Wesentlichen werden die LEI-Informationen (TelematikID) und die Versicherten Informationen (KVNR und IK-Nummer) verarbeitet, ggf. temporär gespeichert, und ein PoPP-Token erstellt.
Die Zugriffsautorisierung wird für Primärsysteme (PS) der LEI dabei vom ZETA Guard in Form von signierten Access Token erzeugt und über das DPoP-Verfahren an das Client-System gebunden.

Für den PoPP-Service nutzende Client-Systeme (mobile Apps) der Anwendungen in den Händen der Versicherten, stellt der PoPP-Service Authorization Server entsprechende Access Token aus.

Hinweis: Eine Vertrauensstellung des PoPP-Service (Resource Server) besteht hierbei zum ZETA Guard und zum Authorization Server des PoPP-Service.

6.2.1 eGK-Handling

6.2.1.1 eGK-Handling, Einführung

Ohne hier auf eine Zerlegung des Systems PoPP-Service einzugehen wird in diesem Kapitel beschrieben und spezifiziert, wie das System PoPP-Service Nachrichten mit einer Smartcard austauscht. Der Transport solcher Nachrichten wird in anderen Kapiteln behandelt. Deshalb ist das Kommunikationsmodell hier einfach: Der PoPP-Service schickt Kommando APDU zu einer Smartcard und erhält von dort die korrespondierenden Antwort APDU zur Auswertung.

Der PoPP-Service kommuniziert im Rahmen der folgenden Use Cases mit einer Smartcard:

1. Ein Versicherter "steckt" seine eGK in einen Kartenleser, der über einen PoPP-Client mit dem PoPP-Service kommuniziert. Unterpunkte:
1. Der Versicherte befindet sich in einer LEI und
1. eGK, kontaktbehaftet in einem eH-KT, oder
2. eGK, kontaktbehaftet in einem Standard-Kartenleser, oder
3. eGK, kontaktlos in einem eH-KT, oder
4. eGK, kontaktlos in einem Standard-Kartenleser.
2. Der Versicherte und ein LE befinden sich außerhalb einer LEI. Der LE verfügt über ein mobiles Endgerät mit PS und die eGK kommuniziert
1. kontaktbehaftet mit einem am PS angeschlossenen Standard-Kartenleser oder
2. kontaktlos mit einem am PS angeschlossenem Standard-Kartenleser.
2. Ein Versicherter nutzt beim mobilen Check-in ein Versichertenendgerät um vom PoPP-Service ein TAN-Set zu erhalten. Das Versichertenendgerät verfügt über einen Standard-Kartenleser mit dem die eGK
1. kontaktbehaftet kommuniziert oder
2. kontaktlos kommuniziert.

Im Rahmen der Erzeugung eines PoPP-Token verfolgt der PoPP-Service bei der Kommunikation mit einer Smartcard die folgenden Ziele:

1. Der PoPP-Service überzeugt sich, dass es sich bei der Smartcard um eine echte eGK handelt.
2. Der PoPP-Service überzeugt sich, dass die eGK gültig ist.
3. Der PoPP-Service liest aus der eGK Daten aus, die für die Erstellung des PoPP-Token relevant sind.

Die genannten Ziele werden bei kontaktbehafteter Kartenkommunikation mit einer eGK basierend auf [gemSpec_eGK_ObjSys_G2.1] wie folgt erreicht:

1. Der PoPP-Service baut einen Trusted Channel mit der Identität ID.C.eGK.AUT_CVC.E256 auf. Gelingt dies, dann ist die Echtheit der eGK bestätigt.
2. Der PoPP-Service liest innerhalb des Trusted Channels das X.509 Zertifikat aus der Datei EF.C.CH.AUT.E256 aus und überprüft dieses auf Gültigkeit.
3. Der PoPP-Service entnimmt dem ausgelesenen X.509 Zertifikat die für das PoPP-Token notwendigen Informationen.

Die genannten Ziele werden bei kontaktloser Kartenkommunikation mit einer eGK basierend auf [gemSpec_eGK_ObjSys_G2.1](die einen PACE Kanal voraussetzt) wie folgt erreicht:

1. Der PoPP-Service authentisiert die eGK mit der Identität ID.C.eGK.AUT_CVC.E256. Wegen [gemSpec_COS#N107.235)b] ist es nicht möglich dabei einen Trusted Channel zwischen PoPP-Service und eGK zu etablieren.
2. Der PoPP-Service liest aus der eGK das X.509 Zertifikat aus der Datei EF.C.CH.AUT.E256 aus und überprüft dieses auf Gültigkeit. Da der Kommunikationskanal zwischen PoPP-Service und eGK im kontaktlosen Fall nicht Ende-zu-Ende gesichert ist, ist der PoPP-Service nicht ohne weiteres in der Lage zu beurteilen, ob das im präsentierte X.509 Zertifikat von derselben eGK stammt, deren Echtheit er mit der Identität ID.C.eGK.AUT_CVC.E256 überprüft hat. Deshalb konsultiert der PoPP-Service im kontaktlosen Fall eine Datenbank, welche die Frage beantwortet: Stammen das CV-Zertifikat der Echtheitsprüfung und das präsentierte X.509 Zertifikat aus ein und derselben eGK? So eine Datenbank wird in [Kapitel ] beschrieben.
3. Der PoPP-Service entnimmt dem präsentierten X.509 Zertifikat die für das PoPP-Token notwendigen Informationen.

Der PoPP-Service schaltet in der eGK nichts frei und erwartet auch nicht, dass in der eGK etwas freigeschaltet ist, insbesondere weder durch Card-2-Card noch durch eine PIN-Eingabe. Technisch ist dies gleichbedeutend mit der Aussage, dass der PoPP-Service nur solche Kommando APDU an eine eGK sendet, für die im Rahmen der Objektsystemspezifikation die Zugriffsbedingung "ALWAYS" festgelegt ist ("ALWAYS" = jeder, der im Besitz der Karte ist, ist in der Lage diese Operation auszuführen).

Hinweis 1: Im kontaktlosen Fall funktioniert eine sinnvolle Kartenkommunikation mit der eGK nur nach Aufbau eines PACE-Kanals. Weil die dazu notwendige CAN auf der eGK aufgedruckt ist und somit jeder, der im Besitz der eGK ist so einen PACE-Kanal aufzubauen in der Lage ist, wird hier der Einfachheit halber die Etablierung eines PACE-Kanals und die damit verbundene Freischaltung von Funktionalität in der eGK auch unter "ALWAYS" subsumiert.

Hinweis 2: Im kontaktlosen Fall stehen nach Etablierung eines PACE-Kanals dieselben Daten und Funktionen in einer eGK zur Verfügung, wie im kontaktbehafteten Fall unmittelbar nach Stecken einer eGK.

Hinweis 3: Für die Generation 3 einer eGK ist geplant, dass eine eGK G3 eine Identität besitzt, die sich ohne PIN-Eingabe nutzen lässt und deren zugehöriges X.509 Zertifikat alle Informationen enthält, die für ein PoPP-Token relevant ist.

Abbildung 15: Zustandsdiagramm für die Verarbeitung einer eGK

Abbildung "Zustandsdiagramm für die Verarbeitung einer eGK" zeigt das Zustandsdiagramm für die Verarbeitung einer eGK. Der PoPP-Service wartet in jedem der gezeigten Zustände auf den Empfang einer Nachricht. Er bearbeitet die Nachricht, sendet eine passende Nachricht zurück und geht in den Folgezustand über. Berücksichtigt sind die kontaktbehaftete und die kontaktlose Handhabung einer eGK Generation 2.x, sowie die (geplante) Handhabung einer eGK Generation 3 (für welche die Handhabung kontaktbehaftet und kontaktlos identisch ist). Das Zustandsdiagramm berücksichtigt nur Gutfälle. Das bedeutet, Fehlerfälle, Abbrüche und ähnliches sind im abgebildeten Zustandsdiagramm nicht enthalten.

6.2.1.2 Szenario

In diesem Kapitel ist "Szenario" definiert als eine Abfolge von Elementen in einer Liste. Jedes Element beschreibt entweder Statuswörter, die als Gutfall für eine Antwort APDU gewertet werden, oder eine Kommando APDU.

Definition CommandApdu: Eine Kommando APDU gemäß [gemSpec_COS].

Definition ExpectedStatusWord: Eine Menge mit einem oder mehreren Statuswörtern aus [gemSpec_COS].

Definition ScenarioStep: Eine Aggregation von genau einer CommandApdu und einem Objekt ExpectedStatusWord.

Definition Szenario: Eine Liste mit keinem, einem oder mehreren Elementen des Typs ScenarioStep.

Hinweis 1: "StandardScenarioMessage.steps" lässt sich auffassen als ein Skript, welches abzuarbeiten ist. Ein "Interpreter" eines "StandardScenarioMessage.steps" wertet das Skript Element für Element aus. Die im Element enthaltene Kommando APDU wird an eine Smartcard gesendet. Falls die korrespondierende Antwort APDU der Smartcard ein Statuswort enthält, welches Element der Menge "ExpectedStatusWord" ist, dann fährt der Interpreter mit dem nächsten Listenelement fort, ansonsten bricht er die Bearbeitung des Skripts ab (Exceptionhandling).

Hinweis 2: Ein "sehr einfacher Interpreter" wird "ExpectedStatusWord" ignorieren und auf die Auswertung der Statuswörter in den Antwort APDU verzichten. So ein Interpreter erkennt keine Fehlerfälle. Im Fehlerfall wird so ein Interpreter ein möglicherweise sehr langes Skript zeitintensiv auch noch dann fortsetzten, wenn ein "intelligenter Interpreter" erkannt hätte, dass ein Fortsetzen wegen eines Fehlers nicht sinnvoll ist.

Gemäß Abbildung "Systemkontext PoPP-Lösung" schickt der PoPP-Service StandardScenarioMessages entweder an ein PS, wo die Szenarien vom PoPP-Client bearbeitet oder an einen Konnektor weitergeleitet werden, oder an ein anderes Gerät. Hier ist lediglich die Unterscheidung wichtig, ob eine StandardScenarioMessage von einem Konnektor verarbeitet wird oder nicht. Sobald sich ein Gerät mit dem PoPP-Service verbindet, teilt es dem PoPP-Service mit, ob Szenarien von einem Konnektor verarbeitet werden, oder nicht (Property "cardConnectionType" in der "StartMessage").

6.2.1.3 eGK öffnen

Dieses Kapitel beschreibt, wie ermittelt wird, ob es sich bei der präsentierten Smartcard um eine eGK handelt und welche Version diese hat. Die Vorgehensweise ist unabhängig davon, ob die Smartcard kontaktbehaftet oder kontaktlos betrieben wird. Deshalb wird hier auf eine diesbezügliche Unterscheidung verzichtet.

Hinweis 1: Das erste Listenelement selektiert das Masterfile (MF) einer eGK. Dieses Kommando bringt eine eGK in einen für die nachfolgenden Kommandos definierten Zustand. Antwortet die Smartcard auf dieses Kommando mit einem erwarteten Statuswort, dann handelt es sich um eine eGK (oder um eine Smartcard, die vorgaukelt eine eGK zu sein). Wird irrtümlich eine Karte mit falschem Typ angesprochen (etwa ein HBA oder eine Bankkarte), dann wird das durch ein inakzeptables Statuswort erkannt. Falls eine Karte vorgaukelt eine eGK zu sein, dann wird dies in einem späteren Szenario erkannt.

Hinweis 2: Das zweite Listenelement liest den Inhalt von EF.Version2. Basierend auf den Versionsinformationen ist es möglich eGK unterschiedlicher Generationen zu erkennen, oder beispielsweise wegen Schwachstellen abzulehnen.

Definition: eGKincludedPtvObjSys ist eine Menge mit Produkttypversionen von eGK Objektsystemen, die der PoPP-Service zu unterstützen hat. Produkttypversionen werden in diese Menge aufgenommen oder aus ihr entfernt, wenn sich die Anforderungslage (also die Vorgaben der gematik) ändern. Basierend auf den Erfahrungen der Vergangenheit ist davon auszugehen, dass sich diese Menge nur wenige Male pro Jahr ändert, während sich die Anzahl zugelassener Kartenprodukte häufiger ändert. Deshalb wird die Menge zulässiger Kartenprodukte über die Produkttypversion definiert.

Definition: eGKexcludedPiObjSys ist eine Menge mit Produktidentifikationen aktiver Objektsysteme, die von der Verwendung durch den PoPP-Service ausgeschlossen werden. Produktidentifikationen der Kartenhersteller werden in diese Menge aufgenommen, wenn es Schwierigkeiten mit einem konkreten Kartenprodukt gibt. Basierend auf den Erfahrungen der Vergangenheit ist davon auszugehen, dass die Mächtigkeit der Menge klein ist und sich nur selten ändert.

Hinweis 1: Die Produkttypversion eines Kartenproduktes findet sich in der Datei EF.Version2. Basierend auf der Anforderungslage der gematik besteht die Menge eGKincludedObjSys im Januar 2025 aus folgenden Elementen:
{'040400', '040401', '040500', '040501', '040502', '040600', '040700'}.
Mit Einführung der eGK Generation 3 wird die Menge (laut aktuellem Plan) um den Wert '050000' ergänzt.

Hinweis 2: Die Produktidentifikation des aktiven Objektsystems findet sich in der Datei EF.Version2. Basierend auf dem Kenntnisstand Januar 2025 ist die Menge eGKexcludedObjSys leer.

6.2.1.4 eGK G2 kontaktbehaftet

Dieses Kapitel behandelt die kontaktbehaftete Kommunikation mit einer eGK gemäß [gemSpec_eGK_ObjSys_G2.1]. Dies deckt folgende Anwendungsfälle ab:

1. Versicherter in einer LEI, eGK kontaktbehaftet in einem eH-KT
2. Versicherter in einer LEI, eGK kontaktbehaftet in einem Standard-Kartenleser
3. Versicherter und LE außerhalb einer LEI, LE mit mobilem Endgerät mit PS und kontaktbehaftetem Standard-Kartenleser
4. Versicherter mit Versichertenendgerät am PoPP-Service und kontaktbehaftetem Standard-Kartenleser

Im Gutfall schickt der PoPP-Service drei weitere Szenarien mit jeweils mehreren Kommando APDU an die Karte:

Hinweis 1: Das erste Listenelement liest den Inhalt von EF.C.CA.CS.E256 mit CVC-Sub-CA aus. Der PoPP-Service benötigt dieses CV-Zertifikat zur Verifikation des End-Entity-CVC (sofern er es nicht aus anderen Quellen bereits kennt).

Hinweis 2: Das zweite Listenelement liest den Inhalt von EF.C.eGK.AUT_CVC.E256 mit dem End-Entity-CVC aus. Der PoPP-Service benötigt dieses CV-Zertifikat für die Berechnung der Sessionkeys.

Hinweis 3: Das dritte Listenelement (LIST PUBLIC KEY) liest die in der Smartcard verfügbaren öffentlichen Schlüssel aus. Basierend auf dieser Liste ist es dem PoPP-Service möglich eine kurze Chain von CV-Zertifikaten zusammenzustellen für den Import seines CV-Authentisierungsschlüssels (siehe Szenario SceTC1). Im besten Fall ist kein CV-Zertifikatsimport erforderlich, weil die eGK bereits über den CV-Authentisierungsschlüssel des PoPP-Service verfügt.

Hinweis 1: Das erste Listenelement ist ein MSE Set Kommando gemäß [gemSpec_COS#(N100.900)] zur Selektion des privaten Schlüssels PrK.eGK.AUT_CVC.E256 für den Algorithmus elcSessionkey4SM. Dieser Schlüssel ist kartenseitig am Aufbau des Trusted Channels beteiligt.

Hinweis 2: Jedes Paar aus MSE Set Kommando und PSO Verify Certificate Kommando importiert einen öffentlichen Schlüssel in die Smartcard.

1. SceTC1 enthält kein solches Paar, wenn der öffentliche CV-Authentisierungsschlüssel des PoPP-Service bereits in der Smartcard gespeichert ist.
2. SceTC1 enthält genau ein solches Paar, wenn der öffentliche Schlüssel zur Verifikation des End-Entity-CVC des PoPP-Service bereits in der Smartcard gespeichert ist:
   CVC-Chain = End-Entity-CVC.
3. SceTC1 enthält genau zwei solche Paare, wenn der öffentliche Root-Schlüssel in der Smartcard gespeichert ist, mit dem sich das CVC-Sub-CA zum End-Entity-CVC des PoPP-Service verifizieren lässt:
   CVC-Chain = CVC-Sub-CA, End-Entity-CVC.
4. SceTC1 enthält genau drei solche Paare, wenn der öffentliche Root-Schlüssel in die Smartcard zu importieren ist, mit dem sich das CVC-Sub-CA zum End-Entity-CVC des PoPP-Service verifizieren lässt:
   CVC-Chain = Link-CVC-Root, CVC-Sub-CA, End-Entity-CVC.
5. SceTC1 enthält mehr als drei solcher Paare, wenn mehr als ein CVC-Root-Schlüssel in die Smartcard zu importieren ist.

Hinweis 3: MSE Set Kommando gemäß [gemSpec_COS#(N103.300)] zur Selektion eines öffentlichen Signaturprüfschlüssels in der Smartcard. Der Wert CAR entspricht dem Wertfeld des Elementes CAR des CV-Zertifikates, welches im nächsten Kommando importiert wird.

Hinweis 4: PSO VerifyCertificate Kommando gemäß [gemSpec_COS#(N095.410)] zum Import eines CV-Zertifikates. Der Wer CvcTemplate entspricht dem Wertfeld (value-field) des BER-TLV codierten CV-Zertifikates.

Hinweis 5: Das letzte Listenelement ist ein GENERAL AUTHENTICATE Kommando gemäß [gemSpec_COS#(N085.012)]. Dies ist der erste Schritt zur Etablierung eines Trusted Channels zwischen PoPP-Service und Smartcard. Der zweite und letzte Schritt wird in SceReadX.509 ausgeführt.

Hinweis 1: Das erste Listenelement ist ein GENERAL AUTHENTICATE Kommando gemäß [gemSpec_COS#(N085.016)] mit ephemeralPK_PoPP-Service als ephemerem öffentlichen Schlüssel des PoPP-Service. Dies ist der zweite und letzte Schritt zur Etablierung eines Trusted Channels. Der PoPP-Service ist nun in der Lage mit dem von ihm erzeugten ephemerem Schlüsselpaar, seinem privaten CV-Authentisierungsschlüssel und ephemeralPK_eGK aus [A_27011*] Sessionkeys gemäß [gemSpec_COS#(N85.054)c] zu berechnen. Alle folgenden Kommandos sind mit den vereinbarten Sessionkeys zu sicheren gemäß den Regeln aus [gemSpec_COS#13]. Dies wird in der Anforderung durch einen '*' hinter CommandApdu angedeutet.

Hinweis 2: Das zweite Listenelement selektiert das Verzeichnis DF.ESIGN. Das Kommando ist in [A_27003*] im Klartext notiert. Im real verwendeten Szenario ist es gemäß den Regel aus [gemSpec_COS#13] zu sichern. Die zugehörige Antwort APDU wird von der Smartcard gemäß [gemSpec_COS#13] gesichert.

Hinweis 3: Das dritte Listenelement liest das X.509 Zertifikat aus der Datei EF.C.CH.AUT.E256. Das Kommando ist in [A_27003*] im Klartext notiert. Im real verwendeten Szenario ist es gemäß den Regel aus [gemSpec_COS#13] zu sichern. Die zugehörige Antwort APDU wird von der Smartcard gemäß [gemSpec_COS#13] gesichert.

6.2.1.5 eGK G2 kontaktlos

Dieses Kapitel behandelt die kontaktlose Kommunikation einer eGK gemäß [gemSpec_eGK_ObjSys_G2.1]. Dies deckt folgende Anwendungsfälle ab:

1. Versicherter in einer LEI, eGK kontaktlos in einem eH-KT
2. Versicherter in einer LEI, eGK kontaktlos in einem Standard-Kartenleser
3. Versicherter und LE außerhalb einer LEI, LE mit mobilem Endgerät mit PS und kontaktlosem Standard-Kartenleser
4. Versicherter mit Versichertenendgerät am PoPP-Service und kontaktlosem Standard-Kartenleser

Im Gutfall schickt der PoPP-Service nach dem in [A_27008*] beschriebenen Szenario ein weiteres Szenario mit einer Reihe von Kommando APDU an die Karte:

Hinweis 1: Das erste Listenelement liest den Inhalt von EF.C.CA.CS.E256 mit CVC-Sub-CA aus. Der PoPP-Service benötigt dieses CV-Zertifikat zur Verifikation des End-Entity-CVC (sofern er es nicht aus anderen Quellen bereits kennt).

Hinweis 2: Das zweite Listenelement liest den Inhalt von EF.C.eGK.AUT_CVC.E256 mit dem End-Entity-CVC aus. Der PoPP-Service benötigt dieses CV-Zertifikat für die Authentisierung.

Hinweis 3: Das dritte Listenelement selektiert das Verzeichnis DF.ESIGN.

Hinweis 4: Das vierte Listenelement ist ein MSE Set Kommando gemäß [gemSpec_COS#(N100.900)] zur Selektion des privaten Schlüssels PrK.eGK.AUT_CVC.E256 für den Algorithmus elcRoleAuthentication.

Hinweis 5: Das fünfte Listenelement liest das X.509 Zertifikat aus der Datei EF.CH.AUT.E256.

Hinweis 6: Das sechste Listenelement ist ein INTERNAL AUTHENTICATE Kommando gemäß [gemSpec_COS#(N086.400)].

6.2.1.6 eGK G3 kontaktbehaftet und kontaktlos

Dieses Kapitel behandelt die kontaktbehaftet und die kontaktlose Kommunikation einer eGK der Generation 3, so wie es Stand Januar 2025 geplant ist. Dies deckt alle Anwendungsfälle aus [Kapitel ] ab.

Im Gutfall schickt der PoPP-Service nach dem in [A_27008*] beschriebenen Szenario ein weiteres Szenario mit einer Reihe von Kommando APDU an die Karte:

Hinweis 1: Das erste Listenelement selektiert das Verzeichnis DF.ESIGN.

Hinweis 2: Das zweite Listenelement ist ein MSE Set Kommando gemäß [gemSpec_COS#(N102.900)] zur Selektion des privaten Schlüssels PrK.CH.AutU.E256 für den Algorithmus signECDSA.

Hinweis 3: Das dritte Listenelement liest das X.509 Zertifikat aus der Datei EF.CH.AutU.E256.

Hinweis 4: Das vierte Listenelement ist ein PSO Compute Digital Signature Kommando gemäß [gemSpec_COS#(N087.500)] wobei das Kommandodatenfeld einen Hashwert über eine Challenge enthält. Die zugehörige Antwort APDU wird im Erfolgsfall eine Signatur zur Challenge enthalten.

6.2.1.7 Prüfung des X.509 Zertifikates einer eGK

In [A_27013*], [A_27021*] und [A_27023*] wird gefordert, dass der PoPP-Service das aus einer eGK ausgelesene X.509 Zertifikat zu prüfen hat. Dies geschieht wie folgt:

Hinweis: Der OCSP-Responder des TSP eGK ist im Internet erreichbar. Die Adresse des OCSP-Responders ist dem Authority Information Access (AIA) des eGK-Zertifikats zu entnehmen.

6.2.1.8 eGK-Handling Fehlercodes

In den vorherigen Kapiteln zum eGK-Handling werden diverse Fehlermeldungen definiert. Dabei ist es das Ziel für jede Stelle, an der ein Fehler detektierbar ist, eine eigene Fehlermeldung zu definieren, für den Fall, dass es an der Außenschnittstelle relevant ist. Derart aussagekräftige Fehlermeldungen unterstützen in der Entwicklungs- und Testphase das Debugging. Für den realen Betrieb ist zweifelhaft, ob aussagekräftige Fehlermeldungen sinnvoll sind. Mitunter wird gewünscht einem Angreifer nicht zu viel darüber zu verraten, an welcher Stelle genau sein Angriff scheiterte. Konkret auf das eGK-Handling bezogen ist es aus Sicht menschlicher Nutzer eher so, dass eine eGK sich eignet um ein PoPP-Token zu erstellen, oder eben nicht. Die Tabelle in diesem Kapitel weist jeder (internen) Fehlermeldung des PoPP-Service eine Fehlermeldung zu, die an der Außenschnittstelle am Interface [I_PoPP_Token_Generation.yaml] oder [I_PoPP_CheckIn_ResourceServer.yaml] sichtbar sind.

6.2.1.9 eGK-Hash-Datenbank

Die "eGK-Hash-Datenbank" im PoPP-Service beantwortet die Frage: "Stammt ein vorgelegtes CV-Zertifikat und ein vorgelegtes X.509 Zertifikat aus ein und derselben eGK?"

So eine eGK-Hash-Datenbank wird im PoPP-Service für eGK der Generation 2.x für den Fall benötigt, dass die eGK kontaktlos kommuniziert. Die einfachste Art der technischen Umsetzung wäre eine (mathematische) Funktion, die jedem CV-Zertifikat genau ein X.509 Zertifikat zuordnet. Softwaretechnisch wäre das eine Tabelle (in Java ein Map). In dem Fall enthielte die Tabelle personenbezogene Daten, was weder datensparsam noch datenschutzfreundlich wäre. Stattdessen verwendet die eGK-Hash-Datenbank eine Menge setEgkHashes, wobei jedes Element der Menge ein SHA-256 Hashwert über die Konkatenation von CV-Zertifikat und X.509 Zertifikat ist. Wenn der eGK-Hash-Datenbank dann ein Pärchen aus CV-Zertifikat und X.509 Zertifikat präsentiert wird, beantwortet die eGK-Hash-Datenbank letztendlich die Frage: "Ist der zugehörige SHA-256 Hashwert für das vorgelegte CV-Zertifikat und X.509 Zertifikat Element der Menge?"

Überlegungen zum Mengengerüst: Es gibt (Stand Januar 2025) fast 75 Millionen gesetzlich Versicherte mit eGK Generation 2.x. Es ist davon auszugehen, dass die Anzahl "nicht abgelaufener eGK" darüber liegt, weil es Versicherte gibt, die über mehr als eine "nicht abgelaufene eGK" verfügen, beispielsweise Ersatz für defekte eGK oder infolge eines Kassenwechsels. Hier wird geschätzt, dass die eGK-Hash-Datenbank so zu dimensionieren ist, dass die Mächtigkeit der Menge setEgkHashes bis zu 100.000.000 (100 Millionen) reicht. 100 Millionen SHA-256 Werte beanspruchen netto 3.200 Millionen Byte, also 3,2 Gigabyte rund 3 Gibi Byte. Das ist eine Größenordnung, die für eine moderne Infrastruktur keine besonderen Ansprüche stellt.

Überlegungen zur Befüllung der Menge setEgkHashes: Ein neues Element wird der Menge setEgkHashes hinzugefügt, wenn ein KTR (oder dessen Dienstleister) das neue Element dem PoPP-Service mitteilt, oder wenn eine eGK Generation 2.x kontaktbehaftet vom PoPP-Service angesprochen wird (lazy-initialization, siehe [A_27013*]). Bei der Anlieferung von Elementen für die Menge setEgkHashes verwendet der KTR (oder dessen Dienstleister) eine mTLS Verbindung und übermittelt die Elemente als signierte Nachricht.

Überlegungen zum Entfernen von Elementen aus setEgkHashes: Es ist nicht vorgesehen, dass KTR (oder deren Dienstleiter) in der Lage sind das Entfernen eines Elementes aus setEgkHashes zu veranlassen. Stattdessen ist vorgesehen, dass jedem Element ein Verfallsdatum zugeordnet ist, welches sich aus dem Element "notAfter" aus dem X.509 Zertifikat ergibt. Die eGK-Hash-Datenbank ist damit in der Lage "abgelaufene" Elemente aus der Menge setEgkHashes zu entfernen. Die eGK-Hash-Datenbank wird nicht dazu verpflichtet "abgelaufene" Elemente aus der Menge setEgkHashes zu entfernen. Falls die eGK-Hash-Datenbank in der Lage ist auch mit einer sehr großen Anzahl an Elementen in setEgkHashes umzugehen, dann ist ein Entfernen "abgelaufener" Werte auch nicht erforderlich. Die eGK-Hash-Datenbank beantwortet ja nur die Frage ob ein vorgelegtes Pärchen aus einer eGK stammt, nicht aber, ob das X.509 Zertifikat des Pärchens noch gültig ist. Die Frage "ist ein X.509 Zertifikat noch gültig?" wird nicht von der eGK-Hash-Datenbank, sondern an anderer Stelle beantwortet (siehe Prüfung des X.509 Zertifikats in [A_27130*]).

Definition listImportClients: Die Liste listImportClients enthält Identitäten, die der PoPP-Service akzeptiert, wenn diese als Client eine mTLS Verbindung aufbauen zum Zweck des Imports von Hashwerten in die eGK-Hash-Datenbank.

Definition listSignatureVerificationKeys: Die Liste listSignatureVerificationKeys enthält Identitäten, die der PoPP-Service akzeptiert, wenn diese signierte Nachrichten zum Zweck des Imports von Hashwerten an die eGK-Hash-Datenbank übermitteln.

Hinweis: Die Liste listImportClients erhält der Anbieter des PoPP-Service direkt vom jeweiligen Kassen-Dienstleister und die Liste listSignatureVerificationKeys wird dem Hersteller des PoPP-Service von der gematik zur Verfügung gestellt (vgl. [A_27153*]).

Hinweis 1: Es ist nicht erforderlich, dass die eGK-Hash-Datenbank für jeden Hashwert individuell ein Ablaufdatum speichert. Es ist beispielsweise möglich einem Ablaufdatum eine Menge von Hashwerten zuzuordnen. Der Speicher der eGK-Hash-Datenbank enthält dieses Ablaufdatum dann nur einmal.

Hinweis 2: Aus Sicherheitsgründen ist es erforderlich, dass ein in setEgkHashes gespeicherter Hashwert nicht einem konkreten X.509 Zertifikat zuzuordnen ist. Deshalb enthält das Ablaufdatum in der eGK-Hash-Datenbank nicht den vollständigen Wert "notAfter" aus dem X.509 Zertifikat, sondern lediglich dessen Jahr und Monat.

Hinweis 3: Jedes technische System hat eine Speichergrenze. Das Ignorieren von Hashwerten, die sich nicht mehr speichern lassen, verhindernd undefinierte Zustände durch Speicherüberlauf.

Hinweis 4: Sowohl CV-Zertifikate, als auch X.509 Zertifikate verwenden aktuell SHA-256 als Hashverfahren. Deshalb ist es aus Sicherheitssicht ausreichend in setEgkHashes ebenfalls SHA-256 Werte zu speichern. Insgesamt gibt es 2^256 = 1,16x10^77 verschiedene SHA-256 Hashwerte. Angenommen jedem dieser Hashwerte wird ein Volumen zugeordnet, wie es ein Coronavirus einnimmt, dann käme im Mittel pro Würfel mit einer Kantenlänge von zwei Lichtjahren ein Coronavirus. Das bedeutet, dass die Menge setEgkHash im Vergleich zu allen möglichen Werten so dünn besetzt. ist, dass es für einen Angreifer praktisch unmöglich ist ein Pärchen aus gültigem CV-Zertifikat und gültigem X.509 Zertifikat zu finden, das nicht aus ein und derselben eGK stammt, aber trotzdem von der eGK-Hash-Datenbank eine "ja"-Antwort bekommt.

Hinweis 5: Die Codierung von "signedMessage" wird derzeit mit den Kostenträgern und deren Dienstleistern abgestimmt.

6.2.2 Zugriffsautorisierung und Business-Logik

Bei mobilen Szenarien, wie "online Check-in", "online Apotheke" oder "Anmeldung Videosprechstunde" muss der Zugriff eines Anwendungsfrontends (App mit integriertem PoPP-Modul) autorisiert werden.

Die Zugriffsautorisierung erfolgt auf der Basis von Client-Identifikation und Nutzerauthentisierung. Die Prüfung der Nutzerauthentisierung wird entweder durch die Authentifizierung des Versicherten mit seiner GesundheitsID oder durch eGK realisiert.

Beim Verbindungsaufbau zwischen Client und PoPP-Service an Schnittstellen zum Internet wird ein API-KEY übermittelt, welcher durch den PoPP-Service an der Web-Schnittstelle auf Zulässigkeit geprüft wird.

API-KEYs werden durch die gematik in ihrer Rolle als Gesamtverantwortlicher der TI erzeugt. Sie sind Zufallswerte mit hoher Entropie und produkt-spezifisch. Die Zulässigkeit von API-KEYs wird von der gematik über organisatorische Prozesse dem Betreiber des PoPP-Service und den Herstellern von Clientsystemen mitgeteilt. Die Übermittlung muss vertraulichkeits- und integritätsgeschützt erfolgen. Die gematik muss bei der Übergabe des API-KEY sicherstellen, dass nur ein berechtigter Client-Hersteller einen für ihn erzeugten API-KEY erhält.

Die Veranlassung zur Sperrung eines API-KEYs erfolgt durch die gematik.

Das Ergebnis der Zugriffsautorisierung ist je nach Verfahren: 

1. ein "eHealth-ID-check" Access Token bei einer Zugriffsautorisierung mit GesundheitsID oder
2. ein "card-check" Access Token bei einer Zugriffsautorisierung mit eGK(mobil).

Die ausgestellten Access Token unterscheiden sich im Inhalt der transportierten Informationen. Die Access Token berechtigen ein PoPP-Modul zum Zugriff auf die fachlichen Schnittstellen des PoPP-Service zum Erhalt von TAN.

Unter Einsatz der TAN erhalten PS authentifizierter LEI einen Nachweis des Versorgungskontextes in Form eines PoPP-Token.

Abbildung 16: Anwendungsfälle des PoPP-Service Authorization Server bei der Zugriffsautorisierung eines in eine App integrierten PoPP-Moduls

Abbildung 17: Anwendungsfälle des PoPP-Service Resource Server beim Zugriff eines in eine App integrierten PoPP-Moduls

Mittels dieser Prozesse werden zulässige API-KEYs übermittelt und API-KEYs als ungültig erklärt.

6.2.2.1 Validierung der Access Token

6.2.2.2 TAN-Set, "lange" und "kurze" TAN

Für das Einlösen von TAN gegen PoPP-Token sind zwei unterschiedliche Typen von TAN vorgesehen. Für Anwendungsfälle mit einem Bezug zu einer konkreten Telematik-ID und somit einer LEI wird eine "kurze" menschenlesbare TAN generiert.

Für Anwendungsfälle, wo es zum Zeitpunkt der TAN-Erstellung keinen Bezug zu einer konkreten Telematik-ID und somit einer LEI gibt, wird ein TAN-Set mit "langer" TAN generiert.

Hinweis: Der Defaultwert für die Anzahl der "langen" TAN eines TAN-Sets beträgt drei.

Hinweis 1: Dezimal numerische Zeichenketten lassen sich leicht in QR-Codes umwandeln.
Hinweis 2: 40 dezimale Ziffern entsprechen rund 132,9 bit Entropie.

Hinweis: Die Anforderungen an den Gültigkeitszeitraum des TANSet-Record sind in A_27328* festgelegt.

6.2.2.3 TANSet-Record

Hinweis: Der Defaultwert für die expirationTime beträgt 48h.

6.2.3 Schnittstelle für Token Abrufe

Die technische Spezifikation der Schnittstelle I_PoPP_Token_Generation zum Abruf von PoPP-Token durch Clientsysteme veröffentlicht die gematik auf GitHub im OpenAPI-Format.
Zusätzlich gelten die folgenden Anforderungen.

Hinweis:
Das Erstellen und Versenden des zusätzlichen VSDM-PN wird über den PoPP-Service konfiguriert. Zu Beginn des PoPP-Service Betriebes ist der Schalter aktiviert. Sobald alle betroffenen Fachanwendungen und PS umgestellt sind, wird der Schalter deaktiviert. Die gematik wird den Betreiber des PoPP-Service dem entsprechend informieren und beauftragen.

Hinweis: Entsprechend [A_26595*] werden die Anwendungskontexte stündlich neu gestartet.

6.3 PoPP-Modul

Die Anforderungen an eine Frontendkomponente für Versicherte sind erfasst in [gemSpec_PoPP_Modul]. Ein PoPP-Modul, welches in eine App integriert wird, muss diese Anforderungen erfüllen.

6.4 PoPP-Client

Die Beschreibung des PoPP-Client

6.5 Fehlerbehandlung

Error Code (HTTP Status Code. ergänzt um operationsspezifische Ergebnisse) werden in den jeweiligen Schnittstellen Dateien (Yaml-Files) erfasst und dokumentiert. 
In der PoPP-Service Spezifikation gibt es keine Auflistung von Error-Code. 

7 Testanforderungen

Anforderungen an Test und Testbarkeit des PoPP-Service finden sich in [gemKPT_Test].

<< Die neuen Test-Festlegungen für PoPP sind im Änderungsantrag C_12019 zusammengeführt. >>
C_12019 - 

8 Betrieb

In diesem Kapitel werden übergreifende, betriebliche Anforderungen getroffen oder auf Kapitel mit speziellen Ausprägungen für den Anbieter PoPP-Service in normativen Querschnittsdokumenten verwiesen.

<<Die Festlegungen werden im Änderungseintrag C_11939 zusammengeführt.>>

< siehe C_11939 >

8.1 Schnittstellen und Anwendungsfälle

Die vom PoPP-Service zur Verfügung gestellten Schnittstellen und Anwendungsfälle werden im entsprechenden Kapitel von [gemKPT_Betr] dargestellt.

8.2 Leistungsanforderungen und Performance

Die vom PoPP-Service zu leistenden Performancevorgaben werden im entsprechenden Kapitel von [gemSpec_Perf] dargestellt. Dazu gehören insbesondere Vorgaben zur Verfügbarkeit, eingesetzten Redundanz und der Leistungsfähigkeit der Schnittstellenabrufe. Darüber hinaus werden Vorgaben zur Verarbeitung der eingesetzten Datenliefermodelle gemacht, die sich sowohl auf den Fachdienst, als auch organisatorisch auf den entsprechenden Anbieter beziehen, welcher diese Datenlieferungen gewährleisten muss.

9 Anhang A – Verzeichnisse

9.1 Abkürzungen

Tabelle 21: Im Dokument verwendete Abkürzungen

9.2 Glossar

Tabelle 22: Glossar der explizit im Dokument verwendeten Begriffe

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

9.3 Abbildungsverzeichnis

9.4 Tabellenverzeichnis

9.5 Referenzierte Dokumente

9.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.

Tabelle 23: Referenzierte Dokumente der gematik

9.5.2 Weitere Dokumente

Tabelle 24 : Weitere Dokumente

9.6 Allgemeine Erläuterungen

9.6.1 Entity Statement des PoPP-Service

Tabelle 25: Entity Statement des PoPP-Service