EMV communication protocols

Information exchange between the card and terminal applications from a communication point of view is carried out in accordance with the seven level Reference model of interaction of open systems (EMBOS).

EMBOS describes the General communication interaction between two objects, introducing the concept of seven different Protocol levels placed on top of each other. The EMBOS Protocol Suite provides a reliable mechanism for information exchange between two applications that are generally supported on different hardware and software platforms.
An important aspect of the model EMBOS is a strict separation of Protocol levels. This means that each level only communicates with the level directly adjacent to it from above or below via a well-defined inter-level interface, and each level provides a specific set of services to the Protocol level located above it. The IPC dialog with the terminal currently uses only three levels of interaction between open systems: physical, channel, and application.
The physical layer defines the characteristics of the electrical signals exchanged between the card and the terminal. The channel level is represented by the asynchronous protocols T = 0 and T= 1. In this case, the t= 1 Protocol directly corresponds to the EMBOS as a channel-level Protocol, and in the t= 0 Protocol, the functionality of the physical, channel, and application levels is intertwined.
The application level of interaction between the card and the terminal is represented by the C-APDU (Command Application Protocol Data Unit) and R-APDU (Response Application Protocol Data Unit) data blocks. Using C-APDU blocks, commands are passed from the terminal to the card that determine what the card should do with the information received in the commands. The card sends its response to the command in the R-APDU block.
The interaction between the card and reader occurs on the basis of architecture “client— server” when the card plays the role of a server and a terminal client. The reader sends commands to the card, possibly along with the data used by the card to process the operation. After executing the command, the card sends the reader a response. This response can include data received as a result of executing the card command, as well as data about the status of executing the command.
The data blocks exchanged between the reader and the card at the channel level are called TPDU blocks (TPDU-Transmission Protocol Data Unit). The structure of TPDU blocks used in the T= O Protocol differs from the structure of blocks used in the T-1 Protocol.

The connection established using the physical and channel layer protocols is used by the application layer Protocol, which is used for data exchange (C-APDU and R – APDU blocks) between the card and terminal applications. To do this, APDU blocks are passed for processing to the channel-level Protocol, which creates TPDU blocks from THEM. To transmit TPDU blocks over a physical channel, a physical layer Protocol is used that defines the mechanisms for transmitting signals encoding information bits, synchronizing the receiver and transmitter, and so on. The receiving side generates a TPDU block from the received bits, converts it into an APDU block, and passes it to the waiting application.
It has already been noted that the t= 0 Protocol provides a weak separation between the Protocol levels of the EMBOS model. As a result, there may be restrictions associated with the implementation of certain mechanisms that are usually implemented during data transfer. An example is providing secure messaging between the card and the reader. Secure messaging involves the use of cryptographic methods to encrypt the transmitted information transmitted in the channel between the reader and card applications. In this case, only applications at each end of the connection should understand the information passed between them, while intermediate Protocol layers should see the leaking information as a meaningless set of bytes. Since TPDU blocks can only be built using the syntax and semantics of the APDU block in the T= 0 Protocol, data can only be encrypted at the card/terminal application level (before creating the APDU block).
The weak separation of Protocol levels in the g=0 Protocol is not the result of a design error, but rather the result of an attempt to create a Protocol with a satisfactory data exchange rate between the reader and the card when using very limited smart card resources. The data transfer channel between the reader and the card is a bottleneck when performing a transaction involving the card. For maximum satisfaction of the cardholder, it is desirable that transactions are processed as quickly as possible, ideally instantly. Therefore, in the T= 0 Protocol, error handling and application-level Protocol support are optimized in such a way as to minimize the amount of information passing through the reader — card interface, and thus reduce transaction time.
Note also that using the g= 0 Protocol allows you to save on the size of RAM memory. When using the g=1 Protocol, it is necessary to keep the last block sent by the card in RAM memory in case it needs to be retransmitted. It should be said that the requirement to store the sent block in RAM memory is sensitive for the card. Below you will learn about how the terminal reads card data using the READ RECORD command. In this case, when reading an entry containing the card Issuer’s public key certificate, you may need to store a block of about 250 bytes.
Protocol T = 0
The t= 0 Protocol is an asynchronous half-duplex byte Protocol (the unit of transmitted data is a byte of information). Asynchrony of the Protocol means that the moment when data transfer starts is arbitrary and is not regulated by the physical layer Protocol in any way. The half-duplex nature of the data link means that data can be transmitted in both directions, but only in one direction at a time.
As shown in Fig. 2.7, to transmit one byte of information, 10 bits of information must be transmitted, regardless of the Protocol used (T= 0 or T= 1). In addition to the 8 information bits, the start bit and the parity bit are used.
In addition, there are security intervals between byte transfer intervals. By default, in the g= 0 Protocol, the size of the security interval is two bits. In the t= 1 Protocol, it is equal to 1 bit. Thus, the effective data transfer rate in the g= O Protocol is approximately 1.5 times lower than the transfer rate in the channel.
In the T= 0 Protocol, error detection is performed by controlling the parity bit in each byte that passes through the reader — card interface. The parity bit is set to make the total number of single bits in the transmitted character (byte) even. The receiving party uses the value of the bits passed before the parity bit to determine what state the parity bit should be in. If the actual received parity bit does not match the expected value, it is concluded that an error occurred in the transmitted data byte and a procedure is required to restore the distorted data. It is obvious that the described error detection mechanism only deals with the case when an odd number of bits were distorted in the transmitted symbol. Otherwise, the error will go unnoticed and, consequently, no steps will be taken to correct it.
The procedure for restoring corrupted data during transmission, used in the T= 0 Protocol, is initiated by the receiving party, which, if a parity error is detected, should signal the transmitting party that it expects to retransmit the byte received with the error. This signal is sent as follows. When an error is detected, the receiving party switches the I/O line from the high-voltage state it is in during the protection interval to the low-voltage state. This occurs in the middle of the first bit of the security interval. The transmitting side monitors the status line I/O. When in the beginning of the second bits of the guard interval it detects to a low voltage condition, the disclosing party understands that it is her signal to re-transfer just transferred bytes. When a low level is detected, the transmitting side switches the I/O line to a high voltage state and waits for at least the time required to transmit two bits, then sends back the byte that was previously transmitted with an error.

