Elektronische Gesundheitskarte und Telematikinfrastruktur

Feature

Laufzeitverlängerung gSMC-K

    

     

      
Version
      
1.1.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
06.12.2022
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemF_Laufzeitverlängerung_gSMC-K
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

Dieses Dokument beschreibt das Feature "Laufzeitverlängerung gSMC-K" mit dem die spezifikatorische Grundlage für eine sichere verlängerte Nutzung von Konnektor-Identitäten der gSMC-K gelegt wird.
Das Feature ist bereits fachlich freigegeben und wird für den Produkttyp Konnektor bereitgestellt.
Die Umsetzung der Option Laufzeitverlängerung ist ab sofort verpflichtend.

1.1 Zielsetzung

Die in Konnektoren verbauten gSMC-K werden zum Zeitpunkt der Hardware-Produktion mit TI-Zertifikaten personalisiert. Gemäß gematik- und BSI-Vorgaben dürfen die Komponentenzertifikate ab dem Zeitpunkt des Abrufs maximal 5 Jahre gültig sein. Dadurch haben die Konnektoren - ohne Maßnahmen zur Verlängerung/Aktualisierung von Zertifikaten - eine maximal mögliche Lebensdauer von 5 Jahren. Unter Berücksichtigung der Lager- und Lieferzeiten fordert die gematik, dass die Konnektoren zum Zeitpunkt der Installation beim Leistungserbringer eine Restlaufzeit von mindestens 4 Jahren aufweisen müssen.
Die ersten Konnektoren für den Online-Produktivbetrieb wurden in der zweiten Jahreshälfte 2017 produziert. Somit laufen deren Zertifikate bis Ende 2022 ab und werden dadurch ungültig.
Nach Ablauf der Zertifikate im Konnektor stehen die Funktionen des Konnektors nicht mehr zur Verfügung. Stand heute muss das Gerät rechtzeitig vor Ablauf der Zertifikate getauscht werden, um eine unterbrechungsfreie TI-Nutzung für die Leistungserbringer zu gewährleisten.

Das Feature "Laufzeitverlängerung gSMC-K" beschreibt eine technische Alternative zu einem Austausch der betroffenen Geräte.

1.2 Zielgruppe

Das Dokument richtet sich an Konnektor-Hersteller, die das Feature "Laufzeitverlängerung gSMC-K" in ihrem Konnektor-Produkt umsetzen wollen.

1.3 Abgrenzungen

In diesem Dokument sind die Festlegungen und Erläuterungen zum optionalen Feature "Laufzeitverlängerung gSMC-K" für den Produkttyp Konnektor enthalten, die die [gemSpec_Kon] ergänzen.

1.4 Methodik

1.4.1 Anforderungen

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Da in dem Beispielsatz „Eine leere Liste DARF NICHT ein Element besitzen.“ die Phrase „DARF NICHT“ semantisch irreführend wäre (wenn nicht ein, dann vielleicht zwei?), wird in diesem Dokument stattdessen „Eine leere Liste DARF KEIN Element besitzen.“ verwendet. Die Schlüsselworte werden außerdem um Pronomen in Großbuchstaben ergänzt, wenn dies den Sprachfluss verbessert oder die Semantik verdeutlicht.

Anforderungen werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und Textmarke [<=] angeführten Inhalte.

1.4.2 Hinweise auf offene Punkte

Themen, die noch intern geklärt werden müssen oder eine Entscheidung seitens der Gesellschafter erfordern, sind wie folgt im Dokument gekennzeichnet:

Beispiel für einen offenen Punkt.

2 Technisches Konzept Laufzeitverlängerung gSMC-K

2.1 Zusammenfassung

Die Abbildung 1 zeigt die vom Laufzeitende der gSMC-K-Zertifikate betroffenen Handlungsfelder im Überblick.

Abbildung 1 Betroffene Konnektor-Funktionalitäten und Zertifikate

Für die Lösung gelten übergreifende Rahmenbedingungen:

• Die Verlängerung muss ein automatisierter Prozess mit einem Fallback bei Fehlern sein.
• Die Weiternutzung der bestehenden, zertifizierten Umsetzung kryptographischer Verfahren auf der gSMC-K wird angestrebt.
• Die Umsetzungs- und Zertifizierungsaufwände der Konnektor-Hersteller sollen möglichst klein sein.
• Eine implizite ECC-Migration soll nicht erfolgen.
  

