Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

Identity Provider - Frontend

    

     

      
Version
      
1.8.0
     
     

      
Revision
      
1004708
     
     

      
Stand
      
16.08.2024
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_IDP_Frontend
     
    

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb eines Identity Provider (IDP) Clients. Der Client besteht aus den logisch voneinander getrennten Komponenten Anwendungsfrontend bzw. Web-Backend und Authenticator-Modul, welche einzeln, aber auch kombiniert in einer Anwendung bereitgestellt werden können. Das Authenticator-Modul übernimmt den Authentifizierungsprozess mit dem IDP-Dienst oder sektoralem Identity Provider. Das Anwendungsfrontend bzw. Web-Backend ist eine Anwendung, welche Zugriff auf Daten innerhalb der Telematikinfrastruktur (TI) erlangen möchte. Um diesen Zugriff zu erhalten, muss eine Authentifikation an einem sektoralen Identity Provider oder mittels Smartcard beim IDP-Dienst durchgeführt werden. Das Authenticator-Modul realisiert dabei den Authentifizierungsprozess und die Kommunikation mit der Smartcard, wodurch das Anwendungsfrontend funktional entlastet wird.

Dieses Dokument beschreibt die normativen Anforderungen sowohl zum Anwendungsfrontend bzw. Web-Backend als auch zum Authenticator-Modul. Zudem enthält dieses Dokument informative Hinweise, um bei der Umsetzung zu unterstützen.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller der Anwendung, welche das Authenticator-Modul und das Anwendungsfrontend bzw. Web-Backend beinhaltet. Die Anwendung ist auf Endgeräten des Nutzers (Smartphone oder PC) installiert.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzungen

Spezifiziert werden in diesem Dokument die von Authenticator-Modul und Anwendungsfrontend bzw. Web-Backend bereitgestellten Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe auch Anhang 11 Anhang B – Verzeichnisse).

Das vorliegende Dokument beschreibt ausschließlich die Schnittstellen, welche durch das Authenticator-Modul oder ein Anwendungsfrontend bzw. Web-Backend bereitzustellen sind. Schnittstellen, welche durch den IDP-Dienst oder durch sektorale Identity Provider betrieben werden, sind im Dokument [gemSpec_IDP_Dienst] bzw. [gemSpec_IDP_Sek] beschrieben. Schnittstellen, welche durch Fachdienste zu bedienen sind, werden im Dokument [gemSpec_IDP_FD] beschrieben. Der Federation Master ist in [gemSpec_IDP_FedMaster] beschrieben.

Die vollständige Anforderungslage für die in diesem Dokument beschriebenen Anwendungen ergeben sich aus weiteren Konzept- und Spezifikationsdokumenten. Diese sind in dem Produkttypsteckbrief des Produkttyps IDP-Dienst [gemProdT_IDP-Dienst_PTV] verzeichnet.

Nicht Bestandteil des vorliegenden Dokumentes sind Festlegungen zu den Themenbereichen, wie beispielsweise der Umgang des Anwendungsfrontends mit den erlangten Fachdaten, welche proprietären Schnittstellen hierbei verwendet werden oder wie An- oder Abmeldeprozesse außerhalb der OpenID Connect (OIDC)- bzw. OpenAuthorization 2.0 (OAuth2) -Funktionalitäten abgebildet werden.

1.5 Methodik

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

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

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

Hinweis auf offene Punkte

2 Systemüberblick

