CEN/TS 15480-2:2007

SLOVENSKI STANDARD
01-februar-2009
6LVWHPL]LGHQWLILNDFLMVNLPLNDUWLFDPL.DUWLFDHYURSVNLKGUåDYOMDQRYGHO
/RJLþQHVWUXNWXUHSRGDWNRYLQVWRULWYHY]YH]LVNDUWLFR
Identification card systems - European Citizen Card - Part 2: Logical data structures and
card services
Identifikationskartensysteme - Europäische Bürgerkarte - Teil 2: Logische
Datenstrukturen und Kartendienste
Systèmes des cartes d'identification - Carte Européenne du Citoyen - Partie 2:
Structures logiques des données et services cartes
Ta slovenski standard je istoveten z: CEN/TS 15480-2:2007
ICS:
35.240.15 Identifikacijske kartice in Identification cards and
sorodne naprave related devices
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION
CEN/TS 15480-2
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
April 2007
ICS 35.240.15
English Version
Identification card systems - European Citizen Card - Part 2:
Logical data structures and card services
Systèmes des cartes d'identification - Carte Européenne du Identifikationskartensysteme - Europäische Bürgerkarte -
Citoyen - Partie 2: Structures logiques des données et Teil 2: Logische Datenstrukturen und Kartendienste
services cartes
This Technical Specification (CEN/TS) was approved by CEN on 17 July 2006 for provisional application.
The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their
comments, particularly on the question whether the CEN/TS can be converted into a European Standard.
CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available
promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS)
until the final decision about the possible conversion of the CEN/TS into an EN is reached.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Cyprus, Czech Republic, Denmark, Estonia, Finland,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal,
Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36  B-1050 Brussels
© 2007 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 15480-2:2007: E
worldwide for CEN national Members.

Contents Page
Foreword.4
1 Scope .5
2 Normative references .5
3 Terms and definitions .6
4 Abbreviations.6
4.1 Abbreviations.6
4.2 Coding conventions and notation.8
5 Data elements and data structures.10
5.1 Supported data Structures .10
5.2 Access to data structures.10
5.3 Answer to reset (ATR) / answer to select (ATS) .11
5.4 General architecture and file supported .13
5.5 Selection of data structures .14
5.6 Access to files.14
6 Basic card services .16
6.1 General.16
6.2 Identification.16
6.3 User verification.17
6.4 Device authentication.18
6.5 Digital signature.21
6.6 Client/server authentication .24
6.7 Encryption key decipherment .24
7 Extended card services.24
7.1 General.24
7.2 Biometrics – on card matching .24
7.3 Passive authentication.25
7.4 Basic access control .25
7.5 Active authentication .25
7.6 Extended access control .25
7.7 Role authentication.25
Annex A (normative) Command set.27
A.1 CLASS byte coding.27
A.2 Command chaining mechanisms.27
A.3 Retrieval of response data longer than 256 bytes.28
A.4 Logical channels.28
A.5 Short and extended length fields.29
A.6 Status words .29
A.7 Command set .30
Annex B (normative) Card Verifiable Certificates .47
B.1 Introduction.47
B.2 Use of the public key extracted from the certificate .47
B.3 Validity of the key extracted from a certificate .47
B.4 Structure of CVC.47
B.5 Steps of CVC verification.48
B.6 Commands to handle the CVC .48
Annex C (normative) Cryptographic Information Application .49
C.1 Description .49
C.2 CIA data organisation.57
Annex D (normative) Mandatory and optional features .76
D.1 General .76
D.2 Data elements and data structures.76
D.3 Card services .77
D.4 Command set.78
D.5 Algorithms.79
Annex E (normative) Key and signature formats for elliptic curves over prime fields GF(p) .80
Annex F (informative) Access rules in expanded format.81
F.1 Object protection by access rules in expanded format .81
F.2 Access rules in expanded format .81
F.3 Security attribute referencing expanded format .82
F.4 Security attribute template for physical interfaces.83
Annex G (informative) Example of data structure: the Security Data Objects concept .84
G.1 SDO concept .84
Annex H (informative) Extended access control for MRTDs .98
H.1 General .98
H.2 Extended access control protocol.98
H.3 CV certificates for EAC .103
Bibliography.105

