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. 

Inhalt:

Genutzte Mechanismen

Um die Nutzung von RSA2048 durch die Nutzung von ECC-256 in der TI zu ersetzen, kommen folgende Mechanismen zum Einsatz:

1. Tausch von Hardware (HBA, SMC-B, gSMC-KT, Konnektoren)
2. Update von Software bzw. Firmware (eHealth-KT, Konnektoren, Primärsystem, KIM-Clientmodule)
3. Anpassungen im Vertrauensraum der TSL / BNetzA-VL
4. Widerruf / Sperrung von Zertifikaten

Diese dienen dazu:

1. Voraussetzungen: die notwendigen Voraussetzungen zu schaffen,
2. Durchsetzung: die Nutzung von RSA2048 auf ECC-256 umzustellen und
3. 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:

1. 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:
   1. Konnektordaten: Jeder Konnektor liefert täglich verschiedene Betriebsdaten aus seiner lokalen Betriebsumgebung an die BDE-Senke der TI.
   2. Betriebsdaten: Jeder Dienst der TI liefert für diesen definierte Betriebsdaten in spezifizierten Zeitabständen an die BDE-Senke der TI. 
   3. Manuelles Tracking
2. 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 Ergebnis 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 gegen G2.1 SMC-B getauscht. Der Austauschfortschritt 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

Die RSA SMC-B EE-Zertifikate werden gesperrt. Signaturen, welche vor der Sperrung durchgeführt wurden, bleiben im TI-Vertrauensraum jedoch unverändert prüfbar. Die Nutzung von ECC-Signaturen und -Verschlüsselungen wird durch flächendeckende Verbreitung von G2.1 SMC-B und PTV6-Konnektoren und final durch die Sperrung der RSA EE-Zertifikate 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. Ebenfalls stellen PTV6 Konnektoren sicher, dass deren Registrierungen am VPN-ZugD in jedem Fall mit ECC-Zertifikat der SMC-B signiert sind, sodass damit ein Verlust der TI-Verbindung infolge der Sperrung der RSA-EE-Zertifikate der SMC-B ausgeschlossen ist.

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-Zertifikate der SMC-B gesperrt. Anwendungsfälle für SMC-B-Signaturen sind z.B. KIM, die Authentisierung ggü. ePA/eRezept/VPN-ZugD sowie die 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, etc.

HBA

Voraussetzungen

Stand April 2026 werden noch G2.0 HBA verwendet, welche keine ECC-Zertifikate enthalten. Diese werden durch die Herausgeber gegen G2.1 HBA getauscht. Der Austauschfortschritt 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.
• Seit dem 1.1.2026 werden ausschließlich ECC-only HBAs (ohne RSA-Zertifikate) herausgegeben.
• Die ursprünglich für den 01.01.2026 geplante Umstellung von RSA auf ECC, insbesondere im Bereich der qualifizierten elektronischen Signatur (QES), wurde aufgrund nicht vollständig abgeschlossener HBA-Tauschaktionen auf den 30.06.2026 verschoben. Dies geschah in Abstimmung zwischen der gematik, der BNetzA, der SRC und dem BSI. Eine weitere Verlängerung ist für den QES-Bereich nicht vorgesehen. 
• Die Nutzung von QES-RSA-Zertifikaten zur Erzeugung einer QES, stellen einen Aufsichtsfall für die BNetzA nach sich, sollte sich herausstellen, dass RSA über den 30.06.2026 weiter zur QES genutzt wird. 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 seit dem 01.01.2026 versucht, 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. Ein Update auf PTV6 schafft hier Abhilfe.

Vorgesehenes Monitoring: Betriebsdaten → TSP X.509 →  HBA OCSP-Anfragen (ECC vs. RSA)

Abhängigkeiten:

• PTV6-Konnektor-Rollout
• oder Rollout aller ECC-Ready Primärsysteme

Abschaltung

Die Verwendung von RSA2048 für QES ist nach dem 31.12.2025 nach europäischem Recht für die Dokumentensignatur unzulässig. Es wird trotzdem eine Übergangsfrist bis zum 30.06.2026 gewährt, in der weiterhin QES-Signaturen mit RSA2048 erstellt werden dürfen.

Es ist jedoch ab 01.07.2026 jederzeit mit einer Sperrung der RSA2048-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 der 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.

Mit der flächendeckenden Verbreitung von PTV6-Konnektoren ist auch die Voraussetzung für die Herausgabe von ECC-only eGK (ohne RSA-Zertifikate) gegeben.

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-Komponenten 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:

Vorgesehenes Monitoring: Konnektordaten → Verbreitung der ECC-fähigen KT-Versionen an den verbundenen Konnektoren.

Maßnahmen gSMC-KT

Im Laufe des Jahres 2026 werden noch 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 2025 nicht möglich war 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.

