fido-alliance / iot-fdo-conformance-tools Goto Github PK

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
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• 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_128_128, 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

  • 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

  • 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.

  • 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.

To2Requestor.confCheckResponse: To1 test list is used instead of To2 list.

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

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

• When using AES_CCM_64_128_128/AES_CCM_64_128_256 ciphersuites, conformance owner returns EMBlock without AES IV field in unprotected header in message 65 and client fails with error "COSE_Encrypt0 Unprotected header: Failed to read AESIV Key"
• Observed that at https://github.com/fido-alliance/fdo-fido-conformance-server/blob/main/core/shared/enc.crypto.go#L411 IVBytes are populated based on algInfo.IVLen field but such field is not present for CCM ciphersuites as declared at https://github.com/fido-alliance/fdo-fido-conformance-server/blob/main/core/shared/enc.crypto.go#L111
• According to https://tinyurl.com/coserfc a check can be included for CCM ciphersuites to populate IVBytes with algInfo.NonceLen
• Log is attached for reference that shows empty unprotected header without IV field

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

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

With latest fix https://github.com/fido-alliance/fdo-fido-conformance-server/commit/34676284901fa38afacbf21bcabf0399e1382e17 ,when uploading voucher via UI, an error "NetworkError when attempting to fetch resource" is observed. and following error is observed in logs. The stack trace for the same error is present in log attached.

• *http: panic serving 127.0.0.1:48822: interface conversion: interface {} is fdoshared.DeviceSgType, not int

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

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

The conformance server does not check response for group test FIDO_TEST_LIST_VOUCHER
https://github.com/fido-alliance/fdo-fido-conformance-server/blob/bed48409e41da82fc603fa89ef645ca8cc5acb14/core/device/to2/to2-common.go#L44

According to specification, RVValue should be bstr https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-PS-v1.1-20220419/FIDO-Device-Onboard-PS-v1.1-20220419.html#RVDef (RVValue = bstr .cbor any, cbor null is not null).

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

2023/09/27 10:44:21 Requesting GetOVNextEntry62 for entry 0 
2023/09/27 10:44:21 Requesting GetOVNextEntry62 for entry 1 
2023/09/27 10:44:21 Requesting GetOVNextEntry62 for entry 2 
2023/09/27 10:44:21 Requesting GetOVNextEntry62 for entry 0 
2023/09/27 10:44:21 http: panic serving [::1]:62577: runtime error: invalid memory address or nil pointer dereference
goroutine 163 [running]:
net/http.(*conn).serve.func1()
        /Users/thaodtp/sdk/go1.19.5/src/net/http/server.go:1850 +0xb0
panic({0x1033cca80, 0x103862f50})
        /Users/thaodtp/sdk/go1.19.5/src/runtime/panic.go:890 +0x258
github.com/fido-alliance/fdo-fido-conformance-server/testexec.executeTo2_62({{}, {0x1400b0f0190, 0x10, 0x10}, {0x140002cc270, 0x15}, 0x2, 0x1400037d050, 0x0, {{}, ...}, ...}, ...)
        /Users/thaodtp/Documents/work/projects/FDO/FA/fdo-fido-conformance-server/testexec/do.to2.62.execute.go:119 +0x93c
github.com/fido-alliance/fdo-fido-conformance-server/testexec.ExecuteDOTestsTo2({{}, {0x1400b0f0190, 0x10, 0x10}, {0x140002cc270, 0x15}, 0x2, 0x1400037d050, 0x0, {{}, ...}, ...}, ...)

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

• API called: /api/dot/execute

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

2023/09/21 13:26:26 Starting FIDO_TEST_VOUCHER_ENTRY_BAD_HDRINFO_HASH
2023/09/21 13:26:26 Starting FIDO_TEST_VOUCHER_ENTRY_BAD_SIGNATURE
2023/09/21 13:26:26 Starting FIDO_TEST_VOUCHER_ENTRY_BAD_PREV_HASH
panic: interface conversion: interface {} is fdoshared.DeviceSgType, not *int

goroutine 83 [running]:
github.com/fido-alliance/fdo-fido-conformance-server/core/shared.GetIntRef(...)
        /Users/thaodtp/Documents/work/projects/FDO/FA/fdo-fido-conformance-server/core/shared/other.crypto.go:49
github.com/fido-alliance/fdo-fido-conformance-server/core/device.GenerateOvEntry({{}, 0x140061aa000?, {0x140000307e0?, 0x1a0?, 0xc4?}}, {{}, 0x8a?, {0x140000307c0?, 0x14005b1f710?, 0xfffffffffffffff9?}}, ...)
        /Users/thaodtp/Documents/work/projects/FDO/FA/fdo-fido-conformance-server/core/device/genvoucher.go:51 +0x268
github.com/fido-alliance/fdo-fido-conformance-server/core/device.NewVirtualDeviceAndVoucher({{}, {0x1400009c910, 0x3, 0x3}, {0x14000190240, 0x8a, 0x8a}, 0x5, 0xfffffffffffffff9, {{}, ...}, ...}, ...)

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

• The issue occurs when calling API "/api/dot/api"

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

2023/09/27 13:30:05 Requesting GetOVNextEntry62 for entry 5 
2023/09/27 13:30:05 Requesting GetOVNextEntry62 for entry 0 
2023/09/27 13:30:05 Requesting GetOVNextEntry62 for entry 1 
2023/09/27 13:30:05 Requesting GetOVNextEntry62 for entry 2 
2023/09/27 13:30:05 Requesting GetOVNextEntry62 for entry 3 
2023/09/27 13:30:05 http: panic serving [::1]:50577: runtime error: invalid memory address or nil pointer dereference
goroutine 38 [running]:
net/http.(*conn).serve.func1()
        /Users/thaodtp/sdk/go1.19.5/src/net/http/server.go:1850 +0xb0
panic({0x100b20a80, 0x100fb6f50})
        /Users/thaodtp/sdk/go1.19.5/src/runtime/panic.go:890 +0x258
github.com/fido-alliance/fdo-fido-conformance-server/testexec.executeTo2_62({{}, {0x140003e6170, 0x10, 0x10}, {0x1400021c288, 0x15}, 0x2, 0x140007a6420, 0x0, {{}, ...}, ...}, ...)
        /Users/thaodtp/Documents/work/projects/FDO/FA/fdo-fido-conformance-server/testexec/do.to2.62.execute.go:57 +0x434
github.com/fido-alliance/fdo-fido-conformance-server/testexec.ExecuteDOTestsTo2({{}, {0x140003e6170, 0x10, 0x10}, {0x1400021c288, 0x15}, 0x2, 0x140007a6420, 0x0, {{}, ...}, ...}, ...)

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

• API: /api/dot/execute
• Test case: FIDO_DOT_62_POSITIVE
• This is related to #15
• Observed after debugging:
  • value of testId input in to2requestor.GetOVNextEntry62(uint8(i), testId) is FIDO_DOT_62_POSITIVE https://github.com/fido-alliance/fdo-fido-conformance-server/blob/6d23facb23ff9012ab77fc8b96aeba015f16d683/testexec/do.to2.62.execute.go#L48
  • For case FIDO_DOT_62_POSITIVE, the GetOVNextEntry62 function returns at this line
    https://github.com/fido-alliance/fdo-fido-conformance-server/blob/6d23facb23ff9012ab77fc8b96aeba015f16d683/core/device/to2/req-to2-62-GetOVNextEntry.go#L30
    which means the nextEntry and err are both nil, hence panic at this line
    https://github.com/fido-alliance/fdo-fido-conformance-server/blob/6d23facb23ff9012ab77fc8b96aeba015f16d683/testexec/do.to2.62.execute.go#L57

I'm unable to build the project following the default instructions because there might be some issue with the modules:

⬢[idiez@toolbox webauthnworks]$ git clone [email protected]:WebauthnWorks/fdo-fido-conformance-server.git
Cloning into 'fdo-fido-conformance-server'...
remote: Enumerating objects: 621, done.
remote: Counting objects: 100% (621/621), done.
remote: Compressing objects: 100% (329/329), done.
remote: Total 621 (delta 413), reused 485 (delta 277), pack-reused 0
Receiving objects: 100% (621/621), 131.16 KiB | 718.00 KiB/s, done.
Resolving deltas: 100% (413/413), done.
⬢[idiez@toolbox webauthnworks]$ cd fdo-fido-conformance-server/
⬢[idiez@toolbox fdo-fido-conformance-server]$ ls
Makefile   _dis       bin  externalapi  go.mod  main.go         running.ctx.go-e  services  tools
README.md  _vouchers  dbs  frontend     go.sum  running.ctx.go  seeding.setup.go  testexec
⬢[idiez@toolbox fdo-fido-conformance-server]$ make setup
echo "\n----- Preconfig: Updating git submodules -----\n"
\n----- Preconfig: Updating git submodules -----\n
git submodule init
Submodule 'frontend' ([email protected]:WebauthnWorks/fdo-fido-conformance-frontend.git) registered for path 'frontend'
git submodule update
Cloning into '/home/idiez/code/repos/webauthnworks/fdo-fido-conformance-server/frontend'...
Submodule path 'frontend': checked out 'e380823d935819775d56f036e2f7e4b73797df98'
echo "\n----- Preconfig: Setting up svelte frontend nodejs dependencies -----\n"
\n----- Preconfig: Setting up svelte frontend nodejs dependencies -----\n
cd ./frontend && npm i

added 91 packages, and audited 92 packages in 2s

11 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
echo "\n----- Preconfig: Updating go dependencies -----\n"
\n----- Preconfig: Updating go dependencies -----\n
go get
github.com/WebauthnWorks/fdo-fido-conformance-server imports
	github.com/WebauthnWorks/fdo-device-implementation: cannot find module providing package github.com/WebauthnWorks/fdo-device-implementation
