In addition to commands for identifying the cardholder, there is a further set of commands for authenticating the terminal and the card. Since each of these communications partners is equipped with a complete computer, the procedures can be made much more complex, and thus more secure, than those used for PIN verification. In PIN verification, the card receives a secret code in plaintext (the PIN) via the interface, and it only has to compare this with the PIN held in memory. Tapping the transmission line would thus have fatal consequences. Modern authentication procedures are designed to make such attacks impossible. In principle, authentication involves verifying a secret known to both of the communicating parties without requiring it to be sent across the interface. The procedures are constructed such that tapping the data transmission would not compromise the security of the authentication. Depending on the operating system, various commands are available for authenticating the card or the terminal, or both at the same time. For the sake of clarity, here and in the rest of this chapter we refer to authentication between the card and the terminal. However, in terms of information technology what actually happens is that the ‘outside world’ authenticates itself with respect to an application in the card. This does not involve verifying that the card as a whole is genuine, but only that the embedded microcontroller shares a secret with the external world. This should be taken into account in certain applications. In many operating systems, the keys used for authentication are protected by a retry counter. If a terminal unsuccessfully attempts authentication too many times, the card blocks the associated key for further authentication tests. This is a perfectly acceptable procedure with regard to system security, but it does have one drawback. Resetting the retry counter for the authentication key to its initial value often involves very complex, logistically cumbersome and costly administrative procedures. Consequently, some systems do not have retry counters
for authentication keys.

For security reasons, only card-specific keys should be used for authentication. These keys can be generated from a unique feature of the card. A serial number or chip production number is very suitable for this purpose. Such non-confidential (and thus public) numbers can be read from the card using a suitable command. There is presently no standard in this regard; here we use the GET CHIP NUMBER command. The name varies from one operating system to the next, as do the data that are exchanged. Here we are only interested in the functionality. The command GET CHIP NUMBER obtains a unique serial number from the card, which in light of the DES algorithm should preferably be eight bytes long. This number is used to uniquely identify the chip and to compute card-specific keys. There is one more command that is needed for authentication. This is GET CHALLENGE, which is specified in ISO/IEC 7816-4. It is used to request a random number from the card. This number is subsequently used during authentication. When DES authentication is used, the length of the number is typically eight bytes, but it may be different for other cryptographic algorithms In order to make the following examples relatively easy to understand and avoid unnecessary complexity, we have omitted describing the derivation of the card-specific key. However, deriving card-specific keys is absolutely essential for reasons of security. The INTERNAL AUTHENTICATE command allows the terminal to authenticate a card, or in the case of a multiapplication card, to authenticate an application. This command can be used to verify that a card is genuine. The card receives a random number, which it encrypts using a cryptographic algorithm such as DES using a key that is known only to it and the terminal. The result of this encryption is returned to the terminal in the response. The terminal performs the same encryption as the card and compares its result with the result in the response received from the card. If the two results match, it follows that the card also knows the secret authentication key and must be genuine. The card has thus been authenticated. This command implements the classic challenge–response procedure for authenticating a communications partner. The exact data content of the challenge is not specified in detail in the ISO/IEC 7816-4 standard. The only thing that is standardized is that the value sent to the card must be random and session-specific. Consequently, when the INTERNAL AUTHENTICATE command and the other authentication commands described below are used in an application, a detailed specification is always necessary to ensure that they can be used interoperably. The terminal uses the EXTERNAL AUTHENTICATE command to show the card that it is connected to a genuine terminal. This command must be initiated by the terminal, since the communications process must always operate within the command–response framework. However, the card can force terminal authentication by blocking access to certain files until the terminal has been successfully authenticated.

This authentication is performed as follows. First, the terminal sends a GET CHALLENGE command to request a random number from the card, which it then encrypts using a secret key. Using the next command, EXTERNAL AUTHENTICATE, the terminal returns the encrypted random number to the card. The card performs the same encryption using the secret key, which it also knows, and then compares the result with the value received from the terminal. If they match, the terminal must also possess the secret authentication key and is thus genuine. After successful terminal authentication, the operating system changes the state of its state machine. This allows the terminal to access certain files for reading or writing. For the user, this is the visible result of an external authentication. If the INTERNAL AUTHENTICATE and EXTERNAL AUTHENTICATE commands are executed one after the other, the communicating parties are mutually authenticated. Each one thus knows that the other one is genuine. However, this requires a total of three complete command sequences. In order to simplify this complicated and time-consuming procedure, the three commands and their data have been merged into a single command, which is called MUTUAL AUTHENTICATE. This command is defined in the ISO/IEC 7816-8 standard. It can be used to perform mutual authentication of two parties in accordance with the ISO/IEC 9798–2/3 standard. Using a single authentication command also increases the security of the overall procedure, since it prevents the fraudulent insertion of commands between two one-way authentications.Afurther improvement in the security of the procedure results from the fact that it is impossible to obtain plaintext–ciphertext pairs by tapping the communications between the terminal and the card, which would otherwise provide an ideal basis for an attack.

Mutual authentication works as follows. First, the terminal uses the GET CHALLENGE command to request the chip number of the card. It can then compute the card-specific key. The terminal then uses the ASK RANDOM command to obtain a random number from the card, and it generates its own random number. After the terminal receives the random number from the card, it combines the two random numbers and the chip number to form a single data block, which it encrypts using the secret authentication key and a cryptographic algorithm in CBC mode. It sends the resulting ciphertext block to the card, which decrypts it and compares the chip number and the random number with the numbers it previously sent to the terminal. If they match, the terminal has been authenticated. Now the card swaps the two random numbers, deletes the chip number and again encrypts the resulting block using the secret key. After the terminal has received and decrypted this block, it can determine whether the card possesses the secret authentication key by comparing the known random numbers. If they match, the card is also authenticated.