SIST EN 419212-5:2018

SLOVENSKI STANDARD
01-julij-2018
1DGRPHãþD
SIST EN 419212-1:2015
SIST EN 419212-2:2015
Uporabniški vmesnik za varnostne elemente za elektronsko identifikacijo,
avtentikacijo in zanesljivost storitev - 5. del: Zaupnost e-storitev
Application Interface for Secure Elements for Electronic Identification, Authentication and
Trusted Services - Part 5: Trusted eService
Anwendungsschnittstelle für sichere Elemente, die als qualifizierte elektronische Signatur
-/Siegelerstellungseinheiten verwendet werden - Teil 5: Vertrauenswürdige elektronische
Dienste
Interface applicative des éléments sécurités pour les services électroniques
d'identification, d'authentification et de confiance - Partie 5 : Services électroniques de
confiance
Ta slovenski standard je istoveten z: EN 419212-5:2018
ICS:
35.240.15 ,GHQWLILNDFLMVNHNDUWLFHýLSQH Identification cards. Chip
NDUWLFH%LRPHWULMD cards. Biometrics
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 419212-5
EUROPEAN STANDARD
NORME EUROPÉENNE
April 2018
EUROPÄISCHE NORM
ICS 35.240.15 Supersedes EN 419212-1:2014, EN 419212-2:2014
English Version
Application Interface for Secure Elements for Electronic
Identification, Authentication and Trusted Services - Part
5: Trusted eService
Interface applicative des éléments sécurités pour les Anwendungsschnittstelle für sichere Elemente zur
services électroniques d'identification, elektronischen Identifikation, Authentisierung und für
d'authentification et de confiance - Partie 5 : Services vertrauenswürdige Dienste - Teil 5:
électroniques de confiance Vertrauenswürdige elektronische Dienste
This European Standard was approved by CEN on 6 February 2017.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2018 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 419212-5:2018 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Abbreviations and notation. 6
5 Additional Service Selection. 6
6 Client/Server Authentication . 10
6.1 General . 10
6.2 Client/Server protocols . 10
6.3 Steps preceding the client/server authentication . 11
6.4 Padding format . 11
6.4.1 PKCS #1 v 1-5 Padding . 11
6.4.2 PKCS #1 V 2.x (PSS) Padding . 12
6.4.3 Building the DSI on ECDSA . 13
6.5 Client/Server protocol . 13
6.5.1 General . 13
6.5.2 Step 1 — Read certificate . 14
6.5.3 Step 2 — Set signing key for client/server internal authentication . 15
6.5.4 Step 3 — Internal authentication . 16
6.5.5 Client/Server authentication execution flow . 18
6.5.6 Command data field for the client server authentication . 19
7 Role Authentication . 20
7.1 Role Authentication of the card . 20
7.2 Role Authentication of the server . 20
7.3 Symmetrical external authentication . 20
7.3.1 Protocol . 20
7.3.2 Description of the cryptographic mechanisms . 24
7.3.3 Role description . 25
7.4 Asymmetric external authentication . 25
7.4.1 Protocol based on RSA . 25
8 Symmetric key transmission between a remote server and the ICC . 28
8.1 Steps preceding the key transport . 28
8.2 Key encryption with RSA . 28
8.2.1 General . 28
8.2.2 PKCS#1 v1.5 padding . 30
8.2.3 OAEP padding . 30
8.2.4 Execution flow . 31
8.3 Diffie-Hellman key exchange for key encipherment . 33
8.3.1 General . 33
8.3.2 Execution flow . 35
9 Signature verification . 37
9.1 General . 37
9.2 Signature verification execution flow . 37
9.2.1 General . 37
9.2.2 Step 1: Receive Hash . 37
9.2.3 Step 2: Select verification key . 39
9.2.4 Step 3: Verify digital signature . 39
10 Certificates for additional services . 40
10.1 File structure . 40
10.2 File structure . 41
10.3 EF.C_X509.CH.DS . 41
10.4 EF.C.CH.AUT . 41
10.5 EF.C.CH.KE. 42
10.6 Reading Certificates and the public key of CAs . 42
11 APDU data structures . 42
11.1 Algorithm Identifiers . 42
11.2 General . 42
11.3 CRTs . 43
11.3.1 General . 43
11.3.2 CRT DST for selection of ICC’s private client/server auth. key . 43
11.3.3 CRT AT for selection of ICC’s private client/server auth. key . 43
11.3.4 CRT CT for selection of ICC’s private key . 44
11.3.5 CRT DST for selection of IFD’s public key (signature verification) . 44
Annex A (informative)  Security Service Descriptor Templates . 45
Annex B (informative)  Example of DF.CIA . 51
Bibliography . 58

