3

According to PCI-DSS requirement 3.5.2:

Secret and private keys used to encrypt /decrypt cardholder data should be stored in one of the following forms at all times:

  1. Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key.

  2. Within a secure cryptographic device (such as a host security module(HSM) or PTS-approved point-of-interaction device).

  3. As at least two full-length key components or key shares, in accordance with an industry-accepted method.

My questions:

  1. How to store Key-Encrypting Key separately from Data-Encrypting Key and is that a best practice?

  2. If we decide to store KEK separately from DEK, then should we need to store DEK in a server and KEK in a separate server?

  3. If we decide to store keys in a cryptographic device, then which will be a best practice among HSM and PTS?

  4. What is two full-length key components or key shares? Could anyone explain about it?

Is there any useful links or documents available?

1
  • As always with PCI-DSS, ask your PCI-DSS consultant for help, documents, requirements for your particular set of circumstances, and so on and so forth. Feb 26, 2014 at 4:27

2 Answers 2

3
  1. Think of the Data Encrypting Key as a "session key" in SSL. It can/should be a random value that you would spin up for the purpose of encrypting an account number. The Key Encrypting Key would be the public key retrieved from a certificate. You use the KEK to encrypt the DEK, then throw away the plaintext DEK after encrypting the data. Meanwhile, the private key (paired with the public key on the certificate) remains securely locked up inside a protected environment, far away from the data environment. And yes, this is a best practice.

  2. I would never store the plaintext DEK. Instead, encrypt the DEK with the KEK, and store only the encrypted DEK.

  3. An HSM provides a tamper resistant environment to house cryptographic operations, and is preferred for sensitive operations like key decryption.

  4. Use an algorithm like Shamir's Secret Sharing. It allows you to split the key into several parts, and requires a certain number of parts to reassemble it.

2

Well, let me try to help you.

Let's imagine you have a safe inside a drawer full of diamonds, will you store the combination or the key of the safe in the very same drawer? This is the very same, just common sense. So to answer your questions:

  1. Yes it is a best practice. If you don't really use your KEK a lot, you could even keep it in a pendrive inside a safe. But since you might use it a lot, you can store it in a different server (or different PC).

  2. Well that is up to you, if someone has access to the whole disk will find both: KEK and DEK, does this problem by itself worth the money for a new server? You will need to do some analysis on that. If not, consider at least storing them within different permission sets (maybe different users with different capacities...).

  3. PTS has nothing to do here go for HSM if you can afford since it is a solution by itself and you look like a bit unsure about these topics.

  4. This is simply a way to have several people/processes involved when decrypting a key, this is called secret sharing and there are several algorithms out there.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .