Previous Table of Contents Next


The poor protocol layering of the T=0 protocol is not the product of poor design. Rather, it is the result of an attempt to make the protocol as responsive as possible in order for communication between the reader and the card to be as efficient as possible. The data transmission speed across the reader-to-card interface is relatively slow (nominally 9600 bits per second) and this channel is in the critical path of all transactions that involve the card. To maximize consumer satisfaction, it is desirable that such transactions proceed as quickly as possible—instantaneously would be very nice. Consequently, in the T=0 protocol, the error handling and the application protocol support are optimized to minimize the amount of information which flows across the reader-to-card interface and thereby minimize the transaction time.

The T=0 Protocol

The T=0 protocol is a byte-oriented protocol. Like all other ISO-compliant smart card protocols, it functions in a command-response mode in which the reader-side of the connection issues a command to the card, which then performs the commanded operation and sends back a response.


Note:  
Byte-oriented means that a byte is the unit of information transferred across a channel and that error handling is handled one byte at a time as well.

In the T=0 protocol, error detection is done by looking at the (even) parity bit on each byte transferred across the reader-to-card interface. The transfer of each byte of information requires the use of 10 bits, as illustrated in Figure 4.2. The parity bit is cleared or set to make the total number of bits set (per character transferred) be an even number. The receiver side of the channel can look at the bit values transferred prior to the parity bit and determine whether the parity bit should be set. If the actual parity bit transferred does not match what was expected, then it can be assumed that an error exists in the byte of data just transferred and some recovery procedure must be undertaken. The recovery procedure used with the T=0 protocol is triggered by the receiving side, which, on detecting a parity error, signals that it expects the transmitting side to retransmit the byte (that was received in error). It provides the signal to the transmitting side by holding the I/O line in a low state. Normally, the I/O line is in a high state immediately preceding the transfer of a byte, so a low state acts as an error feedback signal to the transmitter. On detecting this, the transmitting side of the channel waits for at least two character times and then again sends the byte that was previously received in error.


Figure 4.2.  Reader/card byte transfer and error feedback loop.

Those well versed in communication protocols might see this error detection and recovery mechanism as being somewhat prone to less-than-perfect behavior. This indeed tends to be the case in actual practice. For most readers, however, the channel tends to be very good or very bad. If it’s very good, then this error detection and recovery mechanism is seldom used; if it’s very bad, then the error detection and recovery mechanism is likely to fail at some point. This leads to the transmitting and receiving sides of the channel getting out of synchronization. If this situation is detected by the card, it will usually be programmed to go mute and quit responding to commands from the reader. At this point, or if the reader detects the ambiguous state first, the reader issues a reset signal to the card that forces the communication protocol to be brought up from scratch.

The TPDU for the T=0 protocol comprises two distinct data structures: one that is sent from the reader to the card (as a command) and one that is sent from the card to the reader (as a response). The command header (sent from the reader to the card) includes five fields:

  CLA—A 1-byte field that establishes a collection of instructions; this is sometimes referred to as the class designation of the command set.
  INS—A 1-byte field that specifies a specific instruction (to the card) from within the set of instructions defined within the CLA designation; this is sometimes referred to as the instruction designation within the class of commands.
  P1—A 1-byte field used to specify the addressing used by the [CLA,INS] instruction.
  P2—A 1-byte field also used to specify the addressing used by the [CLA,INS] instruction.
  P3—A 1-byte field used to specify the number of data bytes transferred either to the card or from the card as part of the [CLA,INS] instruction execution.

The procedure bytes, which are sent from the card to the reader, are used to respond to the reader’s command and include three required fields and one optional field:

  ACK—A 1-byte field that indicates reception (by the card) of the [CLA,INS] command.
  NULL—A 1-byte field used by the card to essentially do flow control on the I/O channel; it sends the message from the card to the reader that the card is still working on the command and signals the reader not to send another command just yet.
  SW1—A 1-byte field used by the card to send a status response back to the reader regarding the current command.
  SW2—A 1-byte (optional) field that may be included in the procedure bytes, depending on the specific command being executed. If included, it also conveys a status response back to the reader.


Previous Table of Contents Next