Re: A _good_ and valid use for TPM

[phcoder]

Well I don't understand you. When someone speaks about an attack on tpm 
you always consider it not-applicable in your environment. Most of them 
actually are. Like power analysis is able to recover keys in $1000 
margin. With firewire attack you can do it with $10. You can't seriously 
assume an attacker which has less then $100 budget in any application. 
Reading directly from tpm in its current state is just a matter of time. 
However you consider any attack on the scheme coreboot+grub+boot or boot 
virus protection+sha-1+grub+boot with the encryption key in flash memory 
relevant. In both of these scenarios an attacker is unable to read the 
key without a hardware tampering level comparable to the one required to 
recover the key from tpm.
TPM is dangerous and once we use it it's difficult to come back. If it 
could provide something over the two mentioned schemes then I would say 
that it's worth investigating. But as it isn't I say smash you tpm chip.

The only thing that tpm offers over other possibilities is a claim to 
achieve something that is theoretically impossible. Such claims are 
often the case in computer industry. I call it "marketing security". I 
suppose companies and engineers know that their claims are false still 
say it because their salaries depend on how well their product is sold
Regards
Vladimir 'phcoder' Serbinenko
Alex Besogonov wrote:
> On Sat, Feb 21, 2009 at 3:46 PM, Robert Millan <address@hidden> wrote:
> > > Yes, I'm trying to do remote attestation.
> > You're confusing things.  I think you simply want to ensure data integrity, and
> > the TPM doesn't even do that: it simply puts the problem in hands of a third
> > party.
> No, I'm not confusing anything.
>
> > "remote attestation" is only useful when you want to coerce others into
> > running your (generaly proprietary) software.  I hope this is not what you
> > want to do.
> It's exactly what I want to do (minus the 'coercing' part). I want to
> ensure that devices run only my unmodified software (which I consider
> secure) and only in this case provide decryption keys for sensitive
> data. Of course, it done not for DRM purposes, but rather to protect
> sensitive data from theft (real theft, not copyright infringement).
>
> > > Well, I spoke phcoder on Jabber - there might be a way to do this.
> > > He's going to investigate it.
> > This is unnecessary.  Once GRUB supports crypto, it can simply load
> > itself from an encrypted filesystem on disk.  An image can be of
> > arbitrary size.
> Nope. Still no way to test system integrity.
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel