smart card driver

                           




http://www.media
Picking up from part I and part II, we turn to the problem of installing vendor-specific drivers to access additional PIV functionality in GoldKey USB token which is not exposed by the driver built into Windows.
The driver can downloaded from Microsoft Update Catalog. (Credit goes to Himanshu Soni from MSFT for this hint.) First step is obtaining the hardware ID. This is easiest to do from the GUI using Device Manager:

Viewing device properties in Computer Management / MMC

The hardware ID is hidden in the “Details” tab of the Properties dialog, by scrolling the drop down menu:

Device details for GoldKey token, detected as PIV-compatible smart card

Right-clicking to copy that ID, we can run a query on online Catalog by hardware ID. The search returns a couple of hits, for different version of the driver and operating system. After installing the latest driver available for the appropriate local Windows version, there will be several changes in the way smart card stack operates. First the USB token will be identified as GoldKey instead of as generic PIV card:

Smart cards and readers, after GoldKey driver installation

Note that the virtual smart card reader presented by GoldKey– after all every card must be present in a reader according to PC/SC model– is still identified as a generic MSFT device based on the Windows user-mode driver framework (WUDF)
Another side-effect of installing the driver is a change to the registry to correctly identify all future instances of GoldKey based on the answer-to-reset (ATR) value returned by the card on initial activation. Looking at HKLM\Software\Microsoft\Cryptography\Calais\SmartCards, we observe that there is a new card type in addition to the built-in entries for PIV and GIDS:

Registry key corresponding to GoldKey

As for the meaning of the values:

• “Crypto Provider” refers to the cryptographic service provider (CSP) associated with this smart  card. Not surprisingly, since the token confirms to the Windows smart-card architecture described earlier, this is the vendor-independent base CSP used for all smart cards. Same goes for the “Key Storage Provider” entry, which is the CSP-equivalent in the next-generation cryptographic API in Windows.
• 80000001 value identifies the smart-card mini driver. In this case it is a DLL authored by GoldKey installed from Microsoft Update earlier. (By contrast, the other two entries both point to the same system DLL with tell-tale prefix “ms” often used for MSFT binaries.) This module will be loaded by the CSP/KSP, depending on which interface an application is using.
• The more interesting values are “ATR” and “ATR Mask,” which are responsible for the discovery logic. When a new smart card is presented, the system checks its ATR for exact match against each smart card type defined these registry keys. The criterion for comparison is:

Observed & ATR-Mask == ATR & ATR-Mask

where “Observed” is the ATR returned by the unknown card, & denotes bitwise and operator, ATR and ATR-Mask are the values taken from registry key. The mask provides flexibility when the ATR can vary slightly for the “same” type of card. For example a certain byte may differ depending on card options, even when all of them have exact same card applications and should be mapped to the same driver. By setting specific bytes or bits in the mask to zero, they are effectively ignored in the comparison. In other words it is a rudimentary wild-card pattern. In this case, the ATR mask is set to all ones, indicating an exact byte-for-byte comparison with no variations allowed.

With the ATR mapping in place, all other instances of GoldKey tokens will also be correctly associated with the custom driver. Next we can examine what happens during a provisioning operation by re-running the command line from last post and capturing an APDU trace.

[continued]

fire.com/download/bsped5ww6gp5cdl/Smart+Card+Driver+windolws+7.rar