Re^2: Cryptology in the database

[patspam]

Hats off, that's a pretty cool approach. My server is actually a virtual machine which is why the hardware security module (HSM) approach (really expensive out-of-the-box version of what you detailed) is out. Sorry to keep shutting down these great ideas with extra info that I should have provided in my inital post.

I guess the fact that my server is a VM means that my security is already pretty weak, but assuming I'm willing to trust my virtual server provider (or maybe BECAUSE I'm willing to trust them) there's still an appeal in encrypting private data in the db.

Your PS has gotten me thinking though, there's certainly nothing stopping me from commissioning a second virtual machine to separate webapp code from db. Now that I think about it, maybe the very best I can achieve in this virtual server situation is to commission a second virtual machine to act as a virtual HSM, that is, to act as the encryption provider/key store etc.. whereby the encryption key(s) never actually leave the vm (unless someone hacks it of course). I obviously don't get the primary benefit of an HSM which is physical tamper-proof security of the key(s), but it at least means that someone has to hack both vms, or just hack the webapp server and hijack the app/communication channel to the virtual HSM to decrypt data online (which, according to my reading, is an unavoidable problem even in a physical HSM and can only really be 'protected' against by monitoring for activity spikes etc..).

I'm cautiously optimistic about the above approach, but please someone pop my bubble if I've over-looked something obvious

Cheers,

Patrick

[jethro]

I don't think I've heard of any break-ins into hypervisors yet. It will eventually happen, but at the moment virtualization seems to be quite safe IMHO.

Checking for activity spikes is a good idea, another idea would be poisoned data sets, i.e. you add data that you are careful to never access. If it gets accessed, further access is prevented (or simply the decoding key changed so that the attacker still thinks he gets data, but it is unreadable) and you are alerted. This could be implemented maybe with the help of stored procedures or a separate watcher process.