<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br></div></div></div></blockquote></span></div></div></div></blockquote><div><br></div></span><div>I don't think it is possible to put any system beyond the possibility of doubt. The point is to reduce the attack surface as far as is practicable but not demand superhuman efforts. Yes, an intel agency might have got into ATMEL and jiggered the microcode of the chip. But at least when I am using a Pi I only have the microcode and a very small bootstrap reading data from the SD interface to worry about. That is a lot less than a BIOS.</div></div></div></div></blockquote><div><br></div><div>I now see what was unclear in my earlier email, so let me try again: Your TCB includes the machine on which you prepared the OS image on the SD card. It's entirely possible that you thought you were writing a Raspbian OS image on, say, a Windows box. But it could well be that your Windows box has been hacked, and it writes a modified OS image behind the scenes. A rooted Windows box can easily intercept all calls to pretend that the hash is good, but when your Pi boots from the card, it boots from the modified binary. You can't trust the hash of the SD card taken on the Pi -- it's too downstream and the hacker may own it. You may or may not be able to trust the hash of the SD card taken on your Windows box -- it depends on whether your Windows box is indeed "good" (i.e. not owned by the attacker). But how can you tell if your Windows image is good? That problem is identical to the problem of figuring out if your Raspbian image is good. You can see that the problem extends transitively. </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The machine I am checking the image fingerprints on actually has a TPM. But I don't see how it helps in the slightest.<br></div></div></div></div></blockquote><div><br></div><div> The only way to know what precise binary the machine booted (modulo attacks on TPM foundries), is to acquire a hash of the actual bits that are executed with the help of some specialized hardware. TPM is one such hardware.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>What I could do to improve the scheme would be to move the checking of the image fingerprints off onto another machine that is entirely offline.<br></div></div></div></div></blockquote><div><br></div><div>You are using "entirely offline" as being synonymous with "trustworthy" or "provides assurance of its integrity". This is an error. The problem of "what exact OS is this machine running" recursively repeats itself on every platform, until you use a box with a hardware root of trust.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Do you try to explain the operation of the CPU to counsel? Or other trusted hardware/software, like device firmware?</div></div></div></div></blockquote><div><br></div></span><div>That is way beyond what any counsel would ever put in front of a judge unless absolutely vital.</div></div></div></div></blockquote><div><br></div><div>Great, that goes counter to your assertion that you'd have to explain how a TPM works. Counsel won't care to know the specifics of how it works, beyond its function (assuring integrity) and the assumptions that go into providing that function securely. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div></div></span><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Look, if you're happy with your approach in court, power to you. It's probably sufficient for whatever you're doing; I'd trust your gut call that it's the optimal tradeoff between being simple enough to explain and secure enough for your purpose (which you didn't quite describe, so you can't get upset if people assume a higher value case or a stronger attacker than what you have in mind). But you asked how the process could be improved, and I mentioned the state of the art. Feel free to ignore it as being "academic" -- you're probably right that it doesn't matter for low value cases, where there is no attacker or the attacker is severely limited. But when a high-value case comes along, you'll need stronger techniques, and adding TPM attestation on top of your process strictly improves what you're doing.  </div></div></div></div></blockquote><div><br></div></span><div>Well there are two parts to the problem. The first is how to establish a trust axiom. The second is how to collect and preserve evidence from the system.</div><div><br></div><div>I am focused on the second part and removing as many variables as I can from the evidence collection phase.</div></div></div></div></blockquote><div><br></div><div>I gently suggest that you reconsider a hardware root of trust. It does indeed solve a problem that just making a host "offline" does not solve.</div><div><br></div><div>Hope this helps,</div><div>- egs</div><div><br></div><div><br></div></div><br></div></div>