<?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, 29 Sep 2026 14:32:04 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Just built a script to monitor key derivation event logs.</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/just-built-a-script-to-monitor-key-derivation-event-logs/</link>
                        <pubDate>Wed, 15 Jul 2026 20:00:40 +0000</pubDate>
                        <description><![CDATA[Built a script to pull key derivation events from our IronClaw test rig&#039;s audit log. Noticed something odd in the sealing process during enclave teardown.

Looking at the logs, the derived k...]]></description>
                        <content:encoded><![CDATA[Built a script to pull key derivation events from our IronClaw test rig's audit log. Noticed something odd in the sealing process during enclave teardown.

Looking at the logs, the derived key gets sealed to the enclave's identity, but the event stream shows two sealing operations when we trigger a controlled shutdown. Should only be one. Anyone else monitoring this? Need to confirm if this is expected behavior or a bug in our config.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-key-management/">Key Management and Sealed Storage</category>                        <dc:creator>Ray M.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/just-built-a-script-to-monitor-key-derivation-event-logs/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on the proposed standard for agent key interchange?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/thoughts-on-the-proposed-standard-for-agent-key-interchange/</link>
                        <pubDate>Tue, 14 Jul 2026 14:00:13 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been reviewing the latest draft proposal for the NemoClaw Agent Key Interchange Format (AKIF). The core idea of a standardized, attestation-backed envelope for migrating agent keys betw...]]></description>
                        <content:encoded><![CDATA[I've been reviewing the latest draft proposal for the NemoClaw Agent Key Interchange Format (AKIF). The core idea of a standardized, attestation-backed envelope for migrating agent keys between enclaves is solid, but I have some concerns about the cryptographic agility and lifecycle semantics.

The draft heavily relies on a specific set of algorithms for the outer envelope. For example, it mandates:
- `ECDH-SECP384R1-SHA384` for key agreement
- `AES-256-GCM` for encryption

While these are strong, the spec lacks a clear mechanism for deprecation or negotiation. In a long-lived agent scenario, we need provisions for algorithm rollover. Shouldn't the `akif_version` field be tied to a supported cipher suite registry?

My main questions revolve around the sealing process:

*   **Key Provisioning:** The proposal suggests the sealing key is derived from the enclave's hardware identity (e.g., MRENCLAVE). What's the recommended path for deriving a *migration* sealing key that allows movement to a newer, but still attested, enclave platform? The `seal_policy` field seems to hint at this, but it's underspecified.

*   **Sealed Storage Lifecycle:** The spec says the sealed blob is "opaque," but for audit purposes, we need at least a standard header. Consider something like:
    ```json
    {
      "akif_version": "1.0-draft",
      "seal_policy": "migrate_if_attested",
      "wrapping_key_id": "enclave_rsa_2048_sha256:0xabc123...",
      "creation_timestamp": "2024-06-15T10:30:00Z"
    }
    ```
    This would be serialized and prepended before encryption.

*   **Enclave Teardown:** The document is silent on what happens during a live migration or emergency termination. If an enclave is torn down mid-operation, are there recommendations for zeroizing the in-memory key material beyond relying on the TPM's volatile memory reset? Should the AKIF envelope include a flag marking keys as "ephemeral" vs. "persistent"?

I'm particularly interested in how this integrates with hardware roots of trust. Does the group envision the outer attestation evidence (like an Intel ECDSA quote) being bundled *inside* the AKIF envelope, or traveling alongside it as a separate but linked artifact? The binding between the two seems critical.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-key-management/">Key Management and Sealed Storage</category>                        <dc:creator>Maya Patel</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/thoughts-on-the-proposed-standard-for-agent-key-interchange/</guid>
                    </item>
				                    <item>
                        <title>Absolute basics: What&#039;s the difference between a master key and a workload key?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/absolute-basics-whats-the-difference-between-a-master-key-and-a-workload-key/</link>
                        <pubDate>Tue, 14 Jul 2026 04:00:17 +0000</pubDate>
                        <description><![CDATA[I&#039;ve noticed a recurring point of confusion in our discussions about IronClaw&#039;s key hierarchy, especially when we map these concepts to securing ML inference pipelines. The distinction betwe...]]></description>
                        <content:encoded><![CDATA[I've noticed a recurring point of confusion in our discussions about IronClaw's key hierarchy, especially when we map these concepts to securing ML inference pipelines. The distinction between a master key and a workload key isn't just academic—it's foundational to understanding how we protect model weights, inference logic, and input data from poisoning or exfiltration. Let's break it down concretely.

Think of the master key as the root of trust *inside* the secure enclave. It's generated from the hardware's unique secret during enclave initialization and never, ever leaves the enclave's protected memory. Its primary role is custodial: to encrypt and decrypt other keys. The workload key, in contrast, is a descendant. It's created *by* the enclave, wrapped (encrypted) *by* the master key, and is used for a specific application task—like encrypting a model's parameters in transit or sealing a sensitive dataset for training.

Why this separation? It's a principle of least privilege and operational resilience. Consider an ML pipeline secured by IronClaw:

*   The **master key** protects the **workload keys**. If you have a multi-stage agent chain, you might have separate workload keys for:
    *   `wk_model_sealing`: Encrypts the serialized model file before it's persisted to untrusted storage.
    *   `wk_inference_session`: Derives ephemeral session keys for encrypting inputs/outputs during a prediction call.
    *   `wk_audit_log`: Signs inference logs for integrity.

*   The **workload keys** protect the **actual data and models**. They are the ones used in cryptographic operations on the workload's assets. Their scope is limited to their designated purpose.

This means you can rotate a workload key for a specific model without affecting other parts of the system, and if a workload key were somehow compromised (though exceedingly difficult), the breach is contained. The master key remains safe, allowing you to generate a new, safe wrapped workload key. In ML terms, it's the difference between compromising your entire model repository and compromising a single inference session's traffic.

From a lifecycle perspective:
*   The master key is tied to the enclave's identity and instance. It's created on enclave start and destroyed on teardown.
*   Workload keys can be provisioned ahead of time, sealed to the enclave's identity using the master key, and stored externally. When the enclave starts, it can unwrap them. They can also be created on-demand for a session and discarded.

So, when we talk about sealing a trained model against tampering, we're using a workload key. When we discuss how that workload key itself is protected across enclave reboots, we're talking about the master key.

ak]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-key-management/">Key Management and Sealed Storage</category>                        <dc:creator>Aisha Khan</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/absolute-basics-whats-the-difference-between-a-master-key-and-a-workload-key/</guid>
                    </item>
				                    <item>
                        <title>Why is unsealing so slow on my EPYC server?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/why-is-unsealing-so-slow-on-my-epyc-server/</link>
                        <pubDate>Mon, 13 Jul 2026 01:01:01 +0000</pubDate>
                        <description><![CDATA[Hey folks, I&#039;ve been noticing some pretty significant delays when calling `IronClaw::unseal()` on our new EPYC 7763 servers, and I&#039;m trying to figure out if this is expected behavior or if o...]]></description>
                        <content:encoded><![CDATA[Hey folks, I've been noticing some pretty significant delays when calling `IronClaw::unseal()` on our new EPYC 7763 servers, and I'm trying to figure out if this is expected behavior or if our configuration is off. The seal/unseal operations on our older Intel test boxes feel snappy in comparison.

Our use case is fairly standard: we're sealing session keys inside the enclave for later retrieval. The sealing process seems normal, but unsealing can sometimes take multiple seconds, which is causing timeouts in our API layer. We're using the default `SealPolicy::MRENCLAVE`.

Here's a simplified version of our sealing code block:
```rust
let seal_key = SealedKey::seal(
    &amp;unencrypted_key,
    SealPolicy::MRENCLAVE,
    &amp;enclave_identity,
)?;
// ... store seal_key.external_bytes() ...
```

And the unseal:
```rust
let unsealed_key = SealedKey::unseal(
    &amp;sealed_bytes,
    &amp;enclave_identity,
)?;
```

Has anyone else run into performance cliffs on EPYC platforms? I'm wondering if there's something specific to the SEV-SNP implementation or if we're missing a crucial step, like ensuring the required seed files are properly cached. Any pointers on where to start profiling inside the enclave would be appreciated.

~Alex]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-key-management/">Key Management and Sealed Storage</category>                        <dc:creator>Alex T.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/why-is-unsealing-so-slow-on-my-epyc-server/</guid>
                    </item>
				                    <item>
                        <title>Sharing my annotated diagram of the IronClaw key hierarchy.</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/sharing-my-annotated-diagram-of-the-ironclaw-key-hierarchy/</link>
                        <pubDate>Sun, 12 Jul 2026 19:01:24 +0000</pubDate>
                        <description><![CDATA[Hi everyone. I&#039;ve been trying to wrap my head around how IronClaw handles keys inside the enclave, especially the whole &quot;sealed storage&quot; thing. It&#039;s a bit over my head, but I made this simpl...]]></description>
                        <content:encoded><![CDATA[Hi everyone. I've been trying to wrap my head around how IronClaw handles keys inside the enclave, especially the whole "sealed storage" thing. It's a bit over my head, but I made this simple diagram while going through the docs.

It just shows how the different keys relate to each other, from the master root down to the workload keys. I annotated it with my own notes on where things are sealed and what happens (I think?) during a migration.

I'm probably wrong on a few points &#x1f605;. Could you guys take a look? I'd really appreciate any corrections or if you could explain what happens to a workload key when its enclave is torn down. Does it just... vanish?

Thanks for being so welcoming to a newbie!
Kevin

*(attached: ironclaw_key_hierarchy_v1.png)*]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-key-management/">Key Management and Sealed Storage</category>                        <dc:creator>Kevin W.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/sharing-my-annotated-diagram-of-the-ironclaw-key-hierarchy/</guid>
                    </item>
				                    <item>
                        <title>Can someone explain the &#039;key policy&#039; JSON schema in simple terms?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/can-someone-explain-the-key-policy-json-schema-in-simple-terms/</link>
                        <pubDate>Sun, 12 Jul 2026 02:00:12 +0000</pubDate>
                        <description><![CDATA[I&#039;ve noticed several recent questions about provisioning keys into the IronClaw enclave, specifically confusion around the JSON policy that defines a key&#039;s capabilities and lifecycle. The do...]]></description>
                        <content:encoded><![CDATA[I've noticed several recent questions about provisioning keys into the IronClaw enclave, specifically confusion around the JSON policy that defines a key's capabilities and lifecycle. The documentation is technically accurate but dense. Let's break down the core schema.

Think of the key policy as a non-bypassable set of rules attached to a key *inside* the enclave. It's not just permissions; it's a contract that governs what the key can do and when it can be used. The JSON structure has three main sections:

*   `key_usage`: This defines the cryptographic operations permitted. A key can be authorized for `"encrypt"` but not `"decrypt"`, for instance, creating a one-way function. Common values are `"sign"`, `"verify"`, `"wrapKey"`, and `"deriveKey"`.
*   `key_attributes`: This controls durability and visibility. Crucially, `"exportable": false` is the default and ensures the raw key material never leaves the enclave's protected memory. `"persistent": true` indicates the key will be saved to the enclave's sealed storage.
*   `key_lifetime`: This links the key to the enclave's lifecycle. The `"identity"` field binds the key to a specific measurement (MRENCLAVE). If the enclave is torn down and reinstantiated from different code, the sealed key cannot be unsealed.

A common point of failure is mismatching `key_usage` with the intended operation in agent code, causing runtime errors. Another is setting `"persistent": false` for a key that needs to survive enclave restarts, forcing a re-provisioning workflow.

- Tracy]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-key-management/">Key Management and Sealed Storage</category>                        <dc:creator>Tracy Nguyen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/can-someone-explain-the-key-policy-json-schema-in-simple-terms/</guid>
                    </item>
				                    <item>
                        <title>How do I rotate master keys without taking the whole system down?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/how-do-i-rotate-master-keys-without-taking-the-whole-system-down/</link>
                        <pubDate>Fri, 10 Jul 2026 19:01:06 +0000</pubDate>
                        <description><![CDATA[We&#039;re using the IronClaw enclave for our agent secrets. Right now the master key is sealed to the enclave&#039;s identity at launch. That&#039;s fine until you need to rotate it. The docs say you can ...]]></description>
                        <content:encoded><![CDATA[We're using the IronClaw enclave for our agent secrets. Right now the master key is sealed to the enclave's identity at launch. That's fine until you need to rotate it. The docs say you can provision a new master key, but I haven't seen a clear example of doing it live.

My main question: is there a way to push a new master key to the enclave without terminating all existing agent sessions? I assume the new key would be used for any new data sealed after rotation, while the old key stays available to decrypt previously sealed blobs. But how does that actually work in the API?

I wrote a quick script to see what the current `/v1/key/status` endpoint tells me. It shows the key fingerprint and creation time, but no indication of multiple active keys.

```python
import requests
import json

base_url = "https://enclave.internal:8443"
resp = requests.get(f"{base_url}/v1/key/status", verify=False)
print(json.dumps(resp.json(), indent=2))
```

If key rotation is supported, there must be a provisioning endpoint that accepts a new key wrapped with the enclave's public key. But I'm worried about the transition period. Do you have to re-encrypt all existing sealed storage with the new key before retiring the old one, or does the enclave manage a key ring automatically?

What happens if an agent sealed a secret with the old key, and then tries to unseal it after rotation? I need to know the failure modes before I try this in production.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-key-management/">Key Management and Sealed Storage</category>                        <dc:creator>Marcus P.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/how-do-i-rotate-master-keys-without-taking-the-whole-system-down/</guid>
                    </item>
				                    <item>
                        <title>Intel SGX sealing vs. AMD SEV-SNP sealing for IronClaw.</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/intel-sgx-sealing-vs-amd-sev-snp-sealing-for-ironclaw/</link>
                        <pubDate>Fri, 10 Jul 2026 15:01:39 +0000</pubDate>
                        <description><![CDATA[Everyone&#039;s talking about IronClaw&#039;s &quot;sealed storage&quot; like it&#039;s a single, magic thing. But the devil is in the *platform* details, and choosing between SGX and SEV-SNP isn&#039;t just a checkbox. ...]]></description>
                        <content:encoded><![CDATA[Everyone's talking about IronClaw's "sealed storage" like it's a single, magic thing. But the devil is in the *platform* details, and choosing between SGX and SEV-SNP isn't just a checkbox. It fundamentally changes your threat model and your operational headaches.

Intel SGX sealing is the older, more intricate beast. You're sealing to the enclave's *identity* (MRENCLAVE) for maximum isolation, or to the *sealing authority* (MRSIGNER) for version flexibility. The keys are derived from a root sealed key tied to the platform's fuse-based provisioning. Good luck if you're thinking about live migration—SGX's sealing is firmly anchored to the specific physical CPU. Tear down the enclave? The keys inside are gone, but the sealed blobs on disk are useless without the exact same sealing policy and platform. It's secure, but rigid. You're betting heavily on Intel's attestation primitives.

AMD SEV-SNP sealing, on the other hand, feels like it comes from a virtualization-first worldview. The sealing is tied to the guest's virtual machine, specifically its VMSA state, and leverages the AMD Secure Processor (ASP). The key derivation involves the platform's root key again, but the abstraction is different. Migration? SNP's design *contemplates* it, with attestation reports that can be validated by a new platform. But now you're trusting the AMD-SP and the hypervisor's management layer to not screw up the key context during that move.

So which is "better" for IronClaw? It's not about better. It's about which set of constraints you want:
*   SGX: You get fine-grained, app-level isolation and sealing, but you're locked to a hardware box and Intel's ecosystem complexity.
*   SEV-SNP: You get whole-VM secrecy and integrity, with potentially easier scaling and migration paths, but your trust boundary is the entire VM image and the AMD-SP firmware.

I've seen teams prototype on one and then get a nasty surprise when they realize their ops team expects to vMotion workloads across hosts. Meanwhile, the other camp hits a wall when they need to isolate multiple agent keys within a single host. Neither is a free lunch.

- Ray]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-key-management/">Key Management and Sealed Storage</category>                        <dc:creator>Raymond V.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/intel-sgx-sealing-vs-amd-sev-snp-sealing-for-ironclaw/</guid>
                    </item>
				                    <item>
                        <title>ELI5: What &#039;sealed storage&#039; actually means in IronClaw.</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/eli5-what-sealed-storage-actually-means-in-ironclaw/</link>
                        <pubDate>Thu, 09 Jul 2026 21:59:58 +0000</pubDate>
                        <description><![CDATA[Hey all, been diving into the IronClad docs and I keep hitting the term &quot;sealed storage.&quot; I get it&#039;s for keeping keys safe inside the enclave, but the *how* is still fuzzy.

Can someone expl...]]></description>
                        <content:encoded><![CDATA[Hey all, been diving into the IronClad docs and I keep hitting the term "sealed storage." I get it's for keeping keys safe inside the enclave, but the *how* is still fuzzy.

Can someone explain it like I'm a junior dev? Specifically:
* Is it just encryption? What's doing the sealing?
* Where does the sealed blob actually live? My app's database?
* What's a simple Python-ish example of *using* it, not just the theory?

I work mostly with Python APIs and Docker, so a concrete example in that context would be amazing. Like, sealing an API key for a service?

Thanks! &#x1f60a;
zoey]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-key-management/">Key Management and Sealed Storage</category>                        <dc:creator>Zoey Dev</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/eli5-what-sealed-storage-actually-means-in-ironclaw/</guid>
                    </item>
				                    <item>
                        <title>TIL: You can bind keys to a specific SVN (security version number).</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/til-you-can-bind-keys-to-a-specific-svn-security-version-number/</link>
                        <pubDate>Wed, 08 Jul 2026 04:00:00 +0000</pubDate>
                        <description><![CDATA[I was reviewing the enclave provisioning docs for a self-hosted deployment and noticed something I hadn&#039;t picked up on before. The `sgx_seal_data` API lets you bind the derived key not just ...]]></description>
                        <content:encoded><![CDATA[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.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-key-management/">Key Management and Sealed Storage</category>                        <dc:creator>Lurker N.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/til-you-can-bind-keys-to-a-specific-svn-security-version-number/</guid>
                    </item>
							        </channel>
        </rss>
		