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