The T = 1 transmission protocol
The T = 1 transmission protocol is an asynchronous half-duplex protocol for smart cards. It is based on the international ISO/IEC 7816-3 standard. The TS 102.221 and EMV specifications are also relevant for this protocol. The T=1 protocol is a block-oriented protocol, which means that one block is the smallest data unit that can be transmitted between the card and the terminal. This protocol features strict layer separation, and it can be assigned to the data link layer (transport layer) in the OSI reference model. In this context, layer separation means that data destined for higher layers, such as the application layer, can be processed completely transparently by the data link layer. It is not necessary for layers other than the ones directly involved to interpret or modify the contents of the transmitted data. Secure messaging (SM), in particular, requires adherence to layer separation. Only then can encrypted user data be passed across the interface without resorting to complicated procedures or tricks. The T=1 protocol is currently the only international smart card protocol that permits all varieties of secure data transmission without any compromises. The transmission protocol sequence starts after the card has sent theATRor after a successful PPS has been executed. The first block is sent by the terminal, and the next block is sent by the card. Communication then continues in this manner, with the transmit privilege alternating between the terminal and the card. Incidentally, the T = 1 protocol is not limited to being used for communication between smart cards and terminals. It is also used by many terminals to exchange application and control data with the computers to which they are connected. The data transmission rate is naturally of particular interest for any data transmission protocol. Table 6.34 lists the transmission times for some typical commands using the T = 1 protocol.

Block structure
The transmitted blocks are basically used for two different purposes. One of these is the transparent transmission of application-specific data, while the other is sending protocol control data or handling transmission errors. A transmission block consists of an initial prologue field, an information field and a final epilogue field. The prologue and epilogue fields are mandatory and must always be sent. The information field is optional and contains data for the application layer, which is either a command APDU sent to the card or a response APDU from the card. There are three fundamentally different types of blocks in T=1: information blocks, receipt acknowledgement blocks and system blocks. Information blocks (I blocks) are used to transparently exchange application-layer data. Receipt acknowledgement blocks (R blocks), which do not contain any data fields, are used for positive or negative reception confirmation. System blocks (S blocks) are used for control information related to the protocol itself. Depending on the specific control data, they may have an information field.

The prologue field
The prologue field consists of three subfields: node address (NAD), protocol control byte (PCB) and length (LEN). It is three bytes long and contains basic control and pointer data for the actual transmission block.
Node address (NAD)
The first byte in the prologue field is called the node address (NAD) byte. It contains the destination and source addresses for the block. Each of these is coded using three bits. If an address is not used, its bits are set to 0. Furthermore, for compatibility with older microcontrollers, control is provided for the EEPROM or EPROM programming voltage. However, there is no practical use for this, since all smart card microcontrollers now have on-board charge pumps.
Protocol control byte (PCB)
The subfield following the node address is the protocol control byte (PCB). As the name suggests, it serves to control and supervise the transmission protocol. This increases the amount
Length field (LEN)
The one-byte length (LEN) field indicates the length of the information field in hexadecimal form. Its value can be’00′to’FE’. The code’FF’is reserved for future extensions and currently should not be used.

The information field
In an I block, the information field serves as a container for application layer data (OSI layer 7). The content of this field is transmitted completely transparently. This means that the content is directly passed on by the transmission protocol without any analysis or evaluation. In an S block, the information field transfers data for the transmission protocol. This is the only case in which this content of this field is used by the transport layer. According to the ISO standard, the size of the information field can range from’00′to’FE’ (254) bytes. The value’FF’(255) is reserved by ISO for future use. The terminal and card may have I fields with different sizes. The default size of the terminal I field is 32 bytes (IFSD = information field size for the interface device); this can be modified via a special S field. This default value of 32 bytes also applies to the card (IFSC = information field size for the card), but this can be modified by a parameter in the ATR.12 In practice, the size of the I field for both the terminal and the card is between 50 and 254 bytes.

Epilogue field
The epilogue field, which is transmitted at the end of the block, contains an error detection code computed from all previous bytes in the block. The computation employs either an LRC (longitudinal redundancy check) or a CRC (cyclic redundancy check). The method used must be specified in the interface characters of the ATR. If it is not specified, by convention the LRC method is implicitly used. Otherwise, the CRC computation is carried out according to ISO 3309. The divider polynomial used, G(x) = x16+x12 + x5 + 1, is the same as for CCITT Recommendation V.41.13 Both of these error detection codes can only be used for error detection; they cannot correct a block error. The single-byte longitudinal redundancy checksum is computed using XOR concatenation of all previous bytes in the block. This computation can be executed very quickly, and its implementation is not code-intensive. It is usually performed on the fly during data transmission or reception. It is a standard part of practically all T = 1 implementations. Using the CRC procedure to generate an error detection code yields a much greater probability of error detection than the relatively primitive XOR checksum. However, this procedure is presently not used in practice, since the XOR checksum has become the established standard throughout the world. With the CRC procedure, the epilogue field must be extended to two bytes, which further reduces the data transmission rate.