Allgemeines
PTV6 und PTV2
Zum Jahreswechsel 2025/2026 stehen zwei große Änderungen für die TI an, die zwingend Anpassungen im Konnektor verlangen:
- Ablösung von RSA-Kryptographie durch ECC-Kryptographie
- Ablösung von VSDM 1.0 durch VSDM 2.0
RSA-2048 ist nur bis Ende 2025 vertrauenswürdig. Die Eignung für die TI wurde vom BSI in der technischen Richtlinie bis Ende 2024 festgelegt und bis Ende 2025 verlängert. Mit dem Feature ECC-preferred, dass in Einboxkonnektor PTV6 und HSK PTV2 spezifiziert wurde, wird diese Umstellung umgesetzt. Dabei wurde auch Funktionalität ergänzt, welche der gematik über Betriebsdaten die Verwendung von Smartcards (gSMC-KT, HBA, SMC-B) ohne ECC-Zertifikate sichtbar macht.
Im SGB V §291b Abs. 1 wird für VSDM 2.0 als gesetzliches Startdatum der 1.1.2026 festgelegt. VSDM 2.0 erfordert den Nachweis des Behandlungskontextes über das Feature PoPP (Proof of Patient Presence). Für Umgebungen, die eHKTs nutzen, ist eine Erweiterung der Konnektoren (EBK und HSK) für die Kommunikation zwischen PoPP Dienst und Kartenterminal notwendig. Diese Funktionalität wurde in der PTV6 für die Einboxkonnektoren und PTV2 für die HSKs spezifiziert.
Mit der Einführung von PTV6 (Konnektor) bzw. HSK PTV2 (Highspeed-Konnektor) stehen entscheidende Änderungen bevor, die Ihre Systeme betreffen. Um eine reibungslose Umsetzung dieser Änderungen sicherzustellen und die Interoperabilität (IOP) zu gewährleisten, möchten wir Sie über die wichtigsten Neuerungen und Anforderungen informieren:
Wichtige Änderungen mit PTV6 und PTV2
RSA2ECC-Migration: PTV6 unterstützt den Übergang zu ECC (Elliptic Curve Cryptography). Es werden keine neuen TLS-Verbindungen mit RSA mehr konfigurierbar sein. Bitte stellen Sie sicher, dass Ihre Systeme auf ECC umgestellt sind.
Breaking Changes: Änderungen an Schnittstellenoperationen wie EncryptDocument, SignDocument, und ExternalAuthenticate erfordern Anpassungen in Ihrem System. Bitte überprüfen Sie die entsprechenden Rückgabewerte des Konnektors vor der Weiterverarbeitung in Ihrem System.
PoPP-Feature: Das neue PoPP-Feature (Proof of Patient Presence) muss in Ihre Systeme integriert werden. Alternativ können Sie die Interoperabilität mit einem separaten PoPP-Client sicherstellen.
Roadmap zum Rollout PTV6 (Konnektor) und PTV2 (HSK)
Die Roadmap befindet sich aktuell in Überarbeitung. Wir erwarten von den Herstellern angepasste Roadmaps.
Stand vom
FAQ
Nummer | Fragen der Industrie | gematik |
---|---|---|
28 | ||
27 | ||
26 | Bezüglich VSDM2/Popp-Client: Mir ist nicht klar, was hier der konkrete Zusammenhang mit der RSA/ECC Umstellung ist, für uns ist dies an sich ein getrenntes Thema. Trotzdem ist für uns natürlich interessant, wie hier ein realistischer Zeitplan aussieht: - Wann ist die Spezifikation für den PoPP-Client finalisiert? - Wann stehen Testmöglichkeiten für den PoPP-Client und das VSDM2 bereit? - Wann ist es in der RU verfügbar? - Wann ist es in der PU verfügbar? - Wieviel Zeit rechnet die Gematik hier für die Implementierung in den Primärsystemen ein um einen Termin am 1.1.2026 noch realistisch halten zu können? | Wir würden zum Workshop am 03.06.25 einen entsprechende Zeitplan mitbringen, aus dem die angefragten Daten hervorgehen. |
25 | Vorausgesetzt wir haben einen PTV6 Konnektor und ein Primärsystem, welches EEC bereits voll unterstützt. - Welche konkreten Schritte/Prüfungen sind notwendig um sicherzustellen, dass es in der Umgebung der Praxis keine Komponenten mehr gibt, die bei der RSA-ECC-Umstellung ausfallen könnten. - Haben die PTV6 Konnektoren eine Prüfmöglichkeit/Warnlisten oder ähnliches oder müssen wir als Primärsystemhersteller jede Komponente einzeln prüfen? Gerne für den Workshop mitnehmen. Es sollte unserer Ansicht nach sehr detailliert für jede einzelne mögliche Komponente konkret dargestellt werden, wie wir als Primärsystemhersteller die Voraussetzungen in der Praxis Prüfen können und über die notwendigen Schritte informieren/warnen können. | |
24 | Spricht was dagegen, bei "SignDocument" den Crypt-Parameter IMMER auf "RSA_ECC" zu setzen, für alle Dokumente, nicht nur fürs E-Rezept, wie heute empfohlen? Oder gibt es Anwendungsfälle für die Signatur (insbesondere unser Hauptanwendungsfall EBZ), die noch nicht ECC-Ready sind? | Es wird empfohlen bei "SignDocument" den Crypt-Parameter immer auf "RSA_ECC" zu setzen. Die so entstandenen ECC-Signaturen (die PTV5-Konnektoren im Feld agieren mit dem Parameter ECC-preferred) können von allen prüfenden Komponenten der TI (EBK, HSK, BC) verifiziert werden. |
23 | "ca. 2/2 der Konnektoren haben Autoupdate aktiviert. " Wenn das stimmt hätten alle Konnektoren Auto Update aktiv. Stimmt das? Oder ein Schreibfehler | gemeint ist die Hälfte der Konnektoren |
22 | PoPP-Feature: Das neue PoPP-Feature (Proof of Patient Presence) muss in Ihre Systeme integriert werden. Alternativ können Sie die Interoperabilität mit einem separaten PoPP-Client sicherstellen. Wer muss alles PoPP realisieren? Apotheken, KIS, Software für Arztpraxen? Gibt es eine spez. Spezifikation? | - Alle Primärsysteme, die den LEIs Zugriff auf VSDM2, ePA oder eRezept ermöglichen, müssen zukünftig PoPP unterstützen. |
21 | Ist das Verständnis korrekt, dass die "breaking changes" im Endpunkt "ExternalAuthenticate" darin liegen, dass
| Ja, die Änderung ist hier ebenfalls analog wie oben. Der Parameter "SignatureType" wird nicht ausgewertet und das Signaturverfahren wird über die Kartenversion bestimmt. Sie können hier nichts parametrieren und müssen in der Response der Operation prüfen, welches Signaturverfahren Anwendung fand. Diese semantische Änderung in der Auswirkung des Parameters "SignatureType" so wie das diesbezüglich geänderte Verhalten der Operation stellen ebenfalls eins der "breaking changes" bei PTV6 dar. |
20 | Ist das Verständnis korrekt, dass die "breaking changes" im Endpunkt "SignDocument" darin liegen, dass der Eingabe-Parameter "SIG: Crypt"
| Ja, die Änderung ist hier analog wie bei "EncryptDocument". Der Parameter "Crypt" wird nicht ausgewertet, daher ist er zwar syntaktisch optional aber semantisch nicht mehr. Das Primärsystem muss unabhängig vom CRYPT-Parameter sowohl mit RSA-Artefakten als auch mit ECC-Artefakten in der Antwort zurechtkommen. |
19 | Ist das Verständnis korrekt, dass die "breaking changes" im Endpunkt "EncryptDocument" darin liegen, dass die Eingabe-Parameter "KeyReference" und "Crypt"
| Ja, die beiden Parameter werden nicht ausgewertet, daher sind sie zwar syntaktisch optional aber semantisch nicht mehr. Andersrum gesagt: Sie können hier nichts parametrieren. Das Primärsystem muss unabhängig vom CRYPT-Parameter sowohl mit RSA-Artefakten als auch mit ECC-Artefakten in der Antwort zurechtkommen. |
18 | Bei welchem Konnektor mit welcher Firmware-Version wird ein Downgrade von PTV6 auf eine PTV5-Version erfolgreich sein und bei welchen Kombinationen nicht? Gibt es hier Unterschiede zwischen RU- und PU-Konnektoren? | |
17 | Gibt es einen "Zeitpunkt", ab dem Primärsystemanbieter frei umstellen können und im Zweifel auch zurück können? | Anpassungen an Primärsystemen sollten abwärtskompatible implementiert werden und können dann ab sofort ausgerollt werden. |
16 | Wie erkennen wir, ob SMC-B, SMC-Kt und HBA ECC fähig sind? Methode am Konnektor? | In der Übersicht der gesteckten Karten oder der Antwort auf getCards kann die Version der Karte eingesehen werden. ECC fähig sind Karten ab folgenden Versionen SMC-B PTV 4.8.0 HBA PTV 4.7.1 gSMC-KT PTV 4.4.1 |
15 | Was ist denn wenn bei dem Wartungspairing kein Pairing Block mehr zur Verfügung steht? | Wenn kein freier Pairingblock vorhanden ist, überschreibt das Kartenterminal den ältesten Eintrag. |
14 | Welche gSMC-KT funktionieren? Wie wird die benötigte Version erkannt? | Für gSMC-KT wurde festgelegt, dass G2.0 Karten bis Ende 2026 weiterbenutzt werden können. Ein PTV6-Konnektor zeigt für alle gepairten Kartenterminals die verwendete Kryptographie (RSA, ECC) an. Der PTV6 Konnektor führt ein Wartungspairing mit den Kartenterminals durch, um das RSA Zertifikat durch das ECC-Zertifikat zu ersetzen. Voraussetzung ist, dass die Firmewareversion des Kartenterminals aktuell ist und eine G2.1 gSMC-KT steckt. Wird daher für ein Kartenterminal einige Tage nach dem PTV6 update immer noch RSA angezeigt, so steckt eine G2.0 gSMC-KT, die bis Ende 2026 getauscht werden muss. |
13 | Welcher Hersteller liefert wann PTV6 bzw. PTV2? | Die Roadmap ist auf dieser Confluence Seite hinterlegt, |
12 | Können Teams Kanäle ggf. genutzt werden, um Informationen weiter zu tragen? | Wir können relevante Informationen bzgl EBK/HSK auf RUaaS stellen. Dann könne sich die Hersteller darauf subscriben und wären up-to-date |
11 | Muss ich bei meinen EBK zum Stichtag das PTV6 nutzen oder kann es ggf. weitergehen? | Es kann ggf. weitergehen. Zum Zeitpunkt des RSA-Phasout (Abschaltung von RSA in der PKI) wird nur die PKI geändert. Ein PTV5 Konnektor könnte unter gewissen Voraussetzungen auch nach Phaseout funktionieren. Das hängt aber vom individuellen Setup/Situation der LEI ab (dualpersonalisiert? pairing der KTs) Das ist mit Risikoverbunden und wir raten davon ab. |
10 | Wenn ich PTV6 einspiele, kann ich dann ab dem Stichtag nur noch ECC machen? Verkürzt PTV6 diese Zeit (Stichtag)? | Man kann es so sehen, dass der PTV6 den SOG-IS Stichtag für PSe vorzieht. Hintergrund ist die Risikoreduzierung in Bezug auf die Verfügbarkeit. Ziel ist, nicht alle Aspekte der Nicht-Verwendung von RSA auf einen Schalter mit einem Mechanismus an einem festen Tag zu legen. |
9 | Ist PTV6 kostenpflichtig? | gematik regelt nicht die Kostenpflicht. TI-Pauschale gedeckt. |
8 | Müssen die PS Hersteller das PTV6 Update an die LE verteilen oder wird das Konnektor-intern erfolgen? | it depends... Wenn die LE die Auto-Update-Funktionalität des Konnektors nutzen (muss im Konnektor aktiviert sein, per default aktiv), dann holt sich der Konnektor automatisch das PTV6 Update, sobald es zugelassen und durch gematik freigegeben ist. ca. 2/2 der Konnektoren haben Autoupdate aktiviert Wenn Autoupdate deaktiviert ist, dann muss sich der Inhaber des Konnektors (oder dessen beauftragten Dienstleister) selbst darum kümmern, dass das PTV6 Update installiert wird. |
7 | Nur nochmal zur Sicherheit: Erst klang es so, als ob ECC nach wie vor optional ist. Die letzte Aussage klang aber doch danach, als ob sofern ECC Material vorhanden ist, ECC forciert wird und nur falls RSA-Only Material vorhanden ist, RSA weiter bis zum Stichtag verwendet werden kann. Vielleicht kann das hier nochmal jemand konkretisieren. | Mit PTV6 wird die ECC-Nutzung durchgesetzt (sofern möglich). D.h., wenn ECC Material vorhanden ist, dann wird dies forciert genutzt und nicht das vorhandene RSA Material. Daher muss:
|
6 | Zur Frage von Hr. Haas: Nach meinem Verständnis macht der PTV6 ausschließlich ECC, d.h. wird PTV6 bei einem Kunden eingespielt, MUSS das AVS ECC machen - sonst funktioniert das AVS nicht mehr! | Ein PTV6-Konnektor erzwingt bei Signaturerstellung die Nutzung von ECC-Kryptographie nur dann, wenn ECC-Schlüsselmaterial zur Verfügung steht. Der PTV6-Konnektor entscheidet selbst, unabhängig von übergebenen Parametern, ob er ECC oder RSA-Signatur erzeugt. Er kann natürlich nur dann sich für ECC entscheiden, wenn auch eine Karte zur Verfügung steht, die private ECC-Schlüssel enthält, also eine G2.1-Karte. Steht keine G2.1-Karte zur Verfügung, liefert der PTV6-Konnektor weiterhin RSA-Signaturen, er meldet nicht etwa einen Fehler. Das ist der grundlegende Unterschied zur Abschaltung von RSA, nach der definitiv keine RSA-basierten Artefakte mehr erzeugt werden. Für ein PS ist es daher bei der Signaturerzeugung mittels eines PTV6-Konnektors entscheidend, den Rückgabewert von SignDocument oder ExternalAuthenticate zu überprüfen, um zu erfahren, welchen Signatur zurück geliefert wurde, RSA oder ECC. Eine genaue Übersicht über die Unterschiede im Verhalten von PTV5- und PTV6-Konnekotren findet sich unter Übersicht des Verhaltens des PTV5- und PTV6-Konnektors (HSK PTV2) an der Clientsystemschnittstelle |
5 | Kommen die HSKs direkt mit PTV6 bzw. dessen API? | Die API für die PSe sind sind beim PTV2 HSK identisch zum EBK PTV6. Die derzeitigen HSKs im Feld sind PTV 1.x und haben noch EBK PTV5äquivalente Schnittstellen |
4 | "PSe sollten ihren Nutzern nahelegen....": ja, wirklich gerne! Aber wie kann man per einheitlicher oder jeweiliger Konnektor-Hersteller-Schnittstelle herausfinden, ob überhaupt Nur-RSA-Geräte/-Karten im Einsatz sind? | Sie können über ReadCertificate viele Zertifikate lesen und prüfen. Weiterhin steht CheckCertificateExpiration zur Verfügung, mit dessen Hilfe auch gSMC-K und gSMC-KT ermittelt werden können. |
3 | Wenn der PTV6 kommt und dieser entscheidet das er nur ECC macht welche Komponenten müssen dann alle ECC können? KIM-Clientmodul, PVS... | direkt: die PVSe indirekt: Auch die Zentralen Dienste, welche die Daten vom Konnektor über die PSe eingereicht bekommen |
2 | Dass ein Konnektor, der sich mit RSA-Identität identifiziert, keine VPN-Verbindung zur TI aufbauen werden können wird ist verstanden. Wird die Client-Verbindung zum Konnektor auf ECC-Zertifikat aus der TI geprüft, dass bestimmte Dienste dann nicht möglich sein werden? Wenn ja, welche? Hintergrund: Das Umstellen eines Client-Zertifikats ist bei unseren Kunden oft mit nicht-unerheblichem Aufwand verbunden und erfordert eine zu planende Unterbrechung der TI-Verfügbarkeit für mehr als nur eine handvoll Nutzer | Diese Frage wurde unter ECC-Testwoche: FAQs, Issues and Solving in Punkt 18 beantwortet. |
1 | Gibt es ne Seite mit den PTV 6 Breaking Changes? oder muss ich das selber aus den Spec /ILF rausfischen? | Zum 13.05.2025 finden sich die Änderungen von PTV6 gegenüber der letzten PTV5 in gemSpecPages unter Konn 24.1, Konn 25.1 und Draft CI 25.2. |
- No labels
3 Comments
Selcuk, Aliye
14.05.2025Ich bitte alle Fragestellende die Fragen direkt in die obige Tabelle unter "Fragen und Antworten" einzutragen. Das Handling über das Kommentarfeld könnte auf die Dauer schwierig sein. Vielen Dank für Ihr Verständnis.
Christian Riedl
14.05.2025Würden wir gerne, aber es fehlen die Rechte die Seite zu bearbeiten.
Selcuk, Aliye
19.05.2025Die Prüfung hat ergeben, dass die Anpassung der Rechte aufwändiger ist als von mir vermutet. Daher bitte ich Sie, Ihre Kommentare weiterhin im Kommentarfeld einzutragen, bis wir eine alternative Lösung gefunden haben.
Wir werden Ihre Fragen aus dem Kommentarfeld in die obige Tabelle übernehmen und anschließend löschen, um die Übersichtlichkeit der Fragen und Antworten zu gewährleisten.