From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 00:30:22 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 E423516A4CE for ; Thu, 16 Sep 2004 00:30:22 +0000 (GMT) Received: from mail.praemunio.com (mail.praemunio.com [66.179.47.216]) by mx1.FreeBSD.org (Postfix) with SMTP id 6357A43D49 for ; Thu, 16 Sep 2004 00:30:22 +0000 (GMT) (envelope-from frank@knobbe.us) Received: from localhost (HELO mail.knobbe.us) by localhost with SMTP; 15 Sep 2004 19:30:21 -0500 Received: from localhost (HELO ??) by localhost with SMTP; 15 Sep 2004 19:30:20 -0500 From: Frank Knobbe To: hackers@freebsd.org In-Reply-To: <200409072022.i87KM7Kf049770@wattres.Watt.COM> References: <200409072022.i87KM7Kf049770@wattres.Watt.COM> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Ju6X22j4rxtHuheldqk6" Message-Id: <1095294619.633.206.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 15 Sep 2004 19:30:19 -0500 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 00:30:23 -0000 --=-Ju6X22j4rxtHuheldqk6 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-09-07 at 15:22, Steve Watt wrote: > Having the password compiled in to something that's necessarily clear-tex= t > on the same media? Sorry for being late... I'm still catching up on piles of email :) 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. 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... :) 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 Any thoughts? Regards, Frank --=-Ju6X22j4rxtHuheldqk6 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBSN6bJjGc5ftAw8wRAkDBAJ4mkmkrgooun82LbbF22zNeuX6duwCdE2O8 LHTMD7QA9YGj/2zq18EuW9A= =DMmR -----END PGP SIGNATURE----- --=-Ju6X22j4rxtHuheldqk6--