Background

This handbook aligns with the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-57 series, the CMS IS2P2, and the CMS Acceptable Risk Safeguards (ARS).

FISMA further emphasizes the importance of continuously monitoring information system security by requiring agencies to conduct assessments of security controls at a risk-defined frequency. The CMS ARS states that CMS information systems must define, develop, disseminate, review, and update its Risk Assessment documentation at least once every three years or whenever a significant change has occurred. This includes a formal, documented system security/privacy package that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and formal, documented processes and procedures to facilitate the implementation of the policy and associated controls.

Policy

Policy delineates the security management structure, clearly assigns security responsibilities, and lays the foundation necessary to reliably measure progress, compliance, and direction to all CMS employees, contractors, and any individual who receives authorization to access CMS information technology (IT) systems or systems maintained on behalf of CMS to assure the confidentiality, integrity, and availability of CMS information and information systems.

Information Systems Security and Privacy Policy (IS2P2)

The CMS IS2P2 defines the framework and policy under which CMS protects and controls access to CMS information and information systems in compliance with the Department of Human and Health Services (HHS) policy, federal law, and regulations. This policy requires all CMS stakeholders to implement adequate information security and privacy safeguards to protect all CMS's sensitive information.

The policies contained within the CMS IS2P2 assist in satisfying the requirements for controls that require CMS to create a policy and associated procedures related to information systems.

The dynamic nature of information security and privacy disciplines and the constant need for assessing risk across the CMS environment can result in gaps in policy, outside of the routine policy review cycle. The CMS Policy Framework includes the option to issue a CIO Directive to address these types of gaps in CMS policy by providing guidance to CMS stakeholders while a policy is being developed, updated, cleared, and approved.

Chief Information Officer (CIO) Directives

The CMS Chief Information Officer (CIO), the CMS Chief Information Security Officer (CISO), and the CMS Senior Official for Privacy (SOP) jointly develop and maintain the CMS IS2P2. The CIO delegates authority and responsibility to specific organizations and officials within CMS to develop and administer defined aspects of the CMS Information Security and Privacy Program as appropriate.

Standards

Standards define both functional and assurance requirements within the CMS security and privacy environment. CMS policy is executed with the requirements prescribed in standards with the objective of enabling consistency across the CMS environment. The CMS environment includes users, networks, devices, all software, processes, information in storage or transit, applications, services, and systems that can be connected directly or indirectly to networks. These components are responsible for meeting and complying with the security and privacy baseline defined in policy and further prescribed in standards. The parameters and thresholds for policy implementation are built into the CMS standards, and provide a foundation for the procedural guidance provided by the Program Guide series.

Secrets Management

A secret is a digital authentication credential. Secrets are individually named sets of sensitive information, and address a broad spectrum of secure data. Secrets need to be protected against unauthorized disclosure, and all keys need to be protected against modification, tempering, deletion and disclosure. There are different types of secrets, including:

• User passwords
• Root passwords
• Application and database passwords
• Auto-generated encryption keys
• Private encryption keys
• Application Programming Interface (API) keys
• Application keys
• Secure Shell (SSH) keys
• IAM secret keys
• Programmatic access keys (project / client IDs)
• Authorization tokens
• Bearer tokens
• Certificates
• Private certificates (e.g. Transport Layer Security (TLS), Secure Sockets Layer (SSL))
• RSA and other one-time password devices
• Account tags
• Passphrases
• Any other application tokens that are deemed confidential

Secrets management refers to the tools and methods for managing digital authentication credentials (secrets), including passwords, keys, APIs, and tokens for use in applications, services, privileged accounts and other sensitive parts of the IT ecosystem.

Passwords and keys are some of the most broadly used and important tools your organization has for authenticating applications and users and providing them with access to sensitive systems, services, and information. Because secrets have to be transmitted securely, secrets management must account for and mitigate the risks to these secrets, both in transit and at rest.

Note – Root access keys should be protected at all costs and deleted if possible. A bad actor may shut down servers, delete data, create and destroy users, or any other API capability with the root user’s key. For this reason, CMS highly recommends that root access key should not be in use or should be disabled if already in use. CMS also recommends keeping the root user’s credentials safe and private. Do not share them with other employees or contractors. It is also advisable to activate Multi Factor Authentication (MFA) for the root account to protect it even if the password leaks. Also, access and secret access keys should only be developed at a user level, and never at a root level.

