CEN/TS 15480-2:2012

SLOVENSKI STANDARD
01-september-2012
1DGRPHãþD
SIST-TS CEN/TS 15480-2:2009
6LVWHPL]LGHQWLILNDFLMVNLPLNDUWLFDPL.DUWLFDHYURSVNLKGUåDYOMDQRYGHO
/RJLþQHVWUXNWXUHSRGDWNRYLQVWRULWYHY]YH]L]YDUQRVWMR
Identification card systems - European Citizen Card - Part 2: Logical data structures and
security services
Identifikationskartensysteme - Europäische Bürgerkarte - Teil 2: Logische
Datenstrukturen und Sicherheitsfunktionen
Systèmes de cartes d’identification - Carte Européenne du Citoyen - Partie 2: structures
de données logiques et services de sécurité
Ta slovenski standard je istoveten z: CEN/TS 15480-2:2012
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
June 2012
ICS 35.240.15
English Version
Identification card systems - European Citizen Card - Part 2:
Logical data structures and security services
Systèmes de cartes d'identification - Carte Européenne du Identifikationskartensysteme - Europäische Bürgerkarte -
Citoyen - Partie 2: structures de données logiques et Teil 2: Logische Datenstrukturen und Sicherheitsfunktionen
services de sécurité
This Technical Specification (CEN/TS) was approved by CEN on 9 January 2012 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, Croatia, 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, Turkey and United Kingdom.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2012 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 15480-2:2012: E
worldwide for CEN national Members.

Contents Page
Foreword .4
1 Scope .5
2 Normative references .5
3 Terms and definitions .6
4 Abbreviations .7
4.1 Abbreviations .7
4.2 Coding conventions and notation.9
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 . 15
5.5 Selection of data structures . 16
5.6 Access to files . 17
6 Basic card services . 18
6.1 General . 18
6.2 Identification . 18
6.3 User verification . 20
6.4 Device authentication . 20
6.5 Digital signature . 23
6.6 Client/Server Authentication . 24
6.7 Encryption key decipherment . 24
7 Extended card services . 25
7.1 General . 25
7.2 Biometrics – on card matching . 25
7.3 Passive Authentication . 25
7.4 Basic Access Control . 25
7.5 Active Authentication . 25
7.6 Extended Access Control . 26
7.7 Role authentication. 26
7.8 Restricted Identification (RI) . 27
7.9 Age, Validity or Auxiliary Data Verification . 28
7.10 Modular Enhanced Role Authentication (mERA) . 28
Annex A (normative) Command set . 29
A.1 CLASS byte coding. 29
A.2 Command chaining mechanisms . 29
A.3 Extended length mechanism . 30
A.4 Logical channels . 31
A.5 Short and extended length fields . 31
A.6 Status words . 31
A.7 Command set . 32
Annex B (normative) Cryptographic Information Application . 54
B.1 Description . 54
B.2 CIA data organisation . 63
Annex C (normative) Mandatory features . 83
C.1 General . 83
C.2 Data elements and data structures . 83
C.3 Card services . 84
C.4 Command set . 84
C.5 Device Authentication and Key Derivation . 85
C.6 Digital signature . 85
C.7 Client/Server Authentication . 86
C.8 Encryption Key Decipherment . 86
Annex D (informative) Optional features . 87
D.1 General . 87
D.2 Data elements and data structures . 87
D.3 Card services . 88
D.4 Command set . 88
D.5 Device Authentication and Key Derivation . 89
D.6 Digital signature . 89
Annex E (informative) Application Profiles . 90
E.1 General . 90
E.2 Application Profile 1: ICAO Application with EAC features . 90
E.3 Application Profile 2: Travel Document Application . 96
E.4 Application Profile 3: eID Application . 101
E.5 Application Profile 4: Digital Signature Application . 111
E.6 E.6 Application Profile 5: eServices Application using a trusted third party . 121
E.7 Application Profile 6: Health Insurance Application . 136
E.8 Application Profile 7: Combined eID and signature application . 152
E.9 Application Profile 8: Multi-Service application . 156
Annex F (informative) Access rules in expanded format . 161
F.1 Object protection by access rules in expanded format . 161
F.2 Access rules in expanded format . 161
F.3 Security attribute referencing expanded format . 162
F.4 Security attribute template for physical interfaces . 163
Annex G (informative) Example of data structure: the Security Data Objects concept . 164
G.1 SDO concept . 164
Bibliography . 176

