Previous Table of Contents Next


Elementary File Characteristics

An EF is a leaf node of the file hierarchy. It is a file that actually contains data. There are two variants of EFs: an internal EF, which is to be used by applications on the card, and a working EF, which is used as a storage mechanism for information used by an off-card application.

Within a specific DF, an EF may be identified by a short (5-bit) identifier. There are four variants of working EFs:

  A transparent file
  A linear, fixed-length record file
  A linear, variable-length record file
  A cyclic, fixed-length record file

A transparent file can be viewed as a string of bytes. When a command is used to read or write information from a transparent file, it is necessary to provide a byte offset (from the start of the file) to the specific byte (within the transparent file) where reading or writing should begin. A command to read or write information from/to a transparent file will also contain a counter or length of the byte string to be read or written to the file.

Fixed- or variable-length record files are, as their name suggests, files that comprise subdivisions called records. Records (within a file) are identified by a sequence number. In a fixed-length record file, all the records contain the same number of bytes. In a variable-length record file, each record in the file can contain a different number of bytes. As might be suspected, a variable-length record file generally has a significantly higher overhead in read/write access time and in the amount of administrative (data storage) overhead required by the file system.

A cyclic file is a rather unique (to smart card file systems) structure. It allows applications to access a record in a consistent, transparent fashion and yet have the file system itself map this access into a variety of different physical records. This allows the limits of erase and rewrite cycles on EEPROM memory to be somewhat mitigated.

A cyclic file is best thought of as a ring of records. Each successive write to the file performs the operation on the next physical record in the ring. Read operations are performed on the last physical record to which it was actually written.

To manipulate the smart card file system, an application level protocol is defined in the form of a collection of functions for selecting, reading, and writing files. These functions are discussed qualitatively in the following sections. In Appendix A, these commands are presented in a more quantitative fashion, including the specific CLA and INS designations, along with the error and status codes generally returned by the various commands.

The Select File Command

The Select File command is used to establish what may be thought of as a logical pointer to a specific file in the smart card’s file system. Once a file is selected by this command, any subsequent file manipulation commands, such as those to read or write information, will operate on the file pointed to by this logical pointer. Access to the smart card’s file system is not multithreaded (from the card’s viewpoint), but it is possible to have multiple such logical pointers in play at any point in time. This is done by using the Manage Channel command to establish multiple logical channels between the reader-side application and the card. Commands to access different files can then be multiplexed (by the reader-side application), allowing different files on the card to be in various states of access by the reader-side application at the same time.

The primary piece of information the Select command must convey (from the reader-side application to the smart cards APDU processor) is the identification of the file that this logical pointer must point to. This identification can be provided in three ways (with the specific addressing mechanism being indicated in the data field of the Select File command APDU):

  By file identifier (2-byte value)
  By DF name (string of bytes identifying the DF)
  By path (concatenation of file identifiers)
  By short ID

Not all smart cards support all four naming mechanisms. For example, the 3K Multiflex card included with this book supports only the first mechanism.

The Read Binary Command

The Read Binary command is used by a reader-side application to retrieve some segment of an EF on the card. The EF being accessed must be a transparent file; that is, it cannot be a record-oriented file. If a Read Binary command is attempted on a record-oriented EF, the command will abort with an error indicator being returned by the card to the reader-side application.

Two parameters are passed from the reader-side application to the card for this command: an offset pointer from the start of the file to initial byte to be read, and the number of bytes to be read and returned to the reader-side application.

The Write Binary Command

The Write Binary command is used by a reader-side application to put information into a segment of an EF on the card. The file being accessed must be a transparent file; that is, it cannot be a record-oriented file. If a Write Binary command is attempted on a record-oriented EF, the command will abort with an error indicator being returned by the card to the reader-side application.

Depending on the attributes passed from the reader-side application to the card in the Write Binary command, the command can be used to either set a series of bytes in the EF (that is, set selected bits within the designated bytes to a value of 1), clear a series of bytes in the EF (that is, set selected bits within the designated bytes to a value of 0), or do a one-time write of a series of bytes in the EF.


Previous Table of Contents Next