Spezifikation der SMC–K

Transcription

Einführung der Gesundheitskarte
Version:
1.1.1
Revision:
rel/rel_main/20
Stand:
26.08.2008
Status:
freigegeben
Seite 1 von 78
gematik_SMC_Spezifikation_SMC-K.doc
Version: 1.1.1
© gematik
Stand: 26.08.2008
Dokumentinformationen
Änderungen zur Vorversion
Folgende Änderungen wurden gegenüber der Version 1.1.0 vorgenommen:
• Die Applikation DF.Sicherheitsanker in Kapitel 8.6 ist nun optional
Folgende Änderungen wurden gegenüber der Version 0.9.0 vorgenommen:
• Anforderungsnummern vom Schema "automatische Nummerierung gemäß
(N…)" wurden umgestellt auf "manuelle sechsstellige Nummerierung gemäß
(N…)".
• Zu jeder Anforderung wurde präzisiert, welche Komponente primär von der
Anforderung betroffen ist.
• Attribut CHA für Vorstellungsobjekte wurde ergänzt, daraus ergeben sich folgende Änderungen:
•
Neue Anforderung (N019855)
•
Neues Kapitel 5.3.6
•
Neue Anforderung (N031540)b.5
• Präzisierung zum Wert keyId in Kapitel 5.3.11.1
• Vereinbarung von Introductionkeys setzt keinen Sicherheitszustand, siehe
(N031923)b und (N031923)c.
• Werte für P1 und P2 in Tabelle 9 korrigiert, Beschreibung entsprechend angepasst
• Trailerwert für NoKeyReference in Tabelle 7 und Tabelle 12 korrigiert
• Rekord 1 in EF.DIR korrigiert, siehe Tabelle 25
• Wegen [IKEv1] und [TLS] folgende Schlüsselverwendung angepasst:
•
Tabelle 31 PrK.AK.AUT
•
Tabelle 35 PrK.NK.VPN.R1024S1
•
Tabelle 36 PrK.NK.VPN.R2048S256
• X509 Identität der SAK im Kapitel 8.5 hinzugefügt
• Schlüsselsuche korrigiert
• Kapitel 9 mit Hinweisen zur optischen Gestaltung und Zulassung hinzugefügt.
• Kapitel 8.6 eingefügt, DF.Sicherheitsanker
Seite 2 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
• Kapitel 5.3.18 GET RANDOM hinzugefügt
• Kapitel 8.5.5 / MF / DF.SAK / PrK.SAK.SIG hinzugefügt
• Editorische Korrekturen
Seite 3 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Referenzierung
Die Referenzierung in weiteren Dokumenten der gematik erfolgt unter:
[gemSpec_SMC–K]
gematik: Einführung der Gesundheitskarte –
Dokumentenhistorie
Version Stand
Kap./
Seite
Grund der Änderung, besondere Hinweise
Bearbeitung
0.0.1
28.01.08
Dokument erstellt
SPE/DK, AFI
0.0.2
28.01.08
Kapitel 1 und 2 editorisch ausgeweitet
SPE/DK, AFI
0.0.3
29.01.08
Anforderungen in Kapitel 3 ergänzt
SPE/DF, AFI
0.0.4
31.01.08
Prosatexte ergänzt
SPE/DK, AFI
0.0.5
0.0.6
16.02.08
Namen kryptographischer Identitäten angepasst
Einarbeitung zahlreicher technischer Kommentare
editorische Verbesserungen
SPE/DK, AFI
0.0.8
10.03.08
Einarbeitung von Reviewkommentaren
SPE/DK, AFI
0.9.0
12.03.08
freigegeben
gematik
0.9.1
04.04.08
Attribut CHA ergänzt
SPE/DK, AFI
0.9.2
07.04.08
kleinere Korrekturen
SPE/DK, AFI
1.0.0
14.04.08
freigegeben zur Vorkommentierung
gematik
14.04.08
…
11.06.08
•
SPE/DK, AFI
•
•
•
•
•
1.1.0
1.1.1
Änderung der Schlüsselverwendung für
TLS und IPSec Aufbau
X509 Identität der SAK hinzugefügt
Nummern umgestellt (N…) à 6-stellig
(N…)
GET RANDOM hinzugefügt
PrK.SAK.SIG hinzugefügt
Einarbeitung von Reviewkommentaren
17.06.08
freigegeben
gematik
22.08.08
Applikation DF.Sicherheitsanker in Kapitel
8.6 ist nun optional
SPE/DK, AFI
26.08.08
freigegeben
gematik
Seite 4 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Inhaltsverzeichnis
Dokumentinformationen ..................................................................................... 2
Inhaltsverzeichnis................................................................................................ 5
1
Zusammenfassung ....................................................................................... 9
2
Einführung ................................................................................................... 10
2.1
Zielsetzung und Einordnung des Dokuments ..............................................10
2.2
Zielgruppe .......................................................................................................10
2.3
Geltungsbereich .............................................................................................11
2.4
Arbeitsgrundlagen..........................................................................................11
2.5
Abgrenzung des Dokuments .........................................................................11
2.6
Methodik..........................................................................................................11
2.6.1 Nomenklatur................................................................................................11
2.6.2 Verwendung von Schüsselworten................................................................11
2.6.3 Normative und informative Kapitel...............................................................12
2.6.4 Komponentenspezifische Anforderungen ....................................................12
3
Anforderungen und Annahmen (informativ)............................................. 14
3.1
Anforderungen an die Komponente SMC–K.................................................14
4
Systemüberblick (informativ)..................................................................... 16
5
Betriebssystem (normativ) ......................................................................... 18
5.1
Allgemein ........................................................................................................18
5.2
Einschränkungen ...........................................................................................18
5.3
Erweiterungen.................................................................................................18
5.3.1 RSA Schlüssellänge....................................................................................19
5.3.2 Ordner.........................................................................................................19
5.3.3 Datei............................................................................................................19
5.3.4 Symmetrisches Vorstellungsobjekt ..............................................................19
5.3.5 Speicherung von Vorstellungsobjekten........................................................21
5.3.6 Setzen eines Sicherheitsstatus....................................................................22
5.3.7 Suche nach einem Schlüsselobjekt .............................................................22
5.3.8 Anforderung für: HBA, SMC–A/B, SMC–K Suche nach einem
symmetrischen Vorstellungsobjekt...........................................................................22
5.3.9 Anzahl logischer Kanäle ..............................................................................23
5.3.10
Attribute eines logischen Kanals..............................................................23
5.3.11
Secure Messaging Layer .........................................................................23
Seite 5 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
5.3.11.1
Ableitung von Sessionkeys ..............................................................24
5.3.11.2
Bearbeitung einer Kommando APDU...............................................25
5.3.12
EXTERNAL AUTHENTICATE .................................................................26
5.3.12.1
Use Case externe Authentisierung...................................................26
5.3.12.2
Kommandobearbeitung, Schlüsselsuche .........................................27
5.3.12.3
Kommandoabarbeitung, neue Algorithmen ......................................27
5.3.13
INTERNAL AUTHENTICATE...................................................................28
5.3.13.1
Use Case interne Authentisierung....................................................28
5.3.13.2
5.3.13.3
5.3.14
PSO Compute Cryptographic Checksum.................................................29
5.3.14.1
Use Case Berechnen einer kryptographischen Checksumme..........30
5.3.14.2
Antwort der Karte auf Berechnen einer kryptographischen
Checksumme.......................................................................................................30
5.3.14.3
Kommandoabarbeitung innerhalb der Karte.....................................31
5.3.15
PSO Decipher .........................................................................................31
5.3.15.1
Use Case Entschlüsseln mittels 3TDES, G1 (normativ) ...................31
5.3.15.2
5.3.15.3
5.3.16
PSO Encipher..........................................................................................33
5.3.16.1
Use Case Verschlüsseln mittels 3TDES, G1 (normativ)...................33
5.3.16.2
5.3.16.3
5.3.17
Verify Cryptographic Checksum ..............................................................34
5.3.17.1
Use Case Prüfung einer kryptographischen Checksumme ..............34
5.3.17.2
Antwort der Karte auf Berechnen einer kryptographischen
Checksumme.......................................................................................................35
5.3.17.3
5.3.18
GET RANDOM ........................................................................................36
5.3.18.1
Use Case Erzeugen kryptographisch sicherer Zufallszahl................36
5.3.18.2
Antwort der Karte auf Erzeugen einer kryptographisch sicheren
Zufallszahl 37
5.3.18.3
5.3.19
MANAGE CHANNEL...............................................................................38
5.3.19.1
Use Case Öffnen eines logischen Kanals ........................................38
5.3.19.2
Use Case Schließen eines logischen Kanals ...................................39
5.3.19.3
Antwort der Karte auf Kanalmanagementoperationen......................39
5.3.19.4
5.3.20
MANAGE SECURITY ENVIRONMENT ...................................................40
5.3.20.1
Use Case Schlüsselauswahl zur internen, symmetrischen
Authentisierung ....................................................................................................40
5.3.20.2
Use Case Schlüsselauswahl zur internen, asymmetrischen
5.3.20.3
Use Case Schlüsselauswahl zur externen, symmetrischen
5.3.20.4
Use Case Schlüsselauswahl zur externen, asymmetrischen
5.3.20.5
Use Case Schlüsselauswahl zur symmetrischen, gegenseitigen
6
Lebenszyklus von Karte und Applikation (informativ)............................. 43
Seite 6 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
7
Anwendungsübergreifende Festlegungen (normativ) ............................. 44
7.1
Attributstabellen .............................................................................................44
7.1.1 Attribute eines Ordners................................................................................44
7.1.2 Attribute einer Datei (EF).............................................................................44
7.2
8
Zugriffsregeln für besondere Kommandos ..................................................44
Dateisystem der SMC–K (normativ)........................................................... 45
8.1
Attribute des Objektsystems .........................................................................45
8.1.1 Answer To Reset.........................................................................................45
8.2
Root, die Wurzelapplikation...........................................................................46
8.2.1 / MF / EF.ATR .............................................................................................47
8.2.2 / MF / EF.C.CA_SAK.CS .............................................................................49
8.2.3 / MF / EF.DIR ..............................................................................................50
8.2.4 / MF / EF.GDO ............................................................................................51
8.2.5 / MF / EF.Version ........................................................................................52
8.2.6 / MF / PuK.RCA.CS.....................................................................................53
8.3
/ MF / DF.AK (normativ, optional) ..................................................................54
8.3.1 / MF / DF.AK / EF.C.AK.AUT.......................................................................55
8.3.2 / MF / DF.AK / PrK.AK.AUT.........................................................................56
8.4
/ MF / DF.NK (normativ, optional) ..................................................................57
8.4.1 / MF / DF.NK / EF.C.NK.VPN.R1024S1.......................................................58
8.4.2 / MF / DF.NK / EF.C.NK.VPN.R2048S256...................................................59
8.4.3 / MF / DF.NK / PrK.NK.VPN.R1024S1.........................................................60
8.4.4 / MF / DF.NK / PrK.NK.VPN.R2048S256.....................................................61
8.5
/ MF / DF.SAK (normativ)................................................................................62
8.5.1 / MF / DF.SAK / EF.C.SAK.AUT ..................................................................63
8.5.2 / MF / DF.SAK / EF.C.SAK.AUTD_CVC ......................................................64
8.5.3 / MF / DF.SAK / PrK.SAK.AUT ....................................................................65
8.5.4 / MF / DF.SAK / PrK.SAK.AUTD_CVC ........................................................66
8.5.5 / MF / DF.SAK / PrK.SAK.SIG .....................................................................67
8.6
/ MF / DF.Sicherheitsanker (normativ)...........................................................68
8.6.1 / MF / DF.Sicherheitsanker / EF.C.TSL.CA..................................................69
9
Verschiedenes (informativ) ........................................................................ 70
9.1
Äußere Gestaltung .........................................................................................70
9.2
Zulassung .......................................................................................................70
Anhang A: Use Cases in DF.SAK (informativ) ................................................ 71
A.1 – Vorstellungsrunde ...........................................................................................71
A.2 – Aufbau Trusted Channel .................................................................................72
A.3 – Austausch von APDUs mittels Trusted Channel...........................................72
A.3.1 – Sicherung einer Kommando APDU .............................................................72
B.3.2 – Entsicherung einer Antwort APDU...............................................................73
Seite 7 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Anhang B............................................................................................................ 74
B1 – Abkürzungen.....................................................................................................74
B2 – Glossar ..............................................................................................................74
B3 – Abbildungsverzeichnis.....................................................................................74
B4 – Tabellenverzeichnis..........................................................................................74
B5 – Referenzierte Dokumente.................................................................................76
B6 – Klärungsbedarf .................................................................................................77
Anhang Y: Sicherheitshinweise (informativ)................................................... 78
Seite 8 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
1 Zusammenfassung
Die technischen Richtlinien zur Stapel- und Komfortsignatur (siehe [TR–03114] und [TR–
03115]) empfehlen eine gesicherte Verbindung zwischen der Signaturanwendungskomponente (SAK) und der sicheren Signaturerstellungseinheit (in diesem Fall HBA). Zudem
wird eine Authentisierung der SAK gegenüber dem HBA verlangt, anhand derer der HBA
erkennt, dass eine sichere Umgebung zur Erzeugung von Stapel- bzw. Komfortsignaturen
vorhanden ist. Gemäß den genannten technischen Richtlinien wird in diesem Dokument
davon ausgegangen, dass die SAK eine Chipkarte enthält, die mit SMC–K bezeichnet
wird. Für diese Art der technischen Umsetzung enthält dieses Dokument die Spezifikation
einer SMC–K.
Dieses Dokument enthält aufbauend auf [gemSpec_eGK_P1] die vollständige technische
Spezifikation des Betriebssystems einer SMC–K sowie die Konfiguration des Dateisystems. Dabei werden zunächst die Betriebssystemerweiterungen beschrieben. Anschließend werden die Anwendungen für Anwendungskonnektor, Netzkonnektor und Signaturanwendungskomponente dargestellt.
Seite 9 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
2 Einführung
2.1 Zielsetzung und Einordnung des Dokuments
Diese Spezifikation definiert die Anforderungen an die Funktionalität einer Betriebssystemplattform für die SMC–K, die auf internationalen Standards für Chipkartenbetriebssysteme aufbaut.
Der Aufbau des Dokumentes gliedert sich wie folgt:
• Kapitel 1 Zusammenfassung enthält die wichtigsten Aussagen dieses Dokumentes.
• Kapitel 2 Einführung enthält Aussagen zum Umgang mit diesem Dokument.
• Kapitel 3 Anforderungen und Annahmen (informativ) enthält Eingangsanforderungen, welche die Basis für die normativen Aussagen in späteren Kapiteln
bilden.
• Kapitel 4 Systemüberblick (informativ) wird in einer späteren Version das Konzept des Betriebssystems der SMC–K enthalten.
• Kapitel 5 Betriebssystem (normativ) enthält alle normativen Vorgaben für das
Betriebssystem der SMC–K.
• Kapitel 6 Lebenszyklus von Karte und Applikation (informativ) enthält informative Angaben zum Lebenszyklus einer SMC–RFID. Diese ordnen die Gültigkeit der in diesem Dokument getroffenen normativen Aussagen in einen zeitlichen Kontext ein.
• Kapitel 7 Anwendungsübergreifende Festlegungen (normativ) enthält übergreifende normative Aussagen zu Attributswerten von Objekten.
• Kapitel 8 Dateisystem der SMC–K (normativ) enthält alle normativen Vorgaben zur Konfiguration des Dateisystems einer SMC–K.
2.2 Zielgruppe
Das Dokument richtet sich an Hersteller von Chipkartenbetriebssystemen und an Anwendungsprogrammierer, die unmittelbar mit der SMC–K kommunizieren, wie etwa Softwareentwickler für Konnektoren.
Zudem richtet es sich an die Produzenten einer SMC–K, welche die SMC–K konfigurieren
und personalisieren.
Seite 10 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
2.3 Geltungsbereich
Der Inhalt des Dokumentes ist verbindlich für die Erstellung von chipkartenbasierten Sicherheitsmodulen, die in Konnektoren zur Anwendung kommen.
2.4 Arbeitsgrundlagen
Die Ausarbeitung steht in engem Zusammenhang mit der Spezifikation des Heilberufsausweises.
2.5 Abgrenzung des Dokuments
Dieses Dokument spezifiziert das Verhalten an der elektrischen Schnittstelle zu einem
Chipkartenbetriebssystem (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.
2.6 Methodik
2.6.1 Nomenklatur
Dieses Dokument verwendet dieselbe Nomenklatur wie [gemSpec_eGK_P1].
Bei Referenzierungen wird durch die Zusatzangabe „#Nummer“ auf ein spezifisches Kapitel oder eine Festlegung (z. B. (N399) in dem referenzierten Dokument Bezug genommen.
2.6.2 Verwendung von Schüsselworten
Für die genauere Unterscheidung zwischen normativen und informativen Inhalten werden
die dem [RFC 2119] entsprechenden in Großbuchstaben geschriebenen, deutschen
Schlüsselworte verwendet:
• MUSS bedeutet, dass es sich um eine absolutgültige und normative Festlegung bzw. Anforderung handelt.
• DARF NICHT bezeichnet den absolutgültigen und normativen Ausschluss einer Eigenschaft.
• SOLL beschreibt eine dringende Empfehlung. Abweichungen zu diesen Festlegungen sind in begründeten Fällen möglich. Wird die Anforderung nicht umgesetzt, müssen die Folgen analysiert und abgewogen werden.
• SOLL NICHT kennzeichnet die dringende Empfehlung, eine Eigenschaft auszuschließen. Abweichungen sind in begründeten Fällen möglich. Wird die Anforderung nicht umgesetzt, müssen die Folgen analysiert und abgewogen werden.
Seite 11 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
• KANN bedeutet, dass die Eigenschaften fakultativ oder optional sind. Diese
Festlegungen haben keinen Normierungs- und keinen allgemeingültigen Empfehlungscharakter.
2.6.3 Normative und informative Kapitel
Kapitel 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 SOLLEN und somit im
Rahmen der Zulassung getestet werden SOLLEN. Falls dies in einem speziellen Fall nicht
so ist, handelt es sich höchstwahrscheinlich um einen editorischen Fehler.
Zusätzlich wird grundsätzlich ausgehend von den Erläuterungen in Kapitel 5.3 und
Abbildung 2 für jede Anforderung die Kartenart genannt, für die diese Anforderung Relevanz besitzt.
2.6.4
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 Komponenten zu betrachten. Die normativen Abschnitte tragen deshalb eine Kennzeichnung, aus wessen Sichtweise die Anforderung primär betrachtet wird. Dabei gelten
natürlicherweise folgende Zusammenhänge:
• Wird eine Anforderung aus der Sichtweise von K_Anwendungsspezifikation
oder K_externeWelt betrachtet, handelt es sich um eine Mindestanforderung
für die in der Mengenklammer genannten Komponenten.
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.
In der Mengenklammer nicht aufgeführte Komponenten brauchen die Anforderung nicht unterstützen, deshalb bewegten sich K_Anwendungsspezifikation
bzw. K_externeWelt außerhalb des spezifizierten Bereichs, falls sie von nicht
genannten Komponenten die genannte Anforderung verlangte.
• Wird eine Anforderung aus Sicht einer Karte (K_eGK, K_HBA, K_SMC–A/B
oder K_SMC–K) betrachtet, handelt es sich in der Regel um Anforderungen
an die interne Funktionsweise.
• Die obigen Aussagen werden im Folgenden durch Beispiele verdeutlicht:
• Beispiel 1: In (N098.766) werden Aussagen zu den Komponenten K_SMC–
A/B und K_SM–K getroffen. Andere dort nicht genannte Komponenten (etwa
K_eGK und K_HBA) sind damit von dieser Anforderung nicht betroffen.
• Beispiel 2: In (N009.850) werden Aussagen zur Anwendungsspezifikation für
die Komponenten K_HBA, K_SMC–A/B und K_SMC–K getroffen. Damit ha-
Seite 12 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
ben die genannten Komponenten dieses Attribut zu unterstützen. Andere,
nicht genannte Komponenten sind von dieser Anforderung nicht betroffen.
• Beispiel 3: In Kapitel 5.3.18.1 wird ein Use Case aus Sicht der externen Welt
betrachtet, die mit Komponenten des Typs K_SMC–A/B und K_SMC–K kommuniziert. Dort nicht aufgeführte Komponenten brauchen diesen Use Case
nicht unterstützen, deshalb bewegt sich die externe Welt außerhalb des spezifizierten Bereichs, falls sie zu nicht genannten Komponenten entsprechende
Kommandos sendet.
Tabelle 1: Liste der Komponenten, aus deren Sicht Anforderungen betrachtet werden
Komponente
Beschreibung
K_Anwendungsspezifikation
{…}
Instanz, welche eine Anwendung spezifiziert, damit gilt diese Anforderung auch für jede Anwendungsspezifikation, die für eine in
der Mengenklammer genannte Komponente bestimmt ist
Betriebssystem einer eGK
Betriebssystem eines HBA
Betriebssystem einer SMC–A oder einer SMC–B
Betriebssystem einer SMC–K
Instanz, welche Nachrichten generiert um diese an eine in der
Mengenklammer genannte Komponente zu senden
Instanz, welche eine Chipkarte im Rahmen einer Produktion individualisiert
K_eGK
K_HBA
K_SMC–A/B
K_SMC–K
K_externeWelt {…}
K_Personalisierung
Seite 13 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
3 Anforderungen und Annahmen (informativ)
3.1 Anforderungen an die Komponente SMC–K
Die nachfolgenden Anforderungen sind bislang noch nicht als Anforderungen im Anforderungskatalog aufgenommen, werden jedoch berücksichtigt und sobald möglich mit einer
AFO–ID versehen.
Tabelle 2: Funktionale Anforderungen
Kennung
Beschreibung
FuAn–1
Die SMC–K MUSS für den privaten Schlüssel Entschlüsselung und Verschlüsselung/Signatur für die Authentifizierung unterstützen, wobei für die
Benutzung des privaten Schlüssels keine Benutzerverifikation erforderlich
sein darf.
Bewertung:
Diese Anforderungen werden durch die Applikationen in Kapitel 8.3
(DF.AK) und 8.4 (DF.NK) erfüllt.
FuAn–2
Die SMC–K MUSS dem Konnektor einen Zufallszahlengenerator mit einer
Entropie von mindestens 80 Bit bieten.
Bewertung:
Diese Anforderung wird durch das Kommando GET RANDOM erfüllt (siehe Kapitel 5.3.18 und [gemSpec_eGK_P1#15.9.3]
FuAn–3
Die SMC–K MUSS den öffentlichen Schlüssel frei auslesen lassen.
Bewertung:
Diese Anforderung wird durch die Zugriffsregel „READ ALWAYS“ für alle
Zertifikatsfiles in den in Kapitel 8.3 (DF.AK) und 8.4 (DF.NK) erfüllt.
FuAn–4
Das Schlüsselmaterial KANN bei entsprechender Eignung im Schlüsselspeicher selbst generiert werden oder in einer sicheren Umgebung in diesen eingebracht werden.
Bewertung:
Diese Anforderung wird derzeit nicht erfüllt, weil das Kommando GENRATE ASYMMETRIC KEY PAIR nur für Signaturschlüssel, nicht aber für Authentisierungsschlüssel normativ ist (siehe (N000.002) und
[gemSpec_eGK_P1#15.9.2])
FuAn–5
Die SMC–K KANN die Zertifikate des Konnektors speichern und eine
Nachladung der Zertifikate unterstützen.
Bewertung:
Speichern ist berücksichtigt, siehe Kapitel 8.3.1, 8.4.1, 8.4.2, 8.5.1.
Nachladen ist berücksichtigt, siehe Kapitel 8.3.1, 8.4.1, 8.4.2
Seite 14 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Tabelle 3: Nicht–funktionale Anforderungen
Kennung
Beschreibung
–
Tabelle 4: Sicherheitsanforderungen
Kennung
Beschreibung
SiAn–1
Die SMC–K MUSS private Schlüssel sicher schützen, das heißt, dass sie
private Schlüssel NICHT herausgeben DARF und dabei auch physikalischen Angriffen widerstehen MUSS (Tamper Resistance).
Bewertung:
Diese Anforderung wird durch SiAn–2 erfüllt.
SiAn–2
Die SMC–K MUSS als Sicherheitsmodul eingesetzt sein, dessen Eignung
durch eine erfolgreiche Evaluierung nachgewiesen wurde. Die Prüftiefe
MUSS mindestens Common Criteria EAL3+ entsprechen. Die Mechanismenstärke MUSS "hoch" sein.
Seite 15 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
4 Systemüberblick (informativ)
Der Konnektor [gemSpec_Kon] ist eine dezentrale Komponente der Telematikinfrastruktur
(TI), welche zur bundesweiten Einführung der elektronischen Gesundheitskarte gemäß
§ 291a SGB V aufgebaut wird.
Er besitzt zwei Netzwerkschnittstellen und stellt über seine LAN–Schnittstelle das Bindeglied zwischen den Primärsystemen und dezentral vorhandener Kartenterminals
[gemSpec_KT] und darin eingelegten Chipkarten wie etwa eGK und HBA dar. Über seine
WAN–Schnittstelle stellt der Konnektor die Dienste und Anwendungen der Telematikinfrastruktur den Leistungserbringern (LE) zur Verfügung.
Der Konnektor besteht aus den Funktionsblöcken Netzkonnektor (KONN.NK), Anwendungskonnektor im engeren Sinne (KONN.AK) und Signaturanwendungskomponente
(KONN.SAK). Die Funktionsblöcke KONN.AK und KONN.SAK werden zusammen auch
als Anwendungskonnektor im weiteren Sinne bezeichnet.
Entsprechend der Gesamtarchitektur [gemGesArch] sind die kryptographischen Identitäten des Konnektors in einem sicheren Schlüsselspeicher, der SM–K, zu hinterlegen. Die
SMC–K ist eine mögliche Ausprägung des Schlüsselspeichers SM–K.
Abbildung 1: Überblick über die Funktionsblöcke des Konnektors
Die Aufgabe des Netzkonnektors (KONN.NK) ist die Herstellung und Absicherung der
Verbindung über die WAN–Schnittstelle des Konnektors zur Telematikinfrastruktur über
eine VPN–Komponente. Der WAN–Paketfilter des Netzkonnektors schützt die Komponenten des Konnektors und damit auch das LAN des Leistungserbringers (LE) vor ungültigen
Anfragen aus dem WAN. Der LAN–Paketfilter des Netzkonnektors schützt die Komponenten des Konnektors und die Telematikinfrastruktur vor ungültigen Anfragen aus dem LAN.
Seite 16 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Die zum Aufbau der VPN–Verbindung in die TI benötigte kryptographische Identität
(ID.NK.VPN) des Netzkonnektors befindet sich in der Applikation DF.NK auf einer SMC–
K.
Der Anwendungskonnektor (KONN.AK) steuert die fachlichen Anwendungsfälle und
überwacht die Kommunikation zwischen dem Netz des Leistungserbringers und dem der
Telematikinfrastruktur. Die zum Aufbau der optionalen sicheren Verbindung zu den Primärsystemen des Leistungserbringers benötigte kryptographische Identität (ID.AK.AUT)
des Anwendungskonnektors befindet sich in der Applikation DF.AK auf einer SMC–K.
Die Signaturanwendungskomponente (KONN.SAK) erzeugt und prüft qualifizierte elektronische Signaturen und erbringt weitere Sicherheitsfunktionen für den Konnektor. Die
KONN.SAK zeigt dem HBA die sichere Einsatzumgebung an und überträgt die Data–To–
Be–Signed verschlüsselt an den HBA. Hierfür wird der Authentisierungsschlüssel
(ID.SAK.AUTD_CVC) der KONN.SAK verwendet. Die KONN.SAK signiert mit dem
Schlüssel (Prk.SAK.SIG) unter anderem die für die Komfortsignatur benötigte Zuordnungstabelle zwischen der SSEE und den Referenzdaten der Komfortmerkmale und ermöglicht mit dem Schlüssel (Puk.SAK.SIG) eine Prüfung dieser Signatur. Zur Absicherung
der Kommunikationsstrecke zum – und Authentifizierung gegenüber – dem Extended
Trusted Viewer (xTV) und den dezentralen Kartenterminals wird die kryptographische
Identität (ID.SAK.AUT) der KONN.SAK verwendet. Alle genannten kryptographische Identitäten und Schlüssel der KONN.SAK befinden sich in der Applikation DF.SAK auf einer
SMC–K.
Sind die drei beschriebenen Funktionsblöcke (KONN.AK, KONN.SAK und KONN.NK) des
Konnektors in einer physischen Einheit gebündelt, so lautet die Bezeichnung dieser Einheit Einbox–Konnektor. Diese Ausprägung des Konnektors ist für den Betrieb kleiner und
mittelgroßer Leistungserbringereinrichtungen ausgelegt und wird durch den Hersteller des
Konnektors als Komplettsystem ausgeliefert. In Einbox–Konnektoren können die kryptographischen Elemente der drei Funktionsblöcke in einem gemeinsamen Sicherheitsmodul, der SMC–K hinterlegt werden.
Hingegen ist für den Einsatz bei einer Organisation mit einer hohen Anforderung an den
Durchsatz der Einsatz des so genannten Mehrkomponenten–Konnektor vorgesehen.
Hierbei agieren mehrere Instanzen der drei Funktionsblöcke als ein Konnektor und ermöglichen so eine Lastverteilung der Anfragen. An den Betrieb des Mehrkomponenten–
Konnektor werden aufgrund der räumlichen Trennung der Komponenten hohe Anforderungen an die Betriebsumgebung gestellt. Im Fall der Mehrkomponenten–Konnektoren
müssen die kryptographischen Identitäten der Funktionsblöcke auf getrennten Sicherheitsmodulen gespeichert werden, die unter der jeweiligen alleinigen Kontrolle des zugeordneten Funktionsblocks stehen. Weitere Realisierungsalternativen der SM–K sind in
[gemGesArch] beschrieben.
Alle drei Funktionsblöcke sowie die SMC–K selbst sind nach Common Criteria zu evaluieren und werden für den Betrieb in der Telematikinfrastruktur durch die gematik zugelassen.
Seite 17 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
5
Betriebssystem (normativ)
Dieses Kapitel beschreibt die elektrische Schnittstelle einer SMC–K und damit eine Sicht
auf das Betriebssystem der SMC–K. Grundsätzlich werden im Vergleich zur Funktionalität, wie sie in [gemSpec_eGK_P1] beschrieben ist, weitere Fähigkeiten im Betriebssystem
benötigt, die in diesem Kapitel beschrieben werden.
5.1 Allgemein
(N000.001)
Allgemeine Anforderungen an das Betriebssystem der SMC–K:
a. Grundsätzlich MÜSSEN alle normativen Festlegungen des Dokumentes
[gemSpec_eGK_P1] für das COS der SMC–K umgesetzt werden.
b. Einschränkungen MÜSSEN in Kapitel 5.2 genannt werden.
c. Erweiterungen MÜSSEN in Kapitel 5.3 genannt werden.
5.2 Einschränkungen
Derzeit gibt es keine Einschränkungen für das COS der SMC–K im Vergleich zu
[gemSpec_eGK_P1]. Das bedeutet, dass alle normativen Anforderungen aus
[gemSpec_eGK_P1] auch vom COS der SMC–K zu erfüllen sind (Plattformgedanke).
(N000.002)
K_HBA, K_SMC–A/B, K_SMC–K
Das COS der SMC–K MUSS alle Anforderungen aus [gemSpec_eGK_P1] erfüllen.
5.3 Erweiterungen
Dieses Unterkapitel listet die Anforderungen an das COS der SMC–K auf, die in
[gemSpec_eGK_P1] entweder nicht enthalten sind, oder die dort nicht obligatorisch sind.
Dabei wird von folgendem Modell ausgegangen:
• Das Dokument [gemSpec_eGK_P1] beinhaltet Basisfunktionalität wie etwa
Dateizugriffe, Benutzerverifikation, Komponentenauthentisierung, Zugriffsschutz, gesicherte Kommunikation, etc, die grundsätzlich so auch in anderen
Chipkartenbetriebssystemen der Telematikinfrastruktur vorhanden ist.
• Falls [gemSpec_eGK_P1] um die Funktionalitäten „logische Kanäle“ und
„Introductionkeys“ erweitert wird, sind alle Anforderungen an einen Heilberufeausweis erfüllt.
• Falls die Funktionalität eines Heilberufeausweises um die Funktionalität „Unterstützung Trusted Channel“ (sprich PSO Compute CC, PSO Verify CC, …)
erweitert wird, sind alle Anforderungen für eine SMC–A und SMC–B erfüllt.
Seite 18 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
• Falls die Funktionalität einer SMC–A/B um die Fähigkeit Client Server Authentisierung mit RSA 1024 Bit Schlüssel erweitert wird, dann sind alle Anforderungen an eine SMC–K erfüllt.
Abbildung 2: Aufbau der COS Spezifikationen
5.3.1 RSA Schlüssellänge
Dieses Kapitel ergänzt [gemSpec_eGK_P1#(N002.100)a]
(N002.150) K_SMC–A/B, K_SMC–K
Das COS MUSS RSA Schlüssel mit einer Moduluslänge n aus der Menge {1024,
2048} die Algorithmen signPKCS1_V1_5 rsaDecipherPKCS1_V1_5 im Kommando
INTERNAL AUTHENTICATE unterstützen.
Hinweis (1)
Diese Anforderung ergibt sich aus [gemSpec_Krypt#5.1.1.4].
5.3.2 Ordner
Dieses Kapitel ergänzt [gemSpec_eGK_P1#9.3.1].
(N009.850) K_Anwendungsspezifikation {K_HBA, K_SMC–A/B, K_SMC–K}
Ein Ordner MUSS genau ein Attribut shareable vom Typ Boolean besitzen. Im
Rahmen dieser Spezifikation MUSS der Wert des Attributes stets True sein, wodurch angezeigt wird, dass dieser Ordner in mehr als einem logischen Kanal als currentFolder verwendbar ist (siehe [gemSpec_eGK_P1#(N029.900)a]).
5.3.3 Datei
Eine Datei MUSS genau ein Attribut shareable vom Typ Boolean besitzen. Im Rahmen dieser Spezifikation MUSS der Wert des Attributes stets True sein, wodurch
angezeigt wird, dass diese Datei in mehr als einem logischen Kanal als currentEF
verwendbar ist (siehe [gemSpec_eGK_P1#(N030.000)b]).
5.3.4 Symmetrisches Vorstellungsobjekt
Dieses Kapitel ergänzt [gemSpec_eGK_P1#9.5] um ein weiteres Unterkapitel.
Hinweis (2)
Leider ist das Verb „vorstellen“ im Deutschen ein Homonym. Gemeint ist hier nicht
„sich etwas vorstellen“ (englisch: to imagine), sondern „sich jemandem vorstellen“ (englisch: to
introduce). Die Bezeichnung leitet sich ab aus dem Vorgang, wie das Schlüsselmaterial bereitSeite 19 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
gestellt wird. Dabei wird zunächst eine asymmetrische gegenseitige und zertifikatsbasierte Authentisierung durchgeführt (man stellt sich einander vor) und die dabei etablierten Sessionkeys
werden persistent für den späteren Gebrauch gespeichert. Die derart gespeicherten Sessionkeys erfüllen dann dieselben Aufgaben wie die beiden Schlüssel, die an der Authentisierung
beteiligt waren. Insofern „erbt“ ein Vorstellungsobjekt gewisse Informationen aus dem Zertifikat
mit dem öffentlichen Schlüssel, aber auch sicherheitsrelevante Eigenschaften des privaten
Schlüssels. Der Vorteil von Vorstellungsobjekten liegt darin, dass für Karten, die sich häufig
gegenseitig authentisieren und einmalig einander „vorgestellt“ wurden, von diesem Zeitpunkt
an die performanteren (etwa Faktor 2 bis 3) Vorstellungsobjekte verwenden können.
Hinweis (3)
Hier wird davon ausgegangen, dass es möglich ist auf einer Karte mehrere private
Authentisierungsobjekte zu speichern. Zur Referenzierung der jeweils zugehörigen öffentlichen
Schlüssel reicht dann die ICCSN nicht aus. Falls dann zusätzlich gewünscht wird, dass zu einem öffentlichen Schlüssel mehrere Vorstellungsobjekte möglich sind, bietet sich folgende
Konvention an:
Die CHR im Zertifikat referenziert den öffentlichen Schlüssel zu einem privaten Schlüssel. Die
CHR besteht aus 12 Oktett und wird wie folgt gebildet:
a) CHR
= index || keyReference || ICCSN, mit
b) index
= ´00´ für alle Zertifikate,
c) keyReference
= Referenz des zugehörigen privaten Schlüssels
gemäß [gemSpec_eGK_P1#(N099.600)]
d) ICCSN
= zehn Oktett lange Seriennummer der Karte aus EF.GDO.
Hinweis (4)
Zur Referenzierung von Vorstellungsobjekten wird dann im Prinzip die CHR verwendet, wobei das index–Oktett aus CHR variiert wird. Vorschlag:
a) index = ´01´ à Vorstellungsobjekt mit 2TDES Schlüsselmaterial
b) index = ´02´ à Vorstellungsobjekt mit 3TDES Schlüsselmaterial
c) index = ´03´ à Vorstellungsobjekt mit AES–128 Schlüsselmaterial
d) index = ´04´ à Vorstellungsobjekt mit AES–192 Schlüsselmaterial
e) index = ´05´ à Vorstellungsobjekt mit AES–256 Schlüsselmaterial
f) …
Hinweis (5)
Dieses Kapitel ähnelt [gemSpec_eGK_P1#9.5.1].
Ein symmetrisches Vorstellungsobjekt wird im Rahmen von Authentisierungen gemäß
[gemSpec_eGK_P1#16.4.1] eingesetzt. Für dieses Schlüsselobjekt gelten folgende Regeln, die bei der Spezifikation einer Anwendung einzuhalten sind:
(N019.830) K_HBA, K_SMC–A/B, K_SMC–K
Ein symmetrisches Vorstellungsobjekt MUSS ein Attribut keyIdentifier besitzen. Als
Wert von keyIdentifier MUSS ein beliebiger Oktettstring der Länge zwölf Oktett möglich sein.
Ein COS KANN weitere Werte für keyIdentifier unterstützen.
Ein COS KANN weitere Werte für keyIdentifier ablehnen.
Ein symmetrisches Authentisierungsobjekt MUSS genau ein Attribut vom Typ accessRuleList (siehe [gemSpec_eGK_P1#9.1.4]) besitzen.
Ein symmetrisches Vorstellungsobjekt MUSS genau ein Attribut encKey gemäß
[gemSpec_eGK_P1#9.2.1] besitzen.
Ein symmetrisches Vorstellungsobjekt MUSS genau ein Attribut macKey gemäß
[gemSpec_eGK_P1#9.2.1] besitzen.
Ein symmetrisches Vorstellungsobjekt MUSS genau ein Attribut listAlgorithmIdentiSeite 20 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
fier mit Elementen vom Typ algorithmIdentifier besitzen, welche angeben, für welche
Zwecke es verwendbar ist.
a. Die Liste MUSS mindestens ein Element enthalten.
b. Die Liste MUSS fähig sein, vier Elemente aufzunehmen.
c. Das COS KANN Listen mit mehr als vier Elementen unterstützen.
Das COS KANN Listen mit mehr als vier Elementen ablehnen.
d. Für symmetrische Vorstellungsobjekte in Generation 1 MUSS der Wert von algorithmIdentifier Element der Menge {
desRoleAuthentication,
desRoleCheck,
desSessionkey4TC,
(nur SMC–A/B und SMC–K, nicht aber HBA)
desSessionkey4SM
} sein.
e. Ein COS KANN weitere Werte für algorithmIdentifier unterstützen.
Ein COS KANN weitere Werte für algorithmIdentifier ablehnen.
Ein symmetrisches Vorstellungsobjekt MUSS genau ein Attribut CHA gemäß
[gemSpec_eGK_P1#8.1.1.4] besitzen.
Ein symmetrisches Vorstellungsobjekt MUSS die folgenden Kommandos unterstützen:
– EXTERNAL AUTHENTICATE
(siehe (N031.921)a und (N031.923)a),
– INTERNAL AUTHENTICATE
(siehe (N031.924)a und (N031.926)a),
– MUTUAL AUTHENTICATE (siehe [gemSpec_eGK_P1#15.7.1.2,15.9.6.6]),
Bevor ein solches Kommando in der Lage ist mit dem symmetrisches Vorstellungsobjekt zu arbeiten, ist es zu selektieren. Dies geschieht mittels der in Kapitel 5.3.20
beschriebenen Use Cases.
Ein symmetrisches Vorstellungsobjekt KANN weitere Kommandos unterstützen.
Ein symmetrisches Vorstellungsobjekt KANN weitere Kommandos ablehnen.
5.3.5 Speicherung von Vorstellungsobjekten
Dieses Kapitel ergänzt [gemSpec_eGK_P1#(N019.900)].
Das hierarchische Objektsystem MUSS ein Attribut persistentIntroductionKeyList
unterstützen.
a. Das COS MUSS eine beliebige Anzahl Listenelemente unterstützen, wobei die
maximale Anzahl der Elemente bei der Kartenproduktion festgelegt werden.
Das COS KANN eine dynamische Änderung der Listenlänge unterstützen.
Das COS KANN eine dynamische Änderung der Listenlänge ablehnen.
b. Als Listenelement MUSS der Objekttyp „symmetrisches Vorstellungsobjekt“ (siehe Kapitel 5.3.2) unterstützt werden in Verbindung mit einer Referenz zu einem
Ordner, dem dieses Schlüsselobjekt zugeordnet ist (siehe (N031.540)b.6.iv).
c. Elemente der Liste MÜSSEN persistent gespeichert werden.
Seite 21 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
5.3.6 Setzen eines Sicherheitsstatus
Dieses Kapitel fügt unmittelbar hinter [gemSpec_eGK_P1#(N030.300)b] einen weiteren
Punkt ein.
(N019.951)
Falls obj
a. ein symmetrisches Vorstellungsobjekt (siehe Kapitel 5.3.4) ist und obj.CHA (siehe (N019.855)) in der Liste tmpList
1. bereits vorhanden ist, dann beende diesen Algorithmus.
2. noch nicht vorhanden ist, dann MUSS obj.CHA am Anfang von tmpList eingetragen werden.
5.3.7 Suche nach einem Schlüsselobjekt
Dieses Kapitel ergänzt [gemSpec_eGK_P1#10.2].
Diese Suche ist eine Generalisierung von SearchIntroductionKey und SearchSecretKey
gemäß [gemSpec_eGK_P1#10.2.3]:
identifier
algID
Input:
Output:
startFolder
key
keyNotFound
Errors:
notSupported
Notation
gemäß (N019.830) oder [gemSpec_eGK_P1] (N016.400), (N017.100)
Kryptographisches Verfahren, welches der zu suchende
Schlüssel unterstützt, oder „Wildcard“
Ordner, aus dem heraus die Suche startet
Enthält das gefundene Schlüsselobjekt
Zu den gegebenen Inputparametern wurde kein passendes Schlüsselobjekt gefunden.
Der Schlüssel unterstützt den von algID geforderten Algorithmus nicht.
key = SearchKey( startFolder, identifier, algID )
(N019.952)
Wenn der Parameter identifier eine Schlüsselreferenz
a. gemäß (N019.830) enthält, gilt key = SearchIntroductionKey( startFolder, identifier, algID ), sonst
b. gilt key = SearchSecretKey( startFolder, identifier, algID ).
5.3.8 Anforderung für: HBA, SMC–A/B, SMC–K
Suche nach einem symmetrischen Vorstellungsobjekt
Dieses Kapitel ergänzt [gemSpec_eGK_P1#10.2].
Symmetrische Vorstellungsobjekte werden zu Authentisierungszwecken verwendet. Zudem
werden
sie
bei
der
Auswertung
von
Zugriffsregeln
(siehe
[gemSpec_eGK_P1#(N022.400)] und [gemSpec_eGK_P1#(N022.500)]) verwendet. Bei
dieser Art der Schlüsselsuche handelt es sich um eine karteninterne Funktionalität, bei
der viele Implementierungsdetails eine Rolle spielen. An der Schnittstelle „Interpreter“ wird
das im Folgenden festgelegte Verhalten deutlich:
Input:
identifier
algID
startFolder
gemäß (N019.830)
Kryptographisches Verfahren, welches der zu suchende
Schlüssel unterstützt, oder „Wildcard“
Ordner, aus dem heraus die Suche startet
Seite 22 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
key
keyNotFound
Output:
Errors:
notSupported
Notation
Enthält das gefundene Schlüsselobjekt
Zu den gegebenen Inputparametern wurde kein passendes Schlüsselobjekt gefunden.
Der Schlüssel unterstützt den von algID geforderten Algorithmus
nicht.
key = SearchIntroductionKey(startFolder, identifier, algID)
Anforderung für: HBA, SMC–A/B, SMC–K
Die „lokale Variable“ folder wird auf startFolder gesetzt. Dann werden folgende
Schritte ausgeführt:
a. Es wird im Attribut persistentIntroductionKeyList des Objektsystems nach einem
Schlüsselobjekt gesucht, dessen Attribut keyIdentifier identisch zu identifier ist
und das dem Ordner folder zugeordnet ist. Wenn ein solches Schlüsselobjekt
1. existiert, dann wird es als Output–Parameter key verwendet.
2. nicht existiert und folder ist
i. gleich root, dann wird der Fehler „keyNotFound“ zurückgemeldet.
ii. ungleich root, dann wird folder auf den nächst höheren Ordner gesetzt
und der Algorithmus mit Schritt (N021.540)a fortgesetzt.
Wenn das Attribute key.listAlgorithmIdentifier nicht den Wert algID enthält, dann
wird der Fehler "notSupported" zurückgemeldet.
5.3.9 Anzahl logischer Kanäle
Dieses Kapitel ersetzt [gemSpec_eGK_P1#(N026.100)].
Damit mehrere Leistungserbringer im „Multitasking“ Betrieb quasi parallel Stapelsignaturen auszuführen in der Lage sind, unterstützt das COS das Konzept der logischen Kanäle
gemäß [ISO7816–4].
(N026.150) K_externeWelt {K_HBA, K_SMC–A/B, K_SMC–K}
Die Kanalnummer MUSS entweder null sein, oder der Nummer eines geöffneten
Kanals entsprechen (siehe Kapitel 5.3.19.1).
5.3.10 Attribute eines logischen Kanals
Dieses Kapitel ergänzt [gemSpec_eGK_P1#(N029.900)c].
Der channelContext MUSS eine Liste keyReferenceList besitzen, mit folgendem zusätzlichem Element:
macCalculation mit den Komponenten keyReference und algorithmIdentifier.
5.3.11 Secure Messaging Layer
Dieses Kapitel ersetzt komplett [gemSpec_eGK_P1#14.1] inklusive aller Unterkapitel.
Seite 23 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Dieses Unterkapitel beschreibt die Funktionsweise des Layers „SecMes“ in
[gemSpec_eGK_P1#Abbildung 1]. Dieser Layer benutzt neben den Informationen aus
[gemSpec_eGK_P1#(N029.900)d] folgende weitere Attribute:
• KD.i ist ein Oktettstring, der eine vom COS generierte Zufallszahl speichert,
die im Rahmen der Ableitung von Sessionkeys verwendet wird.
• KD.e ist ein Oktettstring, der eine extern generierte Zufallszahl speichert, die
im Rahmen der Ableitung von Sessionkeys verwendet wird.
5.3.11.1 Ableitung von Sessionkeys
Input:
Output:
Errors:
Notation:
–
–
–
der benötigte Input wird dem channelContext entnommen
kein Output vorhanden
keine
SessionkeyDerivation()
Im folgenden gelten die Definitionen:
algId = channelContext.keyReferenceList.externalAuthenticate.algorithmIdentifier
PrK
= privater Schlüssel, der an der Authentisierung beteiligt war, referenziert in
channelContext.keyReferenceList.internalAuthenticate.keyReference
chr
= channelContext.keyReferenceList.externalAuthenticate.keyReference
cha
= Attribute CHA (siehe [gemSpec_eGK_P1#(N019.700)a]) des Schlüssels
mit der Referenz chr.
bitList = … (für Generation 2 ergänzen)
(N031.400)
Falls algId die Aushandlung von 3TDES Schlüsseln anzeigt, gilt
a. K_eGK, K_HBA, K_SMC–A/B, K_SMC–K
für die Attribute aus SessionkeyContext:
(Kenc, SSCenc, Kmac, SSCmac) = KeyDerivation_3TDES (KD.i XOR KD.e).
(N031.500) K_eGK, K_HBA, K_SMC–A/B, K_SMC–K
Falls algId die Aushandlung von AES–128 Schlüsseln anzeigt, gilt … (für Generation 2 vervollständigen).
(N031.520)
Falls algId anzeigt, dass die Sessionkeys
a. K_eGK, K_HBA, K_SMC–A/B, K_SMC–K
im Rahmen von Secure Messaging einzusetzen sind, dann setze
SessionkeyContext.flagSessionEnabled = SK4SM.
b. K_SMC–A/B, K_SMC–K
den Betrieb eines Trusted Channels zu unterstützen haben, dann
1. setze SessionkeyContext.flagSessionEnabled = SK4TC und
2. trage in channelContext.keyReferenceList.dataDecipher eine herstellerspezifische keyReference und algorithmReference = desSessionkey4TC ein und
3. trage in channelContext.keyReferenceList.macCalculation eine herstellerspezifische keyReference und algorithmReference = desSessionkey4TC ein.
c. K_HBA, K_SMC–A/B, K_SMC–K
persistent zu speichern sind, dann setze
SessionkeyContext.flagSessionEnabled = noSK.
Seite 24 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Falls algId anzeigt, dass die Sessionkeys persistent zu speichern sind, dann
a. gilt obj = SearchIntroductionKey( keyId ). Falls die Suche erfolglos verlief, dann
MUSS obj auf ein beliebiges Element von persistentIntroductionkeyList gesetzt
werden.
b. Die Attribute des durch obj referenzierten Listenelementes, werden auf folgende
Werte gesetzt:
1. obj.keyIdentifier
= ´02´ || I2OS( OS2I( chr ), 11), siehe Hinweis (4)
2. obj.accessRuleList
= PrK.accessRuleList
3. obj.encKey
= SSCenc.
4. obj.macKey
= SSCmac.
5. obj.cha
= cha.
6. Für das Attribute listAlgorithmIdentifier gilt:
i. Schritt 1: obj.listAlgorithmIdentifier = {desRoleCheck}
ii. Schritt 2: Falls PrK.listAlgorithemIdentifier einen Werte aus der Menge {
rsaClientAuthentication, rsaRoleAuthentication} enthält dann gilt:
obj.listAlgorithmIdentifier
+= desRoleAuthentication
iii. Schritt 3: Falls PrK.listAlgorithemIdentifier den Wert rsaSessionkey4SM
enthält dann gilt:
+= desSessionkey4SM
iv.
Schritt 4: Falls PrK.listAlgorithemIdentifier den Wert rsaSessionkey4TC enthält dann gilt:
+= desSessionkey4TC
7. Falls der private Schlüssel, zu dem algId gehört, derselben Ebene oder einer
tieferen zugeordnet ist, als der öffentliche Schlüssel, welcher durch chr referenziert wird, dann MUSS obj dem Ordner des private Schlüssels zugeordnet
werden.
8. Sonst MUSS obj dem Ordner des öffentlichen Schlüssels zugeordnet werden.
5.3.11.2 Bearbeitung einer Kommando APDU
Falls im CLA Byte kein Secure Messaging angezeigt wird (siehe [ISO7816–4] Kapitel 5.1.1) und SessionkeyContext.flagSessionEnabled den Wert
a. SK4SM besitzt, dann
1. MUSS der Sicherheitszustand des zugehörigen Aushandlungsschlüssels mittels clearSecurityStatus(…) zurückgesetzt werden.
2. MUSS CmdApdu3 = CmdApdu2 gesetzt werden.
b. sonst MUSS CmdApdu3 = CmdApdu2 gesetzt werden.
Falls im CLA Byte Secure Messaging angezeigt wird und flagSessionEnabled besitzt den Wert
a. SK4SM, dann MUSS
Seite 25 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
1. die
gesicherte
CmdApdu2
den
normativen
Vorgaben
aus
[gemSpec_eGK_P1#14.2] entsprechen. Falls ein DO mit Tag = ´87´ in der
CmdApdu2 vorhanden ist, MUSS flagCmdEnc auf True gesetzt werden, sonst
auf False.
Das COS KANN weitere Secure Messaging Formate akzeptieren.
Das COS KANN weitere Secure Messaging Formate ablehnen.
2. die
gesicherte
CmdApdu2
analog
zu
den
Regeln
aus
[gemSpec_eGK_P1#14.2] entsichert werden. Das Ergebnis ist dann CmdApdu3. Falls dabei ein Fehler festgestellt wird, genau dann
i. MUSS der Sicherheitszustand des zugehörigen Aushandlungsschlüssels mittels clearSecurityStatus(…) zurückgesetzt werden (siehe
[gemSpec_eGK_P1#13.4]).
ii. MUSS die Bearbeitung des Kommandos terminieren.
iii. RspApdu2 enthält in diesem Fall keine Antwortdaten und besteht lediglich aus dem Trailer IncorrectSmDo = ´69 88´.
b. andernfalls
1. MUSS die Bearbeitung des Kommandos terminieren.
2. RspApdu2 enthält in diesem Fall keine Antwortdaten und besteht lediglich aus
dem Trailer IncorrectSmDo = ´69 88´.
Die vom Secure Messaging Layer („SecMes“ in [gemSpec_eGK_P1#Abbildung 1])
gegebenenfalls weitergeleitete CmdApdu3 MUSS gemäß den Vorgaben dieses Dokumentes bearbeitet werden, wobei eine Antwortnachricht RspApdu1 entsteht. Es
wird davon ausgegangen, dass der Secure Messaging Layer CmdApdu3 so aufbereitet, dass im CLA Byte kein Secure Messaging angezeigt wird und die Kanalnummer stets auf null gesetzt wurde.
Falls flagSessionEnabled den Wert
a. SK4SM besitzt, dann MUSS die ungesicherte RspApdu1 gemäß
[gemSpec_eGK_P1#14.3] in die gesicherte RspApdu2 umgewandelt werden.
b. sonst MUSS RspApdu2 = RspApdu1 gesetzt werden.
Falls sowohl KD.i, als auch KD.e vorhanden sind (einer oder beide Werte wurden
mit dem gerade bearbeiteten Kommando gesetzt), dann
a. MUSS SessionkeyContext mittels SessionkeyDerivation() geändert werden (siehe Kapitel 5.3.11.1) und anschließend
b. MÜSSEN KD.i und KD.e auf den Wert „nicht vorhanden“ gesetzt werden.
5.3.12 EXTERNAL AUTHENTICATE
Dieses Kapitel ergänzt [gemSpec_eGK_P1#15.7.1] um weitere Algorithmen.
5.3.12.1 Use Case externe Authentisierung
Dieses Kapitel ergänzt [gemSpec_eGK_P1#15.7.1.1] um weitere Algorithmen.
Seite 26 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
(N031.921)
Wenn algId gleich
a. K_SMC–A/B, K_SMC–K
desSessionKey4TC ist, dann MUSS cmdData gleich 104 Oktett lang sein.
b. K_HBA, K_SMC–A/B, K_SMC–K
rsaSessionkey4Intro oder rsaSessionkey4TC ist, dann MUSS cmdData genauso
viele Oktette enthalten, wie der Modulus des Authentisierungsschlüssels.
5.3.12.2 Kommandobearbeitung, Schlüsselsuche
Dieses Kapitel ersetzt [gemSpec_eGK_P1#15.7.1.4] Punkt (N084.200)c.
(N031.922)
Wenn channelContext.keyReferenceList.externalAuthenticate
a. nicht leer ist und eine Referenz auf ein symmetrisches Authentisierungsobjekt
enthält, dann wird affectedObject = SearchKey(
currentFolder,
channelContext.keyReferenceList.externalAuthenticate.keyReference,
channelContext.keyReferenceList.externalAuthenticate.algID
) gesetzt. Gemäß (N021.540) sowie [gemSpec_eGK_P1#10.2.3] und
[gemSpec_eGK_P1#(N104.300)] KANN es vorkommen, dass die Schlüsselsuche nicht erfolgreich ist. Wenn die Schlüsselsuche den Fehler
Hinweis (6)
Der
letzte
Satz
in
(N031.922)a
erscheint
unvollständig.
In
[gemSpec_eGK_P1#15.7.4.3] Punkt (N086.700)b existieren Unterpunkte zu der ersetzenden
Stelle, die den Satzanfang fortführen.
5.3.12.3 Kommandoabarbeitung, neue Algorithmen
(N031.923)
Wenn channelContext.keyReferenceList.externalAuthenticate.algID den Wert
desSessionKey4TC besitzt, dann werden folgende Schritte ausgeführt:
1. cmdData wird wie folgt aufgeteilt:
i. cmdData = C2 || MAC2
ii. OctetLength( MAC2 ) = 8.
2. out = VERIFY_Retail_MAC( affectedObject.macKey, MAC2, C2 )
3. Falls out den Wert INVALID besitzt, dann MUSS das Kommando mit dem
Trailer AuthenticationFailure terminieren.
4. R = 3TDES_CBC_DEC( affectedObject.encKey, 0, C2 )
5. R wird wie folgt aufgeteilt:
i. R = token || RND.int || ICCSN8.int || KD.i
ii. Es sei
16
= OctetLength ( token )
iii. Es sei
8
= OctetLength( RND.int )
iv. Es sei
8
= OctetLength( ICCSN8.int )
Seite 27 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
v. Es sei
64
= OctetLength( KD.i )
6. Das Kommando MUSS genau dann mit AuthenticationFailure terminieren,
falls
i. RND.int ungleich RND.ICC (siehe [gemSpec_eGK_P1#(N029.900)b])
ist, oder
ii. ICCSN8.int ungleich iccsn8 (siehe [gemSpec_eGK_P1#(N019.900)c])
ist.
7. KD.i MUSS an den Secure Messaging Layer übergeben werden (siehe Kapitel 5.3.10).
rsaSessionkey4TC besitzt, dann MUSS im Rahmen der Kommandobearbeitung
identisch zu rsaSessionkey4SM verfahren werden.
rsaSessionkey4Intro besitzt, dann MUSS im Rahmen der Kommandobearbeitung
identisch zu rsaSessionkey4SM verfahren werden, bis auf folgende Ausnahme:
Der Text von [gemSpec_eGK_P1#(N084.600)] ist durch folgenden Text zu ersetzen:
Falls das Kommando mit dem Trailer NoError antwortet und der Wert von channelContext.keyReferenceList.externalAuthenticate.algID ungleich rsaSessionkey4Intro ist, genau dann MUSS setSecurityStatus( affectedObject ) ausgeführt
werden.
5.3.13 INTERNAL AUTHENTICATE
Dieses Kapitel ergänzt [gemSpec_eGK_P1#15.7.4] um weitere Algorithmen.
5.3.13.1 Use Case interne Authentisierung
(N031.924)
K_externeWelt
Wenn algId gleich
a. {K_SMC–A/B, K_SMC–K}
desSessionKey4TC ist, dann MUSS token gleich 16 Oktett lang sein.
b. {K_HBA, K_SMC–A/B, K_SMC–K}
rsaSessionkey4Intro oder rsaSessionkey4TC ist, dann MUSS token gemäß
[gemSpec_eGK_P1#(N106.700)] gewählt werden.
c. {K_HBA, K_SMC–A/B, K_SMC–K}
signPKCS1_V1_5 ist, dann MUSS die Anzahl Oktette in token kleiner als 0,4 OctetLength( n ) sein, mit n als Modulus des ausgewählten Authentisierungsschlüssels.
Dieses Kapitel ersetzt [gemSpec_eGK_P1#15.7.4.3] Punkt (N086.700)b.
(N031.925)
Wenn channelContext.keyReferenceList.internalAuthenticate
Seite 28 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
a. nicht leer ist, dann wird affectedObject = SearchKey(
currentFolder,
channelContext.keyReferenceList.internalAuthenticate.keyReference,
channelContext.keyReferenceList.internalAuthenticate.algID
Hinweis (7)
Der
letzte
Satz
in
(N031.925)a
erscheint
unvollständig.
In
(N031.926)
Wenn channelContext.keyReferenceList.internalAuthenticate.algID den Wert
desSessionKey4TC besitzt, dann werden folgende Schritte ausgeführt:
1. Setze
RND.int
= RAND( 8 )
2. Setze
ICCSN8.int = iccsn8 (siehe [gemSpec_eGK_P1#(N019.900)c])
3. Setze
KD.e
= RAND( 64 )
4. Setze S = RND.int || ICCSN8.int || token || KD.e
5. Setze C1 = 3TDES_CBC_ENC ( affectedObject.encKey, 0, S )
6. Setze MAC1 = CALCULATE_Retail_MAC( affectedObject.macKey, C1 )
7. Setze response = C1 || MAC1
8. RND.int
MUSS
als
RND.ICC
[gemSpec_eGK_P1#(N029.900)b]).
gespeichert
werden
(siehe
9. KD.e MUSS an den Secure Messaging Layer übergeben werden (siehe Kapitel 5.3.10).
rsaSessionkey4Intro oder rsaSessionkey4TC besitzt, dann MUSS im Rahmen
der Kommandobearbeitung identisch zu rsaSessionkey4SM verfahren werden.
signPKCS1_V1_5 besitzt, dann gilt:
response = RSASSA_PKCS1_V1_5_SIGN( PrK, token )
5.3.14 PSO Compute Cryptographic Checksum
Dieses Kapitel ergänzt [gemSpec_eGK_P1#15.8] um ein weiteres Kommando.
Das Kommando PSO Compute CC berechnet zu gegebenen Daten eine kryptographische Checksumme mittels eines symmetrischen Schlüssels. Der symmetrische Schlüssel
wird im Rahmen einer gegenseitigen Authentisierung (siehe Anhang A.2) ausgehandelt.
Die durch eine Checksumme zu schützenden Daten sind als Parameter in der Kommandonachricht enthalten.
Seite 29 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
5.3.14.1 Use Case Berechnen einer kryptographischen Checksumme
In dieser Variante enthält die APDU des PSO Compute CC Kommandos zwei Parameter:
(N087.220) K_externeWelt {K_SMC–A/B, K_SMC–K}
Der Parameter data enthält die zu schützenden Daten. Der Parameter data ist ein
Oktettstring mit beliebigem Inhalt. Die Länge von data unterliegt nur den Beschränkungen aus [gemSpec_eGK_P1#12.5.5].
Der Parameter length bestimmt die Länge der erwarteten Antwortdaten. Der Wert
von length MUSS aus dem in [gemSpec_eGK_P1#12.5.6] definierten Bereich gewählt werden.
Es MUSS eine Case 4 Kommando APDU gemäß [gemSpec_eGK_P1#12.7.4.1]
über die Schnittstelle „Interpreter“ geschickt werden. Für die Konstruktion dieser
Case 4 Kommando APDU MÜSSEN die Angaben aus Tabelle 5 verwendet werden.
Tabelle 5: PSO Compute CC, Berechnen einer kryptographischen Checksumme
CLA
INS
P1
P2
Data
Ne
Inhalt
´00´
´2A´
´8E´
´80´
´XX…YY´
length
Beschreibung
CLA Byte gemäß [ISO7816–4]
Instruction Byte gemäß [ISO7816–4]
Beschreibung der Antwortdaten, hier kryptographische Checksumme
Beschreibung der Kommandodaten, hier Klartext
data
Anzahl der erwarteten Oktette in den Antwortdaten
5.3.14.2 Antwort der Karte auf Berechnen einer kryptographischen Checksumme
Tabelle 6: PSO Compute CC Antwort APDU im Erfolgsfall
Daten
´XX…YY´
Trailer
´9000´
Inhalt
mac
Inhalt
NoError
Beschreibung
kryptographische Checksumme
Beschreibung
erfolgreiche Berechnung eines MAC
Tabelle 7: PSO Compute CC Antwort APDU im Fehlerfall
Trailer
Inhalt
Beschreibung
´69 85´
´6A 88´
´6A 81´
´69 82´
NoKeyReference
KeyNotFound
UnsupportedFunction
SecurityStatusNotSatisfied
kein Schlüssel für MAC Berechnung ausgewählt
kein Schlüssel für MAC Berechnung vorhanden
Schlüssel unterstützt den angegeben Algorithmus nicht
Zugriffsregel nicht erfüllt
Hinweis (8)
Diese Tabelle enthält keine Fehler, die in den Komponenten I/O, ChannelSwitch
und SecMes in [gemSpec_eGK_P1#Abbildung 1] entdeckt wurden.
Ein COS KANN zusätzliche Trailer verwenden.
Seite 30 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
5.3.14.3 Kommandoabarbeitung innerhalb der Karte
Das COS MUSS die PSO Compute CC Variante aus Kapitel 5.3.14.1 unterstützen.
Das COS KANN weitere PSO Compute CC Varianten unterstützen.
Das COS KANN weitere PSO Compute CC Varianten ablehnen.
Wenn channelContext.keyReferenceList.macCalculation
a. leer ist, genau dann MUSS das Kommando mit dem Trailer NoKeyReference
terminieren.
b. nicht leer ist, dann wird affectedObject = SearchKey(
currentFolder,
channelContext.keyReferenceList.macCalculation.keyReference,
channelContext.keyReferenceList.macCalculation.algID
1. keyNotFound meldet, genau dann MUSS das Kommando mit dem Trailer
KeyNotFound terminieren.
2. notSupported meldet, genau dann MUSS das Kommando mit dem Trailer UnsupportedFunction terminieren.
Wenn AccessRuleEvaluation( affectedObject, CLA, INS, P1, P2 ) den Wert False
zurückliefert, genau dann MUSS das Kommando mit dem Trailer SecurityStatusNotSatisfied terminieren.
Mit den Attributen SSCmac und Kmac aus dem Attribut SessionkeyContext des aktuellen channelContext des logischen Kanals gilt:
a.
SSCmac = SSCmac + 1.
b.
mac
= CALCULATE_Retail_MAC( Kmac, I2OS( SSCmac, 8) || data ).
Als Datenfeld der Antwortnachricht MUSS mac verwendet werden.
Als Trailer MUSS NoError gewählt werden.
Für die Priorität der Trailer gilt:
a. Die Priorität der Trailer in Tabelle 7 ist herstellerspezifisch.
b. Jeder Trailer in Tabelle 7 MUSS eine höhere Priorität als NoError haben.
5.3.15 PSO Decipher
5.3.15.1 Use Case Entschlüsseln mittels 3TDES, G1 (normativ)
Dieses Kapitel ergänzt [gemSpec_eGK_P1#15.8.2] um einen weiteren Use Case.
Seite 31 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Diese Variante gilt für folgenden Algorithmus: desSessionkey4TC.
In dieser Variante enthält die APDU des PSO Decipher Kommandos zwei Parameter:
Der Parameter C enthält die zu entschlüsselnden Daten. Der Parameter C ist ein
Oktettstring mit beliebigem Inhalt. Die Anzahl Oktette in C MUSS ein ganzzahliges
Vielfaches von acht sein.
Es MUSS eine Case 4 Kommando APDU gemäß [gemSpec_eGK_P1#12.7.4] über
die Schnittstelle „Interpreter“ geschickt werden. Für die Konstruktion dieser Case 4
Kommando APDU MÜSSEN die Angaben aus Tabelle 8 verwendet werden.
Tabelle 8: PSO Decipher, Entschlüsseln mittels DES
Inhalt
´00´
´2A´
´80´
´86´
´XX…YY´
length
CLA
INS
P1
P2
Data
Ne
Beschreibung
Beschreibung der Antwortdaten, hier Klartext
Beschreibung der Kommandodaten, hier Chiffrat
´01´ || C = Paddingindikator || Kryptogramm
Dieses Kapitel ersetzt [gemSpec_eGK_P1#15.8.2.4] Punkt (N090.100)b.
(N089.846)
Wenn channelContext.keyReferenceList.dataDecipher
a. nicht leer, dann wird affectedObject = SearchKey(
currentFolder,
channelContext.keyReferenceList.dataDecipher.keyReference,
channelContext.keyReferenceList dataDecipher.algID
Hinweis (9)
Der
letzte
Satz
in
(N089.846)a
erscheint
unvollständig.
Dieses Kapitel ergänzt [gemSpec_eGK_P1#15.8.2.4] um einen weiteren Algorithmus.
(N089.847)
Wenn channelContext.keyReferenceList.dataDecipher.algID den Wert
desSessionkey4TC besitzt, dann gilt mit den Attributen SSCenc und Kenc aus
Seite 32 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
dem Attribut SessionkeyContext des aktuellen channelContext des logischen
Kanals
1. Schritt 1: SSCenc
= SSCenc + 1.
2. Schritt 2: P
= 3TDES_CBC_DEC( Kenc, SSCenc, C ).
3. Schritt 3: plain
= TruncateIso( P, 8 ).
4. Falls die Funktion TruncateIso mit dem Fehler paddingError terminiert, genau
dann MUSS das Kommando mit dem Trailer WrongCiphertext terminieren.
5.3.16 PSO Encipher
5.3.16.1 Use Case Verschlüsseln mittels 3TDES, G1 (normativ)
Dieses Kapitel ergänzt [gemSpec_eGK_P1#15.8.3] um einen weiteren Use Case.
Diese Variante gilt für folgenden Algorithmus: desSessionkey4TC.
In dieser Variante enthält die APDU des PSO Encipher Kommandos zwei Parameter:
(N091.440) K_externeWelt { K_SMC–A/B, K_SMC–K}
Der Parameter M enthält die zu verschlüsselnden Daten. Der Parameter M ist ein
Oktettstring mit beliebigem Inhalt. Die Länge von M unterliegt nur den Beschränkungen aus [gemSpec_eGK_P1#12.5.5].
Tabelle 9: PSO Encipher, Verschlüsseln mittels DES
Inhalt
´00´
´2A´
´86´
´80´
´XX…YY´
length
CLA
INS
P1
P2
Data
Ne
Beschreibung
Beschreibung der Antwortdaten, hier Chiffrat
Beschreibung der Kommandodaten, hier Klartext
M
Dieses Kapitel fügt nach [gemSpec_eGK_P1#(N091.600)] folgendes ein.
Wenn channelContext.keyReferenceList.dataDecipher
a. nicht leer, dann wird affectedObject = SearchKey(
currentFolder,
Seite 33 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
channelContext.keyReferenceList.dataDecipher.keyReference,
channelContext.keyReferenceList.externalAuthenticate.algID
Dieses Kapitel ergänzt [gemSpec_eGK_P1#15.8.3.3] um einen weiteren Algorithmus.
Wenn channelContext.keyReferenceList.dataDecipher.algID den Wert
a. desSessionkey4TC besitzt, dann gilt mit den Attributen SSCenc und Kenc aus
dem Attribut SessionkeyContext des aktuellen channelContext des logischen
Kanals
1. Schritt 1:
SSCenc
= SSCenc + 1.
2. Schritt 2:
P
= PaddingIso( M, 8 ).
3. Schritt 3:
C
= 3TDES_CBC_ENC( Kenc, SSCenc, P ).
4. Schritt 3:
cipher
= ´01´ || C.
5.3.17 Verify Cryptographic Checksum
Dieses Kapitel ergänzt [gemSpec_eGK_P1#15.8] um ein weiteres Kommando.
Das Kommando PSO Verify CC überprüft mittels eines symmetrischen Schlüssels, ob
eine gegebene kryptographische Checksumme zu gegebenen Daten passt. Der symmetrische Schlüssel wird im Rahmen einer gegenseitigen Authentisierung (siehe Anhang A.2)
ausgehandelt. Checksumme und geschützte Daten sind als Parameter in der Kommandonachricht enthalten.
5.3.17.1 Use Case Prüfung einer kryptographischen Checksumme
In dieser Variante enthält die APDU des PSO Verify CC Kommandos zwei Parameter:
Der Parameter data enthält die geschützten Daten. Der Parameter data ist ein Oktettstring mit beliebigem Inhalt.
Der Parameter mac enthält eine kryptographische Checksumme. Der Parameter
mac ist ein Oktettstring mit beliebigem Inhalt, dessen Länge NICHT größer sein
DARF, als die Blocklänge des symmetrischen Algorithmus.
Die Parameter data und mac MÜSSEN im Datenfeld der Kommandonachricht enthalten sein. Die Kodierung wird in (N096.372)a spezifiziert.
Seite 34 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Tabelle 10: PSO Verify CC, Prüfen einer kryptographischen Checksumme
Inhalt
´00´
´2A´
´00´
Á2´
´XX…YY´
CLA
INS
P1
P2
Data
Beschreibung
Beschreibung der Antwortdaten, hier keine Antwortdaten
Beschreibung der Kommandodaten, hier Input Template für MAC
inputTemplate
5.3.17.2 Antwort der Karte auf Berechnen einer kryptographischen Checksumme
Tabelle 11: PSO Verify CC Antwort APDU im Erfolgsfall
Trailer
´9000´
Inhalt
NoError
Beschreibung
erfolgreiche Verifizierung eines MAC
Tabelle 12: PSO Verify CC Antwort APDU im Fehlerfall
Trailer
´69 85´
´6A 88´
´6A 81´
´69 82´
´6A 80´
Inhalt
NoKeyReference
KeyNotFound
UnsupportedFunction
SecurityStatusNotSatisfied
VerificationError
Beschreibung
kein Schlüssel für MAC Berechnung ausgewählt
kein Schlüssel für MAC Berechnung vorhanden
Schlüssel unterstützt den angegeben Algorithmus nicht
Zugriffsregel nicht erfüllt
MAC Prüfung fehlgeschlagen
Hinweis (10)
Das COS MUSS die PSO Verify CC Variante aus 5.3.17.1 unterstützen.
Das COS KANN weitere PSO Verify CC Varianten unterstützen.
Das COS KANN weitere PSO Verify CC Varianten ablehnen.
Wenn channelContext.keyReferenceList.macCalculation
a. leer ist, genau dann MUSS das Kommando mit dem Trailer NoKeyReference
terminieren.
b. nicht leer ist, dann wird affectedObject = SearchKey(
currentFolder,
channelContext.keyReferenceList.macCalculation.keyReference,
channelContext.keyReferenceList.macCalculation.algID
) gesetzt. Gemäß (N021.540) sowie [gemSpec_eGK_P1#10.2.3 und (N104.300)]
KANN es vorkommen, dass die Schlüsselsuche nicht erfolgreich ist. Wenn die
Schlüsselsuche mit den Fehler
1. keyNotFound meldet, genau dann MUSS das Kommando mit dem Trailer
KeyNotFound terminieren.
2. notSupported meldet, genau dann MUSS das Kommando mit dem Trailer UnsupportedFunction terminieren.
Seite 35 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Es gilt:
a. inputTemplate = ´80 – L80 – data || 8E – L8E – mac´
Mit den Attributen SSCmac und Kmac aus dem Attribut SessionkeyContext des aktuellen channelContext des logischen Kanals gilt:
a. SSCmac
= SSCmac + 1.
b. result
= VERIFY_Retail_MAC(Kmac, mac, I2OS( SSCmac, 8) || data ).
Falls result den Wert
a. INVALID besitzt, genau dann MUSS als Trailer VerificationError verwendet werden.
b. VALID besitzt, genau dann MUSS als Trailer NoError verwendet werden.
5.3.18 GET RANDOM
Das Kommando GET RANDOM erzeugt eine Zufallszahl. Im Unterschied zu GET CHALLENGE steht diese Zufallszahl nach Abschluss des Kommandos kartenintern nicht für
weitere Aktionen zur Verfügung. Dafür erfüllt die mittels GET RANDOM erzeugte Zufallszahl gewisse Sicherheitsanforderungen (siehe (N098.766)b).
5.3.18.1 Use Case Erzeugen kryptographisch sicherer Zufallszahl
In dieser Variante enthält die APDU des GET RANDOM Kommandos einen Parameter:
Seite 36 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Tabelle 13: GET RANDOM
CLA
INS
P1
P2
Ne
Inhalt
Beschreibung
´80´
´84´
´00´
´00´
length
CLA Byte gemäß [ISO7816–4] wird hier „proprietary“ angezeigt
Instruction Byte gemäß [ISO7816–4] (identisch zu GET CHALLENGE)
–
–
5.3.18.2 Antwort der Karte auf Erzeugen einer kryptographisch sicheren Zufallszahl
Tabelle 14: GET RANDOM Antwort APDU im Erfolgsfall
Daten
Inhalt
Beschreibung
´XX…YY´
random
Zufallszahl
Trailer
Inhalt
Beschreibung
´90 00´
NoError
erfolgreiche Erzeugung einer Zufallszahl
Tabelle 15: GET RANDOM Antwort APDU im Fehlerfall
Trailer
Inhalt
Beschreibung
´69 82´
SecurityStatusNotSatisfied Zugriffsregel nicht erfüllt
Hinweis (1):
und SecMes aus [gemSpec_eGK_P1#Abbildung 1] entdeckt wurden.
Das COS MUSS die GET RANDOM Variante aus 5.3.18.1 unterstützen.
Das COS KANN weitere GET RANDOM Varianten unterstützen.
Das COS KANN weitere GET RANDOM Varianten ablehnen.
Als affectedObject MUSS currentFolder verwendet werden.
Das COS MUSS
a. einen zufälligen Oktettstring random mit length Oktett erzeugen und
b. die Güte dieser Zufallszahl MUSS mindestens [gemSpec_Krypt#5.2] entsprechen.
Als Trailer MUSS NoError gewählt werden.
Das Datenfeld der Antwortnachricht enthält random.
Seite 37 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
5.3.19 MANAGE CHANNEL
Dieses Kapitel ersetzt [gemSpec_eGK_P1#15.9.5].
Das Kommando MANAGE CHANNEL dient dem Öffnen und Schließen von logischen
Kanälen mit einer von null verschiedenen Kanalnummer. Ob ein Kanal geöffnet oder welcher Kanal geschlossen wird, bestimmen Parameter, die diesem MANAGE CHANNEL
Kommando beigefügt sind.
Ein zusätzlich zum Basiskanal 0 geöffneter logischer Kanal KANN Einfluss auf die
Kommandoausführung haben, wenn diese Kommandos auf Objekte zugreifen, die
in anderen logischen Kanälen aktiv sind. Deshalb gilt folgende Anforderung, die von
der Kommando APDU schickenden Einheit einzuhalten ist:
Die Kommandos DELETE, ACTIVATE und DEACTIVATE DÜRFEN NICHT an das
COS gesendet werden, wenn außer dem Basiskanal noch ein weiterer logischer
Kanal geöffnet ist.
5.3.19.1 Use Case Öffnen eines logischen Kanals
In dieser Variante enthält die APDU des MANAGE CHANNEL drei Parameter:
Der Parameter logicalChannelNumber enthält die Nummer des Kanals, in welchem
dieses Kommando auszuführen ist. Der Wert von logicalChannelNumber MUSS null
sein und MUSS gemäß [ISO7816–4] Kapitel 5.1.1 ins CLA Byte der APDU eingestellt werden, die an der Schnittstelle „Interface I/O“ sichtbar ist.
Der Parameter intendedAction zeigt an, dass ein logischer Kanal zu öffnen ist wobei
die Kanalnummer vom COS bestimmt wird. Der Wert von intendedAction MUSS
0 = ´0000´ sein.
von length MUSS 1 = ´01´ sein.
Es MUSS eine Case 2 Kommando APDU gemäß [gemSpec_eGK_P1#12.7.2.1]
über die Schnittstelle „Interpreter“ geschickt werden. Für die Konstruktion dieser
Case 2 Kommando APDU MÜSSEN die Angaben aus Tabelle 16 verwendet werden.
Tabelle 16: MANAGE CHANNEL zum Öffnen eines logischen Kanals
CLA
INS
P1
P2
Ne
Inhalt
´00´
´70´
´00´
´00´
´01´
Beschreibung
intendedAction, hier Öffnen eines Kanals,
Kanalnummer wird vom COS bestimmt.
Seite 38 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
5.3.19.2 Use Case Schließen eines logischen Kanals
In dieser Variante enthält die APDU des MANAGE CHANNEL Kommandos zwei Parameter:
Der Parameter logicalChannelNumber MUSS die Nummer eines geöffneten Kanals
enthalten, der zu schließen ist. Der Wert von logicalChannelNumber MUSS von null
verschieden sein und MUSS gemäß [ISO7816–4] Kapitel 5.1.1 ins CLA Byte der
APDU eingestellt werden, die an der Schnittstelle „Interface I/O“ sichtbar ist.
Der Parameter intendedAction zeigt an, dass ein logischer Kanal zu schließen ist
wobei die Kanalnummer im CLA Byte übertragen wird. Der Wert von intendedAction
MUSS 32768 = ´8000´ sein.
die Schnittstelle „Interface I/O“ geschickt werden. Für die Konstruktion dieser Case 1 Kommando APDU MÜSSEN die Angaben aus Tabelle 17 verwendet werden.
Tabelle 17: MANAGE CHANNEL zum Schließen eines Kanals
CLA
Inhalt
´XX´
INS
P1
P2
´70´
´80´
´00´
Beschreibung
CLA Byte gemäß [ISO7816–4] mit einer von 0 verschiedenen Kanalnummer
Instruction Byte gemäß [7816–4]
intendedAction, hier Schließen eines Kanals,
betroffener Kanal wird im CLA Byte angezeigt.
5.3.19.3 Antwort der Karte auf Kanalmanagementoperationen
Tabelle 18: MANAGE CHANNEL Antwort APDU im Erfolgsfall
Daten
Kanalnr.
Trailer
´90 00´
Inhalt
´XX´
Inhalt
NoError
Beschreibung
Nummer des soeben geöffneten Kanals
Beschreibung
erfolgreiche Operation
Tabelle 19: MANAGE CHANNEL Antwort APDU im Fehlerfall
Trailer
´68 81´
Inhalt
NoMoreChannelsAvailable
Beschreibung
kein weiterer logischen Kanäle verfügbar
Hinweis (11)
Das COS MUSS die MANAGE CHANNEL Varianten aus Kapitel 5.3.19.1 und
5.3.19.2 unterstützen.
Das COS KANN weitere MANAGE CHANNEL Varianten unterstützen.
Das COS KANN weitere MANAGE CHANNEL Varianten ablehnen.
Seite 39 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Die Zugriffsbedingung für alle MANAGE CHANNEL Varianten MUSS ALWAYS sein.
Wenn intendedAction das Öffnen eines Kanals anzeigt
a. und bereits alle verfügbaren logischen Kanäle geöffnet sind, dann MUSS das
Kommando mit dem Trailer NoMoreChannelsAvailable terminieren,
b. andernfalls MUSS das COS
1. eine nicht verwendete Kanalnummer newChannelNumber allokieren,
2. einen weiteren logischen Kanal öffnen,
3. diesem die allokierte Nummer newChannelNumber zuweisen und
4. dessen Kanalkontext entsprechend [gemSpec_eGK_P1#(N030.100)] initialisieren.
c. Als Datenfeld der Antwortnachricht MUSS I2OS( newChannelNumber, 1) verwendet werden.
Wenn intendedAction das Schließen eines Kanals anzeigt
a. dann MUSS der entsprechende logische Kanal geschlossen werden und
b. die freiwerdende Kanalnummer MUSS für zukünftige Allokationen verfügbar sein.
c. Das Datenfeld der Antwortnachricht MUSS leer sein.
5.3.20 MANAGE SECURITY ENVIRONMENT
Dieses Kapitel ergänzt [gemSpec_eGK_P1#15.9.6] um weitere Use Cases.
5.3.20.1 Use Case Schlüsselauswahl zur internen, symmetrischen Authentisierung
Diese
Kapitel
ersetzt
[gemSpec_eGK_P1#(N100.200)]
und
[gemSpec_eGK_P1#(N100.300)].
(N100.200) K_externeWelt
Der Parameter keyRef enthält den neuen Wert für das Element keyReference im
Listenelement internalAuthenticate. Wert und Kodierung MÜSSEN
a. {K_eGK, K_HBA, K_SMC–A/B, K_SMC–K}
entweder gemäß [gemSpec_eGK_P1#(N099.600)] gewählt werden, oder
gemäß (N019.830) gewählt werden.
Der Parameter algId enthält den neuen Wert für das Element algorithmIdentifier im
Listenelement internalAuthenticate. Wert und Kodierung MÜSSEN gemäß
[gemSpec_eGK_P1#Tabelle 166]gewählt werden, wobei ein Wert aus der Menge {
Seite 40 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
desRoleAuthentication,
{K_eGK, K_HBA, K_SMC–A/B, K_SMC–K}
desSessionkey4TC
{
K_SMC–A/B, K_SMC–K}
} verwendet werden MUSS.
Das COS KANN weitere Werte für algId akzeptieren.
Das COS KANN weitere Werte für algId ablehnen.
5.3.20.2 Use Case Schlüsselauswahl zur internen, asymmetrischen Authentisierung
Diese Kapitel ersetzt [gemSpec_eGK_P1#(N100.800)].
Listenelement internalAuthenticate. Wert und Kodierung MÜSSEN gemäß
[gemSpec_eGK_P1# Tabelle 166] gewählt werden, wobei ein Wert aus der Menge {
rsaClientAuthentication,
rsaRoleAuthentication,
rsaSessionkey4Intro,
{
K_HBA, K_SMC–A/B, K_SMC–K}
rsaSessionkey4SM,
rsaSessionkey4TC,
{
signPKCS1_V1_5
5.3.20.3 Use Case Schlüsselauswahl zur externen, symmetrischen Authentisierung
Diese
Kapitel
ersetzt
[gemSpec_eGK_P1#(N101.200)]
und
[gemSpec_eGK_P1#(N101.300)].
Listenelement externalAuthenticate. Wert und Kodierung MÜSSEN
Listenelement externalAuthenticate. Wert und Kodierung MÜSSEN gemäß
[gemSpec_eGK_P1#Tabelle 166] gewählt werden, wobei ein Wert aus der Menge {
desRoleCheck,
desSessionkey4TC {
5.3.20.4 Use Case Schlüsselauswahl zur externen, asymmetrischen Authentisierung
Listenelement externalAuthenticate. Wert und Kodierung MÜSSEN gemäß
Seite 41 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
[gemSpec_eGK_P1#Tabelle 166] gewählt werden, wobei ein Wert aus der Menge {
rsaRoleCheck,
rsaSessionkey4Intro, {
K_HBA, K_SMC–A/B, K_SMC–K}
rsaSessionkey4SM, {K_eGK, K_HBA, K_SMC–A/B, K_SMC–K}
rsaSessionkey4TC, {
5.3.20.5 Use Case Schlüsselauswahl zur symmetrischen, gegenseitigen Authentisierung
Listenelement externalAuthenticate. Wert und Kodierung MÜSSEN
Hinweis (12)
Es ist nicht erforderlich die normative Forderung [gemSpec_eGK_P1#(N102.300)]
zu ändern oder zu erweitern, weil das Kommando MUTUAL AUTHENTICATE stets zur Etablierung von Sessionkeys für Secure Messaging verwendet wird.
Seite 42 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
6 Lebenszyklus von Karte und Applikation (informativ)
Hinweis (13)
Die in diesem Kapitel verwendeten Begriff Vorbereitungsphase und Nutzungsphase werden in [gemSpec_eGK_P1] Kapitel 5 definiert.
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.
Seite 43 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
7 Anwendungsübergreifende Festlegungen (normativ)
7.1 Attributstabellen
(N980.100) K_Personalisierung
Die in diesem Dokument definierten Zugriffsregeln DÜRFEN in der Nutzungsphase
(siehe Kapitel 4) NICHT veränderbar sein.
Der Terminus „alle SE“ bedeutet, dass Objekte sich in SE#1 wie angegeben verwenden lassen MÜSSEN. Diese Objekte KÖNNEN in anderen SE verwendet werden und MÜSSEN dort dieselben Eigenschaften wie in SE#1 besitzen.
7.1.1 Attribute eines Ordners
Enthält eine Tabelle mit Ordnerattributen
a. keinen applicationIdentifier (AID), so KANN diesem Ordner herstellerspezifisch
ein beliebiger AID zugeordnet werden.
b. einen oder mehrere AID, dann MUSS sich dieser Ordner mittels aller angegebenen AID selektieren lassen.
c. keinen fileIdentifier (FID),
1. so DARF dieser Ordner sich NICHT mittels eines fileIdentifier aus dem Intervall gemäß [gemSpec_eGK_P1] Kapitel 9.1.1 selektieren lassen, es sei denn
es handelt sich um den Ordner root, dessen optionaler fileIdentifier den Wert
´3F00´beistzen MUSS.
2. so KANN diesem Ordner ein beliebiger fileIdentifier außerhalb des Intervalls
gemäß [gemSpec_eGK_P1] Kapitel 9.1.1 zugeordnet werden.
7.1.2 Attribute einer Datei (EF)
Enthält eine Tabelle mit Attributen einer Datei keinen shortFileIdentifier, so DARF
sich dieses EF NICHT mittels shortFileIdentifier aus dem Intervall gemäß
[gemSpec_eGK_P1] Kapitel 9.1.2 selektieren lassen.
7.2 Zugriffsregeln für besondere Kommandos
Gemäß[gemSpec_eGK_P1] gilt:
Die Zugriffsbedingung für die Kommandos GET CHALLENGE, MANAGE SECURITY ENVIRONMENT und SELECT MUSS stets ALWAYS sein, unabhängig vom lifeCycleStatus und unabhängig vom aktuellen Security Environment.
Seite 44 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
8 Dateisystem der SMC–K (normativ)
Dieses Kapitel beschreibt die Konfiguration des Dateisystems, wobei folgende Applikationen berücksichtigt werden:
• MF
siehe Kapitel 8.2
• DF.AK
siehe Kapitel 8.3
• DF.NK
siehe Kapitel 8.4
• DF.SAK siehe Kapitel 8.5
Alle normativen Anforderungen des Kapitels 8 und seiner Unterkapitel MÜSSEN für
SMC–K gelten.
Die SMC–K KANN Applikationen enthalten, die in diesem Dokument nicht genannt
sind.
(N984200) K_Personalisierung
Die SMC–K KANN außer den in diesem Dokument genannten Applikationen keine
weiteren Applikationen enthalten.
8.1 Attribute des Objektsystems
Das Objektsystem gemäß [gemSpec_eGK_P1] enthält folgende Attribute:
Der Wert des Attributes root MUSS die Anwendung gemäß Tabelle 22 sein.
Der Wert des Attributes answerToReset MUSS gemäß Kapitel 8.1.1 sein.
Der Wert des Attributes iccsn8 MUSS identisch zu den letzten acht Oktetten im body von EF.GDO sein (siehe Kapitel 8.2.4).
Das Attribut persistentPublicKeyList MUSS den Schlüssel PuK.RCA.CS enthalten
(siehe Tabelle 28).
Das Attribut persistentIntroductionKeyList MUSS in der Lage sein, mindestens 100
Listenelemente zu speichern.
8.1.1 Answer To Reset
Tabelle 20: ATR Kodierung
Zeichen
TS
T0
Wert
´3B´
´9x´
Bedeutung
Initial Character (direct convention)
Format Character (TA1/TD1 indication, x = no. of HB)
Seite 45 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Zeichen
TA1
TD1
TD2
TA3
TB3
TD3
TA4
Ti
TCK
Wert
´xx´
´81´
´B1´
´FE´
´45´
´1F´
´xx´
HB
XOR
Bedeutung
Interface Character (FI/DI, erlaubte Werte: siehe [gemSpec_eGK_P1])
Interface Character, (T=1, TD2 indication)
Interface Character, (T=1, TA3/TB3/TD3 indication)
Interface Character (IFSC coding)
Interface Character, (BWI/CWI coding)
Interface Character, (T=15, TA4 indication)
Interface Character (XI/UI coding)
Historical Bytes (HB, imax. = 15)
Check Character (exclusive OR)
Der ATR SOLL ein TC1 Byte mit dem Wert ´FF´ enthalten. In diesem Fall MUSS T0
auf den Wert ´Dx´ gesetzt werden.
Die Historical Bytes MÜSSEN gemäß [ISO7816–4] kodiert werden.
Tabelle 21: Beispielhafte Kodierung der Historical Bytes
Zeichen
CI
TPI
TCS
TCC
CLS
Bedeutung
‘00’ gemäß [ISO7816–4]
‘6x’ gemäß [ISO7816–4] (x kodiert die Länge des DO), Wertfeld gemäß (N985.200)
‘31’ gemäß [ISO7816–4], Wertfeld ist Card Service Data Byte gemäß [ISO7816–4]
‘73’ gemäß [ISO7816–4], Wertfeld ist Card Capabilities Data Bytes gemäß
[ISO7816–4], Anzeige von unterstützten logischen Kanälen, Extended Le–Feld, …)
Card Life Cycle (Default–Wert ‘00’)
8.2 Root, die Wurzelapplikation
Diese Applikation beinhaltet allgemeine Datenelemente und Informationen, die dem Betrieb der Chipkarte als solche dienen, oder allen Anwendungen gleichermaßen zur Verfügung stehen.
Tabelle 22: Attribute / MF
Attribute
Wert
Objekttyp
Ordner
AID
´D276 0001 4480 01´
FID
´3F 00´
lifeCycleStatus
„Operational state (activated)“
Zugriffsregel für logischen LCS „Operational state (activated)”, alle SE
Zugriffsart
Zugriffsbedingung
SELECT
ALWAYS
andere
NEVER
Zugriffsregel für logischen LCS „Operational state (deactivated)”
Zugriffsart
Zugriffsbedingung
alle
herstellerspezifisch
Bemerkung
Bemerkung
Bemerkung
Hinweis (14)
Kommandos, die gemäß [gemSpec_eGK_P1] mit einem Ordnerobjekt arbeiten
sind:
ACTIVATE, DEACTIVATE, DELETE, LOAD APPLICATION, SELECT
Seite 46 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Hinweis (15)
Da sich weder dieser Ordner noch der übergeordnete Ordner deaktivieren lassen,
braucht dieser Zustand für Objekte im Kapitel 8.2 nicht berücksichtigt werden.
Abbildung 3: Dateistruktur einer SMC–K auf oberster Ebene
8.2.1 / MF / EF.ATR
Die transparente Datei EF.ATR enthält Informationen zur maximalen Größe einer APDU
in Sende- und Empfangsrichtung sowie zur Identifizierung des Betriebssystems.
Tabelle 23: Attribute / MF / EF.ATR
Attribute
Wert
Objekttyp
transparentes Elementary File
fileIdentifier
´2F 01´
shortFileIdentifier
´1D´ = 29
numberOfBytes
flagTransactionMode False
flagChecksum
True
lifeCycleStatus
body
´XX…YY´
Zugriffsart
Zugriffsbedingung
READ BINARY
ALWAYS
SELECT
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
siehe Hinweis (17)
siehe unten
Bemerkung
Bemerkung
Hinweis (16)
Kommandos, die gemäß [gemSpec_eGK_P1] mit einem transparenten EF arbeiten
sind:
ACTIVATE, DEACTIVATE, DELETE, ERASE BINARY, READ BINARY, SELECT,
UPDATE BINARY
Hinweis (17)
Der Wert des Attributs fileIdentifier ist in [ISO7816–4] festgelegt.
Seite 47 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Für das Attribut body gelten folgende Festlegungen:
Der Oktettstring body MUSS DER–TLV kodierte Datenobjekte (DO) enthalten, welche lückenlos hintereinander konkateniert werden MÜSSEN.
In body MUSS an erster Stelle genau ein DO_BufferSize mit folgenden Eigenschaften enthalten sein:
a. Tag = É0´.
b. DO_Buffersize MUSS genau vier DO mit einem Tag ´02´ enthalten. Der Tag ´02´
bezeichnet einen Integer Wert, der gemäß [ISO8825–1] Kapitel 8.3 kodiert werden MUSS.
c. Das erste DO mit Tag ´02´ gibt die maximale Anzahl der Oktette an, die eine ungesicherte Kommando APDU nicht überschreiten SOLL.
d. Das zweite DO mit Tag ´02´ gibt die maximale Anzahl der Oktette an, die eine
ungesicherte Antwort nicht überschreiten SOLL.
e. Das dritte DO mit Tag ´02´ gibt die maximale Anzahl der Oktette an, die eine gesicherte Kommando APDU nicht überschreiten SOLL.
f. Das vierte DO mit Tag ´02´ gibt die maximale Anzahl der Oktette an, die eine gesicherte Antwort nicht überschreiten SOLL.
In body MUSS an zweiter Stelle genau ein DO_CardData mit folgenden Eigenschaften enthalten sein:
a. Tag = ´66´.
b. Das Wertfeld von DO_CardData MUSS genau ein DO_PreIssuingData mit folgenden Eigenschaften enthalten sein:
1. Tag = ´46´.
2. Das erste Oktett des Wertfeldes MUSS die Chiphersteller ID gemäß
[ISO_SD5] enthalten.
3. Die Oktette zwei bis sechs MÜSSEN die Kartenhersteller–ID enthalten. Anträge unter http://www.sit.fraunhofer.de/ bzw.
http://141.12.72.35/_karten_ident/SIT/pdfs/ICCM_Antrag_2006.pdf.
4. Weitere Oktette sind herstellerspezifisch zu kodieren und SOLLEN eine Betriebssystemversion eineindeutig referenzieren.
c. Das Wertfeld von DO_CardData KANN weitere DER–TLV kodierte Datenobjekte
enthalten sein.
In body KÖNNEN weitere DER–TLV kodierte Datenobjekte enthalten sein.
Seite 48 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
8.2.2 / MF / EF.C.CA_SAK.CS
Diese Datei enthält ein CV–Zertifikat gemäß [gemPKI_Reg] und [gemSpec_eGK_P1],
welches den öffentlichen Schlüssel PuK.CA_SAK.CS einer CA enthält. Das Zertifikat lässt
sich mittels PuK.RCA.CS (siehe Kapitel 8.2.6) prüfen. Der im Zertifikat enthaltene öffentliche Schlüssel dient der Verifizierung von weiteren Zertifikaten, die im Dateisystem enthalten sind (siehe zum Beispiel Kapitel 8.5.1).
Tabelle 24: Attribute / MF / EF.C.CA_SAK.CS
Attribute
Wert
Objekttyp
fileIdentifier
´2F 04´
shortFileIdentifier
´04´ = 4
numberOfBytes
´014B´ Oktett = 331 Oktett
flagChecksum
False
lifeCycleStatus
body
´7F21 820146 XX...YY´
Zugriffsart
Zugriffsbedingung
READ BINARY
ALWAYS
SELECT
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
wird personalisiert
Bemerkung
Bemerkung
Hinweis (18)
sind:
UPDATE BINARY
Seite 49 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
8.2.3 / MF / EF.DIR
Die Datei EF.DIR enthält eine Liste mit Anwendungstemplates gemäß [ISO7816–4].
Tabelle 25: Attribute / MF / EF.DIR
Attribute
Wert
Objekttyp
linear variables Elementary File
fileIdentifier
´2F 00´
shortFileIdentifier
´1E´ = 30
numberOfBytes
maxNumRecords
maxRecordLength
flagRecordLCS
False
flagChecksum
True
lifeCycleStatus
recordList
Rekord 1
´61 09 (4F 06 D27600014480 01)´
Rekord 2
´61 08 (4F 06 D27600000102)´
Rekord 3
…
…
Zugriffsart
Zugriffsbedingung
READ RECORD
ALWAYS
SEARCH RECORD
SELECT
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
siehe Hinweis (20)
siehe Hinweis (20)
root,
siehe 8.2
SAK,
siehe 8.5
siehe Hinweis (21)
Bemerkung
Bemerkung
Hinweis (19)
Kommandos, die gemäß [gemSpec_eGK_P1] mit einem linear variablen EF arbeiten sind: ACTIVATE, ACTIVATE RECORD, DEACTIVATE, DEACTIVATE RECORD, DELETE, APPEND RECORD, ERASE RECORD, READ RECORD, SEARCH RECORD, SELECT, UPDATE RECORD
Hinweis (20)
Die Werte von fileIdentifier und shortFileIdentifier sind in [ISO7816–4] festgelegt.
Hinweis (21)
Weitere Records existieren nur, wenn optionale Applikationen vorhanden sind.
Seite 50 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
8.2.4 / MF / EF.GDO
In EF.GDO wird das Datenobjekt ICCSN gespeichert, welches die Kennnummer der Karte
enthält.
Tabelle 26: Attribute / MF / EF.GDO
Attribute
Wert
Objekttyp
fileIdentifier
´2F 02´
shortFileIdentifier
´02´ = 2
numberOfBytes
´000C´ Oktett = 12 Oktett
flagChecksum
True
lifeCycleStatus
body
´5A 0A XX...YY´
Zugriffsart
Zugriffsbedingung
READ BINARY
ALWAYS
SELECT
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
wird personalisiert
Bemerkung
Bemerkung
Hinweis (22)
sind:
UPDATE BINARY
Das Attribut body enthält die Seriennummer der Karte. Dabei gilt:
In body MUSS genau ein DER–TLV kodiertes Datenobjekt DO_ICCSN mit folgenden Eigenschaften enthalten sein:
a. Tag = ´5A´ und Längenfeld = ´0A´.
b. Für das Wertfeld MUSS gelten:
1. Das erste Oktett MUSS den Major Industry Identifer (MII) mit dem Wert ´80´
enthalten, welcher eine Gesundheitskarte kennzeichnet (siehe [EN 1867]).
2. Die nächsten drei Nibble MÜSSEN den Country Code Deutschlands mit dem
Wert ´276énthalten (siehe [ISO3166]).
3. Die nächsten fünf Nibble MÜSSEN den Issuer Identifer enthalten.
4. Die restlichen 5 Oktette MÜSSEN BCD kodiert eine Seriennummer enthalten.
Hinweis (23)
Die Kennung eines Kartenherausgebers (Issuer Identifier) erlaubt in Verbindung
mit dem Ländercode eine weltweit eineindeutige Identifizierung des Kartenherausgebers. In
Verbindung mit der Seriennummer ist es deshalb möglich, eine Karte weltweit eineindeutig zu
referenzieren.
Hinweis (24)
Die Kennung des Kartenherausgebers entsprechend [EN 1867] wird in Deutschland im Auftrag des DIN durch GS1 Germany GmbH, Köln (www.gs1-germany.de) vergeben.
Der Kartenherausgeber ist gewöhnlich der rechtmäßige Besitzer der ausgegebenen Karte.
Seite 51 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
8.2.5 / MF / EF.Version
Diese Datei enthält Informationen zur Version des Betriebssystems und zur Version des
Dateisystems.
Tabelle 27: Attribute / MF / EF.Version
Attribute
Wert
Objekttyp
linear fixes Elementary File
fileIdentifier
´2F 10´
shortFileIdentifier
´10´ = 16
maxNumRecords
2 Rekord
maxRecordLength
5 Oktett
flagRecordLCS
False
flagChecksum
True
lifeCycleStatus
recordList
Rekord 1
´XX…YY´
Rekord 2
´XX…YY´
…
…
Zugriffsart
Zugriffsbedingung
READ RECORD
ALWAYS
SEARCH RECORD
SELECT
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
siehe Hinweis (26)
Versionsnummer
siehe Hinweis (28)
siehe Hinweis (28)
siehe Hinweis (26)
Bemerkung
Bemerkung
Hinweis (25)
Kommandos, die gemäß [gemSpec_eGK_P1] mit einem linear variablen EF arbeiten sind: ACTIVATE, ACTIVATE RECORD, DEACTIVATE, DEACTIVATE RECORD, DELETE, APPEND RECORD, ERASE RECORD, READ RECORD, SEARCH RECORD, SELECT, UPDATE RECORD
Hinweis (26)
Diese Datei MUSS mindestens zwei Records enthalten. Sie KANN mehr Records
enthalten. Der Inhalt weiterer Records ist herstellerspezifisch.
Hinweis (27)
Eine Versionsnummer wird wie folgt zum Inhalt eines Rekords in EF.Version konvertiert: Die erste und zweite Zahl werden in drei Stellen BCD kodiert. Die dritte Zahl in vier
Stellen BCD kodiert.
Beispiel: Versionsnummer 5.9.10 à ´0050090010´ = ´005´ || ´009 || ´0010´.
Hinweis (28)
Record 1 enthält die Versionsnummer des Betriebssystems. Record 2 enthält die
Versionsnummer der Dateisystemkonfiguration. Da für die SMC–K derzeit beides in einem Dokument beschrieben ist, sind die beiden Record-Inhalte identisch.
Seite 52 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
8.2.6 / MF / PuK.RCA.CS
Dieses Objekt enthält den öffentlichen Schlüssel der Root–CA, welche an der Wurzel der
CVC–Hierarchie steht. Der öffentliche Schlüssel dient der Überprüfung von Zertifikaten,
welche von dieser Root–CA ausgestellt wurden (siehe zum Beispiel Kapitel 8.2.2).
Tabelle 28: Attribute / MF / PuK.RCA.CS
Attribute
Wert
Objekttyp
öffentliches RSA Signaturprüfobjekt
keyIdentifier
´XX…YY´, acht Oktette
publicKey
…, Moduluslänge 2048 Bit
oid
´2B24 0304 0202 03´ = {1 3 36 3 4 2 2 3}
Zugriffsart
Zugriffsbedingung
PSO Verify Cert.
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
wird personalisiert
wird personalisiert
Bemerkung
Bemerkung
Hinweis (29)
Kommandos, die gemäß [gemSpec_eGK_P1] mit einem öffentlichen Signaturprüfobjekt arbeiten sind:
PSO Verify Certificate
Seite 53 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
8.3 / MF / DF.AK (normativ, optional)
Die Anwendung DF.AK enthält kryptographische Objekte des Anwendungskonnektors.
Der in dieser Anwendung enthaltene Schlüssel PrK.AK.AUT unterstützt den Aufbau eines
TLS-Kanals zwischen dem Anwendungskonnektor und dem Primärsystem oder einem
Kartenterminal andererseits. Wegen des erhöhten Schutzbedarfes dieser Verbindungen
wird eine Schlüssellänge von 2048 Bit verwendet (siehe [gemSpec_Krypt#5.1.1.8]).
Diese Anwendung enthält neben dem vorgenannten Schlüssel PrK.AK.AUT ein Zertifikat
C.AK.AUT, welches den öffentlichen Schlüssel PuK.AK.AUT enthält. Es wird als nicht
erforderlich angesehen, dass die Anwendung auch Zertifikate höherer Ebenen enthält.
Die Anwendung DF.AK KANN auf einer SMC–K vorhanden sein. In diesem Sinne
sind die Angaben dieses Unterkapitels optional.
Falls die Anwendung DF.AK auf einer SMC–K vorhanden ist, dann MUSS sie gemäß den Angaben dieses Unterkapitels konfiguriert sein. In diesem Sinne sind die
Angaben dieses Unterkapitels normativ.
Tabelle 29: Attribute / MF / DF.AK
Attribute
Wert
Objekttyp
Ordner
applicationIdentifier
´D276 0001 4402´
fileIdentifier
lifeCycleStatus
Zugriffsart
Zugriffsbedingung
SELECT
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
Bemerkung
Bemerkung
Hinweis (30)
sind: ACTIVATE, DEACTIVATE, DELETE, LOAD APPLICATION, SELECT
Hinweis (31)
Abbildung 4: Dateistruktur der Anwendung DF.AK
Seite 54 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
8.3.1 / MF / DF.AK / EF.C.AK.AUT
Diese Datei enthält ein Zertifikat mit dem öffentlichen Schlüssel PuK.AK.AUT zu
PrK.AK.AUT (siehe Kapitel 8.3.2). Der Zertifikatsinhalt wird in [gemX.509_Kon] beschrieben.
Tabelle 30: Attribute / MF / DF.AK / EF.C.AK.AUT
Attribute
Wert
Objekttyp
fileIdentifier
Ć5 03´
shortFileIdentifier
´03´ = 3
numberOfBytes
KANN passend zum Dateiinhalt gewählt werden
flagChecksum
False
lifeCycleStatus
body
´XX…YY´
Zugriffsart
Zugriffsbedingung
READ BINARY
ALWAYS
SELECT
ALWAYS
UPDATE BINARY
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
wird personalisiert
Bemerkung
Bemerkung
Hinweis (32)
sind:
UPDATE BINARY
Seite 55 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
8.3.2 / MF / DF.AK / PrK.AK.AUT
Dieser Schlüssel ermöglicht den Aufbau eines TLS-Kanals vom Anwendungskonnektor
zum Primärsystem, oder vom Anwendungskonnektor zu einem Kartenterminal. Wegen
des erhöhten Schutzbedarfes dieser Verbindung wird hier eine Schlüssellänge von
2048 Bit verwendet (siehe [gemSpec_Krypt#5.1.1.8]). Der öffentliche Teil zu diesem privaten Schlüssel ist in EF.C.AK.AUT enthalten (siehe Kapitel 8.3.1).
Aus Sicht des Primärsystems handelt der Anwendungskonnektor beim Aufbau der TLSVerbindung als Server. Gemäß [TLS#8.1.1] wird dabei während der Serverauthentisierung eine Entschlüsselung nach [PKCS#1v2.1#7.2.2] durchgeführt.
Tabelle 31: Attribute / MF / DF.AK / PrK.AK.AUT
Attribute
Objekttyp
keyIdentifier
privateKey
algorithmIdentifier
Wert
privates RSA Objekt
´03´ = 3
alle Werte aus der Menge, siehe [gemSpec_eGK_P1]: {
rsaDecipherPKCS1_V1_5
signPKCS1_V1_5
}
Zugriffsart
Zugriffsbedingung
INTERNAL AUTH.
ALWAYS
PSO Decipher
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
wird personalisiert
Serverauthent.
Clientauthent.
Bemerkung
Bemerkung
Hinweis (33)
Kommandos, die gemäß [gemSpec_eGK_P1] mit einem privaten Authentisierungsobjekt arbeiten sind: EXTERNAL AUTHENTICATE, INTERNAL AUTHENTICATE
Seite 56 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
8.4 / MF / DF.NK (normativ, optional)
Die Anwendung DF.NK enthält kryptographische Objekte des Netzkonnektors.
Die in dieser Anwendung enthaltenen Schlüssel PrK.NK.VPN.R1024S1 und
PrK.NK.VPN.R2048S256 unterstützen den Aufbau einer VPN-Verbindung zum VPNKonzentrator. Weil noch nicht alle VPN-Konzentratoren eine Schlüssellänge von 2048 Bit
unterstützen, ist übergangsweise auch ein Schlüssel mit 1024 Bit vorgesehen (vergleiche
hierzu auch [gemSpec_Krypt#5.1.1.5]). Sobald im Rahmen der Algorithmen-Migration die
VPN-Algorithmen vollständig auf RSA2048/SHA256 umgestellt wurden, wird das
RSA1024/SHA1 Zertifikat bzw. die zugehörigen Schlüssel auf SMC-K nicht mehr notwendig sein und in darauf folgenden Versionen der Spezifikation entfallen.
Diese Anwendung enthält neben den vorgenannten privaten Schlüsseln pro privatem
Schlüssel ein Zertifikat mit dem öffentlichen Schlüssel zum jeweiligen privaten Schlüssel.
Es wird als nicht erforderlich angesehen, dass die Anwendung auch Zertifikate höherer
Ebenen enthält.
Die Anwendung DF.NK KANN auf einer SMC–K vorhanden sein. In diesem Sinne
sind die Angaben dieses Unterkapitels optional.
Falls die Anwendung DF.NK auf einer SMC–K vorhanden ist, dann MUSS sie gemäß den Angaben dieses Unterkapitels konfiguriert sein. In diesem Sinne sind die
Angaben dieses Unterkapitels normativ.
Tabelle 32: Attribute / MF / DF.NK
Attribute
Wert
Objekttyp
Ordner
´D276 0001 4403´
fileIdentifier
lifeCycleStatus
Zugriffsart
Zugriffsbedingung
SELECT
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
Bemerkung
Bemerkung
Hinweis (34)
Hinweis (35)
Seite 57 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Abbildung 5: Dateistruktur der Anwendung DF.NK
8.4.1 / MF / DF.NK / EF.C.NK.VPN.R1024S1
Diese Datei enthält ein Zertifikat mit dem öffentlichen Schlüssel zu PrK.NK.VPN.R1024S1
(siehe Kapitel 8.4.3). Der Zertifikatsinhalt wird in [gemX.509_Kon] beschrieben.
Tabelle 33: Attribute / MF / DF.NK / EF.C.NK.VPN.R1024S1
Attribute
Wert
Objekttyp
fileIdentifier
Ć5 04´
shortFileIdentifier
´04´ = 4
numberOfBytes
flagChecksum
False
lifeCycleStatus
body
´XX…YY´
Zugriffsart
Zugriffsbedingung
READ BINARY
ALWAYS
SELECT
ALWAYS
UPDATE BINARY
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
wird personalisiert
Bemerkung
Bemerkung
Hinweis (36)
sind:
UPDATE BINARY
Seite 58 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
8.4.2 / MF / DF.NK / EF.C.NK.VPN.R2048S256
Diese Datei enthält ein Zertifikat mit dem öffentlichen Schlüssel
PrK.NK.VPN.R2048S256 (siehe Kapitel 8.4.4). Der Zertifikatsinhalt wird
[gemX.509_Kon] beschrieben.
zu
in
Tabelle 34: Attribute / MF / DF.NK / EF.C.NK.VPN.R2048S256
Attribute
Wert
Objekttyp
fileIdentifier
Ć5 05´
shortFileIdentifier
´05´ = 5
numberOfBytes
flagChecksum
False
lifeCycleStatus
body
´XX…YY´
Zugriffsart
Zugriffsbedingung
READ BINARY
ALWAYS
SELECT
ALWAYS
UPDATE BINARY
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
wird personalisiert
Bemerkung
Bemerkung
Hinweis (37)
sind:
UPDATE BINARY
Seite 59 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
8.4.3 / MF / DF.NK / PrK.NK.VPN.R1024S1
Dieser Schlüssel ermöglicht den Aufbau eines VPN-Kanals zu einem VPN-Konzentrator,
der nicht in der Lage ist, mit einer Schlüssellänge von 2048 Bit zu arbeiten. Dies ist gemäß [gemSpec_Krypt#5.1.1.5] zulässig. Der öffentliche Teil zu diesem Schlüssel ist in
EF.C.NK.VPN.R1024S1 enthalten (siehe Kapitel 8.4.1).
Es ist vorgesehen, dass der Netzkonnektor die beiden Verfahren
(1) " Authentication with Digital Signatures", [IKEv1#5.1] und
(2) " Authentication with Public Key Encryption", [IKEv1#5.2]
unterstützt.
Hinweis (38)
[IKEv1#5.1] spricht zwar von "RSA signatures MUST be encoded as a private key
encryption in PKCS #1 format and not as a signature in PKCS #1 format", was in der Sprache
von [PKCS#1v2.1] wegen des Wortes "encryption" an den Algorithmus RSAES-PKCS1-v1_5
denken lässt. Allerdings ist [IKEv1] im Kontext von [PKCS#1v1.5] geschrieben worden. In
[PKCS#1v1.5#9.4] wird in Bullet 3 implizit vorgeschrieben, dass in der Sprache von
[PKCS#1v2.11] nicht RSAES-PKCS1-v1_5 sondern RSASSA-PKCS1-v1_5 zu verwenden ist.
Tabelle 35: Attribute / MF / DF.NK / PrK.NK.VPN.R1024S1
Attribute
Objekttyp
keyIdentifier
privateKey
algorithmIdentifier
Wert
privates RSA Objekt
´04´ = 4
signPKCS1_V1_5
}
Zugriffsart
Zugriffsbedingung
INTERNAL AUTH.
ALWAYS
PSO Decipher
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
wird personalisiert
siehe [IKEv1#5.1]
siehe [IKEv1#5.2]
Bemerkung
Bemerkung
Hinweis (39)
Seite 60 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
8.4.4 / MF / DF.NK / PrK.NK.VPN.R2048S256
Dieser Schlüssel ermöglicht den Aufbau eines VPN-Kanals zu einem VPN-Konzentrator,
der in der Lage ist, mit einer Schlüssellänge von 2048 Bit zu arbeiten. Der öffentliche Teil
zu diesem Schlüssel ist in EF.C.NK.VPN.R2048S256 enthalten (siehe Kapitel 8.4.2).
Es ist vorgesehen, dass der Netzkonnektor die beiden Verfahren
(1) " Authentication with Digital Signatures", [IKEv1#5.1] und
(2) " Authentication with Public Key Encryption", [IKEv1#5.2]
unterstützt.
Hinweis (40)
[IKEv1#5.1] spricht zwar von "RSA signatures MUST be encoded as a private key
encryption in PKCS #1 format and not as a signature in PKCS #1 format", was in der Sprache
von [PKCS#1v2.1] wegen des Wortes "encryption" an den Algorithmus RSAES-PKCS1-v1_5
denken lässt. Allerdings ist [IKEv1] im Kontext von [PKCS#1v1.5] geschrieben worden. In
[PKCS#1v1.5#9.4] wird in Bullet 3 implizit vorgeschrieben, dass in der Sprache von
[PKCS#1v2.11] nicht RSAES-PKCS1-v1_5 sondern RSASSA-PKCS1-v1_5 zu verwenden ist.
Tabelle 36: Attribute / MF / DF.NK / PrK.NK.VPN.R2048S256
Attribute
Objekttyp
keyIdentifier
privateKey
algorithmIdentifier
Wert
privates RSA Objekt
´05´ = 5
alle Werte aus der Menge, siehe [gemSpec_eGK_P1: {
signPKCS1_V1_5 rsaClientAuthentication
}
Zugriffsart
Zugriffsbedingung
INTERNAL AUTH.
ALWAYS
PSO Decipher
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
wird personalisiert
siehe [IKEv1#5.1]
siehe [IKEv1#5.2]
Bemerkung
Bemerkung
Hinweis (41)
Kommandos, die gemäß [gemSpec_eGK_P1 mit einem privaten Authentisierungsobjekt arbeiten sind:
EXTERNAL AUTHENTICATE, INTERNAL AUTHENTICATE
Seite 61 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
8.5 / MF / DF.SAK (normativ)
Die Anwendung DF.SAK enthält kryptographische Objekte der Signaturanwendungskomponente.
Der in dieser Anwendung enthaltene Schlüssel PrK.SAK.AUT unterstützt den Aufbau eines TLS-Kanals zwischen der SAK und einem Extended Trusted Viewer sowie der SAK
zu einem Kartenterminal. Wegen des erhöhten Schutzbedarfes dieser Verbindungen wird
eine Schlüssellänge von 2048 Bit verwendet (siehe [gemSpec_Krypt#5.1.1.8]).
Diese Anwendung enthält neben dem vorgenannten Schlüssel PrK.SAK.AUT ein Zertifikat
C.SAK.AUT, welches den öffentlichen Schlüssel PuK.SAK.AUT enthält. Es wird als nicht
erforderlich angesehen, dass die Anwendung auch Zertifikate höherer Ebenen enthält.
Mit dem Schlüsselpaar PrK.SAK.SIG und PuK.SAK.SIG wird die Erstellung einer Signatur, bzw. Überprüfung einer Signatur für den Integritätsschutz von Konfigurationsdaten der
SAK ermöglicht. Es wird eine Schlüssellänge von 2048 Bit verwendet.
Der in dieser Anwendung enthaltene Schlüssel PrK.SAK.AUTD_CVC unterstützt den Aufbau eines Trusted Channels zwischen der Signaturanwendungskomponente einerseits
und der sicheren Signaturerstellungseinheit andererseits.
Diese Anwendung enthält neben dem vorgenannten Schlüssel PrK.SAK.AUTD_CVC ein
Zertifikat
C.SAK.AUTD_CVC,
welches
den
öffentlichen
Schlüssel
zu
PrK.SAK.AUTD_CVC enthält. Zur Prüfung des Zertifikates C.SAK.AUTD_CVC wird der
öffentliche Schlüssel aus C.CA_SAK.CS (siehe Kapitel 8.2.2) benötigt.
Die Anwendung DF.SAK MUSS auf einer SMC–K vorhanden sein.
Die Anwendung DF.SAK MUSS gemäß den Angaben dieses Unterkapitels konfiguriert sein.
Tabelle 37: Attribute / MF / DF.SAK
Attribute
Wert
Objekttyp
Ordner
´D276 0001 4404´
fileIdentifier
lifeCycleStatus
Zugriffsart
Zugriffsbedingung
SELECT
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
Bemerkung
Bemerkung
Hinweis (42)
Hinweis (43)
Seite 62 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Abbildung 6: Objektstruktur der Anwendung DF.SAK
8.5.1 / MF / DF.SAK / EF.C.SAK.AUT
Diese Datei enthält ein Zertifikat mit dem öffentlichen Schlüssel PuK.SAK.AUT zu
PrK.SAK.AUT (siehe Kapitel 8.5.3). Der Zertifikatsinhalt wird in [gemX.509_Kon] beschrieben.
Tabelle 38: Attribute / MF / DF.SAK / EF.C.SAK.AUT
Attribute
Wert
Objekttyp
fileIdentifier
Ć5 06´
shortFileIdentifier
´06´ = 6
numberOfBytes
flagChecksum
False
lifeCycleStatus
body
´XX…YY´
Zugriffsart
Zugriffsbedingung
READ BINARY
ALWAYS
SELECT
ALWAYS
UPDATE BINARY
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
wird personalisiert
Bemerkung
Bemerkung
Hinweis (44)
sind:
UPDATE BINARY
Seite 63 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
8.5.2 / MF / DF.SAK / EF.C.SAK.AUTD_CVC
Diese Datei enthält ein CV–Zertifikat gemäß [gemPKI_Reg] und [gemSpec_eGK_P1],
welches den öffentlichen Schlüssel PuK.SAK.AUTD_CVC (siehe Tabelle 41) enthält. Dieses Zertifikat lässt sich mittels des öffentlichen Schlüssels aus EF.C.CA_SAK.CS (siehe
Tabelle 24) prüfen.
Für die CHR des Zertifikates MUSS gelten: CHR = ´0090´ || ICCSN, wobei die
ICCSN denselben Wert besitzen MUSS wie das Wertfeld aus (N985.400)b.
Tabelle 39: Attribute / MF / EF.C.SAK.AUTD_CVC
Attribute
Wert
Objekttyp
fileIdentifier
´2F 03´
shortFileIdentifier
´03´ = 3
numberOfBytes
´0155´ Oktett = 341 Oktett
flagChecksum
False
lifeCycleStatus
body
´7F21 820150 XX...YY´
Zugriffsart
Zugriffsbedingung
READ BINARY
ALWAYS
SELECT
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
wird personalisiert
Bemerkung
Bemerkung
Hinweis (45)
sind:
UPDATE BINARY
Hinweis (46)
Das Zertifikat enthält die Rolle CHA = Signaturanwendungskomponente (SAK) =
´D2760000400033´ (siehe [gemPKI_Reg])
Seite 64 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
8.5.3 / MF / DF.SAK / PrK.SAK.AUT
Dieser Schlüssel ermöglicht den Aufbau eines TLS-Kanals von der SAK zu einem Trusted
Viewer, oder von der SAK zu einem Kartenterminal. Wegen des erhöhten Schutzbedarfes
dieser Verbindung wird hier eine Schlüssellänge von 2048 Bit verwendet (siehe
[gemSpec_Krypt#5.1.1.8]). Der öffentliche Teil zu diesem privaten Schlüssel ist in
EF.C.AK.AUT enthalten (siehe Kapitel 8.3.1).
Aus Sicht des Trusted Viewers handelt die SAK beim Aufbau der TLS-Verbindung als
Client oder Server. Gemäß [TLS#8.1.1] wird dabei während der Serverauthentisierung
eine Entschlüsselung nach [PKCS#1v2.1#7.2.2] durchgeführt.
Aus Sicht des Kartenterminals handelt die SAK beim Aufbau des TLS-Kanals als Client.
Gemäß [TLS#7.4.8] wird dabei während der Clientauthentisierung eine Signatur nach
[PKCS#1v2.1] durchgeführt, wobei der Chipkarte der DigestInfo vorgegeben wird.
Tabelle 40: Attribute / MF / DF.SAK / PrK.SAK.AUT
Attribute
Objekttyp
keyIdentifier
privateKey
algorithmIdentifier
Wert
privates RSA Objekt
´06´ = 6
signPKCS1_V1_5
}
Zugriffsart
Zugriffsbedingung
INTERNAL AUTH.
ALWAYS
PSO Decipher
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
wird personalisiert
Serverauthent.
Clientauthent.
Bemerkung
Bemerkung
Hinweis (47)
Seite 65 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
8.5.4 / MF / DF.SAK / PrK.SAK.AUTD_CVC
Dieser Schlüssel wird im Rahmen von asymmetrischen Authentisierungsprotokollen verwendet. Insbesondere dient dieser Schlüssel der Vereinbarung von Introductionkeys (siehe Anhang A.1). Die Schlüssellänge ist in [gemSpec_Krypt#5.1.2.1] festgelegt.
Tabelle 41: Attribute / MF / DF.SAK / PrK.SAK.AUTD_CVC
Attribute
Objekttyp
keyIdentifier
privateKey
algorithmIdentifier
Wert
privates RSA Objekt
´10´ = 16
alle Werte aus der Menge, siehe [gemSpec_eGK_P1]
{rsaSessionkey4Intro, rsaSessionkey4TC}
Zugriffsart
Zugriffsbedingung
EXTERNAL AUTH.
ALWAYS
INTERNAL AUTH.
AUT( ´D276 0000 4000 35´ )
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
wird personalisiert
Bemerkung
siehe Hinweis (49)
Bemerkung
Hinweis (48)
Hinweis (49)
Diese Rolle ist gemäß [gemPKI_Reg#Tabelle 12] einem HBA zugewiesen.
Seite 66 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
8.5.5 / MF / DF.SAK / PrK.SAK.SIG
Dieser private Schlüssel dient dazu Konfigurationsdaten der SAK zu signieren mit dem
Ziel die Integrität der Daten zu schützen. Da es sich um eine SAK interne Funktionalität
handelt, ist weder ein Zertifikat noch ein Zugriffschutz erforderlich.
Der zugehörige öffentliche Schlüssel wird mit PuK.SAK.SIG bezeichnet und lässt sich
mittels des in [gemSpec_eGK_P1#15.9.2.2] beschriebenen Use Cases auslesen.
Tabelle 42: Attribute / MF / DF.SAK / PrK.SAK.SIG
Attribute
Objekttyp
keyIdentifier
privateKey
algorithmIdentifier
Wert
privates RSA Objekt
´11´ = 17
alle Werte aus der Menge, siehe [gemSpec_eGK_P1]
{ sign9796_2_DS2, signPKCS1_V1_5, signPSS }
Zugriffsart
Zugriffsbedingung
GEN. ASYM KEY P. nicht Gegenstand dieser Spezifikation
P1=´84´
GEN. ASYM KEY P. ALWAYS
P1=´81´
PSO CompDigSig
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
wird personalisiert
Bemerkung
Bemerkung
Hinweis (50)
Kommandos, die gemäß [gemSpec_eGK_P1] mit einem privaten Signaturobjekt
arbeiten sind:
GENERATE ASYMMETRIC KEY PAIR, PSO Compute Digital Signature
Seite 67 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
8.6 / MF / DF.Sicherheitsanker (normativ)
Die Anwendung DF.Sicherheitsanker enthält Zertifikate, die im Rahmen der Prüfung von
TSL- oder TCL-Listen relevant sind.
Hinweis (51)
Aktuell wird in diesem Ordner nur das Root Zertifikat C.TSL.CA gespeichert. Dieses selbstsignierte Zertifikat enthält einen öffentlichen Schlüssel zur Prüfung der Signer Zertifikate C.TSL.SIG und C.TCL.SIG. Die öffentlichen Schlüssel der letztgenannten Signaturzertifikate dienen dazu, Signaturen von TSL bzw. TCL Listen zu prüfen. Da die Gültigkeit der Signaturzertifikate vergleichsweise kurz ist (nach derzeitiger Festlegung zwei Jahre) im Vergleich zur
(derzeit fünfjährigen) Gültigkeit des Root–Zertifikates und ein Zertifikatsupdate innerhalb der
SMC–K derzeit nicht möglich ist, wird auf der SMC–K nur das Root–Zertifikat gespeichert.
Die Anwendung DF.Sicherheitsanker KANN auf einer SMC–K vorhanden sein.
Die Anwendung DF.Sicherheitsanker KANN auf einer SMC–K fehlen.
Wenn die Anwendung DF.Sicherheitsanker vorhanden ist, dann MUSS sie gemäß
den Angaben dieses Unterkapitels konfiguriert sein.
Tabelle 43: Attribute / MF / DF.Sicherheitsanker
Attribute
Wert
Objekttyp
Ordner
´D276 0001 4405´
fileIdentifier
lifeCycleStatus
Zugriffsart
Zugriffsbedingung
SELECT
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
Bemerkung
Bemerkung
Hinweis (52)
Hinweis (53)
Abbildung 7: Dateistruktur der Anwendung DF.Sicherheitsanker
Seite 68 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
8.6.1 / MF / DF.Sicherheitsanker / EF.C.TSL.CA
Diese Datei enthält ein Zertifikat mit dem öffentlichen Schlüssel PuK.TSL.CA. Dieser öffentliche Schlüssel dient der Verifikation der Zertifikate C.TCL.SIG und C.TSL.SIG. Bei
C.TSL.CA handelt es sich um ein selbstsigniertes Zertifikat.
Tabelle 44: Attribute / MF / DF.Sicherheitsanker / EF.C.TSL.CA
Attribute
Wert
Objekttyp
fileIdentifier
Ć6 01´
shortFileIdentifier
´01´ = 1
numberOfBytes
flagChecksum
False
lifeCycleStatus
body
´XX…YY´
Zugriffsart
Zugriffsbedingung
READ BINARY
ALWAYS
SELECT
ALWAYS
andere
NEVER
Zugriffsart
Zugriffsbedingung
alle
Bemerkung
wird personalisiert
Bemerkung
Bemerkung
Hinweis (54)
sind:
UPDATE BINARY
Seite 69 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
9 Verschiedenes (informativ)
9.1 Äußere Gestaltung
Die äußere Gestaltung einer SMC–K ist in [gemSpec_SMC_OPT] festgelegt.
Hinweis (55)
Gemäß [gemSpec_SMC_OPT] handelt es sich um eine ID–1 Karte, mit heraustrennbarem ID–000 Plug–in.
9.2 Zulassung
Die Zulassung einer SMC–K wird im Dokument [gemZulKomp-SMC] festgelegt.
Seite 70 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Anhang A: Use Cases in DF.SAK (informativ)
Dieser Anhang beschreibt die wesentlichen Use Cases der Applikation DF.SAK.
A.1 – Vorstellungsrunde
Im Rahmen der hier so bezeichneten „Vorstellungsrunde“ findet eine gegenseitige Authentisierung mit Aushandlung von Sessionkeys statt, die im Anschluss an eine erfolgreiche Authentisierung persistent als Introductionkeys gespeichert werden. Der Nutzen dieser „Vorstellungsrunde“ liegt darin, dass bei späteren Authentisierungen dann performant
nutzbare symmetrische Schlüssel in den beteiligten Komponenten vorliegen. Die vereinbarten Introductionkeys sind individuell für die beteiligten Authentisierungsschlüssel. Falls
also eine Komponente A n anderen Komponenten „vorgestellt“ wird, so sind in Komponente A deshalb n verschiedene Introductionkeys zu speichern.
Offensichtlich ist dieses Verfahren weniger geeignet eGKs einem HBA dauerhaft vorzustellen. Dazu reicht der Speicherplatz des HBA nicht aus. Sinnvoll einsetzbar ist dieses
Verfahren in Organisationen, wo insgesamt eine überschaubare Menge von HBA, SMC–
A/B und SMC–K vorhanden ist und diese Karten laufend miteinander interagieren.
Hier wird davon ausgegangen, dass
(1) eine SMC–K und ein HBA beteiligt sind,
(2) die SMC–K im Besitz des öffentlichen Schlüssels PuK.HPC.AUTD_CVC ist, mithin
das entsprechende Zertifikat C.HPC.AUTD_CVC in die SMC–K importiert wurde,
(3) der HBA im Besitz des öffentlichen Schlüssels PuK.SAK.AUTD_CVC ist, mithin
das entsprechende Zertifikat C.SAK.AUTD_CVC in den HBA importiert wurde.
Es werden folgende Schritte durchgeführt:
(4) In der SMC–K wird gemäß Kapitel 5.3.20.2 der Schlüssel PrK.SAK.AUTD_CVC
mit der algId rsaSessionkeyIntro selektiert.
(5) In der SMC–K wird gemäß Kapitel 5.3.20.4 der öffentliche Schlüssel
PuK.HPC.AUTD_CVC mit der keyReference = CHR aus C.HPC.AUTD_CVC und
algId rsaSessionkeyIntro selektiert.
(6) Im HBA wird gemäß Kapitel 5.3.20.2 der Schlüssel PrK.HPC.AUT_CVC mit der algId rsaSessionkeyIntro selektiert.
(7) Im
HBA
wird
gemäß
Kapitel 5.3.20.4
der
öffentliche
Schlüssel
PuK.SAK.AUTD_CVC mit der keyReference = CHR aus C.SAK.AUTD_CVC und
der algId rsaSessionkeyIntro selektiert.
(8) Die Authentisierungssequenz gemäß [gemSpec_eGK_P1#16.4.2]wird ausgeführt,
wobei die SMC–K den Platz der „Gegenstelle“ innehat und der HBA den Platz der
„eGK“.
Seite 71 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
A.2 – Aufbau Trusted Channel
Hier wird davon ausgegangen, dass
(1) eine SMC–K und ein HBA beteiligt sind,
(2) Vorstellungsschlüssel gemäß Anhang A.1 zwischen der SMC–K und dem HBA
etabliert wurden,
(3) die Seriennummer der SAK aus deren EF.GDO bekannt sei,
(4) die Seriennummer des HBA aus dessen EF.GDO bekannt sei.
Es werden folgende Schritte durchgeführt:
(5) In der SMC–K wird gemäß Kapitel 5.3.20.1 der Vorstellungsschlüssel mit der keyRef gemäß der CHR aus C.HPC.AUTD_CVC unter Berücksichtigung von
Hinweis (4) mit der algId desSessionkey4TC selektiert.
(6) In der SMC–K wird gemäß Kapitel 5.3.20.3 der Vorstellungsschlüssel mit der keyRef gemäß der CHR aus C.HPC.AUTD_CVC unter Berücksichtigung von
Hinweis (4) mit der algId desSessionkey4TC selektiert.
(7) Im HBA wird gemäß Kapitel 5.3.20.5 der Vorstellungsschlüssel mit der keyRef
gemäß der CHR aus C.SAK.AUTD_CVC unter Berücksichtigung von Hinweis (4)
mit der algId desSessionkey4SM selektiert.
(8) Die Authentisierungssequenz gemäß [gemSpec_eGK_P1#16.4.1] wird ausgeführt,
wobei entweder
a) die SMC–K den Platz der „Gegenstelle“ und der HBA den Platz der „eGK“ innehat, oder
b) die SMC–K den Platz der „eGK“ und der HBA den Platz der „Gegenstelle“ innehat.
Hinweis (56)
In Punkt (8) werden zwei Alternativen für die Authentisierungsreihenfolge genannt.
Je nach Konfiguration der Zugriffsbedingungen für die beteiligten privaten Schlüssel ist es
möglich, dass eine der Alternativen nicht durchführbar ist.
A.3 – Austausch von APDUs mittels Trusted Channel
Die in diesem Anhang behandelten technischen Use Cases unterstützen einen Trusted
Channel derart, dass es der SAK möglich ist, eine ungeschützte Kommando APDU (das
heißt ohne Secure Messaging) in eine gesicherte Kommando APDU zu transformieren.
Zudem wird es der SAK ermöglicht, eine geschützte Antwort APDU in eine ungesicherte
Antwort APDU zu transformieren
A.3.1 – Sicherung einer Kommando APDU
Die dabei zu verwendenden Algorithmen sind in [gemSpec_eGK_P1#Kapitel 14.2] beschrieben.
Falls die Kommando APDU Daten enthält und diese verschlüsselt zu übertragen sind,
dann führt die SMC–K dabei die Schritte gemäß [gemSpec_eGK_P1#(N032.200)a] und
Seite 72 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
[gemSpec_eGK_P1#(N032.200)b] durch. Dazu wird das Kommando PSO Encipher gemäß Kapitel 5.3.16.1 verwendet. Dabei gelten folgende Zusammenhänge:
Tabelle 45: Verschlüsselung von Kommandodaten
[gemSpec_eGK_P1]
(N032.200)a: Data
(N032.200)a: C
dieses Dokument
(N091.440): M
(N091.655)a.3: C
In jedem Fall ist die Kommando APDU bei der gesicherten Übertragung durch einen MAC
zu sichern. Dabei führt die SMC–K die Schritte gemäß [gemSpec_eGK_P1#(N032.700)]
und [gemSpec_eGK_P1#(N032.800)a.v] durch. Dazu wird das Kommando PSO Compute
CC gemäß Kapitel 5.3.14.1 verwendet. Dabei gelten folgende Zusammenhänge:
Tabelle 46: MAC Sicherung eines Kommandos
[gemSpec_eGK_P1]
(N032.800)a.v: MACin
(N032.800)a.v: MAC
dieses Dokument
(N087.220): data
(N087.248)b: mac
B.3.2 – Entsicherung einer Antwort APDU
Die dabei verwendeten Algorithmen sind in [gemSpec_eGK_P1#Kapitel 14.3] beschrieben.
In jedem Fall ist die Antwort APDU bei der gesicherten Übertragung durch einen MAC
geschützt. Zur MAC–Prüfung wird das Kommando PSO Verify CC gemäß Kapitel 5.3.17.1
verwendet. Dabei gelten folgende Zusammenhänge:
Tabelle 47: Prüfung eines MAC in einer Antwort APDU
[gemSpec_eGK_P1]
(N034.100)a.iv: MACin
(N034.100)a.iv: MAC
dieses Dokument
(N096.340): data
(N096.343): mac
Hinweis (57)
Der Zusammenhang zwischen der Antwort APDU einerseits und MACin und MAC
andererseits ist in [gemSpec_eGK_P1#(N034.300)a, (N034.100)a und (N034.200]) beschrieben.
Falls die Antwort APDU Daten enthält und diese verschlüsselt übertragen wurden, dann
wird zur Entschlüsselung das Kommando PSO Decipher gemäß Kapitel 5.3.15.1 verwendet. Dabei gelten folgende Zusammenhänge:
Tabelle 48: Entschlüsselung von Antwortdaten
[gemSpec_eGK_P1]
(N033.700)b: C
(N033.700)b: Data
dieses Dokument
(N089.840): C
(N089.847)a.3: plain
Hinweis (58)
Der Zusammenhang zwischen der Antwort APDU einerseits und C andererseits ist
in [gemSpec_eGK_P1#(N034.300)a und (N033.700)d] beschrieben.
Seite 73 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Anhang B
B1 – Abkürzungen
Kürzel
Erläuterung
AK
APDU
ATR
CA
C2C
DF
EF
GDO
HBA
MF
NK
RCA
SAK
TPM
TSL
VPN
Anwendungskonnektor
Application Protocol Data Unit
Answer to Reset
Certification Authority
Card to Card
Dedicated File
Elementary File
Global Data Object
Heilberufeausweis
Master File
Netzkonnektor
Root Certification Authority
Signaturanwendungskomponente
Trusted Platform Module
Trust-service Status List
Virtual Private Network
B2 – Glossar
Das Projektglossar wird als eigenständiges Dokument zur Verfügung gestellt.
B3 – Abbildungsverzeichnis
Abbildung 1: Überblick über die Funktionsblöcke des Konnektors .................................. 16
Abbildung 2: Aufbau der COS Spezifikationen................................................................ 19
Abbildung 3: Dateistruktur einer SMC–K auf oberster Ebene.......................................... 47
Abbildung 4: Dateistruktur der Anwendung DF.AK ......................................................... 54
Abbildung 5: Dateistruktur der Anwendung DF.NK ......................................................... 58
Abbildung 6: Objektstruktur der Anwendung DF.SAK ..................................................... 63
Abbildung 7: Dateistruktur der Anwendung DF.Sicherheitsanker .................................... 68
B4 – Tabellenverzeichnis
Tabelle 1: Liste der Komponenten, aus deren Sicht Anforderungen betrachtet werden .. 13
Tabelle 2: Funktionale Anforderungen ............................................................................ 14
Seite 74 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Tabelle 3: Nicht–funktionale Anforderungen ................................................................... 15
Tabelle 4: Sicherheitsanforderungen .............................................................................. 15
Tabelle 5: PSO Compute CC, Berechnen einer kryptographischen Checksumme.......... 30
Tabelle 6: PSO Compute CC Antwort APDU im Erfolgsfall ............................................. 30
Tabelle 7: PSO Compute CC Antwort APDU im Fehlerfall .............................................. 30
Tabelle 8: PSO Decipher, Entschlüsseln mittels DES ..................................................... 32
Tabelle 9: PSO Encipher, Verschlüsseln mittels DES ..................................................... 33
Tabelle 10: PSO Verify CC, Prüfen einer kryptographischen Checksumme.................... 35
Tabelle 11: PSO Verify CC Antwort APDU im Erfolgsfall ................................................ 35
Tabelle 12: PSO Verify CC Antwort APDU im Fehlerfall ................................................. 35
Tabelle 13: GET RANDOM............................................................................................. 37
Tabelle 14: GET RANDOM Antwort APDU im Erfolgsfall................................................ 37
Tabelle 15: GET RANDOM Antwort APDU im Fehlerfall................................................. 37
Tabelle 16: MANAGE CHANNEL zum Öffnen eines logischen Kanals ........................... 38
Tabelle 17: MANAGE CHANNEL zum Schließen eines Kanals ...................................... 39
Tabelle 18: MANAGE CHANNEL Antwort APDU im Erfolgsfall....................................... 39
Tabelle 19: MANAGE CHANNEL Antwort APDU im Fehlerfall........................................ 39
Tabelle 20: ATR Kodierung............................................................................................. 45
Tabelle 21: Beispielhafte Kodierung der Historical Bytes ................................................ 46
Tabelle 22: Attribute / MF................................................................................................ 46
Tabelle 23: Attribute / MF / EF.ATR ................................................................................ 47
Tabelle 24: Attribute / MF / EF.C.CA_SAK.CS................................................................ 49
Tabelle 25: Attribute / MF / EF.DIR ................................................................................. 50
Tabelle 26: Attribute / MF / EF.GDO ............................................................................... 51
Tabelle 27: Attribute / MF / EF.Version ........................................................................... 52
Tabelle 28: Attribute / MF / PuK.RCA.CS........................................................................ 53
Tabelle 29: Attribute / MF / DF.AK .................................................................................. 54
Tabelle 30: Attribute / MF / DF.AK / EF.C.AK.AUT.......................................................... 55
Tabelle 31: Attribute / MF / DF.AK / PrK.AK.AUT............................................................ 56
Tabelle 32: Attribute / MF / DF.NK .................................................................................. 57
Tabelle 33: Attribute / MF / DF.NK / EF.C.NK.VPN.R1024S1 ......................................... 58
Tabelle 34: Attribute / MF / DF.NK / EF.C.NK.VPN.R2048S256 ..................................... 59
Tabelle 35: Attribute / MF / DF.NK / PrK.NK.VPN.R1024S1 ........................................... 60
Tabelle 36: Attribute / MF / DF.NK / PrK.NK.VPN.R2048S256 ....................................... 61
Tabelle 37: Attribute / MF / DF.SAK................................................................................ 62
Tabelle 38: Attribute / MF / DF.SAK / EF.C.SAK.AUT..................................................... 63
Seite 75 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Tabelle 39: Attribute / MF / EF.C.SAK.AUTD_CVC......................................................... 64
Tabelle 40: Attribute / MF / DF.SAK / PrK.SAK.AUT ....................................................... 65
Tabelle 41: Attribute / MF / DF.SAK / PrK.SAK.AUTD_CVC ........................................... 66
Tabelle 42: Attribute / MF / DF.SAK / PrK.SAK.SIG ........................................................ 67
Tabelle 43: Attribute / MF / DF.Sicherheitsanker............................................................. 68
Tabelle 44: Attribute / MF / DF.Sicherheitsanker / EF.C.TSL.CA .................................... 69
Tabelle 45: Verschlüsselung von Kommandodaten ........................................................ 73
Tabelle 46: MAC Sicherung eines Kommandos.............................................................. 73
Tabelle 47: Prüfung eines MAC in einer Antwort APDU.................................................. 73
Tabelle 48: Entschlüsselung von Antwortdaten............................................................... 73
B5 – Referenzierte Dokumente
Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument
referenzierten Dokumente der gematik. Der mit dem vorliegenden Dokument korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen, die im Rahmen des Vorhabens zur Einführung der Gesundheitskarte veröffentlicht werden, wird pro Release in einer
Dokumentenlandkarte definiert. Version und Stand der referenzierten Dokumente sind
daher in der nachfolgenden Tabelle nicht aufgeführt. Die jeweils gültige Version und das
Freigabedatum der aufgeführten gematik-Dokumente entnehmen Sie bitte der von der
gematik veröffentlichten Dokumentenlandkarte (aktuell [gemDokLK_2.3.4]), wobei jeweils
der aktuellste Releasestand maßgeblich ist, in dem die vorliegende Version aufgeführt
wird. Zur Unterstützung der Zuordnung wird in der Dokumentenlandkarte im Kapitel 4 eine
Übersicht über die Dokumentenversionen und deren Zuordnung zu den verschiedenen
Releases bereitgestellt.
[Quelle]
Herausgeber (Erscheinungsdatum): Titel
[gemDokLK_2.3.4]
Dokumentenlandkarte Releasestand 2.3.4 – Online Feldtest 10.000
Festlegung der Versionsstände
Gesamtarchitektur
Registrierung einer CVC-CA der zweiten Ebene
Spezifikation elektronische Gesundheitskarte;
Teil 1 – Spezifikation der elektrischen Schnittstelle
Konnektorspezifikation
Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur
Spezifikation eHealth-Kartenterminal
Gemeinsame optische Merkmale der SMC
[gemGesArch]
[gemPKI_Reg]
[gemSpec_eGK_P1]
[gemSpec_Kon]
[gemSpec_Krypt]
[gemSpec_KT]
[gemSpec_SMC_OPT]
Seite 76 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
[Quelle]
[gemX.509_Kon]
[gemZulKomp-SMC]
Festlegungen zu den X.509-Komponentenzertifikaten des Konnektors
Zulassungsverfahren Komponente SMC
Weitere Referenzierungen:
[Quelle]
[EN 1867]
[IKEv1]
[ISO3166]
[ISO7816–4]
[ISO8825–1]
[ISO_SD5]
[PKCS#1v1.5]
[PKCS#1v2.1]
[RFC 2119]
[TLS]
[TR–03114]
[TR–03115]
EN 1867:1997
Machine readable cards – Health care applications – Numbering system and
registration procedure for issuer identifiers
DIN EN 1867:1997
Maschinenlesbare Karten – Anwendungen im Gesundheitswesen – Benummerungssystem und Registrierungsverfahren für Kartenausgeberschlüssel
The Internet Key Exchange (IKE), RFC 2409
ISO/IEC 3166: Codes for the representations of names of countries
Identification cards — Integrated circuit cards —
Part 4: Organization, security and commands for interchange,
second edition, 2005-01-15
Information technology – ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
and Distinguished Encoding Rules (DER)
http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf
ISO/IEC JTC1/SC17 STANDING DOCUMENT 5, 2006-06-19
Register of IC manufacturers
http://www.pkicc.de/cms/media/pdfs/IC_manufacturer_ISO_SD5_1962006.pdf
PKCS #1: RSA Encryption Standard, An RSA Laboratories Technical Note
Version 1.5, Revised November 1, 1993
PKCS #1 v2.1: RSA Cryptography Standard, RSA Laboratories, 2002-06-14
Network Working Group, Request for Comments: 2119, S. Bradner Harvard,
University, March 1997, Category: Best Current Practice
Key words for use in RFCs to Indicate Requirement Levels
http://www.apps.ietf.org/rfc/rfc2119.html
The Transport Layer Security (TLS) Protocol, Version 1.1, RFC 4346
BSI TR–03114, Stapelsignatur mit dem Heilberufsausweis
Version: 2.0, Veröffentlichung: 22.10.2007
http://www.bsi.de/literat/tr/tr03114/BSI-TR-03114.pdf
BSI TR-03115, Komfortsignatur mit dem Heilberufsausweis
Version: 2.0, Veröffentlichung: 19.10.2007
http://www.bsi.de/literat/tr/tr03115/BSI-TR-03115.pdf
B6 – Klärungsbedarf
Kap.
Offener Punkt
Zuständig
6.4
Auswirkungen von IKEv2 auf Kapitel 6.4 sind zu prüfen
SPE/DK, AFI
Zugriffsrechtematrix in SMC–K oder in SAK
IST, BSI
Seite 77 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008
Anhang Y: Sicherheitshinweise (informativ)
Der Hauptteil des Dokumentes enthält im Wesentlichen funktionale Anforderungen. Darüber hinaus sind bei
der COS Entwicklung auch Sicherheitsanforderungen zu beachten. Grundsätzlich sind Sicherheitsanforderungen in einem Protection Profile oder Security Target zu finden. Deshalb ist die Zukunft dieses Abschnittes
ungewiss, da Redundanzen zwischen den vorgenannten Dokumenten und diesem Abschnitt unerwünscht
sind. Entweder dient dieser Abschnitt in Zukunft als Stoffsammlung für Aspekte, welche die vorgenannten
Dokumente (neben anderem) enthalten sollten, oder dieser Abschnitt entfällt mangels Relevanz.
1. Symmetrische Vorstellungsobjekte sind sicher zu speichern.
Seite 78 von 78
Version: 1.1.1
© gematik
Stand: 26.08.2008

Spezifikation der SMC–K

Transcription

Similar documents

Sinnesobjekte - Das Buddhistische Haus

Ein Referenzmodell zur Integration der

Version 1.1.1 vom 02.04.2008

SICCT Secure Interoperable ChipCard Terminal

Spezifikation eHealth-Kartenterminal