HSM and Key Management

HSMs A Hardware Security Module (HSM) securely stores secret key material. They are similar to large-storage, multisession smart cards. However, unlike smart cards, they are used mainly on the server side of a system. are devices that create and maintain private keys in a secure manner.  The private keys are never made available outside of the HSMs and the device destroys its contents in the event of someone attempting to gain access to the private keys.

It is recommended that any sensitive device in the environment should generate its keys using a HSM.  Devices that are typically considered as security-sensitive include the following:

  • Certificate Authorities

  • Web servers

  • ActivID CMS

As its name implies, host-attached HSMs are devices that are directly attached to a host. These HSMs are attached to the ActivID CMS servers using a PCI card. ActivID CMS also supports a number of networked-based HSMs. The HSMs for ActivID CMS are managed by ActivID Key Management System (KMS). ActivID KMS and its tools are able to initialize, clone, and load the HSM as required. The ActivID CMS HSMs store and generate the following keys:

HSM Protection

A proper use of cryptographic keys is in most cases the right way to meet the ActivID CMS confidentiality and integrity objectives. It is therefore essential to control ownership of keys and HSM at all times. To protect the keys used in the ActivID CMS environment, every private key should be generated, stored, and protected by a HSM. In addition, all access to the HSMs should be audited, logged, and checked by multiple parties and no single individual should ever have access to or be able to access the HSM directly.

One assurance that should be obtained is that the HSM has been under control by the organization at all times. Therefore, it is critically important to maintain records of HSM movements.

Another assurance that should be obtained is that the HSM configuration and key content is exactly what ActivID CMS expects. Make sure that you carefully follow the HSM recycling guidelines.

All records shall be kept whenever HSMs are removed or disconnected from ActivID CMS for maintenance or for any other reasons. Also, keys should be changed whenever an HSM is put back in the system, and the PIN should be changed if it has been used outside of the regular environment.

Note: The principles mentioned in this documentation only relate to the HSMs that are used to protect the private keys used by ActivID CMS.
Other components such as the HSMs used to protect the Certificate Authorities and Web servers are considered to be outside the scope of this documentation.

ActivID CMS-Related Security Considerations

To ensure the integrity of the HSMs, it is recommended that a separate standalone system be used to manage and maintain the HSM. At no point should the ActivID Key Management System (KMS) software be installed on the ActivID CMS server. 

Once the HSMs are initialized, the hard disks of the standalone system should be stored in a secure manner and any access to them should be logged appropriately. In addition, the ActivID KMS failsafe.cfg file and the site keys should be stored in a secure location. In combination with the previous recommendations, performing the following processes in this section is required to secure the environment.

You should store all items related to the HSMs in a secure location in a Tamper Evident bag. This bag should be serialized and all access to this bag or its contents should be recorded in an HSM audit log. The devices include, but are not limited to the following:

  • Operator password

  • Security Officer password(s)

  • Key ceremony documentation

  • Site key

  • Management PC hard disk

  • Cloned HSMs

You should create an audit log for the HSMs. The audit log must be used to log all actions relating to the HSMs in a chronological order, with each entry numbered, dated, and signed by those who are present. 

It is important that you define procedures that detail the person permitted to sign and update the audit log and how many individuals can be present at any one time. It is recommended to have at least three witnesses to any event relating to the HSM.

The audit log must be stored in a secure location and should not be accessible by any individual member of the staff that is authorized to sign the audit log. The log should be updated for any of the following events:

  • Security incidents

  • Key ceremonies (Initialization, Master Key Import/Export, and Transport Key Import/Export)

  • HSM cloning

  • HSM initialization or destruction

To ensure that the customers’ private keys are sufficiently protected, external customers are only able to request certificates using ActivID CMS.

ActivID CMS instructs the customer smart card to generate private keys in the smart card. ActivID CMS is responsible for securely transporting the public key to the Certificate Authority for signing, and returning the certificate to the smart card using a Global Platform Secure Channel.

Smart cards issued by ActivID CMS are protected by Global Platform keys. Global Platform (GP) Master Keys are 3DES 112-bit keys, or AES 128 or 256-bit keys used to generate the keys for management or usage. Each GP Master Key Set is defined for a population of cards issued during the Master Key life span. GP Master Key Sets are groups of three master keys that correspond to the three keys required to open a secure channel (MAC, ENC, and KEK). These Master Keys are permanently defined in the HSM.

When a smartcard is initialized by ActivID CMS, the three GP Master Keys are replaced with new keys generated by the HSM. These new keys are generated by diversifying the GP Master Keys with the smart card serial number.

For a complete description of the HSM Key ceremony, refer to the HID ActivID Key Management System Installation and Usage Guide.

The HSM Key ceremony needs to be performed in a secure environment so that the GP Master Keys do not become compromised. If the Key ceremony is not performed and well-known test keys are used instead, there is a risk that an attacker could record the new card keys as they are personalized on the new card. There is also a risk that an attacker could intercept the card before it is personalized, and add his or her own management keys on the card.