
Secure Hardware and Open Source: An Alternative to Java Card - murzika
https://medium.com/@Ledger/secure-hardware-and-open-source-ecd26579d839
======
lisper
Here is a fully open secure hardware device:

[https://sc4.us/hsm/](https://sc4.us/hsm/)

(Please don't submit this link to HN. I want to stay somewhat stealthy until
I've had a chance to write an introductory article.)

At the moment it's only a prototype. I have done a very small production run,
so if you want one to experiment with, contact me. I'm planning on doing a
kickstarter to fund a real production run.

~~~
dfox
One thing that seems to be missing from your project is the actual "HSM-ness".
Things like side channels and so probably are not relevant to the target
market, but some kind of assurance that device's firmware was not tampered
with is probably required.

~~~
btchip
Well side channel attacks should be very relevant for all projects involving
security. And several similar projects have already been produced (see TREZOR,
KeepKey in the Bitcoin space), based on a similar chip which is in my opinon
not great for that kind of use case (the fuse protection mechanism is not
certified, the chip doesn't offer any protection against active physical
attacks and so on) - that's well explained in the original Yubico article.

~~~
lisper
The SC4-HSM is not designed to be secure against physical compromise, but it
can be made resistant against such attacks by encrypting the keys with a pass-
phrase. This is not a perfect solution because the pass-phrase needs to be
entered through a non-secure host, but it's better than nothing. An attacker
would need to compromise the pass phrase _and_ obtain physical possession in
order to mount a successful attack.

~~~
dfox
With this security model it is in essence no better than plain USB flash
drive. I would assume that adding at least some protection against physical
attacks could be reasonably simple and would greatly expand the usefulness of
the device (eg. making it somehow inherently tamper-evident and replacing the
DFU bootloader with something custom and open that does the same thing as RDP
Level 1, but without the bricking risk)

~~~
lisper
> With this security model it is in essence no better than plain USB flash
> drive

I disagree. With the right firmware, the SC4-HSM can securely generate keys
that cannot be compromised without decapping the chip.

------
pjmlp
So what measures does this "secure" C alternative offer against memory
corruption to be positioned as better option than Java Card?!

~~~
btchip
It's based on public ARM specifications (MPU + service calls) so the attack
surface is way smaller compared to a virtual machine and the performance is of
course way better. Applications can still corrupt their own memory space
temporarily (not rewrite their code) but can't touch other applications or the
Operating System.

~~~
pjmlp
So I don't see any benefit to go from possible logical errors to possible
logical errors + memory corruption bugs.

~~~
btchip
the benefit is running native ARM code that you can verify vs running slow
interpreted code in a black box. Have a look at the SHA-512 implementation in
Java Card quoted in the article and it should be fairly obvious why you want
to avoid that kind of pain.

------
mkesper
This is relevant for things like OpenPGP Card
([http://g10code.com/p-card.html](http://g10code.com/p-card.html)) etc.
Running free software on practically non-researchable proprietary platform is
worrying.

------
pwlb
It's gonna be hard if you really want security. Card developers put a lot of
effort into securing operations against sidechannel pertuberation, sidechannel
and many more attacks, that opensource developers will hardly be able to
handle on theeir own.

~~~
btchip
This architecture allows you to move gradually from certified libraries
(included in the proprietary HAL) to your own custom libraries when you're
satisfied with the result.

------
TD-Linux
Was there a justification why the Ledger Blue still has a proprietary HAL?

~~~
btchip
yes, some parts of the chip are still available only under NDA (typically
I/Os, cryptographic accelerators, tamper detection)

