Disclaimer

Diese Seite wird stetig verbessert und mit neuen Informationen gefüllt. Wir empfehlen Ihnen diese Seite zu "beobachten", um bei Aktualisierungen informiert zu werden. 



Ziel der ECC-preferred Migration von Primärsystemen mit PTV 6 Konnektoren

Kurz zum Hintergrund: Am 01.01.2026 wird RSA in der TI abgeschaltet. Bereits Mitte 2025 werden die Konnektoren auf PTV6 mit ECC preferred umgestellt, sodass auch alle Primärsysteme sowie entsprechende Komponenten und Dienste die ECC preferred Migration bis Mitte 2025 abgeschlossen haben sollten – auch um in den verbleibenden Monaten ggf. noch Fehlerbehebungen durchzuführen.



Was bedeutet ECC-ready?

Die Komponente kann funktional mit ECC umgehen. ECC ready ist nicht ausreichend, dass die TI nach der RSA Abschaltung fehlerfrei funktioniert. Sie können Limitierungen den ECC-ready Funktionalität in der ECC Testwoche überprüfen (siehe RSA Abschaltung / ECC Testwoche).

Was bedeutet ECC-preferred?
1. Wenn RSA vom Konnektor angefordert wird, jedoch Karten und Konnektor ECC können, dann wird ECC zurückgegeben.
2. Der PTV6 Konnektor akzeptiert keine neuen RSA basierten TLS Clientsystem-Verbindungen, jedoch bleiben vorhandene Verbindungen bestehen.


Zeitplan der ECC-Migration

Rückblick

Die gematik hat im Jahr 2016 ein Konzept für die ECC-Migration erstellt und mit den Gesellschaftern in mehreren Workshops abgestimmt. Im Vordergrund stand die Vorbereitung der Karten und der zugehörigen PKI (Phase 1).

Im Jahr 2018 wurde dann mit der Phase 2 begonnen, in welcher der Beginn der Dual-Mode-Fähigkeit der Komponenten und Dienste der Telematikinfrastruktur eingeläutet wurde. Das entsprechende Konzept gab einen aktualisierten Überblick über die drei vorgesehenen Phasen der Migration, den Umsetzungsstand der Phase 1 und fokussierte auf den geplanten Aktivitäten der Phase 2 im Sinne eines Grobkonzepts. Daraus abgeleitete Änderungsbedarfe an Komponenten und Diensten der TI wurden in den Folgejahren schrittweise umgesetzt und ins Feld gebracht. Den Abschluss der Phase 2 mit der Erwartung, dass sich alle im Feld befindlichen TI Komponenten im "ECC-ready" Status befinden erfolgte Mitte 2024.

Phase 3

Das übergeordnete Ziel der Phase 3 der ECC-Migration ist das Phase-Out der aktiven Nutzung RSA-basierter Identitäten. Die aktive Nutzung meint dabei die Verwendung öffentlicher und privater RSA-Schlüssel zur Erzeugung RSA-verschlüsselter oder signierter Elemente. Dem gegenüber soll eine "passive" Nutzung vorhandener RSA-Schlüssel nicht verboten werden, um weiterhin Daten entschlüsseln und Signaturen prüfen zu können.

Zunächst war ein RSA-Phaseout für den Jahreswechsel 2023/2024 vorgesehen, In Abstimmung mit dem BSI und gemäß der Vorgaben der technischen Richtlinien wurde das Enddatum der RSA-2048-Kryptografie auf den 31.12.2025 festgelegt (siehe auch gemSpec_Krypt Kapitel 5 "Migration 120-Bit-Sicherheitsniveau"). 

Voraussetzung für das Ausphasen der aktiven Nutzung RSA-basierter Identitäten ist, dass alle TI Komponenten im Feld "ECC-preferred" kompatibel sind. 



Hintergrundinformationen