2.1.1 Betroffene Komponenten und Zertifikate

Die gSMC-K enthält Schlüsselmaterial und Zertifikate für verschiedene Identitäten. Ein Teil davon sind die Geräteidentitäten des Konnektors, die von der gematik spezifiziert und im TI-Kontext gefordert sind; nur diese werden vom gematik-Konzept zur Laufzeitverlängerung der gSMC-K erfasst.
Darüber hinaus gibt es herstellerspezifisch genutzte Identitäten, die hier nicht Gegenstand der Betrachtung sind. Ob und wie herstellerspezifische Anteile der gSMC-K betroffen sind, und die Entscheidung, ob und welche Maßnahmen hierbei ergriffen werden, obliegt dem Konnektor-Hersteller.

Die Geräteidentität des Konnektors (Konnektoridentität) teilt sich in drei Identitäten auf:

1. ID.NK.VPN für den Netzkonnektor   
   Die Identität des Netzkonnektors dient der Authentisierung gegenüber dem VPN-Konzentrator und zur Registrierung beim VPN-Zugangsdienst.
2. ID.AK.AUT für den Anwendungskonnektor    
   Die Identität des Anwendungskonnektors dient der Authentisierung gegenüber den Clientsystemen im Rahmen von TLS-Verbindungen.
3. ID.SAK.AUT für die im Anwendungskonnektor enthaltene Signaturanwendungskomponente
   Die Identität des Signaturdienstes dient zur Authentisierung gegenüber den Kartenterminals. 
4. Darüber hinaus muss sich der Signaturdienst des Konnektors gegenüber dem Heilberufsausweis mittels eines kartenverifizierbaren Zertifikats (C.SAK.AUTD_CVC) mit entsprechendem Profil ausweisen, um einen Trusted Channel für die Stapel- und Komfortsignaturen aufbauen zu können.  

Nach Ablauf der gSMC-K-Zertifikate im Konnektor stehen wichtige Funktionen des Konnektors nicht mehr zur Verfügung:

• der IPsec-Verbindungsaufbau zum VPN-ZugD - C.NK.VPN 
• der Aufbau von TSL gesicherten Verbindungen zu Clientsystemen (Primärsystemen) - C.AK.AUT
• die Use Cases Stapelsignatur und Komfortsignatur, für die C2C mit einem HBA benötigt wird - C.SAK.AUTD_CVC

2.1.2 Lösung

Die im Feld befindlichen Konnektoren werden per Firmware-Update in die Lage versetzt, neue TI-Zertifikate für ihre alten Schlüssel der gSMC-K zu erhalten und zu verwenden. Der TSP X.509 nonQES für Komponenten stellt Zertifikate in der TI für den Abruf durch die Konnektoren bereit.

• Dazu werden die TSP-Komponenten für X.509 und CVC (beides Arvato) im Auftrag der Konnektor-Hersteller, die die Kartenherausgeber für die gSMC-K sind, neue Zertifikate für alle nicht gesperrten Zertifikate auf Basis der alten CSR Anträge oder der beim TSP vorliegenden Zertifikatsdaten erzeugen. Die Laufzeit der neuen Zertifikate endet am 31.12.2025.
• Die operative Umsetzung dieses Schritts soll zentral gesteuert per Auftrag der gematik an Arvato erfolgen. 
• Die neuen Zertifikate werden dem TSP in einem eigens eingerichteten „Zertifikats-Downloadpunkt“ innerhalb der TI für die Konnektoren zum Download via http bereitgestellt.
• Die Konnektoren werden so angepasst, dass sie neue Zertifikate für das auf der gSMC-K bestehende Schlüsselmaterial abrufen können, diese neuen Zertifikate in ihrem sicheren Speicher ablegen und es ab diesem Zeitpunkt statt der alten Zertifikate von der gSMC-K verwenden.
  Die Verwendung der alten Zertifikate bleibt bis zu ihrem Ablaufdatum möglich
