15
Jan
12

Encryption Key Management Primer – Requirement 3.5

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.

Advertisements

0 Responses to “Encryption Key Management Primer – Requirement 3.5”



  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

January 2012
M T W T F S S
« Dec   Feb »
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,836 other followers


%d bloggers like this: