PCI DSS Compliant Key Management Lifecycles

Key management is critical to the operation of cryptographic protocols and application security mechanisms. With the increase in the development and distribution of cryptographic mechanisms implemented in information systems, key management is constantly emerging as the main challenge.

An exciting aspect of key management in enterprise deployments is the key lifecycle, which encompasses the generation of keys, protection against accidental and deliberate disclosure by restricting physical or logical access, and practices for authentication, revocation, and deletion.

You can find best practices in our article highlighting NIST key management lifecycle recommendations regarding PCI DSS compliance.

NIST Recommendations for PCI DSS Compliance: Key Lifecycle Management Recommendations

The stages of the encryption key lifetime as specified by NIST are as follows.

Before the operation

In the pre-operation phase, the key for standard cryptographic operations has not yet been generated. Pre-operation includes the following six functions:

• User Registration: It involves secure communication with an RA (Registration Authority) to establish a connection with a security domain, such as an HMAC key, PIN, or password.
• System Initialization: Includes identification of trusted entities and selection of algorithms.
• User Initialization: Involves initializing the software/hardware component or module for cryptographic operations with the initial keying material obtained during the user registration phase.
• Keying Material Setup: It addresses the FIPS 140 standards for the security of keying material used while initializing the user’s hardware or software component of an encryption module.
• Key Generation: Requires the creation and distribution of keying material for communication between entities. It is recommended that keys be generated within a FIPS 140 validated encryption device or module.
• Key Record: It involves linking the keying material to data related to a particular user or object. This cryptographic binding creates a strong correlation between the asset and the keying material.

Operational

After the keys are generated, key management facilitates the operational availability of keying material for standard encryption purposes. Operational includes the following four functions:

• Normal Operational Storage: This is where an encryption module is responsible for storing keying material that can control or remove in addition to cryptographic protection of information.
• Continuity of Operations: Provides stability of processes; often, users or administrators must retrieve keying materials from the secure backup repository to cover the possibility that the keying materials may be misplaced or rendered unusable.
• Key Replacement: If a key has been compromised, the key has expired, or the system has set a volume restriction, key replacement is the process of replacing it with another that can perform the same actions as the original key.
• Key Derivation: A function that generates one or more secret keys from a private argument such as a master key or password is known as key derivation. It employs a one-way or irreversible key derivation process to generate the desired keys, ensuring that the secret parameter cannot be recovered from the obtained keys. Secret parameters, key derivation keys, and user-generated passwords are three regularly used derivation procedures.

Post-operation

The switching material is no longer in everyday use, but access to the material is possible. It includes the following five functions after the operation:

• Archive Storage and Key Recovery: Shows key archiving and recovery security mechanisms.
• Entity Deregistration: When an item or entity is deregistered, the permissions to live in a security domain are deregistered as well. Deregistration assures that the deregistered keying material can no longer participate in future communications.
• Key Record Deletion: Stops the keying material from being used if the data or information associated with an object is changed.
• Key Disposal: It deals with the safe destruction of keys by removing all traces of the keying material, making sure electronic or physical procedures cannot recover them.
• Key Revocation: Blacklisting keying material is accomplished by issuing a security warning. For example, in PKI, key revocation is accomplished by adding the certificate serial number to the Certificate Revocation List (CRL), a cryptographic list of revoked certificates. An alternative online mechanism is the Online Certificate Status Protocol (OCSP).

Legacy/Destroyed

It is the process of deleting keys. All archives of its existence should also be deleted. Key metadata items are sometimes retained for review and auditing. However, storing metadata of keys can be a security risk, where one can monitor which keys have been compromised during a typical lifecycle and which have been compromised as compromised or deleted at any time during their lifecycle.

What Are the PCI DSS Cryptographic Key Management Requirements?

Payment Cards Industry Data Security Standard (PCI-DSS) compliance protects vulnerable customers unaware of the complex behind-the-scenes technologies. Financial institutions are responsible for complying with regulations mandating the protection of customers’ information.

See Also: What Are the PCI DSS Encryption Requirements

All of this security is based on cryptography, which makes credit card information and personal information unreadable in a security breach. Encryption keys that can unlock data are an essential part of any encryption process. These keys require tight protection, and internal controls must authorize their access.

PCI DSS stipulates 12 compliance requirements with additional sub-requirements. The PCI DSS requirements for key management are:

