gemSpec_gSMC-KT_ObjSys_G2_1_V4.3.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation der gSMC-KT

Objektsystem

    

     

      
Version
      
4.3.0
     
     

      
Revision
      
838427
     
     

      
Stand
      
12.05.2022
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_gSMC-KT_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 Objektstruktur der gSMC-KT und definiert die Anforderungen an die Kartenschnittstelle zur gerätespezifischen Security Module Card Typ KT (gSMC-KT) zum Einsatz in eHealth-Kartenterminals.

Es werden die anwendungsspezifischen Strukturen der gSMC-KT, die bei der Initialisierung und Personalisierung in die gSMC-KT geladen werden sowie die Zugriffsrechte auf Elemente der gSMC-KT festgelegt.

Die Spezifikation behandelt Anwendungen der gSMC-KT unter den folgenden, rein kartenorientierten Gesichtspunkten:

• Ordnerstruktur,
• Dateien,
• Sicherheitsmechanismen wie Zugriffsregeln.

Somit definiert dieses Dokument eine Reihe von Datencontainern, Schlüsselobjekten und Passwörtern. Zudem werden hier die Sicherheitsmechanismen für diese Objekte festgelegt, d. h. es wird festgelegt, welchen Instanzen es unter welchen Voraussetzungen möglich ist, auf Inhalte der Container zuzugreifen, Operationen mit den Schlüsselobjekten durchzuführen etc. Die Semantik und die Syntax der Inhalte in Datencontainern ist dagegen nicht Gegenstand dieses Dokumentes.

1.2 Zielgruppe

Das Dokument richtet sich an

• Hersteller, welche die hier spezifizierten Anwendungen herstellerspezifisch für eine bestimmtes Chipkartenbetriebssystem umsetzen,
• Kartenherausgeber, die anhand der hier spezifizierten Anwendungen die elektrische Personalisierung eines Sicherheitsmoduls für Kartenterminals planen,
• Hersteller von Systemen, die Programme entwickeln, welche unmittelbar mit der Chipkarte kommunizieren,
• Kartenterminalhersteller.

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; sie ist somit die Grundarchitektur für die ROM-Maske des Halbleiters.

Im Teil „Gemeinsame optische Merkmale der SMC“ (siehe [gemSpec_SMC_OPT]) wird die optische Gestaltung für alle SMCs und damit auch für die gSMC-KT festgelegt.

1.5 Methodik

1.5.1 Nomenklatur

Dieses Dokument verwendet dieselbe Nomenklatur wie [gemSpec_COS].

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

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 innerhalb der Textmarken angeführten Inhalte.

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_gSMC-KT_ObjSys_001 Liste der Komponenten, an welche dieses Dokument Anforderungen stellt

2 Optionen

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

2.1 Lange Lebensdauer im Feld

2.2 Kartenadministration

In den Kapiteln 5.4.14 und 5.4.15 sind die Objekte für die zwei verschiedenen Verfahren zur Absicherung der Kommunikation zwischen einem Kartenadministrationssystem (z.B. einem CMS) und einer Karte beschrieben.

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.

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

• Unterstützung von mindestens vier logischen Kanälen.
• Unterstützung der Kryptobox-Funktionalität.
• Unterstützung von Onboard-RSA-Schlüsselgenerierung

4.1 Mindestanzahl logischer Kanäle

4.2 Kryptobox

4.3 Unterstützung Onboard-RSA-Schlüsselgenerierung

4.4 Optionale Funktionspakete

4.4.1 Kontaktlose Schnittstelle

4.4.2 USB-Schnittstelle (optional)

4.4.3 Option_PACE_PCD (optional)

4.4.4 RSA CV-Zertifikate (optional)

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

4.4.5 Symmetrischer Kryptographiealgorithmus DES (optional)

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

4.5 Attributstabellen

Dieses Dokument legt das Verhalten aller Objekte im Security Environment SE#1 normativ fest. Das Verhalten in Security Environments mit einer anderen Nummer als SE#1 wird durch dieses Dokument nicht festgelegt.

Alle Angaben zu Objekten (Ordnern, Dateien, Passwörtern und Schlüsseln) in diesem Dokument beziehen sich ausschließlich auf das Security Environment SE#1.

4.5.1 Attribute eines Ordners

4.5.2 Attribute einer Datei (EF)

