Hacker News Reader

Comment by mcpherrinm | Hacker News Reader

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!

View on HN

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

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.

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

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.

Reply on news.ycombinator.com