Foreword
This document (CEN/TS 15480-2:2007) has been prepared by Technical Committee CEN/TC 224 “Personal
identification, electronic signature and cards and their related systems and operations”, the secretariat of
which is held by AFNOR.
CEN/TS 15480, Identification card systems — European Citizen Card consist of the two following parts:
Part 1: Physical, electrical and transport protocol characteristics
Part 2: Logical data structures and card services
Part 3: ECC Interoperability using an application interface
Part 4: Recommendations for ECC issuance, operation and use
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this CEN Technical Specification: Austria, Belgium, Bulgaria, Cyprus, Czech
Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain,
Sweden, Switzerland and United Kingdom.

1 Scope
This Technical Specification specifies the logical characteristics and security features at the card/system
interface for the European Citizen Card.
The European Citizen Card is a smart card with Identification, Authentication and electronic Signature (IAS)
services. Therefore:
 the supported services are specified;
 the supported data structures as well as the access to these structures are specified;
 the command set is defined.
This Technical Specification has the objective of ensuring the interoperability at card/system interface in the
usage phase.
In order to reach the interoperability objective, IAS services are compliant to prEN 14890 part 1 and part 2. As
the CWA documents offer options, this specification fully defines a complete profile. This specification also
provides other features not defined in the CWA documents (biometric on card matching, command chaining,
role authentication …).
This Technical Specification is also compliant with ICAO specification (authentication methods, basic access
control …).
This Technical Specification does not mandate the use of a particular technology, and is intended to allow
both native and Java card technologies.
This specification encompasses mandatory and optional features. Optional features make up a toolbox of
modular options from which issuers can pick up the necessary protocols to fulfil the requisites of their use
cases. Mandatory features are necessarily to be implemented for a smart card to be compliant to this
Technical Specification. Two IAS-enabled smart cards issued by two different issuers, and compliant with this
Technical Specification but implementing different modular options out of this Technical Specification, can
interoperate with a terminal provided such a terminal supports both options. Therefore, interoperability
requires a specific agreement between issuers/governments in order to determine which cross-border
services are to be shared, and consequently which protocols are to be supported by the terminals in each
country.
All the APDU commands described in this Technical Specification are in accordance with ISO/IEC 7816 part 4
or part 8. They are fully described here in order to provide the settings adopted by this specification and to
prevent any ambiguity in case of several possible interpretations of the standards.
For physical, electrical and transport protocol characteristics, refer to CEN/TS 15480-1.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ANSI X9.63, Public Key Cryptography For the Financial Services Industry: Key Agreement and Key Transport
th
Using Elliptic Curve Cryptography, January 8 1999
prEN 14890-1:2007, Application Interface for smart cards used as Secure Signature Creation Devices —
Part 1: Basic requirements
prEN 14890-2:2007, Application Interface for smart cards used as Secure Signature Creation Devices —
Part 2: Additional Services
ISO/IEC 7816-3, Identification cards — Integrated circuit cards — Part 3: Cards with contacts — Electrical
interface and transmission protocols
ISO/IEC 7816-4:2005, Identification cards — Integrated circuit(s) cards — Part 4: Organization, security and
commands for interchange
ISO/IEC 7816-11, Identification cards — Integrated circuit cards — Part 11: Personal verification through
biometric methods
ISO/IEC 7816-15, Identification cards — Integrated circuit cards with contact — Part 15: Cryptographic
information application
ISO/IEC 9796-2, Information technology — Security techniques — Digital signature schemes giving message
recovery — Part 2: Integer factorisation based mechanisms
ISO/IEC 14443-4, Identification cards — Contactless integrated circuit(s) cards — Proximity cards — Part 4:
Transmission protocol
ISO/IEC 15946-2, Information technology — Security techniques — Cryptographic techniques based on
elliptic curves — Part 2: Digital signatures
ISO/IEC 19794-2, Information technology — Biometric data interchange formats — Part 2: Finger minutiae
data
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
Application Dedicated File (ADF)
ADF is a Dedicated File (DF) with an Application Identifier (AID)
3.2
root
Master File MF in case of a native operating system, the applet instance having the default selection privilege
in case of a Java card implementation
4 Abbreviations
4.1 Abbreviations
ADF Application Dedicated File
AID Application Identifier
AMB Access Mode Byte
AT Authentication Template
ATR Answer to Reset
ATS Answer to Select
BER Basic Encoding Rules
BHT Biometric Header Template
BIT Biometric Information Template
CA Certification Authority
CAR Certification Authority Reference
CCT Cryptographic Checksum Template
CED Certificate Effective Date
CHA Certificate Holder Authorisation
CHR Certificate Holder Reference
CIA Cryptographic Information Application
CPI Certificate Profile Identifier
CRT Control Reference Template
CT Confidentiality Template
CV Card Verifiable
CXD Certificate Expiration Date
DES Data Encryption Standard
DF Dedicated File
DH Diffie Hellman
DOCP Data Object Control Parameters
DST Digital Signature Template
ECDH Elliptic Curve DH
ELC Elliptic Curve Cryptosystem
ECDSA Elliptic Curve Digital Signature Algorithm
EF Elementary File
FCI File Control Information
FCP File Control Parameters
HT Hash Template
IAS Identification, Authentication and electronic Signature
ICC Integrated Circuit Card
IFD Interface Device
KAT Control reference template for key agreement
LSB Least Significant Byte
MAC Message Authentication Code
MF Master File
MSE Manage Security Environment
OID Object Identifier
PAN Primary Account Number
PIN Personal Identification Number
PK – DH Public key – Diffie Hellman (asymmetric key base algorithm)
PSO Perform Security Operation
RFU Reserved for Future Use
RSA Rivest Shamir Adleman
SDO Security Data Object
SCB Security Condition Byte
SE Security Environment
SEID Security Environment IDentifier byte
SM Secure Messaging
TLV Tag Length Value
UQB Usage Qualifier Byte
4.2 Coding conventions and notation
4.2.1 Coding conventions
The following coding conventions apply throughout the Technical Specification:
‘0’ to ‘9’ and ‘A’ to ‘F’ the sixteen hexadecimal digits;
" . " ASCII-string;
B1 || B2 concatenation of bytes B1 (the most significant byte) and B2 (the least significant byte).
4.2.2 Notation
For private and public keys as well as for certificates the following simplified Backus-Naur notation is used:
::= |
::= ..
::= |
::= PrK
::= PuK
::= |
::= CH
::= | |
::= ICC
::= IFD
::= S
::= | | |

