gemSpec_COS_V3.10.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation des Card Operating System (COS)

Elektrische Schnittstelle

    

     

      
Version
      
3.10.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
21.04.2017
     
     

      
Status
      
in Bearbeitung
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_COS
     
    

Dokumentinformationen

Es handelt sich hier um eine veränderte Fassung des Dokumentes für Karten der Generation 2.1.

Die wichtigsten Änderungen gegenüber der Betriebssystemspezifikation der Generation 2 sind:

1. Der DES Algorithmus wurde aus dem normativen Umfang in ein optionales Funktionspaket verschoben, siehe (N000.030), entsprechende Performanzvorgaben wurden entfernt.
2. CV-Zertifikate basierend auf dem RSA Algorithmus wurden in ein optionales Funktionspaket verschoben, siehe (N000.032) entsprechende Performanzvorgaben wurden entfernt.
3. Performanzvorgaben angepasst, das bedeutet:
1. Dort, wo die zugelassenen G2 COS deutlich performanter sind, wurden strengere Werte gesetzt und
2. dort, wo die Performanzvorgaben viel zu streng waren, wurden sie an den Stand der Technik angepasst.
4. Anforderungen zur Kürzung von keyReferenceList im Kommando LIST PUBLIC KEY präzisiert.
5. Die RSA Schlüsselgenerierung wurde aus dem normativen Umfang in ein optionales Funktionspaket verschoben, siehe (N000.034).

Die wichtigsten Änderungen gegenüber den Betriebssystemspezifikationen der Generation 1 sind:

1. Alle Betriebssystemspezifikationen der Generation 1 wurden in diesem Dokument zusammengefasst.
2. Alle SRQs zu den Betriebssystemspezifikationen wurden integriert.
3. Die kontaktlose Datenübertragung und die Datenübertragung gemäß [ISO/IEC 7816-12] wurden aufgenommen.
4. Die Kryptographie gemäß [FIPS 197] (AES) und [BSI-TR-03111] (elliptische Kurven) wurden dem normativen Teil hinzugefügt.
5. Für RSA-Schlüssel ist die Moduluslänge von 3072 bit zu unterstützen.

Dokumentenhistorie

Inhaltsverzeichnis

1 CosK_c31 Einordnung des Dokuments (informativ)

1.1 CosK_c52 Zielsetzung

Diese Spezifikation definiert die Anforderungen an die Funktionalität einer Betriebssystemplattform (COS-Plattform) für elektronische Karten im Gesundheitswesen (eGK, HBA, …), die internationalen Standards entsprechen und die internationale sowie europäische Interoperabilität sicherstellen.

Im Einzelnen werden auf der Basis von [ISO/IEC 7816-4], [ISO/IEC 7816-8] und [ISO/IEC 7816-9] Kommandos und Optionen beschrieben, die vom COS zu unterstützen sind.

Der Aufbau dieses Dokumentes gliedert sich wie folgt:

• CosK_c31 Einordnung des Dokuments enthält Aussagen zum Umgang mit diesem Dokument.
• CosK_70a Optionen beschreibt und listet Funktionspakete, die nicht zwingend in allen Kartentypen vorhanden sind. wird in einer späteren Version Eingangsanforderungen enthalten, welche die Basis für die normativen Aussagen in späteren Kapiteln bilden werden.
• CosK_c19 Systemüberblick wird in einer späteren Version Grundlagen zu Betriebssystemen für Smartcards enthalten, die auf der Normenreihe ISO/IEC 7816 basieren.
• CosK_91f Lebenszyklus von Karte und Applikation grenzt den Gültigkeitsbereich der Spezifikation aus zeitlicher Sicht ab.
• CosK_2b8 Datentypen und Datenkonvertierung definiert einige grundlegende Datentypen, welche die normativen Beschreibungen in späteren Kapiteln vereinfachen.
• CosK_ab0 Kryptographische Algorithmen definiert einige grundlegende kryptographische Funktionen, welche die normativen Beschreibungen in späteren Kapiteln vereinfachen.
• CosK_81a CV-Zertifikat beschreibt Zertifikate, welche zu nutzen sind, um öffentliche Schlüssel in eine Smartcard zu importieren.
• CosK_f55 Objekte enthält eine Art Klassendiagramm in textueller Form. Die dort definierten Objekte und Attribute vereinfachen die normativen Beschreibungen in nachfolgenden Kapiteln.
• CosK_e16 Objektsystem beschreibt, wie sich Informationen persistent auf einer Smartcard hierarchisch speichern lassen.
• CosK_893 Zugriffskontrolle beschreibt den Schutz von Informationen auf einer Smartcard vor unberechtigtem Zugriff.
• CosK_581 Kommunikation beschreibt, wie die Smartcard Informationen mit anderen Systemen austauscht.
• CosK_d0b Kanalkontext beschreibt die Informationen, welche volatil und kanalspezifisch (zu logischen Kanälen siehe auch [ISO/IEC 7816-4]) von der Smartcard gespeichert werden.
• CosK_2ff Gesicherte Kommunikation beschreibt, wie die Smartcard Informationen kryptographisch geschützt mit anderen Systemen austauscht.
• CosK_3a7 Kommandos enthält normative Aussagen zu Kommandos, welche an eine Smartcard geschickt werden und normative Aussagen, wie diese Kommandos von der Smartcard zu bearbeiten sind. Im Wesentlichen ist dies das wichtigste Kapitel des Dokumentes, weil es die äußere Sichtweise auf das Verhalten der Smartcard an der elektrischen Schnittstelle am umfassendsten beschreibt.
• CosK_8e4 Authentisierungsprotokolle beschreibt Sequenzen, die aus mehr als einem Kommando bestehen.
• CosK_b1b Verschiedenes spezifiziert konkrete Werte für eine Reihe von Platzhaltern.
• CosK_9b0 Vorgaben zur Performanz enthält Anforderungen an einen Performanztest
  

