High-Performance Application-Level Encryption: Sub-Millisecond Access Control
Build ultra-fast encrypted systems that keep data secure from DB admins while delivering sub-millisecond performance through intelligent caching and role-based access control.
Application-Level Encryption
Zero-Trust Security + Sub-Millisecond Performance
The Challenge: Security vs Performance
The Traditional Dilemma
Most encryption solutions force you to choose: either accept database administrators can read your sensitive data, or sacrifice performance with round-trips to key management services on every database read.
In today's zero-trust security landscape, application-level encryption has become essential. Your database administrators, cloud providers, and even your own infrastructure team shouldn't have access to sensitive plaintext data. But traditional approaches often introduce significant latency penalties.
What We'll Build
- • App-level encryption - DB admins can't read plaintext
- • Role-based access - Decryption gated by caller's token/policy
- • Sub-millisecond hot-path - No KMS round-trips after first access
- • Enterprise-ready - Key rotation, audit trails, multi-tenancy
High-Level Architecture
Our solution uses a five-component architecture that implements envelope encryption with policy-based access control, intelligent caching, and zero-plaintext storage.
Components
1. Identity (Auth0/IdP)
Issues JWT with roles/claims for authentication and authorization.
2. PDP (Policy Decision Point)
OPA/Cedar checks JWT claims against "who may use which keys for which purpose".
3. Crypto Service
Internal microservice using Vault/KMS as KEK authority. Implements envelope encryption + data-key cache with AEAD primitives.
4. Data Service(s)
Business read/write APIs. Never touch raw keys; only call Crypto Service.
5. Database
Stores ciphertext + metadata (no plaintext).
Zero-Trust Encryption Pipeline
End-to-end security with sub-millisecond performance
Identity Layer (Auth0/IdP)
JWT Token with Claims
Policy Decision Point (OPA/Cedar)
Policy Evaluation Engine
Crypto Service (High-Performance Core)
AEAD Primitives + Intelligent Caching
- • LRU + TTL
- • Sub-ms lookup
- • Bounded size
- • AES-GCM
- • ChaCha20
- • Poly1305
- • Vault
- • Azure KV
- • AWS KMS
Data Services (Business Logic)
Never touch raw keys
Encrypted Database (Zero Plaintext)
Envelope Encryption Record Structure
Envelope Encryption Layout (per record)
Each encrypted record contains these fields for complete envelope encryption with searchability and key rotation support.
Unique record identifier
uuid-4567-89ab-cdefMulti-tenant isolation
org_12345AES-GCM (or ChaCha20-Poly1305)
[Encrypted payload bytes]Additional authenticated data (not secret)
tenant_id|record_id|purposeDEK wrapped with tenant/purpose KEK
[KEK-wrapped data encryption key]Which KEK wrapped the DEK (for rotation)
vault://payment-keys/v2Crypto params versioning
crypto_v1.2For search: HMAC/FPF/Deterministic tags
[Searchable encryption indexes]Core Flows
1) Write/Update (Encrypt)
Authentication & Authorization
Data Service authenticates caller (JWT) → sends JWT + purpose/tenant to PDP for policy check.
Policy Decision
PDP returns "allowed" → Data Service calls Crypto Service: encrypt(payload, context)
Crypto Service Processing
- • Fetch DEK for (tenant, purpose) from in-memory cache
- • On cache miss: Generate fresh DEK, wrap with KEK in Vault/KMS
- • Cache plaintext DEK with short TTL (5-15 minutes) and LRU eviction
- • AEAD encrypt with AES-GCM, using context as AAD (binds to tenant/id)
Database Storage
Store complete envelope encryption record:
2) Read (Decrypt)
Authentication & Policy Check
Data Service authenticates caller (JWT) → PDP checks role/policy for decrypt on (tenant, purpose).
Authorized Decryption Request
If allowed, Data Service calls Crypto Service with:
Crypto Service Processing
- • Cache lookup: DEK via cache key = hash(dek_encrypted)
- • On cache miss: Unwrap with KMS/Vault (one network call)
- • Cache DEK with TTL for future requests
- • AEAD decrypt and return plaintext to Data Service
Latency Characteristics
After TTL expiry, pays 1 KMS/Key Vault call (typical cloud latency)
AEAD in memory only, zero remote calls - sub-millisecond performance
Cache hit ratio of 95%+ means most operations run at memory speed with zero external dependencies.
Policies & Key Management Strategy
Policies & Key Scoping
KEK names and aliases reflect authorization scope, enabling fine-grained access control across tenants and data purposes.
KEK Naming Convention
PDP Rule Example
"Role PAYMENTS_READER can use decrypt with kek/tenantA/payments for purpose=payments.read."The Crypto Service enforces PDP decision before any unwrap/decrypt call; Vault/KMS also enforces at the API level via caller/service principal IAM.
Search & Querying Options
Strategic approaches for enabling search on encrypted data while maintaining security.
Non-Sensitive Columns
Don't encrypt columns you must filter/sort on. Keep timestamps, status fields, and public IDs in plaintext.
Equality Search
Prefix/Range Search
Requires specialized constructs (FPF/OPRF or external searchable index). Only implement if truly needed; document leakage trade-offs carefully.
Key Rotation & Re-wrapping
KEK Rotation (Fast)
Re-wrap stored dek_encrypted from kek_v1 → kek_v2 without touching ciphertext.
DEK Rotation (Heavier)
Re-encrypt payload with new DEK. Only for strict compliance regimes or annual policy.
Multi-tenant Strategy
Isolation Strategy
Keep blast radius small and policies straightforward
Maximum isolation; cache keeps it fast
HKDF-derived for chatty workloads; short TTL
Performance Tactics (What Actually Keeps It Fast)
Performance Characteristics
Data-Key Cache in Crypto Service
Cache Configuration
Performance Optimizations
AEAD Implementation
Auditing & Observability
Audit Logging
Log every unwrap/decrypt attempt with comprehensive context (no secrets logged).
Metrics & Monitoring
Comprehensive performance and health metrics for operational visibility.
Failure Modes & Fallbacks
Vault/KMS Unavailable
Operations continue as long as DEKs are in cache. Existing encrypted data remains accessible.
New/missed keys return 503 with retriable error code. System degrades gracefully.
Policy Decision Point Unavailable
Fail secure by default. All policy decisions return DENY when PDP is unreachable.
For SLO requirements: use last-known decision with very short TTL. Document risk carefully.
Key Cache Poison Protection
Protect against cache poisoning attacks through cryptographic binding and integrity verification.
Performance Targets
Implementation Sketch (Spring Boot)
Crypto Service Module
Service Ports
EncryptPort
encrypt(byte[] payload, Context ctx) -> CipherRecordDecryptPort
decrypt(CipherRecord rec, Context ctx) -> byte[]Technology Stack
Cryptography
Google Tink (AEAD/DeterministicAead)
Key Management
Azure Key Vault / AWS KMS / Vault Transit
Policy Engine
OPA sidecar or embedded Cedar
Decryption Flow Implementation
// Retrieve encrypted record from database
CipherRecord rec = repository.find(id);
// Policy check - throws exception if not allowed
policy.check(jwt, "decrypt", rec.kekId, rec.purpose);
// Get AEAD instance from cache (with automatic unwrap on miss)
Aead aead = dekCache.get(rec.dekEncrypted, rec.kekId, () -> {
byte[] dek = kms.unwrap(rec.dekEncrypted, rec.kekId); // one remote call on miss
return AeadFactory.fromRawKey(dek); // build AEAD (keep in cache)
});
// Decrypt and return plaintext
byte[] plaintext = aead.decrypt(rec.ciphertext, rec.aadContext);- • Cache-first approach: DEK lookup from in-memory cache
- • Lazy KMS calls: Only unwrap on cache miss
- • Policy enforcement: Every decrypt operation is authorized
- • AAD binding: Ciphertext cryptographically bound to context
When to Consider Alternatives
DB Transparent Encryption (TDE / Column Encryption)
Good For
- • Disk theft protection
- • Basic compliance requirements
- • Infrastructure-level encryption
Not Sufficient For
- • App-layer access control
- • DBA threat protection
- • Fine-grained policies
Tokenization / Vault Detokenization
Great for: PAN/SSN fields with strict compliance & format needs. Usually complements, not replaces, envelope encryption.
Proxy Re-Encryption (PRE)
Powerful for: Cross-org sharing without re-encrypting, but heavier ops/crypto. Use only if you truly need third-party re-sharing workflows.
Confidential Computing (TEE/Nitro/SGX)
Raises bar on: In-memory key exposure protection. Consider for high-sensitivity tiers requiring hardware-level security.
Ship-it Checklist
Define purposes and kek_id taxonomy
Establish clear naming conventions for KEKs and data purposes
Author PDP policies; add unit tests for allow/deny
Implement comprehensive policy rules with test coverage
Stand up Crypto Service with AEAD + DEK cache and Vault/KMS integration
Deploy core encryption service with caching and key management
Add blind indexes only where needed; document leakage
Implement searchable encryption with clear security trade-offs
Wire audit logs + metrics; SLOs and alerts for KMS latency, cache hit-rate
Comprehensive observability and performance monitoring
Build KEK re-wrap and DEK rotate jobs
Automated key rotation and lifecycle management
Pen-test: nonce reuse guards, AAD binding, key-material zeroization
Security validation and cryptographic implementation testing
Bottom Line
Use envelope encryption with a short-lived data-key cache behind a policy-enforcing Crypto Service. It keeps your hot-path fast, binds decryption to roles/policies, and gives you clean rotation and auditing.
For Equality Search
Add blind indexes with documented trade-offs
For Stricter Isolation
Layer tokenization where appropriate
For Cross-Org Sharing
Consider PRE for re-sharing workflows