Re^2: Cryptology in the database

in reply to Re: Cryptology in the database
in thread Cryptology in the database

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

Comment on Re^2: Cryptology in the database

Replies are listed 'Best First'.
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
SQL injection [is] a really tough hole to protect against Not really. Revoke `SELECT, INSERT, UPDATE, DELETE` privileges from you application's user account and grant access to your data through stored procedures only (provided that the DBMS of your choice supports it). That's what I consider the most effective SQL injection prevention. See also Avoiding SQL Injection (owasp.org). -- Andreas	[reply] [d/l]
Re^5: Cryptology in the database by jsegal (Friar) on Mar 31, 2008 at 23:23 UTC
One potential thing encryption can guard against is theft of the database backup tapes. If the database backup tapes and the application server backup tapes are kept and stored in different locations, it is conceivable that someone could steal a database backup tape and thus obtain a copy of the database without a copy of your application. In this case, encryption could be a benefit. --JAS	[reply]
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
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 Security (more often than not) comes with inconvenience, trouble or annoyance. You will have to compare the benefits with the disadvantages and find a balance that's right for you. Since you are dealing with medical info you will probably sleep better with a secure solution anyway, that will more than make up for that once-a-year wake up call :) -- Andreas	[reply]

In Section Seekers of Perl Wisdom