::= AUT
::= KA
::= RA
::= KE
::= ..
::= |
::= C_CV
::= C_X509
::= |
EXAMPLES:
1) PrK.ICC.AUT = Private key of the ICC for device authentication;
2) PuK.S.KA = Public key of the sender used for key agreement;
3) C.CH.AUT = Certificate of the card holder for Client Server Authentication.
In addition the following notation is used:
K Random number (32 bytes) of the ICC used for session key derivation
ICC
K Random number (32 bytes) of the IFD used for session key derivation
IFD
K Symmetric Key for encryption used in device and / or role authentication
ENC
K Symmetric Key for MAC calculation used in device and / or role authentication
MAC
K Secure Messaging session key (3DES) for encryption
SK-ENC
K Secure Messaging session key (3DES) for MAC calculation
SK-MAC
RND.ICC Random number (8 byte) of the ICC
RND.IFD Random number (8 byte) of the IFD
SN.ICC Serial number (8 LSB) of the ICC (IFD)
SN.IFD Serial number (8 LSB) of the IFD
5 Data elements and data structures
5.1 Supported data Structures
The European Citizen Card shall support the data structures described in 5.2. These data structures are used
to store external accessed data (certificates, card serial number, .). Exceptions from this rule, i.e. use cases
where data objects are used that can be accessed by a GET DATA command are listed in the description of
the services.
In addition the card may support further data structures including proprietary structures to handle data as long
as these structures have no effect on the services defined in this Technical Specification, i.e. on the
interoperability. E.g. the storage of private and secret keys, the storage of PIN reference data and of security
environments is not defined in this Technical Report. The storage of these entities is out of the scope of this
Technical Specification and implementation specific.
5.2 Access to data structures
5.2.1 File system considerations
The European Citizen Card might embed a virtual machine or be a native operating system.
1) The card may include an MF. The differentiation between cards with or without an MF is based on
the card ATR/ATS. See ISO/IEC 7816-4:2005, 8.1 – card service data byte. Consequently the card
shall include the card service data byte when returning the ATR/ATS.
2) If an application is selected implicitly, i.e., always selected at the card reset, it has the default
selection privilege. The corresponding AID shall be indicated in the historical bytes or the EF.ATR.
3) The root is the MF or the applet instance having the default selection privilege. This depends on the
card manufacturer implementation choice (JavaCard or native implementation).
4) Three basic file types are supported:
i) transparent EF;
ii) dedicated files DF;
iii) application dedicated files ADF, refer to clause for a definition of the term ADF.
5) For card without MF, each applet instance matches with an application DF (ADF).
6) All cards shall be personalized with an EF.DIR file.
i) The EF.DIR is always under the root.
ii) The EF.DIR identifier is: '2F00', the short EF identifier is 30 = '1E' =11110 bin.
5.3 Answer to reset (ATR) / answer to select (ATS)
5.3.1 General
The ATR of the card shall follow the rules indicated in ISO/IEC 7816-3 and ISO/IEC 7816-4. The ATS of the
card shall follow the rules specified in ISO/IEC 14443-4.
Data objects for card identification shall be provided in the historical data bytes of the ATR/ATS or in an
optional EF.ATR. If both ATR/ATS and EF.ATR specify data objects, the data objects from ATR/ATS shall be
present in EF.ATR and optionally more data objects. In case of ISO/IEC 14443-4 and protocol type B no ATS
is available and for this reason the presence of the EF.ATR is mandatory in this case.
Card Identification Data Objects table provides the list of data objects which may be supported by the card.
The data objects are shown for the BER-TLV structure as used in an EF.ATR. For data objects transmitted in
the historical data bytes the compact TLV format as defined in ISO/IEC 7816-4 shall apply.
If a data object format is used in the historical bytes or in EF.ATR the length of the DO shall be used as
defined in the table. Furthermore the definitions for the coding of content of the data objects given in the table
are mandatory. The coding of further parameters in the content of the data objects is left to the choice of the
card manufacturer but shall follow the rules given in ISO/IEC 7816-4.
Table 1 — Card Identification Data Objects
Tag Length What Content Support
'43' '01' Card service Byte 1: Mandatory
data b8=1: Application selection by full DF name
b6=1: BER TLV DO are present in EF.DIR
b4.b2=100: EF.DIR / EF.ATR is a transparent EF
(use READ BINARY)
b1=1: card with MF (i.e. Native card)
b1=0 : card without MF (i.e. Java card)
'46' '04' Pre-issuing Byte 1: Optional
DO IC Manufacturer according ISO/IEC 7816-6

