HSMs are shit.<p>In a previous role we used a major vendor's HSM to protect our private keys. VERY expensive kit, more expensive than the load balancers and servers combined.<p>We needed to use Elliptic Curve keys for a particular customer - so it got even more expensive as we had to buy:<p>1. A license from the LB vendor to use the HSM<p>2. A licence from the HSM vendor to use EC with the LB.<p>... even though they trumpeted these announcements of how radically great they were together we found:<p>1. The integration didn't work, full stop.<p>2. The version of OpenSSL we had to use (supplied) was about 18 months out of date<p>3. The specially b0rked version of OpenSSL supplied didn't support EC via a HSM<p>Even better - when Heartbleed came out I had a patch from RedHat on day 1. The load balancer?<p>Nope - nothing on their website - I had to create a ticket which said 'we are aware of the issue', at which point the ticket was closed. I questioned this and was told they couldn't keep it open, I had to create a new ticket every few weeks to find out whether they'd actually deigned to assign a bug id to the issue.<p>The HSM vendor just said nothing, zero, until a new version of the firmware was silently released 4 months later.<p>The whole industry is shit. I'd rather have a farm of Yubikeys than one of those HSMs.
Odd -- JavaCard smartcards are available for under $5, have crypto co-processors, and certainly support general-purpose code. See for example my project for KeePass, <a href="http://code.lardcave.net/2016/08/06/1/" rel="nofollow">http://code.lardcave.net/2016/08/06/1/</a> . After programming, you can choose to lock down the card (which means you can only erase the card, not modify it). I'm using NXP chips and although I haven't investigated completely I would be highly surprised if it was not possible to get the tamper-resistant and cryptographic properties the author is after.<p>There is an open-source toolchain for generating code for the card which works great from OS X or Linux. Contactless writers are available on eBay for like twenty bucks. And they will even work (via NFC) with Android phones.<p>It's a great time to be playing with contactless general-purpose smartcards.
So FWIW, I asked about how Redhat signs their packages some time ago (about 6-7 years ago!) and was introduced to Fedora's "Signing Server" service, which is entirely open source. The email in full is:<p><pre><code> Hi Jeff, good to hear from you.
There's really two parts to our signing server; the first is the
separation of signing to a separate machine with the associated
client/server and ACL controls, and the second is the interface to the
nCipher HSM. The first part we've not made open because it's quite
specific to Red Hat internal build systems and our kerberos setup.
The second part is mostly straightforward use of nCipher utilities but
includes a patch to GNUpg which I was originally going to make public
but came into difficulty because it requires headers from the nCipher
developer kit, and linking to it, and it's under a very non-compatible
license. Given the cost of nCipher HSM units we didn't think other
projects would want that solution either.
So I'd actually prefer to point you to the work that has been done on
a signing server for Fedora, which is open. See
http://fedoraproject.org/wiki/ReleaseEngineering/Projects/SigningServer
The Fedora folks looked into various hardware solutions too which were
cheaper and didn't have the proprietary API issues, I can't find a
link to that at the moment but Jesse Keating
should be able to give you more info.
Hope that's a good starting point...
</code></pre>
If anyone is interested, the project is actually named Sigul and is located at:<p><a href="https://fedorahosted.org/sigul/" rel="nofollow">https://fedorahosted.org/sigul/</a>
I'd like to address the difference between a SmartCard and an HSM as I feel like the author doesn't acknowledge some of the practical differences. While at the core they are both "hardware security", i.e. a physical chip that implements security, an "HSM" as I have commonly seen the term used is a completely different thing in most other ways.<p>An HSM is typically a 1-2U server, that is designed to provide high throughput of cryptographic operations. It is ultimately a collection of a few high performance servers networked together, with some custom ICs - not just a small chip. As a result, you pay up to tens of thousands of dollars for one, because it's a piece of critical infrastructure that is made to high tolerances. It's akin to buying hardware load balancers or firewalls appliances.<p>In addition to this, the validation process of an HSM is long. An HSM company will likely have teams of hardware engineers, software engineers, and specialised cryptography teams. There are audits for things like FIPS compliance, as well as extensive pentesting by external companies. All of this is expensive, to create a device that will never be mass market.
He mentions yubikey in the title, but then nowhere else. The Yubikey Neo seems to be pretty close to his target device. The Yubikey 4 removed the ability to write new apps.<p>The stuff about the NDA I do find alarming. In order to write "secure" programs for the chip on the Yubikey, you must have an NDA with the manufacturer. In fact the open source pgpcard app for the Yubikey is different than what ships with the Yubikey because they can't open source the secure bits. Which is a bit upsetting. So uploading the open source version weakens your security.<p>That said, having my keys there still gives me much higher degree of security then an encrypted file on my computer. Malware may be able to get my pin, but not my keys.
This site is down so I was not able to read the original article, but I would like to take this opportunity to draw HN's attention to my current project:<p><a href="https://sc4.us/hsm" rel="nofollow">https://sc4.us/hsm</a><p>It's a fully open USB HSM based on an STM32F405 SoC. Includes an HWRNG, 1MB Flash, and 196k of RAM. Currently runs TweetNaCl and also functions as a FIDO U2F token. Technical details are here:<p><a href="https://sc4.us/hsm/manual.html" rel="nofollow">https://sc4.us/hsm/manual.html</a><p>Currently out of stock but we will be shipping again in early January.
The issue of affordable HSM/TPM for general purpose use is something my research group is trying to solve. We have most of the theory down, but the implementation is a work in progress. The key point is trying to maintain full physical isolation from the CPU and OS, while also providing general low-level computing capabilities.<p>Do you guys think something like this could be patented and/or commercialized?
Has the author seen the SC4-HSM I wonder? <a href="https://sc4.us/hsm/" rel="nofollow">https://sc4.us/hsm/</a><p>Show HN thread: <a href="https://news.ycombinator.com/item?id=12053181" rel="nofollow">https://news.ycombinator.com/item?id=12053181</a>
How does something like the U2F Zero[1] compare?<p>As I understand it, the u2f zero acts as an HID device and not as a smartcard provider, but could one modify the firmware to do that? Isn't this basically an open source yubikey you can make yourself for < $25?<p>1. <a href="https://github.com/conorpp/u2f-zero" rel="nofollow">https://github.com/conorpp/u2f-zero</a>
This is the key quote:<p><pre><code> The feature table also lists various supported
applications, demonstrating the interest of the
manufacturer in programming the device for specific
applications, rather than providing a platform for others
to do so. (Imagine if manufacturers of USB drives made USB
drives for text files and USB drives for image files and
USB drives for MP3 files and so on, and the idea of selling
a USB block device was alien to these people. If you wanted
to store a new kind of file on a USB drive, you had to
convince the manufacturer to implement support for it.) The
draw of the Nitrokey then is the possibility the
manufacturer merely incidentally allows alternate firmware
to be flashed, rather than the manufacturer explicitly
capitalising on the premise of an HSM as a general-purpose
platform.
</code></pre>
Great point, and completely lost on manufacturers.
I'm the author of the article.<p>After musing on the comments here I wrote a followup about improv HSMs. These aren't tamperproof and as such are suitable for use in secure datacentres only. <a href="https://www.devever.net/~hl/improvhsm" rel="nofollow">https://www.devever.net/~hl/improvhsm</a>
The author brings up many reasonable points but seems to mix issues of HSMs & Smart Cards not providing a generic open hardware platform with possible security problems of a platform.<p>There is no question that there would be value in having a hardware platform that has certain security features, but that alone doesn't meet the requirements of most users of HSMs and Smart cards. The primary use cases I've seen are allowing a third party to have assurance of protection of data stored in the device and assurance of the rules for accessing the data. In most cases this assurance comes from a combination of the hardware itself and the software/firmware running on the hardware. A hardware platform only solves half the problem that most purchasers of HSMs and smart cards are asking vendors to solve.
The author is not thinking about why these things are built and marketed as they are.<p>The use case for the smart card is different than a HSM with FIPS 140-2 level 3 or 4 validation. The whole point is to operate in a tested, known valid state while resisting tampering. The higher level devices are filled with epoxy and have other anti-tampering features.<p>A smartcard is most often a form of MFA. It can be used as an HSM of sorts, but offers limited benefit for that purpose.
What is the problem to take a 10$ stm32f discovery board and use it as TPM. There are different flash protections:<p>1) you can read/write flash via JTAG<p>2) you can only write flash, but not read the old one<p>3) you can't rewrite flash, neigher can you read it.<p>You will still have to implement USB communication, but there is already a lib from STM for it. Some models also have generous flash (in MB ranges).<p>You can use internal SRAM which is more than enough and use AES acceleration peripherial. One can attach sdcard and use SPI + DMA + AES periherial to shuffle data along if one needs alot of storage.
Since zooming won't fix the line width, here's a quick fix - paste into the console:<p><pre><code> var article = document.querySelector('article'); article.style['max-width'] = '650px'; article.style['margin'] = '0 auto';</code></pre>
The OP states:<p>"Smartcards and HSMs are essentially two “brands” for the same thing: a chip which guards access to the data stored within it, and will only allow that data to be accessed in certain ways or under certain conditions. HSMs are the “enterprise” label for such devices, whereas smartcards are essentially the same thing, only cheaper."<p>Yubikey(mentioned in the title) is a TOTP card that works with the HSM on the far end though. They serve different purposes. You load the tokens into the HSM device.<p>They aren't the same thing. What am I missing?
This is a somewhat older rant (at least 2015, I think). And the title is misleading. It is really "Why I wish there were a product similar to but different than smartcards, HSMs, YubiKeys, etc." Because there isn't much in there that argues why smartcards (or yubikeys, etc.) are not good at what they do. The author just wants a different thing, and doesn't understand why this fantasy product doesn't exist.
It's not exactly in small card form, but someone looking for a general-purpose programmable tamper-proof computer might be interested in the ORWL: <a href="https://www.crowdsupply.com/design-shift/orwl" rel="nofollow">https://www.crowdsupply.com/design-shift/orwl</a>
For the microchip itself, I'm pretty sure this already exists.<p>Try looking at nRF52. It has NFC, Bluetooth radio, and hardware RNG. I'm pretty sure it has the features he asks for (firmware can lock down and block reading/writing from debug port. but debug can always do a complete erase/reset of the chip)<p>A future SKU will probably have USB as well.<p>The only problem is it is probably too power hungry to be powered by the NFC radio waves itself. And that is probably true for anything with an powerful ARM microcontroller.<p>Maybe it'd be best to use a microcontroller with ARM TrustZone as well though. That should help bring the security of the device up to a more acceptable level.
What about the FST-01? It's what I use and it works pretty well in my experience. <a href="http://wiki.seeedstudio.com/wiki/FST-01" rel="nofollow">http://wiki.seeedstudio.com/wiki/FST-01</a>
Would that answer OP's needs: <a href="https://www.ledgerwallet.com/products/9-ledger-blue" rel="nofollow">https://www.ledgerwallet.com/products/9-ledger-blue</a> ?
The statement that "all HSMs and smartcards are the same" shows limited understanding. High-end HSMs can take 1000s of hits per second, a smartcard only a few.
I am curious to hear why the device you are looking for should be a compact and portable device. You listed it as your very first requirement so it must be a must-have.
Speaking of which, whatever happened to Google's Project Vault? Did it die after Mudge quit Google? It looked so promising.<p><a href="https://www.youtube.com/watch?v=V6qrQzn8uBo" rel="nofollow">https://www.youtube.com/watch?v=V6qrQzn8uBo</a>
I'm quite a big fan of OPs work and I think that if they take some time with JavaScript they will change their "Let me be clear about this: JavaScript sucks. It’s not the worst, but it’s also not by any means good" opinion.<p>Check out JavaScript the Good Parts. It's a great language hidden under a layer of horrible horrible design choices.