Bug 2080516

There (In reply to James Ralston from comment #0)
> Description of problem:
> 
> I installed a RHEL9 beta system by booting the installer USB flash drive,
> augmenting the kernel command line in GRUB with fips=1, continuing the boot,
> and selecting encryption in the anaconda storage menu.
> 
> The resulting system showed that the LUKS filesystem was initialized with
> the argon2id PBKDF for the LUKS keyslot:
> 
> $ cryptsetup luksDump /dev/nvme0n1p3
> …
> Keyslots:
>   0: luks2
>         Key:        512 bits
>         Priority:   normal
>         Cipher:     aes-xts-plain64
>         Cipher key: 512 bits
>         PBKDF:      argon2id
>         Time cost:  12
>         Memory:     1048576
>         Threads:    4

It seems the installation environment was not properly configured for fips. Libcryptsetup requires these files to exist
with the later containing '1' value to properly report fips
compliant pbkdf default parameters: '/etc/system-fips' and '/proc/sys/crypto/fips_enabled'.

I can confirm that creating an empty /etc/system-fips file in the installation environment results in PBKDF:pbkdf2 being used for the encrypted device created in FIPS mode. Tested on RHEL-9.0 GA

At the same time, https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/9.0_release_notes/deprecated_functionality#deprecated-functionality_security says

  /etc/system-fips is now deprecated

  Support for indicating FIPS mode through the /etc/system-fips file has been removed, and the file will not be included in future versions of RHEL. To install RHEL in FIPS mode, add the fips=1 parameter to the kernel command line during the system installation. You can check whether RHEL operates in FIPS mode by using the fips-mode-setup --check command.

Fixed upstream in https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/365

Hi


Looks the bug just reproduce in anaconda environment. 

[anaconda root@storageqe-69 ~]# sysctl crypto.fips_enabled 
crypto.fips_enabled = 1
[anaconda root@storageqe-69 ~]# 
[anaconda root@storageqe-69 ~]# 
[anaconda root@storageqe-69 ~]# dd if=/dev/zero of=test.tar bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0.0537773 s, 1.9 GB/s
[anaconda root@storageqe-69 ~]# cryptsetup luksFormat --pbkdf argon2id  test.tar -q 
Enter passphrase for test.tar: 
[anaconda root@storageqe-69 ~]# cryptsetup luksDump  test.tar | grep PBKDF
        PBKDF:      argon2id


check the --help output, the default luks2 PBKDF is argon2id
...
Default compiled-in key and passphrase parameters:
        Maximum keyfile size: 8192kB, Maximum interactive passphrase length 512 (characters)
Default PBKDF for LUKS1: pbkdf2, iteration time: 2000 (ms)
Default PBKDF for LUKS2: argon2id
...

[anaconda root@storageqe-69 ~]# cryptsetup -V
cryptsetup 2.4.3



but how to test cryptsetup-2.4.3-5.el9 in anaconda ?

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (cryptsetup bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:8399

After the installation it can be fixed by running following command:

cryptsetup luksConvertKey /dev/nvmeXnYpZ

The command above will change pbkdf parameters to appropriate default values (pbkdf2 function, targeting 2 seconds unlock time if system runs in FIPS mode) for keyslot unlocked by user provided passphrase. New keyslot binary area is written with data containing same volume key but it will be protected by new KEK derived from passphrase using pbkdf2 function.

It can be applied to specific keyslot by adding -S<keyslot_id> parameter to the command above.