6.4 Data Transmission Protocols 419 Terminal SELECT FILE [FID = '3F00'] response to SELECT FILE Smart Card NAD PCB LEN EDC '00' '00' '06í 'A2'''A4 00 00 02 3F 00 TPDU APDU NAD PCB LEN EDC '00' '00' '02' 'B2''9 '0 00 TPDU APDU SELECT FILE [FID = '3F00'] response to SELECT FILE NAD PCB LEN EDC '00' '00' '06' 'A2'''A4 00 00 02 3F 00 TPDU APDU NAD PCB LEN EDC '00' '00' '02' 'B2''9 '0 00 TPDU APDU SELECT FILE [FID = '3F00'] response to SELECT FILE NAD PCB LEN EDC '00' '40' '06' 'E2'''A4 00 00 02 3F 00 TPDU APDU NAD PCB LEN EDC '00' '40' '02' 'F2''9 '0 00 TPDU APDU Figure 6.38 Successful transmission of a TPDU using the T = 1 transmission protocol. The XOR option is used for the error detection code (EDC). A SELECT FILE command with a FID of '3F00', which selects the MF, is transmitted in the APDU. The incrementing of the send sequence count in the PCB byte for each transaction, and the corresponding changes in the EDC, can be readily seen used. The elaborate error correction mechanisms are a typical example. Although they may be theoretically interesting, in many cases they are ineffective in dealing with actual transmission errors. In practice, it is usually better to simply reinsert the card in the terminal and start a new session, rather than using innumerable resynchronization requests to attempt to restabilize communications. Consequently, the EMV specification imposes several restrictions relative to the original ISO/IEC standard, as summarized in Table 6.40. 6.4.4 The T = 14 transmission protocol (Germany) The ISO/IEC 7816-3 standard includes a tag in the ATR for designating a national transmis- sion protocol. Such a transmission protocol is designated T = 14. With the introduction of the C-Netz for mobile telephony and card phones in Germany, a protocol was needed for communicating with the smart cards used in these systems. The character-oriented T = 0 protocol was considered undesirable, and at that time there was not yet a standardized block- oriented protocol. Consequently, in 1987 Telekom decided to use a protocol developed by a DIN working group. This protocol received the designation T = 14, which simply means that it is a country-specific implementation. It had no significance outside of Germany, but it had 420 Smart Card Data Transmission Table 6.40 Summary of the differences in the implementation of the T = 1 transmission protocol between the ISO/IEC 7816-3 standard and the EMV specification Mechanism or option ISO/IEC 7816-3 EMV BWT expired Reset the card (for example) Deactivate the card Smart card sends a request Allowed A maximum of three to change the IFS successive requests is allowed Smart card sends an S block Allowed Deactivate the card with an abort request Zero-length I block Allowed Prohibited Terminal sends three Behavior according to Deactivate the card successive blocks without specified error handling; receiving a valid response usually a resync request enormous influence on the development of the internationally standardized T = 1 protocol, since the T = 14 protocol formed the principal foundation for this protocol. The T = 14 protocol was used extremely widely in Germany, since it was employed in the C-Netz mobile telecommunications network and public card phones. With the closing down of the C-Netz at the end of 2000 and the change to the T = 1 protocol for public card phones, the T = 14 protocol is no longer an important protocol in Germany, which is why it is described here only briefly. The T = 14 protocol has a block-oriented structure and works asynchronously using the applied clock signal. The divider (clock rate conversion factor) has a value of 512, which yields a data transmission rate of 9600 bit/s at a clock frequency of 4.9512 MHz. Data transmission at layer 2 (the data link layer) always takes place using the direct convention. The size of the buffers for transmitted and received blocks must be at least 50 bytes, with a maximum value of 255 bytes. There is no block chaining mechanism. 6.4.5 The USB transmission protocol A future amendment to the ISO/IEC 7816-3 standard will contain a specification for a new transmission protocol for smart cards. This is the Universal Serial Bus (USB) protocol, which has come to prevail over competing protocols, such as Firewire and the like, for use with smart card applications. The USB protocol requires a special hardware component in the smart card microcontroller, but this component is already present in many chips, at least as an option. The major advantage of USB with respectto currently used transmission protocols is that it is an established industrial standard coming from the PC world. USB also offers a higher transmission rate than T = 0or T = 1. It presently appears that Version 1.1 of the USB specification will be used for smart cards, with both the low-speed option (1.5 Mbit/s) and the full-speed option (12 Mbit/s) being sup- ported, depending on the type of microcontroller. It should be noted that the effective trans- mission rate is significantly lower than the stated values once the required protocol data have been subtracted. USB Version 2.0, which has a data transmission rate of up to 480 Mbit/s (in the high-speed mode), will not be used in the foreseeable future. 6.5 Message Structure: APDUs 421 Contacts C4 (AUX1) and C8 (AUX2), which up to now have been specified but not used, will be used to implement the USB interface in smart cards. Further details will be specified in the above-mentioned standard, but it can be expected that it will take several years until all of the related standardization work is completed. 6.4.6 Comparison of asynchronous transmission protocols With regard to comparing the various transmission protocols, a brief remark with regard to achievable data transmission rates is in order. Attempts are often made to compare the T = 0 and T = 1 protocols based on calculated effective transmission rates. However, such calculations are only valid for specific commands in specific contexts. If they are generalized, they become meaningless and invalid. Both protocols have their strengths and weaknesses with regard to achievable transmission rates. These are strongly dependent on very many individual factors, such as the transmission error rate, the size of the I/O buffer in the card and the specific implementation of the protocol. In short, it can be assumed that on average and with most applications, the effective transmission rates of both protocols are nearly the same. If you want to increase the transmission rate, changing the protocol will have little effect. It is more effective to reduce the divider value, since this yields significantly better results. Two international transmission protocols have been described in the previous sections. In order to provide an overview, Table 6.41 summarizes the essential features of these protocols, as well as their advantages and disadvantages. Table 6.41 Comparison of internationally standardized asynchronous data transmission protocols Criterion T = 0T= 1T= 2 (proposed) Data transmission asynchronous, asynchronous, asynchronous, half-duplex, half-duplex, full-duplex, byte-oriented block-oriented block-oriented Standard ISO/IEC 7816-3, ISO/IEC 7816-3, ISO/IEC 10536-4 GSM 11.11, EMV EMV Divider freely definable, freely definable, freely definable, usually 372 usually 372 usually 372 Block chaining not possible possible possible Error detection parity bits parity bits, parity bits, EDC at end of block EDC at end of block Memory required ≈300 bytes ≈1100 bytes ≈1600 bytes for implementation 6.5 MESSAGE STRUCTURE: APDUs Applications protocol data units (APDUs) are used to exchange all data that passes between the smart card and the terminal. The APDU is an internationally standardized data unit for the application layer, which is layer 7 in the OSI model. In smart cards, this layer is located directly 422 Smart Card Data Transmission above the transmission protocol layer. The protocol-dependent data units of the transmission protocol layer are called ‘transmission protocol data units’ (TPDUs ). A distinction is made between command APDUs (C-APDUs), which represent commands to the card, and response APDUs (R-APDUs), which represent replies to these commands from the card. In simple terms, an APDU is a sort of container that holds a complete command to the card or a complete response from the card. APDUs are passed by the transmission protocol transparently, which means without modification or interpretation. APDUs that comply with the ISO/IEC 7816-4 standard are intended to be independent of the transmission protocol. Consequently, the content and format of an APDU must not change when a different transmission protocol is used. This applies above all to the two standard protocols, T = 0 and T = 1. This demand for protocol independence affects the structure of the APDUs, since it must be possible to transmit them transparently using both the byte-oriented T = 0 protocol and the block-oriented T = 1 protocol. 6.5.1 Structure of the command APDU A command APDU is composed of a header and a body. The body may have a variable length, or it may be entirely absent if the associated data field is empty. CLA INS P1 P2 Lc field Le fielddata field header body Figure 6.39 Structure of a command APDU The header consists of four elements, which are the class byte (CLA), the instruction byte (INS) and two parameter bytes (P1 and P2). The class byte is also used to identify applications and their specific command sets. For instance, the class byte'A0' is used for GSM, while the code '8X' is most commonly used for company-specific (private-use) commands. ISO-based commands are coded by class byte '0X'. The standard additionally specifies the class bytes to be used to indicate the use of secure messaging and logical channels. All of this is still compatible with using the class byte as an application identifier. The next byte in the command APDU is the instruction byte, which encodes the actual command. Almost the entire address space of this byte can be exploited, with the sole restriction that only even codes can be used. This is because the T = 0 protocol allows the programming voltage to be activated by returning the instruction byte incremented by one in the procedure byte. The instruction byte thus always has had an even value. 17 The two parameter bytes are primarily used to provide more information about the command selected by the instruction byte.They thus serve mainly as switches that select various command options. For example, they are used to choose various options for SELECT FILE or specify the offset for READ BINARY. 17 See also Section 16.11.5, ‘The most important smart card commands’ 6.5 Message Structure: APDUs 423 Table 6.42 The most important class byte (CLA) codes according to ISO/IEC 7816-4 b8–b5 b4 b3 b2 b1 Meaning . . . . . . . . . X X Logical channel number . . . 0 0 . . . . . . Secure messaging not used . . . 0 1 . . . . . . Non-ISO secure messaging using a private method . . . 1 0 . . . . . . ISO secure messaging, header not authentic . . . 1 1 . . . . . . ISO secure messaging, header authentic '0' . . . . . . . . . . Structure and coding compliant with ISO/IEC 7816-4/7/8 '8','9' . . . . . . . . . . . . Structure compliant with ISO/IEC 7816-4, user-specific coding and meaning of commands and responses (private use) 'A' . . . . . . . . . . . . Structure and codes compliant with ISO/IEC 7816-4, specified in supplementary documents (e.g. GSM 11.11) 'F' 1111Reserved for PPS Table 6.43 Summary of the assignment of class bytes to applications Class Application '0X' Standard commands compliant with ISO/IEC 7816-4/7/8 '80' Electronic purses compliant with EN 1546-3 '8X' Application-specific and company-specific commands (private use) '8X' Credit cards with chips, compliant with EMV 'A0' GSM mobile telecommunication systems compliant with GSM 11.11 The section following the header is the body, which can be omitted except for a length specification. The body serves a dual function. First, it specifies the length of the data section sent to the card (in the Lc field) 18 and the length of the data section to be sent back from the card (in the Le field). 19 Second, it contains the data for the commands that are sent to the card. If the value of the Le field is'00', the terminal expects the card to return the maximum amount of data available for the command. This is the only exception to the numerical description of the length. The Le and Lc fields are usually one byte long, but they can be converted into fields that are each three bytes long. Such fields can be used to represent lengths up to 65,536, since the first byte contains the escape sequence'00'. The standard defines this three-byte length specification for future applications. Due to the limitations of currently available memory sizes, it has not yet been implemented. The previously described parts of the command APDU can be combined to produce the four general cases illustrated in Figure 6.41. 18 ‘Lc’ stands for ‘length command’ 19 ‘Le’ stands for ‘length expected’ 424 Smart Card Data Transmission '00' byte 1 byte 2 byte 3 Le/Lc (MSB) Le/Lc (LSB) Figure 6.40 Structure of an extended Lc or Le field header header header header case 1 case 2 case 3 case 4 Le field Lc field Lc field Le field data field data field Figure 6.41 The four possible command APDU cases 6.5.2 Structure of the response APDU The response APDU, which is sent by the card in reply to a command APDU, consists of an optional body and a mandatory trailer, as shown in Figure 6.42. The body consists of the data field, whose length is specified by the Le byte of the preceding command APDU. Regardless of the value specified in the Le byte, the length of the data field can be zero if the smart card terminates command processing due to an error or incorrect parameters. This is indicated in the two single-byte status words SW1 and SW2 in the trailer. SW1 SW2 data field trailerbody Figure 6.42 Structure of the response APDU type 1 SW1 SW2 type 2 SW1 SW2data field Figure 6.43 The two types of response APDUs 6.6 Securing Data Transmissions 425 The card must always send a trailer in response to a command. The two bytes SW1 and SW2, which are also called the ‘return code’, encode the response to the command. For example, the return code'9000' means that the command was executed completely and successfully. There are more than 50 different codes. Their basic classification scheme is shown in Figure 6.44. 20 return code (SW1 || SW2) process completed process aborted warning processing execution error checking errornormal processing '61XX' '9000' '62XX' '63XX' '64XX' '65XX' '67XX' to 6FXX'' Figure 6.44 Return code classification scheme as defined by the ISO/IEC 7816-4 standard. The return codes '63XX'and'65XX' indicate that data in non-volatile memory (EEPROM) have been altered, while the remaining '6X' codes indicate that this has not occurred If a '63XX' or '65XX' return code is received after a command has been executed, this means that the card’s non-volatile memory (usually the EEPROM) has been modified. If another code starting with '6X' is returned, command execution was terminated prematurely without modifying the non-volatile memory. It should be noted that although there is a standard for return codes, many applications use non-standard codes. The only exception is the code'9000', which almost universally indicates successful processing. With all other codes, it is always necessary to consult the relevant specification in order to be sure of their meanings. 6.6 SECURING DATA TRANSMISSIONS The entire data exchange between a terminal and a smart card uses digital electrical pulses on the I/O line of the smart card. It is conceivable and not technically difficult to solder a wire to the I/O contact, record all the communications for a session and later analyze them. In this way, it is possible to gain knowledge of all the data transmitted in both directions. A somewhat more difficult task is to electrically isolate the I/O contact, mount a dummy contact on top of it, and then use thin wires to connect both of these contacts to a computer. With this arrangement, it is easy to allow only certain commands to reach the card or insert ‘foreign’ commands into the communications sequence. Both of these typical types of attack can succeed only if secret data passes unprotected over the I/O line. Data transmission should thus basically be designed such that even if an attacker 20 See also Section 16.10.8, ‘Smart card return codes’ 426 Smart Card Data Transmission is able to eavesdrop on data transmissions and insert his own message blocks, he will not be able to gain any advantage from doing so. There are various mechanisms and methods that can be used to protect against these attacks and against even more sophisticated types of attack. They are collectively referred to as ‘secure messaging’. These mechanisms are not specific to smart cards, and they have been used for a long time in data communications systems. What is special in the smart card domain is that neither the processing capacity of the communicating parties nor the transmission rate is particularly great. Consequently, commonly used standard methods have been scaled down to match the capabilities of smart cards, without in any way reducing the security of these methods. The objective of secure messaging is to ensure the authenticity, and if necessary the con- fidentiality, of part or all of the transmitted data. A variety of security mechanisms are used to meet this objective. A security mechanism is defined as a function requiring the following items: a cryptographic algorithm, a key, an argument and initial data as necessary. A general condition must also be satisfied, which is that all security mechanisms must behave completely transparently with regard to existing protocol layers, in order to ensure that existing, standard- ized procedures are not adversely affected by secure messaging. This applies particularly to the two transmission protocols T = 0 and T = 1, as well as to commonly used standard smart card commands. Before using a secure messaging method, both parties must agree on the cryptographic algorithm to be used and a common secret key. According to Kerckhoff’s principle, the security of the method relies entirely on this key. If it is revealed, secure messaging is reduced to a generally known additional checksum that decreases the effective data transmission rate and at best can be used to correct transmission errors. Several different types of secure messaging methods have been known for many years. They are all relatively rigid and tailored to specific applications. Most of them cannot be faulted as far as security is concerned. However, none of them has become internationally predominant or has proved to be sufficiently flexible to be included in current standards. Security mechanism key cryptographic algorithm initial data (optional) argument Figure 6.45 The data and functions required for a security mechanism The requirements of transparency with respect to existing commands, use with two fun- damentally different transmission protocols and maximum adaptability have led to the stan- dardization of a very flexible (and correspondingly complex and elaborate) secure messaging method in the ISO/IEC 7816-4 standard, with additional related functions defined in ISO/IEC 6.6 Securing Data Transmissions 427 7816–8. 21 This method is based on embedding all user data in TLV-coded data objects. Three different types of data objects are defined: r data objects for plaintext: contains data in plaintext (e.g., the data section of an APDU) r data objects for security mechanisms: contains the results of a security mechanism (e.g., a MAC) r data objects for auxiliary functions: contains control data for secure messaging (e.g., the padding method used) The class byte indicates whether secure messaging is used for the command. The two available bytes can encode whether the method specified in ISO/IEC 7816-4 is used and whether the header is also included in the cryptographic checksum (CCS). 22 If the header is included in the computation, it is authentic, as it cannot be changed during the transmission without this being evident. Data objects for plaintext According to the standard, all data that are not BER-TLV coded must be encapsulated, which means they must be embedded in data objects. Several different tags are used, as shown in Table 6.44. Bit 1 of each tag indicates whether the data object is included in the computation of the cryptographic checksum. If this bit is not set (e.g.,'B0'), the data object is not included in the computation, while if it is set (e.g.,'B1'), the data object is included. Table 6.44 Tags for plaintext data objects Tag Meaning 'B0','B1' BER-TLV coded; contains data objects related to secure messaging 'B2','B3' BER-TLV coded; contains data objects not related to secure messaging '80','81' No BER-TLV coded data '99' State information for secure messaging Data objects for security mechanisms The data objects used for security mechanisms are divided into those used for authentication and those used for confidentiality. The tags defined for this purpose are listed in Tables 6.45 and 6.46. Here ‘authenticity’ refers to all data objects related to cryptographic checksums and digital signatures. Data encryption, and marking such data as encrypted in the context of secure 21 Secure messaging is usually abbreviated to ‘SM’, which many programmers interpret as ‘sado-masochism’ on account of the many degrees of freedom and room for interpretation provided by these two standards 22 For the coding of the class byte, see Section 6.5.1, ‘Structure of the Command APDU’ [...]... Figure 7.1 The most important standards and specifications for smart card commands ISO/IEC 7816-4/7/8/9, EMV 2000, GSM 11.11, TS 311.111, EN 726–3 and EN 154 6–3 Extensive tables listing the coding of the most important smart card commands can be found in Section 16.10.7, Smart card command encoding’ Naturally, it is impossible to buy a single smart card anywhere in the world that contains all the commands... controversial, since they can potentially be used to bypass the entire security system of a smart card 7 .5 Identification Commands 453 Smart card Terminal   command processing Response [subtracted value = 3 || new value = 7 || return code]     command processing Response [subtracted value = 2 || new value = 5 || return code]     command processing Response [added value = 5 || new value = 10 || return... by the terminal to the card are the commands to the card The terminal also receives the responses to its commands in APDUs embedded in the transmission protocol There are a large number of commands based on this mechanism, and they initiate specific activities within the card The simplest examples are read and write commands for smart card files In smart card applications, the card is used as a data... following sections describe the most important and most widely used smart card commands The basis for this selection is formed by the following standards and specifications: Smart Card Commands 437 Standards and specifications for smart card commands general payment systems ISO/IEC 7816-7 (SCQL) EMV 2000 (credit & debit cards) EN 154 6 (electronic purses) ISO/IEC 7816-8 (cryptographic functions) CEPS... relative to the competition, or to deny their competitors access to a particular application area, by using commands that are Smart Card Handbook, Third Edition W Rankl and W Effing C 2004 John Wiley & Sons, Ltd ISBN: 0-470- 856 68-8 436 Smart Card Commands highly optimized with regard to card functions and memory usage In any case, a decision to use commands based on available standards always means choosing... Smart card command encoding’ Some commands are supported by nearly all smart card operating systems and have only a limited number of options For such commands, the command and response APDUs are fully decoded in their descriptions The internal processing sequences of seven typical commands are also shown in psuedocode in Chapter 5 in the description of the ‘Small OS’ operating system 438 Smart Card. .. highest-performance types of currently available smart card microcontrollers 23 24 See also Section 6 .5. 1, ‘Structure of the command APDU’ There is a proposal to revise and upgrade the ISO/IEC 7816-3 standard to increase the number of possible logical channels to eight by using an additional RFU bit 7 Smart Card Commands Communications procedures between a terminal and a smart card are always based on the master–slave... securely transferring electronic funds between two electronic purses in the same card The potential utility of logical channels for applications is matched by the difficulties that their management entails for the smart card operating system In principle, each logical channel represents nothing less than a separate smart card, with all of its states and conditions This effectively means that the operating... transmission Figure 7.3 Classification of smart card commands that are primarily used for administrative functions (before and after the smart card is in actual use) we have generally used the standard that has the largest number of functional options for the command in question 7.1 FILE SELECTION COMMANDS Without exception, file management in all modern smart card operating systems is objectoriented... for smart card file management This non-compliance dates back to the historical emergence of commands that were subsequently incorporated into current standards The precursors of smart cards, which are memory cards, have only one memory region that can be read and written using offset and length parameters Externally, this memory can be regarded as a single file with a transparent structure The first smart . commands that are Smart Card Handbook, Third Edition. W. Rankl and W. Effing C  2004 John Wiley & Sons, Ltd ISBN: 0-470- 856 68-8 436 Smart Card Commands highly optimized with regard to card functions. initiate specific ac- tivities within the card. The simplest examples are read and write commands for smart card files. In smart card applications, the card is used as a data storage medium, an. EMV BWT expired Reset the card (for example) Deactivate the card Smart card sends a request Allowed A maximum of three to change the IFS successive requests is allowed Smart card sends an S block