• PCI DSS Requirement 2.3: Encrypt all non-console management access using strong encryption.
• PCI DSS Requirement 3.5.1: There should be a documented description of the cryptographic architecture detailing all algorithms, protocols, and keys used to protect cardholder data, including key strength, expiration date, and a description of the function of each key.
• PCI DSS Requirement 3.6: All key management processes and procedures for cryptographic keys used to encrypt cardholder data should be fully documented and implemented.

Industry standards such as NIST SP 800-52 “Guidelines for the Selection, Configuration and Use of Transport Layer Security (TLS) Applications” and NIST SP 800-57 “Recommendation for Key Management” and OWASP to ensure PCI DSS compliance and achieve strong cryptography. You can use good practices.

The PCI DSS consists of 12 standards that serve as the foundation for enterprises to function securely and protect cardholder information. The three PCI DSS requirements that focus specifically on the generation, distribution, and access control of cardholder data are as follows:

PCI DSS Requirement 3.6.1 requires organizations to generate strong encryption keys. The PCI DSS standard does not address exactly how to achieve strong encryption, thus making it a daunting task.

A PCI QSA auditor will examine whether an organization’s tools to generate its key are generating a random number that is nearly impossible to predict.

See Also: Encryption Key Management Essentials

A pseudo-random number generator makes this possible. The Federal Office of Information Security prescribes four features for quality random numbers, and criteria 3 and 4 are the most preferred generators due to the complexity and limited possibility of an attacker guessing any previous number or any prior information in the sequence.

The risk for a business in this process is that they establish a routine compliance checklist and employ the incorrect tools to ensure compliance, only to realize their error when the auditor undertakes tests to validate these features.

PCI DSS Requirement 3.6.2 focuses on the secure distribution of cryptographic keys. As indicated in the access list, keys should be distributed to selected custodians, which should not be in large numbers.

PCI DSS requirement 9 requires the management of privileged access rights, and official documentation is reviewed to determine the proper management of elevated privileges. After the analysis is complete, an auditor will check the keys to be distributed to the correct administrators.

Abuse of privilege by privileged users has often weakened security mechanisms. Permanent registration of the key management system should be performed to ensure that only authorized users have access.

HSM devices ease many essential management issues and are highly recommended. However, organizations should thoroughly research HSM devices for clarity on topics such as the ability of devices to integrate with their existing systems.

See Also: HSMs for PCI DSS Compliance

An administrator needs to create a group for key principals and manage all principals entering and leaving that group for some HSM devices.

To meet PCI standard requirements and provide the highest level of data security, HSMs provide all the encryption functionality, user access, and in many cases, key management software required for PCI DSS compliance.

What Are PCI DSS Cryptographic Key Management Best Practices?

According to PCI DSS, several compliance standards and security best practices, sensitive data must be encrypted, and encryption keys must be protected with adequate key management.

Sensitive data must be encrypted according to security best practices and PCI DSS compliance rules. DEKs are physically or logically segregated from sensitive data and secured with strong key-encryption keys (KEK).

See Also: PCI DSS Key Rotation Requirements

Anyone who needs to protect sensitive data in a database should know that putting encryption keys in the exact location puts data in danger. Depending on what type of information is stored and what industry guidance your company falls under, compliance regulations may apply in addition to PCI DSS.

PCI DSS Requirement 3 addresses the need for encryption and key management and states the following:

• Protection methods such as encryption, hacking, masking, and hashing are critical components of protecting cardholder data. If an intruder bypasses other security checks and gains access to encrypted data without the appropriate cryptographic keys, the data becomes unreadable and unusable for that person.
• Other effective means of protecting stored data should also be considered as potential risk reduction opportunities. Methods for reducing risk include not retaining cardholder data unless essential, shortening cardholder data if the entire PAN is not required, and not sending unprotected PANs via end-user messaging technologies like email and instant messaging.

PCI focuses specifically on the PAN or Primary Account Number and encrypts personally identifiable information (PII) such as names, birthdates, email addresses, zip codes, usernames, or passwords and requires it to be appropriately protected with key management.

Other compliance requirements to protect information go beyond cardholder data because PCI focuses specifically on the PAN or Primary Account Number and encrypts personally identifiable information (PII) such as names, birthdates, email addresses, zip codes, usernames, or passwords.