gemF_Personalisierung_HSM_V1.0.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Feature: 

Personalisierung SM-B im HSM
(HSM-B)

    

     

      
Version
      
1.0.0
     
     

      
Revision
      
857709
     
     

      
Stand
      
23.02.2024
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemF_Personalisierung_HSM
     
    

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

Der HSK verfügt über ein HSM, welches die sichere Speicherung und Nutzung von privatem Schlüsselmaterial und eine performante Ausführung von kryptographischem Operationen ermöglicht. Da die Anwendungen VSDM, KIM und ePA die Institutionsidentität intensiv nutzen, soll ein Prozess definiert werden, wie eine Institutionsidentität sicher in einen HSK-HSM eingebracht werden kann. Neben den technischen Voraussetzungen am HSK sind auch die TSP und die Herausgeber von dieser Änderung betroffen.

Mit dem Feature wird es möglich, viele Institutionsidentitäten in einen HSK einzubringen und einer oder mehreren virtuellen Konnektor-Instanzen im HSK zuzuweisen, wo sie dann im Informationsmodell konfiguriert werden. Die Performancebeschränkungen von SMC-B wird damit entfernt. Der HSK kann HSM-B und SMC-B parallel nutzen (z.B. weil nicht für alle Institutionsidentitäten eine HSM-B Personalisierung etabliert ist). Der HSK kann aber weiterhin auch ausschließlich mit kartengebundenen Institutionsidentitäten (SMC-B) verwendet werden, ebenso wie ausschließlich mit HSM-Bs. Für den Betrieb des HSK ist lediglich die Verfügbarkeit einer Institutionsidentität erforderlich, unabhängig von deren Speicherort.

1.1 Zielsetzung

Spezifikation für die Personalisierung und Nutzung von Institutionsidentitäten im HSM eines Highspeed-Konnektors sowohl im Eigenbetrieb als auch im TI-Gateway.

1.2 Zielgruppe

Hersteller, Anbieter, Nutzer und andere Stakeholder.

1.3 Abgrenzungen

Das Dokument spezifiziert Anforderungen an die Produkte Highspeed-Konnektor, TI-Gateway und TSP-Komponenten, an die Anbieter TI-Gateway, Highspeed-Konnektor, SMC-B sowie an den TSP-X.509 nonQES Komponenten (kurz TSP-Komponenten), den TSP-X.509 nonQES SMC-B und den TSP-CVC. Der Identitäten-Herausgabeprozess wird für das Gesamtverständnis des Ablaufs mit beschrieben, jedoch nicht mit diesem Dokument geregelt (sondern weiterhin in [gemRL_TSL_SP_CP]). 
Basis- und KTR-Consumer sind von diesem Dokument nicht betroffen.

Das Dokument beinhaltet nur neue bzw. geänderte Anforderungen. Die vollständige Anforderungslage der Produkt- und Anbietertypen ergeben sich aus den Produkttypsteckbriefen, dem Anbietersteckbrief und den darin referenzierten Anforderungen.

1.4 Methodik

1.4.1 Epic und User Story

<Methodik von Epic und User Story erläutern>

Epics und zugeordnete User Stories werden durch eine eindeutige ID gekennzeichnet.

Epic und UserStory werden im Dokument wie folgt dargestellt:
<Jira-ID> - <Zusammenfassung des Jira-Issue>
Text / Beschreibung
[<=] 

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

1.4.2 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.

2 Einordnung in die Telematikinfrastruktur

Es wird der Herausgabe- und Personalisierungsprozess von Institutionsidentitäten (SM-B) spezifiziert, die auf einem HSM (Hardware Security Module) eines Highspeed-Konnektors (HSK) personalisiert werden. Diese SM-B-Identitäten stehen dann im HSK sowohl für TI-Gateway-Nutzer als auch für Nutzer, die einen eigenen HSK in Eigennutzung betreiben (Anbieter HSK), zur Verfügung. Für diese Nutzer ist dann nicht mehr zwingend eine SMC-B (Smartcard), die über ein eHealth-Kartenterminal (eH-KT) an den HSK angebunden ist, notwendig. Die Nutzung von SMC-Bs ist aber weiterhin möglich. Zudem wird weiterhin ein eH-KT benötigt, um HBAs und eGKs nutzen zu können.

