Previous | Table of Contents | Next |
As we imagine new applications for a smart card, we might like to think of it as just another computing platform, but the smart card computer has a number of unique properties that you must keep in mind as you design and build these new applications. In writing reader-side software, you are constantly bumping up against the severe resource constraints of the smart card as a computing platform: low-speed communication, slow central processing unit, 8-bit data, and limited available memory. Furthermore, you must be even more aware of the security implications in the logic of your code and think as much about what your code allows that you dont want it to as much as what it allows that you do want.
Finally, the smart card programmer has to be constantly mindful of the context in which the computer carrying his or her application will be used and the nature of the systems to which it is connected. A smart card computer isnt a self-contained computing system, plugged into a reliable power supply in a warm office. Rather, it is a node in a complex transaction processing network whose user may be standing in the rain and whose power supply may be interrupted by the next bolt of lightning.
Among all the special considerations that must be dealt with in writing card-side software, the ones that will be the most constant source of pain for the workstation or PC programmer are the unusual properties of the smart card memory system. Not only does the memory system consist of three different kinds of memory, each demanding to be dealt with in its own way, but the properties of these memories can vary markedly from chip-to-chip and manufacturer-to-manufacturer.
Random Access Memory
The most difficult resource constraint for most card-side programmers to deal with is the limited amount of random access memory (RAM). Small cards have 128 bytes of RAM. Big cards have 640 bytes of RAM. Carefully note the absence of any Ks or Ms after these numbers. Thats 128 bytes, not 128 kilobytes or megabytes.
Since it is such a limited resource, RAM is managed carefully and explicitly. Some RAM is pre-allocated to hold fixed, specific, often-used values that comprise the global state of the smart card. Some RAM is pre-allocated for specific uses, such as input and output buffers. Some RAM is set aside for general scratch use and can be used freely by code for temporary and intermediate values.
Finally, some RAM is used for communication between code modules. Whether or not these locations are in current use, and if they are in use, what they contain, depends solely on the call stack. Accessing and using this RAM requires detailed knowledge of how you got where you are. Fortunately, most smart card assemblers and linkers provide tools for effectively using this type of RAM.
The first step in writing any card-side software is getting a detailed memory map of both the chip and the operating system for which you are writing and the other applications with which your code will be run.
Nonvolatile Memory
Nonvolatile memory (NVM) on a smart card is used to store values that are expected to remain on the card from use-to-use. Account numbers, digital certificates, passwords, private keys, VisaCash, and American Airlines AAdvantage (frequent flyer) points are all examples of data that would be kept in nonvolatile memory.
NVM in smart card chips is built with a number of different technologies. Various EEPROM, FLASH, and FRAM technologies are all used. One common feature of these technologies that most application programmers arent ready for is that it takes a noticeable amount of timeup to 10 millisecondsto write a data value into nonvolatile memory. In fact, it is not too far off the mark to say that NVM is better thought of as a randomly addressable disk block than it is workstation-style memory. In a pinch, you can use NVM for temporary values, but you probably shouldnt make a habit of it. Keep in mind the cardholder who is standing in the rain at an ATM or at the head of a long check-out line in a grocery store.
Furthermore, NVM must be written in blocks of 4, 16, or more bytes at a time. In other words, when you want to write a byte to memory location A, you also have to erase and rewrite the bytes at locations around A; at locations A-1, A+1, and A+2, for example. Although this fact is usually hidden from the application programmer by libraries supplied by the chip manufacturer, things can go wrong and values you didnt think you touched can mysteriously change by themselves. Keep in mind that writing to one location can also trigger writing to locations nearby.
Nonvolatile memory, surprisingly, wears out. Chip manufacturers claim that their NVM is good for 10,000, 40,000, or 100,000 writes, but these figures can vary widely from actual chip to actual chip. If you have a value that is going to change a lot, it is a good idea to allocate more than one memory location for it and cycle the current value through the allocated locations. For example, write the initial value at location X, the first update at location X+1, the second update at location X+2, the third update at X+3, the fourth update back at X, and so forth. This way, you spread the wear caused by the writing of the value over multiple memory locations. Of course, this does cost you more memory both to store the update code, the values, and the index of which value is the current value.
Data stored in NVM has an advertised shelf life of 10 years. To our knowledge, no studies have been done to estimate the actual mean and standard deviation of this value. Smart cards are not bad data archives but the problem may be refreshing data that you want to last beyond 10 years.
Previous | Table of Contents | Next |