Securing Data at Rest: From LUKS to NBDE – A Modern Encryption Guide | HackerNoon

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

What are the different types of 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 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.

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

File system level encryption

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

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

In following sections, we will discuss Full Disk encryption with LUKS (Linux Unified Key Setup) and strengthen it using 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 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

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

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

Differences between LUKS and dm-crypt

Secure Key Files

1. TPM 2.0 (Trusted Platform Module) integration
2. Integrate with custom-built key storage
3. Different disks/Mounting points or the Main disk. And of course, this can’t be removed easily.
4. HSM (Hardware Security Module)
5. 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 it.

LUKS + NBDE offers more security with auto/easier way to manage disk encryption/decryption at boot at high level, NBDE has following concepts.

1. CLEVIS – Pluggable framework for automated decryption. in NBDE, Clevis provides automated unlocking of LUKS volumes
2. CLEVIS Pin – is a plug-in into Clevis framework. Implements interactions with TANG server
3. TANG – Stateless, secure network based data recovery service. TANG is not an escrow server, nothing saved on the server

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.

Automation: NBDE enables automated unlocking of encrypted volumes at boot, reducing manual intervention and improving security for data-at-rest in unattended server environments.

Modularity: Clevis is designed as a flexible framework, allowing other pins (not just Tang) for different unlocking scenarios or hardware integrations.

Statelessness: The Tang server does not retain any secrets or escrow keys, protecting against central server compromise.

Layered Workflow

1. The client (Clevis) initiates unlock during boot.
2. Clevis uses the Tang pin to communicate with the Tang server and perform a secure key exchange.
3. Cryptographic operations (JOSE) manage the secure ephemeral key material.
4. LUKSMeta stores the binding and unlock logic.
5. 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 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.