Encryption Key Management Primer – Requirement 3.6

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.

Advertisement