HMAC secret extention with FIDO Conformance Tools v1.6.35 (CTAP2.1 Authenticator)

[thalesfid...@gmail.com]

Hello All,

I'm actually using FIDO Conformance Tools v1.6.35 (CTAP2.1 Authenticator) and i encounter an issue with P-3 test of HMAC secret extention part.

i have CTAP2_ERR_PIN_AUTH_INVALID on the getAssertion command. By  debugging, i spot that the issue comes when i try to verify the signature of saltAuth =>(verify(shared secret, saltEnc, saltAuth).

due to open inspector, i saw that the tool sent a get shared secret command  with protocol 1 before  the Make credential command (P-2 test)  whereas it sent a get shared secret command  with protocol 2 before the getAssertion command.

Concerning the  CBOR map entry in the "extensions" field to the authenticator, i received:

4: {"hmac-secret": {1: {1: 2, 3: -25, -1: 1, -2: h'8B034920112F9E3B1A78A719663EC2B00E498E82582068F50E6EB0292E6BFFDA', -3: h'D16AF2D3170231D8DB91DC9BC88019A4FE4F0F1C43A8486CCA930A5F2A5020EE'}, 2: h'0C7046157EC2816E4965EC139EF08CDC58F697FDDCE54BCF1D53D908065BACBC', 3: h'BD19486177BD43DEE78D3856A3C534DC'}} 

I noticed that  pinUvAuthProtocol(0x04): is missing in this CBOR Map. According to CTAP 2.1 specification: 

pinUvAuthProtocol(0x04): (optional) as selected when getting the shared secret. CTAP2.1 platforms MUST include this parameter if the value of pinUvAuthProtocol is not 1.  

According to the protocol value given in  getting the shared secret command, it should be 2 so that it should be present in the input data.

On my side i considered that it was 1 according to CTAP 2.1 specification:

 If pinUvAuthProtocol is absent and a pinUvAuthProtocol value of 1 is supported by the authenticator, let the value of pinUvAuthProtocol be 1

Did i miss something?

Thank you for you clarification.

Regards,

F. Faven

[Ackermann Yuriy]

Hey Faven.

I have addressed a similar issue just today. Try 1.6.37 https://builds.fidoalliance.org/Desktop%20UAF%20FIDO2%20U2F/EXPERIMENTAL/v1.6.37/.

Yuriy Ackermann

FIDO, Identity, Standards

skype: ackermann.yuriy

github: @herrjemand

twitter: @herrjemand

medium: @herrjemand

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/b4d011c3-922d-4708-8430-e49d061b9b0bn%40fidoalliance.org.

[thalesfid...@gmail.com]

Hello Yuriy,

Thanks for the update.

It's fixed now.

Best regards,

f.faven

[thalesfid...@gmail.com]

hi Yuriy,

Sorry to bother you again, but it seems that in resident key tests part, a getPinToken command is sent, before the pin has been set.

Regards,

F.faven

Le mercredi 1 décembre 2021 à 15:44:28 UTC+1, Ackermann Yuriy a écrit :

[thalesfid...@gmail.com]

By the way, i noticed that for P-6 of  HMAC secret extention, this is the same issue : a getAssertion command is sent without pinUvAuthparam in extension, whereas a get shared secret has been sent with protocol 2.

Regards,

F.Faven

[nuno sung]

If it's possible, should we follow this conformance tool issue under below one ?

https://github.com/fido-alliance/conformance-test-tools-resources/issues/620

ffa...@thalesgroup.com 在 2021年12月2日 星期四上午12:10:40 [UTC+8] 的信中寫道：