Hi Andrej,

The v19.08_TBSA0.9 version of psa-arch test suite is aligned with current TF-M master.

 

I have executed the test suite and found that unfortunately the attestation test suite is currently broken:

• It was introduced by the QCBOR library update in https://review.trustedfirmware.org/c/trusted-firmware-m/+/2679/6
• Currently there is a misalignment between psa-arch and tf-m in terms of QCBOR version. psa-arch still relies on older version of QCBOR.
• The version mismatch lead some parsing error in CBOR that is the reason why the test suite is failing.
• Other issue is that v19.08_TBSA0.9 version of psa-arch mandates the key-id in unprotected COSE header, however that field is optional according to the standard. In TF-M the inclusion of key-id was  bind to ATTEST_INCLUDE_TEST_CODE_AND_KEY_ID, which was split to two compile time switch (https://review.trustedfirmware.org/c/trusted-firmware-m/+/3147) ATTEST_INCLUDE_COSE_KEY_ID and ATTEST_ INCLUDE_TEST_CODE.

 

Way forward:

• I let the psa-arch test team to update QCBOR.
• Fix will be put on master, but currently the tip of the psa-arch master is not aligned with TF-M master. They  are supports different PSA API versions.
• In TF-M there is a branch where the PSA API update is happening. This branch is intended to be merged to master in Q1.

 

Tamas

 

 

Hi Tamas

 

> Could you tell what was the values of these compile time switches in your test?

 

For the previous TFM, we have used INCLUDE_TEST_CODE_AND_KEY_ID. For the current TFM it was renamed to INCLUDE_TEST_CODE.

Other parameters are new, so I have tried different combinations of these parameters, but the PSA Test-Suite Attestation is still failed.

 

> Further do you implemented the boot data sharing between bootloader and runtime firmware?

 

It’s used the TFM template code without change from tfm\platform\ext\common\template

 

> Do you sign SPE and NPSE images together or they are signed separately?

 

We do not use the secondary bootloader so far, so image is not signed.

 

As the Attestation Regression tests are passed. It’s good to know what combination of parameters have to be used to generate the same token as it was generated by the older TFM and accepted by the PSA Test Suite (last commit on master branch). Or the PSA Test Suite is obsolete.

 

Thank you,

Andrej

 

 

Hi Andrej,

 

Could you tell what was the values of these compile time switches in your test? I assume you did the test on NXP board. Further do you implemented the boot data sharing between bootloader and runtime firmware? Do you sign SPE and NPSE images together or they are signed separately?

 

Tamas

 

 

Hello,

 

After upgrade to the latest version of TFM, the Attestation test from the PSA Test Suite is failed (but the TFM Attestation regression tests are passed).

 

What combination of configuration parameters must be used (INCLUDE_OPTIONAL_CLAIMS, INCLUDE_TEST_CODE, INCLUDE_COSE_KEY_ID, BOOT_DATA_AVAILABLE) to follow PSA Test Suite expectations?

What commit of the PSA Test-suite must be used for the latest TFM? We are still on the 2019-07-25 (c80681ed7c7f3e2cbf02ded1ef2464ba2ca7ccd5) commit, which was OK with 2-month old TFM.

Is the PSA Test Suite Attestation test valid for the latest TFM?

 

Thank you,

Andrej Butok

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.