Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation des Card Operating System (COS)

Elektrische Schnittstelle

    

     

      
Version
      
3.14.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
16.05.2022
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_COS
     
    

Dokumentinformationen

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments (informativ)

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

• : Einordnung des Dokuments enthält Aussagen zum Umgang mit diesem Dokument.
• : Optionen beschreibt und listet Funktionspakete, die nicht zwingend in allen Kartentypen vorhanden sind.
• : Systemüberblick wird in einer späteren Version Grundlagen zu Betriebssystemen für Smartcards enthalten, die auf der Normenreihe ISO/IEC 7816 basieren.
• : Lebenszyklus von Karte und Applikation grenzt den Gültigkeitsbereich der Spezifikation aus zeitlicher Sicht ab.
• : Datentypen und Datenkonvertierung definiert einige grundlegende Datentypen, welche die normativen Beschreibungen in späteren Kapiteln vereinfachen.
• : Kryptographische Algorithmen definiert einige grundlegende kryptographische Funktionen, welche die normativen Beschreibungen in späteren Kapiteln vereinfachen.
• : CV-Zertifikat beschreibt Zertifikate, welche zu nutzen sind, um öffentliche Schlüssel in eine Smartcard zu importieren.
• : Objekte enthält eine Art Klassendiagramm in textueller Form. Die dort definierten Objekte und Attribute vereinfachen die normativen Beschreibungen in nachfolgenden Kapiteln.
• : Objektsystem beschreibt, wie sich Informationen persistent auf einer Smartcard hierarchisch speichern lassen.
• : Zugriffskontrolle beschreibt den Schutz von Informationen auf einer Smartcard vor unberechtigtem Zugriff.
• : Kommunikation beschreibt, wie die Smartcard Informationen mit anderen Systemen austauscht.
• : Kanalkontext beschreibt die Informationen, welche volatil und kanalspezifisch (zu logischen Kanälen siehe auch [ISO/IEC 7816-4]) von der Smartcard gespeichert werden.
• : Gesicherte Kommunikation beschreibt, wie die Smartcard Informationen kryptographisch geschützt mit anderen Systemen austauscht.
• : 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.
• : Authentisierungsprotokolle beschreibt Sequenzen, die aus mehr als einem Kommando bestehen.
• : Verschiedenes spezifiziert konkrete Werte für eine Reihe von Platzhaltern.
• : Informative Hinweise zur Sicherheitsevaluierung.
  
• : 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  zu beginnen. Dort werden, wenn möglich, Verweise auf andere Kapitel gesetzt, wenn Dinge dort ausführlicher beschrieben werden. Wegen der besonderen Bedeutung von  wird dessen Aufbau im Folgenden näher beleuchtet:

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

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller von Smartcard-Betriebssystemen und an Hersteller von Anwendungen, welche unmittelbar mit einer Smartcard 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 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 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 Versicherten-, Leistungserbringer-, Geräte- oder sonstigen Karte zu finden sind, ist nicht Gegenstand dieses Dokumentes. Diese finden sich in 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: CosT_9f7: Abkürzungen und Definitionen

Diese Dokumentenversion wurde mit einem neuen Tool statt mit Word erstellt. Das hat folgende Auswirkungen:

1. In der Normenreihe ISO/IEC 7816 ist es üblich Kommandonamen mit Kapitälchen darzustellen. Weil dieses Feature im Tool nicht verfügbar ist, werden 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 Nummerierung erfolgt in Word und neuem Tool teilweise unterschiedlich:
3. 1. Die erste Gliederungsstufe ist sowohl in Word, als auch im Tool alphabetisch: a, b, c, d, ...
   2. 1. Die zweite Gliederungsstufe erfolgt numerisch mit arabischen Ziffern (Word: 1, 2, ...) bzw. kleinen römischen Ziffern (Tool: i, ii, iii, iv, v, ...)
      2. 1. Die dritte Gliederungsstufe erfolgt in Word numerisch mit kleinen römischen Ziffern (i, ii, iii, iv, v, vi, ...) und im Tool alphabetisch mit Großbuchstaben (A, B, C, ...).
         2. 1. Die vierte Gliederungsstufe erfolgt in Word alphabetisch mit Großbuchstaben (A, B, C, ...) und im Tool numerisch mit großen römischen Ziffern (I, II, III, IV, V, VI, ...)
               
            2. 1. Weitere Gliederungsebenen werden in diesem Dokument in Anforderungen nicht verwendet.
   3. Daraus folgt, dass Referenzen auf N-Nummern sich von der Word-Version hin zur Tool-Version möglicherweise unterscheiden, aber ineinander umrechenbar sind. Zudem ist erkennbar, falls in der Tool-Version die Umrechnung unterblieb. Beispiel: Eine Referenz auf (N654.321)a.7.ii.D ist eine Word-Version, die im Tool 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 im Tool identisch zu den N-Nummern in der Word-Version.
