[BUG] Exception in decryption of message 65 when using AES GCM and CCM ciphersuites

[Sai-Anudeep47]

To simplify issue resolution process, please provide network logs, and or test voucher. aad_bytes_conformance_owner.log

What part of the spec are you testing?

• [ ] Rendezvous Server
• [x] Device Onboarding Service
• [ ] Device Implementation

What protocol are having issue with?

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

Issue description

• While decryption message 65 sent by conformance owner, client throws following exceptions for respective cipher suites and results in failure of message decryption.
  • For AES256GCM, the exception is javax.crypto.AEADBadTagException: Tag mismatch!
  • For AES_CCM_64_128128, the exception is java.io.IOException: org.bouncycastle.crypto.InvalidCipherTextException: mac check in CCM failed_

• In both the cases, AAD bytes are used for authentication check and following are observations w.r.t the same

  • [x] At https://github.com/fido-alliance/fdo-fido-conformance-server/blob/main/core/shared/signing.misc.go#L50, the context must be "Encrypt0" rather than "Encrypt" as mentioned in https://tinyurl.com/aadrfc

  • [x] It is observed that at https://github.com/fido-alliance/fdo-fido-conformance-server/blob/main/core/shared/enc.crypto.go#L218 protectedHeaderInner returns unwanted values similar to #27 and missing map type for "Alg"

    • Log for conformance owner by adding print statements is attached.

  • [x] Also, it is observed, that encoded aadbytes returns invalid byte array which when compared with aad value generated on client side.

    • On Conformance owner side, aad byte array returns: [128]
    • On client side, aad byte array has value of: [-125, 104, 69, 110, 99, 114, 121, 112, 116, 48, 68, -95, 1, 24, 32, 64]
    • Log for same can be seen in the same attached file for conformance server. For client side a screenshot is attached.
    • According to https://tinyurl.com/aadencrfc, there is specific encoding rules to be followed for AAD struct.

[yackermann]

Okay. 2/3 Issues addressed. For the last one I need to finish integration flow test. Will finish in the morning

[Sai-Anudeep47]

Following are few additional observations.

• [x] At https://github.com/fido-alliance/fdo-fido-conformance-server/blob/main/core/shared/enc.crypto.go#L424 it is observed that protectedHeaderInner is directly used, it should be protectedHeaderBytes
• Upon adding print statements as follows, it is observed that protectedHeaderBytes returns map type for Alg which is expected. Attached screenshot for reference fmt.Println("-------- protectedHeaderInner Value -------- ") fmt.Println("protectedHeaderInner: ", protectedHeaderInner) fmt.Println("protectedHeaderBytes: ", protectedHeaderBytes) fmt.Println("protectedHeaderBytes_EncodetoString: ", hex.EncodeToString(protectedHeaderBytes))

[yackermann]

@Sai-Anudeep47 yes you are correct

[yackermann]

Ok. This should be now resolved.

[Sai-Anudeep47]

@herrjemand The issue is still noticed with latest fix. Following is a observation upon debugging.

• protectedHeaderBytes should be used instead of unprotectedHeaderBytes in aadStruct at https://github.com/fido-alliance/fdo-fido-conformance-server/blob/main/core/shared/enc.crypto.go#L420 according to https://tinyurl.com/aadstructrfc

Upon modifying conformance code with above changes, the expected behavior is observed where AAD bytes generated by conformance owner is same as generated on client side. Even though AAD being matched, during authentication check for encrypted text, it throws afore mentioned exception, as follows

• For AES256GCM, the exception is javax.crypto.AEADBadTagException: Tag mismatch!
• For AES_CCM_64_128_128, the exception is java.io.IOException: org.bouncycastle.crypto.InvalidCipherTextException: mac check in CCM failed

[yackermann]

🤦 Sorry for that.

Fixed now