I'm trying to enroll with ykfde-enroll -d /dev/sda2 -s 2

Around once a second I get a new

Yubikey core error: timeout
   Remember to touch the device if necessary.

Hi, I can't figure out if I got myself an unsupported key or I'm doing something wrong. Please advice!

This is what I have https://www.yubico.com/products/security-key/

The Security Key by Yubico combines hardware-based authentication, public key cryptography, and the U2F and FIDO2 protocols to eliminate account takeovers.

Works out of the box with Gmail, Facebook, and hundreds more
Supports FIDO2, U2F
Waterproof and crush resistant

sudo ykpersonalize -2 -ochal-resp -ochal-hmac -ohmac-lt64 -oserial-api-visible
Yubikey core error: no yubikey present

[526554.956204] usb 1-4: USB disconnect, device number 5
[526555.681790] usb 1-4: new full-speed USB device number 6 using xhci_hcd
[526555.830941] usb 1-4: New USB device found, idVendor=1050, idProduct=0120
[526555.830943] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[526555.830944] usb 1-4: Product: Security Key by Yubico
[526555.830944] usb 1-4: Manufacturer: Yubico
[526555.831985] hid-generic 0003:1050:0120.0002: hiddev0,hidraw0: USB HID v1.10 Device [Yubico Security Key by Yubico] on usb-0000:00:14.0-4/input0

Hi,

We recently implemented HMAC SHA1 in OnlyKey, it is fully compatible with Yubikey's HMAC SHA1 challenge and response. We have integrated support with KeePassXC keepassxreboot/keepassxc#3352 and are looking to integrate with other projects as well. The only change required is to allow OnlyKey's USB VID/PID to be used in addition to the already allowed Yubikey USB VID/PIDs. Would you be willing to add support for OnlyKey?

Thanks!

I've made everything just like you explain it but I got this error when i run

ykfde-format --cipher aes-xts-plain64 --key-size 512 --hash sha512 /dev/<device>

Hello.

This is a very simple question :

Do the way you compute the passphrase with the yubikey is the same as the "yubikey-luks" modules that we usually use to cypher the filesystem of an install under ubuntu ?

Meaning, can it be used to unlock standalone partition on removable medias for example, of backups of such luks partition of backup hard drive with the yubikey itself ?

Q1:Does this require the yubikey to be connected to usb(typec) before powering it on? Or do you have to stick it in when prompted by the luks pw?
Q2:Can I add a regular pw in addition to yubikey?
Q3:Is it safe to remove the luks after deactivation?
Q4:Can I use it at the same time as PAM such as sudo?

I followed these simple steps below under Arch/Manjaro but ykfde-enroll fails and asks the question about an old LUKS passphrase that has never been set or required:

"Please provide the old LUKS passphrase for the existing keyslot."

Any ideas? Thanks!

#create an empty partition using "Disks" w/o filesystem.

sudo pacman -Syu yubikey-full-disk-encryption

$sudo nano /etc/ykfde
YKFDE_CHALLENGE="something"
YKFDE_CHALLENGE_SLOT="2"

$sudo ykfde-format --cipher aes-xts-plain64 --key-size 512 --hash sha512 /dev/<device>
WARNING: This script will run 'cryptsetup luksFormat --cipher aes-xts-plain64 --key-size 512 --hash sha512 /dev/<device>'.  If this is not what you intended, please abort.
   Remember to touch the device if necessary.
   New LUKS device successfully formatted
   
$sudo cryptsetup luksDump /dev/<device>
LUKS header information for /dev/<device>
Version:       	1
Cipher name:   	aes
Cipher mode:   	xts-plain64
Hash spec:     	sha512
Payload offset:	4096
...
Key Slot 0: ENABLED
...
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

$sudo ykfde-enroll -d /dev/<device> -s 2
INFO: Setting device to '/dev/<device>'.
INFO: Setting LUKS keyslot to '2'.
 > YubiKey slot status 'ykinfo -q -2': 1
WARNING: This script will utilize LUKS keyslot '2' on device '/dev/<device>'.  If this is not what you intended, please abort.
   Running: 'ykchalresp -2 something'...
   Remember to touch the device if necessary.
   Received response: '1121389712098712340987019238470987'
Please provide the old LUKS passphrase for the existing keyslot.
 Enter passphrase: 123456
 > Passing '123456' to 'cryptsetup'
 > Adding new LUKS passphrase with 'cryptsetup --key-slot=2 luksAddKey /dev/<device>'...
