#3430 PR open: LUKS2: try to handle multiple key slots

Labels: enhancement

rmetrich opened issue at 2025-03-17 12:54:

Pull Request Details:

  • Type: Bug Fix + Enhancement

  • Impact: Normal

  • Reference to related issue (URL):

Related to PR 2504 - Add initial LUKS2 support

  • How was this pull request tested?

On RHEL9 UEFI system + TPM2 with LUKS encrypted root partition on LVM:

# lsblk
NAME                                          MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
sr0                                            11:0    1 1024M  0 rom   
vda                                           252:0    0   20G  0 disk  
├─vda1                                        252:1    0  600M  0 part  /boot/efi
├─vda2                                        252:2    0    1G  0 part  /boot
└─vda3                                        252:3    0 18.4G  0 part  
  └─luks-157c516f-a8a8-48f2-9b79-082ea905d73b 253:0    0 18.4G  0 crypt 
    ├─rhel-root                               253:1    0   10G  0 lvm   /
    ├─rhel-swap                               253:2    0    2G  0 lvm   [SWAP]

The /dev/vda3 partition is also bound to the TPM2 (which leads to having a 2nd key slot):

# cryptsetup luksDump /dev/vda3
[...]
Keyslots:
  0: luks2
    Key:        512 bits
    Priority:   normal
    Cipher:     aes-xts-plain64
    Cipher key: 512 bits
    PBKDF:      argon2id
    Time cost:  6
    Memory:     1048576
    Threads:    2
    Salt:       a0 fc ce ea 62 42 05 58 d6 ba 42 d4 43 7d 08 a6 
                b4 9c ce 09 48 2a ed 7d fb 8a e0 b5 3d d6 84 52 
    AF stripes: 4000
    AF hash:    sha256
    Area offset:32768 [bytes]
    Area length:258048 [bytes]
    Digest ID:  0
  1: luks2
    Key:        512 bits
    Priority:   normal
    Cipher:     aes-xts-plain64
    Cipher key: 512 bits
    PBKDF:      pbkdf2
    Hash:       sha256
    Iterations: 1000
    Salt:       f7 60 c4 d8 cd cb 9b dc b9 6c e6 ec 94 c9 0c 97 
                41 ef 9b 84 e8 6a 54 86 60 ca f8 71 37 dc 16 64 
    AF stripes: 4000
    AF hash:    sha256
    Area offset:290816 [bytes]
    Area length:258048 [bytes]
    Digest ID:  0
Tokens:
  0: clevis
    Keyslot:    1
Digests:
  0: pbkdf2
    Hash:       sha256
        [...]
  • Description of the changes in this pull request:

The current code doesn't deal properly with multiple key slots nor extracts the Hash that was used at LUKS creation properly. With current code, when multiple key slots are found or PBKDF algorithm is "pbkdf2" (instead of default "argon2id"), the disk layout file contains 2 lines for crypt parameters, causing havoc during recovery because of having new UUIDs being generated due to malformed 2nd line, e.g.:

crypt /dev/mapper/luks-157c516f-a8a8-48f2-9b79-082ea905d73b /dev/vda3 type=luks2 cipher=aes-xts-plain64 key_size=512 hash=sha256
sha256 uuid=157c516f-a8a8-48f2-9b79-082ea905d73b

This new code tries to do better:

  • it searches for the Hash in Keyslots section only (and falls back to Digests section if not found)

  • it warns the admin if multiple keyslots are in use (e.g. because of multiple passphrases or Clevis binding)

  • it handles the PBKDF algorithm

  • it makes sure that the crypt parameters are always on one line, e.g.

    crypt /dev/mapper/luks-157c516f-a8a8-48f2-9b79-082ea905d73b /dev/vda3 type=luks2 cipher=aes-xts-plain64 key_size=512 hash=sha256 uuid=157c516f-a8a8-48f2-9b79-082ea905d73b

jsmeix commented at 2025-03-17 14:24:

@rmetrich
thank you for your continuous improvements for ReaR,
in particular your improvements for special cases
could make bigger differences for business users
who often use ReaR in special environments.

jsmeix commented at 2025-03-17 14:27:

@rmetrich
could you have a look at my remaining point
https://github.com/rear/rear/pull/3430#discussion_r1998775809
as time permits - perhaps it is already sufficiently fail-safe
and I am just overcautious by only looking at the code
(I did not test anything here).

[Export of Github issue for rear/rear.]