From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 23 19:05:34 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97DB916A503 for ; Wed, 23 Aug 2006 19:05:34 +0000 (UTC) (envelope-from david@madole.net) Received: from d.omd3.com (mx1.omd3.com [69.90.174.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 735F643D60 for ; Wed, 23 Aug 2006 19:05:31 +0000 (GMT) (envelope-from david@madole.net) Received: from static-66-212-193-19.myeastern.com ([66.212.193.19] helo=david) by d.omd3.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.54) id 1GFy3D-0007hr-Ro; Wed, 23 Aug 2006 15:06:07 -0400 Date: Wed, 23 Aug 2006 15:05:00 -0400 From: "David S. Madole" To: 'Jeff Palmer' , "'hackers@freebsd.org'" X-Priority: 3 X-Mailer: Bynari Insight Connector 3.1.0-0427200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <20060823190531.735F643D60@mx1.FreeBSD.org> Cc: Subject: RE: Geli questions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 19:05:34 -0000 > 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