[continued from part I]
PIV and GIDS are the two smart card standards, or card edges, built into Windows 7. Earlier post in this series covered how the built-in discovery mechanism will try to check for both applications using their well-known AID when encountering an unfamiliar card for the first time. For those looking for a smart card solution with minimum hassle, that sound promising. No drivers or middleware installation required, not even behind the scenes installation from Windows Update. Implicitly one would also assume MSFT has tests their own applications– VPN, BitLocker-To-Go disk encryption, Kerberos smart card logon, TLS client authentication in Internet Explorer– end-to-end for these types of cards. In steady state, once cards have already been configured with the appropriate credentials, this assumption holds. The catch is, using a smart card is only part of the equation. Before reaching that point, the card must be configured with the type of cryptographic keys and credentials for the required scenario. For example VPN usually calls for an RSA key and associated X509 digital certificate.
PIV as defined by NIST SP 800-73 part I has the curious property that key-generation and loading certificates on the card requires the application administrator role, as distinct from card-holder role. While ordinary card operations such as signing a document calls for the user to enter his/her PIN, authenticating as the administrator typically calls for using a special RSA key or set of diversified symmetric keys which belong to the organization handing out the cards. End users typically do not have access to these credentials and can not load new credentials on the card without some help from the IT department. That has important implications for provisioning. For example it rules out the straight-forward enrollment option by visiting a web page that uses HTML keygen tag or the proprietary cenroll ActiveX control for Windows Certificate Server web-enrollment. Similarly the MSDN instructions for creating a self-signed certificate for use with BitLocker will not work on a PIV card.
On the bright side, requiring administrative privileges avoid certain maintenance head-aches. Because users can not muck with the contents of a card once issued, that may translate into fewer help-desk calls to replace/re-issue broken cards. That may have been the motivating factor behind this aspect of PIV design. (But then again, if users are allowed to run arbitrary software against the card, they can still brick it.) Otherwise the security advantages of such restrictions seem minor. Any attack that depends on users replacing the keys/certificates on a card, perhaps to take advantage of some vulnerability in the certificate validation logic somewhere, could also be implemented using bogus cards that do not obey PIV restrictions. One can argue that limiting the functionality of valid PIV cards makes the forgery of such attack cards a little more difficult, since attackers must also replicate the physical appearance of authentic cards.
The other major disadvantage is that properly configuring PIV cards requires separate middleware, usually locked into a particular vendor of cards. In other words, all that functionality built-into Windows for making PIV cards work seamlessly– a major requirement for government and defense customers– only applies to using existing credentials already on the card, not provisioning them in the first place.
That brings us to the second option supported out-of-the-box in Windows: GIDS or Generic Identity Device Specification backed primarily by MSFT and Oberthur. GIDS has functionality similar to PIV at a high-level. GIDS-compliant cards can generate and store multiple key-pairs of common algorithm types (RSA and ECC with standard NIST curves), perform cryptographic operations such as signing and decryption using these keys subject to PIN entry. They can also store auxiliary data including X509 certificates associated with the keys. Big advantage is that GIDS permits provisioning operations to be carried out with user PIN, allowing for self-service models.
At first that sounds like a decisive argument for going with GIDS. Returning to the original question, a user armed with a GIDS card can generate a self-signed certificate suitable for BitLocker by following exactly the steps in that MSDN article. The downsides are:
- PIV is by far more common. That in itself is not an argument about the merits of either standard, but it does translate into a more competitive market with greater choice of hardware, including in other form factors such as USB tokens. By contrast few vendors ship GIDS cards. (There are understandable reasons for this: PIV is a US federal standard mandated by the government, and it also predates GIDS by a couple of years.)
- PIV enjoys better cross-platform support. While OS X and Linux never had very good smart card support to begin with, the requirements from US government customers has forced vendors to at least implement basic support. There is even an Android application for reading basic information from PIV cards over NFC.
- A certification model exists for PIV cards, with independent labs testing cards submitted by vendors. NIST maintains list of products certified under FIPS 140 and the security-level they were certified for. (This assumes that a formal certification process helps improve product quality in the long run– a premise some disagree with.)
- Finally PIV has applications beyond logical access control. For example there is an entire suite of products for controlling building access with badge-readers that speak the PIV standard. No similar ecosystem of hardware and software exists for GIDS yet.