[BUG] Incompatible Hash/HMAC algorithm usage when SECP384R1 attestation type used for owner and device

[Sai-Anudeep47]

To simplify issue resolution process, please provide network logs, and or test voucher. to2_client384_hellodevicehash_fail_log.txt

What part of the spec are you testing?

• [ ] Rendezvous Server
• [ ] Device Onboarding Service
• [x] #34

What protocol are having issue with?

• [ ] TO0
• [ ] TO1
• [x] TO2

Issue description

• When attestation type of SECP384R1 is used on both owner and device, according to Spec https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-PS-v1.1-20220419/FIDO-Device-Onboard-PS-v1.1-20220419.html#the-devmod-module:~:text=Table%20%E2%80%91%3A%20Mapping%20of%20Hash/HMAC%20Types%20with%20Key%20sizes, hash and HMAC should be SHA384/HMAC-SHA384
• But at https://github.com/fido-alliance/fdo-fido-conformance-server/blob/main/core/shared/enc.crypto.go#L85 SHA256/HMAC-SHA256 is hardcoded and not picked dynamically based on attestation types and this leads to "Failed to verify helloDeviceHash" error

Log is attached for reference.

[yackermann]

Yeah, that was a typoe. Thx @Sai-Anudeep47

[Sai-Anudeep47]

Issue is observed now, when SECP256R1 attestation type is used. Conformance owner must dynamically pick algorithm based on attestation type rather than hardcoded algorithm. Including the spec reference again as link present in original comment is not accessible https://tinyurl.com/hashmapping

[yackermann]

@Sai-Anudeep47 sorry but I am confused. Are you talking about ProveDevice64?

[Sai-Anudeep47]

@herrjemand It is observed when parsing TO2.ProveOVHdr message by client, where it calculates hash of the original TO2.HelloDevice message and compares with hash value present in TO2.ProveOVHdr as mentioned in spec https://tinyurl.com/helloDeviceHash

[yackermann]

Found the issue! Thx @Sai-Anudeep47.

This is now addressed