[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