AES-256-GCM envelope · Cloudflare Worker + D1

BYOC secret manager & envelope encryption on Cloudflare.

Your master key, your D1, readable without Cloudflare's dashboard. A Worker, a D1 database, and a KEK you hold — deployed to your own account with wrangler deploy. No vendor vault, no plaintext file.

  • AES-256-GCM envelope
  • zero runtime deps
  • per-tenant isolation
KEK · per-environment wrap keykek_kvDEK · per-tenant data keydek_verciphertext9f4c a1e0 77bd 2c11e83a 5510 c6fa 0d9e ‖ tagAES-256-GCM · iv 12B · ct∥tagwrapDek()encrypt()frozen encryption context (AAD) — placement integrity{ tenant, column, dek_ver } → binds this blob to one row

The envelope

Three tiers, one un-relocatable ciphertext.

The envelope pattern AWS KMS and Google Cloud KMS use — a data key encrypts the data, a wrap key wraps the data key. flare-encrypt makes it multi-tenant and three-tier, with a mandatory encryption context on every operation.

KEK

Per-environment wrap key

In Secrets Store or a Worker Secret — never in D1. It only wraps DEKs, so KEK rotation re-wraps keys without re-encrypting a row. Per-environment material contains a compromise.

versioned by kek_kv

DEK

Per-tenant data key

One AES-256 key per tenant, stored only wrapped. Dropping its row crypto-shreds the tenant; per-tenant scope keeps the GCM nonce budget comfortable.

versioned by dek_ver

ciphertext

Bound to its row

AES-256-GCM sealed under the tenant's DEK with a frozen AAD of { tenant, column, dek_ver }. Copy the blob into another tenant's row and the tag check fails — placement integrity from crypto, not policy.

AAD = placement integrity

Confidentiality from the keys; placement integrity from the encryption context.Watch a relocation fail →

Signing keys

Sign without ever exporting the key.

Beside secrets, the store is a signing oracle: a key — Ed25519 or ECDSA P-256 (ES256) — is generated inside the store, wrapped under the same master key, and rehydrated non-extractable per sign call — the private key never crosses the API. Send a message, get a signature; verify anywhere with just the public key.

sign-only tokens

A token that signs, and nothing else

A keys:sign token — optionally pinned to one key — gets signatures but cannot read secrets, list anything, or mint keys. Give CI a release-signing credential that is worthless for exfiltration.

cap keys:sign · per-key pin

audited use

Every signature leaves a proof

Each sign call lands in the hash-chained audit log committing to the key version andsha256(message) — evidence of exactly what was signed, with the payload never logged.

key.sign { keyVer, msgSha256 }

verify offline

Verification needs no store

The SDK's verify takes just the raw public key — no KEK, no network, no account. Rotation retains prior versions so old signatures keep verifying through the grace window. Ed25519 (AWS KMS cannot sign it) and ES256 on the exact JOSE wire — rawr‖s, never DER.

Ed25519 (EdDSA) · ES256

The private key's whole life stays inside your Cloudflare boundary — honest scope: an isolate, not an HSM. Read the signing model →

What "fully own" means

Four properties, in priority order.

01

Operator-held

All key material and ciphertext lives in your account — no hosted vault, nothing in the read path.

02

Portable

Data in D1 you export, plus a KEK you hold — decrypt an export offline with the sdk, no Worker.

03

Multi-tenant by construction

A per-environment KEK wraps per-tenant DEKs, so a compromise stops at the environment. An encryption context binds each ciphertext to its row.

04

Any-runtime injection

The fe CLI streams secrets into a process via execve — never a .env file. Any runtime.

Signals it works

Testable claims, not adjectives.

  1. 01Run a real app with no plaintext on disk — fe run injects secrets via execve.
  2. 02A ciphertext copied from tenant A into tenant B fails to decrypt — the GCM tag rejects it.
  3. 03A sign-only token gets signatures, never the key — verify offline with the public key alone.
  4. 04Break-glass: a D1 export plus the KEK decrypt offline on plain Node.
  5. 05Dogfood real credentials, plus one external operator.
  6. 06“Where do our secrets live?” → “your account” — backed by a tamper-evident audit log.

Own your secrets, provably.

Step through the envelope, watch a relocation fail, then point the live panel at your store.