So let’s talk about a better way to do database encryption - one that includes the use of an asymmetric encryption method. Normally you’d want to avoid this route simply because the processing overhead associated with using a public/private key pair is astronomical when applied on a transactional basis. However, we’re going to do something that avoids most of the overhead concerns and will have minimal impact on your transaction speed (no more than a symmetric key option would have anyway).
First, we are going to generate our keys (called a 'key pair') – then, with our public key and private key in hand we'll... Wait, let’s set the private key aside for the moment.
The public key is the one that will be used to actually perform the encryption process – it’s our data scrambler. If you think about the applications that interact with your database, you’ll tend to find that the bulk of your credit card transactions are about putting data in. It isn’t all that often that someone (inside your organization) would need to see a full credit card number or other sensitive data element to do their job. Customers certainly don’t need to see the full credit card number – they may just need the last 4 digits to help them identify which card they are using – but really, there is little need to ever push sensitive cardholder data back out to your customers.
So the public key is the one that you would place in the application pathway – it’s the one that your applications will call on to perform the encryption process on the data elements you select (like the full credit card number). The coolest thing here is that the public key has no protective requirements whatsoever – if someone were to get a hold of the public key somewhere along the application pathway, your data remains safe. You can literally place the public key anywhere you want – even in multiple locations at once… Feel free to embed that bad-boy in all of the application code you want to…
Now back to our private key – the one that’s used to decrypt (or unscramble) the data, thereby making it readable again. The private key is the one that really needs protecting. In this encryption model, we’re going to move the private key to its own dedicated server – likely a small virtualized environment that has been completely locked down with every control imaginable (including the logging of every single interaction that takes place on the box, especially anything having to do with the key itself). Now, if an application needs to decrypt the data, it makes a call to the protected server, plugging the private key into the database to unlock the data. There are a number of ways to perform this kind of a call securely – there are even built in functions in most programming languages that have been created for precisely this sort of thing.
