can the persistent storage on tails-os be configured to use yubikey to unlock?

I use tails-os with persistent storage to keep sensitive data secure but relatively easy to access on an airgapped laptop. I might be pissing up a rope here, but I wonder if it might be possible to configure the persistent storage with a yubikey for unlocking the encrypted partition? The problems I see is that although the necessary yk/luks pkgs can be installed after each boot, they are kept on the persistent storage and so not available until after the persistent storage device has been opened (catch22?). Also, there would need to be some cfg files in /etc that would need to be modified (crypttab and ykluks.cfg maybe), and stay modified in order for the persistent storage to know to look for a yubikey after boot but before taking user to tails desktop. I guess I'm wondering if perhaps the live disk could be modified in a way to statically install the necessary pkgs and modify the necessary cfg files without requiring the persistent storage to be available? --- UPDATE: Ok so what I have been able to manage so far is to add my yubikey's fido2 to a luks slot of my usb loaded with tails-os with Persistent storage configured, running this command with the usb plugged into a usb port on daily driver: $ sudo systemd-cryptenroll /dev/sdc2 --fido2-device=auto Verified the fido2 added to a luks slot for the Persistent partition:

$sudo systemd-cryptenroll /dev/sdc2
SLOT TYPE    
   0 password
   2 fido2

Then I was able to remove the password that was setup for slot 0 of the Persistent storage: $ sudo cryptsetup -q -v luksKillSlot /dev/sdc2 0 Verified the password slot was removed:

$sudo systemd-cryptenroll /dev/sdc2
SLOT TYPE 
   2 fido2

Booted my laptop with the tails-os usb, and did not open the Persistent storage at the tails setup screen, but started tails. Then I ran the command to open the Persistent storage using the fido2 slot entry: $ sudo cryptsetup luksOpen --token-only /dev/sdb2 Persis Verified the partition was opened by checking Persis was listed in /dev/mapper: $ ls /dev/mapper Created a mount point in /media/amnesia/Persis to have the partition show up in the regular user's (amnesia) favorite locations menu in the file manager: $ sudo mkdir -p /media/amnesia/Persis ; sudo chown -R /media/amnesia/Persis ; sudo mount /dev/mapper/Persis /media/amnesia/Persis And voila, although a little clunkier than if things could be set up more statically on the live disk, the Persistence partition was successfully opened and mounted by my yubikey's fido2. However, I did run into a glitch I cannot yet explain. I run with three yubikeys all configured identically, and so differing in device ID only. Except the command to open the partition with the --token-only worked only with the specific yubikey that was plugged in when the sudo systemd-cryptenroll /dev/sdc2 --fido2-device=auto command was run. When trying to use one of my other two yubkieys, the luksOpen command just fails, informing that the fido2 pin code entered was incorrect (or something similar). However, when I set up a challengeresponse using any one of my yubikeys in a keepassxc db, for example, any of my yubikeys afterward works fine to access and modify the keepassxc db. I thought the challengeresponse feature on the yubikey is the fido2 feature, no? If so, the only thing I can think is that the sudo systemd-cryptenroll /dev/sdc2 --fido2-device=auto command to add the YK's fido2 to a key slot on the luks partition must also use the yubikey's device ID as part of the --token-only authentication process?