TI-Dienste ECC-Umstellung (TM) nach dem 31.12.25?

[FortiSecond]

Nachdem nun mindestens drei Threads beschreiben, dass/welche/ob Probleme mit TURBOMED (oder Komponenten wie KIM, LDAP, ePA) nach ECC-Umstellung bestehen (könnten), hier mal etwas Knuspriges.

Das ist (meinerseits) ohne Gewähr - wie alles rund um TI -, hat dennoch blutdrucksenkendes Potenzial:

Ab dem 01.01.2026 verliert RSA2048 nach SOG-IS seine Eignung. In Folge dessen soll RSA2048 nicht mehr verwendet werden.

Im QES-Bereich wird das durch die BNetzA beaufsichtigt und eine Durchsetzung pünktlich ab 1.1.26 ist zu erwarten. Für die Client- und Konnektorzertifikate für der Clientanbindung, die ja im nonQES-Bereich stattfindet, werden jedoch noch bis Mitte 2026 RSA2048-Zertifikate toleriert. Es sind keine technischen Maßnahmen vorgesehen, die diese Nutzung blockieren oder verhindern.

Nichtsdestotrotz weist die gematik darauf hin, dass auch auf dieser Strecke so schnell wie möglich due Nutzung von RSA2048 einzustellen ist. Alternativ können die ECC- oder RSA3072-Zertifikate genutzt werden.

BÄM!

Und

Für die beidseitige Authentisierung bei der Clientsystemanbindung gilt über den 01.07.2026 hinaus Folgendes:

Es gibt keine technischen Mechanismen, die eine Verwendung von RSA2048 bei Clientanbindung in Zukunft verhindern.
Eine manuelle Umstellung auf ECC oder RSA3072 ist dennoch zeitnah notwendig.

Wenn man das also rein technisch betrachtet, wird am 01.01.2026 die TURBOMED-Welt nicht zusammenbrechen, wenn man sich noch nicht oder bisher nur erfolglos getraut haben sollte, alles auf ECC umzustellen.
Die Verpflichtung besteht gleichwohl dem Text nach weiterhin.

Da ja die Verpflichtung am KRITISCHEN Punkt (nämlich der QES/Signatur) gerade ad absurdum geführt wurde mit der Nachfrist für eHBA (und SMC-B), muss man sich fragen, warum man ausgerechnet die Verbindung der Arztsoftware zum Konnektor (nur im Praxisnetz) noch so hoch ansetzt.

Bei all den bisher beschriebenen Unwägbarkeiten bei CGM TURBOMED (mal geht dies, mal das nicht) ist das Setzen von Prioritäten keine schlechte Idee:
- Entweder formal unzulässig aber zuverlässig weiter in RSA arbeiten, bis TM es sicher kann (oder CGM eine kugelsichere Anleitung bereitstellt oder ein VSP oder DVO erfolgreich die Pflichtfunktion des PVS funktionsfähig macht)
- Oder teilweise Nichtfunktion der TI ab 01.01.26 in Kauf nehmen und bisweilen potenziell kein VSDM, ePA, E-Rezept, eAU, eEB, eArztbrief, NFDM etc. nutzen.

Was ist für die Gesundheit, für Leib und Leben der Patienten vorrangig?
Richtig: Eine vernünftige ärztliche Behandlung.
Auch richtig: Korrekte NFDM, Medikamentenliste und so weiter...


Ansonsten...
Hier ist die Quelle (gematik), die teilweise ordentlich ins Detail geht:
https://wiki.gematik.de/spaces/RUAAS/pa ... 3%BCr+DVOs

[turbotm]

Mit Ihnen ließe sich hervorragend bei ein oder zwei Bier am Stammtisch über unseren Megaschwachsinn fachsimpeln.
Ganz herzlichen Dank für Ihren Einsatz.
Maier

[DocET]

Das klingt nach Entspannung statt Verzweiflung zum vierten Advent in der Praxis.
Danke fürs Teilen dieser guten Nachricht.
Viele Grüße von DocET.

[DC19]

Guten Morgen,

bedeutet dies, dass ich zum Januar gar nichts umstellen müsste. Kein Konnektor, usw?

