Envelope Encryption DEK/KEK Architecture Design Prompt
Design an envelope-encryption scheme — per-object data keys wrapped by a KMS-held key-encryption key — with key rotation, caching, and blast-radius limits that survive a key compromise.
- Target user
- Platform and application engineers building field- or object-level encryption on top of a cloud KMS
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior security engineer who has designed envelope-encryption schemes on cloud KMS for data that must stay encrypted at rest at the field or object level. I will provide: - What data is being protected and its granularity (per-record, per-tenant, per-object) — [DATA SCOPE] - The KMS in use (AWS KMS, GCP KMS, Azure Key Vault, Vault Transit) — [KMS] - Throughput and latency requirements for encrypt/decrypt — [PERFORMANCE] - Threat model and compliance drivers (who must not read this, tenancy, residency) — [THREATS] Your job, step by step: 1. **DEK/KEK structure** — design the layering: a per-object/per-tenant data-encryption key (DEK) that does the bulk symmetric encryption, wrapped by a key-encryption key (KEK) that never leaves the KMS. Specify DEK generation (KMS GenerateDataKey vs local with KMS wrap) and where the wrapped DEK is stored alongside the ciphertext. 2. **Blast radius** — choose DEK granularity to limit exposure: a single DEK for everything means one leak exposes everything; per-tenant/per-object DEKs contain it. State the tradeoff against key-management overhead. 3. **KEK access control & rotation** — design KMS key policy / IAM so only the intended service can call Decrypt, enable KEK rotation, and explain how DEK re-wrapping (not data re-encryption) handles KEK rotation cheaply. Address how often DEKs themselves rotate and what that costs. 4. **DEK caching** — to meet throughput, design plaintext-DEK caching with a short TTL and memory-only storage, and state the tradeoff (cache hit reduces KMS calls and cost but widens the window a memory-scrape attacker has). 5. **Failure & audit** — define behavior when KMS is unreachable (fail-closed for new writes), how decrypt calls are logged for audit, and how to detect anomalous decrypt volume. 6. **Crypto hygiene** — specify the AEAD cipher (e.g. AES-256-GCM), per-encryption nonce handling, and authenticated associated data binding ciphertext to its context to prevent confused-deputy reuse. Output as: (a) the key-hierarchy diagram-in-words, (b) the encrypt and decrypt flow step by step, (c) the KMS key policy + rotation runbook, (d) the caching config with its stated risk, (e) the audit/alerting plan. Present as a design for security review — flag any choice that trades blast radius for convenience, and recommend a cryptographer review the final scheme before it protects production data.
Why this prompt works
Envelope encryption is the standard way to get field- or object-level encryption without hammering a KMS on every operation, but it has a few choices that quietly decide whether a key compromise is a contained incident or a total breach. The biggest is DEK granularity: one data key for everything is cheap to manage and catastrophic if it leaks, while per-tenant or per-object keys contain the blast radius. This prompt makes that tradeoff explicit rather than letting the model default to the convenient single-key design.
The prompt also handles the two operational details that teams get wrong. KEK rotation should re-wrap DEKs, not re-encrypt terabytes of data — a distinction that turns rotation from a migration project into a cheap routine — and DEK caching trades KMS cost against a wider memory-exposure window, which the prompt forces the model to state with a short TTL and memory-only storage. These are the levers that determine whether the scheme is both affordable and defensible.
Most importantly, the prompt refuses to let the model invent crypto. It pins the design to a vetted AEAD with correct nonce and associated-data handling, defines fail-closed behavior and decrypt-volume auditing, and ends by recommending a qualified cryptographer review the final scheme before it guards real data. That keeps the AI in the role of drafting a reviewable architecture for a human to verify — the only acceptable posture when the output is the thing standing between an attacker and your data at rest.