6

I'm trying to get my head around 3.6.3 and 3.6.2 in the PCI-DSS standard, secure cryptographic key storage and distribution.

Would having two 256 bit key halves stored in separate, isolated locations which are XORed together to create the data encrypting key count? Is a key encrypting key strictly required?

The encryption service would be able to read both halves and assemble the data encrypting key. All administrative access to a given key half will be restricted by RBAC and auditing. Assuming that the keys are from a suitability random data source having one of the key halves wouldn't provide a bit (yes, pun intended) of information as to the actual content of the key.

Tim Brigham
  • 3,782
  • 3
  • 30
  • 36
  • 2
    Speaking purely out of ignorance of the standard and going only on what you've presented here, could you argue that XORing two 256-bit strings together is using a key-encrypting key? One bitstring is the encrypted key, the other is the KEK, and the cipher used is Vernam's Cipher? – apsillers Jun 14 '13 at 20:25
  • @apsillers - that is a genius way of looking at it. – Tim Brigham Jun 14 '13 at 20:28
  • 1
    You can do better, without giving the owners of the half-key any knowledge of the secret. Use Shamir's Secret Sharing Scheme - there are libraries and command line tools to do this in a straightforward way. – Deer Hunter Jun 14 '13 at 21:27
  • 1
    @TimBrigham Note that Verman's Cipher will expose some information that normal block ciphers will not; e.g., an adversary that has the plain and encrypted forms of the key can derive the KEK, and (if you ever need to encrypt two keys with your KEK -- perhaps a replacement key is one is compromised), the XOR combination of both encrypted keys is the same as the XOR of the plain keys. Whether any of this is an actual problem depends on what your requirements are (which I'll leave to someone better acquainted with the standard). – apsillers Jun 14 '13 at 21:35

2 Answers2

1

One of the problems with the PCI DSS is that requirements are either in place or they're not so it's not a risk-based approach. The dual control means no single user has 'the keys to the kingdom' so to speak and the key encrypting key (KEK) prevents the key used for data encryption (let's call it the Data Encryption Key or DEK) from ever being seen in the clear.

The KEK should always be of equal or greater strength than the DEK - I'm not sure the requirements are clear on this though they do recommend you're in line with NIST standards (such as 800-57). I don't think using XOR as a KEK for the DEK would provide this.

Enforcing dual control can be tough - doing it though a service which has access to distributed key parts with separate RBAC is a good idea. Another is having a KEK in an application and DEK encrypted with KEK in a database with RBAC on application and DB systems. MS SQL has a key management system built in using Master Encryption Keys, Data Encryption Keys and certificates to protect keys. StrongAuth have a Lite Encryption Library for doing this also. If you have a QSA, you could ask them how they've seen this implemented in the past.

AndyMac
  • 3,159
  • 13
  • 21
0

Coming up with a clear yes/no answer to PCI-related questions is difficult because there are human auditors involved and there isn't a uniform standard for making compliant/non-compliant judgements. One auditor may approve of your approach while another may not.

3.6.2 Secure cryptographic key distribution

3.6.3 Secure cryptographic key storage

Splitting your key into two pieces and re-assembling them just propagates the problem and creates complexity. Now you have two "keys", one encrypted and another that unlocks the encryption of the first key. How do you protect the second key? For systems to work you have to have a key unencrypted somewhere or a human available 24/7 to type in a passphrase.

I interpret 3.6.2 as transfer your key over secure means and only to places where it is needed and 3.6.3 as store your key in the right places with appropriate access controls and auditing.

u2702
  • 2,086
  • 11
  • 11