1824811 - Cannot use YK4 FIPS token with security.webauthn.ctap2 enabled

Status: VERIFIED FIXED

(Core :: DOM: Web Authentication, defect, P1)

Description

[dominic.evans]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/112.0

Steps to reproduce:

Start Firefox 111.0.1 and Firefox 112 on MacOS, both with clean profiles

1. navigate to https://demo.yubico.com/webauthn
2. register a new temporary account with some generated credentials
3. attempt to add a YubiKey 4 key (a FIDO/U2F device that does not support FIDO2)

Actual results:

On Firefox 111.x and earlier this works fine and the YubiKey 4 Series can be registered and used. Attempting to use Firefox 112 this doesn't succeed. Tested again after restarting Firefox with both security.webauth.u2f: true or security.webauth.u2f: false (just to rule that out as a cause) in about:config — neither succeeds.

The same behaviour is seen on various other websites where the YubKey has been registered as a MFA device.

Expected results:

The YubiKey 4 Series should continue to be able to function as an authenticator in Firefox 112 onwards.

Comment 1

[dominic.evans]

I did notice "Users on macOS and Linux can now use FIDO2 / WebAuthn authenticators over USB. Some advanced features, such as fully passwordless logins, require a PIN to be set on the authenticator." in the release notes, is Firefox aborting because the FIDO device doesn't support a PIN challenge?

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Web Authentication' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[John Schanck [:jschanck]]

Can you confirm that it works in 112 with security.webauthn.ctap2: false?

Comment 4

[dominic.evans]

