A_28578 - PoPP-Service - Pseudonymisierung bei den Telemetriedaten (Anomalie-Erkennung)

PoPP-Service - Pseudonymisierung bei den Telemetriedaten (Anomalie-Erkennung)
Der PoPP-Service MUSS bei der Pseudonymisierung von Daten im Kontext von A_26532-* folgende Vorgaben umsetzen:

1. Der PoPP-Service MUSS ein von der gematik/CDC bereitgestelltes Verschlüsselungszertifikat, integritäts- und authentitätsgeschützt in der VAU einpflegen (Initialisierung des Fachdienstes). (Hinweis: Das Verschlüsselungszertifikat ist ECC-basiert, d. h. auch der EE-Schlüssel ist ein ECC-Schlüssel.)
2. Der PoPP-Service MUSS auf Anweisung der gematik/CDC dieses Verschlüsselungszertifikat innerhalb von 5 Werktagen wechseln können. (Kontext: Regelmäßiger Wechsel des Verschlüsselungszertifikats)
3. Sei P die zu pseudonymisierende Zeichenkette. Der PoPP-Service MUSS am Ende von P solange Leerzeichen anfügen bis die Länge der somit erzeugten Zeichenkette ein Vielfaches von 32 ist. Sei Padding-Länge die Anzahl der hinzugefügten Leerzeichen. Diese Padding-Länge wird als Byte kodiert (Beispiel: Padding-Länge 0 würde als \x00 Byte kodiert) und der erzeugten Zeichenkette vorangestellt. Das Ergebnis wird als Plaintext bezeichnet.
4. Er MUSS diesen Plaintext mittels ECIES (AES/GCM) unter Verwendung des öffentlichen Verschlüsselungsschlüssels aus dem Verschlüsselungszertifikat aus Punkt 1 (bzw. 2) verschlüsseln.
1. Dabei MUSS der PoPP-Service ein ephemeres ECDH-Schlüsselpaar zufällig erzeugen und mit diesem und dem öffentlichen Schlüssel aus dem Verschlüsselungszertifikat 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-cdc-p17" verwenden, d. h. in der Formulierung von [RFC-5869] info="ecies-cdc-p17".
4. Er MUSS mit dieser Schlüsselableitung einen AES-128-Bit Content-Encryption-Key (CEK) für die Verwendung von AES/GCM ableiten.
5. Er MUSS für die Verschlüsselung mittels AES/GCM einen 96 Bit langen Null-Vektor (0…0) als Initialisierungsvektor (IV) verwenden.
6. Er MUSS mit dem CEK und dem IV mittels AES/GCM den Plaintext verschlüsseln, wobei dabei ein 128 Bit langer Authentication-Tag zu verwenden ist.
7. Aus dem Verschlüsselungszertifikat MUSS er den SubjectKeyIdentifier (SKI) entnehmen und die ersten 16 Bit als „gekürzter SKI“ im folgenden Schritt verwenden.
8. Er MUSS das Ergebnis wie folgt kodieren: chr(0x02) || <gekürzter SKI> || <32 Byte X-Koordinate des öffentlichen Schlüssels aus (a) > || <AES-GCM-Chiffrat> || <16 Byte AuthenticationTag>. (Hinweis: es fehlt absichtlich die Y-Koordinate und der IV).
9. Die X-Koordinate ist (wie üblich) vorne mit chr(0) zu padden solange bis sie eine Kodierungslänge von 32 Byte erreicht. Die Byte-Order MUSS Network-Byte-Order (= Big) sein.
10. Das so kodierte Ergebnis wird als erweitertes Chiffrat bezeichnet.
5. Der PoPP-Service MUSS das erweiterte Chiffrat mittels Base64 kodieren. Das Ergebnis ist ein Pseudonym von P (vgl. Punkt 3).