Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

On Wed, Aug 19, 2009 at 1:00 PM, Emmanuel Fleury<address@hidden> wrote:
> Dear all,
>
> I know this is a quite sensitive topic and I'm really not willing to
> start a new flame-war about it. I just want to know the exact status of
> it and what is the (official) position of the GRUB team on the TPM support.
>
> Last discussion about the TPM issue was in February (see:
> http://lists.gnu.org/archive/html/grub-devel/2009-02/msg00217.html) and
> it ended up with a kind of statu quo.
It wasn't a status quo. TPM is a harmful technology which can't be
accepted in any software conscious of freedom. I know that TPM can
provide features some people consider useful but:
1) Making use of TPM you become dependent on good will of TPM
manufacturer. You can never know if or when the TPM manufacturer or
someone connected with them will ask you to use remote attestation to
prove them that you use only the software they signed and that they
effectively control your computer. Put in simple words it's like
locking you with your computer in a prison cell and going in this cell
every time you use your computer and relying on someone else to gently
open you the door every time you need it. It this case even if you
really trust the person holding cell keys it's not a freedom.
You can argue that there are several TPM manufacturers and none will
do any nasty things but you forget about TPM consortium and that
actions around TPM are coordinated and that harmful features are a
part of TPM specification.
2) The similar features can be implemented without resorting to TPM by
using coreboot and make every stage verify the signature of every next
stage. Signature handling will be done in grub when crypto patches are
merged and someone (perhaps me) will have enough time to implement
signatures (I already implemented RSA once but unfortunately I deleted
my compile directory which also had sources). This is like locking
your computer and keeping the key.
3) TPM manufacturers claim to achieve the goals like being
tamperproof. This is simply not possible. Everything is tamperable.
It's just the question of effort. Someone with electronic microscope
and enough time and material would be able to recover TPM key. And
electronic microscope is something you can have access to if you have
a diploma or connections. Even without such equipment it's just a
question of time before a fatal flow in TPM is discovered and
published. After that point TPM wouldn't be very different from WEP.
One of such flows is very known: firewire. Anyone with physical access
to your computer can add a firewire card to it and dump RAM through it
and have any information he wants.
Any cryptographical implementation claiming to achieve impossible has
a weakness. If it's open-source it clearly states "weakness is this"
and explains whole functionality. Commercial implementations would
just close the specifications, hide the weakness and sell as much as
they can before the weakness is found out.
It's like trusting someone something is steel just because it looks like such.
In short tamperproof is unachievable. If your goal is to delay the
attacker, obfuscate your system yourself. This way you have the
advantage that the attacker can't just read publication and see the
weaknesses of a particular system. If your goal is to deflect physical
attacks the only way to do so is to restrict physical access. Put good
locks and guards around your computer or bury it and put concrete
around it or use any of 1000 ways to physically protect the computer.
>
> I just propose to expose the consequences of TPM support for GRUB, first
> in a technical point of view and then on an ethical one. Then, I hope
> the GRUB team will write his official position on the TPM support.
>
GRUB is GNU project and GNU's position is detailed here:
http://www.gnu.org/philosophy/can-you-trust.html
>
> 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.
>
Michael Gorven has ported libgcrypt SHA-1 and other hashes to grub2.
Additionally SHA-1 is depreceated and flawed.
> 2) Extend the PCR register (TPM_SHA1CompleteExtend command) with the
> SHA-1 digest.
>
Why would we need a chip to check if SHA-1 matches if we can use signatures?
>
> 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.
You propose to check that our checksum in PCR is ok but you already
assume GRUB wasn't tampered. If you assume grub wasn't tampered no
need to checksum. If you don't it's useless to checksum.
>
> 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...
>
Signatures give that
>
>
> 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...
Why do I as user need someone else to check my computer?
>
> [Note that, according to the TPM specifications, it is always possible
> to clear the TPM without password under physical presence assertion
> (TPM_ForceClear command, Part 3, p.29) and thus the user will also be
> able to use the TPM (if you are ok to loose all the data stored on the
> platform).]
If you assume attacker has no physical access to a machine checking
signatures on updates recieved from network and proper permission
model is enough to deflect any attack
>
> On the other hand, there is a quite high step between the partial
> support that I've described before and the full support with remote
> attestation... (and users may require this partial support for their own
> usage).
Usage like? We're speaking about security here and any serious secure
system has to answer questions:
1) "Which attacks is it supposed to deflect?"
2) "Does it deflect those attacks?"
3) "How much does the security costs?" (in money, ressources and inconvinience)
4) "Which other holes does it open?"
(inexact quotation of Bruce Schneier)
Just adding crpytography layers, pronouncing "AES" three times a day
or putting autographed picture of Bruce Schneier on your computer
doesn't enhance the security.
>
> Now, the question whether one shouldn't support a technology because it
> may lead to evil usage is something that should be solved inside the
> GRUB team (and I believe that the GRUB team has already solved this
> question out).
It's not like just "can lead". Remote attestation is a part of TPM
spec. It's like saying nuclear bombs aren't a problem just because
"they can explode".



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git