[Cryptography] Cheap forensic recorder
Emin Gün Sirer
el33th4x0r at gmail.com
Mon Mar 2 22:33:33 EST 2015
>More generally, I think the way to approach “nothing up my sleeves”
hardware is to move down in complexity, not up. I’d like to see a series of
small security devices based on minimalist processors. We’ve talked about
HRNGs in the past. How about a small device that did nothing but compute
the hash of the contents of an SD card?
Ironically, you're describing a TPM platform.
On Mon, Mar 2, 2015 at 10:29 PM, Arnold Reinhold <agr at me.com> wrote:
> On Sun, 1 Mar 2015 19:17 Phillip Hallam-Baker wrote:
> >> 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.
> More generally, I think the way to approach “nothing up my sleeves”
> hardware is to move down in complexity, not up. I’d like to see a series of
> small security devices based on minimalist processors. We’ve talked about
> HRNGs in the past. How about a small device that did nothing but compute
> the hash of the contents of an SD card? If you are using a Raspberry Pi as
> your forensics tool, you could use a Beagle Bone with a different distro to
> check the SD card hash.
> Even better would be an Arduino class machine with the smallest AT
> processor that can do the job. For minimal cost, one could blink out the
> hash in Morse code on a single LED. In base-32, you’d need ten 5-character
> groups for a 250-bit hash, this would take a minute and a half at a
> relatively slow 7 groups per minute. The target hash could be printed with
> the dots and dashes next to the characters so there would be no need for a
> user to know Morse, e.g.:
> R .-.
> X -..-
> 6 -….
> K -.-
> Of course Arduino LED and LCD display shields are available at more cost
> for easier hash output reading.
> Yes you’d have to trust the firmware in the checker microprocessor. But
> this would be open source and simple enough to read. And one could checkthe
> device against different SD cards whose hash is tested elsewhere. The
> possibility that the checker firmware has a hidden “if you see hash X
> report hash Y” backdoor could be ruled out by accounting for all long
> non-instruction strings in the object code.
> Another useful device might be an SPI bus repeater wedge that would block
> all write commands unless a jumper was in place. This could act as
> trustable a write protect switch for SD cards and PC BIOS chips.
> Arnold Reinhold
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cryptography