DEK-KEK the industry standard to protect highly sensitive data (Part 1)

(Part 1 - Foundational concepts)

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:

• Microsoft Azure – Encryption at Rest
• Google Cloud KMS – Envelope Encryption
• Wikipedia – Hybrid Cryptosystem (Envelope Encryption)
• ZeroToHero – Understanding DEK and KEK in Encryption

Let's get started by some foundational concepts, industry standards for data protection and how Fystack made technical decisions and applied them to secure our MPC wallet infrastructure 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.

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).

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.

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).

2. Asymmetric Encryption

Uses a pair of keys:

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

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.

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.

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.

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:

1. 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).
2. 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.
3. 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!