Previous Table of Contents Next


File Design

Before writing any software for a smart card application—reader-side or card-side—you should carefully design the files that the smart card will carry to support your application. At first blush, this may seem like a trivial matter. But knowledge of your application’s files will spread to both card-side software and reader-side software. If you get it wrong, there will be lots of software to change—not to mention lots of cards in the field to update or discard and replace.

Smart card file design is just as complex and perhaps more so than file design for PC or even mainframe applications. This is because the smart card file design includes careful and detailed consideration of the security policy covering the data contained in the smart card’s files.

First, a number of parties with different interests and concerns may be involved—card issuer, cardholder, application provider, application sponsor, and liability carrier, to name a few. Suppose, for example, we are dealing with adding a loyalty program for a local grocer to a Mondex card issued by Second Bank. This loyalty program is written by a French software house and it is to give airline travel miles to the grocer’s customers. Who gets to see what data and who gets to update what data?

Once this is sorted out, there is the issue of how you go about proving somebody is who he says he is, who gets to say what is sufficient proof and who gets to approve and revoke whose authorizations? Can the grocer prevent Second Bank from looking at the customer’s loyalty point holdings? Can the airline insist that the card carry a public key certificate to authenticate code from the French software house? If so, where is the certificate kept and who can see it?

It is almost impossible to spend too much time thinking through the file system design for your smart card application.

Reader Behavior

Smart card readers are not as standardized as smart cards themselves. In fact, they aren’t standardized at all. Most of the smart card systems in the field today are closed systems consisting of specific cards and specific readers that have been tested to work together. While a reader can tell what to expect from a random ISO 7816 card, a card can make few assumptions about what to expect from a random reader.

There are efforts underway to standardize readers. The EMV specification discussed in Chapter 7, “Reader-Side Application Programming Interfaces,” for example, has as much to say about readers as it does about cards. When writing card software, don’t assume that the reader communication channel behaves as uniformly as a serial channel on a PC or a workstation. Some readers and their software drivers have built-in notions of how a card should behave and can act in rude ways—like turning off the power—if their expectations aren’t met. Things to watch out for are how quickly you have to respond to reset, how long you have to respond to messages from the terminal, and what bit patterns might cause the terminal to act in strange ways.

Reader Communication

If you are building a card-side application that has to work with existing readers and existing reader software, you will undoubtedly find yourself using the ISO 7816-4 communication protocol. The basic packet of this protocol is called an application protocol data unit (APDU) and it consists of a 5-byte header followed by a Tag-Length-Value (TLV) encoded data field. This is what most of the smart card reader applications currently expect, and if you are going to play with these terminals, you will have to talk their language.

On the other hand, if you are designing and building both the card side and the reader side of your application, it may be attractive to consider the possibility of adopting something other than ISO 7816’s APDU protocol. This protocol does have a specific model of computation—namely a master/slave relationship between terminal and card—built into it and as a result is awkward and inefficient in particular situations (for example, when the card wants to control the conversation). On the other hand, designing your own communication protocol does isolate your system from the mainstream of smart card systems. This may be a bug or a feature.

Fortunately, the designers of the ISO 7816 APDU protocol were well aware of the need to provide for graceful growth and extension. The result is that you can use APDU packets but endow them with virtually any semantics you wish. First, you can define wholly new APDU packets that have your meaning and carry your data. If this doesn’t provide you with enough freedom, you can use any of the 47 class byte values (D0 through FE) that have been explicitly set aside for wholly arbitrary and proprietary extensions of ISO 7816. What follows an ISO 7816 D0 header byte is completely up to you.

There is one danger lurking in the bushes should you get too creative in your communication packet design. Some readers and some software infrastructures have ISO 7816 assumptions built into them and get unhappy if what they see passing between the two halves of your application isn’t sufficiently ISO 7816 by their lights. If possible, be sure to test your application with all the readers and all the infrastructures with which you intend it to work.

The Standards-Based APIs

One reason you write card-side code is to move functionality from the terminal to the card. This may be done to improve transaction speed, to enhance security, or to transfer control from the owner of the terminal to the owner or holder of the card. In this scenario, what was a series of commands to the card before the installation of the card-side code now becomes one command. The code on the card packages or encapsulates all the previous commands.

When you move code from the reader side to the card side, it is natural to expect that the card services that were available as commands to code on the reader-side are still available as function calls to code on the card side. For example, you will want to be able to read a file on the card-side just as you could read a file on the reader-side. As a result, smart card card-side APIs typically include calls to the functions that implement the command interfaces to cards.


Previous Table of Contents Next