Diese Seite ist öffentlich und der Inhalt kann unter Angabe der Quell-URL dieser Seite gerne mit Partnern/Kunden geteilt oder an Dritte weitergegeben werden. 


Die Telematikinfrastruktur (TI) stellt ihre Kryptografie von RSA auf ECC (Elliptic Curve Cryptography) um. Dies erfolgt auf Empfehlung des BSI und der Europäischen eIDAS, da RSA-2048 nur noch befristet bis Ende 2025 zulässig ist. In einer Leistungserbringerinstitution sind dabei auch Komponenten betroffen. Im Folgenden wird für jede relevante Komponente dargestellt, ob ein Austausch oder Update nötig ist und wie der Ablauf gegebenfalls aussieht.

Allgemeine Liste der durchzuführenden Tätigkeiten

Komponente

Prüfung auf ECC-Fähigkeit

Wenn nicht ECC-fähig (G2.0) Was tun?
Institutionskennkarte (SMC-B)

– Im Konnektor‑Webinterface unter „Kartenverwaltung“ prüfen auf ECC‑Zertifikate

– Im Kartenportal Informationen einsehen

→ Neue SMC‑B G2.1 beantragen (Antrag → Ident)

Telematik-ID muss gleichbleiben (wichtig für KIM)! Folgekarte beantragen (KEINE neue Karte)

Heilberufsausweis (HBA)

Aufdruck Rückseite: „G2“ (kein ECC) – Medisign-Version: 3.20 (G2.0) vs. 10.21/02.22 (G2.1)

– Im Konnektor‑Webinterface unter „Kartenverwaltung“ prüfen auf ECC‑Zertifikate

→ Neuen eHBA G2.1 beantragen (Antrag → PIN/PUK)

Telematik-ID muss gleichbleiben (wichtig für KIM)! Folgekarte beantragen (KEINE neue Karte)

gSMC-KT (Terminalkarte)

– Im Konnektor‑Interface: nur RSA-Zertifikat sichtbar

– Direkt im stationären Terminal: Anzeige „AUT“ ohne „AUT2“

→ gSMC‑KT G2.1 bestellen, tauschen + neu koppeln
Kartenterminal (Firmware)Firmware-Version im Menü prüfen – Herstellerdoku auf ECC-Unterstützung prüfen→ Firmware-Update einspielen, erneut koppeln
KonnektorIm Konnektor‑Interface: Suche nach "gSMC‑K"Anzeige nur ein RSA‑Zertifikat = Karte ist G2.0 (RSA‑only).→ Umstieg auf TI-Gateway
PVS-/KIM-SoftwareVersionsdetail im PVS/KIM: braucht Support für ECC (PTV ≥ 1.6.2‑9)→ Update auf ECC-kompatible Softwareversion durchführen

Detaillierter Blick mit konkreteren Handlungsanweisungen

Komponente

Prüfung auf ECC-Fähigkeit

(manuell bzw. nicht standardisiert)

Prüfung auf ECC-Fähigkeit

(standardisiert)

Beschreibung: Was zu tun bei nicht ECC-Fähigkeit

Involvierte Rollen (wer es tun muss)

Hintergrund/Zusatzinfo

Institutionskennkarte/Praxisausweis (SMC-B)

Identifikation einer SMC-B G2.0 mit folgenden Optionen:

  • Konnektor-Managementoberfläche (Admin): Überprüfen Sie im Menüpunkt „Kartenverwaltung“ oder „Zertifikate“, ob ECC-Zertifikate vorhanden sind.
  • Kartenportal des Anbieters: Melden Sie sich im Portal Ihres Kartenanbieters an und prüfen Sie die Zertifikatsinformationen Ihrer Karten.
  • Kartentyp anhand des Aufdrucks: Überprüfen Sie den Aufdruck (falls vorhanden) auf der Karte:

    • G2: Nicht ECC-fähig. → neue SMC-B G2.1 beantragen

    • G2.1: ECC-fähig.


Für SMC-B, HBA und gSMC-KT lässt sich die ECC-Fähigkeit dieser gesteckten Karten nach folgendem Algorithmus über die SOAP-Schnittstelle des Konnektors ermitteln.

SchrittBeschreibung
Lasse die Infos aller in KTs gesteckten Karten ausgeben

Aufruf von GetCards(mandant-wide=true) → Response: Liste aller gesteckten Cards in den verbundenen KTs des Konnektors

NB: Sollen nicht alle gesteckten Karten geprüft werden, so ist dies entsprechend durch setzen der Aufrufparameter wie CtId, SlotId oder CardType von GetCards anzupassen.

Prüfe jede Karte auf ihre ECC-Fähigkeit

Für jede Card aus Cards:

Prüfe, ob Card.CardVersion.ObjectSystemVersion >= 4.4.0 ist (Dabei sind die durch Punkt separierten Stellen der Version in die Objekte Major, Minor und Revision aufgeteilt). Wenn ja, dann ist die Karte Card ECC-fähig.

NB: sobald man Card extrahiert hat kann man daraus auch gleich weitere für den Nutzer ggf. nützliche Information extrahieren. Z.B. könnte man, falls zutreffend, ausgeben, dass eine Karte vom Typ Card.CardType mit ICCSN Card.Iccsn nicht ECC-fähig ist und ausgetauscht werden muss.

 

Neue SMC-B G2.1 als Folgekarte beantragen

  • Antragsportal: Neue SMC-B (G2.1) beantragen, falls noch keine Kontaktaufnahme von Kartenherausgeber erfolgt ist.
    • Identitätsprüfung durchführen (Nur bei neuer Karte mit voller Laufzeit! Nicht bei Ersatzkarte)

Hinweis: Bei Kartentausch oder Anbieterwechsel die TelematikID beibehalten, um betrieblichen Problemen vorzubeugen.

Nach erfolgreicher Prüfung durch die KV erfolgt der Versand der Karte und des Transport-PINs und die Inbetriebnahme kann erfolgen:

  • Freischaltung der Karte im Antragsportal
  • Stecken der Karte in das Kartenterminal und Aktivierung der Karte mittels Transport-PIN und Vergabe eines neuen PINs über das Praxisverwaltunsgsystem
  • Funktionstest inkl. Überprüfung der TI-Verbindung

 

Praxisinhaber (Beantragung)

ggfs. DVO oder Admin (Einrichtung)

KV/Kammer (Genehmigung)

ECC erforderlich: Ältere SMC-B (G2.0, nur RSA) sind zukünftig nicht nutzbar.

Zeit: spätestens September 2025 (3 Monate vor Ablauf) neue SMC-B G2.1 beantragen, falls noch keine Kontaktaufnahme vom Anbieter erfolgt ist, da Postlaufzeit + Freischaltung nötig. 

Telematik-ID muss gleichbleiben (wichtig für KIM)! Folgekarte beantragen (KEINE neue Karte)

Heilberufsausweis (HBA)

Identifikation einer HBA G2.0 mit folgenden Optionen:

  • Konnektor-Managementoberfläche (Admin): Überprüfen Sie im Menüpunkt „Kartenverwaltung“ oder „Zertifikate“, ob ECC-Zertifikate vorhanden sind.
  • Kartentyp anhand des Aufdrucks (falls vorhanden): Überprüfen Sie auf der Kartenrückseite:

    • G2: Nicht ECC-fähig. → neuen HBA G2.1 beantragen

    • G2.1: ECC-fähig.

  • Medisign: Versionsnummer auf der Kartenrückseite

    • G2.0: Die Versionsnummer lautet 3.20 → neuen HBA G2.1 beantragen

    • G2.1: Die Versionsnummer lautet 10.21 oder 02.22.

  • Medisign: Chip-Design

    • G2.0: Der Chip ist quadratisch und verfügt über 20 Kontaktflächen. → neuen HBA G2.1 beantragen

    • G2.1: Der Chip ist rechteckig und hat nur 7 Kontaktflächen.

  • Kartenportal des Anbieters: Melden Sie sich im Portal Ihres Kartenanbieters an und prüfen Sie die Zertifikatsinformationen Ihrer Karten.


Neuen eHBA G2.1 als Folgekarte beantragen

  • Antragsportal: Neuen HBA (G2.1) beantragen, falls noch keine Kontaktaufnahme von Kartenherausgeber erfolgt ist.
    • Identitätsprüfung durchführen (Nur bei neuer Karte mit voller Laufzeit! Nicht bei Ersatzkarte)

Hinweis: Bei Kartentausch oder Anbieterwechsel die TelematikID beibehalten, um betrieblichen Problemen vorzubeugen.

