Diese Seite richtet sich speziell an Primärsystemhersteller und bietet eine ergänzende Hilfestellung, um den Umstieg auf ECC effizient und reibungslos zu gestalten.
Der Fokus liegt hier auf den Usecases rund um ePA. Weitere Anwendungsfälle werden schrittweise ergänzt, um eine praxisnahe und kontinuierlich wachsende Unterstützung zu gewährleisten.
Alle hier bereitgestellten Inhalte basieren auf den offiziellen Spezifikationen, Implementierungsleitfäden und Dokumentationen der gematik. Diese Seite dient als zusätzliche Orientierungshilfe: Sie stellt konkrete Umstellungen dar, zeigt technische Zusammenhänge auf, bündelt relevante Informationen und erleichtert so die Implementierung im Primärsystem.
Relevante Anwendungsfälle mit Hinweisen zur Umstellung sind zusätzlich hier zu finden: "Test Scope zum Nachweis der ECC-Fähigkeit"
Inhalt:
Aktuell können die Primärsysteme sowohl RSA als auch ECC (Elliptic Curve Cryptography) Algorithmen nutzen u.a.:
Die Erläuterungen für diese Zusammenfassung finden Sie in den folgenden Abschnitten dieser Seite.
Ab dem 01.01.2026 darf das Verfahren RSA-2048 nicht mehr verwendet werden (eine Vorgabe der Bundesnetzagentur und des BSI).
Sollte der Umstieg auf ECC-Signaturen bis dahin nicht vollständig abgeschlossen sein, bedeutet das in der Praxis:
Voraussetzung für eine erfolgreiche Umstellung:
Das bedeutet:
Die Umstellung auf ECC liegt primär in der Verantwortung der Primärsysteme. Diese müssen sicherstellen, dass bei Nutzung von G2.1-HBAs die Signaturprozesse vollständig auf ECC umgestellt sind.
Achtung: PTV6-Konnektoren sind keine zwingende Voraussetzung für die ECC-Migration.
Ab der zweiten Jahreshälfte 2025 beginnt voraussichtlich der Rollout von:
Diese Konnektoren erzwingen die Verwendung von ECC, wenn G2.1-Karten vorhanden sind – unabhängig davon, ob das Primärsystem weiterhin versucht, RSA zu verwenden.
Folgen:
Der PTV6-Konnektor ignoriert den RSA-Wunsch des Primärsystems, d.h. bei unvollständiger ECC-Implementierung im Primärsystem kann es zu Fehlern kommen.
Für weitere detaillierte Informationen zur Änderung des Verhaltens zwischen PTV5 und PTV6 an den relevanten Schnittstellen wird empfohlen, die Seite Übersicht des Verhaltens des PTV5- und PTV6-Konnektors (HSK PTV2) an der Clientsystemschnittstelle zu besuchen.
Besonderheit: G2.0-HBAs im Übergangszeitraum bis diese vollständig durch G2.1 im Feld ersetzt wurden:
Bis Ende 2025 werden noch G2.0-HBAs und G2.0 SMC-Bs im Feld sein, welche kein ECC unterstützen. Beide Kartentypen werden bis Ende 2025 im Feld mit der Generation G2.1 ausgetauscht.
→ Die Primärsysteme müssen daher bis Jahresende beide Signaturverfahren (RSA & ECC) parallel unterstützen, abhängig von eingesetzter Kartengeneration.
Im Folgenden werden die relevanten ePA Anwendungsfälle und den Anpassungsbedarf seitens der Primärsysteme für die robuste ECC-basierte Nutzung dargestellt. Dazu werden jeweils die wichtigsten Aspekte der Ausgangssituation dargestellt. Darauf aufbauend wird dann jeweils der Anpassungsbedarf in einem Detailgrad dargestellt. Alle aufgeführten Operationen stehen in Abhängigkeit zur Kartengeneration der verwendeten SMC-B. Da bis Ende 2025 noch SMC-B der Generation G2.0 genutzt werden, muss das PS vorab prüfen, welche Generation vorliegt. Dies geschieht mit der EventService::GetCards-Operation am Konnektor.
Im Rückgabewert von EventService::GetCards muss die Produkttypversion des Objektsystems der SMC-B Karte ausgelesen werden. Diese ist aus der Response zu entnehmen: CARD:Cards/CARD:Card/CARD:CardVersion/CARD:ObjectSystemVersion
Darauf basierend kann aus der ObjectSystemVersion nach folgender Tabelle bestimmt werden, welche Kartengeneration diese SMC-B Karte besitzt:
| < 4.4.0 | G2.0 Karte |
| >= 4.4.0 | G2.1 Karte |
Nachfolgend wird das weitere Vorgehen für die ECC-fähigen G2.1-Karten beschrieben:
A_20666-02 - Auslesen des Authentisierungszertifikates:
Das Primärsystem MUSS das Zertifikat C.HCI.AUT der SM-B über die Operation ReadCardCertificate des Konnektors gemäß [gemSpec_Kon#4.1.9.5.2] bzw. [gemILF_PS#4.4.4.2] auslesen.
Hierbei ist darauf zu achten, dass wie in A_25720-01 - Auslesen des Authentisierungszertifikates aus einem HSM beschrieben, das bei der Signatur bevorzugt zu verwendende ECC-Zertifikat gelesen wird. Dafür muss bei der Operation ReadCardCertificate (oder aber im Falle des CS (Clientsystem) des KTR (Kostenträger) bei der Operation ReadCertificate) der Defaultwert Crypt auf "ECC" gesetzt werden. Nur bei einer Karte der Generation G2.0 kann der Defaultwert Crypt "RSA" genutzt werden (siehe TIP1-A_4700-03).
A_24882-01 - Signatur clientAttest:
Das Primärsystem MUSS zum Signieren des clientAttest-JWT mit der SMC-B die Konnektorschnittstelle AuthSignatureService::ExternalAuthenticate nutzen gemäß [gemSpec_Kon] und als zu signierende Daten den BinaryString den SHA-256-Hashwert des clientAttest-JWT in Base64-Codierung übergeben.
Um sicherzustellen, dass per ECC signiert wird, muss das Primärsystem, wie in A_24883-02 - clientAttest als ECDSA-Signatur beschrieben, beim Signieren des clientAttest-JWT mit Operation ExternalAuthenticate den Signatur-Typ ECDSA-Signatur verwenden. Dazu MUSS im Element dss:SignatureType die URI urn:bsi:tr:03111:ecdsa übergeben werden.
Hierbei ist darauf zu achten, dass wie in A_26818 - Formatkonvertierung bei ECDSA basierter clientAttest-Signatur beschrieben, nach erfolgter Signatur der Signatur-Typ ermittelt wird, indem aus der Response das XML-Attribut dss:SignatureObject/dss:Base64Signature/@Type ausgewertet wird.
Ist der Wert des Signatur-Typ urn:bsi:tr:03111:ecdsa, so wurde durch ExternalAuthenticate eine ECDSA-Signatur erstellt und das XML-Attribut dss:SignatureObject/dss:Base64Signature aus der Response MUSS vom PS vor weiterer Verwendung als signiertes clientAttest-JWT vom X9.62 Format gem. [BSI-TR-03111 ]#5.2.2 in das für ECDSA-Signaturen benötigte Concatenated-Format gem. [RFC 7518]#3.4 konvertiert werden. Links zu Beispielen sind in der AFO hinterlegt.
A_20665-01 - Signatur der Challenge des IdP-Dienstes:
Das Primärsystem MUSS für das Signieren des CHALLENGE_TOKEN des IdP-Dienstes mit der Identität ID.HCI.AUT der SM-B die Operation AuthSignatureService::ExternalAuthenticate des Konnektors gemäß [gemSpec_Kon#4.1.13.4] bzw. [gemILF_PS#4.4.6.1] verwenden und als zu signierende Daten BinaryString den SHA-256-Hashwert des CHALLENGE_TOKEN in Base64-Codierung übergeben.
Um sicherzustellen, dass per ECC signiert wird, muss das Primärsystem, wie in A_24751 - Challenge signieren als ECDSA-Signatur beschrieben, beim Signieren der Challenge mit Operation ExternalAuthenticate den Signatur-Typ ECDSA-Signatur verwenden. Dazu MUSS im Element dss:SignatureType die URI urn:bsi:tr:03111:ecdsa übergeben werden.
Auch hier muss wie im Abschnitt zum clientAttest beschrieben eine Formatkonvertierung zu Concatenated-Format gem. [RFC 7518]#3.4 gemacht werden.
Anschließend werden die signierte "challenge" und das verwendete Authentisierungszertifikat (ECC) der Smartcard an den IDP-Dienst übermittelt
A_24400 - Prüfziffer als JWS signieren mit ExternalAuthenticate:
Das PS MUSS zum Signieren der Prüfziffer mit der SMC-B des ePA-Mandanten die Konnektorschnittstelle AuthSignatureService::ExternalAuthenticate nutzen gemäß [gemSpec_Kon].
Um sicherzustellen, dass per ECC signiert wird, muss das Primärsystem, wie in A_24540 - Prüfziffer als JWS signieren als ECDSA-Signatur beschrieben, beim Signieren des JWS mit Operation ExternalAuthenticate den Signatur-Typ ECDSA-Signatur verwenden. Dazu MUSS im Element dss:SignatureType die URI urn:bsi:tr:03111:ecdsa übergeben werden.
Auch hier muss wie im Abschnitt zum clientAttest beschrieben eine Formatkonvertierung zu Concatenated-Format gem. [RFC 7518]#3.4 gemacht werden.
Um einen reibungslosen Betrieb über den 01.01.2026 hinaus sicherzustellen, müssen Primärsysteme im Vorfeld:
Wir freuen uns jederzeit über Hinweise und Feedback über unser Serviceportal: Anfragen zur RSA/ ECC-Migration, um diesen Leitfaden aktuell und so zielführend wie möglich zu halten!