Protection: online behavior
Terminals with integrated security modules can be used fully autonomously to operate applications using smart cards. Of course, periodic uploads and downloads to and from the background system are still necessary, but they usually occur only infrequently. However, in the case of a relatively large application with a large number of cards in circulation, it must at least be possible for a terminal to quickly make a connection to the background system if necessary, in order to provide direct end-to-end communication between a smart card and the background system. The importance of this increases with the size of the system and the scope of the benefit an attacker can obtain by means of fraud. This is because a direct communications link to the smart card allows the background system to access the current database of the card and block the card if necessary. In addition, the keys stored in the background system are significantly more secure than the keys stored in the many terminals in the field, even if the terminals have security modules. The background system can also produce good statistical evaluations of the card data it receives via sporadic end-to-end links to the smart cards. All of these arguments are naturally particularly relevant to electronic purses based on smart cards. The ‘urge’ to go online can be triggered by random variables and timing windows stored in the smart card. An equally effective method is to use a counter in the card to demand an online connection with mutual authentication after a certain number of offline transactions have taken place or if the value of the offline transaction exceeds a certain level. At the end of the session, the background system can reset the counter or alter the values of the parameters that control the online behavior of the card.

Protection: blacklists
It is impossible to fully eliminate the possibility of counterfeit smart cards being used in a system, no matter how well the cards may be protected against attacks. A smart card system must also incorporate effective mechanisms to protect users by blocking stolen cards throughout the entire system. The methods used for this purpose are strongly dependent on the application in question and the design of the system, but they can all be reduced to a few basic techniques. In order to prevent forged or lost smart cards from being used, it is necessary to maintain lists that identify either valid cards or invalid cards by means of some unique feature. This feature is usually a number, such as the card number. From the perspective of impeccable system design, which requires everything that is not explicitly permitted to be implicitly prohibited, a list of valid cards would be best. However, in a large system such a ‘whitelist’ would be awkwardly large and would require very frequent updating. This can be easily illustrated by noting that in a system with 10 million smart cards and an 8-byte card number, the whitelist would contain 80 MB of data. This is why blacklists are used in practice. A blacklist records all cards that have been blocked. In the example just mentioned, the size of the list would be reduced to 800 KB if the number of blocked cards is 1% of the total. However, if it is necessary to block significantly more than 1% of the cards in the system, due to attacks or lost cards, the size of the list would quickly become impractical even with this approach. In order to further reduce the number of data transfers and the amount of data that must be transferred between the system that maintains the list and the system that tests cards against the list, ‘red lists’ are occasionally used as well. A red list identifies cards that are demonstrably forged and thus should be immediately confiscated or at least blocked for all further transactions. The number of entries in such a list lies in the two- or three-figure range, even in large systems. Smart cards can be checked against these lists in real time with systems that work online. With systems that work partially or fully offline, updated blacklists and red lists must be transferred to the terminals as often as possible. This should occur at least daily, since a protective mechanism based on a blacklist will otherwise not be effective.

Attack and defense: computer viruses and Trojan horses
Until recently, computer viruses were entirely unknown with smart cards, since there was no technical provision for downloading program code while the card was in use. Modern smart card operating systems, however, have mechanisms that allow program code to be downloaded to smart cards after they have been issued to cardholders, and then executed. This means that in principle, the conditions necessary for the existence of computer viruses in smart cards have been created. By definition, a computer virus is a program that can reproduce itself and thus spread to other computers. If such a program cannot reproduce itself, it is called a Trojan horse. Both types of program have in common that under certain circumstances they can perform unauthorized actions in the host computer. With a smart card, this could involve reading and outputting the values of secret keys. Unlike the situation with normal PCs, it is not a straightforward task to load a program into the memory of a smart card and then execute it. There are security mechanisms in the card that prevent programs from being run without authorization. For example, some applications may require prior authentication of the terminal. In addition, it is usually necessary to use at least a MAC or a digital signature to load program code into a smart card. Some smart card operating systems also use software or hardware to mutually isolate the memory regions used by individual applications, so that the applications in the smart card cannot affect each other. As a result of these strong security measures, it is unlikely that computer viruses or Trojan horses that are unintentionally downloaded when the card is already in use will be able to impair the functions or security of any applications within the foreseeable future.

Attack and defense: exhaustive key search
One possible type of attack at the cryptographic level is an exhaustive search for a key. For this, the attacker needs a plaintext–ciphertext pair (or better yet, several pairs), and naturally he has to have the appropriate cryptographic algorithm. He or she then encrypts the given plaintext using each possible key in turn until the given ciphertext is obtained. This key can then be tested with all other plaintext–ciphertext pairs on hand. If correct encryption can be performed in each case, the key that has been identified is most likely the correct key. This procedure is basically suitable for all encryption algorithms, although it is not always the fastest method for determining the value of the secret key. As early as 1993, MichaelWiener published plans for a special computer with a stated cost of one million dollars that could test all DSS keys for a given plaintext–ciphertext pair within seven hours [Wiener 93]. This would allow the value of a 56-bit DES key to be determined in 3.5 hours on average. A few years later, in 1997, the DES key for a plaintext–ciphertext pair provided by RSA Inc was determined in 97 days by systematic searching, using more than 70,000 computers interconnected via the Internet [RSA 97]. The search rate during the final phase of this experiment amounted to around 0.7% of the DES key space every 24 hours. Another example of the large processing capacity that can be obtained by interconnecting computers via the Internet is the SETI@Home initiative for searching for extraterrestrial life. The EFF ‘DES Cracker’, which was built as a massively parallel computer in 1998, required only 56 hours to determine an unknown DES key [EFF 98].

In practice, several different approaches are taken to counter such attacks. The simplest and best-known measure is to make the key space of the cryptographic algorithm so large that it is not possible to perform a systematic search within an acceptable length of time, even with very high processing capacity. This is why the DES algorithm has now been replaced by triple DES as a matter of principle. Compared with currently available processing capacity, the key space of the DES has simply become too small. Another defensive measure can be created very easily by constructing the application protocol such that pairs of plaintext and ciphertext do not occur. In smart card applications, in most cases it is not even necessary to encrypt the data, since it is sufficient to secure the data using a MAC. Since the mapping of multiple plaintext blocks onto a MAC is not unique, a brute-force attack using aMAC is a great deal more arduous than the same type of attack using a plaintext–ciphertext pair. If a random number is prefixed to the plaintext in the smart card (which is called ‘salting’) and the resulting data are encrypted or used to compute a MAC before being transmitted, the data to be encrypted will be different each time the function is used, so the results will also be different each time. This also makes an exhaustive search more difficult, since in many cases the random number does not have to be public. For example, it could be a secret shared by the security module and the smart card. Incidentally, a random number prefixed to the data to be encrypted within the smart card also provides very good protection against attacks using differential fault analysis (DFA) and power analysis (SPA/DPA), even if the random number is public. The task of the attacker can also be made more difficult by using dynamic keys (session keys), which are different for each encryption operation. In this case, even if the attacker manages to determine the value of the key by some happy accident, it will not be of any use to him, since the key will have changed again before the next transaction.