Confusion with CTAP USB data

[Fujimi Bentley]

Hello Fido community!

I'm implementing a USB device for CTAP 2(.1) and I'm confused with what I'm seeing.
The process I'm following:
1. Go to webauthn.io
2. Start USB MCU
3. Register a random user and get the USB interaction:

Group 1:
WebAuth: ff ff ff ff 86 00 08 08 33 54 6c 94 40 ca 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
USB out: ff ff ff ff 86 00 11 08 33 54 6c 94 40 ca 25 61 61 00 00 02 02 00 00 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Group 2:
WebAuth: 61 61 00 00 90 00 01 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
USB out: 61 61 00 00 90 00 33 00 a2 01 83 66 55 32 46 5f 56 32 68 46 49 44 4f 5f 32 5f 30 6c 46 49 44 4f 5f 32 5f 31 5f 50 52 45 03 50 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50 00 00 00 00 00 00
Group 3:
WebAuth: ff ff ff ff 86 00 08 7d de a2 e8 e5 77 c6 2d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
USB out: ff ff ff ff 86 00 11 7d de a2 e8 e5 77 c6 2d 61 61 00 01 02 02 00 00 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Group 4:
WebAuth: 61 61 00 01 90 00 01 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
USB out: 61 61 00 01 90 00 33 00 a2 01 83 66 55 32 46 5f 56 32 68 46 49 44 4f 5f 32 5f 30 6c 46 49 44 4f 5f 32 5f 31 5f 50 52 45 03 50 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50 00 00 00 00 00 00
Group 5:
WebAuth: 61 61 00 01 90 00 9e 6b 77 65 62 61 75 74 68 6e 2e 69 6f 03 a3 62 69 64 46 64 47 56 7a 64 41 64 6e 61 6d 65 64 74 65 73 74 6b 64 69 73 70 6c 61 79 4e 61 6d 65 64 74 65 73 74 04 82 a2 63 61 6c
USB out: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Group 6:
WebAuth: 61 61 00 01 00 6d 65 6b 77 65 62 61 75 74 68 6e 2e 69 6f 03 a3 62 69 64 46 64 47 56 7a 64 41 64 6e 61 6d 65 64 74 65 73 74 6b 64 69 73 70 6c 61 79 4e 61 6d 65 64 74 65 73 74 04 82 a2 63 61 6c
USB out: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Group 7:
WebAuth: 61 61 00 01 01 67 26 64 74 79 70 65 6a 70 75 62 6c 69 63 2d 6b 65 79 a2 63 61 6c 67 39 01 00 64 74 79 70 65 6a 70 75 62 6c 69 63 2d 6b 65 79 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
USB out: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Group 1: is CTAPHID_INIT using WINK and CBOR seems to work as expected as WebAuthn then requests Group 2: CBOR->Get info.

Group 2:
The CBOR data string has a length of 50 bytes (100 hex):
a20183665532465f5632684649444f5f325f306c4649444f5f325f315f50524503504142434445464748494a4b4c4d4e4f50
Response data: 61 61 00 00 90 00 33 00 CBOR Data
step through incase I did something silly here: CID(61610000), CMD 90 (CBOR 0x10 | init packet top bit 0x80), Length: (0033 or 51) CTAP result(00 success)
CBOR is just the requried fields, with U2F_V2, FIDO_2_0 and FIDO_2_1_PRE and CBOR parses successfully on cbor.me

Note that right now the USB only responds to CTAPHID_INIT and CBOR get info, otherwise it just returns 0's.

My understanding of Group 5 is:
CID (61610001) CMD(90-CBOR 0x10|0x80) Len(009e-158) CTAP command byte(6b)
But 6B seems to be a CBOR map and Group 6 and 7 are continuation packets. The CBOR response from Group 5 is (length is 158 bytes so it's not missing anything):
6b776562617574686e2e696f03a3626964466447567a6441646e616d6564746573746b646973706c61794e616d6564746573740482a263616c6d656b776562617574686e2e696f03a3626964466447567a6441646e616d6564746573746b646973706c61794e616d6564746573740482a263616c672664747970656a7075626c69632d6b6579a263616c6739010064747970656a7075626c69632d6b6579

This does not work properly with cbor.me...

Question 1: Why does the WebAuthn page request CTAPHID_INIT a second time but work with Group 3. Is the response in Group 2 incorrect?
Question 2: Why is an identical handler for Group 4 accepted when Group 2 caused a second init?
Question 3: What is the CBOR request in group 5? CMD code 0x6b does not seem to conform to CTAP 2.1, is this a U2F_V2 format? If so I please get some details on this, I am only working with:https://fidoalliance.org/specs/fido-v2.1-rd-20201208/fido-client-to-authenticator-protocol-v2.1-rd-20201208.html

Thanks! I will try changing the CBOR convention to NOT use map at the start so it's like the data from Group 5, if this works I will be very confused since I thought CBOR requried map first..

Fujimi

[Fujimi Bentley]

Is nobody replying to this because the post is too long?

I am stumped about this and tried a variety of changes:

1. modified length incase I missunderstoond length parameter
2. Simplified the CBOR data further so it is only FIDO2

3. copied an AAGUID from an existing open source project incase the 16 bytes are not "encoded"

Any indication or thoughts would be greatly appreciated because I am not getting anywhere... My next stop is to get an open source virtual token working and capture it's output but I do not understand why I need to go that far, this should be simple....

Regards!

Fujimi

[Fujimi Bentley]

To answer my own questions for anyone trying to work this out in the future

Q1: It just does multiple init requests, a "working" FIDO token got up to CID 4 in a regsiter -> authenticate flow

Q2: It didn't trigger an error, it just does what it wants

Q3: Not sure yet, seems to be a response to the CBOR data... The byte that doesnt make sense is 9e and the CBOR data does not conform to the CBOR standard as described...

[Fujimi Bentley]

To potentially assist someone else, this is a hex dump of a USB2 FIDO2 token that I got from amazon with webauthn.io.

This was captured using wireshark USB cap and mucked around with a json parser to clean it up abit.

Separated the direction, CID and command byte. Data after is subject to the command but I'm not willing to write up a parser.

The keep alive parameter (bb) was trimmed back since it just duplicates every 100ms until I pressed the button.

Noteworthy points:

1. CID went up to 6 and did not start at 0.

2. Did not get the odd CBOR block of data that is present in Group 5's CBOR data (sorry 9e is length, I noted that before, confused myself). The issue is the CBOR data does not seem to parse properly.

The data provided in line 13~15 in the text file worked with CBOR.me with a valid CTAP command byte of 01, command byte in Group 5 is 6b...? Will post back if I work out what is going on but it seems like if I send a "normal" CBOR data string, this issue might not happen....

Regards!

Fujimi