code signing/secure boot sequence (Re: [OLPC-devel] Re: wireless/libertas: miscellaneous fixes)

[Adam Back]

I'd say (wrt to wanting a copy of the same software set as your
trusted friend has), what you want is a copy of what your friend
thinks he has.  (Not what he actually has as that could include
viruses etc).  ie you want a way to receive packages store-and-forward
via relatively untrusted machines, such that they cant be modified
without changing their authorship.

So I think one should be able to do that no?  (Get a copy of what he
thinks he has) if there is some packager or author authentication.  So
if you get firefox-1.5.i386.rpm it will be unmodified.

So in practice the user would have no reason to tamper with his .rpm
cache directory (no reason rebuild rpms with software patches eg), so
it should not fail.

Now obviously a user could cause it to fail intentionally, but they
can do that anyway, even without code signing.


About the definition of trust -- its true SSL particularly is crappy
as it means you end up with someone -- like the CAs -- being trusted
by everyone.  But with RPM it is actually signed with PGP, so there is
a web of trust.  Perhaps a distributor or package builder can at least
sign the binaries they produce?  (Its sort of what happens, if I
subscribe to yum repo of livna or other add ons, its up to me to check
their keys or live with the warnings about unverified signatures;
similarly to tolerate installing unsigned rpms if I choose).

Adam

On Tue, Jul 11, 2006 at 12:05:24AM -0400, Christopher Blizzard wrote:
> Adam Back wrote:
> >Chris Blizzard wrote:
> >>You don't have to drive it from a program that's contained in the
> >>BIOS - you just need to have enough set up to be able to load a
> >>program from somewhere else that can handle the real re-install.
> >
> >I think you'll want to sign the images in this install process.  Can
> >you use the RPM code signing to do it?
> >
> >Seems like you'll be doing something a bit like the secure boot
> >sequences used by the TPM -- load a BIOS, it fetches the installer
> >over the network, verifies a signature on it, then goes to the next
> >stage; each stage verifying signatures on the next...
> >
> >Adam
> 
> I'd rather avoid signing for a couple of reasons -
> 
> 1. It requires knowing a huge amount about trust relationships.  Much 
> like in the SSL world, signed code/certificates require that you trust a 
> third party.  And what's the failure case when you load unsigned code?
> 
> The best trust relationships are those of the person sitting next to 
> you.  You know that they have a certain image that you want.  And you 
> have to work together using the client (the install target) and the 
> server (the install server) to do an install.
> 
> My one and only concern with this is the virus problem.  It's a real 
> concern, too.  We need some sharp thinking on it.  But I don't want to 
> resort to a TPM-like system to try and eradicate it.  I suspect that if 
>  a person's base system libraries stick to the unix model (that is, 
> your system is read only) that a lot of virus problems are avoided.  And 
> assuming that you're using that as the base image for your re-install 
> you're going to be in good shape.
> 
> 2. It all feels pretty orwellian to me.  We're building a free system 
> here, I want that freedom to extend to the install experience as well. 
> If someone comes along and builds a better mousetrap OLPC experience, 
> they should be allowed to install it.
> 
> This doesn't mean that we shouldn't use checksums for data integrity and 
> some kind of PIN system to figure out who we're talking to for the 
> install experience.  But I don't want the what-ifs to end up creating a 
> system that's unusable and impractical to implement and support either. 
>  We're trying to create a great experience for our users here; not 
> something that is mathmatically proven to be impossible to crack.
> 
> --Chris