2.3. Working with Smart Cards (TMS)

Most certificates are enrolled through the CA. When certificates will be enrolled through an application such as a web browser or web server and will only be used by that application, then a simple CA or RA configuration is all that's necessary.
For security and for broader uses of the certificates, many organizations uses smart cards (also called tokens). For managing smart cards, or tokens, Certificate System uses interlocking subsystems to create a token management system (TMS) which handles operations for certificates and keys stored on smart cards.
A TMS environment requires a CA, TKS, and TPS, with an optional DRM for server-side key generation:
  • The Token Processing System (TPS) interacts with smart cards to help them generate and store keys and certificates for a specific entity, such as a user or device. Smart card operations go through the TPS and are forwarded to the appropriate subsystem for action, such as the Certificate Authority to generate certificates or the Data Recovery Manager to archive and recover keys.
  • The Token Key Service (TKS) generates, or derives, symmetric keys used for communication between the TPS and smart card. Each set of keys generated by the TKS is unique because they are based on the card's unique ID. The keys are formatted on the smart card and are used to encrypt communications, or provide authentication, between the smart card and TPS.
  • The Certificate Authority (CA) creates and revokes user certificates stored on the smart card.
  • Optionally, the Data Recovery Manager (DRM) archives and recovers keys for the smart card.
The Enterprise Security Client is the conduit through which TPS communicates with each token over a secure HTTP channel (HTTPS), and, through the TPS, with the Certificate System. As with a non-TMS environment, an OCSP responder can be used to check the revocation status of certificates.
How the TMS Manages Smart Cards

Figure 2.3. How the TMS Manages Smart Cards


To use the tokens, the Token Processing System must be able to recognize and communicate with them. The tokens must first be enrolled to format the tokens with required keys and certificates and add the tokens to the Certificate System. The Enterprise Security Client provides the user interface for end entities to enroll tokens.

2.3.1. The TKS and Secure Channels

The Token Key Service (TKS) generates the (token) keys the TPS uses to communicate with the Enterprise Security Client. The TPS communicates with the TKS over SSL, but the TPS communicates with the smart cards themselves over a secure channel. The secure channel is made from an agreed on algorithm which is used by the TPS and smart card to independently derive three keys. The TKS provides the security between tokens and the TPS since the security relies on the relationship between the master key and the token keys.
Every smart card has three keys stored on it:
  • An auth key which is used for encryption and authentication; a session key dervied from the auth key each time a secure channel is opened.
  • A MAC key which is used for message authentication; like the auth keys, a session key is derived from the MAC key each time a secure channel is opened.
  • A key encryption key (KEK) which is to encrypt the session keys.
The TPS contacts the smart card to initialize a secure channel, sending key set information and a host challenge. The smart card creates a card challenge, generates the session keys, and generates a cryptogram, then sends its initialization response. The TKS — using the card UID number, an agreed on algorithm, and the key information — independently derives the session keys and the host cryptogram. The TKS uses the host/server cryptogram to verify the card cryptogram, and then TPS establishes the secure channel with the smart card.
Having the TKS independently derive the session keys effectively shares secrets between the TPS and the smart card without having to store these symmetric keys on the server.
The TKS manages the master and transport keys required to generate and distribute keys for smart cards or tokens. A master key is a Triple DES symmetric key stored either in software or hardware token. The transport key wraps the other keys derived and used by the TKS and TPS.
The TKS actually carries out the key-related functions that the TPS needs for its communications:
  • Helps establish a secure channel (signed and encrypted) between the token and TPS.
  • Provides proof of presence for the security token during enrollment.
  • Supports key changeover when the master key changes on the TKS. Tokens with older keys get new token keys.
  • Helps generate a symmetric session key for the DRM to wrap (encrypt) the entity's private key for (optional) server-side key generation, where the entity's encryption keys are generated on the DRM

NOTE

Because of the sensitivity of the data that the TKS manages, the TKS should be set behind the firewall with restricted access.