Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation der elektronischen Gesundheitskarte
eGK-Objektsystem

    

     

      
Version
      
4.7.1
     
     

      
Revision
      
908256
     
     

      
Stand
      
17.05.2024
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_eGK_ObjSys_G2.1
     
    

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

1.1 Zielsetzung

Dieses Dokument spezifiziert die anwendungsspezifischen Strukturen der elektronischen Gesundheitskarte (eGK) und beschreibt die Strukturen der Anwendungen, die bei der Initialisierung und Personalisierung in die eGK geladen werden. Außerdem werden in diesem Teil die Zugriffsrechte auf Elemente der eGK festgelegt.

Die Spezifikation behandelt Anwendungen der eGK unter den folgenden, rein kartenorientierten Gesichtspunkten:

• Ordnerstruktur
• Dateien
• Sicherheitsmechanismen wie Zugriffsregeln.

Somit stellt dieses Dokument auf unterster technischer Ebene eine Reihe von Datencontainern bereit, die etwa mit Versichertenstammdaten, Notfalldaten etc. befüllbar sind. Zudem werden hier die Sicherheitsmechanismen für diese Datencontainer festgelegt, d. h. es wird festgelegt, welchen Instanzen es unter welchen Voraussetzungen möglich ist, auf Inhalte der Container zuzugreifen. Die Semantik und die Syntax der Inhalte in Datencontainern ist dagegen nicht Gegenstand dieses Dokumentes (siehe dazu auch 1.4).

1.2 Zielgruppe

Das Dokument richtet sich an:

• Hersteller, welche die hier spezifizierten Anwendungen herstellerspezifisch für ein bestimmtes Chipkartenbetriebssystem umsetzen
• Kartenherausgeber, die anhand der hier spezifizierten Anwendungen die
  elektrische Personalisierung einer eGK planen
• Hersteller von Systemen, die Programme entwickeln, welche unmittelbar mit der Chipkarte kommunizieren.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungsverfahren werden durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, 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 Abgrenzung des Dokuments

Die Basiskommandos, die Grundfunktionen des Betriebssystems sowie die grundlegenden Sicherheitsfunktionen und -algorithmen (hard facts) für alle Karten des Gesundheitswesens (eGK, HBA, SMC-B, gSMC-K, gSMC-KT) werden in der Spezifikation des Card Operating System (COS) detailliert beschrieben [gemSpec_COS]. Diese Spezifikation ist Grundlage der Entwicklung der Kommandostrukturen und Funktionen für die Chipkartenbetriebssysteme. Der Teil „Äußere Gestaltung“ [gemSpec_eGK_OPT] beschreibt die äußere Gestaltung der eGK.

1.5 Methodik

1.5.1 Nomenklatur

In [gemSpec_COS] wurde ein objektorientierter Ansatz für die Beschreibung der Funktionalität des Betriebssystems gewählt. Deshalb wurde dort der Begriff "Passwortobjekt" verwendet, wenn Instanzen für eine Benutzerverifikation besprochen wurden. Da in diesem Dokument lediglich numerische Ziffernfolgen als Verifikationsdaten eines Benutzers verwendet werden, wird hier statt Passwortobjekt vielfach der Begriff PIN gewählt, wenn keine Gefahr besteht, dass es zu Verwechslungen kommt zwischen den Verifikationsdaten und der Instanz des Objektes, in denen sie enthalten sind (zur Erinnerung: ein Passwortobjekt enthält neben den Verifikationsdaten auch einen Identifier, eine Zugriffsregel, eine PUK, …).

Der Begriff "Wildcard" wird in diesem Dokument im Sinn eines "beliebigen, herstellerspezifischen Wertes, der nicht anderen Vorgaben widerspricht" verwendet.

Externe Authentisierung für CV-Zertifikate der Generation 1 mit einer Rolle CHA (informativ)

