Cryptographic Key
PCIComplianceHubLast updated
A value used with a cryptographic algorithm to transform data, most commonly to encrypt or decrypt it. Symmetric cryptography uses the same key for both operations; asymmetric cryptography uses a matched public and private pair. Under PCI DSS a key is not simply a value but a managed object: it has a defined cryptoperiod, a named custodian, storage restricted to the fewest possible locations, and a defined point of retirement or replacement. Keys that protect account data must themselves be protected, typically by a key encrypting key or a hardware security module.
Applies to. Requirements 3.6 and 3.7 apply to keys used to protect stored account data, including the keys behind keyed hashes under 3.5.1.1. 3.6.1 sets the protection rules: custodian access kept to the fewest people necessary, key-encrypting keys at least as strong as the keys they protect and stored separately from them, and storage in the fewest locations and forms, with 3.6.1.2 naming the three acceptable storage forms. 3.7.1 to 3.7.8 cover the lifecycle from generation and distribution through storage, cryptoperiod, retirement, manual handling, substitution and custodian acknowledgement, and 3.6.1.1 and 3.7.9 add duties for service providers.
Example. A service provider encrypts stored PAN with a data-encrypting key generated inside a hardware security module. The key never leaves the device in cleartext, two named custodians hold the administrative credentials, and the documented cryptoperiod triggers a scheduled change. When one custodian resigns, the provider retires the key under 3.7.5 and re-encrypts the affected data with a new one.
Limits. A key is not a password or a certificate, although 3.5.1.3 treats passwords, passphrases and cryptographic keys alike as authentication factors when they unlock disk-level encryption. Requirements 3.6 and 3.7 reach only keys that protect stored account data; keys and certificates used to protect PAN in transit fall under 4.2.1, and wireless encryption keys under 2.3.1 and 2.3.2. Knowing a key's algorithm and length says nothing about whether it is managed correctly, which is what the assessor tests.