I know that the title seems to be completely contradictory, but allow me to elaborate. Reading Bruce Schneier's recent article on data deletion got me thinking that every server should have full-disk encryption, if only for the fact that knowing rm file securely deletes the file and as long as it's not anywhere else, it's gone forever.
If I found a way to, say, run one "really secure" server which served as the key server for the LUKS filesystem decryption keys and all other servers simply did some kind of net-boot in which they reached out to this "really secure" server for the keys, could I achieve full-automation on these machines? Since I have to assume that Amazon could (if they wanted) easily extract encryption keys, do I realistically lose any security with this setup? By full-automation, I mean being able to add and remove machines at will without any manual intervention on my behalf or physical access. Additionally, machines should be able to restart on their own and not choke waiting for a decryption passphrase.
Also, is this possible? I thought that there was a way to do something like this, but I'm a little hazy on the subject at the moment.
Best Answer
This is a common use case for FDE where you supply the FDE with a blank password. You then need to configure the FDE bootloader to skip password query, and just boot the computer with a blank password. If using LUKS, you could probably change the source code and recompile LUKS boot loader to just skip password entry and continue with a blank password.
Note that using a blank password for FDE is not insecure in this use case (to make drive erasing easier). The password encrypts a drive-encrypting key, that in turn encrypts the drive. This is to make it possible to change the password without having to re-encrypt the whole drive. Thus, even if the drive-encrypting key is not encrypted or protected, the contents will still be protected when this drive-encrypting key is securely wiped.
When its time to decommission the server, you just wipe the few first megabytes that contain the bootloader, and then verify the bootloader is gone.
Another use case is to put the bootloader on a another device/media that is more easily destroyed than the HDD. When its time to decommission the server, you either retain the boot media or destroy it.
Booting via PXE is also a viable solution. You then put the whole bootloader on a PXE server. You could even flash iPXE ( http://www.ipxe.org ) into the motherboard/network card chip, and then its possible to fetch the bootloader over HTTP/HTTPS.
Some drives also employ this function built-in, where it will generate a random encryption key, store it in flash or on disk platter, and then encrypt the whole drive. When you then supply the ATA Secure Erase command, it will securely wipe the encryption key, making the whole drive unreadable.