Foreword
This document (CEN/TS 15480-2:2012) 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.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights.
This document supersedes CEN/TS 15480-2:2007.
CEN/TS 15480 Identification card systems — European Citizen Card consists of the following four parts:
Part 1, Physical, electrical and transport protocol characteristics
Part 2, Logical data structures and card services
Part 3, European Citizen Card Interoperability using an application interface
Part 4, Recommendations for European Citizen Card issuance, operation and use
According to the CEN/CENELEC Internal Regulations, the national standards organisations of the following
countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria, Croatia, 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, Turkey and the 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 aims to ensure the interoperability at card/system interface in the usage phase.
In order to reach the interoperability objective, IAS services are compliant with EN 14890 Part 1 and Part 2. As
the EN documents offer options, this specification fully defines a complete profile.
This Technical Specification also considers ICAO Doc 9303.
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 requirements for use.
Mandatory features shall be implemented for a smart card to be compliant with this Technical Specification.
Mandatory features required for compliancy to ECC specification are given in Annex C, the optional features
are given in Annex D. Two IAS-enabled smart cards issued by two different issuers, and compliant with this
Technical Specification but implementing different application profiles out of this Technical Specification, can
interoperate with a terminal provided that such a terminal supports both application profiles. 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 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.
EN 14890-1:2008:2008, Application Interface for smart cards used as Secure Signature Creation Devices —
Part 1: Basic requirements
ISO/IEC 7816-3, Information technology — Identification cards — Integrated circuit(s) cards with contacts —
Part 3: Electronic signals and transmission protocols
ISO/IEC 7816-4:2005, Identification cards — Integrated circuit(s) cards — Part 4: Organisation, security and
commands for interchange
ISO/IEC 7816-4:2005/PDAM 2.1:2008, Identification cards — Integrated circuit(s) cards — Part 4:
Organisation, security and commands for interchange, AMENDMENT 2: Handling of Extended Length
Information (Working Draft)
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 7816-15:2004/Amd 1:2007, Identification cards — Integrated circuit cards with contact — Part 15:
Cryptographic information application, AMENDMENT 1: Examples of the use of the cryptographic information
application
ISO/IEC 7816-15:2004/Amd 2:2008, Identification cards — Integrated circuit cards with contact — Part 15:
Cryptographic information application, AMENDMENT 2: Error corrections and extensions for multi-application
environments
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 19794-2, Information technology — Biometric data interchange formats — Part 2: Finger minutiae
data
ANSI X9.63, Public Key Cryptography For the Financial Services Industry: Key Agreement and Key Transport
th
Using Elliptic Curve Cryptography, January 8 1999
BSI TR-03110 Version 1.11, Advanced Security Mechansims for Machine Readable Travel Documents –
Extended Access Control (EAC)
BSI TR-03111 Version 1.11, Technical Guideline Elliptic Curve Cryptography
ICAO Doc 9303, Machine Readable Travel Documents, Part 3 – Machine Readable Official Travel Documents
– Volume 2 Specifications for Electronically Enabled MRtds with Biometric Identification Capability, Third
Edition, 2008
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
Application Dedicated File (ADF)
structure hosting an application in a card
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_X509.CH.AUT = Certificate of the card holder for client/server authentication.
In addition, the following notation is used:
K Randomness provided by ICC and IFD used for session key derivation
ICC/IFD
RND.ICC Random number of the ICC
RND.IFD Random number of the IFD
SN.ICC Serial number of the ICC
SN.IFD Serial number 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 externally accessed data (certificates, card serial number, .). Exceptions from this rule, i.e. 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. For example, 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 or the content of EF.ATR/INFO. 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 (native or JavaCard implementation).
4) Three basic file types are supported (refer to ISO/IEC 7816-4 for definitions of EF, DF and ADF):
i) transparent EF;
ii) dedicated files DF;
iii) application dedicated files ADF
5) For cards without MF, each applet instance matches with at least one application DF (ADF).
6) All cards shall contain an EF.DIR file.
i) The EF.DIR is always under the root.
ii) The file identifier of EF.DIR 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/INFO (see, 5.3.3). 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/INFO is mandatory in this case.
Table 1 provides the list of data objects which may be supported by the card in the ATR/ATS in the Compact-
TLV format as defined in ISO/IEC 7816-4, Table 2 provides the data objects in EF.ATR/INFO for the BER-TLV
structure. The data objects defined in Table 1 and Table 2 have to be used as given in the tables, these are
not application specific.
5.3.2 Historical bytes
The ATR/ATS contains configuration data so that ICC and IFD can communicate together (protocol, speed,
etc.).
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.
If a data object from Table 1 is used in the historical bytes 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 Historical Bytes
Byte # Name Value Description
Category COMPACT-TLV data objects followed by a status indicator shall be
1 ‘00’
indicator present as the last three historical bytes
Card service
2 ‘31’ Tag for next byte
data tag
b8=1: Application selection by full DF name
b6=1: BER-TLV DO are present in EF.DIR
a
b5=1: BER-TLV DO present in EF.ATR/INFO
Card service
3 ’B9’ or ‘B8’
data byte
b4.b2=100: EF.DIR/EF.ATR is a transparent EF (use READ
BINARY)
b1 = 0: Card with MF
b1 = 1: Card without MF
Pre-issuing DO
4 ‘64’ Tag for next 4 bytes
tag
5 IC manufacturer ‘XX’ IC Manufacturer according ISO/IEC 7816-6
6 Type of the IC ‘XX’ defined by the IC or card manufacturer
7 OS Version XX Version of the operating system defined by card manufacturer
Discretionary
8 ‘XX’ Discretionary data
data
Card capabilities
9 ‘73’ Tag for next 3 bytes
data tag
DF selection
Card capabilities
b8=1: DF selection full name
data byte 1
10 ‘94’ b5=1: DF selection using file identifier
� Selection
EF selection
method
b3=1: file selection using short file identifier is supported
Card capabilities
data byte 2
11 ‘01’ b4.b1 = 0001: data unit size is 1 byte
� Data coding
byte
b8=1: command chaining is supported
b7=0: Extended Lc and Le fields not supported
Card capabilities
‘C0’, ‘80’, ‘D0’ b7=1: Extended Lc and Le fields supported
data byte 3
or ‘90’
b5, b4=00: no logical channel supported
� Miscellaneous
b5, b4=10: channel number assignment by the card
Maximum number of channels supported: 4
Status indicator
13 ‘8x’ Tag for next byte, x is either '2' or '3'
tag
14 Status indicator [ LCS || ] ‘9000’ Life Cycle State (optional) followed by status words SW1-SW2
a
DO may be present in EF.ATR/INFO for compatible tag

