Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Re: Cryptology in the database

by jethro (Monsignor)
on Apr 01, 2008 at 01:14 UTC ( #677698=note: print w/replies, xml ) Need Help??

in reply to Cryptology in the database

Well, if all you want is slightly more security, there might be a hardware-based solution that's not that hard to make. The idea is to build a small storage readable from the parallel port, which is only readable after startup. As soon as a special pin on the parallel port is toggled once, that storage isn't accessible anymore (until the next reboot of the machine).

Anyone versed in electronics could build something like this with a relais and some diodes, and an eprom for storage. The trick is that the relais is off after a power down or a reset. When a special pin is toggled, the relais gets turned on and then holds itself on. If the relais is also connected to an adress pin of the eprom, the previous accessible adress range is changed irrevocably

A similar idea without a relais: The eproms lower address pins are not directly connected to the parallel port pins, but to a counter circuit that can only count upwards and does not overflow to 0 (or the highest bit just never turns to 0 after it changed to 1).

Or you get a small microcontroller (for example a PIC) to do that.

You also need a compiled (C or C++) wrapper around your database that does the key retrieval and database decoding with lots of obfuscation and checksumming of the wrapper so that the attacker can't easily patch the code after decompiling it.

This scheme is not much more than an obfuscation. If the attacker knows what's going on, he will just replace the perl code to make a complete dump of the database and reboot the machine. But to find that out he probably needs to do a lot of testing and a few risky revisits to your machine. Not just an easy hit and run.

The hardware is necessary so that the attacker can't just copy your hard disk and search for the key in his remote copy. The compiled decoding wrapper is necessary so that he can't just read the program, find the $key and add one line system("echo $key > /tmp/foo"); on his next visit.

The security you get is not much, but it's the most you can hope for against an attacker with root access. But the time you would have to invest to build this system is considerable. So entering the password at every reboot might be inconvenient, but it gives you the same security with a lot less work.

PS: If you can't deploy a second machine to act as independent database server, why not split your one machine into two virtual ones?

Replies are listed 'Best First'.
Re^2: Cryptology in the database
by patspam (Sexton) on Apr 01, 2008 at 01:58 UTC

    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


      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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://677698]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (4)
As of 2021-03-07 00:09 GMT
Find Nodes?
    Voting Booth?
    My favorite kind of desktop background is:

    Results (119 votes). Check out past polls.