Diese Seite wird entsprechend des aktuellen Kenntnisstandes stetig erweitert. Wir empfehlen Ihnen diese Seite zu "beobachten", um bei Aktualisierungen informiert zu werden.
Sollten Ihnen weitere hier nicht aufgeführte Probleme bekannt sein, so bitten wir Sie, diese über das ServiceDesk Portal zu melden.
Dieses Konzept richtet sich an Gesellschafter, Anbieter und Dienstleister in der TI.
Das Vorgehen beschreibt, wie der Übergang von RSA zu ECC in der TI während der Migration erreicht wird. Der Fokus liegt dabei auf dezentralen Komponenten.
Ein Reporting und eine rollierende Zeitplanung ist ausdrücklich nicht Bestandteil dieses Dokuments. Die Zeitplanung zum Migrationsvorgehen und den FAQ befindet sich im Bereich Planung- und Umsetzungshorizont.
| Version | Stand | Kap./Seite | Grund der Änderung, besondere Hinweise | Bearbeitung |
|---|---|---|---|---|
| 1.0.0 |
| initiale Erstellung | gematik | |
| 2.0.0 |
| Kapitel: Kontrollierte Außerbetriebnahme von RSA im Rahmen der ECC-Migration | gematik |
Inhalt:
Genutzte Mechanismen
Um die Nutzung von RSA2048 durch die Nutzung von ECC-256 in der TI zu ersetzen, kommen folgende Mechanismen zum Einsatz:
- Tausch von Hardware (HBA, SMC-B, gSMC-KT, Konnektoren)
- Update von Software bzw. Firmware (eHealth-KT, Konnektoren, Primärsystem, KIM-Clientmodule)
- Anpassungen im Vertrauensraum der TSL / BNetzA-VL
- Widerruf / Sperrung von Zertifikaten
Diese dienen dazu:
- Voraussetzungen: die notwendigen Voraussetzungen zu schaffen,
- Durchsetzung: die Nutzung von RSA2048 auf ECC-256 umzustellen und
- Abschaltung: die Nutzung von RSA2048 final zu unterbinden.
Diese Phasen werden im weiteren für jede relevante Komponente der TI definiert.
Komponenten
Wie Voraussetzungen, Durchsetzung und Abschaltung für die einzelnen Komponente der TI umgesetzt werden, wird nachfolgend erläutert. Neben den Maßnahmen wird dabei auch auf die Aspekte Monitoring und indirekt auf zeitliche Terminierung eingegangen:
- Vorgesehenes Monitoring: Messungen und Auswertungen, die beschreiben wie die gematik überwachen kann, in welchem Maße Voraussetzungen erreicht und Maßnahmen umgesetzt wurden. Dazu stehen der gematik folgende Möglichkeiten zur Verfügung:
- Konnektordaten: Jeder Konnektor liefert täglich verschiedene Betriebsdaten aus seiner lokalen Betriebsumgebung an die BDE-Senke der TI.
- Betriebsdaten: Jeder Dienst der TI liefert für diesen definierte Betriebsdaten in spezifizierten Zeitabständen an die BDE-Senke der TI.
- Manuelles Tracking
- Abhängigkeiten: Als Voraussetzung für eine Terminierung, zu wann, ob/in welchen Schritten vorgegangen werden soll
In diesem Dokument wird lediglich beschrieben, welche Größen von der gematik überwacht werden und welche zeitlichen Abhängigkeiten bestehen. Die Ergebniss dieses Monitorings sind für gematik-interne Verwendung vorgesehen und hier nur zur Übersicht aufgelistet. Ob dazu konkrete Reports und eine rollierende Planung veröffentlicht werden, ist hier nicht festgelegt - jedenfalls ist es nicht Teil dieses Dokuments.
Konnektor
Voraussetzungen
Hardware
Voraussetzung für die Nutzung von ECC an den Schnittstellen zum Zugangsdienst und den Kartenterminals sind dualpersonalisierte Konnektoren. Diese Konnektoren beinhalten sowohl RSA- als auch ECC-Zertifikate. Einboxkonnektoren (EBK) haben diese Zertifikate auf der im Gerät intern fest verbauten gSMC-K Gerätekarte bzw. bei laufzeitverlängerten Konnektoren innerhalb des nichtflüchtigen Gerätespeichers zur Verfügung. Highspeedkonnektoren (HSK) haben diese Zertifikate innerhalb der gSM-K Struktur auf einem HSM in einem Rechenzentrum hinterlegt, auf welche nur der HSK exklusiv Zugriff hat. Seit 5 Jahren werden ausschließlich dualpersonalisierte Konnektoren verkauft.
Alle Konnektoren mit RSA-only personalisierten gSMC-K laufen am 31.12.2025 ab und können danach nicht mehr verwendet werden. Solche Konnektoren sind ausschließlich vom Produkttyp EBK und die Ablösung dieser Konnektoren wird von der gematik überwacht. Somit ist ab dem 01.01.2026 die hardwareseitige Voraussetzung für die Ablösung von RSA durch ECC gegeben.
Vorgesehenes Monitoring: Konnektordaten → Konnektorbestand RSA-Only-Konnektoren
Firmware PTV5
Im Feld ist Stand Sept. 2025 flächendeckend PTV5 im Einsatz. Die Firmware der PTV5 verwendet im Default RSA2048, ist aber in der Lage, ECC-Artefakte zu verarbeiten und bei entsprechendem Aufruf ECC-Artefakte zu erzeugen.
Vorgesehenes Monitoring: Konnektordaten → Verbreitungsgrad PTV5
Durchsetzung
Firmware PTV6
PTV6 Konnektoren verhalten sich nach dem ECC-Preferred Prinzip. Dabei wird per Default ECC verwendet. Nur wenn eine angesprochene Karte bzw. Identitätsträger kein ECC-Schlüsselmaterial enthält, fällt die Software automatisch auf RSA2048 zurück. Eine Steuerung durch Aufrufparameter über die Schnittstellen ist dabei nicht möglich. Die Verarbeitung von bestehenden RSA-Artefakten ist mit der Firmware weiterhin gegeben.
PTV6 stellt die VPN-Verbindung und die KT-Verbindung eigenständig auf ECC um, wenn die Voraussetzungen dafür gegeben sind:
- Für die VPN-Verbindung muss der Konnektor dualpersonalisiert sein.
- Für die KT-Verbindung muss der Konnektor dualpersonalisiert, die KT-Firmware aktuell sein und eine G2.1-gSMC-KT stecken.
Vorgesehenes Monitoring: Konnektordaten → Verbreitungsgrad PTV6, Verbreitungsgrad PTV2
Maßnahme PTV6 Rollout
Beschleunigter Rollout von PTV6 bzw. dem funktional identischen HSK PTV2 sobald diese Firmwareversionen zugelassen sind. Die gematik misst den Verbreitungsgrad von PTV6 im Feld.
Abhängigkeiten: PTV6-Konnektor-Rollout darf erst nach umfassenden Ausrollen von KIM 1.5.2-9 im Feld erfolgen.
Vorgesehenes Monitoring: Konnektordaten → Verbreitungsgrad PTV6, Verbreitungsgrad PTV2
Abschaltung
Sobald G2.0 gSMC-KT im Feld gegen G2.1-Karten getauscht wurden und kein RSA2048 mehr in den Verbindungen zu Kartenterminals verwendet wird, werden RSA-Zertifikate aus den Laufzeitverlängerungspaketen entfernt und die RSA2048-Zertifikate der gSMC-K aus dem Vertrauensraum der TI entfernt, indem die RSA KOMP-CAs für C.SAK.AUT und C.SMKT.AUT aus der TI-TSL entfernt werden.
Weiterhin müssen auch RSA-Zertifikate der gSM(C)-K bis zur Abschaltung mit der Laufzeitverlängerung verlängert werden und prüfbar sein, um die KT-Verbindung mit RSA weiter zu unterstützen. Somit werden erst mit der Abschaltung die RSA-Zertifikate aus den Laufzeitverlängerungspaketen entfernt.
Abhängigkeiten:
- Komplettierung der Durchsetzung der Kartenterminals
- ECC-Only-LZV-Pakete erst ab Zeitpunkt der Abschaltung
- Komplettierung der Maßnahmen Rollout der Primärsysteme
SMC-B
Voraussetzungen
Aktuell werden noch G2.0 SMC-B verwendet, welche keine ECC-Zertifikate enthalten. Diese werden durch die Herausgeber bis zum 01.01.2026 gegen G2.1 SMC-B getauscht werden. Der Austausch wird von der gematik gemessen.
Vorgesehenes Monitoring:
- Manuelles Tracking → Bestand G2.0 SMC-B
- Betriebsdaten → TSP X.509 → G2.0 SMC-B OCSP-Anfragen
Durchsetzung
Auch über den 01.01.2026 hinaus bleiben SMC-B Zertifikate im TI-Vertrauensraum unverändert gültig und prüfbar. Die Nutzung von ECC-Signaturen und -Verschlüsselungen wird durch flächendeckende Verbreitung von G2.1 SMC-B und PTV6-Konnektoren durchgesetzt.
Mit der flächendeckenden Verbreitung von PTV6-Konnektoren ist auch die Voraussetzung für die Herausgabe von ECC-only SMC-B (ohne RSA-Zertifikate) gegeben.
Vorgesehenes Monitoring: Betriebsdaten → TSP X.509 → SMC-B OCSP-Anfragen (ECC vs. RSA)
Abhängigkeiten: PTV6-Konnektor-Rollout
Abschaltung
Sobald die flächendeckende Verbreitung von G2.1 SMC-B und PTV6 festgestellt wurde und die Abhängigkeiten von KIM erfüllt sind (siehe KIM-Durchsetzung), werden die Ausstellerzertifikate für die RSA2048-Zertifikate der SMC-B auf "revoked" gesetzt. Weiterhin werden die EE-Zertifkate der SMC-B gesperrt. Anwendungsfälle für SMC-B-Signaturen sind z.B. KIM, Authentisierung ggü. ePA/eRezept/VPN-ZugD und Konnektor-Backups.
Bei Restbeständen von G2.0 Karten oder PTV5 Konnektoren ist dann in dem Fehlertrace mit dem Fehler 1027 „CA_CERT_MISSING“ zu rechnen. Der Fehler kann bei allen Anwendungsfällen auftreten, die eine Gültigkeitsprüfung von SMC-B- Zertifikaten durchführen, wie Signieren, Signaturprüfen, VSDM.
HBA
Voraussetzungen
Aktuell werden noch G2.0 HBA verwendet, welche keine ECC-Zertifikate enthalten. Diese werden durch die Herausgeber bis zum 01.01.2026 gegen G2.1 HBA getauscht. Der Austausch wird von der gematik gemessen.
Vorgesehenes Monitoring:
- Manuelles Tracking → Bestand G2.0 HBA
- Betriebsdaten → TSP X.509 → G2.0 HBA OCSP-Anfragen
Durchsetzung
- Die Nutzung von ECC für die QES wird mit der flächendeckenden Verbreitung von G2.1 HBA und PTV6-Konnektoren sowie durch die Umstellung der Primärsysteme entsprechend der Umstellungsleitfäden in Verbindung mit PTV5-Konnektoren durchgesetzt.
- Die nonQES-Authentisierungsfunktion des HBA wird mit der flächendeckenden Verbreitung von G2.1 HBA und PTV6-Konnektoren durch die Umstellung der Primärsysteme entsprechend der Umstellungsleitfäden auf ECC umgestellt.
- Laut BNetzA werden ab 2026 die RSA CA-Zertifikate für die QES in der BNetzA-Vertrauensliste auf „withdrawn“ gesetzt. Das hat zur Folge, dass keine neuen RSA QES-Zertifikate mehr ausgestellt werden können, so dass ab dem 1.1.2026 ECC-only HBAs (ohne RSA-Zertifikate) herausgegeben werden müssen.
- Es ist davon auszugehen, dass die Nutzung zur Erzeugung einer QES der vor dem 1.1.2026 erstellten QES-RSA-Zertifikate einen Aufsichtsfall der BNetzA nach sich zieht, sollte sich herausstellen, dass diese über 31.12.2025 weiter zur QES genutzt werden. In solch einem Fall ist mit der Veranlassung der Sperrung der QES EE-Zertifikate zu rechnen.
- Bei HBAs von bestimmten TSPs laufen QES-RSA-Zertifikate am 31.12.2025 ab. Wird versucht, danach mit einem solchen Zertifikat eine Signatur zu erstellen, findet sich im Fehlertrace der Fehler 1021 "CERTIFICATE_NOT_VALID_TIME" im Konnektor.
- Damit ein nach dem 01.01.2026 herausgegebener HBA oder ein HBA mit abgelaufenem oder widerrufenem/gesperrtem RSA-Zertifikat ohne Fehler zum Signieren verwendet werden kann:
- muss ein PTV6-Konnektor verwendet werden oder
- kann ein PTV5-Konnektor verwendet werden, wenn das Primärsystem in dem Signaturaufruf den Parameter CRYPT=RSA_ECC setzt.
Known Issue: NFD können bei PTV5-Konnektoren nicht mit Angabe des CRYPT Parameters signiert werden.
Vorgesehenes Monitoring: Betriebsdaten → TSP X.509 → HBA OCSP-Anfragen (ECC vs. RSA)
Abhängigkeiten:
Abschaltung
Da die Verwendung von RSA2048 für QES nach dem 31.12.2025 nach europäischen Recht für die Dokumentensignatur unzulässig ist, ist ab 01.01.2026 jederzeit mit einer Sperrung dieser Zertifikate zu rechnen. Wenn ein Konnektor versucht, mit einem widerrufenen Zertifikat eine Signatur zu erstellen, findet sich im Fehlertrace der Fehler 1047 „CERT_REVOKED“.
Die nonQES Authentisierungsfunktion mit RSA2048-Zertifikaten wird nach flächendeckenden Verbreitung von G2.1 HBA und PTV6-Konnektoren durch das Entfernen der relevanten RSA-CAs aus dem Vertrauensraum der TI (TI-TSL) unterbunden.
eGK
Voraussetzungen
G2.1 mit ECC-Zertifikaten werden flächendeckend eingesetzt. Dies ist zum heutigen Stand bereits erfüllt und es befinden sich keine RSA-Only-eGK mehr im Feld.
Vorgesehenes Monitoring: Manuelles Tracking → Reporting der TSPs, Zertifikatsablauf der G2.0 Karten
Durchsetzung
Damit der Usecase VSDM das ECC-Zertifikat verwendet, muss die Karte mit einem PTV6 Konnektor verwendet werden. Durch die Verwendung des VSDM-Prüfungsnachweises für eRezept und ePA wirkt das auch auf diese Anwendungen.
Abhängigkeiten: PTV6-Konnektor-Rollout
Vorgesehenes Monitoring: Betriebsdaten → TSP X.509 → Anzahl der OCSP-Anfragen zu RSA-Zertifikaten der eGK
Abschaltung
Entfernen der eGK-CAs für RSA-Zertifikate aus der TI-TSL. Als Konsequenz werden ab diesem Zeitpunkt nur noch ECC-only eGK herausgegeben. Die IOP-Fähigkeit mit ECC-only eGK ist erst mit PTV6 Konnektoren qualifiziert nachgewiesen, sodass der flächendeckende Rollout hier eine Abhängigkeit darstellt.
Vorgesehenes Monitoring: Manuelles Tracking → Stichprobenhaftes Prüfen von Karten, welche nach Abschaltung personalisiert wurden
Abhängigkeiten: PTV6-Konnektor-Rollout vor Abschaltung
eHealth-Kartenterminal & gSMC-KT
Voraussetzungen
Maßnahmen eHealth-Kartenterminal
Entgegen der meisten anderen TI-Kompoenten beziehen KTs ihre TSL nicht über download, sondern über FW updates bzw. Dateiimport. Ein Update der Kartenterminal-Firmware auf einen minimalen Stand ist erforderlich, um sicherzustellen, dass die KTs eine ECC-fähige TSL bekommen.
Voraussetzung für den Umstieg auf ECC ist eine G2.1 SMC-KT und eine Firmwareversion >= der folgenden:
| KT-Produkt | ProductVendorId | FW-Version |
|---|---|---|
| Ingenico Orga | INGHC | 3.9.1 |
| GT900 | GERTE | 2.1.1 |
| Cherry ST | DECHY | 4.0.47 |
Vorgesehenes Monitoring: Konnektordaten → Verbreitung der ECC-fähigen KT-Versionen an den verbundenen Konnektoren.
Maßnahmen gSMC-KT
Aktuell werden noch in großer Zahl G2.0 gSMC-KT genutzt. Damit bei der TLS-Verbindung zum Konnektor ECC-Kryptographie genutzt werden kann, ist eine G2.1 gSMC-KT notwendig. Ein Austausch der im Feld befindlichen G2.0 gSMC-KT ist daher erforderlich.
Da ein vollständiger Kartentausch bis Jahresende nicht möglich ist und unter Berücksichtigung, dass die RSA-Zertifikate der gSMC-KT 2.0 ausschließlich in geschlossenen Netzen (z. B. innerhalb einer Arztpraxis) und nicht zur Verschlüsselung oder Signatur medizinischer Daten verwendet werden, bleibt die Nutzung der gSMC-KT 2.0 über den 01.01.2026 hinaus vorerst zulässig. Unabhängig von der Laufzeit der auf den Karten gespeicherten Zertifikate ist die Nutzung jedoch spätestens zum 31.12.2026 einzustellen.
Die meisten dieser Karten laufen in dieser Zeit ab und werden regulär getauscht. Restbestände, die im Januar und Februar 2027 ablaufen, müssen vorzeitig getauscht werden.
Um den neuen kryptografischen Sicherheitsanforderungen des BSI zu entsprechen, empfiehlt die gematik, die Karte spätestens bis zum 01.01.2026 gegen eine gSMC-KT 2.1 auszutauschen.
Vorgesehenes Monitoring: Konnektordaten → Anteil der ECC-Pairings
Durchsetzung
Wenn die Voraussetzungen erfüllt sind, setzt der PTV6-Konnektor die Verwendung von ECC bei der TLS-Verbindung zu Kartenterminals durch. Dies erfolgt, indem die RSA-basierten Pairings durch ein Wartungspairing automatisch auf ECC-basierte Pairings umgestellt werden.
Vorgesehenes Monitoring: nicht verfügbar
Abschaltung
RSA2048-gSMC-KT-Zertifikate werden aus dem Vertrauensraum der TI entfernt, indem die RSA KOMP-CAs für C.SAK.AUT und C.SMKT.AUT aus der TI-TSL entfernt werden.
Vorgesehenes Monitoring: nicht verfügbar
Abhängigkeit:
- Austausch der G2.0 gSMC-KT im Feld
- Aktuelle KT-FW im Feld
KIM-Clientmodul
Voraussetzungen
Das Empfangen von ECC verschlüsselten/signierten KIM-Nachrichten erfordert eine KIM-Version größer als 1.0/1.5.2.
Das Versenden von ECC-verschlüsselten KIM-Nachrichten erfordert eine G2.1 SMC-B beim Empfänger sowie eine KIM-Version größer 1.0.
Das Versenden von ECC-signierten KIM-Nachrichten erfordert eine G2.1 SMC-B und einen PTV6-Konnektor bzw. eine G2.1 SMC-B und einen PTV5-Konnektor mit KIM 1.5.2-9 beim Sender.
Subsummiert resultieren daraus folgende Voraussetzungen:
- KIM-CM 1.5.2-9 ist flächendeckend ausgerollt
- Konnektor PTV6 ist flächendeckend ausgerollt
- HBA und SMC-B G2.0 sind vollständig getauscht
Maßnahmen KIM 1.5.2-9 CM Rollout
Die KIM-Clientmodule werden auf KIM 1.5.2-9 aktualisiert. Dies betrifft auch alle Basis Consumer Instanzen im Feld.
Vorgesehenes Monitoring: Manuelles Tracking → Meldungen der KIM-CM-Hersteller → Status Rollout KIM 1.5.2-9
Durchsetzung
Die Verwendung von ECC für die Verschlüsselung von KIM-Nachrichten wird durch das Herausfiltern der RSA2048-Verschlüsselungszertifikate (SM-B, HBA) vom VZD durchgesetzt. Ein Versender einer KIM-Nachricht ist durch den vom VZD angewendeten Filter in der Rückgabe der LDAP-Abfrage nicht mehr in der Lage, mit den RSA-Zertifikaten eines Empfängers zu verschlüsseln, da nur noch die ECC-Zertifikate zurückgegeben werden.
Wenn die Voraussetzungen erfüllt sind, garantieren sie die Verwendung von ECC für das Signieren von KIM-Nachrichten.
Abhängigkeiten: PTV6-Konnektor-Rollout darf erst nach umfassenden Ausrollen von KIM 1.5.2-9 im Feld erfolgen.
Abschaltung
Die CAs der RSA2048-Zertifikate von SMC-B und HBA werden aus dem Vertrauensraum der TI entfernt (siehe SMC-B). Zusätzlich werden die EE-Zertifikate der SMC-B gesperrt. Die Sperrung der EE-Zertifikate der HBA unterliegt der Zuständigkeit der BNetzA. Auch hier ist mit Sperrung dieser zu rechnen.
Primärsystem
Voraussetzungen
Das Primärsystem muss seine Kompatibilität mit den Schnittstellen des PTV6 sicherstellen: und ggf. ECC-preferred-Verhalten bei PTV5-Konnektoren durchsetzen. Die Vorgehensweise ist im Detail in den ULFs beschrieben.
Maßnahmen PS-Implementierung
Primärsysteme müssen die Umsetzung notwendiger Anpassungen anhand der Umstellungsleitfäden (ePA, eRezept, KIM, NFDM und weitere Unterseiten) sicherstellen, um IOP-Probleme im Zuge der Migration insbesondere PTV6 Update zu vermeiden.
Vorgesehenes Monitoring:
- Manuelles Tracking → Meldungen der PS-Hersteller aus den Umfragen der gematik (Umfragen zur ECC-Readiness) und Direktansprache der PS-Hersteller
- Manuelles Tracking → Meldungen der RU-Teilnehmer über das RUaaS Serviceportal (ANFRUS, Meldung der Readiness, Fehlermeldungen etc.)
- Betriebsdaten
- TSP X.509 → RSA basierte OCSP-Aufrufe
- E-Rezept Signaturquote RSA/ ECC
Abhängigkeiten: PTV6-Konnektor-Rollout darf erst nach umfassendem Ausrollen der PVS, die die ULFs umgesetzt haben, erfolgen.
Maßnahmen Tests
Die Primärsysteme müssen gegen PTV6-Konnektoren getestet werden. Da die Ende-zu-Ende Anwendungsfälle vielschichtig sind und von der gematik weder vollumfänglich übersehen noch gesteuert werden können, ist hier eigenverantworliche Testplanung und Testdurchführung durch die PS-Hersteller erforderlich. Die gematik stellt hierfür unterstützend die ECC-Testwochen zur Verfügung, in denen die entsprechende Testumgebung als Voraussetzung geschaffen ist.
Vorgesehenes Monitoring: Manuelles Tracking → Problemmeldungen der RU-Teilnehmer aus den ECC-Testwochen
Abhängigkeiten:
- PTV6-Konnektoren bzw. PTV2 HSK Versionen den PS-Herstellern verfügbar
- Testmittel den PS-Herstellern verfügbar, um die im Feld gängigen Kombinationen/Konstellationen nachstellen zu können
- Qualifizierte Testergebnisse in vielen Aspekten nur innerhalb der Testwochen möglich
Maßnahmen Rollout
Die PTV6-fähigen Primärsystemversionen müssen ausgerollt werden. Wenn nach den ULFs implementiert wurde, kann der PS Rollout dann sofort erfolgen und es muss keine Abhängigkeit beachtet werden.
Vorgesehenes Monitoring: Manuelles Tracking → Meldungen der PS-Hersteller aus den Umfragen der gematik (Umfragen zur ECC-Readiness)
Abhängigkeiten: keine
Durchsetzung
Werden neue Clientsysteme über TLS an den Konnektor angeschlossen, können nur noch RSA3072 oder ECC-NIST Client-Zertifikate eingerichtet werden. Bei der Umstellung von bereits bestehenden RSA-basierten TLS-Konfigurationen auf ECC müssen alle Server- und Clientzertifikate umgestellt werden, da Mischkonfigurationen nicht von allen Konnektoren unterstützt werden.
Vorgesehenes Monitoring:
- HSK: Konnektordaten → Kryptografie der zuletzt eingerichteten Clientsystemverbindung (erst ab HSK PTV2)
- EBK: nicht verfügbar
Abhängigkeiten: PTV6-Konnektor-Rollout
Abschaltung
Clientsystemverbindung
Sollte erkannt werden, dass die an einem Konnektor eingerichtete Clientsystemauthentisierung RSA2048 basiert ist, sollte diese zwar gegen eine andere ersetzt werden, jedoch gibt es im Rahmen der geplanten RSA-Abschaltungen keine Durchsetzungsmechanismen und daher auch keine Konsequenzen, wenn dies in einer LEI nicht umgesetzt wird. D.h. bestehende RSA2048 Verbindungen werden sowohl mit PTV5 als auch mit PTV6 bis auf Unbestimmte Zeit weiterhin nutzbar sein.
Nichtsdestotrotz weist die gematik darauf hin, dass gem. SOG-IS solche Verbindungen ab 2026 nicht mehr zulässig sind.
Prüfung bei Serverauthentisierung
Wenn der Konnektor das gSMC-K Zertifikat als TLS-Server-Zertifikat nutzt, und das Primärsystem dieses gegen die TSL prüft, wird mit Entfernen der RSA-gSMC-K C.AK.AUT Zertifikate aus dem Vertrauensraum der TI durch Entfernen der RSA KOMP-CAs aus der TI-TSL eine PKI-Kettenprüfung durch ein Clientsystem nicht erfolgreich sein. Es ist keine empfohlene Konfiguration, dass das Primärsystem das TLS-Server-Zertifikat gegen die TSL und PKI-Kette prüft. Es ist intendiert, dass das TLS-Server-Zertifikat vom Client immer als Self-Signed angesehen wird.
Vorgesehenes Monitoring: Betriebsdaten → TSP X.501 → OCSP Anfragen für C.AK.AUT
Kontrollierte Außerbetriebnahme von RSA im Rahmen der ECC-Migration
Die Außerbetriebnahme von RSA2048 über den Vertrauensraum der TI wurde während der Testwochen in der Referenzumgebung konsequent umgesetzt. Dabei zeigte sich, dass mit jeder weiteren Testwoche weniger kritische Themen identifiziert wurden.
Gleichwohl bestehen Risiken bei der Umstellung in der Produktivumgebung:
- Unter anderem gibt es keine vollumfängliche Testabdeckung,
- Systeme wurden speziell für die Referenzumgebung (RU) angepasst, jedoch vermeintlich bislang nicht in der Produktivumgebung (PU).
- Zudem könnte es unter realen Lastbedingungen bei der Umstellung auf ECC zu Performance- oder Stabilitätsproblemen kommen.
Um diesen Risiken mit weiteren Maßnahmen zu begegnen, erfolgt die Abschaltung von RSA nicht an einem Stichtag, sondern kontrolliert und schrittweise – anders als in der RU während der Testwochen. Konkret ist vorgesehen, den Vertrauensraum iterativ zu bereinigen: Es wird jeweils eine Sub-CA aus der TSL entfernt, das Verhalten des Systems anschließend mittels Monitoring engmaschig überwacht. Sollten keine unerwarteten Störungen auftreten, folgt nach einer definiereten Boabachtungsphase die Entfernung der nächsten CA. Bei Problemen kann die CA temporär wieder aktiviert und die Ursachen analysiert und behoben werden.
Dabei wird berücksichtigt, dass bestimmte CAs weiterhin im Vertrauensraum verbleiben müssen – etwa für gSMC-KT 2.0, um deren Funktionalität bis mindestens 2026 sicherzustellen, oder für Karten, auf denen weiterhin RSA-basierte Identitäten aufgebracht werden müssen.
Nachfolgend ist die Außerbetriebnahme von RSA aus PKI-Management-Sicht beschrieben.
Planungsstand
Allgemeine Schritte der Außerbetriebnahme von RSA
Nachfolgend sind die Schritte im allgemeinen betrachtet:
| Maßnahme | Wo? | Was passiert? | Wirkung |
|---|---|---|---|
| Entfernen/Statuswechsel von Ausstellerzertifikaten | TSL | RSA-CA-Zertifikate werden aus der TSL entfernt oder erhalten einen Statuswechsel. | EE-Zertifikate werden ungültig, Zertfikatspfad kann nicht mehr erfolgreich validiert werden. Für Signaturprüfungen verbleiben diese CAs im Vertrauensraum. |
| Entfernen von Zertifikatstyp-OIDs | TSL | OIDs für RSA-Zertifikatstypen werden aus TSL-Einträgen entfernt. | Zertifikate können für bestimmte Zwecke technisch nicht mehr verwendet werden. |
| Filterung und Entfernung von Zertifikaten | VZD | Es wird ein Filter im VZD gesetzt, welche keine RSA-Zertifikate mehr beauskunftet. RSA-Zertifikate (v.a. Verschlüsselungszertifikate) werden aus Verzeichnisdienst entfernt. | Keine neuen RSA-verschlüsselten Nachrichten mehr möglich. |
| Sperren von Zertifikaten | TSP/OCSP | EE-Zertifikate werden beim TSP auf „revoked“ gesetzt. | Zertifikate können nicht mehr eingesetzt werden, bestehende Signaturen bleiben prüfbar. |
| Abschaltung des RSA-TSL-Downloadpunkts | TSL | Der Downloadpunkt für reine RSA-TSL wird deaktiviert. Komponenten können keine RSA-TSL mehr herunterladen. | Es kann wird nur noch der ECC-TSL-Downloadpunkt verwendet welcher eine TSL bereitstellt, welche alle CAs beinhaltet. Die TSL ist mit ECC signiert und muss entsprechend vor der Verarbeitung geprüft werden. |
| Statuswechsel der QES CA's "withdrawn" | BNetzA_VL (QES) | Die QES CA's werden laut Bundesnetzagentur einen Statuswechsel auf "withdrawn" erhalten | Dadurch lassen sich keine QES Zertifikate für HBAs ausstellen. |
Schritte der Außerbetriebnahme von RSA im Detail
Entfernen/Statuswechsel von Ausstellerzertifikaten
Aktuell etwas über einhundert relevente CAs von verschiedenen TSPs in der TSL. Diese werden nachfolgenden ge-clustert betrachtet und die entsprechend Planung zur Entfernung oder zum Statuswechsel betrachtet.
| Allgemeine CA (Zweck) (Bemerkung) | Zeitplan | Abschaltkriterium (Alle aufgelisteten Kriterien müssen erfüllt sein, sonst kann der Schritt nicht ausgeführt werden) |
|---|---|---|
| eGK-ALVI-CA (eGK, Kassen-Apps) (Authentisierung in Kassen-Apps, ePA-Aktensystem) | Obsolet - Es gab nie RSA CA's für ALVI und wurde direkt mit Einführung der ePA mit ECC umgesetzt. | Bereits erfüllt |
| eGK-CA (elektronische Gesundheitskarte) (Authentisierung, Verschlüsselung, Signatur) |
| siehe: eGK |
| HBA-CA (Heilberufsausweis) (Authentisierung, Verschlüsselung) | Schritt 1:
Schritt 2:
| siehe: HBA Nicht zum Quartalsende |
| SMCB-CA (Institutionskarte SMC-B) (Authentisierung, Verschlüsselung, Signatur) | Schritt 1:
Schritt 2:
Schritt 3:
| siehe: SMC-B Nicht zum Quartalsende ECC-Only Kartenherausgabe gestartet |
| KOMP-CA (Komponenten, gSMC-K, gSMC-KT, etc.) (Authentisierung von Konnektoren/Kartenterminals/Fachdiensten) | Schritt 1: Entfernen der OIDs für die jeweiligen Zertifikatstypen aus der TSL: Siehe: Entfernen von Zertfikatstyp-OIDs Schritt 2: Entfernen der RSA KOMP-CA aus der TSL |
|
| VPNK-CA (VPN-Konzentrator) (Authentisierung VPN-Zugangsdienst) | Entfernen der RSA VPNK-CA aus der TSL |
|
Entfernen von Zertifikatstyp-OIDs
oid | Zert. Typ | Komponente | Plandatum | Usecase | Kommentar |
|---|---|---|---|---|---|
| oid_hsk_sig | C.HSK.SIG | HSK | HSM-B | Aktuell in PU nicht in Verwendung Verwendung nach Spec. nur mit ECC | |
| oid_hsk_enc | C.HSK.ENC | HSK |
| HSM-B | Aktuell in PU nicht in Verwendung Verwendung nach Spec. nur mit ECC |
| oid_fd_aut | C.FD.AUT | Fachdienste |
| EPA-VAU/-VST/FDZ eRezept-VAU | RSA2048 aktuell in PU nicht in Verwendung |
| oid_fd_osig | C.FD.OSIG | Fachdienste |
| eRezept | RSA2048 aktuell in PU nicht in Verwendung |
| oid_nk_vpn | C.NK.VPN | Konnektor (gSMC-K) |
| IPSec Verbindung aufbauen | Sobald alle Konnektoren sich über ECC reregistriert haben, also mit Rollout-Abschluss von PTV6 |
| oid_vpnk_vpn_sis | C.VPNK.VPN-SIS | Konnektor (gSMC-K) |
| IPSec Verbindung aufbauen | Sobald alle Konnektoren sich über ECC reregistriert haben, also mit Rollout-Abschluss von PTV6 |
| oid_vpnk_vpn | C.VPNK.VPN | VPN-ZugD |
| IPSec Verbindung aufbauen | Sobald alle Konnektoren sich über ECC reregistriert haben, also mit Rollout-Abschluss von PTV6 |
| oid_cm_tls_c | C.CM.TLS-CS | KIM-Clientmodul |
| Client-Cert zum KIM-FD, und zum Konnektor | Sobald KIM CM auf V1.5.2-9 umgestiegen ist, werden vom FD ECC-Certs bezogen und die OID kann entfernt werden. |
| oid_fd_tls_c | C.FD.TLS-C | Alle FD, die als TLS-Clients fungieren |
| EPA-MGMT als Client eRezept-FD als Client (für EPA) Intermediär als Client KIM-FD als Client TSP-SMB-Schnittstelle | |
| oid_fd_tls_s | C.FD.TLS-S | Alle FD, die als TLS-Server fungieren |
| CMS EPA-AS/-MGMT/-VST/-FDZ eRezept-FD IDP Intermediär als Server KIM-FD TIGW-Zugangsmodul UFS VSDD | |
| oid_fd_sig | C.FD.SIG | Fachdienste |
| EPA-AS/-VAU eRezept-FD IDP / sekIDP TIM-FD VPNZ (RegServer) VZD Wanda | |
| oid_fd_enc | C.FD.ENC | Fachdienste |
| EPA-AS/-VAU/-VST/-FDZ eRezept-VAU Wanda | |
| oid_zd_tls_s | C.ZD.TLS-S | Zentrale Dienste |
| BDE (C.ZD.TLS-S.STAMP) KSR TSL-Dienst VPNZ VZD | |
| oid_zd_sig | C.ZD.SIG | Konnektor PS |
| Bestandsnetze.xml PoPP PoPP-Token | PoPP(-Token) sind nicht umgesetzt. Somit auch keine Verwendung mit RSA |
| oid_smkt_aut | C.SMKT.AUT | eHKT (gSMC-KT) |
| mTLS-Verbindung KT-Konnektor | Wenn keine gSMC-KT in der Version G2.0 mehr im Feld sind. |
| oid_sak_aut | C.SAK.AUT | Konnektor (gSMC-K) |
| mTLS-Verbindung KT-Konnektor | Wenn keine gSMC-KT in der Version G2.0 mehr im Feld sind. |
| oid_ak_aut | C.AK.AUT | Konnektor (gSMC-K) | Clientsystem TLS-Verbindung (AUT der gSMC-K) | siehe: PS-Abschaltung |
Filterung und Entfernung von Zertifikaten
| Maßnahme | Wo? | Was passiert, wann? | Wirkung |
|---|---|---|---|
| Filterung/Entfernung von HBA/SMC-B Zertifikaten aus dem Verzeichnisdienst. | VZD |
| RSA Zertifikate werden nicht mehr verwendet |
Sperren von Zertifikaten
| Maßnahme | Wo? | Was passiert, wann? | Wirkung |
|---|---|---|---|
| TSP QES | Durch Vorgaben der BNetzA in Abstimmung mit den TSPs | Es können nur noch ECC QES-Signaturen ausgestellt werden. Vergangene RSA Signaturen bleiben prüfbar. Siehe auch: HBA |
| TSP nonQES | Die Zertfikate werden als Massenauftrag gesperrt. Die Signaturzertifikate werden bei den TSPs zum Stichtag auf den Status "revoked" gesetzt. In diesem Status behalten vor dem Stichtag getätigte Signaturen ihre Gültigkeit. Ein Quartal nach "revoked" setzen der SMC-B CA | Das Sperren von EE-Zertifikate in der PU ist irreversibel. Es können nur noch ECC Zertfikate einer G2.1 verwendet werden. Siehe auch: SMC-B |
Abschaltung des RSA-TSL-Downloadpunkts
| Maßnahme | Wo? | Was passiert, wann? | Wirkung |
|---|---|---|---|
| Abschaltung des RSA-TSL-Downloadpunkts | TSL | Der Downloadpunkt für reine RSA-TSL wird deaktiviert. Komponenten können keine RSA-TSL mehr laden. | Es wird nur noch der ECC TSL Downloadpunkt verwendet. In der TU/RU ist die RSA TSL bereits seit mitte 2025 nicht mehr aktiv. Mit Tausch der restlichen RSA-only Personalisierten Konnektoren (Ende 25') in der PU wird die RSA TSL nicht mehr benötigt. |
Statuswechsel der QES CA's auf "withdrawn"
| Allgemeine CA (Zweck) (Bemerkung) | Was passiert, wann? | Wirkung |
|---|---|---|
| HBA-qCA (HBA, QES) (Qualifizierte elektronische Signatur) |
| Es lassen sich keine EEs QES RSA Zertfikate für HBAs ausstellen und somit können nur noch ECC only HBAs herausgegeben werden. |
Abkürzungsverzeichnis
| Kürzel | Erläuterung |
|---|---|
| AUT | Authentication |
| BNetzA | Bundesnetzagentur |
| BNetzA-VL | Vertrauensliste (TSL) der Bundesnetzagentur |
| BSI | Bundesamt für Sicherheit in der Informationstechnik |
| CRL | Certificate Revocation List |
| DVO | Dienstleister vor Ort |
| eAU | Elektronische Arbeitsunfähigkeitsbescheinigung |
| ECC | Elliptic Curve Cryptography |
| ECDSA | Elliptic Curve Digital Signature Algorithm |
| EE-Zertifikat | End-Entity-Zertifikat |
eGK | Elektronische Gesundheitskarte |
| ePA | Elektronische Patientenakte |
| gSMC-K | Smartcard zur Identifikation und Authentisierung des Konnektors |
| gSMC-KT | Smartcard zur Identifikation und Authentisierung des Kartenterminals |
| HBA | Heilberufsausweis |
| IDP | Identity Provider |
| KIM | Kommunikationsdienst im Medizinwesen |
| KOM-LE | Früherer Name für KIM (Kommunikation im Medizinwesen) |
| KSR | Konfigurations- und Software-Repository |
| LE | Leistungserbringer |
| LEI | Leistungserbringerinstitution |
| NFD | Notfalldatensatz |
| OCSP | Online Certificate Status Protocol |
| PKI | Public Key Infrastructure |
| PS | Primärsystem |
| PTV | Produkttypversion |
| PU | Produktivumgebung |
| PVS | Praxisverwaltungssystem |
| QES | Qualifizierte elektronische Signatur |
| RSA | (Rivest–Shamir–Adleman) ist ein asymmetrisches kryptographisches Verfahren |
| RU | Referenzumgebung |
| SigD | Signaturdienst |
| SMC-B | Sicherheitsmodul Card Typ B |
| TI | Telematikinfrastruktur |
| TI-M | TI-Messenger |
| TLS | Transport Layer Security |
| TSL | Trust-service Status List |
| TU | Testumgebung |
| VPNK | VPN-Konzentrator |
| VSDD | Versichertenstammdatendienst |
| VSDM | Versichertenstammdatenmanagement |
| VZD | Verzeichnisdienst |
| WANDA | Weitere Anwendungen für den Datenaustausch in der Telematikinfrastruktur |
Wir freuen uns jederzeit über Hinweise und Feedback, um dieses Dokument aktuell und so zielführend wie möglich zu halten!
Anfragen zur RSA/ECC-Migration (gern auch über "Meldung" als vereinfachter Workflow ohne Rückantwort)