Auto-booting and Securing a Linux Server with an Encrypted Filesystem

I know of a clever variant of Option 1 called Mandos.

It uses a combination of a GPG key pair, Avahi, SSL and IPv6 all added to your initial RAM disk to securely retrieve its root partition's key password. If the Mandos server isn't present on the LAN your server is an encrypted brick or the Mandos server hasn't seen a heartbeat from the Mandos client software for a given period of time it will ignore future requests for that key pair and the server is an encrypted brick next time it boots.

Mandos Homepage

Mandos README

If you're just looking to protect against non-technical attackers I think your best bet is better physical security.

My thinking is thus:

If you're looking for a boot requiring no human interaction to enter key material then you're not going to come up with any solution that will be safe from even casual theft by an attacher with any technical skills (or, more appropriately, the ability to pay someone with technical skills).

Putting key material in something like a USB thumb-drive wouldn't offer any real security. The attacker could just read the key off of the thumb drive. The thumb drive can't know whether the computer it has been plugged into is the server computer or the attacker's laptop. All the attacker has to do is be sure they either take everything, or in the case of your USB key on the end of a 15 foot long USB extendo-cable stuck inside a safe, just plug the extendo-cable into their PC and read the key.

If you're going to transfer the key over the network you'll probably "encrypt" it. All the attacker has to do is eavesdrop on the keying process, steal the server, and then reverse-engineer any "encryption" you did when you sent the key across the network. By definition, the server computer receiving an "encrypted" key from across the network has to be able to "decrypt" that key in order to use it. So, really, you're not encrypting the key-- you're just encoding it.

Ultimately, you need an (artifical?) intelligence present to input the key into the server. One that can say "I know that I am not divulging the key to anyone but the server computer, and I know that it hasn't been stolen." A human can do this. A USB thumb drive cannot. If you find another intelligence that can do it then I think you'll have something marketable. >smile<

It's most likely, I think, that you'll lose the key and destroy your data while not gaining any security. In lieu of your strategy with encryption games, I think you're better off having stronger physical security.

Edit:

I think we're working from different definitions of the term "threat model", perhaps.

If your threat model is hardware theft, then your proposed solution re: disk encryption is, as I see it, doing nothing about counteracting the threat. Your proposed solution looks like a countermeasure against theft of the data, not theft of the hardware.

If you want to stop the hardware from being stolen, you need to bolt it down, lock it up, encase it in concrete, etc.

I've already said what I wanted to say re: theft of the data, so I won't harp on that again, except to say: If you're going to put the key into a physical device and you can't protect the server computer from being stolen then you can't protect the key device from being stolen either.

I guess your best "cheap" solution is to rig some kind of network-based key exchange. I'd put one or more humans in the loop to authenticate "release" of the key in the event of a reboot. It would cause downtime until the human "released" the key, but at least it would give you a chance to find out why a key "release" was being requested and decide whether or not to do so.