Microsoft Windows CE 3.0 Smart Card Subsystem

Microsoft Corporation

June 2000

Summary: Smart cards, or Integrated Circuit Cards (ICCs), are credit card–sized, microprocessor-based devices that help provide secure data storage and that communicate with applications running on other microprocessor-based devices. The Microsoft® Windows® CE 3.0 smart card subsystem provides a link between smart card interface devices (IFDs) and smart-card applications. This paper provides a brief overview of the architecture of smart card systems and describes the Windows CE 3.0 smart card subsystem. (6 printed pages)

Contents

Smart Card System Architecture Windows CE Smart Card Subsystem Components For More Information

Smart Card System Architecture

A typical smart card system consists of smart cards, their IFDs or readers, the applications that interact with the smart cards, and a subsystem that handles communication between the smart card readers and the applications. In Windows CE 3.0 this subsystem is made up of dynamic link libraries (DLLs) that provide system-level services such as resource allocation; other libraries that provide specific services on behalf of the smart card, such as authentication and file handling, a set of APIs that applications use to communicate with the resource manager, and device drivers for the smart card reader devices. In general, smart card-aware applications written for this architecture will use both the resource manager and one or more service providers.

The following diagram illustrates the architecture of a Windows CE-based smart card system:

ms834348.cesmartcard301(en-us,MSDN.10).gif

Figure 1. Smart Card system architecture

PC/SC Compliance

To assure ease of integration with a wide range of cards, drivers, and applications, the Windows CE smart card subsystem is fully compliant with the specifications defined by the PC/SC workgroup. The PC/SC specifications are based on the interoperability standards defined by ISO 7186, ISO 7816, and EMV, and complements those standards by defining low-level device interfaces and device-independent application APIs and resource management services.

Smart Cards

One of the most important features of smart cards is their ability to support multiple applications. For example, a card might contain an individual's driver's license, multiple credit card and bank accounts, workplace identification and stored value for the company cafeteria, and health care records. Each application is independent of the others—a police officer's card reader can read the driver's license information, but cannot view the bank account information, and an employer's card reader could not access the employee's driving record.

Smart Card Interfaces

In addition to their applications, smart cards can also implement and expose a set of interfaces that define the services available within a smart card, the protocols necessary to invoke the services, and any assumptions regarding the context of the services. Similar to COM interfaces, each smart card interface is identified by a globally unique identifier (GUID). For example, consider a hypothetical interface, IMugshot, which provides a JPEG image of the card owner for identification purposes. A single instance of IMugshot can provide photo identification for the drivers' license, and workplace identification. Similarly a smart card-aware application that knows the GUID for IMugshot can query the smart card database for a list of cards that support the interface.

Smart Card Readers

Smart cards connect to the host subsystem through an IFD, or smart card reader. The reader and host can be on a single device, or multiple readers can connect to the host (or a network of hosts) through variety of standard peripheral interfaces, including RS-232C serial, PCMCIA, and universal serial bus (USB) ports. In every case, however, readers are controlled by standard Windows device drivers, and as such must conform to the Windows CE device model.

ms834348.cesmartcard301(en-us,MSDN.10).gif

Figure 2. Windows CE device model

Windows CE Smart Card Subsystem Components

Smart Card Reader Drivers

The interface device handler, or reader driver has these elements:

  • The Reader Helper Driver Library provides common smart card driver support routines and provides additional protocol support to specific drivers as needed.
  • Specific Smart Card reader drivers, which map the conceptual driver services to the specific hardware reader device. There may be hierarchies of specific drivers as well, such as generic serial port drivers that communicate with specific port drivers. The specific reader driver must communicate any card insertion and removal events to the Smart Card class driver for forwarding to the resource manager. The driver also must provide data exchange capabilities to the card by any or all of the available protocols.

Service Providers

Smart Card service providers are base service providers (DLLs) that enable access to specific services. Each Smart Card Service Provider (SSPs) maps to a specific smart card implementation. Service providers are aware of the services provided by specific smart cards and facilitate applications' access to these services. SSPs can build on the services of other SSPs to accomplish their tasks. Examples of service providers that can be invoked by other SSPs are the ISO 7816-4 File System and APDU Providers.

The PCSC specification for service providers has defined common interfaces for widely implemented services (Authentication, File Access, Cryptography) In recognition of existing import/export issues, Cryptographic interfaces are relegated to their own service provider, isolated from other services.

Currently Windows CE does not include a Smart Card service provider. Typically, the vendor that supplies a smart card also provides the appropriate service provider(s).

Resource Manager

The resource manager coordinates the applications' access to readers and to smart cards. It identifies and tracks resources, allocates readers and resources across multiple applications, and supports transaction primitives for accessing services available on a specified card. It also provides the service provider(s) with what appears to be a direct connection to the target smart card.

Security and personal privacy issues are central to most smart card implementations. The resource manager maintains security by preventing unauthorized access to smart cards or readers and by tracking which cards are in which readers. Wherever possible, the resource manager uses the security mechanisms existing within the underlying operating system when accessing a reader or smart card.

Resource Manager API

The resource manager API is a set of Windows CE functions that provide direct access to the resource manager’s services. These functions can provide a list of smart cards supplied by a specific user, the interfaces, and the primary service provider of a specific card. Applications can also access the resource manager indirectly, through a smart card service provider.

Smart Card Database

The resource manager uses a database to keep track of readers, cards, applications, and service providers. The smart card database contains a list of known smart cards, the interfaces and primary service provider of each card, and known smart card readers and reader groups. Database security is maintained by placing access restrictions on the database rather than by adding security mechanisms to the smart card subsystem.

To simplify setup utilities and to ensure the integrity of the smart card database, the resource manager API provides functions for introducing and removing smart cards and readers to and from the database. Other functions track the activity of cards that are in use, and send and receive data to the readers on behalf of the application.

Accessing a Smart Card

The resource manager provides a variety of different methods for an application or service provider to connect to a smart card. The simplest way is for the application to call the SCardConnect function, specifying the reader it wants to communicate through.

An application can also search for a specific smart card within a specified 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 displays a graphical user interface (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 guide a 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 from the resource manager a list of cards that support a specified set of smart card interfaces. The application can then use this list to connect to cards based on their capabilities rather than their names.

When an application looks for a card, the application supplies an array of reader names. 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 can be opened for exclusive use by other applications, so access to this list of readers is not guaranteed.

Direct Access Functions

A number of smart card devices currently on the market do not conform to ISO-7816 specifications. For compatibility with these devices, Windows CE 3.0 provides a set of low-level access functions that allow applications to control communications directly with the card reader, and to retrieve and set card reader attributes.

For More Information

For additional information about the PC/SC workgroup, its specifications, and a list of compatible products, visit https://www.pcscworkgroup.com/.