l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to add confinement to the Hurd?


From: Bas Wijnen
Subject: Re: How to add confinement to the Hurd?
Date: Mon, 1 May 2006 15:30:48 +0200
User-agent: Mutt/1.5.11+cvs20060403

On Mon, May 01, 2006 at 06:20:14AM +0200, Pierre THIERRY wrote:
> > Well, without a TC chip in the system the system-implemented
> > confinement check relies on the good will of the machine owner.
> 
> Which is way more than needed in some use cases of confinement.

In the absence of a trusted machine owner and a TC chip, there's only one
reasonable thing to do, and that's not using the machine.

> > Do you know how "secure booting" works?
> 
> I think I know remotely. But I'll gladly read an extensive description
> of the process, and I'm absolutely sure it would be a beneficial to some
> discussions about TC and Hurd.

I'll give it a try.  I'm not at all an expert, and one of the reasons I'm
writing this is that it may be corrected. :-)

First of all, the TC chip can do encryption and signing of pieces of code.  It
does this using a private key which is not known to anyone at all, and cannot
be extracted.  The corresponding public key is public (duh!) and signed by the
chip manufacturer.

Also, there is a sort of "stack" in the TC chip, which gets reset at system
boot, and to which signatures can be added.  They cannot be removed, and the
only way to clear the stack is by rebooting the machine.  This stack can be
inspected.  (This is a part that I'm particularly unsure about.)

The first part of the bios is what gets executed at boot time.  This part of
the bios is not flashable.  It computes the checksum of the bios (including
the flashable part) and puts it on the stack of the TC chip.  Then it
continues from the flashable part.

The bios will load the boot loader into memory.  Before starting to run the
code, it is signed by the TC chip, and the signature is stored.

The boot loader will load an OS.  The OS is loaded into memory, it is signed,
and the signature is put in the chip.

Now we have an OS running.  It makes a network connection with Disney in order
to play a DRM'd movie.  Disney will require to talk over a line which is
encrypted.  The system sends the public key of the TC chip to Disney.  Disney
checks the signature on it (from the manufacturer) and knows that it is a real
TC chip public key.  They then send their own public key to the machine,
encrypted to the TC chip key.  The OS receives this key from the chip (which
decrypts the communication) and uses it to talk to disney.  It also sends the
TC chip stack to Disney.  Disney thus has signatures of all parts of the boot
process (the bios, the boot loader and the OS itself (that is, the kernel and
the TCB at least)), and it can check them against known good versions.

If any of the boot programs is not a version that is trusted by Disney, the OS
will be unable to tell them otherwise, because the TC chip will not lie to
them about the checksums.  The OS can at most be silent about things, in which
Disney will refuse to proved the movie.

Again, people who know more about this please correct it.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]