Nach erfolgreicher Prüfung erfolgt die Lieferung mit PIN/PUK-Brief. Leistungserbringer ändert PIN (nonQES+QES) und nutzt neue Karte im Terminal. Alte HBA ggf. bis Ablauf parallel nutzbar, dann sperren/vernichten. 

  • Freischaltung der Karte im Antragsportal mittels Freischaltcode aus PIN-Brief
  • Stecken der Karte in das Kartenterminal und Aktivierung der Karte mittels Transport-PINs (PIN.CH für die Karte und PIN.QES für die qualifizierte elektronische Signatur) in persönliche PINs. Dies erfolgt in der Regel über das Praxisverwaltungssystem oder mit einem Tool des Vertrauensdiensteanbieters.
    • Neuer PIN für PIN.CH
    • Neuer PIN für PIN.QES
  • Funktionstest (z.B. signieren eines E-Rezeptes)


 

Jeweiliger Karteninhaberin (Arzt/Zahnarzt/Apotheker) selbst;

Kammer/Anbieter stellt aus.

ECC erforderlich: Ältere HBAs der Generation G2.0 ohne ECC funktionieren für neue TI-Funktionen nicht. 

Zeit: spätestens September 2025 (3 Monate vor Ablauf) neuen HBA G2.1 beantragen, falls noch keine Kontaktaufnahme vom Anbieter erfolgt ist, da Postlaufzeit + Freischaltung nötig.  Ohne gültigen HBA kein E-Rezept / ePA-Zugriff möglich.

Telematik-ID muss gleichbleiben (wichtig für KIM)! Folgekarte beantragen (KEINE neue Karte)

gSMC-KT

Identifikation einer gSMC-KT G2.0 mit folgenden Optionen:

Über den Konnektor je nach Hersteller:

  • Navigiere zu „Praxis → Karten“ oder Kartenmanagement in der Admin-Oberfläche
  • Suche nach der gSMC-KT der Terminal-Komponente.

Direkt am Kartenterminal je nach Hersteller:

  • Im Web‑Interface: Menü „Info → gSMC‑KT“ anzeigen – zeigt es nur RSA oder auch EC (ECC)? Fehlt EC, ist es G2.0 → Karte tauschen

  • Im Terminal‑Menü: → Service → Test → Einzeltest → Slot 3 (oder 4):

    • Anzeige „AUT“ + „AUT2“ → G2.1

    • Nur „AUT“ ohne „AUT2“ → G2.0 (RSA-only) → Karte tauschen 

    • Bei bestimmten Modellen, wie dem CHERRY ST1506, navigieren Sie zu:
      Menü → Einstellungen → Status → gSMC-KT Informationen
      Dort können Sie Details zu den Zertifikaten einsehen.

Neue gSMC-KT G2.1

Terminal selbst bleibt, nur die Sicherheitskarte tauschen.

  • Neue gSMC-KT beim Hersteller für jedes betroffene Kartenterminal bestellen.

Sobald neue Karte für jedes Kartenterminal vorhanden ist:

  • Siegel und alte Karte entfernen
  • Neue Karte am Terminal einstecken und neues Siegel (Aufkleber) aufbringen
  • Anschließend Terminal im Konnektor neu koppeln (Admin-Oberfläche), damit TLS-Verbindung mit neuem Zertifikat aufgebaut wird. Terminal meldet danach wieder eGK-Lesebereitschaft.

Praxis-Admin/IT kann Tausch selbst vornehmen (laut Anleitung);

alternativ DVO beim Praxisbesuch.

ECC erforderlich: G2.0-Karten (RSA) sollten gegen G2.1 ersetzt werden, da sonst keine ausreichend sichere Verbindung mehr zum Konnektor besteht.

Nach physischem Tausch, Admin-Passwörter für Kopplung nötig.

Primärsystem

Prüfung auf ggf. notwendiges Software-Update des Primärsystems durch Prüfung der letzten Release-Notes, Mitteilung des Herstellers oder durch Kontaktaufnahme zum Hersteller

  • keine universelle API vorhanden
  • Die einzelnen PS-Hersteller sollten bei Bedarf für die Bereitstellung eine Algorithmus/Proprietary-API zur Ermittlung, ob eine vorliegende PS-Version ECC-Fähig ist oder nicht kontaktiert werden.
  • Als "Best Practise" empfiehlt die gematik, dass die Hersteller ihre Algorithmus/Proprietary-APIs an die gematik melden, sodass diese hier  zentral zugänglich gemacht werden können.