Thus, the Protocol for detecting and correcting error simultaneously uses the physical and data link layers of the model of ENGOS. Obviously, the described error detection and correction Protocol is not effective. Indeed, in practice, in most cases (for most readers), the quality of the channel is either very good or very poor. If it is very good, the error detection and correction mechanism is rarely used, and it might not be used at all. If the channel quality is poor, the error detection and correction mechanism described will constantly detect an error when transmitting a character and try to re-transmit this character to the receiving party. Repeated character retransmission will cause the transmitting and receiving sides of the channel to fail to sync.
If the card detects that it is out of sync with the reader first, it is usually programmed to switch to silent mode and stop responding to commands from the reader. In this situation, or when the reader detects the out-of-sync state first, it sends the card a Reset initial setup signal, which solves the problem of getting out of an undefined situation.
It is obvious that in the case of a bad channel, the mechanism for detecting and correcting errors in the t= 0 Protocol either does not cope with errors at all, or provides a low data exchange rate. To solve the problem of a bad channel, you need to use error-correcting codes. These codes can be used when using block data transfer protocols, but error-correcting codes are not yet used in smart cards.

Unit TPDU Protocol T= 0 has two different structures: one in the transmission command from the reader to the card (TPDU-team), another for transmitting a response to the command from the card reader (TPDU-response).
The TPDU command header sent from the reader to the card is formed based on the APDU application-level block and consists of five fields, each one byte in size:
CLA: a single-byte field that defines the class that the command belongs to; copied from the CLA byte of the APDU block;
INS: a single-byte field that defines a specific command; copied from the INS byte of the APDU block;
P1: a single-byte field used as a command parameter; copied from the P1 byte of the APDU block;
P2: a single-byte field, also used as a command parameter; copied from the P2 byte of the APDU block;
RZ: a single-byte field used to determine the number of bytes of data transmitted to or from the card when executing a command. The direction of data transmission depends on the specific command (INS values). Depending on INS, the RS value is determined by either the Lc byte value or the Le byte value of the APDU block.
(For more information about the CLA, INS, PI, P2, Lc, and Le fields in the APDU block, see section 3.9.)
After sending the above-mentioned five bytes of the TPDU command header, the card responds with a procedure byte, which determines the reader’s further actions related to data transmission and programming voltage control. Recall that in the first microprocessor cards for programming eepr0m memory cells (i.e. for erasing and writing data to EEPR0M), a separate power supply was required, supplying the VPP card contact with a programming voltage (usually 12.5 or 21 V). The chips used in modern smart cards are able to independently extract the programming voltage from the VCC supply. However, at the time of the approval of the IS0/IEC 7816 standard, VPP voltage control was necessary, and therefore it was implemented in the T= 0 Protocol.
According to ISO 7816-3, there are three types of procedure bytes:
ask confirmation byte;
a NULL byte that takes the single value ‘ 60’h;
a SW1 byte that takes the values ‘6x’h or; 9x’h, excluding the value’ 60’h.
The ask confirmation byte can take four values (table. 2.7).
Note that the values of INS and INS +1 in table. 2.7 denote the bytes obtained from the INS and INS+1 bytes, respectively, by inverting (replacing with the opposite value) each bit contained in them. In other words, binary bitwise addition of ins with INS and INS+1 with INS+1 produces a byte consisting of eight ‘O’ bits.
The EMV standard specifies the reader’s actions, taking into account that the standard does not consider the possibility of using a programming voltage:

if the value of the ask byte is INS, the reader sequentially passes the remaining bytes to the card, if any, or is ready to receive the remaining bytes from the card;
if the value of the ask byte is INS, the reader passes the next byte to the card, if any, or is ready to receive the next byte from the card.
After performing the actions specified in the ask byte, the reader waits for the next byte of the procedure from the card.
The NULL procedure byte serves as a means for the card to extend the time interval during which the card executes the command. After sending the TPDU command, the reader waits for a TPDU response. If the response does not arrive within a certain period of time, the reader can send the card a Reset signal to reset it. To prevent reinstalling, the card sends a NULL byte to the reader. As a result, the reader waits for the next byte of the procedure and does nothing with the programming voltage, nor does it transmit data to the card.
Finally, if the value of the ask byte is SW1, the programming voltage is not applied and the reader waits for the status word SW2. The SW1 and SW2 bytes are used by the card to inform the terminal application about the status of the received command execution by the card. Acceptable values for SW1 and SW2 are defined as part of the application Protocol. (For more information about the possible values of SW1 and SW2, see SECTION 2.)

Protocol T= 1 is a block Protocol. This means that a certain set of information (a block) is moved between the reader and the card as a whole. Within this block structure, there may be a block or several APDU blocks defined for a specific application. This shows that the g= 1 Protocol provides a clear separation between the channel and application Protocol levels. Moving information in blocks, however, requires that the block is passed without errors, otherwise the Protocol will be ineffective. Detecting and correcting errors in this case is a more complex and effective procedure than in the case of the t= 0 Protocol.
Error detection in the t= 1 Protocol is performed using either the longitudinal redundancy character (LRC— Longitudinal Redundancy Character), which is a slightly more complex form of parity control than in the t= 0 Protocol, or using the cyclic linear code verification sequence or otherwise redundant cyclic control (CRC-Cyclic Redundancy Check).
The longitudinal redundancy symbol is calculated as a bitwise addition modulo 2 of all bytes of the transmitted message, with the exception of the LRC byte. The CRC algorithm used in the T= 1 Protocol is defined by the ISO 3309 standard. It is a cyclic code with a generating polynomial d (x) = x16 + X12 + XY + 1 of degree 16, which means that the verification sequence generated by the code has the size of two bytes.
It is not difficult to prove that the code distance (the minimum Hamming distance between any two code words) of this cyclic code is 4 (the minimum weight (number of units) of the code word is 4). It follows that the cyclic code described in the ISO 3309 standard is able to detect any single, two-fold errors, as well as errors of odd multiplicity in the resulting block. The code is not guaranteed to detect other group errors. The ability of the code to correct any errors of odd multiplicity follows from the fact that, obviously, all code words of the code in question have an even weight.
It is easy to show that if as a result of an error in the channel, the transmitted word can equally likely pass to any other word of the same length, then the probability of detecting an error in the code in question is 1-2~16 = 99.99847%.

Moreover, the code is able to fix any single errors. However, the error correction mode for data transfer in smart cards is not yet used, because it requires significant computing resources to implement the card.
When the receiving party detects an error, it transmits this information to the transmitting party using a special data block.
The g= 1 Protocol uses three different types of blocks. Each block has the same structure, but it is used for different tasks.
Information block (Information block or I-block). The block is used for transmitting information between the card and terminal applications. The information block also serves as a confirmation of receiving the block from the receiving party.
Receive ready block or R-block. This block is used for transmitting either a positive or negative confirmation receipt from the receiving party to the transmitting party. A positive receipt indicates that the block was accepted correctly, and a negative one indicates that an error was detected in the accepted block.
Administrative block (Supervisory block or S-block). This block is used for transmitting control information between the card and the reader.
Each block of the t= 1 Protocol includes three fields

