>> PPA/DVO: Spezifikation wird nicht mehr fortgeschrieben.

@ QS: Falls Veröffentlichung notwendig ist, bitte alte Version nehmen. Info dazu kommt noch.

@PET: Bitte noch nicht archivieren!

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation der Security Module Card SMC-B

Objektsystem

    

     

      
Version
      
3.13.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
15.05.2019
     
     

      
Status
      
Dokument abgekündigt
     
     

      
Klassifizierung
      
nicht öffentlich
     
     

      
Referenzierung
      
gemSpec_SMC-B_ObjSys
     
    

Dokumentinformationen

Änderungen zur Vorversion

Änderungen zur Vorversion beruhen auf P18.1

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen an das Objektsystem der Sicherheitsmodulkarte SMC-B. Es beinhaltet die Definition der Anforderungen an die Objektstruktur, die Beschreibung der Kartenschnittstelle der Sicherheitsmodulkarte SMC-B für Institutionen im Gesundheitswesen.

Das Dokument berücksichtigt dabei:

• die DIN-Spezifikation für Chipkarten mit digitaler Signatur
• die ESIGN-Spezifikation für elektronische Signaturen
• die zugehörenden ISO-Standards (speziell ISO/IEC 7816, Teile 1-4, 6, 8, 9 und 15)
• andere Quellen (z. B. Anforderungen der Trustcenter)

Dieses Dokument spezifiziert Anwendungen der Sicherheitsmodulkarte SMC-B unter den folgenden, rein kartenorientierten Gesichtspunkten:

• Ordnerstruktur,
• Dateien,
• Sicherheitsmechanismen wie Zugriffsregeln.

Somit stellt dieses Dokument auf unterster technischer Ebene eine Reihe von Datencontainern bereit. 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 Kapitel 1.4).

1.2 Zielgruppe

Das Dokument richtet sich an

• Hersteller, welche die hier spezifizierten Anwendungen für ein bestimmtes Chipkartenbetriebssystem umsetzen,
• Kartenherausgeber, die anhand der hier spezifizierten Anwendungen die elektrische Personalisierung einer Sicherheitsmodulkarte SMC-B planen,
• Hersteller von Systemen, 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 wird 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]. Die Spezifikation [gemSpec_COS] ist Grundlage der Entwicklung der Kommandostrukturen und Funktionen für die Chipkartenbetriebssysteme.

Die optische Gestaltung für alle SMCs und damit auch für die SMC-B wird in dem Dokument „Gemeinsame optische Merkmale der SMC“ [gemSpec_SMC_OPT] wird festgelegt.

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.

Für die Authentisierung der Zugriffe durch ein CMS 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.

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:

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:

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, dann ist es zulässig den Term SmCmdEnc zu ignorieren, falls er in der Spezifikation vorhanden ist.
2. Falls eine Antwortnachricht keine Antwortdaten enthält, dann 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, dann 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, dann ist es für den Prüfling zulässig in der zugehörige Zugriffsregel den Term SmRspEnc zu verwenden.

1.5.2 Verwendung von Schü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 zwischen 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 1: Tab_SMC-B_ObjSys_001 Liste der Komponenten, an welche dieses Dokument Anforderungen stellt

2 Optionen und Ausprägungen

Dieses Unterkapitel listet Funktionspakete auf, die für eine Zulassung einer SMC-B der Generation 2 nicht zwingend erforderlich sind.

2.1 Ausprägung ohne Zugriff auf die eGK

SMC-Bs können auch in Organisationen eingesetzt werden, die an der TI teilnehmen, aber nicht zum Zugriff auf die eGK berechtigt sind. Um zu verhindern, dass eine solche SMC-B den Zugriff auf eine eGK freischalten kann, werden ihre Rollenzertifikate EF.C.SMC.AUTR_CVC.R2048 und EF.C.SMC.AUTR_CVC.E256 sowie das Zertifikat EF.C.CA_SMC.CS.R2048 der RSA-Sub-CA bei der Personalisierung entweder gar nicht oder mit Nullen befüllt. Die entsprechenden Schlüssel bleiben herstellerspezifisch „unbefüllt“ oder werden mit nichtnutzbaren Dummy-Daten befüllt.

Dies wird in den entsprechenden Personalisierungsfestlegungen mit dem Zusatz „Ausprägung_ORG“ gekennzeichnet.

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 folgende Optionen enthält:

