Hacker News Reader

Comment by pzb | Hacker News Reader

Both Smart Cards and HSMs can (and frequently do) contain FIPS validated cryptographic modules and can be USB devices. What seems to set them apart is content capacity and speed. A "HSM" can usually store dozens, hundreds, or even tens of thousands of keys and can do numerous cryptographic operations per second. Most "smart cards" can only store a few keys and frequently 1-2 operations per second.

Many HSMs also add advanced authentication capabilities, such as M-of-N access control and/or hardware authenticators (e.g. you need 3 of 5 smart cards to use the HSM). The other key feature usually found in HSMs but not smart cards is backup/cloning without exporting the key (in PKCS#11 terms). This means that the key can be moved between HSMs with all the protections in place. I've yet to see a smart card that does this.

View on HN

> The other key feature usually found in HSMs but not smart cards is backup/cloning without exporting the key (in PKCS#11 terms). This means that the key can be moved between HSMs with all the protections in place. I've yet to see a smart card that does this.

How does this work? Can an attacker buy an identical HSM, back up the key, and restore it onto the new HSM?

Theoretically yes, though you would have to explicitly switch the original HSM into backup mode, an operation that requires one or more admins to be present and strongly authenticated, most often with smart cards.

It sounds like that's exactly how it works (two months ago):

https://news.ycombinator.com/item?id=12069784

The NitroKey HSM requires all previous setup (DKEK?) passwords and PINs. Anecdotal random unnamed vendor? Not so much:

They did, with undocumented commands, export the key from the device in an unencrypted format and loaded it into the other model

When you initialize your HSM, a key is created which is owned by you and stored in a smartcard/token. If you buy an identical HSM, you shoud need the token to restore keys into it.

>Many HSMs also add advanced authentication capabilities, such as M-of-N access control

And this is exactly my point, it's all functionality which the manufacturers have decided some customer might need. I don't want that, I want a secure general-purpose Turing-complete execution environment which gives me full flexibility in what crypto, mechanisms and policy to implement. This entire industry approach is silly.

Any old server gives you full flexibility. One key point is, what do you mean by secure? If they give this Turing-complete machine to their customers, and then the customer uses or is given the wrong software (Murphy's Law), how is it going to be assured that this is still "secure"? And are many other paying customers looking for this Turing-complete thing they can write their own software for, or don't a lot more customers want turnkey solutions to specific problems?

While these devices are turing complete machines under the hood, the interface to them is incredibly strict.

Using them from code is like using a remote API, you can't execute code, you can only make requests and receive responses, and a lot of thought it put into the interface to ensure it's as secure as possible.

As far as the physical interface, they are more like an appliance than a server, in that you don't get the normal ports you would on any other machine, the actual casing is typically alarmed so that keys are wiped when the device is opened, important circuitry is embedded in epoxy so that it's essentially impossible to attach debugging instruments without destroying it, etc.

I can't really emphasise enough how these machines are designed for security.

Reply on news.ycombinator.com