Re: How to add confinement to the Hurd?

[Jonathan S. Shapiro]

Bas:

There are about a thousand tiny details that you skipped, but your basic
description of how TPM and TCPA works is extremely clear and basically
accurate in its summary.

Many people have found this difficult to do, so I should add:
congratulations!

One small correction, which does not alter the substance of your
description: the TC chip does not do encryption of code. It does
signing, but not encryption. In principle, it *could* do encryption, but
the TC chip has very little computational power. It is generally agreed
among the various TC-style chip designers that encryption function
should be left on the host (which has, in any case, been authenticated,
so this is safe).

One addition: the TC chip also provides a small amount of "secure
storage". These are registers that are not readable unless the OS that
booted is the same OS that stored them (though there are provisions here
for upgrade). This is the mechanism that supports secure local disk
encryption. It is also, unfortunately, the mechanism that lets
Microsoft's (or anyone else's) music player be able to play content that
your OS will not permit any other player to play.

shap


On Mon, 2006-05-01 at 15:30 +0200, Bas Wijnen wrote:
> 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
> 
> _______________________________________________
> L4-hurd mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/l4-hurd