1、September 2012Normenausschuss Informationstechnik und Anwendungen (NIA) im DINPreisgruppe 36DIN Deutsches Institut fr Normung e. V. Jede Art der Vervielfltigung, auch auszugsweise, nur mit Genehmigung des DIN Deutsches Institut fr Normung e. V., Berlin, gestattet.ICS 35.240.15Zur Erstellung einer DI
2、N SPEC knnen verschiedene Verfahrensweisen herangezogen werden: Das vorliegende Dokument wurde nach den Verfahrensregeln einer Vornorm erstellt.!$sT:= | := := | := PrK:= PuK := | := CH := | | := ICC := IFD := S:= | | | := AUT := KA:= RA := KE := := | := C_CV := C_X509 DIN CEN/TS 15480-2 (DIN SPEC 91
3、130-2):2012-09 CEN/TS 15480-2:2012 (E) 10 := | 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 no
4、tation is used: KICC/IFDRandomness provided by ICC and IFD used for session key derivation 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
5、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 desc
6、ription 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
7、 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 Euro
8、pean 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 c
9、ard 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
10、 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): DIN CEN/TS 15480-2 (DIN SPEC 91130-2):
11、2012-09 CEN/TS 15480-2:2012 (E) 11 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
12、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/I
13、EC 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.
14、 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
15、 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 shal
16、l 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 objec
17、t 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 c
18、hoice of the card manufacturer but shall follow the rules given in ISO/IEC 7816-4. DIN CEN/TS 15480-2 (DIN SPEC 91130-2):2012-09 CEN/TS 15480-2:2012 (E) 12 Table 1 Card Identification Historical Bytes Byte # Name Value Description 1 Category indicator 00 COMPACT-TLV data objects followed by a status
19、 indicator shall be present as the last three historical bytes 2 Card service data tag 31 Tag for next byte 3 Card service data byte B9 or B8 b8=1: Application selection by full DF name b6=1: BER-TLV DO are present in EF.DIR b5=1: BER-TLV DO present in EF.ATR/INFOa b4.b2=100: EF.DIR/EF.ATR is a tran
20、sparent EF (use READ BINARY) b1 = 0: Card with MF b1 = 1: Card without MF 4 Pre-issuing DO tag 64 Tag for next 4 bytes 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 c
21、ard manufacturer 8 Discretionary data XX Discretionary data 9 Card capabilities data tag 73 Tag for next 3 bytes 10 Card capabilities data byte 1 null Selection method 94 DF selection b8=1: DF selection full name b5=1: DF selection using file identifier EF selection b3=1: file selection using short
22、file identifier is supported 11 Card capabilities data byte 2 null Data coding byte 01 b4.b1 = 0001: data unit size is 1 byte 12 Card capabilities data byte 3 null Miscellaneous C0, 80, D0 or 90 b8=1: command chaining is supported b7=0: Extended Lc and Le fields not supported b7=1: Extended Lc and L
23、e fields supported b5, b4=00: no logical channel supported b5, b4=10: channel number assignment by the card Maximum number of channels supported: 4 13 Status indicator tag 8x Tag for next byte, x is either 2 or 3 14 Status indicator LCS | 9000 Life Cycle State (optional) followed by status words SW1
24、-SW2 aDO 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 manufacturers policy (e.g. reference and version of the application). DIN CEN/TS 15480-2 (DIN SPEC
25、91130-2):2012-09 CEN/TS 15480-2:2012 (E) 13 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, th
26、e 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 m
27、andatory 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 autho
28、rity 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 o
29、bject 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
30、 data objects within this ADF and not to the whole card. DIN CEN/TS 15480-2 (DIN SPEC 91130-2):2012-09 CEN/TS 15480-2:2012 (E) 14 Table 2 Card Identification Data Objects (1 of 2) Tag Length What Value Meaning 80 N.A. Category indicator 00 Indicate format of next historical bytes (compact TLV) 43 01
31、 Card service data tag Tag for next byte Card service data byte B9, B8 b8=1 : Application selection by full DF name b6=1 : BER TLV DO are present in EF.DIR b5=1 : BER-TLV DO present in EF.ATRa b4.b2=100 : EF.DIR/EF.ATR is a transparent EF (use READ BINARY) b1 = 0 : Card with MF b1 = 1 : Card without
32、 MF 46 04 Pre-issuing DO Tag for next 4 bytes IC manufacturer XX IC Manufacturer according ISO/IEC 7816-6 Type of the IC XX defined by the IC or card manufacturer OS Version XX Version of the operating system defined by card manufacturer Discretionary data XX Discretionary data 47 03 Card capabiliti
33、es tag Tag for next 3 bytes Card capabilities data byte 1 null Selection method 94 DF selection b8=1 : DF selection full name b5=1 : DF selection using file identifier EF selection b3=1 : file selection using short file identifier is supported Card capabilities data byte 2 null Data coding byte 01 b
34、4.b1 = 0001 : data unit size is 1 byte Card capabilities data byte 3 null Miscellaneous C0, 80, D0, 90 b8=1 : command chaining is supported b7=0 : Extended Lc and Le fields NOT supported b7=1 : Extended Lc and Le fields supported b5, b4=00 : no logical channel supported b5, b4=10 : channel number as
35、signment by the card Maximum number of channels supported :4 4F 0110 Application Identifier XXXX AID of implicitly selected application (1 to 16 bytes) DIN CEN/TS 15480-2 (DIN SPEC 91130-2):2012-09 CEN/TS 15480-2:2012 (E) 15 Table 2 Card Identification Data Objects (2 of 2) E0b 10 IO buffer size 02
36、L02 WWWW | 02 L02 XXXX | 02 L02 YYYY | 02 L02 ZZZZ 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. WWWW = DO maximum length of command APDU without secure messaging XXXX = DO maximum length of command A
37、PDU with secure messaging YYYY = DO maximum length of response APDU without secure messaging ZZZZ = DO maximum length of response APDU with secure messaging. 7F66 Variable IO buffer size 02 L02 XXXX | 02 L02 YYYY XXXX: Positive integer, the number of bytes in a command APDU shall not exceed this num
38、ber YYYY: Positive integer, if the card does not support response chaining for a particular command-response pair, then Neshall be set such that the number of bytes in a response APDU does not exceed this number 78 08 Allocation scheme tag Tag for next 8 bytes OID 06 06 2B8022F87802 OID of the alloc
39、ation authority to be identified as CEN. 82 02 or 03 Status indicator Tag for next 2 or 3 bytes Status Word LCS | 9000 Life cycle state (optional) followed by SW1+ SW2 aA DO(s) may be present in EF.ATR for the purposes of compatible tag allocation scheme or other purposes bThe use of the E0 data obj
40、ect is not recommended for future applications. 5.4 General architecture and file supported Figure 1 shows an example of directory and elementary file organisation. DIN CEN/TS 15480-2 (DIN SPEC 91130-2):2012-09 CEN/TS 15480-2:2012 (E) 16 Figure 1 Directory architecture example The card supports the
41、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
42、 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
43、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 b
44、y 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 interoperabi
45、lity. 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 messag
46、ing 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: DIN CEN/TS 15480-2 (DIN SPEC
47、91130-2):2012-09 CEN/TS 15480-2:2012 (E) 17 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
48、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
49、 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 i