github.com/WebauthnWorks/fdo-fido-conformance-server imports
	github.com/WebauthnWorks/fdo-device-implementation/common: cannot find module providing package github.com/WebauthnWorks/fdo-device-implementation/common
github.com/WebauthnWorks/fdo-fido-conformance-server imports
	github.com/WebauthnWorks/fdo-device-implementation/to1: cannot find module providing package github.com/WebauthnWorks/fdo-device-implementation/to1
github.com/WebauthnWorks/fdo-fido-conformance-server imports
	github.com/WebauthnWorks/fdo-do: cannot find module providing package github.com/WebauthnWorks/fdo-do
github.com/WebauthnWorks/fdo-fido-conformance-server imports
	github.com/WebauthnWorks/fdo-rv: cannot find module providing package github.com/WebauthnWorks/fdo-rv
github.com/WebauthnWorks/fdo-fido-conformance-server imports
	github.com/WebauthnWorks/fdo-fido-conformance-server/externalapi imports
	github.com/WebauthnWorks/fdo-do/dbs: cannot find module providing package github.com/WebauthnWorks/fdo-do/dbs
github.com/WebauthnWorks/fdo-fido-conformance-server imports
	github.com/WebauthnWorks/fdo-fido-conformance-server/externalapi imports
	github.com/WebauthnWorks/fdo-fido-conformance-server/externalapi/testapi imports
	github.com/WebauthnWorks/fdo-do/to0: cannot find module providing package github.com/WebauthnWorks/fdo-do/to0
github.com/WebauthnWorks/fdo-fido-conformance-server imports
	github.com/WebauthnWorks/fdo-fido-conformance-server/externalapi imports
	github.com/WebauthnWorks/fdo-fido-conformance-server/externalapi/testapi imports
	github.com/WebauthnWorks/fdo-fido-conformance-server/testexec imports
	github.com/WebauthnWorks/fdo-device-implementation/to2: cannot find module providing package github.com/WebauthnWorks/fdo-device-implementation/to2
make: *** [Makefile:15: preconfig_conformance_server] Error 1

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
• #34

What protocol are having issue with?

• TO0
• TO1
• 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.

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

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

• Decryption of message 65 failed on client side using AES256GCM cipher suite due to authentication failure
• According to https://www.rfc-editor.org/rfc/rfc8152#section-5.3, for AEAD algorithms, authenticated data structure (context, protected header, external_aad) has to be used while encryption and decryption.
• According to https://pkg.go.dev/crypto/cipher#NewGCM, additionalData to be passed for Seal function for AEAD algorithms, but observed, it is missing in https://github.com/fido-alliance/fdo-fido-conformance-server/blob/main/core/shared/enc.crypto.go#L405

DELETE /api/dot/testruns/{testinsthex}/{testrunid}: duplicate required input (testinst and testrunid) in path variable and request body, only request body is used.

The specification does not require FDO components to support device attestation and verification using RSA cryptography: https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-PS-v1.1-20220419/FIDO-Device-Onboard-PS-v1.1-20220419.html#device-attestation

Sample voucher in Msg22-OwnerSign during RV test: 825915098385186559019086186550f1d0fd009e6b47d2b9f94d39bb1245608181820e41f678244920616d2061207669727475616c204649444f20416c6c69616e6365206465766963652183010159012630820122300d06092a864886f70d01010105000382010f003082010a0282010100a86c7834f8fe62366157e64e73c962fa282eb272ac56b39ef6f30563f9426c3f3b5fd092b7b45c55b11fedaf48b1bb194f12d776b9d3196df3439ba4aa2209642a70f7ba5c19b8e7bcd7c33376a82b017507198999dfe8481a404f48635808b1c650b13811ca95b1db4f4f5670477983f91b324f2cd6f73482bfef2a5de3af254d779f3f24310f55acb35584d358f61b1356df11d35efef4bab661065f65d4d7e5e8059e23c322a3b4619c31699541c15f729ffd23affcc398ac3129d4e0710b061b3f7b4fbd11bfaad5e2fde2e73055edf6e2c858407576774c6ba93da4f4f92ce1f9f1ee9ff93e2fc3dec7d48f3ecc9045a3182911948a288394836319626b0203010001822f58204db7a347ed39a81cf9e2bc739ec771385a31ea5c860633c4f507bdb538e3d6b882055820d9b610a980686710d12fd218af5fd9ce7b7df28d26165b971133155b0ce5ddcb8359032730820323308202caa003020102021100f1d0fd009e6b47d2b9f94d39bb124560300a06082a8648ce3d040302307d311e301c06035504030c1546444f205445535420494e5445524d4544494154453122302006092a864886f70d0109011613696e666f40776562617574686e2e776f726b7331173015060355040a0c0e576562617574686e20576f726b73310b3009060355040613024e5a3111300f06035504070c0854617572616e6761301e170d3233303330363039303331385a170d3333303330363039303331385a3081a9310b3009060355040613025553311630140603550407130d53616e204672616e636973636f31163014060355040a130d4649444f20416c6c69616e6365316a3068060355040313615741572046444f205649525455414c2054455354203636333136343330363636343330333032443339363533363632324433343337363433323244363233393636333932443334363433333339363236323331333233343335333633302057415730820122300d06092a864886f70d01010105000382010f003082010a0282010100ac27678fb721ac8a8caaa47f58b8aa6b45e1457a3f6a7a9508a9aad364b7f0b7ec789f3ca51fe21748f52656daea0387bda5face45860e798d330bf58797cd51d5ed9cfb22f786652abf7ee740010802465d3588dc79f94471988e25c7c0e8be86b41be0f31d86cc83f619bc6ad795d96db0ea16e641237673a85d04fdaaf019823b33bfe5bc6038c97d3126169aee63a62c349a9827e4bacdf3a36956e2fdc8993dec10aeee408db22a2888f4852ce709686b0c925438ed313784b55f1c061f7a2df71b4906d5795fe8e3c3de98c37fef743017ad970471330dd6f7b67243b4e74ffd3e7c00c768112a9a08c633f72fef76e1cdfc73f8be1c10edeb2525e2530203010001a3333031300e0603551d0f0101ff040403020780301f0603551d230418301680143ea70672c2102b98767f3edcc905b7d7f3f9a704300a06082a8648ce3d04030203470030440220719b4e2e100452281df119aa8ead9bdc4b1de26dc52cec05d1ab93c965e15feb022052e5c2a935a8740c5d35f152b821556f4b32567a65cbc1242105ae2bb9e799865903d5308203d1308201b9a003020102020102300d06092a864886f70d010105050030753116301406035504030c0d46444f205445535420524f4f543122302006092a864886f70d0109011613696e666f40776562617574686e2e776f726b7331173015060355040a0c0e576562617574686e20576f726b73310b3009060355040613024e5a3111300f06035504070c0854617572616e6761301e170d3232303132333136303232395a170d3439303631303136303232395a307d311e301c06035504030c1546444f205445535420494e5445524d4544494154453122302006092a864886f70d0109011613696e666f40776562617574686e2e776f726b7331173015060355040a0c0e576562617574686e20576f726b73310b3009060355040613024e5a3111300f06035504070c0854617572616e67613059301306072a8648ce3d020106082a8648ce3d030107034200041076e0d0e67dbce00fd0ba7202f073a24a6ce1faecb20a69a2aad9b3203cb503ad1d24841c4f85d63d896b43104e5dd3c023b79f80e0d6c60bd725ade40fae30a32f302d300c0603551d13040530030101ff301d0603551d0e041604143ea70672c2102b98767f3edcc905b7d7f3f9a704300d06092a864886f70d010105050003820201003ab2db5fae488ebaf76996a086f9c001ce352028f6293af1a23f0c4b276f1b54a3f93d7e3f5250c2870a892d75fdcd3ab05d4cd489083c14c18ad3b104ae0b6af55ac5bfaa7ff5195a1611d3640d88ad99b72e053f30d494e6cbfcefb6f1cc2c88233ffc28276eddec3aff3588c7d70f1277e672abfb5adac9167d0f8bedb645908bb8a4a6f20127e61e4c5414e2f1406a1fbc542ec263862ab36b38721e95686f5ae2adfacd78a2a50edc31422c542b8716deca4c0a2e8b3ff438fc412632ec3e8b3224c048a84c978a92ebe4e8752a6fa0f6252feeada7e0125ab79af2e386a6739463cb252fbedec3b907dbde4c1fc0931e95d1321600910c023682fccce72c0c540ff64452fe961de8bd1464cbbdd6ea69cfb28a4ce3d738ffea76e1fcc221f161193d0e17b596ef323d6571cecc030f9190768531b2d5a76ad6d913b85364333170f5c40d544be09f5d2739248f61d86e8c5552322c11e4c43483e07dcc629338ab08da125f7fc79ffd194f107d28c03cc90b01b6fcb4aea40a61ae183b41e301a4c9af4b38ba4cd69142a989beab15a5d442d6194ebb7db5026559a85457cb77473876f9fc3a0d8c5b573518a077fd075e187b112b2f2119007712aa4744b5f15de42ad80f410d79f57b1f220b364fa6c8265e5753cf5404786069c194852daaf2e8e2c868aade2aab27c7d1f7990ac4b4536370cb1b8b371cd22a447359056a308205663082034e020900ada31b6ce9a9c313300d06092a864886f70d01010b050030753116301406035504030c0d46444f205445535420524f4f543122302006092a864886f70d0109011613696e666f40776562617574686e2e776f726b7331173015060355040a0c0e576562617574686e20576f726b73310b3009060355040613024e5a3111300f06035504070c0854617572616e6761301e170d3232303132333136303232395a170d3439303631303136303232395a30753116301406035504030c0d46444f205445535420524f4f543122302006092a864886f70d0109011613696e666f40776562617574686e2e776f726b7331173015060355040a0c0e576562617574686e20576f726b73310b3009060355040613024e5a3111300f06035504070c0854617572616e676130820222300d06092a864886f70d01010105000382020f003082020a0282020100dd22f3a4d369939feba7961af8f9b8d05ca379fa30b04a7d9381c823cf61744a505f96c7ac55cbf8dc3406580518301d2e485c4662efdede9ab24954ed53b9d80d49b7d71490b330ddf534f1ee899926893d1b4625a06cef7356acefc62f8072ec26feb65ed75a05f90312c5adf63ac03b92b2f1ac3347ef1347b9911b9d96ee53b1786e308b03273fd7608197f27f81461d32899651c02f930c5afc8b8ff526d2d96431759a2dd583d248ced3d2fd6251f1de29aec08727fea086d18bb008703c27b4caa73a2988379f3cefd0037ba90a0950484c593dacb5d6c6ad1f5aa1c61fbf6c207875038eed43d13f84fd1d0a9ce4e1f474933a7725bf266deeb2c562207f95fbce81ece0c76d942890254243563c2443886e6e171aca913329aafca38f88364e8845cb2363e2d85fcac85e14dc5d74557a6cfbe1331bcb2560a479468f94a9e167a4d28deb35d93606e8bcd6e1c94c2ff9bb8970dc5649c34d1584723d600d89a6d3f35db00ab9581c83364b4552430eb97e9b9d0f558fa92b50e133b6fffd2950a0cff5442f53d2ceb9f49e50dfcdd2c4363f130337530584fbd9885f9d21bf0f31f75fd4bc7c9c5714409148f85759820b511d3a53bf1ef07e918b1511894ba7dbce4c11b0845459552c5ca3b78d3891fd580aef78ac6b24fdbcf5db3ad713328d8f2f227d3b1a539094c4d69117bba3c2dc0b976c653b3efb27370203010001300d06092a864886f70d01010b050003820201005e317fa6dccf6a653b9551db115ff9ca31db25ad0947d9bead51c0258d2fb38832fb9e5cae00097552a941bfb1fc11abff87c8aef8e7a8e33a81130f31cd72fdd2f7ec68a7020bcfdcabf95e3855f311ea12e21de13f091937a594e7e48cd46322a787e965a7690684ee35647d08c3bd93d03fbc42a1a99c3af23cc828ca0e59dfd048bbfb7e9075c21d1d619bbae58207bc868e6cf1713cab689443ad329973340f9021d522a908fa22bcda6c37db845a417c6c4ba186697b368095825fb49e30562f88f1c492b55ad130756c8eaea5d70c61a217764f8e5594a3f7f2f817b81d5c71f59bb6dde9a1097f5cc9e54e923ba7b56f4248db0ae90df1c846bd60eb82473961097c3cf9fe1f3218eb109f1cf66989484fb84426864b4cd3cc9e4d631a46460566c96b1dafdb59976b1f5d696ec1e9d03f5338afd2df590df18191a3997d3e5f1141b2c2bbc0ec10487b6f63dda5c75621c54f77227db983ebe96367a6dbecfd7bb4d6fcff5071c4f906152cd3ecb52f3477ad6750a5d1e230a9b62259421e66365cb12d401ba0819ad14af7e43b06fda5998279a2b2a20134fa1cb2181cf025a0d30cd4c02a9c29ed3d8cfadfa873b06d6cc766b44a33a2bb7a09d46bf397843ff3ed12d5be5126eca7b843e42d766678d7fd77e34789d6b2a8f1c06b022540e55c747d031b5b53e17d1c2dd0623de58f5d078c298edcf5bfe4555f838445a101390100a31901005000000000000000000000000000000000190101830000f6390102500000000000000000000000000000000059017684822f5820dcd37d20a358704d4a03218bd6ed0a5e82cc33407a02a2b608a9e6083417f3d2822f5820478633617fb5114430768b5943231c9c79805c029a801a8b64e45632b918eeb1f683010159012630820122300d06092a864886f70d01010105000382010f003082010a0282010100e341c111aa0b8192a37e8026f3e36ecbbb26aba9e3e1e74465929150e824a1ff43dc9f4e1e5d95cf81d2976198995433edf2f4ecb5f65475ec84c919dba5d7254831320aab1e4d47858b9c289dc6fb5ad7618e80b00a1adb0addfdb188e390908fd6747d906a33a1177a1a611605b8a969eb7dec0efce2d296a89f6a5e98270cda28a501c9cc139000e249764fcd7e9991c2dd57f177e025be1d4097633496e479dd8bb84823e46447cdcd27b392cf7574b93bfbc5e77ac5aa7b972f0202ad649ef6fd309c89faeb435779fac15e21bad63fd1af5b13219c1cf0e2a161391bf928f467591ffed0593a8bfc26dfa866f07bc0077a80ce2baddc5d92b4a0f5965b02030100015901001cd2022c0b148ee60d7d858101a412219330ffec87ab50815351ae3cb17cb4a47ce7557b11fc1e1bc6f1d4da6e92c137b57dbbf961f5959b3fac6d0c795458ae60671d4fcde359e27b6c970599b3f4a524273ea21c661904757f402363670030402d38e449bcc1366e5063f0094b746ba832f9881601ab7a52eb44da62cae30e25fae0b477ff98477c609444fa5d4cce6bbd6e7a8ea33d68422488769d64ab8679b1d5273c50261282eed6d5545a1bb8f8c53b55891991120a9a75d8314d3511348b41294ed9fa9a35d7e0b5e374fe2578afbb42c018155df8b64ece4203b381e47c565166df7ea767195533afbd797f61934e115456bf122992d4861633507d8445a101390100a31901005000000000000000000000000000000000190101830000f6390102500000000000000000000000000000000058c784822f5820f18e2f70b0a4dd9845e698a02288d9d99fce2ee221241875f678152dbfa2efa9822f5820478633617fb5114430768b5943231c9c79805c029a801a8b64e45632b918eeb1f6830b0158783076301006072a8648ce3d020106052b8104002203620004ed8827298a1cabb309414912a354f734bd55973aeea7b59b78c367550b08ee03f9f277b98a5fc2b93fc5d9ca2df3037aff40fc81e4f4e82bd785053c0c1deb8caa27316fdf33f3eec344a145ad7298611cd075e0bfd603a9bbde01ed9109908759010084b9dc3bd1ebb2b42533c4f255f79996408a6c7951829bbb163b13d4193657db0e1b42490958a63b09bd1ef86d99595ddc140433146abb0c1f7cf2469559664b2aa2368f3c1440d3efd35cef1ed7f3f46140e08fa7d624cd58b6dfe9ec73c2cce285bb7128a5a93e8864d6447950679b694145d24f59b7b08eb21535b1e934036db0201e946cfccbdd52dd2de74571aebb6b44112ac81cbef767170fdc2c06a619a70563ba20a111d5d803bf0a2100d3049e637c66dd28296a726c4adfeba2856be8d3ffce52a545239fec3786feaea2dffa50eaef911e3fb86b24ef3095f82f8d251d80a2c30e63560e2046347afea4dcad6e728edf18eefa5ad70c2e90abef8444a1013822a31901005000000000000000000000000000000000190101830000f6390102500000000000000000000000000000000059017684822f5820ccea60a113b3bb5ca290ff17d59c7ee4d74947ab4321e771158d0ad7bb15ec10822f5820478633617fb5114430768b5943231c9c79805c029a801a8b64e45632b918eeb1f683010159012630820122300d06092a864886f70d01010105000382010f003082010a0282010100be1417c302a91e667b9ecd1fc4c36b303e19a9a2e55e3c65f1dd0b128ce2996788529b5b4b0dc86ccebdec5e792c8783ea86505fa1239b374a8ff4171525641db58bd59b7ab0d87f08380f93a03882287edbdd7acaddde3699415fde7a8f1395c0fbeaa49e0ad26e49120cf9a070d4065f275575ade432a4b6b7fbd00d6c89f43f3061a0dd8e982e36a242365b924b63744431ccc93afdf027ba20d2855bfe4b23b8b6c208f860b352757943a1f8a828abe607a4ea61877ac367cf61b2c51d54b15419546da6ca01dfa8e0d5b130d82ebbcc7e7d7f703f535b51ae7ba1f3b95b3d69f652763a0258c1b121412c7a4e6b80f7f93889b62408e96d4954190f61b7020301000158607db049b869261d8b0149e7f50481b82df7bd97f4481912c6d8af0a7cb397e2dcc3a44ec825534517ae562941d68925a329dbe77d1b9dd67bb69b8a47beba186590c46634c29fa720304653d4951cf7d2545ebbabe743f56c73a19dad4d26e2d71a00278d0050e71c627b1ba5f306a7834cd6148bdef88441a0a31901005000000000000000000000000000000000190101830000f639010250000000000000000000000000000000005831828184447f000001f6191f9003822f5820fa86e03fb5fd6cd0c64416a7bce85da0ee9c5deab66a484363819075ffcb2d605901003725976e60d92ea2514f2953ab8cf012df5abcf0aaf9f604b4cf73487d3dc5db180dfc8cfdece41b46c0fc3436fc5bcd99ea1bba5900ddd457bb434c10fad481720314c7042eb9ae2345d8259b2c6378a8d220ef10a42fd9df98030704b7fa7216f0c81a2611a910d0c75ebb4bbf30ab4bb1ba384eae88e9cda9c674ef0f16d1a2a1dec84d9311bce17d5043b9a14a316677b872f2f76c7214900c6185936bc3a78d8ea53e52a2f83cfbb9fce68aca519ed1d756fb3c7156bd3c6d82f72b47a97676693335445336e1c573293ce7b694de8ec5e23a191772cdccc86e865c75bfde3a74b4e789727436df7d70ab8793c4cd84e3aedea89a2a266e36f85a781128

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

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

• The voucher is received from API "/api/dot/vouchers/{uuid}". After parsing the voucher, received public key with pkType = 5, equivalent to RSA3072, but the pkBody is RSA2048.
• This is related to #19
• When generating RSA key, the value of pkType is fixed with RSAPKCS https://github.com/fido-alliance/fdo-fido-conformance-server/blob/bed48409e41da82fc603fa89ef645ca8cc5acb14/core/shared/voucher.go#L343

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

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

