grub-devel
[Top][All Lists]
Advanced

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

Re: TPM support status ?


From: Duboucher Thomas
Subject: Re: TPM support status ?
Date: Wed, 19 Aug 2009 18:33:52 +0200
User-agent: Thunderbird 2.0.0.22 (Windows/20090605)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> 1) Technical Aspects
> ====================
> 
>>From a purely technical point of view, the TPM support in GRUB is about
> the "Trusted Boot" with a partial support and a full one.
> 
> Partial support means that GRUB is able to (TPM commands are taken from
> "Part 3 - Commands", see further for references):
> 
> 1) Perform a SHA-1 digest (TPM_SHA1Start and TPM_SHA1Update commands) of
> the kernel that is intended to be loaded.
> 
> 2) Extend the PCR register (TPM_SHA1CompleteExtend command) with the
> SHA-1 digest.
> 
I advise you to read the documents named "PC Client Implementation for
BIOS" and "TCG EFI Protocol Specification" which defines how these
functions are to be implemented on an IBM/PC compatible hardware that
supports the TCG specifications. ;)
All of the functions defined there can be easily made using functions in
the BIOS or EFI (i.e. BIOS INT TCG_CompactHashLogExtendEvent). You can
also have a look at the Trusted Grub and/or Grub IMA project for an
insight with an older TCG specification.

> 3) Read the PCR (TPM_PCRRead command) and compare it to a recorded value
> of a previous (safe) boot. We assume that the previous link of the chain
> of trust (BIOS?) has already checked that GRUB hasn't been tampered
> before starting it.
> 
No, no, no and no! :)
This is a typical hen/egg problem: If you compare the PCR value with a
previously reccorded value, then this value must be part of the chain of
trust (if not, then you have no chain of trust and your TPM is useless);
If it is part of the chain of trust, it must be measured into one of the
PCR and it will modifiy the PCR values.
Try to think about a file that stores its own md5 sum, it'll give you a
headache.

> If this part fail, GRUB should stop here and tell the user that the
> kernel has been tampered. If everything went ok, GRUB get back to the
> usual way...
> 
True, but the TPM doesn't only check the kernel, it also works when
someone changed the MBR for instance (or less trivial, a PCI ROM).

> A full support of TPM means that GRUB should also be able to ask to a
> remote authority if the content of the PCR is still ok... Technically,
> it would be stupid to include a full TCP/IP stack (or whatever network
> protocol) into GRUB, so it would be much more realistic to just leave it
> to the OS and only pass the needed data to it.
> 
I've found no public implementation of remote authentication using TPM,
except from a proof of concept that makes use of a Java-based servlet.

> [Note: I have to admit that I don't see how to deal properly with this
> full support as you somehow need to rely on some links of the chain of
> trust that may have been tampered. Implementing this step may require
> quite a lot of thinking (and personally, I don't think it worth it...
> but it's only my humble opinion).]
> 
You can achieve this using TPM_Quote iirc, but I haven't studied this.
However, this is a very specific support for very specific applications
(like MTM), and I don't think it's usefull to see this in a bootloader
... This is highlighted by the fact that BIOS and EFI specifications
only stick to the SRTM and does not implement complex operations, only
leaving pass-through capabilities.

> 2) Ethical Aspects
> ==================
> 
Every technology has its evil uses, so does TPM. However, there's a very
large gap between currently implemented solutions and what you suggest.
Of course, someone may use TPM in a software suite that completly lock
down your computer. However, I don't think that it's the TPM's fault;
its just a technology. I would rather consider it's the fault of
countries with laws that tolerates these behaviours ...

The goal of TPM is to be used in broader security schemes. Its use is
only to make sure that the integrity of the system was preserved. This
would prevent an attacker from inserting a stealth PCI device which can
leaks data using SMM.

As an ending note, I am much more less confident in Intel's processor
microcode that is patented than in a chip I can deactivate and live
without it.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqMKXAACgkQBV7eXqefhqgLiwCgnQf3/vAS05SaFQhFm8op44y7
9+oAoIzZouLxPa16A2d+L8VTFNPlZit6
=zq07
-----END PGP SIGNATURE-----




reply via email to

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