Quick primer on the Windows smart-card stack (3/3)

In the final post of this three-part series, we will discuss the discovery mechanism. The definitive reference on this topic is the smart card mini driver specification at MSDN. Here only a few points will be highlighted.

There are two slightly different notions of “discovery” involved in smart cards:

  • Mapping a card to an existing driver when the card is presented to the system. In this situation drivers are already installed but the
  • Installing an appropriate driver when a new type of card is encountered for the first time. This is the analog to “plug-and-play” technology for smart cards. PnP allows connecting a peripheral such as printer to the PC and having that device automatically get recognized as the appropriate model and configured for use. Gone are the days of manually installing software from CDs shipped by the manufacturer. (Not that hardware vendors seem to have gotten that memo, since packages usually include a CD with proprietary software that installs the drivers.)

Appendix D in the driver specification describes the steps involved in each of these processes. For the case of plug-and-play, the overarching goal is to obtain a device ID which can be used to query Windows Update for the appropriate driver corresponding to that hardware.

  1. The system first attempts to locate a proprietary smart-card plug-and-play applet on the card, with functionality defined by MSFT. If that applet exists, it can be queried for a particular object containing the device ID.
  2. If PnP applet does not exist, Windows tries selecting the master file (MF) on the card and later the EF.ATR object to derive the ID from these sources.
  3. If that also fails, the smart card stack goes into guessing mode, trying to locate PIV and GIDS applets in that order.
  4. If the card does not support either of these profiles, a final attempt is made to construct device ID from the historical bytes portion of the ATR.

For subsequent driver selection, there are three paths:

  1. By card ATR. A mapping in the registry allows associating a particular driver with all cards returning a specific. (ATR matching can be done partially, by specifying an associated bitmask. This allows covering all cards with a particular prefix for example.)
  2. If no explicit registry mapping is defined, Windows next consults a cache of ATRs for cards previously identified as having PIV and GIDS applets. (This mapping is also maintained in the registry.) In this case ATR matching is exact.
  3. In case the cache does not help, the system goes into guessing mode, trying GIDS and PIV AID in that order– note this is the opposite order used during plug-and-play installation.

One important difference in Windows 8 is that when no driver is found, the card is associated with the null driver. That is a “steady state” and requires manual override to associate the card with a different driver. By contrast Windows 7 would repeatedly attempt to perform PnP discovery on the same card.


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s