Das Dokument ist „bottom up“ aufgebaut, das bedeutet, Artefakte werden zunächst beschrieben und definiert, bevor sie verwendet werden. Für eine „top down“ Herangehensweise empfiehlt es sich, mit Kapitel CosK_3a7 zu beginnen. Dort werden, wenn möglich, Verweise auf andere Kapitel gesetzt, wenn Dinge dort ausführlicher beschrieben werden. Wegen der besonderen Bedeutung des Kapitels CosK_3a7 wird dessen Aufbau im Folgenden näher beleuchtet:

Kapitel CosK_3a7enthält alle in der Normenreihe ISO/IEC 7816 standardisierten Kommandos. Der besseren Übersichtlichkeit halber ist Kapitel CosK_3a7 unterteilt in die Abschnitte Management des Objektsystems, Zugriff auf Daten in transparenten EF, Zugriff auf strukturierte Daten, Benutzerverifikation, Komponentenauthentisierung, Kryptoboxkommandos und Verschiedenes. Jeder Abschnitt enthält eine Reihe von Unterabschnitten mit Kommandos in alphabetischer Reihenfolge.

1.2 CosK_ec4 Zielgruppe

Das Dokument richtet sich an Hersteller von Smartcard-Betriebssystemen und an Hersteller von Anwendungen, welche unmittelbar mit einer Smartcard kommunizieren.

1.3 CosK_a38 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z.B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Der Inhalt des Dokumentes ist verbindlich für die Erstellung elektronischer Karten im Gesundheitswesen.

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 CosK_4d2 Abgrenzung des Dokuments

Dieses Dokument spezifiziert das Verhalten an der elektrischen Schnittstelle zu einem Smartcard-Betriebssystem (Card Operating System, COS). Dieses Dokument spezifiziert NICHT die Architektur des COS. Der einfacheren Darstellung wegen, wird in diesem Dokument von einer modularen Aufteilung des COS ausgegangen. Die hier beschriebene Aufteilung ist nicht verpflichtend. Es wird aber empfohlen, sich an dieser Aufteilung zu orientieren, weil bei künftigen Ergänzungen und Erweiterungen die hier beschriebene Aufteilung zu Grunde gelegt wird.

Die Konfiguration einer Smartcard, also die Festlegung, welche Applikationen, Ordner, Dateien, Schlüssel und Passwörter etwa auf einer Versichertenkarte zu finden sind, ist nicht Gegenstand dieses Dokumentes. Diese finden sich den kartenspezifischen Festlegungen zum Objektsystem (z. B. in [gemSpec_eGK_ObjSys], [gemSpec_HBA_ObjSys], [gemSpec_SMC-B_ObjSys]).

In Absprache mit den Verantwortlichen des Dokumentes [gemSpec_Krypt] werden in diesem Dokument bewusst Redundanzen zum vorgenannten Dokument akzeptiert. Trotzdem ist [gemSpec_Krypt] relevant für eine konkrete Karte, da dort, anders als in diesem Dokument, normative Vorgaben für die Nutzungsdauer gewisser kryptographischer Verfahren getroffen werden, die hier beschrieben werden.

1.5 Methodik

1.5.1 Nomenklatur der Präfixe

Tabelle 1, CosT_1e0: Präfixe, die auf Vielfachen von Zehnerpotenzen beruhen:

Die folgende Tabelle basiert auf [BinPrefix].

Tabelle 2, CosT_c5e: Präfixe, die auf Vielfachen von Zweierpotenzen beruhen:

Hinweis CosH_3d9: Beispiel: 300 GB ≈ 279,4 GiB, sprich 300 Gigabyte sind ungefähr 279,4 Gibibyte.

1.5.2 Nomenklatur Verschiedenes

In diesem Dokument wird eine objektorientierte Sichtweise verfolgt. Dazu werden etwa die Artefakte Datei (EF in der Nomenklatur nach [ISO/IEC 7816-4]) oder Schlüssel als Objekte aufgefasst und die Eigenschaften als Attribute des Objektes. Wenn Attribute eines Objektes angesprochen werden, dann wird die Notation obj.attribute verwendet. Wenn das Attribut wieder ein Objekt mit weiteren Attributen ist, dann sind auch längere Bezeichnungen möglich.

Tabelle 3, CosK_9f7: Abkürzungen und Definitionen

Spezifikationen werden nun mit Polarion statt mit Word erstellt. Das hat folgende Auswirkungen:

1. In der Normenreihe ISO/IEC 7816 ist es üblich Kommandonamen mit Kapitälchen darzustellen. In dieser Dokumentenversion Kommandonamen in einem anderen Font dargestellt, beispielsweise READ BINARY, PSO Compute Digital Signature.
2. Die N-Nummern enthalten oft eine Untergliederung in Unterpunkte, Unter-Unterpunkte, etc. Die Numerierung erfolgt in Word und Polarion teilsweise unterschiedlich:
1. Die erste Gliederungsstufe ist sowohl in Word, als auch in Polarion alphabetisch: a, b, c, d, ...
1. Die zweite Gliederungsstufe erfolgt numerisch mit arabischen Ziffern (Word: 1, 2, ...) bzw kleinen römischen Ziffern (Polarion: i, ii, iii, iv, v, ...)
1. Die dritte Gliederungsstufe erfolgt in Word numerisch mit kleinen römischen Ziffern (i, ii, iii, iv, v, vi, ...) und in Polarion alphabetisch mit Großbuchstaben (A, B, C, ...).
1. Die vierte Gliederungsstufe erfolgt in Word alphabetisch mit Großbuchstaben (A, B, C, ...) und in Polarion numerisch mit großen römischen Ziffern (I, II, III, IV, V, VI, ...)
   
