Bug 1979256
| Summary: | clevis added LUKS2 keyslots does not have to use LUKS2 pbkdf defaults for new keyslots. | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Renaud Métrich <rmetrich> | ||||||||
| Component: | clevis | Assignee: | Sergio Correia <scorreia> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Martin Zelený <mzeleny> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | medium | ||||||||||
| Version: | 8.4 | CC: | agk, dapospis, guazhang, jbrassow, mzeleny, okozina, prajnoha, rsroka, scorreia | ||||||||
| Target Milestone: | rc | Keywords: | Triaged | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | clevis-15-6.el8 | Doc Type: | No Doc Update | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2022-05-10 13:52:43 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Renaud Métrich
2021-07-05 12:14:23 UTC
Created attachment 1798120 [details]
Grub config to install the VM
Created attachment 1798122 [details]
libvirt "default" network XML to be able to UEFI+HTTP boot
Cryptsetup simply can not change defaults here. The utility does not know the use case for the keyslot and it aims to achieve highest security possible for the user by default.
cryptsetup luksAddKey action aims to use half system memory with argon2 pbkdf (or 1GiB whatever hits first). But yes, if the system is under memory pressure it leads to oom. Please mind that memory cost is core feature of memory hard pbkdf function. It serves to protect LUKS2 passphrases against parallel attack performed on systems with high parallel core count but expensive memory (GPUs).
I see following posibilities:
a) you can lower memory cost of pbkdf by adding --pbkdf-memory limit in KiB
b) you can switch to back to pbkdf2 with --pbkdf pbkdf2
this needs to be verified by clevis/tang maintainer:
c) Maybe clevis can safely switch to minimal pbkdf values since I expect new passphrase provided by clevis during luksAddKey action is in fact cryptographicly strong key (key generated with high entropy).
Is that correct Sergio?
example for c) would look like this:
cryptsetup luksAddKey cryptsetup luksAddKey --pbkdf pbkdf2 --pbkdf-force-iterations 1000 --key-file <(echo -n "${existing_key}") "$DEV"
But please bear in mind that c) is safe only if the 'new_passphrase' is generated using approved random key generator. I don't know clevis/tang internals good enough to verify that.
Systemd does something very similar when it's aware new passphrase has key generated with high entropy (In reply to Ondrej Kozina from comment #3) [...] > > this needs to be verified by clevis/tang maintainer: > c) Maybe clevis can safely switch to minimal pbkdf values since I expect new > passphrase provided by clevis during luksAddKey action is in fact > cryptographicly strong key (key generated with high entropy). > > Is that correct Sergio? > Yes -- the key is currently generated with pwmake and 256 bits of entropy. > example for c) would look like this: > > cryptsetup luksAddKey cryptsetup luksAddKey --pbkdf pbkdf2 > --pbkdf-force-iterations 1000 --key-file <(echo -n "${existing_key}") "$DEV" > Renaud: could you check if something like this helps? > But please bear in mind that c) is safe only if the 'new_passphrase' is > generated using approved random key generator. I don't know clevis/tang > internals good enough to verify that. (In reply to Sergio Correia from comment #5) > (In reply to Ondrej Kozina from comment #3) > > [...] > > > > > this needs to be verified by clevis/tang maintainer: > > c) Maybe clevis can safely switch to minimal pbkdf values since I expect new > > passphrase provided by clevis during luksAddKey action is in fact > > cryptographicly strong key (key generated with high entropy). > > > > Is that correct Sergio? > > > > Yes -- the key is currently generated with pwmake and 256 bits of entropy. > > > example for c) would look like this: > > > > cryptsetup luksAddKey cryptsetup luksAddKey --pbkdf pbkdf2 > > --pbkdf-force-iterations 1000 --key-file <(echo -n "${existing_key}") "$DEV" > > > > Renaud: could you check if something like this helps? I had a typo in the example, use this one instead: cryptsetup luksAddKey --pbkdf pbkdf2 --pbkdf-force-iterations 1000 --key-file <(echo -n "${existing_key}") "$DEV"" I can confirm this works fine on a 2GB system which has not much free during installation:
[anaconda root@vm-tpm84 ~]# free
total used free shared buff/cache available
Mem: 2005084 1087568 70380 388900 847136 364996
Swap: 4102228 723456 3378772
as per comment #7 I'm moving it clevis/tang. This change seems reasonable and it would also speed up clevis/tang based device activations with safe clevis generated LUKS2 passphrases. I don't manage to reproduce on my 8.4 VMs anymore, but now I have some issue with the TPM, could be the reason. 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 (clevis 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:1857 |