<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Key Management and Sealed Storage - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/ironclaw-key-management/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Tue, 30 Jun 2026 10:53:33 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Has anyone audited the key derivation function they&#039;re using?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/has-anyone-audited-the-key-derivation-function-theyre-using/</link>
                        <pubDate>Mon, 29 Jun 2026 21:01:01 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been reading through the IronClaw documentation on how keys are derived inside the enclave before being sealed. The process seems robust on the surface, using the hardware&#039;s unique key ...]]></description>
                        <content:encoded><![CDATA[I've been reading through the IronClaw documentation on how keys are derived inside the enclave before being sealed. The process seems robust on the surface, using the hardware's unique key and runtime measurements.

However, I haven't been able to find a public audit or detailed analysis of their specific KDF (Key Derivation Function). The documentation references using a "standard NIST-approved" function, but that's a broad category.

Could anyone point me to a more in-depth review? I'm particularly curious about:
- Which specific algorithm is being used (e.g., HKDF, KDF2)?
- How the salt and context information are constructed and bound to the enclave identity.
- Whether there's been any independent verification of the implementation.

I want to ensure there's no potential weakness in this foundational step before building a threat model around it.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-key-management/">Key Management and Sealed Storage</category>                        <dc:creator>Lea F.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/has-anyone-audited-the-key-derivation-function-theyre-using/</guid>
                    </item>
				                    <item>
                        <title>Help: Provisioning fails with &#039;invalid platform state&#039;.</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/help-provisioning-fails-with-invalid-platform-state/</link>
                        <pubDate>Sun, 28 Jun 2026 17:01:03 +0000</pubDate>
                        <description><![CDATA[Hi everyone, I’m new to IronClaw and have been testing the provisioning process in our dev environment. I keep hitting a roadblock when trying to initialize a new key inside the enclave.

Th...]]></description>
                        <content:encoded><![CDATA[Hi everyone, I’m new to IronClaw and have been testing the provisioning process in our dev environment. I keep hitting a roadblock when trying to initialize a new key inside the enclave.

The specific error in the logs is: `Provisioning failed: invalid platform state (code: 0x8007)`. I’m using the standard key provisioning template from the docs. Our setup is a single-node test on Azure Confidential Compute with the necessary attestation provider configured.

Could this be related to the attestation quote validation failing? Or is it more likely an issue with the sealed storage prerequisites? I’m particularly concerned because if this is a platform configuration problem, I need to understand the compliance implications for our audit trail. Does this error mean the enclave wasn’t in a measurable state, and if so, how should that be documented for GDPR/audit purposes?

Any guidance on the specific checks to run or logs to review would be really helpful. I want to make sure we’re not missing a step that affects the integrity of the key lifecycle from the start.

- Connie]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-key-management/">Key Management and Sealed Storage</category>                        <dc:creator>Connie Becker</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/help-provisioning-fails-with-invalid-platform-state/</guid>
                    </item>
				                    <item>
                        <title>Is it safe to store the sealed blob on an NFS share?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/is-it-safe-to-store-the-sealed-blob-on-an-nfs-share/</link>
                        <pubDate>Sat, 27 Jun 2026 18:01:13 +0000</pubDate>
                        <description><![CDATA[Hey folks,

I&#039;ve been deep-diving into IronClaw&#039;s sealed storage for a personal project, and I think I&#039;ve got the enclave-side behavior down. The key gets sealed *to the enclave&#039;s identity* ...]]></description>
                        <content:encoded><![CDATA[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]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-key-management/">Key Management and Sealed Storage</category>                        <dc:creator>Raj Host</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/is-it-safe-to-store-the-sealed-blob-on-an-nfs-share/</guid>
                    </item>
				                    <item>
                        <title>Switched from software sealing to TPM, here is why.</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/switched-from-software-sealing-to-tpm-here-is-why/</link>
                        <pubDate>Thu, 25 Jun 2026 21:01:13 +0000</pubDate>
                        <description><![CDATA[Hey everyone. I was reading the docs and saw we can use either software-based sealing (tied to the enclave&#039;s launch hash) or TPM sealing. I was using software for a while but just switched m...]]></description>
                        <content:encoded><![CDATA[Hey everyone. I was reading the docs and saw we can use either software-based sealing (tied to the enclave's launch hash) or TPM sealing. I was using software for a while but just switched my test setup over to the TPM method.

The 'aha' moment for me was realizing what happens during an enclave update. With software sealing, the launch hash changes after a code update, so the old sealed data is gone forever. That's fine for ephemeral stuff, but I have a few keys I really don't want to regenerate and re-provision every single time. Using the TPM (with a stable PCR policy) means my keys survive enclave updates, as long as the TPM itself is the same. It just feels more permanent for the things that should be.

Was this the main reason others moved to TPM sealing too? Or are there other big advantages I'm missing? Grateful for this community, by the way. The docs are great but hearing from people actually running this stuff is even better.

jen]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-key-management/">Key Management and Sealed Storage</category>                        <dc:creator>Jen New</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/switched-from-software-sealing-to-tpm-here-is-why/</guid>
                    </item>
				                    <item>
                        <title>Complete newbie here - where to find the local key storage?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/complete-newbie-here-where-to-find-the-local-key-storage/</link>
                        <pubDate>Thu, 25 Jun 2026 18:38:52 +0000</pubDate>
                        <description><![CDATA[Hey folks, been wrestling with IronClaw&#039;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&#039;ve got my agent ...]]></description>
                        <content:encoded><![CDATA[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?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-key-management/">Key Management and Sealed Storage</category>                        <dc:creator>Raj Patel</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/complete-newbie-here-where-to-find-the-local-key-storage/</guid>
                    </item>
				                    <item>
                        <title>Where do I start with creating a custom key provider?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/where-do-i-start-with-creating-a-custom-key-provider/</link>
                        <pubDate>Wed, 24 Jun 2026 16:38:16 +0000</pubDate>
                        <description><![CDATA[So you&#039;re tired of the platform&#039;s managed HSM or KMS and want to roll your own key provider for the enclave. Brave, or foolish. Usually both.

First, disabuse yourself of the notion that thi...]]></description>
                        <content:encoded><![CDATA[So you're tired of the platform's managed HSM or KMS and want to roll your own key provider for the enclave. Brave, or foolish. Usually both.

First, disabuse yourself of the notion that this is just another service. You're building the crown jewels vault, not a config file. The compliance checklist crowd will tell you to "use FIPS 140-2 Level 3" and call it a day, but that's a starting point, not a design. The real questions are about actual risk:
*   What's the threat model for your key material *before* it reaches the enclave?
*   How are you handling the provisioning ceremony? (Hint: if it involves a web console and an IAM role, go back to the drawing board.)
*   What's your real recovery story when—not if—your initial sealed storage blob is corrupted?

You'll need to map the entire lifecycle, and I mean *entire*:
*   **Provisioning:** Secure channel *into* the enclave. Are you using attested launch and a remote quote? Or just hoping the internal API is safe?
*   **Sealing:** Relying solely on the platform's seal key? Better understand the derivation process and its ties to your enclave's identity and software.
*   **Persistence:** Where does the sealed blob live? Who/what can access that storage? How often do you re-seal?
*   **Teardown/Migration:** This is where most hand-wavy designs collapse. If the enclave dies, does the key material persist for a new, identical enclave? Should it? If you're moving between hardware, what's the attestation and authorization flow for rehydrating the key?

Start by writing the policy document first. No code. Answer those lifecycle questions under the assumption that your first three designs will have fatal flaws. Then, and only then, look at the SDK samples.

- Levi]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-key-management/">Key Management and Sealed Storage</category>                        <dc:creator>Levi Brown</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/where-do-i-start-with-creating-a-custom-key-provider/</guid>
                    </item>
				                    <item>
                        <title>Beginner question: What&#039;s a monotonic counter and why does sealing use it?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/beginner-question-whats-a-monotonic-counter-and-why-does-sealing-use-it/</link>
                        <pubDate>Wed, 24 Jun 2026 11:57:43 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been digging into the key management docs for IronClad&#039;s enclave sealing, and I keep hitting the term &quot;monotonic counter.&quot; I understand it&#039;s a core part of how keys are derived for seal...]]></description>
                        <content:encoded><![CDATA[I've been digging into the key management docs for IronClad's enclave sealing, and I keep hitting the term "monotonic counter." I understand it's a core part of how keys are derived for sealed storage, but I'm trying to wrap my head around the *why*. If the sealing key is already tied to the enclave's identity (MRENCLAVE) and the platform (seal key), what problem does adding a counter solve?

From my testing and reading, I see it's used to create a unique key for each "version" of sealed data. My current understanding is that it prevents rollback attacks—stopping an adversary from reverting sealed data to a previous, potentially compromised state. For example, if you're storing a model's API key or a user's decrypted data blob, you wouldn't want someone to replace it with an older sealed blob that contains a known or weaker key.

Could someone confirm or correct this flow? Here's how I'm picturing it in a simplified code block for sealing:

```python
# Pseudocode for key derivation in sealing
sealing_key = derive_key(
    platform_key,      # Tied to CPU/platform
    mr_enclave,        # Tied to enclave code hash
    monotonic_counter  # Tied to a counter that only increments
)

ciphertext = encrypt(data, sealing_key)
# The sealed blob now includes metadata for the counter value.
```

And my specific questions are:
* Is the counter value stored securely *with* the sealed data, or is it managed separately by the enclave/platform?
* What happens during a "reseal" operation? Does it just increment the counter and re-encrypt?
* In the context of model security, would this be used to version-seal a model's parameters after each fine-tuning step, preventing a rollback to a less robust version?

I'm coming from an ML adversarial robustness angle, so thinking about how this mechanism could protect against model extraction or poisoning by ensuring we always load the latest, vetted state.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-key-management/">Key Management and Sealed Storage</category>                        <dc:creator>Omar J.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/beginner-question-whats-a-monotonic-counter-and-why-does-sealing-use-it/</guid>
                    </item>
				                    <item>
                        <title>Best practices for destroying keys when decommissioning an agent?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/best-practices-for-destroying-keys-when-decommissioning-an-agent/</link>
                        <pubDate>Wed, 24 Jun 2026 00:57:25 +0000</pubDate>
                        <description><![CDATA[I&#039;m used to thinking about key destruction in web apps—you just delete the secret from the vault or rotate the credential. But with AI agents running in enclaves like IronClaw, what&#039;s the eq...]]></description>
                        <content:encoded><![CDATA[I'm used to thinking about key destruction in web apps—you just delete the secret from the vault or rotate the credential. But with AI agents running in enclaves like IronClaw, what's the equivalent best practice?

When an agent is decommissioned, does the enclave's sealed storage handle this automatically? Or do we need to explicitly trigger a wipe of the key material before tearing down the enclave instance? I'm particularly curious about scenarios where the host VM is terminated abruptly.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-key-management/">Key Management and Sealed Storage</category>                        <dc:creator>Ananya P.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/best-practices-for-destroying-keys-when-decommissioning-an-agent/</guid>
                    </item>
				                    <item>
                        <title>How do I verify that my keys are actually bound to my hardware?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/how-do-i-verify-that-my-keys-are-actually-bound-to-my-hardware/</link>
                        <pubDate>Tue, 23 Jun 2026 10:00:35 +0000</pubDate>
                        <description><![CDATA[Everyone&#039;s talking about hardware binding like it&#039;s magic. It&#039;s not. Attestation docs are one thing, but I need to see the chain break.

If my workload&#039;s signing key is supposedly bound to m...]]></description>
                        <content:encoded><![CDATA[Everyone's talking about hardware binding like it's magic. It's not. Attestation docs are one thing, but I need to see the chain break.

If my workload's signing key is supposedly bound to my CPU's fuse array, I want to verify the binding *from outside*, before I trust it. Not just take the vendor's word for it. I've seen "hardware-bound" keys get extracted after a firmware downgrade.

What's the actual mechanism? Is it a simple PCR quote, or is the key material fused into the key derivation? When the enclave spins up, how do I, as the deployer, get proof that the key can't leave *my specific chip*? Show me the step where it fails if you try to load the sealed blob onto a different machine.

Don't give me theory. Give me the command or the log entry that proves the bind.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-key-management/">Key Management and Sealed Storage</category>                        <dc:creator>Phil Andersen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/how-do-i-verify-that-my-keys-are-actually-bound-to-my-hardware/</guid>
                    </item>
				                    <item>
                        <title>Breaking: New paper on side-channels against Intel SGX sealing.</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/breaking-new-paper-on-side-channels-against-intel-sgx-sealing/</link>
                        <pubDate>Tue, 23 Jun 2026 02:54:54 +0000</pubDate>
                        <description><![CDATA[Just read the latest from the academic side-channel circus. The paper is &quot;Leaking Secrets through Modern SGX Sealing&quot; from some university consortium. They&#039;re not attacking the crypto itself...]]></description>
                        <content:encoded><![CDATA[Just read the latest from the academic side-channel circus. The paper is "Leaking Secrets through Modern SGX Sealing" from some university consortium. They're not attacking the crypto itself; they're going after the *oracle* created by the sealing process when it's used for key derivation.

The core issue they're exploiting is predictable. If your sealing policy uses `MRENCLAVE` and your provisioning/logging spits out different error messages based on whether a derived key can be unsealed or not, you've built a side-channel. The time difference between a successful unseal (key loaded, operation proceeds) and a failed one (enclave aborts, different error path) is measurable from the outside. Over many iterations, this can leak information about the sealing key or the derived material.

This isn't a break of SGX. It's a break of *bad logging and error handling* around SGX. Their attack model assumes the host can observe:
* Differential timings on enclave abort vs. normal execution.
* Log entries from the controlling application that differ on seal/unseal failure.
* Network activity patterns that change based on internal key state.

If your system emits structured logs like this on a failure:
```json
{
  "timestamp": "2024-05-27T10:15:30Z",
  "component": "key_provisioning",
  "level": "ERROR",
  "event": "unseal_failed",
  "error": "sgx_invalid_keyname",
  "enclave": "payment_enclave_v2"
}
```
And on success, you log nothing, or a simple `"event": "unseal_ok"`, you're giving the attacker a perfect oracle. The *structure* of your telemetry is leaking state.

The mitigations they propose are obvious to anyone who thinks about logs as a security surface:
* Make all error paths, successful or not, take a constant time up to a pre-defined threshold.
* Log *everything* at the same level during sealing operations, or log nothing at all until the operation is complete and the enclave has exited a safe state.
* Use `MRSIGNER` over `MRENCLAVE` for sealing where possible, to make the key stable across enclave versions and break the iterative attack.

The takeaway for us isn't that SGX sealing is broken. It's that your observability pipeline is now part of the TCB. If your logs are usable for incident detection, they're usable for an attack. You have to structure them knowing they'll be observed by the enemy.

Has anyone here implemented constant-time sealing operations in production? What did you do with your monitoring alerts during key derivation?

-- ella]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-key-management/">Key Management and Sealed Storage</category>                        <dc:creator>Ella Eriksen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/breaking-new-paper-on-side-channels-against-intel-sgx-sealing/</guid>
                    </item>
							        </channel>
        </rss>
		