On 10/30/23 14:42, Jonathan Billings wrote:
Nothing is preventing you from backing up the LUKS header (cryptsetup luksHeaderBackup), it's just that it is encrypted and includes whatever keyslots you have, and if they're all removed (or you don't remember the pass phrase for them), it isn't really going to help you decrypt an unlocked volume without a passphrase or any of those other methods. What you're asking is the ability to extract the decryption key of the unlocked LUKS volume without knowing any of the methods used to decrypt it. That would be a huge security hole.
I've investigated the topic a bit deeper and want to describe how things really are, for convenience of somebody finding this thread in the future. The fact that the encryption key is not readable anymore when using LUKS2 is due to the fact that the key is not passed to the DM system by value, but by reference to a key loaded in the kernel keyring with type "logon", for which there is no "read" operation. My concern was about the impossibility of ever getting the value of this key for backup purposes, and having to rely on backups of the second level machinery (passphrases etc.). It turns out that the key can be read if one of the passphrases is known. This means that the owner of the machine *can* get the key value, store it in a safe place, while still making the key inaccessible to somebody running software on the system (even as root). The "cryptseup luksOpen" command can be instructed to NOT use the kernel keyring when opening the encrypted volume (--disable-keyring). At that point the --showkeys option of "dmsetup table" works as it used to be in the past. After having done this just once, and got the value to backup, the system owner can decide to let the kernel keyring to be used for normal daily operation. This accomplishes both the (non conflicting anymore) desires expressed in this thread: - the owner can get the encryption key value and save it somewhere for future disaster recovery (this make me happy) - the owner can be sure that a malicious user with root privileges will still not be able to get the key value (this makes somebody else happy) The problem described at the beginning of the thread (passphrases are refused but disk is open) would still not be solvable as is, but at least the owner could have made a backup of the key in the past if sufficiently foresighted. Regards. -- Roberto Ragusa mail at robertoragusa.it _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
