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.
Vorgestellte Foliensätze
Foliensatz wurde am in der E-Rezept Sprechstunde vorgestellt.
Die Roadmap wurde am in der E-Rezept Sprechstunde vorgestellt.
Foliensatz wurde am in der E-Rezept Sprechstunde vorgestellt.
Roadmap zum Rollout PTV6 (Konnektor) und PTV2 (HSK)
Die Einboxkonnektoren liegen der gematik zur Zulassung vor. Für die KSR Verteilung der Konnektoren ist die Feldverfügbarkeit der Feature durch die Primärsysteme erforderlich.
Stand vom
FAQ
| Nummer | Datum | Fragen der Industrie | gematik | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 40 | |||||||||||||||||
| 39 | |||||||||||||||||
| 38 | |||||||||||||||||
| 37 | 22.09.2025 | Hinsichtlich der TLS-gesicherten Kommunikation zwischen Primärsystem und Konnektor: Was muss ich beachten, wenn ich manuell die verwendeten Zertifikate anpassen will? Hintergrund: Ein PTV5-Konnektor verwendet weiter sein konfiguriertes und in Verwendung befindliches RSA2048-Zertifikat nach dem Tag, wenn RSA im nonQES-Bereich abgeschaltet wird. Er verwendet es auch weiter nach einem PTV6-Update. Da aber die gematik darauf hinweist, dass gem. SOG-IS RSA2048-Verbindungen ab 2026 nicht mehr zulässig sind, möchte ich manuell ECC-Zertifikate (bzw. RSA3027) konfigurieren. | Im Konnektor können zwei generelle Typen von Zertifikaten konfiguriert werden:
Wenn Software-Zertifikate konfiguriert werden sollten, so gibt es die Möglichkeit NIST-basierte ECC-Zertifikate oder RSA3072-Zertifikate zu verwenden. Vorsicht ist allerdings geboten, wenn das ECC-Zertifikat der gSMC-K Verwendung finden soll. Dieses Zertifikat gibt es ausschließlich als brainpool-basiertes ECC-Zertifikat. Es gibt im Feld aber Clientsysteme, die brainpool-basierte ECC-Zertifikate nicht prüfen können. Die Anpassung des Konnektor-Zertifikats betrifft alle Clientsysteme, die mit dem Konnektor verbunden sind. Die gematik empfiehlt daher bei der manuellen Umstellung das NIST-basierte ECC-Software-Zertifikat zu verwenden. | ||||||||||||||
36 | 18.09.2025 | Hinsichtlich der TLS-gesicherten Kommunikation zwischen Primärsystem und Konnektor: Wie verhält sich ein Konnektor bzgl. seines Konnektorzertifikats zum einen nach dem Update auf PTV6 oder 2 (für HSK) und zum anderen ab 01.01.2026 bzw. nach dem Tag, wenn RSA tatsächlich im nonQES-Bereich abgeschaltet wird? Hintergrund: Die meisten Konnektoren nutzen aktuell ein RSA basiertes Zertifikat, um sich selbst auszuweisen. In vielen angeschlossenen Systemen ist dieses Zertifikat hinterlegt, um sicherzustellen, dass es sich in der Kommunikation wirklich um den bekannten Konnektor handelt. Falls der Konnektor sich jetzt zu einem bestimmten Zeitpunkt mit einem anderen Zertifikat ausweisen sollte, führte das zwangsläufig zu Einschränkungen in diesen Systemen, da diese neu konfiguriert werden müssten. | Ein PTV5-Konnektor verwendet weiter sein konfiguriertes und in Verwendung befindliches RSA2048-Zertifikat nach dem Tag, wenn RSA im nonQES-Bereich abgeschaltet wird. Ein Konnektor verwendet weiter sein konfiguriertes und in Verwendung befindliches RSA2048-Zertifikat nach dem PTV6-Update. Siehe dazu auch die Zeilen 32-35 dieser Tabelle. | ||||||||||||||
35 | 18.09.2025 | Hinsichtlich der TLS-gesicherten Kommunikation zwischen Primärsystem und Konnektor: Wie verhält sich ein Konnektor bzgl. der Clientzertifikate ab 01.01.2026 bzw. nach dem Tag, wenn RSA tatsächlich im nonQES-Bereich abgeschaltet wird? | Auf unserer für alle zugänglichen Seite Blick in die Praxis wird die Frage in der Zeile "Clientsystemauthentisierung zum Konnektor" und der Spalte "Beschreibung: Was zu tun bei nicht ECC-Fähigkeit" beantwortet: "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." Dies bedeutet, dass auch ein PTV5-Konnektor nach dem Tag, wenn RSA tatsächlich im nonQES-Bereich abgeschaltet wird (die Absicherung der Clientanbindung ist nonQES), die bereits konfigurierten und in Verwendung befindlichen RSA2048-Zertifikate weiterverwenden und akzeptieren wird. Dies resultiert daraus, dass eine Zertifikatsprüfung an der Clientschnittstelle im Abgleich des präsentierten Zertifikats mit dem für den Client im Konnektor hinterlegten Zertifikat besteht. Nichtsdestotrotz weist die gematik darauf hin, dass gem. SOG-IS solche Verbindungen ab 2026 nicht mehr zulässig sind. | ||||||||||||||
| 34 | 16.09.2025 | Hinsichtlich der TLS-gesicherten Kommunikation zwischen Primärsystem und Konnektor: Wie erhalten die Konnektoren die notwendigen Zertifikate mit NIST-Kurven? Ein Test-Konnektor (Secunet EBK) verwendet standardmäßig das ECC-Zertifikat der SMC-K mit Brainpool-Kurve. Kann und wird dieses Zertifikat irgendwie aktualisiert werden, so dass die NIST-Kurve zum Einsatz kommt? Oder muss hier im Konnektor ein Software-Zertifikat mit NIST-Kurve für die TLS-Kommunikation erstellt werden? Falls letzteres zutrifft: Werden alle PTV6/PTV2-Konnektoren die Möglichkeit anbieten, ein solches Software-Zertifikat zu erstellen? | Falls ein Konnektor ein Zertifikat der gSMC-K (kein Software-Server-Zertifikat) zum Absichern der Clientanbindung verwendet, so bleibt es auch bei diesem brainpool-basierten ECC-Zertifikat nach dem PTV6-Update. Die ECC-Zertifikate der gSMC-K sind immer brainpool-basiert und werden durch das PTV6-Update nicht durch NIST-basierte ECC-Zertifikate ersetzt. Es muss im Konnektor ein ECC-Software-Zertifikat basierend auf NIST-Kurve für die TLS-Kommunikation mit dem Client erstellt werden, falls die Verwendung eines solchen Zertifikats gewünscht ist. Wie [gemSpec_Kon#A_21811-04] zu entnehmen ist, werden alle PTV6/PTV2-Konnektoren die Möglichkeit anbieten, ein solches Software-Zertifikat zu erstellen. Siehe dazu auch Zeile 33 dieser Tabelle. | ||||||||||||||
| 33 | 16.09.2025 | Hinsichtlich der TLS-gesicherten Kommunikation zwischen Primärsystem und Konnektor: Ist [gemSpec_Kon#A_21811-04] so zu verstehen, dass KIS-Hersteller bei der TLS-Kommunikation zum TI-Konnektor davon ausgehen können, dass die TI-Konnektoren ECC mit NIST-Kurve anbieten (keine Brainpool-Kurven)? | [gemSpec_Kon#A_21811-04] fordert, dass ab PTV6 alle Konnektoren in der Lage sein müssen, ECC-Zertifikate basierend auf NIST-Kurven zu generieren und zu importieren. Auch das Generieren und Importieren von RSA3072-Zertifikaten wird mit der Anforderung ab PTV6 unterstützt. Diese Zertifikate können dann als Software-Server-Zertifikate oder als Client-Zertifikate verwendet werden. Die Konnektoren werden nach [gemSpec_Kon#A_21811-04] nicht automatisch ECC-Zertifikate anbieten. Dies muss - wenn gewünscht - manuell umgeschaltet werden. Siehe dazu auch Zeile 34 dieser Tabelle. | ||||||||||||||
| 32 | 16.09.2025 | Hinsichtlich der TLS-gesicherten Kommunikation zwischen Primärsystem und Konnektor: Ab wann ist hier zwingend ECC vorgeschrieben? Muss es nach [gemSpec_Kon#A_21811-04] nicht direkt zum 01.01.2026 erfolgen? | Auf unserer für alle zugänglichen Seite Blick in die Praxis wird die Frage in der Zeile "Clientsystemauthentisierung zum Konnektor" und der Spalte "Beschreibung: Was zu tun bei nicht ECC-Fähigkeit" beantwortet: "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 auch mit PTV6 weiterhin nutzbar sein. | ||||||||||||||
| 31 | Bestellung G2.0-Testkarten Ein Thema, welches ich auch noch nicht gesehen habe. Wir würden gerne etwas detaillierter nachtesten, wie sich das System verhält mit noch gültigen G2.0-Karten um sicher zu gehen, dass es hier keine Komplikationen gibt. | Seit letztem Jahr können keine G2.0 Testekarten mehr bestellt werden. Auf unserem Onlineshop können Sie die bestellbaren Testkarten finden: | |||||||||||||||
| 30 | Wo finde ich die Folien zum heutigen Workshop EBK PTV6/HSK PTV2? | Das Protokoll sowie den gezeigten Foliensatz ist auf dieser Seite zu finden: Protokoll - 250603_Workshop EBK PTV6/HSK PTV2 im Dialog mit Herstellern | |||||||||||||||
| 29 | Könnten Sie mich vielleicht noch auf die entsprechende Stelle verweisen, von der ich die Version 6.0.3 für die Nutzung in der RU beziehen kann? Ich war davon ausgegangen, dass es eine Tabelle mit der Liste aller Konnektoren geben wird mit den entsprechenden Links zu den Downloads. | zum offline upload bitte ich Sie sich direkt beim support des Herstellers unter support.ehealth@secunet.com zu melden, so dass Ihnen die Version bereitgestellt werden kann. | |||||||||||||||
| 28 | Im Workshop hatten, meines Wissens nach, alle Konnektoren-Hersteller zugesagt, dass entsprechende Prototypen der PTV-6 Firmware in Zulassung für die RU rechtzeitig zur Verfügung gestellt werden, damit wir PS-Hersteller sinnvoll testen können, bevor die Umstellung erfolgt. Bisher konnte ich noch keine solche Liste mit den entsprechenden PTV-6 Firmware Prototypen finden. Lediglich den Hinweis in der Vorbereitung auf die Q2-Testwoche. Die hier z.B. erwähnte SECUNET Firmware Version 5.70.6 entspricht allerdings nicht PTV-6. Könnten Sie hier evtl. klären, wo, wenn vorhanden, diese Aufstellung zu finden sein soll. Aus dem Workshop und den Sprechstunden habe ich mitgenommen, dass auch bei anderen PS-Herstellern das Bedürfnis herrscht möglich realitätsnah testen zu können bevor die eigentlich Umstellung erfolgt. | Aktuell hat die secunet ihren PTV6 Konnektor in der Version 6.0.3 in der RU zur Verfügung gestellt. Damit besteht jetzt schon die Möglichkeit Tests durchzuführen. Wie im E-Rezept Chat mitgeteilt liegt diese Version uns zur Zulassung vor und ist damit noch nicht für die PU zugelassen. Sobald weitere PTV6 Releases ready entwickelt sind werden diese in der RU bereitgestellt. In der V5.70.6 ist ua. das Feature ECC Registrierung enthalten. | |||||||||||||||
| 27 | Wie lässt sich die PTV-Version des Konnektors ermitteln? Am besten anhand des Discover-Dokuments. | "Blick in die Praxis" – Betroffene Komponenten in Leistungserbringerinstitutionen Die PTV des vorliegenden Konnektors kann via API über die Service Discovery aus der Datei connector.sds entnommen werden. Um an die Datei kommen muss ein HTTPS GET an die URL des Konnektors https://<konnektor_url>:<port>/connector.sds mit der gleichen Clientsystemauthentisierung wie an der SOAP Schnittstelle des Konnektor konfiguriert. In der XML-Struktur der connector.sds Datei kann die PTV dem Element
Dabei ist zusätzlich zu prüfen, ob es sich bei dem vorliegendem Konnektor um einen Einboxkonnektor (EBK) und nicht etwa um einen Highspeed-Konnektor (HSK) handelt. HSKs sind grundsätzlich nicht RSA-Only singlepersonalisiert und daher bezüglich der Geräteidentität immer ECC-fähig, sodass die weiteren Prüfschritte auf Personalisierung der gSM(C)-K für HSKs nicht durchgeführt werden müssen. Um den Konnektortyp (HSK oder EBK) zu ermitteln kann ebenfalls in der connector.sds im Element
| |||||||||||||||
| 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 über die dort vermerkte ObjectSystemVersion eingesehen werden. ECC fähig sind Karten ab folgenden Versionen*:
*: Hierbei entspricht die Produkttypversion der Objektsystemversion | |||||||||||||||
| 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
2 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.
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.