PCI Encryption Key Management

Question

(Full disclosure: I'm already an active participant here and at StackOverflow, but for reasons that should hopefully be obvious, I'm choosing to ask this particular question anonymously).

I currently work for a small software shop that produces software that's sold commercially to manage small- to mid-size business in a couple of fairly specialized industries. Because these industries are customer-facing, a large portion of the software is related to storing and managing customer information. In particular, the storage (and securing) of customer credit card information. With that, of course, comes PCI compliance.

To make a long story short, I'm left with a couple of questions about why certain things were done the way they were, and I'm unfortunately without much of a resource at the moment. This is a very small shop (I report directly to the owner, as does the only other full-time employee), and the owner doesn't have an answer to these questions, and the previous developer is...err...unavailable.

Issue 1: Periodic Re-encryption

As of now, the software prompts the user to do a wholesale re-encryption of all of the sensitive information in the database (basically credit card numbers and user passwords) if either of these conditions is true:

1. There are any NON-encrypted pieces of sensitive information in the database (added through a manual database statement instead of through the business object, for example). This should not happen during the ordinary use of the software.

2. The current key has been in use for more than a particular period of time. I believe it's 12 months, but I'm not certain of that. The point here is that the key "expires".

This is my first foray into commercial solution development that deals with PCI, so I am unfortunately uneducated on the practices involved. Is there some aspect of PCI compliance that mandates (or even just strongly recommends) periodic key updating?

This isn't a huge issue for me other than I don't currently have a good explanation to give to end users if they ask why they are being prompted to run it.

Question 1: Is the concept of key expiration standard, and, if so, is that simply industry-standard or an element of PCI?

Issue 2: Key Storage

Here's my real issue...the encryption key is stored in the database, just obfuscated. The key is padded on the left and right with a few garbage bytes and some bits are twiddled, but fundamentally there's nothing stopping an enterprising person from examining our (dotfuscated) code, determining the pattern used to turn the stored key into the real key, then using that key to run amok. This seems like a horrible practice to me, but I want to make sure that this isn't just one of those "grin and bear it" practices that people in this industry have taken to. I have developed an alternative approach that would prevent such an attack, but I'm just looking for a sanity check here.

Question 2: Is this method of key storage--namely storing the key in the database using an obfuscation method that exists in client code--normal or crazy?

Believe me, I know that free advice is worth every penny that I've paid for it, nobody here is an attorney (or at least isn't offering legal advice), caveat emptor, etc. etc., but I'm looking for any input that you all can provide. Thank you in advance!

Answer 1

Issue 1 : You mention password encryption. Firstly why are passwords rather than salted hashes of passwords used? As for key rotation/expiration, I've seen (and coded for) policies like that. The longer a key is in use (and the more times it is used) the higher the risk it may become comprised/discovered. Some systems, for example Windows DPAPI automatically expire keys, SSL certificates have expiration dates after which a lot of systems will not use them to encrypt new data and so on.

Issue 2: Yes, that's bad. Incredibly bad.

The PCI compliance audit specs for the PAN state "Strong cryptography, such as Triple-DES 128-bit or AES 256-bit, with associated key management processes and procedures"

Rotation could be argued to be part of the key management process, and storing the key securely away from the data definitely is part a key management process.

Section 3.6.4 of the audit specs go further and state

Periodic key changes

• As deemed necessary and recommended by the associated application (for example, re-keying);
• preferably automatically At least annually

Answer 2

If you've not already I'd recommend looking through the PA-DSS and PCI-DSS docs, as they've got a lot of info. regarding the requirements. If your software is certified for PA-DSS then I'd guess you'll have a QSA who should have more specific information about expectations for passing those requirements.

In terms of managing the encryption of data, if you can I'd recommend using inbuilt features from whichever database engine you're using in that getting application level crypto. right can be very tricky. There's a good paper on the options here.

Answer 3

Issue #1: Periodic Re-encryption
(Also known as re-keying). Yes, that is normal, though not required.
Specifically, expiring keys is necessary, and required by PCI. At least once a year, with the option of doing it sooner.
How you deal with that is another matter... For instance, once the key for 2010 expires, what do you do with all the data that was encrypted with that key?
One solution is to store a history of all keys, and a "key version" for each piece of data so that when you decrypt it, you'll know which key to use. (Of course you encrypt using only the new key.) Another solution is the aforementioned rekeying - only have a single at each point (except during rekeying...) and when expiring, decrypt with the old key and re-encrypt with the new one.

Issue #2: Key storage
Quite simply, its bad, and makes encryption (not quite, but nearly) pointless.
Proper key management techniques in general, and PCI in particular, define a strict key management policy and procedures. Some of it is technical: e.g. the Encryption Key (EK) must be encrypted using strong encryption, e.g. DPAPI; some of it is procedural: e.g access to the Key Encryption Key (KEK) must be documented; some of it is manual: e.g. split knowledge / dual control of the KEK.

As @Rory said, talk to your PA QSA, and if you don't have one - get one.

Answer 4

I am most interested in the 2nd question. I struggled sometime with understanding the reasons for storing the encryption key so close to the encrypted data, even though you store it encrypted with a key encryption key.

The only reason that I can think of is using the database encryption infrastructure/capabilities for performing transparent encryption/decryption. Though, this is highly database vendor specific (as stated in a document linked by a previous post too).

I would advice keeping the keys in a different storage, protected by passwords or with an HSM device.

Answer 5

Issue 1 : I'm amazed it's only after 12 months. Our servers require new keys/passwords every 3 months. Nothing credit card related, but still. I guess that's sensible practice, although I can't say for sure it's PCI compliant, but if it isn't, it should be.

Issue 2 : Sounds very sane to me. I'd never store a key, not even obfuscated, right next to the data. That's just an open challenge: "Please, try and hack me".