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
