Loomworks — Level C key-management infrastructure scoping note

Version. 0.1 Date. 2026-06-13 Status. Infrastructure scoping note. Names the decision and the options for moving the key-encryption key (KEK) out of the process environment into a key-management service (Level C of the key-custody hardening). Not a change request — the change request follows once the Operator picks an option. No engine change implied here. Parent. standing-notes/loomworks-standing-note-confidentiality-posture-v0_1 (Rung 1, key custody); scoping-notes/loomworks-key-custody-hardening-scoping-note-v0_1 (Levels A/B/C); the Levels A+B change request (in flight) builds the pluggable KEK seam this note's chosen option plugs into. Provenance. Operator (Marvin Percival) direction — chose B+A+C on 2026-06-13, with C carried here because it is an infrastructure decision, not engine code. Landscape rests on vendor and standards sources verified 2026-06-13 (cited in the HTML companion's notes; this is a means-to-decide, not legal or procurement advice).

Plain-language summary

What this decides. Where the key-encryption key lives once it leaves the process environment. The Levels A+B change request makes the KEK pluggable — obtained through an interface with an environment-backed implementation for now. Level C swaps that implementation so the KEK lives in, and is used inside, a key-management service the running process never holds in the clear. This note lays out the realistic options against the actual DUNIN7-M4 / Cloudflare-tunnel deployment, so the Operator can pick one before its change request is drafted.

Why it is its own decision. Levels A and B are engine code. Level C is an infrastructure and trust choice — which service, on what trust model, with what failure modes and operational burden — that the engine work cannot make for you and should not be rushed into the same unit. It also interacts with the confidentiality-posture work: a key-management service that DUNIN7 controls is custody hardening (Rung 1); it is not the customer-held-key Rung 2. Do not let the two blur — Level C makes DUNIN7's own key custody much stronger; it does not, by itself, make a confidentiality claim against DUNIN7.

What the Operator decides. One of four options (below). A lean is given.

1. What Level C changes, precisely

In envelope encryption (built by Levels A+B), data is encrypted with a data encryption key (DEK); the DEK is wrapped by a key-encryption key (KEK); the wrapped DEK is stored beside the ciphertext. Today the KEK would sit in the process environment — readable wherever the environment is readable.

The Level C move: the KEK never exists in the clear in the process. The process generates a DEK locally, encrypts data with it, and asks the key-management service to wrap the DEK; to read, it asks the service to unwrap. The KEK stays inside the service. The consequence that matters: reading the process environment, or a memory dump of the running engine, no longer yields the KEK — an attacker (or a compelled production, or a malicious insider) must now also compromise the key-management service, which logs the access and can revoke it.

This is the strongest custody posture short of the customer holding the key themselves (which is Rung 2, a different arc).

2. The deployment constraint that shapes the options

Loomworks runs on DUNIN7-M4 (a Mac Mini) behind a Cloudflare tunnel. This is not a standard cloud-hosted posture where a cloud KMS is the obvious default — the engine runs on owned hardware, reached through the tunnel, not inside a cloud provider's compute. That shapes every option:

• A cloud KMS means the engine on the M4 calls out to the cloud on every wrap/unwrap — a network dependency and latency on the cryptographic path, and a trust relationship where the cloud provider now mediates access to your keys.
• An on-premise hardware security module means hardware attached to or near the M4 — strongest custody, highest operational burden, a single physical site.
• A self-hosted software key service means another service to run and secure on infrastructure you control.

There is no free option; each trades custody strength against operational burden, latency, and an external trust relationship.

3. The four options

