What does key management has to do with PCI-DSS

Many security folks I've spoken with do not realize that Key Management plays a vital role in determining the security mechanisms of cryptographic protocols/applications. As cryptographic mechanisms evolve and change over the years, key management remains one of the main challenges for any organization.

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

PCI DSS stipulates 12 requirements for compliance that include further sub-requirements.

The PCI DSS requirements which pertain particularly to key management are:

(1) PCI Requirement 2.3 calls out the need to encrypt all non-console administrative access using strong cryptography.

(2) PCI Requirement 3.5.1 states to maintain a documented description of your cryptographic architecture including any cryptographic algorithms security protocols and keys, including the keys specific to the usage expiration date and strength

(3) Requirement 3.6 (and subsections) says to fully document and implement all key management processes and procedures for cryptographic keys used for encryption of cardholder data. This means to build your organization’s key management program because, according to the PCI DSS, “The manner in which cryptographic keys are managed is a critical part of the continued security of the encryption solution."

These PCI-DSS recommended guides “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” are useful when an organization needs to meet their PCI-DSS compliance.

The encryption key lifecycle, defined by NIST ( reference from NIST Special Publication 800-57 Part 1 Revision), has the following phases.

The four phases of key management are:

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 (see Section 7.3).

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 (see Section 8.3.1).

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 (see Section 8.4).

I have highlighted the requirements of the PCI DSS standard which define the importance of key management. As per NIST to ensure the proper generation & protection of keys, the practice of authentication, revocation, and erasure, eventually ensure PCI-DSS compliance to Key Management. Putting these functionalities and features altogether requires a robust and enterprise-grade Key Management platform used by top financial institutions and large enterprises.

My team runs data protection workshop for customers who would like to know more about Data Protection, do feel free to drop me an email ([email protected]) if you would like to run one for your organization and we will be happy to lead that conversation with your team.