> Jurvis LaSalle wrote: > wouldn't unattended boot require the system to decrypt the hdd itself and > thus hold the keys itself? the req seems antithetical to FDE unless i'm > missing something...
I made my own home-brew key-server to provided unattended boot capability for servers as follows: - Set up a small Linux server on the LAN with a USB thumb drive. (It's a cheap raspberry pi but can be any old machine not used for anything else.) - Use cryptsetuo to create a LUKS volume on the thumb drive, create a keyserver role account, and put your various servers' disk-volume passphrases into subdirectories on the drive. - On your servers, set up an fstab entry to mount the thumb drive after network startup, and add the_netdev keyword to the fstab entries for each of your local volumes that you want encrypted. The easiest method I found to mount the thumb drive is volume type "sshfs", if I set up the keyserver role user's ssh keypair in the root's ssh config. By this method, you can activate key service on that central key server for however long you want; as soon as you dismount the thumb drive, your encryption keys are secure. And you can have a separate pass phrase for every volume. Don't forget to make spare copies of that all-important thumb drive! This works for my tiny home setup but I could see it working just as well for a 500-instance AWS cloud setup, assuming you set up the VPCs with vpn tunnel back to that thumb-drive server (your MacBook, say, if you configure a reserved private IP address for it). -rich
_______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
