<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 1, 2015 at 5:28 PM, Kevin W. Wall <span dir="ltr"><<a href="mailto:kevin.w.wall@gmail.com" target="_blank">kevin.w.wall@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Mar 1, 2015 at 9:43 AM, Phillip Hallam-Baker<br>
<div><div class="h5"><<a href="mailto:phill@hallambaker.com">phill@hallambaker.com</a>> wrote:<br>
> On Sun, Mar 1, 2015 at 9:02 AM, Emin Gün Sirer <<a href="mailto:el33th4x0r@gmail.com">el33th4x0r@gmail.com</a>> wrote:<br>
>><br>
>> On Sun, Mar 1, 2015 at 8:52 AM, Phillip Hallam-Baker<br>
>> <<a href="mailto:phill@hallambaker.com">phill@hallambaker.com</a>> wrote:<br>
>>><br>
>>> If I am using a Raspberry Pi with a clean O/S install from a source I<br>
>>> have checked the thumbprint of, I have a lot more control than is possible<br>
>>> using a TPM.<br>
>>><br>
>>> The TPM is really designed to solve a different set of problems to do<br>
>>> with running the system for a long period of time.<br>
>><br>
>> The TPM (and similar technologies) gives you attestation to binary images,<br>
>> which in turn ensures that the images you think you're running are indeed<br>
>> the images your CPU is executing.<br>
>><br>
>> For instance, if the OS on which you prepared the Raspberry image was<br>
>> compromised, your tools could be storing an adulterated OS image and<br>
>> reporting a different hash, and you'd be none the wiser. Reading Ken<br>
>> Thompson's "Trusting Trust" paper might be a good idea for anyone involved<br>
>> in systems that stand up to forensic scrutiny. Your current setup is not<br>
>> very secure: the TCB is very large because you transitively trust countless<br>
>> systems; the integrity of your findings depends on the provenance and<br>
>> integrity of every single system that went into preparing the final boot<br>
>> image. The TPM, and similar hardware measures, can enable you to perform an<br>
>> end-to-end check, rooted in the hardware root of trust provided by the<br>
>> hardware.<br>
><br>
> This is rhetoric, not argument.<br>
><br>
> Yes, I have read the Thompson paper and like much of the UNIX security work<br>
> I find an obsession with issues of mostly academic importance.<br>
<br>
</div></div>Academic or not, we are starting to seem some of Thompson's arguments<br>
approaching reality so I agree that we can no longer simply dismiss<br>
them.<br>
<br>
However, in your (PHB's) case, I am not sure that the attestation chain of<br>
trust that Emin is arguing for will help all that much. (Although, it<br>
certainly probably will not hurt things either.)<br></blockquote><div><br></div><div>The question I think is who you have to make the proof to.</div><div><br></div><div>Normally I am using a machine and wanting to prove to MYSELF that nobody is attacking ME.</div><div><br></div><div>In this case the problem is how to show that I have nothing up my sleeves to third parties. And this is the same problem we face on things like the cryptobone.</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">
Let's consider malicious hard drive firmware. For the attestation chain to<br>
work with that, that HD firmware needs to somehow be confirmed as the<br>
original firmware as installed by the manufacturer. </blockquote><div><br></div><div>I don't think that works either. I think that we have to get into ceremonies and protocols here. For starters, lets have more than one person make a device.</div><div><br></div><div>Lets say I go through a ceremony to create an image, sign it and post it on a site. I then ask everyone here to download the image, put it through their local tools and tell me if there is a difference.</div><div><br></div><div>Can even do the same thing with commitments etc.</div><div><br></div><div>Sure there are still going to be holes in the protocol but each layer of ceremony is increasing the opponents work factor. And work factor is what it is all about.</div><div><br></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">In most cases, I<br>
think it is probably doubtful that this could be confirmed because one<br>
can't actually 'get at' the hard drive firmware during the boot sequence<br>
to check the attestation chain. (Unlike other firmware for things like NICs,<br>
it is not loaded as part of the device drivers from /lib/firmware or<br>
wherever.) </blockquote><div><br></div><div>One reason I prefer something with SD card firmware. But again, not perfect as they have some firmware etc on them these days.</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">
The other thing that Emin was perhaps hinting at regarding malware in the<br>
firmware of the hard drive I think is an issue, but not so much for<br>
the field system gathering the forensics evidence. The important thing<br>
in forensics is having a verifiable chain-of-evidence and if past<br>
history is any evidence, courts are willing to accept lower levels<br>
of this such as eyewitness from the court, law enforcement, or<br>
the opposing counsel, or perhaps video taping and followed by<br>
turning over the forensics collections system to court authorities.<br>
While such chain-of-evidence / chain-of-custody can be challenged by<br>
the defendant's attorney(s), the team performing the forensics is not<br>
the one on trial so judges are likely to control at least some aspect<br>
of what is a reasonable challenge. And one would think that this can<br>
be simplified by getting opposing counsel to agree beforehand what is<br>
and is not acceptable to them in terms of evidence gathering.<br></blockquote><div><br></div><div>And so much better if we have created the image in advance of the case starting.</div></div></div></div>