DEK-KEK the industry standard to protect highly sensitive data (Part 1) – ██FR█████ █INTELL███████████

This content originally appeared on DEV Community and was authored by Anh Phan

(Part 1 – Foundational concepts)
Read the original post over here Fystack Blog

DEK-KEK is a hybrid encryption approach designed to balance security, performance, and operational simplicity. It’s widely adopted by institutional enterprises, think banks, insurance companies, and crypto exchanges where centralized servers must store extremely sensitive data such as PII (Personally Identifiable Information), crypto private keys, or MPC keyshares.

References and industry examples:

Let’s get started by some foundational concepts, industry standards for data protection and how Fystack makes technical decisions and apply them on Part 2 (coming soon)

Encryption Models in Play

1. Symmetric Encryption

A single private key is used for both encryption and decryption.

Pros:

Simple and fast.
Low computational cost.
Standardized algorithms (e.g., AES).

Cons:

Key sharing is risky.
Key compromise breaks security.
No non-repudiation.

Use Cases:

Data-at-rest encryption (e.g., database fields, file storage, backups).
Data-in-transit encryption when combined with key exchange protocols (e.g., TLS session keys).
Disk encryption (BitLocker, LUKS) or cloud storage encryption (AWS S3 SSE).
Bulk data transfer, due to its speed and efficiency.

Figure 1.1 – Symmetric encryption/decryption model

AES-GCM-256 is chosen as the core algorithm for symmetric encryption/decryption. It ensures both confidentiality (data is unreadable without the key) and integrity (detects any tampering with the ciphertext).

Why AES-GCM-256?

AES (Advanced Encryption Standard) is a proven symmetric encryption algorithm trusted worldwide. The GCM (Galois/Counter Mode) variant adds authenticated encryption, meaning it not only encrypts data but also verifies its integrity. AES-GCM-256 is favored because it is:

– Fast and hardware-accelerated on most modern CPUs.

– Widely audited and trusted, meeting banking and government security standards.

– Resistant to common cryptographic attacks, making it the default choice for enterprise-grade encryption.

AES-GCM-256 Encryption Process

Input:

Plaintext ([]byte) – Raw data to be encrypted (e.g., JSON, string, binary).
DEK ([]byte) – 32-byte Data Encryption Key used by AES-256-GCM.

Output:

Nonce (string) – Base64-encoded 12-byte random nonce required for decryption.
Ciphertext (string) – Base64-encoded encrypted data, which includes the GCM authentication tag.

Figure 1.2 – AES-GCM-256 encryption architectural diagram

AES-GCM-256 Decryption Process

Input:

Ciphertext (string) – Base64-encoded ciphertext as stored in the database.
Nonce (string) – Base64-encoded nonce generated during encryption.
DEK ([]byte) – 32-byte Data Encryption Key used for decryption.

Output:

Plaintext ([]byte) – The original decrypted raw data (convert to string with string(plaintext) if needed).

Figure 1.3 – AES-GCM-256 decryption architectural diagram

2. Asymmetric Encryption

Uses a pair of keys:

A public key for encryption (or signature verification).
A private key for decryption (or signing).

Figure 1.4 Asymmetric encryption/decryption model

Pros:

No shared private keys.
Supports digital signatures.
Good for secure key exchange.

Cons:

Slower and resource-heavy.
Larger key sizes.
Complex key management.

Use cases:

Key exchange protocols (e.g., TLS handshake to establish symmetric session keys).
Digital signatures and certificate-based authentication (e.g., SSL certificates, JWT signing).
Cryptocurrency wallets (e.g., signing transactions with private keys).

Intuitive approach

Let’s start from the most common table in every system User, the primary key is user_id and a sensitive otp_secret, others are omitted for the sake of simplicity.

Figure 1.5 – Intuitive approach to protect data at-rest

Imagine a disaster strikes when no engineers are around — say, during the holidays. The database gets compromised, and the attacker gains access to all users’ OTP secrets in plaintext, effectively bypassing 2FA protection to launch further attacks.

A robust protection mechanism for data at rest is essential. Even in the worst-case scenario, the attacker should only see encrypted data, rendering it useless for further exploitation. To achieve this, an encryption key is introduced as the core defense.

Figure 1.6 – enhanced approach to protect data at-rest

The encryption key can be either a symmetric or asymmetric key and is often managed by cloud provider serverless services (AWS KMS, GCP KMS, Azure Key Vault). When a user query is made, the backend service will load encrypted fields from database, call to Key Management Service (KMS) to decrypt it then return result to client. However this approach still comes with some disadvantages:

The encryption key becomes the single point of compromise.
Huge operational efforts on rotating encryption key (including re-encrypt every row in database).

That is where DEK-KEK model was born and becomes the industry standard.

What are DEK and KEK?

DEK (Data Encryption Key): A symmetric key used directly to encrypt and decrypt data.
KEK (Key Encryption Key): A key (often asymmetric) used to encrypt DEKs, protecting them from being compromised while at rest.

By layering encryption like this, KEKs safeguard DEKs, while DEKs efficiently handle the encryption of large volumes of data.

*DEK vs. KEK Lifecycle

DEK: stored at-rest with encryption, loaded into memory (plaintext) when the backend service boots up and is securely wiped from memory when the server shuts down.
KEK: managed by cloud providers, with backend access restricted by Role-Based Access Control (RBAC)*

Figure 1.7 – DEK-KEK practical implementation

The diagram illustrates how the DEK-KEK encryption model works in a real-world system. At the top of the hierarchy is the Key Encryption Key (KEK), usually stored and managed by a secure service such as AWS KMS, Azure Key Vault, or GCP Cloud KMS. The KEK never encrypts user data directly. Instead, it’s responsible for protecting another key — the Data Encryption Key (DEK) — which is used for actual data encryption and decryption.

The process works as follows:

A DEK (symmetric key) is generated and then immediately encrypted with the KEK. The encrypted version of the DEK is stored in the database, represented by the encrypted_dek column (base64-encoded).
When the application needs to perform encryption or decryption, it retrieves the encrypted DEK, has it decrypted by the KEK, and loads the plain DEK into memory.
The DEK, which is much faster for bulk operations, handles the encryption and decryption of sensitive data such as the otp_secret field.

This model provides a strong balance between security and performance:

The KEK remains protected in a hardened key management service or hardware security module. It follows the strict principle that the key’s plaintext version never leaves the service, ensuring that no user, system or process can directly access or view it.
The DEK, while briefly present in memory, is never stored in plaintext at rest. The memory can be further protected at both the software and hardware layers, for example, using AWS Nitro Enclaves as the Trusted Execution Environment (TEE).
Symmetric encryption ensures fast operations without frequent, costly calls to KMS.

Moreover, this model significantly reduces operational effort required when it is time to rotate the KEK. The entire database remains unchanged. The DEK is re-encrypted in memory by the new KEK then stored back to the database. Simple, secure and efficient!

– To be continued –

In Part 2, we’ll share how Fystack adopted this model to strengthen our MPC wallet infrastructure, the challenges we faced, and the key technical decisions behind it. Stay tuned!

At Fystack, we provide self-hosted MPC wallet infrastructure designed for teams that value security, control, and flexibility.

Contact us at *fystack.io* for self-hosted MPC wallet infrastructure or try Fystack for free now!

This content originally appeared on DEV Community and was authored by Anh Phan