latest

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

Schlüsselgenerierungsdienst

ePA

    

     

      
Version
      
1.6.0
     
     

      
Revision
      
873447
     
     

      
Stand
      
31.03.2023
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_SGD_ePA
     
    

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Die vorliegende Spezifikation definiert Anforderungen an den Produkttyp "Schlüsselgenerierungsdienst ePA" (SGD) und beschreibt die Funktionsweise der Schlüsselgenerierung, die die Basis für die Ver- und Entschlüsselung von Akten- und Kontextschlüssel innerhalb eines Clients (ePA-FdV etc.) ist. 

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter des Produkts "Schlüsselgenerierungsdienst ePA" und des Produktes "ePA-Aktensystem". Weiterhin unterstützt das Dokument Hersteller von "ePA-Frontends des Versicherten" und Hersteller eines "Fachmodul ePA" bei der Entwicklung, da diese Produkte mit mehreren SGD kommunizieren müssen.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungsverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Wichtiger Schutzrechts-/Patentrechtshinweis

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

1.4 Abgrenzungen

Es ist keine Abgrenzung gegenüber anderen Spezifikationen/Konzepten oder im Kontext derzeit nicht relevanten Themen erforderlich.

1.5 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

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

2 Überblick

Ein Schlüsselgenerierungsdienst (SGD) generiert AES-256-Bit-Schlüssel für eine Entität, die sich mittels

• einer eGK,
• einer alternativen Versichertenidentität,
• einer SMC-B, oder
• einer SMC-KTR 

gegenüber dem SGD authentisiert hat. Diese Generierung erfolgt über eine Schlüsselableitung auf Grundlage von geheimen SGD-spezifischen Ableitungsschlüsseln (Masterkeys) und Ableitungsvektoren. Diese Ableitungsvektoren enthalten konstante Merkmale, entweder die KVNR oder die Telematik-ID. Jeweils fließt notwendigerweise solch ein konstantes Merkmal aus der erfolgreichen Authentisierung und dem dabei verwendeten EE-Client-Zertifikat mit in die Ableitung ein. Damit werden nur für Berechtigte (erfolgreich Authentifizierte) diese Schlüssel abgeleitet und die jeweils generierten Schlüssel sind spezifisch – unterschiedliche Ableitungsvektoren erzeugen jeweils unterschiedliche abgeleitete Schlüssel.

Die Sicherung der medizinischen Daten bei der elektronischen Patientenakte [gemSysL_ePA] ist ein Zusammenspiel aus Zugriffskontrolle und Schlüsselmanagement (Verschlüsselung). Aus diesem Hybridmodell folgt: Auch wenn ein Client über mehrere SGD Schlüssel ableiten lassen kann, heißt dies noch nicht, dass für diese Schlüssel überhaupt ein passendes Chiffrat existiert oder dass ein Client auf solch ein Chiffrat Zugriff besitzt.

Die Schlüsselableitung wird in einem SGD innerhalb eines HSM mit einem SGD-spezifischen Firmware-Modul durchgeführt (SGD-HSM genannt). Durch technische Maßnahmen wird ausgeschlossen, dass ein Betreiber eines SGD die Schlüsselableitung selbst durchführen kann oder Zugriff auf die unverschlüsselten versichertenindividuellen Schlüssel erhalten kann. Nur das SGD-HSM kann die geheimen Ableitungsschlüssel verwenden. Es prüft dabei zuvor die erfolgreiche Authentisierung des Anfragenden und verwendet u. a. die darin authentisierten Angaben als Ableitungsvektoren. Es gibt aus der Perspektive eines Client (des ePA-Frontend des Versicherten (ePA-FdV), eines Konnektor-Fachmodul ePA (FM ePA) etc.) immer genau zwei SGD, die ein Client aufgrund der verwendeten SGD-HSM-Zertifikate sicher unterscheiden kann. Der Client fordert eine Schlüsselgenerierung jeweils bei den beiden SGD an und erhält damit zwei unabhängige AES-256-Schlüssel. Nach erfolgreicher Authentifizierung und Autorisierung durch das Aktensystem verwendet der Client diese zwei Schlüssel, um das vom ePA-Aktensystem erhaltene Chiffrat im "Zwiebelschalenprinzip" zu entschlüsseln. So erhält der Client den Akten- und den Kontextschlüssel im Klartext. Diese beiden Schlüssel sind dabei bezüglich der Ver- und Entschlüsselung durch eine gemeinsame Datenstruktur (vgl. Abschnitt 8 Interoperables Austauschformat) fest miteinander verbunden. Die zwei SGD sind technisch, organisatorisch und wirtschaftlich unabhängig voneinander (vgl. Abschnitt 3.1 Beziehung zwischen ePA-Aktensystem und SGD  ). Ein SGD kommt niemals mit dem Akten- und Kontextschlüssel eines Versicherten in Berührung.

Verliert der Versicherte seine eGK oder sein mobiles Endgerät mit seiner alternativen Versichertenidentität, kann er sich mit seiner neuen Identität (Folge-eGK oder einer anderen alternativen Versichertenidentität) am ePA-Aktensystem authentisieren. Da die Merkmale für die Schlüsselableitung in der Folgeidentität gleich sind (gleichbleibende KVNR)  und kodiert ist, welcher Ableitungsschlüssel verwendet worden ist, kann ein Client mittels beider SGD die gleichen Schlüssel erhalten und die Entschlüsselung der Akten- und Kontextschlüssel wieder vornehmen. Der Verlust einer eGK eines Versicherten führt also nicht zum Verlust der Akte des Versicherten.

Analog ist in einer Folge-SMC-B die Telematik-ID konstant. Somit kann eine Leistungserbringerinstitution (LEI) bereits vergebene Berechtigungen und vorher von einem Versicherten für die LEI erzeugte Chiffrate weiterhin nutzen.

2.1 Grundlage und Kernidee

Notwendige Grundlage der Idee der Schlüsselableitung mittels der SGD ist, dass bei einem Kartenwechsel der eGK oder einem Wechsel der alternativen Versichertenidentität die KVNR eines Versicherten in den Zertifikaten der Folgekarte bzw. bei der Folgeidentität korrekt und konstant bleibt. Die Korrektheit der Kartenherausgabeprozesse ist – wie bei nahezu allen digitalen Prozessen in der TI – notwendige Voraussetzung. Analog bleibt bei einem Kartenwechsel einer SMC-B oder einer SMC-KTR die Telematik-ID konstant.

Es muss sichergestellt sein, dass nur erfolgreich authentifizierte Clients eine Schlüsselableitung durchführen können und dabei notwendigerweise die die Clients identifizierenden (konstanten) Merkmale in die Schlüsselableitung als Ableitungsvektor mit einfließen. Die Authentifizierung durch die SGD-HSMs der beiden SGD erfolgt unabhängig vom Aktensystem.

Ziele für die Schlüsselableitung:

1. Die Akten- und Kontextschlüssel dürfen sich unverschlüsselt nur in Clients (ePA-FdV, FM ePA etc.) befinden (bzw. der Kontextschlüssel ebenfalls in der VAU). Dort liegen die Schlüssel nur temporär während der Verwendung der Akte vor und werden dort anschließend sicher gelöscht.
2. Die Akten- und Kontextschlüssel dürfen nur durch das Zusammenwirken mehrerer unabhängiger Teilnehmer entschlüsselbar sein.
3. Alle Ver- und Entschlüsselungen dürfen nur authentisierte Daten verwenden.
4. Die Akten- und Kontextschlüssel müssen mit versichertenindividuellen Schlüsseln geschützt sein (Schlüsseldiversifizierung).
5. Da ausreichend geprüfte symmetrische Verschlüsselungsverfahren (bspw. Finalisten des öffentlichen Auswahlverfahrens für AES) in ihrer Sicherheitseignung deutlich stabiler über längere Zeiträume sind als asymmetrische Verschlüsselungsverfahren (Eignung der Schlüssellängen, vgl. notwendige Anpassung der Schlüssellängen bspw. bei RSA), soll die Lösung möglichst viel auf symmetrischen Verfahren beruhen.
6. Die Verwendung von symmetrischen Verschlüsselungsverfahren ermöglicht eine eventuell zukünftig notwendige Reaktion auf das Thema Quantencomputer-Resistenz.

Wenn die KVNR bzw. die Telematik-ID in einer Folgekarte oder Folgeidentität immer konstant ist, so kann diese (1) als eindeutiges Identifikationsmerkmal bspw. innerhalb einer Authentifizierung und Autorisierung verwendet werden und (2) als Basis für eine eindeutige Schlüsselableitung. Die Schlüsselableitung berechnet aus einem geheimen Ableitungsschlüssel (Mastersecret) und einer KVNR plus anderen Angaben (vgl. Abschnitte 2.4 Initiale Schlüsselableitung für den Kontoinhaber ff) deterministisch einen spezifischen AES-256-Schlüssel. Diese Schlüsselableitung wird in einem HSM mit einem speziellen Firmware-Modul durchgeführt, das verhindert, dass der Betreiber des HSMs (vgl. Abschnitt 4 Bestandteile eines SGD ) in den Ableitungsprozess Einblick erhält – er kennt den geheimen Ableitungsschlüssel nicht, und er kann die Authentifizierungs- und Autorisierungsfunktion im HSM nicht beeinflussen. Ein solcher abgeleiteter versicherten- und zugriffsregelindividueller AES-256-Schlüssel wird dem Client über einen beidseitig authentisierten Ende-zu-Ende-verschlüsselten Kanal zwischen SGD-HSM und dem Client zur Verfügung gestellt. Ein Versicherter verwendet solche abgeleiteten versichertenindividuellen AES-256-Schlüssel aus mehreren voneinander unabhängigen SGD. Ein Client (ein ePA-FdV, ein FM ePA etc.) kann die verschiedenen SGD voneinander unterscheiden. Die Erzeugung der abgeleiteten versichertenindividuellen AES-256-Schlüssel kann auf beliebig viele unabhängige SGD verteilt werden. Das Verfahren skaliert linear – es ist technisch leicht möglich, mehrere SGD zu verwenden.

Die Schlüsselableitungsfunktionalität ePA basiert aktuell auf genau zwei SGD pro Aktensystem (vgl. Abschnitt 2.2 Akteure und Komponenten und Abschnitt 3.1 Beziehung zwischen ePA-Aktensystem und SGD) gemäß [gemKPT_Arch_TIP#4.7 Langfristige Verschlüsselung] . Im Folgenden wird derjenige SGD, den ein Anbieter eines Fachanwendungsspezifischen Dienstes (FAD) bereitstellen muss, als "SGD 1" bzw. "SGD FAD" bezeichnet. Derjenige SGD, der von einem von SGD 1 unabhängigen Dritten in der TI-Plattform (TIP) betrieben wird, wird im Folgenden als "SGD 2" bzw. "SGD TIP" bezeichnet. Mittels der beiden erhaltenen AES-256-Schlüssel verschlüsselt ein Client den Akten- und Kontextschlüssel (vgl. Abschnitt " ") im "Zwiebelschalenprinzip". Das entstandene Chiffrat wird dem ePA-Aktensystem zur Einlagerung übergeben. 

Nach einer erfolgreichen Anmeldung am Aktensystem kann ein Versicherter Folgendes tun:

1. Der Versicherte authentisiert sich jeweils bei den verschiedenen, unabhängigen Schlüsselableitungsdiensten (beidseitig authentisierter verschlüsselter Datenkanal zwischen SGD-HSM und Client, vgl. Abschnitt 9 Datenkanal zwischen Client und SGD (informativ) ).
2. Der Versicherte erhält aufgrund der Konstanz der KVNR  und des im Ableitungsvektor benannten geheimen Ableitungsschlüssel jeweils den gleichen abgeleiteten versichertenindividuellen AES-256-Schlüssel wie zuvor.
3. Der Versicherte kann anschließend im Zwiebelschalenprinzip den Akten- und den Kontextschlüssel entschlüsseln.

Abbildung 1: Überblick Zwiebelschalenprinzip bei der Ver- und Entschlüsselung

Ein wichtiger Aspekt: Das   kryptographische Verfahren für die Generierung der spezifischen Schlüssel in den Schlüsselgenerierungsdiensten ist unabhängig von dem aktuell verwendeten Authentisierungsverfahren. Wenn bei der Authentisierung also zukünftig eine elliptische Kurve  mit 512-Bit anstatt aktuell einer elliptischen Kurve mit 256-Bit verwendet werden soll (oder ein Quanten-Computing-resistentes Signatur-Verfahren), so ist dies ist für das grundsätzliche Verfahren nicht entscheidend. Die Schlüsselableitungsfunktionalität ist diesbezüglich unabhängig.

Der geheime Ableitungsschlüssel eines Schlüsselgenerierungsdienstes (SGD) wird regelmäßig neu erzeugt, so dass auch dort eine Schlüsseldiversifizierung vorhanden ist. Alte Ableitungsschlüssel müssen in den SGD weiter vorgehalten werden, solange sie potentiell benötigt werden. In einem späteren Release wird die (regelmäßige) Umschlüsselung einer ePA-Akte spezifikatorisch bearbeitet. Bei den SGD gibt es dafür jetzt schon vorbereitende Maßnahmen (vgl. Abschnitt 2.4 Initiale Schlüsselableitung für den Kontoinhaber, RND-Zufallswert). Bei einem Schlüsselwechsel bei der jeweiligen Akte (Umschlüsselung) muss auch eine neue Einlagerung (Schlüsselableitungsfunktionalität) vorgenommen werden (im Normalfall mittels eines neuen Ableitungsschlüssels). Das sichere Löschen von nicht mehr benötigten Ableitungsschlüsseln (Masterkeys) wird dann in diesem späteren Release ebenfalls spezifikatorisch bearbeitet. Die Ableitungsschlüssel besitzen eindeutige Bezeichner (A_17920-02 ) und sind unterscheidbar.

2.2 Akteure und Komponenten

Die beteiligten Akteure sind:

Tabelle 1: beteiligte Akteure im Kontext Schlüsselableitungsfunktionalität

Die beteiligten Komponenten und Dienste sind:

Tabelle 2: beteiligte Komponenten und Dienste im Kontext Schlüsselableitungsfunktionalität

Die folgende Grafik gibt einen Überblick über die beteiligten Komponenten und Dienste.

Abbildung 2: beteiligte Komponenten und Dienste im Kontext der Schlüsselableitungsfunktionalität ePA

Ein SGD 1 und ein SGD 2 sind fachlich gesehen baugleich – bis auf die eingesetzten geheimen und privaten Schlüssel (A17910-01   (S1), (S3), (S4) und (S5)) und ihre Identität ( ) unterscheiden sie sich nicht. Insbesondere benötigt ein SGD keine Informationen aus dem ePA-Aktensystem.

2.3 Basisablauf Kommunikation SGD-Client und SGD

Ein Client aus dem Internet (also ein ePA-FdV) erreicht einen SGD über das ZGdV des ePA-Aktensystems (vgl. ). Solch ein Client verwendet die auch für die Kommunikation mit dem Aktensystem verwendete HTTPS-Schnittstelle des ZGdV. Das ZGdV leitet HTTP-Requests mit dem Pfadname /SGD1 an die HTTPS-Schnittstelle des SGD 1 weiter (eigenständige TLS-Verbindung zwischen ZGdV und SGD). Analog tut das ZGdV dies für Requests mit dem Pfadnamen /SGD2 in Bezug auf den SGD 2. Auf Applikationsebene gibt es eine Ende-zu-Ende-Verschlüsselung zwischen den Clients und den SGD-HSMs der SGDs (vgl. Abschnitt 9 Datenkanal zwischen Client und SGD (informativ) ).

Ein Client aus der TI (FM ePA etc.) spricht die beiden SGD über deren HTTPS-Schnittstellen () direkt an. Die IP-Adressen erfahren solche Clients über DNS-Service-Discovery. 

Der grundsätzliche Ablauf einer Anfrage (vgl. Abschnitt 2.4 Initiale Schlüsselableitung für den Kontoinhaber ff) ist in Bezug auf das Kommunikationsmuster bezüglich der beiden SGD immer gleich und wird im Folgenden beschrieben. Zur Vereinfachung der Darstellung ist der Ablauf sequenziell dargestellt. Für eine Performanzsteigerung muss ein Client die Anfragen an die beiden SGD parallelisieren ( ), was bis auf Schritt 6 leicht möglich ist. Eine noch detaillierte Erläuterung zu den kryptographischen Grundlagen der Kommunikation befindet sich in Abschnitt "9 Datenkanal zwischen Client und SGD (informativ)".

Schritt 1:

Der Client verwendet die HTTPS-Schnittstelle des ZGdV, oder falls er aus Netzwerksicht Teil der TI ist (FM ePA etc.) die HTTPS-Schnittstelle eines SGD direkt, um den aktuellen öffentlichen ECIES-Schlüssel des SGD 1 zu erhalten (Pfadname der URL ist "/SGD1") (vgl. Schnittstelle " "). Das ZGdV leitet den HTTP-Request (HTTPS) an den SGD 1 weiter.

Schritt 2:

Der SGD 1 antwortet mit dem aktuellen authentisierten öffentlichen ECIES-Schlüssel des für den Nutzer (AUT-Zertifikat) avisierten SGD-HSM innerhalb des SGD 1 (vgl. A_17894-01 ). Dieser Schlüssel ändert sich alle 15 Minuten und ist dann jeweils für 30 Minuten für alle anfragenden Clients verwendbar. Der ECIES-Schlüssel des SGD-HSM ist durch das SGD-HSM signiert (A_17910-01   (S1)).

Schritt 3:

Der Client prüft das Zertifikat, die Signatur und den ECIES-Schlüssel des SGD-HSM von SGD 1 (). Er prüft dabei u. a., dass die Antwort von einem SGD-1-SGD-HSM kam.

Schritt 4:

Der Client erfragt analog zu Schritt 1 den aktuellen authentisierten öffentlichen ECIES-Schlüssel von SGD 2 (Pfadname der URL ist "/SGD2").

Schritt 5:

Der SGD 2 antwortet analog zu Schritt 2 mit dem signierten ECIES-Schlüssel des für den Nutzer vorgesehenen SGD-HSM innerhalb von SGD 2 (vgl. A_17894-01 ).

Schritt 6:

Der Client prüft analog zu Schritt 3 das Zertifikat, die Signatur und den ECIES-Schlüssel des SGD-HSM von SGD 2 (). Er prüft dabei u. a., dass die Antwort von einem SGD-2-SGD-HSM kam.

Schritt 7:

Der Client berechnet die Hashwerte der erhaltenen ECIES-Schlüsselwerte der beiden SGD-HSM aus Schritt 3 und Schritt 6.

Schritt 8:

Der Client erzeugt ein kurzlebiges ECIES-Schlüsselpaar ( [gemSpec_Krypt#]), was der Client später für die Request an SGD 1 und SGD 2 verwenden wird. Der Client führt den öffentlichen Client-ECIES-Schlüssel zusammen mit den Hashwerten aus Schritt 7 in ein Kodierung gemäß  auf und signiert diese Kodierung mittels des AUT-Materials der eGK, der SMC-B, der SMC-KTR oder der alternativen Authentisierung.

Schritt 9:

Der Client verwendet die Operation GetAuthenticationToken bei SGD 1 um ein Authentisierungstoken zu erhalten. Dafür erzeugt der Client einen Zufallswert (Challenge) und sendet diesen verschlüsselt an das für ihn vorgesehene SGD-HSM bei SGD 1.

Schritt 10:

Die RVE innerhalb von SGD 1 prüft das AUT-Zertifikat, die Client-Signatur des Client-ECIES-Schlüssels und den Client-ECIES-Schlüssel. Falls alle Prüfungen ein OK liefern, bereitet die RVE den Request auf (OCSP-Responses, Umkodierung für die Innenschnittstelle zum den SGD-HSM etc.) und übergibt die verschlüsselte Nachricht an das SGD-HSM. Das SGD-HSM prüft ebenfalls das AUT-Zertifikat, die Client-Signatur des Client-ECIES-Schlüssels und den Client-ECIES-Schlüssel und erstellt ein Authentisierungstoken. Das SGD-HSM erstellt eine Nachricht, die die Challenge des Client, einen Hashwert (des Client-Schlüssels und des AUT-Zertifikats) und das erzeugte Authentisierungstoken enthält. Diese Nachricht verschlüsselt das SGD-HSM für den Client-ECIES-Schlüssel und übergibt das Chiffrat an die RVE. Diese kodiert die Nachricht um und antwortet dem Client.

Schritt 11:

Der Client entschlüsselt die Nachricht des SGD-HSM von SGD 1. In der entschlüsselten Nachricht prüft, es ob seine Challenge enthalten ist. Falls ja, kann es davon ausgehen, dass die Antwort wirklich vom SGD-HSM stammt. Es prüft den Hashwert (des Client-Schlüssels und des AUT-Zertifikats) und speichert das Authentisierungstoken für die folgende Verwendung innerhalb der Operation KeyDerivation.

Schritt 12:

Der Client erzeugt zufällig eine Request-ID, anschließend eine Nachricht. Diese enthält das Authentisierungstoken, die Request-ID und die je nach Anwendungsfall (vgl. Abschnitt 2.4 Initiale Schlüsselableitung für den Kontoinhaber ff) unterschiedliche Ableitungsregel. Diese Nachricht verschlüsselt der Client für das SGD-HSM und verwendet die Operation KeyDerivation von SGD 1.

Schritt 13:

Die RVE innerhalb von SGD 1 prüft das AUT-Zertifikat, die Client-Signatur des Client-ECIES-Schlüssels und den Client-ECIES-Schlüssel. (Hinweis: die RVE cacht die Prüfergebnisse ().) Falls alle Prüfungen ein OK liefern, bereitet die RVE den Request auf (OCSP-Responses, Umkodierung für die Innenschnittstelle zum den SGD-HSM etc.) und übergibt die verschlüsselte Nachricht an das SGD-HSM. Das SGD-HSM entschlüsselt die Nachricht des Client und überprüft, ob das Authentisierungstoken konsistent mit dem Client-ECIES-Schlüssel und dem AUT-Zertifikat des Client ist. Falls ja überprüft es die Ableitungsregel und führt, falls der Client berechtigt ist, die Schlüsselableitung durch. Das Ergebnis verschlüsselt inkl. Authentisierungstoken, Request-ID und Ableitungsvektor das SGD-HSM für den Client. Das Chiffrat übergibt das SGD-HSM an die RVE, die es nach Umkodierung an den Client als Response weiterleitet.

Die Schritte 14 bis 20 (siehe folgende Tabelle) sind analog zu den Schritten 9 bis 13, nur findet die Kommunikation zwischen Client und SGD 2 statt.

Tabelle 3: Tab_Übersicht_der_Kommunikationsschritte_eines_SGD-Clients

Der Client verwendet die erhaltenen beiden AES-256-Schlüssel je nach Anwendungsfall entweder für die Ver- oder die Entschlüsselung des Akten- und des Kontextschlüssels unter Verwendung des interoperablen Austauschformats nach Abschnitt 8 Interoperables Austauschformat . Dabei befinden sich die verwendeten Ableitungsvektoren innerhalb der "associated data" (AD), so dass später die ausgeführte Aktion durch einen autorisierten Client reproduzierbar ist.

2.4 Initiale Schlüsselableitung für den Kontoinhaber

Ein Versicherter (Kontoinhaber) eröffnet ein Konto und der verwendete Client (entweder das ePA-FdV oder das FM ePA) erzeugt den Akten- und Kontextschlüssel. Anschließend durchläuft der Client die Schritte 1 bis 20 aus Abschnitt 2.3 Basisablauf Kommunikation SGD-Client und SGD . Als Nachricht (verschlüsselte "EncryptedMessage" in   ) an die beiden SGD sendet der Client dabei jeweils eine Nachricht der Form

AT<256-Bit-Authentisierungstokenwert-in-Hexform> <Request-ID> KeyDerivation r1:<KVNR>

und erhält jeweils eine Antwort der Form

AT<256-Bit-Authentisierungstokenwert-in-Hexform> <Request-ID> OK-KeyDerivation <AES-256-Bit-Schlüssel-in-Hexform> r1:<256-Bit-RND-in-Hexform>:<KVNR>:<aktueller Ableitungsschlüsselbezeichner>

Die beiden nun erhaltenen AES-256-Schlüssel verwendet der Client zur zweifachen Verschlüsselung des von ihm erzeugten Akten- und Kontextschlüssel im "Zwiebelschalenprinzip" unter Verwendung des interoperablen Austauschformats nach Abschnitt 8 Interoperables Austauschformat . Dabei verwendet der Client jeweils die beiden von den SGD erhaltenen Teilzeichenketten der Form "r1:<256-Bit-RND-in-Hexform>:<KVNR>:<Ableitungsschlüsselbezeichner>" als "associated data" (AD) bei der Kodierung. Dieses entsprechend erzeugte und kodierte Chiffrat schickt der Client an die "Komponente Autorisierung" zur Einlagerung im Aktensystem.

Bei einer Umschlüsselung des Akten- und Kontextschlüssels bei einem späteren ePA-Release (vgl. Ende von Abschnitt 2.1 Grundlage und Kernidee ) wird aufgrund des Einflusses der  jeweils vom SGD gewählten RND-Daten ein anderer Schlüssel generiert. Damit ist ein SGD nach aktueller Spezifikation schon jetzt auf diese Umschlüsselungsfunktionalität in Bezug auf die Client-Schnittstelle vorbereitet.

Hinweis: in den folgenden Sequenzdiagrammen wird auf die Aufführung des Authentisierungstokens und der Request-ID in der Nachricht (Message) an die SGD verzichtet.

Abbildung 3: Initiale Schlüsselableitung für den Kontoinhaber

2.5 Schlüsselableitung durch den Kontoinhaber

Der Versicherte (Kontoinhaber) meldet sich beim Aktensystem an und erhält nach erfolgreicher Authentifizierung und Autorisierung die "AuthorizationKey"-Datenstruktur vom Aktensystem. Darin befindet sich das zweifach verschlüsselte Chiffrat aus Abschnitt 2.4 Initiale Schlüsselableitung für den Kontoinhaber. Dort kann der Client aus den AD, durch Leerzeichen getrennt, jeweils den Ableitungsvektor für den SGD 1 und für den SGD 2 auslesen. Diese haben jeweils folgende Form:

r1:<256-Bit-RND-in-Hexform>:<KVNR>:<Ableitungsschlüsselbezeichner>

Der Client sendet eine Nachricht der Form

AT<256-Bit-Authentisierungstokenwert-in-Hexform> <Request-ID> KeyDerivation r1:<256-Bit-RND-in-Hexform>:<KVNR>:<Ableitungsschlüsselbezeichner>

einmal an den SGD 1 und einmal an den SGD 2, jeweils mit den SGD-spezifischen Ableitungsvektoren. Nach  müssen die Abfragen zur Generierung der beiden Schlüssel durch den Client parallelisiert werden. Das SGD-HSM prüft die Authentizität der Nachricht und verwendet u. a.  die KVNR des Versicherten bei der Schlüsselableitung (versichertenindividuelle Schlüsselableitung). Der Client erhält die beiden gleichen AES-256-Schlüssel, die er wie zuvor in Abschnitt 2.4 Initiale Schlüsselableitung für den Kontoinhaber erhalten hat. Die Antwort der SGD ist dabei analog zu Abschnitt 2.4 Initiale Schlüsselableitung für den Kontoinhaber der folgenden

AT<256-Bit-Authentisierungstokenwert-in-Hexform> <Request-ID> OK-KeyDerivation <AES-256-Bit-Schlüssel-in-Hexform> r1:<256-Bit-RND-in-Hexform>:<KVNR>:<aktueller Ableitungsschlüsselbezeichner>

Nachdem beide Schlüssel (je einer aus SGD 1 und aus SGD 2) vorliegen, entschlüsselt der Client (vgl.  ) das zweifach verschlüsselte Chiffrat im "Zwiebelschalenprinzip" mittels AES-GCM. Dabei prüft es die Authentizität der Chiffrats und der AD (Authenticated Encryption with Associated Data (AEAD)) bzw. damit auch die Authentizität des erhaltenen Klartextes. 

Im Nicht-Fehlerfall liegen danach der Akten- und Kontext-Schlüssel in der Kodierung nach  vor.

Dieses Vorgehen funktioniert unabhängig davon, ob der Versicherte seine eGK (oder alternative Versichertenidentität) wie bei der Aktenkontoeröffnung oder eine Folgekarte (oder "Folge"-Identität) verwendet.

Abbildung 4: Schlüsselableitung durch den Kontoinhaber

2.6 Schlüsselableitung für einen Berechtigungsempfänger

Für das Berechtigen eines Vertreters, einer LEI oder eines KTR durch den Kontoinhaber muss der Client des Kontoinhabers den Akten- und Kontextschlüssel für einen Berechtigungsempfänger verschlüsselten im Aktensystem hinterlegen. Hierfür liegen der Akten- und Kontextschlüssel temporär im Client des Kontoinhabers im Klartext vor. Der Client fragt jeweils SGD 1 und SDG 2 für eine für diesen Anwendungsfall spezifische Schlüsselableitung (r2) an.

Der Client sendet jeweils eine Nachricht der Form

AT<256-Bit-Authentisierungstokenwert-in-Hexform> <Request-ID> KeyDerivation r2:<KVNR-Vertreter oder Telematik-ID>

an beide SGD und erhält jeweils eine Antwort der Form

AT<256-Bit-Authentisierungstokenwert-in-Hexform> <Request-ID> OK-KeyDerivation <AES-256-Bit-Schlüssel-in-Hexform> r2:<256-Bit-RND-in-Hexform>:<KVNR-Kontoinhaber>:<KVNR-Vertreter oder Telematik-ID>:<aktueller Ableitungsschlüsselbezeichner>

Mit beiden erhaltenen Schlüsseln verschlüsselt der Client den Akten- und Kontextschlüssel und kodiert nach  das zweifach verschlüsselte Chiffrat. Dabei werden die Ableitungsinformationen ebenfalls authentitäts- und integritätsgeschützt (AEAD). Die vom Client erzeugte Datenstruktur wird im Aktensystem für den Berechtigungsempfänger hinterlegt.

Abbildung 5: Schlüsselableitung für einen Berechtigungsempfänger

2.7 Schlüsselableitung durch einen Berechtigten

Ein Vertreter, eine LEI bzw. ein KTR meldet sich am Aktensystem an und erhält die AuthorizationKeys-Datenstruktur. Dort befindet sich das zuvor vom Versicherten hinterlegte zweifach verschlüsselte Chiffrat mit dem verschlüsselten Akten- und Kontextschlüssel. In den AD sind die Ableitungsinformationen enthaltenen, die ein Client für die Anfragen an die beiden SGD benötigt. Der Client sendet jeweils an die SGD eine Nachricht der folgenden Form

AT<256-Bit-Authentisierungstokenwert-in-Hexform> <Request-ID> KeyDerivation r2:<256-Bit-RND-in-Hexform>:<KVNR-Kontoinhaber>:<KVNR-Vertreter oder Telematik-ID>:<Ableitungsschlüsselbezeichner>

und erhält jeweils eine Antwort der Form

AT<256-Bit-Authentisierungstokenwert-in-Hexform> <Request-ID> OK-KeyDerivation <AES-256-Bit-Schlüssel-in-Hexform> r2:<256-Bit-RND-in-Hexform>:<KVNR-Kontoinhaber>:<KVNR-Vertreter oder Telematik-ID>:<Ableitungsschlüsselbezeichner>

Das SGD-HSM prüft, ob im vierten Feld der Ableitungsinformationen "<KVNR-Vertreter oder Telematik-ID>" zu den authentischen Angaben passt, die im Zertifikat der Anfrage stehen (plus Signaturprüfung, Sperrstatus u. v. m.). Bei erfolgreicher Prüfung führt das SGD-HSM die Ableitung durch und übergibt dem Client die generierten Schlüssel über den verschlüsselten und beidseitig authentisierten Datenkanal zwischen Client und SGD-HSM.

Der Client kann nun das zweifach verschlüsselte Chiffrat entschlüsseln und ihm stehen der Akten- und der Kontextschlüssel zur Verfügung.

Abbildung 6: Schlüsselableitung durch einen Berechtigten

2.8 Schlüsselableitung für einen Berechtigungsempfänger durch einen Vertreter

Der Vertreter ist am Aktensystem angemeldet und möchte im Rahmen seiner Vertretungstätigkeit im Aktensystem eine LEI oder einen KTR berechtigen. Dafür muss der Client des Vertreters den Akten- und den Kontextschlüssel der Akte des Kontoinhabers für den Berechtigungsempfänger verschlüsselt hinterlegen.

Der Client sendet jeweils die Nachricht

AT<256-Bit-Authentisierungstokenwert-in-Hexform> <Request-ID> KeyDerivation r3:<Telematik-ID>:<KVNR-Kontoinhaber>

und erhält jeweils eine Antwort der Form

AT<256-Bit-Authentisierungstokenwert-in-Hexform> <Request-ID> OK-KeyDerivation <AES-256-Bit-Schlüssel-in-Hexform> r3:<256-Bit-RND-in-Hexform>:<KVNR-Kontoinhaber>:<KVNR-Vertreter>:<Telematik-ID>:<aktueller Ableitungsschlüsselbezeichner>

Mit den beiden von den SGD erhaltenen Schlüsseln verschlüsselt der Client den Akten- und Kontextschlüssel und bildet eine Datenstruktur gemäß . Diese wird für den Berechtigungsempfänger im Aktensystem hinterlegt.

Abbildung 7: Schlüsselableitung für einen Berechtigungsempfänger durch einen Vertreter

2.9 Schlüsselableitung für einen durch einen Vertreter berechtigten Berechtigten

Analog zu Abschnitt 2.7 Schlüsselableitung durch einen Berechtigten verwendet der Client der LEI die AuthorizationKeys-Datenstruktur und die darin befindlichen AD. Der Client verwendet die Ableitungsvektoren aus den AD (diese werden mit "r3:" beginnen). Mit diesen beiden Ableitungsvektoren fragt der Client parallel jeweils SGD  1 und SGD 2 an, jeweils mit einer Nachricht der Form

AT<256-Bit-Authentisierungstokenwert-in-Hexform> <Request-ID> KeyDerivation r3:<256-Bit-RND-in-Hexform>:<KVNR-Kontoinhaber>:<KVNR-Vertreter>:<Telematik-ID>:<aktueller Ableitungsschlüsselbezeichner>

und erhält jeweils eine Antwort der Form

AT<256-Bit-Authentisierungstokenwert-in-Hexform> <Request-ID> OK-KeyDerivation <AES-256-Bit-Schlüssel-in-Hexform> r3:<256-Bit-RND-in-Hexform>:<KVNR-Kontoinhaber>:<KVNR-Vertreter>:<Telematik-ID>:<aktueller Ableitungsschlüsselbezeichner>

Dabei prüft das SGD-HSM innerhalb eines SGD zuvor, ob das Datenfeld "<Telematik-ID>" in den Ableitungsinformationen zu den authentischen Angaben passt, die im Zertifikat der Anfrage stehen (plus Signaturprüfung, Sperrstatus u. v. m.). Bei erfolgreicher Prüfung führt das SGD-HSM die Ableitung durch und übergibt dem Client die generierten Schlüssel über den verschlüsselten und beidseitig authentisierten Datenkanal.

Der Client kann nun das zweifach verschlüsselte Chiffrat entschlüsseln und ihm stehen der Akten- und der Kontextschlüssel zur Verfügung.

Abbildung 8: Schlüsselableitung für einen durch einen Vertreter berechtigten Berechtigten

2.10 Nichtspeicherung von Versichertendaten

Ein SGD speichert keine versichertenspezifischen Daten. Die Berechnung der versichertenindividuellen Schlüssel ist eine kryptographische Berechnung (Schlüsselableitung) auf Grundlage des jeweiligen SGD-spezifischen Ableitungsschlüssels und vom Client authentisiert übergebener Ableitungsvektoren. Ein solcher versichertenindividueller Schlüssel wird nur nach erfolgreicher Authentifizierung eines anfragenden Versicherten berechnet und nach der verschlüsselten Übertragung an den Versicherten sofort wieder im SGD-HSM gelöscht. Für den Aufbau des beidseitig authentisierten verschlüsselten Datenkanals zwischen SGD-HSM und Client wird das AUT-Zertifikat des Nutzes (bspw. des Versicherten) kurzzeitig benötigt. Dieses Zertifikat wird vom SGD nicht persistent gespeichert ( ).

2.11 Besondere Rolle SGD-HSM

Das SGD-HSM mit seinem speziellen HSM-Firmware-Modul und den begleitenden technischen und organisatorischen Prozessen ermöglicht es mit hoher Sicherheit, eine durch den Betreiber bestimmte Schlüsselableitung innerhalb des SGD auszuschließen. Das SGD-HSM entscheidet, ob eine ausreichende Authentifizierung stattgefunden hat und führt erst danach die Schlüsselableitung durch. Anschließend überträgt es die abgeleiteten spezifischen Schlüssel über einen beidseitig authentisierten und verschlüsselten Datenkanal (Ende-zu-Ende-Sicherheit) zum Client.

Damit dies möglich wird, muss man auf die Einschränkungen der Embedded-Umgebung, in dem das SGD-HSM-Firmware arbeitet, eingehen:

1. Die Performanzvorgaben verbieten ähnlich wie in einer Chipkarte die Verwendung eines Ende-zu-Ende geführten TLS-Kanals. Bei Chipkarten verwendet man anstatt eines TLS-Kanals ein Secure-Messaging (Anwendung VSDM).  Die Ende-zu-Ende-verschlüsselte Datenverbindung zwischen Client und SGD-HSM verwendet das ECIES-Verfahren (vgl. Abschnitt 9 Datenkanal zwischen Client und SGD (informativ)) für das es einen kryptographischen Sicherheitsbeweis gibt.
   Zusammen mit den alle 15 Minuten wechselnden ECIES-Verbindungsschlüsseln eines SGD-HSM ermöglicht dieses Vorgehen die in Bezug auf die Clients zustandslose Abarbeitung von Requests innerhalb des SGD-HSMs.
2. Ähnlich wie die Zertifikatsprüfung in einer Chipkarte kann die Zertifikatsprüfung im SGD-HSM nicht auf der relativ komplexen TSL-Auswertung basieren. Anstatt der TSL-Auswertung wird u. a. die Rückführbarkeit zur X.509-Root der TI und weiteren im SGD-HSM sicher gespeicherten CA-Zertifikaten der TI bei der Zertifikatsprüfung verwendet (vgl. Abschnitt 4.5.1 Zertifikats- und Schlüsselprüfung im SGD-HSM ).

3 Übergreifende Festlegungen

3.1 Beziehung zwischen ePA-Aktensystem und SGD

Für einen Versicherten müssen zwei unabhängige SGD-Instanzen zur parallelen Nutzung für die zweifache Schlüsselgenerierung zur Verfügung stehen. Beide SGD müssen dabei technisch, organisatorisch und wirtschaftlich unabhängig sein. Um dies sicherzustellen, gibt es einen SGD, den alle Aktensysteme als SGD 2 verwenden (). 

3.2 Verfügbarkeit und Performanz

Verfügbarkeits- und Performanzanforderungen für einen SGD befinden sich in  und sind dem Produkttypsteckbrief SGD zugewiesen.

3.3 Sichere Betreiberumgebung

Ähnlich wie einem TSP werden an den Betreiber eines SGD ePA Anforderungen u. a. an die sichere Betreiberumgebung aus [gemSpec_DS_Anbieter] gestellt (vgl. Zuordnung im Produkttypsteckbrief). Die zugeordneten Module sind "Basis-IS", "Basis-ISMS", "Erweitertes ISMS", "TI-Sicherheitsbericht" und "„Erweiterter TI-Sicherheitsbericht“.

3.4 Verschiedenes

Eine korrekte Zeit ist im SGD an drei Stellen wichtig: 

1. für die EE-Zertifikatsprüfung in der RVE (ist der aktueller Prüfzeitpunkt innerhalb der Gültigkeitsdauer des zu prüfenden EE-Zertifikats),
2. für die EE-Zertifikatsprüfung in den SGD-HSM, und
3. für Zeitstempel bei Logdaten, die für die Fehleranalyse im SGD erhoben werden können.

Keiner dieser Anwendungszwecke verlangt, dass die Zeit in den o. g. Teilkomponenten im einstelligen Millisekundenbereich korrekt ist. 

Eine Zeitdrift von weniger als 5 Minuten innerhalb des SGD (RVE, SGD-HSM) ist aus Sicherheitssicht akzeptabel.

Die praktische Erfahrung nach mehr als einen Jahr mit verschiedenen SGDs in der PU zeigt, dass es notwendig ist die Zeit in den SGD-HSM kontinuierlich über NTP zu korrigieren. Die HSMs besitzen je nach Hersteller unterschiedliche Mechanismen, die eine schädliche Auswirkung einer temporärer Fehlfunktion des verwendeten NTP-Servers verhindern (ruckartige Änderungen über in den SGD-HSM konfigurierte Schrankenwerte).

Ein weiterer Erfahrungswert ist, dass ein Nachgehen der lokalen Zeit in den SGD-HSM um mehr als 5 Minuten insbesondere die Verfügbarkeit des SGD gefährdet, da dann i. d. R. OCSP-Antworten aus der Zukunft zu kommen scheinen, der akzeptable Schwellwert dafür dann überschritten ist und vom einen SGD-HSM die OCSP-Antworten abgelehnt werden.

Ebenfalls ist ein betriebliches Monitoring der Zeit in den SGD-HSM notwendig.

4 Bestandteile eines SGD

Ein SGD besteht aus

1. einer HTTPS-Schnittstelle (vgl. A_17889) innerhalb der TI,
2. einer Request verarbeitenden Einheit ( ) für die eingehenden HTTP-Requests, und
3. einem (oder mehreren) HSM (SGD-HSM genannt), das den wesentlichen Teil der Sicherheitsleistung des SGD erbringt.

Abbildung 9: Strukturelemente eines SGD

4.1 Request-Verarbeitung in einem SGD

Eingehende Requests eines Clients werden von der Request verarbeitenden Einheit (RVE) an der HTTPS-Außenschnittstelle (vgl.  ) entgegengenommen. Dort werden sie entweder direkt beantwortet (Operation GetPublicKey, A_17895-*) oder aufbereitet und danach an das SGD-HSM gesendet. Abhängig von der Antwort des SGD-HSM erzeugt die RVE eine Antwort für den Client (A_17908-01 ) und sendet diese an ihn. Die RVE hat keinen Einblick in den beidseitig authentisierten und verschlüsselten Datenkanal zwischen Client und SGD-HSM (vgl. Abschnitt 9 Datenkanal zwischen Client und SGD (informativ)). Die RVE stellt nur in Bezug auf die Verfügbarkeit (DoS-Gegenmaßnahmen, Einholen von signierten OCSP-Responses, Umkodieren von Requests etc.) des SGD eine kritische Komponente dar. In Bezug auf die Vertraulichkeit der Schlüssel erbringt sie keine Sicherheitsleistung.

Die Schnittstelle zwischen RVE und SGD-HSM ist eine Innenschnittstelle (vgl. Abschnitt ) und wird deshalb nicht ausspezifiziert beschrieben. Es werden nur notwendige Festlegungen getroffen.

Ein SGD-HSM wird auf einen von der RVE weitergeleiteten Request in fünf Weisen antworten:

1. Die Authentizität des Requests ist nicht gegeben (bspw. AES-GCM meldet FAIL oder das Authentisierungstoken ist ungültig), das SGD-HSM meldet FAIL. Die RVE muss, so wie in den Außenschnittstellen beschrieben, eine Fehlermeldung an den Client senden.
2. Die Authentifizierung war erfolgreich und die Schlüsselableitung wurde durchgeführt. Übergeben wird der RVE das Chiffrat für den Client. Die RVE muss die Antwort-Datenstruktur, so wie bei der Operation KeyDerivation ( ) beschrieben, kodieren und dem Client diese als Response senden.
3. Die Authentifizierung war erfolgreich und die Schlüsselableitung wurde nicht durchgeführt, weil der Klartext-Request des Client falsch formatiert ist. Das SGD-HSM erzeugt eine entsprechende Fehlermeldung für die RVE und übergibt diese an die RVE. Die RVE muss diese Fehlermeldung in einer Antwort-Datenstruktur, so wie in den Außenschnittstellen beschrieben, kodieren und dem Client diese als Response senden.
   Wenn die Fehlformatierung häufig vorkommt, liegt hier evtl. ein systematischer Fehler vor. Der SGD-Betreiber sollte davon wissen und bspw. mit Unterstützung der gematik eine Fehleranalyse unter Verwendung der TI-ITSM-Prozesse starten.
4. Die Authentifizierung war erfolgreich und die Schlüsselableitung wurde nicht durchgeführt, weil kein Ableitungsschlüssel vorhanden war mit dem vom Client übergebenen Ableitungsschlüsselbezeichner. Das SGD-HSM erzeugt ein Chiffrat mit entsprechender Fehlermeldung für den Client. Übergeben wird der RVE (1) das Chiffrat für den Client und (2) die Information über den Fehler. Die RVE muss die Antwort-Datenstruktur, so wie in den Außenschnittstellen beschrieben, kodieren und dem Client diese als Response senden.
   Wenn dieser Fehlerfall häufig vorkommt, liegt hier evtl. ein systematischer Fehler vor. Der SGD-Betreiber sollte davon wissen und eine Fehleranalyse starten.
5. Die Zertifikatsprüfung im SGD-HSM ergab FAIL. D. h., die RVE hat die eigene Zertifikatsprüfung (A_17908-01 ) nicht korrekt ausgeführt. Die RVE muss, so wie in den Außenschnittstellen bzw. in Abschnitt 6.7 Fehlermeldungen beschrieben, eine Fehlermeldung an den Client senden.

4.1.1 Routing auf die SGD-HSM

Ziel ist es, dass die SGD-HSM in einem SGD von einander unabhängig arbeiten können. D. h., u. a. sollen sie nicht ihre kurzlebigen Schlüssel (S4) und die damit verbundenen Schlüssel (S5) (vgl. jeweils Abschnitt "4.3 Schlüssel im SGD-HSM") untereinander synchronisieren müssen. Daher muss die RVE am Anfang des SGD-Protokoll für einen Client bei Erhalt der Nachricht 1 (vgl. Abschnitt "9.1 Ablauf Kommunikation zwischen Client und SGD-HSM") ein SGD-HSM aus der Menge der im SGD verfügbaren SGD-HSM auswählen. Diese Auswahl nimmt die RVE vor und teilt sie dem Client mit, in dem sie dem Client den aktuellen (S4)-Schlüssel des ausgewählten SGD-HSM bei GetPublicKey (vgl. Abschnitt "6.4 Operation GetPublicKey") als Protokoll-Nachricht 2 sendet. Alle weiteren Nachrichten dieses Client innerhalb dieses Protokollablaufes müssen dann genau das ausgewählte SGD-HSM erreichen. Dies bedeutet: die RVE muss für die folgenden vom Client gesendeten Nachrichten des SGD-Protokolls geeignete Routing-Entscheidungen vornehmen. Eine solche Routing-Entscheidung kann die RVE leicht treffen, denn im "PublicKeyECIES" (vgl. A_17900) ist der Hashwert des Ziel-(S4)-Schlüssels enthalten und der "PublicKeyECIES" ist Bestandteil jeder weiteren Protokoll-Nachricht des Clients.

Mit A_22493 ist es nun möglich, dass ein SGD-Client bspw. ein KTR-Consumer oder ein ePA-FdV nach einem GetPublicKey und einem GetAuthenticationToken beliebig viele Schlüsselableitungen mittels KeyDerivation durchführen kann, solange der verwendete (S4)-Schlüssel noch gültig ist (also 15 bis fast 30 Minuten). Damit sind für solch einen SGD-Client nicht mehr 6 * (Anzahl der abzuleitenden Schlüssel) SGD-Nachrichten notwendig, sondern nur noch 4 + 2*(Anzahl der abzuleitenden Schlüssel) SGD-Nachrichten. Für einen SGD-Client gibt es in Abschnitt "7.1 Mehrfachableitung" weiterführende Informationen.

4.2 SGD-HSM

Den wesentlichen Teil der Sicherheitsleistung eines SGD erbringt das SGD-HSM. Das SGD-HSM entscheidet, ob eine ausreichende Authentifizierung stattgefunden hat und führt erst danach eine Schlüsselableitung durch. Anschließend überträgt es die abgeleiteten spezifischen Schlüssel über einen beidseitig authentisierten und Ende-zu-Ende-verschlüsselten Datenkanal an den Client.

Ein SGD-HSM

1. erzeugt mindestens alle 15 Minuten ein neues ECIES-Schlüsselpaar,
   (Ein ECIES-Schlüsselpaar ist 30 Minuten für jeden Client nutzbar und wird danach im SGD-HSM sicher gelöscht)
2. enthält den privaten Signaturschlüssel (A_17910-01   (S1)), der für die Signatur (Authentisierung) des jeweils neu erzeugten öffentlichen ECIES-Schlüssels (A_17910-01   (S4)) notwendig ist,
3. erzeugt halbjährlich einen neuen Ableitungsschlüssel und hält zuvor erzeugte Ableitungsschlüssel im HSM vor,
4. prüft bei eingehenden Anfragen für eine Schlüsselableitung das Zertifikat des Anfragenden,
5. führt bei positivem Prüfergebnis eine Schlüsselableitung entsprechend den Ableitungsregeln durch,
6. verschlüsselt die abgeleiteten Schlüssel für den Anfragenden.

Das SGD-HSM muss ein besonderes Firmware-Modul enthalten, das diese Funktionalität abbildet. Dieses hat einen sehr begrenzten Funktionsumfang (ECC- und AES-Schlüssel erzeugen, Signaturen prüfen, aus einem AUT-Zertifikat die KVNR bzw. Telematik-ID auslesen, eine Hashfunktion (HKDF) berechnen, ECIES Ver- und Entschlüsselung durchführen und AES-GCM ausführen). Die Mehrzahl der Funktionen sind schon standardmäßig im HSM vorhanden.

Hinweis zu Punkt 7:

Analog zu den CC-Evaluierungen der TI-Komponenten muss es möglich sein, ohne dass Verschwiegenheitsregelungen die Klärung von fachlichen Punkten während der Sicherheitsbegutachtung behindern, die notwendige Dauer der Sicherheitsbegutachtung zu minimieren.

4.3 Schlüssel im SGD-HSM

In einem SGD müssen verschiedene Schlüssel verfügbar sein, die durch ein SGD-HSM geschützt werden müssen.

Hinweis zu A_17914-01  : Alle 15 Minuten wird ein neues ECIES -Schlüsselpaar (vgl. auch [gemSpec_Krypt# ]) erzeugt werden. Wenn kurz zuvor ein Client (ePA-FdV oder FM ePA) jedoch den öffentliche Schlüssel des alten Schlüsselpaares über die Schnittstelle GetPublicKey (A_17895-* ) erhalten hat, kann er das alte Schlüsselpaar maximal 15 Minuten weiter nutzen. Die Lebensdauer eines solchen ECIES-Schlüsselpaars in einem SGD-HSM ist also 30 Minuten.

Verständnishinweis zu  und : Dies ist analog zu den Vorgaben, wie seit 2014 die CVC-Root der TI betrieben wird. Damit wird der Betreiber eines SGD vom Verdacht befreit es könnte die geheimen Ableitungsschlüssel A_17910-01  (S3) missbrauchen. Er ist technisch aufgrund der zwei Anforderungen nicht in der Lage dies zu tun.

Aufgrund der Bedeutung der Schlüsselbestätigungsschlüssel für die Sicherheitsleistung werden diese innerhalb eines Clients nicht über die üblichen Zertifikatsprüfverfahren überprüft, sondern die Zertifikate, die die Schlüsselbestätigungsschlüssel enthalten, sind direkt (explizit) in der TSL aufgeführt (vgl.  (Prüfung eines SGD-HSM-Zertifikats) und ). Dadurch wirken etwaige Probleme bspw. in der Komponenten-PKI nicht auf die Sicherung der Authentizität der Schlüsselbestätigungsschlüssel (risikominimierende Maßnahme).

Hinweis: vgl. auch [gemSpec_PKI#Abschnitt ]. 

Hinweis: Die gematik stellt sicher, dass sich in der TSL nur SGD-HSM-Zertifikate nach A_17846-01 #(1) und nach A_17918-01  #(1) befinden, die zugehörig sind zu SGD-HSMs von zugelassenen SGD. Vergleiche auch   (Prüfung eines SGD-HSM-Zertifikats).

4.4 Pflege der Prüfschlüssel (S2) im SGD-HSM

In A_17910-01 (Schlüssel in einem SGD-HSM) wird mit (S2) eine geordnete Liste von Zertifikatssignaturprüfschlüsseln eingeführt. Diese Schlüssel bildet die Grundlage für die Zertifikatsprüfung in einem SGD-HSM ( A_17919-01 ). Einerseits handelt es sich um den RSA-Schlüssel der aktuellen X.509-Root-Version (RCA2) und analog den ECC-Schlüssel (RCA3) und andererseits um nicht von der TI-X.509-Root bestätigte X.509-eGK-CA-Zertifikate, die in der TSL der TI aufgeführt sind. Diese Schlüssel sind fester Bestandteil des SGD-HSM-Firmwaremoduls (A_17912-01 ). Alle zukünftig erzeugten CA-Zertifikate der TI werden durch die X.509-Root bestätigt werden [gemSpec_X.509_TSP#]. 

Aus Performanzgründen müssen für die Zertifikatsprüfung die CA-Zertifikate schon geprüft im SGD-HSM vorliegen. Ansatzpunkt der Prüfung von EE-Zertifikaten ist im SGD-HSM immer einen solcher CA-Schlüssel. Die RVE kennt die aktuelle Liste im SGD-HSM (A_17952-01  Punkt 1) und teilt dem SGD-HSM bei einer Requestweitergabe mit welcher Prüfschlüssel im SGD-HSM für die Zertifikatsprüfung der Richtige ist (vgl. A_17908-01 ), also vom SGD-HSM zu verwenden ist. Wie ein SGD-HSM erkennen kann, ob ein importiertes Zertifikat ein CA-Zertifikat oder ein OCSP-Signer-Zertifikat ist, ist in [gemSpec_PKI] definiert.

Wenn bei  Punkt (1) der Download aufgrund eines Fehlers nicht erfolgen kann, so greift das bei einer "Trust-service Status List" (TSL) übliche Standardvorgehen: die am Vortag heruntergeladene TSL hat eine in der TSL kodierte Gültigkeitsdauer (i. d. R. 30 Tage). Diese TSL ist dann im SGD weiterhin verwendbar und auch zu verwenden. Sollte der Download länger als diese Gültigkeitsdauer nicht funktionieren (was aufgrund der SLA des TSL-Dienstes quasi ausgeschlossen ist), so kann die RVE keine EE-Zertifikatsprüfungen mehr durchführen und muss alle Client-Requests (bis auf GetPublicKey) ablehnen, weil sie bspw.  (Zertifikatsprüfung) erfüllen muss ("Falls eine der Prüfungen ein nicht-positives Ergebnis liefert, so MUSS die RVE des SGD mit einer entsprechenden Fehlermeldung [...] die weitere Requestverarbeitung abbrechen"). 

Hinweis: Nach der Erzeugung einer neuen Root-Version der X.509-Root-CA der TI werden dessen selbstsigniertes Zertifikat und Crosszertifikate auf den Download-Punkt https://download.tsl.ti-dienste.de/ECC/ROOT-CA/ abgelegt. Automatisiert kann der SGD ePA von dort die Verfügbarkeit neuer Versionen überwachen. Im Regelfall wird alle zwei Jahre eine neue Root-Version erzeugt.

Ebenfalls kann man https://download.tsl.ti-dienste.de/ECC/Root-CA/roots.json verwenden. Dort werden die aktuellen Root-Zertifikate inkl. deren Crosszertifikate gepflegt. Implementierungshinweis: die Dateigröße der JSON-Datei kann man als Hashfunktion verwenden. Mit dieser Idee kann man bspw. via curl die HTTP-Methode HEAD verwenden, und damit erfahren ob die lokale Kopie der JSON-Datei noch aktuell ist.

Die JSON-Datei ist ein Array in dem Associative Arrays als Elemente aufgeführt werden. Diese Elemente enthalten je ein Root-Zertifikat inkl. Crosszertifikate für das chronisch vorhergebende und das nachfolgende Root-Zertifikat. D. h.,  kryptographisch gesehen stellt dies eine doppelt verkettet Liste dar. Die Element im Array sind in chronologischer Ordnung sortiert.

[
{ "name" : "RCA1", "CN" : "GEM.RCA1", "cert" : "…base64…", "prev” : "", "next" : "….base64…", "SKI" : "Subject-Key-Identifier als Hexwert" },
{ "name" : "RCA2", … },

{ "name" : "RCA3", … },

…

]

4.4.1 Zuordnung von OCSP-Responder-Zertifikaten zu CA-Zertifikaten (informativ)

Der Vertrauensraum der TI (also die PKI der TI) wird so wie der eIDAS-Vertrauensraum technisch über eine „Trust-service Status List“ nach der dem europäischen Standard ETSI TS 102 231 [ETSI_TS_102_231_v3.1.2] abgebildet. Eine TSL führt verschiedene TSP (CA) auf und einige ihrer CA-Zertifikate.

Im Zusammenspiel dazu gibt es noch die X.509-Root der TI. Über die Prüfung mittels der X.509-Root kann man für bestimmte Anwendungsfälle äquivalente Prüfaussagen wie über die Prüfung mittels der TSL treffen. Die Prüfung über die X.509-Root ist technisch deutlich einfacher als über die TSL, weswegen dieser Weg auch im SGD-HSM verwendet wird.

In der TSL sind neben Metainformationen zu den CA-Zertifikaten ebenfalls OCSP-Responder-Zertifikate aufgeführt. Diese müssen nicht notwendiger Weise per kryptographischer Signaturprüfung auf die CA-Zertifikate rückführbar sein zu den CA über die die Responder Sperrauskünfte geben dürfen. Dies ist ein wichtiger Unterschied im Vergleich zur Prüfung über die X.509-Root.

Bei der Zuordnung der OCSP-Responder-Zertifikate zu den CA-Zertifikaten bei der Erstellung der Import-Listen für die Schlüssel (S2) (vgl. A_17910-*) für die SGD-HSM-Initialisierung ist zu beachten, dass nach dem TSL-Modell alle OCSP-Responder die für einen TSP definiert sind für alle CA desselben TSP Sperrauskünfte geben dürfen. Sind also bspw. für einen TSP in der TSL drei CA-Zertifikate angegeben und ein OCSP-Responder-Zertifikat, so kann dieser Responder für alle drei CA Sperraussagen treffen. Sind mehr als ein OCSP-Responder-Zertifikat pro TSP definiert, so drüber alle OCSP-Responder für alle CA desselben TSP Sperraussagen treffen. Es gibt also ein n zu m Zuordnung, sie sich in der Import-Liste widerspiegeln muss.

Um die Aufgabe der Initialisierung der SGD-HSM zu unterstützen stellt die gematik auf Anfrage ein Programm zur Verfügung, dass diese Zuordnung aus einer aktuellen TSL automatisch erzeugt. Im Rahmen der Schlüsselzeremonie also der Initialisierung der SGD-HSM muss gemäß A_17916 der Anbieter des SGD und ein Vertreter der gematik die Import-Liste gemeinsam in die SGD-HSM importieren, dafür muss diese Liste zwischen beiden Parteien konsentiert sein – Überprüfung der Korrektheit der Liste im Mehr-Augen-Prinzip.

4.5 Funktionsablauf Firmware-Modul SGD-HSM

In diesem Abschnitt wird die Ablauflogik im speziellen HSM-Firmware-Modul beschrieben. Diese Beschreibung ist Grundlage der für die Zulassung notwendigen Sicherheitsüberprüfung (vgl.  ).

4.5.1 Zertifikats- und Schlüsselprüfung im SGD-HSM

Damit im SGD-HSM nur für den jeweils Berechtigten eine Schlüsselableitung durchgeführt wird, muss dessen Request auf Authentizität geprüft werden. Dafür muss dessen AUT-Zertifikat innerhalb des SGD-HSMs überprüft werden.

Eine Standard-TI-Prüfung auf Basis der TSL ist technisch relativ komplex und ist insbesondere in beschränkten  Laufzeitumgebungen wie Chipkarten oder HSM-Firmware-Modulen nur schwer umsetzbar. Damit diese Prüfung technisch praktikabel ist, wird bei der Prüfung des AUT-Zertifikats die Signaturkette auf die X.509-Root der TI geprüft. Es werden ebenfalls OCSP-Antworten notwendigerweise ausgewertet.

Hinweis zu A_17919-01 :

Das SGD-HSM kann davon ausgehen, dass die X.509-Root-CA und alle in der PKI-Hierarchie folgenden CAs korrekt formatierte Zertifikate ausgeben. Es muss also vom SGD-HSM nicht die vollständige Konformität der erhaltenen Zertifikate zu den in [gemSpec_PKI] definierten Zertifikatsprofilen geprüft werden, was technisch in einer beschränkten Laufzeitumgebung schwierig ist.

Die Sonderbehandlung von Root-Schlüsseln im SGD-HSM in A_18010 ist analog definiert worden wie das Verhalten im COS bei G2-Karten. Ein SGD-HSM kann nach A_21274 davon abweichen und die Gültigkeitsdauer auch bei Root-Schlüsseln streng durchsetzen.

4.5.2 Authentisierungstoken im SGD-HSM

4.5.3 Schlüsselableitung im SGD-HSM

Beispiel zu A_17926:

Sei RND="123" und KVNR="a4b5c6". Wenn im Algorithmus in Tabelle 3 a="r1:<RND>:<KVNR>" gesetzt wird, und a als Ableitungsvektor verwendet werden soll, so müssen die Werte der Variablen RND und KVNR interpoliert werden. Es entsteht damit die Zeichenkette a="r1:123:4a5b6c". Dieser Wert von a muss dann als Wert des Ableitungsvektor bei der Schlüsselableitung verwendet werden.

Hinweis: nach wird für die Schlüssel als Schlüsselableitungsfunktion die HKDF nach [RFC-5869] auf Basis von SHA-256 verwendet. Ebenso befinden sich in [gemSpec_Krypt#] die Vorgaben zur Mindestentropie.

Man beachte, dass absichtlich keine Doppelpunkte im Bezeichner zugelassen sind.

Beispiele für gültige Ableitungsschlüsselbezeichner: 

• ACME 2019-1
• AB AbCdEfGhI 12 jklmn

Testmöglichkeit:

echo 'Bezeichner 2021-Test 1' | \
perl -ne 'print /^\w[\w -]{1,7167}$/ ? "OK: " : "UNGÜLTIG: ", $_;'

4.5.4 Kommando-Abarbeitung KeyDerivation im SGD-HSM

Tabelle 4: Tab_Kommandoabarbeitung_im_SGD-HSM

4.5.5 Betriebsunterstützende Leistungen im SGD-HSM

4.6 Betriebsunterstützende Leistungen allgemein

 Die RVE ist dafür verantwortlich neu in der TSL aufgeführte Prüfschlüssel automatisch in die SGD-HSM zu importieren (vgl. Abschnitt "4.4 Pflege der Prüfschlüssel (S2) im SGD-HSM "). Die SGD-HSM stellen die Authentiztität der neu importieren Prüfschlüssel über die Signaturprüfung auf Grundlage von schon im SGD-HSM vorhandenen Root- und CA-Schlüsseln sicher. Um im Betrieb zu erkennen, ob dieses Update evtl. fehlerhafter Weise nicht erfolgt ist, wird mit A_22502-* eine automatische Überprüfung (Abgleich Ist-Soll-Stand der Prüfschlüssel in den SGD-HSM) gefordert.

Erläuterung: die URL für den Download der Soll-Wert-Liste erfragt der Anbieter (bzw. der Betreiber) bei der gematik. Das Format der Soll-Wert-Liste ist das aus der gemeinsamen Schlüsselzeremonie Erst-Initialisierung der SGD-HSM (chk_import_list.py).

Die Umsetzung des Fehlererkennungsteils von A_22502 ist in nur wenigen Zeilen Bash-Skript möglich.

5 Kodierung von Schlüsseln und Nachrichten

Im Rahmen des SGD-Protokolls müssen verschiedene Zahlenwerte (Koordinaten von Kurvenpunkten) und Hashwerte (Hashwerte von Schlüsselwerten) kodiert werden. Diese Kodierungen fließen an mehreren Stellen in eine Hashwerterzeugung mit ein. Dabei ist es wichtig, ob bspw. die Zahl 10 als "0xa" oder "0xA" kodiert wird. Analog bei Hashwerten in Hexadezimalform, die in eine Hashwerterzeugung mit einfließen.

Gut-Beispiel (vgl.  ):

"brainpoolP256r1 " +
"0x3672030bace787aa319e21d40645b2999006beec437fd084dd3fc592f5fcd77c" + " " +
"0x335b226ce5fac0c36a18ce42e95f43c9eed3e256bdd0c98e55a069595515d15b" + " " +
"a3a56e51377c1de0bea0522eba3ec6277e3355edb67d48b9852ab7d7e536feb7" + " " +
"8b2405f41cebaf44d10b2c9025484515b005be5ba785d0c898eae0739a67eb5a"

Bei der Kodierung der ECIES-Schlüssel (vgl. A_17894-01  und ) müssen X- und Y-Koordinaten als Zahlenwerte in Hexadezimalform in einer menschenlesbaren Zeichenkette (string) kodiert werden. Es gibt Kryptographie-Softwarebibliotheken, die falls die Koordinatenwerte mit einer 1 im most-significant Byte beginnen, ein Nullbyte vor den Koordinatenwert setzen. Dies kommt aus einer Konvention aus der ASN.1-Kodierungsweise, die im SGD-Kontext keine Rolle spielt (Ausnahme im DER-kodierten Zertifikat selbst). Beispiel: Die Zahl 128 muss Hexadezimal als "0x80" und nicht als "0x0080" kodiert werden.

5.1 Kodierung von Schlüsseln

5.1.1 ECIES-Schlüssel eines SGD-HSM

Bei der Operation GetPublicKey (A_17895-*) muss der aktuelle öffentliche ECIES-Schlüssel (A_17910-01  (S4)) des SGD-HSMs an einen Client versendet werden.

Hinweis zum besseren Verständnis: Da das Zertifikat im "Certificate"-Datenfeld direkt in der TSL aufgeführt ist (vgl.) und die TSL eine Positivliste ist, gibt es keine Aufführung (A_17894-01 ) oder Einholung von OCSP-Responses.

Tabelle 5: Beispiel zu A_17894

5.1.2 ECIES-Schlüssel eines Clients

Das kurzlebige ECIES-Schlüsselpaar eines Clients (ePA-FdV, FM EPA etc.) muss an die aktuellen öffentlichen ECDH-Schlüssel des nun angefragten SGD-HSM "gebunden" werden. Dies geschieht über die Signatur durch die eGK, die alternative Versichertenidentität, die SMC-B oder eine SMC-KTR.

Hinweis zu A_17900: vor den SHA-256-Hashwerten steht kein "0x"-Präfix, weil es sich bei SHA-256-Hashwerten nicht um Zahlen handelt, sondern um 256-Bit große Bitfelder.

Tabelle 6: Beispiel zu A_17900

5.2 Kodierung von Chiffraten

Hinweise zu :

1. Der bei den Requests bei A_17894-01  (GetAuthenticationToken) und bei übergebene ECIES-Schlüssel hat nach  die beiden Hashwerte der SGD-HSMs Schlüssel von SGD 1 und SGD 2 beigefügt (durch die Signatur des Client mit authentisiert). Beim der Chiffratkodierung nach  sind die beiden Hashwerte kein Teil des Chiffrats, weil sie dort fachlich nicht notwendig sind.
2. Beim pro ECIES-Verschlüsselung vom Sender zu erzeugende ephemeren ECC-Punkt ("ephemer-Sender-ECC-Punkt") wird der Kurvenidentifikator (KurvenID) nicht mit aufgeführt, da der ECC-Punkt auf der gleichen Kurve wie der Empfänger ECC-Punkt liegen muss (vgl.).

Beispiel zu :

Sei durch den Client folgender Klartext im Rahmen der Operation KeyDerivation () vom Client an ein SGD-HSM zu übertragen:

"AT1ce627dd5e4c6536ca0dd93f896744d42c6580537953a49fcc5840dd8f8f4efa 7522d04ca28f2c6d3f5a53b2a31aebe1f91f2cfb75145b35c9a01fae7930340c KeyDerivation r2:7f8f77003dbab49c3a4e32f44726f92324d292fa668fde5ebc3424397986be99:107299005A112102647:2-20a1201-001:Bezeichner ACME Q1 2020"

Dann hat das für den Request vom Client zu erzeugende Chiffrat ("EncryptedMessage"-Feld im Request) folgende Form

"brainpoolP256r1" + " " + 
"0x743cf1b8b5cd4f2eb55f8aa369593ac436ef044166699e37d51a14c2ce13ea0e" + " " +
"0x36ed163337deba9c946fe0bb776529da38df059f69249406892ada097eeb7cd4" + " " +
"0xa8f217b77338f1d4d6624c3ab4f6cc16d2aa843d0c0fca016b91e2ad25cae39d" + " " +
"0x4b49cafc7dac26bb0aa2a6850a1b40f5fac10e4589348fb77e65cc5602b74f9d" + " " +
"pvUazQKriCfuE5wUX74yj5lvnzygbaUgtP/gAY1aPs1NjXCiWseV4GquSKdMozNoYsfIf0LbdpLwKdUSFYz2dySspGLTUBpmalYz/6G/B5M19y6Ce+TyoLJehTB0TzzAD9pwzVSJFsUiYCUG1KU6SohSjAIxHrebyo7+MYuQAd4uPnZ3ZiDukWglDr/7fTUafAEiF5gS0T+LRcaKimfSmPQjtjomgjn6jfl5u9gSyrAwOTCuVkZpSY6yjI1LjEy2jKRpMov4DiYTCMMbY8fLG1PmBp4SDvoLd7p+2ay9cyx1qYU43/zbxQGfK3nzBtFKMggS+73rHJpCL+0FPYoqTRkSAN17vxRUHCBESUfd9aAar3ZrhMrQwSj/QKnyG6Gg43WHYMjT6znsHxA="

Verständnishinweis zu  : Da dies ein häufig auftretender sicherheitskritischer Implementierungsfehler ist, wird auf diesen Punkt explizit hingewiesen und damit eine gesonderte Stellungnahme diesbezüglich im Produktsicherheitsgutachten gefordert.

6 Schnittstellen und Operationen

Der SGD ePA bietet innerhalb der TI eine HTTPS-Schnittstelle als Kommunikationsschnittstelle an.

Die gematik stellt auf Anfrage eine Beispiel-Implementierung für die Außenschnittstellen eines SGD bereit.

6.1 Innenschnittstellen

Die Innenschnittstellen zwischen der Request verarbeitende Einheit (RVE) für die eingehenden HTTP-Request und dem SGD-HSM sind SGD-intern. Deren Ausgestaltung bleibt dem Betreiber überlassen.

6.2 HTTPS-Schnittstellen und HTTP-Kommunikation

Genaue Vorgaben für die Verwendung des TLS-Protokolls bei der HTTPS-Schnittstelle befinden sich in [gemSpec_Krypt] und die entsprechenden Anforderungen sind den Produkttypen (Produkttypsteckbrief) zugewiesen.

Es kann nicht ausgeschlossen werden, dass aufgrund von Fehlkonfiguration oder Fehlfunktion eines Clients aus der TI sehr viele TCP-Verbindungen in kurzer Zeit zum SGD aufgebaut werden. Dann muss es dem Betreiber möglich sein, diesen Sender temporär durch Verwerfen der IP-Pakete des Senders am Verbindungsaufbau zu hindern.

Das ZGdV (vgl.) ist im Vergleich zu einem SGD in einer besseren Position, Gegenmaßnahmen gegen DoS-Angriffe aus dem Internet zu ergreifen. Ein SGD kennt nicht die IP-Adresse des Clients – alle Requests kommen von einer IP-Adresse des ZGdV. Deswegen kann ein SGD nur schlecht auf IP-Ebene DoS-Gegenmaßnahmen gegen Clients aus dem Internet ergreifen. Ein SGD kann jedoch die kryptographische Identität des Anfragenden mit hoher Sicherheit schon in der RVE feststellen und bei DoS-Angriffen auf dieser Grundlage Client-spezifische DoS-Gegenmaßnahmen ergreifen.

Hinweise zu A_17891:

In Bezug auf DoS-Gegenmaßnahmen auf Applikation-Ebene stehen die Operationen GetAuthenticationToken (A_18025-*) und  (  ) im Fokus, also die Operationen, die unmittelbaren Zugriff auf die SGD-HSM verlangen.

Bei der Operation  (A_17895-*) wird nur eine Datenstruktur nach A_17894-01  (aktueller ECIES-Schlüssel des avisierten SGD-HSM) quasi semistatisch zurückgeliefert. Eine RVE muss die ECIES-Schlüssel alle 15 Minuten vom jeweiligen SGD-HSM erfragen und in eine  Datenstruktur nach A_17894-01  überführen. Diese Datenstruktur liefert die RVE dann statisch 15 Minuten lang aus. Damit steht dort der DoS-Schutz auf Anwendungsebene nicht im Fokus.

Bei den Operationen GetAuthenticationToken (A_18025-*) und  ( ) muss die RVE die Signatur und das Zertifikat des Clients prüfen (vgl. bspw.  ) und bei nicht-positivem Prüfergebnis verwerfen (A_17908-01 ). Wenn ein Client zu oft Anfragen stellt, so kann die RVE dessen Anfragen herunter priorisieren oder den Client mit einem Fehler (vgl. [gemSpec_SGD_ePA#Tabelle Tab_Fehlerfälle_und_Fehlermeldungen]) abweisen. Je nach Art des DoS-Angriffs kann es auch notwendig sein, selektiv gleich auf TCP-Ebene Verbindungsaufbauten abzulehnen.

Ein Herunterpriorisieren oder Ablehnen von Client-Requests auf Applikationsebene kann man effizient bspw. mittels "counting bloom filter" implementieren. Dafür erzeugt der SGD ein ausreichend großes 64-bit-Zählerfeld. Bspw. die letzten 256 Bits der Signatur des AUT-Zertifikats werden beim Eintreffen der schon geprüften Requests über eine (nicht-notwendigerweise kryptographisch sichere, d. h. sehr performante) Hashfunktion auf einen Index des Feldes überführt. Dort wird der Zähler mit dem entsprechenden Index im Feld erhöht. Falls dieser Zählerwert über einem festgelegten Limit ist, wird der Request abgelehnt. Periodisch werden alle Zähler des Zählerfeldes, die größer als Null sind, verringert.

Bei der Requestverarbeitung (vgl. Abschnitt ) meldet das SGD-HSM der RVE verschiedene Fehlerfälle. Treten bei Requests mit bestimmten "Certificate"-Inhalten besonders häufig Fehler auf, so kann die RVE solche Requests für eine gewisse Zeit sperren oder ein Rate-Limiting für solche Requests durchsetzen.

Bei bestimmten Arten von DoS-Angriffen kann nur das ZGdV effektiv Gegenmaßnahmen ergreifen (vgl. Kommentar vor ). 

Implementierungshinweis:

Es ist davon auszugehen, das SMC-B-Zertifikat über den VZD semi-öffentlich verfügbar sind. Damit kann man mit dem "Certificate"-Feld alleine nicht sicher auf die Identität des anfragenden Client schließen. Da im öffentlichen Client-Schlüssel der Hashwert des aktuell vom Client verwendeten (S4)-Schlüssels enthalten ist und dieser sich alle 15 Minuten ändert, kann man mit hoher Sicherheit davon ausgehen, dass wenn die Signatur des Client-Schlüssel kryptographisch korrekt ist, der Request tatsächlich vom angegebenen Client (SMC-B-AUT-Zertifikat) kommt.

Für diese Signaturprüfung ist nach A_22448-* ein Cache zu verwenden. Man kann bei Ankunft eines Requests für GetAuthenticationToken oder KeyDerivation nach einigen Sanity-Check (Signaturfeld leer? Certificate-Feld leer? etc.) den Hashwert von PublicKeyECIES || Signature || Certificate berechnen und den Hashwert als Abfrageschlüssel für den Cache verwenden. Im Cache-Eintrag kann man dann ebenfalls den Zertifikatstyp aufführen. Damit kann man effizient entscheiden welche Nutzergruppe hier vorliegt (welche Datenstruktur jetzt zu befragen ist) und dann das Certificate-Feld oder Teile daraus im weiteren Verlauf in der entsprechenden Datenstruktur (Bloomfilter, Redis-In-Memory-Datenbank etc.) verwenden.

Hinweis zum Mengengerüst: im Normalfall existierte pro Kasse eine KTR-Identität (KTR-Consumer-Zertifikat), also sehr viel weniger (Faktor > 3000) als LEI-Identitäten (Kontext Dimensierung der damit verbundenere Datenstrukturen).

Erläuterung: Über den Weg der regelmäßig wechselnden Nutzerpseudonyme im HTTP-Header wird es in einer zukünftigen Ausbaustufe des SGDs einem SGD ermöglicht den DoS-Schutz noch effizienter umzusetzen (analog zu gemSpec_Krypt#A_20162). Vgl. auch A_22494.

6.3 Anforderungen an die JSON-Requests und -Responses

Hinweis zu A_17893:

Bei einer Sicherheitsüberprüfung muss u. a. die Validierung von Daten an der Außenschnittstelle betrachtet werden. Dabei unterstützt  .

6.4 Operation GetPublicKey

Tabelle 7: Tab_GetPublicKey-Request

Hinweis zu A_17895-*:

In A_17895-*  steht die Zertifikatsprüfung des im Request enthaltenen Zertifikats nicht in Bezug zu einer Signaturprüfung einer Challenge oder eines durch den Client zu authentisierenden Datums. Damit findet hier keine Authentifizierung statt. Das Aufführen des Zertifikats hat die zwei folgenden Ziele:

1. Es wird damit einem SGD ermöglicht, gutartige (nicht-manipulierte) Requests auf mehrere SGD-HSM bspw. in verschiedenen geographischen Orten (Verfügbarkeitsanforderung) zu verteilen. Denn die in den verschiedenen SGD-HSMs erzeugten ECIES-Schlüsselpaare müssen damit nicht synchronisiert werden.
   Sollte ein Angreifer ein falsches AUT-Zertifikat schicken, so entsteht dadurch kein Sicherheitsproblem.
2. Es wird außerdem einem SGD ermöglicht, vorab eine Zertifikatsprüfung (Einholen der OCSP-Antworten) durchzuführen (diese OCSP-Antworten werden von dem SGD-HSM benötigt). Diese Zertifikatsprüfung muss die RVE asynchron durchführen, d. h. der SGD darf den Client in Bezug auf die Antwort (der aktuelle signierte ECIES-Schlüssel des für den Client "vorgesehenen" SGD-HSMs) nicht warten lassen.

Für weitere Vorgaben und Hinweise in Bezug auf die Zuweisung eines Clients auf ein SGD-HSM aus der Menge der im SGD verfügbaren SGD-HSM durch die RVE vergleiche Abschnitt "4.1 Request-Verarbeitung in einem SGD ". 

Das in A_17896-* definierte Caching von Sperrinformationen ist die lokale Quelle für die OCSP-Informationen, die die RVE an die SGD-HSM sendet (beim Aufruf von GetAuthenticationToken und KeyDerivation). 

Wie in Abschnitt 2.10 Nichtspeicherung von Versichertendaten beschrieben, benötigt ein SGD in Bezug auf die Schlüsselableitungsfunktionalität das AUT-Zertifikat des Nutzers und eine OCSP-Response für dieses Zertifikat. Dies bildet die Grundlage des beidseitig authentisierten verschlüsselten Datenkanals zwischen SGD-HSM und Client (vgl. Abschnitt 9 Datenkanal zwischen Client und SGD (informativ)). Ein SGD darf diese beiden Daten nicht längerfristig speichern (). Andere personenbezogenen Daten fallen bei einem SGD nicht an. Da ein Versicherter immer über das ZGdV eine Datenverbindung zu den beiden SGD aufbaut, erfahren beide SGD nicht die vom Versicherten verwendete IP-Adresse.

6.5 Operation GetAuthenticationToken

Tabelle 8: Tab_GetAuthenticationToken-Request

Implementierungshinweise:

In jedem SGD-HSM eines SGD wird alle 15 Minuten ein neues (S4)-Schlüsselpaar erzeugt. Das zuvor erzeugte (S4)-Schlüsselpaar ist noch 15 Minuten gültig. Damit gibt es pro SGD-HSM im Normalbetrieb (d. h. nachdem der SGD schon mindestens 30 Minuten am Stück arbeitet) genau zwei gültige (S4)-Schlüsselpaare. Da die "PublicKeyECIES"-Schlüssel jeweils an einen öffentlichen (S4)-Schlüssel pro SGD kryptographisch gebunden sind (vgl. A_17900-*) -- und damit auch dessen Signaturprüfung, kann der Cache als Associative Array pro (S4)-Schlüsselpaar in der RVE implementiert werden. Verliert ein alter öffentlicher (S4)-Schlüssel nach 30 Minuten seine Gültigkeit, so kann das mit diesen öffentlichen (S4)-Schlüssel verbundene Associative Array komplett verworfen/gelöscht werden. 

Sollte es der Implementierung dienen, so ist es zulässig, dass der Cache-Mechanismus nach A_22488 pro RZ-Flanke implementiert wird und nicht zwischen den RZ-Flanken synchronisiert wird.

In der PoC-Implementierung hat das Caching der Signaturprüfung eine Geschwindigkeitssteigerung der Signaturprüfung für A_18021-* und A_17898-* um dem Faktor 1.9 bis 17.1 je nach Verteilung der simulierten Anfragen ergeben. D.h., bei 0% Mehrfachableitungen in der Simulation der Anfragen, war fast eine Verdoppelung der Geschwindigkeit der Signaturprüfung erreicht. Diese Steigerung hatte bei 90% Mehrfachableitungen (bspw. kurzzeitige Last bei Quartalsende KTR-Consumer) den Faktor 17.1.

6.6 Operation KeyDerivation

Tabelle 9: Tab_KeyDerivation-Request

Hinweis: für das Caching der Signaturprüfung nach A_17898-* gilt ebenfalls A_22488 aus Abschnitt "6.5 Operation GetAuthenticationToken".

6.7 Fehlermeldungen

Tabelle 10: Tab_Fehlerfälle_und_Fehlermeldungen

Hinweis zu  : In Bezug auf einen Client vgl.   (Aufwärtskompatibilität JSON-Requests und -Responses).

6.7.1 Fehlermeldungen und HTTP-Status-Code (informativ)

Ein SGD besitzt keine RESTful-Schnittstelle. Demnach resultieren Applikationsfehler nicht in Fehlermeldungen des HTTP-Protokolls bei der Applikationsdatenübermittlung. Applikationsfehler erzeugen keine HTTP-Fehler-Codes. Die Applikationsschicht und die darunterliegende HTTP-Schicht werden als separate Sichten im OSI-Schichtenmodell betrachtet.

Dies erleichtert das Tunneln der SGD-Protokollnachrichten (Applikationsebene) bspw. über das Zugangsgateway des Versicherten. 

Die SGD-Schnittstelle hat mit einer RESTful-Schnittstelle die Gemeinsamkeit, dass über HTTP hauptsächlich JSON-Datenstrukturen übertragen werden. Ansonsten gibt es kaum Gemeinsamkeiten.

Beispiel 1, Bit-Flip im Chiffrat im GetAuthenticationToken-Request:
Die RVE erreicht ein GetAuthenticationToken-Request (Nachricht 3 im SGD-Protokoll). Als konstruiertes Beispiel ist dort im Chiffrat ein Bitflip aufgetreten. Dies kann die RVE nicht erkennen. Das für den Client ausgewählte SGD-HSM erkennt dies (AES-GCM als Authenticated Enryption erzeugt ein FAIL bei der Entschlüsselung). Das SGD-HSM übermittelt diese Information an die RVE (Innen-Interface). Die RVE erzeugt dann als Antwort 

{ "Status" : "decryption FAIL" }

gemäß Tabelle Tab_Fehlerfälle_und_Fehlermeldungen  und zwar als Teil der HTTP-Response mit HTTP-Status-Code 200 (OK).

Beispiel 2, ungültige HTTP-Methode verwendet: 
Aus der TI (also ohne Beteiligung des Zugangsgateway des Versicherten) wird ein HTTP-Request an den SGD2 gesendet. Der Client sendet als konstruiertes Beispiel nicht "POST /SGD2 HTTP/1.1" sondern "OST /SGD2 HTTP/1.1" als erste Zeile des HTTP-Requests. Darauf hin antwortet das Webinterface der SGD2 gemäß des HTTP-Protokolls mit HTTP-Status-Code 400 (Bad Request), weil es die Methode „OST“ innerhalb des HTTP-Protokolls nicht gibt.

7 Clientspezifische Festlegungen

Ein ePA-FdV, ein FM ePA und ein KTR-Consumer sind Clients eines SGD.

Verständnishinweis: In  wird die generelle Auswertbarkeit solcher TSL-Einträge auch thematisiert.

Hinweis: Für die Vereinfachung der Parallelisierung für ein ePA-FdV gibt es  .

Erläuterung: A_22494 wird es in einer zukünftigen Ausbaustufe des SGDs einem SGD erleichtern den DoS-Schutz effizienter umzusetzen (analog zu gemSpec_Krypt#A_20162).

Verständnishinweis: Die Vergabe der Telematik-IDs erfolgt durch die LE- und LEI-Organisationen. Nur die ersten drei Zeichen werden durch die Vorgaben aus [gemSpec_PKI#] festgelegt. Damit kann es theoretisch vorkommen, dass dort nach der 3-ten Stelle der Telematik-ID ein ":" vorkommen könnte, was i. d. R. nicht der Fall ist.

Verständnishinweis: sollte der Client keine Antwort (timeout) bspw. vom ZdGV bekommen u. Ä. so darf er die Anfrage mit dem gleichen Schlüsselpaar noch einmal wiederholen. Es geht um die kryptographische Nutzung des Schlüsselpaars, diese darf nur einmal innerhalb eines Protokollablaufs erfolgen. Bei einem folgenden Protokolldurchlauf muss der Client ein neues ECIES-Client-Schlüsselpaar verwenden.

7.1 Mehrfachableitung

Es gibt Anwendungsfälle bei denen ein SGD-Client mehrere Schlüsselableitungen durch einen SGD direkt nacheinander anfordert.

Beispiele:

• Ein ePA-FdV führt eine Umschlüsselung einer Akte mit anschließender Neuberechtigung durch (und damit auch Neuverschlüsselung von Kontext- und Aktenschlüssel für alle Berechtigten).
• Ein ePA-FdV führt einen Aktenumzug mit anschließender Neuberechtigung durch.
• Ein KTR-Consumer möchte zum Quartalsende vielen Versicherten, die den KTR-Consumer zuvor dafür berechtigt haben, Abrechnungsinformationen zukommen lassen (in die Akte einstellen).

Die Anforderung "A_18005, SGD-Client, nur Einmalverwendung des kurzlebigen ECIES-Client-Schlüsselpaars" hat die fachliche Motivation die Frage nach dem Lebenszyklus von sicherheitskritischen Datenobjekten (private kurzlebiger ECIES-Client-Schlüssel und damit verbundenen AuthenticationToken) zu klären und die Implementierung im SGD-Client zu vereinfachen. Das ECIES-Client-Schlüsselpaar wird einmal verwendet und anschließend sofort gelöscht.

In den o. g. Anwendungsfällen ist es jedoch aus Performanz-Sicht wünschenswert die Mehrfachverwendung zuzulassen und damit die Kosten des erhöhten Aufwands bezüglich der Überwachung des Lebenszyklus der sicherheitskritischen Datenobjekte im Client zu tragen (wann wurden sie erzeugt, wie lange sind sie noch gültig, wann müssen neue Schlüssel erzeugt werden ...).

Durch die Mehrfachableitung sind für einen SGD-Client nach A_22497-* nicht mehr 6 * (Anzahl der abzuleitenden Schlüssel) SGD-Nachrichten notwendig, sondern nur noch 4 + 2*(Anzahl der abzuleitenden Schlüssel) SGD-Nachrichten.

Für die Verbesserung der UX in einem ePA-FdV wird die Mehrfachableitung dort vorgeschrieben.

Erläuterung:

Die ECIES-SGD-Client-Schlüssel werden im ePA-FdV zufällig erzeugt und jeweils die öffentlichen Schlüssel der ECIES-SGD-Client-Schlüsselpaare werden mit aktuellen gültigen (S4)-Schlüssel eines SGD1 und eines SGD2 (über deren Hashwerte) durch eine Signatur auf Grundlage einer eGK oder einer al.vi-Identität gebunden (vgl. Abschnitt "5.1.2 ECIES-Schlüssel eines Clients").

Beispiel eines öffentlichen ECIES-SGD-Client-Schlüssels nach A_17900-*:

"brainpoolP256r1 " +
"0x3672030bace787aa319e21d40645b2999006beec437fd084dd3fc592f5fcd77c" + " " +
"0x335b226ce5fac0c36a18ce42e95f43c9eed3e256bdd0c98e55a069595515d15b" + " " +
"a3a56e51377c1de0bea0522eba3ec6277e3355edb67d48b9852ab7d7e536feb7" + " " +
"8b2405f41cebaf44d10b2c9025484515b005be5ba785d0c898eae0739a67eb5a"

Diese Kodierung wird mittels einer eGK oder einer al.vi-Identität signiert. 

Nach Konstruktion ist die Nutzung dieses authentisierten öffentlichen ECIES-SGD-Client-Schlüssels und dem dazugehörigen privaten Schlüssel begrenzt durch die Gültigkeitsdauern der (S4)-Schlüssel (vgl. die Hashwerte im Beispiel (vorletzte und letzte Datenelemente)). Diese (S4)-Schlüssel sind -- technisch in den SGD durchgesetzt -- minimal 15 Minuten gültig und maximal etwas weniger als 30 Minuten. Ein ePA-FdV geht nach A_23617 davon aus, dass es gegen Ende einer Gültigkeit der (S4)-Schlüssel diese von den SGD bezogen hat (also konservativer Ansatz). Die Nutzbarkeit ist damit noch 15 Minuten. Die "Zeit-Information" (A_23617-*) stellt die Startzeit der Verwendbarkeit dar und ermöglicht einem ePA-FdV festzustellen, ob zum Zeitpunkt der Schlüsselnutzung die 15 Minuten schon abgelaufen sind oder nicht.

8 Interoperables Austauschformat

Damit die Interoperabilität zwischen Clienten eines SGD (ePA-FdV, FM ePA etc.) sichergestellt ist, wird nachfolgend ein interoperables Austauschformat definiert. Zunächst wird mit PHRKey [PHR_Common.xsd] eine Datenstruktur für die Klartextrepräsentation von Kontextschlüssel (ContextKey) und Aktenschlüssel (RecordKey) definiert. Daran folgt die Definition der Datenstruktur EncryptedKeyContainer [AuthorizationService.xsd].

Tabelle 11: Tab_Austauschformat_Akten-_und_Kontextschlüssel

Vergleiche auch [PHR_Common.xsd]

Diese XML-Datenstruktur muss nun mittels des vom SGD 1 abgeleiteten spezifischen Schlüssels verschlüsselt werden (vgl.  ) und zusätzlich muss noch der Rückgabewert nach "OK-Derivation " als "associated data" mit in die MAC-Berechnung bei der AES-GCM-Verschlüsselung und GMAC-Berechnung einfließen. Das Ergebnis muss in einer EncryptedKeyContainer-XML-Datenstruktur kodiert werden, die folgende Form besitzt (vgl. auch Schemadatei  [AuthorizationService.xsd]):

Tabelle 12: Tab_erste_Verschlüsselungsschicht

Diese Daten werden dann mit dem zweiten AES-256-Schlüssel (erhalten von SGD 2) verschlüsselt und es muss wieder eine derartige Datenstruktur erzeugt werden. Jedoch müssen bei den AD nun die AD aus der ersten Verschlüsselungsschicht  (AD1) mit einbezogen werden. Dafür werden die AD1 (Base64-dekodiert) vor die Ableitungsinformationen, die durch SGD 2 hinzukommen, vorangestellt und damit zusammengefügt. Die MAC-Berechnung basiert dann auf dieser zusammengesetzten Zeichenkette. Im "<epa:AssociatedData>"-Feld werden die beiden Teile (Ableitungsinformationen von SGD 1 und Ableitungsinformationen von SGD 2) jeweils einzeln Base64-kodiert und durch Leerzeichen getrennt aufgeführt.

Beispiel für ein AssociatedData einer zweiten Verschlüsselungsschicht:

<epa:AssociatedData>
cjI6N2Y4Zjc3MDAzZGJhYjQ5YzNhNGUzMmY0NDcyNmY5MjMyNGQyOTJmYTY2OGZkZTVlYmMzNDI0Mzk3OTg2YmU5OTpBMTIzNDU2Nzg5OjItMjBhMTIwMS0wMDE6QWt0ZW5zeXN0ZW0gYSwgU0dEMSwgQmV6ZWljaG5lciAyMDIwLTE= 
cjI6NWQ2MWQyZTExNTJiNjcxMWJlOTg0OTZjZDZmMGM5YWJkZTRjYzNiMzIwYjRiYWYxMjc2ZTU1MmFhZGU4MDkxMzpBMTIzNDU2Nzg5OjItMjBhMTIwMS0wMDE6U0dEMiBNYXN0ZXJrZXkgMjAyMC0x
</epa:AssociatedData>

Damit kann ein Client die Ableitungsinformationen von SGD 1 (erster Teil) und von SGD 2 (zweiter Teil) unterscheiden.

Beispiel: Schritt 1, im Client (bspw. ePA-FdV) liegen zufällig lokal erzeugte Akten- und Kontextschlüssel vor, welche in einer PHRKey-Datenstruktur kodiert werden. Der Versicherte habe die KVNR "A123456789".

<?xml version="1.0" encoding="UTF-8">
<epa:PHRKey insurant="A123456789">

    <!-- Aktenschlüssel -->
    <RecordKey algorithm="http://www.w3.org/2009/xmlenc11#aes256-gcm">
        Nj9OixvhO2JKjtYEbQe8oetiQaiennKFJmQEJXsQVQo=
    </RecordKey>

    <!-- Kontextschlüssel -->
    <ContextKey algorithm="http://www.w3.org/2009/xmlenc11#aes256-gcm">
        qyVQMtj3MwXRt8NOuQrNj3g5IPl49Ieami/+QVLzTkc=
    </ContextKey>

</epa:PHRKey>

Beispiel: Schritt 2, Erzeugung der ersten Verschlüsselungsschicht

Sei

3132333435363738393031323334353637383930313233343536373839303132

der von dem SGD 1 erhaltene hexadezimal-kodierte 256-Bit AES/GCM-Schlüssel und der verwendete Ableitungsvektor des SGD 1 sei "r2:7f8f77003dbab49c3a4e32f44726f92324d292fa668fde5ebc3424397986be99:A123456789:2-20a1201-001:Aktensystem a, SGD1, Bezeichner 2020-1", dann würde folgende EncryptedKeyContainer-Datenstruktur entstehen.

<?xml version="1.0" encoding="UTF-8">
<epa:EnryptedKeyContainer algorithm="http://www.w3.org/2009/xmlenc11#aes256-gcm">
    <epa:Ciphertext>        n9G9sp+Sw1KTbKGjmugnqVyC82pUSlE8GJMq4I316zNqHPZy6/nIgXpJcZ7EI2jmHYjrLm/FyWUtbocYYUm8JQCmsWHWU+76gvJyDMwi1XsAj4fgbn/pH0/9XgDcXK905gH4IGD18Z54A3iChuwj6gGvhX5HpS54YH4QuAGiE5ZPFhlKWx2GkYvn4h5kFzM/Z0n7Lg3Txw/dpb6yp4mTGKX1KTWqt3aRUkdSQ05GR4i1PvZB8A4MDaLGo3Tgs1rD2n7ay7D3ZErulsMKK7CDjyHEWmADLBLmT+FDmu9micg+JI4jSaYXsYZYMn99HYi47D0DCUPS7fDDh1iNpkignczP44pHGbnujgnqcr/e42itRWISt0A0d2guNYAXPrrmtJTiOkYfr9Lhx9ttGRHWwcmH8j5+c+RGJdYFW55pSrGWlJ1n5DBsHqf6B+aWp6FWjH+SsQ5OBjkqGWAEggxaZlJMH8oFP+Yk5d0Zdt+TDQgA2UQynxZ/dLqthTjb67vRzWbTtbUGhxOpvdoc6APJZVuB0zjcLMpgKmF6A8SuS4UkaTvzjA40iJXDV3S2xgDmT08UfmWYwsRstifbTNcWNiKNCCFm0I8kqNZIKujv/Ws=
    </epa:Ciphertext>
    <epa:AssociatedData>        cjI6N2Y4Zjc3MDAzZGJhYjQ5YzNhNGUzMmY0NDcyNmY5MjMyNGQyOTJmYTY2OGZkZTVlYmMzNDI0Mzk3OTg2YmU5OTpBMTIzNDU2Nzg5OjItMjBhMTIwMS0wMDE6QWt0ZW5zeXN0ZW0gYSwgU0dEMSwgQmV6ZWljaG5lciAyMDIwLTE=
    </epa:AssociatedData>
</epa:EncryptedKeyContainer>

Beispiel: Schritt 3, Erzeugung der zweiten Verschlüsselungsschicht

Sei

4132333435363738393031323334353637383930313233343536373839303132

der von dem SGD 2 erhaltene hexadezimal-kodierte 256-Bit AES/GCM-Schlüssel und der verwendete Ableitungsvektor des SGD 2 sei "r2:5d61d2e1152b6711be98496cd6f0c9abde4cc3b320b4baf1276e552aade80913:A123456789:2-20a1201-001:SGD2 Masterkey 2020-1", dann würde folgende EncryptedKeyContainer-Datenstruktur der zweiten Verschlüsselungsschicht entstehen.

<?xml version="1.0" encoding="UTF-8">
<epa:EnryptedKeyContainer algorithm="http://www.w3.org/2009/xmlenc11#aes256-gcm">
    <epa:Ciphertext>        wQgFhfzTeeTAYsR2JHChPoqO0In5QCa+ZnH2+0cPYtO+MAi4jfqUrHAHsj1RLqjDoEF6QdN8gjQq8x03dpsx6EJJZzwg0I8Y+c/ck+vANMNxxNclU2s5DJZQ52wGKnQVtMOIQPtNiRKv3c+YV8nMXJKKZrF+laG+4bdmeWhT9BIi1dhev+Sm9vvZQQ9/lI+o18qKWYgBje/L5f7EQEQJzG2t+zWDpPVmPZtCo+0/MKa/rZo6a20iXSeWov6FGe/7S60D4HaaYp66z9IveWH1qd80KUz8wGaI4c/ZO5qGwQBv8puBFNxm6mYPCarGsIeltwunmsh4L+bQmbIf/X/AFEfq+hu9lN7B/v3mgyk7Za+vPpTKuf9EeaC/RDr8nfQVO46Evtqj04vqPlmAI9SsCUpgiR5JwXwQwWtLABJBDr9+us1LfWq4tlIFwslllUZP1B+oSaO59bK//Hu7097mKVI4tIsA5D1/a9de9BgBZ1RblK/roKUe38cbuSFYPHNrPhScycIX3fyd6lOqX56vkvOOsS+E2rbQXUw/JipRGdoS1mhu5pQMJKgAojYm6JKHmKb0ydDopUxltX5Gsv2KMTDyRFaxcGDvavlgVV088bs8dc6UyOjWZRGtKbyNavMLCl3vClwfKyc6rsD9Wc4G4Mp2KadF63icOfePy0F234ktbDUXFiiB391to2x2u4VvTOsDBlD9A7zJYm7Xf+cK3S3J0/RgwdbabxV/eGtKcH12Xmi2RUDuIEHjF4u1CnQFREC2DAq+1gtA6Q7iVCRbESH6toNwMtd2Z/hssv+moM1NEuE3ONb+pf7z26ScTGDVKuN6WmldSi/2CvkD3j4aY38Uzu5sGGDXG0mZrDCzmPH8WntGnrInibVBRRXz0IuQIMgB56tNcPjgvBOhlWCXL92PcrbuJyhRA1mKqLYsAOkfLsXjC1es6NS7EUYb1RACVqNa8bZGqHY6snou2xa6jReH4uC7Qvx4Yr1rkTEnlahNUYUHMYGyhObef/seNxz36Ppv7+BVURe0jaD8WFA9zeQ2X3rDKPU6eU4urmgBtCVOZ1Jxd2z2twOlAx7oQQMq5wsRM2Q4RKOk28aJFcLBhIquNaXUHs6pVuHPEfUVQiyU1cGQ0Hgizj800f18sTiyX8lgFv0/WIw0ol4MUZ8jQhZ+o29bV5OBH36ebDERZJl1eRhe5nPDPJfSIvo+/LiTmlmgEIiTYtaEcWH+7Z9xrxCuE75+RLJfv5GydCsFETpMcpWcyYPP/XHj5O3jL7urpgXxYsAap8UXOkIrcsV+qhRsQG+pe3lqvGodhtkm4i7mbu3Rm9noAKB34DWUO9Sg14JGl4CxhGzhlN4bUqnVd8GYirDinqGot9MQ40tKD3sQ8d1A2qdW4weIKAeKopJ6X4t7iRAFp4ka6vqgmb1KxCXLl2hO3J1bhY8FZ1Q=
    </epa:Ciphertext>
    <epa:AssociatedData>        cjI6N2Y4Zjc3MDAzZGJhYjQ5YzNhNGUzMmY0NDcyNmY5MjMyNGQyOTJmYTY2OGZkZTVlYmMzNDI0Mzk3OTg2YmU5OTpBMTIzNDU2Nzg5OjItMjBhMTIwMS0wMDE6QWt0ZW5zeXN0ZW0gYSwgU0dEMSwgQmV6ZWljaG5lciAyMDIwLTE= cjI6NWQ2MWQyZTExNTJiNjcxMWJlOTg0OTZjZDZmMGM5YWJkZTRjYzNiMzIwYjRiYWYxMjc2ZTU1MmFhZGU4MDkxMzpBMTIzNDU2Nzg5OjItMjBhMTIwMS0wMDE6U0dEMiBNYXN0ZXJrZXkgMjAyMC0x
    </epa:AssociatedData>
</epa:EncryptedKeyContainer>

Hinweis: in der Beispiel-Implementierung der Außenschnittstelle (vgl. Abschnitt 6 Schnittstellen und Operationen) gibt es auch Beispiel-Code für das interoperable Austauschformat.

9 Datenkanal zwischen Client und SGD (informativ)

Wie in Abschnitt "2.11 Besondere Rolle SGD-HSM" erwähnt, ist es notwendig, die fachlichen Abläufe für das SGD-HSM so einfach wie möglich zu gestalten. Einerseits kann man so die notwendige Performanz erreichen und andererseits wird damit der zeitliche Aufwand für die Entwicklung und Sicherheitsüberprüfung () des SGD-HSM-Firmwaremoduls deutlich reduziert.

Das SGD-HSM erbringt den Hauptteil der Sicherheitsleistung, wobei eine unbemerkte Manipulation des Betreibers mit hoher Sicherheit ausgeschlossen werden kann. 

Ziel der Datenübertragung zwischen Client und SGD ist es, einen beidseitig authentisierten Ende-zu-Ende-verschlüsselten Kanal zwischen Client und SGD-HSM zu erzeugen. Auf diesem Kanal wird dann die authentisierte Anfrage nach einer Schlüsselableitung vom Client an das SGD-HSM gesendet.

Weil ein SGD-HSM alle 15 Minuten ein neues ECIES-Schlüsselpaar erzeugt (und per Signatur bestätigt A_17910-01  (S1)) und der Hashwert des öffentlichen Schlüssels des ECIES-Schlüssels des SGD-HSMs in die Client-Signatur für den öffentlichen ECIES-Client-Schlüssel nach  mit eingeht, kann ein SGD-HSM sich über eine ausreichende Frische (vgl. [Boyd-Mathuria-2003#Abschnitt "1.5 Freshness"]) der Client-Anfrage sicher sein. Insbesondere kann ein SGD-HSM davon ausgehen, dass die für die Signatur mittels des AUT-Materials beim Client notwendige Kontrolle über den privaten AUT-Schlüssel im Client vorhanden war.

9.1 Ablauf Kommunikation zwischen Client und SGD-HSM

Ein Client sendet über das HTTPS-Interface des SGD Requests an einen SGD. Falls der Client ein ePA-FdV ist, werden die (in den wesentlichen Teilen verschlüsselten) Request über das ZGdV getunnelt. Zwischen Client und SGD-HSM gibt es auf Applikationsebene eine beidseitig authentisierte und verschlüsselte Datenverbindung. Um dies zu erreichen, führt ein Client die in diesem Abschnitt aufgeführten Schritte durch.

Zunächst erfragt der Client den aktuellen signierten öffentlichen ECIES-Schlüssel bei SGD 1.

Ein SGD-HSM generiert unabhängig vom konkreten Request alle 15 Minuten ein neues ECIES-Schlüsselpaar (A_17914-01 ) für die Absicherung der späteren Transportverschlüsselung zwischen Client und SGD-HSM. Der öffentliche ECIES-Schlüssel wird vom SGD-HSM signiert (A_17914-01 ) und an die RVE übergeben (A_17914-01 ).

Der Client erfragt parallel () analog bei SDG 2 den aktuellen ECIES-Schlüssel des für ihn avisierten SGD-HSMs innerhalb von SGD 2. Sind beide ECIES-Schlüssel erfolgreich geprüft ( ), kann der Client fortfahren. Er fragt beide SGD, parallel () wie folgt an.

Der Client erzeugt ein ECIES-Schlüsselpaar, das er für die Request an beide SDG verwendet ( ).

Ein Client kann sich sicher sein, dass nur das angefragte SGD-HSM seine Nachricht und damit die Challenge entschlüsseln kann (gemeinsames Geheimnis). Das SGD-HSM entschlüsselt die Nachricht. An dieser Stelle weiß das SGD-HSM noch nicht, ob die Challenge auch von dem im Request (dort im AUT-Zertifikat) behaupteten Kommunikationspartner kommt – mit wem er genau also dieses gemeinsame Geheimnis teilt. Das SGD-HSM nimmt zunächst an, dass die Angaben stimmen. Es erzeugt ein Authentisierungstoken (A_18026-*). Das Authentisierungstoken ist spezifisch für das AUT-Zertifikat und den öffentlichen Client-ECIES-Schlüssel inkl. Hashwerte (Kodierung nach  ). Das SGD-HSM bildet den Hashwert aus der Kodierung und dem präsentierten AUT-Zertifikat. Das SGD-HSM bildet die Antwort gemäß A_18026-*  

1. mit dem Challenge-Wert (gemeinsames Geheimnis),
2. dem eben erzeugten Hashwert und
3. dem Authentisierungstoken.

Diese Antwort verschlüsselt das SGD-HSM für den Client-ECIES-Schlüssel. Das SGD-HSM kann sich sicher sein, dass nur der Empfänger, also derjenige der privaten Client-ECIES-Schlüssel besitzt, die Nachricht entschlüsseln kann.

Der Client kann als einziger diese Antwort entschlüsseln. Er prüft, ob seine Challenge (gemeinsames Geheimnis) in der Antwort enthalten ist. Falls ja kann die Antwort nur vom SGD-HSM kommen. Der Client fügt den kodierten Client-ECIES-Schlüssel (vgl. in der Antwort aufgeführten Wert übereinstimmt (Hashwert,   ). Falls alle Prüfungen erfolgreich waren, kann der Client das in der Antwort aufgeführte Authentisierungstoken verwenden.

Die Schritte 3 bis 13 führt ein Client dann parallel für beide SGD aus.

9.2 ECIES-Verfahren

Das "Elliptic Curve Integrated Encryption Scheme (ECIES)" ist ein auf [ABR-1999] basierendes hybrides Verschlüsselungsverfahren (vgl. auch [SEC1-2009], [TR-02102-1]). Das Verfahren liefert eine einseitig authentisierte Verschlüsselung. Eine Änderung am Chiffrat wird vom Empfänger sicher erkannt (CCA2-sicher). Der Empfänger kann auf Grundlage des ECIES-Verfahrens allein nicht erkennen von wem das Chiffrat erzeugt wurde, nur dass es beim Transport nicht verändert wurde. Der Sender kann sich sicher sein, dass nur der Empfänger das Chiffrat entschlüsseln kann. Für das ECIES-Verfahren gilt die kryptographische Sicherheitsbetrachtung (Sicherheitsbeweis) aus [ABR-1999].

Der Sender muss ein ECC-Schlüsselpaar besitzen, dessen Authentizität der Empfänger prüfen kann ( und A_18026-*

). Der Empfänger erzeugt für jede Nachricht ein ephemeres ECC-Schlüsselpaar ([gemSpec_Krypt# Punkt 1]) . Mit dem Schlüsselpaar und den authentischen öffentlichen ECC-Punkts des Empfänger führt der Sender einen einseitig authentisierten ECDH durch [gemSpec_Krypt# Punkt 2]. Aus dem erzeugten ECDH-Geheimnis leitet der Sender über eine KDF gemäß [gemSpec_Krypt# Punkt 3] einen 256-Schlüssel ab. Diesen Schlüssel verwendet der Sender mittels AES-GCM gemäß [gemSpec_Krypt# Punkt 4] um die Nachricht zu verschlüsseln. Da AES-GCM ein authentisiertes Verschlüsselungsverfahren ist, kann man Änderungen beim Transport des Chiffrats (ICV-Wert) sicher erkennen. Ob ein aktiver Angreifer auf der Transportstrecken das Chiffrat verworfen und selbst ein neues erzeugt hat, kann das Verfahren nicht feststellen.

Das ECIES-Verfahren wird üblicherweise bei der ECC-basierten E-Mail-Verschlüsselung eingesetzt, so dass man aus kryptographischer Sicht formulieren könnte: Client und SGD-HSM senden sich im Rahmen der Schlüsselableitungsfunktionalität ePA vier verschlüsselte E-Mails pro Schlüsselableitung.

10 Anhang – Verzeichnisse

10.1 Abkürzungen

10.2 Glossar

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

10.3 Abbildungsverzeichnis

10.4 Tabellenverzeichnis

10.5 Referenzierte Dokumente

10.5.1 – Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummer entnehmen Sie der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte, in der die vorliegende Version aufgeführt wird.

10.5.2 – Weitere Dokumente