Added 1FA hardware hash support

[Samdaaman]

Overview

As noted in the Readme 1FA offers weaker security as an attacker only needs to gain access to your bootable medium and yubikey to be able to decrypt luks partitions. 1FA authentication with a hardware-based hash aims to add an additional degree of security by using a hash of the hardware info (eg serial numbers) as the challenge password. This improves security if your bootable medium is different from the machine you boot off (eg a laptop and usb drive) as an attacker would need to get a hold of your laptop as well as your usb and yubikey.

In my case, I use a portable SSD as a bootable medium which can be prone to getting lost. With 1FA w/ hardware hash I am able to boot use passwordless boot on two of my laptops while any other device requires the original LUKS password. Yes someone could decrypt my SSD without a password, however it would require aquiring my laptop, yubikey and SSD.

How it works

How is the hardware hash calulated

dmidecode -t system | sha256sum | awk '{print $1}')

dmidecode prints the manufacturer, product name, serial number and uuid for your laptop/computer. It is then hashed with sha256 and used as the challenge password

See this line for an example

Multiple devices?

To use multiple devices with this method, you must run yubikey-luks-enroll on each device and change the LUKS slot (-s option) each time. Since each device has a unqiue serial, it will have a unique challenge password and response and therefore must have an individual keyslot.

Links

I found this issue where the idea is mentioned

[Samdaaman]

I just thought it might be a good idea to warn about the danger that this could lock you out if the input to the hardware hash changed for an external reason. It's always a good idea to have a strong backup master password for any of the yubikey-luks configurations

[Vincent43]

I don't know if I understand this correctly - dmidecode reads specification of your laptop and hashes it. Reading this information is available for anyone who has access to your laptop and access to your laptop is needed to unlock encrypted disk it contains anyway so from where the security gain comes from? Why attacker would need your external ssd additionally and how hardware hash of your lap makes difference for it?

Also dmidecode -t system contains a lot of output including dmidecode version which looks very brittle to rely on in the long run moreover it needs root privs while yubikey-luks-open script has rootless mode which would stop working with new option.

[Samdaaman]

Good points @Vincent43. Perhaps performing a grep on certain relevant lines in the dmidecode output could make for a more robust hash input.

As for extra security. I run bootable Linux off an external SSD that is separate from my laptop. By using the hashed hardware specifications of the laptop (such as serial number) as the challenge password it is much harder for someone to unlock the LUKS partition on the SSD with only the SSD and yubikey as they need to guess this password (or the inputs to the hash). Obviously someone would be able to unlock it if they had all three but I am willing to accept the risk for the convenience.

Good point about the luksopen not requiring root. Perhaps this option will only work with root, or if there is a non-root alternative to dmidecode

[Vincent43]

So the LUKS partition is on external SSD and laptop is only needed as unlocker?

Recent systemd-cryptenroll support unlocking LUKS with TPM2 module which you may find interesting.

[Samdaaman]

Good points. My laptop is one part of the unlocker (you also need the yubikey as well to compute the challenge response from the hardware hash).

There are a few reasons why I chose to extend yubikey-luks rather than using TPM2:

• One of my laptops doesn't support TPM2
• TPM2 requires only the laptop being present, with yubikey-luks with hardware hash the laptop and yubikey are required (more secure)
• You are also able to unlock the drive via other Luks keys slots (for example I have a backup master passphrase to use if I am using a new device or if the hardware hash fails).

I understand that this is a niche use case. My goal was to improve the security of 1FA for external SSDs without compromising the usability benefits.