The security objectives (Confidentiality, Integrity and Availability) should always be protected in regards to secrets management. The Federal Information Processing Standards (FIPS) Publication 199 defines three levels of potential impact on organizations or individuals (low, moderate, high) should there be a breach of security (i.e., a loss of confidentiality, integrity, or availability) and has additional examples on the impact of loss of one or more of the security objectives.

Key Management

Key management refers to managing cryptographic keys within a cryptosystem. The term “cryptosystem” is shorthand for “cryptographic system” and refers to a computer system that employs cryptography, a method of protecting information and communications through the use of codes so that only those for whom the information is intended can read and process it.

Cryptosystems deal with generating, exchanging, storing, using and replacing keys as needed at the user level.

The security of the cryptosystem is dependent upon successful key management. Proper management ensures a key stays safe throughout its lifecycle, from generation and use to storing and deletion.

Cryptographic Keys

Cryptography is used to secure communications over networks, to protect information stored in databases, and for many other critical applications. Cryptographic keys play an important part in the operation of cryptography.

With effective cryptographic key management, data that is encrypted can still be protected even in the event of a breach, since encrypted data cannot be decrypted without the right keys. Proper usage of encryption and key management will assist an organization’s efforts to protect their data. NIST SP 800-57 Recommendations for Key Management (Part 1, Revision 5) provides an updated guideline for general cryptographic key management.

At CMS, mechanisms are employed to:

• Prohibit the use of encryption keys that are not recoverable by authorized personnel
• Require senior management approval to authorize recovery of keys by someone other than the key owner
• Comply with approved cryptography standards mentioned in transit and at rest, as defined in the HHS Standard for Encryption of Computing Devices and Information, and in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.

At CMS, cryptographic protection applies to both portable storage devices (e.g., USB memory sticks, CDs, digital video disks, external/removable hard disk drives) and mobile devices with storage capability (e.g., smart phones, tablets, E-readers). This applies to all digital assets like application software, Data Stores (Such as databases and file systems), Cloud Service, and Software As a Service.

When cryptographic mechanisms are needed, CMS information systems use encryption products that have been validated under the Cryptographic Module Validation Program to confirm compliance with Federal Information Processing Standards (FIPS) 140-2 in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.

Key Management Concepts

Key Management Phases

According to NIST SP 800-57 Recommendation for Key Management: Part 1 - General in Section 8, there are four phases of key management:

1. Pre-operational phase: The keying material is not yet available for normal cryptographic operations. Keys may not yet be generated or are in the pre-activation state. System or enterprise attributes are established during this phase as well.
2. Operational phase: The keying material is available and in normal use. Keys are in the active or suspended state. Keys in the active state may be designated as protect only, process only, or both protect and process; keys in the suspended state can be used for processing only.
3. Post-operational phase: The keying material is no longer in normal use, but access to the keying material is possible, and the keying material may be used for processing protected information. Keys are in the deactivated or compromised states. Keys in the post-operational phase may be in an archive.
4. Destroyed phase: Keys are no longer available. Records of their existence may or may not have been deleted. Keys are in the destroyed state. Although the keys themselves may have been destroyed, the key’s metadata (e.g., key name, type, cryptoperiod, and usage period) may be retained. A cryptoperiod is the time span during which a specific key is authorized for use by legitimate entities or the keys for a given system will remain in effect.

Key Establishment

Key establishment is the process that results in the sharing of a key between two or more entities. This process could be by a manual distribution, by using automated key-transport or key agreement mechanisms, or by key derivation using an already-shared key between or among those entities. Key establishment processes include the creation of a key. Key establishment techniques and issues are discussed in Section 5.3 of NIST SP 800-175B Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms.

Key Management Functions

Roles and responsibilities need to be defined for the CMS management of at least the following functions:

• The generation or acquisition of key information (i.e., keying material and the associated metadata)
• The secure distribution of private keys, secret keys and the associated metadata
• The establishment of cryptoperiods
• Key and/or certificate inventory management, including procedures for the routine supersession of keys and certificates at the end of a cryptoperiod or validity period
• Procedures for the emergency revocation of compromised keys and the establishment (e.g., distribution) of replacement keys and/or certificates
• Accounting for and the storage and recovery of the operational and backed-up copies of key information
• The storage and recovery of archived key information
• Procedures for checking the integrity of stored key information before using it 
• The destruction of private or secret keys that are no longer required