TI Kryptographie: In der TI werden verschiedene Algorithmen zur Verschlüsselung, Signierung und Authentifizierung verwendet. Als die TI 1.0 entwickelt wurde, war RSA der Standardalgorithmus für asymmetrische Kryptographie. Im Jahr 2014 ist man dazu übergegangen, auf den moderneren ECC-Algorithmus zu setzen, der bei gleicher Sicherheit mit kleineren Schlüsseln auskommt und somit effizienter Berechnungen durchführen kann.

Die Vorgaben: Das BSI hat 2018 mit der Veröffentlichung der Technischen Richtline TR-03116-1 "Kryptographische Vorgaben für Projekte der Bundesregierung, Teil 1: Telematikinfrastruktur" festgelegt, dass RSA bis Ende 2024+ in der TI verwendet werden kann. Eine aktuellere Version konnte bisher noch nicht veröffentlicht werden. Weiterhin legt [SOG-IS-2020] konkretisierend dazu fest:

Note 27-LegacyRSA. 
The acceptability deadline for the legacy use of modulus of size above 1900 bits, but less that 3000 bits, is set to December 31, 2025

Zusätzlich legt die gemSpec_Krypt fest, dass die Gültigkeitszeiträume der RSA Algorithmen "zulässig bis gemäß [SOG-IS-2020]" sind. Dies wurde für Konnektor PTVen und ePA 2.5 entsprechend in die Kommentierung gegeben und veröffentlicht. Daher ist der 31. Dezember 2025 aus [SOG-IS-2020] der mit den Gesellschaftern vereinbarte Stichtag.

Allgemein lässt sich sagen, dass weder RSA noch ECC grundsätzlich „sicherer“ ist, vielmehr hängt die Sicherheit von der korrekten Implementierung, der gewählten Schlüssellänge und dem Kontext, in dem sie verwendet werden, ab. Beide sind unter aktuellen Bedingungen mit klassischen Computern sicher, solange ausreichend lange Schlüssel und gute kryptographische Praktiken verwendet werden. Beide Algorithmen sind theoretisch durch den Fortschritt bei Quantencomputern bedroht.


Auswirkungen auf Primärsysteme 

Die Maßgabe ist: Verwende ECC wo möglich und RSA nur noch, wo unbedingt erforderlich.




Mit den nachfolgenden Checklisten wollen wir Ihnen eine Möglichkeit zur Überprüfung der ECC preferred Fähigkeit Ihrer Software mitgeben. Die Checklisten werden unterteilt in Implementierung & Testvorbereitung, Testdurchführung und Auswertung. Wir empfehlen Ihnen, alle Punkte durchzugehen und zu prüfen.

Checkliste Implementierung und Testvorbereitung ECC preferred

  • neue Versionen der Implementierungsleitfäden lesen und entsprechend den Vorgaben implementieren: https://gemspec.gematik.de/docs/gemILF/

  • notwendige Änderungen im Quellcode des Primärsystems

    • Bitte prüfen Sie, ob Sie den optionalen Parameter "crypt" bei den SignDocument und EncryptDocument Aufrufen auf RSA setzen. Wenn ja, dann können Sie den Parameter komplett weglassen, er wird ab PTV6 nicht mehr ausgewertet. Um herauszufinden ob RSA oder ECC verwendet wurde, kann die Operation ReadCardCertificate verwendet werden:
      • "ReadCardCertificate" gibt das Zertifikat zurück, mit dem der Konnektor signieren / verschlüsseln würde 
    • zu verwendende ECC Kurven bei Clientsystemauthentisierung (Brainpool und NIST, siehe gemSpec_Krypt) 
  • keine Änderungen sind notwendig
    • bei ExternalAuthenticate
  • empfohlenes Testsetup zur Testdurchführung
    • Konnektoren: Nutzung der neuesten PTV6 Konnektorversion
    • Karten: G2.1 Karten verwenden, diese besitzen RSA und ECC Zertifikate