4.6 Zugriffsregeln für besondere Kommandos

Gemäß [gemSpec_COS] wird festgelegt:

4.7 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:

5 Dateisystem der gSMC-KT

Zu den grundlegenden Applikationen der Sicherheitsmodulkarte gSMC-KT zählen:

• das Wurzelverzeichnis, auch root oder Master File (MF) genannt und
• die Kartenterminalanwendung DF.KT mit Schlüsselmaterial und Zertifikaten zum Aufbau einer sicheren Verbindung zwischen Konnektor und Kartenterminal.

5.1 Attribute des Objektsystems

Das Objektsystem der Komponente gSMC-KT enthält gemäß [gemSpec_COS] 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.2 ATR-Kodierung und technische Eigenschaften

Für die gSMC-KT gelten die Konventionen für die technischen Eigenschaften, ATR und Übertragungs¬protokolle aus [gemSpec_COS] für die elektrische Schnittstelle. Die gSMC-KT ist als Plug-In-Karte (ID-000) für die Nutzung in entsprechenden Kartenterminals vorgesehen.

5.3 Allgemeine Struktur

Die Abbildung Abb_gSMC-KT-ObjSys_001 zeigt die allgemeine Struktur der gSMC-KT.

Abbildung 1: Abb_gSMC-KT-ObjSys_001 Objektstruktur einer gSMC-KT auf oberster Ebene

5.4 Root-Anwendung und Dateien auf MF-Ebene

5.4.1 MF

Das MF der gSMC-KT ist ein “Application Dedicated File” (siehe [gemSpec_COS#8.3.1.3]).

Hinweis (1) Kommandos, die gemäß [gemSpec_COS] mit einem Ordnerobjekt arbeiten, sind:
ACTIVATE, DEACTIVATE, DELETE, FINGERPRINT, LIST PUBLIC KEY, LOAD APPLICATION, SELECT, TERMINATE DF.

Hinweis (2) Da sich weder dieser Ordner noch darüberliegende Ebenen deaktivieren lassen, sind diese Zustände für Objekte im Kapitel 5.4 im Allgemeinen irrelevant.

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

5.4.2 MF / EF.ATR

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

Hinweis (4) 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 (5) Der Wert des Attributs fileIdentifier ist in [ISO 7816–4] festgelegt.

5.4.3 MF / EF.DIR

Die Datei EF.DIR enthält eine Liste mit Anwendungstemplates gemäß [ISO 7816–4]. Da weder das Nachladen von Anwendungen vorgesehen ist, noch das Löschen bestehender Anwendungen, ist es nicht erforderlich, dass die Liste veränderbar ist.

Hinweis (6) 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 (7) Die Werte von fileIdentifier und shortFileIdentifier sind in [ISO 7816–4] festgelegt.

Hinweis (8) Die beiden derzeit definierten Records benötigen je 21 Oktette.

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

5.4.4 MF / EF.GDO

In EF.GDO wird das Datenobjekt ICCSN gespeichert, das die Kennnummer der Karte enthält.

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.

Das Attribut body enthält die Seriennummer der Karte. Dabei gilt:

5.4.5 MF / EF.KeyInfo

Die Datei EF.KeyInfo enthält die Information darüber, welche Datei- und Schlüsselreferenzen aktuell zu verwenden sind und welches Gültigskeitsende sie haben.

Hinweis (11) 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 (12) Das Kommando ist nur vom Inhaber des CMS-Schlüssels ausführbar

5.4.6 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 (13) 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 (14) Das Kommando ist nur vom Inhaber des CMS-Schlüssels ausführbar, siehe Kap. 5.6

5.4.7 MF / EF.C.CA.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.CS.E256 einer CA enthält. Das Zertifikat lässt sich mittels PuK.RCA.CS.E256 (siehe Kapitel 5.4.13.1) prüfen. Der im Zertifikat enthaltene öffentliche Schlüssel dient der Verifizierung von weiteren Zertifikaten, die im Dateisystem enthalten sind (siehe zum Beispiel Kapitel 5.4.9).

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

5.4.8 MF / EF.C.CA.CS.E384 (Option_lange_Lebensdauer_im_Feld)

Diese Datei enthält ein CV-Zertifikat für die Kryptographie mit elliptischen Kurven gemäß [gemSpec_COS], welches den öffentlichen Schlüssel PuK.CA.CS.E384 einer CA enthält. Das Zertifikat lässt sich mittels PuK.RCA.CS.E384 (wird später nachgeladen) prüfen. Der im Zertifikat enthaltene öffentliche Schlüssel dient der Verifizierung von weiteren Zertifikaten, die im Dateisystem enthalten sind (siehe zum Beispiel Kapitel 5.4.10).

5.4.9 MF / EF.C.SMC.AUTD_RPS_CVC.E256

Diese Datei enthält ein CV-Zertifikat für die Kryptographie mit elliptischen Kurven gemäß [gemSpec_COS], welches den öffentlichen Schlüssel PuK.SMC.AUTD_RPS_CVC.E256 zum zugehörigen privaten Schlüssel (siehe Tab_gSMC-KT_ObjSys_016) enthält. Dieses Zertifikat lässt sich mittels des öffentlichen Schlüssels aus EF.C.CA.CS.E256 (siehe Tab_gSMC-KT_ObjSys_007) prüfen.

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 Zertifikat enthält die Rolle CHAT = Remote PIN Sender (RPS), d.h. in der Flagliste cvc_FlagList_TI ist Flag 54 gesetzt.

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

5.4.10 MF / EF.C.SMC.AUTD_RPS_CVC.E384 (Option_lange_Lebensdauer_im_Feld)

Diese Datei enthält ein CV-Zertifikat für die Kryptographie mit elliptischen Kurven gemäß [gemSpec_COS], welches den öffentlichen Schlüssel PuK.SMC.AUTD_RPS_CVC.E384 zum zugehörigen privaten Schlüssel (siehe Tab_gSMC-KT_ObjSys_017) enthält. Dieses Zertifikat lässt sich mittels des öffentlichen Schlüssels aus EF.C.CA.CS.E384 (siehe Tab_gSMC-KT_ObjSys_008) prüfen.

5.4.11 MF / PrK.SMC.AUTD_RPS_CVC.E256

Dieser Schlüssel wird für die Kryptographie mit elliptischen Kurven im Rahmen von asymmetrischen Authentisierungsprotokollen verwendet. Der zugehörige öffentliche Schlüssel befindet sich in einem CV-Zertifikat, das in der Datei EF.C.SMC.AUTD_RPS_CVC.E256 gespeichert ist (siehe Kapitel 5.4.9).

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 Transcipher, PSO Compute Digital Signature, TERMINATE

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

Hinweis (22) Diese Rolle ist einem Gerät für Stapel- und Komfortsignatur zugewiesen. Dabei wird die PIN.QES des "Remote"-Gerätes dorthin übertragen.

Hinweis (23) Diese Rolle ist einem Remote-PIN-Empfänger zugewiesen.

5.4.12 MF / PrK.SMC.AUTD_RPS_CVC.E384 (Option_lange_Lebensdauer_im_Feld)

Dieser Schlüssel wird für die Kryptographie mit elliptischen Kurven im Rahmen von asymmetrischen Authentisierungsprotokollen verwendet. Der zugehörige öffentliche Schlüssel befindet sich in einem CV-Zertifikat, das in der Datei EF.C.SMC.AUTD_RPS_CVC.E384 gespeichert ist (siehe Kapitel 5.4.10).

Hinweis (24) 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 Decipher, PSO Transcipher, PSO Compute Digital Signature, TERMINATE

5.4.13 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.4.13.1 MF / PuK.RCA.CS.E256

Dieses Objekt enthält den öffentlichen Schlüssel der Root-CA für die Kryptographie mit elliptischen Kurven, welche an der Wurzel der CVC-Hierarchie steht. Der öffentliche Schlüssel dient der Überprüfung von Zertifikaten, welche von dieser Root-CA ausgestellt wurden (siehe zum Beispiel Kapitel 5.4.3).

Hinweis (25) Kommandos, die gemäß [gemSpec_COS] mit einem öffentlichen Signaturprüfobjekt arbeiten, sind: PSO Verify Certificate, TERMINATE.

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

Hinweis (27) Während gemäß den Tabellen in [gemSpec_COS]#H.4] als RFU gekennzeichnete Bits einer Flaglisten in CV-Zertifikaten auf ‚0’ zu setzen sind, werden RFU Bits einer Flagliste im CHAT eines Sicherheitsankers auf ‚1’ gesetzt.

Hinweis (28) 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.4.14 Asymmetrische Kartenadministration

Die hier beschriebene optionale Variante der Administration der gSMC-KT betrifft ein Administrationssystem (i.A. ein Kartenmanagementsystem (CMS)) zur Administration der gSMC-KT.

Die Administration einer gSMC-KT 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.4.15 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.

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

5.4.14.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 (29) Kommandos, die gemäß [gemSpec_COS] mit einem öffentlichen Signaturprüfobjekt arbeiten, sind:    
ACTIVATE, DEACTIVATE, DELETE, PSO Verify Certificate, TERMINATE

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

5.4.15 Symmetrische Kartenadministration

Die hier beschriebene optionale Variante der Administration einer gSMC-KT betrifft ein Administrationssystem (i.A. ein Kartenmanagementsystem (CMS)) zur Administration der gSMC-KT.

Die Administration einer gSMC-KT 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.4.14 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.

5.4.15.1 MF / SK.CMS.AES128

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

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

5.4.15.2 MF / SK.CMS.AES256

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

Hinweis (34) 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.

5.4.15.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 gSMC-KT bezüglich der Zertifikate zu erlauben.

5.4.15.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 gSMC-KT bezüglich der Zertifikate zu erlauben.

5.5 MF / DF.KT (Kartenterminalanwendung)

5.5.1 Dateistruktur und Dateiinhalt

DF.KT wird verwendet für:

• die Authentisierung zur Anbindung des Kartenterminals an einen bestimmten Konnektor.

Die folgende Abbildung zeigt die Dateistruktur von DF.KT

Abbildung 2: Abb_gSMC-KT-ObjSys_002 Dateistruktur von DF.KT

Es MUSS möglich sein, die Funktionalität von DF.KT in mehr als einem logischen Kanal zu nutzen, d. h. die von DF.KT bereitgestellten Funktionen MÜSSEN parallel nutzbar sein.

Hinweis (35) Kommandos, die gemäß [gemSpec_COS] mit einem Ordnerobjekt arbeiten, sind:
ACTIVATE, DEACTIVATE, DELETE, FINGERPRINT, LIST PUBLIC KEY, LOAD APPLICATION, SELECT, TERMINATE DF.

Hinweis (36) Es ist möglich, dass die Kartenterminalanwendung DF.KT in einer anderen Komponente als gSMC-KT installiert ist. Dort ist es denkbar, dass das übergeordnete Verzeichnis deaktivierbar ist. Deshalb ist dieser Zustand für Objekte im Kapitel 5.5 zu berücksichtigen.

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

5.5.2 MF / DF.KT / EF.C.SMKT.AUT.XXXX

Die Datei EF.C.SMKT.AUT.XXXX enthält ein X.509-Zertifikat C.SMKT.AUT.R2048 für die Kryptographie mit RSA, welches den öffentlichen Schlüssel PuK.SMKT.AUT.R2048 zum privaten Schlüssel PrK.SMKT.AUT.R2048 (siehe Kapitel 5.5.3) enthält.

Dieses Zertifikat, der darin enthaltene öffentliche Schlüssel sowie der zugehörige private Schlüssel werden beim Pairing des Kartenterminals mit dem Konnektor und zur sicheren Identifikation und Authentisierung des Kartenterminals durch den Konnektor verwendet.

Bei Nutzung der Option_lange_Lebensdauer_im_Feld können im Bedarfsfall durch ein Kartenadministrationssystem (CMS oder CUpS) in dieser Datei auch die X.509-Zertifikate C.SMKT.AUT.R3072, C.SMKT.AUT2.E256 oder C.SMKT.AUT.E384 gespeichert werden.

Hinweis (38) 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 (39) Es ist möglich, dass die Kartenterminalanwendung DF.KT in einer anderen Komponente als gSMC-KT installiert ist. Dort ist es denkbar, dass das übergeordnete Verzeichnis deaktivierbar ist. Deshalb ist dieser Zustand für Objekte im Kapitel 5.5 zu berücksichtigen.

Hinweis (40) Das Kommando ist nur vom Inhaber des CMS- / CUP-Schlüssels ausführbar, siehe Kapitel 5.6.

5.5.3 MF / DF.KT / PrK.SMKT.AUT.R2048

PrK.SMKT.AUT.R2048 ist der private Authentisierungsschlüssel zur Anbindung des Kartenterminals an einen bestimmten Konnektor.

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

Hinweis (42) Es ist möglich, dass die Kartenterminalanwendung DF.KT in einer anderen Komponente als gSMC-KT installiert ist. Dort ist es denkbar, dass das übergeordnete Verzeichnis deaktivierbar ist. Deshalb ist dieser Zustand für Objekte im Kapitel 5.5 zu berücksichtigen.

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

5.5.4 MF / DF.KT / EF.C.SMKT.AUT2.XXXX

Die Datei EF.C.SMKT.AUT2.XXXX enthält ein X.509-Zertifikat C.SMKT.AUT.E256 für die Kryptographie mit elliptischen Kurven, welches den öffentlichen Schlüssel PuK.SMKT.AUT.E256 zum privaten Schlüssel PrK.SMKT.AUT.E256 (siehe Kapitel 5.5.6) enthält. Dieses Zertifikat, der darin enthaltene öffentliche Schlüssel sowie der zugehörige private Schlüssel werden beim Pairing des Kartenterminals mit dem Konnektor und zur sicheren Identifikation und Authentisierung des Kartenterminals durch den Konnektor verwendet.

Bei Nutzung der Option_lange_Lebensdauer_im_Feld können im Bedarfsfall durch ein Kartenadministrationssystem (CMS oder CUpS) in diesem EF auch die X.509-Zertifikate C.SMKT.AUT.R3072, C.SMKT.AUT2.E256 oder C.SMKT.AUT.E384 gespeichert werden.

Hinweis (44) 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.5.5 MF / DF.KT / PrK.SMKT.AUT.R3072 (Option_lange_Lebensdauer_im_Feld)

PrK.SMKT.AUT.R3072 ist der private Authentisierungsschlüssel für die Kryptographie mit RSA zur Anbindung des Kartenterminals an einen bestimmten Konnektor.

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

5.5.6 MF / DF.KT / PrK.SMKT.AUT.E256

PrK.SMKT.AUT.E256 ist der private Authentisierungsschlüssel für die Kryptographie mit elliptischen Kurven zur Anbindung des Kartenterminals an einen bestimmten Konnektor.

Hinweis (46) 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 Decipher, PSO Transcipher, PSO Compute Digital Signature, TERMINATE

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

5.5.7 MF / DF.KT / PrK.SMKT.AUT2.E256 (Option_lange_Lebensdauer_im_Feld)

PrK.SMKT.AUT2.E256 ist der private Authentisierungsschlüssel für die Kryptographie mit elliptischen Kurven zur Anbindung des Kartenterminals an einen bestimmten Konnektor.

Hinweis (48) 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 Decipher, PSO Transcipher, PSO Compute Digital Signature, TERMINATE

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

5.5.8 MF / DF.KT / PrK.SMKT.AUT.E384 (Option_lange_Lebensdauer_im_Feld)

PrK.SMKT.AUT.E384 ist der private Authentisierungsschlüssel für die Kryptographie mit mit elliptischen Kurven zur Anbindung des Kartenterminals an einen bestimmten Konnektor.

Hinweis (50) 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 Decipher, PSO Transcipher, PSO Compute Digital Signature, TERMINATE

5.6 Laden einer neuen Anwendung oder Anlegen eines EFs nach Ausgabe der gSMC-KT

Es wird angenommen, dass das Laden neuer Anwendungen oder das Erstellen neuer EFs auf MF-Ebene (einschließlich Aktualisieren der Dateien EF.DIR und EF.Version2) oder das Nachladen von Zertifikaten oder das Generieren und Sperren von Schlüsseln nach der Ausgabe der gSMC-KT von einem Card Management System (CMS) durchgeführt wird. Dies ist ein optionaler Prozess.

Ebenso ist das CMS optional. Die Inhalte des Kapitels 13 in [gemSpec_COS] sind allerdings normativ, wenn das Laden neuer Anwendungen oder das Erstellen neuer EFs nach Ausgabe der gSMC-KT durchgeführt werden müssen.

6 Anhang A – Verzeichnisse

6.1 Abkürzungen

6.2 Glossar

Das Projektglossar wird als eigenständiges Dokument zur Verfügung gestellt.

6.3 Abbildungsverzeichnis

6.4 Tabellenverzeichnis