↓ Skip to main content
Le Site de François
  1. Index/

LUKS (Linux Unified Key Setup)

Security Encryption Storage Linux Boot

LUKS (Linux Unified Key Setup) is the standard specification for block device encryption on Linux, created by Clemens Fruhwirth in 2004. It sits above the kernel’s dm-crypt subsystem — which performs the actual AES sector-by-sector encryption via the device mapper — and adds a structured, on-disk header that decouples key management from the encryption itself. Any block device can be a LUKS container: a partition, a logical volume, a loop device; anything that sits beneath it (filesystem, swap, LVM) is encrypted transparently, with no changes required to the software using it. The managed cryptsetup tool and the libcryptsetup library provide userspace access to LUKS volumes, and are the canonical interface for all operations on them.

The architectural centrepiece of LUKS is its volume key (also called the master key): a randomly generated key that directly encrypts the block device data and never changes for the lifetime of the volume. What LUKS stores in its header are not the volume key itself but the volume key encrypted by each active unlock credential, one per keyslot. LUKS1 supports 8 keyslots; LUKS2 (the current format, required by most modern tooling) supports 32. This design means multiple independent passphrases or tokens can unlock the same volume, and revoking one — by wiping its keyslot — does not require re-encrypting the device. Losing the header, however, makes the volume permanently unrecoverable, since no other path to the volume key exists.

LUKS2 introduced a token mechanism that embeds metadata in the header to describe how a keyslot can be unlocked by means other than a passphrase. systemd-cryptenroll uses this to enroll TPM2 chips, FIDO2 hardware tokens, and recovery keys as first-class unlock methods alongside or instead of passphrases. TPM2 enrollment seals the volume key against a set of PCR values — by default PCR 7 (Secure Boot state) — so the disk unlocks automatically at boot only if the system’s measured boot state matches what was present at enrollment time; any change to the firmware, bootloader, or Secure Boot configuration breaks the seal and falls back to requiring a passphrase. This is the mechanism that ties LUKS disk encryption into the broader measured boot stack: TPM PCR binding, UKI-based boot, and Secure Boot enforcement together form a chain in which LUKS-encrypted root filesystems unlock automatically on a verified boot and require manual intervention on anything else. The alternative network-based approach — Clevis with a Tang server — releases the unlock key from a remote server only when the client can prove it is on a trusted network, providing a complementary model without requiring a local TPM.

Related

NBDE / Clevis / Tang (Network-Bound Disk Encryption)

Security Encryption Storage Linux Luks Boot Rhel
NBDE (Network-Bound Disk Encryption) is an approach to automatic LUKS disk unlocking that binds the volume key not to hardware state (a TPM PCR measurement) but to network presence: a LUKS-encrypted volume unlocks automatically at boot if and only if the machine can reach a designated Tang server on a trusted network. Remove the machine from that network — because it was stolen, because a data centre drive was pulled, because someone exfiltrated the hardware — and the volume key becomes unrecoverable without a fallback passphrase. The threat model is therefore complementary to TPM-based unlocking: TPM sealing asks “is this the right software stack?” and locks the key to a specific platform measurement; NBDE asks “is this machine on the trusted network?” and locks the key to network presence. Neither addresses both threat classes alone, which is why the two are routinely combined — and why RHEL formalises NBDE as a subcategory of the broader Policy-Based Decryption (PBD) framework that the Clevis pin system implements.

Measured Boot

Security Boot Tpm Attestation Linux Firmware Uefi
Measured Boot is a boot process architecture in which each component in the boot chain — firmware, bootloader, kernel, initrd, kernel command line — is cryptographically hashed and that hash is recorded into a TPM Platform Configuration Register (PCR) before the component executes. The critical distinction from Secure Boot is in what each mechanism provides: Secure Boot is an enforcement mechanism that prevents unauthorised components from running at all; Measured Boot is a recording mechanism that creates a tamper-evident log of exactly what did run, without necessarily preventing anything. The two are complementary and typically deployed together — Secure Boot enforces a policy at boot time, Measured Boot produces the evidence that the policy was enforced as claimed. A system can have Measured Boot without Secure Boot (it records everything that ran, even unsigned components), but Secure Boot without Measured Boot provides enforcement with no attestable evidence of what was enforced.

RHCOS (Red Hat Enterprise Linux CoreOS)

Linux Security Openshift Immutable Selinux Luks Tpm Boot
RHCOS (Red Hat Enterprise Linux CoreOS) is the operating system that runs on every OpenShift control plane and worker node. It is not a general-purpose Linux distribution — it is a purpose-built, immutable, container-optimised OS designed to run exclusively as a managed node in an OpenShift cluster. Its security posture is architecturally different from a hardened RHEL installation: rather than hardening a mutable system through configuration management, RHCOS makes the OS layer structurally resistant to modification by design. The root filesystem’s /usr tree is read-only (enforced at mount time by rpm-ostree and, in recent versions, by composefs over the OSTree object store), /etc and /var are writable but managed exclusively by the Machine Config Operator (MCO), and no package manager is available at runtime for ad-hoc software installation. An operator who wants to change any node-level configuration — kernel arguments, sysctl settings, systemd units, certificates, kubelet configuration — creates a MachineConfig object in the OpenShift API; the MCO renders it into an Ignition config, applies it to the target MachineConfigPool (master, worker, or custom), and drains and reboots the affected nodes in a rolling fashion. Direct SSH access to nodes for configuration changes is explicitly unsupported and actively discouraged — oc debug node/<name> is the supported emergency access path, dropping into a privileged container on the node’s host namespaces under audit.