FIDO2 security key (Yubikey 5 NFC) and Webauthn

J

JanBeh

I recently try to use a Yubikey 5 NFC (via USB) with FreeBSD. I installed the packages libfido2-1.15.0 and py311-yubikey-manager-5.2.0, which respectively provide the fido2-token and ykman tools that seem to work just fine.

However, when I try to go to https://webauthn.io/ and try using my security key using Firefox or Chromium, then it usually works only once. For the second action (e.g. attempting to login after having registered, or logging in for a second time shortly after I logged in for the first time), I get the following error messages:

With Firefox, the website responds with:
The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission.
Click to expand...

With Chromium, I sporadically get:
Use your security key with webauthn.io: Insert your security key and touch it.
Click to expand...
Even though my key is inserted (and also if I re-insert it), nothing happens. If I press "Cancel", which is the only option, the website responds with:
The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations-client.
Click to expand...

I tried with and without pcscd running. It's not really reproducible when it happens and when not. Sometimes it also fails for the first request.

The Firefox console log also doesn't seem to give any helpful information, and I didn't find anything in /var/log either. Can anyone else reproduce the problem? I don't even know where to file a bug report because I'm unsure which component is the one that is buggy.
 
I have tried to narrow down the problem. First of all, I updated FreeBSD and Firefox/Chromium. I'm now using FreeBSD 14.1-RELEASE-p3 and packages firefox-129.0.1,2 and chromium-127.0.6533.119.

Further testing revealed that Firefox and Chromium seem to behave slightly differently. While Chromium sporadically fails as explained above (sometimes also works a couple of tries in a row), Firefox usually fails after the second operation.

For some strange reason (and I tested that several times), switching to the text console using CTRL+ALT+F1 and switching back to X using CTRL+ALT+F9 fixes the problem temporarily, i.e. using Firefox it works one more time until it fails again.

If I use multiple Firefox windows with different profiles, only the first Firefox window that I use will succeed, the second attempt (even if done with a different profile) will fail again until I switch to text mode and back to X.

I have no idea what's going on and why switching to the text console and back to X serves as a workaround. Does anyone have an idea what may be the cause? Maybe it has to do to granting access to the security token based on which user is currently logged in, and switching to the console refreshes that information somehow? What are the mechanisms behind this?

Again, it would also be helpful if anyone else could test this and tell me whether they experience the same odd behavior or whether this just happens on my machine with my hardware.
 
I have investigated further and while I didn't solve my original problem, I learned a few more things about how different software accesses the security key and also a potential security issue.

Some programs seem to access the security key through /dev/uhid*, for example fido2-token, ssh-keygen, and also Firefox and Chromium. Access to this device file is given to any user that is part of the u2f group, independently of whether those users are currently logged on locally. While this is not good from a security p.o.v., at least no users are members of that u2f group by default.

Other programs, namely ykman, seem to access the token through the PC/SC-daemon via the local socket /var/run/pcscd.comm. This socket is accessible to all users (rw-rw-rw-). In theory, the PC/SC-daemon uses polkit to restrict token access to locally logged in users (if I understand this right). Indeed, package pcsc-lite-2.2.2,2 installs a file /usr/local/share/polkit-1/actions/org.debian.pcsc-lite.policy with the following contents:

Code: 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd">
<policyconfig>
  <vendor>The PCSC-lite Project</vendor>
  <vendor_url>https://pcsclite.apdu.fr/</vendor_url>
<!--  <icon_name>smart-card</icon_name> -->

  <action id="org.debian.pcsc-lite.access_pcsc">
    <description>Access to the PC/SC daemon</description>
    <message>Authentication is required to access the PC/SC daemon</message>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

  <action id="org.debian.pcsc-lite.access_card">
    <description>Access to the smart card</description>
    <message>Authentication is required to access the smart card</message>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

</policyconfig>

However, if I do ssh unprivileged-user@localhost I can execute ykman and, for example, generate TOTP tokens using the YubiKey 5 NFC. Or do worse stuff, such as erasing all keys or even effectively bricking the device.

I attempted to replace the two lines <allow_active>yes</allow_active> with <allow_active>no</allow_active>, respectively, and restart the PC/SC-daemon. Access to the device via ykman was still possible for unprivileged users.

This seems to be a security issue. Can anyone reproduce this?

I also tested how my new findings relate to my original problem using WebAuthn and Firefox. If I block access to /dev/uhid0, then Firefox acts like the security key wasn't plugged in. However, Firefox (but not Chromium) still behaves oddly. I can only initiate a WebAuthn registration or authentication once, such that Firefox asks me: "Touch your security key to continue with webauthn.io." Any further, repeated attempt will immediately result in an error (displayed on webauthn.io as "The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission."). As soon as I switch to the text console using CTRL+ALT+F1 and switch back to X using CTRL+ALT+F9, Firefox will ask once more to touch my security key.

As this behavior also occurs without having an actual hardware key, I would kindly appreciate if anyone else could reproduce this odd behavior (and possibly explain why switching to the text console has an effect on how Firefox behaves).
 
JanBeh said:
This seems to be a security issue.
Click to expand...
Sorry, slightly OT, but you may have bigger security concerns to deal with:

it.slashdot.org

