Telematikinfrastruktur 2.0

Spezifikation

Proof of Patient Presence (PoPP)-Service

    

     

      
Version
      
1.0.0_CC2
     
     

      
Revision
      
1263203
     
     

      
Stand
      
16.06.2025
     
     

      
Status
      
zur Abstimmung freigegeben
     
     

      
Klassifizierung
      
öffentlich_Entwurf
     
     

      
Referenzierung
      
gemSpec_PoPP_Service
     
    

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

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 Versorgungskontexts in Form eines kryptografisch 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 auf TI (Telematikinfrastruktur)-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 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 Versicherten genutzte Anwendungen implementiert werden, welche bei der mobilen Nutzung der elektronischen Gesundheitskarte (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 Produkttyps 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 Dokuments 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 Leistungserbringerinstitution (LEI) befindet. Im kryptografisch 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, welches der LEI zur Autorisierung für den Zugriff auf die Daten des Versicherten in Diensten der Telematikinfrastruktur (TI) dient.

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

1. PoPP-Service - der als TI-Plattformdienst PoPP-Token für eine LEI erstellt. Die LEI authentisiert sich dafür mit der SM(C)-B. Die Identität des Versicherten wird kryptografisch gesichert ermittelt entweder über die Authentisierung seiner eGK oder über die Authentisierung des Versicherten via GesundheitsID.
2. Primärsystem (PS) der LEI - als Host der Client-Seite. Das PS besteht aus den folgenden Komponenten:
   
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 den Check-in 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 Versorgungskontexts (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 einzige 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 Transaktionsnummer (TAN) erzeugt. Die TAN werden später in der LEI zur Herstellung des Versorgungskontexts 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 zu Beginn die Verwendung eines QR-Code zur Übermittlung "langer" TAN beschrieben, um die Interoperabilität dieses Verfahrens sicherzustellen. Da die gematik Technologieoffenheit fördert, ist sie auch für alternative Übertragungsverfahren, wie beispielsweise NFC, offen.

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 [5.1.1 PoPP-Token-Erstellung]) der Versorgungskontext nachgewiesen wurde. Somit ist es den PoPP-Token nutzenden Anwendungen und Diensten möglich, in ihrem Anwendungs- oder Dienstkontext Autorisierungsentscheidungen auch aufgrund der Prüfmethode zu treffen. 

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 sowieden Produktivbetrieb des PoPP-Service aus.
Die gematik unterstützt den Hersteller des 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 ZETA 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-Moduls 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 [6.2.1.9 eGK-Hash-Datenbank]). 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 elektronische Patientenakte (ePA) erzeugen zu lassen. Dabei benutzt die LEI ein für die PoPP-Lösung angepasstes PS, in dem PoPP-Client-Funktionalität, ZETA 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 Versorgungskontexts zwischen LEI und Versicherten mitwirken. Die Versicherten steuern ihre Krankenversichertennummer (KVNR) bei, indem sie sich:

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

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 Request, 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 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 einen PoPP-Token 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 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 eine oder mehrere TAN.
  

• 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 werden 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 ZETA Client triggert über verschiedene Aufrufwege die PoPP-Token-Erstellung, 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 und Anmeldung 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(C)-B:
  im Internet verfügbar für die OCSP-Prüfung von SM(C)-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,
• E-Rezept.

