Qubes FIDO2/CTAP2 proxy for Passkey authenticaiton with hardware devices?

[lax]

I am currently using a password manager solution for Passkeys in Qubes OS:

• Air-gapped KeepassXC vault qube
• Client qube with Firefox browser and KeepassXC extension
• This extension connects via qrexec to vault for Passkey registration/authentication

This works fine so far. I thought, it would be a good idea to also connect a FIDO2 hardware token (Nitrokey) to store Passkeys securely.

Qubes Global Config → USB Devices has a section “U2F devices”. But this proxy is only for legacy U2F/CTAP1 protocol and does not work for Passkeys, correct?

Hence kindly asking about recommended solution in Qubes:

• Attach USB-connected Nitrokey from USB qube to client qube demanding Passkeys? Does this work well?
• Do devs have a roadmap in the pipeline to extend CTAP1 proxy to CTAP2 for passkeys?

[KitsuneNoBaka]

Does the CTAP proxy work with Whonix-WS and Tor Browser?

I followed the instructions here (CTAP proxy — Qubes OS Documentation) to set it up, but it didn’t work. I suspected Whonix and Tor Browser might be the cause. Does anyone actually use the CTAP proxy with Whonix and Tor Browser? Are there any additional settings required? If not, I assume I made a mistake somewhere.

Not recognizing Yubikey for setting up challenge response with KeepassXC

New to Yubikey. I have been using KeepassXC for ages and am now trying to incorporate a Yubikey for challenge response. The Yubikey shows up in sys-usb after following this method: https://doc.qubes-os.org/en/latest/user/security-in-qubes/ctap-proxy.html This led me to believe, that the vms I had set to use ctap would recognize the Yubikey. But in my dedicated KeepassXC vm, when I follow the procedure to make a new datafile and successfully reach the Challenge-Response box, I get a ‘No hard…

[NuageQubes81]

For passkeys I would not treat the U2F setting as equivalent to full CTAP2/WebAuthn support. U2F is the older/simple case; passkeys often need CTAP2 features, especially resident/discoverable credentials, so a proxy that only covers U2F can fail in confusing ways.

The safest practical test is with a disposable or low-value browser qube first: attach the Nitrokey only to that client qube, try both registration and login, then detach it again. If that works, it is usable, but it is a different trust trade-off from a qrexec proxy because the client qube talks to the token directly. I would avoid attaching the token to the vault qube unless the vault really needs it.

[lax]

Yeah, I just saw Not recognizing Yubikey for setting up challenge response with KeepassXC as well.

So it actually seems possible to use CTAP2 via proxy (is it?). I think, this still is a legitimate question: Qubes Global Config explicitely names that section “U2F devices” and “U2F proxy”. U2F is a legacy standard and not compatible to Passkeys, which require FIDO2 with WebAuthn + CTAP2:

WebAuthn and CTAP provide a complete replacement for U2F, which has been renamed “CTAP1” in the latest version of the FIDO2 standard.[37] The WebAuthn protocol is backward-compatible (via the AppID extension) with U2F-only security keys[38] but the U2F protocol is not compatible with a WebAuthn-only authenticator

See also CTAP:

The CTAP specification refers to two protocol versions, the CTAP1/U2F protocol and the CTAP2 protocol.

[lax]

@NuageQubes81

For passkeys I would not treat the U2F setting as equivalent to full CTAP2/WebAuthn support. U2F is the older/simple case; passkeys often need CTAP2 features, especially resident/discoverable credentials, so a proxy that only covers U2F can fail in confusing ways.

Yes, exactly. That’s why I asked, if Qubes CTAP proxy also support CTAP2 for Passkeys.

@NuageQubes81

The safest practical test is with a disposable or low-value browser qube first: attach the Nitrokey only to that client qube, try both registration and login, then detach it again.

Unfortunately I don’t have a hardware device to test things out at the moment.

[quietbadger27]

I would keep the two cases separate: the Qubes UI label may still say U2F, but passkeys usually mean CTAP2 resident/discoverable credentials, so I would not assume the existing proxy covers that path. If nobody with a Nitrokey answers, the lowest-risk check is exactly a disposable/low-value browser qube with the token attached only for the registration/login test, then detached again. That at least tells you whether direct USB attach works before deciding if the proxy/roadmap question matters for your setup.