[52351] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: TPM & disk crypto

daemon@ATHENA.MIT.EDU (=?UTF-8?B?SXZhbiBLcnN0acSH?=)
Fri Oct 13 09:14:49 2006

X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Thu, 12 Oct 2006 14:00:13 -0400
From: =?UTF-8?B?SXZhbiBLcnN0acSH?= <krstic@solarsail.hcs.harvard.edu>
To: "Travis H." <solinym@gmail.com>
Cc: Adam Back <adam@cypherspace.org>,
	"James A. Donald" <jamesd@echeque.com>, cryptography@metzdowd.com
In-Reply-To: <d4f1333a0610101243k287bf83fxab493ff53db99f09@mail.gmail.com>

Travis H. wrote:
> I can validate everything else, but as long as the BIOS is
> motherboard-specific and closed source, I don't see why I should trust
> it.  We need to get rid of this legacy crud.  LinuxBIOS is a good step
> but unfortunately it is only supported on a few motherboards. 

We're shipping LinuxBIOS on the One Laptop per Child machines.

> No BIOS
> I know of has a semblance of security, given temporary physical access
> to the machine.

I came up with a scheme that lets us do a "secure BIOS" without a TPM;
bypassing it without a PLCC would be extremely difficult. I'm not yet
certain if we'll end up shipping a PLCC socket on the final hardware,
but if not, I suspect you'd be hard-pressed to do much to the BIOS
protection even with physical access, short of un-soldering and
re-soldering a different SPI flash chip to the motherboard. That was
explicitly not part of my threat model.

-- 
Ivan Krstić <krstic@solarsail.hcs.harvard.edu> | GPG: 0x147C722D

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

home help back first fref pref prev next nref lref last post