Okay, so far all I’ve explained are the public and private keys that are used. Now I’m going to add in a third key – a session key that is used for each transaction involving encryption. When I mentioned that we’d be doing something special to address concerns regarding transaction overhead with an asymmetric encryption method, this is it.
When your application needs to encrypt a piece of data, it’s actually going to encrypt that data with what is called a session key. Instead of using your public key to encrypt the data, you are going to use the public key to encrypt the session key. When your application needs to decrypt a piece of data, it’s actually going to use your private key (from your protected environment) to decrypt the session key that was used to encrypt the data, then that session key will be used to decrypt the data itself.
If you’re a little confused at this point, let me describe what a session key does. A session key is a randomly generated symmetric key often associated with the concept of ‘one-time-use’ encryption. When you encrypt the data, your application will generate a random session key. This is a symmetric key that will be used to both encrypt and decrypt the data. Once the data is encrypted, your application will then use the public key we’ve been talking about to encrypt the session key. The encrypted data gets stored in one field, while the encrypted session key is recorded in another field associated with the same transaction. Later, when another application needs access to the data, it will call on the private key to decrypt the session key and then use the session key to decrypt the data.
It may still be a bit confusing, and this is really the first time I’ve tried to explain the process in writing without using diagrams or giving a face to face presentation (which usually involves a white board). If you do some poking around, you may find additional information on this encryption scenario – or you can just comment below and I’ll see if I can provide a better explanation – maybe even updating this article to be a bit more clear.
Why do all of this to begin with? I’ve barely even scraped the surface of the benefits this kind of encryption solution offers. First of all, it’s obviously going to be a lot more secure since the decryption key is used a lot less often and afforded a much greater degree of protection. Moving it out of the application pathway for any externally accessible applications also makes a huge difference. But let’s look at this from another perspective.
What happens when you need to change keys as part of your key management practice – ohhh yes, PCI calls for key changes. If you just have one key for everything, it pretty much means you have to unencrypt the entire database and then re-encrypt it again with the new key. What happens to the data during this period? Is it exposed? What about any application downtime that might be incurred? Now, if you’re using the method I’ve described, you really only need to decrypt and re-encrypt the session keys that were used to protect the data itself. The data remains encrypted throughout the entire process.
There are several additional benefits that I’ll look to add to this article at a later date. For now, I just wanted to share the method as an option for consideration and see what kind of response I get from people. I want to focus on any points requiring clarification before I do a deeper dive.
For now, I hope this was enough to get you thinking – and maybe even reassessing your current database encryption strategy.
