A smart card interface consists of a predefined set of services available within a smart card, the protocols necessary to invoke the services, and any assumptions regarding the context of the services.

With respect to smart cards, the term “interface” is similar to how it is used in COM, which in turn is similar in concept to the ISO 7816/5 application identifier but with a different scope. Each smart card interface is identified by a globally unique identifier (GUID). For example, an interface might be defined that provides biorhythm information to its holder. If a given smart card supports this service, then it may claim to support that interface GUID. Using the interface GUIDs, an application may search for a particular set of interfaces, locating any card that supports that set, to complete a task.

Although an interface has one GUID, it might be implemented differently on different cards. For example, the biorhythm interface mentioned above can have several different implementations, yet all are referenced using the same GUID. The different implementations would not change the interaction between the application and the smart card; however, the interaction between the service provider and the smart cards may differ depending on the interface’s implementation.

Primary Service Provider

Each smart card known to the system may have a registered COM interface listed as its primary service provider. When you access a smart card through COM, this primary service provider supplies the control interfaces to the card. This allows card services to be exposed to a wide range of programming environments, including Java and Visual Basic.

Introducing Smart Cards to the System

Before the smart card subsystem can find a smart card, the smart card must be introduced to the system. This is typically done with a smart card setup utility provided by the card manufacturer. The utility could come as a program on a floppy disk (with the smart card), an ActiveX control available on a web site, and so on.

The setup utility must provide the following pieces of information about the card:

  • Its ATR string, and an optional mask to use as an aid in identifying the card.
  • A list of smart card interfaces supported by the card.
  • A friendly name for the card, to be used in identifying the card to the user. In most cases, the user will supply this to the setup utility.
  • The primary service provider associated with the card (optional), to be used when accessing the card through COM interfaces.

To simplify setup utilities, and to ensure the integrity of the smart card database, the smart card subsystem provides the following two functions. SCardIntroduceCardType introduces a smart card into the database and SCardForgetCardType removes it from the database.

.

Accessing a Smart Card

The smart card subsystem provides several means for an application or service provider to connect to a smart card:

  • An application can call SCardConnect to connect to a card that resides in a given reader. This is the simplest way to establish communication with a smart card.
  • An application can search for a specific smart card within a given reader group. The application identifies the card by its friendly name, and specifies a list of readers in which the card may appear. The resource manager searches the list of readers for any cards with an ATR string that matches the named card, and returns status information to the application. The smart card subsystem never puts up a GUI or interacts with the card beyond obtaining the ATR string. It does, however, supply sufficient information for the application or a common control to be able to walk the user through locating the desired card or card type. This results in mapping the request to a specific reader, to which further I/O is directed.
  • An application can request a list of cards supporting a given set of smart card interfaces. The application can then use the list in the previous case. This allows applications to connect to cards based on their capabilities, without regard to their names.

When an application looks for a card, it supplies an array of reader names in which to look. For each reader element in the array, the resource manager supplies the following information:

  • Whether the reader is available for use by this application.
  • Whether there is a card inserted into this reader, and if so, what its ATR string is.
  • Whether the card’s ATR string matches any of the requested cards’ ATR strings.

The application uses the returned information to apply further filters to the cards or to prompt the user to select the desired card. Note that one or more of the returned list of readers may be opened for exclusive use by other applications, so access to this list of readers is not guaranteed.

Relation to Other Services

Other parts of the Microsoft Internet Security Framework use the smart card subsystem, as shown in the following illustration. (Because of U.S. export restrictions, a CSP that uses an SCSP to communicate cryptographic-related requests should sign and verify the SCSP.)

 Smartcard,Smartcards,Smart Card,Smart Cards,ISO Contact Card,ISO Contact Cards,Contact Card,Contact Cards,Printing Cards,SLE5542 Offset Printing Cards,SLE5528 Printing Card,ATMEL AT88SC153 Offset Printing Card,SLE5542 Contact Card