gemSpec_eGK_ObjSys_V3.11.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation der elektronischen Gesundheitskarte
eGK-Objektsystem

    

     

      
Version
      
3.11.0
     
     

      
Revision
      
714626
     
     

      
Stand
      
28.10.2016
     
     

      
Status
      
in Bearbeitung
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_eGK_ObjSys
     
    

Dokumentinformationen

Änderungen zur Vorversion

Überarbeitung der Dokumente für den Online-Produktivbetrieb (Stufe 1), als Grundlage für Produktivzulassungen und den bundesweiten Rollout.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

Nach Inkrafttreten der eIDAS-Verordnung wurde die Anforderungslage der gematik entsprechend angepasst. Signaturgesetz (SigG) und -verordnung (SigV) sind weiterhin gültig und finden dort Anwendung, wo sie der eIDAS-Verordnung nicht widersprechen. SigG und SigV sollen zukünftig durch das deutsche Vertrauensdienstegesetz (VDG) abgelöst werden. Mit Verabschiedung des Vertrauensdienstegesetzes kann es in diesem Dokument daher zu Anpassungen und Konkretisierungen entsprechend der geänderten Rechtslage kommen.

1.1 Zielsetzung

Dieses Dokument spezifiziert die anwendungsspezifischen Strukturen der 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 elektronischen Gesundheitskarte (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.

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#6.7.5) 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örige 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örige 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 Textmarken 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.13 und 5.3.14 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 (1) Die in diesem Kapitel verwendeten Begriffe "Vorbereitungsphase" und "Nutzungsphase" werden in [gemSpec_COS#4] definiert.

4 Anwendungsübergreifende Festlegungen

Zur Umsetzung dieses Kartentyps ist ein Betriebssystem hinreichend, welches keine der in [gemSpec_COS] spezifizierten Optionen umsetzt.

4.1 Unterstützung optionaler Funktionspakete

4.1.1 USB-Schnittstelle (optional)

4.1.2 Kontaktlose Schnittstelle (optional)

4.1.3 Logische Kanäle (optional)

4.1.4 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.2 Reservierung Speicherplatz

4.2.1 AMTS

4.2.2 Speicherplatz für zukünftige Anwendungen

4.2.3 Größe der Speicherplatzreservierung für zukünftige Anwendungen

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:

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),
• die Krypto-Anwendung DF.ESIGN und
• die Beschreibung kryptographischer Objekte DF.CIA_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:

5.1.1 Answer To Reset

5.2 Allgemeine Struktur

Abb_eGK_ObjSys_001 zeigt die allgemeine Struktur der eGK.

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 (Option kontaktlose Schnittstelle)

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

5.3.3 MF / EF.C.CA_eGK.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_eGK.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_eGK.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

Diese Datei enthält pro Rekord 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] 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 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.10 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.11 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 (15) 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.12 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.12.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 (16) Kommandos, die gemäß [gemSpec_COS] mit einem öffentlichen Signaturprüfobjekt arbeiten, sind: Activate, Deactivate, Delete, PSO Verify Certificate, Terminate.

Hinweis (17) Während gemäß den Tabellen in [gemSpec_PKI#6.7.5] 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 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.14 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.13.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 (18) Kommandos, die gemäß [gemSpec_COS] mit einem öffentlichen Signaturprüfobjekt arbeiten, sind: Activate, Deactivate, Delete, PSO Verify Certificate, Terminate.

Hinweis (19) Während gemäß den Tabellen in [gemSpec_PKI#6.7.5] 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.14 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.13 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.14.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 (20) 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 (21) 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.14.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.

5.3.14.3 MF / SK.VSD.AES128

Dieser AES-Schlüssel mit 128 bit Schlüssellänge wird benötigt, um administrative Aufgaben bezüglich der Dateien mit Versichertendaten (z. B. das Aktualisieren der Daten) auszuführen.

5.3.14.4 MF/ SK.VSD.AES256

Dieser AES-Schlüssel mit 256 bit Schlüssellänge wird benötigt, um administrative Aufgaben bezüglich der Dateien mit Versichertendaten (z. B. das Aktualisieren der Daten) auszuführen.

5.3.15 MF / SK.CAN

Das Schlüsselobjekt CAN (Card Access Number) dient dazu eine kontaktlose Kommunikationsschnittstelle zur eGK kryptographisch abzusichern.

Hinweis (22) Kommandos, die gemäß [gemSpec_COS] mit symmetrischen Kartenverbindungsobjekten arbeiten, sind: Activate; Deactivate; Delete, General Authenticate, Terminate.

5.4 Gesundheitsanwendung, Health Care Application (DF.HCA)

Hinweis (23) 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 (24) Da sich dieser Ordner deaktivieren lässt, ist dieser Zustand für Objekte in 5.4 relevant.

Hinweis (25) Da sich weder dieser Ordner noch darüberliegende Ebenen terminieren lassen, ist dieser Zustand für die Spezifikation im Allgemeinen irrelevant.

Abbildung 2: Abb_eGK_ObjSys_002 Dateistruktur der Gesundheitsanwendung

5.4.1 MF / DF.HCA / EF.Einwilligung

Diese Datei enthält die Information über die Einwilligungen zu freiwilligen Anwendungen.