[Cryptography] Known Hardware (was Other obvious issues being ignored?)

Thierry Moreau thierry.moreau at connotech.com
Sun Oct 25 10:39:07 EDT 2015


On 10/24/15 20:35, Jerry Leichter wrote:
>
>>
>> which leads me to ask the general question, what does one do when
>> something you might soon depend upon can simply never be analyzed?
>
> We've always been in that domain.  Who knows what's actually in your hardware?

I tried to be in a position to know for the "Open source HSM" concept 
turned into the "evanescent security module" concept:

I bought a booksize X86 box: No hard disk, no internal flash disk.

I should have removed the wi-fi daughterboard.

I installed my own "Linux from scratch" with as little outside world 
driver support as possible on either USB flash disk or MicroSDHC 
bootable media.

I used the (recently introduced) Linux overlay file system such that the 
boot media is root file system but remains read-only (i.e. unavoidably 
writable directories such as /var/run are "overlay-ed" by RAM file 
system directories).

The boot process starts an HTTP server with a single dedicated 
application -- application-specific session with cookie-like session 
management limited to a single instance.

There are two flavors of applications: (equivalent to) create root CA 
private key pair and sign security certificates by root CA.

The application console is any browser connected to the RJ45 port on the 
box.

Critical inputs are through a cheap bar code reader. Critical outputs 
are through a plain laser printer.

I would have preferred input and output with paper punch ribbon media 
but the local computer dealer did not carry those items when I started 
the project.

(Basically, the critical data is the root CA private key.)

What remains problematic:

Side channel attacks: I plan to do the work sessions in a remote fishing 
cabin in the northern forests, out of battery power. Air gap of a few 
kilometers from the nearest motor vehicle as we are completing the 
journey by row boat. Please leave your cell phones at home.

Leftover buffer data in the printer: purchase the printer unit with as 
little RAM memory as possible and have these RAM buffers stuffed with 
random page data after the work session.

How do I convince you that this fingernail size flash memory IC has the 
software which you had a chance to review before the work session (you 
obviously were given a copy of all relevant source code and build 
scripts plus a chance to procure a development box within a reasonable 
budget)? ... see below ...

Two Main lesson:

(A) Having a computer do a critical computation under strictly 
controlled conditions is possible these days with the scope of control 
being a complete application in the occasional key management work 
session context ...

... but ...

... as any IT controls, the scheme only shifts control from a 
comprehensive system (or set of data) towards a smaller component: a 
flash memory IC in demand of data integrity protection (or a master 
cryptographic key in demand of secrecy protection).

I vaguely envision that a workable solution would rest on multiple flash 
memory ICs compiled by different parties, ...

(B) The fun thing is that you don't need throughout software quality 
control. The critical computation is the only useful work done by the 
whole computer system. Hence if it works in the laboratory for some data 
set and the only software along the critical path of the critical 
computation is reviewed, you should get a proper assurance level.

- Thierry Moreau


More information about the cryptography mailing list