Hi Anton,
I'd like to give a brief introduction on the changes (both happened and proposal) for TF-M testing.
The duration would be ~30 minutes.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Monday, July 20, 2020 4:14 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] TF-M Technical Forum call - July 23
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 all
The new buildsystem (work in progress) is now available at https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5039. Comment would be very much appreciated.
There have been some minor interface changes to how the buildsystem is invoked.
a sample invocation is:
cmake -S .. \
-B . \
-G"Unix Makefiles" \
-DTFM_PLATFORM=musca_s1 \
-DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake \
-DCMAKE_BUILD_TYPE=release
-DBL2=ON \
-DNS=ON \
-DTFM_PSA_API=ON \
-DTEST_NS=ON
-DTEST_S=ON \
-DTFM_ISOLATION_LVL=2
More specifically
cmake -S [Source_dir (often ..)] \
-B [build_dir (often .)] \
-G ["Unix Makefiles" OR Ninja] \
-DTFM_PLATFORM=[musca_b1 OR musca_s1 OR mps2/an521 OR cypress/psoc64 ETC...]
-DCMAKE_TOOLCHAIN_FILE=[build_dir/toolchain_GNUARM.cmake OR build_dir/toolchain_ARMCLANG.cmake]
-DCMAKE_BUILD_TYPE=[release OR debug OR minsizerel OR relwithdbginfo]
-DBL2=[OFF OR ON]
-DNS=[OFF OR ON]
-DTFM_PSA_API=[OFF OR ON]
-DTEST_NS=[OFF OR ON]
-DTEST_S=[OFF OR ON]
-DTFM_ISOLATION_LVL=[1 OR 2]
Note that this interface is not set in stone and may change before these patches are merged.
The new buildsystem is currently missing a few of the platforms, as well as some features. All of these are planned to be added prior to merging. Notable are dualcpu/Cypress PSoC64 which is currently being finalized, documentation building, and image signing for some of the boot modes which is on the TODO list.
Note that unlike previous versions, this should work "out the box" with regard to dependencies. The paths for dependencies can be set, but some patches to mbedtls that are in the process of being upstreamed are used. These patches are stored in the lib/ext/mbedcrypto directory and can easily be applied manually.
Regards,
Raef Coles
Hi,
Just a heads-up for the coming changes related to MCUBoot. Some of them requires installing new tools in build system others could affect devices on the field (if there is any) after SW upgrade.
Short term, within one week:
1. Official imgtool enablement:
* The official released version of the image signings script will be used.
* Must be installed in the build system. It is a PyPI package: imgtool v1.6
* https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4564/6
2. Encrypted image support:
* This feature already exists in the upstream repo for a while
* This change makes possible to turn it on in TF-M build system
* https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4565/6
Long term, but still expected in Q3:
1. Removal of forked MCUBoot from TF-M:
* Only upstream MCUBoot will supported
* Platform and project related files will be kept:
i. shim layer to match MCUBoot HAL's to TF-M's HAL
ii. bl2_main.c, example signing keys, keys.c
iii. platform code: flash and UART drivers, implementation of boot_hal.h
* When building TF-M with upstream MCUboot it is a mixture of files from the two repo + crypto code from mbedcrypto repo.
* https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4953
* The removal of the fork depends on the feature upstream to MCUBoot repo:
i. https://github.com/JuulLabs-OSS/mcuboot/pull/739
ii. RAM_LOAD: PR will come a bit later
1. Removal of LEGACY_TFM_TLV_HEADER support
* This is a compatibility mode. It was introduced to hide the difference in the definition of the TLV header int he shared data between bootloader and runtime SPE.
* If forked removed, then this is not necessary anymore, unless an forked version of MCUBoot wants to cooperate new SPE.
* Please check and indicate if you think that this is a valid use case and compatibility mode must be kept!
Tamas
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