YubiKeys Are Vulnerable To Cloning Attacks Thanks To Newly Discovered Side Channel - Slashdot

The YubiKey 5, the most widely used hardware token for two-factor authentication based on the FIDO standard, contains a cryptographic flaw that makes the finger-size device vulnerable to cloning when an attacker gains brief physical access to it, researchers said Tuesday. ArsTechnica: The...
it.slashdot.org
 
richardtoohey2 said:
it.slashdot.org

YubiKeys Are Vulnerable To Cloning Attacks Thanks To Newly Discovered Side Channel - Slashdot

The YubiKey 5, the most widely used hardware token for two-factor authentication based on the FIDO standard, contains a cryptographic flaw that makes the finger-size device vulnerable to cloning when an attacker gains brief physical access to it, researchers said Tuesday. ArsTechnica: The...
it.slashdot.org
Click to expand...
Thanks for sharing. In my case, I think I should be safe as ykman info reports firmware version 5.7.1.

I think a non-privileged remotely logged-in user (or, for example, a process running as nobody) being able to use (or delete or brick, but not clone) a token is not easily comparable to an attack where you need physical access, including opening the plastic casing (as noted here). Even though the latter allows cloning (which is worse), the former could be done much more easily, e.g. by a colleague happening to have an account on the same machine as you are working on.

The issue with pcscd (if this is really an issue and not some dumb mistake from my side) may also apply to different hardware, i.e. not just the YubiKey 5 NFC.
 
Geez I forgot how expensive these things were and now they're like "everything is trash, get a new one."
 
richardtoohey2 said:
Sorry, slightly OT, but you may have bigger security concerns to deal with:

it.slashdot.org

YubiKeys Are Vulnerable To Cloning Attacks Thanks To Newly Discovered Side Channel - Slashdot

The YubiKey 5, the most widely used hardware token for two-factor authentication based on the FIDO standard, contains a cryptographic flaw that makes the finger-size device vulnerable to cloning when an attacker gains brief physical access to it, researchers said Tuesday. ArsTechnica: The...
it.slashdot.org
Click to expand...
we should pour a little calm on this particular issue - the attack requires:
  • physical access to the key
  • the key must be physically destroyed to get at the internal hardware
  • put into some very expensive non-portable machinery
  • the user(!) must then log in via the key (or you have working credentials for the target) during the attack
  • you need to rebuild the key (or return a cloned one with the same serial# etc) without the user noticing the damage/swap
To perform this without the user noticing is difficult. For sure there will be a vanishing small number of people where this attack is feasible, but in most cases https://xkcd.com/538 is a simpler approach.
 
dch said:
  • the user(!) must then log in via the key (or you have working credentials for the target) during the attack
Click to expand...
While discussing the side-channel attack is certainly interesting (I wonder if there are scenarios where the relying party wants or needs to rely on the user not being able to clone the key, also see attestation), and while I don't mind talking further about that "off-topic topic" in this thread, I'd like to politely repeat that I'd still be happy about someone willing to check whether they can reproduce the odd Firefox behavior on their machine (no hardware key needed). 😁🙏
 
In firefox I have no issue to using fido2 device (nitrokey 3a nfc), I just tested with webauthn.io by registering and login in multiple time in a row (with a delay of 6s the time to enter my pin).
Also I am using wayland, but I am not sure that it is relevant.
The only thing that I have is when I use the fido2 variant that does not store a resident key, I have to reset my usb key if I want to do it multiple time in a row (but I am pretty sure that it is more an issue with my key than firefox).
 
monwarez said:
In firefox I have no issue to using fido2 device (nitrokey 3a nfc), I just tested with webauthn.io by registering and login in multiple time in a row (with a delay of 6s the time to enter my pin).
Click to expand...
That is very interesting! I wonder what's the difference in our setup.

I tried on a different machine, a Lenovo ThinkPad X1 Carbon, using the same YubiKey 5 NFC, and I could not reproduce the issue. Firefox works fine and lets me login multiple times. I might have slightly different packages installed on that machine, but I tried to install all relevant security-key related packages and also upgraded to FreeBSD-14.1 and upgraded all packages. Still, Firefox on that laptop computer works fine while on my desktop computer it doesn't.

However, apparently I'm not the only person with this issue. Some other person on the mailinglist could reproduce it: Dave Cottlehuber just wrote on the freebsd-questions mailinglist:
I can reproduce it, and have seen this in the past a couple of years ago, […]
Click to expand...
(see E-mail in archive)

So there seems to be other people with this issue, but it doesn't happen in all scenarios.

monwarez said:
Also I am using wayland, but I am not sure that it is relevant.
Click to expand...
Probably not, because my laptop doesn't use wayland either and it also doesn't exhibit the issue.

P.S.: Many thanks for the feedback and testing!
 
JanBeh said:
However, if I do ssh unprivileged-user@localhostI can execute ykman and, for example, generate TOTP tokens using the YubiKey 5 NFC. Or do worse stuff, such as erasing all keys or even effectively bricking the device.

[…]

This seems to be a security issue. Can anyone reproduce this?
Click to expand...
JanBeh said:
I cross-posted these issues on the FreeBSD mailing lists:
Click to expand...
FYI, there is a pull-request to fix this now.
 
You must log in or register to reply here.
Back
Top