Protective components of the smart card application
The protective mechanisms of the application are based on suitable mechanisms in the hardware and operating system. The application is dependent on having these two lower levels fully meet their obligations with regard to protection, since it cannot correct for any errors in the hardware or the operating system. For example, if it is possible to read the contents of the EEPROM using an analysis procedure, even the most complicated and secure encryption processes are of no use at all, since the keys can be taken directly from the EEPROM by an attacker. An application must nevertheless be constructed such that the entire system is not compromised in the event of a successful attack on an individual card.

Protection: simple mechanisms
In order to provide effective protection against attacks, all mechanisms of an application should be designed to be as uncomplicated as possible, and they should always conform to the generally applicable principle of ‘keep it as simple as possible’. In the first place, this makes implementation easier, and later on, it makes it easier to test the protective mechanisms in order to verify that they are properly implemented and effective. It is extremely dangerous to assume that protection against all possible forms of attack can be obtained by simply making something sufficiently complicated. As a rule, exactly the opposite is true. A common consequence of using complicated processes and mechanisms is that various things are forgotten or overlooked, which makes things that much easier for an attacker. Fundamentally, the available protective mechanisms in the operating system should always be utilized in the application. They have been tested for reliability, and the defense they provide starts at a lower software level than that of the application. This is not intended to mean that an application does not need to have any protective mechanisms of its own, but the mechanisms already present in the operating system should always be used.

Protection: conservative access privileges
In addition to the principle of ‘keep it simple’, there is a second generally valid rule. This is that access privileges for the files and commands of a smart card should be granted as conservatively as possible. Access should be generally prohibited, and only allowed if it is absolutely necessary. The advantages of this approach are that it makes it less likely that access to important data and commands will be granted unintentionally, and it costs an attacker additional effort to obtain each piece of necessary information. This can considerably reduce the attractiveness of an attack, since it increases the overall amount of effort required.

Protection: state machines for command sequences
Attacking a smart card application is considerably more difficult if it is not possible to execute every command at any desired time and an unlimited number of times. This can be realized by using a state machine to specify the allowed sequences of commands. For example, if mutual authentication of the terminal and the smart card is specified as the first required action, an attacker will have to overcome this protective barrier before he or she can execute any further commands.

Protection: redundant access security
The attacker’s job is made considerably more difficult if the smart card files are protected not only by access conditions stored in the objects, but also by using a state machine to specify the permitted commands and parameters. With this, the attacker cannot discover the specific features of the system by simply trying each command or combination of commands in turn. If the command sequences are supervised by a state machine, only the commands defined in the application can be executed in the smart card. All other commands will be blocked in principle by the state machine. This considerably reduces the scope of the possibilities available to an attacker with regard to command manipulation.

Protection: various test levels
It has been standard practice for many decades to support various test levels for bank notes. This involves security features that can be independently checked by different groups of people or different types of machines. For instance, many of the visual features, such as security threads and watermarks, can be checked by anyone on the street. For checking at the next level, an ultraviolet lamp is needed to allowthe fluorescent pigments in the paper to be seen. The features belonging to the next higher level are used by automated equipment to verify that the notes are genuine. A typical example is the infrared characteristics of the bank note. Yet another level of independent features is provided for tests performed by the central bank. This concept can easily be transferred to smart cards, with the logical consequence that not everybody or every piece of equipment can test all of the features. For example, a retail terminal for an electronic purse system might contain only some of the keys used for signature verification, rather than all of them. Thiswould not weaken the system in a cryptographic sense, and it would have the advantage that an attacker could not compromise the entire system by learning the master key of a retail terminal. The only entity that would know all the keys in the system required for a complete transaction data set would be the system operator, who would always be able to recognize an attack due to the forged signatures, and who would thus be able to take appropriate countermeasures in case of an attack.

Protection: security features
Features incorporated in the microcontroller can offer additional operational security for smart cards. These features consist of additional functional units that are added to the microcontroller and can be tested by the terminal, along with testing the software in the chip. Both analog and digital components are used for this purpose. The security of these features is based on concealment and is different for each application, which means that the chips are applicationspecific.

Protection: secure data transmission
There are certain risks associated with transmitting data in an insecure environment. Using relatively simple technical manipulations of the interface between the terminal and the card, it is possible to insert or delete almost any desired data within the normal data steam during a session. If this happens while data related to security are being transmitted, an attacker could derive a benefit from such manipulations. In order to prevent this type of relatively simple and easily executed attack, a secure messaging method can be employed. However, complete encryption all of transmitted data should be avoided as much as possible, with encryption being reserved for transmitting secret keys and similar items. One reason for not encrypting all of the data relates to data privacy legislation. Almost all information that is written to the memory of a smart card is public. If this information is encrypted, nobody can check what is actually written to or read from the card. In order to avoid any suspicions regarding encrypted data, which in principle would be justified, data should as much as possible remain unencrypted while being transmitted.

Protection: error recovery functions
If a session is prematurely terminated for an undefined reason, or there are fundamental questions regarding an earlier session, it is a major benefit to have application-specific log files in the smart card. Such files are maintained by the operating system, which updates them regularly during the session to reflect the current state of the application and any signatures or other data that may have been received from the terminal. The logged data are located in a cyclic file in which the oldest record is always overwritten each time a new entry is made, causing the content of the oldest record to be lost. For example, if a log file contains 20 records, information regarding the most recent 20 sessions can be stored for subsequent analysis of session history. This information can be used resolve many questions and unambiguously clarify contested transactions and sequences of events. An reason for maintaining detailed log files in the smart card is the fact that they make certain error recovery functions possible.With a log file, it is possible to automatically restore the previous state of the card (a roll back) if a session is terminated in an undefined manner. This would otherwise require analyzing the exact process and sequence of events, which might require human intervention.

Protection: authentication
Unilateral authentication, which is well known due to its use with magnetic-stripe cards, basically amounts to nothing more than verification by the terminal that the card is genuine. A magnetic-stripe card, due to its passive nature, cannot verify the genuineness of a terminal. The introduction of smart cards has fundamentally changed this situation. Now the card can also test whether it has been inserted into a genuine terminal or is connected to a genuine background system. This has extensive consequences with regard to security, since it makes it possible for the card to also take active measures against unauthorized access attempts. Numerous possibilities arise from the ability of the card and the terminal to perform mutual authentication, but they are usually not exploited to anywhere near their full potential. A smart card should at minimum refuse to allow any access attempts as long as the terminal cannot properly authenticate itself. This would make it impossible to undertake any sort of analysis of the smart card operating system in private, even if only to find out what commands are present.