At least for me, this "HSM" makes the right trade-offs. I don't need tamper self-destruction, for example. My adversaries are either: 1) thieves of opportunity, or 2) the "world conspiracy" / nation state intelligence agencies who suddenly might decide to spy on me if the world takes a dystopian turn.

For 1) tamper-proofness is total overkill. For 2), I doubt that any civilian technology would withstand a hardware attack e.g. by the NSA. If I just look at the equipment we have at our lowly, underfunded physics laboratory - probe stations, decapping facilities, wirebonders, an expert can already defeat many older hardware countermeasures with that. And I know there are much more sophisticated techniques out there, e.g. to image chips and extract secrets. Also, a variation of the "wrench" argument: Who says that the vendors of closed HSMs have not all been just forced to place backdoors?

The biggest realistic threat to me (by probability times possible damage) is by far that I might catch a Trojan. This device provides at least partial protection, in that it makes it hard for a remote attacker to sign messages or log on in my name.

> I doubt that any civilian technology would withstand a hardware attack e.g. by the NSA.

You'd probably be wrong. There are several consumer accessible chips (i.e. from Atmel that you can order on digikey) that use tamper-proof silicon where the very act of opening up the package to inspect the die destroys the private key data. Even civilian tamper-proof tech is extremely robust, using physical phenomena to protect the data instead of obfuscation.

That doesn't preclude someone with the resources of the NSA from figuring it out or backdooring the design but the resources needed to defeat tamper proof devices is orders of magnitude greater than those needed to use them and that gap is constantly growing.

Well, that's probably true, but my only source for that is what people wrote on the internet. OTOH, I know e.g. the NSA has basically infinite resources.

Anecdotally, I've heard that there are ways to destructively image complete chips, and not just the layout but also the internal charge state. I believe the technique used femtosecond lasers. Of course that is also hearsay and I can't validate it.

My point is, as an interested layman, I don't know enough to trust this technology with my life - but it would be exactly useful if my life depended on keeping my secrets. So that contradiction kind of reduces its value for me.

I'm sure people with the required knowledge can properly evaluate these products, and for those people they are probably immensely useful.

I would not bet my life savings against the NSA's ability to compromise the SC4-HSM if they had physical possession. On the other hand, there is a simple defense against physical compromise that would probably hold up even against the NSA: encrypt the keys with a strong pass phrase. That wouldn't hold up against a monkey wrench attack (https://xkcd.com/538/), of course, but there are limits to what you can do for <$100.

Infinite resources don't exist.

Something I was told back when I was working around WikiLeaks is, "You can't make it impossible for them to get your goat, but you want to make it very, very expensive."

I see this as a lot like the "GPG is very secure but no one uses it" scenario. People who have certain needs can open up their wallets for certain products.

The adversary for the vast majority of practical scenarios is some remote attacker exploiting some unpatched vulnerability.

How much less of an issue would all the recent password dumps be if the hash algorithm was a simple HMAC on a device like this?

And surely a bitcoin wallet has a better chance on this device, than sitting in a file on my desktop just hoping the password never gets key logged.

And, moreso than any other point, at the current price point, this device is actually plausible to experiment with.

> at the current price point, this device is actually plausible to experiment with

Yes, that's really the idea at this point. Neither the hardware nor the firmware have been audited, so it would be unwise to use it to protect anything mission-critical at the moment (which is why there's a big disclaimer to that effect on the order page). On the other hand, the approach does seem to be holding up well to initial scrutiny.

> Calling this an HSM is somewhat disingenuous

Well, I had to call it something. I'm open to suggestions.

> tamper self-destruction of key material

That's true, but there is readout protection built into the SoC.

> and likely no side-channel protection

Side-channel protection is provided by the software, which is a side-channel-resistant implementation.

But the principal attack model is a compromised client machine, not physical compromise of the device. There's only so much you can offer for <$100.

At least in my mind, the defining attribute of an HSM is protection against physical compromise of the device.

Maybe we disagree on that definition: I guess it is hardware, and it exists for security, and it's a module.

I admit it's unfair to compare this with a $10,000 HSM from Thales or Safenet, of course. But it seems like a smartcard based solution might be better on that front, as they're designed to withstand physical attacks.

You can defend against some side channels (timing from the host, for example) but I was thinking more like EM/RF emissions.

I want to be clear that I think this is still a great project, and I commend your work so far!

>> At least in my mind, the defining attribute of an HSM is protection against physical compromise of the device.

FIPS definitions help a bit here.

A hardware FIPS 140 Level 2 cryptographic module (HSM) is only required to show evidence of tampering. A $5 broken seal if often the solution. Note that applying a seal to the module in the link is not sufficient because I can compromise the thing without opening it (just press the button and reflash with non-signed images).

Level 3 is a step up in that you must have some degree of tamper resistance, but in several cases, most of this security behemoths just drop a layer of epoxy on the board and call it a day. Then they sell it to you for $10.000.

With Level 4 things get serious, but then you can count your suppliers in on hand and pay accordingly (and Safenet is not one of them).

I agree that smartcard-based solution would be ideal, but specs and native firmware and SDK are never open, so you cannot build an open-source product with them.

> because I can compromise the thing without opening it (just press the button and reflash with non-signed images).

I don't think so. With RDP enabled the only thing the bootloader lets you do is erase all flash. After that RDP is disabled and you can write your own image but at that point the keys are already gone.

> smartcard

Those are not at all secure against compromised hosts.

> EM/RF emissions

You probably don't want to use this to secure the nuclear launch codes. But I think you'd have to work pretty damn hard to get anything out of it. There are no external parts here, it's all one SoC, one that is specifically designed to keep proprietary code out of the hands of Chinese hackers. If it were easy to attack it would lose most of its market.

> I commend your work so far!

Thanks!

>> smartcard

> Those are not at all secure against compromised hosts.

How so? Certainly there are poorly designed applications on smartcards that are vulnerable, but the smartcard itself should be fine.

If an attacker pwns your host they can do anything you can do. If you can access the smartcard, then the attacker can too. As soon as you plug the card in, the card is just as compromised as the host.

This is the reason that the SC4-HSM has a built-in display and user inputs. These serve the same purpose as the display on a PoS terminal, except that because they are a part of the HSM itself, they can't be compromised by an attacker who pwns the host that the HSM is plugged in to.

An attacker can still attempt a phishing attack, but this will be much, much harder. And for really mission-critical applications, an attacker would have to control every possible means of computing a secure hash on the host machine.

I should probably write a paper about this.

I thought that the whole point of a smartcard is that your keys, once loaded, can never be extracted again, even by the host. Rather than passing secrets to the host directly, there's a miniature PKI that does request/signature, secured by a password, using a hardware pinpad if you're very serious.

Little window for error too, since screwing up the password some small number of times results in the card being blocked, and in some cases, destroyed.

Even if the host is running hostile code, the worst it could do is forge signing requests?

> screwing up the password

If the host machine is pwned then it's not hard to steal your password.

> the worst it could do is forge signing requests

Well yeah, that's true. But if the card is protecting a really sensitive asset (like your bitcoin account) then a single forged request can do an awful lot of damage.

The point being that the malware either has to horn in on a legitimate request (and I'm not sure if that's possible or not given how PKI), or issue its own request, which the user has to authorize with password, ideally out of band using a hardware pinpad.

> ideally out of band using a hardware pinpad

Not "ideally". Critically. Without an out-of-band PIN the card is easy to compromise. And most cards don't have input devices.

And even with a secure PIN entry, without a display you can't actually know what transaction you are authorizing. So yes, the malware would have to "horn in" on a legitimate request. But if your machine is pwned that's not hard.

just thinking out loud. definately not disagreeing with your hardware choice.

a good idea for a pi zero?

You could certainly do something like this with a pi. But it would be bulkier and probably less secure. But my initial prototyping was done with a Teensy3. It all depends on your threat model.

its great that we are getting access to so many tiny sweet tiny boards. just in case - pi zero: https://www.raspberrypi.org/products/pi-zero/

i was thinking more feature set than threat model. Namely Secure at rest storage and password generator for secure comms. i believe the pi has a hwrnd which is probably the most essential thing for such devices.

We disagree on that definition. The defining attribute of an HSM is protection against software compromise of the main computer.

Having provided near-perfect defense against a software-only adversary, many HSM vendors then add layers and layers of protection for the hardware. But the real key is ensuring that someone who gets root on your server can use your keys but not copy them.

> there is readout protection built into the SoC

I have managed to bypass readout protection on STM32F1 with just a few nights of hacking and $2 in parts; I suspect F4 isn't much different. I wouldn't trust any general purpose MCU in this regard.

The RDP on the F4 is more capable than the F1. The F1 only has level 1 RDP, the F4 has level 2 as well. If you can break level 2 without decapping the chip that would be big news (and probably result in a class action lawsuit against STM). Can you describe how you did it? [EDIT: Never mind, I see you already answered that in the other branch of this thread.]

I had a look at the documentation and it seems they finally made it a JTAG fuse and not just a value in program memory. Nice move.

Nice, I'd wondered how hard that would be. Could you share details?

The FPB (flash patch and breakpoint) peripheral on Cortex-M3 allows live-patching the flash contents; this allows you to temporarily change the reset vector. That, plus careful supply voltage glitching to reset some peripherals but not other, and the device is pwned.

Nice! But it sounds like it would not be effective against RDP level 2.