Previous Table of Contents Next


As smart cards become more widely understood and used, smart card capabilities are also appearing as extensions or options on existing domain-specific application programming interfaces. Furthermore, since some application types—cryptography or credit card payment, for example—will have a particular use for the capabilities of a smart card, there are a growing number of domain-specific application program interfaces for smart cards. Tables 7.2, 7.3, and 7.4 list some domain-specific APIs for smart cards or that include smart cards.

Table 7.2. Payment system reader-side smart card APIs.
Name Primary Vendor URL Email Contact

EMV’96 Europay, MasterCard, Visa www.mastercard.com
Visa ICC Specification Visa www.visa.com
C-SET Europay www.eurocard mastercard.tm.fr gdaligault@ europayfrance.fr
SET Version 2.0 Visa, MasterCard, AMEX www.visa.com tlewis@visa.com
Visa Open Technology Platform Visa www.visa.com

Table 7.3. Cryptographic reader-side smart card APIs.
Name Primary Vendor URL Email Contact

Cryptographic API Microsoft www.microsoft.com boltr@ microsoft.com
PKCS #11 RSA www.rsa.com
DCE Personal Security Module Open Group www.opengroup.org
Schlumberger Cryptoflex Schlumberger www.cyberflex. austin.asc.slb.com

Table 7.4. Other domain-specific reader-side smart card APIs.
Name Primary Vendor URL Email Contact

IATA 791/20.204 Int’l Air Transport Assoc. www.iata.org sanfordk@iata.org

The reader-side smart card API situation is by no means settled, and the standards and mind-share wars are just beginning. Furthermore, these interfaces are not mutually exclusive. One could, for example, implement the EMV’96 terminal interface within PC/SC or the PKCS #11 interface within Open Card. Due to its inclusion in the widely distributed Windows operating system, the PC/SC architecture is a solid and soon-to-be widely available foundation for including smart cards in applications.

This chapter describes some popular high-level, reader-side APIs for smart cards. These descriptions are not a substitute for the full documentation of the interface, but are intended to provide a sense of the level and orientation of the interface.

PC/SC

Led by Microsoft, a team of smart card manufacturers (including CP8 Transac, Hewlett-Packard, Schlumberger, and Siemens-Nixdorf) defined a general-purpose architecture for including smart cards in personal computer systems. The specification for this architecture was published in December 1996 and is called the Interoperability Specification for ICCs and Personal Computer Systems. It has come to be known as simply PC/SC.

A primary purpose of the PC/SC architecture and specification is to enable card reader manufacturers and smart card manufacturers to develop products independently but have the results of their efforts smoothly work together. As a result of this effort, application programmers can build smart card applications that aren’t tied to particular readers or cards, and system builders can mix and match readers and cards freely. Figure 7.1 is a diagram of the Microsoft PC/SC smart card architecture.


Figure 7.1.  The PC/SC architecture.

The PC/SC architecture defines the interface between smart card readers and the resource manager so that, from the application’s point of view on top of the resource manager, all smart card readers look and behave the same. A smart card reader manufacturer provides with its smart card reader hardware a PC/SC driver that connects the reader hardware to the resource manager. Thus, a smart card reader is treated by the system just like a floppy disk reader or a CD-ROM reader. The only difference is that you put a smart card into it rather than a floppy disk or a CD-ROM.


Note:  
Since smart card readers vary more widely and can contain more functionality than a simple floppy disk reader, there is a provision in the PC/SC architecture for the application program to communicate directly with the smart card reader in addition to communicating with the smart card that it contains. This capability is indicated by the line directly between the application and the resource manager. This interface could be of use when, for example, the smart card reader is an automatic teller machine (ATM) or a point-of-sale (POS) terminal.

The actual application programming interface seen by the smart card application is provided by the smart card service provider (SSP). This interface can be card specific, domain specific or completely general purpose. The PC/SC specification includes a description of general-purpose interface, which includes card authorization, PIN verification, file access, and cryptographic services. This interface is described in the section “The PC/SC API.”

Card-specific PC/SC smart card service providers are typically written by smart card manufacturers and included with the cards themselves. Thus, for example, Gemplus provides an SSP for each of its off-the-shelf cards, as do Schlumberger and Datakey. Minimally these card-specific SSPs make each command supported by the card available to the application in an easy-to-use manner. Some also support some higher-level functionalities that can be built from the basic commands.


Previous Table of Contents Next