No key available with this passphrase.

Please use a proper kdf and salting instead of sha256sum. Sha256 can be done very quickly so you can create rainbow tables for common passwords. You can use scrypt for instance and a 64 bit random salt.

It would be nice to have script for easy adding new password instead of manually invoking several commands and copy+paste password to LUKS.

Hi,
I wanted to use this package on my freshly installed full-disk encrypted arch installation. However, I cannot unlock my device during boot using Yubikey...

When I test the configuration:
ykfde-open -d /dev/sda2 -s 2 -t
I can successfully decrypt my device.
During boot, I'm asked for the password, but not to push the button on my Yubikey like it is done during the test case. The unlock then fails.

My /etc/default/grub looks like:
GRUB_CMDLINE_LINUX_DEFAULT="quiet cryptdevice=/dev/sda2:Archlinux root=/dev/mapper/Archlinux-root"

and my hooks in /etc/mkinitcpio.conf look like
HOOKS=(base udev autodetect keyboard keymap modconf block ykfde encrypt lvm2 filesystems keyboard fsck)

My /etc/ykfde.conf is unchanged, everything is commented. I tried the procedure with DBG=1 to get further information, but I can just see that ykfde is trying my challenge to unlock my device without making any attempt to receive data from the yubikey.

Probably I'm still doing something wrong, but I can't see it. So I'm sorry if this is a stupid mistake.

Thank you

Hey

Thank you very much for this tool. It worked great for me when using on external drives. However, I struggle to get it running on my encrypted root partition.

I set up the 2FA according to the description. When I boot I can unlock the disk, but seconds later the entire system is frozen. Weirdly, my CapsLock key is blinking. I already checked my journal without finding anything that could help. Any idea what could cause this?

I am running arch linux (5.16.0)

During boot the shutdown hook throws this error : cp:can not create directory :'/run/initramfs/' no such file or directory

The initramfs files necessary for the luks-locking suspend are not created in /run/initramfs so we do a normal suspend see suspend script.

There is already an issue about this on the mkinitcpio repository and a bug reported.

While waiting for a fix on mkinicpio or whatever is causing this problem, you can check here for a temporary solution.

I'm a little confused about the configuration of the 1FA bit. Is the "challenge" being set in ykfde.conf the actual secret key that was written to the yubikey in the HMAC-SHA1 Challenge-Response config step?

I'm using Manjaro, and my root partition (as well as home, var and opt) are part of an LVM that's inside a LUKS-encrypted partition. Slots 0 and 1 in LUKS are already configured.

I installed yubikey-full-disk-encryption-git, and ran:

ykfde-enroll -d /dev/nvme0n1p3 -s 2

This worked correctly, and when I tested with ykfde-open -d /dev/nvme0n1p3 -s 2 -t, it came back with "Device successfully opened".

I added ykfde to my mkinitcpio HOOKS, but after rebooting, it just asked me for my passphrase (slot 1, btw), like normal.

I realized that when I ran the test command above, it would fail unless the yubikey was inserted before I ran it. Do I need to plug in the yubikey before booting my machine for this to work?

Here are the HOOKS in my /etc/mkinitcpio.conf:

HOOKS=(base systemd autodetect modconf block keyboard sd-vconsole ykfde sd-encrypt sd-lvm2 filesystems fsck)

I was trying adding my yubikey to luks.
As i follow the readme it allways say No key available with this passphrase.
I do not understand this.

I recently installed Arch Linux, and followed the guide to encrypt my root directory as described here: https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Encrypting_devices_with_LUKS_mode. The command I used was:

cryptsetup -y -v luksFormat /dev/sda7

I have successfully booted and unlocked the drive with the passphrase I set up, and ran the command in a previous issue:
#36
without any issue.

However, when I attempt to enroll a key via ykfde-enroll -v -d /dev/sda7 -s 2 -o I get the error No key available with this passphrase.

I'm trying to avoid running luksFormat again because I don't want to have to redo everything I've already setup. Is the problem that I didn't encrypt the drive with the proper flags the first time, making it incompatible with the key enrollment? If so, do I simply need to reformat the drive? If I need to reformat, is there a way I can do this without losing my data?

Output of luksDump

Hi, the YKFDE_CHALLENGE= key appears to not work /etc/ykfde.conf

I am putting the exact same password to unlock it with 2FA, but with 1FA it doesn't seem to go.

