Health Professional Card

Transcription

Spezifikation des
elektronischen Heilberufsausweises
Teil II: HPC - Anwendungen und Funktionen
Version 2.3.2
05.08.2009
Bundesärztekammer
Kassenärztliche Bundesvereinigung
Bundeszahnärztekammer
Bundespsychotherapeutenkammer
Kassenzahnärztliche Bundesvereinigung
Bundesapothekerkammer
Deutsche Krankenhausgesellschaft
HPC-Spezifikation V2.3.2, Teil II
Seite 1 von 162
Editor: Ulrich Waldmann (Fraunhofer SIT)
Die technische Spezifikation für den Heilberufsausweis (HPC) und die Sicherheitsmodulkarte (SMC)
besteht aus folgenden Teilen:
Teil 1: Kommandos, Algorithmen und Funktionen der Betriebssystemplattform
Teil 2: HPC – Anwendungen und Funktionen
Teil 3: SMC – Anwendungen und Funktionen
Seite 2 von 162
Spezifikation des elektronischen Heilberufsausweises
Teil II: HPC – Anwendungen und Funktionen
Inhaltsverzeichnis
1
2
3
4
5
6
7
Zielsetzung und Geltungsbereich....................................................................................6
Referenzierte Dokumente ...............................................................................................7
Abkürzungen und Notation............................................................................................11
3.1
Abkürzungen ...................................................................................................11
3.2
Notation ...........................................................................................................15
Der Heilberufsausweis ..................................................................................................17
4.1
ATR-Kodierung................................................................................................17
4.2
Allgemeine Struktur .........................................................................................18
4.3
Root-Anwendung und Dateien auf MF-Ebene.................................................19
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
4.3.6
4.3.7
4.3.8
4.3.9
4.3.10
4.3.11
4.3.12
4.3.13
4.3.14
MF ................................................................................................................................ 19
EF.ATR......................................................................................................................... 20
EF.DIR.......................................................................................................................... 21
EF.GDO........................................................................................................................ 22
EF.Version.................................................................................................................... 24
EF.C.CA_HPC.CS........................................................................................................ 25
EF.C.HPC.AUTR_CVC ................................................................................................ 26
EF.C.HPC.AUTD_SUK_CVC....................................................................................... 27
PIN.CH ......................................................................................................................... 28
PrK.HPC.AUTR_CVC .................................................................................................. 28
PrK.HPC.AUTD_SUK_CVC ......................................................................................... 29
PuK.RCA.CS ................................................................................................................ 29
PuK.CAMS_HPC.AUT_CVC........................................................................................ 30
SK.CAMS ..................................................................................................................... 30
4.4
4.5
Sicherheitsumgebungen auf MF-Ebene ..........................................................31
Öffnen der HPC ...............................................................................................31
4.5.1
4.5.2
4.5.3
4.5.4
4.5.5
Kommandosequenz nach Auslesen des ATR.............................................................. 31
Auswahl der Root-Anwendung..................................................................................... 31
Lesen von EF.ATR und EF.GDO ................................................................................. 32
Lesen von EF.DIR und EF.Version .............................................................................. 32
Lesen der CV-Zertifikate der HPC ............................................................................... 33
4.6
PIN-Management ............................................................................................34
4.6.1
4.6.2
4.6.3
4.6.4
PIN-Prüfung.................................................................................................................. 34
PIN-Änderung............................................................................................................... 34
Zurücksetzen des Fehlbedienungszählers und Setzen einer neuen PIN .................... 35
Abfragen des PIN.CH-Status ....................................................................................... 35
Management von Kanälen ............................................................................................37
5.1
Allgemeine Aspekte.........................................................................................37
5.2
Öffnen eines logischen Kanals ........................................................................37
5.3
Schließen eines logischen Kanals ...................................................................37
Interaktionen zwischen HPC und eGK..........................................................................39
6.1
Allgemeines .....................................................................................................39
6.2
Instanzen des CVC Schlüsselmanagements...................................................39
6.3
Prüfung der CV-Zertifikate der eGK ................................................................40
6.4
Asymmetrische HPC/eGK-Authentisierung ohne Aufbau eines Trusted
Channel ...........................................................................................................42
Interaktionen zwischen HPC und SMC .........................................................................45
7.1
Allgemeines .....................................................................................................45
7.2
Vorbereitungsschritte.......................................................................................46
7.3
Asymmetrische Authentisierung mit Aufbau eines Trusted Channel...............47
Seite 3 von 162
7.4
8
Asymmetrische Authentisierung mit Speicherung von Vorstellungsschlüsseln
.........................................................................................................................49
7.5
Symmetrische Authentisierung mit Aufbau eines Trusted Channel.................51
7.6
Autorisierungsprozesse ...................................................................................54
Die Heilberufsanwendung .............................................................................................56
8.1
Dateistruktur und Dateiinhalt ...........................................................................56
8.1.1
8.1.2
9
10
8.2
Sicherheitsumgebungen ..................................................................................57
8.3
Auswahl der Anwendung .................................................................................57
8.4
Lesen und Aktualisieren von EF.HPD .............................................................57
Anwendung für die qualifizierte elektronische Signatur (QES) .....................................59
9.1
9.1.1
9.1.2
9.1.3
9.1.4
9.1.5
9.1.6
9.1.7
DF.QES (Qualified Electronic Signature Application) .................................................. 59
PrK.HP.QES ................................................................................................................. 60
PIN.QES ....................................................................................................................... 60
EF.DM .......................................................................................................................... 61
EF.SSEC ...................................................................................................................... 62
EF.C.HP.QES............................................................................................................... 63
EF.C.HP.QES-AC1, -AC2 und -AC3............................................................................ 64
9.2
9.3
9.4
9.5
9.6
9.7
Erzeugung einer qualifizierten elektronischen Signatur...................................65
Auswahl der QES-Anwendung ........................................................................66
Auswahl der Sicherheitsumgebung .................................................................66
Lesen und Aktualisieren der Display Message................................................67
PIN-Management ............................................................................................68
9.7.1
9.7.2
9.7.3
9.7.4
Prüfung der PIN............................................................................................................ 68
Änderung der PIN......................................................................................................... 68
Zurücksetzen des Fehlbedienungszählers................................................................... 69
Abfrage des PIN.QES-Status ....................................................................................... 70
9.8
Berechnung einer QES....................................................................................70
9.9
Lesen der zu QES gehörenden Zertifikate ......................................................71
9.10
Schreiben von Attributzertifikaten ....................................................................72
Die ESIGN-Anwendung ................................................................................................73
10.1
10.1.1
10.1.2
10.1.3
10.1.4
10.1.5
10.1.6
11
12
DF.HPA (Health Professional Application)................................................................... 56
EF.HPD (Health Professional Data)............................................................................. 57
DF.ESIGN..................................................................................................................... 73
PrK.HP.AUT ................................................................................................................. 73
PrK.HP.ENC ................................................................................................................. 74
EF.DM .......................................................................................................................... 74
EF.C.HP.AUT ............................................................................................................... 75
EF.C.HP.ENC............................................................................................................... 75
10.2
10.3
Auswahl der ESIGN-Anwendung ....................................................................76
10.4
Lesen der X.509-Zertifikate .............................................................................76
10.5
PIN Management.............................................................................................77
10.6
Client/Server-Authentisierung..........................................................................77
10.7
Entschlüsselung des Dokumenten-Chiffrierungsschlüssels ............................79
10.8
Umschlüsselung des Dokumenten-Chiffrierungsschlüssels ............................80
Kryptografische Informationsanwendungen..................................................................82
11.1
Allgemeine Struktur .........................................................................................82
11.2
DF.CIA.QES und DF.CIA.ESIGN (Cryptographic Information Applications) ...82
11.3
Dateien mit kryptografischen Informationsobjekten (CIOs) .............................83
11.4
Auswahl der Anwendungen .............................................................................85
11.5
Lesen der CIA-Dateien ....................................................................................85
Die Organisationsspezifische Authentisierungsanwendung .........................................87
12.1
Seite 4 von 162
13
12.1.1
12.1.2
12.1.3
12.1.4
12.1.5
DF.AUTO (Organization-specific Authentication Application)...................................... 87
PrK.HP.AUTO............................................................................................................... 88
PIN.AUTO..................................................................................................................... 88
PIN.SO ......................................................................................................................... 89
EF.C.HP.AUTO1 und EF.C.HP.AUTO2....................................................................... 90
12.2
12.3
12.4
Auswahl der AUTO-Anwendung......................................................................91
PIN-Management ............................................................................................91
12.4.1
12.4.2
12.4.3
PIN-Prüfung.................................................................................................................. 91
PIN-Änderung............................................................................................................... 92
Zurücksetzen des Fehlbedienungszählers................................................................... 92
12.5
Lesen der organisationsspezifischen Zertifikate..............................................93
12.6
Aktualisieren der organisationsspezifischen Zertifikate ...................................94
12.7
Client/Server-Authentisierung..........................................................................94
Laden einer neuen Anwendung oder Anlegen eines EFs nach Ausgabe der HPC .....97
13.1
Identifizierung des HPC-Betriebssystems .......................................................97
13.2
Einrichtung eines Trusted Channel zwischen CAMS und HPC.......................97
13.2.1
13.2.2
Asymmetrische Authentisierung................................................................................... 98
Durchführung der symmetrischen Authentisierung .................................................... 100
13.3
Laden einer Anwendung oder einer neuen Datei ..........................................101
13.4
Eintragen einer neuen Anwendung in EF.DIR...............................................102
Annex A (normativ) Kartenausgeberschlüssel, Nummernräume der
Zertifizierungsdiensteanbieter und Certificate Holder Authorizations ........................103
Annex B (normativ) Struktur und Inhalt der QES-Zertifikate ...............................................109
Annex C (normativ) Zertifikate für Authentifizierung und Verschlüsselung .........................137
Annex D (informativ) Kryptografische Informationsobjekte der QES-Anwendung .............138
Annex E (informativ) Kryptographische Informationsobjekte der ESIGN-Anwendung ........153
Seite 5 von 162
1
Zielsetzung und Geltungsbereich
Diese Spezifikation beschreibt die Karten-Schnittstelle zu:
• dem Heilberufsausweis (HPC) für Angehörige approbierter Heilberufe
und Authentisierungsverfahren zwischen HPC 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 (SigG
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 Trustcenter)
Die Gültigkeitsdauer einer HPC beträgt mindestens 3 Jahre. Ein Heilberufler kann mehr als
eine HPC besitzen.
Seite 6 von 162
2
Referenzierte Dokumente
[Quelle]
Herausgeber (Erscheinungsdatum): Titel
[ALGCAT]
Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und
Eisenbahnen: Bekanntmachung zur elektronischen Signatur nach dem
Signaturgesetz und der Signaturverordnung (Übersicht über geeignete
Algorithmen) vom 17. November 2008, siehe www.bundesnetzagentur.de
T7, TeleTrusT: Common PKI Specification, Part 1: Certificate and CRL
Profiles, Version 2.0, 20th January 2009, www.common-pki.org
T7, TeleTrusT: Common PKI Specification, Part 9: SigG-Profile, Version
2.0, 20th January 2009, www.common-pki.org
[COM-PKI-1]
[COM-PKI-9]
[DIN66291-1]
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]
gematik (2008): Spezifikation der elektronischen Gesundheitskarte,
Teil 1: Spezifikation der elektrischen Schnittstelle, Version 2.2.2,
16.09.2008
[eGK-P2]
gematik (2008): Spezifikation der elektronischen Gesundheitskarte,
Teil 2: Grundlegende Applikationen, Version 2.2.1, 19.06.2008
[EN14890-1]
EN 14890-1: 2008
Application Interface for smart cards used as secure signature creation
devices, Part 1: Basic services
[EN14890-2]
EN 14890-2: 2008
Application Interface for smart cards used as Secure Signature Creation
Devices, Part 2: Additional services
[EN1867]
EN 1867:1997
Machine readable cards – Health care applications – Numbering system
and registration procedure for issuer identifiers
[GMG]
Gesetz zur Modernisierung der gesetzlichen Krankenversicherung (GKVModernisierungsgesetz - GMG), BGBl 2003 Teil I Nr. 55 S.2190, 19.
November 2003
[HPC-P1]
Bundesärztekammer et al.: Spezifikation des elektronischen Heilberufsausweises und der Security Module Card, Teil I: – Kommandos,
Algorithmen und Funktionen der Betriebssystemplattform,
V2.3.2 DE, 05.08.2009
[HPC-P3]
Bundesärztekammer et al.: Spezifikation des elektronischen Heilberufsausweises und der Security Module Card, Teil III: SMC – Anwendungen
und Funktionen, V2.3.2 DE, 05.08.2009
[ISO3166]
ISO/IEC 3166-1: 2006
Codes for the representations of names of countries and their subdivisions
Seite 7 von 162
[Quelle]
– Part 1: Country codes
[ISO7812]
ISO/IEC 7812-1: 2006
Cards and personal identification – Identification of issuers –
Part 1: Numbering system
[ISO7816-1]
ISO/IEC 7816-1: 1998
Identification cards - Integrated circuit cards with contacts Part 1: Physical characteristics
[ISO7816-2]
ISO/IEC 7816-2: 2007
Identification cards - Integrated circuit cards with contacts Part 2: Dimensions and location of contacts
[ISO7816-3]
ISO/IEC 7816-3: 2006
Identification cards - Integrated circuit cards with contacts Part 3: Electrical interface and transmission protocols
[ISO7816-4]
ISO/IEC 7816-4: 2005
Identification cards - Integrated circuit cards Part 4: Organization, security and commands for interchange
[ISO7816-5]
ISO/IEC 7816-5: 2004
Identification cards - Integrated circuit cards Part 5: Registration of application providers
[ISO7816-6]
ISO/IEC 7816-6: 2004
Identification cards - Integrated circuit cards Part 6: Interindustry data elements for interchange
[ISO7816-8]
ISO/IEC 7816-8: 2004
Identification cards - Integrated circuit cards Part 8: Commands for security operations
[ISO7816-9]
ISO/IEC 7816-9: 2004
Identification cards - Integrated circuit cards Part 9: Commands for card management
[ISO7816-13]
ISO/IEC 7816-13: 2007
Identification cards - Integrated circuit cards Part 13: Commands for application management in multi-application
environment
[ISO7816-15]
ISO/IEC 7816-15: 2004
Identification cards - Integrated circuit cards Part 15: Cryptographic information application
[ISO8825]
ISO/IEC 8825-1: 2002
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: 2002
Banking – Personal Identification Number (PIN) management and security
–
Seite 8 von 162
[Quelle]
Part 1: Basic principles and requirements for online PIN handling in ATM
and POS systems
[ISO9796-2]
ISO/IEC 9796-2: 2002
Information technology – Security techniques – Digital signature schemes
giving Message Recovery – Part 2: Integer factorization based
mechanisms
[ISO10118]
ISO 10118-2
[ISO10646]
Information technology – Security techniques – Hash functions, Part 2:
Hash functions using an n-bit block cipher algorithm, 2000
ISO/IEC 10646:2003
Information technology -- Universal Multiple-Octet Coded Character Set
(UCS)
[ISO10918]
ISO/IEC 10918-1
Information technology - digital compression and coding of continuoustone still images: Requirements and guidelines, 1994
[ISO11770]
ISO/IEC 11770-3: 2008
Information technology - Security techniques - Key management
Part 3: Mechanisms using asymmetrische techniques
[NIST-SHS]
NIST: FIPS Publication 180-2:
Secure Hash Standard (SHS-1), 01.08.2002
[PKCS#1]
[PKI-Reg]
[PKI-Nota]
[PP-HPC]
PKCS#1 RSA Cryptography Standard
V2.1: June 14, 2002
gematik: Registrierung einer CVC-CA der zweiten Ebene
Version 1.8.0
gematik: Festlegungen zu den Notationen von Schlüsseln und Zertifikaten
kryptographischer Objekte in der TI, Version 1.1.0
BSI: Common Criteria Protection Profile – Health Professional Card (PPHPC) with SSCD Functionality, BSI-CC-PP-0018-V2-2009, Version 2.5,
April 6th, 2009
[PP-SMC-A]
BSI: Common Criteria Protection Profile – Secure Module Card Type A
(PP-SMC-A), BSI-PP-0019, Version 1.9.1, February 1st 2008
[PP-SMC-B]
BSI: Common Criteria Protection Profile – Secure Module Card Type B
(PP-SMC-B), BSI-PP-0019, Version 1.9.1, February 1st 2008
[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
[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
Seite 9 von 162
[Quelle]
[RFC3629]
UTF-8, a transformation format of ISO 10646, November 2003
[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
[SMC-K]
gematik: Spezifikation der SMC-K, Version 1.2.0
[SSL]
Netscape: SSL3.0 Specification
[TID]
Spezifikation des Aufbaus der Telematik-ID für HBA und SMC, Version
1.0.0, 22.08.2008
[TR-03114]
BSI: TR-0311, Stapelsignatur mit dem Heilberufsausweis, Version 2.0,
19.10.2007, www.bsi.de/literat/tr/tr03114/BSI-TR-03114.pdf
[TR-03115]
BSI: TR-03115, Komfortsignatur mit dem Heilberufsausweis, Version 2.0,
19.10.2007, www.bsi.de/literat/tr/tr03115/BSI-TR-03115.pdf
[TR-03116]
BSI: TR-03116, Technische Richtlinie für die eCard-Projekte der
Bundesregierung, Version 3.0, 08.04.2009,
www.bsi.de/literat/tr/tr03116/BSI-TR-03116.pdf
Seite 10 von 162
3
3.1
Abkürzungen und Notation
Abkürzungen
AC
Attribute Certificate (Atttributzertifikat)
AID
Application Identifier (Anwendungskennung)
AKS
Auslöser KomfortSignatur
AOD
Authentication Object Directory
APDU
Application Protocol Data Unit [ISO7816-3]
ASN.1
Abstract Syntax Notation One
ASCII
American Standard Code for Information Interchange
AT
Authentication Template
ATR
Answer-to-Reset
AUT
Authentisierung
AUTD
CV-basierte Geräteauthentisierung
AUTR
CV-basierte Rollenauthentisierung
AUTO
Organisationsspezifische Authentisierung
BA
Berufsausweis
BCD
Binary Coded Decimal
BER
Basic Encoding Rules
BNA
Bundesnetzagentur
C
Zertifikat
C2C
Card-to-Card
CA
Certification Authority (Zertifizierungsdiensteanbieter)
CAMS
Card Application Management System
CAR
Certification Authority Reference
CC
Cryptographic Checksum (kryptographische Prüfsumme)
CD
Certificate Directory
CER
Canonical Encoding Rules
CG
Cryptogram
CH
Cardholder (Karteninhaber)
CHA
Certificate Holder Authorization
CHR
Certificate Holder Reference
CIA
Cryptographic Information Application
CIO
Cryptographic Information Objects
CLA
Class-Byte einer Kommando-APDU
COS
Card Operating System (Chipkartenbetriebssystem)
Seite 11 von 162
CPI
Certificate Profile Identifier
CRL
Cerificate Revocation List (Zertifikatssperrliste)
CS
CertSign (CertificateSigning)
CTA
Card Terminal Application (Kartenterminalanwendung)
CV
Card Verifiable
CVC
Card Verifiable Certificate
D,DIR
Directory
DE
Datenelement
DER
Distinguished Encoding Rules
DES
Daten Encryption Standard
DF
Dedicated File
DI
Baud rate adjustment factor
DM
Display Message
DO
Datenobjekt
DS
Digital Signature
DSI
Digital Signature Input
DTBS
Data to be signed
ECDSA
Elliptic Curve Digital Signature Algorithm
EF
Elementary File
eGK
elektronische Gesundheitskarte [eGK-P1] und [eGK-P2]
EHIC
European Health Insurance Card
ENC
Encryption
ES
Electronic Signature
FCI
File Control Information
FCP
File Control Parameter
FI
Clock rate conversion factor
FID
File Identifier
GDO
Global Data Object
GKV
Gesetzliche Krankenversicherung
GP
Global Platform
HB
Historical Bytes
HCI
Health Care Institution (Institution des Gesundheitswesens)
HP
Health Professional (Heilberufler)
HPA
Health Professional Application
HPC
Health Professional Card (Heilberufsausweis)
HPD
Health Professional related Data
ICC
Integrated Circuit Card (Chipkarte)
ICCSN
ICC Serial Number (Chip-Seriennummer)
ICM
IC Manufacturer (Kartenhersteller)
Seite 12 von 162
ID
Identifier
IFSC
Information Field Size Card
IIN
Issuer Identification Number
INS
Instruction-Byte einer Kommando-APDU
KeyRef
Key Reference
KM
Komfortmerkmal
KT
Karten-Terminal
LCS
Life Cycle Status
LSB
Least Significant Byte(s)
MAC
Message Authentication Code
MF
Master File
MII
Major Industry Identifier
MSE
Manage Security Environment
OCSP
Online Certicate Status Protocol
OD
Object Directory
OID
Object Identifier
OSIG
Organisationssignatur
PIN
Personal Identification Number
PIX
Proprietary Application Provider Extension
PK,PuK
Public Key
PKCS
Public Key Cryptography Standard (hier [PKCS#1])
PKI
Public Key Infrastructure
PKIX
Public Key Infrastructure for X.509 Certificates (IETF)
PP
Protection Profile (Schutzprofil)
PrK
Private Key
PSO
Perform Security Operation
PUK
Personal Unblocking Key (Resetting Code)
PV
Plain Value
P1
Parameter P1 einer Kommando-APDU
P2
Parameter P2 einer Kommando-APDU
QES
Qualifizierte Elektronische Signatur
RA
Registration Authority (Registrierungsinstanz)
RAM
Random Access Memory
RC
Retry Counter (Fehlbedienungszähler)
RCA
Root CA
RD
Referenzdaten
RF
Radio Frequency
RFC
Request für Comment
RFID
Radio Frequency Identification
Seite 13 von 162
RFU
Reserved for future use
RID
Registered Application Provider Identifier
RND
Random Number (Zufallszahl)
ROM
Read Only Memory
RPE
Remote PIN-Empfänger
RPS
Remote PIN-Sender
RSA
Algorithmus von Rivest, Shamir, Adleman [RSA]
SAK
Signaturanwendungskomponente
SE
Security Environment (Sicherheitsumgebung)
SFID
Short EF Identifier
SIG
Signatur
SigG
Signaturgesetz [SigG01]
SigV
Signaturverordnung [SigV01]
SK
Secret Key
SM
Secure Messaging
SMA
Security Module Application
SMC
Security Module Card
SMD
Security Module Data
SMKT
Sicherheitsmodul Kartenterminal
SN
Seriennummer
SO
Security Officer (Administrator)
SSCD
Secure Signature Creation Device
(Sichere Signaturerstellungseinheit)
SSEC
Security Status Evaluation Counter
SSEE
Sichere Signaturerstellungseinheit
SSL
Security Sockets Layer [SSL]
SUK
Stapel- und Komfortsignatur
TLV
Tag Length Value
TC
Trusted Channel
TLS
Transport Layer Security
UID
User Identification
UTF8
8-bit Unicode Transformation Format
WTLS
Wireless Transport Layer Security
ZDA
Zertifizierungsdiensteanbieter
3TDES
3-Key-Triple-DES
Seite 14 von 162
3.2
Notation
Für Schlüssel und Zertifikate wird die folgende vereinfachte Backus-Naur-Notation
verwendet (zu den Festlegungen siehe [PKI-Nota]):
<object descriptor> ::= <key descriptor> | <certificate descriptor>
<key descriptor>::= <key>.<keyholder>.<key usage>
<key>::= <private key> | <public key> | <secret key>
<private key>::= PrK (asym.)
<public key>::= PuK (asym.)
<secret key>::= SK (sym.)
<keyholder>::= <health professional> | <card holder> | <certification authority> |
<health professional card> | <card application management system> |
<health care institution> | <security module card> | <signature application component> |
<security module card terminal> |
<electronic health card>
<health professional>::= HP
<card holder>::= CH
<certification authority>::= <root certification authority> |
<certification authority for CAMS of HPC> | <certification authority for HPC> |
<certification authority for SMC> | <certification authority for eGK> |
<certification authority for comfort signature trigger>
<root certification authority>::= RCA
<certification authority for card application management system of health professional card>::=
CA_CAMS_HPC
<certification authority for health professional card>::= CA_HPC
<certification authority for security module card>::= CA_SMC
<certification authority for electronic health card>::=
CA_eGK (CA elektronische Gesundheitskarte)
<certification authority for comfort signature trigger>::= CA_KM (CA Komfortmerkmal)
<health professional card>::= HPC
<card application management system> ::= CAMS
<health care institution>::= HCI
<security module card>::= SMC
<signature application component>::= SAK
<security module card terminal>::= SMKT
<electronic health card>::= eGK (elektronische Gesundheitskarte)
<key usage>::= <organizational signature> | <encipherment> | <authentication> |
<certsign cvc> | <certsign x509>
<organizational signature>::= OSIG
<encipherment>::= ENC
<certsign cvc>::= CS
<certsign x509>::= CA
<authentication>::= AUT | <cv based authentication>
<cv based authentication>::= <role authentication> | <device authentication>
<role authentication> ::= AUTR_CVC
Seite 15 von 162
<device authentication> ::= AUTD_CVC | <remote pin sender> | <remote pin receiver> |
<stack and comfort signature card> | <comfort signature trigger> |
<signature application component>
<remote pin Sender>:: = AUTD_RPS_CVC (Remote PIN Sender)
<remote pin Receiver>::= AUTD_RPE_CVC (Remote PIN Empfänger)
<stack and comfort signature card>::= AUTD_SUK_CVC (Stapel- und Komfortsignatur)
<comfort signature trigger>::= AUTD_AKS_CVC (Auslöser Komfort Signatur)
<certificate descriptor>::=
<certificate>.<certificate holder>.<certificate usage>
<certificate>::= C
<certificate holder>::=
<health professional> | <certification authority> | <health professional card> |
<card application management system> | <security module card> |
<security module card terminal> | <electronic health card>
<certificate usage>::=
<organizational signature> | <encipherment> | <authentication> | <certsign cvc> |
<certsign x509>
Für eine Sequenz von Datenelementen wird die folgende Notation verwendet:
|| = Konkatenation von Daten
Zur Vereinfachung werden X.509v3-Zertifikate ohne Versionsnummer bezeichnet.
Seite 16 von 162
4
4.1
Der Heilberufsausweis
ATR-Kodierung
Tabelle 1 – (N2001.00) ATR-Kodierung (Sequenz von oben nach unten)
Parameter
TS
T0
TA1
TC1
TD1
TD2
TA3
TB3
TD3
TA4
CI
Tag/Length
ICM
ICT
OSV
DD
Tag/Length
1. CCB
2. CCB
3. CCB
Wert
‘3B’
'Dx' oder
‘9x’
Bedeutung
Initial Character (direct convention)
Format Character (Anzeige von TA1 / TD1), 'Dx' bedeutet, dassTC1 vorhanden
ist, '9x' bedeutet, dass TC1 nicht vorhanden ist, x = Zahl der Historical Bytes;
x = 0 empfohlen, d.h. keine Historical Bytes im ATR, sondern nur in EF.ATR
‘xx’
Interface Character (FI / DI Wert), 'xx' = '18', '95', '96' oder '97'
'FF'
Extra Guard Time Integer; zulässige Optionen sind:
a) TC1 mit dem 'FF' vorhanden (dringend empfohlen)
b) TC1 nicht vorhanden
‘81’
Interface Character (T=1, Anzeige von TD2)
‘B1’
Interface Character (T=1, Anzeige von TA3 / TB3 / TD3)
‘FE’
Interface Character (IFSC-Kodierung)
‘45’
Interface Character (BWI / CWI-Kodierung)
‘1F’
Interface Character (T=15, Anzeige von TA4)
xx000x11
Interface Character (XI / UI-Kodierung), x = herstellerspezifisch
'00' oder '80' Category Indicator Byte (erstes Byte von max. 15 Historical Bytes)
'00' bedeutet, dass ein Status Indicator in Form der letzten drei Historical Bytes
vorhanden ist; '80' bedeutet, dass ein Status Indicator als Datenobjekt
vorhanden (ein, zwei oder drei Bytes) ist.
'6x'
Compact Header des Pre-issuing Datenobjektes (PIDO)
mit x = Zahl der nachfolgenden PIDO-Bytes
'xx'
IC Manufacturer Identifier (Teil des PIDO)
Die Kennung wird von ISO an den IC-Hersteller vergeben, see www.sc17.com
IC Type (Teil des PIDO), 1 Byte falls b8 = 0 oder
'xx' oder
'xxxx'
2 Bytes, falls b8 = 1 im ersten Byte; Kodierung herstellerspezifisch
'xx'
Operating System Version (Teil der PIDO)
Kodierung herstellerspezifisch
'xx...'
Discretionary Data (Teil der PIDO), n Bytes
Kodierung herstellerspezifisch
'73'
Compact Header der Card Capabilities Bytes (CCB)
Die Card Capabilities sind auch im EF.ATR vorhanden, siehe Tabelle 4
(N2005.00)
1xx10110
Card Capabilities Byte der Selektionsmethoden
= 'x6'
b8 b7 b6 b5 b4 = 1xx10 bezeichnet die DF-Selektion mit vollständigem DFNamen und mit File Identifier, b3 = 1 bezeichnet die Unterstützung von Short
EF Identifier, b2 = 1 bezeichnet die Unterstützung von Record Number, b1 = 0
bezeichnet keine Unterstützung von Record Identifier
00100001
Card Capabilities Byte der Daten-Kodierung
= '21'
b8 = 0 bezeichnet keine Unterstützung von EFs mit TLV-Struktur, b7 b6 = 01
bezeichnet das proprietäres Verhalten der Schreibfunktionen, b5 = 0 bezeichnet
den Wert 'FF' als erstes Byte von TLV-Tagfeldern als unzulässig, b4 b3 b2 b1 =
0001 bezeichnet die Größe der Dateneinheiten in Vierbiteinheiten (Zweierpotenz), d.h. ein Byte
11010yzt
Card Capabilities Byte von Command Chaining, Längenfeldern und logischen
Kanälen
= 'Dx'
b8 = 1 bezeichnet die Unterstützung von Command Chaining für LOAD
APPLICATION (weitere Kommandos wurden nicht für Command Chaining
spezifiziert), b7 = 1 bezeichnet die Unterstützung von Extended Lc- und LeFeldern, b6 ist RFU (b6 = 0 empfohlen), b5 b4 = 10 bezeichnet die Zuweisung
Seite 17 von 162
Parameter
Tag/Length
LCS
SW1
SW2
TCK
Wert
Bedeutung
der Nummern logischer Kanäle durch die Karte, b3 b2 b1 = yzt bezeichnet die
maximale Anzahl logischer Kanäle: y, z, t nicht alle auf 1 gesetzt bedeutet
4y+2z+t+1, d.h. eins bis sieben; y = z = t = 1 bedeutet acht oder mehr
'81' oder
Compact header des Status Indicator
'82' oder '83' - nicht vorhanden, falls Category Indicator Byte = '00'
- vorhanden, falls Category Indicator Byte = '80'
'00' oder
Life Cycle Status
'05' oder '07' - 1. Status Indicator Byte, falls CI = '00' oder
- 1. Status Indicator Byte, falls CI = '80' u. Status Indicator Header = '81' o. '83'
- nicht vorhanden, falls CI = '80' und Status Indicator Header = '82'
- LCS = '05' empfohlen
'6x' oder '9x' 1. Status Word
- 2. Status Indicator Byte, falls CI = '00' oder
- 1. Status Indicator Byte, falls CI = '80' und Status Indicator header = '82' oder
- 2. Status Indicator Byte, falls CI = '80' und Status Indicator header = '83' oder
- SW1 = '90' empfohlen
'xx'
2. Status Word
- 3. Status Indicator Byte, falls CI = '00' oder
- 2. Status Indicator Byte, falls CI = '80' und Status Indicator Header = '82' oder
- 3. Status Indicator Byte, falls CI = '80' und Status Indicator Header = '83' oder
- SW2 = '00' empfohlen
'xx'
Check Character: 'xx' = exclusives OR aller ATR-Bytes;
Hinweis: Gemäß ISO/IEC 7816-3 gehört TS nicht zum ATR und geht folglich
nicht in die Berechnung der XOR-Summe ein
Tabelle 1 (N2001.00) zeigt die ATR-Kodierung für Heilberufsausweise (T = 1-Karten). Da EF.DIR ein
strukturiertes und EF.ATR ein transparentes EF ist und diese Mischung nicht sauber als "Card Service
Data Byte" gemäß ISO/IEC 7816-4 kodiert werden kann, darf dieses Byte in den Historical Bytes nicht
vorhanden sein.
4.2
Allgemeine Struktur
Die HPC enthält:
- die Root-Anwendung mit einigen EFs für allgemeine Datenobjekte auf MF-Ebene, CV-Zertifikate und
globale Schlüssel für Authentisierungsverfahren (mit denen Zugriffsrechte auf die eGK geltend
gemacht 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.
- die qualifizierte elektronische Signaturfunktion (QES) für die Signaturerstellung.
- die Anwendung mit Informationen zu den verwendeten kryptografischen Verfahren (CIA), die sich
gemäß [EN14890-1] auf die QES-Anwendung bezieht.
- die ESIGN-Anwendung für Client/Server-Authentisierung, Dokumenten-Entschlüsselung und –Umschlüsselung.
- die Anwendung mit Informationen zu den verwendeten kryptografischen Verfahren (CIA), die sich
gemäß [EN14890-1] auf die ESIGN-Anwendung bezieht.
Seite 18 von 162
Die HPC kann darüber hinaus die Anwendung für organisationsspezifische Authentisierung (AUTO)
enthalten. Diese wird für Authentisierungsmechanismen verwendet, welche für die ESIGN-Anwendung
nicht geeignet sind.
Abbildung 1 (N2002.00) zeigt die allgemeine Struktur.
MF (Root)
DF.HPA
EF.ATR
PIN.CH
EF.DIR
PrK.HPC.AUTR_CVC
DF.QES
EF.GDO
PrK.HPC.AUTD_SUK_CVC
DF.CIA.QES
EF.Version
PuK.RCA.CS
DF.ESIGN
EF.C.CA_HPC.CS
PuK.CAMS_HPC.AUT_CVC**
DF.CIA.ESIGN
EF.C.HPC.AUTR_CVC
EF.C.HPC.AUTD_SUK_CVC
SK.CAMS**
DF.AUTO*
* Diese Anwendung ist optional
** Dieser Schlüssel ist optional und muss nur dann vorhanden sein,
wenn ein CAMS mit asymmetrischer Authentisierung verwendet wird
Abbildung 1 – (N2002.00) Allgemeine Dateistruktur einer HPC
4.3
4.3.1
Root-Anwendung und Dateien auf MF-Ebene
MF
MF ist ein „Application Dedicated File“ (siehe Kapitel 8.3.1.3 in [HPC-P1]) mit den in Tabelle 2
(N2003.00) aufgeführten Eigenschaften.
Tabelle 2 – (N2003.00) Attribute von MF
Attribut
Objekttyp
Application Identifier
File Identifier
Life Cycle Status
Zugriffsregel in allen SEs
Zugriffsart
SELECT
LOAD APPLICATION
(nach HPC-Ausgabe)
Wert
Application Dedicated File
‘D27600014601’
‘3F00’
Operational state (activated)
Sicherheitsbedingung
ALWAYS
AUT(‘D27600014600' || '01’) AND
SmMac AND
SmCmdEnc
Anmerkung
Optional vorhanden
Anmerkung
Nur dann ausführbar, wenn
ein CAMS genutzt wird, siehe
Kapitel 13.
Falls ein CAMS mit symmetrischer Authentisierung eingesetzt wird, muss die
Seite 19 von 162
Sicherheitsbedingung die
Schlüsselreferenz des
entsprechenden symmetrischen Schlüssels enthalten,
d.h. AUT('13') statt
AUT(‘D27600014600' || '01’).
ACTIVATE, DEACTIVATE, DELETE
4.3.2
NEVER
EF.ATR
Die transparente Datei EF.ATR enthält ein zusammengesetztes Datenobjekt zur Anzeige der I/OPuffergrößen und das DO 'Pre-issuing data', das für die Dienste des CAMS wichtig ist. Die folgende
Tabelle zeigt die Eigenschaften von EF.ATR.
Tabelle 3 – (N2004.00) Attribute von MF / EF.ATR
Attribut
Objekttyp
File Identifier
Short File Identifier
Number of Bytes
Flag Transaction Mode
Flag Checksum
Life Cycle Status
Content
Wert
Transparent Elementary File
‘2F01’
‘1D’ = 29
COS-spezifisch
False
True
...
Anmerkung
Gemäß [ISO7816-4]
siehe Tabelle 4
(N2005.00)
Zugriffsart
SELECT, READ BINARY
ACTIVATE, DEACTIVATE, DELETE,
ERASE BINARY, UPDATE BINARY
ALWAYS
NEVER
Anmerkung
Der Inhalt von EF.ATR ist in Tabelle 4 (N2005.00), Tabelle 5 (N2006.00), Tabelle 6 (N2007.00) und
Tabelle 7 (N2008.00) definiert.
Tabelle 4 – (N2005.00) Inhalt von EF.ATR
Tag
Länge
Wert
Bedeutung
’E0’
‘xx’
’02 xx xxxx 02 xx xxxx 02 xx xxxx 02 xx xxxx’
‘66’
‘xx’
’46 xx …’ siehe Tabelle 6 (N2007.00) ||
'47 03 x6 21 Dx' siehe Tabelle 7 (N2008.00)
I/O-Puffergrößen, siehe Tabelle 5
(N2006.00)
DO Card Daten: DO Pre-issuing
data || DO Card Capabilities
Das Datenobjekt I/O-Puffergrößen in Tabelle 5 (N2006.00) enthält 4 eingebettete DOs (Tag '02’ =
Integer-Wert, Längenfeld 1 Byte mit Wert '02' oder '03', Wertefeld = max. Anzahl von Bytes der
entsprechenden APDU).
Tabelle 5 – (N2006.00) Datenobjekt Input/Output-Puffergrößen
Tag
Länge
Wert
'E0'
'xx'
'02' -L-'xxxx' || '02' -L-'xxxx' || '02'-L-'xxxx' || '02'-L-'xxxx' =
- DO max. Länge der Kommando-APDU ohne SM ||
- DO max. Länge der Antwort-APDU ohne SM ||
- DO max. Länge der Kommando-APDU mit SM ||
- DO max. Länge der Antwort-APDU mit SM
Seite 20 von 162
Anmerkung – Im Gegensatz zum Hinweis 1 in Kapitel 11.5.5 von [HPC-P1] und Hinweis 1 in Kapitel 11.5.6 von
[HPC-P1] ist es nicht möglich, maximale Längen in Abhängigkeit von bestimmten Kombinationen CLA, INS, P1
und P2 auszudrücken. Das wird möglicherweise in späteren Versionen dieses Dokuments definiert, sobald geeignete Datenstrukturen in [ISO7816-4] aufgenommen sind.
Tabelle 6 – (N2007.00) Wert des DO Pre-issuing Data (Tag ‘46’)
Länge
(Byte)
1
5
x
x
x
Bedeutung der konkatenierten Datenelemente
(höchstwertiges Byte: ICM)
IC-Herstellerkennung (siehe www.sc17.com)
Kartenherstellerkennung (siehe DIN-RA:
http://sit.sit.fraunhofer.de/_karten_ident/SIT/rid_sde)
IC-ID (Kartenhersteller-spezifisch)
COS-Version (Kartenhersteller-spezifisch)
ROM-Maske (Kartenhersteller-spezifisch)
Tabelle 7 – (N2008.00) Wert des DO Card Capabilities (Tag ‘47’)
b8 b7 b6 b5 b4 b3 b2 b1 Bedeutung des 1. Byte (‘x6’)
1
-
x
-
x
-
1
-
0
-
1
-
1
-
0
DF-Auswahl mit vollem DF-Namen
DF-Auswahl mit partiellem DF-Namen (nicht festgelegt)
DF- Auswahl mit Pfad (nicht festgelegt)
DF- Auswahl mit File Identifier
Implizite DF-Auswahl (nicht unterstützt)
Unterstützung der Short File Identifier
Unterstützung von Recordnummern
Record Identifier (nicht unterstützt)
b8 b7 b6 b5 b4 b3 b2 b1 Bedeutung de 2. Byte (‘21’)
0
-
0
-
1
-
0
-
0
0
0
1
EFs mit TLV-Struktur (nicht unterstützt)
Verhalten der Schreibfunktionen (proprietär)
Wert 'FF' als 1. Byte von BER-TLV Tagfeldern unzulässig
Größe der Dateneinheiten in Vierbit-Einheiten
(als Zweierpotenz, d.h. ’01’ = 2 Vierbit-Einheiten = 1 Byte)
b8 b7 b6 b5 b4 b3 b2 b1 Bedeutung des 3. Byte (‘Dx’)
1
-
1
-
0
-
1
0
-
-
-
-
-
y
x
z
x
t
x
Unterstützung von Command Chaining, siehe Anmerkung 1
Extended Lc und Le-Felder
b6 ist RFU (b6 = 0 empfohlen)
Zuweisung der Nummern logischer Kanäle durch die Karte
Maximale Anzahl logischer Kanäle, siehe Anmerkung 2
Anmerkung 1 – Command Chaining wird evt. für das Kommando LOAD APPLICATION gebraucht, siehe Kapitel
13.3.
Anmerkung 2 – Die Card-Capability-Bytes sind gemäß Kapitel 8.1.1.2.7 in [ISO7816-4] gestaltet. Im 3. Byte kodieren die Bits b3-b1 die maximale Anzahl logischer Kanäle, die von der Karte unterstützt wird: Wenn y, z, t nicht
durchgehend auf 1 gesetzt sind, werden 4y+2z+t+1 logische Kanäle unterstützt, d.h. eins bis sieben. y = z = t = 1
bedeutet Unterstützung von acht oder mehr logischen Kanälen. Die maximale Anzahl logischer Kanäle muss auf
einen der folgenden Werte gesetzt sein: b3b2b1 = 011 (4 Kanäle), 100 (5 Kanäle), 101 (6 Kanäle), 110 (7 Kanäle)
oder 111 (≥ 8 Kanäle).
4.3.3
EF.DIR
EF.DIR enthält die Anwendungs-Templates für MF, DF.HPA, DF.QES, DF.CIA.QES, DF.ESIGN,
DF.CIA.ESIGN, und DF.AUTO gemäß ISO/IEC 7816-4. EF.DIR erlaubt das Hinzufügen von AIDs
weiterer (nachgeladener) Anwendungen, siehe Eigenschaften von EF.DIR in der folgenden Tabelle.
Seite 21 von 162
Tabelle 8 – (N2009.00) Attribute von MF / EF.DIR
Attribut
Objekttyp
File Identifier
Number of Bytes
Maximum Number von Records
Maximum Record Länge
Flag Record LCS
Flag Checksum
Life Cycle Status
Content
Zugriffsart
SELECT, READ RECORD,
SEARCH RECORD
APPEND RECORD, UPDATE
RECORD
Wert
Linear Variable Record Elementary File
‘2F00’
‘1E’ = 30
190
10 (3 für zukünftige Verwendung)
19 Bytes
False
True
True
...
ACTIVATE, ACTIVATE
RECORD, DEACTIVATE,
DEACTIVATE RECORD,
DELETE, ERASE RECORD
NEVER
Anmerkung
10 * max. Recordlänge
siehe Tabelle 9 (N2010.00)
ALWAYS
Anmerkung
AUT(‘D27600014600' || '01’) AND
SmMac
Nur dann ausführbar, wenn ein CAMS
genutzt wird, siehe Kapitel 13. Falls ein
CAMS mit symmetrischer Authentisierung eingesetzt wird, muss die Sicherheitsbedingung die Schlüsselreferenz
des entsprechenden symmetrischen
Schlüssels enthalten, d.h. AUT('13')
statt AUT(‘D27600014600' || '01’).
Die in EF.DIR enthaltenen Anwendungs-Templates sind in Tabelle 9 (N2010.00) gezeigt.
Tabelle 9 – (N2010.00) Anwendungs-Templates in EF.DIR
Tag
Länge
Anwendungs-Template
Bedeutung
’61’
’61’
‘61’
‘08’
‘08’
‘08’
‘4F 06 D27600014601’
‘4F 06 D27600014602’
‘4F 06 D27600006601’
‘61’
‘61’
‘61’
‘0D’
’0C’
‘11’
‘4F 0B E828BD080F D27600006601’
‘4F 0A A000000167 455349474E’
‘4F 0F E828BD080F A000000167 455349474E’
‘61’
‘08’
‘4F 06 D27600014603’
Anwendungs-Template mit AID.MF
Anwendungs-Template mit AID.HPA
Anwendungs-Template mit AID.QES
(DINSIG)
Anwendungs-Template mit AID.CIA.QES
Anwendungs-Template mit AID.ESIGN
Anwendungs-Template mit
AID.CIA.ESIGN
Anwendungs-Template mit AID.AUTO
(optional)
4.3.4
EF.GDO
Tabelle 10 (N2011.00) zeigt die Eigenschaften von EF.GDO.
Seite 22 von 162
Tabelle 10 – (N2011.00) Attribute von MF / EF.GDO
Attribut
Objekttyp
File Identifier
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Wert
‘2F02’
‘02’ = 2
12
False
True
...
Zugriffsart
SELECT, READ BINARY
ALWAYS
NEVER
Anmerkung
siehe Tabelle 11
(N2012.00)
Anmerkung
EF.GDO beinhaltet in Übereinstimmung mit [Resolution190] das Datenobjekt ICC Serial Number,
siehe Tabelle 11 (N2012.00).
Tabelle 11 – (N2012.00) DO ICCSN in EF.GDO
Tag
’5A’
Länge Wert
‘0A’
‘80276 …'
Bedeutung
ICCSN
Der Aufbau des Datenobjekts ICCSN (Tag ‘5A’) für Karten im Gesundheitswesen ist in Abbildung 2
(N2013.00) gezeigt.
MII = Major Industry
Identifier
TICCSN
L
ICCSN
‘5A‘
’0A‘
20 Ziffern (10 Bytes)
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 - (N2013.00) ICCSN für Karten im Gesundheitswesen
Die Kartenausgeberschlüssel, die für die HPC verwendet werden, sind in Annex A dargestellt.
In dieser Spezifikation wird die ICCSN verwendet für:
- die Kartenidentifikation, z.B. durch ein CAMS
- die Referenzierung von Schlüsseln in CVCs.
Der Kartenherausgeber muss sicherstellen, dass die Seriennummer (SN) eineindeutig ist (insbesondere, wenn verschiedene Kartenhersteller beteiligt sind). Die zwei führenden BCDs der Seriennummer
(im
Anschluss
an
die
Kennung
des
Herausgebers)
geben
den
beteiligten
Zertifizierungsdiensteanbieter an, siehe Annex A.
Seite 23 von 162
4.3.5
EF.Version
EF.Version enthält Records fester Länge mit den Versionsnummern der Spezifikationsteile und eine
SRQ-Nummer (welche die Obergrenze der relevanten SRQs anzeigt), auf denen die Karte beruht. Die
nachfolgende Tabelle zeigt die Eigenschaften der Datei EF.Version.
Tabelle 12 – (N2014.00) Attribute von MF / EF.Version
Attribut
Objekttyp
File Identifier
Number of Bytes
Maximum Number von Records
Maximum Record Länge
Flag Record LCS
Flag Checksum
Life Cycle Status
Content
Zugriffsart
SELECT, READ RECORD,
SEARCH RECORD
UPDATE RECORD
Wert
Linear Fix Record Elementary File
‘2F10’
‘10’ = 16
20
4
5 Bytes
False
True
True
...
ACTIVATE, ACTIVATE
RECORD, APPEND RECORD,
DEACTIVATE, DEACTIVATE
RECORD, DELETE, ERASE
RECORD
NEVER
Anmerkung
siehe Tabelle 13 (N2015.00)
ALWAYS
Anmerkung
AUT(‘D27600014600' || '01’) AND
SmMac
Nur dann ausführbar, wenn ein CAMS
genutzt wird, siehe Kapitel 13. Falls ein
CAMS mit symmetrischer Authentisierung eingesetzt wird, muss die Sicherheitsbedingung die Schlüsselreferenz
des entsprechenden symmetrischen
Schlüssels enthalten, d.h. AUT('13') statt
AUT(‘D27600014600' || '01’).
Die Datei EF.Version enthält 4 Records fester Länge, siehe Tabelle 13 (N2015.00). Die ersten 3
Records zeigen die 3 Teile der HPC-Spezifikation und eine SRQ-Nummer an, die zur Karte in
Beziehung stehen. Das Tripel Versionsnummer XX.YY.ZZ des entsprechenden Spezifikationsteils ist
zusammen mit der vierstelligen SRQ-Nummer SSSS als XXYYZZSSSS in BCDs kodiert. Der letzte
Record ist für eine zukünftige Nutzung reserviert (RFU).
Tabelle 13 – (N2015.00) Inhalt von EF.Version
Recordnr.
Wert (5 Bytes)
Bedeutung
1
‘0203020000’
2
‘0203020000’
3
‘0203020000’
4
‘0000000000’
Version der unterstützten HPC-Spezifikation Teil 1, gefolgt von der
Obergrenze der SRQ-Nummern, mit der die Karte konform ist.
Hier: Version 2.3.2, keine zusätzlichen SRQs
RFU
Seite 24 von 162
4.3.6
EF.C.CA_HPC.CS
EF.C.CA_HPC.CS enthält das CV-Zertifikat des Zertifizierungsdiensteanbieters, die von der WurzelCA für das Gesundheitswesen für eine CA_HPC ausgegeben wurde. Tabelle 14 (N2016.00) zeigt die
Eigenschaften der Datei.
Tabelle 14 – (N2016.00) Attribute von MF / EF.C.CA_HPC.CS
Attribut
Objekttyp
File Identifier
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Wert
‘2F04’
‘04’ = 4
331
False
False
...
Anmerkung
siehe Tabelle 17
(N2019.00)
Zugriffsart
SELECT, READ BINARY
ALWAYS
NEVER
Anmerkung
Die Tabelle 15 (N2017.00) zeigt die Kodierung von CV-Zertifikaten für CAs und für Karten (eGK, HPC
oder SMC). Die enthaltenen OIDs zeigen an, welches Signatur- bzw. Authentisierungsschema vom
zertifizierten Schlüsselpaar verwendet wird, siehe Tabelle 16 (N2018.00).
Tabelle 15 – (N2017.00) CPI-Werte und CV-Felder
CPI
PK
OID
CHA
CHR
CAR
(1 B)
(250 B)
(7 oder 6 B)
Modulus
(256 Bytes)
|| Exponent
(4 Bytes)
'2B240304020204'
(7 Bytes)
(8 oder 12
B)
ZDAKennung
(5 Bytes) ||
Erweiterung
(3 Bytes)
(8 B)
'21'
(0 oder
7B)
-
'22'
Modulus
(256 Bytes)
|| Exponent
(4 Bytes)
'2B2403050204'
(6 Bytes)
Prefix
(6 Bytes)
|| Role
identifier
(1 Bytes)
‘00’
(1 Bytes) ||
KeyRef
(1 Bytes) ||
ICCSN
(10 Bytes)
Anmerkung
ZDAKennung
(5 Bytes) ||
Erweiterung
(3 Bytes)
CVC für eine CA,
ausgegeben von einer RCA
(signierter Schlüssel wird für
Verifikation weiterer Schlüssel
in der CVC-Kette verwendet;
Signiert ist der Hash-Wert des
CVC-Inhalts), z.B.:
C.CA_HPC.CS
ZDACVC für eGK, HPC oder
Kennung
SMC, ausgegeben von einer
(5 Bytes) || CA (signierter Schlüssel wird
Erweiterung für Card-to-card(3 Bytes)
Authentisierung verwendet),
z.B. C.HPC.AUTR_CVC,
C.HPC.AUTD_SUK_CVC
Tabelle 16 – (N2018.00) Object Identifier
OID-Name
OID-Nummer
OID-Kodierung
Registrierungsinstanz
sigS_ISO9796-2Withrsa_sha256
Signaturschema mit RSA-Signatur und DSI gemäß
ISO/IEC 9796-2 und SHA-256
authS_ISO9796-2Withrsa_sha256_mutual
Authentisierungsschema mit RSA-Signature und
DSI gemäß ISO/IEC 9796-2 und SHA-256 für
gegenseitige Authentisierung mit oder ohne Aufbau
eines gesicherten Kanals
{1 3 36 3 4 2 2 4}
‘2B240304020204’
TeleTrusT
{1 3 36 3 5 2 4}
‘2B2403050204’
TeleTrusT
Seite 25 von 162
Anmerkung – In [ISO9796-2] ist Annex A.4 relevant.
Aufbau und Inhalt des CVC in EF.C.CA_HPC.CS mit CPI = ‘21’ sind in Kapitel 7.1 von [HPC-P1] definiert und in Tabelle 17 (N2019.00) dargestellt. Die CV-Zertifikatsdatei enthält ein zusammengesetztes
Zertifikats-Datenobjekt mit Tag '7F21' (RSA-Zertifikat mit Message Recovery). Die Gesamtlänge des
Dateiinhalts beträgt 331 Bytes.
Tabelle 17 – (N2019.00) Aufbau und Inhalt eines EF mit CV-Zertifikat nach CPI = ‘21’
Tag
Länge
Wert
'7F21'
'820146'
CV-Zertifikat (326 Bytes)
Tag
Länge Wert
'5F37'
'820100' SIG.CA (256 Bytes)
Digital Signature Input für SIG.CA (‘6A’ …’BC’):
'6A' = Padding gemäß ISO9796-2 (1 Byte)
'21' = CPI (1 Byte)
PK, erster Teil des Modulus (221 Bytes)
SHA-256 Hash-Wert (32 Bytes)
Input: CPI || PK || OID || CHR || CAR, siehe Tabelle 15 (N2017.00)
'BC' = Trailer gemäß ISO9796-2 (1 Byte)
'5F38'
'3E'
Non-recoverable Teil der Signatur SIG.CA (62 Bytes):
PK, Rest des Modulus gefolgt vom Exponenten (39 Bytes)
OID (7 Bytes)
CHR (8 Bytes)
CAR (8 Bytes)
4.3.7
EF.C.HPC.AUTR_CVC
EF.C.HPC.AUTR_CVC enthält das CV-Zertifikat der HPC für rollen-basierte C2C-Authentisierung
zwischen HPC und eGK und für die Autorisierung von SMC-A und SMC-B. Die Eigenschaften der
Datei sind in der folgenden Tabelle aufgeführt.
Tabelle 18 – (N2020.00) Attribute von MF / EF.C.HPC.AUTR_CVC
Attribut
Objekttyp
File Identifier
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Wert
‘2F03’
‘03’ = 3
341
False
False
...
Anmerkung
siehe Tabelle 19
(N2021.00)
Zugriffsart
SELECT, READ BINARY
ALWAYS
NEVER
Anmerkung
Aufbau und Inhalt des CVC in EF.C.HPC.AUTR_CVC mit CPI = ‘22’ sind in Kapitel 7.1 von [HPC-P1]
definiert und in Tabelle 19 (N2021.00) dargestellt. Die CV-Zertifikatsdatei enthält ein
zusammengesetztes Zertifikat-Datenobjekt mit Tag '7F21' (RSA-Zertifikat mit Message Recovery). Die
Gesamtlänge des Dateiinhalts beträgt 341 Bytes.
Seite 26 von 162
Tabelle 228 (N2623.00) enthält die für C.HPC.AUTR_CVC relevanten “Certificate Holder
Authorizations”.
Tabelle 19 – (N2021.00) Aufbau und Inhalt eines EF mit CV-Zertifikat nach CPI = ‘22’
Tag
Länge
Wert
'7F21'
'820150'
CV-Zertifikat (336 Bytes)
Tag
Länge Wert
'5F37'
'820100' SIG.CA (256 Bytes)
Digital Signature Input für SIG.CA (‘6A’ …’BC’):
'6A' = Padding gemäß ISO9796-2 (1 Byte)
'22' = CPI (1 Byte)
PK, erster Teil des Modulus (221 Bytes)
SHA-256 Hash-Wert (32 Bytes)
Input: CPI || PK || OID || CHA || CHR || CAR, siehe Tabelle 15
(N2017.00)
'5F38'
4.3.8
'BC' = Trailer gemäß ISO9796-2 (1 Byte)
Non-recoverable Teil der Signatur SIG.CA (72 Bytes):
PK, Rest des Modulus gefolgt vom Exponenten (39 Bytes)
OID (6 Bytes)
CHA (7 Bytes)
CHR (12 Bytes)
CAR (8 Bytes)
'48'
EF.C.HPC.AUTD_SUK_CVC
EF.C.HPC.AUTD_SUK_CVC enthält das CV-Zertifikat der HPC für funktionsbasierte C2C-Authentisierung zwischen HPC/SMC-A, HPC/SMC-B und HPC/SMC-K mit der HPC als Signaturkarte für Stapelund Komfortsignaturen (SUK), um PIN-Daten und die zu signierenden Daten (DTBS) zu empfangen.
Tabelle 20 – (N2022.00) Attribute von MF / EF.C.HPC.AUTD_SUK_CVC
Attribut
Objekttyp
File Identifier
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Wert
‘2F05’
‘05’ = 5
341
False
False
...
Anmerkung
siehe Tabelle 19
(N2021.00)
Zugriffsart
SELECT, READ BINARY
ALWAYS
NEVER
Anmerkung
Aufbau und Inhalt des CVC in EF.C.HPC.AUTD_SUK_CVC mit CPI = ‘22’ sind in Kapitel 7.1 von
[HPC-P1] definiert und in Tabelle 19 (N2021.00) dargestellt. Tabelle 229 (N2624.00) enthält die für
C.HPC.AUTD_SUK_CVC relevante “Certificate Holder Authorization”.
Seite 27 von 162
4.3.9
PIN.CH
PIN.CH ist die globale PIN des Karteninhabers. Die PIN besteht aus 5 bis 8 Ziffern und ist änderbar.
Der Wiederholungszähler muss den Anfangswert 3 besitzen.
Die Nutzung eines 8-stelligen Rücksetzcodes (Personal Unblocking Key, PUK) 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 Rücksetzcode richtig oder falsch
ist. Die Eingabe des korrekten Wertes setzt den Wiederholungszähler von PIN.CH auf den Anfangswert zurück. Der Sicherheitsstatus der PIN.CH kann unbegrenzt verwendet werden, d.h. der DefaultWert von SSEC beträgt unendlich. Die folgende Tabelle zeigt die PIN-Eigenschaften:
Tabelle 21 – (N2023.00) Attribute von MF / PIN.CH
Attribut
Objekttyp
Password Identifier
Password Reference
Secret
Minimum Length
Start Retry Counter
Retry Counter
Transport Status
Flag Enabled
Start Security Status Evaluation
Counter
PUK
PUK Usage
Zugriffsart
CHANGE RD (Option ‘00’)
GET PIN STATUS
RESET RC (Option ‘00’ und ‘01’)
VERIFY
Andere
Wert
Passwort
‘01’
‘01’
....
5
3
3
Transport-PIN Zufallszahl oder
Transport-PIN abgeleitet oder
Transport-PIN fester Wert oder
Reguläres Passwort
True
Infinite
Anmerkung
Wird personalisiert
...
10
Wird personalisiert
ALWAYS
ALWAYS
ALWAYS
ALWAYS
NEVER
Anmerkung
Gemäß Kapitel 14.6.1.4 und Kapitel 14.6.5.6 in [HPC-P1] prüft das COS nur die Minimallänge (5
Ziffern) von PIN.CH, d.h. das COS kontrolliert nicht, ob die Maximallänge von 8 Ziffern übergeschritten
wird.
Das Transport-PIN-Verfahren „Reguläres Passwort“ kann insbesondere für Nachfolgekarten Bedeutung haben. Im Falle eines anderen Verfahrens wird das Kommando CHANGE REFERENCE DATA
(siehe 4.6.2) dazu verwendet, eine reguläre PIN zu setzen.
4.3.10 PrK.HPC.AUTR_CVC
PrK.HPC.AUTR_CVC ist der globale private Schlüssel für C2C-Authentisierungen zwischen HPC/eGK
und HPC/CAMS, und zur Autorisierung von SMC-A und SMC-B. Weitere Eigenschaften des
Schlüssels sind in der folgenden Tabelle dargestellt.
Seite 28 von 162
Tabelle 22 – (N2024.00) Attribute von MF / PrK.HPC.AUTR_CVC
Attribut
Objekttyp
Key Identifier
Key Reference
Private Key
Algorithm Identifier
Zugriffsart
INTERNAL AUTHENTICATE
EXTERNAL AUTHENTICATE
Andere
Wert
Privates RSA-Objekt
‘10’
‘10’
.... (2048 Bits)
rsaRoleAuthentication
rsaSessionkey4SM
Anmerkung
PWD(PIN.CH)
ALWAYS
NEVER
Anmerkung
Wird personalisiert
Der zu PrK.HPC.AUTR_CVC (mit CVC-Inhaberprofil 2,3,...) gehörende öffentliche Schlüssel ist im
Zertifikat C.HPC.AUTR_CVC enthalten.
4.3.11 PrK.HPC.AUTD_SUK_CVC
PrK.HPC.AUTD_SUK_CVC ist der globale private Schlüssel für C2C-Authentisierungen zwischen
HPC/SMC-A, HPC/SMC-B und HPC/SMC-K für die Übertragung von PIN-Daten und der DTBS zum
HPC. Weitere Eigenschaften des Schlüssels sind in der folgenden Tabelle dargestellt.
Tabelle 23 – (N2025.00) Attribute von MF / PrK.HPC.AUTD_SUK_CVC
Attribut
Objekttyp
Key Identifier
Key Reference
Private Key
Zugriffsart
Andere
Wert
Privates RSA-Objekt
‘11’
‘11’
.... (2048 Bits)
rsaRoleAuthentication
rsaSessionkey4SM
rsaSessionkey4Intro
Anmerkung
ALWAYS
ALWAYS
NEVER
Anmerkung
Wird personalisiert
Der zu PrK.HPC.AUTD_SUK_CVC (mit CVC-Inhaberprofil 53) gehörende öffentliche Schlüssel ist im
Zertifikat C.HPC. AUTD_SUK_CVC enthalten.
4.3.12 PuK.RCA.CS
PuK.RCA.CS ist der öffentliche Schlüssel der Root-CA des Gesundheitswesens für die Prüfung von
CVC-Zertifikaten, die von dieser herausgegeben werden. Die nachfolgende Tabelle zeigt die Eigenschaften des öffentlichen Schlüssels.
Seite 29 von 162
Tabelle 24 – (N2026.00) Attribute von MF / PuK.RCA.CS
Attribut
Objekttyp
Key Identifier
Key Reference
Public Key
OID
Zugriffsart
PSO: VERIFY CERTIFICATE
Andere
Wert
Öffentliches RSA-Signaturprüfungsobjekt
CAR von C.CA_HPC.CS: ZDA-Kennung (5
Bytes) || Erweiterung (3 Bytes)
.... (2048 Bits)
´2B240304020204´ = {1 3 36 3 4 2 2 4}
ALWAYS
NEVER
Anmerkung
Wird personalisiert
Wird personalisiert
Anmerkung
Die Schlüsselreferenz von PuK.RCA.CS kann aus der HPC gemäß Abbildung 3 (N2049.00)
ausgelesen werden.
4.3.13 PuK.CAMS_HPC.AUT_CVC
PuK.CAMS_HPC.AUT_CVC (optional) ist der öffentliche Schlüssel, mit dem eine Authentisierung zwischen HPC und CAMS mit der Einrichtung eines TC durchgeführt wird. Die nachfolgende Tabelle zeigt
die Eigenschaften des öffentlichen Schlüssels.
Tabelle 25 – (N2027.00) Attribute von MF / PuK.CAMS_HPC.AUT_CVC
Attribut
Objekttyp
Key Identifier
CHA
Public Key
OID
Zugriffsart
Andere
Wert
Öffentliches RSA-Authentisierungsobjekt
'000000000000000000000013' (12 Bytes)
‘D2760001460001’
.... (2048 Bits)
’2B2403050204’ = {1 3 36 3 5 2 4}
rsaSessionkey4SM
ALWAYS
ALWAYS
NEVER
Anmerkung
Wird personalisiert
Wird personalisiert
Anmerkung
PuK.CAMS_HPC.AUT_CVC muss genau dann in der Karte vorhanden sein, wenn ein CAMS mit
asymmetrischer Authentisierung verwendet wird. PuK.CAMS_HPC.AUT_CVC ist ein globaler Schlüssel mit einem einheitlichen Key Identifier und einem CAMS-spezifischen Schlüsselwert, der zudem
vom Ausgabejahr der HPC abhängen kann. Das zugehörige CAMS ist wahrscheinlich daran
gebunden, jede einzelne Karte zu identifizieren, um den passenden Schlüssel zu verwenden. Der Key
Identifier kommt als Schlüsselreferenz im Authentisierungsverfahren zwischen HPC und CAMS zum
Einsatz (siehe Kapitel 13.2.1), während die CHA in Zugriffsregeln verwendet wird, siehe Tabelle 2
(N2003.00), Tabelle 8 (N2009.00), Tabelle 12 (N2014.00) und Tabelle 101 (N2105.00).
4.3.14 SK.CAMS
SK.CAMS (optional) ist der geheime Schlüssel für die Durchführung des HPC / CAMS-Authentisierungsverfahrens mit Aufbau eines Trusted Channel. Die nachfolgende Tabelle zeigt die Eigenschaften
des Schlüssels.
Seite 30 von 162
Tabelle 26 – (N2028.00) Attribute von MF / SK.CAMS
4.4
Attribut
Objekttyp
Key Identifier
encKey
Wert
3TDES Authentication Object
'13' = 19
...
macKey
...
Zugriffsregeln in allen SEs
Zugriffsart
MUTUAL AUTHENTICATE
Other
desSessionkey4SM
PWD(PIN.CH)
NEVER
Anmerkung
Wird
personalisiert
Wird
personalisiert
Anmerkung
Sicherheitsumgebungen auf MF-Ebene
Auf MF-Ebene wird ausschließlich die Sicherheitsumgebung SE # 1 (Default-SE) verwendet. Es ist
möglich, z.B. für die entfernte PIN-Eingabe, in SE # 1 einen Trusted Channel aufzubauen.
4.5
4.5.1
Öffnen der HPC
Kommandosequenz 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:
- Umgebung des Heilberuflers
- sonstige Umgebungen
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 zur HPC gehörenden CV-Zertifikate
enthält. In anderen Umgebungen, in der z.B. die HPC nicht bekannt ist, kann es notwendig sein,
zuerst das EF.DIR, EF.GDO, EF.Version und möglicherweise auch die kryptografischen
Informationsobjekte in den EFs von DF.CIA.QES und DF.CIA.ESIGN zu lesen. Der Kartentyp kann
anhand der in EF.DIR angezeigten Kartenanwendungen bestimmt werden. Eine effiziente Weise, den
Typ einer präsentierten Karte zu bestimmen, ist die Selektion des MF mit einem SELECT Kommando
ohne Datenfeld und mit FCP in den Antwortdaten, in denen die Kennung der Root-Anwendung angezeigt wird, siehe Kapitel 4.5.2. Welcher Generation eine Karte angehört, kann an der in EF.Version
angezeigten Spezifikationsversion erkannt werden.
Im Folgenden werden das Auswählen der Root-Anwendung und das Lesen von EF.ATR, EF.GDO,
EF.DIR und EF.Version beschrieben.
4.5.2
Auswahl der Root-Anwendung
Nach dem Reset ist die Root-Anwendung automatisch ausgewählt. Zu einem späteren Zeitpunkt kann
die Root-Anwendung beispielsweise durch ein SELECT Kommando mit Anwendungskennung
ausgewählt werden, wie in Tabelle 27 (N2029.00) gezeigt ist.
Seite 31 von 162
Tabelle 27 - (N2029.00) SELECT Kommando für MF
CLA
INS
P1
P2
Lc
Datenfeld
Le
Gemäß ISO/IEC 7816-4
‘A4’ = SELECT
‘04’ = DF-Auswahl mit AID
‘0C’ = Keine FCI in der Antwort
‘06’ = Länge von AID im Datenfeld
‘D27600014601’ = AID der Root-Anwendung(MF)
Nicht vorhanden
Tabelle 28 - (N2030.00) SELECT Antwort
Datenfeld
SW1-SW2
Nicht vorhanden
‘9000’ oder spezifische Status-Bytes, siehe [HPC-P1]
Anmerkung 1 – Der FID ‘3F00’ wird nicht für die MF-Auswahl verwendet, da nur im aktuellen Verzeichnis nach
dem angegebenen FID gesucht wird, siehe Kapitel 14.2.6.10 von [HPC-P1].
Anmerkung 2 – Der AID der Root-Anwendung kann mittels SELECT Kommando mit P2 = ‘04’ und leerem Datenfeld ermittelt werden. Die Antwort enthält FCP mit dem entsprechenden AID, siehe Kapitel 8.3.3 in [HPC-P1]. Das
ermöglicht eine effiziente Bestimmung des Kartentyps.
4.5.3
Lesen von EF.ATR und EF.GDO
Zum Lesen von EF.ATR und EF.GDO wird das ISO/IEC 7816-4 Kommando READ BINARY
verwendet.
Tabelle 29 - (N2031.00) READ BINARY Kommando mit SFID
CLA
INS
P1
‘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
‘00’ = Lesen bis Dateiende
P2
Lc
Datenfeld
Le
Tabelle 30 - (N2032.00) READ BINARY Antwort
Datenfeld
SW1-SW2
4.5.4
Daten
Lesen von EF.DIR und EF.Version
Zum Lesen von EF.DIR und EF.Version wird das ISO/IEC 7816-4 Kommando READ RECORD
verwendet.
Seite 32 von 162
Tabelle 31 - (N2033.00) READ RECORD Kommando
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘B2’ = READ RECORD
‘xx’ = Recordnummer
‘F4’ = b8-b4: 11110 SFID von EF.DIR: 30
‘84’ = b8-b4: 10000 SFID von EF.Version: 16
b3-b1: 100 Lese Record P1
Nicht vorhanden
Nicht vorhanden
‘00’ = Gesamter Record
Anmerkung – In nachfolgenden Kommandos, kann der Short FID auf Null gesetzt werden (P2 = '04').
Tabelle 32 – (N2034.00) READ RECORD Antwort
Datenfeld
SW1-SW2
4.5.5
Record
Lesen der CV-Zertifikate der HPC
Zum Lesen der zu einer HPC gehörenden Zertifikate C.CA_HPC.CS, C.HPC.AUTR_CVC und
C.HPC.AUTD_SUK_CVC 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. Welche Rollen / Profile von einer neu präsentierten Karte
unterstützt werden, kann die externe Software ohne Wiedergewinnung des CVC-Signaturinputs
herausfinden, da die „Certificate Holder Authorization“ (CHA) auch im unverschlüsselten Teil des
Zertifikats enthalten ist, vgl. Tabelle 19 (N2021.00).
Tabelle 33 - (N2035.00) READ BINARY Kommando zum Lesen eines CV-Zertifikats
CLA
INS
P1, P2
- P1 = b8-b6:100
b5-b1: 00100 SFID von EF.C.CA_HPC.CS: 4
b5-b1: 00011 SFID von EF.C.HPC.AUTR_CVC: 3
b5-b1: 00101 SFID von EF.C.HPC.AUTD_SUK_CVC: 5
P2 = Offset
- ‘xxxx’ = Offset (Bit b8 von P1 = 0)
Lc
Nicht vorhanden
Datenfeld Nicht vorhanden
Le
‘000000’ = Lesen bis Dateiende
Datenfeld
SW1-SW2
CV Zertifikat
Falls die unterstützte „Extended Length“ nicht ausreicht, um das vollständige Zertifikat mit einem
einzelnen Befehl zu lesen, muss das READ BINARY Kommando mit Angabe des entsprechenden Offsets in P1-P2 wiederholt werden.
Seite 33 von 162
4.6
4.6.1
PIN-Management
PIN-Prüfung
Zur PIN-Prüfung wird das ISO/IEC 7816-4 Kommando VERIFY verwendet.
Tabelle 35 - (N2037.00) VERIFY Kommando für die PIN-Prüfung
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘20’ = VERIFY
‘00’
‘01’ = PIN.CH-Referenz
‘08’ = Länge des zugehörenden Datenfeldes
PIN (PIN-Format: siehe Kapitel 8.1.7 in [HPC-P1])
Nicht vorhanden
Tabelle 36 - (N2038.00) 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-Bytes, die in Kapitel 14.6.6.3 in [HPC-P1] spezifiziert sind,
angezeigt werden.
4.6.2
PIN-Änderung
Zur Änderung der PIN kann das ISO/IEC 7816-4 Kommando CHANGE REFERENCE DATA zu jeder
Zeit vom Heilberufler genutzt werden. Ist PIN.CH referenziert, kann das Kommando nur mit P1 = ‘00’,
d.h. mit alter und neuer PIN im Datenfeld ausgeführt werden. Die erfolgreiche Prüfung der alten PIN
setzt keinen Sicherheitsstatus der referenzierten PIN, siehe Kapitel 14.6.1.4 in [HPC-P1].
Das Kommando wird insbesondere dazu verwendet, den PIN-Transportstatus aufzuheben und eine
reguläre PIN zu setzen, siehe Kapitel 8.2.5 und 14.6.1 in [HPC-P1].
Tabelle 37 - (N2039.00) CHANGE REFERENCE DATA Kommando
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘24’ = CHANGE REFERENCE DATA
‘00’ = Ändere Referenzdaten
PIN_alt || PIN_neu (PIN-Format: siehe Kapitel 8.1.7 in [HPC-P1])
Nicht vorhanden
Seite 34 von 162
Tabelle 38 - (N2040.00) CHANGE REFERENCE DATA Antwort
Datenfeld
SW1-SW2
4.6.3
Nicht vorhanden
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, siehe
Kapitel 14.6.5.6 von [HPC-P1].
Tabelle 39 – (N2041.00) RESET RETRY COUNTER Kommando 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 Datenfeldes
- Falls P1 = ‘00’ und P2 = ’01’: Rücksetz-Code (8 Byte) gefolgt von
einer neuen PIN (8 Byte)
- wenn P1 = ‘01’: Rücksetz-Code (8 Byte)
(RC und PIN-Format: siehe Kapitel 8.1.7 in [HPC-P1])
Nicht vorhanden
Tabelle 40 - (N2042.00) RESET RETRY COUNTER Antwort
Datenfeld
SW1-SW2
4.6.4
Nicht vorhanden
Abfragen des PIN.CH-Status
Die Software kann sowohl den Authentisierungsstatus, als auch den PIN-Transportstatus mit dem
GET PIN STATUS Kommando ermitteln, siehe folgende Tabelle.
Tabelle 41 – (N2043.00) GET PIN STATUS Kommando
CLA
INS
P1
P2
Lc
Datenfeld
Le
Gemäß ISO/IEC 7816-4 für proprietäre Klasse
‘20’ = GET PIN STATUS
‘00’
Nicht vorhanden
Nicht vorhanden
Nicht vorhanden
Seite 35 von 162
Tabelle 42 – (N2044.00) GET PIN STATUS Antwort
Datenfeld
SW1-SW2
Nicht vorhanden
‘9000’ PIN-Prüfung nicht erforderlich oder
spezifische Status-Bytes, siehe [HPC-P1]
Seite 36 von 162
5
5.1
Management von Kanälen
Allgemeine Aspekte
Die Unterstützung von vier logischen Kanälen durch eine HPC ist verbindlich vorgeschrieben, siehe
Kapitel 11.4 in [HPC-P1]. Die maximale Anzahl logischer Kanäle ist in EF.ATR angegeben, siehe
Tabelle 4 (N2005.00). Jeder Kanal hat seinen eigenen von den anderen unabhängigen
Sicherheitsstatus, d.h. dass beispielsweise die erfolgreiche Eingabe einer globalen PIN in einem
Kanal keinen Sicherheitsstatus in irgendeinem anderen Kanal setzt.
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 43 – (N2045.00) MANAGE CHANNEL Kommando zur Auswahl eines logischen Kanals
CLA
INS
P1-P2
Lc
‘70’ = MANAGE CHANNEL
‘0000’ = Öffne einen logischen Kanal,
Kanalnummer im Datenfeld der Antwort
Nicht vorhanden
Datenfeld
Le
Nicht vorhanden
‘01’
Tabelle 44 - (N2046.00) MANAGE CHANNEL Antwort
Datenfeld
-
SW1-SW2
5.3
-
Nr. des logischen Kanals, zugewiesen durch die HPC
(1 Byte)
nicht vorhanden, falls kein weiterer logischer Kanal
verfügbar ist
‘9000’, falls eine Kanalnummer. zugewiesen ist
‘6881’ kein weiterer logischer Kanal verfügbar
oder spezifische Status-Bytes, siehe [HPC-P1]
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 45 – (N2047.00) MANAGE CHANNEL Kommando zum Schließen eines logischen Kanals
CLA
INS
P1-P2
Lc
‘70’ = MANAGE CHANNEL
‘8000’ = Schließen eines logischen Kanals, Kanalnummer in CLA
Nicht vorhanden
Datenfeld
Le
Nicht vorhanden
Nicht vorhanden
Seite 37 von 162
Tabelle 46 – (N2048.00) MANAGE CHANNEL Antwort
Datenfeld
SW1-SW2
Nicht vorhanden
Seite 38 von 162
6
6.1
Interaktionen zwischen HPC und eGK
Allgemeines
Für die HPC/eGK-Authentisierung sind zwei Schritte notwendig:
- die eGK muss ihre Authentizität nachweisen
- der Heilberufler muss seine Zugriffsberechtigung nachweisen
Hierfür muss eine CV-basierte Authentisierung stattfinden, nach der in der eGK der zugehörige
Sicherheitsstatus gesetzt ist, z.B. "Autorisierung des Zertifikatsinhabers (siehe Annex A) wurde erfolgreich präsentiert".
Während des Authentisierungsprozesses werden keine SM-Schlüssel erzeugt, da die HPC in der
folgenden Kommunikation mit der eGK (Lesen und Schreiben von Daten) nicht beteiligt ist.
Die HPC muss sicherstellen, dass der Authentisierungsprozess zwischen HPC und eGK nur nach
erfolgreicher Eingabe der PIN.CH durch den Heilberufler möglich ist.
6.2
Instanzen des CVC Schlüsselmanagements
Das allgemeine Modell für CV-Zertifikate und Instanzen des Schlüsselmanagements für CVCSchlüssel zeigt Abbildung 3 (N2049.00). Die Abbildung zeigt im Besonderen, wo die
Schlüsselreferenzen lokalisiert sind, die für die CVC-Prüfung und den nachfolgenden
Authentisierungsprozess benötigt werden.
Wurzel-CA Gesundheitswesen
PuK.RCA.CS
C.CA_
HPC.CS
CA
der Heilberufler
C.HPC.
AUTR_
CVC
AUT
CA
CS
CVC
PrK
PuK
= Authentisierung
= Zertifizierungsinstanz
= Certificate Signing
= CV-Zertifikat
= Privater Schlüssel
= Öffentlicher Schlüssel
Schlüsselreferenzen, die für das
CVC-basierte Authentisierungsverfahren
im HBA gesetzt werden müssen
PrK.RCA.CS
C.CA_
eGK.CS
CA
der Kostenträger
C.eGK.
AUTR_
CVC
PuK.RCA.CS ist in HBA, SMC und eGK vorhanden.
Die Schlüsselreferenz von PuK.RCA.CS (8 bytes), die vor
der Verifikation von C.CA_eGK.CS gesetzt werden muss,
ist in EF.C.CA_eGK.CS der eGK als CAR (8 bytes) am Ende
des Zertifikats enthalten.
Die Schlüsselreferenz von PuK.CA_eGK (8 bytes), die vor
der Verifikation von C.eGK.AUTR_CVC gesetzt werden
muss, ist in EF.C.eGK.AUTR_CVC der eGK als CAR
(8 bytes) am Ende des Zertifikats enthalten.
Die Schlüsselreferenz von PuK.eGK.AUTR_CVC (12 bytes),
die vor der C2C-Authentisierung gesetzt werden muss, ist
in EF.C.eGK.AUTR_CVC der eGK als CHR (12 bytes)
unmittelbar vor der CAR enthalten. Die CHR ist eine
Konkatenation von Index (1 byte, in allen Zertifikaten auf
’00’ gesetzt), Referenz auf den zugehörigen privaten
Schlüssel auf der eGK (1 byte) und Wert des DO ICCSN
(10 bytes), welches in EF.GDO der eGK enthalten ist.
CVC in HBA
(von der eGK
zu prüfen)
CVC in eGK
(von HBA
bzw. SMC zu
prüfen)
Abbildung 3 – (N2049.00) Instanzen des CVC Schlüsselmanagements, CV Zertifikate und
Schlüsselauswahl in einer HPC
Seite 39 von 162
Falls eine eGK mit einem neuen öffentlichen Schlüssel der Wurzelinstanz eingesetzt wird, werden
Cross-Zertifikate benötigt, die mit dem in der HPC 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 in der HPC vorhanden ist). Cross-Zertifikate werden von
der Wurzel-CA bereitgestellt und können z.B. in einem Konnektor gespeichert und von dort gelesen
werden.
Da die Nutzung von CV-Zertifikaten auch über Grenzen hinweg möglich ist, können Cross-Zertifikate
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 der HPC 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).
6.3
Prüfung der CV-Zertifikate der eGK
Die Prüfung der CV-Zertifikate kann von unten nach oben erfolgen, da möglicherweise der öffentliche
Schlüssel für die C2C-Authentisierung bereits in der HPC vorhanden ist, siehe Kapitel 9.1 von [HPCP1] zur persistenten Speicherung von öffentlichen Schlüsseln.
Dazu versucht die externe Software, den öffentlichen Schlüssel der eGK zu setzen, um den Authentisierungsprozess direkt starten zu können, siehe Kapitel 6.4. Falls dieser Schlüssel noch nicht vorhanden ist, wird zunächst der öffentliche Schlüssel der CA_eGK gesetzt werden, um das eGK-Zertifikat zu
prüfen und den öffentlichen Schlüssel der eGK zu importieren. Falls dies wiederum nicht möglich ist,
wird der öffentliche Schlüssel der Wurzel-CA gesetzt, um das CA-Zertifikat zu prüfen und den CASchlüssel zu importieren. Alternativ kann der Prozess mit der Verifikation des eGK-Zertifikats beginnen, da die Wahrscheinlichkeit, bereits in der HPC gespeichert zu sein, für einen CA-Schlüssel größer
ist als für einen eGK-Schlüssel.
Im Folgenden wird der herkömmliche von oben nach unten durchgeführte Prozess dargestellt, der mit
der Prüfung des CA-Zertifikats beginnt. Dazu wird der öffentliche Schlüssel der gemeinsamen WurzelCA mit dem MSE Kommando ausgewählt. Die Schlüsselreferenz kann von der Software gemäß
Abbildung 3 (N2049.00) ermittelt werden.
Tabelle 47 - (N2050.00) MSE Kommando zur Auswahl des Root-Schlüssels
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘22’ = MANAGE SECURITY ENVIRONMENT
‘81’ = SET für Verifikation
‘B6’ = Digital Signature Template
‘0A’= Länge des zugehörenden Datenfeldes
‘83 08’ || ‘xx..xx’ = DO KeyRef von PuK.RCA.CS (zum
Auffinden der Schlüsselreferenz siehe Abbildung 3
(N2049.00))
Nicht vorhanden
Tabelle 48 - (N2051.00) MSE Antwort
Datenfeld
SW1-SW2
Nicht vorhanden
Nachdem der öffentliche Wurzel-Schlüssel zur Prüfung von C.CA_eGK.CS ausgewählt worden ist,
wird das Kommando PSO: VERIFY CERTIFICATE an die HPC gesendet. Das Datenfeld enthält die
Signatur (welche den ersten Teil des Root-Zertifikats abdeckt und deren Signatur-Input im Klartext
nach der Verarbeitung der Signatur wiederhergestellt wird) und den restlichen Teil des CV-Zertifikats
Seite 40 von 162
(mit dem Schlussteil des PK-Modulus, OID, CHR, CAR), siehe Kapitel 7.1.2 in [HPC-P1] und Tabelle
17 (N2019.00).
Tabelle 49 - (N2052.00) PSO: VERIFY CERTIFICATE Kommando zur Prüfung des CA-Zertifikats
der eGK
CLA
INS
P1
P2
’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
‘000146’ = Länge des zugehörenden Datenfeldes = 326
‘5F37’ || ‘820100’ || SIG.RCA (256 Bytes) || ‘5F38’ || ‘3E’ || Nicht-wiederherstellbarer Teil der Zertifikatsignatur (62 Bytes)
Nicht vorhanden
Lc
Datenfeld
Le
Tabelle 50 - (N2053.00) PSO: VERIFY CERTIFICATE Antwort
Datenfeld
SW1-SW2
Nicht vorhanden
Jetzt ist der öffentliche Schlüssel zur Prüfung des C.eGK.AUT_CVC in der HPC gespeichert und kann
ausgewählt werden.
Tabelle 51 - (N2054.00) MSE Kommando zur Auswahl des öffentlichen Schlüssels der CA_eGK
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘81’ = SET für Verifikation
‘0A’= Länge des zugehörenden Datenfeldes
‘83 08’ || ‘xx..xx’ = DO KeyRef von PuK.CA_eGK.CS (zum
Auffinden der KeyRef siehe Abbildung 3 (N2049.00))
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
Anschließend kann das C.eGK.AUT_CVC geprüft werden.
Seite 41 von 162
Tabelle 53 - (N2056.00) PSO: VERIFY CERTIFICATE Kommando zur Prüfung von
C.eGK.AUT_CVC
CLA
INS
P1
P2
’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
Lc
Datenfeld ‘5F37’ || ‘820100’ || SIG.RCA (256 Bytes) || ‘5F38’ || ‘48’ || Nicht-wiederherstellbarer Teil der Zertifikatsignatur (72 Bytes)
Le
Nicht vorhanden
Tabelle 54 - (N2057.00) PSO: VERIFY CERTIFICATE Antwort
Datenfeld
SW1-SW2
6.4
Nicht vorhanden
Asymmetrische HPC/eGK-Authentisierung ohne Aufbau eines Trusted Channel
In der unten beschriebenen Kommandosequenz weist zunächst die eGK ihre Echtheit gegenüber der
HPC nach. Anschließend weist die HPC nach, dass sie Zugriffsrechte auf die eGK hat. Der Prozess
könnte auch in umgekehrter Reihenfolge ablaufen, da das COS nicht kontrolliert, ob zunächst die
interne oder externe Authentisierung durchgeführt werden muss. Die Kommandosequenz steht unter
Kontrolle der externen Software.
Bevor der Authentisierungsprozess durchgeführt werden kann, muss die PIN.CH erfolgreich
eingegeben werden. In einem ersten Schritt werden die Schlüsselreferenzen für PuK.eGK.AUT_CVC
und PrK.HPC.AUTR_CVC und die zugehörenden Algorithmenkennungen gesetzt.
Tabelle 55 - (N2058.00) MSE Kommando für die Schlüssel- und Algorithmenauswahl
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘81’ = SET für external Authentisierung
‘A4’ = Authentication Template in Datenfeld
‘83 0C xx ... xx’ || ‘80 01 00’
= DO KeyRef von PuK.eGK.AUT_CVC (zum Auffinden der KeyRef
siehe Abbildung 3 (N2049.00) und Anmerkung) || DO AlgID
rsaRoleCheck
Nicht vorhanden
Anmerkung – Als Schlüsselreferenz wird die CHR aus dem CV-Zertifikat der eGK verwendet. Die Referenz hat
eine Länge von 12 Bytes: Index '00' (1 Byte) || KeyRef von PrK.eGK.AUT_CVC (1 Byte) || ICCSN.eGK (10 Bytes),
siehe Kapitel 8.5.2 in [HPC-P1] zur CHR-Struktur.
Datenfeld
SW1-SW2
Nicht vorhanden
Seite 42 von 162
Tabelle 57 - (N2060.00) MSE Kommando für Schlüssel- und Algorithmenauswahl
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘41’ = SET für interne Authentisierung
‘0A’ = Länge des zugehörenden Datenfeldes
’84 01 10’ || ‘80 01 00'
= DO KeyRef von PrK.HPC.AUTR_CVC || DO AlgID rsaRoleAuthentication
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
Anmerkung – Beide MSE SET Kommandos für interne und externe Authentisierung werden unmittelbar
hintereinander ausgeführt, so dass die Sequenz der Authentisierungskommandos nicht durch ein MSE SET
Kommando unterbrochen wird, siehe Kapitel 15 in [HPC-P1].
Danach wird von der HPC eine Zufallszahl angefordert.
Tabelle 59 - (N2062.00) GET CHALLENGE Kommando
CLA
INS
P1, P2
Lc
Datenfeld
Le
‘84’ = GET CHALLENGE
‘0000’
Nicht vorhanden
Nicht vorhanden
‘08’ = Länge der erwarteten Zufallszahl = 8
Tabelle 60 - (N2063.00) 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 die HPC liefert. Um diese digitale Signatur zu erhalten, muss das
Kommando INTERNAL AUTHENTICATE mit RND.HPC || ICCSN8.HPC im Datenfeld (siehe Kapitel
14.7.4 in [HPC-P1]) an die eGK gesendet werden. Die HPC muss die Signatur der eGK prüfen.
Seite 43 von 162
Tabelle 61 – (N2064.00) EXTERNAL AUTHENTICATE Kommando zur eGK-Authentisierung
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘82’ = EXTERNAL AUTHENTICATE
‘00’ = Algorithmus der Karte bereits bekannt
‘00’ = Schlüsselreferenz der Karte bereits bekannt
Auf die Authentisierung bezogene Daten, siehe Kapitel 14.7.1 in
[HPC-P1]) und
Nicht vorhanden
Tabelle 62 – (N2065.00) EXTERNAL AUTHENTICATE Antwort
Datenfeld
SW1-SW2
Nicht vorhanden
Nachdem die eGK authentisiert ist, muss die HPC seine Zugriffsrechte auf die eGK nachweisen. Die
zuständige Software muss von der eGK vor der Sendung weiterer Kommandos eine Zufallszahl
anfordern.
Tabelle 63 - (N2066.00) INTERNAL AUTHENTICATE Kommando
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘88’ = INTERNAL AUTHENTICATE
Auf die Authentisierung bezogene Daten,
siehe Kapitel 14.7.4 in [HPC-P1],
‘0100’ = Länge der erwarteten Signature
Tabelle 64 – (N2067.00) INTERNAL AUTHENTICATE Antwort
Datenfeld
SW1-SW2
siehe [HPC-P1], Kapitel 14.7.4
Der Authentisierungs-Token (Inhalt des Antwortdatenfeldes) wird in der entsprechenden eGK geprüft
und setzt bei positivem Ergebnis in der eGK den Sicherheitsstatus "CHA mit Rollenkennung 'xx'
erfolgreich präsentiert".
Seite 44 von 162
7
7.1
Interaktionen zwischen HPC und SMC
Allgemeines
Für Interaktionen zwischen HPC/SMC weist zunächst jede Karte gegenüber der anderen Karte ihre
Echtheit nach. Dazu muss zunächst ein CV-basierter Authentisierungsprozess ablaufen, damit in beiden Karten der entsprechende Sicherheitsstatus gesetzt werden kann, d.h. “Certificate Holder Authorization y (siehe Annex A) wurde erfolgreich präsentiert”. Allgemein unterstützt die HPC die folgenden
C2C-Authentisierungsprozesse:
-
Asymmetrische Authentisierung ohne Vereinbarung von Sitzungsschlüsseln
Asymmetrische Authentisierung mit Aufbau eines Trusted Channel
Asymmetrische Authentisierung mit persistenter Speicherung von Vorstellungsschlüsseln
Symmetrische Authentisierung mit den Vorstellungsschlüsseln mit Aufbau eines Trusted Channel.
Jeder asymmetrische Authentisierungsschlüssel unterstützt allerdings nur eine Untermenge der drei
oben genannten asymmetrischen Algorithmen, siehe Tabelle 22 (N2024.00) und Tabelle 23
(N2025.00). Welcher Prozess angemessen ist, hängt von der angestrebten HPC/SMC-Interaktion
(z.B. entfernte Datenübertragung) und den betroffenen Zugriffsregeln in der Karte ab (z.B.
Kommandodaten sind mit Secure Messaging zu schützen), siehe Tabelle 65 (N2068.00). Der Prozess
wird mit der entsprechenden Algorithmenkennung mittels MSE SET Kommandos ausgewählt.
Tabelle 65 – (N2068.00) Mögliche Authentisierungsprozesse mit HPC und/oder SMC
(informativ)
Quellkarte
SMC-A
(Profil 54:
PINSender)
SMC-B
(Profil 54:
PINSender)
Zugriffsbedingung auf
Authentisierungsschlüssel der Quellkarte
Authentisierung der
Zielkarte
Authentisierung der
Zielkarte
SMC-K
Authentisierung der
(Profil 51:
Zielkarte
SAK)
RFID Token
(Profil 52:
Always
KomfortMerkmal)
Zielkarte
HPC
(Profil 53:
SSEE)
SMC-B (Profil
55: PINEmpfänger)
RFID Token
(Profil 55: PINEmpfänger)
HPC
(Profil 53:
SSEE)
SMC-B
RFID Token
HPC
(Profil 53:
SSEE)
Zugriffsbedingung auf
Authentisierungsschlüssel der Zielkarte
Anmerkung
ALWAYS
Anwendungsfall
PIN-Übertragung
ALWAYS
Anwendungsfall
PIN-Übertragung
ALWAYS
Anwendungsfall
PIN-Übertragung
ALWAYS
Kein
Anwendungsfall
ALWAYS
Kein
Anwendungsfall
ALWAYS
Anwendungsfall
PIN-Übertragung
ALWAYS
SMC-K
Authentisierung der
(Profil 51: SAK) Zielkarte
Anwendungsfall
DTBSÜbertragung
Anwendungsfall
Auslösung der
Komfort-Signatur
Für die HPC/SMC-Authentisierungsprozesse verwendet jede Seite einen privaten Schlüssel für
Geräteauthentisierung. Auf Seite der HPC werden gegenüber der SMC-A, SMC-B und SMC-K das
Seite 45 von 162
Zertifikat C.HPC.AUTD_SUK_CVC (Profil 53 Stapel- und Komfortsignatur-fähige Karte) und der
private Schlüssel PrK.HPC.AUTD_SUK_CVC genutzt. Zur Definition der Profile siehe Tabelle 229
(N2624.00).
Die Authentisierungsprozesse werden wie in Kapitel 15.4 in [HPC-P1] beschrieben durchgeführt.
Welche Seite sich zuerst authentisiert, hängt von den Zugriffsregeln der beteiligten Authentisierungsschlüssel ab. In den in Tabelle 65 (N2068.00) aufgeführten Authentisierungsprozessen muss sich die
HPC zuerst authentisieren. Beispielsweise authentisiert sich die HPC gegenüber der SMC-A zuerst,
damit ein Trusted Channel für die entfernte PIN-Eingabe aufgebaut werden kann.
Der asymmetrische Authentisierungsprozess mit Speicherung von Vorstellungsschlüsseln wird von
HPC, SMC-A, SMC-B und SMC-K unterstützt. Der Prozess liefert Schlüssel für den symmetrischen
Authentisierungsprozess, der gewöhnlich performanter als die asymmetrischen Algorithmen ist.
Die Vorstellungsschlüssel übernehmen Eigenschaften sowohl des öffentlichen, als auch des privaten
Schlüssels aus dem asymmetrischen Authentisierungsprozess, d.h. die verifizierte Rollenkennung, die
Schlüsselreferenz des öffentlichen Schlüssels (mit festgelegtem Index), die Zugriffsregel und den verwendeten Algorithmus, siehe Kapitel 8.5.2 in [HPC-P1]. Ein asymmetrischer Authentisierungsprozess
mit Aufbau eines Trusted Channel kann also durch das symmetrische Verfahren mit gespeicherten
Vorstellungsschlüsseln ersetzt werden.
7.2
Vorbereitungsschritte
Kapitel 4.5.5 beschreibt, wie die CV-Zertifikate der HPC – die auf MF-Ebene gespeichert sind – ausgelesen werden können. Es wird davon ausgegangen, dass die beteiligte Software die CVCs der HPC
nur einmal ausliest und sie z.B. zusammen mit der zugehörigen ICCSN im System speichert.
Die CV-Zertifikate der beteiligten SMC müssen geprüft werden, so dass die zugehörigen öffentlichen
Schlüssel zum Aufbau des Trusted Channel in der HPC vorhanden sind. Die folgenden CVCs müssen
verifiziert werden:
-
C.CA_SMC.CS
C.SMC.AUTD_RPS_CVC (SMC-A, SMC-B) oder C.SAK.AUTD_CVC (SMC-K)
Das Verfahren entspricht dem in Kapitel 6.3 beschriebenen Ablauf.
Falls die externe Software den Sicherheitsstatus vieler Authentisierungsschlüssel handhaben muss,
ohne einen Zustandsautomaten (der die internen Zustände verschiedener Karten abbilden könnte)
implementiert zu haben, kann sie mit dem GET SECURITY STATUS KEY Kommando den mit einer
CHA (mit Rollenkennung ungleich ’00’) verbundenen Sicherheitsstatus von der Karte erfragen, siehe
Tabelle 66 (N2069.00).
Tabelle 66 - (N2069.00) GET SECURITY STATUS KEY Kommando zur Abfrage eines bestimmten
Sicherheitsstatus
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘82’ = GET SECURITY STATUS KEY
‘80’ = Abfrage des Sicherheitsstatus
‘00’
‘0A’
- ‘5F4C 07’ || ‘D27600004000 36’ = DO CHA des Profils 54 (SMC-A, SMC-B) oder
- ‘5F4C 07’ || ‘D27600004000 33’ = DO CHA des Profils 51 (SMC-K)
Nicht vorhanden
Seite 46 von 162
Tabelle 67 - (N2070.00) GET SECURITY STATUS KEY Antwort
Datenfeld
SW1-SW2
7.3
Nicht vorhanden
- ‘9000’ Sicherheitsstatus gesetzt, siehe [HPC-P1]
- ‘63CF’ Sicherheitsstatus nicht gesetzt, siehe [HPC-P1]
Asymmetrische Authentisierung mit Aufbau eines Trusted Channel
Im ersten Teil des Verfahrens weist die HPC seine Echtheit gegenüber der SMC nach. Bevor die externe Software die folgenden Kommandos sendet, fordert sie von der SMC eine Zufallszahl an. Vor
den eigentlichen Authentisierungskommandos wird in der HPC die Schlüsselreferenz von PrK.HPC.
AUTD_SUK_CVC und die Algorithmenkennung gesetzt.
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘A4’ = Authentication Template im Datenfeld
’84 01 11’ || ‘80 01 54'
= DO KeyRef von PrK.HPC.AUTD_SUK_CVC der HPC || DO AlgID rsaSessionkey4SM
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
Darüber hinaus müssen der Schlüssel für die externe Authentisierung und der entsprechende Algorithmus in der HPC ausgewählt werden. Beide MSE SET Kommandos für interne und externe Authentisierung werden unmittelbar hintereinander ausgeführt, so dass die Sequenz der Authentisierungskommandos nicht durch ein MSE SET Kommando unterbrochen wird, siehe Kapitel 15 in [HPC-P1].
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘81’ = SET für externe Authentisierung
‘83 0C xx ... xx’ || ‘80 01 54’ = DO KeyRef von PuK.SMC.AUTD_RPS_CVC (SMC-A, SMC-B)
oder PuK.SAK.AUTD_CVC (SMC-K), siehe Anmerkung || DO AlgID rsaSessionkey4SM
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
Seite 47 von 162
Anmerkung – Als Schlüsselreferenz wird die CHR aus dem CV-Zertifikat der Gegenseite verwendet. Die Referenz
hat eine Länge von 12 Bytes: Index '00' (1 Byte) || KeyRef von PrK.SMC.AUTD_RPS_CVC oder
PrK.SAK.AUTD_CVC (1 Byte) || ICCSN.SMC (10 Bytes), siehe Kapitel 8.5.2 in [HPC-P1] zur CHR-Struktur.
Tabelle 72 – (N2075.00) INTERNAL AUTHENTICATE Kommando
CLA
INS
P1
P2
Lc
Datenfeld
Le
siehe Kapitel 14.7.4 in [HPC-P1]
‘0100’ = Länge der erwarteten Signatur
Datenfeld
SW1-SW2
Der Authentisierungs-Token (Inhalt des Antwortdatenfeldes) wird in der entsprechenden SMC geprüft
und setzt bei positivem Ergebnis in der SMC den Sicherheitsstatus "CHA mit Rollenkennung 'xx'
erfolgreich präsentiert".
Der zweite Teil des Authentisierungsprozesses umfasst die externe Authentisierung der SMC.
Zunächst wird eine Zufallszahl von der HPC angefordert.
CLA
INS
P1, P2
Lc
Datenfeld
Le
‘0000’
Nicht vorhanden
Nicht vorhanden
Datenfeld
SW1-SW2
RND.HPC (8 Bytes)
Die Zufallszahl wird der SMC zusammen mit den 8 LSB der ICCSN der HPC übergeben. Das
Ergebnis des von der SMC ausgeführten Kommandos INTERNAL AUTHENTICATE wird mit dem
Kommando EXTERNAL AUTHENTICATE an die HPC gesendet. Die HPC muss die SMC-Signatur
prüfen.
Seite 48 von 162
Tabelle 76 – (N2079.00) EXTERNAL AUTHENTICATE Kommando zur SMC-Authentisierung
CLA
INS
P1
P2
Lc
Datenfeld
Le
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
Die auf die Authentisierung bezogenen Daten enthalten Elemente zur Schlüsselableitung. Die Secure
Messaging-Schlüssel werden gemäß Kapitel 13.1 in [HPC-P1] berechnet.
7.4
Asymmetrische Authentisierung mit Speicherung von Vorstellungsschlüsseln
In der Authentisierungssequenz mit Vereinbarung von Vorstellungsschlüsseln empfängt die HPC das
erste INTERNAL AUTHENTICATE, die SMC das erste EXTERNAL AUTHENTICATE, um in der SMC
den Sicherheitsstatus zu setzen, der für die Verwendung des privaten Authentisierungsschlüssels der
SMC erforderlich ist. Bevor die Authentisierungskommandos zur HPC gesendet werden, werden die
Referenz des Schlüssels PrK.HPC.AUTD_SUK_CVC und die passende Algorithmenkennung gesetzt.
CLA
INS
P1
P2
Lc
Datenfel
d
Le
‘84 01 11 || 80 01 94’
= DO KeyRef von PrK.HPC.AUTD_SUK_CVC der HPC ||
DO AlgID rsaSessionkey4Intro
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
‘9000’ oder spezifische Status-Bytes; siehe [HPC-P1]
Darüber hinaus müssen der Schlüssel für die externe Authentisierung und der entsprechende Algorithmus in der HPC ausgewählt werden. Beide MSE SET Kommandos für interne und externe Authentisierung werden unmittelbar hintereinander ausgeführt, so dass die Sequenz der Authentisierungskommandos nicht durch ein MSE SET Kommando unterbrochen wird, siehe Kapitel 15 in [HPC-P1].
Seite 49 von 162
CLA
INS
P1
P2
Lc
Datenfel
d
Le
‘11’ = Länge des zugehörigen Datenfeldes = 17
’83 0C xx’ || ‘80 01 94'
= DO KeyRef von PuK.SMC.AUTD_RPS_CVC (SMC-A, SMC-B) oder
Puk.SAK.AUTD_CVC (SMC-K), siehe Anmerkung || DO AlgID rsaSessionkey4Intro
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
Anmerkung – Als Schlüsselreferenz wird die CHR aus dem CV-Zertifikat der Gegenseite verwendet.
Die Referenz hat eine Länge von 12 Bytes: Index '00' (1 Byte) || KeyRef von PrK.SMC.AUTD_
RPS_CVC oder PrK.SAK.AUTD_CVC (1 Byte) || ICCSN.SMC (10 Bytes), siehe Kapitel 8.5.2 in [HPCP1] zur CHR-Struktur.
Der erste Teil des Authentisierungsprozesses umfasst die interne Authentisierung der HPC. Zunächst
wird eine Zufallszahl von der SMC angefordert. Daraufhin muss ein INTERNAL AUTHENTICATE
Kommando mit RND.SMC || ICCSN8.SMC im Datenfeld an die HPC gesendet werden.
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘00’ = Key Reference der Karte bereits bekannt
Auf die Authentisierung bezogene Daten, siehe Kapitel 14.7.4 in [HPC-P1]
‘0100’ = Länge der erwarteten Authentisierungsdaten = 256
Tabelle 83 - (N2086.00) INTERNAL AUTHENTICATE Antwort
Datenfeld
SW1-SW2
Der Authentisierungs-Token (Inhalt des Antwortdatenfeldes) wird in der entsprechenden SMC geprüft
und die SMC setzt vorübergehend einen Sicherheitsstatus. Der zweite Teil des Authentisierungsprozesses umfasst die externe Authentisierung der SMC. Dazu fordert die Software zunächst eine Zufallszahl von der HPC an.
CLA
INS
P1, P2
‘0000’
Seite 50 von 162
Lc
Datenfeld
Le
Nicht vorhanden
Nicht vorhanden
Datenfeld
SW1-SW2
RND.HPC (8 bytes)
Die Zufallszahl wird der SMC zusammen mit den 8 LSB der ICCSN der HPC übergeben. Das
Ergebnis des von der SMC ausgeführten Kommandos INTERNAL AUTHENTICATE wird mit dem
Kommando EXTERNAL AUTHENTICATE an die HPC gesendet. Die HPC prüft die SMC-Signatur.
Tabelle 86 - (N2089.00) EXTERNAL AUTHENTICATE Kommando zur SMC-Authentisierung
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘00’ = Key Reference der Karte bereits bekannt
‘000100’ = Länge des zugehörigen Datenfeldes = 256
Nicht vorhanden
Tabelle 87 - (N2090.00) EXTERNAL AUTHENTICATE Antwort
Datenfeld
SW1-SW2
Nicht vorhanden
Die HPC setzt vorübergehend einen Sicherheitsstatus. Die auf die Authentisierung bezogenen Daten
enthalten Elemente zur Schlüsselableitung. Gemäß Kapitel 13.1 in [HPC-P1] werden während des
ersten Kommandos, das auf die Authentisierungssequenz folgt, die Vorstellungsschlüssel abgeleitet
und deren Attribute gesetzt. Die CHR aus dem CV-Zertifikat der SMC wird als Schlüsselreferenz
gespeichert, nachdem der Index (erstes Byte der CHR) an das berechnete Schlüsselmaterial
angepasst wurde, d.h. ‘02’ für 3TDES-Schlüssel, siehe Kapitel 8.5.2 in [HPC-P1]. Während der
Ableitung der Vorstellungsschlüssel wird der Sicherheitsstatus gelöscht, Secure Messaging wird nicht
eingeschaltet. Die Vorstellungsschlüssel werden in einer symmetrischen Authentisierung verwendet,
um Schlüssel für Secure Messaging zu vereinbaren, siehe nächstes Kapitel.
7.5
Symmetrische Authentisierung mit Aufbau eines Trusted Channel
Falls ein bestimmte HPC und eine bestimmte SMC sich bereits einander vorgestellt, d.h. eine asymmetrische Authentisierung mit persistenter Speicherung von Vorstellungsschlüsseln durchgeführt haben, können beide Karten die symmetrische Authentisierung unter Nutzung der gemeinsamen Vorstellungsschlüssel ausführen.
Bei erfolgreicher symmetrischer Authentisierung wird der Sicherheitsstatus “Erfolgreiche Prüfung der
der SMC-Rollenkennung” gesetzt, da die nachgewiesene Rollenkennung, die verwendete Schlüsselkennung und die Zugriffsregel des privaten Schlüssels auf die Vorstellungsschlüssel übergegangen
sind, siehe [HPC-P1], Kapitel 8.5.2, Kapitel 13.1.1 und Kapitel 15.6.
Die Kommandosequenz auf Seite de HPC beginnt mit dem Auswählen der Vorstellungsschlüssel und
der entsprechenden Algorithmenkennung für interne Authentisierung.
Seite 51 von 162
CLA
INS
P1
P2
Lc
Datenfeld
Le
’83 0C 02 xx...xx’ || ‘80 01 54' = DO KeyRef der Vorstellungsschlüssel in der HPC, siehe
Anmerkung || DO AlgID desSessionkey4SM
Nicht vorhanden
Anmerkung – Die Schlüsselreferenz hat eine Länge von 12 Bytes: Index '02' für 3TDES (1 Byte) || KeyRef von
PrK.SMC.AUTD_RPS_CVC oder PrK.SAK.AUTD_CVC (1 Byte) || ICCSN.SMC (10 Bytes), siehe Kapitel 8.5.2 in
[HPC-P1] zum Aufbau der Referenz von Vorstellungsschlüsseln.
Datenfeld
SW1-SW2
Nicht vorhanden
Zudem muss für die externe Authentisierung der Schlüssel und der entsprechende Algorithmus in der
HPC ausgewählt werden. Beide MSE SET Kommandos für interne und externe Authentisierung werden unmittelbar hintereinander ausgeführt, so dass die Sequenz der eigentlichen Authentisierungskommandos nicht durch ein MSE SET Kommando unterbrochen wird, siehe Kapitel 15 in [HPC-P1].
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘83 0C 02 xx ... xx’ || ‘80 01 54’ = DO KeyRef der Vorstellungsschlüssel in der HPC,
siehe Anmerkung || DO AlgID desSessionkey4SM
Nicht vorhanden
Anmerkung – Die Schlüsselreferenz hat eine Länge von 12 Bytes: Index '02' für 3TDES (1 Byte) || KeyRef von
PrK.SMC.AUTD_RPS_CVC oder PrK.SAK.AUTD_CVC (1 Byte) || ICCSN.SMC (10 Bytes), siehe Kapitel 8.5.2 in
[HPC-P1] zum Aufbau der Vorstellungsschlüsselreferenz.
Datenfeld
SW1-SW2
Nicht vorhanden
Anschließend wird eine Zufallszahl von der SMC angefordert. Dann muss ein INTERNAL AUTHENTICATE Kommando mit RND.SMC || ICCSN8.SMC im Datenfeld zur HPC gesendet werden.
Seite 52 von 162
CLA
INS
P1
P2
Lc
Datenfeld
Le
Datenfeld
SW1-SW2
Auf Seite der SMC erfolgt anschließend ein MUTUAL AUTHENTICATE Kommando. Dieses
Kommando gibt die Authentisierungsdaten der HPC an die SMC weiter. Die SMC muss die HPCAuthentisierungsdaten prüfen und die eigenen Authentisierungsdaten berechnen. Die Authentisierungsdaten der SMC (Inhalt des Antwortdatenfeldes) werden in der HPC mittels eines EXTERNAL
AUTHENTICATE Kommandos geprüft.
Tabelle 94 – (N2097.00) EXTERNAL AUTHENTICATE Kommando für die SMC-Authentisierung
CLA
INS
P1
P2
Lc
Datenfeld
Le
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
Eine erfolgreiche Prüfung setzt in der HPC den Sicherheitsstatus “CHA mit Rollenkennung 'xx'
erfolgreich präsentiert”. Ein Trusted Channel wurde aufgebaut, der nun zur gesicherten
Datenübertragung an die HPC zur Verfügung steht.
Seite 53 von 162
7.6
Autorisierungsprozesse
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 autorisierten SMC-A
oder SMC-B erreicht. Die Autorisierung der SMC ist mit der Nutzung des Schlüssels PrK.SMC.AUTR_
CVC in Authentisierungsprozessen verknüpft. Die Nutzung des Schlüssels PrK.SMC.AUTR_ CVC für
eine SMC/eGK-Authentisierung setzt gemäß seiner Zugriffsregeln die erfolgreiche Authentisierung
durch eine HPC mit der passenden Rollenkennung in der CHA des Zertifikat C.HPC.AUTR_CVC
voraus, siehe Kapitel 5.3.9 und Kapitel 5.7 in [HPC-P3] für weitere Details.
Alternativ kann für die SMC-B, die Authentisierung des Heilberuflers durch eine erfolgreiche Eingabe
der PIN.SMC erzielt werden, siehe Kapitel 6.3.10, Kapitel 6.3.11 und Kapitel 6.7 in [HPC-P3] für
weitere Details.
Die folgende Tabelle zeigt mögliche Autorisierungsprozesse gegenüber SMCs und benennt die
beteiligten Karten und Zugriffsbedingungen der Authentisierungsschlüssel.
Tabelle 96 – (N2099.00) Mögliche Autorisierungsverfahren (informativ)
Mögliche
Nutzung
Sich authenti- Sicherheitsbedingung
sierende Karte des Auth.-schlüssels
der sich authentisierenden Karte
HPC
PWD(PIN.CH)
mit Profil 2
(oder anderem
Rollenprofil)
Autorisierung
SMC-B
PWD(PIN.SMC) OR
der SMC zum
mit Profil 2
AUT(CHA des Profils 2)
Zugriff auf
(oder anderem
eGK-Daten
Rollenprofil)
SMC-A
mit Profil 2
(oder anderem
Rollenprofil)
HPC
ALWAYS
mit Profil 53
Autorisierung
der SMC zur
PIN-Übertragung an die
sich authentisierende
Karte
Autorisierung
der SMC zur
Übertragung
der DTBS an
die HPC
SMC-B
mit Profil 55
RFID Token
mit Profil 55
HPC
mit Profil 53
ALWAYS
PWD(PIN.Token) OR
ALWAYS
ALWAYS
Zielkarte
Sicherheitsbedingung des
Authentisierungsschlüssels
der Zielkarte
SMC-A mit zugehörigem Profil
SMC-B mit zugehörigem Profil
SMC-A
mit Profil 54
SMC-B
mit Profil 54
SMC-A
mit Profil 54
SMC-B
mit Profil 54
SMC-A
mit Profil 54
SMC-B
mit Profil 54
SMC-K
mit Profil 51
AUT(CHA des zugehör. Profils)
PWD(PIN.SMC) OR
PWD(PIN.SMC) OR
PWD(PIN.SMC) OR
Anmerkung – Diese Tabelle listet die Autorisierungsverfahren, die technisch aufgrund der Zugriffsregeln der
zugrunde liegenden Authentisierungsschlüssel möglich sind. Es ist damit nicht definiert, welche Anwendungsfälle
schließlich in der Praxis zugelassen werden.
Die Autorisierung der SMC-A oder SMC-B für entfernte PIN-Übertragung an die sich authentisierende
Karte (HPC, SMC-B oder RFID Token) oder die Autorisierung einer SMC-K für die Übertragung der
DTBS zur HPC ist Teil des C2C-Authentisierungprozesses, d.h. die Zielkarte authentisiert sich zuerst,
Seite 54 von 162
um der SMC die Nutzung des Authentisierungsschlüssel zum Senden der Daten zu ermöglichen,
siehe Kapitel 7.1.
Bevor die HPC eine SMC autorisiert, muss PIN.CH erfolgreich präsentiert werden. Die PIN.CHAuthentisierung und die SMC-Autorisierung können in einem beliebigen logischen Kanal der HPC
erfolgen. In einem ersten Schritt muss der private Schlüssel für die Rollenauthentisierung oder der
entsprechende Vorstellungsschlüssel (falls zuvor bei einer Rollenauthentisierung mit dem private
Schlüssel gespeichert) zusammen mit dem passenden Algorithmus ausgewählt werden.
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘A4’ = Authentication Template
‘84 01 10 || 80 01 00’
= DO KeyRef von PrK.HPC.AUTR_CVC || DO AlgID rsaRoleAuthentication
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
Anschließend wird von der SMC eine Zufallszahl (RND.SMC) angefordert. Dann muss das
Kommando INTERNAL AUTHENTICATE mit RND.SMC || ICCSN8.SMC im Datenfeld an die HPC
gesendet werden.
Tabelle 99 – (N2102.00) INTERNAL AUTHENTICATE Kommando zur Prüfung der Echtheit der
HPC für die Autorisierung einer SMC
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘0100’ = Länge erwarteten Authentisierungsdaten = 256
Datenfeld
SW1-SW2
Die von der HPC generierten Authentisierungsdaten werden von der SMC geprüft. Ist die Prüfung
erfolgreich, wird in der SMC der Sicherheitsstatus gesetzt, der die Nutzung des privaten Schlüssels
PrK.SMC.AUTR_CVC erlaubt.
Seite 55 von 162
8
8.1
Die Heilberufsanwendung
Dateistruktur und Dateiinhalt
Abbildung 4 (N2104.00) zeigt die Dateistruktur von DF.HPA.
MF
DF.HPA
EF.HPD
Abbildung 4 - (N2104.00) Dateistruktur von DF.HPA
8.1.1
DF.HPA (Health Professional Application)
DF.HPA ist eine “Application” gemäß Kapitel 8.3.1.1 in [HPC-P1], d.h. ist mittels Anwendungskennung
selektierbar. Tabelle 101 (N2105.00) zeigt die Eigenschaften des Anwendungsverzeichnisses.
Tabelle 101 – (N2105.00) Attribute von MF / DF.HPA
Attribut
Objekttyp
File Identifier
Wert
Application Directory
‘D27600014602’
-
Life Cycle Status
Zugriffsart
SELECT
LOAD APPLICATION
(after HPC issuing)
ACTIVATE, DEACTIVATE,
DELETE
NEVER
ALWAYS
AUT(‘D27600014600' || '01’) AND
SmMac AND
SmCmdEnc
Anmerkung
Herstellerspezifisch; Falls unterstützt, dann
außerhalb des Intervalls [‘1000’, ‘FEFF’];
Anmerkung
Nur dann ausführbar, wenn ein CAMS genutzt wird, siehe Kapitel 13. Falls ein CAMS
mit symmetrischer Authentisierung eingesetzt wird, muss die Sicherheitsbedingung
die Schlüsselreferenz des entsprechenden
symmetrischen Schlüssels enthalten, d.h.
AUT('13') statt AUT(‘D27600014600' || '01’).
Schlüssel und CVCs für den Authentisierungsprozess befinden sich auf MF-Ebene. Die Heilberufsanwendung erlaubt das Anlegen weiterer Dateien, falls dafür in der Zukunft eine Notwendigkeit bestehen
sollte, siehe Kapitel 13.
Seite 56 von 162
8.1.2
EF.HPD (Health Professional Data)
Das transparente Datei 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. Die
File kann immer gelesen werden, aber eine Aktualisierung ist nur nach erfolgreicher Eingabe der
PIN.CH möglich. Siehe Tabelle 102 (N2106.00) für weitere Eigenschaften der Datei.
Tabelle 102 – (N2106.00) Attribute von MF / DF.HPA / EF.HPD
Attribut
Objekttyp
File Identifier
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Zugriffsart
SELECT, READ BINARY
UPDATE BINARY
ERASE BINARY
8.2
Wert
‘D001’
‘01’ = 1
2048
False
True
...
ALWAYS
PWD(PIN.CH)
NEVER
Anmerkung
Wird personalisiert
Anmerkung
Sicherheitsumgebungen
In DF.HPA wird nur das SE # 1 verwendet.
8.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 103 - (N2107.00) SELECT Kommando für DF.HPA
CLA
INS
P1
P2
Lc
‘A4’ = SELECT
‘04’ = DF-Auswahl mittels AID
‘06’ = Länge des zugehörenden
Datenfeldes
Datenfeld ‘D27600014602’ = AID von DF.HPA
Le
Nicht vorhanden
Datenfeld
SW1-SW2
8.4
Nicht vorhanden
Lesen und Aktualisieren von EF.HPD
Seite 57 von 162
Zum Lesen von EF.HPD wird das READ BINARY Kommando verwendet.
Tabelle 105 - (N2109.00) READ BINARY Kommando zum Lesen von EF.HPD
CLA
INS
P1, P2
- P1 = b8-b6:100
b5-b1: 00001 SFID von EF.HPD: 1
P2 = Offset
- 'xxxx’ = Offset (bit 8 von P1 = 0)
Lc
Nicht vorhanden
Le
'00' oder ‘000000’
Datenfeld
SW1-SW2
Daten
Falls die unterstützte „Extended Length“ nicht ausreicht, um die Daten mit einem einzelnen Befehl zu
lesen, muss das READ BINARY Kommando mit Angabe des entsprechenden Offsets in P1-P2
wiederholt werden.
Die Aktualisierung von EF.HPD ist mit dem Kommando UPDATE BINARY nach erfolgreicher Eingabe
von PIN.CH möglich.
Tabelle 107 - (N2111.00) UPDATE BINARY Kommando für updating EF.HPD
CLA
INS
P1, P2
‘D6’ = UPDATE BINARY
- P1 = b8-b6:100
b5-b1: 00001 SFID von EF.HPD: 1
P2 = Offset
- 'xxxx’ = Offset (bit 8 von P1 = 0)
Lc
‘xx’ oder ‘00xxxx’ = Länge des zugehörenden
Datenfeldes
Datenfeld Daten
Le
Nicht vorhanden
Tabelle 108 - (N2112.00) UPDATE BINARY Antwort
Datenfeld
SW1-SW2
Nicht vorhanden
schreiben, muss das UPDATE BINARY Kommando mit Angabe des entsprechenden Offsets in P1-P2
wiederholt werden.
Seite 58 von 162
9
9.1
Anwendung für die qualifizierte elektronische Signatur (QES)
Dateistruktur und Dateiinhalt
Abbildung 5 (N2113.00) zeigt die prinzipielle Dateistruktur der QES-Anwendung, die in
Übereinstimmung mit DIN66291 definiert ist.
MF
DF.QES
PrK.HP.QES
EF.C.HP.QES
PIN.QES
EF.C.HP.QES-AC1
EF.DM
EF.C.HP.QES-AC2
EF.SSEC
EF.C.HP.QES-AC3
= Attributzertifikat
AC
= X.509-Zertifikat
C
DM = Display Message
= Heilberufler
HP
QES = Qualifizierte Elektronische Signatur
PrK = Privater Schlüssel
SSEC = Security Status Evaluation Counter
Abbildung 5 – (N2113.00) Prinzipielle Struktur der QES-Anwendung
Die QES-Anwendung besitzt EFs für das X.509-QES-Zertifikat und maximal drei Attributzertifikate.
Zusätzlich sind ein EF für eine Display Message, die bei der Remote-Nutzung einer stationären HPC
verwendet werden kann, und ein EF zur Anzeige des unterstützten Maximalwertes des SSEC
angelegt.
9.1.1
DF.QES (Qualified Electronic Signature Application)
DF.QES ist ein “Application Directory” gemäß Kapitel 8.3.1.1 in [HPC-P1], d.h. ist mittels Anwendungskennung selektierbar, siehe Kapitel 9.4. Die folgende Tabelle zeigt Eigenschaften und Zugriffsregel, die für das QES-Anwendungsverzeichnis gelten.
Tabelle 109 – (N2114.00) Attribute von MF / DF.QES
Attribut
Objekttyp
File Identifier
Wert
‘D27600006601’
-
Life Cycle Status
Zugriffsart
SELECT
LOAD APPLICATION, ACTIVATE,
DEACTIVATE, DELETE
ALWAYS
NEVER
Anmerkung
Herstellerspezifisch; Falls unterstützt,
dann außerhalb des Intervalls [‘1000’,
‘FEFF’]; siehe Kapitel 8.1.1 in [HPC-P1]
Anmerkung
Seite 59 von 162
9.1.2
PrK.HP.QES
PrK.HP.QES ist der private Schlüssel zur Berechnung von qualifizierten elektronischen Signaturen.
Die nachfolgende Tabelle zeigt die Schlüsselreferenz und andere Eigenschaften des Schlüssels. Die
Eigenschaften der PIN werden in Kapitel 9.1.3 dargestellt.
Tabelle 110 – (N2115.00) Attribute von MF / DF.QES / PrK.HP.QES
Attribut
Objekttyp
Key Identifier
Key Reference
Private Key
Key Available
Zugriffsregel in SE # 1
Zugriffsart
COMPUTE DIGITAL SIGNATURE
(P2 = ‘9E’ oder ‘AC’)
Andere
Zugriffsregel in SE # 2
Zugriffsart
COMPUTE DIGITAL SIGNATURE
(P2 = ‘9E’ oder ‘AC’)
Wert
Privates RSA-Objekt
‘04’ = 4
‘84’
.... (2048 Bits)
True
signPKCS1_V1_5
signPSS
sign9796_2_DS2
Anmerkung
PWD(PIN.QES)
Anmerkung
Einzelsignatur-Modus
Wird personalisiert
NEVER
PWD(PIN.QES) AND
AUT(‘D27600004000’ || '33') AND
SmMac AND
SmCmdEnc AND
SmRespEnc
Siehe Anmerkung
Andere
Wird personalisiert
Anmerkung
Modus für Stapel- und
Komfortsignatur, siehe
[TR-03114] und [TR-
03115]
Geräteauthentisierung
von SMC-K mit Profil 51
(SAK)
NEVER
Anmerkung – Trotz der AND-Relation der Sicherheitsbedingungen kann die HPC allein nicht ausschließen, dass
die Authentisierung mit Profil 51 ohne Vereinbarung von SM-Schlüsseln erfolgte und die SM-Schlüssel mit einem
von 51 verschiedenen Profil der Gegenseite vereinbart wurden (die Authentisierung mit Profil 51 könnte dabei
bestehen bleiben). Das wird durch zwei beschränkende Maßnahmen verhindert: Erstens kann der private
Schlüssel der SMC-K mit Profil 51 (SAK) nur unter Vereinbarung von SM-Schlüsseln oder Speicherung von
Vorstellungsschlüsseln genutzt werden. Zweitens verlangt die Zugriffsregel der dem Profil 51 zugeordneten
Authentisierungsschlüssels der SMC-K, dass sich die HPC mit Profil 53 zuerst gegenüber der SMC-K
authentisiert. Da die Speicherung von Vorstellungsschlüsseln keinen Sicherheitsstatus setzt, können nach
Authentisierung der SMC-K ggf. in der HPC vorliegende SM-Schlüssel nur aus eben jener Authentisierung
stammen.
9.1.3
PIN.QES
PIN.QES ist eine DF-spezifische PIN, die nur zum Schutz des privaten Schlüssels für die elektronische Signatur des Heilberuflers (PrK.HP.QES) gemäß SigG/SigV verwendet wird. Die PIN besteht aus
6 bis 8 Ziffern.
Die Nutzung eines 8 bis 12-stelligen Rücksetzcodes (Personal Unblocking Key, PUK) wird durch einen
Nutzungszähler beschränkt, dessen Anfangswert auf 10 gesetzt ist. Der Sicherheitsstatus von
PIN.QES kann nur für eine begrenzte Anzahl von Signaturen verwendet werden, d.h. der SSECMaximalwert ist endlich.
Die PIN-Referenz für die Kommandos VERIFY, CHANGE REFERENCE DATA und RESET RETRY
COUNTER und andere PIN-Eigenschaften sind in der folgenden Tabelle zusammengefasst.
Seite 60 von 162
Tabelle 111 – (N2116.00) Attribute von MF / DF.QES / PIN.QES
Attribut
Objekttyp
Password Identifier
Password Reference
Secret
Minimum Length
Start Retry Counter
Retry Counter
Transport Status
Flag Enabled
Counter
PUK
PUK Usage
Zugriffsart
GET PIN STATUS
RESET RC (Option ‘01’)
VERIFY
Andere
Wert
Passwort
‘01’
‘81’
....
6
3
3
Transport-PIN Zufallszahl oder
Transport-PIN abgeleitet oder
Transport-PIN fester Wert oder
Reguläres Passwort
True
SE # 1: SSEC = 1
SE # 2: 1 ≤ SSEC ≤ 250
...
10
ALWAYS
ALWAYS
ALWAYS
ALWAYS
NEVER
Anmerkung
Wird personalisiert
Max. Wert in SE # 2 wie
in EF.SSEC angezeigt
Wird personalisiert
Anmerkung
Gemäß Kapitel 14.6.1.4 und 14.6.5.6 in [HPC-P1] prüft das COS nur die minimale Länge (6 Ziffern)
der PIN.QES, d.h. das COS kontrolliert nicht, ob die maximale Länge von 8 Ziffern überschritten wird.
Die Initialisierung der PIN.QES, beispielsweise durch Nutzung einer Transport-PIN, muss den Vorgaben der BNA entsprechen. Zum Einrichten der regulären PIN dient das Kommando CHANGE REFERENCE DATA (siehe 4.6.2).
9.1.4
EF.DM
Die transparente Datei EF.DM enthält die Display Message, die dem Heilberufler anzeigt, dass ein
Trusted Channel erfolgreich aufgebaut wurde. Sie besteht aus 8 Bytes (ASCII-Zeichen). Die Display
Message kann vom Heilberufler nach erfolgreicher Eingabe seiner PIN.CH geändert werden. Weitere
Eigenschaften der Datei EF.DM zeigt die nachfolgende Tabelle.
Tabelle 112 – (N2117.00) Attribute von MF / DF.QES / EF.DM
Attribut
Objekttyp
File Identifier
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Zugriffsart
SELECT
READ BINARY
Wert
‘D004’
‘04’ = 4
8 Bytes
True
True
...
ALWAYS
{AUT(‘D27600004000’ || '33') OR
Anmerkung
Wird personalisiert
Anmerkung
Rollenauthentisierung
Seite 61 von 162
AUT(‘D27600004000’ || '36') } AND
SmMac AND
SmRspEnc
der SMC-K mit Profil 54
(SAK) oder SMC-A oder
SMC-B mit Profil 51
(PIN-Sender)
UPDATE BINARY
PWD(PIN.CH)
Zugriffsregel von
PIN.CH ist auf MFEbene definiert
ERASE BINARY
NEVER
9.1.5
EF.SSEC
Die transparente Datei EF.SSEC zeigt die SSEC-Maximalwerte an, die für eine konkrete Anwendungsumgebung der HPC gemäß Evaluierung und Bestätigung der HPC als Sichere Signaturerstellungseinheit definiert wurden. Die Eigenschaften der Datei sind in Tabelle 113 (N2118.00)
zusammengestellt.
Tabelle 113 – (N2118.00) Attribute von MF / DF.QES / EF.SSEC
Attribut
Objekttyp
File Identifier
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Wert
‘D005’
‘05’ = 5
46 Bytes
False
False
...
Anmerkung
Wird personalisiert,
siehe Tabelle 114
(N2119.00)
Zugriffsart
SELECT, READ BINARY
ALWAYS
NEVER
Anmerkung
Der Inhalt von EF.SSEC, siehe Tabelle 114 (N2119.00), wird während der Personalisierung
gespeichert. Die externe Signaturanwendungskomponente kann den Inhalt der Datei lesen, um die
Größe des Signaturstapels zu optimieren. Es ist allerdings nicht möglich, die aktuellen SSEC-Werte
aus der Karte auszulesen, da die zulässigen SSEC-Maximalwerte während der Kartenproduktion im
RAM fest implementiert werden und der aktuelle Stand vom COS verwaltet wird. Die Angaben in
EF.SSEC müssen den implementierten SSEC-Maximalwerten entsprechen.
Seite 62 von 162
Tabelle 114 – (N2119.00) Inhalt von EF.SSEC
Tag
’7B’
Länge
‘2C’
Bedeutung
Datenobjekte der Sicherheitsumgebung
Tag Länge Wert
Bedeutung
‘80’
‘01’
‘01’
Sicherheitsumgebung: 1
‘A4’ ‘11’
Tag
Länge Wert
‘82’
‘06’
‘D27600006601’
‘83’
‘01’
‘81’
‘95’
‘01’
‘08’
‘C0’
‘01’
‘01’
Tag Länge Wert
Bedeutung
‘80’
‘01’
‘02’
Sicherheitsumgebung: 2
‘A4’ ‘11’
Tag
Länge Wert
‘82’
‘06’
‘D27600006601’
‘83’
‘01’
‘81’
‘95’
‘01’
‘08’
‘C0’
‘01’
‘xx’
Bedeutung
DF-Name: DF.QES
Schlüsselreferenz: PIN.QES
Usage Qualifier: Benutzerauthentisierung
SSEC-Maximalwert: 1
Bedeutung
DF-Name: DF.QES
Schlüsselreferenz: PIN.QES
Usage Qualifier: Benutzerauthentisierung
SSEC-Maximalwert, z.B. 250
Anmerkung 1 – Abgesehen vom SSEC-Object werden unterhalb des Tag ‘7B’ die Datenobjekte gemäß [ISO78164] verwendet. Der SSEC-Maximalwert könnte auch in der CIA.QES-Datei EF.PrKD als “Common Object Attribute”
“userConsent” ausgedrückt werden. Allerdings würde ein Wert von beispielsweise 250 die in [ISO7816-15] definierte Obergrenze („cia-ub-userConsent“ = 15) überschreiten. Zudem kann das Attribut “userConsent” schwerlich
mit einzelnen Sicherheitsumgebungen verknüpft werden.
Anmerkung 2 – Die SSEC-Maximalwerte im Bereich 251-254 sollten nicht verwendet werden, da diese Werte im
COS möglicherweise eine andere Bedeutung haben. Falls ein unbegrenzter SSEC notwendig ist, muss das in
EF.SSEC durch die Kodierung ‘FF’ im SSEC-Feld angezeigt werden.
9.1.6
EF.C.HP.QES
Die transparente Datei EF.C.HP.QES enthält das X.509-Zertifikat mit dem öffentlichen Schlüssel des
Heilberuflers für die qualifizierte elektronische Signatur gemäß SiG/SigV. Die Eigenschaften der Datei
sind in Tabelle 115 (N2120.00) zusammengefasst.
Tabelle 115 – (N2120.00) Attribute von MF / DF.QES / EF.C.HP.QES
Attribut
Objekttyp
File Identifier
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Zugriffsart
SELECT, READ BINARY
Wert
‘C000’
‘10’ = 16
1536 oder auf Zertifikatslänge beschränkt
False
False
...
ALWAYS
NEVER
Anmerkung
Wird personalisiert
Anmerkung
Seite 63 von 162
9.1.7
EF.C.HP.QES-AC1, -AC2 und -AC3
Die transparenten Dateien EF.C.HP.QES-AC1, -AC2 und -AC3 können X.509-Attributzertifikate
enthalten, z.B. von einer Heilberufskammer (z.B. Ärztekammer, Apothekerkammer) oder von einer
entsprechenden Organisation (z.B. einer Ärztevereinigung). Die charakteristischen Dateiattribute und
Zugriffsregeln sind in den nachfolgenden Tabellen dargestellt.
Tabelle 116 – (N2121.00) Attribute von MF / DF.QES / EF.C.HP.QES-AC1
Attribut
Objekttyp
File Identifier
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Zugriffsart
SELECT, READ BINARY
UPDATE BINARY
Wert
‘C001’
‘01’ = 1
False
False
... Wenn leer, dann erstes Byte auf ‘00’ gesetzt
Anmerkung
ALWAYS
PWD(PIN.CH)
Anmerkung
ERASE BINARY
NEVER
Wird personalisiert
Zugriffsregel von
Attribut
Objekttyp
File Identifier
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Zugriffsart
SELECT, READ BINARY
UPDATE BINARY
Wert
‘C002’
‘02’ = 2
False
False
Anmerkung
ALWAYS
PWD(PIN.CH)
Anmerkung
ERASE BINARY
NEVER
Wird personalisiert
Zugriffsregel von
Attribut
Objekttyp
File Identifier
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Wert
‘C003’
‘03’ = 3
False
False
Anmerkung
Wird personalisiert
Seite 64 von 162
Zugriffsart
SELECT, READ BINARY
UPDATE BINARY
ERASE BINARY
ALWAYS
PWD(PIN.CH)
Anmerkung
Zugriffsregel von
NEVER
Alle TLV-kodierten X.509-Zertifikate besitzen als erstes Byte das Tag ‘30’ (eines Sequence-Objektes).
Wenn die Datei kein Zertifikat enthält, so muss das dadurch angezeigt werden, dass das erste Byte
auf ’00’ gesetzt ist.
9.2
Erzeugung einer qualifizierten elektronischen Signatur
Der Prozess zur Erzeugung einer elektronischen Signatur besteht aus mehreren Schritten, die in
Abbildung 6 (N2124.00) gezeigt werden.
Abbildung 6 - (N2124.00) Signaturprozess gemäß ISO/IEC 9796-2
Der Signaturprozess ist für die HPC so definiert, dass das Hashing vollständig außerhalb der Karte erfolgt. Da beim RSA-Verfahren der Hashwert kürzer ist als der Signatur-Input (DSI) für die Signaturberechnung, muss ein Padding-Verfahren auf den Hashwert angewendet werden, d.h. der Hashwert wird
formatiert. Das Padding wird in der HPC durchgeführt und das Padding-Verfahren, das angewendet
werden soll, muss mit dem Kommando MSE ausgewählt werden.
Seite 65 von 162
9.3
Sicherheitsumgebungen
Im DF.QES gibt es zwei Sicherheitsumgebungen (SEs):
-
SE # 1: Voreingestelltes SE zur Nutzung der Signaturfunktion für Einzelsignaturen. Die Nutzung
eines Trusted Channel ist nicht vorgeschrieben aber möglich.
-
SE # 2: SE zur Nutzung der Signaturfunktion für Stapel- und Komfortsignaturen. Zwischen
HPC/SMC-K wird ein Trusted Channel genutzt, um die zu signierenden Daten in der geschützten
Umgebung des Heilberuflers (wird von der Karte geprüft) zu übertragen.
Anmerkung – Für die Stapel- und Komfortsignatur wird die PIN mit oder ohne Trusted Channel in SE # 2 zur HPC
übertragen. Muss die PIN entfernt eingegeben werden, so kontrolliert die externe Software, dass die PIN in einem
Trusted Channel übertragen wird.
9.4
Auswahl der QES-Anwendung
Vor Selektion der Anwendung kann es notwendig sein, einen weiteren logischen Kanal zu öffnen, siehe Kapitel 5.2. Die QES-Anwendung wird mit dem folgenden SELECT Kommando ausgewählt.
Tabelle 119 - (N2125.00) SELECT Kommando für DF.QES
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘A4’ = SELECT
'0C' = Keine FCI in der Antwort
Datenfeldes
‘D27600006601’ = AID von DF.QES
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
Mit der DF-Auswahl ist die Sicherheitsumgebung SE # 1 implizit gewählt.
9.5
Auswahl der Sicherheitsumgebung
Falls die QES-Anwendung für die Stapel- und Komfortsignatur verwendet werden soll, dann muss, bevor irgendein Kommando nach der Auswahl der Anwendung gesendet wird, die Sicherheitsumgebung
SE # 2 mit dem Kommando MSE unter Nutzung der RESTORE-Funktion ausgewählt werden.
Seite 66 von 162
Tabelle 121 - (N2127.00) MSE Kommando zur SE-Auswahl für die Stapel- und Komfortsignatur
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘F3’ = RESTORE
‘02’ = SE # 2
Nicht vorhanden
Nicht vorhanden
Nicht vorhanden
Datenfeld
SW1-SW2
9.6
Nicht vorhanden
Lesen und Aktualisieren der Display Message
Wenn der Authentisierungsprozess vor der QES-Berechnung einen Trusted Channel aufgebaut hat,
kann die Display Message ausgelesen und dem Heilberufler als Zusicherung dienen, dass nachfolgende Kommandos Secure Messaging nutzen. Allerdings wird das Lesen der Display Message nicht
von der HPC kontrolliert. Zum Auslesen der Display Message wird das READ BINARY Kommando
verwendet.
Tabelle 123 - (N2129.00) READ BINARY Kommando zum Lesen der Display Message
CLA
INS
P1
'84' = b8-b6:100
b5-b1: 00100 SFID von EF.DM: 4
P2
‘00’ = Offset
Lc
Nicht vorhanden
Le
'08' = Länge der erwarteten Zufallszahl = 8
Anmerkung – Jede Anwendung mit Trusted Channel (DF.QES und DF.ESIGN) hat ihre eigene Datei EF.DM mit
SFID 4.
Datenfeld
SW1-SW2
Display Message
Die Display Message kann mit dem UPDATE BINARY Kommando nach erfolgreicher Eingabe der
PIN.CH geändert werden.
Seite 67 von 162
Tabelle 125 - (N2131.00) UPDATE BINARY Kommando zum Ändern der Display Message
CLA
INS
P1
b8-b6:100
b5-b1: 00100 SFID von EF.DM: 4
P2
‘00’ = Offset
Lc
Datenfeldes
Datenfeld Neue Display Message (8 Bytes)
Le
Nicht vorhanden
Datenfeld
SW1-SW2
9.7
9.7.1
Nicht vorhanden
PIN-Management
Prüfung der PIN
Für die PIN-Prüfung wird das ISO/IEC 7816-4 Kommando VERIFY genutzt.
Tabelle 127 - (N2133.00) VERIFY Kommando zur PIN-Prüfung
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘20’ = VERIFY
‘00’
‘81’ = PIN.QES Referenz
PIN (Format: siehe Kapitel 8.1.7 in [HPC-P1])
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
Falls die eingegebene PIN falsch war und zusätzliche Versuche erlaubt sind, muss die Zahl der noch
möglichen Versuche in den Status Bytes, die in Kapitel 14.6.6.3 von [HPC-P1] spezifiziert sind,
angezeigt werden.
9.7.2
Änderung der PIN
Zur Änderung der PIN kann das ISO/IEC 7816-4 Kommando CHANGE REFERENCE DATA zu jeder
Zeit vom Heilberufler genutzt werden. Wenn PIN.QES referenziert ist, kann das Kommando nur mit P1
= ‘00’ ausgeführt werden, d.h. mit alter und neuer PIN im Datenfeld. Die erfolgreiche Prüfung der alten
PIN setzt für die referenzierte PIN keinen Sicherheitsstatus, siehe Kapitel 14.6.1 in [HPC-P1].
Seite 68 von 162
Das Kommando wird insbesondere dazu genutzt, den Transportstatus der PIN aufzuheben und die reguläre PIN zu setzen, siehe Kapitel 8.2.5 und 14.6.1 in [HPC-P1].
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘00’ = Ändern der Referenzdaten
‘81’ = PIN.QES-Referenz
Nicht vorhanden
Datenfeld
SW1-SW2
9.7.3
Nicht vorhanden
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 des referenzierten PINObjekts wird durch dieses Kommando weder gesetzt noch beeinflusst, siehe Kapitel 14.6.5 von [HPCP1]. Damit ist vor der Nutzung des PrK.HP.QES weiter die erfolgreiche Eingabe der PIN.QES
notwendig. Die Nutzung des Fehlbedienungszählers muss den Vorgaben der Bundesnetzagentur
entsprechen. Gemäß den aktuellen Vorgaben darf mit dem RESET RETRY COUNTER Kommando
keine neue PIN.QES gesetzt werden.
Tabelle 131 – (N2137.00) RESET RETRY COUNTER Kommando zum Rücksetzen des
Fehlbedienungszählers
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘01’
‘81’ = Referenz der PIN.QES, zu der der Rücksetzcode (“PUK”)
gemäß ISO/IEC 7816-4 gehört
Rücksetzcode ("PUK", Format: siehe Kapitel 8.1.7 in [HPC-P1])
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
Seite 69 von 162
9.7.4
Abfrage des PIN.QES-Status
Die Software kann den Status der PIN mit dem GET PIN STATUS Kommando abfragen, siehe
folgende Tabelle.
Tabelle 133 – (N2139.00) GET PIN STATUS Kommando
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘20’ = GET PIN STATUS
‘00’
‘81’ = PIN.QES-Referenz
Nicht vorhanden
Nicht vorhanden
Nicht vorhanden
Tabelle 134 – (N2140.00) GET PIN STATUS Antwort
Datenfeld
SW1-SW2
9.8
Nicht vorhanden
‘9000’ Verifikation nicht erforderlich oder
spezifische Status-Bytes, siehe [HPC-P1]
Berechnung einer QES
Das Signieren erfolgt, nachdem die Daten außerhalb der HPC vollständig gehasht wurden. Bevor das
Kommando PSO: COMPUTE DIGITAL SIGNATURE zur HPC gesendet wird, muss der private Signaturschlüssel und der Algorithmus ausgewählt werden.
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘41’ = SET für Berechnung
‘84 01 84’ || ‘80 01 yy’ = DO KeyRef von PrK.HP.QES || DO AlgID
‘yy’ = ‘02’: signPKCS1_V1_5
‘yy’ = ‘05’: signPSS
‘yy’ = ‘07’: sign9796_2_DS2
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
Seite 70 von 162
Tabelle 137 - (N2143.00) PSO: COMPUTE DIGITAL SIGNATURE Kommando
CLA
INS
P1
P2
‘2A’ = PERFORM SECURITY OPERATION: COMPUTE DIGITAL SIGNATURE
‘9E’ = Rückgabe der digitalen Signatur
- ‘9A’ = Datenfeld enthält die Daten, die signiert oder in den Digital Signature
Input (DSI) integriert werden sollen (für PKCS#1 SSA-V1.5 und PKCS#1 PSS)
- ‘AC’ = Datenfeld enthält Datenobjekte mit Datenelementen, die signiert oder in
den Digital Signature Input integriert werden sollen (für ISO9796-2 DS2)
Lc
‘00xxxx’ = Länge des zugehörenden Datenfeldes
Datenfeld - DSI gemäß ISO9796-2 DS2 oder
- DSI gemäß PKCS#1 SSA-V1.5 oder
- DSI gemäß PKCS#1 PSS
Le
‘0100’ = Länge der erwarteten digitalen Signatur = 256
Tabelle 138 - (N2144.00) PSO: COMPUTE DIGITAL SIGNATURE Antwort
Datenfeld
SW1-SW2
9.9
Digitale Signatur
Lesen der zu QES gehörenden Zertifikate
Zum Lesen des X.509-QES-Zertifikates oder eines Attributzertifikates wird das Kommando READ
BINARY verwendet.
Tabelle 139 - (N2145.00) READ BINARY Kommando zum Lesen der QES-Zertifikate
CLA
INS
P1, P2
- P1 = b8-b6: 100
b5-b1: 10000 SFID von EF.C.HP.QES: 16
00001 SFID von EF.C.HP.QES-AC1: 1
P2 = Offset
Lc
Nicht vorhanden
Le
'000000'
Datenfeld
SW1-SW2
Zertifikatsdaten
Seite 71 von 162
Falls die unterstützte „Extended Length“ nicht ausreicht, um das vollständige Zertifikat mit einem
einzelnen Befehl zu lesen, muss das READ BINARY Kommando mit Angabe des entsprechenden Offsets in P1-P2 wiederholt werden.
9.10 Schreiben von Attributzertifikaten
Zum Aktualisieren der Attributzertifikate (siehe Zugriffsbedingungen in Tabelle 116 (N2121.00),
Tabelle 117 (N2122.00) und Tabelle 118 (N2123.00)) muss das ISO/IEC 7816-4 Kommando UPDATE
BINARY verwendet werden.
Tabelle 141 - (N2147.00) UPDATE BINARY Kommando zum Schreiben eines neuen
Attributzertifikats in die HPC
CLA
INS
P1, P2
- P1 = b8-b6: 100
b5-b1:
P2 = Offset
Lc
Datenfeld Daten
Le
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
wiederholt werden.
Seite 72 von 162
10 Die ESIGN-Anwendung
10.1 Dateistruktur und Dateiinhalt
Abbildung 7 (N2149.00) zeigt die prinzipielle Struktur der ESIGN-Anwendung, die in Übereinstimmung
mit [EN14890-1] definiert ist.
MF
DF.ESIGN
EF.C.HP.AUT
PrK.HP.AUT
EF.C.HP.ENC
PrK.HP.ENC
EF.DM
AUT
C
DM
ENC
HP
= Authentisierung
= Zertifikat
= Display Message
= Verschlüsselung
= Heilberufler
Abbildung 7 – (N2149.00) Prinzipielle Struktur von DF.ESIGN
10.1.1 DF.ESIGN
DF.ESIGN ist ein “Application Directory” gemäß Kapitel 8.3.1.1 in [HPC-P1], d.h. ist mittels Anwendungskennung selektierbar, siehe Kapitel 10.3. Tabelle 143 (N2150.00) zeigt die Eigenschaften des
Anwendungsverzeichnisses.
Tabelle 143 – (N2150.00) Attribute von MF / DF.ESIGN
Attribut
Objekttyp
File Identifier
Wert
'A000000167 455349474E’
-
Life Cycle Status
Zugriffsart
SELECT
DEACTIVATE, DELETE
ALWAYS
NEVER
Anmerkung
Anmerkung
10.1.2 PrK.HP.AUT
PrK.HP.AUT ist der private Schlüssel für Client/Server-Authentisierung. Die Schlüsselreferenz und
weitere Eigenschaften des privaten Schlüssels werden in der folgenden Tabelle aufgeführt.
Seite 73 von 162
Tabelle 144 – (N2151.00) Attribute von MF / DF.ESIGN / PrK.HP.AUT
Attribut
Objekttyp
Key Identifier
Key Reference
Private Key
Key Available
Wert
Privates RSA-Objekt
‘02’ = 2
‘82’
.... (2048 Bits)
True
INTERNAL AUTHENTICATE:
rsaClientAuthentication
Anmerkung
Wird personalisiert
Wird personalisiert
PSO: COMPUTE DIGITAL
SIGNATURE:
signPKCS_V1_5
signPSS
sign9796_2_DS2
Zugriffsart
INTERNAL AUTHENTICATE,
PSO: COMPUTE DIGITAL SIGNATURE
(P2 = ‘9E’ oder ‘AC’)
Andere
PWD(PIN.CH)
Anmerkung
Die Zugriffsregel für
NEVER
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] und [TR-03116].
10.1.3 PrK.HP.ENC
PrK.HP.ENC ist der private Schlüssel für das Entschlüsseln von Dokumenten-Chiffrierungsschlüsseln.
Die Schlüsselreferenz und weitere Eigenschaften des privaten Schlüssels werden in der folgenden
Tabelle aufgeführt.
Tabelle 145 – (N2152.00) Attribute von MF / DF.ESIGN / PrK.HP.ENC
Attribut
Objekttyp
Key Identifier
Key Reference
Private Key
Key Available
Wert
Privates RSA-Objekt
‘03’ = 3
‘83’
.... (2048 Bits)
True
rsaDecipherOaep
rsaDecipherPKCS1_V1_5
Anmerkung
Zugriffsart
PSO: DECIPHER, PSO:
TRANSCIPHER
PWD(PIN.CH)
Anmerkung
Die Zugriffsregel für
Andere
NEVER
Wird personalisiert
Wird personalisiert
10.1.4 EF.DM
Das transparente File EF.DM enthält dieselbe Display Message wie in Kapitel 9.1.4. beschrieben. Die
folgende Tabelle zeigt die Eigenschaften der Datei.
Seite 74 von 162
Tabelle 146 – (N2153.00) Attribute von MF / DF.ESIGN / EF.DM
Attribut
Objekttyp
File Identifier
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Zugriffsart
SELECT
READ BINARY
Wert
‘D004’
‘04’ = 4
8 Bytes
True
True
...
ALWAYS
{AUT(‘D27600004000’ || '33') OR
AUT(‘D27600004000’ || '36') } AND
SmMac AND
SmRspEnc
UPDATE BINARY
PWD(PIN.CH)
ERASE BINARY
NEVER
Anmerkung
Wird personalisiert
Anmerkung
Geräteauthentisierung
der SMC-K mit Profil 54
(SAK) oder SMC-A oder
SMC-B mit Profil 51
(PIN-Sender)
Die Zugriffsregel von
10.1.5 EF.C.HP.AUT
EF.C.HP.AUT enthält das X.509-AUT-Zertifikat des Heilberuflers. Die Eigenschaften der Zertifikatsdatei sind in der folgenden Tabelle dargestellt.
Tabelle 147 – (N2154.00) Attribute von MF / DF.ESIGN / EF.C.HP.AUT
Attribut
Objekttyp
File Identifier
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Wert
‘C500’
‘01’ = 1
False
False
...
Zugriffsart
SELECT, READ BINARY
ALWAYS
NEVER
Anmerkung
siehe Annex C
Anmerkung
10.1.6 EF.C.HP.ENC
EF.C.HP.ENC enthält das X.509-ENC-Zertifikat des Heilberuflers. Die Eigenschaften der Zertifikatsdatei sind in der folgenden Tabelle dargestellt.
Seite 75 von 162
Tabelle 148 – (N2155.00) Attribute von MF / DF.ESIGN / EF.C.HP.ENC
Attribut
Objekttyp
File Identifier
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Wert
‘C200’
‘02’ = 2
False
False
...
Zugriffsart
SELECT, READ BINARY
ALWAYS
NEVER
Anmerkung
siehe Annex C
Anmerkung
10.2 Sicherheitsumgebungen
DF.ESIGN wird ausschließlich in SE # 1 (Default SE) genutzt. Es ist möglich, in SE # 1 einen Trusted
Channel aufzubauen, um beispielsweise Remote-Konfigurationen mit einer stationären HPC zu ermöglichen.
10.3 Auswahl der ESIGN-Anwendung
Die Auswahl der ESIGN-Anwendung erfolgt mit dem Kommando SELECT.
Tabelle 149 - (N2156.00) SELECT Kommando für DF.ESIGN
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘A4’ = SELECT
‘0A’ = Länge des zugehörenden Datenfeldes
'A000000167 455349474E’ = AID von DF.ESIGN
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
‘9000’ oder spezifische Status -Bytes, siehe [HPC-P1]
10.4 Lesen der X.509-Zertifikate
Zum Lesen der Zertifikate C.HP.AUT und C.HP.ENC, wird das READ BINARY Kommando verwendet.
Seite 76 von 162
Tabelle 151 - (N2158.00) READ BINARY Kommando zum Lesen eines X.509-Zertifikats
CLA
INS
P1-P2
- P1 = b8-b6: 100
b5-b1: 00001 SFID von EF.C.HP.AUT: 1
00010 SFID von EF.C.HP.ENC: 2
P2 = Offset
Lc
Nicht vorhanden
Le
'000000'
Datenfeld
SW1-SW2
CV Zertifikat
wiederholt werden.
10.5 PIN Management
Vor der Nutzung von PrK.HP.AUT oder PrK.HP.ENC muss PIN.CH erfolgreich eingegeben werden,
siehe Kapitel 4.6.1.
10.6 Client/Server-Authentisierung
Um die Zugriffsrechte zu Komponenten wie z.B. Servern überprüfen zu können, muss ein PKIbasierter Authentisierungsprozess 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 zertifiziert. 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 SSL-Protokoll)
- das WTLS-Protokoll
Die Karte berechnet in einem INTERNAL AUTHENTICATE Kommando eine digitale Signatur, indem
sie den im Datenfeld des Kommandos übergebenen Authentisierungs-Input formatiert und den privaten Authentisierungsschlüssel auf die Daten 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, werden der zugehörige
private Schlüssel und die zum Authentisierungsprotokoll passende Algorithmenkennung gesetzt.
Seite 77 von 162
Tabelle 153 – (N2160.00) MSE Kommando für die Schlüssel- und Algorithmenauswahl
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘A4’ = Authentication Template
‘84 01 82’ || ’80 01 05’ = KeyRef von PrK.HP.AUT ||
DO AlgID rsaClientAuthentication
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘00’
‘00’
Datenfeld
SW1-SW2
Digitale Signatur
PrK.HP.AUT kann auch in einem PSO: COMPUTE DIGITAL SIGNATURE Kommando verwendet
werden. Der private Authentisierungsschlüssel und die Algorithmenkennung zur Angabe des Authentisierungsprotokolls müssen vorher gesetzt werden.
CLA
INS
P1
P2
Lc
Datenfeld
‘84 01 82’ || ’80 01 yy’ = DO KeyRef von PrK.HP.AUT || DO AlgID
Le
‘yy’ = ‘07’: sign9796_2_DS2
Nicht vorhanden
Seite 78 von 162
Datenfeld
SW1-SW2
Nicht vorhanden
CLA
INS
P1
P2
‘9E’ = Rückgabe einer digitalen Signatur
Lc
Le
Datenfeld
SW1-SW2
Digitale Signatur
10.7 Entschlüsselung des Dokumenten-Chiffrierungsschlüssels
Zum Austausch vertraulicher Dokumente wird das folgende Verfahren genutzt:
-
der Schlüsseltransport wird durch Verschlüsseln des Dokumenten-Chiffrierungsschlü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 die HPC nicht beteiligt. Die Software des PC des Senders berechnet einen Dokumenten-Chiffrierungsschlüssel, verschlüsselt das Dokument damit und verschlüsselt anschließend den Dokumenten-Chiffrierungsschlüssel mit dem öffentlichen X.509-ENCSchlüssel des Empfängers. Diesen erhält sie z.B. von einem Zertifikatsserver.
Bevor der Chiffrierungsschlüssel vom Empfänger mit seinem PrK.HP.ENC entschlüsselt werden kann,
muss die PIN.CH erfolgreich eingegeben worden sein. Der private Schlüssel PrK.HP.ENC und der
Algorithmus müssen mit dem ISO/IEC 7816-4 Kommando MSE ausgewählt werden.
Seite 79 von 162
CLA
INS
P1
P2
Lc
Datenfeld
‘41’ = SET für Entschlüsselung
‘B8’ = Confidentiality Template
’84 01 83’ | ’80 01 yy’ = DO KeyRef von PrK.HP.ENC || DO AlgID
Le
‘yy’ = 85’: rsaDecipherOaep
‘yy’ = 81’: rsaDecipherPKCS1_V1_5
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
Nachdem der Schlüssel und der Algorithmus ausgewählt sind, kann die Entschlüsselung mit dem
ISO/IEC 7816-8 Kommando PSO: DECIPHER erfolgen.
Tabelle 163 – (N2170.00) PSO: DECIPHER Kommando
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘2A’ = PERFORM SECURITY OPERATION: DECIPHER
‘80’ = Rückgabe des Klartextes
‘86’ = Verschlüsselte Daten im Datenfeld
‘00’ (Padding Indicator) || Kryptogramm (256 Bytes)
‘0000’ oder ‘00xx’ = Länge des Dokumenten-Chiffrierungsschlüssels
Tabelle 164 – (N2171.00) PSO: DECIPHER Antwort
Datenfeld
SW1-SW2
Dokumenten-Chiffrierungsschlüssels
‘9000’oder spezifische Status-Bytes, siehe [HPC-P1]
10.8 Umschlüsselung des Dokumenten-Chiffrierungsschlüssels
Zum Austausch bereits verschlüsselter Dokumente mit Dritten wird das folgende Verfahren genutzt:
-
der Dokumenten-Chiffrierungsschlüssel wird mit dem privaten Schlüssel PrK.HP.ENC
entschlüsselt
der Schlüsseltransport wird durch Verschlüsseln des Dokumenten-Chiffrierungsschlüssels mit
dem öffentlichen Schlüssel des Dritten abgesichert.
Beide Schritte werden mit einem einzelnen TRANSCIPHER Kommando ausgeführt, so dass der
Chiffrierungsschlüssel nicht im Klartext an der Kartenschnittstelle erscheinen muss.
Seite 80 von 162
Bevor der Chiffrierungsschlüssel umgeschlüsselt werden kann, muss die PIN.CH erfolgreich eingegeben worden sein. Der private Schlüssel PrK.HP.ENC und der Algorithmus müssen mit dem ISO/IEC
7816-4 Kommando MSE ausgewählt werden.
CLA
INS
P1
P2
Lc
Datenfeld
‘41’ = SET für Entschlüsselung
’84 01 83’ || ’80 01 yy’ = DO KeyRef von PrK.HP.ENC || DO AlgID
Le
‘yy’ = ‘85’: rsaDecipherOaep
‘yy’ = ‘81’: rsaDecipherPKCS1_V1_5
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
Nachdem der Schlüssel und der Algorithmus ausgewählt sind, kann die Umschlüsselung mit dem proprietären Kommando PSO: TRANSCIPHER erfolgen, siehe Kapitel 14.8.7 in [HPC-P1]. Das Datenfeld
des Kommandos enthält neben einem zusammengesetzten Kryptogramm DO (Tag ‘A6’) mit dem umzuschlüsselnden Chiffrierungsschlüssel auch ein zusammengesetztes Klartext DO (Tag ‘A0’), das für
den Verschlüsselungsteil der Operation die Algorithmenkennung (Tag ‘80’) und den öffentlichen
Schlüssel des Dritten (Tag ‘7F49’) bereitstellt, siehe Kapitel 14.8.7.4 in [HPC-P1].
Tabelle 167 – (N2174.00) PSO: TRANSCIPHER Kommando
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘2A’ = PERFORM SECURITY OPERATION: TRANSCIPHER
‘86’ = Rückgabe eines Kryptogramms
‘00021F’ = Länge des zugehörenden Datenfeldes = 543
‘A6’ || LängeA6 (3 B) || ’86’ || Länge86 (3 B) || Padding Indicator (1 B) || Kryptogramm (256 B) ||
‘A0’ || LängeA0 (3 B) || ’80’ || Länge80 (1 B) || AlgID (1 B) ||
‘7F49’ || Länge7F49 (3 B) || ‘81’ || Länge81 (3 B) || Modulus (256 B) ||
’82’ || Länge82 (1 B) || Exponent (4 B)
‘0000’ oder ‘0101’ = Länge des verschlüsselten Dokumenten-Chiffrierungsschlüssels
mit vorangestelltem Padding Indicator = 257
Tabelle 168 – (N2175.00) PSO: TRANSCIPHER Antwort
Datenfeld
SW1-SW2
Padding Indicator || Verschlüsselter Dokumenten-Chiffrierungsschlüssel
Seite 81 von 162
11 Kryptografische Informationsanwendungen
11.1 Allgemeine Struktur
Abbildung 8 (N2176.00) zeigt die prinzipielle Struktur der kryptografischen Informationsanwendungen
(CIAs), die mit der QES- und der ESIGN-Anwendung verknüpft sind.
MF
DF.CIA.QES
CIA
OD
AOD
PrKD
CD
= Cryptographic Inf. Application
= Object Directory
= Authentication Object Directory
= Private Key Directory
= Certificate Directory
DF.CIA.ESIGN
EF.CIAInfo
EF.CIAInfo
EF.OD
EF.OD
EF.AOD
EF.AOD
EF.PrKD
EF.PrKD
EF.CD
EF.CD
Abbildung 8 – (N2176.00) DF.CIA-Anwendungen und ihre Unterstrukturen
11.2 DF.CIA.QES und DF.CIA.ESIGN (Cryptographic Information Applications)
DF.CIA.QES und DF.CIA.ESIGN sind “Applications Directories” gemäß Kapitel 8.3.1.1 in [HPC-P1],
d.h. sie sind mit der entsprechenden Anwendungskennung selektierbar, siehe Kapitel 11.4. Die folgenden Tabellen zeigen die Attribute und Zugriffsregeln, die für die Anwendungsverzeichnisse gelten.
Tabelle 169 – (N2177.00) Attribute von MF / DF.CIA.QES
Attribut
Objekttyp
File Identifier
Wert
'E828BD080F D27600006601’
-
Life Cycle Status
Zugriffsart
SELECT
DEACTIVATE, DELETE
ALWAYS
NEVER
Anmerkung
Herstellerspezifisch; Falls unterstützt, dann außerhalb des Intervalls
[‘1000’, ‘FEFF’]; siehe Kapitel 8.1.1
in [HPC-P1]
Anmerkung
Seite 82 von 162
Tabelle 170 – (N2178.00) Attribute von MF / DF.CIA.ESIGN
Attribut
Objekttyp
File Identifier
Life Cycle Status
Zugriffsart
SELECT
DEACTIVATE, DELETE
Wert
'E828BD080F A000000167
455349474E’
-
Anmerkung
ALWAYS
NEVER
Anmerkung
11.3 Dateien mit kryptografischen Informationsobjekten (CIOs)
Die logischen File-Namen, File Identifier, Short File Identifier und die Dateiinhalte (siehe Annex D und
Annex E) sind konform zu ISO/IEC 7816-15. Die entsprechenden CIO-Dateien beider Anwendungen
DF.CIA.QES und DF.CIA.ESIGN besitzen die gleichen charakteristischen Attribute und Zugriffsregeln,
die in den folgenden Tabellen dargestellt sind.
Tabelle 171 – (N2179.00) Attribute von EF.CIAInfo (Cryptographic Information Application Info)
Attribut
Objekttyp
File Identifier
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Zugriffsart
SELECT, READ BINARY
Wert
‘5032’
‘12’ = 18
256 Bytes oder auf die Länge der CIOs
beschränkt
False
True
...
ALWAYS
NEVER
Anmerkung
Siehe Annex D und
Annex E
Anmerkung
Tabelle 172 – (N2180.00) Attribute von EF.OD (Object Directory)
Attribut
Objekttyp
File Identifier
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Wert
‘5031’
‘11’ = 17
beschränkt
False
True
...
Anmerkung
Siehe Annex D und
Annex E
Seite 83 von 162
Zugriffsart
SELECT, READ BINARY
ALWAYS
NEVER
Anmerkung
Tabelle 173 – (N2181.00) Attribute von EF.AOD (Authentication Object Directory)
Attribut
Objekttyp
File Identifier
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Zugriffsart
SELECT, READ BINARY
Wert
‘5034’
‘14’ = 20
beschränkt
False
True
...
ALWAYS
NEVER
Anmerkung
Siehe Annex D und
Annex E
Anmerkung
Tabelle 174 – (N2182.00) Attribute von EF.PrKD (Private Key Directory)
Attribut
Objekttyp
File Identifier
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Zugriffsart
SELECT, READ BINARY
Wert
‘5035’
‘15’ = 21
beschränkt
False
True
...
ALWAYS
NEVER
Anmerkung
Siehe Annex D und
Annex E
Anmerkung
Tabelle 175 – (N2183.00) Attribute von EF.CD (Certificate Directory)
Attribut
Objekttyp
File Identifier
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Wert
‘5038’
‘16’ = 22
beschränkt
False
True
...
Anmerkung
Siehe Annex D und
Annex E
Seite 84 von 162
Zugriffsart
SELECT, READ BINARY
ALWAYS
NEVER
Anmerkung
11.4 Auswahl der Anwendungen
Zur Auswahl der Anwendungen wird das ISO/IEC 7816-4-Kommando SELECT verwendet, wie in der
folgenden Tabelle gezeigt ist.
Tabelle 176 – (N2184.00) SELECT Kommando für DF.CIA.QES und DF.CIA.ESIGN
CLA
INS
P1
P2
Lc
‘00’
‘A4’ = SELECT
‘0B’ oder ‘0F’ = Länge des zugehörenden Datenfeldes
Datenfeld
- ‘E828BD080F D27600006601’ = AID von DF.CIA.QES oder
- 'E828BD080F A000000167 455349474E’ = AID von DF.CIA.ESIGN
Nicht vorhanden
Le
Anmerkung – Der „Registered Application Provider Identifier“ (RID) von DF.CIA entspricht den Vorgaben in
ISO/IEC 7816-15. Dem RID folgt der AID der Anwendung, zu der die CIOs gehören, in diesem Fall AID.QES
oder AID.ESIGN.
Tabelle 177 – (N2185.00) SELECT Antwort
Datenfeld
SW1-SW2
Nicht vorhanden
11.5 Lesen der CIA-Dateien
Zum Lesen der CIA-Dateien wird das ISO/IEC 7816-4 Kommando READ BINARY genutzt.
Tabelle 178 – (N2186.00) READ BINARY Kommando zum Lesen der CIA –Dateien
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘xx’ = b8-b6: 100
b5-b1: 10010 SFID von EF.CIAInfo: 18
b5-b1: 10001 SFID von EF. OD: 17
b5-b1: 10100 SFID von EF. AOD: 20
b5-b1: 10101 SFID von EF. PrKD: 21
b5-b1: 10110 SFID von EF. CD: 22
‘00’ = Offset
Nicht vorhanden
Nicht vorhanden
‘00’ = Lesen bis zum Ende der Datei (max 256 Bytes)
Seite 85 von 162
Anmerkung – SFID 19 kann nicht genutzt werden, siehe ISO/IEC 7816-15.
Datenfeld
SW1-SW2
CIOs
Seite 86 von 162
12 Die Organisationsspezifische Authentisierungsanwendung
Die Organisationsspezifische Authentisierungsanwendung ist eine optionale Anwendung. Es liegt im
Ermessen der HPC-Herausgeberorganisation (Berufskammer), ob die Anwendung nach Kartenausgabe vorhanden ist und nutzbar gemacht werden kann. Die eigentliche Nutzung der Anwendung liegt im
Ermessen des Karteninhabers. Falls die Organisationsspezifische Authentisierungsanwendung genutzt wird, dann ist der Inhalt dieses Kapitels verbindlich vorgeschrieben.
12.1 Dateistruktur und Dateiinhalt
DF.AUTO wird genutzt für
-
organisationsspezifische Authentisierungsprozesse (z.B. Windows Logon mit Smart Card), welche
mit der ESIGN-Anwendung aufgrund technischer Unterschiede (z.B. proprietäre Zertifikatserweiterungen) oder eines unvereinbaren Verfahrens (z.B. vorgeschriebenes PIN-Caching) nicht umgehen können.
Abbildung 9 (N2188.00) zeigt die prinzipielle Struktur der AUTO-Anwendung.
MF
DF.AUTO
PrK.HP.AUTO
PIN.AUTO
EF.C.HP.AUTO1
EF.C.HP.AUTO2
PIN.SO
AUTO
C
HP
SO
PrK
= Organisationsspezifische Authentisierung
= X.509-Zertifikat
= Heilberufler
= Administrator
= Privater Schlüssel
Abbildung 9 – (N2188.00) Prinzipielle Struktur von DF.AUTO
12.1.1 DF.AUTO (Organization-specific Authentication Application)
DF.AUTO ist ein “Application Directory” gemäß Kapitel 8.3.1.1 in [HPC-P1], d.h. ist mittels Anwendungskennung selektierbar. Die folgende Tabelle zeigt die Attribute und Zugriffsregeln, die für das Anwendungsverzeichnis gelten.
Seite 87 von 162
Tabelle 180 – (N2189.00) Attribute von MF / DF.AUTO
Attribut
Objekttyp
File Identifier
Wert
‘D27600014603’
-
Life Cycle Status
Zugriffsart
SELECT
DEACTIVATE, DELETE
ALWAYS
NEVER
Anmerkung
Anmerkung
12.1.2 PrK.HP.AUTO
PrK.HP.AUTO ist der private Schlüssel für Client/Server-Authentisierung. Die folgende Tabelle zeigt
die Eigenschaften und Zugriffsregeln des privaten Schlüssels.
Tabelle 181 – (N2190.00) Attribute von MF / DF.AUTO / PrK.HP.AUTO
Attribut
Objekttyp
Key Identifier
Key Reference
Private Key
Key Available
Wert
Privates RSA-Objekt
‘02’ = 2
‘82’
.... (2048 Bits)
True
INTERNAL AUTHENTICATE:
rsaClientAuthentication
Anmerkung
Wird personalisiert
Wird personalisiert
PSO: COMPUTE DIGITAL SIGNATURE:
signPKCS1_V1_5
signPSS
sign9796_2_DS2
Zugriffsart
GENERATE ASYMMETRIC KEY PAIR
INTERNAL AUTHENTICATE,
PSO: COMPUTE DIGITAL SIGNATURE
(P2 = ‘9E’ oder ‘AC’)
Andere
PWD(PIN.SO)
PWD(PIN.AUTO)
Anmerkung
NEVER
Anmerkung – PrK.HP.AUTO ist ein privates RSA-Objekt, welches gemäß Kapitel 8.5.3 in [HPC-P1] das GENERATE ASYMMETRIC KEY PAIR Kommando unterstützt. Da die organisationsspezifische Zertifikatsinformation
dem Personalisierer wahrscheinlich nicht bekannt ist, kann es notwendig sein, dieses Kommando während der
Kartennutzung zu verwenden, um eine Generierung von Zertifikaten zu ermöglichen.
12.1.3 PIN.AUTO
PIN.AUTO ist eine DF-spezifische PIN, die ausschließlich dem Schutz des privaten Authentisierungsschlüssels für den organisationsspezifischen Authentisierungsmechanismus des Heilberuflers
(PrK.HP.AUTO) dient. PIN.AUTO muss genau 5 Ziffern besitzen.
Seite 88 von 162
Die Nutzung eines 8-stelligen Rücksetzcodes (Personal Unblocking Key, PUK) wird durch einen Nutzungszähler beschränkt, dessen Anfangswert auf 10 gesetzt ist. Der Sicherheitsstatus von PIN.AUTO
kann unbegrenzt verwendet werden, d.h. der Default-Wert von SSEC beträgt unendlich.
Die nachfolgende Tabelle zeigt die PIN-Referenz, wie sie in den Kommandos VERIFY, CHANGE
REFERENCE DATA und RESET RETRY COUNTER verwendet wird, und weitere PIN-Eigenschaften.
Tabelle 182 – (N2191.00) Attribute von MF / DF.AUTO / PIN.AUTO
Attribut
Objekttyp
Password Identifier
Password Reference
Secret
Minimum Length
Start Retry Counter
Retry Counter
Transport Status
Flag Enabled
Counter
PUK
PUK Usage
Zugriffsart
GET PIN STATUS
VERIFY
Andere
Wert
Passwort
‘01’
‘81’
....
5
3
3
Ein Verfahren gemäß Kapitel 8.2.5 in [HPC-P1]
True
Infinite
Anmerkung
Wird personalisiert
...
10
Wird personalisiert
ALWAYS
ALWAYS
ALWAYS
ALWAYS
NEVER
Anmerkung
Die Initialisierung von PIN.AUTO, z.B. durch Nutzung einer Transport-PIN, unterliegt den Richtlinien
der zuständigen Organisation. Falls eine Transport-PIN verwendet wird, so muss ein Verfahren aus
Kapitel 8.2.5 in [HPC-P1] zum Einsatz kommen.
12.1.4 PIN.SO
PIN.SO ist eine DF-spezifische PIN, die für administrative Zwecke bezüglich DF.AUTO verwendet
wird, d.h. zur Generierung des asymmetrischen Schlüsselpaars und zum Aktualisieren der organisationsspezifischen Authentisierungszertifikate. PIN.SO besteht aus 6 bis 8 Ziffern.
Die Nutzung eines 8-stelligen Rücksetzcodes (Personal Unblocking Key, PUK) wird durch einen Nutzungszähler beschränkt, dessen Anfangswert auf 10 gesetzt ist. Der Sicherheitsstatus von PIN.SO
kann unbegrenzt verwendet werden, d.h. der Default-Wert von SSEC beträgt unendlich.
Die nachfolgende Tabelle zeigt die PIN-Referenz, wie sie in den Kommandos VERIFY, CHANGE
REFERENCE DATA und RESET RETRY COUNTER verwendet wird, und weitere PIN-Eigenschaften.
Tabelle 183 – (N2192.00) Attribute von MF / DF.AUTO / PIN.SO
Attribut
Objekttyp
Password Identifier
Password Reference
Secret
Minimum Length
Start Retry Counter
Wert
Passwort
‘03’
‘83’
....
6
3
Anmerkung
Wird personalisiert
Seite 89 von 162
Retry Counter
Transport Status
Flag Enabled
Counter
PUK
PUK Usage
Zugriffsart
GET PIN STATUS
VERIFY
Andere
3
Ein Verfahren gemäß Kapitel 8.2.5 in [HPC-P1]
True
Infinite
...
10
Wird personalisiert
ALWAYS
ALWAYS
ALWAYS
ALWAYS
NEVER
Anmerkung
Gemäß Kapitel 14.6.1.4 und Kapitel 14.6.5.6 in [HPC-P1] prüft das COS nur die minimale Länge von
PIN.SO, d.h. das COS kontrolliert nicht, ob die maximale Länge von 8 Ziffern überschritten wird.
Die Initialisierung von PIN.SO, z.B. durch Nutzung einer Transport-PIN, unterliegt den Richtlinien der
zuständigen Organisation. Falls eine Transport-PIN verwendet wird, so muss ein Verfahren aus
Kapitel 8.2.5 in [HPC-P1] zum Einsatz kommen.
12.1.5 EF.C.HP.AUTO1 und EF.C.HP.AUTO2
EF.C.HP.AUTO1 und EF.C.HP.AUTO2 enthalten die organisationsspezifischen X.509-AUT-Zertifikate
des Heilberuflers. Damit können dem Heilberufler zwei verschiedene Identitäten zur Verfügung
stehen, die beide mit demselben privaten Schlüssel PrK.HP.AUTO verknüpft sind.
Die Zertifikate können nach erfolgreicher Authentisierung mit PIN.SO aktualisiert werden, siehe
Tabelle 184 (N2193.00) und Tabelle 185 (N2194.00).
Tabelle 184 – (N2193.00) Attribute von MF / DF.AUTO / EF.C.HP.AUTO1
Attribut
Objekttyp
File Identifier
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Zugriffsart
SELECT, READ BINARY
UPDATE BINARY
ERASE BINARY
Wert
‘E001’
‘01’ = 1
False
False
...
ALWAYS
PWD(PIN.SO)
NEVER
Anmerkung
Wird personalisiert
Anmerkung
Tabelle 185 – (N2194.00) Attribute von MF / DF.AUTO / EF.C.HP.AUTO2
Attribut
Objekttyp
File Identifier
Wert
‘E002’
‘02’ = 2
Anmerkung
Seite 90 von 162
Number of Bytes
Flag Checksum
Life Cycle Status
Content
Zugriffsart
SELECT, READ BINARY
UPDATE BINARY
ERASE BINARY
False
False
...
ALWAYS
PWD(PIN.SO)
NEVER
Wird personalisiert
Anmerkung
12.2 Sicherheitsumgebungen
In DF.AUTO wird ausschließlich das voreingestellte SE # 1 verwendet.
12.3 Auswahl der AUTO-Anwendung
Die Auswahl der AUTO-Anwendung erfolgt mit dem SELECT Kommando.
Tabelle 186 - (N2195.00) SELECT Kommando für DF.ESIGN
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘A4’ = SELECT
'D27600014603’ = AID von DF.AUTO
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
‘9000’ oder specifische Status-Bytes, siehe [HPC-P1]
Nach der DF-Auswahl ist implizit die Sicherheitsumgebung SE # 1 gewählt.
12.4 PIN-Management
12.4.1 PIN-Prüfung
Vor der Nutzung des privaten Schlüssels PrK.HP.AUTO, muss PIN.AUTO erfolgreich präsentiert
worden sein. Zum Aktualisieren der Zertifikatsdateien muss PIN.SO erfolgreich präsentiert werden.
Für die PIN-Prüfung wird das ISO/IEC 7816-4 Kommando VERIFY verwendet.
Seite 91 von 162
Tabelle 188 - (N2197.00) VERIFY Kommando zum Prüfen einer PIN
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘20’ = VERIFY
‘00’
‘81’ = PIN.AUTO Referenz oder
‘83’ = PIN.SO Referenz
PIN (Format: siehe Kapitel 8.1.7 in [HPC-P1])
Nicht vorhanden
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-Bytes, die in Kapitel 14.6.6.3 in [HPC-P1] spezifiziert sind,
angezeigt werden.
12.4.2 PIN-Änderung
Zur Änderung von PIN.AUTO oder PIN.SO kann das ISO/IEC 7816-4 Kommando CHANGE REFERENCE DATA zu jeder Zeit vom Heilberufler genutzt werden. Das Kommando kann nur mit P1 = ‘00’,
d.h. mit alter und neuer PIN im Datenfeld ausgeführt werden. Die erfolgreiche Prüfung der alten PIN
setzt keinen Sicherheitsstatus des referenzierten PIN-Objektes, siehe Kapitel 14.6.1 in [HPC-P1].
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘00’ = Ändern der Referenzdaten
‘81’ = PIN.AUTO-Referenz oder
‘83’ = PIN.SO-Referenz
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
12.4.3 Zurücksetzen des Fehlbedienungszählers
Zum Zurücksetzen des Fehlbedienungszählers auf seinen Ausgangswert und – falls so realisiert –
zum Setzen einer neuen PIN wird das Kommando RESET RETRY COUNTER verwendet. Der SicherHPC-Spezifikation V2.3.2, Teil II
Seite 92 von 162
heitsstatus wird durch dieses Kommando weder gesetzt noch beeinflusst, siehe Kapitel 14.6.5 in
[HPC-P1].
Tabelle 192 – (N2201.00) RESET RETRY COUNTER Kommando zum Zurücksetzen des
Fehlbedienungszählers
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘00’ oder ‘01’
- ‘81’ = Referenz von PIN.AUTO, zu der der Rücksetzcode (“PUK”) gemäß
ISO/IEC 7816-4 gehört oder
- ‘83’ = Referenz von PIN.SO, zu der der Rücksetzcode (“PUK”) gemäß ISO/IEC
7816-4 gehört
- Falls P1 = ‘00’: Rücksetz-Code (8 Byte) gefolgt von einer neuen PIN (8 Byte)
- Falls P1 = ‘01’: Rücksetz-Code (“PUK”, Format: siehe Kapitel 8.1.7 in [HPC-P1])
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
Anmerkung – Das Kommando kann auch dazu verwendet werden, den Transportstatus der PIN aufzuheben,
siehe Kapitel 14.6.5.1 und Kapitel 14.6.5.3 in [HPC-P1].
12.5 Lesen der organisationsspezifischen Zertifikate
Zum Lesen der Zertifikate EF.C.HP.AUTO1 und EF.C.HP.AUTO2, wird das READ BINARY Kommando verwendet.
Tabelle 194 - (N2203.00) READ BINARY Kommando zum Lesen eines X.509-Zertifikats
CLA
INS
P1-P2
- P1 = b8-b6: 100
b5-b1: 00001 SFID von EF.C.HP.AUTO1: 1
00010 SFID von EF.C.HP.AUTO2: 2
P2 = Offset
Lc
Nicht vorhanden
Le
'000000'
Datenfeld
SW1-SW2
Zertifikatsdaten
Seite 93 von 162
wiederholt werden.
12.6 Aktualisieren der organisationsspezifischen Zertifikate
Zum Aktualisieren der organisationsspezifischen Zertifikate (siehe Zugriffsbedingungen in Tabelle 184
(N2193.00) und Tabelle 185 (N2194.00)), muss das ISO/IEC 7816-4 Kommando UPDATE BINARY
verwendet werden.
Tabelle 196 - (N2205.00) UPDATE BINARY Kommando zum Aktualisieren eines Zertifikat
CLA
INS
P1, P2
- P1 = b8-b6: 100
b5-b1:
00001 SFID von EF.C.HP.AUTO1: 1 oder
00010 SFID von EF.C.HP.AUTO2: 2
P2 = Offset
Lc
Datenfeld Daten
Le
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
wiederholt werden.
12.7 Client/Server-Authentisierung
Um die Zugriffsrechte zu Komponenten wie z.B. Servern überprüfen zu können, muss ein PKIbasierter Authentisierungsprozess ausgeführt werden. Das verwendete Schlüsselpaar ist das des
Karteninhabers (PrK.HP.AUTO, PuK.HP.AUTO). Der öffentliche Schlüssel ist zusammen mit dem eindeutigen Namen des Karteninhabers ("Distinguished Name") durch das X.509-Zertifikat nachprüfbar
zertifiziert. 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 SSL-Protokoll)
- das WTLS-Protokoll
Die Karte berechnet in einem INTERNAL AUTHENTICATE Kommando eine digitale Signatur, indem
sie den im Datenfeld des Kommandos übergebenen Authentisierungs-Input formatiert und den privaten Authentisierungsschlüssel auf die Daten 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, wird der zugehörige private Schlüssel und die zum Authentisierungsprotokoll passende Algorithmenkennung gesetzt.
Seite 94 von 162
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘A4’ = AT
‘84 01 82’ || ’80 01 05’
= DO KeyRef von PrK.HP.AUTO || DO AlgID rsaClientAuthentication
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘00’
‘00’
Datenfeld
SW1-SW2
Digitale Signatur
PrK.HP.AUTO kann auch mit dem COMPUTE DIGITAL SIGNATURE Kommando verwendet werden.
Zuvor müssen der private Authentisierungsschlüssel und die zum Authentisierungsprotokoll passende
Algorithmenkennung gesetzt werden.
Seite 95 von 162
CLA
INS
P1
P2
Lc
Datenfeld
‘84 01 82’ || ’80 01 yy’ = DO KeyRef von PrK.HP.AUTO || DO AlgID
Le
‘yy’ = ‘07’: sign9796_2_DS2
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
CLA
INS
P1
P2
‘9E’ = Return digital signature
Lc
Le
Datenfeld
SW1-SW2
Digitale Signatur
‘9000’ oder spezifische Status-Bytes, see [HPC-P1]
Seite 96 von 162
13 Laden einer neuen Anwendung oder Anlegen eines EFs
nach Ausgabe der HPC
13.1 Identifizierung des HPC-Betriebssystems
Es wird angenommen, dass das Laden neuer Anwendungen oder das Erstellen neuer EFs auf MFEbene oder in DF.HPA nach der Ausgabe der HPC von einem Card Application Management System
(CAMS) durchgeführt wird. Dies ist ein optionaler Prozess. Ebenso ist das CAMS optional. Die Inhalte
dieses Kapitels sind allerdings normativ, wenn das Laden neuer Anwendungen oder das Erstellen
neuer EFs nach HPC-Ausgabe durchgeführt werden müssen.
Ein CAMS kann schon Informationen über eine bestimmte HPC 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 z.B. von EF.ATR, EF.GDO, EF.DIR und EF.Version
bekommen.
13.2 Einrichtung eines Trusted Channel zwischen CAMS und HPC
Ein Trusted Channel kann mit symmetrischen oder asymmetrischen Authentisierungsverfahren eingerichtet werden. Dies hängt vom beteiligten CAMS ab. Beide CAMS-Authentisierungsverfahren sind zulässig und werden als gleichwertig betrachtet. Im Folgenden wird das asymmetrische Authentisierungsverfahren beschrieben, das auch Teil des Schutzprofils der HPC [PP-HPC] ist.
Zur Einrichtung eines Trusted Channel zwischen der HPC und dem zugehörigen CAMS muss ein
asymmetrisches Authentisierungsverfahren mit der Berechnung von Secure Messaging-Schlüsseln
gemäß [HPC-P1] durchgeführt werden, siehe folgendes Kapitel. Da der PuK.CAMS_HPC.AUT_CVC
schon in der HPC gespeichert ist, ist keine Prüfung der CVCs des CAMS notwendig. Dem CAMS
müssen allerdings die CVCs der HPC übermittelt werden, siehe Abbildung 10 (N2600.00).
WurzelCA
Selbstzertifikat signiert von der
Wurzel-CA zur Bereitstellung
C.RCA.
des öffentlichen RootCS
Schlüssels PuK.RCA.CS,
der zur Verifikation von
C.CA_HPC.CS gebraucht wird.
PuK.HPC.AUTR_CVC
Während der Authentisierung
verwendete Schlüssel
Bereitstellung von
PuK.HPC.AUTR_CVC
über Zertifikatskette
CAMS
C.CA_
HPC.
CS
PrK.CAMS_HPC.AUT_CVC
Während der Authentisierung
verwendete Schlüssel
C.HPC.
AUTR_
CVC
PrK.HPC.AUTR_CVC
HBA
PuK.CAMS_HPC.AUT_CVC
(in HBA vorhanden)
Abbildung 10 – (N2600.00) Schlüssel und Schlüsselimport für HPC/CAMS Authentisierung mit
Aufbau eines Trusted Channel
Seite 97 von 162
13.2.1 Asymmetrische Authentisierung
Im ersten Teil des Prozesses weist die HPC seine Echtheit gegenüber dem CAMS nach. Bevor das
Kommando zur internen Authentisierung an die HPC gesendet wird, fordert die externe Software eine
Zufallszahl vom CAMS an. Auf der HPC werden zunächst die Schlüssel und Algorithmen für beide
Authentisierungskommandos ausgewählt.
Anmerkung – Beide MSE SET Kommandos für interne und externe Authentisierung werden unmittelbar hintereinander ausgeführt, so dass die Sequenz der Authentisierungskommandos nicht durch ein MSE SET Kommando unterbrochen wird, siehe Kapitel 15 in [HPC-P1].
CLA
INS
P1
P2
Lc
Datenfeld
Le
’84 01 10’ || ‘80 01 54'
= DO KeyRef von PrK.HPC.AUTR_CVC || DO AlgID rsaSessionkey4SM
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘83 0C 00000000 00000000 00000013’ || ‘80 01 54’ = DO KeyRef von
PuK.CAMS_HPC.AUT_CVC || DO AlgID rsaSessionkey4SM
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
Seite 98 von 162
CLA
INS
P1
P2
Lc
Datenfeld
Le
siehe Kapitel 14.7.4 in [HPC-P1],
‘0100’ = Länge der erwarteten Signatur
Datenfeld
SW1-SW2
Der Authentisierungs-Token (Inhalt des Antwortdatenfeldes) wird im entsprechenden CAMS geprüft.
Der zweite Teilprozess umfasst die externe Authentisierung des CAMS. Zunächst wird eine Zufallszahl von der HPC angefordert.
CLA
INS
P1, P2
Lc
Datenfeld
Le
‘0000’
Nicht vorhanden
Nicht vorhanden
Datenfeld
SW1-SW2
RND.HPC (8 Bytes)
Die Zufallszahl wird dem CAMS zusammen mit den 8 LSB der ICCSN der HPC übergeben. Das
Ergebnis der vom CAMS ausgeführten internen Authentisierung wird mit dem Kommando EXTERNAL
AUTHENTICATE an die HPC gesendet. Die HPC muss die CAMS-Signatur prüfen.
Tabelle 214 – (N2609.00) EXTERNAL AUTHENTICATE Kommando zur CAMS-Authentisierung
CLA
INS
P1
P2
Lc
Datenfeld
Le
Nicht vorhanden
Seite 99 von 162
Tabelle 215 - (N2610.00) EXTERNAL AUTHENTICATE Antwort
Datenfeld
SW1-SW2
Nicht vorhanden
Die Authentisierungsdaten enthalten Datenelemente zur Schlüsselableitung, die gemäß Kapitel 13.1
und 14.7.1 in [HPC-P1] erfolgt. Eine erfolgreiche Prüfung setzt in der HPC den Sicherheitsstatus
“Privater CAMS-Schlüssel erfolgreich nachgewiesen”. Ein Trusted Channel wurde aufgebaut, d.h.
neue Anwendungsdaten können nun mit Secure Messaging zur HPC gesendet werden.
13.2.2 Durchführung der symmetrischen Authentisierung
Falls der symmetrische Schlüssel SK.CAMS in der Karte vorhanden ist, muss das symmetrische
Authentisierungsverfahren zwischen HPC und CAMS wie folgt durchgeführt werden. Die Kommandosequenz beginnt mit dem Setzen des symmetrischen Schlüssels und der passenden Algorithmenkennung für gegenseitige Authentisierung.
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘81’ = SET für gegenseitige Authentisierung
‘83 01 13’ || ‘80 01 54’ = DO KeyRef von SK.CAMS || DO AlgID
desSessionkey4SM
Nicht vorhanden
Datenfeld
SW1-SW2
Nicht vorhanden
‘9000’ oder spezifische Status-Bytes, siehe
[HPC-P1]
Anschließend wird eine Zufallszahl von der HPC abgerufen.
CLA
INS
P1, P2
Lc
Datenfeld
Le
‘0000’
Nicht vorhanden
Nicht vorhanden
Datenfeld
SW1-SW2
RND.HPC (8 Bytes)
Dann wird ein INTERNAL AUTHENTICATE Kommando mit RND.HPC || ICCSN8.HPC im Datenfeld
an das CAMS gesendet. Ein MUTUAL AUTHENTICATE Kommando folgt auf Seiten der HPC. Dieses
Seite 100 von 162
Kommando übermittelt die Authentisierungsdaten des CAMS an die HPC. Die HPC verifiziert die
CAMS-Daten und berechnet die eigenen Authentisierungsdaten.
Tabelle 220 – (N2615.00) MUTUAL AUTHENTICATE Kommando
CLA
INS
P1
P2
Lc
Datenfeld
‘82’ = MUTUAL AUTHENTICATE
Auf die Authentisierung bezogene Daten, siehe Kapitel 14.7.1
von [HPC-P1]
Le
Tabelle 221 - (N2616.00) MUTUAL AUTHENTICATE Antwort
Datenfeld
SW1-SW2
Auf die Authentisierung bezogene Daten, siehe Kapitel 14.7.1
von [HPC-P1]
Eine erfolgreiche Prüfung setzt in der HPC den erforderlichen Sicherheitsstatus. Die HPC-Authentisierungsdaten (aus dem Datenfeld der Antwort) werden im CAMS während eines EXTERNAL AUTHENTICATE Kommandos geprüft. Schließlich steht ein Trusted Channel zur Verfügung, der eine Datenübertragung an die HPC mit Secure Messaging ermöglicht.
13.3 Laden einer Anwendung oder einer neuen Datei
Für den Ladeprozess wird das LOAD APPLICATION Kommando genommen, wie es in Kapitel 14.2.5
von [HPC-P1] definiert ist. Fall ein einzelnes Kommando für die Übertragung der gesamten Anwendung oder Datei nicht ausreicht, wird möglicherweise Command Chaining genutzt.
Tabelle 222 – (N2617.00) LOAD APPLICATION Kommando zum Laden von Anwendungsdaten
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘EA’ = LOAD APPLICATION
‘00’
‘00’
‘xx’ oder 00xxxx’ = Länge des zugehörenden Datenfeldes
Neue anwendungsbezogene Daten
Nicht vorhanden
Tabelle 223 – (N2618.00) LOAD APPLICATION Antwort
Datenfeld
SW1-SW2
Nicht vorhanden
Das LOAD APPLICATION Kommando kann auch zum Anlegen eines neuen EFs verwendet werden,
siehe Kapitel 14.2.2 und 14.2.5 in [HPC-P1]. Falls für die angelegte Datei eine neue Zugriffsregel gilt,
dann muss diese Zugriffsregel in das COS integriert werden.
Seite 101 von 162
13.4 Eintragen einer neuen Anwendung in EF.DIR
Falls eine neue Anwendung geladen wurde, muss in EF.DIR ein DO Anwendungstemplate mit der
Kennung der neuen Anwendung eingefügt werden. Hierfür wird das Kommando APPEND RECORD
verwendet
Tabelle 224 - (N2619.00) APPEND RECORD Kommando
CLA
INS
P1
P2
Lc
Datenfeld
Le
‘E2’ = APPEND RECORD
‘00’
‘F0’ = b8-b4: 11110 SFID von EF.DIR: 30
b3-b1: 000
’xx’ = Länge des zugehörenden Datenfeldes
DO Application Template, siehe Tabelle 9
(N2010.00)
Nicht vorhanden
Tabelle 225 – (N2620.00) APPEND RECORD Antwort
Datenfeld
SW1-SW2
Nicht vorhanden
Seite 102 von 162
Annex A (normativ)
Kartenausgeberschlüssel, Nummernräume der
Zertifizierungsdiensteanbieter und
Certificate Holder Authorizations
A.1 Kartenausgeberschlüssel
Die Identifikationsnummer für Kartenherausgeber (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äß [ISO3166] 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 Eigentümer 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 [EN1867] 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
- Kartensperrung,
- kartenindividuelle Schlüsselableitung,
- Schlüsselidentifizierung (z.B. den öffentlichen Schlüssel in einem CV-Zertifikat),
- Erstellung von Daten, die für die Authentisierung relevant sind und
- Binden von Objekten oder Operationen an eine bestimmte Karte.
Die folgende Tabelle zeigt einige Kartenausgeberschlüssel, die im deutschen Gesundheitswesen für
Heilberufsausweise (HPCs) und Security Module Cards (SMCs) verwendet werden. Die vollständige
Liste der registrierten Kartenherausgeber ist nicht veröffentlicht, aber kann evt. bei GS1 angefordert
werden.
Seite 103 von 162
Tabelle 226 - (N2621.00) Kartenausgeberschlüssel (unvollständige Liste)
MII für das
Gesundheitswesen
‘80’
Länderkennung
Deutschland
Kartenausgeberschlüssel (Issuer Identifier)
‘276’
‘00101’
’00108’
’00109’
’00110’
’00279’
'00xxx'
Werbe- und Vertriebsgesellschaft Deutscher Apotheker mbH
Bundesärztekammer
Bundespsychotherapeutenkammer
Bundeszahnärztekammer
Kassenzahnärztliche Bundesvereinigung
Landeskrankenhausgesellschaften (DKTIG)
A.2 Nummernräume für Zertifizierungsdiensteanbieter
Jedem Zertifizierungsdiensteanbieter (ZDA) wurde ein individueller Nummernraum für Seriennummern
zugewiesen, um die ZDA-übergreifende Eindeutigkeit sowohl der ICCSN, als auch des Attributs
serialNumber der SubjectDN (Teil des Subject-Feldes im X.509-Zertifikat) zu garantieren. Für beide
Zwecke werden die zwei führenden Ziffern der Seriennummer als Präfix genutzt, um den Zertifizierungsdienstenbieter anzuzeigen, der für die Eindeutigkeit der restlichen Ziffern zuständig ist. Tabelle
227 (N2622.00) zeigt die vergebenen ZDA-Präfixe.
Tabelle 227 – (N2622.00) ZDA-Präfixe für Seriennummernräume
Präfix
10
11
12
13
14
15
16
Zertifizierungsdiensteanbieter
D-TRUST
Signtrust
T-Systems Telesec
S-Trust
TC TrustCenter
DGN
medisign
Die folgenden Beispiele zeigen ICCSNs von Karten, die von der Bundesärtzekammer (Kartenausgeberschlüssel ‘00108’) ausgegeben wurden und Seriennummern der D-TRUST bzw. Signtrust enthalten:
’80’ ‘276’ ‘00108’ ‘10 12345678’ ICCSN mit Seriennummer der D-TRUST
’80’ ‘276’ ‘00108’ ‘11 12345678’ ICCSN mit Seriennummer der Signtrust
A.3 Certificate Holder Authorizations und Profile
Die “Certificate Holder Authorization” (CHA) ist Teil der CV-Zertifikate jeder Karte, d.h. der HPC, der
SMC-A, der SMC-B und der anderen Karten in deutschen Gesundheitswesen. Sie wird insbesondere
in Zugriffsregeln verwendet, welche den kryptograpfischen Schlüsseln und den Dateien zugeordnet
sind, so dass die Karte bei einem bestimmten Zugriff von außen (z.B. Kommando zum Berechnen
einer digitalen Signatur oder zum Aktualisieren von Daten) selbst entscheiden kann, ob das entsprechende Kommando zulässig ist oder abgewiesen werden muss. Eine CHA wird nur dann als gültig
anerkannt, wenn der zugehörende Authentisierungsprozess erfolgreich ausgeführt wurde. Während
des Authentisierungsprozesses muss die externe Einheit (z.B. die HPC eines Heilberuflers einer bestimmten Berufsgruppe) nachweisen, dass sie den privaten Schlüssel besitzt, der zu dem im CVC enthaltenen öffentlichen Schlüssel gehört. Die Nutzung dieses privaten Schlüssels setzt in der HPC die
erfolgreiche Eingabe der zugehörenden PIN voraus, so dass die Ausführung der Authentisierung
rechtmäßig ist.
Seite 104 von 162
Die CHA besteht aus 7 Bytes und enthält eine Anwendungskennung (AID, erste 6 Bytes) und eine
Rollenkennung (Role ID, letztes Byte). Der AID wiederum besteht aus einem “Registered Application
Provider Identifier” (RID, erste 5 Bytes) und einer “Proprietary Application Provider Extension” (PIX).
Für Rollenkennungen im deutschen Gesundheitswesen wird die weltweit eindeutige Anwendungskennung ‘D27600004000’ verwendet. Der RID ‘D276000040’ 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. Die PIX des oben genannten AID wird auf ‘00’ gesetzt.
Die Rollenkennung beinhaltet die eigentliche Autorisierung des Karteninhabers, d.h. ein Profil für die
autorisierte Nutzung kryptografischer Schlüssel oder für den Zugriff auf Daten anderer Karten. Die Definition der Profile und die Zuordnung von Berufsgruppen zu einem bestimmten Profil ist nicht Gegenstand dieser Spezifikation. Zwei Profilgruppen sind für das deutsche Gesundheitswesen vorgesehen
(siehe [PKI-Reg] für weitere Details):
-
Profile für die Rollenauthentisierung von Berufsgruppen (z.B. Ärzte oder Apotheker), Mitarbeiter
der Berufsgruppen (z.B. Mitarbeiter von Ärtzten oder Apothekern) und Institutionen (z.B. Arztpraxen, Apotheken oder Krankenhäuser). Falls verschiedene Berufsgruppen dieselben Zugriffsrechte auf bestimmte Kartendaten besitzen, können sie demselben Profil zugeordnet werden. Dadurch können die Zugriffsregeln in den Karten kompakt gehalten werden. Gegenwärtig sind zehn
Profile (0-9) für die Rollenauthentisierung im deutschen Gesundheitswesen definiert, siehe
Tabelle 228 (N2623.00).
-
Profile für die Geräteauthentisierung bestimmter Karten und funktionaler Einheiten (z.B. PINEmpfänger oder Signaturkarte). Gegenwärtig sind fünf Profile (51-55) für die Geräteauthentisierung im deutschen Gesundheitswesen definiert, siehe Tabelle 229 (N2624.00).
Tabelle 228 – (N2623.00) CHAs für die Rollenautentisierung von Personen / Institutionen
(informativ)
CHA-Präfix
‘D27600004000’
CHA
Rollenkennung
‘00’
‘D27600004000’
‘01’
‘D27600004000’
‘02’
‘D27600004000’
‘03’
Profil des CVC-Inhabers
ZDA
Profil 0 zur Rollenauthentisierung
des Versicherten ohne Zugriffsrecht auf geschützte eGK-Daten
(eGK)
des eKiosk als Umgebung zur
Wahrnehmung der Rechte des
Versicherten (SMC-B)
- des Arztes/Zahnarztes in einer
Institution, z.B. eigene Praxis,
Gemeinschaftspraxis, Krankenhaus (HPC),
- des Mitarbeiters medizinische
Institution (z.B. in Arztpraxis,
Krankenhaus) (HPC oder BA),
- des Mitarbeiters medizinische
Institution (z.B. in Arztpraxis,
Krankenhaus) mit Autorisierung
und Protokollierung gemäß
§ 291a Abs. 5 Satz 4 SGB V
(SMC-A, SMC-B).
Der "Mitarbeiter medizinische Institution" verkörpert gegenüber
der Telematikinfrastruktur die
Institution des Arztes.
- des Apothekers in einer öffentli-
CA_eGK
Zugriffsbedingung des
(z.B. Authentisierung mit
CHA der zugehörigen Karte)
eGK: ALWAYS
CA_eKiosk SMC-B: tbd
CA_HPC
CA_SMC
HPC, BA: PWD(PIN.CH)
SMC-A, SMC-B in Praxis:
AUT(‘D27600004000’ || '02')
SMC-A, SMC-B in
Krankenhaus:
AUT( ‘D27600004000’ || '02')
OR
AUT( ‘D27600004000’ || '03')
OR
AUT( ‘D27600004000’ || '04')
OR
AUT( ‘D27600004000’ || '05')
Siehe Anmerkung 2
CA_HPC
CA_SMC
Seite 105 von 162
CHA-Präfix
‘D27600004000’
CHA
Rollenkennung
‘04’
‘D27600004000’
‘05’
‘D27600004000’
‘06’
‘D27600004000’
‘07’
‘D27600004000’
‘08’
‘D27600004000’
‘09’
‘D27600004000’
‘0A’ –
‘32’
chen Apotheke oder einer Krankenhausapotheke, jeweils mit
Sitz in Deutschland (HPC),
- des Mitarbeiters einer Apotheke
als berufsmäßiger Gehilfe oder
Person, die zur Vorbereitung auf
den Beruf tätig ist, gemäß § 291a
Abs. 5 Satz 4 SGB V (HPC oder
BA),
- des Mitarbeiters Apotheke mit
Autorisierung und Protokollierung
gemäß § 291a Abs. 5 Satz 4
SGB V (SMC-A, SMC-B).
Der „Mitarbeiter Apotheke" verkörpert gegenüber der Telematikinfrastruktur die Institution des
Apothekers.
- des psychologischen Psychotherapeuten, Kinder- und Jugendlichenpsychotherapeuten
(der ärztliche Psychotherapeut
verwendet Profil 2) (HPC),
- des Mitarbeiters psychologische
Praxis tbd (SMC-A, SMC-B)
- des Heilmittelerbringers (HPC
oder BA)
- des Hilfsmittelerbringers (BA)
einer Instanz tbd (SMC-A oder
SMC-B)
des im Rettungswesen medizinisch tätigen Personals (Rettungssanitäter, Rettungsassistent) (HPC oder BA). Dabei handelt es sich um Angehörige eines
anderen Heilberufs, die für die
Berufsausübung oder die Führung der Berufsbezeichnung eine
staatlich geregelte Ausbildung
(§ 291a Abs. 4 Satz 1 Nr. 2 e)
absolviert haben.
- des Mitarbeiters von Gesundheitseinrichtungen ohne eigenen
HPC oder BA (SMC-A, SMC-B)
- des Mitarbeiters von Krankenkassen (SMC-A, SMC-B)
- des Mitarbeiters von Gesundheitseinrichtungen ohne eigenen
HPC oder BA (SMC-A, SMC-B)
- der sicheren Einsatzumgebung
für den Versicherten (SMC-A,
SMC-B)
Profile 10 – 50 für eine spätere
Nutzung reserviert
ZDA
(z.B. Authentisierung mit
CHA der zugehörigen Karte)
SMC-A, SMC-B:
AUT(‘D27600004000’ || '03')
CA_HPC
CA_SMC
HPC: PWD(PIN.CH)
SMC-A, SMC-B:
AUT(‘D27600004000’ || '04')
tbd
tbd
SMC-A oder SMC-B: tbd
tbd
tbd
SMC-A, SMC-B: tbd
tbd
SMC-A, SMC-B: tbd
tbd
tbd
Anmerkung 1 – Viele oder alle ZDAs in Tabelle 228 (N2623.00) können identisch sein. Alle CV-Zertifikate von
HPC und SMC stammen von derselben Wurzel-Zertifizierungsinstanz für CV-Zertifikate.
Seite 106 von 162
Anmerkung 2 – Die SMC eines Krankenhauses besitzt dieselben Zugriffsrechte auf eine eGK wie die SMC einer
Arzt- oder Zahnarztpraxis. Während die SMC einer Praxis jedoch ausschließlich (ungeachtet der Eingabe von
PIN.SMC) durch den HPC eines Arztes oder Zahnarztes autorisiert werden kann, sind möglicherweise die Profile
mehrerer Berufsgruppen berechtigt, die SMC in einem Krankenhaus zu autorisieren. Die aufgeführten Profile stellen die maximal zugelassenen Profile dar. Die zuständige Institution kann daraus eine Untermenge festlegen, die
zur Autorisierung einer bestimmten SMC berechtigt ist.
Tabelle 229 – (N2624.00) CHAs für die für Geräteauthentisierung von funktionellen Einheiten
(informativ)
CHA-Präfix
‘D27600004000’
CHA
Rollenkennung
‘33’
‘D27600004000’
‘34’
‘D27600004000’
‘35’
‘D27600004000’
‘36’
‘D27600004000’
‘37’
ZDA
Profil 51 für die Geräteauthentisierung der sicheren Signaturumgebung der SAK (SMC-K )
Profil 52 für die Geräteauthentisierung des Auslösers der Komfortsignatur (RFID Token oder
Biometriemodul)
CA_SAK
Profil 53 für die Geräteauthentisierung der SSEE für Stapelund Komfortsignatur (HPC)
Profil 54 für die Geräteauthentisierung eines PIN-Senders
(SMC-A, SMC-B)
Profil 55 für die Geräteauthentisierung eines PIN-Empfängers
(SMC-B, RFID Token)
CA_KM
(z.B. Authentisierung mit CHA
der zugehörigen Karte)
SMC-K:
AUT(‘D27600004000’ || ‘35’)
RFID-Token:
PWD(PIN.CH) OR ALWAYS
Biometriemodul:
PWD(Biometrisches Merkmal)
CA_HPC HPC:
ALWAYS
CA_SMC SMC-A und SMC-B:
AUT(‘D27600004000’ || ‘35’) OR
AUT(‘D27600004000’ || ‘37’)
CA_SMC SMC-A, SMC-B:
CA_KM
ALWAYS
Anmerkung – Viele oder alle ZDAs in Tabelle 229 (N2624.00) können identisch sein. Alle CV-Zertifikate von
HPC und SMC stammen von derselben Wurzel-Zertifizierungsinstanz für CV-Zertifikate.
Die HPC besitzt zwei CV-Zertifikate:
-
C.HPC. AUTR_CVC für die Rollenauthentisierung (siehe in Kapitel 4.3.7) mit einem Profil des
Karteninhabers als Mitglied einer Berufsgruppe und
-
C.HPC.AUTD_SUK_CVC für die Geräteauthentisierung (siehe in Kapitel 4.3.8) mit dem Profil 53
einer SSEE für die Stapel- und Komfortsignatur. Dieses Profil wird zum Empfang der zu
signierenden Daten und der PIN-Daten genutzt.
Die SMC-A besitzt zwei CV-Zertifikate:
-
C.SMC.AUTR_CVC für die Rollenauthentisierung (siehe Kapitel 5.3.7 in [HPC-P3]) mit einem
Profil der Mitarbeiter bzw. der Institution und
C.SMC.AUTD_RPS_CVC für die Geräteauthentisierung (siehe Kapitel 5.3.8 in [HPC-P3]) mit
dem Profil 54 eines PIN-Senders.
Die SMC-B besitzt drei CV-Zertifikate:
-
C.SMC.AUTR_CVC für die Rollenauthentisierung (siehe Kapitel 6.3.7 in [HPC-P3]) mit einem
Profil der Mitarbeiter bzw. der Institution,
Seite 107 von 162
-
C.SMC. AUTD_RPS_CVC für die Geräteauthentisierung (siehe Kapitel 6.3.8 in [HPC-P3]) mit
dem Profil 54 eines PIN-Senders,
-
C.SMC.AUTD_RPE_CVC für die Geräteauthentisierung (siehe Kapitel 6.3.9 in [HPC-P3]) und mit
dem Profil 55 eines PIN-Empfängers.
Seite 108 von 162
Annex B (normativ)
Struktur und Inhalt der QES-Zertifikate
B.1 Zertifikat des öffentlichen Schlüssels für elektronische Signaturen (X.509v3
QES-Zertifikat)
B.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 Common PKI-Spezifikation für interoperable PKI-Anwendungen (speziell Teil 1: "Certificate
and CRL Profiles" [COM-PKI-1], und dem optionalen Profil "SigG-Profile"[COM-PKI-9].
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-Attributzertifikaten.
Das QES-Public-Key-Zertifikat ist nachfolgend als eine Teilmenge der Common PKI-Spezifikation für
Zertifikate beschrieben. Die Attributzertifikate sind in Kapitel B.7 beschrieben.
B.1.2 Zertifikatsstruktur
Die generelle Zertifikatsstruktur besteht aus drei verbindlichen Teilen:
-
dem zu signierenden Zertifikatsinhalt,
dem Signaturalgorithmus 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 }
Seite 109 von 162
B.2 ToBeSignedCertificate
B.2.1 Allgemeine 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,
[2]
[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.
B.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.
B.2.3 Seriennummer
Die serialNumber identifiziert in Kombination mit den issuer-Namensfeldern der QES-Zertifikate ein
ES-Zertifikat ([RFC2459]) eindeutig. Diese Anforderung an Eindeutigkeit ist in [COM-PKI-1] auf alle
Arten von Zertifikaten erweitert, d.h., sie gilt sowohl für ES als auch für Attributzertifikate (ACs).
Die ASN.1-Definition des Typs CertificateSerialNumber für das Feld serialNumber:
CertificateSerialNumber
::=
INTEGER
Die Definition von [RFC2459] für Seriennummern setzt für den Wert oder die Länge dieses Feldes
keine Obergrenze. [RFC3280] verlangt jedoch, 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 [COM-PKI-1] und müssen bei
QES-Zertifikaten für Heilberufler berücksichtigt werden.
B.2.4 Signatur
Das Feld signature vom Typ AlgorithmIdentifier benennt den Signaturalgorithmus, der von der
Certification Authority (CA) benutzt wurde, um dieses Zertifikat zu signieren. Sein Inhalt muss mit dem
des Feldes signatureAlgorithm (siehe B.3) übereinstimmen.
Die ASN.1 Definition des Typs AlgorithmIdentifier für das Feld signature:
Seite 110 von 162
Algorithmidentifier
algorithm
parameters
::=
SEQUENCE {
OBJECT IDENTIFIER,
ANY DEFINED BY algorithm OPTIONAL }
B.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
teletexString
utf8String
bmpString
universalString
::=
CHOICE {
PrintableString (SIZE (1..maxSize))
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 ASCII-Kodierung, internationale
Version
-
Eine Teletex-Zeichenfolge (TeletexString) enthält Zeichen gemäß dem T.61-Alphabet, mit dem
spezifisch deutsche Zeichen wie Umlaute (ä, ö, ü) und ß kodiert werden können.
-
Die UTF8-Kodierung, definiert in [RFC3629], 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ärtskompatibilität aufgeführt worden und DÜRFEN NICHT für neue Zertifikate
verwendet werden. [COM-PKI-1] 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-QES-Zertifikate in
Übereinstimmung mit dieser Spezifikation genutzt werden dürfen, sind nur die folgenden Attribute
zwingend vorgeschrieben:
-
country name und
organization name.
Die Nutzung anderer Attributstypen, z.B. der Seriennummer, ist optional.
Seite 111 von 162
Das Kodierschema für alle Attributstypen issuer in den HB-QES-Zertifikaten ist in Tabelle 7 von [COMPKI-1] definiert.
B.2.5.1 Country name
Der "country name" benennt das Land, in dem die CA ihren Stammsitz hat.
Die ASN.1 Definition des Attributtyps countryName:
id-at
id-at-countryName AttributeType
CountryName
::=
::=
::=
{254}
{ id-at 6 }
PRINTABLE STRING (SIZE(2))
Die „PrintableString“-Repräsentation des Ländernamens für Deutschland ist gemäß [ISO3166] „DE“.
B.2.5.2 Organization name
Der "organization name" identifiziert die CA.
Die ASN.1 Definition des Attributtyps organizationName:
id-at-organizationName AttributeType
OrganizationName
::= { id-at 10 }
::= DirectoryString (SIZE(1..64))
B.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
::=
CHOICE {
UTCTime,
GeneralizedTime }
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.
Seite 112 von 162
Beispiel:
"20030101000000Z"
Die maximale Gültigkeitsdauer wird von der CA festgelegt und folgt gesetzlichen Vorgaben, die von
der Stärke der benutzten Algorithmen abhängen.
B.2.7 Subject
Das Feld subject identifiziert den Zertifikatsinhaber im Sinne einer technischen Identifizierung (die
juristische Identifizierung kann gemäß Common PKI-Spezifikation mittels Erweiterung subjectDirectoryAttributes erfolgen, siehe B.2.9.5). 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 Common PKI-Spezifikation oder relevanten RFCs
entsprechen, ist optional.
Das Kodierschema für diese subject-Attributstypen in HB-QES-Zertifikaten ist in Tabelle 7 von [COMPKI-1] definiert.
B.2.7.1 Country name
Der "country name" identifiziert das Land, in dem der Zertifikatsinhaber angemeldet ist. Die in Kapitel
B.2.5.1 beschriebenen Regeln finden hier Anwendung.
B.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 Kodierungsvariante für DirectoryString ist das UTF8-Subset, das nur ANSI/ISO 88591-Zeichen (Unicode Latin-1 page) enthält (siehe auch Anmerkungen in B.2.5).
B.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:
id-at-commonName AttributeType ::= { id-at 3 }
CommonName
Die bevorzugte Kodierungsvariante für DirectoryString ist das UTF8-Subset, das nur ANSI/ISO 88591-Zeichen (Unicode Latin-1 page) enthält (siehe auch Anmerkungen in C.2.5).
Seite 113 von 162
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 B.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 :PN vorangestellte
Zahl unterschieden werden, 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.
B.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
SerialNumber
::= { id-at 5 }
::= PRINTABLE STRING (SIZE(1..64))
B.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 Typs 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:
-
den Signaturalgorithmus (verbindlich),
den Hash-Algorithmus (falls erforderlich), und
das Padding-Format, z.B. das DSI-Format (falls erforderlich).
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 Signaturalgorithmus, das DSI-Format und der Hash-Algorithmus (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 die HPC sind relevant:
-
der Signaturalgorithmus RSA oder – in der Zukunft – auch ECDSA,
die Hash-Algorithmen der SHA-2-Familie (insbesondere SHA-256)
Seite 114 von 162
-
die Paddding-Formate, d.h. die DSI-Formate PKCS#1 SSA-V1.5, PKCS#1 PSS und ISO/IEC
9796-2 DS2.
Bei einer Prüfung muss als erstes der Signaturalgorithmus bekannt sein und angewendet werden; d.h.
im Zertifikat muss die OID für den Signaturalgorithmus 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. Die Angabe des Hash-Algorithmus wird von PKCS#1 SSA-V1.5
unterstützt (die Digestinfo von PKCS#1 enthält den OID des Hash-Algorithmus). Die Anzeige des
Hash-Algorithmus ist auch im DSI-Format ISO/IEC 9796-2 DS2 für die Option 2 (d.h. 2-Byte-Trailer mit
Kennung der Hash-Funktion und ‘CC’) enthalten. Allerdings fehlt sie im DSI-Format ISO/IEC 9796-2
DS2 für die Option 1 (mit Trailer ‘BC’) und im DSI-Format PKCS#1 PSS. Da die HPC alle drei Signaturalgorithmen unterstützt, muss der OID sowohl den RSA-Algotithmus, als auch den Hash-Algorithmus SHA-256 anzeigen.
B.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 der Anwendung bekannt und von ihr verarbeitbar sein MUSS. Andernfalls muss
das komplette Zertifikat bei der Prüfung abgelehnt werden. Als Wert der Erweiterung wird eine Folge
von Octets definiert. Leere Erweiterungen sollen nicht gesetzt werden.
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 [COM-PKI-9] und
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
CRL distribution points.
Seite 115 von 162
Diese "basic X.509 certificate extensions" werden durch folgenden übergeordneten object-identifierZweig identifiziert:
id-ce OBJECT IDENTIFIER
::= { 2 5 29 }
Private X.509 extension für qualifizierte Zertifikate:
-
qualified certificate statements
authority information access.
Die "X.509 certificate extensions" werden durch folgenden übergeordneten object-identifier-Zweig
identifiziert:
id-pe OBJECT IDENTIFIER
::= { 1 3 6 1 5 5 7 1 }
Common PKI SigG Private X.509 Extensions:
-
admission
restriction
additional information
Die "Common PKI SigG private X.509 certificate extensions" werden durch folgenden übergeordneten
object-identifier-Zweig identifiziert:
id-commonpki OBJECT IDENTIFIER
id-commonpki-at OBJECT IDENTIFIER
::= { 1 3 36 8 }
::= { id-commonpki 3 }
BNA Private X.509 Extensions:
-
validity model.
B.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
pathLenConstraint
::=
{ id-ce 19 }
SEQUENCE {
INTEGER (0..MAX) OPTIONAL }
B.2.9.2 Schlüsselnutzung (Key Usage)
Dieses Feld spezifiziert die Nutzung der zertifizierten Public Keys:
Die ASN.1 Definition des Typs KeyUsage:
id-ce-keyUsage OBJECT IDENTIFIER
::= { id-ce 15 }
Seite 116 von 162
KeyUsage
digitalSignature
nonRepudiation
keyEncipherment
dataEncipherment
keyAgreement
keyCertSign
cRLSign
encipherOnly
decipherOnly
::=
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 Authentifizierungszertifikate. 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.
B.2.9.3 Certificate Policies
In diesem Feld werden die Zertifikats-Policies definiert, die bei der Ausgabe des Zertifikates gültig
waren. Die Erweiterung MUSS vorhanden sein, und sie SOLL als NICHT kritisch markiert werden. Die
Werte müssen in Übereinstimmung mit [COM-PKI-1] 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
NICHT als kritisch markiert werden, obwohl ihr Inhalt die Nutzbarkeit von Zertifikaten einigermaßen
einschränkt. Da andererseits diese Information extrem wichtig für die rechtliche Gültigkeit von digitalen
Signaturen ist, MUSS 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
PolicyQualifierInfo OPTIONAL}
PolicyQualifierInfo
policyQualifierId
qualifier
::=
SEQUENCE {
PolicyQualifierId,
ANY DEFINED BY policyQualifierId }
CertPolicyId
::=
OBJECT IDENTIFIER
-- commonpki branch for certificate policies
id-commonpki-cp OBJECT IDENTIFIER
::= { id-commonpki 1 }
id-commonpki-cp-accredited OBJECT IDENTIFIER
::= { id-commonpki-cp 1 }
B.2.9.4 Subject Alternative Name
Dieses Feld enthält einen oder mehrere „alternative technical names“ des Zertifikats-Inhabers, z. B.
eine eindeutige E-Mail-Adresse oder die eindeutige Internetadresse der Homepage des betreffenden
Nutzers. Da das Feld subject den Kartenbesitzer eindeutig identifiziert, SOLL die Erweiterung
SubjectAltNames NICHT als kritisch markiert werden.
Die ASN.1 Definition des Typs SubjectAltName:
id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
Seite 117 von 162
SubjectAltName
::=
GeneralNames
GeneralNames
::=
SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralName
otherName
rfc822Name
dNSName
x400Address
directoryName
ediPartyName
uniformResourceIdentifier
iPAddress
registeredID
::=
CHOICE {
[0] IMPLICIT OtherName,
[1] IMPLICIT IA5String,
[3] IMPLICIT ORAddress,
[4] EXPLICIT Name,
[5] IMPLICIT EDIPartyName,
[7] IMPLICIT OCTET STRING,
[8] IMPLICIT OBJECT IDENTIFIER }
OtherName
type-id
Value
::=
SEQUENCE {
OBJECT IDENTIFIER
[0] EXPLICIT ANY DEFINED type-id }
ORAddress
::=
built-in-standard-attributes
built-in-domain-defined-attributes
extension-attributes
SEQUENCE {
ANY,
SEQUENCE OF ANY OPTIONAL,
SET OF ANY OPTIONAL }
EDIPartyName
NameAssigner
partyName
SEQUENCE {
[0] EXPLICIT DirectoryString OPTIONAL,
[1] EXPLICIT DirectoryString }
::=
In RFC822 ist die Konvention zur Bildung von E-Mail-Adressen definiert. Ein Beispiel für eine E-MailAdresse:
"[email protected]"
B.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 kritisch
markiert werden.
Die ASN.1 Definition des Typs SubjectDirectoryAttributes:
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::=
SubjectDirectoryAttributes
::=
{ id-ce 9 }
Attributes
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
::=
::=
::=
{245}
{ id-at 12 }
DirectoryString (SIZE(1..64))
Seite 118 von 162
"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
::=
::=
{1361557}
{ id-pkix 9 }
Date of Birth Attribute
Optionales Attribut, das das Geburtsdatum des Karteninhabers enthält.
id-pda-dateOfBirth AttributeType
DateOfBirth
::=
::=
{ id-pda 1 }
GeneralizedTime
Place of Birth Attribute
Optionales Attribut, das den Geburtsort des Karteninhabers enthält.
id-pda-placeOfBirth AttributeType ::=
PlaceOfBirth
::=
{ id-pda 2 }
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 [COM-PKI-1] definiertes optionales Attribut, das den Geburtsnamen des Karteninhabers enthält.
id-commonpki-at-nameAtBirth OBJECT IDENTIFIER ::= { id-commonpki-at 14 }
NameAtBirth
B.2.9.6 Authority Key Identifier
Dieses Feld ist gemäß [COM-PKI-1] 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 kritisch
markiert werden.
Die ASN.1-Definition des Typs AuthorityKeyIdentifier:
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
AuthorityKeyIdentifier
::=
SEQUENCE {
keyIdentifier
[0] IMPLICIT KeyIdentifier
authorityCertIssuer
[1] IMPLICIT GeneralNames
OPTIONAL,
OPTIONAL,
Seite 119 von 162
authorityCertSerialNumber
KeyIdentifier
::=
[2] IMPLICIT CertificateSerialNumber
OPTIONAL }
OCTET STRING
Anmerkung – Beide Identifikationsmethoden, die in [RFC2459] beschrieben sind, KÖNNEN im selben Zertifikat
benutzt werden. [COM-PKI-1] fordert, dass das Feld keyIdentifier exakt dieselbe ID enthalten MUSS wie der
subjectKeyIdentifier des CA-Zertifikates (siehe B.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.
B.2.9.7 Subject Key Identifier
Dieses Feld enthält eine Referenz zum PK des Zertifikatsinhabers und ist gemäß Common PKISpezifikation optional; seine Verwendung wird aber empfohlen. Der "subject key Identifier" in Form der
ICCSN (in Verbindung mit der key usage) kann in HPCs 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
::=
::=
{ id-ce 14 }
OCTET STRING
B.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
OBJECT IDENTIFIER
accessLocation GeneralName }
Der OID-Wert id-ad-ocsp {id-ad 1} nutzt die Komponente accessMethod, um den OCSP-Service
anzuzeigen. Die OCSP-URL wird im Feld accessLocation angegeben.
B.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. Hybridmodelle, sind ebenfalls möglich. Informationen über die Gültigkeitsmodelle können im Internet gefunden werden:
-
BNetzA: http://www.bundesnetzagentur.de/media/archive/1343.pps
OIDs: http://www.informatik.tu-darmstadt.de/TI/Forschung/FlexiPKI/validitymodel/index.html
Die ASN.1-Definition des Typs ValidityModel:
id-validityModel OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 8301 3 5 }
Seite 120 von 162
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 }
B.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 B.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
statementInfo
::=
SEQUENCE {
OBJECT IDENTIFIER,
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
::=
semanticsIdentifier
nameRegistrationAuthorities
SEQUENCE {
OBJECT IDENTIFIER OPTIONAL,
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 ZertifikatsPolicy 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}
Seite 121 von 162
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.
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.
B.2.9.11 CRL Distribution Points
Dies Feld bestimmt, wie CRL-Informationen erhalten werden können. Die Erweiterung sollte als nicht
kritisch markiert werden.
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
::=
CHOICE {
[0] GeneralNames,
Seite 122 von 162
nameRelativeToCRLIssuer
ReasonFlags
unused
keyCompromise
cACompromise
affiliationChanged
superseded
cessationOfOperation
certificateHold
priveledgeWithdrawn
aACompromise
RelativeDistinguishedName }
::=
BIT STRING {
(0),
(1),
(2),
(3),
(4),
(5),
(6),
(7),
(8) }
Dieses Feld ist gemäß [COM-PKI-1] verpflichtend, falls indirekte CRLs veröffentlicht werden, und es
sollte vorhanden sein, falls direkte CRLs veröffentlicht werden.
B.2.9.12 Professional Admission
Zulassungsinformationen für Heilberufler können im Basis-QES-Zertifikat durch die Nutzung der in
[COM-PKI-9] aufgeführten "private extension" admission vom Typ AdmissionSyntax angegeben
werden, oder in einem oder mehreren Attributzertifikaten durch die Nutzung des Attributs admission,
das auch vom Typ AdmissionSyntax ist, ebenfalls wie in [COM-PKI-9] 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-commonpki-at-admission OBJECT IDENTIFIER
id-commonpki-at-namingAuthorities OBJECT IDENTIFIER
::= { commonpki-at 3 }
::= { commonpki-at 11 }
AdmissionSyntax
admissionAuthority
contentsOfAdmissions
::=
SEQUENCE {
GeneralName OPTIONAL,
SEQUENCE OF Admissions}
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.),
Seite 123 von 162
die verantwortlich für die Erteilung und Prüfung von Zulassungen sind. Eine Zulassungsstelle wird
durch ein Objekt GeneralName benannt (siehe B.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 Webseite, die Listen von "offiziell" eingetragenen
Berufsbezeichnungen und zusätzliche Informationen zu diesen Berufsgruppen enthält (Text und
möglicherweise OIDs).
-
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,
die professionOID und die Registrierungsnummer sind immer erforderlich, während die anderen
Indikatoren, d.h. namingAuthority und addProfessionInfo, optional sind. In Verschlüsselungs- und
Authentisierungzertifikaten enthält das Feld registrationNumber eine eindeutige Nummer („Telematik-ID“), die zur Identifikation des Karteninhabers und zur Kartengenerationen übergreifenden
Zuordnung der Zertifikate verwendet wird. Es wird empfohlen (unterliegt der Entscheidung des
Karteninhabers), dass diese Nummer immer gleich bleibt. Eine Registrierungsnummer darf nicht
mehr als einer Person zugeordnet werden. Daher muss ein Präfix verwendet werden, welches
sicherstellt, dass die Herausgeberorganisationen unterschiedliche Nummernräume verwenden,
sieheTabelle 230 (N2625.00). Der Präfix ist von der eigentlichen Nummer durch ein Minuszeichen („-“) (ASCII 45) getrennt. Beispielsweise könnte die Telematik-ID eines Arztes 112100123456789012 sein, siehe [TID]. Die Komponente addProfessionInfo kann zusätzliche
anwendungsbezogene Informationen (DER-kodiert) enthalten.
Tabelle 230 – (N2625.00) Präfixe der Registrierungsnummern
Präfix
Bedeutung
1
Ärzteschaft
2
Zahnärzteschaft
3
Apothekerschaft
4
Psychotherapeutenschaft
5
Krankenhaus
6
Weitere Sektoren bzw. sonstige Leistungserbringer und deren
Institutionen
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 Zertifizierungsstelle 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.
Seite 124 von 162
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
Attributzertifikaten eine namingAuthorityURL anzugeben. Falls eine namingAuthorityURL angegeben
ist, sollte das Feld professionItems von ProfessionInfo nur registrierte Titel enthalten. Das Feld
professionOIDs muss 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:
Berufsgruppe „Ärzte":
Im Basis-QES-Zertifikat sollte angegeben werden, dass der Inhaber des Zertifikates ein Arzt ist. Die
Mindestinformation, die in der Erweiterung admission des Basiszertifikates angegeben sein muss, ist
"Ärztin/Arzt" in der Komponente professionItems von AdmissionSyntax.
{ ..., professionItems {"Ärztin/Arzt"}, ... }
Anmerkung – Diese und weitere berufsspezifische Informationen können in einem Attributzertifikat für Qualifikationen (siehe B.7.1) oder in einem Attributzertifikat für Autorisierungen (siehe B.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", "PTA-Praktikant" oder "Azubi" ist.
Zum Beispiel muss bei einem "Apotheker" mindestens die Bezeichnung "Apotheker" in professionItems enthalten sein.
{ ..., professionItems {"Apotheker"}, ... }
Anmerkung – Nur den Gruppenmitgliedern „Apotheker“, „Apothekerassistent“, „Apothekenassistent“, „PTA“ und
„Pharmazieingenieur“ ist es erlaubt, elektronische Verordnungen digital zu signieren. Jedoch dürfen alle
Gruppenmitglieder andere Dokumente, außer elektronische Verordnungen digital signieren. Weitere berufsgruppenspezifische Informationen können in dieser Erweiterung des Basis-QES-Zertifikats oder im Attribut
admission in einem oder in mehreren Attributzertifikaten (siehe B.7) enthalten sein.
Neben der Benennung der Qualifikation des Karteninhabers hat die Berufsgruppe "Apotheker" die
folgenden Kategorien für zusätzliche Berufsinformationen 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.
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 Attributzertifikates eingefügt werden können.
Seite 125 von 162
{ 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" } } } } } }
B.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-commonpki-at-restriction OBJECT IDENTIFIER ::= {commonpki-at 8}
RestrictionSyntax ::= DirectoryString (SIZE(1..1024))
Die Kodierung des DirectoryString erfolgt in UTF-8.
B.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 Zertifikatsinhalte verantwortlich ist,
kann entscheiden, zusätzliche Informationen wie “ This certificate belongs to an approved medical id
card issued by the responsible local medical chamber" 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-commonpki-at-additionalInformation OBJECT IDENTIFIER ::= {commonpki-at 15}
AdditionalInformationSyntax ::= DirectoryString (SIZE(1..2048))
Die Kodierung des DirectoryString erfolgt in UTF-8.
B.3 Signature algorithm
Dieses Feld enthält dieselbe Kodierung wie das Signaturfeld in der to “be signed sequence”.
B.4 Signature
Dieses Feld enthält die Signatur der CA, die das Zertifikat ausgestellt hat.
Seite 126 von 162
B.5 QES-Zertifikat in Tabellenform und mit vollständiger 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.
Tabelle 231 – (N2626.00) Inhalt des QES-Zertifikats eines Heilberuflers
Zertifikatsfeld
Inhalt
version
serialNumber
signature
issuer
X.509v3
Seriennummer des Zertifikats
Algorithmenkennung der CA-Signatur
Zertifizierungsinstanz (CA)
DE für Deutschland
z.B. DEZGW für deutsche CA im Gesundheitswesen
Gültigkeitszeitraum
Koordinierte Weltzeit (UTC Time)
Koordinierte Weltzeit (UTC Time)
Zertifikatsinhaber (Certificate holder)
DE für Deutschland
Bundesland
Vollständiger Allgemeiner Name (Common name)
Seriennummer für die eindeutige Bennennung des
Zerttifikatsinhabers
Daten des öffentlichen Schlüssels
OID des Algorithmus incl. Parameter (falls
vorhanden)
Öffentlicher Schlüssel mit Modulus und öffentlichem
Exponenten
Erweiterungen
Klassifikation als Endbenutzerzertifikat
Nicht-Abstreitbarkeit (nonRepudiation), d.h. Nutzung
des Zertifikats auf digitale Signaturen gemäß SigGAnforderung beschränkt
Angabe der SigG-Konformität
Alternativer technischer Name, möglicherweise mit
e-Mail-Adresse des Zertifikatsinhabers
X.500-Attribute für zusätzliche persönliche Daten wie
zum Beispiel Geburtsdatum, Geburtsort, Geschlecht,
Staatsangehörigkeit, Land des Wohnsitzes und
Geburtsname
Referenz des öffentlichen CA-Schlüssels für die
Prüfung der CA-Signatur
Referenz des öffentlichen Schlüssels des
Zertifikatsinhabers
Angabe wie und wo Informationen über den Status
des Zertifikats erhältlich sind
Information über das Verfahren zur Prüfung der
Zertifikatsgültigkeit
Angabe, dass das Zertifikat ein qualifiziertes
Zertifikat ist, und gegebenenfalls obere Grenze des
Geldbetrags in Transaktionen
Angabe wie CRL-Information erhalten werden
können
Information zur Berufszulassung
Weitere Beschränkungen der Zertifikatsnutzung
Nicht-einschränkende Information zur
Zertifikatsnutzung
Algorithmuskennung der CA-Signatur (Wert identisch
zum Signaturfeld im Zertifikatsinhalt
CA-Signatur
countryName
organizationName
validity
notBefore
notAfter
subject
countryName
stateOrProvince
commonName (CN)
serialNumber
algorithm
subjectPublicKey
extensions
basicConstraints
keyUsage
certificatePolicies
subjectAltName
subjectDirectoryAttributes
authorityKeyIdentifier
subjectKeyIdentifier
authorityInfoAccess
validityModel
qcStatements
cRLDistributionPoints
admission
restriction
additionaInformation
signatureAlgorithm
signature
Common
PKIReferenz
T2 #2 #12
T2 #13
T2 #4, T4
T2 #5, T5
T7 #13
T7 #6
T2 #6, T3
T3 #2
T3 #3
T2 #7, T5
T7 #13
T7 #12
T7 #1
T7 #4
Diese
Spezifikation,
Kapitel
B.2.2
B.2.3
B.2.4
B.2.5
B.2.5.1
B.2.5.2
B.2.6
B.2.6
B.2.6
B.2.7
B.2.7.1
B.2.7.2
B.2.7.3
B.2.7.4
Diese
Spezifikation,
Verwendung
vorgeschrieben
vorgeschrieben
vorgeschrieben
vorgeschrieben
vorgeschrieben
vorgeschrieben
vorgeschrieben
vorgeschrieben
vorgeschrieben
vorgeschrieben
vorgeschrieben
optional
vorgeschrieben
optional
T2 #8 #14
T2 #15
B.2.8
B.2.8
vorgeschrieben
vorgeschrieben
T2 #16
B.2.8
vorgeschrieben
T2 #11, T9
T10, T18
T10, T12
B.2.9
B.2.9.1
B.2.9.2
vorgeschrieben
optional
vorgeschrieben
T10, T14
T10, T16
#1
T10, T17
B.2.9.3
B.2.9.4
optional
optional
B.2.9.5
optional
T10, T11
B.2.9.6
vorgeschrieben
T10, T11
B.2.9.7
optional
T10, T13,
T23
-
B.2.9.8
optional
B.2.9.9
optional
T10, T25
B.2.9.10
vorgeschrieben
T10, T22
B.2.9.11
optional
T29, T29b
T29, T29e
T29, T29f
B.2.9.12
B.2.9.13
B.2.9.14
vorgeschrieben
optional
optional
T1 #3, T4
B.3
vorgeschrieben
T1 #4
B.4
mandatory
Seite 127 von 162
Im Folgenden ist die vollständige Syntax des QES-Zertifikats angegeben:
Certificate DEFINITIONS IMPLICIT TAGS ::=
-- IMPLICIT TAGS: Since all objects are tagged, the tags of universal data types are omitted
BEGIN
IMPORTS Controls, BasicLatin, Latin-1Supplement FROM ASN.1-CHARACTER-MODULE
{joint-iso-itu-t asn1(1) specification(0) modules(0) iso10646(0)}
-- Further character sets of [ISO10646] may be imported in order to form an internationally
-- usable character subset of the [ISO10646] Universal Multiple-Octet Coded Character Set (UCS).
Certificate
tbsCertificate
signatureAlgorithm
signature
::=
SEQUENCE {
TBSCertificate,
BIT STRING }
::=
SEQUENCE {
[0]
EXPLICIT Version DEFAULT v1,
Name,
Validity,
Name,
SubjectPublicKeyInfo,
[1]
[2]
[3]
EXPLICIT Extensions Optional }
-- version
Version
::=
INTEGER { v1(0), v2(1), v3(2) }
-- serial number
CertificateSerialNumber
::=
INTEGER
::=
SEQUENCE {
OBJECT IDENTIFIER,
-- to be signed certificate
TBSCertificate
version
serialNumber
signature
issuer
validity
subject
issuerUniqueID
subjectUniqueID
extensions
-- signature
Algorithmidentifier
algorithm
parameters
-- issuer
Name
::= CHOICE { RDNSequence }
RDNSequence
::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName
::=
AttributeTypeAndValue
type
Value
SET OF AttributeTypeAndValue
::= SEQUENCE {
AttributeType,
AttributeValue }
AttributeType
::=
OBJECT IDENTIFIER
AttributeValue
::=
ANY DEFINED BY AttributeType
-- directory string
Seite 128 von 162
DirectoryString
printableString
teletexString
utf8String
bmpString
universalString
::=
CHOICE {
PrintableString (SIZE (1..maxSize))
TeletexString (SIZE (1..maxSize))
UTF8String (SIZE (1..maxSize))
BMPString (SIZE (1..maxSize))
UniversalString (SIZE (1..maxSize)) }
-- country name attribute
CountryName
::=
PRINTABLE STRING (SIZE(2))
-- organization name attribute
OrganizationName
::=
::=
SEQUENCE {
Time,
Time }
::=
CHOICE {
UTCTime,
GeneralizedTime }
-- validity
Validity
notBefore
notAfter
Time
utcTime
generalizedTime
-- state or province name attribute
StateOrProvinceName
::=
-- common name attribute
CommonName
::=
-- serial number attribute
SerialNumber
::=
PRINTABLE STRING (SIZE(1..64))
::=
SEQUENCE {
BIT STRING }
::=
::=
SEQUENCE (1..MAX) OF Extension
SEQUENCE {
OBJECT IDENTIFIER,
OCTET STRING }
-- subject public key info
SubjectPublicKeyInfo
algorithm
subjectPublicKey
-- extensions
Extensions
Extension
extnId
critical
extnValue
-- basic constraints extension
BasicConstraints
cA
pathLenConstraint
-- key usage extension
KeyUsage
digitalSignature
nonRepudiation
keyEncipherment
dataEncipherment
keyAgreement
keyCertSign
::=
SEQUENCE {
INTEGER (0..MAX) OPTIONAL }
::=
BIT STRING {
(0),
(1),
(2),
(3),
(4),
(5),
Seite 129 von 162
cRLSign
encipherOnly
decipherOnly
-- certificate policies extension
CertificatePolicies
(6),
(7),
(8) }
::=
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
::=
SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralName
otherName
rfc822Name
dNSName
x400Address
directoryName
ediPartyName
uniformResourceIdentifier
iPAddress
registeredID
::=
CHOICE {
[0]
IMPLICIT OtherName,
[1]
IMPLICIT IA5String,
[2]
IMPLICIT IA5String,
[3]
IMPLICIT ORAddress,
[4]
EXPLICIT Name,
[5]
IMPLICIT EDIPartyName,
[6]
IMPLICIT IA5String,
[7]
IMPLICIT OCTET STRING,
[8]
IMPLICIT OBJECT IDENTIFIER }
OtherName
type-id
Value
:: =
SEQUENCE {
OBJECT IDENTIFIER
[0] EXPLICIT ANY DEFINED type-id }
ORAddress
:: =
built-in-standard-attributes
built-in-domain-defined-attributes
extension-attributes
SEQUENCE {
ANY,
SEQUENCE OF ANY OPTIONAL,
SET OF ANY OPTIONAL }
EDIPartyName
:: = SEQUENCE {
nameAssigner [0] EXPLICIT DirectoryString OPTIONAL,
partyName [1] EXPLICIT DirectoryString }
-- subject directory attributes extension
SubjectDirectoryAttributs
::=
Attributes
Title
::=
DateOfBirth
::=
GeneralizedTime
PlaceOfBirth
::=
Seite 130 von 162
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
::=
keyIdentifier
authorityCertIssuer
authorityCertSerialNumber
KeyIdentifier
::=
SEQUENCE {
[0] IMPLICT KeyIdentifier
OPTIONAL,
[1] IMPLICIT GeneralNames OPTIONAL,
[2] IMPLICIT
CertificateSerialNumber OPTIONAL}
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
exponent
::=
Iso4217CurrencyCode
::=
alphabetic
numeric
-- ETSI QC statement on retention period
QcRetentionPeriod
::=
SEQUENCE {
Iso4217CurrencyCode,
INTEGER,
INTEGER }
CHOICE {
PrintableString,
INTEGER(1..999) }
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 }
Seite 131 von 162
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 }
-- Common PKI 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
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 }
ValidityModel
validityModelId
validityModelInfo
RestrictionSyntax
::= SEQUENCE {
OBJECT IDENTIFIER
ANY DEFINED BY validityModelID OPTIONAL }
AdditionalInformationSyntax ::= DirectoryString (SIZE(1..2048))
END
B.6 Object Identifier, die in dieser Spezifikation verwendet werden
Die nachfolgende Tabelle zeigt die relevanten Object Identifier.
Seite 132 von 162
Tabelle 232 – (N2627.00) Ü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 Zertifikatserweiterungen
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 HPC-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, 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 Zertifikatserweiterungen
id-pe-qcStatements
{ id-pe 3 }
gibt an, dass das Zertifikat ein qualifiziertes 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 }
Staatsangehörigkeit des Karteninhabers
id-pda-countryOfResidence
{ id-pda 5 }
Land, in dem der Karteninhaber wohnt
id-commonpki
{ 1 3 36 8 }
Zweig für Common PKI
id-qcs
{ id-pkix 11 }
Zweig für QC statements
id-qcs-pkixQCSyntax-v1
{ id-qcs 1 }
RFC3039 QC statement
id-commonpki-at
{ id-commonpki 3 }
Zweig für Common PKI-Attribute und -Erweiterungen
id-commonpki-at-admission
{ id-commonpki-at 3 }
bezeichnet berufliche Zulassungsinformationen
id-commonpki-at-restriction
bezeichnet andere (nicht-monetäre) Beschränkungen der
Zertifikatsnutzung
id-commonpki-atnamingAuthorities
Zweig für namensgebende Organisationen für Berufe
id-commonpki-at-nameAtBirth
Geburtsname
id-commonpki-atadditionalInformation
bezeichnet nicht-beschränkende Informationen zur
Zertifikatsnutzung
id-commonpki-cp
{ id-commonpki 1 }
Zweig für Common PKI Zertifikats-Policies
id-commonpki-cp-accredited
{ id-commonpki-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 BNetzA, um Gültigkeitsmodelle
anzuzeigen
Seite 133 von 162
Object Identifier
Bedeutung
Name
Wert
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
B.7 Attributzertifikat für elektronische Signaturen (X.509v3 Zertifikat)
Attributzertifikate 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 Attributzertifikate in einem bestimmten Kontext nutzen will,
müssen die Attributzertifikate am Ende des Dokumentes angefügt und mit signiert werden. Zurzeit
werden ausschließlich v1-Attributzertifikate gemäß Common PKI v1.1-Spezifikation verwendet.
Allgemeine Definition eines Attributzertifikates:
AttributeCertificate
acinfo
signatureAlgorithm
signature
::=
SEQUENCE {
AttributeCertificateInfo,
BIT STRING }
TBSAttributeCertificate
version
subject
baseCertificateID
subjectName
issuer
signature
serialNumber
attrCertValidityPeriod
attributes
issuerUniqueID
extensions
::=
SEQUENCE {
Version
DEFAULT v1,
CHOICE {
[0]
IssuerSerial,
[1]
GeneralNames },
GeneralNames,
AttCertValidityPeriod,
SEQUENCE OF Attribute,
UniqueIdentifier OPTIONAL,
Extensions OPTIONAL }
Attribute
type
Values
::=
SEQUENCE {
AttributeType,
SET OF AttributeValue }
Die issuerUniqueID darf nicht verwendet werden. Der Bezug zum Basis-QES-Zertifikat, zu dem das
Attributzertifikat gehört, wird durch Angabe des Herausgebers und der Seriennummer des QES-BasisZertifikats hergestellt.
IssuerSerial
issuer
serial
issuerUID
::=
SEQUENCE {
GeneralNames,
UniqueIdentifier OPTIONAL }
Seite 134 von 162
AttCertValidityPeriod
notBeforeTime
notAfterTime
::=
SEQUENCE {
GeneralizedTime,
GeneralizedTime }
Die issuerUID darf nicht verwendet werden. Berufsspezifische Zulassungen können in einem Attributzertifikat durch Nutzung des Attributs admission des Typs AdmissionSyntax wie in [COM-PKI-9]
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 B.2.9.12.
Im Folgenden sind die Anforderungen für die Nutzung des Attributs admission in Attributzertifikaten
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 Attributzertifikaten dieselbe Struktur aufweisen und das
Attribut admission vom ASN.1-Typ AdmissionSyntax nutzen. Attributzertifikate müssen die folgenden
Erweiterungen mit zum zugehörenden Basiszertifikat passenden Werten enthalten: AuthorityKeyIdentifier, CertificatePolicies, CRLDistributionPoints, AuthorityInfoAccess und QCStatements.
Die Vorgaben für die Nutzung und den Inhalt von Attributzertifikaten und die möglichen Kategorien der
berufsspezifischen Zulassungen werden im Detail in gesonderten Dokumenten beschrieben. Die beiden folgenden Unterkapitel beschreiben beispielhafte Implementierungen..
B.7.1 Attributzertifikat für Qualifikationen
Das Attributzertifikat für Qualifikationen enthält die folgenden Informationen:
-
Beruf
Spezialisierungsart und
konkrete Spezialisierung
Für jede Spezialisierungsart kann ein gesondertes Attributzertifikat herausgegeben werden. Die
Organisation, die diese Qualifikationen bestätigt, ist die zugehörende Kammer.
B.7.2 Attributzertifikate für Autorisierungen
Die Attributzertifikate für Autorisierungen enthalten u.a. die folgenden Informationen:
-
die generelle Autorisierung
den Typ der Autorisierung und
die konkrete Autorisierung
Für jede Autorisierungsart kann ein gesondertes Attributzertifikat herausgegeben werden.
Die Organisation, die diese Autorisierungen bestätigt, ist die zugehörende Standesorgansiation.
Es folgt ein Beispiel für ein Attributzertifikat für Autorisierungen.
{ admissionAuthority "KASSENAERZTLICHE VEREINIGUNG BAYERNS",
contentsOfAdmissions {
{ professionInfos {
{ namingAuthority {
namingAuthorityId id-OIDForKBV,
Seite 135 von 162
namingAuthorityUrl "UrlToGeneralAuthorization" },
professionItems { "Vertragsarzt" } },
{ namingAuthority {
namingAuthorityId id-OIDFor,
namingAuthorityUrl "UrlToAuthorizationType" },
professionItems { "VF" } },
{ namingAuthority {
namingAuthorityId id-OIDForBAEK,
namingAuthorityUrl "UrlToDedicatedAuthorization" },
professionItems { "Sonographie" } } } } }
B. 8 Zertifizierungsinstanzen für X.509-Zertifikate
Die Sicherheitsanforderungen an die HPC erfordern unterschiedliche Typen von X.509-Nutzerzertifikaten:
-
QES-Zertifikat (X.509-Zertifikat für eine qualifizierte elektronische Signatur) und bis zu 3 Attributzertifikate,
-
AUT-Zertifikat (X.509-Authentifizierungszertifikat) und
-
ENC-Zertifikat (X.509-Verschlüsselungszertifikat).
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 Nutzerzertifikaten für qualifizierte elektronische Signaturen verwendet werden. Die CA der Heilberufler erstellt auch die X.509-AUT- und X.509-ENC-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-Sector
Wurzel-CA
- Prk.CA.CS_QES
von der BNA zertifiziert
zum Signieren C.HP.QES
und zugehörigen ACs
- Prk.CA.CS_AUT & ENC
von der Wurzel-CA des
HP-Sektors zertifiziert
zum Signieren von
C.HP.AUT und
AC
C.HP.ENC
CA
Gesundheitswesen
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
= Attributzertifikat
= Authentisierung
= Bundesnetzagentur
= Zertifikat
= Zertifizierungsinstanz
= CertSign
= Verschlüsselung
= Qualifizierte Elektronische Signatur
Abbildung 11 – (N2628.00) X.509-Certificates und Zertifizierungsinstanzen
Anmerkung – Die Funktion einer CA des Gesundheitswesens kann von mehreren Organisationen (akkreditierte
ZDAs) übernommen werden.
Seite 136 von 162
Annex C (normativ)
Zertifikate für Authentifizierung und
Verschlüsselung
C.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.
C.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 webbasierte
Client-Authentifizierungen mit dem TLS-Protokoll durchführen zu können, kann optional auch
das "key encipherment"-Bit im AUT-Zertifikat gesetzt werden (in Übereinstimmung mit dem
Common PKI-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 webbasierte Client-Authentifizierungen mit dem TSL-Protokoll durchführen zu können, kann die
nicht-kritische Erweiterung extendedKeyUsage optional in das AUT-Zertifikat eingefügt werden
(entsprechend Common PKI 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
::=
::=
SEQUENCE SIZE (1..MAX) OF KeyPurposeId
OBJECT IDENTIFIER
Seite 137 von 162
Annex D (informativ)
Kryptografische Informationsobjekte der
QES-Anwendung
Dieser Anhang zeigt ein detailliertes Beispiel für die kryptografischen Informationsobjekte (CIO), die
zum DF.CIA.QES einer HPC gehören.
D.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 Nutzerauthentifizierung erfordern) und “prnGeneration” (Die Karte hat
die Fähigkeit, Pseudozufallszahlen zu erzeugen).
D.1.1 ASN.1 value notation
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
ciaInfo CIAInfo ::= {
version v2,
label “Qualified Signature Application”,
cardflags { authRequired, prnGeneration }
seInfo {
SecurityEnvironmentInfo {
se 1,
aid 'D27600006601’ H
}
SecurityEnvironmentInfo {
se 2,
aid 'D27600006601’ H
}
},
supportedAlgorithms {
-- Hash algorithm: SHA-256
algorithmInfo {
reference 1, -- unique reference for cross-referencing
algorithm 592, -- PKCS#11 mechanism type CKM_SHA256 = 0x250
parameters NULL: NULL, -- type of parameters is NULL and value is NULL
supportedOperations {hash},
objId {2 16 840 1 101 3 4 2 1},-- SHA-256
-- no algRef as no HASH command is used
},
-- Signature algorithm
-- RSA with DSI according to PKCS#1 V.1.5 and SHA-256
algorithmInfo {
algorithm 64, -- PKCS#11 mechanism type CKM_SHA256_RSA_PKCS = 0x40
supportedOperations {compute-signature},
objId {1 2 840 113549 1 1 11},-- SHA256 and RSA with DSI according to PKCS#1
algRef 2 -- is equivalent to 0x02, see [HPC-P1], Table (N1218.00)
},
-- RSA with DSI according to PKCS#1 PSS and SHA-256
Seite 138 von 162
26
27
28
29
30
31
32
algorithmInfo {
algorithm 67, -- PKCS#11 mechanism type CKM_SHA256_RSA_PKCS_PSS = 0x43
objId {1 2 840 113549 1 1 11},-- SHA256 and RSA with DSI according to PKCS#1
},
-- RSA with DSI according to ISO/IEC 9796-2 DS2 (randomized) and SHA-256
algorithmInfo {
algorithm 2147483649, -- algorithm not defined in PKCS#11,
-- vendor defined 0x80000001
objId {1 3 36 3 4 3 2 4}, -- 2B240304030204
-- SHA-256 and RSA with DSI according to ISO/IEC 9796-2 with random number
},
-- Device Authentisierung algorithm
algorithmInfo {
supportedOperations {compute-signature, verify-signature},
objId {1 3 36 3 5 2 4}, -- Authentication scheme with RSA signature and DSI
-- according to ISO/IEC 9796-2 and SHA-256 for mutual authentication with or
-- without establishment of a Trusted Channel, see [HPC-P1], Table (N48.50) and
Table (N1216.00)
},
-- Card Verifiable (CV) Ceritificate signature verification
algorithmInfo {
supportedOperations {verify-signature},
objId {1 3 36 3 4 3 2 4}, -- 2B240304030204
-- SHA-256 and RSA with DSI according to ISO/IEC 9796-2 with random number
-- algRef is not used (key and algorithm are selected by the Certification
-- Authority Reference CAR provided in the Card Verifiable CV certificate)
}
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
}
}
D.1.2 ASN.1 Description, tags, lengths and values
1 CIAInfo SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 227
2 version INTEGER: tag = [UNIVERSAL 2] primitive; length = 1
1
3 label Label UTF8String: tag = [0] primitive; length = 31
0x5175616C6966696564205369676E6174757265204170706C69636174696F6E
4 cardflags CardFlags BIT STRING: tag = [UNIVERSAL 3] primitive; length = 2
0x0560
5
6
7
8
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 = 6
0xD27600006601
Seite 139 von 162
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
37
38
39
40
41
SecurityEnvironmentInfo SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 11
0x02
0xD27600006601
supportedAlgorithms SEQUENCE OF: tag [UNIVERSAL 16] constructed; length = 156
algorithmInfo SEQUENCE: tag [UNIVERSAL 16] constructed; length = 24
reference Reference INTEGER: tag [UNIVERSAL 2] primitive; length = 1
0x01
algorithm Identifier OCTET STRING: tag = [UNIVERSAL 4] primitive; length = 2
0x0250
parameter NULL: tag [UNIVERSAL 5] primitive; length = 0
supportedOperations Operations BIT STRING: tag [UNIVERSAL 3] primitive; length = 2
0x0102
objId OBJECTIDENTIFIER: tag [UNIVERSAL 6] primitive; length = 9
0x608648016503040201
0x02
0x40
0x0604
0x60864883770D
algRef Reference INTEGER: tag [UNIVERSAL 2] primitive; length = 1
0x02
0x03
0x43
0x0604
0x60864883770D
0x05
0x04
0x80000001
0x0604
0x2B240304030204
0x07
0x03
Seite 140 von 162
42
43
44
45
46
47
48
49
50
51
0x80000002
0x0405
0x2B2403050204
0x04
0x80000003
0x0401
0x2B240304020203
D.1.3 Hexadecimal DER-encoding
1 30 81 E3
2
02 01
01
3
80 1F
51 75 61 6C 69 66 69 65 64 20 53 69 67 6E 61 74 75 72 65 20 41 70 70 6C 69 63 61 74 69 6F 6E
4
03 02
05 60
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
30 1A
30 0B
02 01
01
04 06
D2 76 00 00 66 01
30 0B
02 01
02
04 06
D2 76 00 00 66 01
30 81 9C
30 18
02 01
01
04 02
02 50
05 00
03 02
01 02
06 09
60 86 48 01 65 03 04 02 01
30 17
02 01
02
04 01
40
05 00
03 02
06 04
06 06
60 86 48 83 77 0D
02 01
02
30 17
Seite 141 von 162
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
D.2
02 01
03
04 01
43
05 00
03 02
06 04
06 06
60 86 48 83 77 0D
02 01
05
30 1B
02 01
04
04 04
80 00 00 01
05 00
03 02
06 04
06 07
2B 24 03 04 03 02 04
02 01
07
30 17
02 01
05
04 04
80 00 00 02
05 00
03 02
04 05
06 06
2B 24 03 05 02 04
30 18
02 01
06
04 04
80 00 00 03
05 00
03 02
04 01
06 07
2B 24 03 04 02 02 03
EF.OD
Das EF "Object Directory" enthält die Information, welche CIO-EFs vorhanden sind und wie sie durch
SFID referenziert werden.
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
}
Seite 142 von 162
1 CIOChoice CHOICE
authObjects : tag = [8] constructed; length = 5
2
AuthObjects CHOICE
path Path SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 3
3
efidOrPath OCTET STRING: tag = [UNIVERSAL 4] primitive; length = 1
0x14
4 CIOChoice CHOICE
privateKeys : tag = [0] constructed; length = 5
5
PrivateKeys CHOICE
6
0x15
7 CIOChoice CHOICE
certificates : tag = [4] constructed; length = 5
8
Certificates CHOICE
9
0x16
1 A8 05
2
30 03
3
04 01
14
4 A0 05
5
30 03
6
04 01
15
7 A4 05
8
30 03
9
04 01
16
D.3
EF.AOD
Das EF “Authentication Object Directory” enthält die Information über die PIN.QES.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
pwd : {
commonObjectAttributes {
label "PIN.QES",
flags { private },
authId '13'H,
accessControlRules {
accessControlRule {
accessMode { execute },
securityCondition authReference: {
authMethod {secureMessaging, extAuthentication},
seIdentifier 2
}
}
}
},
classAttributes {
authId '03'H
},
typeAttributes {
Seite 143 von 162
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
passwordAttributes {
pwdFlags { local, initialized, exchangeRefData },
pwdType iso9564-1,
minLength 6,
storedLength 0,
maxLength 8,
pwdReference ‘81’H
-- P2 Value of the VERIFY command
path {
efidOrPath ‘3F0004’H
-- Qualified path: Last Byte = P1 of SELECT with DF name
}
}
}
},
pwd : {
label "PUK.QES",
flags { private },
accessControlRule {
securityCondition authReference: {
authMethod {secureMessaging, extAuthentication},
seIdentifier 2
}
}
}
},
classAttributes {
authId '13'H
},
typeAttributes {
passwordAttributes {
pwdFlags { local, change-disabled, unblock-disabled, initialized,
unblockingPassword },
pwdType iso9564-1,
minLength 8,
storedLength 8,
maxLength 8,
pwdReference ‘81’H
-- P2 Value of the RESET RETRY COUNTER command
path {
efidOrPath ‘3F0004’H
-- Qualified path: Last Byte = P1 of SELECT with DF name
}
}
}
}
1 AuthenticationObjectChoice CHOICE
pwd SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 47
2
commonObjectAttributes CommonObjectAttributes SEQUENCE: tag = [UNIVERSAL 16]
constructed; length = 16
3
label Label UTF8String: tag = [UNIVERSAL 12] primitive; length = 7
0x50494E2E514553
4
flags CnovellommonObjectFlags BIT STRING: tag = [UNIVERSAL 3] primitive; length = 2
0x0780
5
authId Identifier OCTET STRING: tag = [UNIVERSAL 4] primitive; length = 1
0x13
6
accessControlRules SEQUENCE OF: tag = [UNIVERSAL 16] constructed; length = 15
7
acessControlRule SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 13
8
accessMode BIT STRING: tag = [UNIVERSAL 3] primitive; length = 2
0x0520
Seite 144 von 162
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
37
38
39
40
41
42
securityCondition CHOICE
authReference SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 7
authMethod BIT STRING: tag = [UNIVERSAL 3] primitive; length = 2
0x06C0
seIdentifier INTEGER: tag = [UNIVERSAL 2] primitive; length = 1
2
classAttributes CommonAuthenticationObjectAttributes SEQUENCE:
tag = [UNIVERSAL 16] constructed; length = 3
0x03
typeAttributes : tag = [1] constructed; length = 22
PasswordAttributes SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 20
pwdFlags PasswordFlags BIT STRING; length = 3
0x044810
pwdType PasswordType ENUMERATED: tag = [UNIVERSAL 10] primitive; length = 1
4
minLength INTEGER: tag = [UNIVERSAL 2] primitive; length = 1
6
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
0x81
path SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 5
efidOrPath OCTED STRING: tag = [UNIVERSAL 4]; length = 3
0x3F0004
AuthenticationObjectChoice CHOICE
0x50554B2E514553
flags CommonObjectFlags BIT STRING: tag = [UNIVERSAL 3] primitive; length=2
0x0780
acessControlRule SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 13
0x0520
0x06C0
seIdentifier INTEGER: tag = [UNIVERSAL 2] primitive; length = 1
2
0x13
pwdFlags PasswordFlags BIT STRING: tag = [UNIVERSAL 3] primitive; length = 2
0x017A
pwdType PasswordType ENUMERATED: tag = [UNIVERSAL 10] primitive; length=1
4
8
8
Seite 145 von 162
43
44
45
8
0x81
path SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 5
efidOrPath OCTED STRING: tag = [UNIVERSAL 4]; length = 3
0x3F0004
1 30 2F
2
30 10
3
0C 07
50 49 4E 2E 51 45 53
4
03 02
07 80
5
04 01
13
6
30 0F
7
30 0D
8
03 02
05 20
9
30 07
10
03 02
06 C0
11
02 01
02
12
30 03
13
04 01
03
14
A1 1E
15
30 1B
16
03 03
04 48 10
17
0A 01
04
18
02 01
06
19
02 01
00
20
02 01
08
21
80 01
81
22
30 05
23
04 03
3F 00 04
24 30 2B
25
30 0D
26
0C 07
50 55 4B 2E 51 45 53
27
03 02
07 80
28
30 0F
29
30 0D
30
03 02
05 20
31
30 07
32
03 02
06 C0
33
02 01
02
34
30 03
35
04 01
12
36
A1 15
37
30 13
38
03 02
01 7A
39
0A 01
04
Seite 146 von 162
40
41
42
43
44
45
D.4
02 01
08
02 01
08
02 01
08
80 01
81
30 05
04 03
3F 00 04
EF.PrKD
Das EF “Private Key Directory” enthält die notwendigen Informationen über den privaten Schlüssel
PrK.HP.QES.
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
privateRSAKey : {
label "PrK.HP.QES",
flags { private },
authId '03'H
-- pointer to the AOD-entry of PIN.QES
accessControlRule {
securityCondition or: {
securityCondition {
authId : '03'H, -- pointer to the AOD-entry of PIN.QES
authReference : {
authMethod { userAuthentication }
seIdentifier 1 }
}
}
securityCondition {
authId : '03'H, -- pointer to the AOD-entry of PIN.QES
authReference : {
authMethod { secureMessaging,
extAuthentication, userAuthentication }
seIdentifier 2 }
}
}
}
}
}
},
classAttributes {
iD '84'H,
-- cross-reference to the CD-entry of C.HP.QES
usage { sign, signRecover, nonRepudiation },
keyReference ’84’H
-- used in MSE-SET command
},
typeAttributes {
privateRSAKeyAttributes {
Value { efidOrPath ''H },
modulusLength 2048
}
}
}
Seite 147 von 162
1 PrivateKeyChoice CHOICE
privateRSAKey SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 64
2
3
0x50724B2E48502E514553
4
flags CommonObjectFlags BIT STRING: tag = [UNIVERSAL 3] primitive; length = 2
0x0780
5
0x03
6
7
accessControlRule SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 30
8
0x0520
9
or SEQUENCE OF: tag = [2] constructed; length = 24
securityCondition SecurityCondition CHOICE
10
0x03
11
12
0x0520
13
seIdentifier INTEGER: tag = {UNIVERSAL 2] primitive; length = 1
0x01
14
0x03
15
16
0x0520
17
seIdentifier INTEGER: tag = {UNIVERSAL 2] primitive; length = 1
0x02
18
classAttributes CommonKeyAttributes SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 10
19
iD Identifier OCTET STRING: tag = [UNIVERSAL 4] primitive; length = 1
0x84
20
usage KeyUsageFlags BIT STRING: tag = [UNIVERSAL 3] primitive; length = 2
0x0520
21
keyReference KeyReference INTEGER: tag = [UNIVERSAL 2] primitive; length = 1
0x84
22
23
PrivateRSAKeyAttributes SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 8
24
Value Path SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 2
25
modulusLength INTEGER: tag = [UNIVERSAL 2] primitive; length = 2
2048
1 30 40
2
30 26
3
0C 0A
50 72 4B 2E 48 50 2E 51 45 53
4
03 02
07 80
5
04 01
03
6
30 20
7
30 1E
8
03 02
05 20
Seite 148 von 162
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
D.5
A2 18
04 01
03
30 07
03 02
05 20
02 01
01
04 01
03
30 07
03 02
05 20
02 01
02
30 0A
04 01
84
03 02
05 20
02 01
84
A1 0A
30 08
30 02
04 00
02 02
08 00
EF.CD
Das EF “Certificate Directory” enthält die File-Referenzen zu den X.509-Zertifikaten C.HP.QES,
C.HP.QES-AC1, C.HP.QES-AC2, und C.HP.QES-AC3.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
x509Certificate : {
label "C.HP.QES",
flags { private }
},
classAttributes {
iD '84'H
-- cross-reference to the PrKD-entry of PrK.HP.QES
},
typeAttributes {
value indirect :
path : {
efidOrPath '10'H --SFID of C.HP.QES
}
}
},
x509Certificate : {
label "C.HP.QES-AC1",
flags { private }
},
classAttributes {
iD '84'H
},
typeAttributes {
value indirect :
path : {
efidOrPath '01'H --SFID of C.HP.QES-AC1
}
}
},
Seite 149 von 162
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
x509Certificate : {
flags { private }
},
classAttributes {
iD '84'H
},
typeAttributes {
value indirect :
path : {
efidOrPath '02'H --SFID of C.HP. QES-AC2
}
}
},
x509Certificate : {
flags { private }
},
classAttributes {
iD '84'H
},
typeAttributes {
value indirect :
path : {
efidOrPath '03'H --SFID of C.HP. QES-AC3
}
}
}
1 CertificateChoice CHOICE
x509Certificate SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 30
2
3
0x432E48502E514553
4
0x0780
5
classAttributes CommonCertificateAttributes SEQUENCE: tag = [UNIVERSAL 16]
6
0x84
7
X509CertificateAttributes SEQUENCE: tag = [UNIVERSAL 16] constructed;
length = 5
8
value CHOICE
indirect Referencedvalue CHOICE
9
0x10
11
12
0x432E48502E5145532D414331
13
0x0780
Seite 150 von 162
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
0x84
length = 5
value CHOICE
0x01
CertificateChoice CHOICE
0x432E48502E5145532D414332
0x0780
0x84
length = 5
value CHOICE
0x02
0x432E48502E5145532D414333
0x0780
0x84
length = 5
value CHOICE
0x03
1 30 1E
2
30 0E
3
0C 08
43 2E 48 50 2E 51 45 53
4
03 02
Seite 151 von 162
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
07 80
30 03
04 01
84
A1 07
30 05
30 03
04 01
10
30 22
30 12
0C 0C
43 2E 48 50 2E 51 45 53 2D 41 43 31
03 02
07 80
30 03
04 01
84
A1 07
30 05
30 03
04 01
01
30 22
30 12
0C 0C
43 2E 48 50 2E 51 45 53 2D 41 43 32
03 02
07 80
30 03
04 01
84
A1 07
30 05
30 03
04 01
02
30 22
30 12
0C 0C
43 2E 48 50 2E 51 45 53 2D 41 43 33
03 02
07 80
30 03
04 01
84
A1 07
30 05
30 03
04 01
03
Seite 152 von 162
Annex E (informativ)
Kryptographische Informationsobjekte der
ESIGN-Anwendung
Dieser Anhang zeigt ein detailliertes Beispiel für die kryptografischen Informationsobjekte (CIO), die
zum DF.CIA.ESIGN einer HPC gehören.
E.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 Nutzerauthentifizierung erfordern) und “prnGeneration” (Die Karte
hat die Fähigkeit, Pseudozufallszahlen zu erzeugen).
E.1.1 ASN.1 value notation
1
2
3
4
5
7
8
9
10
ciaInfoExample CIAInfo ::= {
version v2,
label “ESIGN Application”,
cardflags { authRequired, prnGeneration }
seInfo {
{
se 1,
aid 'A000000167 455349474E’ H
},
{
se 2,
aid 'A000000167 455349474E’ H
}
}
E.1.2 ASN.1 Description, tags, lengths and values
1 CIAInfo SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 45
2 version INTEGER: tag = [UNIVERSAL 2] primitive; length = 1
1
3 label Label UTF8String: tag = [0] primitive; length = 17
0x455349474E204170706C69636174696F6E
4 cardflags CardFlags BIT STRING: tag = [UNIVERSAL 3] primitive; length = 2
0x0560
5 seInfo SEQUENCE OF: tag = [UNIVERSAL 16] constructed; length = 17
6
SecurityEnvironmentInfo SEQUENCE: tag = [UNIVERSAL 16] constructed;
length = 15
7
0x01
8
0xA000000167455349474E
9
0x02
Seite 153 von 162
10
0xA000000167455349474E
E.1.3 Hexadecimal DER-encoding
1 30 3E
2
02 01
01
3
80 11
45 53 49 47 4E 20 41 70 70 6C 69 63 61 74 69 6F 6E
4
03 02
05 60
5
30 22
6
30 0F
7
02 01
01
8
04 0A
A0 00 00 01 67 45 53 49 47 4E
30 0F
9
02 01
02
10
04 0A
A0 00 00 01 67 45 53 49 47 4E
E.2
EF.OD
Das EF "Object Directory" enthält die Information, welche CIO-EFs vorhanden sind und wie sie durch
SFID referenziert werden.
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 CIOChoice CHOICE
authObjects : tag = [8] constructed; length = 5
2
AuthObjects CHOICE
3
0x14
4 CIOChoice CHOICE
privateKeys : tag = [0] constructed; length = 5
5
PrivateKeys CHOICE
6
0x15
7 CIOChoice CHOICE
certificates : tag = [4] constructed; length = 5
8
Certificates CHOICE
Seite 154 von 162
9
0x16
1 A8 05
2
30 03
3
04 01
14
4 A0 05
5
30 03
6
04 01
15
7 A4 05
8
30 03
9
04 01
16
E.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
24
25
26
27
pwd : {
label "PIN.CH",
flags { private },
authId '12'H
},
classAttributes {
authId '02'H
},
typeAttributes {
pwdFlags { initialized, exchangeRefData },
pwdType iso9564-1,
minLength 5,
storedLength 0,
maxLength 8,
pwdReference 1
-- P2 Value of the VERIFY command
}
},
pwd : {
label "PUK.CH",
flags { private }
},
classAttributes {
authId '12'H
},
typeAttributes {
pwdFlags { global, change-disabled, unblock-disabled, initialized, unblockingPassword },
pwdType iso9564-1,
minLength 8,
storedLength 8,
maxLength 8,
pwdReference 1
-- P2 Value of the RESET RETRY COUNTER command
}
}
Seite 155 von 162
2
3
0x50494E2E4348
4
0x0780
5
0x12
6
7
0x02
8
9
pwdFlags PasswordFlags BIT STRING: tag = [UNIVERSAL 3] primitive;
length = 3
0x040810
10
4
11
5
12
0
13
8
14
0x01
16
17
0x50554B2E4348
18
0x0780
19
20
0x12
21
22
pwdFlags PasswordFlags BIT STRING: tag = [UNIVERSAL 3] primitive;
length = 2
0x013A
23
4
24
8
25
8
26
8
27
0x01
Seite 156 von 162
1 30 2E
2
30 0F
3
0C 06
50 49 4E 2E 43 48
4
03 02
07 80
5
04 01
12
6
30 03
7
04 01
02
8
A1 16
30 14
9
03 03
04 08 10
10
0A 01
04
11
02 01
05
12
02 01
00
13
02 01
08
14
80 01
01
15 30 2A
16
30 0C
17
0C 06
50 55 4B 2E 43 48
18
03 02
07 80
19
30 03
20
04 01
12
21
A1 15
30 13
22
03 02
01 3A
23
0A 01
04
24
02 01
08
25
02 01
08
26
02 01
08
27
80 01
01
E.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.
1
2
3
4
5
6
privateRSAKey : {
label "PrK.HP.AUT",
flags { private },
authId '02'H
-- pointer to the AOD-entry of PIN.CH
Seite 157 von 162
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
37
38
{
securityCondition and : {
authId : '02'H, -- pointer to the AOD-entry of PIN.CH
authReference : {
}
}
}
}
}
},
classAttributes {
iD '82'H,
-- cross-reference to the CD-entry of C.HP.AUT
usage { signRecover },
keyReference –130
},
typeAttributes {
value {
efidOrPath ''H
},
modulusLength 1728
}
},
privateRSAKey : {
label "PrK.HP.ENC",
flags { private },
authId '02'H
-- pointer to the AOD-entry of PIN.CH
{
securityCondition and : {
authId : '02'H, -- pointer to the AOD-entry of PIN.CH
authReference : {
}
}
}
}
}
},
classAttributes {
iD '83'H,
-- in this specification unused (but mandatory)
usage { keyDecipher },
keyReference –131
},
typeAttributes {
value {
efidOrPath ''H
},
modulusLength 1728
}
}
E.4.2 ASN.1 Description, tags, lengths and value
2
3
0x50724B2E48502E415554
4
flags CommonObjectFlags BIT STRING: tag = [UNIVERSAL 3] primitive;
Seite 158 von 162
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
length = 2
0x0780
0x02
AccessControlRule SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 15
0x0520
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
0x82
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
1728
21
22
0x50724B2E48502E4B45
23
flags CommonObjectFlags BIT STRING: tag = [UNIVERSAL 3] primitive;
length = 2
0x0780
24
0x02
25
26
AccessControlRule SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 15
27
0x0520
28
and SEQUENCE OF: tag = [1] constructed; length = 9
29
authId Identifier OCTET STRING: tag = [UNIVERSAL 4] primitive;
length = 1
0x02
30
authReference AuthReference SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 4
31
authMethod AuthMethod BIT STRING: tag = [UNIVERSAL 3] primitive;
length = 2
0x0520
Seite 159 von 162
32
33
34
35
36
37
38
0x83
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
1728
1 30 40
2
30 26
3
0C 0A
50 72 4B 2E 48 50 2E 41 55 54
4
03 02
07 80
5
04 01
02
6
30 11
7
30 0F
8
03 02
05 20
9
A1 09
10
04 01
02
11
30 04
12
03 02
05 20
13
30 0A
14
04 01
82
15
03 02
04 10
16
02 01
82
17
A1 0A
30 08
18
30 02
04 00
19
02 02
06 C0
20 30 3F
21
30 25
22
0C 09
50 72 4B 2E 48 50 2E 4B 45
23
03 02
07 80
24
04 01
02
25
30 11
26
30 0F
27
03 02
05 20
28
A1 09
29
04 01
02
30
30 04
31
03 02
Seite 160 von 162
05 20
32
33
34
35
36
37
38
E.5
30 0A
04 01
83
03 02
02 04
02 01
83
A1 0A
30 08
30 02
04 00
02 02
06 C0
EF.CD
Das EF “Certificate Directory” enthält die File-Referenzen zu den X.509-Zertifikaten C.HP.AUT und
C.HP.ENC.
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
}
}
2
3
0x432E48502E415554
4
0x0780
5
Seite 161 von 162
6
7
8
9
10
11
12
13
14
15
16
17
18
0x82
length = 5
value CHOICE
0x01
0x432E48502E415554
0x0780
0x83
length = 5
value CHOICE
0x02
1 30 1E
2
30 0E
3
0C 08
43 2E 48 50 2E 41 55 54
4
03 02
07 80
5
30 03
6
04 01
82
7
A1 07
30 05
8
30 03
9
04 01
01
10 30 1E
11
30 0E
12
0C 08
43 2E 48 50 2E 41 55 54
13
03 02
07 80
14
30 03
15
04 01
83
16
A1 07
30 05
17
30 03
18
04 01
02
Seite 162 von 162

Health Professional Card

Transcription

Documents pareils

NATO HPC - MEN Metallwerk Elisenhütte GmbH

Halsketten-Dog Collars-Colliers

Argon AM 2015

Kurzanleitung zur Internet-Banking-Anmeldung mit dem VR

Schaltplan Sitzheizung BMW E30 - E30

ESPAÑAMUNDO LOTERIA PRIMITIVA S.A.

Effiziente numerische Simulation

CRYPTOCard SC-1 Smartcard incl. USB Reader oder PCMCIA

Product Specification Sheet

IDC- Flach- und Rundkabelkonfektionen IDC