Hello,
The next Technical Forum is planned on Thursday, July 23 at 6:00-07:00 UTC (Asia time zone).
Please reply on this email with your proposals for agenda topics.
Best regards,
Anton Komlev
Hi,
The ITS design requires that all data items are private to its client - it essentially just provides a persistence capability within the same isolation domain. So it is not possible for two distinct clients to access the same stored material, *unless they do this through a common intermediary*.
Jamie outlines one approach: PSA Crypto Partition hosts the key store, and delegates the operations to the AES partition. But this fails the concurrency requirement as noted.
Another plausible approach is that the AES Partition is a special/trusted client of the PSA Crypto Partition and uses a dedicated service/API to retrieve the AES client's key material. However, this also fails the concurrency objective when the PSA Crypto Partition is busy.
Without the IPC model (which allows for nested/interleaved message handling, under service developer control) - the design that would work is to:
1. Create a key store Partition that interfaces with ITS
2. Have the PSA Crypto and AES partitions be trusted clients of the key store (the key store does not allow other client connections)
3. Key management operations go through a PSA Crypto service, which invokes the key store service to store material in ITS
4. AES operations go through a AES service, which invokes the key store service to retrieve key material
This model works, but delivering the desired concurrency requires that the framework supports multiple Partitions, and can run one Partition while another is busy/blocked.
Note that the key store service is _just_ a proxy to ITS using the key-id + Crypto-client-id supplied by its client. Security depends on the client-ids of the Crypto and AES Partitions being fixed so that the private key store service can strictly enforce which clients can use it.
Regards,
Andrew
From: psa-crypto <psa-crypto-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Fox via psa-crypto
Sent: 10 July 2020 14:22
To: Quach, Brian <brian(a)ti.com>; tf-m(a)lists.trustedfirmware.org; psa-crypto(a)lists.trustedfirmware.org
Subject: Re: [psa-crypto] Persistent key storage ownership/access
Hi Brian,
It is true that each persistent key has only one owner who can access it, the partition that created it.
But note that even if the driver partition could be given permission to access the key, then it wouldn't immediately fix the issue. The driver partition would then need to implement another layer of access control, otherwise partitions would be able to use it as a conduit to access keys that they don't themselves own.
I think a more expected flow would look like:
1. NS application calls psa_import_key() to store a key with an ID. Key is stored by ITS with client ID of -1 (DEFAULT_NS_CLIENT_ID).
2. NS application calls an AES crypto function in the PSA Crypto partition and provides the key ID.
3. PSA Crypto partition retrieves the key from ITS for use. Client ID = -1.
4. PSA Crypto partition calls an AES crypto function in the driver partition and provides the key material.
But I assume you discarded this approach because it didn't give you the level of concurrency between PSA Crypto and the crypto driver that you wanted.
I am adding the psa-crypto mailing list to this, as people on there may have more/better input.
Kind regards,
Jamie
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Quach, Brian via TF-M
Sent: 10 July 2020 06:18
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Persistent key storage ownership/access
Hi,
I see that keys can only be accessed/modified by their owning secure partition.
File ID used by ITS is 12-bytes. Assuming the Application imports a persistent key and then opens the key, the File ID would be:
| 32 -bits | 32 -bits | 32 -bits |
==========================================
PSA Crypto SP ID | Key ID | DEFAULT_NS_CLIENT_ID (-1)
Then the key handle returned from the psa_open_key() is used for any cryptographic operations. This makes perfect sense to me for PSA API v1.0 beta 3.
However, for PSA API v1.0 release where open/close key was removed and only the Key ID will be used, I'm confused on how the key access and File ID would work.
Initially, when the app imports the key, the key file would have the same 12-byte file ID as the case above. However, when the application calls a cryptographic function, it now provides the
32-bit key ID instead of the handle. The persistent key is not cached and must be read from the ITS. I had assumed the crypto driver would call psa_export_key() to retrieve the key for use, however, the File ID in this case would be:
| 32 -bits | 32 -bits | 32 -bits |
==========================================
PSA Crypto SP ID | Key ID | Secure Partition ID of Crypto Driver
The file ID would not match what the App imported and the key would not be found.
Am I misunderstanding how the key should be accessed for use after it has been imported or how the File ID is generated?
Another explanation of the scenario if the above was not clear:
1. NS application calls psa_import_key() to store a key with an ID. Key is stored by ITS with client ID of -1 (DEFAULT_NS_CLIENT_ID).
2. NS application calls an AES crypto function and provides the key ID.
3. AES driver crypto function calls psa_export_key() to retrieve the key from ITS for use. Client ID = AES secure partition.
RoT Partition 1:
* PSA Crypto (with keystore)
RoT Partition 2:
- AES driver (placed its own partition so other crypto ops in PSA Crypto partition can run in parallel...multiple HW accelerators)
RoT Partition 3:
* ITS
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
Hi Brian,
It is true that each persistent key has only one owner who can access it, the partition that created it.
But note that even if the driver partition could be given permission to access the key, then it wouldn't immediately fix the issue. The driver partition would then need to implement another layer of access control, otherwise partitions would be able to use it as a conduit to access keys that they don't themselves own.
I think a more expected flow would look like:
1. NS application calls psa_import_key() to store a key with an ID. Key is stored by ITS with client ID of -1 (DEFAULT_NS_CLIENT_ID).
2. NS application calls an AES crypto function in the PSA Crypto partition and provides the key ID.
3. PSA Crypto partition retrieves the key from ITS for use. Client ID = -1.
4. PSA Crypto partition calls an AES crypto function in the driver partition and provides the key material.
But I assume you discarded this approach because it didn't give you the level of concurrency between PSA Crypto and the crypto driver that you wanted.
I am adding the psa-crypto mailing list to this, as people on there may have more/better input.
Kind regards,
Jamie
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Quach, Brian via TF-M
Sent: 10 July 2020 06:18
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Persistent key storage ownership/access
Hi,
I see that keys can only be accessed/modified by their owning secure partition.
File ID used by ITS is 12-bytes. Assuming the Application imports a persistent key and then opens the key, the File ID would be:
| 32 -bits | 32 -bits | 32 -bits |
==========================================
PSA Crypto SP ID | Key ID | DEFAULT_NS_CLIENT_ID (-1)
Then the key handle returned from the psa_open_key() is used for any cryptographic operations. This makes perfect sense to me for PSA API v1.0 beta 3.
However, for PSA API v1.0 release where open/close key was removed and only the Key ID will be used, I'm confused on how the key access and File ID would work.
Initially, when the app imports the key, the key file would have the same 12-byte file ID as the case above. However, when the application calls a cryptographic function, it now provides the
32-bit key ID instead of the handle. The persistent key is not cached and must be read from the ITS. I had assumed the crypto driver would call psa_export_key() to retrieve the key for use, however, the File ID in this case would be:
| 32 -bits | 32 -bits | 32 -bits |
==========================================
PSA Crypto SP ID | Key ID | Secure Partition ID of Crypto Driver
The file ID would not match what the App imported and the key would not be found.
Am I misunderstanding how the key should be accessed for use after it has been imported or how the File ID is generated?
Another explanation of the scenario if the above was not clear:
1. NS application calls psa_import_key() to store a key with an ID. Key is stored by ITS with client ID of -1 (DEFAULT_NS_CLIENT_ID).
2. NS application calls an AES crypto function and provides the key ID.
3. AES driver crypto function calls psa_export_key() to retrieve the key from ITS for use. Client ID = AES secure partition.
RoT Partition 1:
* PSA Crypto (with keystore)
RoT Partition 2:
- AES driver (placed its own partition so other crypto ops in PSA Crypto partition can run in parallel...multiple HW accelerators)
RoT Partition 3:
* ITS
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
Hi,
I see that keys can only be accessed/modified by their owning secure partition.
File ID used by ITS is 12-bytes. Assuming the Application imports a persistent key and then opens the key, the File ID would be:
| 32 -bits | 32 -bits | 32 -bits |
==========================================
PSA Crypto SP ID | Key ID | DEFAULT_NS_CLIENT_ID (-1)
Then the key handle returned from the psa_open_key() is used for any cryptographic operations. This makes perfect sense to me for PSA API v1.0 beta 3.
However, for PSA API v1.0 release where open/close key was removed and only the Key ID will be used, I'm confused on how the key access and File ID would work.
Initially, when the app imports the key, the key file would have the same 12-byte file ID as the case above. However, when the application calls a cryptographic function, it now provides the
32-bit key ID instead of the handle. The persistent key is not cached and must be read from the ITS. I had assumed the crypto driver would call psa_export_key() to retrieve the key for use, however, the File ID in this case would be:
| 32 -bits | 32 -bits | 32 -bits |
==========================================
PSA Crypto SP ID | Key ID | Secure Partition ID of Crypto Driver
The file ID would not match what the App imported and the key would not be found.
Am I misunderstanding how the key should be accessed for use after it has been imported or how the File ID is generated?
Another explanation of the scenario if the above was not clear:
1) NS application calls psa_import_key() to store a key with an ID. Key is stored by ITS with client ID of -1 (DEFAULT_NS_CLIENT_ID).
2) NS application calls an AES crypto function and provides the key ID.
3) AES driver crypto function calls psa_export_key() to retrieve the key from ITS for use. Client ID = AES secure partition.
RoT Partition 1:
- PSA Crypto (with keystore)
RoT Partition 2:
- AES driver (placed its own partition so other crypto ops in PSA Crypto partition can run in parallel...multiple HW accelerators)
RoT Partition 3:
- ITS
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
Hi Anton,
I'd like to give a brief introduction to SPRTL (Secure Partition Runtime Library) update. It will take no more than 30 minutes.
Best Regards,
Summer
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of David Hu via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Friday, July 3, 2020 10:44 AM
To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TF-M Technical Forum call - July 9
Hi Anton,
I’d like to give a brief introduction to Profile Medium design. It won’t take very long time.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Thursday, July 2, 2020 6:58 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] TF-M Technical Forum call - July 9
Hello,
The next Technical Forum is planned on Thursday, July 9 at 15:00-16:00 UTC (US time zone).
Please reply on this email with your proposals for agenda topics.
Best regards,
Anton Komlev
Hello Tomas,
I am trying to port TFM to IAR Embedded Workbench v8.50.5 IDE (NOT cmake) for LPC55S69.
And have an error during linking in tfm\platform\ext\common\iar\tfm_common_s.icf on #include "region_defs.h":
Error[Lc003]: expected ""check", "define", "do", "export", "if", "include", "initialize", "keep", "place", "reserve", or a placement label
It can be fixed by changing: #include "region_defs.h" to: include "region_defs.h";
but it creates 44 Errors [Lc003] in region_defs.h,
The IAR linker does not understand the C preprocessor directives like #ifndef, #ifdef, #endif etc.
How did you solve this IAR issue?
As we have to use IAR IDE (not cmake), what is your suggestion? Maybe a special IAR Linker preprocessing parameter/option?
Thank you,
Andrej Butok
Hi All,
Please review the design of the TF-M HAL: https://review.trustedfirmware.org/c/trusted-firmware-m/+/4076.
This new design aims to make the TF-M more simple to integrate and porting to different platforms. The current version only includes the HAL API for the TF-M core, the HAL for Secure Partition will be the next step.
Main Context:
* There are 6 modules in the Core HAL:
* Isolation API: Provides the necessary isolation functionalities required by the PSA FF and TBSA-M, and provides functions to SPM to check the validate of memory access.
* Platform API: Provides the platform initial, receives platform data, system reset, etc.
* Loader API: Provides the function to load partition and service and provides the necessary data to SPM.
* Log dev API: Provides the log system functions.
* Interrupt API: Provides the interrupt functions.
* Debug API: Provides the debug functions.
* There are some sequence diagrams that help you to more quick and easy the using of the new HAL.
Main Change:
There are some main changes to the TF-M core:
* Move most of the platform data from Core to the platform and need tools to support it.
* The platform needs to provide the required necessary memory to the Core for its runtime data using.
* Load mode change. The platform needs to load the secure partition and provide the necessary info to the core.
Please see the design for more details and welcome comments.
BR,
Edison
Hi All,
New TF-Mv1.1-RC2 tag has been applied to all project repositories, marking fixes of issues found in RC1.
The changes are small so only affected configurations will be retested.
Best regards,
Anton Komlev
Tech Lead of TF-M in Arm Ltd.
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: 24 June 2020 18:16
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TF-M v1.1 - Heads up
Hi All,
Both trusted-firmware-m and tf-m-tests repositories are tagged with TF-Mv1.1-RC1 tag marking the code freeze and beginning of the release candidate testing.
Best regards,
Anton Komlev
Tech Lead of TF-M in Arm Ltd.
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shebu Varghese Kuriakose via TF-M
Sent: 10 June 2020 18:28
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] TF-M v1.1 - Heads up
Hi All,
Just a heads up that TF-Mv1.1 tag is planned for middle to end of July. Code freeze of TF-M master is aimed around end of June to allow enough time for testing.
Similar to TF-Mv1.0 and previous tags, v1.1 will include all TF-M changes in TF-M master available till code freeze in end of June.
Availability of the tag will be notified via. this mailing list.
Thanks,
Shebu
Technology Manager-TF-M, Arm Ltd.
