[lisper]

I foresaw this years ago, which prompted me to build this:

https://sc4.us/hsm/

It's an HSM which you can flash yourself. Unfortunately, it never generated much interest and so I had to fold up the tent. But maybe it was just ahead of its time.

[saganus]

I remember when this came out, and was interested in getting one!

Unfortunately I was aiming to use it to generate TOTP codes (and replace my authenticator app), but IIRC it needed a RT clock and thus a battery, which was not part of the design.

Great project though.

[lisper]

You could feed it time info through the USB interface.

[saganus]

That was actually my first line of thought as well, but I could never find a way to do that.

My low-level development expertise is pretty low, so perhaps there is a way, but after looking through the USB specification and other USB-development related docs, I just could not figure it out unfortunately.

The closest thing I found was to do someting like this (https://stackoverflow.com/questions/13335402/unable-to-sync-...) but I never did.

Do you think that would have worked?

[lisper]

It has been a long time since I touched that code, but the SC4-HSM came with several demos, including a FIDO U2F token, all of which used the USB interface. It would not be at all difficult to make a TOTP application that got its time from there.

[technion]

I was a huge fan of what was promised here. I ordered one but every time I tried to work with it I had some catastrophic unrelated incident - like a curse lol.

Anyway I suspect the problem is the nature of crypto. For this to actually take off, you would have needed to hand a bag of money to Jake Paul or John mcafee or a bitboy, and I'd highly suspect a really good product has a hard time competing against those that do

[lxgr]

Neat! But is the microcontroller used tamper-proof? If not, your customers are still vulnerable to supply chain attacks such as the one in the article.

[lisper]

The core hardware is actually very similar. Both use more or less the same STM32 SoC. The difference is that the Trezor comes pre-flashed in a sealed package designed not to be opened, while the SC4-HSM is designed to be flashed by the user, and the case is not sealed so it can easily be opened to inspect the hardware. So while I can't say it would be impossible, launching a supply chain attack against the SC4-HSM would be a lot harder to execute and conceal.

[lxgr]

Hm, but as a regular user, how would I make sure that what I received in the mail is actually an SC4-HSM and not an identical device that looks the part, but is running some pre-flashed firmware emulating all responses expected by a blank SC4-HSM (i.e. "I'm empty", "writing firmware with hash xyz succeeded" etc.) with high fidelity?

[lisper]

Anything is possible, but this would be extremely difficult. You can't program an off-the-shelf unit to emulate itself. The flashing sequence is a hardware function. There is an actual button that determines whether the system is coming up in flash mode or run mode after a reset. To fake the flashing sequence you would need to have a custom chip, or a custom PCB, or you would need to rewire the stock PCB so that wire went to a different pin. Not impossible, but very hard.

[lxgr]

> You can't program an off-the-shelf unit to emulate itself.

You don't need full emulation, just protocol emulation should be enough, right? This might involve having more storage than the authentic device (or getting very clever with compression) in order to e.g. be able to authentically provide a "firmware dump", and maybe run at a faster clock speed so that the timing isn't suspicious, but it still seems easier than full emulation.

> Anything is possible, but this would be extremely difficult.

I agree that it would be very difficult, but unfortunately this property sort of caps the "maximum desirable popularity" of a solution: Nobody will go through that effort for a niche/hobbyist HSM, but as soon as people start protecting serious/expensive secrets with it, somebody might just do it.

Shipping each unit with a private key only known to the vendor, and providing a one-time attestation service, could make this attack much harder to pull off at scale (as you would need to physically extract one key per fake device produced as an attacker).

[lisper]

> You don't need full emulation, just protocol emulation should be enough, right?

Yes, but you would need to bypass the hardware button that puts it in DFU mode, and you would need to do that in a way that isn't visible. Possible, but difficult. (Look at the photos of the hacked Trezor. It's obvious that it has been tampered with.)

> as soon as people start protecting serious/expensive secrets with it, somebody might just do it.

Sure, but remember, this was a self-funded one-man project. (Well, I hired a contractor to do the hardware design, and I had some code contributed by another developer, but other than that it was just me.) The idea was to test the market to see if there was any interest at all in this sort of thing. If this had gotten any traction at all I would have had the resources to put additional mitigations in place.

But even as it stood it would have been extremely difficult for an attacker to compromise these devices. They were shipped to me from the manufacturer in sealed anti-static bags, and I did the final assembly myself. By far the biggest security weakness in the process was me. If I wanted to backdoor these devices I probably could, but only because I controlled the manufacturing process. I really don't think anyone else short of a state actor could do it, not because of the technical difficulty, but because they would have to get physical access somehow without being detected.

> Shipping each unit with a private key only known to the vendor, and providing a one-time attestation service, could make this attack much harder to pull off at scale

Yes, that's a very good idea. If I had sold more than a few dozen I probably would have done something like that.