Gemäß [gemSpec_COS#10.2] wird die Notwendigkeit einer externen Authentisierung für Karten der Generation 1 mit einer Rolle CHA.1 wie folgt dargestellt: AUT(CHA.1). Wegen der häufigen ODER-Verknüpfung von Rollen in Zugriffsregeln, wird in diesem Dokument abweichend davon, aus Gründen der Übersichtlichkeit, folgende Notation synonym verwendet:

• C.1 entspricht Rollenauthentisierung mittels CV-Zertifikaten mit der Rolle CHA.1.
• C.1.2 entspricht Rollenauthentisierung mittels CV-Zertifikaten mit der Rolle CHA.1 oder (boolesches oder) CHA.2. In komplexeren Ausdrücken bindet dieses ODER genauso wie jedes andere ODER auch und damit schwächer als UND.

Die Zugriffsrechte in dieser Notation werden nur noch informativ in den Tabellen mit den Zugriffsrechten aufgeführt, um deutlich zu machen, welche Profile Zugriffsrechte haben. Diese Zugriffrechte werden in eGKs der Generation 2 nicht mehr umgesetzt, da zugreifende Karten (HBA, SMC-B) ausschließlich Generation 2-Karten sein werden.

Die Angabe dieser informativen Zugriffsrechte beschränkt sich aus Gründen der Übersichtlichkeit jeweils nur auf die Anteile der Zugriffsregel, die einem Profil zuzuordnen sind.

Beispiel:

Externe Authentisierung für CV-Zertifikate der Generation 2 mit einer Flaglist

Die in diesem Dokument referenzierten Flaglisten cvc_FlagList_CMS und cvc_FlagList_TI sind normativ in [gemSpec_PKI#Struktur  und Inhalt eines CV-Zertifikates für ELC-Schlüssel der Generation 2] und die dazugehörenden OIDs oid_cvc_fl_cms und oid_cvc_fl_ti sind normativ in [gemSpec_OID] definiert.

Gemäß [gemSpec_COS#(N022.400)] wird die Notwendigkeit einer externen Rollenauthentisierung für Karten der Generation 2 mit einer Flaglist wie folgt dargestellt: AUT(OID, FlagList) wobei OID stets aus der Menge {oid_cvc_fl_cms, oid_cvc_fl_ti} ist und FlagList ein sieben Oktett langer String, in welchem im Rahmen dieses Dokumentes genau ein Bit gesetzt ist. Abkürzend wird deshalb in diesem Dokument lediglich die Nummer des gesetzten Bits angegeben in Verbindung mit der OID. Ein gesetztes Bit i in Verbindung mit der oid_cvc_fl_cms wird im Folgenden mit flagCMS.i angegeben und ein gesetztes Bit j in Verbindung mit der oid_cvc_fl_ti wird im Folgenden mit flagTI.j angegeben.

Beispiele:

Für die Authentisierung der Zugriffe durch ein CMS oder ein VSDM auf die dafür vorgesehenen Objekte können entweder symmetrische Verfahren mit AES-Schlüsseln oder alternativ asymmetrische Verfahren mit CV-Zertifikaten verwendet werden. Für beide Verfahren sind die Schlüsselobjekte in dieser Spezifikation spezifiziert. Um die Zugriffsregeln für administrative Zugriffe in den einzelnen Tabellen übersichtlich darstellen zu können, werden folgende Abkürzungen verwendet:

In der obigen Tabelle, wie auch an anderen Stellen im Dokument, werden aus Gründen der besseren Lesbarkeit häufig mehrere Zugriffsarten zusammengefasst und dafür eine Zugriffsbedingung angegeben. Beispielsweise (Read, Update) nur, wenn SmMac(CAN) AND SmCmdEnc AND SmRspEnc. Dabei ist Folgendes zu beachten:

1. Für Kommandonachrichten ohne Kommandodaten ist der Term SmCmdEnc sinnlos.
2. Für Antwortnachrichten ohne Antwortdaten ist der Term SmRspEnc sinnlos.
3. Die Spezifikation ist wie folgt zu interpretieren:
1. Falls eine Kommandonachricht keine Kommandodaten enthält, ist es zulässig, den Term SmCmdEnc zu ignorieren, falls er in der Spezifikation vorhanden ist.
2. Falls eine Antwortnachricht keine Antwortdaten enthält, ist es zulässig, den Term SmRspEnc zu ignorieren, falls er in der Spezifikation vorhanden ist.
4. Für die Konformitätsprüfung eines Prüflings gilt bei der Beurteilung von Zugriffsbedingungen:
1. Falls für eine Zugriffsart keine Kommandodaten existieren, ist es für den Prüfling zulässig, in der zugehörigen Zugriffsregel den Term SmCmdEnc zu verwenden.
2. Falls für eine Zugriffsart keine Antwortdaten existieren, ist es für den Prüfling zulässig, in der zugehörigen Zugriffsregel den Term
   SmRspEnc zu verwenden.

An der Benutzerschnittstelle werden für Benutzergeheimnisse andere Bezeichnungen verwendet, als in technischen Dokumenten. Tab_eGK_ObjSys_001 listet die Zuordnung.

Tabelle 1: Tab_eGK_ObjSys_001: Zuordnung der Bezeichnungen für PINs

1.5.2 Verwendung von Schlüsselworten

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 innerhalb der Afo-ID und der Textmarke angeführten Inhalte.

Abwandlungen von „MUSS“ zu „MÜSSEN“ etc. sind der Grammatik geschuldet. Da im 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.

1.5.3 Komponentenspezifische Anforderungen

Da es sich beim vorliegenden Dokument um die Spezifikation einer Schnittstelle zwischen mehreren Komponenten handelt, ist es möglich, die Anforderungen aus der Sichtweise jeder Komponente zu betrachten. Die normativen Abschnitte tragen deshalb eine Kennzeichnung, aus wessen Sichtweise die Anforderung primär betrachtet wird.

Tabelle 2: Tab_eGK_ObjSys_002: Liste der Komponenten, an welche dieses Dokument Anforderungen stellt

2 Optionen

In den Kapiteln 5.3.12 und 5.3.13 sind die Objekte für die zwei verschiedenen Verfahren zur Absicherung der Kommunikation zwischen CMS/VSD und einer Karte beschrieben die bei der Ausgabe der Karte angelegt werden müssen.

3 Lebenszyklus von Karte und Applikation

Diese Spezifikation gilt nicht für die Vorbereitungsphase von Applikationen oder deren Bestandteile. Sie beschreibt lediglich den Zustand des Objektsystems in der Nutzungsphase.

Die Nutzungsphase einer Applikation oder eines Applikationsbestandteils beginnt, sobald sich ein derartiges Objekt, wie in der Spezifikation der Anwendung definiert, verwenden lässt. Die Nutzungsphase einer Applikation oder eines Applikationsbestandteils endet, wenn das entsprechende Objekt gelöscht oder terminiert wird.

Hinweis: Die in diesem Kapitel verwendeten Begriffe "Vorbereitungsphase" und "Nutzungsphase" werden in [gemSpec_COS#Lebenszyklus von Karte und Applikation (informativ)] definiert.

4 Anwendungsübergreifende Festlegungen

4.1 Unterstützung optionaler Funktionspakete

4.1.1 USB-Schnittstelle (optional)

4.1.2 Logische Kanäle (optional)

4.1.3 Kryptobox (optional)

Falls eine eGK die Option_Kryptobox nutzen will, MUSS für das Objektsystem ein COS verwendet werden, das die Option_Kryptobox implementiert hat.

4.1.4 RSA CV-Zertifikate (optional)

Falls eine eGK RSA CV-Zertifikate nutzen will, MUSS für das Objektsystem ein COS verwendet werden, das die Option_RSA_CVC implementiert hat.

4.1.5 Symmetrischer Kryptographiealgorithmus DES (optional)

Falls eine eGK den symmetrischen Algorithmus DES nutzen will, MUSS für das Objektsystem ein COS verwendet werden, das die Option_DES implementiert hat.

4.1.6 Onboard-RSA-Schlüsselgenerierung (optional)

4.2 Reservierung Speicherplatz

4.3 Attributstabellen

4.3.1 Attribute einer Datei (EF)

4.4 Zugriffsregeln für besondere Kommandos

4.5 Attributswerte und Personalisierung

Die in diesem Dokument festgelegten Attribute der Objekte berücksichtigen lediglich fachlich motivierte Use Cases. Zum Zwecke der Personalisierung ist es unter Umständen und je nach Personalisierungsstrategie erforderlich, von den in diesem Dokument festgelegten Attributswerten abzuweichen.

Beispielsweise ist es denkbar, dass für die Datei EF.GDO das Attribut lifeCycleStatus nach der Initialisierung auf dem in [gemSpec_COS] nicht normativ geforderten Wert „Initialize“ steht und für diesen Wert die Zugriffsregeln etwa ein Update Binary Kommando erlauben. In diesem Fall wiche nicht nur der Wert des Attributes lifeCycleStatus, sondern auch der des Attributes interfaceDependentAccessRules von den Vorgaben dieses Dokumentes ab. Nach Abschluss der Personalisierung wäre dann der Wert des Attributs lifeCycleStatus bei korrekter Personalisierung spezifikationskonform auf dem Wert „Operational state (activated)“ aber in interfaceDependentAccessRules fände sich für den Zustand „Initialize“ immer noch „Update Binary“. Im Rahmen einer Sicherheitsbetrachtung wäre diese Abweichung als unkritisch einzustufen, wenn sichergestellt ist, dass der Zustand „Initialize“ unerreichbar ist.

Denkbar wäre auch, dass die Personalisierung so genannte Ini-Tabellen und spezielle Personalisierungskommandos nutzt, die Daten, die mit dem Kommando übergeben werden, an durch die Ini-Tabelle vorgegebene Speicherplätze schreibt. In dieser Variante wären die Attribute von EF.GDO auf den ersten Blick konform zu dieser Spezifikation, obwohl durch das Personalisierungskommando ein Zugriff auf das Attribut body bestünde, der so eventuell nicht in den Zugriffsregeln sichtbar wird und damit gegen die allgemeine Festlegung „andere (Kommandos) NEVER“ verstieße. Im Rahmen einer Sicherheitsbetrachtung wäre diese Abweichung als unkritisch einzustufen, wenn sichergestellt ist, dass die Personalisierungskommandos nach Abschluss der Personalisierung irreversibel gesperrt sind.

Die folgende Anforderung ermöglicht herstellerspezifische Personalisierungsprozesse:

4.6 Wegfall der Personalisierung von RSA-Objekten

Gemäß [gemSpec_Krypt#G2-A_4357-*] sind RSA-Schlüssel mit einer Moduluslänge von 2048 bit nur zeitlich begrenzt einsetzbar. Danach ist es weiterhin zulässig, die in diesem Dokument spezifizierten RSA-Schlüssel und RSA-Zertifikatscontainer wie bisher mit Schlüsselmaterial und Zertifikaten zu befüllen. Allerdings ist das mit Aufwand und Kosten verbunden, dem kein Nutzen innerhalb der TI gegenübersteht. Deshalb werden Anforderungen zur Personalisierung so geändert, dass RSA-Artefakte nach der Personalisierung "leer" sind, das heißt im Rahmen der Personalisierung nicht befüllt werden.

In späteren Dokumentenversionen werden die RSA-Artefakte nicht mehr enthalten sein.

Im Vergleich zur vorherigen Dokumentenversion wurden die Personalisierungsvorschriften für RSA-Artefakte entfernt. Hier folgen nun Festlegungen, wie mit den weiterhin vorhandenen RSA-Artefakten im Rahmen der Personalisierung zu verfahren ist:

Hinweis: Um Fehlersituationen im Feld zu vermeiden, wird im Rahmen von Interoperabilitätstests nachgewiesen, dass die übrigen TI-Komponenten die geänderten Karten unterstützen. Ein verbindlicher Zeitplan zum Rollout für die betroffenen TI-Komponenten wird zeitnah festgelegt.

5 Spezifikation grundlegender Applikationen

Zu den grundlegenden Applikationen der elektronischen Gesundheitskarte (eGK) zählen:

• Das Wurzelverzeichnis der eGK, auch root oder Master File (MF) genannt,
• die Gesundheitsanwendung DF.HCA (Health Care Application) und
• die Krypto-Anwendung DF.ESIGN

Die QES-Anwendung gehört nicht zu den verpflichtenden Anwendungen einer eGK und wird deshalb in einem eigenen Kapitel 6 behandelt.

5.1 Attribute des Objektsystems

Das Objektsystem gemäß [gemSpec_COS#9.1] enthält folgende Attribute:

Hinweis: PuK.RCA.CS.E256 ist ein öffentlicher Schlüssel der CVC-Root-CA. Die CVC-Root-CA erzeugt alle zwei Jahre ein neues Schlüsselpaar. Deshalb ändert sich die Liste der relevanten Schlüssel PuK.RCA.CS.E256 regelmäßig. Die allgemeine Formulierung in A_22585 vermeidet in solchen Fällen eine Anpassung der Spezifikation. Detaillierte Informationen sind den Master-Dateien zu entnehmen, die im Rahmen der Kartenproduktzertifizierung eingesetzt werden.

Hinweis 1: Die oben angegebenen Werte von X leiten sich wie folgt her: Ohne die Option_lange_Lebensdauer ist es üblich, Kartenprodukte nach der Zulassung bis zu fünf Jahre auszugeben und nach der Ausgabe fünf Jahre zu betreiben. Die 2020 erzeugte CVC-Root-CA wurde erst Anfang 2022 veröffentlicht. Daraus folgt für eine Karte, die kurz vor der Veröffentlichung der 2020-CVC-Root-CA zugelassen und bis 2027 ausgegeben wurde und dann bis 2032 im Feld verbleibt, dass im ungünstigen Fall sieben weitere CVC-Root-CA per Link-Zertifikat nachzuladen sind: 2020, 2022, 2024, 2026, 2028, 2030, 2032. Analog gilt für Karten mit Option_lange_Lebensdauer bei einer angenommenen Laufzeitverlängerung von fünf Jahren (Zulassung Anfang 2022, Ausgabe bis 2027, Betrieb bis 2037): Zusätzlich zum vorherigen Beispiel kommen die Schlüssel aus den Jahren 2034 und 2036 hinzu. Der in X angegebene Wert berücksichtigt einen weiteren Schlüssel im Sinne eines Sicherheitspuffers.

Hinweis 2: Sollte ein asymmetrischer Schlüssel für Kartenadministration vorhanden und nutzbar sein (PuK.RCA.ADMINCMS.CS.E256), dann wird vermutlich auch dieser Schlüssel über die Nutzungsdauer erneuert oder ausgetauscht. Da es möglich ist, im Rahmen dieses Austausches abgelaufene Sicherheitsanker von der Karte zu löschen, ist für den Austausch von PuK.RCA.ADMINCMS.CS.E256 kein weiterer Platzbedarf in persistentPublicKeyList erforderlich.

Hinweis 1: A_22588 wird anhand von Beispielen verdeutlicht. Angenommen wird, dass zum Zeitpunkt der Personalisierung Sicherheitsanker aus folgenden Jahren existieren: 2016, 2018, 2020. Initialisiert sei nur der Sicherheitsanker aus dem Jahr 2016. Wenn sich das CV-Zertifikat in EF.C.CA.CS.E256 mit

(Beispiel 1) dem Sicherheitsanker aus dem Jahr 2016 prüfen lässt, dann ist diesbezüglich nichts weiter zu tun.

(Beispiel 2) dem Sicherheitsanker aus dem Jahr 2018 prüfen lässt, dann ist diesbezüglich der Sicherheitsanker aus dem Jahr  2018 nach persistentPublicKeyList zu personalisieren.

(Beispiel 3) dem Sicherheitsanker aus dem Jahr 2020 prüfen lässt, dann sind diesbezüglich die Sicherheitsanker aus dem Jahr 2018 und 2020 nach persistentPublicKeyList zu personalisieren.

Hinweis 2: Weitere Sicherheitsanker lassen sich jederzeit von jedermann mittels Link-Zertifikaten und dem Kommando PSO Verify Certificate in die persistentPublicKeyList einbringen.

5.1.1 Answer To Reset

5.2 Allgemeine Struktur

Abb_eGK_ObjSys_001 zeigt die allgemeine Struktur einer eGK auf oberster Ebene.

Abbildung 1: Abb_eGK_ObjSys_001 Objektstruktur einer eGK auf oberster Ebene

5.3 Root, die Wurzelapplikation (MF)

Das MF der eGK ist ein Ordner (siehe [gemSpec_COS#8.3.1]) mit den in Tab_eGK_ObjSys_006 gezeigten Eigenschaften.

Hinweis 2: Kommandos, die gemäß [gemSpec_COS] mit einem Ordnerobjekt arbeiten, sind: Activate, Deactivate, Delete, Fingerprint, Get Random, List Public Key, Load Application, Select, Terminate DF.

Hinweis 3: Da sich weder dieser Ordner noch darüberliegende Ebenen deaktivieren oder terminieren lassen, sind diese Zustände für Objekte im 5.3 im Allgemeinen irrelevant.

5.3.1 MF / EF.ATR

Die transparente Datei EF.ATR enthält Informationen zur maximalen Größe der APDU. Ferner dient sie zur Versionierung unveränderlicher Elemente einer Karte.

Hinweis 4: Kommandos, die gemäß [gemSpec_COS] mit einem transparenten EF arbeiten, sind: Activate, Deactivate, Delete, Erase Binary, Read Binary, Select, Update Binary, Set Logical Eof, Terminate, Write Binary.

Hinweis 5: Der Wert des Attributs fileIdentifier ist in [ISO7816-4] festgelegt.

5.3.2 MF / EF.CardAccess

EF.CardAccess wird für das PACE-Protokoll bei Nutzung der kontaktlosen Schnittstelle benötigt.

5.3.3 MF / EF.C.CA.CS.E256

Diese Datei enthält ein CV-Zertifikat für die Kryptographie mit elliptischen Kurven gemäß  [gemSpec_PKI, welches den öffentlichen Schlüssel PuK.CA.CS.E256 einer CA enthält. Dieses Zertifikat lässt sich mittels des öffentlichen Schlüssels PuK.RCA.CS.E256 (siehe Tab_eGK_ObjSys_023) prüfen.

Hinweis 6: Kommandos, die gemäß [gemSpec_COS] mit einem transparenten EF arbeiten, sind: Activate, Deactivate, Delete, Erase Binary, Read Binary, Select, Update Binary, Set Logical Eof, Terminate, Write Binary.

5.3.4 MF / EF.C.eGK.AUT_CVC.E256

Diese Datei enthält ein CV-Zertifikat für die Kryptografie mit elliptischen Kurven gemäß [gemSpec_COS, welches den öffentlichen Schlüssel PuK.eGK.AUT_CVC.E256 zu PrK.eGK.AUT_CVC.E256 (siehe Tab_eGK_ObjSys_020) enthält. Dieses Zertifikat lässt sich mittels des öffentlichen Schlüssels aus EF.C.CA.CS.E256 (siehe Tab_eGK_ObjSys_009) prüfen.

5.3.5 MF / EF.DIR

Die Datei EF.DIR enthält eine Liste mit Anwendungstemplates gemäß [ISO7816-4]. Diese Liste wird dann angepasst, wenn sich die Applikationsstruktur durch Löschen oder Anlegen von Anwendungen verändert.

Hinweis 7: Kommandos, die gemäß [gemSpec_COS] mit einem linear variablen EF arbeiten, sind: Activate, Activate Record, Append Record, Deactivate, Deactivate Record, Delete, Delete Record, Erase Record, Read Record, Search Record, Select, Terminate, Update Record, Write Record.

Hinweis 8: Die Werte von fileIdentifier und shortFileIdentifier sind in [ISO7816-4] festgelegt.

5.3.6 MF / EF.GDO

In EF.GDO wird das Datenobjekt ICCSN gespeichert, das die Kennnummer der Karte enthält. Die Kennnummer basiert auf [Resolution190].

Hinweis 9: Kommandos, die gemäß [gemSpec_COS] mit einem transparenten EF arbeiten, sind: Activate, Deactivate, Delete, Erase Binary, Read Binary, Select, Update Binary, Set Logical Eof, Terminate, Write Binary.

5.3.7 MF / EF.Version @deprecated

Wichtiger Hinweis:

Das Objekt EF.Version wird durch die vorliegende Spezifikation normativ gefordert, jedoch in zukünftigen Generationen des eGK-Objektsystems nicht mehr unterstützt. Es wird mit dieser Markierung „@deprecated“ gekennzeichnet. Es ist dann ausschließlich EF.Version2 zu verwenden (siehe auch entsprechende Erläuterung in [gemSpec_Karten_Fach_TIP_G2.1#EF.Version @deprecated]

Diese Datei enthält pro Record die Versionsnummer einer "Schnittstelle". Dabei werden folgende "Schnittstellen", besser gesagt folgende Ebenen unterschieden:

• Betriebssystem: Die "Schnittstelle" des Betriebssystems wird in [gemSpec_COS] spezifiziert. Dabei werden der grundsätzliche Funktionsumfang und der Aufbau der Nachrichten von und zur eGK festgelegt.
• Objektsystem: Die Konfiguration des Objektsystems wird in diesem Dokument spezifiziert. Damit wird für die fachliche Ebene festgelegt, wo Daten abgelegt sind und welche Zugriffsrechte die eGK durchsetzt.
• Fachliche Anwendung: Diese "Schnittstelle" beschreibt im Wesentlichen den Inhalt von Dateien, die im Rahmen fachlicher Anwendungen verwendet werden.

Hinweis 10: Kommandos, die gemäß [gemSpec_COS] mit einem linear fixen EF arbeiten, sind:
Activate, Activate Record, Append Record Deactivate, Deactivate Record, Delete, Delete Record, Erase Record, Read Record, Search Record, Select, Update Record, Terminate

5.3.8 MF / EF.Version2

Die Datei EF.Version2 enthält die Versionsnummern sowie Produktidentifikatoren grundsätzlich veränderlicher Elemente der Karte:

• Version des Produkttyps des aktiven Objektsystems (inkl. Kartenkörper)
• Herstellerspezifische Produktidentifikation der Objektsystemimplementierung
• Versionen der Befüllvorschriften für verschiedene Dateien dieses Objektsystems

Die konkrete Befüllung ist in [gemSpec_Karten_Fach_TIP_G2.1] beschrieben.

Elemente, die nach Initialisierung durch Personalisierung oder reine Kartennutzung nicht veränderlich sind, werden in EF.ATR versioniert.

Hinweis 11: Kommandos, die gemäß [gemSpec_COS] mit einem transparenten EF arbeiten, sind: Activate, Deactivate, Delete, Erase Binary, Read Binary, Select, Update Binary, Set Logical Eof, Terminate, Write Binary.

5.3.9 Passwortobjekte und Multireferenz-Passwortobjekte

5.3.9.1 MF / PIN.CH

Dieses reguläre Passwortobjekt wird zur Freischaltung von Schlüsseln und Inhalten der eGK verwendet. Dieses Passwortobjekt wird nur innerhalb der TI verwendet.

Hinweis 12: Kommandos, die gemäß [gemSpec_COS] mit einem Passwortobjekt arbeiten, sind: Activate, Change Reference Data, Deactivate, Delete, Disable Verification Requirement, Enable Verification Requirement, Get Pin Status, Reset Retry Counter, Verify, Terminate.

Hinweis 13: Die PIN.CH und alle Multireferenz-PINs können ohne Einschränkungen geändert werden.

5.3.9.2 MF / MRPIN.home

Dieses Multireferenz-Passwortobjekt wird zur Freischaltung von Schlüsseln und Inhalten der eGK verwendet. Dieses Passwortobjekt wird nur außerhalb der TI verwendet.

Hinweis 14: Kommandos, die gemäß [gemSpec_COS] mit einem Passwortobjekt arbeiten, sind: Activate, Change Reference Data, Deactivate, Delete, Disable Verification Requirement, Enable Verification Requirement, Get Pin Status, Reset Retry Counter, Verify, Terminate.

5.3.9.3 MF / MRPIN.NFD

Dieses Multireferenz-Passwortobjekt wird zur Freischaltung von Inhalten der Anwendung Notfalldatensatz verwendet.

Hinweis 15: Kommandos, die gemäß [gemSpec_COS] mit einem Passwortobjekt arbeiten, sind: Activate, Change Reference Data, Deactivate, Delete, Disable Verification Requirement, Enable Verification Requirement, Get Pin Status, Reset Retry Counter, Verify, Terminate.

5.3.9.4 MF / MRPIN.DPE

Dieses Multireferenz-Passwortobjekt wird zur Freischaltung von Inhalten der Anwendung Datensatz Persönliche Erklärungen verwendet.

Hinweis 16: Kommandos, die gemäß [gemSpec_COS] mit einem Passwortobjekt arbeiten, sind: Activate, Change Reference Data, Deactivate, Delete, Disable Verification Requirement, Enable Verification Requirement, Get Pin Status, Reset Retry Counter, Verify, Terminate.

5.3.9.5 MF / MRPIN.GDD

Dieses Multireferenz-Passwortobjekt wird zur Freischaltung von Inhalten der Anwendung Gesundheitsdatendienst verwendet.

Hinweis 17: Kommandos, die gemäß [gemSpec_COS] mit einem Passwortobjekt arbeiten, sind: Activate, Change Reference Data, Deactivate, Delete, Disable Verification Requirement, Enable Verification Requirement, Get Pin Status, Reset Retry Counter, Verify, Terminate.

5.3.9.6 MF / MRPIN.NFD_READ

Dieses Multireferenz-Passwortobjekt wird zur Freischaltung von Inhalten der Anwendung Notfalldatensatz verwendet. Dieses Multireferenz-Passwortobjekt kann im Gegensatz zu MRPIN.NFD nicht deaktiviert werden.

Hinweis 18: Kommandos, die gemäß [gemSpec_COS] mit einem Passwortobjekt arbeiten, sind: Activate, Change Reference Data, Deactivate, Delete, Disable Verification Requirement, Enable Verification Requirement, Get Pin Status, Reset Retry Counter, Verify, Terminate.

5.3.9.7 MF / MRPIN.OSE

Dieses Multireferenz-Passwortobjekt wird zur Freischaltung von Inhalten der Anwendung Organspendeerklärung verwendet. Dieses Multireferenz-Passwortobjekt kann nicht deaktiviert werden.

Hinweis 19: Kommandos, die gemäß [gemSpec_COS] mit einem Passwortobjekt arbeiten, sind: Activate, Change Reference Data, Deactivate, Delete, Disable Verification Requirement, Enable Verification Requirement, Get Pin Status, Reset Retry Counter, Verify, Terminate.

5.3.9.8 MF / MRPIN.AMTS

Dieses Multireferenz-Passwortobjekt wird zur Freischaltung von Inhalten der Anwendung AMTS Datenmanagement verwendet.

5.3.9.9 MF / PIN.AMTS_REP

Dieses Passwortobjekt wird zur Freischaltung von Inhalten der Anwendung AMTS Datenmanagement durch einen Vertreter des Versicherten verwendet. Dieses Passwortobjekt kann nicht abgeschaltet werden.

5.3.10 MF / PrK.eGK.AUT_CVC.E256

Dieser Schlüssel wird im Rahmen von asymmetrischen Authentisierungsprotokollen mit elliptischer Kryptographie verwendet. Der zugehörige öffentliche Schlüssel PuK.eGK.AUT_CVC.E256 ist in EF.C.eGK.AUT_CVC.E256 enthalten.

Hinweis 20: Kommandos, die gemäß [gemSpec_COS] mit einem privaten Schlüsselobjekt (ELC) arbeiten, sind: Activate; Deactivate; Delete, External Authenticate, General Authenticate, Generate Asymmetric Key Pair, Internal Authenticate, PSO Compute Digital Signature, PSO Decipher, PSO Transcipher, Terminate.

5.3.11 Sicherheitsanker zum Import von CV-Zertifikaten

In diesem Kapitel wird das öffentliche Signaturprüfobjekt behandelt, das an der Wurzel eines PKI Baumes für CV-Zertifikate steht. Dieses wird auch Sicherheitsanker genannt und dient dem Import von CV-Zertifikaten der zweiten Ebene. Derzeit ist ein Sicherheitsanker vorhanden.

5.3.11.1 MF / PuK.RCA.CS.E256

Dieses Objekt enthält den öffentlichen Schlüssel der Root-CA, welcher an der Wurzel der der CVC.E256-Hierarchie steht. Er wird zur Prüfung von CV-Zertifikaten der zweiten Ebene unter Nutzung elliptischer Kryptographie benötigt.

Hinweis 21: Kommandos, die gemäß [gemSpec_COS] mit einem öffentlichen Signaturprüfobjekt arbeiten, sind: Activate, Deactivate, Delete, PSO Verify Certificate, Terminate.

Hinweis 22: Während gemäß den Tabellen in

[gemSpec_PKI#Struktur und Inhalt eines CV-Zertifikates für ELC-Schlüssel der Generation 2] als RFU gekennzeichnete Bits einer Flaglisten in CV-Zertifikaten der Generation 2 auf ‘0’ zu setzen sind, werden RFU-Bits einer Flagliste im CHAT eines Sicherheitsankers auf ‘1’ gesetzt.

Hinweis 23: Es ist möglich, dass importierte Authentisierungsschlüssel auch zum Aufbau eines Trusted Channels verwendet werden. Dabei wird das Kommando General Authenticate verwendet. Deshalb ist es erforderlich, dass importierte Authentisierungsschlüssel das Kommando General Authenticate unterstützen. Die Zugriffsart General Authenticate fehlt in der oben genannten Zugriffsregel, weil gemäß [gemSpec_COS] dabei lediglich für private Schlüssel, nicht aber für öffentliche Schlüssel Zugriffsregeln ausgewertet werden. Falls das herstellerspezifische COS im Rahmen eines General Authenticate Kommandos auch Zugriffsregeln für öffentliche Schlüssel auswertet, dann ist eine entsprechende Zugriffsart herstellerspezifisch mit der Zugriffsbedingung ALWAYS zu ergänzen.

5.3.12 Asymmetrische Kartenadministration

Die hier beschriebene optionale Variante der Administration der eGK umfasst sowohl das Kartenmanagementsystem (CMS), als auch die Pflege der Versichertenstammdaten (VSD).

Die Administration einer eGK erfordert den Aufbau eines kryptographisch gesicherten Kommunikationskanals (Trusted Channel). In diesem Kapitel werden Schlüssel beschrieben, die den Aufbau eines solchen Trusted Channels mittels asymmetrischer Verfahren ermöglichen. Die Schlüssel zum Aufbau mittels symmetrischer Verfahren werden in 5.3.13 beschrieben.

Voraussetzung für den Aufbau mittels asymmetrischer Verfahren ist, dass sowohl die zu administrierende Karte, als auch das administrierende System über ein asymmetrisches Schlüsselpaar verfügen. Sei (PrK.ICC, PuK.ICC) das Schlüsselpaar der Smartcard und (PrK.Admin, PuK.Admin) das Schlüsselpaar des administrierenden Systems, dann ist es erforderlich, dass die Smartcard PuK.Admin kennt und das administrierende System PuK.ICC kennt.

Während die Schlüsselpaare auf Smartcards typischerweise kartenindividuell sind, so ist es denkbar, dass mit einem Schlüsselpaar eines administrierenden Systems genau eine, oder mehrere oder alle Smartcards administriert werden. Das Sicherheitskonzept des administrierenden Systems erscheint die geeignete Stelle zu sein um eine Variante auszuwählen.

5.3.12.1 MF / PuK.RCA.ADMINCMS.CS.E256

Dieses Objekt enthält den öffentlichen Schlüssel der Root-CA, welcher an der Wurzel der der CVC.E256-Hierarchie für die asymmetrische VSD/CMS-Authentisierung steht. Es wird dabei vorausgesetzt, dass bezüglich der organisationsspezifischen CV-Zertifikate für CMS und VSD eine einzige organisationsspezifische CVC-Root genutzt wird. PuK.RCA.ADMINCMS.CS.E256 wird für den Import weiterer Schlüssel für die elliptische Kryptographie benötigt.

Hinweis 24: Kommandos, die gemäß [gemSpec_COS] mit einem öffentlichen Signaturprüfobjekt arbeiten, sind: Activate, Deactivate, Delete, PSO Verify Certificate, Terminate.

Hinweis 25: Während gemäß den Tabellen in

[gemSpec_PKI#Struktur und Inhalt eines CV-Zertifikates für ELC-Schlüssel der Generation 2] als RFU gekennzeichnete Bits einer Flaglisten in CV-Zertifikaten der Generation 2 auf ‘0’ zu setzen sind, werden RFU Bits einer Flagliste im CHAT eines Sicherheitsankers auf ‘1’ gesetzt.

5.3.13 Symmetrische Kartenadministration

Die hier beschriebene Variante der Administration der eGK umfasst sowohl das Kartenmanagementsystem (CMS), als auch die Pflege der Versichertenstammdaten (VSD).

Die Administration einer eGK erfordert den Aufbau eines kryptographisch gesicherten Kommunikationskanals (Trusted Channel). In diesem Kapitel werden Schlüssel beschrieben, die den Aufbau eines solchen Trusted Channels mittels symmetrischer Verfahren ermöglichen. Die Schlüssel zum Aufbau mittels asymmetrischer Verfahren werden in 5.3.12 beschrieben.

Voraussetzung für den Aufbau mittels symmetrischer Verfahren ist, dass sowohl die zu administrierende Karte, als auch das administrierende System über denselben symmetrischen Schlüssel verfügen.

Während die Schlüssel auf Smartcards typischerweise kartenindividuell sind, ist es denkbar, dass mit einem Schlüssel eines administrierenden Systems genau eine, oder mehrere oder alle Smartcards administriert werden. Das Sicherheitskonzept des administrierenden Systems erscheint die geeignete Stelle zu sein um eine Variante auszuwählen.

Es sind getrennte Schlüssel für das CMS und den VSD definiert. Bei der Personalisierung sind nur die Schlüssel personalisieren, die tatsächlich benötigt werden.

5.3.13.1 MF / SK.CMS.AES128

Dieser AES-Schlüssel mit 128 bit Schlüssellänge wird benötigt, um administrative Aufgaben am Objektsystem (z. B. das Anlegen von neuen Anwendungen) auszuführen.

Hinweis 26:Kommandos, die gemäß [gemSpec_COS] mit einem symmetrischen Authentisierungsobjekt arbeiten, sind: Activate, Deactivate, Delete, External Authenticate, General Authenticate, Get Security Status Key, Internal Authenticate, Mutual Authenticate, Terminate.

Hinweis 27: Falls ein Kartenherausgeber Karten asynchron unter Nutzung symmetrischer Schlüssel administrieren will, so ist die Variante „ALWAYS“ umzusetzen. Andernfalls liegt es im Belieben des Kartenherstellers ob die Variante „ALWAYS“ oder die Variante „NEVER“ umgesetzt wird.

5.3.13.2 MF / SK.CMS.AES256

Dieser AES-Schlüssel mit 256 bit Schlüssellänge wird benötigt, um administrative Aufgaben am Objektsystem (z. B. das Anlegen von neuen Anwendungen) auszuführen.