PCI Requirement 3.5.4 states, “Store cryptographic keys in the fewest possible locations.” Reducing the amount of locations where cryptographic keys are stored helps your organization to track and monitor all key locations. If you have 100 locations, your organization would have to maintain strict control over 100 locations, which could lower the quality of control and increase the chance of unauthorized exposure. Minimizing the amount of locations to places that are necessary helps decrease the potential for an attack.

It’s not the assessors job to determine whether or not you’re really storing the cryptographic keys in the fewest possible places; but it is our job to ask you what the reason is for storing a key in the places that they are in. We may ask, “If you have it in 3 locations, why can’t you get away with 2 locations?” At some point, your answer will be your business justification, like, “Because that would render a high risk to our environment.” Assessors are looking to see that you’ve done your due diligence to reduce the amount of locations where your cryptographic keys reside. During the assessment, your assessor will also, “Examine key storage locations and processes to verify that the keys are stored in the fewest possible locations.”

“We want to limit the places that you store your encryption keys to really the minimum amount of places that are necessary. The purpose for this is that if you have your encryption key stored, while it might sound facetious, in 100 locations, that means you’re going to have to maintain strict control over 100 locations. The fewer possible places where these keys reside, the better off you are as an organization for protecting those keys. Specific to Requirement 3.5, we have a sub-requirement that says we store these keys in the fewest possible locations. From an assessment perspective, it’s not our job or role or charter to define whether or not it’s in the fewest possible locations or not. But, one of the things we’re going to ask you is, “If you have it in 5 places, why don’t you have it in 4?” Or, “If you have it in 3 places, why can’t you get away with 2?” At some point, you’re going to say, “Because this breaks my business process,” or, “This would render a high risk to our environment, such that we wouldn’t be able to protect ourselves in the event of a disaster.” Whatever reason that is, what we’re looking for is that you’ve done your due diligence on where you’re storing those keys, how those keys are being stored, and then indeed, that these keys are stored in the fewest possible locations. “

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.

PCI Requirement 3.5.2 states, “Restrict access to cryptographic keys to the fewest number of custodians necessary.” There should be very few employees who have access to your organization’s cryptographic keys. Typically, only those deemed “key custodians” have this type of access. In order to comply with PCI Requirement 3.5.2, your organization needs to maintain strict access controls around who has access to cryptographic keys in order to prevent an unauthorized user from gaining access to the encryption/decryption keys.

Wherever keys reside, there needs to be strict control. Whether that’s in a safe, somewhere electronic, or backed up, an assessor will want to examine where your keys reside. An assessor will also want to see the list of users who have access to keys, and ensure that the list includes the fewest number of key custodians as possible.

If we’re encrypting cardholder data – or any other data for that matter – and somebody gains access to your encryption/decryption keys, chances are it’s game over. They can look to decrypt that data or gain access to it. PCI DSS Requirement 3.5.2 states that your organization needs to maintain strict access controls around who has access to these keys. There’s going to be several places, from an assessment perspective, that we look to see where these keys are stored. You might have them physically in a safe somewhere, we might look to see how you’re storing them electronically, we might ask how you’re backing them up. In any event, wherever these keys reside, you need to maintain strict control over those particular keys.

PCI Requirement 3.5.1 is an additional requirement that only applies to service providers. It requires that your organization, “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 and expiry date, a description of the key usage for each key, and an inventory of any HSMs and other SCDs used for key management.”

PCI Requirement 3.5.1 requires some extra effort and diligence surrounding documentation because, according to the PCI DSS, “Maintaining current documentation of the cryptographic architecture enables an entity to understand the algorithms, protocols, and cryptographic keys used to protect cardholder data, as well as the devices that generate, use and protect the keys. This allows an entity to keep pace with evolving threats to their architecture, enabling them to plan for updates as the assurance levels provided by different algorithms/key strengths changes. Maintaining such documentation also allows an entity to detect lost or missing keys or key-management devices, and identify unauthorized additions to their cryptographic architecture.”

During the assessment process, the responsible personnel will be interviewed and documentation will be reviewed in order to validate that your organization’s documentation appropriately describes the cryptographic architecture.

“If your organization is a service provider, Requirement 3.5.1 has an additional set of documented procedures for you. This really requires that you do a little bit of extra diligence around documenting the keys that you use, documenting if you’re using an HSM, documenting what those might look like, who you might share keys with – there’s a great deal of information that you’re asked to keep in addition to just the normal documentation. So, have a look at Requirement 3.5.1, specific to you as service provider. If you have any questions, spend some time with your assessor or QSA. I’m sure they’ll be happy to work you with you to identify what complying with this requirement might look like. “

If your organization is using encryption to render cardholder data unreadable, you must have a key management program in place. PCI Requirement 3.5 requires organizations to, “Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse.”

PCI Requirement 3.5 applies to: “keys used to encrypt stored cardholder data, and also applies to key-encrypting keys used to protect data-encrypting keys—such key-encrypting keys must be at least as strong as the data-encrypting key.”

If an unauthorized individual were to gain access to your encryption/decryption keys, they will be able to decrypt your keys. To comply with PCI Requirement 3.5, your organization must have implemented documentation related to preventing unauthorized access to keys. The PCI DSS explains, “The requirement to protect keys from disclosure and misuse applies to both data-encrypting keys and key-encrypting keys. Because one key-encrypting key may grant access to many data-encrypting keys, the key-encrypting keys require strong protection measures.”

During the assessment, everything involved in your key management program will be examined, your staff and key custodian will be interviewed, and the implementation of documentation will be assessed. The PCI DSS also states, “Examine key-management policies and procedures to verify processes are specified to protect keys used for encryption of cardholder data against disclosure and misuse and include at least the following:

• Access to keys is restricted to the fewest number of custodians necessary.
• Key-encrypting keys are at least as strong as the data-encrypting keys they protect.
• Key-encrypting keys are stored separately from data-encrypting keys.
• Keys are stored securely.”

For other resources regarding key management, we recommend viewing the NIST 800-57 document and our webinar on best practices for encryption and key management.

“If your organization is a service provider, Requirement 3.5.1 has an additional set of documented procedures for you. This really requires that you do a little bit of extra diligence around documenting the keys that you use, documenting if you’re using an HSM, documenting what those might look like, who you might share keys with – there’s a great deal of information that you’re asked to keep in addition to just the normal documentation. So, have a look at Requirement 3.5.1, specific to you as service provider. If you have any questions, spend some time with your assessor or QSA. I’m sure they’ll be happy to work you with you to identify what complying with this requirement might look like. “