[Cryptography] Cheap forensic recorder

Phillip Hallam-Baker phill at hallambaker.com
Sun Mar 1 19:17:20 EST 2015

On Sun, Mar 1, 2015 at 5:28 PM, Kevin W. Wall <kevin.w.wall at gmail.com>

> On Sun, Mar 1, 2015 at 9:43 AM, Phillip Hallam-Baker
> <phill at hallambaker.com> wrote:
> > On Sun, Mar 1, 2015 at 9:02 AM, Emin Gün Sirer <el33th4x0r at gmail.com>
> wrote:
> >>
> >> On Sun, Mar 1, 2015 at 8:52 AM, Phillip Hallam-Baker
> >> <phill at hallambaker.com> wrote:
> >>>
> >>> 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.
> >>>
> >>> The TPM is really designed to solve a different set of problems to do
> >>> with running the system for a long period of time.
> >>
> >> 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.
> >>
> >> 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.
> >
> > This is rhetoric, not argument.
> >
> > Yes, I have read the Thompson paper and like much of the UNIX security
> work
> > I find an obsession with issues of mostly academic importance.
> Academic or not, we are starting to seem some of Thompson's arguments
> approaching reality so I agree that we can no longer simply dismiss
> them.
> However, in your (PHB's) case, I am not sure that the attestation chain of
> trust that Emin is arguing for will help all that much. (Although, it
> certainly probably will not hurt things either.)

The question I think is who you have to make the proof to.

Normally I am using a machine and wanting to prove to MYSELF that nobody is
attacking ME.

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

> Let's consider malicious hard drive firmware. For the attestation chain to
> work with that, that HD firmware needs to somehow be confirmed as the
> original firmware as installed by the manufacturer.

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.

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.

Can even do the same thing with commitments etc.

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.

> In most cases, I
> think it is probably doubtful that this could be confirmed because one
> can't actually 'get at' the hard drive firmware during the boot sequence
> to check the attestation chain. (Unlike other firmware for things like
> NICs,
> it is not loaded as part of the device drivers from /lib/firmware or
> wherever.)

One reason I prefer something with SD card firmware. But again, not perfect
as they have some firmware etc on them these days.

The other thing that Emin was perhaps hinting at regarding malware in the
> firmware of the hard drive I think is an issue, but not so much for
> the field system gathering the forensics evidence. The important thing
> in forensics is having a verifiable chain-of-evidence and if past
> history is any evidence, courts are willing to accept lower levels
> of this such as eyewitness from the court, law enforcement, or
> the opposing counsel, or perhaps video taping and followed by
> turning over the forensics collections system to court authorities.
> While such chain-of-evidence / chain-of-custody can be challenged by
> the defendant's attorney(s), the team performing the forensics is not
> the one on trial so judges are likely to control at least some aspect
> of what is a reasonable challenge. And one would think that this can
> be simplified by getting opposing counsel to agree beforehand what is
> and is not acceptable to them in terms of evidence gathering.

And so much better if we have created the image in advance of the case
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150301/1b52c167/attachment.html>

More information about the cryptography mailing list