Attacks at the logical level
The main prerequisite for attacks on the security of a smart card at the logical level is knowledge of the communications and information flow between the terminal and the smart card. In this case it is not particularly necessary to understand the processes occurring at the hardware level, but rather the software processes. In terms of information technology, the sample scenarios described here are located one level above attacks that primarily exploit the properties of the hardware.

Attack and defense: dummy smart cards
Probably the simplest imaginable type of attack is to use a smart card that has been custom programmed and includes additional logging and analysis functions. Up until a few years ago, this was practically unfeasible, since only a few companies had access to smart cards and the microcontrollers used to produce them. Nowadays, though, smart cards and configuration programs can be freely purchased from a number of companies. This naturally increases the options available to an attacker. Even without this, with a certain amount of effort and dexterity it is possible to assemble a working smart card using a plastic card and a standard microcontroller in an SMD package. Such a card can at least be made to imitate the electrical interface of a real smart card and to behave the same way for data transfers. It is now possible to obtain such cards from a wide variety of sources via the Internet. New possibilities are also offered by Java technology for smart cards, which makes it easy to generate programs and load them into dummy cards. With such a dummy card, itwould be possible to record at least a part of the communications with a terminal and subsequently evaluate this information. After several attempts, it would probably be possible to perform part of the communications in exactly the same way as a genuine smart card. Whether this can be put to advantage is doubtful, since all professionally designed applications have cryptographic protection for important activities. As long as the secret key is not known, the attack will not go any farther than the first authentication. Such an attack can only be successful if the secret key is known or the complete application runs without any cryptographic protection. Should such an application exist, it is highly doubtful that any benefits that could be obtained from this type of attack would be sufficiently large to justify the necessary effort.

Analysis: determining the command set of a smart card
The instruction classes and commands that are supported by a smart card are of course not often published, but it is very easy to determine what they are. This is more interesting with regard to completely determining the command set of a smart card than it is for an attack on the security of the smart card. However, it is conceivable that an attack could be mounted on the basis of this information. The method used to determine the command repertoire is illustrated in Figure 8.38. The first step is to generate a command APDU and send it to the smart card using a freely programmable terminal. The class byte in the APDU is changed for each APDU to cover the range from ’00′to’FF’. As soon as a return code other than ‘invalid class’ is received, the first valid class byte has been determined. There are usually two or three valid instruction classes, which can then be used to try all possible instruction bytes in the next round. This consists of sending command APDUs with various instruction bytes to the smart card and noting the ones that yield a return code other than ‘unknown instruction’. If suitable software is available in the terminal, this method can be used determine which commands are supported by a particular smart card in one to two minutes. To a certain extent, a portion of the possible parameters of the commands so identified can also be determined in a similar manner. This algorithm can be made considerably faster by using only the class byte codes allowed by the ISO/IEC 7816-4 standard and allowing the instruction byte to be an indexed variable. This strongly reduces the number space of the class byte by taking secure messaging and logical channels into account. A similar improvement can be made by using only even-valued instruction bytes, since the odd-valued codes contain only the Vpp control information, which is no longer used. The reason that this simple search algorithm for instruction classes, commands and parameters can be so effective is that practically all command interpreters in smart card operating systems evaluate received commands by starting with the class byte and working through the following bytes. This process is terminated as soon as the first invalid byte is recognized, and a suitable return code is generated and sent back to the terminal. However, it can only work if the smart card does not have a global state machine that monitors the command sequence. If such a state machine is present, it is at least possible to use this procedure to determine the command sequence in a step-by-step manner. The utility of such a procedure for an attacker may not appear to be that great, since the command set is usually not secret. However, it does at least provide a simple and fast means to determine all of the available commands. It is also a very useful means for determining whether the producer of the operating system has incorporated any undocumented commands in the software.

