Requiring a Yubikey to boot a VM. FIDO Alliance strategy against Unauthorized Access

Does anyone know how to lock a Virtual Machine OS with a Yubikey? Can FIDO locks be placed on specific instruction sets and cpu functions? Can a challenge-response be made for Intel VT PID that would require a Yubikey? For starting KVM or VirtualBox? For any OSs installed in virtualizers?

To be more specific, how about requiring a Yubikey to boot a Silverblue or Debian guest on KVM on a Fedora host? Would there be special considerations about passing a host USB with a Yubikey to a VM guest I/O?

If anyone is interested in more abstract, computational theory discussion, I was wondering if someone could explain how malicious code gets injected into a system when there are passwords blocking access on many levels including sudo and root? Sure, once a system is turned on, LUKS decrypted with a password, and then connected to a nework, access is possible remotely in so far as access permissions are not denied by PAM, SELinux policy, or in limiting access with units defined in systemd or sandboxing applications, etc. But if permissions are somehow hijacked to execute code arbitrarily, then remote attacks could be prevented by requiring a physical token like a yubi or nitro key. No remote attacker could control whether a system operator inserts or removes a physical key. And the token key accompanies the user that has tied it to the specific system. Authentic identity can not be alienated or transferred to an unauthorized party, especially when there are biometric signatures. The cryptographic tokens are too complex to extract from the physical device or forge. So if something happens at a terminal or workstation, it is only because the keyholder decided for the process to occur. That’s the kind of security framework I am thinking about how to implement. In the abstract, at least to me this seems like a reasonable method for rigid designation of authorization.

There is an article that discusses some of the possibilities of locking system processes with yubikeys. I have some questions about the meaning and significance of a few terms. https://fedoramagazine.org/how-to-use-a-yubikey-with-fedora-linux/

/etc/pam.d/login - Configuring this option means that no one other than the keybearer can run commands on a terminal (“console”). This is for cli only non-graphical use, correct?

/etc/pam.d/sudo - Updates can’t take place without the key inserted, any application requiring sudo can’t take place, commands can’t be run if someone leaves a terminal open–but does that mean remote executions of code are also prevented?

/etc/pam.d/gdm-password - Does “Gnome authentication” mean a key has to be inserted for GUI to be accessed?

The article states that “Convenience covers anything from using the hardware token to unlock your LUKS encrypted disk to logging in to your Fedora Workstation with the press of a button.” Both of these options are not yet easily available on Fedora, although they probably are on Windows and Mac. I think Fedora Magazine is working on unpacking that how-to. https://pagure.io/fedora-magazine-newsroom/issue/178
There are some hints here:

Webauth to sites depends upon the whether the site has developed the FIDO option. There is no way to store a password on a token key and have it entered in to a password field ion a site, is there? That function would be independent of sites providing support.

There is definitely opportunity for expanding the “Works With” developments of Yubikey, Nitro, and other token/dongle keys.

If someone wanted to lock Gnome GUI with Yubikey, authselect for /etc/pam.d could be used at /etc/dconf/db/distro.d/* according to documentation. So I’m thinking that means that when the computer logs out at sleep or asks for a challenge-response at Gnome start up, the Yubikey could be required. Can anyone unpack exactly how to do that step by step?

The grub script method that a Qubes OS user created (Yubikey + LUKS on Qubes 4.1 - General - Qubes OS Forum) looks like it would work. I started to test it in a Fedora VM, The script has to be modified to match Fedora. Not sure how to do that. Is this script added to /etc/default/grub with an editor?

Next, I am going to try removing grub and add sd-boot (bootctl install) with systemd-cryptenroll.

like this:
sudo mkdir /efi . . . etc
sudo mkdir /efi/$(cat /etc/machine-id) . . . etc
sudo bootctl . . . etc
systemd-cryptenroll --fido2-device=auto /dev/vda3