section 5 – Basic Organizations

ISO 7816 Part 4: Interindustry Commands for Interchange

ISO 7816 part 4, section..1 2 3 4 5 6 7 8 9 annex.. A B C D E F

For the latest version of ISO7816 part 4, please contact ISO in Switzerland.

ISO 7816-4, Section 5 – Basic Organizations

5.1 Data structures
5.2 Security architecture of the card
5.3 APDU message structure
5.4 Coding conventions for command headers, data fields and response trailers
5.5 Logical channels
5.6 Secure messaging

5.1 Data structures

This clause contains information on the logical structure of data as seen at the interface, when processing interindustry commands for interchange. The actual storage location of data and structural information beyond what is described in this clause are outside the scope of ISO/IEC 7816.

5.1.1 File organization
5.1.2 File referencing methods
5.1.3 Elementary file structures
5.1.4 Data referencing methods
5.1.4.1 Record referencing
5.1.4.2 Data unit referencing
5.1.4.3 Data object referencing
5.1.5 File control information

5.1.1 File organization

This part of ISO/IEC 7816 supports the following two categories of files :

• Dedicated file (DF)
• Elementary file (EF)

The logical organization of data in a card consists of following structural hierachy of dedicated files :

• The DF at the root is called the master file (MF). The MF is mandatory.
• The other DFs are optional.

The following two types of EFs are defined :

• Internal EF – Those EFs are intended for storing data interpreted by the card, i.e. data analyzed and used by the card for management and control purposes.
• Working EF – Those EFs are intended for storing data not interpreted by the card, i.e. data to be used by the outside world exclusively.

Figure 1 illustrates an example of the logical file organization in a card.

Figure 1 – Logical file organization (example)

5.1.2 File referencing methods

When a file cannot be implicitly selected, it shall be possible to select it by at least one of the following methods :

• Referencing by file identifier – Any file may be referenced by a file identifier coded on 2 bytes. If the MF referenced by a file identifier, ‘3F00’ shall be used (reserved value). The value ‘FFFF’ is reserved for future use. The value ‘3FFF’ is reserved (see referencing by path). In order to select unambiguously any file by its identifier, all EFs and DFs immediately under a given DF shall have different file identifiers.
• Referencing by path – Any file may be referenced by a path (concatentation of file identifiers). The path begins with the identifier of the MF or of the current DF and ends with the identifier of the file itself. Between those two identifiers, the path consists of the identifiers of the successive parent DFs if any. The order of the file identifiers is always in the direction parent to child. If the identifier of the current DF is not known, the value ‘3FFF’ (reserved value) can be used at the beginning of the path. The path allows an unambiguous selection af any file from the MF or from the current DF.
• Referencing by short EF identifier – Any EF may be referenced by a short EF identifier coded on 5 bits valued in the range from 1 to 30. The value ‘0’ used as a short EF identifier references the currently selected EF. Short EF identifiers connot be used in a path or as a file identifier (e.g. in a SELECT FILE command)
• Referencing by DF name – Any DF may be referenced by a DF name coded on 1 to 16 bytes. In order to select unambiguously by DF name (e.g. when selecting by means of application identifiers as define in part 5 of ISO/IES 7816), each DF name shall be unique within a given card.

5.1.3 Elementary file structures

The following structures of EFs are defined :

• Transparent structure – The EF is seen at the interface as a sequence of data units.
• Record structure – The EF is seen at the interface as a sequence of individually identifiable records.

The following attributes are defined for EFs structured in records :

• Size of the records: either fixed or variable
• Organization of the records: either as a sequence (linear structure) or as a ring (cyclic structure).

The card shall support at least one of the following four methods for structuring EFs :

• Transparent EF.
• Linear EF with record of fixed size.
• Linear file with records of variable size.
• Cyclic EF with records of fixed size.

Figure 2 shows those for EF structures.

F I G U R E 2

Figure 2 – EF structures

NOTE – The arrow on the figure references the most recently written record.

5.1.4 Data referencing methods

Data may be referenced as records, as data units or as data objects. Data is considered to be stored in a single continuous sequence of records (within an EF of record structure) or of data units (within an EF of transparent structure). Reference to a record or to a data unit outside an EF is an error.