Byte 2:
Type of the IC, defined by the IC or card manufacturer

Byte 3:
Version of the operating system defined by card
manufacturer
Byte 4:
Discretionary data (defined by the card manufacturer)
'47' '03' Card Byte 1 (DF / EF selection): Mandatory
capabilities b8=1: DF selection by full name
b5=1: DF selection using file identifier
b3=1: file selection using short file identifier is supported
Byte 2 (data coding byte):
b4…b1 = 0001: data unit size is 1 byte
Byte 3:
b8=1: command chaining is supported
b5, b4 = 00: No logical channel supported
b5, b4 = 10: channel number assignment by the card
Maximum number of channels supported: 4
'4F' '01'…'10' Application AID of an implicitly selected application Conditional:
Identifier
This DO shall be
present if there is an
implicitly selected
application
Four data objects with tag .02. (universal class). The
'E0' variable IO buffer size Conditional:
value field of each DO encodes the maximum number
This DO shall be
of bytes of the respective APDU.
present if the ECC
.02. . L . .xx .xx. || .02. . L . .xx .xx. || .02. . L . .xx
.xx. || .02. . L . .xx .xx. = platform supports
extended length fields
DO maximum length of command APDU without
secure messaging ||
DO maximum length of command APDU with secure
messaging ||
DO maximum length of response APDU without
secure messaging ||
DO maximum length of response APDU with secure
messaging.
5.3.2 Historical bytes
The category indicator as the first historical byte shall be set to the value '00'. Therefore the last three bytes
shall be a status indicator, i.e. a card life cycle status indicator followed by two status bytes SW1-SW2.
Transmission in historical bytes for the data objects "card service data" and "card capabilities" is mandatory.
For other data objects the decision is left to the card manufacturer.
5.3.3 EF.ATR
The usage of an EF.ATR is optional. The support of an EF.ATR shall be indicated in the "card service data
byte" of the historical bytes. With regard to ISO/IEC 14443-4, the ATS Application information bytes are not
normalized for data objects interoperable description. Therefore, for both contact and contact-less cards,
EF.ATR may host information.
For data objects stored in the EF.ATR the BER-TLV format is mandatory.
5.4 General architecture and file supported
Figure 1 —shows an example of directory and elementary file organization.