The list and the order of the historical bytes are compulsory unless further items complete these historical
bytes according to the smart card manufacturer’s policy (e.g. reference and version of the application).
5.3.3 EF.ATR/INFO
At least one of the options ATR/ATS or EF.ATR/INFO shall be supported.
The support of an EF.ATR/INFO shall be indicated in the "card service data byte" of the historical bytes if an
ATR/ATS is supported. With regard to ISO/IEC 14443-4, the ATS Application information bytes are not
normalised for data objects interoperable description. Therefore, for both contact and contact-less cards,
EF.ATR/INFO may host information.
For data objects stored in the EF.ATR/INFO the BER-TLV format is mandatory. All data objects given in
Table 2 are mandatory to be contained in EF.ATR/INFO except if they are conditional or not applicable.
In order to identify the compatible tag allocation scheme and the authority responsible for the scheme, the
interindustry template referenced by tag '78' is used by the present specification. The allocation authority shall
be identified as CEN by an OID with the following root:
ISO (1) identified-organisation (3) CEN (162)
The specification number to be defined according to CEN conventions shall be added to this root to figure the
full OID. The corresponding BER-TLV encoded OID shall be nested in the data object '06'.
The DO referenced by tag '78' may be hosted in EF.ATR while the historical byte denoting the Card Service
Data shall has bit5 set to one to indicate that a DO is available in EF.ATR.
Alternatively, the D.O. ‘78’ can be hosted by an ADF whereby denoting that the tag allocation scheme applies
to data objects within this ADF and not to the whole card.
Table 2 — Card Identification Data Objects (1 of 2)
Tag Length What Value Meaning
Category Indicate format of next historical bytes (compact
'80' N.A. '00'
indicator TLV)
Card service
'43' '01' Tag for next byte
data tag
b8=1 : Application selection by full DF name
b6=1 : BER TLV DO are present in EF.DIR
a
b5=1 : BER-TLV DO present in EF.ATR
Card service
'B9', 'B8'
b4.b2=100 : EF.DIR/EF.ATR is a transparent
data byte
EF (use READ BINARY)
b1 = 0 : Card with MF
b1 = 1 : Card without MF
Pre-issuing
'46' '04' Tag for next 4 bytes
DO
IC
'XX' IC Manufacturer according ISO/IEC 7816-6
manufacturer
Type of the IC 'XX' defined by the IC or card manufacturer

