A_27274 - VSDM-Betreiber: jährliche Erzeugung des gemeinsamen Geheimnisses

Ein Betreiber eines VSDM-Dienstes MUSS (min.) jährlich ein Geheimnis 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. [<=]
[<=]

A_27275 - VSDM-Betreiber: verschlüsselter Export des gemeinsamen Geheimnisses für Prüfziffer prüfende Fachdienste-VAUs

Ein Betreiber eines VSDM-Dienstes MUSS das gemeinsame Geheimnis (vgl. A_27274-*) mittels des ECIES-Verfahrens [SEC1-2009] für den Export an die VAUs der prüfenden Fachdienste (E-Rezept-FD, ePA-Aktensysteme) verschlüsseln und dabei folgende Vorgaben umsetzen

1. Er MUSS ein ephemeres ECDH-Schlüsselpaar erzeugen, auf der Kurve des EE-Schlüssels aus dem Verschlüsselungszertifikat des Empfängers (VAUENC) -- als P-256 oder brainpoolP256r1, 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.

[<=]

A_27276 - VSDM: Export-Paket

Ein VSDM-FD MUSS bei der Erstellung der Export-Pakete für den Export der gemeinsamen Geheimnisse (vgl. A_27274-*) an die prüfenden Systeme (E-Rezept-VAU, ePA-Aktensystem-VAU-HSM etc.) die gleiche Export-Paket-Struktur verwenden wie im Kontext Prüfziffer Version 1. [<=]

A_27356 - VSDM: explizite Angabe der Geheimnis-Version bei Erzeugung

Ein VSDM-FD MUSS es einem VSDM-FD-Betreiber ermöglichen:

1. bei der (im Regelfall jährlichen) Erzeugung des Geheimnisses die Schlüsselversion, die bei der Erzeugung zu verwenden ist, explizit und beliebig (außer die aktuell aktive Schlüsselversion) anzugeben, 
   (Es ist also keine strenge Monotonie bei der Folge der Schlüsselversionen durchzusetzen.)
2. explizit und beliebig auszuwählen welche Schlüsselversion aktiv (zur Erzeugung von Prüfziffern) verwendet werden soll, und  
3. explizit auszuwählen welche Schlüsselversion zu löschen ist.

[<=]

A_27277 - VSDM-Betreiber: Schlüsselwechsel

Ein Betreiber eines VSDM-Dienstes MUSS folgendes sicherstellen.

1. Nach der jährlicher Erneuerung des gemeinsamen Geheimnisses (vgl. A_27274-*) MUSS dieses mittels A_27275-* und A_27276-* und des schon für die Prüfziffer Version 1 etablierten Prozess jeweils für die prüfenden Systeme (E-Rezept-VAU und ePA-Aktensystem-VAUs) verschlüsselt und an diese übermittelt werden.
2. Das gemeinsame Geheimnis MUSS zunächst "inaktiv" sein.
3. Erst nach erfolgreichen Import durch alle prüfenden Systeme MUSS das gemeinsame Geheimnis aktiviert werden und mittels A_27286-* der entsprechende AES/GCM-Schlüssel abgeleitet werden. Dieser ist dann aktiv und der jüngste AES/GCM-Schlüssel und MUSS nach A_27278-* für die Erzeugung der Prüfziffern Version 2 verwendet werden.

[<=]

A_27286 - VSDM-FD: Ableitung des AES/GCM-Schlüssel für die Sicherung der Prüfziffern Version 2 aus dem gemeinsamen Geheimnis

Ein VSDM-FD MUSS nach der Erzeugung eines gemeinsamen Geheimnisses (vgl. A_27274-*), mit dem Geheimnis eine Schlüsselableitung durchführen. Mittels der HKDF nach [RFC-5869] auf Basis von SHA-256 und dem Ableitungsvektor "VSDM+ Version 2 AES/GCM" ein 128 Bit (=16 Byte) Wert (Bitfolge) abgeleitet werden. Diese 128 Bit Bitfolge MUSS als AES/GCM-Schlüssel für die Erzeugung der Prüfziffern Version 2 gemäß A_27278-* verwendet werden.

D. h. Es wird nach A_27274-* ein neuer Schlüssel jährlich erzeugt, der dann die Versionsnummer x habe. Anschließend erfolgt einmalig eine Schlüsselableitung wie in A_27286-* definiert. Damit wird der AES/GCM-Schlüssel-Version x erzeugt. Nach "Aktivierung" (vgl. A_27277-*) wird dieser gemäß A_27278-* verwendet um Prüfziffern zu erzeugen. [<=]

A_27323 - VSDM-FD: relative Zeit (Zeit-offset) Prüfziffer Version 2

Ein VSDM-FD MUSS als Offset für die Zeitkodierung (iat) bei der Erstellung der Prüfziffer Version 2 (A_27278-*) folgende Vorgabe verwenden:

offset-Name	Wert	Erläuterung
iat_offset	1735689600	offset für die Erzeugungszeit (iat) der Prüfziffer Version 2 Hinweis: Die Zeit "2025-01-01T00:00:00+00:00" (ISO-Format 8601) nach Unix-Zeit (UTC) konvertiert ist 1735689600.

[<=]

A_27352 - VSDM-Prüfziffer Version 2: Erzeugung von hcv

Ein den hcv-Wert (Hash Check Value) erzeugendes System (VSDM-FD oder Primärsystem) MUSS bei der Erzeugung des hcv-Wertes, wie folgt vorgehen:

1. Es sei VB gleich der Versicherungsbeginn (UC_AllgemeineVersicherungsdatenXML.Versicherter.Versicherungsschutz.Beginn, https://github.com/gematik/api-telematik/blob/OPB5/fa/vsds/Schema_VSD.xsd ). VB MUSS keine Leerzeichen enthalten. 
2. Falls der Versicherte eine "StrassenAdresse" (vgl. XML-Schema) und darin ein nichtleeres Element "Strasse" besitzt, dann sei SAS gleich der Wert in diesem Element. Andernfalls sei SAS="" (leere Zeichenfolge). Ggf. Führende oder endende Leerzeichen MÜSSEN entfernt werden.
3. Sei SHA-256 wie in [FIPS-180-4] definiert.
4. Sei H = SHA-256(VB || SAS).
5. Sei H_40 die ersten 5 Bytes (40 Bit) von H.
6. Von H_40 setzt man das MSB im ersten Byte auf 0, dass Ergebnis sei H_40_0. 

Der hcv-Wert ist gleich H_40_0.

[<=]

A_27278 - VSDM-FD: Struktur einer Prüfziffer der Version 2

Ein VSDM-FD MUSS zunächst folgende innere Datenstruktur (Klartext) erstellen:

Name	Länge	Festlegungen und Erläuterung
I_Feld_1	5	In diesem Feld sind Sperrinformationen und ein gekürzter Hashwert kodiert. Sperrinformation: Falls die eGK ungültig/gesperrt ist, sei S=128, anderenfalls sei S=0. Hashwert: Der hcv-Wert MUSS wie in A_27352-* definiert berechnet werden. Und wird im Folgenden als H_40_0 bezeichnet. Sei H_40_0[0] das erste Byte von H_40_0 und H_40_0[1:] alle restlichen Bytes von H_40_0. Dann ist I_Feld_1 = (H_40_0[0] | S) || H_40_0[1:]. (Erläuterung zum besseren Verständnis: das MSB im ersten Byte von H_40 wird auf 0 gesetzt (A_27352-*, Schritt 6) und man erhält H_40_0. Anschließend wird die Sperrinformation auf das erste Byte aufaddiert. D. h. wenn von I_Feld_1 das MSBit des ersten Bytes 1 ist, dann ist die eGK ungültig/gesperrt.)
r_iat_8	3	Sei iat die aktuelle Unix-Zeit (UTC) in Sekunden (also keine Nachkommastellen) im VSDM-FD zum Erzeugungszeitpunkt der Prüfziffer. Dann MUSS r_iat_8 = (iat - iat_offset) >> 3 Alle Zahlenwerte MÜSSEN in Network-Byte-Order (= Byte-Order Big) kodiert werden. Alle Zeiten sind wie bei der Unix-Zeit üblich UTC. Hinweis: für iat_offset vgl. A_27323-*. Beispiel: Wird die Prüfziffer um "2025-01-02T00:00:00+00:00" = 1735776000 erzeugt, dann ist r_iat = (1735776000 - 1735689600) >> 3 = 10800
KVNR	10	10 Stellige KVNR, ASCII-kodiert (Beispiel: A123456789)

Der Klartext hat damit eine Länge von 18 Byte.

Name	Länge
Feld_1	1	In diesem Feld sind drei Informationen kodiert: (1) Kennzeichnung für Version 2 der Prüfziffer Sei V = 128. (2) Betreiberkennung Die Betreiberkennung (wie bspw. im Export-Paket (A_27276-*) übertragen) ist zunächst ein Buchstabe von 'A' bis 'Z'. Sei BK diese Betreiberkennung als ASCII-Zeichen.  Sei BK_D = BK - 65 und sei BK_D_4 = BK_D << 2. (3) Geheimnis/Schlüssel-Version Sei SV gleich die Geheimnis/Schlüssel-Version, die für die Verschlüsselung des Klartextes (siehe Tabelle oben) verwendet wird. SV wird binär kodiert, bspw. wenn SV = 2 ist, so ist SV kodiert \x02. SV MUSS kleiner 4 sein (vgl. auch A_27356-*). Sei Feld_1 = V + BK_D_4 + SV Beispiel: Sei die Betreiberkennung gleich 'B' und die Schlüssel-Version gleich 2, dann ist BK_D_4 gleich 4. Und damit Feld_1 = 128 + 4 + 2 = 134.
Intitialisierungsvektor für AES/GCM	12	wie bei AES/GCM üblich MUSS der 96 Bit lange IV (= 12 Bytes) pro Verschlüsselung zufällig über eine kryptographisch hochwertige Zufallsquelle erzeugt werden
eigentliches Chiffrat	18	mittels AES/GCM verschlüsselter Klartext (innere Datenstruktur, s. o.) mit dem jüngsten aktivierten AES/GCM-Schlüssel (vgl. A_27286-*)
AES/GCM Authentication-Tag (GMAC)	16	128-Bit Authentication-Tag, der bei der AES/GCM entsteht (berechnet wird)

Die oben aufgeführte Datenstruktur hat die Gesamtgröße von 47 Byte. Diese Datenstruktur MUSS base64-kodiert werden. Das Ergebnis der Kodierung ist "die Prüfziffer Version 2". Deren Länge ist 64 Byte (Hinweis: gleiche Länge wie eine Prüfziffer Version 1).

[<=]

A_27299 - VSDM-Prüfziffer Version 2: prüfenden Systeme, Import der gemeinsamen Geheimnisse und AES/GCM-Schlüsselableitung

Ein die Prüfziffer Version 2 prüfendes System (E-Rezept-FD-VAU, ePA-Aktensystem-VAU/VAU-HSM etc.) MUSS Export-Pakete gemäß A_27276-* importieren. Es werden dabei gemeinsame Geheimnisse gemäß A_27274-* importiert. Diese MUSS die im Export-Paket aufgeführte Betreiberkennung und Version zugeordnet werden. Mit dem gemeinsamen Geheimnis MUSS das prüfende System eine Schlüsselableitung gemäß A_27286-* durchführend und dem erhaltenen AES/GCM-Schlüssel die Betreiberkennung und Version des gemeinsamen Geheimnisses (also aus dem entsprechenden Import) zuordnen.

Anschließend MÜSSEN die AES/GCM über Betreiberkennung und Version (vgl. Kodierung der beiden Werte in einer Prüfziffer Version 2 in A_27278-*) im prüfenden System verfügbar/adressierbar sein.

Ein prüfendes System MUSS die Möglichkeit besitzen alte gemeinsame Geheimnisse und abgleitete AES/GCM-Schlüssel (Kontext Prüfung Prüfziffer Version 2) im System per Administration zu löschen.
[<=]

A_27342 - Konfigurationsvariable enforce_hcv_check

Ein die Prüfziffer Version 2 prüfendes System (E-Rezept-VAU, ePA-Aktensystem-VAU-HSM etc.) MUSS eine Konfigurationsvariable enforce_hcv_check besitzen, die standarmäßig auf false gesetzt ist. [<=]

A_27279 - VSDM-Prüfziffer Version 2: Prüfung und Entschlüsselung

Ein die Prüfziffer Version 2 prüfendes System (E-Rezept-VAU, ePA-Aktensystem-VAU-HSM etc.) MUSS folgende Prüfungen der Prüfziffer Version 2 vornehmen. Ergibt eine der Prüfungen ein nicht-positives Prüfergebnis, so MUSS die Prüfziffer als ungültig abgelehnt werden.

1. Prüfung: besitzt die Prüfziffer eine Länge von 64 Bytes.
2. Prüfung: kann die Prüfziffer erfolgreich base64-dekodiert werden.
   Die nun erhaltene erfolgreich base64-dekodierte 47 Byte lange Bytefolge wird als dtbc (data to be checked) im Folgenden bezeichnet.
3. Prüfung: ist das erste Byte von dtbc größer als 128 (das MSBit ist also auf 1 gesetzt).
   Hinweis: ansonsten handelt es sich um eine Prüfziffer Version 1 (für die Prüfung in A_27279-* also nicht geeignet).
4. Prüfung: gibt es im prüfenden System einen AES/GCM-Schlüssel mit der im ersten Byte von dtbc aufgeführter Betreiberkennung und aufgeführter Version (vgl. A_27299-* und A_27278-*).
5. Die folgenden 12 Byte in dtbc werden als IV bezeichnet. Die darauf folgenden 18 Bytes werden als ciphertext bezeichnet. Die darauf folgenden 16 Bytes werden als Authentication-Tag bezeichnet.
   Prüfung: ist die AES/GCM-Entschlüsselung erfolgreich mittels des in Schritt 4 identifizierten AES/GCM-Schlüssels und mit IV, ciphertext, Authentication-Tag
   D. h. gibt es gerade kein Symbol FAIL als Ergebnis der AES/GCM-Entschlüsselung -- die Authentizität und Integrität des Chiphertexts/Klartexts ist damit festgestellt.
   Im folgenden wird der erfolgreich entschlüsselte Klartext betrachtet.
6. Prüfung: ist das MSBit im ersten Byte des Klartextes gleich 0 (ansonsten ist die eGK gesperrt).
7. Prüfung zeitliche Gültigkeit der Prüfziffer:
   Sei, wie in A_27278-*, definiert r_iat_8 die Bytefolge von Byte-Offset 5 bis inkl. Byte-Offset 7 (also 3 Byte groß) aus dem Klartext. r_iat_8 MUSS im Network-Byte-Order (= Byte-Order Big) kodierte unsignierte Zahl interpretiert werden.
   Zunächst MUSS der Wert iat mit iat = (r_iat << 3) + iat_offset (vgl. A_27323-*) berechnet werden.
   Anschließend MUSS anwendungsspezifisch iat mit der aktuellen Zeit überprüft werden:
   ePA: A_24573-* (20 Minuten Fenster)
   E-Rezept: A_23451-* (30 Minuten Fenster)
8. Prüfung hcv:
   Im folgenden werden die ersten 5 Byte des Klartextes als H_40_0 bezeichnet.
   Genau dann wenn enforce_hcv_check (vgl. A_27342-*) auf true gesetzt ist, dann MUSS geprüft werden, ob H_40_0 gleich dem vom Primärsystem übergebenen hcv-Wert ist (vgl. A_24590-*).
   (Der hcv-Wert aus A_24590-* MUSS vor dem Vergleich base64-dekodiert werden.)
9. Die letzten 10 Byte des Klartextes werden als KVNR bezeichnet.
   Prüfung: ist die KVNR aus dem Klartext gleich der KVNR, die im Anwendungskontext erwartet wird.

[<=]

A_24611-02 - ePA-Aktensystem - Im VAU-HSM gespeicherte Schlüssel und Informationen für VAU-Betrieb

Das ePA-Aktensystem MUSS sicherstellen, dass folgende, für den Betrieb der VAU notwendigen Schlüssel und Informationen in einem HSM (als VAU-HSM bezeichnet) gespeichert werden:

• privater Schlüssel der Authentisierungsidentität der Aktenkontoverwaltungs-VAU (u.a. genutzt für die Authentisierung der VAU beim Aufbau des VAU-Kanals)
• ggf. private Schlüssel der Authentisierungsidentität der Befugnisverifikations-VAU
• ggf. private Schlüssel der Authentisierungsidentitäten für Service-VAUs
• privater Schlüssel der Verschlüsselungsidentität der VAU
• privater Schlüssel der Signaturidentität der VAU
• Zertifikat C.FD.ENC mit policyIdentifier oid_epa_vau für die Verschlüsselungsidentität des anderen ePA-Aktensystembetreibers
• Masterkeys für die Ableitung der versichertenindividuellen Datenpersistierungsschlüssel
• Masterkeys für die Ableitung der versichertenindividuellen Befugnispersistierungsschlüssel
• Masterkeys für die Ableitung der versichertenindividuellen Überschlüsselungsschlüssel (vgl. Abschnitt "Umschlüsselung und Überschlüsselung")
• symmetrische Schlüssel für die HMAC-Prüfung der VSDM-Prüfziffern (jeweils einen pro VSD-Dienst-Betreiber)
• symmetrischer Schlüssel für CMAC (zur Sicherung der registrierten Befugnisse)
• Hashwertrepräsentationen der erlaubten VAU-Software und VAU-Hardware (für die Aktenkontoverwaltungs-VAU, ggf. für die Befugnisverifikations-VAU und ggf. für Service-VAUs)
  
• Root-CA (nur, falls das Befugnisverifikations-Modul im VAU-HSM läuft).

[<=]

A_24612-03 - ePA-Aktensystem - Erzwingen von 4-Augen-Prinzip für Einbringen und Verwalten von Informationen ins VAU-HSM

Das ePA-Aktensystem MUSS technisch erzwingen, dass die folgenden, für den Betrieb der VAU notwendigen Schlüssel und Informationen ausschließlich im 4-Augen-Prinzip in das VAU-HSM eingebracht und verwaltet werden können:

• privater Schlüssel der Authentisierungsidentität der Aktenkontoverwaltungs-VAU
• ggf. privater Schlüssel der Authentisierungsidentität der Befugnisverifikations-VAU
• ggf. private Schlüssel der Authentisierungsidentitäten für Service-VAUs
• privater Schlüssel der Verschlüsselungsidentität der VAU
• privater Schlüssel der Signaturidentität der VAU
• Zertifikat C.FD.ENC mit policyIdentifier oid_epa_vau für die Verschlüsselungsidentität des anderen ePA-Aktensystembetreibers
• symmetrische Schlüssel für HMAC der VSDM-Prüfziffer (jeweils einen pro VSD-Dienst-Betreiber)
• symmetrischer Schlüssel für CMAC (zur Sicherung der registrierten Befugnisse)
• Hashwertrepräsentationen der erlaubten VAU-Software und VAU-Hardware (für die Aktenkontoverwaltungs-VAU, ggf. für die Befugnisverifikations-VAU und ggf. für Service-VAUs)
  
• Root-CA (nur, falls das Befugnisverifikations-Modul im VAU-HSM läuft).

[<=]

A_24614-02 - ePA-Aktensystem - Einbringung von Informationen ins VAU-HSM im 4-Augen-Prinzip mit der gematik

Der Betreiber des ePA-Aktensystems MUSS sicherstellen, dass die folgenden, für den Betrieb der VAU notwendigen Schlüssel und Informationen ausschließlich im 4-Augen-Prinzip ins VAU-HSM eingebracht und im VAU-HSM verwaltet werden, bei dem eine von der gematik benannte Person beteiligt ist:

• privater Schlüssel der Authentisierungsidentität der Aktenkontoverwaltungs-VAU
• ggf. private Schlüssel der Authentisierungsidentität der Befugnisverifikations-VAU
• ggf. private Schlüssel der Authentisierungsidentitäten für Service-VAUs
• privater Schlüssel der Verschlüsselungsidentität der VAU
• privater Schlüssel der Signaturidentität der VAU
• Zertifikat C.FD.ENC mit policyIdentifier oid_epa_vau für die Verschlüsselungsidentität des anderen ePA-Aktensystembetreibers
• symmetrische Schlüssel für HMAC der VSDM-Prüfziffer (jeweils einen pro VSD-Dienst-Betreiber)
• symmetrischer Schlüssel für CMAC (zur Sicherung der registrierten Befugnisse)
• Hashwertrepräsentationen der erlaubten VAU-Software und VAU-Hardware (für die Aktenkontoverwaltungs-VAU, ggf. für die Befugnisverifikations-VAU und ggf. für Service-VAUs)
  
• Root-CA (nur, falls das Befugnisverifikations-Modul im VAU-HSM läuft).

[<=]

A_24618-02 - ePA-Aktensystem - Zugriff auf Schlüssel und Informationen im VAU-HSM

Das ePA-Aktensystem MUSS sicherstellen, dass auf die folgenden, für den Betrieb der VAU notwendigen und im VAU-HSM gespeicherten Schlüssel und Informationen ausschließlich über attestierte VAU-Instanzen zugegriffen werden kann:

• privater Schlüssel der Authentisierungsidentität der VAU ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz
• privater Schlüssel der Authentisierungsidentität der Befugnisverifikations-VAU ausschließlich durch eine Befugnisverifikations-VAU-Instanz
• privater Schlüssel der Authentisierungsidentität eines Service-VAU-Typs ausschließlich durch eine Service-VAU-Instanz dieses Service-VAU-Typs
• privater Schlüssel der Verschlüsselungsidentität der VAU ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz
  
• privater Schlüssel der Signaturidentität der VAU ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz
  
• Zertifikat C.FD.ENC mit policyIdentifier oid_epa_vau für die Verschlüsselungsidentiät des anderen ePA-Aktensystembetreibers ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz
  
• Masterkeys für die Ableitung der versichertenindividuellen Datenpersistierungsschlüssel ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz
  
• Masterkeys für die Ableitung der versichertenindividuellen Befugnispersistierungsschlüssel ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz
• Masterkeys für die Ableitung der versichertenindividuellen Überschlüsselungsschlüssel (vgl. Abschnitt "Umschlüsselung und Überschlüsselung") ausschließlich durch die Aktenkontoverwaltungs-VAU-Instanz oder durch eine dedizierte Überschlüsselungs-VAU
• symmetrische Schlüssel für HMAC der VSDM-Prüfziffer (jeweils einen pro VSD-Dienst-Betreiber) ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz oder eine Befugnisverifikations-VAU-Instanz
  
• symmetrischer Schlüssel für CMAC (zur Sicherung der registrierten Befugnisse) ausschließlich durch eine Aktenkontoverwaltungs-VAU-Instanz oder eine Befugnisverifikations-VAU-Instanz.

[<=]

A_27288 - Entitlement Management – Abgleich der KVNR bei Erstellen einer Befugnis über VSDM-Prüfziffer

Das Entitlement Management MUSS sicherstellen, dass für die in setEntitlementPs vom Primärsystem in x-insurantid übergebene KVNR und die übergebene Befugnis (signiertes JWT) folgendes gilt: die KVNR in x-insurantid stimmt mit der KVNR überein, die in der CMAC-gesicherten Befugnis enthalten ist, die als Ergebnis des Aufrufs der Regel rr3 mit der vom Primärsystem erhaltenen Befugnis (signiertes JWT) vom HSM zurückgegeben wird.
[<=]

A_27321 - Entitlement Management – Abgleich hcv bei Erstellen einer Befugnis über VSDM-Prüfziffer in Version 2

Falls vom Primärsystem in setEntitlementPs eine Befugnis (signiertes JWT) mit einer Prüfziffer in Version 2 übergeben wird und das Ergebnis des Aufrufs der Regel rr3 eine interne Datenstruktur der VSDM-Prüfziffer zurückliefert MUSS das Entitlement Management sicherstellen, dass

• bei einem JWT mit Attribut "hcv" der Wert von "hcv" mit dem Wert von hcv aus der VSDM-Prüfziffer übereinstimmt und ansonsten die Operation setEntitlementPs abbricht,
• bei einem JWT ohne Attribut "hcv" die Operation setEntitlementPs abbricht, falls der Konfigurationsparameter enforce_hcv_check (vgl. A_27342-*) auf true gesetzt ist.
  

[<=]

A_27289 - Entitlement Management – Maximale Anzahl fehlerhafter Abgleiche der KVNR bei Erstellen einer Befugnis über VSDM-Prüfziffer

Das Entitlement Management MUSS sicherstellen, dass ein Nutzer (LEI) innerhalb einer Stunde maximal fünfmal eine Befugnis (signiertes JWT) über setEntitlementPs übermitteln kann, bei der die mitgelieferte KVNR in x-insurantId von der KVNR abweicht, die in der Prüfziffer der übermittelten Befugnis (signiertes JWT) enthalten ist, andernfalls für den Nutzer für diesen Zeitraum die Operation setEntitlementPs abbrechen. [<=]

A_27322 - Entitlement Management – Maximale Anzahl fehlerhafter Abgleiche der VSD-Update-Zeit bei Erstellen einer Befugnis über VSDM-Prüfziffer in Version 2

Das Entitlement Management MUSS sicherstellen, dass ein Nutzer (LEI) innerhalb einer Stunde maximal fünfmal eine Befugnis (signiertes JWT) mit einer Prüfziffer in Version 2 über setEntitlementPs übermitteln kann, bei der die Operation setEntitlementPs gemäß A_27321-* abbricht. [<=]

A_24590-02 - Entitlement Management - Befugnis durch ein Primärsystem

Das Entitlement Management MUSS sicherstellen, dass die Befugnisvergabe durch ein Primärsystem über die Schnittstelle I_Entitlement_Management durch Verwendung eines gültig signierten JWT mit den dargestellten Mindest-Inhalten erfolgt:

Befugnis	Claim Name	Claim
Protected Header
	"typ"	"JWT"
	"alg"	"ES256" oder "PS256"
	"x5c"	Signaturzertifikat C.HCI.AUT
Payload
	"iat"	Zeitstempel Ausgabezeitpunkt
	"exp"	Verfalldatum, = "iat" + 20 min
	"auditEvidence"	VSDM-Prüfziffer aus dem VSDM-Prüfungsnachweis, base64-kodiert.
	"hcv"	Hash check value der als Ergebnis der Operation ReadVSD gemäß A_27352-* berechnet wird. Der berechnete hcv-Wert MUSS base64 kodiert werden.

[<=]

A_25208 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - VSDM - PN3 - URL kvnr

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf den Endpunkt /Task mit den URL-Parameter pnw="..." durch eine abgebende LEI, falls das Ergebnis im VSDM Prüfungsnachweis gleich 3 ist, prüfen, ob ein URL-Parameter kvnr="..." übermittelt wurde und bei fehlerhafter Prüfung mit dem Fehler 455 abbrechen. [<=]

A_25208-01 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - VSDM - URL kvnr

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf den Endpunkt /Task mit den URL-Parameter pnw="..." durch eine abgebende LEI prüfen, ob ein URL-Parameter kvnr="..." übermittelt wurde und bei fehlerhafter Prüfung mit dem Fehler 455 abbrechen. [<=]

A_27346 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - VSDM - URL hcv

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf den Endpunkt /Task mit den URL-Parameter pnw="..." durch eine abgebende LEI prüfen, falls enforce_hcv_check = TRUE, ob ein URL-Parameter hvc="..." übermittelt wurde und bei fehlerhafter Prüfung mit dem Fehler 457 abbrechen. [<=]

A_23450 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - VSDM - Prüfung Prüfungsnachweis

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf den Endpunkt /Task mit den URL-Parametern pnw="..." durch eine abgebende LEI, den im Parameter pnw übermittelten Prüfungsnachweis extrahieren, prüfen und bei Fehlen oder fehlerhafter Prüfung mit dem Fehler 403 abbrechen, damit nur Clients die Operation aufrufen können, welche einen Anwesenheitsnachweis erfolgreich durchgeführt haben.  [<=]

A_23450-01 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - VSDM - Prüfung Prüfungsnachweis

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf den Endpunkt /Task mit den URL-Parametern pnw="..." durch eine abgebende LEI, den im Parameter pnw übermittelten Prüfungsnachweis extrahieren, die Version der Prüfziffer bestimmen, den Prüfungsnachweis prüfen und bei Fehlen oder fehlerhafter Prüfung mit dem Fehler 403 abbrechen, damit nur Clients die Operation aufrufen können, welche einen Anwesenheitsnachweis erfolgreich durchgeführt haben.  [<=]

A_27287 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - VSDM - Vergleich KVNR

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf den Endpunkt /Task mit den URL-Parameter pnw="..." durch eine abgebende LEI prüfen, ob die in der Prüfziffer übermittelte KVNR identisch ist mit dem Wert im URL-Parameter kvnr="..." und bei Ungleichheit mit dem Fehler 456 abbrechen. [<=]

A_27347 - E-Rezept-Fachdienst - Rezepte lesen - Apotheke - VSDM - Vergleich hcv

Der E-Rezept-Fachdienst MUSS beim Aufruf der HTTP-GET-Operation auf den Endpunkt /Task mit den URL-Parameter pnw="..." durch eine abgebende LEI prüfen, falls im Operationsaufruf  der URL-Parameter hcv übermittelt wurde, den im URL-Parameter übermittelten Wert transformieren, miteinander vergleichen und bei Ungleichheit mit dem Fehler 458 abbrechen. [<=]

A_27301 - E-Rezept-Fachdienst - Prüfung und Entschlüsselung Prüfziffer Version 2

Der E-Rezept-Fachdienst MUSS eine Prüfziffer Version 2 gemäß [gemSpec_Krypt#A_27279-*] entschlüsseln und prüfen.  [<=]

A_23448 - PS abgebende LEI: E-Rezepte von Versicherten abrufen (VSDM)

Das PS der abgebenden LEI MUSS den Anwendungsfall "E-Rezepte eines Versicherten durch Abgebenden abrufen" gemäß TAB_ILFERP_020 umsetzen. 

Tabelle 5 : TAB_ILFERP_020 – E-Rezepte von Versicherten abrufen (VSDM)

Name	E-Rezepte von Versicherten abrufen (VSDM)
Auslöser	Aufruf des Anwendungsfalls in der GUI
Akteur	Leistungserbringer, Mitarbeiter der abgebenden LEI
Vorbedingung	Der eGK des Versicherten ist im eHealth-Kartenterminal gesteckt. Die LEI hat sich gegenüber der TI authentisiert.
Nachbedingung	Es steht eine Liste von Informationen mit Task-ID und zugehörigen AccessCode zu einlösbaren E-Rezepten des Versicherten für die Weiterverarbeitung zu Verfügung.
Standardablauf	VSD der eGK lesen VSDM Prüfungsnachweis ermitteln E-Rezepte abrufen

[<=]

A_23448-01 - PS abgebende LEI: E-Rezepte von Versicherten abrufen (VSDM)

Das PS der abgebenden LEI MUSS den Anwendungsfall "E-Rezepte eines Versicherten durch Abgebenden abrufen" gemäß TAB_ILFERP_020 umsetzen. 

Tabelle 6 : TAB_ILFERP_020 – E-Rezepte von Versicherten abrufen (VSDM)

Name	E-Rezepte von Versicherten abrufen (VSDM)
Auslöser	Aufruf des Anwendungsfalls in der GUI
Akteur	Leistungserbringer, Mitarbeiter der abgebenden LEI
Vorbedingung	Der eGK des Versicherten ist im eHealth-Kartenterminal gesteckt. Die LEI hat sich gegenüber der TI authentisiert.
Nachbedingung	Es steht eine Liste von Informationen mit Task-ID und zugehörigen AccessCode zu einlösbaren E-Rezepten des Versicherten für die Weiterverarbeitung zu Verfügung.
Standardablauf	VSD der eGK lesen VSDM Prüfungsnachweis ermitteln Hashwert hcv ermitteln E-Rezepte abrufen

[<=]

A_27354 - PS abgebende LEI: E-Rezepte von Versicherten abrufen - Hashwert hcv erzeugen

Das PS der abgebenden LEI MUSS im Anwendungsfall "E-Rezepte von Versicherten abrufen" den Hashwert hcv erzeugen. [<=]

A_27355 - PS abgebende LEI: E-Rezepte von Versicherten abrufen - Hashwert hcv Base64URLSafe kodieren

Das PS der abgebenden LEI MUSS im Anwendungsfall "E-Rezepte von Versicherten abrufen" den Hashwert hcv Base64URLSafe kodieren. [<=]

A_23449-01 - PS abgebende LEI: E-Rezepte von Versicherten abrufen - E-Rezepte abrufen

Das PS der abgebenden LEI MUSS im Anwendungsfall "E-Rezepte von Versicherten abrufen" die HTTP-Operation GET /Task mit

• ACCESS_TOKEN im Authorization-Header
  
• base64- und URL-codierter Prüfungsnachweis in URL-Parameter pnw
• Versicherten-ID in URL-Parameter kvnr

ausführen. [<=]

A_23449-02 - PS abgebende LEI: E-Rezepte von Versicherten abrufen - E-Rezepte abrufen

Das PS der abgebenden LEI MUSS im Anwendungsfall "E-Rezepte von Versicherten abrufen" die HTTP-Operation GET /Task mit

• ACCESS_TOKEN im Authorization-Header
  
• base64- und URL-codierter Prüfungsnachweis in URL-Parameter pnw
• Versicherten-ID in URL-Parameter kvnr
• Base64URLSafe-kodierter Hashwert hcv in URL-Parameter hcv

ausführen. [<=]