The T = 0 transmission protocol
The T=0 transmission protocolwas first used in France during the initial development of smart cards, and itwas also the first internationally standardized smart card protocol. Itwas generated in the early years of smart card technology, and it is thus designed for minimum memory usage and maximum simplicity. This protocol is used worldwide in GSM cards, which makes it the most widely used of all current smart card protocols. The T = 0 protocol is standardized in ISO/IEC 7816-3. Additional compatible specifications are contained in the GSM 11.11, TS 102.221 and EMV specifications. The T = 0 protocol is byte-oriented, which means that the smallest unit processed by the protocol is a single byte. The transmission data unit consists of a header containing a class byte, a command byte and three parameter bytes, optionally followed by a data section. In contrast to the application protocol data unit (APDU) specified by ISO/IEC 7816-4, length information is provided only by parameter P3. This indicates the length of the command data or response data. It is also specified by the ISO/IEC 7816-3 standard. Due to the byte orientation of the T = 0 protocol, if a transmission error is detected, retransmission of the incorrect byte must be requested immediately. With block protocols, by contrast, an entire block (a sequence of bytes) must be retransmitted if an error occurs. Error detection with T = 0 is based exclusively on a parity bit appended to each sent byte. If the recipient detects a transmission error, it must set the I/O line to a low level for the duration of one etu starting halfway through the first bit interval of the guard time of the faulty byte. This indicates to the other party that the most recent byte must be retransmitted. This byte repetition mechanism is very simple, and it has the advantage that it is selective, since only incorrect bytes have to be repeated. Unfortunately, this mechanism suffers from a severe disadvantage. Most interface ICs treat the etu interval as the smallest detectable unit, so they cannot recognize a low level on the I/O line that is set halfway through a stop bit. Standard interface ICs are thus not suitable for the T = 0 protocol. However, if each bit is received separately by software, this is not a problem.

The T = 0 protocol also allows an external programming voltage for the EEPROM or EPROM to be switched on or off. This is done by adding 1 to the received command byte and sending it back to the terminal as an acknowledge byte. This is why only even-valued command bytes are permitted, since otherwise this mechanism would not work. However, switching an external programming voltage is technically obsolete, since all smart card microcontrollers now generate the programming voltage in the chip itself. We thus need not discuss this topic any further. To illustrate the T = 0 command–response sequence, let us assume that the terminal sends the card a command with a data section, and the card responds with data and a return code (see Figure 6.28). The terminal first sends the card a 5-byte command header, consisting of a class byte, a command byte and the P1, P2 and P3 bytes. If this is received correctly, the card returns an acknowledgement (ACK) in the form of a procedure byte (PB). This acknowledgement is coded the same as the received command byte. On receipt of the procedure byte, the terminal sends exactly the number of data bytes indicated by the P3 byte. Now the card has received the complete command, and it can process it and generate a response. If the response contains data in addition to the 2-byte return code, the card informs the terminal of this via a special return code, with the amount of data indicated by SW2. After receiving this response, the terminal sends the card a GET RESPONSE command, which consists only of a command header and an indication of the amount of data to be sent. The card now sends the terminal the requested amount of data generated in response to the first command, with the appropriate return code. This completes one command sequence. If a command is sent to the card and the card only generates a return code with no data section, the GET RESPONSE portion of Figure 6.28 does not occur. Since an additional command from the application layer is needed to perform this action (fetching data related to a previous command), there is naturally no longer strict separation between the protocol layers. An application-layer command (GET RESPONSE) must be used here to support the data link layer, which has certain effects on the application in question. The maximum interval between the leading edges of two successive bytes is designated the work waiting time. This is coded in data element TC2 of the ATR. The primary function of the guard time is to separate individual bytes during the transmission. This gives the sender and the recipient more time to perform the functions of the transmission protocol.

If the smart card returns a procedure byte containing the null value (’60′) to the terminal, this does not have any effect on the actual sequence of the protocol, but it does inform the terminal that the smart card is still processing the last command that it received. Sending a null value can thus be used as a sort of waiting time extension (WTX), although it is not standardized in this form. The T = 0 protocol allows the card to receive the bytes in the data section individually after it has received the header. To do so, it only has to send the inverted command byte to the terminal as a procedure byte, whereupon the terminal will send a single data byte. The next data byte follows the next procedure byte from the card. This bytewise transmission can continue until the card has received all the bytes in the data section, or until it sends the non-inverted command byte to the terminal as a procedure byte. Upon receiving the non-inverted command byte, the terminal sends all the remaining data bytes to the card, which will have then received the complete command. There are two incompatibilities here between GSM 11.11 and ISO/IEC 7816-3. The first is that according to the GSM standard, a GET RESPONSE command is requested using SW1 =’9F’, while according to the ISO/IEC standard the usual value is’61′.11 In each case, SW2 contains the amount of data to be fetched. The second incompatibility between the two standards relates to the manner in which data is fetched using GET RESPONSE. The manner described above corresponds to theGSMstandard and is representative for the majority of smart card applications throughout the world. According to the ISO/IEC standard, a certain amount of data can be fetched using GET RESPONSE, but there is no marker to allow subsequent data packets to be requested one after the other.With the ISO/IEC standard, GET RESPONSE always starts with the first byte. These two incompatibilities can be easily handled in the terminal by suitable software. The important thing is to be aware that they exist. With a transmission protocol, the primary concerns of the user are ultimately only the data transmission rate and the error detection and correction mechanisms. Transmitting an 8-bit byte requires sending 12 bits, including one start bit, one parity bit and two etu for the guard time. Transmitting one byte thus takes 12 etu, which is equivalent to 1.25 ms with a 3.5712-MHz clock frequency and a divider value of 372. Table 6.33 lists data transmission times for some typical commands. The data transmission rate naturally drops if transmission errors occur. However, the singlebyte repetition mechanism is very advantageous here, since only incorrectly received bytes have to be retransmitted.

The error detection mechanism of the T = 0 protocol consists only of a parity check at the end of each byte. This allows reliable recognition of single-bit errors, but two-bit errors cannot be detected. Furthermore, if a byte is lost during the transmission from the terminal to the card, this results in an endless loop (deadlock) in the card, since it is expecting a specific number of bytes and has no possibility of timing out. The only practical way for the terminal to escape from this situation is to reset the card and establish communications again from the beginning. There is a very similar situation when the terminal is expecting more data than the smart card sends. This also unavoidably leads to a deadlock. For this reason, some implementations of the T = 0 protocol in terminals have a timer that triggers termination of communications after a configurable maximum interval. The mechanism used for this is similar to that for the block waiting time (BWT) with the T = 1 protocol. However, it is not standardized and is thus implementation-dependent. In normal communications, the insufficient separation of the link and transport layers does not cause any major problems. The smooth operation of the GSM application is the best proof of this. However, problems quickly arise if secure messaging is used. With a partly encrypted header and a fully encrypted data section, it is no longer possible to support the T = 0 protocol using the previously described procedure without incurring large overheads. This is because the unencrypted command byte must be used for the procedure byte in the T = 0 protocol. However, this fact has been recognized by the standards organizations and is taken into account in the standards related to secure messaging, so all varieties of secure messaging are possible using the T = 0 protocol. Due to the absence of layer separation and the obvious problems in the event of a bad connection, the T=0 protocol is often considered to be outdated. However, transmission errors almost never occur in communications between the terminal and the card. The main advantages of the T=0 protocol are its good average transmission rate, minimal implementation overhead and widespread use.