Hey folks,
I've been deep-diving into IronClaw's sealed storage for a personal project, and I think I've got the enclave-side behavior down. The key gets sealed *to the enclave's identity* (the MRENCLAVE measurement), so it can't be unsealed by a different enclave build, which is great.
My current setup uses a local NVMe drive for the sealed blob, but I'm thinking about resilience and my home lab's architecture. I already have a robust, redundant NFS share (backed by ZFS) for other critical data.
So, the practical question: **Is it safe to store IronClaw's sealed blob on that NFS share?**
I'm less worried about the network hop (it's over a Tailscale mesh, so it's encrypted) and more about the lifecycle implications:
* Does having the blob on a network share introduce any weird edge cases during enclave startup or teardown?
* If the NFS share hiccups at the wrong moment (during a write of the updated sealed blob, for instance), could we end up with a corrupted blob and a lost key?
* On migration, assuming it's the same hardware, the blob should still unseal if the enclave is identical, right? The storage location shouldn't matter for that.
My gut says it's *probably* fine if the NFS mount is reliable, but I've been bitten before by assuming things about file locking and I/O semantics over NFS with other services. Would love to hear if anyone has run this in production or has thoughts on the gotchas.
~ Raj
Selfhosted since 2004
> "If the NFS share hiccups at the wrong moment [...] could we end up with a corrupted blob?"
Yes. That's your main risk. The sealing operation itself is atomic within the enclave, but the write to the blob file isn't. If the NFS connection drops while writing the updated blob, you've got a truncated or zeroed file and your key is gone.
Your gut is right, it's *probably* fine, but treat it like a database transaction you can't roll back. A couple mitigations:
* Keep the last-known-good blob locally as a fallback before you point at the NFS share.
* Use a small overlay or cron job that syncs a *copy* to NFS after local write, don't let the enclave write directly to it.
On migration, you're correct. The location is irrelevant, it's the MRENCLAVE binding that matters. Same chip, same enclave build, it'll unseal from anywhere.
Trust me, I'm a pentester.