Background

The management and security of cryptographic keys is essential for keeping CMS’s information systems safe and secure. Cryptographic keys help protect sensitive information by ensuring it remains confidential, integrity intact, and available when needed. This guide is designed to help CMS follow best practices for key management, making sure our systems are well-protected and meet important security standards.

This guide is based on recommendations from several important resources, including the National Institute of Standards and Technology (NIST) Special Publication 800-57, which provides guidelines for managing cryptographic keys, the CMS IS2P2, and the CMS Acceptable Risk Safeguards (ARS). These policies work together to ensure that all CMS systems handle cryptographic keys safely and effectively.

Additionally, federal law requires us to regularly check and improve our security controls. Under the Federal Information Security Management Act (FISMA), agencies like CMS must regularly assess their security measures to stay ahead of potential risks. According to the CMS ARS, CMS information systems must review and update their risk assessments at least every three years, or sooner if there’s a major change in the system. These assessments include documenting our security policies, assigning roles and responsibilities, and outlining how we manage and protect sensitive data across the organization.

Policy

Policy outlines how CMS manages the security of its information and systems. It clearly assigns security responsibilities and provides a framework to measure progress and ensure compliance. This policy applies to all CMS employees, contractors, and anyone with access to CMS IT systems to assure the confidentiality, integrity, and availability of of CMS information and information systems.

Information Systems Security and Privacy Policy (IS2P2)

The CMS IS2P2[1] defines the main framework and policy that CMS uses to protect its information and information systems in compliance with the, federal law, and regulations. This policy requires all CMS stakeholders to implement adequate information security and privacy safeguards to protect all CMS sensitive information. 

The policies outlined in the CMS IS2P2 support meeting the requirements for controls that mandate CMS to establish a policy and related procedures for managing 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[2] 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. Every part of this environment is required to meet certain security and privacy standards to ensure that data is protected, whether it's stored, being used, or transmitted across the network. 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 

Secrets are sensitive pieces of information, such as passwords, encryption keys, or tokens, that provide access to systems or application. 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, tampering, deletion and disclosure. Secrets include but not limited to the following:

• 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
• Private certificates (e.g. Transport Layer Security (TLS), Secure Sockets Layer (SSL))[3]
• RSA and other one-time password devices
• Account tags
• Any other application tokens that are deemed confidential.

These secrets are essential for securely accessing applications, services, privileged accounts, and other critical parts of an organization's IT systems.. Since passwords and encryption keys are some of the most widely used and important tools for verifying users and systems, it is crucial to manage them securely. Secrets management ensures that these sensitive credentials are protected, both when they are stored (at rest) and when they are being transmitted. Proper management helps reduce the risks of unauthorized access or breaches by implementing strong protections for secrets at all times.

Note:

• Protect Root Access Keys: Root access keys should be protected above all else. CMS recommends that root access keys not be used at all or, if necessary, be disabled and protected with Multi-Factor Authentication (MFA).
• Transmission of Secrets: Whenever secrets are sent or shared, it must be done securely, using encrypted methods that comply with Federal Information Processing Standards (FIPS) 140-3[4].
• Regular Rotation: Shared secrets, such as encryption keys and single-factor or shared passwords, should be periodically rotated to minimize the risk of unauthorized access.

Key Management

Key management refers to the secure handling of cryptographic keys within a cryptosystem. Managing keys includes generating, distributing, exchanging, storing, using and replacing keys as needed at the user level and then deletion or destruction when they are no longer needed.

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, digital video disks, external/removable hard disk drives) and mobile devices with storage capability (e.g., smart phones, tablets, E-readers).

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 FIPS140-3[5] 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[1] 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[2], and usage period) may be retained.

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 [3].

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

1. 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; and
• The destruction of private or secret keys that are no longer required.

        “Key management” will be used throughout this document to refer to this collection of functions.

Cryptographic Key Management Systems (CKMS)

A cryptographic key management system (CKMS) is the framework and services that provide for key management.

