Hello Mauricio, I have updated the Test plan to include another section that will help confirm that clevis will still be able to decrypt argon2id devices.
Thank you for your feedback! ** Description changed: Thank you @kylerhornor for the original bug report [impact] current version of clevis on jammy uses argon2id instead of pbkdf2 for the encryption algorithm which is not approved by the NIST. An upstream commit (https://github.com/latchset/clevis/commit/71596307516ce2367e6303bd7f7ae7b180b29a35) did make clevis use pbkdf2 instead of argon2id to avoid OOM scenarios on systems with constrained memory. So this fix also resolves this issue on jammy. Noble currently has that fix. - Although argon2id is considered more secure, the maintainer has confirmed that currently the entropy used by clevis is high enough to the point where pbkdf2 is considered secure enough to replace argon2id. Please refer to comment #5 on this links for the maintainers' response: + Although argon2id is considered more secure, the maintainer has confirmed that currently the entropy used by clevis is high enough to the point where pbkdf2 is considered secure enough to replace argon2id. Please refer to comment #5 on this links for the maintainers' response: https://bugzilla.redhat.com/show_bug.cgi?id=1979256 Also the bugzilla thread above is a good read for anyone interested in knowing more about why this change was made. [Test Plan] + * Test plan to verify that the new encryption algorithm pbkdf2 is being applied + This test plan was done on a libvirt/kvm virtual machine. 1. setup a jammy VM. Attach to it a tpm2 module (software or pass- through) and an extra drive. 2. install clevis, clevis-tpm2 and clevis-luks: $ sudo apt install clevis clevis-tpm2 clevis-luks 3. using lsblk note the name of the extra drive that was attached to the VM. In this case vdb will be used as an example 4. run the following commands to setup partitions on the drive: $ sudo parted /dev/vdb -- mklabel gpt $ sudo parted /dev/vdb -- mkpart primary 0% 100% 5. setup luks and open the drive: $ sudo cryptsetup luksFormat /dev/vdb1 $ sudo cryptsetup luksOpen /dev/vdb1 <name> replace <name> with a name of your choosing also note how vdb1 is used in this step instead of vdb since we are formatting the partition created in step 4. Verify these values on your system before running the commands. 6. finally bind the drive with clevis using tpm2: $ sudo clevis luks bind -d /dev/vdb1 tpm2 '{"hash":"sha256","key":"rsa","pcr_bank":"sha256","pcr_ids":"6"}' 7. Verify the encryption algorithm being used: sudo cryptsetup luksDump /dev/vdb1 | grep PBKDF: Currently this will show as argon2id but after applying the patch I backported from upstream and repeating step 6 it should show pbkdf2 in the new keyslot + * Test plan to verify that the new version does no break current disk + encryption that was done with argon2id. + + 1. On the non patched version of clevis, run all the steps in the first + part of the test plan, and make sure that output of the final step shows + argon2id. + + 2. create an ext4 partition on the luks drive: + + $ mkfs.ext4 /dev/mapper/<name> + Where <name> is the same value used in step 5 of the first section of the test plan. + + 3. Mount the drive: + $ mount -t ext4 /dev/mapper/<name> /mount/point/of/your/choice + + 4. Access the drive via the mount point and write data to it (as an + example create a file and write any data inside it) + + 5. Unmount and close the luks drive: + $ umount /mount/point/of/your/choice + $ sudo cryptsetup luksClose tpm_Drive + + 5. Upgrade clevis to the new version that uses pbkdf2. + + 6. Open the luks drive: + $ sudo cryptsetup luksOpen /dev/vdb1 <name> + + 7. Mount the drive: + $ mount -t ext4 /dev/mapper/<name> /mount/point/of/your/choice + + 8. And finally verify that you are able to see and access the data you + had previously written. + + [where problems could occur] * The machine could fail to create the new keyslot - * Although the maintainer says that the entropy is high enough for pbkdf2 to be secure it might not be as secure still as argon2id even tho it is NIST compliant. - + * Although the maintainer says that the entropy is high enough for pbkdf2 to be secure it might not be as secure still as argon2id even tho it is NIST compliant. [Original Description] Hello, clevis released with version 18 on jammy (22.04). For reasons that are a bit beyond me, the cryptsetup call inside of clevis creates keyslots using argon2id as the pbkdf. While most folks would say this is preferable, NIST still has not approved it and it is thus incompatible with fips 140-3 at this time. Oddly enough, there was an upstream commit that was implemented to help with an OOM condition that accidentally forced pbkdf2 rather than argon2id. Commit found here: https://github.com/latchset/clevis/commit/71596307516ce2367e6303bd7f7ae7b180b29a35 Ideally, we need to either just bring that commit back to the jammy version, or get to the root cause of why cryptsetup in that exact scenario prefers argon2id. ** Description changed: Thank you @kylerhornor for the original bug report [impact] current version of clevis on jammy uses argon2id instead of pbkdf2 for the encryption algorithm which is not approved by the NIST. An upstream commit (https://github.com/latchset/clevis/commit/71596307516ce2367e6303bd7f7ae7b180b29a35) did make clevis use pbkdf2 instead of argon2id to avoid OOM scenarios on systems with constrained memory. So this fix also resolves this issue on jammy. Noble currently has that fix. Although argon2id is considered more secure, the maintainer has confirmed that currently the entropy used by clevis is high enough to the point where pbkdf2 is considered secure enough to replace argon2id. Please refer to comment #5 on this links for the maintainers' response: https://bugzilla.redhat.com/show_bug.cgi?id=1979256 Also the bugzilla thread above is a good read for anyone interested in knowing more about why this change was made. [Test Plan] * Test plan to verify that the new encryption algorithm pbkdf2 is being applied This test plan was done on a libvirt/kvm virtual machine. 1. setup a jammy VM. Attach to it a tpm2 module (software or pass- through) and an extra drive. 2. install clevis, clevis-tpm2 and clevis-luks: $ sudo apt install clevis clevis-tpm2 clevis-luks 3. using lsblk note the name of the extra drive that was attached to the VM. In this case vdb will be used as an example 4. run the following commands to setup partitions on the drive: $ sudo parted /dev/vdb -- mklabel gpt $ sudo parted /dev/vdb -- mkpart primary 0% 100% 5. setup luks and open the drive: $ sudo cryptsetup luksFormat /dev/vdb1 $ sudo cryptsetup luksOpen /dev/vdb1 <name> replace <name> with a name of your choosing also note how vdb1 is used in this step instead of vdb since we are formatting the partition created in step 4. Verify these values on your system before running the commands. 6. finally bind the drive with clevis using tpm2: $ sudo clevis luks bind -d /dev/vdb1 tpm2 '{"hash":"sha256","key":"rsa","pcr_bank":"sha256","pcr_ids":"6"}' 7. Verify the encryption algorithm being used: sudo cryptsetup luksDump /dev/vdb1 | grep PBKDF: Currently this will show as argon2id but after applying the patch I backported from upstream and repeating step 6 it should show pbkdf2 in the new keyslot * Test plan to verify that the new version does no break current disk encryption that was done with argon2id. 1. On the non patched version of clevis, run all the steps in the first - part of the test plan, and make sure that output of the final step shows - argon2id. + part of the test plan, and make sure that the output of the final step + shows argon2id. 2. create an ext4 partition on the luks drive: - $ mkfs.ext4 /dev/mapper/<name> + $ sudo mkfs.ext4 /dev/mapper/<name> Where <name> is the same value used in step 5 of the first section of the test plan. 3. Mount the drive: - $ mount -t ext4 /dev/mapper/<name> /mount/point/of/your/choice + $ sudo mount -t ext4 /dev/mapper/<name> /mount/point/of/your/choice 4. Access the drive via the mount point and write data to it (as an example create a file and write any data inside it) - 5. Unmount and close the luks drive: - $ umount /mount/point/of/your/choice + 5. Unmount and close the luks drive: + + $ sudo umount /mount/point/of/your/choice $ sudo cryptsetup luksClose tpm_Drive 5. Upgrade clevis to the new version that uses pbkdf2. 6. Open the luks drive: + $ sudo cryptsetup luksOpen /dev/vdb1 <name> 7. Mount the drive: - $ mount -t ext4 /dev/mapper/<name> /mount/point/of/your/choice + + $ sudo mount -t ext4 /dev/mapper/<name> /mount/point/of/your/choice 8. And finally verify that you are able to see and access the data you had previously written. - [where problems could occur] * The machine could fail to create the new keyslot * Although the maintainer says that the entropy is high enough for pbkdf2 to be secure it might not be as secure still as argon2id even tho it is NIST compliant. [Original Description] Hello, clevis released with version 18 on jammy (22.04). For reasons that are a bit beyond me, the cryptsetup call inside of clevis creates keyslots using argon2id as the pbkdf. While most folks would say this is preferable, NIST still has not approved it and it is thus incompatible with fips 140-3 at this time. Oddly enough, there was an upstream commit that was implemented to help with an OOM condition that accidentally forced pbkdf2 rather than argon2id. Commit found here: https://github.com/latchset/clevis/commit/71596307516ce2367e6303bd7f7ae7b180b29a35 Ideally, we need to either just bring that commit back to the jammy version, or get to the root cause of why cryptsetup in that exact scenario prefers argon2id. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2073429 Title: Jammy clevis forces argon2id for keyslots To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/clevis/+bug/2073429/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
