Data encryption: AEAD, key hierarchy, transport, storage, and E2EE

Encryption protects confidentiality only within a stated threat boundary. Authenticated encryption, unique nonces, key purpose and hierarchy, transport identity, backup policy, and endpoint trust are required; encryption does not replace authorization or input safety.

Security invariants

• ENC-C1: TLS protects data between authenticated channel endpoints; termination defines where plaintext becomes available and does not replace application authorization.
• ENC-C2: Envelope encryption uses data-encryption keys for content and versioned key-encryption keys protected by a key-management boundary.
• ENC-C3: Authenticated encryption protects confidentiality and integrity, and AES-GCM requires nonce uniqueness for each key while associated data binds context.
• ENC-C4: Backups, snapshots, exports, caches, and logs have explicit encryption, integrity, retention, restore, and key-dependency policy.
• ENC-C5: End-to-end encryption excludes intermediaries from content plaintext but does not hide all metadata or protect a compromised endpoint.
• ENC-C6: Encryption at rest does not prevent an authorized application compromise, and required KMS failure does not permit plaintext fallback.

Trust-boundary map

Topology edges represent authenticated or otherwise explicit communication paths. Responses reuse those physical paths in reverse; no response-only or bypass edges are added.

Executable scenarios

tls-in-transit — TLS protects data in transit between authenticated endpoints

TLS 1.3 authenticates the server and protects records; client authentication or application credentials are added when the server must authenticate the caller.

envelope-encryption — Envelope encryption separates data and key-encryption keys

A fresh data-encryption key encrypts the object with AEAD; KMS wraps the DEK under a versioned KEK that remains inside its protected boundary.

aead-nonce-and-aad — AEAD nonce uniqueness and associated data

For a given key, AES-GCM IV reuse can destroy security. Associated data binds immutable context such as tenant, object id, schema, and key version.

key-rotation — Rotate KEKs without rewriting plaintext

New writes use the active key version; wrapped DEKs can be rewrapped under a new KEK, while data re-encryption is a separate explicit migration when required.

backup-encryption — Backups have independent encryption and restore policy

Encrypted primary storage does not automatically protect exports, snapshots, logs, or backups; restore must prove key access and integrity.

end-to-end-encryption — End-to-end encryption excludes the intermediary from plaintext

Endpoints establish content keys so the service transports ciphertext; metadata and compromised endpoints remain outside the confidentiality guarantee.

authorized-endpoint-compromise — Encryption does not stop an authorized application compromise

An application permitted to decrypt can expose plaintext after compromise; least privilege, isolation, audit, and data minimization bound this threat.

kms-outage — KMS outage fails closed at the decrypt boundary

Required key service unavailability does not trigger plaintext fallback or use of an unbounded local master-key cache.

cryptographic-erasure — Cryptographic erasure depends on key reachability

Destroying the only usable wrapping key can make ciphertext unrecoverable, but copies, escrow, replicas, caches, and backups must be included in the deletion proof.

Operational and failure rules

• Every rejection path fails closed at the component that owns the decision; infrastructure failure is never converted into authentication, authorization, or integrity success.
• Retries preserve stable transaction identity, replay detection, bounded freshness, and audit context. A retry does not erase a prior success or compromise signal.
• Concurrent validation branches are independent checks. Completion requires every mandatory branch, and no check substitutes for another.
• Logs contain decision metadata and stable identifiers, not credentials, bearer tokens, cryptographic keys, or sensitive payloads.

Related concepts

Authoritative sources

1. RFC 8446: The Transport Layer Security Protocol Version 1.3
2. NIST SP 800-38D: Galois Counter Mode and GMAC
3. NIST SP 800-57 Part 1 Revision 5: Recommendation for Key Management
4. FIPS 197: Advanced Encryption Standard
5. OWASP Cryptographic Storage Cheat Sheet
6. RFC 9420: The Messaging Layer Security Protocol