Linux Unified Key Setup

Last updated

The Linux Unified Key Setup (LUKS) is a disk encryption specification created by Clemens Fruhwirth in 2004 and originally intended for Linux.

Contents

LUKS implements a platform-independent standard on-disk format for use in various tools. This facilitates compatibility and interoperability among different programs and operating systems, and assures that they all implement password management in a secure and documented manner. [1]

Description

LUKS is used to encrypt a block device. The contents of the encrypted device are arbitrary, and therefore any filesystem can be encrypted, including swap partitions. [2] There is an unencrypted header at the beginning of an encrypted volume, which allows up to 8 (LUKS1) or 32 (LUKS2) encryption keys to be stored along with encryption parameters such as cipher type and key size. [3] [4]

The presence of this header is a major difference between LUKS and dm-crypt, since the header allows multiple different passphrases to be used, with the ability to change and remove them. If the header is lost or corrupted, the device will no longer be decryptable. [5]

Encryption is done with a multi-layer approach. First, the block device is encrypted using a master key. This master key is encrypted with each active user key. [6] User keys are derived from passphrases, FIDO2 security keys, TPMs or smart cards. [7] [8] The multi-layer approach allows users to change their passphrase without re-encrypting the whole block device. Key slots can contain information to verify user passphrases or other types of keys.

There are two versions of LUKS, with LUKS2 featuring resilience to header corruption, and using the Argon2 key derivation function by default, whereas LUKS1 uses PBKDF2. [9] Conversion between both versions of LUKS is possible in certain situations, but some features may not be available with LUKS1 such as Argon2. [3] LUKS2 uses JSON as a metadata format. [3] [10]

Available cryptographic algorithms depend on individual kernel support of the host. Libgcrypt can be used as a backend for hashing, which supports all of its algorithms. [11] It is up to the operating system vendor to choose the default algorithm. [12] LUKS1 makes use of an anti-forensics technique called AFsplitter, allowing for secure data erasure and protection. [13]

LUKS with LVM

Logical Volume Management can be used alongside LUKS. [14]

LVM on LUKS
When LVM is used on an unlocked LUKS container, all underlying partitions (which are LVM logical volumes) can be encrypted with a single key. This is akin to splitting a LUKS container into multiple partitions. The LVM structure is not visible until the disk is decrypted. [15]
LUKS on LVM
When LUKS is used to encrypt LVM logical volumes, an encrypted volume can span multiple devices. The underlying LVM volume group is visible without decrypting the encrypted volumes. [16]

Full disk encryption

Debian-Installer showing an option for automated partitioning with LVM on LUKS Debian Graphical Installer Partman-auto init automatically partition 1.png
Debian-Installer showing an option for automated partitioning with LVM on LUKS

A common usage of LUKS is to provide full disk encryption, which involves encrypting the root partition of an operating system installation, which protects the operating system files from being tampered with or read by unauthorized parties. [14]

