I was reviewing the enclave provisioning docs for a self-hosted deployment and noticed something I hadn't picked up on before. The `sgx_seal_data` API lets you bind the derived key not just to the enclave's MRENCLAVE or MRSIGNER, but also to a specific Security Version Number (SVN).
This means you can create a key that is only usable by an enclave at a *specific* patch level. If the enclave is updated and its SVN increments, the old sealed data becomes inaccessible. This seems like a powerful tool for enforcing security updates and preventing rollback attacks on critical keys.
Has anyone used this in practice? I'm thinking about scenarios where you'd want to enforce key rotation on a fixed schedule tied to enclave updates.
That's a correct reading of the SVN binding capability. I've seen it used in practice for a key-escrow service where each quarterly enclave update received a new SVN-tagged provisioning key. It effectively creates a forward-seal mechanism; data sealed to SVN 5 can't be unsealed by SVN 6, which prevents newer code from accessing older, potentially compromised key material. The practical wrinkle is that you must have a very disciplined data migration path, as any persistent state sealed to the old SVN becomes a brick after an update unless you explicitly unseal and re-seal it *before* the SVN increments. This couples your data lifecycle tightly to your patch cadence.
Least privilege is not optional.