Cryptographic Key Management Systems (CKMS)

The term cryptographic key management system (CKMS) refers to the framework and services that provide for the generation, establishment, control, accounting, and destruction of cryptographic keys and associated management information.

It includes all elements (hardware, software, other equipment, and documentation); facilities; personnel; procedures; standards; and information products that form the system that establishes, manages, and supports cryptographic products and services for end entities.

A CKMS may handle symmetric keys, asymmetric keys or both. Key management policies, practice statements, and specifications should identify common CKMS elements and suggest functions of and relationships among the organizational elements responsible for the management and use of cryptographic keys.

NIST SP 800-152 contains requirements for the design, implementation, and procurement of a CKMS for the CMS organization. A key management system can be designed to provide services for a single individual (e.g., in a personal data-storage system), an organization (e.g., in a secure Virtual Private Network (VPN) for intraoffice communications), or a large complex of organizations (e.g., in secure communications for the U.S. Government).

Key Management Planning

According to NIST SP.800-57 Part 2 Revision 1, CMS organizations are required by statutory and administrative rules and guidelines to protect the confidentiality and integrity of their sensitive information and processes. Federal agencies are required to determine a FIPS 200 impact level (i.e., Low, Moderate or High) based on the security categories defined in FIPS 199. The security categories are based on the potential impact on an organization if certain events occur that jeopardize the information and information systems needed by the organization to accomplish its assigned mission, protect its assets, fulfill its legal responsibilities, maintain its day-to-day functions, and protect individuals.

CMS encourages Application Development Organizations (ADOs) to utilize software solutions (both on premises and in the Cloud) that help with the creation, identification, management, retrieval, rotation, and removal of keys - especially when these products help ADOs to better comply with CMS key management policy and its requirements.

CMS organizations also need to define their security objectives for storing and/or communicating their sensitive information. These objectives may include the following:

• Providing confidentiality for stored and/or transmitted data,
• Source authentication for received data,
• Integrity protection for stored/transmitted data,
• Entity authentication, etc.

The development of new cryptographic systems, including CKMS, should ideally be conducted following the processes described in NIST SP 800-160 Developing Cyber-Resilient Systems: A Systems Security Engineering Approach. However, in many cases, systems that rely on cryptographic protection are already being used. Where such systems are being augmented or otherwise modified, security/privacy planning is still required, but the NIST SP 800-160 processes will need to be abridged or otherwise adapted because of legacy constraints. CMS organizations must still select NIST SP 800-53, based on ARS 5.0 Control Catalog, security/privacy controls based on system design, operational characteristics, and FIPS 199 impact levels.

Key management planning should involve the following steps:

1. An appropriate key management architecture is selected based on the available cryptographic mechanisms and objectives. Section 2.3 of NIST SP 800-57 Part. 2 Revision 1 provides examples of architectures to be considered.
2. A Key Management Specification is developed for each cryptographic product to be used in the system. When developing a Key Management Specification for a cryptographic product, the unique key management products and services needed from the CKMS to support the operation of the cryptographic product must be defined. The specification of cryptographic mechanisms, including key management functions, should consider the CMS organization’s resource limitations and procedural environment. If a Key Management Plan already exists for a CMS organization, the Key Management Specification needs to be in conformance with the CKMS Security Policy. The CKMS Practice Statement should support both the CKMS Security Policy and the Key Management Specification.
3. Based on the Key Management Plan, a CKMS Security Policy (CKMS SP) is developed that documents the decisions made in developing the Key Management Plan. A CKMS SP is a set of rules that are established to describe the goals, responsibilities, and overall requirements for the management of cryptographic keying material throughout the entire key lifecycle.
4. A CKMS may be operated by the organization owning the information to be protected, or may be operated by another organization (e.g., under contract). The organization operating the CKMS develops a CKMS Practice Statement (CKMS PS). A CKMS PS specifies how key management procedures and techniques are used to enforce the CKMS SP.

Key Strength

CMS organizations should consider the following best practices:

• Establish what the application's minimum computational resistance to attack should be. Understanding the minimum computational resistance to attack should take into consideration the sophistication of your adversaries, how long data needs to be protected, where data is stored and if it is exposed. Identifying the computational resistance to attack will inform engineers as to the minimum length of the cryptographic key required to protect data over the life of that data. Consult NIST SP 800-131a Transitioning the Use of Cryptographic Algorithms and Key Lengths for additional guidance on determining the appropriate key lengths for the algorithm of choice.
• When encrypting keys for storage or distribution, always encrypt a cryptographic key with another key of equal or greater cryptographic strength.
• Choose a key length that meets or exceeds the comparative strength of other algorithms in use within your system. Refer to NIST SP 800-57 Table 2.
• Formulate a strategy for the overall organization's cryptographic strategy to guide developers working on different applications and ensure that each application's cryptographic capability meets minimum requirements and best practices.
• Review NIST SP 800-57 Recommendation for Key Management for recommended guidelines on key strength for specific algorithm implementations.

Public Key Infrastructure

Public key infrastructure (PKI), as stated in NIST Special Publication 800-32: Introduction to Public Key Technology and the Federal PKI Infrastructure, is the combination of software, encryption technologies, and services that enables enterprises to protect the security of their communications and business transactions on networks. PKI integrates digital certificates, public key cryptography, and certification authorities (CA) into a complete enterprise-wide network security architecture.

All public key certificates used at CMS are issued in accordance with Federal PKI policy and validated to the Federal PKI trust anchor when being used for user signing, encrypting purposes, authentication, and authorization.

The CA is responsible for issuing a public key certificate for each identity, confirming that the identity has the appropriate credentials. Note - certification authority (CA) is similar to a notary. The CA confirms the identities of parties sending and receiving electronic payments or other communications.

At CMS, various Certificate Authority requests are available and processed through the Infrastructure and User Services Group - Division of Operations Management (IUSG-DOM).

There are two ways to submit a CA request for a certificate:

• Requestor submits a request through the CMS Connect System.

Note: Only users with a CMS USER ID who have access to or VPN to the CMS Network will be able to login to the Agency Solution for Customer Support (ASCS). If you do not have a CMS USER ID, see option #2 below to submit an email request.

• Requestor sends certificate request email to the CMS - DOMSSLCert mailbox at DOMSSLCert@cms.hhs.gov

For inquiries on the type of certificate to request, contact the CMS - DOMSSLCert mailbox at DOMSSLCert@cms.hhs.gov for assistance.

Key Usage

Per NIST SP 800-57 Part 1 Revision 5: Recommendation for Key Management, a single key should be used for only one purpose (e.g., encryption, integrity authentication, key wrapping, random bit generation, or digital signatures).

There are several reasons for this:

• The use of the same key for two different cryptographic processes may weaken the security provided by one or both of the processes.
• Limiting the use of a key limits the damage that could be done if the key is compromised.
• Some uses of keys interfere with each other. For example, the length of time the key may be required for each use and purpose. Retention requirements of the data may differ for different data types.

This recommendation permits the use of a private key-transport or key-agreement key to generate a digital signature for the following special case: When requesting the (initial) certificate for a static key-establishment key that was generated as specified in FIPS 186-5, the corresponding private key may be used to sign the certificate request.

Key Management Lifecycle Best Practices

Generation

Cryptographic keys should be generated within cryptographic modules with at least a FIPS 140-2 compliance. For explanatory purposes, consider the cryptographic module in which a key is generated to be the key-generating module.

Any random value required by the key-generating module should be generated within that module; that is, the Random Bit Generator that generates the random value should be implemented within cryptographic modules with at least a FIPS 140-2 compliance that generates the key.

Hardware cryptographic modules are preferred over software cryptographic modules for protection.

Use/Distribution

The generated keys should be transported (when necessary) using secure channels and should be used by their associated cryptographic algorithm within at least a FIPS 140-2 compliant cryptographic module. For additional detail for the recommendations in this section refer to NIST Special Publication 800-133.

Keys or secrets should be shared out of band and should never be sent with or alongside the data the secrets or keys they are protecting. Also, secrets shared out-of-band should be protected and not stored somewhere that can be easily compromised (like on a piece of paper on a user’s desk). Out of band sharing of keys should be deleted or destroyed immediately after use.

ADOs should also consider using a Diffie-Hellman algorithm like Secure-Remote Procedure Call (S-RPC) for the sharing of keys when out of band sharing is not a viable option. Note - The Diffie–Hellman (DH) Algorithm is a key-exchange protocol that enables two parties communicating over public channel to establish a mutual secret without it being transmitted over the Internet. DH enables the two to use a public key to encrypt and decrypt their conversation or data using symmetric cryptography.

Examples of how keys can be shared included:

• Use a Key or Secrets Management System
• Use a shared key store or password manager vault
• Use of client-side encrypted pastebin or similar service
• Use of a restricted document
• Sending encrypted data via email (CMS adheres to the encryption requirements in the HHS Standard for Encryption of Computing Devices and Information)
• Using a third-party, CMS approved storage service

ADOs should document the method being used for the business or system owner. ADOs are also encouraged to use TLS Version 1.2 or 1.3 encryption standards for Data-in-transit.

Storage

• ADOs should document in a Key Management Plan where secrets are being stored, and that documentation should be made available to the business or system owner, and updated as needed but no less than annually. The documentation should be written per system, define types of secrets used, list all secret alias names, creation date, recommended rotation date, level of sensitivity/classification, recommended end of use, business owner, and secret manager. The secrets should be encrypted and stored separately using a KMS solution or service.
• CMS strongly encourages ADOs to use “split knowledge” or “M of N” for very sensitive key storage so that one individual does not have sole access to a key
• Developers must understand where cryptographic keys are stored within the application and understand what memory devices the keys are stored on.
• Keys must be protected on both volatile and persistent memory, ideally processed within secure cryptographic modules.
• Keys should never be stored in plaintext format.
• Ensure all keys are stored in a cryptographic vault, such as a hardware security module (HSM), or isolated cryptographic service or secret management services.
• If you are planning on storing keys in offline devices/databases, then encrypt the keys using Key Encryption Keys (KEKs) prior to the export of the key material. KEK length (and algorithm) should be equivalent to or greater in strength than the keys being protected.
• Ensure that keys have integrity protections applied while in storage (consider dual purpose algorithms that support encryption and Message Authentication Code (MAC)).
• Ensure that standard application-level code never reads or uses cryptographic keys in any way and use key management libraries.
• Ensure that keys and cryptographic operation is done inside a secure cryptographic vault.
• All work should be done in the cryptographic vault (such as key access, encryption, decryption, signing, etc.).

Escrow and Backup

Data that has been encrypted with lost cryptographic keys will never be recovered. Therefore, it is essential that the application incorporate a secure key backup capability, especially for applications that support data-at-rest encryption for long-term data stores.

When backing up keys, ensure that the database that is used to store the keys is encrypted using at least a FIPS 140-2 validated module. It is sometimes useful to escrow key material for use in investigations and for re-provisioning of key material to users in the event that the key is lost or corrupted.

Never escrow keys used for performing digital signatures, but consider the need to escrow keys that support encryption. Oftentimes, escrow can be performed by the Certificate Authority (CA) or key management system that provisions certificates and keys, however in some instances separate APIs must be implemented to allow the system to perform the escrow for the application.

Accountability and Audit

Accountability involves the identification of those that have access to, or control of, cryptographic keys throughout their lifecycles. Accountability can be an effective tool to help prevent key compromises and to reduce the impact of compromises once they are detected.

At a minimum, the key management system should account for all individuals who are able to view plaintext cryptographic keys.

In addition, more sophisticated key-management systems may account for all individuals authorized to access or control any cryptographic keys, whether in plaintext or ciphertext form.

Accountability provides three significant advantages:

• It aids in the determination of when the compromise could have occurred and what individuals could have been involved.
• It tends to protect against compromise, because individuals with access to the key know that their access to the key is known.
• It is very useful in recovering from a detected key compromise to know where the key was used and what data or other keys were protected by the compromised key.

Certain principles have been found to be useful in enforcing the accountability of cryptographic keys. These principles might not apply to all systems or all types of keys.

Some of the principles that apply to long-term keys controlled by humans include:

• Uniquely identifying keys.
• Identifying the key user.
• Identifying the dates and times of key use, along with the data that is protected.
• Identifying other keys that are protected by a symmetric or private key. Two types of audit should be performed on key management systems:
• The security/privacy plan and the procedures that are developed to support the plan should be periodically audited to ensure that they continue to support the Key Management Policy in NIST SP 800-57.
• The protective mechanisms employed should be periodically reassessed with respect to the level of security that they provide and are expected to provide in the future, and that the mechanisms correctly and effectively support the appropriate policies.

New technology developments and attacks should be taken into consideration. On a more frequent basis, the actions of the humans that use, operate, and maintain the system should be reviewed to verify that the humans continue to follow established security/privacy procedures.

Strong cryptographic systems can be compromised by lax and inappropriate human actions. Highly unusual events should be noted and reviewed as possible indicators of attempted attacks on the system.

Accountability and Audit ensures the security objectives (Confidentiality, Integrity and Availability) are maintained. Effective integrity can be maintained if ADOs incorporate logging and provide for audit trails so we can track who used keys or secrets, for what purpose, etc.

Integrity of the keys supports non-repudiation.

Key Rotation

Key rotation provides several benefits, which are not limited to:

• In the event that a key is compromised, regular rotation limits the number of actual messages/systems vulnerable to compromise. If key version is suspected to be compromised, disable it and revoke access to it as soon as possible.
• Regular key rotation ensures CMS systems are resilient to manual rotation, whether due to a security breach or the need to migrate application to a stronger cryptographic algorithm.
• Limiting the number of messages encrypted with the same key version helps prevent attacks enabled by cryptanalysis. Cryptanalysis is the study of ciphertext, ciphers and cryptosystems with the aim of understanding how they work and finding and improving techniques for defeating or weakening them.

For symmetric encryption, CMS organizations should configure automation key rotation by setting a key rotation period and starting time when key is created.

For asymmetric encryption, CMS organizations should always manually rotate keys, because the new public key must be distributed before the key pair can be used.

Recommended minimum frequency of key rotation – Annually.

Note - The rotation schedule can be based on either the key's age or the number or volume of messages encrypted with a key version. NIST SP 800-57 Recommendation for Key Management describes cryptoperiods as a factor in determining an appropriate period for rotation.

If responsible personnel have indications that keys have been compromised, they should manually rotate the keys and re-encrypt data that was encrypted by the compromised keys as soon as possible. To re-encrypt data, download the old data, decrypt it with the old key, encrypt the old data using the new key, and then re-upload the re-encrypted data.

CMS recommends Online Certificate Status Protocol (OCSP) over Certificate Lifecycle Management (CLM) because there can be latencies in the system where CLM may not have the most up to date revocations.

Key Revocation

According to NIST SP 800-57 Part 2 Recommendation for Key Management: Part 2 – Best Practices for Key Management Organizations, symmetric keys are often revoked by the use of Compromised Key Lists (CKLs). Certificate Revocation Lists (CRLs) are commonly used to revoke public key certificates, thus revoking the private key corresponding to the public key in the certificate. Regardless of whether symmetric or asymmetric keys are used, a means of revoking keys is recommended.

This CMS guide will use the term revoked key notification (RKN) to refer to a mechanism to revoke keys. An RKN may include the revocation reason and an indication of when the revocation was requested. The inclusion of the revocation reason can be useful in risk decisions regarding the information that was received or stored using those keys.

A key may also be suspended from use for a variety of reasons, such as an unknown status of the key or due to the key owner being temporarily unavailable (e.g., the key owner is on extended leave). In the case of a certificate suspension, the intent is to suspend the use of the public key included in the certificate (e.g., to not verify digital signatures or establish keys while the use of the certificate is suspended). This may be communicated to relying parties as an “on hold” revocation reason code in a CRL and in an OCSP response. The certificate may later be revoked (e.g., a compromise of the private key corresponding to the public key in the certificate was confirmed) or the certificate may be reactivated (e.g., the key has not been compromised or the owner returned to work).

Compromise of Keys

Key compromise occurs when the protective mechanisms for the key fail (e.g., the confidentiality, integrity, or association of the key to its owner fail;) and the key can no longer be trusted to provide the required security. It is the responsibility of an owner of a private or secret key to protect the confidentiality of that key. Reporting a possible key compromise is the responsibility of anyone suspecting that a key has been compromised (e.g., the key’s owner or an entity that observes that the data protected by that key has been compromised).

When a key is compromised, all use of the key to apply cryptographic protection to information (e.g., compute a digital signature or encrypt information) should cease, and the compromised key should be revoked.

Guidelines to Minimize the Likelihood of a Key Compromise

