latest


>> 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 des elektronischen Heilberufsausweises

HBA-Objektsystem



    
Version 3.13.0
Revision 548770
Stand 15.05.2019
Status Dokument abgekündigt
Klassifizierung nicht öffentlich
Referenzierung gemSpec_HBA_ObjSys

Dokumentinformationen

Änderungen zur Vorversion

Einarbeitungen der Änderungen gemäß Änderungsliste P18.1.

Dokumentenhistorie

Version
Stand
Kap./ Seite
Grund der Änderung, besondere Hinweise
Bearbeitung
2.3.2
05.08.09

Die Version 2.3.2 der „Spezifikation des elektronischen Heilberufsausweises, Teil 2: HPC – Anwendungen und Funktionen“ für die Generation 1 ist Grundlage der vorliegenden Spezifikation. Die Dokumentenhistorie der Version 2.3.2 ist nicht in dieses Dokument übernommen worden; sie kann bei Bedarf dort eingesehen werden.
gematik
3.0.0
19.09.12

freigegeben
gematik
3.1.0
30.01.13

Harmonisierung mit der Struktur der anderen ObjSys-Spezifikationen und Entfernen der N-Nummerierung
gematik
3.2.0 RC
23.10.13

Fehlerkorrekturen, Einfügen einer Anforderung zu persistentPublicKeyList, Attribut shareable wurde für alle Ordner und Dateien hinzugefügt, Ändern der Flaglist-Darstellung, Einfügen von EF.CardAccess, Kommentare eingearbeitet
gematik
3.3.0 RC
18.12.13

Aufnahme des Kommandos LIST PUBLIC KEY FÜR MF, Zuordnung der AFOs zu Initialisierung und Personalisierung, Überarbeitung der Struktur, Entfernen der Option „Lange Lebensdauer“, Modifizieren von EF.ATR, EF.DIR und EF.Version, Option „Testkarten“ aufgenommen, Änderungen in DF.QES: Keine Nutzung der CAN für Remote PIN und Stapelsignatur bei Nutzung der kontaktlosen Schnittstelle, Modifizieren von EF.GDO
gematik
3.4.0
21.02.14

Einfügen einer Liste offener Punkte, Expiration Date für Sicherheitsanker festgelegt, Einfügen Vorgaben für Inhalte von Dateien in CIA.Info, Einarbeiten Kommentare Iteration 2b
gematik
3.5.0
27.03.14

Einarbeitung Fehlerkorrektur Iteration 2b
gematik
3.6.0
06.06.14

Einarbeitung Änderungen Iteration 3
gematik
3.7.0
26.08.14

Richtigstellung in Tab_HBA_ObjSys_065, Einarbeitung weitere Änderungen Iteration 3 und Iteration 4
gematik
3.8.0
17.07.15

Folgende Errata eingearbeitet:    
R.1.4.1, R1.4.2, R1.4.3, R1.4.7
gematik
3.9.0
24.08.16

Anpassungen zum Online-Produktivbetrieb (Stufe 1)
gematik



Anpassungen gemäß Änderungsliste
gematik
3.10.0
28.10.16

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

freigegeben
gematik
3.12.0
28.11.18

Einarbeitung P15.11
gematik



Einarbeitung P18.1
gematik
3.13.0
15.05.19

freigegeben
gematik

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Dieses Dokument spezifiziert die Objektstruktur des Heilberufsausweises (HBA) und beschreibt die Kartenschnittstelle zu dem HBA für Angehörige approbierter Heilberufe. Die Spezifikation ist so aufgebaut, dass sie an die Anforderungen anderer Heilberufe angepasst werden kann.

Die Spezifikation berücksichtigt:

    • Die EU-Verordnung Nr. 910/2014 (eIDAS)
    • 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)

Die Spezifikation behandelt Anwendungen des elektronischen Heilberufsausweises (HBA) 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 eines HBA 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]. Diese Spezifikation ist Grundlage der Entwicklung der Kommandostrukturen und Funktionen für die Chipkartenbetriebssysteme.

Die „Äußere Gestaltung“ des HBA wird vom jeweils für die Ausgabe der HBAs verantwortlichen Sektor in eigener Verantwortung spezifiziert; dies ist nicht Aufgabe der gematik.

1.5 Methodik

1.5.1 Nomenklatur

‘1D’
Hexadezimale Zahlen und Oktettstrings werden in Hochkommata eingeschlossen.
x || y
Das Symbol || steht für die Konkatenierung von Oktettstrings oder Bitstrings:
‘1234’   ||   ‘5678’   =   ‘12345678’.

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

Langform
Kurzform
Informativ: AUT( CHA.1 )
C.1
Informativ: AUT( CHA.7 )
C.7
Informativ: AUT( CHA.2 )   OR   AUT( CHA.3 )
C.2.3
Informativ: PWD(PIN)   AND   [AUT( CHA.2 )  OR  AUT( CHA.3 )]
PWD(PIN)   AND   [C.2.3]
AUT(oid_cvc_fl_cms,’00010000000000’)
flagCMS.15
AUT(oid_cvc_fl_ti, ‘00010000000000’) OR AUT(oid_cvc_fl_ti, ‘00008000000000’)
flagTI.15 OR flagTI.16
PWD(PIN)  AND
[
    AUT(oid_cvc_fl_cms,’00010000000000’)
    OR
    AUT(oid_cvc_fl_ti, ‘00008000000000’)
]
PWD(PIN)   AND   [flagCMS.15 OR flagTI.16)]
SmMac(oid_cvc_fl_cms, ’00800000000000’)
SmMac(flagCMS.08)

Um die Zugriffsregeln für administrative Zugriffe in den einzelnen Tabellen übersichtlich darstellen zu können, werden folgende Abkürzungen verwendet:

AUT_CMS
          {SmMac(SK.CMS.AES128)
OR      SmMac(SK.CMS.AES256)
OR      SmMac(flagCMS.08)}
AND    SmCmdEnc
AND    SmRspEnc
AUT_CUP
          {SmMac(SK.CUP.AES128)
OR      SmMac(SK.CUP.AES256)
OR      SmMac(flagCMS.10)}
AND    SmCmdEnc
AND    SmRspEnc
AUT_PACE
           SmMac(SK.CAN)
AND    SmCmdEnc
AND    SmRspEnc

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 Zugriffsbedingunng angegeben. Beispielsweise (READ, UPDATE) nur, wenn SmMac(SK.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, 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 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_HBA_ObjSys_001 Liste der Komponenten, an welche dieses Dokument Anforderungen stellt

Komponente
Beschreibung
K_Initialisierung
Instanz, welche eine Chipkarte im Rahmen der Initialisierung befüllt
K_Personalisierung
Instanz, welche eine Chipkarte im Rahmen der Produktion individualisiert
K_COS
Betriebssystem einer Smartcard

2 Optionen

Dieses Unterkapitel listet Funktionspakete auf, die für eine Zulassung eines HBA der Generation 2 nicht zwingend erforderlich sind.

2.1 Option_Erstellung_von_Testkarten

Card-G2-A_3319 - K_Personalisierung K_Initialisierung Vorgaben für die Option_Erstellung_von_Testkarten

Der HBA KANN als Testkarte ausgestaltet werden. Soweit in dieser Spezifikation Anforderungen an Testkarten von den Anforderungen an Produktivkarten abweichen, wird dies an der entsprechenden Stelle aufgeführt.
[<=]

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

Card-G2-A_2036 - K_Initialisierung Anzahl logischer Kanäle

Für die Anzahl logischer Kanäle, die von einem HBA zu unterstützen ist, gilt:

    1. Die maximale Anzahl logischer Kanäle MUSS gemäß [ISO7816-4#Tab.88] in den Historical Bytes in EF.ATR angezeigt werden.
    2. Der HBA MUSS mindestens vier logische Kanäle unterstützen. Das bedeutet, die in den Bits b3b2b1 gemäß [ISO7816-4#Tab.88] kodierte Zahl MUSS mindestens ‘011’ = 3 oder größer sein.
[<=]

4.2 Unterstützung optionaler Funktionspakete

4.2.1 USB-Schnittstelle (optional)

Card-G2-A_3006 - K_HBA: USB-Schnittstelle

Falls ein HBA die Option_USB_Schnittstelle nutzen will, MUSS für das Objektsystem ein COS verwendet werden, das die Option_USB_Schnittstelle implementiert hat.

[<=]

Card-G2-A_2867 - K_HBA: Vorhandensein einer USB-Schnittstelle

Falls ein HBA die Option_USB_Schnittstelle nicht nutzen will, KANN für das Objektsystem ein COS verwendet werden,

    1. das die Option_USB_Schnittstelle implementiert hat.
    2. das die Option_USB_Schnittstelle nicht implementiert hat.

[<=]

4.2.2 Kontaktlose Schnittstelle (optional)

Card-G2-A_3007 - K_HBA: Kontaktlose Schnittstelle

Falls ein HBA die Option_kontaktlose_Schnittstelle nutzen will, MUSS für das Objektsystem ein COS verwendet werden, das die Option_kontaktlose_Schnittstelle implementiert hat.

[<=]

Card-G2-A_2866 - K_HBA: Vorhandensein einer kontaktlosen Schnittstelle

Falls ein HBA die Option_kontaktlose_Schnittstelle nicht nutzen will, KANN für das Objektsystem ein COS verwendet werden,

    1. das die Option_kontaktlose_Schnittstelle implementiert hat.
    2. das die Option_kontaktlose_Schnittstelle nicht implementiert hat.

[<=]

Card-G2-A_3009 - K_HBA: Zusatzanforderungen für kontaktlose Schnittstelle

Falls ein HBA die Option_kontaktlose_Schnittstelle nutzen will, dann MÜSSEN zusätzlich zu allen nicht gekennzeichneten Anforderungen auch alle Anforderungen erfüllt sein, die mit Option_kontaktlose_Schnittstelle gekennzeichnet sind.

[<=]

Card-G2-A_3010 - K_Initialisierung und K_Personalisierung: Kontaktlose Schnittstelle wird nicht genutzt

Will der Kartenherausgeber eines HBA mit einem COS, das die Option_kontaktlose_Schnittstelle gemäß [gemSpec_COS] implementiert hat, die Nutzung dieser Schnittstelle verhindern, dann MUSS das Attribut interfaceDependentAccessRules aller Objekte so gesetzt sein, dass im Rahmen einer kontaktlosen Kommunikation die Zugriffsregelauswertung AccessRuleEvaluation (siehe [gemSpec_COS#10.4] stets den Wert „False“ liefert.

[<=]

Card-G2-A_3011 - K_Initialisierung: Kontaktlose Schnittstelle im COS nicht vorhanden

Falls das COS für einen HBA die Option_kontaktlose_Schnittstelle nicht implementiert hat, MUSS der Teil des Attributes interfaceDependentAccessRules, welcher sich auf die kontaktlose Kommunikation bezieht, für alle Objekte irrelevant für die Zulassung sein.

[<=]

Card-G2-A_3012 - K_Personalisierung: Absicherung der kontaktlosen Schnittstelle

Falls ein HBA die Option_kontaktlose_Schnittstelle nutzen will, MUSS die Kommunikation zwischen Karte und Kartenleser mit einer gegenseitigen Authentifizierung und Aufbau eines sicheren Kommunikationskanals abgesichert werden. Hierfür MUSS das PACE-Protokoll genutzt werden.

[<=]

Card-G2-A_2038 - K_Personalisierung: Druck der CAN auf den HBA bei Verwendung der optionalen kontaktlosen Schnittstelle

Falls ein HBA die Option_kontaktlose_Schnittstelle nutzen will, MUSS das Attribut can des Objektes SK.CAN mit der Nummer übereinstimmen, die auf dem HBA aufgedruckt ist.

[<=]

Card-G2-A_3277 - K_Personalisierung und K_Initialisierung: Konformität kontaktlose Schnittstelle

Ein HBA mit kontaktloser Schnittstelle MUSS in seiner endgültigen Konfiguration (einschließlich Kartenkörper und Antenne) bezüglich der elektrischen Eigenschaften dieser kontaktlosen Schnittstelle konform zu [ISO-IEC 14443] und [ISO/IEC FCD 10373-6] sein.

[<=]

4.2.3 Kryptobox (optional)

Card-G2-A_3014 - K_HBA: Vorhandensein Kryptobox

Für einen HBA KANN für das Objektsystem ein COS verwendet werden,

    1. das die Option_Kryptobox implementiert hat
    2. das die Option_Kryptobox nicht implementiert hat.

[<=]

4.3 Attributstabellen

Card-G2-A_2032 - K_Initialisierung: Änderung von Zugriffsregeln

Die in diesem Dokument definierten Zugriffsregeln DÜRFEN in der Nutzungsphase NICHT veränderbar sein.

[<=]

Card-G2-A_2329 - K_Initialisierung: Verhalten der Objekte, kein konkretes SE genannt

Falls für die SE abhängigen Attribute eines Objektes kein konkretes SE genannt ist, dann MUSS sich dieses Objekt in SE#1 wie angegeben verwenden lassen.

[<=]

Card-G2-A_3182 - K_Initialisierung: Verwendbarkeit der Objekte in anderen SEs, kein konkretes SE genannt

Falls für die SE abhängigen Attribute eines Objektes kein konkretes SE genannt ist, dann KANN dieses Objekt in SE verwendbar sein, die verschieden sind von SE#1.

[<=]

Card-G2-A_3183 - K_Initialisierung: Eigenschaften der Objekte in anderen SEs, kein konkretes SE genannt

Falls für die SE abhängigen Attribute eines Objektes kein konkretes SE genannt ist und dieses Objekt in einem von SE#1 verschiedenen SE verwendbar ist, dann MUSS es dort dieselben Eigenschaften wie in SE#1 besitzen.

[<=]

Card-G2-A_3184 - K_Initialisierung: Verhalten der Objekte, konkretes SE genannt

Falls für die SE abhängigen Attribute eines Objektes ein konkretes SE genannt ist, dann MUSS sich dieses Objekt dort wie angegeben verwenden lassen.

[<=]

Card-G2-A_3185 - K_Initialisierung: Verwendbarkeit der Objekte in anderen SEs, konkretes SE genannt

Falls für die SE abhängigen Attribute eines Objektes ein konkretes SE genannt ist, dann KANN dieses Objekt in SE verwendbar sein, die nicht konkret genannt sind.

[<=]

Card-G2-A_3186 - K_Initialisierung: Eigenschaften der Objekte in anderen SEs, konkretes SE genannt

Falls für die SE abhängigen Attribute eines Objektes ein konkretes SE genannt ist und dieses Objekt ist in einem nicht konkret angegebenen SE verwendbar, dann MUSS es dort dieselben Eigenschaften wie in einem konkret angegebenen besitzen.

[<=]

4.3.1 Attribute eines Ordners

Card-G2-A_2033 - K_Initialisierung: Ordnerattribute

Enthält eine Tabelle mit Ordnerattributen

  1. keinen applicationIdentifier (AID), so KANN diesem Ordner herstellerspezifisch ein beliebiger AID zugeordnet werden.
  2. einen oder mehrere AID, dann MUSS sich dieser Ordner mittels aller angegebenen AID selektieren lassen.
  3. keinen fileIdentifier (FID),
    1. so DARF dieser Ordner NICHT mittels eines fileIdentifier aus dem Intervall gemäß [gemSpec_COS#8.1.1] selektierbar sein, es sei denn, es handelt sich um den Ordner root, dessen optionaler fileIdentifier den Wert ‘3F00’ besitzen MUSS.
    2. so KANN diesem Ordner ein beliebiger fileIdentifier außerhalb des Intervalls gemäß [gemSpec_COS#8.1.1] zugeordnet werden.
[<=]

4.3.2 Attribute einer Datei (EF)

Card-G2-A_2034 - K_Initialisierung: Dateiattribute

Enthält eine Tabelle mit Attributen einer Datei keinen shortFileIdentifier, so DARF sich dieses EF NICHT mittels shortFileIdentifier aus dem Intervall gemäß [gemSpec_COS#8.1.2] selektieren lassen.

[<=]

Card-G2-A_2673 - K_Personalisierung und K_Initialisierung: Wert von „positionLogicalEndOfFile“

Für transparente EFs MUSS der Wert von „positionLogicalEndOfFile“, soweit nicht anders spezifiziert, auf die Anzahl der tatsächlich belegten Bytes gesetzt werden.

[<=]

4.4 Zugriffsregeln für besondere Kommandos

Card-G2-A_2035 - K_Initialisierung: Zugriffsregeln für besondere Kommandos

Für Kommandos, für die eine Zugriffsregelauswertung gemäß [gemSpec_COS] optional ist, werden nicht in den Attributstabellen, sondern zentral in dieser Anforderung die Zugriffsbedingungen festgelegt:

    1. Für die kontaktbehaftete Schnittstelle MUSS die Zugriffsbedingung für die Kommandos GET CHALLENGE, LIST PUBLIC KEY, MANAGE SECURITY ENVIRONMENT und SELECT stets ALWAYS sein.

    2. Falls der HBA die Option_kontaktlose_Schnittstelle unterstützt, dann MUSS die Zugriffsbedingung für die Kommandos GET CHALLENGE, LIST PUBLIC KEY, MANAGE SECURITY ENVIRONMENT und SELECT stets ALWAYS sein.

    3. Falls ein Kartenherausgeber die Nutzung einer im COS vorhandenen kontaktlosen Schnittstelle unterbinden will, dann MUSS die Zugriffsbedingung für die Kommandos GET CHALLENGE, LIST PUBLIC KEY, MANAGE SECURITY ENVIRONMENT und SELECT für die kontaktlose Schnittstelle herstellerspezifisch stets entweder ALWAYS oder NEVER sein.


[<=]

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:

Card-G2-A_3325 - K_Initialisierung und K_Personalisierung: Abweichung von Festlegungen zum Zwecke der Personalisierung

Zur Unterstützung herstellerspezifischer Personalisierungsprozessen KÖNNEN die Werte von Attributen eines Kartenproduktes von den Festlegungen dieses Dokumentes abweichen. Hierbei MÜSSEN Abweichungen auf solche beschränkt sein, die hinsichtlich ihrer Wirkung in der personalisierten Karte sowohl fachlich wie sicherheitstechnisch der in der Spezifikation vorgegebenen Werten entsprechen.
[<=]

Für die Initialisierung und Personalisierung asymmetrischer Schlüssel gelten folgende Anforderungen:

Card-G2-A_3525 - K_Initialisierung: Schlüsselgenerierung auf der Karte

Der HBA MUSS die Generierung von asymmetrischen Schlüsselpaaren auf der Karte ermöglichen.

[<=]

Card-G2-A_3526 - K_Initialisierung: Weitere Verfahren zur Personalisierung von Schlüsseln

Der HBA KANN andere Verfahren als das in Card-G2-A_3525 genannte zur Personalisierung asymmetrischer Schlüsselpaare unterstützen.

[<=]

Card-G2-A_3523 - K_Personalisierung: Schlüsselgenerierung auf der Karte

Wenn ein privater Schlüssel für den HBA zu personalisieren ist, dann MUSS das Schlüsselpaar von der Smartcard selbst erzeugt werden. Es MUSS sichergestellt sein, dass der private Teil des Schlüssels die Smartcard nie verlässt.

[<=]

4.6 Kartenadministration

In den Kapiteln 5.3.16 und 5.3.17 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.

Card-G2-A_3005 - Absicherung der Kartenadministration

Bei der Personalisierung MUSS der Schlüssel PuK.RCA.ADMINCMS.CS für die asymmetrische Authentifizierung des Kartenadministrationssystems in die Karte eingebracht werden.
​​

[<=]

Card-G2-A_3590 - Symmetrische Kartenadministration

Bei der Personalisierung KÖNNEN die Schlüssel (SK.CMS und SK.CUP) für die symmetrische Authentifizierung des Kartenadministrationssystems in die Karte eingebracht werden.

[<=]

Card-G2-A_3591 - Schlüsselspeicherung

Der Kartenherausgeber MUSS sicherstellen, dass die Schlüssel zur Absicherung der Kartenadministration während der gesamten Nutzungsdauer des HBA sicher verwahrt werden und bei Bedarf an ein Kartenadministrationssystem (z.B. ein CUpS) übergeben werden können.

[<=]

5 Spezifikation grundlegender Applikationen

Zu den grundlegenden Applikationen des elektronischen Heilberufsausweises (HBA) zählen:

    • das Wurzelverzeichnis des HBA, auch root oder Master File (MF) genannt,
    • die Gesundheitsanwendung DF.HPA (Health Professional Application),
    • die Krypto-Anwendung DF.QES
    • die Beschreibung kryptographischer Objekte DF.CIA.QES
    • die Krypto-Anwendung DF.ESIGN
    • die Beschreibung kryptographischer Objekte DF.CIA.ESIGN
    • die organisationsspezifische Anwendung DF.AUTO.

5.1 Attribute des Objektsystems

Das Objektsystem [gemSpec_COS] enthält folgende Attribute:

Card-G2-A_2039 - K_Initialisierung: Wert des Attributes root

Der Wert des Attributes root MUSS die Anwendung gemäß Tab_HBA_ObjSys_004 sein.

[<=]

Card-G2-A_2040 - K_Personalisierung und K_Initialisierung: Wert des Attributes answerToReset

Die Werte der Attribute coldAnswerToReset und warmAnswerToReset MÜSSEN den Vorgaben der Anforderungen Card-G2-A_2043, Card-G2-A_2044, Card-G2-A_2045 und Card-G2-A_3015 entsprechen.

[<=]

Card-G2-A_2041 - K_Personalisierung: Wert des Attributes iccsn8

Der Wert des Attributes iccsn8 MUSS identisch zu den letzten acht Oktetts im body von EF.GDO sein.

[<=]

Card-G2-A_2042 - K_Initialisierung: Inhalt persistentPublicKeyList

Das Attribut persistentPublicKeyList MUSS die Schlüssel PuK.RCA.CS.R2048 und PuK.RCA.CS.E256 enthalten.

[<=]

Card-G2-A_3181 - K_Initialisierung: Größe persistentPublicKeyList

Für das Attribut persistentPublicKeyList MUSS so viel Speicherplatz bereitgestellt werden, dass mindestens fünf weitere öffentliche Signaturprüfschlüssel einer Root-CA mittels Linkzertifikaten persistent importierbar sind.

[<=]

Card-G2-A_3266 - K_Initialisierung: Wert von pointInTime

Das Attribut pointInTime MUSS den Wert '0000 0000 0000' = 2000.00.00 haben. Der Wert MUSS initialisiert werden.

[<=]

Card-G2-A_3395 - K_Personalisierung: personalisierter Wert von pointInTime

Das Attribut pointInTime MUSS im Rahmen der Personalisierung auf den Wert von CED eines Endnutzerzertifikates gesetzt werden. Falls es mehrere Endnutzerzertifikate gibt, so ist das CED mit dem größten Wert zu verwenden.

[<=]

5.1.1 ATR-Kodierung

Card-G2-A_2043 - K_Personalisierung und K_Initialisierung: ATR-Kodierung

Die ATR-Kodierung MUSS die in Tab_HBA_ObjSys_003 dargestellten Werte besitzen.

Tabelle 2: Tab_HBA_ObjSys_003 ATR-Kodierung (Sequenz von oben nach unten)

Zeichen

Wert

Bedeutung

TS

‘3B’

Initial Character (direct convention)

T0

‘9x’

Format Character (TA1/TD1 indication, x = no. of HB)

TA1

‘xx’

Interface Character (FI/DI, erlaubte Werte: siehe [gemSpec_COS#N024.100])

TD1

‘81’

Interface Character, (T=1, TD2 indication)

TD2

‘B1’

Interface Character, (T=1, TA3/TB3/TD3 indication)

TA3

‘FE’

Interface Character (IFSC coding)

TB3

‘45’

Interface Character, (BWI/CWI coding)

TD3

‘1F’

Interface Character, (T=15, TA4 indication)

TA4

‘xx’

Interface Character (XI/UI coding)

Ti

HB

Historical Bytes (HB, imax. = 15)

TCK

XOR

Check Character (exclusive OR)


​​

​​

[<=]

Card-G2-A_2044 - K_Personalisierung und K_Initialisierung: TC1 Byte im ATR

Der ATR SOLL ein TC1 Byte mit dem Wert FF enthalten. In diesem Fall MUSS T0 auf den Wert Dx gesetzt werden.

[<=]

Card-G2-A_3015 - K_Personalisierung und K_Initialisierung: Historical Bytes im ATR

Das Attribut answerToReset SOLL KEINE Historical Bytes enthalten.

[<=]

Card-G2-A_2045 - K_Personalisierung und K_Initialisierung: Vorgaben für Historical Bytes

Falls answerToReset Historical Bytes enthält, dann MÜSSEN

    1. diese gemäß [ISO7816-4] kodiert sein.
    2. die dort getroffenen Angaben konsistent sein zu Angaben im EF.ATR.

[<=]

5.2 Allgemeine Struktur

Card-G2-A_2046 - K_Personalisierung: Kompatibilität zu G1-Karten

Der HBA der Generation 2 MUSS rückwärtskompatibel zu den Karten der Generation 1 sein. Deshalb MUSS er bezüglich der CV-Zertifikate sowohl Zertifikate und Schlüssel für das RSA-Verfahren mit einer Schlüssellänge von 2048 bit (Generation 1) als auch Zertifikate und Schlüssel für die Verfahren mit elliptischen Kurven mit einer Schlüssellänge von 256 bit (Generation 2) enthalten.
[<=]

Abbildung 1: Abb_HBA_ObjSys_001 Allgemeine Dateistruktur eines HBA

5.3 Root, die Wurzelapplikation MF

MF ist ein „Application Dedicated File“ (siehe [gemSpec_COS#8.3.1.3]).

Card-G2-A_2047 - K_Initialisierung: Initialisierte Attribute von MF

MF MUSS die in Tab_HBA_ObjSys_004 dargestellten Werte besitzen.

Tabelle 3: Tab_HBA_ObjSys_004 Initialisierte Attribute von MF

Attribute

Wert

Bemerkung

Objekttyp

Ordner


applicationIdentifier

‘D27600014601’


fileIdentifier

‘3F 00’

falls vorhanden

lifeCycleStatus

„Operational state (activated)“


shareable

True


Zugriffsregeln für die Kontaktschnittstelle

Zugriffsregel für logischen LCS „Operational state (activated)“ kontaktbehaftet

Zugriffsart

Zugriffsbedingung

Bemerkung

FINGERPRINT

Wildcard


GET RANDOM

ALWAYS


LOAD APPLICATION

AUT_CMS

siehe Hinweis 4:

andere

NEVER


Zugriffsregel für logischen LCS „Operational state (deactivated)“ kontaktbehaftet

Zugriffsart

Zugriffsbedingung

Bemerkung

alle

herstellerspezifisch


Zugriffsregel für logischen LCS „Termination state” kontaktbehaftet

Zugriffsart

Zugriffsbedingung

Bemerkung

alle

herstellerspezifisch


Zugriffsregeln für die kontaktlose Schnittstelle (falls vorhanden)

Zugriffsregel für logischen LCS „Operational state (activated)” kontaktlos

Zugriffsart

Zugriffsbedingung

Bemerkung

GET RANDOM

ALWAYS


LOAD APPLICATION

AUT_CMS

siehe Hinweis 4:

andere

NEVER


Zugriffsregel für logischen LCS „Operational state (deactivated)” kontaktlos

Zugriffsart

Zugriffsbedingung

Bemerkung

alle

herstellerspezifisch


Zugriffsregel für logischen LCS „Termination state” kontaktlos

Zugriffsart

Zugriffsbedingung

Bemerkung

alle

herstellerspezifisch



​​

​​

​​

[<=]

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 lassen, sind diese Zustände für Objekte im Kapitel 5.3 im Allgemeinen irrelevant.

Hinweis 4: Nur dann ausführbar, wenn ein CMS genutzt wird (optional), siehe Kapitel 4.9

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.

Card-G2-A_2048 - K_Initialisierung: Initialisierte Attribute von MF / EF.ATR

EF.ATR MUSS die in Tab_HBA_ObjSys_005 dargestellten Werte besitzen.

Tabelle 4: Tab_HBA_ObjSys_005 Initialisierte Attribute von MF / EF.ATR

Attribute

Wert

Bemerkung

Objekttyp

transparentes Elementary File


fileIdentifier

‘2F 01’

siehe Hinweis 6:

shortFileIdentifier

‘1D’= 29


numberOfOctet

herstellerspezifisch


positionLogicalEndOfFile

Zahl der tatsächlich belegten Oktette


flagTransactionMode

True


flagChecksum

True


lifeCycleStatus

„Operational state (activated)“


shareable

True


body

Inhalt gemäß [gemSpec_Karten_Fach_TIP]

siehe unten

Zugriffsregeln für die Kontaktschnittstelle

Zugriffsregel für logischen LCS „Operational state (activated)” kontaktbehaftet

Zugriffsart

Zugriffsbedingung

Bemerkung

READ BINARY
WRITE BINARY

ALWAYS


andere

NEVER


Zugriffsregel für logischen LCS „Operational state (deactivated)” kontaktbehaftet

Zugriffsart

Zugriffsbedingung

Bemerkung

alle

herstellerspezifisch


Zugriffsregel für logischen LCS „Termination state“ ” kontaktbehaftet

Zugriffsart

Zugriffsbedingung

Bemerkung

alle

herstellerspezifisch


Zugriffsregeln für die kontaktlose Schnittstelle (falls vorhanden)

Zugriffsregel für logischen LCS „Operational state (activated)” kontaktlos

Zugriffsart

Zugriffsbedingung

Bemerkung

READ BINARY
WRITE BINARY

ALWAYS


andere

NEVER


Zugriffsregel für logischen LCS „Operational state (deactivated)” kontaktlos

Zugriffsart

Zugriffsbedingung

Bemerkung

alle

herstellerspezifisch


Zugriffsregel für logischen LCS „Termination state“ kontaktlos

Zugriffsart

Zugriffsbedingung

Bemerkung

alle

herstellerspezifisch



​​

[<=]

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.

Card-G2-A_3278 - K_Initialisierung: Initialisiertes Attribut numberOfOctet von MF / EF.ATR

Das Attribut numberOfOctet MUSS so gewählt werden, dass nach Abschluss der Initialisierungsphase entweder

  • genau 23 Oktette für die Artefakte PT_Pers und PI_Personalisierung frei bleiben, falls PI_Kartenkörper initialisiert wird, oder

  • genau 41 Oktette für die Artefakte PI_Kartenkörper, PT_Pers und PI_Personalisierung frei bleiben.

[<=]

5.3.2 MF / EF.CardAccess (Option kontaktlose Schnittstelle)

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

Card-G2-A_3199 - K_Initialisierung: Initialisierte Attribute von MF / EF.CardAccess

Falls die kontaktlose Schnittstelle für den HBA genutzt wird, MUSS EF.CardAccess vorhanden sein und die in Tab_HBA_ObjSys_083 dargestellten Attribute besitzen.

Tabelle 5: Tab_HBA_ObjSys_083 Initialisierte  Attribute von MF / EF.CardAccess

Attribute
Wert
Bemerkung
Objekttyp
transparentes Elementary File

fileIdentifier
’01 1C’

shortFileIdentifier
‘1C’= 28

lifeCycleStatus
„Operational state (activated)“

flagTransactionMode
False

flagChecksum
True

numberOfOctet
passend zum Inhalt

positionLogicalEndOfFile
passend zum Inhalt

shareable
True

body
passend zu den Attributen von SK.CAN gemäß [TR-03110-3]

Zugriffsregeln für die Kontaktschnittstelle
Zugriffsart
Zugriffsbedingung
Bemerkung
Zugriffsregel für logischen LCS „Operational state (activated)” kontaktbehaftet
READ BINARY
ALWAYS

andere
NEVER

Zugriffsregel für logischen LCS „Operational state (deactivated)” kontaktbehaftet
alle
herstellerspezifisch

Zugriffsregel für logischen LCS „Operational state (terminated)” kontaktbehaftet
alle
herstellerspezifisch

Zugriffsregeln für die kontaktlose Schnittstelle (falls vorhanden)
Zugriffsregel für logischen LCS „Operational state (activated)” kontaktlos
READ BINARY
ALWAYS

andere
NEVER

Zugriffsregel für logischen LCS „Operational state (deactivated)” kontaktlos
alle
herstellerspezifisch

Zugriffsregel für logischen LCS „Operational state (terminated)” kontaktlos
alle
herstellerspezifisch


[<=]

5.3.3 MF / EF.DIR

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

Card-G2-A_2055 - K_Initialisierung: Initialisierte Attribute von MF / EF.DIR

EF.DIR MUSS die in Tab_HBA_ObjSys_007 dargestellten Werte besitzen.

Tabelle 6: Tab_HBA_ObjSys_007 Initialisierte Attribute von MF / EF.DIR

Attribute

Wert

Bemerkung

Objekttyp

linear variables Elementary File


fileIdentifier

‘2F 00’

Siehe Hinweis 8:

shortFileIdentifier

‘1E’= 30

Siehe Hinweis 8:

numberOfOctet

‘00 BE’ Oktett = 190 Oktett


maxNumRecords

10 Rekord


maxRecordLength

32 Oktett


flagRecordLCS

False


flagTransactionMode

True


flagChecksum

True


lifeCycleStatus

„Operational state (activated)“


shareable

True


recordList
    Rekord 1
    Rekord 2
    Rekord 3
    Rekord 4
    Rekord 5
    Rekord 6

    Rekord 7
    Rekord 8
    …


‘61- 08- (4F 06 D27600014601)’
‘61- 08- (4F 06 D27600014602)’
‘61- 08- (4F 06 D27600006601)’
‘61- 0D- (4F 0B E828BD080F D27600006601)’
‘61- 0C- (4F 0A A000000167 455349474E)’
‘61- 11- (4F 0F E828BD080F A000000167 455349474E)’
61- 08- (4F 06 D27600014603)’
nicht vorhanden, MUSS mittels APPEND RECORD angelegt werden


AID.MF
AID.HPA
AID.QES
AID.CIA.QES
AID.ESIGN
AID.CIA ESIGN

AID AUTO

Zugriffsregeln für die Kontaktschnittstelle

Zugriffsregel für logischen LCS „Operational state (activated)“ kontaktbehaftet

Zugriffsart

Zugriffsbedingung

Bemerkung

APPEND RECORD

AUT_CMS

siehe Hinweis 8:.

DELETE RECORD

AUT_CMS

siehe Hinweis 8:

READ RECORD
SEARCH RECORD

ALWAYS


UPDATE RECORD

AUT_CMS

siehe Hinweis 8:

andere

NEVER


Zugriffsregel für logischen LCS „Operational state (deactivated)“ kontaktbehaftet

Zugriffsart

Zugriffsbedingung

Bemerkung

alle

herstellerspezifisch


Zugriffsregel für logischen LCS „Termination state” kontaktbehaftet

Zugriffsart

Zugriffsbedingung

Bemerkung

alle

herstellerspezifisch


Zugriffsregeln für die kontaktlose Schnittstelle (falls vorhanden)

Zugriffsregel für logischen LCS „Operational state (activated)” kontaktlos

Zugriffsart

Zugriffsbedingung

Bemerkung

APPEND RECORD

AUT_CMS

siehe Hinweis 9:

DELETE RECORD

AUT_CMS

siehe Hinweis 9:

READ RECORD
SEARCH RECORD

AUT_PACE
OR    AUT_CMS


UPDATE RECORD

AUT_CMS

siehe Hinweis 9:

andere

NEVER


Zugriffsregel für logischen LCS „Operational state (deactivated)” kontaktlos

Zugriffsart

Zugriffsbedingung

Bemerkung

alle

herstellerspezifisch


Zugriffsregel für logischen LCS „Termination state” kontaktlos

Zugriffsart

Zugriffsbedingung

Bemerkung

alle

herstellerspezifisch



​​

[<=]

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.

Hinweis 9: Das Kommando ist nur vom Inhaber des CMS- / CUP-Schlüssels ausführbar, siehe Kapitel 5.9.

5.3.4 MF / EF.GDO

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

Card-G2-A_2057 - K_Initialisierung: Initialisierte Attribute von MF / EF.GDO

EF.GDO MUSS die in Tab_HBA_ObjSys_008 dargestellten Werte besitzen.

Tabelle 7: Tab_HBA_ObjSys_008 Initialisierte Attribute von MF / EF.GDO

Attribute
Wert
Bemerkung
Objekttyp
transparentes Elementary File

fileIdentifier
‘2F 02’

shortFileIdentifier
‘02’= 2

numberOfOctet
‘00 0C’ Oktett = 12 Oktett

positionLogicalEndOfFile
'0'

flagTransactionMode
False

flagChecksum
True

lifeCycleStatus
„Operational state (activated)“

shareable
True

body
Wildcard
wird personalisiert
Zugriffsregeln für die Kontaktschnittstelle
Zugriffsregel für logischen LCS „Operational state (activated)“ kontaktbehaftet
Zugriffsart
Zugriffsbedingung
Bemerkung
READ BINARY
ALWAYS

andere
NEVER

Zugriffsregel für logischen LCS „Operational state (deactivated)“ kontaktbehaftet
Zugriffsart
Zugriffsbedingung
Bemerkung
alle
herstellerspezifisch

Zugriffsregel für logischen LCS „Termination state“ kontaktbehaftet
Zugriffsart
Zugriffsbedingung
Bemerkung
alle
herstellerspezifisch

Zugriffsregeln für die kontaktlose Schnittstelle (falls vorhanden)
Zugriffsregel für logischen LCS „Operational state (activated)” kontaktlos
Zugriffsart
Zugriffsbedingung
Bemerkung
READ BINARY
AUT_PACE

andere
NEVER

Zugriffsregel für logischen LCS „Operational state (deactivated)” kontaktlos
Zugriffsart
Zugriffsbedingung
Bemerkung
alle
herstellerspezifisch

Zugriffsregel für logischen LCS „Termination state” kontaktlos
Zugriffsart
Zugriffsbedingung
Bemerkung
alle
herstellerspezifisch


[<=]

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.

Card-G2-A_2058 - K_Personalisierung: Personalisiertes Attribut von EF.GDO

Bei der Personalisierung von EF.GDO MÜSSEN die in Tab_HBA_ObjSys_151 angegebenen Attribute mit den dort angegebenen Inhalten personalisiert werden.


Tabelle 8: Tab_HBA_ObjSys_151 Personalisierte Attribute von MF / EF.GDO

Attribute

Wert

Bemerkung

positionLogicalEndOfFile

00 0C Oktett = 12 Oktett


body

Inhalt gemäß [gemSpec_Karten_Fach_TIP]  



[<=]

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

Card-G2-A_2059 - K_Initialisierung: Attribute von MF / EF.Version2

EF.Version2 MUSS die in Tab_HBA_ObjSys_009 dargestellten Werte besitzen.

Tabelle 9: Tab_HBA_ObjSys_009 Initialisierte Attribute von MF / EF.Version2

Attribute

Wert

Bemerkung

Objekttyp

transparentes Elementary File


fileIdentifier

‘2F 11’


shortFileIdentifier

‘11’= 17


numberOfOctet

‘00 3C’ Oktett = 60 Oktett


positionLogicalEndOfFile

passend zum Inhalt


flagTransactionMode

True


flagChecksum

True


lifeCycleStatus

„Operational state (activated)“


shareable

True


body

Inhalt gemäß [gemSpec_Karten_Fach_TIP]


Zugriffsregeln für die Kontaktschnittstelle

Zugriffsregel für logischen LCS „Operational state (activated)“ kontaktbehaftet

Zugriffsart

Zugriffsbedingung

Bemerkung

READ BINARY

ALWAYS


UPDATE BINARY
SET LOGICAL EOF

AUT_CMS

siehe Hinweis 12:

andere

NEVER


Zugriffsregel für logischen LCS „Operational state (deactivated)“ kontaktbehaftet

Zugriffsart

Zugriffsbedingung

Bemerkung

alle

herstellerspezifisch


Zugriffsregel für logischen LCS „Termination state” kontaktbehaftet

Zugriffsart

Zugriffsbedingung

Bemerkung

alle

herstellerspezifisch


    • Zugriffsregeln für die kontaktlose Schnittstelle (falls vorhanden)

Zugriffsregel für logischen LCS „Operational state (activated)” kontaktlos

Zugriffsart

Zugriffsbedingung

Bemerkung

READ BINARY

ALWAYS


UPDATE    BINARY
SET LOGICAL EOF

AUT_CMS

siehe Hinweis 12:

andere

NEVER


Zugriffsregel für logischen LCS „Operational state (deactivated)” kontaktlos

Zugriffsart

Zugriffsbedingung

Bemerkung

alle

herstellerspezifisch


Zugriffsregel für logischen LCS „Termination state” kontaktlos

Zugriffsart

Zugriffsbedingung

Bemerkung

alle

herstellerspezifisch



​​

[<=]

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, siehe Kapitel 5.9.

5.3.6 MF / EF.C.CA_HPC.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_HPC.CS.R2048 einer CA enthält.

Card-G2-A_2060 - K_Initialisierung: Initialisierte Attribute von MF / EF.C.CA_HPC.CS.R2048

EF.C.CA_HPC.CS.R2048 MUSS die in Tab_HBA_ObjSys_010 dargestellten Werte besitzen.

Tabelle 10: Tab_HBA_ObjSys_010 Initialisierte Attribute von MF / EF.C.CA_HPC.CS.R2048

Attribute

Wert

Bemerkung

Objekttyp

transparentes Elementary File


fileIdentifier

‘2F 04’


shortFileIdentifier

‘04’= 4


numberOfOctet

‘01 4B’ Oktett = 331 Oktett


positionLogicalEndOfFile

‘0’


flagTransactionMode

False


flagChecksum

False


lifeCycleStatus

„Operational state (activated)“


shareable

True


body

kein Inhalt

wird personalisiert

Zugriffsregeln für die Kontaktschnittstelle

Zugriffsregel für logischen LCS „Operational state (activated)“ kontaktbehaftet

Zugriffsart

Zugriffsbedingung

Bemerkung

DELETE

AUT_CMS OR AUT_CUP

siehe Hinweis 14:

READ BINARY

ALWAYS


andere

NEVER


Zugriffsregel für logischen LCS „Operational state (deactivated)“ kontaktbehaftet

Zugriffsart

Zugriffsbedingung

Bemerkung

alle

herstellerspezifisch


Zugriffsregel für logischen LCS „Termination state” kontaktbehaftet

Zugriffsart

Zugriffsbedingung

Bemerkung

alle

herstellerspezifisch


Zugriffsregeln für die kontaktlose Schnittstelle (falls vorhanden)

Zugriffsregel für logischen LCS „Operational state (activated)” kontaktlos

Zugriffsart

Zugriffsbedingung

Bemerkung

DELETE

AUT_CMS OR AUT_CUP

siehe Hinweis 14:

Read Binary

AUT_PACE


andere

NEVER


Zugriffsregel für logischen LCS „Operational state (deactivated)” kontaktlos

Zugriffsart

Zugriffsbedingung

Bemerkung

alle

herstellerspezifisch


Zugriffsregel für logischen LCS „Termination state” kontaktlos

Zugriffsart

Zugriffsbedingung

Bemerkung

alle

herstellerspezifisch



​​

[<=]

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- / CUP-Schlüssels ausführbar, siehe Kapitel 5.9.

Card-G2-A_3281 - K_Personalisierung: Personalisierte Attribute von MF / EF.C.CA_HPC.CS.R2048

Bei der Personalisierung von EF.C.CA_HPC.CS.R2048 MÜSSEN die in Tab_HBA_ObjSys_089 angegebenen Attribute mit den dort angegebenen Inhalten personalisiert werden.

Tabelle 11: Tab_HBA_ObjSys_089 Personalisierte Attribute von MF / EF.C.CA_HPC.CS.R2048

Attribute

Wert

Bemerkung

positionLogicalEndOfFile

‘01 4B’ Oktett = 331 Oktett

bis 31.12.2018

body

C.CA_HPC.CS.R2048 gemäß [gemSpec_PKI]

bis 31.12.2018

positionLogicalEndOfFile

'0' oder '01 4B', passend zur Personalisierung des Attributsbody

ab 01.01.2019

body

unbefüllt oder vollständig '00 ... 00'

ab 01.01.2019

body
Option_Erstellung _von_Testkarten

C.CA_HPC.CS.R2048 gemäß [gemSpec_PKI]
aus Test-CVC-CA

Details siehe [gemSpec_TK#3.1.2]


[<=]

5.3.7 MF / EF.C.CA_HPC.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_HPC.CS.E256 einer CA enthält.

Card-G2-A_2061 - K_Initialisierung: Initialisierte Attribute von MF / EF.C.CA_HPC.CS.E256

EF.C.CA_HPC.CS.E256 MUSS die in Tab_HBA_ObjSys_011 dargestellten Werte besitzen.

Tabelle 12: Tab_HBA_ObjSys_011 Initialisierte Attribute von MF / EF.C.CA_HPC.CS.E256

Attribute

Wert

Bemerkung

Objekttyp

transparentes Elementary File


fileIdentifier

‘2F 07’


shortFileIdentifier

‘07’= 7


numberOfOctet

‘00 DC’ Oktett = 220 Oktett


positionLogicalEndOfFile

‘0’


flagTransactionMode

True


flagChecksum

False


lifeCycleStatus

„Operational state (activated)“


shareable

True


body

kein Inhalt

wird personalisiert

Zugriffsregeln für die Kontaktschnittstelle

Zugriffsregel für logischen LCS „Operational state (activated)“ kontaktbehaftet

Zugriffsart

Zugriffsbedingung

Bemerkung

DELETE

AUT_CMS OR AUT_CUP

siehe Hinweis 14:

READ BINARY

ALWAYS


UPDATE BINARY

AUT_CMS OR AUT_CUP

siehe Hinweis 14:

andere

NEVER


Zugriffsregel für logischen LCS „Operational state (deactivated)“ kontaktbehaftet

Zugriffsart

Zugriffsbedingung