(In reply to John Schanck [:jschanck] from comment #3)

Can you confirm that it works in 112 with security.webauthn.ctap2: false?

Yep! Confirmed after disabling FIDO CTAP2 support in 112.0b7 I can authenticate again — thanks, will use this workaround

Comment 5

[Daniel Veditz [:dveditz]]

That's very odd. If I disable the FIDO2 interface on a Yubikey 5 key, in theory it should behave like your Yubikey 4. But we're able to use those as FIDO U2F keys without any problem with the new CTAP2 code enabled.

We are going to disable CTAP2 again before releasing 112 while we figure out the scope of keys similarly affected. We'll try again in a later release.

Comment 6

[Daniel Veditz [:dveditz]]

The same behaviour is seen on various other websites where the YubKey has been registered as a MFA device.

If it's not too invasive a question, could you list some of them? Presumably on those other sites you're having trouble using the key, while on the yubico demo site you got hung up on registering the key. Those are different operations and if both are broken it might be for different reasons. Another test you could do on the Yubico demo site is to register the key in Fx111 (or with ctap2 turned off) and then turn on ctap2 support and check whether logging in didn't work.

I noticed the demo site is requesting extra info about the hardware. Are they just gathering stats, or do they use that info to register keys differently? Is your Yubikey 4 broken (with ctap2 support enabled) on the demo site https://webauthn.io which doesn't gather this info?

Comment 7

[dominic.evans]

Yes on those other sites it was authenticating with pre-registered keys that wasn't working with CTAP2 enabled, disabling CTAP2 fixed those as well

Interestingly my Yubikey 4 doesn't work at all when attempting to register it on https://webauthn.io — I tested Firefox 112 (with and without ctap2), Firefox 111, Safari 16.3 and Chrome 111 — all prompted for the key, but never progressed my activations.

Comment 8

[dominic.evans]

OK fixed that, my key had locked the session (preventing further U2F registrations) because I'd done too many in short succession whilst testing I guess. Unlocked by doing a verify pin challenge (ykman fido access verify-pin)

Another test you could do on the Yubico demo site is to register the key in Fx111 (or with ctap2 turned off) and then turn on ctap2 support and check whether logging in didn't work.

Correct. On both Yubico demo site and on webauthn.io, I can only register the key with ctap2 turned off, and on both sites if I toggle ctap2 back on before attempting to authenticate it fails — if I toggle ctap2 off again then I can authenticate successfully

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox112 (beta). We have limited time to fix this, the soft freeze is in 8 days. However, the bug still isn't assigned.

:freddy, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit auto_nag documentation.

Comment 11

[John Schanck [:jschanck]]

We have disabled ctap2 for 112 release.

Comment 12

[John Schanck [:jschanck]]

One of our engineers tested with a Yubico 4 series on an M1 Mac running Monterey 12.6 and they were not able to reproduce this in Firefox 112 or 113. So we're still not sure what the issue is.

Dominic, could you also provide me with:

• the type of Mac that you're using,
• the operating system version,
• the "device type" and "firmware version" lines from ykman info.

It would also be helpful if you could test with Firefox 113 (Nightly) with security.webauthn.ctap2 set to true.

Comment 13

[will.smart]

I know I'm a bit late to the party here, but I'll just throw my test results in:
I was able to test on:
a YK4 device with 4.3.4 firmware
a YK5 device with FIDO2 disabled (CTAP1 only) with 5.4.3 firmware
a YK5 device with FIDO/U2F disabled (CTAP2 only) with 5.4.3 firmware

all on a intel macbook pro (2017) running Firefox 112.0 with security.webauthn.ctap2 set to true.

everything worked as expected with
https://demo.yubico.com/webauthn
and webauthn.io

Comment 14

[John Schanck [:jschanck]]

I now have access to a YK4 with firmware 4.3.1, and I've not been able to reproduce the problem on Debian Linux or macOS Ventura.

(In reply to dominic.evans from comment #8)

[...] Unlocked by doing a verify pin challenge (ykman fido access verify-pin)

If I run that command with a YK4 connected I get ERROR: This YubiKey does not support a FIDO pin. Is it a YK4 FIPS?

I'm going to close this for now. We can re-open it if we get more information from dominic.

Comment 15

[dominic.evans]

Sorry for the slow reply John, I was on vacation this last week and hadn't been checking e-mails.

(In reply to John Schanck [:jschanck] from comment #12)

One of our engineers tested with a Yubico 4 series on an M1 Mac running Monterey 12.6 and they were not able to reproduce this in Firefox 112 or 113. So we're still not sure what the issue is.

Dominic, could you also provide me with:

• the type of Mac that you're using,
• the operating system version,
• the "device type" and "firmware version" lines from ykman info.

It would also be helpful if you could test with Firefox 113 (Nightly) with security.webauthn.ctap2 set to true.

Mac is a 16-inch MacBookPro18,1 (2021) with Apple M1 Pro
OS is Ventura 13.3
Yes it's a YK4 FIPS

% ykman info
Device type: YubiKey FIPS
Serial number: <REDACTED>
Firmware version: 4.4.5
Enabled USB interfaces: OTP, FIDO

Applications
OTP             Enabled
FIDO U2F        Enabled
FIDO2           Not available
OATH            Disabled
PIV             Disabled
OpenPGP         Disabled
YubiHSM Auth    Not available

Comment 16

[dominic.evans]

Can reproduce on latest Firefox Nightly build 114.0a1 (2023-04-11), can neither register the key with security.webauthn.ctap2=true, nor authenticate (if the key has previously been registered). As soon as I toggle security.webauthn.ctap2 to false, both are successful

Screen recording:
https://user-images.githubusercontent.com/8060970/231287968-fcead1a3-8a8b-4243-9340-29ec103e9170.mov

(obviously this doesn't show me tapping the gold contacts on the Yubikey, but be assured that I was doing so equally well in both attempts)

Comment 17

[John Schanck [:jschanck]]

OK, I think we've established that this is only an issue with the YK4 FIPS. Unfortunately there's no way for me to obtain a YK4 FIPS for testing---Yubico doesn't have them anymore.

I have a guess as to why signing is not working. However, I'm still confused about registration.

In your earlier tests, did you unlock registration by running

ykman fido unlock -P <Admin PIN>

as described in Section 2.5.2 of the YK4 FIPS Manual?

Comment 18

[dominic.evans]

Yes as noted earlier in the thread, I unlocked registration — though the command is ykman fido access verify-pin -P <admin pin> in current versions of yubikey manager, they moved it around a little. You're told the redirect if you attempt to use the old command:

% ykman fido unlock
ERROR: This command has moved! Use ykman fido access verify-pin

Comment 19

[John Schanck [:jschanck]]

Dominic, could you try Nightly again? We made a few changes that might affect you. There's a chance that we've fixed the registration issue. If we have not, I'd also like to confirm that the workaround (disabling security.webauthn.ctap2) still works.

Comment 20

[dominic.evans]

(In reply to John Schanck [:jschanck] from comment #19)

Dominic, could you try Nightly again? We made a few changes that might affect you. There's a chance that we've fixed the registration issue. If we have not, I'd also like to confirm that the workaround (disabling security.webauthn.ctap2) still works.

Sure, tested on 114.0a1 (2023-04-20) with a fresh default profile — unfortunately registration with security.webauthn.ctap2 enabled still didn't work in this build. Toggling it to false and retrying and registration worked first time still

Comment 21

[dominic.evans]

FYI unfortunately my YK4 FIPS snapped in half today so I no longer have it available to test ctap2 on further nightlies

The good news is that my replacement YubiKey 5C NFC FIPS works well with ctap2 enabled

Comment 22

[John Schanck [:jschanck]]

Glad to hear that you have working setup now, Dominic. I'm also happy to report that we have a fix.

It turns out that the YK4 FIPS reports CAPABILITY_CBOR in its flags. This was a reserved flag in CTAP1, and the initialization routine in authenticator-rs assumed (incorrectly) that presence of CAPABILITY_CBOR implies support for CTAP2.

Many thanks to Will Smart from Yubico for running diagnostics on a YK4 FIPS token.

Upstream PR: https://github.com/mozilla/authenticator-rs/pull/265
Upstream commit: https://github.com/mozilla/authenticator-rs/commit/2da9e9912e9c3b2d5ce5af5d9f07002c39ce528e

A patch for Firefox 115 is included with Bug 1833240 (D178112). That patch vendors the latest version of authenticator-rs and includes several changes that we do not want to backport to Firefox 114. I'll attach a separate patch to this bug for beta uplift.

Comment 23

[John Schanck [:jschanck]]

Attachment: Bug 1824811 - fallback to CTAP1 when CTAP2 getInfo fails. r=keeler

Comment 24

[dominic.evans]

Awesome! Great job and great pairing. Thanks again for all your hard work on Firefox!

Comment 25

[will.smart]

Happy to report that the latest nightly (115.0a1 2023-05-16) works as expected with the YK4 FIPS series (Firmware 4.4.5).

Comment 26

[John Schanck [:jschanck]]

Comment on attachment 9333782 [details]
Bug 1824811 - fallback to CTAP1 when CTAP2 getInfo fails. r=keeler

Beta/Release Uplift Approval Request

• User impact if declined: Users with the YubiKey 4 Series FIPS security key will not be able to perform WebAuthn operations unless they set security.webauthn.ctap2=false. It's possible that other token models are affected.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Regression testing as part of QA-1843.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The patch is a workaround for a quirk of the YubiKey 4 Series FIPS. Most security keys will not see a change in our library's behavior.
• String changes made/needed:
• Is Android affected?: No

Comment 27

[Donal Meehan [:dmeehan]]

:jschanck thanks for the beta uplift request.
I see the patch was reviewed in Phabricator, but it was never landed. I see comment 22 mentioned the fix that landed in central.
Wanted to confirm this is expected?

Comment 28

[John Schanck [:jschanck]]

Yes, that's because the patch applies to a library (authenticator-rs) that we vendor into M-C. We incorporated a new version of that library into 115 in Bug 1833240, but we are only backporting the one patch to 114.

Comment 29

[Donal Meehan [:dmeehan]]

Comment on attachment 9333782 [details]
Bug 1824811 - fallback to CTAP1 when CTAP2 getInfo fails. r=keeler

Approved for 114.0b6.

Comment 30

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-beta/rev/da11b16198cd

Comment 31

[Monica Chiorean]

Hello [e-mail],

We were not able to reproduce the issue before the fix in 112.0(20230406114409) nor on latest 114.0b7 build using below devices:

• Yubico 4(FW 4.3.5),
• YubiKey NEO Firmware 3.3.3
• YubiKey Bio FIDO Edition Firmware 5.5.6.
  Can you please confirm that on your side there is also No regression on latest Beta build (https://archive.mozilla.org/pub/firefox/candidates/114.0b7-candidates/), before we close this issue? Thank you very much.

Comment 32

[John Schanck [:jschanck]]

Will sent me an email confirming that 114.0b6 works for him.

Comment 33

[Monica Chiorean]

Mark as verified based on comment#32.
Also attaching info from Will:
"I can confirm that this is fixed starting with 114.0b6. (and confirmed on 114.0b7 as well)

Verified with a Yubikey 4 FIPS 4.4.5.
After the source of the bug was nailed down, I spoke to some folks over here, and we're fairly confident that this issue is only present on the 4.4.x firmwares. I expect everything before 4.4.0 and after 5.0.0 would be unaffected. Thanks "