Date: Wed, 23 Aug 2006 15:05:00 -0400 From: "David S. Madole" <david@madole.net> To: 'Jeff Palmer' <questions@totaldiver.net>, "'hackers@freebsd.org'" <hackers@freebsd.org> Subject: RE: Geli questions Message-ID: <20060823190531.735F643D60@mx1.FreeBSD.org>
next in thread | raw e-mail | index | archive | help
> From: Jeff Palmer > Sent: Wednesday, August 23, 2006 2:17 PM >=20 > The idea: I'd like to use geli to encrypt *everything* on=20 > 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=20 > an SSL based VPN server at my central office. (Think OpenVPN=20 > server) I'd like a way for geli to encrypt the entire disk, =20 > but fetch the key from a server located on the VPN. this=20 > would require the appliance to boot up, access the internet=20 > (static IP), access the VPN (ssl key'd) and fetch the key=20 > that geli needs. Did I miss something there or do you have a chicken-and-egg problem? How ar= e you going to encrypt the entire disk, boot from it, and _then_ retrieve t= he 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 f= irewalls upstream of your box anyway. Most of the environments I've worked in would not be too happy about instal= ling an appliance that has deliberately obscured it's inner workings and th= at persistently connects a VPN outside of the organization. Sounds like a c= ompletely unauditable back-door. The only mechanisms that I have seen for doing things like this that pose m= ore 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 whi= ch is passed to the boot loader through some covert mechanism such as patch= ing 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 m= echanism 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 an= d treachery and the lower-level you can make the code (like BIOS and boot l= oader) the harder it will be to break. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060823190531.735F643D60>