edit: As in it seems to fail to authenticate. "No Key available with this passphrase"

Running latest archlinux

$ pacman -Q yubikey-full-disk-encryption
yubikey-full-disk-encryption r143.2ce7aa7-1

$ pacman -Q cryptsetup
cryptsetup 2.3.4-1

Hello,

I have an UEFI boot setup where my EFI system partition is unencrypted, but my boot partition is encrypted. In fact, I don't have a proper boot partition, boot lives in the root partition, which is encrypted.

Following the README I'm able to have this working after I manually unlock boot with a passphrase.
Current boot process steps:
(passphrase for unlocking boot) -> GRUB -> (yubikey for unlocking root) -> system booted.

I'm wondering if yubikey can be used for unlocking the boot partition as well. Eliminating step 1.

I read that mkinitcpio will not maintained anymore. Any plan to support dracut as replacement, bro?

This is a really great tool!
I just have one minor issue with using a btrfs filesystem with the ykfde suspend service. It fails because of the barrier=0 option fix for ext4 filesystems, because it doesn't seem to be an option for btrfs. Got it working with commenting out the whole fix. I would suggest adding a check whether the filesystem really is ext4 inside the if before remount it.

Hey I followed the installation instructions as close as possible, but I think I cant get the ykfde hook to work on boot. As far as I can see, the enroll step worked. ykfde-open check returned success.

I configured the /etc/mkinitcpio.conf accordingly and the hooks line reads: HOOKS=(base udev plymouth autodetect keyboard keymap consolefont modconf block ykfde plymouth-encrypt lvm2 filesystems fsck) obviously I use plymouth. However I think #19 is implemented and available in the arch linux community package.

I use btrfs on luks for my root partition and grub as boot manager. My grub setup uses cryptdevice to find the root partition:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/nvme0n1p3:root"

When I try to decrypt my setup with the yubikey, to me it looks like, the ykfde hook is not working correctly, as when I add the passphrase for the challenge, the key is not flashing and thus it cant be used to generate the challenge response. Any suggestions how to debug this?

We've already known that ext4 barrier prevents system from suspending, so remounting cryptdevice with nobarrier option will solve the problem.

But src/ykfde-suspend#L79 can't handle ext4 filesystems on lvm layers as is described at ArchWiki now, hanging the suspend process.

I believe that the problem can be solved by detecting ext4 filesystems running on crypted lvms and remount them accordingly, or adding a config option to allow users specify their own ext4 logic partitions.

However, I haven't figured out yet whether these approaches are feasible and how they can be implemented. Any ideas?

Hi,

I just successfully set up my Arch with "true" (password/SHA256-based) 2FA - thanks a lot for an awesome piece of software!

Just one small suggestion: I found it quite confusing (and not documented) that, if I use the "true" 2FA, I still need to set YKFDE_CHALLENGE to some non-empty value. Otherwise, the initrd hook goes into "fallback" mode and queries for the password only.

From your perspective, would it make sense to change the behaviour, so that the Yubikey authentication is also performed if YKFDE_CHALLENGE is empty, but YKFDE_CHALLENGE_PASSWORD_NEEDED is set?