On a Linux system, the boot partition (/boot) may be encrypted if the bootloader itself supports LUKS (e.g. GRUB). This is undertaken to prevent tampering with the Linux kernel. However, the first stage bootloader or an EFI system partition cannot be encrypted (see Full disk encryption#The boot key problem). [14]

On mobile Linux systems, postmarketOS has developed osk-sdl to allow a full disk encrypted system to be unlocked using a touch screen.

For systems running systemd, the systemd-homed component can be used to encrypt individual home directories. [17]

Operating system support

The reference implementation for LUKS operates on Linux and is based on an enhanced version of cryptsetup, using dm-crypt as the disk encryption backend. Under Microsoft Windows, LUKS-encrypted disks can be used via the Windows Subsystem for Linux. [18] (Formerly, this was possible with LibreCrypt, [19] which currently has fundamental security holes, [20] [21] and which succeeded FreeOTFE, formerly DoxBox.)

DragonFly BSD supports LUKS. [22]

Installer support

Several Linux distributions allow the root device to be encrypted upon OS installation. These installers include Calamares, [23] Ubiquity, [24] Debian-Installer, [25] and more.

On-disk format

LUKS headers are backward compatible; newer versions of LUKS are able to read headers of previous versions. [26]

LUKS1

LUKS1 Header [26]
OffsetData typeDescription
00hexchar[6] Magic number {'L', 'U', 'K', 'S', 0xBA, 0xBE }
66hexuint16_tLUKS Version (0x0001 for LUKS1)
88hexchar[32]Cipher Algorithm (e.g. "twofish", "aes")
4028hexchar[32]Cipher mode (e.g. "cbc-essiv:sha256")
7248hexchar[32] Cryptographic hash function (e.g. "sha1", "ripemd160")
10468hexuint32_tPayload offset (position of encrypted data) in 512 byte offsets
1086Chexuint32_tNumber of key bytes
11270hexchar[20] PBKDF2 master key checksum
13284hexchar[32]PBKDF2 master key salt parameter
164A4hexuint32_tPBKDF2 master key iterations (Default: 10)
168A8hexchar[40] UUID of the partition (e.g. "504c9fa7-d080-4acf-a829-73227b48fb89")
208D0hex(48 Bytes)Keyslot 1
544220hex(48 Bytes)Keyslot 8
592 Bytes total
Format of each keyslot
OffsetData typeDescription
0uint32_tState of keyslot: Active=0x00AC71F3; Disabled=0x0000DEAD
4uint32_tPBKDF2 iteration parameter
8char[32]PBKDF2 salt parameter
40uint32_tStart sector of key
44uint32_tNumber of anti-forensic stripes (Default: 4000)
48 Bytes total

LUKS2

The LUKS2 header has a binary area and a JSON area, a second binary and JSON area, and a keyslots area. The binary and JSON areas are repeated two times with minor variations. [10]

Binary area

The size of the binary areas is always 4kiB. The size of binary plus JSON area can be a power-of-two number of bytes between 16 kiB and 4 MiB, making the size of the JSON areas between 12 kiB and 4092 kiB each.

LUKS2 binary and JSON header area (16 kiB each) [10]
OffsetData typeDescription
1st Binary area
00hexchar[6] Magic number {'L', 'U', 'K', 'S', 0xBA, 0xBE }, allows fast detection by blkid
66hexuint16_tLUKS Version (0x0002 for LUKS2)
88hexuint64_tSize of binary and json area (commonly 16 kiB, 4000hex)
1610hexuint64_tEpoch, incremented when the header is modified
2418hexchar[48]ASCII Partition Label, null terminated
7248hexchar[32]String determining the checksum algorithm (commonly "sha256"), null terminated
10468hexuint8_t[64]Salt , unique for every binary area
168A8hexchar[40] UUID of the device, null terminated (e.g. "02f47c64-7e74-4711-8bd4-a37613d1ecd3")
208D0hexchar[48]Secondary "subsystem" label, null terminated
256100hexuint64_toffset of this LUKS area on the device (typically 0)
264108hex_char[184]Padding, must be zeroed
4481C0hexuint8_t[64]Checksum of 1st binary area calculated with the checksum algorithm, zero-padded if shorter
512200hex_char[3584]Padding, must be zeroed
1st JSON area
40961000hexchar[12288]LUKS JSON object, null terminated
2nd Binary area
163844000hexchar[6] Second Magic number {'S', 'K', 'U', 'L', 0xBA, 0xBE }
Identical to 1st binary area
164884068hexuint8_t[64]Salt, unique for every binary area
Identical to 1st binary area
166404100hexuint64_toffset of this LUKS area on the device (typically 4000hex, 16384dec)
166484108hex_char[184]Padding, must be zeroed
1683241C0hexuint8_t[64]Checksum of 2nd binary area calculated with the checksum algorithm, zero-padded if shorter
168964200hex_char[3584]Padding, must be zeroed
2nd JSON area
Identical to 1st JSON area
32 kiB total

JSON area

The base LUKS2 JSON metadata object has 5 keys: config, keyslots, digests, segments, and tokens. [10]

Config contains general settings and information of the LUKS header, and persistent mount options.

Segments describe areas on the disk than contain data and can be decrypted. They also describe the algorithm with which a segment is encrypted.

Digests describe what keyslots contain encrypted keys able to decrypt which segments. They contain a hash of the decrypted key of the keyslot that functions as a checksum and to verify correctness of the password.

Keyslots contain encrypted keys. The method of encryption varies, a combination of passwords, keyfiles, hardware keys, and other methods can be uses to decrypt the contained master-keys.

The tokens object can hold additional for external systems integrating with LUKS.

Userdata, segments, are encrypted with a large master-key and an efficient encryption algorithm. The master key can then be encrypted with a more expensive algorithm and potentially weaker user-provided keys, these encrypted master-keys are then stored in Keyslots. This slows brute-force attempts at guessing the password, and also allows changing decryption methods and passwords without having to reencrypt the entire data section, by only needing to rewrite the same master-key encrypted differently into the keyslots. [10]

A typical LUKS2 JSON area, with added indentation and line-breaks:

{"keyslots":{"0":{"type":"luks2","key_size":64,"af":{"type":"luks1","stripes":4000,"hash":"sha256"},"area":{"type":"raw","offset":"32768","size":"258048","encryption":"aes-xts-plain64","key_size":64},"kdf":{"type":"argon2id","time":4,"memory":1048576,"cpus":4,"salt":"YOvmrBmgFT7Ehm7ANZrn0quep1fUFisNCv4e+X8+CLk="}}},"tokens":{},"segments":{"0":{"type":"crypt","offset":"16777216","size":"dynamic","iv_tweak":"0","encryption":"aes-xts-plain64","sector_size":512}},"digests":{"0":{"type":"pbkdf2","keyslots":["0"],"segments":["0"],"hash":"sha256","iterations":105703,"salt":"hrSZ0Sh6t3EVAyeH7XLSH1dEQrRmJwimbjHx85PLS/k=","digest":"tXiDNw8fanGe8QcXewvtzF3AOTOqaIXBmhAGa8Kb42w="}},"config":{"json_size":"12288","keyslots_size":"16744448","flags":["allow-discards"]}}

Keyslots area

Keyslots take up the device region after the two binary and JSON areas. In the typical case shown above this starts at 32 kiB, and runs up to 4 MiB or 16 MiB. Here we will use 16MiB as an example.

Usually a device is spanned by a single segment, with the offset set to 16MiB and the size to dynamic. During reencryption or in unusual configuration there might be multiple segments that in total should span the device without gaps or overlap.

The segment(s) should each have a single associated digest, that each have one or more associated keyslots. Keyslots may also be unassociated with any digest and used for other purposes.

Keyslots themselves are mapped into the keyslots area, in the example above to a single 252kiB area starting right after the header at 32 kiB. This area is obfuscated with anti-forensic stripes in the same manner as in LUKS1.

The default algorithm for digests, pbkdf2, as well as the anti-forensic stripes type "luks1", are identical to LUKS1. The key derivation defaults to stronger algorithms unsupported by LUKS1, but can be set to the supported pbkdf2. [10]

Examples

Cryptsetup is the reference implementation of the LUKS frontend.

To encrypt a device with the path /dev/sda1:

# cryptsetupluksFormat/dev/sda1 

To unlock an encrypted device, where name is the mapped device name:

# cryptsetupopen/dev/sda1name 

Re-encrypting

Re-encrypting a LUKS container can be done either with the cryptsetup tool itself, or with a legacy tool called cryptsetup-reencrypt. These tools can also be used to add encryption to an existing unencrypted filesystem, or remove encryption from a block device. [11] [27]

Both methods have similar syntax:

# cryptsetupreencrypt/dev/sda1 
# cryptsetup-reencrypt/dev/sda1 

See also

References

  1. Fruhwirth, Clemens (2018-01-20). "LUKS On-Disk Format Specification Version 1.2.3" (PDF). Retrieved 2021-09-23.
  2. "Encrypting drives using LUKS". Fedora Docs. Retrieved 6 May 2022.
  3. 1 2 3 "Chapter 12. Encrypting block devices using LUKS". Red Hat Customer Portal.
  4. "How to Encrypt Hard Disk (partition) using LUKS in Linux". 27 February 2019.
  5. "How to Encrypt Your Data with dm-crypt". Linode. 22 November 2022.
  6. Bossi, Simone; Visconti, Andrea (2015). "What Users Should Know About Full Disk Encryption Based on LUKS" (PDF).{{cite journal}}: Cite journal requires |journal= (help)
  7. "systemd-cryptenroll - ArchWiki". wiki.archlinux.org. Retrieved 2023-11-22.
  8. "How to encrypt a LUKS container using a smart card or token". 20 April 2014.
  9. "How LUKS works with Full Disk Encryption in Linux". 25 September 2021.
  10. 1 2 3 4 5 6 "on-disk-format-luks2.pdf" (PDF). 7 March 2024.
  11. 1 2 cryptsetup(8)    Linux Administration and Privileged Commands Manual
  12. "Breaking LUKS Encryption". eForensics. 21 August 2020.
  13. "AFsplitter".
  14. 1 2 3 "dm-crypt/Encrypting an entire system" . Retrieved 6 May 2022.
  15. "Arch with LVM on LUKS".
  16. "LUKS on LVM: encrypted logical volumes and secure backups". 12 September 2014.
  17. "Home Directories". systemd.
  18. "Servicing the Windows Subsystem for Linux (WSL) 2 Linux Kernel". Microsoft Developer Blogs. 16 April 2021.
  19. "LibreCrypt". GitHub. 27 July 2022.
  20. "Flaw in driver allows privilege escalation. Feedback wanted · Issue #38 · t-d-k/LibreCrypt". GitHub. 30 September 2015.
  21. "Driver allows writing to arbitrary devices · Issue #39 · t-d-k/LibreCrypt". GitHub . 7 October 2015.
  22. "DragonFly's Major Features List" . Retrieved 6 May 2022.
  23. Michael Larabel (8 May 2016). "Calamares Installer Adds LUKS Encryption Support". Phoronix.
  24. "How to Encrypt Your Hard Disk in Ubuntu". Make Tech Easier. 13 January 2017.
  25. "PartmanCrypto". Debian Wiki. Retrieved 6 May 2022.
  26. 1 2 "LUKS On-Disk Format Specification" (PDF).
  27. "CRYPTSETUP-REENCRYPT(8) Man page". man7.org.