The first post in this series described how the PIV specification defined different privilege levels, and specifically required administrator access to enroll for new digital certificates on a compliant card. By itself this is not a technical limitation. After all end users can be given the administrator credential for their cards, in addition to the usual PIN used for authenticating as card-holder. Alternatively cards can be issued with a well-known default administrator key. Realistic deployments do not work this way. Typically those credentials are held by the organization overseeing the card program. Enrollment is either done ahead of time– users are issued cards already configured with the necessary certificates– or it is done in person. The user shows up at the IT department office and connects their card to a dedicated machine that has access to the administrator keys for all cards issued by that organization. There are two arguments for doing it this way:
- Lower maintenance costs. Users can not delete credentials or otherwise mess up the existing card state if they do not have credentials necessary for doing so. But this argument fails for two reasons. First users would have to go out of their way to trigger provisioning events, using specialized software. Second even with the administrator restriction, they can still lock up a card by entering wrong PIN repeatedly. In the case of Global Platform compliant cards, they may even brick the card for good by repeatedly failing authentication to the card manager.
- Verify the authenticity of cards. This is a more subtle requirement: when a user is trying to enroll for a certificate, how does the issuer know that keys were indeed generated on a smart card? The whole point of using smart cards is that key material is generated and lives only inside the card; it never leaves that trusted boundary. During certificate enrollment, the user is presenting a CSR already signed with the private key they claim was generated on the card. Can the issuer verify this? Even if enrollment is done in person similar concerns remain for high-assurance environments. How does the IT staff know that user is presenting a genuine card? After all anyone can take a blank white plastic card, print all the right logos and provision an applet that looks like PIV but has an intentional backdoor for leaking keys.
Requiring extra authentication before generating keys and loading certificates can mitigate that, if the protocol is designed properly. It is not clear this holds for PIV. There is a challenge-response scheme for authenticating administrators, but at the end of the day the card responds with a simple yes/no answer declaring success. A bogus card can always report success making it look indistinguishable from the genuine version. (That said, it is possible to use this as a primitive operation to verify that the card is genuine. Armed with the administrator credentials, one can flip a coin and depending on the result, either authenticate correctly or deliberately supply the wrong answer to the card. A counterfeit card has 50% chance of returning the correct success/failure status. Repeating that multiple times one can get down the probability of using bogus card as low as desired. It is unclear if such a process is ever used in practice.)
Back to the GoldKey. As hinted earlier, the PIV application on the token supports provisioning as card holder. The catch is that requires installing additional software. This is an unintended side-effect of the way discovery works in Windows: The GoldKey token presents itself as a plain smart card and reader combination, the OS will automatically try to infer the type of card. One of the steps in this process is to check for PIV and GIDS cards by selecting the well-known AID for those standards. By design the token responds successfully to a SELECT for PIV. But that leads the OS to conclude that this is “just” an ordinary PIV card and associate it with the built-in driver. This can be observed by expanding the “Smart cards” node in Device Manager:
That inscrutable device name comes from the document defining the PIV standard: National Institute of Standards & Technology (NIST) publication 800-73. The good news is smart card discovery worked flawless and identified the GoldKey token as PIV card. The bad news is that built-in driver for PIV does not support provisioning, for reasons alluded to above and in the earlier post. One way to verify this is to try using certreq tool to generate a self-signed certificate for a regular PIV card, as described in the MSDN article on BitLocker. The operation will fail:
As an aside, GoldKey would present a different error if used in the same scenario, since it also emulates a card reader with a fixed card– there is no point in asking user to insert a different card.
Getting past this stage requires installing the correct smart card mini driver.