Smart Card Protocols and ISO 7816-4
The previous chapter discussed the answer-to-reset (ATR) mechanism, which establishes a basic communication channel between the smart card and the reader. This channel is a half-duplex physical channel. This chapter investigates the use of more complex protocols on top of this physical channel.
A link-level communication protocol resides directly on top of the physical channel, providing error-free communication between the reader and the smart card. Once this link level protocol is established, application-level protocols can be defined. ISO 7816-4 defines two such application-level protocols:
- File system API providing a set of functions to manipulate files (e.g. read, write, select etc.)
- Security service API allowing the smart card and the reader to mutually authenticate themselves and also to encrypt data to be exchanged between the card and the reader.
ISO 7816-4 defines a protocol message structure to support the application protocol APIs. This message structure consists of application protocol data units (APDUs) which are exchanged between the reader application and the smart card application by the link level protocol. This chapter will provide an overview of the file access and security APIs. A more detailed description can be found in Appendix A, "The ISO 7816-4 Command set".
1. Link Level Protocols
The Open Systems Interconnection (OSI) Reference Model describes the communication between two parties in terms of seven distinct protocols that are layered on top of one another as shown in Figure 5.1. The protocol layers are strictly separated from one another. Consequently, each layer may only communicate with the layer directly above or below it through a well-defined set of services.
Figure 5.1: The OSI Reference Model.
The T=1 smart card protocol fits well into the data link protocol layer of the OSI Reference Model. However, the T=0 protocol includes elements from several layers of the model and so does not provide a clear separation between the link layer and the application layer. Consequently, it is an awkward task to provide any intervening protocol layers on top of the T=0 protocol. An example of an intermediate protocol is secure messaging, where cryptographic techniques are used to encrypt data so that only the application elements on each end of the communication channel can understand the information exchanged.
The T=0 protocol was designed to optimise the efficiency of the communication between the card and the reader. Consequently, the error handling and application protocol support were designed to minimise the amount of information flowing between the reader and the card and thereby reduce the transaction time. This resulted in the poor protocol layering of the T=0 protocol.
1.1 The T=0 Protocol
The T=0 protocol is a byte-oriented protocol where a character is transmitted across the channel between the reader and the card. In addition, error handling is performed on each byte by looking at the parity bit. If the actual parity bit does not correspond to the parity of the transmitted data, then an error must have occurred. In the T=0 protocol, the receiving side signals that it requires the byte to be retransmitted in the case of detecting a parity error. This is done by holding the I/O line low (normally the I/O line is set high preceding the transfer of a byte). When the transmitting side detects this, it resends the byte that was previously received in error.
The reader and the smart card exchange data structures known as transmission protocol data units (TPDUs). The TPDUs used in the T=0 protocol differ from those used in the T=1 protocol. The TPDU for the T=0 protocol consists of two distinct structures:
- a command that is sent from the reader to the card and
- a response that is sent from the card to the reader.
The command header includes the following five fields each one byte in length:
- CLA: class designation of the command set to establish a collection of instructions
- INS: specifies a specific instruction from within the set of instructions
- P1: used to specify the addressing used by the [CLA, INS] instruction
- P2: also used to specify the addressing used by the [CLA, INS] instruction
- P3: specifies the number of data bytes transferred to or from the card as part of the [CLA, INS] instruction execution.
Each value of CLA defines an application-specific set of instructions. Table 4.1 below lists values for some sets of instructions.
| CLA Byte |
Instruction Set |
| 0X |
ISO 7816-4 instructions (files and security) |
| 10 to 7F |
Reserved for future use |
| 8X or 9X |
ISO 7816-4 instructions |
| AX |
Application/vendor specific instructions |
| B0 to CF |
ISO 7816-4 instructions |
| D0 to FE |
Application/vendor specific instructions |
| FF |
Reserved for protocol type selection |
Table 5.1: CLA instruction set definitions [2].
The INS byte is used to identify a specific instruction within a class of instructions identified by the value of CLA. Table 5.2 lists the instructions in the ISO 7816-4 standard used access file system and security functions.
| INS Value |
Command Name |
INS Value |
Command Name |
| 0E |
Erase Binary |
C0 |
Get Response |
| 20 |
Verify |
C2 |
Envelope |
| 70 |
Manage Channel |
CA |
Get Data |
| 82 |
External Authenticate |
D0 |
Write Binary |
| 84 |
Get Challenge |
D2 |
Write Record |
| 88 |
Internal Authenticate |
D6 |
Update Binary |
| A4 |
Select File |
DA |
Put Data |
| B0 |
Read Binary |
DC |
Update Record |
| B2 |
Read Record(s) |
E2 |
Append Record |
Table 5.2: ISO 7816-4 INS codes [2].
The parameters P1 and P2 are defined at the link level but are actually dependent on the specific instruction (application level). They provide control or addressing parameters for the various application-specific instructions. For example, in the Select File instruction, P1 is used to indicate how the file will be referred to (by identifier, name, path etc.) and P2 offers further refinement as to which file is to be selected. P3 defines the number of bytes to be transmitted during the execution of the INS specified instruction. The convention used to indicate movement of data is card-centric i.e. outgoing refers to data moving from the card to the reader and incoming refers to data moving from the reader to the card.
For each command TDPU sent from the reader, a response TPDU is sent by the card. The response includes three mandatory fields and one optional field (all one byte in length):
- ACK: indicates that the card has received the [CLA, INS] command
- NULL: used for flow control on the I/O channel by the card. It signals (to the reader) that the card is still processing the command and so the reader must wait before sending another command
- SW1: status response of the current command
- SW2: (optional) also conveys a status response to the reader
The ACK byte is a repeat of the INS byte from the command TPDU. If the response does not reach the reader within a specified time, the reader may initiate a RST sequence to restart the protocol between the reader and the card. This can be prevented if the reader receives at least one NULL byte from the card. SW1 informs the reader of the result of the requested instruction. The values allowed for SW1 are defined as part of the application protocol. Some instructions require the card to send data to the reader. In this case SW2 is returned to the reader, triggering the reader to execute a GetResponse command. The card will then return the data bytes generated by the execution of the previous command.
1.2 The T=1 Protocol
The T=1 protocol is a block-oriented protocol in which a well-defined collection of data or a block is moved as a unit between the reader and the card. This block may incorporate an application-specific APDU providing an example of the distinct layering between the link and application protocol layers. However, the error detection and correction is more complex than that used in the T=0 protocol.
Error detection is performed using either a longitudinal redundancy character which, is a more complex form of parity checking that that used in T=0 protocol or a cyclic redundancy check character that is guaranteed to detect single-bit errors in a transmitted block. The receiving end of the channel signals the transmitting end to resend a block when it detects an error within the block.
The T=1 protocol uses three types of blocks:
- Information block: Used to exchange data between application software on the card and application software on the reader side of the channel.
- Receive ready block: Used for positive and negative acknowledgements. A positive acknowledgement indicates that the block was correctly received. Whereas a negative acknowledgement indicates that an error was detected in the block received
- Supervisory block: Used to transfer control information between the reader and the card
Each T=1 block comprises of three fields:
- Prologue field: Mandatory field with a size of three bytes including the following three elements:
- NAD: Node Address is used to identify the addresses of the source and the intended destination of the block.
- PCB: Protocol Control Byte is used to indicate the type of block (either information, receive ready or supervisory)
- LEN: Length of the block
- Information field: Optional field that may be up to 254 bytes in length and may contain an APDU
- Epilogue field: Mandatory field that is either 1 or 2 bytes in length and is used for error detection
2. Application level Protocols
The ISO 7816-4 standard addresses two areas of functionality for application software:
- File system: A set of functions is provided in the form of an API. By using this API application software on the reader side can access files in the file system.
- Security functions: These can be used to limit access to application software or to files on the card.
The T=0 or T=1 protocols are used to support application-level protocols between the smart card application and the reader application. These application protocols exchange data structures called application protocol data units (APDUs). The following diagram illustrates this architecture:
Figure 5.2: Application communication architecture [2].
The APDU structure defined by ISO 7816-4 is very similar to the TPDU structure used in the T=0 protocol. In fact, when an APDU is transported by the T=0 protocol, the elements of the APDU directly overlay the elements of the TPDU.
2.1 The ISO 7816-4 APDU
There are two types of messages used to support the ISO 7816-4 application protocols: the command APDU (sent from the reader to the card) and the response APDU (sent from the card to the reader).
Figure 5.3: The command APDU structure.
The command APDU consists of a header and a body (this can be seen in the diagram above). The header includes CLA, INS, P1 and P2 fields. As in the T=0 protocol, CLA and INS specify an application class and instruction. P1 and P2 are used to qualify specific instructions and are given specific definitions by each [CLA, INS] instruction. The body of the APDU can vary in size and is used to transmit data to the card's APDU processor as part of a command or to convey a response from the card to the reader. The Lc field specifies the number of bytes to be transmitted to the card as part of the instruction i.e. the length of he data field. The data field contains information that must be sent to the card to allow its APDU processor to execute the command specified in the APDU. The Le field specifies the number of bytes that will be returned to the reader in the response APDU.
The body of the APDU can take on four different forms:
- Case 1: No data is transferred to or from the card, so the APDU only contains the header.
- Case 2: No data is transferred to the card, but data is returned from the card. The body of the APDU only contains a non-null Le field.
- Case 3: Data is transferred to the card, but none is returned from it. The body of the APDU includes the Lc and data fields.
- Case 4: Data is transferred to the card and is also returned from the card as a result of the command. The body of the APDU includes the Lc, data and Le fields.
Figure 5.4: The response APDU structure.
The response APDU has a much simpler structure than that of the command APDU. It consists of a body and a trailer. The body is either null or it includes a data field - depending on the specific command. The length of the data field is determined by the Le field in the corresponding command APDU. The trailer consists of up to two fields of status information called SW1 and SW2. These fields return a status code in which one byte is used to specify an error category and the other is used to specify a command-specific status or error indication.
2.2 The File System API
The file system is used on the nonvolatile memory or EEPROM. It is defined as a simple hierarchical structure (similar to conventional file systems). The file system may contain three types of files (identified by a 2-byte identifier):
- Master file (MF)
- Dedicated file (DF)
- Elementary file (EF)
There is one master file found on each smart card and it is the root of the file system. A master file may contain dedicated files or elementary files. The file identifier reserved for the master file is 3F00. The directory file is essentially a container (or directory) for elementary files - a DF may contain zero or more EFs. Dedicated files partition the smart card into an ordered structure of elementary files. A dedicated file must be given a unique file identifier within the dedicated file or master file that contains it - allowing for a unique path for each file. A dedicated file can also be referenced by name (1-16 bytes long). The naming convention can be found in ISO 7816-5. An elementary file is a leaf node in the hierarchy and contains the actual data. An elementary file can be identified by a 5-bit identifier within a dedicated file. This file system hierarchy is illustrated in Figure 5.5.
Figure 5.5: The smart card file system architecture [2].
There are four types of elementary files:
- Transparent file
- Linear, fixed-length record file
- Linear, variable-length record file
- Cyclic, fixed-length record file
A transparent file is essentially a string of bytes i.e. an unstructured binary file. Consequently a byte offset from the start of the file is required when data is to be read or written to this type of file. In addition, a command to read or write to a transparent file will contain the length of the byte string to be read or written to the file.
Fixed and variable length files contain records that are identified by a sequence number. In a fixed-length record file, all the records contain the same number of bytes. In contrast, a variable-length record file contains records that may vary in length. As a result, variable-length record files have a higher overhead in read/write access times as well as a higher administrative overhead required by the file system.
A cyclic file allows applications to access records in a consistent and transparent manner. It can be thought of as a ring of files. Write operations are performed on the next physical record in the ring.
The few functions that are defined in ISO 7816-4 for selecting, reading and writing to files will be briefly discussed below. These commands are presented in more detail in Appendix A.
Select File:
This command establishes a logical pointer to a particular file in the smart card's file system. This pointer is required for any file manipulation operations. Access to the smart card's file system is not multithreaded, however it is possible to have several file pointers defined at any point in time. This is accomplished by the Manage Channel command, which establishes multiple logical channels between the reader side application and the card. This allows different files on the card to be in various states of access by the reader application at the same time.
The identification of the file can be provided in the following ways:
- file identifier (2-byte value)
- DF name (string of bytes)
- path (concatenation of file identifiers)
- short ID
Note that not all smart cards support all four naming mechanisms.
Read Binary:
This command is used by the application on the reader side to retrieve a part of an EF on the card. However, the EF must be a transparent file (not record-oriented). If the Read Binary command is attempted on a record-oriented EF, the command will abort with an error indicator being returned from the card.
The Read Binary command takes two parameters: an offset pointer from the start of the file to the initial byte to be read, and the number of bytes to be read and returned to the reader.
Write Binary:
This command is used to insert data into a transparent EF on the card. This command can be used to set a series of bytes in the EF (i.e. set selected bits within a specified byte to a value of 1), clear a series of bytes or perform a write of a series of bytes in the EF.
Update Binary:
A reader-side application can utilise this command to directly erase and store a contiguous sequence of bytes in a transparent EF on the card. It effectively functions as a write command i.e. a string of bytes provided in the command are written into the EF on the card. The input parameters consist of an offset pointer from the start of the file as well as the number of bytes to be written.
Erase Binary:
The Erase Binary command is used to clear bytes within a transparent EF on a card. Similarly to the previous commands, the input parameters comprise an offset from the start of the EF to the segment of bytes to be erased as well as the number of bytes to be erased.
Read Record:
This command is used to read and return the contents of one or more records in an EF on a card. Unlike the previous command, the EF for the Read Record command must be a record-oriented file. If it is applied to a transparent EF, the command will abort and an error will be returned to the reader.
The following may be returned from this command, depending on the input parameters:
- A specified record
- All the records from the beginning of the file to a specific record
- All the records from a specific record to the end of the file
Write Record:
This command is used to write a record into a record-oriented EF. As with the Write Binary command, this command can be used to write a record into an EF, set or clear specific bits within a specific record in an EF. Some addressing shortcuts to specify the record to be written to include the first or last record in an EF, the next or previous record in an EF or a specific record within an EF identified by a number.
Append Record:
The Append Record command is used to add a record to the end of a linear, record-oriented EF or to write the first record to a cyclic, record-oriented EF on a card.
Update Record:
This command writes a specific record into a record-oriented EF on a card. As with the Update Binary command, the old record is erased and the new one is written into the EF.
Get Data:
This command reads and returns the contents of a data object stored within the file system on the card. The Get Data command is card-specific as the definition of a data object varies between different cards.
Put Data:
This command (as the name suggests) puts information into a data object on the card. As with the previous command, this is a card-specific command.
2.3 The Security API
Each component of the file system on a smart card has an associated list of access properties. The access properties ensure that only authorised parties are allowed to access the particular component of the file system. The authentication can be simple, such as requiring the reader to provide a predefined personal identification number (PIN). Alternatively, it may be more complicated, such as requiring the reader to prove that it possess some shared secret with the card (e.g. a key) by encrypting or decrypting a string of bytes provided by the card.
A few of the functions provided by the security API are briefly discussed below.
Verify:
This command is sent by the application on the reader side to the security system on the card. Its purpose is to convince the card that the reader knows a password maintained by the card in order to restrict access to sensitive information stored on the card. The password-type information may be associated with a specific file or to some or all of the file hierarchy. If the Verify command fails i.e. the reader provides an incorrect password, an error is returned to the reader.
Internal Authenticate:
This command allows the card to authenticate itself to the reader by proving that it possesses a secret key shared with the reader. The reader application software first generates a random number and encrypts it with some algorithm known to both card and reader. This constitutes a challenge to the card. The card then decrypts this challenge with the secret key (that is stored on the card) and sends the resulting data back to the reader. If the data received by the reader matches the random number that it generated then the reader application software is assured of the identity of the card.
External Authenticate:
This command is used in conjunction with the Get Challenge command to enable the reader application software to authenticate itself to the card. The reader receives challenge data (a random number) from the card and encrypts it with a secret key. This is then sent to the card using the External Authenticate command. The card decrypts the data and compares it to the random number that it generated in the previous Get Challenge command. If there is a match, then the card is assured of the identity of the reader application.
Get Challenge:
This command is sent by the reader to the card. Its purpose is to provide the reader application with a random number generated by the smart card. As previously described, this number is used in the External Authenticate command.
Manage Channel:
The Manage Channel command is used by the reader application to open and close the logical communication channels between it and the card. Initially the card opens a basic communication channel by establishes an application-level protocol with the reader application through the completion of an ATR sequence. This channel is then used to open or close additional logical channels through the Manage Channel command.
Envelope:
This command supports the use of secure messaging using the T=0 protocol. It enables an APDU to be encrypted and then incorporated into the Envelope command's data section (of its APDU). The APDU processor on the card can then extract and execute the command.
Get Response:
As with the previous command, the Get Response command allows the use of the T=0 protocol for transferring APDUs. The Case 4 type of APDU cannot be supported by the T=0 protocol i.e. it is not possible to send a block of data to the card and then receive a block of data in return. So when using the T=0 protocol, the initial command results in a response which indicates that more data is waiting to be sent by the card. The Get Response command is then used to retrieve this data.