4. Automatische Referenzierungen wie in Word (beispielsweise siehe Abbildung 3 oder siehe Tabelle 47) sind im Tool nicht möglich. Ersatzweise werden händisch gepflegte Label nach folgendem Schema verwendet:
5. 1. CosA_xxx für Abbildungen,
      
   2. CosH_xxx für Hinweise,
   3. CosT_xxx für Tabellen
   4. wobei xxx eine dreistellige Folge hexadezimaler Ziffern ist.

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 14.3.2.1 und 14.3.2.2 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.

2 Optionen (normativ)

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

Hinweis: Der Punkt (N000.022) wurde durch (N000.036) und (N000.038) abgelöst.

Die folgenden Punkte sind absichtlich leer: (N000.030), (N000.032).

Hinweis CosH_84b: Die Option_RSA_KeyGeneration wird derzeit lediglich im Rahmen der Personalisierung von Karten der Typen HBA und SMC-B sowie bei der Umsetzung der Option_lange_Lebensdauer verwendet.

3 Systemüberblick (informativ)

1. Smartcards sind sichere Datenspeicher.
2. 1. Smartcards speichern Daten in Dateien oder Rekords.
   2. Smartcards speichern personenbezogene Schlüssel für IAS-Services.
3. Smartcards kontrollieren den Zugriff mittels Zugriffsregeln.
4. 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.
5. 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 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 (siehe (N048.700)). 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.

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

Hinweis CosH_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:

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:

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:

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:

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:

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.

5.7.2 Extrahiere führende Oktette

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

5.8 PaddingIso

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

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:

