views:

525

answers:

2

Has anyone got practical experience or a reference for a scheme that implements a key management scheme that would comply with the PCI DSS security standard?

There are obviously quite a few implementations around given the number of companies compliant with PCI DSS but trying to find details of them is tough. When it gets down to storing private data the discussion normally stops at which encryption algorithm to use. After that there's normally a statement about appropriately storing the private key but no discussion about practical ways to do it or things like periodically changing the key or providing the key to applications etc.

Specificlly I'm interested in thee requirements from sections 3.5 and 3.6 of the PCI DSS standard.

3.5.2 Store cryptographic keys securely in the fewest possible locations and forms.

3.6.a Verify the existence of key-management procedures for keys used for encryption of cardholder data. Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov.

3.6.4 Verify that key-management procedures are implemented to require periodic key changes at least annually.

I've had a look at the NIST Cryptographic publications as the PCI DSS requirements document suggests but apart from recent notes of a Cryptographic Key Management Workshop there doesn't appear to be much there in the way of real implementable schemes or standards.

As to what I'm trying to do it's not:

  1. Store passwords + salts as one way hashes for authentication,
  2. Choose a strong symmteric algorigthm for data encryption,
  3. Avoid needing to store private data in the first place.
  4. Avoid the need for key management with other mechanisms: physical security, database security, dragons and wizards etc.

All of which are valid concerns but in this case are not the answer. The nuts and bolts of my requirements are in a different SO question .Net Design pattern for storing and retrieving sensitive per user data but it all boils down to key management hence this more refined question.

+2  A: 

Have you seen NIST SP 800-57, Recommendation for Key Management?

Martin v. Löwis
Good link, thx, that's the refence standard I was after. Now where could I find an example of how key parts are implemented...
sipwiz
@sipwiz: I have no idea. My guess would be that somebody would sell you these key parts for a lot of money; you might ask NIST whether they have a list of companies that would do so.
Martin v. Löwis
+4  A: 

I'm familiar with the pain you're going through. We struggled to update an old EFT system towards PCI compliance. Key management was certainly (from my software point of view) the most challenging part.

I think I also stumbled into the NIST Recommendations for Key Management that Martin posted, and got incredibly frustrated with the lack of concrete examples.

ANSI X9.17 - Financial Institution Key Management is probably the most relevant to your needs, with PCI-DSS. Good luck reading it though, the document is a massive collection of TLA's which I know I certainly struggled to read.

When frustration turned to desperation I stumbled into The Electronic Money Mill which is a fictional tale, with a good number of relevant technical references. Chapter 17 discusses X9.17 and may help with the understanding.

From all this reference material I designed a key management system that our auditor was pleased with. The design documents are fairly lengthy, but in summary the idea is that you have your Data Encrypying Key protected by a Key Encrypting Key, and the Key Encrypting Key is stored on a physically separate box, itself protected by a Master Key.

My implementation was to have a Key Server application running on a windows box. This application required entry of two separate 'key server master keys' before it could be used. These keys would be known only to the key server administrators. These keys are xor'd together to generate the Master Key, which is stored only in protected memory whilst the application is running. Application can then automatically generate cryptographically strong Key Encrypting Keys, which are stored in encrypted form using the Master Key.

Applications that have a need for encryption will request a Key Encrypting Key from the Key Server. The KEK is used by the application to encrypt/decrypt the Data Encrypting Key, which can be stored securely with the application data.

Good luck. I hope you also find it an interesting challenge!

PaulG
Luckily I don't have to implement the PCI DSS standard, it was just an example in my question so that I'd get answers with robust key management schemes. The trick does seem to be how to get the key encrypting key into the application. I don't want to have a separate server for it so am thinking of either getting the application to generate a prompt for it or being able to ssh to the application to set it.
sipwiz
Sounds good. The separate box is only a requirement if you want to persist the KEK, and intended to protect from a situation where someone takes a copy of the entire application + data (such as literally walking away with the box)
PaulG