From: RB (aoz.syngmail.com)
Date: Thu Nov 27 2008 - 00:18:47 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Wed, Nov 26, 2008 at 05:52, Matthijs Koot <matthijskoot.biz> wrote:
> You mention that you were looking at TPM "while trying to solve the
> (...) physical presence security problem". Although you didn't claim
> that TPMs provide any solution there, I'd like to emphasize (for other
> readers) that according to the TCG-specs, TPM is not designed to protect
> itself against non-"simple" hardware attacks:

:-) I try not to go off half-cocked, and it would have been foolish
to claim a TPM guards strongly against physical compromise. It is my
understanding that If used properly, they can improve defense against
physical compromise to a level slightly less than that of a smartcard,
advantage going to the smartcard since they may be readily removed and
separately secured.

> So 1) being able to manipulate the (locality) modifier is bad, and
> 2) TPM only provides modest protection against attacker's with physical
> access. The TCG-people confirm this: TPM is intended to protect against
> software-based threats (which it may not do very effectively, as
> Joanna's post suggested, as long as integrity checks can only be done at
> boot/load-time).

The key is maintaining the chain of trust, and the TPM is only a
facility used to aid the process. Mild physical protection aside, it
doesn't know or really care whether a link in the chain is
compromised, only what each link reports to it. Therefore, the
software itself must be "vigilant", as the TPM only provides a safer
storage location for a less subvertible canary.

>> association. It is _just_ a [presumed] secure cryptography facility
>> that supports a wide variety of functionality.
>
> Although you didn't claim the opposite, it may be useful to mention that
> the TPM does not directly expose an interface to its encryption
> capabilities: TPM does not (yet?) give us general-purpose
> hardware-accelerated encryption. I'm not sure about hashing and signing.

The state of TPM support is slightly more complex than that. While
some cryptography facilities are available (since the EK and SRK
private material would otherwise have to be exposed), the hardware is
sufficiently slow as to discourage use beyond priming other, much
faster routines. I don't think it's ever going to be an accelerant
over even the slowest software implementations.

> Btw, it is interesting to see TPM being discussed so gentle and
> reasonable on this list. Perhaps everyone's anticipating TPM to become a
> new fun target for pentesting :)

Software is software, and many of us have our jobs based on humanity's
record on software security. Unless the TC model changes vastly,
programmers are still going to have to exercise due diligence in
secure programming and monitoring integrity. That isn't happening on
a large scale today, so I don't much expect the immediate future to
change. I, for one, am glad to see at least some people share my
opinion: yes, TPMs could be used for evil, but right now they're just
interesting hooks upon which to hang greater security.

RB
_______________________________________________
Dailydave mailing list
Dailydavelists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]