Version of the operating system defined by card
OS Version 'XX'
manufacturer
Discretionary
'XX' Discretionary data
data
Card
'47' '03' capabilities Tag for next 3 bytes
tag
DF selection
Card
b8=1 : DF selection full name
capabilities
b5=1 : DF selection using file identifier
data byte 1
'94'
EF selection
� Selection
method
b3=1 : file selection using short file identifier is
supported
Card
capabilities
data byte 2
'01' b4.b1 = 0001 : data unit size is 1 byte

� Data
coding byte
b8=1 : command chaining is supported
b7=0 : Extended Lc and Le fields NOT supported
Card
capabilities b7=1 : Extended Lc and Le fields supported
data byte 3
'C0', '80', 'D0', '90'
b5, b4=00 : no logical channel supported
�
b5, b4=10 : channel number assignment by the
Miscellaneous
card
Maximum number of channels supported :4
Application AID of implicitly selected application (1 to 16
'4F' '01'…'10' 'XX…XX'
Identifier bytes)
Table 2 — Card Identification Data Objects (2 of 2)
4 concatenated data objects with tag ‘02’
(Universal class). The value field of each DO
encodes the maximum number of bytes of the
respective APDU.
'WW'…'WW' = DO maximum length of command
'02' – L – 'WW'…'WW'
APDU without secure messaging
|| '02' – L – 'XX'…'XX'
b
'E0' '10' IO buffer size
|| '02' – L – 'YY'…'YY' 'XX'…'XX' = DO maximum length of command
|| '02' – L – 'ZZ'…'ZZ' APDU with secure messaging
'YY'…'YY' = DO maximum length of response
APDU without secure messaging
'ZZ'…'ZZ' = DO maximum length of response
APDU with secure messaging.
'XX'…'XX': Positive integer, the number of bytes
in a command APDU shall not exceed this
number
'02' – L – 'XX'…'XX' ||
'YY'…'YY': Positive integer, if the card does not
'7F66' Variable IO buffer size
'02' – L – 'YY…'YY'
support response chaining for a particular
command-response pair, then N shall be set
e
such that the number of bytes in a response
APDU does not exceed this number
Allocation
'78' '08' Tag for next 8 bytes
scheme tag
OID of the allocation authority to be identified as
OID '06 06 2B8022F87802'
CEN.
'02' or Status
'82' Tag for next 2 or 3 bytes
'03' indicator
Status Word [LCS || ] '9000' Life cycle state (optional) followed by SW1+ SW2
a
A DO(s) may be present in EF.ATR for the purposes of compatible tag allocation scheme or other purposes
b
The use of the 'E0' data object is not recommended for future applications.

5.4 General architecture and file supported
Figure 1 shows an example of directory and elementary file organisation.
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 purposes, 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 3 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
Files selection is always relative to the ADF. The EF selection can be performed either:
 explicitly by the SELECT command using FID over two bytes, or
 implicitly 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 3 — 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 3 — 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
b
'A1' variable Security attribute template for physical interfaces Any file
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
This data object will be substituted by the the data object defined in the upcoming revised CD version of ISO/IEC 7816-4 as soon as it
is available.
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.
Where 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/IEC 7816-4 and this standard (e.g. ID =
'3F00’ is reserved for the MF, '2F00' is reserved for EF.DIR, ‘2F01’ is reserved for EF.ATR, ‘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 2. Bit 4, 5 and 6 are not relevant with respect to
interoperability and therefore not defined in the present specification.
Table 4 — File descriptor byte
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
File Accessibility
0 0 Not shareable file
0 1 Shareable file
DF
0 - 1 1 1 0 0 0
EF category
0 - Not all set to 1 - - -
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 with ISO/IEC 7816-4 according to Table 2.
Table 5 — 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 EN
14890-1:2008:2008 and EN 14890-2. Unless indicated as OPTIONAL, the following services shall be
supported.
6.2 Identification
6.2.1 Identification of the cardholder
At personalisation 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 6.4.3 or
an asymmetric device authentication protocol according to 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 2. The PAN is BCD coded.
Table 6 — 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:
 the Major Industry Identifier (MII) typical
...