Re: Cryptology in the database

Before diving into algorithms and key management, one should ask What to you want to protect against? Some challenges are

Direct access to file and log file viewing/tampering.
System user privilege abuse.
Stolen or lost media.

At work I face some of these requirements and I find it hard to come up with a satisfying solution.

There are plenty of articles on database encryption, e.g. Encrypting Data Values in DB2 Universal Database (ibm.com/developerworks) which describes using Column level encryption in the DB2 database. While an interesting read, the article does not touch on key management. The question of where do we store the keys remain unanswered.

I recommend reading the Payment Card Industry Data Security Standard Specification (pcisecuritystandards.org). The PCI DSS Specification outlines a series of principles on how financial institutions are to protect financial data (credit card details etc). Again, there is no definitive implementation, but some of the ideas behind it are interesting (from section 3):

Keep cardholder data storage to a minimum.
Do not store sensitive authentication data subsequent to authorization (even if encrypted).
Render [cardnumber], at minimum, unreadable anywhere it is stored (including data on portable digital media, backup media, in logs, and data received from or stored by wireless networks).

I find the idea of not storing sensitive data unless it's absolutely necessary particularly interesting.

--
Andreas

Comment on Re: Cryptology in the database

Replies are listed 'Best First'.
Re^2: Cryptology in the database by patspam (Sexton) on Mar 31, 2008 at 07:01 UTC
Thanks for the reply Andreas. You're right in that I will probably want to use column level encryption to apply encryption to the data, Kenan's book covers the different strategies (key families, key scope, striping etc..) and the article you linked too looks like interesting reading for an easy way to do it in db2. The problem I'm struggling with is where to store the keys. It seems to me that if someone is skilled enough to break into my db server to take a copy of the database (this is what I want to protect against) then chances are they're also skilled enough to break into my application server (which is actually currently the same machine) to view my perl source code to un-obfuscate the encryption key. So encryption doesn't seem to give me any extra level of security at all :( I suppose the problem is slightly more apparent in perl than in a language like Java because the source code is easily viewable on the server as source, but compiled code can still be reverse engineered.. Maybe this is why it doesn't exist on the CPAN? Is it a lost cause? Patrick	[reply]
Re^3: Cryptology in the database by ikegami (Patriarch) on Mar 31, 2008 at 07:37 UTC
"break into my db server" is rather vague. How would the attacker do that? You need to look at more specific attacks (for example, "tricking the database into returning data is shouldn't" and "access to arbitrary files"), calculate the chance of the attack happening, the cost of successful attack (not just financial), the costs of the possible counter-measures (again, not just financial) and the effectiveness of the possible counter-measures. The most likely source of leaks is an SQL injection vulnerability, and encrypting the database won't help protect you from that at all since you'll happily decrypt the returned data for the attacker.	[reply]
Re^4: Cryptology in the database by patspam (Sexton) on Mar 31, 2008 at 09:08 UTC
Hi ikegami, You're right, I'm not being specific enough. By "break into my db server" I really mean "obtain a copy of my database" How would the attacker do that? Gaining shell access to my server and doing a live dump of the db (only I have access to the machine, no shared-hosting or anything), stealing my backups, etc.. Chance of the attack happening Hopefully very low but since I'm dealing with medical info I'm compelled to encrypt the database anyway the cost of successful attack A whole lot of badness the costs of the possible counter-measures and the effectiveness of the possible counter-measures The point of my post is to find out if any counter-measures exist, suggestions welcome! I'm not so much concerned with SQL injection in regards to this question although I totally agree it's a really tough hole to protect against and something I'll also need to adrress in my code. Cheers, Patrick	[reply]
Re^5: Cryptology in the database by andreas1234567 (Vicar) on Mar 31, 2008 at 10:28 UTC
Re^5: Cryptology in the database by jsegal (Friar) on Mar 31, 2008 at 23:23 UTC
Re^3: Cryptology in the database by andreas1234567 (Vicar) on Mar 31, 2008 at 07:41 UTC
The problem I'm struggling with is where to store the keys. Yes, that's the hard part. One solution could be to not store the keys on disk at all. Rather, supply them as arguments when you start your application. That way the keys are stored in memory only (and possibly also cached to disk (swap), but that's another story). An attacker would then have to gain access to your application's memory in order to access your data. I assume that to access content in memory would be considerably harder than to access content on disk. -- Andreas	[reply]
Re^4: Cryptology in the database by patspam (Sexton) on Mar 31, 2008 at 09:15 UTC
I think I'm leaning towards this option (even though it will be me who gets the alert at 4am that the server has crashed and is waiting for me to re-enter the key so it can start again..). The only thing conceptually broken about doing that is that I'm the only one with access to the box, so if someone is able to hack in and gain root access to copy the database, they could equally install a key logger to grab my 4am key entry. Patrick	[reply]
Re^5: Cryptology in the database by andreas1234567 (Vicar) on Mar 31, 2008 at 12:48 UTC
Re^2: Cryptology in the database by stiller (Friar) on Mar 31, 2008 at 08:05 UTC
I find the idea of not storing sensitive data unless it's absolutely necessary particularly interesting. It's a very good one. Unfortunately it's often an uphill batle to get acceptance for not storing a lot of 'nice to have' data that's not really neccesary to keep and that greatly increase the complexity of the application. Beeing able to conjure som estimates on the cost (not just economic) of adding each table/field sell better with management than just complaining though. Remember to apply π² to your first idea when you think of a number. Add prime time news headlines to the picture when it's security related.	[reply]
Re^3: Cryptology in the database by andreas1234567 (Vicar) on Mar 31, 2008 at 08:21 UTC
Add prime time news headlines to the picture when it's security related. Possibly the ugliest example so far is the TJX data breach (45.6M card numbers stolen). Then there's the UK HM Revenue and Customs lost computer disks (25M confidential child benefit details lost). The list grows quickly. -- Andreas	[reply]