| Eurocrypt informations | ISO 7816 Answer to reset |
Information on ISO 7816/3 & 4 by JC
last updated : 29-Dec-96
In this text I will attempt to outline the structure to the Answer To Reset (ATR) from a Smartcard as defined in the ISO protocol. At this point it is worth mentioning that 7816/4 adds further dimensions to the ISO protocol in terms of software and communication with the card. Most of the 7816/4 directives are intended to increase the possibilities of card management; the cards complying with 7816/3 are a subset of such directives.
In contact smartcards (those with electrical contacts visible) it is necessary for bi-directional communication to be established. This is done by a reset pulse from the terminal on the reset line in which the card has been inserted. If a microprocessor is present on the smartcard, it will return the ATR via the I/O line so that the application terminal can correctly identify the card.
Command instructions are set into the CPU during the manufacturing process. Later, in the application environment, the card will act on valid instructions and ignore those not preprogrammed, although it is likely that invalid instructions can become trigger mechanisms to protect the data therein.
It is not necessary to determine the command instructions from the CPU unless executable code is to be introduced into the card. As there are only a few manufacturers of chips for cards a Smart Card Operating System (SCOS) was developed. SCOS commands include orders to open, read, write, or erase files, just like any other operating system. The SCOS also features other specialized commands such as access control to records through keys or PINs, message certification, and communication with the outer world. Moreover, the SCOS may be used to develop applications. Again, this feature is used chiefly by manufacturers, but is seldom available to issuers or users. For example, encryption and decryption data algorithms may be developed as SCOS applications and included in ROM or UAM memory.
The ATR is a maximum of 33 bytes, TS as the initial byte. Following a successful ATR the terminal may ask the card about any specific protocol for further communication. The card will respond with another string called Protocol Type Selection (PTS), which contains the requested information. If the card does not respond with the PTS, the terminal will assume the former parameters and protocol in all further communications during that session.
The main ATR characters are :
| Name | Number | Function | Presence |
|---|---|---|---|
| TS | 1 | Initial Character | Mandatory |
| T0 | 1 | Format Character | Mandatory |
| TA,TB,TC,TD, ... | <= 15 | Interface Characters | Optional |
| T1,T2,...,TK | <=15 | Historical Characters | Optional |
| TCK | 1 | Check Character | Conditional |
In the ATR response, each byte is made up of 10 bits - a start bit, eight data bits, and a stop bit.
In order to explain TS correctly I will assume high and low voltage levels of A and B respectively, although a high voltage level need not be logic level 1. Prior to a character transmission, the I/O line must be at B (i.e. high) state. The start bit must be at A (low). After sending a character (not only TS) the I/O line goes to B state and waits at least the time corresponding to two bits. Then the I/O line is ready to send the next character.
The first character TS is of most importance since it contains information on logic conventions and transmission rate. As no transmission rate has been established before TS, the card must accept a frequency of between 1 and 5 Mhz.
The elementary time unit (etu) is defined as the time for the transmission of a bit in I/O operations. If the card has an internal clock, the initial etu is 1/9600 sec, which relates to a serial baud rate of 9600 BPS. If there is no internal clock, the initial etu is 372/f, where f is the frequency provided by the clock on the terminal. An external clock of 3.57 Mhz is usually used in the terminal for two reasons :
I wont bore you with the calculations that provide the ONLY two expected values for TS in asynchronous communication - namely 3B and 3F. 3B relates to direct convention and 3F relates to inverse convention.
The second character in the ATR is T0, or the format character. It is mandatory and gives information on the presence and number of subsequent (optional) ATR characters. To do this, T0 is split into two nibbles. The most significant nibble (MSN) is called Y and indicates the presence or absence of interface characters. The least significant nibble (LSN) is called K and indicates the number of historical characters, if any. The two nibbles work differently. K can be treated as a binary number (0 to 15) which tells of the number of historical characters present. Y on the other hand is treated as four separate digits which indicate the presence or absence of TA, TB, TC and TD with TD defined by the MSB.
Example.
T0 is 58. Y = 5, K = 8.
K tells us that there are 8 historical characters present. Y is 0101 which tells us that TA and TC are present and that TB and TD are absent.
This process continues for the maximum number of 15 interface characters. TD is split in each iteration to determine the further presence of interface characters. The LSN of TD (called T) is important as it contains the protocol type for subsequent transmission :
If TD is NOT sent, T = 0 is used by default.
TA, TB, TC and the second TB if present are used to define transmission parameters F, D, I, P, and N for the working etu. Defaults for these values are :
If anyone wants, I will provide the equations for each of the above values at their request.
Historical characters have been traditionally used by manufacturers to specify information such as IC, memory size, ROM mask version, SCOS version, memory areas, and the number of failed accesses of their cards.
TCK is the check character, which must be the last character of ATR in all cases, except when T = 0 is the only protocol type employed by the card; then TCK is NOT sent. The value of a TCK data byte shall be such that an XOR performed on all bytes from TS to TCK would be zero.
7816/3 dictates that ISO cards should be addressed by a 5 byte header from the terminal. These relate to CLA, INS, P1, P2, and P3. At times, there may be errors in addressing the card and in those instances the card responds to the terminal with two bytes, SW1 and SW2 informing it of the error.
A summary of these are :
| SW1 | SW2 | Meaning |
|---|---|---|
| 90 | 00 | Command executed OK |
| 62 | 81 | Returned data may be corrupted |
| 62 | 82 | The end of the file has been reached before the end of reading |
| 62 | 84 | Selected file is not valid |
| 65 | 01 | Memory failure. There have been problems in writing or reading the EEPROM. Other hardware problems may also bring about this error |
| 67 | 00 | The command length is not correct |
| 68 | 00 | he request function is not supported by the card |
| 69 | 00 | Unknown command. The instruction is not recognized; most probably it is a problem of erroneous typing, protocol violation, or incorrect format. Some instructions included in the T = 0 description included in ISO 7816/4 are not known by this card |
| 6A | 00 | Bytes P1 and/or P2 are incorrect |
| 6A | 80 | The parameters in the data field are incorrect |
| 6A | 82 | File not found |
| 6A | 83 | Record not found |
| 6A | 84 | There is insufficient memory space in record or file |
| 6A | 87 | The P3 value is not consistent with the P1 and P2 values |
| 6A | 88 | Referenced data not found |
| 6C | XX | Incorrect P3 length |
| 6D | XX | Wrong instruction code |
| 6E | XX | The instruction class is not supported by this card |
| 6F | XX | Generic error. An error has been detected, but a precise diagnosis cannot be given |
SW1 can be grouped into 4 main categories as defined in 7816/3 :
Hope this helps. Regards.
JC.