The CKMS includes all hardware, software, equipment, and documentation needed to form the system that perform key management. A CKMS will further encompass the facilities where cryptographic activities are performed and the personnel performing the activities.  

NIST SP 800-152[4] 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.,  key management tools provided by an agency for all FISMA systems to use or a large complex of organizations (e.g., in secure communications for the U.S. Government).

A CKMS my 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 must document proper use of the system. 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.

A CKMS Security Policy (CKMS SP) is the 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. 

A CKMS Practice Statement (CKMS PS) documents how key management procedures and techniques are used to enforce the CKMS Security Policy.

The development of new cryptographic systems, including CKMS, should preferably follow the processes outlined in NIST SP 800-160, Developing Cyber-Resilient Systems: A Systems Security Engineering Approach. In general, teams at CMS should not be designing cryptographic systems themselves and should instead use established products. When these systems are augmented or modified, security and privacy planning remain essential, although the NIST SP 800-160 processes may need to be streamlined or adapted to address legacy constraints. CMS organizations are required to select security and privacy controls from NIST SP 800-53, guided by the ARS 5.0 Control Catalog, while considering system design, operational characteristics, and FIPS 199 impact levels.

Key Management Planning

Application Development Organizations (ADOs) must identify and document how they plan to manage the key material for their system.  This will facilitate the proper use and maintenance of cryptographic systems.

Application Development Organizations (ADOs) should utilize software solutions, either on premises and in the cloud, that facilitate the creation, identification, management, retrieval, rotation, and removal of keys. Using a software solution will provide more reliable management of keys than performing the steps manually.

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.

ADOs must create the following documentation for the key management activities:

• Key Management Architecture: A diagram and summary of how the CKMS is incorporated into the overall system architecture.  ADOs should refer to NIST SP 800-57 Part 2 Revision 1[5] that provides examples of architectures.
• Key Management Specification: The selection of key management products and services needed from the CKMS needed to support the operation of the cryptographic product. 

• Key Management Plan: Documented procedures for the management of keys throughout the lifecycle.

  Key Strength

The security of the information protected by cryptography directly depends on the strength of the keys. CMS organizations should use the following best practices:

• Always use a cryptographic key with another key of equal or greater cryptographic strength when encrypting keys for storage or distribution
• 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.

1. Review NIST SP 800-57 Recommendation for Key Management for detailed recommendations on key strength for specific algorithm implementations.  Table 1 also summarizes the information in SP 800-57-3.
2. Table 1

Recent Office of Management and Budget (OMB) Memorandum M-23-02[6] has instructed Federal Agencies to prepare for increasing maturity in quantum computer which is poised to disrupt the contemporary cryptography environment by increasing how fast keys can be guessed (e.g. brute force attempts) and by making it trivial to factor large prime numbers.  Over the next decade agencies will need to begin using “post-quantum cryptography” algorithms as approved by NIST. This document will be updated when there are formal requirements for ADOs here at CMS.

CMS and other federal agencies must take proactive steps to assess their cryptographic dependencies and prepare for the transition to quantum-resistant encryption. In preparation:

• Inventory cryptographic dependencies to identify systems vulnerable to quantum attacks.
• Evaluate NIST-approved post-quantum cryptography algorithms for potential early adoption.
• Establish a migration roadmap that aligns with federal guidance on quantum-safe encryption.

These foundational steps will help ensure a smooth transition as formal requirements and implementation timelines are established. The following sections provide further details on CMS’s approach to mitigating quantum-related risks and securing critical systems.

Public Key Infrastructure at CMS

Public key infrastructure (PKI) is an asymmetric cryptographic algorithm that uses two different keys to perform encryption, decryption, and digital signatures.  It is most commonly used for encrypting network traffic, particularly for websites. All federal websites must encrypt their network connections using Transport Layer Security v1.2 or higher as advised in NIST SP-800-52 rev 2. OMB M-22-09[7] requires that federal websites use HSTS and submit for preloading via DotGov.

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[8] is responsible for issuing a public key certificate for each identity, confirming that the identity has the appropriate credentials.

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:

1. Submits a request through the CMSConnect Portal.
   • Navigate to “IT Services” and search for “SSL” to find the available forms to submit.
2. Email the CMS - DOMSSLCert mailbox at DOMSSLCert@cms.hhs.gov to submit a request.
   • Include the brand of certificate and the type of certificate in your email.

For inquiries on the type of certificate to request, contact the CMS - DOMSSLCert mailbox at DOMSSLCert@cms.hhs.gov for assistance.  They have a document that explains the different companies offering certificates and which certificates to choose.  After you have requested the certificate there may be additional steps to finish applying for one.

Note: only those with a CMS User ID can submit a request through CMSConnect; others should email.

Key Usage

Per NIST SP 800-57 Part 1 Revision 5: Recommendation for Key Management, a single key should be used for only one function  (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.
• Retention requirements of the data may differ for different data types, and data needing longer retention may need a longer key.

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[9], 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-3 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-3 compliance that generates the key. 

Note: All cryptographic modules used within CMS must transition to FIPS 140-3-compliant modules by September 22, 2026, as FIPS 140-2 certifications will no longer be valid for new deployments after this date.

Hardware cryptographic modules are preferred over software cryptographic modules for protection[10].

Distribution

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

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. 

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[12])
• Using a third-party, CMS approved storage service.

1. 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

Cryptographic keys must be securely stored.  The location of stored keys should be documented in a Key Management Plan, which should be updated as needed, but no less than annually. While in storage, the choice of protection mechanisms may vary. 

ADOs should consider the following when storing keys: 

• Encrypt keys and store separately using a KMS solution or service.
• Understand where cryptographic keys are stored within the application as well as the memory devices the keys are stored on.
• Protect keys on both volatile and persistent memory; ideally, process them within secure cryptographic modules.
• Never store keys in plaintext format.
• Ensure all keys are stored in a cryptographic vault, such as a hardware security module (HSM), isolated cryptographic service or secret management services.
• Encrypt keys you plan to store in offline devices/databases using Key Encryption Keys (KEKs) prior to the export of the key material, and ensure that KEK length (and algorithm) is 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.

• Perform all work in a cryptographic vault (such as key access, encryption, decryption, signing, etc.)

  Use

The keys are used to encrypt and decrypt data both in transit and at rest. To perform these operations, keys must be accessed from storage and utilized. Keys should be handled with care while in use and must not be inadvertently saved to disk. Memory should be securely cleared after use. The specific mechanism for handling keys will depend on the implementation and intended purpose.

Backup and Escrow

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-3 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. Escrowing key material refers to securely storing a copy of cryptographic keys with a trusted third party or in a secure system designed for that purpose.

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 clearly identifying and documenting individuals or systems that have access to or control over cryptographic keys throughout their entire lifecycle. This includes maintaining detailed records of who accessed the keys, when, and for what purpose, as well as implementing mechanisms to track and monitor key usage. Accountability serves as a critical mechanism not only for preventing key compromises by ensuring proper oversight and control but also for enabling prompt detection, investigation, and mitigation of incidents when compromises occur. This level of transparency and control strengthens the overall security of cryptographic key management.

Key management systems should log who accessed the keys, when the keys are accessed, what the keys protect (including if they protect other keys), and what the keys are used for.

Holding individuals accountable for their actions with cryptographic keys provides three significant advantages:

• It aids in the determination of when the compromise could have occurred and what individuals could have been involved.
• It discourages improper use, because individuals with access to the key know that their access to the key is known.
• It is 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.

Three types of audit should be performed on key management systems:

• Review the security/privacy plan and the supporting procedures to ensure that they continue to support the Key Management Policy in NIST SP 800-57[13].
• Periodically assess the protective mechanisms employed with respect to the level of security that they provide and are expected to provide in the future.  Do the mechanisms correctly and effectively support the appropriate policies?
• Review who has permission to access keys and evaluate if that access is still necessary.

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 to track who used keys or secrets, when and for what purpose, etc.  Audit trails should be regularly monitored and have alerts/notification built in to warn when there may be inappropriate use. Logging requirements should record the following details at a minimum:

• Who accessed or modified a key
• What operations were performed (e.g., encryption, decryption, rotation).
• When the access or operation occurred.

• Where the access originated

  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[14].

For symmetric encryption, which uses the same key for both encryption and decryption, CMS organizations should configure automation key rotation by setting a key rotation period and starting time when the key is created.

Note: The new key will only be used with future encryption actions; the old key is still needed to decrypt the previous text

For asymmetric encryption, which involves a pair of keys (a public key for encryption and a private key for decryption), CMS organizations will need to manually rotate keys. This is because the new public key must be distributed to users before the new key pair can be used. 

Note: Allow sufficient time to obtain and distribute new keys before the old keys expire.

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[15].

If key owners, developers, or system maintainers suspect a key compromise, they should promptly rotate the affected keys and re-encrypt any data that was secured with the compromised keys. To re-encrypt data, download the existing data, decrypt it using the old key, encrypt it with the new key, and then re-upload the newly encrypted data.

CMS recommends Online Certificate Status Protocol[16] (OCSP) over Certificate Lifecycle Management[17] (CLM) because there can be latencies in the system where CLM may not have the most up to date revocations. OCSP provides real-time revocation status, reducing risks from stale certificate lists while CLM may introduce delays in propagation, increasing exposure to compromised keys. CMS will continue evaluating OCSP and emerging certificate management technologies for optimizing key lifecycle security.

Key Revocation

According to NIST SP 800-57 Part 2 Recommendation for Key Management: Part 2 – Best Practices for Key Management Organizations[18], 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. This makes it critical for ADO’s to have a means of revoking keys used within their systems.

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 a key fail, rendering it untrustworthy for providing the required security. Anyone who suspects a key has been compromised—whether they are the key owner or an observer—must report it immediately. ADOs must establish a formal process for reporting possible key compromises.

In the event of a key compromise, the following steps must be taken:

• Users must promptly report suspected key compromises to the CMS Security Operations Center (SOC).
• Security administrators must immediately revoke the compromised key and update its status in the CMS Cryptographic Key Management System (CKMS).
• Identify affected systems, data, and dependencies to assess the scope of the compromise. Impact Analysis: Identify affected systems, data, and dependencies.
• Generate a replacement key and re-encrypt all affected data to restore security.
• Conduct a post-incident forensic analysis to determine the root cause and implement measures to prevent recurrence.

When a key is compromised, all use of the key should cease, and the compromised key should be revoked. 

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, either directly in the Key Management Plan or in a location the KMP can reference. The CMS KPM Template contains an example compromise-recovery plan. (should we add the template as an exhibit at the bottom of this plan or reference a link? The template will have all the NIST SP 800-57 Part 1 Rev. 5 regulations for compromise recovery)

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[19] 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.
• 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)[20] 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.

• SSMS (Secret Sharing Made Short)[21] is another standard protocol that is encouraged for key management within Cloud application.

  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[22].

Access to the key archive must be strictly limited to authorized personnel or entities to prevent unauthorized use or compromise.

If a key must be recoverable (e.g., after the end of its cryptoperiod[23]), 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. To ensure security and integrity, the archive should be maintained by a trusted entity, such as the CMS organization responsible for the key or a trusted third party.

When recovering archived keys, the following steps must be followed to ensure secure retrieval and compliance with security policies:

1. Verify Authorization: Confirm that the key retrieval request is properly authorized and documented.
2. Retrieve Key Metadata: Gather relevant information, including the key’s cryptoperiod, owner, and access logs.
3. Secure Key Restoration: Use approved cryptographic mechanisms (e.g., key wrapping) to securely restore the key.
4. Enforce Usage Restrictions: Ensure that recovered keys are used strictly for their designated functions and are not reintroduced for new encryption operations.
5. Document and Notify: Log all recovery actions and notify security officials to maintain auditability and oversight.

By adhering to this structured recovery process, CMS organizations can ensure the security and integrity of archived cryptographic keys while mitigating risks associated with unauthorized access or misuse.

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[24]. 

To protect trust stores from unauthorized modifications and compromises, CMS organizations should implement the following security controls:

• Design controls to secure the trust store against injection of third-party root certificates. Access controls should be strictly managed and enforced on an entity and application basis.
• Implement mechanisms to verify the integrity of objects stored within the trust store, ensuring they have not been altered or tampered with. This includes automatic integrity checks to detect unauthorized certificate modifications. Do not allow for export of keys held within the trust store without authentication and authorization.
• Ensure that trusted root certificates are validated against the Federal Public Key Infrastructure (PKI) Trust Framework to maintain compliance and prevent reliance on unapproved certificate authorities.
• Prohibit the export of private keys without proper authentication and authorization. Implement role-based access controls (RBAC) to ensure that only authorized personnel can perform key export operations.
• Define and enforce strict policies and procedures for securely exporting key material from applications to network services and other system components. Prohibit the export of private keys without proper authentication and authorization.
• Implement a controlled and secure process for updating the trust store to ensure that only authorized changes are applied. Enforce multi-factor authentication (MFA) for any administrative modifications to the trust store.

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

Conclusion

In conclusion, this Key Management Program Guide provides a comprehensive framework for the secure management of cryptographic keys throughout their lifecycle. By adhering to the principles, standards, and best practices outlined in this guide, CMS ensures the confidentiality, integrity, and availability of sensitive information across its systems. Leveraging NIST recommendations and federal requirements, the guide equips stakeholders with the tools and methodologies necessary to navigate evolving security challenges. By implementing robust key management policies and practices, CMS strengthens its commitment to safeguarding data, maintaining compliance, and supporting the organization’s broader mission of providing secure and efficient services.

[1] NIST SP 800-57 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf

[2] 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.

[3] NIST SP 800-175 B https://csrc.nist.gov/publications/detail/sp/800-175b/rev-1/final

[4] NIST SP 800-152 https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-152.pdf

[5] NIST SP 800-57 Part 2 Revision 1 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt2r1.pdf

[6] OMB M-23-02: https://www.whitehouse.gov/wp-content/uploads/2022/11/M-23-02-M-Memo-on-Migrating-to-Post-Quantum-Cryptography.pdf

[7] OMB M-22-09: https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf

[8] A certification authority (CA) is similar to a notary. The CA confirms the identities of parties sending and receiving electronic payments or other communications. Authentication is a necessary element of many formal communications between parties, including payment transactions.

[9] FIPS 186-5: https://csrc.nist.gov/pubs/fips/186-4/final

[10]https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final

[11]https://csrc.nist.gov/publications/detail/sp/800-133/rev-2/final

[12]https://intranet.hhs.gov/sites/default/files/s3fs-public/s3fs-public/policies-guides-encryption.pdf

[13] NIST SP 800-57 Part 2 https://csrc.nist.gov/publications/detail/sp/800-57-part-2/rev-1/final

[14] 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.

[15] See Section 5.3 in 800-57 Part 1. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf

[16] The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate.

[17] Certificate Lifecycle Management (CLM) solutions mitigate that risk by eliminating the potential for human error.

[18]https://csrc.nist.gov/publications/detail/sp/800-57-part-2/rev-1/final

[19] See SP 800-175B, SP 800-56A, and SP 800-56B

[20] 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.

[21] 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.

[22] See SP 800-57, Part 2

[23] 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.

[24]https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt2r1.pdf

[25]https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf

END NOTES

[1] https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2

[2]https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/Policies.html

[3] NIST Special Publication 800-133 Revision 2; https://csrc.nist.gov/pubs/sp/800/133/r2/final

[4] FIPS 140-3 https://csrc.nist.gov/pubs/fips/140-3/final

[5] FIPS 140-3 https://csrc.nist.gov/pubs/fips/140-3/final