Whenever I start my computer, Grub prompts me for the LUKS decryption password (and drops me to a rescue shell if I don't comply) before I even have the chance to use YKFDE. After supplying my decryption password to Grub (I have two passwords enrolled, one "simple" password and one 2FA YubiKey password) the boot continues and goes into the YKFDE prompt where I put in my challenge, touch my YubiKey and am then told that the crypt device is already decrypted and mounted.

My boot partition is not encrypted, my /etc/mkinitcpio.conf hooks are HOOKS="base udev autodetect keyboard keymap modconf block ykfde filesystems fsck", my /etc/defaults/grub default command line is GRUB_CMDLINE_LINUX_DEFAULT="quiet cryptdevice=/dev/nvme0n1p2:luks-manjaro:allow-discards root=/dev/mapper/luks-manjaro resume=/dev/mapper/luks-manjaro".

I'm assuming my Grub is somehow misconfigured, but I coulnd't find any resources on how to do so correctly.

I tried setting up ykfde on my PinePhone (running Manjaro ARM) the same way I did on my laptop, but it doesn't work:

1. Set up an encrypted filesystem on the phone's SD card
2. Then set up /etc/ykfde.conf
3. Add ykfde hook to /etc/mkinitcpio.conf
4. sudo mkinitcpio -P
5. When I reboot, my drive does not appear under /dev/mapper

I am able to manually decrypt it using the YubiKey with ykfde-open, so it has something to do with the hook, probably. I tried moving the keyboard hook to the front, but that didn't help.

What else can I try to debug this?

Currently suspending machine with unlocked disk leaves it unencrypted. There are however luksSuspend and luksResume commands which overcome this.

Actual implementation in initramfs already exists and it integration will make this project more complete.
https://github.com/NerdyProjects/arch-luks-suspend

As enhancing LUKS passphrase with user provided passwords is already implemented I think we can go step further and use this password as actual challenge provided at runtime instead of using one hardcoded in config.

Above will make the whole setup more robust and more secure as there will be no more stored secrets which can leak or be lost.

I think this behavior should be default for anyone who's using passwords already. Users will provide password before yubikey challenge-response instead. Those who don't use password will stay with challenge stored in config.

Behavior of using password as challenge is already implemented in https://github.com/cornelinux/yubikey-luks , however it doesn't combine password as part of LUKS passphrase yet, see cornelinux/yubikey-luks#15

PKGBUILD fails during makepkg -s due to package name change from yubikey-full-disk-encryption to yubikey-full-disk-encryption-git

pkgver() {
cd "${pkgname}"
printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}

Hi,

Is it possible with your ykfde initramfs hook (for archlinux :)), to do as you wrote:
1.) so use the challenge configured in the config file and send it to the key to receive the response
2.) and either before or after (or before AND after) this response to add a PASSWORD, that one has to type in every time (in addition to touching the yk4)
?

I think that would be awesome, becuase even if someone would have both laptop and yk4 they still would need the password like this.

Thanks a lot in advance,

Tormen

Hello there! I was checking your scripts and I noticed that you pass the password to the ykchalresp bin as part of its command line, thus exposing it to the system:

If you run top or htop you will see the password shows up there. The same happens in the initram script, but on that scenario is not so dangerous. However, on the already booted up scenario, having the password shown as part of the command is VERY dangerous.

I haven't used ykchalresp but a better approach would be to pass the password like: printf "%s" "$P1" | ykchalresp -2 - or something like that (we need to test this).

I currently have my luks header on a usb drive and I’m trying to add ykfde to a free keyslot. However, ykfde-enroll and ykfde-open don’t seem to read out the additional parameters with the syntax -- --header /$headerlocation, so the luks device isn’t recognized. What am I missing?

On another note, the header flag does seem to be recognized byykfde-format since it shows up in luksDump. There’s no way to verify it though since I can’t open it.

Hello, Thanks for any advice/help in advance!

TL;DR;
I accidentally overwrite my Yubikey slot “2” (using ykpersonalize), and my laptop is now failed to decrypt my volume.

I have 2 devices that are already encrypted.

1. Laptop, Archlinux, LVM volume encrypted using LUKS, and I configured Yubikey for 2FA to decrypt the volume.
2. Desktop, Debian, LVM encrypted using LUKS and decryption is using passphrase key.

Yesterday, I was trying to add Yubikey into my desktop for 2FA (While keeping passphrase as key slot 0, for backup), I run ykpersonalize command which overwrite the existing key that I was using for my laptop. Thinking that my laptop has passphrase as backup too. However, today morning, when I was trying to login to my laptop, I couldn’t decrypt the volume and every time I put the Yubikey passphrase, it just respond:

FAILED! [2] No key available with this passphrase.

When running cryptsetup luksDump <LVM_physical_volume> it just shows that I only have one key slot.

Is there anything I can do to restore my Yubikey to work on my laptop?

Thanks

First of all, great software!

I'm using 1FA on a non-root partition, with TRIALS and TIMEOUT set to 1.
If the YubiKey is disconnected, it falls back to asking a password. If I don't want to mount the partition, I need to press ENTER to skip.

Is there a way to auto-skip, set a timeout or disable the fallback?

Thanks!

PS: Is not the fallback to the encrypt hook as suggested in the README, I don't have it enable.

Plymouth is a tool used to display the initial bootstages better.
You can read more about it here.

It however, requires the Encrypt hook to be replaced with Plymouth-encrypt.
Since YKFDE replaces the encrypt module as well, I was wondering if you could make a plymouth compatible version.

If we're using systemd-boot, should the udev and shutdown hooks be replaced with systemd and sd-shutdown?

First off I just want to say amazing package; thank you so much for configuring this!

