Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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 freswa (frederik) - Thursday, 09 April 2020, 20:51 GMT
Task Type Bug Report
Category Packages: Extra
Status Assigned
Assigned To Christian Hesse (eworm)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

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

Comment by Christian Hesse (eworm) - Thursday, 09 April 2020, 20:58 GMT
What exactly is dangerous about it?
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.
Comment by Adrian Lopez (zeioth) - Thursday, 09 April 2020, 21:15 GMT
"If you do not want a fallback just do not add extra 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.
Comment by Adrian Lopez (zeioth) - Thursday, 09 April 2020, 21:15 GMT
And please do not suggest to avoid encrypting /boot, because that's even more dangerous. One could inject a trojan into a ramdisk and execute basically whatever they want.
Comment by Christian Hesse (eworm) - Thursday, 09 April 2020, 21:24 GMT
You can have one passphrase for /boot, another passphrase and keyfile for /. IMHO the code is correct.
Once again... What exactly is dangerous about it?
Comment by Adrian Lopez (zeioth) - Thursday, 09 April 2020, 21:28 GMT
Oh wait and it's even better: When you are asking for the fallback password, there's not even attempts limit or time delay. Crackers must love your "feature".
Comment by Adrian Lopez (zeioth) - Thursday, 09 April 2020, 21:29 GMT
"Once again... What exactly is dangerous about it?"
Anyone can see you while while you type. Passwords are not reliable.
Comment by loqs (loqs) - Thursday, 09 April 2020, 22:05 GMT
Retries is limited to the compiled in default for cryptsetup of three. Timeout delay is enforced by the iterations count of the key derivation function for the keyslot.
Comment by Adrian Lopez (zeioth) - Thursday, 09 April 2020, 22:22 GMT
Three attempts? I have way more than three here:
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.
Comment by loqs (loqs) - Thursday, 09 April 2020, 22:35 GMT
I think it is the while loop [1] which appears to keep looping with a two second delay? Note the prompt change in your image after the third attempt.
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
Comment by Adrian Lopez (zeioth) - Thursday, 09 April 2020, 22:49 GMT
Because when you have a full disk encryption, there's a pre-grub screen asking you for your luks password.
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.
Comment by Maxim (mxfm) - Friday, 10 April 2020, 19:48 GMT
Andrian, can you elaborate on your logic (taking into account rethinking in last comment)? In luks, as in plain dm-crypt mode a key and a passphase are two views of the same 'secret' material, so if key is unavailable (because uderlying device is not inserted), then passphrase can be entered.

'If the only way to boot into the system with a keyfile is by not encrypting /boot, ...' Why?
Comment by VladimĂ­r Dudr (sogun) - Thursday, 14 May 2020, 21:24 GMT
Adrian, honestly if you don't protect your grub, someone can install trojan to your bootloader, if you don't protect your firmware, someone can put trojan there, etc... Or you get coldbooted, or someone just hacks you intel ME, or ...

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.

Loading...