grub-devel
[Top][All Lists]
Advanced

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

Re: A _good_ and valid use for TPM


From: Isaac Dupree
Subject: Re: A _good_ and valid use for TPM
Date: Wed, 18 Feb 2009 09:52:10 -0500
User-agent: KMail/1.10.3 (Linux/2.6.27-11-generic; KDE/4.1.3; x86_64; ; )

Alex Besogonov wrote:
> There's no way to break this chain of trust without hacking TPM (which
> I consider very unlikely)

fair to say "unlikely"

> doing uber-dirty hardware tricks (like
> modifying RAM on-the-fly using DMA from rogue PCI devices)

yeah, it's probably technically possible, but enough work to do that it's not 
worth guarding against.

But guess what?  While your system is running, they can take out your RAM and 
read it (disk-encryption key and all) before the RAM forgets its contents, see 
e.g.
http://blogs.zdnet.com/security/?p=900

> or
> exploiting some local vulnerability (which is rather unlikely).

maybe.  But how do you patch security vulnerabilities in e.g. the GRUB 
install, if modification = tampering?  (I guess there's a way to do it, 
though.)

> >If you suppose that your attacker is unable to tamper the hardware then
> >bios and grub password is all you need. If you suppose that he can then
> >you can't even trust your ram modules. It can be tampered in many ways
> >like serving hacked bootloader or just being non-volatile then an
> >attacker can read the key from memory.
>
> I'm trying to guard against attacker who can _steal_ the server itself
> and/or tamper with the hardware.

which is very difficult.  Why do you have to reboot, though? and is there some 
way you can store the key locally in those cases, without compromising it 
further?

> PS: please, at least read the relevant specs before calling TPM
> 'Treacherous'.

the ones that say to keep the keys in the hands of the manufacturers?(no I 
haven't read the specs either, maybe Robert Millan has though)

-Isaac





reply via email to

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