"What happens if your servers or laptops or disks are stolen? Can the data still be accessed? The answer is 'No' if you have full disk encryption set up right." "What happens if your servers or laptops or disks are stolen? Can the data still be accessed? The answer is 'No' if you have full disk encryption set up right." In today's threat landscape, encrypting data is not optional; rather, it's foundational. While different use cases and applications require various levels of encryption, disk-level encryption, also known as FDE - Full Disk Encryption, has become the de facto standard for securing data at rest. Suppose you run Linux systems or any big data workloads. In that case, you’ve probably heard of LUKS (Linux Unified Key Setup), dm-crypt (device mapper encryption), or even NBDE (Network Bound Disk Encryption). Let’s break down what these are, why they matter, and when you should use them. FDE - Full Disk Encryption, LUKS (Linux Unified Key Setup), dm-crypt (device mapper encryption), NBDE (Network Bound Disk Encryption) What are the different types of Encryption? Application-level data encryption Application-level data encryption It's the most preferred secured way to encrypt sensitive data using encryption keys before storing data on disk or databases. Encryption keys are securely managed in a separate system, such as a Key Management System (KMS), to isolate key storage from the encrypted data.This approach helps protect data even if an attacker gains access at the system, file system, or database administrator level, as the data remains encrypted without the keys.Extra logic at the application layer to handle encryption or decryption.Suitable to protect sensitive data to satisfy different industry compliance requirements.PII (Personal Identity Information) - First name, last name, addresses, phone numbers, email addresses, SSN, etc.PCI-DSS(Payment Card Industry - Data Security Standards) - Credit card numbers, CVV codes, expiration dates, etc.PHI (Protected Health Information)  - Medical records, diagnoses, treatment information, lab results, insurance details, and other patient health information covered under HIPAAOther sensitive or regulated data: Trade secrets, intellectual property, financial records, legal documents, or any data that, if exposed, could result in compliance violations or reputational harm. It's the most preferred secured way to encrypt sensitive data using encryption keys before storing data on disk or databases. Encryption keys are securely managed in a separate system, such as a Key Management System (KMS), to isolate key storage from the encrypted data. This approach helps protect data even if an attacker gains access at the system, file system, or database administrator level, as the data remains encrypted without the keys. Extra logic at the application layer to handle encryption or decryption. Suitable to protect sensitive data to satisfy different industry compliance requirements. PII (Personal Identity Information) - First name, last name, addresses, phone numbers, email addresses, SSN, etc. PII (Personal Identity Information) - PCI-DSS(Payment Card Industry - Data Security Standards) - Credit card numbers, CVV codes, expiration dates, etc. PCI-DSS(Payment Card Industry - Data Security Standards) - PHI (Protected Health Information)  - Medical records, diagnoses, treatment information, lab results, insurance details, and other patient health information covered under HIPAA PHI (Protected Health Information) HIPAA Other sensitive or regulated data: Trade secrets, intellectual property, financial records, legal documents, or any data that, if exposed, could result in compliance violations or reputational harm. Other sensitive or regulated data: Database Encryption Database Encryption Encrypts data at rest within the database system (e.g., Transparent Data Encryption (TDE))Usually encrypts the entire database file, table, column or tablespace automatically, without the application handling encryption directlyKeys are managed by the database engine or an integrated KMS.Protects against threats like stolen disks or unauthorized file access, but not against privileged users (e.g., DBAs) who can query decrypted data if they have access. Encrypts data at rest within the database system (e.g., Transparent Data Encryption (TDE)) at rest Transparent Data Encryption (TDE) Usually encrypts the entire database file, table, column or tablespace automatically, without the application handling encryption directly without the application handling encryption directly Keys are managed by the database engine or an integrated KMS. Protects against threats like stolen disks or unauthorized file access, but not against privileged users (e.g., DBAs) who can query decrypted data if they have access. Protects against threats like stolen disks or unauthorized file access File system level encryption Suitable for Files/Folders/volumes encryption.Key management could be done at OS level, TPM/HSM, KMSProtects against physical theft/lossBest for endpoint/storage device security Suitable for Files/Folders/volumes encryption. Key management could be done at OS level, TPM/HSM, KMS Protects against physical theft/loss Best for endpoint/storage device security Full Disk Encryption (FDE) Full Disk Encryption (FDE) Encrypts data at rest at the disk level or device mapper level and offersProtection against insider threats - If an attacker gains direct disk access, the data remains unreadable. There are many cases, including financial industries, that have been impacted by these kinds of actsEssential for big data systems - Store unstructured data and Clusters that cannot operate on encrypted payloads at the application layer still benefit from encryption at rest.Performance & cost efficiency - Often faster than complex, distributed application-level encryption in certain scenarios.FDE is not suitable or replace application-level encryption; rather, it complements or augments data-at-rest security posture. Encrypts data at rest at the disk level or device mapper level and offers Protection against insider threats - If an attacker gains direct disk access, the data remains unreadable. There are many cases, including financial industries, that have been impacted by these kinds of acts Protection against insider threats Essential for big data systems - Store unstructured data and Clusters that cannot operate on encrypted payloads at the application layer still benefit from encryption at rest. Essential for big data systems Performance & cost efficiency - Often faster than complex, distributed application-level encryption in certain scenarios. Performance & cost efficiency FDE is not suitable or replace application-level encryption; rather, it complements or augments data-at-rest security posture. not suitable or replace In following sections, we will discuss Full Disk encryption with LUKS (Linux Unified Key Setup) and strengthen it using NBDE (Network Based Disk Encryption). LUKS (Linux Unified Key Setup) NBDE (Network Based Disk Encryption). Linux Unified Key Setup (LUKS) De facto standard for Full Disk Encryption(FDE), which uses the existing device mapper kernel system (aka dm-crypt)Disk encryption key can be encrypted using a random text/library The key encryption material is in a file (aka keyFile) protected by OS level permissionsKeyFile will be maintained on a different disk from the LUKS-protected diskUp to 8 OS level accounts can be configured to access the same disk with 8 slots in LUKS. Whereas LUKS2 offers 32 slotsLUKS is often considered as standard full disk encryption as the chip makers are following AES-NI (AES-New Instructions) in native. So less impact on CPUDefault cipher is AES-CBC-ESSIV:SHA256 or AES-XTS-PLAIN64 depending upon OS installationThe default key size for LUKS is 256 bits and 512 bits with Anaconda Installer (XTS mode) De facto standard for Full Disk Encryption(FDE), which uses the existing device mapper kernel system (aka dm-crypt) Disk encryption key can be encrypted using a random text/library The key encryption material is in a file (aka keyFile) protected by OS level permissions KeyFile will be maintained on a different disk from the LUKS-protected disk Up to 8 OS level accounts can be configured to access the same disk with 8 slots in LUKS. Whereas LUKS2 offers 32 slots LUKS is often considered as standard full disk encryption as the chip makers are following AES-NI (AES-New Instructions) in native. So less impact on CPU Default cipher is AES-CBC-ESSIV:SHA256 or AES-XTS-PLAIN64 depending upon OS installation The default key size for LUKS is 256 bits and 512 bits with Anaconda Installer (XTS mode) Fig: LUKS - Full Disk Encryption Fig: LUKS - Full Disk Encryption LUKS Setup The following documentation shows step by step guidance to setup LUKS on Redhat Linux systems. https://www.redhat.com/en/blog/disk-encryption-luks https://www.redhat.com/en/blog/disk-encryption-luks What is LUKS not suitable for? Treat LUKS always as a complementary encryption mechanism at the disk level along with application-level encryption. But it's not a replacement for application-level/DataBase or File system-levelel encryption. LUKS is an additional convenience layer that stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use and cryptographic security. Plain dm-crypt mode, being the earlier kernel functionality, does not employ the convenience layer. it is more difficult to apply the same cryptographic strength with it. Lets look at the differences between LUKS and dm-crypt Treat LUKS always as a complementary encryption mechanism at the disk level along with application-level encryption. But it's not a replacement for application-level/DataBase or File system-levelel encryption. LUKS is an additional convenience layer that stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use and cryptographic security. Plain dm-crypt mode, being the earlier kernel functionality, does not employ the convenience layer. it is more difficult to apply the same cryptographic strength with it. Lets look at the differences between LUKS and dm-crypt Differences between LUKS and dm-crypt Add RowRemove RowAdd ColRemove ColAdd RowRemove RowAdd ColRemove ColAdd RowRemove RowAdd ColRemove ColLUKSdm-cryptLicense GPL
YesYesChange password without re-encrypting
YesNoDefense against low entropy passphrase (against dictionary attacks) Salting and Hashing
YesNoMultiple decryption keys for same encrypted data
YesNoKeys recovery mechanism
YesNoStore encryption settingsYesNoAdd RowRemove RowAdd ColRemove Col Add RowRemove RowAdd ColRemove Col Add Row Remove Row Add Col Remove Col Add RowRemove RowAdd ColRemove Col Add Row Remove Row Add Col Remove Col Add RowRemove RowAdd ColRemove Col Add Row Remove Row Add Col Remove Col LUKSdm-cryptLicense GPL
YesYesChange password without re-encrypting
YesNoDefense against low entropy passphrase (against dictionary attacks) Salting and Hashing
YesNoMultiple decryption keys for same encrypted data
YesNoKeys recovery mechanism
YesNoStore encryption settingsYesNo LUKSdm-cryptLicense GPL
YesYesChange password without re-encrypting
YesNoDefense against low entropy passphrase (against dictionary attacks) Salting and Hashing
YesNoMultiple decryption keys for same encrypted data
YesNoKeys recovery mechanism
YesNoStore encryption settingsYesNo LUKSdm-crypt LUKS dm-crypt License GPL
YesYes License GPL Yes Yes Change password without re-encrypting
YesNo Change password without re-encrypting Yes No Defense against low entropy passphrase (against dictionary attacks) Salting and Hashing
YesNo Defense against low entropy passphrase (against dictionary attacks) Salting and Hashing Yes No Multiple decryption keys for same encrypted data
YesNo Multiple decryption keys for same encrypted data Yes No Keys recovery mechanism
YesNo Keys recovery mechanism Yes No Store encryption settingsYesNo Store encryption settings Yes No Add RowRemove RowAdd ColRemove Col Add Row Remove Row Add Col Remove Col Secure Key Files TPM 2.0 (Trusted Platform Module) integrationIntegrate with custom-built key storageDifferent disks/Mounting points or the Main disk. And of course, this can't be removed easily.HSM (Hardware Security Module)NBDE (Network Bound Disk Encryption). Which is the preferred, secure, and automated way for production systems.  NBDE is available in RHEL 7.4 onwards. TPM 2.0 (Trusted Platform Module) integration Integrate with custom-built key storage Different disks/Mounting points or the Main disk. And of course, this can't be removed easily. HSM (Hardware Security Module) NBDE (Network Bound Disk Encryption). Which is the preferred, secure, and automated way for production systems.  NBDE is available in RHEL 7.4 onwards. Network Bound Disk Encryption (NBDE): NBDE offers asymmetric cryptography, it allows a machine with an encrypted disk to boot, without the disk's encryption, where the key has to be entered at boot time. But only when the machine is on the correct network, and without storing the encryption key in plain text, or storing it off the machine, or transmitting data across the network in such a way that a thief could make use of it. LUKS + NBDE offers more security with auto/easier way to manage disk encryption/decryption at boot at high level, NBDE has following concepts. LUKS + NBDE CLEVIS - Pluggable framework for automated decryption. in NBDE, Clevis provides automated unlocking of LUKS volumesCLEVIS Pin - is a plug-in into Clevis framework. Implements interactions with TANG serverTANG - Stateless, secure network based data recovery service. TANG is not an escrow server, nothing saved on the server CLEVIS - Pluggable framework for automated decryption. in NBDE, Clevis provides automated unlocking of LUKS volumes CLEVIS CLEVIS Pin - is a plug-in into Clevis framework. Implements interactions with TANG server CLEVIS Pin TANG - Stateless, secure network based data recovery service. TANG is not an escrow server, nothing saved on the server TANG Fig: Network Bound Disk Encryption (NBDE) Key Points Security Model: The system leverages asymmetric cryptography so that disk decryption is only possible when the machine is connected to the correct network (where the Tang server is accessible), without needing to store decryption keys locally or transmit them insecurely. Security Model: Automation: NBDE enables automated unlocking of encrypted volumes at boot, reducing manual intervention and improving security for data-at-rest in unattended server environments. Automation: Modularity: Clevis is designed as a flexible framework, allowing other pins (not just Tang) for different unlocking scenarios or hardware integrations. Modularity: Statelessness: The Tang server does not retain any secrets or escrow keys, protecting against central server compromise. Statelessness: Layered Workflow The client (Clevis) initiates unlock during boot.Clevis uses the Tang pin to communicate with the Tang server and perform a secure key exchange.Cryptographic operations (JOSE) manage the secure ephemeral key material.LUKSMeta stores the binding and unlock logic.Upon a successful exchange, Clevis decrypts the master key and unlocks the LUKS-encrypted volume. The client (Clevis) initiates unlock during boot. Clevis uses the Tang pin to communicate with the Tang server and perform a secure key exchange. Cryptographic operations (JOSE) manage the secure ephemeral key material. LUKSMeta stores the binding and unlock logic. Upon a successful exchange, Clevis decrypts the master key and unlocks the LUKS-encrypted volume. NBDE - Advantages No need to enter pass phrases on system boot/reboot manually(if root also encrypted)No need to keep pass phrases in KeyFilesNo sharing of public or private keys between TANG server and CLEVIS frameworkAutomated Remote calls to TANG server (acts as a decryption key server)Uses asymmetric keys (M-R Exchange Algorithm) Scalable option with growing server deployments. No need to enter pass phrases on system boot/reboot manually(if root also encrypted) No need to keep pass phrases in KeyFiles No sharing of public or private keys between TANG server and CLEVIS framework Automated Remote calls to TANG server (acts as a decryption key server) Uses asymmetric keys (M-R Exchange Algorithm) Scalable option with growing server deployments. Conclusion: If your organization handles sensitive data or operates in regulated industries, FDE with LUKS + NBDE offers a powerful, automated, and secure solution for data-at-rest protection. FDE with LUKS + NBDE

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Read My Stories

Too Long; Didn't Read

CTA: Download the FREE AI Productivity Shift report

Securing Data at Rest: From LUKS to NBDE - A Modern Encryption Guide

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

A Deep Dive Into AWS Key Management Service (KMS)

Beyond Deleted: Cradle's True 'Disappearing' Message Technology.

Fileless Malware: The Secret Weapon of Cybercriminals That Targets Your System’s Vulnerabilities

Identifying Effective Data Encryption Techniques for Healthcare Organizations

The True Cost of Ransomware Attacks in 2023

A Deep Dive Into AWS Key Management Service (KMS)

Beyond Deleted: Cradle's True 'Disappearing' Message Technology.

Fileless Malware: The Secret Weapon of Cybercriminals That Targets Your System’s Vulnerabilities

Identifying Effective Data Encryption Techniques for Healthcare Organizations

The True Cost of Ransomware Attacks in 2023

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps