Smart Card Applications

This chapter is from the book

Smart Cards: The Developer's Toolkit

Learn More Buy

This chapter is from the book

This chapter is from the book 

Smart Cards: The Developer's Toolkit

Learn More Buy

Interindustry Smart Card Commands (ISO 7816-4)

As was mentioned previously, in an effort to provide some standardization among smart cards, an interindustry command set was defined in the ISO/IEC 7816-4 specification. This command set included commands in two distinct areas, as well as several general-purpose, administrative commands. The two specific areas are:

• security features

• on-card file systems

The commands aimed at security provide mechanisms that allow the authentication of identity among the participants in smart card–based transactions. That is, computers can authenticate to computers and a person (a cardholder) can authenticate to a computer (the smart card). These mechanisms are based in well-established cryptographic operations.

APDUs

The messages used to support the ISO 7816-4–defined application protocol(s) comprise two structures: one used by the reader side of the channel to send commands to the card and the other used by the card to send responses back to the reader. The former is referred to as the command APDU and the latter as the response APDU.

As illustrated in Figure 4.8, the command APDU comprises a header and a body, each of which is further subdivided into several fields. The header includes CLA, INS, P1, and P2 fields. CLA and INS define an application class and instruction group as described, for example, in ISO 7816-4. The P1 and P2 fields are used to qualify specific instructions and are therefore given specific definitions by each [CLA,INS] instruction. The body of the APDU is a variable size (and form) component that is used to convey information to the card's APDU processor as part of a command or to convey information from the card back to the reader as part of a response to a command. The Lc field specifies the number of bytes to be transferred to the card as part of an instruction; it contains the length of the data field. The data field comprises data that must be conveyed to the card in order to allow its APDU processor to execute the command specified in the APDU. The Le field specifies the number of bytes that will be returned to the reader by the card's APDU processor in the response APDU for this particular command. The body of the APDU can have four different forms:

Figure 4.8 Command APDU structure.

• No data is transferred to or from the card, so the APDU includes only the header component.

• No data is transferred to the card but data is returned from the card, so the body of the APDU includes only a non-null Le field.

• Data is transferred to the card but no data is returned from the card as a result of the command, so the body of the APDU includes the Lc field and the data field.

• Data is transferred to the card and data is returned from the card as a result of the command, so the body of the APDU includes the Lc field, the data field, and the Le field.

Figure 4.9 illustrates the much simpler structure of the response APDU structure. It includes a body and a trailer. The body is either null or includes a data field, depending on the specific command that it is a response to and depending on whether that command was successfully executed by the card's APDU processor. If the response APDU does include a data field, its length is determined by the Le field of the command to which the response corresponds.

Figure 4.9 Response APDU structure.

Error Responses

