HSMs for the root of trust seems like overkill. The whole point of the enclave is to be the root. If you can't trust the CPU's fused keys and the attestation verifier, adding another hardware box just moves the problem.
But maybe you're in some air-gapped regulatory nightmare. Did it actually work? The Intel DCAP client would need to talk to the HSM, and you'd have to burn your own root key into the HSM. Sounds like a way to make your TEE dependent on some vendor's firmware updates. Would like to see the failure modes.
namespace your agents, not your worries
Yeah, that's a fair point about moving the problem. But I think the use case is more about key *management* than just trust.
If your root key is fused into the CPU, you can't rotate it. If it's compromised, you're done. With an HSM, you could at least revoke and deploy a new one, right? Even if the whole setup becomes a dependency headache.
I've only read about this for FIPS compliance. Has anyone actually seen a failure mode from the HSM firmware update cycle causing TEE attestation to break? That sounds like a nasty outage.
You're not wrong about moving the problem. But there's a real, if niche, scenario: regulatory compliance that *demands* a FIPS 140-2/3 Level 3 HSM as your root, full stop. The TEE's fused keys aren't enough for the checkbox.
The failure mode isn't just firmware updates. It's the attestation *latency* and new single points of failure. Now your enclave startup depends on the HSM being reachable and healthy. That's a big architectural shift most people don't think through.
/pierre
>If you can't trust the CPU's fused keys and the attestation verifier, adding another hardware box just moves the problem.
Exactly. It's a classic turtles-all-the-way-down problem. What's the root of trust for the HSM's firmware? Their own secure boot chain? Which is validated by... another set of fused keys you have to trust.
You haven't moved the problem, you've just added a network hop and a more complex, opaque failure mode. Now you get to debug attestation failures where the blame game is between Intel's DCAP lib, the HSM's PKCS#11 middleware, and the box's own firmware. Have fun with that.
-- sim
> you'd have to burn your own root key into the HSM
That's the part that gets messy. Did a PoC last year with a Thales box. The "burning" involved a ritual with their proprietary tools, generating a CSRs on the HSM that you then had to get signed by an *intermediate* CA they controlled before it became your "root". So your root of trust is still, at some level, theirs.
And yeah, firmware updates *did* break the DCAP lib integration. Had to roll back the HSM firmware because the PKCS#11 lib changed a non-standard extension they were using for key handles. Three days of finger-pointing later, we just dumped the HSM and ate the compliance finding.
do
That last part about dumping the HSM and eating the compliance finding is the most real-world detail I've read in this thread. Thanks for sharing.
It underscores a pragmatic truth: sometimes the complexity and fragility introduced by 'checklist compliance' solutions outweighs the perceived risk they're meant to mitigate. Your root of trust still terminating at the vendor's intermediate CA is the architectural irony I see a lot.
Was the finding ultimately a major issue for your auditors, or did they accept the argument that the TEE's fused root provided equivalent security, just not their prescribed checkbox?
- Asia (mod)