1. Weitere Gliederungsebenen werden in diesem Dokument nicht verwendet.
2. Daraus folgt, dass Referenzen auf N-Nummern sich von der Word-Version hin zur Polarion-Version unterscheiden, aber ineinander umrechenbar sind. Zudem ist erkennbar, falls in der Polarion-Version die Umrechnung unterblieb. Beispiel: Eine Referenz auf (N654.321)a.7.ii.D ist eine Word-Version, die in Polarion so lautet: (N654.321)a.vii.B.IV. Abgesehen von dieser anderen Art der Darstellung von N-Nummern auf tieferen Gliederungsebenen sind die N-Nummern in Polarion identisch zu den N-Nummern in der Word-Version.
   

1.5.3 Normative und informative Abschnitte

Abschnitte mit normativen Inhalten tragen hinter der Kapitelüberschrift den Hinweis:

(normativ)

Generell gilt, dass lediglich die Gliederungen, welche durch eine Nummer (N4711) gekennzeichnet sind, zulassungsrelevante Eigenschaften enthalten und somit im Rahmen der Zulassung getestet werden. Falls dies in einem speziellen Fall nicht so ist, handelt es sich höchstwahrscheinlich um einen editorischen Fehler.

1.5.4 Komponentenspezifische Anforderungen

Da es sich beim vorliegenden Dokument um die Spezifikation einer Schnittstelle zwischen mehreren Komponenten handelt, ist es unvermeidlich, dass dieses Dokument Anforderungen für jede der Komponenten enthält. Die normativen Abschnitte tragen deshalb eine Kennzeichnung, auf welche Komponente sich die Anwendung primär bezieht. Dabei gelten natürlicherweise folgende Zusammenhänge:

• Alle normativen Anforderungen an die Komponenten K_Anwendungsspezifikation und K_externeWelt sind auch normative Anforderungen an diejenigen Komponenten, die in den jeweiligen Mengenklammern genannt sind.
• Für eine in der Mengenklammer aufgeführte Komponente ist es zulässig, mehr zu unterstützen als durch K_Anwendungsspezifikation oder K_externeWelt gefordert.
• Für eine in der Mengenklammer aufgeführte Komponente ist es zulässig, die Unterstützung von Dingen abzulehnen, die durch K_Anwendungsspezifikation oder K_externeWelt nicht gefordert werden.

Die obigen Aussagen werden im Folgenden durch Beispiele verdeutlicht:

• In (N007.900) wird von K_Anwendungsspezifikation {K_Karte} gefordert, nur bestimmte seIdentifier zu verwenden, wenn die Anwendungsspezifikation für die Komponente K_COS bestimmt ist. Damit ist auch die maximale Anzahl von möglichen Security Environments in der Anwendung beschränkt. Einer Anwendungsspezifikation ist es nicht erlaubt, mehr SEs zu verwenden. Für das COS der Komponente K_COS bedeutet dies, dass es mindestens diese maximale Anzahl an SE zu unterstützen hat. Für das COS der Komponente K_COS ist es sowohl zulässig, mehr SEs zu unterstützen als auch zusätzliche SEs abzulehnen.
• In CosK_05a und CosK_1f5 werden im Zusammenhang mit dem Kommando READ BINARY Anforderungen an K_externeWelt {K_Karte} gestellt. Für die externe Welt ist es unzulässig, andere READ BINARY-Varianten zu verwenden. Für das COS bedeutet dies, dass es mindestens diese Varianten zu unterstützen hat. Für das COS ist es sowohl zulässig. mehr READ BINARY-Varianten zu unterstützen als auch zusätzliche READ BINARY-Varianten abzulehnen.

Tabelle 4, CosT_485: Liste der Komponenten, an welche dieses Dokument Anforderungen stellt