Primärsystem auf aktuelle ECC-fähige Version bringen

  • Update via Autoupdate oder Installer durchführen. Individuelle Herstellervorgaben einhalten.
  • Funktionstests (VSDM, KIM-Mail, eRezept) durchführen.
Praxis-IT/Administrator oder PVS-Hersteller-Support (Remote)Aktualität: Das PVS muss kompatibel sein vor der Aktualisierung des Konnektors auf PTV6  – sonst Ausfall von TI-Funktionen. Herstellerinfos beachten zu TI-Updates (meist in Release Notes).
KIM-Clientmodul

Überprüfung der installierten KIM-Clientmodulversion

Ältere KIM-Versionen (KIM1.0 bis KIM 1.5.2-8 - für das CM ist das PTV 1.2.2 bis PTV 1.6.2-8) versagen bei ECC.

Es ist unbedingt das Update auf KIM 1.5.2-9 (CM PTV >= 1.6.2-9) einzuspielen. Ab Datum   haben alle KIM-CM Hersteller ein CM mit KIM 1.5.2-9 zum Update/Download bereitgestellt. Unmittelbar nach dem Datum muss KIM-CM aktualisiert werden, unabhängig davon, welche Version das vorhandene KIM-CM trägt.

 

  • nicht via API möglich
  • Anstatt der Prüfung wird empfohlen, ab  das CM-Update auszulösen und sicherzustellen, dass dieses erfolgreich durchläuft. Dann kann von ECC-Fähigkeit beim KIM-CM ausgegangen werden.


NB:

  • Ab Datum   haben alle KIM-CM Hersteller ein CM mit KIM 1.5.2-9 zum Update/Download bereitgestellt.

KIM-Software updaten auf ECC-fähige Version. 

  • Update durchführen - Integriert im PVS: kommt per PS-Update;  extern: neuen Client installieren
  • Test: E-Mail Versand/Empfang

Wichtig: Direkt vor dem Tausch G2.0- zu G2.1-SMC-B oder HBA und damit vor dem Wechsel der Zertifikate müssen KIM-Nachrichten abgerufen werden. Sonst droht nach dem Wechsel der Verlust älterer, noch nicht abgerufener KIM-Nachrichten. 

Hinweise: 

  • Clientzertifikat vom Modul zum KIM-Fachdienst: Wird automatisch ab KIM 1.5.2.-9 (CM PTV 1.6.2-9) vom Clientmodul vom Fachdienst bezogen und muss nicht manuell bezogen und eingebracht werden 
  • Clientzertifikat vom Modul zum Konnektor: Zertifikat auf ECC durch DVO umstellen.
Praxis-Admin/IT oder DVO; in Abstimmung mit PVS-Hersteller und KIM-Dienstanbieter.

Kompatibilität: Ältere KIM-Versionen (KIM1.0 bis KIM 1.5.2-8 - für das CM ist das PTV 1.2.2 bis PTV 1.6.2-8) versagen bei ECC. Es ist unbedingt das Update auf KIM 1.5.2-9 (CM PTV >= 1.6.2-9) einzuspielen. 

Timing: Update ist vor 2026 durchzuführen, da sonst KIM-Ausfall.

Aktualität: Das KIM-CM muss auf KIM 1.5.2-9 (CM PTV >= 1.6.2-9) aktualisiert werden bevor der Konnektors auf PTV6 aktualisiert wird – sonst Ausfall von TI-Funktionen. 

KIM-Adresse an SMC-B gebunden – bei Kartentausch Mails vorher abrufen und neue Karte bei KIM anmelden.

KIM-Adresse an HBA gebunden – bei Kartentausch Mails vorher abrufen und neue Karte bei KIM anmelden.

Telematik-ID muss gleichbleiben! Folgekarte beantragen (KEINE neue Karte)

Konnektor



Erkennen eines RSA‑only Konnektors

Suche nach "gSMC‑K" in der Admin-Oberfläche des Konnektors

  • Anzeige nur ein RSA‑Zertifikat = Karte ist G2.0 (RSA‑only).

    • → Austausch gegen TI-Gateway





Der Zugriff auf Informationen der gSMC-K des Konnektors über die Außenschnittstelle des Konnektors ist limitiert und variiert leicht zwischen PTV5 und PTV6.

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 ProductInformation.ProductTypeInformation.ProductTypeVersion entnommen werden.


