0

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.

migrated from security.stackexchange.com Jan 16 '15 at 12:54

This question came from our site for information security professionals.

  • Why not? Windows can do this when using Active Directory to manage BitLocker keys. – Michael Hampton Nov 6 '16 at 4:09
2

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.

1

Automating VMs with FDE (Full Disk Encryption) except for /boot partition can be done.

Here are a few options, all using standard LUKS encryption on Linux:

  1. Hardcode the LUKS passphrase in the initramfs (Golden Image)
    • This can be changed after deployment and a KVM used to enter it at every reboot after that.
  2. Install initramfs ssh server, e.g. dropbear
    • Would require ssh login and key entry before full boot. Could be automated.
  3. Use client/server setup to pass keys, e.g. Mandos
0

Maybe I didn't get your answer or I am a n00b, but couldn't you make a Golden Image that already has Encryption then deploy using Zero touch? Manage using something like Puppet or SCCM,but what i find very useless is that you want the pass-phrase to be input automatically (some code could surely be made for that) but then it makes the server less secure and defeats the purpose of the encryption.

  • It isnt useless. If you read the Original question, its about secure wipe. During normal usage, theres no need to protect the data, thus the encryption can have a auto random password. But when its time to decommission the server, you dont need to securely wipe the whole drive. You just need to wipe the sector(s) where the key is stored, preferable with gutmann 35. Then the rest of disk can be erased with dd if=/dev/zero of=/dev/(diskname) bs=1024 . If someone recovers one of the zeroed sectors, it wont matter since they are encrypted with a key that has been gutmann 35:ed. – sebastian nielsen Jan 26 '15 at 3:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.