Im Workshop vorgestellter Foliensatz

Kontakte

 Folgende Kontakte betreuten Sie im Termin auf Seiten der gematik:

Team

Kontakt

Name

Rolle

Produktteam Edge



pt-edge@gematik.de

Aliye Selcuk

Produktkoordination

Nicole Senger

IT-Projektleitung

René Lohe

Product Owner

Claudia Krüger

Produktmanagement

Ferdinand von Rottenburg

Solution Architect

Erik Münz

Solution Architect

Tomasz Jaworek

Solution Architect

Elke Kellmann

Agile Coach

Smartcards


smartcards@gematik.de

 

Hauke Langhoff

Produktmanagement

Susanne Dupré

Systems Engineering

RSA2ECC Projektteam


 

rsa2ecc@gematik.de


 

Sebastian Völker

IT-Projektleitung

Benny Geitner

Product Owner / Project Coordination

Jennifer Bodemer

Project Coordination

Theresa Weiss (im Workshop nicht
anwesend gewesen)

Projektleiterin Primärsystemumstellung RSA2ECC

Operations

roberto.hengst@gematik.de

Roberto Hengst

Experte für Primärsysteme


Das Produktteam (PT) Edge befasst sich mit der Koordination (Spezifikation/Zulassung/Test) der "Dezentralen Komponenten"* der TI.
Dies umfasst Konnektoren (EBK/HSK), TI-Gateway und auch Consumer.

*außer Kartenterminals. Diese werden im PT Smartcards koordiniert.






HerstellerKontakt
Secunetsupport.ehealth@secunet.com
KoCo/CGMdirk.engel@kococonnector.com

Im Laufe des Termins wurden wir gebeten verschiedene Links zu Teilen. Wir stellen Ihnen diese gerne zur Verfügung: 



Hinweise/Anmerkungen/Wünsche 

Im Laufe des Termins haben wir verschiedene Hinweise, Wünsche und Anregungen im Chat und im verbalen Austausch vernommen. Für eine bessere Lesbarkeit und Übersichtlichkeit des Protokolls fassen wir diese hier zusammen: 

  • Es wurde angeregt eine Umfrage unter den PS-Herstellern mit den folgenden Fragestellungen durchzuführen: 

    1. "Was ist der früheste Termin, zu dem ein ECC-Rollout im Feld von Ihnen für Ihre Kunden durchgeführt werden kann?" (Datum)
    2. "Welches sind die dafür zwingend benötigten Vorbedingungen und welche zeitlichen Abstände ergeben sich dazu? (Freitext)

     

Informationen zum Zugriff auf Confluence-Seiten der gematik:

Sollten Sie Probleme mit dem Zugriff auf Confluence-Seiten der gematik haben, können wir Ihnen folgende Hinweise mit an die Hand geben: 

  • für den Zugriff muss die Zwei-Faktor-Authentifizierung erfolgen. Sollte sich die Seite nicht öffnen lassen, können Sie folgende Schritte probieren:
    • Da es sich um veröffentlichte Seiten in unserem Confluence handelt, konnten wir hin und wieder das Phänomen feststellen, dass sich Partner vorher von ihrem gematik Account abmelden müssen. Danach war die Seite erreichbar. 
    • Schließen Sie die Seite. Versuchen Sie sich neu anzumelden. 

 
Anmerkungen der Workshop Teilnehmer zur Umstellung RSA zu ECC: 

Ergänzende Anmerkungen zum Austausch auf der Tonspur und aus dem Chat:

  • Kommunikation an Leistungserbringer: Der Aspekt bezüglich Kommunikation an Leistungserbringer ist für die Hersteller bisher sehr neblig und intransparent

  • Bitte an die gematik um verbindliche Aussage zu Zeitplänen und Lieferungen.
  • Es wurde der Wunsch nach mehr Transparenz bzgl. Lieferdaten geäußert.
  • RSA to ECC betrifft vieles: KIM Clients, gSMC-KT, SMC-B, eHBA, Konnektoren, PVS. Insbesondere beim Thema eHBA und SMC-B können wir als Primärsystemhersteller im Prinzip nichts beeinflussen.
  • Infos zu ALLEN Komponenten bzgl. ECC-Fähigkeit werden gewünscht, weil PS-Hersteller die erste Stelle sind, die von Nutzern befragt wird, z.B. welche Firmware wird eingesetzt, Codebeispiele (API etc.), wie die ECC-Fähigkeit und die FW abgefragt werden kann


Hinweise zur RSA2ECC-Migration und dem damit verbundenen Kartentausch:

  • Nach der Einschätzung der Teilnehmer wird der Austausch der HBA's zu Ende 2025 ist zu spät betrachtet.

  • Wenn die HBAs und SMC-Bs Ende des Jahres massenhaft getauscht werden, müssten durch DVOs ausreichend Arzt-freundliche Termine zur Verfügung gestellt werden (was Ende des Jahres oft ein Problem darstellen dürfte), um die notwendigen Anpassungen im PVS und bei den Zertifikaten durchführen zu können. Hier wird es Reibung und weiteren Vertrauensverlust in die TI geben. Zudem entstehen Kosten, welche eine Erhöhung der TI-Pauschale nach sich ziehen müssten.
  • Wenn die Umstellung zum 01.01.26 noch nicht 100% sicher ist, dass es nur noch ECC gibt, sollte man lieber über den 01.01.26 die Karten noch mit RSA ausliefern und dann nicht mehr verwenden, wenn doch wirklich abgeschaltet wird. 
  • Der schlimmste anzunehmende Fall aus Sicht der Industrie ist:
    • ..die ECC Karten sind am 31.12.25 im Briefkasten der Praxis und am 01.01.2026 wir RSA abgeschaltet. Also benötigen wir als PVS-Hersteller einen transparenten und konkreten Termin deutlich vor Jahresende, eigentlich sofort!
  • Es wurde der Wunsch nach Testfällen für KIM geäußert. Möglichst noch vor der ePA.
  • Bitte nach Offenlegung zu den Informationen von Kartenanbietern. 
  • Hinsichtlich der Kartentests wünschen sich die PVS Hersteller eine Übersicht, wie sie die Karten abfragen können. Eine Aufarbeitung in Form einer Tabelle wurde vorgeschlagen in der sich ablesen lässt welche Karte welche Firmware, Version usw. beinhaltet.
  • Es wurde der Hinweis gegeben, dass die SMC-B-Karten-Ausgabe mit gleicher TelematikID nicht gut im Feld funktioniert. Verbindliche Aussagen zu Prozessen, Komponenten und Zeiten sind an der Stelle für die PS-Hersteller notwendig, da sie von den Nutzern häufig als erstes bei Problemen befragt werden


Hinweise zur Info-Seite der ECC-Komponenten:

  • Es wurde der folgende Wunsch  bzgl. der Einordnung der Übersichtsseite zu den ECC-TI Komponenten mitgeteilt:
    • die Übersichtstabelle liegt als Seite unterhalb von "ECC Testwochen".
    • um schneller die gesuchte Seite zu finden, wurde vorgeschlagen, die Seite direkt unter "RSA2ECC-Migration" zu hängen. 
  • Für die Übersichtlichkeit wird eine Tabelle gewünscht, auf der idealerweise zu den Herstellernamen noch die jeweilige Hersteller-Produktversion aufgeführt sind. Die Angaben von gematik Produkt- und Produkttypversion hilft nicht für eine Prüfung im Feld, denn dort sind die Herstellerversionen einsehbar. Daher wäre es gut, die verschiedenen Herstellerversionen (die zugelassen und im Kontext RSA2ECC geprüft wurden) angegeben werden.
    • Ergänzend dazu wurde  weiterhin gewünscht: 
      • Und dann, pro Komponente, die API,/das Codebeispiel um abfragen zu können, welche Version diese Komponente hat. Falls es bei bestimmten Komponenten keine einheitliche API/kein einheitliches Codebeispiel gibt, dann jeweils pro Hersteller/Produkt.
      • Wiki-Seite mit immer aktuellen Firmware-Download-Links (RU) wäre doch auch fein 
      • Vorab-Firmwareversionen der Hersteller sollten auf RUAsAService bereitgestellt werden! Und das idealerweise verbindlich. Dann braucht man auch keine individuellen Kontakte.
  • Folgende Erfahrung zu einem Fall von vor ein paar Wochen geteilt:
    • Die Ärztin wollte unbedingt Arvato-KimClient und Secunet auf dem neusten Stand haben. Dort ist bereit RSA aus der Secunet Oberfläche entfernt worden, und es ging laut Support nix mehr. Erst nachdem dort ein ECC-Client-Zertifikat erstellt und im PVS/Kim-Client-Module hinterlegt wurde, funktionerte alles wieder.

Anmerkungen zum Authenticator und ECC-Testtool

  • Die Anzeige im gematik Authenticator ist schön. Aber es fehlt eine klare Interpretation eine klare Handlungsanweisung für den Anwender. So führt das wieder zu Rückfragen.
  • Die Teilnehmer haben mitgeteilt, dass das Testtool nicht ausreichend ist. Sie brauchen einen "echten" Konnektor um die Tests durchzuführen.
    • Die Erfahrung der letzten Jahre zeigte immer Unterschiede zwischen allen Simulatoren und allen Konnektoren auf


