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