[Cryptography] Show Crypto: prototype USB HSM

Ron Garret ron at flownet.com
Wed Apr 13 13:20:29 EDT 2016


On Apr 13, 2016, at 8:27 AM, John Ioannidis <ji at tla.org> wrote:

> On Tue, Apr 12, 2016 at 11:28 AM, Ron Garret <ron at flownet.com> wrote:
>> One of the biggest challenges in crypto is protecting your keys against an attacker who pwns your machine.  The fundamental problem is that such an attacker can do anything you can do, including access hardware tokens that are connected to the machine.  Some hardware tokens have an input device built in (usually a push button, sometimes a fingerprint sensor) which needs to be activated before the token will operate, but these are still subject to phishing attacks.  In order to really be secure, a hardware token must have not just an input device, but a display as well so that information about the operation being authorized can be shown to the user in a way that is guaranteed to be out of the control of an attacker who pwns the host machine.
>> 
> 
> You are addressing crypto professionals here. Don't you think we
> already know this?

I didn’t want to assume that *everyone* on this list was a professional cryptographer.  And it certainly does not appear to be common knowledge that a USB token needs to have built-in I/O in order to be secure against ownership of the client device.  In fact, it seems to be a rather controversial claim.  But if you thought my original post was inappropriate I apologize.

>> I did a market survey and could not find a device that met these requirements.  The closest thing I could find was the Trezor bitcoin wallet, but at $99 it seemed a bit pricey so I decided to roll my own.  The result is the SC4-HSM, a USB dongle with an STM32F405 processor (32-bit ARM cortex M4 with a built-in hardware RNG, 1MB flash, 192k RAM) and a 128-32 pixel monochrome Adafruit display.  It also has two user pushbuttons and two LEDs (though I’m going to be changing that to a single tri-color LED).  It currently runs TweetNaCl, but there’s a lot of headroom for more complex crypto.  It’s also possible to swap the F405 for an F415, which has built-in crypto operations (AES, 3DES, various SHA hashes).  Both processors have hardware support for freezing a firmware load so that it cannot be overwritten, and so the contents of the flash cannot be read out even with physical access to the device.  The target market for these chips is medical devices and process controllers, and one of the requirements is to keep the firmware out of the hands of Chinese industrial espionage agents.
>> 
> 
> If the secret you are protecting is valuable enough, there are lots of
> ways to uncover it. Read up about decapping chips with nitric acid,
> micromanipulators, and other such fun stuff. If you want to get a bit
> fancier, read up on FIBs. If your secret is worth more than $100, you
> should really spend at least that much protecting it.

You can make the SC4-HSM secure against decapping by encrypting the keys with a pass-phrase.

> The part about freezing the firmware is valid, but even then, you have
> to balance that against the need to do firmware upgrades for when bugs
> are discovered.

In that case you’d need to obtain a new HSM.  But the SC4-HSM is ridiculously cheap, only about $20 in parts in single quantities, so replacing it is a viable solution.

> The most valuable part of medical devices is not the code. It's the
> process of getting them approved for medical use.

That may well be, but I don’t understand why you think it’s relevant.  Preventing firmware from being copied is a feature of sufficient value that hardware manufacturers are building it into their chips, and that’s all that matters for this application.

> 
>> Photos of the prototype are attached.  I’m about to do a small production run (O(10) units) which will cost about $50 each.  If anyone here is interested in obtaining one of these please contact me privately.
>> 
>> I’m also actively recruiting a consultant to help with firmware development and auditing.
> 
> You just got some free consulting. Here is some more: do not hire
> anyone who would not bring these points up right away.

Thank you for your feedback.

rg



More information about the cryptography mailing list