Using a GoldKey token as PIV card (part I)

GoldKey is one of the handy self-encrypting drive solutions on the market, with an unusual feature: it can also function as a stand-alone smart card compliant with the PIV standard. An earlier post looked at the limitations of using a dedicated drive such as IronKey, compared to applying BitLocker-To-Go to any old disk using smart cards. The main problem is locking the user into the storage capacity of the removable drive. An IronKey has hardware secure element for managing encryption keys, but it is only capable of applying that to protect its on-board storage. By contrast, a general purpose smart card combined with BitLocker-To-Go can encrypt an arbitrarily large volume with comparable security assurance and much lower cost. Since the drive itself is just off-the-shelf commodity hardware, there is a very competitive market pushing storage capacities higher and prices lower.

GoldKey tokens then combine the best of both worlds. For users looking for a turnkey solution, they provide a ready-to-use encrypted drive with cross-platform support, independent of any operating system functionality. For those interested in encrypting other (larger) volumes in conjunction with an existing disk encryption system such as BitLocker, they offer full PIV card functionality. At low-level, the token presents itself as a smart card reader with PIV card already inserted into that reader.

In fact since PIV can also be used for other security applications such as authentication or document signing, the value proposition is not limited to encrypting data at rest. PIV standard defines up to five types of keys with confusing names, although not every card is necessarily provisioned with all of them:

  • Card management
  • PIV authentication
  • Card authentication
  • Key management
  • Digital signature

The first key is not intended for end-user scenarios; it is only for use by administrator in configuring cards. PIV authentication key is used for logical access, such as smartcard logon to Windows. Card authentication key is special in that it can be used over contactless interface– in other words, over NFC– which makes it perfectly suited for physical access scenarios: tap the card against an NFC reader to open doors. Key management is a fancy name for encryption. That key would be employed when decrypting S/MIME email message or protecting sensitive data at rest. The final key, as the name suggests, is for digitally signing email and documents. GoldKey user manual gives examples for many of these use cases, except physical access which obviously can not be supported easily due to form factor.

PIV is a great choice here, because it is a widely deployed standard with cross platform support. It also happens to be one of two card types recognized by default in Windows 7 and later out of the box. It does have one downside compared to the other, far less popular option of GIDS: in standard usage PIV cards do not allow self-service enrollment. More specifically, users can not generate new keys or load certificates on the card by themselves. Here the story gets better, owing to a GoldKey-specific quirk: in a departure from the strict FIPS behavior, these tokens can be provisioned by the end user using custom mini-drivers from GoldKey. Appreciating the significance of this– and why it is not standard FIPS 201 behavior– calls for a detour into PIV.

The limitation is not due to any oversights in NIST 800 SP73 part 2, the authoritative specification of the on-card behavior of PIV applications. Quick peek shows that all of the primitives required for certificate enrollment are present:

  1. Generate a new key pair and return the public key. That would be GENERATE ASYMMETRIC KEY.
  2. Digitally sign a CSR (certificate signing request) containing that public key using the corresponding private key. Check; signature operations are implemented using the all-purpose GENERAL AUTHENTICATE command. Constructing the CSR and populating its fields is typically done off-card, since the card does not know about certificate templates. Signing a hash of the resulting CSR is necessary and sufficient.
  3. CSR is sent to the certificate authority. CA verifies the identity of the requestor using an out-of-band process and sanity checks the CSR fields for consistency. (For example user Alice can only submit a CSR where the “common name” field says Alice.) The card is not involved in this step.
  4. Assuming all checks out, a proper X509 certificate is returned to the user. That certificate needs to be loaded on the card. That final step is accomplished with the PUT DATA command, also clearly defined in the spec.

The catch: steps #1 and #4 require administrator privileges. The specification also defines roles associated with the PIV application and associated credentials. End users have a PIN and entering that credential authenticates as card-holder rather than administrator.  (Note these privilege levels have no relationship to enrollment restrictions around the certificate, and whether the certificate authority is willing to issue a certificate. Even if the user has root/administrator privileges on the local machine and a certificate already in hand, the card would not allow loading it.) By contrast, authenticating as administrator requires credentials that are held by centralized authority such as the IT department overseeing the card deployment.

What could be the motivation for this policy choice?



Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s