Diese Seite richtet sich speziell an Primärsystemhersteller und bietet eine ergänzende Hilfestellung, um den Umstieg auf ECC erfolgreich zu gestalten.
Der Fokus liegt hier auf den Usecases rund um KIM. 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:
KIM
Zusammenfassung
KIM-Clientmodule kapseln für die Primärsysteme die KIM-Transportfunktionalität. Daher sind in den Primärsystemen keine Anpassungen bezüglich ECC für das Verschicken und Empfangen der KIM-Nachrichten nötig. Die Primärsysteme müssen organisatorisch dafür sorgen, dass sie mit richtigen, ECC-fähigen Versionen der KIM-Clientmodule arbeiten.
Die Erläuterungen für diese Zusammenfassung finden Sie in den folgenden Abschnitten dieser Seite.
Dringlichkeit der Umstellung auf ECC für die KIM-Nachrichten
Ausgangslage
Verschlüsseln:
Aktuell wird die überwiegende Mehrzahl der KIM-Nachrichten sowohl mit RSA als auch mit ECC verschlüsselt. Dies erfolgt in den KIM-Clientmodulen.
Ab KIM 1.5.2-9 verschlüsseln die KIM-Clientmodule nur dann mit RSA, wenn für einen Empfänger ausschließlich ein RSA-Zertifikat und kein ECC-Zertifikat im VZD hinterlegt ist.
Die ersten KIM-Clientmodule nach KIM 1.5.2-9 werden Mitte Mai 2025 in der RU erwartet.
Signieren:
Beim Signieren der KIM-Nachrichten (nonQES) richten sich die KIM-Clientmodule in erster Linie nach der verfügbaren SMC-B. Falls die SMC-B ECC-Material zur Verfügung stellt, signieren die KIM-Clientmodule ab der KIM 1.5.2-9 mithilfe von ECC.
Die KIM-Clientmodule kapseln vollständig die Funktionalität des Signierens der KIM-Nachrichten.
Die ersten KIM-Clientmodule nach KIM 1.5.2-9 werden Mitte Mai 2025 in der RU erwartet.
Hintergrund
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-signierte und verschlüsselte KIM-Nachrichten 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 KIM als Transportdienst
- Dies betrifft indirekt alle QES-relevante Anwendungsfälle, die über KIM abgewickelt werden, wie eAU, eArztbrief und eEB.
Technische Voraussetzungen im Feld
Nach aktuellen Informationen aus dem Feld ist festzustellen, dass
- alle im Feld befindlichen PTV5-Konnektoren bereits die Ausstellung von ECC-basierten Signaturen unterstützen. PTV5-Konnektoren sind bereits flächendeckend im Feld ausgerollt.
- alle G2.0 HBAs/SMC-Bs werden bis Jahresende im Feld durch G2.1 ersetzt oder außer Betrieb genommen.
- Die ersten KIM-Clientmodule gemäß KIM 1.5.2-9 werden Mitte Mai 2025 in der RU erwartet. Dieses Update ist für die ECC-Fähigkeit unumgänglich. Bis Ende 2025 müssen alle Clientmodule bei allen LEIs aktualisiert worden sein.
Achtung: PTV6-Konnektoren sind keine Voraussetzung für die ECC-Migration bei KIM. Die KIM-Clientmodule verhalten sich in den obigen PT-Versionen ECC-preferred auch unter Verwendung der neuesten PTV5-Konnektoren (insbesondere die RISE-Konnektoren müssen in der Produktversion >= 5.1.18 vorliegen).
Das bedeutet:
Die Umstellung auf ECC bei KIM liegt in der Verantwortung der KIM-Clientmodule. Diese werden sicherstellen, dass bei Nutzung von G2.1-SMC-Bs die Signaturprozesse vollständig auf ECC umgestellt sind und keine unnötige RSA-Verschlüsselung stattfindet.
Die Primärsysteme müssen keine Anpassungen durchführen, damit beim Erzeugen der KIM-Nachrichten keine RSA-Artefakte entstehen und damit die ECC-Migration vollzogen wird.
Handlungsbedarf für Primärsysteme bei Erstellung von KIM-Payload
Bei manchen Anwendungsfällen, die sich auf KIM-Payload beziehen (z.B. eAU, eArztbrief, eEB), sind ggf. Anpassungen im Primärsystem notwendig.
Dabei ist zu beachten, dass die jeweilige Definition/Spezifikation der jeweiligen Fachverfahren obliegen. Diese sind hier aufgelistet: Dienstkennung-Kim-kom-le / KIM-Fachverfahren.
Zusammenfassung & Empfehlung
Um einen reibungslosen Betrieb über den 01.01.2026 hinaus sicherzustellen, müssen Primärsysteme im Vorfeld:
- Die Nutzung von neuesten KIM-Clientmodulen sicherstellen.
- Parallelbetrieb von RSA und ECC bis Ende 2025 sicherstellen, um G2.0-Karten weiterhin bedienen zu können.
Bis Ende 2025 werden alle G2.0 HBA/SMC-B im Feld durch G2.1 Karten ersetzt werden.
G2.0 Karten sind nicht ECC fähig und müssen bis spätestens 31.12.2025 ausgetauscht und die neuen G2.1-Karten vor dem 01.01.2026 aktiv (in Gebrauch) sein.
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. Empfehlung: Innerhalb der RSA-ECC-Übergangszeit sollen KIM-Mails regelmäßig abgerufen werden, um im Falle eines Kartentausches das Risiko eines Datenverlustes zu reduzieren (z. B. G2.0 zu G2.1 und damit Wechsel der Zertifikate).
Wir freuen uns jederzeit über Hinweise und Feedback, um diesen Leitfaden aktuell und so zielführend wie möglich zu halten!