Item — HN Reader

If they could add some hardware tamper-evidence/tamper-response (design-to-meet FIPS 140-3 level 3 or EAL whatever, although no need to actually get certified), this could be super useful as a cheap application-specific HSM (which can run app logic inside, rather than the lobotomized/zombie signing oracle PKCS "HSM" use which is common.)

Obviously can prototype without this functionality, and can build out the toolchain/etc. I'm a lot more excited about Tropic Square than most alternatives, but this is shipping now.

1 comments

Regarding FIPS 140-2 level 2 tamper evidence and level 3 tamper response I'm interested to hear what you (and others here on HN) value and why.

Level 2 can be accomplished with nail polish and glitter, or plastic potting. Yubikey's potting is a good example of level 2 tamper evidence.

For level 3 tamper response, e.g. of a rack-mounted server case, it is enough to put micro-switches under the lid. For that type of product level 2 tamper evidence could be accomplished by covering the server case's screws with copper cans stamped with serial numbers.

When I first learned what is actually required for FIPS 140-2 level 2 and 3 I thought it was security theater. Then I realized that in practice such a server case will be (1) in a locked server cabinet, in a server room with access control, within a building with access control. Add a two-person requirement for entering the room and unlocking the cabinet, and the attacker will have to be quite sophisticated and capable to not be discovered way before any tamper evidence or tamper response comes into play.

In other words, if you don't care about FIPS for regulatory reasons, or insurance reasons, or company policy reasons, then how much does level 3 tamper response really matter?

Regarding CC EAL, I'll simply say that I don't believe there is any other hardware security product that is more open source hardware and software than the TKey. Thanks to it being FPGA-based it is somewhat protected from various attacks on the supply chain. If you're looking to do an Ed25519 signature I don't believe there is a single device more simple or easily verifiable than the TKey and it's Ed25519 signer application. I'd love to be proven wrong.

I was at ACM Copenhagen although more downstairs at ASHES (which my company sponsored) and DeFi. Ryan Hurst who was there is probably the best person to ask about the specific certification use cases.

But overall -- I work for an insurer. Having to document how something was done a year+ after it was done to convince auditors/insurers/large clients is a LOT easier if you can point to a specific piece of hardware vs. a bespoke process. The downside of not having tamper-evidence or tamper-response (ideally) at the hw level is you need to build a lot of other controls around it, and that is expensive, impractical, and difficult to document in a lot of environments. e.g. in a datacenter it's unlikely you can enforce "two man from security/senior executive team in the cage"; it's probably going to be (at best) two ops staff, often contractors, and two-man rule isn't actually that widely used outside CAs themselves. The use cases I'd like for this are application logic, not traditional CAs (who do need FIPS). Add to this lifecycle management of the hardware from production to pickup/delivery to provisioning, pre-deployment storage, deployment, operation, routine audit, replacement, audit, and decommissioning, and it's way easier to put protection into the module. Most of the time I've just seen hardware protection inherited from single-chip vs. module-level protection created, but if there's no certified IC available, module protection it is.

Actual FIPS certification would be nice (or a better standard), but challenging in deployment because almost every vendor FIPS certifies with a specific application load and as soon as you run custom applications (which is badly supported in the HSM world), you lose certification anyway. "FIPS rated hardware running a non-FIPS load, audited in appendix A" is insurable, but ideally there would be something better. 99+% of HSM deployments are just used as dumb key signers which are trivially exploitable when you pop the host, though, so I'd certainly take the non-FIPS option.

(Today, the state of the art is pretty much SGX or another TEE on the host running custom application logic to evaluate and instruct signing which talks to the FIPS HSM to do key control and actual signing, e.g. what Anchorage does.)

Thank you for the detailed response! Lots of good perspectives.

Ryan Hurst is great. I ended up spending several hours with him at CCS talking about HSMs.

I was mostly upstairs at CATS due to two other projects I'm involved with - Sigsum and System Transparency. Sigsum is a minimal transparency log design which uses proactive cosigning witnessing to mitigate split view attacks. In collaboration with TrustFabric (Al, Martin et al) and Filippo Valsorda we have achieved consensus on the cryptographic semantics of the witnesses, so all of us met at CATS to discuss the bootstrapping of a witness ecosystem.

I'd love to learn more about some of the things you mention!

* What standards do you consider better than FIPS in this context?

* When you say "ideally there would be something better", what would you like to have?

Something else to consider: Performance. TKey is RV32ICZmmul running at 20-ish MHz, with the on-board 16x16 bit DSPs to accelerate the multiplication instructions. If you need more than a few ECC signatures per second then you need something more powerful than the TKey.

You've already mentioned the USB Armory II elsewhere in this thread so I'm sure you've already thought of it. I'll point it out here explicitly so others might benefit as well: The USB Armory II looks to be a fantastic flexible HSM substrate. Andrea Barisani et al's work on getting it to run Go is genius. Go as firmware is genius for that matter (see TinyGo).