Previous Table of Contents Next


Smart Card Operating Systems

Smart card operating systems are not operating systems in the sense that today’s mainstream programmers and software developers think of them. Smart card operating systems certainly don’t have the functionality of Windows or UNIX or even DOS. Rather, they are more like pre-DOS collections of on-card commands to which the smart card responds.

The basic relationship between a smart card terminal, such as a personal computer into which a smart card is inserted, and the smart card itself is one of master and slave. The terminal sends a command to the smart card, the smart card executes the command, returns the result if any to the terminal, and waits for another command.

In addition to describing the physical characteristics of a smart card and the detailed formats and syntaxes of these commands and the results they return, smart card standards such as ISO 7816 and CEN 726 also describe a wide range of commands that conforming smart cards can implement. Most smart card manufacturers offer off-the-shelf smart cards with operating systems that implement some or all of these standard commands, together with manufacturer-specific extensions and additions. Table 1.4 lists a few examples.

Table 1.4. Examples of operating systems for off-the-shelf smart cards.
Card Type Manufacturer Maximum memory size Extensible

Multiflex Schlumberger 8 KB Yes
MPCOS64K Gemplus 8 KB Yes
USCO48 US3 8 KB No
OC100 Bull CP8 8 KB No
I006.1 Orga 4 KB No

Smart Card File Systems

Most smart card operating systems support a modest file system based on the ISO 7816 smart card standard. Because a smart card has no peripherals, a smart card file is really just a contiguous block of smart card memory. A smart card file system is a singly rooted directory-based hierarchical file system in which files can have long alphanumeric names, short numeric names, and relative names.

You usually can't extend or expand an already allocated file, so you have to create files at the maximum size they are expected to be. Furthermore, there is no notion of garbage collection or compacting in a smart card file system. So, for example, if file A and file B are created in this order in the same file system directory, and then file A is deleted, the space occupied by A is lost until file B is also deleted. If file B is deleted because it was the last file created, the space occupied by file B is reclaimed and can be reused by file C, for example.

Smart card operating systems support the usual set of file operations such as create, delete, read, write, and update on all files. In addition, operations are supported on particular kinds of files. Linear files, for example, consist of a series of fixed-size records that can be accessed by record number or read sequentially using read next and read previous operations. Furthermore, some smart card operating systems support a limited form of seek on linear files. Cyclic files are linear files that cycle back to the first record when the next record after the last record is read or written. Purse files are an example of an application-specific file type supported by some smart card operating systems. Purse files are cyclic files, each of whose records contain the log of an electronic purse transaction. Finally, transparent files are single undifferentiated blocks of smart card memory that the application program can structure any way it pleases.

Associated with each file on a smart card is an access control list. This list records what operations, if any, each card identity is authorized to perform on the file. For example, identity A may be able to read a particular file but not update it, whereas identity B may be able to read, write, and even alter the access control list on the file.

One of the key design tasks of a smart card programmer in building a new smart card application is defining and laying out the files that the application will expect to find on the smart card; for example, see Table 1.5. Size and usage of smart card real estate is a key concern, but the names of the files, their hierarchical relationship to one another, and their access authorizations must also be thought through.

Table 1.5. Examples of smart card file types.
Type Special Operations Sample Uses

Linear Seek Credit card account table
Cyclic Read next, read previous Transaction log
Purse Debit with certificate Loyalty points, e-cash
Transparent Read and write binary Picture
SIM file Encrypt, decrypt Cellular telephone

Smart Card Communications

The typical single-chip computer on a smart card is able to transmit and receive data at speeds up to 115,200 bits per second (bps), but most smart card terminals drive smart cards at 9,600 bps for contact smart cards and 7,800 bps for contactless smart cards. Because only a small amount of data is being transmitted and because the channel can be quite noisy, reliable communication is more important than high-speed communication.

The communications pathway to and from a smart card is half-duplex; that is, data is either flowing from the terminal to the smart card or from the smart card to the terminal, but not both at the same time. The result is that the smart card and the terminal have to be synchronized and always agree on whose turn it is to talk and whose turn it is to listen. If both the terminal and the card transmit at the same time, data will be lost. If they both believe it is their turn to listen, the system enters a deadlock situation and nothing further happens.

Data received by and transmitted from a smart card is stored in a buffer in the smart card’s very limited random access memory. Therefore, only relatively small packets—10 to 100 bytes—of information are moved in each message. Although the ISO and CEN standards describe in detail the format and coding of these messages, nothing prevents the smart card programmer from designing messages specifically tuned to his or her application. You must ensure that other surrounding systems don’t make assumptions about the messages based on the ISO or CEN standards (which you’ll learn more about in Chapter 3).


Previous Table of Contents Next