Assertion appears to be produced with invalid signature when hmac-secret is requested

[aseigler]

Came across this while trying to debug why Solo won't work with Windows Hello (#116). Using the tools from libfido2, it appears Solo is producing an assertion with invalid signature, only when hmac-secret is requested (perhaps sig is being created over wrong data?). This is on Windows 10 with 1903. I debugged it for a good while but can't figure out what is going wrong, also tried building a test into the test suite for Solo but was not able to get it to work, so escalating here.

Repro steps:

1. Download and build libfido2

2. Plug Solo into a USB port

3. Open an elevated command prompt (run as administrator), optionally set FIDO_DEBUG environment variable to 1 ("set FIDO_DEBUG=1")

4. From examples folder, run manifest.exe to get a listing of available authenticators:

D:\source\repos\libfido2\build\64\examples\Debug>manifest.exe \\?\hid#vid_0483&pid_a2ca#6&11f6700a&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}: vendor=0x0483, product=0xa2ca (SoloKeys Solo 2.4.0)

5. From examples folder, use cred.exe to create a credential on device output from manifest.exe. Use -P if required, and press button on Solo when execution stops.

D:\source\repos\libfido2\build\64\examples\Debug>cred.exe -t ecdsa -k solo.pubkey -i solo.cred_id -P 112233 -h "\\?\hid#vid_0483&pid_a2ca#6&11f6700a&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}"

6. Create appropriate 32 byte hmac_salt file. I simply used a file with the bytes F1D0 repeated 16 times.

7. From examples folder, use assert.exe to request an assertion from the previously created cred_id. Supply the pubkey from the -k output from cred.exe and the cred_id from the -i output, and the hmac_salt file to signify you are requesting an hmac_secret. Press button on Solo when execution stops.

D:\source\repos\libfido2\build\64\examples\Debug>assert.exe -t ecdsa -a solo.cred_id -h hmac_secret -s hmac_salt -P 112233 solo.pubkey "\\?\hid#vid_0483&pid_a2ca#6&11f6700a&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}"

Results:

rx: payload at 000000985F2FED00, len 256 00 a3 01 a2 62 69 64 58 46 3c a4 95 d4 7e 79 0a fc 35 e4 f3 e3 03 d6 a0 ee 09 29 4e c8 27 76 4e d7 ea 53 f6 93 42 16 7a 90 fa 33 49 96 0d e5 88 0e 8c 68 74 34 17 0f 64 76 60 5b 8f e4 ae b9 a2 86 32 c7 99 5c f3 ba 83 1d 97 63 10 01 00 00 64 74 79 70 65 6a 70 75 62 6c 69 63 2d 6b 65 79 02 58 54 49 96 0d e5 88 0e 8c 68 74 34 17 0f 64 76 60 5b 8f e4 ae b9 a2 86 32 c7 99 5c f3 ba 83 1d 97 63 85 00 00 01 11 a1 6b 68 6d 61 63 2d 73 65 63 72 65 74 58 20 49 40 60 e8 3e fc 47 96 a0 8e 80 e6 95 57 e5 50 40 96 0e 53 fc 5d 5f a9 68 89 20 e8 11 ca 65 41 03 58 47 30 45 02 21 00 ad f2 9a a8 a8 34 28 94 5a 5d 34 ea e2 b8 15 96 e2 85 04 11 2a b4 5b 49 4b dd d6 14 65 01 03 d9 02 20 51 97 7b 06 35 3e c6 27 70 4b 77 93 05 6b 72 8b e5 7d 5a d0 b8 3e ce 15 48 8a 66 20 d0 fc 72 f0 adjust_assert_count: cbor_type adjust_assert_count: cbor_type adjust_assert_count: cbor_type decode_assert_authdata: buf=000001CDAD1754E0, len=84 decode_hmac_secret: buf=000001CDAD175505, len=47 decode_assert_authdata: buf=000001CDAD175780, len=84 decode_hmac_secret: buf=000001CDAD1757A5, len=47 verify_sig_es256: ECDSA_verify fido_assert_verify: FIDO_ERR_INVALID_SIG (0xfffffffa)

The payload above is an authenticatorGetAssertion_Response. If you run the same command (below) without the -h or -s (no hmac-secret requested), it works fine, which is why I think perhaps the signature in the response is being created over the wrong data.

D:\source\repos\libfido2\build\64\examples\Debug>assert.exe -t ecdsa -a solo.cred_id -P 112233 solo.pubkey "\\?\hid#vid_0483&pid_a2ca#6&11f6700a&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}"

Also, using YubiKey works fine with or without hmac-secret request, with hmac-secret the authenticatorGetAssertion_Response is 7 bytes shorter than the response from Solo.

[conorpp]

Thanks a lot for checking this out Alex. I replicated the issue and found the issue with the signatures. Now running assert.exe ... succeeds. I will post an update tomorrow.

[conorpp]

@aseigler Can you try Windows Hello again with this pre-release of 2.4.1?

firmware-secure-2.4.1.json

firmware-hacker-2.4.1.hex

# signed update for secure
solo program bootloader firmware-secure-2.4.1.json

# update for hacker
solo program bootloader firmware-hacker-2.4.1.hex

[aseigler]

Assert.exe definitely looks much happier than previous. It's gonna take a little longer to test the rest of Windows functionality requiring hmac-secret.

[aseigler]

The signature validation issue is definitely fixed in this release, but unfortunately that wasn't the issue blocking Hello enrollment. Haven't been able to try desktop login from Azure registration yet.