PCI Requirement 3.5.3 requires organizations to, “Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) of the following forms at all times:
- Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key.
- Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point-of-interaction device)
- As at least two full-length key components or key shares, in accordance with an industry-accepted method.”
An assessor will examine your procedures, system configurations, and key storage locations to verify that your organization is protecting keys and complying with PCI Requirement 3.5.3.
PCI Requirement 3.5.3 works alongside PCI Requirements 3.5.1, 3.5.2, and 3.5.4 to protect keys. We don’t want to only protect your keys from unauthorized access; we want to take you a step further and prevent them from getting the information contained in the keys, even if they do happen to obtain them.
Wherever you’re storing these keys, we want to make sure that the encryption keys that are being stored are protected. So not only are we asking that these keys be protected from unauthorized access, we also want to make sure that individuals (attackers or people with malintent) are prevented from getting the information contained in these keys, should they ever get custody of them. We’re going to ask that from an assessment perspective, specific to PCI Requirement 3.5.3, that these keys be rendered unreadable. You’re going to be encrypting them, you might be storing them on an HSM, or if you use split knowledge and dual controls in order to support this particular requirement, that you have means and methods to render those particular keys unreadable by anybody, should they ever get access to them. These keys should never reside in clear text in an unprotected state, ever.