Aus der übergreifenden Bezeichnung SM-B (Security Module Typ B) leitet sich die kartengebundene Variante der Identität mit der Bezeichnung SMC-B (Security Module Card Typ B) ab. Analog dazu wird die Ausprägung auf einem HSM im HSK im folgenden HSM-B genannt (Hardware Security Module Typ B). Somit können beide Ausprägungen im folgenden unterschieden werden, auch wenn die Identitäten, die sie repräsentieren, nicht unterscheidbar sind (Zertifikate gleichen Typs unterscheiden sich nicht, unabhängig davon, ob sie auf einem HSM-B oder einer SMC-B gespeichert sind.

3 Konzept

Für die Personalisierung des HSM-B im HSK eines TI-Gateway wird ein Vorgehen entworfen, für welches bis auf die Interaktion des Antragstellers bzw. TI-Gateway-Nutzers (Inhaber der Identität) keine manuellen Schritte notwendig sind. Dies ist sowohl auf Grund der erwarteten Menge an zu personalisierenden Identitäten als auch wegen des notwendigen Betreiberausschluss notwendig.

Für die Personalisierung des HSM-B im HSK-Eigenbetrieb sind manuelle Schritte vorgesehen, weshalb es hier die Rolle Schlüsselverwalter gibt, die diese Schritte durchführt, da in diesen Fällen aufwändige technische Umsetzungen für die erwartete geringere Menge an Identitäten nicht gerechtfertigt sind, und zudem die Umsetzung der Prozesse in direkter Verantwortung der identitätsinnehabenden Organisation selbst erfolgt.

Der Unterschied in der HSM-B-Personalisierung zwischen TI-Gateway und HSK-Eigenbetrieb liegt hauptsächlich in der notwendigen Kommunikation zum Anbieter SMC-B, welche im Falle des TI-Gateway durch das Zugangsmodul umgesetzt und im Falle des Eigenbetriebs eines HSK durch die Rolle Schlüsselverwalter manuell durchgeführt wird.

Da die Verwaltung des HSM vom HSK-Basissystem vorgenommen wird, muss dort Funktionalität umgesetzt werden, die an der Personalisierung beteiligt ist und die einer virtuellen Konnektor-Instanz im HSK (im folgenden kurz vInstanz) das HSM-B zur Verfügung stellt, damit dieses dort vom Nutzer bzw. dem DVO konfiguriert und vom Nutzer verwendet werden kann.

3.1 Beteiligte Rollen & Komponenten

Im Folgenden werden die am Prozess beteiligten Rollen und Komponenten beschrieben. Da das Feature HSM-B sowohl für das TI-Gateway als auch für den HSK-Eigenbetrieb betrachtet wird, ist eine entsprechende Fall-Unterscheidung notwendig an den Stellen, bei denen sich Rollen für diese beiden Szenarien unterscheiden.

3.1.1 Für vorbereitende Schritte

• gematik: Zulassungsstelle für Anbieter TI-Gateway, Anbieter HSK, Anbieter SMC-B (inklusive Produkt TSP).
• Hersteller HSK: Entwickelt den HSK und bringt ihn zur Zulassung. Der Hersteller erzeugt / beantragt und personalisiert HSK-Identitäten auf das HSM des HSK. Ebenso koppelt der Hersteller das HSM mit dem HSK, sodass nur der HSK die Identitäten auf dem HSM nutzen kann.
• TSP Komponenten: Stellt Komponenten- und Dienst-Zertifikate aus (hier relevant HSK-Identitäten auf Antrag der HSK-Hersteller und TLS- und Signatur-Identitäten für Anbieter SMC-B und Anbieter TI-Gateway).
• Anbieter SMC-B: Etabliert Vertrauensbeziehungen zu zugelassenen Anbietern TI-Gateway bzw. zu den Schlüsselverwaltern von zugelassenen Anbietern HSK. Beantragt TLS-Zertifikat aus vom TSP Komponenten.
• Anbieter TI-Gateway: Etabliert Vertrauensbeziehungen zu zugelassenen Anbietern SMC-B. Beantragt TLS- und Signatur-Zertifikat vom TSP Komponenten.
• Anbieter HSK: Registriert seinen Schlüsselverwalter beim Anbieter SMC-B.

3.1.2 Für die Herausgabe

3.1.2.1 Herausgebende Seite

• Herausgeber: Verantwortliche Institution für die Herausgabe von Institutionsidentitäten, Bestätigung von berechtigten Antragstellern und Institutionen und Attributbestätigung für die Organisation des Antragstellers
• Anbieter SMC-B: Erstellung von SM-B Zertifikaten, Bereitstellung OCSP-Responder, Aktivierung der Zertifikate am OCSP-Responder, Bereitstellung der Prozesse und Portale für Antrag und Freigabe der SM-B-Identitäten, umfasst die Produkte TSP X.509 nonQES SMC-B und TSP-CVC, die die Zertifikate für SM-B-Identitäten ausstellen und technische Anforderungen im Zuge der Antragstellung und Personalisierung umsetzen.

3.1.2.2 Beantragende Seite

• Identitätsträger (Institutionsidentität): Der Identitätsträger (die Institution) nimmt über möglicherweise verschiedene Akteure an dem Prozess teil. Die Interaktionen zwischen den Akteuren einer Institution liegen in der Verantwortung der Institution: 
• • Antragsteller: Die zur Beantragung der Institutionsidentität berechtigten Personen und zur Aktivierung der Institutionsidentität berechtigten Personen (bzw. berechtigt, den Aktivierungscode zu empfangen und an weitere berechtigte Personen weiterzugeben).
  • vInstanz-Admin: Administrator für die vInstanz(en) des Identitätsträgers, der in dessen Auftrag agiert (=> DVO)
    Da die Aktivierung des HSM-B über die vInstanz-Managementoberfläche stattfindet, müssen vInstanz-Admin und Antragsteller zusammenarbeiten oder der vInstanz-Admin berechtigt sein, den Aktivierungscode übergeben zu bekommen.
  • vInstanz-Nutzer: Fachlicher Nutzer einer oder mehrerer vInstanzen als TI-Gateway-Kunde oder im HSK-Eigenbetrieb und somit berechtigter Nutzer des HSM-B. Da im Fall TI-Gateway im Rahmen der Antragstellung verifiziert wird, dass eine Beziehung zum gewählten TI-Gateway-Anbieter besteht, müssen der vInstanz-Nutzer als TI-Gateway-Kunde und der Antragsteller zusammenarbeiten (oder beide Rollen werden von der selben Person ausgefüllt).

Fall TI-Gateway

• TI-Gateway, bestehend aus technischen Komponenten und deren Betreiber:
• • Highspeed-Konnektor (HSK): Von der gematik zugelassene Komponente, bestehend aus einem Basissystem, virtuellen Konnektor-Instanzen (vInstanzen) und einem HSM. Das zum HSK gehörende HSM speichert die hier betrachteten SM-B-Identitäten. Das HSM-B ist somit ein Teil des HSK und keine eigenständige Komponente.
  • TI-Gateway Zugangsmodul: Von der gematik zugelassene Komponente, die im TI-Gateway u.a. ein Nutzer-Portal anbietet und administrative Zugriffe auf den HSK - insbesondere auch bezüglich HSM-B-Personalisierung - anstelle eines menschlichen Administrators umsetzt.
    
  • Anbieter TI-Gateway: Von der gematik zugelassener Anbieter, der HSK und Zugangsmodul betreibt.

Fall HSK-Eigenbetrieb

Der Anbieter HSK betreibt einen HSK für sich selbst bzw. für eine Unternehmensgruppe, der er angehört. Antragsteller ist er entweder selbst oder jemand anderes aus dieser Unternehmensgruppe. Für diese Spezifikation werden beim Anbieter HSK unterschieden:

• Schlüsselverwalter: Dieser Akteur gehört zum Anbieter HSK und vermittelt zwischen den technischen Systemen des Anbieters SMC-B und dem HSK. Administrative Zugriffe auf den HSK zur HSM-B-Personalisierung (Erzeugung Schlüssel im HSM über HSK, Zertifikatsbezug vom Anbieter SMC-B, Zertifikatsimport in HSK) erfolgen durch die neue Rolle Schlüsselverwalter, die direkt durch Personal des Anbieters HSK ausgefüllt oder von diesem beauftragt wird.
• HSK: technische Komponente (siehe oben)

3.2 Vorbereitende Schritte

3.2.1 Personalisierung von HSK-Identitäten durch Hersteller HSK

Beteiligte Rollen: Hersteller HSK, TSP Komponenten

Dieser Schritt erfolgt vorbereitend und ist nicht für jede einzelne HSM-B-Personalisierung erneut notwendig.

Abbildung 1: Personalisierung HSK-Geräteidentitäten

Der Hersteller des HSK personalisiert im HSM des HSK die notwendigen Identitäten, die (neben AK.AUT und SAK.AUT, wie sie auch auf der gSMC-K vorhanden sind) die Identitäten HSK.SIG und HSK.ENC umfassen. Der Hersteller erzeugt die Schlüsselpaare auf dem HSM, beantragt beim TSP Komponenten die Zertifikate C.HSK.SIG und C.HSK.ENC und bringt diese in den HSK ein. Dies geschieht in der Entwicklungs-/Fertigungsumgebung des Herstellers oder im Falle bereits im Feld betriebener HSKs durch einen Wartungseinsatz des Herstellers vor Ort beim Betreiber. Die Personalisierungsprozesse des Herstellers werden im Rahmen eines Sicherheitsgutachtens regelmäßig geprüft. Andere als der Hersteller und die Komponente HSK haben keinen Zugriff auf das HSM, wodurch die Identitäten HSK.SIG/ENC im Betrieb nur vom HSK selbst verwendet werden können. Antragsberechtigt für diese Identitäten beim TSP Komponenten sind ebenfalls nur Hersteller HSK (die Freigabe zum Bezug solcher Zertifikate wird von der gematik erteilt).

Die Identitäten werden zum einen zur Signatur/Signaturprüfung von CSR-Paketen (C.HSK.SIG) und zum anderen zur Ver-/Entschlüsselung von Zertifikatspaketen (C.HSK.ENC) genutzt. Die Zertifikate enthalten eine für den jeweiligen HSK eindeutige ID in Form einer Pseudo-ICCSN, welche sich nach der für diesen HSK personalisierten HSK-Identität richtet, also identisch ist zur Pseudo-ICCSN in C.AK.AUT und C.SAK.AUT. Die Pseudo-ICCSN ist in Struktur und Handhabung identisch zur ICCSN in den Zertifikaten der gSMC-K. Die Pseudo-ICCSN ist entsprechend bei einem Zertifikatspaar (Signatur & Verschlüsselung) für einen HSK identisch. Da die Zertifikate aus der Komponenten-PKI stammen, sind sie gegen die TSL prüfbar. Werden HSKs außer Betrieb genommen oder HSK-Zertifikate/Schlüssel als kompromittiert angenommen, meldet der Hersteller HSK die entsprechende HSK-ID an den TSP Komponenten in Form eines Sperrauftrags, sodass das C.HSK.SIG als "revoked" per OCSP verauskunftet wird.

3.2.2 Vertrauensbeziehungen herstellen

Dieser Schritt erfolgt vorbereitend und ist nicht für jede einzelne HSM-B-Personalisierung erneut notwendig.

3.2.2.1 HSK-Eigenbetrieb

Beteiligte Rollen: gematik, Anbieter SMC-B, Anbieter HSK, Schlüsselverwalter

Im Falle des HSK-Eigenbetriebs muss der Schlüsselverwalter registriert werden. Die Schlüsselverwalter von zugelassenen Anbietern HSK werden der gematik von diesem Anbieter HSK benannt. Die gematik gibt diese Information (Schlüsselverwalter als Person und zugehörige Organisation, also Anbieter HSK) weiter an die Anbieter SMC-B. Die potentiellen Schlüsselverwalter wenden sich an den Anbieter SMC-B und bekommen - sofern sie dem Anbieter SMC-B von der gematik genannt wurden - Zugang zum Trust-Management-System bzw. Antrags- und Freigabeportal des Anbieter SMC-B mit der Rolle Schlüsselverwalter. Damit kann der Schlüsselverwalter Aufträge zur Schlüsselgenerierung erhalten, CSR-Pakete hochladen und Zertifikatspakete herunterladen. Schlüsselverwalter wenden sich zur Registrierung an die Anbieter SMC-B. Anbieter SMC-B sind verpflichtet alle Schlüsselverwalter von zugelassenen Anbietern HSK zu registrieren, wenn diese sich beim Anbieter SMC-B melden und der Anbieter SMC-B die Kontaktdaten dieser Personen von der gematik gemeldet bekommen hat.

3.2.2.2 TI-Gateway

Beteiligte Rollen: gematik, Anbieter SMC-B, Anbieter TI-Gateway

Die Kommunikation erfolgt zwischen Anbieter SMC-B und den Zugangsmodulen bei den Anbietern TI-Gateway. Um die n-zu-m Beziehung zwischen den Anbietern SMC-B und den Anbietern TI-Gateway effizient herzustellen, wird die Vertrauensliste der TI (TSL) erweitert. Die Anbieter TI-Gateway werden als Trust Service Provider (TSP) mit einem TSP-Service (TSPService) vom Typ "unspecified" in die TSL aufgenommen. Der Eintrag der Anbieter SMC-B wird ebenso jeweils um einen Eintrag vom Typ "unspecified" erweitert. Die TSL kann von den Prozessbeteiligten automatisiert gelesen und ausgewertet werden. Über den Namen des Anbieters im Feld Name unterhalb TSPName (TSPName/Name) aus dem TSL-Eintrag ist auch eine eindeutige Zuordnung von den dort hinterlegten Daten zu einem Anbieter möglich.

Die neu in die TSL aufzunehmenden Daten sind statisch und sollten sich pro Anbieter im Normalfall nur ca. alle 5 Jahre ändern, wenn Zertifikate ablaufen und neue hinterlegt werden. Über die im Rahmen der Zulassung aufgebaute Beziehung zu den Anbietern erhält die gematik deren Daten auf einem hinsichtlich Integrität geschützten Weg.

Die Einträge vom Typ "unspecified" für die Anbieter TI-Gateway und Anbieter SMC-B in der TSL werden genutzt:

• von den Anbietern SMC-B:
• • Extrahieren der zugelassenen Anbieter TI-Gateway um diese den Antragstellern zur Auswahl anzubieten,
  • Extrahieren die SMB-Service-URLs der Anbieter TI-Gateway für den Prozess zum Nachweis der TI-Gateway-Nutzer-Registrierung des Antragstellers und
  • Extrahieren des jeweiligen C.FD.TLS-S Zertifikats der Anbieter TI-Gateway.

• von den Anbietern TI-Gateway:
• • Extrahieren der redirect_uri jedes zugelassenen Anbieters SMC-B für den Prozess zum Nachweis der TI-Gateway-Nutzer-Registrierung des Antragstellers
  • Extrahieren des C.FD.TLS-C Zertifikats jedes zugelassenen Anbieters SMC-B für den Abgleich des beim TLS-Verbindungsaufbaus präsentierten Zertifikats

Weiterhin wird die TSL wie bei allen TI Komponenten für sämtliche Zertifikatsprüfungen verwendet. Durch Codierung der technischen Rollen Anbieter-TI-Gateway und Anbieter-SMB in deren TLS-Zertifikaten, wird die Kommunikation zwischen den Systemen dieser Anbieter abgesichert.

3.3 Herausgabe von Institutionsidentitäten

Im folgenden wird der Gesamtablauf der HSM-B-Personalisierung dargestellt, wobei für einige Teilprozesse zwischen dem Fall TI-Gateway und HSK-Eigenbetrieb unterschieden wird.

Einige Schritte, die so auch bereits bei der Beantragung und Herausgabe von SMC-Bs durchlaufen werden, sind teilweise nicht oder nicht vollständig beschrieben, da sie unverändert bleiben.

Vorbereitende, einmaligen Schritte, die vorab notwendig sind, werden hier nicht mehr betrachtet sondern wurden in den vorangegangenen Absätzen erläutert.

Für ein besseres Gesamtverständnis soll der grundlegende Ablauf einer Identitätsherausgabe in Kurzform skizziert werden, wobei bereits eine Identität auf einem HSK-HSM betrachtet wird:

• Antragsteller füllt Antrag im Antragsportal des zuständigen Anbieters SMC-B aus. Sollte dem Antrag ein Fachverfahren des Herausgebers vorausgehen, kann der Antrag vom Herausgeber bereits vorbefüllt sein.
• Anbieter SMC-B identifiziert Antragsteller und und lässt die Berechtigung vom Herausgeber prüfen
• Anbieter SMC-B veranlasst über Anbieter HSK / TI-Gateway Schlüsselerzeugung im HSM des HSK
• HSK löst Schlüsselerzeugung am HSM an, erzeugt CSRs und lässt diese vom HSM signieren
• Anbieter HSK / TI-GW übergeben CSRs an Anbieter SMC-B
• Anbieter SMC-B führt Zertifikatserstellung durch
• Anbieter SMC-B veranlasst die Übertragung der Identität in den HSK
• Anbieter SMC-B lässt dem Antragsteller das Geheimnis zur Aktivierung der Identität (Aktivierungscode) zukommen
• Antragsteller aktiviert die Identität mit Hilfe des Geheimnisses
• Antragsteller führt Freischaltung der Identität beim Anbieter SMC-B durch, der diese am OCSP-Responder freischaltet

Im Folgenden wird jeweils der Gesamtprozess der Herausgabe für die beiden Fälle TI-Gateway und HSK-Eigennutzung dargestellt.

Fall TI-Gateway

Im Fall des TI-Gateways erfolgt eine technische Kommunikation zwischen den Systemen des Anbieters SMB und dem Zugangsmodul des TI-Gateway. Das Zugangsmodul steuert daraufhin den HSK. Damit der Zertifikatsbezug automatisch ablaufen kann, wird im Rahmen der Antragstellung geprüft, dass der Antragsteller auch Kunde beim TI-Gateway ist.

Abbildung 2: Übersicht HSM-B-Personalisierung TI-Gateway

Fall HSK-Eigenbetrieb

Im Fall des HSK-Eigenbetriebs vermittelt der Schlüsselverwalter zwischen den Systemen des Anbieters SMB und dem HSK.

Abbildung 3: Übersicht HSM-B-Personalisierung HSK-Eigenbetrieb

Im Folgenden werden die einzelnen Teilschritte detailliert betrachtet, da dort zum Teil auch zusätzliche Rollen beteiligt sind.

3.3.1 Antragstellung

Die Antragstellung erfolgt für jede einzelne HSM-B-Personalisierung.

3.3.1.1 Auswahl des Identitätsträgers

Beteiligte Rollen: Anbieter SMC-B, Antragsteller

Der Antragsteller meldet sich im Portal seines Anbieters SMC-B an und wählt entweder einen leeren Antrag oder über eine Vorgangsnummer einen vorbefüllten Antrag aus. Es wird automatisch eine Antragsnummer vom Anbieter SMC-B für diesen Antrag erzeugt. Dies ist bereits heute für die SMC-B-Herausgabe der Fall.

Der Antragsteller wählt nun aus, dass er eine kartenungebundene SM-B-Identität beantragen möchte (HSM-B).

Im Folgenden wird nur der Bezug von HSM-Bs betrachtet.

3.3.1.2 Auswahl des Anbieters

Beteiligte Rollen: Anbieter SMC-B, Antragsteller

Der Anbieter SMC-B präsentiert dem Antragsteller die Liste der Anbieter HSK und Anbieter TI-Gateway, aus der der Antragsteller seinen Anbieter HSK (im Falle des HSK-Eigenbetrieb) bzw. Anbieter TI-Gateway (wenn das TI-Gateway genutzt wird) auswählt.  Es werden alle zugelassenen Anbieter TI-Gateway und alle zugelassenen Anbieter HSK, deren Schlüsselverwalter bereits beim Anbieter SMC-B registriert wurden, gelistet. Der Anbieter SMC-B muss alle Schlüsselverwalter von zugelassenen Anbietern HSK registrieren, wenn diese sich dahingehend bei ihm melden (vgl. 3.2.2.1).

Der Anbieter SMC-B unterstützt den Antragsteller, indem er den Antragsteller eine Vorauswahl bzgl. HSK Eigenbetrieb oder TI-Gateway treffen lässt und dann die Zugehörigkeit des Antragstellers zu einem bestimmten Sektor oder einer Unternehmensgruppe abfragt. Daraufhin werden die Anbieter HSK bzw. Anbieter TI-Gateway dann entsprechend vorselektiert.

Der Anbieter SMC-B ermittelt vorab die Anbieter HSK über die Schlüsselverwalter, die bei ihm registriert sind und die Anbieter TI-Gateway aus der TSL (siehe 3.2.2).

Nach der vollständigen Befüllung des Antrags sendet der Antragsteller diesen ab. Wurde ein TI-Gateway gewählt, erfolgt direkt die Verifikation des Antragstellerkontos beim Anbieter TI-Gateway (siehe 3.3.1.3).

3.3.1.3 TI-Gateway: Verifikation des Antragstellerkontos beim TI-Gateway

Beteiligte Rollen: Anbieter SMC-B, Antragsteller / vInstanz-Nutzer, Anbieter TI-Gateway, Zugangsmodul

Die Verifikation, dass der Antragsteller auch als Nutzer des während der Antragstellung ausgewählten TI-Gateways registriert ist, erfolgt mittels OAuth2/OIDC Authorization Code Flow. Es geschieht am Ende der Antragstellung, während sich der Antragsteller also noch am Browser im Antragsportal des Anbieters SMC-B befindet.

Der Anbieter SMC-B ermittelt aus der TSL mit der SMB-Service-URL den Konfigurationsinformation-Endpunkt und über letzteren die URL des Authentisierungs-Endpunkts, des Token-Endpunkts und das Signaturzertifikat C.FD.OSIG des gewählten Anbieters TI-Gateway. Der Anbieter SMC-B erzeugt einen Auth-Request, wofür die Antragsnummer, eine Zufallszahl und eine Redirect-URI notwendig ist. Er leitet den Antragsteller im Browser unter Übermittlung des Auth-Request zum Authentisierungs-Endpunkt des Anbieters TI-Gateway.

Der Antragsteller erhält eine Login-Seite im Nutzer-Portal seines TI-Gateway Anbieters auf der ihm angezeigt wird, dass zur Bestellung des HSM-B eine Authentisierung gegenüber dem Anbieter TI-Gateway notwendig ist. Dabei wird ihm auch der Namen des Anbieters SMC-B und die Antragsnummer angezeigt. Der Antragsteller authentifiziert sich beim Portal seines TI-Gateway Anbieters bzw. des Zugangsmoduls und weist somit nach, dass er vInstanz-Nutzer bei diesem TI-Gateway ist (eine explizite Authentisierung wird vom Zugangsmodul erzwungen). Das Zugangsmodul merkt sich die Zufallszahl aus dem Auth-Request des Anbieters SMC-B und lehnt spätere Aufrufe mit der selben Zufallszahl ab. Das Zugangsmodul erzeugt einen Authorization-Code, verknüpft diesen intern mit dem Auftrag und anhand der Redirect-URI aus dem Auth-Request leitet das Zugangsmodul den Antragsteller zurück zum Anbieter SMC-B unter Übermittlung des Authorization-Codes und der Antragsnummer aus dem Auth-Request.

Der Antragsteller befindet sich somit im Browser wieder im Antragsportal des Anbieters SMC-B. Letzterer fragt im Hintergrund über einen beidseitig authentisierten TLS-Kanal einen ID-Token beim Zugangsmodul des Anbieters TI-Gateway ab und gibt dabei den Authorization-Code an. Ist der Code gültig, erzeugt das Zugangsmodul einen ID-Token aus der GatewayUserID des authentifizierten vInstanz-Nutzers (Antragsteller), dem Zufallswert aus dem initialen Auth-Request des Anbieters SMC-B und der Antragsnummer und signiert das ID-Token mit seiner FD.OSIG Identität. Über den TLS-Kanals wird der ID-Token zum Anbieter SMC-B als Antwort übertragen. Das Zugangsmodul merkt sich im Erfolgsfall die Verbindung von GatewayUserID und Antragsnummer.

Der Anbieter SMC-B prüft die Signatur des ID-Token und prüft den Inhalt (Zufallswert, Antragsnummer). Der Antrag ist damit entweder automatisch abgesendet oder wird nochmal explizit vom Antragsteller abgesendet. Der Anbieter SMC-B speichert die Zuordnung von Antragsnummer zu GatewayUserID.

Für den Anbieter SMC-B und den Anbieter TI-Gateway (bzw. das Zugangsmodul) gibt es keinen direkten Nachweis, dass es sich beim Antragsteller (beim Anbieter SMC-B) und dem vInstanz-Nutzer (beim Anbieter TI-Gateway) um exakt dieselbe Person handelt. Aus dem Ablauf des Prozesses kann jedoch mit hinreichender Sicherheit darauf geschlossen werden, dass genau der Antragsteller sich als vInstanz-Nutzer am Zugangsmodul des TI-Gateways authentisieren konnte.

3.3.1.4 Identifikation Antragsteller

Beteiligte Rollen: Anbieter SMC-B, Antragsteller

Dieser Schritt erfolgt, genau wie zur Herausgabe der SMC-B, grundsätzlich für jeden Antrag.

Der Anbieter SMC-B muss den Antragsteller identifizieren, bevor Identitäten herausgegeben werden dürfen. Die Anforderungen dafür finden sich in [gemRL_TSL_SP_CP].

Der Schritt erfolgt nach der Antragstellung.

3.3.1.5 Freigabe durch Herausgeber einholen

Beteiligte Rollen: Anbieter SMC-B, Herausgeber

Dieser Schritt erfolgt, genau wie zur Herausgabe einer SMC-B, grundsätzlich für jeden Antrag gemäß Herausgaberichtlinie und Freigabeprozess.

Der Anbieter SMC-B holt eine Freigabe für den Antragsteller beim Herausgeber ein, als Nachweis, dass der Antragsteller und die antragstellende Institution berechtigt sind, eine SM-B zu beantragen und zu nutzen.

Der Schritt erfolgt nach der Identifikation des Antragstellers.

3.3.2 Zertifikatsbezug

Dieser Schritt erfolgt für jede einzelne HSM-B-Personalisierung und erfolgt erst, wenn die Prozesse zur Identifikation (3.3.1.4) und Freigabe (3.3.1.5) erfolgreich durchlaufen wurden. Dies ist also zeitlich entkoppelt von der Antragstellung.

3.3.2.1 Auslösung der Schlüsselerzeugung

3.3.2.1.1 im HSK-Eigenbetrieb

Beteiligte Rollen: Anbieter SMC-B, Schlüsselverwalter, HSK

Der Schlüsselverwalter erhält vom Anbieter SMC-B unter Angabe der Antragsnummer, des Namens des Antragstellers und des Anbieternamens (TSPName/Name aus TSL-Eintrag) des Anbieter SMC-B die Aufforderung zur Schlüsselgenerierung. Vor der Schlüsselerzeugung verifiziert der Schlüsselverwalter, dass der Antragsteller tatsächlich Teil der Organisation ist, die den HSK im Eigenbetrieb nutzt. Über die Funktionalität des HSK-Basissystems erzeugt der Schlüsselverwalter ebenfalls unter Angabe der Antragsnummer alle notwendigen Schlüsselpaare und exportiert das signierte CSR-Paket (siehe 3.3.2.2). Dieses Paket lädt der Schlüsselverwalter im Portal des Anbieter SMC-B hoch.

3.3.2.1.2 im TI-Gateway

Beteiligte Rollen: Anbieter SMC-B, Anbieter TI-Gateway, Zugangsmodul, HSK

Der Anbieter TI-Gateway erhält vom Anbieter SMC-B unter Angabe der Antragsnummer und GatewayUserID die Aufforderung zur Schlüsselgenerierung. Dies findet über eine technische Schnittstelle am Zugangsmodul und einen beidseitig authentisierten TLS-Kanal (mTLS) statt. Das jeweilige TLS-Zertifikat wird dabei gegen die TSL und über eine Rollenprüfung geprüft. Das Zugangsmodul prüft, dass ihm Antragsnummer und UserID als solche Kombination bekannt ist und löst in seiner Administratorrolle am HSK unter Angabe der Antragsnummer und des Anbieternamens (TSPName/Name aus TSL-Eintrag) des Anbieters SMC-B die Schlüsselgenerierung aus und erhält das signierte CSR-Paket (siehe 3.3.2.2), welches es an den Anbieter SMC-B über den mTLS-Kanal sendet.

3.3.2.2 CSR-Erzeugung im HSK

Beteiligte Rollen: HSK, Schlüsselverwalter, Zugangsmodul, Anbieter SMC-B

Der HSK erzeugt alle für eine SM-B-Identität notwendigen Schlüsselpaare im HSM und verknüpft diese in seiner Datenbank mit der Antragsnummer und dem Anbieternamen (TSPName/Name aus TSL-Eintrag) des Anbieters SMC-B, um sie später den Zertifikaten zuordnen zu können. Zu jedem Schlüsselpaar wird ein CSR erstellt, in den jeweils die Antragsnummer eingebettet wird. Die einzelnen CSRs werden jeweils mit dem dazu gehörigen privaten Schlüssel im HSM signiert. Das CSR-Paket aus allen CSRs und dem HSK-Verschlüsselungszertifikat C.HSK.ENC wird vom HSK mit dem privaten Signaturschlüssel zu C.HSK.SIG signiert und das Signaturzertifikat C.HSK.SIG in die Signatur eingebettet (bzgl. HSK-Identitäten siehe 3.2.1). Das signierte CSR-Paket enthält die Antragsnummer und den Anbieternamen (TSPName/Name aus TSL-Eintrag) des Anbieters SMC-B im Namen und wird an den Aufrufer (Schlüsselverwalter oder Zugangsmodul) zurückgegeben und von diesen zum Anbieter SMC-B übertragen.

3.3.2.3 Zertifikatserstellung & Zertifikatsversand

Beteiligte Rollen: Anbieter SMC-B (Schlüsselverwalter, Anbieter TI-Gateway, Zugangsmodul)

Dieser Schritt erfolgt für jede einzelne HSM-B-Personalisierung.

Der Anbieter SMC-B prüft, dass die Antragsnummer im CSR-Paket-Dateinamen und den einzelnen CSRs der erwarteten Antragsnummer entspricht und die Signatur des CSR-Paketes korrekt ist (mathematische Korrektheit Signatur und Zertifikatsprüfung C.HSK.SIG mit zeitlicher Gültigkeit, Prüfung gegen TSL und OCSP). Im Positivfall prüft er, ob das enthaltene C.HSK.ENC dieselbe Pseudo-ICCSN im Feld commonName beinhaltet, wie das geprüfte C.HSK.SIG. Sind alle Prüfungen positiv verlaufen, erstellt der Anbieter SMC-B (nach den üblichen Prüfungen der CSRs) die Zertifikate (CV-Zertifikate einer SM-B-Identität beinhalten eine Pseudo-ICCSN, X.509-Zertifikate beinhalten die Telematik-ID als Identitätsmerkmal) und generiert einen Aktivierungscode. Ist je nach der sektorspezifischen Ausprägung im X.509-Zertifikat die Verwendung der ICCSN im Feld serialNumber vorgesehen, wird dort die selbe Pseudo-ICCSN verwendet wie im CV-Zertifikat. Alle Zertifikate einer Identität und den Aktivierungscode fasst er zu einem Zertifikatspaket zusammen und verschlüsselt dieses mittels des zuvor hinsichtlich Pseudo-ICCSN geprüften C.HSK.ENC. Das Zertifikatspaket enthält die Antragsnummer und den Anbieternamen (TSPName/Name aus TSL-Eintrag) des Anbieters SMC-B im Dateinamen.

Der Anbieter SMC-B liefert im Falle des HSK-Eigenbetriebs das verschlüsselte Zertifikatspaket an den Schlüsselverwalter aus (Bereitstellung im Portal des Anbieters SMC-B).

Im Falle des TI-Gateway liefert der Anbieter SMC-B das verschlüsselte Zertifikatspaket zusammen mit den Auftragsdaten (inkl. GatewayUserID) der Antragstellung (siehe 3.3.1.3) an das Zugangsmodul des Anbieter TI-Gateway aus (über technische Schnittstelle mittels mTLS-Kanal).

3.3.2.4 Zertifikats-Import und HSM-B-Zuordnung

Dieser Schritt erfolgt für jede einzelne HSM-B-Personalisierung.

3.3.2.4.1 HSK-Eigenbetrieb

Beteiligte Rollen: Schlüsselverwalter, HSK

Der Schlüsselverwalter importiert das Zertifikatspaket in den HSK, wo es mit dem dort über das HSM verfügbaren privaten HSK.ENC-Schlüssel entschlüsselt wird. Anhand der Antragsnummer und des Anbieternamens (TSPName/Name aus TSL-Eintrag) werden die Zertifikate den entsprechenden privaten Schlüsseln im HSM zugeordnet und mathematisch geprüft, dass diese zusammengehören. Der HSK speichert den Aktivierungscode verschlüsselt ab und verknüpft ihn mit diesem HSM-B. Anschließend ordnet der Schlüsselverwalter das HSM-B auf Ebene des HSK-Basissystems manuell den vInstanzen zu, die dieses HSM-B nutzen sollen.

3.3.2.4.2 TI-Gateway

Beteiligte Rollen: Anbieter TI-Gateway, Zugangsmodul, HSK

Das Zugangsmodul importiert das Zertifikatspaket in den HSK. Dabei müssen zusätzlich die Identifikatoren für die vInstanzen des Nutzers übergeben werden. Dies sind für einen HSK eindeutige IDs, anhand derer das HSK-Basissystem eine vInstanz identifizieren kann. Somit kann später vom HSK-Basissystem genau diesen vInstanzen das HSM-B zugeordnet werden. Dise Identifikatoren sind herstellerspezifisch. Das Zertifikatspaket wird mit dem im HSK über das HSM verfügbaren privaten HSK.ENC-Schlüssel entschlüsselt. Anhand der Antragsnummer und des Anbieternamens (TSPName/Name aus TSL-Eintrag) werden die Zertifikate den entsprechenden privaten Schlüsseln im HSM zugeordnet und mathematisch geprüft, dass diese zusammengehören. Der HSK speichert den Aktivierungscode verschlüsselt ab und verknüpft ihn mit diesem HSM-B. Anhand der vom Zugangsmodul übergebenen Identifikatoren der vInstanzen, werden die erzeugten HSM-Bs allen vInstanzen dieses Nutzers zugeordnet.

Hinweis: Werden mehrere HSKs eingesetzt muss das Zugangsmodul die Information vorhalten, auf welchem HSK (bzw. dessen HSM) Schlüssel erzeugt wurden und das Zertifikatpaket auch genau dort wieder importieren, da nur dieser HSK das Zertifikatspaket entschlüsseln kann. Werden die vInstanzen eines Nutzern nicht immer auf dem selben HSK betrieben, kann es sein, dass die vInstanz des Nutzers, für den das HSM-B personalisiert werden soll, dann bereits auf einem anderen HSK betrieben wird. Hier muss eine entsprechende sichere Synchronisation stattfinden, damit das HSM-B auf dem HSK verfügbar wird, auf dem auch die vInstanz des entsprechenden Nutzer läuft.

3.3.3 Inbetriebnahme

Beteiligte Rollen: HSK, Antragsteller, vInstanz-Admin, Anbieter TI-Gateway (, Zugangsmodul)

Der vInstanz-Nutzer (Antragsteller) bzw. sein vInstanz-Admin (DVO) konfiguriert die in der vInstanz verfügbaren HSM-Bs im Infomodell (als SM-B_Verwaltet). Bevor diese einem Mandanten zugeordnet werden können, muss der Aktivierungscode über die vInstanz-Management-GUI eingegeben werden. Der HSK (vInstanz oder Basissystem) prüft die Eingabe und aktiviert im Erfolgsfall das HSM-B (Zuordnung zum Mandanten im Infomodell wird umgesetzt).

Der Nutzer muss seine SM-B-Identität beim Anbieter SMC-B freischalten, damit die X.509-Zertifikate der Identität beim TSP im OCSP-Responder freigeschalten werden und somit zu den Zertifikaten auch ein Sperrstatus per OCSP abgefragt werden kann.

4 Anforderungshaushalt

Im Folgenden werden die neuen Anforderungen für die am HSM-B-Herausgabeprozess Beteiligten definiert, wobei das Kapitel nach Zieldokumenten für die Anforderungen in Unterkapitel unterteilt ist.

4.1 Änderung in gemF_Highspeed-Konnektor

Änderung in "5.2.1.2 HSM"

[...]

Die Nutzung eines HSMs für die Identitäten der LEI ist in der Feature-Spezifikation "Personalisierung SM-B mit HSM (HSM-B)" [gemF_Personalisierung_HSM] geregelt. {für zukünftige Versionen des Highspeed-Konnektors angedacht. Aktuell müssen hier weiterhin SMC-Bs verwendet werden.} 

[...]

Das Folgende wird als Absatz 5.2.1.2.1 hinzugefügt.

Im Folgenden werden die neuen Anforderungen für die am HSM-B-Herausgabeprozess Beteiligten definiert.

4.1.1 Anforderungen an den Anbieter SMC-B und dessen TSPs

4.1.1.1 Einbindung des TSP-CVC im Innenverhältnis von Anbieter SMC-B zu seinen TSPs

Bei der Herausgabe einer kartengebundenen SM-B-Identität (SMC-B) gibt es für den Antragsteller ein Portal und die Einbindung der verschiedenen TSPs findet anschließend für den Nutzer transparent im Innenverhältnis des Anbieters SMC-B statt. Dies soll bezogen auf den Schlüsselverwalter bzw. das TI-Gateway Zugangsmodul auch im Folgenden für die technischen Umsetzungen im Zuge der Beantragung und Personalisierung eines HSM-B gelten, bei denen die TSPs beteiligt sind. In der vorliegenden Spezifikation werden technische Anforderungen an den TSP-X.509 nonQES SMC-B gerichtet. Für eine HSM-B-Identität, die CV-Zertifikate umfasst, ist entsprechend auch der TSP-CVC einzubinden. Dies geschieht im Innenverhältnis des Anbieters SMC-B und der TSPs, wird nicht ausspezifiziert und ist für den Schlüsselverwalter bzw. das TI-Gateway Zugangsmodul transparent.

Sicherheitsgutachten

4.1.1.2 Herstellen von Vertrauensbeziehungen

4.1.1.2.1 Eigene Bekanntmachung über die TSL

Damit Anbieter TI-Gateway eine Vertrauensbeziehung zu Anbietern SMC-B aufbauen können, müssen die dafür notwendigen Informationen der Anbieter SMC-B in der TSL hinterlegt werden. Konkret ist das TLS-Zertifikat eines Anbieters SMC-B innerhalb dessen bestehenden TSL-Eintrag mit einem Service-Eintrag vom Typ "unspecified" zu hinterlegen. Ein Anbieter TI-Gateway wertet diese Einträge täglich aus und hält alle aktuellen Zuordnung von "TSPName/Name" und TLS-Zertifikat für die notwendigen Prüfungen vor.

Anbietererklärung

Anbietererklärung

Sicherheitsgutachten

4.1.1.2.2 Ermitteln von Anbietern TI-Gateway über die TSL

fkt. Eig. Test

Hinweis: Neben den Service-Einträgen der Anbieter TI-Gateway und SMC-B sind in Service-Einträgen des Typs "unspecified" aktuell auch die Zertifikate der Schlüsselgenerierungsdienste (SGD) für die ePA aufgeführt.

fkt-Eig. Test

4.1.1.2.3 Ermitteln von Schlüsselverwaltern

Sicherheitsgutachten

4.1.1.3 Auswahl HSM-B und im Fall TI-Gateway Verifikation Nutzerregistrierung

Anforderungen an das technische System:

fkt. Eig. Test

fkt. Eig. Test und Sicherheitsgutachten

fkt. Eig. Test und Sicherheitsgutachten

Kann sich der Antragsteller am TI-Gateway erfolgreich authentisieren wird er im Browser unter Rückgabe eines Auth-Codes und der Antragsnummer an die redirect_uri des Anbieters SMC-B zurückgeleitet.

fkt. Eig. Test

Hinweis: RFC 6749#4.1.3 verlangt, dass redirect_uri im Token-Request enthalten sein muss, sofern er auch im Auth-Request enthalten war und dass die Werte jeweils identisch sind. Für den konkreten Ablauf entsprechend dieser Spezifikation ist der Parameter redirect_uri im Token-Request irrelevant, da die Antwort des Anbieters TI-Gateway innerhalb des mTLS Kanals stattfindet, also der Parameter redirect_uri am Token-Endpunkt des TI-Gateways ignoriert wird.

Hinweis: RFC 8705#2 fordert die Angabe der Client-ID in allen Requests, die über einen mTLS-Kanal gesendet werden. Dadurch kann der Client zugeordnet werden und geprüft werden, dass das präsentierte TLS-Clientzertifikat dem für diesen Client erwarteten Zertifikat entspricht. Letztere Prüfung wird zudem auch in A_25109* gefordert.

fkt. Eig. Test und Sicherheitsgutachten

Sämtliche durch die Richtlinie gemRL_TSL_SP_CP vorgegebenen Aktivitäten des Anbieters SMC-B zur Identifizierung und Berechtigungsprüfung des Antragstellers und zum Versand des Aktivierungscodes (analog zur PIN bei der SMC-B) bleiben von diesem Dokument unberührt. Der Versand des Aktivierungscodes muss den Anforderungen des PIN-Versands in der Richtlinie gemRL_TSL_SP_CP genügen. Der Vollständigkeit halber wird dies durch die folgenden Anforderungen noch einmal normativ reguliert.

Sicherheitsgutachten

Sicherheitsgutachten

4.1.1.4 Zertifikatserstellung

Für den Fall der Herausgabe für ein TI-Gateway wird der Ablauf zur Zertifikatserstellung zwischen Anbieter SMC-B und Anbieter TI-Gateway über eine technische Schnittstelle des TI-Gateway Zugangsmodul abgebildet, welche der Anbieter SMC-B als Client verwendet.

fkt. Eig. Test 

4.1.1.4.1 Aufforderung zur Schlüsselerzeugung

fkt. Eig Test

fkt. Eig. Test

4.1.1.4.2 Abholen des CSR-Pakets

fkt. Eig Test

fkt. Eig. Test

4.1.1.4.3 Zertifikatsproduktion

fkt. Eig. Test und Sicherheitsgutachten

Sicherheitsgutachten

fkt. Eig. Test und Sicherheitsgutachten

fkt. Eig Test

fkt. Eig. Test

4.1.2 Anforderungen an den Hersteller HSK

SiGu HSM-Perso

SiGu HSM-Perso

4.1.3 Anforderungen an den Anbieter HSK

Sicherheitsgutachten

Die geschützte Übermittlung der Daten wird mit den einzelnen Anbietern HSK vereinbart. Kontaktpunkt bei der gematik ist das Funktionspostfach kartenherausgabe@gematik.de.

Die von zugelassenen Anbietern HSK benannten Mitarbeiter werden von der gematik an den Anbieter SMC-B gemeldet.

Sicherheitsgutachten

Der Schlüsselverwalter führt dann Schlüsselerzeugung, Zertifikatsbeantragung und Zertifikatsbezug entsprechend den Vorgaben des Anbieters SMC-B durch. Vor der Ausführung dieser Schritte muss verifiziert werden, dass der Antragsteller tatsächlich Teil der Organisation ist, die den HSK, auf den das HSM-B erstellt werden soll, im Eigenbetrieb verwendet.

Sicherheitsgutachten

Nach erfolgreicher Zuordnung und Aktivierung der HSM-B in einer vInstanz beantragt der Antragsteller die Freischaltung seiner HSM-B-Identität im TMS/Antragsportal des Anbieters SMC-B, so dass diese für OCSP und VZD freigeschaltet wird.

Die für den Schutz des Verfahrens genutzten Schlüssel und Zertifikate im HSM des HSK müssen durch den Schlüsselverwalter unter Nutzung der entsprechenden Funktionalität des HSK (siehe A_23757*) hinsichtlich ihrer Laufzeit überwacht und rechtzeitig vor deren Ablauf eine Ausstellung neuer Schlüssel und Zertifikate beim Hersteller des HSK beauftragt werden.

Sicherheitsgutachten

Sicherheitsgutachten

4.1.4 Produkteigenschaften des HSK

fkt. Eig. Test, CC-Prüfstelle

CC-Prüfstelle, Produktgutachten

CC-Prüfstelle

CC-Prüfstelle

CC-Prüfstelle, fkt. Eig Test

Die einzelnen CSRs im PKCS#10 Format haben als Bsp. für ECDSA (brainpool256) folgende Struktur:

CC-Prüfstelle

fkt. Eig. Test

fkt. EIg Test, CC-Prüfstelle

fkt. EIg Test, CC-Prüfstelle

Gemäß Regel 7 in TUC_KON_000 (TIP1-A_4524* / TAB_KON_512) darf nur dann auf eine SM-B zugegriffen werden, wenn diese als SM-B_Verwaltet konfiguriert ist.

fkt.Eig. Test

Das HSM-B muss wie eine SMC-B verwendet werden können. Das umfasst mindestens:

• Zugriff über CardHandle, Zertifikatstyp und Crypt-Parameter
• Anzeige in der Liste der gesteckten Karte (Admin-GUI)
• Auslesen von C.AUT, C.ENC, C.SIG, für Crypt=[RSA, ECC]
• Operation SignDocument mit C.SIG (eAU, ePA u.a.)
• DecryptDocument mit C.ENC
• ExternalAuthenticate mit C.AUT
• readVSD (C2C und TUC_KON_110)
• Anwendung NFDM (C2C)
• Anwendung eMP (C2C)
• Anwendung ePA

Sofern das HSM-B keine CV-Zertifikate besitzt, müssen und können die C2C-Anwendungsfälle entsprechend nicht unterstützt werden.

4.2 Änderung in gemF_TI-Gateway

4.2.1 Anforderungshaushalt

Im Folgenden werden die neuen Anforderungen für die am Herausgabeprozess Beteiligten definiert.

Zum Nachweis, dass der Antragsteller für ein HSM-B tatsächlich Nutzer des von ihm im Antrag ausgewählten TI-Gateway ist, wird seitens Anbieter SMC-B ein ID-Token vom Anbieter TI-Gateway eingeholt, im Zuge dessen sich der Antragsteller erfolgreich gegenüber dem Anbieter TI-Gateway authentisieren muss. Hierzu werden die Standards OAuth2 (konkret Authorization Code Flow) nach [RFC 6749] und [OpenID Connect] verwendet.

4.2.1.1 Herstellen von Vertrauensbeziehungen

4.2.1.1.1 Eigene Bekanntmachung des Anbieters TI-Gateway

Damit Anbieter SMC-B eine Vertrauensbeziehung zu Anbietern TI-Gateway aufbauen können, müssen die dafür notwendigen Informationen der Anbieter TI-Gateway in der TSL hinterlegt werden. Konkret muss der Anbieter TI-Gateway zunächst in der TSL aufgenommen werden über einen "TrustServiceProvider"-Eintrag. Unter diesem Eintrag ist das TLS-Zertifikat eines Anbieters TI-Gateway in einem Service-Eintrag vom Typ "unspecified" zu hinterlegen. Für den OIDC-Flow im Zuge der HSM-B-Antragstellung muss der Anbieter TI-Gateway zudem seine OIDC-Konfiguration bekanntmachen. Die url dafür wird im o.g. TSLEintrag hinterlegt. Ein Anbieter SMC-B wertet diese Einträge täglich aus und hält alle aktuellen Zuordnung von "TSPName/Name" und TLS-Zertifikat für die notwendigen Prüfungen vor und ruft zu jedem Anbieter TI-Gateway über die url aus dem Service-Eintrag die OIDC-Konfiguartion ab.

Anbietererklärung

Anbietererklärung

Sicherheitsgutachten

fkt. Eig. Test, Produktgutachten

Sicherheitsgutachten

4.2.1.1.2 Ermitteln von Anbietern SMC-B über die TSL

Produktgutachten

Hinweis: Neben den Service-Einträgen der Anbieter TI-Gateway und SMC-B sind in Service-Einträgen des Typs "unspecified" auch die Zertifikate der Schlüsselgenerierungsdienste (SGD) für die ePA aufgeführt.

4.2.1.2 Nutzerauthentifizierung

fkt. Eig. Test, Produktgutachten

Produktgutachten

fkt. Eig. Test, Produktgutachten

fkt.EIg. Test, Produktgutachten

Produktgutachten

4.2.1.3 SMB-Service

fkt. Eig. Test, Produktgutachten

4.2.1.3.1 Token-Endpunkt

fkt. Eig. Test, Produktgutachten

fkt. Eig. Test, Produktgutachten

fkt. Eig. Test

4.2.1.3.2 CSR erzeugen und senden

fkt. Eig. Test

fkt. Eig. Test

fkt. Eig. Test

4.2.1.3.3 Zertifikate importieren

fkt. Eig. Herstellererklärung

fkt. Eig. Test

4.2.1.4 Verwalten von Institutionsidentitäten

fkt. Eig. Test

4.3 Änderung in gemSpec_PKI

Die neuen Zertifikatsprofile C.HSK.SIG und C.HSK.ENC müssen im Dokument an den relevanten Stellen hinzugefügt werden. Die Anforderungen zu den Profilen selbst sind entsprechend neu. Bzgl. Tabelle "Common Name (CN) der End-Entity-Zertifikate Test-PKI" werden nur die neuen Einträge dargestellt. Anforderungen, die auf die angepasste Tabelle verweisen sind ggf. entsprechend ebenso anzupassen.

Die Zertifikatsprofile C.HSK.SIG und C.HSK.ENC müssen vom TSP Komponenten umgesetzt werden.

4.3.1.1 Kapitel 5.6.4.4 C.HSK.Sig – Authentisierung HSK

4.3.1.2 Kapitel 5.6.4.5 C.HSK.ENC– Verschlüsselung HSK

Tabelle 5: Common Name (CN) der End-Entity-Zertifikate Test-PKI

4.4 Änderung in gemSpec_OID

4.4.1 Kapitel 3.5.4 OID-Vorgabe für technische Rollen

Es müssen die neuen technischen Rolle (OIDs) für TI-Gateway Zugangsmodul und die technische Schnittstelle beim Anbieter SMC-B hinzugefügt werden. Anforderungen, die auf die angepasste Tabelle verweisen sind ggf. entsprechend ebenso anzupassen.

4.5 Anpassung in gemSpec_TSL

Bzgl. der Einträge vom Typ "unspecified" müssen Änderungen am Hinweis-Satz in Kap 7.9 und an einer Anforderung vorgenommen werden.

Hinweis: Es wird auch ein Element ServiceSupplyPoint gesetzt und mit einer Platzhalter-URL befüllt, falls keine andere URL benötigt wird. Im Falle eines Eintrages für Anbieter TI-Gateway und Anbieter SMC-B wird eine für den Dienst notwendige URL verwendet. Siehe dazu [TIP1-A_4106] und die nachfolgenden Erklärungen.

4.6 Änderung in gemSpec_X_509_TSP

Die neuen Zertifikatsprofile C.HSK.SIG und C.HSK.ENC müssen hinzugefügt werden. Dies betrifft drei Tabellen, wobei im Folgenden nur die jeweils neuen Einträge gezeigt werden und nicht die vollständigen Tabellen. Anforderungen, die auf die Tabellen verweisen sind ggf. entsprechend ebenso anzupassen.

Tabelle 7: Tab_PKI_511-01 Berechtigte Zertifikatsantragsteller für Komponenten-, Signer-, nonQES-HBA- und Organisationszertifikate

Tabelle 8: Tab_PKI_512-02 Bereitstellungszeitpunkte der Zertifikatsstatusinformation durch den Erstellungsdienst

Tabelle 9: Tab_PKI_516-01 Berechtigte Sperrantragsteller für Komponenten- und Signerzertifikate

5 Dokumentenhaushalt

<optional: Auswirkungen auf den Dokumentenhaushalt>

5.1 Neue Dokumente

<Optional: Eine Übersicht betroffener Dokumente mit kurzer Charakterisierung, z.B. Inhalt, etc.>

5.2 Übersicht betroffener Dokumente

<Optional: Eine Übersicht betroffener Dokumente,z. B. Spezifikationen, Konzepte, SystemDesign etc.>

5.3 Übersicht Produkt- und Anbietertypen

Änderungen in gemProdT_Highspeed-Konnektor

Anmerkung: Die Anforderungen der folgenden Tabelle stellen einen Auszug dar und verteilen sich innerhalb der Tabelle des Originaldokuments [gemProdT_...]. Alle Anforderungen der Tabelle des Originaldokuments, die in der folgenden Tabelle nicht ausgewiesen sind, bleiben unverändert bestehenden.

Tabelle 10: Anforderungen zur funktionalen Eignung "Produkttest/Produktübergreifender Test"

Änderungen in gemAnbT_Highspeed-Konnektor

Anmerkung: Die Anforderungen der folgenden Tabelle stellen einen Auszug dar und verteilen sich innerhalb der Tabelle des Originaldokuments [gemAnbT_Highspeed-Konnektor]. Alle Anforderungen der Tabelle des Originaldokuments, die in der folgenden Tabelle nicht ausgewiesen sind, bleiben unverändert bestehenden.

Tabelle 11: Anforderungen zur funktionalen Eignung "Produkttest/Produktübergreifender Test"

Änderungen in gemAnbT_SMC-B_ATV

Anmerkung: Die Anforderungen der folgenden Tabelle stellen einen Auszug dar und verteilen sich innerhalb der Tabelle des Originaldokuments [gemAnbT_SMC-B]. Alle Anforderungen der Tabelle des Originaldokuments, die in der folgenden Tabelle nicht ausgewiesen sind, bleiben unverändert bestehenden.

Tabelle 12: Anforderungen zur funktionalen Eignung "Sicherheitsgutachten"

Änderungen in gemProdT_X509_TSP_nonQES_Komp_PTV

Tabelle 13: Anforderungen zur funktionalen Eignung "Produkttest/Produktübergreifender Test"

Änderungen in gemProdT_X509_TSP_nonQES_SMC-B

Tabelle 14 

6 Beispiele und Referenzimplementierungen

<Optional: Beispiele für Aufrufsequenzen, ausgetauschte Daten, etc. zur Unterstützung der Implementierung>

7 Anhang A – Verzeichnisse

7.1 Abkürzungen

7.2 Referenzierte Dokumente

7.2.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.

7.2.2 Weitere Dokumente