Security model

What it provides, and what it declines

flare-encrypt provides four properties and honestly declines four. Every guarantee is stated with its residual risk, so nobody markets past the crypto. It provides:

• Confidentiality at rest — a D1 read alone yields only ciphertext and wrapped DEKs; the master key lives outside D1.
• Placement integrity — a ciphertext or wrapped-DEK BLOB relocated to another tenant, column, or version fails the AES-GCM tag.
• Freshness / anti-rollback — a per-(tenant, column) anchor { version, ciphertext_hash } in a Durable Object outside D1 is verified on every read, so a D1-write rollback fails on read, not merely on an after-the-fact alarm.
• Bounded blast radius and crypto-shred — per-tenant DEKs cap per-key exposure and enable O(1) key destruction, after its erasure windows close.
• Sign-without-export — a signing key (Ed25519 or ES256) born inside the store is rehydrated extractable:false per sign call, so no code path can return the private key; every signature is capability-scoped and audited with a hash of what was signed.

It does not provide the following, and these are assumed controls documented loudly rather than pretended away:

• Access control — the encryption context is placement integrity, not authorization. Cross-tenant read isolation rests entirely on token scoping.
• Protection against full-account compromise — an adversary who holds both the KEK store and D1 (or a Worker that can call env.KEK.get() and read D1) reads everything.
• Host-level plaintext hygiene — the CLI writes no plaintext file, but OS swap, core dumps, and the process environment remain the host's responsibility.
• Key commitment — raw AES-256-GCM offers none; each ciphertext is under exactly one DEK, with no multi-recipient message.

The assumed-control boundary

The single most important line: a fully-compromised Worker that can both call decrypt()and read D1 defeats every control below. flare-encrypt reduces blast radius, closes relocation, and anchors freshness in a Durable Object so a D1-write rollback fails on read — but it is not a defense against owning the account it runs in. A breach that rewrites both D1 and the freshness DO still wins.

Trusted (compromise here defeats the design): the master key and the code path that reads it; the isolate executing the SDK; D1 write-integrity and the freshness DO's integrity; the operator's Cloudflare account and credentials. Untrusted (the design defends these): a D1 read in isolation, ciphertext relocation or rollback by a write-capable attacker, over-scoped tokens, the supply chain, and the CLI host.

What each layer defends

The encryption context = placement integrity

The per-tenant-DEK plus context scheme prevents relocation: copy tenant A's blob into tenant B's row and the GCM tag fails. It does nothing to stop an authorized-but-over-scoped token from reading tenant B legitimately, and it is not freshness — two values of the same secret encrypt under the same DEK with a byte-identical context, so their tags are mutually valid. The context is placement integrity, full stop.

Tenant isolation = scoped tokens

A token scoped { project, env, tenant: NULL } reads and exports every tenant's plaintext in that environment through the front door — the store faithfully derives each tenant's context and decrypts. So tenant isolation rests entirely on token scoping: the default is per-tenant tokens, a tenant = NULL wildcard requires an explicit admin orsecrets:export-all capability, and scope resolution compares on immutable IDs and verifies each resolved row is a child of the previous, closing confused-deputy and IDOR paths.

The freshness anchor = anti-rollback on read

A sharded freshness Durable Object holds the authoritative { version, ciphertext_hash }outside D1. Adding version to the context cannot fix rollback — the attacker controls that column too — so the fix lives outside the row entirely, committing to a hash of the currentciphertext. A single-D1-write attacker who rolls a secret back is rejected on read with astale_ciphertext 409. The residual is that the DO is on the read path (an availability dependency that fails closed), and a full-account attacker who writes both D1 and the DO still defeats it.

Per-environment KEK = bounded blast radius

The KEK is per-environment: each environment holds its own key bytes, and a leaked KEK unwraps only its own environment's tenant DEKs. A KEK plus a D1 read compromises that one environment permanently, but no other — the wrap context binds each DEK to its environment via the globally-unique tenant id. Proactive rotation does not contain such a breach; compromise-driven rotation of the affected environment does.

Crypto-shred = honest erasure

Dropping a tenant's wrapped DEK makes its ciphertext unreadable through the live database in O(1), but "permanently unreadable, O(1), done" is false as an immediacy claim. Erasure only completes atmax(D1 Time-Travel window, retained-KEK-version lifetime, DEK-cache TTL) — Time Travel restores up to 30 days, a recovered DEK stays unwrappable while its KEK version is retained, and a cached handle survives up to the cache TTL. The store reports that true completion time.

Audit = hash-chained and mirrored

The audit log is hash-chained so any deletion or edit breaks the chain or leaves a sequence gap, and it is streamed to an immutable Logpush → R2 sink with Object Lock. The chain detects tampering but does not prevent it; the immutable mirror is the only evidence that survives full-account compromise, which is what lets a security engagement answer "your account, not ours" with proof rather than assertion.

Threat register

Each guarantee is paired with its residual risk or the control that is assumed to hold.