Secure Hardware and Open Source: An Alternative to Java Card | Hacker News Reader

Secure Hardware and Open Source: An Alternative to Java Card

medium.com

58 pointsmurzika20 comments

Here is a fully open secure hardware device:

(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.

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.

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.

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.

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)

> 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.

the projects I quoted above have the same "security model" then

> the original Yubico article

Which article are you referring to here?

The "HSM-ness" comes from the fact that there's a hardware RNG that can be used to generate keys. Firmware assurance comes from the fact that it's user-flashable.

> 32 kB RAM

The mentioned microcontroller has 192KiB of SRAM (including 64KiB of core-coupled memory).

Speaking of which, many programmers tend to ignore the CCM but it can be very useful (though it can't be accessed from other peripherals (timers, ADC, etc.) using the DMA).

It can be used for the heap and/or stack memories, for example, freeing up the remaining 128KiB for other purposes.

It can also be used for executing your code from the memory without using the flash which is faster and more energy-efficient.

Some versions of the STM32F415 have 192k but the one I'm currently using only has 32.

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

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.

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

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.

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

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.

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.

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

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

Reply on news.ycombinator.com