[Cryptography] Dumb idea: open-source hardware USB key for crypto

Owen Shepherd owen.shepherd at e43.eu
Sat Jan 11 18:29:48 EST 2014


My thoughts:


   - An FPGA is a bad idea. You need an external ROM to contain the
   configuration data. How often are you going to verify the contents of that
   ROM? (Answer: probably never). There is no way to read protect that ROM
   - Smart card chips would be ideal but tend towards confidential specs,
   and additionally would seem to be obvious targets for a back door?
   - A commercial off the shelf micro seems like a viable option.

Why do I say this?

   - The flash is inside. No easy lines to probe.
   - Most have EFuse bits which can be set which don't let you read or
   write the device without doing a full erase
   - You can get them with large flash. 512kB flash is enough for both the
   code and a sizable collection of public/private key pairs
   - A *lot* less gates for someone to fiddle with than an FPGA. An ARM
   Cortex-M-style MCU is intrinsically no less safe than an FPGA (Note that
   there is no complicated microcode ROM to subvert, no System Management Mode
   to hide in, no motherboard embedded controller to replace the code on, etc)

Proposed layers of protection:

   - The manufacturer's provided anti-readout functionality. This is
   probably the weakest
   - Once the board has been burned, encapsulate it in epoxy to make access
   to the device pins difficult. This just leaves the USB pins as an attack
   avenue
   - Key encryption

Key encryption: Use some standard cryptographic algorithm (AES, Salsa/20,
whatever) to encrypt the keys with the user's PIN/key/password.

Side channel protection: Main one is power. Stick a resistance in series
with the power line, and a sizable capacitance after it? These micros are
pretty power efficient, that should provide quite sizable decoupling
between the internal power rails and external. Of course have all your high
frequency bypassing like normal.

Precautions to be taken by user: Don't plug into strange computers?

Threats:

   - Theft by non sophisticated adversary. Mitigation: PIN/Key code
   - Theft by sophisticated adversary (e.g. NSA). Mitigation: Encrypt the
   secrets with the PIN
   - Modification by a sophisticated adversary. Primary Mitigation:
   Potting. Hardware Protection. This certainly is the strongest, though least
   likely threat model. Its' difficult to find a way to protect from this one
   in general; a smart card chip would help, though based upon disassembly by
   people like Flylogic Engineering they don't buy you much.
   - Reading of memory from a live instance by an adversary. Mitigation:
   Don't keep keys in RAM unless you're doing a cryptographic operation. Have
   relatively short timeouts after which PIN re-entry is required, preferably
   non-resettable.

   Could implement some form of "tamper detect" system, e.g fragile wires
   embedded over the chip which would provide indication of case tampering.
   Issues with these though (e.g. accidental shorting during assembly).
   Determined adversary is liable to be able to counter this.
   - Firmware bugs: Authenticated firmware update mechanism (i.e. require
   the PIN to be entered to authorize new firmware download, validate have
   user validate signature before letting it run? This is trickiest, because
   of confined flash space.
   Maximize simplicity of firmware. Obviously this is somewhat difficult in
   the face of USB. Using an off-chip USB controller avoids that issue, in
   exchange for the other that now the driver and user interface situation is
   made more complex (USB serial ports for one are seriously ugly)

Other features: At a minimum a keypad, a display. This is not going to be
compact.

Potentially: (Micro)SD card slot so can function as encrypted flash drive?

Some form of analog RNG built on PCB? Preferably in addition to some form
of hardware RNG inside the chip (though chip manufacturers are notoriously
cagey about how good their entropy generators are, it can't hurt to mix in
extra slush)


Owen Shepherd
http://owenshepherd.net | owen.shepherd at e43.eu


On 10 January 2014 23:57, Natanael <natanael.l at gmail.com> wrote:

> Den 11 jan 2014 00:23 skrev "Bill Cox" <waywardgeek at gmail.com>:
>
> >
> > I've been noodling the idea of a USB stick designed in a way that we
> > can trust the crypto that goes on there.  It's a hard problem, but
> > there seems to be some guidelines that could help:
> >
> > - Open source hardware - schematics and everything including board
> > layout need to be free
> > - No ICs that could be compromised.  Any CPU would have to be a
> > soft-core in an FPGA, with an open-source design
> > - FPGA configuration memory both readable and writable over a JTAG port
> > - External flash program memory also read/writeable through JTAG
> > - Reasonable hardware RNG where every node in the circuit can be probed
> > - Signal isolation from the PC: solid state relays would swap a simple
> > memory back and forth between the PC side and USB stick side.  Maybe
> > power draw should be randomized to obscure any processing going on.
> > RF shielding should cover the USB stick.  No other communication
> > should be possible.  This is similar to an air gap.
> > - A community supported audit trail verifying produced USB keys are
> secure
> >
> > The idea still has issues.  Where would I be able to store secret keys
> > securely such that an attacker who stole my USB stick could not
> > recover it?  Anyway, it's just a fun idea.  I'd love to have such a
> > device in my pocket.  There's a lot of applications I can think of
> > that could benefit from it, from electronic voting to
> > microtransactions.  As one security expert once said in an
> > electronic-voting discussion I followed, no machine ever connected to
> > the Internet has proven secure.  Could we make such a beast?  I
> > probably don't really have time to work on it, but if a group were
> > building it, I'd participate.
>
> You just put your trust in that the FPGA isn't backdoored. There's been
> backdoored FPGAs before, plenty of times. Secure storage of keys require
> custom hardware as well, an FPGA is just a computational device in itself.
> You need a smartcard or TPM style chip.
>
> Maybe you want an open source HSM?
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140111/80fec40e/attachment.html>


More information about the cryptography mailing list