Hello,
I just recently found out that there's a concept of key ownership in TF-M (e.g., if a new secure partition creates a key and returns the key handle to NSPE, NSPE can't export it even if the key is config-ed to be exportable -- the key can only be used by the owner).
My question is: is this design based on PSA or specific to just TF-M implementation?
Thank you in advance,
Hi,
The PSA Crypto API enables implementations with different isolation characteristics. These are outlined in 2.3 Optional isolationhttps://arm-software.github.io/psa-api/crypto/1.3/overview/goals.html#optional-isolation, and some visualisation of these isolation levels are in the Security Risk Assessment Appendixhttps://arm-software.github.io/psa-api/crypto/1.3/appendix/sra.html#architecture.
TF-M provides a caller-isolation implementation: the crypto processor is a service running in a secure partition, and applications that use the crypto API are treated as separate callers. Secure Partitions have caller identities based on their Partition. Applications in the NSPE either share a single caller identity (always distinct from Secure Partition ids), or can be separated from each other depending on the configuration of the NSPE runtime.
Isolated callers do not share keys. The last paragraph in 9.4 Key identifiershttps://arm-software.github.io/psa-api/crypto/1.3/api/keys/ids.html#key-identifiers describes this behaviour. This is required, for example, to ensure that an untrusted application cannot simply use a secret key that was created for use by a Secure Partition.
Note that the caller identity is not part of the Crypto API, it is implicitly based on the location of the caller in the TF-M system. It is not possible to spoof another caller�s identity.
If you have a secure service that creates keys on behalf of an NSPE application, then for the application to use that key, either:
1. The service must provide interfaces to the application to carry out the operation within the secure service (so the service calls the Crypto API to use the key). 2. The service must provide a copy of the key material to the application, which can import it into its own keystone, and then use it. (Note that this does expose the key material to the NSPE, which may not be an acceptable risk).
Regards, Andrew
From: Norrathep Rattanavipanon via TF-M tf-m@lists.trustedfirmware.org Date: Wednesday, 25 June 2025 at 10:55 To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Subject: [TF-M] Constrains of key ownership in TF-M
Hello,
I just recently found out that there's a concept of key ownership in TF-M (e.g., if a new secure partition creates a key and returns the key handle to NSPE, NSPE can't export it even if the key is config-ed to be exportable -- the key can only be used by the owner).
My question is: is this design based on PSA or specific to just TF-M implementation?
Thank you in advance,
-- Oak Norrathep
�ٹ���ҧ����֡�ҹҹҪҵ� ��������������ȷҧ�Ԫҡ�âͧ����¹ International education hub towards ASEAN�s academic excellence
Got it. Thank you so much for clarifying this.
On Thu, Jun 26, 2025 at 5:46 PM Andrew Thoelke via TF-M < tf-m@lists.trustedfirmware.org> wrote:
Hi,
The PSA Crypto API enables implementations with different isolation characteristics. These are outlined in 2.3 Optional isolation https://arm-software.github.io/psa-api/crypto/1.3/overview/goals.html#optional-isolation, and some visualisation of these isolation levels are in the Security Risk Assessment Appendix https://arm-software.github.io/psa-api/crypto/1.3/appendix/sra.html#architecture .
TF-M provides a caller-isolation implementation: the crypto processor is a service running in a secure partition, and applications that use the crypto API are treated as separate callers. Secure Partitions have caller identities based on their Partition. Applications in the NSPE either share a single caller identity (always distinct from Secure Partition ids), or can be separated from each other depending on the configuration of the NSPE runtime.
Isolated callers do not share keys. The last paragraph in 9.4 Key identifiers https://arm-software.github.io/psa-api/crypto/1.3/api/keys/ids.html#key-identifiers describes this behaviour. This is required, for example, to ensure that an untrusted application cannot simply use a secret key that was created for use by a Secure Partition.
Note that the caller identity is not part of the Crypto API, it is implicitly based on the location of the caller in the TF-M system. It is not possible to spoof another caller’s identity.
If you have a secure service that creates keys on behalf of an NSPE application, then for the application to use that key, either:
- The service must provide interfaces to the application to carry out
the operation within the secure service (so the service calls the Crypto API to use the key). 2. The service must provide a copy of the key material to the application, which can import it into its own keystone, and then use it. (Note that this does expose the key material to the NSPE, which may not be an acceptable risk).
Regards, Andrew
*From: *Norrathep Rattanavipanon via TF-M tf-m@lists.trustedfirmware.org *Date: *Wednesday, 25 June 2025 at 10:55 *To: *tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org *Subject: *[TF-M] Constrains of key ownership in TF-M
Hello,
I just recently found out that there's a concept of key ownership in TF-M (e.g., if a new secure partition creates a key and returns the key handle to NSPE, NSPE can't export it even if the key is config-ed to be exportable -- the key can only be used by the owner).
My question is: is this design based on PSA or specific to just TF-M implementation?
Thank you in advance,
-- Oak Norrathep
ศูนย์กลางการศึกษานานาชาติ มุ่งสู่ความเป็นเลิศทางวิชาการของอาเซียน International education hub towards ASEAN’s academic excellence -- TF-M mailing list -- tf-m@lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave@lists.trustedfirmware.org
tf-m@lists.trustedfirmware.org
-
Andrew Thoelke -
Norrathep Rattanavipanon