1898594 - U2F v1.0 tokens no longer usable in Firefox

Status: RESOLVED WONTFIX

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

Description

[V. Korn]

Attachment: authenticator::*:5 log

Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Steps to reproduce:
I have relatively old U2F token attached to several services like Github. I tried to authenticate in them using this key and found that key dont seems to work. Albeit Firefox gave me notification to push button on token, token itself didnt blink and button push give no reaction.
Same result archived on Webauthn.io or Webauthn.bin.coffee test sites - registration with key just dont work

Actual results:

Nothing happens with key, doesnt blink, doesnt react

Expected results:

Successful login with key.

Additional info:
Firefox Nightly 128 on Ubuntu 23.10, installed from ftp.mozilla.org, not snap.

Model of key is Hypersecu HyperFIDO (vendor=0x096e, product=0x0880). Works fine in Chromium, so device isnt faulty.

I tested older version of Firefox and found that key worked up until Firefox 109, to be more specific last good version is Nightly from 2022-12-06-16 and first bad is 2022-12-07-09.
This exactly when https://bugzilla.mozilla.org/show_bug.cgi?id=1530373 landed CTAP2 support.

As suggested in other bug i used MOZ_LOG=authenticator::*:5 to get some additional info, log attached.

Comment 1

[John Schanck [:jschanck]]

I have a guess as to what's wrong here. I've opened https://github.com/mozilla/authenticator-rs/issues/336 upstream.

Comment 2

[Michael F]

Copying what I wrote on the authenticator-rs issue:

GetVersion is in the FIDO U2F v1.0 spec, so every U2F authenticator should support it.

However, I suspect this is actually caused by U2F's request framing: U2F v1.0 is "based on ISO 7816-4:2005 extended APDU format", but describes it in a completely incorrect way that wouldn't be usable with an existing ISO 7816-4 implementation or transport layer (contrary the stated goals).

U2F v1.1 and v1.2 fixed most of the ways it's incompatible with ISO 7816-4:2005, but in doing so made it incompatible with U2F v1.0. There is no mention of backwards compatibility with U2F v1.0 in the spec, so a U2F v1.1 or v1.2 authenticator could just not handle it (eg: VASCO SecureClick).

I wrote some docs about the problems with U2F's framing a while ago when I rewrote it.

Model of key is Hypersecu HyperFIDO (vendor=0x096e, product=0x0880). Works fine in Chromium, so device isnt faulty.

According to the FIDO MDS, "HyperFIDO U2F Security Key" only claims compatibility with U2F v1.0. Firefox only works with U2F v1.1 or later.

While Chromium never sends a GetVersion command, its U2F framing implementation does the exact same thing as authenticator-rs (since 2018).

U2F v1.0 has no Le (expected response length) field, so a fully-compliant U2F v1.0 implementation should be broken on every other command sent in U2F v1.1 or v1.2 format.

GetVersion is the only command with Nc = 0 (so Lc should be included in U2F v1.0, but omitted in U2F v1.1/v1.2). A U2F v1.0 authenticator should then read the Le as Nc = 0, but then fail on every other command with Nc ≠ 0 and Ne = 65536 due to the extra two Le bytes. The fact it works even works in Chromium on other commands is surprising, and suggests HyperFIDO follows neither U2F v1.0 or v1.1, or ISO 7816-4:2005 correctly.

GetVersion is a useful signal for testing U2F v1.1+ authenticators without requiring the user to press a button or causing any visible or audible activity. Encoding the request in a way that'd work with HyperFIDO would break compatibility with every other U2F v1.1 and v1.2 authenticator.

I'd recommend replacing it with a newer model - they'll also support user verification, which is needed for self-contained multi-factor authentication, and stronger encryption algorithms.

Most authenticators produced today support at least CTAP 2.0, and those with backwards compatibility target U2F v1.2. The "interface version" in the U2FHID_INIT command is always set to "2", even in U2F v1.0, so there's no way to tell it apart from a v1.1 or v1.2 authenticator without sending commands and seeing what it rejects.