Seitenvergleich

...

Vorschlag Lieferprozess (DRAFT)

Setup Verschlüsselung

...

Details Schlüsselmaterial

• RKI generiert neues Schlüsselmateriel für asymmetrische Verschlüsselung mit 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 Teil des Schlüssels 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 verbleibt ausschließlich im RKI in Hand des Fachverantwortlichen und im KeyStore des entschlüsselnden Servers

Transportverschlüsselung

• 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

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

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 als payload in eine Datei eingebettet

  gemäß Schema KKRTransport basierend auf der dann aktuellen Definition

  analog dem beim RÜD verwendeten Schema KKRTransport

  • 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

    dieser Ordner wird per cryptshare an ein Funktionspostfach im ZfKD gesendet

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

  • verschlüsselt

  • in KKRTransport eingebettet

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

• der Transport der zu liefernden Dateien erfolgt über den sicheren Austauschserver des RKI “cryptshare” an ein Funktionspostfach im ZfKD

• 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

...