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
