Key Management Lifecycles compliant to PCI DSS

This article highlights the NIST key lifecycle recommendations in relation to PCI DSS compliance.

Key management plays a vital role in underscoring the security mechanisms of cryptographic protocols/applications. With the evolution and increase in deployment of cryptographic mechanisms implemented in information systems, key management consistently emerges as the main challenge.

An interesting aspect of key management in enterprise deployments is the key lifecycle, which encompasses generation of keys, protection against accidental and intentional exposure by restraining physical/logical access, and the practice of authentication, revocation and deletion.

1. PCI DSS Requirements for Key Management

PCI SSC (Payment Card Industry Security Standards Council) is a governing body established in 2006 which holds the mandate of managing the development and alignment of a company’s policies to PCI DSS. Entities that store, process and transmit payment card information must comply with PCI DSS. The latest version (3.2) of PCI DSS was released in April 2016.

PCI DSS stipulates 12 requirements for compliance that include further sub-requirements. The PCI DSS requirements which relate to key management are:

Requirement 2.3: Encrypt all non-console administrative access using strong cryptography.

Requirement 3.5.1: Maintain a documented description of the cryptographic architecture that includes details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength, expiry date and description of the function for each key.

Requirement 3.6 (and subsections): Fully document and implement all key management processes and procedures for cryptographic keys used for encryption of cardholder data.

To achieve compliance, PCI DSS recommends the NIST SP 800-52 “Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations”, and SP 800-57 “Recommendation for Key Management” and OWASP industry standards / best practices for achieving “strong cryptography”.

2. NIST Key Lifecycle Management Recommendations for PCI DSS Compliance

The encryption key lifecycle, defined by NIST, has the following phases.

2.1. Pre-operational

In pre-operational phase, the key is not yet generated/created for standard cryptographic operations. It includes the following six functions.

1. User Registration involves secure communication to an RA (Registration Authority) to create an affiliation with a security domain and generation of a secret parameter e.g. a HMAC key, PIN or password.
2. System Initialization incorporates the identification of trusted entities and the selection of algorithms.
3. User Initialization includes initializing the software/hardware component/module for cryptographic operations by the initial keying material that was obtained through user registration phase.
4. Keying Material Installation deals with the requirements of the FIPS 140 standard for the security of the keying material during the initialization process of user’s hardware/software component of a cryptographic module.
5. Key Establishment requires the keying material to be generated and distributed for communication between entities. It’s recommended that keys are generated inside a FIPS 140-validated cryptographic device/module.
6. Key Registration involves the binding of keying material to data/information related to a specific user/object. This cryptographic binding generates a strong correlation between the entity and the keying material.

2.2. Operational

After the generation of keys, key management facilitates the operational availability of keying material for standard cryptographic purposes. It includes the following four functions.

1. Normal Operational Storage is where a cryptographic module is responsible for storing the keying material, which can perform additional, check, or remove cryptographic protection of information.
2. Continuity of Operations ensures the steadiness of processes, it is often essential for users/administrators to be able to recuperate the keying materials from secure backup storage to cater for the possibility of keying material becoming misplaced or unusable.
3. Key Change deals with the process of replacing a key with another key that can carry out the same operations as the original key in case of key compromise, expiration of the crypto period of the key or if the system has set a limit on the permitted volume of data encrypted by a key.
4. Key Derivation is a function that creates one or more secret keys from a secret parameter such as a master key or a passphrase. It uses a key-derivation algorithm (one-way or irreversible) that generates the desired keys with the aim that the secret parameter cannot be recovered from the derived keys. Three commonly used derivation mechanisms are secret parameters, key-derivation key and user-generated password..

2.3. Post-operational

The keying material is no longer in normal use, but access to the material is possible. It includes the following five functions.

1. Archive Storage & Key Recovery illustrates the key archival and recovery security mechanisms.
2. Entity De-registration eliminates the permissions of an object/entity to take part in a security domain. The intent of de-registration is to make sure that the keying material to be de-registered is no longer trusted to participate in further communications.
3. Key De-registration stops the use of keying material in case the data/info associated to an object is altered.
4. Key Destruction deals with destruction of keys in a secure way that eliminates all traces of the keying material, making sure it can’t be recuperated by electronic/physical procedures.
5. Key Revocation is achieved by issuing a security warning to blacklist the keying material. For example, key revocation in PKI is accomplished by adding the certificate serial number in the Certificate Revocation List (CRL), which is a cryptographic list of revoked certificates. An alternative online mechanism is the Online Certificate Status Protocol (OCSP).

2.4. Obsolete/Destroyed

The key(s) has been deleted. All archives of its existence also have to be deleted. Key metadata elements are sometimes retained for review/inspection. But it can be a security risk to store the metadata of keys (compromised or deleted) that someone can track which keys transitioned through a normal life-cycle and which ones were compromised at some time during their life-cycle.

3. Conclusion

This article has highlighted the requirements of the PCI DSS standard which are required for key management. A key management lifecycle according to the NIST standards is also explained in detail which can ensure the proper generation & protection keys, the practice of authentication, revocation, and erasure, eventually protecting the whole key lifecycle management in compliance to PCI DSS. Putting these functionalities and features all together, requires a banking grade crypto key management system.

References and Further Reading

• Selected articles on Key Management (2012-16), by Ashiq JA, Chuck Easttom, Dawn M. Turner, Guillaume Forget, James H. Reinholm, Matt Landrock, Peter Landrock, Steve Marshall, Torben Pedersen, Maria Stokes, John Trankenschuh and more 
• Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementation, SP 800-52 Revision 1 (2014), Tim Polk Kerry McKay Computer Security Division Information Technology Laboratory , NIST
• NIST Special Publication 800-57 Part 1 Revision 4 Recommendation for Key Management Part 1: General (2016), by Elaine Barker, Computer Security Division Information Technology Laboratory, National Institute of Standards and Technology
• “Cybersecurity Incidents What Happened.” (2016), the United States Office of Personnel Management.

Image: "Information Security Wordle: PCI DSS v1.2 (try #2)", courtesy of Purple Slog, (CC BY 2.0)