[FortiSecond]

Guten Morgen,

bedeutet dies, dass ich zum Januar gar nichts umstellen müsste. Kein Konnektor, usw?

Alles unter Vorbehalt von Irrtum, Fehlannahmen, Druckfehlern, Amnesie, Halluzinationen und spontaner leges largitoribus*:
FORMAL ZWINGEND:
Alles mit Ausnahme eHBA, SMC-B und gSMC-KT (aber alle drei "geboten", da nur Übergangsfrist eingeräumt).

TECHNISCH ZWINGEND:
Austausch eines Konnektors, der "nur RSA" kann, d.h. alte Secunet, alte Kocoboxen etc.
Kartenleser auf aktuelle Firmware bringen, Konnektor auf aktuelle Firmware bringen

TECHNISCH NICHT ZWINGEND (ABER FORMAL GEBOTEN):

Ohne Ausfallrisiko für andere Teile/Funktionen technisch problemlos umzustellen, wenn die jeweiligen Komponenten ECC können:

- gSMC-KT (Kartenterminals ent-pairen, neu pairen)
- eHBA (freischalten, tauschen, in TM beim Arzt hinterlegen)
- SMC-B (Re-Registrierung am Zugangsdienst)

Mit Ausfallrisiko für andere Teile/Funktionen:

- Konnektorzertifikat "zur Identifikation gegenüber dem Clientsystem" auf ECC umstellen

- Zertifikat für die Authentifizierung des Clientsystems mit ECC erstellen (das, was erzeugt und in TM, KIM etc. hinterlegt wird)
Hinweis: Erstellen ist ohne Risiko, und solange das bisherige RSA noch gültig ist und im Konnektor nicht gelöscht oder deaktiviert wird, funktioniert es weiter bzw. ist ein Zurückgehen bei Notwendigkeit möglich.
Secunet erlaubt die parallele Nutzung von RSA und ECC, z.B. wenn KIM sich per "Client = TurboMed" mit dem alten Zertifikat weiter anmeldet. Kocobox? Keine Ahnung.

Ausfallrisiko meint hier: Irgendwas macht Stress, sei es ePA, KIM oder sonstwas. Sicherlich alles lösbar, aber nicht unbedingt immer trivial. Technisch müssten alle aktuellen Beteiligten das können. Praktisch ist es anders: Die Meldungen hier im Forum knabbern an der Zuversicht. Muss nicht bedeuten, dass irgendwas wirklich fehlerhaft ist. Aber klar ist, dass eine für den Endkunden verständliche Dokumentation seitens CGM für ALLE Aspekte der ECC-Umstellung (mir) derzeit nicht als öffentlich leicht auffindbar bekannt ist. Ich hoffe, die Formulierung ist deutlich genug. *hust*

Also rein technisch und nach (nicht nur meiner) Lesart der verlinkten Seite der gematik dürfte es im Januar keinen Ausfall geben, weil eine technische Blockade nicht vorgesehen ist. Voraussetzung ist, wie oben beschrieben, dass der Konnektor generell ECC-fähig ist und dass die Zertifikate (auch die alten RSA) noch über den 31.12.2025 hinaus gültig sind.


* = largitor (m) = Spender

[Johnny]

@FortiSecond:

Alles ganz einfach! Die Gematik wollte sich halt nicht den Schuh (= SchwarzenPeter) anziehen bzw. zuschieben lassen, wenn ab dem 01.01.2026 etliche Praxen wegen nicht Umstellung der Zertifikate (aus welchen Grümdem auch immer) ab Januar wegen technischer Probleme ausfallen würden.

Grrüssend aus Kiel
Johnny

[cwang]

Gerade haben wir von T-System eine E-Mail erhalten. Demnach ist unser eHBA, den wir in April dieses Jahres erhalten haben, "spezifikationskonform bereits ECC-fähig ist und ab dem 1. Januar 2026 ausschließlich ECC-Zertifikate unterstützt."

Das bedeutet doch, dass die ECC-Umstelung zwingend notwendig ist.

[FortiSecond]

Gerade haben wir von T-System eine E-Mail erhalten. Demnach ist unser eHBA, den wir in April dieses Jahres erhalten haben, "spezifikationskonform bereits ECC-fähig ist und ab dem 1. Januar 2026 ausschließlich ECC-Zertifikate unterstützt."

Das bedeutet doch, dass die ECC-Umstelung zwingend notwendig ist.

Läuft denn das RSA-Zertifikat auf dem Ausweis am Jahresende ab?

[cwang]

@FortiSecond
Ja, das muss nach der Mail ("... ausschließlich ...") der Fall sein.

[FortiSecond]

@FortiSecond
Ja, das muss nach der Mail ("... ausschließlich ...") der Fall sein.

Den Satz kenne ich: https://www.telekom-healthcare.com/medi ... uebersicht
Leider habe ich keinen solchen Ausweis zur Hand, um per Seccardadmin oder vergleichbarem Programm die Zertifikatslaufzeiten zu prüfen.

Es wäre aber extrem ungewöhnlich, wenn
a) das RSA-Zertifikat eine vom zeitgleich erstellten ECC-Zertifikat abweichende Laufzeit vorweisen sollte oder
b) die Telekom irgendwelche Zertifikate vorzeitig widerrufen würde

BEIDES wäre eine Minderleistung, denn unabhängig von irgendwelchen Bestimmungen zur TI können Sie die Ausweise ja auch anderweitig nutzen wollen. Vielleicht in einem Zusammenhang, in dem Sie RSA noch verwenden wollen oder müssen, und sei es die Signatur von Scans für revisionssichere Speicherung. Wenn zum Zeitpunkt des Kaufs also die RSA-Funktionalität noch Bestandteil der Spezifikation war und Sie "einen Ausweis mit mindestens 48 Monate gültigen Zertifikaten" erworben haben... gibt es keinen vernünftigen Grund, die Nutzbarkeit künstlich einzuschränken.

Allein die Tatsache, dass die Nutzung von eHBA mit RSA-Zertifikaten in der TI (nicht allgemein*) ausdrücklich in der Übergangsfrist bis 30.06.2026 zulässig ist, widerspricht der künstlichen Verkürzung der Zertifikatlaufzeit gegenüber der ursprünglichen Spezifikation.


Aber völlig unabhängig davon, und das ist viel wichtiger:

Ob der eHBA nun plötzlich kein RSA mehr kann oder nicht, dürfte völlig egal sein, solange ein gültiges ECC-Zertifikat enthalten ist. Denn beim eHBA passiert das transparent ohne nutzerseitige Entscheidung über RSA oder ECC. Und Konnektor wird ECC können (wäre sonst ohnehin erledigt), TM muss es können (kann mit eHBA/ECC umgehen), den Kartenlesern ist es wurscht (sind nur Brücke).

Ausnahme ist, man hat sein KIM-Postfach mit dem eHBA unter Verwendung von ECC registriert, und das RSA-Zertifikat ist zum Jahreswechsel abgelaufen oder widerrufen (warum und auf welcher Rechtsgrundlage das auch geschehen möge). Dann muss das KIM-PF mit dem ECC-Zertifikat verheiratet werden. Ein zusätzlicher Grund ist unter Anderem die Bereitstellung des öffentlichen Schlüssels im Verzeichnisdienst.

Wie gesagt: Ich habe die ersten ECC-only-eHBA gesehen. Nach der Freischaltung der Zertifikate und Brechen der beiden Transport-PIN sind die ohne irgendwelche Anpassungen lauffähig in Konstellationen, in denen nichts außer einem Teil der Kartenleser auf ECC umgestellt wurde. Und zwar auch in den Kartenlesern, die noch eine alte RSA-only-gSMC-KT nutzen. Ausnahme wäre wirklich nur KIM mit eHBA-Registrierung.

Inwieweit die Aussage von T-Systems nun korrekt ist oder von unterschiedlichen Wissensständen, Begrifflichkeiten oder Intentionen der jeweiligen Abteilungen geprägt ist, sei dahingestellt.

* = Der eHBA ist dem Grunde nach eine zur EU-eIDAS-Verordnung konforme Signaturkarte mit zusätzlichen Funktionen. Die Signaturkarte "dahinter" ist nicht an die Ti gebunden.