<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Mar 1, 2015 at 8:52 AM, Phillip Hallam-Baker <span dir="ltr"><<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>If I am using a Raspberry Pi with a clean O/S install from a source I have checked the thumbprint of, I have a lot more control than is possible using a TPM. </div><div><br></div><div>The TPM is really designed to solve a different set of problems to do with running the system for a long period of time. </div></div></div></div></blockquote><div><br></div><div>The TPM (and similar technologies) gives you attestation to binary images, which in turn ensures that the images you think you're running are indeed the images your CPU is executing. </div><div><br>For instance, if the OS on which you prepared the Raspberry image was compromised, your tools could be storing an adulterated OS image and reporting a different hash, and you'd be none the wiser. Reading Ken Thompson's "Trusting Trust" paper might be a good idea for anyone involved in systems that stand up to forensic scrutiny. Your current setup is not very secure: the TCB is very large because you transitively trust countless systems; the integrity of your findings depends on the provenance and integrity of every single system that went into preparing the final boot image. The TPM, and similar hardware measures, can enable you to perform an end-to-end check, rooted in the hardware root of trust provided by the hardware. </div><div><br></div><div>- egs</div><div><br></div></div><br></div></div>