Hey all, hitting a weird roadblock with my Open Claw home server setup. I rotated the keys in my KMS (Hashicorp Vault) for my enclave agent. The remote attestation to the KMS still passes perfectly, which is confusing me.
But when the enclave tries to unseal its state using the new key, it fails. Logs just show a generic seal error from the SDK. The old key still works, so it's definitely the rotation. I'm using the provided `enclave-agent` Docker image. Did I miss a step? Do I need to somehow "re-wrap" the sealing key inside the attested session? The docs mention key rotation but not this specific failure.
Hey, I'm pretty new to this myself but I just went through key rotation last week and hit the same snag. Attestation passes because that's about identity, but the seal fails because the data is literally encrypted with the old key.
In my case, the fix was stupid simple. I had to restart the `enclave-agent` container after the rotation. The agent seemed to cache the old key material internally, even though the KMS had the new one. A quick `docker restart enclave-agent` and it picked up the new key and unsealed fine.
Maybe give that a shot? The docs really should mention the restart step.
- Tom
Interesting. Your diagnosis about attestation being separate from the sealing operation is correct, but I don't think the restart suggestion is the full solution, at least not for a well-behaved system. The attestation proves the enclave's identity to the KMS, which then releases the key, but the seal/unseal operation is a local cryptographic function using that key material.
The generic seal error from the SDK is the real clue. It usually means the key material the enclave received from the KMS after attestation is not the same key material that was used to originally seal the data. A restart *might* clear a corrupted session, but the more likely issue is the key derivation or wrapping step during rotation.
> "Do I need to somehow 're-wrap' the sealing key inside the attested session?"
Possibly. Did you follow the exact key rotation procedure for your KMS provider? For Vault, you often need to re-wrap the *exported* sealing key with the new primary key *before* you retire the old one, otherwise the existing wrapped blob becomes unreadable. The agent gets the new key, but the sealed data was wrapped with the old. Check if your KMS has a "rewrap" API call for the specific key path. If you just rotated the master key and didn't re-wrap the dependent data keys, that's your failure point.
shk
Restarting the container fixes the symptom, not the problem. It just forces a fresh attestation session. The real issue is your KMS policy probably released the new *key name* to the attested enclave, but the actual data was sealed with the old *key material*. They're different objects.
So yeah, your restart works, but it masks a config problem in your key transition. The enclave should get the new key material and re-seal its state *before* the old key is deactivated. If you just rotate and swap, you're always one step behind. The docs are bad, but this is basic crypto state management, not a cache bug.