Closed Falroi closed 3 years ago
No. The challenge is different than the secret written to yubikey. In order to retrieve yubikey response you need to combine them both:
challenge + secret key on yubikey = yubikey response
In 1fa mode they yubikey response is also the LUKS password.
The readme states:
The YubiKey response is a HMAC-SHA1 40 byte length string created from your provided challenge and 20 byte length secret key stored inside the token. It will be used as your LUKS encrypted volume passphrase.
Is the challenge just a phrase we make up though or is it something we need to generate? At this point I believe I'm following the readme correctly. Are there any known issues using this with UEFI systems?
Users can set anything they want as challenge but it can't be longer than 64 characters. UEFI/BIOS shouldn't have any effect on usage of this project.
So far each of my attempts get me as far as the welcome to grub screen, Attempting to decrypt master key... and a prompt to enter passphrase for hd0.gpt2 (
I am encrypting with luks at the time of installation via the garuda installer.
Did you enrolled ykfde compatible password with ykfde-enroll in post install?
I am encrypting with luks at the time of installation via the garuda installer.
Did you enrolled ykfde compatible password with ykfde-enroll in post install?
The first time I tried using a password that was 7 digits and an * the second time I tried using two words with no space and a string of 7 digits with no space. Yes, I'm using the method you've linked.
Update: I this could be hook related. I've just read that Garuda uses or has used plymouth by default. So at this point I'm going to try replacing the plymouth-encrypt hook with ykfde in mkinitcpio and regenerating.
Update: No luck. It seems like it only wants to decrypt with keyslot 0 which is not the yubikey.
Update: I this could be hook related. I've just read that Garuda uses or has used plymouth by default. So at this point I'm going to try replacing the plymouth-encrypt hook with ykfde in mkinitcpio and regenerating.
Without ykfde hook there is no chance it could work.
Update: No luck. It seems like it only wants to decrypt with keyslot 0 which is not the yubikey.
Is it ykfde doing the decrypt? Can you confirm you have more than one keyslot used on device and ykfde password works when you try it on running system?
Please ensure you have the right challenge written in /etc/ykfde.conf as YKFDE_CHALLENGE="<challenge>"
then run sudo ykfde-open -d /dev/<address> -t -v -n test
.
Update: I this could be hook related. I've just read that Garuda uses or has used plymouth by default. So at this point I'm going to try replacing the plymouth-encrypt hook with ykfde in mkinitcpio and regenerating.
Without ykfde hook there is no chance it could work.
Update: No luck. It seems like it only wants to decrypt with keyslot 0 which is not the yubikey.
Is it ykfde doing the decrypt? Can you confirm you have more than one keyslot used on device and ykfde password works when you try it on running system?
As of now no, on boot its grub trying to handle the decrypt, and its asking for my passphrase using keyslot 0. Yes ykfde does work for both partitions on a running system I enrolled with ykfde.
Please ensure you have the right challenge written in /etc/ykfde.conf as
YKFDE_CHALLENGE="<challenge>"
then runsudo ykfde-open -d /dev/<address> -t -v -n test
.
Verified this and used the command posted, yubikey lights and unlocks the encrypted device with ykfde no problem. It looks like as of now my only issues are with booting only using the yubikey.
grub is bootloader which only loads initramfs where encryption should happen unless you encrypt whole disk including /boot
.
Could you post contents of /etc/mkinitcpio.conf
?
I have three partitions total, /boot/efi (unencrypted), root (encrypted) and swap (encrypted). I will post the contents of /etc/mkinitcpio.conf as soon as I'm home: about an hour or so. Thank you for helping me through this! Note: grub does see the partition as encrypted but its asking for me to input a passphrase as I still have the original keyslots (non ykfde) of my luks encrypted partitions active.
So as I understand you have /boot
encrypted and you unlock disk at first by grub cryptodisk feature. For such scenario you can't utilize ykfde because grub isn't aware of it, see also https://github.com/agherzan/yubikey-full-disk-encryption/issues/33#issuecomment-418074107 .
Theoretically ykfde can work in second phase, inside initramfs to do second unlock (post-grub) but it supports only one encrypted partition while you have encrypted swap additionally (unless you use lvm).
Out of curiosity why would the partition manager say /boot/efi is a non encrypted partition?
/boot/efi
is separate partition from/boot
. EFI partition (in your case mounted in /boot/efi
) can't be encrypted.
/boot/efi
is separate partition from/boot
. EFI partition (in your case mounted in/boot/efi
) can't be encrypted.
Would you recommend I manually create the partitions on a fresh install? What would you do if it was your system?
I made my recommendation before in https://github.com/agherzan/yubikey-full-disk-encryption/issues/33#issuecomment-418074107 . Instead of swap you may use zram.
Closing as duplicate of https://github.com/agherzan/yubikey-full-disk-encryption/issues/33 .
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?