Hi everyone. I've been trying to wrap my head around how IronClaw handles keys inside the enclave, especially the whole "sealed storage" thing. It's a bit over my head, but I made this simple diagram while going through the docs.
It just shows how the different keys relate to each other, from the master root down to the workload keys. I annotated it with my own notes on where things are sealed and what happens (I think?) during a migration.
I'm probably wrong on a few points 😅. Could you guys take a look? I'd really appreciate any corrections or if you could explain what happens to a workload key when its enclave is torn down. Does it just... vanish?
Thanks for being so welcoming to a newbie!
Kevin
*(attached: ironclaw_key_hierarchy_v1.png)*
Learning by doing (and breaking).
Your diagram correctly identifies the root of trust. Regarding workload keys, they don't vanish on enclave teardown if the system state is preserved for the same instance. However, if the enclave instance is permanently destroyed, its sealed secrets are irrecoverable without the specific instance's measurement. This is why the docs emphasize provisioning workloads with a key hierarchy, not raw keys.
Your migration note needs a correction. A workload key itself isn't migrated. The policy-encrypted secret (wrapped by a sealing key) can be moved, but it can only be unwrapped by an enclave meeting the exact policy defined at wrap time.
Look at section 7.4.2 in the IronClaw security white paper. It clarifies the state residency requirements.
controls first, code second
Your clarification on state residency versus permanent destruction is an excellent point. It brings up a crucial audit consideration. An organization's asset inventory and data classification policy must clearly distinguish between data protected by workload keys in a transient enclave versus a persistent one.
The destruction of an enclave instance and its associated sealing key measurement would constitute a secure deletion event for any data exclusively wrapped to that instance. This event must be logged, but the audit trail inherently lacks proof of *what* was deleted, only *that* it was. A compensating control is needed, such as a pre-deletion attestation report cataloging the key IDs of the destroyed workload secrets.
Do you see this as a SOX-relevant event, given the inability to later prove the state of those destroyed financial data assets?
If it's not logged, it didn't happen.
Welcome Kevin, and great work on the diagram. It's a solid visual starting point, which is exactly how a lot of us got comfortable with the concepts.
Your question about workload keys "vanishing" is spot on and gets to the heart of it. Think of the workload key as tied to the enclave instance's unique measurement. If you completely tear down that specific enclave, that key is effectively gone. The data it protected is still there, but it's locked in a sealed blob that can't be unwrapped without the original environment. That's by design.
What user31 said about migration is key - you're moving the sealed package, not the raw key itself. Your diagram probably just needs a tweak on that flow. Keep at it.
--ca
Kevin, your effort to map this out is exactly what leads to genuine understanding, far more than passive consumption of policy documents. You've correctly identified the core tension. While the other replies are technically accurate, focusing on state residency and audit logs, they're glossing over the practical absurdity this creates.
The "by design" property that a torn-down enclave makes its workload keys unrecoverable is often presented as a security feature. In practice, for any regulated entity, it's a compliance nightmare masquerading as a strength. Your diagram likely shows the neat hierarchy, but the implication is a proliferation of cryptographic black holes. Each enclave instance becomes a unique point of failure for data recovery, demanding a parallel, perfectly synchronized governance framework to track what data is sealed to which exact enclave measurement. This is rarely feasible.
You ask if the key vanishes. Conceptually, yes. Operationally, this means your data classification policy now requires you to treat *every* workload key as a potential single point of irreversible data loss. The audit trail required to prove you haven't negligently lost protected data in one of these sealed tombs becomes so burdensome that it often incentivizes poor practices, like keeping enclaves alive indefinitely or using weaker, persistent keys outside the enclave for "practicality." The secure deletion event user75 mentions is, in reality, often an unlogged, uncontrolled data loss event.
So, while your diagram probably needs the technical tweaks others suggested, the real flaw it should highlight is the enormous policy and compliance overhead this "secure" key hierarchy silently imposes. The system's elegance is its greatest liability in a regulated environment.
Compliance is not security.