Previous Table of Contents Next


Summary

You will spend most of your smart card application development effort working with one or more reader-side application programming interfaces. A critical question to ask yourself as you design your application is how much of the smart card do you want your application to use. At one extreme, you can design your application to take advantage of some unique features of a particular smart card and use an API that surfaces all of these features to your application program. At the other extreme, your application may not be aware that there is a smart card “down there” at all, when, for example, the card is hidden behind a generic cryptographic interface. Between these two extremes are applications that use cards which conform to specific standards, such as EMV or ISO 7816-4, which can be purchased from many vendors.

Since a smart card is in fact an active computer rather than just an inert storage device, you will also be faced with the question of what functionality to implement on the host side of your application, and what functionality to implement on the smart card. While it can take a noticeable amount of time to ship data to the smart card and wait for its reply, the calculations it does are done in a secure environment and the parameters that these calculations use are not exposed to compromise. Generally speaking, if it is a public calculation, do it on the host, but if there are aspects of the calculation you don’t want stolen, do it on the card.

A smart card can add significantly new functionalities to almost any application, initially, perhaps, as simply a secure, portable data store, but eventually as an integral part of a truly distributed application. These new functionalities will only be realized if the unique properties of a smart card, particularly its secure computing capabilities, are thoroughly understood and carefully harnessed.


Previous Table of Contents Next