• Für die Verwendung gegenüber dem VPN-Zugangsdienst ist dafür eine Re-Registrierung mit dem neuen NK.VPN-Zertifikat notwendig.
• Für die neuen Zertifikate muss es ebenso Sperrprozesse geben wie für die alten Zertifikate. Solange beide Zertifikate zeitlich gültig sind, müssen auch beide Zertifikate gesperrt werden, wenn bspw. ein Konnektor als gestohlen gemeldet wird.

Abbildung 2 Überblick der Abfolge der Schritte zur Laufzeitverlängerung gSMC-K

2.1.3 Wiederholbarkeit der Aktion

Die Spezifikationen und die Implementierungen der Hersteller werden so gestaltet, dass die Aktion der Laufzeitverlängerung auch wiederholt werden kann.
Eine zweite Laufzeitverlängerung darf nur nach Einwilligung  durch das BSI erfolgen. 

2.1.4 Zusammenspiel mit der ECC-Migration der Konnektoren

Die ECC-Migration der Konnektoren erfolgt unabhängig von der Laufzeitverlängerung der gSMC-K:

• ECC-Support für ePA steht ab Konnektor PTV4 zur Verfügung.
• ECC-Support für alle kartenbasierten Anwendungsfälle ist ebenso ab PTV4 vorhanden.
• ECC für TLS und IPsec wird ab PTV5 vorhanden sein.
• Eine vollständige ECC-Fähigkeit alter, insbesondere nicht-dual-personalisierter Konnektoren kann mit der erarbeiteten Lösung nicht erreicht werden, so dass diese Geräte vor Ende 2025 abgelöst werden müssen.

2.1.5 Bedeutung der Laufzeitverlängerung der gSMC-K für Robustheit, Akzeptanz und Zukunftsfähigkeit der TI

Mit dem Feature "Laufzeitverlängerung der gSMC-K" soll ein großflächiger Konnektortausch vor der Verfügbarkeit einer Zukunftskonnektorlösung vermieden werden. Die Lösung wurde so gestaltet, dass möglichst geringe Aufwände für die Umsetzung und Zertifizierung anfallen.

Im folgenden werden erst die jeweiligen Detailkonzepte der betroffenen Handlungsfelder beschrieben, bevor in Kapitel 4 die Spezifikations-Änderungen ausformuliert werden.

2.2 Identität ID.NK.VPN relevant für Konnektor - VPN-Zugangsdienst

Entsprechend der Lösungsbeschreibung in Kapitel 3.1 werden neue C.NK.VPN-Zertifikate vom TSP X.509 Komponenten erzeugt und gemeinsam mit den anderen zur gleichen ICCSN gehörigen Zertifikaten abgelegt.
Der Konnektor beginnt ab einem definierten Zeitpunkt vor Ablauf der gSMC-K-Zertifikate mit der Prüfung, ob neue Zertifikate für die ICCSN seiner gSMC-Ks vorhanden sind.
Der Konnektor lädt die bereitgestellten neuen Zertifikate herunter und legt sie in seinem sicheren Speicher ab. Die neuen Zertifikate müssen ab diesem Zeitpunkt verwendet werden. Dazu muss die Registrierung mit dem neuen C.NK.VPN-Zertifikat erfolgen.

2.3 Identität ID.AK.AUT relevant für Konnektor - PS

Beim Verbindungsaufbau zwischen PSund Konnektor präsentiert der Konnektor dem PS das Zertifikat der Identität ID.AK.AUT von der gSMC-K. Dieses Zertifikat ist 5 Jahre gültig und wird nach Erreichen des Ablaufdatums vom Primärsystem nicht mehr akzeptiert. Ein PS wird dann keine gesicherte Verbindung zu solch einem Konnektor aufbauen können. 

Bei einer erfolgreichen zentralen Erneuerung der Zertifikate der gSMC-K wird das erneuerte C.AK.AUT zur Verwendung vorgemerkt (siehe TUC_KON_410, Schritt 4). Das neue AK.AUT-Zertifikat wird vom Konnektor nicht automatisch verwendet, sondern dies wird vom Administrator manuell gesteuert (siehe A_21759). Bei Bedarf kann der Administrator alternativ nicht-TI-Zertifikate am Konnektor generieren und exportieren bzw. extern generieren und in den Konnektor importieren, so wie deren Verwendungsstartzeitpunkt definieren.