Anmerkungen zur Vorstellung der PTV6

  • Es besteht die Sorge, dass Informationen zur PTV6 nicht korrekt bei den Ärzten ankommen und folgende Annahme bei den Ärzten besteht: 
    • PTV6 wird wieder ein kostenpflichtiges Upgrade bzw. erfordert eine Lizenz das die Praxen erstmal beim Anbieter kaufen müssen.
    • Wenn ja, dann bedeutet dies, dass der Großteil dies nicht bis Ende des Jahres bestellen und terminieren werden.
    • PTV6 müsste, da es keine Zusatzfunktionen bringt sondern nur technische neue Anforderungen umsetzt kostenfrei und automatisch zur Verfügung gestellt werden.
  • Die PVS/AVS hätten gerne eine (pro Konnektor-Hersteller) konkrete Ausführung der für PTV6/PTV2 vorgenommenen Änderungen der Konnektor-Software und die damit ggf. begründete Notwendigkeit PTV6/PTV2 vor dem 31.12.2025 einzusetzen.
  • Das der SignatureType-Parameter bei ExternalAuthenticate nicht mehr ausgewertet wird, war bei den PSen ein großes Problem. Deren KIM-Client-Modul - Anbieter haben noch keine offizielle Freigabe für ihre neue Version seitens der gematik bekommen.
    • Entsprechend muss erst der Rollout aller KIM-Client-Modul-Anbieter abgeschlossen sein, bevor PTV6 ins Feld kommt!

  • Es wird nach Freigabe noch Zeit für den Rollout benötigt. Üblicherweise ist das 1x im Quartal.

  • Von den PSen wird gefordert, dass die rechtzeitige Bereitstellung von PTV6/2 für die Hersteller verpflichtend sein sollte.

  • Rollout nicht "verhindern", sondern "kontrolliert zu Zieltermin"

  • Die PSe müssen ja auch gegen die neue WSDL arbeiten, und parallel auf PTV5/PTV6 prüfen um die passende Dienstversion anzusprechen. Alles fehleranfällig... natürlich auch PS-seitig, nicht zwingend Konnektorseitig.

  • Folie 22 (Roadmap).

    • Es wird eine Zeitübersicht gewünscht, die die zwingend notwendigen Anpassungen der Primärsysteme (wenn nötig unterschieden nach PVS/AVS/KIS) mit einbeziehen!

    • Von den PS-Herstellern wird ein konkreter Termin angefragt, an dem die PSe Fertig sein müssen. 

  • Bereitstellung KSR und Manueller Download.

    • Es sollte vorab "künstlich" die Umstellung unterdrückt werden.

    • Wunsch nach einem konkreten Datum vor dem die KSR-Umstellung nicht stattfinden darf. (nicht vor Oktober) → davor gibt es keine automatischen Updates und Umstellung.

    • Das finale Datum ist noch in Konkretisierung. Aktuell ist August anvisiert. Das Datum wird über die gematik -Kanäle informiert.

    • Die KSR-Freischaltung kann geplant verzögert werden, damit alle PS im Feld vorbereitet sind. 

  • Die gematik sollte bitte eine möglichst vollständige Übersicht zur Verfügung stellen welche Systeme mit Brainpool und welche mit NIST und welche mit Sonstigen arbeiten bzw. ab PTV6 arbeiten werden.
  • Es wird darum gebeten, dass das Team an der eRezept-Sprechstunde mit kurzer Präsentation zum PoPP-Feature teilnimmt. Das Team wird nach der Veröffentlichung des Implementierungsleitfadens in der E-Rezept Sprechstunde vorstellen.
  • Bitte Link auf das Dokument in dem beschreiben wird, was PS-Hersteller entwickeln und testen müssen in Bezug auf PTV-Schnittstelle, also Übersicht über Änderungen statt nur komplett neue Schnittstellenbeschreibung. 
  • Autom. Re-registrierung am VPN-ZugD durch den PTV6
  • Autom. Wartungspairing mit dem KT, sofern die gSMC-KT G2.1 ist und KT FW aktuell ist
  • Das pairing und die Registrierung kann die gematik über BDE tracken

  • Da die verschiedenen Zertifikatswechsel das höchste Potential für (unvorhergesehene) Betriebsstörungen haben können, wäre es toll, wenn Ihr eine konkrete Festlegung & Übersicht auf der Confluence-Seite aufnehmen könnten:

    1. Festlegung, dass grundsätzlich ab dem 01.01.2026 RSA-basierte Zertifikate - unabhängig davon, ob die zugehörigen Schlüssel in einer Smartcard, einem HSM oder softwarebasiert gespeichert werden - nicht mehr verwendet werden können.
    2. Liste der Zertifikate, für die eine Ausnahme gemacht wird - und bis wann:
      1. Alle Zertifikate der gSMC-KT bis zum TT.MM.YYYY
      2. alle lokalen Zertifikate zwischen Konnektor und Clientsystemen (PS, KIM-CM etc.)


Absicht eines Folgeworkshops

  • Es wurde eine Umfrage an die Teilnehmer gestellt, ob es einen Folgeworkshop zur PTV2/PTV6 geben soll. 
  • 96% der Personen, die abgestimmt haben, sprachen sich für einen weiteren Workshop aus.
  • Die gematik wird sich um die Organisation eines zweiten Termins kümmern. 


Protokoll 


Agendapunkt

Frage

Antwort

Top 2

Aktuelle Situation und Herausforderungen RSA zu ECC-Umstellung 















Für Ärzte ist nicht ersichtlich auf welche Konnektoren sie setzen sollten. Auch für PS-Hersteller ist diese Frage schwierig zu beantworten. Fragen werden aber als erstes immer an die PS-Hersteller gerichtet. 


Was sollen Kunden wählen, wenn sie einen ablaufenden Konnektor durch neue Technik ersetzen müssen?

Wir wünschen uns mehr Transparenz in diesem Bereich. 

Wir als gematik empfehlen auf das TI-Gateway zu setzen. 


Die Anbieter bieten verschiedene technische Lösungen an für die Anbindung an das TI-Gateway (Softwareclient oder Hardwareclient; Protokolle Wiregard, IPSec, CCP) an und spezialisieren sich zum Teil auf bestimmte Nutzergruppen. 
Alle TI-Gateway-Anbieter bauen aktuell auf Komponenten von Secunet/Worldline, RISE oder eHEX auf. Schon heute gibt es ein großes Angebot für TI-Gateway-Anbindungen. Weitere Hersteller/Anbieter werden in Zukunft noch hinzukommen.

Zu dieser Antwort gab es ergänzende Anmerkung aus dem Teilnehmerkreis im Chat: 

  • "Es wird nicht bei nur 2 Anbietern bleiben. Die CGM wird in kürze auch Zugang zur TI über ein TI-Gateway anbieten."
  • "Das ist halt genau unser Problem, wir haben dafür einfach keine Zeit mehr bis Ende 25 und noch mehr Anbieter zu warten."

Was ist technisch das Problem? Weshalb Sie kein TI-Gateway mit einem Wireguard-VPN verwenden können?

Antwort eines Teilnehmers:

Weil unsere Router kein Wireguard unterstützt. Dabei handelt es sich nicht um einen kleinen Hersteller. In den Praxen sicherlich kein Problem aber größere Einrichtungen mit diesem Anbieter werden ähnliche Probleme haben.

gematik:

Wireguard wird nur von von dem TI-Gateway von RISE genutzt, wobei auch ein Software-VPN-Client verwendet werden kann.

Bei anderen Anbietern kann IPSec oder CCP mit Software-Client oder Hardware-Clients verwendet werden.

Werden HBAs kein RSA haben?

Ja, ab dem 01.01.2026 werden nur noch ECC-personalisierte HBAs ausgegeben.

Welche Vorlaufzeit haben die Kartenhersteller zum Ablauf der eHBA Karten? 

Medisign plant für den Kartentausch 5 Monate Vorlauf ein. Ab Juli 2025 werden Kunden von Medisign angeschrieben und über das Massentauschverfahren informiert. Dieses Verfahren ist mit der gematik abgestimmt. Jeder Anbieter macht das jedoch anders, da es verschiedene Stände und Laufzeiten gibt. 

Wenn neue Karten aktiviert werden, werden alte deaktiviert. Es gibt keine finanzielle Doppelbelastung.

Das Vorgehen der anderen Kartenherausgeber ist aktuell nicht bekannt.

Bleibt beim Kartentausch die Telematik ID die gleiche ?

Ja, solange es Austauschkarten sind.

Wann kommen ECC-only ins Feld? 

Die Karten werden ab 01.01.2026  für den HBA zur Verfügung stehen. Die Karten werden kein RSA-2048 Zertifikat haben.  

Wenn ECC-only-Karten genannt werden, ist dann nur Brainpool gemeint? In der Runde denken manche, dass es auch NIST-Karten geben wird. 

Kartengebundene ECC-Zertifikate nutzen immer Brainpool. Für die TLS-Authentifizierung bei der Verbindung zwischen Clientsystem und Konnektor können ECC-NIST Zertifikate verwendet werden (importiert oder im Konnektor generiert).

Wenn nur ECC, dann nur Brainpool ?

Die Antwort auf die Frage ist der FAQ-Seite zu entnehmen.

https://wiki.gematik.de/x/y9DEJg


Weitere Antwort aus dem Teilnehmerkreis im Chat: 

  • "m.w. auch NIST"
  • "Meines Wissens nach ist das NIST. Brainpool wird für die Client-Certificates gekickt. Zumindest ist das bei Secunet der Fall. Temporär kann man auswählen zwischen Nist und Bpool. Das soll wohl dann aber in einem späteren Update nur noch auf NIST beschränkt werden."
Gibt es ECC-only Testkarten?

Antwort von der gematik: 

leider werden physische ECC-only Testkarten erst Mitte August verfügbar sein.

Ersatzweise halten wir den Test mit Kartensimulationen für Tests des Konnektors für ausreichend.

Für Simulationen, die mit der von achelos vertriebenen Simulation kompatible ist, stellen wir hier ein passendes Image zu Verfügung:

HBA_80276883110000163974_gema5_arzt_ECC.zip

Andere non-achelos Simulationen sind selbst wie folgt anzupassen:

  • RSA Zertifikate mit 1 Byte "00" befüllt
  • RSA Keys unbrauchbar gemacht


Bei den oben angesprochenen Simulationen wird dieses umgesetzt mit

  • Für RSA Zertifikate:
    <attribute id="body">00</attribute>
    <attribute id="positionLogicalEndOfFile">01</attribute>

  • Für RSA Keys:
    <attribute id="keyAvailable">FALSE</attribute>


Damit ergibt sich folgendes Verhalten
Es kommt im Simulationslog eine 6400 wenn ein System auf einen 
RSA-Schlüssel zugreifen möchte

Es kommt im Simulationlog zu einem 6B00 wenn ein System davon ausgeht ein
vollständiges Zertifikat lesen zu wollen und dann nur 1 Byte erhält.

Wo finde ich eine vollständige Liste der Komponenten, die für RSA zu erfüllen sind?

Die Auflistung können Sie dieser Seite entnehmen:
https://wiki.gematik.de/x/QAhNJw

PS muss nicht angepasst werden, um ECC-fähiges KIM Client zu nutzen, aber was ist mit LDAP?

 
Wird der BrainPool jetzt gekippt oder ist das Bestandteil von PTV6, wo steht da die Änderung in der Spezifikation?

 
Bei RISE Konnektor V 6.0.8 gibt es die gSMC-K ECC mit Brainpool only! da gibt es dann Probleme mit LDAP (z.B. Thunderbird geht nicht).

Auch für LDAP kann das ECC-Brainpool-Zertifikat der gSMC-K durch ein generiertes oder importiertes ECC-NIST-Softwarezertifikat ersetzt werden, um so eine Kompatibilität mit diversen Clientsystemen herzustellen. Dabei ist zu beachten, dass ein und dasselbe Serverzertifikat für alle Clientsysteme und alle Schnittstellen (SOAP, LDAP, DVD) verwendet wird.

Mit PTV6 ist Brainpool als Option für generierte/importierte Zertifikate neuer Cleintsystemverbindungen entfernt. Es kann NIST oder RSA-3072 importiert oder vom Konnektor self-signed generiert werden.

Es sei denn, man wählt AK.AUT der gSMC-K. Dann ist es weiterhin Brainpool, da sich das nicht mit vertretbarem Aufwand ersetzen lässt.

Es werden im Konnektor genügend Konfigurationsoptionen für die Clientsystemverbindung angeboten, dass damit z.B. auch Thunderbird problemlos angebunden werden kann.

Laufzeitverlängerung des Secunet-Konnektor: Kommt der Konnektor damit klar, wenn RSA komplett abgeschaltet ist?
In der ECC-Testwoche konnte das nicht verprobt werden.

Laufzeitverlängerung betrifft nur die Konnektoren die dual personalisiert sind. Ob es bei der Laufzeitverlängerung nach Abschaltung von RSA zu Problemen kommen kann, wird von der gematik untersucht.

