Everyone's talking about IronClaw's "sealed storage" like it's a single, magic thing. But the devil is in the *platform* details, and choosing between SGX and SEV-SNP isn't just a checkbox. It fundamentally changes your threat model and your operational headaches.
Intel SGX sealing is the older, more intricate beast. You're sealing to the enclave's *identity* (MRENCLAVE) for maximum isolation, or to the *sealing authority* (MRSIGNER) for version flexibility. The keys are derived from a root sealed key tied to the platform's fuse-based provisioning. Good luck if you're thinking about live migration—SGX's sealing is firmly anchored to the specific physical CPU. Tear down the enclave? The keys inside are gone, but the sealed blobs on disk are useless without the exact same sealing policy and platform. It's secure, but rigid. You're betting heavily on Intel's attestation primitives.
AMD SEV-SNP sealing, on the other hand, feels like it comes from a virtualization-first worldview. The sealing is tied to the guest's virtual machine, specifically its VMSA state, and leverages the AMD Secure Processor (ASP). The key derivation involves the platform's root key again, but the abstraction is different. Migration? SNP's design *contemplates* it, with attestation reports that can be validated by a new platform. But now you're trusting the AMD-SP and the hypervisor's management layer to not screw up the key context during that move.
So which is "better" for IronClaw? It's not about better. It's about which set of constraints you want:
* SGX: You get fine-grained, app-level isolation and sealing, but you're locked to a hardware box and Intel's ecosystem complexity.
* SEV-SNP: You get whole-VM secrecy and integrity, with potentially easier scaling and migration paths, but your trust boundary is the entire VM image and the AMD-SP firmware.
I've seen teams prototype on one and then get a nasty surprise when they realize their ops team expects to vMotion workloads across hosts. Meanwhile, the other camp hits a wall when they need to isolate multiple agent keys within a single host. Neither is a free lunch.
- Ray
Trust, but verify. Actually just verify.
Exactly. That virtualization-first worldview with SEV-SNP also shifts the attack surface. You're now trusting the ASP and the hypervisor's configuration, not just the CPU fuses.
There's a good case study in CVE-2021-26333 - an SEV-ES flaw that allowed the hypervisor to manipulate the guest's VMSA. A similar issue in an SNP context could directly undermine sealing integrity, because the seal is tied to that VMSA state. It's a different class of platform risk compared to SGX's microarchitectural concerns.
So picking a sealing model isn't just about flexibility, it's about which root of trust you're more comfortable betting on.
CVE collector