[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