Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
The exchange of information between the card and the terminal from the point of view of the organization of communications is carried out in accordance with the seven-level reference model for the interaction of open systems (EMVOS). EMVOC levels are shown in table. 2.6.
Tab. 2.6. EMVOS levels
EMVOS describes the general communication interaction between two entities, introducing the concept of seven different protocol layers placed on top of each other. The set of EMVOS protocols provides a reliable mechanism for information exchange between two applications, which are generally supported on different hardware and software platforms.
An important aspect of the EMVOS model is the strict separation of protocol layers. This means that each layer communicates only with the layer immediately adjacent to it above or below through a given interlayer interface, and each layer provides a specific set of services to the protocol layer located above it. In the dialogue between the IPC and the terminal, today only three levels of interaction of open systems are used: physical, channel and application.
The physical layer defines the characteristics of the electrical signals exchanged between the card and the terminal reader. The link layer is represented by the asynchronous protocols T = 0 and T = 1. At the same time, the T = 1 protocol fully corresponds to the link layer of the EMVOS model, and the T = 0 protocol combines the functionality of the physical, link and application layers.
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. With the help of C-APDUs, commands are sent from the terminal to the card that determine what the card should do using the information received in the commands. The card transmits its response to the command in the R-APDU unit.
The interaction between the card and the terminal follows the client-server architecture, when the card plays the role of the server, and the terminal plays the role of the client. In this case, the terminal sends commands to the card, possibly along with the data used by the card to carry them out. After executing the next command, the card sends a response to the command to the reader. This response contains information about the status of the command processing by the card, and may also include data received by the card as a result of command execution.
The data blocks that are exchanged between the reader and the card at the data link layer are called TPDUs (TPDUs - Transmission Protocol Data Units). The structure of TPDUs used in the T = 0 and T = 1 protocols is different.
The connection established using the physical and data link protocols is used for data exchange (by the C-APDU and R-APDU units) between the card and terminal applications. To do this, APDUs are sent for processing to the link layer protocol, which creates TPDUs from them. To transmit TPDUs over a physical channel, a physical layer protocol is used, which determines the mechanisms for transmitting signals encoding information bits, synchronizing the receiver and transmitter, etc. The receiving side forms a TPDU from the received bits, converts it into an APDU, which is transmitted to the waiting application host side.
It has already been noted that the T - 0 protocol provides a weak separation between the protocol layers of the EMVOS model. As a consequence, there may be limitations associated with the implementation of some mechanisms, usually implemented in the transmission of data. An example is the provision of secure data exchange between the card and the terminal, which involves the use of cryptographic methods to encrypt the transmitted information. In this case, only applications at each end of the connection should be able to understand the information transmitted between them, while at lower protocol layers, the transmitted information should be perceived as a meaningless set of bytes. Since in the T = 0 protocol, the TPDU is created using the syntax and semantics of the APDU,
The weak separation of protocol layers in the T = 0 protocol is not the result of an error in its design, but is the result of a search for a compromise between the need to ensure a satisfactory data transfer rate and the very limited resources of a smart card, in particular, the size of its RAM. The data transfer channel between the reader and the card is a bottleneck when performing a transaction. To increase the effective rate of data exchange between the card and the reader, the T-0 protocol has optimized the error handling mechanism and support for the application layer in such a way as to minimize the amount of information transmitted through the reader-card interface. This reduces the processing time of the transaction.
Note also that the use of the T = 0 protocol saves on the amount of RAM. When using the T - 1 protocol, it is necessary to keep the last block sent by the card in the RAM memory in case it needs to be retransmitted. It must be said that the requirement to store the sent block in RAM is sensitive to the card. Below will be described how the terminal reads card data using the READ RECORD command. In this case, when reading the record containing the public key certificate of the card issuer, it may be necessary to store a data block of about 250 bytes on the card.
2.4.1. Protocol T = O
The T = 0 protocol is an asynchronous half-duplex byte protocol (the unit of transmitted data is a byte of information). Asynchronous protocol means that the moment of the start of data transfer is arbitrary and is not regulated in any way by the physical layer protocol. The fact that the channel organized using the T = 0 protocol is half-duplex means that data can be transmitted in both directions, but at a time the transmission is made in only one direction.
As shown in fig. 2.7, to transfer one byte of information, it is required to transmit 10 bits of information, 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 guard intervals between the transmission of information bytes. By default, in the T = 0 protocol, the size of the guard interval is two bits. In the T = 1 protocol, it is equal to 1 bit. Thus, the effective data transfer rate in the T = 0 protocol is approximately 1.5 times lower than the channel transfer rate.
In the T = 0 protocol, errors are detected by checking the parity bit in each byte transmitted through the reader-card interface. The parity bit is set in such a way as to make the total number of single bits in the transmitted character (byte) even
Error signal
Rice. 2.7. Transfer of information bytes in the T = 0 protocol
nym. The receiving side determines the state of the parity bit by the value of the bits transmitted before the parity bit. If the received parity bit does not correspond to the expected value, then it is concluded that an error has occurred in the transmitted data byte and it is necessary to perform the procedure for recovering the corrupted data. It is obvious that the described error detection mechanism only copes with the case when an odd number of bits have been corrupted in the transmitted symbol. Otherwise, the error will go unnoticed and, therefore, no steps will be taken to correct it.
The procedure for restoring corrupted data during transmission, used in the T = 0 protocol, is started by the receiving side, which, upon detecting a parity error, must signal to the transmitting side that it is waiting for the retransmission of the byte received with an error. This signal is supplied as follows. The receiving side, after detecting an error, transfers the I / O line from a high voltage state, in which it is during the guard interval, to a low voltage state. This occurs in the middle of the first bit of the guard interval.
The transmitting side constantly monitors the status of the I / O line. When, at the beginning of the second bit of the guard interval, it detects the transfer of the line to a low voltage state, the transmitting side realizes that this is a signal for it to retransmit the byte just transmitted. Upon detecting a low voltage level, the transmitting side sets the I / O line to a high voltage state and waits at least for the time required to transmit two bits, and then again sends the byte transmitted earlier in error.
Thus, the error detection and correction protocol uses both the physical and channel layers of the EMVOS model. It is obvious that the used error detection and correction protocol is not efficient. Indeed, in practice, in most cases (for most readers), the channel quality is either very good or very bad. If it is very good, then the error detection and correction mechanism is rarely used, and it might not be used at all. If the channel quality is poor, then when a symbol is transmitted, the described error detection and correction mechanism will constantly detect an error and try to re-transmit this symbol to the receiving side. Repeatedly retransmitting the symbol will cause the transmitting and receiving sides of the channel to go out of sync.
If the card detects out of sync with the reader first, it usually goes into silent mode and stops responding to the reader's commands. In this situation, or in the case when the reader detects the out-of-sync state first, it will put the card in an idle state and send it an initial RST signal, which will solve the problem of getting out of an undefined situation.
Obviously, in the case of a bad channel, the T = 0 protocol error detection and correction mechanism either does not cope with errors at all, or provides a low data exchange rate. To solve the problem of a bad channel, it is necessary to use codes that algorithmically correct errors by software. The use of such codes is possible when using block data transfer protocols, however, these codes are not yet used in smart cards.
The TPDU block in the T = 0 protocol has two different structures: one when transmitting a command from the reader to the card (TPDU command), the other when transmitting a response to a command from the card to the reader (TPDU response).
The TPDU command header sent from the reader to the card is formed on the basis of the APDU application level block and consists of five fields, one byte in size each:
CLA: a single-byte field that identifies the class to which the command belongs; copied from the CLA byte of the APDU;
INS: a single-byte field that identifies a specific command; copied from the INS byte of the APDU;
P1: one-byte field used as a command parameter; copied from the P1 byte of the APDU;
P2: one-byte field, also used as a command parameter; copied from byte P2 of the APDU;
R3: A one-byte field used to determine the number of data bytes to be transferred to or from the card when a command is executed. The direction of data transfer depends on the specific command (INS value). Depending on INS, the P3 value is determined by either the Lc byte value or the Le byte value of the APDU.
(For more information on the fields CLA, INS, Pl, P2, Lc, Le of the APDU, see section 3.9.)
After sending the above five bytes of the TPDU command header, the card responds with a procedure byte, which determines the further actions of the reader related to data transfer and control of the programming voltage. Recall that in the first microprocessor cards for programming EEPROM memory cells (that is, for erasing and writing data to EEPROM), a separate power supply was needed to supply programming voltage to the VPP card pin (most often 12.5 or 21 volts). The microcircuits used in modern smart cards are able to independently extract the programming voltage from the VCC supply. However, at the time the ISO / IEC 7816 standard was approved, VPP voltage control was necessary and therefore it was taken into account in the T - 0 protocol.
According to ISO 7816-3, there are three types of procedure bytes:
Note that the values INS and INS 4-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 they contain. In other words, binary bitwise addition of the bytes INS to INS and INS + 1 to INS + 1 results in a byte consisting of eight 'O' bits.
r L 1
MasterCard to J
Tab. 2.7. ACK procedure byte values
In the EMV standard, the actions of the reader are specified taking into account the fact that the standard does not consider the possibility of using a programming voltage:
The NULL procedure byte is used by the card to extend the time interval during which the card can execute the command. After sending a TPDU command, the reader waits for a TPDU response. If the answer does not come within a certain period of time, then the reader can initiate a warm installation of the card. To prevent this, 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, and also does not transfer data to the card.
Finally, if the value of the ACK byte is SW1, then the programming voltage is not applied, and the reader waits for the status word SW2. Bytes SW1 and SW2 are used by the card to inform the terminal application about the status of the card's execution of the command received from the terminal. Valid values for SW1 and SW2 are defined as part of the application protocol. (For more details on the possible values of SW1 and SW2, see section 3.9.)
2.4.2. Protocol T = 1
The T = 1 protocol is a block protocol. This means that a certain set of information (data block) moves between the reader and the card as a whole. This block structure can contain a block or several APDUs of a particular application. Thus, the T = 1 protocol provides a clear separation between the data link layer and the application protocol layer.
Error detection in the T-1 protocol is performed using either the Longitudinal Redundancy Character (LRC), which is a slightly more complex form of parity than in the T = 0 protocol, or using a cyclic linear code check sequence, or otherwise redundant cyclic control (CRC - Cyclic Redundancy Check).
The longitudinal redundancy symbol is calculated as a bitwise modulo 2 addition of all bytes of the transmitted message except for 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 g (x) = x 16 + x 12 + x 5 + 1 of degree 16, which means that the check sequence generated by the code , is two bytes in size.
It is easy to prove that the code distance, that is, the minimum Hamming distance between codewords of the code, in our case is equal to 4 (the minimum weight (number of ones) of a nonzero codeword is 4). Recall that, by definition, the Hamming distance between two codewords is equal to the number of mismatched positions of these words. It is easy to prove that the cyclic code described in the ISO 3309 standard is able to reliably detect any single, double, and odd multiplicity errors in the received data block. It is not guaranteed that the code is capable of detecting other group errors as well. The ability of the code to detect any errors of odd multiplicity follows from the fact that, obviously, all codewords of the code under consideration have an even weight.
It is easy to show that if, as a result of distortion of the transmitted word, it can equally likely pass into any other word of the same length, then the probability of detecting an error using the code under consideration is 1 - 2 16 = 99.99847%.
Moreover, the code is capable of fixing any single errors. However, the error correction mode for data transmission in smart cards is not used. This is due to the fact that the specificity of the channel in this case is such that either there are no errors in the channel, or there are many of them. The appearance of single errors, for the correction of which the Hamming code is suitable, seems exotic.
Encoding transmitted messages and detecting errors in received messages are often performed by a microcircuit using a special CRC coprocessor (see Fig. 2.1).
When the receiving side detects an error, it sends information about this to the transmitting side using a special data block.
The T = 1 protocol uses three different block types. Each block has the same structure, but with its help different tasks are solved.
Information block (Information block, or I-block). The block is used to transfer information between card and terminal applications. The information block also serves as a confirmation of the receipt of the block from the receiving side.
Receive ready block, or R-block. This block is used to transmit either a positive or negative acknowledgment receipt from the receiving side to the transmitting side. A positive receipt indicates that the block was received correctly, and a negative receipt indicates that an error was detected in the received block.
Administrative block (Supervisory block, or S-block). This block is used to transfer control information between the card and the reader.
Each block of the T = 1 protocol includes three fields (Fig. 2.8).
Rice. 2.8. Components of the protocol block T = 1
Introductory field. Mandatory block field with a length of 3 bytes. It includes the following three elements, each one byte in size:
NAD - node address (Node Address);
PCB - Protocol Control Byte;
LEN - Data Length.
Information field. An optional block field up to 254 bytes long. It is intended for transmission of applied commands and responses to commands.
Final field. Mandatory block field, 1 or 2 bytes long. This field contains a check sequence for error detection. If the sequence is the LRC longitudinal redundancy symbol, then the final field is one byte. If the check sequence is generated by a cyclic code, then the size of the final field is 2 bytes.
The EMV standard uses the LRC longitudinal redundancy symbol for error detection, and therefore the final block field is 1 byte.
The NAD element of the introductory field is used to indicate 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) in the case of using multiple logical channels between the transmitting and receiving sides.
In a situation where a single logical channel is used between the transmitting and receiving sides, the values of the SAD and DAD bits are set to zero. Bits 4 and 8 of the NAD byte, which are not used for encoding SAD or DAD, are used to convey information that controls the programming voltage VPP.
The PCB control byte is used to indicate the block type and control the block transfer. The two most significant bits of the PCB byte are used to designate different types of blocks:
The LEN element defines the number of bytes in the information field of the block. The LEN value ranges from 0 to 'FE'h, i.e. the maximum number of bytes in the information field is 254.
To set some parameters of the T = 1 protocol used to control data transmission, the interface symbols TA (3), TB (3), TC (3), obtained by the reader from the ATR sequence, are used.
Thus, the TA symbol (3) determines the size of the information field of the T = 1 protocol block 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 transmitted by the reader to the card is also 32 bytes by default and can be changed by the reader using the administrative block transmitted to the card.
Bits 4-1 of the TB symbol (3) define the CWI parameter (the default value is 13), which in turn sets the CWT (Character Waiting Time) parameter, which is defined as the maximum allowable time between the first two bits of two consecutive characters of the same block. The CWT parameter can be used to determine the error in the length of the received block.
Bits 8-5 of the TB symbol (3) define the BWI parameter (default value is 4). The BWI parameter sets the BWT (Block Waiting Time) value, which is defined as the maximum allowable time between the moment when the last character of the block sent by the reader starts to be transmitted and the moment when the first character of the next block received by the reader from the card begins to be received. The BWT parameter can be used to determine if 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 character of a block is transmitted and the moment when the first character of the next block sent in the opposite direction is received.
Parameters CWT and BWT are determined by the following formulas:
CWT = (2 CWI + 11) ETU;
BWT = (2 BW1 • 916 • 372 ' D + 11] • etu,
I f) '
where / is as before, the clock signal frequency CLK.
If bit 1 of the TC (3) interface symbol is 1, this means that a cyclic code is used to detect errors in the block. If this bit is 0, then the longitudinal redundancy symbol (EMV case) is used for error detection.
The T = 1 protocol is more advanced and therefore more complex in comparison with the byte protocol. This protocol uses a more efficient error detection and correction algorithm applied at the data block level. In comparison with the case of the T = O protocol, this efficiency is confirmed by the fact that in the T = 1 protocol, the use of a CRC-code makes it possible to reliably detect all errors of odd multiplicity. The procedure for notifying the transmitting side about an error in the block transmitted by it is also more efficient.
The T = 1 protocol allows organizing several logical channels between the card and the terminal, as well as transmitting several commands in one information block. According to ISO 7816-4, a logical channel is considered as a separate communication channel with some directory of the card file system. The terminal can establish up to four logical communication channels with the card. The channel number (from 0 to 3) is encoded by bits bl and b2 of the CLA command byte. At the logical level, data transfer over any two channels occurs independently.
The ability to transmit multiple commands in one TPDU is useful, for example, when the terminal reads card data. In this case, multiple READ RECORD commands can be sent in one TPDU at once. This allows, among other things, to save on data transfer time. Indeed, when using the T - 1 protocol, to transfer X bytes of information, you will need to transfer 40 + THEM bits (40 bits are obtained from 3 bytes of the header and 2 bytes of the CRC code check sequence, 11 bits are required in the T = 1 protocol to transfer one byte of information) ... When using the T = 0 protocol, to transfer the same X bytes of information, 12X bits will need to be transmitted. It follows that when transferring more than 40 bytes of information, the T = 1 protocol turns out to be faster than the T = 0 protocol.
The higher efficiency of the T = 1 protocol in comparison with the T - 0 protocol is manifested in the case when large amounts of data are transferred between the card and the reader and / or the quality of the reader is not high enough.
At the same time, for the higher efficiency of the T = 1 protocol, one has to pay with the resources of the card. 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 space 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 when an error is detected in the block transmitted by the card.
2.4.3. Application protocols
The ISO / IEC 7816-4 standard defines the functions used by smart card and terminal applications when performing a transaction. It describes two classes of functions.
First, the commands available to the terminal program for working with information stored in the file system of the card are defined.
Second, security functions are defined that can be used to restrict access to application functions and map files, and secure data exchange. These functions include authentication of the card and the external program that works with the card, ensuring the integrity and confidentiality of information transmitted in a command directed to the card, checking the cardholder's PIN.
As already mentioned, card and terminal applications use APDUs (Application Protocol Data Units) to exchange data. The structure of the APDU is defined by the ISO 7816-4 standard. APDUs are exchanged using the T - 0 or T = 1 link layer protocols. The card application interprets the APDUs and performs the operations they define. The architecture of the data exchange system between the card and terminal applications is shown in Fig. 2.9.
Rice. 2.9. Application-level communication architecture
For the command set defined in ISO 7816-4, see 3.10.
Tab. 2.6. EMVOS levels
| Level number | Level name |
| 7 | Application level |
| 6 | Presentation layer |
| 5 | Session level |
| 4 | Transport layer |
| 3 | Network layer |
| 2 | Link layer |
| 1 | Physical layer |
EMVOS describes the general communication interaction between two entities, introducing the concept of seven different protocol layers placed on top of each other. The set of EMVOS protocols provides a reliable mechanism for information exchange between two applications, which are generally supported on different hardware and software platforms.
An important aspect of the EMVOS model is the strict separation of protocol layers. This means that each layer communicates only with the layer immediately adjacent to it above or below through a given interlayer interface, and each layer provides a specific set of services to the protocol layer located above it. In the dialogue between the IPC and the terminal, today only three levels of interaction of open systems are used: physical, channel and application.
The physical layer defines the characteristics of the electrical signals exchanged between the card and the terminal reader. The link layer is represented by the asynchronous protocols T = 0 and T = 1. At the same time, the T = 1 protocol fully corresponds to the link layer of the EMVOS model, and the T = 0 protocol combines the functionality of the physical, link and application layers.
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. With the help of C-APDUs, commands are sent from the terminal to the card that determine what the card should do using the information received in the commands. The card transmits its response to the command in the R-APDU unit.
The interaction between the card and the terminal follows the client-server architecture, when the card plays the role of the server, and the terminal plays the role of the client. In this case, the terminal sends commands to the card, possibly along with the data used by the card to carry them out. After executing the next command, the card sends a response to the command to the reader. This response contains information about the status of the command processing by the card, and may also include data received by the card as a result of command execution.
The data blocks that are exchanged between the reader and the card at the data link layer are called TPDUs (TPDUs - Transmission Protocol Data Units). The structure of TPDUs used in the T = 0 and T = 1 protocols is different.
The connection established using the physical and data link protocols is used for data exchange (by the C-APDU and R-APDU units) between the card and terminal applications. To do this, APDUs are sent for processing to the link layer protocol, which creates TPDUs from them. To transmit TPDUs over a physical channel, a physical layer protocol is used, which determines the mechanisms for transmitting signals encoding information bits, synchronizing the receiver and transmitter, etc. The receiving side forms a TPDU from the received bits, converts it into an APDU, which is transmitted to the waiting application host side.
It has already been noted that the T - 0 protocol provides a weak separation between the protocol layers of the EMVOS model. As a consequence, there may be limitations associated with the implementation of some mechanisms, usually implemented in the transmission of data. An example is the provision of secure data exchange between the card and the terminal, which involves the use of cryptographic methods to encrypt the transmitted information. In this case, only applications at each end of the connection should be able to understand the information transmitted between them, while at lower protocol layers, the transmitted information should be perceived as a meaningless set of bytes. Since in the T = 0 protocol, the TPDU is created using the syntax and semantics of the APDU,
The weak separation of protocol layers in the T = 0 protocol is not the result of an error in its design, but is the result of a search for a compromise between the need to ensure a satisfactory data transfer rate and the very limited resources of a smart card, in particular, the size of its RAM. The data transfer channel between the reader and the card is a bottleneck when performing a transaction. To increase the effective rate of data exchange between the card and the reader, the T-0 protocol has optimized the error handling mechanism and support for the application layer in such a way as to minimize the amount of information transmitted through the reader-card interface. This reduces the processing time of the transaction.
Note also that the use of the T = 0 protocol saves on the amount of RAM. When using the T - 1 protocol, it is necessary to keep the last block sent by the card in the RAM memory in case it needs to be retransmitted. It must be said that the requirement to store the sent block in RAM is sensitive to the card. Below will be described how the terminal reads card data using the READ RECORD command. In this case, when reading the record containing the public key certificate of the card issuer, it may be necessary to store a data block of about 250 bytes on the card.
2.4.1. Protocol T = O
The T = 0 protocol is an asynchronous half-duplex byte protocol (the unit of transmitted data is a byte of information). Asynchronous protocol means that the moment of the start of data transfer is arbitrary and is not regulated in any way by the physical layer protocol. The fact that the channel organized using the T = 0 protocol is half-duplex means that data can be transmitted in both directions, but at a time the transmission is made in only one direction.
As shown in fig. 2.7, to transfer one byte of information, it is required to transmit 10 bits of information, 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 guard intervals between the transmission of information bytes. By default, in the T = 0 protocol, the size of the guard interval is two bits. In the T = 1 protocol, it is equal to 1 bit. Thus, the effective data transfer rate in the T = 0 protocol is approximately 1.5 times lower than the channel transfer rate.
In the T = 0 protocol, errors are detected by checking the parity bit in each byte transmitted through the reader-card interface. The parity bit is set in such a way as to make the total number of single bits in the transmitted character (byte) even
Error signal
Rice. 2.7. Transfer of information bytes in the T = 0 protocol
nym. The receiving side determines the state of the parity bit by the value of the bits transmitted before the parity bit. If the received parity bit does not correspond to the expected value, then it is concluded that an error has occurred in the transmitted data byte and it is necessary to perform the procedure for recovering the corrupted data. It is obvious that the described error detection mechanism only copes with the case when an odd number of bits have been corrupted in the transmitted symbol. Otherwise, the error will go unnoticed and, therefore, no steps will be taken to correct it.
The procedure for restoring corrupted data during transmission, used in the T = 0 protocol, is started by the receiving side, which, upon detecting a parity error, must signal to the transmitting side that it is waiting for the retransmission of the byte received with an error. This signal is supplied as follows. The receiving side, after detecting an error, transfers the I / O line from a high voltage state, in which it is during the guard interval, to a low voltage state. This occurs in the middle of the first bit of the guard interval.
The transmitting side constantly monitors the status of the I / O line. When, at the beginning of the second bit of the guard interval, it detects the transfer of the line to a low voltage state, the transmitting side realizes that this is a signal for it to retransmit the byte just transmitted. Upon detecting a low voltage level, the transmitting side sets the I / O line to a high voltage state and waits at least for the time required to transmit two bits, and then again sends the byte transmitted earlier in error.
Thus, the error detection and correction protocol uses both the physical and channel layers of the EMVOS model. It is obvious that the used error detection and correction protocol is not efficient. Indeed, in practice, in most cases (for most readers), the channel quality is either very good or very bad. If it is very good, then the error detection and correction mechanism is rarely used, and it might not be used at all. If the channel quality is poor, then when a symbol is transmitted, the described error detection and correction mechanism will constantly detect an error and try to re-transmit this symbol to the receiving side. Repeatedly retransmitting the symbol will cause the transmitting and receiving sides of the channel to go out of sync.
If the card detects out of sync with the reader first, it usually goes into silent mode and stops responding to the reader's commands. In this situation, or in the case when the reader detects the out-of-sync state first, it will put the card in an idle state and send it an initial RST signal, which will solve the problem of getting out of an undefined situation.
Obviously, in the case of a bad channel, the T = 0 protocol error detection and correction mechanism either does not cope with errors at all, or provides a low data exchange rate. To solve the problem of a bad channel, it is necessary to use codes that algorithmically correct errors by software. The use of such codes is possible when using block data transfer protocols, however, these codes are not yet used in smart cards.
The TPDU block in the T = 0 protocol has two different structures: one when transmitting a command from the reader to the card (TPDU command), the other when transmitting a response to a command from the card to the reader (TPDU response).
The TPDU command header sent from the reader to the card is formed on the basis of the APDU application level block and consists of five fields, one byte in size each:
CLA: a single-byte field that identifies the class to which the command belongs; copied from the CLA byte of the APDU;
INS: a single-byte field that identifies a specific command; copied from the INS byte of the APDU;
P1: one-byte field used as a command parameter; copied from the P1 byte of the APDU;
P2: one-byte field, also used as a command parameter; copied from byte P2 of the APDU;
R3: A one-byte field used to determine the number of data bytes to be transferred to or from the card when a command is executed. The direction of data transfer depends on the specific command (INS value). Depending on INS, the P3 value is determined by either the Lc byte value or the Le byte value of the APDU.
(For more information on the fields CLA, INS, Pl, P2, Lc, Le of the APDU, see section 3.9.)
After sending the above five bytes of the TPDU command header, the card responds with a procedure byte, which determines the further actions of the reader related to data transfer and control of the programming voltage. Recall that in the first microprocessor cards for programming EEPROM memory cells (that is, for erasing and writing data to EEPROM), a separate power supply was needed to supply programming voltage to the VPP card pin (most often 12.5 or 21 volts). The microcircuits used in modern smart cards are able to independently extract the programming voltage from the VCC supply. However, at the time the ISO / IEC 7816 standard was approved, VPP voltage control was necessary and therefore it was taken into account in the T - 0 protocol.
According to ISO 7816-3, there are three types of procedure bytes:
- ACK confirmation byte;
- NULL byte, accepting a single value '60'h;
- SW1 byte taking the values' 6x'h or '9x'h, excluding the value' 60'h.
Note that the values INS and INS 4-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 they contain. In other words, binary bitwise addition of the bytes INS to INS and INS + 1 to INS + 1 results in a byte consisting of eight 'O' bits.
r L 1
MasterCard to J
Tab. 2.7. ACK procedure byte values
| ACK byte value | Reader actions |
| INS | VPP voltage is not supplied to the card, the reader sequentially transmits the remaining bytes |
| INS + 1 | VPP voltage is applied to the card, the reader sequentially transmits the remaining bytes |
| INS | VPP voltage is not supplied to the card, the reader transmits the next byte to the card |
| INS + 1 | VPP voltage is applied to the card, the reader transmits the next byte to the card |
In the EMV standard, the actions of the reader are specified taking into account the fact that the standard does not consider the possibility of using a programming voltage:
- if the value of the ACK byte is equal to INS, then the reader sequentially transfers the remaining bytes to the card, if any, or is in a state of readiness to receive the remaining bytes from the card;
- if the value of the ACK byte is equal to INS, then the reader transmits the next byte to the card, if any, or is ready to receive the next byte from the card.
The NULL procedure byte is used by the card to extend the time interval during which the card can execute the command. After sending a TPDU command, the reader waits for a TPDU response. If the answer does not come within a certain period of time, then the reader can initiate a warm installation of the card. To prevent this, 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, and also does not transfer data to the card.
Finally, if the value of the ACK byte is SW1, then the programming voltage is not applied, and the reader waits for the status word SW2. Bytes SW1 and SW2 are used by the card to inform the terminal application about the status of the card's execution of the command received from the terminal. Valid values for SW1 and SW2 are defined as part of the application protocol. (For more details on the possible values of SW1 and SW2, see section 3.9.)
2.4.2. Protocol T = 1
The T = 1 protocol is a block protocol. This means that a certain set of information (data block) moves between the reader and the card as a whole. This block structure can contain a block or several APDUs of a particular application. Thus, the T = 1 protocol provides a clear separation between the data link layer and the application protocol layer.
Error detection in the T-1 protocol is performed using either the Longitudinal Redundancy Character (LRC), which is a slightly more complex form of parity than in the T = 0 protocol, or using a cyclic linear code check sequence, or otherwise redundant cyclic control (CRC - Cyclic Redundancy Check).
The longitudinal redundancy symbol is calculated as a bitwise modulo 2 addition of all bytes of the transmitted message except for 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 g (x) = x 16 + x 12 + x 5 + 1 of degree 16, which means that the check sequence generated by the code , is two bytes in size.
It is easy to prove that the code distance, that is, the minimum Hamming distance between codewords of the code, in our case is equal to 4 (the minimum weight (number of ones) of a nonzero codeword is 4). Recall that, by definition, the Hamming distance between two codewords is equal to the number of mismatched positions of these words. It is easy to prove that the cyclic code described in the ISO 3309 standard is able to reliably detect any single, double, and odd multiplicity errors in the received data block. It is not guaranteed that the code is capable of detecting other group errors as well. The ability of the code to detect any errors of odd multiplicity follows from the fact that, obviously, all codewords of the code under consideration have an even weight.
It is easy to show that if, as a result of distortion of the transmitted word, it can equally likely pass into any other word of the same length, then the probability of detecting an error using the code under consideration is 1 - 2 16 = 99.99847%.
Moreover, the code is capable of fixing any single errors. However, the error correction mode for data transmission in smart cards is not used. This is due to the fact that the specificity of the channel in this case is such that either there are no errors in the channel, or there are many of them. The appearance of single errors, for the correction of which the Hamming code is suitable, seems exotic.
Encoding transmitted messages and detecting errors in received messages are often performed by a microcircuit using a special CRC coprocessor (see Fig. 2.1).
When the receiving side detects an error, it sends information about this to the transmitting side using a special data block.
The T = 1 protocol uses three different block types. Each block has the same structure, but with its help different tasks are solved.
Information block (Information block, or I-block). The block is used to transfer information between card and terminal applications. The information block also serves as a confirmation of the receipt of the block from the receiving side.
Receive ready block, or R-block. This block is used to transmit either a positive or negative acknowledgment receipt from the receiving side to the transmitting side. A positive receipt indicates that the block was received correctly, and a negative receipt indicates that an error was detected in the received block.
Administrative block (Supervisory block, or S-block). This block is used to transfer control information between the card and the reader.
Each block of the T = 1 protocol includes three fields (Fig. 2.8).
| Introductory field | Information field | Final field | ||
| Nodal address NAD | Control byte RSV | Data length LEN | APDU | Error detection LRC / CRC |
| 1 byte | 1 byte | 1 byte | 0 to 254 bytes | 1 or 2 bytes; in accordance with EMV - 1 byte |
Rice. 2.8. Components of the protocol block T = 1
Introductory field. Mandatory block field with a length of 3 bytes. It includes the following three elements, each one byte in size:
NAD - node address (Node Address);
PCB - Protocol Control Byte;
LEN - Data Length.
Information field. An optional block field up to 254 bytes long. It is intended for transmission of applied commands and responses to commands.
Final field. Mandatory block field, 1 or 2 bytes long. This field contains a check sequence for error detection. If the sequence is the LRC longitudinal redundancy symbol, then the final field is one byte. If the check sequence is generated by a cyclic code, then the size of the final field is 2 bytes.
The EMV standard uses the LRC longitudinal redundancy symbol for error detection, and therefore the final block field is 1 byte.
The NAD element of the introductory field is used to indicate 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) in the case of using multiple logical channels between the transmitting and receiving sides.
In a situation where a single logical channel is used between the transmitting and receiving sides, the values of the SAD and DAD bits are set to zero. Bits 4 and 8 of the NAD byte, which are not used for encoding SAD or DAD, are used to convey information that controls the programming voltage VPP.
The PCB control byte is used to indicate the block type and control the block transfer. The two most significant bits of the PCB byte are used to designate different types of blocks:
- the most significant bit, equal to 0, denotes an information block;
- the two most significant bits, equal to 1, designate the administrative block;
- Most significant bit equal to 1 and next bit equal to 0 denote a receive ready block.
The LEN element defines the number of bytes in the information field of the block. The LEN value ranges from 0 to 'FE'h, i.e. the maximum number of bytes in the information field is 254.
To set some parameters of the T = 1 protocol used to control data transmission, the interface symbols TA (3), TB (3), TC (3), obtained by the reader from the ATR sequence, are used.
Thus, the TA symbol (3) determines the size of the information field of the T = 1 protocol block 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 transmitted by the reader to the card is also 32 bytes by default and can be changed by the reader using the administrative block transmitted to the card.
Bits 4-1 of the TB symbol (3) define the CWI parameter (the default value is 13), which in turn sets the CWT (Character Waiting Time) parameter, which is defined as the maximum allowable time between the first two bits of two consecutive characters of the same block. The CWT parameter can be used to determine the error in the length of the received block.
Bits 8-5 of the TB symbol (3) define the BWI parameter (default value is 4). The BWI parameter sets the BWT (Block Waiting Time) value, which is defined as the maximum allowable time between the moment when the last character of the block sent by the reader starts to be transmitted and the moment when the first character of the next block received by the reader from the card begins to be received. The BWT parameter can be used to determine if 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 character of a block is transmitted and the moment when the first character of the next block sent in the opposite direction is received.
Parameters CWT and BWT are determined by the following formulas:
CWT = (2 CWI + 11) ETU;
BWT = (2 BW1 • 916 • 372 ' D + 11] • etu,
I f) '
where / is as before, the clock signal frequency CLK.
If bit 1 of the TC (3) interface symbol is 1, this means that a cyclic code is used to detect errors in the block. If this bit is 0, then the longitudinal redundancy symbol (EMV case) is used for error detection.
The T = 1 protocol is more advanced and therefore more complex in comparison with the byte protocol. This protocol uses a more efficient error detection and correction algorithm applied at the data block level. In comparison with the case of the T = O protocol, this efficiency is confirmed by the fact that in the T = 1 protocol, the use of a CRC-code makes it possible to reliably detect all errors of odd multiplicity. The procedure for notifying the transmitting side about an error in the block transmitted by it is also more efficient.
The T = 1 protocol allows organizing several logical channels between the card and the terminal, as well as transmitting several commands in one information block. According to ISO 7816-4, a logical channel is considered as a separate communication channel with some directory of the card file system. The terminal can establish up to four logical communication channels with the card. The channel number (from 0 to 3) is encoded by bits bl and b2 of the CLA command byte. At the logical level, data transfer over any two channels occurs independently.
The ability to transmit multiple commands in one TPDU is useful, for example, when the terminal reads card data. In this case, multiple READ RECORD commands can be sent in one TPDU at once. This allows, among other things, to save on data transfer time. Indeed, when using the T - 1 protocol, to transfer X bytes of information, you will need to transfer 40 + THEM bits (40 bits are obtained from 3 bytes of the header and 2 bytes of the CRC code check sequence, 11 bits are required in the T = 1 protocol to transfer one byte of information) ... When using the T = 0 protocol, to transfer the same X bytes of information, 12X bits will need to be transmitted. It follows that when transferring more than 40 bytes of information, the T = 1 protocol turns out to be faster than the T = 0 protocol.
The higher efficiency of the T = 1 protocol in comparison with the T - 0 protocol is manifested in the case when large amounts of data are transferred between the card and the reader and / or the quality of the reader is not high enough.
At the same time, for the higher efficiency of the T = 1 protocol, one has to pay with the resources of the card. 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 space 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 when an error is detected in the block transmitted by the card.
2.4.3. Application protocols
The ISO / IEC 7816-4 standard defines the functions used by smart card and terminal applications when performing a transaction. It describes two classes of functions.
First, the commands available to the terminal program for working with information stored in the file system of the card are defined.
Second, security functions are defined that can be used to restrict access to application functions and map files, and secure data exchange. These functions include authentication of the card and the external program that works with the card, ensuring the integrity and confidentiality of information transmitted in a command directed to the card, checking the cardholder's PIN.
As already mentioned, card and terminal applications use APDUs (Application Protocol Data Units) to exchange data. The structure of the APDU is defined by the ISO 7816-4 standard. APDUs are exchanged using the T - 0 or T = 1 link layer protocols. The card application interprets the APDUs and performs the operations they define. The architecture of the data exchange system between the card and terminal applications is shown in Fig. 2.9.
Rice. 2.9. Application-level communication architecture
For the command set defined in ISO 7816-4, see 3.10.