• Periodically rotate keys per the recommendation in this guide;
• Limiting the amount of time that a secret symmetric or asymmetric private key is in plaintext form;
• Preventing humans from viewing plaintext secret symmetric and asymmetric private keys;
• Restricting plaintext secret and private keys to physically protected “containers.” This includes key generators, key-transport devices, key loaders, cryptographic modules, hardware security modules (HSMs), and key-storage devices;
• Using integrity checks to ensure that the integrity of a key or its association with other data has not been compromised. For example, keys may be wrapped (i.e., encrypted and integrity protected) in such a manner that unauthorized modifications to the wrapped key or to the key’s metadata will be detected;
  • Providing a cryptographic integrity check on the key (e.g., using a MAC or a digital signature);
• Employing key confirmation to help ensure that the proper key was, in fact, established;
• Using trusted timestamps for signed data;
• Destroying keys as soon as they are no longer needed; and
• Creating a compromise-recovery plan, especially in the case of the compromise of a CA key.
• Data (key) dispersion - Data dispersion is recommended either through Redundant Array of Independent Disks (RAID) or use of erasure coding (bit splitting) in the Cloud. Data dispersion also addresses potential legal complications (for Cloud applications) that could arise should a server be confiscated by law enforcement. Note - RAID (redundant array of independent disks) is a way of storing the same data in different places on multiple hard disks or solid-state drives (SSDs) to protect data in the case of a drive failure.
• SSMS (Secret Sharing Made Short) is another standard protocol that is encouraged for key management within Cloud application. Note - SSMS uses a three-phase process: encryption of information; use of information dispersal algorithm (IDA), which is designed to efficiently split the data using erasure coding into fragments; and splitting the encryption key itself using the secret-sharing algorithm.

A compromise-recovery plan is essential for restoring cryptographic security services in the event of a key compromise. A compromise-recovery plan should be documented and easily accessible. The plan may be included in a Key-Management Practices Statement39. If not, the Key-Management Practices Statement should reference the compromise-recovery plan.

According to NIST SP 800-57 Part 1 Rev. 5, a compromise-recovery plan should contain:

• An identification of the personnel to notify and what the notification should contain (e.g., the scope of the compromise − whether specific keys were compromised or the certificate generation process was compromised);
• An identification of the personnel to perform the recovery actions;
• The method for obtaining a new key (i.e., re-keying);
• An inventory of all cryptographic keys (e.g., the location of all keys and certificates in a system);
• The education of all appropriate personnel on the compromise-recovery procedures;
• An identification of all personnel needed to support the compromise-recovery procedures;
• Policies requiring that key-revocation checking be performed (to minimize the effect of a compromise);
• The monitoring of the re-keying operations (to ensure that all required operations are performed for all affected keys); and
• Any other compromise-recovery procedures.

Other compromise-recovery procedures may include:

• A physical inspection of the equipment;
• An identification of all information that may be compromised as a result of the incident;
• An identification of all signatures that may be invalid due to the compromise of a signing key; and
• The distribution of new keying material, if required.

Key Archive and Key Recovery Functions

A key archive is a repository containing keys and their associated information (i.e., key information) for recovery beyond the cryptoperiod of the keys. Not all keys need to be archived. A CMS organization’s security/privacy plan should discuss key archiving.

Access to key archive should be limited to authorized personnel/entities.

If a key must be recoverable (e.g., after the end of its cryptoperiod), either the key should be archived, or the system should be designed to allow reconstruction (e.g., re-derivation) of the key from archived information. Retrieving the key from archive storage or by reconstruction is commonly known as key recovery. The archive should be maintained by a trusted party (e.g., the CMS organization associated with the key or a trusted third party).

Note - A cryptoperiod is the time span during which a specific key is authorized for use by legitimate entities or the keys or a given system will remain in effect.

NIST Special Publication 800-57 Part 1, Revision 5 Recommendation for Key Management: Part 1 – General further addresses the appropriateness of archiving keys and other cryptographically related information.

Trust Store

A trust store is a repository that contains cryptographic artifacts like certificates and private keys that are used for cryptographic protocols such as TLS. Because the compromise of a cryptographic key compromises all of the information and processes protected by that key, it is essential that client nodes be able to trust that keys and/or key components come from a trusted source, and that their confidentiality (if required) and integrity have been protected both in storage and in transit.