Die bestehenden RSA-Zertifikate auf der Strecke Client↔Konektor dürfen auch in 2026 verwendet werden (werden automatisch übernommen). Können alle KIM-CM (PTV 1.5.2-9) auch mit diesen RSA-Zertifikate weiterhin umgehen?

Die bestehenden RSA-2048-Zertifikate funktionieren weiterhin bis zu ihrem Ablauf oder bis sie durch sichere Zertifikate ersetzt wurden über den 01.01.2026 hinweg.

Die KIM-CM gemäß KIM PTV 1.5.2-9 sind z.T. jetzt schon im Feld und können mit aktuell verwendeten RSA-2048-Zertifikaten auf der Strecke Client↔Konektor umgehen. Diese Fähigkeit bleibt ihnen auch nach dem 01.01.2026 erhalten. 

Die Spezifikation der PTV6-Konnektoren sieht vor, dass diese Konnektoren bestehende RSA-2048-Zertifikate auf der Strecke Client↔Konektor auch in 2026 verwenden.

"Nur ECC-Only-Karten sollen ab 01.01.2026" rausgegeben werden. Heißt zwar, dass definitiv am 01.01.2026 ECC-Only-Karten existieren. Aber es kann auch heißen, dass schon vorher ECC-Only-Karten raus gehen könnten. Daher, die Frage: Ab wann können/dürfen ECC-Only-Karten "im Feld existieren"?

ECC-Only-Karten dürfen frühestens am 1.1.2026 im Feld existieren. Vorher wird es (außer in TU/RU zu Testzwecken) keine solche Karten im Feld geben.





Top 3

 ECC Testtools


Vorstellung Authenticator 












Gibt es noch andere Testfälle (außer eRezept), die sich auf ECC-Verhalten mit dem Tiger-Testtool testen lassen?
Der Testfall ist für PVS-Hersteller nutzlos, die selbst keine Rezepte erstellen. 

Der Testfall für das eRezept ist der erste Testfall. Es werden weitere kommen. Der nächste Testfall wird die ePA betreffen.  

KIM-Client Hersteller testen ihre Clientmodule selbst. Die PVS-Hersteller müssen die Clientmodule nur Updaten. Hier muss kein Parameter aktiv umgestellt werden.

Gibt es das Testtool auch für die Produktivumgebung? 

Nein.

Bisher noch nicht geplant. Kann aber zur Verfügung gestellt werden. Umstellung der Anbindung an den Konnektor kann jetzt schon erfolgen. 

Ist schon gewährleistet, dass es eine vollautomatische Migration gibt? Müssen Zertifikate automatisch hinterlegt werden? 

KIM Client Module werden automatisch die Zertifikate herunterladen. 
Zertifikate im Konnektor müssen händisch auf ECC umgetauscht werden. Hier gibt es keine vollautomatische Migration.

Was muss in der Konfiguration beachtet werden bei der Umstellung auf die PTV6? 

Demo des Authenticator Testtool:

Muss der Authenticator installiert werden? 

Die vorgestellten Benachrichtigungsfeatures zur Verwendung von G2.0-Karten im Authenitcator sind ein Hilfsmittel, für Institutionen, die den Authenticator bereits einsetzen. 

Nur für diese Benachrichtigung einen Authenticator zu installieren wird nicht empfohlen. Karteninhaber werden im Rahmen des Massentausches von den Herausgebern angeschrieben. Außerdem wird der PTV6 über entsprechende Betriebszustände über die Verwendung von G2.0 Karten Informieren.

Können wir das ECC-Testtool nicht als WebFrontEnd zur Verfügung stellen? Ohne Installation bei uns?

 Ist aktuell nicht möglich.

Müssen bei tausenden von Praxen das P12 Zertifikat manuell getauscht werden?

 

Nein.

Client-Zertifikate müssen mit PTV6 nicht erneuert werden. Bestehende Konfigurationen für die Clientsystemverbindungen werden vom PTV6-Konnektor weiterhin so wie sie sind akzeptiert, auch wenn diese nicht das erforderliche Sicherheitsniveau von >120 Bit erfüllen.

Dennoch empfiehlt die gematik, die Konnektorkonfiguration von bestehenden Clientsystemverbindungen im Konnektor zu prüfen und zeitnah auf jeweils eine der folgenden Verbindungen umzustellen. Diese Umstellung ist jedoch optional und nicht zwingend bis zu einem Stichtag umzusetzen.:

  • RSA-3072
  • ECC-NIST
  • ECC-Brainpool des AK.AUT der gSMC-K

Im Standard ist das RSA aber auf 2048, daher die Frage, wie stelle ich denn ein RSA-2048 auf RSA-3072 um?

Antwort eines Teilnehmers:
Zumindest beim RISE Konnektor kann man das beim Erstellen des Clientzertifikates auswählen, welchen Algorithmus man haben möchte

KoCo führt das Vorgehen bei ihren Konnektoren aus. Bei der KoCoBox kann das bei der Erstellung über die Oberfläche ausgewählt werden. Mit PTV6 wird die Auswahl auf RSA-3072 & ECC Nist eingeschränkt. (RSA-2048 und ECC Brainpool entfallen)

Ein RSA-3072 kann auch nach dem 31.12.2025 genutzt werden obwohl ab dem 01.01.2026 nur noch ECC gültig sein sollte?

Ich wäre jetzt davon ausgegangen, dass alles was mit RSA zu tun hat in sämtlichen Optionen entfällt.

RSA-3072 wird beim Konnektor weiterhin möglich sein. Das ist dort jedoch nur bei der Clientsystemauthentisierung möglich/relevant. (warum nicht alle RSA? --> nach SOG-IS sind nur RSA Schlüssellängen < 3000 Bit ab 2026 unzulässig. RSA-3072 ist daher noch okay)