Checkliste Testdurchführung ECC preferred

Checkliste Auswertung ECC preferred


Umfang der ECC-Funktionalität aus Sicht der Primärsysteme

Die folgenden Tabellen enthalten die relevanten Use Cases und Funktionalitäten, welche geprüft und getestet werden müssen.

Übersicht der relevanten Use Cases

In den Tabellen werden folgende Abkürzungen für beteiligte Produkte verwendet:

  • Primärsystem (PS)

  • Praxisverwaltungssystem (PVS)
  • Apothekenverwaltungssystem (AVS)

  • Konnektor (KON)

  • Kartenterminal (KT)

  • Aktensystem (AS)

  • KIM Clientmodul (CM)
  • Fachdienst VSDM (FD VSDM)
  • Intermediär VSDM (IMV)
  • Krankenversichertenkarte (KVK)

ePA 3 (ePA für alle) Use Cases

Use Case Name

Quellen:

gemILF_PS_ePA, ab Version 3.0.0

Was sollten PS Hersteller tun

beteiligte Produkte

woran ist für den PS Hersteller zu erkennen, dass Use Case mit ECC erfolgreich war

Aufbau einer User Session beim Aktensystem (IDP-Flow) mit einer SMC-B G2.1;

  • Nonce signieren als ECDSA-Signatur mit external Authenticate

  • Challenge signieren als ECDSA-Signatur mit external Authenticate
  • ReadCardCertificate Parameter Crypt auf ECC gesetzt 
PS, KON, KT, Karte, AS

Die Authentisierung beim IDP ist erfolgreich. Im ReadCardCertificate wurde das ECC-Zertifikat ausgelesen. 

Einstellen einer Befugnis im Behandlungskontext

  • Prüfziffer als JWS signieren als ECDSA-Signatur mit ExternalAuthenticate
PS, KON, KT, Karte, AS Die Befugnis wurde erfolgreich beim AS eingestellt.

KIM Use Cases

Use Case Name

Quellen: 

gemSpec_CM_KOMLE, ab Version 1.1.19

Was sollten PS Hersteller tunbeteiligte Produkteworan ist für den PS Hersteller zu erkennen, dass Use Case mit ECC erfolgreich war

KIM Payload (eAU, EBZ, eArztbrief) mit Konnektor QES signieren / verifizieren

  • "crypt" Parameter wird nicht mehr ausgewertet
  • Defaultwerte ändern sich von RSA zu ECC
PS, CM, KON, KT, Karte, Das Payload Dokument konnte erfolgreich signiert (keine Fehlermeldungen) und dann auch wieder verifiziert werden (im Idealfall auch von einem anderen Konnektorhersteller)

KIM Payload (eAU, EBZ, eArztbrief) mit Konnektor verschlüsseln / entschlüsseln

  • "crypt" Parameter wird nicht mehr ausgewertet
  • Defaultwerte ändern sich von RSA zu ECC
PS, CM, KON, KT, Kartesiehe Eintrag "verschlüsseln / entschlüsseln" im Abschnitt 

"übergreifende Funktionalitäten"

Transportsicherung zwischen Clientsystem und Clientmodul

Gemäß gemSpec_CM_KOMLE Kapitel 4.1.2 "Transportsicherung zwischen Clientsystem und Clientmodul" muss die Kommunikation zwischen Clientsystem und Clientmodul geschützt werden. Im Rahmen des TLS Verbindungsaufbau (sowohl SMTP als auch POP3) präsentiert das KIM Clientmodul Zertifikatsmaterial welches maßgebend für den jeweiligen Verbindungsaufbau ist. Bisher handeltes sich an dieser Stelle um ein "RSA-Zertifikat". Mit der Migration in Richtung ECC wird dies dann zur ausschließlichen Nutzung von ECC Schlüsselmaterial führen - was bedeutet, dass die im Feld befindlichen Clientsysteme (PVS + Mailclient) diesen Wechsel des Schlüsselmaterials unterstützen müssen.