• Unterstützung von mindestens vier logischen Kanälen.

4.1 Mindestanzahl logischer Kanäle

Jeder Kanal besitzt seinen eigenen unabhängigen Sicherheitsstatus, d.h. eine externe Authentisierung der Rollenkennung in einem logischen Kanal setzt keinen Sicherheitszustand in irgendeinem anderen Kanal.

4.2 Optionale Funktionspakete

4.2.1 Kontaktlose Schnittstelle

4.2.2 USB-Schnittstelle (optional)

4.2.3 Kryptobox (optional)

4.3 Attributstabellen

4.3.1 Attribute eines Ordners

4.3.2 Attribute einer Datei (EF)

4.4 Zugriffsregeln für besondere Kommandos

Gemäß [gemSpec_COS] gilt:

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 Attributes 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 Kartenadministration

In den Kapiteln 5.3.15 und 5.3.16 sind die Objekte für die zwei verschiedenen Verfahren zur Absicherung der Kommunikation zwischen einem Kartenadministrationssystem (z.B. einem CUpS) und einer Karte beschrieben, die bei der Ausgabe der Karte angelegt werden müssen.

5 Spezifikation grundlegender Applikationen

Zu den grundlegenden Applikationen der Sicherheitsmodulkarte SMC-B zählen:

• das Wurzelverzeichnis der SMC, auch Root oder Master File (MF) genannt,
• die Sicherheitsmodulanwendung DF.SMA (Security Module Application),
• die Krypto-Anwendung DF.ESIGN

5.1 Attribute des Objektsystems