Beim RSA-Phase-Out geht es nicht Pauschal "gegen" RSA. Vielmehr wird ein Sicherheitsniveau von mindestens 120 Bit gefordert, welches mit einem RSA Zertifikat mit mindestens 3000 Bit Schlüssellänge oder einem ECC Zertifikat erreicht werden kann.

Authenticator:

Es wäre gut wenn die Erkennung von nicht ECC fähigen eHBAs / SMC-Bs anhand der Versionsnummer kurz dokumentiert wird. Dann könnte man eine Prüfung ins PVS einbauen.

Wir prüfen anhand der ObjectSystemVersion die innerhalb des Zertifikates der Karten zu finden ist - wir nutzen dafür die Konnektor Abfrage "CardHandle", da diese das für uns auslesen kann.

Alle Karten (SMC-B, HBA und gSMC-KT) die eine ObjectSystemVersion <= 4.3.0 haben - können nur RSA und sind somit Karten der Generation 2.0 (die Generation steht auch auf den Karten selbst drauf)

Karten dessen ObejctSystemVersion >4.3.0 , also ab 4.4.0, besitzen, können ECC und RSA - hierbei handelt es sich also um Karten der Generation 2.1 (diese Generation steht ebenfalls auch auf den Karten selbst)

Ist der Authenticator ein Online-Service oder muss lokal installiert und eingerichtet werden?

Der gematik Authenticator ist keine Online-Service-Anwendung, sondern muss für die Verwendungen von Webanwendungen wie beispielsweise das Organspenderegister, lokal installiert werden.

Mit der Umstellung auf die TI-Pauschale gibt es keine spezielle Finanzierung für neue Konnektorversionen mehr. Für die Preisbildung ist der Markt verantwortlich.




Top 4

Konnektor und High-Speed-Konnektor als wichtige dez. Komponenten für die Umstellung













Nur RSA-3072 oder ECC Nist. Oder gibt es auch die Erstellung ECC und RSA-3072?

Mischkonfigurationen für verschiedene Clients sind möglich.

Ist gewährleistet, dass beim Update PTV5 →  PTV6 bestehende hinterlegte (ggf. alte) Client-Zertifikate weiterhin funktionieren?

Ja. 
Bestehende konfigurierte RSA-2048-Zertifikate sind nach PTV6 Update weiterhin nutzbar und werden nicht automisch gelöscht oder dergleichen.
Der Konnektor verwendet die bestehenden, konfigurierten RSA-2048-Zertifikate nach dem PTV6-Update automatisch weiter ohne Zutun des Nutzers. Das funktioniert so lange, wie das RSA-2048-Zertifikat gültig ist oder bis ein neues Zertifikat gewählt wird. Dieses neue Zertifikat darf nur ECC-NIST oder RSA-3072 oder ECC-Brainpool des AK.AUT der gSMC-K sein, etwas anderes akzeptiert/bietet der PTV6-Konnektor nicht an. 

Wenn der PTV6-Konnektor RSA-Signaturen bei alten G2-Karten weiterhin unterstützt: 

Warum wird die Umschaltung auf "ausschließlich ECC-Signaturen bei Gen2.1-Karten" im PTV6 nicht zeitgesteuert am 31.12.2025 scharf geschaltet?

Nur die harte Umstellung auf Nur-ECC für Gen2.1 in PTV6 führt zu einem notwendigen Vorab-Rollout von Primärsystemen VOR dem 31.12.2025.

Daher wäre es für das Gesamtvorhaben sinnvoll, wenn der PTV6-Konnektor das Ignorieren des Übergabeparameters für Signaturen erst zum 31.12.2025 scharf schaltet!

Die gematik plant, solch einen Stichtag, bis zu welchem hart die Umstellung der Primärsysteme auf PTV6 abgeschlossen sein muss, festzulegen. Es wird jedoch ggf. nicht der 31.12.2025, sondern ein Termin noch zeitiger im Q3/Q4 2025 gelegen sein.

Wenn ein Konnektor zu einem Stichtag sein Verhalten ändert, kann dieses zu nicht beherrschbaren Anfragespitzen im Support kommen, außerdem erschwert es die Kompatibilität mit dieser Konnektorversion zu testen. Daher haben wir keine datumsgesteuerten Verhaltensänderungen spezifiziert.

Das Fachdienst Zertifikat wird vom KIM-Client automatisiert ausgetauscht. Es muss nichts manuell gemacht werden. Richtig?

Im KIM-Client Modul sind zwei weitere Zertifikate hinterlegt:

Ein Konnektor Serverzertifikat im PEM-Format. >> Muss dieses Zertifikat im KIM-Client Modul ausgetauscht werden? Wenn ja, geschieht dass dann auch automatisiert durch das Update des KIM-Client Moduls?

Zudem wird zur Client-Authentifizierung ein PKCS12 Zertifikat + Passwort verwendet. >> Muss dieses Zertifikat im KIM-Client Modul ausgetauscht werden? Wenn ja, geschieht dass dann auch automatisiert durch das Update des KIM-Client Moduls?

Das Fachdienst-Zertifikat wird vom KIM-CM beim Update automatisiert ausgetauscht, falls es nicht schon vorher manuell getauscht wurde. Es muss beim Update nichts manuell gemacht werden.

Das Konnektor-Serverzertifikat kommt von der gSMC-K oder ist generiert/importiert und wird mit dem Update auf PTV6 beibehalten, auch wenn es ein RSA-2048-Zertifikat ist. Allerdings meldet der PTV6 über einen Betriebszustand, dass das Konnektor-Serverzertifikat die geforderte 120bit Länge nicht hat und gewechselt werden muss. 

