Requirement 3.6 states:
“Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data, including the following:
Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov.”
Again, for users of PGP or hardware security module (HSM), you should have no problem complying with the sub-requirements of 3.6. For those that do encryption key management manually, you will have to implement detailed procedures to accomplish these requirements and this is who I am focusing this post. However, keep in mind that the order in which I address the sub-requirements is not necessarily in PCI order.
Let’s first talk about key management in general. The PCI DSS references the NIST key management procedures. NIST has issued special publication (SP) 800-57 that is probably the best “bible” for encryption key management. It goes into detail not only on encryption itself (volume 1), but also key management (volume 2) and discussion of special key management situations such as public key infrastructure (PKI), IPSec and others (volume 3). For requirement 3.6, only volume 2 is likely relevant unless you are using IPSec, PKI or other special cases.
For those of you that are a service provider and you share cryptographic keys with your customers, you will need to document your policies, standards and procedures for securely sharing those cryptographic keys with your customers.
Under requirement 3.6.c are the secure key management practices that the PCI DSS requires. These are where people seem to get off track and where NIST SP800-57 can provide you the greatest assistance.
Requirement 3.6.1 is the easiest and I have spoken on this topic in my post on encryption basics. You need to generate strong encryption keys. You should generate your encryption keys using a minimum of two people (your key custodians) and using a pseudo-random key generator such as the one available from Gibson Research Corporation (GRC). Each key custodian enters their part of the key into the system and then the system uses those parts to encrypt the data.
Requirement 3.6.2 discusses how encryption keys are distributed and 3.6.3 is about how key parts are stored. This is related to how your key custodians manage their part of the key. Typically a key custodian will be assigned a safe where their key part is stored on paper or other unsecured media. Only the custodian and their back up know the combination to the safe. I have also seen PGP Zip or encrypted WinZip files used as the secure repository for key parts. The idea is that key parts cannot be distributed in clear text. And when the key parts are stored, they need to be secured.
Requirement 3.6.4 always seems to be a sticking point because people get caught up in the key expiration concept. The primary thing to remember is that whether or not a key expires is typically related to the encryption algorithm used such as for those using public key infrastructure (PKI). In most cases, the encryption keys do not expire, so this requirement is not applicable. In those cases where the key does expire, you need to have procedures documented explaining how the key expiration process is handled.
This does bring up a good point about any encryption process and addresses requirements 3.6.5.a and 3.6.5.b. There will be times when encryption keys need to be changed. This most often happens when a key custodian changes roles or leaves the organization. In those cases, you need to have a process in place to change the encryption keys.
One thing implied by requirements 3.6.5.a and 3.6.5.b is how do you know that an encryption key has been weakened or compromised? Typically, your activities surrounding critical file monitoring will be the trigger that encryption keys have been compromised or have at least been attempted to be compromised. You should be monitoring the encryption process as a critical file as well as the encrypted encryption keys if you are storing them on a server or other computer system. Should your file monitoring indicate that these files are being tampered with, you need to change your keys.
Requirement 3.6.6 is all about the manual management of encryption keys by key custodians and the need for no one individual to know the entire encryption key. Obviously this requires at least two people to be involved, but you need to have backups for those people, so it really is a minimum of four people. I have seen instances of three and four primary key custodians, however, going beyond that seems a bit much.
Requirement 3.6.7 is all about change control in making sure that key changes require authorization and that unauthorized changes cannot go unnoticed. Management approval of encryption key changes is a straight forward concept and should be a concept already implemented for change control. However, people seem to get balled up in the unauthorized key change concept. Again, your critical file monitoring processes should catch these attempts.
Requirement 3.6.8 requires that all key custodians are required to formally acknowledge their responsibilities in managing and protecting any encryption keys in their custody by signing an agreement to that effect. This does not have to be some long and lengthy document, just a single page that indicates that the individual has access to the encryption key parts and that they agree to keep those parts secure and protected.
And there we have it. If you have read the entire series, you should now have a very basic understanding of encryption and encryption key management. You are not an expert, but you should now have a basic understanding of the concepts and controls surrounding encryption.
The definition of Cryptoperiod by NIST is the following “The time span during which a specific key is authorized for use or in which the keys for a given system or application may remain in effect.” Even though some keys do not expire because of the encryption protocol used, does not mean a cryptoperiod would not be applicable. In my opinion this would be a mis-leading interpretation that would leave entities at risk.
While I agree with what you and NIST are saying, as I also like to say, “In theory, theory works.” Unfortunately, there are business issues that do not always make the changing of encryption keys feasible. I have clients that it took up to two years to get their databases encrypted and now you want them to change their keys and essentially leave their databases unencrypted for about four years while the new key is implemented? Granted, these are very large clients and, no, they do not save every transaction, just the last years worth. A lot of the very large Participating Organizations successfully argued that annual key changes were just not always feasible or desirable. In addition, the PCI SSC and card brands were reporting that more than 70% of Level 1 merchants were using a compensating control for meeting requirement 3.6 because they could not change keys annually as was required prior to PCI DSS v2.0. As a result, key changes are only really required when the keys are suspected to be compromised. Is that a good idea for everyone to follow? No and I do recommend that people periodically change keys when they can. But not everyone can or should.
We are a level 1 merchant with a couple thousand PIN pads as well as a huge database with 1.5 yrs of data. What would be some example of compensating controls for meeting 3.6? Annual key changes are simply not feasible, but our last QSA was not able to give us any suggestions for compensating controls.
This in interesting regarding your comments related to Requirement 3.6.4, key expiration applicable to encryption algorithms such as those used for PKI. I was under the impression that symmetric keys such as AES and TDES used internally should also have a defined crypto-period. NIST SP800-57 has defined recommended crypto-periods for Symmetric Data Encryption keys, so I am not sure how it can be considered not applicable if the keys do not expire. It may be a manual process but I believe it must still be done.
Yes, NIST recommends key changes, but the PCI DSS only says that changes are required if the key expires or the key is suspected of being compromised. In most situations, keys do not expire unless the encryption protocol causes the key to have an expiration date. As a result, in most cases, keys will not expire. The reason the PCI DSS calls this out this way is that a lot of large merchants, even with aggressive data purge practices, still can have voluminous amounts of cardholder data in their systems that would take months or even years to decrypt and encrypt with a new key. This would cause large amounts of data to potentially unprotected during key changes, so the PCI SSC decided it was better to only require key changes if the key was suspected of being compromised rather than expriring keys as preferred by NIST.
Requirement 3.6.4 states “Verify that key-management procedures are implemented to require periodic key changes at the end of the defined cryptoperiod.” I did not see anywhere where PCI DSS goes into detail as you have mentioned regarding the algorithm used. PCI DSS points back to NIST for guidance, and NIST has defined best practices for symmetric and asymmetric key changes. Unfortunately this is the reason why there is so much confusion with this requirement as there is a lot of room for interpretation.