2.4 Identität SAK.AUTD_CVC relevant für C2C mit HBA

Für die Verwendung von Stapel- und Komfortsignatur (SUK) bei der QES wird im Rahmen der CardToCard-Authentisierung (C2C) zwischen HBA und dem Konnektor die Identität SAK.AUTD_CVC der gSMC-K verwendet. Die vom HBA verwendete Identität ist HPC.AUTD_SUK_CVC.

Bei HBA-G2.0-Karten wird für die mehrfache QES-Signatur mit einer einzigen PIN-Eingabe (also SUK) eine Freischaltung des HBA mittels C2C und Aufbau eines Trusted Channel (SE#2) zwischen gSMC-K und HBA für die Übertragung der zu signierenden Daten gefordert.
Die technische Notwendigkeit der C2C und des Trusted Channel für die SUK entfällt bei HBA G2.1. Um das Sicherheitsniveau für QES zu erfüllen, wird jedoch weiterhin ein Trusted Channel für die QES-Stapel- und Komfortsignatur gefordert. 

Durch die „Innere Uhr“ der Karten (Parameter pointInTime des COS) ergibt sich bei einer längeren Nutzung von CV-Zertifikaten über deren Gültigkeitszeitraum hinaus das Risiko, dass in bestimmten Szenarien das C2C fehlschlägt. Im konkreten Szenario könnte ein HBA ein zu altes gSMC-K-Zertifikat ablehnen und somit wäre dann keine Stapel- und Komfortsignatur mehr möglich. Daher muss das Zertifikat nach 5 Jahren ersetzt werden.

Entsprechend der Lösungsbeschreibung in Kapitel 3.1 werden neue SAK.AUTD_CVC-Zertifikate vom TSP CVC Komponenten erzeugt und gemeinsam mit den anderen zur gleichen ICCSN gehörigen Zertifikaten abgelegt. Der Konnektor beginnt ab einem definierten Zeitpunkt vor Ablauf der gSMC-K-Zertifikate mit der Prüfung, ob neue Zertifikate für die ICCSN seiner gSMC-Ks vorhanden sind.
Der Konnektor lädt die bereitgestellten neuen Zertifikate herunter und legt sie in seinem sicheren Speicher ab. Die neuen Zertifikate müssen ab diesem Zeitpunkt verwendet werden.

2.5 Identität ID.SAK.AUT relevant für eHealth-Kartenterminal

Die Identität ID.SAK.AUT auf der gSMC-K ist die im Anwendungskonnektor (AK) genutzte Identität für die Signaturanwendungskomponente (SAK) des Konnektors. Sie dient zur Authentisierung gegenüber den Kartenterminals.
Bisher haben die eHealth-Kartenterminals keine Uhr, gegen die ein Zertifikats-Ende-Datum geprüft werden könnte. Daher wird für das Kartenterminal beim Verifizieren des Konnektor-SAK-Zertifikats momentan auch keine Prüfung des Laufzeitendes gefordert.

Das Zertifikat C.SAK.AUT der gSMC-K wird dennoch erneuert und verwendet. Dies soll zur Absicherung der Robustheit dienen, falls Kartenterminals mit Uhren zukünftig zugelassen werden. (Zukunftsfähigkeit). Da die Kartenterminals für die Pairing-Informationen genau nur den öffentlichen Schlüssel des Konnektor-Zertifikats speichern und sich dieser nicht unterscheidet zwischen alten und erneuertem C.SAK.AUT, ist die automatische Nutzung des neuen Zertifikats im Feld problemlos möglich.

3 Operative Umsetzung

3.1 Bereitstellung des Zertifikats-Downloads

Arvato als TSP Komponenten (für x.509 und CVC) ist von der gematik beauftragt, den Zertifikats-Download zur Benutzung durch die Konnektoren, bereitzustellen. Neben der Bereitstellung des Downloadpunkts mit den Zertifikatspaketen, müssen auch alle operativen Bedingungen gegeben sein, wie beispielsweise Firewall-Freischaltungen.

3.2 Bereitstellung der Zertifikate

Die gematik wird Arvato als TSP Komponenten (für x.509 und CVC) beauftragen, neue Zertifikate für alle gSMC-K Zertifikate, die vor dem 01.01.2021 erstellt worden sind, auf Kosten der gematik zu erzeugen.

3.3 Sperrprozesse

Für alle ausgestellten Zertifikate (auch für die erneuerten) werden Sperr-Informationen vom OCSP-Responder der Komponenten-PKI bereitgestellt. Dies ist in TIP1-A_3627 für die Zertifikats-Typen der gSMC-K festgelegt und gilt somit auch für die erneuerten Zertifikate.
Zur Zeit erfolgt der Sperrprozess über die Zertifikats-Seriennummer, daher benötigen die Konnektor-Hersteller die Info zur Seriennummer. 
Es ist geplant, folgenden Prozess zwischen dem TSP Komponenten (Arvato) und den Konnektor-Herstellern zu etablieren:

• Arvato erneuert die Zertifikate auf Veranlassung der gematik.
  Innerhalb des Ausstellungsprozesses erzeugt die Arvato einen Report (z.B. im Format cvs), in dem alle relevanten Daten pro Zertifikat enthalten sind, insbesondere ICCSN, Ablaufdatum und neue Seriennummer.
• Die Konnektor-Hersteller erhalten diesen Report von Arvato.

3.4 Offline Konnektoren

Es kann vorkommen, dass Konnektoren dauerhaft offline sind (z.B. Reserve insbesondere in Krankenhäusern). Für diese Konnektoren ist die skizzierte Lösung nur geeignet, wenn sie rechtzeitig vor Ablauf der Zertifikate online genommen werden.

Dafür wurde die Möglichkeit geschaffen, dass ein Administrator manuell neue gSMC-K-Zertifikate einbringt, ggf. auch nach Ablauf der ursprünglichen Zertifikate.  

4 Spezifikation

4.1 Änderungen in gemSpec_Kon

4.1.1 (3.1) Konnektoridentität und gSMC-K

4.1.2 (3.1.1) Erneuerung der Zertifikate der gSMC-K

Es werden keine expliziten Festlegungen zu herstellerspezifisch verwendetem Material auf der gSMC-K getroffen. Es liegt in der Verantwortung des Konnektor-Herstellers, dafür zu sorgen, dass der Konnektor nach Erneuerung und Aktivierung der spezifizierten Zertifikate insgesamt fehlerfrei lauffähig ist.

4.1.3 (3.3) Betriebszustand

Tabelle 5: TAB_KON_504-01 Ausführungserlaubnis für Dienste in kritischen Fehlerzuständen

4.1.4 (4.3.5 ) Neustart und Werksreset

folgende Anforderung wird im Kapitel 4.3.5 ergänzt

4.1.5 Identität ID.NK.VPN relevant für Konnektor - VPN-Zugangsdienst

4.1.5.1 (4.3.7) Re-Registrierung des Konnektors mit neuem NK-Zertifikat

4.1.6 (3.5.1) Identität ID.AK.AUT relevant für Konnektor - PS (3.5.1 Betriebsaspekte)

4.1.7 (7 Anhang F) Events

Tabelle 8: TAB_KON_777 Events Interne Mechanismen

4.2 Änderungen in gemSpec_X.509_TSP

4.2.1 (6.6) Erneuerung von Zertifikaten der gSMC-K

A_21765-01 ersetzt A_21765:

4.3 Änderungen in gemSpec_CVC_TSP

4.3.1 (5.2) Erneuerung von CV-Zertifikaten der gSMC-K

A_21774-01 ersetzt A_21774:

4.4 (4.1.1.2) Änderungen in gemILF_PS -"ServerAuthentisierung"

Der Konnektor verwendet als TLS-Server-Zertifikat die auf der gSMC-K gespeicherte <PTV5>bzw. vom Konnektor über die TI erneuerte</PTV5> Identität ID.AK.AUT. Der CommonName dieses Zertifikats ist mit der ICCSN und dem Herausgabedatum befüllt und nicht mit dem Hostnamen des Konnektors. Eine optional durchzuführende Hostnamenprüfung durch das Primärsystem kann daher ggf. nur daraufhin erfolgen, ob der Konnektor in der LEI unter dem in Subject.AltNames festgelegten DNSName="konnektor.konlan" erreichbar ist.

<PTV5>Nach einer erfolgreichen Erneuerung der Identität ID.AK.AUT kann der Zeitpunkt der Verwendung von dieser erneuerten Identität vom Administrator frei gewählt werden. 

Der Konnektor sendet nach erfolgreicher automatischer Erneuerung der Zertifikate ein Ereignis mit dem Topic SMC_K/UPDATE/SUCCESS. Das Primärsystem sollte diese Information beziehen, den Anwender geeignet über den erfolgreichen Zertifikatsupdate informieren und eine Warnung ausgeben, dass bei Verwendung der ID.AK.AUT für die Server-Authentisierung eine Umstellung auf das neue AK.AUT-Zertifikat manuell vom Administrator vorgenommen werden muss.

Darüber hinaus kann der Konnektor intern oder extern generierte Identitäten als TLS-Server-Zertifikat verwenden. Der Administrator hat zwei Möglichkeiten, die ID.AK.AUT für die Authentisierung gegenüber den Clientsystemen zu ersetzen:

• er kann ein Zertifikat und das dazugehörige Schlüsselmaterial konnektorextern mit seinen lokalen Mitteln erzeugen und in den Konnektor importieren oder
  
• er kann ein Zertifikat und das dazugehörige Schlüsselmaterial im Konnektor erzeugen und das Zertifikat ggf. aus dem Konnektor exportieren.

Der CommonName dieser Zertifikate kann mit einem frei wählbaren Hostnamen des Konnektors befüllt werden. Eine optional durchzuführende Hostnamenprüfung durch das Primärsystem kann dann vollumfänglich erfolgen.

Der Zeitpunkt der Verwendung von generierten oder importierten Zertifikaten kann vom Administrator frei gewählt werden und ist unabhängig vom Zeitpunkt der Generierung oder des Imports. Der Administrator kann jederzeit zwischen der Verwendung von generierten, importierten, erneuerten oder ursprünglichen Zertifikaten der gSMC-K hin- und herschalten.</PTV5>

Für eine Prüfung des TLS-Server-Zertifikates des Konnektors durch das Primärsystem sind verschiedene auch kombinierbare Umsetzungsvarianten möglich.

<PTV5>Die Prüfung der generierten oder importierten Zertifikate durch das Primärsystem kann nicht gegen die TI-TSL oder die TI-Komponenten-CA-Zertifikate erfolgen, da es sich um rein lokale Identitäten außerhalb des TI-Vertrauensraums handelt.</PTV5>

Variante Prüfung gegen TI-Komponenten-SubCAs

Im Falle einer Prüfung der TLS-Server-Zertifikate des Konnektors gegen die produktive Komponenten-SubCA der TI (z.B. am PS gespeichert in einer PEM-Datei) ist der Lebenszyklus der in der TSL veröffentlichten TI-Komponenten-SubCA zu beachten. Die SubCA ist 8 Jahre gültig und wird über diesen Zeitraum in der TSL veröffentlicht. Nach spätestens drei Jahren werden jedoch End-Entity-Komponenten-Zertifikate von einer neu hinzugefügten SubCA abgeleitet, damit diese noch 5 Jahre gültig sind. Das PS muss also damit rechnen, TLS-Server-Zertifikate von Konnektoren gegen mindestens drei produktive SubCAs validieren zu können, weil es im Feld End-Entity-Konnektorzertifikate geben kann, die aus unterschiedlichen SubCAs abgeleitet sind. Am Laufzeitende einer TI-Komponenten-SubCA verliert diese ihre Gültigkeit und wird aus der TSL entfernt. Die aktuelle TSL  ist unter https://download.tsl.ti-dienste.de/ verfügbar.

Darin befinden sich Zertifikate mit dem Namen GEM.KOMP-CA*, also z.B. GEM.KOMP-CA1, GEM.KOMP-CA3, o.ä. Diese Zertifikate sind auch separat im Verzeichnis https://download.tsl.ti-dienste.de/ verfügbar, um sie als Trusted CA in der LE-Umgebung zu verwalten.  

<PTV4> Parallel dazu wird für die Einführung von elliptischen Kurven eine zweite TSL () sowie entsprechende ECC verwendende Komponenten-CA-Zertifikate () von der gematik zur Verfügung gestellt. Diese neue TSL beruht auf ECC als kryptografisches Verfahren, enthält jedoch zusätzlich alle für den parallelen Einsatz von RSA und ECC erforderlichen RSA-Anteile. </PTV4>

Variante Etablierung Vertrauensbeziehung zwischen Konnektor und PS

Falls ein Administrator am Primärsystem das TLS-Server-Zertifikat des Konnektors im Rahmen der Inbetriebnahme des Konnektors dem Zertifikatsspeicher des lokalen PS-Rechners hinzufügen will (zur Etablierung einer Vertrauensbeziehung zwischen einer Konnektor-Instanz und einer PS-Instanz in einer einzelnen LE-Umgebung), wird an PS-Arbeitsplätzen das Konnektor-TLS-Server-Zertifikat beim ersten TLS-Handshake mit dem Konnektor einmalig akzeptiert und vom Primärsystem-Arbeitsplatz persistent gespeichert, um die gesamte nachfolgende TLS-Kommunikation zwischen PS und Konnektor abzusichern (so wie an einem Browser eine Ausnahmeregelung für CAs einer Webseite gespeichert werden kann). 

Das Konnektor-TLS-Server-Zertifikat muss im Falle der Etablierung der Vertrauensbeziehung zwischen Konnektor und Primärsystem-Arbeitsplatz nicht durch das Primärsystem gegen die Komponenten-SubCAs aus der TSL geprüft werden. Im Falle eines Konnektorwechsels muss dieses Pairing mit dem neuen Konnektor erneut durchgeführt werden. Beim Austausch konnektoreigener Zertifikate, z. B. im Zuge eines Wechsels der TLS-Server-Zertifikate des Konnektors <PTV4>aufgrund der Umstellung auf Zertifikate, die ECC verwenden,</PTV4>  muss die Vertrauensbeziehung erneut mit den neu erstellten End-Entity-Zertifikaten hergestellt werden.

<PTV5>Falls ein Administrator ein konnektorextern generiertes und in den Konnektor importiertes Zertifikat, ein im Konnektor generiertes Zertifikat oder die erneuerte ID.AK.AUT für die Server-Authentisierung verwendet, so ist das Zertifikat am Primärsystem entweder bereits bekannt (z.B. durch die Verwendung einer PKI), oder es wird im Rahmen der Inbetriebnahme des Konnektors dem Zertifikatsspeicher des lokalen PS-Rechners wie oben beschrieben hinzugefügt.</PTV5>

Änderung in Absatz 4.1.4: Neuer Absatz:

<PTV5>
4.1.4.7 Informationen zu Fehlern bei der Zertifikatserneuerung (Laufzeitverlängerung gSMC-K)
Der Konnektor stellt Informationen über ggf. aufgetretene Fehler bei der Erneuerung der Zertifikate der gSMC-K über den Systeminformationsdienst zur Verfügung, insbesondere über den Topic SMC_K/DOWNLOAD/ERROR und SMC_K/UPDATE/ERROR.

Diese Informationen sollten gemäß den Betriebsprozessen des Primärsystems beim Leistungserbringer sorgfältig berücksichtigt werden, da eine fehlerhafte oder unvollständige Erneuerung der Zertifikate der gSMC-K zu einem Ausfall der TI-Anwendungsfälle führen und einen Konnektor-Tausch notwendig machen kann. Das Primärsystem sollte diese Informationen daher beziehen (siehe Kap. 4.1.4.3) und den Anwender geeignet informieren.

Ebenso stellt der Konnektor Informationen über aufgetretene Fehler bei der Reregistrierung mit erneuertem Zertifikat zur Verfügung, insbesondere über den Topic SMC_K/REGISTER/ERROR. Bei Auftreten des Fehlers mit Parameter Fail=No_Smcb muss in der Leistungserbringerumgebung dafür gesorgt werden, dass eine freigeschaltete SMC-B verfügbar ist, die der Konnektor für die Re-Registrierung verwenden kann.</PTV5>

5 Anhang A – Verzeichnisse

5.1 Abkürzungen

5.2 Referenzierte Dokumente

5.2.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummern sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

5.2.2 Weitere Dokumente