Die Anleitung des Schlüsselwechsels ist beim jeweiligen KIM Clientmodul Hersteller zu erfragen.

PS, CM


eRezept Use Cases

Use Case Name

Quellen:

gemILF_PS, ab Version 2.23.0

gemILF_PS_eRp

Was sollten PS Hersteller tunbeteiligte Produkteworan ist für den PS Hersteller zu erkennen, dass Use Case mit ECC erfolgreich war

IdP Token mit SMC-B -> mit richtigem Zertifikat (ECC)

gemILF_PS_eRp

Kapitel 5.1.4.2 Abruf von Token beim IDP Dienst

ExternalAuthenticate, ReadCardCertificate aus gemSpec_KON und gem_ILF_PS


PS, KON, KT, Karte,Authentisierung beim IdP erfolgreich. Im ReadCardCertificate wurde das ECC-Zertifikat ausgelesen. 
Verordnungsdatensatz mit ECC signieren
PVS, KON, KT, HBARequest wird vom Fachdienst akzeptiert. es gibt keine Fehlermeldung 
Abgabedatensatz mit ECC signieren
AVS, KON, KT, SMC-B/HBARequest wird vom Fachdienst akzeptiert. es gibt keine Fehlermeldung

Alternative Zuweisung - E-Rezept Daten entschlüsseln (Optional)


AVS, KON, SMC-BEntschlüsselung hat funktioniert

VSDM Use Cases

Use Case NameWas sollten PS Hersteller tunbeteiligte Produkteworan ist für den PS Hersteller zu erkennen, dass Use Case mit ECC erfolgreich war

VSDM

TLS Nutzung, ReadVSD Operation durchführenPS, KON, IMV, FD VSDMReadVSD Operation ist erfolgreich

VSDM - Read KVK

(Privatversicherte/Beamte),

Read KVK Operation durchführenPS, KON, KT, KVKReadKVK Operation ist erfolgreich

übergreifende Funktionalitäten (Konnektor, Kartenterminal, Karten, IdP)

Use Case Name

Quellen:

gemILF_PS, ab Version 2.23.0

gemSpec_Kon

Was sollten PS Hersteller tunbeteiligte Produkteworan ist für den PS Hersteller zu erkennen, dass der Use Case mit ECC erfolgreich war

Interface-Änderungen am Konnektor PTV6

die neuen Schnittstellen von PTV6 unterstützen

PS, KON

TLS Verbindung zum Konnektor

Der Konnektor kann so konfiguriert werden, dass er eine TLS Verbindung zum Primärsystem herstellt. Dies ist für die Nutzung der Komfortsignatur oder des TI-Gateways verpflichtend. Im Test sollte geprüft werden, ob der Konnektor die TLS Verbindung mit ECC NIST Zertifikaten aufbauen kann. Dabei kann man sowohl Brainpool als auch NIST Zertifikate verwenden, sich Zertifikate vom Konnektor generieren lassen oder extern erstellte nutzen. PS, KON, KT, Karte

Zur Überprüfung der genutzten Zertifikate kann der TLS Handshake mit Wireshark ausgewertet werden. 

Im Management Interface des Konnektors prüfen, welches Authentisierungsverfahren eingestellt ist (TLS und welcher Algorithmus).

Clientauthentisierung auf ECC NIST Kurven umstellen

Zertifikate mit ECC NIST statt Brainpool-Kurven zu generieren (auch nicht außerhalb des Konnektors).

Hintergrund: viele Browser können nicht  mit ECC Brainpool Kurven umgehen und damit wäre die Konnektor Management UI nicht zugänglich.

PS, KON

Falls implementiert: CA des Konnektorzertifikates prüfen

PS sollte warnen, wenn RSA Zertifikate registriert sind und zur Neugenerierung auffordern.