Das Objektsystem der SMC-B enthält gemäß [gemSpec_COS#9.1] folgende Attribute:

5.1.1 ATR-Kodierung und technische Eigenschaften

5.2 Allgemeine Struktur

Abbildung 1 zeigt die allgemeine Struktur der SMC-B.

Abbildung 1: Abb_SMC-B_ObjSys_001 Allgemeine Struktur der SMC-B

Eine kryptografische Informationsanwendung (DF.CIA.ESIGN) ist nicht erforderlich, da eine SMC-B stationär gesteckt bleibt und die Anwendung der zuständigen Software bekannt ist.

5.3 Root, die Wurzelapplikation MF

Das MF der SMC-B ist ein “Application Dedicated File” (siehe [gemSpec_COS#8.3.1.3]) mit den in Tab_SMC-B_ObjSys_002 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

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

Hinweis 4: Das Kommando ist nur vom Inhaber des CMS-Schlüssels ausführbar, siehe Kap. 5.6.

5.3.1 MF / EF.ATR

Die transparente Datei EF.ATR enthält Informationen zur maximalen Größe der APDU sowie zur Identifizierung des Betriebssystems.

Hinweis 5: Kommandos, die gemäß [gemSpec_COS] mit einem transparenten EF arbeiten, sind: ACTIVATE, DEACTIVATE, DELETE, ERASE BINARY, READ BINARY, SELECT, SET LOGICAL EOF, UPDATE BINARY, TERMINATE, WRITE BINARY

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

5.3.2 MF / EF.DIR

Die Datei EF.DIR enthält eine Liste mit Anwendungs-Templates gemäß [ISO/IEC 7816-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 ISO/IEC 7816-4 festgelegt.

Hinweis 9: Das Kommando ist nur vom Inhaber des CMS-Schlüssels ausführbar, siehe Kap. 5.6.

5.3.3 MF / EF.GDO

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

5.3.4 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 10: Kommandos, die gemäß [gemSpec_COS] mit einem transparenten EF arbeiten, sind: ACTIVATE, DEACTIVATE, DELETE, ERASE BINARY, READ BINARY, SELECT, SET LOGICAL EOF, UPDATE BINARY, TERMINATE, WRITE BINARY

Hinweis 11: Das Kommando ist nur vom Inhaber des CMS-Schlüssels ausführbar, siehe Kap. 5.6.

5.3.5 MF / EF.C.CA_SMC.CS.R2048

Diese Datei enthält ein CV-Zertifikat für die Kryptographie mit RSA gemäß [gemSpec_COS], welches den öffentlichen Schlüssel PuK.CA_SMC.CS.R2048 einer CA enthält. Für die Ausprägung _ORG bleibt diese Datei leer oder wird mit Nullen befüllt.

Hinweis 12: Kommandos, die gemäß [gemSpec_COS] mit einem transparenten EF arbeiten, sind: ACTIVATE, DEACTIVATE, DELETE, ERASE BINARY, READ BINARY, SELECT, SET LOGICAL EOF, UPDATE BINARY, TERMINATE, WRITE BINARY

Hinweis 13: Das Kommando ist nur vom Inhaber des CMS- / CUP-Schlüssels ausführbar, siehe Kap. 5.6.

5.3.6 MF / EF.C.CA_SMC.CS.E256

Diese Datei enthält ein CV-Zertifikat für die Kryptographie mit elliptischen Kurven gemäß [gemSpec_COS], welches den öffentlichen Schlüssel PuK.CA_SMC.CS.E256 einer CA enthält.

5.3.7 MF / EF.C.SMC.AUTR_CVC.R2048

EF.C.SMC.AUTR_CVC.R2048 enthält das CV-Zertifikat der SMC-B für die Kryptographie mit RSA für rollenbasierte C2C-Authentisierung zwischen SMC-B und eGK. Das zugehörende private Schlüsselobjekt PrK.SMC.AUTR_CVC.R2048 ist im Kapitel 5.3.11 definiert. Für die Ausprägung _ORG bleibt diese Datei leer oder wird mit Nullen befüllt.

Hinweis 14: Kommandos, die gemäß [gemSpec_COS] mit einem transparenten EF arbeiten, sind: ACTIVATE, DEACTIVATE, DELETE, ERASE BINARY, READ BINARY, SELECT, SET LOGICAL EOF, UPDATE BINARY, TERMINATE, WRITE BINARY

Hinweis 15: Das Kommando ist nur vom Inhaber des CMS- bzw. CUP-Schlüssels ausführbar, siehe Kap. 5.6.

5.3.8 MF / EF.C.SMC.AUTR_CVC.E256

EF.C.SMC.AUTR_CVC.E256 enthält das CV-Zertifikat der SMC-B für die Kryptographie mit elliptischen Kurven für rollenbasierte C2C-Authentisierung zwischen SMC-B und eGK. Das zugehörende private Schlüsselobjekt PrK.SMC.AUTR_CVC.E256 ist im Kapitel 5.3.12 definiert. Für die Ausprägung _ORG bleibt diese Datei leer oder wird mit Nullen befüllt.

Hinweis 16: Das Kommando ist nur vom Inhaber des CMS- / CUP-Schlüssels ausführbar, siehe Kap. 5.6.

5.3.9 MF / EF.C.SMC.AUTD_RPE_CVC.E256

EF.C.SMC.AUTD_RPE_CVC.E256 enthält das CV-Zertifikat für die Kryptographie mit elliptischen Kurven für die C2C-Geräteauthentisierung zwischen einer lokal vorhandenen SMC-B und einer SMC-B als entferntem PIN-Empfänger. Das zugehörende private Schlüsselobjekt PrK.SMC.AUTD_RPE_CVC.E256 ist im Kapitel 5.3.13 definiert.

Hinweis 17: Kommandos, die gemäß [gemSpec_COS] mit einem transparenten EF arbeiten, sind: ACTIVATE, DEACTIVATE, DELETE, ERASE BINARY, READ BINARY, SELECT, SET LOGICAL EOF, UPDATE BINARY, TERMINATE, WRITE BINARY

Hinweis 18: Das Kommando ist nur vom Inhaber des CMS- / CUP-Schlüssels ausführbar, siehe Kap. 5.6.

5.3.10 MF / PIN.SMC

Dieses Passwortobjekt wird zur Freischaltung von Schlüsseln und Inhalten der SMC-B verwendet.

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.11 MF / PrK.SMC.AUTR_CVC.R2048

PrK.SMC.AUTR_CVC.R2048 ist der globale private Schlüssel für die Kryptographie mit RSA für die C2C-Authentisierung zwischen SMC-B/eGK. Der zugehörige öffentliche Schlüssel PuK.SMC.AUTR_CVC.R2048 ist in C.SMC.AUTR_CVC.R2048 (siehe Kapitel 5.3.7) enthalten. Für die Ausprägung _ORG bleibt dieser Schlüssel herstellerspezifisch „unbefüllt“ oder wird mit Zufallswerten befüllt.

Tabelle 21: Tab_SMC-B_ObjSys_112 Hex-Werte in Zugriffsregel

Hinweis 21: Kommandos, die gemäß [gemSpec_COS] mit einem privaten Schlüsselobjekt RSA arbeiten, sind:    
ACTIVATE, DEACTIVATE, DELETE, EXTERNAL AUTHENTICATE, GENERATE ASYMMETRIC KEY PAIR, INTERNAL AUTHENTICATE, PSO Decipher, PSO Transcipher, PSO Compute Digital Signature, TERMINATE

Hinweis 22: Die SMC-B eines Krankenhauses verhält sich wie die SMC-B einer Arzt- bzw. Zahnarzt-Praxis. Sofern die Notwendigkeit besteht, dass eine SMC-B eines Krankenhauses auch durch HBAs anderer Profile als die eines Arztes freigeschaltet werden können muss, kann diese Spezifikation entsprechend in kommenden Versionen daraufhin angepasst werden.

Hinweis 23: Das Kommando ist nur vom Inhaber des CMS- / CUP-Schlüssels ausführbar, siehe Kap. 5.6.

Der öffentliche Schlüssel, der zu PrK.SMC.AUTR_CVC.R2048 (mit Profil des CVC-Inhabers), gehört, ist in C.SMC.AUTR_CVC.R2048 enthalten.

5.3.12 MF / PrK.SMC.AUTR_CVC.E256

PrK.SMC.AUTR_CVC.E256 ist der globale private Schlüssel für die Kryptographie mit elliptischen Kurven für die C2C-Authentisierung zwischen SMC-B/eGK. Der zugehörige öffentliche Schlüssel PuK.SMC.AUTR_CVC.E256 ist in C.SMC.AUTR_CVC.E256 (siehe Kapitel 5.3.8) enthalten. Für die Ausprägung _ORG bleibt dieser Schlüssel herstellerspezifisch „unbefüllt“ oder wird mit Zufallswerten befüllt.

Hinweis 24: Kommandos, die gemäß [gemSpec_COS] mit einem privaten Schlüsselobjekt ELC arbeiten, sind:    
CTIVATE, DEACTIVATE, DELETE, EXTERNAL AUTHENTICATE, GENERAL AUTHENTICATE, GENERATE ASYMMETRIC KEY PAIR, INTERNAL AUTHENTICATE, PSO Decipher, PSO Transcipher, PSO Compute Digital Signature, TERMINATE

Hinweis 25: Die SMC-B eines Krankenhauses verhält sich wie die SMC-B einer Arzt- bzw. Zahnarzt-Praxis. Sofern die Notwendigkeit besteht, dass eine SMC-B eines Krankenhauses auch durch HBAs anderer Profile als die eines Arztes freigeschaltet werden können muss, kann diese Spezifikation entsprechend in kommenden Versionen daraufhin angepasst werden.

Hinweis 26: Das Kommando ist nur vom Inhaber des CMS- / CUP-Schlüssels ausführbar, siehe Kap. 5.6

5.3.13 MF / PrK.SMC.AUTD_RPE_CVC.E256

PrK.SMC.AUTD_RPE_CVC.E256 ist der globale private Schlüssel für die Kryptographie mit elliptischen Kurven für die C2C-Authentisierung zwischen einer gSMC-KT und einer SMC-B in der Funktion des PIN-Empfängers. Der zugehörige öffentliche Schlüssel PuK.SMC.AUTD_RPE_CVC.E256 ist in C.SMC.AUTD_RPE_CVC.E256 (siehe Kapitel 5.3.9) enthalten.

Hinweis 27: Kommandos, die gemäß [gemSpec_COS] mit einem privaten Schlüsselobjekt ELC arbeiten, sind:
CTIVATE, DEACTIVATE, DELETE, EXTERNAL AUTHENTICATE, GENERAL AUTHENTICATE, GENERATE ASYMMETRIC KEY PAIR, INTERNAL AUTHENTICATE, PSO Decipher, PSO Transcipher, PSO Compute Digital Signature, TERMINATE

Hinweis 28: Das Kommando ist nur vom Inhaber des CMS- / CUP-Schlüssels ausführbar, siehe Kap. 5.6:

5.3.14 Sicherheitsanker zum Import von CV-Zertifikaten

In diesem Kapitel werden öffentliche Signaturprüfobjekte behandelt, die an der Wurzel eines PKI Baumes für CV-Zertifikate stehen. Diese werden auch Sicherheitsanker genannt und dienen dem Import von CV-Zertifikaten der zweiten Ebene. Derzeit ist jeweils ein Sicherheitsanker vorhanden,

1. zwecks Abwärtskompatibilität zur Generation 1 Infrastruktur (PuK.RCA.CS.R2048),
2. zur unmittelbaren Ablösung der Generation 1 Algorithmen (PuK.RCA.CS.E256) und

5.3.14.1 MF / PuK.RCA.CS.R2048

PuK.RCA.CS.R2048 ist der öffentliche Schlüssel der Root-CA des Gesundheitswesens für die Kryptographie mit RSA für die Prüfung von CV-Zertifikaten, die von dieser herausgegeben werden.

Hinweis 29: Kommandos, die gemäß [gemSpec_COS] mit einem öffentlichen Signaturprüfobjekt arbeiten, sind:
ACTIVATE, DEACTIVATE, DELETE, PSO Verify Certificate, TERMINATE

Hinweis 30: Das Kommando ist nur vom Inhaber des CMS- / CUP-Schlüssels ausführbar, siehe Kap.5.6

5.3.14.2 MF / PuK.RCA.CS.E256

PuK.RCA.CS.E256 ist der öffentliche Schlüssel der Root-CA des Gesundheitswesens für die Kryptographie mit elliptischen Kurven für die Prüfung von CV-Zertifikaten, die von dieser herausgegeben werden.

Hinweis 31: Während gemäß den Tabellen in [gemSpec_COS]#H.4] 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.15 Asymmetrische Kartenadministration

Die hier beschriebene Variante der Administration der SMC-B betrifft ein Administrationssystem (i.A. ein Kartenmanagementsystem (CMS)) zur Administration der SMC-B.

Die Administration einer SMC-B 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.16 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.15.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 CMS-Authentisierung steht. PuK.RCA.ADMINCMS.CS.E256 wird für den Import weiterer Schlüssel für die elliptische Kryptographie benötigt.

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

Hinweis 33: Während gemäß den Tabellen in [gemSpec_COS]#H.4] 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 34: Das Kommando ist nur vom Inhaber des CMS- / CUP-Schlüssels ausführbar, siehe Kap. 5.6.

5.3.16 Symmetrische Kartenadministration

Die hier beschriebene Variante der Administration der SMC-B betrifft ein Administrationssystem (i.A. ein Kartenmanagementsystem (CMS)) zur Administration der SMC-B.

Die Administration einer SMC-B 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.15 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.

Wenn die symmetrischen Schlüssel (SK.CMS und SK.CUP) für die Authentifizierung des Kartenadministrationssystems genutzt werden, dann MÜSSEN sie kartenindividuell personalisiert werden, so dass mit einem Schlüssel eines administrierenden Systems kann genau eine SMC-B administriert werden kann.

Bei der Personalisierung sind nur die Schlüssel zu personalisieren, die tatsächlich benötigt werden.

5.3.16.1 MF / SK.CMS.AES128

SK.CMS.AES128 (optional) ist der geheime Schlüssel für die Durchführung des SMC-B/CMS-Authentisierungsverfahrens mit Aufbau eines Trusted Channel. Die nachfolgende Tabelle Tab_SMC-B_ObjSys_033 zeigt die Eigenschaften des Schlüssels.

Hinweis 35: 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 36: Das Kommando ist nur vom Inhaber des CMS- / CUP-Schlüssels ausführbar, siehe Kap. 5.6:

5.3.16.2 MF / SK.CMS.AES256

SK.CMS.AES256 (optional) ist der geheime Schlüssel für die Durchführung des SMC-B / CMS-Authentisierungsverfahrens mit Aufbau eines Trusted Channel.

5.3.16.3 MF / SK.CUP.AES128

Dieser AES-Schlüssel mit 128 bit Schlüssellänge wird benötigt, um dem CUPS administrative Zugriffe auf die SMC-B bezüglich der Zertifikate zu erlauben.

5.3.16.4 MF / SK.CUP.AES256

Dieser AES-Schlüssel mit 256 bit Schlüssellänge wird benötigt, um dem CUPS administrative Zugriffe auf die SMC-B bezüglich der Zertifikate zu erlauben.

5.4 Die Sicherheitsmodul-Anwendung DF.SMA @deprecated

Wichtiger Hinweis:

Die Sicherheitsmodul-Anwendung (DF.SMA, inklusive aller untergeordneten Objekte) wird in zukünftigen Generationen des SMC-B-Objektsystems nicht mehr unterstützt.

5.4.1 Dateistruktur und Dateiinhalt @deprecated

Die folgende Abbildung zeigt die Dateistruktur von DF.SMA für die SMC-B.

Abbildung 2: (Abb_SMC-B_ObjSys_002) Prinzipielle Struktur der Sicherheitsmodul-Anwendung der SMC-B

5.4.2 MF / DF.SMA (Security Module Application) @deprecated

DF.SMA ist ein „Application Directory“ gemäß [gemSpec_COS#8.3.1.1], d.h. ist mittels Anwendungskennung selektierbar.

Hinweis 37: Kommandos, die gemäß [gemSpec_COS] mit einem Ordnerobjekt arbeiten, sind:    
ACTIVATE, DEACTIVATE, DELETE, FINGERPRINT, GET RANDOM, LIST PUBLIC KEY, LOAD APPLICATION, SELECT, TERMINATE

Hinweis 38: herstellerspezifisch; Falls unterstützt, dann außerhalb des Intervalls [‘1000’, ‘FEFF’]; siehe [gemSpec_COS# 8.1.1]

Hinweis 39: Das Kommando ist nur vom Inhaber des CMS-Schlüssels ausführbar, siehe Kapitel 5.6.

5.4.2.1 MF / DF.SMA / EF.SMD @deprecated

Die transparente Datei EF.SMD ist für die Speicherung von SMC-B-bezogenen Daten vorgesehen, z.B. von speziellen Konfigurationsdaten. Die Datei kann immer gelesen werden, aber eine Aktualisierung ist nur nach erfolgreicher Authentisierung zwischen der SMC-B und einem entsprechenden HBA oder SMC-B möglich. Die folgende Tabelle Tab_SMC-B_ObjSys_036 zeigt die Attribute und Zugriffsbedingungen der Datei EF.SMD. Alternativ zur Authentisierung mit einem HBA oder einer SMC-B kann für den aktualisierenden oder löschenden Zugriff die Authentisierung mit der PIN.SMC genutzt werden.

Hinweis 40: Kommandos, die gemäß [gemSpec_COS] mit einem transparenten EF arbeiten, sind: ACTIVATE, DEACTIVATE, DELETE, ERASE BINARY, READ BINARY, SELECT, SET LOGICAL EOF, UPDATE BINARY, TERMINATE, WRITE BINARY

Hinweis 41: Authentisierung mit PIN.SMC oder Rollenauthentisierung mit einem HBA oder SMC mit einem Hex-Wert ‘yy.....yy’, der der Flagliste eines entsprechenden HBA oder einer entsprechenden SMC entspricht (Generation 2, siehe [gemSpec_COS]).

5.4.2.2 MF / DF.SMA / EF.CONF @deprecated

Die transparente Datei EF.CONF speichert Konfigurationsdaten für die Konnektorwartung. Dies kann beispielsweise beim Austausch des Konnektors genutzt werden, um Pairing-Informationen zu sichern und an den neuen Konnektor zu übertragen. Lesen, Aktualisieren und Löschen der Daten sind nur nach erfolgreicher Präsentation der PIN.CONF zugelassen.

Hinweis 42: Kommandos, die gemäß [gemSpec_COS] mit einem transparenten EF arbeiten, sind: ACTIVATE, DEACTIVATE, DELETE, ERASE BINARY, READ BINARY, SELECT, SET LOGICAL EOF, UPDATE BINARY, TERMINATE, WRITE BINARY

5.4.2.3 MF / DF.SMA / EF.NET @deprecated

Die transparente Datei EF.NET kann Netzwerkkonfigurationsdaten speichern, z.B.

• DNS-Namen oder IP-Adressen in Verbindung mit Portnummer und Protokolltyp (TCP oder UDP) der Access Gateways,
• VPN IP-Version (IPv4 oder IPv6)
• DNS-Name des Aktualisierungsservers.

Die Daten sind organisationsspezifisch. Das Lesen der Daten ist immer möglich. Aktualisieren und Löschen ist nur nach erfolgreicher Präsentation der PIN.SMC zugelassen.