Hey folks, been wrestling with IronClaw's sealed storage in my homelab for a few days now. Coming from a Tailscale-and-Nginx-homelab background, this is a different beast. I've got my agent deployed and the enclave is running, but I'm hitting a wall on something that feels basic.
In all the docs, they talk about keys being "sealed to the enclave." I understand the concept, but as a hands-on guy, I want to *see* the artifacts. Where does the system actually keep the local, sealed key blobs? Is it a file on the host's disk? A dedicated partition? I spun up a test instance on my Proxmox node and can't for the life of me find a persistent file that looks like a key store after provisioning.
I tried looking in `/var/lib/ironclaw` and the usual `/etc/` suspects, but no dice. My gut says it's probably a TPM-backed seal, but even then, there's got to be some persistent state written somewhere, right? Or is it all in memory?
Here's the `ironclaw-agent` config snippet I'm using, in case it's relevant:
```yaml
enclave:
provider: "sgx"
seal_storage_path: "/secure/ironclaw/seal"
key_provisioning:
source: "vault"
migration_policy: "sealed-only"
```
I pointed `seal_storage_path` to a custom location, but the directory stays empty even after successful initialization and key provisioning. So what gives? Is the "sealed storage" literally just the TPM's NVRAM or the SGX enclave's sealed data and not a file I can `ls -la` on?
Trying to map the mental model to something I can debug when, inevitably, my hypervisor host needs a reboot or I migrate the VM. What actually gets carried over?
iptables -A INPUT -j DROP
Ah, the classic "where's the file?" question. You're looking for a physical artifact, but "sealed to the enclave" is their marketing glitter for "cryptographic blob that's useless anywhere else." Your config shows SGX, so the sealed data is likely in that path you set, but it's just ciphertext. The real "key" is the enclave's measurement, which never hits disk. If you pulled the blob, you couldn't open it on another host, even with the same software. That's the whole sales pitch. Check your `/secure/ironclaw/seal` for a blob file with a funky extension, but don't expect to peek inside.
Yeah, that path in your config is exactly where it should be. On my SGX test rig, I found a `.sealed` file in the directory I specified, but like user467 said, it's just opaque binary data.
If you're not seeing anything there, check the agent logs for permission errors on that directory. The agent won't create parent directories, so `/secure/ironclaw/seal` needs to already exist with the right perms for the agent user. I made that mistake once and the logs just said "seal operation failed" without much detail.
It's a bit anticlimactic when you find it - just a blob you can't actually use for anything. But hey, that's the point, right? 😄
-- Mike
Ah, the ritual hunt for the blob. You're right to look for it, even if user467 is correct that it's just ciphertext. The real fun starts when you realize that *where* it's stored depends entirely on how the enclave provider handles the sealing operation.
Your SGX config snippet is the giveaway. On SGX, that `seal_storage_path` is literally just a directory for opaque files. But here's the part nobody talks about: the agent's runtime user needs *exclusive* write access to that directory, and often the files are created with restrictive permissions like 0600. If you're checking as root or another user, you might not even see them listed, depending on your `ls` arguments and the mount's ACLs. A lazy `ls -la` might show nothing, while `sudo -u ironclaw-agent ls -l /secure/ironclaw/seal` reveals the goods.
Your gut about TPM is interesting though. If you were using the `tpm` provider, the "blob" is often a sealed object *inside* the TPM's NVRAM, not a file at all. The path in the config might just be for metadata or becomes entirely ignored. That's a bigger headache because you can't even `rm` it to force reprovisioning. You have to clear the TPM.
So yeah, look at the directory with the agent's actual user context. And check the logs for any "sealed" or "persist" operations. If it's working, there's a blob. It's just playing hide-and-seek with your privileges.
J