Secondly; I have a handful of encrypted drives, I wanted to inquire if it was possible to decrypt more than just the root drive while booting by setting an option in /etc/crypttab file to use the yubifde package instead of prompting for a password.

Finally I wanted to inquire if it is possible to use both 2FA and 1FA depending on the drive.
I.E. ideally I would like my / partition to be 2FA, but then have my /home partition automatically decrypted using 1FA and a password stored on my / partition instead of a password stored in the config.

Again Love the package, thank you!

Hello,

I am using the primary key was 1FA which is working well. However, I want to register my secondary key incase the primary one gets lost.

At the moment i have populated YKFDE_CHALLENGE="" with the string which the key emits on short touch. This passphrase is set by Yubico as a factory setting. My backup key has a different default passphrase. Can YKFDE_CHALLENGE accept multiple passphrase corresponding to each of my yubikey?

Thanks

It seems that the latest aur package was missing.
I could be your co-maintainer.

With YFDE, I cannot get the discard to work in any way...

According to the documentation, YFDE should read configuration from cryptdevice kernel parameter. This works, but not for allow-discards part.

Grub config - /etc/default/grub:

GRUB_CMDLINE_LINUX="cryptdevice=UUID=...:some-luks-vol:allow-discards ..."

Following line was enough to enable discard without YFDE.

So I've tried to force it in /etc/ykfde.conf:

# Optional flags passed to 'cryptsetup'. Example: "--allow-discards" for TRIM
# support. Leave empty to use 'cryptdevice' boot parameter.
YKFDE_LUKS_OPTIONS="--allow-discards"

Revision: I had initially figured that the problem was related to the trail counters,
After testing a little bit more and reading over some of the code it appears that after suspending the system, with the suspend-module active, it can get stuck on 'Decrypting.


It seems that the suspend-resume variant does not include trails, but more importantly, does not allow for a manual passphrase or retry, which means that it gets stuck after the Initial attempt, retry and last try fail.

After which is props up
Decrypting {cryptsetup luksResume}...
At which it will sit until a power cycle.

As the title says, how do I go about adding a regular luks key (as a backup in the unlikely event I lose access to all of my yubikeys at the same time)? Since luksAddKey requires an existing passphrase and my only slot is with ykfde, I’m unable to use cryptsetup. Does ykfde-enroll have the option not to use the yubikey?

The script used dejavu-sans font (plymouth support ) .
If you not install dejavu-sans , plymouth message will not displaying properly.
So i think, it should write in readme.

Is it possible to use this with Arch/Windows Dual Boot?

Hey @agherzan,
thanks for this great module. I'm using the ykfde-suspend.service. After locking my encrypted volume. I face some weird bugs e.g.

Bug 1: The module freeze and no password promt appears

Bug 2: Weird infinity loop, which shows "no Entity"
The prompt appears but this bug appears if the usb device is present (at first) and you remove it in the password prompt.

Either, I have to restart which is kind of annoying.

I'm using the 5.10.16-arch1-1 kernel.
I also recommend to provide github issue templates, because for me it is hard to tell which information are needed as well.

Regards,
William

Thank you for your nice work! This script may run into error when multiple Yubikeys are connected. A way to resolve this could be to bind the serial of Yubikey in config.

Hi and thanks a lot for this great and quite useful project!

I've been wondering if you would consider making the use of udisksctl optional. At least on Arch Linux, udisks2 brings and pulls many things I don't need, just to allow unprivileged use of ykfde-open while your tool is otherwise attractively simple and standalone.

I think it would be rather straightforward to move udisks2 (and thus expect too) to optdepends, and check if udisksctl and expect are available on the system at runtime when reaching the unprivileged use case. What do you think?

For support Debian/Ubuntu preparation of special version of initramfs script is needed. Also adding deb build recipes in debian subdirectory.

After enabling ykfde-suspend I seem to experience some RAM issues with applications that are open. These problems more often than not occur after longer suspends. (> 5 minutes). For instance my desktop env (sway) will sometimes not draw context menus and some UI applications will seemingly crash until I force reboot.

Currently we support only luksOpen and luksAddKey commands without much customization. It would be better to have universal wrapper over cryptsetup commands which will pass ykfde password to them.

Example:

ykfde-wrapper luksFormat --hash sha256 --iter-time 5000 /dev/sda
will execute:
cryptsetup luksFormat --hash sha256 --iter-time 5000 /dev/sda
and automatically pass ykfde password to it.