Hi,
Per https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-07 (which is latest spec I can find for profile 1 token):
The Certification Reference claim is used to link the class of chip and PSA RoT of the attesting device to an associated entry in the PSA Certification database. It MUST be represented as a thirteen-digit [EAN-13<https://www.gs1.org/standards/barcodes/ean-upc>].¶<https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-07#se…>
Linking to the PSA Certification entry can still be achieved if this claim is not present in the token by making an association at a Verifier between the reference value and other token claim values - for example, the Implementation ID.¶<https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-07#se…>
psa-certification-reference-type = text .regexp "[0-9]{13}"
psa-certification-reference = (
? psa-certification-reference-key =>
psa-certification-reference-type
)
But in the tf-m-tools repo:
iat-verifier\iatverifier\psa_iot_profile1_token_claims.py it checks for PSA 2.0 profile HW version which is EAN-13 + 5.
class HardwareVersionClaim(AttestationClaim):
"""Class representing a PSA Attestation Token Hardware version claim"""
def verify(self, token_item):
self._check_type('HARDWARE_VERSION', token_item.value, str)
value_len = len(token_item.value)
expected_len = 19 # 'EAN13-Version' 13 + 1 + 5. e.g.:0604565272829-10010
if len(token_item.value) != expected_len:
msg = 'Invalid HARDWARE_VERSION length; must be {} characters, found {} characters'
self.verifier.error(msg.format(expected_len, value_len))
for idx, character in enumerate(token_item.value):
if character not in string.digits:
if idx != 13 or character not in '-':
msg = 'Invalid character {} at position {}'
self.verifier.error(msg.format(character, idx+1))
It seems like this was changed 3yrs ago:
SHA-1: 8ac8d17d15353c7f7933ae8065646946ae47f993
* Fix HW Version claim expected length
www.psacertified.org issuing HW versions of format '[0-9]{13}-[0-9]{5}'.
It is called 'certification reference':
https://www.psacertified.org/certified-products/
Signed-off-by: Tamas Ban <tamas.ban(a)arm.com>
Change-Id: I0417e1ce76896f1128864676f29a4314b3fd1fb8
When I run "check_iat" script, I get these errors:
./scripts/check_iat -k public_key.pem -K -p -t PSA-IoT-Profile1-token cc27xx.cbor
ERROR:iat-verifiers:Invalid HARDWARE_VERSION length; must be 19 characters, found 13 characters
ERROR:iat-verifiers:Invalid character i at position 1
ERROR:iat-verifiers:Invalid character r at position 2
ERROR:iat-verifiers:Invalid character m at position 3
ERROR:iat-verifiers:Invalid character w at position 4
ERROR:iat-verifiers:Invalid character a at position 5
ERROR:iat-verifiers:Invalid character r at position 6
ERROR:iat-verifiers:Invalid character e at position 7
ERROR:iat-verifiers:Invalid character . at position 8
ERROR:iat-verifiers:Invalid character o at position 9
ERROR:iat-verifiers:Invalid character r at position 10
ERROR:iat-verifiers:Invalid character g at position 11
ERROR:iat-verifiers:Invalid character at position 12
ERROR:iat-verifiers:Invalid character at position 13
Is the verifier tool incorrect or should I be following "EAN13-Version' 13 + 1 + 5" even for profile 1 token?
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
Hi everyone,
We would like to propose the deprecation of the following two TF-M platforms:
1. Musca-S1 (Arm)
Musca-S1 was one of the earliest platforms featuring an Armv8-M silicon implementation, providing a valuable real hardware target for initial development. However, with the availability of many modern hardware platforms, Musca-S1 is no longer essential and can be deprecated.
2. BL5340_dvk_cpuapp (Laird Connectivity)
This platform was initially proposed for deprecation at the end of 2023. Support activity has been minimal, and it closely mirrors the already-supported nRF5340 platform from Nordic Semiconductor.
Please share any comments or objections regarding this proposal. If no major concerns are raised by the end of June 2025, we plan to mark these platforms as deprecated and proceed with their removal from the codebase.
Thank you,
Anton
Hi team,
Can you help me with this statement that "Currently, the TF-M Secure Storage service implements PSA Protected Storage version 1.0-beta2. There is not yet an implementation of PSA Internal Trusted Storage in TF-M."
Our SoC does NOT have internal flash, but we have OTP where we keep the confidential data. Can you help how to handle this ITS situation. I wonder if PSA level-2 certification requires ITS? Thanks
BR
Michael
Hello,
The next Technical Forum is planned on Thursday, Sep 12 at 7:00-8:00 UTC (East time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi Antonio,
I figured it out. I wasn’t including secure_fw/partitions/crypto/tfm_mbedcrypto_include.h properly so attestation was linking directly to the PSA Crypto function implementation instead of the client interface. I’m surprised it did not complain about a symbol collision without having the mbedcrypto__ prefix. The PSA crypto API implementation source files were “PRIVATE” so I’m not sure how attestation was able to link to them at all.
Regards,
Brian
From: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>
Sent: Thursday, May 8, 2025 9:42 AM
To: Quach, Brian <brian(a)ti.com>; Mudit Sharma <Mudit.Sharma(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Subject: Re: [EXTERNAL] Re: [TF-M] Attestation calls to PSA Crypto
Hi Brian, we can't reproduce exactly that mixture easily but I don't think that should affect how the partition code gets linked to the interface code. Regardless of the type of partition (SFN/IPC) the linking of the interfaces should remain
ZjQcmQRYFpfptBannerStart
This message was sent from outside of Texas Instruments.
Do not click links or open attachments unless you recognize the source of this email and know the content is safe.
Report Suspicious <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/G3vK!tvdkk1ajei0aJagkHNPjPb…>
ZjQcmQRYFpfptBannerEnd
Hi Brian,
we can't reproduce exactly that mixture easily but I don't think that should affect how the partition code gets linked to the interface code. Regardless of the type of partition (SFN/IPC) the linking of the interfaces should remain the same, i.e. your setup should not be able to link at all directly with the crypto library that provides the PSA Crypto APIs.
Thanks, Antonio
________________________________
From: Quach, Brian
Sent: Thursday, May 08, 2025 15:29
To: Mudit Sharma; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: Antonio De Angelis
Subject: RE: [EXTERNAL] Re: [TF-M] Attestation calls to PSA Crypto
Hi Mudit,
Thanks for checking. Is the build you tested using the same mix of SFN and IPC as I was?
Regards,
Brian
From: Mudit Sharma <mudit.sharma(a)arm.com<mailto:mudit.sharma@arm.com>>
Sent: Thursday, May 8, 2025 5:21 AM
To: Quach, Brian <brian(a)ti.com<mailto:brian@ti.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: Antonio.DeAngelis(a)arm.com<mailto:Antonio.DeAngelis@arm.com>
Subject: [EXTERNAL] Re: [TF-M] Attestation calls to PSA Crypto
Hi Brian, We built secure world TF-M test for AN521 platform: ``` cmake -S spe -B build_spe -DTFM_PLATFORM=arm/mps2/an521 \ -DCONFIG_TFM_SOURCE_PATH="$TFM_SOURCE_DIR" \ -DCMAKE_BUILD_TYPE=Debug \ -DTEST_S=ON -DTEST_NS=OFF ``` We ran this test
ZjQcmQRYFpfptBannerStart
This message was sent from outside of Texas Instruments.
Do not click links or open attachments unless you recognize the source of this email and know the content is safe.
Report Suspicious <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/G3vK!uXdq_RaPN01xCsXEHfkD30…>
ZjQcmQRYFpfptBannerEnd
Hi Brian,
We built secure world TF-M test for AN521 platform:
```
cmake -S spe -B build_spe -DTFM_PLATFORM=arm/mps2/an521 \
-DCONFIG_TFM_SOURCE_PATH="$TFM_SOURCE_DIR" \
-DCMAKE_BUILD_TYPE=Debug \
-DTEST_S=ON -DTEST_NS=OFF
```
We ran this test on a FVP model and stepped through
`tfm_attest_test_1001`. Please find attached a screenshot of the call stack.
Function in `attest_core` (in the Attestation partition) invokes
function in the `tfm_crypto_api`. This request is routed by the Secure
Partition Manager (SPM) into the Crypto partition via `psa_call()`.
On 5/6/25 00:33, Quach, Brian wrote:
>
> Is my configuration valid? How should it work?
>
Any time you call a function across partitions, regardless of isolation
level, the SPM forwards it to the target partition using `psa_call()`
>
Best regards,
Mudit Sharma
Hi,
Assuming Isolation Level 1 and IPC backend, I'm using Attestation partition with SFN model with stateless handle and a custom Crypto partition using IPC model with stateless handle. My custom Crypto partition includes a PSA crypto wrapper which defines all the PSA Crypto APIs to use HW crypto. We used IPC since we want to be able to support isolation level 2-3 in the future.
When the Attestation partition make calls to PSA Crypto (psa_hash_setup for example), should it use a psa_call() to the Crypto Partition? That is what I had expected since the crypto partition is IPC model but I'm seeing it call the PSA crypto code directly. Also, it appears to provide client side psa_hash_operation_t directly to the psa_hash_setup which is expecting the full operation struct.
Is my configuration valid? How should it work?
[ 52%] Building C object secure_fw/partitions/partitions/_1/crypto_sp/CMakeFiles/ti_tfm_psa_rot_partition_crypto.dir/home/brian/gits/secure_drivers/source/third_party/psa_crypto/psa_crypto_wrapper.o
[ 53%] Building C object secure_fw/partitions/partitions/_1/crypto_sp/CMakeFiles/ti_tfm_psa_rot_partition_crypto.dir/__/__/__/__/__/generated/secure_fw/partitions/ti_crypto/auto_generated/intermedia_crypto_sp.o
[ 53%] Building C object secure_fw/partitions/partitions/_1/crypto_sp/CMakeFiles/ti_tfm_psa_rot_partition_crypto.dir/home/brian/gits/spe/source/third_party/tfm/platform/ext/common/syscalls_stub.o
[ 54%] Linking C static library libti_tfm_psa_rot_partition_crypto.a
[ 54%] Built target ti_tfm_psa_rot_partition_crypto
[ 54%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/tfm_attest.o
[ 55%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/tfm_attest_req_mngr.o
[ 55%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_core.o
[ 56%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_boot_data.o
[ 56%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_asymmetric_key.o
[ 57%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_token_encode.o
[ 57%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/initial_attestation/auto_generated/intermedia_tfm_initial_attestation.o
[ 58%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_sign1_sign.o
[ 58%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_sign1_verify.o
[ 59%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_util.o
[ 59%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_parameters.o
[ 60%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.o
[ 60%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/platform/ext/common/syscalls_stub.o
[ 61%] Linking C static library libtfm_psa_rot_partition_attestation.a
[ 61%] Built target tfm_psa_rot_partition_attestation
[ 61%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/__/platform/ext/common/syscalls_stub.o
[ 62%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/crt_memcmp.o
[ 62%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/crt_memmove.o
[ 63%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/crt_strnlen.o
[ 63%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/service_api.o
[ 64%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/shared/crt_memcpy.o
[ 64%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/shared/crt_memset.o
[ 65%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/sprt_partition_metadata_indicator.o
[ 65%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/sfn_common_thread.o
[ 66%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/psa_api_ipc.o
[ 66%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/spm/core/psa_interface_thread_fn_call.o
[ 67%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/__/interface/src/tfm_attest_api.o
[ 67%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/__/interface/src/tfm_psa_call.o
[ 68%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/__/interface/src/tfm_crypto_api.o
[ 68%] Linking C static library libtfm_sprt.a
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
