FS#66190 - [cryptsetup] "Keyfile could not be opened" has a dangerous behaviour and it is not present upstream
Attached to Project:
Arch Linux
Opened by Adrian Lopez (zeioth) - Thursday, 09 April 2020, 20:35 GMT
Last edited by Toolybird (Toolybird) - Wednesday, 27 September 2023, 06:56 GMT
Opened by Adrian Lopez (zeioth) - Thursday, 09 April 2020, 20:35 GMT
Last edited by Toolybird (Toolybird) - Wednesday, 27 September 2023, 06:56 GMT
|
Details
Description:
This line of code is triggered when you setup cryptsetup to look for a keyfile that doesn't exists. For example, when you have it in an USB stick, and you start the computer without it. I suggest changing the line [ ! -f ${ckeyfile} ] && echo "Keyfile could not be opened. Reverting to passphrase." For this one instead: [ ! -f ${ckeyfile} ] && echo "Keyfile could not be opened. Press enter to reboot." That would make it much more robust against social engineering. Additional info: * cryptsetup 2.3.1-1 * Affected line of code: https://git.archlinux.org/svntogit/packages.git/tree/trunk/hooks-encrypt?h=packages/cryptsetup#n33 * Apparently this problem only exists in arch and it's not present upstream. * Upstream report: https://gitlab.com/cryptsetup/cryptsetup/-/issues/550 Steps to reproduce: * Add a luks keyfile following all the steps described here: https://github.com/VfcD/P7/blob/master/README.md * Start the computer without providing the keyfile. |
This task depends upon
Closed by Toolybird (Toolybird)
Wednesday, 27 September 2023, 06:56 GMT
Reason for closing: Not a bug
Additional comments about closing: Refer to PM's comments
Wednesday, 27 September 2023, 06:56 GMT
Reason for closing: Not a bug
Additional comments about closing: Refer to PM's comments
LUKS supports up to eight passphrases, that exist side by side and either of them can decrypt the volume. One may want to use a passphrase as fallback.
If you do not want a fallback just do not add extra passphrases. But please do not complain if your hardware with keyfile breaks.
The most important: Always use strong passphrases.
If you have a full disk encryption, you are required to have at least one passphrase. You will be asked for it before grub loads.
In case you add a keyfile, you will be asked for it post grub, as an extra secutiry measurement.
It make no sense to ask two times for the password, THAT'S THE WHOLE POINT OF ADDING AN EXTRA SECUTIRY LAYER.
"But please do not complain if your hardware with keyfile breaks."
You can easily setup backup keys using udev rules.
Once again... What exactly is dangerous about it?
Anyone can see you while while you type. Passwords are not reliable.
https://i.imgur.com/0jQmQKX.jpg
Even so. There's no reason for a fallback method.
What's the point of adding a USB keyfile if I can skip it completely and use a password instead? Password that, again, cannot be deleted from luks if you have a full disk encryption, like the one Manjaro and many other distros offer out of the box.
What do you mean password can not be deleted from LUKS? Both LUKS1 and LUKS2 allow keyslot changing and removal.
https://git.archlinux.org/svntogit/packages.git/tree/trunk/hooks-encrypt?h=packages/cryptsetup#n87
If you try to delete that password from luks you will be propted to introduce a valid password, when you do, it will be rejected (since it's the last one). So you won't be allowed to delete it, even if you have a keyfile on a different slot.
But you have a point there, even if I have both luks password and keyfile, that doesn't add any extra security. Anyone with the password could easily use a live cd to mount the unit and have full access.
Therefore, indeed it might not be your responsability.
EDIT: Now that I think about it... If the only way to boot into the system with a keyfile is by not encrypting /boot, but if you don't encrypt /boot then you are vulnerable to injections of code in the ramdisk. Then indeed, the current system is the only one truly secure, as long as no one know your password.
'If the only way to boot into the system with a keyfile is by not encrypting /boot, ...' Why?
Keyfile is convenience feature mostly i think, especially because grub cannot use it. At least in full-disk (except grub) encryption scenario.
If you need to have computer unbootable without USB drive, then put keyfile in initramfs, which you put on LUKS encrypted stick along with kernel and grub and boot from it.
Other option is to have /boot on separate partition (passowrd protected so GRUB can open it) and then you can have your / keyfile-only protected.
If LUKS doesn't allow for deleteing password, put something long enough there and forget it.
For most people current solution is enough, as it provides fallback in case of keyfile loss and still protects your data well enough. Others can create solutions they need.
Furthermore: A keyfile is just a password stored in a file. It does not change the fact that you need to supply a valid password to unlock the container. Example: `dd if=/dev/zero of=test bs=4M count=500; echo -n 'test' > luks.key; cryptsetup -d luks.key luksFormat test; cryptsetup open test blahblah`, then enter 'test' when prompted for the password.
If a keyfile is supplied, it can be used in-place of a user-typed password, if it satisfies the key. If it's not, it'll prompt you for the unlock password.
The error is not ambiguous; it tells you exactly what goes wrong.