1.5.5 Verwendung von Schlüsselworten

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in Klammern sowie die dem [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet. Konjugationen von „MUSS“ zu „MÜSSEN“ etc. sind der Grammatik geschuldet. Falls in einem speziellen Fall die Verben müssen, dürfen, sollen, können ohne einen einzigen Großbuchstaben verwendet werden, handelt es sich höchstwahrscheinlich um einen editorischen Fehler.

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 stattdessen „Eine leere Liste DARF KEIN Element besitzen.“ verwendet.

In dieser Version wird das Verb "kann" in normativen Festlegungen nur noch für optionale Funktionspakete verwendet, aber nicht länger im Sinne von "zulässigen Implementierungsvarianten" oder "herstellerspezifischen Erweiterungen". Beispiel alt: (N002.200) Das COS KANN weitere Moduluslängen unterstützen oder ablehnen. Die gematik betrachtet normative Festlegungen mit dem Verb "kann" als Implementierungsvarianten und erfragt bei Herstellern welche konkrete Ausprägung gewählt wurde. Das ist im gezeigten Beispiel sinnlos. Deshalb wird die etwa in (N002.200) an einen Hersteller gerichtete Erlaubnis bestimmte Erweiterungen vorzunehmen oder zu unterlassen methodenkonform angepasst.

In diesem Dokument werden Aussagen mit dem Schlüsselwort KANN generell sowohl positiv als auch negativ formuliert. (N002.200) ist im Zusammenhang mit (N002.100)a dafür ein gutes Beispiel. In (N002.100)a wird eine normative Forderung erhoben, die offen lässt, ob zusätzliche Werte fakultativ verboten sind oder nicht. Diese Lücke wird durch (N002.200) geschlossen.

2 CosK_70a Optionen (normativ)

Dieses Unterkapitel listet Funktionspakete auf, die nicht zwingend erforderlich sind für eine Zulassung des COS im Sinne dieses Dokumentes.

Hinweis CosH_032: Die Option_DES wird derzeit lediglich zur Implementierung von Karten der Generation 1 verwendet, also eGK G1 und eGK G1+. Die Option_DES ist für Karten der Generation 2 und später irrelevant.

Hinweis CosH_14c: Die Option_RSA_CVC wird derzeit zur Implementierung folgender Karten benötigt:
                            a. Karten der Generaion 1, also eGK G1 und eGK G1+,
                            b.HBA und SMC-B der Generation 2 und Generation G2.1.

Hinweis CosK_84b: Die Option_RSA_KeyGeneration wird derzeit lediglich im Rahmen der Personalisierung von Karten der Typen HBA und SMC-B verwendet.

3 CosK_c19 Systemüberblick (informativ)

1. Smartcards sind sichere Datenspeicher.
1. Smartcards speichern Daten in Dateien oder Rekords.
2. Smartcards speichern personenbezogene Schlüssel für IAS-Services.
2. Smartcards kontrollieren den Zugriff mittels Zugriffsregeln.
1. Ein personenbezogener Zugriff wird durch Passwörter ermöglicht.
2. Ein rollenbezogener Zugriff wird durch Authentisierungsschlüssel ermöglicht.
3. Eine sichere Kommunikation wird durch „Trusted Channel" ermöglicht.
3. Eine Smartcard kann sowohl als Start- als auch als Endpunkt eines Trusted Channels fungieren. D. h. diese Smartcard kann einerseits Sessionkeys im Applikationslayer für PSO-Kommandos verwenden, als auch im Secure Messaging Layer. Wo genau hängt von der algId bei der gegenseitigen Authentisierung ab.

4 CosK_91f Lebenszyklus von Karte und Applikation (informativ)

In der Literatur finden sich verschiedene Beschreibungen für den Lebenszyklus von Karten. Dieses Kapitel stellt eine vereinfachte Sicht dar und legt dabei einen Gültigkeitsbereich für diese Spezifikation fest. Grob lässt sich der Lebenszyklus einer Karte in drei Phasen einteilen:

1. Vorbereitungsphase: Diese Phase umfasst aus Sicht der Produktion alle Schritte, die erforderlich sind, um eine Karte für die Nutzungsphase vorzubereiten. Dazu zählen im Wesentlichen die Entwicklung des Betriebssystems, dessen Test, Abnahme und gegebenenfalls auch Evaluierung und Zulassung. Entsprechende Chips werden anschließend produziert, initialisiert und personalisiert. Die Chips werden in einen Kartenkörper implantiert und an einen Kartennutzer ausgeliefert. Die Reihenfolge der Produktionsschritte weicht unter bestimmten Umständen von der genannten Reihenfolge ab und ist hier lediglich beispielhaft skizziert. Dieses Dokument gilt nicht für die Vorbereitungsphase der Karte. Die Vorbereitungsphase der Karte endet spätestens mit der Übergabe der Karte an einen Kartennutzer. Dann beginnt die Nutzungsphase der Karte.
2. Nutzungsphase: Diese Phase umfasst den elektrischen Gebrauch der Karte. Dieses Dokument gilt für die Nutzungsphase der elektrischen Kartenschnittstelle. Die Nutzungsphase der Karte endet, wenn sämtliche Business Use Cases irreversibel gesperrt sind, mithin also auch, wenn die Karte physikalisch zerstört wird.
3. Terminierungsphase: Befindet sich die Karte in der Terminierungsphase, dann sind typischerweise alle intendierten Nutzungen der Karte irreversibel gesperrt. In der Regel lassen sich also weder Daten auslesen noch speichern und es ist keine Benutzerverifikation und auch keine Komponentenauthentisierung mehr möglich. Dies ist erreichbar durch eine physikalische Zerstörung des Chips, oder etwa auch durch die Unterstützung des Kommandos TERMINATE CARD USAGE. Da nach Ausführung eines solchen Kommandos herstellerspezifisch noch gewisse Kommandos möglich sind (etwa SELECT, GET CHALLENGE, …) oder die Übertragungsschicht T=1 möglicherweise noch aktiv ist, ist es nicht möglich, hier von einer Karte zu sprechen, die völlig inaktiv ist.

Analog zu den Phasen einer Karte ist es möglich, auch für Applikationen oder deren Bestandteile (Dateien, Passwörter, Schlüssel, …) die Phasen Vorbereitung, Nutzung und Terminierung zu definieren. Die Aussagen zur physikalischen Zerstörung der Karte gehen dann über in ein Löschen der Applikation oder deren Bestandteile.

Dieses Dokument 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 wird.

5 CosK_2b8 Datentypen und Datenkonvertierung (normativ)

Dieses Dokument verwendet die folgenden Datentypen äquivalent zu [BSI-TR-03111#3]:

1. Oktettstring (OS),
2. Bitstring (BS),
3. Integer (I),
4. Körperelement (Field Element FE) und
5. elliptischen Kurvenpunkt (ECP).

Definition: Das höchstwertige Bit (most significant bit, MSBit) eines Bitstrings ist das am weitesten links stehende.

Definition: Das niedrigstwertige Bit (least significant bit, LSBit) eines Bitstrings ist das am weitesten rechts stehende.

Definition: Das höchstwertige Oktett (most significant byte, MSByte) eines Oktettstrings ist das am weitesten links stehende.

Definition: Das niedrigstwertige Oktett (least significant byte, LSByte) eines Oktettstrings ist das am weitesten rechts stehende.

Dieses Dokument verwendet die folgenden Konvertierungsfunktionen äquivalent zum Dokument [BSI-TR-03111#3.1]:

1. Bitstring nach Oktettstring BS2OS,
2. Oktettstring nach Bitstring OS2BS,
3. Körperelement nach Oktettstring FE2OS,
4. Oktettstring nach Körperelement OS2FE.

5.1 BitLength Anzahl Bit in einem Bitstring

Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird die hier beschriebene Funktion wie folgt verwendet:

Tabelle 5, CosK_89d: Definition der Funktion BitLength(...)

Hinweis CosK_fca: Beispiele:
a. BitLength(     '' ) = 0
b. BitLength(   '0' ) = 1,    BitLength(   '1' ) = 1,
c. BitLength( '00' ) = 2,    BitLength( '01' ) = 2,
d. BitLength( '10' ) = 2,    BitLength( '11' ) = 2, …

5.2 OctetLength Anzahl Oktett in einem Oktettstring

Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird die hier beschriebene Funktion wie folgt verwendet:

Tabelle 6, CosK_f2b: Definition der Funktion OctetLength(...)

Hinweis CosH_f1b: Beispiele:
a. OctetLength( '' )        = 0
b. OctetLength( '0034' ) = 2
c. OctetLength( 0 )        = 1, weil die Zahl 0 in einem Oktett codierbar ist, 0 = '00'.
d. OctetLength( 127 )    = 1, weil 127 = '7F`
e. OctetLength( 255 )    = 1, weil 255 = 'FF'
f. OctetLength( 256 )    = 2, weil 256 = '0100'.

Hinweis CosH_3cb, ACHTUNG: Der Oktettstring '0000FFFF' lässt sich als Repräsentant der Zahl 65535 interpretieren. Ohne führende Nullen lautet die hexadezimale Repräsentation der Zahl 65535='FFFF'. Daraus folgt:   OctetLength( '0000FFFF' ) = 4, aber OctetLength(65535) = 2.

5.3 I2OS Integer nach Oktettstring

Dieser Abschnitt beschreibt die Konvertierung einer nicht-negativen ganzen Zahl in einen Oktettstring. Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird diese Konvertierung als Funktion wie folgt verwendet:

Tabelle 7, CosK_042: Definition der Funktion I2OS(...)

Hinweis CosH_7e6: In gewissen Grenzen ist dies die Umkehrfunktion zu (N000.200).

Hinweis CosH_ff7: Beispiele:
a. I2OS(30010, 1) = '3A',
b. I2OS(30010, 2) = '753A',
c. I2OS(30010, 3) = '00753A'.

5.4 OS2I Oktettstring nach Integer

Dieser Abschnitt beschreibt die Konvertierung eines Oktettstrings in eine nicht–negative ganze Zahl. Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird diese Konvertierung als Funktion wie folgt verwendet:

Tabelle 8, CosK_c6a: Definition der Funktion OS2I(...)

Hinweis CosH_07c: In gewissen Grenzen ist dies die Umkehrfunktion zu (N000.100).

5.5 OS2P Oktettstring nach Punkt (uncompressed encoding)

Dieser Abschnitt beschreibt die Konvertierung eines Oktettstrings in einen Punkt auf einer elliptischen Kurve. Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird diese Konvertierung als Funktion wie folgt verwendet:

Tabelle 9, CosK_3e0: Definition der Funktion OS2P(...)

5.6 P2OS Endlicher Punkt nach Oktettstring

Dieser Abschnitt beschreibt die Konvertierung eines Punktes auf einer elliptischen Kurve in einen Oktettstring. Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird diese Konvertierung als Funktion wie folgt verwendet:

Tabelle 10, CosK_e43: Definition der Funktion P2OS(...)

5.7 Extrahiere führende Elemente

5.7.1 Extrahiere führende Bits

Dieser Abschnitt beschreibt, wie aus einem Bitstring oder Oktettstring führende Bits extrahiert werden.

Tabelle 11, CosK_638: Definition der Funktion Extract_MSBit(...)

(N000.500) K_COS
Es gilt die Vorbedingung n kleiner gleich s.

(N000.600) K_COS
Der Bitstring out enthält die n MSBit von in.

5.7.2 Extrahiere führende Oktette

Dieser Abschnitt beschreibt, wie aus einem Oktettstring führende Oktette extrahiert werden.

Tabelle 12, CosK_1ff: Definition der Funktion Extract_MSByte(...)

(N000.700) K_COS
Es gilt die Vorbedingung n kleiner gleich s.

(N000.800) K_COS
Der Oktettstring out enthält die n MSByte von in.

5.8 PaddingIso

Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Es wird gemäß [ISO/IEC 7816-4#10.2.3.1] Abschnitt „Sequential stage“ Spiegelstrich 2 gepadded. Im Rahmen diverser interner Operationen im Betriebssystem wird die hier beschriebene Funktion wie folgt verwendet:

Tabelle 13, CosK_552: Definition der Funktion PaddingIso(...)

Hinweis CosH_cc1: Dies ist die Umkehrfunktion zu (N001.000).

5.9 TruncateIso

Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird die hier beschriebene Funktion wie folgt verwendet:

Tabelle 14, CosK_9fb: Definition der Funktion TruncateIso(...)

Hinweis  CosH_523: Dies ist die Umkehrfunktion (N000.900).

5.10 MGF Mask Generation Function

Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird die hier beschriebene Funktion wie folgt verwendet:

Tabelle 15, CosK_24c: Definition der Funktion MGF(...)

Hinweis CosH_e55: Wenn diese Funktion mit i = 0 aufgerufen wird, dann ist das Ergebnis konform zu
a. [ISO/IEC 9796-2#C], und
b. [PKCS#1#B.2.1].

Hinweis CosH_e90: Wenn diese Funktion mit i = 1 aufgerufen wird, dann ist das Ergebnis konform zu
a. [ANSI X9.63#5.6.3], falls dort der optionale Parameter SharedInfo leer ist, und
b. [BSI-TR-03111#4.3.3], allerdings wird dort das Schlüsselmaterial anders aus N extrahiert.

5.11 RAND Zufälliger Oktettstring

Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird die hier beschriebene Funktion wie folgt verwendet:

Tabelle 16, CosK_7d4: Definition der Funktion RAND(...)

5.12 ceiling Aufrunden einer reellen Zahl

Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird die hier beschriebene Funktion wie folgt verwendet:

Tabelle 17, CosK_c0e: Definition der Funktion ceiling(...)

5.13 floor Abrunden einer reellen Zahl

Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird die hier beschriebene Funktion wie folgt verwendet:

Tabelle 18, CosK_6ed: Definition der Funktion floor(...)

6 CosK_ab0 Kryptographische Algorithmen (normativ)

6.1 CosK_0bb Hash-Algorithmen

Ein Hash-Algorithmus errechnet zu einer beliebigen Folge von Bits, von (beinahe) unbegrenzter Länge, einen Bitstring fester Länge. Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird ein Hash-Algorithmus als Funktion, wie in den folgenden Unterkapiteln gezeigt, verwendet.

6.1.1 SHA-1

Tabelle 19, CosK_12c: Definition der Funktion SHA_1(...)

6.1.2 SHA-256

Tabelle 20, CosK_159: Definition der Funktion SHA_256(...)

6.1.3 SHA-384

Tabelle 21 , CosK_a9f: Definition der Funktion SHA_384(...)

6.1.4 SHA-512

Tabelle 22, CosK_676: Definition der Funktion SHA_512(...)

6.2 Schlüsselvereinbarung

In diesem Abschnitt wird eine Funktion beschrieben, die aus einem Eingabewert Schlüsselmaterial für symmetrische Algorithmen berechnet. Derartiges Schlüsselmaterial wird vorwiegend im Rahmen von sicherer Transportverschlüsselung eingesetzt. Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird eine Schlüsselvereinbarung als Funktion, wie in den folgenden Unterkapiteln gezeigt, verwendet.

6.2.1 Verhalten für 3TDES-Schlüssel, Option_DES

Tabelle 23, CosK_084: Definition der Funktion KeyDerivation_3TDES(...)

6.2.2 Vereinbarung von AES-128-Schlüsseln

Tabelle 24, CosK_7f9: Definition der Funktion KeyDerivation_AES128(...)

6.2.3 Vereinbarung von AES-192-Schlüsseln

Tabelle 25, CosK_cae: Definition der Funktion KeyDerivation_AES192(...)

6.2.4 Vereinbarung von AES-256-Schlüsseln

Tabelle 26, CosK_a21: Definition der Funktion KeyDerivation_AES256(...)

6.2.5 Schlüsselableitung aus einer Card Access Number

Tabelle 27, CosK_f06: Definition der Funktion KDF(...)

6.3 Symmetrischer Basisalgorithmus für Vertraulichkeit

Ein Verschlüsselungsalgorithmus berechnet zu einem beliebigen Oktettstring (plaintext) mit Hilfe eines geheimen Schlüssels ein Chiffrat (ciphertext). Ein entsprechender Entschlüsselungsalgorithmus berechnet zu einem Chiffrat (ciphertext) mit Hilfe desselben symmetrischen Schlüssels den ursprünglichen Oktettstring (plaintext). In diesem Kapitel wird lediglich die Bearbeitung eines Blocks mittels eines Blockverschlüsselungsalgorithmus behandelt. Die Behandlung von Inputdaten mit beliebiger Länge wird in 6.7 spezifiziert.

6.3.1 Symmetrische Verschlüsselung eines Datenblocks, Option_DES

Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird eine Verschlüsselung als Funktion wie folgt verwendet:

6.3.1.1 Verschlüsselung mittels DES, Option_DES

Tabelle 28, CosK_c71: Definition der Funktion DES_ENC(...)

6.3.1.2 Verschlüsselung mittels 3TDES, Option_DES

Tabelle 29, CosK_01b: Definition der Funktion 3TDES_ENC(...)

6.3.2 Symmetrische Entschlüsselung eines Datenblocks, Option_DES

Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird eine Entschlüsselung als Funktion wie folgt verwendet:

6.3.2.1 Entschlüsselung mittels DES, Option_DES

Tabelle 30, CosK_a36: Definition der Funktion DES_DEC(...)

6.3.2.2 Entschlüsselung mittels 3TDES, Option_DES

Tabelle 31, CosK_478: Definition der Funktion 3TDES_DEC(...)

6.3.3 Symmetrische Verschlüsselung eines Datenblocks, AES

Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird eine Verschlüsselung als Funktion wie folgt verwendet:

Tabelle 32, CosK_ee7: Definition der Funktion AES_ENC(...)

6.3.4 Symmetrische Entschlüsselung eines Datenblocks, AES

Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird eine Verschlüsselung als Funktion wie folgt verwendet:

Tabelle 33, CosK_bed: Definition der Funktion AES_DEC(...)

6.4 Asymmetrischer Basisalgorithmus RSA

Als asymmetrischer Basisalgorithmus wird RSA verwendet. Bezüglich des mathematischen Hintergrundes wird an dieser Stelle lediglich auf [PKCS#1] verwiesen.

(N002.200) Diese Anforderung ist absichtlich leer. Der ursprüngliche Text erlaubte auch andere Moduluslängen zu unterstützen. Dies wird nun in (N002.100) durch das Wort "mindestens" ausgedrückt.

(N002.300) Diese Anforderung ist absichtlich leer. Der ursprüngliche Text erlaubte auch andere Werte für öffentliche Exponenten. Dies wird nun in (N002.100) durch das Wort "mindestens" ausgedrückt.

Konform zu [PKCS#1#2] werden die RSA-Schlüsselparameter in diesem Dokument wie folgt dargestellt:

Tabelle 34, CosT_689: Liste der Schlüsselparameter eines RSA-Schlüssels

Hinweis CosH_e02: In diesem Dokument wird der Einfachheit halber nicht mit „chinese remainder theorem“ Parametern gearbeitet. Wegen der größeren Performanz wird aber empfohlen, innerhalb des COS für Operationen mit dem privaten Schlüssel „chinese remainder theorem“ Parameter zu verwenden.

Hinweis CosK_e24: Gemäß (N002.400) sind andere, beliebige Verhältnisse von p und q zulässig. Insbesondere auch solche, die zu p > q gehören.

6.5 Asymmetrischer Basisalgorithmus elliptische Kurven

Als asymmetrischer Basisalgorithmus werden elliptische Kurven verwendet. Bezüglich des mathematischen Hintergrundes wird an dieser Stelle lediglich auf [BSI-TR-03111] verwiesen. Die Domainparameter der im folgenden genannten Kurven finden sich auch im Anhang C.

6.6 Datenauthentisierung

Im Rahmen einer Datenauthentisierung werden beliebigen Daten Informationen derart hinzugefügt, dass die Integrität und Authentizität der Daten überprüfbar ist.

6.6.1 MAC-Generierung

Die MAC-Generierung ist eine Datenauthentisierung, welche auf einem symmetrischen Basisalgorithmus basiert. Dabei wird zu einem Oktettstring beliebigen Inhalts und Länge ein MAC berechnet, dessen Länge lediglich vom Algorithmus abhängt, nicht aber vom Oktettstring. Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird eine MAC-Generierung als Funktion wie folgt verwendet:

6.6.1.1 Generierung Retail-MAC, Option_DES

Tabelle 35, CosK_d3d: Definition der Funktion CALCULATE_Retail_MAC(...)

Hinweis CosH_dc6: Im Rahmen von Secure Messaging wird ein von „null“ verschiedener Initialisierungsvektor Y₀ bei der Konstruktion der Nachricht M berücksichtigt (siehe dazu (N032.800) und (N034.100)).

6.6.1.2 Generierung CMAC ohne internes Padding vor der CMAC-Berechnung

Tabelle 36, CosK_fd0: Definition der Funktion CalculateCMAC_NoPadding(...)

6.6.1.3 Generierung CMAC mit internem ISO-Padding vor der CMAC-Berechnung

Tabelle 37, CosK_245: Definition der Funktion CalculateCMAC_IsoPadding(...)

6.6.2 MAC-Prüfung

Die MAC-Prüfung prüft die Konsistenz zwischen Daten und den hinzugefügten Informationen der Datenauthentisierung. Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird eine MAC-Prüfung als Funktion wie folgt verwendet:

6.6.2.1 Prüfung Retail-MAC, Option_DES

Tabelle 38, CosK_590: Definition der Funktion VERIFY_Retail_MAC(...)

6.6.2.2 Prüfung CMAC ohne internes Padding vor der CMAC-Berechnung

Tabelle 39, CosK_fa6: Definition der Funktion VERIFYCMAC_NoPadding(...)

6.6.2.3 Prüfung CMAC mit internem Padding vor der CMAC Berechnung

Tabelle 40, CosK_2ad: Definition der Funktion VERIFYCMAC_IsoPadding(...)

6.6.3 Signaturberechnung

Unter der Berechnung einer Signatur wird in diesem Dokument lediglich die mit dem privaten Schlüssel durchgeführte Operation verstanden.

6.6.3.1 Signaturberechnung mittels RSA

6.6.3.1.1 RSA, ISO9796–2, DS1, SIGN, Option_RSA_CVC

Diese Funktionalität wird an der physikalischen Schnittstelle im Rahmen des Kommandos INTERNAL AUTHENTICATE sichtbar (siehe (N086.900)c und (N086.900)d). Sie wird wie folgt verwendet:

Tabelle 41, CosK_533: Definition der Funktion RSA_ISO9796_2_DS1_SIGN

6.6.3.1.2 RSA, SSA, PKCS1–V1_5

Diese Funktionalität wird an der physikalischen Schnittstelle im Rahmen des Kommandos PSO Compute Digital Signature sichtbar (siehe (N088.600)d). Sie wird wie folgt verwendet:

Tabelle 42, CosK_234: Definition der Funktion RSASSA_PKCS1_V1_5_SIGN(...)

6.6.3.1.3 RSA, SSA, PSS

Diese Funktionalität ist an der physikalischen Schnittstelle nicht sichtbar. Sie wird im Rahmen interner Funktionen verwendet.

Tabelle 43, CosK_858: Definition der Funktion RSA_PSS_SIGN(...)

6.6.3.1.4 RSA, ISO9796–2, DS2, SIGN

Diese Funktionalität wird an der physikalischen Schnittstelle im Rahmen des Kommandos PSO Compute Digital Signature sichtbar (siehe (N088.600)b). Sie wird wie folgt verwendet:

Tabelle 44, CosK_ace: Definition der Funktion RSA_ISO9796_2_DS2_SIGN(...)

6.6.3.1.5 RSASSA–PSS–SIGN

Diese Funktionalität wird an der physikalischen Schnittstelle im Rahmen der Kommandos INTERNAL AUTHENTICATE (siehe (N086.900)a) und PSO Compute Digital Signature sichtbar (siehe (N088.600)c). Sie wird wie folgt verwendet:

Tabelle 45, CosK_7cc: Definition der Funktion RSASSA_PSS_SIGN(...)

6.6.3.2 Signaturberechnung mittels ELC

Diese Funktionalität wird an der physikalischen Schnittstelle im Rahmen des Kommandos PSO Compute Digital Signature sichtbar (siehe (N088.600)c). Sie wird wie folgt verwendet:

Tabelle 46, CosK_78b: Definition der Funktion ELC_SIG(...)

Hinweis CosH_b8f: In (N003.600)a wird ein möglicherweise zu langer Hash-Wert auf die Bitlänge von n reduziert, vergleiche dazu auch [BSI-TR-03111#4.2]. Bei den in diesem Dokument verwendeten Kombinationen aus Hash-Algorithmus und Kurvenlänge ist H_t stets identisch zu H, sodass die Berechnung in (N003.600)a nicht praxisrelevant ist.

6.6.4 Signaturprüfung

Unter der Prüfung einer Signatur wird in diesem Dokument lediglich die mit dem öffentlichen Schlüssel durchgeführte Operation verstanden. Diese Funktionalität wird an der physikalischen Schnittstelle nur teilweise sichtbar, je nach Schlüsseltyp. Im Rahmen diverser interner Operationen im Betriebssystem wird eine Signaturprüfung als Funktion wie folgt verwendet:

6.6.4.1 RSA, ISO9796–2, DS1, VERIFY, Option_RSA_CVC

Tabelle 47, CosK_adc: Definition der Funktion RSA_ISO9796_2_DS1_VERIFY(...)

(N003.700)a. Schritt 1: Signature opening: Gemäß [ISO/IEC 9796-2#B.5]:

(N003.700)b. Schritt 2: Message recovery: Gemäß [ISO/IEC 9796-2#8.4]:

Hinweis CosH_6a8: ACHTUNG: In (N003.700)b.i ist F* ein Oktettstring. Aus diesem F* geht durch Abschneiden des „most significant bit“ ein Bitstring hervor, der F* aus [ISO/IEC 9796-2#8.4] entspricht. Deshalb wird in (N003.700)b.i das zweithöchste Bit geprüft und in [ISO/IEC 9796-2#8.4] das „leftmost“ Bit.

6.6.4.2 Signaturprüfung mittels elliptischer Kurven

Tabelle 48, CosK_b2b: Definition der Funktion ELC_VER_SIG(...)

(N003.800)c K_COS
        Schritt 2:  s_inv     = s^–1 mod n.

(N003.800)d K_COS
        Schritt 3:  u₁     = s_inv OS2I (H_t ) mod n.    
                       u₂     = s_inv r mod n.

(N003.800)e K_COS
        Schritt 4:  Q     = [u₁] G + [u₂] P_a     mit     Q = ( x_Q, y_Q ).

(N003.800)f K_COS
        Schritt 5:  v     = OS2I ( FE2OS( x_Q ) ) mod n.

6.7 Vertraulichkeit von Daten, symmetrischer Fall

6.7.1 Symmetrische Verschlüsselung

Die symmetrische Verschlüsselung überführt eine beliebige Nachricht plaintext (Oktettstring beliebigen Inhalts und Länge) in ein Chiffrat ciphertext. Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird eine symmetrische Verschlüsselung als Funktion wie folgt verwendet:

6.7.1.1 Verschlüsselung 3TDES, Option_DES

Tabelle 49, CosK_20c: Definition der Funktion 3TDES_CBX_ENC(...)

6.7.1.2 Verschlüsselung AES

Tabelle 50, CosK_b34: Definition der Funktion AES_CBC_ENC(...)

6.7.2 Symmetrische Entschlüsselung

Die symmetrische Entschlüsselung überführt ein Chiffrat ciphertext (Oktettstring beliebigen Inhalts und Länge) in einen Klartext plaintext. Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird eine symmetrische Verschlüsselung als Funktion wie folgt verwendet:

6.7.2.1 Entschlüsselung 3TDES, Option_DES

Tabelle 51, CosK_ef0: Definition der Funktion 3TDES_CBX_DEC(...)

6.7.2.2 Entschlüsselung AES

Tabelle 52, CosK_b49: Definition der Funtion AES_CBC_DEC(...)

6.8 Vertraulichkeit von Daten, asymmetrischer Fall

6.8.1 Asymmetrische Verschlüsselung

Die asymmetrische Verschlüsselung überführt eine Nachricht M (Oktettstring beliebigen Inhalts und Länge) in ein Chiffrat C. Diese Funktionalität wird an der physikalischen Schnittstelle nicht unmittelbar sichtbar. Im Rahmen diverser interner Operationen im Betriebssystem wird eine asymmetrische Verschlüsselung als Funktion wie folgt verwendet:

6.8.1.1 RSA, ES, PKCS1 V1.5

Tabelle 53, CosK_982: Definition der Funktion RSAES_PKCS1_V1_5_ENCRYPT(...)

6.8.1.2 RSA, OAEP, Verschlüsselung

Tabelle 54, CosK_089: Definition der Funktion RSAES_OAEP_ENCRYPT(...)