Data referencing method, record numbering method and data unit size are EF-dependent features. The card can provide indications in the ATR, in the ATR file and in any file control information. When the card provides indications in several places, the indication valid for a given EF is the closest one to that EF within the path from the MF to that EF.

5.1.4.1 Record referencing

Within each EF of record structure, each record can be referenced by a record identifier and/or by a record number. Record identifiers and record numbers are unsigned 8-bit integers with values in the range from ’01’ to ‘FE’. The value ’00’ is reserved for special purposes. The value ‘FF’ is RFU.

Referencing by record identifier shall induce the management of a record pointer. A reset of the card, a SELECT FILE and any command carrying a valid short EF identifier can affect the record pointer. Referencing by record number shall not affect the record pointer.

Referencing by record identifier – Each record identifier is provided by an application. If a record is a SIMPLE-TLV data object in the data field for a message (see 1.4.4), then the record identifier is the first byte of the data object. Within an EF of record structure, records may have the same record identifier, in which case data contained in the records may be used for discriminating between them.
Each time a reference is made with a record identifier, an indication shall specify the logical position of the target record the first or last occurrence, the next or previous occurrence relative to the record pointer :

• Within each EF of linear structure, the logical positions shall be sequentially assigned when writing or appending i.e. in the order of creation. Therefore the first created record is in the first logical position.
• Within each EF of cyclic structure, the logical positions shall be sequentially assigned in the opposite order, i.e. the most recently created record is in the first logical position.

Each time a reference is made with a record identifier, an indication shall specify the logical position of the target record the first or last occurrence, the next or previous occurrence relative to the record pointer :

• Within each EF of linear structure, the logical positions shall be sequentially assigned when writing or appending i.e. in the order of creation. Therefore the first created record is in the first logical position.
• Within each EF of cyclic structure, the logical positions shall be sequentially assigned in the opposite order, i.e. the most recently created record is in the first logical position.

The following additional rules are defined for linear structures and for cyclic structures :

• The first occurrence shall be the record with the specified identifier and in the first logical position; the last occurrence shall be the record with the specified identifier and in the last logical position.
• When there is no current record, the next occurrence shall be equivalent to the first occurrence. The previous occurrence shall be equvalent to the last occurrence.
• When there is a current record, the next occurrence shall be the closest record with the specified identifier but in a greater logical position than the current record. The previous occurrence shall be the closest record with the specified identifier but in a smaller logical position than the current record.
• The value ’00’ shall refer to the first, last, next and previous record in the numbering sequence, independently from the record identifier.

Referencing by record number – Within each EF of record structure, the record numbers are unique and sequential :

