Thanks for the patch. Would you be able to open a review for it on review.trustedfirmware.org? It's easier to get it analysed and get feedback that way

Thanks, Antonio

From: Augusto Cesare Zanellato via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Monday, February 10, 2025 22:50
To: Tamas Ban <Tamas.Ban@arm.com>
Cc: tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Re: Clarification on boot seed
 
Hi,

Note that this identifies the PSA RoT implementation, not a particular instance. To uniquely identify an instance, see the Instance ID claim

https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-24.html#name-implementation-id

It is more kind a soc-family-id.\

Thanks for the clarification, I only had read the older 7th draft where it wasn't so clear.
Regarding boot seed: attached to this email there's a patch I've been testing locally.
Let me know your thoughts, specifically about whether extending the boot seed by sha256 hashing is appropriate and whether using the pico sdk sha256 is ok or if it should be using MbedTLS.

Regards,
Augusto


Il giorno lun 10 feb 2025 alle ore 11:29 Tamas Ban <Tamas.Ban@arm.com> ha scritto:

Hi,

 

> shouldn't it be a value changing on each boot?
Yes, you are right. Boot seed is about the distinguish boot cycles. It should be a random number per boot cycle.

https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-24.html#name-boot-seed

 

> implementation id, couldn't it be read from the board id (pico_get_unique_board_id)?

Note that this identifies the PSA RoT implementation, not a particular instance. To uniquely identify an instance, see the Instance ID claim

https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-24.html#name-implementation-id

It is more kind a soc-family-id.

 

Regards,

Tamas

 

From: David Hazi via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Saturday, February 8, 2025 10:52 AM
To: Augusto Cesare Zanellato <augustocesare.zanellato@studenti.unipd.it>; tf-m@lists.trustedfirmware.org
Subject: [TF-M] Re: Clarification on boot seed

 

Hi,

 

TF-M has got a default OTP map and template files which using the default map. This makes the development and testing easier. Each platform can use these as a starting point and implement the platform specific parts with the help of these.

 

You can use the functions provided by the pico SDK, in this case you have to change the platform functions.

In your case:

  • copy the “platform/ext/common/template/attest_hal.c” file to the platform’s directory
  • add the copied “attest_hal.c“ file’s path to the platform_s cmake target, you can use the “platform/ext/target/arm/mps4/common/common.cmake” as an example
  • Change the “tfm_plat_get_boot_seed” and “tfm_plat_get_implementation_id” functions in the new “attest_hal.c“ file.
  • build with -DPLATFORM_DEFAULT_ATTEST_HAL=OFF or add this cmake variable to the platform’s config.cmake file

 

If you can, please upstream the changes, we welcome all contributions.

 

Regards,

Dávid

 

From: Augusto Cesare Zanellato via TF-M <tf-m@lists.trustedfirmware.org>
Sent: 07 February 2025 15:48
To:
tf-m@lists.trustedfirmware.org
Subject: [TF-M] Clarification on boot seed

 

Hi,
I'm doing a PoC on initial attestation for an university project using a RP2350 board and I'm not really understanding why boot seed is stored in OTP, shouldn't it be a value changing on each boot?
Pico SDK conveniently exposes one via a ROM function (rom_get_boot_random).

Another similar doubt I have is w.r.t. implementation id, couldn't it be read from the board id (pico_get_unique_board_id)? Board id is factory programmed in otp so it should actually be unique.

Best Regards,

Augusto Zanellato