European foreword
This document (EN 419212-5:2018) has been prepared by Technical Committee CEN/TC 224 “Personal
identification and related personal devices with secure element, systems, operations and privacy in a
multi sectorial environment”, the secretariat of which is held by AFNOR.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by October 2018, and conflicting national standards shall
be withdrawn at the latest by October 2018.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document supersedes EN 419212-1:2014 and EN 419212-2:2014.
This standard supports services in the context of electronic IDentification, Authentication and Trust
Services (eIDAS) including signatures.
In EN 419212 Part 2, the standard allows support of implementations of the European legal framework
for electronic signatures, defining the functional and security features for a Secure Elements (SE) (e.g.
smart cards) intended to be used as a Qualified electronic Signature Creation Device (QSCD) according
to the Terms of the “European Regulation on Electronic Identification and Trust Services for electronic
transactions in the internal market” [22].
A Secure Element (SE) compliant to the standard will be able to produce a “qualified electronic
signature” that fulfils the requirements of Article of the Electronic Signature Regulation ” [22] and
therefore can be considered equivalent to a hand-written signature.
This standard consists of five parts:
Part 1: “Introduction and common definitions” describes the history, application context, market
perspective and a tutorial about the basic understanding of electronic signatures. It also provides
common terms and references valid for the entire 419212 series.
Part 2: “Signature and Seal Services” describes the specifications for signature generation according to
the eIDAS regulation.
Part 3: “Device Authentication” describes the device authentication protocols and the related key
management services to establish a secure channel.
Part 4: “Privacy specific Protocols” describes functions and services to provide privacy to identification
services.
Part 5: “Trusted eServices” describes services that may be used in conjunction with signature services
described in Part 2.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.
Introduction
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent
rights of which they are aware and to provide supporting documentation.
The European Committee for Standardization (CEN) draws attention to the fact that it is claimed that
compliance with this document may involve the use of a patent concerning the mapping function given
in EN 419212-2:2017 8.2.
The patent relates to “Sagem, MorphoMapping Patents FR09-54043 and FR09-54053, 2009”.
CEN takes no position concerning the evidence, validity and scope of this patent right.
The holder of this patent right has ensured CEN that he/she is willing to negotiate licences under
reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this
respect, the statement of the holder of this patent right is registered with CEN. Information may be
obtained from:
Morpho
11, boulevard Galliéni
92445 Issy-les-Moulineaux Cedex
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights other than those identified above. CEN shall not be held responsible for identifying any or
all such patent rights.
1 Scope
Part 5 of this series contains Identification, Authentication and Digital Signature (IAS) services in
addition to the QSCD mechanisms already described in Part 2 to enable interoperability and usage for
IAS services on a national or European level.
It also specifies additional mechanisms like key decipherment, Client Server authentication, identity
management and privacy related services.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 7816-4:2013, Identification cards — Integrated circuit cards — Part 4: Organization, security
and commands for interchange
ISO/IEC 7816-8:2016, Integrated circuit(s) cards with contacts — Part 8: Commands for security
operations
ISO/IEC 9796-2:2010, Information technology — Security techniques — Digital signature schemes giving
message recovery — Part 2: Integer factorization based mechanisms
PKCS #1 v2.1:2002, RSA Cryptography Standard, RSA Laboratories
3 Terms and definitions
For the purposes of this document, the terms and definitions apply as described in EN 419212-1.
4 Abbreviations and notation
For the purposes of this document, the symbols and abbreviations apply as described in EN 419212-1.
5 Additional Service Selection
Additional services are typically used in the context of applications that use digital signatures.
A well-known additional service is the client/server authentication. In this case, the ICC is used as a
crypto toolbox, e.g. in order to encrypt a challenge with a private key, being stored in the ICC. This is
particularly helpful in applications, where a tamper resistant device is required for client/server
authentication. A secure ICC has the necessary tamper resistant quality and may therefore be used
efficiently to support the application in this context.
Document decryption is another known service which may be performed by the IFD. A terminal
application receives a document, typically encrypted with a symmetric key. The symmetric key is also
provided encrypted with a public key. The ICC contains the appropriate private key, deciphers the
symmetric key and returns it to the terminal application.
While the typical usage of a signature card is the generation of a digital signature, an application might
want to verify a signature with a public key, being stored in the ICC. In this case an additional service is
invoked for signature verification.

