Securing PKI: Protecting CA Keys and Critical Artifacts

Article
08/31/2016

Applies To: Windows Server 2003 with SP2, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012

A primary security control in a PKI is how private keys are stored and managed, particularly for certification authorities. A strong key protection strategy along with other physical and logical controls can provide defense in depth to prevent external attackers or insider threats from compromising the integrity of the PKI. Additionally, a well-run PKI requires the secure storage of several artifacts, such as HSM activation cards or tokens, backup files, and documents. Improper storage of these artifacts can lead to the compromise of the entire PKI, without an attacker ever having to compromise a CA system. This section provides a set of recommendations for securing the keys used by CAs or other critical systems, and recommendations for securely storing other PKI artifacts.

Protecting CA Keys

When designing a new PKI, a key design decision is whether or not to use an HSM or create keys stored in software. HSMs come in a number of form factors including rack-mounted appliances which can be attached using a serial or network connection, as well as smaller PCI or USB-connected devices. HSMs have a number of tamper-evident and self-destructing features. They are also available with multiple performance and compliance options. However, purchasing HSMs for PKI can represent a significant capital investment. For all CAs used in a production environment to secure corporate resources, a recommendation is to implement an HSM as part of a secure PKI. Below are a number of the benefits gained when using an HSM:

HSMs provide the capability of enforcing additional controls whenever the CA key is used, such as enforcing Enforcing Multi Person Control
Implementing HSMs ensures that the private key cannot be used without access to a properly configured HSM. In the event of a compromise, the damage done can be limited. With a software-based key, any number of copies of the key can exist and be used from any computer.
HSMs perform cryptographic operations on secure hardware. Even if a computer is compromised, the cryptographic keys are not available in the computer’s memory to be captured.
HSMs can provide tamper evidence or tamper resistance for physical attacks

Note

Marking a software-based key as “not exportable” is not considered a security feature and should not be relied upon to prevent attackers from obtaining the private key.

In a default Active Directory® Certificate Services installation without an HSM present, the CA private key is stored using the Data Protection API (DPAPI) which encrypts the key using the local computer account credentials. Additionally, by default the CA private key is marked exportable. Therefore, any person authenticating with local administrator privileges can access, back up, or export these keys using a number of various methods including the Certificates MMC Snap-in, the backup function in the Certificate Services MMC Snap-In, and using certutil.exe and use them in another location. Use hardware protected keys and avoid using software-based keys for CAs unless the PKI is considered low assurance or the PKI is not used to protect high value data or transactions (e.g. lab environment, proof of concept, etc.) or if using an HSM is not feasible due to operational or fiscal constraints.

Migrating Software Keys to HSMs

While it is technically possible in many cases to migrate an existing software-based key to an HSM, in general it is not the preferred approach. One of the benefits in using an HSM is the knowledge that the key has never been stored or used outside the secure HSM. Even if no compromise has occurred or is suspected, with a software-based key there is no real assurance that other copies of the key do not exist. In the event that you have an existing PKI and want to begin leveraging HSMs, consider a migration to a new infrastructure with new keys that are generated within the HSM.

Network Based HSMs

Some HSMs are network based. Since offline CAs should not be connected to a live network, it is recommended that if network HSMs are used for offline CAs, that they are connected via a private network that only contains the CA and the HSM device. For example, a dedicated switch can be used to connect the two devices. Avoid connecting the private network to a live network.

Multi Person Control

HSMs help enforce multi person control for sensitive processes, such as configuring a new HSM module or activating a key for use. This is commonly known as “k of n”, or having a “quorum.” The basic premise of k of n is to divide the interactions needed to access information among multiple entities. In the case of an HSM connected to a CA, multiple objects, typically cards or tokens, need to be connected to the HSM to generate or activate use of the CA private key. The cards or token can then be separated, distributed, and securely stored to help enforce these processes.

When determining how many tokens to create and how many to require for different tasks, it is important to take into account the following:

The level of oversight required – For a sensitive root CA, it may be desirable to have multiple organizations hold portions of the access tokens, so there is oversight from multiple teams prior to any work being technically performed
Operational overhead – Generally speaking, the greater the level of protection given to a key the greater the operational overhead will be to perform tasks on the CA
Backup and disaster recovery – Always create enough objects such that a quorum of objects is available in the event of a disaster

Consider the following example and how it illustrates the recommendations above. A private key could be stored on an HSM where, to access the key, three of six objects would be needed to administer the HSM, and three of six objects would be required to activate the private key for use. In this example, where both the operational set and administrative set would require three objects for access, the six objects could be divided into two sets; a primary set and a backup set. After this division, the objects would be divided into three distinct parts. These three parts could be distributed to representatives from different organizations where their representatives would ensure the objects were individually inventoried, placed in tamper-evident containers, and escrowed to separate locations, or handled in a way to ensure separation.

The figure below shows this example relationship between HSM objects in creation and in distribution.

Example HSM Object Relationships

The figure above assumes there are three disjointed entities or organizations involved in this process. Example organizations are:

PKI Administration – A team or organization ultimately responsible for maintenance and upkeep of the PKI servers
Information Security – A team or organization responsible for securing data and assets without having administration ownership
Operations Security – A team or organization responsible for architecting and/or enforcing physical and/or process security
Internal Audit – A team responsible for ensuring security policies, procedures, guidelines and standards are being enforced
Other Stakeholders – Teams or Organizations dependent on PKI services

By ensuring the involvement of organizations beyond PKI Administration, a level of checks and balances is achieved. The cooperation and continued involvement of these organizations is crucial. Ideally, no one person or organization controls these critical assets.

Enforcing Multi Person Control

If the policy in the fictitious example above is to require all three organizations to participate whenever the CA key is used, additional controls need to be put into place. In this example it would be possible for only two organizations to be required if one of those organizations obtained both their primary and backup objects. When designing how to separate these critical objects, ensure that adequate technical or procedural controls exist to ensure that no single person can access a quorum of objects. For example, further enforcement could be performed by leveraging the storage facility access procedures. Staff of the storage facility could help by verifying identification and enforcing logical access by requiring multiple person’s access challenges or by utilizing separate secure containers with multiple locks. The process can also be simplified by placing secure storage capacity onsite in control of the data center operations security.

One way to regulate access to secured assets is to ensure two representatives are present and positively identified prior to being granted access to their secured assets. For example, a combination of photo identification, biometrics, or other means of identification can be required prior to allowing access to the secure facility, or the location housing the offline CAs. An example of object mapping is shown in the figure below, where there are three fictional organizations involved; PKI Administration (PKIAdmin), Information Security (InfoSec), and Operations Security (OpsSec).

Example Object Storage Map

Multi Person Control without HSMs

In situations where an HSM cannot be used, it is critical to protect and monitor persons and accounts with local administrator privileges. Multi-person control can be achieved in several ways including multiple door locks, incorporating multi-factor authentication and separating factors, or even having multiple people set a single password for an elevated account where one person setting a password part does not disclose their part to the others setting a password part. In the example below, a pseudo-randomly generated 60 character strong password is separated into distinct parts.

Example Password Part Separation

The password parts could be generated and set separately, and stored similarly to the HSM object storage example above. The figure below shows a simple example solution for separating password parts between the three fictitious organizations.

Password Part Storage Map

If a method in which passwords are written or printed is used, special care should be taken to ensure the password parts are distinctly generated and not stored electronically.

Artifact Protection and Chain of Custody

Protecting the private key ensures that the trust granted to the CA is protected. If the private key is protected by an HSM, handle the HSM cards or tokens as critical assets. These objects, along with any other important data such as backup drives, USB-form factor HSMs, standalone safe keys, written combinations, or written password parts need to be tracked, inventoried, and verified end to end. If this data is not properly secured, it may be possible for an attacker to compromise the PKI without ever having to compromise a single computer.

Use Tamper-Evident Containers

Some assets in a PKI should have their usage tracked, and any unauthorized use or attempted access should be detectable. For these situations, it is recommended to use tamper-evident bags or containers to store assets. For example, using tamper-evident bags for objects used to activate a CA private key provides assurance that the objects have not been used or compromised.

Choosing a good tamper-evident container is not a trivial task. Ideally, the container has a strong seal, has a good resistance to humidity, has a unique number stamped on the outside, and has an area to write details for chain of custody. Since these objects may contain electronics, anti-static properties may be desirable. Some manufacturers will offer samples to evaluate before making a purchase. Stores specializing in assisting financial businesses or law enforcement have many options for tamper-evident containers as well.

While it may be a good idea to use a transparent container for asset-tagged artifacts for identification and verification, ensure any artifacts with secrets such as password parts are safely concealed, either by using a non-transparent tamper-evident container, placing the material in a non-transparent envelope, or placing the envelope in the transparent tamper-evident container.

Artifact Storage

PKI artifacts are often required to be stored for long lengths of time. When storing artifacts, ensure that they are in a climate-controlled environment such as an onsite datacenter vault or a safe-deposit box. Silica gel packets can be used to eliminate any residual moisture if they are inserted with artifacts in anti-static bags or storage containers.

Maintain a Chain of Custody and Asset Inventory

As you operate a PKI, the secure assets may need to be moved, or possession may change to another person or organization. For all secure assets, create a chain of custody that tracks who is responsible for the asset. Keeping a chain of custody will ensure that if there is ever an investigation into misuse of the asset, a strong audit trail will exist to show who had possession at all times.

When storing the artifacts in a vault, safe, or other type of storage cell, perform a hand-written check-in log and inventory and retain the logs. When extracting the artifacts, the previous inventory needs to be verified, and a check-out log written. These check-in and check-out logs should have fields for the following:

Date and time
The tamper-evident container unique code or number
Identification or asset label of the artifact contained within the container
Verification that the container is not tampered with
The person performing the inventory
Check-out or check-in
A location where the artifacts were extracted or secured

Below is an example of a check-out log with fictitious entries.

Sample Check-out log

At regular intervals, even if artifacts are not used, inventories should be performed and a copy of the inventory stored with the artifacts. Below is a sample inventory log with fictitious entries.

Sample Inventory Log

Conclusion

Using an HSM to provide strong protection of CA keys or other high value keys is one of the strongest controls you can implement to protect your PKI. HSMs can provide assurance that keys are only available for use from authorized systems and help to mitigate the risk of an attacker or insider threat obtaining unrestricted access to the keys. Protecting other PKI assets and auditing their use helps to ensure that keys are not used in an unauthorized manner after they have been created in the HSM.

For a complete list of the recommendations for protecting CA keys and critical artifacts, along with the level of business impact at which you should consider implementing them, refer to Securing PKI: Appendix F: List of Recommendations by Impact Level.