ProductVendorIDPTV6 ab ProductTypeVersion
KOCOC6.0.0
SECUN6.0.0
RISEG5.61.0


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 ProductInformation.ProductIdentification.ProductCode wie folgt geprüft werden:

KonnektortypMögliche Werte aus ProductCode
HSK[RHSK, secu_hsk, IK, kocohsk]
EBK[kocobox, RKONN, secu_kon]




Für EBK PTV <6:

Schritt

Beschreibung

Ermittle das Ablaufdatum der RSA-Zertifikate der gSMC-K

Aufruf von CheckCertifikateExpiration(crypt=RSA).

(warning) der Aufrufparameter crypt=RSA muss hier zwingend übergeben werden.

Dann extrahiere das Ablaufdatum connector_expirydate aus der Response, indem über die zurückgegebene Liste der Response iteriert wird, bis ein Eintrag CertificateExpiration gefunden wurde, für den gilt, dass die Elemente CertificateExpiration.CtId und CertificateExpiration.CardHandle leer sind. Das ist dann der Eintrag für die gSMC-K.

Ermittle die ECC-Fähigkeit mittels Ablaufdatum

Erkenne die ECC-Fähigkeit der des Konnektors (bzw. dessen gSMC-K) am Wert von connector_expirydate wie folgt:

  • genau 31.12.2025: singlepersonalisiert → nicht ECC-Fähig
  • bis 24.08.2025: singlepersonalisiert → nicht ECC-fähig
  • zwischen 25.08.2025 und 30.12.2025: dualpersonalisiert → ECC-fähig
  • ab 2026: dualpersonalisiert → ECC-fähig


Für EBK PTV >=6:

Gehe äquivalent zu "Für PTV <6" vor, jedoch rufe CheckCertificateExpiration ohne Angabe des crypt Parameters auf.


  

Zusatzinfo ggf. zum Verständnis des vorgestellten Algorithmus:

  • die gSMC-K besitzt keine Objektsystemversion. Daher kann hier nicht analog zu HBA, SMC-B, gSMC-KT vorgegangen werden
  • alle durch Laufzeitverlängerung bereits verlängerten singlepersonalisierten Konnektoren laufen genau zum 31.12.2025 aus
  • unverlängerte singlepersonalisierte Konnektoren laufen bis Oktober 2025 aus
  • sowohl RSA- als auch ECC- Zertifikate einer gSMC-K haben das gleiche Ablaufdatum (Differenzen lediglich im Sekunden/Minuten Bereich)

 

Austausch gegen TI-Gateway/Highspeed-Konnekor

Anbieter auswählen

  • Zugelassenen TI-Gateway-Anbieter auswählen und Vertrag abschließen

  • Bestehende Konnektor- und KIM-Verträge prüfen und ggf. kündigen unter Berücksichtigung von Fristen

Installation Vor-Ort:

  • Installation des TI-Clients und Einrichtung der Verbindung

  • Migration der Konfigurationen: Um zu vermeiden, dass der neue Konnektor nicht von Grund auf neu konfiguriert werden muss, ist hierbei die Migration der Konfigurationen (Aufrufkontext, Einstellungen, Clientzertifikate, etc.) nötig. 
    • Alternativ: Neueinrichtung
  • Funktionstest durchführen (z.B.: Versichertenstammdaten, KIM, eAU/E-Rezept, ePA)
  • Alten Konnektor zurücksenden oder ordnungsgemäße Entsorgung

DVO/IT-Dienstleister für Installation

Praxis stellt SMC-B + Credentials bereit.

Frist: Die RSA-Only Konnektoren verfügen über kein ECC-Schlüsselmaterial auf der gSMC-K. Nach Ende 2025 wird RSA-basierter Betrieb nicht mehr erlaubt – ohne gültiges Zertifikat funktioniert der TI-Zugang nicht mehr

Die Nutzung eines HSK als Ersatz via TI-Gateway (gehosteter Konnektor) ist möglich seit 2024. 

Erkennen eines dual-personalisierten RSA+ECC Konnektors

Suche nach "gSMC‑K" in der Admin-Oberfläche des Konnektors

  • Anzeige RSA + ECC‑Zertifikate = Karte ist G2.1 (ECC‑fähig)

      • → ggfs. Laufzeitverlängerung durchführen

 