PS, KON

Re-Registrierung mit ECC am VPN-ZugD

Falls die automatische Re-Registrierung fehlschlägt, muss das PS den Nutzer informieren, dass manuelle Konfigurationen notwendig sind.

gemILF_PS/latest/ Kapitel: 4.1.4.3

PS, KON, Karte, VPN-Zugangsdienst

signieren / verifizieren


  • "crypt" Parameter wird nicht mehr ausgewertet
  • Defaultwerte ändern sich von RSA zu ECC
PS, KON, KT, Karte

ein Dokument konnte erfolgreich signiert werden (keine Fehlermeldungen) und dann auch wieder verifiziert (im Idealfall auch von anderen Konnektorherstellern)

Signieren

mit ReadCardCertificate mit crypt Parameter ECC Zertifikat der SMC-B / HBA lesen, dann vergleichen, ob in signiertem Dokument das gleiche Zertifikat enthalten ist wie die Rückgabe von ReadCardCertificate

Zertifikate können binär verglichen werden => Andreas Haloff nochmal fragen ob möglich

verschlüsseln / entschlüsseln
  • "crypt" Parameter wird nicht mehr ausgewertet
  • Defaultwerte ändern sich von RSA zu ECC
PS, KON, KT, Karte

ein Dokument konnte erfolgreich verschlüsselt werden (keine Fehlermeldungen) und dann nach dem Verschlüsseln nachgewiesen werden, dass das Dokument tatsächlich mit ECC verschlüsselt wurde:

*Mit welchem Verfahren das Dokument verschlüsselt wurde kann wie folgt ermittelt werden:

1)  Suche das Element ecPublicKey entsprechend der DER-Codierung aus https://gemspec.gematik.de/docs/gemSpec/gemSpec_Krypt/latest/#5.9, z.B. 

$ openssl ec -in example-named-curve-private-key.pem  -pubout -outform der -out mykey.pub
$ dumpasn1 mykey.pub
  0  90: SEQUENCE {
  2  20:   SEQUENCE {
  4   7:     OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
 13   9:     OBJECT IDENTIFIER brainpoolP256r1 (1 3 36 3 3 2 8 1 1 7)
       :     }
 24  66:   BIT STRING
       :     04 2A 5C 16 C6 93 DD FF 8E F4 28 3A EF A9 91 59
       :     1E 16 6B 3A EB 6C 53 1C 31 9E 5D C0 98 6B 85 5B
       :     23 4B 30 37 CF CE 6A BB C7 82 4A F0 24 13 78 ED
       :     DB E9 CE 4C D8 75 B3 71 31 91 95 52 38 90 F5 68
       :     B7
       :   }

2) Wenn ecPublicKey gefunden wird, dann ist das Dokument ECC verschlüsselt. Wenn nicht, kann von RSA-Verschlüsselung ausgegangen werden


SMC-B über das PVS aktivierenNutzer durch Fehlermeldung informieren, wenn RSA verwendet wirdPS, KON, KT, KarteAktivierung kann ohne Fehlermeldung durchgeführt werden

Ablaufdatum des eHKTs am PVS anzeigen

  • Ablaufdatum aus dem ECC Zertifikat der gSMC-KT lesen (EF.C.SMKT.AUT2)
PS, KON, KT, Karte
ReadCardCertificate und VerifyCertificate
  • "crypt" Parameter wird nicht mehr ausgewertet
  • Defaultwerte ändern sich von RSA zu ECC
PS, KON, KT, KarteFunktioniert fehlerfrei auch für ECC Zertifikate
Remote SMC-B PIN über WebNutzer durch Fehlermeldung informieren, wenn RSA verwendet wirdPS, KON, KT, Karte
  • Fehlermeldung, wenn RSA verwendet wird
  • Freischaltung durch den Aufruf der Operation verifyPIN, bei ECC


  • No labels

© gematik GmbH 2024