Fido2luks does not work

[szszszsz]

Fido2luks fails with setting up LUKS device. This works with Nitrokey FIDO2.

Dev returns: Device returned error: CborError: 0x14: Missing non-optional parameter.)
If I have not made mistake during the early retest, this was the kty field, as reported by serde.

Logs with full traffic attached, as well as the used Makefile.
Sim version: v1.2.2-alpha.20221130-111-ga1d9dd0 (current main), with updated dependencies to the latest (cargo update; see attached Cargo lock file).

PS I expect the same problem occurs, while running example of the responsible for the ctap communication underlying ctap_hmac crate. Might be easier for the debugging.

• sim-logs-fido2luks.txt
• sim-logs-fido2luks-calls.txt
• Makefile.txt (can't add Makefile directly)
• Cargo.lock.zip

cc @robin-nitrokey

[robin-nitrokey]

This is caused by a bug in a Deserialize implementation in ctap-types: trussed-dev/ctap-types#7.

[robin-nitrokey]

Though the algorithm field is really missing:

https://github.com/shimunn/ctap/blob/bf862f6a4bbc007263cbe679db33c8dd3c2ffc79/src/cbor.rs#L589-L590

I’m not sure whether this is valid.

[robin-nitrokey]

Okay, it’s optional:

   COSE_Key = {
       1 => tstr / int,          ; kty
       ? 2 => bstr,              ; kid
       ? 3 => tstr / int,        ; alg
       ? 4 => [+ (tstr / int) ], ; key_ops
       ? 5 => bstr,              ; Base IV
       * label => values
   }

https://www.rfc-editor.org/rfc/rfc8152#section-7

alg: This parameter is used to restrict the algorithm that is used
with the key. If this parameter is present in the key structure,
the application MUST verify that this algorithm matches the
algorithm for which the key is being used.

https://www.rfc-editor.org/rfc/rfc8152#section-7.1

[intr-cx]

Hi, sorry to bump this, but I'm curious about the state of this issue. Since the fido2luks project seems unmaintained/dead (although the software still works fine with the NK FIDO2), I'm wondering if this can be resolved from this side of the fence.

[robin-nitrokey]

@intr-cx The CTAP2 issues described above are fixed in the firmware, although we might revert some of the fixes in the future because the specification requires a strict implementation that rejects invalid data. Additionally, there is a bug in the USB descriptor parser used by fido2luks. We don’t want to work around that bug in the firmware. I’ve submitted patches to fix the parser. They might work for you, though I have only tested the device selection, not the entire LUKS setup:

• Fix usage check ArdaXi/ctap#5
• Fix usage check shimunn/ctap#8