Hi.
I hope you are doing well.
I haven't received any responses yet.
If possible, could you please share any basic guidelines or documentation references?
Thanks
Best Regards
Phillip ----- 원본 메시지 -----
보낸 사람: 김종혁 <phillip3420(a)adtek.co.kr>
받는 사람: tf-m(a)lists.trustedfirmware.org
날짜: 2026-10-22 10:12:52
제목: [tf-m_v2.2.2] ROTPK revocation and updates question
Hello.
I'm developing the RSE Firmware based on neoverse rdv3r1 and tf-m version 2.2.2
In TF-M v2.2.2, I found code for ROTPK revocation and updates.
I think this code is intended for scenarios where keys,
such as the private key corresponding to a ROTPK, need to be replaced.
It seems that revoking or updating a ROTPK is authorized by verifying a signature generated with the private key corresponding to that ROTPK.
If this understanding is correct,
I would expect an additional authorization step to take place before TF-M processes the request.
For example, if changing ROTPK “A” can be authorized
by a signature generated with its corresponding private key, “A_private,”
this seems potentially risky from a security perspective.
Am I understanding this correctly, or am I missing something?
If an additional authorization step is expected before the ROTPK revocation or update procedure in TF-M,
could you provide an example of what that step would involve?
Thanks
Best Regards
Phillip
Hello.
I'm developing the RSE Firmware based on neoverse rdv3r1 and tf-m version 2.2.2
In TF-M v2.2.2, I found code for ROTPK revocation and updates.
I think this code is intended for scenarios where keys,
such as the private key corresponding to a ROTPK, need to be replaced.
It seems that revoking or updating a ROTPK is authorized by verifying a signature generated with the private key corresponding to that ROTPK.
If this understanding is correct,
I would expect an additional authorization step to take place before TF-M processes the request.
For example, if changing ROTPK “A” can be authorized
by a signature generated with its corresponding private key, “A_private,”
this seems potentially risky from a security perspective.
Am I understanding this correctly, or am I missing something?
If an additional authorization step is expected before the ROTPK revocation or update procedure in TF-M,
could you provide an example of what that step would involve?
Thanks
Best Regards
Phillip
Hello.
I'm developing the RSE Firmware based on neoverse rdv3r1 and tf-m version 2.2.2
In TF-M v2.2.2, I found code for ROTPK revocation and updates.
I think this code is intended for scenarios where keys,
such as the private key corresponding to a ROTPK, need to be replaced.
It seems that revoking or updating a ROTPK is authorized by verifying a signature generated with the private key corresponding to that ROTPK.
If this understanding is correct,
I would expect an additional authorization step to take place before TF-M processes the request.
For example, if changing ROTPK “A” can be authorized
by a signature generated with its corresponding private key, “A_private,”
this seems potentially risky from a security perspective.
Am I understanding this correctly, or am I missing something?
If an additional authorization step is expected before the ROTPK revocation or update procedure in TF-M,
could you provide an example of what that step would involve?
Thanks
Best Regards
Phillip
Hello,
This email is to notify you of 3 new security vulnerabilities affecting Trusted Firmware-M (TF-M).
1. Pre-auth OOB write in RSE SFCP handshake hijacks BL1 boot-ROM control flow
Some RSE configurations place nodes in a trusted subnet whose links are initially untrusted, so the SFCP implementation performs a handshake before normal traffic is protected with the negotiated session key.
Advisory: https://trustedfirmware-m.readthedocs.io/en/latest/security/security_adviso…
Fix: https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m/…
1. Plaintext SFCP packet on RSE returns delegated-attestation private key
The platform expects that the RSEs in the system are members of the trusted subnet and therefore use encrypted communications. This is not enforced on the "non-interrupt driven" receive code path for sfcp_receive_msg. Therefore, external RSEs in the system could send unencrypted packets which would be successfully received.
Advisory: https://trustedfirmware-m.readthedocs.io/en/latest/security/security_adviso…
Fix: https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m/…
1. OOB flash write in Corstone-1000 update bricks the secure enclave
The Corstone-1000 FWU bootloader backend writes update payload blocks directly to flash through ProgramData().
The write address is calculated from the target image partition base plus the number of image bytes already received. Without validating this calculated range against the flash address space and the selected update partition size, a sequence of FWU writes can extend past the end of the intended partition.
Advisory: https://trustedfirmware-m.readthedocs.io/en/latest/security/security_adviso…
Fix: https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m/…
If you have any questions or comments, please let us know.
Best regards,
Anton
on behalf of the TF-M Security Team
Hello TF-M Community,
I'd like to upgrade the default CMake version in TF-M to 4.3.5.
Please let me know if you have any objections or foresee compatibility issues with your development environment or downstream projects. If there are no objections by Sep 21, I'll proceed with the upgrade.
Thanks,
Anton
Hello,
We're pleased to announce the release of TF-M v2.3.0.
Major highlights:
* Adoption of TF-PSA-Crypto 1.1.0 in place of Mbed TLS
* Extended support for the Clang/LLVM Arm Toolchain for Embedded (ATfE)
* TF-M Tests: RTX OS is now built from source
This release also includes numerous fixes and improvements - please see the release notes<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/50322/8/docs…> for full details.
Release v2.1.5 will follow shortly.
Many thanks to everyone who contributed, reviewed, and supported this milestone.
Best regards,
The TF-M Team
Hello,
Following the recent releases of the PSA Crypto and Mbed TLS libraries we're preparing two new TF-M maintenance releases: v2.3.1 and v2.1.6. These releases will include the latest security fixes from PSA Crypto and Mbed TLS, along with a few minor TF-M fixes.
The current tentative plan is to start the release process on August 3 and publish both releases on August 11. If there are any changes you would like to include, please ensure they are reviewed and merged into the corresponding release branches by August 1.
For both releases we do not expect platform-specific testing as the changes are platform-independent and CI should provide sufficient validation. However, please feel free to reach out if you have any concerns or anticipate any platform-specific impact.
Best regards,
Anton
Hi,
I was trying to build TF-M with local libraries and noticed that patches were not applied in that flow.
I found an issue with fetch_remote_library() when using local library paths instead of downloading the dependency.
The function exposes LIB_FORCE_PATCH, and the documentation says it should control patching when the library source is provided as a local folder. However, in the current implementation this does not really work for local libraries.
We have our Modus Toolbox IDE which builds TFM as part of a project where all the libraries are already cloned, thus we need a way to forca patch local sources.
Is upstream community interested in this ? If so I can propose a fix soon.
A patch is available for review.
Best regards,
Bohdan Hunko
Cypress Semiconductor Ukraine LLC
Senior Engineer
CSS ICW SW INT BFS SFW
Mobile: +380995019714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
HI, i'm developing the RSE firmware based on TF-Mv2.3.0(with TF-Mv2.3.0 release tag) for the our platform that refers to rdv3r1.
In TF-M runtime security service, it needs a IAK(Initial Attestation Key) derived by IAK seed to create IAT(Initial Attestation Token).
When i checked tfm_plat_get_iak(), it gets IAK_seed by just reading KMU slot which IAK_seed is stored.
However, the KMU keyslot storing IAK_seed have been locked since IAK_seed is created so that IAT creation is failed.
I was checking possible ways that exports locked key in KMU keyslot and found some evidence in the source codes.
That is using CC3xx opaque key that is the method using the KMU export with keyslot index instead using raw key values.
Currently, it seems that cc3xx opaque keys feature is supported only for HW keys and AES / CMAC algorithm.
However, IAK_seed is stored in S/W keyslot and IAK needs ECC algorithm derivation.
(CC3xx lowlevel seems to support it but PSA crypto driver doesn't support it)
According to TODO comments like below, it seems that there is some long term plan about it.
(I guess that it will be removed When PSA crypto driver supporting all keys and algorithm is implemented)
rse_setup_iak_seed()(a)rse_kmu_keys.c
/* TODO: Should be removed once setup_key properly locks KMU slots */kmu_err = kmu_set_key_locked(&KMU_DEV_S, RSE_KMU_SLOT_IAK_SEED);if (kmu_err != KMU_ERROR_NONE) { return (enumtfm_plat_err_t) kmu_err;}
Are there any plans or progress regarding this?
Best Regards
RH Kim