• Within each EF of linear structure, the record numbers shall be sequentially assigned when writing or appending, i.e. in the order of creation. Therefore the first record (record number one, #1) is the first created record.
• Within each EF of cyclic structure, the record numbers shall be sequentially assigned in the opposite order, i.e. the first record (record number one, #1) is the most recently created record.

The following additional rule is defined for linear structures and for cyclic structures :

• The value ’00’ shall refer to the current record, i.e. that record fixed by the record pointer.

5.1.4.2 Data unit referencing

Within each EF of transparent structure, each data unit can be referenced by an offset (e.g. in READ BINARY command). It is an unsigned integer, limited to either 8 or 15 bits according to an option in the respective command. Valued to 0 for the first data unit of the EF, the offeset is incremented by 1 for every subsequent data unit.
By default, i.e. if the card gives no indication, the size of the date unit is one byte.

NOTES

1. An EF of record structure may support data unit referencing and in case it does, data units may contain structural information along with data, e.g. record numbers in a linear structure.
2. Within an EF of record structure, data unit referencing may not provide the intended result because the storage order of the records in the EF is not known, e.g. storage order in a cyclic structure.

5.1.4.3 Data object referencing

Each data object (as defined in 1.4.4) is headed by a tag which references it. Tags are specified in this part and other parts of ISO/IEC 7816.

5.1.5 File control information

The file control information (FCI) is the string of data bytes available in response to a SELECT FILE command. The file control information may be present for any file. Table 1 introduces 3 templates intended for conveying file control information when coded as BER-TLV data objects.

• The FCP template is intended for conveying file control parameters (FCP), i.e. any BER-TLV data objects defined in table 2.
• The FMD template is intended for conveying file management data (FMD), i.e. BER-TLV data objects specified in other clauses of this part or in other parts of ISO/IEC 7816 (e.g., application label as defined in part 5 and application expiration data as defined in part 6).
• The FCI template is intended for conveying file control parameters and file management data.

Table 1 – Template relevant to FCI

The 3 templates may be retrieved according to selection options of the SELECT FILE command . If the FCP or FMD option is set, then the use of the corresponding template is mandatory. If the FCI option is set then the use of the FCI template is optional.

Part of the file control information may additionally be present in a working EF under control of an application and referenced under tag ’87’. The use of the FCP or FCI template is mandatory for the coding of file control information in such an EF.

File control information not coded according to this part of ISO/IEC 7816 may be introduced as follows :

• ’00’ or any value higher then ‘9F’ – The coding of the subsequent string of bytes is proprietary.
• Tag=’53’ – The value field of the data object consists of discretionary data not coded in TLV.
• Tag=’73’ – The value field of the data object consists of dicretionary BER-TLV data object.

Table 2 – File control parameters

Table 3 – File descriptor bytey

Shareable means that the file supports at least concurrent access on different logical channels.

5.2 Security architecture of the card

This clause describes the following features :

5.2.1 Security status
5.2.2 Security attributes5.2.3 Security mechanisms
5.2.3 Security mechanisms

Security attributes are compared with the security status to execute command and/or to access files.

5.2.1 Security status

Security status represents the current state possibly achieved after completion of

• answer to reset (ATR) and possible protocol type selection (PTS) and/or
• a single command or a sequence of commands possibly performing authentication procedures.

The security status may also result from the completion of a security procedure related to the identification of the involved entities, if any, e.g.

• by proving the knowledge of a password (e.g. using a VERIFY command)
• by proving the knowledge of a key (e.g. using a GET CHALLANGE command followed by an EXTERNAL AUTHENTICATE command)
• by secure messaging (e.g. message authentication)

Three security statuses are considerd :

• Global security status – It may be modified by the completion of an MF-related authentication procedure (e.g. entity authentication by a password or by a key attached to the MF).
• File-specific security status – It may be modified by the completion of a DF-related authentication procedure (e.g. entity authentication by a password or by a key attached to the specific DF). It may be maintained, recovered or lost by file selection (see 6.10.2) this modification may be relevant only for the application to which the authentication procedure belongs.
• Command-specific status – It only exists during the execution of a command involving authentication using secure messaging (see 1.6): such a command may leave the other security status unchanged

If the concept of logical channels is applied, the file specify security status may depend on the logical channel (see 1.5.1).

5.2.2 Security attributes

The security attributes, when they exist, define the allowed actions and the procedures to be performed to complete such actions.

Security attibutes may be associated with each file and fix the security conditions that shall be satisfied to allow operations on the file. The security attributes of file depend on :

• its category (DF or EF),
• optional parameters in its file control information and/or in that of its parent file(s).

NOTE – Security attributes may also be associated to other objects (e.g. keys).

The security attributes, when they exist, define the allowed actions and the procedures to be performed to complete such actions.

Security attibutes may be associated with each file and fix the security conditions that shall be satisfied to allow operations on the file. The security attributes of file depend on :

• its category (DF or EF),
• optional parameters in its file control information and/or in that of its parent file(s).

NOTE – Security attributes may also be associated to other objects (e.g. keys).

5.2.3 Security mechanisms

This part of ISO/IEC 7816 defines the following security mechanisms :

• Entity authentication with password – The card compares data received from the outside world with secret internal data. This mechanism may be used for protecting the right of the user.
• Entity authentication with key – The entity to be euthenticated has to prove the knowledge of the relevant key in an authentication procedure (e.g. using a GET CHALLENGE command followed by an EXTERNAL AUTHENTICATE command).
• Data authentication – Using internal data, either secret or public, the card checks redundant data recived from the outside world. Alternately, using secret internal data, the card computes a data element (cryptographic checksum or digital signature) and inserts it in the data sent to the outside world. This mechanism may be used for protecting the rights of a provider.
• Data encipherment – Using secret internal data, the card deciphers a cryptogram received in a data field. Alternately, using internal data, either secret or public, the card computes a cryptogram and inserts it in a data field, possibly together with other data. This mechanism may be used to provide a confidentiality service, e.g. for key management and conditional access. In addition to the cryptogram mechanism, data confidentiality can be achieved by data concealment. In this case, the card computes a string of concealing bytes and adds it by exclusive-or to data bytes received from or sent to the outside world. This mechanism may be used for protecting privacy and for reducing the possibilities of message filtering.

The result of an authentication may be logged in an internal EF according to the requirements of the application.

5.3 APDU message structure

A step in an application protocol consists of sending a command, processing it in the receiving entity and sending back the response. Therefore a spcecific response corresponds to a specific command, referred to as a command-response pair.

5.3.1 Command APDU
5.3.2 Decoding convention for command bodies
5.3.3 Response APDU

An application protocol data unit (APDU) contains either a command message or a response message, sent from the interface device to the card or conversely.
In a command-response pair, the command message and the response message may contain data, thus inducing four cases which are summarised by table 4.

Table 4 – Data within a command-response pair

5.3.1 Command APDU

Illustrated by figure 3 (see also table 6), the command APDU defined in this part of ISO/IEC 7816 consists of

• a mandatory header of 4 bytes (CLA INS P1 P2),
• a conditional body of variable length

Figure 3 – Command APDU structure

The number of bytes present in the data field of the command APDU is denoted by Lc.

The maximum number of bytes expected in the data field of the response APDU is denoted by Le (length of expected data). When the Le field contains only zeros, the maximum number of available data bytes is requested.
Figure 4 shows the 4 structures of command APDUs according to the 4 cases defined in table 4.

I M A G E 4

Figure 4 – The 4 structures of command APDUs
In case 1, the length Lc is null; therefore the Lc field and the data field are empty. The length Le is also null; therefore the Le field is empty. Consequently, the body is empty.
In case 2, the length Lc is null; therefore the Lc field and the data field are empty. The length of Le is not null; therefore the Le field is present. Consequently, the body consists of the Le field.
In case 3, the length Lc is not null; therefore the Lc field is present and the data field consists of the Lc subsequent bytes. The length Le is null; therefore the Le field is empty. Consequently, the body consists of the Lc field followed by the data field.
In case 4, the length Lc is not null; therefore the Lc field is present and the data field consists of the Lc subsequent bytes. The length Le is also not null; therefore the Le field is also present. Consequently, the body consists of the Lc field followed by the data field and the Le field.

5.3.2 Decoding conventions for command bodies

In case 1, the body of the command APDU is empty. Such a command APDU carries no length field.

In cases 2, 3 and 4 the body of the command APDU consists of a string of L bytes denoted by B1 to BL as illustrated by figure 5. Such a body carries 1 or 2 length fields; B1 is [part of] the first length field.

Figure 5 – Not empty body

In the card capabilities (see 8.3.6), the card states that, within the command APDU, the Lc field and Le field

• either shall be short (one byte, default value)
• or may be extended (explicit statement)

Consequently, the cases 2, 3 and 4 are either short (one byte for each length field) or extended (B1 is valued to ’00’ and the value of each length is coded on 2 other bytes).

Table 5 shows the decoding of the command APDUs according to the four cases defined in table 4 and figure 4 and according to the possible extension of Lc and Le.

Table 5 – Decoding of the command APDUs

Decoding conventions for Le
If the value of Le is coded in 1 (or 2) byte(s) where the bits are not all null, then the value of Le is equal to the value of the byte(s) which lies in the range from 1 to 255 (or 65535); the null value of all the bits means the maximum value of Le: 256 (or 65536).

The first 4 cases apply to all cards.

Case 1 – L=0 : the body is empty.

• No byte is used for Lc valued to 0
• No data byte is present.
• No byte is used for Le valued to 0.

Case 2S – L=1

• No byte is used for Lc valued to 0
• No data byte is present.
• B1 codes Le valued from 1 to 256

Case 3S – L=1 + (B1) and (B1) != 0

• B1 codes Lc (=0) valued from 1 to 255
• B2 to Bl are the Lc bytes of the data field
• No byte is used for Le valued to 0.

Case 4S – L=2 + (B1) and (B1) != 0

• B1 codes Lc (!=0) valued from 1 to 255
• B2 to Bl-1 are the Lc bytes of the data field
• Bl codes Le from 1 to 256

For cards indicating the extension of Lc and Le (see 8.3.8 card capabilities), the next 3 cases also apply.

Case 2E – L=3 and (B1)=0

• No byte is used for Lc valued to 0
• No data bytes is present
• The Le field consists of the 3 bytes where B2 and B3 code Le valued from 1 to 65536

Case 3E – L=3 + (B2||B3). (B1)=0 and (B2||B3)=0

• The Lc field consists of the first 3 bytes where B2 and B3 code Lc (!=0) valued from 1 to 65536
• B4 and B2 are the Lc bytes of the data field
• No byte is used for Le valued to 0

Case 4E – L= 5 + (B2||B3),(B1)=0 and (B2||B3)=0

• The Lc field consists of the first 3 bytes where B2 and B3 code Lc (!=0) valued from 1 to 65535
• B4 to Bl-2 are the Lc bytes of the data field
• The Le field consists of the last 2 bytes Bl-1 and Bl which code Le valued from 1 to 65536

For each transmission protocol defined in part 3 of ISO/IEC 7816 an annex attached to this part (one per protocol) specifies the transport of the APDUs of a command-response pair for each of the previous 4 cases.

5.3.3 Response APDU

Illustrated by figure 6 (see also table 7), the response APDU defined in this part of ISO/IEC 7816 consists of

• a conditional body of variable length
• a mandatory trailer of 2 bytes (SW1 SW2)

The number of bytes present in the data field of the response APDU is denoted by Lr.

The trailer codes the status of the receiving entity after processing the command-response pair.

NOTE – If the command is aborted, then the response APDU is a trailer coding an error condition on 2 status bytes.

5.4 Coding conventions for command headers, data fields and response trailers

5.4.1 Class byte
5.4.2 Instruction byte

Table 6 shows the contents of the command APDU.

Table 6 – command APDU contents

Table 7 shows the contents of the response APDU.

Table 7 – response APDU contents

The subsequent clauses specify coding conventions for the class byte, the instruction byte, the parameter bytes, the data field bytes and the status byte. Unless otherwise specified, in those bytes, RFU bits are coded zero and RFU bytes are coded ’00’.

5.4.1 Class byte

According to table 8 used in conjunction with table 9, the class byte CLA of a command is used to indicate

• to what extent the command and the response comply with this part of ISO/IEC 7816
• and when applicable (see table 9), the format of secure messaging and the logical channel number.

Table 8 – Coding and meaning of CLA

Table 9 – Coding and meaning of nibble ‘X’ when CLA=’0X’,’8X’,’9X’ or ‘AX’

5.4.2 Instruction byte

The instruction byte INS of a command shall be coded to allow transmission with any of the protocols defined in part 3 of ISO/IEC 7816. Table 10 shows the INS codes that are consequently invalid.

Table 10 – Invalid INS codes

Table 11 shows the INS codes defined in this part of ISO/IEC 7816. When the value of CLA lies within the range from ’00’ to ‘7F’, the other values of INS codes are to be assigned by ISO/IEC JTC 1 SC17.

Table 11 – INS codes defined in this part of ISO/IEC 7816

5.4.3 Parameter bytes

The parameter bytes P1-P2 of a command may have any value. If a parameter byte provides no further qualification, then it shall be set to ’00’.

5.4.4 Data field bytes

Each data field shall have one of the following three structures.

• Each TLV-coded data field shall consist of one or more TLV-coded data objects.
• Each non TLV-coded data field shall consist of one or more data elements, according to the specifications of the respective command.
• The structure of the proprietary-coded data fields is not specified in ISO/IEC 7816.

This part of ISO/IEC 7816 supports the following two types of TLV-coded data objects in the data fields :

• BER-TLV data objects
• SIMPLE-TLV data object

ISO/IEC 7816 uses neither ’00’ nor ‘FF’ as tag value.

Each BER-TLV data object shall consists of 2 or 3 consecutive fields (see ISO/IEC 8825 and annex D).

• The tag field T consists of one or more consecutive bytes. It encodes a class, a type and a number.
• The length field consists of one or more consecutive bytes. It encodes an integer L.
• If L is not null, then the value field V consists of L consecutive bytes. If L is null, then the data object is empty: there is no value field.

Each SIMPLE-TLV data object shall consist of 2 or 3 consecutive fields.

• The tag field T consists of a single byte encoding only a number from 1 to 254 (e.g. a record identifier). It codes no class and no construction-type.
• The length field consists of 1 or 3 consecutive bytes. If the leading byte of the length field is in the range from ’00’ to ‘FE’, then the length field consists of a single byte encoding an integer L valued from 0 to 254. If the leading byte is equal to ‘FF’, then the length field continues on the two subsequent bytes which encode an integer L with a value from 0 to 65535.
• If L in not null, then the value field V consists of consecutive bytes. If L is null, then the data object is empty: there is no value field.

The data fields of some commands (e.g. SELECT FILE ), the value fields of the SIMPLE-TLV data object and the value field of the some primitive BER-TLV data objects are intended for encoding one or more data elements.

The data fields of some other commands (e.g. record-oriented commands) and the value fields of the other primitive BER-TLV data objects are intended for encoding one or more SIMPLE-TLV data objects.

The data fields of some other commands (e.g. object-oriented commands) and the value fields of the constructed BER-TLV data objects are intended for encoding one or more BER-TLV data objects.

NOTE – Before between or after TLV-coded data objects, ’00’ or ‘FF’ bytes without any meaning may occur (e.g. due to erase or modified TLV-coded data objects).

5.4.5 Status bytes

The status bytes SW1-SW2 of a response denote the processing state in the card. Figure 7 shows the structural scheme of the values defined in this part of ISO/IEC 7816.

F I G U R E 7

Figure 7 – Structural scheme of status bytes

NOTE – When SW1=’63’ or ’65’, the state of the non-volatile memory is changed. When SW1=’6X’ except ’63’ and ’65’, the state of the non-volatile memory is unchanged.

Due to specifications in part 3 of ISO/IEC 7816, this part does not define the following values of SW1-SW2 :

• ’60XX’
• ’67XX’, ‘6BXX’, ‘6DXX’, ‘6EXX’, ‘6FXX’; in each case if ‘XX’!=’00’
• ‘9XXX’, if ‘XXX’!=’000′

The following values of SW1-SW2 are defined whichever protocol is used (see examples in annex A).

• If a command is aborted with a response where SW1=’6C’, then SW2 indicates the value to be given to the short Le field (exact length of requested data) when re-issuing the same command before issuing any other command.
• If a command (which may be of case 2 or 4, see table 4 and figure 4) is processed with a response where SW1=’61’, then SW2 indicates the maximum value to be given to the short Le field (length of extra data still available) in a GET RESPONSE command issued before issuing any other command.

NOTE – A functionality similar to that offered by ’61XX’ may be offered at application level by ‘9FXX’. However, applications may use ‘9FXX’ for other purposes.

Table 12 completed by tables 13 to 18 shows the general meanings of the values of SW1-SW2 defined in this part of ISO/IEC 7816. For each command, an appropriate clause provides more detailed meanings.

Tables 13 to 18 specify values of SW2 when SW1 is valued to ’62’, ’63’, ’65’, ’68’, ’69’ and ‘6A’. The values of SW2 not defined in tables 13 to 18 are RFU, except the values from ‘F0’ to ‘FF’ which are not defined in this part of ISO/IEC 7816.

Table 12 – Coding of SW1-SW2