[Cryptography] Cheap forensic recorder

Emin Gün Sirer el33th4x0r at gmail.com
Sat Mar 7 17:37:28 EST 2015

This discussion brought up a few points worth clarifying:

1. A TPM is just a hardware component. It is not an end-all solution, in
fact, it's not even a solution by itself. Soldering one onto a board does
not confer any magic capabilities. The integration of the TPM onto the rest
of the hardware and software (i.e. the "platform"), the way it is used by
the software, and many other factors, play a role in how well the resulting
statements from the platform can be trusted.

>My understanding is that TPMs are limited to a very small set of functions
such as ensuring that private keys generated on the device can't be
exported or become visible to a program that might export them.

2. TPMs can perform additional functionality that goes beyond that. In
particular, they can perform attestation, i.e. the process of issuing a
statement about the state of a computation, where the verity of these
statements rests on clearly-specifiable assumptions.

>Also TPMs and trusted boot are two different things.

3. TPMs and trusted boot are indeed different things, and in fact,
attestation is itself different from trusted boot. Attestation can be used
to implement trusted boot, but can also be used for other, more general
functionality, such as attesting to the state of a dynamic computation, not
just its boot-time hash.

>He is describing a platform that *he* trusts, not a platform that has been
subverted by the NSA and then called "TPM".

There are three errors here:

4. It's critical to separate abstract ideas from their implementation. A
TPM is a generic name given to a class of devices. An Atmel TPM, for
instance, is a specific instance. An agency may have subverted a particular
instance at a given time, or perhaps every instance, in the worst case. We
seem to be going through a particularly bad time where intelligence
agencies seem to have compromised quite a few of manufacturers' processes.
But these considerations of which instances are trustworthy is at a
separate level of abstraction, unless you're willing to make the claim that
*all* secure hardware coprocessors are untrustworthy for all time. Not only
is the latter a tall claim, but that set of assumptions (that no hardware
canbe trusted) is difficult to work into a coherent worldview.

5. TPM doesn't parse as (Trusted) (Platform Module). It parses as (Trusted
Platform) (Module). It's just a module used in building platforms one may
be able to trust.

6. Trusted != trustworthy.

At the end of the day, every machine entrusted with a function entails a
particular set of trust assumptions. It's possible to homebrew a device
that operates as a tamper-evident, attested box, using epoxy resin and a
lot of assumptions about software provenance, e.g. what was running on the
machine that prepared the images for the homebrew device, and what was
running on the machine that prepared that machine, and so forth. It's also
possible to use a hardware root of trust to replace a large number of
assumptions about software with a smaller number of assumptions about
hardware. As always, it's a game of finding a set of assumptions that match
the task.

Overall, this discussion would have been better informed if the assumptions
and requirements were stated up front. As with most real-world security
discussions, they trickled out piecemeal.

- egs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150307/2a0b4e6f/attachment.html>

More information about the cryptography mailing list