A common design pattern we're seeing in enclave applications is the generation of a master key inside the TEE, then using that key to derive other keys for specific purposes (e.g., one for database encryption, one for session tokens). The alternative is to generate and store each needed key directly inside the enclave's sealed storage.

So, which is architecturally safer for a system like IronClaw?

On the surface, derivation seems cleaner. You only have one root secret to manage and seal. If that sealed blob is migrated or recovered, you can regenerate all the derived keys. It also limits exposure; a compromise of one derived key context doesn't necessarily compromise the root.

But this introduces a critical dependency: the derivation logic itself. That logic—the KDF, the context strings, the derivation path—must be absolutely immutable and consistent across every enclave instantiation, forever. Any bug or change in that logic breaks your ability to recover the same derived keys from the same sealed root. With direct storage, each key is independent; a flaw in one doesn't cascade.

I lean towards derivation for its elegance and reduced secret footprint, but it demands flawless, versioned, and never-changing derivation code. Direct storage is more brute-force but also more resilient to changes in the application's key management logic.

What's your experience? Have you run into issues with key derivation chains after updating enclave code, or does the simplicity of direct storage win out in production?