Re: CSI 2008 Redux

[RB <aoz.syn () gmail com>]

On Sat, Nov 22, 2008 at 06:03, Dave Aitel <dave.aitel () gmail com> wrote:
> And I don't understand why you need a trusted computing chip if you decide
> to trust your hypervisor in the first place. Trusting the hypervisor instead
> of a public key on a chip from Dell makes a lot more sense. It's more
> configurable in a user-friendly way, and less configurable in a RIAA/Big
> Brother friendly way.

To quickly address the public key bit: yes, the chip from
Infineon/Atmel/etc. that Dell soldered to their motherboard has an RSA
key (EK) burned into it, but that is only used if you follow the full
TCG specifications.  The second RSA key (SRK), which is what everyone
actually deals with, is changed every time you "take ownership" of the
chip.  You can't specify or modify the private portion, but you often
can't with smartcards.

Leaving the trust issue alone, I find it entirely regrettable that so
many seem to have blindly swallowed the "Right to Read" hype and
simply assume TPM chips are evil insilicate.  I detest DRM & Big
Brother as much as your garden-variety Libertarian, but while trying
to solve the very difficult physical presence security problem a
couple of years ago, I decided to try to examine them for what they
are.  Needless to say, I was surprised: although TPM chips certainly
could provide the building blocks to do what we all fear, they're
generally quite benign, more analogous to an integrated smartcard than
an evil overlord's rootkit.

Here's an extremely simplistic overview:
For the most part, a TPM chip sits idle - after "measuring"
(generating a checksum) of a few boot-time bits, it largely serves as
a secure cryptography facility.  The only checksums it actively makes
are of itself and of the BIOS; after that, each component in the boot
process _tells_ the TPM a 20-byte value (usually the SHA1) of the next
component and which register to store it in.

Encryption comes in two flavors: bound and sealed.  Bound encryption
uses the SRK to encrypt/decrypt arbitrary data that is generally
another encryption key.  Sealed encryption takes it a step further and
integrates the checksums from specified boot processes, generally
tying the resulting key to very particular hardware & software
configurations.

The problem at this point is that people inextricably conflate TPMs
with the remainder of the TCG specifications: mostly remote
attestation and the associated big-brother issues.  It's a simple
piece of technology that supports a much larger and agreeably more
intrusive suite, but its utility goes far beyond the unfortunate
association.  It is _just_ a [presumed] secure cryptography facility
that supports a wide variety of functionality.

Hardware trumps software, and I, for one, would rather trust a
smartcard to securely store my keys than a piece of software.


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