Elektronische Gesundheitskarte und Telematikinfrastruktur

 

 

 

Übergreifende Spezifikation

Verwendung kryptographischer Algorithmen in der
Telematikinfrastruktur

 

   

Version	2.2829.10
Revision	857707833972
Stand	23.02.2024Wert nicht konfiguriert
Status	freigegeben
Klassifizierung	öffentlich
Referenzierung	gemSpec_Krypt

 

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

Dokumentinformationen

Inhaltsverzeichnis

1 Einführung

1.1 Zielsetzung und Einordnung des Dokuments

1.2 Zielgruppe

1.3 Geltungsbereich

1.4 Abgrenzung des Dokuments

1.5 Methodik

2 Einsatzszenarioübergreifende Algorithmen

2.1 Identitäten

2.1.1 X.509-Identitäten

2.1.1.1 Digitale nicht-qualifizierte elektronische Signaturen

2.1.1.2 Qualifizierte elektronische Signaturen

2.1.1.3 TLS-Authentifizierung

2.1.1.4 IPsec-Authentifizierung

2.1.1.5 Digitale Signaturen durch TI-Komponenten

2.1.1.6 Verschlüsselung

2.1.2 CV-Identitäten

2.1.2.1 CV-Zertifikate G2

2.1.2.2 CV-Certification-Authority (CV-CA) Zertifikat G2

2.2 Zufallszahlengeneratoren

2.3 Hilfestellung bei der Umsetzung (Zufallsgeneratoren)

2.4 Schlüsselerzeugung und Schlüsselbestätigung

2.4.1 Prüfung auf angreifbare (schwache) Schlüssel

2.4.2 ECC-Schlüssel in X.509-Zertifikaten

2.4.3 RSA-Schlüssel in X.509-Zertifikaten

2.5 Einmalpasswörter

3 Konkretisierung der Algorithmen für spezifische Einsatzszenarien

3.1 Kryptographische Algorithmen für XML-Dokumente

3.1.1 XML-Signaturen für nicht-qualifizierte Signaturen

3.1.2 XML-Signaturen für qualifizierte elektronische Signaturen

3.1.3 Webservice Security Standard (WSS)

3.1.4 XML-Verschlüsselung – Symmetrisch

3.1.5 XML-Verschlüsselung – Hybrid

3.2 Karten-verifizierbare Authentifizierung und Verschlüsselung

3.2.1 Card-to-Card-Authentisierung G2

3.2.2 Card-to-Server (C2S) Authentisierung und Trusted Channel G2

3.3 Netzwerkprotokolle

3.3.1 IPsec-Kontext

3.3.2 TLS-Verbindungen

3.3.3 DNSSEC-Kontext

3.4 Masterkey-Verfahren (informativ)

3.5 Hybride Verschlüsselung binärer Daten

3.5.1 Symmetrischer Anteil der hybriden Verschlüsselung binärer Daten

3.5.2 Asymmetrischer Anteil der hybriden Verschlüsselung binärer Daten

3.6 Symmetrische Verschlüsselung binärer Daten

3.7 Signatur binärer Inhaltsdaten (Dokumente)

3.8 Signaturen innerhalb von PDF/A-Dokumenten

3.9 Kartenpersonalisierung

3.10 Bildung der pseudonymisierten Versichertenidentität

3.11 Spezielle Anwendungen von Hashfunktionen

3.11.1 Hashfunktionen und OCSP (informativ)

3.12 kryptographische Vorgaben für die SAK des Konnektors

3.13 Migration im PKI-Bereich

3.14 Spezielle Anwendungen von kryptographischen Signaturen

3.15 ePA-spezifische Vorgaben

3.15.1 Verbindung zur VAU

3.15.2 Vorgaben für ePA-Schlüssel und ePA-ChiffrateePA-Aktensysteminterne Schlüssel

3.15.3 ePA-Aktensysteminterne Schlüsselspezifische TLS-Vorgaben

3.15.4 ePA16 E-Rezept-spezifische TLS-Vorgaben

3.15.5 Schlüsselableitungsfunktionalität ePA17 KOM-LE-spezifische Vorgaben

3.16 E-Rezept-spezifische Vorgaben18 HMAC-Sicherung der Prüfziffer VSDM

3.17 KOM-LE-19 spezifische TLS-Vorgaben für VSDM

3.18 HMAC-Sicherung der Prüfziffer VSDM4 Umsetzungsprobleme mit der TR-03116-1

34.19 spezifische TLS-Vorgaben für VSDM1 XMLDSig und PKCS1-v2.1

4 Umsetzungsprobleme mit der TR-03116-1.2 XMLEnc: Die Nutzung von RSAES-OAEP und AES-GCM

4.1 XMLDSig und PKCS1-v2.13 XML Signature Wrapping und XML Encryption Wrapping

4.2 XMLEnc: Die Nutzung von RSAES-OAEP und AES-GCM4 Güte von Zufallszahlen

4.3 XML Signature Wrapping und XML Encryption Wrapping5 Migration 120-Bit-Sicherheitsniveau

45.4 Güte von Zufallszahlen1 PKI-Begriff Schlüsselgeneration

5 Migration 120-Bit-Sicherheitsniveau.2 X.509-Root der TI

5.1 PKI-Begriff Schlüsselgeneration3 TSL-Dienst und ECDSA-basierte TSL allgemein

5.2 X.509-Root der TI4 ECC-Unterstützung bei TLS

5.3 TSL-Dienst und ECDSA-basierte TSL allgemein5 ECC-Unterstützung bei IPsec

5.4 ECC-Unterstützung bei TLS6 ECDSA-Signaturen

5.5 ECC-Unterstützung bei IPsec6.1 ECDSA-Signaturen im XML-Format

5.6.2 ECDSA-Signaturen im CMS-Format

5.6.1 ECDSA-Signaturen im XML-Format7 ECIES

5.67.2 ECDSA-Signaturen im CMS-Format1 ECIES und authentisierte Broadcast-Encryption

5.7.2 ECIES und mobKT

5.7.1 ECIES und authentisierte Broadcast-Encryption8 ECC-Migration eHealth-KT

5.78.2 ECIES und mobKT1 Interoperabilität zwischen eHealth-KT und Konnektor

5.89 ECC-Migration eHealth-KTKonnektor

5.8.1 Interoperabilität zwischen eHealth-KT und Konnektor10 Verschiedene Produkttypen und ECC-Migration (informativ)

5.9 ECC-Migration Konnektor6 VAU-Protokoll für E-Rezept

56.10 Verschiedene Produkttypen und ECC-Migration1 Übersicht (informativ)

6 Kommunikationsprotokoll zwischen ePA-VAU und ePA-Clients.2 Definition

6.1 Motivation2.1 E-Rezept-VAU-Identität

6.2 Übersicht.2 Client-seitige Prüfung der E-Rezept-VAU-Identität

6.3 VAUClientHello-Nachricht2.3 E-Rezept-VAU-Request und -Response

6.4 VAUServerHello-Nachricht2.4 Zufallsquelle für Clients

6.5 Schlüsselableitung7 VAU-Protokoll für ePA für alle

67.6 VAUClientSigFin-Nachricht1 Übersicht Verbindungsaufbau/Schlüsselaushandlung

6.7 VAUServerFin-Nachricht.2 Transport und Sicherung der Nutzdaten

67.8 Nutzerdatentransport3 OIDC-Authentisierung eines Clients (Nutzer)

67.9 VAUServerError-Nachricht4 Authentisierung des E-Rezept-FD als ePA-Client

67.10 Abbrechen des Protokollablaufs5 Routing auf VAU-Instanzen

67.11 VAU-Kanal und MTOM/XOP6 Fehlersignalisierung

67.12 Zusätzliche HTTP-Header-Informationen7 Tracing in Nichtproduktivumgebungen

67.13 Tracing in Nichtproduktivumgebungen7.1 Zufallsquelle für Clients

6.14 Optionale PQC-Erweiterung8 Post-Quanten-Kryptographie (informativ)

7 Kommunikationsprotokoll zwischen E-Rezept-VAU und E-Rezept-Clients9 Erläuterungen (informativ)

79.1 Übersicht (informativ)Prüfung auf angreifbare (schwache) Schlüssel

7.2 Definition9.2 RSA-Schlüssel in X.509-Zertifikaten

7.2.1 E-Rezept-VAU-Identität10 Anhang – Verzeichnisse

710.2.2 Client-seitige Prüfung der E-Rezept-VAU-Identität1 Abkürzungen

710.2.3 E-Rezept-VAU-Request und -Response Glossar

710.2.4 Zufallsquelle für Clients3 Abbildungsverzeichnis

8 Post-Quanten-Kryptographie (informativ)10.4 Tabellenverzeichnis

9 Erläuterungen (informativ)10.5 Referenzierte Dokumente

910.1 Prüfung auf angreifbare (schwache) Schlüssel5.1 Dokumente der gematik

910.2 RSA-Schlüssel in X.509-Zertifikaten5.2 Weitere Dokumente

10 Anhang – Verzeichnisse

10.1 Abkürzungen

10.2 Glossar

10.3 Abbildungsverzeichnis

10.4 Tabellenverzeichnis

10.5 Referenzierte Dokumente

10.5.1 Dokumente der gematik

10.5.2 Weitere Dokumente

1 Einführung

1.1 Zielsetzung und Einordnung des Dokuments

Die vorliegende übergreifende Spezifikation definiert Anforderungen an Produkte der TI bezüglich kryptographischer Verfahren. Diese Anforderungen sind als übergreifende Regelungen relevant für Interoperabilität und Verfahrenssicherheit.

Für die TI ist die Technische Richtlinie 03116 Teil 1 [BSI-TR-03116-1] normativ, d. h. nur dort aufgeführte kryptographische Verfahren dürfen von Produkten in der TI verwendet werden. Wenn mehrere unterschiedliche Produkttypen der TI zusammenarbeiten ist es bez. der Interoperabilität nicht sinnvoll wenn jeder beteiligte Produkttyp alle dort aufgeführten Verfahren umsetzen muss, da er vermuten muss, die Gegenstelle beherrscht nur eine Teilmenge der dort aufgeführten Verfahren. Um einen gemeinsamen Nenner zu definieren, legt dieses Dokument für bestimmte Einsatzzwecke ein Mindestmaß an verpflichtend zu implementierenden Verfahren aus [BSI-TR-03116-1] fest, oftmals mit spezifischen Parametern. Ein Produkttyp ist frei, weitere Verfahren aus der [BSI-TR-03116-1] optional zu implementieren, kann sich jedoch nicht ohne Weiteres darauf verlassen, dass sein potentieller Kommunikationspartner diese auch beherrscht.

In Bezug auf die Formulierung der Ende-Daten der Zulässigkeit eines kryptographischen Verfahrens wird die Konvention aus der TR-02102- und der TR-03116-Familie verwendet, d. .h., eine Aussage „Algorithmus X ist geeignet bis Ende 2029+“  bedeutet generell nicht, dass Algorithmus X nach Ende 2029 nicht mehr geeignet ist, sondern lediglich, dass über die Eignung nach Ende 2029 keine explizite Aussage gemacht wird und dass aus heutiger Sicht die weitere Eignung nicht ausgeschlossen ist. Aussagen über den Betrachtungszeitraum hinaus sind mit einem höheren Maß an Spekulation verbunden. Sollte bei den Angaben zum Ende der zeitlichen Zulässigkeit kein "+" aufgeführt sein (bspw. "Ende 2025") , so bedeutet dies, dass eine Verlängerung der Zulässigkeit über den aufgeführten Zeitpunkt hinaus nicht geplant ist. 

Bei neuen Erkenntnissen über die verwendeten kryptographischen Algorithmen, die zu einer Änderung der TR-03116-1 führen, wird eine Anpassung dieses Dokumentes erfolgen. Für Verwendungszwecke, bei denen bereits eine Migration zu stärkeren Algorithmen in Planung ist oder die Verwendung von Algorithmen unterschiedlicher Stärke zulässig ist, wird ein Ausblick gegeben, bis wann welche Algorithmen ausgetauscht sein müssen. Bei den Migrationsstrategien für kryptographische Algorithmen ist darauf zu achten, dass hinterlegte Objekte umzuschlüsseln sind bzw. die älteren Algorithmen (unter der Bedingung, dass sie sicherheitstechnisch noch geeignet sind) für eine gewisse Übergangsphase weiter unterstützt werden müssen und danach zuverlässig in den Komponenten deaktiviert werden müssen.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter von Produkten der TI, die kryptographische Objekte verwalten.

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.

Schutzrechts-/Patentrechtshinweis

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

1.4 Abgrenzung des Dokuments

Aufgabe des Dokumentes ist es nicht, eine Sicherheitsbewertung von kryptographischen Algorithmen vorzunehmen. Dieser Gesichtspunkt wird in [BSI-TR-03116-1] behandelt. Es werden lediglich die dort vorgegebenen Algorithmen weiter eingeschränkt, um die Herstellung der Interoperabilität zu unterstützen.

Es ist nicht Ziel dieses Dokumentes, den Prozess zum Austauschen von Algorithmen zu definieren, sondern lediglich den zeitlichen Rahmen für die Verwendbarkeit von Algorithmen festzulegen und somit auf den Bedarf für die Migration hinzuweisen.

1.5 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC-2119] 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 Einsatzszenarioübergreifende Algorithmen

Nachfolgend werden grundlegende Festlegungen zur Verwendung von Algorithmen innerhalb der Telematikinfrastruktur getroffen. Diese Anforderungen sind unabhängig von den im nachfolgenden Kapitel definierten Einsatzszenarien und werden durch diese verwendet.

GS-A_3080 - asymmetrischen Schlüssel maximale Gültigkeitsdauer

Die Lebensdauer von asymmetrischen Schlüsseln und somit die in einem Zertifikat angegebene Gültigkeitsdauer SOLL maximal 5 Jahre betragen.

 [<=]

2.1 Identitäten

Der Begriff „kryptographische Identität“ (nachfolgend nur noch als Identität bezeichnet) bezeichnet einen Verbund aus Identitätsdaten und einem kryptographischen Objekt, das bspw. im Rahmen einer Authentisierung und Authentifizierung verwendet werden kann. Im Allgemeinen handelt es sich um Schlüsselpaare, bestehend aus öffentlichem und privatem Schlüssel, sowie einem Zertifikat, das die Kombination aus Attributen und öffentlichem Schlüssel durch eine übergeordnete Instanz (CA – Certification Authority) bestätigt.

Bei den Algorithmenvorgaben für Identitäten muss u. a. spezifiziert werden:

• für welche Algorithmen und für welchen Verwendungszweck die Schlüssel verwendet werden (Bestimmte Verwendungszwecke schließen einander aus, bspw. dürfen nicht Signaturschlüssel für die Sicherung von Authentizität und Integrität von Dokumenten als Signaturschlüssel für beliebige Challenges im Rahmen einer Authentisierung verwendet werden.),
• welche Algorithmen für die Signatur des Zertifikates verwendet werden,
• mit welchen Algorithmen die OCSP-Responses signiert werden und
• wie die Zertifikate des OCSP-Responders signiert sind.

2.1.1 X.509-Identitäten

Eine X.509-Identität ist eine Identität gemäß Abschnitt 2.1, bei der ein X.509-Zertifikat [RFC-5280] verwendet wird.

Bei der Aufteilung von X.509-Identitäten wurden die Identitäten zunächst nach Gruppen für verschiedene Einsatzzwecke des Schlüssels unterteilt und diese bei Bedarf um einen notwendigen Einsatzkontext erweitert. Aus dieser Aufteilung ergibt sich die nachfolgend tabellarisch dargestellte Übersicht der Arten von X.509-Identitäten. Der exemplarische Einsatzort der Identitäten ist hierbei rein informativ, die Ausprägung wird in den Spezifikationen festgelegt, die eine kryptographische Identität benötigen.

Tabelle 1: Tab_KRYPT_001 Übersicht über Arten von X.509-Identitäten

Für den Aufbau der X.509-Zertifikate gelten die Vorgaben aus den jeweiligen Spezifikationen der X.509-Zertifikate.

2.1.1.1 Digitale nicht-qualifizierte elektronische Signaturen

GS-A_4357-02 - X.509-Identitäten für die Erstellung und Prüfung digitaler nicht-qualifizierter elektronischer Signaturen

Alle Produkttypen, die X.509-Identitäten bei der Erstellung oder Prüfung digitaler nicht-qualifizierter elektronischer Signaturen verwenden, MÜSSEN die in Tab_KRYPT_002 aufgeführten Algorithmen unterstützen und die Tabellenvorgaben erfüllen.
Produkttypen, die Zertifikate (X.509-Identitäten) auf Basis der Schlüsselgeneration „ECDSA“ ausstellen (vgl. Abschnitt 5.1) oder verwenden, MÜSSEN die in Tab_KRYPT_002a aufgeführten Algorithmen und die Tabellenvorgaben erfüllen.
[<=]

Tabelle 2: Tab_KRYPT_002 Algorithmen für X.509-Identitäten zur Erstellung nicht-qualifizierter Signaturen für die Schlüsselgeneration „RSA“

A_15590 - Zertifikatslaufzeit bei Erstellung von X.509-Zertifikaten mit RSA 2048 Bit

Ein TSP-X.509-nonQES, der X.509-Zertifikate erstellt auf Basis der Schlüsselgeneration „RSA“ (d. h., für den die Vorgaben aus Tab_KRYPT_002 gelten), MUSS das Ende der Zertifikatsgültigkeitsdauer für das auszustellende Zertifikat unabhängig von der in Tab_KRYPT_002 festgelegten Endedaten der Zulässigkeit der verwendeten RSA-Schlüssellängen festlegen.

[<=]

Erläuterung: Die technische Durchsetzung des Endes der Zulässigkeit von RSA mit weniger als 3000 Bit Schlüssellänge in X.509-Zertifikaten erfolgt durch die Herausnahme der entsprechenden RSA-basierten Sub-CA-Zertifikate aus der TSL zum Zeitpunkt des Ablaufens der Zulässigkeit (gemäß TIP1-A_2062). Ein TSP muss bez. der Zertifikatsgültigkeitsdauer der von ihm ausgegebenen Zertifikate das nach Spezifikationslage definierte Verhalten zeigen (i. A. Zertifikatsgültigkeitsdauer der ausgegebenen Zertifikate von 5 Jahren). Ein TSP kann auch mit dem Kartenherausgeber beliebige Gültigkeitsdauern unter 5 Jahren für die Laufzeit der vom TSP ausgegebenen Zertifikate vereinbaren.

A_23458 - Konnektor, Zulässigkeitszeiträume kryptographische Algorithmen

Der Konnektor SOLL NICHT die Zulässigkeitszeiträume kryptographischer Algorithmen technisch durchsetzen. [<=]

Erläuterung: Analog zu A_15590 für die TSP der TI gilt, dass die Unterbindung der Verwendung von RSA mit Schlüssellängen unter 3000 Bit durch die gematik erfolgt durch die Herausnahme der entsprechenden RSA-basierten Sub-CA-Zertifikate aus der TSL zum Zeitpunkt des Ablaufens der Zulässigkeit (gemäß TIP1-A_2062).

Tabelle 3: Tab_KRYPT_002a Algorithmen für X.509-Identitäten zur Erstellung nicht-qualifizierter Signaturen für die Schlüsselgeneration „ECDSA“

Aktuell werden in der TI CRLs ausschließlich im Rahmen des IPsec-Verbindungsaufbaus (Verbindung der Konnektoren in die TI) verwendet.

Für die maximale Gültigkeitsdauer der Zertifikate gilt die Anforderung [GS-A_3080].

A_22220 - Konnektor: zulässige Algorithmen und Domainparameter bei Zertifikatsprüfungen

Ein Konnektor KANN bei einer Zertifikatsprüfung alle im SOGIS-Katalog [SOGIS-2020] als zulässig aufgeführten kryptographischen Signaturverfahren inkl. der dem jeweiligen Verfahren zugehörigen Domainparametern (Mindestschlüssellängen, Kurvenparameter etc.) für eine Zertifikatsprüfung verwenden, sofern die Angaben aus [gemSpec_Krypt#Tab_KRYPT_002 und _002a (und auch _003 und _003a)] als Mindestvorgaben (Mindestschlüssellängen, Mindestgrößen der Kurvenparameter etc.) eingehalten werden.  [<=]

A_19073 - Feste Laufzeit CV-Zertifikate einer Karte (eGK/HBA/SMC-B)

Die Anbieter CVC-TSP eGK, Anbieter HBA und Anbieter SMC-B MÜSSEN CV-Zertifikate tagesgenau in der Laufzeit auf die am kürzest gültigen X.509-Zertifikate der "Schlüsselgeneration ECDSA" der Karte beschränken.
Sind keine X.509-Zertifikate der "Schlüsselgeneration ECDSA" auf der Karte vorgesehen, dann MUSS die Laufzeit auf die am kürzest gültigen X.509-Zertifikate der "Schlüsselgeneration RSA" der Karte beschränkt werden. [<=]

A_19173 - Feste Laufzeit X.509-Zertifikate einer Karte (eGK/HBA/SMC-B)

Der Anbieter HBA, Anbieter SMC-B und der Anbieter X.509 TSP eGK MÜSSEN alle X.509-Zertifikate der "Schlüsselgeneration ECDSA" der Karte tagesgenau in der Laufzeit auf die der am längsten gültigen CV-Zertifikate der Karte beschränken. Sind keine X.509-Zertifikate der "Schlüsselgeneration ECDSA" auf der Karte vorgesehen, dann MUSS die Laufzeit aller X.509-Zertifikate der "Schlüsselgeneration RSA" der Karte tagesgenau in der Laufzeit auf die der am längsten gültigen CV-Zertifikate der Karte beschränkt werden. [<=]

Hinweis: "Tagesgenau" bedeutet, dass der Zeitpunkt sich nicht im Kalenderdatum, jedoch in der Uhrzeit unterscheiden darf. 

A_23139 - TSP-X.509-nonQES: ECC-Kurvenparameter, Komplexitätsreduktion

Ein TSP-X.509-nonQES, der nicht die X.509-Root-CA der TI ist, MUSS sicherstellen, dass

1. ein öffentlicher ECC-Schlüssel im CA-Zertifikat,
2. die öffentlichen ECC-Schlüssel der zum CA-Zertifikat aus (1) zugehörigen OCSP-Zertifikate (vgl. [RFC-6960#4.2.2.2] bzw. A_23142), und
3. die öffentlichen ECC-EE-Schlüssel in den EE-Zertifikate, die durch die CA mit dem Schlüssel aus (1) prüfbar sind,

die gleichen Kurvenparameter (brainpoolP256r1, P-256 etc. vgl. [gemSpec_Krypt#Tab_KRYPT_002a]) besitzen.
[<=]

Verständnishinweis:

Die Chipkarten der TI verwenden für ihre ECC-EE-Schlüssel alle die Kurvenparameter brainpoolP256r1. Dies ist in den Objektsystem-Spezifikationen (und damit auch den Objektsystemen) der Chipkarten fixiert. Die CA-en, die EE-Zertifikate für diese Chipkarten bestätigen, müssen nach A_23139-* ebenfalls ein ECC-Schlüsselpaar auf Basis von brainpoolP256r1 verwenden.

Die Komponenten-PKI der TI besitzt mehrere CA-Zertifikate. Es gibt mindestens ein CA-Zertifikat, das für die Prüfung der ECC-EE-Zertifikate von SMC-K, SMC-KT und der meisten Fachdienste verwendet wird. Dieses CA-Zertifikat verwendet ebenfalls als öffentlichen Prüfschlüssel ein Schlüssel auf brainpoolP256r1-Basis (A_23139-*).

Für bestimmte Fachdienste, die zukünftig direkt von einen Primärsystem per TLS erreichbar sein sollen, sollen TLS-Zertifikate in der Komponenten-PKI der TI erzeugt werden können, die anstatt brainpool-Kurvenpunkte (brainpoolP256r1) NIST-Kurvenpunkte (P-256) als öffentliche Schlüssel enthalten. Grund dafür ist die deutlich bessere Unterstützung der NIST-Kurvenparameter durch verschiedene Standard-Kryptographie-Softwarebibliotheken.

Es gibt in der Komponenten-PKI mindestens ein CA-Zertifikat, dessen öffentlicher ECC-Schlüssel NIST-kurvenbasiert ist. Falls ein Fachdienst einen CSR mit einen NIST-Kurvenpunkt als öffentlichen Schlüssel einreicht bei der Komponenten-PKI, dann wird dieser unter der CA bestätigt, die NIST-kurvenbasiert ist.

In der Regel werden X.509-Root-CA-Zertifikate (RCA7 etc.) NIST-kurvenbasiert sein. Damit kann ein PVS mit einer Kryptographie-Softwarebibliothek ohne brainpool-Kurvenunterstützung mit solch einem Root-CA-Zertifikat die komplette Zertifikatskette bis zum Fachdienst prüfen.

Für die X.509-Root-CA gilt A_23139-* absichtlich nicht.

2.1.1.2 Qualifizierte elektronische Signaturen

GS-A_4358-01 - X.509-Identitäten für die Erstellung und Prüfung qualifizierter elektronischer Signaturen

Alle Produkttypen, die X.509-Identitäten für die Erstellung oder Prüfung von qualifizierten elektronischen Signaturen verwenden, MÜSSEN mindestens alle in Tabelle Tab_KRYPT_003 aufgeführten Algorithmen unterstützen und die Tabellenvorgaben erfüllen.    
TSP-X.509-QES, die qualifizierte Zertifikate (X.509-Identitäten) auf Basis der Schlüsselgeneration „ECDSA“ (vgl. Abschnitt 5.1) erstellen oder verwenden MÜSSEN die in Tab_KRYPT_003a aufgeführten Algorithmen und die Tabellenvorgaben erfüllen. [<=]

Tabelle 4: Tab_KRYPT_003 Algorithmen für X.509-Identitäten zur Erstellung qualifizierter elektronischer Signaturen für die Schlüsselgeneration „RSA“

Tabelle 5: Tab_KRYPT_003a Algorithmen für X.509-Identitäten zur Erstellung qualifizierter Signaturen für die Schlüsselgeneration „ECDSA“

2.1.1.3 TLS-Authentifizierung

GS-A_4359-02 - X.509-Identitäten für die Durchführung einer TLS-Authentifizierung

Alle Produkttypen, die X.509-Identitäten für eine TLS-Authentifizierung verwenden, MÜSSEN alle in Tab_KRYPT_002 aufgeführten Algorithmen unterstützen und die Tabellenanforderungen erfüllen.    
Produkttypen die Zertifikate (X.509-Identitäten) auf Basis der Schlüsselgeneration „ECDSA“ ausstellen (vgl. Abschnitt 5.1) oder verwenden, MÜSSEN die in Tab_KRYPT_002a aufgeführten Algorithmen und die Tabellenvorgaben erfüllen. [<=]

A_22457 - TLS-Clients, Ciphersuiten bei TLS-Verbindung mit eHealth-KT

Alle Produkttypen, die als TLS-Client gegenüber dem eHealth-Kartenterminal agieren, DÜRFEN bei beidseitig authentisierten TLS-Verbindungen NICHT Ciphersuiten mit Authentisierungsalgorithmen (RSA bzw. ECDSA) anbieten, wenn sie nicht auch für die Clientauthentisierung Schlüsselmaterial und Zertifikat für diese Authentisierungsalgorithmen besitzen.  [<=]

2.1.1.4 IPsec-Authentifizierung

GS-A_4360-01 - X.509-Identitäten für die Durchführung der IPsec-Authentifizierung

Alle Produkttypen, die X.509-Identitäten für eine IPsec-Authentifizierung verwenden, MÜSSEN alle in Tab_KRYPT_002 aufgeführten Algorithmen unterstützen und die Tabellenanforderungen erfüllen.    
Produkttypen die Zertifikate (X.509-Identitäten) auf Basis der Schlüsselgeneration „ECDSA“ ausstellen (vgl. Abschnitt 5.1) oder verwenden, MÜSSEN die in Tab_KRYPT_002a aufgeführten Algorithmen und die Tabellenvorgaben erfüllen. [<=]

2.1.1.5 Digitale Signaturen durch TI-Komponenten

GS-A_4361-02 - X.509-Identitäten für die Erstellung und Prüfung digitaler Signaturen

Alle Produkttypen, die X.509-Identitäten verwenden, die zur Erstellung und Prüfung digitaler Signaturen in Bezug auf TI-Komponenten (technische X.509-Zertifikate) genutzt werden, MÜSSEN alle in Tab_KRYPT_002 aufgeführten Algorithmen unterstützen und die Tabellenanforderungen erfüllen.    
Produkttypen die Zertifikate (X.509-Identitäten) auf Basis der Schlüsselgeneration „ECDSA“ ausstellen (vgl. Abschnitt 5.1) oder verwenden, MÜSSEN die in Tab_KRYPT_002a aufgeführten Algorithmen und die Tabellenvorgaben erfüllen. [<=]

2.1.1.6 Verschlüsselung

GS-A_4362-02 - X.509-Identitäten für Verschlüsselungszertifikate

Alle Produkttypen, die X.509-Identitäten für die Verschlüsselung (Verschlüsselungszertifikate) verwenden, MÜSSEN alle in Tab_KRYPT_002 aufgeführten Algorithmen unterstützten und die Tabellenanforderungen erfüllen.    
Produkttypen die Zertifikate (X.509-Identitäten) auf Basis der Schlüsselgeneration „ECDSA“ ausstellen (vgl. Abschnitt 5.1) oder verwenden, MÜSSEN die in Tab_KRYPT_002a aufgeführten Algorithmen und die Tabellenvorgaben erfüllen. [<=]

2.1.2 CV-Identitäten

CV-Identitäten werden für die Authentifizierung zwischen Karten verwendet.

2.1.2.1 CV-Zertifikate G2

GS-A_4365-02 - CV-Zertifikate G2

Alle Produkttypen, die CV-Zertifikate der Kartengeneration G2 erstellen oder prüfen, MÜSSEN die in Tab_KRYPT_006 aufgeführten Algorithmen verwenden und die Tabellenanforderungen erfüllen.
[<=]

Tabelle 6: Tab_KRYPT_006 Algorithmen für CV-Zertifikate

Für die maximale Gültigkeitsdauer der Zertifikate gilt die Anforderung [GS-A_3080].

2.1.2.2 CV-Certification-Authority (CV-CA) Zertifikat G2

GS-A_4366-02 - CV-CA-Zertifikate G2

Alle Produkttypen, die CV-CA-Zertifikate der Kartengeneration G2 erstellen oder prüfen, MÜSSEN dien Tab_KRYPT_007 aufgeführten Algorithmen verwenden und die Tabellenanforderungen erfüllen.
[<=]

Tabelle 7: Tab_KRYPT_007 Algorithmen für CV-CA-Zertifikate

Für die maximale Gültigkeitsdauer der Zertifikate gilt die Anforderung [GS-A_3080].

2.2 Zufallszahlengeneratoren

GS-A_4367 - Zufallszahlengenerator

Alle Produkttypen, die Zufallszahlen generieren, MÜSSEN die Anforderungen aus [BSI-TR-03116-1#3.8 Erzeugung von Zufallszahlen] erfüllen.
[<=]

2.3 Hilfestellung bei der Umsetzung (Zufallsgeneratoren)

(Hinweis: dies ist das ehemalige „Kapitel 5.2.4 Hilfestellung bei der Umsetzung der Anforderungen“. Der Text in diesem Abschnitt entstand in enger Abstimmung mit dem BSI auf Gesellschafterwunsch.)

Die Sicherheit eines deterministischen Zufallszahlengenerators (DRNGs) hängt maßgeblich von drei Faktoren ab:

• von der Entropie des Seeds,
• vom algorithmischen Anteil (generelles Design) und
• dem Schutz des inneren Zustands (und der zur Ausgabe vorgesehenen Zufallszahlen).

Der Nachweis, dass der algorithmische Anteil eines DRNGs den Anforderungen einer bestimmten Funktionalitätsklasse genügt, kann schwierig und aufwändig sein. Deshalb wurde das BSI gebeten, die DRNGs in [FIPS-186-2+CN1] und [ANSI-X9.31] in Bezug auf die kryptographische Güte ihres algorithmischen Anteils zu bewerten.

Das Ergebnis ist:

A) [FIPS-186-2+CN1]: Lässt man in dem DRNG aus Appendix 3.1 (S. 16f.) in Schritt 3c bzw. in dem DRNG aus Algorithmus 1 (Change Notice 1, S. 72f.) in Schritt 3.3 den Term "mod q" weg, so werden gleich verteilt 160-Bit Zufallszahlen bzw. 320-Bit Zufallszahlen erzeugt (vgl. Abschnitt „General Purpose Random Number Generation“ (Change Notice 1, S. 74)).    
Beide DRNGs sind dann

1. algorithmisch geeignet für die Klasse K4 [AIS-20-1999] und
2. erfüllen die algorithmischen Anforderungen aus DRG.3 [AIS-20].

Ob eine konkrete Implementierung eines dieser DRNG bspw. Teil der Klasse DRG.3 ist, bleibt im Einzelfall zu prüfen, da dazu u. a. auch Fragen über die Initialisierung zu beantworten sind (vgl. (DRG.3.1) [KS-2011]).

Das BSI empfiehlt bei den Zufallsgeneratoren aus [FIPS-186-2+CN1] nach Möglichkeit SHA-256 [FIPS-180-4] anstatt SHA-1 zu verwenden. Folgt man der Empfehlung, so ist der Algorithmus dementsprechend zu adaptieren.

B) [ANSI-X9.31]: Der Zufallsgenerator aus Appendix A.2.4 ist

(1) algorithmisch geeignet für die Klasse K3 [AIS-20-1999] und

(2) erfüllt die algorithmischen Anforderungen aus DRG.2 [AIS-20].

2.4 Schlüsselerzeugung und Schlüsselbestätigung

GS-A_4368 - Schlüsselerzeugung

Alle Produkttypen, die Schlüssel erzeugen, MÜSSEN die Anforderungen aus [BSI-TR-03116-1#3.9 Schlüsselerzeugung] erfüllen. [<=]

Hinweis: im Rahmen der Sicherheitszertifizierung von Komponenten, wie bspw. des Konnektors, wird dies überprüft.

GS-A_5021 - Schlüsselerzeugung bei einer Schlüsselspeicherpersonalisierung

Ein Herausgeber von Sicherheitsmodulen für kryptographisches Schlüsselmaterial, welche in der TI genutzt werden (also bspw. eGK, SMC-B, HSM-B, SMC-KT und HBA), MUSS sicherstellen, dass auf dem Sicherheitsmodul gespeicherten Schlüssel die Anforderungen aus [BSI-TR-03116-1#3.5 Schlüsselerzeugung] erfüllen.

[<=]

Hinweis: Dies ist eine Anforderung an Kartenherausgeber, die so sicherstellen müssen, dass das in den Sicherheitsmodulen (also auch HSM-B) zur Verfügung stehende kryptographische Schlüsselmaterial geeignet ist Daten mit sehr hohem Schutzbedarf schützen zu können. (siehe auch Kapitel 4.4) 

GS-A_5338 - HBA/SMC-B – Erzeugung asymmetrischer Schlüsselpaare auf der jeweiligen Karte selbst

Ein Kartenherausgeber oder, falls der Kartenherausgeber einen Dritten mit der Kartenpersonalisierung beauftragt, der Kartenpersonalisierer für HBA oder SMC-B MUSS sicherstellen, dass bei der Personalisierung der Karten HBA und SMC-B alle asymmetrischen Schlüsselpaare, bei denen die privaten Schlüssel auf der Karte gespeichert werden, auf der Karte erzeugt werden.
[<=]

Aufgrund des geringeren Mengengerüsts bei HBA und SMC-B ist dort die On-Card-Generierung der entsprechenden Schlüsselpaare möglich. Somit (vgl. auch [PP-0082, FPT_EMS.1] ist technisch sichergestellt, dass keine Kopie der privaten Schlüssel außerhalb der Chipkarte existiert (Kontext: Ende-zu-Ende-Verschlüsselung von medizinischen Daten).

GS-A_5386 - kartenindividuelle geheime und private Schlüssel G2-Karten

Ein Kartenherausgeber, der G2-Karten herausgibt, MUSS sicherstellen, dass bei der Personalisierung der Karten alle für eine Karte zu personalisierenden privaten und geheimen Schlüssel kartenindividuell sind. Bei Beauftragung eines Dritten mit der Schlüsselerzeugung ist dies durch den Dritten sicherzustellen.    
Falls symmetrische Schlüssel (bspw. SK.CMS.AES128) nicht pro Karte zufällig erzeugt werden, sondern mit einem Schlüsselableitungsverfahren erzeugt werden, so MUSS der Kartenherausgeber sicherstellen, dass

1. das verwendete Schlüsselableitungsverfahren (KDF) unumkehrbar und nicht-vorhersagbar ist (Hilfestellung: Beispiele in [gemSpec_Krypt, 2.4 und 3.4]).
2. der Masterkey (Key Derivation Key (KDK)) GS-A_4368 erfüllt (insbesondere Entropie-Vorgaben). Der KDK MUSS eine Mindestentropie von 120 Bit besitzen.

[<=]

Für private Schlüssel bei HBA und SMC-B wird die kartenindividuelle Erzeugung und Personalisierung durch GS-A_5338 technisch sichergestellt. Je nach verwendetem COS, insbesondere dessen spezifischen Personalisierungsverfahrens, kann es sein, dass ein Kartenherausgeber symmetrische Schlüssel aus technischen Gründen personalisieren muss, obwohl er später nicht plant mit diesen Schlüsseln bspw. im Rahmen eines CMS zu arbeiten. Es ist sicherheitskritisch, dass auch diese symmetrischen Schlüssel ebenfalls die Anforderungen GS-A_5021 bzw. GS-A_4368 erfüllen.

Als geeignete Schlüsselableitungsverfahren (KDF) für die Erzeugung von kartenindividuellen Schlüssel sind bspw. folgende Verfahren geeignet:

• alle Verfahren aus [NIST-SP-800-108] mittels CMAC [NIST-SP-800-38B],
• alle Verfahren aus [NIST-SP-800-56-A] bzw. [NIST-SP-800-56-B] mittels jeder nach [BSI-TR-03116-1] zulässigen Hashfunktion,
• alle Verfahren aus [NIST-SP-800-56C] mittels CMAC [NIST-SP-800-38B] oder eines HMAC, der auf einer nach [BSI-TR-03116-1] zulässigen Hashfunktion basiert,
• das Verfahren nach [ANSI-X9.63, Abschnitt 5.6.3] mittels jeder nach [BSI-TR-03116-1] zulässigen Hashfunktion.

A_23900 - TSP-X.509: Einzigartigkeit der bestätigten öffentlichen Schlüssel

Ein TSP-X.509 nonQES SMC-B MUSS TSP-intern prüfen, ob EE-Schlüssel in den vom TSP auszustellenden Zertifikaten pro Identität einzigartig sind. Der TSP MUSS TSP-intern sicherstellen, dass zwei unterschiedliche End-Entitäten nicht das selbe Schlüsselpaar verwenden.
Der TSP MUSS von ihm in Zertifikaten bestätigte öffentliche EE-Schlüssel in einem Schlüsselspeicher ablegen. Dieser Schlüsselspeicher ist initial leer. Vor Ausstellen eines neuen Zertifikats MUSS der TSP prüfen, ob der öffentliche EE-Schlüssel schon im Schlüsselspeicher enthalten ist. Falls ja, so MUSS der TSP die Zertifikatserstellung ablehnen. Falls nein, MUSS der TSP nach erfolgreicher Zertifikatserstellung den nun im Zertifikat bestätigten öffentliche EE-Schlüssel im Schlüsselspeicher einfügen. [<=]

Erläuterung zu A_23900:

Die Einzigartigkeit der öffentlichen EE-Schlüssel ist nach A_23900 nur TSP-intern sicherzustellen, es wird also nicht verlangt, dass die Schlüsselspeicher i. S. v. A_23900 über alle TSP ausgetauscht oder synchronisiert werden. A_23900 stellt eine Detaillierung von [gemRL_TSL_SP_CP#GS-A_4906] dar.

2.4.1 Prüfung auf angreifbare (schwache) Schlüssel

A_17294 - TSP-X.509: Prüfung auf angreifbare (schwache) Schlüssel

Ein TSP-X.509-nonQES MUSS vor einer Zertifikatserzeugung den durch das Zertifikat zu bestätigenden öffentlichen Schlüssel auf dessen kryptographische Angreifbarkeit hin prüfen. 
Falls die Prüfung des öffentlichen Schlüssels das Ergebnis „angreifbar“ liefert, so MUSS der TSP die Zertifikatserstellung für diesen Schlüssel ablehnen. 
Mindestumfang der Prüfung MÜSSEN 

1. der Test auf die "Debian-OpenSSL-PRNG-Schwachstelle" und
2. der Test auf die Anfälligkeit gegen den ROCA-Angriff sein. 

Der TSP MUSS den Mindestumfang der Prüfung bei Bekanntwerden neuer Angriffsmöglichkeiten gemäß [gemSpec_DS_Anbieter#GS-A_5560] erweitern. [<=]

TSPs, die im Internet TLS-Zertifikate ausgeben (bspw. für die Verwendung von HTTPS), müssen aufgrund der Baseline Requirement des CA/Browser Forums (https://cabforum.org/baseline-requirements-documents/ ) vor der Zertifikatserzeugung kryptographische Prüfungen des zu bestätigenden öffentlichen Schlüssels durchführen. Analog gilt dies mit   auch für TI-TSPs. Die gematik stellt auf Anfrage eine Beispielimplementierung für die Tests des Mindestumfangs bereit. 

Unter https://security.googleblog.com/2022/08/announcing-open-sourcing-of-paranoids.html ist eine Vielzahl von Schlüsseltests als OpenSource verfügbar.

2.4.2 ECC-Schlüssel in X.509-Zertifikaten

GS-A_5518 - Prüfung Kurvenpunkte bei einer Zertifikatserstellung

Alle Produkttypen, die X.509-Zertifikate erstellen und dabei öffentliche Punkte auf einer elliptischen Kurve in diesen Zertifikaten bestätigen, MÜSSEN überprüfen, ob die zu bestätigenden Punkte auch auf der zugehörigen Kurve (im Regelfall brainpoolP256r1 [RFC-5639#3.4]) liegen. Falls nein, MUSS der Produkttyp eine Zertifikatsausstellung verweigern.

[<=]

A_17091 - ECC-Schlüsselkodierung

Ein TSP-X.509-nonQES MUSS sicherstellen, dass wenn er ECC-Schlüssel für eine Zertifikatserstellung erhält, diese in unkomprimierter Form (d. h. explizite Aufführung der vollständigen x- und y-Koordinaten [BSI-TR-03111#Abschnitt 3.2.1 "Uncompressed Encoding"]) vom Antragsteller übergeben werden.
[<=]

Hinweis: Diese Kodierungsform (uncompressed encoding) ist auch die Form, wie sie letztendlich in den X.509-Zertifikaten verwendet wird. Weiterhin kann ein TSP in dieser Form mit der Prüfung aus GS-A_5518 sicherstellen, dass keine Fehlkodierung des zu bestätigenden ECC-Schlüssels aufgetreten ist.

2.4.3 RSA-Schlüssel in X.509-Zertifikaten

A_17092 - RSA-Schlüssel Zertifikatserstellung, keine kleinen Primteiler und e ist prim

Ein TSP KANN im Rahmen der Zertifikatsbeantragung, bei denen öffentliche RSA-Schlüssel bestätigt werden, folgende Tests auf die RSA-Schlüssel anwenden. Wenn ein u. g. Test das Ergebnis FAIL als Ergebnis liefert, so ist der Schlüssel fehlerhaft und der TSP muss die Zertifikatserstellung für diesen Schlüssel ablehnen.

1. Ist der öffentliche Exponent e (des untersuchten RSA-Schlüssels) prim und gilt 2^16<e<2^256 (vgl. [BSI-TR-03116-1#3.2 RSA])?
   Falls nein, ist das Ergebnis FAIL.
2. Ist der Modulus des untersuchten RSA-Schlüssels kleiner als 2^2048?
   Falls nein, ist das Ergebnis FAIL.
3. Ist der Modulus des untersuchten RSA-Schlüssels relativ prim zu allen Primzahlen kleiner als 100?
   Falls nein, ist das Ergebnis FAIL.

[<=]

Erläuterungen zu  befinden sich in Abschnitt 9.2 RSA-Schlüssel in X.509-Zertifikaten. 

A_17093 - RSA-Schlüssel Zertifikatserstellung, Entropie der Schlüsselkodierung

Ein TSP KANN im Rahmen der Zertifikatsbeantragung, bei denen öffentliche RSA-Schlüssel bestätigt werden, folgenden Test auf die RSA-Schlüssel anwenden. Wenn ein Test das Ergebnis FAIL liefert, so ist der Schlüssel fehlerhaft und der TSP muss die Zertifikatserstellung für diesen Schlüssel ablehnen.

1. Ist die Entropie des kodierten RSA-Schlüssels (im Sinne von [gemSpec_Krypt# ], entropy()-Funktion) kleiner als 6.72? Falls ja, so ist das Ergebnis FAIL.

[<=]

Erläuterungen zu   befinden sich in Abschnitt 9.2 RSA-Schlüssel in X.509-Zertifikaten.

2.5 Einmalpasswörter

Bei verschiedenen Registrierungs- oder Anmeldeprozessen werden Einmalpasswörter (insbesondere bei KIM) verwendet. Für diese Einmalpasswörter gilt folgende Vorgabe:

A_22686 - Einmalpasswörter (One-Time-Passwords, OTP), Mindestentropie

Alle Produkttypen, die Einmalpasswörter (One-Time-Passwords, OTP) erzeugen, MÜSSEN sicherstellen, dass diese Einmalpasswörter eine Mindestentropie von 120 Bit besitzen. D. h. sie werden zufällig erzeugt und sind mit praktischer Sicherheit - Wahrscheinlichkeit gleich 1 – 2^(–120)) - nicht erratbar. [<=]

3 Konkretisierung der Algorithmen für spezifische Einsatzszenarien

In den nachfolgenden Abschnitten werden die kryptographischen Algorithmen für verschiedene Einsatzszenarien spezifiziert. In diesem Zusammenhang sind ausschließlich die kryptographischen Aspekte der Einsatzszenarien relevant.

 

Abbildung 1: Verwendung von Algorithmen nach Zonen und OSI-Schicht

Abbildung 1 stellt beispielhaft die für die Vertraulichkeit von medizinischen Daten relevanten Algorithmen auf den verschiedenen OSI-Schichten in einer Übersicht dar. Es besteht in dieser Abbildung kein Anspruch auf Vollständigkeit.

3.1 Kryptographische Algorithmen für XML-Dokumente

GS-A_4370 - Kryptographische Algorithmen für XML-Dokumente

Alle Produkttypen, die XML-Dokumente

• verschlüsseln, MÜSSEN dies mittels CMS [RFC-5652] oder XMLEnc durchführen,
• signieren, MÜSSEN dies mittels CMS [RFC-5652] oder XMLDSig durchführen.

[<=]

XML-Signaturen sind bezüglich der verwendeten Algorithmen selbst beschreibend, die für die Erstellung einer Signatur verwendeten Algorithmen sind in der Signatur aufgeführt.

Zur vollständigen Spezifikation der Algorithmen für XML-Signaturen müssen für alle Signaturbestandteile Algorithmen spezifiziert werden. Die nachfolgenden Abschnitte wählen aus der Menge der zulässigen Algorithmen die jeweiligen Algorithmen für die einzelnen Einsatzszenarien aus.

Die Referenzierung von Algorithmen in XML-Signaturen und XML-Verschlüsselungen erfolgt nicht wie in Zertifikaten oder Signaturen binärer Daten über OIDs sondern über URIs. Die URIs der Algorithmen dienen als eindeutige Identifier und nicht dazu, dass unter der jeweils angegebenen URI die Beschreibung zu finden ist.

Tabelle 8: Tab_KRYPT_008 Beispiele für solche Algorithmen-URIs

3.1.1 XML-Signaturen für nicht-qualifizierte Signaturen

GS-A_4371-02 - XML-Signaturen für nicht-qualifizierte Signaturen

Alle Produkttypen, die XML-Signaturen für nicht-qualifizierte Signaturen erzeugen oder prüfen, MÜSSEN die Algorithmen und Vorgaben der Tabelle Tab_KRYPT_009 erfüllen. [<=]

Tabelle 9: Tab_KRYPT_009 Algorithmen für die Erzeugung von nicht-qualifizierten elektronischen XML-Signaturen

3.1.2 XML-Signaturen für qualifizierte elektronische Signaturen

GS-A_4372-02 - XML-Signaturen für qualifizierte elektronische Signaturen

Alle Produkttypen, die XML-Signaturen für qualifizierte elektronische Signaturen erzeugen oder prüfen, MÜSSEN die Vorgaben der Tabelle Tab_KRYPT_010 erfüllen. [<=]

Tabelle 10: Tab_KRYPT_010 Algorithmen für qualifizierte XML-Signaturen

3.1.3 Webservice Security Standard (WSS)

Nicht relevant für den Wirkbetrieb der TI.

3.1.4 XML-Verschlüsselung – Symmetrisch

GS-A_4373 - XML-Verschlüsselung - symmetrisch

Alle Produkttypen, die XML-Dokumente mittels [XMLEnc-1.1] verschlüsseln, MÜSSEN die folgenden Vorgaben umsetzen:

• Als symmetrische Block-Chiffre muss AES [FIPS-197] mit einer Schlüssellänge von 256 Bit im Galois/Counter Mode (GCM) gemäß [NIST-SP-800-38D] mit der Tag-Länge von 128 Bit verwendet werden.
• Die IVs dürfen sich bei gleichem Schlüssel nicht wiederholen (vgl. [NIST-SP-800-38D#S.25] und [BSI-TR-02102-1#S. 24]). Der IV soll eine Bitlänge von 96 Bit besitzen, seine Länge muss mindestens 96 Bit sein. Es wird empfohlen den IV zufällig zu wählen (vgl. [gemSpec_Krypt#GS-A_4367]).
• Hinweis: Im Normalfall ist davon auszugehen, dass für die Sicherung der Integrität und Authentizität der übertragenen Daten zudem noch eine Signatur der zu verschlüsselnden Daten notwendig ist.

[<=]

3.1.5 XML-Verschlüsselung – Hybrid

GS-A_4374 - XML-Verschlüsselung - Hybrid

Alle Produkttypen, die Dokumente mittels [XMLEnc-1.1] hybrid verschlüsseln, MÜSSEN das Dokument gemäß [gemSpec_Krypt#GS-A_4373] symmetrisch verschlüsseln, wobei der eingesetzte symmetrischer Schlüssel (jeweils) für eine spezifische Person oder Komponente asymmetrisch verschlüsselt wird.    
(Hinweis: Analog zum Hinweis in [gemSpec_Krypt#GS-A_4373] gilt auch hier, dass im Normalfall für die Sicherung der Integrität und Authentizität der übertragenen Daten zudem noch eine Signatur dieser Daten notwendig ist.)
[<=]

GS-A_4376-02 - XML-Verschlüsselung - Hybrid, Schlüsseltransport RSAES-OAEP

Alle Produkttypen, die Dokumente mittels [XMLEnc-1.1] RSA-basiert hybrid ver- und entschlüsseln, MÜSSEN für den Schlüsseltransport den Algorithmus RSAES-OAEP gemäß [PKCS#1] verwenden. [<=]

3.2 Karten-verifizierbare Authentifizierung und Verschlüsselung

3.2.1 Card-to-Card-Authentisierung G2

GS-A_4379 - Card-to-Card-Authentisierung G2

Alle Produkttypen, die die Card-to-Card-Authentisierung für Karten der Generation G2 durchführen, MÜSSEN dabei eine CV-Identität gemäß [gemSpec_Krypt#GS-A_4365-*] verwenden. 

 
[<=]

Das Verfahren zur Durchführung der Card-to-Card-Authentisierung wird in [gemSpec_COS] spezifiziert.

3.2.2 Card-to-Server (C2S) Authentisierung und Trusted Channel G2

GS-A_4380 - Card-to-Server (C2S) Authentisierung und Trusted Channel G2

Alle Produkttypen, die eine Card-to-Server-Authentisierung für Karten der Generation G2 durchführen, MÜSSEN die folgenden Vorgaben berücksichtigen:

• Die Authentisierung muss mit AES analog [EN-14890-1#8.8] erfolgen.
• Die Schlüsselvereinbarung muss analog zu [EN-14890-1#8.8.2] erfolgen.

[<=]

Das Verfahren zur Durchführung der Card-to-Server-Authentisierung wird in [gemSpec_COS] spezifiziert.

C2S-Authentisierung bzw. der Trusted-Channel wird zwischen der Karte und dem zugeordneten Management-System verwendet.

Der Algorithmus AES ist nach [BSI-TR-03116-1] in der TI bis Ende 2029+ (meint bis Ende des Betrachtungsraums der TR) zulässig.

GS-A_4381-01 - Schlüssellängen Algorithmus AES

Alle Produkttypen, die den Algorithmus AES nutzen, MÜSSEN die Schlüssellängen gemäß Tabelle Tab_KRYPT_012 nutzen. [<=]

Tabelle 11: Tab_KRYPT_012 Algorithmen für Card-to-Server-Authentifizierung

3.3 Netzwerkprotokolle

Im Gegensatz zu kryptographischen Verfahren für den Integritätsschutz oder die Vertraulichkeit von Daten, bei denen keine direkte Kommunikation zwischen dem Sender bzw. dem Erzeuger und dem Empfänger stattfindet, kann bei Netzwerkprotokollen eine Aushandlung des kryptographischen Algorithmus erfolgen. Das Ziel der nachfolgenden Festlegungen ist es daher, jeweils genau einen verpflichtend zu unterstützenden Algorithmus festzulegen, so dass eine Einigung zumindest auf diesen Algorithmus immer möglich ist. Zusätzlich können aber auch optionale Algorithmen festgelegt werden, auf die sich Sender und Empfänger ebenfalls im Zuge der Aushandlung einigen können. Es darf jedoch durch keine der Komponenten vorausgesetzt werden, dass der Gegenpart diese optionalen Algorithmen unterstützt.

3.3.1 IPsec-Kontext

GS-A_4382-04 - IPsec-Kontext - Schlüsselvereinbarung

Alle Produkttypen, die die Authentifizierung, den Schlüsselaustausch und die verschlüsselte Kommunikation im IPsec-Kontext durchführen, MÜSSEN die Schlüsselvereinbarung mittels IKEv2 [RFC-7296] gemäß den folgenden Vorgaben durchführen:

• Zur Authentisierung MUSS eine Identität mit einem X.509-Zertifikat gemäß [gemSpec_Krypt#GS-A_4360-*] verwendet werden.

• Für „Hash und URL“ MUSS SHA-1 verwendet werden.
• Die Diffie-Hellman-Gruppe Gruppe 14 (definiert in [RFC-3526], verwendbar bis Ende 2025) MUSS für den Schlüsselaustausch unterstützt werden. Zusätzlich KÖNNEN Gruppen aus [BSI-TR-02102-3, Abschnitt 3.2.4, Tabelle 5], bei denen der Verwendungszeitraum ein „+“ enthält, verwendet werden. 
• Der private DH-Exponent für den Schlüsselaustausch MUSS eine Länge von mindestens 256 Bit haben.

• Die Authentisierung der ephemeren (EC)DH-Parameter erfolgt durch eine Signatur der Parameter durch den jeweiligen Protokollteilnehmer. Bei dieser Signatur MUSS SHA-256 als Hashfunktion verwendet werden. Es SOLL die Authentisierungsmethode „Digital Signature“ nach [RFC-7427] dabei verwendet werden.

• Bei den symmetrische Verschlüsselungsalgorithmen MUSS AES mit 256 Bit Schlüssellänge im CBC-Modus unterstützt werden (sowohl für IKE-Nachrichten als auch später für die Verschlüsselung von ESP-Paketen). Es KÖNNEN weitere Verfahren nach [BSI-TR-02102-3, Abschnitt 3.2.1, Tabelle 2] bzw. [BSI-TR-02102-3, Abschnitt 3.3.1, Tabelle 7] verwendet werden.
• Für den Integritätsschutz (sowohl innerhalb von IKEv2 als auch anschließend für ESP-Pakete) MUSS HMAC mittels SHA-256 unterstützt werden. Es KÖNNEN weitere Verfahren nach [BSI-TR-02102-3, Abschnitt 3.2.3, Tabelle 4] bzw. [BSI-TR-02102-3, Abschnitt 3.3.1, Tabelle 8] verwendet werden, andere Verfahren dürfen nicht verwendet werden.
• Als PRF MUSS PRF_HMAC_SHA2_256 unterstützt werden. Es KÖNNEN weitere Verfahren nach [BSI-TR-02102-3, Abschnitt 3.2.2, Tabelle 3] verwendet werden, andere Verfahren dürfen nicht verwendet werden.
• Schlüsselaktualisierung: die IKE-Lifetime darf maximal 24*7 Stunden betragen (Reauthentication). Die IPsec-SA-Lifetime darf maximal 24 Stunden betragen (Rekeying). Der Initiator soll nach Möglichkeit vor Ablauf der Lifetime das Rekeying anstoßen. Ansonsten muss der Responder bei Ablauf der Lifetime das Rekeying von sich aus sicherstellen, bzw. falls dies nicht möglich ist, die Verbindung beenden.
• Für die Schlüsselberechnung muss Forward Secrecy [BSI-TR-02102-1, S.ix] (in [RFC-7296] „Perfect Forward Secrecy“ genannt) gewährleistet werden. Meint die Wiederverwendung von zuvor schon verwendeten (EC-)Diffie-Hellman-Schlüsseln ([RFC-7296, Abschnitt 2.12]) ist nicht erlaubt.

[<=]

Ziel ist es zum Zeitpunkt der IKE-SA-Reauthentication ausgeführte Anwendungsfälle nicht zu unterbrechen. Aktuell wird aufgrund von TIP1-A_4492 im Rahmen der Reauthentication dem Konnektor eine neue (i.d.R. andere) VPN-TI-IP-Adresse zugewiesen, was dazu führt, dass bestehende TCP-Verbindungen in die TI effektiv zerstört und laufende Anwendungsfälle unterbrochen werden. Perspektivisch wird die folgende Anforderung als MUSS-Anforderung in TIP1-A_4492 integriert.

GS-A_5547 - gleiche VPN-IP-Adresse nach Reauthentication

Der VPN-Zugangsdienst KANN nach einer Reauthentication (vgl. GS-A_4382-* Spiegelstrich „Schlüsselaktualisierung“) die gleiche VPN-IP-Adresse wie vor der Reauthentication vergeben. Die Reauthentication ist in Bezug auf TIP1-A_4492 nicht als „neue Verbindung/Neuaufbau des Tunnels“ zu betrachten.
[<=]

Da noch nicht alle VPN-Zugangsdienste technisch in der Lage sind GS-A_5547 umzusetzen werden als Symptomlinderung die Gültigkeitsdauern der ausgehandelten Schlüssel erhöht, auch in Anbetracht, dass weitere Sicherheitsmaßnahmen (bspw. TIP1-A_5389) umgesetzt werden neben den klassischen Prüfungen, die im Rahmen einer Reauthentication durchgeführt werden.

GS-A_5548 - Mindestgültigkeitszeiten IKE- und IPsec-SAs (Konnektor)

Der Konnektor MUSS die Konfiguration der Gültigkeitsdauern der IKE- bzw. IPsec-SAs auf (1) mindestens 90% und (2) kleiner als 100% der in GS-A_4382-* Spiegelstrich „Schlüsselaktualisierung“ aufgeführten Maximalwerte setzen.
[<=]

Auszug Beispielkonfiguration /etc/ipsec.conf

    ikelifetime=161h
    lifetime=23h
    margintime = 20m
    rekeyfuzz = 40%
    keyexchange=ikev2

GS-A_5549 - Mindestgültigkeitszeiten IKE- und IPsec-SAs (VPN-Zugangsdienst)

Der VPN-Zugangsdienst MUSS die Konfiguration der Gültigkeitsdauern der IKE- bzw. IPsec-SAs auf die in GS-A_4382-* Spiegelstrich „Schlüsselaktualisierung“ aufgeführten Maximalwerte setzen.
[<=]

GS-A_5508 - IPsec make_before_break

Alle Produkttypen, die mittels IPsec Daten schützen, MÜSSEN die Reauthentication (vgl. [RFC-7296#2.8.3 „Reauthentication is done by […]“]) durchführen, indem die neue IKE-SA aufgebaut wird bevor die bestehende IKE-SA gelöscht wird.
[<=]

GS-A_4383 - IPsec-Kontext – Verschlüsselte Kommunikation

Alle Produkttypen, die mittels IPsec-Daten schützen, MÜSSEN dies ausschließlich auf Grundlage der in GS-A_4382-* als zulässig aufgeführten Verfahren und Vorgaben tun.
[<=]

A_14652 - SZZP-light, asymmetrischen Schlüssel maximale Gültigkeitsdauer

Die Lebensdauer von asymmetrischen Schlüsseln für die IPsec-Verbindungen im SZZP-light sowie Sicherheitsgateway Bestandsnetze und somit die in einem Zertifikat angegebene Gültigkeitsdauer DARF NICHT 5 Jahre überschreiten.
[<=]

3.3.2 TLS-Verbindungen

GS-A_4385 - TLS-Verbindungen, Version 1.2

Alle Produkttypen, die Übertragungen mittels TLS durchführen, MÜSSEN die TLS-Version 1.2 [RFC-5246] unterstützen.
[<=]

A_18467 - TLS-Verbindungen, Version 1.3

Alle Produkttypen, die Übertragungen mittels TLS durchführen, KÖNNEN die TLS-Version 1.3 [RFC-8446] unterstützen, falls sie

1. dabei nur nach [BSI-TR-02102-2] empfohlene Verbindungskonfigurationen (Handshake-Modi, (EC)DH-Gruppen, Signaturverfahren, Ciphersuiten etc.) verwenden, und 
2. mindestens die Ciphersuite "TLS_AES_128_GCM_SHA256" dabei unterstützen. 

[<=]

A_18464 - TLS-Verbindungen, nicht Version 1.1

Alle Produkttypen, die Übertragungen mittels TLS durchführen, DÜRFEN NICHT die TLS-Version 1.1 [RFC-4346] unterstützen. [<=]

GS-A_4387 - TLS-Verbindungen, nicht Version 1.0

Alle Produkttypen, die Übertragungen mittels TLS durchführen, DÜRFEN NICHT die TLS-Version 1.0 unterstützen. [<=]

GS-A_5035 - Nichtverwendung des SSL-Protokolls

Alle Produkttypen, die Daten über Datenleitungen übertragen wollen, DÜRFEN NICHT das SSL-Protokoll unterstützen. [<=]

Bei TLS 1.1 oder älter ist im Rahmen des TLS-Verbindungsaufbaus die Verwendung von SHA-1 bei der Erstellung und Prüfung von Signaturen (TLS-Handshake) notwendig. Es gibt keine Möglichkeit der Aushandlung/Vereinbarung der Verwendung von kryptographisch höherwertigeren Hashfunktionen dafür. Dies wurde erst mit TLS 1.2 möglich. SHA-1 erbringt in Konstruktionen, die nur die kryptographische Einwegeigenschaft der Hashfunktion benötigen (bspw. bei der HMAC-Berechnung auf SHA-1-Basis) noch ein -- zwar nicht hochwertiges, aber immer noch -- vertretbares Sicherheitsniveau. Die allgemeine Kollisionsresistenz, so wie sie bei Signaturen notwendig ist, kann SHA-1 nicht mehr leisten. SHA-1 wurde in diesem Aspekt praktisch (i. S. v. nicht nur theoretisch) -- und öffentlichkeitswirksam demonstriert -- gebrochen. Aus diesem Grunde hat die IETF alle TLS Version unter 1.2 abgekündigt und bspw. alle Webbrowser-Hersteller haben die Unterstützung von TLS-Versionen unter 1.2 deaktiviert.

Einen lesenswerten Abriss bekannter Angriffe auf TLS findet man in [TLS-Attacks], vgl. auch [Breaking-TLS].

Analog zu IKE/IPsec und GS-A_4382-* (Spiegelstrich 5) wird deshalb folgend mit A_21275-* eine Verwendung von SHA-1 bei der Signaturerstellung und -prüfung im Kontext des TLS-Handshakes untersagt.

A_21275-01 - TLS-Verbindungen, zulässige Hashfunktionen bei Signaturen im TLS-Handshake

Alle Produkttypen, die Übertragungen mittels TLS durchführen, MÜSSEN sicherstellen, dass

1. sie im Rahmen der Erstellung und Prüfung von digitalen Signaturen im Rahmen des TLS-Handshakes ausschließlich folgende kryptographisch geeignete Hashfunktionen verwenden: 
   1. SHA-256, SHA-384, SHA-512 [FIPS-180-4]
   2. SHA3-256, SHA3-384, SHA3-512 [FIPS-202]
2. sie dabei mindestens SHA-256 unterstützen,

(Bitte die Umsetzungshinweise in Bezug auf die "signature_algorithms"-Extension in gemSpec_Krypt#A_21275-* beachten.) [<=]

Umsetzungshinweise zu A_21275-*:

Bei den Anwendungsfällen der TI-Anwendungen sind die Mehrzahl der TLS-Verbindungen einseitig authentisiert. D. h. beim TLS-Handshake signiert nur der TLS-Server dessen (EC)DH-Schlüssel. Bei der Initiierung der TLS-Verbindung sendet der TLS-Client in der "signature_algorithms"-Extension beim ClientHello. In der Extension werden alle vom Client unterstützen Hashfunktionen kodiert. Dort muss also nach A_21275-* mindestens SHA-256 enthalten sein. Bei TLS 1.2 wird von fast allen TLS-Bibliotheken ebenfalls SHA-1 angegeben, dieses Verhalten lässt sich im Normalfall nicht ohne Code-Änderungen in den Bibliotheken verändern -- dieses Verhalten widerspricht zunächst A_21275-*. Das bloße Aufführen von SHA-1 als grundsätzlich unterstützte Hashfunktion soll nicht als fehlerhaftes Verhalten gelten. Wichtig für die Umsetzung von A_21275-* sind die tatsächlich erstellten Signaturen und die Prüfung dieser Signaturen.

Informationen zu Algorithmen in der "signature_algorithms"-Extension findet man in [RFC-5246#7.4.1.4.1.] und [RFC-8446-4.2.3.], vgl. auch [RFC-9155].

GS-A_4384-0103 - TLS-Verbindungen

Alle Produkttypen, die Übertragungen mittels TLS durchführen, MÜSSEN die folgenden Vorgaben erfüllen:

• Zur Authentifizierung MUSS eine X.509-Identität gemäß [gemSpec_Krypt#GS-A_4359-*] verwendet werden.
• Als Cipher-Suite MÜSSEN TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 und TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 unterstützt werden.
• Beim ephemeren Elliptic-Curve-Diffie-Hellman-Schlüsselaustausch (vgl. "ECDHE" im Namen der Cipher-Suites) MÜSSEN die Kurven P-256 und P-384 [FIPS-186-45] unterstützt werden. Es SOLLEN die Kurven brainpoolP256r1 und brainpoolP384r1 (vgl. [RFC-5639] und [RFC-7027]) unterstützt werden. Andere Kurven als in GS-A_4384-* aufgeführt DÜRFEN NICHT verwendet werden.
• Es KÖNNEN weitere Cipher-Suiten aus [TR-02102-2, Abschnitt 3.3.1 Tabelle 1] unterstützt werden. 

[<=]

Erläuterung zu GS-A_4384-*:

In einigen Konstellationen (ePA-FdV auf iOS-Geräten) ist die Verwendung von brainpool-Kurven nur schwer möglich. Dort bedeutet die SOLL-Bestimmung aus GS-A_4384-*, dass es zulässig ist auf die brainpool-Kurven-Unterstützung dort zu verzichten. 

Hinweis: hinter den folgenden Identifier-n verbirgt sich kryptographisch gesehen jeweils die gleiche Kurve:

Analog P-384 [FIPS186-45]:

GS-A_5541 - TLS-Verbindungen als TLS-Klient zur Störungsampel oder SM

Alle Produkttypen, die das TLS-Protokoll als TLS-Klient zur Störungsampel oder zum Service-Monitoring verwenden, KÖNNEN

(1) auf die explizite Prüfung, dass der TLS-Server die (EC)DH-Gruppe für den ephemeren (EC)DH-Schlüsselaustausch spezifikationskonform gewählt hat (vgl. GS-A_4384-* und A_17124-* Punkt 4), verzichten,

und

(2) davon ausgehen, dass der TLS-Server die Auswahl der TLS-Verbindungsparameter (TLS-Version, TLS-Ciphersuite etc.) korrekt, i.S.v. spezifikationskonform, durchführt.

[<=]

GS-A_5580-01 - TLS-Klient für betriebsunterstützende Dienste

Alle Produkttypen, die das TLS-Protokoll als TLS-Klient für Betriebsunterstützende Dienste (Service-Monitoring, Betriebsdaten-Erfassung etc.) verwenden, MÜSSEN das vom Betriebsunterstützenden Dienst präsentierte Zertifikat prüfen. Für diese Prüfung MUSS entweder TUC_PKI_018 oder die vereinfachte Zertifikatsprüfung (GS-A_5581 „TUC  vereinfachte  Zertifikatsprüfung“ (Komponenten-PKI)) verwendet werden. [<=]

A_22430 - TLS-Klient für betriebsunterstützende Dienste im Internet

Alle Produkttypen, welche die Betriebsdatenerfassung im Internet nutzen, MÜSSEN prüfen, ob das von der Betriebsdatenerfassung an der Internetschnittstelle während des TLS-Verbindungsaufbaus präsentierte TLS-Serverzertifikat gültig ist (d. h. u. a. per Zertifikatsprüfung rückführbar auf ein CA-Zertifikat einer CA, die die "CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" (https://cabforum.org/baseline-requirements-documents/) erfüllt) und für den erwarteten FQDN ausgestellt wurde. Bei negativen Prüfergebnis MUSS der TLS-Verbindungsaufbau zur Betriebsdatenerfassung abgelehnt werden. [<=]

Bei  bestimmten  Produkttypen,  bspw.  TSPs,  beschränkt  sich  die  Prüfung  von  Zertifikaten beim TLS-Verbindungsaufbau in Bezug auf die TI ausschließlich auf die Prüfung des Zertifikats des Service Monitorings oder anderer betriebsunterstützender Dienste. Dafür ist der TUC_PKI_018 unangemessen leistungsstark und komplex. Deshalb wird folgend mit GS-A_5581 eine passgenauere Zertifikatsprüfung als Alternative definiert.

GS-A_5581 - "TUC vereinfachte Zertifikatsprüfung“ (Komponenten-PKI)

Alle  Produkttypen,  die  eine  Zertifikatsprüfung konform  zu  in  dieser  Anforderung  definierten „TUC vereinfachte Zertifikatsprüfung“ durchführen wollen, erreichen dies indem sie folgende Vorgaben erfüllen.
(1) Es MUSS einen Prozess geben der authentisch und integer die Komponenten-CA-Zertifikate der TI regelmäßig (mindestens einmal pro Monat) ermittelt. Diese sind Basis für die folgenden Prüfschritte. 
(2) Es MUSS geprüft werden, ob im vom TLS-Server präsentierten Zertifikat der korrekte  (i.  S.  v.  vom  TLS-Client  erwartete)  FQDN  enthalten  ist  (bspw.  monitoring-update.stampel.telematik).
(3) Es MUSS geprüft werden, ob das präsentierte Zertifikat per Signaturprüfung rückführbar ist zu einem der CA-Zertifikate aus (1).
(4) Es MUSS geprüft werden, ob das präsentierte Zertifikat zeitlich gültig ist.

Wenn einer der Prüfschritte aus (2) bis (4) fehlschlägt, MUSS der Verbindungsaufbau abgebrochen werden.  

Es gibt GS-A_5581 folgend in gemSpec_Krypt Anwendungshinweise. [<=]

Als Hilfestellung: für die Umsetzung von GS-A_5581 Spiegelstrich (1) kann man bspw. folgende Maßnahmen wählen.

(a) Übergabe bei einem Vororttermin in der gematik,

(b) Regelmäßiger Download über https://download.tsl.ti-dienste.de/

(c)  Verwendung  einer  dedizierten  Software  zum  Download,  Signaturprüfung  und Auswertung  der  TI-TSL  (es  existiert  dafür  jeweils mindestens eine Open-Source-Lösung und eine kommerzielle Lösung) 

(d) oder andere Lösung, die die Integrität und Authentizität der Zertifikate sicherstellt.

Ziel ist es, dass für die Verbindung zur Störungsampel oder zum Service Monitoring auch einfach verfügbare und einfach verwendbare HTTPS-Clienten wie wget oder curl verwendet werden können.

Unter der Annahme, dass

(a) im Verzeichnis /etc/TI-Komponenten-CAs die in GS-A_5581 Punkt (1) aufgeführten Zertifikate liegen und

(b) die an die Störungsampel zu sendende Information (i. d. R. unsignierte XML-Daten) in der Datei SOAP_Daten liegen,
erfüllen folgende Aufrufe die Punkt (2)-(4) aus GS-A_5581.
I.
wget --ca-directory=/etc/TI-Komponenten-CAs --post-file=SOAP_Daten https://monitoring-update.stampel.telematik:8443/I_Monitoring_Message
II.
curl --capath /etc/TI-Komponenten-CAs –d SOAP_Daten https://monitoring-
update.stampel.telematik:8443/I_Monitoring_Message

GS-A_5542 - TLS-Verbindungen (fatal Alert bei Abbrüchen)

Alle Produkttypen, die das TLS-Protokoll verwenden, MÜSSEN sicherstellen, dass alle von ihnen durchgeführten Verbindungsabbrüche (egal ob im noch laufenden TLS-Handshake oder in einer schon etablierten TLS-Verbindung) mit einer im TLS-Protokoll aufgeführten Fehlermeldung (fataler Alert) angekündigt werden, außer das TLS-Protokoll untersagt dies explizit.

[<=]

Sicherheitsziel bei der Verwendung von TLS in der TI ist die Forward Secrecy [BSI-TR-02102-1, S. ix], was sich u. a. in den vorgegebenen Cipher-Suites (vgl. GS-A_4384-* und A_17124-*) widerspiegelt. Um dieses Ziel zu erreichen, muss sichergestellt werden, dass in regelmäßigen Abständen frisches Schlüsselmaterial über einen authentisierten Diffie-Hellman-Schlüsselaustausch gebildet wird, welches das alte Material ersetzt, wobei das alte Material sowohl im Klienten als auch im Server sicher gelöscht wird. Insbesondere bei der Nutzung von TLS-Resumption (vgl. [RFC-5246, S. 36] oder [RFC-5077]) kann die Dauer einer TLS-Session deutlich länger sein als die Lebensdauer der TCP-Verbindung innerhalb welcher der initiale Schlüsselaustausch stattgefunden hat. Aus diesem Grunde werden analog zu den IPsec-Vorgaben (vgl. [gemSpec_Krypt#GS-A_4383]) Vorgaben für die maximale Gültigkeitsdauer dieses Schlüsselmaterials gemacht (vgl. auch [SDH-2016]).

GS-A_5322 - Weitere Vorgaben für TLS-Verbindungen

Alle Produkttypen, die Übertragungen mittels TLS durchführen, MÜSSEN u. a. folgende Vorgaben erfüllen:

• Falls der Produkttyp als Klient oder als Server im Rahmen von TLS an einer Session-Resumption mittels SessionID (vgl. [RFC-5246, Abschnitt 7.4.1.2]) teilnimmt, MUSS er sicherstellen, dass nach spätestens 24 Stunden das über den Diffie-Hellman-Schlüsselaustausch ausgehandelte Schlüsselmaterial und alles davon abgeleitete Schlüsselmaterial (vgl. [RFC-5246, Abschnitt 8.1 und 6.3]) bei ihm sicher gelöscht wird.
• Falls der Produkttyp als Klient im Rahmen von TLS an einer Session-Resumption nach [RFC-5077] teilnimmt, MUSS er sicherstellen, dass nach spätestens 24 Stunden das über den Diffie-Hellman-Schlüsselaustausch ausgehandelte Schlüsselmaterial und alles davon abgeleitete Schlüsselmaterial (vgl. [RFC-5246, Abschnitt 8.1 und 6.3]) bei ihm sicher gelöscht wird. Damit verbundene SessionTickets MUSS er ebenfalls sicher löschen.
• Falls der Produkttyp als Server im Rahmen von TLS an einer Session-Resumption nach [RFC-5077] teilnimmt, MUSS er sicherstellen, dass nach spätestens 24 Stunden das über den Diffie-Hellman-Schlüsselaustausch ausgehandelte Schlüsselmaterial und alles davon abgeleitete Schlüsselmaterial (vgl. [RFC-5246, Abschnitt 8.1 und 6.3]) bei ihm sicher gelöscht wird. Damit verbundene SessionTickets MUSS er, falls bei ihm vorhanden, sicher löschen. Das Schlüsselmaterial, dass bei der Erzeugung des SessionTickets (für die Sicherung von Vertraulichkeit und Authentizität der SessionTickets) verwendet wird, MUSS spätestens alle 48 Stunden gewechselt werden und das alte Material MUSS sicher gelöscht werden. Als kryptographische Verfahren zur Erzeugung/Sicherung der SessionTickets MÜSSEN ausschließlich nach [BSI-TR-03116-1] zulässige Verfahren verwendet werden und das Schlüsselmaterial muss die Entropieanforderungen gemäß [gemSpec_Krypt#GS-A_4368] erfüllen.
• Falls ein Produkttyp als Klient oder Server im Rahmen von TLS die Renegotiation unterstützt, so MUSS er dies ausschließlich nach [RFC-5746] tun. Ansonsten MUSS er die Renegotiation-Anfrage des Kommunikationspartners ablehnen.

[<=]

Aktuell gibt es in der TI keine Anwendungsfälle (Wechsel der kryptographischen Identität innerhalb einer TLS-Verbindung oder erzwungene Schlüssel-„Auffrischung“ der Sitzungsschlüssel), die eine Session-Renegotiation im Rahmen von TLS unmittelbar erforderlich machen. Lesenswert bez. des Themas Sicherheitsprobleme mit TLS-Session-Renegotiation ist [IR-2014, S.181ff] und allgemein [CM-2014].

Es hat sich gezeigt, dass es notwendig ist weitere Vorgaben zur TLS-Renegotiation für die Sicherstellung der Interoperabilität zwischen Komponenten und Diensten zu machen.

GS-A_5524 - TLS-Renegotiation eHealth-KT

Das eHealth-KT MUSS beim einen TLS-Verbindungsaufbau die TLS-Extension „renegotiation_info“ gemäß [RFC-5746] senden, unabhängig davon ob das eHealth-KT TLS-Renegotiation unterstützt oder nicht unterstützt. Im weiteren TLS-Protokollverlauf MUSS das eHealth-KT eines der beiden folgenden Verhalten aufweisen:

1. Entweder das eHealth-KT lehnt jede Renegotiation mit einem „no_renegotiation“-Alert ab, oder
2. das eHealth-KT unterstützt die Renegotiation gemäß [RFC-5746], wobei ausschließlich „Secure Renegotiation“ durch das eHealth-KT akzeptiert werden (d.h., falls das „secure_renegotiation“-flag [RFC-5746#3.7] gleich FALSE ist, muss das KT die Renegotiation mit einem „no_renegotiation“-Alert ablehnen).

[<=]

GS-A_5525 - TLS-Renegotiation Konnektor

Der Konnektor MUSS den RFC 5746 (TLS-Renegotiation-Indication-Extension [RFC-5746]) unterstützen und nur „Secure Renegotiation“ erlauben und durchführen.

[<=]

Für eine Java-Implementierung bedeutet dies, dass allowLegacyHelloMessages und allowUnsafeRenegotiation jeweils auf false gesetzt sind ("Modus Strict", http://www.oracle.com/technetwork/java/javase/overview/tlsreadme2-176330.html ).

Da der Angriff [Ray-2009], der zur Erstellung des [RFC-5746] führte, praktisch durchführbar war, wurde die Mehrzahl der existierenden TLS-Bibliotheken relativ zügig angepasst (Timeline in [IR-2014, S. 190, Abbildung 7.2]). (Vgl. die erste Spalte „Secure Renegotiation“ bei https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Extensions ) Um für den unwahrscheinlichen Fall, dass aktuell ein schon bestehender Fachdienst Probleme bei der Umsetzung der folgenden Anforderung hat, wurde diese als SOLL-Anforderung formuliert. Es ist geplant diese Anforderung zukünftig in eine MUSS-Anforderung zu ändern.

GS-A_5526 - TLS-Renegotiation-Indication-Extension

Alle Produkttypen, die das TLS-Protokoll verwenden, SOLLEN den RFC 5746 (TLS-Renegotiation-Indication-Extension [RFC-5746]) unterstützen.

[<=]

Die folgende Anforderung hat den Zweck die Interoperabilität zwischen Konnektor und Intermediär sicherzustellen.

GS-A_5527 - TLS-Renegotiation-Indication-Extension Intermediär

Der Intermediär MUSS den RFC 5746 (TLS-Renegotiation-Indication-Extension [RFC-5746]) unterstützen und nur „Secure Renegotiation“ erlauben und durchführen.

[<=]

Für eine verbesserte Interoperabilität zu bestimmten TLS-Implementierungen (bspw. SChannel, vgl. auch ( https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations bzw. https://www.ssllabs.com/ssltest/clients.html) sollen im Konnektor zusätzlich zu den Cipher-Suiten aus GS-A_4384-* weitere Cipher-Suiten unterstützt werden. Mit der mittelfristigen Anhebung des zu erreichenden Sicherheitsniveaus auf 120 Bit (vgl. [SOG-IS-2020] und [BSI-TR-03116-1]) werden die folgenden Cipher-Suiten mittelfristig verpflichtend. In diesem Kontext spielt die Performanz (3000 Bit Diffie-Hellman vs. 256 Bit Elliptic Curve Diffie-Hellman) bei Embedded-Geräten wie dem Konnektor eine wichtige Rolle.

GS-A_5345-0104 - TLS-Verbindungen Konnektor

Der Konnektor MUSS für die TLS gesicherten Verbindungen neben den in [gemSpec_Krypt#GS-A_4384-*] aufgeführten Ciphersuiten folgende Vorgaben umsetzen:
 

1. Der Konnektor MUSS zusätzlich folgende Ciphersuiten unterstützen:

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xC0, 0x27), 
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xC0, 0x28), 
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xC0, 0x2f) und 
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC0, 0x30). 

1. Der Konnektor KANN weitere Ciphersuiten aus [TR-02102-2, Abschnitt 3.3.1 Tabelle 1] unterstützen.
2. Falls Ciphersuiten aus Spiegelstrich (1) oder (2) unterstützt werden,
   1.     MÜSSEN bei dem ephemeren Elliptic-Curve-Diffie-Hellman-Schlüsselaustausch die Kurven P-256 und P-384 [FIPS-186-45] unterstützt werden,
   2.     MÜSSEN die Kurven brainpoolP256r1 und brainpoolP384r1 (vgl. [RFC-5639] und [RFC-7027]) unterstützt werden.

   Andere Kurven SOLLEN NICHT verwendet werden.

1. Falls Ciphersuiten aus (1) oder (2) unterstützt werden, so MÜSSEN diese im CC-Zertifizierungsverfahren berücksichtigt werden.

[<=]

A_23226-01 - TLS-Verbindung, Konnektor: Legacy-KT-Unterstützung

Der Konnektor MUSS für die Unterstützung von alten eHealth-KT folgende TLS-Vorgaben ebenfalls unterstützen:

• Als Cipher Suite MUSS TLS_DHE_RSA_WITH_AES_128_CBC_SHA oder TLS_DHE_RSA_WITH_AES_256_CBC_SHA unterstützt werden.
• Dabei MUSS für die Schlüsselaushandlung Gruppe 14 (definiert in [RFC-3526], verwendbar bis Ende 2025) verwendet werden.
• Der private DH-Exponent für den Schlüsselaustausch MUSS eine Länge von mindestens 256 Bit haben.

[<=]

A_18183 - TLS-Protokoll-Verwendung in WANDA Basic

Falls ein Anbieter einer anderen Anwendung des Gesundheitswesens ohne Zugriff auf Dienste der TI in angeschlossenen Netzen des Gesundheitswesens (WANDA Basic) das TLS-Protokoll verwendet, so MUSS er dabei ausschließlich Ciphersuiten und Domainparameter (Schlüssellängen, Kurvenparameter etc.), die nach [TR-02102-2] empfohlen sind, verwenden. [<=]

Erläuterung: Eine andere Anwendung des Gesundheitswesens ohne Zugriff auf Dienste der TI in angeschlossenen Netzen des Gesundheitswesens (WANDA Basic) muss beim TLS-basierten Nachrichtentransport durch die TI nach [TR-02102-2] sichere Cipher-Suiten und Domainparameter verwenden. Für solch eine Anwendung ist eine die Interoperabilität mit TI-Diensten sicherstellende Einschränkung der Cipher-Suiten und Domainparameter nach GS-A_4384-* und A_17124-* nicht notwendig, d. h. beide Anforderungen gelten nicht für solche Anwendungen, sondern A_18183 gilt.

Gleiches gilt für die Verwendung von TLS für die Anbindung von Leistungserbringernetzen an das TI-Gateway, da bei dieser VPN-Anbindung Client und Server Teil des selben Produkttyps sind (TI-Gateway Zugangsmodul).

A_24779 - TI-Gateway-Zugangsmodul - TLS-Cipher-Suiten

Das TI-Gateway Zugangsmodul MUSS, falls es das TLS-Protokoll für die Sicherung der Datenübertragung aus dem Nutzernetzwerk zum TI-Gateway Zugangsmodul verwendet (vgl. A_23351*), ausschließlich TLS-Cipher-Suiten aus [TR-02102-2, Abschnitt 3.3.1 Tabelle 1] mit den dort vorgegebenen Domainparametern (Schlüssellänge, ECC-Kurven-Parameter etc.) verwenden bzw. bei Verwendung von TLS 1.3 die Vorgaben aus [TR-02102-2, Abschnitt 3.4] befolgen.  [<=]

A_18986 - Fachdienst-interne TLS-Verbindungen

Alle Produkttypen, die Übertragungen mittels TLS durchführen, die nur innerhalb ihres Produkttypen verlaufen (bspw. ePA-Aktensystem interne TLS-Verbindungen zwischen dem Zugangsgateway und der Komponente Authentisierung), KÖNNEN für diese TLS-Verbindungen neben den in GS-A_4384-* und ggf. A_17124-* festgelegten TLS-Vorgaben ebenfalls alle weiteren in [TR-02102-2] empfohlenen TLS-Versionen und TLS-Ciphersuiten mit den jeweiligen in [TR-02102-2] dafür aufgeführten Domainparametern (Kurven, Schlüssellängen etc.) verwenden. [<=]

Erläuterung: A_18986 ”befreit” Produkttypen-interne TLS-Verbindungen von der Beschränkung auf die Vorgaben von GS-A_4384-* und ggf. A_17124-* und erweitert diese Vorgaben auf die Gesamtheit der in [TR-02102-2] empfohlenen TLS-Konfigurationen.

Hinweis: In Abschnitt "3.15.3 ePA-spezifische TLS-Vorgaben " gibt es weitere TLS-Vorgaben.

3.3.3 DNSSEC-Kontext

Hinweis: Die Verwendung von DNSSEC innerhalb der TI wird seit 2018 nicht mehr in den TI-Spezifikationen vorgeschrieben. DNSSEC wird in der TI von den meisten Komponenten und Fachdiensten nicht mehr verwendet. Die Unterstützung von DNSSEC in den DNS-Servern der TI wird nur noch für Legacy-Anwendungen weiterbetrieben. In der TI sind fast alle Kommunikationen über TLS und damit über die PKI der TI abgesichert.

GS-A_4388 - DNSSEC-Kontext

Alle Produkttypen, die DNSSEC verwenden, MÜSSEN die Algorithmen und Vorgaben gemäß Tabelle Tab_KRYPT_017 erfüllen.

[<=]

Tabelle 12: Tab_KRYPT_017 Algorithmen für DNSSEC

Hinweis: Nach [RFC-5702] ist die Verwendung von SHA-256 [FIPS-180-4] möglich. Schlüssellängen von RSA zwischen 512 bis 4096 Bit sind seit den Anfängen von DNSSEC möglich. Bei TSIG ist nach [RFC-4635] auch SHA-256 verwendbar und bspw. von bind seit der Version 9.5 unterstützt.

3.4 Masterkey-Verfahren (informativ)

Die gematik wurde aufgefordert, beispielhaft ein mögliches Ableitungsverfahren für einen versichertenindividuellen symmetrischen Schlüssel auf Grundlage eines Ableitungsschlüssels (Masterkey) aufzuführen. Ein Kartenherausgeber ist frei in der Wahl seines Ableitungsverfahrens. Jedoch müssen beim Einsatz eines Ableitungsverfahrens, um die Qualität der Ableitung zu garantieren, insbesondere folgende Punkte beachtet werden:

• Der Ableitungsprozess muss unumkehrbar und nicht-vorhersehbar sein, um sicherzustellen, dass die Kompromittierung eines abgeleiteten Schlüssels nicht den Ableitungsschlüssel oder andere abgeleitete Schlüssel kompromittiert.
• Bei einer Schlüsselableitung (im Sinne von [ISO-11770]) basiert die kryptographische Stärke der abgeleiteten Schlüssel auf der Ableitungsfunktion und der kryptographischen Stärke des geheimen Ableitungsschlüssels (insbesondere hier dessen Entropie). Die Entropie der abgeleiteten Schlüssel ist kleiner gleich der Entropie des geheimen Ableitungsschlüssels. Um die Entropie der abgeleiteten Schlüssel sicherzustellen, muss die Entropie des geheimen Ableitungsschlüssels (deutlich) größer sein als die zu erreichende Entropie der abgeleiteten Schlüssel.
• Der Betreiber eines Schlüsseldienstes muss im Falle des Einsatzes einer Schlüsselableitung (nach [ISO-11770]) in seinem Sicherheitskonzept Maßnahmen für das Bekanntwerden von Schwächen des kryptographischen Verfahrens, welche die Grundlage der Schlüsselableitung ist, darlegen.

Ein Kartenherausgeber hat auch die Freiheit, gar kein Ableitungsverfahren zu verwenden, sondern alle symmetrischen SK.CMS aller seiner Karten sicher in seinem RZ vorzuhalten.

Ziel des Masterkey-Verfahrens zur Ableitung eines versichertenindividuellen Schlüssels ist es, aus einem geheimen Masterkey und einem öffentlichen versichertenindividuellen Merkmal einen geheimen symmetrischen Schlüssel abzuleiten, der zur Absicherung der Verbindung zwischen CMS und Smartcard verwendet wird. Öffentlich bedeutet an dieser Stelle nicht, dass die Merkmale selbst nicht schützenswert sind, es soll jedoch ausdrücken, dass die Vertraulichkeit des versichertenindividuellen Schlüssels nicht von der Geheimhaltung dieser Merkmale abhängt. Die Vertraulichkeit der Daten muss durch die Geheimhaltung des Masterkeys gewährleistet sein. Das bedeutet, die Geheimhaltung anderer Daten als des Masterkeys darf für die Vertraulichkeit der Daten nicht notwendig sein. Die Durchführung dieses Verfahrens muss bei gleichen Eingangsparametern immer das gleiche Ergebnis generieren.

Für die Durchführung des Algorithmus wird neben dem Masterkey auch noch mindestens ein versichertenindividuelles Merkmal verwendet. Die Auswahl des Merkmals ist fachlich motiviert und wird daher in diesem Dokument nicht spezifiziert. Das in Tabelle 20 beispielhafte Verfahren besteht aus einer Kombination von AES-Verschlüsselung [FIPS-197] und Hashwert-Bildung. Die Schlüssel- bzw. Hashwert-Länge ergibt sich gemäß Tabelle 21 .

Tabelle 13: Tab_KRYPT_018 Ablauf zur Berechnung eines versichertenindividuellen Schlüssels

In der nachfolgenden Tabelle werden Kürzel entsprechend der Definition aus Abschnitt 3.2.3 verwendet.

Tabelle 14: Tab_KRYPT_019 eingesetzte Algorithmen für die Ableitung eines versichertenindividuellen Schlüssels

3.5 Hybride Verschlüsselung binärer Daten

Für die hybride Verschlüsselung werden die Daten zunächst symmetrisch mittels eines zufällig gewählten geheimen symmetrischen Schlüssels verschlüsselt. Der geheime Schlüssel wird im Anschluss asymmetrisch für jeden Empfänger separat verschlüsselt.

Hinweis: unter binären Daten sind im gesamten Dokument beliebige Daten insbesondere beliebigen Typs (Text, HTML, PDF, JPG etc.) zu verstehen. Es gilt das Prinzip: das Spezielle vor dem Allgemeinen: gibt es weitere spezielle Vorgaben für bestimmte Datenformate, sind diese für die entsprechenden Daten verpflichtend (überschreiben oder ergänzen die allgemeinen Vorgaben).

3.5.1 Symmetrischer Anteil der hybriden Verschlüsselung binärer Daten

GS-A_4389 - Symmetrischer Anteil der hybriden Verschlüsselung binärer Daten

Produkttypen, die die hybride Verschlüsselung binärer Daten durchführen, MÜSSEN für den symmetrischen Anteil der Verschlüsselung die folgenden Vorgaben berücksichtigen:

• Als symmetrische Block-Chiffre muss AES [FIPS-197] mit einer Schlüssellänge von 256 Bit im Galois/Counter Mode (GCM) gemäß [NIST-SP-800-38D] mit der Tag-Länge von 128 Bit verwendet werden.
• Die IVs dürfen sich bei gleichem Schlüssel nicht wiederholen (vgl. [NIST-SP-800-38D#S.25] und [BSI-TR-02102-1#S.24]). Der IV soll eine Bitlänge von 96 Bit besitzen, seine Länge muss mindestens 96 Bit sein. Es wird empfohlen den IV zufällig zu wählen (vgl. [gemSpec_Krypt#GS-A_4367]).
• Hinweis: Im Normalfall ist davon auszugehen, dass für die Sicherung der Integrität und Authentizität der zu verschlüsselnden Daten zudem noch eine Signatur dieser Daten notwendig ist.

[<=]

Hinweis: In [RFC-5084] findet man Informationen über die Verwendung von AES-GCM innerhalb von CMS [RFC-5652].

3.5.2 Asymmetrischer Anteil der hybriden Verschlüsselung binärer Daten

GS-A_4390 - Asymmetrischer Anteil der hybriden Verschlüsselung binärer Daten

Produkttypen, die die hybride Verschlüsselung binärer Daten durchführen, MÜSSEN für den asymmetrischen Anteil der Verschlüsselung die folgenden Vorgaben berücksichtigen:

• Als asymmetrisches Verschlüsselungsverfahren MUSS RSAES-OAEP gemäß [PKCS#1, Kapitel 7.1] verwendet werden.
• Als Mask-Generation-Function für die Verwendung in RSAES-OAEP MUSS MGF 1 mit SHA-256 als Hash-Funktion gemäß [PKCS#1, Anhang B.2.1] verwendet werden.

[<=]

3.6 Symmetrische Verschlüsselung binärer Daten

GS-A_5016 - Symmetrische Verschlüsselung binärer Daten

Produkttypen, die die symmetrische Verschlüsselung binärer Daten durchführen, MÜSSEN die folgenden Vorgaben berücksichtigen:

• Als symmetrische Block-Chiffre muss AES [FIPS-197] mit einer Schlüssellänge von 256 Bit im Galois/Counter Mode (GCM) gemäß [NIST-SP-800-38D] mit der Tag-Länge von 128 Bit verwendet werden.
• Die IVs dürfen sich bei gleichem Schlüssel nicht wiederholen (vgl. [NIST-SP-800-38D#S.25] und [BSI-TR-02102-1#S.24]). Der IV soll eine Bitlänge von 96 Bit besitzen, seine Länge muss mindestens 96 Bit sein. Es wird empfohlen den IV zufällig zu wählen (vgl. [gemSpec_Krypt#GS-A_4367]).
• Hinweis: Im Normalfall ist davon auszugehen, dass für die Sicherung der Integrität und Authentizität der übertragenen Daten zudem noch eine Signatur der zu verschlüsselnden Daten notwendig ist.

[<=]

Hinweis: In [RFC-5084] findet man Informationen über die Verwendung von AES-GCM innerhalb von CMS [RFC-5652].

A_15561 - AES-NI

Wenn der eingesetzte Konnektor AES-NI unterstützt und AES-NI dort aktiviert ist (vgl. [BSI-TR-03116-1#Abschnitt "4.7  Hardware-Unterstützung AES (AES-NI)"]), MUSS der Konnektor für alle AES-Ausführungen die AES-NI verwenden. [<=]

3.7 Signatur binärer Inhaltsdaten (Dokumente)

GS-A_5080-01 - Signaturen binärer Daten (Dokumente)

Alle Produkttypen, die CMS-Signaturen [RFC-5652] von Inhaltsdaten (wie bspw. Textdokumenten ungleich PDF/A) erzeugen oder prüfen, MÜSSEN die Algorithmen und Vorgaben der Tabelle Tab_KRYPT_020 erfüllen. [<=]

Tabelle 15: Tab_KRYPT_020 Algorithmen für die Erzeugung und Prüfung von binären Daten im Kontext von Dokumentensignaturen

3.8 Signaturen innerhalb von PDF/A-Dokumenten

GS-A_5081-01 - Signaturen von PDF/A-Dokumenten

Alle Produkttypen, die in PDF/A-Dokumenten [PDF/A-2] Signaturen einbetten/erzeugen oder diese Signaturen prüfen, MÜSSEN die Algorithmen und Vorgaben der Tabelle Tab_KRYPT_021 erfüllen. [<=]

Tabelle 16: Tab_KRYPT_021 Algorithmen für die Erzeugung und Prüfung von PDF/A-Dokumentensignaturen

3.9 Kartenpersonalisierung

Vgl. auch Abschnitt 2.4 (Schlüsselerzeugung)2.4 Schlüsselerzeugung und Schlüsselbestätigung .

GS-A_4391 - MAC im Rahmen der Personalisierung der eGK

Der Herausgeber der eGK MUSS sicherstellen, dass bei der Personalisierung der eGK die Daten bei der Übermittlung integritätsgeschützt werden. Für die Absicherung der Integrität ist in diesem Kontext der AES-256 CMAC nach [NIST-SP-800-38B] (vgl. [BSI-TR-03116-1#3.2.2, 4.5.2]) zu verwenden.

Die Länge des CMAC muss 128 Bit betragen.

Nach [NIST-SP-800-38B#S.13] sollen nicht mehr als 248 Nachrichtenblöcke (222 GByte) mit demselben Schlüssel verarbeitet werden. Nach [NIST-SP-800-38B#S.14] ist ein CMAC anfällig für Replay-Attacken, was bei der Anwendung des CMACs zu berücksichtigen ist.

[<=]

3.10 Bildung der pseudonymisierten Versichertenidentität

GS-A_4392 - Algorithmus im Rahmen der Bildung der pseudonymisierten Versichertenidentität

Alle Produkttypen, die pseudonymisierte Versichertenidentitäten berechnen, MÜSSEN den Hash-Algorithmus SHA-256 [FIPS-180-4] verwenden. [<=]

3.11 Spezielle Anwendungen von Hashfunktionen

GS-A_4393 - Algorithmus bei der Erstellung von Hashwerten von Zertifikaten oder öffentlichen Schlüsseln

Alle Produkttypen, die Fingerprints eines öffentlichen Schlüssels oder eines Zertifikates erstellen, MÜSSEN den Hash-Algorithmus SHA-256 [FIPS-180-4] dafür verwenden. [<=]

Erläuterung:

Alle CAs und der TSL-Dienst müssen im Rahmen ihrer Prozesse öffentliche Schlüssel oder Zertifikate (bspw. auf Webseiten) veröffentlichen. Dabei wird auch jeweils der SHA-256 Hashwert mit veröffentlicht.

Hersteller einer gSMC-KT müssen den Hashwert des auf der Karte befindlichen Zertifikats in MF/DF.KT/EF.C.SMKT.AUT.R2048 entweder auf dem ID-1-Kartenkörper drucken (das ID-000-Modul ist dann herausbrechbar) oder ausgedruckt mitliefern. Der Konnektor muss den Hashwert des Zertifikats bei initialen Pairing mit dem KT berechnen und dem Administrator präsentieren.

Innerhalb der CertHash-Extension als Teil einer OCSP-Response wird vom TSP ein SHA-256 Hashwert des Zertifikats, über das eine Sperrinformation gegeben wird, mitgeliefert.

GS-A_5131 - Hash-Algorithmus bei OCSP/CertID

Alle Produkttypen, die OCSP-Anfragen stellen oder beantworten, MÜSSEN bei der Erstellung und Verwendung der CertID-Struktur (vgl. [RFC-6960, Abschnitt 4.1.1] oder [RFC-2560, Abschnitt 4.1.1]) den Hash-Algorithmus SHA-1 [FIPS-180-4] verwenden.

Ein OCSP-Server KANN auch zusätzlich andere Hashfunktionen im Rahmen der CertID, die nach [BSI-TR-03116-1] zulässig sind, unterstützen.

[<=]

3.11.1 Hashfunktionen und OCSP (informativ)

Es hat sich gezeigt, dass zum folgenden Themenkomplex eine Erläuterung hilfreich ist.

Im Zusammenspiel OCSP-Anfrage und OCSP-Antwort werden an drei Stellen Hashfunktionen verwendet, die theoretisch alle paarweise verschieden sein können.

Erste Stelle: Zunächst erzeugt ein OCSP-Client eine OCSP-Anfrage (vgl. [RFC-6960, Abschnitt 4.1.1] oder [RFC-2560, Abschnitt 4.1.1]). Dafür muss dieser u. a. eine CertID-Datenstruktur erzeugen:

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of issuer's public key
       serialNumber        CertificateSerialNumber }

Bei der Wahl der Hashfunktion kann er sich nur darauf verlassen, dass der OCSP-Responder als Hashalgorithmus (vgl. „hashAlgorithm“-Datenfeld) SHA-1 [FIPS-180-4] unterstützt. Für den Anfragenden und den OCSP-Responder gilt dementsprechend GS-A_5131. Er muss SHA-1 für die CertID-Struktur verwenden. Ein OCSP-Responder, der zusätzlich weitere Hashfunktionen unterstützt, muss nichts zurückbauen – er darf auch so in der TI arbeiten.

Warum ist der Einsatz von SHA-1 an dieser Stelle kryptographisch gesehen ausreichend? Da (1) ein OCSP-Responder der TI nicht für beliebige CAs arbeitet (Wahl von DN und öffentlichen Schlüssel ist damit beschränkt) und (2) i. d. R. die CertHash-Extension Teil der OCSP-Antwort ist und innerhalb der CertHash-Extension in der TI eine kryptographisch hochwertige Hashfunktion verwendet wird, ist die Verwendung von SHA-1 hier aus Sicherheitssicht betrachtet unbedenklich. (Vgl. analoges Vorgehen BNetzA-OCSP-Responder für den qualifizierten Vertrauensraum.) Es ist also sichergestellt, dass zwischen OCSP-Client und -Responder keine (evtl. von einem Angreifer böswillig herbeigeführten) Unklarheiten darüber entstehen können über welches Zertifikat gerade gesprochen wird. Es geht bei GS-A_5131 vornehmlich um die Interoperabilität von OCSP-Client und OCSP-Responder.

Die optionale Signatur einer OCSP-Anfrage wird in der TI nicht verwendet, damit ist die dort verwendete Hashfunktion für die aktuelle Betrachtung irrelevant.

Zweite Stelle: Für die Beantwortung der OCSP-Anfrage erzeugt der OCSP-Responder u. a. eine CertHash-Datenstruktur:

id-commonpki-at-certHash OBJECT IDENTIFIER ::= {1 3 36 8 313}
CertHash ::= SEQUENCE {
     hashAlgorithm   AlgorithmIdentifier,  -- The identifier
     -- of the algorithm that has been used the hash value below.
     certificateHash OCTET STRING }

Hierfür muss eine kryptographisch hochwertige (nach [BSI-TR-03116-1] zulässige) Hashfunktion verwendet werden. Normativ ist an dieser Stelle: „GS-A_4393 Algorithmus bei der Erstellung von Hashwerten von Zertifikaten oder öffentlichen Schlüsseln“. Spätestens an dieser Stelle können OCSP-Client und OCSP-Server sich sicher sein, ob sie über das gleiche Zertifikat sprechen.

Dritte Stelle: Die OCSP-Response muss am Ende vom OCSP-Responder signiert werden. Dafür ist die Vorgabe aus Tab_KRYPT_002 „Signatur der OCSP-Response“ normativ, welche über die für die jeweiligen Zertifikate geltenden Anforderungen (bspw. GS-A_4357-0102) angezogen werden.

3.12 kryptographische Vorgaben für die SAK des Konnektors

GS-A_5071-01 - kryptographische Vorgaben für eine Signaturprüfung in der SAK-Konnektor

Die SAK des Konnektors MUSS bei der Prüfung von qualifizierten elektronischen Signaturen mindestens folgende Verfahren wie im Algorithmenkatalog [ALGCAT] benannt, unterstützen:

• RSA
  • SHA-256, SHA-384, SHA-512 nach FIPS-180-4 (März 2012) [FIPS-180-4] (jeweils Abschnitt 6.2, 6.7, 6.5 und 6.4 ebenda),
  • RSASSA-PSS nach PKCS#1 (PKCS#1 v2.1: RSA Cryptographic Standard, 14.06.2002) Abschnitt 8.1 und 9.1,
  • RSASSA-PKCS1-v1_5 nach PKCS#1 (PKCS#1 v2.1: RSA Cryptographic Standard, 14.06.2002) Abschnitt 8.2 und 9.2,
  • bei RSA muss ein Modulus zwischen 1976 bis 4096 Bit verwendbar sein,
• ECDSA
  • SHA-256 nach FIPS-180-4 (März 2012) [FIPS-180-4] (Abschnitt 6.2),
  • ECDSA basierend auf E(F_p) (vgl. Technische Richtlinie 03111, Version 2.0) auf der Kurve P256r1 [RFC-5639].

[<=]

3.13 Migration im PKI-Bereich

GS-A_5079 - Migration von Algorithmen und Schlüssellängen bei PKI-Betreibern

Der Anbieter einer Schlüsselverwaltung MUSS neue Vorgaben zu Algorithmen und/oder Schlüssellängen der gematik nach einer vorgegebenen Übergangsfrist umsetzen. Nach Ablauf der Übergangsfrist MÜSSEN ausschließlich diese geänderten Parameter bei der Erzeugung von Zertifikaten verwendet werden. [<=]

3.14 Spezielle Anwendungen von kryptographischen Signaturen

GS-A_5207 - Signaturverfahren beim initialen Pairing zwischen Konnektor und eHealth-Kartenterminal

Alle Produkttypen, die beim initialen Pairing zwischen Konnektor und eHealth-Kartenterminal

1. die Signatur des Shared-Secret (ShS.AUT.KT vgl. [gemSpec_KT#2.5.2.1, 3.7.2.1]) erzeugen oder prüfen, und
2. auf Basis von RSA die TLS-Verbindung betreiben, die für das aktuell durchzuführende Pairing notwendig ist,

MÜSSEN für die Signatur des Shared-Secret und dessen Signaturprüfung RSASSA-PSS [PKCS#1] verwenden.
[<=]

Erläuterung: Beim initialen Pairing zwischen Konnektor und eHealth-Kartenterminal wird vom Konnektor ein 16 Byte langes Geheimnis erzeugt, das bei späteren Verbindungsaufbauten zwischen Konnektor und KT im Rahmen eines Challenge-Response-Verfahrens ([gemSpec_KT#3.7.2]) verwendet wird. Dieses Geheimnis wird von der gSMC-KT des KT beim initialen Pairing signiert. Die Signatur wird vom KT zum Konnektor transportiert und dort vom Konnektor geprüft.

GS-A_5208 - Signaturverfahren für externe Authentisierung

Der Konnektor MUSS an der Schnittstelle für die externe Authentisierung die Signaturverfahren RSASSA-PKCS1-v1_5 [PKCS#1] und RSASSA-PSS [PKCS#1] anbieten. [<=]

Erläuterung: Der Konnektor erlaubt (bei entsprechender Berechtigung) die direkte Nutzung der privaten Schlüssel MF/ DF.ESIGN/ PrK.HP.AUT.* auf einem HBA oder MF/ DF.ESIGN/ PrK.HCI.AUT.* auf einer SMC-B durch ein Primärsystem. Dies wird fast immer für eine klientenseitige TLS-Authentisierung gegenüber einem TLS-Server (außerhalb der TI) verwendet. Dafür werden über die Schnittstelle RSASSA-PKCS1-v1_5-Signaturen von den entsprechenden Karten erzeugt und über den Konnektor an ein Primärsystem übergeben. Für unbenannte Anwendungen müssen auch RSASSA-PSS-Signaturen erzeugbar sein. Diese Signaturen sind nicht als Dokumentensignaturen verwendbar, der Verwendungszweck ist in den zu den privaten Schlüsseln gehörigen Zertifikaten kodiert (ExtendedKeyUsage: keyPurposeId = id-kp-clientAuth).

Hinweis: GS-A_5208 ist nicht dem PTV4-Konnektor zugewiesen, sondern die erweiterte Anforderungen  .

GS-A_5340 - Signatur der TSL

Der TSL-Dienst MUSS für die Signatur der TSL das Signaturverfahren RSASSA-PSS [PKCS#1] verwenden mit dem XMLDSig-Identifier „http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1“ nach [RFC-6931, Abschnitt „2.3.10 RSASSA-PSS Without Parameters“]. [<=]

3.15 ePA-spezifische Vorgaben

3.15.1 Verbindung zur VAU

DieDer Begriff "vertrauenswürdige Ausführungsumgebung" (VAU) wird in [gemSpec_DokumentenverwaltungAktensystem_ePAfuerAlle] eingeführt. JedesJeder ePA-Frontend des Versicherten (FdV)Client muss mit jeder beliebigen VAU (egal von welchem Anbieter ePA-Aktensystem) kommunizieren können. Deshalb ist es für die Interoperabilität notwendig, das Kommunikationsprotokoll zwischen beiden Kommunikationspartnern zu definieren und dessen Verwendung zu fordern.

A_1554615549-01 - ePA-Frontend des VersichertenVAU-Client: Kommunikation zwischen ePA-FdVClient und ePA-VAU

DasEin ePA-Frontend des VersichertenClient MUSS bei der Kommunikation mit der VAU das Kommunikationsprotokoll aus [gemSpec_Krypt#Abschnitt "Kommunikationsprotokoll zwischen VAU und ePA-Clients"] verwenden und dabei die Rolle Client einnehmen. Dabei MUSS es die CipherConfiguration "AES-256-GCM-BrainpoolP256r1-SHA-256" (vgl. Abschnitt 6) verwenden. Das ePA-Frontend des VersichertenVAU-Protokoll für ePA für alle"] verwenden.
Der Client einer VAU MUSS nach spätestens 24 Stunden das Aushandeln eines neuen AES-Sitzungsschlüsselsneuer AES-Verbindungsschlüssel erzwingen. Er Es MUSS den abgelaufenen Sitzungsschlüsselzeitlich abgelaufene Verbindungsschlüssel bei sich sicher löschen.
 [<=]

Hinweis: ein ePA-Frontend des Versicherten ist nach A_15872 (bzw. A_15873-*) [gemSpec_ePA_FdV] verpflichtet, das Zertifikat des Kommunikationspartners (VAU) zu prüfen (Kontext: Prüfung Authentizität des empfangene ECDH-Schlüssels). Nach A_15873-* (vgl. auch A_15874-*) in [gemSpec_ePA_FdV] muss dabei die TSL der TI Prüfungsgrundlage sein [gemSpec_ePA_FdV].

A_15549 - VAU-Client: Kommunikation zwischen VAU-Client und VAU

Ein Client einer VAU MUSS bei der Kommunikation mit der VAU das Kommunikationsprotokoll aus [gemSpec_Krypt#Abschnitt "Kommunikationsprotokoll zwischen VAU und ePA-Clients"] verwenden. Dabei MUSS es die CipherConfiguration "AES-256-GCM-BrainpoolP256r1-SHA-256" (vgl. Abschnitt 6) verwenden.
Der Client einer VAU MUSS nach spätestens 24 Stunden das Aushandeln eines neuen AES-Sitzungsschlüssels erzwingen. Er MUSS den abgelaufenen Sitzungsschlüssel bei sich sicher löschen. [<=]

A_15561 - AES-NI

Wenn der eingesetzte Konnektor AES-NI unterstützt und AES-NI dort aktiviert ist (vgl. [BSI-TR-03116-1#Abschnitt "4.7  Hardware-Unterstützung AES (AES-NI)"]), MUSS der Konnektor für alle AES-Ausführungen die AES-NI verwenden. [<=]

A_15547 - VAU: Kommunikation zwischen VAU und ePA-FdV bez. FM ePA15547-01 - ePA-VAU: Kommunikation zwischen ePA-VAU und ePA-Client

Das ePA-Aktensystem MUSS sicherstellen, dass dessen VAU bei der Kommunikation mit dem ePA-Frontend des Versicherten oder dem FM ePAClient das Kommunikationsprotokoll aus [gemSpec_Krypt#Abschnitt "Kommunikationsprotokoll zwischen VAU und ePA-Clients"] verwendet und dabei die Rolle Server einnimmt.  Dabei MUSS es die CipherConfiguration"AES-256-GCM-BrainpoolP256r1-SHA-256" (vgl. Abschnitt 6) verwenden.
Die VAU MUSS nach spätestens 24 Stunden das Aushandeln eines neuen AES-Sitzungsschlüssels erzwingen. Die VAU MUSS den abgelaufenen Sitzungsschlüssel und das ephemere EC-Schlüsselpaar, das im ECDH Grundlage der Schlüsselableitung für diesen Schlüssel war, sicher löschen.
Die VAU MUSS ein VAU-Protokoll für ePA für alle"] verwendet.
Die VAU MUSS sicherstellen, dann jeder ausgehandelte AES-Verbindungsschlüssel nach spätestens 24 Stunden sicher gelöscht wird.
Die VAU MUSS ein AUT-Zertifikat aus der Komponenten-PKI der TI besitzen (mit Rollenkennung-OID "oid_epa_vau"), das einen ECC-EE-Schlüssel der VAU bestätigt. Die VAU MUSS für die Erstellung der VAUServerHello-Nachricht mit dem zugehörigen privaten EE-Schlüssel signieren (Signatur der VAUHelloServerData). In der VAUHelloServer-Nachricht MUSS die VAU das Zertifikat aufführen und die dazugehörige OCSP-Response.
[<=]

3.15.2 Vorgaben für ePA-Schlüssel und ePA-Chiffrate

A_15705 - Vorgaben Aktenschlüssel (RecordKey) und Kontextschlüssel (ContextKey)

Ein Client eines ePA-Aktensystems MUSS sicherstellen, dass

1.   die von ihnen erzeugten Aktenschlüssel (RecordKey) und Kontextschlüssel (ContextKey) AES-Schlüssel [FIPS-197] mit 256 Bit Schlüssellänge sind,

2.   diese Schlüssel von ihnen ausschließlich mittels AES/GCM analog [gemSpec_Krypt#GS-A_4373] bzw. [gemSpec_Krypt#GS-A_4389] verwendet werden und

3.   sie die Arbeit mit Aktenschlüssel (RecordKey) und Kontextschlüssel (ContextKey), die nicht Spiegelstrich 1. erfüllen, ablehnen.

[<=]

A_18004 - Vorgaben für die Kodierung von Chiffraten (innerhalb von ePA)

Ein Client eines ePA-Aktensystems MUSS Folgendes sicherstellen.

1.   Der bei der Verschlüsselung mittels AES/GCM verwendete IV MUSS immer zufällig erzeugt werden und dessen Länge MUSS stets 96 Bits (12 Byte) betragen.

2.   Ein Chiffrat (base64-dekodiert) MUSS immer die Struktur:
    12 Byte IV + AES-GCM-Ciphertext + 16 Byte AuthTag (ICV)
aufweisen.

[<=]

3.15.3Verbindungsparameter (vgl. A_24425-*) authentisiert. [<=]

Hinweis: Das AUT-Zertifikat hat die VAU auch schon bei ePA 1.x und 2.x verwendet.

3.15.2 ePA-Aktensysteminterne Schlüssel

A_15745 - Verschlüsselte Speicherung der verschlüsselten ePA-Daten-01 - Betreiberschlüssel Aktensystem

Ein ePA-Aktensystem MUSS sicherstellen, dass

1.   es einen betreiberspezifischenzwei betreiberspezifische Schlüssel (BS / Masterkey für Daten und Masterkey für Befugnisse) gibt,

2.   dieserdiese Schlüssel ein AES-Schlüssel [FIPS-197] mit 256 Bit Schlüssellänge ist,

3.   dieser Schlüssel in einem mindestens nach FIPS-140-2 Level 3 zertifizierten HSM liegt und nur dort verwendet wird,

2.   dieser(vgl. A_24645-* bezüglich Speicherung der Schlüssel) sind,

4.3.diese Schlüssel im Betrieb ausschließlich der VAU des entsprechenden ePA-Aktensystem zugänglich istsind,

5.4.dieserdiese Schlüssel nur zur Schlüsselableitung nach einem in [gemSpec_Krypt#Abschnitt 2.4] zulässigen Verfahren verwendet wirdwerden,

6.5.es eine Schlüsselableitung mit diesemdiesen betreiberspezifischen SchlüsselSchlüsseln und einem aktenspezifischen Merkmal (bspw. der KVNR) gibt und daraus ein aktenspezifischer Schlüssel (ABS) abgeleitet wirdversichertenindividuelle Persistierungsschlüssel für die Daten und für die Befugnisse abgeleitet werden,

7.   dieser aktenspezifische Schlüssel eindiese versichertenindividuelle Persistierungsschlüssel AES-Schlüssel [FIPS-197] mit 256 Bit Schlüssellänge ist,

8.   die verschlüsselten ePA-Daten einer Akte mit diesem aktenspezifischen Schlüssel verschlüsselt werden,

9.   die verschlüsselten ePA-Daten außerhalb der VAU niemals im Klartext (also ohne mittels des ABS verschlüsselt zu sein) liegen,

6.   dieser Schlüssel (ABS)sind,

10.7.diese Schlüssel ausschließlich mittels AES/GCM analog [gemSpec_Krypt#GS-A_4389] verwendet wird (der ABS wird durch Anfrage der VAU im HSM berechnet (Schlüsselableitung) und dann von dort an die VAU übermittelt, die AES/GCM-Operationen mit dem ABS finden in der VAU statt)werden,

11.8.dieserdiese Schlüssel (ABS) im Betrieb ausschließlich der VAU des entsprechenden ePA-Aktensystem zugänglich istsind.

[<=]

Erläuterung: Das zu erreichende Ziel ist, dass, wenn ein Angreifer (mit hohem Angriffspotential, im Sinne von CC) selbst unter (1) der (hypothetischen) Annahme, die ePA an sich wäre überhaupt nicht verschlüsselt (es würde gar kein Aktenschlüssel existieren etc.) und (2), er alles im ePA-Aktensystem außer der VAU (inkl. HSM mit dem betreiberspezifischen Schlüssel) sicherheitstechnisch kompromittiert hätte, der Angreifer immer noch nicht auf die Klartextdaten zugreifen könnte.

Hintergrund ist, dass es unter dem Hybrid-Modell der ePA-Architektur aus Zugriffskontrolle und Verschlüsselung bei Entzug einer Berechtigung einem nun nicht mehr berechtigten Nutzer kryptographisch theoretisch immer noch möglich ist, die Daten der Akten, auf die er vormals berechtigten Zugriff hatte, zu entschlüsseln (er bricht bspw. in das Rechenzentrum des Anbieters ePA-Aktensystem ein und stiehlt dort alle Festplatten). Durch den in einem HSM beschützten betreiberspezifischen Schlüssel ist dieser beschriebene Angriff nun unterbunden.

A_15746 - Sicherstellung der Verfügbarkeit des betreiberspezifischen SchlüsselsA_15746-01 - Sicherstellung der Verfügbarkeit der betreiberspezifischen Schlüssel

Ein ePA-Aktensystem MUSS sicherstellen, dass für die Sicherstellung der Verfügbarkeit desder betreiberspezifischen SchlüsselsSchlüssel (vgl. A_15745-*) eine sicherheitstechnisch geeignete Sicherung (Backup) des Schlüsselmaterials erzeugt und sicher verwahrt wird.


[<=]

A_16176-01 - Mindestvorgaben für ePA-Aktensystem-interne Schlüssel

Ein ePA-Aktensystem MUSS bei innerhalb des Aktensystems eingesetzten Schlüsselmaterial, das nicht aus der TI-PKI kommt (Signatur Authorisierungstoken etc.), folgende Vorgaben umsetzen:

1. Alle verwendeten nicht-TI-Schlüssel MÜSSEN ein Sicherheitsniveau von 120 Bit ermöglichen (vgl. [gemSpec_Krypt#5 "Migration 120-Bit Sicherheitsniveau"]).
2. Alle nicht-TI-RSA-Schlüssel MÜSSEN eine Mindestschlüssellänge von 3000 Bit besitzen.
3. Alle nicht-TI-ECC-Schlüssel MÜSSEN auf einem folgenden der Domainparametern (Kurven) basieren:
   • P-256 oder P-384 [FIPS-186-45],
   • brainpoolP256r1, brainpoolP384r1 oder brainpoolP512r1 [RFC-5639].

[<=]

Erläuterung: Ziel von A_15751 und A_16176-01 ist es, den Umstellungsbedarf im Rahmen der ECC-Migration der TI und ihrer Anwendungen in der Phase 2 zu minimieren.

A_20519-01 - Wechsel desder betreiberspezifischen SchlüsselsSchlüssel

Ein ePA-Aktensystem MUSS sicherstellen, dass

1. der betreiberspezifischedie betreiberspezifischen Schlüssel (BS) (vgl. A_15745-*) mindestens alle 5 Jahrejährlich gewechselt wirdwerden,
2. nach Erzeugung eines neuen BS alle auf Grundlage des alten BS erzeugten Chiffrate umgeschlüsselt werden (neue Schlüsselableitung der aktenspezifischen Schlüssel (ABS) A_15745#6, Umschlüsselung der chiffrierten Aktendaten),
3. anschließend die altenalte Chiffrate und der alte BS sicher gelöscht werden, und
4. die Schritte 2. und 3. spätestens 4 Wochen nach Schlüsselwechsel deseines BS abgeschlossen sind.

[<=]

Hinweis: Der betreiberspezifischeDie betreiberspezifischen Schlüssel (BS) darfdürfen gemäß A_15745-* ausschließlich der VAU des ePA-Aktensystems zugänglich sein. Daher muss die Umschlüsselung in der VAU stattfinden. Dabei ist *keine* Mitwirkung des Versicherten (oder eines von ihm berechtigten Nutzers) erforderlich.

3.15.43 ePA-spezifische TLS-Vorgaben

A_15751-02 - TLS-Verbindung zwischen ePA-Aktensystem und ePA-FdVClient

Ein ePA-Aktensystem und ein ePA-Frontend des VersichertenClient MÜSSEN in Bezug auf die TLS-Verbindung zwischen ihnen

1. folgende Ciphersuiten unterstützen
   1.                     TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC0, 0x30),
   2.                     TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xC0, 0x2F),
   3.                     TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xC0, 0x2C),
   4.                     TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xC0, 0x2B).

2. Sie KÖNNEN weitere Cipher-Suiten aus [TR-02102-2, Abschnitt 3.3.1 Tabelle 1] unterstützen. 
3. Bei dem ephemeren Elliptic-Curve-Diffie-Hellman-Schlüsselaustausch und bei der Signaturprüfung mittels ECDSA MÜSSEN die Kurven P-256 oder P-384 [FIPS-186-45] unterstützt werden. Daneben SOLLEN die Kurven brainpoolP256r1, brainpoolP384r1 oder brainpoolP512r1 (vgl. [RFC-5639] und [RFC-7027]) unterstützt werden. Andere Kurven SOLLEN NICHT verwendet werden (Hinweis: die Intention des letzten Satzes ist insbesondere, dass die Ordnung des Basispunktes in E(F_p) nicht zu klein werden darf).

[<=]

A_1583324913 - ePA: TLS-Verbindungen, OCSP-Stapling

Ein ePA-Aktensystem MUSS bei allen seinen ePA-spezifischen HTTPS-Schnittstellen (Rolle TLS-Server) TLS-OCSP-Stapling [RFC-6066] verwenden (aktivieren). Es MUSS sicherstellen, dass die im TLS-Handshake mit gesendeten OCSP-Responses max. 50 Minuten alt sind. Sollte vom entsprechenden OCSP-Responder für den Bezug der OCSP-Responses trotz regelmäßigen Versuchens keine OCSP-Response bezogen werden können, so MUSS das Aktensystem die jüngste ihm zur Verfügung stehende OCSP-Response verwenden, und es regelmäßig weiter probieren (bspw. im 5'-Takt).

Ein ePA-Client MUSS in seiner TLS-Implementierung OCSP-Stapling unterstützen und die dort aufgeführten OCSP-Responses verwenden. Sollte diese zu alt sein (vgl. [gemILF_PS_ePA#A_24900]), so MUSS der ePA-Client versuchen, selbst OCSP-Responses einzuholen, wobei er die Client-seitiges OCSP-Response-Caching nach [gemSpec_PKI#A_23225] umsetzen MUSS. [<=]

Erläuterung:

Die Erfahrungen in der PU haben in den letzten Jahren gezeigt, dass ohne dedizierte Maßnahmen wie OCSP-Stapling und Client-seitiges OCSP-Response-Caching eine zu hohe Last an den OCSP-Respondern der Komponenten-PKI erzeugt wird.

A_15833-01 - TLS-Verbindungen ePA-FdV

Ein ePA-Frontend des Versicherten MUSS die TLS-Vorgaben in A_15751-* bei allen seinen TLS-Verbindungen einhalten.
[<=]

Es gibt ePA-Aktensysteme deren "Zugangsgateway des Versicherten" [gemSpec_Zugangsgateway_VersAccess Gateway [gemSpec_Aktensystem_ePAfuerAlle] die Verwendung von TLS-Session-Resumption per Session-ID von einem ePA-FdV verlangen. Ebenfalls gibt es ePA-Aktensysteme deren Zugangsgateway des VersichertenAccess Gateway die Verwendung von TLS-Session-Resumption per Session-Tickets von einem ePA-FdV verlangen. Nach einem TLS-Verbindungsende muss ein ePA-FdV eine TLS-Session-Resumption verwenden, ansonsten muss der Versicherte sich neu authentisieren (erneuter Login).

Ein ePA-FdV muss, um die beiden Anwendungsfälle (1) Aktensystemwechsel und (2) Versicherten-Vertreter über ein ePA-FdV eines anderen Aktensystemherstellers zu ermöglichen, beide Varianten der TLS-Session-Resumption unterstützen. Die meisten TLS-Bibliotheken unterstützen beide Varianten per Default.

A_21269-01 - ePA-FdVClient: TLS-Session-Resumption per Session-ID und per Session-Ticket

Ein ePA-Frontend des Versicherten MUSS sowohl Client SOLL TLS-Session-Resumption (per Session-ID als auchoder per TLS-Session-Resumption per Session-Tickets unterstützen. Falls im ePA-FdV (Rolle TLS-Client) Session-Daten (Session-ID oder oder Session-Ticket -- jeweils inkl. kryptographischer Daten (Premaster-Secret etc.)) vorliegen, so MUSS das ePA-FdV bei einem erneuten TLS-Verbindungsaufbau zum Zugangsgateway des Versicherten (Rolle TLS-Server) diese Session-Daten im Rahmen des TLS-Verbindungsaufbaus mit Session-Resumption verwenden.
Ein ePA-FdV (Rolle TLS-Client) MUSS falls ein Zugangsgateway des Versicherten (Rolle TLS-Server) im Rahmen eines TLS-Handshakes ein TLS-Session-Tickets sendet und der TLS-Handshake erfolgreich war, dieses Session-Ticket inkl. der für eine spätere TLS-Session-Resumption notwendigen kryptographischen Parameter (Premaster-Secret etc.) lokal speichern.
Ein ePA-FdV (Rolle TLS-Client) MUSS falls ein Zugangsgateway des Versicherten (Rolle TLS-Server) im Rahmen eines TLS-Handshakes kein TLS-Session-Tickets sendet und der TLS-Handshake erfolgreich war, alle für eine spätere TLS-Session-Resumption per Session-ID notwendigen Daten lokal speichern.

Ein ePA-FdV MUSS nach Ende der Aktensitzung (bspw. der Versicherte beendet die ePA-FdV-App) alle für eine TLS-Session-Resumption notwendigen Daten lokal löschen.
) unterstützen. [<=]

3.15.5 Schlüsselableitungsfunktionalität ePA

Zur Schlüsselableitung bei der Schlüsselableitungsfunktionalität ePA wird die HKDF nach [RFC-5869] auf Basis von SHA-256 verwendet. Diese Funktion wird auch als Grundlage der Schlüsselableitungen bei TLS Version 1.3 verwendet.

A_17876 - SGD: Schlüsselableitung der spezifischen Schlüssel

Ein SGD ePA MUSS folgende Vorgaben durchsetzen:

•      Als Ableitungsverfahren für die Schlüsselableitung der versichertenindividuellen Schlüssel MUSS das HKDF nach [RFC-5869] auf Basis von SHA-256 verwendet werden.

•      Die Ableitungsschlüssel MÜSSEN eine Mindestentropie von 512 Bit besitzen.

[<=]

Ein Client eines SGD (bspw. ein ePA-FdV) erhält über einen beidseitig authentisierten Ende-zu-Ende-verschlüsselten Kanal von jeweils zwei unabhängigen SGD AES-256-Bit-Schlüssel. Diese beiden Schlüssel nutzt der Client, um den Akten- und Kontextschlüssel des Versicherten im "Zwiebelschalenprinzip" zu ver- oder zu entschlüsseln.

A_17872 - Ver- und Entschlüsselung der Akten und Kontextschlüssel (Schlüsselableitungsfunktionalität ePA)

Ein Client eines SGD ePA MUSS bei der Ver- und Entschlüsselung der Akten- und Kontextschlüssel im Kontext Schlüsselableitungsfunktionalität ePA folgende Vorgaben umsetzen.

1.   Als symmetrische Block-Chiffre MUSS AES [FIPS-197] mit einer Schlüssellänge von 256 Bit im Galois/Counter Mode (GCM) gemäß [NIST-SP-800-38D] mit der Tag-Länge von 128 Bit verwendet werden.

2.   Der IV MUSS dabei zufällig erzeugt werden (vgl. [NIST-SP-800-38D#S.25] und [BSI-TR-02102-1#S.24]).

3.   Der IV MUSS eine Bitlänge von 96 Bit (12 Byte) besitzen.

[<=]

Für die Ende-zu-Ende-verschlüsselte Datenübertragung zwischen Client und SGD-HSM wird ECIES (vgl. [SEC1-2009#5.1 Elliptic Curve Integrated Encryption Scheme], [TR-02102-1#3.3. ECIES-Verschlüsselungsverfahren] und Abschnitt  ) verwendet. Dabei besitzt der Empfänger einen elliptischen Kurvenpunkt (öffentlicher Schlüssel), dessen Authentizität der Sender prüfen kann. Dies wird erreicht, indem der Kurvenpunkt des Empfängers (entweder Client oder SGD-HSM) mittels der Langzeitidentität des Empfängers signiert ist. Der Sender erzeugt ein ephemeres ECDH-Schlüsselpaar. Mit diesem und dem Kurvenpunkt des Empfängers führt der Sender einen ECDH-Schlüsselaustausch durch. Aus dem berechneten ECDH-Geheimnis berechnet der Sender mittels einer HKDF auf Basis von SHA-256 einen AES-256-Bit-Schlüssel der im Galois/Counter-Mode (GCM) verwendet wird (Authenticated Encryption). Damit verschlüsselt der Sender den Klartext und erhält ein AES-GCM-Chiffrat. Der Sender sendet seinen erzeugten ephemeren Kurvenpunkt und das AES-GCM-Chiffrat an den Empfänger. Damit ist der Nachrichtentransport Ende-zu-Ende-verschlüsselt zwischen Sender und Empfänger, jedoch nur einseitig authentisiert. Die beidseitige Authentisierung wird über einen Authentisierungstoken, den das SGD-HSM für einen Client erzeugt, erreicht (vgl. [gemSpec_SGD_ePA#]). Für das ECIES-Verfahren gilt der kryptographische Sicherheitsbeweis aus [ABR-1999].

A_17873 - SGD, SGD-HSM-authentisiertes ECIES-Schlüsselpaar

Ein SGD ePA MUSS sicherstellen, dass die zwei Schlüsselpaare (vgl. [gemSpec_SGD_ePA# (S4) ]) für  den ECIES-Nachrichtenempfang durch das SGD-HSM auf Basis der Kurvenparameter brainpoolP256r1 [RFC-5639] gewählt werden. Für die Authentisierung der öffentlichen ECIES-Schlüssels (Signatur mit [gemSpec_SGD_ePA# (S1) ] und Kodierung nach [gemSpec_SGD_ePA# ]) MUSS ECDSA [BSI-TR-03111] verwendet werden.
[<=]

A_17874 - SGD-Client, Client-authentisiertes ECIES-Schlüsselpaar

Ein Client eines SGD ePA MUSS für den Nachrichtenempfang mittels des ECIES-Verfahrens im Kontext der Schlüsselableitungsfunktionalität ePA bei den verwendeten ECC-Schlüsseln die Kurvenparameter brainpoolP256r1 [RFC-5639] verwenden. Für die Authentisierung des öffentlichen ECIES-Schlüssels des Clients (Signatur mit AUT-Identität des Nutzers des Clients gemäß [gemSpec_SGD_ePA#]) MUSS ECDSA [BSI-TR-03111] verwendet werden.
[<=]

In  und in  wird nicht aufgeführt, welche Hashfunktion im Rahmen der Signaturstellung und -prüfung zu verwenden ist. Dies wird mit folgender Anforderung nachgeholt.

A_19971 - SGD und SGD-Client, Hashfunktion für Signaturerstellung und -prüfung

Ein SGD ePA und ein Client eines SGD ePA MÜSSEN bei der Signaturerstellung und -prüfung im Kontext:

1.   Signaturerstellung mit [gemSpec_SGD_ePA# (S1) ] und Kodierung nach [gemSpec_SGD_ePA#] (vgl. ), bzw. Prüfung dieser Signatur, und

2.   Signaturerstellung für die Authentisierung der öffentlichen ECIES-Schlüssels des Clients (vgl. ), bzw. Prüfung dieser Signatur

die Hashfunktion SHA-256 [FIPS-180-4] verwenden. [<=]

A_17875 - ECIES-verschlüsselter Nachrichtenversand zwischen SGD-Client und SGD-HSM

Ein SGD ePA und ein Client eines SGD ePA MÜSSEN folgende Vorgaben umsetzen.

1.   Für den Ende-zu-Ende-verschlüsselten Datenaustausch zwischen SGD-Client und SGD-HSM MUSS das ECIES-Verfahren [SEC1-2009] verwendet werden.

2.   Der ECDH-Schlüsselaustausch innerhalb von ECIES zwischen SGD-Client und SGD-HSM MUSS nach [NIST-800-56-A#5.7.1.2] (Hinweis: ist fachlich identisch zu [SEC1-2009#3.3.1]) durchgeführt werden.

3.   Aus dem gemeinsamen ECDH-Geheimnis MUSS mit der HKDF nach [RFC-5869] auf Basis von SHA-256  ein AES-256-Bit-Schlüssel abgeleitet werden.

4.   Dieser Schlüssel (siehe Punkt 3) MUSS mittels AES-GCM und den fachlichen Vorgaben für AES-GCM aus   verwendet werden, um den symmetrisch Teil der ECIES-Verschlüsselung authentisiert zu ver- bzw. zu entschlüsseln.

Hinweis: die Kodierung der Chiffrate wird in [gemSpec_SGD_ePA] festgelegt.
[<=]

A_18023 - SGD, Ableitungschlüssel Authentisierungstoken

Ein SGD ePA MUSS folgende Vorgaben umsetzen.

1.   Die Ableitungsschlüssel für die Erstellung der Authentisierungstoken [gemSpec_SGD_ePA#  (S5)] MÜSSEN eine Mindestentropie von 256 Bit besitzen.

2.   Diese Ableitungsschlüssel MÜSSEN mit der HKDF nach [RFC-5869] auf Basis von SHA-256 verwendet werden.

[<=]

3.16 E-Rezept-spezifische Vorgaben

Der Fachdienst E-Rezept besitzt zwei HTTPS-Schnittstellen, eine in der TI und eine im Internet.

A_21332-02 - E-Rezept: TLS-Vorgaben

Ein E-Rezept-FD, ein Apothekenverzeichnis, ein E-Rezept-Client und ein IDP MÜSSEN in Bezug auf die TLS-Verbindung zwischen ihnen

1. folgende Ciphersuiten unterstützen
   1.                     TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC0, 0x30),
   2.                     TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xC0, 0x2F),
   3.                     TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xC0, 0x2C),
   4.                     TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xC0, 0x2B).
2. Sie KÖNNEN weitere Cipher-Suiten aus [TR-02102-2, Abschnitt 3.3.1 Tabelle 1] unterstützen. 
3. Bei dem ephemeren Elliptic-Curve-Diffie-Hellman-Schlüsselaustausch und bei der Signaturprüfung mittels ECDSA MÜSSEN die Kurven P-256 oder P-384 [FIPS-186-45] unterstützt werden. Daneben SOLLEN die Kurven brainpoolP256r1, brainpoolP384r1 oder brainpoolP512r1 (vgl. [RFC-5639] und [RFC-7027]) unterstützt werden. Andere Kurven SOLLEN NICHT verwendet werden (Hinweis: die Intention des letzten Satzes ist insbesondere, dass die Ordnung des Basispunktes in E(F_p) nicht zu klein werden darf).

[<=]

Ähnlich wie bei der Anwendung ePA endet die TLS-Verbindung am E-Rezept-FD an der Webschnittstelle (Eingangspunkt). Ziel ist es die Code-Komplexität innerhalb der VAU so gering wie möglich zu halten (Trusted Computing Base), um eine ausreichende Sicherheitsanalyse des VAU-Programmcodes überhaupt erst möglich zu machen. Dafür werden die Probleme des TLS-Handlings, der Lastverteilung und des DoS-Schutzes auf Applikationsebene außerhalb der VAU an den Webschnittstellen des Fachdienstes E-Rezept bearbeitet. So kann sich der Programmcode in der VAU auf seine zentrale Aufgabe des Zugriffsschutzes der über die VAU einstellbaren und abholbaren E-Rezepte fokussieren.

Um die Verbindungsstrecke zwischen Webschnittstelle und E-Rezept-VAU in Bezug auf Vertraulichkeit zu schützen, wird eine Verschlüsselung auf Anwendungsebene eingeführt. Bei ePA ist dies das VAU-Protokoll. Beim E-Rezept kann aufgrund der andersartigen Anwendungslogik in der E-Rezept-VAU ein einfacheres Sicherungsverfahren verwendet werden. Dieses ist in Abschnitt 6 VAU-Protokoll für E-Rezept normativ definiert. 

A_22698 - E-Rezept, Erzeugung des Nutzerpseudonyms LEI

Der Fachdienst E-Rezept MUSS folgende Punkte sicherstellen.

1. Die VAU MUSS einen mindestens 120-Bit-Entropie-haltigen Pseudonymisierungsschlüssel erzeugen und zur Verwendung durch die VAU vorhalten.
2. Dieser Pseudonymisierungsschlüssel MUSS ausschließlich durch die VAU verwendbar sein (Backups durch den Betreiber, welche durch ein Mehr-Augen-Prinzip geschützt werden, sind zulässig).
3. Dieser Pseudonymisierungsschlüssel MUSS halbjährlich automatisch durch die VAU neu erzeugt (gewechselt) werden.
4. Die VAU MUSS im Falle, dass der Nutzer eine LEI ist, die Telematik-ID des Nutzers ermitteln und dann mittels der HKDF nach [RFC-5869] auf Basis von SHA-256, dem geheimen Pseudonymisierungsschlüssel und der Telematik-ID ein 256 Bit langes LEI-Pseudonym erzeugen (d. h., Ausgabelänge der HKDF ist also 256 Bit (32 Byte), IKM (vgl. [RFC-5869) = PS, info (vgl. [RFC-5869]) = Telematik-ID, salt (vgl. [RFC-5869] = „“ (leere Zeichenkette)).
5. Die VAU MUSS das in (4) erzeugeerzeugte LEI-Pseudonym zusammen  mit den weiteren, für die Rohdatenlieferung definierten, Informationen an den äußeren E-Rezept-FD (!= VAU) weiter geben.

[<=]

Erläuterung zu A_22698-*:
Der Pseudonymisierungsschlüssel kann auch nur in Software vorliegen – muss also nicht zwangsweise in einem HSM vorliegen.
Für die Unterstützung von betrieblichen Prozessen soll dem E-Rezept-Projekt ein Überblick über die Anzahl der aktuell im Feld befindlichen Primärsystem-Versionen zur Verfügung gestellt werden. Der E-Rezept-FD übermittelt die Pseudonyme als Teil der Rohdatenlieferung an die gematik.

3.17 KOM-LE-spezifische Vorgaben

Bei KOM-LE werden E-Mail-Anhänge , deren Gesamtgröße 15 MiB überschreitet, separat symmetrisch verschlüsselt und das Chiffrat auf dem "Fachdienst Download-Server (KAS)" abgelegt. Das Chiffrat erhält eine ID, die aus dem Hashwert des Chiffrats gebildet wird. Dabei ist die in  festgelegte Hashfunktion zu verwenden. Der verwendete symmetrische Schlüssel und die Hashwert-Referenz sind dann Teil des Klartextes der verschlüsselten E-Mail-Nachricht (KOM-LE). Die Chiffrate auf dem Download-Server (KAS) werden automatisch nach einer bestimmten im FD festgelegten Zeit gelöscht.

A_19644 - Hashfunktion für Hashwert-Referenzen beim Fachdienst Download-Server (KAS)

Ein KOM-LE-Client und der Fachdienst Download-Server (KAS) MÜSSEN bei der Erzeugung und Verwendung von Hashwert-Referenzen für Anhänge - die auf dem Fachdienst Download-Server (KAS) abgelegt werden -  die Hashfunktion SHA-256 [FIPS-180-4] verwenden. [<=]

3.18 HMAC-Sicherung der Prüfziffer VSDM

A_23460 - VSDM-Betreiber: HMAC-Schlüsselerzeugung

Ein Betreiber eines VSDM-Dienstes MUSS den HMAC-Sicherungsschlüssel für die kryptographische Sicherung der VSDM-Prüfziffern zufällig mit einer Länge von 256 Bit  (= 32 Byte) und einer Mindestentropie von 120 Bit erzeugen. [<=]

Hinweis: es gelten die Anforderungen aus Abschnitt "2.2 Zufallszahlengeneratoren" (Güte der Zufallsquellen) auch für die VSDM-Betreiber (Anbietersteckbrief).

A_23461 - VSDM-Betreiber: HMAC-Verfahren

Ein Betreiber eines VSDM-Dienstes MUSS die HMAC-Sicherung der VSDM-Prüfziffern das HMAC-Verfahren aus [RFC-2104] mit der Hashfunktion SHA-256 (also nicht wie im RFC beschrieben mittels SHA-1) verwenden. Für das dabei zu verwendende geheime Schlüsselmaterial gilt A_23460-*. [<=]

Beispiel:

Wenn der geheime HMAC-Schlüssel (hexdump) 3a8e0064436bf2dbe7ca41ec6f1ed60beec083bc4100633281eb397cb294391c ist, so ist der HMAC-SHA-256-Wert gemäß A_23461-* auf die leere Bytefolge folgende Bitfolge (hexdump) 4c0a04f65d498113a5df2ab388d99d2c0bc6224a662b1ce529342745e7af414a 

A_23463 - VSDM-Betreiber: verschlüsselter Export des HMAC-Schlüssels für die E-Rezept-VAU

Ein Betreiber eines VSDM-Dienstes MUSS den HMAC-Sicherungsschlüssel mittels des ECIES-Verfahrens [SEC1-2009] für den Export an den E-Rezept-FD verschlüsseln und dabei folgende Vorgaben umsetzen

1. Er MUSS ein ephemeres ECDH-Schlüsselpaar erzeugen und mit diesem und dem VAU-Schlüssel aus A_20160-* ein ECDH gemäß [NIST-800-56-A] durchführen. Das somit erzeugte gemeinsame Geheimnis ist Grundlage für die folgende Schlüsselableitung.
2. Als Schlüsselableitungsfunktion MUSS er die HKDF nach [RFC-5869] auf Basis von SHA-256 verwenden.
3. Dabei MUSS er den Ableitungsvektor "ecies-vau-transport" verwenden, d. h. in der Formulierung von [RFC-5869] info="ecies-vau-transport" .
4. Er MUSS mit dieser Schlüsselableitung einen AES-128-Bit Content-Encryption-Key für die Verwendung von AES/GCM ableiten.
5. Er MUSS für Verschlüsselung mittels AES/GCM einen 96 Bit langen IV zufällig erzeugen.
6. Er MUSS mit dem CEK und dem IV mittels AES/GCM p verschlüsseln, wobei dabei ein 128 Bit langer Authentication-Tag zu verwenden ist.
7. Er MUSS das Ergebnis wie folgt kodieren: chr(0x01) || <32 Byte X-Koordinate von öffentlichen Schlüssel aus (a) > || <32 Byte Y-Koordinate> || <12 Byte IV> || <AES-GCM-Chiffrat> || <16 Byte AuthenticationTag> (vgl. auch Tab_KRYPT_ERP und folgende die Beispielverschlüsselung).
   Die Koordinaten sind (wie üblich) vorne mit chr(0) zu padden solange bis sie eine Kodierungslänge von 32 Byte erreichen.

[<=]

Beispiel:

Sei folgendes Zertifikat ein Beispiel-E-Rezept-VAU-Verschlüsselungszertifikat:

-----BEGIN CERTIFICATE-----
MIICWzCCAgKgAwIBAgIUYVkTweOLq4G7U28Gwwb3tAghcW8wCgYIKoZIzj0EAwIw
gYIxCzAJBgNVBAYTAkRFMQ8wDQYDVQQIDAZCZXJsaW4xDzANBgNVBAcMBkJlcmxp
bjEQMA4GA1UECgwHZ2VtYXRpazEQMA4GA1UECwwHZ2VtYXRpazEtMCsGA1UEAwwk
RS1SZXplcHQtVkFVIEJlaXNwaWVsaW1wbGVtZW50aWVydW5nMB4XDTIyMTAwNDIx
NTg1OFoXDTIzMTAwNDIxNTg1OFowgYIxCzAJBgNVBAYTAkRFMQ8wDQYDVQQIDAZC
ZXJsaW4xDzANBgNVBAcMBkJlcmxpbjEQMA4GA1UECgwHZ2VtYXRpazEQMA4GA1UE
CwwHZ2VtYXRpazEtMCsGA1UEAwwkRS1SZXplcHQtVkFVIEJlaXNwaWVsaW1wbGVt
ZW50aWVydW5nMFowFAYHKoZIzj0CAQYJKyQDAwIIAQEHA0IABB1wleU9eglD8Q7j
7HuTVyG7KJIRoJ6Rt1x8+GHvb3xeht3f5RPeETi+py3tLK5RWhFeGOIKmnydoBxJ
mK6VcmijUzBRMB0GA1UdDgQWBBTyOvu1E6xmEMu/6KIhI/kQJYw9CTAfBgNVHSME
GDAWgBTyOvu1E6xmEMu/6KIhI/kQJYw9CTAPBgNVHRMBAf8EBTADAQH/MAoGCCqG
SM49BAMCA0cAMEQCIGgWYuADP/Aulq0/QIzJDkCgqAXlVvmr92UPbfcRClvNAiAc
w8VE8xBtMx9g5sLK/HiDCsrQ9TNZjwpb5rb1t4ozgg==
-----END CERTIFICATE-----

und folgendes der dazugehörige private Schlüssel:

-----BEGIN EC PARAMETERS-----
BgkrJAMDAggBAQc=
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
MHgCAQEEII1+MNpxZfd+cPjE1Z5DCHCnuGCQt5MA6U55yuaxoB8CoAsGCSskAwMC
CAEBB6FEA0IABB1wleU9eglD8Q7j7HuTVyG7KJIRoJ6Rt1x8+GHvb3xeht3f5RPe
ETi+py3tLK5RWhFeGOIKmnydoBxJmK6Vcmg=
-----END EC PRIVATE KEY-----

Weiterhin sei folgendes der zu verschlüsselnde HMAC-Schlüssel (hexdump)

3a8e0064436bf2dbe7ca41ec6f1ed60beec083bc4100633281eb397cb294391c

Dann ist folgendes der Hexdump eines Chiffrats nach A_23463

019dec56554203624c214ac5321c798b78281d3fff4a0a4e187319ebebeba2ace40fe71913c6e02998cd3cd6f8268a0daf9f40eb1561541de9868d46eb913e3f3157d5ed6bd9d4aef792d473be5fa2868dbcd228e5a603afdae2c69fc459e656513cff835934de5e2f159b772ebbd21d6dfef2a4960ad829b968fc974b

Die gematik stellt Beispiel-Code für die Erzeugung eines Export-Pakets bereit.

3.19 spezifische TLS-Vorgaben für VSDM

Es gelten zunächst auch für VSDM u. a. die allgemeinen TLS-Anforderungen GS-A_4384-* und A_17124-*. Um die Umsetzung in den VSDM zu erleichtern wird auf die zwingende Unterstützung von NIST-Kurven beim ephemeren ECDH (TLS-Handshake) verzichtet -- es können ausschließlich brainpool-Kurven verwendet werden.

A_23912 - VSDM: Unterstützung von NIST-Kurven beim ephemeren ECDH (TLS-Handshake)

Ein VSDM KANN auf die Unterstützung von NIST-Kurven beim ephemeren ECDH (TLS-Handshake) bei der Umsetzung von GS-A_4384-* und A_17124-* verzichten. Er MUSS in diesem Fall die in GS-A_4384-* und A_17124-* anderen aufgeführten ECC-Gruppen (brainpoolP256r1 und brainpoolP384r1) unterstützen.
[<=]

Erläuterung zu A_23912-*: Das "SOLL" in GS-A_4384-* und A_17124-* für die brainpool-Kurven wird mit A_23912 zu einem "MUSS", falls auf die Unterstützung von NIST-Kurven beim ephemeren ECDH (TLS-Handshake) im VSDM verzichtetet wird.

A_23913 - Intermediär: TLS, Kurven beim ephemeren ECDH (TLS-Handshake)

Ein Intermediär MUSS bei der Umsetzung von GS-A_4384-* und A_17124-* die Kurven brainpoolP256r1 und brainpoolP384r1 beim ephemeren ECDH (TLS-Handshake) unterstützen. [<=]

Erläuterung: Durch A_23913 wird beim Intermediär dass "SOLL" in GS-A_4384-* und A_17124-* zu einem "MUSS".

4 Umsetzungsprobleme mit der TR-03116-1

Das u. a. durch die TR-03116-1 [BSI-TR-03116-1] angestrebte Sicherheitsniveau soll persönliche medizinische Daten effektiv schützen. Dazu lehnt sie sich an die sehr starken kryptographischen Vorgaben für die qualifizierte elektronische Signatur [SOG-IS-2020] an. Einige Formate (bspw. XMLDSig) oder Implementierungen (bspw. Standard-Java-Bibliotheken) können einige Vorgaben von Hause aus nicht erfüllen.

Dieses Kapitel weist auf Umsetzungsprobleme hin (ehemals Kapitel 3.3 aus dem Kryptographiekonzept des Basis-Rollouts).

4.1 XMLDSig und PKCS1-v2.1

Mit [XMLDSig] allein ist aktuell keine Nutzung von RSASSA-PSS [PKCS#1] möglich.

Aus diesem Grund hat die gematik entschieden für die Signatur nach [XMLDSig] zusätzliche Identifier für RSASSA-PSS aus [RFC-6931] innerhalb der TI zu verwenden, welche auf der Lösung aus [XMLDSig-RSA-PSS] basieren. Der RFC-6931 [RFC-6931] ist die Aktualisierung von [RFC-4051]. Die in Abschnitt „2.3.9 RSASSA-PSS With Parameters“ und „2.3.10 RSASSA-PSS Without Parameters“ aufgeführten Identifier für RSASS-PSS-Signaturen müssen innerhalb von XMLDSig für solche Signaturen verwendet werden.

GS-A_5091 - Verwendung von RSASSA-PSS bei XMLDSig-Signaturen

Produkttypen, die RSASSA-PSS-Signaturen [PKCS#1] innerhalb von XMLDSig erstellen oder prüfen, MÜSSEN die Identifier aus [RFC-6931] Abschnitt „2.3.9 RSASSA-PSS With Parameters“ und „2.3.10 RSASSA-PSS Without Parameters“ für die Kodierung dieser Signaturen verwenden.
[<=]

Ein Beispiel aus [RFC-6931] Abschnitt „2.3.10 RSASSA-PSS Without Parameters“:

<SignatureMethod
     Algorithm=
     "http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1"
   />

Vgl. [gemSpec_COS, (N003.000)]: Die Hashfunktion, auf der die Mask-generation-function basiert, ist SHA-256 [FIPS-180-4]. Die Länge des salt ist gleich der Ausgabelänge eben jener Hashfunktion (= 256 Bit).

4.2 XMLEnc: Die Nutzung von RSAES-OAEP und AES-GCM

Bei der Verschlüsselung mittels XMLEnc [XMLEnc] gibt es zwei Probleme in Bezug auf fehlende Identifier für kryptographische Verfahren, die in Abstimmung mit dem BSI für den Einsatz in der TI notwendig sind.

1.                      Für die symmetrische Verschlüsselung mittels AES-GCM ([FIPS-197], [NIST-SP-800-38D]) gibt es keine Algorithmen-Identifier innerhalb von [XMLEnc]. Solche gibt es in [XMLEnc-1.1, Abschnitt 5.2.4].
2.                      Für die Kodierung von RSA-OAEP-Chiffraten innerhalb von [XMLEnc] fehlt in [XMLEnc] ein Identifier für RSAES-OAEP mit der MGF1 basierend auf SHA-256 (vgl. auch Kapitel 5.10 „MGF Mask Generation Function“ in [gemSpec_COS]). Einen solchen Identifier(„http://www.w3.org/2009/xmlenc11#mgf1sha256“) gibt es in XMLEnc Version 1.1 [XMLEnc-1.1, Abschnitt 5.5.2].

Aus diesem Grund hat die gematik entschieden für die XML-Verschlüsselung die Vorgaben aus [XMLEnc-1.1] zu verwenden.

4.3 XML Signature Wrapping und XML Encryption Wrapping

Komplexität ist der natürliche Feind von Sicherheit. Die unter dem Sammelbegriff XML betitelten Formate und Protokolle sind sehr flexibel und leistungsfähig, aber auch sehr komplex. Noch dazu sind Sicherheitsmechanismen in diesem Bereich zum Teil nachträglich beigefügt worden und sind damit oft weniger leistungsfähig als im CMS-Bereich. XML-Daten effektiv zu schützen ist aktives Forschungsthema [XMLEnc-CM], [XSpRES]. Öfter als in anderen Bereichen werden neue Schwachstellen bekannt [BreakingXMLEnc], [XSW-Attack].

Aus diesem Grunde wird bei einer Sicherheitsevaluierung gesondert auf derartige Angriffe geachtet. Die gematik beobachtet neue Entwicklungen im Bereich der XML-Sicherheit und leitet falls notwendig Maßnahmen ein.

4.4 Güte von Zufallszahlen

Nach dem Kerckhoffs'schen Prinzip von 1883 [Ker-1883] darf die Sicherungsleistung von kryptographischen Verfahren alleinig auf der Geheimhaltung der geheimen oder privaten Schlüssel beruhen. Geheimhaltung inkludiert insbesondere, dass sie nicht erraten werden können. Wenn bei einer Schlüsselerzeugung zu wenig Entropie vorhanden ist, kann die Geheimhaltung nicht gewährleistet werden. Die kryptographischen Verfahren, welche mit diesen Schlüsseln dann arbeiten, können die von ihnen verlangten Sicherheitsleistungen nicht mehr erbringen. Aus diesem Grunde verlangt [BSI-TR-03116-1] eine Mindestgüte der Zufallszahlerzeugung u. a. bei einer Schlüsselerzeugung. Die Basis für die Beurteilung der Güte stellt [AIS-20] und [AIS-31] dar.

Aktuell sind nicht alle Produkte in der TI bez. dieser Mindestgüte bewertet worden. Davon sind Smartcards nicht betroffen, da diese eine Sicherheitsevaluierung/-zertifizierung durchlaufen haben, bei der die Güte der Zufallszahlenerzeugung positiv beurteilt wurde. Probleme bereiten insbesondere  HSMs.

Neben einer möglichen Common-Criteria-Zertifizierung dieser Produkte, bei der analog zu den Smartcards die Güte geprüfte wird, gibt es weitere mögliche Lösungen:

1. gesonderte Prüfung der Güte nach [AIS-20] und [AIS-31] ohne komplette Common-Criteria-Zertifizierung,
2. Herstellererklärung über die Güte (wie sie bspw. aktuell bei der Kartenproduktion üblich ist).

5 Migration 120-Bit-Sicherheitsniveau

Das „Sicherheitsniveau eines kryptographischen Verfahrens“ ist definiert als der Logarithmus zur Basis 2 der Anzahl der „Rechenschritte“ die notwendig sind um ein kryptographisches Verfahren mit hoher Wahrscheinlichkeit zu brechen. Was als „Rechenschritt“ definiert ist, ist vom Verfahren abhängig. Das Sicherheitsniveau wird in Bit angegeben. Beispielsweise nimmt man aktuell an, dass für das Brechen einer AES-Chiffre mit 128 Bit Schlüssellänge rund 2126,4 Rechenschritte, die der Durchführung einer AES-Verschlüsselung (eines 128-Bit Eingabeblocks) entsprechen, im Mittel notwendig sind. Somit erreicht eine AES-128-Bit-Verschlüsselung maximal ein Sicherheitsniveau von ca. 126,4 Bit. Eine RSA-2048-Bit-Verschlüsselung erreicht ein Sicherheitsniveau von ca. 100 Bit.

Für die TI ist ab Ende 2025 ein Sicherheitsniveau von mindestens 120 Bit für alle kryptographischen Verfahren zu erreichen. Daher ist bis dahin eine Migration aller Komponenten und Dienste notwendig, die kryptographische Verfahren mit Schlüssellängen bez. Domainparametern verwenden, die nur ein Sicherheitsniveau von unter 120 Bit erreichen können.

Aufgrund der höheren Performanz, insbesondere in Chipkarten und Embedded-Geräten, wird nicht auf RSA-3072-Bit sondern auf ECDSA mit 256-Bit-Schlüsseln migriert.

Es gibt Produkttypen, die kryptographische Verfahren so einsetzen, dass diese keine direkten Wechselwirkungen bei anderen Produkttypen besitzen. Beispielsweise werden von einem ePA-Aktensystem Autorisierungstoken (inkl. Signatur) erzeugt und diese werden von einem ePA-FdV oder als FM ePA als opakes Objekt behandelt. Dabei kann weiterhin RSA verwendet werden, solange die dabei verwendeten Schlüsselgrößen mindestens 3000 Bit betragen (Sicherheitsniveau 120-Bit erzielen) ( ). Ggf. ist es empfehlenswert dennoch auf ECC-basierte Verfahren zu migrieren (schnellere Ausführungsgeschwindigkeit, geringere Signaturgröße).

Die Migration erfolgt schrittweise und Komponenten und Dienste werden zusätzlich mit Schlüsselmaterial und Zertifikaten auf Basis von ECDSA auf der Kurve brainpoolP256r1 ausgestattet werden. Es gibt bis maximal Ende 2025 (vgl. Abschnitt 2.1.1.1) einen Parallelbetrieb in der TI.

Nachdem die X.509-Root der TI (Produkttyp „gematik Root-CA“), die TSPs der TI und die Objektsysteme der Chipkarten um ECC-Unterstützung für X.509-Identitäten erweitert wurden, erfolgt die schrittweise und parallele Unterstützung dieser Identitäten nun in weiteren Produkttypen bzw. Fachanwendungen.

5.1 PKI-Begriff Schlüsselgeneration

In [gemKPT_PKI_TIP#3.2] wird der Begriff der Schlüsselgeneration eingeführt. Eine CA signiert Zertifikate im abstrahierten Sinne mit „ihrem Signaturschlüssel“. Dieser Schlüssel wird regelmäßig neu erzeugt und solange Verfahren und Schlüssellänge bzw. Domainparameter gleichbleiben, handelt es sich um eine neue Schlüsselversion. Kryptographisch betrachtet wurde der neue Signaturschlüssel zufällig (vgl. GS-A_4368) erzeugt, ist also kryptographisch unabhängig vom alten Signaturschlüssel, und die CA arbeitet mit mehreren kryptographischen Schlüsseln.

Beispiel: im Fall der X.509-Root der TI (vgl. Abschnitt 5.2) wird ihr Signaturschlüssel im Regelfall alle zwei Jahre neu erzeugt (vgl. GEM.RCA1 und GEM.RCA2, https://download.tsl.ti-dienste.de/ ). Der Signaturschlüssel liegt hier in zwei Versionen vor. Beide Schlüssel kommen aus der Schlüsselgeneration „RSA“.

Für die Migration muss ein Signaturschlüssel in der X.509-Root der TI erzeugt werden, der aus der Schlüsselgeneration „ECDSA“ stammt. Für ihn gelten die Vorgaben aus [gemSpec_Krypt#GS-A_4357-0102, Schlüsselgeneration „ECDSA“].

5.2 X.509-Root der TI

Die X.509-Root der TI (Produkttyp: gematik Root-CA) ermöglicht es über eine klassische PKI-Baumstruktur die meisten Zertifikate der TI zu prüfen. Für zukünftige Anwendungen, die nur mit erhöhten Kosten das leistungsstarke, aber auch deutlich komplexere TSL-Modell auswerten können, ist sie eine Infrastrukturleistung der TI, so wie auch die CVC-Root.

Die X.509-Root muss für die Migration ECDSA-basierte Zertifikate für TSPs ausstellen können. Aufgrund von [gemSpec_PKI#GS-A_5511] muss die X.509-Root der TI neben dem Signaturschlüssel für die Schlüsselgeneration „RSA“ auch einen Signaturschlüssel für die Schlüsselgeneration „ECDSA“ gemäß GS-A_4357-0102 (brainpoolP256r1) erzeugen, und diesen verwenden können.

Als Hilfestellung wird im Folgenden ein X.509-Root-TI-Zertifikat betrachtet. Gemäß GS-A_4357-0102 muss der öffentliche ECDSA-Schlüssel der Schlüsselgeneration „ECDSA“ auf der Kurve brainpoolP256r1 liegen. Sei

d=SHA-256(„gemSpec_Krypt-Beispiel X.509-Root-TI ECDSA-Schluessel“)
=0x62e50dca4da29b0b10ead635a20b51fb1ec281d11f90cde8b5a9d92371ae8052

Dieses d wird als Ganzzahl (Little-Endian) interpretiert und dies sei der für das Beispiel maßgebliche private Schlüssel. Damit ergibt sich folgender öffentlicher Punkt auf der Kurve brainpoolP256r1:

(0x377434509adcbb827f74acd7adf0ce72aa28ddc53be3f15ea8023a9b0722c09d,
0x5364a99686c02092bbf9efde9878847b90f09d90b7ac4193553820258a58dfd5)

Folgend ist die ASN.1-DER-Kodierung des Schlüssels, so wie sie sich später auch im Zertifikat befindet, aufgeführt:

MFowFAYHKoZIzj0CAQYJKyQDAwIIAQEHA0IABDd0NFCa3LuCf3Ss163wznKqKN3FO+PxXqgCOpsH
IsCdU2SplobAIJK7+e/emHiEe5DwnZC3rEGTVTggJYpY39U=

   0  90: SEQUENCE {
  2  20:   SEQUENCE {
  4   7:     OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
 13   9:     OBJECT IDENTIFIER brainpoolP256r1 (1 3 36 3 3 2 8 1 1 7)
       :     }
24  66:   BIT STRING
       :     04 37 74 34 50 9A DC BB 82 7F 74 AC D7 AD F0 CE
       :     72 AA 28 DD C5 3B E3 F1 5E A8 02 3A 9B 07 22 C0
       :     9D 53 64 A9 96 86 C0 20 92 BB F9 EF DE 98 78 84
       :     7B 90 F0 9D 90 B7 AC 41 93 55 38 20 25 8A 58 DF
       :     D5
       :   }

Das selbstsignierte Beispiel-Root-Zertifikat im PEM-Format:

-----BEGIN CERTIFICATE-----
MIICajCCAg+gAwIBAgIBATAKBggqhkjOPQQDAjBtMQswCQYDVQQGEwJERTEVMBMG
A1UECgwMZ2VtYXRpayBHbWJIMTQwMgYDVQQLDCtaZW50cmFsZSBSb290LUNBIGRl
ciBUZWxlbWF0aWtpbmZyYXN0cnVrdHVyMREwDwYDVQQDDAhHRU0uUkNBMzAeFw0x
NjEyMDkwODQxNTZaFw0yNjEyMDcwODQxNTZaMG0xCzAJBgNVBAYTAkRFMRUwEwYD
VQQKDAxnZW1hdGlrIEdtYkgxNDAyBgNVBAsMK1plbnRyYWxlIFJvb3QtQ0EgZGVy
IFRlbGVtYXRpa2luZnJhc3RydWt0dXIxETAPBgNVBAMMCEdFTS5SQ0EzMFowFAYH
KoZIzj0CAQYJKyQDAwIIAQEHA0IABDd0NFCa3LuCf3Ss163wznKqKN3FO+PxXqgC
OpsHIsCdU2SplobAIJK7+e/emHiEe5DwnZC3rEGTVTggJYpY39WjgZ4wgZswHQYD
VR0OBBYEFBERSneTkJZDKt3uLzjddI870TMmMEIGCCsGAQUFBwEBBDYwNDAyBggr
BgEFBQcwAYYmaHR0cDovL29jc3Aucm9vdC1jYS50aS1kaWVuc3RlLmRlL29jc3Aw
DwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwFQYDVR0gBA4wDDAKBggq
ghQATASBIzAKBggqhkjOPQQDAgNJADBGAiEApQ6qGHTx97IsdzgoWH9/W32yt4rk
udUis0xxGZ48YOUCIQCTQ4puol5YYIAZYk74mfid3JBOvMBV/XgPV2WpS/99yg==
-----END CERTIFICATE-----

Relativ am Anfang des Zertifikats befindet sich die OID gemäß GS-A_4357-0102

16  10:   SEQUENCE {
18   8:     OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2)
      :     }

Ab Offset 280 befindet sich der schon o. g. öffentlicher Schlüssel:

282  90:   SEQUENCE {
284  20:     SEQUENCE {
286   7:       OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
295   9:       OBJECT IDENTIFIER brainpoolP256r1 (1 3 36 3 3 2 8 1 1 7)
       :       }
306  66:     BIT STRING
       :       04 37 74 34 50 9A DC BB 82 7F 74 AC D7 AD F0 CE
       :       72 AA 28 DD C5 3B E3 F1 5E A8 02 3A 9B 07 22 C0
       :       9D 53 64 A9 96 86 C0 20 92 BB F9 EF DE 98 78 84
       :       7B 90 F0 9D 90 B7 AC 41 93 55 38 20 25 8A 58 DF
       :       D5
       :     }

Und am Ende des Zertifikats befindet sich die ECDSA-Signatur:

535  10:   SEQUENCE {
537   8:     OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2)
       :     }
547  73:   BIT STRING, encapsulates {
550  70:     SEQUENCE {
552  33:       INTEGER
       :         00 A5 0E AA 18 74 F1 F7 B2 2C 77 38 28 58 7F 7F
       :         5B 7D B2 B7 8A E4 B9 D5 22 B3 4C 71 19 9E 3C 60
       :         E5
587  33:       INTEGER
       :         00 93 43 8A 6E A2 5E 58 60 80 19 62 4E F8 99 F8
       :         9D DC 90 4E BC C0 55 FD 78 0F 57 65 A9 4B FF 7D
       :         CA
       :       }
       :     }
       :   }

Wenn das oben aufgeführte Zertifikat sich in der Datei "root.pem" befindet, so kann man bspw. mittels

openssl verify -check_ss_sig root.pem

die Signatur überprüfen und erhält als Ausgabe:

root.pem: C = DE, O = gematik GmbH, OU = Zentrale Root-CA der Telematikinfrastruktur, CN = GEM.RCA3
error 18 at 0 depth lookup:self signed certificate
OK

5.3 TSL-Dienst und ECDSA-basierte TSL allgemein

Durch die ECC-Migration dürfen bereits produktiv betriebene Komponenten und Dienste in ihrer Verfügbarkeit nicht gefährdet werden. Aus diesem Grunde wird es eine zweite TSL "TSL(ECC-RSA)" geben. Diese wird mittels ECDSA (brainpoolP256r1) signiert sein und RSA- und ECDSA-basierte CA-Zertifikate enthalten. Bis zum Abschluss der ECC-Migration wird es zwei TSL in der TI geben: die seit Beginn des Online-Betriebs der TI bestehende RSA-basierte "TSL(RSA)" und die ECDSA-basierte "TSL(ECC-RSA). Die beiden TSL sind technisch unabhängig voneinander (Kontext Sequenznummern etc.). Dementsprechend wird es in Bezug auf die ECC-Migration keinen Vertrauensankerwechsel im Sinne von [ETSI_TS_102_231_v3.1.2] geben. Die Vertrauensbeziehung zwischen den beiden durch die zwei TSL beschriebenen Vertrauensräumen  wird über den klassischen Mechanismus der Cross-Zertifizierung realisiert. Die RSA-basierte X.509-TSL-Signer-CA wird ein X.509-Cross-Zertifikat "für" die ECDSA-basierte X.509-TSL-Signer-CA der TI ausstellen (vgl. ) und vice versa.

Analog zur VL der BNetzA wird es die Möglichkeit geben vom Downloadpunkt des TSL-Dienstes "TSL(ECC-RSA)" einen Hashwert der aktuellen TSL zu erhalten und damit für das Prüfen der Aktualität der lokal gespeicherten TSL nicht immer die gesamte TSL vom Downloadpunkt neu laden zu müssen (vgl.  ).

A_17205 - Signatur der TSL: Signieren und Prüfen (ECC-Migration)

Alle Produkttypen, die die TSL(ECC-RSA) signieren oder prüfen, MÜSSEN dafür das Signaturverfahren ECDSA [BSI-TR-03111] auf Basis der Domainparameter brainpoolP256r1 verwenden mit dem XMLDSig-Identifier „ http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256“ [XMLDSig]. Als Hashfunktion (Messagedigest) MUSS SHA-256 [FIPS-180-4] verwendet werden.
[<=]

5.4 ECC-Unterstützung bei TLS

Das TLS-Protokoll unterstützt die Verwendung von RSA- und ECC-basierten Cipher-Suiten.

Als Beispiel soll sich ein Konnektor mit ECC-Unterstützung mit einem "alten" eHealth-Kartenterminal (das also nur GS-A_4359-* und nicht A_17124-* kennt) verbinden. Beim Verbindungsaufbau (TLS-ClientHello) gibt der TLS-Client (Konnektor) eine geordnete Liste von unterstützenden Cipher-Suiten an. Der TLS-Server (eHealth-KT) untersucht diese Liste von vorn nach hinten und wählt die erste auch von ihm unterstützte Cipher-Suite. Somit gilt:

1. Ein TLS-Client kann durch die von ihm gewählte Reihenfolge in der Liste der Cipher-Suiten angeben, welche Cipher-Suite der Client präferiert (bspw. ECC-basierte Cipher-Suiten).
2. Ein  TLS-Client und ein TLS-Server können unterschiedliche Fähigkeiten besitzen (ECC-Unterstützung Ja/Nein). Solange sie eine gemeinsame Schnittmenge besitzen (in unserem Fall RSA-basierte Cipher-Suiten), können sie miteinander eine TLS-Verbindung aufbauen.

Ein TLS-Verbindungsaufbau eines Konnektors mit ECC-Unterstützung unterscheidet sich inhaltlich nur durch 4 zusätzliche Bytes (c02bc02c, vgl. GS-A_5354-* und A_23226-*) von einem TLS-Verbindungsaufbau ohne ECC-Unterstützung.

Verbindet sich beispielsweise ein "alter" Konnektor im Rahmen von VSDM mit einem Intermediär mit Option "ECC-Migration", wählt der Intermediär nach GS-A_4384-* eine RSA-basierte Cipher-Suite. Der Verbindungsaufbau kommt zu Stande und der Konnektor wird quasi nie erfahren, dass der Intermediär ebenfalls ECC-basierte Cipher-Suiten unterstützt. Erst wenn der Konnektor per Firmware-Upgrade sozusagen mit der Option "ECC-Migration" ausgestattet wird, muss er u. a. A_17124-* Spiegelstrich 3 umsetzen. Danach wird der Intermediär nach A_17124-* Spiegelstrich 4 die erste ECC-basierte Cipher-Suite bei einem TLS-Verbindungsaufbau auswählen.

A_17124-0103 - TLS-Verbindungen (ECC-Migration)

Alle Produkttypen, die Übertragungen mittels TLS durchführen, MÜSSEN die folgenden Vorgaben erfüllen:

1. Zur Authentifizierung MUSS eine X.509-Identität gemäß [gemSpec_Krypt#GS-A_4359-*] verwendet werden.
2. Als Ciphersuiten MÜSSEN TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xC0,0x2B) und  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xC0,0x2C) unterstützt werden.
3. Falls der Produkttyp in der Rolle als TLS-Client agiert, so MUSS er die eben genannten Ciphersuiten gegenüber evtl. ebenfalls von ihm unterstützen RSA-basierte Ciphersuiten (vgl. GS-A_4384-*) bevorzugen (in der Liste "cipher_suites" beim ClientHello vorne an stellen, vgl.  [RFC-5246#7.4.1.2 Client Hello]). 
4.  Beim ephemeren Elliptic-Curve-Diffie-Hellman-Schlüsselaustausch (vgl. "ECDHE" im Namen der Cipher-Suites) MÜSSEN die Kurven P-256 und P-384 [FIPS-186-45] unterstützt werden. Es SOLLEN die Kurven brainpoolP256r1 und brainpoolP384r1 (vgl. [RFC-5639] und [RFC-7027]) unterstützt werden. Andere Kurven als in A_17124-* aufgeführt DÜRFEN NICHT verwendet werden.

[<=]

A_17775 - TLS-Verbindungen Reihenfolge Ciphersuiten (ECC-Migration)

Alle Produkttypen, die Übertragungen mittels TLS durchführen und in der Rolle TLS-Server agieren, SOLLEN die Reihenfolge der Ciphersuiten in der Liste "cipher_suites" aus dem TLS-ClientHello bei der Auswahl der Ciphersuite befolgen.

[<=]

Die meisten Software-Pakete oder TLS-zentrierten Hardware-Lösungen (TLS-Terminatoren etc.) unterstützen die (wie oft formuliert) "Honorierung" der Reihenfolge aus der Liste "cipher_suites", aber nicht alle. Deshalb und weil die Honorierung wichtig aber nicht absolut notwendig ist, wurde A_17775 als SOLL-Anforderung formuliert.

A_17322 - TLS-Verbindungen nur zulässige Ciphersuiten und TLS-Versionen (ECC-Migration)

Alle Produkttypen, die Übertragungen mittels TLS durchführen, MÜSSEN sicherstellen, dass sie nur (durch andere Anforderungen) zugelassene TLS-Ciphersuiten bzw. TLS-Versionen anbieten bzw. verwenden.
[<=]

Hinweis: Im Rahmen der Zulassungstests und der CC-Evaluierung wurde dies (A_17322) stets so umgesetzt. Mit A_17322 soll dieses Vorgehen explizit auch auf Spezifikationsebene ausgesprochen und transparent gemacht werden.

5.5 ECC-Unterstützung bei IPsec

Das IKE-Protokoll [RFC-7296] wird verwendet um Schlüsselmaterial auszuhandeln für die folgende Verschlüsselung und Integritätssicherung der über IPsec geschützten IP-Pakete. Auszuhandeln bedeutet, dass ein (elliptische Kurven) Diffie-Hellman -Schlüsselaustausch durchgeführt wird. Im Gegensatz zum TLS-Protokoll Version 1.2 trägt schon die erste Protokollnachricht des Initiators (IKE_SA_INIT) einen (EC)DH-Schlüssel, evtl. aus einer kryptographischen Gruppe, die der Responder nicht unterstützt. Im Gegensatz zu TLS Version 1.3 kann dabei genau nur ein (EC)DH-Schlüssel übertragen werden, nicht eine Auswahl von Schlüsseln aus verschiedenen Gruppen. Der Initiator (Konnektor) kann im Normalfall nicht wissen, ob der Responder (VPN-Konzentrator) einen ECC-basierten DH-Schlüsselaustausch unterstützt. Der Initiator versucht es einfach und beginnt die IKE-Schlüsselaushandlung mit folgender Nachricht

Initiator                         Responder
   -------------------------------------------
   HDR, SAi1, KEi, Ni  -->

[RFC-7296]. In KEi ist der ephemere ECDH-Schlüssel auf Grundlage der Domainparameter brainpoolP256r1 enthalten. Falls der Responder diese Domainparameter (ECC-Kurve) nicht unterstützt, antwortet der Responder mit einer INVALID_KE_PAYLOAD-Nachricht, in der eine vom Responder unterstützte und präferierte kryptographische Gruppe angegeben ist [RFC-7296#Abschnitt 1.2]. Somit kommt es bei einem initialen Verbindungsaufbau zwischen einen "neuen" Konnektor und einem "alten" VPN-Zugangsdienst zu einem zusätzlichen "roundtrip", was akzeptiert wird, weil dies die Schlüsselaushandlung und damit den folgenden Verbindungsfall im Normalfall nur unwesentlich verzögert. Ein "neuer" Konnektor, der ggf. solch eine INVALID_KE_PAYLOAD-Nachricht erhält, wird dann auf die Vorgaben GS-A_4382-* "zurückfallen".

A_22342 - Konnektor, IKE-Schlüsselaushandlung – Erleichterung Migrationsphase 1 (ECC-Migration)

Solange ein Konnektor nur mit einem RSA-Zertifikat am VPN-Zugangsdienst registriert ist, KANN der Konnektor den IKE-Verbindungsaufbau gemäß der Vorgaben aus GS-A_4382-* durchführen. [<=]

A_22343-01 - Verwendung von ECC beim Verbindungsaufbau nach RE-Registrierung mit ECC-NK-Zertifikat (ECC-Migration)

Sobald der Konnektor mit einem ECC-Zertifikat am VPN-Zugangsdienst registriert ist, MUSS er den nächsten regulären Verbindungsaufbau zum VPN-Konzentrator gemäß der Vorgaben aus A_17125 durchführen. [<=]

A_17210 - Konnektor, IKE-Schlüsselaushandlung Fallback (ECC-Migration)

Ein Konnektor MUSS, falls beim IKE-Verbindungsaufbau klar wird, dass der IKE-Responder (VPN-Konzentrator, VPN-Zugangsdienst) (noch) keine ECC-Verfahren unterstützt (INVALID_KE_PAYLOAD-Nachricht), auf die Vorgaben aus GS-A_4382-* "zurückfallen".
[<=]

Analog zum TLS-Protokoll wählt der Responder die Cipher-Suite und ein "alter" Konnektor kann nicht erkennen, dass es sich evtl. um einen "neuen" VPN-Zugangsdienst handelt.

A_17125 - IKE-Schlüsselaushandlung für IPsec (ECC-Migration)

Alle Produkttypen, die die Authentifizierung, den Schlüsselaustausch und die verschlüsselte Kommunikation im IPsec-Kontext durchführen, MÜSSEN die Schlüsselvereinbarung mittels IKEv2 [RFC-7296] gemäß den folgenden Vorgaben durchführen:

1. Zur Authentisierung MUSS eine Identität mit einem X.509-Zertifikat gemäß [gemSpec_Krypt#GS-A_4360-*] Schlüsselgeneration "ECDSA" verwendet werden.
2. Für „Hash und URL“ MUSS SHA-1(vgl. [RFC-7296#3.6]) verwendet werden. 
3. Für den Schlüsselaustausch MUSS ein ephemer ECDH verwendet werden. Dabei MUSS die Kurve brainpoolP256r1 [RFC-6954] unterstützt werden. Es KÖNNEN die Kurven brainpoolP384r1, brainpoolP512r1 [RFC-6954] und ECP Gruppen 19, 20 und 21 [RFC-5903] unterstützt werden.
4. Als Verschlüsselungsverfahren im Rahmen von IKE MUSS AEAD_AES_128_GCM und AEAD_AES_256_GCM [RFC-5282] unterstützt werden (IANA.-Nr. 20) (Hinweis verpflichtend Unterstützung nach [RFC-5282#3.2]). Es MÜSSEN zudem AEAD_AES_128_GCM_12 und AEAD_AES_256_GCM_12 (IANA-Nr. 19) unterstützt werden. Es KÖNNEN weitere Verfahren nach [TR-02021-3#3.2.1 Tabelle 2] unterstützt werden.
5. Als PRF für die Schlüsselerzeugung MUSS PRF_HMAC_SHA2_256 (IANA-Nr. 5) [RFC-4868] unterstützt werden. Es KÖNNEN weitere Verfahren nach [TR-02021-3#3.2.2 Tabelle 3] unterstützt werden.
6. Als Authentisierungsverfahren MUSS ECDSA-256 als Basis von brainpoolP256r1 (IANA-Nr. 14) [RFC-7427] unterstützt werden. Es KÖNNEN weitere Verfahren nach [TR-02021-3#3.2.5 Tabelle 6] unterstützt werden.
7. Für die Verschlüsselung der ESP-Pakete MUSS AES-GCM mit 16 Byte großem ICV (IANA-Nr. 20) und AES-GCM mit 12 Byte großem ICV (IANA-Nr. 19) [RFC-4106] jeweils mit 128 und 256 Bit Schlüssellänge unterstützt werden.
   Es KÖNNEN weitere Verfahren nach [TR-02021-3#3.3.1 Tabelle 7] unterstützt werden.
8. Falls weitere Verfahren nach [TR-02021-3#3.3.1 Tabelle 7] unterstützt werden, so MUSS mindestens ein Verfahren zum Integritätsschutz der ESP-Pakete aus [TR-02021-3#3.3.2 Tabelle 8] unterstützt werden. (Hinweis: bei den verpflichtend zu unterstützenden AEAD-Verfahren aus Spiegelstrich 7 ist ein zusätzlicher Integritätsschutz by-design nicht notwendig.)

[<=]

Hinweis:

"strongSwan" unterstützt diese Algorithmen, vgl. https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites 

A_17126 - IPsec-Kontext -- Verschlüsselte Kommunikation (ECC-Migration)

Alle Produkttypen, die mittels IPsec-Daten schützen, MÜSSEN dies ausschließlich auf Grundlage der in   (und ggf. GS-A_4382-* vgl. diesbezüglich A_17210) als zulässig aufgeführten Verfahren und Vorgaben tun.
[<=]

5.6 ECDSA-Signaturen

5.6.1 ECDSA-Signaturen im XML-Format

A_17206 - XML-Signaturen (ECC-Migration)

Alle Produkttypen, die XML-Signaturen auf Basis eines ECC-Schlüssels erzeugen oder prüfen, MÜSSEN dafür das Signaturverfahren ECDSA [BSI-TR-03111] auf Basis der Domainparameter brainpoolP256r1 verwenden. Sie MÜSSEN dabei den XMLDSig-Identifier „ http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256“ [XMLDSig verwenden. Als Hashfunktion (Messagedigest) MÜSSEN sie SHA-256 [FIPS-180-4] verwenden.
[<=]

Die Anforderung   gilt für allgemeine XML-Datensignaturen, also auch für Tokensignaturen etc.   fordert für die Interoperabilität bei der Prüfbarkeit von Dokumentensignaturen die Verwendung des interoperablen Containerformats nach [ETSI-XAdES].

A_17360 - XML-Signaturen (Dokumente) (ECC-Migration)

Alle Produkttypen, die XML-Signaturen von Dokumenten auf Basis eines ECC-Schlüssels erzeugen oder prüfen, MÜSSEN dabei die Vorgaben aus A_17206 umsetzen und die Signatur nach [ETSI-XAdES] (interoperables Container-Format) bei der Erzeugung kodieren bzw. bei der Prüfung auswerten.
[<=]

5.6.2 ECDSA-Signaturen im CMS-Format

A_17207 - Signaturen binärer Daten (ECC-Migration)

Alle Produkttypen, die (nicht-XML-)Signaturen von Daten auf Basis eines ECC-Schlüssels erzeugen oder prüfen, MÜSSEN dafür das Signaturverfahren ECDSA [BSI-TR-03111] auf Basis der Domainparameter brainpoolP256r1 verwenden (vgl. [RFC-5753] und [RFC-6090]). Als Hashfunktion (Messagedigest) MÜSSEN sie SHA-256 [FIPS-180-4] verwenden.
[<=]

Die Anforderung A_17207 gilt für allgemeine (nicht-XML-)Datensignaturen, also auch für Tokensignaturen etc. A_17359 fordert für die Interoperabilität bei der Prüfbarkeit von Dokumentensignaturen die Verwendung des interoperablen Containerformats nach [ETSI-CAdES].

A_17359 - Signaturen binärer Daten (Dokumente) (ECC-Migration)

Alle Produkttypen, die (nicht-XML-)Signaturen von Dokumenten auf Basis eines ECC-Schlüssels erzeugen oder prüfen, MÜSSEN dabei die Vorgaben aus A_17207 umsetzen und die Signatur nach [ETSI-CAdES] (interoperables Container-Format) bei der Erzeugung kodieren bzw. bei der Prüfung auswerten.
[<=]

Hinweis: Signaturen in PDF/A-Dokumenten werden mittels CMS kodiert.

A_17208 - Signaturen von PDF/A-Dokumenten (ECC-Migration)

Alle Produkttypen, die (nicht-XML-)Signaturen auf Basis eines ECC-Schlüssels erzeugen oder prüfen, MÜSSEN dafür das Signaturverfahren ECDSA [BSI-TR-03111] auf Basis der Domainparameter brainpoolP256r1 nach [PAdES-3] und [PDF/A-2] verwenden. Als Hashfunktion (Messagedigest) MÜSSEN sie SHA-256 [FIPS-180-4] verwenden.
[<=]

5.7 ECIES

In der TI wird für die ECC-basierte Ver- und Entschlüsselung das "Elliptic Curve Integrated Encryption Scheme (ECIES)" verwendet. Es ist das einzige ECC-basierte, von den Chipkarten der TI unterstützte, Verschlüsselungsverfahren. Das ECIES ist ein hybrides Verfahren basierend auf [ABR-1999]. Es besteht aus einem asymmetrischen Teil (elliptic curve diffie hellman) und einen symmetrischen Teil (Verschlüsselungsverfahren und MAC-Verfahren). Weiterhin ist eine Schlüsselableitungsfunktion für das Verfahren notwendig. In [gemSpec_COS#6.8.2.3 Asymmetrische Entschlüsselung mittels ELC] wird definiert, welche Varianten dieser drei notwendigen Verfahren eine Chipkarte der TI unterstützt (ECDH [BSI-TR-03111#4.3.1 Key Agreement Algorithm], HKDF mittels SHA-256 und einem Zähler nach X9.63 [BSI-TR-03110-3#A.2.3.2], AES-256-CBC und CMAC). Da im Normalfall immer für eine Identität, die Chipkarten-basiert ist, verschlüsselt wird, muss ein Sender genau diese Verfahren einsetzen. Ansonsten kann die Chipkarte das Chiffrat nicht entschlüsseln, auch wenn die Chipkarte den prinzipiell richtigen privaten Schlüssel in sich trägt.

Da man das gesamte Chiffrat für eine Entschlüsselung auf einmal an die Karte (innerhalb einer APDU) senden muss, kann man nur etwas weniger als 8KiB entschlüsseln (bzw. 64KiB bei extended APDUs, die jedoch nicht alle Kartenterminal unterstützen), obwohl das ECIES-Verfahren an für sich die Ver- und Entschlüsselung praktisch beliebig großer Datenmengen unterstützt. Auch wäre es aus Nutzersicht in Bezug auf die Performanz nicht akzeptabel, schon allein moderat große verschlüsselte Dokumente komplett zu einer Karte für eine Entschlüsselung zu transportieren (mehr als 18 Minuten würde dies für ein 10 MiB großes Dokument benötigen). Deswegen wird für die TI hier eine zusätzliche Metaebene eingeführt und normativ gefordert. Analog zu einer Verschlüsselung mittels RSAES-OAEP muss ein Sender einen Transportschlüssel zufällig erzeugen. Ein solcher Transportschlüssel, ist dann aus Sicht der Chipkarte der zu ver- oder entschlüsselnde Klartext. Der aus Nutzersicht eigentliche Klartext (Dokumente) wird nie an die Karte gesendet. Die Karte entschlüsselt den verschlüsselten Transportschlüssel und übergibt ihn anschließend an den Kartennutzer. Dieser kann mit dem Transportschlüssel nun das Dokument unabhängig von der Chipkarte entschlüsseln. Bei RSAES-OAEP wird der Transportschlüssel als Content-Encryption-Key (CEK) bezeichnet. Im hier vorliegenden Fall bei ECIES kann diese Bezeichnung zu Missverständnissen führen. Mittels ECIES wird über ein ECDH und folgender Schlüsselableitung ein Verschlüsselungsschlüssel erzeugt. Diesen kann man auch als CEK bezeichnen, weswegen im Folgenden immer nur vom Transportschlüssel gesprochen wird.

Da eine solche Metaebene für eine ECIES-Chiffrat-Kodierung unüblich ist (weil ohne TI-Chipkarteneinsatz unnötig), ist die Kodierung der Chiffrate mittels CMS oder XMLEnc nichttrivial und wird daher im Interesse der zu erzielenden Interoperabilität in diesem Abschnitt ausführlicher dargestellt.

Für die symmetrische Verschlüsselung der Nutzerdaten (Dokumente etc.) wird zufällig ein Transportschlüssel erzeugt. Für diesen gelten die Vorgaben aus GS-A_4389 (symmetrische Verschlüsselung) und GS-A_4368 (Schlüsselerzeugung). Der Transportschlüssel wird dann unkodiert ("is just the \"value\" of the content-encryption key" [RFC-5652#6.4]) zur Verschlüsselung an das ECIES-Verfahren übergeben. Bei der ECIES-Verschlüsselung müssen dann die Parameter so gewählt werden, dass eine Chipkarte der TI diese unterstützt, d. h. nach [gemSpec_COS#6.8.2.3 Asymmetrische Entschlüsselung mittels ELC].

Das erhaltene ECIES-Chiffrat muss dann als eine ASN.1-Struktur kodiert werden, die genau dem Aufbau entspricht, den man benötigt um eine Entschlüsselung mittels einer Chipkarte der TI durchzuführen (vgl. [gemSpec_COS#(N085.068) Spiegelstrich 7).

Abbildung 2: ASN.1-Kodierung des Chiffrats was den Transportschlüssel enthält

Beispiel:

poGOBgkrJAMDAggBAQd/SUOGQQRouC6tM2TQQ+RP3pptgdAaDF8Te7IVCkUBe2H+PJSLK4W/BXIX
kndiBwEfftd5wk4pjzCdC2j1q14/CIWcW89nhjEC7G47UAu2ZqmbIhxstkXV3UI2UUek/qwBwtb2
6aUild+5kkTZXf5674OKHSdj6IFwjggvhYt9b/CTsA==

$ dumpasn1 a.bin
  0 142: [6] {
  3   9:   OBJECT IDENTIFIER brainpoolP256r1 (1 3 36 3 3 2 8 1 1 7)
 14  67:   [APPLICATION 73] {
 17  65:     [6]
       :       04 68 B8 2E AD 33 64 D0 43 E4 4F DE 9A 6D 81 D0
       :       1A 0C 5F 13 7B B2 15 0A 45 01 7B 61 FE 3C 94 8B
       :       2B 85 BF 05 72 17 92 77 62 07 01 1F 7E D7 79 C2
       :       4E 29 8F 30 9D 0B 68 F5 AB 5E 3F 08 85 9C 5B CF
       :       67
       :     }
 84  49:   [6]
       :     02 EC 6E 3B 50 0B B6 66 A9 9B 22 1C 6C B6 45 D5
       :     DD 42 36 51 47 A4 FE AC 01 C2 D6 F6 E9 A5 22 95
       :     DF B9 92 44 D9 5D FE 7A EF 83 8A 1D 27 63 E8 81
       :     70
135   8:   [14] 2F 85 8B 7D 6F F0 93 B0
       :   }
Diese Datenstruktur soll konzeptionell so behandelt werden, wie ein RSA-OAEP-Chiffrat eines CEK. Es ist jedoch die hiermit neu definierte OID oid_ti_ecies_transport_encryption [gemSpec_OID] zu verwenden.

Ein Beispiel aus [gemSpec_SMIME-KOMLE] dient als Vorlage für die Darstellung der zu verwendenden Kodierung mittels CMS (S/MIME):

ContentInfo
.contentType: 1.2.840.113549.1.9.16.1.23 (id-ct-authEnvelopedData)
..AuthEnvelopedData
...version: 0
...recipientInfos
....RecipientInfo
.....ktri
......version: 0
......rid
.......issuerAndSerialNumber
........issuer
........[... weitere Kindelemente ...]
........SerialNumber: 123456789
.......keyEncryptionAlgorithm
........oid_ti_ecies_transport_encryption
.......encryptedKey: [ ... ASN.1-Struktur (Tupel (PO, C, T) in kartenkompatibler ASN.1-Binärverpackung) ... ]
....RecipientInfo
.....ktriversion: 0
......rid
.......issuerAndSerialNumber
........issuer
........[... weitere Kindelemente ...]
........SerialNumber: 314159265
.......keyEncryptionAlgorithm
........OID TI-ECIES-TransportEncryption
.......encryptedKey: [ ... ASN.1-Struktur (Tupel (PO, C, T) in kartenkompatibler ASN.1-Binärverpackung) ... ]
...authEncryptedContentInfo
....contentType: 1.2.840.113549.1.7.1 (id-data)
....contentEncryptionAlgorithm:
.....algorithm: 2.16.840.1.101.3.4.1.46 (id-aes256-gcm)
......parameters:
.......aes-nonce: [... IV ...]
.......aes-ICVlen: [... ICVLen ... ]
....encryptedContent: [...]
...mac: [...]
...unauthAttrs
....Attribute (id-recipientEmails)
.....attrType: komle-recipient-emails

und so weiter ...

Für die Kodierung von TI-ECIES-Chiffraten innerhalb von XML wird hiermit der neue Identifier "http://gematik.de/ecies/2019" definiert. Für die XML-Kodierung ist eine Kodierung analog der folgenden Struktur zu verwenden.

<?xml version="1.0" encoding="UTF-8"?>
<xenc:EncryptedData
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    xmlns:dsig11="http://www.w3.org/2009/xmldsig11#"
    xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"
    Type="http://www.w3.org/2001/04/xmlenc#">
  <xenc:EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#aes256-gcm" />

<!-- Damit ist len(IV)=12 Byte und TagLen=16 Byte, vgl. [XMLEnc#5.2.4 AES-GCM] --> 
  <ds:KeyInfo>
    <xenc:EncryptedKey>
    <!-- Hybridschlüssel für einen Empfänger, für weitere Empfänger gäbe es jeweils ein weiteres EncryptedKey-Element -->
      <xenc:EncryptionMethod Algorithm="http://gematik.de/ecies/2019" />
      <!-- Die Version des speziellen ECIES -->
      <ds:KeyInfo> 
        <ds:X509Data>
         <ds:X509Certificate>
       <!-- Base64-kodiertes X.509-Zertifikat (DER) des Empfängers -->
         </ds:X509Certificate> 
        </ds:X509Data>
      </ds:KeyInfo>
      <xenc:CipherData>
        <xenc:CipherValue>
<!-- Base64-kodierte ASN.1-Struktur (Tupel (PO, C, T) in kartenkompatibler ASN.1-Binärverpackung) -->
        </xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedKey>
  </ds:KeyInfo>   
  <xenc:CipherData>
    <xenc:CipherValue>
<!--
Base64-kodiertes symmetrisch mittels AES-256-GCM verschlüsseltes Dokument 
(IV || ciphertext || Tag) mit len(IV)=12 Byte und len(Tag)=16 Byte,
vgl. [XMLEnc#5.2.4 AES-GCM]
-->
    </xenc:CipherValue>
  </xenc:CipherData> 
</xenc:EncryptedData>

A_17220 - Verschlüsselung binärer Daten (ECIES) (ECC-Migration)

Alle Produkttypen, die binäre Daten (also nicht XML-Daten) ECC-basiert verschlüsseln (im Folgenden als Nutzerdaten bezeichnet) und diese mittels CMS [RFC-5626] kodieren, MÜSSEN folgende Vorgaben umsetzen.

1. Zunächst MUSS ein 256-Bit AES-Schlüssel zufällig erzeugt werden (vgl. GS-A_4368),
   Dieser Schlüssel wird im Folgenden als Transportschlüssel bezeichnet (vgl. Erklärung in Abschnitt [gemSpec_Krypt#]).
2. Mit diesem Transportschlüssel MÜSSEN die Nutzerdaten mittels AES-GCM und den Vorgaben aus GS-A_4389 verschlüsselt werden.
3. Der Transportschlüssel MUSS unkodiert mit den in [gemSpec_COS#6.8.1.4 ELC Verschlüsselung] aufgeführten Vorgaben mittels ECIES verschlüsselt werden (siehe Erklärung in [gemSpec_Krypt#ECIES]). Das damit entstehende Chiffrat wird im Folgenden als Transport-Chiffrat bezeichnet.
4. Das Transport-Chiffrat MUSS wie in [gemSpec_Krypt#] beschrieben in eine ASN.1-Struktur (Tupel (PO, C, T) in kartenkompatibler ASN.1-Binärverpackung kodiert werden.
5. Diese Kodierung MUSS in eine keyEncryptionAlgorithm-Datenstruktur mit der OID oid_ti_ecies_transport_encryption [gemSpec_OID] eingebracht werden.
6. Die restliche Kodierung des mittels AES-GCM erzeugten Chiffrats der Nutzerdaten MUSS wie in CMS üblich [RFC-5626] [RFC-5084] erfolgen (vgl. Darstellung in  [gemSpec_Krypt#]).

[<=]

A_17221-01 - XML-Verschlüsselung (ECIES) (ECC-Migration)

Alle Produkttypen, die XML-Dokumente mittels [XMLEnc-1.1] und ECC-basierte verschlüsseln, MÜSSEN die Vorgaben aus A_17220 Spiegelstrich 1 bis 3 umsetzen. Weiter MÜSSEN sie folgende Vorgaben umsetzen:

1. Das Transport-Chiffrat MUSS wie in [gemSpec_Krypt#] beschrieben in eine ASN.1-Struktur (Tupel (PO, C, T) in kartenkompatibler ASN.1-Binärverpackung kodiert werden.
2. Diese ASN.1-Binärverpackung MUSS Base64-kodiert werden und so kodiert in eine XML-Datenstruktur, so wie sie in [gemSpec_Krypt#] beschrieben ist, eingebracht werden (Hinweis: man beachte ohne "RecipientKeyInfo" Tags).
3. Die mittels AES-GCM verschlüsselten Nutzerdaten MÜSSEN ebenfalls Base64-kodiert in die eben erzeugte XML-Datenstruktur gemäß [gemSpec_Krypt#] eingebracht werden.

[<=]

Im Interesse der Interoperabilität stellt die gematik auf Anfrage Testvektoren (Beispiel-Chiffrate mit Klartext) zur Verfügung.

5.7.1 ECIES und authentisierte Broadcast-Encryption

In [SEC1-2009#5.2] und in [RFC-5753#4] wird auf ein potentielles Problem hingewiesen, dass insbesondere bei der Verwendung eines static-static-ECDH innerhalb von ECIES auftreten kann (also Sender und Empfänger verwenden ihre Langzeit-Identität "static-static"). Verallgemeinert formuliert, handelt es sich um das Problem der authentisierten Broadcast-Verschlüsselung. Ein Sender möchte an mehrere Empfänger "gleichzeitig" den gleichen Klartext verschlüsselt senden (vgl. auch [RFC-4082#1]). Bei TI-ECIES-TransportEncryption [gemSpec_Krypt#ECIES] wird der Transportschlüssel jeweils für jeden Empfänger mittels ECIES verschlüsselt. Jeder Empfänger kennt nun diesen zwischen dem Sender und allen Empfängern geteilten Schlüssel (Transportschlüssel) und kann jetzt (aus kryptographischer Sicht) den Klartext beliebig verändern, ohne dass dies bei einer Entschlüsselung auffällt. Die "authenticated Encryption" via AES-GCM (Transportschlüssel) kann hier also nicht die von ihr evtl. angenommene Sicherheitsleistung erbringen. 

Wenn also bspw. bei KOM-LE eine Nachricht an mehrere Empfänger (eingetragen im CC-Feld) versendet werden soll, so muss an dieser Stelle zusätzlich die Authentizität der versendeten Nachricht gesichert werden. Bei KOM-LE erfolgt dies über die verpflichtende Signatur der Nachricht mit Hilfe der SMC-B (OSIG-Schlüsselmaterial). Es ist davon auszugehen, dass andere Anwendungen, die an mehrere Empfänger Nachrichten/Daten "gleichzeitig" versenden, ebenfalls zusätzliche Maßnahmen ergreifen müssen.

5.7.2 ECIES und mobKT

Ein "Mobiles Kartenterminal" [gemSpec_MobKT] ist so etwas wie ein Tablet mit zwei Chipkartenslots. Es ermöglicht einem LE außerhalb seiner Praxisräumlichkeiten (also insbesondere ohne Konnektor und stationäres eHealth-Karterterminal), auf Daten eines Versicherten auf dessen eGK zuzugreifen. Das Mobile Kartenterminal muss die dabei ausgelesenen versichertenspezifischen Daten verschlüsselt lokal im Gerät ablegen. Wenn das Mobile Kartenterminal verloren geht, sind damit diese Daten geschützt. Sie können erst mit Hilfe des gesteckten und freigeschaltenen HBA des LE wieder entschlüsselt (genutzt) werden, bspw. zur Übertragung ins Primärsystem. Für die Verschlüsselung muss nach Ende 2025 ECIES und nicht mehr RSA-OAEP verwendet werden. Es gelten dafür fachlich quasi die gleichen Vorgaben wie in A_17220, nur gibt es keine Notwendigkeit in Bezug auf die Kodierung des Chiffrats interoperabel  sein zu müssen. Denn nur das spezifische Mobile Kartenterminal selbst muss die Daten ver- und entschlüsseln können im Sinne von "die Kodierung der Chiffrate auswerten können". Deshalb gibt es nachfolgend eine Spezialisierung von A_17220 für das Mobile Kartenterminal.

A_17575 - MobKT: Verschlüsselung binärer Daten (ECIES) (ECC-Migration)

Ein Mobiles Kartenterminal MUSS folgende Vorgaben umsetzen.

1. Für die Verschlüsselung der Versichertendaten MUSS ein 256-Bit AES-Schlüssel zufällig erzeugt werden (vgl. GS-A_4368). Dieser Schlüssel wird im Folgenden als Transportschlüssel bezeichnet.
2. Mit diesem Transportschlüssel MÜSSEN die Versichertendaten mit AES-GCM und den Vorgaben aus GS-A_4389 verschlüsselt werden.
3. Der Transportschlüssel MUSS mit den in [gemSpec_COS#6.8.1.4 ELC Verschlüsselung] aufgeführten Vorgaben mittels ECIES verschlüsselt werden (siehe Erklärung in [gemSpec_Krypt#] und [gemSpec_Krypt#Hinweis zu A_17575]).
4. Falls auf dem gesteckten HBA ein ECC-basiertes ENC-Zertifikat vorhanden ist, so MUSS ECIES für die Ver- und Entschlüsselung des Transportschlüssels verwendet werden, anstatt von RSA-OAEP. Falls noch kein ECIES-verschlüsselter Transportschlüssel im Mobilen Kartenterminal vorliegt, sondern ein RSA-OAEP-verschlüsselter Transportschlüssel, so MUSS dieser Transportschlüssel zusätzlich mittels ECIES und dem ECC-ENC-Schlüssel des HBAs des LE verschlüsselt werden.

[<=]

Hinweis zu A_17575:
In einem HBA steht die Schnittstelle [gemSpec_COS#6.8.1.4 ELC Verschlüsselung] für die Verschlüsselung des Transportschlüssels zur Verfügung. Dass der Transportschlüssel verschlüsselt werden muss, wird nur sehr selten als Anwendungsfall vorkommen. Die Entschlüsselung - notwendiger Weise mit und durch den HBA - jedoch häufig.

5.8 ECC-Migration eHealth-KT

Mit A_17089-01 und A_17090-01 (vgl. Abschnitt 3.3.2) wird vom eHealth-Kartenterminal die Unterstützung der mit der Kartengeneration 2.1 (vgl. [gemSpec_gSMC-KT_ObjSys_G2.1]) hinzugekommenen ECDSA-basierten Identität bereitgestellt.

A_17089-0103 - eHealth-Kartenterminals: TLS-Verbindungen (ECC-Migration)

Ein eHealth-Kartenterminal MUSS prüfen, ob die in ihm gesteckte SMC-KT für die TLS-Verbindung zum Konnektor eine RSA-basierte Identität (AUT) und/oder eine ECDSA-basierte Identität besitzt (vgl. [gemSpec_gSMC-KT_ObjSys_G2.1], bspw. jeweils EFs mit ShortFileIdentifier 1 und 4 prüfen).
Falls eine RSA-basierte Identität dort vorhanden ist, so MUSS das eHealth-Kartenterminal folgende TLS-folgende Vorgaben erfüllen:

1. Als Cipher-Suite MÜSSEN TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 und TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 unterstützt werden.
2. Beim ephemeren Elliptic-Curve-Diffie-Hellman-Schlüsselaustausch (vgl. "ECDHE" im Namen der Cipher-Suites) MÜSSEN die Kurven P-256 und P-384 [FIPS-186-45] unterstützt werden. Es SOLLEN die Kurven brainpoolP256r1 und brainpoolP384r1 (vgl. [RFC-5639] und [RFC-7027]) unterstützt werden. Andere Kurven als in A_17089-* aufgeführt DÜRFEN NICHT verwendet werden.
3. Es KÖNNEN weitere Cipher-Suiten aus [TR-02102-2, Abschnitt 3.3.1 Tabelle 1] unterstützen.

Falls eine ECDSA-basierte Identität vorhanden ist, so MUSS das eHealth-Kartenterminal zusätzlich folgende Vorgaben erfüllen:

1. Als Ciphersuiten MÜSSEN TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xC0,0x2B) und  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xC0,0x2C) unterstützt werden.
2. Beim ephemeren Elliptic-Curve-Diffie-Hellman-Schlüsselaustausch (vgl. "ECDHE" im Namen der Cipher-Suites) MÜSSEN die Kurven P-256 und P-384 [FIPS-186-45] unterstützt werden. Es SOLLEN die Kurven brainpoolP256r1 und brainpoolP384r1 (vgl. [RFC-5639] und [RFC-7027]) unterstützt werden. Andere Kurven als in GS-A_17089-* aufgeführt DÜRFEN NICHT verwendet werden.

Dies bedeutet, falls beide Identitäten auf der SMC-KT vorhanden sind (wie bei [gemSpec_gSMC-KT_ObjSys_G2.1]), so MÜSSEN alle vier oben genannten Ciphersuiten unterstützt werden.
[<=]

A_17090-01 - eHealth-Kartenterminals: Signaturverfahren beim initialen Pairing zwischen Konnektor und eHealth-Kartenterminal (ECC-Migration)

Ein eHealth-Kartenterminal MUSS in Bezug auf das verwendete Signaturverfahren beim initialen Pairing zwischen Konnektor und eHealth-Kartenterminal folgende Vorgaben umsetzen:

1. Falls für die aktuelle TLS-Verbindung mit dem Konnektor eine RSA-basierte Ciphersuite verwendet wird, so MUSS für die Signatur des Shared-Secret (ShS.AUT.KT vgl. [gemSpec_KT#2.5.2.1, 3.7.2.1]) RSASSA-PSS [PKCS#1] und SHA-256 verwendet werden. (Hinweis: die Parameter für RSASSA-PSS wie MGF oder Salt-Länge sind durch die SMC-KT eindeutig und fest vorgegeben und werden deshalb hier nicht aufgeführt.)
2. Falls für die aktuelle TLS-Verbindung mit dem Konnektor eine ECDSA-basierte Ciphersuite verwendet wird, so MUSS für die Signatur des Shared-Secret ECDSA [BSI-TR-03111] und SHA-256 verwendet werden (Hinweis: die zu verwendenden Domainparameter (Kurve etc.) sind durch die SMC-KT eindeutig und fest vorgegeben). Für die Kodierung der ECC-Parameter in der Signatur MUSS die plain-Kodierung nach [TR-03111#5.2.1] verwendet werden.

[<=]

Hinweis: Das in A_17090-01 geforderte Verhalten lässt sich bei OpenSSL leicht mit SSL_get_current_cipher() umsetzen.

Ein eHealth-Kartenterminal muss beim TLS-Verbindungsaufbau, der vom Konnektor initiiert wird, dessen TLS-Client-Zertifikat prüfen. Dafür muss ein eHealth-Kartenterminal alle "CA-Zertifikate der relevanten TSP speichern" [gemSpec_KT#TIP1-A_3255]. Um diesen kritischen Punkt, jedoch noch einmal zu unterstreichen:

A_17183 - CA-Zertifikate der relevanten TSP speichern (ECC-Migration)

Das eHealth-Kartenterminal MUSS bei der Umsetzung von [gemSpec_KT#TIP1-A_3255] sowohl RSA-basierte CA-Zertifikate der Komponenten-PKI als auch ECC-basierte CA-Zertifikate (TSL(ECC-RSA)) der Komponten-PKI speichern.
[<=]

A_22458 - TLS-Algorithmus passend zum Pairing

Der Konnektor MUSS beim TLS-Verbindungsaufbau (TLS-Handshake) zu einem eHealth-Kartenterminal ausschließlich Ciphersuiten mit solchen Authentisierungsalgorithmen (entweder RSA oder ECDSA) anbieten, die zum Algorithmus des gespeicherten KT-Zertifikats passen, wenn zu diesem Kartenterminal bereits Pairinginformationen (Shared Secret in Kombination mit dem Zertifikat des Kartenterminals) gespeichert sind. [<=]

Konnektoren speichern die Pairinginformationen zu den mit ihnen gepairten Kartenterminals als Tupel {Kartenterminal-Zertifikat; Shared Secret}, wobei das beim Pairing vom Kartenterminal genutzte Zertifikat gespeichert wird. Wird später (bspw. durch ein Software-Update des Kartenterminals, welches die Nutzung von ECDSA Identitäten ermöglicht) ein anderes Zertifikat vom Kartenterminal beim TLS-Handshake präsentiert (also bspw. eine ECDSA Identität statt der zuvor genutzten RSA-Identität), passt dies für den Konnektor nicht zur vorhandenen Pairinginformation. Der Verbindungsaufbau scheitert somit, bis ein neues Pairing vorgenommen wird (bei dem dann das ECDSA-Zertifikat vom Kartenterminal verwendet wird). Dieses Verhalten muss vermieden werden, da dies einen massenhaften Ausfall von Kartenterminals durch ein Software-Update der Terminals hervorrufen kann. Daher darf der Konnektor nur solche Cipher-Suiten anbieten, die auch zum für das betroffene Kartenterminal gespeicherte Zertifikat passen.

5.8.1 Interoperabilität zwischen eHealth-KT und Konnektor

Zur Sicherstellung der Interoperabilität zwischen Health-KT und Konnektor werden folgende Festlegungen getroffen. Bei den folgend aufgeführten Themen hatte es bezüglich der Interoperabilität Probleme gegeben.

A_22451 - ClientHello ohne akzeptable Cipher-Suite

Falls die ClientHello-Nachricht keine der gemäß [gemSpec_Krypt#A_17089-01] zu unterstützenden Cipher-Suiten enthält, dann MUSS das eHealth-Kartenterminal die ClientHello-Nachricht mit einem "handshake_failure" beantworten, siehe [RFC-5426#7.4.1.2]. [<=]

Hinweise zum Thema Renegotiation:

Hinweis 1: Gemäß GS-A_5525 unterstützt der Konnektor "renegotiation". Daraus folgt, dass er diese Fähigkeit in der ClientHello- Nachricht entweder durch eine "renegotiation_info" extension anzeigt, oder durch ein TLS_EMPTY_RENEGOTIATION_INFO_SCSV (siehe [RFC-5746#3.4, §1, erster Punkt]).

Hinweis 2: Gemäß [RFC-5246#7.4.1.3 letzter §] ist es einem Server nur dann erlaubt in der ServerHello-Nachricht eine "renegotiation_info" extension zu schicken, wenn die ClientHello-Nachricht Informationen zu "renegotiation" enthält. Gemäß dem vorstehenden Hinweis ist das beim TLS-Handshake zwischen Konnektor und eHealth-KT stets der Fall.

Hinweis 3: Die gematik legt nicht fest, wie sich ein eHealth-KT zu verhalten hat, wenn die ClientHello-Nachricht weder eine "renegotiation_info" extension, noch ein TLS_EMPTY_RENEGOTIATION_INFO_SCSV enthält.

Hinweis 4: Es gilt für das eHealth-KT GS-A_5524-*, womit sichergestellt ist, dass ein eHealth-KT keine unsichere TLS-Renegotiation durchführt.

A_22453 - ServerHello, Cipher-Suite

Von den gemäß [gemSpec_Krypt#A_17089-01] zu unterstützenden Cipher-Suiten wählt das eHealth-Kartenterminal eine aus, vergleiche [RFC-5426#7.4.1.3]. Falls das eHealth-Kartenterminal eine Cipher-Suite aus [gemSpec_Krypt#A_17089-01] in der Form

1. TLS_DHE_RSA... (also RSA) auswählt, dann MUSS es eine RSA-basierte Identität zur Authentisierung im Kontext des TLS-Protokols verwenden.
2. TLS_ECDHE_ECDSA... (also ECDSA) auswählt, dann MUSS es eine ECDSA-basierte Identität zur Authentisierung im Kontext des TLS-Protokols verwenden.

[<=]

A_22454 - CertificateRequest

Das eHealth-Kartenterminal MUSS eine CertificateRequest-Nachricht schicken, für die folgendes gilt:

1. Die Struktur CertificateRequest gemäß [RFC-5246#7.4.4] MUSS im Abschnitt certificate_types genau ein Element vom Typ ClientCertificateType enthalten.
2. Falls das eHealth-Kartenterminal in der ServerHello-Nachricht eine Cipher-Suite aus [gemSpec_Krypt#A_17089-01] in der Form
   1. TLS_DHE_RSA... (also RSA) anzeigt, dann MUSS als ClientCertificateType "rsa_sign" gewählt werden, siehe [RFC-5246#7.4.4].
   2. TLS_ECDHE_ECDSA... (also ECDSA) anzeigt, dann MUSS als ClientCertificateType "ecdsa_sign" gewählt werden, siehe [RFC-8422#5.5].

[<=]

A_22455 - ClientCertificate

Bezüglich der ClientCertificate-Nachricht (siehe [RFC-5246#7.4.6]) gilt für das eHealth-Kartenterminal folgendes Verhalten:

8. Falls der Client keine ClientCertificate-Nachricht schickt, dann MUSS der TLS-Handshake mit einem "failure alert" abgebrochen werden.
9. Der TLS-Handshake MUSS fortgesetzt werden, selbst wenn die "certificate_list"
   1. leer ist (also kein Element enthält), oder
   2. kein End-Entity-Zertifikat daraus erfolgreich extrahiert und erfolgreich gegen eine im eHealth-Kartenterminal gespeicherte CA geprüft werden konnte, oder
   3. ein End-Entity-Zertifikat unpassenden Typs enthält (beispielsweise RSA-PublicKey statt ECDSA-PublicKey).

[<=]

5.9 ECC-Migration Konnektor

A_17094-0102 - TLS-Verbindungen Konnektor (ECC-Migration)

Der Konnektor MUSS zusätzlich zu den RSA-basierten TLS-Ciphersuiten (vgl. GS-A_4385 und GS-A_5345-01) die TLS-Ciphersuiten

1. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 und 
2. TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

unterstützen. Dabei MÜSSEN bei dem ephemeren Elliptic-Curve-Diffie-Hellman-Schlüsselaustausch die Kurven P-256 und P-384 [FIPS-186-45] und die Kurven brainpoolP256r1 und brainpoolP384r1 (vgl. [RFC-5639] und [RFC-7027]) unterstützt werden.   Andere Kurven SOLLEN NICHT verwendet werden.
Falls der Konnektor in der Rolle TLS-Client agiert, so MUSS er die eben genannten Ciphersuiten gegenüber RSA-basierten Ciphersuiten (vgl. GS-A_4384-*) bevorzugen (in der Liste "cipher_suites" beim ClientHello vorne an stellen, vgl.  [RFC-5256#7.4.1.2 Client Hello]).
[<=]

Hinweis: für den Konnektor gelten die IPsec-Anforderungen A_17125 und A_17126.

A_17209 - Signaturverfahren für externe Authentisierung (ECC-Migration)

Der Konnektor MUSS an der Schnittstelle für die externe Authentisierung die Signaturverfahren RSASSA-PKCS1-v1_5 [PKCS#1], RSASSA-PSS [PKCS#1]  und ECDSA [BSI-TR-03111] anbieten. [<=]

A_23511 - Konnektor, IOP, Kodierung ECC-Schlüssel, Primärsystem-Verbindungssicherung

Der Konnektor MUSS sicherstellen, dass bei der Umsetzung von TIP1-4517-* ECC-Schlüssel stets in der "named-curve"-Kodierung exportiert werden (d. h., eben gerade nicht die "explizite" Kurvenparameter-Kodierung verwenden).
D. h., sowohl

1. für ein Primärsystem von einem Konnektor erzeugte und exportierte private ECC-Schlüssel MÜSSEN mittels named-curve-Darstellung kodiert sein (siehe Hinweise) und
2. bei den vom Konnektor erzeugten TLS-Authentisierungszertifikaten MÜSSEN die im Zertifikat bestätigten öffentlichen ECC-Schlüssel in der named-curve-Darstellung kodiert sein (siehe Hinweise).

[<=]

Hinweise:

(1) Die meisten in Primärsystemen verwendeten Kryptographie-Bibliotheken erlauben mittlerweile keine explizite Angabe von ECC-Kurvenparametern (i. S. v. explizite Aufführung von A, B, p und q-Werten). Damit sind bspw. vom Konnektor erzeugte Zertifikate, die nicht A_23511-konform sind, mit diesen Bibliotheken nicht verwendbar. Fachlicher Hintergrund ist CVE-2020-0601 (https://nvd.nist.gov/vuln/detail/CVE-2020-0601) und "Digital Signature Schemes with Domain Parameters", Serge Vaudenay, 2004 (https://lasec.epfl.ch/pub/lasec/doc/Vau04b.pdf ).

(2) Ein Beispiel für einen privaten ECC-Schlüssel mit named-curve-Parameter-Kodierung im PEM-Format:

-----BEGIN EC PARAMETERS-----
BgkrJAMDAggBAQc=
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
MHgCAQEEIC5PFJ/4fOdPLZ1BebMqpHN8ydae9kSPGS5qICS/WGpnoAsGCSskAwMC
CAEBB6FEA0IABCpcFsaT3f+O9Cg676mRWR4WazrrbFMcMZ5dwJhrhVsjSzA3z85q
u8eCSvAkE3jt2+nOTNh1s3ExkZVSOJD1aLc=
-----END EC PRIVATE KEY-----
(über 

openssl ecparam -name brainpoolP256r1 -genkey -param_enc named_curve -out <pre>example-named-curve-private-key.pem

erzeugt)

Die DER-Kodierung sieht dann wie folgt aus

$ openssl ec -in example-named-curve-private-key.pem  -pubout -outform der -out mykey.pub
$ dumpasn1 mykey.pub
  0  90: SEQUENCE {
  2  20:   SEQUENCE {
  4   7:     OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
 13   9:     OBJECT IDENTIFIER brainpoolP256r1 (1 3 36 3 3 2 8 1 1 7)
       :     }
 24  66:   BIT STRING
       :     04 2A 5C 16 C6 93 DD FF 8E F4 28 3A EF A9 91 59
       :     1E 16 6B 3A EB 6C 53 1C 31 9E 5D C0 98 6B 85 5B
       :     23 4B 30 37 CF CE 6A BB C7 82 4A F0 24 13 78 ED
       :     DB E9 CE 4C D8 75 B3 71 31 91 95 52 38 90 F5 68
       :     B7
       :   }

0 warnings, 0 errors.

(3) In Abschnitt "5.2 X.509-Root der TI" gibt es ein ausführliches Beispiel für ein X.509-Zertifikat mit einem öffentlichen ECC-Schlüssel mit named-curve-Parameter Kodierung.

5.10 Verschiedene Produkttypen und ECC-Migration (informativ)

Dem VPN-Zugangsdienst sind die IPsec-Anforderungen  und   zugewiesen, ebenso A_17205. Im Rahmen der Registrierung bei einem VPN-Zugangsdienst wird vom Konnektor eine Signatur mittels einer SMC-B erzeugt. Diese muss der VPN-Zugangsdienst (Registierungsserver) prüfen können, dafür gilt für diesen A_17206.

Für die Produkttypen, die bei der Anwendung VSDM verwendet werden, ist die ECC-RSA-TSL-Auswertung   und die ECC-Unterstützung bei TLS A_17124-* relevant.

Fachanwendungsspezifische Anpassungen aufgrund der ECC-Migration befinden sich in den jeweiligen Spezifikationen (bspw. ).

6 Kommunikationsprotokoll zwischen ePA-VAU und ePA-Clients

6.1 Motivation

Die Architekturentscheidung, dass auf der Verbindungsstrecke zwischen einem ePA-Frontend eines Versicherten (Client) bzw. eines FM ePA (Client) und einer VAU (Server) immer HTTP über ein Gateway als Kommunikationsprotokoll verwendet wird, hat Vorteile. Ein Nachteil ist, dass damit keine direkte TLS-Verbindung zwischen Client und Server möglich ist. Der TLS-Kanal terminiert am Gateway. Um die "letzten Meile" zwischen Gateway und VAU innerhalb des ePA-Aktensystems nicht ungeschützt zu lassen, wird das "VAU-Protokoll" eingeführt und verwendet. Es wird nicht der Weg gewählt HTTP über TLS über HTTP über TLS zu tunneln. Stattdessen wird das folgende Protokoll eingeführt als eine leichtgewichtige Sicherungsschicht zwischen einer VAU (Server) und einem ePA-Frontend eines Versicherten (Client) bzw. eines FM ePA (Client). Der Server und der Client besitzen jeweils eine kryptographische Langzeitidentität. Diese sind Grundlage für einen beidseitig authentisierten ephemeren ECDH. Aus dem gemeinsamen ECDH-Geheimnis werden mittels einer HKDF zwei AES-Schlüssel abgeleitet (vgl. A_16943-*). Per AES-GCM werden nach dem Schlüsselaustausch alle ausgetauschten Nutzerdaten kryptographisch gesichert. Es gibt einen Nachrichtenzähler der vor Replay-Attacken schützt.

Die gematik stellt eine Beispielimplementierung bereit (https://fachportal.gematik.de/service/entwicklung/ ).

6.2 Übersicht

Es gibt bei der Kommunikation, die das Protokoll steuert, zwei aktive und einen passiven Teilnehmer. Der Client initiiert die Kommunikation per HTTP-POST-Request. Der Server antwortet als HTTP-Server auf diesen Request mit einer HTTP-Response. Das Gateway leitet die Daten weiter und erscheint unsichtbar. Das Gateway erzwingt die Verwendung des HTTP-Protokolls.

Das Kommunikationsprotokoll hat als Hauptaufgabe die zwischen Client und Server (VAU) auszutauschenden Nutzerdaten vor dem Gateway in Bezug auf Vertraulichkeit, Authentizität, Integrität (inkl. Verhinderung von Replay-Attacken) zu schützen. Das Protokoll bietet (absichtlich) keinen Schutz der HTTP-Header-Informationen. Es ist bei der ePA-Architektur sichergestellt, dass eine Änderung der HTTP-Header-Informationen keine negativen Auswirkungen auf die Vertraulichkeit, Integrität und Authentizität der Nutzerdaten hat. Hinweis zum besseren Verständnis: Zwischen Gateway und Client besteht immer eine TLS-Verbindung, so dass nur das Gateway bzw. nur ein Angreifer im Aktensystem selbst die Header-Informationen ändern könnte.

Ein Designziel ist es, den Verbindungsaufbau möglichst "menschenlesbar" zu gestalten und so die Implementierung und die Fehlersuche (u. a. auch im Betrieb) zu erleichtern. So sind die meisten Nachrichten einfache, menschenlesbare JSON-Objekte. Die im Protokoll definierten Fehlermeldungen (VAUServerError-Nachricht) haben den Hauptzweck, die manuelle Fehleranalyse zu erleichtern. Das VAU-Protokoll ist relativ einfach, so dass ein Client oder ein Server bei Auftreten eines Fehlers selten etwas anderes tun kann, als die Protokollabarbeitung abzubrechen (und als Client einen neuen Protokolldurchlauf zu initiieren). Dies bedeutet: die Art der aufgetretenen Fehlernachricht ist für den Client i. d. R. irrelevant, weil die Handlungsoptionen sehr begrenzt sind. Erst bei der manuellen Fehleranalyse werden die differenzierten Fehlermeldungen hilfreich.

Viele Nachrichten und Datenfelder ähneln fachlich Bestandteilen aus dem TLS-Protokoll und werden absichtlich anders benannt, um Verwechselungen zu vermeiden.

Das Protokoll bietet die Möglichkeit, zukünftig verschiedene CipherConfiguration (im TLS-Protokoll entspricht dies den TLS-Cipher-Suiten) zu unterstützen; aktuell gibt es genau eine ("AES-256-GCM-BrainpoolP256r1-SHA-256").

Der Ablauf der Schlüsselaushandlung des VAU-Protokolls ist im folgenden Ablaufdiagramm dargestellt.

Abbildung 3: Übersicht über das VAU-Protokoll

Da die Werte des ephemeren öffentlichen ECDH-Schlüssels des jeweiligen anderen Kommunikationspartners in die eigene Signatur eingehen, können sowohl Client und Server bei der Signaturprüfung sicherstellen, dass die Schlüsselaushandlung frisch ist (vgl. [Boyd-Mathuria-2003#Abschnitt "1.5 Freshness"]). 

Aus dem gemeinsamen ECDH-Geheimnis wird ein AES-Schlüssel abgeleitet und damit die weitere Kommunikation mittels AES-GCM in Bezug auf Vertraulichkeit und Integrität geschützt. Der dabei explizit mitgelieferte Nachrichtenzähler schützt vor Replay-Attacken.

A_16884 - VAU-Protokoll: Nachrichtentypen und HTTP-Content-Type

Es gibt genau zwei Nachrichtenarten: (1) Nachrichten zur Schlüsselaushandlung (VAUClientHello, VAUServerHello, VAUClientSigFin und VAUServerFin) und Fehlermeldungsübermittlung (VAUServerError) und (2) Nachrichten, die kryptographisch geschützte Nutzerdaten transportieren.
Typ-(1)-Nachrichten MÜSSEN vom Client und vom Server jeweils per HTTP mit dem Content-Type 'application/json' übermittelt werden und Typ-(2)-Nachrichten mit dem Content-Type 'application/octet-stream'. [<=]

A_17074 - VAU-Protokoll: Ignorieren von zusätzlichen Datenfeldern in Protokoll-Nachrichten

Ein Client oder ein Server MUSS zusätzliche (i. S. v. ihm unbekannte) Datenfelder (Key-Value-Paare) in JSON-Objekten (Typ-(1)-Nachrichten und "Data"-Feldern darin) im Rahmen des VAU-Protokolls ignorieren. [<=]

Die in den Anforderungen angegebenen Reihenfolgen von Attribute-Value-Pairs innerhalb der JSON Objekte sind als Beispiele zu verstehen und nicht in ihrer Reihenfolge normativ. Es gilt der JSON Standard [ecma-262].

A_17081 - VAUProtokoll: zu verwendende Signaturschlüssel

Ein Client und ein Server MUSS für die Signatur im Rahmen des VAU-Protokolls (VAUServerHello- und VAUClientSigFin-Nachrichten) Schlüsselmaterial verwenden, dass dediziert für die Entity-Authentication vorgesehen ist (AUT-Schlüsselmaterial (einer eGK, einer SMC-B etc.) oder privates Schlüsselmaterial der VAU-Server-Identität (Rollenprofil "oid_epa_vau")). [<=]

6.3 VAUClientHello-Nachricht

A_16883-01 - VAU-Protokoll: Aufbau VAUClientHello-Nachricht

Der Client MUSS die Kommunikation mittels einer VAUClientHello-Nachricht initiieren. Dafür erzeugt er zunächst eine VAUClientHelloData-Datenstruktur der Form
{
"DataType" : "VAUClientHelloData",
"CipherConfiguration" : [ "AES-256-GCM-BrainpoolP256r1-SHA-256" ],
"PublicKey"  : "...Base64-kodierter-ECC-Schlüssel(DER)...",
"AuthorizationAssertion" : "Authorizaton Assertion (Base64-kodiert)",
"CertificateHash" : "...Base64-kodierter SHA-256 Hashwert des Client-X.509-Zertifikats"
}
Der Client MUSS im Rahmen der Schlüsselaushandlung ein ECDH-Schlüsselpaar basierend auf der Kurve BrainpoolP256r1 [RFC-5639] erzeugen. Er MUSS im "PublicKey"-Feld den öffentlichen Punkt des ephemeren ECDH-Schlüsselpaares  Base64-kodiert gemäß [TR-03111#5.1.1 X9.62 Format] eintragen. Im ”AuthorizationAssertion”-Feld MUSS der Client die Base64-kodierte Authorization-Assertion gemäß A_15592-03 eintragen. Der Client MUSS im ”CertificateHash”-Feld den Base64-kodierten Hashwert seines Client-Zertifikats (AUT- oder AUT_alt-Zertifikat) eintragen (Der Hashwert wird vom kompletten DER-kodierten X.509-Zertifikat inkl. äußerer Zertifikatssignatur erzeugt. Der SHA-256 Hashwert (d. h. 256-Bit = 32 Byte) wird anschließend Base64-kodiert. Diese Kodierung wird als Wert bei ”CertificateHash” eingetragen.).

Beispiel:
{
"DataType" : "VAUClientHelloData",
"CipherConfiguration": [ "AES-256-GCM-BrainpoolP256r1-SHA-256" ],
"PublicKey" : "MFowFAYHKoZIzj0CAQYJKyQDAwIIAQEHA0IABDY8OMZlrJpLUdgnm8gHbevpFjemkL8IxMXohQlw3VHePf+T1lW+P0nW9VpnU1SxwCkjY1PU6HGTT+3wawKvRIE=",
"AuthorizationAssertion" : ".......",
"CertificateHash" : "wu72yzp4KdtcWV/vJUcKW14UL+FIJyWcwgETbxwDK+4="
}

Hinweis: Der öffentliche Schlüssel im Beispiel hat nach der Base64-Dekodierung folgende ASN.1-Datenstruktur:
  0  90: SEQUENCE {
  2  20:   SEQUENCE {
  4   7:     OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
 13   9:     OBJECT IDENTIFIER brainpoolP256r1 (1 3 36 3 3 2 8 1 1 7)
       :     }
 24  66:   BIT STRING
       :     04 36 3C 38 C6 65 AC 9A 4B 51 D8 27 9B C8 07 6D
       :     EB E9 16 37 A6 90 BF 08 C4 C5 E8 85 09 70 DD 51
       :     DE 3D FF 93 D6 55 BE 3F 49 D6 F5 5A 67 53 54 B1
       :     C0 29 23 63 53 D4 E8 71 93 4F ED F0 6B 02 AF 44
       :     81
       :   }

Der Client MUSS diese Datenstruktur Base64-kodieren und vom Ergebnis einen SHA-256-Hashwert bilden, den er später mit dem im VAUServerHello aufgeführten Wert vergleichen muss. In das Datenfeld "Data" in der folgenden VAUClientHello-Nachricht MUSS er die Base64-kodierte VAUClientHelloData-Daten eintragen.

Die VAUClientHello-Nachricht hat folgenden Aufbau:
{ 
"MessageType" : "VAUClientHello",
"Data"        : "...Base64-kodierte-VAUClientHelloData..."
}

[<=]

A_16897 - VAU-Protokoll: Versand der VAUClientHello-Nachricht

Der Client MUSS die VAUClientHello-Nachricht per HTTP mit dem Content-Type 'application/json' an den Server senden. [<=]

6.4 VAUServerHello-Nachricht

A_16898 - VAU-Protokoll: Erzeugung des Hashwert vom Data-Feld aus der VAUClientHello-Nachricht

Der Server MUSS beim Empfang der VAUClientHello-Nachricht einen SHA-256-Hashwert der Daten im Data-Feld (zunächst keine Base64-Dekodierung durchführen) erzeugen. [<=]

A_16901-02 - VAU-Protokoll: Aufbau der VAUServerHello-Nachricht

Der Server MUSS auf die VAUClientHello-Nachricht mit einer VAUServerHello-Nachricht, folgender Form, antworten
{ 
"MessageType" : "VAUServerHello",
"Data"        : "...Base64-kodierte-Daten...",
"Signature"   : "...Base64-kodierte-ECDSA-Signatur...",
"Certificate" : "...Base64-kodiertes-Signaturzertifikat...",
"OCSPResponse" : "...Base64-kodierte-OCSP-Response-für-dieses-Zertifikat..."
}

Die ECDSA-Signatur MUSS nach [TR-03111#5.2.2. X9.62 Format] ("ecdsa-with-Sha256") kodiert sein.
In den Daten von "Data" MUSS der Server in die Base64-kodierte VAUServerHelloData-Datenstruktur der folgenden Form eintragen. Der Server MUSS im "CertificateHash"-Feld den Base64-kodierten SHA-256 Hashwert des Server-X.509-Zertifikats eintragen. (Der Hashwert wird vom kompletten DER-kodierten X.509-Zertifikat inkl. äußerer Zertifikatssignatur erzeugt. Der SHA-256 Hashwert (d. h. 256-Bit = 32 Byte) wird anschließend Base64-kodiert. Diese Kodierung wird als Wert bei ”CertificateHash” eingetragen.)
{
"DataType" : "VAUServerHelloData",
"CipherConfiguration" : [ "AES-256-GCM-BrainpoolP256r1-SHA-256" ],
"VAUClientHelloDataHash" :  "...SHA-256-Hashwert-des-erhaltenen-Data-Felds-in-VAUClientHello...",
"PublicKey"  : "...Base64-kodierter-ECC-Schlüssel(DER)...",
"CertificateHash" : "...Base64-kodierter SHA-256 Hashwert des Server-X.509-Zertifikats"
}
Der Server MUSS im "PublicKey"-Feld den öffentlichen Punkt seines ephemeren ECDH-Schlüsselpaares Base64-kodiert gemäß [TR-03111#5.1.1 X9.62 Format] eintragen.

Der Server MUSS im Feld "VAUClientHelloDataHash" den Base64-kodierten SHA-256-Hashwert der empfangenen VAUClientHelloData (ohne Base64-Dekodierung) eintragen (vgl. ). 

Der Server MUSS die in der Datenstruktur (VAUServerHello) angegebene Signatur erzeugen (über den Base64-kodieren Wert im "Data"-Feld). Im "Certificate"-Feld MUSS er das für eine Signaturprüfung notwendige EE-Zertifikat eintragen und im "OCSPResponse"-Feld die OCSP-Response, die nicht älter als 24 Stunden sein darf, für dieses EE-Zertifikat.
[<=]

A_16902 - VAU-Protokoll: Versand der VAUServerHello-Nachricht

Der Server MUSS auf eine VAUClientHello-Nachricht mit einer VAUServerHello-Nachricht antworten. Der Server MUSS die VAUServerHello-Nachricht per HTTP mit dem Content-Type 'application/json' an den Client senden. [<=]

A_16903 - VAU-Protokoll: Client, Prüfung des VAUClientHelloDataHash-Werts (aus VAUServerHelloData)

Der Client MUSS beim Empfang der VAUServerHello-Nachricht den Hashwert "VAUClientHelloDataHash" (vgl. A_16901-*) mit dem vom ihm (Client) vor dem Versand der VAUClientHello-Nachricht (vgl. A_16883-01) errechneten Wert vergleichen. Sind die beiden Werte verschieden, so MUSS der Client den Protokollablauf abbrechen. [<=]

A_16941-01 - VAU-Protokoll: Client, Prüfung der Signatur der VAUServerHelloData

Der Client MUSS die Signatur der Daten von "Data" prüfen (bitgenau den Datenwert von "Data" nehmen, ohne eine Base64-Dekodierung) der "Data"-Daten vorzunehmen. Der Client MUSS dafür den Signaturschlüssel des Servers auf Authentizität und Integrität prüfen. (Hinweis: in einem Client wird die TSL der TI als Prüfgrundlage für die Prüfung von TI-Zertifikaten verwendet.) Falls die Signaturprüfung kein positives Ergebnis erbringt, so MUSS der Client den Protokollablauf abbrechen (vgl. A_16849).
Der Client MUSS prüfen, ob der im VAUServerHelloData->CertificateHash aufgeführter Hashwert mit dem Hashwert des Server-Zertifikats im VAUServerHello->Certificate-Feld übereinstimmt (vgl. Erzeugung des Hashwerts in A_16901-*). Falls nein, so MUSS der Client den Protokollablauf abbrechen (vgl. ). [<=]

A_23273 - VAU-Protokoll: Client, Prüfung der Signatur der VAUServerHelloData, Gültigkeit von OCSP-Antworten

Der Client MUSS bei der Signaturprüfung der VAUServerHelloData die im "OCSPResponse"-Feld enthaltene OCSP-Response verwenden, wenn diese nicht älter als 24 Stunden ist.
Dabei MUSS geprüft werden: Systemzeit - 24h <= producedAt. (Eine zusätzliche Auswertung von nextUpdate SOLL NICHT erfolgen.)
Andernfalls MUSS der Client eine frische OCSP-Response einholen. [<=]

6.5 Schlüsselableitung

A_16852-01 - VAU-Protokoll: ECDH durchführen

Der Client und auch der Server MÜSSEN jeweils für sich prüfen, ob der empfangene ephemere öffentliche elliptische Kurvenpunkt der Gegenseite auch auf der von ihnen verwendeten Kurve (BrainpoolP256r1) liegt.
Falls nein, MÜSSEN sie jeweils den Protokollablauf abbrechen. Falls der Server derjenige ist, der in diesem Fall abbricht, MUSS der zuvor an den Client eine VAUServerError-Nachricht mit der Fehlermeldung "invalid curve (ECDH)" senden.
Falls ja, MÜSSEN beide einen ECDH nach [NIST-800-56-A] durchführen. Das dabei erzeugte gemeinsame Geheimnis ist folgend Grundlage von drei Schlüsselableitungen (vgl.  ). [<=]

A_16943-01 - VAU-Protokoll: Schlüsselableitung (HKDF)

Für die Schlüsselableitung MÜSSEN Client und Server die HKDF nach [RFC-5869] auf Basis von SHA-256 verwenden.
Das ”Input Keying Material” (IKM) [RFC-5869] ist das in  erzeugte gemeinsame ECDH-Geheimnis zwischen Server und Client.
Die erste Schlüsselableitung hat den Ableitungsvektor ”KeyID” (”info” Parameter aus [RFC-5869] ist dann also ”KeyID”) und erzeugt einen 256 Bit langen Schlüsselidentifier.
Die zweite Schlüsselableitung mit dem Ableitungsvektor ”AES-256-GCM-Key-Client-to-Server” erzeugt den 256-Bit AES-Schlüssel für die Verwendung innerhalb von AES-256-GCM für Nachrichten, die der Client für den Server verschlüsselt.
Die dritte Schlüsselableitung mit dem Ableitungsvektor ” AES-256-GCM-Key-Server-to-Client” erzeugt den 256-Bit AES-Schlüssel für die Verwendung innerhalb von AES-256-GCM für Nachrichten, die der Server für den Client verschlüsselt. [<=]

6.6 VAUClientSigFin-Nachricht

A_17070-02 - VAU-Protokoll: Aufbau der VAUClientSigFin-Nachricht

Der Client MUSS auf eine VAUServerHello-Nachricht mit einer wie folgt definierten VAUClientSigFin-Nachricht antworten.
Die VAUClientSigFin-Nachricht hat folgenden Aufbau:
{ 
"MessageType"    : "VAUClientSigFin",
"VAUClientHelloDataHash" : "...SHA-256-Hashwert-der-Base64-kodierten-VAUClientHelloData...",
"VAUServerHelloDataHash" : "...SHA-256-Hashwert-der-erhaltenen-Base64-kodierten-VAUServerHelloData...", 
"Signature" : "...Base64-kodierte-Signatur...",
"Certificate" : "...Base64-kodiertes-Signaturzertifikat...",
"OCSPResponse" : "...Base64-kodierte-OCSP-Response-für-dieses-Zertifikat...",
"FinishedData" : "...Base64-kodierte-verschlüsselte-Finished-Daten ..."
}

Im "VAUClientHelloDataHash"-Feld MUSS der Client den Base64-kodieren Hashwert seiner Base64-kodierten VAUClientHelloData eintragen.
Im "VAUServerHelloDataHash"-Feld MUSS der Client den Base64-kodieren Hashwert der empfangenen Base64-kodierten VAUServerHelloData eintragen.
Die folgende Signatur MUSS der Client über die beiden konkatenierten Base64-kodierten Zeichenketten (Inhalt vom "VAUClientHelloDataHash"-Feld || Inhalt vom "VAUClientServerDataHash"-Feld) bilden.

Eine ECDSA-Signatur im "Signature"-Feld MUSS nach [TR-03111#5.2.2. X9.62 Format] ("ecdsa-with-Sha256") kodiert sein.
Diese so kodierte Signatur wird Base64-kodiert und als Wert im "Signature"-Feld eingetragen.
Eine RSASSA-PSS-Signatur MUSS nach [RFC-8017] (PKCS#1) kodiert werden. Diese so kodierte Signatur wird Base64-kodiert und als Wert im "Signature"-Feld eingetragen.
(Verständnishinweis: Eine G2-Karte kann in Bezug auf AUT-Schlüssel nur RSA-Signaturen erzeugen. Eine G2.x-Karte kann und MUSS im Kontext VAU-Protokoll ECDSA-Signaturen erzeugen.)

Der Client MUSS im "Certificate"-Feld das für die Prüfung der Signatur notwendige X.509-EE-Zertifikat Base64-kodiert eintragen.

Er SOLL für dieses Zertifikat im "OCSPResponse"-Feld die OCSP-Response, die nicht älter als 24 Stunden sein darf, eintragen.
Falls ihm keine OCSP-Response zur Verfügung steht, so MUSS er im OCSPResponse-Feld den Leerstring als Wert eintragen ("OCSPResponse" : "").

Der Client MUSS für die Berechnung des "FinishedData"-Feldes zunächst folgende Zeichenkette bilden
"VAUClientSigFin" ||
unkodierter Hashwert aus "VAUClientHelloDataHash" ||
unkodierter Hashwert aus  "VAUServerHelloDataHash"
Diese Zeichenkette MUSS 15+32+32=79 Bytes lang sein. Der Client MUSS diese Zeichenkette mittels AES-GCM (vgl. ) verschlüsseln und dabei folgende Zeichenkette bilden
256-Bit KeyID || 96-Bit Nonce (IV) mit Ciphertext und 128 Bit Authentication-Tag
Diese Zeichenkette MUSS er Base64-kodieren und das Ergebnis als Wert des "FinishedData"-Feld eintragen.
[<=]

Hinweis: Obwohl innerhalb einer der VAUServerHelloData der Wert VAUClientHelloDataHash enthalten ist und damit auch in die Berechnung von VAUServerHelloDataHash mit einfließt, wird der Wert VAUClientHelloDataHash explizit in VAUClientSigFin aufgeführt. Ziel ist es möglichst direkt Transparenz über die bestätigten Daten zu schaffen.

A_17071 - VAU-Protokoll: Versand der VAUClientSigFin-Nachricht

Der Client MUSS auf eine VAUServerHello-Nachricht mit einer VAUClientSigFin-Nachricht antworten. Der Client MUSS die VAUClientSigFin-Nachricht per HTTP mit dem Content-Type 'application/json' an den Server senden. [<=]

6.7 VAUServerFin-Nachricht

A_17072-01 - VAU-Protokoll: Empfang der VAUClientSigFin-Nachricht

Der Server MUSS beim Empfang der VAUClientSigFin-Nachricht prüfen,

1.   ob die darin enthaltene Signatur gültig ist, 

2.   ob der Hashwert des Client-Zertifikats aus dem ”Certificate”-Feld gleich dem Hashwert aus dem ClientHelloData->CertificateHash-Feld ist (vgl. Erzeugung des Hashwerts in ), und

3.   ob der Wert im "FinishedData"-Feld der nach  zu erwartenden Wert entspricht.

Falls eine der Prüfungen 1 bis 3 ein nicht-positives Prüfergebnis liefert, so MUSS der Server mit einer VAUServerError-Nachricht antworten und die weitere Protokolldurchführung abbrechen. Wobei er folgende Fehlermeldung pro Prüfung verwenden MUSS: 

1.   -> "Signature from VAUClientSigFin invalid"

2.   -> "Client Certificate inconsistent", und

3.   -> "VAUClientSigFin invalid".

[<=]

A_16899 - VAU-Protokoll: Aufbau der VAUServerFin-Nachricht

Der Server MUSS eine wie folgt aufgebaute VAUServerFin-Nachricht erzeugen.
{ 
"MessageType"    : "VAUServerFin",
"FinishedData" : "...Base64-kodierte-verschlüsselte-Finished-Daten..."
}
Der Server MUSS für die Berechnung des "FinishedData"-Feldes zunächst folgende Zeichenkette bilden
"VAUServerFin" ||
unkodierter Hashwert aus "VAUClientHelloDataHash" ||
unkodierter Hashwert aus "VAUServerHelloDataHash"
Diese Zeichenkette MUSS 12+32+32=76 Bytes lang sein. Der Server MUSS diese Zeichenkette mittels AES-GCM (vgl. ) verschlüsseln und dabei folgende Zeichenkette bilden
256-Bit KeyID || 96-Bit Nonce (IV) mit Ciphertext und 128 Bit Authentication-Tag
Diese Zeichenkette MUSS er Base64-kodieren und das Ergebnis als Wert des "FinishedData"-Feld eintragen. [<=]

A_17073 - VAU-Protokoll: Versand der VAUServerFin-Nachricht

Der Server MUSS nach dem Erhalt einer VAUClientSigFin-Nachricht mit einer VAUServerFin-Nachricht antworten. Der Server MUSS die VAUServerFin-Nachricht per HTTP mit dem Content-Type 'application/json' an den Client senden. [<=]

A_17084 - VAU-Protokoll: Empfang der VAUServerFin-Nachricht

Der Client MUSS beim Empfang der VAUServerFin-Nachricht prüfen, ob der Wert im "FinishedData"-Feld der nach A_16899 zu erwartenden Wert entspricht. Falls nein, so MUSS der Client den weiteren Protokollablauf abbrechen (vgl. A_16849). [<=]

6.8 Nutzerdatentransport

A_16945-02 - VAU-Protokoll: Client, verschlüsselte Kommunikation (1)

Wie bei der Schlüsselaushandlung MUSS der Client mittels HTTP-POST-Request die nun verschlüsselte Kommunikation initiieren.
Der Client MUSS einen unsigned 64-Bit-Nachrichtenzähler führen, die er bei jeder abgeschickten Nachricht um zwei erhöhen MUSS.

Er bildet die Datenstruktur "P1" mit
 P1=Version (ein Byte mit dem Wert 0x01) || 
    Nachrichtenzähler (unsigned 64-Bit im Big-Endian-Format) || 
    Anzahl der Bytes der folgenden zusätzlichen HTTP-
Header-Informationen (unsigned 32-Bit im Big-Endian-Format) || 
    zusätzliche HTTP-Header-Informationen || 
    Plaintext 
wobei „Plaintext“ die zu übertragende Nutzlast (bspw. SOAP-Request) bezeichnet. 

Wenn die Anzahl der Bytes der folgenden zusätzlichen HTTP-Header-Informationen mit 0 (also 0x00000000) angegeben wird, so gibt es keine folgenden zusätzlichen HTTP-Header-Informationen, d. h. es folgen direkt die Plaintext-Bytes. 

Der Nachrichtenzähler MUSS initial mit 1 starten.
Der Client MUSS zunächst einen IV wie folgt erzeugen:

•      Sei a ein zufällig erzeugtes 32-Bitfeld.

•      Sei IV=a (32 Bit) || Nachrichtenzähler (unsigned 64-Bit im Big-Endian-Format).

Damit ist der IV 96-Bit lang. Unter Verwendung dieses IV und des zweiten aus  abgeleiteten Schlüssel (Client-to-Server-Schlüssel) wird P1 verschlüsselt. Der Client berechnet so den "Ciphertext".
Die vom Client nun an den Server zu übermittelnde Datenstruktur MUSS folgende Form besitzen.
 256-Bit KeyID || 96-Bit IV mit Ciphertext und 128 Bit Authentication-Tag

Diese Nachricht MUSS der Client per HTTP-POST-Request mit Content-Type 'application/octet-stream' ohne weitere Kodierungen versenden. [<=]

A_16952-02 - VAU-Protokoll: Server, verschlüsselte Kommunikation

Der Server erkennt aus der KeyID, welchen AES-Schlüssel er für die Entschlüsselung verwenden muss (vgl. A_16943-* zweiter abgeleiteter Schlüssel (Client-to-Server-Schlüssel)).
Falls ihm die KeyID unbekannt ist, so MUSS er mit einer VAUServerError-Nachricht mit der Fehlermeldung "KeyID XXX not found" antworten, wobei er XXX durch die empfangene KeyID in Hexadezimalform ersetzen MUSS.
Falls bei der Entschlüsselung ein Fehler auftritt (bspw. Authentication-Tag passt nicht zur Nachricht), MUSS der Server mit einer VAUServerError-Nachricht mit der Fehlermeldung "AES-GCM decryption error." antworten.

Falls die Entschlüsselung erfolgreich war, MUSS der Server den Klartext gemäß der Struktur von P1 aus A_16945-*  interpretieren.

Falls die Version in P1 ungleich 0x01 ist, so MUSS der Server (1) eine VAUServerError-Nachricht gemäß A_16851-* mit der Fehlermeldung ”invalid protocoll version” senden und gemäß A_16849 die Protokollausführung abbrechen.

Sei mit ”Server-Zählerwert” der letzte vom Server für den Nachrichtenversand verwendete Zählerwert bezeichnet. Initial (d. h. es wurde innerhalb eines Protokollablaufs noch nie eine Nachricht vom Server versendet) MUSS dieser Server-Zählerwert gleich 0 sein.
Der Server MUSS prüfen, ob der Zählerwert im Klartext größer als der ”Server-Zählerwert” ist. Falls nein, so MUSS der Server (1) eine VAUServerError-Nachricht gemäß A_16851-* mit der Fehlermeldung ”invalid counter value” senden und (2) gemäß A_16849 die Protokollausführung abbrechen.
Der Server MUSS den ”Server-Zählerwert” auf Zählerwert + 1 setzen.
Falls es dabei zu einem Zählerüberlauf kommt, so MUSS der Server (1) eine VAUServerError-Nachricht gemäß A_16851-* mit der Fehlermeldung ”message counter overflow” senden und (2) gemäß A_16849 die Protokollausführung abbrechen.
Der Server MUSS zusätzliche HTTP-Header-Informationen analog zu A_16945-* interpretieren und verwenden. Falls dies nicht möglich ist (bspw. Längenwert ist größer als eigentliche Nachrichtengröße), so MUSS der Server (1) eine VAUServerError-Nachricht gemäß A_16851-* mit der Fehlermeldung ”HTTP additional header length error” senden und (2) gemäß A_16849 die Protokollausführung abbrechen.

Der Server erzeugt zunächst die Datenstruktur "P2" mit
 P2 = Version (ein Byte mit dem Wert 0x01) || 
      Server-Zählerwert (unsigned 64-Bit, big-endian-format) ||
      Anzahl der Bytes der folgenden zusätzlichen HTTP-Header-Informationen (unsigned 32-Bit im Big-Endian-Format) || 
       zusätzliche HTTP-Header-Informationen || 
      Klartext-Antwort des Servers

Der Server MUSS P2 mit AES-256-GCM verschlüsseln. Dafür MUSS der Server zufällig eine 96-Bit-großen IV wie folgt erzeugen:

1.   Sei a ein zufällig erzeugtes 32-Bitfeld.

2.   Sei IV=a (32 Bit) || Server-Nachrichtenzähler (unsigned 64-Bit im Big-Endian-Format).

Damit ist der IV 96-Bit lang. Unter Verwendung dieses IV und des dritten aus A_16943-* abgeleiteten Schlüssel (Server-to-Client-Schlüssel) MUSS der Server P2 verschlüsseln.

Die zu übermittelnde Datenstruktur MUSS folgende Form besitzen
 256-Bit KeyID || 96-Bit IV mit Ciphertext und 128 Bit Authentication-Tag

Diese Datenstruktur MUSS der Server per HTTP-Response mit Content-Type 'application/octet-stream' ohne weitere Kodierungen versenden. [<=]

A_16957-01 - VAU-Protokoll: Client, verschlüsselte Kommunikation (2)

Beim Empfang der Antwort (vgl. A_16952-*) MUSS der Client folgende Vorgaben durchsetzen.
Falls

1.   er die KeyID nicht kennt,

2.   die Entschlüsselung fehlschlägt (bspw. Authentication-Tag passt nicht zur Nachricht), oder

3.   der 64-Bit Zählerwert ungleich 1 plus dem Zählerwert ist, den der Client für den Request verwendet hat,

so MUSS der Client die Nachricht verwerfen und die weitere Protokollausführung mittels des empfangenen KeyID abbrechen.

Anderen falls (alles ok, kein Abbruch) MUSS der Client den mit der KeyID verbundenen Zählerwert um eins erhöhen. D. h., Nachrichten vom Client an den Server haben immer einen ungeraden Zählerwert. [<=]

A_16958 - VAU-Protokoll: Client, Neuinitiieren einer Schlüsselaushandlung

Der Client KANN jeder Zeit eine neue Schlüsselaushandlung (VAUClientHello etc.) initiieren. [<=]

A_17069 - VAU-Protokoll: Client Zählerüberlauf

Der Client MUSS, falls so viele Nachrichten ausgetauscht werden, dass für den unsigned 64-Bit-Nachrichtenzähler ein arithmetischer Überlauf droht, eine neue Schlüsselaushandlung initiieren (VAUClientHello etc.). [<=]

6.9 VAUServerError-Nachricht

A_16851-01 - VAU-Protokoll: VAUServerError-Nachrichten

Der Server MUSS folgende Vorgaben umsetzen:
In verschiedenen im Protokoll beschriebenen Fehlerfällen sendet der Server eine VAUServerError-Nachricht an den Client.
Für die eigentliche Fehlerübermittlung MUSS folgende Datenstruktur erzeugt:
{
"DataType" : "VAUServerErrorData",
"Data"     : "...Fehlermeldung...", 
"Time"     : "...aktuelle-Zeit-in-der-VAU..."
}
Die Zeit im "Time"-Feld MUSS im Format nach ISO-8601 kodiert werden (Beispiel: "2018-11-22T10:00:00.123456").
Diese Datenstruktur MUSS der Server Base64-kodieren und in der folgenden Nachricht im Datenfeld "Data" einbetten.
{
"MessageType" : "VAUServerError",
"Data" : "...Base64-kodierte-VAUServerErrorData..",
"Signature" : "...Base64-kodierte-ECDSA-Signatur...",
"Certificate" : "...Base64-kodiertes-Signaturzertifikat...",
"OCSPResponse" : "...Base64-kodierte-OCSP-Response-für-dieses-Zertifikat..."
}

Die ECDSA-Signatur im "Signature"-Feld MUSS nach [TR-03111#5.2.2. X9.62 Format] ("ecdsa-with-Sha256") kodiert sein.
Im "Certificate"-Feld MUSS der Server, das verwendete Signaturzertifikat aufführen, und im "OCSPResponse"-Feld eine OCSP-Response für diese Zertifikat, welche nicht älter als 24 Stunden ist. [<=]

A_16900 - VAU-Protokoll: Client, Behandlung von Fehlernachrichten

Erhält der Client eine VAUServerError-Nachricht (vgl. A_16851-01), MUSS er die Signatur prüfen. Falls die Prüfung positiv ist, so MUSS er die Protolldurchführung abbrechen (vgl. A_16849). [<=]

A_23282 - VAU-Protokoll: Signaturen im VAU-Protokoll

Clients und Server im VAU-Protokoll-Sinne MÜSSEN bei der Signaturerzeugung und -Prüfung beachten, dass die Signaturen der Nachrichten des VAU-Protokoll (wie in A_16851-* definiert) über die Base64-kodierten Daten erfolgt. Dies gilt für alle Protokoll-Nachrichten im VAU-Protokoll -- stets werden die Base64-kodierten Daten des "Data"-Felds signiert. [<=]

6.10 Abbrechen des Protokollablaufs

A_16849 - VAU-Protokoll: Aktionen bei Protokollabbruch

Wenn ein Client oder ein Server den Protokollablauf nach Protokollbeschreibung abbrechen muss, dann MUSS dieser die eventuell aktuell vorhandene KeyID aus seiner Datenbasis löschen und die damit verbundenen Schlüssel sicher löschen.
[<=]

6.11 VAU-Kanal und MTOM/XOP

Nachdem die Etablierung des VAU-Kanals abgeschlossen ist, kommuniziert ein VAU-Client (bspw. ein ePA-FdV) mit der VAU bspw. um einen großen verschlüsselten Arztbrief der Akte hinzuzufügen. Dabei ist es für die Performanz (also auch für die Nutzerakzeptanz) günstig, größere Daten mittels der „SOAP Message Transmission Optimization Mechanism (MTOM)“/ „XML-binary Optimized Packaging (XOP)“-Kodierung zu transportieren. MTOM/XOP ist die nach W3C empfohlene Methode, um über HTTP/SOAP größere binäre Daten zu transportieren. Dabei werden die Binärdaten nicht Base64- innerhalb einer XML-Datenstruktur kodiert, sondern beim HTTP/SOAP-Request (bzw. bei der -Response) über eine MIME-Multipart-Kodierung innerhalb von HTTP. Dabei werden innerhalb der SOAP-Nachricht die Binärdaten über eine ID (<xop:Include href=“cid:Beispiel-ID1“/>) referenziert und innerhalb des HTTP-Request bzw. der HTTP-Response über die „Content-ID“ (vgl. das folgende Beispiel) und eine MIME-Kodierung binär kodiert. Dies führt zur Reduktion Datengröße der zu übertragenden Daten von rund 27,5%.

Beispiel:

Ohne MTOM/XOP:

POST /URL1 HTTP/1.1
Content-Type: application/soap+xml; charset=UTF-8
Content-Transfer-Encoding: binary
Content-Length: …
 
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header />
  <SOAP-ENV:Body>
    <ns1:uploadFileRequest xmlns:ns1="urn:example:Upload">
      <ns1:name>Test-Bild.png</ns1:name>
      <ns1:content> … Hier kommen in Base64 kodierte Daten … </ns1:content>
    </ns1:uploadFileRequest>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

 

Mit MTOM/XOP:

POST /URL1 HTTP/1.1
Content-Type: Multipart/Related; boundary="----=_Part_1_1234----"; type="application/xop+xml"; start="Eintrag-1"; start-info=“application/soap+xml“; charset=UTF-8
Content-Transfer-Encoding: binary
Content-Length: …
 
----=_Part_1_1234----
Content-Type: application/xop+xml; type=“application/soap+xml“; charset=“UTF-8“
Content-Transfer-Encoding: 8bit
Content-ID: Eintrag-1
 
<s11:Envelope xmlns:s11='http://schemas.xmlsoap.org/soap/envelope/' xmlns:xmime='http://www.w3.org/2005/05/xmlmime'>
 <s11:Body>
  <m:data xmlns:m='http://example.org/stuff'>
  <m:photo xmime:contentType='image/jpeg'>
   <xop:Include xmlns:xop='http://www.w3.org/2004/08/xop/include'
        href='cid:Bild-1'/>
</m:photo>
</m:data>
 </s11:Body>
</s11:Envelope>
 
----=_Part_1_1234----
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: Bild-1
 
… hier kommen die binären Daten …
----=_Part_1_1234----
 

Für die Dekodierung einer solchen MIME-Multipart-Kodierung ist es sehr hilfreich (und ggf. notwendig) als Empfänger den vom Sender intendierten (vollständigen) „Content-Type“ aus dem HTTP-Request-Header bzw. dem HTTP-Response-Header zu kennen. Dieser wird jedoch durch das VAU-Protokoll überschrieben (vgl. A_16945-* und A_16952-*). Um die u. a. nach [gemSpec_FM_ePA#A_16220-*] und [gemSpec_ePA_FdV#A_16222-*] geforderte Verwendung von MTOM/XOP zu unterstützen, wird der originär intendierte Content-Type, der im „start“-Feld ggf. vertrauliche Daten enthalten kann, innerhalb der „zusätzlichen HTTP-Header-Informationen“ (vgl. A_16945-* und A_16952-*) mitgeliefert.

A_18465-01 - VAU-Protokoll: MTOM/XOP-HTTP-Header-Informationen

Wenn ein VAU-Client oder ein VAU-Server Übertragungen mittels MTOM/XOP durchführen, so MÜSSEN sie die durch MTOM/XOP erzeugten „Content-Type“-Informationen (vgl. [gemSpec_Krypt#6.11 VAU-Kanal und MTOM/XOP]) innerhalb ihrer Nachricht als „zusätzliche HTTP-Header-Informationen“ gemäß A_16945-* und A_16952-* aufführen. [<=]

6.12 Zusätzliche HTTP-Header-Informationen

A_20549 - VAU-Protokoll: Einbringen der ursprünglich intendierten Content-Type-Variable

Ein VAU-Client oder ein VAU-Server MÜSSEN in den „zusätzliche HTTP-Header-Informationen“ gemäß A_16945-* und A_16952-*, die ursprünglich intendierten Content-Type HTTP-Header-Variable einbringen. D. h. Ein Kommunikationspartner erstellt einen HTTP-Request oder eine HTTP-Response. Diese hat eine "ursprünglich intendierten Content-Type", bspw. "application/soap+xml; charset=utf-8". Diese MUSS dann bei der Verschlüsselung der Nachricht mittels des VAU-Protokolls in die "zusätzlichen HTTP-Header-Informationen" eingetragen werden. [<=]

A_18466-01 - VAU-Protokoll: zusätzliche HTTP-Header-Informationen

Wenn ein VAU-Client oder ein VAU-Server Übertragungen durchführen und in den empfangenen Nachrichten sind „zusätzliche HTTP-Header-Informationen“ gemäß A_16945-* und A_16952-*, so MÜSSEN sie diese auswerten (Hinweis: insbesondere „Content-Type“-Informationen (vgl. [gemSpec_Krypt#6.11 VAU-Kanal und MTOM/XOP]).

Dabei "überschreiben" diese zusätzlichen HTTP-Header-Information HTTP-Header-Variablen im "äußeren" HTTP-Request (insbesondere "Content-Type") bei der Interpretation der Informationen aus dem Request. [<=]

6.13 Tracing in Nichtproduktivumgebungen

Für die Fehlersuche -- insbesondere bei IOP-Problemen zwischen Produkten verschiedener Hersteller in einer fortgeschrittenen Entwicklungsphase -- hat es sich als notwendig erwiesen, dass ein Fehlersuchender den Klartext der Kommunikation zwischen ePA-Client und VAU-Instanz mitlesen kann. Vgl. [gemSpec_Aktensystem#5.8. Tracing in Nichtproduktivumgebungen].

A_21888 - VAU-Client, Nichtproduktivumgebung, vorgegebene ECDH-Schlüssel

Ein Client im VAU-Protokoll MUSS in einer Nichtproduktivumgebung von A_16883-* abweichen in dem er sein ephemeres ECDH-Schlüsselpaar nicht zufällig erzeugt, sondern folgendes ECDH-Schlüsselpaar (auf der Kurve BrainpoolP256r1) für jeden VAU-Protokollverbindungsaufbau verwendet:

•   privater Schlüssel: d=0x78ece94904fc6bf9900cced4c5af4dcd4fbebc585b2054b636cc3f76333bdee

•   öffentlicher Schlüssel: x=0x21fafedc8ba1ef5477995a28a9794f86355df305f1f58afc88f87e91c664353a y=0x27803e3dcf670bd305f3b923f915bfe119389d869c3565828c89bd422231f9f4

[<=]

Hinweis-1: SHA-256("gemSpec_Krypt: privater VAUClient-ECDH-Schluessel fuer Nichtproduktivumgebungen nach A_21888-*") ist als hexdump kodiert gleich 078ece94904fc6bf9900cced4c5af4dcd4fbebc585b2054b636cc3f76333bdee

Hinweis-2:

Folgend ist der private Schlüssel aus A_21888-* als PKCS8-Container PEM-kodiert aufgeführt:

-----BEGIN PRIVATE KEY-----
MIGIAgEAMBQGByqGSM49AgEGCSskAwMCCAEBBwRtMGsCAQEEIAeOzpSQT8a/mQDM
7Uxa9NzU++vFhbIFS2Nsw/djM73uoUQDQgAEIfr+3Iuh71R3mVooqXlPhjVd8wXx
9Yr8iPh+kcZkNTongD49z2cL0wXzuSP5Fb/hGTidhpw1ZYKMib1CIjH59A==
-----END PRIVATE KEY-----

A_21977 - VAU-Client, Nichtproduktivumgebung, vorgegebene ECDH-Schlüssel, optionale Konfigurierbarkeit

Ein Client im VAU-Protokoll KANN in einer Nichtproduktivumgebung die Umsetzung von A_21888-* durch einen Nutzer (FdV) oder Administrator (Konnektor etc.) konfigurierbar machen, d. h. das Verhalten des Clients zwischen zufälliger Schlüsselerzeugung und festen Schlüssel aus A_21888-* per Konfiguration veränderlich machen. [<=]

A_21889 - VAU-Server, Produktivumgebung, Ablehnung der ECDH-Client-Schlüssel nach A_21888-*

Ein Server im VAU-Protokoll MUSS genau in der Produktivumgebung (PU) bei einem VAU-Handshake den Client-ECDH-Schlüssel aus A_21888-* ablehnen. D. h. er muss falls ein Client im VAUClientHello den öffentlichen Schlüssel aus A_21888-* präsentiert, den Handshake mit einem VAUServerError gemäß A_16851-* abbrechen. [<=]

6.14 Optionale PQC-Erweiterung (informativ)

In diesem Abschnitt wird eine optionale Protokollerweiterung des VAU-Protokolls für ePA dargestellt, die sich aktuell in der gematik in der Evaluierung befindet. Kryptographisch gesehen entspricht sie dem PQC-Vorgehen bei TLS aus [TLS-CC-2021]. Mehr Information über PQC findet man in Abschnitt "".

Ein Client initiiert mit einer VAUClientHello-Nachricht den VAU-Protokoll-Handshake (Schlüsselvereinbarung). Möchte er zusätzlich zum klassischen ephemeren ECDH-Schlüsselaustausch ein PQC-Verfahren anwenden und die beiden gemeinsam mit dem VAU-Server dabei erzeugten Geheimnisse in die Schlüsselableitung für die symmetrischen Sitzungsschlüssel einfließen lassen, so führt er im Handshake einen Verfahrensidentifikator inkl. dazugehörigen öffentlichen Schlüssel eines der unten aufgeführten PQC-Verfahren mit an.

In [liboqs] sind die Referenzimplementierungen der Round-3-Kandidaten der NIST-PQC-Standardisierung [NIST-PQC] enthalten. Ebenfalls sind dort folgende Identifier definiert, die den Definitionen aus den Round-3-Kandidaten entsprechen:

Key encapsulation mechanisms (KEM):

1.                        BIKE: BIKE-L1, BIKE-L3

2.                        Classic McEliece: Classic-McEliece-348864, Classic-McEliece-348864f, Classic-McEliece-460896, Classic-McEliece-460896f, Classic-McEliece-6688128, Classic-McEliece-6688128f, Classic-McEliece-6960119, Classic-McEliece-6960119f, Classic-McEliece-8192128, Classic-McEliece-8192128f

3.                        FrodoKEM: FrodoKEM-640-AES, FrodoKEM-640-SHAKE, FrodoKEM-976-AES, FrodoKEM-976-SHAKE, FrodoKEM-1344-AES, FrodoKEM-1344-SHAKE

4.                        HQC: HQC-128, HQC-192, HQC-256

5.                        Kyber: Kyber512, Kyber512-90s, Kyber768, Kyber768-90s, Kyber1024, Kyber1024-90s

6.                        NTRU: NTRU-HPS-2048-509, NTRU-HPS-2048-677, NTRU-HPS-4096-821, NTRU-HPS-4096-1229, NTRU-HRSS-701, NTRU-HRSS-1373

7.                        NTRU-Prime: ntrulpr653, ntrulpr761, ntrulpr857, ntrulpr1277, sntrup653, sntrup761, sntrup857, sntrup1277

8.                        SABER: LightSaber-KEM, Saber-KEM, FireSaber-KEM 

Im VAUClientHelloData führt der Client zusätzlich auf:

"PQC.PublicKey" : [ "...Verfahrensidentifikator...", "...base64-kodierter-Public-Key-des-PQC-KEM-Verfahrens..."]

"Verfahrensidentifikator" steht für einen der o. g. KEM-Identifier. In [liboqs] ist jeweils für jedes Verfahren eine "KeyGen"-Funktion definiert. Diese erzeugt zufällig ein Schlüsselpaar und gibt als Ergebnis u. a. den öffentlichen Schlüssel aus. Dieser wird so wie er aus der Referenzimplementierung kommt, per base64-Kodierung kodiert im Feld "base64-kodierter-Public-Key-des-PQC-KEM-Verfahrens" eingetragen.

Der Server akzeptiert optionale Attribute in den JSON-Nachrichten des VAU-Handshakes auf Grund von A_17074-*. Wenn er das Verfahren ebenfalls unterstützt, dann fügt er den öffentlichen Teil des Ergbnisses der Encaps(öffentlicher Schlüssel des Clients)-Funktion im VAUServerHelloData wie folgt base64-kodiert auf:

"PQC.Encaps" : "... base64-kodierter-öffentlicher-Teil-von-Encaps(öffentlicher Schlüssel des Clients) ..."

Beim Aufruf von Encaps(öffentlicher Schlüssel des Clients) wird als Ergebnis der Funktion ein öffentlicher Teil und ein geheimer Schlüssel K als Ergebnis berechnet. Der VAU-Server fügt bei der Schlüsselableitung der symmetrischen Sitzungsschlüssel (vgl. A_16943-*) neben dem gemeinsamen ECDH-Geheimnisse noch "Verfahrensidentifikator" || K als Eingabe für die HKDF hinzu (IKM= gemeinsames ECDH-Geheimnis || Verfahrensidentifikator || K). Damit hängen die abgeleiteten Sitzungsschlüssel sowohl vom ECDH-Geheimnis als auch vom geheimen Schlüssel K, also vom PQC-KEM, ab.

Bei Erhalt der VAUServerHello-Nachricht im VAU-Client, führt der VAU-Client die Funktion Decaps(s, decodierter öffentlicher Encaps-Wert) aus, wobei s der private Client-PQC-Schlüssel aus der Schlüsselpaarerzeugung für PublicKeyPQC ist (vgl. KeyGen-Funktion). Als Ergebnis erhält er K. Damit kann er genau wie der VAU-Server die Schlüsselableitung der symmetrischen Sitzungsschlüssel (vgl. A_16943-*) durchführen (IKM= gemeinsames ECDH-Geheimnis || Verfahren-ID || K). 

Sollte der Client bei Erhalt der VAUServerHello-Nachricht kein "Encaps"-Datenfeld im VAUServerHelloData-Teil vorfinden, so unterstützt der VAU-Server das Verfahren nicht. Dem VAU-Client steht es dann frei, den Verbindungsaufbau ohne PQC-Verfahren weiter durchzuführen, den Verbindungsaufbau abzubrechen oder den Verbindungsaufbau neu zu beginnen.

Wenn die Schlüsselableitung bei beiden Kommunikationspartnern erfolgreich durchgeführt werden konnte -- d. h., der VAU-Protokoll-Handshake konnte erfolgreich abgeschlossen werden, dann verläuft der Protokollablauf wie in Abschnitt ff definiert wie üblich weiter.

7 Kommunikationsprotokoll zwischen E-Rezept-VAU und E-Rezept-Clients

7VAU-Protokoll für E-Rezept

6.1 Übersicht (informativ)

Ähnlich wie bei der Anwendung ePA besitzt der Fachdienst E-Rezept mindestens zwei HTTPHTTPS-Schnittstellen. Die dabei vom Nutzer (Client) aufgebaute TLS-Verbindung endet an einer dieser HTTPS-Schnittstellen. Die E-Rezept-VAU liegt hinter den Webschnittstellen. Um die Verbindungsstrecke zwischen HTTPS-Schnittstellen und E-Rezept-VAU zu schützen, verschlüsselt und kodiert der Client seine HTTP-Requests (als innere Requests bezeichnet) auf die im Abschnitt 6.2 Definition definierte Weise. Diese so erzeugten HTTP-Requests (äußere Requests) sendet der Client per HTTPS an eine der Webschnittstellen des E-Rezept-Dienstes. Dabei ist für die Schnittstelle ein regelmäßig wechselndes Nutzerpseudonym im äußeren HTTP-Request sichtbar. Dieses unterstützt den Fachdienst E-Rezept bei der Lastverteilung und beim DoS-Schutz auf Applikationsebene. Von der Webschnittstelle erhält die E-Rezept-VAU die verschlüsselten Requests, entschlüsselt und verarbeitet diese. Als Antwort erzeugt die E-Rezept-VAU einen für den Client verschlüsselte HTTP-Response. Den Schlüssel dafür hat der Client für die VAU ephemer erzeugt und dieser Schlüssel ist Teil des verschlüsselten Requests. Die Webschnittstelle empfängt das Chiffrat von der VAU und gibt dieses als Antwort auf den HTTP-Request an den Client zurück.

Ablauf:

• Der Client erfragt initial das X.509-Zertifikat der VAU (A_20160-*). Je nachdem, ob die X.509-Root der TI oder die TSL als Prüfbasis verwendet wird, erfolgt die Abfrage des VAU-X.509-Zertifikats spezifisch (entweder A_21216 oder A_21218). Im Zertifikat ist der öffentliche Verschlüsselungsschlüssel der E-Rezept-VAU enthalten. Dieses Zertifikat kommt aus der Komponenten-PKI der TI und ist langlebig, d. h. der Client kann dieses Zertifikat (inkl. Schlüssel) für folgende Verschlüsselungen lokal vorhalten.
• Der Client erzeugt einen HTTP-Request mit Request-Body und Request-Header als Datenstrukturen (= innerer HTTP-Request) (A_20161-*).
• Der Client verschlüsselt diesen Request mit dem Verschlüsselungsschlüssel der E-Rezept-VAU. Im Chiffrat ist ein Authentisierungstoken des Nutzers enthalten, eine zufällig gewählte Request-ID, ein vom Client ephemer erzeugter symmetrischer Antwortschlüssel und der am Anfang erzeugte HTTP-Request als Datenstrom (A_20161-*).
• Der Client erzeugt einen neuen (äußeren) HTTP-Request und überträgt darin das Chiffrat an eine HTTPS-Schnittstelle des Fachdienstes E-Rezept. Dabei gibt der Client ggf. das schon aus einer vorherigen Response des Fachdienstes E-Rezept mitgeteilte Nutzerpseudonym (A_20161-*) mit.
• Die Webschnittstelle nimmt den Request entgegen und trifft eine Routing-Entscheidung oder eine Priorisierungsentscheidung im Lastfall. Anschließend leitet sie den Request an die VAU weiter (A_20162).
• Die VAU entschlüsselt den Request und verarbeitet ihn. Die Antwort wird inkl. der Request-ID mit dem vom Nutzer erzeugten Antwortschlüssel verschlüsselt und an die Webschnittstelle gesendet.
• Die Webschnittstelle antwortet gegenüber dem Client mit diesem Chiffrat auf den HTTP-Request.
• Der Client entschlüsselt das Chiffrat und prüft die Request-ID in der entschlüsselten Antwort.

Das Protokoll ist statuslos. Zwischen verschiedenen VAU-Instanzen (bspw. VAU-Instanzen in unterschiedlichen Brandabschnitten eines Rechenzentrum) müssen keine Session-Schlüssel oder ähnliches synchronisiert werden.

Die Struktur der inneren HTTP-Request ist so einfach, dass davon auszugehen ist, dass in der VAU-Instanz keine umfangreichen Webserver oder HTTP-Bibliotheken notwendig sind. Ziel der E-Rezept-VAU ist es die Code-Komplexität (Trusted Computing Base, TCB) so weit es nur irgendwie geht minimal zu halten.

Abbildung 43: Sicherungsschichten beim Datentransport zwischen E-Rezept-Client und E-Rezept-VAU

Die gematik stellt eine Beispielimplementierung bereit.

76.2 Definition

76.2.1 E-Rezept-VAU-Identität

A_20160-01 - E-Rezept-VAU, Schlüsselpaar und Zertifikat

Der Fachdienst E-Rezept MUSS folgende Punkte sicherstellen.

• Die VAU MUSS ein EE-X.509-Zertifikat aus der Komponenten-PKI der TI besitzen
  (mit Rollenkennung-OID "oid_erp-vau"), das einen ECC-EE-Schlüssel der VAU bestätigt. 
• Die VAU MUSS die Vertraulichkeit des privaten Schlüssels für diese Zertifikat sicherstellen.
• Die notwendige Sicherung (Backup) und Verteilung dieses privaten Schlüssels MUSS ausschließlich im Mehr-Augen-Prinzip und mit geeigneten Maßnahmen zur Wahrung der Vertraulichkeit des Schlüssels geschehen.
• Der Fachdienst E-Rezept MUSS das VAU-Zertifikat in seinen Webschnittstellen unter dem Pfad /VAUCertificate (einer URL) durch Clients abrufbar machen. Dieses Zertifikat MUSS DER-kodiert sein.
• Der Fachdienst E-Rezept MUSS eine maximal 12 Stunden alte OCSP-Response für das VAU-Zertifikat in seinen Webschnittstellen unter dem Pfad /VAUCertificateOCSPResponse für Clients abrufbar machen.

[<=]

Hinweis: Unter "/VAUCertificateOCSPResponse" erhält ein Client (einfacher GET-Request) eine korrekte OCSP-Response für das VAU-Zertifikat (A_20160-*, Punkt 1). Dies ist analog wie OCSP-Stapling bei TLS zu sehen, nur auf einer höheren OSI-Schicht. Der FD stellt korrekte OCSP-Responses zur Verfügung damit nicht jeder Client selbst den OCSP-Responder fragen muss. Diese Funktionalität hat nichts mit der OCSP-Proxy-Funktionalität zu tun wie sie bspw. beim Zugangsgateway des Versicherten bei ePA angeboten wird. Der FD fragt bspw. stündlich selbst den OCSP-Status für sein VAU-Zertifikat ab, prüft die Antwort und stellt sie unter "/VAUCertificateOCSPResponse" Clients zur Verfügung.

A_20967 - E-Rezept-VAU, Erstellung und Pflege der Schlüssel im Mehr-Augen-Prinzip

Der Fachdienst E-Rezept MUSS folgende Punkte sicherstellen.

1. Die Erstellung, Sicherung und Wiederherstellung von nicht-flüchtigen (nicht kurzzeitig gültigen) Schlüsseln (A_20160-* Punkt 2-3, Masterkey für die Verschlüsselung der E-Rezept in der VAU etc.) MUSS im Mehr-Augen-Prinzip erfolgen bei dem mindestens ein gematik-Mitarbeiter beteiligt ist.
2. Die Administration des/der HSM der VAU MUSS ebenfalls im Mehr-Augen-Prinzip erfolgen bei dem mindestens ein gematik-Mitarbeiter beteiligt ist.

Die oben genannten Punkten MÜSSEN durch das/die HSM der VAU technisch durchgesetzt werden (Rechtekonzept). [<=]

Hinweis: A_20967 beschreibt ein analoges Vorgehen wie es bei den SGD(1,2) üblich ist. Der Betreiber des FD besitzt für bestimmte Rollenauthentisierungen für die HSM Authentisierungschipkarten inkl. PIN, die gematik ebenfalls. Nur bei gleichzeitiger Authentisierung beider Beteiligter erlauben die HSM bestimmte Aktionen/Funktionalitäten.

76.2.2 Client-seitige Prüfung der E-Rezept-VAU-Identität

Bevor ein E-Rezept-Client die E-Rezept-VAU-Identität für die Verschlüsselung seiner Request (vgl. 6.2.3 E-Rezept-VAU-Request und -Response ) verwendet, muss der Client deren X.509-Zertifikat prüfen ([gemSpec_eRp_FdV#A_19739], [gemILF_PS_eRP#A_20769]).

Ein E-Rezept-Client auf einen Praxisverwaltungssystem (PVS) oder einen Apothekenverwaltungssystem (AVS) muss die TSL als Prüfbasis für solch eine Prüfung verwenden [gemILF_PS_eRP#A_20764].
Da ein E-Rezept-FdV nur zwei TI-Zertifikate prüfen muss, wird im FdV die technisch deutlich einfachere Zertifikatsprüfung auf Basis der TI-X.509-Root verwendet [gemSpec_eRp_FdV#A_20032-*], und nicht die Prüfung über die TSL wie im Client eines PVS oder AVS [gemILF_PS_eRP#A_20764]. Beide Prüfwege sind sicherheitstechnisch äquivalent.

A_21216 - E-Rezept-Client, Zertifikatsprüfung auf TSL-Basis

Ein E-Rezept-Client, der nicht das E-Rezept-FdV ist, MUSS das VAU-Zertifikat vom E-Rezept-FD beziehen (vgl. A_20160-*, URL /VAUCertificate) und ebenfalls für dieses Zertifikat die OCSP-ReponseResponse für dieses Zertifikat beziehen (vgl. A_20160-*, URL /VAUCertificateOCSPResponse). Er MUSS das Zertifikat mittels TUC_PKI_018 (OCSP-Graceperiod=12h, PolicyList={oid_erp-vau}) prüfen und dabei die vom FD bezogene OCSP-Response verwenden. [<=]

Der E-Rezept-FD muss für die Zertifikatsprüfung im E-Rezept-FdV eine (außer für die Verfügbarkeit) sicherheitsunkritische Unterstützungsleistung erbringen und dafür folgend benannte Zertifikate zum Download anbieten. 
Zunächst erfolgen mit Tab_KRYPT_ERP_Zertifikatsliste und Tab_KRYPT_ERP_Algorithmus_FD_Zertifikatsliste_erstellen zwei Hilfsdefinitionen.

Tabelle 17: Tab_KRYPT_ERP_Zertifikatsliste Definition Datenstruktur Zertifikatsliste

Tabelle 18: Tab_KRYPT_ERP_Algorithmus_FD_Zertifikatsliste_erstellen

Hinweis: zum produktiven Start des E-Rezept-FD enthält das Array "ee_certs" drei Elemente (Zertifikat des VAU-Protokolls, Signaturzertifikat des Discovery-Dokumentes, Signaturzertifikat des ID_Token), das Array "ca_certs" ein Element und das Array "add_roots" null Elemente.

A_21217 - E-Rezept-FD, Zertifikatslisten und OCSP-Response für Clients

Ein E-Rezept-FD MUSS

• nachdem die E-Rezept-VAU-Identität (vgl. A_20160-*) erzeugt wurde mittels des Algorithmus aus Tab_KRYPT_ERP_FD_Zertifikatsliste_erstellen die Datenstruktur analog zu Tab_KRYPT_ERP_Zertifikatsliste erstellen.
• diese erzeugte Zertifikatsliste auf seiner Webschnittstelle (HTTPS) über die URL /CertList (GET-Methode, Reponse-Content-Type 'application/json') verfügbar machen.
• die Zertifikatsliste mittels des Algorithmus aus Tab_KRYPT_ERP_FD_Zertifikatsliste_erstellen aktualisieren wenn (1) die E-Rezept-VAU-Identität aktualisiert wurde (Schlüsselwechsel der VAU etc.) oder (2) die gematik neue IDP-Zertifikate über die Liste E-Rezept-Clients bekannt machen möchte. Im Fall (2) meldet die gematik dies an den FD.
• an seiner Webschnittstelle (HTTPS) über die URL /OCSPList (GET-Methode, Reponse-Content-Type 'application/json') ein Array mit den base64-kodierten OCSP-Responses für die alle Zertifikate aus dem Array "ee_certs". Diese OCSP-Response-Liste muss der FD mindestens alle 11 Stunden mit "frischen" OCSP-Responses für die Zertifikate aus dem Array "ee_certs" aktualisieren.

[<=]

Tabelle 19: Tab_KRYPT_ERP_FdV_Truststore_aktualisieren

Tabelle 20: Tab_KRYPT_ERP_OCSP_Liste Definition Datenstruktur OCSPList

A_21218 - E-Rezept-Client, Zertifikatsprüfung auf Basis der X.509-Root

Das E-Rezept-FdV MUSS die RCA3 (das Zertifikat der Version 3 der X.509-Root der TI) als Vertrauensanker im Programm-Code bzw. mit dem Programm-Code fest assoziiert enthalten und als Basis für die Prüfung von TI-Zertifikat verwenden.
Das FdV MUSS einen TI-Zertifikate-Truststore enthalten und pflegen, wie folgend definiert.

Der Truststore MUSS Prüfschlüssel/Zertifikat aufgeteilt in folgende vier Kategorien enthalten: (A) Root-Schlüssel, (B) CA-Zertifikate, (C) E-Rezept-VAU-Zertifikat, (D) IDP-Zertifikat(e). Initial kann dieser Truststore nur RCA3 enthalten oder die Zertifikate die mittels Tab_KRYPT_ERP_FD_Zertifikatsliste_erstellen ermittelt werden.
Falls im Truststore keine Zertifikate für Kategorie (C) und (D) vorliegen, so MUSS das FdV den Truststore aktualisieren indem es über den FD (URL /CertList) die Zertifikatsliste lädt und diese mittels des Algorithmus Tab_KRYPT_ERP_FdV_Truststore_aktualisieren prüft und ggf. in den Truststore lädt.
Das E-Rezept-FdV MUSS über den FD (URL /OCSPList) OCSP-Responses für die Zertifikate (C) und (D) beziehen, wenn aktuell keine OCSP-Responses für diese Zertifikate im FdV vorliegen, die jünger als 12 Stunden sind.
Falls in der OCSP-Liste OCSP-Responses enthalten sind die zu keinem der Zertifikate (C) und (D) passen, so MUSS das FdV den Truststore aktualisieren (s. o.).
Zertifikate aus (C) und (D) MÜSSEN OCSP-Responses, die jünger als 12 Stunden sind besitzen, damit diese Zertifikate in fachliche Use-Cases im FdV verwendet werden können.

Die OCSP-Responder-Zertifikate MÜSSEN per Signaturprüfung auf ein Zertifikat der Kategorie (B) rückführbar sein, ansonsten MÜSSEN die entsprechenden OCSP-Responses verworfen werden.

Das FdV MUSS bei der Prüfung der TI-Zertifikate in fachlichen Use-Cases im FdV, prüfen ob das Zertifikat im oben beschriebenen Truststore enthalten ist und eine gültige OCSP-Response enthält die jünger als 12 Stunden ist. Falls dies nicht so ist, so ist das Ergebnis der Prüfung des TI-Zertifikats FAIL.
[<=]

A_21222 - E-Rezept-Client, allgemein Zertifikatsprüfung

Ein E-Rezept-Client MUSS bevor er TI-X.509-Zertifikate in fachlichen Abläufen (bspw. VAU-Kanal) verwendet, diese Zertifikate prüfen (vgl. A_21216 und A_21218). [<=]

76.2.3 E-Rezept-VAU-Request und -Response

A_20161-01 - E-Rezept-Client, Request-Erstellung

Ein E-Rezept-Client MUSS, falls ihm noch kein gültiges E-Rezept-VAU-Zertifikat vorliegt, ein solches nach den fachlichen Vorgaben von A_20160-* beziehen (/VAUCertificate).
Ein E-Rezept-Client MUSS sicherstellen, dass gültige Sperrinformation (OCSP-Response mit Sperrstatus "good") für das Zertifikat vorliegen, die maximal 12 Stunden alt sind. Liegen diese nicht vor so MUSS der Client ein Verbindungsaufbau auf VAU-Protokoll-Ebene ablehnen/unterbinden.

Ein E-Rezept-Client MUSS bei der Request-Erstellung folgende Schritte durchführen.

• Er erzeugt einen HTTP-Request, den er an die VAU senden möchte, als Datenstruktur (vgl. Beispiele nach dieser Anforderung).
• Er erzeugt zufällig eine 128-Bit lange hexadezimalkodierte Request-ID (also 32 Zeichen, Buchstaben a-f kleingeschrieben).
• Er erzeugt zufällig einen 128-Bit AES-Schlüssel (im Weiteren auch Antwortschlüssel genannt), den er hexadezimal kodiert (also 32 Zeichen, Buchstaben a-f kleingeschrieben).
• Er MUSS die Request-ID und den AES-Schlüssel für jeden HTTP-Request an die VAU zufällig neu erzeugen.
• Er erzeugt die folgende Zeichenkette p mit
  p="1" + " " + JWT-Authentisierungstoken + " " + Request-ID + " " + AES-Schlüssel + " " + Datenstruktur aus Schritt 1.
• Die Zeichenkette p MUSS mittels des ECIES-Verfahrens [SEC1-2009] und mit folgenden Vorgaben verschlüsselt werden:
  • Er MUSS ein ephemeres ECDH-Schlüsselpaar erzeugen und mit diesem und dem VAU-Schlüssel aus A_20160-* ein ECDH gemäß [NIST-800-56-A] durchgeführen. Das somit erzeugte gemeinsame Geheimnis ist Grundlage für die folgende Schlüsselableitung.
  • Als Schlüsselableitungsfunktion MUSS er die HKDF nach [RFC-5869] auf Basis von SHA-256 verwenden.
  • Dabei MUSS er den Ableitungsvektor "ecies-vau-transport" verwenden, d. h. in der Fomulierung von [RFC-5869] info="ecies-vau-transport" .
  • Er MUSS mit dieser Schlüsselableitung einen AES-128-Bit Content-Encryption-Key für die Verwendung von AES/GCM ableiten.
  • Er MUSS für Verschlüsselung mittels AES/GCM einen 96 Bit langen IV zufällig erzeugen.
  • Er MUSS mit dem CEK und dem IV mittels AES/GCM p verschlüsseln, wobei dabei ein 128 Bit langer Authentication-Tag zu verwenden ist.
  • Er MUSS das Ergebnis wie folgt kodieren: chr(0x01) || <32 Byte X-Koordinate von öffentlichen Schlüssel aus (a) > || <32 Byte Y-Koordinate> || <12 Byte IV> || <AES-GCM-Chiffrat> || <16 Byte AuthenticationTag> (vgl. auch Tab_KRYPT_ERP und folgende die Beispielverschlüsselung).
    Die Koordinaten sind (wie üblich) vorne mit chr(0) zu padden solange bis sie eine Kodierungslänge von 32 Byte erreichen.

1. Er erzeugt einen HTTPS-Request an den FD mit der POST-Methode und dem Pfad /VAU/<Nutzerpseudonym>[/optional-beliebiger-weiterer-URL-Pfadteil] mit dem Content-Type 'application/octet-stream' und sendet diesen an die Webschnittstelle des FD.
   "Nutzerpseudonym" MUSS eine ggf. aus der vorherigen (zeitlich letzten) Antwort des FD dem Nutzer übergebene URL-sichere Zeichenkette sein (bspw. ein 128 Byte langer Hexadezimal-Kode).
   Falls dem Client kein Nutzerpseudonym vorliegt so MUSS er "0" als Nutzerpseudonym verwenden.

[<=]

Tabelle 21: Tab_KRYPT_ERP Kodierung des Chiffrats aus A_20161-*

Hinweise zu A_20161-*:

1. Beispiel für eine hexadezimalkodierte Request-ID nach A_20161-* (2): "32b6594cc29bb54a14cb2a8e09558817"
2. Beispiel für einen 128-Bit-AES-Schlüssel nach A_20161-* (3): "a576daad8096fc52987250a8e7eb9bd3"
3. Aus kryptographischer Sicht könnte ein Client den Antwort-AES-Schlüssel (A_20161-* Punkt (3)) auch für weitere Requests verwenden. Dies würde jedoch erzwingen, dass es im Client eine komplexere Überwachung des Lebenslaufs des Schlüssels gibt (Wann wurde er erzeugt,  d. h. wann muss er gewechselt werden etc.). Um dies zu verhindern und die Implementierung im Client einfacher zu halten, gibt es A_20161-* Punkt (4).

Beispielverschlüsselung (Testvektor):

Der Langzeit-VAU-Schlüssel nach A_20160-* sei folgender:
x=0x8634212830dad457ca05305e6687134166b9c21a65ffebf555f4e75dfb048888 
y=0x66e4b6843624cbda43c97ea89968bc41fd53576f82c03efa7d601b9facac2b29

Die zu Verschlüsselnde Nachricht sei "Hallo Test" (10 Zeichen).

Der Client erzeugt zufällig den privaten ECC-Schlüssel d=5bbba34d47502bd588ed680dfa2309ca375eb7a35ddbbd67cc7f8b6b687a1c1d

Damit ist dessen öffentlicher ephemerer ECDH-Schlüssel:
x=0x754e548941e5cd073fed6d734578a484be9f0bbfa1b6fa3168ed7ffb22878f0f 
y=0x9aef9bbd932a020d8828367bd080a3e72b36c41ee40c87253f9b1b0beb8371bf 

Nach ECDH ergibt sich damit folgendes gemeinsames Geheimnis:
9656c2b4b3da81d0385f6a1ee60e93b91828fd90231c923d53ce7bbbcd58ceaa

Nach Schlüsselableitung (info="ecies-vau-transport") erhält der Client folgende CEK:
23977ba552a21363916af9b5147c83d4

Der Client erzeugt zufällig einen 12 Byte großen IV:
257db4604af8ae0dfced37ce

Die AES/GCM-Chiffre berechnet aus der Nachricht, dem CEK und dem IV folgendes Chiffrat:

86c2b491c7a8309e750b und folgenden 16 Byte großen Authentication Tag 4e6e307219863938c204dfe85502ee0a

Das Gesamt-Chiffrat vollständig kodiert ist damit (ohne Leerzeichen, als Hexdump)

01 754e548941e5cd073fed6d734578a484be9f0bbfa1b6fa3168ed7ffb22878f0f 9aef9bbd932a020d8828367bd080a3e72b36c41ee40c87253f9b1b0beb8371bf 257db4604af8ae0dfced37ce 86c2b491c7a8309e750b 4e6e307219863938c204dfe85502ee0a

In der Webschnittstelle muss ein CMAC-Schlüssel für die Bildung der Nutzerpseudonyme vorliegen (A_20162-*). Dieser Schlüssel wird regelmäßig gewechselt (A_20162-*) und er kann in der Webschnittstelle als normales Datenobjekt (also nicht innerhalb des HSMs) vorliegen (Schutzbedarf bezüglich Vertraulichkeit: mittel).

A_20162 - E-Rezept-FD, Webschnittstellen, VAU-Requests

Der Fachdienst E-Rezept MUSS an seinen Webschnittstellen folgendes sicherstellen:

1. Er MUSS unter dem Pfad /VAU/<Nutzerpseudonym>[/optional-beliebiger-weiterer-URL-Pfadteil] (der URL) mit dem Content-Type 'application/octet-stream' HTTPS-Requests entgegennehmen (nach dem Nutzerpseudonym kann u. Um. ein "/" und anschließend weitere Pfadangaben vom Client angegeben werden, vgl. Beispiele unten).
2. Er MUSS in der Webschnittstelle über einen AES-CMAC 128 Bit Schlüssel verfügen, der mindestens alle 10 Tage zufällig neu erzeugt wird. Dieser Schlüssel MUSS als reiner Software-Schlüssel (nicht in einem HSM) in der Webschnittstelle vorliegen.
3. Er MUSS das Nutzerpseudonym (NP) auf Integrität (CMAC) prüfen (vgl. Schritt 8). Ist die Integrität nicht gegeben, so MUSS er anstatt des übergebenen NP "0" als Wert verwenden.
4. Er MUSS anhand des NP eine Lastverteilung innerhalb des FD und eine NP-zentrierte Lastbeschränkung durchführen.
   Im Lastszenario MÜSSEN Requests mit NP "0" mindestens 10 mal geringer priorisiert werden, als Requests mit gültigem NP.
5. Er muss den Request zur Abarbeitung an einen geeigneten Verarbeitungskontext der VAU übergeben.
6. Die VAU-Instanz muss eine verschlüsselte Antwort (vgl.  A_20163) erzeugen und an die Schnittstelle senden.
7. In der Antwort der VAU-Instanz MUSS die VAU das Prenutzerpseudonym (PNP, vgl.  A_20163) als Teil der Antwort der VAU auf den Nutzer-Request an die Webschnittstelle übergeben.
8. Er MUSS mittels des CMAC-Schlüssels (vgl.  Schritt 2) den 128-Bit-lange CMAC-Wert des PNP erzeugen und diesen hexadezimal kodieren (= CMAC). Die Zeichenkette "<PNP>" + "-" + "<CMAC>" sei das NP.
9. Als Antwort MUSS  die Schnittstelle eine HTTP-Response senden mit dem Content-Type 'application/octet-stream', der Antwort der VAU-Instanz als Bytestrom (Octet-Stream) und im HTTP-Response-Header MUSS 'Userpseudonym: <NP>" enthalten sein.

[<=]

Beispiele für mögliche Pfade die nach A_20162 von einem Client erzeugt werden könnten:

/VAU/0
/VAU/0/Task/create
/VAU/270810c79748768a9b0aefbf52c8d72be7ad5e0d2d328d9bb70dbf58623fc7ae

A_20163 - E-Rezept-VAU, Nutzeranfrage, Ent- und Verschlüsselung

Die E-Rezept-VAU MUSS das Folgende sicherstellen und im Falle eines Fehlschlagens die Abarbeitung des Requests mit einer entsprechenden Fehlermeldung an die sie aufrufende Webschnittstelle abbrechen.

1. Die E-Rezept-VAU MUSS einen verschlüsselten Nutzer-Request von der Webschnittstelle entgegennehmen.
2. Die E-Rezept-VAU MUSS einen verschlüsselten Nutzer-Request nach den kryptographischen Vorgaben aus A_20161-* und mit dem privaten Schlüssel aus A_20160-* versuchen zu entschlüsseln.
3. Die E-Rezept-VAU MUSS den erhaltenden Klartext p auf den Strukturaufbau aus A_20160-* prüfen.
4. Die E-Rezept-VAU MUSS das JWT-Authentisierungstoken auf Gültigkeit prüfen.
5. Die E-Rezept-VAU MUSS den in p kodieren HTTP-Request abarbeiten.
6. Die E-Rezept-VAU MUSS einen 128-Bit-AES-CMAC-Schlüssel zufällig erzeugen und mindestens alle 10 Tage wechseln.
7. Die E-Rezept-VAU MUSS aus dem "sub"-Feld-Wert mittels des CMAC-Schlüssels den 128 Bit langen CMAC-Wert berechnen und hexadezimal kodieren (32 Byte lang). Dies sei das Prenutzerpseudonym (PNP).
8. Die Antwort "a" auf den HTTP-Request aus p MUSS wie folgt kodiert werden:
   a="1"  + " " + Request-ID-aus-p + " " + Response-Header-und-Body.
9. Die E-Rezept-VAU MUSS a mittels des 128-Bit langen AES-Schlüssels aus p und AES/GCM (96 Bit zufällig erzeugter IV, 128 Authentication Tag) verschlüsseln und erhält c'.
10. Die E-Rezept-VAU MUSS c' und das PNP an die Webschnittstelle als Antwort übergeben.

[<=]

A_20174 - E-Rezept-Client, Response-Auswertung

Ein E-Rezept-Client MUSS bei der Response-Auswertung (vgl. vorgehenden Client-Request aus A_20161-*) folgende Schritte durchführen. Dabei MUSS der Client bei Fehlschlagens im Folgenden aufgeführten Prüfungen die Analyse der Response abbrechen, und er MUSS die Request-ID und den AES-Antwortschlüssel sicher löschen.

1. Er MUSS prüfen, ob der Content-Type der Response 'application/octet-stream' ist.
2. Wenn im Response-Header die Variable "Userpseudonym" vorhanden ist, so MUSS er den Wert von "Userpseudonym" als NP für den nächsten Request an die VAU verwenden. (Der Client MUSS einen ggf. vorhandenen alten Wert des NP im Client überschrieben.)
3. Er MUSS das Antwort-Chiffrat mit den Vorgaben aus A_20163 (9) und dem AES-Antwort entschlüsseln und prüfen ob die Entschlüsselung erfolgreich möglich war.
4. Er MUSS prüfen, ob die Struktur des erhaltenen Klartextes p der Struktur aus A_20163 (8) entspricht.
5. Er MUSS  prüfen, ob die Request-ID in p der Request-ID aus dem Client-Request entspricht (Gleichheit prüfen).
6. Er MUSS das dritte Feld-Element in p ("Response-Header-und-Body") als HTTP-Antwort der E-Rezept-VAU in fachlich weiter verarbeiten.

[<=]

A_20175 - E-Rezept-Client, Speicherung Nutzerpseudonym

Ein E-Rezept-Client MUSS das im Request verwendete Nutzerpseudonym (NP) in Software speichern (kein HSM/TPM/SE) und das NP ausschließlich für seinen Einsatzzweck der E-Rezept-VAU-Kommunikation verwenden. Insbesondere MUSS der Client die Vertraulichkeit des NP wahren (bspw. nicht unnötig in Protokolleinträgen und Fehlermeldungen aufführen). [<=]

Der Fachdienst E-Rezept besitzt eine REST-Schnittstelle, d. h. Fehler werden mittels HTTP-Status/Fehler-Codes signalisiert. Die in der folgenden Tabelle (Tab_KRYPT_VAUERR) aufgeführten Fehler kann ein E-Rezept-Client in Bezug auf die in diesem Abschnitt definierte kryptographische Sicherung zwischen Client und VAU treffen.

Tabelle 22: Tab_KRYPT_VAUERR Auftretende Fehler bei auf Anwendungsschicht kryptographisch gesicherten VAU-Kommunikation (E-Rezept)

76.2.4 Zufallsquelle für Clients

Zur Auffrischung des Entropie-Pools des Clients kann der Client von verschiedenen Diensten der TI Zufall ausreichender Güte (vgl. GS-A_4367) beziehen. Der FD-E-Rezept ist dafür eine Quelle von mehreren. Ein Client muss verschiedene unabhängige Quellen abfragen und die Zufallsdaten kryptographisch geeignet (bspw. über den Fortuna-PRNG-Algorithmus) zusammenführen.

A_21215 - E-Rezept-FD, Random-Operation

Der Fachdienst E-Rezept MUSS an seiner Webschnittstelle (HTTPS) unter der URL /Random (GET-Methode) 128 Byte Zufallsdaten hexadezimalkodiert (Lower-Case -- [0-9a-f]) einen Client zur Verfügung stellen. Bei jedem Request MÜSSEN die Zufallsdaten neu erzeugt werden. Die Response MUSS den Content-Type application/json besitzen.
Teil einer Beispiel-Response:

Content-length: 258 
Content-type: application/json 
Date: Tue,01 Dec 2020 12:46:18 GMT 
Server: nginx/1.14.0 (Ubuntu)

"a5dc9d13ee2e76ddd9b75e9c28421fc4b5a9a131751a3dad1203f8d1b149366ef938163d43718f31fe5464e05f236ba62588cea48ff8cdb9f77abe52a03a389f8a2573127c7062974238714e457399cfc9fcd7eeb656c2cfd3bf50fb1d74b4cd5c73607283533f423760c2e38a3fd646602ef244d4dbdb332c8f696b5e07ef51"
[<=]

Um die Anforderung umzusetzen ist es im Normalfall ausreichend /dev/urandom als Zufallsquelle auf einen Linux-Server zu verwenden.

7 VAU-Protokoll für ePA für alle

Der grundsätzliche architektonische Aufbau des ePA-Aktensystems als Fachdienst bei ePA für alle entspricht dem bei ePA 1.x, 2.x und beim E-Rezept: Das Aktensystem besteht aus mehreren Webschnittstellen, bei denen über das HTTPS-Protokoll Requests eintreffen. Diese Requests werden im Aktensystem an verschiedene VAU-Instanzen zur Verarbeitung weitergeleitet. Die Antwort von einer VAU-Instanz erzeugt und an die Webschnittstelle übergeben. Von dieser wird sie per HTTPS an die Clients innerhalb einer HTTP-Response übermittelt. Zwischen ePA-Client und VAU gibt es also keine durchgehende TLS-Verbindung -- eine TLS-Verbindung des Clients endet an einer Webschnittstelle des Aktensystems.
Das VAU-Protokoll erzeugt einen durchgehenden (also ununterbrochenen) Kanal zwischen ePA-Client und VAU.

Abbildung 4: Sicherungsschichten beim Datentransport zwischen ePA-Client und ePA-VAU-Instanz

Bei ePA 1.x (und ePA 2.x), beim E-Rezept und bei ePA für alle werden jeweils unterschiedliche Authentisierungsarten für die Client-Authentisierung verwendet. Die Client-Authentisierung durchläuft quasi eine Evolution, der das VAU-Protokoll durch Anpassung folgen muss, damit die Sicherheitsziele weiterhin erreicht werden. Bei ePA 1.x und 2.x war es möglich, dass Nutzer des Aktensystems direkt über private AUT-Schlüssel Verbindungsparameter signieren konnten. Beim E-Rezept wird aktuell eine Variante des OIDC-Protokolls verwendet, bei der ein E-Rezept-Client direkt das Auth-Token lokal vorliegen hat. Solche Auth-Token verwendet er bei der Authentisierung im VAU-Protokoll beim E-Rezept-FD. Bei ePA für alle gibt es einen Authentication-Flow nach [RFC-7636] (OAuth 2.0 PKCE). Dort hat ein Client keinen Zugriff mehr auf das Auth-Token, d. h. das VAU-Protokoll aus dem E-Rezept in der aktuellen Ausbaustufe kann nicht verwendet werden. Deshalb wird für ePA für alle eine neue Version des VAU-Protokolls eingeführt. In einer späteren Ausbaustufe wechselt auch beim E-Rezept die Authentisierung auf diese OIDC-Variante -- ab dann wird bei ePA für alle und bei E-Rezept dasselbe VAU-Protokoll verwendet.

Wenn über eine HTTPS-Schnittstelle ein Request eines ePA-Clients eintrifft, steht es einem Aktensystem frei, über welches Protokoll es diesen Request an die VAU-Instanzen verteilt (bspw. per Message-Queue), d. h. die Aktensysteminterne Verbindungsstrecke zwischen HTTPS-Schnittstellen und VAU-Instanzen ist frei durch den Aktensystemhersteller wählbar.

A_24654 - ePA: HTTP-Version

Ein ePA-Aktensystem MUSS an seinen HTTPS-Schnittstellen, i. S. v. Schnittstellen, die ein ePA-Client anspricht, mindestens HTTP Version 1.1 unterstützen. [<=]

Hinweis: Im Kontext ePA bietet HTTP/2 nur geringe Vorteile gegenüber HTTP/1.1. HTTP/2 besitzt jedoch eine deutlich höhere Komplexität. Ein Hersteller ist mit A_24654-* nicht verpflichtet, eine HTTP-Version größer als 1.1 zu implementieren. A_24654 ist nicht dahingehend zu verstehen, dass von einem Aktensystem perfekte Konformität zu HTTP/1.1 umzusetzen ist. Im Kontext der ePA-Funktionalität wird nur der Umfang von HTTP verwendet, den man normaler Weise bei Webservices verwendet.

Wenn im folgenden innerhalb dieses Kapitels 7 VAU-Protokoll für ePA für alle  vom VAU-Protokoll gesprochen wird, ist stets die Variante für ePA für alle gemeint.

TCP-Verbindung...

TLS-Verbindung

TLS-Verbindung

äußere HTTP-Request
(HTTPS-Schnittstelle)

äußere HTTP-Request...

OSI-Schicht

OSI-Schicht

VAU-Protokoll

VAU-Protokoll

im Aktensystem

im Aktensystem

innere HTTP-Request

innere HTTP-Request

ePA-spezifische API (REST und SOAP) in einer VAU-Instanz

ePA-spezifische API (REST und SOAP) in einer VAU-Instanz

in einer VAU-Instanz

in einer V...

Hersteller-spezifische Weiterleitung

Hersteller-spezifische We...

im ePA-Client

im ePA-Client

Transport
(Internet oder TI)

Transport... Text is not SVG - cannot display

Abbildung 5: OSI-Schichten in einem Aktensystem

Wie im OSI-Referenzmodell üblich, ist das VAU-Protokoll agnostisch gegenüber dem über ihm transportierten Daten oder Protokollen. Das VAU-Protokoll ermöglich einen Ende-zu-Ende gesicherten Transport von Daten, bei dem es irrelevant ist, welche Protokolle unter oder über ihm in Bezug auf das OSI-Modell verwendet werden.

A_24656 - ePA, Unabhängigkeit von TLS-Ebene und VAU-Protoll-Ebene

Ein ePA-Aktensystem und ein ePA-Client MÜSSEN sicherstellen, dass die TLS-Ebene unabhängig zur VAU-Protokoll-Ebene ist, i. S. v. es gibt keine Bindung zwischen TLS-Session und VAU-Protokoll-Verbindung.
Es MUSS möglich sein, die TLS-Verbindung, über die erfolgreich ein VAU-Protoll-Handshake stattgefunden hat, zu beenden und auf einer neuen unabhängigen TLS-Verbindung weiter das VAU-Protokoll mit schon ausgehandelten Verbindungsschlüsseln zu verwenden. [<=]

Das VAU-Protokoll ermöglicht (zunächst) eine einseitig authentisierte Schlüsselaushandlung zwischen Client (FdV, LEI-PVS/AVS/KIS, KTR-Consumer) und Server (VAU-Instanz). Ähnlich wie bei einer TLS-Verbindung werden nach einer Schlüsselaushandlungsphase symmetrische Schlüssel gemeinsam berechnet und diese symmetrischen Schlüssel werden anschließend für die Sicherung der nun folgenden Nutzdaten auf Anwendungsebene verwendet. Direkt nach erfolgreich abgeschlossener Schlüsselaushandlung verwendet ein Client innerhalb der etablierten VAU-Protokoll-Verbindung auf einer höheren OSI-Schicht das OIDC-Protokoll für die Nutzer-Authentisierung gegenüber der VAU-Instanz. Ist die Authentifizierung erfolgreich gewesen, vermerkt die VAU-Instanz bei den ausgehandelten symmetrischen Schlüsseln diesen Authentisierungsstatus in den Metadaten für diese Verbindungsschlüssel. Ab dann besteht eine beidseitig authentisierte über das VAU-Protokoll gesicherte Verbindung insbesondere mit den gemeinsam berechneten symmetrischen Verbindungsschlüsseln. Das VAU-Protokoll verwendet kryptographisch für die Schlüsselaushandlung das KEM-TLS-Protokoll ([KEM-TLS], [IETF-KEM-TLS]). Die Kodierung der KEM-TLS-Nachrichten muss spezifisch für die gewählte Architektur bei ePA für alle angepasst werden. Für die Schlüsselaushandlung wird ein PQC-sicheres Hybridverfahren auf Basis von Kyber768 und ECDH analog zu [IETF-Hybrid-TLS] verwendet. Die Verwendung von PQC-sicheren Hybridverfahren findet man ebenfalls bei Messengern [PQC-Hybrid-Signal] oder bei Web-Browsern [PQC-Hybrid-Chrome]. Das VAU-Protokoll erreicht Forward-Secrecy bei der Schlüsselaushandlung -- eine etwaige Kompromittierung von Langzeit-Schlüsseln einer VAU beeinflusst nicht die Sicherheitseigenschaften von VAU-Verbindungen der Vergangenheit. Nach der Schlüsselaushandlung wählt ein Client zufällig für jeden Request eine Request-ID, die der Server in der Response aufführt. Somit kann ein Client Request-Response-Paare sicher zuordnen und kann ebenfalls Replay-Angriffe abwehren. Im Vergleich zur VAU-Protokoll-Variante aus Abschnitt 6 VAU-Protokoll für E-Rezept (E-Rezept aktuelle Ausbaustufe) wird ca. ab der vierten Nutzdaten-Nachricht ein Geschwindigkeitsvorteil erreicht, weil für die direkte Sicherung der Nutzdaten keine asymmetrischen Verfahren mehr verwendet werden (vgl. im Gegensatz dazu A_20161-* Punkt 6). Die Forward-Secrecy und die Post-Quantum-Resistenz wird bei der VAU-Protokoll-Variante aus Abschnitt 6 VAU-Protokoll für E-Rezept nicht erreicht -- es wird also mit der Anpassung des VAU-Protokolls, die aufgrund der Authentisierungsveränderung unabdingbar ist, sowohl eine Verbesserung der Sicherheitseigenschaften als auch der Performanz erreicht.

Abbildung 6: KEM-TLS Verbindungsaufbau [KEM-TLS]

Die gematik stellt Beispielimplementierungen des VAU-Protokolls in verschiedenen Programmiersprachen zur Verfügung.

7.1 Übersicht Verbindungsaufbau/Schlüsselaushandlung

Bei im Prinzip allen in der Praxis verwendeten kryptographischen Protokollen gibt es mehrere Phasen im Protokoll: Zunächst erfolgt eine Schlüsselaushandlung bei der hauptsächlich asymmetrische kryptographische Verfahren eingesetzt werden. Als Ergebnis der Schlüsselaushandlung werden symmetrische Schlüssel (AES-Schlüssel) von Client und Server gemeinsam berechnet. Diese symmetrischen Schlüssel werden anschließend für die kryptographische Sicherung der Nutzdaten verwendet. Es werden wie üblich je nach Kommunikationsrichtung (Client->Server, Server->Client) unterschiedliche Schlüssel verwendet (analog zu TLS, IPsec/IKE, SSH etc.). Die symmetrischen Schlüssel sind dann nutzerspezifisch (und je nach gewählter Implementierungs-Architektur im Aktensystem auch VAU-Instanz-spezifisch). Sie sind nicht aktenspezifisch. D. h., dieselben schon ausgehandelten symmetrischen Schlüssel können für Zugriffe auf mehrere Akten bspw. durch ein PVS verwendet werden.

Die Schlüsselaushandlung beim VAU-Protokoll erfolgt nach [KEM-TLS] und benötigt vier Nachrichten (zwei Round-Trips), die zwischen Client und VAU ausgetauscht werden. Der kryptographische Verbindungsaufbau ist in [KEM-TLS] genauer beschrieben und ebenfalls die kryptographische Funktion der einzelnen Schlüsselableitungen. Im Folgenden wird eine vereinfachte Übersicht als Verständnishilfe aufgeführt.

Nachricht	Aktion
Nachricht 1	Client -> VAU Ein Client erzeugt zwei Schlüsselpaare (ECDH, Kyber768) (analog zu [IETF-Hybrid-TLS]) und sendet die beiden öffentlichen Schlüssel an die VAU (= Nachricht 1). Bei diesen Schlüsselpaaren handelt es sich also um ephemere Schlüssel des Clients, d. h. pro Verbindungsaufbau/Handshake werden diese vom Client neu erzeugt.
Nachricht 2	VAU -> Client Die VAU verwendet die öffentlichen Schlüssel jeweils mittels eines KEM (Encapsulate), um zwei gemeinsame Geheimnisse (ss_e_ecdh, ss_e_kyber768) und zwei KEM-Chiffrate zu erzeugen. Diese Geheimnisse fließen in eine KDF (RFC-5859/SHA-256) ein (Basis: ss_e = ss_e_ecdh || ss_e_kyber768) und damit werden die symmetrischen Schlüssel K1_c2s und K1_s2c erzeugt. Wie bei TLS 1.3 üblich, werden diese Schlüssel im weiteren für die Sicherung von Daten in der Aushandlungsphase des Protokolls für die Kommunikation zum Server (K1_c2s) und zum Client (K1_s2c) verwendet. Die KEM-Chiffrate und über AES/CGM verschlüsselte semi-statische VAU-Schlüssel (A_24425-*) werden an den Client gesendet (= Nachricht 2). Verständnishinweis: Die authentisierte Verschlüsselung der öffentlichen VAU-Schlüssel (A_24425-*) erfolgt aufgrund des Grundprinzips bei TLS 1.3 möglichst früh, um Daten auch in der Handshake-Phase zu verschlüsseln. Die öffentlichen VAU-Schlüssel (A_24425-*) sind nicht vertraulich.
Nachricht 3	Client -> VAU Mittels der KEM-Chiffrate aus Nachricht 2 und der privaten Schlüssel des Clients (vgl. Nachricht 1: ECDH, Kyber768) berechnet der Client K1_c2s und K1_s2c und kann die öffentlichen VAU-Schlüssel erfolgreich entschlüsseln (AEAD-Chiffre). Er verwendet die öffentlichen VAU-Schlüssel (ECDH, Kyber768) und erhält mittels zwei KEM-Encapsulate-Berechnungen zwei Geheimnisse und zwei KEM-Chiffrate. Er berechnet aus den zwei Geheimnissen: ss_s = ss_s_ecdh || ss_s_kyber768. Diese KEM-Chiffrate verschlüsselt er über AES/GCM mittels des Schlüssels K1_c2s und erhält ein Ergebnis-Chiffrat. Mittels einer KDF auf Basis von ss = ss_e || ss_s werden abgeleitet: vier vertrauliche AES/GCM-Schlüssel:  •   K2_c2s_key_confirmation, •   K2_c2s_app_data, •   K2_s2c_key_confirmation, und •   K2_s2c_app_data und eine (nicht vertrauliche) KeyID. Der Client erzeugt den Hashwert des Transskript der zuvor ausgetauschten Daten (analog TLS). Diesen Hashwert verschlüsselt er mittels des Schlüssels K2_c2s_key_confirmation (Ziel: Key-Confirmation). Der Client sendet das Ergebnis-Chiffrat (K1_c2s) und das Key-Confirmation-Chiffrat (K2_c2s_key_confirmation) an die VAU (= Nachricht 3).
Nachricht 4	VAU -> Client Mittels der zwei KEM-Chiffrate aus Nachricht 3 und der KEM-Decapsulation-Funktionen werden die beiden Geheimnisse ss_s_ecdh und ss_s_kyber768 berechnet, und anschließend ss_s= ss_s_ecdh || ss_s_kyber768 berechnet. Analog wie im Client bei Nachricht 3 werden die dort aufgeführten vier vertraulichen AES/GCM-Schlüssel und die nicht-vertrauliche KeyID abgeleitet auf Basis von ss = ss_e || ss_s.  Mit Hilfe des Schlüssels K2_c2s_key_confirmation und der im Server gespeicherten vorherigen Nachrichten prüft der Server das vom Client gesendete Transskript-Chiffrat bzw. den Transskript-Hash darin. Der Server erzeugt selbst einen Transskript-Hash (Hashwert der Konkatenation Nachricht 1 || Nachricht 2 || Nachricht 3) und sendet diesen mittels K2_s2c_key_confirmation verschlüsselt an den Client zurück.

Client und VAU prüfen die jeweiligen Key-Confirmation (jeweils mittels der Schlüssel K2_c2s_key_confirmation und K2_s2c_key_confirmation), bevor sie die Schlüssel K2_c2s_app_data und K2_s2c_app_data in der nächsten Phase des Protokolls -- Sicherung der Nutzdaten -- verwenden.

A_24425 - VAU-Protokoll: VAU-Schlüssel für die VAU-Protokoll-Schlüsselaushandlung

Ein Aktensystem MUSS sicherstellen, dass

1.   es eine Signatur-Identität aus der Komponenten-PKI der TI gibt, die technisch sichergestellt ausschließlich nur von VAU-Instanzen verwendbar ist (AUT-Zertifikat und Schlüsselmaterial (VAU-HSM) wie bei ePA 1x. und 2.x).

2.   es semi-statische Schlüsselpaare für ECDH (auf Basis Kurve P-256 [FIPS-186-5]) und Kyber768 [IEFT-Kyber] gibt, deren private Schlüssel, technisch sichergestellt, ausschließlich von VAU-Instanzen verwendbar sind.

3.   die privaten Schlüssel in einer VAU-Instanz erzeugt und verarbeitet werden (also nicht im VAU-HSM),

4.   die semi-statischen Schlüssel eine maximale Lebensdauer von einem Monat besitzen (Hinweis: die Forward-Secrecy hängt nicht vom Wechselintervall ab, innerhalb eines Verbindungsaufbaus und der Schlüsselaushandlung dabei fließen ephemere Schlüsselwerte von Client und Sever ein).

5.   die semi-statischen Schlüssel in einer über die Signatur-Identität authentisierten folgenden Datenstruktur aufgeführt werden.

Struktur der signierten semi-statischen öffentlichen VAU-Schlüssel

VAU_Keys = {           "ECDH_PK" :             { "crv" : "P-256",               "x" : Binärwert-x-Koordinate-32-Bit-big-endian,               "y" : Binärwert-x-Koordinate-32-Bit-big-endian,             },           "Kyber768_PK" : Binärwert-öffentlicher-Schlüssel-nach-keygen-Spec-Kyber768,           "iat" : Erzeugungszeits-Sekunden-Since-Epoch (integer),           "exp" : Nicht-mehr-Verwendbar-nach (integer),           "comment" : "Erzeugt bei VAU-Instanz xyz, Meta-Info abcd" } In "comment" KÖNNEN beliebige Text-Daten aufgeführt werden. Es können weitere Attribute hinzugeführt werden. Ein Client MUSS ihm unbekannte Attribute ignorieren. Diese Struktur wird mittels CBOR [RFC-CBOR] binär kodiert und im Folgenden VAU_Keys_encoded genannt. Diese binäre Byte-Folge wird in folgende Datenstruktur eingebracht {  "signed_pub_keys" : VAU_Keys_encoded,  "signature-ES256" : ECDSA-Signatur-SHA-256-analog-RFC-7515 (R||S => 64 Byte) binär,  "cert_hash"       : SHA-256-Wert des "signierenden" AUT-VAU-Zertifikats,  "cdv"             : Cert-Data-Version (natürliche Zahl, beginnend mit 1, vgl. A_24957-*),  "ocsp_response"   : OCSP-Response-für-das-VAU-Signaturzertifikat-nicht-älter-als-24-Stunden-DER-Kodierung } Diese Datenstruktur wird mittels CBOR binär kodiert (serialisiert). Das Ergebnis der Kodierung wird "signierte öffentliche VAU-Schlüssel" (Plural) genannt.

[<=]

A_24957 - VAU-Protokoll: Verfügbarmachung des AUT-VAU-Zertifikat plus Prüfkette

Ein Aktensystem MUSS über an seinen Webschnittstellen mittels eines äußeren HTTPS-Requests per HTTP-GET unter dem Pfadnamen /CertData.<SHA-256-Hashwert-Hex-[0-9a-f]>-Versionszahl (a-f kleingeschrieben) folgende Datenstruktur zur Verfügung stellen:

{
   "cert": DER-kodiertes-AUT-VAU-Zertifikat,
   "ca"  : DER-kodiertes-Komponenten-PKI-CA-aus-dem-"cert"-kommt,
   "rca_chain" : [Cross-Zertifikat-1, ..., Cross-Zertifikat-n],
}

Die Versionszahl MUSS eine natürliche Zahl sein, beginnend mit 1, die es trotz A_24958-* erlaubt, Fehler in den Daten zu korrigieren (siehe Erläuterung nach A_24957-*).

Diese Datenstruktur MUSS per CBOR [CBOR-RFC] serialisiert/kodiert werden und per Mime-Type "application/cbor" [RFC-CBOR] (HTTP Content-Type) an den VAU-Client als Response auf den GET-Request gesendet werden.

In "rca_chain" MÜSSEN alle Cross-Zertifikate in chronologischer Ordnung von RCA5 ausgehend aufgeführt werden, bis die Root-Schlüssel (Cross-Zertifikat) erreicht werden, mit denen das "ca"-Zertifikat bestätigt (signiert) wurde; d. h., sozusagen eine einfach verkettete Liste von Cross-Zertifikaten chronologisch aufsteigend.
[<=]

Erläuterung:

In A_24425-* werden die "signed_pub_keys" mit dem Schlüsselmaterial der AUT-VAU-Identität des Aktensystems authentisiert, analog zum VAU-Protokoll ePA 1.x und 2.x. Dieses Zertifikat ist über die Signaturkettenprüfung der TI-PKI prüfbar. Dafür benötigt der VAU-Client die Zertifikate, die die Prüfkette ausmachen. Als Vertrauensanker besitzt der Client entweder X.509-Root-Zertifikate, und zwar mindestens RCA5 (PU), oder die TSL. Die Konstruktion nach A_24957-* stellt die Zertifikate für die Prüfkette und das AUT-VAU-Zertifikat selbst ("cert"-Feld) zur Verfügung. Aufgrund der Konstruktion kann man davon ausgehen, dass die Daten in solch einer Datei sich nie ändern werden, i. S. v. einmal vom Client per GET bezogen werden und dann ewig gespeichert werden kann. Sollte sich nach einem Deployment der CertData-Datei (i. S. v. einige Clients haben diese Datei schon bezogen) bspw. CertData-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855-1 herausstellen, dass dort Fehler enthalten sind, dann kann man über die Versionsnummer im Handshake (vgl. "cdv"-Feld, A_24425-*) und der Erstellung einer neuen CertData-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855-2 diese Fehler im laufenden Betrieb korrigieren.

A_24958 - VAU-Protokoll: VAU-Client Prüfbasis Zertifikatsprüfung

Ein VAU-Client (PVS, ePA-FdV etc.) MUSS als Prüfbasis eine Root-Version (X.509-Root-TI-Zeritifikat), die mindestens 2 Jahre alt ist, verwenden oder die TSL. Der VAU-Client MUSS die Operation nach A_24957-* verwenden, um die für die Zertifikatsprüfung von A_24425-* notwendigen Zertifikate zu beziehen. Die bezogenen Zertifikatsdaten MUSS der VAU-Client lokal (zeitlich unbegrenzt) vorhalten (Caching). Bei Erhalt einer Nachricht 2 (A_24608-*) MUSS er zunächst prüfen, ob er die für die Zertifikatsprüfung notwendigen Zertifikate im lokalen Cache vorrätig hat, und falls ja MUSS er diese verwenden.
[<=]

A_24427 - VAU-Protokoll: VAU-Schlüssel für die VAU-Protokoll-Schlüsselaushandlung

Ein Aktensystem KANN in Bezug auf die Erzeugung der signierten öffentlichen VAU-Schlüssel (vgl. A_24425-*) und der Erzeugung und der Vorhaltung der dazu passenden zwei privaten Schlüssel (ECDH, Kyber768) zwischen zwei Modellen wählen:
(1)
Im Normalfall wird eine VAU-Instanz "auf Vorrat" im Aktensystem gestartet. Beim Starten der Instanz erzeugt die Instanz die beiden Schlüsselpaare und signierte diese mittels der im VAU-HSM befindlichen Signaturidentität (gemäß A_24425-*). Die privaten Schlüssel bleiben genau nur in dieser VAU-Instanz.
(2)
Eine VAU-Instanz erzeugt regelmäßig die Schlüsselpaare und anschließend die Datenstruktur der signierten öffentlichen VAU-Schlüssel. Die privaten Schlüssel werden auf sichere Weise bei den VAU-Instanzen verfügbar gemacht. [<=]

Erläuterung: Je nach verwendeten Implementierungs-Architektur und den zur Implementierung verwendeten HSM (die recht unterschiedliche Schlüsselverteilungsmethoden haben), kann für einen Hersteller ein Modell einfacher umzusetzen sein als das andere. Die Motivation der Anforderung ist festzustellen, dass beide Modelle explizit erlaubt sind.

A_24757 - VAU-Protokoll: Nutzerpseudonym

Ein VAU-Client MUSS die HTTP-Variable "VAU-NP" aus vorherigen VAU-Protokoll-Verbindungen speichern und bei den folgenden VAU-Protokoll-Handshakes bei der Nachricht 1 (vgl. A_24428-*) im HTTP-Request-Header aufführen (Hinweis: zu dem Zeitpunkt kann es noch keine inneren HTTP-Request geben / Verbindungsaufbau). Initial hat ein Client diesen Wert noch nicht, dann führt er die Variable nicht im Request-Header auf.
Ein VAU-Client MUSS nach einer erfolgreichen Client-Authentisierung (vgl. [gemSpec_Krypt#7.3 und 7.4]) den inneren HTTP-Response-Header prüfen, ob die Variable "VAU-NP" aufgeführt ist, falls ja MUSS er einen lokal gespeicherten Wert ggf. aktualisieren (i. S. v. ein Aktensystem (VAU-Instanz) wird dieses Nutzerpseudonym auch wechseln).
[<=]

Erläuterung: Das VAU-NP erleichtert die Implementierung im Aktensystem. Es ist für die Implementierung günstig, wenn ein Nutzer mit möglichst vielen seiner Requests (bzw. neuer VAU-Verbindungen) in derselben VAU-Instanz landet. Die Variable dient dem Routing nach der HTTPS-Schnittstellen des Aktensystems (Verteilung der Requests auf die verschiedenen VAU-Instanzen, vgl. Abschnitt 7.5 Routing auf VAU-Instanzen).

Bestimmte Clients (bspw. der E-Rezept-FD in der Rolle als ePA-Client) werden ggf. auf mehrere VAU-Instanz verteilt, die konkrete Ausgestaltung liegt in der Entscheidungshoheit des Aktensystemherstellers.

Vgl. auch A_24773-* (Neustart der Verbindung bei unterschiedlichen Nutzergeräten im Erstnutzungsfall).

A_24428 - VAU-Protokoll: VAU-Client: Nachricht 1

Ein VAU-Client MUSS für die Erzeugung folgende Schritte durchlaufen.
Ein VAU-Client MUSS

1.   ein ECC-Schlüsselpaar auf der Kurve P-256 [FIPS-186-5] erzeugen.

2.   ein Kyber768-Schlüsselpaar [IETF-Kyber] erzeugen.

Anschließend MUSS er die öffentlichen Schlüssel in folgende Datenstruktur überführen
 {
    "MessageType" : "M1",
    "ECDH_PK"    :  { "crv" : "P-256",
                      "x" : analog A_24425-*,
                      "y" : analog A_24425-* },
    "Kyber768_PK" : analog zu A_24425-*
}

Diese Datenstruktur MUSS er mittels CBOR [RFC-CBOR] in eine Bytefolge kodieren (serialisieren).
Diese Bytefolge ist die Nachricht 1.

Diese Nachricht 1 MUSS der VAU-Client an die HTTPS-Schnittstelle des Aktensystem per POST auf den Pfad /VAU senden, wobei er den Mime-Type "application/cbor" [RFC-CBOR] (HTTP Content-Type) verwendet und die Nachricht 1 im Request-Body aufführt.

Vgl. auch A_24757-*
[<=]

Hinweis: Für ein ePA-FdV ist das Access Gateway im Internet und dessen HTTPS-Schnittstelle der Zugang zum Aktensystem, an den das ePA-FdV seinen Request (bspw. A_24428-*) sendet. Ein ePA-Client aus der TI verwendet direkt die äußere HTTPS-Schnittstelle eines Aktensystems innerhalb der TI (analog zu ePA 1.x und 2x.).

A_24429 - VAU-Protokoll: VAU-Instanz: Erhalt von Nachricht 1

Eine VAU-Instanz (Server im VAU-Protokoll) MUSS die für Nachricht 1 erzeugten Datenobjekte nach A_24428-* verarbeiten können. [<=]

A_24619 - VAU-Protokoll: AES/GCM-Verschlüsselung im Handshake

Eine VAU-Instanz und ein ePA-Client verschlüsseln im Rahmen des Handshakes des VAU-Protokolls verschiedene Nachrichten-Teile mittels AES/GCM. Dabei MÜSSEN sie pro Verschlüsselung den IV jeweils zufällig als 96-Bit-Wert erzeugen. Der Authentication-Tag MUSS 128 Bit lang sein. Das Ergebnis der Verschlüsselung MUSS dann in der folgenden Kodierung aufgeführt werden:
IV || eigentliche AES-GCM-Chiffrat || 128-Bit langer Authentication-Tag. [<=]

A_24608 - VAU-Protokoll: VAU-Instanz: Nachricht 2

Eine VAU-Instanz (Server im VAU-Protokoll) MUSS die beiden öffentlichen Schlüssel aus Nachricht 1 (vgl. A_24428-*) prüfen (korrekte ECC-Kurve ("crv":"P-256"), öffentlicher Punkt liegt auf der Kurve P-256 [FIPS-186-5], der öffentliche Kyber768-Schlüssel ist valide [IETF-Kyber]).
Sie MUSS für ECDH und Kyber768 jeweils die KEM-Encapsulate-Funktion verwenden und erhält dabei zwei Geheimnisse (ss_e_ecdh, ss_e_kyber768) und zwei Ciphertexte (ECDH_ct, Kyber768_ct).
Sie MUSS für die beiden Geheimnisse zusammenfügen: ss_e = ss_e_ecdh || ss_e_kyber768 und das Ergebnis mittels der HKDF [RFC-5859] auf Basis von SHA-256 verwenden (info = '' (leere Zeichenkette)), um 64 Byte abzuleiten. Die ersten 32 Byte (=256 Bit) heißen K1_c2s und die letzten 32 Byte heißen K1_s2c.

Mit dem Schlüssel K1_s2c mittels AES/CGM (vgl. A_24619) MÜSSEN die  "signierten öffentlichen VAU-Schlüssel" (vgl. A_24425-*) verschlüsselt werden. Das Ergebnis (vgl. A_2416) heißt aed_ciphertext_msg_2.

Sie MUSS folgende Datenstruktur erzeugen:
{
    "MessageType" : "M2",
    "ECDH_ct"     :  ... analog ECDH_PK aus A_24488-* ...,
    "Kyber768_ct" : Kyber768-Ciphertext analog [IETF-Kyber768], vgl. Referenz-Implementierung Kyber768,
    "AEAD_ct"     : aead_ciphertext_msg_2
}

Diese Datenstruktur MUSS sie mittels CBOR [RFC-CBOR] serialisieren. Diese Bytefolge ist Nachricht 2.

Sie MUSS einen ID erzeugen, kodiert aus der Zeichenmenge
A-Za-z0-9-/ 
die maximal 200 Zeichen lang ist. Die ID MUSS mit "/" (Slash) beginnen und MUSS ein gültiger URL-Pfadname sein. Diese ID MUSS es dem Aktensystem ermöglichen, die VAU-Instanz und den aktuellen Handshake bei Eintreffen der Nachricht-3 des ePA-Clients, der diese ID mitsendet, zu identifizieren. Das Aktensystem kann die Struktur der ID selbst definieren. Ein ePA-Client MUSS die ID als opake Zeichenkette behandeln.
Sie MUSS die Nachricht 2 inkl. ID an die HTTPS-Schnittstelle des Aktensystem übergeben (die Art der Verbindung zwischen VAU-Instanz und HTTPS-Schnittstelle des Aktensystems kann ein Hersteller frei wählen). Das Aktensystem (bzw. die äußere HTTPS-Schnittstelle) MUSS als Antwort auf den HTTPS-Request, über den die Nachricht 1 eingetroffen ist, die Nachricht 2 als Antwort im Response-Body senden. Der zu verwendende Mime-Type MUSS "application/cbor" (HTTP Content-Type) für die Response sein. Im Response-Header MUSS mit der HTTP-Header-Variable "VAU-CID" die ID aufgeführt werden. [<=]

Hinweis: Bei der KEM-Encapsulate-Funktion fließt Zufall aus dem System ein. Für die VAU-Instanzen (und auch für die ePA-Clients) gelten die Vorgaben aus Abschnitt 2.4 (Güte der Zufallserzeugung, Zuweisung über den Produkttypsteckbrief).

Beispiele für die ID aus A_24608:

•   /VAU/9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08/1b4f0e9851971998e732078544c96b36c3d01cedf7caa332359d6f1d83567014

•   /VAU/A-XYZ/1b4f0e9851971998e732078544c96b36c3d01cedf7caa332359d6f1d83567014 

A_24622 - VAU-Protokoll: VAU-Client: Erhalt von Nachricht 2

Ein VAU-Client MUSS die für Nachricht 2 erzeugten Datenobjekte nach A_24608-* verarbeiten können.
Er MUSS prüfen, ob

1.   im HTTP-Response-Header die Variable "VAU-CID" enthalten ist, falls nicht Abbruch.

2.   der Wert der Variable eine Bytefolge ist, dessen Länge maximal 200 Byte lang ist und die nur die Zeichen 
A-Za-z0-9-/ 
enthält und mit "/" (Slash) beginnt. Falls nicht Abbruch.

Er MUSS den Wert als Pfad für das Versenden der Nachricht 3 (vgl. A_24623) und aller weiteren Nachrichten -- also auch nach dem erfolgreichen Handshake -- im Kontext dieser Verbindung verwenden. [<=]

A_24623 - VAU-Protokoll: VAU-Client: Nachricht 3

Ein VAU-Client MUSS aus der Nachricht 2 (vgl. A_24622-*) der VAU-Instanz mittels der Ciphertexte ECDH_ct und Kyber768_ct und den privaten ephemeren Client-Schlüsseln aus A_24488 (Nachricht 1) und der jeweiligen KEM-Decapsulation-Funktionen zwei Geheimnisse berechnen: ss_e_ecdh und ss_e_kyber768. Er MUSS die beiden Geheimnisse zusammenfügen: ss_e = ss_e_ecdh || ss_e_kyber768 und das Ergebnis mittels der HKDF [RFC-5859] auf Basis von SHA-256 verwenden (info = '' (leere Zeichenkette), um 64 Byte abzuleiten. Die ersten 32 Byte (=256 Bit) heißen K1_c2s und die letzten 32 Byte heißen K1_s2c.

Mit dem Schlüssel K1_s2c mittels AES/CGM (vgl. A_24619-*) MUSS der Ciphertext "AEAD_ct" entschlüsselt werden: die "signierten öffentlichen VAU-Schlüssel" (vgl. A_24425-*) werden so als Klartext erhalten. Diese VAU-Schlüssel MUSS er nach A_24624-* prüfen. Mittels der öffentlichen Schlüssel (ECDH_PK, Kyber768_PK) MUSS er jeweils die KEM-Encapsulation-Funktion ausführen und er erhält zwei Geheimnisse: ss_s_ecdh und ss_s_kyber768. Diese führt er zusammen: ss_s = ss_s_ecdh || ss_s_kyber768. Weiter berechnet er ss = ss_e || ss_s.
Dieses Geheimnis verwendet die HKDF [RFC-5859] auf Basis von SHA-256 (info = '' (leere Zeichenkette)), um 160 Byte (=5 * 32 Byte) abzuleiten. Er MUSS diese 160 Byte in 32 Byte-Blöcke (von offset 0 bis zum Ende) auf folgende fünf Variablen (vier Schlüssel + eine KeyID) verteilen:

• K2_c2s_key_confirmation,
• K2_c2s_app_data,
• K2_s2c_key_confirmation,
• K2_s2c_app_data

und 

• KeyID (nicht vertraulich).

Diese ersten vier sind vertrauliche Schlüsselwerte für AES/GCM. Die KeyID wird nach dem Handshake als eindeutige ID für die K2*_app_data Schlüssel dienen.

Er MUSS eine Datenstruktur wie folgt erzeugen:

{
    "ECDH_ct"    : client_kem_result_2["ECDH_ct"],
    "Kyber768_ct" : client_kem_result_2["Kyber768_ct"],
    "ERP" : False,
    "ESO" : False
}

ERP steht für "Enforce Replay Protection" und ESO steht für "Enforce Sequence Order". Innerhalb der Spezifikation heißt diese Datenstruktur Nachricht_3_inner_Layer. Diese Datenstruktur MUSS er per CBOR [CBOR] serialisieren/kodieren. Diese Serialisierung MUSS er mittels K1_c2s verschlüsseln (vgl. A_24619) (= "ciphertext_msg_3).
Er MUSS die komplette Nachricht-1 (CBOR-Kodierung), die Nachricht-2 und ciphertext_msg_3 konkatenieren (= Transskript des Client) und davon den SHA-256-Hashwert berechnen. Diesen Hashwert MUSS er mittels K2_c2s_key_confirmation verschlüsseln (vgl. A_24619), das Chiffrat sei als aead_ciphertext_msg_3_key_confirmation hier bezeichnet.

Dann MUSS er folgende Datenstruktur erzeugen:

{
     "MessageType" : "M3",
     "AEAD_ct"     : ciphertext_msg_3,
     "AEAD_ct_key_confirmation" : aead_ciphertext_msg_3_key_confirmation
}            

Diese Datenstruktur MUSS er per CBOR serialisieren, das Ergebnis ist Nachricht 3.
Er MUSS die Nachricht 3 per äußeren HTTP-Request an das Aktensystem senden und dabei den Wert der VAU-CID (vgl. A_24622) als URL-Pfadnamen verwenden, unter Verwendung der HTTP-POST-Methode.
[<=]

A_24624 - VAU-Protokoll: VAU-Client: Prüfung der "signierten öffentlichen VAU-Schlüssel"

Ein VAU-Client MUSS die "signierten öffentlichen VAU-Schlüssel" (vgl. A_24425-*) bei der Verarbeitung von Nachricht 3 (vgl. A_24623-*) wie folgt prüfen. Hat er bei einem der folgenden Prüfpunkte kein positives Prüfergebnis, MUSS er die Verarbeitung (Handshake) abbrechen.

3. Prüfung des TI-Zertifikats aus dem "cert"-Feld u. a. unter der Verwendung der OCSP-Response aus "ocsp_response" für die Prüfung des Sperrstatus (Prüfung ob "good"). Die OCSP-Response darf dabei nicht älter als 24 Stunden sein.
4. Das Zertifikat MUSS aus der aus der Komponenten-PKI der TI stammen und die Rollen-OID "oid_epa_vau" besitzen.

Das VAU-Zertifikat MUSS zeitlich gültig sein. Es MUSS kryptographisch in einer Zertifikats-/Signaturprüfungskette rückführbar auf eine X.509-Root-Version der TI-PKI sein. [<=]

A_24625 - VAU-Protokoll: VAU-Instanz: Erhalt von Nachricht 3

Eine VAU-Instanz (Server im VAU-Protokoll) MUSS die für Nachricht 3 erzeugten Datenobjekte nach A_24623-* verarbeiten können. [<=]

A_24626 - VAU-Protokoll: VAU-Instanz: Nachricht 4

Eine VAU-Instanz MUSS bei Erhalt der Nachricht 3 das Chiffrat AEAD_ct mittels des Schlüssels K1_c2s entschlüsseln. Schlägt dies fehl, MUSS sie den Verbindungsaufbau mit einem Fehler (vgl. A_24635-*) abbrechen. Sie MUSS analog wie der Client (vgl. A_24623-*) die Schlüsselerzeugung der folgenden Schlüssel durchführen, nur dass sie dafür die KEM-Decapsulation-Methode verwendet:

• K2_c2s_key_confirmation,
• K2_c2s_app_data,
• K2_s2c_key_confirmation,
• K2_s2c_app_data

und 

• KeyID (nicht vertraulich).

Sie MUSS analog zu A_24635-* das Transskript des Clients und dessen SHA-256-Wert berechnen. Sie MUSS mittels K2_c2_key_confirmation das Chiffrat "AEAD_ct_key_confirmation" aus Nachricht 3 entschlüsseln und prüfen, ob der von ihr (= VAU-Instanz) berechnete Transskript-Client-Hashwert mit dem entschlüsselten Klartext übereinstimmt. Schlägt die Entschlüsselung fehl oder wird eine Ungleichheit zwischen berechnete Transskript-Client-Hashwert und Klartext festgestellt, MUSS sie den Handshake mit einem Fehler abbrechen (vgl. A_24635-*).
Sie MUSS den Transskript der VAU-Instanz als die Konketation von Nachricht1 || Nachricht 2 || Nachricht 3 berechnen, davon den SHA-256-Hashwert berechnen und diesen mittels K2_s2c_key_confirmation verschlüsseln (vgl. A_24619-*), und erhält ein Chiffrat  genannt "AEAD_ct_key_confirmation". 
Sie MUSS die folgende Datenstruktur erzeugen:
{
     "MessageType" : "M4",
     "AEAD_ct_key_confirmation" : Chiffrat-AEAD_ct_key_confirmation
}
Diese Datenstruktur MUSS sie mittels CBOR [RFC-CBOR] serialisieren. Diese Bytefolge ist Nachricht 4.

Sie MUSS die Nachricht 4 inkl. ID (vgl. A_24608-*) an die HTTPS-Schnittstelle des Aktensystem übergeben. Das Aktensystem (bzw. die äußere HTTPS-Schnittstelle) MUSS als Antwort auf den HTTPS-Request, über den die Nachricht 3 eingetroffen ist, die Nachricht 4 als Antwort im Response-Body senden. Der zu verwendende Mime-Type MUSS "application/cbor" (HTTP Content-Type) für die Response sein. Im Response-Header MUSS mit der HTTP-Header-Variable "VAU-CID" die ID aufgeführt werden. [<=]

Erläuterung:

Die Aufführung von "VAU-CID" im Response-Header ist eigentlich nicht mehr absolut notwendig, da der Client diese schon bei Nachricht 2 erhalten und als URL-Pfadname ab jetzt im Laufe der weiteren Verbindung verwenden wird (A_24622-*). Die Absicht der Aufführung ist, eine etwaige Fehlersuche bspw. bei IOP-Tests zu unterstützen.

A_24627 - VAU-Protokoll: VAU-Client: Erhalt von Nachricht 4

Ein VAU-Client MUSS die für Nachricht 4 erzeugten Datenobjekte nach A_24626-* verarbeiten können.

Er MUSS die Nachrichten 1, 2 und 3 konkatenieren und den SHA-256-Hashwert erzeugen. Dies ist der Transskript-Hashwert. Er MUSS mittels K2_s2c_key_confirmation das Chiffrat "AEAD_ct_key_confirmation" entschlüsseln (vgl. A_24619-*).
Der erhaltene Klartext ist der gesendete Transskript-Server-Hashwert.
Schlägt die Entschlüsselung fehl oder wird eine Ungleichheit zwischen eben berechneten Transskript-Hashwert und gesendeten Transskript-Server-Hashwert (Klartext des Chiffrats) festgestellt, MUSS er den Handshake mit einem Fehler abbrechen. [<=]

7.2 Transport und Sicherung der Nutzdaten

A_24629 - VAU-Protokoll: VAU-Client: Verschlüsselungszähler

Ein VAU-Client MUSS sicherstellen, dass der Schlüssel K2_c2s_app_data als Attribut einen 64-Bit-Zähler besitzt. Dieser Zähler MUSS initial 0 sein. Der VAU-Client MUSS sicherstellen, dass bei jeder Verwendung des Schlüssels bei der Verschlüsselung einer Nachricht der Zähler um eins erhöht wird. Der erste verwendete Zählerwert ist also 1. Es spielt dabei keine Rolle, ob die Nachricht (Chiffrat) ggf. nicht übermittelt werden konnte, der Zähler MUSS bei jeder neuen Nutzung um eins erhöht werden. [<=]

Hinweis: Ein Zählerüberlauf kann praktisch nie erreicht werden. Würde ein Client im Nano-Sekunden-Takt den Zähler erhöhen, würde erst nach mehr als 583 Jahren der Überlauf eintreten. Deshalb wird auf einen Überlauftest verzichtet.

A_24628 - VAU-Protokoll: VAU-Client: Request erzeugen/verschlüsseln

Ein VAU-Client MUSS einen inneren HTTP-Request als Klartext erzeugen. 

Er MUSS den Klartext mittels AES/GCM und dem Schlüssel K2_c2s_app_data verschlüsseln (siehe AAD weiter unten).
Dafür wird ein 32-Bit Zufallswert a erzeugt. Nach A_24629-* wird der mit K2_c2s_app_data verbundene Zähler um eins erhöht. Es wird der IV mit IV=a || Zähler erzeugt. Dieser IV wird für die AES/GCM-Verschlüsselung verwendet.

Er MUSS einen Request-Counter pflegen, der verbunden ist mit der KeyID. Für jeden Request MUSS der VAU-Client diesen Request-Counter erhöhen, bei Empfang einer Antwort ist es dem Client möglich, die Response zum zuvor gestellten Request sicher zuzuordnen (vgl. A_24633). (vgl. Erläuterungen zu A_24628-*).

Es wird folgender Header erzeugt: 

Name	Länge	Beschreibung bzw. Vorgabe des Werts
Version (=0x02)	1 Byte	Versionsnummer, wird auf den Wert 2 gesetzt
PU/nonPU	1 Byte	Wird das Chiffrat in der PU erzeugt, so MUSS der Wert 1 sein. Anderenfalls hat das Byte den Wert 0.
Response/Request	1 Byte	Für eine Nachricht des ePA-Clients an eine VAU-Instanz wird der Wert auf 1 gesetzt. In der Kodierung des Response-Chiffrat hat dieses Byte den Wert 2, was markiert, dass es sich um eine Response handelt.
Request-Counter	8 Byte	Eindeutige Zählernummer für diesen Request Für jeden neuen Request wird vom Client dieser Wert um eins erhöht.
KeyID	32 Byte	KeyID aus dem Handshake (vgl. A_24623-*)

Dieser Header stellt die "Additional Associated Data" dar, die in die Berechnung des Authentication-Tag bei der AES/GCM-Verschlüsselung einfließen MÜSSEN. Der Authentication-Tag MUSS 128 Bit lang sein.

Das erweitere Chiffrat (also inkl. Header) MUSS folgende Struktur haben: 

Name	Länge	Beschreibung bzw. Vorgabe des Werts
Version (=0x02)	1 Byte	Versionsnummer, wird auf den Wert 2 gesetzt
PU/nonPU	1 Byte	Wird das Chiffrat in der PU erzeugt, so MUSS der Wert 1 sein. Anderenfalls hat das Byte den Wert 0.
Response/Request	1 Byte	Für eine Nachricht des ePA-Clients an eine VAU-Instanz wird der Wert auf 1 gesetzt. In der Kodierung des Response-Chiffrat wird es auf den Wert 2 gesetzt, was markiert, dass es sich um eine Response handelt.
Request-Counter	8 Byte	Eindeutige Zählernummer für diesen Request, für jeden neuen Request wird vom Client dieser Wert um eins erhöht.
KeyID	32 Byte	KeyID aus dem Handshake (vgl. A_24623-*)
IV	12 Byte (= 96 Bit)	IV für die AES/GCM-Verschlüsselung (32 Bit Zufall + 64 Bit Verschlüsselungszähler, s. o. in A_24628-*)
CT	variabel	eigentliche AES/GCM-Chiffrat, dessen Länge gleich der Länge des Klartextes ist
GMAC-Wert	16 Byte (= 128 Bit)	Authentication-Tag, der während der AES/GCM-Verschlüsselung inkl. der Associated Data (Daten aus der Header-Tabelle, s. o.) berechnet wird.

Der VAU-Client MUSS diese Datenstruktur per HTTP-POST an die VAU-Instanz senden und als URL-Pfadnamen dabei den Wert der VAU-CID (vgl. A_24622-*) verwenden. Dabei MUSS er den Media-Type 'application/octet-stream' (HTTP Content-Type) verwenden.
[<=]

Erläuterung:

Der Verschlüsselungszähler, der im Client mit dem Schlüssel K2_c2s_app_data verbunden ist, hat die Funktion für den Galois Counter Mode (GCM) sicherzustellen, dass der jeweils pro Verschlüsselungsvorgang erzeugte Initialisierungsvektor (IV) (bei gleichen Wert von K2_c2s_app_data) einzigartig ist. 

Der Request-ID-Zähler hat drei Funktionen. Einmal soll im Client eine Response des Servers sicher einem vorher gesendeten Request zuordenbar sein. Sollte im Verbindungsaufbau "Enforce Replay Protection" aktiviert worden sein, prüft der Server, ob Requests mit gleicher Request-ID mehrfach eingetroffen sind (ähnlich der "Anti Replay Window"-Technik bei IPsec). Wenn analog "Enforce Sequence Order" aktiviert worden ist, dann prüft der Server die Folge der Request-ID der einkommenden Requests auf strenge Monotonie.

In der aktuellen Ausbaustufe von ePA für alle werden die letzten beiden Funktionen nicht benötigt (wie auch aktuell beim E-Rezept nicht).

Da Verschlüsselungszähler und Request-ID unterschiedliche Funktionen/Motivationen besitzen, sind sie als separate (theoretisch auch im Wert unterschiedliche) Datenobjekte aufgeführt.

A_24630 - VAU-Protokoll: VAU-Instanz: Request entschlüsseln/auswerten

Ein Request erreicht das Aktensystem über eine HTTPS-Schnittstelle. Im äußeren Request nimmt das Aktensystem das Routing mittels der Verbindungs-ID (URL-Pfadname, A_24622-* und A_24628-*) und/oder der KeyID im Header des Chiffrats vor.

Eine VAU-Instanz MUSS bei Erhalt eines Chiffrat nach A_24628-* folgendes prüfen.

2. Ist die Länge der Datenstruktur mindestens 72 Byte lang.
3. Ist die "PU/nonPU" Byte korrekt, i. S. v. korrekte Umgebung, in der auch die VAU-Instanz arbeitet.
4. Ist das Request/Response-Byte gleich 1.
5. Ist die KeyID bekannt.

Sollte eine dieser Prüfungen oder eine weitere der folgenden Prüfungen ein nicht-positives Prüfergebnis ergeben, so MUSS die VAU-Instanz die Verarbeitung des Requests abbrechen und mit einer Fehlermeldung (vgl. A_24635-*) dem Client antworten.

Die VAU-Instanz MUSS den mit der KeyID verbundenen Schlüssel K2_c2s_app_data für die Entschlüsselung des Chiffrats verwenden und dabei analog A_24628-* den Header als "Additional Associated Data" mit in die Entschlüsselung einfließen lassen. Ergibt die Entschlüsselung das Symbol "FAIL", so MUSS Abbruch und Fehlermeldung (vgl. A_24635-*) erfolgen. Die VAU-Instanz MUSS den Request-Counter-Wert speichern, der für die Antwort (A_24632-*)  benötigt wird.
[<=]

Hinweis:

"Enforce Replay Protection" und "Enforce Sequence Order" werden in der aktuellen Ausbaustufe von ePA für alle nicht umgesetzt, weil fachlich noch nicht benötigt.

A_24631 - VAU-Protokoll: VAU-Instanz: Verschlüsselungszähler

Eine VAU-Instanz MUSS sicherstellen, dass der Schlüssel K2_s2c_app_data als Attribut einen 64-Bit-Zähler besitzt. Dieser Zähler MUSS initial 0 sein. Eine VAU-Instanz MUSS sicherstellen, dass bei jeder Verwendung des Schlüssels bei der Verschlüsselung einer Nachricht der Zähler um eins erhöht wird. Der erste verwendete Zählerwert ist also 1. Es spielt dabei keine Rolle, ob die Nachricht (Chiffrat) ggf. nicht übermittelt werden konnte, der Zähler MUSS bei jeder neuen Nutzung um eins erhöht werden. [<=]

Verständnishinweis: analog A_24629-*.

A_24632 - VAU-Protokoll: VAU-Instanz: Response erstellen/verschlüsseln

In der VAU-Instanz wird der innere HTTP-Request (Ergebnis aus A_24630-*) fachlich verarbeitet und als Antwort eine innere HTTP-Response erzeugt. Diese ist der Klartext, der jetzt behandelt wird.

Eine VAU-Instanz MUSS analog zu A_24628-* einen Header erzeugen, wobei sie

4. beim Response/Request-Byte den Wert 2 verwenden MUSS,
5. im Request-Counter den gespeicherten Wert aus A_24630-* (Eingang des Requests) verwenden MUSS.

Die anderen Header-Variablen MÜSSEN analog zu A_24628-* festgelegt werden.
Die Konstruktion des IV MUSS analog zu A_24628-* erfolgen, nur dass für den Verschlüsselungszähler der Wert nach A_24631-* (K2_s2_app_data) verwendet werden MUSS.
Mit dem IV und dem Schlüssel K2_s2c_app_data MUSS der Klartext (s. o.) verschlüsselt werden mit AES/GCM, wobei der Header als "Additional Associated Data" bei der Verschlüsselung mit einfließt.

Das so erzeugte erweiterte Chiffrat (vgl. A_24628-*, also Chiffrat inkl. Header) MUSS an den Client im HTTP-Response-Body versendet werden, wobei das Aktensystem den Media-Type 'application/octet-stream' (HTTP Content-Type) verwenden MUSS.
[<=]

A_24633 - VAU-Protokoll: VAU-Client: Response entschlüsseln/auswerten

Ein VAU-Client MUSS bei Erhalt einer Antwort gemäß A_24632-* auf einen Request gemäß A_24628-* folgendes prüfen:

10.                     Ist die Länge der Datenstruktur (erweiterte Chiffrat) mindestens 72 Byte lang.
11.                     Ist die "PU/nonPU" Byte korrekt, i. sS v. korrekte Umgebung, in der auch der VAU-Client arbeitet.
12.                     Ist das Request/Response-Byte gleich 2.
13.                     Hat der Response-Counter den von Client erwarteten Wert.
14.                     Ist die KeyID bekannt.

Ergibt eine der Prüfungen ein nicht-positives Ergebnis, MUSS der Client die Verarbeitung der Response abbrechen.
Er MUSS das Chiffrat mit dem mit der KeyID verbundenen Schlüssel K2_s2c_app_data mittels AES/GCM entschlüsseln und dabei den Header als "Additional Associated Data" in die Entschlüsselung mit einfließen lassen. Ergibt die Entschlüsselung das Symbol "FAIL", so MUSS er die Verarbeitung des Chiffrats/Response abbrechen.
[<=]

7.3 OIDC-Authentisierung eines Clients (Nutzer)

Bei den meisten ePA-Clients wird für die Authentisierung des Nutzers der OAuth2/OIDC/PKCE-Authentication-Workflow nach Etablierung der kryptographischen Phase des VAU-Protokolls verwendet.

Abbildung 7 : OAuth2/OIDC/PKCE-Authentisierung einer LEI am zentralen IDP der TI

D. h., der rein kryptographische Teil des VAU-Protokolls hat erfolgreich stattgefunden und zwischen ePA-Client und VAU-Instanz konnten zwei symmetrische Schlüssel in einer Form der Multi-Party-Computation zusammen berechnet werden. Eine einseitig authentisierte und vertrauliche Datenverbindung besteht zwischen ePA-Client und VAU-Instanz. Über diese Datenverbindung findet auf einer höheren OSI-Schicht eine Client-Authentisierung statt. Dafür werden vom Client innere HTTP-Requests über das VAU-Protokoll an die VAU-Instanz gesendet. Im OIDC Fall zwei Stück:

11.                     einmal wird ein Hashwert (die "Codechallenge") per GET bezogen und
12.                     als zweites wird ein "Authentication Code" per POST vom Client an die VAU-Instanz gesendet.

Mittels des Urspungsbilds der Codechallenge (Zufallswert erzeugt von der VAU-Instanz/ Input-Daten für die Hashwertberechnung) und dem AUTH-Code bezieht die VAU-Instanz ein Identity-Token vom IDP, in dem Identitätsangaben des Clients (KVNR oder Telematik-ID) stehen. Nach Prüfung und Analyse dieses Identity-Tokens kennt die VAU-Instanz die Client-Identität -- eine beidseitig authentisierte Datenverbindung steht ab dann bereit. Bevor dies erfolgt ist, darf eine VAU-Instanz keine zusätzliche Funktionalität (i. S. v. ePA-spezifische APIs) per innerer HTTP-Requests einem noch unauthentisierten Client verfügbar machen.

A_24634 - VAU-Protokoll: VAU-Instanz: notwendige Authentifizierung des VAU-Clients (Nutzers)

Eine VAU-Instanz MUSS sicherstellen, dass, solange der ePA-Nutzer noch nicht authentisiert ist, keine ePA-Funktionalität (ePA-spezifische APIs, die nicht zur weiteren Client-Authentisierung dienen) vom ePA-Client verwendbar sind (siehe Erläuterung vor A_24634-*). [<=]

A_25055 - VAU-Protokoll: OIDC Authentisierung oberhalb der VAU-Protokoll-Schicht

Eine VAU-Instanz MUSS für eine OIDC/OAuth2/PCKE notwendige HTTP Endpunkte per inneren HTTP-Request/Responses einem Client verfügbar machen (Codechallenge per GET zur Verfügung stellen, Authentication Code per POST vom Client empfangen) machen.

Nach erfolgreichen Authentisierung über OIDC MUSS die VAU-Instanz in den Metadaten der Verbindungsschlüssel (KeyID, K2_*_app_data) den neuen Authentisierungszustand vermerken (Rückwirkung auf A_24634-*).

Nach erfolgreicher Authentisierung über OIDC, genauer innerhalb des Response-Headers (innerer Request) nach dem POST-Request für den Authentication-Codes durch den Client, MUSS sie ein Nutzerpseudonym dem Client in der HTTP-Variable "VAU-NP" verfügbar machen, vgl. A_24770-*. [<=]

A_25143 - VAU-Protokoll: Abfrage aktueller Status der Nutzerauthentisierung

Eine VAU-Instanz MUSS über innere HTTP-Requests über den Pfadnamen /VAU-Status per HTTP-GET wie folgend aufgeführt Informationen über den Status der aktuellen VAU-Verbindung bereitstellen. Als Antwort MUSS eine VAU-Instanz eine JSON-Datenstruktur der folgenden Struktur senden (Reponse-Content-Type 'application/json'):

{  "VAU-Type": "epa",
   "VAU-Version" : "Version bspw. in der Form <Hersteller>-1.2.3.4p8",
   "User-Authentication" : "None | TID:<Telematik-ID> | KVNR:<KVNR> | GID:<Gesundheits-ID>",
   "KeyID": " ... in Hexadezimalform [0-9a-f] (kleinbuchstaben)",
   "Connnection-Start": "2024-01-16T10:08:42.123Z"
}

Bei "User-Authentication" steht entweder "None" falls noch keine erfolgreiche Nutzerauthentisierung stattgefunden hat, die Telematik-ID falls eine erfolgreiche Nutzerauthentisierung eines Nutzers, der eine Telematik-ID besitzt (bspw. LEI), die KVNR eines erfolgreich authentisierten Versicherten oder (in einer späteren Ausbaustufe) die Gesunheits-ID des erfolgreich authentisierten Nutzers.

In der Datenstruktur KÖNNEN weitere Daten (Key-Value-Paare) von der VAU-Instanz aufgeführt werden. Die maximale Größe der von der VAU-Instanz gesendeten Datenstruktur MUSS kleiner gleich 2 MiB sein.

Die Abfrage von /VAU-Status MUSS als "Aktivität" im Sinne von gemSpec_Aktensystem#A_25006-* gelten. [<=]

Erläuterung: Die Maximalgrößenangabe dient dazu, damit eine Primärsystem-Implementierung (ePA-Client) weiß welche Datengrößen es maximal akzeptieren können muss.

7.4 Authentisierung des E-Rezept-FD als ePA-Client

Bei der Authentisierung des E-Rezept-FD als ePA-Client wird nicht OIDC zur Client-Authentisierung verwendet, sondern folgendes einfaches Challenge/Response-Verfahren.

A_24658 - VAU-Protokoll: PKI-basierte Client-Authentisierung

Eine VAU-Instanz MUSS über einen inneren HTTP-Request zwei Operation wie folgt anbieten.

(1) Über den Pfadnamen /FrischeParameter MUSS die VAU-Instanz Daten per HTTP-GET bereitstellen.
Diese Daten sind eine base64-kodierte Zeichenkette. Der Media-Type (Context-Type) MUSS 'text/plain;charset=UTF-8' sein.
Die Zeichenkette ist für einen Client opak. Diese Zeichenkette MUSS es einer VAU-Instanz ermöglichen, zu ermitteln, ob und wann ein VAU-HSM oder die Befugnisverifikations-VAU (BV-VAU [gemSpec_Aktensystem#3.4 Befugnisverifikations-Modul], das/die mit der VAU-Instanz verbunden ist, diese Zeichenkette erzeugt hat (bspw. Unix-Zeit + ECDSA-Signatur HSM). Es MUSS sichergestellt sein, dass nur das VAU-HSM oder die BV-VAU, das/die mit der VAU-Instanz verbunden ist, den Frischeparameter erzeugt haben kann.

(2) Über den Pfadnamen /PKI-Aut MUSS sie die Möglichkeit anbieten, per HTTP-POST ein Authentisierungstoken an die VAU-Instanz zu senden.

Die Authentisierungstoken sind JWT [RFC-7519], deren Body wie folgt aufgebaut ist:
{
    "type" : "ePA-Authentisierung über PKI",
    "iat" : ...zeit...,
    "challenge" : Frischeparameter,
    "sub": ...Telematik-ID...
}
Im Header des JWT MUSS innerhalb eines x5c-Array das "signierende" Zertifikat enthalten sein. Bei "sub" trägt der Client/Nutzer seine Telematik-ID ein.

Die VAU-Instanz MUSS das vom Client gesendete Authentisierungstoken prüfen:

7. Ist das im Header aufgeführte "signierende" Zertifikat gültig, inkl. OCSP-Prüfung (vgl. OCSP-Response-Caching nach [gemSpec_PKI#A_23225]).
8. Ist die Signatur valide.
9. Stimmt der "sub"-Wert im Body mit der Telematik-ID im "signierenden" Zertifikat überein.
10.                     Ist die "iat"-Zeit nicht älter als 10 Minuten.
11.                     Ist die "challenge" vom VAU-HSM oder einer BV-VAU erzeugt worden.
12.                     Ist die challenge nicht älter als 10 Minuten.
13.                     Ist der "type" gleich "ePA-Authentisierung über PKI"

Bei Prüfung mit positivem Prüfergebnis MUSS die VAU-Instanz den neuen Authentisierungsstatus (bspw. E-Rezept-FD wurde authentifiziert) in den Metadaten den Verbindungsschlüssel (K2_c2s_app_data, K2_s2c_app_data) vermerken.

Im inneren HTTP-Response-Header MUSS die VAU-Instanz das Nutzerpseudonym (vgl. A_24770-*) übertragen.

Die VAU MUSS die Authentisierung beliebiger Nutzer mit gültigen AUT-Zertifikat und Telematik-ID darin erlauben (also nicht nur eingeschränkt auf den E-Rezept-FD). [<=]

Beim Frischeparameter soll sichergestellt werden, dass der Authentisierungsvorgang des Clients nicht zu alt ist. Dies muss auch das VAU-HSM bzw. die BV-VAU prüfen. Das Signaturmaterial, das die Challenge/Frischeparameter für die Prüfung im Aktensystem authentisiert, muss keinen Zusammenhang zu TI-PKI haben, da die Challenge vom Client als opakes Objekt behandelt wird (A_24771-*). D. h., nur das Aktensystem selbst (VAU, VAU-HSM, BV-VAU) selbst prüft die Challenge.

A_24959 - VAU-Protokoll: PKI-basierte Client-Authentisierung (VAU-HSM, BV-VAU)

Ein Aktensystem MUSS sicherstellen, dass bei der Prüfung der PKI-basierten Authentisierung (bspw. durch den E-Rezept-FD) die Prüfung des vom Client signierten JWT mindestens die Prüfschritte aus A_24658-* bei der Prüfung im VAU-HSM oder in der BV-VAU durchgeführt werden. Bei nicht-positiven Prüfergebnis MUSS das VAU-HSM oder die BV-VAU das JWT ablehnen -- die Client-Authentisierung beim VAU-HSM bzw. BV-HSM kann nicht stattfinden. [<=]

A_25192 - VAU-Protokoll: VAU-Instanz, zusätzliche TID-Prüfung E-Rezept-FD

Ein Aktensystem MUSS sicherstellen, dass in einer VAU-Instanz bei jeder Nutzer-Authentisierung (i. S. v. egal ob über A_24568-* oder A_25055-*) eines ePA-Nutzers, bei der der Nutzer die Telematik-ID "9-E_Rezept_Fachdienst" besitzt, prüft, ob das "authentisierende" EE-AUT-Zertifikat des Nutzers

1.   professionItem und professionOID gemäß [gemSpec_OID#GS-A_4446-*] oid_erp-vau und 1.2.276.0.76.4.258 als Attribute besitzt, und

2.   aus einer Komponenten-PKI-CA der TI-PKI stammt (vgl. Implementierungshinweis).

[<=]

Eine E-Rezept-VAU als ePA-Nutzer hat innerhalb eines Aktensystems besonders umfassende Zugriffsrechte. Als Risikomitigation wird bei einer Nutzerauthentisierung in einer ePA-VAU-Instanz überprüft, ob das AUT-Zertifikat der E-Rezept-VAU (als ePA-Nutzer) besondere Eigenschaft besitzt.

Implementierungshinweis:

Sowohl bei A_24568-* als auch bei A_25055-* wird eine auf dem EE-AUT-Zertifikat basierende Signatur vom Nutzer erzeugt. Solch eine Signatur muss eine ePA-VAU-Instanz im Rahmen der Nutzerauthentitfizierung prüfen, was auch die Prüfung des EE-AUT-Zertifikats inkludiert. Die TI-PKI besitzt genau drei Hierarchie-Ebenen: Root-Zertifikat, CA-Zertifikat, EE-Zertifikat. Es ist für die Prüfung A_25192-*#Punkt-2 ausreichend zu prüfen, ob das bestätigende CA-Zertifikat im CommonName mit "GEM.KOMP-CA" (anschließend kommt eine natürliche Zahl) beginnt und ob das CA-Zertifikat im Signatur-Graph Kind einer TI-PKI-Root ist. Beide Bedingungen sind technisch leicht zu prüfen, dennoch empfiehlt es sich innerhalb einer VAU-Instanz das Prüfergebnis zu cachen (Hashwert des AUT-Zertifikats + besondere-E-Rezept-Prüfung-OK).

A_24771 - VAU-Protokoll: E-Rezept als Client

Der E-Rezept-FD MUSS für die Authentisierung bei einer VAU-Instanz nach dem erfolgreichen Durchlaufen der VAU-Protokoll-Handshake-Phase den Mechanismus nach A_24658-* verwenden.

Dabei bezieht er zunächst eine Challenge/Frischeparameter nach A_24658-*. Diese MUSS er als opakes Objekt behandeln (also nicht versuchen, den Inhalt auszuwerten).

Anschließend MUSS er einen signierten JWT nach A_24658-* erzeugen und diese per HTTP-POST im inneren Request eine VAU-Protokoll-Verbindung an die VAU-Instanz senden. [<=]

Der E-Rezept-FD kann für die Datenübertragung zum Aktensystem folgendes Vorgehen wählen. Er verbindet sich initial einmal per VAU-Protokoll mit einer VAU-Instanz und verwendet den Mechanismus nach A_24658-* zur Authentisierung des E-Rezept-FD bei der VAU-Instanz. Hat dies erfolgreich stattgefunden, erhält der E-Rezept-FD als "normaler" ePA-Client ein Nutzerpseudonym (vgl. A_24770-*). Nun kann er mit diesem Nutzerpseudonym (A_24757-*) bspw. 50 neue TLS-Verbindungen zum Aktensystem eröffnen. Bezüglich des DoS-Schutzes am Aktensystem: an der IP-Adresse kann ein Aktensystem schon erahnen, dass es sich um den E-Rezept-FD handelt und so diese 50 Verbindungen auf IP-Ebene dem Client erlaubt (Perimeter/Firewall), was es bei anderen IP-Adressen evtl. nicht tut (Rate-Limiting). Innerhalb der neuen TLS-Verbindungen führt der E-Rezept-FD jeweils VAU-Protokoll-Verbindungsaufbauten plus Nutzerauthentisierung (A_24770-*) durch und ein Aktensystem kann "geeignet" (vgl. Abschnitt 7.5 Routing auf VAU-Instanzen) die Verbindungsaufbauten auf für das Aktensystem günstige VAU-Instanzen verteilen. Im Beispiel kann der E-Rezept-FD dann über 51 Datenkanäle parallel Rezeptinformationen für verschiedene Versicherte in deren Akten einbringen (Parallelverarbeitung).

7.5 Routing auf VAU-Instanzen

Für ein Aktensystem erleichtert es in bestimmten Konstellationen die Implementierung, wenn schon beim VAU-Protokoll-Verbindungsaufbau es Hinweise darüber gibt, um welche Client-Identität (i. S. v. Nutzer-Identität) es sich handelt. Dann kann eine Routing-Komponente des Aktensystems, die nach den HTTPS-Schnittstellen und vor den VAU-Instanzen liegt, die Requests "geeignet" auf die verschiedenen VAU-Instanzen verteilen. Was "geeignet" hier bedeutet, liegt in der Ausgestaltungshoheit des Aktensystemherstellers.

A_24770 - VAU-Protokoll: VAU-Instanz, Nutzerpseudonym erzeugen

Nach erfolgreicher Nutzer-Authentisierung des Clients MUSS die VAU-Instanz ein Nutzerpseudonym (NP) erzeugen. Dieses NP MUSS, im HTTP-Response-Header des inneren HTTP-Request unter dem Variablenname "VAU-NP" eingetragen werden und so an den Client übertragen werden. [<=]

Beispiel

VAU-NP: 1b4f0e9851971998e732078544c96b36c3d01cedf7caa332359d6f1d83567014

In A_24757-* ist definiert, dass ein VAU-Client solch ein Nutzerpseudonym bei seinen Requests für die Nachricht 1 im Handshake (VAU-Protokoll Verbindungsaufbau) im Request-Header im (äußeren) HTTP-Request aufführen muss und dass er auch eine Aktualisierung des Nutzerpseudonym nach erfolgreicher Nutzer-Authentisierung erkennen und sein lokal gespeichertes Nutzerpseudonym aktualisieren muss.

A_25150 - VAU-Protokoll: VAU-Instanz, Nutzerpseudonym regelmäßig wechseln

Ein Aktensystem MUSS sicherstellen, dass ein Nutzerpseudonym nach maximal 2 Monaten gewechselt wird, i. S. v. nach erfolgreicher Authentisierung von Entität A wird NP_1 an den Client zurückgegeben (A_24770-*) nach etwas mehr als zwei Monaten authentisiert sich A erneuert und erhält NP_2, dann MUSS NP_1 ungleich NP_2 sein. Die bloße Kenntnis von NP_1 und NP_2 DARF NICHT erkennen lassen, dass diese beide Pseudonyme zur gleichen Entität gehören oder gar zu A gehören.
(vgl. Implementierungshinweis). [<=]

Implementierungshinweis zu A_25150:

Eine mögliche Herangehensweise für A_25150-* ist, dass alle VAU-Instanzen Zugriff auf einen geheimen Pseudonymisierungsschlüssel für die Pseudonymerstellung haben. Dieser Schlüssel liegt nicht notwendiger Weise ausschließlich im HSM, sondern kann beim Start der  VAU-Instanz in diese sicher geladen werden und im sicheren Speicher der VAU-Instanz verbleiben. Der Schlüssel wird alle zwei Monate Aktensystemweit gewechselt. Nach erfolgreicher Authentisierung wird mit dem Entitäts-ID (bspw. KVNR) ein HMAC(K=<Schlüssel>, text=<KVNR>) erzeugt. Dieser berechnete HMAC-Wert ist dann das NP.

Routingentscheidung

Es gibt wenige Fälle, in denen aufgrund von fehlenden Informationen eine Routing-Entscheidung im Aktensystem nicht optimal getroffen werden konnte. In diesen Fällen darf ein Aktensystem das Neuverbinden des Client einfordern. Ein solcher Fall ist bspw., wenn eine Arztpraxis auf einem PVS-Rechner eine Akte aktuell in Verwendung hat. Und auf einem "neuen" PVS-Rechner/Tablet etc., der noch nie mit dem Aktensystem in Kontakt stand -- also lokal noch kein Nutzerpseudonym gespeichert hat (vgl. A_24757-*), eine Akte verwenden möchte. Auf dem neuen PVS-Rechner würde dann ein VAU-Protokoll-Verbindungsaufbau und Nutzer-Authentisierung stattfinden. Mit hoher Wahrscheinlichkeit landet diese Verbindung in einer anderen VAU-Instanz. Dies würde dann erkannt und A_24772-* kann vom Aktensystem ausgelöst werden. Der "neue" PVS-Rechner würde sich neu verbinden, diesmal mit ihm bekanntem Nutzerpseudonym. Das Aktensystem kann dann eine für sich günstigere Routing-Entscheidung treffen. Das Aktensystem ist frei in der Entscheidung, ob und bei welchen Konstellationen es von dieser Möglichkeit Gebrauch macht.

A_24772 - VAU-Protokoll: Restart für Änderung der Routingentscheidung

Ein ePA-Aktensystem KANN nach erfolgreicher Authentisierung des ePA-Clients (i. S. v. Nutzer-Authentisierung) folgende Retry-Nachricht senden:
{
    "MessageType" : "Restart",
    "KeyID" : ... KeyID ...
}

Genauer: die Nutzer-Authentisierung hat erfolgreich stattgefunden, und bei dem nächsten Request des Clients KANN ein Aktensystem die Restart-Nachricht als Antwort (Response) auf den Request des Clients senden.

Diese Datenstruktur MUSS per CBOR [CBOR] serialisiert und die erzeugte Kodierung unter Verwendung des Media-Type 'application/cbor' (HTTP Content-Type) an den ePA-Client im äußeren HTTP zurückgesendet werden.  [<=]

A_24773 - VAU-Protokoll: Clients: Neustart/Wiederholung des Verbindungsaufbaus

Ein VAU-Client MUSS Restart-Nachrichten nach A_24772-* verarbeiten können, und bei Erhalt einer solchen Nachricht die aktuelle VAU-Protokoll-Verbindung, die mit der aufgeführten KeyID verbunden ist, beenden, indem es die mit der KeyID verbundenen symmetrischen Schlüssel sicher löscht. Anschließend MUSS es einen neuen VAU-Protoll-Verbindungsaufbau durchlaufen (inkl. Nutzer-Authentisierung gegenüber der VAU-Instanz). [<=]

7.6 Fehlersignalisierung

A_24635 - VAU-Protokoll: VAU-Instanz und Aktensystem: Erzeugung von Fehlermeldungen

Eine VAU-Instanz MUSS das Auftreten von Fehlern bei der Abarbeitung des VAU-Protokolls an das "äußere" Aktensystem melden. Daraufhin MUSS das Aktensystem an der HTTPS-Schnittstelle den Client-Request in folgender Weise mit einer Fehlermeldung beantworten:

Als HTTP-Response-Code MUSS das Aktensystem einen HTTP-Fehlercode (i. S. v. eben nicht 200) in der äußeren HTTP-Response verwenden (siehe folgende Tabelle). Es MUSS weiterhin eine Datenstruktur der folgenden Art erzeugen:
{
            "MessageType" : "Error",
            "ErrorCode" : ...natürliche-Zahl...,
            "ErrorMessage" : "... Menschenlesbarer Text bzw. Fehlerursache ..."
} 
Diese Datenstruktur MUSS es per CBOR [CBOR] serialisieren und per Mime-Type "application/cbor" [RFC-CBOR] (HTTP Content-Type) im äußeren Response-Body aufführen.

Ein Aktensystem KANN weitere selbst definierte Variablen-Werte-Paare in der o. g. Datenstruktur aufführen.

Folgende Fehler-Meldungen MUSS es mindestens geben:
 

HTTP-Error	ErrorCode	ErrorMessage / Beschreibung
400	1	"Decoding Error" Fehler in einer Kodierung bspw. der CBOR-Kodierung
400	2	"Missing Parameters" notwendige Datenfelder bspw. in der Handshake fehlen
403	3	"GCM returns FAIL" Eine AES/GCM-Entschlüsselung ergibt das Symbol "FAIL".
403	4	"PU/nonPU Failure"
403	5	"Transscript Error" Im Handshake wird Ungleichheit zwischen den beiden Transskript-Hashwerten festgestellt.
400	6	"bad format: extended ciphertext" Die erste Sanity-Prüfung des erweiterten Chiffrat bspw. bei A_24630 schlägt fehl.
403	7	"is not a request" A_24630 (Prüfschritt 3)
403	8	"unknow KeyID"
403	9	"unknown CID"

[<=]

A_24767 - VAU-Protokoll, Fehlerverarbeitung im VAU-Client

Ein VAU-Client MUSS die Fehlermeldungen nach A_24635-* verarbeiten können. [<=]

7.7 Tracing in Nichtproduktivumgebungen

Für die Fehlersuche in Nichtproduktivumgebungen -- insbesondere bei IOP-Problemen zwischen Produkten verschiedener Hersteller in einer fortgeschrittenen Entwicklungsphase -- hat es sich als notwendig erwiesen, dass ein Fehlersuchender den Klartext der Kommunikation zwischen ePA-Client und VAU-Instanz mitlesen kann, vgl. [gemSpec_Aktensystem#5.8. Tracing in Nichtproduktivumgebungen].

Bei ePA für alle unterscheidet sich der Mechanismus hier im Vergleich zu ePA 2.x ein wenig: Es werden nicht für den Client feste ECDH-Schlüssel für die Schlüsselaushandlung im VAU-Protokoll in Nichtproduktivumgebungen vorgegeben, sondern der Client wird verpflichtet, die ausgehandelten symmetrischen Sitzungsschlüssel (K2_c2s_app_data, K2_s2c_app_data) im äußeren HTTP-Request im Request-Header aufzuführen. Die Motivation dafür ist, dass es bei einigen Krypto-Bibliotheken ggf. schwieriger sein kann, den Zufall, der bei der KEM-Encapsulation-Operation einfließt, fest vorzugeben. Es erleichtert also die Implementierbarkeit. Am Chiffrat kann eine VAU-Instanz sicher feststellen, für welche Umgebung ein Client ein Chiffrat erzeugt hat. Ein VAU-Instanz lehnt in der Produktivumgebung dann solche Nichtproduktivumgebungs-Chiffrate ab.

A_24477 - VAU-Client, Nichtproduktivumgebung, Offenlegung von symmetrischen Verbindungsschlüsseln

Ein VAU-Client in einer Nichtproduktivumgebung MUSS nach einer erfolgreichen Schlüsselaushandlung mit dem VAU-Protokoll die ausgehandelten symmetrischen Schlüssel K2_c2s_app_data und K2_s2c_app_data base64-kodiert innerhalb einer HTTP-Request-Header-Variable "VAU-nonPU-Tracing" bei jedem äußeren HTTP-Request aufführen. Dabei sind die beiden Base64-kodierten Schlüsselwerte durch Leerzeichen zu trennen. Beispiel:
    VAU-nonPU-Tracing: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE=

Als erstes ist der Wert von Schlüssel K2_c2s_app_data aufzuführen, als zweiter Wert ist der Wert von Schlüssel K2_s2c_app_data aufzuführen. [<=]

Hinweis: Ebenfalls muss ein VAU-Client nach A_24628-* im Chiffrat kennzeichnen, ob es eine Nachricht in einer Nichtproduktivumgebung ist oder nicht.

A_24478 - VAU-Instanz, Nichtproduktivumgebung, Ablehnung von nonPU-Chiffraten in der PU

Ein Aktensystem in der Produktivumgebung MUSS äußere HTTPS-Request, die im Request-Header eine Variable "VAU-nonPU-Tracing" enthalten, mit einer HTTP-Fehlermeldung 403-Forbidden beantworten. Das Aktensystem MUSS sicherstellen, dass der innere Request (Chiffrat im Request-Body des äußeren Requests) keine VAU-Instanz erreicht.
Eine VAU-Instanz in der Produktivumgebung, die am Chiffrat am nonPU/PU-Byte erkennt (vgl. A_24628-*), dass es sich um ein nonPU-Chiffrat handelt, MUSS den Request mit einer Fehlermeldung an die äußere Schicht des Aktensystems (Webschnittstelle) beantworten. Die VAU-Instanz MUSS sicherstellen, dass das Chiffrat nicht entschlüsselt und das Chiffrat in der VAU-Instanz sicher gelöscht wird. [<=]

7.7.1 Zufallsquelle für Clients

A_24921 - ePA-Aktensystem, Random-Operation

Ein Aktensystem MUSS an seiner äußeren HTTPS-Schnittstellen eine Random-Operation, wie in A_21215-* definiert, zur Verfügung stellen. [<=]

Erläuterung: Auf einem Linux-Server ist es ausreichend, Daten aus /dev/urandom zu verwenden.

8 Post-Quanten-Kryptographie (informativ)

Wie in [BSI-PQC-2020] dargestellt, erscheint es mit Blick auf dem aktuellen Stand von Wissenschaft und Technik als sehr unwahrscheinlich, dass aktuell Quanten-Computer in ausreichender Leistungsstärke verfügbar sind, die der asymmetrischen Kryptographie -- so wie sie aktuell in der TI eingesetzt wird -- gefährlich werden könnten.

Dies bedeutet, dass insbesondere Authentisierungsvorgänge, die im "Jetzt" mit klassischen asymmetrischen kryptographischen Verfahren mit ausreichend großen Schlüssellängen durchgeführt werden (vgl. [SOG-IS-2020] und [BSI-TR-03116-1]), nicht in Frage stehen.

Schwieriger wird es mit der Verschlüsselung mit klassischen asymmetrischen Verfahren bei denen Chiffrate erzeugt werden, die ein Angreifer sammeln kann, und durch deren Entschlüsselung zu einer Zeit in der Zukunft, bei der solche Quanten-Computer verfügbar sind, dann Schaden entstehen kann ("harvest now, decrypt later").

Dort erscheint es ratsam auf hybride Lösungen zu migrieren. D. h., etablierte kryptographische asymmetrische Verfahren und post-quantum-sichere asymmetrische kryptographische Verfahren werden in einer Weise kombiniert, dass wenn genau nur eines der beiden Verfahren gebrochen wird, die Sicherheit (Vertraulichkeit und Integrität) der verschlüsselten Daten nicht gefährdet ist.

Aktuell gibt es diesbezüglich verschiedene Forschungsaktivitäten und Vorschläge für eine entsprechende hybride Protokoll-Erweiterungen von kryptographischen Protokollen wie TLS, IKE oder SSH [TLS-CC-2021], [ENISA-PQC-2021#6.1]. Die gematik beobachtet intensiv die laufenden Forschungs- und Evaluierungsaktivitäten [NIST-PQC] die voraussichtlich 2023/242024 einen geeigneten Stand erreichen werden. Bei TI-spezifischen Protokollen (VAU-Protokoll, SGD-Protokoll) evaluiert die gematik aktuell PQC-Protokollerweiterungen die kryptographisch denen bei TLS [TLS-CC-2021] entsprechen (vgl. Abschnitt "")Beim VAU-Protokoll für ePA für alle wird bereits eine PQC-sichere Schlüsselaushandlung auf Basis von [KEM-TLS] und [IETF-Hybrid-PQC] eingesetzt. D. h., Anwendungsdaten zwischen ePA-Clients und ePA-VAU sind beim Transport bereits PQC-sicher. In einer nächsten Ausbaustufe verwendet der E-Rezept-Projekt ebenfalls diese VAU-Protokollvariante für die Verbindung zwischen E-Rezept-Client und E-Rezept-VAU.

Bei Messengern [PQC-Hybrid-Signal] oder bei Web-Browsern [PQC-Hybrid-Chrome] nimmt die Verwendung von PQC-sicheren Hybrid Verfahren immer mehr zu. Es ist absehbar, dass dieses Vorgehen bald generell der Stand der Technik ist.

9 Erläuterungen (informativ)

9.1 Prüfung auf angreifbare (schwache) Schlüssel

Im Folgerelease wird es in diesem Abschnitt Hinweise für die Anforderungen aus Abschnitt 2.4.1 Prüfung auf angreifbare (schwache) Schlüssel geben.

9.2 RSA-Schlüssel in X.509-Zertifikaten

In anderen, nicht-TI Public-Key-Infrastrukturen werden öffentliche Schlüssel bei einer Zertifikatsantragsstellung immer mittels ihrem korrespondieren privaten Schlüssel signiert (vgl. Certificate Signing Request [RFC-2986], proof of posession). Dort kann der TSP sich nach einer erfolgreichen Signaturprüfung sicher sein, dass er aus Kodierungssicht den "richtigen" Schlüssel in den Händen hält, weil ansonsten die Signaturprüfung mit praktischer Sicherheit fehlschlägt. Missverständnisse aufgrund von "falscher" Byte-Order oder verschiedener Kodierung sind somit praktisch (Falsch-Positiv-Rate < 2-100) ausgeschlossen. In der PKI der TI werden mehr als 95 % aller Zertifikatserstellungen ohne eine Signatur mittels der jeweiligen privaten Schlüssel durchgeführt. Ein TSP der TI kann damit bei RSA-Schlüsseln – aus den Schlüsselwerten an sich – im Regelfall nicht sicher erkennen, ob eine Fehlkodierung (Missverständnis zwischen Zertifikatsantragssteller und TSP) aufgetreten ist. Es gibt effiziente Möglichkeiten solche Fehlkodierungen zu erkennen. Den Einsatz solcher Möglichkeiten möchte die gematik befördern und gibt mit   und zwei Verfahren als KANN-Anforderungen an. 

Die Untersuchungen aus [MK-2016] und [ROCA-2017] zeigen, dass es hilfreich ist sich mit den konkreten Werten der RSA-Schlüssel zu beschäftigen. Die folgenden Verfahren nutzen Struktureigenschaften von RSA-Schlüsseln, die nicht-RSA-Schlüssel im Normalfall nicht vorweisen. 

keine kleinen Primteiler:

Der Modulus eines RSA-Schlüssels muss aus genau zwei (oder wenigen [RFC-8017]) "großen" Primfaktoren bestehen. Falls der vom TSP angetroffene Wert durch eine vom TSP vorgegebene Primzahl teilbar ist, so ist der RSA-Schlüssel ungeeignet. Falls dieser Primteiler deutlich kleiner als 2^1023 ist, so kann es sich nicht um einen korrekten RSA-Schlüssel handeln.

Wird ein Modulus unabsichtlich von einem Sender falsch kodiert, so ist der dadurch entstehende Wert statistisch über alle möglichen Fehlkodierungen betrachtet im Normalfall mit der Wahrscheinlichkeit von 1/2 durch zwei teilbar, mit der Wahrscheinlichkeit von 1/3 durch 3 teilbar, mit einer Wahrscheinlichkeit von 1/5 durch 5 teilbar usw. Falls man nun den Modulus durch die ersten Primzahlen kleiner als 100 (25 Primzahlen) versucht zu teilen (was effizient möglich ist) und eine Teilbarkeit ausschließen kann, so kann man eine unabsichtliche Fehlkodierung mit einer hohen Wahrscheinlichkeit erkennen.

In der gematik wurden mehr als eine Billion (10^12) RSA-Schlüssel zufällig erzeugt und verschiedene Fehlkodierungen dieser Schlüssel auf Primteiler kleiner 100 untersucht. Es wurden dabei folgende Erkennungsraten festgestellt.

Art der Fehlkodierung	Erkennungsrate in Prozent  (auf zwei Nachkommastellen gerundet)
Byte-Order falsch (vertauscht)	76,03 %
Off-by-One (left shift)	100 %
Off-by-One (right shift)	88,07 %
Base64-kodiert anstatt Binär	87,60 %
Base58-kodiert anstatt Binär	88,01 %
Hex-kodiert anstatt Binär	87,91 %

Man muss davon ausgehen, dass die entsprechende Fehlkodierung nicht nur bei einem einzigen RSA-Schlüssel, sondern bei allen RSA-Schlüsseln eines Personalisierungsauftrags auftritt. Somit nähert sich die Erkennungsrate exponentiell 100 % an. Beispiel: bei einer Erkennungsrate von 75 % für eine bestimmte Art der Fehlkodierung (vgl. Tabelle) erhält man bei 1000 RSA-Schlüsseln in Gesamtheit eine Erkennungsrate von mehr als 1-1,15*10^-125, also nahe 1.

öffentlicher Exponent ist prim:

Sei e der öffentliche Exponent und n der Modulus eines RSA-Schlüssels. Bei der Wahl von e ist es notwendig, dass dieser relativ prim zu phi(n) ist. Um die Schlüsselerzeugung zu vereinfachen (und zu beschleunigen), wählen jedoch faktisch alle kryptographischen Softwarebibliotheken, Chipkarten und HSMs e prim. Wenn also dem TSP ein e vorliegt, das nicht prim ist, so kann er davon ausgehen, dass ein Fehler vorliegt.

Diese Überlegungen führen zu den Tests in  . Diese Tests haben eine Falsch-Positiv-Rate von 0 und benötigen weniger als 7 Mikrosekunden pro RSA-Schlüssel.

Entropie der Schlüsselkodierung:

Der Modulus eines RSA-Schlüssels muss aus genau zwei (oder wenigen [RFC-8017]) "großen" zufällig gewählten Primfaktoren bestehen. Diese zufällige Wahl hat zur Folge, dass die Entropie der kodierten Schlüsselwerte eine hohe Entropie im Sinne von notwendigen Bits pro Byte besitzt. Eine Fehlkodierung wird evtl. weniger Entropie (Bits pro Byte) besitzen, weil sie, wie die base64-Kodierung, bestimmte Bits immer auf 0 setzt. In [NIST-SP-800-22] werden verschiedene Tests spezifiziert, um die "Zufälligkeit" einer Zeichenfolge zu bestimmen. Diese Tests zielen auf größere Datengrößen (Längen der Zeichenfolge) ab und sind nur teilweise dafür geeignet die Kodierung von 256 Byte langen RSA-Moduli zu bewerten. Anstatt diese Tests als Basis zu verwenden, wird im Folgenden die klassische Berechnung der Shannon-Entropie vieler RSA-Moduli in unterschiedlichen Kodierungsformen betrachtet. Von einer Zeichenkette X wird mittels 

die Entropie im Sinne von notwendigen Bits pro Byte des kodierten Schlüsselwertes berechnet. Dabei ist X die Kodierung (Bytefolge) des Schlüssels und pi die relative Häufigkeit von Byte i (wobei nach Konvention in dem Kontext gilt: log(0)=0).

Unter https://rosettacode.org/wiki/Entropy findet man Implementierung dieser Entropie-Berechnungsfunktion in 78 Programmiersprachen. 

Die gematik verwendet folgende C-Implementierung:

double entropy(char *S, int len) {
        int table[256]={0};
        int i;
        double H=0;

        for(i=0; i<len; i++) {
            table[(unsigned char)S[i]]++;
        }
        for(i=0; i<256; i++) {
            if (table[i]>0) {
                H-= (double) table[i]/len*log2( (double) table[i]/len);
            }
        }
        return H;
}

In der gematik wurden mehr als eine Billion (10^12) RSA-Schlüssel zufällig erzeugt und verschiedene Fehlkodierungen auf ihre Entropie (notwendigen Bits pro Byte in der Kodierung) untersucht.

Ein Histogramm eines Beispiel-Testlaufs mit mehr als eine Billion (10^12) RSA-Schlüsseln:

8    >=H(X)>7,455	3396
7,455>=H(X)>7,2135	234195871140
7,2135>=H(X)>6,9715	765693789112
6,9715>=H(X)>6,7295	112336352

Es wurde kein Schlüssel gefunden, dessen korrekte Kodierung eine Entropie kleiner als 6,7295 besitzt.

Ein Histogramm eines Beispiel-Testlaufs mit mehr 10 Milliarden (1*10^10) Schlüsseln (diese wurden jeweils in unterschiedlichen Kodierungsvarianten kodiert und danach wurde die entropy()-Funktion auf die Kodierung angewendet):

korrekt kodiert (s. o.) 7.40 49808 7.30 97418682 7.20 3351624284 7.10 6095663118 7.00 1210930726 6.90 43696816 6.80 256390 6.70 176

Base64-kodiert 5.90 9981660 5.80 6902282798 5.70 3861576302 5.60 25792616 5.50 6624

Base58-kodiert 5.80 11220 5.70 4102181822 5.60 6615817484 5.50 81606244 5.40 23230

als Hexadezimal-Zahl kodiert 3.90 10758804076 3.80 40835572 3.70 352

Diese Überlegungen bezüglich der Entropie der RSA-Schlüsselkodierung führen zu dem Test in . Dieser Test hat eine Falsch-Positiv-Rate von weniger als 2^-40 und benötigen weniger als 7 Mikrosekunden pro RSA-Schlüssel. 

10 Anhang – Verzeichnisse

10.1 Abkürzungen

Kürzel	Erläuterung
BS	betreiberspezifischer Schlüssel
C2C	Card to Card
C2S	Card to Server
CEK	Content Encryption Key
CA	Certificate Authority
CBC	Cipher Block Chaining
DNS	Domain Name System
DNSSEC	Domain Name System Security Extensions
DRNG	Deterministic Random Number Generator
eGK	elektronische Gesundheitskarte
HKDF	HMAC-based Extract-and-Expand Key Derivation Function
HMAC	Hash-based Message Authentication Code
IV	Initialization Vector (Initialisierungsvektor) bspw. bei AES-GCM
ICV	Integrity Check Value, Authentisierungswert (MAC) bei AES-GCM
KDF	Key Derivation Function (Schlüsselableitungsfunktion)
MAC	Message Authentication Code
OCSP	Online Certificate Status Protocol
OID	Object Identifier
OSI	Open Systems Interconnection
SAK	Signaturanwendungskomponente
SGD	Schlüsselgenerierungsdienst
SE	Secure Element
SM	Service Monitoring
TCB	Trusted Computing Base
TI	Telematikinfrastruktur
TLS	Transport Layer Security
TPM	Trusted Plattform Module
TSIG	Transaction Signature
URI	Uniform Resource Identifier
VAU	vertrauenswürdige Ausführungsumgebung, vgl. [gemSpec_DokumentenverwaltungAktensystem_ePAfuerAlle]
WANDA Basic	Weitere Anwendungen für den Datenaustausch ohne Nutzung der TI oder derer kryptografischen Identitäten

10.2 Glossar

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

10.3 Abbildungsverzeichnis

Abbildung 1: Verwendung von Algorithmen nach Zonen und OSI-Schicht

Abbildung 2: ASN.1-Kodierung des Chiffrats was den Transportschlüssel enthält

Abbildung 3: Übersicht über das VAU-ProtokollSicherungsschichten beim Datentransport zwischen E-Rezept-Client und E-Rezept-VAU

Abbildung 4: Sicherungsschichten beim Datentransport zwischen E-RezeptePA-Client und E-RezeptePA-VAU-Instanz

Abbildung 5: OSI-Schichten in einem Aktensystem

Abbildung 6: KEM-TLS Verbindungsaufbau [KEM-TLS]

Abbildung 7 : OAuth2/OIDC/PKCE-Authentisierung einer LEI am zentralen IDP der TI

10.4 Tabellenverzeichnis

Tabelle 1: Tab_KRYPT_001 Übersicht über Arten von X.509-Identitäten

Tabelle 2: Tab_KRYPT_002 Algorithmen für X.509-Identitäten zur Erstellung nicht-qualifizierter Signaturen für die Schlüsselgeneration „RSA“

Tabelle 3: Tab_KRYPT_002a Algorithmen für X.509-Identitäten zur Erstellung nicht-qualifizierter Signaturen für die Schlüsselgeneration „ECDSA“

Tabelle 4: Tab_KRYPT_003 Algorithmen für X.509-Identitäten zur Erstellung qualifizierter elektronischer Signaturen für die Schlüsselgeneration „RSA“

Tabelle 5: Tab_KRYPT_003a Algorithmen für X.509-Identitäten zur Erstellung qualifizierter Signaturen für die Schlüsselgeneration „ECDSA“

Tabelle 6: Tab_KRYPT_006 Algorithmen für CV-Zertifikate

Tabelle 7: Tab_KRYPT_007 Algorithmen für CV-CA-Zertifikate

Tabelle 8: Tab_KRYPT_008 Beispiele für solche Algorithmen-URIs

Tabelle 9: Tab_KRYPT_009 Algorithmen für die Erzeugung von nicht-qualifizierten elektronischen XML-Signaturen

Tabelle 10: Tab_KRYPT_010 Algorithmen für qualifizierte XML-Signaturen

Tabelle 11: Tab_KRYPT_012 Algorithmen für Card-to-Server-Authentifizierung

Tabelle 12: Tab_KRYPT_017 Algorithmen für DNSSEC

Tabelle 13: Tab_KRYPT_018 Ablauf zur Berechnung eines versichertenindividuellen Schlüssels

Tabelle 14: Tab_KRYPT_019 eingesetzte Algorithmen für die Ableitung eines versichertenindividuellen Schlüssels

Tabelle 15: Tab_KRYPT_020 Algorithmen für die Erzeugung und Prüfung von binären Daten im Kontext von Dokumentensignaturen

Tabelle 16: Tab_KRYPT_021 Algorithmen für die Erzeugung und Prüfung von PDF/A-Dokumentensignaturen

Tabelle 17: Tab_KRYPT_ERP_Zertifikatsliste Definition Datenstruktur Zertifikatsliste

Tabelle 18: Tab_KRYPT_ERP_Algorithmus_FD_Zertifikatsliste_erstellen

Tabelle 19: Tab_KRYPT_ERP_FdV_Truststore_aktualisieren

Tabelle 20: Tab_KRYPT_ERP_OCSP_Liste Definition Datenstruktur OCSPList

Tabelle 21: Tab_KRYPT_ERP Kodierung des Chiffrats aus A_20161-*

Tabelle 22: Tab_KRYPT_VAUERR Auftretende Fehler bei auf Anwendungsschicht kryptographisch gesicherten VAU-Kommunikation (E-Rezept)

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.

[Quelle]	Herausgeber: Titel
[gemGlossar]	gematik: Glossar der Telematikinfrastruktur
[gemSpec_COS]	gematik: Spezifikation des Card Operating System (COS)
[gemSpec_Dokumentenverwaltung]		gematik: Spezifikation ePA-Dokumentenverwaltung
[gemSpec_DS_Anbieter]	Spezifikation Datenschutz- und Sicherheitsanforderungen der TI an Anbieter
[gemSpec_eGK_ObjSys]	gematik: Die Spezifikation der elektronischen Gesundheitskarte (eGK) – Objektsystem
[gemSpec_KT]	gematik: Spezifikation eHealth-Kartenterminal
[gemSpec_MobKT]	gematik: Spezifikation Mobiles Kartenterminal
[gemSpec_SGD_ePA]	gematik: Spezifikation Schlüsselkommentierungsdienst ePA
[gemSpec_SST_FD_VSDM]	gematik: Schnittstellenspezifikation Fachdienste (UFS/VSDD/CMS)
[gemSpec_Zugangsgateway_Vers]		gematik: Spezifikation Zugangsgateway des Versicherten ePA

10.5.2 Weitere Dokumente

[Quelle]	Herausgeber (Erscheinungsdatum): Titel
[ABR-1999]	DHIES: An Encryption Scheme Based on the Diffie–Hellman Problem Abdalla, Michel and Bellare, Mihir and Rogaway, Phillip, 1999 http://web.cs.ucdavis.edu/~rogaway/papers/dhies.pdf
[AIS-20-1999]	W. Schindler: Functionality Classes and Evaluation Methodology for Deterministic Random Number Generators. Version 1.0, 02.12.1999, ehemalige mathematisch technische Anlage zur AIS20, https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Zertifierung /Interpretation/AIS20_Functionality_Classes_Evaluation_Methodology_ DRNG.pdf?__blob=publicationFile
[AIS-20]	AIS 20: Funktionalitätsklassen und Evaluationsmethodologie für deterministische Zufallszahlengeneratoren, Version 3, 15.05.2013, https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifierung/Interpretation /AIS_20_pdf.pdf?__blob=publicationFile
[AIS-31]	AIS 31: Funktionalitätsklassen und Evaluationsmethodologie für physikalische Zufallszahlengeneratoren, Version 3, 15.05.2013, http://www.bsi.bund.de/SharedDocs/Downloads/DE/BS/Zertifierung/Interpretationen/ AIS_31_pdf.pdf?__blob=publicationFile
[ALGCAT]	Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung (Übersicht über geeignete Algorithmen), Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen, vom 30.12.2016 (auch online verfügbar: https://www.bundesanzeiger.de mit dem Suchbegriff „BAnz AT 30.12.2016 B5“)
[ANSI-X9.31]	National Institute of Standards and Technology, NIST-Recommended Random Number Generator Based on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES and AES Algorithms, January 31, 2005.     http://csrc.nist.gov/groups/STM/cavp/documents/rng/931rngext.pdf
[ANSI-X9.62]	ANSI X9.62:2005 Public Key Cryptography for the Financial Services Industry, The Elliptic Curve Digital Signature Algorithm (ECDSA)
[ANSI-X9.63]	American National Standard for Financial Services X9.63–2001 Public Key Cryptography for the Financial Services Industry Key Agreement and Key Transport Using Elliptic Curve Cryptography
[Boyd-Mathuria-2003]	Protocols for Authentication and Key Establishment, Colin Boyd and Anish Mathuria, 2003
[BrainPool]	ECC Brainpool Standard Curves and Curve Generation v. 1.0 19.10.2005 http://www.teletrust.de/fileadmin/files/oid/oid_ECC-Brainpool-Standard-curves-V1.pdf
[Breaking-TLS]	Lucky Thirteen: Breaking the TLS and DTLS Record Protocols Nadhem J. AlFardan and Kenneth G. Paterson Information Security Group, Royal Holloway, University of London, Egham, Surrey TW20 0EX, UK, 6th February 2013
[BreakingXMLEnc]	How to Break XML Encryption, Tibor Jager, Juraj Somorovsky, 2011 http://www.nds.rub.de/media/nds/veroeffentlichungen/2011/10/22/HowToBreakXMLenc.pdf
[BSI-PQC-2020]	Migration zu Post-Quanten-Kryptografie, Handlungsempfehlungen des BSI, Stand: August 2020, https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Krypto/Post-Quanten-Kryptografie.pdf?__blob=publicationFile&v=2
[BSI-TR-02102-1]	BSI TR-02102-1 Technische Richtlinie „Kryptographische Verfahren: Empfehlungen und Schlüssellängen“ Version 2023-01 https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html
[BSI-TR-02102-2]	BSI TR-02102-2 Technische Richtlinie „Kryptographische Verfahren: Empfehlungen und Schlüssellängen, Teil 2 – Verwendung von Transport Layer Security (TLS), Version 2023-01 https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.html
[BSI-TR-02102-3]	BSI TR-02102-3 Technische Richtlinie „Kryptographische Verfahren: Empfehlungen und Schlüssellängen, Teil 3 – Verwendung von Internet Protocol Security (IPsec) und Internet Key Exchange (IKEv2)“ Version 2023-01 https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-3.html
[BSI-TR-03111]	Technical Guideline BSI TR-03111 Elliptic Curve Cryptography, Version 2.10, Date: 2018-06-01 https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03111/TR-03111_node.html
[BSI-TR-03116-1]	Technische Richtlinie BSI TR-03116-1 Kryptographische Vorgaben für Projekte der Bundesregierung, Version: 3.20, Fassung September 2018, 21.09.2018 https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03116/BSI-TR-03116.html   Die Technische Richtlinie befindet sich aktuell in der Überarbeitung. Sobald die Überarbeitung der TR-03116-1 erfolgt ist, wird die Referenz auf die neue Version der TR-03116-1 hier aktualisiert.
[CM-2014]	20 Years of SSL/TLS Research, An Analysis of the Internet’s Security Foundation, Christopher Meyer, 9. February 2014 http://www-brs.ub.ruhr-uni-bochum.de/netahtml/HSS/Diss/MeyerChristopher/diss.pdf
[eIDAS]	Verordnung (EU) Nr. 910/2014 des europäischen Parlaments und des Rates vom 23. Juli 2014 über elektronische Identifizierung und Vertrauensdienste für elektronische Transaktionen im Binnenmarkt und zur Aufhebung der Richtlinie 1999/93/EG
[ecma-262]	JSON Standard https://www.ecma-international.org/publications/standards/Ecma-262.htm
[EN-14890-1]	DIN EN 14890-1:2008 Application Interface for smart cards used as Secure Signature Creation Devices - Part 1: Basic services
[ENISA-PQC-2021]	Post-Quantum Cryptography: Current state and quantum mitigation, European Union Agency for Cybersecurity (ENISA), May 2021, https://www.enisa.europa.eu/publications/post-quantum-cryptography-current-state-and-quantum-mitigation
[ETSI-CAdES]	ETSI TS 101 733 V1.7.4 (2008-07), Electronic Signatures and Infrastructures (ESI); CMS Advanced Electronic Signatures (CAdES)
[ETSI_TS_102_231_v3.1.2]	ETSI (Dezember 2009): ETSI Technical Specification TS 102 231 (‘Provision of harmonized Trust Service Provider (TSP) status information’) – Version 3.1.2
[ETSI-XAdES]	ETSI TS 101 903 V1.4.2 (2010-12), Electronic Signatures and Infrastructures (ESI); XML Advanced Electronic Signatures (XAdES)
[FIPS-180-4]	Federal Information, Processing Standards Publication 180-4, Secure Hash Standard (SHS), March 2012 http://csrc.nist.gov/publications/fips/fips180-4/fips180-4.pdf
[FIPS-186-2+CN1]	FIPS 186-2 - National Institute of Standards and Technology, Digital Signature Standard (DSS), Federal Information Processing Standards Publication 186-2, January 27, 2000 – Appendix 3.1 unter der Beachtung des Change Notice 1, vom 5. Oktober 2001 http://csrc.nist.gov/publications/fips/archive/fips186-2/fips186-2-change1.pdf
[FIPS-186-5]	FIPS 186-5 FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION (Supersedes FIPS 186-4) Digital Signature Standard (DSS), 03.02.2023 https://csrc.nist.gov/pubs/fips/186-5/final  https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf
[FIPS-197]	Federal Information Processing Standards Publication 197, (FIPS–197), November 26, 2001, Announcing the ADVANCED ENCRYPTION STANDARD (AES) http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
[FIPS-202]	NIST, FIPS PUB 202, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions, 2015, http://nvlpubs.nist.gov/nistpubs/fips/NIST.FIPS.202.pdf
[IETF-KEM-TLS]	KEM-based Authentication for TLS 1.3 T. Wiggers, S. Celi, P. Schwabe, D. Stebila, N. Sullivan https://datatracker.ietf.org/doc/draft-celi-wiggers-tls-authkem/
[IEFT-Kyber]	Kyber Post-Quantum KEM, P. Schwabe, B. E. Westerbaan Cloudflare, 2023, https://www.ietf.org/archive/id/draft-cfrg-schwabe-kyber-03.html
[IR-2014]	Bulletproof SSL and TLS: Understanding and deploying SSL/TLS and PKI to secure servers and web applications, Ivan Ristić, 2014 https://www.feistyduck.com/books/bulletproof-ssl-and-tls/
[ISO-11770]	ISO/IEC 11770: 1996, Information technology – Security techniques – Key management, Part 3: Mechanisms using asymmetric techniques
[Ker-1883]	Auguste Kerckhoffs, "La cryptographie militaire", Journal des sciences militaires, vol. IX, Seite 5–83, Jan. 1883, Seite 161–191, Feb. 1883. siehe auch http://www.petitcolas.net/fabien/kerckhoffs/
[KEM-TLS]	Post-quantum TLS without handshake signatures Peter Schwabe, Douglas Stebila, and Thom Wiggers https://eprint.iacr.org/2020/534
[KS-2011]	W. Killmann, W. Schindler, „A proposal for: Functionality classes for random number generators“, Version 2.0, September 2011 https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Zertifierung/Interpretation /AIS31_Functionality_classes_for_random_numder_generators.pdf?__ blpb=publicationFile
[MK-2016]	The Million-Key Question – Investigating the Origins of RSA Public Keys, Petr Svenda, Matus Nemec, Peter Sekan, Rudolf Kvasnovsky, David Formanek, David Komarek, Vashek Matyas,  The 25th USENIX Security Symposium (UsenixSec'2016) https://crocs.fi.muni.cz/public/papers/usenix2016
[NIST-PQC]	Post-Quantum Cryptography, National Institute of Standards and Technology (NIST),  https://csrc.nist.gov/projects/post-quantum-cryptography
[NIST-SP-800-22]	A. Ruskin et al., A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications, SP 800-22 Rev. 1a , 2010 https://csrc.nist.gov/publications/detail/sp/800-22/rev-1a/final
[NIST-SP-800-38A]	NIST Special Publication 800-38A, Recommendation for Block, Cipher Modes of Operation, Methods and Techniques, Morris Dworkin, December 2001 Edition, http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
[NIST-SP-800-38B]	NIST Special Publication 800-38B, Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, Morris Dworkin, May 2005 Edition, http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf
[NIST-SP-800-38D]	NIST Special Publication 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, Morris Dworkin, November, 2007
[NIST-SP-800-56-A]	NIST Special Publication 800-56A Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography,   April 2018 https://csrc.nist.gov/publications/detail/sp/800-56a/rev-3/final
[NIST-SP-800-56-B]	NIST Special Publication 800-56B Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography, August 2009
[NIST-SP-800-56C]	NIST Special Publication 800-56C Recommendation for Key Derivation through Extraction-then-Expansion, November 2011
[NIST-SP-800-108]	NIST Special Publication 800-108 Recommendation for Key Derivation Using Pseudorandom Functions, October 2009
[NK-PP]	Common Criteria Schutzprofil (Protection Profile) Schutzprofil 1:  Anforderungen an den Netzkonnektor, BSI-CC-PP-0097
[Oorschot-Wiener- 1996]	On Diffie-Hellman Key Agreement with Short Exponents, Paul C. van Oorschot, Michael J Weiner, Eurocrypt’ 96
[Padding-Oracle- 2005]	Padding Oracle Attacks on CBC-mode Encryption with Secret and Random IVs Arnold K. L. Yau, Kenneth G. Paterson and Chris J. Mitchell, FSE 2005 http://www.isg.rhul.ac.uk/~kp/secretIV.pdf
[PAdES-3]	ETSI TS 102 778-3 V1.2.1, PDF Advanced Electronic Signature Profiles; Part 3: PAdES Enhanced – PAdES-BES and PAdES-EPES Profiles Technical Specification, 2010
[PDF/A-2]	ISO 19005-2:2011 – Document management – Electronic document file format for long-term preservation – Part 2: Use of ISO 32000-1 (PDF/A-2)
[PKCS#1]	vgl. [RFC-8017]
[PP-0082]	Common Criteria Protection Profile, Card Operating System Generation 2 (PP COS G2), BSI-CC-PP-0082-V2, Version 1.9, 18th November 2014
[PQC-Hybrid-Chrome]	Protecting Chrome Traffic with Hybrid Kyber KEM, Thursday, August 10, 2023 https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html
[PQC-Hybrid-Signal]	The PQXDH Key Agreement Protocol, Revision 2, 2023-05-24 https://signal.org/docs/specifications/pqxdh/  (vgl. auch https://signal.org/blog/pqxdh/ )
[RFC-2119]	RFC 2119 (März 1997): Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, http://tools.ietf.org/html/rfc2119
[RFC-2590]	RFC 2590 (June 1999): X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP https://tools.ietf.org/html/rfc2560 (Obsoleted by [RFC-6960])
[RFC-2986]	RFC 2986 (November 2000): PKCS #10: Certification Request Syntax Specification, Version 1.7 https://tools.ietf.org/html/rfc2986
[RFC-3279]	RFC 3279 (April 2002): Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile https://tools.ietf.org/html/rfc3279
[RFC-3526]	RFC 3526 (Mai 2003: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) http://tools.ietf.org/html/rfc3526
[RFC-4051]	Additional XML Security Uniform Resource Identifiers (URIs), April 2005 https://tools.ietf.org/html/rfc4051
[RFC-4635]	RFC 4635 (August 2006): HMAC SHA TSIG Algorithm Identifiers http://tools.ietf.org/html/rfc4635
[RFC-5077]	Transport Layer Security (TLS) Session Resumption without Server-Side State, January 2008, https://tools.ietf.org/html/rfc5077
[RFC-5084]	RFC 5084: Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS), November 2007 https://tools.ietf.org/html/rfc5084
[RFC-5091]	RFC 5091: Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems, X. Boyen, L. Martin, December 2007 https://tools.ietf.org/html/rfc5091
[RFC-5246]	The Transport Layer Security (TLS) Protocol Version 1.2, August 2008, https://tools.ietf.org/html/rfc5246
[RFC-5280]	RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, Mai 2008 https://tools.ietf.org/html/rfc5280
[RFC-5480]	RFC 5480 (March 2009): Elliptic Curve Cryptography Subject Public Key Information, https://tools.ietf.org/html/rfc5480
[RFC-5639]	RFC 5639 (March 2010): Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation, http://www.ietf.org/rfc/rfc5639.txt
[RFC-5652]	RFC 5652 (September 2009): Cryptographic Message Syntax (CMS), R. Housley, http://tools.ietf.org/html/rfc5652
[RFC-5702]	RFC 5702 (October 2009): Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC, http://tools.ietf.org/html/rfc5702
[RFC-5746]	RFC 5746: Transport Layer Security (TLS) Renegotiation Indication Extension, February 2010, https://tools.ietf.org/html/rfc5746
[RFC-5753]	RFC 5753: Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS), January 2010,  https://tools.ietf.org/html/rfc5753
[RFC-5869]	HMAC-based Extract-and-Expand Key Derivation Function (HKDF), May 2010,  https://tools.ietf.org/html/rfc5869
[RFC-5903]	Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2, June 2010,  https://tools.ietf.org/html/rfc5903
[RFC-6090]	RFC 6090: Fundamental Elliptic Curve Cryptography Algorithms, February 2011,  https://tools.ietf.org/html/rfc6090
[RFC-6954]	Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2),July 2013,  https://tools.ietf.org/html/rfc6954
[RFC-6960]	RFC 6960 (June 2013): X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP, https://tools.ietf.org/html/rfc6960
[RFC-7027]	RFC 7027: (October 2013) Elliptic Curve Cryptography (ECC) Brainpool Curves  for Transport Layer Security (TLS), https://tools.ietf.org/html/rfc7027
[RFC-7296]	RFC 7296 (October 2014): Internet Key Exchange Protocol Version 2 (IKEv2), https://tools.ietf.org/html/rfc7296
[RFC-7427]	RFC 7427 (January 2015): Signature Authentication in the Internet Key Exchange Version 2 (IKEv2), https://tools.ietf.org/html/rfc7427
[RFC-8017], [PKCS#1]	"Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.2",  November 2016 https://tools.ietf.org/html/rfc8017
[RFC-931]	RFC 6931: Additional XML Security Uniform Resource Identifiers (URIs), Donald Eastlake, April 2013, https://tools.ietf.org/html/rfc6931
[RFC-9155]	RFC 9155: Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2, December 2021, https://datatracker.ietf.org/doc/rfc9155/
[ROCA-2017]	The Return of Coppersmith's Attack: Practical Factorization of Widely Used RSA Moduli, Matus Nemec, Marek Sys, Petr Svenda, Dusan Klinec, Vashek Matyas 24th ACM Conference on Computer and Communications Security (CCS'2017) https://crocs.fi.muni.cz/public/papers/rsa_ccs17
[SEC1-2009]	Standards for Efficient Cryptography, SEC 1: Elliptic Curve Cryptography, Certicom Research, Contact: Daniel R. L. Brown (dbrown@certicom.com), May 21, 2009, Version 2.0 https://www.secg.org/sec1-v2.pdf
[SDH-2016]	Measuring the Security Harm of TLS Crypto Shortcuts, Drew Springall, Zakir Durumeic, J. Alex Halderman, November 2016, https://jhalderm.com/pub/papers/forward-secrecy-imc16.pdf
[SOG-IS-2020]	SOG-IS Crypto Evaluation Scheme Agreed Cryptographic Mechanisms, Version 1.2, January 2020 https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.2.pdf
[TLS-Attacks]	Lessons Learned From Previous SSL/TLS Attacks - A Brief Chronology Of Attacks And Weaknesses, Christopher Meyer und Jörg Schwenk, 31. Januar 2013, http://eprint.iacr.org/2013/049
[TLS-CC-2021]	Hybrid Post-Quantum Key Encapsulation Methods (PQ KEM) for Transport Layer Security 1.2 (TLS), September 2021, https://datatracker.ietf.org/doc/draft-campagna-tls-bike-sike-hybrid/
[XMLCan_V1.0]	Exclusive XML Canonicalization, Version 1.0, W3C Recommendation 18 July 2002, http://www.w3.org/TR/xml-exc-c14n/
[XMLDSig]	XML Signature Syntax and Processing Version 1.1, W3C Recommendation 11 April 2013 https://www.w3.org/TR/xmldsig-core1/
[XMLDSig-Draft]	XML Signature Syntax and Processing Version 2.0, W3C Editor's Draft 04 February 2014, http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/
[XMLDSig-RSA- PSS]	RSA-PSS in XMLDSig, 25/26 September 2007, Konrad Lanz, Dieter Bratko, Peter Lipp, http://www.w3.org/2007/xmlsec/ws/papers/08-lanz-iaik/
[XMLEnc]	XML Encryption Syntax and Processing, W3C Recommendation 10 December 2002, http://www.w3.org/TR/xmlenc-core/
[XMLEnc-CM]	Technical Analysis of Countermeasures against Attack on XML Encryption - or - Just Another Motivation for Authenticated Encryption. Juraj Somorovsky, Jörg Schwenk. 2011 http://www.w3.org/2008/xmlsec/papers/xmlEncCountermeasuresW3C.pdf
[XMLEnc-1.1]	XML Encryption Syntax and Processing, W3C Recommendation 11 April 2013, http://www.w3.org/TR/xmlenc-core1/
[XSpRES]	XML Spoofing Resistant Electronic Signature (XSpRES) -- Sichere Implementierung für XML-Signaturen Bundesamt für Sicherheit in der Informationstechnik 2012 https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/SOA/XSpRESS.pfd?__blob=publicationFile
[XSW-Attack]	On Breaking SAML: Be Whoever You Want to Be Juraj Somorovsky, Andreas Mayer, Jörg Schwenk, Marco Kampmann, Meiko Jensen, Usenix 2012 http://www.nds.rub.de/media/nds/veroeffentlichungen/2012/08/03/BreakingSAML.pdf
[Vaudenay-2002]	Security Flaws Induced by CBC Padding: Applications to SSL, IPsec, WTLS … , Serge Vaudenay, Eurocrypt 2002, LNCS 2332/2002, 535-545 https://www.iacr.org/cryptodb/data/paper.php?pubkey=2850