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

Component	Responsibility
client	Authenticated Client
tls-endpoint	TLS 1.3 Endpoint
application	Authorized Application
kms	Key Management Service
hsm	Protected Key Boundary
key-metadata	Key Version and Nonce Metadata
database	Encrypted Data Store
backup	Encrypted Backup and Retention
e2ee-peer	End-to-End Peer
audit-log	Key and Decrypt Audit
attacker	Network, Storage, or Endpoint Attacker

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.

▶Walkthrough: tls-in-transit (not found)

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.

▶Walkthrough: envelope-encryption (not found)

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.

▶Walkthrough: aead-nonce-and-aad (not found)

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.

▶Walkthrough: key-rotation (not found)

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.

▶Walkthrough: backup-encryption (not found)

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.

▶Walkthrough: end-to-end-encryption (not found)

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.

▶Walkthrough: authorized-endpoint-compromise (not found)

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.

▶Walkthrough: kms-outage (not found)

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.

▶Walkthrough: cryptographic-erasure (not found)

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

[CONCEPT]secrets-management [CONCEPT]mtls [CONCEPT]zero-trust [CONCEPT]threat-modeling-stride

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