Außerdem sind die App-Backend-Systeme 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 Versorgungskontexts

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 TAN 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 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 eine Authentifizierung gemäß den Vorgaben von [gemSpec_ZETA].

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#Kapitel Ablauf der SM(C)-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 integriertem 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 der 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 eine oder mehrere "lange" 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-Moduls.

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 oder 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 muss die Versichertenidentität verifiziert werden, was in diesem Fall über die Authentifizierung via GesundheitsID stattfindet. 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-Moduls eine "kurze" TAN bzw. eine oder 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 (bspw. 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 überträgt.

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(C)-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 Versorgungskontexts

Die Funktionalität "PoPP-Token: Nachweis des Versorgungskontexts" stellt auf Anforderung von PoPP-Clients ein PoPP-Token bereit. Das PoPP-Token ist ein kryptografisch gesicherter Nachweis eines Versorgungskontexts über zwei Identitäten des Gesundheitswesens (Versicherte, bzw. dessen eGK und LEI). 

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 [4.1 Übersicht der Systemanwendungsfälle für die Ausstellung des PoPP-Token].

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": "x_vW4LVDipvu8iUQ5alKsZLWtH6jh4eJ4c5offXtMV0",
      "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 Master 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.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 für Zugriffe durch Leistungserbringerinstitutionen (LEI) bereits im Sinne der TI 2.0 über die Zero Trust Mechanismen bzw. konkret durch das Einbinden des von der gematik bereitgestellten ZETA Guard. Solange Versichertenzugriffe noch nicht über ZETA abgebildet werden können, finden diese über den PoPP-Service-eigenen AuthZ-Server statt.
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 Vertrauenswürdige Ausführungsumgebung (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 1: Der öffentliche Schlüssel des TLS-Zertifikats des sektoralen IDPs ist im jwks derjenige, bei dem das "x5c" Objekt gesetzt ist. Die Prüfgrundlage für die Vertrauenskette bis zum Federation Master ist durch A_23046*, A_23038* und A_23040* gegeben.

Hinweis 2: Damit bei einem Wechsel des CA-Zertifikats für das TLS-Zertifikat durch den sektoralen IDP die Funktionalität erhalten bleibt, ist eine fortlaufende Aktualisierung des Truststores mit den CAB-Forum-CA-Zertifikaten notwendig. Letzteres ist ebenso aus Sicherheitssicht notwendig bzgl. aus dem Truststore entfernter (gesperrter) Zertifikate, wobei durch die Bindung an den konkreten öffentlichen Schlüssel über das Entity Statement ein zusätzlicher Schutz besteht.

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 [gemSpec_ZETA#A_25406*]). Zudem werden Anfragen von Versicherten (Zugriffe via PoPP-Modul) nicht über den ZETA Guard geleitet, sondern direkt vom Authorization Server des PoPP-Service entgegengenommen - solange ZETA noch keine Versichertenzugriffe unterstützt. Die Formulierung "alle seine Schnittstellen" inkludiert u.a. auch die technische Schnittstelle zu den TSPs der Kassen zur Befüllung der eGK-Hash-Datenbank.
Es sind A_25421* und A_26612* zu berücksichtigen.

Hinweis: Somit können von einer LEI maximal 30 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 [6.2.1.9 eGK-Hash-Datenbank]. 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 wird 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 inkl. eGK-Hash-Datenbank.
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-Image 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 ZETA Guard 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-Images ist, muss es vom Hersteller des PoPP-Services 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-Image 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-Image 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 4-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 das VAU-Image (PoPP-Service 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-Image erhält, kann jederzeit über das Protokoll aus dem HSM nachvollzogen werden, dass vom Anbieter nur die VAU-Image 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-Image, 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-Image 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-Image 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-Image 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-Image 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 drei 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 HSM) und/oder in zusätzlicher vom Anbieter bereitgestellter Hardware (bspw. durch einen mit zusätzlichem Zutrittsschutz ausgestatteten Serverschrank). 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-Image 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-Image 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-Image - 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-Image" ist die Bekanntmachung des vom Dienst-Hersteller signierten Hashwerts eines VAU-Image 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 Verarbeitungskontextes 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-Image 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 [6.2.1.9 eGK-Hash-Datenbank].

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-Image 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-Image 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-Image 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-Image ü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. Die Umsetzung der Anforderung umfasst bspw. Maßnahmen in der Betriebsumgebung, die verhindern, dass Einzelne unbemerkt physischen Zugang bekommen oder dass technische Angriffs-Hilfsmittel (bspw. Flex) in die Betriebsumgebung eingebracht werden. 

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-Image und somit VK verwendet werden

5.3.2 Algorithmus für Schlüsselpaare

5.3.3 Entity Statement

5.3.4 PoPP-Service 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 Request 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-Responder 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-Responder 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 LEI-Zugang zum PoPP-Service (Versichertenzugriffe laufen aktuell noch nicht über ZETA; dies wird in einer Folgestufe von ZETA umgesetzt und dann vom PoPP-Service genutzt). Das Gegenstück zum ZETA Guard des PoPP-Service ist der ZETA Client, der - wie der PoPP-Client - Teil des PS ist. Der ZETA Guard erfüllt folgende Aufgaben:

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-Service Schnittstelle 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(C)-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 [5.2 Datenschutz und Sicherheit]).

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 Client aus dem Internet. Auf Basis des OAuth Framework [RFC6749] stellt er Access Token für in der Föderation registrierte Client 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 authentifiziert.

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

6.1.3.1 Service Discovery und Client Registrierung

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.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. Versicherte haben auf ihrem Gerät eine App, welche ein PoPP-Modul integriert. Dieses PoPP-Modul ist die Benutzeroberfläche des PoPP-Service für die Versicherten und wird in [gemSpec_PoPP_Modul] spezifiziert. Beim Auslösen eines "Check-in" durch den Versicherten über dieses PoPP-Modul muss durch die Komponente PoPP-Service Authorization Server dann sichergestellt werden, dass ein autorisierter Nutzer dieses "Check-in" durchführt. Der PoPP-Service Authorization Server startet dazu die Nutzerauthentifizierung über den sektoralen IDP.

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 Verifikation der Versichertenidentität durch Authentisierung mit GesundheitsID oder Authentisierung der eGK erhält das PoPP-Modul, je nach Konstellation und Konfiguration, eine oder mehrere "lange" 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 unterschiedlichen Check-in Prozesse.

Abbildung 14: Sequenzdiagramm Nutzer Authentisierung mit GesundheitsID oder eGK und die Erlangung von TAN ü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 werden eine oder mehrere "lange" 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 13: Kurzbeschreibung des Ablaufs der Nutzerauthentisierung mit GesundheitsID für die Erlangung von TAN über ein PoPP-Modul

Der Ablauf bei der Verifizierung 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 14: Kurzbeschreibung des Ablaufs der Authentifizierung der eGK für die Erlangung von TAN ü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 15: Kurzbeschreibung des Ablaufs nach Authentifizierung mit GesundheitsID oder eGK für die Erstellung von TAN 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 Versorgungskontexts beitragen. 
Im Wesentlichen werden die LEI-Informationen (Telematik-ID) 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 TAN 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 Channel 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 [6.2.1.9 eGK-Hash-Datenbank] 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 (G)2.x, sowie die (geplante) Handhabung einer eGK G3 (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 enthält eine Kommando-APDU und eine Liste von Statuswörtern, die als Gutfall für eine Antwort-APDU gewertet werden.

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

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

Definition Step: 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 März 2025 aus folgenden Elementen:
{'040400', '040401', '040500', '040501', '040502', '040600', '040700'}.
Mit Einführung der eGK G3 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 März 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 optimale 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 2.a: 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 2.b: PSO VerifyCertificate Kommando gemäß [gemSpec_COS#(N095.410)] zum Import eines CV-Zertifikates. Der Wert CvcTemplate entspricht dem Wertfeld (value-field) des BER-TLV codierten CV-Zertifikates.

Hinweis 3: Das letzte Listenelement ist ein GENERAL AUTHENTICATE Kommando gemäß [gemSpec_COS#(N085.012)]. Der Wert CHR entspricht dem Wertfeld des Elementes CHR des End-Entity-CVC. 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 März 2025 geplant ist. Dies deckt alle Anwendungsfälle aus [6.2.1.1 eGK-Handling, Einführung] 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-Responder 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

Übersicht zu den weiteren Unterabschnitten:

1. "Einleitung und Mengengerüst": die eGK-Hash-Datenbank wird auf hoher Abstraktionsebene beschrieben
2. "Use Cases im laufenden Betrieb": Analyse der Fälle, die im laufenden Betrieb auftreten, das ist die Grundlage für die Spezifikation der "check(. . .)" Funktion in A_27622*
3. "Definition von Begriffen zur Wahrscheinlichkeit": Definition von Begriffen, die in Folgeabschnitten verwendet werden
4. "Use Cases zur Befüllung durch Kostenträger": Analyse der Fälle, die beim Befüllen durch Kostenträger (oder deren Dienstleister) auftreten, das ist die Grundlage für die Spezifikation der "import(. . .)" Methode in A_27623
5. "Weitere Anforderungen an die eGK-Hash-Datenbank": unter anderem Spezifikation der "check(. . .)" Funktion und der "import(. . .)" Methode, basierend auf der Analyse in vorherigen Abschnitten

6.2.1.9.1 Einleitung und Mengengerüst

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

So eine eGK-Hash-Datenbank wird im PoPP-Service für eGK der Generation 2.x benötigt. Die einfachste Art der technischen Umsetzung wäre eine (mathematische) Funktion, die jedem CV-Zertifikat genau ein AUT-Zertifikat zuordnet. Softwaretechnisch wäre das eine Tabelle (in Java ein Map<CVC, AUT>). In dem Fall enthielte die Tabelle personenbezogene Daten, was weder datensparsam noch datenschutzfreundlich wäre. Stattdessen verwendet die eGK-Hash-Datenbank eine Menge egkEntries, die statt der Zertifikate unter anderem Hashwerte der Zertifikate enthält. Wenn der eGK-Hash-Datenbank dann ein Paar aus CV-Zertifikat und AUT-Zertifikat präsentiert wird, beantwortet die eGK-Hash-Datenbank letztendlich die Frage: "Ist a) dem Hashwert des CV-Zertifikats der Hashwert des AUT-Zertifikats zugeordnet und b) wenn das CV-Zertifikat unbekannt ist, ist dem Hashwert des AUT-Zertifikats nicht bereits der Hashwert eines anderen CV-Zertifikats zugeordnet?"

Überlegungen zum Mengengerüst: Es gibt (Stand März 2025) fast 75 Millionen gesetzlich Versicherte mit eGK G2.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 egkEntries bis zu 150.000.000 (150 Millionen) reicht. Zweimal 150 Millionen SHA-256 Werte beanspruchen netto 9.400 Millionen Byte, also 9,4 Gigabyte. Das ist eine Größenordnung, die für eine moderne Infrastruktur keine besonderen Ansprüche stellt.

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

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

Definition „Lieferant“: Mit „Lieferant“ ist in diesem Unterkapitel eine Instanz gemeint, die berechtigt ist dem PoPP-Service neue Elemente für die eGK-Hash-Datenbank zu übermitteln. Es ist möglich, dass die Rolle des „Lieferanten“ von einem Kostenträger selbst wahrgenommen wird. Vermutlich wird es Kostenträger geben, welche das Einliefern von neuen Elementen an ihre Dienstleister delegieren. „Lieferant“ ist im Folgenden damit eine verkürzte Form von „Kostenträger (oder deren Dienstleister)“.

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 Elementen 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 Elementen an die eGK-Hash-Datenbank übermitteln.

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

6.2.1.9.2 Use Cases im laufenden Betrieb

Dieser Abschnitt beschreibt die möglichen Konstellationen, die im PoPP-Service bei der Überprüfung von CV-Zertifikaten und AUT-Zertifikaten mittels der eGK-Hash-Datenbank auftreten, also im Rahmen der "check(. . .)" Funktion nach A_27622*. Es gilt folgende Nomenklatur:

1. Für das genutzte Übertragungsprotokoll zur eGK sind zwei Werte möglich:
1. "T=1": kontaktbehaftete Übertragung mit dem Protokoll T=1 aus ISO/IEC 7816-3.
2. Nicht "T=1", also "T=CL": kontaktlose Übertragung mit einem Protokoll aus der ISO/IEC 14443 Serie.
2. Für das CV-Zertifikat, welches dem PoPP-Service übermittelt wird, sind zwei Werte möglich:
1. "CVC bekannt": Das übermittelte CV-Zertifikat (genauer dessen Hashwert) ist in der eGK-Hash-Datenbank bekannt.
2. Nicht "CVC bekannt" also "CVC unbekannt": Das übermittelte CV-Zertifikat (genauer dessen Hashwert) ist in der eGK-Hash-Datenbank nicht bekannt.
3. Für das AUT-Zertifikat, welches dem PoPP-Service übermittelt wird, sind zwei Werte möglich:
1. "AUT bekannt": Das übermittelte AUT-Zertifikat (genauer dessen Hashwert) ist in der eGK-Hash-Datenbank bekannt.
2. Nicht "AUT bekannt" also "AUT unbekannt": Das übermittelte AUT-Zertifikat (genauer dessen Hashwert) ist in der eGK-Hash-Datenbank nicht bekannt.
4. Für das vorgelegte Paar aus CV-Zertifikat und AUT-Zertifikat sind zwei Werte möglich:
1. "match": Die eGK-Hash-Datenbank bestätigt, dass das vorgelegte CV-Zertifikat zum vorgelegten AUT-Zertifikat gehört.
2. Nicht "match" also "mismatch": Die eGK-Hash-Datenbank ist nicht in der Lage zu bestätigen, dass das vorgelegte CV-Zertifikat zum vorgelegten AUT-Zertifikat gehört. Folgende Ursachen sind möglich:
1. Felder 3 und 4: Weder das CV-Zertifikat noch das AUT-Zertifikat sind der eGK-Hashdatenbank bekannt.
2. Felder 7 und 8: Nur das CV-Zertifikat ist der eGK-Hash-Datenbank bekannt.
3. Felder 11 und 12: Sowohl das CV-Zertifikat als auch das AUT-Zertifikat sind der eGK-Hash-Datenbank bekannt, aber sie gehören nicht zusammen.
4. Felder 15 und 16: Nur das AUT-Zertifikat ist der eGK-Hash-Datenbank bekannt.
5. Des Weiteren speichert die eGK-Hash-Datenbank zu jedem Element einen Zustand, der einen der folgenden Werte annimmt:
1. "imported": Das Element wurde mittels "import(. . .)" Methode in die eGK-Hash-Datenbank aufgenommen.
2. "ad hoc": Das Element wurde mittels "check(…)" Methode in die eGK-Hash-Datenbank aufgenommen.
3. "blocked": Der PoPP-Service stellt keine PoPP-Token aus, wenn ein vorgelegtes CV-Zertifikat oder ein vorgelegtes AUT-Zertifikat in einem Element enthalten sind, dessen Zustand "blocked" ist.

Aus der obigen Liste folgt, dass fünf Variablen zu berücksichtigen sind und die fünfte (Zustand des Elementes) keine boolesche Variable ist. Leider sind Karnaugh-Veitch-Diagramme mit mehr als vier Variablen unübersichtlich und Karnaugh-Veitsch-Diagramme berücksichtigen lediglich boolesche Variablen. Zwecks Komplexitätsreduktion wird das System deshalb wie folgt vereinfacht:

1. Für alle Felder "CVC unbekannt" und "AUT unbekannt" liegt kein Element vor. Deshalb liegt auch kein Zustand vor. Daraus folgt, dass der Zustand "blocked" für solche Felder keine Rolle spielt.
2. Für alle übrigen Felder in denen der Zustand des Elementes "blocked" ist generiert der PoPP-Service eine Fehlermeldung.
3. Fazit: Der Zustand "blocked" eines Elementes ist für die weitere Betrachtung im Karnaugh-Veitch-Diagramm irrelevant. Deshalb sind hier lediglich binäre (boolesche) Variablen relevant. Zudem ist der Zustand des Elements nur für wenige Felder relevant, die dann waagerecht unterteilt werden.

Abbildung 16: Karnaugh-Veitch Diagramm zur "check"-Funktion

Einträge in der eGK-Hash-Datenbank werden wie folgt dargestellt:

1. cvcX bezeichnet den Hashwert eines bestimmten CV-Zertifikates "X".
2. autY bezeichnet den Hashwert eines bestimmten AUT-Zertifikates "Y".
3. {cvcX, autY, imported} bezeichnet einen Eintrag in der eGK-Hash-Datenbank, der durch den Import gemäß [A_27623*] entstand.
4. {cvcX, autY, adHoc} bezeichnet einen Eintrag in der eGK-Hash-Datenbank, der durch "trust on first (contact based) use" gemäß [A_27622*] entstand.
5. {cvcX, autY, blocked} bezeichnet einen Eintrag in der eGK-Hash-Datenbank, der nicht zur Erzeugung eines PoPP-Token nutzbar ist.

Für das zugehörige Karnaugh-Veitch-Diagramm gilt:

1. Felder 1, 2, 5, 6, 13, 14: Es gibt sechs mit "x" gekennzeichnete "don’t care" Felder, weil es unmöglich ist, dass "match" zutrifft, wenn "CVC unbekannt" oder "AUT unbekannt" ist.
2. Feld 3: Bei kontaktbehafteter Kommunikation ist "CVC unbekannt" und "AUT unbekannt". Gemäß "trust on first (contact based) use" wird hier "ad hoc" ein neuer Eintrag zur eGK-Hash-Datenbank hinzugefügt: {cvcX, autY, adHoc}.
3. Feld 4: Bei kontaktloser Kommunikation ist "CVC unbekannt" und "AUT unbekannt". Der PoPP-Service ist nicht in der Lage sicher zu entscheiden, ob CV-Zertifikat und AUT-Zertifikat zusammengehören. Statt eines PoPP-Token wird eine Fehlermeldung generiert.
4. Feld 7i: Bei kontaktbehafteter Kommunikation und "CVC bekannt" liegt ein "mismatch" mit "AUT unbekannt" vor und der Eintrag stammt aus einem Import. Aus "mismatch" folgt, dass der private Schlüssel zum CV-Zertifikat nicht wie vorgesehen verwendet wird. Da der Eintrag zum CV-Zertifikat "importiert" wurde ist sicher auszuschließen, dass in der Vergangenheit missbräuchlich PoPP-Token ausgestellt wurden. Wegen dieses Sicherheitsvorfalls wird sowohl das CV-Zertifikat, als auch die AUT-Zertifikate blockiert:
1. Vorgelegt werde das Paar (cvcX, autY).
2. Zustand vorher:
1. {cvcX, autX, imported}
2. "kein Eintrag für autY"
3. Zustand nachher:
1. {cvcX, autX, blocked}
2. {cvcX, autY, blocked}
5. Feld 7a: Bei kontaktbehafteter Kommunikation und "CVC bekannt" liegt ein "mismatch" mit "AUT unbekannt" vor und der Datenbankeintrag stammt aus einem "ad hoc" Vorgang. Vorgelegt werde das Paar (cvcX, autY). Der Datenbankeintrag laute vorher: {cvcX, autZ, adHoc}. Der PoPP-Service ist in diesem Fall nicht in der Lage zu entscheiden, ob cvcX zu autY oder zu autZ oder zu einem anderen AUT-Zertifikat gehört. Es ist möglich, dass in der Vergangenheit missbräuchlich PoPP-Token ausgestellt wurden. Es ist sicher, dass der private Schlüssel zum CV-Zertifikat nicht wie vorgesehen verwendet wird. Wegen dieses Sicherheitsvorfalls werden das CV-Zertifikat und die AUT-Zertifikate blockiert.
1. Vorgelegt werde das Paar (cvcX, autY).
2. Zustand vorher:
1. "kein Eintrag zu autY"
2. {cvcX, autZ, adHoc}
3. Zustand hinterher:
1. {cvcX, autY, blocked}
2. {cvcX, autZ, blocked}
6. Felder 8, 12, 16: Bei kontaktloser Kommunikation gibt es ein "mismatch". Neben dem unter Feld 7 beschriebenen Vorfall ist es hier auch möglich, dass ein Angreifer zwei verschiedene eGK dem PoPP-Service präsentiert: Eine eGK für Authentisierung mit CV-Zertifikat und eine andere aus der das AUT-Zertifikat ausgelesen wird. Statt eines PoPP-Token wird eine Fehlermeldung generiert. Der Inhalt der eGK-Hash-Datenbank wird nicht verändert.
7. Felder 9, 10: Bei "CVC bekannt" und "AUT bekannt" liegt ein "match" vor. Das ist der Gutfall, der zur Ausstellung eines PoPP-Token führt (egal ob der Zustand des CV-Zertifikates "imported" oder "ad Hoc" ist).
8. Feld 11i: Bei kontaktbehafteter Kommunikation und "CVC bekannt" liegt ein "mismatch" mit "AUT bekannt" vor und der Eintrag stammt aus einem Import. Aus "mismatch" folgt, dass der private Schlüssel zum CV-Zertifikat nicht wie vorgesehen verwendet wird. Da der Eintrag zum CV-Zertifikat "importiert" wurde, ist sicher auszuschließen, dass in der Vergangenheit missbräuchlich PoPP-Token ausgestellt wurden. Wegen dieses Sicherheitsvorfalls werden sowohl die CV-Zertifikate als auch die AUT-Zertifikate blockiert:
1. Vorgelegt werde das Paar (cvcX, autY).
2. Zustand vorher:
1. {cvcX, autX, imported}
2. {cvcY, autY, *=egal}
3. Zustand nachher:
1. {cvcX, autX, blocked}
2. {cvcY, autY, blocked}
9. Feld 11a: Bei kontaktbehafteter Kommunikation und "CVC bekannt" liegt ein "mismatch" mit „AUT bekannt“ vor und der Datenbankeintrag stammt aus einem "ad hoc" Vorgang. Vorgelegt werde das Paar (cvcX, autY). Der Datenbankeintrag laute vorher: {cvcX, autZ, adHoc}. Der PoPP-Service ist in diesem Fall nicht in der Lage zu entscheiden, ob cvcX zu autY oder zu autZ oder zu einem anderen AUT-Zertifikat gehört. Es ist möglich, dass in der Vergangenheit missbräuchlich PoPP-Token ausgestellt wurden. Es ist sicher, dass der private Schlüssel zum CV-Zertifikat nicht wie vorgesehen verwendet wird. Wegen dieses Sicherheitsvorfalls werden sowohl die CV-Zertifikate als auch die AUT-Zertifikate blockiert:
1. Vorgelegt werde das Paar (cvcX, autY).
2. Zustand vorher:
1. {cvcX, autZ, adHoc}
2. {cvcY, autY, *=egal}
3. Zustand hinterher:
1. {cvcX, autZ, blocked}
2. {cvcY, autY, blocked}
   
10. Feld 15i: Bei kontaktbehafteter Kommunikation und "CVC unbekannt" gibt es ein "mismatch" und der Datenbankeintrag zum vorgelegten AUT-Zertifikat wurde importiert. Da der Eintrag zum AUT-Zertifikat "importiert" wurde ist sicher auszuschließen, dass in der Vergangenheit missbräuchlich PoPP-Token ausgestellt wurden. Wegen dieses Sicherheitsvorfalls wird sowohl das vorgelegte CV-Zertifikat als auch das vorgelegte AUT-Zertifikat blockiert:
1. Vorgelegt werde das Paar (cvcX, autY).
2. Zustand vorher:
1. "kein Eintrag zu cvcX"
2. {cvcY, autY, imported}
3. Zustand nachher:
1. {cvcX, autY, blocked}
2. {cvcY, autY, blocked}
11. Feld 15a: Bei kontaktbehafteter Kommunikation und "CVC unbekannt" gibt es ein "mismatch" und der Datenbankeintrag zum vorgelegten AUT-Zertifikat stammt aus einem "ad hoc" Vorgang. Vorgelegt werde das Paar (cvcX, autY). Der Datenbankeintrag laute vorher: {cvcZ, autY, adHoc}. Der PoPP-Service ist in diesem Fall nicht in der Lage zu entscheiden, ob autY zu cvcX oder cvcZ oder zu einem anderen CV-Zertifikat gehört. Es ist möglich, dass in der Vergangenheit missbräuchlich PoPP-Token ausgestellt wurden. Es ist sicher, dass der private Schlüssel zu wenigstens einem der beteiligten CV-Zertifikate nicht wie vorgesehen verwendet wird. Wegen dieses Sicherheitsvorfalls werden beide Einträge blockiert.
1. Vorgelegt werde das Paar (cvcX, autY).
2. Zustand vorher:
1. "kein Eintrag für cvcX".
2. {cvcZ, autY, adHoc}.
3. Zustand hinterher:
1. {cvcX, autY, blocked}
2. {cvcZ, autY, blocked}

6.2.1.9.3 Definition von Begriffen zur Wahrscheinlichkeit

Hier werden einige Begriffe zu Wahrscheinlichkeiten definiert, die in Folgekapiteln verwendet werden. Die Begriffe sind nach Wahrscheinlichkeiten von "sicher" bis "unmöglich" sortiert.

1. sicher: Ein Ereignis tritt mit einer Wahrscheinlichkeit von eins ein.
   Beispiel: Eine Urne enthält nur rote Kugeln. Die Wahrscheinlichkeit aus dieser Urne eine rote Kugel zu ziehen ist eins.
2. extrem wahrscheinlich: Die Eintrittswahrscheinlichkeit ist fast eins. Theoretisch ist es möglich, dass das Ereignis nicht eintritt, aber in der Praxis muss der Nichteintritt nicht betrachtet werden.
   Beispiel: Zwei Zufallszahlen der Länge 128 bit, die unabhängig voneinander generiert werden, sind verschieden.
3. sehr wahrscheinlich: Die Eintrittswahrscheinlichkeit ist so hoch, dass in der Praxis das Gegenereignis nicht beobachtet wird.
   Beispiel: Zu einer Nachricht M wird der SHA-256 Hashwert zweimal berechnet. Beide Ergebnisse stimmen überein.
   Hinweis: In [https://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf] werden RAM-Lesefehler untersucht. Bei Verwendung von ECC-RAM ist es sehr wahrscheinlich, dass RAM-Lesefehler entdeckt werden. Deshalb ist es sehr wahrscheinlich, dass eine zweimalige Hashwertberechnung dasselbe Ergebnis liefert.
4. wahrscheinlich: Die Eintrittswahrscheinlichkeit ist so hoch, dass das Ereignis regelmäßig beobachtet wird.
5. unwahrscheinlich: Die Eintrittswahrscheinlichkeit ist so niedrig, dass das Ereignis nur selten beobachtet wird. Obwohl das Ereignis selten eintritt, müssen Systeme mit so einem Ereignis kontrolliert umgehen können, was durch Tests zu bestätigen ist.
   Beispiel: Bitfehler im RAM eines Servers, beispielhafte Gegenmaßnahme ECC-RAM.
6. sehr unwahrscheinlich: Die Eintrittswahrscheinlichkeit ist so niedrig, dass ein System gegen so ein Ereignis nicht gehärtet werden muss.
   Beispiel: Zu einer Nachricht M wird der SHA-256 Hashwert zweimal berechnet. Beide Ergebnisse sind verschieden.
   
7. extrem unwahrscheinlich: Die Eintrittswahrscheinlichkeit ist fast null. Theoretisch ist es möglich, dass das Ereignis eintritt, aber in der Praxis muss der Eintritt nicht betrachtet werden.
   Beispiel: Zwei Zufallszahlen der Länge 128 bit, die unabhängig voneinander gewürfelt werden, sind gleich.
8. unmöglich: Ein Ereignis tritt mit einer Wahrscheinlichkeit von null ein.
   Beispiel: Eine Urne enthält nur rote Kugeln. Die Wahrscheinlichkeit aus dieser Urne eine grüne Kugel zu ziehen ist null.

6.2.1.9.4 Use Cases zur Befüllung durch Kostenträger

Dieses Kapitel betrachtet die Befüllung der eGK-Hash-Datenbank durch Lieferanten.

Annahmen:

1. Es ist "extrem unwahrscheinlich", das zwei verschiedene Zertifikate denselben Hashwert haben. Deshalb werden derartige Fälle hier nicht weiter betrachtet.
2. Es ist "unwahrscheinlich" (aber denkbar), dass eGKs erst im Feld eingesetzt werden und für diese ein Eintrag in die eGK-Hash-Datenbank erfolgt (per "trust on first (contact based) use") und zu einem späteren Zeitpunkt liefert ein Lieferant für dieselbe eGK per Import einen Eintrag für die eGK-Hash-Datenbank. Daraus folgt, dass es zwar "unwahrscheinlich" aber möglich ist, dass zum Zeitpunkt des Imports bereits ein Eintrag in der eGK-Hash-Datenbank vorliegt. Dieses Kapitel betrachtet dann die dabei auftretenden Fälle und wie mit ihnen umzugehen ist.

Hinweis: Falls die Wahrscheinlichkeit des Ereignisses "eine eGK wird im Feld benutzt bevor ein Import ihrer Daten in die eGK-Hash-Datenbank" von "unwahrscheinlich" auf "sehr unwahrscheinlich" oder niedriger eingestuft wird, dann wird dieses Kapitel gegenstandslos. Derzeit ist die Annahme, dass dieses Ereignis lediglich "unwahrscheinlich" ist. Daraus folgt, dass dieses Kapitel relevant ist.

Ein neuer Eintrag {cvcX, autX, imported} wird der eGK-Hash-Datenbank neu hinzugefügt oder entfernt (remove).

1. Für das CV-Zertifikat, welches im Eintrag enthalten ist, sind zwei Werte möglich:
1. "CVC bekannt": Das CV-Zertifikat (genauer dessen Hashwert) ist in der eGK-Hash-Datenbank bekannt.
2. Nicht "CVC bekannt" also "CVC unbekannt": Das CV-Zertifikat (genauer dessen Hashwert) ist in der eGK-Hash-Datenbank nicht bekannt.
2. Für das AUT-Zertifikat, welches im Eintrag enthalten ist, sind zwei Werte möglich:
1. "AUT bekannt": Das AUT-Zertifikat (genauer dessen Hashwert) ist in der eGK-Hash-Datenbank bekannt.
2. Nicht "AUT bekannt" also "AUT unbekannt": Das AUT-Zertifikat (genauer dessen Hashwert) ist in der eGK-Hash-Datenbank nicht bekannt.
3. Für Einträge, die das CV-Zertifikat oder das AUT-Zertifikat (oder beide) enthalten, sind zwei Werte relevant:
1. Wenigstens einer dieser Einträge ist im Zustand "blocked".
2. Keiner dieser Einträge ist "blocked" (also "unblocked").
4. Für den Vergleich zwischen dem Eintrag und einem bestehenden Eintrag in der eGK-Hash-Datenbank sind zwei Werte denkbar:
1. "match": Die Hashwerte im Eintrag sind identisch zu den Hashwerten in einem bestehenden Eintrag.
2. Nicht "match" (also "mismatch"): Die Hashwerte des Eintrags sind nicht identisch zu irgendeinem bestehenden Eintrag.

Aus der obigen Liste folgt, dass vier binäre (boolesche) Variablen zu berücksichtigen sind. Für das zugehörige Karnaugh-Veitch Diagramm gilt:

Abbildung 17: Karnaugh-Veitch Diagramm zur "import"-Methode

1. Felder 1, 4: Der Fall, dass "CVC unbekannt" und "AUT unbekannt" aber "blocked" ist, kann nicht vorkommen. Deshalb sind diese Felder irrelevant (don’t care).
2. Felder 1, 2, 5, 6, 13, 14: Der Fall, dass ein "match" vorliegt, wenn cvcX oder autX "unbekannt" sind, kann nicht vorkommen. Deshalb sind diese Felder irrelevant (don’t care).
3. Feld 3: Weder cvcX, noch autX sind in der eGK-Hash-Datenbank enthalten.
1. "import": Ein neuer Eintrag wird der eGK-Hash-Datenbank hinzugefügt.
2. "remove": Der zu entfernende Eintrag ist nicht in der eGK-Hash-Datenbank enthalten. Die eGK-Hash-Datenbank wird nicht verändert.
4. Felder 7, 8: cvcX ist "bekannt" aber autX ist "unbekannt". Daraus folgt, dass der private Schlüssel des CV-Zertifikates nicht wie vorgesehen verwendet wird. In der Vergangenheit wurden missbräuchlich PoPP-Token ausgestellt. Der Eintrag wird gesperrt.
1. Zustand in der eGK-Hash-Datenbank vorher:
1. "kein Eintrag zu autX"
2. {cvcX, autY, *=egal}
2. Zustand nachher:
1. {cvcX, autX, blocked}
2. {cvcX, autY, blocked}
5. Feld 9: cvcX ist "bekannt" aber "blocked" und es liegt ein "match" vor. Die eGK-Hash-Datenbank wird nicht verändert.
6. Feld 10: Sowohl cvcX, als auch autX sind "bekannt" und auch in der eGK-Hash-Datenbank sind cvcX und autX einander zugeordnet ("match") und der Zustand von cvcX in der eGK-Hash-Datenbank ist nicht "blocked".
1. "import": Ein neuer Eintrag wird der eGK-Hash-Datenbank hinzugefügt. Dann lassen sich folgende Fälle unterscheiden: Der Zustand von cvcX in der eGK-Hashdatenbank ist
1. "imported": Keine Aktion erforderlich, da die eGK-Hash-Datenbank den neuen Eintrag bereits enthält.
2. "adHoc": Der Zustand des cvcX in der eGK-Hashdatenbank wird von "adHoc" auf "imported" geändert.
1. Zustand vorher: {cvcX, autX, adHoc}
2. Zustand nachher: {cvcX, autX, imported}
2. "remove": Der Eintrag wird aus der eGK-Hash-Datenbank entfernt.
7. Felder 11, 12: Sowohl cvcX, als auch autX sind "bekannt", aber in der eGK-Hash-Datenbank einander NICHT zugeordnet ("mismatch"). In der Vergangenheit wurden PoPP-Token missbräuchlich ausgestellt. Einträge werden gesperrt.
1. Zustand vorher:
1. {cvcX, autY, *=egal}
2. {cvcZ, autX, *=egal}
2. Zustand nachher:
1. {cvcX, autY, blocked}
2. {cvcZ, autX, blocked}
8. Felder 15, 16: cvcX ist "unbekannt", autX ist "bekannt". Daraus folgt, dass der private Schlüssel des CV-Zertifikates nicht wie vorgesehen verwendet wird. In der Vergangenheit wurden missbräuchlich PoPP-Token ausgestellt. Der vorhandene Eintrag wird gesperrt und ein neuer Eintrag angelegt.
1. Zustand vorher:
1. "kein Eintrag für cvcX"
2. {cvcY, autX, *=egal}
2. Zustand nachher:
1. {cvcX, autX, blocked}
2. {cvcY, autX, blocked}

Hinweis: Die Beschränkung der Anzahl von Einträgen in A_27045*, Punkt 5 auf 20 Millionen sorgt dafür, dass die signierte Nachricht kleiner als 2 GiByte = 2.147.483.647‬ Byte bleibt. Größere Nachrichten lassen sich mit Standardbibliotheken unter gängigen Programmiersprachen (etwa Java) nicht verarbeiten. Falls ein Lieferant mehr Einträge anliefern möchte, dann verwendet er mehrere signierte Nachrichten.

6.2.1.9.5 Weitere Anforderungen an die eGK-Hash-Datenbank

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

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

Hinweis 3: Sowohl CV-Zertifikate, als auch AUT-Zertifikate verwenden aktuell SHA-256 als Hashverfahren. Deshalb ist es aus Sicherheitssicht ausreichend in der eGK-Hash-Datenbank 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 eGK-Hash-Datenbank im Vergleich zu allen möglichen Werten so dünn besetzt. ist, dass es für einen Angreifer praktisch unmöglich ist ein Paar aus gültigem CV-Zertifikat und gültigem AUT-Zertifikat zu finden, welches nicht aus ein und derselben eGK stammt, aber trotzdem von der eGK-Hash-Datenbank eine "ja"-Antwort bekommt.

Hinweis 4: Die Codierung von SignedData wird derzeit mit den Kostenträgern und deren Dienstleistern abgestimmt.

6.2.1.9.6 Anmerkungen zur Implementierung

Die Intention dieses Unterkapitels ist es, Hilfestellungen bei der Implementierung der eGK-Hash-Datenbank zu liefern. Dieses Unterkapitel enthält keine Anforderungen.

Am Anfang dieses Unterkapitels sei zunächst angenommen, dass der PoPP-Service und mit ihm die eGK-Hash-Datenbank in Betrieb seien. Aus Performancegründen erscheint es ratsam die eGK-Hash-Datenbank im RAM zu halten, weil Speicherzugriffe auf (volatile) RAM-Inhalte vielfach schneller ablaufen als solche auf ein persistentes Dateisystem.

Gemäß A_27622* „check(. . .)“-Funktion Punkt 5.c.i (Feld 3) ist es möglich im laufenden Betrieb beispielsweise durch "trust on first (contact based) use" der eGK-Hash-Datenbank neue Einträge hinzuzufügen. Zudem sind in A_27622* weitere Punkte enthalten, bei denen sich der Inhalt der eGK-Hash-Datenbank ändert. Deshalb erscheint es nicht hinreichend zu sein, den Inhalt der eGK-Hash-Datenbank ausschließlich im RAM vorzuhalten, damit er beispielsweise durch einen Stromausfall erhalten bleibt. Daraus folgt, dass es zur eGK-Hash-Datenbank im (volatilen) RAM auch eine persistente Variante der eGK-Hash-Datenbank gibt.

Gemäß A_27622* und A_27623 spielt die Reihenfolge in welche Einträge zur eGK-Hash-Datenbank hinzugefügt werden eine Rolle.

Szenario 1:

1. Die eGK-Hash-Datenbank enthalte einen Eintrag {cvc1, aut1, imported}.
2. Aus irgendeinem Grund werde cvc1 und damit auch aut1 blockiert.
3. Anschließend werde versucht der "check(…)"-Funktion {cvc1, aut2} zu präsentieren. Ohne die eGK-Hash-Datenbank zu ändern scheitert die "check(…)"-Funktion wegen blockiertem cvc1.
4. Anschließend werde {cvc2, aut2, "T=1"} der "check(…)"-Funktion präsentiert, was zu einem neuen Eintrag {cvc2, aut2, adHoc} führt.
5. Endzustand in Szenario 1:
1. {cvc1, aut1, blocked}
2. {cvc2, aut2, adHoc}

Szenario 2:

1. Die eGK-Hash-Datenbank enthalte einen Eintrag {cvc1, aut1, imported}.
2. Anschließend werde {cvc2, aut2, "T=1"} der "check(…)"-Funktion präsentiert, was zu einem neuen Eintrag {cvc2, aut2, adHoc} führt.
3. Anschließend werde versucht der "check(…)"-Funktion {cvc1, aut2, "T=1"} zu präsentieren. Das blockiert cvc1, cvc2, aut1 und aut2.
4. Endzustand in Szenario 2:
1. {cvc1, aut1, blocked}
2. {cvc2, aut2, blocked}

Beispielhaftes Konzept für eine Implementierung der eGK-Hash-Datenbank:

1.  Nach erfolgreicher Signaturprüfung speichert die "import(…)"-Methode die "SEQUENCE OF" egkInfos zunächst zusammen mit einem Zeitstempel persistent.
2. Falls im Rahmen der "check(…)"-Funktion ein neuer Eintrag angelegt wird (Feld 3), dann wird ebenfalls mit Zeitstempel eine „SEQUENCE OF“ egkInfos mit den Daten aus dem neuen Eintrag persistent gespeichert, mit status=2=adHoc.
3. Falls im Rahmen der "check(…)"-Funktion oder der "import(…)"-Methode ein oder mehr Einträge blockiert werden, dann werden alle dabei blockierten Einträge in einer „SEQUENCE OF“ egkInfos mit Zeitstempel persistent gespeichert, mit status=3=blocked.

Daraus ergibt sich, dass die eGK-Hash-Datenbank zweimal vorliegt: Volatil im RAM und als durch Zeitstempel geordnete Liste von „SEQUENCE OF“ egkInfos, die persistent gespeichert sind. Der Zustand im RAM lässt sich dabei jederzeit aus den persistenten Informationen eindeutig rekonstruieren, wenn die zeitlich geordneten „SEQUENCE OF“ egkInfos nacheinander verarbeitet werden.

Der Neuaufbau des RAM-Zustandes der eGK-Hash-Datenbank ist möglicherweise (je nach Implementierung) zeitintensiv. Dann bietet es sich an, von der RAM-Version der eGK-Hash-Datenbank einen persistenten Speicherabzug zu erstellen, der sich performanter ins RAM laden lässt.

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 App mit integriertem PoPP-Modul 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 sind Zufallswerte mit hoher Entropie und produkt-spezifisch. Die Zulässigkeit von API-KEYs wird über organisatorische Prozesse des Betreiber des PoPP-Service den Herstellern von Clientsystemen mitgeteilt. Die Übermittlung muss vertraulichkeits- und integritätsgeschützt erfolgen. Der Betreiber des PoPP-Service muss bei der Übergabe der API-KEYs sicherstellen, dass nur ein berechtigter Client-Hersteller einen für ihn erzeugten API-KEY erhält.

Die gematik kann beim Betreiber des PoPP-Service die Sperrung eines API-KEYs veranlassen.

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 Versorgungskontexts in Form eines PoPP-Token.

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

Abbildung 19: 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-Management

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 eine oder mehrere "lange" TAN generiert.

Hinweis 1: Der Defaultwert für die Anzahl maxTAN beträgt drei. Es können somit per Default zur gleichen Zeit maximal drei kurze und drei lange TAN für einen Versicherten vorliegen.

Hinweis 2: Das JWT für die Rückgabe der TAN an das aufrufende PoPP-Modul ist in [I_PoPP_CheckIn_ResourceServer.yaml] spezifiziert.

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

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

Hinweis: Der Defaultwert für maxTime 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.

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 erfolgt in [gemILF_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.

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 20: Im Dokument verwendete Abkürzungen

9.2 Glossar

Tabelle 21: 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 22: Referenzierte Dokumente der gematik

9.5.2 Weitere Dokumente

Tabelle 23: Weitere Dokumente

9.6 Allgemeine Erläuterungen

9.6.1 Entity Statement des PoPP-Service

Tabelle 24: Entity Statement des PoPP-Service

9.7 Offene Punkte / Klärungsbedarf

- derzeit keine -