> From: Jeff Palmer > Sent: Wednesday, August 23, 2006 2:17 PM > > The idea: I'd like to use geli to encrypt *everything* on > the disk. So if someone (a competitor maybe) removes the > disk from the machine, he can't gain any data off of it > easily. I know nothing is 100%, but why make the process > easy for him? > > The plan: the appliance would be persistantly connected to > an SSL based VPN server at my central office. (Think OpenVPN > server) I'd like a way for geli to encrypt the entire disk, > but fetch the key from a server located on the VPN. this > would require the appliance to boot up, access the internet > (static IP), access the VPN (ssl key'd) and fetch the key > that geli needs.
Did I miss something there or do you have a chicken-and-egg problem? How are you going to encrypt the entire disk, boot from it, and _then_ retrieve the key? You need the key to read the disk just to boot. I also don't see the value added by using the VPN to get the key. Couldn't someone run your key-retreival code by hand after booting off another media? How is it more secure than just putting the key on the disk? An HTTPS GET would be a lot simpler than VPN and a lot more likely to get through any firewalls upstream of your box anyway. Most of the environments I've worked in would not be too happy about installing an appliance that has deliberately obscured it's inner workings and that persistently connects a VPN outside of the organization. Sounds like a completely unauditable back-door. The only mechanisms that I have seen for doing things like this that pose more than a trivial obstacle for someone involve modifying the hardware. One way is to modify the BIOS in the machine to contain the decryption key which is passed to the boot loader through some covert mechanism such as patching the boot sector after loading it into memory (which then passes it on). Or encrypt all the sectors on the disk including the boot loader and build the decryption, including the key, into the BIOS. The bottom line is that it will be roughly as difficult to break whatever mechanism you come up with as it is difficult for you to implement it in the first place. You really don't have much choice but to rely on obscurity and treachery and the lower-level you can make the code (like BIOS and boot loader) the harder it will be to break. David _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