Input field. A required field in the block length of 3 bytes. It includes the following three elements, each of which is 1 byte in size:
NAD-address of the node (Node Address);
RSV-control byte of the Protocol (Protocol Control Byte);
LEN — the data length (Data Length).
Information field. Optional field for a block up to 254 bytes long. It is intended for transmitting application commands and data.
Final field. Required field for a block of 1 or 2 bytes in length. This field contains a verification sequence for detecting an error. If the longitudinal redundancy symbol LRC is used as such a sequence, then the final field is one byte in size. If the verification sequence is generated by a cyclic code, the size of the final field is equal to 2 bytes.
The NAD element of the input field is used to specify the addresses of the source of the transmitted block (Source Address or SAD, bits 3-1) and its recipient (Destination Address or DAD, bits 7-5) if multiple logical channels are used between the transmitting and receiving sides.
In situations where multiple logical channels are not used, the values of the SAD and DAD bits are set to zero. Bits 4 and 8 of the NAD byte that are not used for SAD or DAD encoding are used for transmitting information that controls the VPP programming voltage.
The RSV control byte is used to specify the block type (whether it is an information block, a ready-to-receive block, or an administrative block) and carries some control information, including the Sequence Number bit (the transmitting party changes the bit value to the opposite when transmitting a new block) and the Block Chaining Bit (if the bit value is 1, this means that a chain of related blocks is being passed and the next block of the chain should be passed). The two highest bits of the RSV byte are used to denote different types of blocks:
the highest bit equal to 0 indicates an information block;
the two highest bits equal to 1 represent the administrative block;
the highest bit, equal to 1, and the next bit, equal to 0, denote the ready-to-receive block.

The LEN element defines the number of bytes in the block’s information field. The LEN value ranges from 0 to FE (hex), i.e. the maximum number of bytes in the information field is 254.
To set some parameters of the t=1 Protocol used for controlling data transmission, use the interface symbols TA(3), TV(3), TC(3), received by the reader from the ATR sequence.
So the symbol TA(3) defines the size of the information field of the Protocol block T=1, transmitted by the card to the reader. By default, the size of this field is 32 bytes.
The size of the information field of the block passed by the reader to the card is also 32 bytes by default and can be changed by the reader using the administrative block passed to the card.
Bits 4-1 of the TV character (3) define the CWI parameter (the default value is 13), which in turn sets the CWT parameter (Character Waiting Time), defined as the maximum allowed time between two consecutive characters of the same block. The CWT parameter can be used to determine an error in the length of the received block.
Bits 8-5 of the TV character (3) define the BWI parameter (the default value is 4). The BWI parameter sets the value of BWT (Block Waiting Time), defined as the maximum allowed time between the moment when the last character of the block sent by the reader starts transmitting and the moment when the first character of the next block received by the reader from the card starts receiving. The BWT parameter can be used to determine whether the card has stopped responding to terminal commands.
There is also the BGT (Block Guard Time) parameter, which is defined as the minimum time between the moment when the last sign of the block starts transmitting and the moment when the first sign of the next block is transmitted in the alternative direction.
The CWT and BWT parameters are defined using the following formulas:
CWT = (2CWI + U)xetu;
BWT = (2BWIx960x372/f) + lletu, where /— as before, the clock frequency of the CLK signal.

If bit 1 of the vehicle interface symbol (3) is equal to 1, it means that a cyclic code is used to detect errors in the block. If this bit is 0, the longitudinal redundancy symbol is used to detect errors.
The T=1 Protocol is more advanced and therefore more complex than the byte Protocol. This Protocol uses a significantly more efficient error detection and correction algorithm applied at the data block level. In comparison with the case of the t=0 Protocol, this efficiency is confirmed by the fact that in the t=1 Protocol, the use of the CRC code makes it possible to reliably detect all errors of odd multiplicity. The procedure for notifying the transmitting party of an error in the transmitted block is also much more effective.
The T=1 Protocol allows you to organize multiple logical channels between the card and the terminal, as well as transmit multiple commands in a single block of information. In accordance with ISO 7816-4, the logical channel is considered as a separate communication channel with a certain directory of the card file system. The terminal can set up to 4 logical communication channels with the card. The channel number (from 0 to 3) is encoded by bits B1 and B2 of the CLA command byte. Data is transmitted over two logical channels at the logical level in an independent manner.
The ability to send multiple commands in a single TPDU block is useful, for example, when the terminal reads the card data. In this case, several READ RECORD commands can be passed at once in a single TPDU block. This also allows you to save on data transfer time. Indeed, when using the t=1 Protocol, 40+11X bits are required to transmit X bytes of information (40 bits are obtained from 3 bytes of the header and 2 bytes of the CRC code verification sequence, 11 bits are required to transmit one byte of information). When using the t=0 Protocol, you will need to send 12X bits to transmit the same X bytes of information. It follows that when transmitting more than 40 bytes of information, the t=1 Protocol is faster than the t=0 Protocol.
The higher efficiency of the T=1 Protocol in comparison with the t=0 Protocol is shown when large amounts of data are transmitted between the card and the reader and / or the reader quality is not high enough.

At the same time, you need to pay for the higher efficiency of the t=1 Protocol. In addition to the fact that the software implementing the Protocol on the card and terminal side requires more memory due to the higher complexity of the Protocol, more RAM must be used on the card side. This is due to the fact that when using the t=1 Protocol, the card must store the last transmitted message in case it needs to be retransmitted if an error is detected in the message transmitted by the card.