Laufzeitverlängerung mit PTV6

  • Die ECC-Zertifikate eines solchen Konnektors müssten vor dem Ablauf der Laufzeit der gSMC-K-Zertifikate laufzeitverlängert werden. Der Konnektor benötigt dazu jedoch das LZV2 Feature, damit er seine ECC-Laufzeitverlängerung erneut durchführen kann. Bei RISE ist PTV6 die Voraussetzung, um LZV2 Feature durchzuführen.

Umstieg auf TI-Gateway

  • Da nach derzeitigem Plan PTV6 jedoch erst im Q4 2025 im Feld zur Verfügung steht, wird ein Umstieg auf HSK oder TI-Gateway empfohlen. (Siehe "Austausch gegen TI-Gateway")



DVO/IT-Dienstleister für Installation

Praxis stellt SMC-B + Credentials bereit.

Frist: Die Laufzeitverlängerung bzw. der Umstieg auf ein TI-GW/HSK müssen bis zum Ablaufdatum des Konnektors vollzogen sein.

LZV2 kostenpflichtig: Es wird eine Laufzeitverlängerung Stufe 2 (LZV2) für dualpersonalisierte Konnektoren geben. Um die LZV2 nutzen zu können ist voraussichtlich ein kostenpflichtiges Update beim Anbieter notwendig. Es wird der Umstieg auf ein HSK/TI-Gateway empfohlen.

Clientsystemauthentisierung zum Konnektor

Prüfen, welche Client-Zertifikate (KIM-Modul, PS, Authenticator) verwendet werden in der Admin-Oberfläche des Konnektors (Alternativ: Konnektorlogs, oder Konnektorevent "EC_TLS_Client_Certificate_Security")


  • Wenn in der Clientsystemauthentisierung RSA-2048 oder BASIC-AUTH genutzt wird, dann sollte diese gegen ein Authentisierungsmittel mit >120 Bit Sicherheitsniveau ersetzt werden.

  • nicht via API möglich
  • nur durch Untersuchung des Transportprotokolls bestehender Verbindungen möglich


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.

Nichtsdestotrotz weist die gematik darauf hin, dass gem. SOG-IS solche Verbindungen ab 2026 nicht mehr zulässig sind.

Ersetze Clientsystemauthentisierung

  • Einloggen in der Admin-Oberfläche des Konnektors und nach Clientsystemauthentisierung suchen
  • Für bestehende Clientsysteme neue Client-Zertifikate generieren
    • ECC-NIST (empfohlen), ECC-Brainpool des AK.AUT der gSMC-K oder RSA3072
  • Neues Zertifikat im Clientsystem hinterlegen (Primärsystem, KIM-Modul, Authenticator)
  • Funktionstest durchführen (Verbindung zum Konnektor)

Praxis-IT/Administrator oder PVS-Hersteller-Support (Remote), DVO

Hinweis: Die neue Generation der Konnektoren unterstützt auch nach einem Update weiterhin RSA-2048 zur Clientauthentisierung auch in 2026. Ein Umstieg auf ECC_NIST wird empfohlen.

Registrierung am VPN-Zugangsdienst mit ECC

  • In der Admin-Oberfläche des Konnektors kann der aktuelle Registrierungsstatus am VPN-Zugangsdienst überprüft werden.
  • Sollte dieser anzeigen, dass die derzeitige Registrierung auf dem RSA basiert, so muss
    • dafür gesorgt werden, dass sich bereits eine G2.1 SMC-B im Einsatz befindet (siehe oben in dieser Tabelle)
    • eine Re-Registrierung mit dem ECC durchgeführt werden.
  •  < PTV6: nicht via API möglich
  • Ab PTV6:
    Prüfung auf aktiven Betriebszustand EC_VPN_Registration_ECC_Pending via GetResourceInformation()

Re-Registrierung mit ECC

  • Einloggen in der Admin-Oberfläche des Konnektors
  • GGfs. Konnektor Firmware aktualisieren (ECC-ready)

  • SMC-B G2.1 einsetzen (falls nicht bereits erfolgt, siehe oben in dieser Tabelle)
  • ECC-VPN-Registrierung mit ECC-Zertifikat der SMC-B G2.1 

  • VPN-Verbindung neu aufbauen & Funktionstest durchführen 

  • Nach erfolgreichen Funktionstest kann die Alte RSA-Registrierung entfernt werden (optional)

Praxis-IT/Administrator oder PVS-Hersteller-Support (Remote) oder DVO

