Microcontrollers in smart cards strengthen system security. Security features can vary, but the aim is to restrict access to stored information and prevent the card from being used by unauthorized parties.

Each manufacturer includes some unique security features. These are never discussed to maintain security.

In general, however, a smart-card device includes one or more of these security features:

Manufacturers may also employ special tamper-resistant layers or nonstandard circuit and memory topologies. Test modes are isolated to ensure they can’t be used to gain information and to ensure that the device executes only from its on-chip program.

THE ROLE OF SOFTWARE

Not only does smart-card software determine the card’s functionality in the overall system, it also plays a huge part in the security of the system and the card in particular. Typically, as much as 50% of a smart card microcontroller’s ROM code is dedicated security.

The software takes advantage of the microcontroller’s security features. It then verifies the different players by linking the terminal, card, and card carrier. Lastly, it encrypts and/or decrypts the data.

To use the microcontroller security features, there are many aspects and techniques that you should consider—some running counter to what is normally considered good programming practice! The following suggestions are not all-inclusive or sufficient for all applications, but they point out the challenges of writing secure code.

Avoid implementing the application functionality using a standard method or routine. Make it unique so it’s more difficult to understand or duplicate.

Deliberately use complex or illogical program flow. Alternate between having code in ROM and EEPROM to reduce the readability of the software. Periodically check that the EEPROM has not been erased or altered by verifying the state of some known, nonzero bits in the array.

Use variability in the software so a sensitive event does not always occur at a fixed time after reset. For example, use nonfunctional EEPROM writes to obscure the writes that are changing sensitive information. As well, use time-critical routines and the built-in watchdog function, and explicitly erase the entire RAM, or critical portions, whenever the device is reset.

You need to consider the consequences of atypical accidental or deliberate actions. What would happen if power is interrupted during critical portions of the software?

When you’re determining state tables, don’t assume that a set of inputs could not occur. What would happen if a set of conditions could be forced?

Check the state of any security flags (hardware or software) and/or registers before executing critical sections of code. When you implement a counter in software, ensure that the count is changed before the related action (e.g., comparing the input PIN) takes place.

And finally, limit the ability of the application to modify itself, but allow for controlled upgrade or modification of the system by the download of new software to the EEPROM.

The software controls not only the operation of the controller but also its relationship and interface to the rest of the system. There are usually three things that must be verified or linked before the flow of information and/or value can take place.

The system and its network (e.g., with the terminal) must be authenticated, and then the card is verified. This is often done by mutual authentication between the card and terminal via a handshake routine in which the card proves its validity to the terminal and the terminal to the card (see Figure 4). Optionally, you can link the card to the card carrier and verify that the card carrier is legitimate.

(Click here to enlarge)

Figure 4—Once mutual authentication between the card and the terminal is complete, an authorized action can take place.

Currently, a PIN is commonly used to verify the cardholder. Unfortunately, it’s not necessarily unique to the person and far too many people write their PIN on their card, nullifying any security benefits.

Various biometrics such as voiceprints, fingerprints, retina or iris scans, and dynamic signature patterns are being evaluated to provide the linking mechanism between the card and card carrier. The card carrier’s unique biometric image captured by sensors at the terminal or card can be compared with the template stored on a smart card.

Such matching techniques are still imperfect and must prove acceptable by the card-carrying public. Depending on the application, designers must decide whether they’re more interested in rejecting impostors or ensuring legitimate cardholders are always accepted.

Encryption and decryption algorithms are often used in smart-card systems. Cryptographic algorithms commonly maintain confidentiality, verifying the data’s integrity, authenticating the sender’s identity, or offering a way of nonrepudiation in a financial transaction. A variety of private key algorithms are available, such as DES (Data Encryption Standard), and public key algorithms like RSA (Rivest, Shamir, Adellman).

Most algorithms can be supported in software. However, system time constraints may necessitate an encryption coprocessor integrated into the smart card controller to accelerate performance of the algorithms. The smart card CPU controls the encryption coprocessor using various algorithm libraries.

Software can range from simple to much more complex algorithmic authentication processes. While restricting external access to the device, the software responds to an incorrectly entered PIN—anything from requesting a new attempt to completely locking up the device on a predetermined number of consecutive incorrect PIN inputs—or ask for additional information when behavior doesn’t fit expected norms.