From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 01:02:47 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 B73F216A4CE for ; Thu, 16 Sep 2004 01:02:47 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id B703443D41 for ; Thu, 16 Sep 2004 01:02:46 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 5005 invoked from network); 16 Sep 2004 01:00:10 -0000 Received: from unknown (HELO straylight.m.ringlet.net) (217.75.134.254) by gandalf.online.bg with SMTP; 16 Sep 2004 01:00:10 -0000 Received: (qmail 38292 invoked by uid 1000); 16 Sep 2004 01:03:17 -0000 Date: Thu, 16 Sep 2004 04:03:17 +0300 From: Peter Pentchev To: Frank Knobbe Message-ID: <20040916010317.GN1001@straylight.m.ringlet.net> Mail-Followup-To: Frank Knobbe , hackers@freebsd.org References: <200409072022.i87KM7Kf049770@wattres.Watt.COM> <1095294619.633.206.camel@localhost> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iK/wEI4vkfDmI6Zw" Content-Disposition: inline In-Reply-To: <1095294619.633.206.camel@localhost> User-Agent: Mutt/1.5.6i cc: hackers@freebsd.org 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 01:02:47 -0000 --iK/wEI4vkfDmI6Zw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 15, 2004 at 07:30:19PM -0500, Frank Knobbe wrote: > On Tue, 2004-09-07 at 15:22, Steve Watt wrote: > > Having the password compiled in to something that's necessarily clear-t= ext > > on the same media? >=20 > Sorry for being late... I'm still catching up on piles of email :) >=20 >=20 > Instead of having a plaintext password on the same media, how about a > mechanism that reads the CPU's serial number, or some other hardware > dependent number that can not be read by users on a system. If the drive > gets removed from the system, the attacker would have a challenge. >=20 > Of course you have to be careful before you replace failed hardware that > is used to derive the key :) Don't replace the failed CPU before you > decrypted... no wait... uhm... :) Okay, how about an offline copy of > the number in case of hardware failure... :) >=20 > Seriously though, tying the boot process to a hardware dependent value > that is not accessible from within the booted system might be something > to consider.=20 >=20 > Any thoughts? One word that Bruce M. Simpson already mentioned: TCPA :) Well, it's not exactly what you describe, but it is basically what you describe done right - no offense intended, of course, I mean that the TCPA specs at http://trustedcomputinggroup.org/home seem to provide the benefits that you are looking for in a framework that mostly alleviates the problems. Of course, the key word is 'mostly', and there is more to TCPA than just encrypted booting, and there are lots of people who disagree with the 'more' part, but still you might want to take a look at it. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am the meaning of this sentence. --iK/wEI4vkfDmI6Zw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBSOZU7Ri2jRYZRVMRAk5QAKCLepMfmlIpXmBybMDL+32JVrJG9ACgrBWI 0UfYZvlKLnJkdoWHgF7yH5A= =xpbl -----END PGP SIGNATURE----- --iK/wEI4vkfDmI6Zw--