​Developing Key Management Systems

Based on a publication written by the Cloud Key Management Working Group

Key management is the management of cryptographic keys in a cryptosystem. A reliable key management system (KMS) helps a business meet compliance and data control requirements, and also benefits the overall security of the organization. In this post, we’ll be covering some of the important questions to keep in mind when developing key management systems for your organization, policies to follow regarding the control environment, and controls to enact that are relevant to the different phases of the key management lifecycle. This blog highlights major takeaways from the research document Key Management in Cloud Services.

Questions to Answer First

As with most modern computing technologies that intersect with cloud computing, there are many possible architectural combinations of solutions to cloud computing and key management. The primary questions that affect how organizations approach the architectural choice include:

1. What key management systems are already in use by the organization? CSA recommends that organizations — regardless of any cloud adoption planned, underway, or established — document the capabilities of existing KMS in terms that can be evaluated for potential use in achieving business, privacy, and security outcomes. This establishes the foundation for evaluating a cloud KMS in the future.
2. What are the desired functional, operational, and business outcomes for use of the cloud service? This question may elicit a long list of desired outcomes, with considerations of cost, complexity, stability, service level agreement, privacy, transparency, and more.

Key Management Control Environment

The next important factor to consider is the control environment — the setting which facilitates the operation of controls and the controls themselves. The control environment consists of all the policies and procedures supported by management as well as their actions regarding deviations from policy. Here is an overview of some of the policies that are necessary to ensure a proper control environment:

Governance and Policy Management:

• Each encryption key or group of keys needs to be governed by an individual key usage policy.

• Encryption and key management policies and procedures should be reviewed annually.

Risk Management:

• An encryption and key management risk program should include provisions for risk assessment, risk treatment, risk context, and monitoring and feedback.

Change Management:

• Changes to encryption and key management systems, policies, and procedures should be made in accordance with a procedure that includes determining the effects, costs, and benefits of the change.
• Changes should be communicated to all relevant stakeholders.
• Changes should all be recorded with the possibility of the change being reversed to the original state.

Key Management System:

• An encryption and key management storage system should require keys and/or certificates to be automatically recorded.
• Key security functions should be isolated from non-security functions via partitions or domains.

Centralized Logging:

• A secure audit trail of unalterable logging information evidencing key transactions, administration activities, and security events should be maintained.

Audit:

• Encryption and key management systems, policies, and processes should be independently audited annually.

Key Management Controls

The phases of the key management lifecycle govern the creation, usage, storage, and destruction of keys. Here are some of the controls associated with different phases:

Generation:

• All keys should be generated within a secure cryptographic module which relies upon a random bit generator.

Activation:

• Symmetric or private keys should be activated only when they are required to be used.
• Public keys should be activated when they are made available or on the date indicated in associated metadata.

Deactivation:

• Symmetric or private keys should be deactivated when they are no longer required for applying cryptographic protection to data. Then, these keys may be destroyed or archived.

Compromise:

• Generally, keys are compromised when they are released to or determined by an unauthorized entity. Cryptographic protection applied to information of compromised keys must cease and the compromised key must be revoked.

Replacement:

• Sometimes, keys need to be replaced due to a compromise of the key or the end of the key’s crypto-period. The new key should be generated in a manner that is entirely independent of the value of the old key.

Recovery:

• Key recovery is the act of bringing crypto keys back up or archived keys back to their original state. It is important to closely replicate associated key attributes to their original state to preserve the assigned usage attributes. Key information may be recovered from backups during the key’s valid crypto-period or from archives.

Destruction:

• Once it has been carefully determined that they are no longer required, keys should be destroyed in a manner that removes all traces of the keying material.
• Once the key has been marked for deletion, there is no facility to undo this state. It is imperative to provide the user with sufficient warning prior to destruction.

Interested in a more in-depth look at this topic?

This blog highlights some of the major points from the research document Key Management in Cloud Services by the Cloud Key Management Working Group.

In the full version of this research document you will read a more detailed explanation of some of the topics brought up in this blog as well as information about:

• Programmatic Library Interfaces, including REST and SOAP recommendations.
• API Practical Considerations, including what these relationships look like in practice, the interface triangle, and practical API management.

Acknowledgments