Re: A _good_ and valid use for TPM

[Jan Alsenz]

Hi!

Alright, lets try to make sure everyone is talking about the same things here.

First of all a TPM is not just some kind of secure memory only accessible from
early BIOS, it basically is a small computer. You can only send it commands, and
it can "decide" to reject them, e.g. if you try to read out the endorsement
private key.
(Of course there is always the chance that the TPM has hidden commands to do
that, or the manufacturer already has the keys anyway)

Next, we need to keep in mind, what kind of attack and attacker we're trying to
defend against.
As I see it we have an attacker with relatively low-tech abilities (he cannot
replace chips, break the TPM physically, or knows it's "dark secrets"), who gets
physical access to the machine. So he is basically limited to flashing the BIOS,
 replacing anything, that is written on a disk, controling the network, etc.
I excluded a higher grade attacker, because, if we have one of these, there is
nothing we can do. Any solution, TPM or not, can be broken under these 
assumptions.

Now for, what the TPM can do and is SUPPOSED to do according to the 
specification.
First there is nothing it can do actively, like interrupt or change anything in
the system. It is pretty passive and only acts on request.
The TPM has a number of PCRs (Platform Configuration Registers), where it can
store and concatenate hash values - this is what every stage of a trusted boot
chain has to do.
Every stage has to get a hash of the next one, before it executes it. (The
assumption here is, that the PCRs cannot be tampered with and the stages to it
correctly)
So in the end (after boot) you have a bunch of PCR values, that represent all
the code and data, that was used to boot the system. If you have this and are
sure, that the current configuration is correct, you have a reference value of
the expected system state, which you can use for the following:
- seal a key:
        You can create a key with the TPM and "bind" it to specific values of 
the PCRs,
so it only en/decrypts with it, if these values match.
        You can encrypt any kind of data with this, but the only useful thing 
for boot
is to encrypt a cryptographic key needed to further start the system.
- remote attestation:
        The TPM can proof to another party, that the PCRs have certain values 
(of
course the communication needs to be established by normal software running on
the machine)

The TPM has a few more functions, but I think they are not relevant here.

And now for the ongoing discussion:
(things I didn't comment on should have been answered above)

Alex Besogonov wrote:
> 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.
It could possibly be done, but that is out of scope here.
Regardless of what you use to establish your trust, if someone can extract the
key for your disk encryption from the running system your screwed.

>> And what about cache attack?
> You mean frozen memory chip attack?
No, cache timing. (search for "aes cache timing")

>>> 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.
Actually - it is.
Check the "TCG PC Client Specific Implementation Specification for Conventional
Bios" or "TCG PC Specific Implementation Specification" at
https://www.trustedcomputinggroup.org/specs/PCClient/
and look for CRTM (Core Root of Trust for Measurement)

>>> 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.
Well, it is a bit more, but it's definitely not just obfuscation. Actually it's
pretty well documented what it's supposed to do (all the specification is
available, there is an open-source emulation implementation of it).
What you are referring to, is that you don't trust it to have ONLY this
functionality, but you can make the same argument for every part of your PC! Are
you sure, there is nothing in your network card, CPU or hard drive, that can be
used against you?

>> 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.
I am very sure of 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.
Yeah, but an attacker could patch that out too.

> 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.

Greets,

Jan

signature.asc
Description: OpenPGP digital signature