Figure 1 — Directory architecture example
The card supports the following type of files:
 the root is unique and identifies the default selected directory after reset;
 DF files that are attached to the root or to another DF;
 one or more ADFs each representing an application that may include dedicated files;
 transparent EF files.
An ADF may be stored under another ADF. Due to the fact that an ADF is always selected by its AID, this is
not visible by the outside world.
For interoperability purpose, the European Citizen Card shall support at least one level of DF and ADF under
the root and one level of DF under any ADF.
5.5 Selection of data structures
5.5.1 Selection of an application
After reset and return of the ATR/ATS, the root is automatically selected (refer to clause for definition of the
root).
The terminal may select the EF.DIR, which is a mandatory EF, always present under the root. The EF.DIR is
always selected by FID (‘2F00’) or addressed by its short EF identifier ‘1E’ = 30.
The EF.DIR contains the list of the AID of the applications (ADF) present on the smart card.
ADF selection is always performed by name. An ADF may support the selection by more than one AID (e.g. a
national and an international AID) in order to support interoperability.
In case of a card without MF (typically a Java card implementation), the SELECT by AID of an application
shall be issued by the terminal always in clear, even if a secure messaging session is currently active. For
such cards this SELECT by AID in clear shall not break the current secure messaging session (if any). For
such cards this behaviour is necessary in order to allow the association of one applet instance to one
application in a Java card.
5.5.2 Selection of files
File selection is always relative to the ADF. The EF selection can be performed either:
 explicitely by the SELECT command using FID over two bytes, or
 implicitely by addressing the file content using short EF identifier.
All files, except ADF or root (when card without MF), may be selected by file ID (2 bytes-long). An elementary
file may also be selected implicitly by an access with short EF identifier.
5.6 Access to files
5.6.1 File control parameter
The File Control Parameter (FCP) referenced by tag '62' provides the logical, structural and security attributes
of a file (EF or DF or ADF). Table 2 — File Control Parameter defines the subset of ISO/IEC 7816-4 to be
supported at least by the ICC. The FCP is returned by a SELECT command if the corresponding command
parameter is set, see Annex A. The European Citizen Card may return additional data objects in the FCP (i.e.
data objects with other tags). Those data objects are to be ignored by the IFD in the context of ECC usage.
The ICC may also support File Control Information (FCI) and File Management Data (FMD) that may contain
proprietary data not relevant with respect to interoperability. For this reason the FCI as well as the FMD are
out of the scope of the present specification.
Table 2 — File Control Parameter
Tag Length Description
'62' Var. File Control Parameter (FCP)
Tag Length Description Applies to
'80' '02' Number of data bytes in the file excluding structural Transparent EFs
information
'82' '01' File descriptor byte (data coding byte) DFs, ADFs,
transparent EFs
‘83’ ‘02’ File Identifier coded on two bytes DFs, transparent
a
EFs
'84' '01' to '10' DF name (AID) ADFs
'88' '01' Short EF identifier (optional) EFs
'8A' '01' Life cycle status byte Any file
'A1' variable Security attribute template for physical Any file
b
interfaces
a
An ADF shall be selected by AID but the tag '83' may be present inside the FCP of an ADF. For interoperability reasons, an ADF shall
not be selected by File ID.
b
The patent situation has still to be clarified.
Whether access rules in compact or in (referenced) expanded format compliant with ISO/IEC 7816-4 are
supported is out of the scope of this Technical Specification.
In case an Application DF is selectable by more than one AID the FCP returned by a SELECT command shall
contain at least the AID used to select the ADF.
The File Control Parameter data objects are encoded compliant with ISO/IEC 7816-4 and described in the
following clauses.
There are no restrictions on file IDs, except for those defined by ISO (e.g. ID = '3F00’ is reserved for the MF,
‘0000’ is reserved for the current file, '3FFF’ and ‘FFFF’ are forbidden etc.)
5.6.2 File descriptor byte
The file descriptor byte is encoded as defined in Table 3 — File descriptor byte. Bit 4, 5 and 6 are not relevant
with respect to interoperability and therefore not defined in the present specification.
Table 3 — File descriptor byte
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
File Accessibility
0 0 Not shareable file
0 1 Shareable file
0 - 1 1 1 0 0 0 DF
0 - Not all set to 1 - - - EF category
EF structure
0 - - - - 0 0 1 Transparent structure

- 'Shareable' means that the file supports at least concurrent access on different logical channels.
- The support of shareable files is optional.
5.6.3 Life cycle status byte
Referenced by tag '8A' a life cycle status byte is present in the FCP of any file. This byte shall be interpreted
compliant to ISO/IEC 7816-4 according to Table 4 — Life cycle status byte.
Table 4 — Life cycle status byte
b8 b7 b6 b5 b4 b3 b2 b1 Meaning Applies to
a
0 0 0 0 0 0 0 1 Creation state Any file
a
0 0 0 0 0 0 1 1 Initialisation state Any file
0 0 0 0 0 1 - 1 Operational state (activated) Any file
0 0 0 0 0 1 - 0 Operational state (deactivated) Any file
0 0 0 0 1 1 - - Termination state Any file
- Any other value is RFU
a
Usage of creation and initialization states are implementation dependant.
6 Basic card services
6.1 General
The card services described here from a functional standpoint relate to the IAS services as referred to in prEN
14890-1 and prEN 14890-2. Unless indicated OPTIONAL, the following services shall be supported.
6.2 Identification
6.2.1 Identification of the cardholder
At personalization time, any data dedicated to identify the cardholder are designated as identification data.
6.2.2 Identification of the European Citizen Card
If the European Citizen card makes use of the symmetric device authentication protocol according to clause
6.4.3 or an asymmetric device authentication protocol according to clause 6.4.4.2 or 6.4.4.3, the ECC shall
contain a Primary Account Number (PAN). The structure of the PAN is in accordance with ISO/IEC 7812-1
and defined in Table 5 — Primary Account Number. The PAN is BCD coded.
Table 5 — Primary Account Number
ISO/IEC 7812 definition
Length 6 digits (BCD) 12 digits (BCD) 1 digit (BCD)
IIN Issuer Identification Number
Data
Individual card number Check digit
Country
MII Issuer identifier
code
For the Issuer Identification Number (IIN) the following definitions apply:
 Major Industry Identifier (MII) is a single digit with the value 9, i.e., for assignment by national standard
bodies according to ISO/IEC 7812-1;
 country code is a three digit value in accordance with EN ISO 3166-1;
 issuer identifier is coded on two digits and identifies for the major industry and the country the card issuer
in a unique way. The value is assigned by the corresponding national standard body.
The individual account identification is coded on 12 digits (BCD) and allows a unique identification of the smart
card over all cards having the same IIN.
The check digit is a single digit and allows verification of the PAN integrity. The check digit is calculated
according to the Luhn formula, see ISO/IEC 7812-1.
The PAN is stored in the elementary file EF.SN under the root. The contents of EF.SN is BER-TLV coded
using the tag '5A' that references the PAN, see Table 6 — Structure of EF.SN. In this data object the PAN (19
digits) is concatenated with a filler digit (1 digit with value 'F', BCD encoded) in order to get a value field that is
10 bytes long. The (short) EF Identifier of EF.SN is provided by means of the Cryptographic Information
Application.
Table 6 — Structure of EF.SN
Tag Length Value
'5A' '0A' PAN, (BCD encoded) || Filler bit with value 'F'
Throughout the present specification the following elements of the concatenation of the PAN and the filler bit
are used:
 rightmost 8 bytes are called smart card serial number SN.ICC and used in the context of the device
authentication protocols;
 complete concatenation of the PAN and the filler bit is used in the Card Verifiable certificate of a
European Citizen Card as Certificate Holder Reference (CHR), see Annex B.
6.3 User verification
6.3.1 General aspects
A retry counter and an initial value of the retry counter are defined for each reference data. If the verification
fails, the retry counter is decremented by one and an error status that contains the remaining attempts is
returned by the application.
When the retry counter equals zero, the reference data is blocked and can no longer be used. Note that a
successful verification of the reference data resets its retry counter to the initial value.
The IAS platform supports a resetting code mechanism to unblock reference data, i.e. to reset the
corresponding retry counter to its initial value and optionally to set new reference data. Whether resetting
codes are supported or not and which command variant is supported is defined by the security attributes of
the application as indicated in the corresponding DF.CIA.
6.3.2 Knowledge based
To insure interoperability:
 for the VERIFY command, the referenced data shall be encoded in the P2 parameter;
 for the CHANGE REFERENCE DATA command, the reference data shall be selected by a password
reference encoded in the P2 parameter. Upon successful command execution the reference data inside
the card is replaced by the new reference data provided in the command data field;
 for the RESET RETRY COUNTER, the referenced data shall be encoded in the P2 parameter.
NOTE Command flows for the VERIFY and the CHANGE REFERENCE DATA command can be found in the
upcoming prEN 14890-1. Refer to A.7.5.7 for more information on the usage of the RESET RETRY COUNTER command.
6.3.3 Biometrics – on card matching
Please refer to 7.2.
6.4 Device authentication
6.4.1 General
The European Citizen Card shall at least implement one device authentication protocol based on asymmetric
cryptography. For interoperability reasons a terminal shall implement all protocols based on asymmetric
cryptography.
6.4.2 Authentication environments
Two kinds of environments shall be distinguished, by considering their security level: trusted and un-trusted
environments. During the personalization phase, the issuer will define the access rules to the application
resources. Different access rules can be defined for trusted and un-trusted environments. The terminal shall
adapt the authentication to the security level required by the resource it wishes to access.
For definition of trusted/un-trusted environments, refer to prEN 14890-1:2007, 5.2 and 8.2.
6.4.3 Symmetric authentication scheme
The smart card implements the mutual authentication scheme using symmetric keys as defined in prEN
14890-1:2007, 8.8.
6.4.4 Asymmetric device authentication schemes
6.4.4.1 Card verifiable certificate verification commands
Card verifiable (CV) certificates are used in the context of asymmetric device authentication schemes to
import a public key and related attributes into the European Citizen Card. The structure of the supported CV
certificates and the card internal verification process is specified in Annex B. Details about possible
certification hierarchies can be found in prEN 14890-1:2007, Clause 8.
This clause defines the command flow used to verify a command chain.
6.4.4.2 Key transport protocol
The ICC makes use of the key transport protocol defined in prEN 14890-1:2007, 8.4 for an asymmetric device
authentication service. This protocol makes use of card verifiable (CV) certificates, see Annex B of this
Technical Specification, in order to import public keys into the ICC. Details about possible certification
hierarchies and the calculation of the cryptographic authentication tokens can be found in the referenced
document. While prEN 14890-1 offers several degrees of freedom with respect to the command syntax, this
Technical Specification defines the commands to be used in detail in order to support interoperability.
AlgID DO in KAT CRT is mandatory.
6.4.4.3 Device authentication with privacy protection
The device authentication with privacy protection scheme is based on prEN 14890-1:2007, 8.5. To avoid the
card disclosing private information, such as identity, a secure channel session is established before any other
operation. To do so, the protocol starts with an unauthenticated Diffie-Hellman key exchange and then
authenticates the IFD before the ICC.
Five main phases may be distinguished:
1) set the privacy protection;
2) transport of the IFD public key to the ICC;
3) external authentication of the IFD;
4) transport of the ICC public key to the IFD;
5) internal authentication of the ICC.
6.4.4.4 Privacy constrained device authentication with non traceability based on ELC
The protocol is constructed to serve special case of non-traceability. The protocol does not offer the amount of
privacy as available in authentication with privacy protection (clause 6.4.4.3).
This protocol hinders a verifier to submit the provable existence of the verification process. A possible
application is the use with contact less implementations in the context of citizen cards and homeland security.
It enhances the existing EAC protocol by aspects of privacy.
Five main phases may be distinguished:
- Read public parameters;
- IFD authentication (EXTERNAL AUTHENTICATE);
- ICC authentication (INTERNAL AUTHENTICATE);
- Establish secure session;
- Verification of ICC's certificate.
----------------------
...