Die meisten dieser Karten laufen bis zum 31.12.2026 ab und werden regulär getauscht.

Um den neuen kryptografischen Sicherheitsanforderungen des BSI zu entsprechen, empfiehlt die gematik, die Karte spätestens bis zum 01.07.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

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 mindestens KIM 1.5.2-9 bzw. 1.5.2-10 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 werden in der TSL auf "revoked" gesetzt und die vom HBA werden aus dem Vertrauensraum der TI entfernt (siehe SMC-B bzw. HBA). Zusätzlich werden die EE-Zertifikate der SMC-B gesperrt. Die Sperrung der QES 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 eigenverantwortliche 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 die Durchsetzung des ECC-preferred-Verhalten bei PTV5-Konnektoren gem. 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, dürfen 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 verprobt. 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 besteht das Risiko, dass nicht alle RU Konfigurationen äquivalent in die PU übertragen sind.
• 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 in der PU 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 werden Sub-CAs in Gruppen eingeteilt. Anschließend wird schrittweise jede CA-Gruppe aus der TSL entfernt, das Verhalten des Systems anschließend mittels Monitoring engmaschig überwacht. Sollten keine unerwarteten Störungen auftreten, folgt nach einer definierten Beobachtungsphase die Entfernung der nächsten CA-Gruppe. Bei Problemen kann die CA-Gruppe bzw. eine betreffende CA temporär wieder aktiviert und die Ursachen analysiert und behoben werden. Details dazu sind den Tabellen aus Kapitel "Schritte der Außerbetriebnahme" zu entnehmen.

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 Ende 2026 sicherzustellen, für Karten, auf denen weiterhin RSA-basierte Identitäten aufgebracht werden müssen oder für jene Zertifikate, für die eine Signaturprüfung in der Zukunft sichergestellt sein muss.

Nachfolgend ist die Außerbetriebnahme von RSA aus PKI-Management-Sicht für die verschiedenen Umgebungen beschrieben. Das Kapitel "Außerbetriebnahme in der PU" geht dabei gezielt auf die erforderlichen Änderungen und deren Zeitpunkt/Abhängigkeiten ein. Daran orientierend legt das Kapitel "Außerbetriebnahme in TU und RU" die Termine und Besonderheiten für die Test- und Referenzumgebung fest.

Außerbetriebnahme in der PU

Planungsstand

Der untenstehende Zeitplan gibt an, zu wann die jeweiligen einzelnen Migrationsschritte angesetzt sind und wie lange die Durchführung dieser Schritte bis zu vollständigen Umsetzung ggf. andauert. Während wie oben erwähnt ein engmaschiges und kontinuierliches Monitoring der Voraussetzungen zu den Migrationsschritten durch die gematik erfolgt, wird der hier dargestellte Plan mindestens zu den in "Sync/Revision" angegeben Daten angepasst und aktualisiert und öffentlich zum Status der entsprechenden bevorstehenden nächsten Schritte informiert.

Allgemeine Schritte der Außerbetriebnahme von RSA

Nachfolgend sind die Schritte im allgemeinen betrachtet:

Schritte der Außerbetriebnahme von RSA im Detail

Entfernen/Statuswechsel von RSA-Ausstellerzertifikaten

Aktuell sind etwas über einhundert relevante CAs von verschiedenen TSPs in der TSL. Diese werden nachfolgenden ge-clustert betrachtet und die entsprechend Planung zur Entfernung oder zum Statuswechsel betrachtet.

Entfernen von Zertifikatstyp-OIDs

Filterung und Entfernung von Zertifikaten

Sperren von Zertifikaten

Abschaltung des RSA-TSL-Downloadpunkts

Statuswechsel der QES CA's auf "withdrawn"

ECC-Only Personalisierung

Außerbetriebnahme in der TU und RU

Planungsstand

In der TU ist bereits seit 18 Jun 2025  der finale Migrationszustand so umgesetzt, wie er für die PU nach Durchführung aller einzelnen Migrationsschritte vorgesehen ist.

Für die RU ist die finale Außerbetriebnahme zum gleichen Zeitpunkt wie die Migration in der PU vorgesehen. Davor werden die Migrationsschritte in der RU im Rahmen der ECC-Testwochen gemäß folgendem Zeitplan durchgeführt.

Besonderheit in den Umgebungen RU und TU

Sig-Algo in den OCSP-Responses der RSA-EEs

Der TI-OCSP von RU/TU beauskunftet RSA-EEs signiert mit ECC für eGK, SMC-B und nonQES Zertifikate des HBA dauerhaft bereits ab dem 27.04.2026. In der PU ist die Signatur mit ECC ab dem 01.10.2026 vorgesehen.

Abkürzungsverzeichnis

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)

Allgemeines Anfrageportal - Serviceprojekt