Before getting into key management, it is important to acknowledge that these requirements are not relevant to every encryption solution. In the case of PGP, key management requires the user to create a private/public key pair and then authenticate using their passphrase. It is not that the principles of key management do not apply to PGP; it is just that such key management practices are not usually associated with PGP.
Hardware security module (HSM) solutions typically provide facilities for strong key creation as well as a secure storage mechanism for keys. A prime example of this concept is with the Trusted Platform Module (TPM) that is now standard on notebook computers. I will try to point out the differences with these various approaches as I move through the discussion.
So with that as a background, let us start into our discussion of requirement 3.5. The overall goal of requirement 3.5 is stated as:
“Protect any keys used to secure cardholder data against disclosure and misuse: Note: This requirement 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.”
Typically, the first question I get is, “What in the world is a key-encrypting key?” I need to push this question off, as there are other questions that need to be addressed before a meaningful discussion of the key-encrypting key (KEK) can occur.
With the key-encrypting key question put on the back burner, the second question most people ask is how does one accomplish protection of encryption keys? In the case of PGP, that is the responsibility of the key owner not to disclose their passphrase. It is the role of the HSM key repository to protect and manage keys. If your encryption solution does not provide a secure repository for your encryption keys, then you need to provide such a capability.
When you have PGP or HSM, then protecting encryption keys is built-in. A manual option is to store you encryption keys on paper or removable storage media and store the paper or removable media in a safe. The problem with the manual option is that encryption keys are typically needed to boot the secure server or start an application that needs access to encrypted data. The security surrounding the keys becomes problematic at best as operations personnel need regular access to the keys in order to keep systems and applications running. As a result, most organizations desire to have their keys stored electronically for ease of access by servers and applications.
This now brings us to the concept of a KEK. If you desire electronic storage of encryption keys, then you need to ensure their security. If you store encryption keys in a folder on another server, you need to not only restrict access; you also need to encrypt them so that should someone copy the folder, they cannot read the keys. To accomplish that, you encrypt the encryption keys wherever they are stored and then secure the key encrypting key (aka KEK).
This is where requirements 3.5.1 and 3.5.2 come into play. These requirements are focused on ensuring that if an organization has taken the approach of managing their own encryption keys and electronically storing them, the keys are properly secured and managed by as few persons as feasible.
That does not mean that those of you using PGP or HSM are not responsible for also complying with requirements 3.5.1 and 3.5.2. It is just that those of you using PGP or HSM likely have an easier time complying as both technologies can provide their own solutions for meeting these requirements.
In a future entry, I will discuss requirement 3.6.