Der Systemüberblick des Authenticator-Moduls bzw. des Anwendungsfrontends unterscheidet sich vom Systemüberblick des Fachdienstes und des IDP-Dienstes geringfügig, weshalb an dieser Stelle auf die Beschreibung in [gemSpec_IDP_Dienst#Kap. 2 Systemüberblick] verwiesen wird. Der Unterschied ist, dass es sich beim Primärsystem um eine, aber auch zwei getrennte Anwendungsteile handeln kann, die in dem hier in diesem Dokument beschriebenen Frontend in einer Anwendung zusammengefasst sind. Es findet im Frontend des Versicherten keine Trennung von Anwendungsfrontend und Authenticator-Modul statt.

3 Systemkontext

Das Frontend des Nutzers besteht bei mobiler Nutzung in Form eines mobilen Endgeräts mit zwei logisch voneinander getrennten Komponenten, welche kombiniert in einer Anwendung auf derselben Hardware betrieben werden. Hierbei handelt es sich einerseits um das Authenticator-Modul, welches als dezentraler Teil des IDP-Dienstes den Authentifizierungsprozess wiederverwendbar (für weitere Anwendungsfrontends) kapselt und andererseits um das Anwendungsfrontend, welches Zugriff auf Fachdaten eines Fachdienstes erlangen will. Wenn das Anwendungsfrontend auf einen Fachdienst zugreifen will, muss sich der Nutzer über das Authenticator-Modul beim IDP-Dienst identifizieren. Als Identifikationsnachweis wird vom IDP-Dienst der Besitz der Smartcard (HBA, eGK oder SMC-B) erwartet und zudem, dass der aktuelle Nutzer der Smartcard auch die Kenntnis der dazugehörigen PIN hat.

Die folgende Abbildung skizziert den Systemkontext aus der Sicht eines Endgerätes, auf dem das Authenticator-Modul und das Anwendungsfrontend kombiniert in einer Applikation installiert sind. Daraus ergeben sich Schnittstellen zu dem IDP-Dienst, dem Fachdienst und der Smartcard des Nutzers. Anforderungen zu den Schnittstellen des IDP-Dienstes werden für das Authenticator-Modul in 7.2 Schnittstellen des Authenticator-Moduls  beschrieben. Anforderungen zu den Schnittstellen des IDP-Dienstes und des Fachdienstes werden für das Anwendungsfrontend in Kapitel 8.2 Schnittstellen des Anwendungsfrontends  beschrieben. Weiterführende Informationen zur Interaktion werden in Kapitel 10 Anhang A – Interaktionen mit Smartcards der TI  skizziert.

Abbildung 1: Systemkontext aus Sicht des Frontend (bestehend aus Authenticator-Modul und Anwendungsfrontend)

Will ein Nutzer mit seinem Anwendungsfrontend auf einen Fachdienst zugreifen, kann dieser Zugriff nicht direkt erfolgen. Das Authenticator-Modul übernimmt den Aufruf und schickt diesen an den Authorization-Endpunkt. Der Authentifizierungsprozess des Nutzers verläuft zwischen dem Authenticator-Modul und dem IDP-Dienst. Bei einem positiven Verlauf der Authentifizierung liefert das Authenticator-Modul einen Authorization-Code an das Anwendungsfrontend. Gegen Vorlage dieses Codes erhält das Anwendungsfrontend vom IDP-Dienst sowohl einen ID_TOKEN als auch einen ACCESS_TOKEN. Das Anwendungsfrontend liefert den ACCESS_TOKEN an den Fachdienst und erhält bei positiver Validierung des Tokens Zugang zu den Fachdienstdaten.

Die Beschreibung der einzelnen Prozessschritte ist im Dokument [gemSpec_IDP_Dienst#Kap.3.3] enthalten.

3.1 Akteure und Rollen

Die Beschreibung der einzelnen Akteure und Rollen ist im Dokument [gemSpec_IDP_Dienst#Kap.3.1] enthalten.

3.2 Nachbarsysteme

Als Nachbarsysteme des Anwendungsfrontends sind das Authenticator-Modul (nur logisch innerhalb einer Anwendung vom Anwendungsfrontend getrennt), der IDP-Dienst (siehe [gemSpec_IDP_Dienst]) sowie die mit dem IDP-Dienst in Verbindung stehenden Fachdienste (siehe [gemSpec_IDP_FD]) zu nennen. Des Weiteren können das Authenticator-Modul und das Anwendungsfrontend als Teil eines Primärsystems realisiert werden. Die Nachbarsysteme ändern sich dadurch nicht. 

Abbildung 2: Systemüberblick mit Nachbarsystemen

4 Zerlegung des Produkttyps

Das Frontend lässt sich in zwei Module aufteilen: in ein Authenticator-Modul und ein Anwendungsfrontend (GUI), welche in einer Applikation kombiniert sind. Bei der Nutzung innerhalb eines Primärsystems kann das Primärsystem auch vollständig die Funktionalität des Authenticator-Moduls übernehmen. Die Aufteilung in unterschiedliche Module existiert nur logisch, aber nicht in Form von unterschiedlichen Anwendungen.

Abbildung 3: Zerlegung des Frontends

Authenticator-Modul

Das Authenticator-Modul bietet die Schnittstelle zum IDP-Dienst an und ist gemeinsam mit dem Anwendungsfrontend in einer mobilen App kombiniert. Für Primärsysteme muss das Authenticator-Modul als Bestandteil des Primärsystems implementiert werden (siehe [gemILF_PS_eRp]). Als Primärsysteme sollen hier PVS (ärztliche und zahnärztliche Praxisverwaltungssystem), KIS (Krankenhausinformationssystem) und AVS (Apothekenverwaltungssystem) genannt sein. Die Beschreibung des Authenticator-Moduls erfolgt in diesem Dokument, weil das Authenticator-Modul einen wesentlichen Bestandteil des Nutzer-Endgerätes/Gerät des Versicherten (GdV) darstellt und somit nicht in der zentralen Providerzone der Telematikinfrastruktur betrieben wird. Authenticator-Modul und Anwendungsfrontend werden in diesem Zusammenhang als ortsveränderliche Komponenten auf unsicheren Endgeräten betrachtet.

Anwendungsfrontend

Das Anwendungsfrontend ist eine Software, welche innerhalb der Telematikinfrastruktur lesend oder schreibend auf die Daten der Fachdienste zugreift.

5 Verteilungssicht

Die Beschreibung der theoretisch möglichen Verwendung unterschiedlicher Authenticator-Modul-Profile bleibt hier aus, da durch das beschriebene Authenticator-Modul ausschließlich ein einziger IDP-Dienst adressiert wird. Es ist somit für den IDP-Dienst der TI ausschließlich ein einziges Authenticator-Modul zugelassen. Die gematik behält sich das Recht vor, hieran Änderungen vorzunehmen.

Abbildung 4: Verteilungssicht beim Einsatz eines mobilen Endgerätes 

Teilsysteme (Module der App des Versicherten) sind zusammen auf einem Gerät, aber niemals auf mehreren Geräten verteilt, vorhanden. Als Liste der möglichen Teilsysteme seien die folgenden genannt:

• Mobiles Endgerät des Nutzers (z. B. Android Smartphone, Apple iPhone)
• Stationäres Endgerät des Nutzers (z. B. Konnektor, PVS, AVS, KIS)

Hinweis: Die beiden Teilsysteme Authenticator-Modul und Anwendungsfrontend können in zukünftigen Versionen ggf. auch auf getrennten Endgeräten <<device>> betrieben werden.

Bei der Nutzung eines stationären Endgerätes und eines Primärsystems, sind das Authenticator-Modul und das Anwendungsfrontend Teil des Primärsystems.

Abbildung 5: Verteilungssicht beim Einsatz eines stationären Endgerätes und eines Primärsystems

In jedem Fall benötigt jeder Nutzer genau ein Endsystem, auf welchem das Authenticator-Modul gemeinsam mit dem Anwendungsfrontend installiert und eingerichtet ist.

6 Übergreifende Festlegungen

6.1 Kommunikation mit Diensten der TI

Anwendungsfrontends und das Authenticator-Modul nutzen TLS-Verbindungen für die Kommunikation zu den Diensten der TI.
Das Anwendungsfrontend und das Authenticator-Modul ermitteln die Informationen zu den Endpunkten des Identity Providers aus dem Discovery Document.

7 Funktionsmerkmale Authenticator-Modul des IDP-Dienstes

Das Authenticator-Modul ist ein Modul, welches gemeinsam mit dem Anwendungsfrontend in einer Applikation für mobile Endgeräte wie Smartphones bereitgestellt wird. Bei Nutzung eines Primärsystems wird die Funktionalität des Authenticator-Moduls vom Primärsystem selbst realisiert.

Die Bereitstellung der Anwenderfrontends erfolgt über die dem jeweiligen Betriebssystem üblicherweise zur Verfügung stehenden Portale in einer sicheren, für den Nutzer kostenfreien Form. Im Falle des Betriebssystems Android erfolgt die Bereitstellung im Google Play Store oder dem zukünftig für dieses Betriebssystem etablierten Portal.

Für das Betriebssystem iOS findet die sichere Bereitstellung im Apple App Store statt, wobei dem Nutzer auch hier keine Kosten durch den Abruf der Software entstehen dürfen.

Aufgabe des Authenticator-Moduls ist, die von einem Anwendungsfrontend zum Zugriff auf Fachdienste benötigten ID_TOKEN, ACCESS_TOKEN und SSO_TOKEN mit Zustimmung des Nutzers (Resource Owner) und nach eingehender Überprüfung dessen Identität am Authorization-Endpunkt zu beantragen. Hierfür wird vom Authorization-Endpunkt ein AUTHORIZATION_CODE ausgestellt, der vom Authenticator-Modul an das Anwendungsfrontend übergeben wird. Das gleichzeitig vom Authorization-Endpunkt übergebene SSO_TOKEN wird vom Authenticator-Modul selbst gespeichert und wird von diesem für einen zukünftigen Authentifizierungsprozess ohne erneute Abfrage der Zugangsdaten des Nutzers verwendet. Das SSO_TOKEN erfüllt hier die Funktion eines Refresh-Token. Durch Übergabe des AUTHORIZATION_CODE erhält das Anwendungsfrontend am Token-Endpunkt das ID_TOKEN und ACCESS_TOKEN. 

Die für die Beantragung des ID_TOKEN und ACCESS_TOKEN notwendigen Informationen bekommt das Authenticator-Modul vom Anwendungsfrontend übergeben. Weitere Informationen bezieht das Authenticator-Modul mittels Near Field Communication-Schnittstelle (NFC) von einer Smartcard. Die notwendige elektronische Signatur im Challenge-Response-Verfahren ruft das Authenticator-Modul ebenfalls von der Smartcard ab und fordert hierbei den Nutzer zur PIN-Eingabe auf. Im Fall eines Primärsystems erfolgt diese Aktion ohne Interaktion mit dem Nutzer im Hintergrund. Weitere nicht normative Informationen hierzu finden sich im Kapitel 10 Anhang A – Interaktionen mit Smartcards der TI.

7.1 Vorbereitende Maßnahmen

Details zur Aktualisierung und sicheren Aufbewahrung der Komponenten-CAs finden sich in 7.6 Zertifikate der Komponenten-PKI.

Details zur Kodierung der Signatur des Discovery Document finden sich in [gemSpec_IDP_Dienst#Kapitel 5.1.3 Schutz des Discovery Document].

7.2 Schnittstellen des Authenticator-Moduls

Schnittstellen des Authenticator-Moduls sind diejenigen, an welchen es Anfragen durch das Anwendungsfrontend empfängt und jene, welche das Authenticator-Modul selbst verwendet, um mit dem Authorization-Endpunkt des IDP-Dienstes in Kontakt zu treten.

Das Authenticator-Modul nimmt die Authentifizierungs-Anfrage des Anwendungsfrontends entgegen und nutzt den Authorization-Endpunkt des IDP-Dienstes, um die Anfrage einzureichen. Der Authorization-Endpunkt des IDP-Dienstes antwortet – nach positiver Validierung der Anfrage – mit einem AUTHORIZATION_CODE. Das Authenticator-Modul nimmt den AUTHORIZATION_CODE und leitet diesen an das Anwendungsfrontend weiter. Nachfolgende Abbildung skizziert die Schnittstellen des Authenticator-Moduls. Komponenten und Schnittstellen, welche nicht direkt vom Authenticator-Modul genutzt werden, sind in der Abbildung grau hinterlegt.

Abbildung 6: Schnittstellen des Authenticator-Moduls

7.2.1 Schnittstellendefinition

Eingehende Daten am Authenticator-Modul stammen vom IDP-Dienst und wurden dort zuvor mit dem aktuellen Signaturzertifikat signiert. Zusätzlich wird die Integrität durch den TLS-Kanal geschützt.

Hinweis: Die Prüfung der Gültigkeit des SSO_TOKEN ergibt sich aus dessen maximaler Gültigkeitsdauer, welche je nach Fachdienst unterschiedlich sein kann und insgesamt durch den Anbieter des IDP-Dienstes eingegrenzt ist. Eine Integritätsprüfung des SSO_TOKEN ist nicht möglich, weil das SSO_TOKEN für den Authorization-Endpunkt mit dessen öffentlichen Schlüssel verschlüsselt ist.

Der Aufbau der Anfrage entspricht [gemSpec_IDP_Dienst#Kapitel 7.1 Authorization Request].

Hinweis 1: Der Authorization-Endpunkt des IDP-Dienstes, welcher die Nutzerauthentifizierung durchführt und für die Ausstellung des AUTHORIZATION_CODE zuständig ist, liefert den user_consent und das CHALLENGE_TOKEN als Antwort auf den Authorization-Request des Authenticator-Moduls.

Hinweis 2: Der Aufbau der Antwort und des CHALLENGE_TOKEN entspricht [gemSpec_IDP_Dienst#Kapitel 7.2 Authorization Response].

Hinweis: Bei Primärsystemen kann auf eine erneute PIN-Eingabe und Consent-Freigabe verzichtet werden, solange sich die SMC-B im freigeschalteten Modus befindet.

Das Authenticator-Modul wird vom Anwendungsfrontend zur Authentifizierung gegenüber dem IDP-Dienst herangezogen. Das Anwendungsfrontend ist eine beim IDP-Dienst als "OpenID Connect-Client" registrierte Software. Das Anwendungsfrontend erhält seinerseits bei der Registrierung am IDP-Dienst einen eindeutigen Identifier.

Da sich Authenticator-Modul und Anwendungsfrontend immer auf ein und demselben Endgerät des Nutzers befinden, ist es nicht notwendig, dass der IDP-Dienst deren Adressierung im Voraus kennt. Will nun das Anwendungsfrontend einen Zugriff auf den entsprechenden Fachdienst initiieren, leitet es eine Anfrage an die vom IDP-Dienst bekanntgegebene URI. Die Anfrage wird innerhalb der Anwendung dem Authenticator-Modul zugewiesen. Das Authenticator-Modul bereitet die Anfrage auf und prüft, ob alle Voraussetzungen erfüllt sind. Dann leitet das Authenticator-Modul die Anfrage an den Authorization-Endpunkt des IDP-Dienstes weiter. Der IDP-Dienst erzeugt eine session_id und fordert (im Falle eines mobilen Endgerätes) vom Authenticator-Modul die Signatur einer CHALLENGE durch das vorgesehene Identifikationsmittel. Im Falle eines Versicherten die eGK, und im Falle einer Leistungserbringerinstitution die SM-B welche über das Primärsystems durch die Operation ExternalAuthenticate des Konnektors gemäß [gemSpec_Kon#4.1.13.4] bzw. [gemILF_PS#4.4.6.1] angesprochen wird. Das Token wird hierbei nicht selbst signiert, sondern der darüber gebildete HASH-Wert (siehe Abschnitt 10.3.7.3 Signiervorgang in diesem Dokument).

Hinweis: Der Datentyp "Signed_Authentication_Data" ist in Anhang C des Dokuments [gemSpec_IDP_Dienst] beschrieben.

Hinweis 1: Das Signieren und Verschlüsseln des CHALLENGE_TOKEN ist durch die Verwendung eines Nested JWT [angelehnt an den folgenden Draft: https://tools.ietf.org/html/draft-yusef-oauth-nested-jwt-03 zu realisieren. Im cty-Header ist "NJWT" zu setzen, um anzuzeigen, dass es sich um einen Nested JWT handelt. Das Signieren wird dabei durch die Verwendung einer JSON Web Signature (JWS) [RFC7515 # section-Compact Serialization] gewährleistet. Die Verschlüsselung des signierten Token wird durch die Nutzung der JSON Web Encryption (JWE) [RFC7516 # section-3] sichergestellt. Als Verschlüsselungsalgorithmus ist ECDH-ES (Elliptic Curve Diffie-Hellman Ephemeral Static key agreement) vorgesehen.

Hinweis 2: Der Aufbau der Anfrage entspricht [gemSpec_IDP_Dienst#Kapitel 7.3 Authentication Request]. 

Hinweis 1: Der Authorization-Endpunkt liefert den AUTHORIZATION_CODE gemeinsam mit dem SSO_TOKEN innerhalb einer HTTP-Redirection (HTTP-Status Code 302) an das Authenticator-Modul zurück. Der Wert des Attributs location der HTTP 302 Response ist die vom Anwendungsfrontend beim mobilen Betriebssystem registrierte URI. Beim Aufruf der URI wird automatisch das Anwendungsfrontend mit der Verarbeitung der URI gestartet.

Hinweis 2: Der Aufbau der Header entspricht [gemSpec_IDP_Dienst#Kapitel 7.4 Authentication Response].

Hinweis: Der IDP-Dienst hat das SSO_TOKEN mit dem privaten Schlüssel PRK_AUTH für sich signiert und verschlüsselt. Das Authenticator-Modul kann und braucht den Inhalt des Tokens nicht zu lesen. Durch die Vorlage des SSO_TOKEN kann bei Bedarf ein neuer AUTHORIZATION_CODE am Authorization-Endpunkt ohne die erneute Authentisierung des Nutzers erzeugt werden.

7.2.2 Nutzung

Die im Abschnitt 7.2.1 Schnittstellendefinition beschriebenen Schnittstellen des Authenticator-Moduls werden durch das Anwendungsfrontend genutzt. Die Nutzung durch das Anwendungsfrontend erfolgt hierbei zwangsläufig vom gleichen Gerät aus.

Die verwendeten Standards sind:

• RFC3986 (URI)
• RFC7165 (JOSE)
• RFC7231 (HTTP)
• RFC7515 (JWS JSON SIGNATURE)
• RFC7516 (JWE JSON ENCRYPTION)
• RFC7517 (JWK JSON KEY)
• RFC7518 (JWE JSON ALGORITHM)
• RFC7519 (JWT JSON WEB TOKEN)
• RFC7520 (JOSE Protection)
• RFC7521 (Assertion Authorization)
• RFC7522 (Assertion SAML 2.0)
• RFC7523 (JSON TOKEN Profile)
• RFC6749 (OAuth 2.0 Authorization)
• RFC6750 (OAuth 2.0 Bearer) 
• RFC7636 (Proof Key for Code Exchange by OAuth Public Clients) 
• RFC7662 (OAuth 2.0 TOKEN INTROSPECTION)
• RFC8252 (OAuth 2.0 for Native Apps)

7.3 Hardwaremerkmale

Das Authenticator-Modul greift auf die NFC-Schnittstelle des Nutzer-Endgerätes oder auf einen angeschlossenen Smartcard-Reader zu, um das nonQES-Signatur-Zertifikat auszulesen und gegen Einforderung der PIN-Eingabe im Challenge-Response-Verfahren eine Signatur auszulösen.

Das Endgerät des Nutzers muss in der Lage sein über NFC mit der eGK oder dem HBA zu kommunizieren. Die hierfür notwendige Middleware ist als gegebene Voraussetzung anzusehen und somit Bestandteil des Betriebssystems bzw. wird zusammen mit dem Authenticator-Modul installiert und ist insofern durch den Anbieter des IDP-Dienstes bereitzustellen.

7.4 Zertifikatsprüfung

Das Authenticator-Modul verwendet bei den in TAB_Authenticator_001 dargestellten Aktivitäten Zertifikate.

Tabelle 2: TAB_Authenticator_001 – Zertifikatsnutzung des Authenticator-Modul

Hinweis: "Ein Zertifikat aktiv verwenden" bedeutet im Sinne von [A_20617-01 - Authenticator-Modul: Verpflichtende Zertifikatsprüfung], dass ein Authenticator-Modul einen dort aufgeführten öffentlichen Schlüssel innerhalb einer kryptografischen Operation (Signaturprüfung, Verschlüsselung, Signaturprüfung von öffentlichen (EC)DH-Schlüsseln etc.) nutzt. Erhält ein Authenticator-Modul bspw. einen Access Token, in dem Signaturen und Zertifikate enthalten sind, und behandelt es diesen Token als opakes Datenobjekt, ohne die Zertifikate darin gesondert zu betrachten, dann verwendet das Authenticator-Modul diese Zertifikate im Sinne von [A_20617-01 - Authenticator-Modul: Verpflichtende Zertifikatsprüfung] passiv.

7.5 Zertifikatsprüfung von Internet-Zertifikaten

Folgende Vorgaben gelten für die Prüfung von Internet-Zertifikaten.

Hinweis: Eine positiv ausgefallene Signaturprüfung von A_20068-01 ist gleichbedeutend damit, dass das CA-Zertifikat im Zertifikats-Truststore eines aktuellen Webbrowsers vorhanden ist.

Hinweis 1: Der IDP-Dienst authentisiert sich mit einem extended-validation-X.509-Zertifikat. 
Hinweis 2: Es gelten die Bedingungen für den TLS-Handshake gemäß [gemSpec_PKI#GS-A_4662].

7.6 Zertifikate der Komponenten-PKI

7.7 Nutzung von alternativen Authentisierungsmitteln

7.7.1 Technisches Konzept

Das Authenticator-Modul realisiert Funktionen zur 

• Erhebung von Gerätedaten,
• Erzeugung eines Schlüsselpaars auf dem Gerät des Versicherten und Auswahl von lokalen Authentisierungsmitteln,
• Durchführung des Registrierungsprozesses zur Hinterlegung der Pairing-Daten einschließlich des öffentlichen Schlüssels am IDP-Dienst,
• Anwendung des privaten Schlüssels zum Zweck der Authentisierung gegenüber dem IDP-Dienst,
• Inspektion der am Pairing-Endpunkt gespeicherten Pairing-Daten,
• Inspektion der lokal gespeicherten Daten und
• Durchführung des Deregistrierungsprozesses.

Die Erhebung von Gerätedaten obliegt dem Authenticator-Modul; ihre Bewertung dem IDP-Dienst. Die technische Konzeption basiert auf Nutzung der vom Betriebssystem und von der Hardware gebotenen Möglichkeiten zur lokalen Authentisierung und der Realisierung eines geeigneten Schlüsselspeichers. Das Authenticator-Modul setzt im Zuge der Schlüsselerzeugung die notwendigen Parameter. Nicht angestrebt bzw. spezifiziert sind rein Software-basierte Lösungen zur Schlüsselverwaltung oder Authentifizierungsverfahren zur autorisierten Anwendung des privaten Schlüssels, die nicht auf der Kombination von Betriebssystem und Gerätehardware beruhen. 

7.7.2 Spezifikation

7.7.2.1 Vorbereitende Maßnahmen

7.7.2.1.1 Registrierung des Authenticator-Moduls

7.7.2.2 Registrierung von alternativen Authentisierungsmitteln

7.7.2.2.1 Initiative des Nutzers

7.7.2.2.2 Authentifizierung des Nutzers gegenüber dem Pairing-Endpunkt

7.7.2.2.3 Lokale Initialisierung des Geräts

Hinweis: Die Anforderung adressiert keine faktische funktionale Prüfung, sondern eine vorab durchgeführte Auswertung von Informationen, die über Betriebssystem-APIs bereitgestellt werden.

 Hinweis 1: Die Anforderung adressiert keine faktische funktionale Prüfung, sondern eine vorab durchgeführte Auswertung von Informationen, die über Betriebssystem-APIs bereitgestellt werden. 

Hinweis 2: Zum Begriff "Ausführungsumgebung" siehe die Erläuterung in Abschnitt [gemSpec_IDP_Dienst#5.4.1 Zielsetzung]. 

Hinweis 3: Die Anforderung soll ausschließen, dass Implementierungen des Authenticator-Moduls unter ggf. möglicher Umgehung der Betriebssystem-APIs eigene (z. B. Software-basierte) Lösungen implementieren oder, sofern möglich, andere Hardwareeinheiten als die fest im Gerät verbauten verwenden.

Hinweis 4: Im Fall von  

• Android-Geräten muss das Gerät eine StrongBox Keymaster-Implementierung besitzen. Diese muss verwendet werden.
• Apple iOS-Geräten muss das Gerät mit einer Secure-Enclave ausgestattet sein. Diese muss verwendet werden. 

Hinweis: Als qualitativ ausreichend werden biometrische Mittel der Güte Biometric.STRONG im Kontext von Android-Implementierungen angesehen (siehe [androidbiom]). Im Fall von Apple-iOS-Geräten sind die vom Gerät implementierten biometrischen Mittel qualitativ ausreichend, wenn das Gerät mit einer Secure-Enclave ausgestattet ist. 

Umsetzungshinweis: Lokale Schlüsselspeicher haben ggf. eigene Anforderungen an die Art eines Identifiers. Es wird empfohlen, einen solchen durch einmaliges Anwenden von SHA-256 auf die geforderte Länge zu bringen.

7.7.2.2.4 Einleiten des Registrierungsprozesses durch das Authenticator-Modul

Die in folgenden Abschnitt genannten Anforderungen adressieren die Einleitung des Registrierungsprozesses durch das Authenticator-Modul: 

Hinweis: Die genaue Spezifikation der Schemata ist in den Tabellen "Schema Datentyp "Device_Information"" und "Schema Datentyp "Device_Type"" in [gemSpec_IDP_Dienst], Anhang C dargestellt.

Hinweis: Der Datentyp "Registration_Data" ist in Anhang C des Dokuments [gemSpec_IDP_Dienst] beschrieben.

Hinweis: Das Authenticator-Modul muss den http-Request an den Pairing-Endpunkt wie in Anhang C [gemSpec_IDP_Dienst] beschrieben gestalten.

7.7.2.2.5 Abschluss der Registrierung - Rückmeldung an den Nutzer

Hinweis: Unter einer missbräuchlichen Verwendung wird eine von der Verwendung des C.CH.AUT zur Authentifizierung am IDP-Dienst abweichende Verwendung verstanden.

7.7.2.3 Verwendung von alternativen Authentisierungsmitteln

Hinweis: Anforderungen an die Gestaltung der Signatur der vom Authorization-Endpunkt des IDP-Dienstes übermittelten Challenge und die hierbei zu signierenden Daten finden sich in A_20700-07 - Authenticator-Modul: Signatur der "CHALLENGE".

Hinweis: Die Struktur des Datentyps "Encrypted_Authentication_Data" ist in Anhang C des Dokuments [gemSpec_IDP_Dienst] beschrieben.

7.7.2.4 Lokale Inspektion von alternativen Authentisierungsmitteln

Die Inspektionsfunktion gestattet dem Nutzer die folgenden lokal gespeicherten Daten einzusehen:

• die Metadaten des lokal gespeicherten Authentifizierungszertifikats C.CH.AUT,
• den von ihm gegenüber dem IDP-Dienst vergebenen Namen des Endgeräts und
• den lokal gespeicherten Key-Identifier.

Motivation: Die Funktion macht dem Nutzer eine erfolgte Registrierung und die zur Anwendung von alternativen Authentisierungsmitteln auf seinem Gerät gespeicherten Daten transparent. 

7.7.2.5 Lokale Löschung von alternativen Authentisierungsmitteln

Dem Nutzer wird durch die Löschung der folgenden Daten die Möglichkeit gegeben, ein von ihm registriertes Pairing zu deaktivieren. Die Löschung umfasst: 

• den Key-Identifier,
• das Authentifizierungszertifikats C.CH.AUT,
• den vom Nutzer vergebenen Namen für das Mobilgerät
• die Löschung oder dauerhafte Unbrauchbarmachung des Schlüssels PrK_SE_AUT.

Die Durchführung der Löschung führt zu einer Deaktivierung des Pairings, nicht aber zum Entfernen der Pairing-Daten am Pairing-Endpunkt. Der Benutzer wird über den Fortbestand der dort vorhandenen Daten informiert.

Motivation: Die Realisierung der Funktion soll dem Nutzer ohne eine bestehende Verbindung mit dem IDP-Dienst eine Deaktivierung des von ihm registrierten alternativen Authentisierungsmittels ermöglichen. 

7.7.2.6 Inspektion und Deregistrierung der am Pairing-Endpunkt gespeicherten Daten

Hinweis: Das Authenticator-Modul muss den http-Request an den Pairing-Endpunkt wie in Anhang C, [gemSpec_IDP_Dienst] beschrieben gestalten. 

Hinweis: Das Authenticator-Modul muss den http-Request an den Pairing-Endpunkt wie Anhang C, [gemSpec_IDP_Dienst] beschrieben gestalten. 

7.7.2.6.1 Abschluss von Inspektion und Deregistrierung

8 Funktionsmerkmale Anwendungsfrontend des IDP Dienstes

Das Anwendungsfrontend ist eine Software-Komponente, welche darauf zugeschnitten ist, Daten der Fachdienste der Telematikinfrastruktur zu verarbeiten. Die Verarbeitung tritt hier in Form von Erstellung, Änderung, Anzeige, Weitergabe und Löschung auf. Um den agierenden Akteur vor dessen Zugriff auf die Fachdienste zu identifizieren, ist eine Authentisierung notwendig.

Es liegt jedoch nicht im Fokus der Fachdienste, Identitätskontrollen durchzuführen und zu überprüfen, ob eine aktuell vorgetragene Identität valide und gültig ist. Aus diesem Grund werden Identity Provider verwendet, deren alleinige Aufgabe es ist, bereits ausgegebene Identifikationsmittel auf deren aktuelle Gültigkeit und Integrität hin zu überprüfen und gleichzeitig sicherzustellen, dass der vortragende Akteur auch berechtigt ist, das Identifikationsmittel nutzen zu dürfen. Aus diesem Grund wird bei Funktionalitäten im Zusammenhang mit der Smartcard eine PIN-Abfrage angefordert. Diese soll sicherstellen, dass Besitz (Smartcard) und Wissen (PIN) zur selben Zeit quasi am selben Ort zusammenkommen und willentlich eine bestimmte Aktion auslösen.

Das Anwendungsfrontend muss die in diesem Dokument beschriebenen Schnittstellen bedienen, um auf in der TI als zentrale oder dezentrale Plattformleistung angebotene Fachdienste zugreifen zu können.

8.1 Vorbereitende Maßnahmen

Hinweis: Der IDP-Dienst nutzt die registrierte redirect_uri im späteren Verlauf dazu, eine Redirection auszuführen. Dabei wird der ausgestellte AUTHORIZATION_CODE vom Authenticator-Modul an das Anwendungsfrontend weitergeleitet.

Hinweis: Über das Discovery Document können u. a. die URIs der Endpunkte des IDP-Dienstes und die Adressen der dazugehörigen öffentlichen Schlüssel bezogen werden.

Hinweis: Der IDP-Dienst übergibt den Downloadpunkt während der organisatorischen Registrierung des Anwendungsfrontends bzw. des Primärsystems beim IDP-Dienst.

8.2 Schnittstellen des Anwendungsfrontends

Das Anwendungsfrontend hat Schnittstellen zum logisch getrennten, aber in einer Applikation kombinierten Authenticator-Modul, sowie zum IDP-Dienst und zum Fachdienst.

Es initiiert seine Authentifizierungsanfrage, welche vom Authenticator-Modul übernommen und im Auftrag des Anwendungsfrontends beim IDP-Dienst eingereicht wird. Nach erfolgreicher Authentifizierung übergibt der IDP-Dienst einen AUTHORIZATION_CODE an das Authenticator-Modul zurück. Dieser Code wird an das Anwendungsfrontend weitergereicht. Das Anwendungsfrontend erhält vom IDP-Dienst durch Vorlage des Codes einen ID_TOKEN und einen ACCESS_TOKEN. Durch Vorlage des ACCESS_TOKEN erhält das Anwendungsfrontend Zugriff auf die Daten des Fachdienstes.
Nachfolgende Abbildung skizziert die beschriebenen Schnittstellen des Anwendungsfrontends. Schnittstellen zwischen anderen Komponenten sind dabei grau angedeutet.

Abbildung 7: Schnittstellen des Anwendungsfrontends

8.2.1 Schnittstellendefinition

Das Anwendungsfrontend übergibt seine Authentifizierungs-Anfrage an das Authenticator-Modul. Es reicht den vom Authenticator-Modul übergebenen AUTHORIZATION_CODE beim IDP-Dienst ein und erhält nach positiver Validierung einen ID_TOKEN und einen ACCESS_TOKEN. Das Anwendungsfrontend nutzt den ACCESS_TOKEN, um Fachdaten vom Fachdienst anzufragen.

Hinweis: Der Aufbau der Anfrage entspricht [gemSpec_IDP_Dienst#Kapitel 7.1 Authorization Request].

Hinweis: Wenn möglich, sollen dem Nutzer Hilfestellungen gegeben werden, anhand derer man die Wiederholung des Fehlers vermeiden kann.

Hinweis: Der Aufbau des KEY_VERIFIER entspricht [gemSpec_IDP_Dienst#Kapitel 7.5 Token Request]. 

Hinweis 1: Der Aufbau der Anfrage entspricht [gemSpec_IDP_Dienst#Kapitel 7.5 Token Request].

Hinweis 2: Als Verschlüsselungsalgorithmus für den KEY_VERIFIER ist ECDH-ES (Elliptic Curve Diffie-Hellman Ephemeral Static key agreement) vorgesehen.

Hinweis: Es ist insbesondere der Inhalt der Fehlermeldung gemeint. Die Formatierung darf den Gegebenheiten des Endgerätes entsprechend angepasst werden.

Hinweis 1: Der Aufbau der Antwort und des ID_TOKEN entspricht [gemSpec_IDP_Dienst#Kapitel 7.6 Token Response]

Hinweis 2: Das Anwendungsfrontend nimmt sowohl den ID_TOKEN, als auch den ACCESS_TOKEN aus der Antwort des Token-Endpunktes des IDP-Dienstes. Der Token-Endpunkt antwortet mit dem Token auf die erfolgreiche Übergabe und Validierung des AUTHORIZATION_CODE durch das Anwendungsfrontend.  

Hinweis: Der Aufbau der Antwort und des ACCESS_TOKEN entspricht [gemSpec_IDP_Dienst#Kapitel 7.6 Token Response]. 

8.3 Anmeldung am IDP-Dienst mittels sektoraler Identity Provider

Im Rahmen der Zugänglichmachung des E-Rezepts für Versicherte ohne NFC-fähige eGK wurden ab dem 01.01.2022 Kassen-eigene Authentifizierungssysteme an das E-Rezept angebunden werden. Diese werden im Folgenden als sektorale Identity Provider bezeichnet, um sie vom zentralen IDP-Dienst abzugrenzen, welcher die Authentisierung der Nutzer direkt oder indirekt über die eGK realisiert und die bereitgestellten Attribute von dieser ableitet. 

Zur Einbindung eines sektoralen Identity Provider wird der zentrale IDP-Dienst als Authorization-Server zwischen dem Anwendungsfrontend, den sektoralen Identity Providern und dem E-Rezept Fachdienst eingesetzt.

Dieses Vorgehen wird auch nach der Etablierung einer Föderation von Identity Providern beibehalten, da der IDP-Dienst den Funktionsumfang eines Authorization-Servers bereits zum Großteil abdeckt. Das E-Rezept FdV agiert hierbei dann nur noch in der Rolle eines Anwendungsfrontends.

Die folgenden Festlegungen stellen eine Konkretisierung der generellen Vorgaben gemäß 9 Nutzung sektoraler Identity Provider dar, welche bei der Verwendung des IDP-Dienstes als Authorization-Server gelten.

Hinweis: Übergangsweise enthält diese Liste sowohl sektorale Identity Provider der Föderation als auch die bis zum 31.12.2023 zulässigen sektoralen Authenticator Module, welche noch nicht an die Föderation angebunden wurden.

Hinweis: Übergangsweise enthält diese Liste sowohl sektorale Identity Provider der Föderation als auch die bis zum 31.12.2023 zulässigen sektoralen Authenticator Module, welche noch nicht an die Föderation angebunden wurden. Der IDP-Dienst trifft anhand der "idp_iss_id" eine Fallunterscheidung bezüglich des konkreten Folgeprozesses.

Hinweis: Es wird hierbei angenommen, dass auf dem Endgerät des Nutzers ein zum sektoralen Identity Provider gehörendes Authenticator-Modul existiert, das für die angegebene URL als Handler registriert ist. Ist dies nicht der Fall, wird der Nutzer auf eine entsprechende Webseite des sektoralen Identity Provider geleitet, welche ihn über die Installationsmöglichkeiten informiert und alternativ den Login über ein getrenntes Gerät mit installiertem Authenticator-Modul ermöglicht.

Hinweis: Durch den Verzicht auf die zwingende Nutzung von Universal Links hat der Anbieter des sektoraler Identity Providers die Möglichkeit über die Webseite eine Fehlerbehandlung bei nicht installiertem Authenticator-Modul zu machen.

Hinweis: Der Parameter kk_app_redirect_uri wird befristet im Prozess der Anbindung von sektoralen Identity Providern außerhalb der Föderation verwendet.

Hinweis: Der Parameter kk_app_redirect_uri wird befristet im Prozess der Anbindung von sektoralen Identity Providern außerhalb der Föderation verwendet.

8.3.1 Registrierung des Anwendungsfrontend für App2App-Kommunikation

Aufgrund der genannten Abhängigkeiten sind zu den folgenden Anforderungen jeweils die geforderten Ausgestaltungen für Android und iOS genannt. Bei beiden Betriebssystemen werden Apps - analog zu web-basierten Anwendungen - über URLs adressiert, die von den installierten Apps beansprucht werden. Die Eindeutigkeit der Zuordnung zwischen URL und App wird in beiden Fällen durch Daten innerhalb der Distribution und unter der URL abrufbaren Informationen hergestellt (sog. Asset-Link-Dateien im Fall von Android bzw. Apple-App-Site-Association-Dateien im Fall Apple/iOS).  

Hinweis: Das gesetzte Flag ist notwendige Voraussetzung für die Etablierung der App als Default Handler für die im Host-Parameter genannten URL.  

[{

  "relation": ["delegate_permission/common.handle_all_urls"],

  "target": {

    "namespace": "android_app",

    "package_name": "<Beispiel:com.example.erpfasttrack>",

    "sha256_cert_fingerprints":

    [...]

  }

}]

{

  "applinks": {

      "details": [

           {

             "appIDs": [ "A9FL89PFFL.de.gematik.erp4ios.eRezept" ],

             "paths": ["*"]

           }

       ]

   },
....

}

8.4 Funktionen des Anwendungsfrontends bei Nutzung des IDP-Dienst als OIDC IDP

Wenn der Fachdienst selbst als Client gegenüber dem IDP-Dienst agiert und sowohl Authorization_Request wie auch Token_Request selbst formuliert entfällt auf das Anwendungsfrontend lediglich eine vermittelnde Rolle zum verwendeten Authenticator Modul des IDP-Dienstes.

In diesem Fall sind die Anforderungen aus Kapitel 8.1 und 8.2 für das Anwendungsfrontend nicht relevant. Die entsprechenden Funktionen übernimmt der Authorization Server.

9 Nutzung sektoraler Identity Provider

Zu einem sektoralen IDP gehören der eigentliche Identity Provider und ein oder mehrere Authenticator-Module. Anforderungen zum sektoralen IDP und seinen Authenticator-Modulen sind in [gemSpec_IDP_Sek] spezifiziert. Die nachfolgenden Anforderungen beziehen sich auf die Anwendungsfrontends der Fachdienste und deren Schnittstellen zum sektoralen IDP.

Im Kontext der vorliegenden Spezifikation wird angenommen, dass zu einem sektoralen Identity Provider-Dienst mindestens ein dediziertes Authenticator-Modul existiert, welches in der Lage ist, die Authentifizierung eines Nutzers zu übernehmen, d. h. den Nutzer mit spezifischen Methoden gegenüber dem sektoralen Identity Provider-Dienst zu authentifizieren und eine hiernach vom sektoralen Identity Provider-Dienst produzierte Attestierungen in Form eines AUTHORIZATION_CODE über das Authenticator-Modul an den anfragenden Authorization-Server zurückzugeben. Die Delegierung der Authentifizierung an ein Authenticator-Modul und den zugehörigen sektoralen Identity Provider erfolgt auf Initiative des Nutzers. 

9.1 Unterstützung des Authorization Flow zur Nutzerauthentifizierung mit sektoralen IDP

Zur Realisierung des in [gemSpec_IDP_Sek#7.1] definierten Flows, einschließlich der hierbei erforderlichen Übergabe des AUTHORIZATION_CODE und anderer Daten, bedarf es eines wechselseitigen Aufrufs zwischen dem Anwendungsfrontend und dem gewählten Authenticator-Modul des sektoralen Identity Provider. Dies wird im Folgenden als App2App-Kommunikation bezeichnet (siehe [RFC8252], Abschnitt "7.2. Claimed "https" Scheme URI Redirection",  https://datatracker.ietf.org/doc/html/rfc8252#section-5). Die genaue Interaktionsform ist von den Spezifika des verwendeten Betriebssystems abhängig. 

9.2 Unterstützung Single-Sign-On (SSO)

Verwendet ein Nutzer innerhalb einer Anwendung mehrerer TI-Fachdienste, so möchte er sich nur einmalig authentisieren. Die Verwendung mehrerer Fachdienste nach einmaliger Authentisierung innerhalb einer Anwendung ist ein Single-Sign-On auf Anwendungsebene.    

Ein Beispiel für die Verwendung von SSO auf Anwendungsebene:

Der Nutzer bewegt sich in der APP seinem ePA-FdV (i.d.R. in der App seiner Krankenkassen). Neben den kassenspezifischen Funktionen bietet die APP auch Fachdienste der TI-Föderation wie ePA und TIM an. Möchte der Nutzer einen Fachdienst der TI-Föderation in der APP nutzen, so muss er sich gegenüber des sektoralen IDP der Krankenkasse authentisieren. Der Anwender möchte diesen Authentisierungsablauf nur einmal (z.B. beim Start der Anwendung) durchführen müsse (SSO auf Anwendungsebene).

Damit SSO auf Anwendungsebene genutzt werden kann, muss auch das Authenticator Modul des sektoralen IDP, über welchen sich der Nutzer authentifiziert, Teil der Anwendung sein. Aufrufe an das Authenticator Modul, wie sie in [gemSpec_IDP_Sek] Tabelle "Ablaufbeschreibung App-App-Flow" beschrieben sind, müssen für das auf Anwendungsebene beschränkte SSO innerhalb der Anwendung über API-Schnittstellen (statt wie in A_23084 beschrieben über Plattformmechanismen) erfolgen.

Hinweis: Dies ersetzt die Funktion nach A_23084* und A_23085*

10 Anhang A – Interaktionen mit Smartcards der TI

Das folgende Kapitel hat einen rein informativen Charakter und soll Hilfestellung beim Verständnis der Interaktion mit Smartcards der TI geben. Es ergeben sich aus den Beschreibungen keine normativen Anforderungen, welche umzusetzen wären. Normative Vorgaben aus referenzierten Dokumenten bleiben führend. Als Ziel soll hiermit ein grundsätzliches Verständnis der Abläufe vermittelt werden, welches eine Realisierung der Kommunikation des Authenticator-Moduls mit den Smartcards erleichtert. 

10.1 Einleitung

Zur Nutzung bestimmter Dienste der Telematikinfrastruktur ist eine Authentisierung der zugreifenden Person erforderlich. Dieses Dokument betrachtet ein Konzept für folgende User Story aus Kartensicht:

Ein Kartennutzer möchte eine eGK oder einen HBA über die kontaktlose Schnittstelle nutzen, um sich mittels Challenge- Response-Verfahren zu authentisieren. Soll die Challenge durch die SMC-B signiert werden, wird hierbei die Funktion "externalAuthenticate" des PTV-Konnektors verwendet, wenn sich die SMC-B im freigeschalteten Zustand befindet.

10.2 Grober Ablauf aus Kartensicht

Das Authenticator-Modul verwendet folgenden Ablauf, wobei hier nur Interaktionen mit der Karte dargestellt werden:

1. Von der Karte wird das zur Identität gehörende X.509-Zertifikat gelesen.
2. Es wird eine Nutzerauthentisierung durchgeführt.
3. Der zur Identität gehörende private Schlüssel wird zum Signieren einer Challenge genutzt. Die Signatur ist die zugehörige Response.

Aus Sicht einer eGK oder eines HBA stellt sich die User Story wie folgt dar (siehe Abbildung "Überblick zum Ablauf"):

1. Der User bringt die Karte in das Feld eines NFC-Kartenlesers. Dadurch bootet die Karte und es wird ein Kommunikationskanal etabliert.
2. Das Authenticator-Modul etabliert einen PACE-Kanal zur Karte.
3. Das Authenticator-Modul ermittelt den Kartentyp.
4. Das Authenticator-Modul wählt den privaten Schlüssel der zu verwendenden Identität aus.
5. Das Authenticator-Modul liest das X.509-Zertifikat aus.
6. Das Authenticator-Modul stößt eine Nutzerverifikation an.
7. Das Authenticator-Modul sendet ein Token zur Karte, welches von dieser signiert wird.
8. Dem Authenticator-Modul ist es möglich, beliebig viele weitere Token zur Karte zu schicken, um diese von der Karte signieren zu lassen.
9. Die Story endet damit, dass der User die Karte aus dem Feld des NFC-Kartenlesers entfernt, wodurch die Karte abgeschaltet wird.

Erläuterungen zu Abbildung "Überblick zum Ablauf": Betrachtet wird hier ein System, welches aus folgenden Komponenten besteht:

1. Auf einem mobilen Gerät (in Abbildung "Überblick zum Ablauf" nicht gezeigt) ist eine Software installiert, welche (unter anderem) das Authenticator-Modul enthält.
2. Das Authenticator-Modul greift mit Hilfe diverser Komponenten des mobilen Gerätes via NFC-Schnittstelle auf eine Karte mit kontaktloser Schnittstelle zu.
3. Die Karte mit kontaktloser Schnittstelle wird in Abbildung 8 mit PICC (Proximity Integrated Circuit Card) bezeichnet.
4. Das Authenticator-Modul wird (ganz grob) in folgende zwei Komponenten unterteilt:
5. 1. "Secure Messaging Layer", eine Komponente, welche einen PACE-Kanal zur PICC etabliert und dann für eine kryptographisch gesicherte Kommunikation verantwortlich ist.
   2. "other", der Rest des Authenticator-Moduls, der nicht zur Komponente Secure Messaging Layer gehört.
      

Abbildung 8: Überblick zum Ablauf

10.3 Ablauf im Detail

Die folgenden Unterkapitel schildern den Ablauf zum Signieren einer Challenge im Detail. Ziel der Darstellung in diesem Kapitel ist es, dass ein Entwickler in die Lage versetzt wird, auf Basis dieser Beschreibung (plus den Informationen aus verlinkten Dokumenten) die auf der kontaktlosen Nutzung von Smartcards der TI basierten Funktionen eines Authenticator-Moduls zu entwickeln.

10.3.1 Aufbau eines Kommunikationskanals zwischen Authenticator-Moduls und PICC

Wie ein Kommunikationskanal zwischen Authenticator-Modul und der PICC etabliert wird, hängt von der Hard- und Software des Gerätes ab, auf welchem das Authenticator-Modul läuft und mit welchem die PICC verbunden wird.

10.3.2 Aufbau eines PACE-Kanals

Nach Aufbau eines Kommunikationskanals ist das Authenticator-Modul in der Lage, Kommandonachrichten an die PICC zu senden und korrespondierende Antwortnachrichten von dort zu empfangen. Da es sich bei NFC um eine Funkschnittstelle handelt, ist mit der Möglichkeit zu rechnen, dass Angreifer die Kommunikation belauschen oder beeinflussen. Aus Sicherheitsgründen sind Karten der TI so konfiguriert, dass sie (von wenigen Ausnahmen abgesehen) Funktionen über die kontaktlose Schnittstelle nur im Rahmen einer kryptographisch gesicherten Verbindung bereitstellen. Dem Stand der Technik entsprechend wird dabei PACE eingesetzt.

PACE (Password Authenticated Connection Establishment) bietet die Möglichkeit, selbst mit schwachen Passwörtern einen kryptographisch starken Kommunikationskanal zu etablieren. Das PACE-Protokoll wird kurz in [gemSpec_COS#15.4.2] beschrieben. Die dortige Beschreibung geht auf [TR-03110] zurück.

Der Aufbau eines PACE-Kanals gliedert sich grob in zwei Phasen:

1. Auswahl eines gemeinsamen Satzes von Parametern
2. Ablauf des PACE-Authentisierungsprotokolls

Anschließend sind beide Kommunikationspartner im Besitz starker kryptographischer Schlüssel, mit deren Hilfe sie die weitere Kommunikation absichern.

10.3.2.1 Auswahl eines gemeinsamen Satzes von Parametern

In [TR-03110] sind mehrere Varianten beschrieben, mittels eines (schwachen) Passwortes starke kryptographische Schlüssel zu vereinbaren. Drei dieser Varianten sind in [gemSpec_COS] verpflichtend enthalten. Welche Variante eine Karte der TI konkret unterstützt, ist in der Datei EF.CardAccess konform zu [TR-03110] codiert.

Eine allgemeine Funktion zum Aufbau eines PACE-Kanals würde die Daten aus EF.CardAccess auswerten. Derzeit wird in [gemSpec_eGK_ObjSys], [gemSpec_HBA_ObjSys] und [gemSpec_HBA_ObjSys_G2.1] nur genau eine PACE-Variante verwendet. Zudem ist zu erwarten, dass die derzeit verwendete Variante mindestens bis zum Jahre 2026 verwendet wird. Deshalb wird hier folgende Empfehlung für die Implementierung des Authenticator-Moduls ausgesprochen:

Das Authenticator-Modul verwendet die PACE-Variante "id-PACE-ECDH-GM-AES-CBC-CMAC-128" und den Schlüssel SK.CAN mit der Schlüsselreferenz keyRef='02'.

Die verwendete PACE-Variante legt unter anderem die Domainparameter der zu verwendenden elliptischen Kurve fest.

10.3.2.2 Auswahl des passenden Schlüssels in der Karte

Vor dem Durchlauf des PACE-Protokolls ist auf der PICC der zugehörige Schlüssel SK.CAN auszuwählen. Dies geschieht mittels des Manage Security Environment Kommandos gemäß [gemSpec_COS#(N102.448)] mit den Parametern OID und keyRef gemäß der in 10.3.2.1 Auswahl eines gemeinsamen Satzes von Parametern ausgewählten PACE-Variante. Gemäß der dort gegebenen Empfehlung gilt also:

• OID = " id-PACE-ECDH-GM-AES-CBC-CMAC-128" und
• keyRef='02'.

Falls die PICC auf dieses Kommando NICHT mit dem Trailer '9000' = NoError antwortet, ist die PICC zu keiner der im Literaturverzeichnis aufgelisteten Objektsystemspezifikationen konform. In diesem Fall wird empfohlen, den Use Case abzubrechen.

10.3.2.3 Ablauf des PACE-Authentisierungsprotokolls

Der Ablauf des PACE-Authentisierungsprotokolls ist in [gemSpec_COS#CosA_8da] beschrieben. In der dortigen Abbildung sind drei Komponenten zu sehen, die wie folgt mit den Komponenten aus der unteren Abbildung "Sequenzdiagramm PACE-Authentisierung" korrespondieren:

Tabelle 7: Zusammenhang CosA_8da mit der folgenden Abbildung

Abbildung 9: Sequenzdiagramm PACE-Authentisierung

Die PICC ist mit einer CAN (Card Access Number) ausgestattet. Die CAN ist auf dem Kartenkörper aufgedruckt. (Für die eGK siehe gemSpec_eGK_Opt - z.B. Abb_eGKOPT_5. Für den HBA gibt es keine Vorgaben der gematik zum Layout, mit Card-G2-A_2038 nur eine Pflicht der Bedruckung). Die Komponente "Secure Messaging Layer" benötigt die CAN, um das PACE-Protokoll erfolgreich zu durchlaufen. Typischerweise wird die CAN einmalig vom Karteninhaber eingegeben. Es ist aber auch eine automatische Erkennung der CAN (etwa per Kamera) denkbar. Hier wird davon ausgegangen, dass der "Secure Messaging Layer" eine Komponente ist, die durch Übergabe der CAN zum Durchlaufen des PACE-Protokolls angestoßen wird.

Im Gutfall wird das PACE-Protokoll erfolgreich durchlaufen und im "Secure Messaging Layer" wurden dabei dieselben kryptographischen Schlüssel etabliert wie in der PICC.

Im Schlechtfall scheitert einer der im Folgenden beschriebenen Schritte. Dann ist davon auszugehen, dass die aktuelle PICC nicht in der Lage ist, ein Token zu signieren. Gründe für das Scheitern umfassen unter anderem:

1. Die im "Secure Messaging Layer" verwendete CAN stimmt nicht mit der CAN überein, die in der PICC gespeichert ist.
2. Bei der PICC handelt es sich weder um eine eGK noch um einen HBA.

Im Folgenden werden die Nachrichten genauer beschrieben, die zwischen "Secure Messaging Layer" und PICC ausgetauscht werden.

Der "Secure Messaging Layer" erzeugt ein ephemeres Schlüsselpaar (~SK1.PCD, ~PK1.PCD), Details dazu in [gemSpec_COS#(N085.066)a.4].

Message 1: Der "Secure Messaging Layer" sendet ein General Authenticate Kommando gemäß [gemSpec_COS#(N106.550)a] zur PICC.

Message 2: Die Antwortdaten der PICC enthalten das Kryptogramm z.

Der "Secure Messaging Layer" errechnet mittels CAN und z die Zahl s gemäß [gemSpec_COS#(N085.066)b].

Message 3: Der "Secure Messaging Layer" sendet ein General Authenticate Kommando gemäß [gemSpec_COS#(N106.552)a] zur PICC, welches ~PK1.PCD enthält.

Message 4: Die Antwortdaten der PICC enthalten das Kryptogramm ~PK1.PICC.

Der "Secure Messaging Layer" errechnet mittels der Zahl s, dem Schlüssel ~SK1.PCD und ~PK1.PICC gemäß [gemSpec_COS#(N085.066)c] ephemere Domainparameter ~D und ein weiteres ephemeres Schlüsselpaar (~SK2.PCD, ~PK2.PCD).

Message 5: Der "Secure Messaging Layer" sendet ein General Authenticate Kommando gemäß [gemSpec_COS#(N106.556)] zur PICC, welches ~PK2.PCD enthält.

Message 6: Die Antwortdaten der PICC enthalten den Schlüssel ~PK2.PICC.

Der "Secure Messaging Layer" errechnet mittels ~D, SK2.PCD und ~PK2.PICC gemäß [gemSpec_COS#(N085.066)d] Sessionkeys k.MAC und k.ENC, sowie den MAC T.PCD.

Message 7: Der "Secure Messaging Layer" sendet ein General Authenticate Kommando gemäß [gemSpec_COS#(N106.560)] zur PICC, welches T.PCD enthält.

Message 8: Die Antwortdaten der PICC enthalten den MAC T.PICC

Der "Secure Messaging Layer" überprüft T.PICC gemäß [gemSpec_COS#(N085.066)e].

Falls kein Fehler auftrat, wird die Routine zum Etablieren des PACE-Kanals erfolgreich beendet. Damit liegen in der Komponente "Secure Messaging Layer" Sessionkeys vor. Die weitere Beschreibung geht davon aus, dass alle Kommandonachrichten des Authenticator-Moduls über die Komponente "Secure Messaging Layer" gesendet werden. Die Komponente "Secure Messaging Layer" schützt dabei Kommandonachrichten mit "Secure Messaging" gemäß [gemSpec_COS#13.2]. Die von der PICC empfangenen Antwortnachrichten sind kryptographisch gemäß [gemSpec_COS#13.3] geschützt und der "Secure Messaging Layer" prüft und entschlüsselt die Antwortnachrichten der PICC so, dass sie im Klartext und in der in [gemSpec_COS#14] beschriebenen Form zur Verfügung gestellt werden.

Es wird empfohlen, dass nach Aufbau des PACE-Kanals das Masterfile (MF) gemäß [gemSpec_COS#(N040.800)] selektiert wird. Wenn die PICC dieses Kommando erfolgreich durchgeführt hat, dann ist die PICC zuverlässig in einem Zustand, mit dem im Folgenden weitergearbeitet werden kann.

10.3.3 Ermitteln des Kartentyps

In der vorliegenden Dokumentversion dieser Spezifikation gilt die hier beschriebene Ermittlung des Kartentyps, der in [gemSpec_eGK_ObjSys_G2.1], [gemSpec_HBA_ObjSys] und [gemSpec_HBA_ObjSys_G2.1] definiert ist. Andere Kartentypen der TI (derzeit sind das SMC-B, gSMC-K und gSMC-KT) unterstützen das kontaktlose Interface nicht und werden hier nicht betrachtet.

Unter anderem gibt es folgende Möglichkeiten, den Kartentyp für die hier relevanten Karten zu ermitteln:

1. Auslesen des ersten Rekords von EF.DIR gemäß [gemSpec_COS#(N066.100)].
2. 1. Vorteil: Die Antwortdaten sind kurz und weisen eindeutig auf den Kartentyp hin.
   2. Nachteil: Daten aus der Datei EF.DIR lassen sich über die kontaktlose Schnittstelle nur nach Aufbau eines PACE-Kanals auslesen.
3. Selektieren des Masterfiles (MF) ohne Applikation Identifier (AID) und Rückgabe der File Control Parameter (FCP) gemäß [gemSpec_COS#(N041.300)]. In diesem Fall ergäbe sich der Kartentyp aus dem Attribut AID, welches Teil der FCP ist.
4. 1. Vorteil: Funktioniert immer und über die kontaktlose Schnittstelle auch ohne PACE.
   2. Nachteile:
   3. 1. Die FCP-Daten sind je nach Implementierung sehr umfangreich und es ist möglich, dass zum vollständigen Empfang "extended length" erforderlich ist, weil die FCP-Daten mehr als 256 Byte umfassen. Das Feature "extended length" war zumindest in der Vergangenheit für mobile Endgeräte problematisch.
      2. Die FCP-Daten werden als BER-TLV-Struktur ausgegeben. Es erscheint nicht vorteilhaft, nur für die Interpretation der FCP-Daten einen BER-TLV-Parser zu implementieren.
5. Selektieren des Masterfiles (MF) mit Applikation Identifier (AID) gemäß [gemSpec_COS#(N040.800)], wobei dabei die applicationIdentifier Werte für eGK und HBA im Rahmen einer "Trial and Error"-Vorgehensweise durchzuprobieren wären. Die Karte antwortet entweder mit '6A82'=FileNotFound (Kartentyp und gewählter Wert von applicationIdentifier passen nicht zusammen) oder mit '900'=NoError (Kartentyp und gewählter Wert von applicationIdentifier passen zusammen).
6. 1. Vorteil: Funktioniert immer und über die kontaktlose Schnittstelle auch ohne PACE.
   2. Nachteil: "Trial and Error" verschlechtert die Performance, falls viele Versuche erforderlich sind.

Empfehlung: Erst nach Aufbau des PACE-Kanals ist eine kryptographisch gesicherte und damit zuverlässige Kommunikation möglich. Deshalb wird empfohlen, den Kartentyp durch Auslesen des ersten Rekords von EF.DIR zu ermitteln.

Abbildung 10: Ablauf zur Ermittlung des Kartentyps

Die Kommando-Application Protocol Data Unit (APDU) gemäß [gemSpec_COS#(N066.100) lautet in diesem Fall konkret: '00 B2 01F4 00'.

Die Antwort-APDU enthält (im Erfolgsfall) Daten und einen Trailer: Fallunterscheidung: Falls

1. die Daten gleich '61094F07D2760001448000' sind, handelt es sich um eine eGK und der Trailer der Antwort-APDU ist irrelevant.
2. die Daten gleich '61084F06D27600014601' sind, handelt es sich um einen HBA und der Trailer der Antwort-APDU ist irrelevant.
3. der Trailer gleich '9000' = NoError ist und die Daten keinen der vorgenannten Werte enthalten, dann handelt es sich weder um eine eGK noch um einen HBA.
4. der Trailer gleich '6281' = CorruptDataWarning ist, dann wurden die Daten in der PICC möglicherweise verfälscht. Dieser Fall tritt äußerst selten auf. Falls entschieden wird, mit so einer PICC trotzdem weiter zu arbeiten, dann wird empfohlen, anhand der Länge und des Inhaltes der Daten zu entscheiden, mit welchem Wert der unterstützten Kartentypen die vorliegenden Daten die größere Ähnlichkeit aufweisen.

Nach Interpretation der Antwort-APDU entscheidet das Authenticator-Modul, ob eine eGK, ein HBA oder ein unbekannter (nicht unterstützter) Kartentyp vorliegt.

10.3.4 Auswahl des privaten Schlüssels

Für den Kartentyp eGK sind private Schlüssel sowohl auf RSA-Basis als auch auf Basis elliptischer Kurven verfügbar. Dasselbe gilt für den Kartentyp HBA basierend auf [gemSpec_HBA_ObjSys_G2.1]. Lediglich für den Kartentyp HBA basierend auf [gemSpec_HBA_ObjSys] steht nur RSA-Kryptographie zur Verfügung.

Gemäß [TR–03116-1#3.2] ist die Moduluslänge von 2048 Bit für RSA-Schlüssel nur bis Ende 2023 zulässig. Deshalb wird empfohlen, – sofern vorhanden – Schlüssel basierend auf elliptischen Kurven einzusetzen.

Nach dem bis hierher beschriebenen Ablauf aus 10.3.2 Aufbau eines PACE-Kanals und 10.3.3 Ermitteln des Kartentyps liegt zwar der Kartentyp fest, nicht aber die Information, ob es sich um einen HBA gemäß [gemSpec_HBA_ObjSys] oder [gemSpec_HBA_ObjSys_G2.1] handelt. Unter anderem gibt es folgende Möglichkeiten herauszufinden, ob ein vorliegender HBA Schlüssel basierend auf elliptischen Kurven unterstützt:

1. Selektieren des ELC-Schlüssels, falls das gelingt, sind solche Schlüssel vorhanden.
2. 1. Vorteil: Einfach.
   2. Nachteil: "Trial and Error"-Methode. In 10.3.3 Ermitteln des Kartentyps wurde davon abgeraten, weil es einfache Ersatzmöglichkeiten gibt.
3. Auslesen von EF.ATR und Interpretieren des Inhaltes, hier Produktidentifikation des initialisierten Objektsystems.
4. 1. Vorteil: Eindeutige Aussage.
   2. Nachteil: Aufwendige Interpretation der BER-TLV-Strukturen.
5. Auslesen von EF.Version2 und interpretieren des Inhaltes, hier Produkttypversion des aktiven Objektsystems.
6. 1. Vorteil: Eindeutige Aussage.
   2. Nachteil: Aufwendige Interpretation der BER-TLV-Strukturen.

Zur Vereinfachung der Implementierung wird folgende Vorgehensweise empfohlen: Falls im Ablauf gemäß 10.3.3 Ermitteln des Kartentyps als Kartentyp ermittelt wurde

1. eGK, dann wird keyRef='82' und algId='00' verwendet →PrK.CH.AUT.E256, signECDSA.
2. HBA, dann wird keyRef='86' und algId='00' verwendet →PrK.HP.AUT.E256, signECDSA.
3. HBA und die Selektion des privaten Schlüssels mit keyRef='86' schlägt fehl, dann wird keyRef='82' und algId='05' verwendet →PrK.CH.AUT.R2048, signPSS.

Abbildung 11: Ablauf zur Selektion des privaten Schlüssels

Vor der Selektion des privaten Schlüsselobjektes ist zunächst die passende Anwendung auf der PICC zu selektieren, in diesem Fall das DF.ESIGN. Die Kommando-APDU gemäß [gemSpec_COS#(N042.700)] lautet in diesem Fall (sowohl für eGK als auch für HBA): '00 A4 040C 0A A000000167455349474E'. Die zugehörige Antwort-APDU enthält lediglich "trailer_1". Falls "trailer_1" ungleich '9000' = NoError ist, dann handelt es sich weder um eine eGK noch um einen HBA.

Nach Selektion der Anwendung DF.ESIGN wird gemäß der Empfehlung der private Schlüssel gemäß [gemSpec_COS#(N102.900)] selektiert. Die Kommando APDU lautet dann:

Die zugehörige Antwort APDU enthält lediglich "trailer_2". Falls "trailer_2" gleich '9000' = NoError ist, dann wurde der private Schlüssel erfolgreich selektiert. Falls "trailer_2" ungleich '9000' ist, dann enthält die Anwendung DF.ESIGN keinen privaten Signaturschlüssel mit der angegebenen keyRef und algId.

10.3.5 Lesen des X.509-Zertifikates

Das zum privaten Schlüsselobjekt zugehörige X.509-Zertifikat enthält Informationen, die für die Validierung einer Signatur erforderlich sind. Deshalb ist die Kenntnis des X.509-Zertifikates signifikant. Die Informationsmenge im X.509-Zertifikat ist so groß (bis zu 1.900 Byte), dass sie nicht bei allen zulässigen Implementierungen mit einem einzigen Kommando aus der PICC auslesbar ist. Hinzu kommt, dass es für mobile Geräte eine Obergrenze in der Datenmenge gibt, die im Rahmen eines Kommando-Antwortpaares austauschbar ist. Für das Auslesen des X.509-Zertifikates sind also zwei Puffergrößen relevant:

1. Puffergröße der PICC: Der Wert der Puffergröße ließe sich aus der Datei EF.ATR auslesen.
2. Puffergröße des mobilen Endgerätes: Es ist nicht bekannt, wie dieser Wert sicher zu ermitteln wäre.

Empfehlung: Es wird empfohlen, beim Auslesen des X.509-Zertifikates eine Blockgröße von 223 zu wählen. Damit ist die Größe einer gesicherten Antwortnachricht kleiner als 256 Byte. Der Wert von 256 Byte erscheint ein sicherer Wert für die Puffergröße mobiler Endgeräte. Dieser Wert ist erheblich kleiner als die 1033 Byte, die gemäß [gemSpec_COS#(N029.890)a.4] mindestens zu unterstützen sind.

Alles in allem wird das X.509-Zertifikat also in mehreren Blöcken zu je (empfohlenen) 223 Byte gelesen. Dabei ist zu unterscheiden zwischen dem ersten Lesekommando und allen weiteren Lesekommandos. Es wird empfohlen, im ersten Lesekommando gemäß [gemSepc_COS#(N051.500)], also Read Binary-Kommando und mit shortFileIdentifier vorzugehen. Alle weiteren Lesekommandos verwenden [gemSpec_COS#(N051.100)], also Read Binary-Kommando ohne shortFileIdentifier.

Im ersten Lesekommando wird offset = 0 gewählt. Bei allen weiteren Lesekommandos (im Sinne einer do-while-Schleife) wird der offset auf die Anzahl der bislang ausgelesenen Byte gesetzt. Die do-while-Schleife bricht ab, wenn die Antwortnachricht auf ein Lesekommando keine Antwortdaten mehr erhält, sondern nur noch den obligatorischen Trailer. Welchen Wert dieser Trailer hat, ist für den weiteren Verlauf irrelevant, sofern die bis dahin ausgelesenen Daten (konkateniert) ein valides X.509-Zertifikat ergeben. Die Validierung des X.509-Zertifikates ist nicht Gegenstand dieses Dokumentes.

Abbildung 12: Ablauf zum Auslesen des X.509-Zertifikates

Das erste Lesekommando wählt gleichzeitig die zu lesende Datei aus. Deshalb enthält das erste Lesekommando einen shortFileIdentifier. Der shortFileIdentifier ist in Abhängigkeit vom Kartentypen gemäß 10.3.3 Ermitteln des Kartentyps und des ausgewählten privaten Schlüssels gemäß 10.3.4 Auswahl des privaten Schlüssels zu wählen.

Tabelle 8: Auswahl des shortFileIdentifier

Für die weiteren Lesekommandos ist ein offset zu wählen, der gleich der Anzahl N der bislang ausgelesenen Bytes entspricht. N in hexadezimaler Darstellung besteht aus einem most-significant-byte MSByte_N und einem least-significant-byte LSByte_N. Die folgende Tabelle zeigt die (ungesicherte) Kommando APDU für alle weiteren Lesekommandos (diese sind unabhängig vom Kartentyp und unabhängig vom ausgewählten privaten Schlüsselobjekt):

Tabelle 9: Kommando APDU für Lesekommandos

Aus dem obigen Text und Abbildung 12 geht die Empfehlung hervor, die Schleife dann abzubrechen, wenn die Antwortnachricht keine Daten (oder, was dasselbe ist, leere Daten) enthält. Diese Vorgehensweise hat den Vorteil, dass der Wert des Trailers irrelevant ist. Typischerweise wird bei dieser Vorgehensweise ein Kommando zu viel geschickt. Falls die Anzahl an Bytes im X.509-Zertifikat kein Vielfaches der Blockgröße (hier 223) ist, dann gibt die PICC im Trailer anfangs '9000' = NoError zurück, dann bei vorhandenen Daten (also Anzahl Bytes in data_x größer null) '6282' = EndOfFileWarning, und wenn dann doch noch weiter gelesen wird '6B00' = OffsetTooBig zurück. Für den (eher untypischen) Fall, dass die Anzahl Bytes im X.509-Zertifikat ein Vielfaches der gewählten Blockgröße ist, wird nie '6282' = EndOfFileWarning gemeldet. Eine Implementierung, welche mit der minimalen Anzahl an Lesebefehlen auskommen will, hat dies zu berücksichtigen.

Weil das auszulesende X.509-Zertifikat als ASN.1-Codierung vorliegt, ist es möglich, die genaue Anzahl der Bytes durch Analyse der ersten ausgelesenen Bytes zu ermitteln. Es erscheint nicht sinnvoll, diesen Aufwand zu treiben.

10.3.6 Benutzerverifikation

Die Verwendung des privaten Schlüsselobjektes ist erst nach einer Benutzerverifikation möglich. Es wird empfohlen, die Benutzerverifikation erst nach Validierung des X.509-Zertifikates durchzuführen, weil eine Benutzerverifikation bei nicht validem X.509-Zertifikat überflüssig erscheint. Für die im Rahmen dieses Dokumentes betrachteten privaten Schlüsselobjekte ist die Benutzerverifikation nach einem Aktivieren der PICC nur genau einmal notwendig. Anschließend lassen sich die hier behandelten privaten Schlüsselobjekte beliebig oft verwenden.

Für die Benutzerverifikation ist dem Authenticator-Modul das Geheimnis (also die PIN) bekanntzugeben. Typischerweise wird die PIN vom Benutzer eingegeben. Für die Benutzerverifikation ist die Zahlenfolge der PIN in einen Format-2-PIN-Block gemäß [gemSpec_COS#(N008.100)] umzuwandeln. Die folgende Tabelle enthält einige Beispiele für eine derartige Umwandlung.

Tabelle 10: Beispielhafte Umwandlungen einer PIN

Abbildung 13: Ablauf zur Verifikation des Benutzers

Für die Benutzerverifikation ist nur eine Kommandonachricht erforderlich. Welches Passwortobjekt dabei verwendet wird, hängt vom Kartentyp ab.

Tabelle 11: Passwortobjekt in Abhängigkeit des Kartentyps

Falls die Antwort-APDU den Trailer '9000' = NoError enthält, lassen sich mit dem privaten Schlüsselobjekt Signaturen erstellen.

10.3.7 Signieren

Typischerweise sind per digitaler Signatur geschützten Artefakte mitunter sehr groß (etwa einige Megabyte oder auch Gigabyte). Wegen der begrenzten Bandbreite ist es nicht sinnvoll, die kompletten Artefakte zu einer Karte zu übertragen. Technisch bedeutet dies, dass der Signaturvorgang arbeitsteilig abläuft. Sicherheitstechnisch unbedenkliche Operationen laufen außerhalb der Karte ab und nur die sicherheitskritischen Operationen werden in der Karte ausgeführt. Dazu wird an der Schnittstelle zur Karte ein Zwischenergebnis der Signaturberechnung übergeben.

10.3.7.1 Signaturen mit dem Algorithmus signPSS = RSASSA-PSS

Der Algorithmus signPSS = RSASSA-PSS ist in [PKCS #1] Kapitel 8.1.1 beschrieben. Dabei wird die zu signierende Nachricht M zunächst gemäß EMSA-PSS-Encode codiert. Das Codierverfahren EMSA-PSS-Encode ist in [PKCS #1] Kapitel 9.1.1 beschrieben. Außerhalb der Karte werden dabei die Schritte gemäß [PKCS #1] Kapitel 9.1.1 Steps 1 und 2 mit dem Hash-Algorithmus SHA-256 durchgeführt. Als Ergebnis liegt der Hashwert mHash vor, der in 10.3.7.3 Signiervorgang weiterverarbeitet wird.

10.3.7.2 Signaturen mit dem Algorithmus signECDSA

Der Algorithmus signECDSA ist in [TR–03111#4.2.1.1] beschrieben. Dort wird in Actions 5 der Hashwert H_t(M) verwendet. Im vorliegenden Fall ist dieser Wert wie folgt zu berechnen: H_t(M) = mHash = SHA-256 Hashwert der Nachricht M. Als Ergebnis liegt der Hashwert mHash vor, der in 10.3.7.3 Signiervorgang weiterverarbeitet wird.

10.3.7.3 Signiervorgang

Eine Nachricht challenge wird signiert. Hier wird davon ausgegangen, dass dem Authenticator-Modul die zu signierende Nachricht challenge übergeben wird. Zunächst berechnet das Authenticator-Modul gemäß 10.3.7.1 Signaturen mit dem Algorithmus signPSS = RSASSA-PSS oder 10.3.7.2 Signaturen mit dem Algorithmus signECDSA den SHA-256 Hashwert zu challenge gemäß mHash = SHA-256(challenge).

Abbildung 14: Ablauf eines Signaturvorgangs

Für den Signaturvorgang ist nur eine Kommando-APDU erforderlich: '00 2A 9E9A 20 mHash00'.

Falls die Antwort-APDU Daten enthält (response also nicht leer ist), dann war der Signaturvorgang erfolgreich.

11 Anhang B – Verzeichnisse

11.1 Abkürzungen

11.2 Glossar

Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.

11.3 Abbildungsverzeichnis

11.4 Tabellenverzeichnis

11.5 Referenzierte Dokumente

11.5.1 Dokumente der gematik

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

11.5.2 Weitere Dokumente

Die weiteren zu beachtenden Dokumente sind folgender Tabelle zu entnehmen.