[Cryptography] Anyone interested in a cheap security module for Raspberry Pi?

[Bill Cox]

On Wed, Jul 26, 2017 at 1:24 PM, Ron Garret <ron at flownet.com> wrote:

>
> On Jul 26, 2017, at 11:10 AM, Bill Cox <waywardgeek at gmail.com> wrote:
>
> On Wed, Jul 26, 2017 at 9:39 AM, Ron Garret <ron at flownet.com> wrote:
>
>> I have a different threat model than most HSMs:  I assume the attacker
>> could be:
>>
>
> - Malware on the host computer
> - The owner of the device, so pass phrases do not help
> - A botnet of HSM emulators, so I'll need hardware attestation
> - A group of hackers motivated enough to buy a large number of HSMs and
> PWN them to control the network
>
>
> I think we may have a fundamental disconnect here.  The SC4-HSM is not
> intended to be used in a data center.  It’s intended to be used by an
> individual who has it in their physical possession and plugs it in to a USB
> port of a host that is also by necessity in their physical possession.  So
> there is no “network” that an attacker could possibly control.
>

What I would do is run some software on the user's computer to form a
network of HSMs.  Only firmware and keys in the HSM need to be trusted, not
the host software.  The HSMs would secure not just the owner's secrets, but
would participate in securing secrets of other users.  This creates a
potential incentive for the owner to hack their own HSM, since the secrets
of others might be valuable.  The idea sounds a bit nutty, but there seem
to be ways to improve security, reliability, and availability considerably
with this approach.

Some concerns I would have putting my secrets into a SC4-HSM: What if I
lose it?  What if it breaks?  Do I need to backup all my secrets?  What if
I want to buy a hamburger with my bitcoins bug my HSM is plugged in at
home?  What if an attacker steals it and brute-forces my HSM pin/password?
Do I need to use a super-hard password, and enter it every time I buy a
hamburger?  I really just want to buy a Hamburger with bitcoins on my
phone.  Can I do that with the HSM, without carrying it around?  There seem
to be opportunities to improve on all this with networked HSMs working
together.  That's the area I am currently interested in.


> Also, the SC4-HSM has an on-board display and push-buttons which are
> integral to its security model.  You could emulate an SC4-HSM, but absent
> some really major breakthroughs in virtual reality technology you could not
> hide the fact that you were emulating it.  :-)
>

Attackers who want to PWN the network of collaborating HSMs would like to
run emulators.

> I think it would be useful to have:
>
> - Basic tamper resistance
>
> Having an accessible debug port would be bad.  This would allow an
> attacker to see secret keys.  There is a debug port on the  STM32F405R.  Do
> you somehow disable it?
>
>
> Yes.  There are two ways to disable the debug port, one temporary, the
> other permanent.  These are described in detail in the documentation.
>

I checked it out.  RDP mode 2 looks like what I want.

> Neither a safe nor passphrase would help, because the owner is in the
> threat model.
>
>
> I don’t understand this at all.  How can the owner of a device be an
> attacker?  That seems impossible by definition.
>
> Because the HSM stores other people secrets if it is cooperating in the
HSM network.  There are ways to mitigate the risk, but the HSM owner is
considered a potential attacker.

> I do not want to lock it down like a Tivo, but instead have the hardware
> erase all secrets, including the attestation key, before allowing the owner
> to reprogram the entire device.
>
>
> Yes, this is exactly how the reversible lock-down feature works.
>

Thanks for the tip.  This looks good.

> Tamper detection would be useful.
>
>
> The SC4-HSM does not have this, though it could be added.  However, this
> would undermine what I consider to be one of the SC4-HSM’s significant
> features: the ability to open the device and visually inspect the circuitry
> to insure that what is in the package is what is supposed to be there.  If
> you’re willing to trust your vendor then you might as well just use an iPod
> Touch.
>

I might want a semi-clear glitter paint or nail polish over the MCU, maybe
just the leads.  This should not make it hard to verify that the MCU is
what it is supposed to be, but make it hard to replace the MCU with a PWNed
one, which could happen while I mail a pre-programmed HSM in DRP mode 2 to
a customer.  There would be no way for the customer to verify the firmware
isn't hacked once mode 2 is enabled, but they could compare the glitter
paint to the picture on a web site.

> - Verifiable boot and firmware updates.
>
>
> The SC4-HSM gives you access to DFU mode, which gives you direct
> hardware-level access to the flash.  There is no bootloader.  (You could,
> of course, upload one if you wanted to, but why would you want to?)
>

In DPR mode 2, I'd need a boot loader to enable firmware upgrades.  I need
a bit more flexibility than the built-in mode 1.  For example, I might have
a bitcoin app loaded, and want to also load a U2F app.  I do not want to
lose my bitcoins when adding the U2F app.  However, if someone wants
program upload a new virtual machine, some apps might want their data
erased, even if the binary is signed by the author.


> In addition, all of the current firmware and the tool chain is
> open-source.  It doesn’t get any more verifiable than that.  (Note however
> that the current version of the firmware has NOT been audited.  Verifiable
> != verified.)
>

Being open is my favorite feature of the SC4-HSM.

> I'll need to be able to run a boot loader that verifies firmware
> signatures before upgrading
>
>
> The SC4-HSM is designed to minimize the trust you need to put in third
> parties.  The only part of the design that is not independently verifiable
> is the SoC chip itself.  Everything else is either open to inspection or
> under the user’s direct control.  This is *more* secure than firmware
> signatures because those require that you trust both the bootloader and the
> signer of the firmware.
>

True, but I'd want to be able to install apps, somewhat like javacard apps
(but 10X less complexity in the VM).  At that point, I want to trust the
app author.

> , and in some cases, it will need to erase secrets before upgrading.  Can
> the STM32F405R do that?
>
>
> Yes.  See above.
>

This was a nice surprise to me.  Looks like they got this part right.

> - ECC (P256 is fine), AES, and SHA256 acceleration to enable reasonable
> transactions per second (as in more than 1).
>
>
> The STMF405 does not have AES and SHA in hardware, but the STMF415 does
> (that is the only difference between these two chips).  The current
> production run has 405 chips but I would be more than happy to make a batch
> of HSMs with 415s if that were desirable.  However, the limiting factor on
> performance for any given application is much more likely to be the USB2
> interface than the fact that you have to do your crypto in software.
>
> The SC4-HSM computes an Ed25519 signature in about half a second.  I
> haven’t timed P256, but it seems about the same.
>

Half a second is painful.  I suspect that can be sped up with custom
assembly code, but I would prefer ECC acceleration here: preferably a nice
wide multiplier.  I can't find the NXP K81 ECC acceleration speeds.  I
can't find a reference manual or user guide either, which is a potential
huge problem.  Does NXP require an NDA to have access to their K81 user
manual?  That would make it very hard to use in an open system.  However,
at least they claim to have ECC hardware acceleration, and that likely
gives it a 10X speed boost.

In some similar applications, ECC took about 1/3 the time with hardware
acceleration, since I do multiple ECC operations per transaction.

> Flash would be divided between the virtual machine emulator and the
> application it runs, so each app only gets a fraction of flash memory.  The
> K81's 256KiB of flash seems low, but probably good enough.  The 1MiB of
> the  STM32F405R is a nice upgrade.
>
> Do you think a SC4-HSM might be close to supporting this application's
> needs?  If not, would you have any interest in having my help developing a
> new HSM that would?
>
>
> As you have noted, the SC4-HSM has more than enough RAM and Flash for your
> needs, but it was not designed for high-throughput.  It was designed to be
> e.g. a U2F token or a bitCoin wallet for personal use by a single
> individual who carries it around in their pocket.  A significant portion of
> the cost is in the display (not just the hardware but the assembly costs
> associated with it) which you don’t need in a data center.
>

It looks very good to me for its intended purpose, and I still want one.


> However, if you want to explore a low-cost HSM for data center use I would
> be more than happy to discuss it with you.
>
> Getting hardware into data centers is mind bogglingly difficult and takes
a very long time.  I am interested in open security modules partly so I can
make progress on algorithms without waiting for hardware to appear in data
centers.

Your device is close to what I am looking for.  There is also a $50 dev
board for the K81, which might make a good dev platform, if I can ever find
the user manual for the K81.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170726/3613d171/attachment.html>