• Conformance owner returns "Error decrypting... Error decrypting EMB GCM. cipher: message authentication failed" when decrypting message 66 from client. Screenshot is attached for reference.
• 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#L502C39-L502C39 according to https://tinyurl.com/aadstrucrfc

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

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

• Conformance RV sends zero/null value in unprotected headers of COSE structure of message 33, which is not in accordance with spec https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-PS-v1.1-20220419/FIDO-Device-Onboard-PS-v1.1-20220419.html#rvblobrcvmsg:~:text=to1d%20%3D%20CoseSignature
• Expected

[h'A10126', {}, h'828184440A313C376B31302E34392E36302E3535191F6B05822F5820DD8011856FAC98D022675A9064ED1EC41C5696DF59FB37F6F141B4B2EFE34229', h'86C2B9649994115857D671C73C03E317F23E50B791022369E0702B9D618BD3B1C3F88FA3862C2838C7D2435F25BE3F7FC08FFAD53CC9B920A705AB09C9BBBCCF']

• Received

[h'A10126', {256: h'00000000000000000000000000000000', 257: [0, 0, null], -259: h'00000000000000000000000000000000'}, h'828184440A313C376B31302E34392E36302E3535191F6B05822F5820DD8011856FAC98D022675A9064ED1EC41C5696DF59FB37F6F141B4B2EFE34229', h'86C2B9649994115857D671C73C03E317F23E50B791022369E0702B9D618BD3B1C3F88FA3862C2838C7D2435F25BE3F7FC08FFAD53CC9B920A705AB09C9BBBCCF']

• This is related to #22

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

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

• Null/ Invalid value for protected header is sent by conformance owner in message 61.
• According to Specification and COSE RFC https://www.rfc-editor.org/rfc/rfc8152#section-4.2 and Table 2 in https://www.rfc-editor.org/rfc/rfc8152#section-3.1, it should be a map value of {1 : COSE_ALG}
• Expected protected header for ECDSA384 attestation type in diagnostic form
  h'A1013822'
• Received protected header in diagnostic form
  h'A0'

Log is attached for reference

Wrong pem tag.

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

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

Using AES CCM Ciphers "AES_CCM_64_128_128" and "AES_CCM_64_128_256" by client, results "Unknown cipher suit!" error by conformance server.

The spec states for message 33 "This message is bit-for-bit identical to TO0.OwnerSign.to1d"

see: https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-PS-v1.1-20220419/FIDO-Device-Onboard-PS-v1.1-20220419.html#rvblobrcvmsg

The conformance server is returning to1d with EAT paraments added to the unprotected header of To1d when generating message 33.

The spec states:
to1d = CoseSignature

For example this is the To01 being sent in message 22 TO0.OwnerSign.to1d. Note: unprotected headers are an empty map "{}"

TO0.OwnerSign.to1d: CoseSignature

