FDE with 2FA doesn't check 2nd factor?

[guiniol]

Hello,

I set up ykfde to use 2 factor authentication. Everything seems to work great, but this morning I typed a wrong password and yet, my disk was decrypted. So I tried again with a wrong password on purpose and it worked again. I'm using archlinux. I don't know what information I could provide to help debug this. I previously had setup ykfde without 2fa (because it wasn't available yet), so maybe I made a mistake when I switched. To switch, I first changed the config and then typed sudo ykfde -s <2fa> and then used ykfde-cpio and then regenerated the initcpio files.

Cheers

[eworm-de]

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?

[guiniol]

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.

[guiniol]

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.

[guiniol]

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

[eworm-de]

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

[guiniol]

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?

[eworm-de]

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.

[guiniol]

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.

[eworm-de]

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.

[eworm-de]

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.

[guiniol]

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

[eworm-de]

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

yk_challenge_response() failed: Resource temporarily unavailable

[guiniol]

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

[eworm-de]

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