Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFE: cryptsetup: support automatic LUKS header FIDO2 param discovery even if multiple FIDO2 tokens are enrolled #19208

Closed
daenney opened this issue Apr 5, 2021 · 18 comments · Fixed by #25367
Labels
cryptsetup fido2 RFE 🎁 Request for Enhancement, i.e. a feature request

Comments

@daenney
Copy link

daenney commented Apr 5, 2021

systemd version the issue has been seen with

v248

Used distribution

Arch Linux

Linux kernel version used (uname -a)

Linux unicorn 5.11.11-arch1-1 #1 SMP PREEMPT Tue, 30 Mar 2021 14:10:17 +0000 x86_64 GNU/Linux

CPU architecture issue was seen on

amd64

Expected behaviour you didn't see

I'm able to unlock my root volume with one of my fido2 keys

Unexpected behaviour you saw

I was unable to unlock, with either fido2-device=auto or fido2-device=/dev/hidraw1 passed as rd.luks.options=

Steps to reproduce the problem

Enrolled 2 keys using systemd-cryptenroll --fido2-device=auto /dev/nvme0n1p4 each time (with only one key plugged in each time)

Additional program output to the terminal or log subsystem illustrating the issue
When booting with fido2-device=auto:

Apr 05 01:35:12 archlinux kernel: Command line: rd.luks.options=fido2-device=auto rd.luks.uuid=c399df9f-f0db-4b5d-8743-27ebfe445161 rd.luks.name=c399df9f-f0db-4b5d-8743-27ebfe445161=unicorn root=/dev/mapper/unicorn debug
...
Apr 05 01:35:12 archlinux systemd-cryptsetup[209]: Multiple FIDO2 tokens enrolled, cannot automatically determine token.
Apr 05 01:35:12 archlinux systemd-cryptsetup[209]: Automatic FIDO2 metadata discovery was not possible because missing or not unique, falling back to traditional unlocking.

When booting with fido2-device=/dev/hidraw1

Apr 05 02:40:07 archlinux kernel: Command line: rd.luks.options=fido2-device=/dev/hidraw1 rd.luks.uuid=c399df9f-f0db-4b5d-8743-27ebfe445161 rd.luks.name=c399df9f-f0db-4b5d-8743-27ebfe445161=unicorn root=/dev/mapper/unicorn debug
...
Apr 05 02:40:07 archlinux systemd-cryptsetup[203]: Multiple FIDO2 tokens enrolled, cannot automatically determine token.
Apr 05 02:40:07 archlinux systemd-cryptsetup[203]: Automatic FIDO2 metadata discovery was not possible because missing or not unique, falling back to traditional unlocking.
# systemd-cryptenroll --fido2-device=list
PATH         MANUFACTURER PRODUCT              
/dev/hidraw1 Yubico       YubiKey OTP+FIDO+CCID

# systemd-cryptenroll --fido2-device=list
PATH         MANUFACTURER PRODUCT   
/dev/hidraw0 SoloKeys     Solo 2.3.0
@poettering
Copy link
Member

Yeah, you cannot use automatic token discovery if you enroll multiple keys right now. it's a bit of a problem inherent to FIDO2: if you enroll multiple tokens we don't really know which token we are talking to, hence they only way to make this work would be to first assume it's token one, then try to unlock things, and if that doesn't work, assume it's token two, and try that and so on. But that sucks hard since in the worst case the token you actually plugged in will ask you n times for authentication (i.e. it will ask you n times for toucing it), since we have to check n binary keys against it if you enrolled n tokens...

Hence, so far I opted to just not support things automatically in that case. You could manually encode all the data we normally discover from the LUKS2 header in /etc/crypttab if you want to work around things, but that won't make you happy either, since you can only list a single fido2 device there, hence if you pick the wrong one, things won't work either.

Maybe I misread something in the FIDO2 specs, but unless I am mistaken FIDO2 tokens generally do not allow identification (i.e. have no serial number or so) that was accessible before authentication, and that's the issue here. PKCS#11 works differently on that btw. A PKCS#11 security token provides us with all kinds of identifying info before we start authenticating with it, hence for PKCS#11 it's a lot easier: there we can just check what token is plugged in and then find the right enrollment for it in the LUKS header. But in FIDO2 besides vendor info all devices look the same to us, so besides actually trying to authenticate with them there's no way to figure out which one belongs to which enrollment.

I'll turn this into an RFE thing: we probably should implement a logic of iterating through all FIDO2 enrollments for each plugged in token after all. It will suck interaction-wise, but besides having to touch the device multiple times in the worst case there's no technical reason we couldn't make this work.

@poettering poettering changed the title cryptsetup: Can't unlock when multiple fido2 tokens enrolled RFE: cryptsetup: support automatic LUKS header FIDO2 param discovery even if multiple FIDO2 tokens are enrolled Apr 6, 2021
@poettering poettering added cryptsetup fido2 RFE 🎁 Request for Enhancement, i.e. a feature request labels Apr 6, 2021
@gdonval
Copy link

gdonval commented Oct 5, 2021

unless I am mistaken FIDO2 tokens generally do not allow identification (i.e. have no serial number or so) that was accessible before authentication

So I tried something on a SoloKey (fw version 4.1.2) using fido-tools. I noticed that contrary to fido2-cred, fido2-assert does not explicitly say they require a PIN or any sort of user interaction. So I tried things based on the tools' respective man pages.

First create your credential and certificate:

echo credential challenge | openssl sha256 -binary | base64 > cred_param
echo relying party >> cred_param
echo user name >> cred_param
dd if=/dev/urandom bs=1 count=32 | base64 >> cred_param
fido2-cred -M -i cred_param /dev/hidraw1 | fido2-cred -V -o cred

echo assertion challenge | openssl sha256 -binary | base64 > assert_param
echo relying party >> assert_param
head -1 cred >> assert_param
tail -n +2 cred > pubkey

Then do an assert. Do note the -t up=false, this is what does the magic here:

fido2-assert -G -t up=false -i assert_param /dev/hidraw1 | fido2-assert -V pubkey es256

With the aforementioned Solokey, user interaction is not enforced.

So potentially, systemd could "just" assert its way through different keys and only activate the ones that are passing verification with the correct options (PIN and/or user interaction) to unlock the correct secret.

I will try tomorrow with a Yubikey. But I am quite optimistic: fido's specs make clear that user presence/verification can be ignored. Though if implementers were insane and followed w3c's very special take on this, there might be problems ahead.

Otherwise, there might be a way to use discoverable credentials to do just this reliably (though UP might be forced there too, no idea yet).

As a final thought, using pinToken, there might be a possibility to circumvent the problem by submitting multiple assertions with a single interaction/verification (at least that is how I understand it).

@gdonval
Copy link

gdonval commented Oct 6, 2021

I can confirm this is working on a Yubikey on firmware 5.2.6!


So in terms for FIDO, the process could look as follows..

(Note that I don't know the specifics of what cryptenroll does at the moment. I am not intending to replace what is being done or change what to use as a challenge or relying party or user name, etc. I am just putting values that sort of make sense in order to go through the process to get a POC that can be adapted to the current process afterwards.)

Extra data to be stored in the luks header

## Create a new credential on device

dd if=/dev/urandom bs=1 count=32 | base64 > cred_param           # Random challenge
echo systemd-cryptenroll:luks2 >> cred_param                     # Relying party name
echo root_system >> cred_param                                   # User name (went for mount point name)
echo luks-X...  | openssl sha256 -binary | base64 >> cred_param  # User ID (binary blob, went for something based on LUKS UUID)

# The following asks for the PIN (fine as this is during `systemd-cryptenroll` is doing its magic)
fido2-cred -M -i cred_param /dev/hidraw1 eddsa | fido2-cred -V -o cred eddsa


## DATA TO STORE IN LUKS HEADERS ##
head -1 cred > cred_id
tail -n +2 cred > pubkey
####################################

At boot time

dd if=/dev/urandom bs=1 count=32 | base64 > assert_param         # Random challenge
echo systemd-cryptenroll:luks2 >> assert_param                   # Must be the same as in cred_param
cat cred_id >> assert_param                                      # Must be the cred_id provided before                                                     

for dev in /dev/hidraw*; do
    fido2-assert -G -t up=false -i assert_param $dev | fido2-assert -V pubkey eddsa && echo "$dev: PASSED [and now doing fancy things with user consent]" || echo "$dev: FAILED [ignoring this one]"
done

On my computer (2 FIDO keys, 1 TPM), I get this (ignoring actual error messages sent to stderr):

/dev/hidraw0: FAILED [ignoring this one]
/dev/hidraw1: PASSED [and now doing fancy things with user consent]
/dev/hidraw2: FAILED [ignoring this one]
/dev/hidraw3: FAILED [ignoring this one]
/dev/hidraw4: FAILED [ignoring this one]
/dev/hidraw5: FAILED [ignoring this one]

Nothing in "At boot time" requires any sort of user interaction.


Fun part

Turns out everything (authentication and hmac-secret) can be combined in a rather nice way...

dd if=/dev/urandom bs=1 count=32 | base64 > cred_param           # Random challenge
echo systemd-cryptenroll:luks2 >> cred_param                     # Relying party name
echo root_system >> cred_param                                   # User name (went for mount point name)
echo luks-X...  | openssl sha256 -binary | base64 >> cred_param  # User ID

# the two `-h` is doing the magic (activates `hmac-secret`) 
fido2-cred -M -h -i cred_param /dev/hidraw1 eddsa | fido2-cred -V -h -o cred eddsa

head -1 cred > cred_id
tail -n +2 cred > pubkey
dd if=/dev/urandom bs=1 count=32 | base64 > assert_param         # Random challenge
echo systemd-cryptenroll:luks2 >> assert_param                   # Must be the same as in cred_param
cat cred_id >> assert_param                                      # Must be the cred_id provided before   

# Verify the device has a secret related to current LUKS partition
fido2-assert -G -t up=false -i assert_param /dev/hidraw1 | fido2-assert -V pubkey eddsa && echo "VALID DEVICE" || echo "INVALID DEVICE"

# Now let's use `hmac-secret`
echo "HMAC SALT" | openssl sha256 -binary | base64 >> assert_param

fido2-assert -G -h -t up=false -i assert_param /dev/hidraw1
fido2-assert -G -h -t up=true -i assert_param /dev/hidraw1
fido2-assert -G -h -t up=true -t pin=true -i assert_param /dev/hidraw1

You should see that -t up=false fails if asking for hmac-secret (-h) but succeeding otherwise.

@poettering
Copy link
Member

@gdonval: if you want to turn off up/uv/clientPin you can just use the respective options to systemd-cryptenroll:

$ ./build/systemd-cryptenroll --help | grep -A1 fido2
     --fido2-device=PATH
                       Enroll a FIDO2-HMAC security token
     --fido2-with-client-pin=BOOL
                       Whether to require entering a PIN to unlock the volume
     --fido2-with-user-presence=BOOL
                       Whether to require user presence to unlock the volume
     --fido2-with-user-verification=BOOL
                       Whether to require user verification to unlock the volume

@poettering
Copy link
Member

(but i think turning off up/uv/clientPin is of course chickening out: up checks as kind of a second factor are a major point why fido2 is great)

@poettering
Copy link
Member

ah, but i think i understand what you are trying to say: you want two auth requests: the first one without touch, the second one with touch? the first one identifies, and the second one then does the actual authentication? interesting idea. but i am pretty sure you cannot turn off up/uv/clientPin on all devices, so this would be a device-specific fix only.

I think we can instead just use the same randomized data for all enrolled tokens, and thus sidestep the whole issue: if we reuse the randomized data for all enrolled tokens, we can the search for the result among the enrolled keys and be happy.

@gdonval
Copy link

gdonval commented Oct 6, 2021

the first one without touch, the second one with touch? the first one identifies, and the second one then does the actual authentication

Exactly (sorry for the lengthy piece).

but i am pretty sure you cannot turn off up/uv/clientPin on all devices

At least Yubico and Solo do it and that's in the specs (specs warn it might be unsupported but not invalid). If unsupported, systemd-cryptenroll would determine it from the start (and could write relevant state).

if we reuse the randomized data for all enrolled tokens

It is possible to use the allowList argument in authenticatorGetAssertion to provide multiple credentials IDs at once ( then use authenticatorGetNextAssertion). Only a single user interaction is required.

So the only requirement is for the hmac-secure salt to be the always the same on all systems. I am not sure about the security ramifications of that.

@Be-ing
Copy link
Contributor

Be-ing commented Oct 29, 2021

Maybe I misread something in the FIDO2 specs, but unless I am mistaken FIDO2 tokens generally do not allow identification (i.e. have no serial number or so) that was accessible before authentication, and that's the issue here.

There must be some way to handle this considering I just logged into GitHub without identifying which FIDO2 token I was using and I have multiple FIDO tokens registered with my GitHub account.

@Be-ing
Copy link
Contributor

Be-ing commented Oct 29, 2021

I am currently locked out of my main laptop due to this issue. I setup 4 Yubikeys using systemd-cryptenroll --fido2-device=auto and removed my LUKS password intending to only use the FIDO keys. But now

/usr/lib/systemd/systemd-cryptsetup attach root /dev/nvme0n1p3 - fido2-device=auto

fails with:

Multiple FIDO2 tokens enrolled, cannot automatically determine token.

then asks for my password, but there is no password. 😟

The crypttab documentation describes a fido2-cid option but I can't find any documentation how to find the client ID associated with a key. 😟

@Be-ing
Copy link
Contributor

Be-ing commented Oct 30, 2021

I managed to recover my data by booting a Fedora 35 beta live USB drive, building and installing the systemd main branch on it, then using /usr/lib/systemd/systemd-cryptsetup. Evidently the behavior of cryptsetup with multiple FIDO2 keys has changed in the main branch since release 249. With 249, which is used in Fedora 35 beta, I got the Multiple FIDO2 tokens enrolled, cannot automatically determine token. error. With the main branch, I was able to use my FIDO2 keys in the order I registered them with cryptenroll. For example, if I plugged in the third key I registered, I had to tap the key three times.

I attempted to use cryptenroll to register a password, but I got caught in a circular trap because cryptenroll asked for the password which did not exist anymore instead of letting me use the FIDO2 tokens. cryptsetup had the same problem.

Requiring an unreleased build of systemd to boot my system would be really ugly. So, I ended up backing up my data from the Fedora 35 live USB drive with the systemd build from Git, then wiping my whole SSD, and reinstalling Fedora 34 with a password to encrypt the btrfs volume (with / and /home on btrfs subvolumes).

This worst case scenario took me an entire day to deal with because the current systemd release doesn't really support using multiple FIDO2 keys. Considering I'd be using the same FIDO2 key almost all the time, with the other keys as backups, I could put up with the behavior of the current main Git branch. However, I can't wait for that to be released and packaged to use my laptop again. So, all that to say that I don't consider LUKS encryption with FIDO2 keys to be practically usable yet. I do not trust myself to never lose a single hardware key so I'm not going to risk making my laptop unusable because of that.

@Be-ing
Copy link
Contributor

Be-ing commented Oct 30, 2021

I don't know how systemd's use of FIDO2 with LUKS differs from WebAuthn, but in WebAuthn the allowCredentials JSON object is an array that lists multiple public keys, any of which may be used by the authenticator.

poettering added a commit to poettering/systemd that referenced this issue Nov 2, 2021
Let's document this for now. We should be able to lift these limitations
sooner or later, at which point we can drop this documentation again.

These two limitations are a pitfall that people should be aware of,
before going FIDO2-only.

See: systemd#20230 systemd#19208
bluca pushed a commit that referenced this issue Nov 2, 2021
Let's document this for now. We should be able to lift these limitations
sooner or later, at which point we can drop this documentation again.

These two limitations are a pitfall that people should be aware of,
before going FIDO2-only.

See: #20230 #19208
codepeon pushed a commit to codepeon/systemd that referenced this issue Nov 10, 2021
Let's document this for now. We should be able to lift these limitations
sooner or later, at which point we can drop this documentation again.

These two limitations are a pitfall that people should be aware of,
before going FIDO2-only.

See: systemd#20230 systemd#19208
(cherry picked from commit 0bada3f)
@coelner
Copy link

coelner commented Dec 29, 2021

Maybe I'm missing something, but systemd relies on the hidraw device to omit the underlying layer like BLE, USB, NFC, ... therefore no unique identification attribute. However since this: https://patchwork.kernel.org/project/linux-input/patch/20191204034109.21944-1-marcel@holtmann.org/ it should be possible to get an unique attribute.
Especially the rd.luks.options=fido2-device= directive gets without a guarantied major number a little bit tricky.

A specific /dev/hidrawX configuration could lead to a potential dead-lock, because it can't be guarantied that the major number stays the same?

cat /sys/class/hidraw/hidraw0/device/uevent | grep HID
HID_ID=0003:00000483:0000A2CA
HID_NAME=SoloKeys Solo 4.1.5
HID_PHYS=usb-0000:00:14.0-1/input0
HID_UNIQ=123456A7890B

If we can assume that the HID_UNIQ is actually set and unique could we use it somehow? [The solokey v1 works, the DIY OpenSK currently not] The problem here is that devices with multi interfaces (e.g. USB + NFC) will presumable have different UNIQs (USB iSerial, BLE MAC, NFC ???)

IMHO the parallel try and error to find the right token seems the easiest UX. After probing all tokens without any usable response the other key-slots should be tried.

@Be-ing
Copy link
Contributor

Be-ing commented Dec 29, 2021

IMHO the parallel try and error to find the right token seems the easiest UX.

WebAuthn services don't require trial and error.

@gdonval
Copy link

gdonval commented Jan 14, 2022

Parameter name Data type Required? Definition
allowList Sequence of PublicKeyCredentialDescriptors Optional A sequence of PublicKeyCredentialDescriptor structures, each denoting a credential, as specified in [WebAuthN]. The authenticator is requested to only generate an assertion using one of the denoted credentials.

https://fidoalliance.org/specs/fido-v2.0-rd-20170927/fido-client-to-authenticator-protocol-v2.0-rd-20170927.html

AFAIK, if no credential matches, the keys won't lit up. If multiple keys have a match, they'll just send back the correct assertion data. Systemd then "just" have to unlock with whichever device is answering first and then cancel the request for the rest of them.

@shalzz
Copy link

shalzz commented Mar 6, 2022

I have a similar albeit a slightly differently scenario where I have a TPM, a single FIDO2 token and a passphrase enrolled as keys to a luks partition.
It seems both the TPM and the single FIDO2 token are both considered as "tokens" and when either one fails it directly fails over to the passphrase, completely skipping over the second token (In my case TPM is always tried first and then fails over to passphrase)
Ideally enrolled keys should be tried in priority of TPM > FIDO > passphrase.
Especially considering that I couldn't get passphrase to "exit" in-order to allow systemd-cryptsetup to try other enrolled keys

PeterCxy pushed a commit to PeterCxy/systemd that referenced this issue Oct 29, 2022
Do not attempt to decrypt using a key slot unless its corresponding
credential is found on an available FIDO2 token. Avoids multiple touches
/ confirmations when unlocking a LUKS2 device with multiple FIDO2 tokens
enrolled.

Partially fixes systemd#19208 (when the libcryptsetup plugin is in use).
PeterCxy added a commit to PeterCxy/systemd that referenced this issue Nov 4, 2022
After commit cefb7c7, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 tokens.

Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.

Fixes systemd#19208.
PeterCxy pushed a commit to PeterCxy/systemd that referenced this issue Nov 11, 2022
Do not attempt to decrypt using a key slot unless its corresponding
credential is found on an available FIDO2 token. Avoids multiple touches
/ confirmations when unlocking a LUKS2 device with multiple FIDO2 tokens
enrolled.

Partially fixes systemd#19208 (when the libcryptsetup plugin is in use).
PeterCxy pushed a commit to PeterCxy/systemd that referenced this issue Nov 11, 2022
Do not attempt to decrypt using a key slot unless its corresponding
credential is found on an available FIDO2 token. Avoids multiple touches
/ confirmations when unlocking a LUKS2 device with multiple FIDO2 tokens
enrolled.

Partially fixes systemd#19208 (when the libcryptsetup plugin is in use).
PeterCxy pushed a commit to PeterCxy/systemd that referenced this issue Nov 11, 2022
Do not attempt to decrypt using a key slot unless its corresponding
credential is found on an available FIDO2 token. Avoids multiple touches
/ confirmations when unlocking a LUKS2 device with multiple FIDO2 tokens
enrolled.

Partially fixes systemd#19208 (when the libcryptsetup plugin is in use).
PeterCxy pushed a commit to PeterCxy/systemd that referenced this issue Nov 11, 2022
Do not attempt to decrypt using a key slot unless its corresponding
credential is found on an available FIDO2 token. Avoids multiple touches
/ confirmations when unlocking a LUKS2 device with multiple FIDO2 tokens
enrolled.

Partially fixes systemd#19208 (when the libcryptsetup plugin is in use).
@bluca bluca closed this as completed in 32f57b0 Nov 12, 2022
@daenney
Copy link
Author

daenney commented Nov 12, 2022

Since #25268 mentions "partially fixes" this should be re-opened this until it's all confirmed to work as expected.

@PeterCxy
Copy link
Contributor

@bluca This issue should be re-opened as #25268 does not fix it for the case where systemd is shipped without the cryptsetup plugins -- although I am personally not aware of any modern distribution that ships systemd-crypt{enroll,setup} but not cryptsetup and its plugins.

@PeterCxy
Copy link
Contributor

I think the next step should be a discussion on whether fixing it for the legacy code path without cryptsetup plugins is in the scope of this issue (and whether that legacy code path should be something actively maintained or just a fallback).

@bluca bluca reopened this Nov 12, 2022
PeterCxy added a commit to PeterCxy/systemd that referenced this issue Nov 12, 2022
After commit cefb7c7, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 tokens.

Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.

Fixes systemd#19208.
PeterCxy added a commit to PeterCxy/systemd that referenced this issue Nov 13, 2022
After systemd#25268, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 tokens.

Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.

Fixes systemd#19208.
PeterCxy added a commit to PeterCxy/systemd that referenced this issue Nov 13, 2022
After systemd#25268, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 key slots.

Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.

Fixes systemd#19208.
PeterCxy added a commit to PeterCxy/systemd that referenced this issue Nov 13, 2022
After systemd#25268, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 key slots.

Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.

Fixes systemd#19208.
PeterCxy added a commit to PeterCxy/systemd that referenced this issue Nov 13, 2022
After systemd#25268, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 key slots.

Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.

Fixes systemd#19208.
PeterCxy added a commit to PeterCxy/systemd that referenced this issue Nov 13, 2022
After systemd#25268, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 key slots.

Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.

Fixes systemd#19208.
PeterCxy added a commit to PeterCxy/systemd that referenced this issue Nov 13, 2022
After systemd#25268, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 key slots.

Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.

Fixes systemd#19208.
PeterCxy added a commit to PeterCxy/systemd that referenced this issue Nov 14, 2022
After systemd#25268, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 key slots.

Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.

Fixes systemd#19208.
PeterCxy added a commit to PeterCxy/systemd that referenced this issue Nov 15, 2022
After systemd#25268, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 key slots.

Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.

Fixes systemd#19208.
PeterCxy added a commit to PeterCxy/systemd that referenced this issue Nov 24, 2022
After systemd#25268, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 key slots.

Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.

Fixes systemd#19208.
PeterCxy added a commit to PeterCxy/systemd that referenced this issue Dec 10, 2022
After systemd#25268, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 key slots.

Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.

Fixes systemd#19208.
bluca pushed a commit that referenced this issue Dec 12, 2022
After #25268, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 key slots.

Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.

Fixes #19208.
eworm-de pushed a commit to eworm-de/systemd that referenced this issue Feb 4, 2023
After systemd#25268, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 key slots.

Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.

Fixes systemd#19208.

(cherry picked from commit e6319a1)
d-hatayama pushed a commit to d-hatayama/systemd that referenced this issue Feb 15, 2023
Do not attempt to decrypt using a key slot unless its corresponding
credential is found on an available FIDO2 token. Avoids multiple touches
/ confirmations when unlocking a LUKS2 device with multiple FIDO2 tokens
enrolled.

Partially fixes systemd#19208 (when the libcryptsetup plugin is in use).
d-hatayama pushed a commit to d-hatayama/systemd that referenced this issue Feb 15, 2023
After systemd#25268, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 key slots.

Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.

Fixes systemd#19208.
valentindavid pushed a commit to valentindavid/systemd that referenced this issue Aug 8, 2023
After systemd#25268, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 key slots.

Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.

Fixes systemd#19208.

(cherry picked from commit e6319a1)
(cherry picked from commit 892cb01)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cryptsetup fido2 RFE 🎁 Request for Enhancement, i.e. a feature request
8 participants