4

Decrypting the DEK using KEK under PCI-Standards, which are separated by Servers:

Let say for example we have server1 and server2

Server1:

  • It is in East US, called it as Application Server.
  • Hosted my website and database.
  • In my code I'm using AES 256-bit cryptograpy.
  • Store the encrypted cardholder data in DB.
  • This server contains Encrypted DEK(Data Encryption Key).

Server2:

  • It is in WestUS, called it as Key Server.
  • Only contains the Key Encryption Key(KEK) to decrypt the DEK.
  • All port are bocked only accept the request from server1.

I have two processes in my mind for implementation. But just got confused which could be a better way:

Process 1:

Below code is running in server1:

public string Data()
{
    AES objaes =new AES();
    objaes.key= getkey(EncryptedDEK);
//decrypt the values
}

public string getkey(string EncryptedDEK)
{

  //connect to the server 2 and get the DEK
  request(EncryptedDEK);
}

The below function access the server 2 for decrypting encrypted DEK:

public string request(string encryptedDEK)
{
    //check the request
    //decrypt the encrypted DEK with KEK
   //return the Decrypted DEK
}

On the above process, the application touches the key server.I didn't like my application to touch the key server. I need my key server to be very safe and also to be protective against malicious individuals.

Process 2:

Application requests Card number to server 1 --> Server 1 (Encrypted DEK) --> Server 1 sends Encrypted DEK to the Server2 through SQL SERVER 2012 -->Server 2 decrypts DEK and sends it back to the Server 1 --> server 1 responses to the application with the decrypted data
  1. Through sql server can I decrypt the Encryped DEK by connecting to the Server 2 from Server 1?
  2. Which one among the two process works fine or comes under PCI-DSS standards?
  3. Is there any better way than the above two processes?

1 Answer 1

2

If your DEK is being used on the application server, then it's not really encrypted by the KEK, since the app server has access to it. You can just toss the key server, as anyone with access to the app server, one time, can get the DEK and you're done.

You're better of using asymmetric crypto (the KEK) and generating a session key (DEK) for each item. That way, the app server can encrypt with the public key of the KEK and a new DEK for each item. The key server will have the private key, and the private key must never leave the key server.

For encryption, the app server doesn't need to touch the key server at all. You can have many front-end systems encrypting without issue.

Of course to decrypt, you need to access the key server. The app sends the previously-encrypted blob and the key server encrypts it. I suggest setting up another keypair for each app server, and using that keypair to sign decryption attempts. The key server can log every decryption attempt, so you can alarm if you get too many decryption requests. That's useful for finding malicious admins.

Also, please use a library like KeyCzar, so that all the details are implemented correctly. KeyCzar has this exact scenario (sessions) implemented for you. KeyCzar also has tools to help with key management, which is another thing you must deal with. KeyCzar has .NET, C++, Java, and Python implementations.

Finally, please talk to your PCI auditor about this. Some auditors require use of an HSM for this scenario -- that's basically what you're setting up with the key server. Some cloud providers (AWS) rent HSMs, so that may be an easy option.

2
  • 1
    Thanks, In case if I'm using the HSM, how to connect or communicate with the HSM through application server. That is if we connecting the HSM to application server as anyone got access to the app server, can get the DEK from HSM, isn't it? so how HSM is secure then? Commented Mar 3, 2014 at 9:38
  • 1
    The HSM works like I described - your application will verify its identity to the HSM, and the HSM performs the crypto. The keys never leave the HSM. And yes, you still have the problems mentioned; you need to audit access and make sure a malicious admin didn't steal the app credentials and submit illicit decryption requests. All of this is also part of general auditing - you don't want a malicious admin adding malware to a server either.
    – MichaelGG
    Commented Mar 3, 2014 at 17:43

You must log in to answer this question.

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