Wenn das Konnektor-Serverzertifikat durch einen Administrator gewechselt wird, muss es allen Clientsystemen bekannt gemacht werden, die diesen Konnektor nutzen - auch den KIM-Clientmodulen. Dies muss u.U. nicht der Fall sein, wenn das Konnektor-Serverzertifikat z.B. von einer externen PKI kommt, die den Clients bekannt ist.

Das Client-Zertifikat des KIM-Clientmoduls wird beim Update auf PTV6 weiterverwendet, sollte aber bei der nächsten Möglichkeit durch ein RSA-3072 oder ECC-Zertifikat getauscht werden.

Erst, wenn PTV6-Konnektoren (oder simulierte Ziel-Umgebung) zur Verfügung stehen, kann eine PS-Entwicklung gegen dieses Zielsystem erfolgen für ein getestetes Rollout eines PS.

Für die Simulation des PTV6-Verhaltens stellt die gematik einen Proxy bereit.

Sobald die Entwicklung der PTV6 Konnektoren abgeschlossen ist, können diese für die RU von den Herstellern bezogen werden.

Kann der PTV6 Rollout zentral gesteuert werden?

Ja, der PTV6 Rollout kann durch die gematik zentral durch freischalten der jeweiligen Firmwareversion auf dem KSR gesteuert werden. Dieses automatische Deployment setzt jedoch voraus, dass die Konnektoren in den LEI das "KSR Autoupdate" Feature aktiviert haben.

Ist das Feature deaktiviert, so muss die LEI (bzw. deren beauftragter DVO) sich selbst darum kümmern, die PTV6 Firmware zu installieren. 

Ist PTV6 Firmware kostenfrei oder wird es eine Lizenz geben? 

Muss der KSR Rollout auch von der gematik final freigegeben werden?

Die Preisbildung für das PTV6-Release erfolgt durch den Markt. Die Refinanzierung ist in der TI Pauschale enthalten. 

Der Starttermin für den Rollout über den KSR wird in Abstimmung zwischen dem Hersteller und der gematik festgelegt. Erst, wenn die gematik auch keine IOP Probleme im Feld identifiziert wird die Freischaltung über den KSR freigegeben.

Wird es Testkonnektoren mit PTV6 vorab für die PVS Hersteller geben? Wenn ja, ab wann?

 Müsste ja etwa 4-6 Monate vor Rollout sein.

Es wird keine kompletten Konnektor-Testgeräte für PTV6 geben. PS-Hersteller müssen die von ihnen selbst beschafften Konnektoren dafür nutzen.

Allerdings werden die Konnektorhersteller nach Abschluss von Entwicklung und Qualitätssicherung ihr PTV6-Zulassungsversionen als Firmwareimages zum Testen in der RU zur Verfügung stellen. 

Kann jemand von den Teilnehmern aus dem WS den ungefähren Entwicklungsaufwand in Manntagen mitteilen für die notwendigen Änderungen durch PTV6-Schnittstelle? 

Antwort eines Teilnehmers:

In unserer Software vermutlich 2-3 mit Testen (mal PoPP ausgelassen). Aber der Aufwand ist je nach Softwarearchitektur und Code-Qualtität, Fähigkeiten der Entwickler/Produkt-Management unterschiedlich. Aber die groben Änderungen sind ja erstmal nur die wenigen Konnektorfunktionen betreffend (siehe Folien). Und im Prinzip, können diese mit PTV5 bereits in dem Maße genutzt werden, dass präferiert ECC genutzt wird.

Die gematik müsste testen das sich die Konnektoren so wie das Testtool verhalten.

Die Simulation ermöglicht eine frühzeitige Entwicklung der PTV6-Kompatibilität, ersetzt aber nicht einen Abnahmetest gegen die Konnektorimplementierungen der Hersteller. Dafür wird sie aber keine Verantwortung - und Haftung! - übernehmen. Daher MUSS gegen jeden Konnektor und jeden HSK getestet werden!

Geht hierbei dann also um die ClientSystem Zertifikate zur Authentifizierung ggü. dem Konnektor?

Ja, darum geht es.


 


Top 4. 2

Relevanz PoPP für PS 






Wie wird im PoPP-Kontext die Ablösung von CardLink aussehen? 

Mit der Abschaltung von VSDM1 wird die Nutzung von CardLink technisch nicht mehr möglich sein. Die Spezifikationen von PoPP sehen jedoch vor, dass die Nutzung der eGK über das Smartphone der Versicherten weiterhin technisch realisierbar bleibt. Voraussetzung hierfür ist die Integration des PoPP-Moduls in die jeweilige App (nicht zu verwechseln mit dem PoPP-Client für PS).

Die Kommunikation erfolgt direkt zwischen der eGK und dem PoPP-Service, um die Authentifizierung der Karte sicherzustellen. Welche Use Cases unterstützt werden, legen die Fachdienste der jeweiligen Anwendungen fest.

Für die versicherte Person bleibt der Workflow mit der eGK vergleichbar mit dem bisherigen eH-CardLink-Prozess und fühlt sich entsprechend vertraut an. 

Bitte beachten, dass dies der aktuelle Stand der Vorveröffentlichung der PoPP-Service Spezifikation ist.

In Bezug auf die Antwort zur Frage "Können wir beim Thema PoPP darauf eingehen wie die Ablösung von CardLink aussehen wird?"
→ Und wie funktioniert das TAN-Verfahren das damit einhergeht?

CardLink ist eine Brückentechnologie, die nach der vollständigen Einführung von PoPP und dem damit verbundenen Abschalten von VSDM 1 ihre technische Grundlage verliert. Mit der Bereitstellung des PoPP-Service wird es bis zur Ablösung einen befristeten Parallelbetrieb von CardLink und PoPP geben. 

Die konkrete Ausgestaltung der Workflows wird im ILF bzw. in der PoPP-Modul-Spezifikation beschrieben; diese befindet sich derzeit noch in der Erstellung.

In Bezug auf die Antwort zur Frage "Können wir beim Thema PoPP darauf eingehen wie die Ablösung von CardLink aussehen wird?" → 

Gibts da schon ungefähre Zeitpläne was die Abschaltung von VDSM1 angeht?

Der PoPP-Service wird voraussichtlich Mitte 2026 bereitgestellt. Der Rollout in den Primärsystemen ist für einen Zeitraum von sieben Monaten geplant. Die Abschaltung von VSDM1 erfolgt jedoch erst nach vollständigem Abschluss des Rollouts, das heißt, sobald keine Nutzenden mehr VSDM1 verwenden.

Wie funktioniert der mobile Check in bei PoPP? Gibt es Unterschiede zu Cardlink im Workflow für den Nutzer?

Die konkrete Ausgestaltung der Workflows wird im ILF bzw. in der PoPP-Modul-Spezifikation beschrieben; diese befindet sich derzeit noch in der Erstellung.

Der Umsetzungsleitfaden ist aber noch "work in progress", oder?

Meines Wissens ist nur der E-Rezept-Teil fertig. Wenn das stimmt, zu wann wir der fertig sein?

Die Veröffentlichung des ILFs erfolgt iterativ. Eine erste Veröffentlichung ist in den nächsten Wochen geplant.

Wird PoPP die bisherige Authentifizierung mit SMC-B und IDP zum E-Rezept Fachdienst ablösen?

Für das Einstellen von eRezepten wird PoPP nicht genutzt. Nur für den Abruf wird zukünftig PoPP notwendig sein.




Top 4.4 

Roadmap zum Rollout PTV6 und PTV2 



Wo finde ich die PTV6 WSDL?

Für EBK ist sie hier im Ordner "conn" zu finden: https://github.com/gematik/api-telematik/releases/tag/6.0.1


Für HSK ist sie hier im Ordner "conn" zu finden: https://github.com/gematik/api-telematik/releases/tag/hsk_2.0.1

Wann bietet der erste Hersteller seinen Rollout auf PTV6 an? 

Gibt es eine Herstellerübergreifende Vereinbarung, dass es zu einem gemeinsamen Stichtag die Umstellung erfolgt. 

Nach aktueller Planung wird der erste Rollout von PTV6 im November starten. 

Es gibt keine Herstellerübergreifende Vereinbarung zum Starttermin der Umstellung.




Top 5

Diskussion / Fragen der Industrie 






Wir brauchen einen harten Termin für den Rollout und nicht nur tracking der Abhängigkeiten.

Der Hersteller kann bei PTV6 nicht selbst entscheiden, wann PTV6 ins KSR kommt

gematik sorgt dafür, dass keine automatischen Updatemechanismen vor einem TBD Stichtag umgesetzt werden

AUßER, es ist durch Feldinfos nachgewiesen, das man bereits vor dem Stichtag ausrollen kann

Wann können wir als Hersteller eine PTV6 Version für meinen Test-Konnektor bekommen, um Anpassungen und Test machen zu können? 

Bitte Tiger Testtool nutzen. Wenn es um Konnektor Hersteller spezifische Tests geht, dann die RU Zulassungsobjekte von den Herstellern holen, indem diese kontaktiert werden.

Serverzertifikat muss nicht geändert werden. 

Das Konnektor-Serverzertifikat und hinterlegte Clientzertifikate werden durch das PTV6 update nicht geändert. Der Konnektor zeigt die zu kurzen Schlüssel über einen Betriebszustand an. Server und Clientzertifikate müssen dann bei Gelegenheit auf RSA-3072 oder ECC manuell umkonfiguriert werden.

Das TI-Gateway in der Cloud. Wie sieht die Zukunftsperspektive aus? 

Kurzfristige Lösungen gibt es hier nicht. Eine Perspektive in Richtung Zero Trust wird angestrebt und wird Anwendungsweise ausgerollt. Der erste Rollout erfolgt im nächsten Jahr. 

Was wird an die LE kommuniziert? z.B. Austausch Kartenmaterial. 
Worauf müssen die PS noch achten und kommunizieren? Was müssen sie noch leisten?

Wir als gematik haben noch keine öffentlichen Kampagnen vorgenommen. Aber wir sind im Austausch mit den Gesellschaftern. 

Ausgabe nach HBA Karten bzgl. Krypt Parametern. 

Primärsysteme sollten dem der Herausgabe von ECC-only HBA ab 01.01.2026 vorbauen, indem Sie für Signaturaufrufe mit einem HBA den Aufrufparameter CRYPT=RSA_ECC hinzufügen. Dieser Parameter bewirkt, dass bei G2.1-Karten eine ECC-Signatur erzeugt wird und ein fehlendes RSA-Zertifikat auf der Karte (nach aktuellem Kenntnisstand) keine Auswirkungen hat. Damit können auch nach dem 01.01.2026 herausgegebene HBA an einem PTV5-Konnektor verwendet werden.

Anwendung für Versicherte mit PoPP-Feature in der Apotheke. 

Das PoPP-Feature wird das VSDM-Verfahren für die Einlösung von eRezepten ersetzen. 

Die Nutzererfahrung bleibt unverändert beim Stecken der eGK. Für Versicherte gibt es hier keinen Unterschied. 


 

 

  • No labels

© gematik GmbH 2025