Re: A _good_ and valid use for TPM

[Alex Besogonov]

On Thu, Feb 19, 2009 at 9:30 PM, phcoder <address@hidden> wrote:
>> Yes, but that's way too hard.
> Sure? There was a demonstration when rsa key was recovered just by plotting
> variations on powerline of usb port
TPM performs encoding/decoding, and I consider it secure.

I don't think it's possible to recover the symmetric key used later
during normal system operation.

> And what about cache attack?
You mean frozen memory chip attack?

>> That's possible, but again I consider this not critical. BIOS itself
>> is checksummed and checked by the root of trust.
> Isn't bios (or part of it) the root of "trust"
As far as I understand - no.

>> Why?
> Because I don't want support this technology. TPM=obfuscation=unsecurity.
No. TPM is just a secure way to store keys, nothing more. It can be
used for good and bad.

> And as an opensource and open security fan I can't claim to have solved an
> impossible problem. But if you want to use obfuscation schemes it's your
> right
I want a reasonably secure scheme that DOESN'T use obfuscation.

> You assume that noone will develop hypervisor able to fool tpm bios. One
> could powercut the tpm chip (similar to how a resistor is remove to avoid
> burning efuses in xbox) then power would be reestablished to it and bios
> would be executed on hypervisor which will retrieve the keys.
Would not work. Or rather it'll require uber-precise timing, a lot of
soldering and access to private data of the mainboard developer.

> Actually you
> can trust tpm only as much as you trust in obfuscation power of bios. Only
> obfuscation prevents attacker from disconnecting tpm and reading keys from
> it. And there are only few types of tpm. Sooner or later someone will figure
> their interface. Then it can be read by special usb adapter
TPMs are fairly well engineered, it requires several magnitudes more
time to crack it than any pure software security system.

>> Actually, I can probably even formally prove this assumption.
> I really don't see you point. With my proposition mbr still can be verified
> by tpm but grub2 needs to know nothing about tpm as long as it ensures it
> doesn't load any unsigned modules.
First, I don't think it's possible to implement SHA-1 hashing in MBR -
there's probably just not enough space left in 512-byte code segment
for that.

Second, the only safe action non TPM-aware MBR can perform if it
detects tampering is just shutting down hard. Everything else is
dangerous.

Third, it would be nice to be able to measure (attest integrity) of
other files, but that's just nice and not really necessary.

> This approach is more versatile. It can
> be used also for e.g. checking that debian install is really from debian.
> And having experience with manufacturers supplying buggy hw and sw  tend to
> avoid solutions directly relying on hardware when another implementation is
> possible
TPM will be used in the most minimalistic way possible. I'll even add
pure software signature checking support (which can be useful for
another purposes like checking that kernel is not damaged, etc.).

> Which collaboration other than not loading anything unchecked does your
> scheme need from grub?
Mainly, communicating with TPM in MBR to tell it that the next stage
has passed checks.

> From readme of trustedgrub the only thing it does is checking integrity
Yes.

>> PS: please, can you CC me when you answer my posts?
> Could you come to irc channel or meet me at jabber/gtalk?
Feel free to contact me on Alex.Besogonov _atttttttt___ gmail.com in Jabber.