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 zunächst auf den Usecases rund um das E-Rezept. 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:
E-Rezept
Dringlichkeit der Umstellung auf ECC für die Ausstellung von E-Rezepten
Ausgangslage
Aktuell wird die überwiegende Mehrzahl der E-Rezepte mit RSA-signierten qualifizierten elektronischen Signaturen (QES) erstellt – lediglich eine geringe Anzahl der PSe nutzt hierfür ECC (Elliptic Curve Cryptography).
Problem
Ab dem 01.01.2026 darf das Signaturalgorithmus-Verfahren RSA-2048 nicht mehr für qualifizierte elektronische Signaturen (QES) verwendet werden.
Die Verantwortung und Aufsicht über die qualifizierte elektronische Signatur liegt bei der Bundesnetzagentur, die die Abschaltung von RSA durch regulatorische Maßnahmen verbindlich vorgibt.
Sollte der Umstieg auf ECC-signierte E-Rezepten bis dahin nicht vollständig abgeschlossen sein, bedeutet das in der Praxis:
- Sofern die Systeme nicht auf ECC umgestellt wurden, drohen ab dem 01.01.2026 flächendeckende Ausfälle bei der Rezeptausstellung
- Dies gilt auch für weitere QES-relevante Anwendungsfälle
Technische Voraussetzungen im Feld
Unsere Tests zeigen, dass
- alle im Feld befindlichen PTV5-Konnektoren bereits die Ausstellung von ECC-basierten QES unterstützen. PTV5-Konnektoren sind bereits flächendeckend im Feld ausgerollt.
- G2.1-HBA-Karten (Heilberufsausweise) ECC-Signaturen unterstützen (im Gegensatz zu G2.0 Karten, welche nur RSA unterstützen).
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.
Zusätzlicher Handlungsdruck durch neue PTV6-Konnektor-Generationen
Ab der zweiten Jahreshälfte 2025 beginnt voraussichtlich der Rollout von:
- PTV6-Konnektoren
- PTV2-HS-Konnektoren
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 detailierte 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.
Bei der RSAECC-Migration ist auch der nonQES Bereich betroffen! Und damit auch die SMC-B.
Auch hier besteht ein Handlungsdruck zur Umstellung auf ECC, sonst kommt es zu Fehlern bspw. bei der Authentisierung (z. B. am IDP-Dienst um sich am E-Rezept Fachdienst zu authentisieren) kommt.
Zusammenfassung & Empfehlung
Um einen reibungslosen Betrieb über den 01.01.2026 hinaus sicherzustellen, müssen Primärsysteme im Vorfeld:
- Die Nutzung von ECC-QES und ECC-nonQES implementieren, insbesondere bei Nutzung von G2.1-HBAs oder G2.1-SMC-Bs.
- Die Umstellung auf ECC zeitnah einleiten, um ausreichend Test- und Rollout-Zeit zu haben.
- Parallelbetrieb von RSA und ECC bis Ende 2025 sicherstellen, um G2.0-Karten weiterhin bedienen zu können.
Ein Versäumnis dieser Maßnahmen führt spätestens mit RSA-Abschaltung oder Einführung von PTV6/HSK-PTV2 zu Funktionsverlusten bspw. bei der E-Rezept-Erstellung oder der Anmeldung an TI-Fachdiensten.
Nachfolgend sind auf dieser Seite die wichtigsten Anpassungen dargestellt, um einen reibungslosen Übergang zu gewährleisten.
G2.0 Karten sind nicht ECC fähig und müssen bis 31.12.2025 ausgetauscht werden
Bis Ende 2025 werden alle G2.0 HBA/SMC-B im Feld durch G2.1 Karten ersetzt werden.
LEI bzw. deren DVOs müssen sich nicht um den Austausch aktiv bemühen. Der Austausch wird durch die Kartenherausgeber veranlasst.
Nach Erhalt der Karten müssen diese aktiviert (Transportpin) und die SMC-B neu registriert (Registrierung des Konnektors am VPN-ZugD) werden. Darin sind LEI und DVO dann durchaus involviert.
Anpassungsbedarfe bei E-Rezept Anwendungsfällen
Im folgenden werden die relevanten E-Rezept 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, dass Primärsystemhersteller ohne offene Fragen ihre Implementierung beginnen können.
E-Rezept per Konnektor mittels HBA QES signieren lassen
Ausgangssituation
Die SignDocument Operation des Konnektors wird verwendet, um das E-Rezept-Bundle qualifiziert elektronisch zu signieren. Hier sind die spezifischen Parameter:
A_19281-03 - PS verordnende LEI: E-Rezept erstellen - E-Rezept-Bundle QES signieren
Das PS der verordnenden LEI MUSS im Anwendungsfall "E-Rezept durch Verordnenden erstellen" für das E-Rezept die Signaturoperation des Konnektors mit
- der Referenz RFC-5652 für CMS-Signatur (CAdES)
- Signaturtype für eine enveloping Signature
- dem base64-codierten E-Rezept-Bundle
- eingebetteter OCSP-Antwort (IncludeRevocationInfo = true)
- Angabe des Mimetypes "text/plain; charset=utf-8"
ausführen.
(gemILF_PS_eRp_V1.10.0.pdf#afo=A_19281-03)
Anpassungsbedarf
Um sicherzustellen, dass per ECC signiert wird, muss das Primärsystem zusätzlich zu den in A_19281-03 genannten Parametern beim Aufruf der Signaturoperation SignDocument an der Konnektorschnittstelle, den Parameter
<ns10:Crypt>RSA_ECC</ns10:Crypt> setzen. Dieser Wert RSA_ECC gibt an, dass der Konnektor ECC basiert signieren soll, sofern die Signaturkarte ECC-Material beinhält. Ist kein ECC Material auf der Karte vorhanden, so führt der Konnektor automatisch eine RSA-basierte Signatur durch.
Abgabedatensatz signieren
Ausgangssituation
Die QES Signatur des Abgabedatensätzen ist in A_21619-01 festgelegt.
Weiterhin können Abgabedatensätze unter bestimmte Bedingungen auch per nonQES mittels SMC-B signiert werden:
Die Inhalte und die Struktur des Abgabedatensatzes werden durch DAV und GKV-SV vorgegeben.
Für die Signatur des Abgabedatensatzes wird der Konnektor verwendet.
(gemILF_PS_eRp_V1.10.0/#5.3.12)
Anpassungsbedarf
Um sicherzustellen, dass per ECC signiert wird, muss das Primärsystem zusätzlich zu den in den Anforderungen des Abgabadatensatzes genannten Parametern beim Aufruf der Signaturoperation SignDocument an der Konnektorschnittstelle, den Parameter
<ns10:Crypt>RSA_ECC</ns10:Crypt> setzen.
Authentisierung am E-Rezept-Fachdienst
Ausgangssituation
Der Authentisierungsprozess des Primärsystems am IDP umfasst mehrere Schritte: (gemILF_PS_eRp_V1.10.0#5.1.4.2)
Innerhalb dieser Schritte ist ein Konnektoraufruf im Zuge der Signatur des CHALLENGE_TOKEN gem. A_20663-01 und A_20665-01 notwendig.
Je nach Art der vom Konnektor durchgeführten Signatur (RSA- oder ECC-Signatur) muss das Primärsystem gem. RFC7518 entsprechend formatiert unter Berücksichtigung von A_20667-01 einreichen. Dabei ist für RSA-Signaturen nach RFC7518, Section 3.3 vorzugehen. Für ECC basierte Operationen muss jedoch nach RFC7518, Section 3.4 vorgegangen werden, wobei Brainpool-Kurven dort nicht explizit genannt werden. Dazu gibt es für gematik IDPs die Definition der Extension, sodass im JWT die Kurve mit "crv": "BP-256" angegeben werden muss.
Anpassungsbedarf
Um sicherzustellen, dass per ECC am IDP authentisiert wird und dabei gleichzeitig kompatibel mit den Konnektoren PTV6 als auch PTV5 zu sein, muss das Primärsystem den Ablauf gem. folgendem Diagramm 1 während des Authentisierungsprozesses am IDP umsetzen. Die Details zu den einzelnen Schritten inkl. Beispielaufrufen sind unter dem Diagramm zu finden.
Es wird im weiteren angenommen, dass das PS die folgenden Punkte gem. (gemILF_PS_eRp_V1.10.0#5.1.4.2) bereits durchgeführt hat, bevor der Ablauf aus dem folgenden Diagramm 1 ausgeführt wird.
a) Erzeugung eines CODE_VERIFIER und einer CODE_CHALLENGE.
b) Anfrage des CHALLENGE_TOKEN beim Authorization-Endpunkt des IDP-Dienstes.
Nach dem Durchlaufen des Diagramm 1 durch das PS müssen noch die folgenden Punkte gem. durchgeführt werden, um den IDP Autentisierungsflow abzuschließen:
e) Erzeugung eines Token-Key und KEY_VERIFIER.
f) Einreichen des AUTHORIZATION_CODE beim Token-Endpunkt zusammen mit dem verschlüsselten KEY_VERIFIER.
Diagramm 1: "Ablauf des IDP Authentisierungsflow unter Nutzung von ExternalAuthenticate des Konnektors"
1. Kartentyp Ermitteln
Rufe GetCards am Konnektor auf
Ermittle die Kartengeneration
Im Rückgabewert von GetCards muss die Produkttypversion des Objektsystems der SMC-B Karte Ausgelesen werden, mit welcher signiert werden soll. Diese ist aus der Response von getCards hier zu entnehmen: //CARD:Cards/CARD:Card/CARD:CardInfoType/CARD:CardVersion/CARD:COSVersion/CARD:ObjectSystemVersion
Darauf basierend kann aus der ObjectSystemVersion nach folgender Tabelle bestimmt werden, welche Kartengeneration diese SMC-B Karte besitzt:
| Objektsystem-PTV | Kartengeneration |
|---|---|
| < 4.4.0 | G2.0 Karte |
| >= 4.4.0 | G2.1 Karte |
2. Signieren
Signatur des CHALLENGE_TOKEN mittels ExternalAuthenticate Operation am Konnektor
Um sicherzustellen, dass mit einer der verwendeten Signaturkarte angemessenen Kryptografie, jedoch wenn möglich präferiert ECC signiert wird, muss das Primärsystem zusätzlich zu den in den Anforderungen aus gemILF_PS_eRp_V1.10.0#5.1.4.2 beim Aufruf der Operation ExternalAuthenticate an der Konnektorschnittstelle, das Parameter-Tupel
SignatureType und SignatureSchemes entsprechend setzen.
Bei zu verwendender SMC-B der Generation >= G2.1 muss das Primärsystem ExternalAuthenticate ECC-basiert aufrufen.
Bei zu verwendender SMC-B der Generation == G2.0 muss das Primärsystem ExternalAuthenticate RSA-basiert aufrufen.
Prüfung der Kryptografie der von ExternalAuthenticate zurückgegebenen Signatur
Obgleich im voherigen Schritt explizit durch die Angabe der Parameter SignatureType und SignatureSchemes beim Aufruf von ExternalAuthenticate dediziert eine ECC- bzw. RSA Signatur angefordert wurde, führt der Konnektor jedoch nur bis PTV5 diese Signatur auch wie im Request angegeben aus. Mit PTV6 werden die Parameter SignatureType und SignatureSchemes ignoriert und nicht ausgewertet. Stattdessen signiert der Konnektor automatisch und forciert ECC basiert, sofern die Signaturkarte ECC-Material beinhält. Ist kein ECC Material auf der Karte vorhanden, so führt der Konnektor automatisch eine RSA-basierte Signatur durch.
Daher muss das Primärsystem stets den rückgabewert von ExternalAuthenticate analysiseren und darauf basierend im nächsten Schritt entscheiden, ob RSA-basiert oder ECC-basiert weiter verfahren wird.
*Mit welchem Verfahren das Dokument signiert wurde kann vom Primärsystem wie folgt ermittelt werden:
Aus der Response von ExternalAuthenticate muss das XML-Attribut dss:SignatureObject/dss:Base64Signature/@Type nach folgender Tabelle ausgewertet werden:
Wert vom XML-Attribut dss:SignatureObject/dss:Base64Signature/@Type | Kryptogarfie der durchgeführten Signatur |
|---|---|
| urn:ietf:rfc:3447 | RSA (PKCS#1) |
| urn:bsi:tr:03111:ecdsa | ECC (ECDSA) |
3. Formatieren & Einreichen
Erstellung des JWT mit ECC Signatur
Wichtig: Bei ECC-basiertem Rückgabewert von ExternalAuthenticate muss die Signatur vom ASN.1 DER Format ins JOSE concatenated Format konverteiert werden, bevor diese an den IDP-Dienst weiterversandt wird.
- Code-Beispiel mit Java und der jose4j-library: https://github.com/gematik/ref-idp-server/blob/master/idp-client/src/main/java/de/gematik/idp/client/IdpClient.java#L172
- Custom-Code-Beispiel mit Java-Script: https://github.com/gematik/app-Authenticator/blob/ac17e8e80475021b2e2b80f9d7cd5f5c02a317e1/src/renderer/modules/gem-idp/services/signing-service.ts#L72
Der JOSE Header der signierten Challenge (noch vor der Tokenverschlüsselung) sieht bei der Verwendung von ECC wie folgt aus:
{
"typ": "JWT",
"cty": "NJWT",
"x5c": [
"MII..." Enthält das verwendete Signer-Zertifikat als Base64 ASN.1 DER-Encoding. Hier kommt ausnahmsweise NICHT URL-safes Base64-Encoding zum Einsatz!
],
"alg": "BP256R1"
}
Erstellung des JWT mit RSA Signatur
Achtung: Bei RSA-basiertem Rückgabewert von ExternalAuthenticate ist der Schritt des Konvertierens nicht notwendig.
Der JOSE Header der signierten Challenge (noch vor der Tokenverschlüsselung) sieht bei der Verwendung von RSA wie folgt aus:
{
"typ": "JWT",
"cty": "NJWT",
"x5c": [
"MII..." Enthält das verwendete Signer-Zertifikat als Base64 ASN.1 DER-Encoding. Hier kommt ausnahmsweise NICHT URL-safes Base64-Encoding zum Einsatz!
],
"alg": "PS256"
}
Signatur beim Authorization-Endpunkt einreichen
Senden der ECC signierten Challenge an den IDP & Empfang des AUTHORIZATION_CODE vom IDP-Dienst.
Die Einreichung erfolgt gem. A_20667-01
Wir freuen uns jederzeit über Hinweise und Feedback, um diesen Leitfaden aktuell und so zielführend wie möglich zu halten!
Add Comment