[Cryptography] Cheap forensic recorder

[Phillip Hallam-Baker]

On Sun, Mar 1, 2015 at 10:06 AM, Emin Gün Sirer <el33th4x0r at gmail.com>
wrote:

>
>> I remember back when folk were doing all the work on cryptographic
>> elections in the 1990s and the concern was to protect confidentiality.
>> People really didn't get my assertion that what I was interested in was the
>> ability to audit the election.
>>
>
> I'm sorry about your experience but we're not talking about that right now
> nor was I involved in it in any way. We all agree that this particular
> application requires auditability. Your proposed technique does not provide
> bullet-proof auditability. Surely, you've followed the recent revelations
> about how agencies are hacking disk firmware even as we speak. Your
> proposed scheme fails in the presence of such an adversary.
>

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.

If we are considering questions such as whether Bob who is divorcing Alice
snuck into her house and planted a trojan on her machine so he could spy on
her with his webcam, I don't think we need to consider the possibility that
the NSA corrupted the hardware.


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

If an intel agency can jigger the pre-boot firmware of a Raspberry Pi, they
can jigger the TPM.


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.


A TPM really does not help very much because it is a sealed box that the
>> whole security of the system depends on and I can't audit it. I certainly
>> can't expect to explain it to counsel.
>>
>
> I don't know what you can and cannot explain to counsel, but many simple
> things that are easy to explain are also easily broken. 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.


It is really easy to throw the 'transitive trust' problem, the TPM is just
>> as vulnerable.
>>
>
> Sure, you're trusting the foundry and the silicon, but the TCB profile is
> vastly different: the attackers now have to have hacked a silicon foundry
> to launch an attack on you, instead of just hacking the machine where you
> prepared the raspbian OS.
>

The silicon foundry undoubtedly has a broader attack surface. But thats OK
because another group I work with are very concerned about the problem of
making those secure...

As far as court cases go, the criteria is 'best evidence' not 'beyond
possibility of doubt'. We put evidence in tamper evident bags for example
but it is normally assumed that a forensic investigator isn't engaged in
perfidious behavior and deliberately sabotaging things.


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150301/2fc553de/attachment.html>