Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- dighealth:ti:sicherheit:rsa-ecc [2025/09/23 08:54] – [Allgemein] fjh
+++ dighealth:ti:sicherheit:rsa-ecc [2026/04/16 08:23] (aktuell) – [Konnektor] fjh
@@ Zeile 1: / Zeile 1: @@
 ====== RSA-ECC-Migration ======
+===== Hintergrund =====
+<note>
+Nach Angaben der Betreibergesellschaft der TI sind aktuell knapp 93 Prozent der Primärsysteme und 90 Prozent der KIM-Clientmodule laut Selbstauskunft auf ECC umgestellt. Die Anzahl der Konnektoren, die derzeit noch ausschließlich mit RSA-Zertifikaten laufe, liege derzeit bei 1.449 (Stand: 02.01.2026)((s. https://www.aerztezeitung.de/Wirtschaft/TI-Verschluesselung-gematik-wirbt-mit-Kurzleitfaden-fuer-schnelle-Umstellung-461574.html.))
+</note>
+<note important>Übergangslösung für eHBA bis 30.06.2025
+Das bedeutet im Einzelnen:
+   * HBA, die Zertifikate mit RSA-Verschlüsselung enthalten, können noch bis zum 30. Juni 2026 von betroffenen Leistungserbringenden genutzt werden. Danach können nur noch HBA mit ECC-basierten Zertifikaten eingesetzt werden, um beispielsweise E-Rezepte zu signieren.
+   * Ab dem 1. Januar 2026 dürfen die Kartenanbieter ausschließlich ECC-fähige Karten produzieren und ausgeben, die keine RSA-Zertifikate mehr enthalten.((https://www.gematik.de/newsroom/news-detail/aktuelle-information-ti-verschluesselungsalgorithmen-umstellung-von-rsa-auf-ecc.))
+</note>
 Die Telematikinfrastruktur (TI) stellt ihre Kryptografie von RSA (Rivest-Shamir-Adleman) auf die modernere ECC (Elliptic Curve Cryptography) um. Die Umstellung ist notwendig, da gemäß [[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf?__blob=publicationFile|Technischer Richtlinie]] des Bundesamtes für Sicherheit in der Informationstechnik (BSI)((BSI TR-02102-1 - Kryptographische Verfahren: Empfehlungen und Schlüssellängen.)) RSA (1900–3000 Bit) (im Folgenden als RSA-2048 betitelt) nur noch befristet bis Ende 2025 zulässig ist. Auch der europäische [[https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.3.pdf|SOGIS-Katalog]] fordert diese Umstellung.((SOG-IS Crypto Evaluation Scheme
@@ Zeile 14: / Zeile 31: @@
   * **__nonQES__**: Hier liegt die Verantwortung bei der gematik in Abstimmung (im Benehmen) mit dem BSI. Die gematik sieht hier in Einzelfällen einen gewissen Handlungsspielraum, auch wenn das BSI (natürlich) von der Verwendung von RSA-2048 über den 31.12.2025 hinaus abrät. Somit wird es wohl darauf hinauslaufen, dass diese Anforderung kommuniziert und eingefordert wird, aber RSA-2048 in gewissen Einzelfällen bzw. für gewissen Komponenten und Dienste für (vermutlich unterschiedliche) Zeiträume toleriert wird.
-===== Allgemein =====
+<note important>Wichtige Afo der gematik bzgl. Laufzeitbegrenzung von RSA-Zertifikaten
+https://gemspec.gematik.de/docs/gemSpec/gemSpec_Krypt/latest/#A_15590
+A_15590 - Zertifikatslaufzeit bei Erstellung von X.509-Zertifikaten mit RSA 2048 Bit
+Ein TSP-X.509-nonQES, der X.509-Zertifikate erstellt auf Basis der Schlüsselgeneration „RSA“ (d. h., für den die Vorgaben aus Tab_KRYPT_002 gelten), MUSS das Ende der Zertifikatsgültigkeitsdauer für das auszustellende Zertifikat unabhängig von der in Tab_KRYPT_002 festgelegten Endedaten der Zulässigkeit der verwendeten RSA-Schlüssellängen festlegen.
+Erläuterung: Die technische Durchsetzung des Endes der Zulässigkeit von RSA mit weniger als 3000 Bit Schlüssellänge in X.509-Zertifikaten erfolgt durch die Herausnahme der entsprechenden RSA-basierten Sub-CA-Zertifikate aus der TSL zum Zeitpunkt des Ablaufens der Zulässigkeit (gemäß TIP1-A_2062). Ein TSP muss bez. der Zertifikatsgültigkeitsdauer der von ihm ausgegebenen Zertifikate das nach Spezifikationslage definierte Verhalten zeigen (i. A. Zertifikatsgültigkeitsdauer der ausgegebenen Zertifikate von 5 Jahren). Ein TSP kann auch mit dem Kartenherausgeber beliebige Gültigkeitsdauern unter 5 Jahren für die Laufzeit der vom TSP ausgegebenen Zertifikate vereinbaren.
+</note>
+===== Probleme nach Umstellung =====
+==== TI-Zugang ====
+  * Betroffen sind ca. 2000 SMC-B der medisign, deren RSA-Zertifikat (C.HCI.OSIG) zum 31.12.2025 abläuft, während die ECC-Zertifikate weiter gültig sind.
+  * Gleichzeitig wird bei vielen (täglich notwendigen) Konnektorregistrierungen am VPN-Zugangsdienst das ECC-Zertifikat genutzt, wobei allerdings die Signatur der Registrierung dann mit dem RSA-Zertifikat erfolgt.
+  * Durch Kombination dieser beiden Ursachen entsteht ein Problem, weil die Zugangsdienste wegen der abgelaufenen Zertifikate entsprechende Registrierungen aus ihrer Datenbank entfernen. Dadurch scheitern die Registrierungen dann natürlich und der TI-Zugang funktioniert nicht mehr.
+  * Betroffen sind KoCo-Konnektoren (und CGM-Zugangsdienst) sowie Secunet-Konnektoren (meist mit arvato-Zugangsdienst). RISE-Konnektoren sind nicht betroffen.
+  * Lösungsmöglichkeit für secunet: Neuregistrierung des Konnektors mit ECC-Zertifikat und Firmware-Update auf neueste Version 5.70.6 (T-Systems und arvato).
+  * Lösung für CGM ist bereits erfolgt: Die betroffenen Registrierungseinträge wurden am Zugangsdienst wieder eingespielt.((https://www.apotheke-adhoc.de/nachrichten/detail/e-health/medisign-workaround-fuer-smc-b-probleme/.))
+Quelle: gematik und https://www.aerzteblatt.de/news/konnektoren-und-smc-b-karten-bestimmte-kombinationen-fuhren-zu-ti-ausfall-a011b1f0-511c-4c07-8b6e-b3dcc81f798e
+Medisign selbst dazu: https://www.medisign.de/blog/smc-b-so-lassen-sich-probleme-beim-ti-zugang-loesen/
+==== NFDM ====
+Für PTV5 kaputt s. unten
+===== Details zur Migration =====
 Diverse Komponenten der TI müssen ECC-ready sein bzw. dahin migriert werden, insbesondere natürlich alle zentralen Dienst, aber auch die folgenden im Detail betrachteten Komponenten.
@@ Zeile 23: / Zeile 77: @@
   * Konnektoren, deren gSMC-K noch RSA-only ist, müssen bis Ende 2026 ausgetauscht bzw. auf das TI-Gateway migriert werden. Dabei handelt es sich um 28.000 Secunet-Konnektoren und 4500 CGM/KoCo-Konnektoren.((https://www.hausaerztlichepraxis.digital/praxis/e-health-und-it/ti-komponenten-im-check-wer-muss-tauschen-167623.html.))
-  * Ausgetauscht bzw. migriert werden müssten (voraussichtlich) auch alle Konnektoren, die ECC auf der gSMC-K haben, aber die bis Ende 2025, aber deren Zertifikate bis Ende 2025 auslaufen, da auf Basis von PTV5+ eine weitere Laufzeitverlängerung nicht möglich ist.
+  * Ausgetauscht bzw. migriert werden müssten (voraussichtlich) auch alle Konnektoren, die ECC auf der gSMC-K haben, aber deren Zertifikate bis Ende 2025 auslaufen, da auf Basis von PTV5+ eine weitere Laufzeitverlängerung nicht möglich ist.
   * Erst der Konnektor der Produkttypversion 6 (PTV6-Konnektor) erzwingt die Nutzung von ECC-Zertifikaten.
   * Der flächendeckende Rollout des PTV-6-Konnektors ist also Voraussetzung für eine reibungslose Migration auch der anderen Komponenten hin zu ECC.
@@ Zeile 53: / Zeile 107: @@
 ==== eHBA ====
+<note important>gematik verlängert Frist für den Austausch bis 30.06.2026: https://www.aerztezeitung.de/Wirtschaft/gematik-verlaengert-Uebergangsfrist-fuer-Austausch-der-E-Arztausweise-461018.html#:~:text=Nachdem%20die%20Berichte%20%C3%BCber%20Probleme,Konnektoren%20gibt%20es%20keinen%20Aufschub.</note>
   * **Massentausch aller eHBA der Generation 2.0 (G2.0) in eHBA der Generation 2.1 (G2.1) bis 31.12.2025**
@@ Zeile 59: / Zeile 115: @@
     * **__Ergebnis:__**
       * Alle Leistungserbringenden besitzen einen eHBA, der es Ihnen ermöglicht, ECC-QES-Signaturen zu erstellen.
-  * **Massensperrung aller noch gültigen RSA-QES-Zertifikate** durch die VDA (über OSCP voraussichtlich) **zum Stichtag 31.12.2025**. Bei einem VDA sind die QES-HBA-Zertifikate sowieso nur mit der Gültigkeit bis 31.12.2025 ausgestellt worden.
+  * **Massensperrung aller noch gültigen RSA-QES-Zertifikate** (auch auf den G2.1-Karten mit RSA!!!) durch die VDA (über OSCP voraussichtlich) **zum Stichtag 31.12.2025**. Bei einem VDA sind die QES-HBA-Zertifikate sowieso nur mit der Gültigkeit bis 31.12.2025 ausgestellt worden.
     * **__Ergebnis:__**
       * eHBA G2.0 sind ab dem Stichtag nicht mehr für eine QES-Signatur nutzbar. Ärzt*innen, die bis dahin keinen eHBA G2.1 besitzen, können somit keine E-Rezepte und auch keine eAU mehr ausstellen, da der Konnektor sowohl das Endentitäts-Zertifikat (auch über OCSP) als auch das zugehörige QES-CA-Zertifikat bei der Erstellung prüft.((Vgl. dazu in der Konnektorspec den [[https://gemspec.gematik.de/docs/gemSpec/gemSpec_Kon/latest/#4.1.8.4.3|TUC_KON_150 "Dokumente signieren"]], der vom Primärsystem über die Operation SignDocument() aufgerufen wird. Dieser ruft u.a. den [[https://gemspec.gematik.de/docs/gemSpec/gemSpec_Kon/latest/#4.1.8.3.8|TUC_KON_159 "Signaturdatenelemente nachbereiten]]" auf, der die Signatur prüft. Die Prüfung des Zertifikats erfolgt über [[https://gemspec.gematik.de/docs/gemSpec/gemSpec_Kon/latest/#4.1.9.4.1|TUC_KON_037 "Zertifikat prüfen"]]. Dieser wiederum nutzt intern den [[https://gemspec.gematik.de/docs/gemSpec/gemSpec_PKI/latest/#8.5.1|TUC_PKI_030 "QES-Zertifikatsprüfung"]] zur Zertifikatsprüfung.))