[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-list
Subject:    Re: LUKS - lost token?
From:       Roberto Ragusa <mail () robertoragusa ! it>
Date:       2023-10-30 19:57:56
Message-ID: e75f9463-1749-5c95-a4a0-474fcf4839f0 () robertoragusa ! it
[Download RAW message or body]

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@lists.fedoraproject.org
To unsubscribe send an email to users-leave@lists.fedoraproject.org
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@lists.fedoraproject.org
 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue


[prev in list] [next in list] [prev in thread] [next in thread]