Option 1 — Cloud KMS (e.g. a major provider's managed KMS)

The KEK lives in a cloud provider's managed key-management service (FIPS-validated hardware behind it); the engine calls the cloud to wrap/unwrap DEKs.

• Buys: strong, audited, revocable key custody with no hardware to run; rotation is a service operation; mature, well-understood integration.
• Costs: the engine on the M4 now depends on reaching the cloud on the cryptographic path — network latency per wrap/unwrap (mitigated by wrapping DEKs, not data: the service is only touched per-DEK, not per-record-read, and DEKs can be cached in memory for a session); an availability dependency (if the cloud KMS is unreachable, new encryption/decryption stalls); and a trust relationship — the cloud provider mediates access to your keys and could, under its own compulsion, be a point of legal reach. For a confidentiality-sensitive platform, "we moved the keys to a third party's cloud" is a posture some buyers will question.

Option 2 — On-premise hardware security module (HSM) at the M4

A tamper-evident HSM (FIPS 140-2 Level 3/4) attached to or co-located with the M4 holds the KEK; cryptographic operations happen inside the hardware.

• Buys: the strongest custody — keys never leave tamper-evident hardware you physically control; no third-party mediates; low, predictable latency (local); no external availability dependency.
• Costs: highest operational burden — procuring, installing, maintaining, and securing physical hardware; a single physical site (the M4's location) becomes a single point of physical failure unless replicated; backup and disaster-recovery for the HSM itself is non-trivial; this is a real infrastructure commitment, not a configuration change.

Option 3 — Self-hosted software key service (e.g. an open-source secrets/KMS service you run)

A software key-management service running on infrastructure you control holds and uses the KEK; the engine calls it locally.

• Buys: no third-party trust relationship; keys stay on your infrastructure; more control than a cloud KMS, less hardware than an HSM; can later be backed by an HSM root if desired.
• Costs: you now run and secure another service — its own attack surface, its own availability, its own key-custody problem one level down (what protects its root key?). Done carelessly it relocates the single-key problem rather than solving it. Done well (root key in hardware or split via secret-sharing) it is strong, but the "done well" is real work.

Option 4 — Cloud KMS as KEK, with the root held externally (split/BYOK)

A hybrid: a cloud KMS does the operational wrap/unwrap, but the root is held by you (bring-your-own-key) or split so no single party — including the cloud provider — can unilaterally use it.

• Buys: the operational convenience of a cloud KMS plus defense against the cloud-provider-mediation concern of Option 1 — the provider cannot unilaterally compromise a key it does not solely control.
• Costs: the most complex to set up and operate correctly (split custody, M-of-N controls, ceremonies); the operational burden approaches Option 2's without fully escaping the cloud dependency. Strongest on the trust axis, heaviest on the setup axis.

4. Lean

Option 1 (cloud KMS) as the near-term move, designed so Option 4 (split/BYOK root) is reachable later — and Option 2 (on-premise HSM) named as the destination if the confidentiality positioning demands maximal custody.

Reasoning: the pluggable KEK seam (built by Levels A+B) makes the integration the same regardless of which service backs it — so the decision is reversible and the cheapest correct first step is the managed cloud KMS, which gets the KEK out of the process environment (the actual exposure being closed) with the least operational burden. The cloud-mediation trust concern is real but addressable by moving to Option 4's split-root model later without re-architecting (same seam). Option 2 (on-premise HSM) is the strongest custody and the right destination if the platform's confidentiality positioning — the regulated-domain buyers — makes "keys never leave hardware we physically control" a selling requirement; but it is a heavy infrastructure commitment that should be demand-pulled by a real buyer requirement, not adopted speculatively, exactly as Rung 2 is.

So: Option 1 now (closes the environment-exposure cheaply), Option 4 as the trust-hardening upgrade path (same seam), Option 2 as the maximal-custody destination if a buyer requires it. This mirrors the rung-ladder discipline — take the cheapest correct step, keep the stronger ones reachable, pull them by real demand.

One caution on the lean. Option 1 introduces a cloud dependency on the cryptographic path and a third-party trust relationship. Before committing, confirm: (a) the wrap/unwrap-per-DEK-with-session-caching pattern keeps the latency and availability impact acceptable for the engine's actual access patterns (a CC/infra check), and (b) the cloud-mediation trust posture is acceptable for the near-term customers, or that the Option 4 upgrade path is credible enough to satisfy them. If either fails, Option 3 (self-hosted) or Option 2 (HSM) moves up.

5. What the Operator does next

1. Pick an option (lean: Option 1 now, Option 4 as upgrade path, Option 2 as demand-pulled destination).
2. Confirm the two cautions on the lean — latency/availability pattern (a CC or infrastructure check) and the trust posture for near-term buyers. These are the genuine open questions; the rest is settled by the lean.
3. Once an option is chosen and the cautions clear, its change request swaps the KEK provider's implementation (built pluggable by Levels A+B) from environment-backed to the chosen service. The seam makes this a contained change, not a re-architecture.

This note does not pick for you — it is the menu and the lean. The decision is an infrastructure and trust judgment that is properly the Operator's (and the founder's, since it touches the broader DUNIN7 program's posture, not just the Loomworks engagement).

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Level C key-management infrastructure scoping note — v0.1 — 2026-06-13