The response APDU also includes a trailer field, which can comprise two fields of status information that are referenced as SW1 and SW2. These fields return (from the card's APDU processor) to the reader-side application a status code that, according to ISO 7816-4, has a numbering scheme in which one byte is used to convey an error category and the other byte is used to convey a command-specific status or error indication. This numbering scheme is illustrated in Figure 4.10.

Figure 4.10 ISO/IEC 7816-4 return codes.

The CLA code that is included in each command APDU has two additional components to be noted:

• The two low-order bits of the CLA byte can be used to designate a logical communication channel between the reader-side application and the card's APDU processor.

• The next two higher order bits of the CLA byte can be used to indicate that secure messaging is to be used between the reader-side application and the card's APDU processor.

After the link-level protocol is established between the reader-side application and the card's APDU processor, a base-level (command) logical channel is created. This is indicated (in the CLA byte) by both of the low-order bits being 0. Additional logical channels can be created by using the Manage Channel command, which is defined by ISO 7816-4.

ISO 7816-4 also defines a modest secure messaging protocol, which can be used to ensure privacy and integrity of APDUs transferred between the reader-side application and the card's APDU processor.

Security Commands

Associated with each component of the file system is a list of access properties. Through these access properties, a state can be defined such that the smart card system must be put into that state, through the successful execution of a series of commands by the reader, before that component of the file system can be accessed. At the most basic level, the operations to be performed on the file system are to select a specific file and then write information to that file or read information from that file. As shown in the following sections, the access properties may be as simple as requiring the reader to provide a predefined PIN or as complex as the reader proving that it possesses some shared secret (e.g., a key) with the card. These mechanisms will be reviewed in more detail in the following sections.

The Verify Command

The Verify command is a command sent by a reader-side application to the security system on the card to allow it to check for a match to password type information stored on the card. This command is used to allow the reader-side application to convince the card that it (the reader-side application) knows a password maintained by the card to restrict access to information on the card.

The password type information may be attached to a specific file on the card or to part or all of the file hierarchy on the card. Successful execution of this command indicates that the reader-side application did know the correct password and it puts the card into a state such that a subsequent access to a file guarded by this password information will succeed.

If the Verify command fails (i.e., the password required by the card is not correctly provided by the reader-side application), then an error status indicator is returned by the card to the reader-side application.

The Internal Authenticate Command

The Internal Authenticate command is a command sent by a reader-side application to the security system on the card to allow the card to prove that it possesses a secret key that is shared with the reader-side application. To prepare this command, the reader-side application creates a set of challenge data (i.e., essentially, the reader-side application generates a random number). This number is then encrypted with some agreed-on algorithm (with the card); this constitutes a challenge to the card.

When given the command, the card then decrypts the challenge with a secret key stored in a file on the card. The information derived from the decryption is then passed back to the reader-side application as a response to the command. If the card really does have the correct secret key, then the information passed back will be the random number generated by the reader-side application prior to issuing the Internal Authenticate command.

This command is used by the reader-side application to authenticate the card's identity. That is, when successfully completed, the reader-side application knows the identity of the card and can give to the card access to information or services within the reader-side application.

The External Authenticate Command

The External Authenticate command is used by a reader-side application, in conjunction with the Get Challenge command (described in the next section) to allow the reader-side application to authenticate its identity to the card.

Through the Get Challenge command, the reader-side application receives a set of challenge data from the card (i.e., a random number generated by the card). The reader-side application then encrypts this information with a secret key. This then forms a challenge, which is sent to the card via the External Authenticate command. If the reader-side application knows the same secret key that is stored on the card, then when the card decrypts the challenge, it will find the same random number generated by the last Get Challenge command. Therefore, the card now knows the identity of the reader-side application and can give it (the reader-side application) to data on the card.

The attractive characteristic of this method (from a security standpoint) is that the secret key used to authenticate identity between the reader-side application and the card was never transferred between the reader-side application and the card.

The Get Challenge Command

The Get Challenge command is used by the reader-side application to extract information that can be used to formulate a challenge to the card that can be validated through an External Authenticate command. The result of this command is the generation of a random number by the card, which is then passed back to the reader-side application.

File System

A central application for smart cards defined by the ISO/IEC 7816-4 standard is a file system. The file system is actually applied to the nonvolatile memory on the smart card, generally electrically erasable and programmable read-only memory (EEPROM). The file system defined is a relatively straightforward hierarchical structure comprising three basic elements:

• a master file (MF) component

• a directory file (DF) component

• an elementary file (EF) component

The MF component is the root of the file hierarchy; there is only one MF on a smart card. An MF may contain as elements a DF, or even many DFs, and it may contain none to many EFs. The DF component is essentially a container for EF components; a DF may contain none to many EFs. An EF component may contain only records. This simple hierarchical structure is illustrated in Figure 4.11.

Figure 4.11 The smart card file system architecture.

Several characteristics of the smart card file system are significantly different from typical (e.g., disk-based) file systems. These differences are almost exclusively due to the physical characteristics of the EEPROM memory system—specifically, the facts that EEPROM memory can only be subjected to a modest number of erase and write cycles and that it is significantly faster to write to EEPROM memory in a cumulative fashion than in a pure erase and then write fashion. The first of these characteristics resulted in the definition of a rather unique file structure called a cyclic file. The second characteristic resulted in rather unique definitions of the various file write commands.

The cyclic file is actually a ring buffer of physical files that are addressed and accessed as a single file. On successive write operations, the next physical file (in the ring of physical files) is accessed. The net result is that erase and write operations can be spread across a wider selection of EEPROM memory locations. This mitigates somewhat the limit (generally on the order of 100,000 cycles) on the number of times that a specific EEPROM memory location can be erased and rewritten.

EEPROM memory has the additional interesting characteristic that it is significantly faster to set additional bits in a memory location than it is to erase all the currently set bits and then rewrite them. This fact becomes doubly useful in certain operations (e.g., manipulating a purse value on a smart card) where it is required that operations on a file be performed in such a fashion that the values stored in the file are well understood at any point in time, even if power is removed from the smart card in the middle of a file operation. To facilitate the exploitation of these characteristics, the write operations to a smart card file are typically bit-set operations while the update operations are actually erase and rewrite operations, which we generally associate with file-writing operations. These characteristics will be examined in a bit more detail in the following sections.

MF Characteristics

Each smart card file system has exactly one MF. The MF serves as the root of the hierarchical file structure. In the parlance of general file systems, the MF is a container or a directory; it may contain other dedicated (or directory) files (DFs) or it may contain EFs.

Any file can be identified by a 2-byte file identifier. The file identifier 3F00 is reserved for the MF; that is, there is only one file with a file identifier of 3F00, and the file with that identifier is the MF.

DF Characteristics

The DF also is a container or a directory file in the same vein as the MF. The DF forms a subdirectory within the file hierarchy rooted in the MF. A DF also can be identified by a file identifier. A DF must be given a unique file identifier within the DF (or MF) that contains it. This allows for the creation of a unique path designation for a file (i.e., a path is simply the concatenation of the file identifiers of the file in question, and of all the DFs between the file in question and its containing DF or MF).

A DF also can be referenced by a name that may be from 1 to 16 byes long. The naming conventions for the DF name are found in the ISO/IEC 7816-5 specification.

EF Characteristics

The EF is the leaf node of the file hierarchy. It is the 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 EFs as illustrated in Figure 4.12:

• a transparent file

• a linear, fixed-length record file

• a linear, variable-length record file

• a cyclic, fixed-length record file

Figure 4.12 Smart card file system file types.

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 the 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 file in a consistent, transparent fashion and yet have the file system itself map this access into a variety of different physical files. 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 that was actually written to.

File Access Commands

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.

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. After a file is selected by this command, any subsequent 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 command must convey (from the reader-side application to the smart card's APDU processor) is the identification of the file to which this logical pointer must point. 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)

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 set a series of bytes in the EF (i.e., set selected bits within the designated bytes to a value of 1), clear a series of bytes in the EF (i.e., 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.

The Update Binary Command

The Update Binary command is used by a reader-side application to directly erase and store a set of information (bytes) 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 an Update 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.

The Update Binary command provides the functions that would normally be associated with a file write command. That is, a string of bits provided in the command are actually written into the EF on the card, with those byte positions in the file on the card being erased first. The net result is that the string of bytes found in the designated position within the EF on the card is exactly the string sent by the reader-side application in the Update Binary command.

Input parameters for the command include an offset pointer from the start of the file and a byte count of the total number of bytes to be written.

The Erase Binary Command

The Erase Binary command is used by a reader-side application to erase (set the value to 0) a string of bits within an EF on a card. The file being accessed must be a transparent file; that is, it cannot be a record-oriented file. If an Erase 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 specified as part of the command: an offset from the start of the EF to the segment of bytes within the file to be erased and the number of bytes within that segment.

The Read Record Command

The Read Record command is a command sent by a reader-side application to read and return the contents of one or more records in an EF on a card. This command must be executed against a record-oriented EF. If it is applied to a transparent EF, the command will abort and an error indicator will be sent from the card back to the reader-side application.

Depending on the parameters passed through the command, the one designated record is read and returned, or all the records from the beginning of the file to the designated record are read and returned, or all the records from the designated record to the end of the file are read and returned.

The Write Record Command

The Write Record command is a command sent by a reader-side application to write a record into an EF on the card. This command must be executed against a record-oriented EF. If it is applied to a transparent EF, the command will abort and an error indicator will be sent from the card back to the reader-side application. In the sample command sequence noted previously, 14 (hexadecimal) characters will be written into the currently selected record beginning at the sixth character position in that record. The characters to be written are contained in the Data field (i.e., the hexadecimal representation for "Sally Green").

As with the Write Binary command, this command can actually be used to achieve one of three results: a one-time write of a record into the EF, setting of specific bits within a specific record in the EF, or clearing of specific bits within a specific record in the EF.

Several addressing shortcuts may be used in this command to specify the record to be written to, including the first record in the EF, the last record in the EF, the next record in the EF, the previous record in the EF, or a specific record (identified by number) within the EF.

The Append Record Command

The Append Record command is a command sent by a reader-side application to either add an additional record at the end of a linear, record-oriented EF on a card or to write the first record in a cyclic, record-oriented EF on a card. If it is applied to a transparent EF, the command will abort and an error indicator will be sent from the card back to the reader-side application.

In the preceding example, P1 is an unused parameter and is always 00₁₆. P2 is the short identifier of the file to which the record append will apply. Lc specifies the number of characters in the record to be appended and the Data field contains the characters to be appended—in this case, the hexadecimal representation of "Sally Green." That is, for whatever end, this command appends the words "Sally Green" in a record onto the end of the selected file.

The Update Record Command

The Update Record command is a command sent by a reader-side application to write a record into an EF on the card. This command must be executed against a record-oriented EF. If it is applied to a transparent EF, the command will abort and an error indicator will be sent from the card back to the reader-side application.

As with the Update Binary command, this command is used to write a specific record into an EF. The net result of the operation is that the specific record in the EF is erased and the new record specified in the command is written into the EF.

Administrative Commands

The master-slave command protocol specified by ISO/IEC 7816-4 is quite restrictive in its ability to accommodate the wide variety of commands that you might want to access on a smart card. In an attempt to compensate for some of the syntactic shortcomings, ISO/IEC 7816-4 also defines a number of administrative commands that allow a wider latitude of command structures and responses.

The Get Response Command

The Get Response command is another command that allows the use of the T=0 link-level protocol for conveying the full range of APDUs. Specifically, the Case 4 type of APDU body cannot be supported with the T=0 protocol. That is, you can't send a body of data to the card and then receive a body of data back as a direct response to that command. For this type of command, using the T=0 protocol, the initial command results in a response that indicates more data is waiting (in the card). The Get Response command is then used to retrieve that waiting data.

It should be noted that no other command can be interleaved between the original command and the Get Response command.

The Manage Channel Command

The Manage Channel command is used by the reader-side application to open and close logical communication channels between it and the card. When the card initially establishes an application-level protocol with the reader-side application (i.e., following the ATR sequence) a basic communication channel is opened. This channel is then used to open and/or close additional logical channels via the Manage Channel command.

The Envelope Command

The Envelope command is a command that supports the use of secure messaging via the T=0 link-level protocol. In secure messaging, the full command APDU should be encrypted. However, because the CLA and INS bytes from the APDU overlay elements of the transmission protocol data units (TPDU), these bytes (in the TPDU) cannot be encrypted if the link-level protocol is still to work correctly. So the Envelope command allows a full APDU to be encrypted and then included in the Envelope command's data section (of its APDU). The card's APDU processor can then extract the "real" command and cause it to be executed.

The Get Data Command

The Get Data command is a command sent by a reader-side application to read and return the contents of a data object stored within the file system on the card. This command is essentially the complement of the Put Data command (defined in the next section). This command tends to be very card specific in its internal implementation. However, the semantics of the command are well defined. That is, the definition of just what constitutes a data object varies widely from card to card, but what the command does should be consistent from card to card. Thus, for retrieving a small amount of information, this command might well be preferable to retrieving information from a specific file.

The Put Data Command

The Put Data command is a command sent by a reader-side application to put information into a data object stored within the file system on the card. This command tends to be very card specific in its implementation; however, it is relatively general in its specification. So, the fact that the definition of just what constitutes a data object varies widely from card to card does not necessarily mean that the semantics of the command varies from card to card. In fact, the attractive feature of this command is the fact that you do not need to know the identity of a specific file into which the "data" is to be stored. This tends to make the command similar across a variety of different smart cards. An application, should it need to store only a modest bit of information, can do so with this command and be moderately assured that the command will work on a variety of different smart cards.