Hinweis: Mit der zukünftigen Konnektorgeneration PTV6 (verfügbar ab Q4/25 bzw. Q1/26) wird sich dieser automatisch mit ECC Re-Registrieren. Aktuell wird empfohlen den bisherigen PTV5-Konnektor manuell auf ECC zu registrieren (falls nicht bereits erfolgt).



eHealth-Kartenterminal 

Versionsupdate prüfen

Firmware der Kartenterminals auf Update prüfen und ggf. FW/TSL updaten

Für die am Konnektor verbundenen KTs lässt sich die ECC-Fähigkeit der KT-Firmware nach folgendem Algorithmus über die SOAP-Schnittstelle des Konnektors ermitteln. 

SchrittBeschreibung
Lasse die Infos aller in KTs ausgeben

Aufruf von GetCardTerminals(mandant-wide=true) → Response: Liste aller verbundenen KTs des Konnektors.

Prüfe jedes KT auf eine ECC-fähige FW-Version

Für jedes CardTerminal aus CardTerminals der Response:

Prüfe, ob CardTerminal.ProductInformation.FwVersion >= der Version aus dieser Tabelle ist. Falls die FW Version kleiner ist, dann ist die KT-FW noch nicht ECC-fähig und muss geupdatet werden.:

Hersteller/KT-ProduktlinieProductVendorIDKT-FW
Ingenico OrgaINGHC3.9.1
Cherry STDECHY4.0.47
GT900GERTE2.1.1



Firmware Update einspielen

Falls die installierte Firmwareversion kleiner sein sollte, muss entweder ein Firmwareupdate durchgeführte werden oder zumindest die aktuelle von den jeweiligen Kartenherstellern zu Verfügung gestellte KT-TSL geladen werden (dazu die Hersteller kontaktieren).

Praxis-IT/Administrator oder PVS-Hersteller-Support (Remote)oder DVO


Wir freuen uns über Rückmeldungen, Hinweise oder Feedback, um die Übersicht weiter zu verbessern und den Nutzen für alle Beteiligten zu maximieren.

backhand index pointing right Nutzen Sie hierfür gerne unser Service-Portal: https://service.gematik.de/servicedesk/customer/portal/22

  • No labels

8 Comments

  1. Benjamin Kim

    Die Idee dieser Übersicht ist super, aber die Primärsystemhersteller brauchen für die Spalte "Prüfung auf ECC-Fähigkeit" Aussagen/Vorgehensbeschreibungen auf API-Ebene. Es ist den Leistungserbringenden nicht zuzumuten, sich durch die Web-Oberflächen der Komponenten durchzuklicken (von denen sie die Zugangsdaten häufig nicht parat haben) oder Karten rauszuziehen und sich anzuschauen, ob da etwas aufgedruckt ist. Die Primärsysteme müssen dazu in die Lage gebracht werden, diese Informationen automatisch, im Hintergrund, abzufragen.

  2. Peter Schüller

    In der o. g. Tabelle zum Konnektor reichen die Angaben m. E. nicht aus für den PTV6-Test. Es fehlt die Info, wie man einen Einbox-Konnektor von einem HSK unterscheiden kann (weil letzterer ja, leider, die ProductTypeVersion 2.0.0 haben wird).

    1. Münz, Erik

      Danke für den Hinweis. Wir haben eine Beschreibung hinzugefügt, wie man erkennen kann ob ein EBK/HSK vorliegt. 

  3. Ralf Großhans

    Sinnvoller wäre es, dass der HSK die gleiche Versionsnr. erhält wie ein Einbox Konnektor. Das ist doch nur ein Zahlenwert (String) den die HSK Anbieter ändern müssten.  Diese zwei Nr.-Kreise für das selbe schafft nur Verwirrung und Probleme.

    1. Münz, Erik

      Das ist bereits so umgesetzt. Für HSK wird in ProductInformation.ProductTypeInformation.ProductTypeVersion nicht die HSK PTV berichtet, sondern das EBK-Äquivalent.

      1. Ralf Großhans

        Ihre Aussage verstehe ich nicht. der HSK sagt doch 2.0.0. Diese Version war aber im EBK schon vor Jahren verbrannt.

  4. Ralf Großhans

    ich sehe dort 

    2.0.0-06.0.0-0

    ich würde aber erwarten dass man einfach in der ersten Spalte auch 6.0.0-0 schreibt und alle Verwirrung ist erledigt.