Available at www.rsasecurity.com/rsalabs/pkcs/pkcs-1/ http://www.rsa.com/rsalabs/node.asp?id=2125
ICCs used as national identification cards, travel documents or driving licences generally provide
additional applications to enable eServices (e.g. eGovernment, eBusiness, …) including an ESIGN
application. In the eID card context new privacy issues are to be put into account, e.g. user tracking, data
minimizing, unlinkability of transactions or domain specific identifiers. This standard specifies privacy
preserving protocols and mechanisms as additional services.
Additional services provided in the ICC mandate the existence of an appropriate security environment.
Associated security environments are described in EN 419212-2:2017, Annex A.
In addition to the descriptive information found in DF.CIA (refer to EN 419212-2, clause 14)
information might be required that can be presented in Security Service Descriptors. The concept of
Security Service Descriptors is described in the Annex A.
A user verification may be required prior to the usage of additional services. The password for this user
verification shall be different from the password used for the signature generation. This is to maintain
the purpose of the signature generation password for the sole purpose of a ‘declaration of will’ in the
case of a signature generation.
Figure 1 shows an execution flow for an additional service. The corresponding technical
implementation is given in this document.
Figure 1 — Interaction sequences between application and QSCD
As the standard specifies various mechanisms for device and user authentication with a number of
resulting combinations, Figure 2 shows execution flows for typical signature cards in different security
and privacy context.
Figure 2 — Example of additional service selection
Figure 2 shows the selection of additional services in the context of the ESIGN application. User
verification might be required for some of the additional services. The detailed access conditions are
described in the appropriate security environments.
For security reasons the cryptographic information objects shall not reveal any information which
could be used to associated the ICC to the password. If this cannot be guaranteed, the device
authentication shall be done prior to reading the cryptographic information objects to avoid that an
unauthorized IFD may later reuse that association for further attacks.
Alternatively other measures shall be taken to avoid such an attack. For contactless case in untrusted
environment, two choices are possible.
• Either the reading of CIA file (refer to 14) and the selection of application are done before device
authentication, in conformity with Figure 1
• or the device authentication is done first.
PKCS#15 takes into account privacy preserving measures involving EF.DIR so that to meet data
minimizing property requirements (new component enhanced CIODDO under EF.DIR ensures that the
IFD can access DF.CIA content only once security protocols i.e. PACE are fulfilled).
This prevents the leakage of user information from CIA file and preserves privacy.
6 Client/Server Authentication
6.1 General
For proving access rights to components such as servers, a PK based authentication procedure has to be
performed. Such client/server Authentication (refer to “C/S internal authentication”) is a process,
independent from the requirement of device authentication.

Figure 3 — Example of client/server authentication
In the above example client/server authentication establishes a secured channel between a remote
server and a PC. The ICC will be used as a cryptographic toolbox in order to provide the cryptographic
functionality to the PC.
This specification does not support the authentication of the server (“C/S external authentication”). The
server’s certificate as well as the server protocol is application specific and therefore out of the scope of
this document.
6.2 Client/Server protocols
This specification only covers the case, where the ICC performs a digital signature computation on the
authentication input contained in the data field of an INTERNAL AUTHENTICATE (COMPUTE DIGITAL
SIGNATURE) command. The input is formatted before the private key for authentication is used to form
the signature.
The key pair used for client/server authentication shall be different from the device authentication keys
and signature generation keys respectively. The public part of this key pair, stored with the
distinguished name of the cardholder, is certified by a certificate (typically X.509 [8]). Such a certificate
is not interpreted by the ICC.
Relevant authentication procedures are e.g.:
— the PK Kerberos protocol (for logon authentication)
— the SSL/TLS protocol
— the SSH protocol
All the above protocols are based on the same cryptographic algorithms. In particular they all use PKCS
#1 padding format in the case of RSA. This specification describes the PKCS #1 padding and C/S
authentication based on ECDSA.
6.3 Steps preceding the client/server authentication
The steps preceding a client/server authentication are application specific. Hence this specification
does not mandate the existence of those steps.
The access conditions proposed in EN 419212-2:2017 Annex A specify a user verification as a
mandatory step prior to client/server authentication.
The reference to the password to be used for user verification in the context of client/server
authentication is described in the information of DF.CIA.
6.4 Padding format
6.4.1 PKCS #1 v 1-5 Padding
The DSI generation according to PKCS #1 v1.5 uses the padding scheme defined for the EMSA-PKCS-
v1_5 encoding defined in PKCS #1 Section 9.2 (starting with step 3 of the encoding method). The
padding is applied directly to the Authentication Input T.
Figure 4 shows an example for DSI generation according to PKCS #1 V1.5. In case of RSA, the
authentication input T is formatted according to PKCS #1, Version 2.1, Chapter 9.2 “EMSA-PKCS1-v1-5”.
For particular Authentication input T refer to 6.4.5.