[h'A10126', {}, h'82818444AC1100016C31302E34392E36302E313635191F6A03822F58208A3362B5D9715F2FE8C3BC9C951DE20298E5F63E79F6AF32AC0B2EDBF82209CA', h'7595B
5C03CC45466999278AE50129881A862D5078A062C7706A388C8028675CE24D7D96F849E60BCF81B7724B9A1853983C3331D657AFD1A87AE64D472749BD0']

This is what the conformance server returns in message 33. Note: its not bit-for-bit identical. It appears to add the following EAT parameters

256 --> CUPHNonce value is all zeros
257 --> CUPHOwnerPubKey - empty/null private key
-259 --> possibly EUPHNonce value is all zeris

TO1.RVRedirect, Type 33 (from conformance server)

[h'A10126', {256: h'00000000000000000000000000000000', 257: [0, 0, null], -259: h'00000000000000000000000000000000'}, h'828184F674686F73742E646F636B65722E6
96E7465726E616C191F6A03822F582098C90C705EB4F527769DE5813BE4FD0154D6444A79681BC5B40DDD3B749DAA1B', h'82BE5C7AA3CB819CAB6E5E696E85D1A73193908CEA
1C38E6C188AE24BE1F41668DF0C3D99D03C843B6F4CB97799D3A44490CE1B277B2ADA4DAF577F71E21D0AC']

to2_endianness_logs.txt

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

It is observed during message 61, 'xAKeyExchange' field is sent by conformance owner is in Little Endian format due to which client is unable to decode and throwing at message 64.

Expected value - '0020*'
Actual value - '2000*'

This is also related to #24

Resolved by changing all occurrences of "LittleEndian" to "BigEndian" in

core/shared/kex.crypto.go

Hi @herrjemand

After building and starting the FIDO Conformance Server in onprem mode, server returns "Failed to decode body" error during TO0 and TO1 protocols specifically message 22 and message 30.

Logs for such errors are attached from both FIDO Conformance Server and from FDO clients.

client_to0_msg22_fail_logs.txt

fdo_conformance_server_to0_logs.txt

client_to1_msg30_fail_logs.txt

fdo_conformance_server_to1_logs.txt

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

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

• Using AES_CCM_64_128_128/AES_CCM_64_128_256 ciphersuites on device side returns following error by conformance owner
  Type 255 [500, 64, "ProveDevice64: Error encrypting...Error generating new CCM instance. ccm: tagsize must be 4, 6, 8, 10, 12, 14, or 16", 1692811595, -2572133944488837156]

• Observed that

  • in https://github.com/fido-alliance/fdo-fido-conformance-server/blob/main/core/shared/enc.crypto.go#L117 the tag size is provided as 64
  • whereas at https://github.com/fido-alliance/fdo-fido-conformance-server/blob/main/core/shared/ccm/ccm.go#L62 the upper limit for check is 16, hence the error.

Type of private key is RSA2048 but type of public key in voucher is RSA3072

-----BEGIN OWNERSHIP VOUCHER-----
hRhlWQGQhhhlUPHQ/QCj/klIp5InXqZR0nmBgYIOQfZ4JEkgYW0gYSB2aXJ0dWFs
IEZJRE8gQWxsaWFuY2UgZGV2aWNlIYMFAVkBJjCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAMTfyl4m0mibr2CCVrzcVT/QBXkCVzsCSJETkx02voLPQHZy
Ylzizd80/9b0FOlE+Cu5HXErBTXsnqX28Ynma3d0PKSBix8gF9AY/W/KuyhLphj9
IrTIROOD/dvOQTqCZ1XRBTm+YmP8PyPQAkaRzAk1B7LN0x2Se1pIi/3/3lk4KLdd
u8jvMJ3dx5UqIWkAFNUo5ABYSmCDw0Kluv5fAa3570NtcFqgfpVVwaEolTvCbN1q
jzXX16/N6vc8IAXF+NuTHXP+lLSgpbNByTtqnPDY/nVZ2moh+IqRQMQPtYRKelnK
7UZ+RBdRnABXlP9G4BTBV6gPh4Dl8SDmL3xL4R0CAwEAAYIvWCBSTXxIJtXa1ylH
2x+yUxZ8ELuj0CJE7ldq13Tv7Z1MWIIFWCCqWT2qklX/wFQp43wTW7NRiQtWWW0f
3Ee+lwFBEwyk9oNZAygwggMkMIICyqADAgECAhEA8dD9AKP+SUinkideplHSeTAK
BggqhkjOPQQDAjB9MR4wHAYDVQQDDBVGRE8gVEVTVCBJTlRFUk1FRElBVEUxIjAg
BgkqhkiG9w0BCQEWE2luZm9Ad2ViYXV0aG4ud29ya3MxFzAVBgNVBAoMDldlYmF1
dGhuIFdvcmtzMQswCQYDVQQGEwJOWjERMA8GA1UEBwwIVGF1cmFuZ2EwHhcNMjMw
MzA2MDkwNzE2WhcNMzMwMzA2MDkwNzE2WjCBqTELMAkGA1UEBhMCVVMxFjAUBgNV
BAcTDVNhbiBGcmFuY2lzY28xFjAUBgNVBAoTDUZJRE8gQWxsaWFuY2UxajBoBgNV
BAMTYVdBVyBGRE8gVklSVFVBTCBURVNUIDY2MzE2NDMwNjY2NDMwMzAyRDYxMzM2
NjY1MkQzNDM5MzQzODJENjEzNzM5MzIyRDMyMzczNTY1NjEzNjM1MzE2NDMyMzcz
OSBXQVcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDg+ccto869l91X
1HRc2JPQtc4jhZClVAOMBk5W6S1BIWmjlmeE47eRHNMOSuVY13fNk/OYls9XZmLe
pt54vJakwQNUmpY55EKRYyYi6/hxwMc+khw2sr6j1bNzJNDaTblGkjFiuiQ2B8iL
du0JC+VAcT1wLCTa3Y49FLnwtSJUxTLckkUUFMyclCcZqjiHY1dOW+F1LUAQbBlh
hfftyUiVpLBsfPjtem+G6lly1DFrfDWDUJsEHJbNpC775E81SQSIppR0rP7SMo64
QUcSz8HIHC4b20f/gANPUs40MrEbxNIop5vOFP4krE8VjlfsVwXiMfPksaRQ4Tl6
W8+gnqBXAgMBAAGjMzAxMA4GA1UdDwEB/wQEAwIHgDAfBgNVHSMEGDAWgBQ+pwZy
whArmHZ/PtzJBbfX8/mnBDAKBggqhkjOPQQDAgNIADBFAiBJ9yGOtWmhTRNhuJjb
KDQFlIVpLY2X8216WVtkDVmNaAIhAKmaCwHFdFU6xET+W7aZGlfXRNv/ZxMxXovo
A7zRymPTWQPVMIID0TCCAbmgAwIBAgIBAjANBgkqhkiG9w0BAQUFADB1MRYwFAYD
VQQDDA1GRE8gVEVTVCBST09UMSIwIAYJKoZIhvcNAQkBFhNpbmZvQHdlYmF1dGhu
LndvcmtzMRcwFQYDVQQKDA5XZWJhdXRobiBXb3JrczELMAkGA1UEBhMCTloxETAP
BgNVBAcMCFRhdXJhbmdhMB4XDTIyMDEyMzE2MDIyOVoXDTQ5MDYxMDE2MDIyOVow
fTEeMBwGA1UEAwwVRkRPIFRFU1QgSU5URVJNRURJQVRFMSIwIAYJKoZIhvcNAQkB
FhNpbmZvQHdlYmF1dGhuLndvcmtzMRcwFQYDVQQKDA5XZWJhdXRobiBXb3JrczEL
MAkGA1UEBhMCTloxETAPBgNVBAcMCFRhdXJhbmdhMFkwEwYHKoZIzj0CAQYIKoZI
zj0DAQcDQgAEEHbg0OZ9vOAP0LpyAvBzokps4frssgppoqrZsyA8tQOtHSSEHE+F
1j2Ja0MQTl3TwCO3n4Dg1sYL1yWt5A+uMKMvMC0wDAYDVR0TBAUwAwEB/zAdBgNV
HQ4EFgQUPqcGcsIQK5h2fz7cyQW31/P5pwQwDQYJKoZIhvcNAQEFBQADggIBADqy
21+uSI6692mWoIb5wAHONSAo9ik68aI/DEsnbxtUo/k9fj9SUMKHCoktdf3NOrBd
TNSJCDwUwYrTsQSuC2r1WsW/qn/1GVoWEdNkDYitmbcuBT8w1JTmy/zvtvHMLIgj
P/woJ27d7Dr/NYjH1w8Sd+Zyq/ta2skWfQ+L7bZFkIu4pKbyASfmHkxUFOLxQGof
vFQuwmOGKrNrOHIelWhvWuKt+s14oqUO3DFCLFQrhxbeykwKLos/9Dj8QSYy7D6L
MiTASKhMl4qS6+TodSpvoPYlL+6tp+ASWrea8uOGpnOUY8slL77ew7kH295MH8CT
HpXRMhYAkQwCNoL8zOcsDFQP9kRS/pYd6L0UZMu91uppz7KKTOPXOP/qduH8wiHx
YRk9Dhe1lu8yPWVxzswDD5GQdoUxstWnatbZE7hTZDMxcPXEDVRL4J9dJzkkj2HY
boxVUjIsEeTENIPgfcxikzirCNoSX3/Hn/0ZTxB9KMA8yQsBtvy0rqQKYa4YO0Hj
AaTJr0s4ukzWkUKpib6rFaXUQtYZTrt9tQJlWahUV8t3Rzh2+fw6DYxbVzUYoHf9
B14YexErLyEZAHcSqkdEtfFd5CrYD0ENefV7HyILNk+myCZeV1PPVAR4YGnBlIUt
qvLo4shoqt4qqyfH0feZCsS0U2NwyxuLNxzSKkRzWQVqMIIFZjCCA04CCQCtoxts
6anDEzANBgkqhkiG9w0BAQsFADB1MRYwFAYDVQQDDA1GRE8gVEVTVCBST09UMSIw
IAYJKoZIhvcNAQkBFhNpbmZvQHdlYmF1dGhuLndvcmtzMRcwFQYDVQQKDA5XZWJh
dXRobiBXb3JrczELMAkGA1UEBhMCTloxETAPBgNVBAcMCFRhdXJhbmdhMB4XDTIy
MDEyMzE2MDIyOVoXDTQ5MDYxMDE2MDIyOVowdTEWMBQGA1UEAwwNRkRPIFRFU1Qg
Uk9PVDEiMCAGCSqGSIb3DQEJARYTaW5mb0B3ZWJhdXRobi53b3JrczEXMBUGA1UE
CgwOV2ViYXV0aG4gV29ya3MxCzAJBgNVBAYTAk5aMREwDwYDVQQHDAhUYXVyYW5n
YTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAN0i86TTaZOf66eWGvj5
uNBco3n6MLBKfZOByCPPYXRKUF+Wx6xVy/jcNAZYBRgwHS5IXEZi797emrJJVO1T
udgNSbfXFJCzMN31NPHuiZkmiT0bRiWgbO9zVqzvxi+Acuwm/rZe11oF+QMSxa32
OsA7krLxrDNH7xNHuZEbnZbuU7F4bjCLAyc/12CBl/J/gUYdMomWUcAvkwxa/IuP
9SbS2WQxdZot1YPSSM7T0v1iUfHeKa7Ahyf+oIbRi7AIcDwntMqnOimIN58879AD
e6kKCVBITFk9rLXWxq0fWqHGH79sIHh1A47tQ9E/hP0dCpzk4fR0kzp3Jb8mbe6y
xWIgf5X7zoHs4MdtlCiQJUJDVjwkQ4hubhcaypEzKar8o4+INk6IRcsjY+LYX8rI
XhTcXXRVemz74TMbyyVgpHlGj5Sp4Wek0o3rNdk2Bui81uHJTC/5u4lw3FZJw00V
hHI9YA2JptPzXbAKuVgcgzZLRVJDDrl+m50PVY+pK1DhM7b//SlQoM/1RC9T0s65
9J5Q383SxDY/EwM3UwWE+9mIX50hvw8x91/UvHycVxRAkUj4V1mCC1EdOlO/HvB+
kYsVEYlLp9vOTBGwhFRZVSxco7eNOJH9WArveKxrJP289ds61xMyjY8vIn07GlOQ
lMTWkRe7o8LcC5dsZTs++yc3AgMBAAEwDQYJKoZIhvcNAQELBQADggIBAF4xf6bc
z2plO5VR2xFf+cox2yWtCUfZvq1RwCWNL7OIMvueXK4ACXVSqUG/sfwRq/+HyK74
56jjOoETDzHNcv3S9+xopwILz9yr+V44VfMR6hLiHeE/CRk3pZTn5IzUYyKnh+ll
p2kGhO41ZH0Iw72T0D+8QqGpnDryPMgoyg5Z39BIu/t+kHXCHR1hm7rlgge8ho5s
8XE8q2iUQ60ymXM0D5Ah1SKpCPoivNpsN9uEWkF8bEuhhml7NoCVgl+0njBWL4jx
xJK1WtEwdWyOrqXXDGGiF3ZPjlWUo/fy+Be4HVxx9Zu23emhCX9cyeVOkjuntW9C
SNsK6Q3xyEa9YOuCRzlhCXw8+f4fMhjrEJ8c9mmJSE+4RCaGS0zTzJ5NYxpGRgVm
yWsdr9tZl2sfXWluwenQP1M4r9LfWQ3xgZGjmX0+XxFBssK7wOwQSHtvY92lx1Yh
xU93In25g+vpY2em2+z9e7TW/P9QccT5BhUs0+y1LzR3rWdQpdHiMKm2IllCHmY2
XLEtQBuggZrRSvfkOwb9pZmCeaKyogE0+hyyGBzwJaDTDNTAKpwp7T2M+t+oc7Bt
bMdmtEozort6CdRr85eEP/PtEtW+USbsp7hD5C12ZnjX/XfjR4nWsqjxwGsCJUDl
XHR9AxtbU+F9HC3QYj3lj10HjCmO3PW/5FVfhoRFoQE5AQCjGQEAUAAAAAAAAAAA
AAAAAAAAAAAZAQGDAAD2OQECUAAAAAAAAAAAAAAAAAAAAABZAXaEgi9YII2xCvTI
mxZUr5ZTyXONSfI8l3BrqNKvGG8IeSAQNS9Agi9YIMODa9WeKyQ0KuRypTRzgDKv
dAJWL16GxVYVrkcWQFmk9oMFAVkBJjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBANmSVLd/LyY8stxb8YA4BC5JfkPHMT4ZdVo+yn0VPM/AA2D799tuqla7
Ks4Nyas9tbn9CJHCw3E+T+P75bgT2djSBfh6PJHpXuEV1sLqoAoNLRPsooKBMsw8
4++sS/2hzIniIxpW5+UaiC0WmdeP6WUjxbNAU8wPPR27pCHCcOHfwLVO5kq2Fcx8
uOKc5MpFCYo3zEiU+ynytc0b9DtsBGy54Zlo1yBWvNjwV/lxeRBGAvAvSEB7cQzv
fzoK6gn4V7EbR4RuSzcB+gUqZFkDX0k87rqtbGUKWDb4eZ1EGktF0CTeQY4+LCRJ
puC6Nyui1RchAAluyUh8Xs3BVsXC0AsCAwEAAVkBAAp57LxNdre1qjcgyeCXCuCl
bsYj0Zxv2DcEE1dwtXULXEE73otsh5VwyIDc3FfRVMI8ku0+UYkphxOdv+OJc8qj
RpGLRGkIF8MsTpA0Mgbx4SZuxLbMbQkwczLYYr+wJIITUbS0PlHcG6rZCSh9w66s
xMJA+9OUTUAWqnzCObXYSjl4POjB7figqOqF7zNA3YGFLVqH+hdmYQ1uNnY6ULTz
+21NkByfgzWLn+ZKHzAkIgYWK0hMppXwvbx/dJNY8zvVCriiG6gO22DzKlZ4+LKl
FlLo3zAI3s1V8BmtppyOGMsemq+H8lTHvXoNiIoz+41CeUandZXcAQcYDpJoLvWE
RaEBOQEAoxkBAFAAAAAAAAAAAAAAAAAAAAAAGQEBgwAA9jkBAlAAAAAAAAAAAAAA
AAAAAAAAWQF2hIIvWCBKLmRS85FKk3JLio7pCcB+VpzMqGVv4NMIAF5Gi5AVrIIv
WCDDg2vVniskNCrkcqU0c4Ayr3QCVi9ehsVWFa5HFkBZpPaDBQFZASYwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC6FFoavbr3JHVacX14kfXx0Eh3EJnx
XrraOFX2knMusmFAqhGUzlSbmIwc3l8PW/8hKYdgOuSQ5J2lwj2lev+C+aqbIPMh
iiOaclbYEiiFXOfiwTeTEYGWMSKjp/85asZRwQeAnHolND8adKCwOSQViVUuMYyo
BurNJLdm7ZshwwT9RhB6+WDD61JOstQWO+vnPwxKNkTXtWM1efrKhqmCOmF5Bf0t
7MOdnzOvavZOVgqDpyzDM2tDJJBkLY9+ecGWMfd1Ye9zfXlRprBdRAvlNj6jzfeG
QyxFKzmYdNpSoHDxvQore+zF8TwyDsSMXx3qWbLruDQqSB14zKdWb3yVAgMBAAFZ
AQAmFqg3UQLnvCpQjeBifpZjd3Dpt7YGDYnkOMwP0w+8WYl72KiYRgIUcimkY+jr
pExVIpbIHkCEAgIaYXZit/zYyfetofqJ6sANFhFTpz+dmMjF3IKcUiK+ibPezdYK
+Afbn2vgQNMVOyEDfx1g2k7CS8pqa9naTsMxQp4kcbKwEwazY7dGx5579bAG8VIK
7cDw2Xkj5FgUcweTaEm9kiPufWaO4VwpOsnHCqDjYh/8TAhINQMZLabWKYREdhZX
tYYwauB8e0ltWJ2dLxEq1zWTJ5lyrOhHY8QAGZJXKHp103mD3GSCQt1l9SDfQ1Mg
4xP1GOWpS+3aQ1OkRyjVtB1LhEWhATkBAKMZAQBQAAAAAAAAAAAAAAAAAAAAABkB
AYMAAPY5AQJQAAAAAAAAAAAAAAAAAAAAAFkBdoSCL1gg9QlNcgakuBrN6lriAyNx
F/W8fJJwq74tlUefDCh3EwOCL1ggw4Nr1Z4rJDQq5HKlNHOAMq90AlYvXobFVhWu
RxZAWaT2gwUBWQEmMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2ecF
T8lQOMr2j6k0eeCrMXTMeOECeZzoc3CPJCFB7ldKovIT4mAqgl2ZxeSuMFfQl1yl
1sJ7QBx2Ngh6IEvYpMFuvDolevrQ0AcpFOzIqBRKoGhu1jOjm/1r9ZD07rftItJH
b9/mmEcOXaRAMz1Dqj5bbiBxJd1CPyTKtXGmOBReH2udksRF7DyKJ7q6SiaC/AlM
9zDQuIoyIHQPjhIJHSsb6iAFoecCrSHoRnQRbadWPoRSWSIm4Nv/OH+3jDO/1ClJ
SVfkkK/X+FgoqYY0yVg5h1YvYRgPhJaxtwD3u8s6DQzWXW/8l9LXnhODcqZTZQnD
zcW26BG3GSlJIxV/5wIDAQABWQEAo5yrSnOUy14zGT4BJEjpDrlaCFXwG6lD9yKa
Rw5aIU1RU69rQXOfKBZfQwg3RZqZQLumasx0KQEp2Lm35ffqPrQg2lHFwT5TQAsC
JKcwD3pQewTr2gsKHMc/g3lpVVO8I4ctYZGb18zL0Eb2QfQo+/omJfZJ3L4JjaHu
LrYLiNuGjU4qt6hta+YXyAp0HH+53FH94r7GbV1nrFEu0zCApyCVvfkXu7b7rmrP
4locsoSKvrfbOvmNSu60SsNztgudg9VtPyYgL5aS716WyfGzTxfitftOyz+MqI3T
jls5R/rHm0PErO6neH6Z5UoHI92Lcm1q+z4/mtLFdZDa6QdGUoRFoQE5AQCjGQEA
UAAAAAAAAAAAAAAAAAAAAAAZAQGDAAD2OQECUAAAAAAAAAAAAAAAAAAAAABZAXaE
gi9YIG92rVTICTOEIb8a5gNqLqH6DGt17ZhCp8jjdZGeHik3gi9YIMODa9WeKyQ0
KuRypTRzgDKvdAJWL16GxVYVrkcWQFmk9oMFAVkBJjCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBALOhVeD/RowabjxX+KF+64zDHFhcrT2RlZyHHrhMLHQ0
2AdfOY/TGf30FA0+o21P6LFKyKumJ6XGSBa29agBwyhKnMRLm7Ii6EAIdEItLXRV
h7Em/SAWwiMS4Z1DKtVm6T5x08BKeMB1g/c9guEFhilCz/xVmn/KbV3NsZUajQ5a
UFPWBS4yUcqVESezsV3wUxm1w47b8x9iyff1IXU3bXpCRfWti5mxdc6HJuKW/dN4
/eOHLQpvoXYgBMaF0qSkQWRAQdoHpJ6H9BSDqdb7EYM/WnPKdwvBe0fmLWYZQM3C
zkEZxEyXE8m+3mvRm9Idgj0GhWccj6+8vtWUvao8JIUCAwEAAVkBAEfLNm5PnCBu
4tJG+BZGO0DmxLQW0E67B55K1uLCTiXzgeChf7GCBYHjR37ec9W4Pje56xtXpYE6
gFzzRPrgoaZ6n8/cBWzKlcpqoWl8s1Q61SpvMNHPTylgm5efdQ8+KjmN9f4TC3ZV
s3kr2qvq1yLshufPWtDjIiQ801VL6v7RzByYnrsAe5+Pb8Lo9Wib7xIpDhPkx4Bj
36BpwNHzQcTs83ushsUPig0mgIjpESwCjhNApwT2fwBIheeJu/6CeUSPrdjTvMS/
rR+OX6GIqpXj0kdTG382HKskgZpjYVdC/gF5i87JvLCgaRKEsZsZqDDbp4gPV6SK
IRYDD8SazEaERaEBOQEAoxkBAFAAAAAAAAAAAAAAAAAAAAAAGQEBgwAA9jkBAlAA
AAAAAAAAAAAAAAAAAAAAWQF2hIIvWCAyv14Zrfbb0TAtXryfY3a8XpxVG1hfE2Mh
6IJy9ju6tYIvWCDDg2vVniskNCrkcqU0c4Ayr3QCVi9ehsVWFa5HFkBZpPaDBQFZ
ASYwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCrh7Q1pJjuFEDSodBp
98dQ8S4a4V3p1XGl79GV9+2KwOXHNvAqAUIulsGEaYEqfrc6W0HT6BsFDkr6fZ3j
eCh3Aks1+m/tFQ8R8mRw9JydN0W38zuz33dZG5POFP2xhyS2gAWNoVfp4z+JjiL7
1nGBNYovgDJC31UN2crVjkwpZbI0xVsClONe1CsHESWoQYoHn3QrwkpdzMAzCSy2
O4UwKmhK+o3qKhjqn5yZXt6c/XbkO7d0WcoVMgahua5jBQIbvhG0y1tv0qc1zWSk
uq07TVTvlhnTxZGo4oZ6qj7UmFArGrX5xRCPZ9E4Gm4ekxgcEt1fq0awkxLc89qF
nmP5AgMBAAFZAQBSuiie+aHINM8oVFILmaOYN/EemdLC8brV9MXnRJGuxEOsnmTA
4gdJCu/e9UvcC6CvE24/OdzTxawtlKp/LqyBXIcgGLKG86cYnD2w/Gn/qz75ToeF
rI3oQhGCQqeWvDkegprTuJ/Prx+mZkLW98oAvKtV9D1qfiw+OB6k8ej0awHv8h83
WaEaJe/F2O2iGlevLOcN+/IbgifQvOUl8aDWW/kBVLwbWZyme3lhWU7rC3Q0a5lI
JoyHyqyTxZq9PsyAoURbzux0at+PJxYx9DyEP4NvXe0/u8mfmzht2+gKHCrecVJm
pECfFVrs0V6FzFu4I63znNnberiMkomRTfZphEWhATkBAKMZAQBQAAAAAAAAAAAA
AAAAAAAAABkBAYMAAPY5AQJQAAAAAAAAAAAAAAAAAAAAAFkBdoSCL1ggtzFCvi5g
zvUTIX17MFp+sZGm70Ud11eWXqxcnpboYhuCL1ggw4Nr1Z4rJDQq5HKlNHOAMq90
AlYvXobFVhWuRxZAWaT2gwUBWQEmMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAvSL8lFA4BDzf93k3iE20HM//WIVLGwIytaqBVevtvCzUs6m45QlCSAt8
sAajZYjf3T2af2nBCBe5LkqcyMPc9xZD5+X63p/9zAePnX8nri0F4v7pKza7NHWW
VG8x/dZNpXWITyyejtm1WzTHYLq7LK2urm8zYgDLkjlLhNoUdi4ersbaC69eg8lA
zFAOBxnHiQHLOkPOXEQD0E4mwqFMXhur9v8KC7/w7BWWTCFWvbh3Zhl0wF3hoQYR
6SGNqOMJ73HHXFN50JXvszqlRQGV+q4kEhdfNJVzIkZMe3lJY+goxcQqYD7w3H1M
uGlyoPvIVxBPFd3lqbKk/zjlGRzKxwIDAQABWQEAXPdBlKYKjLuMVU7941b/fPIk
vLMk9cSZAQRKWgXb6pnscRXNfWZmdZQWmfyC2j56HgRmrTXY8hfroeSQq5FF3nwa
DtfI8on+XkgZ1h6phk+D/ztjcM/CGWliGs2k3na9ZxbQi4iY9fH12kMEtAS5Mr5p
n0tVCskD785eN6yVSRYmFsaBh0+6qdLGKJFzVDiLEqSHeUHhJx0o1y/72tyky+jh
B11kfpHm9KUANiq8yWL6iNO2SQeK1AYXEuqgiQTF/v1wZtHUcVKzqGhyfyoIh52Q
j2C2leNOv0Z7XXcQ9A+nbPNAhTkxEUbFOKcAKZVU43IQ2VQdjYWS2MueSUM5Gw==
-----END OWNERSHIP VOUCHER-----
-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQC9IvyUUDgEPN/3
eTeITbQcz/9YhUsbAjK1qoFV6+28LNSzqbjlCUJIC3ywBqNliN/dPZp/acEIF7ku
SpzIw9z3FkPn5fren/3MB4+dfyeuLQXi/ukrNrs0dZZUbzH91k2ldYhPLJ6O2bVb
NMdgurssra6ubzNiAMuSOUuE2hR2Lh6uxtoLr16DyUDMUA4HGceJAcs6Q85cRAPQ
TibCoUxeG6v2/woLv/DsFZZMIVa9uHdmGXTAXeGhBhHpIY2o4wnvccdcU3nQle+z
OqVFAZX6riQSF180lXMiRkx7eUlj6CjFxCpgPvDcfUy4aXKg+8hXEE8V3eWpsqT/
OOUZHMrHAgMBAAECggEANxwyrKSTLeju+ZUAcV7y1FJm/MwaDkydqgF8niSYqPQH
JjKWBWalQYjXVBMbGULAuB5zHh0aedkvxCVJedZYVEbQkomYh7XmpcSuPB4I2d+U
j4fnOQhBlA+PNhsQXf5LsaKFjUxbBxS4m1LNpYnDcElLVNhiCHRi3MCFGLjSrXxR
p7CmvEwEw5s5nUaoLMdua8TWfvZBqIKGbAUV7V8Yp8NT00Y5RZh2Sh3Cm5bbRgpd
SWq/4T3Kuh04cwX3jn+BRdWU91+53kScVQOet50Ti/t+gc1gBC4DitVczTWBl4P8
yeYEcBQml15o1tOg4InOVguq/6OlwzqxBkf27c6VAQKBgQDDvf4Scqp4qgAQVoEu
BpHGX5JLw5OLzttWkbuOl1XfVLVMyXi5QoRhQkwM/DEnCXwm6BcugoWnYhS9j2Op
WWdkj0STHlTu8hR+QS+QXnSPG3NnwCcjTF/IQnQunWF0Ps1+Iq2KlXCffITsAIb0
ntrrzafqfz9e3vzWP5Od+mCIUQKBgQD3XG4RvymP80+bmAQ2E2mA2dBrW3288Dwu
7R/rrpsHs/o31jKZ/Cbq5XhJX+YDWFsoOUM/wNM9rdZgQHPbPegvApCVxWKWepI/
BG/YJ7ThbarGpu8HqBoby259EaXzpKdsyJZg3Qe2kcX3+XXauLwry3IH/UX5j9M+
YVyZ8fBzlwKBgQCaLPgGR9MGH8DVHY26VupTOcvdaTq6EECrOzZj5cd5lRsIVFiG
c2IZyUJlp+5/NPVZH83CkIP9hz+W3248YXMSvdXhmy6C1qJVn7p7GCru3UxVGAC7
yNhYwB8K6GNuUFlDVMUkNvjyZf28dd3Wp5j/yojMJ1Yev7yedI0tDZ0jQQKBgQDc
kCFhV6gywEy6u5j9st9/UjkCkWkTwM6ZNT0iROXdv4CcqzUhkvIMv6I7IvSRBQb7
Xdv2C/UP6WLfHnlwA8p1qH7N3VwkO5UN9eHYxscFv2joi09V73GgWQvjH4pvLuFP
IajdJBlNlLwGefy5k8HN9zFtqEvt1G4TEHOmnVG/bwKBgAyRKljxd/XuAeWXSxON
LZBMU7qJUAi3yAOmhf/AX/OAFMovm8Wepc3aY6obMkWsr6HUM/5WYUzZQtyxvJV4
0V8rBhUuuB2oTgzFHNxsN3VpGG78I6Zidxr1jaeLs37AWfiFLKQ3p8Mmv8PYaMC0
NdbLfsD2J1zpCN4RRZtjAM2F
-----END PRIVATE KEY-----

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

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

• When parsing message 64 by conformance owner, following error is shown 'Error decoding EATPayload...cbor: cannot unmarshal array into Go struct field fdoshared.EATPayloadBase.-257 of type fdoshared.TO2ProveDevicePayload'
• This is resolved by converting struct to array with following line added to type EATPayloadBase struct in 'core/shared/signing.misc.go'

        _           struct{} `cbor:",toarray"`

go: github.com/fido-alliance/[email protected]: reading github.com/fido-alliance/fdo-device-implementation/go.mod at revision v0.3.1: unknown revision v0.3.1
make: *** [Makefile:21: preconfig_conformance_server] Error 1

PS: Is it due to some proxy issue?

Msg62 tests (FIDO_DOT_62_GETOVNEXT_BAD_INDEX, FIDO_DOT_62_POSITIVE) result in ("throw panic") error. See line 48 do.to2.62.execute.go, “nextEntry” can be nil.

Suggested Solution;

diff --git a/running.ctx.go b/running.ctx.go
--- a/running.ctx.go
+++ b/running.ctx.go
@@ -8,8 +8,8 @@ import (
 const APIKEY_RESULT_SUBMISSION = "010203040506"
 const APIKEY_BUILDS_URL = "https://builds.fidoalliance.org"
 const FDO_SERVICE_URL = "http://fdo.tools"
-const TOOLS_MODE = fdoshared.CFG_MODE_ONLINE
-const FDO_DEV_ENV_DEFAULT = tools.ENV_DEV
+const TOOLS_MODE = fdoshared.CFG_MODE_ONPREM
+const FDO_DEV_ENV_DEFAULT = tools.ENV_PROD

POST /api/dot/execute (line 380 do.api.go DOTestMgmtAPI.Execute()): none test will be executed due to input DO testID is checked by RVTestInsts (RV test list).

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

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

• Client fails to verify signature of COSE Payload sent in message 65 by conformance owner. Screenshot is attached for reference.
• Upon debugging, following is observed.

  • COSE Signature is generated by using current owner's private key rather than Owner2's private key (whose public key is sent in COSE payload of message 65) which is not accordance with spec as mentioned at https://tinyurl.com/cosesignmsg65

  • Code snippet on conformance owner w.r.t same is as follows and from https://github.com/fido-alliance/fdo-fido-conformance-server/blob/main/core/do/to2/listener-to2-64-ProveDevice.go#L16

    setupDevice, err := fdoshared.GenerateCoseSignature(setupDevicePayloadBytes, fdoshared.ProtectedHeader{}, 
    fdoshared.UnprotectedHeader{}, **privateKeyInst**, session.SignatureType)
    privateKeyInst, err := fdoshared.ExtractPrivateKey(session.PrivateKeyDER)
    

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

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

• When building code on Linux, following error is observed

GOOS=windows go build -o ./bin//fdo-fido-conformance-server-windows.exe
#github.com/fido-alliance/fdo-fido-conformance-server/core/shared
core/shared/enc.crypto.go:492:2: undefined: log
make: *** [Makefile:28: compile_win] Error 1

• Upon commenting the above line at https://github.com/fido-alliance/fdo-fido-conformance-server/blob/main/core/shared/enc.crypto.go#L492 , getting following error.

GOOS=windows go build -o ./bin//fdo-fido-conformance-server-windows.exe
#github.com/fido-alliance/fdo-fido-conformance-server/core/shared
core/shared/enc.crypto.go:9:2: "encoding/hex" imported and not used
make: *** [Makefile:28: compile_win] Error 1

• The error is resolved by commenting the above line https://github.com/fido-alliance/fdo-fido-conformance-server/blob/main/core/shared/enc.crypto.go#L9

Hi @herrjemand

After building and starting the FIDO Conformance Server in onprem mode, when uploading a voucher of EPID device, server returns "NetworkError" in GUI and "runtime error: invalid memory address or nil pointer dereference" in logs.

Log, Voucher and Screenshot are attached for reference.

fdo_conformance_server_epid_client_voucher_upload_failure_logs.txt
dal_interop_voucher_rsa2048.txt

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

2023/06/21 00:50:38 --- 20 FIDO_RVT_21_CHECK_RESP. Sending buffer 80
2023/06/21 00:50:38 --- 20 FIDO_RVT_21_CHECK_RESP. HTTP 200 Receiving buffer 8150e0de3de695950080a488482ec36718d4 

2023/06/21 00:50:38 http: panic serving [::1]:62756: runtime error: invalid memory address or nil pointer dereference
goroutine 122 [running]:
net/http.(*conn).serve.func1()
        /Users/thaodtp/sdk/go1.19.5/src/net/http/server.go:1850 +0xb0
panic({0x102c27c40, 0x1030baeb0})
        /Users/thaodtp/sdk/go1.19.5/src/runtime/panic.go:890 +0x258
github.com/fido-alliance/fdo-fido-conformance-server/core/do/to0.(*To0Requestor).confCheckResponse(0x102a8b9ef?, {0x14002a2e000, 0x12, 0x200}, {0x102a8b9ef, 0x16}, 0x102a8b914?)

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

• Panic error with test case FIDO_RVT_21_CHECK_RESP and FIDO_RVT_23_CHECK_RESP
• I found wrong if conditions in https://github.com/fido-alliance/fdo-fido-conformance-server/blob/650e1441ed6239e72ecd94d6f1d68fe8db246e16/core/do/to0/common.go#L80 and https://github.com/fido-alliance/fdo-fido-conformance-server/blob/650e1441ed6239e72ecd94d6f1d68fe8db246e16/core/do/to0/common.go#L94

There is no mention of this test case:
Test case FIDO_RVT_23_CHECK_RESP

Requested support of both ECDSA P384 and P256.

To simplify issue resolution process, please provide network logs, and or test voucher.
VinCSS owner server log:

2023-09-27T06:30:05.838Z [OWNER_SERVER] f1d0fd009d2044ba830159ac3ff5f471 info: TO2.GetOVNexEntry62 Request Body: 8118dd 
2023-09-27T06:30:05.845Z [OWNER_SERVER] f1d0fd009d2044ba830159ac3ff5f471 error: Invalid ovEntryNum
Error: Invalid ovEntryNum
    at /Users/thaodtp/Documents/work/projects/FDO/1.1/owner-sdk/dist/owner-sdk/src/routes/protocol/TO2.js:296:25
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) 
2023-09-27T06:30:05.845Z [OWNER_SERVER] f1d0fd009d2044ba830159ac3ff5f471 info: TO2.OVNexEntry63 Response Body: 851865183e764661696c656420746f20676574204f56456e747279217818323032332d30392d32375430363a33303a30352e3834355a00 

fido-conformance-server result:

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

• Server detected invalid data but failed test
• Observed after debugging:
  The testId should also be reassigned to selectedTestId for case FIDO_DOT_62_GETOVNEXT_BAD_INDEX
  https://github.com/fido-alliance/fdo-fido-conformance-server/blob/6d23facb23ff9012ab77fc8b96aeba015f16d683/testexec/do.to2.62.execute.go#L104
  because function GetOVNextEntry62 does not expect any error for NULL_TEST
  https://github.com/fido-alliance/fdo-fido-conformance-server/blob/6d23facb23ff9012ab77fc8b96aeba015f16d683/testexec/do.to2.62.execute.go#L110

Test case responds with error before sending a request to RV server:
FIDO_TEST_VOUCHER_BAD_EMPTY_ENTRIES

Message 64 KeyExhange KDF has Little-Endian lengths while spec says it should be Big-Endian

see:
https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-PS-v1.1-20220419/FIDO-Device-Onboard-PS-v1.1-20220419.html#kdf

Type 64 [h'A10126', {-259: h'856E2AC562994671B7361E9EA82664C7'}, h'A30A503F3E4B2260AE63961EFFB8447A8F15C419010051016287C0198BCB4715A57969CAF09C6E703901008158560020DA9C8BC871DBECC44C6F7BB6A13D6C6B6C273D21C30424DC7C368126CFD598EF002047D6DC38BB2B451CD1E8C3C05591B21CEF84734B021A735B62F359211FF8FFFF00101270F7110E9B72789BBA38606EC64E62', h'8D46B11208338892D3055367818E49E219459DD15D1226FBD805EB4AFF68F5C862909EE5250B57A32B59633BCF2CFD0998E1218FEAE8E40B96EBB068845CDE83']

Expanding the cbor for the payload h'8D46....

{10: h'3F3E4B2260AE63961EFFB8447A8F15C4', 256: h'016287C0198BCB4715A57969CAF09C6E70', -257: [h'0020DA9C8BC871DBECC44C6F7BB6A13D6C6B6C273D21C30424DC7C368126CFD598EF002047D6DC38BB2B451CD1E8C3C05591B21CEF84734B021A735B62F359211FF8FFFF00101270F7110E9B72789BBA38606EC64E62']}

the first 2 bytes of the KDF is [h'0020 this should be 32 byte length value in Big-Endian - However, 0020 is 8192 size in Little-Endian which results in the conformance server unable to marshal.

this results in:

Type 255 [100, 64, "Error decoding EATPayload...cbor: cannot unmarshal array into Go struct field fdoshared.EATPayloadBase.-257 of type fdoshared.TO2ProveDevicePayload (cannot decode CBOR array to struct without toarray option)", 1686237155, 5159311567795824291]

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

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

• COSESign1 Tag '18' is missing from message 33 sent by conformance RV server.

  Expected Message Begin with:
  d28444*
  Actual/Observed Message Begin with:
  844*

  Missing d2 in CBOR / 18 in Diagnostic tag from message. Observed same in message 61.

• COSEEncrypt Tag '16' is missing from message 65 sent by conformance owner server.

  Expected Message Begin with:
  d08343*
  Actual/Observed Message Begin with:
  8343*

  Missing d0 in CBOR / 16 in Diagnostic tag from message.

• This is related to https://github.com/fido-alliance/fdo-fido-conformance-server/issues/8

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

2023/09/10 20:40:59 Generate vouchers. Error generating voucher f1d0fd00-8b4e-4a80-801d-8c667eb11a8d for test FIDO_TEST_VOUCHER_HEADER_BAD_PROT_VERSION. Error generating OVEntry. error generating ES256 cose signature. Could not cast privKey instance to ECDSA PrivateKey
2023/09/10 20:40:59 Responding error: Failed to generate vouchers. Internal server error. HTTP code 500

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

• Internal server error response when calling API api/dot/create.
• Type of input prevEntryPriKey and prevEntrySgType are conflict here:
  https://github.com/fido-alliance/fdo-fido-conformance-server/blob/7e3793a69557037fe3463fba23fac34d745039df/core/device/genvoucher.go#L193

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

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

• The voucher is received from API /api/dot/vouchers/{uuid}.
• Verify the 5th OVEntry failed due to the odd length of the signature, it cannot be divided into 2 parts r and s with equal length or there is no clue to determine which part has a longer length.
• The failed OVEntry data:

        [
            h'a10126',
            {},
            h'84822f58200004fd9bbb225542373f8b3933c441e9d8d747f722ca631f28e541adbf7c0719822f5820108ae9affcb0c66a40126be139890073544b67f301d7b758b1a5429aca2aaed7f6830a01585b3059301306072a8648ce3d020106082a8648ce3d0301070342000465e23c98fd12d88463d4749e7fe3d3d3b2dd97797b84115240d7613183b5cc6749b658302f69e08fdf69c085aee039b4446184019e595725ad2e8e9ad3f6df37',
            h'07fe3a27f5a3edffc7aaa3c9d5e74c5e1075dfee49fb795f3ea4ac314f83c6f1b054731ab4e8c9b9aae2d86469d1cff7cbe27cb5838ad30faee8720f0e5052',
        ]

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

What part of the spec are you testing?

• Rendezvous Server
• Device Onboarding Service
• Device Implementation

What protocol are having issue with?

• TO0
• TO1
• TO2

Issue description

• KDF in counter mode implemented at https://github.com/fido-alliance/fdo-fido-conformance-server/blob/main/core/shared/enc.crypto.go#L199 has the loop from "0 to n-1" but it should be from "1 to n" according to https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-108.pdf and section 5.1
• The above publication is mentioned in spec https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-PS-v1.1-20220419/FIDO-Device-Onboard-PS-v1.1-20220419.html#kdf and screenshot from publication is attached for reference.

FDO implementations are built to share the public key when extending a ownership voucher and not to share the private key. Extra work needs to be done by implementations to extract the private just for the conformance tool. Moreover, some implementations, for security reasons may not be able to extract the private key.

For LF Edge we have an API call were we can get the public key for any Owner. This api returns the public key is in PEM format. The public key is return as an X509 certificate chain. e.g ----BEGIN CERTIFICATE --- ---END CERTIFICATE--. You can then append this to the PEM version of the VOUCHER. When loading a voucher with a certificate chain attached you then use your private key to sign the public key and add it to the OV Entries. You can now return the extended voucher in PEM format.

The reason we use the certificate instead of the public key encoding is because the X5Chain encoding is a part of the base profile so all owners should support it. The public key can be obtained from the public certificate.

An example if this flow is document on LF Edge https://github.com/secure-device-onboard/pri-fidoiot/blob/master/README.md
See section Creating Ownership Vouchers using Individual Component Demos

GET https://host.docker.internal:8043/api/v1/certificate?alias=SECP256R1

Response body will be the Owner's certificate in PEM format

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
For EC384 based vouchers use the following API:

GET https://host.docker.internal:8043/api/v1/certificate?alias=SECP384R1

Result body will be the owners certificate in PEM format

REFER for the other supported attestation type.

Next, collect the serial number of the last manufactured voucher

GET https://host.docker.internal:8038/api/v1/deviceinfo/{seconds} (or http://host.docker.internal:8039/api/v1/deviceinfo/100000)

For authorization, users can use DIGEST AUTH with "apiUser" and api_password as defined in the manufacturer's service.env or can use CLIENT-CERT AUTH (mTLS).

Result will contain the device info

[{"serial_no":"43FF320A","timestamp":"2022-02-18 21:50:21.838","uuid":"24275cd7-f9f5-4d34-a2a5-e233ac38db6c"}]

Post the PEM Certificate obtained form the owner to the manufacturer to get the ownership voucher transferred to the owner.
POST https://host.docker.internal:8038/api/v1/mfg/vouchers/43FF320A(or http://host.docker.internal:8039a/pi/v1/mfg/vouchers/43FF320A)

POST content-type text\plain

In the request body add owner's certificate.

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
Response will contain the ownership voucher

-----BEGIN OWNERSHIP VOUCHER-----
-----END OWNERSHIP VOUCHER-----

Hi @herrjemand

After building and starting the FIDO Conformance Server in onprem mode, server returns following errors when trying to verify device signature during message 32 in TO1, for different clients.

• "Error verifying certificate chain! x509: certificate signed by unknown authority" for a client implemented in JAVA
• "Error decoding leaf certificate. x509: failed to unmarshal elliptic curve point" for a client implemented in C.

This is observed for both attestation types of ECDSA256 and ECDSA384.

Logs, vouchers for such errors are attached from both FIDO Conformance Server and from FDO clients.

csdk_client_to1_msg32_fail_logs.txt
fdo_conformance_server_csdk_client_to1_msg32_fail_logs.txt
fdo_conformance_server_java_client_to1_msg32_fail_logs.txt
java_client_to1_msg32_fail_logs.txt
csdk_interop_voucher_256.txt
csdk_interop_voucher_384.txt
java_client_interop_voucher_256.txt
java_client_interop_voucher_384.txt