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 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 confidentiality, 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, standardized 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 toKerckhoff’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. The requirements of transparency with respect to existing commands, use with two fundamentally different transmission protocols and maximum adaptability have led to the standardization 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/IEC7816–8. 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). 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. 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.

Data objects for security mechanisms
The data objects used for security mechanisms are divided into those used for authentication and those used for confidentiality. 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 messaging, fall under the heading of ‘confidentiality’. The tags listed shown in the above tables must be used for secure messaging according to the type of method used.

Data objects for auxiliary functions
The data objects for auxiliary functions are used in secure messaging to coordinate the general constraints. The two parties use these data objects to exchange information about the cryptographic algorithms and keys used, initial data and similar basic information. In principle, these items can be different for each transmitted APDU, or even between a command and its response. In practice, though, auxiliary function data objects are rarely used, since all of the general constraints for secure messaging are defined implicitly, so they do not have to be specifically defined during communications. Based on the options for secure messaging specified in ISO/IEC 7816-4, which have been only briefly outlined above, we can describe two fundamental procedures.We have kept these descriptions as simple as possible in order to make it easier to understand the complex mechanisms involved. Due to the high degree of flexibility provided by the standard, there are many other possible combinations of security mechanisms, some of which are even more complex. The two procedures described here represent a compromise between simplicity and security. The ‘authentic mode’ procedure uses a cryptographic checksum (CCS or MAC) to protect the application data (APDU) against manipulation during transmission. The ‘combined mode’procedure, by contrast, is used to completely encrypt the application data, so that an attacker cannot draw any conclusions about the data content of the commands and responses that are exchanged. A send sequence counter is only used with one of these two procedures. This counter, whose initial value is a random number, is incremented for each command and each response. This allows both parties to determine whether a command or response has been omitted or inserted. When a send sequence counter is used in combination with the ‘combined mode’ procedure, identical APDUs appear to be different. This is called ‘diversity’.