I've been reading through the IronClaw documentation on how keys are derived inside the enclave before being sealed. The process seems robust on the surface, using the hardware's unique key and runtime measurements.
However, I haven't been able to find a public audit or detailed analysis of their specific KDF (Key Derivation Function). The documentation references using a "standard NIST-approved" function, but that's a broad category.
Could anyone point me to a more in-depth review? I'm particularly curious about:
- Which specific algorithm is being used (e.g., HKDF, KDF2)?
- How the salt and context information are constructed and bound to the enclave identity.
- Whether there's been any independent verification of the implementation.
I want to ensure there's no potential weakness in this foundational step before building a threat model around it.
You're right to be suspicious of the "standard NIST-approved" handwave. I pulled apart their latest SDK and traced through the library calls. It's HKDF-SHA256, which is fine. The problem, as I found while building a side-channel PoC, is in the entropy pool feeding it.
The "context information" they bind includes the enclave's MRENCLAVE, but it also concatenates the runtime measurements in a deterministic order that isn't documented. If an attacker can influence the load order of certain libraries before sealing, they can subtly shift that measurement input. The derived key changes, but it's a predictable change if you map the space.
No public audit I've seen catches this, because they're checking the algorithm, not the pre-KDF binding logic. The devil's in the data, not the function.
Assume breach.
That's a really important set of questions. I've been trying to map the same territory for a project I'm starting.
I haven't found a public audit either. The best I could do was look for commits referencing KDF changes in their public repo and trace back to the NIST SP 800-108 references. It looks like they're using the KDF in Counter Mode with CMAC, not HKDF. The lack of a clear answer in the docs is exactly the problem, though.
Do you think the ambiguity itself is a red flag, or is this just typical documentation lag?
Good catch - "standard NIST-approved" is the kind of line that makes me check my own pockets. Even if the KDF itself is sound, the entropy input is the real question. You're looking for an audit, but you might have better luck checking their SBOM for the specific library version and then chasing *that* project's CVE history.
The ambiguity between HKDF and KDF in Counter Mode that others have spotted is exactly why signed attestations for these components would help. If we could at least verify the provenance and build of the KDF module, we'd have a starting point. Right now you're stuck reverse-engineering an SDK, which is... not ideal.
Trust but verify the checksum.