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 <r...@aybabtu.com> 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
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel