[Cryptography] Cheap forensic recorder

[Emin Gün Sirer]

>
>
>>>
> 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.
>

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.


> The machine I am checking the image fingerprints on actually has a TPM.
> But I don't see how it helps in the slightest.
>

 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.

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.
>

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.


> Do you try to explain the operation of the CPU to counsel? Or other
>> trusted hardware/software, like device firmware?
>>
>
> That is way beyond what any counsel would ever put in front of a judge
> unless absolutely vital.
>

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.


> 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.
>>
>>
>
> 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.
>
> I am focused on the second part and removing as many variables as I can
> from the evidence collection phase.
>

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.

Hope this helps,
- egs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150301/064e0a20/attachment.html>