<div dir="ltr"><div>This discussion brought up a few points worth clarifying:</div><div><br></div><div>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.</div><div><br></div><div>>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.<br></div><div><div><br></div><div>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. </div><div><br></div><div>>Also TPMs and trusted boot are two different things.  </div><div><br></div><div>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. </div><div><br></div><div>>He is describing a platform that *he* trusts, not a platform that has been subverted by the NSA and then called "TPM".</div></div><div><br></div><div>There are three errors here:</div><div><br></div><div>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.</div><div><br></div><div>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. <br></div><div><br></div><div>6. Trusted != trustworthy. <br></div><div><br></div><div>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.</div><div><br></div><div>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. <br></div><div><br></div><div>- egs</div><div><div><br></div></div></div>