Attack: tapping data transmissions
A slightly modified smart card can be used to tap data transmissions during a session and manipulate the data as desired. The modifications consist of gluing an insulated dummy contact on top of the I/O contact, so that the original I/O interface is no longer connected to the I/O contact. The new (dummy) contact and the original I/O contact are then connected to a fast computer.With suitable programming, this computer can delete or insert any desired data within the communications between the terminal and the smart card. If the computer is sufficiently fast, neither the terminal nor the card will detect any difference between normal and manipulated communications. It is clear that the course of a session can be radically affected using this method. Whether an attacker can derive any benefit from this method depends primarily on the application in the smart card. A well-known design principle says that eavesdropping on communications or the deletion or insertion of data in the communications stream must not be allowed to impair security. If this principle is not observed, an attacker can certainly obtain an advantage using this method. There are known cases of fraud using simulated memory cards. In order to provide protection against this type of attack, some terminals have shutters that cut off any wires attached to the smart card. Secure messaging can also be used very effectively here to allow any manipulation of the data during the data transmission to be reliably detected. Many terminals may be used only under supervision, which makes it difficult to use manipulated cards with leads to an accompanying computer in such terminals. In summary, although this type of attack can be regarded as very interesting and quite promising in theory, in practice it achieves only modest success.

Attack and defense: power interruption
A type of attack that was successful with many smart cards until recently is to interrupt the power to the card at a particular time while a command is being executed. This type of attack is based on the fact that with conventional programming, all write operations to EEPROM pages are performed sequentially. If the programmer has not been clever in arranging the order of the write operations, an attacker can derive an advantage by cutting off power at the right time. This can be briefly illustrated using a highly simplified example. In an electronic purse application, if the balance is increased before the log file is updated when processing a purse loading command, an attacker would have a good chance of being able to load a smart card for free. He would only have to switch off the power at the right time, or jerk the card out of the terminal with millisecond accuracy (!). The purse balance would then have been changed to the new value, but there would no log record for this transaction and no response to the command.With simple electronic purse systems in the past, such an attack was certainly a real possibility. In order to determine the exact time to terminate processing, the attacker only has to use an electronic counter to count the number of clock pulses after the time when the command is sent and then perform a series of experiments with increasing clock counts to determine the proper time to interrupt power to the card. It hardly needs to be said that the entire procedure can be more or less automated using a computer. Although this type of attack sounds attractive and appears to be easy to copy, in practice there are several effective countermeasures. The simplest approach is arrange the EEPROM write instructions in a carefully considered order. The EN 1546 standard for multisector electronic purses is well worth examining in this regard, since all of the electronic purses described in this standard are explicitly protected against this sort of attack. However, even a perfectly ordered sequence of write operations cannot by itself achieve absolute protection. This can be illustrated using another example. When the electronic purse of our previous example is being loaded, it may be necessary to erase the EEPROM before the write process. If the erased state of the EEPROM corresponds to the maximum value of the purse balance, which incidentally is the usual case, the purse can be artificially loaded to its maximum value by simply interrupting the power to the card at the right time. The proper moment is when the erase operation has just been completed and the write operation has not yet been started. Operating system designers know an effective countermeasure for this type of attack, which is to use atomic operations as described in detail in Section 5.10. The characteristic of an atomic operation is that it is indivisible, which means that it is performed either completely or not at all. This provides fully adequate protection against the type of attack just described. Even the optimally ordered EEPROM write operations described in the EN 1546 standard require atomic operations in several locations to prevent this type of attack from being implemented.

Attack and defense: current analysis during PIN comparison
A technically very interesting type of attack on comparison features, such as PINs, can be carried out using a combination of physical measurement of a parameter and variation of logical values. This type of attack relates to all mechanisms in which data are sent to the smart card and compared in the card with corresponding values, with a retry counter being incremented according to the result of the comparison. The attackworks on the principle of measuring the current drawn by the card, for example by measuring the voltage drop across a resistor in the Vcc lead. If a suitable command containing the comparison data is sent to the card, it is possible to see from the current measurement whether the retry counter has been incremented, even before the return code has been received. If the return code is sent before the retry counter is written when the result of the comparison is positive, this method can be used to determine the value of the reference data. This is done by sending all possible variations of the comparison value to the smart card and cutting off power to the card before the retry counter has been incremented if the result is negative. A positive result can be clearly recognized from the associated return code, which is sent before the retry counter is written. There are two basic ways to defend against this type of attack. The simplest defense consists of always incrementing the retry counter before making the comparison, and then decrementing it afterwards as appropriate. In this case, the attacker cannot obtain an advantage, regardless of when he interrupts power to the card, since the retry counter will have already been incremented. The second defense is more complicated, but it provides similar protection. In this approach, the retry counter is incremented after a negative comparison and written to an unused EEPROM cell after a positive comparison. Both of these write accesses occur at the same time in the process, so the attacker can draw no conclusions with regard to the result of the comparison. He learns the result of the comparison only after receiving the return code, and at this point it is too late to prevent a write access to the retry counter by cutting off the power.

Attack and defense: timing analysis of PIN comparisons
Programmers always give considerable attention to making programs execute as quickly as possible. Normally, this is also an important consideration. However, the fact that the execution time of a process has been optimized can be utilized for an attack that definitely has a good chance of success. If a PIN is sent to a smart card for comparison, the associated comparison routine normally compares the PIN it receives with the stored PIN value byte by byte. A programmer who is not security-conscious will program this routine such that the first difference between the two compared values causes the routine to immediately terminate and return to the calling program. This leads to minute variations in the execution time of the comparison process, which can nevertheless be measured using suitable equipment (such as a storage oscilloscope). This information could be used by an attacker to determine the secret PIN code in a relatively straightforward manner. Up to a few years ago, this was still an effective type of attack on smart cards. However, it is now a known type of attack, and comparison routines are constructed such that all digits of a PIN are always compared. Consequently, there is no time difference between positive and negative comparison results.

Protection: noise-free cryptographic algorithms
The security of smart card applications is based on secret keys used with cryptographic algorithms. In order to access the card in certain ways or perform certain operations with the card, the terminal must always first authenticate itself using a secret key. Naturally, authentication of the terminal by the card represents an attractive target for an attacker. By contrast, authentication of the card by the terminal is not attractive with respect to an attack on the card, since a smart card can be manipulated as desired using a (dummy) terminal. The smart card authenticates the terminal by sending it a random number, which the terminal then encrypts and returns to the card. The smart card then performs the same encryption and compares the result with the value received from the terminal. If the two values match, the terminal has been authenticated, and it receives a corresponding return code. If the authentication fails, the card sends a different return code. The starting point for the attacker is analyzing the processing time between when the command is sent and when the response is returned by the smart card. As late as the early 1990s, cryptographic algorithms with significant differences in execution times for different keys and plaintexts were still sometimes used. The resulting reduction of the key space can be exploited by an attacker to search for the secret key using a brute-force attack. The duration of the search is strongly dependent on the noise level of the algorithm. The size of the key space becomes smaller as the variation in execution time increases, making it easier and faster to search for the key. If the exact implementation of the algorithm on the target computer is known, this information can also be included as reference data for generating the timing tables. This type of attack was made public under the name ‘timing attack’ in a publication by Paul Kocher in 1995 [Kocher 95], which primarily deals with the time dependencies of the RSA and DSS algorithms. In principle, a timing analysis is a very dangerous threat to the security of a smart card. However, since this type of attack has been known for a relatively long time, all present-day smart cards use only noise-free cryptographic algorithms, which are algorithms for which the time required for encryption or decryption is independent of the input values. This blocks this sort of attack. However, the programmer has conflicting interests in this regard, since a noise-free algorithm usually requires more program code and is always slower than a noisy version. The reason for this is that a noise-free algorithm must be designed such that the path through the program has the same length for all combinations of plaintext data, ciphertext data and keys. This means that the longest necessary path is the reference value, and all other paths must be suitably modified to match this length. To provide additional security, in some applications all authentication keys have their own retry counters, so that only a limited number of unsuccessful authentications can be performed. Once the retry counter has reached its maximum value, the smart card blocks all further attempts at authentication.