LUKS Disk Encryption Guide: cryptsetup, TPM2 Unlock and Network-Bound Disk Encryption

Encrypting a Linux server's disks is easy; making them unlock unattended at boot without leaving the key next to the data is the hard part. A laptop user can type a passphrase, but a rack of servers, a fleet of edge devices or a cloud VM cannot, so teams either skip encryption or store a key file on an unencrypted partition, which defeats it. LUKS, the Linux Unified Key Setup format managed with cryptsetup, supports several ways to solve this: TPM2 binding with systemd-cryptenroll, network-bound disk encryption with Clevis and Tang, and hardware tokens. This guide explains how LUKS keyslots and tokens work, how to choose and configure an unattended unlock method, how to manage recovery keys and headers, and what to monitor. It is for Linux platform and infrastructure security engineers. Laptop encryption with BitLocker and FileVault is covered in the Disk Encryption Guide: BitLocker and FileVault.

Key takeaways

• LUKS protects data at rest, not a running server: once a volume is unlocked, root and anything running as root can read it, so encryption complements but never replaces host hardening.
• Every keyslot is a way in: a passphrase, recovery key, TPM2 binding, Tang binding or FIDO2 token each wraps the same volume key, so inventory and prune slots like any other credential.
• TPM2 binding ties unlock to the machine and its boot state; bind to Secure Boot policy (PCR 7) or signed policies rather than raw firmware measurements, and add a PIN where a stolen server must stay locked.
• Network-bound disk encryption (Clevis and Tang) unlocks only when the server can reach a Tang server on the trusted network, which suits data centres where theft means leaving the building.
• Back up the header and the recovery key: cryptsetup warns that a damaged LUKS header means all data is permanently lost without a header backup.

How identity and access work in LUKS

LUKS stores a header at the start of the device (or in a detached header file). The data is encrypted with a single random volume key (also called the master key). The volume key is never stored in clear: each keyslot holds a copy of it encrypted with a key derived from one unlocking secret. Unlocking means proving possession of any one secret that opens any one keyslot.

The upstream build default cipher is aes-xts-plain64 with a 256-bit key; distributions can change compile-time defaults, so check luksDump output rather than assuming. Running luksFormat on an existing container generates a new volume key, which makes all old data unrecoverable unless the old header is backed up.

Unattended unlock methods

Configuring TPM2 unlock with systemd-cryptenroll

systemd-cryptenroll enrols TPM2, FIDO2, PKCS#11, recovery keys and passphrases into LUKS2 tokens and keyslots. To unlock with an enrolled TPM2, the volume's /etc/crypttab line uses tpm2-device=auto.

• PCR binding is opt-in: --tpm2-pcrs= selects the Platform Configuration Registers the key is sealed against. If the option is not used, the enrolment binds to no PCRs at all, which means any boot of that machine (including one from a tampered boot loader) can unlock it.
• Choose PCRs for stability and meaning: PCR 7 (secure-boot-policy) changes when Secure Boot is turned on or off or firmware certificate databases change. systemd's documentation notes that validating through certificates in PCR 7 is usually preferable to direct measurements, which change on every firmware or OS update. PCRs 0 to 5 cover firmware code and configuration and boot loader, and break on routine updates.
• Signed policies and pcrlock: --tpm2-public-key= binds to a key that signs acceptable PCR policies, so a vendor-signed kernel and initrd unlock without re-enrolment. --tpm2-pcrlock= binds to a policy generated by systemd-pcrlock, which predicts PCR values across updates.
• Add a PIN for high-risk locations: --tpm2-with-pin=yes requires a PIN in addition to PCR policy; systemd hardens the PIN with Argon2id so a compromised TPM alone does not reveal the key.
• Enrol a recovery key: --recovery-key generates a high-entropy, easy-to-type key. Store it in your secrets manager or escrow before relying on TPM2 unlock.
• Remove the bootstrap passphrase deliberately: --wipe-slot= removes old slots (for example an installation passphrase) once TPM2 and recovery key enrolment are tested.
• Detect unexpected volumes: crypttab's tpm2-measure-pcr=yes measures the volume key, name and UUID of the unlocked root volume into PCR 15, so later secrets can be bound to "this specific root volume was unlocked".

Secure Boot underpins PCR 7 binding; see the Linux Secure Boot and Shim Guide.

Network-Bound Disk Encryption with Clevis and Tang

Clevis is a pluggable framework for automated decryption; its tang pin works with Tang, a small server that provides key binding without escrow. During binding, Clevis fetches the Tang server's signed advertisement of public keys, asks you to trust it (much like an SSH host key), and derives a key from it. At boot, Clevis performs an exchange with the Tang server to recover the key. The Tang server never sees or stores client keys, and it is stateless.

• Bind a volume: clevis luks bind -d /dev/sda1 tang '{"url": "http://tang.example"}'. For the root volume, the initramfs must bring up networking: Clevis documents adding rd.neednet=1 to the kernel command line or using dracut's --hostonly-cmdline.
• Pin the advertisement: supplying the advertisement out of band with the adv parameter avoids trust-on-first-use; Clevis treats a manually supplied advertisement as trusted, so get it from the Tang server directly.
• High availability with SSS: the sss pin splits the key using Shamir Secret Sharing. A threshold of 1 across two Tang servers means either can unlock; a threshold of 2 across Tang and TPM2 requires both the network and the original hardware.
• Rotate Tang keys: Tang's documentation stresses periodic rotation of all key types. Generate new keys with jose jwk gen in /var/db/tang, rename old keys to hidden files so they are no longer advertised but still answer existing clients, then rebind clients (unbind the old binding and bind again) and finally delete the old keys.
• TLS is optional by design: Tang's protocol does not require TLS because the exchange does not reveal the key to an observer. Protect Tang servers by placing them only on the networks where unlock should be possible, and by protecting their private keys like any other key material.

Admin roles and privileged access

• Root on an unlocked host sees everything: while a volume is open, its data is readable by root, and root can extract the volume key (for example with cryptsetup luksDump --dump-volume-key or from the device-mapper table). Treat root access as access to the data. See the Unix and Linux Privileged Access Guide.
• Keyslot changes are privileged changes: adding a keyslot (luksAddKey, systemd-cryptenroll, clevis luks bind) creates a new permanent way in. Restrict who can run them and log their use.
• Recovery key custody: store recovery keys in a vault with access logging and dual control for retrieval, not in a spreadsheet or the host's own configuration repository.
• Tang server administrators: anyone controlling a Tang server's keys and network position can help unlock servers that reach it. Keep Tang administration separate from general server administration.

Integrations, API tokens and service accounts

Unattended unlock turns disk encryption into a machine identity problem: the server proves who it is (TPM), where it is (Tang reachability) or what it holds (key file or token) before it gets its key.

• TPM as machine identity: a TPM-sealed key is only as trustworthy as the boot state it is bound to. Pair TPM2 binding with Secure Boot and measured boot, and re-enrol after motherboard replacement.
• Key files: where a key file is unavoidable (for example a data volume unlocked after root is unlocked), keep it on the encrypted root volume or under /etc/cryptsetup-keys.d/ with mode 0400 root, never on /boot or an unencrypted partition.
• Cloud and virtual machines: a virtual TPM is controlled by the hypervisor or cloud provider, so vTPM binding protects against copied disk images but not against the platform operator. Platform-managed encryption with customer-managed keys may be simpler for cloud volumes; see the BYOK, HYOK and External Key Management Guide.
• Automation: provisioning pipelines that run luksFormat and enrolment often handle the initial passphrase and recovery key. Generate them in the pipeline, write them straight to the secrets manager, and never log them. See the Cryptographic Key Management Guide.
• Golden images: never encrypt a template image with a shared volume key and clone it, because every clone would share the key. Encrypt at first boot or re-encrypt (cryptsetup reencrypt) per host. See the Server Build and Golden Image Hardening Guide.

Logging and detection

Metrics: percentage of servers with all data volumes encrypted; percentage of encrypted servers with a recovery key in escrow and tested in the last year; percentage of TPM2 enrolments bound to at least PCR 7 or a signed policy; number of volumes with a key file on unencrypted storage (target zero); number of keyslots per volume above the approved set; and age of Tang server keys against the rotation policy.

Hardening baseline

1. Decide the threat: disk disposal and RMA only (TPM2 without PCRs may do), stolen disks (TPM2), stolen servers (TPM2 with PIN, or NBDE), or tampered boot (PCR 7 or signed policies).
2. Format with LUKS2: default cipher and Argon2id, unique volume key per host; for existing unencrypted servers use cryptsetup reencrypt with a tested backup.
3. Enrol recovery first: generate a recovery key, store it in the vault, and back up the header with luksHeaderBackup to protected storage.
4. Enrol the unattended method: TPM2 with chosen PCRs, Clevis and Tang, or an SSS combination. Pilot on a small ring including firmware and kernel updates to confirm unlocks survive them.
5. Remove bootstrap secrets: wipe the installation passphrase slot once the new method and recovery key are proven.
6. Consider discard: crypttab's discard option improves SSD performance but has security implications (it can reveal which blocks are in use); decide per data classification.
7. Swap and temporary space: encrypt swap (or use a random key per boot) so memory contents do not land on disk in clear.
8. Decommission properly: before disposal, destroy all keyslots (cryptsetup erase) so the remaining ciphertext is unreadable, and record it in the asset register. Rollback for a failed enrolment is the recovery key.

Small estates can start with TPM2 bound to PCR 7 plus an escrowed recovery key. Large data centre estates usually prefer NBDE with at least two Tang servers per site, often combined with TPM2 through SSS, because it handles hardware replacement without per-host re-enrolment of PCR policies.

Common misconfigurations

• Key file next to the data: a crypttab key file on an unencrypted /boot partition means anyone with the disk has the key.
• TPM2 bound to no PCRs: enrolment without --tpm2-pcrs unlocks for any boot of that machine, including one with a modified initramfs.
• PCRs that break every month: binding to firmware code PCRs leads to failed boots after each update, and teams respond by removing PCR binding entirely.
• No recovery key or header backup: a motherboard swap or header corruption turns a hardware fault into permanent data loss.
• Single Tang server: one Tang outage stops every server in the site from booting.
• Cloned encrypted images: all hosts built from one image share a volume key, so one leaked key opens every disk.

Framework mapping

Practitioner checklist

• Encrypt every server data volume with LUKS2 using a unique volume key per host.
• Generate a recovery key for every volume, store it in the vault and test retrieval.
• Back up each LUKS header to protected storage after any keyslot change.
• Bind TPM2 enrolments to PCR 7, a signed policy or a pcrlock policy, never to no PCRs.
• Run at least two Tang servers per site for NBDE, and rotate Tang keys on a schedule.
• Remove installation passphrases and unused keyslots once unattended unlock is proven.
• Keep key files only on already-encrypted storage with root-only permissions.
• Alert on recovery-key unlocks, new keyslots and volume key dumps.
• Erase keyslots with cryptsetup erase before disk disposal or RMA.

Standards and references

• cryptsetup: cryptsetup(8) manual
• systemd: systemd-cryptenroll(1)
• systemd: crypttab(5)
• Clevis project: Clevis automated decryption framework
• Tang project: Tang binding server
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Disk Encryption Guide: BitLocker and FileVault · Linux Secure Boot and Shim Guide · Cryptographic Key Management Guide · Linux Server Hardening Guide