ML-164466 - Änderung in gemSpec_Krypt für initiale Zero-Trust-Spezifikation

[<=]

A_26920 - ZT/ASL mindestens HTTP-Version 1.1

Ein ZT/ASL-Server MUSS an seinen HTTPS-Schnittstellen, i. S. v. Schnittstellen, die ein ZT/ASL-Client anspricht, mindestens HTTP Version 1.1 unterstützen. [<=]

A_26921 - ZT/ASL: ZT/ASL-Schlüssel für die ASL-Protokoll-Schlüsselaushandlung

Ein ZT/ASL-Server MUSS sicherstellen, dass

1. es eine Signatur-Identität (AUT) aus der Komponenten-PKI der TI gibt, die technisch sichergestellt ausschließlich nur von ZT/ASL-Instanzen verwendbar ist.
2. es semi-statische Schlüsselpaare für ECDH (auf Basis Kurve P-256 [FIPS-186-5]) und ML-KEM-768 [FIPS-203] gibt, deren private Schlüssel, technisch sichergestellt, ausschließlich von ZT/ASL-Server verwendbar sind.
3. die privaten Schlüssel (aus 2.) in einer ZT/ASL-Instanz erzeugt und verarbeitet werden,
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 Server 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 ASL-Schlüssel

ASL_Keys = {           "ECDH_PK" :             { "crv" : "P-256",               "x" : Binärwert-x-Koordinate-32-Byte-big-endian (256 Bit),               "y" : Binärwert-x-Koordinate-32-Byte-big-endian (256 Bit),             },           "ML-KEM-768_PK" : Binärwert-öffentlicher-Schlüssel-nach-keygen-FIPS-203-ML-KEM-768,           "iat" : Erzeugungszeits-Sekunden-Since-Epoch (integer),           "exp" : Nicht-mehr-Verwendbar-nach (integer),           "comment" : "Erzeugt bei ASL-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 ASL_Keys_encoded genannt. Diese binäre Byte-Folge wird in folgende Datenstruktur eingebracht {  "signed_pub_keys" : ASL_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-ASL-Zertifikats,  "cdv"             : Cert-Data-Version (natürliche Zahl, beginnend mit 1, vgl. A_26922-*),  "ocsp_response"   : OCSP-Response-für-das-ASL-Signaturzertifikat-nicht-älter-als-24-Stunden-DER-Kodierung } Diese Datenstruktur wird mittels CBOR binär kodiert (serialisiert). Das Ergebnis der Kodierung wird "signierte öffentliche ZT/ASL-Schlüssel" (Plural) genannt.

[<=]

A_26922 - ZT/ASL: Verfügbarmachung des AUT-ZT/ASL-Zertifikats plus Prüfkette

Ein ZT/ASL-Server 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-ZT/ASL-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_26923-* erlaubt, Fehler in den Daten zu korrigieren (siehe Erläuterung nach A_26922-*).

Diese Datenstruktur MUSS per CBOR [RFC-CBOR] serialisiert/kodiert werden und per Mime-Type "application/cbor" [RFC-CBOR] (HTTP Content-Type) an den ZT/ASL-Client als Response auf den GET-Request gesendet werden.

In "rca_chain" MÜSSEN alle Cross-Zertifikate in chronologischer Ordnung von RCA7 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. [<=]

A_26923 - ZT/ASL: ZT/ASL-Client Prüfbasis Zertifikatsprüfung

Ein ZT/ASL-Client MUSS als Prüfbasis eine Root-Version (X.509-Root-TI-Zeritifikat), die mindestens 2 Jahre alt ist, verwenden oder die TSL. Der ZT/ASL-Client MUSS die Operation nach A_26922-* verwenden, um die für die Zertifikatsprüfung von A_26921-* notwendigen Zertifikate zu beziehen. Die bezogenen Zertifikatsdaten MUSS der ZT/ASL-Client lokal (zeitlich unbegrenzt) vorhalten (Caching). Bei Erhalt einer Nachricht 2 (A_26935-*) 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_26932 - ZT/ASL: ZT/ASL-Client, Nachricht 1

Ein ZT/ASL-Client MUSS für die Erzeugung folgende Schritte durchlaufen.
Ein ZT/ASL-Client MUSS

1. ein ECC-Schlüsselpaar auf der Kurve P-256 [FIPS-186-5] erzeugen.
2. ein ML-KEM-768-Schlüsselpaar [FIPS-203] erzeugen.

Anschließend MUSS er die öffentlichen Schlüssel in folgende Datenstruktur überführen
 {
    "MessageType" : "M1",
    "ECDH_PK"    :  { "crv" : "P-256",
                      "x" : analog A_26921-*,
                      "y" : analog A_26921-* },
    "ML-KEM-768_PK" : analog zu A_26921-*
}

Diese Datenstruktur MUSS er mittels CBOR [RFC-CBOR] in eine Bytefolge kodieren (serialisieren).
Diese Bytefolge ist die Nachricht 1.

Diese Nachricht 1 MUSS der ZT/ASL-Client an die HTTPS-Schnittstelle des Aktensystem per POST auf den Pfad /ASL senden, wobei er den Mime-Type "application/cbor" [RFC-CBOR] (HTTP Content-Type) verwendet und die Nachricht 1 im Request-Body aufführt.
[<=]

A_26933 - ZT/ASL-Protokoll: ZT/ASL-Server: Erhalt von Nachricht 1

Eine ZT/ASL-Server  MUSS die für Nachricht 1 erzeugten Datenobjekte nach A_26932-* verarbeiten können. [<=]

A_26934 - ZT/ASL-Protokoll: AES/GCM-Verschlüsselung im Handshake

Ein ZT/ASL-Server und -Client verschlüsseln im Rahmen des Handshakes des ZT/ASL-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.hb [<=]

A_26935 - ZT/ASL-Protokoll: ZT/ASL-Server: Nachricht 2

Ein ZT/ASL-Server MUSS die beiden öffentlichen Schlüssel aus Nachricht 1 (vgl. A_26932-*) prüfen (korrekte ECC-Kurve ("crv":"P-256"), öffentlicher Punkt liegt auf der Kurve P-256 [FIPS-186-5], der öffentliche ML-KEM-768-Schlüssel ist valide [FIPS-203]). Er MUSS für ECDH und ML-KEM-768 jeweils die KEM-Encapsulate-Funktion verwenden und erhält dabei zwei Geheimnisse (ss_e_ecdh, ss_e_mlkem768) und zwei Ciphertexte (ECDH_ct, ML-KEM-768_ct).
Er MUSS für die beiden Geheimnisse zusammenfügen: ss_e = ss_e_ecdh || ss_e_mlkem768 und das Ergebnis mittels der HKDF [RFC-5869] 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_26934-*) MÜSSEN die  "signierten öffentlichen ZT/ASL-Schlüssel" (vgl. A_26921-*) verschlüsselt werden. Das Ergebnis (vgl. A_26934-*) heißt aed_ciphertext_msg_2.

Er MUSS folgende Datenstruktur erzeugen:
{
    "MessageType" : "M2",
    "ECDH_ct"     :  ... analog ECDH_PK aus A_26932-* ...,
    "ML-KEM-768_ct" : ML-KEM-768-Ciphertext analog [FIPS-203],
    "AEAD_ct"     : aead_ciphertext_msg_2
}

Diese Datenstruktur MUSS er mittels CBOR [RFC-CBOR] serialisieren. Diese Bytefolge ist Nachricht 2.

Er MUSS eine 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 ZT/ASL-Server ermöglichen, den aktuellen Handshake entsprechend zuzuordnen bei Eintreffen der Nachricht-3 des ZT/ASL-Clients, der diese ID mitsendet. Der ZT/ASL-Serzuver kann die Struktur der ID selbst definieren. Ein ZT/ASL-Client MUSS die ID als opake Zeichenkette behandeln.
Er MUSS die Nachricht 2 inkl. ID 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 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 "ZT/ASL-CID" die ID aufgeführt werden. [<=]

A_26936 - ZT/ASL-Protokoll: ZT/ASL-Client: Erhalt von Nachricht 2

Ein ZT/ASL-Client MUSS die für Nachricht 2 erzeugten Datenobjekte nach A_26935-* verarbeiten können.
Er MUSS prüfen, ob

1. im HTTP-Response-Header die Variable "ZT/ASL-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_26937) und aller weiteren Nachrichten -- also auch nach dem erfolgreichen Handshake -- im Kontext dieser Verbindung verwenden. [<=]

A_26937 - ZT/ASL-Protokoll: ZT/ASL-Client: Nachricht 3

Ein ZT/ASL-Client MUSS aus der Nachricht 2 (vgl. A_26936-*) des ZT/ASL-Servers mittels der Ciphertexte ECDH_ct und ML-KEM-768_ct und den privaten ephemeren Client-Schlüsseln aus A_26932-* (Nachricht 1) und der jeweiligen KEM-Decapsulation-Funktionen zwei Geheimnisse berechnen: ss_e_ecdh und ss_e_mlkem768. Er MUSS die beiden Geheimnisse zusammenfügen: ss_e = ss_e_ecdh || ss_e_ml_kem_768 und das Ergebnis mittels der HKDF [RFC-5869] 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_26934-*) MUSS der Ciphertext "AEAD_ct" entschlüsselt werden: die "signierten öffentlichen ZT/ASL-Schlüssel" (vgl. A_26921-*) werden so als Klartext erhalten. Diese ZT/ASL-Schlüssel MUSS er nach A_26938-* prüfen. Mittels der öffentlichen Schlüssel (ECDH_PK, ML-KEM-768_PK) MUSS er jeweils die KEM-Encapsulation-Funktion ausführen und er erhält zwei Geheimnisse: ss_s_ecdh und ss_s_mlkem768. Diese führt er zusammen: ss_s = ss_s_ecdh || ss_s_mlkem768. 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"],
    "ML-KEM-768_ct" : client_kem_result_2["ML-KEM-768_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 [RFC-CBOR] serialisieren/kodieren. Diese Serialisierung MUSS er mittels K1_c2s verschlüsseln (vgl. A_26934-*) (= "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_26934-*), 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 ZT/ASL-CID (vgl. A_26936) als URL-Pfadnamen verwenden, unter Verwendung der HTTP-POST-Methode.
[<=]

A_26938 - ZT/ASL-Protokoll: ZT/ASL-Client: Prüfung der "signierten öffentlichen ZT/ASL-Schlüssel"

Ein ZT/ASL-Client MUSS die "signierten öffentlichen ZT/ASL-Schlüssel" (vgl. A_26921-*) bei der Verarbeitung von Nachricht 3 (vgl. A_26937-*) wie folgt prüfen. Erhält er bei einem der folgenden Prüfpunkte kein positives Prüfergebnis, so MUSS er die Verarbeitung (Handshake) abbrechen.

1. Prüfung des TI-Zertifikats, das den Hashwert aus dem "cert_hash"-Datenfeld besitzt (Bezug des Zertifikats vgl. A_26922-*), 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.
2. Das ZT-Server/TI-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.
3. Das TI-Zertifikat MUSS aus der Komponenten-PKI der TI stammt (vgl. Implementierungshinweis A_25192-*#Punkt-2) und die vom Client gewünschte Rollen-OID (bspw. "oid_epa_vau") besitzt.
4. Die Signatur im "signature-ES256"-Datenfeld MUSS eine valide Signatur für die Daten im Datenfeld "signed_pub_keys" (Signaturprüfung ergibt "valid/accept") sein, unter Verwendung des öffentlichen Signatur-Schlüssels aus dem ZT/ASL-TI-Zertifikats bei der Signaturprüfung.
5. Der ECC-Schlüssel in signed_pub_keys (vgl. Erzeugung bei A_26921-*) MUSS ein gültiger Punkt der Kurve P-256 [FIPS-186-5] sein. Der öffentliche Schlüssel in "ML-KEM-768_PK"-Datenfeld MUSS ein gültiger ML-KEM-768-Schlüssel [FIPS-203] sein.
6. Die Zeit in "signed_pub_keys.exp" MUSS größer als die aktuelle Systemzeit (Seconds since epoch) sein, d. h. die beiden Schlüssel (ECDH_PK und ML-KEM-768_PK) sind noch zeitlich gültig.

[<=]

A_26939 - ZT/ASL-Protokoll: ZT/ASL-Server: Erhalt von Nachricht 3

Ein ZT/ASL-Server MUSS die für Nachricht 3 erzeugten Datenobjekte nach A_26937-* verarbeiten können. [<=]

A_26940 - ZT/ASL-Protokoll: ZT/ASL-Server: Nachricht 4

Ein ZT/ASL-Server MUSS bei Erhalt der Nachricht 3 das Chiffrat AEAD_ct mittels des Schlüssels K1_c2s entschlüsseln. Schlägt dies fehl, MUSS er den Verbindungsaufbau mit einem Fehler (vgl. A_26924-*) abbrechen. Er MUSS analog wie der Client (vgl. A_26937-*) die Schlüsselerzeugung der folgenden Schlüssel durchführen, nur dass er 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).

Er MUSS analog zu A_26937-* das Transskript des Clients und dessen SHA-256-Wert berechnen. Er MUSS mittels K2_c2s_key_confirmation das Chiffrat "AEAD_ct_key_confirmation" aus Nachricht 3 entschlüsseln und prüfen, ob der von ihm (= ZT/ASL-Server) 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 er den Handshake mit einem Fehler abbrechen (vgl. A_26924-*).
Er MUSS den Transskript des ZT/ASL-Servers 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_26934-*), und erhält ein Chiffrat  genannt "AEAD_ct_key_confirmation". 
Er MUSS die folgende Datenstruktur erzeugen:
{
     "MessageType" : "M4",
     "AEAD_ct_key_confirmation" : Chiffrat-AEAD_ct_key_confirmation
}
Diese Datenstruktur MUSS er mittels CBOR [RFC-CBOR] serialisieren. Diese Bytefolge ist Nachricht 4.

Er MUSS die Nachricht 4 inkl. ID (vgl. A_26935-*) 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 "ZT/ASL-CID" die ID aufgeführt werden. [<=]

A_26941 - ZT/ASL-Protokoll: ASL/ZT-Client: Erhalt von Nachricht 4

Ein ZT/ASL-Client MUSS die für Nachricht 4 erzeugten Datenobjekte nach A_26940-* 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_26934-*).
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. [<=]

A_26926 - ZT/ASL: ZT/ASL-Client, Verschlüsselungszähler

Ein ZT/ASL-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 ZT/ASL-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. [<=]

A_26927 - ZT/ASL: ZT/ASL-Client: Request erzeugen/verschlüsseln

Ein ZT/ASL-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_26926-* wird der mit K2_c2s_app_data verbundene Zähler um eins erhöht. Es wird der IV mit IV=a || Zähler erzeugt (dessen Länge ist damit 96-Bit). 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 ZT/ASL-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_26931-*). (vgl. Erläuterungen zu A_26927-*).

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 ZT/ASL-Clients an einen ZTA/ASL-Server wird der Wert auf 1 gesetzt. In der Kodierung des Response-Chiffrats 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. Die Zählernummer wird vom Client in Network-Byte-Order (= Big-Endian) kodiert.
KeyID	32 Byte	KeyID aus dem Handshake (vgl. A_26937-*)

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 ZT/ASL-Clients an einen ZT/ASL-Server wird der Wert auf 1 gesetzt. In der Kodierung des Response-Chiffrats 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. Die Zählernummer wird vom Client in Network-Byte-Order (= Big-Endian) kodiert.
KeyID	32 Byte	KeyID aus dem Handshake (vgl. A_26937-*)
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_26927-*)
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 ZT/ASL-Client MUSS diese Datenstruktur per HTTP-POST an den ZT/ASL-Server senden und als URL-Pfadnamen dabei den Wert der ZT/ASL-CID (vgl. A_26936-*) verwenden. Dabei MUSS er den Media-Type 'application/octet-stream' (HTTP Content-Type) verwenden.
[<=]

A_26928 - ZT/ASL: ZT/ASL-Server: Request entschlüsseln/auswerten

Ein Request erreicht den ZT/ASL-Server über eine HTTPS-Schnittstelle. Im äußeren Request nimmt der ZT/ASL-Server das Routing mittels der Verbindungs-ID (URL-Pfadname, A_26936-* und A_26927-*) und/oder der KeyID im Header des Chiffrats vor.

Ein ZT/ASL-Server MUSS bei Erhalt eines Chiffrat nach A_26927-* folgendes prüfen.

1. Ist die Länge der Datenstruktur mindestens 72 Byte lang.
2. Ist die "PU/nonPU" Byte korrekt, i. S. v. korrekte Umgebung, in der auch der ZT/ASL-Server arbeitet.
3. Ist das Request/Response-Byte gleich 1.
4. Ist die KeyID bekannt.

Sollte eine dieser Prüfungen oder eine weitere der folgenden Prüfungen ein nicht-positives Prüfergebnis ergeben, so MUSS der ZT/ASL-Server die Verarbeitung des Requests abbrechen und mit einer Fehlermeldung (vgl. A_26924-*) dem Client antworten.

Der ZT/ASL-Server MUSS den mit der KeyID verbundenen Schlüssel K2_c2s_app_data für die Entschlüsselung des Chiffrats verwenden und dabei analog A_26927-* 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_26924-*) erfolgen. Der ZT/ASL-Server MUSS den Request-Counter-Wert speichern, der für die Antwort (A_26930-*)  benötigt wird. [<=]

A_26929 - ZT/ASL: ZT/ASL-Server, Verschlüsselungszähler

Ein ZT/ASL-Server 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. Ein ZT/ASL-Server 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. [<=]

A_26930 - ZT/ASL: ZT/ASL-Server, Response erstellen/verschlüsseln

In der ZT/ASL-Server wird der innere HTTP-Request (Ergebnis aus A_26928-*) fachlich verarbeitet und als Antwort eine innere HTTP-Response erzeugt. Diese ist der Klartext, der jetzt behandelt wird.

Ein ZT/ASL-Server MUSS analog zu A_26927-* einen Header erzeugen, wobei er

1. beim Response/Request-Byte den Wert 2 verwenden MUSS,
2. im Request-Counter den gespeicherten Wert aus A_26928-* (Eingang des Requests) verwenden MUSS.

Die anderen Header-Variablen MÜSSEN analog zu A_26927-* festgelegt werden.
Die Konstruktion des IV MUSS analog zu A_26927-* erfolgen, nur dass für den Verschlüsselungszähler der Wert nach A_26929-* (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_26927-*, 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_26931 - ZT/ASL: ZT/ASL-Client, Response entschlüsseln/auswerten

Ein ZT/ASL-Client MUSS bei Erhalt einer Antwort gemäß A_26930-* auf einen Request gemäß A_26927-* folgendes prüfen:

1. Ist die Länge der Datenstruktur (erweiterte Chiffrat) mindestens 72 Byte lang.
2. Ist die "PU/nonPU" Byte korrekt, i. sS v. korrekte Umgebung, in der auch der ZT/ASL-Client arbeitet.
3. Ist das Request/Response-Byte gleich 2.
4. Hat der Response-Counter den von Client erwarteten Wert.
5. 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. [<=]

A_26924 - ZT/ASL: ZT/ASL-Server, Erzeugung von Fehlermeldungen

Eine ZT/ASL-Server MUSS das Auftreten von Fehlern bei der Abarbeitung des ZT/ASL-Protokolls wie folgt an den ZT/ASL-Client melden.

Als HTTP-Response-Code MUSS der ZT/ASL-Server 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 [RFC-CBOR] serialisieren und per Mime-Type "application/cbor" [RFC-CBOR] (HTTP Content-Type) im äußeren Response-Body aufführen.

Ein ZT/ASL-Server 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_26928-* schlägt fehl.
403	7	"is not a request" A_26928-* (Prüfschritt 3)
403	8	"unknow KeyID"
403	9	"unknown CID"

[<=]

A_26925 - ZT/ASL: ZT/ASL-Client, Verarbeitung von Fehlermeldungen

Ein ZT/ASL-Client MUSS die Fehlermeldungen nach A_26924-* verarbeiten können.
[<=]

A_26942 - ZT/ASL-Client, Nichtproduktivumgebung, Offenlegung von symmetrischen Verbindungsschlüsseln

Ein ZT/ASL-Client in einer Nichtproduktivumgebung MUSS nach einer erfolgreichen Schlüsselaushandlung mit dem ZT/ASL-Protokoll die ausgehandelten symmetrischen Schlüssel K2_c2s_app_data und K2_s2c_app_data base64-kodiert innerhalb einer HTTP-Request-Header-Variable "ZT/ASL-nonPU-Tracing" bei jedem äußeren HTTP-Request aufführen. Dabei sind die beiden Base64-kodierten Schlüsselwerte durch Leerzeichen zu trennen. Beispiel:
    ZT/ASL-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. [<=]

A_26943 - ZT/ASL-Server, Nichtproduktivumgebung, Ablehnung von nonPU-Chiffraten in der PU

Ein ZT/ASL-Server in der Produktivumgebung MUSS äußere HTTPS-Request, die im Request-Header eine Variable "ZT/ASL-nonPU-Tracing" enthalten, mit einer HTTP-Fehlermeldung 403-Forbidden beantworten. Der ZT/ASL-Server MUSS sicherstellen, dass der innere Request (Chiffrat im Request-Body des äußeren Requests) nicht an einen Resource-Server weitergereicht wird.
Ein ZT/ASL-Server in der Produktivumgebung, die am Chiffrat am nonPU/PU-Byte erkennt (vgl. A_26927-*), dass es sich um ein nonPU-Chiffrat handelt, MUSS den Request mit einer Fehlermeldung an die äußere Schicht des Aktensystems (Webschnittstelle) beantworten. Der ZT/ASL-Server MUSS sicherstellen, dass das Chiffrat nicht entschlüsselt und das Chiffrat sicher gelöscht wird. [<=]