From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 03:24:12 2004 Return-Path: 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 38BCC16A4CF for ; Thu, 16 Sep 2004 03:24:12 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id E66A043D67 for ; Thu, 16 Sep 2004 03:24:11 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id E031B651FA; Thu, 16 Sep 2004 04:24:10 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31208-03-2; Thu, 16 Sep 2004 04:24:10 +0100 (BST) Received: from empiric.dek.spc.org (adsl-64-171-184-46.dsl.snfc21.pacbell.net [64.171.184.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 25826651F4; Thu, 16 Sep 2004 04:24:09 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id ADF9563B3; Wed, 15 Sep 2004 20:24:06 -0700 (PDT) Date: Wed, 15 Sep 2004 20:24:06 -0700 From: Bruce M Simpson To: ctodd@chrismiller.com Message-ID: <20040916032406.GC7413@empiric.icir.org> References: <200409072022.i87KM7Kf049770@wattres.Watt.COM> <20040916010317.GN1001@straylight.m.ringlet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: hackers@freebsd.org cc: Frank Knobbe Subject: Re: Booting encrypted X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2004 03:24:12 -0000 Hello, It really depends on how far you want to go to protect the product, and what your threat model looks like. On Wed, Sep 15, 2004 at 07:17:33PM -0700, ctodd@chrismiller.com wrote: > My main objective is to prevent someone from removing the drive and > mounting it from another *nix system and turning it into a unix toy > (turning on shell access, etc) which it's not designed to be, as well as > getting at the application and configuration. By having encryption done by > the loader in such a way that the key can not be derived, protects the > entire filesystem from tampering. Nothing this appliance is going to be > doing requires super fast disk i/o so encryption is not an issue. In fact > I've even considered using flash instead of a drive, but the same issue is > there. This is more or less what I'd proposed. The key element here is that if your key for the hard drive is stored IN ANY WAY on the hard drive, particularly in or near the loader, your appliance would be cracked fairly easily. Using TCPA, you could lock down your device in this way, and extract the symmetric key for the media from nonvolatile secure storage on the chip once the OS has logged into it. Of course you'd have to sign the OS image in such a way that booting it unlocked the secure storage. I haven't researched this point in depth but I think it may be possible. The TCPA chip generally hangs off the ICH chip in Intel chipset based systems, on the LPC bus PCI function; it's possible that you could retrofit this to a board if the existing board design does not have TCPA pinned out, by pinning out LPC, or by pinning out ISA and slotting it in on a board. Regards, BMS