Heilberufs-Ausweis und Security Module Card

Transcription

Einführung der Gesundheitskarte
Heilberufs-Ausweis
und
Security Module Card
Te i l 2 : H B A - A n w e n d u n g e n u n d F u n k t i o nen
Version:
2.1.0 de
Stand:
28.5.2006
Status:
in Bearbeitung
HBA_Spezifikation _Teil2_V2 1 0-de.doc
Version: 2.1.0
Seite 1 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
Dokumentinformationen
Datum
Version
Modifikationen
31.07.2003
HPC V2.0
New version
22.05.2004
HPC V2.0 Rev. 1
(Draft)
- Precision and corrections
- SE selection additionally at MF level
01.09.2004
HPC V2.0 Rev. 1
(Pre-Final)
- Precision and corrections
- Card-to-card authentication only asymmetric
08.05.2005
HPC V2.05 Draft
Updated Version, some modifications still to be done
25.05.2005
HPC V2.06
Changes:
- References updated
- File structure updated
- AID.DINSIG added
- Access rules partially updated
- Certificate hierarchy updated
- Hashing enhanced
20.06.2005
HPC V2.07
Changes:
- ES-Certificate content updated
- ATR revised (greater card I/O buffer)
- SMC types introduced
- File structure updated
- Key length adopted
- New Figure H.1
30.06.2005
HPC V2.08
Changes:
- Clause 2 completely revised (now Clause 4)
- Downloading of applications added
19.09.2005
HPC V2.09
Changes:
- Harmonization with eGK
- Splitting of original HPA in HPA, QES & ESIGN
- Notation completed
- DF.CIA.ESIGN adopted to the functionality of
DF.ESIGN (only AUT and ENC)
07.10.2005
HPC V2.09
Changes:
- Role Id added in Tabelle F.2
19.11.2005
HPC V2.1 Draft
Changes:
- Figures with authentication proc. Moved to Part 1
- Download with asym. Authentication
Version: 2.1.0
Seite 2 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
Datum
Version
Modifikationen
- HPD file added
- Move of PIN management to MF level
- Addition of CVC.HPC.TCE
- Reduction of Public Keys to PuK.RCA.CS
14.12.2005
HPC V2.1
Changes:
- Harmonization CVC with eGK
- Role identifiers encoded with profile ID
- Editorial improvments
21.02.2006
HPC V2.1.0
Changes:
- Harmonization with eGK
- some minor precisions and corrections
28.05.2006
HBA 2.1.0 de
Übersetzung in die deutsche Sprache durch gematik
Version: 2.1.0
Seite 3 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
Inhaltsverzeichnis
Dokumentinformationen ......................................................................................2
Inhaltsverzeichnis ................................................................................................4
1
Erläuterungen zum Inhalt der Dokumente.................................................11
1.1
2
Technische Spezifikationen des HBA ............................................................ 11
Einführung....................................................................................................12
2.1
Zielsetzung und Einordnung des Dokumentes ............................................. 12
2.2
Zielgruppe ......................................................................................................... 12
2.3
Geltungsbereich ............................................................................................... 12
2.4
Arbeitsgrundlagen ........................................................................................... 13
2.5
Abgrenzung des Dokumentes......................................................................... 13
2.6
Notationen......................................................................................................... 13
3 Technische Eigenschaften, Answer-to-Reset (ATR)
und
Übertragungsprotokolle ....................................................................................16
3.1
Technische Eigenschaften .............................................................................. 16
3.1.1 Answer-to-Reset ........................................................................................... 16
3.1.2 Übertragungs-Protokolle ............................................................................... 16
4
Der Heilberufsausweis ................................................................................17
4.1
Allgemeine Struktur ......................................................................................... 17
4.2
Elementary Files auf der MF-Ebene................................................................ 18
4.2.1 EF.ARR ......................................................................................................... 18
4.2.2 EF.ATR ......................................................................................................... 18
4.2.3 EF.DIR .......................................................................................................... 19
4.2.4 EF.GDO ........................................................................................................ 19
4.2.5 EF.CVC.CA_HPC.CS ................................................................................... 20
4.2.6 EF.CVC.HPC.AUT ........................................................................................ 20
4.2.7 EF.PIN........................................................................................................... 20
4.2.8 EF.PrK........................................................................................................... 20
4.2.9 EF.PuK.......................................................................................................... 21
4.3
Sicherheitsumgebungen (SEs) auf MF-Ebene............................................... 22
Version: 2.1.0
Seite 4 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
4.4
Öffnen des HBA................................................................................................ 22
4.4.1 Kommando-Sequenz nach Auslesen des ATR............................................. 22
4.4.2 Lesen von EF.ATR und EF.GDO .................................................................. 22
4.4.3 Lesen von EF.DIR......................................................................................... 23
4.4.4 Lesen der CV-Zertifikate des HBA ................................................................ 23
4.4.5 SE Auswahl auf MF-Ebene ........................................................................... 24
4.5
PIN Management .............................................................................................. 24
4.5.1 PIN Prüfung................................................................................................... 24
4.5.2 Änderung der PIN ......................................................................................... 25
4.5.3 Zurücksetzen des Fehlbedienungszählers und Setzen einer neuen PIN ..... 25
4.6
HBA/eGK-Authentifizierung ............................................................................ 26
4.6.1 Allgemeines................................................................................................... 26
4.6.2 Instanzen des CVC Schlüssel-Managements............................................... 26
4.6.3 Prüfung der CV Zertifikate der eGK .............................................................. 28
4.6.4 Durchführung des Authentifizierungs-Prozesses .......................................... 29
4.7
5
6
Autorisierung einer SMC zur Kommunikation mit einer eGK ...................... 31
Management von Kanälen...........................................................................33
5.1
Allgemeine Aspekte ......................................................................................... 33
5.2
Öffnen eines logischen Kanals ....................................................................... 33
5.3
Schließen eines logischen Kanals.................................................................. 34
Die Heilberufs-Anwendung HPA ................................................................35
6.1
File-Struktur und File-Inhalt ............................................................................ 35
6.1.1 EF.ARR ......................................................................................................... 35
6.1.2 EF.HPD ......................................................................................................... 35
7
6.2
Sicherheitsumgebungen ................................................................................. 36
6.3
Auswahl der Anwendung ................................................................................ 36
6.4
Lesen und Aktualisieren des EF.HPD ............................................................ 36
Anwendung für die qualifizierte elektronische Signatur (QES) ...............38
7.1
7.1.1 EF.ARR ......................................................................................................... 38
7.1.2 EF.PrK........................................................................................................... 39
7.1.3 EF.PIN........................................................................................................... 39
7.1.4 EF.DM ........................................................................................................... 40
7.1.5 EF.C.HP.QES ............................................................................................... 40
7.1.6 EF.C.HP.QES-AC1, -AC2 and -AC3............................................................. 40
7.2
Erzeugung einer qualifizierten elektronischen Signatur .............................. 40
7.3
Sicherheitsumgebung (SE) ............................................................................. 41
Version: 2.1.0
Seite 5 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
7.4
Auswahl der Anwendung QES........................................................................ 41
7.5
PIN Management .............................................................................................. 42
7.5.1 PIN Prüfung................................................................................................... 42
7.5.2 PIN Änderung................................................................................................ 42
7.5.3 Zurücksetzen des Fehlbedienungszählers.................................................... 43
7.6
Berechnung der QES ....................................................................................... 43
7.6.1 Signieren mit der letzten Runde der Hashwert-Berechnung im HBA............ 43
7.6.2 Signieren mit vollständigem Hashen außerhalb der Karte............................ 45
7.7
Auslesen der zu QES gehörenden Zertifikate ............................................... 46
7.8
Schreiben von Attributszertifikaten................................................................ 47
7.9
Fernbediente QES-Erzeugung ........................................................................ 47
8
Die ESIGN Anwendung................................................................................48
8.1
8.1.1 EF.ARR ......................................................................................................... 48
8.1.2 EF.PrK........................................................................................................... 48
8.1.3 EF.DM ........................................................................................................... 49
8.1.4 EF.C.HP.AUT................................................................................................ 49
8.1.5 EF.C.HP.ENC ............................................................................................... 49
8.2
Sicherheitsumgebung...................................................................................... 49
8.3
Auswahl der ESIGN Anwendung .................................................................... 50
8.4
Lesen eines X.509 Zertifikates ........................................................................ 50
8.5
PIN Management .............................................................................................. 51
8.6
Client / Server Authentifizierung..................................................................... 51
8.7
Entschlüsselung des Dokumenten-Chiffrierungsschlüssels ...................... 52
8.8
Fernbediente Nutzung der ESIGN-Anwendung............................................. 53
9
Kryptografische Informations-Anwendung ...............................................54
9.1
File-Struktur und File-Inhalt von DF.CIA.ESIGN............................................ 54
9.2
Anwendungsauswahl....................................................................................... 54
9.3
Lesen der CIA-Files.......................................................................................... 55
10
Interaktionen zwischen HBA und SMC ...................................................56
10.1
Lesen der CV-Zertifikate ................................................................................ 56
10.2
SE-Auswahl auf MF Ebene ............................................................................ 56
10.3
Auswahl der Anwendung, die mit SM genutzt werden soll ........................ 56
10.4
SE-Auswahl auf DF-Ebene ............................................................................ 56
Version: 2.1.0
Seite 6 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
10.5
CVC Prüfung ................................................................................................... 57
10.6
Authentifizierung mit TC-Einrichtung .......................................................... 57
10.7
Lesen und Aktualisieren einer Display Message ........................................ 59
11
Laden einer neuen Anwendung oder Erstellung eines EFs nach
Ausgabe des HBA ..............................................................................................61
11.1
Identifizierung des HBA-Betriebssystems ................................................... 61
11.2
Einrichtung eines Trusted Channel zwischen CAMS und HBA ................. 61
11.3
Laden einer Anwendung................................................................................ 63
11.4
Registrieren der neuen Anwendung in EF.DIR............................................ 63
11.5
Erstellung eines EF ........................................................................................ 63
Anhang A (normativ) ATR.................................................................................65
A.1 ATR Kodierung ..................................................................................................... 65
Annex B (normativ) File-Attribute, Zugriffsbedingungen und
Sicherheitsumgebungen....................................................................................68
B.1 Zugriffsbedingungen............................................................................................ 68
B.2 MF-Ebene .............................................................................................................. 68
B.3 DF.HPA .................................................................................................................. 71
B.4 DF.QES .................................................................................................................. 72
B.5 DF.ESIGN............................................................................................................... 73
B.6 DF.CIA.ESIGN ....................................................................................................... 74
Annex C (normative) Struktur und Inhalt der QES-Zertifikate ........................76
C.1 Zertifikat des öffentlichen Schlüssels für elektronische Signaturen (X.509v3
QES-Zertifikat) ............................................................................................................. 76
C.1.1 Allgemeine Aspekte ......................................................................................... 76
C.1.2 Zertifikatsstruktur ............................................................................................. 76
C.2 ToBeSignedCertificate ......................................................................................... 77
C.2.1 Generelle Struktur............................................................................................ 77
C.2.2 Version............................................................................................................. 77
C.2.3 Seriennummer ................................................................................................. 78
C.2.4 Signatur............................................................................................................ 78
C.2.5 Herausgeber .................................................................................................... 78
C.2.5.1 Country name ............................................................................................... 79
C.2.5.2 Organization name........................................................................................ 80
C.2.6 Validity ............................................................................................................. 80
C.2.7 Subject ............................................................................................................. 81
Version: 2.1.0
Seite 7 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
C.2.7.1 Country name............................................................................................ 81
C.2.7.2 State or province ....................................................................................... 81
C.2.7.3 Common name ......................................................................................... 81
C.2.7.4 Serial number .......................................................................................... 82
C.2.8 Subject public key info ..................................................................................... 82
C.2.9 Extensions ....................................................................................................... 84
C.2.9.1 Basic Constraints ...................................................................................... 85
C.2.9.2 Key usage (Schlüsselnutzung) .............................................................. 86
C.2.9.3 Certificate Policies .................................................................................. 86
C.2.9.4 Subject Alternative Name ....................................................................... 87
C.2.9.5 Subject Directory Attributes................................................................... 88
Standard Attributes ............................................................................................. 88
Title Attribute........................................................................................................ 88
C.2.9.6 Authority Key Identifier........................................................................... 89
C.2.9.7 Subject Key Identifier.............................................................................. 90
C.2.9.8 Authority Information Access ................................................................ 90
C.2.9.9 Validity Model .......................................................................................... 91
C.2.9.10 Qualified Certificate Statements .......................................................... 91
C.2.9.11 CRL Distribution Points........................................................................ 93
C.2.9.12 Professional Admission ....................................................................... 94
C.2.9.13 Restriction.............................................................................................. 98
C.2.9.14 Additional Information .......................................................................... 98
C.3 Signature algorithm.............................................................................................. 99
C.4 Signature ............................................................................................................... 99
C.5 QES-Zertifikat in Tabellenform und mit kompletter Syntax.............................. 99
C.6 Object Identifier, die in dieser Spezifikation verwendet werden.................... 107
C.7 Attributszertifikat für elektronische Signaturen (X.509v3 Zertifikat) ............. 108
C.7.1 Attributszertifikat für Qualifikationen .............................................................. 110
C.7.2 Attributs-Zertifikate für Autorisierungen ......................................................... 110
C. 8 Certification Authorities für X.509 Zertifikate ................................................. 111
Anhang D (normativ) Zertifikate für Authentifizierung und Verschlüsselung
...........................................................................................................................113
D.1 Struktur und Inhalt ............................................................................................. 113
D.2 Kodierung............................................................................................................ 113
Anhang E (normative) Algorithmen und Input-Formate für Sicherheits
Operationen ......................................................................................................115
E.1 RSA-DSI-Formate................................................................................................ 115
E.1.1 DSI gemäß ISO/IEC 9796-2 mit Zufallszahl................................................... 115
E.1.2 DSI gemäß PKCS #1 ..................................................................................... 115
E.1.3 Algorithm Identifier für PSO: HASH und PSO: COMPUTE DS...................... 116
Version: 2.1.0
Seite 8 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
E.2 Algorithm Identifier für INTERNAL AUTHENTICATE....................................... 116
Anhang F (normative) Issuer Identifier und Certificate Holder Authorizations
...........................................................................................................................118
F.1 Issuer Identifier ................................................................................................... 118
F.2 Profile Identifier................................................................................................... 119
Anhang G (normative) Inhalt der EFs für die Personalisierung ..................121
G.1 EF.ATR ................................................................................................................ 121
G.2 EF.DIR.................................................................................................................. 121
G.3 EF.GDO................................................................................................................ 121
G.4 EF.CVC.CA_HPC.CS und EF.CVC.HPC.AUT.................................................... 122
G.5 EF.C.HP.QES, EF.C.HP.AUT and EF.C.HP.ENC............................................... 122
G.6 EF.CIAInfo ........................................................................................................... 122
G.7 EF.OD .................................................................................................................. 122
G.8 EF.AOD................................................................................................................ 122
G.9 EF.PrKD............................................................................................................... 122
G.10 EF.CD................................................................................................................. 122
Anhang H (informativ) Cryptographic Information Objects..........................123
H.1 EF.CIAInfo ....................................................................................................... 123
H.1.1 ASN.1 Notation der ASN.1-Werte.................................................................. 123
H.1.2 Beschreibung der ASN.1 tags, lengths und values........................................ 123
H.1.3 Hexadezimale DER-Kodierung ...................................................................... 123
H.2 EF.OD .............................................................................................................. 124
H.2.1 Notation der ASN.1-Werte ............................................................................. 124
H.3 EF.AOD............................................................................................................ 125
H.4 EF.PrKD........................................................................................................... 128
H.5 EF.CD............................................................................................................... 132
Version: 2.1.0
Seite 9 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
Anhang I ............................................................................................................136
I.1 - Abkürzungen ...................................................................................................... 136
I.2 - Glossar................................................................................................................ 141
I.3 - Referenzierte Dokumente.................................................................................. 141
Seite 10 von 144
Version: 2.1.0
Stand: 28.5.2006
Heilberufs-Ausweis
und
1 Erläuterungen zum Inhalt der Dokumente
Die Dokumentation für den Heilberufsausweis (HBA) und die Security Module Card (SMC)
besteht aus drei Teilen.
1.1 Technische Spezifikationen des HBA
•
Heilberufsausweis und SMC
Teil 1: Kommandos, Algorithmen und Funktionen der BetriebssystemPlattform
Im Teil 1 werden die Basiskommandos, die Grundfunktionen des Betriebssystems
sowie die grundlegenden Sicherheitsfunktionen und -algorithmen (hard facts) detailliert beschrieben.
Diese Spezifikation ist Grundlage der Entwicklung der Kommandostrukturen und –
funktionen für HBA- und SMC-konforme Chipkartenbetriebssysteme; sie ist somit
die Grundarchitektur für die ROM-Maske des Halbleiters.
•
Teil 2: HBA: Anwendungen und Funktionen
Im Teil 2 werden die anwendungsspezifischen Strukturen des HBA beschrieben.
Dieser Teil enthält die Spezifikationen für die Dateistrukturen und die zugehörigen
Datenelemente,, die bei der Initialisierung und Personalisierung in den HBA geladen werden.
Insbesondere sind hierin die Dateistrukturen der Heilberufsanwendung HPA und
der Anwendungen „qualifizierte Signatur“ und „eSign Anwendung“ spezifiziert. Dazu gehören entsprechende statische Daten sowie die Strukturen und Datencontainer für Zertifikate und Schlüsselelemente.
•
Teil 3: SMC: Anwendungen und Funktionen
Im Teil 3 werden die anwendungsspezifischen Strukturen der SMC beschrieben.
Dabei werden zwei Typen von SMCs unterschieden: SMC-A für die Nutzung innerhalb einer Institution, Typ B zusätzlich zur Authentifizierung einer Institution gegenüber der Gesundheits-Telematik-Infrastruktur. Dieser dritte Teil enthält die
Spezifikationen für die Dateistrukturen und die zugehörigen Datenelemente, die
bei der Initialisierung (SMC-A und SMC-B) und Individualisierung (SMC-B) geladen werden.
Seite 11 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
2 Einführung
2.1 Zielsetzung und Einordnung des Dokumentes
Dieser Teil der Spezifikation beschreibt die Karten-Schnittstelle zu:
dem Heilberufsausweis (HBA) für Angehörige approbierter Heilberufe
und Authentifizierungsverfahren zwischen HBA und elektronischer Gesundheitskarte (eGK),
bei denen die Authentizität der eGK geprüft und Zugriffsrechte zugewiesen werden.
Die Spezifikation ist so aufgebaut, dass sie an die Anforderungen anderer Heilberufe angepasst werden kann.
Die Spezifikation berücksichtigt dabei:
• das deutsche Signaturgesetz und die zugehörende Signaturverordnung (SiG und
SigV)
• die DIN-Spezifikation für Chipkarten mit digitaler Signatur
• die eSIGN-Spezifikation für elektronische Signaturen
• die zugehörenden ISO-Standards (speziell ISO/IEC 7816, Teile 1-4, 6, 8, 9 und
15)
• Andere Quellen (z.B. Anforderungen der Trust-Center)
Ein HBA ist mindestens 3 Jahre gültig. Ein Heilberufler kann mehr als einen HBA besitzen.
2.2 Zielgruppe
Das Dokument richtet sich an Kartenhersteller.
2.3 Geltungsbereich
Der Inhalt des Dokumentes ist verbindlich für die Erstellung von Heilberufsausweisen und
Security Module Cards.
Seite 12 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
2.4 Arbeitsgrundlagen
Die Ausarbeitung steht in engem Zusammenhang mit den weiteren Spezifikationen für Heilberufsausweis (HBA) und SMC [HBA-T1] und [HBA-T3] und mit den Spezifikationen der elektronischen Gesundheitskarte [eGK-P1] und [eGK-P2]
2.5 Abgrenzung des Dokumentes
Dieses Dokument beschreibt die anwendungsbezogenen Ausprägungen und Dateninhalte,
die zur Herstellung und zum Betrieb eines Heilberufsausweises (HBA) verwendet werden.
Die dafür notwendigen technischen Eigenschaften des Chipkörpers werden in Teil 1 "Kommandos, Algorithmen und Funktionen der Betriebssystem-Plattform" verbindlich festgelegt.
2.6 Notationen
Für Schlüssel und Zertifikate wird die folgende vereinfachte Backus-Naur-Notation verwendet:
<object descriptor> ::= <key descriptor> | <certificate descriptor>
<key descriptor>::= <key>.<keyholder>.<key usage> | <SMkey>
<key>::= <private key> | <public key> | <secret key> | <individual key>
<private key>::= PrK (asym.)
<public key>::= PuK (asym.)
<secret key>::= SK (sym., not used)
<individual key>::= IK (sym., not used)
<keyholder>::= <health professional> | <card holder> | <certification authority> | <health professional card> | <electronic health card> | <security module card> | <server>
<health professional> ::= HP
<card holder> ::= CH
<certification authority>::= RCA | CA | CA_NN
<health professional card> ::= HPC
<electronic health card> ::= eGK (elektronische GesundheitsKarte)
<security module card> ::= SMC
Seite 13 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
<server> ::= S
<key usage>::= <qualified electronic signature> | <encipherment> | <authentication> | <certsign>
<qualified electronic signature>::= QES
<encipherment>::= ENC
<authentication>::= AUT
<certsign>::= CS
<SMkey> ::= SMK.ENC | SMK.MAC
<certificate descriptor>::=
<certificate>.<certificate holder>.<certificate usage>
<certificate>::= <X.509v3 certificate> | <card verifiable certificate>
<X.509v3 certificate>::= C
<card verifiable certificate>:: CVC
<certificate holder>::=
<health professional> | <certification authority> | <health professional card> | <security module card> | <server>
<certificate usage>::= <qualified electronic signature> | <encipherment> | <authentication> |
<certsign>
<qualified electronic signature>::= QES | QES-ACx
<encipherment>::= ENC
<authentication>::= AUT
<certsign>::= CS
Für aufeinanderfolgende Datenelemente wird die folgende Notation verwendet
|| = Konkatenation von Datenelementen
X.509v3-Zertifikate werden in diesem Dokument ohne Versionsnummer dargestellt.
Seite 14 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Hexadezimalzahlen werden mit Hochkomma dargestellt, z. B. '30'.
Seite 15 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
3 Technische Eigenschaften, Answer-to-Reset (ATR)
und Übertragungsprotokolle
3.1 Technische Eigenschaften
HBAs sind kontaktbehaftete Smartcards, die PK-Algorithmen ausführen können. Die physikalischen Eigenschaften müssen mit ISO/IEC 7816-1 und den zugehörenden Standards übereinstimmen.
Die Abmessungen und die Anordnung der Kontakte mit ISO/IEC 7816-2 übereinstimmen.
Ein HBA ist eine Chipkarte in Normalgröße (ID-1-Karte), die SMC ist normalerweise eine
Plug-In-Karte (ID-000).
Die Beschreibung der optischen Gestaltung erfolgt nicht in diesem Dokument.
Die Größe des EEPROM muss die Installation aller Anwendungen und der in diesem Dokument beschriebenen zugehörenden Daten zulassen.
3.1.1 Answer-to-Reset
Die Kodierung des ATR wird in Anhang A beschrieben.
3.1.2 Übertragungs-Protokolle
Das zu unterstützende Übertragungsprotokoll ist T = 1 (weitere Einzelheiten werden in Anhang A beschrieben).
Seite 16 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
4
Der Heilberufsausweis
4.1 Allgemeine Struktur
Der HBA enthält:
• einige EFs für allgemeine Datenobjekte in der MF-Ebene, CV-Zertifikate und globale Schlüssel für Authentifizierungsverfahren ( mit denen Zugriffsrechte auf die
eGK zugewiesen werden und die Authentizität der eGK überprüft werden kann)
• die Heilberufs-Anwendung (HPA) zur Bereitstellung von Datenelementen, die auf
den Heilberufler bezogen sind
• Signaturen
• die eSIGN-Anwendung für
- Client/Server-Authentifizierung
- Dokumenten-Ver- und Entschlüsselung
• Die Anwendung mit Informationen zu den verwendeten kryptografischen Verfahren (CIA), die sich gemäß [CWA 14890-1] auf die eSIGN bezieht.
Die allgemeine Struktur des HBA wird in Abbildung 1 dargestellt.
Seite 17 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
MF
EF.ARR**
DF.HPA
DF.ESIGN
DF.QES
EF.ATR
DF.CIA.ESIGN
EF.DIR
EF.GDO
EF.CVC.CA_HPC.CS
EF.CVC.HPC.AUT
EF.PIN*
- PIN.CH
EF.PrK*
- PrK.HPC.AUT
EF.PuK*
- PuK.RCA.CS
- PuK.CAMS_HPC.AUT
* diese Datei ist COS-spezifisch
** diese Datei muss – falls
vorhanden – gemäß
ISO/IEC 7816-4 genutzt werden
Die CA_SMC kann mit der
CA_HPC identisch sein
Abbildung 1 –Dateistruktur des HBA
Anmerkung:
Im Moment wird kein DF.CIA.QES benötigt.
4.2 Elementary Files auf der MF-Ebene
4.2.1 EF.ARR
EF.ARR enthält die Zugriffsregeln für die MF-Ebene.
4.2.2 EF.ATR
Die transparente Datei EF.ATR enthält ein spezielles Datenobjekt zur Anzeige der I/OPuffer-Größen und das DO 'Pre-issuing Daten' das für CAMS-Dienste benötigt wird. Der Inhalt von EF-ATR ist in Tabelle G.1 spezifiziert.
Seite 18 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
4.2.3 EF.DIR
EF.DIR enthält die Anwendungs-Templates für DF.HPA, DF.QES, DF.ESIGN und
DF.CIA.ESIGN, wie sie in ISO/IEC 7816-4 beschrieben sind. EF.DIR erlaubt die Hinzufügung
von AIDs zukünftiger (heruntergeladener) Anwendungen. Der Inhalt von EF.DIR ist in Tabelle G.1 spezifiziert.
4.2.4 EF.GDO
EF.GDO enthält das DO ICC-Serien-Nummer (ICCSN, Tag ‘5A’, siehe Abbildung 2) gemäß
[Resolution190].
MII = Major Industry
Identifier
TICCSN
‘5A‘
ICCSN
L
’0A‘
20 Zeichen (10 Byte)
EN 1867
MII
Country Issuer
Code Identifier
(´80´) (´276´) (5 BCD)
Serial
Number (SN)
(10 BCD)
ISO 3166
Issuer Id.
Number (IIN)
ICC Serial Number
gemäß EU Resolution 190
Abbildung 2 – ICC-Seriennummer des HBA
Die "Issuer Identification Number" (eindeutige Identifikationsnummer des Kartenherausgebers), die für den HBA genutzt wird, wird in Anhang F beschrieben.
In dieser Spezifikation wird die ICCSN für
• die Karten-Identifikation, z.B. durch ein CAMS
• und zum Referenzieren der Schlüssel in CVCs
genutzt
Der Kartenherausgeber muss sicherstellen, dass die Seriennummer (SN) eineindeutig ist
(besonders, wenn verschiedene Kartenhersteller beteiligt sind).
Seite 19 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
4.2.5 EF.CVC.CA_HPC.CS
EF.CVC.CA_HPC.CS enthält das von der Karte prüfbare Zertifikat des Zertifikatsherausgebers (Certificate Service Provider), das von der Wurzel-CA (Root CA) des Gesundheitswesens für eine CA_NN_HPC (NN z.B. eine CA für Ärzte oder Apotheker) erstellt wird. Struktur
und Inhalt eines CVC sind in [HBA-T1] beschrieben.
4.2.6 EF.CVC.HPC.AUT
EF.CVC.HPC.AUT enthält das von der Karte prüfbare Zertifikat des HBA für eine Card-toCard Authentifizierung zwischen HBA und eGK oder HBA und SMC. Struktur und Inhalt eines CVC sind in [HBA-T1] beschrieben.
4.2.7 EF.PIN
EF.PIN enthält die globale PIN des Karteninhabers (PIN.CH). Die PIN besteht aus mindestens 5 Ziffern und ist änderbar. Der Wiederholungszähler hat den Anfangswert 3.
Die Nutzung eines 8-stelligen Rücksetzcodes wird durch einen Nutzungszähler beschränkt,
dessen Anfangswert auf 10 gesetzt ist. Der Nutzungszähler wird bei jeder Nutzung heruntergezählt, unabhängig davon, ob der eingegebene Wert richtig oder falsch ist. Die Eingabe des
korrekten Wertes setzt den Wiederholungszähler von PIN.CH auf den Anfangswert (3) zurück.
Die folgende Tabelle zeigt die PIN-Eigenschaften:
Tabelle 1 – PIN-Eigenschaften
PINName
PIN.CH
PIN-Länge PIN Ref. Anfangswert des Rücksetz-Code Anfangswert des NutWiederholungs- (PUK)
zungszählers (PUK)
zählers
5 - 8 Zif‘01’
3
8 Ziffern
10
fern
4.2.8 EF.PrK
EF.PrK enthält
• den globalen privaten Schlüssel PrK.HPC.AUT für C2C-Authentifizierungen
(HBA/eGK und HBA/SMC).
Tabelle 2 zeigt die Eigenschaften des Schlüssels.
Tabelle 2 –Eigenschaften des Schlüssels PrK.HPC.AUT
Seite 20 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Schlüssel- Name
SchlüsselLänge
KeyID
SE #
Zugriffsbedingungen
PrK.HPC.AUT
für HBA/eGK-Authentifizierung ohne
TC und HBA-Authentifizierung zur
Autorisierung einer SMC)
1024 bit
(RSA)
‘10’
siehe Anmerkung 1
'01'
PIN.CH
PrK.HPC.AUT
für HBA/SMC-Authentifizierung
mit TC)
1024 bit
(RSA)
‘11’
siehe Anmerkung 1
'02'
immer
siehe Anmerkung 2
Anmerkungen
(1) In Karten, die erlauben, dass ein Schlüssel mehr als eine KID haben darf (multi-KIDreferencing), ist der Schlüssel nur einmal vorhanden. In anderen Karten kann der Schlüssel
zweimal gespeichert werden. Die Nutzung des Schlüssels ist an die KID gebunden. Deshalb
ist der AlgID implizit gesetzt.
(2) SE#2 kann nicht für die HBA/eGK-Kommunikation missbraucht werden, da SE#2 SM verwendet. Da der HBA die Generierung gesicherter Kommandos, die an die eGK geschickt werden könnten, nicht zulässt, ist kein Zugriff auf sensible Daten in der eGK möglich. Der Zugriff
auf eine eGK ist nur im SE#1 möglich, wobei der Heilberufler vorher seine PIN.CH erfolgreich
eingegeben haben muss.
Der zu PrK.HPC.AUT gehörende öffentliche Schlüssel ist in CVC.HPC.AUT gespeichert.
4.2.9 EF.PuK
EF.PuK enthält
• den öffentlichen Schlüssel PuK.RCA.CS der Wurzel-CA für das Gesundheitswesen für die Prüfung von CVCs, die von dieser herausgegeben werden.
• den öffentlichen Schlüssel PuK.CAMS_HPC.AUT, mit dem eine Authentifizierung
zwischen HBA und CAMS mit der Einrichtung eines TC durchgeführt wird.
•
Der "key identifier" des PuK.RCA.CS kann aus dem HBA gemäß Abbildung 3 ausgelesen
werden. Tabelle 3 zeigt den "key identifier" des PuK.CAMS_HPC.AUT.
Tabelle 3 –Schlüssel-Eigenschaften des PuK.CAMS_HPC.AUT
Schlüssel-Name
PuK.CAMS_HPC.AUT
Schlüssel-Länge
1024 bit
(RSA)
KeyID
‘13’
AlgID
‘1F’
PuK.CAMS_HPC.AUT ist ein globaler Schlüssel und hat immer dieselbe Schlüssel-Referenz
an der Schnittstelle zum HBA; der Schlüsselwert selbst kann allerdings von dem Ausgabejahr des HBA abhängen, siehe Kapitel 11.2.
Seite 21 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
4.3 Sicherheitsumgebungen (SEs) auf MF-Ebene
Auf MF-Ebene werden die folgenden Sicherheitslevel (SE) verwendet:
• SE#1 ist das generelle SE auf der MF-Ebene und wird in allen Fällen mit Ausnahme des Falles genutzt, der SE#2 zugewiesen ist.
• SE#2 ist mit der Nutzung von PrK.HPC.AUT zur Einrichtung eines Trusted Channel zwischen HBA und eGK verbunden.
4.4 Öffnen des HBA
4.4.1 Kommando-Sequenz nach Auslesen des ATR
Die Kommandosequenz, die nach dem Auslesen des ATR gesendet werden muss, hängt
von der äußeren Umgebung und ihrem Wissen über die jeweilige Karte ab. Im Prinzip können die folgenden Umgebungen unterschieden werden:
• Zugelassene Umgebung des Gesundheitswesens
• sonstige Umgebungen, die die Karte nicht kennen
In einer Umgebung, in der alles bekannt ist, ist es nicht unbedingt notwendig, die ICCSN zu
lesen und über sie z.B. ein bestimmtes Kartenprofil zu identifizieren, das die zum HBA gehörenden CV-Zertifikate enthält. In anderen Umgebungen, in der z.B. der HBA nicht bekannt
ist, kann es notwendig sein, zuerst das EF.DIR, das EF.GDO und möglicherweise auch die
kryptografischen Informations-Objekte in den EFs von DF.CIA.ESIGN zu lesen.
Im Folgenden wird das Lesen von EF.DIR und EF.GDO beschrieben.
4.4.2 Lesen von EF.ATR und EF.GDO
Zum Lesen von EF.ATR und EF.GDO wird das ISO/IEC 78216-4-Kommando READ BINARY
verwendet.
Tabelle 4 - Kommando READ BINARY mit SFID
CLA
INS
P1
P2
Lc
Datenfeld
Le
wie in ISO/IEC 7816-4 definiert
‘B0’ = READ BINARY
‘xx’ = b8-b6: 100
b5-b1: 11101 SFID von EF.ATR: 29
b5-b1: 00010 SFID von EF.GDO: 2
‘00’ = Offset
nicht vorhanden
nicht vorhanden t
‘00’ = Lesen bis zum Ende des Files
Seite 22 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Tabelle 5 - READ BINARY Antwort
Datenfeld
SW1-SW2
Daten
‘9000’ oder spezifische Status Bytes, siehe [HBA-T1]
4.4.3 Lesen von EF.DIR
Zum Lesen von EF.DIR wird das ISO/IEC-4-Kommando READ RECORD genutzt.
Tabelle 6 – Kommando READ RECORD
CLA
INS
P1
P2
Lc
Datenfeld
Le
Wie in ISO/IEC 7816-4 definiert
‘B2’ = READ RECORD
‘xx’ = Record Nr.
‘F4’ = b8-b4: 11110 SFID von EF.DIR: 30
b3-b1: 100 Read Record P1
nicht vorhanden
nicht vorhanden
‘00’ = kompletter Record
Anmerkung:
In nachfolgenden Kommandos kann der Short EFID zu Null gesetzt werden (P2 = '04').
Tabelle 7 – Kommando READ RECORD
Datenfeld
SW1-SW2
Record
4.4.4 Lesen der CV-Zertifikate des HBA
Zum Lesen der zu einem HBA gehörenden Zertifikate CVC.CA_HPC.CS und CVC.HPC.AUT
wird das Kommando READ BINARY benutzt. Diese Zertifikate sollten im PC des Heilberuflers gespeichert werden, damit sie nur einmal gelesen werden müssen. Dadurch kann bei
weiterer Nutzung Zeit gespart werden.
Tabelle 8 – Kommando READ BINARY zum Lesen eines CV Zertifikates
CLA
INS
P1
‘8x’ = b8-b6:100
b5-b1: 00011 SFID von EF.CVC.HPC.AUT: 3
b5-b1: 00100 SFID von EF.CVC.CA_HPC.CS: 4
Seite 23 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
P2
Lc
Datenfeld
Le
‘00’ = Offset
nicht vorhanden
nicht vorhanden
‘00’ = Lesen bis zum Ende des Files (max 256 B)
Datenfeld
SW1-SW2
CV Zertifikat
4.4.5 SE Auswahl auf MF-Ebene
Falls die Nutzung von SE#2 gefordert wird (siehe Kapitel 10.2), muss das ISO/IEC 7816-4Kommando MSE an den HBA gesendet werden.
Tabelle 10 – Kommando MSE zum Auswählen von SE # 2
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘22’ = MANAGE SECURITY ENVIRONMENT
‘F3’ = RESTORE
‘02’ = SE # 2
nicht vorhanden
nicht vorhanden
nicht vorhanden
Tabelle 11 - MSE Antwort
Datenfeld
SW1-SW2
nicht vorhanden
4.5 PIN Management
4.5.1 PIN Prüfung
Für die PIN-Prüfung wird das ISO/IEC 7816-4 Kommando VERIFY genutzt.
Tabelle 12 – Kommando VERIFY für die PIN Prüfung
CLA
INS
P1
P2
Lc
Datenfeld
‘20’ = VERIFY
‘00’
‘01’ = PIN.CH Referenz
‘08’ = Länge des zugehörenden Datenfeldes
PIN (PIN Format: siehe [HBA-T1])
Seite 24 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Le
nicht vorhanden
Tabelle 13 - VERIFY Antwort
Datenfeld
SW1-SW2
nicht vorhanden
Falls die eingegebene PIN falsch ist und zusätzliche Versuche erlaubt sind, muss die Zahl
der noch möglichen Versuche in den Status Codes, die in [HBA-T1] spezifiziert sind, angezeigt werden
4.5.2 Änderung der PIN
Zur Änderung der PIN kann das ISO/IEC 7816-4-Kommando CHANGE.RD zu jeder Zeit vom
Heilberufler genutzt werden. Ist das Kommando erfolgreich ausgeführt, soll der Sicherheitsstatus "PIN mit Referenz '01' erfolgreich eingegeben" gesetzt werden.
Tabelle 14 – Kommando CHANGE RD
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘24’ = CHANGE REFERENCE DATEN
‘00’ = Ändere Referenz-Daten
PIN_alt || PIN_neu (PIN Format: siehe [HBA-T1])
nicht vorhanden
Anmerkung:
Ob ein Sicherheitszustand gesetzt wird, wenn die Transport-PIN eingegeben wird, hängt von den
Vorgaben für die Handhabung der Transport-PIN im jeweiligen HBA ab.
Tabelle 15 - CHANGE RD Antwort
Datenfeld
SW1-SW2
nicht vorhanden
4.5.3 Zurücksetzen des Fehlbedienungszählers und Setzen einer neuen PIN
Zum Zurücksetzen des Fehlbedienungszählers auf seinen Ausgangswert und – falls so realisiert – zum Setzen einer neuen PIN.CH wird das Kommando RESET RETRY COUNTER
verwendet.
Der Sicherheitsstatus wird durch dieses Kommando weder gesetzt noch beeinflusst. Deshalb
wird zusätzlich ein VERIFY-Kommando benötigt.
Seite 25 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Tabelle 16 – Kommando RESET RC zum Zurücksetzen des Fehlbedienungszählers und möglicherweise zum Setzen einer neuen PIN
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘2C’ = RESET RETRY COUNTER
‘00’ oder ‘01’
‘10’ oder ‘08’ = Länge des zugehörenden Datenfeld
- Falls P1 = ‘00’ und P2 = ’01’: Rücksetz-Code (8 Bytes) gefolgt von einer
neuen PIN (8 Bytes)
- wenn P1 = ‘01’: Rücksetz-Code (8 Bytes)
(RC und PIN Format: siehe [HBA-T1])
nicht vorhanden
Tabelle 17 - RESET RC-Antwort
Datenfeld
SW1-SW2
nicht vorhanden
4.6 HBA/eGK-Authentifizierung
4.6.1 Allgemeines
Für die HBA/eGK-Authentifizierung sind zwei Schritte notwendig:
- 1. die eGK muss ihre Authentizität nachweisen
- 2. der Heilberufler muss seine Zugriffsberechtigung nachweisen
Hierfür muss eine CV-basierte Authentifizierung stattfinden, nach der in der eGK der zugehörige Sicherheitsstatus gesetzt ist, z.B. "Autorisierung des Zertifikatsinhabers (siehe Anhang
F) wurde erfolgreich übermittelt".
Während des Authentifizierungsprozesses werden keine SM-Schlüssel erzeugt, da der HBA
in der folgenden Kommunikation mit der eGK (Lesen und Schreiben von Daten) nicht beteiligt ist.
Der HBA muss sicherstellen, dass der Authentifizierungsprozess zwischen HBA und eGK
nur nach erfolgreicher Eingabe der PIN.CH durch den Heilberufler möglich ist.
4.6.2 Instanzen des CVC Schlüssel-Managements
Das allgemeine Modell für CV-Zertifikate und Instanzen des Schlüssel-Managements für
CVC-Schlüssel zeigt Abbildung 3. Die Abbildung zeigt im besonderen, wo die "Key Identifier"
lokalisiert sind, die für die CVC-Prüfung und den nachfolgenden Authentifizierungsprozess
benötigt werden.
Seite 26 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Wurzel-CA Gesundheitswesen
PuK.RCA.CS
PrK.RCA.CS
CVC.
CA_NN_
eGK.CS
CAs
Krankenversicherungen
CVC.
CA_NN_
HPC.CS
CAs
Heilberufler
CVC.
eGK.
AUT
CVC.
HPC.
AUT
Schlüsselreferenzen, die für das CVC
CVC-basierte
Authentisierungsverfahren in der eGK
gesetzt werden müssen
PuK.RCA.CS ist in der eGK, HPC und SMC vorhanden.
Die Schlüsselreferenz von PuK.RCA.CS ist in den Dateien
EF.CVC.CA_eGK.CS, EF.CVC.CA_HPC.CS und EF.CVC.CA_SMC.CS
in dem Wertefeld des DO CAR (Tag ‘42‘, 8 Byte) zu finden und
ist zur Prüfung von CVC.CA_NN_HPC.CS bzw. CVC.CA_NN_SMC.CS
zu setzen.
Zur Prüfung von CVC.HPC.AUT bzw. CVC.SMC.AUT ist
die Schlüsselreferenz des PuK.CA_NN_HPC bzw. PuK.CA_NN_SMC
in der Form zu setzen, wie sie in CVC.CA_NN_HPC.CS bzw.
CVC.CA_NN_SMC.CS der eGK im Feld CHR Subject
(
Key Reference)
angezeigt wurde. Die Schlüsselreferenz hat daher 12 Byte und ist
eine Konkatenation von 4 Null-Byte und dem Wert von
DO CAR (tag ‘42‘, 8 Byte) in
EF.CVC.HPC.AUT bzw. EF.CVC.SMC.AUT.
Die Schlüsselreferenz von PuK.HPC.AUT bzw. PuK.SMC.AUT ist
eine Konkatenation von 2 Null-Byte und der ICCSN (10 Byte) der HPC
bzw. SMC und hat daher ebenfalls 12 Byte. Die ICCSN.HPC ist in
EF.GDO der HPC und ICCSN.SMC in EF.GDO der SMC zu finden.
AUT
CA
CS
CVC
PrK
PuK
= Authentifizierung
= Certification Authority
= Certificate Signing
= Card Verifiable Certificate
= Privater Schlüssel
= Öffentlicher Schlüssell
CVC in HPC
(von der eGK
zu prüfen)
CVC in eGK
(von der HPC bzw.
SMC zu prüfen)
Abbildung 3 – Instanzen des CVC Schlüssel-Managements, CV Zertifikate und Schlüsselauswahl in einem HBA
Falls eine eGK mit einem neuen öffentlichen Schlüssel der Wurzelinstanz eingesetzt wird,
werden Cross-Zertifikate benötigt, die mit dem im HBA vorhandenen öffentlichen Schlüssel
der Wurzelinstanz geprüft werden können (ein Cross-Zertifikat enthält den neuen
PuK.RCA.CS und kann mit dem PuK.RCA.CS geprüft werden, der im HBA vorhanden ist)
Cross-Zertifikate werden von der Wurzel-CA bereitgestellt und können z.B. in einem Konnektor eines PVS/AVS/KIS gespeichert und von dort gelesen werden.
Da die Nutzung von CV-Zertifikaten auch über Grenzen hinweg möglich ist, können CrossZertifikate auch genutzt werden, um bei Bedarf später die öffentlichen Schlüssel der Wurzelinstanzen anderer Länder zu importieren. Mit diesen importierten Schlüsseln kann die Prüfung der Authentizität einer intelligenten Europäischen Krankenversicherungskarte EHIC
ohne irgendeine Änderung oder Erweiterung des HBA erfolgen (Die Prüfung der Authentizität
einer elektronischen EHIC könnte in naher Zukunft notwendig werden, da eine EHIC, die nur
aus auf die eGK gedruckten Daten besteht, leicht fälschbar ist und damit den Krankenversicherungen finanzielle Verluste zufügen kann).
Seite 27 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
4.6.3 Prüfung der CV Zertifikate der eGK
Zunächst muss der öffentliche Schlüssel der gemeinsamen Wurzel-CA mit dem Kommando
MSE ausgewählt werden. Abbildung 3 zeigt, wie die Schlüssel-Referenz durch die Software
(z.B. des PVS) gefunden werden kann.
Tabelle 18 – Kommando MSE zur Auswahl des öffentlichen Schlüssels der Wurzel
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘81’ = SET für die Prüfung
‘B6’ = DST
‘0A’= Länge des zugehörenden Datenfeldes
‘83 08 ...’ = DO für KeyRef von PuK.RCA.CS (siehe Abbildung 3 bzgl.
der Auswahl der KeyRef)
nicht vorhanden
Datenfeld
SW1-SW2
nicht vorhanden
Nachdem der öffentliche Schlüssel PuK der Wurzel ausgewählt worden ist, wird das Kommando PSO:VERIFY CERTIFICATE an den HBA gesendet. Das Datenfeld enthält die Signatur (und deckt damit den ersten Teil des Root-Zertifikats ab, dessen Zahlenwert nach der
Berechnung der Signatur wiederhergestellt wird) und den PK-Remainder (den restlichen Teil
des CV-Zertifikats, siehe [HBA-T1])
Tabelle 20 – Kommando PSO: VERIFY CERTIFICATE zur Prüfung des ersten Teils der eGK CVC
CLA
INS
P1
P2
Lc
Datenfeld
Le
’2A’ = PERFORM SECURITY OPERATION: VERIFY CERTIFICATE
’00’
’AE’ = Zertifikat im Datenfeld, der signierte Signatur-Input besteht aus
nicht BER-TLV-kodierten Daten, d.h., der Zertifikatsinhalt ist eine Konkatenation von DEs
’xx’ = Länge des zugehörenden Datenfeldes
‘5F37’-L-SIG.RCA || ‘5F38’-L-PK_remainder
nicht vorhanden
Tabelle 21 - PSO: VERIFY CERTIFICATE Antwort
Datenfeld
SW1-SW2
nicht vorhanden
Seite 28 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Jetzt ist der öffentliche Schlüssel zur Prüfung des CVC.eGK.AUT im HBA gespeichert und
kann ausgewählt werden.
Tabelle 22 – Kommando MSE zur Auswahl des PuK von CA_NN_eGK
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘81’ = SET für die Prüfung
‘B6’ = DST
‘0E’= Länge des zugehörenden Datenfeldes
‘83 0C ...’ = DO für KeyRef von PuK.CA_NN_eGK.CS (siehe Abbildung
3 bzgl. der Auswahl der KeyRef)
nicht vorhanden
Datenfeld
SW1-SW2
nicht vorhanden
Anschließend kann das CVC.eGK.AUT geprüft werden.
Tabelle 24 – Kommando PSO: VERIFY CERTIFICATE zur Prüfung von CVC.eGK.AUT
LA
INS
P1
P2
Lc
Datenfeld
Le
’2A’ = PERFORM SECURITY OPERATION: VERIFY CERTIFICATE
’00’
’AE’ = Zertifikat im Datenfeld, der signierte Signatur-Input besteht aus
nicht BER-TLV-kodierten Daten, d.h., der Zertifikatsinhalt ist eine Konkatenation von DEs
‘5F37’-L-SIG.CA || ‘5F38’-L-PK_remainder
nicht vorhanden
Tabelle 25 - PSO: VERIFY CERTIFICATE Antwort
Datenfeld
SW1-SW2
nicht vorhanden
4.6.4 Durchführung des Authentifizierungs-Prozesses
Bevor der Authentifizierungs-Prozess durchgeführt werden kann, muss die PIN.CH erfolgreich eingegeben werden.
In einem ersten Schritt werden die Schlüssel-Referenzen für PuK.eGK.AUT und
PrK.HPC.AUT gesetzt.
Seite 29 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Tabelle 26 – Kommando MSE zur Schlüsselauswahl
CLA
INS
P1
P2
Lc
Datenfeld
‘81’ = SET für externe Authentifizierung
‘A4’ = AT
‘83 0C xx ... xx || 84 01 10’ = DO für KeyRef von PuK.eGK.AUT (siehe
Abbildung 3 bzgl. der Auswahl der KeyRef)|| DO für KeyRef von
PrK.HPC.AUT
nicht vorhanden
Le
Anmerkung:
Die Schlüssel-Referenz hat eine Länge von 12 Bytes: '0000' (2 Bytes) || ICCSN.eGK (10 Bytes)
Datenfeld
SW1-SW2
nicht vorhanden
Danach wird vom HBA eine Zufallszahl angefordert.
Tabelle 28 – Kommando GET CHALLENGE
CLA
INS
P1, P2
Lc
Datenfeld
Le
‘84’ = GET CHALLENGE
‘0000’
nicht vorhanden
nicht vorhanden
‘08’
Tabelle 29 - GET CHALLENGE Antwort
Datenfeld
SW1-SW2
RND.HPC (8 Bytes)
Nach dem Kommando GET CHALLENGE folgt das Kommando EXTERNAL AUTHENTICATE, das die digitale Signatur der eGK an den HBA liefert. Um diese digitale Signatur zu erhalten, muss das Kommando INTERNAL AUTHENTICATE mit RND.HPC || ICCSN8.HPC im
Datenfeld (siehe [HBA-T1], Annex E.2) an die eGK gesendet werden. Der HBA muss die
Signatur der eGK prüfen.
Tabelle 30 – Kommando EXT. AUTHENTICATE zur Authentifizierung der eGK
CLA
Seite 30 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
INS
P1
P2
Lc
Datenfeld
Le
‘82’ = EXTERNAL AUTHENTICATE
‘00’
‘00’
‘xx’ = Länge des zugehörenden Datenfeldes
auf die Authentifizierung bezogene Daten, siehe [HBA-T1], Anhang E.2
nicht vorhanden
Tabelle 31 - EXT. AUTHENTICATE Antwort
Datenfeld
SW1-SW2
nicht vorhanden
Nachdem die eGK authentifiziert ist, muss der HBA seine Zugriffsrechte auf die eGK nachweisen. Die zuständige Software (z.B. des Konnektors) muss von der eGK vor der Sendung
weiterer Kommandos eine Zufallszahl abfordern.
Tabelle 32 – Kommando INT. AUTHENTICATE
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘88’ = INTERNAL AUTHENTICATE
‘00’
‘00’
auf die Authentifizierung bezogene Daten, siehe [HBA-T1], Annex E.2
‘00’ oder ‘xx’ = Länge der erwarteten Signatur
Tabelle 33 - INT. AUTHENTICATE Antwort
Datenfeld
SW1-SW2
Der Authentifizierungs-Token (Inhalt des Antwort-Datenfeldes) wird in der entsprechenden
eGK geprüft und setzt bei positivem Ergebnis in der eGK den Sicherheitsstatus " CHA mit
Profilkennung 'xx' erfolgreich präsentiert"
4.7 Autorisierung einer SMC zur Kommunikation mit einer eGK
Wie im [GMG] festgelegt, kann ein Heilberufler andere ausgewählte Personen autorisieren,
auf die geschützten Bereiche der eGK zuzugreifen. Dies wird durch die Nutzung einer SMC
erreicht. Die Nutzung des PrK.SMC.AUT für eine SMC/eGK-Authentifizierung setzt gemäß
den Zugriffsregeln von PrK.SMC.AUT die erfolgreiche Authentifizierung durch einen HBA
voraus (siehe [HBA-T3] für weitere Details).
In einem ersten Schritt muss der Schlüssel PrK.HPC.AUT ausgewählt werden.
Tabelle 34 – Kommando MSE
Seite 31 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘41’ = SET für interne Authentifizierung
‘A4’ = AT
‘84 01 10’ = DO für KeyID von PrK.HPC.AUT
nicht vorhanden
Datenfeld
SW1-SW2
nicht vorhanden
Danach wird das Kommando INTERNAL AUTHENTICATE an den HBA gesendet. Vorher
wird von der SMC noch eine Zufallszahl (RND.SMC) angefordert.
Tabelle 36 – Kommando INT. AUTHENTICATE zur Prüfung der Authentizität eines HBA zur Autorisierung einer SMC
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘00’
‘00’
Datenfeld
SW1-SW2
Die digitale Signatur, die der HBA für die Authentifizierung erzeugt hat, wird durch die SMC
geprüft. Ist die Prüfung erfolgreich, wird in der SMC der Sicherheitsstatus gesetzt, der die
Nutzung des privaten Schlüssels PrK.SMC.AUT zur Kommunikation mit einer eGK erlaubt.
Seite 32 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
5 Management von Kanälen
5.1 Allgemeine Aspekte
Die Unterstützung verschiedener logischer Kanäle durch einen HBA ist verbindlich vorgeschrieben, siehe [HBA-T1]. Wird der HBA in einer Umgebung eingesetzt, in der nur ein Kanal
genutzt wird, muss immer der Basis-Kanal mit der Nummer 0 zur Ausführung aller Kommandos verwendet werden.
Jeder Kanal hat seinen eigenen von den anderen unabhängigen Sicherheitsstatus, d.h., die
erfolgreiche Eingabe einer globalen PIN in einem Kanal setzt keinen Sicherheitsstatus in
irgendeinem anderen Kanal.
5.2 Öffnen eines logischen Kanals
Zum Öffnen eines logischen Kanals wird das ISO/IEC 7816-4 Kommando MANAGE CHANNEL mit der Funktion "öffnen" genutzt. Das Kommando wird immer im Kanal #0 gesendet.
Tabelle 38 – Kommando MANAGE CHANNEL zur Auswahl eines logischen Kanals
CLA
INS
P1-P2
Lc
‘70’ = MANAGE CHANNEL
‘0000’ = öffne einen logischen Kanal, die Kanal-Nr. steht im Datenfeld
der Antwort
nicht vorhanden
Datenfeld
Le
nicht vorhanden
‘01’
Tabelle 39 - MANAGE CHANNEL Antwort
Datenfeld
SW1-SW2
Nr. des logischen Kanals, zugewiesen durch den HBA (1 Byte)
nicht vorhanden, falls kein weiterer logischer Kanal verfügbar ist
‘9000’, falls eine Kanal-Nr. zugewiesen ist
‘6881’ kein weiterer logischer Kanal verfügbar
oder spezifische Status Bytes, siehe [HBA-T1]
Seite 33 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
5.3 Schließen eines logischen Kanals
Zum Schließen eines logischen Kanals wird das ISO/IEC 7816-4 Kommando MANAGE
CHANNEL mit der Funktion "schließen" verwendet.
Tabelle 40 – Kommando MANAGE CHANNEL zum Schließen eines logischen Kanals
CLA
INS
P1-P2
Lc
‘70’ = MANAGE CHANNEL
‘8000’ = Schließen eines logischen Kanals, Kanal-Nr. in CLA
nicht vorhanden
Datenfeld
Le
nicht vorhanden
nicht vorhanden
Tabelle 41 – MANAGE CHANNEL Antwort
Datenfeld
SW1-SW2
nicht vorhanden
Seite 34 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
6 Die Heilberufs-Anwendung HPA
6.1 File-Struktur und File-Inhalt
Abbildung 4 zeigt die File-Struktur des DF.HPA.
MF
DF.HPA
EF.ARR*
EF.HPD
* diese Datei soll – falls vorhanden –
gemäß ISO/IEC 7816-4 genutzt werden
Abbildung 4 – File-Struktur des DF.HPA
Schlüssel und CV-Zertifikate für die Authentifizierungsverfahren sind in der MF-Ebene gespeichert. Der HBA erlaubt das Anlegen weiterer Files, falls dafür in der Zukunft eine Notwendigkeit bestehen sollte (siehe Kapitel 12).
6.1.1 EF.ARR
EF.ARR enthält die Zugriffsbedingungen für DF.HPA.
6.1.2 EF.HPD
Das transparente File EF.HPD ist für die Speicherung von Daten vorgesehen, die sich auf
den jeweiligen Heilberufler beziehen, z.B. die Bestätigung der Teilnahme an Fortbildungsmaßnahmen. Das File kann immer gelesen werden, aber eine Aktualisierung ist nur nach
erfolgreicher Eingabe der PIN.CH möglich.
Seite 35 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
6.2 Sicherheitsumgebungen
Für DF.HPA wird nur das SE#1 verwendet.
6.3 Auswahl der Anwendung
Die Auswahl der Anwendung erfolgt mit dem ISO/IEC 7816-4-Kommando SELECT wie in
den folgenden zwei Tabellen angegeben.
Tabelle 42 – Kommando SELECT für DF.HPA
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘A4’ = SELECT
‘04’ = DF Auswahl mit AID
‘0C’ = kein FCI zurückzugeben
‘D276 00004002’ = AID von DF.HPA
nicht vorhanden
Anmerkung:
In der HPC-Version 1.0 war als AID für den HBA ‘D27600004001’ angegeben. Der RID
‘D276000040’ ist dem deutschen Gesundheitswesen zugewiesen.
Tabelle 43 - SELECT Antwort
Datenfeld
SW1-SW2
nicht vorhanden
6.4 Lesen und Aktualisieren des EF.HPD
Zum Lesen von EF.HPD wird das Kommando READ BINARY verwendet.
Tabelle 44 – Kommando READ BINARY zum Lesen von EF.HPD
CLA
INS
P1
P2
Lc
Datenfeld
Le
'81' = b8-b6:100
b5-b1: 00001 SFID von EF.HPD: 1
‘00’ = Offset
nicht vorhanden
nicht vorhanden
'08'
Seite 36 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Tabelle 45- READ BINARY Antwort
Datenfeld
SW1-SW2
Daten
Die Aktualisierung von EF.HPD ist mit dem Kommando UPDATE BINARY nach erfolgreicher
Eingabe von PIN.CH möglich.
Tabelle 46 – Kommando UPDATE BINARY zur Aktualisierung von EF.HPD
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘D6’ = UPDATE BINARY
'81' = b8-b6:100
b5-b1: 00001 SFID von EF.HPD: 1
‘00’ = Offset
Daten
nicht vorhanden
Tabelle 47 - UPDATE BINARY Antwort
Datenfeld
SW1-SW2
nicht vorhanden
Seite 37 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
7 Anwendung für die qualifizierte elektronische Signatur
(QES)
Abbildung 5 zeigt die prinzipielle File-Struktur der QES-Anwendung, die in Übereinstimmung
mit [DINSIG] definiert ist.
MF
DF.QES
EF.ARR**
EF.C.HP.QES
EF.PrK*
- PrK.HP.QES
EF.C.HP.QES-AC1
EF.PIN*
- PIN.QES
EF.C.HP.QES-AC2
EF.DM
EF.C.HP.QES-AC3
ARR
AC
C
DM
HP
QES
PrK
= Authentifizierung
= Attributszertifikat
= X.509-Zertifikat
= Display Message
= Heilberufler
= qual.elektr.Signaturg
= privater Schlüssel
Abbildung 5 – Prinzipielle Struktur der QES-Anwendung
In der QES-Anwendung sind EFs für das X.509-QES-Zertifikat und maximal drei Attributszertifikate angelegt. Zusätzlich gibt es ein EF für eine Display Message, die für die ferngesteuerte Nutzung eines HBA wichtig ist.
7.1.1 EF.ARR
Das EF.ARR enthält die Zugriffsbedingungen für DF.QES.
Seite 38 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
7.1.2 EF.PrK
Das EF.PrK enthält den privaten Schlüssel PrK.HP.QES zur Berechnung qualifizierter elektronischer Signaturen. Der Key Identifier und die Zugriffsbedingungen für diesen Schlüssel
werden in der folgenden Tabelle aufgeführt. Die PIN-Merkmale sind in Kapitel 7.1.3 beschrieben.
Tabelle 48 – Schlüssel-Eigenschaften
SchlüsselSchlüsselName
Länge
PrK.HP.QES [ALGCAT]
entsprechend
KeyID Zugriffsbedingungen
‘84’
- SE # 1: PIN.QES
- SE # 2: PIN.QES und
SM
Security Status EvaluationZähler des PrK.HP.QES
Eine unbeschränkte Zahl von
Signaturen ist nach einmaliger Eingabe der PIN.QES
möglich (der Wert ist Betriebssystem-spezifisch),
siehe Anmerkung
Anmerkung:
Falls dies von der BNA gefordert wird, muss ein konkreter Wert für den Security Status Evaluation-Zähler vorgegeben werden.
Die prinzipiell erlaubten Padding-Verfahren sind in Anhang E aufgeführt; für die QES darf
aber nur das im QES-Zertifikat angegebene Padding-Verfahren benutzt werden.
7.1.3 EF.PIN
EF.PIN enthält die DF-spezifische PIN.QES, die nur zum Schutz des privaten Schlüssels für
die elektronische Signatur des Heilberuflers (PrK.HP.QES) gemäß SigG/SigV verwendet
werden darf.
Die folgende Tabelle zeigt die PIN-Referenz, die in den Kommandos VERIFY, CHANGE RD
und RESET RC verwendet wird und die weiteren PIN-Attribute.
Tabelle 49 – PIN Eigenschaften
PIN-Name
PIN-Länge
PIN Ref.
PIN.QES
6 - 8 Ziffern
‘81’
Ausgangswert des Rücksetz-Code
Wiederholungszäh- (PUK)
lers
3
8 Ziffern
PUK Nutzungszähler
10
Die Initialisierung der PIN.QES, z.B. durch Nutzung einer Transport-PIN, ist betriebssystemabhängig und muss den Vorgaben der BNA entsprechen.
Seite 39 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
7.1.4 EF.DM
Das transparente File EF.DM enthält die Display Message, die dem Heilberufler anzeigt,
dass ein Trusted Channel erfolgreich aufgebaut wurde. Sie besteht aus 8 Bytes (ASCIIZeichen). Die Display Message kann vom Heilberufler nach erfolgreicher Eingabe seiner
PIN.CH geändert werden.
7.1.5 EF.C.HP.QES
Das transparente File EF.C.HP.QES enthält das X.509-Zertifikat mit dem öffentlichen
Schlüssel des Heilberuflers für eine qualifizierte elektronische Signatur gemäß SiG/SigV.
7.1.6 EF.C.HP.QES-AC1, -AC2 and -AC3
Die transparenten Files EF.C.HP.QES-AC1, -AC2 und -AC3 können X.509Attributszertifikate enthalten, z.B. von einer Heilberufs-Kammer (z.B. Ärztekammer, Apothekerkammer) oder von einer entsprechenden Organisation (z.B. einer Ärztevereinigung).
7.2 Erzeugung einer qualifizierten elektronischen Signatur
Der Prozess zur Erzeugung einer elektronischen Signatur besteht aus mehreren Schritten,
die in Abbildung 6 gezeigt werden.
Nachricht
Hashen der Nachricht
Formatieren
Signieren der Nachricht
Signierte Nachricht
Abbildung 6 – Signatur-Prozess gemäß ISO/IEC 9796-2
Seite 40 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Falls ein Hash-Algorithmus verwendet wird, der im HBA verfügbar ist, wird die Hashwertberechnung bis auf das Hashen des letzten Text-Blocks außerhalb der Karte durchgeführt. Der
bis dahin berechnete Hashwert wird - konkateniert mit dem letzten Text-Block - an den HBA
geliefert. Beim RSA-Verfahren ist der Hashwert kürzer ist als der Digital Signature Input
(DSI) für die Signaturberechnung. Deshalb muss ein Padding-Verfahren auf den Hashwert
angewendet werden, d.h. der Hashwert wird formatiert. Das Padding wird im HBA durchgeführt und das Padding-Verfahren, das angewendet werden soll, muss mit dem Kommando
MSE ausgewählt werden.
Falls ein Hash-Algorithmus verwendet werden soll, der nicht im HBA verfügbar ist, wird die
komplette Hashwert-Berechnung außerhalb des HBA durchgeführt; nur das Padding erfolgt
durch den HBA.
7.3 Sicherheitsumgebung (SE)
Im DF.QES gibt es zwei Sicherheitsumgebungen:
• SE # 1: Voreingestelltes SE. Es wird kein Trusted Channel genutzt.
• SE # 2: SE für die Nutzung der Signaturfunktion mit einem Trusted Channel, um
Konfigurationen mit fernbedientem HBA zu ermöglichen.
7.4 Auswahl der Anwendung QES
Die Auswahl der QES-Anwendung erfolgt mit dem Kommando SELECT.
Tabelle 50 – Kommando SELECT für DF.QES
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘A4’ = SELECT
'0C' = kein FCI zurückzugeben
‘D27600006601’ = AID von DF.QES
nicht vorhanden
Datenfeld
SW1-SW2
nicht vorhanden
Nach der Auswahl des DF ist SE# 1implizit gewählt. Zur Nutzung von SE # 2 siehe Kapitel
10.
Seite 41 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
7.5 PIN Management
7.5.1 PIN Prüfung
Für die PIN-Prüfung wird das ISO/IEC 7816-4 Kommando VERIFY genutzt.
Tabelle 52 - Kommando VERIFY für die PIN Prüfung
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘20’ = VERIFY
‘00’
‘81’ = PIN.QES Referenz
PIN (Format: siehe [HBA-T1])
nicht vorhanden
Tabelle 53 - VERIFY Antwort
Datenfeld
SW1-SW2
nicht vorhanden
Falls die eingegebene PIN falsch ist und zusätzliche Versuche erlaubt sind, muss die Zahl
der noch möglichen Versuche in den Status Codes, die in [HBA-T1] spezifiziert sind, angezeigt werden
7.5.2 PIN Änderung
Zur Änderung der PIN kann das ISO/IEC 7816-4-Kommando CHANGE.RD zu jeder Zeit vom
Heilberufler genutzt werden. Ist das Kommando erfolgreich ausgeführt, soll der Sicherheitsstatus "PIN mit Referenz '81' erfolgreich eingegeben" gesetzt werden.
Tabelle 54 – Kommando CHANGE RD
CLA
INS
‘24’ = CHANGE REFERENCE DATEN
P1
‘00’ = Ändern der Referenz-Daten
P2
‘81’ = PIN.QES Referenz
Lc
Datenfeld
PIN_alt || PIN_neu (PIN Format: siehe [HBA-T1])
Le
nicht vorhanden
Anmerkung:
Ob ein Sicherheitszustand gesetzt wird, wenn die Transport-PIN eingegeben wird, hängt von den
Vorgaben für die Handhabung der Transport-PIN im jeweiligen HBA ab.
Tabelle 55 - CHANGE RD Antwort
Seite 42 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Datenfeld
SW1-SW2
nicht vorhanden
7.5.3 Zurücksetzen des Fehlbedienungszählers
Zum Zurücksetzen des Fehlbedienungszählers auf seinen Ausgangswert wird das ISO/IEC
7816-4 Kommando RESET RETRY COUNTER verwendet.
Der Sicherheitsstatus wird durch dieses Kommando weder gesetzt noch beeinflusst. Damit
ist vor vor der Nutzung des PrK.HP.QES weiter die erfolgreiche Eingabe der PIN.QES notwendig.
Tabelle 56 – Kommando RESET RC zum Zurücksetzen des Fehlbedienungszählers
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘2C’ = RESET RETRY COUNTER
‘01’
‘81’ = Referenz der PIN.QES, zu der der Rücksetzcode (“PUK”) gemäß
ISO/IEC 7816-4 gehört
Rücksetzcode ("PUK", Format: siehe [HBA-T1])
nicht vorhanden
Tabelle 57 - RESET RC Antwort
Datenfeld
SW1-SW2
nicht vorhanden
7.6 Berechnung der QES
7.6.1 Signieren mit der letzten Runde der Hashwert-Berechnung im HBA
In einem ersten Schritt wird der Hash-Algorithmus mit dem Kommando MSE ausgewählt.
Tabelle 58– Kommando MSE zur Auswahl des Hash-Algorithmus
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘41’ = SET für Hashwert-Berechnung
‘AA’ = Hash-Template
80 01 xx’ = DO für AlgID, siehe Tab. 10 in [HBA-T1]
nicht vorhanden
Tabelle 59 – MSE Antwort
Seite 43 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Datenfeld
SW1-SW2
nicht vorhanden
In einem zweiten Schritt werden PrK.HP.QES und der Signatur-Algorithmus in Kombination
mit dem Padding-Verfahren ausgewählt.
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘41’ = SET für Berechnung
‘B6’ = DST
‘84 01 84 || 80 01 xx’ = DO für KeyID von PrK.HP.QES || DO für AlgID,
siehe Tabelle 10 in [HBA-T1]
nicht vorhanden
Datenfeld
SW1-SW2
nicht vorhanden
In einem dritten Schritt wird das Kommando PSO:HASH gesendet.
Tabelle 62 – Kommando PSO: HASH
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘2A’ = PERFORM SECURITY OPERATION: HASH
‘90’ = berechne den Hashwert
‘A0’ = Datenfeld enthält Dos, die relevant für das Hashing sind
‘90’ - L – Zwischen-Hashwert || ‘80’ - L – letzter Block (ohne Padding)
Zwischen-Hashwert: Hashwert (20 Bytes für SHA-1) || Zähler mit der
Zahl der Bits, die schon gehasht sind (8 Bytes für SHA-1); andere Werte
siehe [HBA-T1]
nicht vorhanden
Falls die Nachricht, die gehasht werden soll, kürzer als die Blocklänge ist, muss die Länge
des DO mit dem Tag ‘90’ auf Null gesetzt werden (d.h., es gibt keinen Zwischen-Hashwert),
gefolgt vom DO mit Tag ‘80’, das die Nachricht enthält, die gehasht werden soll.
Tabelle 63 - PSO: HASH Antwort
Seite 44 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Datenfeld
SW1-SW2
nicht vorhanden
Nachdem das Hashen durchgeführt ist, muss das ISO/IEC 7816-8-Kommando PSO: COMPUTE DIGITAL SIGNATURE gesendet werden.
Tabelle 64 – Kommando PSO: COMPUTE DS
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘2A’ = PERFORM SECURITY OPERATION: COMPUTE DIGITAL SIGNATURE
‘9E’ = Rückgabe der digitalen Signatur
‘9A’ = Datenfeld – falls vorhanden – enthält die Daten, die signiert oder in
die DS integriert werden sollen
nicht vorhanden
nicht vorhanden (z.B. DSI schon in der Karte vorhanden)
‘00’ oder ‘xx’ = Länge der erwarteten digitalen Signatur
Tabelle 65 - PSO: COMPUTE DS Antwort
Datenfeld
SW1-SW2
Digitale Signatur
7.6.2 Signieren mit vollständigem Hashen außerhalb der Karte
In diesem Fall wird das Kommando PSO: COMPUTE DS ohne ein vorheriges Kommando
PSO: HASH an den HBA gesendet. Vorher müssen der private Schlüssel und der Algorithmus Identifier ausgewählt werden.
CLA
INS
P1
P2
Lc
Daten
feld
Le
‘41’ = SET für die Berechnung
‘B6’ = DST
‘84 01 84 || 80 01 xx’ = DO für KeyID von PrK.HP.QES || DO für AlgID,
siehe Tabelle 10 in [HBA-T1]
nicht vorhanden
Datenfeld
SW1-SW2
nicht vorhanden
Tabelle 68 – Kommando PSO: COMPUTE DS
Seite 45 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘2A’ = PERFORM SECURITY OPERATION: COMPUTE DIGITAL SIGNATURE
‘9E’ = Digitale Signatur wird zurückgegeben
‘9A’ = das Datenfeld – falls vorhanden – enthält Daten, die signiert oder
in das DSI integriert werden sollen
- Digestinfo für den Fall, dass das Padding gemäß PKCS#1 Kapitel 9.2
erfolgt
- Hashwert für den Fall, dass das Padding gemäß ISO 9796 mit RND
erfolgt
Tabelle 69 - PSO: COMPUTE DS Antwort
Datenfeld
SW1-SW2
Digitale Signatur
7.7 Auslesen der zu QES gehörenden Zertifikate
Zum Lesen des X.509-QES-Zertifikates oder eines Attributzertifikates wird das Kommando
READ BINARY verwendet.
Tabelle 70 – Kommando READ BINARY zum Lesen der QES-Zertifikate
CLA
INS
P1, P2
Lc
Datenfeld
Le
- P1 = b8-b6: 100
b5-b1: 10000 SFID von EF.C.HP.QES: 16 oder
00001 SFID von EF.C.HP.QES-AC1: 1 oder
00011 SFID von EF.C.HP.QES-AC3: 3
P2 = Offset
- ‘xxxx’ = Offset (bit b8 von P1 = 0)
nicht vorhanden
nicht vorhanden
'00' oder '000000'
Datenfeld
SW1-SW2
Zertifikats-Daten
Falls die Karte "extended length" nicht unterstützt, muss das Kommando READ BINARY
wiederholt werden, wobei der zugehörende Offset in P1-P2 spezifiziert wird.
Seite 46 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
7.8 Schreiben von Attributszertifikaten
Zum Aktualisieren von Attributszertifikaten (siehe Zugriffsbedingungen in Anhang B) wird das
ISO/IEC 7816-4 Kommando UPDATE BINARY verwendet.
Tabelle 72 – Kommando UPDATE BINARY zum Schreiben neuer Attributszertifikate in den HBA
CLA
INS
P1, P2
Lc
Datenfeld
Le
- P1 = b8-b6: 100
b5-b1:
00011 SFID von EF.C.HP.QES-AC3: 3
P2 = Offset
Daten
nicht vorhanden
Datenfeld
SW1-SW2
nicht vorhanden
Falls das Zertifikat länger als 256 Bytes ist, muss das Kommando UPDATE BINARY wiederholt werden, wobei der zugehörende Offset in P1-P2 spezifiziert wird.
7.9 Fernbediente QES-Erzeugung
Die fernbediente Nutzung dieser Anwendung wird in Kapitel 10 beschrieben. Die Beschreibung eines Verfahrens, mit dem die Nutzung des TC kontrolliert wird, ist nicht Gegenstand
dieser Spezifikation.
Seite 47 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
8 Die ESIGN Anwendung
Abbildung 7 zeigt die prinzipielle Struktur der ESIGN-Anwendung, die in Übereinstimmung
mit [CWA14890] definiert ist.
MF
DF.ESIGN
EF.ARR**
EF.PrK*
- PrK.HP.ENC
- PrK.HP.AUT
EF.C.HP.ENC
EF.C.HP.AUT
EF.DM
AUT
C
DM
ENC
HP
= Authentifizierung
= Zertifikat
= Display Message
= Verschlüsselung
= Heilberufler
Abbildung 7 – Prinzipielle Struktur von DF.ESIGN
8.1.1 EF.ARR
EF.ARR enthält die Zugriffsbedingungen für DF.ESIGN
8.1.2 EF.PrK
EF.PrK enthält die folgenden privaten Schlüssel:
• PrK.HP.AUT für eine Client/Server-Authentifizierung
• PrK.HP.ENC für das Ver- und Entschlüsseln von Dokumenten
Die "Key Identifier" und der Schutz der privaten Schlüssel werden in der folgenden Tabelle
aufgeführt:
Seite 48 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Tabelle 74 – "Key identifier" und Schutz der privaten Schlüssel
Schlüssel-Name
PrK.HP.AUT
KeyID
‘82’
PrK.HP.ENC
‘83’
Zugriffsbedingungen
- SE # 1: PIN.CH
- SE # 2: PIN.CH und SM
- SE # 1: PIN.CH
- SE # 2: PIN.CH und SM
In Bezug auf die Schlüssellängen müssen dieselben Konventionen wie für die Schlüssel der
qualifizierten elektronischen Signatur berücksichtigt werden, siehe [ALGCAT].
Die zugelassenen Padding-Verfahren werden in Anhang E beschrieben.
Der HBA muss sicherstellen, dass die entsprechenden Schlüssel nur für die Dienste genutzt
werden können, für die sie vorgesehen sind (interne Bindung des Schlüssels an seinen Verwendungszweck. Die Art und Weise, wie dies garantiert wird, ist abhängig vom Betriebssystem).
8.1.3 EF.DM
Das transparente File EF.DM enthält dieselbe Display Message wie in Kapitel 7.1.4. beschrieben.
8.1.4 EF.C.HP.AUT
EF.C.HP.AUT enthält das X.509-AUT-Zertifikat des Heilberuflers.
8.1.5 EF.C.HP.ENC
EF.C.HP.ENC enthält das X.509-ENC-Zertifikat des Heilberuflers.
8.2 Sicherheitsumgebung
In DF.ESIGN sind 2 SEs definiert:
• SE # 1: Voreingestelltes SE. Es wird kein Trusted Channel genutzt.
• SE # 2: SE für die Nutzung der Signaturfunktion mit einem Trusted Channel, um
Konfigurationen mit fernbedientem HBA zu ermöglichen.
Seite 49 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
8.3 Auswahl der ESIGN Anwendung
Die Auswahl der ESIGN-Anwendung erfolgt mit dem Kommando SELECT.
Tabelle 75 - Kommando SELECT für DF.ESIGN
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘A4’ = SELECT
'0C' = kein FCI zurückzugeben
'A000000167 455349474E’ = AID von DF.ESIGN
nicht vorhanden
Datenfeld
SW1-SW2
nicht vorhanden
Nach der Auswahl des DF ist SE # 1 implizit gewählt. Zur Nutzung von SE # 2 siehe Kapitel
10.
8.4 Lesen eines X.509 Zertifikates
Zum Lesen der Zertifikate C.HP.AUT und C.HP.ENC wird das Kommando READ BINARY
verwendet.
Tabelle 77 - Kommando READ BINARY zum Lesen der X.509-Zertifikate
CLA
INS
P1-P2
Lc
Datenfeld
Le
- P1 = b8-b6: 100
b5-b1: 00001 SFID von EF.C.HP.AUT: 1 oder
00010 SFID von EF.C.HP.ENC: 2
P2 = Offset
nicht vorhanden
nicht vorhanden
'00' oder '000000'
Seite 50 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Datenfeld
SW1-SW2
X.509-Zertifikat
Falls die Karte "extended length" nicht unterstützt, muss das Kommando READ BINARY
wiederholt werden, wobei der zugehörende Offset in P1-P2 spezifiziert wird.
8.5 PIN Management
Vor der Nutzung von PrK.HP.AUT oder PrK.HP.ENC muss PIN.CH erfolgreich eingegeben
werden, siehe Kapitel 4.5.1.
8.6 Client / Server Authentifizierung
Um die Zugriffsrechte zu Komponenten wie z.B. Servern überprüfen zu können, muss ein
PKI-basierter Authentifizierungs-Prozess ausgeführt werden. Das verwendete Schlüsselpaar
ist das des Karteninhabers (PrK.HP.AUT, PuK.HP.AUT). Der öffentliche Schlüssel ist zusammen mit dem eindeutigen Namen des Karteninhabers ("Distinguished Name") durch das
X.509-Zertifikat nachprüfbar beglaubigt.
Relevante Authentisierungsprotokolle sind z.B.
• das PK-Kerberos-Protokoll (für Login-Authentisierung)
• das TLS-Protokoll (für Authentisierung auf Seiten des Clients; umfasst das SSLProtokoll)
• das WTLS-Protokoll
Diese Spezifikation deckt nur denjenigen Fall ab, bei dem die Karte für die Berechnung einer
digitalen Signatur den privaten Schlüssel in einem INTERNAL AUTHENTICATE Kommando
auf den Authentisierungs-Input im Datenfeld des Kommandos nach Formatierung dieses
Inputs anwendet.
Die übrigen Anteile des Verfahrens auf Seiten des Clients muss die Systemsoftware des
Karteninhabers übernehmen.
Bevor das INTERNAL AUTHENTICATE Kommando ausgeführt werden kann, muss der zugehörige PrK selektiert werden.
Zusätzlich kann der Algorithmus Identifier, der den Typ des Authentifizierungsprotokolls beschreibt, ausgewählt werden.
Seite 51 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
CLA
INS
P1
P2
Lc
Daten
feld
Le
‘41’ = SET für interne Authentifizierung
‘A4’ = AT
‘84 01 82’ || ’80 01 05’ = DO für KeyID von PrK.HP.AUT || DO AlgID,
siehe Tabelle E.2
nicht vorhanden
Datenfeld
SW1-SW2
nicht vorhanden
CLA
INS
P1
P2
Lc
Daten
feld
Le
‘00’
‘00’
- DigestInfo, genutzt für KERBEROS
H_MD5 || H_SHA1, genutzt für SSL/TLS
H_SHA1, genutzt für WTLS und NETSCAPE
Die Formatierung des Digital Signature Inputs zur Authentifizierung ist in
[HBA-T1], Anhang E spezifiziert.
Datenfeld
SW1-SW2
Digitale Signatur
8.7 Entschlüsselung des Dokumenten-Chiffrierungsschlüssels
Zum Austausch vertraulicher Dokumente wird das folgende Verfahren genutzt:
• der Schlüsseltransport wird durch Verschlüsseln des zum Verschlüsseln des Dokumentes benutzten Schlüssels mit dem PuK.HP.ENC des Empfängers abgesichert.
• Das Dokument wird mit einem symmetrischen Verfahren verschlüsselt.
An der Verschlüsselung eines Dokumentes ist der HBA nicht beteiligt. Die Software des PC
des Senders berechnet einen Verschlüsselungsschlüssel, verschlüsselt das Dokument damit
Seite 52 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
und verschlüsselt anschließend den Verschlüsselungsschlüssel mit dem öffentlichen X.509ENC-Schlüssel des Empfängers. Diesen erhält sie z.B. von einem Zertifikats-Server.
Bevor der Verschlüsselungsschlüssel vom Empfänger mit seinem PrK.HP.ENC entschlüsselt
werden kann, muss die PIN.CH erfolgreich eingegeben worden sein. Der PrK.HP.ENC muss
mit dem ISO/IEC 7816-4 Kommando MSE ausgewählt werden.
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘41’ = SET für Entschlüsselung
‘B8’ = CT
’84 01 83’ = DO für KeyID von PrK.HP.ENC
nicht vorhanden
Datenfeld
SW1-SW2
nicht vorhanden
Nachdem der Schlüssel ausgewählt ist, kann die Entschlüsselung mit dem ISO/IEC 7816-8
Kommando PSO: DECIPHER erfolgen.
Tabelle 85 – Kommando PSO: DECIPHER
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘2A’ = PERFORM SECURITY OPERATION: DECIPHER
‘80’ = Klartext zurückgeben
‘86’ = verschlüsselte Daten im Datenfeld
Padding-Indicator-Byte, gefolgt vom Kryptogramm, siehe [HPC-P1
‘00’ or ‘xx’ = Länge des Dokumenten-Chiffrierschlüssels
Tabelle 86 – PSO: DECIPHER Antwort
Datenfeld
SW1-SW2
Dokumenten-Chiffrierschlüssel
8.8 Fernbediente Nutzung der ESIGN-Anwendung
Die fernbediente Nutzung dieser Anwendung wird in Kapitel 10 beschrieben. Die Beschreibung des Verfahrens, mit dem die Nutzung des TC kontrolliert wird, ist nicht Gegenstand
dieser Spezifikation.
Seite 53 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
9 Kryptografische Informations-Anwendung
9.1 File-Struktur und File-Inhalt von DF.CIA.ESIGN
Abbildung 8 zeigt die prinzipielle Struktur der kryptografischen Informations-Anwendung
(CIA), die mit der ESIGN-Anwendung verknüpft ist.
MF
DF.CIA.ESIGN
EF.ARR*
EF.CIAInfo
EF.OD
CIA = Cryptographic Inf. Application
OD = Object Directory
AOD = Authentication Object Directory
PrKD = Private Key Directory
CD = Certificate Directory
EF.AOD
EF.PrKD
EF.CD
* diese Datei soll – falls vorhanden – gemäß ISO/IEC 7816-4 genutzt werden
Abbildung 8 – Prinzipielle Struktur des DF.CIA
9.2 Anwendungsauswahl
Zur Auswahl der Anwendung wird das ISO/IEC 7816-4-Kommando SELECT verwendet.
Tabelle 87 – Kommando SELECT für DF.CIA.ESIGN
CLA
INS
P1
P2
‘00’
‘A4’ = SELECT
‘04’ = DF Auswahl durch AID
‘0C’ = kein FCI zurückzugeben
Seite 54 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Lc
‘0F’ = Länge des zugehörenden Datenfeldes
Datenfeld
Le
'E828BD080F A000000167 455349474E’ = AID von DF.CIA.ESIGN
nicht vorhanden
Anmerkung:
Der RID von DF.CIA entspricht ISO/IEC 7816-15. Dem RID folgt der AID der Anwendung, zu der
die CIOs gehören, in diesem Fall AID.ESIGN.
Tabelle 88 – SELECT Antwort
Datenfeld
SW1-SW2
nicht vorhanden
9.3 Lesen der CIA-Files
Zum Lesen der CIA-Files wird das ISO/IEC 7816-4 Kommando READ BINARY genutzt.
Tabelle 89 – Kommando READ BINARY zum Lesen der CIA Files
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘xx’ = b8-b6: 100
b5-b1: 10010 SFID von EF.CIAInfo: 18 oder
b5-b1: 10001 SFID von EF. OD: 17 oder
b5-b1: 10100 SFID von EF. AOD: 20 oder
b5-b1: 10101 SFID von EF. PrKD: 21 oder
b5-b1: 10110 SFID von EF. CD: 22
‘00’ = Offset
nicht vorhanden
nicht vorhanden
‘00’ = Lesen bis zum Ende des Files (max 256 Bytes)
Anmerkung:
SFID 19 kann nicht genutzt werden, siehe ISO/IEC 7816-15.
Tabelle 90- SELECT Antwort
Datenfeld
SW1-SW2
CIOs
Seite 55 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
10 Interaktionen zwischen HBA und SMC
10.1 Lesen der CV-Zertifikate
In Kapitel 5.4.4 ist spezifiziert, wie die HBA-CV-Zertifikate – die auf MF-Ebene gespeichert
sind – ausgelesen werden können. Es wird davon ausgegangen, dass die beteiligte Software
(z.B. PVS oder AVS) die CVCs des HBA nur einmal ausliest und sie zusammen mit der zugehörigen ICCSN im System speichert.
10.2 SE-Auswahl auf MF Ebene
Für die Interaktion HBA/SMC muss SE # 2 auf der MF-Ebene ausgewählt werden, siehe Kapitel 5.3.
10.3 Auswahl der Anwendung, die mit SM genutzt werden soll
Vor der Etablierung eines TC muss die jeweilige Anwendung, DF.ESIGN oder DF.QES, ausgewählt werden, siehe Kapitel 8.4 oder 9.3.
Da das Kommando SELECT zur Auswahl einer Anwendung immer ohne SM gesendet wird,
geht der TC verloren, wenn später eine andere Anwendung ausgewählt wird. In diesem Fall
ist ein TC erneut aufzubauen.
10.4 SE-Auswahl auf DF-Ebene
Bevor irgendein Kommando nach der Auswahl der Anwendung gesendet wird, muss SE # 2
mit dem Kommando MSE unter Nutzung der RESTORE-Funktion ausgewählt werden.
Tabelle 91 – Kommando MSE zur Auswahl des SE zur Einrichtung eines TC
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘F3’ = RESTORE
‘02’ = SE # 2
nicht vorhanden
nicht vorhanden
nicht vorhanden
Seite 56 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Datenfeld
SW1-SW2
nicht vorhanden
10.5 CVC Prüfung
Die folgenden CVCs müssen geprüft werden:
• CVC.CA_SMC.CS
• CVC.SMC.AUT
Der Ablauf entspricht dem in Kapitel 4.6.3 beschriebenen Ablauf.
10.6 Authentifizierung mit TC-Einrichtung
Die Kommandosequenz startet für den HBA mit der Auswahl der beteiligten Schlüssel.
Tabelle 93 – Kommando MSE zur Schlüsselauswahl
CLA
INS
P1
P2
Lc
Daten
feld
Le
‘C1’ = SET für int./ext. Authentifizierung
‘A4’ = AT
‘83 0C xx ... xx’ || ‘84 01 11’ = DO für KeyRef von PuK.SMC.AUT (siehe
Abbildung 3 bzgl. der Auswahl der KeyRef) || DO für KeyRef von
PrK.HPC.AUT
nicht vorhanden
Datenfeld
SW1-SW2
nicht vorhanden
Anschließend wird der Authentifizierungsprozess - wie in [HBA-T1], Anhang E beschrieben ausgeführt. Die Prozessschritte müssen aus Sicht des HBA in der in [HPC-1], Anhang E angegebenen Reihenfolge durchgeführt werden, d.h., in einem ersten Schritt muss eine Zufallszahl vom HBA angefordert werden.
Tabelle 95 – Kommando GET CHALLENGE
Seite 57 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
CLA
INS
P1, P2
Lc
Datenfeld
Le
‘84’ = GET CHALLENGE
‘0000’
nicht vorhanden
nicht vorhanden
‘08’
Tabelle 96 - GET CHALLENGE Antwort
Datenfeld
SW1-SW2
RND.HPC (8 Bytes)
Die Zufallszahl wird der SMC zusammen mit den 8 LSB der ICCSN des HBA übergeben.
Das Ergebnis des von der SMC ausgeführten Kommandos INTERNAL AUTHENTICATE
wird mit dem Kommando EXTERNAL AUTHENTICATE an den HBA gesendet.
Tabelle 97 – Kommando EXT. AUTHENTICATE
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘82’ = EXTERNAL AUTHENTICATE
‘00’
‘00’
nicht vorhanden
Anmerkung:
Die auf die Authentifizierung bezogenen Daten enthalten Datenelemente für die SMSchlüsselberechnung.
Tabelle 98 - EXT. AUTHENTICATE Antwort
Datenfeld
SW1-SW2
nicht vorhanden
In einem dritten Schritt muss der HBA seine Authentizität beweisen.
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘00’
‘00’
Seite 58 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Datenfeld
SW1-SW2
Die SM-Schlüssel werden wie in [HBA-T1], Anhang E.3 beschrieben berechnet; der Anfangswert des Send Sequence Counter (SSC) wird wie in [HBA-T1], Kapitel C.5.2. beschrieben gesetzt.
10.7 Lesen und Aktualisieren einer Display Message
Nach der Einrichtung eines TC kann die Display Message gelesen werden und dem Heilberufler zeigen, dass der TC erfolgreich eingerichtet wurde. Das Auslesen wird jedoch vom
HBA nicht kontrolliert.
Zum Auslesen der Display Message wird das Kommando READ BINARY verwendet.
Tabelle 101 – Kommando READ BINARY zum Auslesen der Display Message
CLA
INS
P1
P2
Lc
Datenfeld
Le
'84' = b8-b6:100
b5-b1: 00100 SFID von EF.DM: 4
‘00’ = Offset
nicht vorhanden
nicht vorhanden
'08'
Anmerkung:
Jede TC-relevante Anwendung hat ihr eigenes EF.DM mit SFID 4.
Datenfeld
SW1-SW2
Display Message
Die Display Message kann nach erfolgreicher Eingabe von PIN.CH mit dem Kommando
UPDATE BINARY geändert werden.
Tabelle 103 – Kommando UPDATE BINARY zur Änderung der Display Message
CLA
Seite 59 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
INS
P1
P2
Lc
Datenfeld
Le
b8-b6:100
b5-b1: 00100 SFID von EF.DM: 4
‘00’ = Offset
Neue Display Message (8 Bytes)
nicht vorhanden
Datenfeld
SW1-SW2
nicht vorhanden
Seite 60 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
11 Laden einer neuen Anwendung oder Erstellung eines
EFs nach Ausgabe des HBA
11.1 Identifizierung des HBA-Betriebssystems
Es wird angenommen, dass das Laden neuer Anwendungen oder die Einrichtung neuer EFs
in DF.HPA nach der Ausgabe des HBA von einem Card Application Management System
(CAMS) durchgeführt wird. Ein CAMS kann schon Informationen über einen bestimmten
HBA gespeichert haben, z.B. die ICCSN, das zugehörende Betriebssystem und die schon
vorhandenen Anwendungen. Das CAMS kann diese Informationen aber auch durch das
Auslesen of EF.ATR, EF.GDO und EF.DIR bekommen.
11.2 Einrichtung eines Trusted Channel zwischen CAMS und HBA
Ein Trusted Channel kann mit symmetrischen oder asymmetrischen Authentifizierungsverfahren eingerichtet werden. Dies hängt vom beteiligten CAMS ab. Im Folgenden wird das
asymmetrische Authentifizierungsverfahren beschrieben, das auch Teil des Protection Profiles des HBA [PP-HPC] ist.
Zur Einrichtung eines TC zwischen dem HBA und dem zugehörigen CAMS muss ein asymmetrisches Authentifizierungsverfahren mit der Berechnung der SM-Schlüssel gemäß [HBAT1], Annex E 3 ausgeführt werden. Da der PuK.CAMS_HPC.AUT schon im HBA gespeichert
ist, ist keine Prüfung der CVCs des CAMS notwendig. Dem CAMS müssen allerdings die
CVCs des HBA übermittelt werden, siehe Abbildung 9.
Seite 61 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Root CA
Durch die RCA selbstsigniertes Zertifikat zur BereitstelCVC.
lung des öffentlichen RootSchlüssels PuK.RCA.CS, der RCA.
CS
für die Prüfung von
CVC.CA.HPC.CS benötigt
wird
PuK.HPC.AUT
Schlüssel, die für die
Authentifizierung
benötigt werden
CAMS
PrK.CAMS_HPC.AUT
CVC.
CA_HPC.
CS
Bereitstellung von
PuK.HPC.AUT über
die Zertifikats-Kette
PrK.HPC.AUT
Schlüssel, die für die
Authentifizierung
benötigt werden
CVC.
HPC.
AUT
HBA
PuK.CAMS_HPC.AUT
(im HBA verfügbar)
Abbildung 9 – Schlüssel und Schlüsselimport für eine HBA/CAMS-Authentifizierung mit TC
Einrichtung
In einem ersten Schritt müssen die öffentlichen Schlüssel des CAMS mit dem Kommando
MSE ausgewählt werden.
Tabelle 105 – Kommando MSE zur Auswahl von PuK.CAMS_HPC.AUT
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘C1’ = SET für int./ext. Authentifizierung
‘A4’ = AT
‘840113' = DO KeyID für PuK.CAMS_HPC.AUT
nicht vorhanden
Datenfeld
SW1-SW2
nicht vorhanden
Seite 62 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
11.3 Laden einer Anwendung
Die Kommandosequenz für das Laden einer neuen Anwendung ist herstellerspezifisch.
Kommandos, die hierfür benötigt werden, sind in [HBA-T1] spezifiziert.
11.4 Registrieren der neuen Anwendung in EF.DIR
In EF.DIR muss ein DO Anwendungs-Template mit dem Application Identifier der neuen Anwendung eingefügt werden. Hierfür wird das Kommando APPEND RECORD verwendet.
Tabelle 107 – Kommando APPEND RECORD
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘E2’ = APPEND RECORD
‘00’
‘F0’ = b8-b4: 11110 SFID von EF.DIR: 30
b3-b1: 000
DO Anwendungs-Template, siehe Tabelle G.3
nicht vorhanden
Tabelle 108 – APPEND RECORD Antwort
Datenfeld
SW1-SW2
nicht vorhanden
11.5 Erstellung eines EF
Zur Erstellung eines neuen EF auf MF-Ebene oder unter DF.HPA wird das ISO/IEC 7816-8Kommando CREATE FILE verwendet.
Tabelle 109 – Kommando CREATE FILE
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘E0’ = CREATE FILE
‘00’ = EF-Erstellung
‘00’
FCP des EF, das erstellt werden soll (betriebssystem-spezifisch)
nicht vorhanden
Tabelle 110 – CREATE FILE Antwort
Seite 63 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Datenfeld
SW1-SW2
nicht vorhanden
Falls für dieses EF neue Zugriffsregeln gelten sollen, müssen diese Zugriffsregeln mit dem
Befehl APPEND RECORD in das entsprechende EF.ARR geschrieben werden.
Seite 64 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Anhang A
(normativ)
AT R
A.1 ATR Kodierung
Tabelle A.1 zeigt die Kodierung des ATR für HBAs (T = 1 – Karten)
Tabelle A. 1 – ATR-Kodierung (Sequenz von oben nach unten)
Zeichen
Wert
Bedeutung
TS
‘3B’
Initial Character (direct convention)
T0
‘9x’
Format Character
(TA1/TD1 indication, x = no. of HB)
TA1
‘xx’
Interface Character (FI/DI,
erlaubte Werte: siehe [eHC-P1])
TD1
‘81’
Interface Character
(T=1, TD2 indication)
TD2
‘B1’
Interface Character
(T=1, TA3/TB3/TD3 indication)
TA3
‘FE’
Interface Character (IFSC coding)
TB3
‘45’
Interface Character
(BWI/CWI coding)
TD3
‘1F’
Interface Character
(T=15, TA4 indication)
TA4
‘xx’
Interface Character (XI/UI coding)
Ti
HB
Historical Bytes (HB, imax. = 15)
TCK
XOR
Check Character (exclusive OR)
Für die Kodierung der Historical Bytes gelten die folgenden Konventionen in Übereinstimmung mit ISO/IEC 7816-4:
Seite 65 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
CI
‘00’ gemäß ISO/IEC 7816-4
TPI
‘6x’ gemäß ISO/IEC 7816-4 (x kodiert die Länge des DO)
ICM
IC Herstellerkennung
ICT
Kodierung herstellerspezifisch
OSV
Kodierung herstellerspezifisch
DD
Kodierung herstellerspezifisch (normalerweise nicht verwendet)
TCS
CS
Card Service Data Byte gemäß ISO/IEC 7816-4
TCC
CCB
Card Capabilities Data Bytes
gemäß ISO/IEC 7816-4
(Anzeige der unterstützten logischen Kanäle, Extended Le-Feld, …)
CLS
Card Life Cycle (Default-Wert ‘00’)
SW1-SW2
‘9000’
Aus Performancegründen ist es erlaubt, ein TC1 mit dem Wert 'FF‘ im ATR anzuzeigen.
Seite 66 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Historical Bytes
CI
PIDO CPDO CLS SW1-SW2
-
CI = Category Indicator (’00‘)
PIDO = PrePre-Issuing Data Object
CPDO = Card Profile Data Object
CLS = Card Life Status
SW1-SW2 = Status bytes
Pre-Issuing
Data Object
TPI
ICM
ICT
OSV DD
TPI = Tag/Length Pre-Issuing
DO (‘6x‘)
ICM = IC Manufacturer ID
ICT = IC Type (1 byte, if b8=0;
2 byte, if b8=1 of first byte)
OSV = Operating System Version (1 byte)
DD = Discretionary Data (n byte)
Card Profile Data Objects
TCS
CS
TCC
CCB
TCS = Tag/Length Card Service DO (‘31‘)
CS = Card Service Data Byte
TCC = Tag/Length Card Capabilities DO (’73‘)
CCB = Card Capability Bytes
Abbildung A.1 – Struktur der Historical Bytes
Die aktuellen Werte für die Chip-Hersteller-Kennung (IC Manufacturer ICM) können unter
www.sc17.com abgerufen werden.
Seite 67 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Annex B
(normativ)
File-Attribute, Zugriffsbedingungen
und Sicherheitsumgebungen
B.1 Zugriffsbedingungen
Falls ein Betriebssystem EF.ARR nicht unterstützt, muss dieselbe Funktionalität auf andere
Weise sichergestellt werden. HBAs mit EF.ARR sollen lesenden Zugriff auf die gespeicherten Zugriffsbedingungen erlauben. Deshalb ist die Sicherheitsbedingung für das Kommando
READ RECORD, bezogen auf EF.ARR, auf "always" gesetzt. Ein EF.ARR könnte z.B. durch
ein CAMS ausgelesen werden.
Die in diesem Kapitel spezifizierten Zugriffsregeln werden durch Kodierungsbeispiele dargestellt. Diese können so oder auch durch eine andere Kodierung umgesetzt werden; die geforderte Funktionalität muss aber in jedem Fall garantiert werden.
Falls ein Dual-Interface-Chip mit einer kontaktbehafteten und einer RF-Schnittstelle eingesetzt wird, müssen Zugriffsbedingungen realisiert werden, die die Nutzung der in dieser Spezifikation beschriebenen Anwendungen nur über die kontaktbehaftete Schnittstelle zulässt.
B.2 MF-Ebene
Auf MF-Ebene werden SE # 1 und SE # 2 genutzt. Die Zugriffsbedingungen sind unabhängig
vom SE, falls dies nicht anders spezifiziert ist.
Tabelle B.1 – EFs auf MF Ebene und ihre Eigenschaften
File
FID /
SFID
File
Struktur
File Größe
(Länge der Daten)
Zugriffsbedingung
EF.ARR
(Zugriffsbedingungen)
EF.ATR
(ATR Zusätzliche Daten)
EF.DIR
(Anwendung-Verzeichnis)
EF.GDO
(Globale Daten Objekte)
EF.CVC.HPC.AUT
(Card Verifiable Certificate)
COS spezifisch
‘2F01’ /
29
‘2F00’ /
30
‘2F02’ /
2
‘2F03’ /
3
linear variabel
transparent
8 Records mit x
Bytes
32 Bytes
ARR # 1
linear variabel
transparent
6 Records mit x
Bytes
12 Bytes
ARR # 1
transparent
209 Bytes
ARR # 1
ARR # 1
ARR # 2
Seite 68 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
EF.CVC.CA_HPC.CS
(Card Verifiable Certificate)
‘2F04’ /
4
transparent
210 Bytes
ARR # 1
Tabelle B.2 – Zugriffsbedingungen in EF.ARR auf MF-Ebene
Rec Nr.
1
2
Wert
Bedeutung
’80 01 01
9000’
AM: READ BINARY / READ RECORD
SC: Always
’80 01 01
9000
referenziert in EF.ATR, EF.GDO,
EF.CVC.CA_HPC.CS, EF.CVC.HPC.AUT und EF.ARR
AM: READ RECORD
SC: Always
80 01 04
AF 0D
A406 950180 830113
B403 950130’
3
'86 08 2000 2400 2C00 2C01
9000’
4
'86 08 2000 2400 2C00 2C01
AF 0A
B4 03 95 01 30
B8 03 95 01 30'
AM: APPEND RECORD
SC: AND Template
{AT (UQ = Ext. Authentifizierung, Key Ref =
PuK.CAMS_HPC.AUT) || CCT (UQ = CC in SM command/answer)}
referenziert in EF.DIR
AM: VERIFY, CHANGE RD (Option ‘00’), RESET RC
(Option ‘00’ und ‘01’)
SC: Always
referenziert durch PIN.CH in EF.PIN, SE # 1
(Option ‘00’ und ‘01’)
SC: AND Template
{CCT (UQ = CC in SM command/answer) ||
CT (UQ = CG in SM command/answer)}
referenziert durch PIN.CH in EF.PIN, SE # 2
5
'84 01 88
A4 06
950108 830101'
AM: INTERNAL AUTHENTICATE
SC: AT (UQ = wissensbasierte NutzerAuthentifizierung, KeyRef = PIN.CH)
6
'84 02 8882
9000’
referenziert durch PrK.HPC.AUT in EF.PrK, SE # 1
AM: INT. / EXT. AUTHENTICATE
SC: Always
7
’87 03 2A00AE
9000’
referenziert durch PrK.HPC.AUT in EF.PrK SE # 2
AM: VERIFY CERTIFICATE
SC: Always
8
'84 02 EA E0
AF 12
referenziert durch PuK.RCA.CS in EF.PuK
AM: LOAD APPLICATION, CREATE FILE DF, CREATE
FILE EF (nach HBA-Ausgabe)
SC: AND Template
Seite 69 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
A4 06
95 01 80
83 01 13
B4 03 95 01 30
B8 03 95 01 30'
{AT (UQ = ext. Authentifizierung, Key Ref =
PuK.CAMS_HPC.AUT) ||
CCT (UQ = CC in SM command/answer) ||
referenziert in MF
Seite 70 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
B.3 DF.HPA
In DF.HPA wird nur SE # 1 (voreingestelltes SE) genutzt.
Tabelle B.3 – EFs in DF.HPA und ihre Eigenschaften
File
FID /
SFID
File
Struktur
EF.ARR
EF.HPD
(Daten, die auf den Heilberufler
bezogen sind)
COS spe- linear variabel
zifisch
‘D0001’ / 1 transparent
File Größe
(Länge der Daten)
Zugriffsbedingung
3 Records mit x Bytes
ARR # 1
2 KB
ARR # 2
Tabelle B.4 – Zugriffsbedingungen in EF.ARR in DF.HPA
Rec-No.
Wert
Bedeutung
1
’80 01 01
9000
AM: READ RECORD
SC: Always
80 01 04
AF0D
A406 950180 830113
B403 950130’
AM: APPEND RECORD
SC: AND Template
PuK.CAMS_HPC.AUT) || CCT (UQ = CC in SM command/answer)}
2
3
’80 01 01
9000
referenziert in EF.ARR
AM: READ BINARY
SC: Always
80 01 02
A406
950108 830101'
AM: UPDATE BINARY
SC AT (UQ = wissensbasierte NutzerAuthentifizierung, KeyRef = PIN.CH)
'80 01 02
AF 12
A4 06
95 01 80 83 01 13
B4 03 95 01 30
B8 03 95 01 30'
referenziert in EF.HPD
AM: CREATE FILE (EF)
SC: AND Template
PuK.CAMS_HPC.AUT) ||
referenziert in FCP von DF.HPA
Seite 71 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
B.4 DF.QES
In DF.QES werden SE # 1 und SE # 2 genutzt. Die Zugriffsbedingungen hängen vom SE ab,
falls dies nicht anders spezifiziert ist.
Tabelle B.5 – EFs in DF.QES und ihre Eigenschaften
File
FID /
SFID
File
Struktur
File Größe
(Länge der Daten)
Zugriffsbedingung
EF.ARR
EF.C.HP.QES
(Zertifikat der QES)
EF.C.HP.QES-AC1
(QES Attributs Zertifikat 1)
EF.C.HP.QES-AC2
EF.C.HP.QES-AC3
EF.DM
(Display Message)
COS
spezifisch
‘C000’ /
16
‘C001’ /
1
‘C002’ /
2
‘C003’ /
3
‘D004’ /
4
linear variabel
7 Records mit x Bytes
ARR # 1
transparent
1.5 k Byte oder
Länge des Zertifikats
1k Byte oder
1k Byte oder
1k Byte oder
8 Bytes
ARR # 1
transparent
transparent
transparent
transparent
ARR # 2
ARR # 2
ARR # 2
ARR # 3
Anmerkung:
Der HBA enthält alle Zertifikate, wenn er dem Heilberufler übergeben wird. Dieses schließt die
Personalisierung in mehreren Schritten, z.B. durch Interaktion mit verschiedenen ZertifikatsService-Anbietern, nicht aus.
Tabelle B.6 – Zugriffsbedingungen in EF.ARR in DF.QES
Rec-No.
1
Wert
’80 01 01
9000’
Bedeutung
AM: READ RECORD / READ BINARY
SC: Always
2
’80 01 01
9000
referenziert in EF.ARR und in EF.C.HP.QES
AM: READ BINARY
SC: Always
80 01 02
A406 950108
830101’
AM: UPDATE BINARY
SC: AT (UQ = wissensbasierte Nutzer-Authentifizierung,
KeyRef = PIN.CH)
’80 01 01
AF 0A
B4 03 95 01 30
B8 03 95 01 30
referenziert in EF.CH.QES-AC1 / AC2 / AC3
AM: READ BINARY
SC: AND Template
3
Seite 72 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Rec-No.
Wert
Bedeutung
80 01 02
A406 950108
830101’
AM: UPDATE BINARY
AT (UQ = wissensbasierte Nutzer-Authentifizierung,
KeyRef = PIN.CH)
4
'86 06 2000 2400 2C01
9000'
referenziert in EF.DM
AM: VERIFY, CHANGE RD (Option '00'), RESET RC
(Option '01')
SC: Always
5
'86 06 2000 2400 2C01
AF 0A
B4 03 95 01 30
B8 03 95 01 30'
referenziert durch PIN.QES in EF.PIN, SE # 1
(Option ‘01’)
SC: AND Template
6
'87 03 2A9E9A
A406
950108 830181'
referenziert durch PIN.QES in EF.PIN, SE # 2
PSO: COMPUTE DS
KeyRef = PIN.QES)
7
'87032A9E9A
AF 12
A406
950108 830181
B4 03 95 01 30
B8 03 95 01 30'
referenziert in EF.PrK durch PrK.HP.QES, SE # 1
PSO: COMPUTE DS
SC: AND Template
{AT (UQ = wissensbasierte Nutzer-Authentifizierung,
KeyRef = PIN.QES) ||
referenziert in EF.PrK durch PrK.HP.QES, SE # 2
B.5 DF.ESIGN
In DF.ESIGN werden SE # 1 und SE # 2 genutzt. Die Zugriffsbedingungen hängen vom SE
ab, falls dies nicht anders spezifiziert ist.
Tabelle B.7 – EFs in DF.ESIGN und ihre Eigenschaften
File
EF.ARR
EF.C.HP.AUT
(AuthentifizierungsZertifikat)
EF.C.HP.ENC
(Verschlüsselungs-Zertifikat
)
FID /
SFID
COS
spezifisch
‘C500’ /
1
File
Struktur
linear variabel
File Größe
(Länge der Daten)
4 Records mit x
Bytes
transparent
‘C200’ /
2
transparent
1.5 k Byte oder
1k Byte oder Länge
des Zertifikats
Zugriffsbedingung
ARR # 1
ARR # 1
ARR # 1
Seite 73 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
EF.DM
(Display Message)
‘D004’ /
4
transparent
8 Bytes
ARR # 2
Tabelle B.8 – Zugriffsbedingungen in EF.ARR in DF.ESIGN
Rec-Nr.
1
Wert
’80 01 01
9000’
Bedeutung
SC: Always
2
’80 01 01
AF 0A
B4 03 95 01 30
B8 03 95 01 30
referenziert in EF.ARR, EF.C.HP.AUT und in EF.C.HP.ENC
AM: READ BINARY
SC: AND Template
80 01 02
A406 950108
830101’
AM: UPDATE BINARY
AT (UQ = wissensbasierte Nutzer-Authentifizierung,
KeyRef = PIN.CH)
’87 06 880000 2A8086
A4 06 950108
830101’
referenziert in EF.DM
AM: INT. AUTHENTICATE / PSO: DECIPHER
KeyRef = PIN.CH)
’87 06 880000 2A8086
AF 12
A406
950108 830101
B4 03 95 01 30
B8 03 95 01 30'
referenziert durch PrK.HP.AUT und PrK.HP.ENC in EF.PrK,
SE # 1
AM: INT. AUTHENTICATE / PSO: DECIPHER
SC: AND Template
{AT (UQ = wissensbasierte Nutzer-Authentifizierung,
KeyRef = PIN.CH) ||
3
4
referenziert durch PrK.HP.AUT und PrK.HP.ENC in EF.PrK,
SE # 2
Anmerkung:
Die Zugriffsbedingungen für PIN.CH sind auf der MF-Ebene spezifiziert.
B.6 DF.CIA.ESIGN
In DF.CIA.ESIGN wird nur SE # 1 (voreingestelltes SE) genutzt.
Tabelle B.9 – CIA Files und ihre Eigenschaften
File
FID /
SFID
File
Struktur
File Größe
(Länge der Daten)
Zugriffsbedingung
EF.ARR
COS
linear variable
1 Record mit x Bytes
ARR # 1
Seite 74 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
EF.CIAInfo
(CIA Information)
EF.OD
(Objekt-Verzeichnis)
EF.AOD
(Authenth. Objekt-Verzeichnis)
EF.PrKD
(Private Key Verzeichnis)
EF.CD
(HP Zertifikats Verzeichnis)
spezifisch
‘5032’ /
18
‘5031’ /
17
‘5034’ /
20
‘5035’ /
21
‘5038’ /
22
transparent
transparent
transparent
transparent
transparent
256 Bytes
oder Länge der
64 Bytes
oder Länge der
128 Bytes
oder Länge der
128 Bytes
oder Länge der
128 Bytes
oder Länge der
ARR # 1
CIOs
ARR # 1
CIOs
ARR # 1
CIOs
ARR # 1
CIOs
ARR # 1
CIOs
Anmerkung:
SFID 19 wird nicht benutzt (siehe ISO/IEC 7816-15)
Tabelle B.10 – Zugriffsbedingungen in EF.ARR in DF.CIA.ESIGN
RecNr.
Wert
Bedeutung
1
’80 01 01
9000'
SC: Always
referenziert in EF.ARR, EF.CIAInfo, EF.OD, EF.AOD, EF.PrKD
und EF.CD
Seite 75 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Annex C
(normative)
Struktur und Inhalt der QES-Zertifikate
C.1 Zertifikat des öffentlichen Schlüssels für elektronische Signaturen (X.509v3
QES-Zertifikat)
C.1.1 Allgemeine Aspekte
Die Kodierung der HB-QES-Zertifikate muss mit den folgenden Vorgaben übereinstimmen:
• den standardisierten Kodierungs-Schemata für X.509v3-Zertifikate,
• den gesetzlichen Vorschriften des Signaturgesetzes (SigG) und der Signaturverordnung (SigV) in der jeweils gültigen Fassung und
• der ISIS-MTT-Spezifikation für interoperable PKI-Anwendungen (speziell Teil 1:
"Certificate and CRL Profiles" [ISIS-MTT P1], und dem optionalen Profil "SigGProfile" [ISIS-MTT OP]).
Felder im Zertifikat, die in den oben genannten Dokumenten, Regulierungen und Spezifikationen als verbindlich vorgeschrieben sind, müssen in den QES-Zertifikaten der Heilberufler
vorhanden sein. Zusätzlich sind wegen der vorgesehenen Nutzung der HB-QES-Zertifikate in
nationalen und internationalen Umgebungen weitere Felder in den Zertifikaten als verbindlich
gekennzeichnet.
Die QES-Zertifikate bestehen aus
• dem QES-Public-Key-Zertifikat und
• keinem, einem oder mehreren QES-Attributs-Zertifikaten.
Das QES-Public-Key-Zertifikat ist nachfolgend als eine Teilmenge der ISIS-MTTSpezifikation für Zertifikate beschrieben. Die Attributszertifikate sind in Kapitel C.7 beschrieben.
C.1.2 Zertifikatsstruktur
Die generelle Zertifikatsstruktur besteht aus drei verbindlichen Teilen:
• dem zu signierenden Zertifikatsinhalt
• dem Signatur-Algorithmus und
Seite 76 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
• der Signatur des Zertifikatsherausgebers
In ASN1-Notation wird die generelle Zertifikatsstruktur durch den Typ Certificate definiert, der
im Folgenden spezifiziert wird:
Certificate
tbsCertificate
signatureAlgorithm
signature
::=
SEQUENCE {
TBSCertificate,
AlgorithmIdentifier,
BIT STRING }
C.2 ToBeSignedCertificate
C.2.1 Generelle Struktur
Die generelle Struktur besteht aus den folgenden Feldern (ASN.1-Typ-Definition)
TBSCertificate
version
serialNumber
signature
issuer
validity
subject
subjectPublicKeyInfo
issuerUniqueID
subjectUniqueID
extensions
::=
SEQUENCE {
[0] EXPLICIT Version DEFAULT v1,
CertificateSerialNumber,
Name,
Validity,
Name,
SubjectPublicKeyInfo,
[1] IMPLICIT UniqueIdentifier OPTIONAL,
[3] EXPLICIT Extensions Optional }
Anmerkung:
In X.509-Zertifikaten sind Erweiterungen ("extensions") optional, aber für QES-Zertifikate sind einige Erweiterungen verbindlich vorgeschrieben. Die optionalen Erweiterungen issuerUniqueID und
subjectUniqueID , die in der ASN.1-Definition enthalten sind, dürfen nicht benutzt werden.
C.2.2 Version
Die Version kennzeichnet das Kodierschema eines Zertifikats
Die ASN.1-Definition für den Typ Version:
Version
::=
INTEGER { v1(0), v2(1), v3(2) }
Für QES-Zertifikate von Heilberuflern ist nur X.509v3 verbindlich.
Seite 77 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
C.2.3 Seriennummer
Die serialNumber identifiziert in Kombination mit den issuer-Namensfeldern der QESZertifikate ein ES-Zertifikat (RFC2459) eindeutig. Diese Anforderung an Eindeutigkeit ist in
[ISIS-MTT P1] auf alle Arten von Zertifikaten erweitert, d.h., sie gilt sowohl für ES als auch
für Attributszertifikate (ACs).
Die ASN.1-Definition des Typs CertificateSerialNumber für das Feld serialNumber:
CertificateSerialNumber
::=
INTEGER
Die Definition von [RFC2459] für Seriennummern erzwingt nicht den Wert oder die Länge
dieses Feldes. Trotzdem verlangt [RFC3280], dass die Seriennummer eine ganze positive
Zahl sein muss, die nicht länger als 20 Octets sein darf ( 1 <= SN < 2159, MSB=0 weist auf
das positive Vorzeichen hin!). Diese Anforderungen an die Länge gelten auch für [ISIS-MTT
P1] und müssen bei QES-Zertifikaten für Heilberufler berücksichtigt werden.
C.2.4 Signatur
Das Feld signature vom Typ AlgorithmIdentifier benennt den Signatur-Algorithmus, der von
der Certification Authority (CA) benutzt wurde, um dieses Zertifikat zu signieren. Sein Inhalt
muss mit dem des Feldes signatureAlgorithm (siehe C.3) übereinstimmen.
Die ASN.1 Definition des Typs AlgorithmIdentifier für das Feld signature:
Algorithmidentifier
algorithm
parameters
::=
SEQUENCE {
OBJECT IDENTIFIER,
ANY DEFINED BY algorithm OPTIONAL }
C.2.5 Herausgeber
Das Feld issuer vom Typ Name spezifiziert die CA, die das Zertifikat herausgegeben hat.
Die ASN.1 Definition des Typs Name für das Feld issuer:
Name
RDNSequence
::=
::=
CHOICE { RDNSequence }
SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::=
SET OF AttributeTypeAndValue
AttributeTypeAndValue
type
value
::=
SEQUENCE {
AttributeType,
AttributeValue }
AttributeType
::=
OBJECT IDENTIFIER
AttributeValue
::=
ANY DEFINED BY AttributeType
DirectoryString
printableString
::=
CHOICE {
PrintableString (SIZE (1..maxSize))
Seite 78 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
teletexString
utf8String
bmpString
universalString
TeletexString (SIZE (1..maxSize))
UTF8String (SIZE (1..maxSize))
BMPString (SIZE (1..maxSize))
UniversalString (SIZE (1..maxSize)) }
Für Attribute, die auf dem Typ Directory String basieren, müssen die folgenden Anmerkungen berücksichtigt werden:
• Eine druckbare Zeichenfolge (PrintableString) enthält Zeichen mit ASCIIKodierung, internationale Version
• Eine Teletex-Zeichenfolge (TeletexString) enthält Zeichen gemäß dem T.61Alphabet, mit dem spezifisch deutsche Zeichen wie Umlaute (ä, ö, ü) und ß kodiert werden können.
• Die UTF8-Kodierung, definiert in [RFC2279], ist die bevorzugte Option und muss
in allen Zertifikaten verwendet werden, die nach dem 31.Dezember 2003 herausgegeben werden. Bis zu diesem Termin können Zeichenfolgen gemäß den am
stärksten einschränkenden Regeln von PrintableString oder BMPString verwendet werden. TeletexString und UniversalString sind nur aus Gründen der Rückwärts-Kompatibilität aufgeführt worden und dürfen nicht für neue Zertifikate verwendet werden. [ISIS-MTT P1] empfiehlt die Nutzung einer Untermenge des
UTF8 Zeichensatzes, der nur die ANSI/ISO 8859-1 Zeichen enthält (Unicode Latin-1 page).
Bezogen auf die Attributs-Typen, die in dem Feld für den Herausgeber der HB-QESZertifikate in Übereinstimmung mit dieser Spezifikation genutzt werden dürfen, sind die folgenden Attribute zwingend vorgeschrieben:
• country name, und
• organization name.
Die Nutzung anderer Attributstypen, z.B. der Seriennummer, ist optional.
Das Kodier-Schema für alle Attributstypen issuer in den HB-QES-Zertifikaten ist in [ISIS-MTT
P1, Tabelle 7] definiert.
C.2.5.1 Country name
Der "country name" benennt das Land, in dem die CA ihren Stammsitz hat.
Die ASN.1 Definition des Attribut-Typs countryName:
id-at
::= { 2 5 4 }
id-at-countryName AttributeType ::= { id-at 6 }
CountryName
::= PRINTABLE STRING (SIZE(2))
Die druckbare Zeichenfolge des Ländernamens für Deutschland ist gemäß ISO 3166 "DE".
Seite 79 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
C.2.5.2 Organization name
Der "organization name" identifiziert die CA
Die ASN.1 Definition des Attribut-Typs organizationName:
id-at-organizationName AttributeType
::= { id-at 10 }
OrganizationName
::= DirectoryString (SIZE(1..64))
C.2.6 Validity
Das Feld "Validity" definiert die Gültigkeitsdauer des Zertifikates
Die ASN.1 Definition des Typs Validity
Validity
notBefore
notAfter
::=
SEQUENCE {
Time,
Time }
Time
utcTime
generalizedTime
::=
CHOICE {
UTCTime,
GeneralizedTime }
Gültigkeitsdaten bis 2049 müssen als UTCTime kodiert werden, Daten ab 2050 als GeneralizedTime. Die auswertende Software muss beide Formate interpretieren können. Datumsangaben müssen im folgenden Format erfolgen:
• YYMMDDhhmmssZ für UTCTime, und
• YYYYMMDDhhmmssZ für GeneralizedTime.
mit
-
Y = Jahr
M = Monat
D = Tag
h = Stunde
m = Minute
s = Sekunde
Z ist das Symbol für Greenwich Mean Time GMT.
Beispiel:
"20030101000000Z"
Seite 80 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Die maximale Gültigkeitsdauer wird von der CA festgelegt und folgt gesetzlichen Vorgaben,
die von der Stärke der benutzten Algorithmen abhängen.
C.2.7 Subject
Das Feld subject identifiziert den Zertifikatsinhaber im Sinne einer technischen Identifizierung. Die generelle Unterstruktur des Feldes subject ist Name, welcher identisch ist mit dem
im Feld issuer. Das Subjekt Name muss mindestens die Attribute commonName und
countryName enthalten.
In HB-QES-Zertifikaten, die dieser Spezifikation entsprechen, müssen die folgenden Attribute
vorhanden sein:
• countryName
• commonName.
Die Nutzung weiterer Attributstypen, die der ISIS-MTT-Spezifikation oder relevanten RFCs
entsprechen, ist optional
Das Kodierschema für diese subject-Attributstypen in HB-QES-Zertifikaten ist in [ISIS-MTT
P1, Tabelle 7] definiert.
C.2.7.1 Country name
Der "country name" identifiziert das Land, in dem der Zertifikatsinhaber angemeldet ist. Die in
Kapitel C.2.5.1 beschriebenen Regeln finden hier Anwendung.
C.2.7.2 State or province
"state" identifiziert das Bundesland, in dem der Zertifikatsinhaber angemeldet ist (z.B. Bayern
Die ASN.1 Definition des Attributtyps stateOrProvinceName:
id-at-StateOrProvinceName AttributeType ::= { id-at 8 }
StateOrProvinceName
Die bevorzugte Kodierungs-Variante für DirectoryString ist das UTF8-Subset, das nur ANSI/ISO 8859-1-Zeichen (Unicode Latin-1 page) enthält (siehe auch Anmerkungen in C.2.5).
C.2.7.3 Common name
Der "common name" spezifiziert den Namen einer Person in der Art, wie er normalerweise
benutzt wird. In qualifizierten Zertifikaten muss er den rechtsverbindlichen Namen des Karteninhabers enthalten.
Die ASN.1 Definition des Attributtyps commonName:
Seite 81 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
id-at-commonName AttributeType ::= { id-at 3 }
CommonName
Die bevorzugte Kodierungs-Variante für DirectoryString ist das UTF8-Subset, das nur ANSI/ISO 8859-1-Zeichen (Unicode Latin-1 page) enthält (siehe auch Anmerkungen in C.2.5).
Anmerkung:
Personenbezogene Daten, z.B. das Geschlecht einer Person, können in den Zertifikatserweiterungen subjectDirectoryAttributes spezifiziert werden (z.B. das Geschlecht im Attribut gender, siehe C.2.9.5).
Falls der commonName ein Pseudonym enthält, muss er mit den Zeichen":PN" enden. Um
zu erreichen, dass distinguished names eindeutig sind, darf eine CA dasselbe Pseudonym
nicht für verschiedene Personen nutzen. Die CA kann festlegen, dass die Pseudonyme
durch eine vorangestellte Zahl unterschieden werden: PN, z.B. CN = ”givenName surname
1:PN”. Ein Pseudonym sollte nur aus technischen und/oder rechtlichen Gründen verwendet
werden. Es sollte den surname und mindestens einen givenName des Zertifikatsinhabers
enthalten.
C.2.7.4 Serial number
Dieses Feld enthält eine Seriennummer, die von der CA zugewiesen wird, falls sie für die
Eindeutigkeit des Namens des "subject" notwendig ist.
Die ASN.1 Definition des Attributtyps serialNumber:
id-at-serialNumber AttributeType ::= { id-at 5 }
SerialNumber
::= PRINTABLE STRING (SIZE(1..64))
C.2.8 Subject public key info
Dieses Feld enthält den öffentlichen Schlüssel des Zertifikatsinhabers, z.B. des Heilberuflers,
zusammen mit dem Identifier des zugehörenden Algorithmus.
Die ASN.1 Definition des Attributtyps SubjectPublicKeyInfo:
SubjectPublicKeyInfo
algorithm
subjectPublicKey
::=
SEQUENCE {
BIT STRING }
AlgorithmIdentifier
algorithm
parameters
::=
SEQUENCE {
OBJECT IDENTIFIER,
Die OID für den Algorithmus kann im Prinzip folgende Eigenschaften kennzeichnen:
Seite 82 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
• den Signatur-Algorithmus (verbindlich),
• den Hash-Algorithmus (nicht verbindlich), und
• das Padding-Format, z.B. das DSI-Format (nicht verbindlich)
Software, die die Signatur prüfen soll, benötigt all diese Informationen; diese müssen aber
nicht zwingend durch einen OID im Zertifikat angegeben werden. In speziellen Umgebungen
(z.B. im Internet) können der Signatur-Algorithmus, das DSI-Format und der HashAlgorithmus (zusätzlich) in der Nachricht oder im Nachrichtenkopf angegeben sein. Da das
Vorhandensein nicht garantiert werden kann (speziell, wenn ein signiertes Dokument gespeichert wird, das diese Informationen nicht enthält), darf sich das nutzende System nicht
auf die Verfügbarkeit dieser Informationen verlassen. Zusätzlich wären diese Informationen
ungeschützt, wenn sie nicht in die Signatur des Nutzers einbezogen würden. Deshalb haben
diese Informationen auch keine Relevanz für die OIDs in einem Zertifikat.
Für den HBA sind relevant:
• der Signatur-Algorithmus RSA oder – in der Zukunft – ECDSA,
• der Hash-Algorithmus SHA-1 und Hash-Algorithmen der SHA-2-Familie (speziell
SHA-256),
• die Padding-Formate, z.B. die DSI-Formate PKCS#1 und ISO/IEC 9796-2rnd
Bei einer Prüfung muss als erstes der Signatur-Algorithmus bekannt sein und angewendet
werden; d.h., im Zertifikat muss die OID für den Signatur-Algorithmus enthalten sein.
Im Fall von RSA muss das Padding-Verfahren nach der Re-Transformation der Signatur im
Dekodierungsprozess angewendet werden. Da die definierten Padding-Verfahren einfach
unterschieden werden können (z.B. durch das erste Byte), gibt es keine Notwendigkeit für
eine Anzeige im OID.
Falls der Hash-Algorithmus im DSI angezeigt wird, kann die signierte Nachricht durch Nutzung des angegebenen Hash-Verfahrens gehasht werden und der berechnete Hashwert mit
dem im DSI angegebenen Hashwert verglichen werden. In diesem Fall sollte der OID des
Zertifikates den Hash-Algorithmus nicht anzeigen, um mehr Flexibilität zu erlauben. Die Angabe des Hash-Algorithmus wird von PKCS#1 unterstützt (die Digestinfo von PKCS#1 enthält den OID des Hash-Algorithmus) und die Anzeige des Hash-Algorithmus ist auch im DSIFormat ISO/IEC 9796-2rnd enthalten, wenn der Anhang von 2 Bytes benutzt wird.
Falls der Hash-Algorithmus nicht in der DSI angegeben ist, sollte der OID im Zertifikat den
Hash-Algorithmus zusätzlich zum Signatur-Algorithmus anzeigen.
Hieraus folgt als Konsequenz:
• in einem HBA mit RSA und DSI = PKCS#1 muss der OID nur RSA angeben.
• in einem HBA mit RSA und DSI = ISO/IEC 9796-2rnd (Anhang ‘BC’) muss der
OID RSA und den Hash-Algorithmus SHA-1 angeben.
Seite 83 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
• In einem HBA der die DSI-Formate PKCS#1 und ISO/IEC 9796-2rnd (Anhang
‘BC’) unterstützt, muss der OID RSA und den Hash-Algorithmus SHA-1 angeben
(DSI=PKCS#1 oder ISO/IEC 9796-2rnd (Anhang ‘BC’). Wenn PKCS#1 verwendet wird, muss der im OID angezeigte Hash-Algorithmus verwendet werden.
C.2.9 Extensions
Erweiterungen (extensions) können optional in X.509v3-Zertifikaten enthalten sein und für
die Aufnahme weiterer Informationen genutzt werden. Eine Erweiterung benötigt immer einen Object Identifier, um den Typ der Erweiterung identifizieren zu können. Die Bedeutsamkeit einer Erweiterung muss durch den Wert des Boolschen "criticality flags", "true" oder "false", definiert werden. "True" bedeutet, dass die Erweiterung angegeben sein und von einer
Anwendung verarbeitbar sein muss. Andernfalls wird das komplette Zertifikat bei der Prüfung
abgelehnt. Als Wert der Erweiterung wird eine Folge von Octets definiert.
Extensions
::=
SEQUENCE (1..MAX) OF Extension
Extension
extnId
critical
extnValue
::=
SEQUENCE {
OBJECT IDENTIFIER,
BOOLEAN DEFAULT FALSE,
OCTET STRING }
Für HB-DS-Zertifikate, die dieser Spezifikation entsprechen, sind die folgenden Kategorien
von Erweiterungen von Bedeutung:
• X.509 basic extensions
• private X.509 extensions für qualifizierte Zertifikate [RFC3039 ]
• private X.509 extensions aus [ISIS-MTT OP]
• private X.509 extensions von der BNA.
X.509 basic extensions beinhalten:
• basic constraints
• key usage
• certificate policies
• subject alternative name
• authority key identifier
• subject key identifier
• subject directory attributes
Seite 84 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
• CRL distribution points.
Diese "basic X.509 certificate extensions" werden durch den "initial object identifier arc" identifiziert.
id-ce OBJECT IDENTIFIER
::= { 2 5 29 }
private X.509 extensions für qualifizierte Zertifikate:
• qualified certificate statements
• authority information access.
Die "X.509 certificate extensions" werden durch den "initial object identifier arc" identifiziert:
id-pe OBJECT IDENTIFIER
::= { 1 3 6 1 5 5 7 1 }
ISIS-MTT SigG Private X.509 Extensions:
• admission
• restriction
• additional information
Die "ISIS-MTT SigG private X.509 certificate extensions" werden durch den "initial object
identifier arc" identifiziert:
id-isismtt OBJECT IDENTIFIER
::=
{ 1 3 36 8 }
id-isismtt-at OBJECT IDENTIFIER ::= { id-isismtt 3 }
Private X.509 Extensions der BNA:
• validity model.
C.2.9.1 Basic Constraints
In diesem Feld werden Beschränkungen definiert, die sich auf den Zertifikatsinhaber beziehen. Es muss angezeigt werden, dass ein Heilberufler keine Zertifikate herausgeben darf,
d.h., er kann nicht die Rolle einer CA übernehmen. Falls "basic constraints extension" in einem HB-Zertifikat genutzt werden, müssen sie als kritisch markiert werden und der Wert der
Komponente cA muss auf "false" gesetzt werden, falls er vorhanden ist.
id-ce-basicConstraints OBJECT IDENTIFIER
BasicConstraints
cA
::=
::=
{ id-ce 19 }
SEQUENCE {
Seite 85 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
pathLenConstraint
INTEGER (0..MAX) OPTIONAL }
C.2.9.2 Key usage (Schlüsselnutzung)
Dieses Feld spezifiziert die Nutzung der zertifizierten Public Keys:
Die ASN.1 Definition des Typs KeyUsage:
id-ce-keyUsage OBJECT IDENTIFIER ::=
KeyUsage
digitalSignature
nonRepudiation
keyEncipherment
DatenEncipherment
keyAgreement
keyCertSign
cRLSign
encipherOnly
decipherOnly
::=
{ id-ce 15 }
BIT STRING {
(0),
(1),
(2),
(3),
(4),
(5),
(6),
(7),
(8) }
Für HB-QES-Zertifikate ist nur der Wert nonRepudiation zulässig und muss gesetzt werden.
Die Schlüsselnutzung digitalSignature gilt für Authentifizierungs-Zertifikate. Diese werden in
Authentisierungsverfahren mit digitalen Signaturen im technischen Sinn und nicht wie die
personenbezogene Signatur mit rechtlicher Bedeutung genutzt. Die Erweiterung muss als
kritisch markiert werden.
C.2.9.3 Certificate Policies
In diesem Feld wird die Zertifikats-Policy definiert, die bei der Ausgabe des Zertifikates gültig
war. Die Erweiterung muss vorhanden sein, und sie muss als nicht kritisch markiert werden.
Die Werte müssen in Übereinstimmung mit [ISIS-MTT P1] eingetragen werden. Ältere Systeme nutzen die Erweiterung CertificatePolicies, um qualifizierte Zertifikate zu markieren,
damit ihre Komponenten diese erkennen können. Aus Gründen der vertikalen Interoperabilität sollten diese Erweiterungen vor dem Hintergrund, dass ihr Inhalt die Nutzbarkeit von Zertifikaten einschränken könnte, nicht als kritisch markiert werden. Da andererseits diese Information extrem wichtig für die rechtliche Gültigkeit von digitalen Signaturen ist, sollte sie
von SigG-konformen Komponenten ausgewertet werden.
Die ASN.1 Definition des Typs CertificatePolicies:
id-ce-certificatePolicies OBJECT IDENTIFIER
::= { id-ce 32 }
CertificatePolicies
::=
SEQUENCE SIZE (1..MAX) OF PolicyInformation
PolicyInformation
policyIdentifier
policyQualifiers
::=
SEQUENCE {
CertPolicyId,
SEQUENCE SIZE (1..MAX) OF
Seite 86 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
PolicyQualifierInfo OPTIONAL}
PolicyQualifierInfo
policyQualifierId
qualifier
::=
SEQUENCE {
PolicyQualifierId,
ANY DEFINED BY policyQualifierId }
CertPolicyId
::= OBJECT IDENTIFIER
-- isis-mtt branch for certificate policies
id-isismtt-cp OBJECT IDENTIFIER
::= { id-isismtt 1 }
id-isismtt-cp-accredited OBJECT IDENTIFIER
::= { id-isismtt-cp 1 }
C.2.9.4 Subject Alternative Name
Dieses Feld enthält einen oder mehrere „alternative technical names“ des ZertifikatsInhabers, z.B. eine eindeutige E-Mail-Adresse oder die eindeutige Internet-Adresse der Homepage des betreffenden Nutzers. Da das Feld subject den Kartenbesitzer eindeutig identifiziert, darf die Erweiterung SubjectAltNames nicht als kritisch markiert werden.
Die ASN.1 Definition des Typs SubjectAltName:
id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
SubjectAltName
::=
GeneralNames
GeneralNames
::=
SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralName
::=
otherName
rfc822Name
dNSName
x400Address
directoryName
ediPartyName
uniformResourceIdentifier
iPAddress
registeredID
CHOICE {
[0] IMPLICIT
[1] IMPLICIT
[2] IMPLICIT
[3] IMPLICIT
[4] EXPLICIT
[5] IMPLICIT
[6] IMPLICIT
[7] IMPLICIT
[8] IMPLICIT
OtherName
type-id
value
SEQUENCE {
OBJECT IDENTIFIER
[0] EXPLICIT ANY DEFINED type-id }
::=
OtherName,
IA5String,
IA5String,
ORAddress,
Name,
EDIPartyName,
IA5String,
OCTET STRING,
OBJECT IDENTIFIER }
ORAddress
::= SEQUENCE {
built-in-standard-attributes
ANY,
built-in-domain-defined-attributes SEQUENCE OF ANY OPTIONAL,
extension-attributes
SET OF ANY OPTIONAL }
EDIPartyName
NameAssigner
partyName
::=
SEQUENCE {
[0] EXPLICIT DirectoryString OPTIONAL,
[1] EXPLICIT DirectoryString }
Seite 87 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
In RFC822 ist die Konvention zur Bildung von E-Mail-Adressen definiert Ein Beispiel für eine
E-Mail-Adresse:
• "[email protected]"
C.2.9.5 Subject Directory Attributes
Diese Erweiterung kann zusätzliche Attribute des Karteninhabers enthalten. Qualifizierte Zertifikate können in dieser Erweiterung Daten rechtlich anerkannter Identifikationsmittel (z.B.
von Personalausweisen, Pässen o.ä.) enthalten. Diese optionale Erweiterung darf nicht als
Die ASN.1 Definition des Typs SubjectDirectoryAttributes:
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER
SubjectDirectoryAttributes ::= Attributes
::= { id-ce 9 }
Standard Attributes
Title Attribute
Durch X.520 definiertes optionales Attribut, das den Titel des Karteninhabers enthält.
id-at OBJECT IDENTIFIER
::=
id-at-title OBJECT IDENTIFIER
Title
::=
{ 2 4 5 }
::=
{ id-at 12 }
DirectoryString (SIZE(1..64))
"QC Private Extensions" [RFC3039] für persönliche Daten des Karteninhabers werden durch
den "initial object identifier arc" identifiziert:
id-pkix OBJECT IDENTIFIER ::=
id-pda OBJECT IDENTIFIER ::=
{ 1 3 6 1 5 5 7 }
{ id-pkix 9 }
Date of Birth Attribute
Optionales Attribut, das das Geburtsdatum des Karteninhabers enthält.
id-pda-dateOfBirth AttributeType ::=
{ id-pda 1 }
DateofBirth
::= GeneralizedTime
Place of Birth Attribute
Seite 88 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Optionales Attribut, das den Geburtsort des Karteninhabers enthält.
id-pda-placeOfBirth AttributeType
::=
{ id-pda 2 }
PlaceofBirth
Gender Attribute
Optionales Attribut, das das Geschlecht des Karteninhabers enthält.
id-pda-gender AttributeType
Gender
::=
::=
{ id-pda 3 }
PrintableString (SIZE(1)) – "M",F","m","f"
Country of Citizenship Attribute
Optionales Attribut, das die Nationen enthält, deren Staatsbürger der Karteninhaber zum
Zeitpunkt der Ausgabe des Zertifikates ist.
id-pda-countryOfCitizenship AttributeType
::= { id-pda 4 }
CountryOfCitizenship
::= PrintableString (SIZE(2)) – ISO 3166
Country of Residence Attribute
Optionales Attribut, das die Länder enthält, in denen der Karteninhaber einen Wohnsitz hat
id-pda-countryOfResidence AttributeType ::= { id-pda 5 }
CountryOfResidence
::= PrintableString (SIZE(2)) – ISO 3166
Name at Birth Attribute
Durch [ISIS-MTT P1] definiertes optionales Attribut, das den Geburtsnamen des Karteninhaber enthält.
id-isismtt-at-nameAtBirth OBJECT IDENTIFIER ::= { id-isismtt-at 14 }
NameAtBirth
C.2.9.6 Authority Key Identifier
Dieses Feld ist gemäß [ISIS-MTT P1] verbindlich und gibt die Referenz zum PK der CA an,
der zur Prüfung der CA-Signatur verwendet werden muss. Diese Erweiterung darf nicht als
Die ASN.1-Definition des Typs AuthorityKeyIdentifier:
Seite 89 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
AuthorityKeyIdentifier
::= SEQUENCE {
keyIdentifier
[0] IMPLICT KeyIdentifier
OPTIONAL,
authorityCertIssuer
[1] IMPLICIT GeneralNames
OPTIONAL,
authorityCertSerialNumber
[2] IMPLICIT CertificateSerialNumber
OPTIONAL }
KeyIdentifier
::= OCTET STRING
Anmerkung:
Beide Identifikationsmethoden, die in [RFC2459] beschrieben sind, können im selben Zertifikat
benutzt werden. [ISIS-MTT P1] fordert, dass das Feld keyIdentifier exakt dieselbe ID enthalten
muss wie der subjectKeyIdentifier des CA-Zertifikates (siehe C.2.9.7 weiter unten). Falls das Feld
authorityCertIssuer vorhanden ist, muss es genau ein directoryName-Element enthalten, das mit
dem subject DName des Zertifikates der ausgebenden CA gefüllt ist.
C.2.9.7 Subject Key Identifier
Dieses Feld enthält eine Referenz zum PK des Zertifikatsinhabers und ist gemäß ISIS-MTT
optional; seine Verwendung wird aber empfohlen. Der "subject key Identifier" in Form der
ICCSN (in Verbindung mit der key usage) kann in HBAs genutzt werden, die die Signaturprüfung auf der Basis gespeicherter PKs von bekannten Partnern unterstützen. Diese Erweiterung darf nicht als kritisch markiert werden.
Die ASN.1 Definition des Typs SubjectKeyIdentifier:
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER
SubjectKeyIdentifier
::= OCTET STRING
::= { id-ce 14 }
C.2.9.8 Authority Information Access
Die Erweiterung "Authority Information Access" enthält die URL des OCSP-Servers, der für
die Bereitstellung der Statusinformation über das Zertifikat verantwortlich ist. Diese Erweiterung darf nicht als kritisch markiert werden.
Die ASN.1 Definition des Typs AuthorityInfoAccess:
id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
AuthorityInfoAccessSyntax ::= SEQUENCE (1..MAX) OF AccessDescription
AccessDescription ::= SEQUENCE {
accessMethod
accessLocation
OBJECT IDENTIFIER
GeneralName }
Seite 90 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Der OID-Wert id-ad-ocsp {id-ad 1} nutzt die Komponente accessMethod, um den OCSPService anzuzeigen. Die OCSP-URL wird im Feld accessLocation angegeben.
C.2.9.9 Validity Model
Die von der BNA vorgegebene "private extension" Gültigkeitsmodell benennt das Prüfverfahren, welches benutzt werden muss, um die Gültigkeit des Zertifikates zu überprüfen. Die Erweiterung darf nicht als kritisch markiert werden.
Mögliche Werte sind id-validityModel-chain {1.3.6.1.4.1.8301.3.5.1} für das Kettenmodell,
das von der BNA vorgeschrieben wird, und id-validityModel-shell {1.3.6.1.4.1.8301.3.5.2} für
das Schalenmodell, das von PKIX genutzt wird.
Weitere Gültigkeitsmodelle, z.B. Hybrid-Modelle, sind ebenfalls möglich. Informationen über
die Gültigkeitsmodelle können im Internet gefunden werden:
• BNA: http://www.bundesnetzagentur.de/media/archive/1343.pps
• OIDs: http://www.informatik.tu-darmstadt.de/TI/Forschung/ FlexiPKI/validity model/index.html
Die ASN.1-Definition des Typs ValidityModel:
id-validityModel OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 8301 3 5 }
id-validityModel-chain {1 3 6 1 4 1 8301 3 5 1} -- yet without validityModelInfo.
id-validityModel-shell {1.3.6.1.4.1.8301.3.5.2} -- yet without validityModelInfo.
ValidityModel::= SEQUENCE {
validityModelId
OBJECT IDENTIFIER
validityModelInfo
ANY DEFINED BY validityModelID OPTIONAL }
C.2.9.10 Qualified Certificate Statements
Dieses Feld zeigt an, dass das Zertifikat ein qualifiziertes Zertifikat im Umfeld eines bestimmten rechtlichen Systems ist. Aufgrund der Festlegungen für Zertifikats-Policies (siehe
C.2.9.3) soll diese Erweiterung nicht als kritisch markiert werden.
Die ASN.1 Definition des Typs QCStatements:
id-pe-qcStatements OBJECT IDENTIFIER
::= { id-pe 3 }
QCStatements
::= SEQUENCE OF QCStatement
QCStatement
statementId
::=
SEQUENCE {
OBJECT IDENTIFIER,
Seite 91 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
statementInfo
ANY DEFINED BY statementId OPTIONAL }
Vordefiniertes QC-Statement [RFC3039]
id-qcs OBJECT IDENTIFIER ::= { 1 3 6 1 5 5 7 11 }
id-qcs-pkixQCSyntax-v1 OBJECT IDENTIFIER
::= { id-qcs 1 }
Dieser OID muss als statementId genutzt werden, um die Übereinstimmung mit der in
[RFC3039] definierten Syntax und Semantik anzuzeigen. Er bezieht sich auf den Datentyp
SemanticsInformation weiter unten.
SemanticsInformation
::= SEQUENCE {
semanticsIdentifier
OBJECT IDENTIFIER OPTIONAL,
nameRegistrationAuthorities NameRegistrationAuthorities OPTIONAL }
NameRegistrationAuthorities
::=
SEQUENCE SIZE(1..MAX) OF GeneralName
Der semanticsIdentifier soll einen OID enthalten, der die Semantik für Attribute und Namen in
Zertifikatsfeldern definiert.
Das Feld nameRegistrationAuthorities muss den Namen einer oder mehrerer Registrierungsstellen (registration authorities) enthalten, die für die Registrierung von Attributen und
Namen zuständig sind, die mit dem "subject" verbunden sind.
Einige registeredIDs für Semantik oder für eine Zertifikats-Policy können hier zu finden sein
Anmerkung:
[RFC3039] fordert, dass zumindest einer der beiden Werte semanticsIdentifier und nameRegistrationAuthorities vorhanden sein muss.
ETSI QC Statements
Übereinstimmung mit der EU-Direktive
id-etsi-qcs OBJECT IDENTIFIER ::=
{ 0 4 0 1862 1 }
id-etsi-qcs-QcCompliance OBJECT IDENTIFIER ::= {id-etsi-qcs 1}
Dieser OID muss als statementId genutzt werden, um zu zeigen, dass das Zertifikat in Übereinstimmung mit der EU-Direktive [ECDIR] herausgegeben wurde, so wie diese in dem Land
umgesetzt wurde, in dem die herausgebende CA ihren Sitz hat. Wenn diese OID eingetragen wird, ist das Feld statementInfo zu überspringen.
Seite 92 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Begrenzung des Wertes einer Transaktion
id-etsi-qcs-QcLimitValue OBJECT IDENTIIFER ::= {id-etsi-qcs 2}
Dieser OID muss als statementId in Verbindung mit dem QcEuLimitValue-Statement wie
unten angegeben genutzt werden.
QcEuLimitValue
::=
MonetaryValue
MonetaryValue
currency
amount
exponent
::=
SEQUENCE {
Iso4217CurrencyCode,
INTEGER,
INTEGER }
Iso4217CurrencyCode
alphabetic
numeric
::=
CHOICE {
PrintableString,
INTEGER(1..999) }
Der Wert des Limits einer Transaktion wird durch den Betrag * 10exponent angegeben.
Retention Period
CAs oder zugelassene Registrierungsstellen speichern detaillierte Daten über den Inhaber
eines qualifizierten Zertifikates. Diese Daten erlauben die eindeutige Identifikation der Person im Fall eines Streits.
id-etsi-qcs-QcRetentionPeriod OBJECT IDENTIIFER ::= {id-etsi-qcs 3}
Dieser OID muss als statementId in Verbindung mit dem QcRetentionPeriod wie unten angegeben genutzt werden.
QcRetentionPeriod
::=
INTEGER
Dieses Feld zeigt an, für wie viele Jahre nach Ablauf des Zertifikates die persönlichen Daten
des Zertifikatsinhabers gespeichert bleiben.
C.2.9.11 CRL Distribution Points
Dies Feld bestimmt, wie CRL-Informationen erhalten werden können. Die Erweiterung sollte
als nicht kritisch markiert werden.
Seite 93 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Die ASN.1 Definition des Typs CRLDistributionPoints
id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 }
CRLDistributionPoints
::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
DistributionPoint
distributionPoint
reasons
cRLIssuer
::=
SEQUENCE {
[0] DistributionPointName OPTIONAL,
[1] ReasonFlags OPTIONAL,
GeneralNames OPTIONAL }
DistributionPointName
::=
fullName
nameRelativeToCRLIssuer
CHOICE {
[0] GeneralNames,
RelativeDistinguishedName }
ReasonFlags
unused
keyCompromise
cACompromise
affiliationChanged
superseded
cessationOfOperation
certificateHold
priveledgeWithdrawn
aACompromise
BIT STRING {
(0),
(1),
(2),
(3),
(4),
(5),
(6),
(7),
(8) }
::=
Dieses Feld ist gemäß [ISIS-MTT P1] verpflichtend, falls indirekte CRLs veröffentlicht werden, und es sollte vorhanden sein, falls direkte CRLs veröffentlicht werden.
C.2.9.12 Professional Admission
Zulassungs-Informationen für Heilberufler können im Basis-QES-Zertifikat durch die Nutzung
der in [ISIS-MTT OP] aufgeführten "private extension" admission vom Typ AdmissionSyntax
angegeben werden, oder in einem oder mehreren Attributszertifikaten durch die Nutzung des
Attributs admission, das auch vom Typ AdmissionSyntax ist, ebenfalls wie in [ISIS-MTT OP]
definiert. Die Entscheidung, welche dieser Möglichkeiten genutzt wird, muss von der jeweils
zuständigen Organisation (Kammer) getroffen werden.
Die ASN.1 Definition des Typs AdmissionSyntax:
id-isismtt-at-admission OBJECT IDENTIFIER
id-isismtt-at-namingAuthorities OBJECT IDENTIFIER
AdmissionSyntax
admissionAuthority
contentsOfAdmissions
::=
::= { isismtt-at 3 }
::= { isismtt-at 11 }
SEQUENCE {
GeneralName OPTIONAL,
SEQUENCE OF Admissions}
Seite 94 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Admissions
admissionAuthority
namingAuthority
professionInfos
::=
SEQUENCE {
[0] EXPLICT GeneralName OPTIONAL,
[1] EXPLICIT NamingAuthority OPTIONAL,
SEQUENCE OF ProfessionInfo}
NamingAuthority
namingAuthorityId
namingAuthorityUrl
namingAuthorityText
::=
SEQUENCE {
IA5String OPTIONAL,
DirectoryString (SIZE(1..128)) OPTIONAL }
ProfessionInfo
namingAuthority
professionItems
professionOIDS
registrationNumber
addProfessionInfo
::=
SEQUENCE {
[0] EXPLICT NamingAuthority OPTIONAL,
SEQUENCE OF DirectoryString (SIZE(1..128)),
SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
PrintableString (SIZE(1..128)) OPTIONAL,
OCTET STRING OPTIONAL }
Die Bestandteile der relativ komplexen Struktur der AdmissionSyntax unterstützen die folgenden Konzepte und Anforderungen:
• Das Datenfeld admissionAuthority wird genutzt, um die Organisation zu benennen, die für die Zuweisung von Werten der zugehörigen Elemente verantwortlich
ist. Zulassungsstellen sind Institutionen (z.B. Verbände, Kammern, Vereinigungen, Administrative Einheiten, Firmen, etc.), die verantwortlich für die Erteilung
und Prüfung von Zulassungen sind. Eine Zulassungsstelle wird durch ein Objekt
GeneralName benannt (siehe C.2.9.4).
• Das Datenfeld namingAuthority wird genutzt, um Namen von Organisationen zu
benennen, die für die Führung von Titelregistern zuständig sind. Diese Organisationen definieren Kodierungslisten und zulässige Werte für spezifische Berufsgruppen. Der Name einer bestimmten Organisation kann durch einen object identifier im Feld namingAuthorityId , durch Text im Feld namingAuthorityText, durch
Angabe einer URL im Feld namingAuthorityUrl oder durch eine Kombination dieser Möglichkeiten angegeben werden. Zum Beispiel kann der Text den Namen,
der Organisation, das Land, in dem sie tätig ist und den Namen des Registers
enthalten. Die Option einer URL bezieht sich auf eine Web-Seite, die Listen von
"offiziell" eingetragenen Berufsbezeichnungen und zusätzliche Informationen zu
diesen Berufsgruppen enthält (Text und möglicherweise OIDs). Object identifier
für die Komponente namingAuthorityId gehören zu dem OID-Zweig id-isis-atnamingAuthorities. Die Registrierung neuer OIDs muss bei TeleTrusT beantragt
werden.
• Der Datentyp ProfessionInfo wird benutzt, um bestimmte Berufe, Qualifikationen,
Fachgebiete oder Betätigungsfelder zu benennen. Ein Element wird durch einen
oder mehrere Textbausteine, die zugehörigen Berufs-OIDs in den Feldern professionItems und professionOIDs und durch eine Registrierungsnummer im Feld
registrationNumber charakterisiert. Eine Bezeichnung in Textform ist immer erforderlich, während die anderen Indikatoren optional sind. Die Komponente
Seite 95 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
addProfessionInfo kann zusätzliche anwendungsbezogene Informationen (DERkodiert) enthalten.
Durch die Nutzung verschiedener namingAuthority-OIDs oder Berufs-OIDs können Hierarchien für Berufe, Qualifikationen, Fachgebiete oder Betätigungsfelder aufgebaut werden. Die
verantwortliche Zulassungsinstanz sollte immer im Feld admissionAuthority aufgeführt werden, wenn eine Registrierungsnummer angegeben wird. Die Information über eine Zulassung kann allerdings auch ohne die Nennung einer Zulassungsinstanz durch die alleinige
Nutzung der Komponente professionItems.gegeben werden. In diesem Fall ist die jeweilige
Zulassungsinstanz für die Prüfung der Zulassungsinformation zuständig.
Das Berufsattribut admission beinhaltet nur einen Wert. Dennoch können mehrere Zulassungen in der sequentiellen Struktur der Komponente contentsofAdmissions von AdmissionSyntax oder in der Komponente professionInfos von Admissions zusammengefasst werden.
Die Komponente admissionAuthority von AdmissionSyntax wird als Anfangswert für die
Komponente admissionAuthority von Admissions genutzt. Dieser Anfangswert kann überschrieben werden, falls eine andere Organisation zuständig ist.
Die Komponente namingAuthority von Admissions wird als Anfangswert für die Komponente
namingAuthority von ProfessionInfo genutzt. Dieser Anfangswert kann überschrieben werden, falls eine andere Organisation festgelegt werden muss.
Die Länge eines Objektes ist auf 128 Zeichen begrenzt. Es wird empfohlen, in allen ausgegebenen Attributszertifikaten eine namingAuthorityURL anzugeben. Falls eine namingAuthorityURL angegeben ist, sollte das Feld professionItems von ProfessionInfo nur registrierte
Titel enthalten. Falls das Feld professionOIDs vorhanden ist, muss es die OIDs der Berufsgruppen, die in professionItems aufgeführt sind, in derselben Reihenfolge enthalten. Im Allgemeinen sollte das Feld professionInfos nur einen Eintrag enthalten, es sei denn, die Zulassungen, die aufgeführt werden sollen, sind logisch miteinander verbunden (z.B., sie sind
unter derselben Zulassungsnummer veröffentlicht).
Berufs-OIDs sollen immer unter dem OID-Zweig der verantwortlichen Namensvergabeinstanz vergeben werden.
Wie schon erwähnt: die Entscheidung, wo die berufsbezogenen Informationen zu integrieren
sind, wird von den für die Berufsgruppen zuständigen Organisationen getroffen. Die folgenden Mindestanforderungen sind durch die Verbände der Ärzte und der Apotheker definiert:
Seite 96 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Berufsgruppe "Ärzte":
Im Basis-QES-Zertifikat muss angegeben werden, dass der Inhaber des Zertifikates ein Arzt
ist. Die Mindestinformation, die in der Erweiterung admission des Basiszertifikates angegeben sein muss, ist "PHYSICIAN" in der Komponente professionItems von AdmissionSyntax.
{ ..., professionItems {"Ärztin/Arzt"}, ... }
Anmerkung:
Diese und weitere berufsspezifische Informationen können in einem Attributszertifikat für Qualifikationen (siehe C.7.1) oder in einem Attributszertifikat für Autorisierungen (siehe C.7.2) bereitgestellt werden.
Berufsgruppe "Apotheker":
Im Basis-QES-Zertifikat muss die Qualifikation des Karteninhabers enthalten sein, d.h., es
muss ersichtlich sein, ob der Karteninhaber "Apotheker", "Apothekerassistent", "Pharmazieingenieur", "PTA", “PKA/Helferin", "Apothekenassistent", "Pharmazeutische Assistentin", "Apothekenfacharbeiter", "Pharmaziepraktikant", "Stud.pharm. oder Famulant", "PTAPraktikant" oder "Azubi" ist
Zum Beispiel muss bei einem "Apotheker" mindestens die Bezeichnung "Apotheker" in professionItems enthalten sein.
{ ..., professionItems {"Apotheker"}, ... }
Anmerkung:
Weitere berufsgruppenspezifische Informationen können in dieser Erweiterung des Basis-QESZertifikats oder im Attribut admission in einem oder in mehreren Attributszertifikaten (siehe C.7)
enthalten sein.
Neben der Benennung der Qualifikation des Karteninhabers hat die Berufsgruppe "Apotheker" die folgenden Kategorien für zusätzliche Berufs-Informationen festgelegt:
-
Kategorie "Tätigkeitsbereich"
Kategorie "berufliche Rolle"
Kategorie "Fachapothekereigenschaft"
Kategorie "Zusatzqualifikationen zu Fachapothekereigenschaft"
Kategorie "Fach-PTA-Eigenschaft" und
Kategorie "Zugehörigkeit zu Kammern und Fachorganisationen"
Konkrete Werte für die verschiedenen Kategorien, deren Speicherung in der Erweiterung
admission des Basis-QES-Zertifikats erlaubt sind, werden in einem separaten Dokument
beschrieben.
Seite 97 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Das folgende Beispiel soll zeigen, wie detaillierte berufsspezifische Zusatzinformationen in
die Erweiterung admission des Basis-QES-Zertifikats integriert werden können. Es ist anzumerken, dass die Informationen auch in das Attribut admission des Attributszertifikates eingefügt werden können.
{ admissionAuthority "NameOfAuthorityResponsibleForCompleteContent",
contentsOfAdmissions {
admission_1 {
admissionAuthority "NameOfAuthorityResponsibleForContentOfAdmission1",
namingAuthority {
namingAuthorityId id-OIDOfNamingAuthority,
namingAuthorityUrl "URLToListOfQualifications",
namingAuthorityText "NameOfAuthority" },
professionInfos {
professionInfo {
professionItems { "Apotheker" } } } },
admission_2 {
professionInfos {
professionInfo {
namingAuthority {
namingAuthorityUrl "URLToListOfProfessionalRole" },
professionItems {"Apothekenleiter" } } } } } }
C.2.9.13 Restriction
Diese optionale Erweiterung zeigt Beschränkungen für die Nutzung des Zertifikates an. Die
Organisation einer Berufsgruppe, die für die Zertifikatsinhalte verantwortlich ist, kann entscheiden, die Nutzung der Zertifikate auf den Gesundheitssektor zu beschränken. Falls vorhanden, darf diese Erweiterung nicht als kritisch markiert werden.
Die ASN.1 Definition des Typs Restriction:
id-isismtt-at-restriction OBJECT IDENTIFIER ::= {isismtt-at 8}
RestrictionSyntax ::= DirectoryString (SIZE(1..1024))
Die Kodierung des DirectoryString erfolgt in UTF-8.
C.2.9.14 Additional Information
Diese optionale Erweiterung zeigt zusätzliche nicht-beschränkende Informationen für die
Nutzung des Zertifikates an. Die Organisation einer Berufsgruppe, die für die Zertifikatsinhal-
Seite 98 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
te verantwortlich ist, kann entscheiden, zusätzliche Informationen wie “Dieses Zertifikat gehört zu einer zugelassenen ID-Karte aus dem Bereich Medizin, herausgegeben durch die
zuständige lokale Kammer" oder “Zertifikat als Teil eines elektronischen Arztausweises, herausgegeben durch die zuständige Landesärztekammer” hinzuzufügen. Falls vorhanden, darf
diese Erweiterung nicht als kritisch markiert werden.
Die ASN.1 Definition des Typs AdditionalInformation:
id-isismtt-at-additionalInformation OBJECT IDENTIFIER ::= {isismtt-at 15}
AdditionalInformationSyntax ::= DirectoryString (SIZE(1..2048))
Die Kodierung des DirectoryString erfolgt in UTF-8.
C.3 Signature algorithm
Dieses Feld enthält dieselbe Kodierung wie das Signaturfeld in der “to be signed sequence”.
C.4 Signature
Dieses Feld enthält die Signatur der CA, die das Zertifikat herausgegeben hat.
C.5 QES-Zertifikat in Tabellenform und mit kompletter Syntax
Die folgende Tabelle zeigt das QES-Zertifikat in Tabellenform. Es werden nur die Felder aufgeführt, die für das QES-Zertifikat eines Heilberuflers von Bedeutung sind. In einem solchen
Zertifikat sind alle die Felder, die gemäß ISIS-MTT verbindlich sind, auch für ein HB-QESZertifikat als verbindlich gekennzeichnet. Ein Kreuz in der Spalte ISIS-MTT und HBA gibt an,
dass das zugehörende Feld verbindlich ist.
Seite 99 von 144
Version: 2.1.0 de
Stand: 28.5.2006
Heilberufs-Ausweis
und
Zertifikatsfeld
Inhalt
ISIS-MTT
HPC
version
serialNumber
signature
issuer
X.509v3
Serial number of certificate
Algorithm identifier for CA signature
Certification authority
DE for Germany
e.g. DEZGW for German CA in health care
Validation period
Generalized Time
Generalized Time
Certificate holder
DE for Germany
Name of German state
Common name in its full form
Serial number for unique naming of subject
PK Daten
OID of algorithm incl. parameters if any
Coding of PK with modulus and publicExponent
Extensions
Classification as end user certificate
nonRepudiation, i.e. usage of certificate restricted to
digital signatures according to SigG requirement
Indication of SigG Conformance
alternative technical name with possibly e-Mail address
of certificate holder
X.500 attributes for additional personal Daten as for
example date of birth, place of birth, gender, country of
citizenship, country of residence, and name at birth
Reference to PK of the CA for verification of the CA
signature
Reference to PK of the certificate holder
Identification of how and where information about the
status of the certificate can be obtained
Information about the mechanisms that must be used in
order to prove the validity of the certificate
Indication that the certificate is a qualified certificate,
and where applicable monetary limit of transactions
Identification of how CRL information can be obtained
Professional admission information
Other restrictions regarding the usage of the certificate
Non-restrictive information regarding the usage of the
certificate
Algorithm identifier for CA signature
(Value identical to signature field in Certificate Content)
Signature of CA
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
countryName
organizationName
validity
notBefore
notAfter
subject
countryName I
stateOrProvince
commonName (CN)
serialNumber
algorithm
subjectPublicKey
extensions
basicConstraints
keyUsage
certificatePolicies
subjectAltName
subjectDirectoryAttributes
authorityKeyIdentifier
subjectKeyIdentifier
authorityInfoAccess
validityModel
qcStatements
cRLDistributionPoints
admission
restriction
additionaInformation
signatureAlgorithm
signature
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Tab. C.1: Inhalt des QES-Zertifikats eines Heilberuflers
Version: 2.1.0 de
Seite 100 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
Im Folgenden ist die Syntax eines QES-Zertifikats angegeben:
-- certificate
Certificate
tbsCertificate
signatureAlgorithm
signature
::=
SEQUENCE {
TBSCertificate,
BIT STRING }
-- to be signed certificate
TBSCertificate
::=
version
serialNumber
signature
issuer
validity
subject
issuerUniqueID
subjectUniqueID
extensions
SEQUENCE {
[0] EXPLICIT Version DEFAULT v1,
Name,
Validity,
Name,
SubjectPublicKeyInfo,
[3] EXPLICIT Extensions Optional }
-- version
Version
::=
INTEGER { v1(0), v2(1), v3(2) }
-- serial number
CertificateSerialNumber
::=
INTEGER
::=
SEQUENCE {
OBJECT IDENTIFIER,
-- signature
Algorithmidentifier
algorithm
parameters
-- issuer
Name
::=
CHOICE { RDNSequence }
RDNSequence
::=
SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::=
SET OF AttributeTypeAndValue
AttributeTypeAndValue
type
value
::=
SEQUENCE {
AttributeType,
AttributeValue }
AttributeType
::=
OBJECT IDENTIFIER
AttributeValue
::=
ANY DEFINED BY AttributeType
-- directory string
Version: 2.1.0 de
Seite 101 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
DirectoryString
printableString
teletexString
utf8String
bmpString
universalString
::=
-- country name attribute
CountryName
::=
CHOICE {
PrintableString (SIZE (1..maxSize))
TeletexString (SIZE (1..maxSize))
UTF8String (SIZE (1..maxSize))
BMPString (SIZE (1..maxSize))
UniversalString (SIZE (1..maxSize)) }
PRINTABLE STRING (SIZE(2))
-- organization name attribute
OrganizationName
-- validity
Validity
notBefore
notAfter
Time
utcTime
generalizedTime
::=
SEQUENCE {
Time,
Time }
::=
CHOICE {
UTCTime,
GeneralizedTime }
-- state or province name attribute
StateOrProvinceName
-- common name attribute
CommonName
::=
-- serial number attribute
SerialNumber
::=
PRINTABLE STRING (SIZE(1..64))
-- subject public key info
SubjectPublicKeyInfo
::=
algorithm
subjectPublicKey
SEQUENCE {
BIT STRING }
-- extensions
Extensions
Extension
extnId
critical
extnValue
SEQUENCE (1..MAX) OF Extension
SEQUENCE {
OBJECT IDENTIFIER,
OCTET STRING }
::=
::=
-- basic constraints extenion
BasicConstraints
::= SEQUENCE {
cA
pathLenConstraint
INTEGER (0..MAX) OPTIONAL }
-- key usage extenion
KeyUsage
::=
Version: 2.1.0 de
BIT STRING {
Seite 102 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
digitalSignature
nonRepudiation
keyEncipherment
DatenEncipherment
keyAgreement
keyCertSign
cRLSign
encipherOnly
decipherOnly
(0),
(1),
(2),
(3),
(4),
(5),
(6),
(7),
(8) }
-- certificate policies extension
CertificatePolicies
::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
PolicyInformation
policyIdentifier
policyQualifiers
::=
SEQUENCE {
CertPolicyId,
SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL}
PolicyQualifierInfo
policyQualifierId
qualifier
::=
SEQUENCE {
PolicyQualifierId,
ANY DEFINED BY policyQualifierId }
CertPolicyId
::=
OBJECT IDENTIFIER
-- subject alternative name extension
SubjectAltName
::= GeneralNames
GeneralNames
::=
GeneralName
::=
otherName
rfc822Name
dNSName
x400Address
directoryName
ediPartyName
uniformResourceIdentifier
iPAddress
registeredID
OtherName
type-id
value
SEQUENCE SIZE (1..MAX) OF GeneralName
CHOICE {
[0] IMPLICIT
[1] IMPLICIT
[2] IMPLICIT
[3] IMPLICIT
[4] EXPLICIT
[5] IMPLICIT
[6] IMPLICIT
[7] IMPLICIT
[8] IMPLICIT
OtherName,
IA5String,
IA5String,
ORAddress,
Name,
EDIPartyName,
IA5String,
OCTET STRING,
OBJECT IDENTIFIER }
:: = SEQUENCE {
OBJECT IDENTIFIER
[0] EXPLICIT ANY DEFINED type-id }
ORAddress
:: = SEQUENCE {
built-in-standard-attributes
ANY,
built-in-domain-defined-attributes SEQUENCE OF ANY OPTIONAL,
extension-attributes
SET OF ANY OPTIONAL }
EDIPartyName
:: = SEQUENCE {
nameAssigner [0] EXPLICIT DirectoryString OPTIONAL,
Version: 2.1.0 de
Seite 103 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
partyName [1] EXPLICIT DirectoryString }
-- subject directory attributes extension
SubjectDirectoryAttributes ::= Attributes
Title
::=
DateOfBirth
::=
GeneralizedTime
PlaceOfBirth
::=
Gender
::=
PrintableString (SIZE(1)) – "M",F","m","f"
CountryOfCitizenship
::=
PrintableString (SIZE(2)) – ISO 3166
CountryOfResidence
NameAtBirth
::=
::=
PrintableString (SIZE(2)) – ISO 3166
-- authority key identifier extension
AuthorityKeyIdentifier
::= SEQUENCE {
keyIdentifier
[0] IMPLICT KeyIdentifier
OPTIONAL,
authorityCertIssuer
[1] IMPLICIT GeneralNames
OPTIONAL,
authorityCertSerialNumber
[2] IMPLICIT
CertificateSerialNumber OPTIONAL}
KeyIdentifier
::= OCTET STRING
-- subject key identifier extension
SubjectKeyIdentifier
::= OCTET STRING
-- qualified certificate statements extension
QCStatements
::= SEQUENCE OF QCStatement
QCStatement
statementId
statementInfo
::=
SEQUENCE {
OBJECT IDENTIFIER,
ANY DEFINED BY statementId OPTIONAL }
-- predefined RFC3039 qualified certificate statements
SemanticsInformation
::= SEQUENCE {
semanticsIdentifier
nameRegistrationAuthorities
NameRegistrationAuthorities OPTIONAL }
NameRegistrationAuthorities
::=
SEQUENCE SIZE(1..MAX) OF GeneralName
-- ETSI QC statement on limitation of transaction value
QcEuLimitValue
::= MonetaryValue
MonetaryValue
currency
amount
::=
Version: 2.1.0 de
SEQUENCE {
Iso4217CurrencyCode,
INTEGER,
Seite 104 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
exponent
INTEGER }
Iso4217CurrencyCode
::= CHOICE {
alphabetic
PrintableString,
numeric
INTEGER(1..999) }
-- ETSI QC statement on retention period
QcRetentionPeriod
::= INTEGER
-- CRL distribution points extension
id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 }
CRLDistributionPoints
::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
DistributionPoint
distributionPoint
reasons
cRLIssuer
::=
SEQUENCE {
[0] DistributionPointName OPTIONAL,
[1] ReasonFlags OPTIONAL,
[2] GeneralNames OPTIONAL }
DistributionPointName
::=
fullName
nameRelativeToCRLIssuer
CHOICE {
[0] GeneralNames,
[1] RelativeDistinguishedName }
ReasonFlags
unused
keyCompromise
cACompromise
affiliationChanged
superseded
cessationOfOperation
certificateHold
priveledgeWithdrawn
aACompromise
BIT STRING {
(0),
(1),
(2),
(3),
(4),
(5),
(6),
(7),
(8) }
::=
AuthorityInfoAccessSyntax ::= SEQUENCE (1..MAX) OF AccessDescription
AccessDescription ::= SEQUENCE {
accessMethod OBJECT IDENTIFIER
accessLocation
GeneralName }
-- ISIS-MTT private extenstion/attribute admission
AdmissionSyntax
::= SEQUENCE {
admissionAuthority
GeneralName OPTIONAL,
contentsOfAdmissions
SEQUENCE OF Admissions}
Admissions
admissionAuthority
namingAuthority
professionInfos
::= SEQUENCE {
[0] EXPLICT GeneralName OPTIONAL,
[1] EXPLICIT NamingAuthority OPTIONAL,
SEQUENCE OF ProfessionInfo}
NamingAuthority
NamingAuthorityId
namingAuthorityUrl
::=
Version: 2.1.0 de
SEQUENCE {
IA5String OPTIONAL,
Seite 105 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
namingAuthorityText
DirectoryString (SIZE(1..128)) OPTIONAL }
ProfessionInfo
namingAuthority
professionItems
professionOIDS
registrationNumber
addProfessionInfo
::=
SEQUENCE {
[0] EXPLICT NamingAuthority OPTIONAL,
SEQUENCE OF DirectoryString (SIZE(1..128)),
SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
PrintableString (SIZE(1..128)) OPTIONAL,
OCTET STRING OPTIONAL }
ValidityModel
::= SEQUENCE {
validityModelId
OBJECT IDENTIFIER
validityModelInfo
ANY DEFINED BY validityModelID OPTIONAL }
RestrictionSyntax
AdditionalInformationSyntax ::= DirectoryString (SIZE(1..2048))
Version: 2.1.0 de
Seite 106 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
C.6 Object Identifier, die in dieser Spezifikation verwendet werden
Die nachfolgende Tabelle zeigt die relevanten Object Identifier.
Tabelle C.2 – Überblick über OIDs
Object Identifier
Bedeutung
Name
Wert
id-at
{254}
Zweig für X.500 Attribute
id-at-title
{ 2 5 4 12 }
Titel
id-ce
{ 2 5 29 }
Zweig für Zertifikats-Erweiterungen
id-ce-subjectDirectoryAttributes
{ id-ce 9 }
in diesem Feld werden zusätzliche X.500-Attribute des Karteninhabers zur Verfügung gestellt, die zur rechtlich verbindlichen
Identifizierung genutzt werden können
id-ce-subjectKeyIdentifier
{ id-ce 14 }
bezeichnet das Zertifikat des Karteninhabers, das einen spezifischen PuK enthält
id-ce-keyUsage
{ id-ce 15 }
bezeichnet den Verwendungszweck des privaten Schlüssels als
nur für Signaturen im Sinne von Nicht-Abstreitbarkeit bestimmt
id-ce-subjectAltName
{ id-ce 17 }
enthält den alternativen technischen Namen des HBA-Besitzers
id-ce-basicConstraints
{ id-ce 19 }
zeigt an, dass der Karteninhaber nicht die Rolle einer CA ausüben darf
id-ce-certificatePolicies
{ id-ce 32 }
bezeichnet die Policy an, die bei der Ausgabe des Zertifikates
zugrunde lag und den Zweck, für den sie genutzt werden soll
id-ce-authorityKeyIdentifier
{ id-ce 35 }
bezeichnet den öffentlichen Schlüssel der ausgebenden CA
id-pkix
{1361557}
Zweig für PKIX
id-pe
{ id-pkix 1 }
Zweig für private Zertifikats-Erweiterungen
id-pe-qcStatements
{ id-pe 3 }
gibt an, dass dasZertifikat ein qaulifiziertes Zertifikat innerhalb
eines bestimmten Rechtssystems ist
id-pda
{ id-pkix 9 }
Zweig für Attribute von persönlichen QC-Daten
id-pda-dateOfBirth
{ id-pda 1 }
Geburtsdatum
id-pda-placeOfBirth
{ id-pda 2 }
Geburtsort
id-pda-gender
{ id-pda 3 }
Geschlecht
id-pda-countryOfCitizenship
{ id-pda 4 }
Land, aus dem der Karteninhaber stammt
id-pda-countryOfResidence
{ id-pda 5 }
Land, in dem der Karteninhaber wohnt
id-isismtt
{ 1 3 36 8 }
Zweig für ISIS-MTT
id-qcs
{ id-pkix 11 }
Zweig für QC statements
id-qcs-pkixQCSyntax-v1
{ id-qcs 1 }
RFC3039 QC statement
id-isismtt-at
{ id-isismtt 3 }
Zweig für ISIS-MTT-Attribute und -Erweiterungen
id-isismtt-at-admission
{ id-isismtt-at 3 }
Ibezeichnet berufliche Zulassungsinformationen
id-isismtt-at-restriction
{ id-isismtt-at 8 }
bezeichnet ander (nicht-monetäre) Beschränkungen in Zertifikaten
Version: 2.1.0 de
Seite 107 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
Object Identifier
Bedeutung
Name
Wert
id-isismtt-at-namingAuthorities
{ id-isismtt-at 11 }
Zweig für namensgebende Berufsorganisationen
id-isismtt-at-nameAtBirth
Geburtsname
id-isismtt-at-additionalInformation
bezeichnet nicht-beschränkende Informationen zur Zertifikatsnutzung
id-isismtt-cp
{ id-isismtt 1 }
Zweig für ISIS-MTT Zertifikats-Policies
id-isismtt-cp-accredited
{ id-isismtt-cp 1 }
zeigt an, dass es sich um ein qualifiziertes Zertifikat gemäß
[ECDIR] handelt, dass es den speziellen Anforderungen des
SigG entspricht und von einem akkreditierten ZertifizierungsDiensteanbieter ausgegeben wurde
id-validityModel
{ 1 3 6 1 4 1 8301 3 5 }
Zweig für Erweiterungen der BNA, um Gültigkeitsmodelle anzuzeigen
id-validityModel-chain
{ id-validityModel 1 }
definiert das Kettenmodell als zugrundeliegendes Gültigkeitsmodell
id-validityModel-shell
{ id-validityModel 2 }
definiert das Schalenmodell als zugrundeliegendes Gültigkeitsmodell
id-etsi-qcs
{ 0 4 0 1862 1 }
Zweig für ETSI QC statements
id-etsi-qcs-QcCompliance
{ id-etsi-qcs 1 }
zeigt an, dass das Zertifikat den Vorgaben von [ECDIR] entspricht
id-etsi-qcs-QcLimitValue
{ id-etsi-qcs 2 }
zeigt die Begrenzung der Höhe einer Transaktion gemäß
[ECDIR] an
id-etsi-qcs-QcRetentionPeriod
{ id-etsi-qcs 3 }
zeigt, wie viele Jahre nach Ablaufdatum des Zertifikates die
Registrierungsinformationen über den Karteninhaber gespeichert werden
C.7 Attributszertifikat für elektronische Signaturen (X.509v3 Zertifikat)
Attributszertifikate werden herausgegeben, um dem Karteninhaber spezielle Attribute zuweisen zu können, die nicht im Basis-QES-Zertifikat enthalten sind. Wenn ein Dokument vom
Karteninhaber signiert wird und er ein oder mehrere der Attributszertifikate in einem bestimmten Kontext nutzen will, müssen die Attributszertifikate am Ende des Dokumentes angefügt und mit signiert werden.
Allgemeine Definition eines Attributszertifikates:
AttributeCertificate
acinfo
signatureAlgorithm
signature
::=
SEQUENCE {
AttributeCertificateInfo,
BIT STRING }
TBSAttributeCertificate
version
subject
::=
SEQUENCE {
Version DEFAULT v1,
CHOICE {
Version: 2.1.0 de
Seite 108 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
baseCertificateID
subjectName
issuer
signature
serialNumber
attrCertValidityPeriod
attributes
issuerUniqueID
extensions
Attribute
type
values
[0] IssuerSerial,
[1] GeneralNames },
GeneralNames,
AttCertValidityPeriod,
SEQUENCE OF Attribute,
UniqueIdentifier OPTIONAL,
Extensions OPTIONAL }
::=
SEQUENCE {
AttributeType,
SET OF AttributeValue }
Die issuerUniqueID darf nicht verwendet werden. Der Bezug zum Basis-QES-Zertifikat, zu
dem das Attributszertifikat gehört, wird durch Angabe des Herausgebers und der Seriennummer des QES-Basis-Zertifikats hergestellt.
IssuerSerial
issuer
serial
issuerUID
::=
SEQUENCE {
GeneralNames,
UniqueIdentifier OPTIONAL }
AttCertValidityPeriod
notBeforeTime
notAfterTime
::=
SEQUENCE {
GeneralizedTime,
GeneralizedTime }
Die issuerUID darf nicht verwendet werden. Berufsspezifische Zulassungen können in einem
Attributszertifikat durch Nutzung des Attributs admission des Typs AdmissionSyntax wie in
[ISIS-MTT OP] definiert angegeben werden. Das Attribut admission wird nur mit einem Eintrag besetzt. Trotzdem können mehrere Zulassungen in der sequentiellen Struktur der Komponente contentsOfAdmissions von AdmissionSyntax oder in der Komponente professionInfos of admissions zusammengefasst werden. Weitere Details siehe unter C.2.9.9.
Im Folgenden sind die Anforderungen für die Nutzung des Attributs admission in Attributszertifikaten spezifiziert. Die Attribute eines Heilberuflers sind an seine beruflichen Zulassungen
gebunden. Die folgenden zwei Kategorien können in Bezug auf die sie verantwortenden Organisationen unterschieden werden
• Kategorie "Qualifikationen", und
• Kategorie "Autorisierungen".
Es ist anzumerken, dass beide Kategorien von Attributszertifikaten dieselbe Struktur aufweisen und das Attribut admission vom ASN.1-Typ AdmissionSyntax nutzen. Attributszertifikate
müssen die folgenden Erweiterungen mit zum zugehörenden Basiszertifikat passenden Werten enthalten: AuthorityKeyIdentifier, CertificatePolicies, CRLDistributionPoints, AuthorityInfoAccess and QCStatements.
Version: 2.1.0 de
Seite 109 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
Die Vorgaben für die Nutzung und den Inhalt von Attributszertifikaten und die möglichen Kategorien der berufsspezifischen Zulassungen werden im Detail in einem gesonderten Dokument beschrieben. Die beiden folgenden Unterkapitel beschreiben beispielhafte Implementierungen.
C.7.1 Attributszertifikat für Qualifikationen
Das Attributszertifikat für Qualifikationen enthält die folgenden Informationen:
• Beruf
• Spezialisierungsart, und
• konkrete Spezialisierung
Für jede Spezialisierungsart kann ein gesondertes Attributszertifikat herausgegeben werden.
Die Organisation, die diese Qualifikationen bestätigt, ist die zugehörende Kammer. Nachfolgend ein Beispiel für ein Attributszertifikat für Qualifikationen
{ admissionAuthority "BAYERISCHE LANDESAERZTEKAMMER",
{ professionInfos {
{ namingAuthority {
namingAuthorityId id-OIDForBAEK,
namingAuthorityUrl "UrlToListProfession" },
professionItems { "Arzt" },
registrationNumber "10.530" },
{ namingAuthority {
namingAuthorityUrl "UrlToListSpecialityType" },
professionItems { "GB" } },
{ namingAuthority {
namingAuthorityUrl "UrlToListDedicatedSpeciality" },
professionItems { "Anatomie" } } } } }
C.7.2 Attributs-Zertifikate für Autorisierungen
Die Attributszertifikate für Autorisierungen enthalten u.a. die folgenden Informationen:
• die generelle Autorisierung
Version: 2.1.0 de
Seite 110 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
• den Typ der Autorisierung und
• die konkrete Autorisierung
Für jede Autorisierungsart kann ein gesondertes Attributszertifikat herausgegeben werden.
Die Organisation, die diese Qualifikationen bestätigt, ist die zugehörende Standesorgansiation. Es folgt ein Beispiel für ein Attributszertifikat für Autorisierungen
{ admissionAuthority "KASSENAERZTLICHE VEREINIGUNG BAYERNS",
{ professionInfos {
{ namingAuthority {
namingAuthorityId id-OIDForKBV,
namingAuthorityUrl "UrlToGeneralAuthorization" },
professionItems { "Vertragsarzt" } },
{ namingAuthority {
namingAuthorityId id-OIDFor,
namingAuthorityUrl "UrlToAuthorizationType" },
professionItems { "VF" } },
{ namingAuthority {
namingAuthorityUrl "UrlToDedicatedAuthorization" },
professionItems { "Sonographie" } } } } }
C. 8 Certification Authorities für X.509 Zertifikate
Die Sicherheitsanforderungen an den HBA erfordern unterschiedliche Typen von X.509Nutzer-Zertifikaten:
• QES Zertifikat (X.509 Zertifikat für eine qualifizierte elektronische Signatur) und
bis zu 3 Attributs-Zertifikate
• AUT Zertifikat (X.509 Authentifizierungs-Zertifikat)
• ENC Zertifikat (X.509 Verschlüsselungs-Zertifikat).
Nutzerzertifikate werden von einer oder mehreren CAs des Gesundheitswesens (in diesem
Fall Zertifizierungsdiensteanbietern) ausgestellt. Die Wurzel-CA für qualifizierte elektronische
Signaturen (BNA) erstellt ein Zertifikat für eine solche CA. Das dabei zertifizierte Schlüsselpaar darf nur zur Erstellung von Nutzer-Zertifikaten für qualifizierte elektronische Signaturen
verwendet werden. Die CA der Heilberufler erstellt auch die X.509-AUT- und X.509-ENC-
Version: 2.1.0 de
Seite 111 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
Zertifikate, wobei das dafür verwendete Schlüsselpaar von der Wurzelinstanz des zugehörigen Sektors signiert ist.
Private CA-Schlüssel im
Gesundheitswesen:
BNA
Wurzel CA
HP Sektor
Wurzel CA
• PrK-CA.CS_QES, von der BNA
zertifiziert zum Signieren von
C.HP.QES und zugehörenden
ACs
• PrK.CA.CS_AUT&ENC, von der
HBA-Sektor-Wurzel-CA
CA
zertifiziert zum Signieren von
HeilC.HP.AUT und C.HP.ENC
berufler
AC
AC
AC
C.HP.
QES
X.509
C.HP.
AUT
C.HP.
ENC
X.509
X.509
AC
AUT
BNA
C
CA
CS
ENC
QES
= Attributs
Attribute Zertifikat
= Authentifizierung
= Bundes-Netz-Agentur
= Zertifikat
= Certification Authority
= CertSign
= Verschlüsselung
= Qualifizierte elektr.Signatur
Abbildung C.1 – X.509 Zertifikate und Certification Authorities
Anmerkung:
Die Funktion einer CA des Gesundheitswesens kann von mehreren Organisationen (akkreditierte
ZDAs) übernommen werden.
Version: 2.1.0 de
Seite 112 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
Anhang D
(normativ)
Zertifikate für Authentifizierung und
Verschlüsselung
D.1 Struktur und Inhalt
Das AUT- und das ENC-Zertifikat sind X.509v3-Zertifikate.
Das AUT-Zertifikat enthält Informationen, die für folgende Funktionen geeignet sind:
• die Nutzer-Identifizierung, falls Zugriffsrechte auf dem Server sich auf UIDs beziehen, und
• die Zuweisung von Zugriffsrechten, falls keine UIDs registriert sind und Zugriffsrechte an die im Zertifikat angegebene Autorisierung gebunden sind (z.B. die Berufsangabe Arzt oder Apotheker)
Das ENC-Zertifikat enthält Informationen über den Zertifikatsinhaber, d.h., den Empfänger
vertraulicher Informationen.
D.2 Kodierung
Die Kodierung entspricht prinzipiell derjenigen eines QES-Zertifikats mit den folgenden Änderungen:
• es gibt kein Policy-Feld, das die Übereinstimmung mit den Vorgaben des SigG
angibt, aber einen entsprechenden Identifier für die verwendete Policy.
• als Schlüsselnutzung wird im AUT-Zertifikat "digital signature" angegeben. Um
Web-basierte Client-Authentifizierungen mit dem TSL-Protokoll durchführen zu
können, kann optional auch das "key encipherment"-Bit im AUT-Zertifikat gesetzt
werden (in Übereinstimmung mit dem ISIS-MTT-Authentication Certifiicate Profile).
• im ENC Zertifikat wird "key encipherment" und "data encipherment" als Schlüsselnutzung angegeben.
• Der Algorithmus-OID im Feld "subject public key info" muss entsprechend der
Nutzung des zertifizierten PK gesetzt werden.
Um Web-basierte Client-Authentifizierungen mit dem TSL-Protokoll durchführen zu können,
kann die nicht-kritische Erweiterung extendedKeyUsage optional in das AUT-Zertifikat eingeHBA_Spezifikation _Teil2_V2 1 0-de.doc
Version: 2.1.0 de
Seite 113 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
fügt werden (entsprechend ISIS-MTT Authentication Certificate Profile). Falls diese Erweiterung genutzt wird, muss clientAuth { 1 3 6 1 5 5 7 3 2 } als KeyPurposeID verwendet werden.
ASN.1-Definition des Typs ExtendedKeyUsage
ExtendedKeyUsage
KeyPurposeId
::=
::=
Version: 2.1.0 de
SEQUENCE SIZE (1..MAX) OF KeyPurposeId
OBJECT IDENTIFIER
Seite 114 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
Anhang E
(normative)
Algorithmen und Input-Formate für
Sicherheits Operationen
E.1 RSA-DSI-Formate
E.1.1 DSI gemäß ISO/IEC 9796-2 mit Zufallszahl
Der Input für Digitale Signaturen gemäß ISO/IEC 9796-2 mit Integration einer Zufallszahl hat
die folgende Struktur:
• Kopfzeile: 2 Bits (= 01)
• weitere Daten Bit = 1 (Mn nicht leer)
• Feld für Padding: Bits gleich 0 (Anzahl hängt von der Länge des Modulus ab),
gefolgt von einem einzelnen Bit, das auf 1 gesetzt ist
• Datenfeld: Zufallszahl, von der Karte bezogen (8 Bytes)
• Feld für Hash-Verfahren: Hashwert (für SHA-1: 160 Bits)
• Anhang: 1 Byte: ‘BC’
Anders als im Algorithmus, wie er in ISO/IEC 9796-2 beschrieben ist, wird die Zufallszahl als
interner Wert nicht in die Berechnung des Hashwertes einbezogen. Auch wird kein wiederherstellbarer String (siehe ISO/IEC 9796-2, Kapitel 6.3.4) erzeugt, d.h., der temporär erzeugte String wird direkt als DSI genutzt.
E.1.2 DSI gemäß PKCS #1
Das DSI-Format gemäß [PKCS#1] Kapitel 9.2 (Block Type 1) hat die folgende Struktur:
• Startbyte: ‘00’
• Block type: ‘01’
• Padding-String: ‘FF …FF’
• Separator: ‘00’
• DigestInfo: ASN.1-Sequenz des digestAlgorithm (ASN.1-Sequence von
• OID und Parameter) und
Version: 2.1.0 de
Seite 115 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
• digest (ASN.1-DO Hashwert)
Die an die Karte zu sendende Digestinfo wird wie folgt kodiert:
• SHA-1 mit OID: { 1 3 14 3 2 26 }
• DigestInfo: 3021 3009 06052B0E03021A 0500 0414 || Hashwert (20 Bytes)
E.1.3 Algorithm Identifier für PSO: HASH und PSO: COMPUTE DS
Tabelle 1 zeigt die Algorithm Identifier, die vor der Erstellung der ersten Signatur mit dem
Kommando MSE auszuwählen sind.
Tabelle E.1 – Algorithm Identifier für QES
AlgID
‘11’
‘12’
'41'
Bedeutung
SHA-1 und RSA mit DSI gemäß ISO/IEC 97962 mit RND
SHA-1 und RSA mit DSI gemäß PKCS #1
SHA-256 und RSA mit DSI gemäß ISO/IEC
9796-2 mit RND
SHA-256 und RSA mit DSI gemäß PKCS #1
'42'
OID
{1 3 36 3 4 3 2 1}
(TTT)
{1 2 840 113549 1 1 5} (RSADSI)
{1 3 36 3 4 3 2 4}
(TTT)
{1 2 840 113549 1 1 11}
(RSADSI)
Tabelle 7 aus [HBA-T1] zeigt die OIDs der Hash-Algorithmen, die für die Erstellung der Digestinfo notwendig sind.
E.2 Algorithm Identifier für INTERNAL AUTHENTICATE
Tabelle E.2 zeigt die algorithm identifier die für das Kommando INTERNAL AUTHENTICATION verwendet werden.
Tabelle E.2 – Algorithm Identifier für Hash- und Signatur-Algorithmen für das Kommando INTERNAL AUTHENTICATE zur Komponenten-Authentifizierung und zur Client/ServerAuthentifizierung
AlgID
‘05’
'1E'
'1F'
E.3
Bedeutung
RSA framing gemäß PKCS #1 ohne OID
RSA mit SHA-1 ohne Austausch von Session Keys
RSA mit SHA-1 mit Schlüsselaustausch und dem Speichern von SM-Schlüsseln
Entschlüsselung des Dokumenten-Verschlüsselungs-Schlüssels
Version: 2.1.0 de
Seite 116 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
Tabelle E.3 zeigt die für die Ver- und Entschlüsselung wichtigen algorithm identifier. Das
Eingabeformat für die Ver- und Entschlüsselung ist in [HBA-T1], Tabelle E.2 spezifiziert .
Tabelle E.3 - Algorithm Identifier für Ver- und Entschlüsselung
AlgID
‘1A’
Bedeutung
RSA , PI ≠ ‘00’, siehe Tabelle E.4
Version: 2.1.0 de
Seite 117 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
Anhang F
(normative)
Issuer Identifier und Certificate Holder
Authorizations
F.1 Issuer Identifier
Der issuer identifier erlaubt in Kombination mit dem Ländercode eine weltweit eindeutige
Identifizierung des Kartenherausgebers. Der BCD-kodierte Ländercode für Deutschland hat
gemäß [ISO 3166] den Wert ‘276’. Der Kartenausgeberschlüssel wird in Deutschland im Auftrag des DIN durch GS1-Germany GmbH, Köln zugewiesen. Der Kartenherausgeber ist
normalerweise der rechtmäßige Besitzer der von ihm herausgegebenen Karten. Dies gilt
besonders dann, wenn die Karte eine Identifizierungsfunktion hat, da es dann Gründe für das
Einziehen der Karte geben kann: z.B. die Beendigung des Arbeitsverhältnisses oder der Verlust der Approbation. Deswegen ist normalerweise ein Hinweis auf die Rückseite der Karte
gedruckt, dass der Herausgeber der Karte (z.B. eine Ärztekammer) das Recht hat, die Karte
einzuziehen.
Der issuer identifier ist Teil der ICCSN (Integrated Circuit Card Serial Number), die eine
weltweit eindeutige Identifikation jeder einzelnen Karte erlaubt. Für Karten im Gesundheitsbereich wird ein solches Identifizierungsmerkmal im Europäischen Standard [EN 1867] gefordert. In diesem Standard ist ebenfalls der sogenannte "Major Industry Identifier" (MII) für
Kartenhersteller im Gesundheitsbereich spezifiziert, der den Wert ‘80’ hat.
Aus technischer Sicht kann die ICCSN oder Teile von ihr zu folgenden Zwecken genutzt
werden
• Karten-Sperrung
• karten-individuelle Schlüssel-Ableitung
• Schlüssel-Identifizierung (z.B. den öffentlichen Schlüssel in einem CV-Zertifikat)
• Erstellung von Daten, die für die Authentifizierung relevant sind
• Binden von Objekten oder Operationen an eine bestimmte Karte
Die folgende Tabelle zeigt issuer identifier, die im deutschen Gesundheitswesen für Heilberufsausweise (HBAs) und Security Module Cards (SMCs) verwendet werden
Version: 2.1.0 de
Seite 118 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
Tabelle F.1 - Issuer Identification Nummern (Liste ist unvollständig)
MII für
Gesund
heitswesen
Ländercode für
Deutschland
Issuer Identifier
‘80’
‘276’
‘00101’
’00108’
’00109’
’00110’
'00xxx'
Werbe- und Vertriebsgesellschaft Deutscher Apotheker mbH
Bundesärztekammer
Bundespsychotherapeutenkammer
Bundeszahnärztekammer
Landeskrankenhausgesellschaften (DKTIG)
F.2 Profile Identifier
Ein Profile Identifier ist ein Feld von 1 Byte in einem CV-Zertifikat, das zur asymmetrischen
Card-to-Card-Authentifizierung genutzt wird. Profile werden Einheiten zugeordnet, z.B.
• Berufsgruppen, z.B. Ärzten und Apothekern
• Zertifikatsdienste-Anbietern
• Kartenmanagementsystemen
Das Konzept, Profile bzw. Rollen über einen Profile Identifier zuzuweisen, wird in verschiedenen Anwendungsbereichen genutzt. Deshalb ist es wichtig, dass der Nutzungsbereich der
Profile Identifier klar unterschieden werden kann. Zu diesem Zweck ist dem Profile Identifier
ein Präfix vorangestellt. Dieser nennt
• den Anwendungsbereich, der durch einen Application Identifier (AID) oder einen
Teil davon definiert wird
• die zugehörende Organisationseinheit, die für die Zuweisung des Profils verantwortlich
ist
Für das deutsche Gesundheitswesen wird der weltweit eindeutige application identifier
‘D27600004000’ verwendet. Der "Registered Application Provider Identifier" (RID, die ersten
5 Byte eines AID) wurde von der RID German National Registration Authority (heute SIT im
Auftrag des DIN) dem ZI (Zentralinstitut für die kassenärztliche Versorgung in der Bundesrepublik Deutschland) für die Nutzung im deutschen Gesundheitswesen zugewiesen. Das letzte Byte des oben genannten AID ist die PIX (Proprietary Application Provider Extension) und
wird auf ‘00’ gesetzt. Diese AID stellt zusammen mit der entsprechenden Profil-ID die sogenannte Certificate Holder Authorization (CHA) dar, die in CV-Zertifikate eingetragen wird,
siehe [ISO 7816-8]. Die CHA wird speziell für Sicherheitsattribute genutzt, die sich auf Datenfelder beziehen. Damit kann die Karte bei einem bestimmten Zugriff (z.B. Lesen oder Aktualisieren) entscheiden, ob das dazugehörende Kommando, bezogen auf ein bestimmtes
Datenfeld, ausgeführt oder abgelehnt wird. Eine CHA wird nur dann als gültig anerkannt,
wenn der zugehörende Authentifizierungsprozess erfolgreich ausgeführt wurde. Während
des Authentifizierungsprozesses muss die externe Einheit (z.B. der HBA eines Heilberuflers
der Gruppe x) nachweisen, dass sie den privaten Schlüssel besitzt, der zu dem im CVC entHBA_Spezifikation _Teil2_V2 1 0-de.doc
Version: 2.1.0 de
Seite 119 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
haltenen öffentlichen Schlüssel gehört. Die Nutzung dieses privaten Schlüssels setzt die
erfolgreiche Eingabe der zugehörenden PIN voraus, so dass die Ausführung der Authentifizierung abgesichert ist.
Falls verschiedene Berufsgruppen dieselben Zugriffsrechte auf die eGK haben, können sie
einem Profil zugeordnet werden. Deshalb ist im CHA-Feld "role identifier" ein Profilcode eingetragen. Dadurch wird die Zahl der Zugriffsbedingungen in der eGK reduziert. Die Zuordnung von Berufsgruppen zu einem bestimmten Profil erfolgt außerhalb dieses Dokumentes.
Die folgenden Tabellen geben die für den HBA, die SMC und die eGK verwendete CHAKodierung an. Die Nutzung von CVC.HPC.AUT und CVC.SMC.AUT wird in [eGK-P2] beschrieben.
Tabelle F.2 - CHA Kodierung für HBAs und SMCs
CHA Präfix
‘D27600004000
’
‘D27600004000
’
‘D27600004000
’
‘D27600004000
’
‘D27600004000
’
‘D27600004000
’
CHA Profil ID
‘1A’
CV Zertifikats-Halter
Profil 1 (SMC eKiosk)
‘2A’
Profil 2 (HPC, SMC)
‘3A’
Profil 3 (HPC, SMC)
‘4A’
Profil 4 (HPC, SMC)
‘5A’
Profil 5 (HPC, SMC)
‘6A’
Profil 6 (SMC für Internet-Apotheken)
Tabelle F.3 - CHA in herausgegeben durch eine RCA für eine CA (CA-eGK und CA-HPC)
CHA Präfix
… (5 B) || ‘00’
CHA Profil ID
‘00’
Certification Authority (CA)
Anmerkung:
Als CA-Name für die Wurzel-CA im Gesundheitswesen wird das Acronym "DEZGW" verwendet,
das 1999 für eine (virtuelle) „Deutsche Zertifizierungsstelle Gesundheitswesen (DEZGW)“ registriert worden ist..
Tabelle F.4 - CHA für die eGK (informative)
CHA Präfix
‘D27600000100’
CHA Profil ID
‘00’
Version: 2.1.0 de
eGK
Seite 120 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
Anhang G
(normative)
Inhalt der EFs für die Personalisierung
G.1 EF.ATR
Tabelle G.1 – Inhalt von EF.ATR
Tag
’E0’
L
‘xx’
Wert
’02 xx xxxx 02 xx xxxx 02 xx xxxx 02 xx xxxx’
‘66’
‘xx’
’46 xx …’ siehe Tabelle G.2
Bedeutung
I/O Buffer-Größe, siehe [HBAT1]
DO Karten-Daten
Tabelle G.2 – Wert des DO Pre-issuing Data (Tag ‘46’)
L (Bytes)
Bedeutung der konkatenierten Datenelemente
(Most Significant Byte: ICM)
IC Hersteller ID ICM (siehe www.sc17.com)
Karten-Hersteller ID (siehe DIN-RA: www.sit.fraunhofer.de )
IC-ID (Kartenhersteller-spezifisch)
COS Version (Kartenhersteller-spezifisch)
ROM Maske (Kartenhersteller-spezifisch)
1
5
x
x
x
G.2 EF.DIR
Tabelle G.3 – Anwendungs Templates in EF.DIR
Tag
’61’
‘61’
L
‘08’
‘08’
Anwendungs Template
‘4F 06 D276 00004002’
‘4F 06 D276 00006601’
‘61’
’0C’
‘4F 0A A000000167 455349474E’
‘61’
‘11’
‘4F 0F E828BD080F A000000167 455349474E’
Bedeutung
Anwendungs-Template mit AID.HPA
Anwendungs-Template mit AID.QES
(DINSIG)
Anwendungs-Template mit
AID.ESIGN
Anwendungs-Template mit
AID.CIA.ESIGN
G.3 EF.GDO
Tabelle G.4– DO ICCSN in EF.GDO
Tag
’5A’
L
‘0A’
Wert
‘80276 …'
Version: 2.1.0 de
Bedeutung
ICCSN
Seite 121 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
G.4 EF.CVC.CA_HPC.CS und EF.CVC.HPC.AUT
In den CVC-bezogenen EFs müssen die jeweiligen CVCs gespeichert werden (Kodierung
siehe [HBA-T1]).
G.5 EF.C.HP.QES, EF.C.HP.AUT and EF.C.HP.ENC
In den X.509-Zertifikats-bezogenen EFs müssen die jeweiligen Zertifikate gespeichert werden (siehe Anhang C und D).
G.6 EF.CIAInfo
Der Inhalt von EF.CIAInfo ist in H.1.angegeben.
G.7 EF.OD
Der Inhalt von EF.OD ist in H.2 angegeben.
G.8 EF.AOD
Der Inhalt von EF.AOD ist in H.3 angegeben.
G.9 EF.PrKD
Der Inhalt von EF.PrKD ist in H.4 angegeben.
G.10 EF.CD
Der Inhalt von EF.CD ist in H.5 angegeben.
Version: 2.1.0 de
Seite 122 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
Anhang H
(informativ)
Cryptographic Information Objects
Dieser Anhang zeigt ein detailliertes Beispiel für die kryptografischen Informations-Objekte
(CIO), die zum DF.ESIGN eines HBA gehören.
H.1
EF.CIAInfo
Das EF “CIAInfo” enthält die Versionsnummer der CIO-Beschreibung und das Label der Anwendung, zu der die CIO-Beschreibung gehört. Die “cardflags”-Einstellungen sind “authRequired” (es gibt kryptografische Funktionen, die eine Nutzer-Authentifizierung erfordern) und
“prnGeneration” (Die Karte hat die Fähigkeit, Pseudo-Zufallszahlen zu erzeugen).
H.1.1 ASN.1 Notation der ASN.1-Werte
1
2
3
4
5
7
8
ciaInfoExample CIAInfo ::= {
version v2,
label “CIA of ESIGN Application”,
cardflags { authRequired, prnGeneration }
seInfo {
se 1,
aid 'A000000167 455349474E’ H
}}
H.1.2 Beschreibung der ASN.1 tags, lengths und values
1
2
3
4
5
6
7
8
CIAInfo SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 193
version INTEGER: tag = [UNIVERSAL 2] primitive; length = 1
1
label Label UTF8String: tag = [0] primitive; length = 29
0x4865616C74682050726F66657373696F6E616C20436172642076322E30
cardflags CardFlags BIT STRING: tag = [UNIVERSAL 3] primitive; length = 2
0x0560
seInfo SEQUENCE OF: tag = [UNIVERSAL 16] constructed; length = 26
SecurityEnvironmentInfo SEQUENCE: tag = [UNIVERSAL 16] constructed;
length = 11
se INTEGER: tag = [UNIVERSAL 2] primitive; length = 1
0x01
aid OCTET STRING: tag = [UNIVERSAL 4] primitive; length = 10
0xA000000167455349474E
H.1.3 Hexadezimale DER-Kodierung
1
30 34
Version: 2.1.0 de
Seite 123 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
2
02 01
3
80 1D
01
48 65 61 6C 74 68 20 50 72 6F 66 65 73 73 69 6F 6E 61 6C 20 43
61 72 64 20 76 32 2E 30
4
03 02
5
6
7
30 10
05 60
30 0B
02 01
01
8
04 0A
A000000167455349474E
H.2
EF.OD
Das EF "Object Directory" enthält die Information, welche CIO-EFs vorhanden sind und wie
sie durch SFID referenziert werden.
H.2.1 Notation der ASN.1-Werte
1
2
3
4
5
6
7
8
9
authObjects :
path : {
efidOrPath '14'H -- SFID of EF.AOD
},
privateKeys :
path : {
efidOrPath '15'H -- SFID of EF.PrKD
},
certificates :
path : {
efidOrPath '16'H -- SFID of EF.CD
}
1
2
3
4
5
6
7
8
CIOChoice CHOICE
authObjects : tag = [8] constructed; length = 5
AuthObjects CHOICE
path Path SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 3
efidOrPath OCTET STRING: tag = [UNIVERSAL 4] primitive; length = 1
0x14
CIOChoice CHOICE
privateKeys : tag = [0] constructed; length = 5
PrivateKeys CHOICE
0x15
CIOChoice CHOICE
certificates : tag = [4] constructed; length = 5
Certificates CHOICE
Version: 2.1.0 de
Seite 124 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
9
0x16
1
2
3
A8 05
4
5
6
A0 05
30 03
04 01
14
30 03
04 01
15
7
8
9
A4 05
30 03
04 01
16
H.3
EF.AOD
Das EF “authentication object directory” enthält die Information über die PIN.CH.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
pwd : {
commonObjectAttributes {
label "PIN.CH",
flags { private },
authId '12'H
},
classAttributes {
authId '02'H
},
typeAttributes {
pwdFlags { initialized, exchangeRefDaten },
pwdType iso9564-1,
minLength 5,
storedLength 0,
maxLength 8,
pwdReference 1
-- P2 value of the VERIFY command
}
},
pwd : {
label "PUK.HP",
flags { private }
},
classAttributes {
authId '12'H
},
typeAttributes {
pwdFlags { global, change-disabled, unblock-disabled, initialized, unblockingPassword },
pwdType iso9564-1,
Version: 2.1.0 de
Seite 125 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
minLength 8,
storedLength 8,
maxLength 8,
pwdReference 1
}
24
25
26
27
-- P2 value of the RESET RC command
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
AuthenticationObjectChoice CHOICE
pwd SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 50
commonObjectAttributes CommonObjectAttributes SEQUENCE: tag = [UNIVERSAL 16]
constructed; length = 19
label Label UTF8String: tag = [UNIVERSAL 12] primitive; length = 10
0x50494E2E48502E415353
flags CommonObjectFlags BIT STRING: tag = [UNIVERSAL 3] primitive; length=2
0x0780
authId Identifier OCTET STRING: tag = [UNIVERSAL 4] primitive; length = 1
0x12
classAttributes CommonAuthenticationObjectAttributes SEQUENCE:
tag = [UNIVERSAL 16] constructed; length = 3
0x02
typeAttributes : tag = [1] constructed; length = 22
PasswordAttributes SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 20
pwdFlags PasswordFlags BIT STRING: tag = [UNIVERSAL 3] primitive;
length = 3
0x040810
pwdType PasswordType ENUMERATED: tag = [UNIVERSAL 10] primitive; length=1
4
minLength INTEGER: tag = [UNIVERSAL 2] primitive; length = 1
5
storedLength INTEGER: tag = [UNIVERSAL 2] primitive; length = 1
0
maxLength INTEGER: tag = [UNIVERSAL 2] primitive; length = 1
8
pwdReference Reference INTEGER: [0] primitive; length = 1
0x01
AuthenticationObjectChoice CHOICE
pwd SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 46
0x50554B2E48502E415353
0x0780
classAttributes CommonAuthenticationObjectAttributes SEQUENCE:
tag = [UNIVERSAL 16] constructed; length = 3
0x12
PasswordAttributes SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 19
Version: 2.1.0 de
Seite 126 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
22
pwdFlags PasswordFlags BIT STRING: tag = [UNIVERSAL 3] primitive;
length = 2
0x013A
pwdType PasswordType ENUMERATED: tag = [UNIVERSAL 10] primitive; length=1
4
minLength INTEGER: tag = [UNIVERSAL 2] primitive; length = 1
8
storedLength INTEGER: tag = [UNIVERSAL 2] primitive; length = 1
8
maxLength INTEGER: tag = [UNIVERSAL 2] primitive; length = 1
8
pwdReference Reference INTEGER: [0] primitive; length = 1
0x01
23
24
25
26
27
1
2
3
30 32
30 13
0C 0A
50 49 4E 2E 48 50 2E 41 53 53
4
03 02
5
04 01
07 80
12
6
7
30 03
8
A1 16
04 01
02
30 14
9
03 03
04 08 10
10
0A 01
11
02 01
12
02 01
13
02 01
14
80 01
04
05
00
08
01
15
16
17
30 2E
30 10
0C 0A
50 55 4B 2E 48 50 2E 41 53 53
18
03 02
07 80
19
20
30 03
21
A1 15
04 01
12
30 13
22
03 02
Version: 2.1.0 de
Seite 127 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
01 3A
23
0A 01
24
02 01
25
02 01
26
02 01
27
80 01
04
08
08
08
01
H.4
EF.PrKD
Das EF “private key directory” enthält die notwendigen Informationen über die beiden privaten Schlüssel PrK.HP.AUT und PrK.HP.ENC.
Version: 2.1.0 de
Seite 128 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
privateRSAKey : {
label "PrK.HP.AUT",
flags { private },
authId '02'H
-- pointer to the AOD-entry of PIN.CH
accessControlRules {
{
accessMode { execute },
securityCondition and : {
authId : '02'H, -- pointer to the AOD-entry of PIN.CH
authReference : {
authMethod { userAuthentication }
}
}
}
}
}
},
classAttributes {
iD '82'H,
-- cross-reference to the CD-entry of C.HP.AUT
usage { signRecover },
keyReference –130
-- used in MSE-SET-command
},
typeAttributes {
value {
efidOrPath ''H
},
modulusLength 1728
}
},
privateRSAKey : {
label "PrK.HP.ENC",
flags { private },
authId '02'H
-- pointer to the AOD-entry of PIN.CH
accessControlRules {
{
accessMode { execute },
securityCondition and : {
authId : '02'H, -- pointer to the AOD-entry of PIN.CH
authReference : {
authMethod { userAuthentication }
}
}
}
}
}
},
classAttributes {
iD '83'H,
-- in this specification unused (but mandatory)
usage { keyDecipher },
keyReference –131
-- used in MSE-SET-command
},
typeAttributes {
Version: 2.1.0 de
Seite 129 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
value {
efidOrPath ''H
},
modulusLength 1728
}
37
38
},
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
PrivateKeyChoice CHOICE
privateRSAKey SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 61
0x50724B2E48502E415554
flags CommonObjectFlags BIT STRING: tag = [UNIVERSAL 3] primitive;
length = 2
0x0780
0x02
accessControlRules SEQUENCE OF: tag = [UNIVERSAL 16] constructed; length = 17
AccessControlRule SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 15
accessMode BIT STRING: tag = [UNIVERSAL 3] primitive; length = 2
0x0520
securityCondition SecurityCondition CHOICE
and SEQUENCE OF: tag = [1] constructed; length = 9
authId Identifier OCTET STRING: tag = [UNIVERSAL 4] primitive;
length = 1
0x02
authReference AuthReference SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 4
authMethod AuthMethod BIT STRING: tag = [UNIVERSAL 3] primitive;
length = 2
0x0520
classAttributes CommonKeyAttributes SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 10
iD Identifier OCTET STRING: tag = [UNIVERSAL 4] primitive; length = 1
0x82
usage KeyUsageFlags BIT STRING: tag = [UNIVERSAL 3] primitive; length = 2
0x0410
keyReference KeyReference INTEGER: tag = [UNIVERSAL 2] primitive;
length = 1
0x82
PrivateRSAKeyAttributes SEQUENCE: tag = [UNIVERSAL 16] constructed;
length = 8
value Path SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 2
modulusLength INTEGER: tag = [UNIVERSAL 2] primitive; length = 2
1728
Version: 2.1.0 de
Seite 130 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
PrivateKeyChoice CHOICE
privateRSAKey SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 60
0x50724B2E48502E4B45
flags CommonObjectFlags BIT STRING: tag = [UNIVERSAL 3] primitive;
length = 2
0x0780
0x02
accessControlRules SEQUENCE OF: tag = [UNIVERSAL 16] constructed; length = 17
AccessControlRule SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 15
accessMode BIT STRING: tag = [UNIVERSAL 3] primitive; length = 2
0x0520
securityCondition SecurityCondition CHOICE
and SEQUENCE OF: tag = [1] constructed; length = 9
authId Identifier OCTET STRING: tag = [UNIVERSAL 4] primitive;
length = 1
0x02
authReference AuthReference SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 4
authMethod AuthMethod BIT STRING: tag = [UNIVERSAL 3] primitive;
length = 2
0x0520
classAttributes CommonKeyAttributes SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 10
0x83
usage KeyUsageFlags BIT STRING: tag = [UNIVERSAL 3] primitive; length = 2
0x0204
keyReference KeyReference INTEGER: tag = [UNIVERSAL 2] primitive;
length = 1
0x83
PrivateRSAKeyAttributes SEQUENCE: tag = [UNIVERSAL 16] constructed;
length = 8
value Path SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 2
modulusLength INTEGER: tag = [UNIVERSAL 2] primitive; length = 2
1728
1
2
3
30 3D
30 26
0C 0A
50 72 4B 2E 48 50 2E 41 55 54
4
03 02
5
04 01
6
7
30 11
07 80
02
30 0F
Version: 2.1.0 de
Seite 131 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
8
03 02
9
10
A1 09
05 20
04 01
02
11
12
30 04
03 02
05 20
13
14
30 0A
04 01
82
15
03 02
16
02 01
04 10
82
17
A1 0A
30 08
18
30 02
19
02 02
04 00
04 00
20
21
22
30 3C
30 25
0C 09
50 72 4B 2E 48 50 2E 4B 45
23
03 02
24
04 01
25
26
27
30 11
07 80
02
30 0F
03 02
05 20
28
29
A1 09
04 01
02
30
31
30 04
03 02
05 20
32
33
30 0A
04 01
83
34
03 02
35
02 01
02 04
83
36
A1 0A
30 08
37
30 02
38
02 02
04 00
04 00
H.5
EF.CD
Das EF “certificate directory” enthält die File-Referenzen zu den X.509-Zertifikaten
C.HP.AUT und C.HP.ENC.
Version: 2.1.0 de
Seite 132 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
x509Certificate : {
label "C.HP.AUT",
flags { private },
classAttributes {
iD '82'H
-- cross-reference to the PrKD-entry of PrK.HP.AUT
},
typeAttributes {
value indirect :
path : {
efidOrPath '01'H --SFID of C.HP.AUT
}
}
},
x509Certificate : {
label "C.HP.ENC",
flags { private },
classAttributes {
iD '83'H
-- cross-reference to the PrKD-entry of PrK.HP.ENC
},
typeAttributes {
value indirect :
path : {
efidOrPath '02'H --SFID of C.HP.ENC
}
}
1
CertificateChoice CHOICE
x509Certificate SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 33
2
3
0x432E48502E415554
4
0x0780
5
classAttributes CommonCertificateAttributes SEQUENCE: tag = [UNIVERSAL 16]
6
0x82
7
X509CertificateAttributes SEQUENCE: tag = [UNIVERSAL 16] constructed;
length = 5
8
value CHOICE
indirect ReferencedValue CHOICE
9
0x01
10 CertificateChoice CHOICE
Version: 2.1.0 de
Seite 133 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
11
12
13
14
15
16
17
18
x509Certificate SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 33
0x432E48502E415554
0x0780
classAttributes CommonCertificateAttributes SEQUENCE: tag = [UNIVERSAL 16]
0x83
X509CertificateAttributes SEQUENCE: tag = [UNIVERSAL 16] constructed;
length = 5
value CHOICE
indirect ReferencedValue CHOICE
0x02
Version: 2.1.0 de
Seite 134 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
1
2
3
30 1E
30 11
0C 08
43 2E 48 50 2E 41 55 54
4
03 02
07 80
5
6
30 03
7
A1 07
04 01
82
30 05
8
9
30 03
04 01
01
10
11
12
30 1E
30 11
0C 08
43 2E 48 50 2E 41 55 54
13
03 02
07 80
14
15
30 03
16
A1 07
04 01
83
30 05
17
18
30 03
04 01
02
Version: 2.1.0 de
Seite 135 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
Anhang I
I.1 - Abkürzungen
Kürzel
Erläuterung
AC
Attribute Certificate
AM
Zugriffsmodus (Access Mode)
AOD
Authentication Object Directory
AMS
Anwendungs-Management-System (Application Management System) sh. auch CAMS
ARR
Access Rule Reference
ASN.1
Abstract Syntax Notation One
AT
Authentication Template
ATR
Answer-to-Reset
AUT
Authentisierung (Authentication)
AVS
Apothekenverwaltungssystem
BCD
Binär kodierte Dezimalzahl (Binary Coded Decimal)
BÄK
Bundesärztekammer
BER
Basic Encoding Rules
BNA
Bundesnetzagentur
C
Zertifikat (Certificate)
C2C
Card-to-Card
CA
Zertifizierungsinstanz (Certification Authority)
CAR
Referenz der Zertifizierungsinstanz (Certification Authority Reference)
CBC
Cipher Block Chaining
CC
kryptografische Prüfsumme (Cryptographic Checksum)
CD
Certificate Directory
CE
Zertifikatserweiterungen (Certificate Extensions)
CG
Kryptogramm (Cryptogram)
CH
Karteninhaber (Cardholder)
Version: 2.1.0 de
Seite 136 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
Kürzel
Erläuterung
CHA
Berechtigung des Karteninhabers (Certificate Holder Authorization)
CHR
Referenz des Karteninhabers (Certificate Holder Reference)
CIA
kryptografische Informationsanwendung (Cryptographic Information
Application)
CIO
kryptografische Informationsobjekte (Cryptographic Information
Objects)
CLA
Class-Byte eines Befehls
COS
Kartenbetriebssystem (Card Operating System)
CPI
Kennung des Zertifikatsprofils (Certificate Profile Identifier)
CRT
Control Reference Template
CS
CertSign (CertificateSigning)
CT
Confidentiality Template
CVC
Card Verifiable Certificate
CWA
CEN Workshop Agreement
C2C
Card-to-Card
C2S
Card-to-Server
D, DIR
Verzeichnis (Directory)
DE
Datenelement
DER
Distinguished Encoding Rules
DES
Data Encryption Standard
DO
Datenobjekt
DF
Dedicated File
DI
Baud rate adjustment factor
DM
Display Message
DSI
Digital Signature Input
DST
Digital Signature Template
EF
Elementary File
eGK
elektronische Gesundheitskarte
eHC
electronic Health Card
EHIC
European Health Insurance Card
ENC
Verschlüsselung (Encryption)
Version: 2.1.0 de
Seite 137 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
Kürzel
Erläuterung
ENC( )
verschlüsselte Daten (Encrypted data)
EOF
Dateiende (End-of-File)
ES
Elektronische Signatur
FCP
File Control Parameter
FI
Clock rate conversion factor
FID
Dateikennung (File Identifier)
FM
Dateimanagement (File Management)
GKV
Gesetzliche Krankenversicherung
GP
Global Platform
HB
Historical Bytes
HBA
Heilberufsausweis
HCA
Gesundheitsanwendung (Health Care Application)
HIA
Geschäftsstelle der Krankenversicherung (Health Insurance Agency)
HP
Heilberufler (Health Professional)
HPC
Heilberufsausweis (Health Professional Card)
ICC
Integrated Circuit Card
ICCSN
ICC Serial Number
ICM
IC-Herstellerkennung (IC Manufacturer)
ID
Identifier
IFD
Interface Device
IFSC
Information Field Size Card
IFSD
Information Field Size Device
IIN
Kennung des Kartenanbieters (Issuer Identification Number)
IK
Individual Key
IV
Initial Value
KD
Key derivation Data
Key Ref.
Schlüssel-Referenz (Key Reference)
KE
Key Encipherment
KEI
Key Encipherment Input
KID
Key Encipherment Input
Version: 2.1.0 de
Seite 138 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
Kürzel
Erläuterung
KIS
Krankenhaus-Informations-System
LSB
Least Significant Byte(s)
MAC
Message Authentication Code
MF
Master File
MII
Major Industry Identifier
MSE
Manage Security Environment
OID
Objektkennung (Object Identifier)
PI
Padding Indicator
PIN
Personenkennung (Personal Identification Number)
PIX
Proprietary Appl. Prov. Extension
PK,PuK
Öffentlicher Schlüssel (Public Key)
PKI
Public Key Infrastructure
PP
Schutzprofil (Protection Profile)
PPS
Protocol Parameter Selection
PrK
Privater Schlüssel (Private Key)
PRND
Padding Random Number
PSO
Perform Security Operation
PuK
Public Key
PUK
Personal Unblocking Key (Resetting Code)
PVS
Praxisverwaltungssystem
Q
Qualifiziert
QES
Qualifizierte Elektronische Signatur
R
Rollenkennung
RA
Registration Authority
RC
Retry Counter
RCA
Wurzelinstanz (Root CA)
RD
Referenzdaten (Reference Data)
RF
Radio Frequency
RFC
Request for Comment
RID
Registered Application Provider Id.
RND
Zufallszahl (Random Number)
Version: 2.1.0 de
Seite 139 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
Kürzel
Erläuterung
ROM
Read Only Memory
RSA
Algorithmus von Rivest, Shamir, Adleman
S
Server
S2C
Server-to-Card
SC
Sicherheitsbedingung (Security Condition)
SE
Sicherheitsumgebung (Security Environment)
SFID
Short EF Identifier
SIG
Signatur (Signature)
SK
geheimer Schlüssel (Secret Key)
SM
Secure Messaging
SMA
Security Module Application
SMC
Sicherheitsmodulkarte (Security Module Card)
SMK
SM-Schlüssel (SM key)
SN
Serien-Nummer (Serial Number)
SSC
Send Sequence Counter
SSCD
Sichere Signaturerstellungseinheit (Secure Signature Creation Device)
SSL
Security Sockets Layer
SVR
Server
TCE
Trusted Channel Establisment
TLV
Tag Length Value
TC
sicherer Kanal (Trusted Channel)
TLS
Transport Layer Security
UID
Benutzerkennung (User Identification)
UQ
Usage Qualifier
UTF8
8-bit Unicode Transformation Format
ZDA
Zertifizierungs-Dienste-Anbieter
3DES
Triple-DES
Version: 2.1.0 de
Seite 140 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
I.2 - Glossar
Die Begriffserläuterungen des Projektes zur Einführung der Gesundheitskarte werden in einem zentralen Glossar veröffentlicht.
I.3 - Referenzierte Dokumente
[Quelle]
Herausgeber (Erscheinungsdatum): Titel
[ALGCAT]
Geeignete Algorithmen zur Erfüllung der Anforderungen nach §17
Abs. 1 bis 3 SigG vom 22. Mai 2001 in Verbindung mit Anlage 1
Abschnitt I Nr. 2 SigV vom 22. November 2001, Algorithmenkatalog 2005 vom 02.01.2005, 30. März 2005, Bundesanzeiger Nr.
59, S. 4695-4696 , siehe www.bundesnetzagentur.de
Bundesärztekammer
Ausgabe Heilberufsausweis (HBA)
Fachfeinkonzept, 200503
Bundesärztekammer
Lastenheft zur Spezifikation der HPC/SMC
Version 0.3.9 vom 05.09.2005
Application Interface for SmartCards used as Secure Signature
Creation Devices, Part 1 – Basic Requirements
March 8th 2004
[BÄK-HBAAusgabe]
[BÄK-HBALastenheft]
[CWA14890-1]
[CWA14890-2]
[DIN66291-1]
Application Interface for SmartCards used as Secure Signature
Creation Devices, Part 2 – Additional services
March 12th 2004
DIN V66291-1: 2000
Chipkarten mit Digitaler Signatur-Anwendung/Funktion nach SigG
und SigV
Teil 1: Anwendungsschnittstelle
[DIN66291-4]
DIN V66291-4: 2002
Chipkarten mit Digitaler Signatur-Anwendung/Funktion nach
SigG/SigV Teil 4: Grundlegende Sicherheitsdienste
[ECDIR]
Directive 1999/93/EC of the European Parliament and of the
Council of 13 December 1999 on a Community Framework for
Electronic Signatures
[eGK-P1]
Spezifikation elektronische Gesundheitskarte
Teil 1 – Kommandos, Algorithmen und Funktionen des Kartenbetriebssystems V1.0
Die Spezifikation der elektronischen Gesundheitskarte
[eGK-P2]
Version: 2.1.0 de
Seite 141 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
[Quelle]
Teil 2 – Anwendungen und anwendungsspezifische Strukturen
[EN1867]
EN 1867:1997
Machine readable cards – Health care applications – Numbering
system and registration procedure for issuer identifiers
[HBA-T1]
Teil 1: Kommandos, Algorithmen und Funktionen der Betriebssystem-Plattform V.2.1.0 de
[HBA-T3]
Teil 3: SMC Anwendungen und Funktionen V2.1.0 de
[ISIS-MTT OP]
T7, TeleTrusT: ISIS-MTT Specification, Optional Profile "SigGProfile", Version 1.1, 16th March 2004, www.teletrust.de
[ISIS-MTT P1]
T7, TeleTrusT: ISIS-MTT Specification, Part 1 "Certificate and
CRL Profiles", Version 1.1, 16th March 2004, www.teletrust.de
[ISO3166-1]
ISO/IEC 3166-1: 1997
Codes for the representations of names of countries –
Part 1: Country codes
[ISO7812]
ISO/IEC 7812-1: 2000
Cards and personal identification – Identification of issuers –
Part 1: Numbering system
ISO/IEC 7816-3: FCD2 2005 (2nd edition)
[ISO7816-3]
Identification cards - Integrated circuit cards with contacts Part 3: Electrical interface and transmission protocols
[ISO7816-4]
ISO/IEC 7816-4: 2004 (2nd edition)
Identification cards - Integrated circuit cards Part 4: Organization, security and commands for interchange
[ISO7816-5]
Identification cards - Integrated circuit cards Part 5: Registration of application providers
[ISO7816-6]
Identification cards - Integrated circuit cards Part 6: Interindustry data elements for interchange
[ISO7816-8]
Identification cards - Integrated circuit cards Part 8: Commands for security operations
[ISO7816-9]
Identification cards - Integrated circuit cards -
Version: 2.1.0 de
Seite 142 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
[Quelle]
Part 9: Commands for card management
[ISO7816-13]
ISO/IEC 7816-13: CD2 2005
Identification cards - Integrated circuit cards Part 13: Commands for application management in multiapplication environment
[ISO7816-15]
ISO/IEC 7816-15: 2004
Identification cards - Integrated circuit cards Part 15: Cryptographic information application
[ISO8825]
ISO/IEC 8825-1: 1995
Information technology - ASN.1 encoding rules - Specification of
Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
and Distinguished Encoding Rules (DER)
[ISO9564]
ISO 9564-1
Banking – Personal Identification Number management and Security, Part 1: PIN protection principles and techniques, 1999
[ISO9796-2]
ISO 9796-2: 2002
Information technology – Security techniques – Digital signature
schemes giving message recovery – Part 2: Mechanisms using a
hash function Update
[ISO10118]
ISO 10118-2
Information technology – Security techniques – Hash functions,
Part 2: Hash functions using an n-bit block cipher algorithm, 1994
[ISO10918]
ISO/IEC 10918-1
Information technology - digital compression and coding of continuous-tone still images: Requirements and guidelines, 1994
ISO/IEC 11770: 1996
[ISO11770]
Information technology - Security techniques - Key management
[NIST-SHS]
Part 3: Mechanisms using asymmetric techniques
NIST: FIPS Publication 180-2:
Secure Hash Standard (SHS-1),
01.08.2002
[PKCS#1]
PKCS #1 RSA Cryptography Standard
V2.1: June 14, 2002
[PP-HPC]
Common Criteria Protection Profile – Health Professional Card
(HPC)
BSI-PP-018, 05.12.2005
Version: 2.1.0 de
Seite 143 von 144
Stand: 28.5.2006
Heilberufs-Ausweis
und
[Quelle]
[Resolution190]
Beschluss Nr. 190 der Europäischen Union vom 18. Juni 2003
betreffend die technischen Merkmale der europäischen Krankenversicherungskarte
[RFC1510]
RFC 1510: May 1999
Public Key Cryptography for Initial Authentication in Kerberos
[RFC2246]
RFC 2246: Jan. 1999
The TLS Protocol, Version 1.0
[RFC2279]
UTF-8, a transformation format of ISO 10646, January 1998
[RFC2459]
Internet X.509 Public Key Infrastructure - Certificate and CRL
Profile, January 1999
[RFC3039]
Internet X.509 Public Key Infrastructure Qualified Certificates
Profile, January 2001
[RFC3280]
Internet X.509 Public Key Infrastructure – Certificate and Certificate Revocation List (CRL) Profile, April 2002
[RSA]
R. Rivest, A. Shamir, L. Adleman:
A method for obtaining digital signatures and public key cryptosystems, Communications of the ACM, Vol. 21 No. 2, 1978
[SigG01]
Gesetz über Rahmenbedingungen für elektronische Signaturen
und zur Änderung weiterer Vorschriften, Bundesgesetzblatt Nr.
22, 2001, S.876
[SigV01]
Verordnung zur elektronischen Signatur – SigV, 2001, Bundesgesetzblatt Nr. 509, 2001, S. 3074
Netscape:
[SSL]
SSL3.0 Specification
Version: 2.1.0 de
Seite 144 von 144
Stand: 28.5.2006

Heilberufs-Ausweis und Security Module Card

Transcription

Documents pareils

2 Aufbruch in die Neue Welt

Preise und Bestellung - M-Base

Auszug - Sozialversicherungsnummer, Bankkonto, Führerschein

Bestellformular für die - M-Base

Credit Card Authorisation Form

Die aqua med travel card

PM_AntiRa Campus Erfurt_Cosmopolar

ESPAÑAMUNDO LOTERIA PRIMITIVA S.A.

Steueranreize für Niedrigverdiener: Der Earned Income Tax

Benjamin Franklin, der große amerikanische Staatsmann