Copying what I wrote on the `authenticator-rs` issue: [`GetVersion` is in the FIDO U2F v1.0 spec](https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-u2f-raw-message-formats-ps-20141009.html#getversion-request-and-response---u2f_version), 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"](https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-u2f-raw-message-formats-ps-20141009.html#u2f-message-framing), 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](https://source.chromium.org/chromium/chromium/src/+/1d08c0929ca6be7e3bef9d801602fe08748c9676)). [I wrote some docs about the problems with U2F's framing a while ago when I rewrote it](https://github.com/mozilla/authenticator-rs/blob/9eab362ec16f4143a892e06788c3d7c5b7b0a04f/src/u2ftypes.rs#L185). > 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](https://source.chromium.org/chromium/chromium/src/+/main:components/apdu/apdu_command.cc) does the exact same thing as `authenticator-rs` ([since 2018](https://source.chromium.org/chromium/chromium/src/+/1d08c0929ca6be7e3bef9d801602fe08748c9676)). 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 `Le` 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 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.
Bug 1898594 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Copying what I wrote on the `authenticator-rs` issue: [`GetVersion` is in the FIDO U2F v1.0 spec](https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-u2f-raw-message-formats-ps-20141009.html#getversion-request-and-response---u2f_version), 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"](https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-u2f-raw-message-formats-ps-20141009.html#u2f-message-framing), 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](https://source.chromium.org/chromium/chromium/src/+/1d08c0929ca6be7e3bef9d801602fe08748c9676)). [I wrote some docs about the problems with U2F's framing a while ago when I rewrote it](https://github.com/mozilla/authenticator-rs/blob/9eab362ec16f4143a892e06788c3d7c5b7b0a04f/src/u2ftypes.rs#L185). > 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](https://source.chromium.org/chromium/chromium/src/+/main:components/apdu/apdu_command.cc) does the exact same thing as `authenticator-rs` ([since 2018](https://source.chromium.org/chromium/chromium/src/+/1d08c0929ca6be7e3bef9d801602fe08748c9676)). 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 `Le` 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.
Copying what I wrote on the `authenticator-rs` issue: [`GetVersion` is in the FIDO U2F v1.0 spec](https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-u2f-raw-message-formats-ps-20141009.html#getversion-request-and-response---u2f_version), 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"](https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-u2f-raw-message-formats-ps-20141009.html#u2f-message-framing), 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](https://source.chromium.org/chromium/chromium/src/+/1d08c0929ca6be7e3bef9d801602fe08748c9676)). [I wrote some docs about the problems with U2F's framing a while ago when I rewrote it](https://github.com/mozilla/authenticator-rs/blob/9eab362ec16f4143a892e06788c3d7c5b7b0a04f/src/u2ftypes.rs#L185). > 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](https://source.chromium.org/chromium/chromium/src/+/main:components/apdu/apdu_command.cc) does the exact same thing as `authenticator-rs` ([since 2018](https://source.chromium.org/chromium/chromium/src/+/1d08c0929ca6be7e3bef9d801602fe08748c9676)). 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.