FDE with 2FA doesn't check 2nd factor? about mkinitcpio-ykfde HOT 14 CLOSED

There can be various reasons for that.

First of all... What version are you using?

When you run ykfde -s <2fa>, does it report errors? Does it return with exit code 0?

Possibly you have an active LUKS slot that works with your Yubikey but without 2nd factor. See your acitve slots with:

$ cryptsetup luksDump /dev/<luksdev> | grep ABLED
Key Slot 0: ENABLED
Key Slot 1: ENABLED
Key Slot 2: ENABLED
Key Slot 3: ENABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Does the timestamp (and file content) of the challenge in /etc/ykfde.d/ change?

from mkinitcpio-ykfde.

AFAICT, I'm running the latest version:

$ ykfde -V
ykfde: ykfde v0.6.1 (compiled: Apr  5 2016, 09:25:56)

ykfde -s <2fa> reports no errors and the exit code is 0. Shouldn't it report an error if I already have a second factor and I dont' use ykfde -n <new-2fa> -s <old-2fa>?

I checked the luks slots, and I only have 2 enabled: the one without the yubikey and the one with the yubikey. I tried rebooting without the yubikey to make sure.

There are new files created in /etc/ykfde.d/ everytime I do ykfde -s.

from mkinitcpio-ykfde.

I think I know what is going on, but I don't know how to fix it.
Basically, it seems that the yubikey is still configured without the 2fa.
If I boot without the yubikey plugged, press enter when it asks for the 2fa and then inserts the yubikey, then the disk is decrypted, as it did before I set up 2fa.

from mkinitcpio-ykfde.

So. I erased everything, removed the challenges, killed the slot used by ykfde and then re-set it.
Even then, it doesn't require the 2nd factor.
Do I need to do ykfde first and then ykfde -s <2fa>?
EDIT: doing ykfde first and then `ykfde -s <2fa> didn't change anything.

Here are the hooks in my mkinitcpio.conf:

HOOKS="base systemd autodetect modconf block keyboard sd-encrypt ykfde filesystems fsck"

and here is the ykfde.conf:

[general]
yk slot = 2
device name = root
second factor = yes

[3644995]
yk slot = 2
luks slot = 1

from mkinitcpio-ykfde.

Does it help to run ykfde -n <2fa> or ykfde -s '' -n <2fa>?

from mkinitcpio-ykfde.

If I run ykfde -n <2fa> I get a Failed requesting key. That's ok if you do not use second factor. Give it manually if required., if I do ykfde -s '' -n <2fa>, then I get no error. In both cases, nothing changes. Are there any logs anywhere?

from mkinitcpio-ykfde.

This does not log, no.

Should work as expected... Are you sure there is no other mechanism unlocking with your static key in slot 0? It does not boot when the Yubikey is missing, no?

Looks like I have to sleep on it for a night... Currently I am out of ideas.

from mkinitcpio-ykfde.

OK.
I'll nuke slot 1 and check that it doesn't boot with only slot 0.
If the Yubikey is not plugged in, I definitely have to type the password.

from mkinitcpio-ykfde.

Ok, did some testing inside a virtual machine. Let's go step-by-step:

Let's set up and map a LUKS device:

$ truncate --size=10G /tmp/image
$ losetup -f /tmp/image 
$ cryptsetup luksFormat /dev/loop3                          

WARNING!
========
This will overwrite data on /dev/loop3 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase:
Verify passphrase:
$ cryptsetup luksOpen /dev/loop3 crypt
Enter passphrase for /tmp/image:

This has a static passphrase now. So run ykfde now. It will set up another slot based on your settings in /etc/ykfde.conf. Give the static passphrase from above. We ignore the warning, this does not yet have a second factor.

$ ykfde
Failed requesting key. That's ok if you do not use
second factor. Give it manually if required.
Enter any passphrase:

Now we can run ykfde again to update the challenge. No passphrase needed this time, still ignoring the warning.

$ ykfde
Failed requesting key. That's ok if you do not use
second factor. Give it manually if required.

So let's try with a second factor. That should fail as there is non.

$ ykfde -s foo
Could not update passphrase for key slot 1.

Giving an empty second factor and setting a new one works, though.

$ ykfde -s '' -n foo

Running the same command again fails as the second factor is no longer empty.

$ ykfde -s '' -n foo
Could not update passphrase for key slot 1.

But with the correct second factor it works.

$ ykfde -s foo

Now let's kill the slot and start over.

$ cryptsetup luksKillSlot /dev/loop3 1
Enter any remaining passphrase:

With an empty slot we can set up the second factor directly.

$ ykfde -s bla
Enter any passphrase:

Works as expected... If it does not work for you anything from above must behave different.

from mkinitcpio-ykfde.

Ah, I have an idea... Last chance to explain your behaviour: Your Yubikey is not configured for HMAC-SHA1. Looks like I have to catch that condition in my code.

from mkinitcpio-ykfde.

I'll try again tomorrow morning, and I'll check to see if the yubikey is configured properly.

from mkinitcpio-ykfde.

Pushed commit 8c5352f, that should give something like this if the Yubikey is not configured properly:

yk_challenge_response() failed: Resource temporarily unavailable

from mkinitcpio-ykfde.

So... it seems the yubikey wasn't in HMAC-SHA1 mode...
Everything works fine now. Thanks a lot, and sorry for all the trouble.

from mkinitcpio-ykfde.

No problem. ;)
I found and fixed a bug in my code... So next time we will find the cause faster.

from mkinitcpio-ykfde.