“The great thing about standards is that there are so many to choose from.”
Trying to pick a smart card for enterprise deployment recalls to mind this particular aphorism. This may be surprising for a technology that is over 30 years old, boasting large-scale real-world implementations thanks to wireless carriers (SIM cards) and payment networks (EMV chip & PIN.) Sure enough many aspects of the technology are standardized: ISO standard 7810 defines the physical characteristics of cards, while ISO7816 lays down the law when it comes to contacts and electrical properties. JavaCard and .NET Card are popular runtime environments for programming cards with custom applications. Meanwhile It is not only the internals of the card that have inspired thousands of pages of specifications. ISO7816 also defines low-level communication between a card and reader, Global Platform is de facto standard for managing card contents and more recently ISO 14443 extends this to contactless cards using NFC. Even at the programming layer outside the card, PC/SC API defined by Microsoft in the late 1990s has been ported to Linux and OS X to allow portable way of writing desktop applications to use smart cards.
With all of these acronyms and specifications published by august standardization bodies, one would expect that the technology has now become commoditized to the point that one can just pick up a particular smart card from any manufacturer and expect to use it for any scenario: login to a computer, sign your email, encrypt documents against theft. It turns out that instead the incompatibility has been successfully moved up the stack to the “last hop,” where there is a gap between the abstraction of a “smart card” that PC applications are written against, and the actual functionality loaded on the cards.
To take an illustrative example: earlier posts discussed the notion of using BitLocker-To-Go with smart cards to encrypt removable media. The question is, what type of smart card? (Side note on terminology: we group USB tokens that appear as combined card + reader such as Goldkey, in the same category, since the form factor does not change the software interoperability story.) Can users walk into a store or better yet order cards from a website that are guaranteed to work with minimal hassle? That turns out to be a surprisingly complex story, that depends not only on the functionality present on the card but the presence of appropriate middleware. The first part may seem obvious– given the way BitLocker works, the card must be capable of storing digital certificates and performing public-key decryption operations in order to unlock protected volumes. The unexpected part is that even cards meeting this criteria may not be usable without additional middleware, or in some cases, not usable at all.
The first observation is that most applications (including the OS component responsible for BitLocker disk encryption) do not deal directly with smart cards. Instead they go through an abstraction layer , described in earlier posts [1, 2 & 3] responsible for presenting a common interface for different types of hardware. This is accomplished by having drivers, corresponding to each type of card, combined with a plug-and-play mechanism for mapping drivers to cards. It follows that a necessary but not sufficient requirement to use a given card for general purpose applications on Windows is that appropriate drivers are installed. Note that “general-purpose” is the operative qualifier here: often times a vendor will provide hardware to be used with one specific application, also vendor-written and tailored to that hardware. In that model anything-goes, as the standard smart card stack is not in the picture. Aside from the obvious problem of vendor lock-in and lack of transparency, that approach will not fly when trying to leverage existing applications such as built-in VPN client, BitLocker or Outlook. In the best case, the drivers can be downloaded from Windows Update automatically when the card is used for the first time, using the ATR or a proprietary discovery applet defined by MSFT. But that requires a manufacturer willing to go to the trouble of getting their driver certified by Windows Hardware Quality Labs (WHQL). More likely the vendor will take the path of least resistance and distribute drivers via a proprietary channel such as their own website instead. That model might scale if the machines where the card will be used is known in advance. It runs into trouble when the user walks up to a brand new machine that has not been set up in advanced.
All of these edge-cases might warrant going with smart card profiles where the driver is already present in the OS out-of-the-box. Starting with Windows 7, PIV and GIDS drivers are built-in. The second post in this series will look at the arguments for and against these.