Previous Table of Contents Next


Read-Only Memory

The card-side code you write may be stored in read-only memory (ROM). Executable code and data stored in ROM are put there when the chip is manufactured. If it’s wrong, it can’t be changed. This can lead to expensive programming mistakes both in time and money. It can take up to four months to get a smart card chip with a particular code body made, tested, and embedded in plastic. If your program doesn’t work, you get to get in line again. Furthermore, like printing after you get production set up, it is cost-effective to produce as many chips or cards as you think you’ll possibly use so you will be provided with economic incentives to produce a large number of chips. If they don’t work, you get to throw out an equally large number of them.

A number of programming tricks can be employed to ameliorate this situation (for example, “bugging out” to check for corrected values or substitute code fragments stored in EEPROM at strategic points in the ROM code). Indeed, the soft mask capability of smart cards discussed in the following sections is used as much to correct ROM errors as it is to add new features to existing cards. It is also a good idea to have a number of people review ROM code and even do a public instruction-by-instruction walkthrough before the mask is sent off to the factory. In spite of all your precautions, due to its irreversible nature, ROM code is fertile ground for the application of Murphy’s Law.

Soft Masks

The easiest way to add code to a smart card is to put it in nonvolatile memory. Many card manufactures make off-the-shelf smart cards that accept code after they have been manufactured. If this code is native machine instructions as opposed to byte codes for an on-card virtual machine, it is called a soft mask to differentiate it from the mask of native machine instructions that was sent to the chip manufacturer and hardwired into the chip’s ROM. Once a soft mask has been loaded into a card, it is possible to deactivate the loading capability so that no more code can be loaded, nor any bugs in the soft mask patched.

Primarily due to the counterfeit card concerns discussed earlier, it is not particularly easy to buy cards with the soft mask capability activated. Each card manufacturer has a different policy for using the soft mask capability on its cards and these policies are themselves changing as customers demand more flexibility, control, and involvement in the features and properties of the card.

In addition, since assembly language code can directly access all of the smart card’s addressable memory, including ROM, it can read the operating system and the contents of all files without restriction and quite independently of the file system’s access control system. Card manufacturers regard their smart card operating systems as proprietary technology and can be expected to ensure that their code isn’t exposed. Finally, few of these operating systems were designed to surface a robust, documented and stable application program interface.

For all these reasons, expect to work closely with the card’s manufacturer in adding a soft mask to a smart card.

Tearing

Yet another unique feature of the smart card computing platform is that power may be turned off at any moment. In designing software for a smart card, continually ask yourself, “What state would the card be in if this were the last instruction executed, and will my code recover gracefully from this state the next time the card is used?”

When a cardholder removes the card from the card reader before all the business between the card and the terminal has been finished is called tearing, because the cardholder is thought of as ripping the card out of the terminal. Some readers “swallow” the entire card during use and thus prevent tearing.


Note:  
The readers that swallow the entire card during use can also capture the card if they decide that there is something fishy about it. These readers are much more expensive than push/pull readers, so you should probably assume that your application could be used with a push/pull reader and therefore be exposed to tearing at some time or another.

Database programmers are familiar with the use of transaction begin, commit, and rollback to ensure that relationships between multiple values in a database are preserved in the face of power loss or other processing interruption. Some smart card operating systems implement a transaction interface to data stored in NVM, but most do not. If you need to ensure that two or more values are mutually consistent—for example, that a checking account number agrees with a debit card number, or a street address agrees with a zip code—then you will have to write your own transaction code.

What database programmers and most other programmers aren’t familiar with is the non-atomic write. If a storage location contains a 4 and you overwrite it with a 6 but power is turned off in the process, then you might expect that the location will contain either a 4 or a 6 when the system comes back up. If the memory is smart card nonvolatile memory and if power is removed while nonvolatile memory is being written, you could find a value that is neither 4 nor 6 when the system returns. What’s worse is that the contents of locations next to the one you were writing may also be changed to random bogus values.

Critical NVM data should never be overwritten. At least one previous value should be kept. The ISO 7816-4 specification defines—and most smart cards implement—the cyclic file type for exactly this purpose. Furthermore, it should be possible to determine, based on stored data, whether tearing occurred during the previous use of the card so that card can be restored to the consistent and correct backup state.

A technique that is used if a value must be overwritten is to perform the overwrite a bit at a time so that all the intermediate values are known and acceptable. For example, if memory location containing a number representing a value is to be incremented, then you ensure that none of the intermediate values is greater than the final value. Generally speaking, from the point of view of the card owner/issuer, it is better for cards to destroy value than to create it.


Previous Table of Contents Next