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

63 views
Skip to first unread message

thalesfid...@gmail.com

unread,
Dec 1, 2021, 8:41:24 AM12/1/21
to FIDO Dev (fido-dev)
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

unread,
Dec 1, 2021, 9:44:28 AM12/1/21
to thalesfid...@gmail.com, FIDO Dev (fido-dev)
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

unread,
Dec 1, 2021, 10:22:27 AM12/1/21
to FIDO Dev (fido-dev), Ackermann Yuriy, FIDO Dev (fido-dev)
Hello Yuriy,

Thanks for the update.
It's fixed now.

Best regards,

f.faven

thalesfid...@gmail.com

unread,
Dec 1, 2021, 10:45:08 AM12/1/21
to FIDO Dev (fido-dev), Ackermann Yuriy, FIDO Dev (fido-dev)
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

unread,
Dec 1, 2021, 11:10:40 AM12/1/21
to FIDO Dev (fido-dev), Ackermann Yuriy, FIDO Dev (fido-dev)
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

unread,
Dec 2, 2021, 8:11:16 AM12/2/21
to FIDO Dev (fido-dev), thalesfid...@gmail.com, Ackermann Yuriy, FIDO Dev (fido-dev)
If it's possible, should we follow this conformance tool issue under below one ?

ffa...@thalesgroup.com 在 2021年12月2日 星期四上午12:10:40 [UTC+8] 的信中寫道:
Reply all
Reply to author
Forward
0 new messages