5 ms·

Calling this an HSM is somewhat disingenuous, as it seems to contain none of the usual defenses found in a "real" hardware security module, like tamper self-des

Calling this an HSM is somewhat disingenuous, as it seems to contain none of the usual defenses found in a "real" hardware security module, like tamper self-destruction of key material, and likely no side-channel protection. This is essentially just putting your keys on a dedicated computer, connected over USB. That does have value, mind you. Keeping your keys isolated definitely makes it harder for malware to exfiltrate them, and a "trusted UI" makes it clearer to the end user what's happening.

lisper 10y ago
> 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.
- mcpherrinm 10y ago
  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!
  - lisper 10y ago
    > 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!
    - mSparks 10y ago
      just thinking out loud. definately not disagreeing with your hardware choice. a good idea for a pi zero?
      - lisper 10y ago
        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.
        mSparks 10y ago
        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/ 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.
    - amluto 10y ago
      >> 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.
      - lisper 10y ago
        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.
  - brians 10y ago
    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.
  - zimmerfrei 10y ago
    >> 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.
    - serendipitous 10y ago
      > 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.
- kosma 10y ago
  > 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.
  - mkj 10y ago
    Nice, I'd wondered how hard that would be. Could you share details?
    - kosma 10y ago
      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.
      - lisper 10y ago
        Nice! But it sounds like it would not be effective against RDP level 2.
  - lisper 10y ago
    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.]
    - kosma 10y ago
      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.
captainmuon 10y ago
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.
- technion 10y ago
  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.
  - lisper 10y ago
    > 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.

lisper 10y ago

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

mcpherrinm 10y ago
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!
- lisper 10y ago
  > 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!
  - mSparks 10y ago
    just thinking out loud. definately not disagreeing with your hardware choice. a good idea for a pi zero?
    - lisper 10y ago
      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.
      - mSparks 10y ago
        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/ 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.
  - amluto 10y ago
    >> 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.
    - lisper 10y ago
      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.
- brians 10y ago
  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.
- zimmerfrei 10y ago
  >> 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.
  - serendipitous 10y ago
    > 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.
kosma 10y ago
> 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.
- mkj 10y ago
  Nice, I'd wondered how hard that would be. Could you share details?
  - kosma 10y ago
    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.
    - lisper 10y ago
      Nice! But it sounds like it would not be effective against RDP level 2.
- lisper 10y ago
  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.]
  - kosma 10y ago
    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.

captainmuon 10y ago

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.

technion 10y ago
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.
- lisper 10y ago
  > 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.