Hinweis CosH_523: Dies ist die Umkehrfunktion zu (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:

Hinweis CosH_e55: Wenn diese Funktion mit i gleich 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 gleich 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:

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:

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:

6 Kryptographische Algorithmen (normativ)

6.1 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

6.1.2 SHA-256

6.1.3 SHA-384

6.1.4 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

(N001.400) ist absichtlich leer.

6.2.2 Vereinbarung von AES-128-Schlüsseln

6.2.3 Vereinbarung von AES-192-Schlüsseln

6.2.4 Vereinbarung von AES-256-Schlüsseln

6.2.5 Schlüsselableitung aus einer Card Access Number

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

Die folgenden Punkte sind absichtlich leer: (N001.600), (N001.700), (N001.800), (N001.900).

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

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

6.4 Asymmetrischer Basisalgorithmus RSA

RSA ist ein im COS verwendeter Basisalgorithmus. 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.

Hinweis CosH_e24: Gemäß (N002.400) sind andere, beliebige Verhältnisse von p und q funktional zulässig. Insbesondere auch solche, die zu p > q gehören. Zudem handelt es sich mitnichten um eine funktionale Vorgabe für p und q im Rahmen der Onboard-Schlüsselgenerierung. Die Anforderung (N002.400) hat lediglich die Aufgabe herstellerübergreifend einen Bereich für p und q festzulegen, der im Rahmen einer externen Schlüsselgenerierung mit dem COS interoperabel ist (etwa für Testlaborkartenspezifikation, Personalisierung und ähnliches.

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

Tabelle 29: 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.

6.5 Asymmetrischer Basisalgorithmus elliptische Kurven

Kryptographie basierend auf elliptischen Kurven ist ein im COS verwendeter Basisalgorithmus. 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 in .

6.6 Datenauthentisierung

Im Rahmen einer Datenauthentisierung werden beliebigen Daten weitere 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

(N002.700) ist absichtlich leer.

6.6.1.2 Generierung CMAC ohne internes Padding vor der CMAC-Berechnung

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

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

(N002.900) ist absichtlich leer.

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

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

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

(N003.100) ist absichtlich leer.

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:

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.

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:

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:

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:

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

Die folgenden Punkte sind absichtlich leer: (N003.700).

6.6.4.2 Signaturprüfung mittels elliptischer Kurven

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

(N003.900) ist absichtlich leer.

6.7.1.2 Verschlüsselung AES

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 Entschlüsselung als Funktion wie folgt verwendet:

6.7.2.1 Entschlüsselung 3TDES, Option_DES

(N004.100) ist absichtlich leer.

6.7.2.2 Entschlüsselung AES

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

Dieses Kapitel ist absichtlich leer.

(N004.300) Diese Anforderung ist absichtlich leer., weil die Verschlüsselung gemäß RSAES_PKCS1_V1_5_ENCRYPT ersatzlos entfallen ist.

6.8.1.2 RSA, OAEP, Verschlüsselung

6.8.1.3 Elliptic Curve Key Agreement

Die hier beschriebene Funktionalität ist an der physikalischen Schnittstelle nicht direkt sichtbar, wird aber im Rahmen verschiedener Funktionen mit elliptischen Kurven verwendet.

Hinweis CosH_c0c: In einer früheren Dokumentenversion wurde in diesem Kapitel die Funktion ECKA(...) spezifiziert. In dieser Dokumentenversion wurde die Funktion ECKA(...) aufgespalten in ECKApoint(...) und ECKAvalue(...).

6.8.1.3.1 Elliptic Curve Key Agreement Point Sab

Die hier beschriebene Funktionalität berechnet aus einem privaten und einem öffentlichen Schlüssel auf einer elliptischen Kurve einen Punkt, der als gemeinsames Geheimnis weiterverwendet wird.

Hinweis CosH_261: Dies entspricht dem ersten Teil der Funktion ECKA(...) aus früheren Dokumentenversionen. Der übrige Teil der Funktion ECKA(...) ist in (N004.492) enthalten.

6.8.1.3.2 Elliptic Curve Key Agreement Value Zab

Die hier beschriebene Funktionalität wandelt einen Punkt auf einer elliptischen Kurve, der ein gemeinsames Geheimnis darstellt, in einen Oktettstring um.

Hinweis CosH_35e: Dies entspricht dem zweiten Teil der Funktion ECKA(...) aus früheren Dokumentenversionen. Der erste Teil der Funktion ECKA(...) ist in (N004.490) enthalten.

6.8.1.4 ELC Verschlüsselung

6.8.2 Asymmetrische Entschlüsselung

Die asymmetrische Entschlüsselung überführt ein Chiffrat C in eine Nachricht M.

6.8.2.1 RSA, ES, PKCS1 V1.5, Decrypt

Dieses Kapitel ist absichtlich leer.

(N004.600) Diese Anforderung  ist absichtlich leer.

6.8.2.2 RSA, OAEP, Decrypt

Diese Funktionalität wird an der physikalischen Schnittstelle im Rahmen des Kommandos PSO Decipher sichtbar (siehe (N090.300)b).

6.8.2.3 ELC Entschlüsselung

Diese Funktionalität wird an der physikalischen Schnittstelle im Rahmen des Kommandos PSO Decipher sichtbar (siehe (N090.300)c).

7 CV-Zertifikat (informativ)

Die folgenden Punkte sind absichtlich leer: (N004.900), (N005.000), (N005.100), (N005.200), (N005.300), (N005.400), (N005.500), (N005.600), (N005.700), (N005.800), (N005.900), (N006.000), (N006.100), (N006.200), N006.300), (N006.400), (N006.500), (N006.600).

Bis zur Version 3.12.0 vom 15.05.2019 enthielten sie Anforderungen an CV-Zertifikate für RSA-Schlüssel. Seit dem 1.1.2019 werden derartige CV-Zertifikate in der Telematikinfrastruktur nicht mehr verwendet.

7.1 CV-Zertifikate für ELC-Schlüssel

Normative Festlegungen zu CV-Zertifikaten für ELC-Schlüssel finden sich in [gemSpec_PKI].

8 Objekte

8.1 Diverse Attribute (normativ)

Dieses Unterkapitel beschreibt einige Attribute, die für mehrere Objekttypen gleichermaßen relevant sind.

8.1.1 File Identifier

Der Attributstyp fileIdentifier wird von den Objekttypen DF und Datei verwendet.

Aus der Norm [ISO/IEC 7816-4] leiten sich folgende Regeln ab, die bei der Spezifikation einer Anwendung einzuhalten sind:

Hinweis CosH_596: Die Forderung (N006.700) ist strenger als [ISO/IEC 7816-4]. Dies lässt Raum für herstellerspezifische Ordner (DF) und Dateien (EF).

8.1.2 Short File Identifier

Es ist möglich, dass der Attributstyp shortFileIdentifier von den Objekttypen Datei verwendet wird (siehe 8.3.2).

Aus der Norm [ISO/IEC 7816-4] leiten sich folgende Regeln ab, die bei der Spezifikation einer Anwendung einzuhalten sind:

8.1.3 Life Cycle Status

Der Attributstyp lifeCycleStatus wird von den Objekttypen Objektsystem, Ordner, Datei, Rekord, Passwort und Schlüssel zur Speicherung eines "physikalischen" Life Cycle Status (siehe (N020.500)) verwendet. Zusätzlich ist im Rahmen gewisser Operationen der "logische" Life Cycle Status (siehe (N020.600)) wichtig. Bei der Kommandobeschreibung wird darauf verwiesen, ob der "physikalische" oder der "logische" Life Cycle Status zu verwenden ist.

Aus den Normen [ISO/IEC 7816-4#7.4.10] und [ISO/IEC 7816-9#Fig.1] leiten sich folgende Regeln ab, die bei der Spezifikation einer Anwendung einzuhalten sind:

8.1.4 Zugriffsregelliste

Der Attributstyp interfaceDependentAccessRules wird von den Objekttypen verwendet, welche die Ausführung von Kommandos von der Erfüllung von Zugriffsregeln abhängig machen. Dabei handelt es sich um eine Ansammlung von Zugriffsregeln. Typischerweise werden einem Objekt mehr als eine Zugriffsregel zugeordnet, weil es dem COS dadurch möglich ist, situationsbezogen zu reagieren. So sind gewisse Leseoperationen typischerweise nur über eine kontaktbehaftete Schnittstelle zulässig, während sie für eine kontaktlose Schnittstelle verboten sind. Andererseits ist der Zugriff auf deaktivierte Objekte typischerweise stark eingeschränkt. Darüber hinaus werden Security Environments genutzt, um Abhängigkeiten der Zugriffsregel von der Einsatzumgebung auszudrücken.

Akademisch betrachtet wäre eine dreidimensionale Matrix für interfaceDependentAccessRules angebracht, wo je nach Interface (kontaktbehaftet/kontaktlos = erste Dimension), Lebenszyklus (aktiviert/deaktiviert = zweite Dimension) und Einsatzumgebung (SE-Identifier = dritte Dimension) eine Zugriffsregel ausgewählt wird.

In dieser Dokumentenversion beschränkt sich die erste Dimension auf die beiden Fälle kontaktlose Schnittstelle gemäß 11.2.3 einerseits und kontaktbehaftete Schnittstelle gemäß 11.2.1 oder 11.2.2 andererseits und für die zweite Dimension ist es im deaktivierten oder terminierten Fall hinreichend, nur eine Einsatzumgebung vorzusehen. Deshalb werden in dieser Version des Dokumentes statt einer (mehrdimensionalen) Matrix zwei Listen verwendet.

8.1.5 Rekord

Der Objekttyp record wird von den Objekttypen linear variables, linear fixes und zyklisches Elementary File (EF) verwendet, siehe 8.3.2.2.

Hinweis CosH_d67: Da es aus funktionaler Sicht keine Möglichkeit gibt den lifeCycleStatus eines record in den Zustand "Termination state" zu überführen, ist dieser Zustand für einen record irrelevant.

8.1.6 SE-Identifier

Der Attributstyp seIdentifier ist eng mit dem Begriff Security Environment verknüpft (siehe 8.8). Aus dem gemäß [ISO/IEC 7816-4#10.4.4] erlaubten Wertebereich wird hier folgende Untermenge ausgewählt:

8.1.7 PIN

Der Attributstyp pin wird im Zusammenhang mit der Benutzerverifikation verwendet. Es gilt:

8.1.8 Datum

Der Attributstyp date wird im Zusammenhang mit dem Gültigkeitszeitraum von Schlüsseln verwendet.

8.2 Schlüsselmaterial (normativ)

8.2.1 Symmetrische Schlüssel

8.2.1.1 3TDES-Schlüssel, Option_DES

(N008.200) ist absichtlich leer.
(N008.300) ist absichtlich leer.

8.2.1.2 AES-128-Schlüssel

Der Attributstyp aes128Key dient der Speicherung von Schlüsselmaterial für einen AES-128-Schlüssel.

8.2.1.3 AES-192-Schlüssel

Der Attributstyp aes192Key dient der Speicherung von Schlüsselmaterial für einen AES-192-Schlüssel.

8.2.1.4 AES-256-Schlüssel

Der Attributstyp aes256Key dient der Speicherung von Schlüsselmaterial für einen AES-256-Schlüssel.

8.2.2 Domainparameter für elliptische Kurven

Der Attributstyp domainParameter dient der Speicherung von Parametern, welche eine elliptische Kurve charakterisieren. Konform zu [BSI-TR-03111#Tabelle 2.1] werden die Domainparameter in diesem Dokument wie folgt dargestellt:

Tabelle 48: CosT_92d: Liste der Domainparameter einer elliptischen Kurve

Bei der Spezifikation von Anwendungen sind folgende Regeln zu beachten, vergleiche CosT_92d:

8.2.3 Privater Schlüssel

Der Attributstyp privateKey dient als Oberbegriff für privateRsaKey und privateElcKey.

8.2.3.1 Privater RSA-Schlüssel

Der Attributstyp privateRsaKey dient der Speicherung des privaten Teils eines asymmetrischen RSA-Schlüsselpaares. Bei der Spezifikation von Anwendungen sind folgende Regeln zu beachten: