<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 4, 2015 at 11:03 AM, Arnold Reinhold <span dir="ltr"><<a href="mailto:agr@me.com" target="_blank">agr@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mar 2, 2015, at 10:33 PM, Emin Gün Sirer <<a href="mailto:el33th4x0r@gmail.com">el33th4x0r@gmail.com</a>> wrote:<br>
<br>
> >On Mon, Mar 2, 2015 at 10:29 PM, Arnold Reinhold <<a href="mailto:agr@me.com">agr@me.com</a>> wrote:<br>
> >More generally, I think the way to approach “nothing up my sleeves” hardware is to move down in complexity, not up. I’d like to see a series of small security devices based on minimalist processors. We’ve talked about HRNGs in the past. How about a small device that did nothing but compute the hash of the contents of an SD card?<br>
><br>
> Ironically, you're describing a TPM platform.<br>
><br>
<br>
</span>Perhaps in terms of functionality, but not in terms of trust model. TPMs, as I understand them, are opaque black boxes. We have to trust the manufacturers for their content. That works fine in a wide swath of corporate security applications, where policy must be asserted and maintained over many machines and users. But I don’t see how TPMs help individual practitioners who seek complete control of their computing environment. </blockquote><div><br></div><div>My machine works exactly the same regardless of whether the module is plugged in or not. So how is it protecting me? Like firewalls, I worry that TPMs risk becoming a +5 amulet of protection against the undead rather than being understood as a tool that has a very specific purpose.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Some might say the Thompson “Trusting Trust” paper makes that goal unattainable, but I’m not convinced. Thompson assumed a fixed target that code hidden in the compiler attacks.</blockquote><div><br></div><div>Thompson was provoking an argument. He never argued that the problems were impossible to solve.</div><div><br></div><div>Security is risk control, not risk elimination. What I am looking to do here is to see if we can work out to apply parts of what we applied when setting up the original VeriSign PKI to a wider field. The VeriSign approach is documented in the CPS so I am not divulging proprietary information and in any case Symantec came to CABForum to share the same with the CA world in general.</div><div><br></div><div><br></div><div>In particular, I like the use of ceremonies to formalize process. [Something Carl Ellison has also said a lot of useful stuff on]</div><div><br></div><div>I want to look for ways to make collection of digital forensic evidence as airtight as possible without introducing unreasonable expense or requiring exceptional expertise or special hardware.</div><div><br></div><div>The reason I am starting with a Raspberry Pi 2 is that it is a very simple device with minimal moving parts that boots from removable media. But if a case involved a specific brand of computer such as Windows or Mac, I would want to have a protocol and a ceremony that covers that eventuality as well. [Windows for Raspberry Pi is also very interesting of course].</div><div><br></div><div><br></div><div>Extending to Beaglebone and using devices of one type to cross check another seems like an excellent move as well.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> In large systems it might even be possible to hide a large code blob that figures out what is going on and devises an attack. But by moving down in the complexity chain instead of up, it becomes harder to hide a smart evil code blob. Using a variety of microprocessor architectures and software sources, makes the Thompson attack even more difficult.<br></blockquote><div><br></div><div>There are some very small and constrained builds for Raspberry Pi. Console only O/S etc. Those would also be very interesting to look at.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My approach is an ecosystem of simple devices made from inexpensive off the shelf components with wide availability and limited capabilities that solve specific problems, in this case just verifying the hash on an SD card. Each problem in the trust chain, e.g where does one get the known good hash value, can be dealt with separately.<br>
<br>
Maybe there is a different approach to “nothing up my sleeves" control of computing using TPMs. If so I’d be interested in hearing how it might work.<br></blockquote><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.</div><div><br></div><div>Also TPMs and trusted boot are two different things.  </div></div><br></div></div>