Figure 4 — Example for 2048 bit DSI according to PKCS #1 V1.5
The padding is realized through an octet string consisting of octets with value ‘FF’ (length ≥ 8). Due to
security reasons the authentication input shall be smaller or equal to 33 % of the length of the modulus.
The formatted octet string shall consist of k octets where k is the length in octets of the modulus of the
private key for authentication.
The digest info is described in EN 419212-2:2017, clause 12.3.3.
6.4.2 PKCS #1 V 2.x (PSS) Padding
The DSI generation according to PKCS1-PSS uses the padding scheme defined for the EMSA-PSS
encoding defined in PKCS #1 V 2.1, section 9.1. There are two modes of operation, each indicated by a
separate set of algorithm IDs see EN 419212-1:2017, Table A.17.
The DSI format according to PKCS #1 V 2.1 has the following structure. The message M represents the
authentication input T.
Figure 5 — Example for 2048 bit DSI according to PKCS #1 V2.1
Figure 5 shows an example for the DSI computation according to PKCS #1 V2.1. Building the first hash
in the IFD is an optional step and appropriate, if the message M is large and the transmission of this
large message M would require exhaustive data transmission to the ICC.
The hashing function used in MGF1 is the same as the one used to hash the authentication input. The [8
x Key.ModulusByteLength — (Key.ModulusBitLength — 1)] leftmost bits of the output of the MGF1
function are set to zero to provide a DSI input being arithmetically smaller than the modulus N. The
MGF1 function is described in PKCS #1 V2.1.
Figure 6 — Example for the mask generating function MGF1
Figure 6 shows an example for the mask generating function MGF1. The length of the salt is identical to
the Digest Length H of the hash algorithm. The length of DB computes from
Length(DB) = N – H – 1 = maskLen.
where N is the byte length of the modulus and H is the digest length of the hash algorithm.
The length of the mfgSeed is identical to H, the length of C is 4 bytes as specified in PKCS #1 V 2 . The
initial value of C is zero. The concatenation of [mfgSeed || C] pairs is right truncated at the length of
maskLen to build dbmask.
The [8 x Key.ModulusByteLength - (Key.ModulusBitLength - 1)] leftmost bits of dbmask are set to zero
to provide a DSI input being arithmetically smaller than the modulus N.
The hashing function used in MGF1 is the same as the one used to hash the authentication input. The [8
x Key.ModulusByteLength — (Key.ModulusBitLength — 1)] leftmost bits of the output of the MGF1
function are set to zero to provide a DSI input being arithmetically smaller than the modulus N.
Table 1 — Digital Signature Input (DSI) — Format acc. to PKCS #1 V 2.x
T L V
masked DB = DB ⊕ MGF1(Hash(M’), Key.ByteLength — H — 1)
— — Hash(M’)
‘BC’ = Padding according to ISO/IEC 9796-2 (option 1)
6.4.3 Building the DSI on ECDSA
No hash shall be internally computed by the ICC. The size of the DSI shall not be greater than the size of
the order of the base point (this point is relevant in particular for elliptic curves whose prime length is
not a multiple of eight bits – e.g. P-521).
6.5 Client/Server protocol
6.5.1 General
Table 2 shows the execution flow of the RSA client/server authentication. This specification covers only
the internal authentication.
Table 2 — Client/Server authentication flow
Transmis
Stage Step IFD ICC
sion
... preceding steps(e.g. user
→
verification) that are application
1 — application specific protocol flow
specific for client/server
←
authentication
INTERNAL AUTHENTICATION — server (IFD) authenticates client (ICC)
→
READ BINARY
1 certificate
of certificate (typically X.509)
←
→
2 MSE:SET PrK.CH.AUT
←
INTERNAL AUTHENTICATE
→
3 or
←
COMPUTE DIGITAL SIGNATURE
Client (ICC) is authenticated to server (IFD)
... subsequent steps that are
→
3 — application specific to present not specified in this document
←
client/server authentication
6.5.2 Step 1 — Read certificate
If the IFD does not already have the client's (ICC) authentication certificate, it may read it from a global
data file EF.C.CH.AUT. The client’s certificate C.CH.AUT may contain public algorithm quantities which
depend on the client/server authentication algorithm.
Execution Flow
Table 3 — Read EF.C.CH.AUT — command APDU
Command
Meaning
Parameter
CLA according to ISO/IEC 7816-4
INS ‘B0’ READ BINARY
P1 ‘85’ Example: SFI = 05
P2 ‘00’ offset = 0
Le field ‘00’
For the structure and content of the APDU refer to ISO/IEC 7816-4:2013, 11.2.3.
The structure and coding of C.CA .CS_AUT may be as described in section [NP3#5.13log], but it could
ICC
also be some other certificate format unknown to the ESIGN application. The actual format is
application specific and out of the scope of this standard.
Table 4 — Read EF.C.CH.AUT — response
Response
Meaning
Parameter
Data field EF.C.CH.AUT plain data as stored in EF
SW1-SW2 Refer to ISO/IEC 7816-4
Unless the READ BINARY selects the file using a short EF Identifier (SFI), an appropriate SELECT(EF)
command shall be executed prior to reading the file.
6.5.3 Step 2 — Set signing key for client/server internal authentication
The MSE command sets the keyID of the ICC’s client/server private authentication key to be used for
the following computation of the digital signature.
Execution Flow
Table 5 — Select key reference for internal authentication - command APDU
Command
Meaning
Parameter
CLA according to ISO/IEC 7816-4
INS ‘22’ MANAGE SECURITY ENVIRONMENT
P1 ‘41’ SET for internal authentication
P2 ‘A4’
Lc field ‘xx’
Data field CRT data field with AlgID (PrK.CH.AUT) and KeyRef(PrK.CH.AUT)
For the structure and content of the APDU refer to ISO/IEC 7816-4:2013, 11.5.11.
The structure and coding of the key reference data are specified in 11.2.2.
In order to avoid ambiguity the hashing function MGF1 shall be indicated in the AlgID.
The response data field is empty.
Table 6 — Select key reference for internal authentication — response
Response
Meaning
Parameter
Data field empty
SW1-SW2 Refer to ISO/IEC 7816-4
Alternatively, the COMPUTE DIGITAL SIGNATURE command can be used.
Alternative Execution Flow
Table 7 — Select key reference for internal authentication — command APDU
Command
Meaning
Parameter
CLA according to ISO/IEC 7816-4
INS ‘22’ MANAGE SECURITY ENVIRONMENT
P1 ‘41’ SET for internal authentication
P2 ‘B6’ digital signature DST
Lc field ‘xx’
Data field CRT data field with AlgID (PrK.CH.AUT) and KeyRef(PrK.CH.AUT)
For the structure and content of the APDU refer to ISO/IEC 7816-4:2013, 11.5.11.
The structure and coding of the key reference data are specified in 11.3.2.
The response data field is empty.
Table 8 — Select key reference for internal authentication — response
Response
Meaning
Parameter
Data field empty
SW1-SW2 Refer to ISO/IEC 7816-4
6.5.4 Step 3 — Internal authentication
The IFD sends a challenge in the data field of the INTERNAL AUTHENTICATE command. The ICC
computes a signature over the challenge by using its private key, that was selected in the preceding
step.
Execution Flow
Table 9 — INTERNAL AUTHENTICATE — command APDU
Command
Meaning
Parameter
CLA according to ISO/IEC 7816-4
INS ‘88’ INTERNAL AUTHENTICATE
P1 ‘00’ no algorithm information
P2 ‘00’ key reference — none
Lc field ‘xx’
Data field data authentication input see below (Table 13 to Table 17)
Le field ‘00’
For the structure and content of the APDU refer to ISO/IEC 7816-4:2013, 11.5.2.
The digital signature input format is described in 6.4.5 .
The algorithms usable for client server authentication are described in 11.2.
The response data contains the signature.
Table 10 — INTERNAL AUTHENTICATE — response
Response
Meaning
Parameter
a
RSA: SIG = DS [PrK.CH.AUT](DSI) where DSI is formed according 6.4.
Data field
ECDSA: For the ECDSA algorithm the signature format is described in EN 419212-
2:2017, clause 12.3.6
SW1-SW2 Refer to ISO/IEC 7816-4
a
DS is to be understood as plain RSA exponentiation. It does not imply a layer of input formatting other than
already specified here.
Alternatively, the COMPUTE DIGITAL SIGNATURE command can be used.
Alternative Execution Flow
Table 11 — COMPUTE DIGITAL SIGNATURE- command APDU
Command
Meaning
Parameter
CLA according to ISO/IEC 7816-4
INS ‘2A’ PERFORM SECURITY OPERATION
P1 ‘9E’ expected response DO
P2 ‘9A’ data to be signed
Lc field ‘xx’
Data field data authentication input T see below
Le field ‘00’
For the structure and content of the APDU refer to ISO/IEC 7816-8:2016, 5.2.
The digital signature input format is described in 6.4.5.
The algorithms usable for client server authentication are described in 11.2.
The response data contains the signature.
Table 12 — COMPUTE DIGITAL SIGNATURE — response
Response
Meaning
Parameter
a
RSA: SIG = DS [PrK.CH.AUT](DSI) where DSI is formed according to 6.4.
Data field
ECDSA: For the ECDSA algorithm the signature format is described in in
EN 419212-2:2017, clause 12.3.6
SW1-SW2 Refer to ISO/IEC 7816-4
a
DS is to be understood as plain RSA exponentiation. It does not imply a layer of input formatting other than
already specified here.
In case of RSA, while the IFD sends only the authentication input T, the ICC performs the padding as
described in Figure 4. In the following text it is not necessary to distinguish between these alternatives.
6.5.5 Client/Server authentication execution flow
The ICC generates a signature over the input data, which shall be presented in the response data. For
RSA the plain signature to be presented is the exponentiation result in the same size as the modulus.

Figure 7 — Comparison of operations in the ICC for signature creation versus C/S auth.
(informative)
Figure 7 compares the signature generation process with a Client/Server (C/S) authentication. On
Client/Server authentication the following rules shall apply:
— The selection of a security environment is mandatory if the COMPUTE DIGITAL SIGNATURE
command is used for signature generation and client/server authentication. Using different
commands avoids ambiguity when using COMPUTE DIGITAL SIGNATURE, hence a selection of a
security environment is not necessary.
— For C/S authentication the authentication input is generated by the PC and sent to the ICC. The ICC
computes the digital signature. If padding is involved at least part of the padding needs to be done
in the ICC in order to avoid existing attacks on the keys.
— The digest info is included in the data field of the COMPUTE DIGITAL SIGNATURE command. This
mechanism is different from the computation of a digital signature as described in EN 419212-
2:2017, 7.3.
— If user verification is required, it shall be performed with password references different for the
signature generation [local password] and for C/S authentication [global password].
6.5.6 Command data field for the client server authentication
6.5.6.1 RSA
Table 13 — Command data field for KERBEROS protocol
T L V Bytes
— — DigestInfo acc. to [2]
Table 14 — Command data field for SSL3.0 [10], TLS1.0 [3] and TLS 1.1 [4]
T L V Bytes
— — H_MD5 || H_SHA1 refer to [6] and [7]
Table 15 — Command data field for SSH
T L V Bytes
— — T = H_SHA1 refer to [9]
Table 16 — Command data field for TLS 1.2
T L V Bytes
— — DigestInfo acc. to [5]
The ICC shall perform the padding according to 6.4. The authentication input is taken as described by
the three tables above.
6.5.6.2 ECDSA
For ECDSA the authentication input is padded with leading zero bits. The build scheme for the signature
is described in 6.4.3.
6.5.6.3 Other algorithms
All other algorithms use the padded (PKCS #1) authentication input in the data field.
Table 17 — Input to other algorithms
T L V Bytes
— — authentication input
7 Role Authentication
7.1 Role Authentication of the card
This feature is optional.
The C/S authentication is based on an Internal Authentication protocol whereby the server (IFD)
authenticates the card (ICC). For this purpose, the IFD reads the card’s certificate (usually a X.509
certificate) that may provide extension (acc. X.509) denoting the role with which the cardholder is
endowed to access some reserved data hosted on the server. The differential access to these data are
controlled by the server according to the rules defined by the certificate extensions. This role
authentication of the card is application-specific and not described further in this document.
7.2 Role Authentication of the server
Asymmetric role authentication applying Elliptic Curve Cryptography and Diffie Hellman key exchange
are already specified in part 3 of this standard, i.e. device authentication with privacy EN 419212-
3:2017, 3.5 and mEAC protocol EN 419212-3:2017, 3.6.
With the successful execution and establishment of a secure messaging channel the protocols provide
role authentication as an integral part of the import of CV certificates. Role identifier values and access
conditions are coded in the CHA (EN 419212-3:2017, 5.7.4) or CHAT object (EN 419212-3:2017, 5.7.6).
As a consequence role authentication is an optional feature in these cases.
This clause describes the procedure to authenticate an external entity to the card. The authentication
associates a specific role (e.g. access rights) to the entity. This clause supports these two mechanisms:
— A symmetric role authentication (external authentication).
— An asymmetric role authentication.
The following procedure describes:
— The cryptographic operation that supports the authentication.
— The specification of the associated role in the card.
7.3 Symmetrical external authentication
7.3.1 Protocol
NOTE The authentication procedure is based on a symmetric key set using TDES or AES.
7.3.1.1 Keys definition
The authentication procedure involves a symmetric key set.
In case the TDES scheme is used, the key set is made of two TDES EDE2 keys:
— KS.KENC: for confidentiality — 16 bytes long.
— KS.KMAC: for integrity (MAC) — 16 bytes long.
In case AES scheme with CMAC is used, the key set is made of two AES keys:
— KS.KENC: for confidentiality — 16, 24 or 32 bytes long.
— KS.KMAC: for integrity (MAC) — 16, 24 or 32 bytes long.
In case AES scheme with EMAC is used, the key set is made of three AES keys:
— KS.KENC: for confidentiality — 16, 24 or 32 bytes long.
— KS.KMAC1: for integrity (MAC) — 16, 24 or 32 bytes long.
— KS.KMAC2: for integrity (MAC) — 16, 24 or 32 bytes long.
For the AES key sets, all keys in a set shall be of same length (16, 24 or 32 bytes).
7.3.1.2 Naming rules
ENC Encryption with TDES or AES in CBC mode and initial vector IV = ‘00 … 00’ using
KS.KENC.
AlgoMAC Integrity Cryptogram (MAC) with KS.KMAC.
SN.ICC:8 ICC serial number, 8 least significant bytes
RND.ICC Random number (of length equal to the block size) generated by the ICC and used to
authenticate the external entity.
At the end of this sequence of commands the IFD is authenticated.
Table 18 — Symmetric external authentication
Transmis
Step IFD ICC
sion
Return SN.ICC
→
1 READ BINARY (EF.SN) Card Serial Number in the context of
←
the current application
Key and algorithm selection (unless
→
2 MSE: Set AT implicitly known or specified in step
←
4)
→
3 GET CHALLENGE Return random number RND.ICC
←
MAC checking
→
4 EXTERNAL AUTHENTICATE Decipher
←
Verify RND.ICC (IFD is authenticated)
7.3.1.3 Step 1 — Read key exchange parameters
The IFD requires the ICC’s serial number in order to derive the appropriate keys.
Execution Flow
Table 19 — Read EF.SN.ICC parameters — command APDU
Command
...