Seitenvergleich

...

• im Folgenden sind Ergebnisse aus einer Simulation mit künstlich generierten Daten dargestellt

• ermittelter Platzbedarf für eine .xml Datei mit 1.000 Patienten: 18 MB

• das gilt für bei Verzicht auf Formatierung, “pretty formatting” verdoppelt etwa die Dateigrösse (wird natürlich nicht verwendet für Lieferung)

• Packen als .zip: → 1,5 MB

• die Dateigrösse korreliert relativ gut mit der Patientenanzahl, Hochrechnungen wären also grundsätzlich denkbar

• getroffene Annahmen / Merkmale der Datei

  • .xml ist valide gegen oBDS-RKI

  • 2 Tumore pro Patient

  • alle optionalen Elemente sind gesetzt

  • Freitexte auf 10 Zeichen Länge gesetzt als angenommener Durchschnittswert

  • Klassifikationen sind “echte” Ausprägungen gemäß den jeweiligen Wertebereichen

  • alle in “Menge_” gekapselten Elemente (OP, ST, Folgeereignis etc) sind in zufälliger Anzahl zwischen 1 und 3 erzeugt

• Schlussfolgerung: auf Basis der Annahmen dieser Simulation erscheint eine Stückelung auf 10.000 Patienten pro Datei machbar

Vorschlag Lieferprozess (DRAFT)

Setup Verschlüsselung

Details Schlüsselmaterial

• RKI generiert neues Schlüsselpaar Schlüsselmaterial für asymmetrische Verschlüsselung gemäß anwendbaren Regularien (RKI verwendet bislang 2048 bit RSA key im pgp Verfahren für die epi-Daten)öffentlicher Teil des Schlüssels wird den Lieferregistern bekannt gegebenmit folgenden Eigenschaften:

  • Bitlänge: 4096

  • Signaturalgorithmus: sha256RSA

  • Ausgestellt durch: anfangs selbst-signiert, ab Folgejahr durch PKI CA am RKI

  • Gültigkeitsdauer: bei selbst-signiertem Schlüssel 1y, danach 2y (ggf. Verlängerung mit privatem Schlüssel)

  • Schlüsselverwendung: Datenverschlüsselung

• öffentlicher Schlüssel

  • gespeichert im PEM Format

  • wird den definierten Ansprechpersonen der Lieferregistern bekannt gegeben, sobald PKI CA anwendbar ist kann der public key via Webseite bekannt gemacht werden

• privater Schlüssel

  • gespeichert im ECPrivate Key Format

  • verbleibt ausschließlich im RKI

Details Verschlüsselung

• verwendeter Algorithmus für die Implementierung ist brainpoolP256r1 (in Anlehnung an RÜD Umsetzungsleitfaden 3.0.0)

• Format zum Speichern der Bits als String: base64

• Message Authentication Code (MAC) Algorithmus: HMAC mit SHA256 gem. BSI TR02102

• Generierung des MAC keys: umgekehrte Bytereihenfolge des symmetrischen Schlüssels

• Schlüsselableitungsfunktion: HMAC

• Format zum Speichern des Tripels der ECIES Nachricht: JWT Format (erweitert um Initialisierungsvektor)

Nutzung des Transportschemas KKRTransport

• verschlüsselte Daten werden unter data in das Transportschema eingebettet

  • Institutskennzeichen receiver_ik kann nicht vergeben werden, darum Verwendung von dummy Wert 000000000

  • auf Signaturbildung wird verzichtet aufgrund der gewählten Sicherheitsarchitektur. Im Feld signatureAlgorithm kann dann ebenfalls ein dummy Wert verwendet werden, etwa none

  • alle Dateien werden dann in einen (bzw. einige) zip Ordner organisiert

Lieferung - Register

• die Lieferung erfolgt jährlich

• Register generiert n Dateien mit Daten im Lieferschema gemäß Stückelung

• es werden alle Daten erfasst (“Volllieferung”)

• diese Daten werden pro Datei

  • mit dem öffentlichen Schlüssel für Lieferung ans RKI behandelt

  • als payload in eine Datei eingebettet gemäß Schema KKRTransport

  • basierend auf der dann aktuellen Definition KKRTransport (derzeit v2.0.0)?

  • RKI benötigte dann Institutskennzeichen receiver_ik? Alternativ kann das Feld leer bleiben?

  • Signaturbildung der KR: im ersten Schritt nicht vorgesehen, aber mglw. erforderlich aufgrund Sicherheitsüberlegungen

  • PGP-Verschlüsselung ist vorerst gesetzt, RÜD-REST wird nicht angewendet

  Sendung EPI vs. klinisch: vorgesehen ist die gemischte / integrierte Übermittlung. Für eine reine epi Übermittlung könnten bestehende Wege genutzt werden

  verschlüsselt

  • in KKRTransport eingebettet

• alle Dateien werden dann in einen (bzw. einige) zip Ordner organisiert

  dieser Ordner wird per cryptshare (https://austausch.rki.de) an ein Funktionspostfach im ZfKD gesendet

• der Transport der zu liefernden Dateien erfolgt über den sicheren Austauschserver des RKI “cryptshare”

• es wird ein Muster für ein bundesweit gültiges, jährlich wechselndes Transferpasswort mit den definierten Ansprechpersonen ausgetauscht aufgrund der Ende-zu-Ende-Verschlüsselung der transportierten Daten kann ein einheitliches Transportpasswortes verwendet werden

Empfang - RKI

• das verwendete cryptshare Passwort wird dem RKI bekannt gemacht

• RKI lädt Datein von cryptshare und entpackt .zip in einen dedizierten Ordner

• ein dafür implementiertes import tool

  • erfasst alle Dateien in diesem Ordner

  • entschlüsselt mittels private key

  • validiert jede einzelne xml und protokolliert das Ergebnis

  • überführt den xml Inhalt in ein zum vereinbarten Schema passendes relationales Modell

...