Hi Sebastian,
The section in the Platform Security Model is describing the behavior of a system reset – the recommendation is that any preceding runtime state (in volatile memory, or in CPU or peripheral registers) does not influence the execution of the reboot. This is except for an optional suspend or hibernate state, which explicitly maintains runtime state while powering off most or all of the system and will resume via a CPU reset.
System security requirements might require explicit clearing of volatile memory on reset to prevent cold-boot style attacks that could allow an attacker to read any residual RAM contents – although software-based attacks of this kind are partly mitigated by trusted boot, which prevents an attacker from running arbitrary code at reset (unlike devices that boot from untrusted flash memory).
The specific bullet list in the PSA Firmware Framework for M (in §3.5.1 on Panics) is describing the challenges for an implementation that does NOT do the recommended action of resetting the system when a Secure Partition panics, which justifies the recommendation to reset the system. If the SPM does reset the system, then the challenges in that bullet list are avoided. The issues listed are:
> * An individual Secure Partition cannot be reset and restarted in isolation.
> * A Secure Partition may have state maintained on behalf of clients that will be destroyed when restarting the service. There is no mechanism to re-synchronize the clients.
> * It is not possible to determine at the point of panic how much corruption has occurred within the Secure Partition and elsewhere in the SPE.
If the SPM only restarted the Secure Partition that panicked, then any previous runtime state within that Secure Partition is lost, including any ongoing connections with clients of services within that partition, or any resources that those services were managing for their clients. FF-M does not provide a specified mechanism for such clients to be informed that the connections are broken, and there is no way to provide a general strategy that allows a client to recover from a service failure. This is what is meant by “There is no mechanism to re-synchronize the clients.”.
I have just realized that in FF-M 1.1, there may be scenarios in which restarting a Secure Partition could be justified and technically feasible. If a Secure Partition with only Stateless services maintains no client state or resources, and also maintains no connections to other RoT Services (so there are no RoT Services maintaining state for this Secure Partition) – then restarting this Secure Partition might not suffer from the first two complications listed in §3.5.1. The third issue is harder to control: the risks from the data corruption that lead up to the panic depends partly on the SPE isolation policies, and on what this Secure Partition was responsible for. Reset remains the recommended response to a Secure Partition panic in v1.1.0.
Regards,
Andrew Thoelke
Arm Ltd.
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: 26 October 2021 10:51
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] System reset
Hi Sebastian,
The specification writer looks not here these two days, let me try to explain it based on my understanding.
I think two specs both recommend clearing general runtime data while resetting. If the booting runtime clearing code can clear the RAM data for a specific platform, the memory clearing in the 'tfm_spm_hal_system_reset ' can be skipped. Basically, simple hardware reset triggering is just fine.
The special-purpose memory to be retained during resetting is not a generic runtime memory, hence they need to be treated specially, such as putting them in a special bank or region and skipping clearing them during booting. This special region can be treated as a private asset of one service, which could NOT be shared between components for direct access. The owner service provides the functionality around this asset.
Please put more comments or corrections, thanks.
/Ken
From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Sebastian Bøe via TF-M
Sent: Monday, October 25, 2021 3:16 PM
To: mailto:tf-m@lists.trustedfirmware.org
Subject: [TF-M] System reset
Hi,
I would like some clarification about system reset.
There are these two statements about it in the PSM and PSA-FF:
"No run-time state from before the reset should be retained or used, except where necessary if suspend or hibernate are supported, see section 4.6." -- PSM page 22.
"A Secure Partition may have state maintained on behalf of clients that will be destroyed when restarting the service." -- PSA-FF page 47.
Is it the responsibility of tfm_spm_hal_system_reset to destroy this state or is it OK to destroy it after reset as a part of the C runtime startup procedure?
I assume for instance that PRoT .bss is cleared as a part of the C runtime startup procedure, but should it also have been destroyed as a part of tfm_spm_hal_system_reset ?
PSM - Platform Security Model.
https://developer.arm.com/documentation/den0128/0100/
PSA-FF PSA Firmware Framework
https://armkeil.blob.core.windows.net/developer/Files/pdf/PlatformSecurityA…
Sebastian Bøe
Nordic Semiconductor
Hi all,
I'm been working to unify the HAL APIs for IPC Model.
The IPC Model currently uses two different sets of HAL APIs:
* tfm_spm_hal_* - This is mainly used by the Library Model and IPC Model re-uses some of them
* tfm_hal_* - This is introduced for IPC Model and some are shared to Library Model
This might be confusing for platform vendors.
So I'm trying to make it clear for IPC Model by:
* Duplicating the shared APIs and rename the IPC copy to tfm_hal_*
* Combining several platform init APIs to a single tfm_platform_init for IPC Model
* tfm_spm_hal_enable_fault_handlers
* tfm_spm_hal_system_reset_cfg
* tfm_spm_hal_init_debug
* tfm_spm_hal_nvic_interrupt_target_state_cfg
* tfm_spm_hal_nvic_interrupt_enable
With these changes, IPC Model will use tfm_hal_* APIs only.
Please platform owners review these patches<https://review.trustedfirmware.org/q/topic:%22decouple_legacy_hal_for_ipc%2…> to see if any mistakes (the patches mainly move codes around) or any platforms missed in the patches.
Plan to have them merged before the end of October. Thanks.
Best Regards,
Kevin
Hi,
I would like some clarification about system reset.
There are these two statements about it in the PSM and PSA-FF:
"No run-time state from before the reset should be retained or
used, except where necessary if suspend or hibernate are supported,
see section 4.6." -- PSM page 22.
"A Secure Partition may have state maintained on behalf of clients
that will be destroyed when restarting the service." -- PSA-FF page
47.
Is it the responsibility of tfm_spm_hal_system_reset to destroy this state
or is it OK to destroy it after reset as a part of the C runtime startup
procedure?
I assume for instance that PRoT .bss is cleared as a part of the C runtime
startup
procedure, but should it also have been destroyed
as a part of tfm_spm_hal_system_reset ?
PSM - Platform Security Model.
https://developer.arm.com/documentation/den0128/0100/
PSA-FF PSA Firmware Framework
https://armkeil.blob.core.windows.net/developer/Files/pdf/PlatformSecurityA…
Sebastian Bøe
Nordic Semiconductor
Hi,
I created patches to add the XOR checksum of the whole metadata into the ITS metadata_block header. This is to check the possible error in the flash. It can happen that the ITS file system is upgraded to the new one while the ITS assets are maintained with the current ITS file system. To support compatibility with the current ITS filesystem version, at the initialization of the file system, the file metadata and the block metadata, together with the metadata_block_header are updated to the new ITS file system. The patches are:
https://review.trustedfirmware.org/q/topic:%22ITS_FILESYSTEM%22+(status:ope…
Would you like to review the patches? Any comments are welcomed!
Regards,
Sherry Z
Running regression tests with the current HEAD, the secure tests all pass but the non-secure tests get stuck early on (I suspect that responses don't get back to the NS core).
Reverting 5e68b11764673ee32bae0de8ecf3cde45cc55ea1 "SPM: Trigger scheduler at the end of SPM API" fixes the issue.
Was that patch tested with multi-core?
I created a patch to revert that patch for now - https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11998
Chris Brand
Cypress Semiconductor (Canada), Inc.
Sr Prin Software Engr
CSCA CSS ICW SW PSW 1
Office: +1 778 234 0515
Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>
Hi All,
I want to enable GPIO IRQ in Trusted firmware-m 1.3 on nrf5340DK. I have TFM 1.3 which comes with zephyr v2.7.0 image flashed to board. followed the steps of https://www.trustedfirmware.org/docs/tech_forum_20210819BriefUpdatesInterru… and tfm_slih_test_service which has TIMER0 interrupt handler.
Steps1: Assigning the interrupt GPIOTE0 and TIMER0 in secure partition manifest file.
Steps2: Assigning the MMIO region of GPIOTE0 and TIMER0 in secure partition manifest file.
Step3: Enable(psa_irq_enable) for both GPIOTE0,TIMER0 and Start (tfm_plat_test_secure_timer_start) the TIMER0.
Step4: waiting for interrupt SIGNAL defined in secure partition manifest file for GPIOTE0 and TIMER0) using psa_wait(PSA_WAIT_ANY, PSA_BLOCK) in the secure partition source code.
But do not receive any signal for TIMER0 and GPIOTE0.
Q1) at least TIMER0 signal should be received after the timer start?
Q2)Are there any steps i missed to enable IRQ in TFM secure partition?
Q3)Also, for GPIOTE i need to enable IRQ on the particular pin of port0 ex P0.8, How can i know the signal generated for the interrupt is for P0.8?
Q4)In tfm_secure_irq_handling.rst it mentions "it is important the macro name matches the platform's handler function for that IRQ source."
- In case ``source`` is defined IRQ macro, the name of the handler becomes
``void <macro>_Handler(void)``.
I do not understand why we need to have a handler function name matching with IRQ source when we have to wait on psa_wait(PSA_WAIT_ANY, PSA_BLOCK) for IRQ signal?
Step1,Step2
/*#####################################################################*/
modules\tee\tfm\trusted-firmware-m\platform\ext\target\nordic_nrf\common\nrf5340\tfm_peripherals_def.h
#ifndef __TFM_PERIPHERALS_DEF_H__
#define __TFM_PERIPHERALS_DEF_H__
#include <nrf.h>
#ifdef __cplusplus
extern "C" {
#endif
#define TFM_TIMER0_IRQ (TIMER0_IRQn)
#define TFM_TIMER1_IRQ (TIMER1_IRQn)
#define TFM_GPIOTE0_IRQ (GPIOTE0_IRQn)
#define TFM_SPIM4_IRQ (SPIM4_IRQn)
struct platform_data_t;
extern struct platform_data_t tfm_peripheral_std_uart;
extern struct platform_data_t tfm_peripheral_timer0;
extern struct platform_data_t tfm_peripheral_std_gpiote0;
extern struct platform_data_t tfm_peripheral_std_spim4;
#define TFM_PERIPHERAL_STD_UART (&tfm_peripheral_std_uart)
#define TFM_PERIPHERAL_TIMER0 (&tfm_peripheral_timer0)
#define TFM_PERIPHERAL_GPIOTE0 (&tfm_peripheral_std_gpiote0)
#define TFM_PERIPHERAL_SPIM4 (&tfm_peripheral_std_spim4)
#define TFM_PERIPHERAL_FPGA_IO (0)
#ifdef __cplusplus
}
#endif
#endif /* __TFM_PERIPHERALS_DEF_H__ */
modules\tee\tfm\trusted-firmware-m\platform\ext\target\nordic_nrf\common\nrf5340\target_cfg.c
struct platform_data_t tfm_peripheral_timer0 = {
NRF_TIMER0_S_BASE,
NRF_TIMER0_S_BASE + (sizeof(NRF_TIMER_Type) - 1),
};
struct platform_data_t tfm_peripheral_std_uart = {
NRF_UARTE1_S_BASE,
NRF_UARTE1_S_BASE + (sizeof(NRF_UARTE_Type) - 1),
};
struct platform_data_t tfm_peripheral_std_gpiote0 = {
NRF_GPIOTE0_S_BASE,
NRF_GPIOTE0_S_BASE + (sizeof(NRF_GPIOTE_Type) - 1),
};
struct platform_data_t tfm_peripheral_std_spim4 = {
NRF_SPIM4_S_BASE,
NRF_SPIM4_S_BASE + (sizeof(NRF_SPIM_Type) - 1),
};
/*Secure partition manifest file change*/
samplepartition.yaml
{
"psa_framework_version": 1.1,
"name": "TFM_SP_sample",
# Possible options: "PSA-ROT | APPLICATION-ROT"
"type": "APPLICATION-ROT",
"priority": "NORMAL",
"model": "IPC",
"entry_point": "sample_partition_main",
"stack_size": "0x200",
"services": [
# Define the secure service here.
{
"name": "TFM_EXAMPLE_SERVICE",
# SIDs must be unique, ones that are currently in use are documented in
# tfm_secure_partition_addition.rst on line 184
"sid": "0x00001001",
"non_secure_clients": true,
"version": 1,
"version_policy": "STRICT"
},
],
# Define all the IRQs that the service wants to handle.
"mmio_regions": [
{
"name": "TFM_PERIPHERAL_GPIOTE0",
"permission": "READ-WRITE"
},
{
"name": "TFM_PERIPHERAL_SPIM4",
"permission": "READ-WRITE"
},
{
"name": "TFM_PERIPHERAL_TIMER0",
"permission": "READ-WRITE"
},
],
"irqs": [
{
"source": "TFM_GPIOTE0_IRQ",
"name": "TFM_GPIOTE0_IRQ",
"handling": "SLIH",
"tfm_irq_priority": 64,
},
{
"source": "TFM_SPIM4_IRQ",
"name": "TFM_SPIM4_IRQ",
"handling": "SLIH",
"tfm_irq_priority": 64,
},
{
"source": "TFM_TIMER0_IRQ",
"name": "TFM_TIMER0_IRQ",
"handling": "SLIH",
"tfm_irq_priority": 64,
}
],
"dependencies": [
"TFM_CRYPTO"
]
}
Step3, Step4
/*#####################################################################*/
/*Secure partition Code*/
sample_partition.c
#define TIMER_RELOAD_VALUE (1*1000*1000)
static void gpiote0_handler(void)
{
LOG_INFFMT("gpiote0_handler called!!\n");
psa_irq_disable(TFM_GPIOTE0_IRQ_SIGNAL);
psa_eoi(TFM_GPIOTE0_IRQ_SIGNAL);
}
static void spim4_handler(void)
{
LOG_INFFMT("spim4_handler called !\n");
psa_irq_disable(TFM_SPIM4_IRQ_SIGNAL);
psa_eoi(TFM_SPIM4_IRQ_SIGNAL);
}
static void timer0_handler(void)
{
LOG_INFFMT("timer0_handler called!\n");
psa_irq_disable(TFM_TIMER0_IRQ_SIGNAL);
psa_eoi(TFM_TIMER0_IRQ_SIGNAL);
}
static void timer_init(NRF_TIMER_Type * TIMER, uint32_t ticks)
{
nrf_timer_mode_set(TIMER, NRF_TIMER_MODE_TIMER);
nrf_timer_bit_width_set(TIMER, NRF_TIMER_BIT_WIDTH_32);
nrf_timer_frequency_set(TIMER, NRF_TIMER_FREQ_1MHz);
nrf_timer_cc_set(TIMER, NRF_TIMER_CC_CHANNEL0, ticks);
nrf_timer_one_shot_enable(TIMER, NRF_TIMER_CC_CHANNEL0);
}
static void timer_stop(NRF_TIMER_Type * TIMER)
{
nrf_timer_task_trigger(TIMER, NRF_TIMER_TASK_STOP);
nrf_timer_int_disable(TIMER, NRF_TIMER_INT_COMPARE0_MASK);
nrf_timer_event_clear(TIMER, NRF_TIMER_EVENT_COMPARE0);
}
static void timer_start(NRF_TIMER_Type * TIMER)
{
timer_stop(TIMER);
nrf_timer_task_trigger(TIMER, NRF_TIMER_TASK_CLEAR);
nrf_timer_int_enable(TIMER, NRF_TIMER_INT_COMPARE0_MASK);
nrf_timer_task_trigger(TIMER, NRF_TIMER_TASK_START);
}
void tfm_plat_test_secure_timer_start(void)
{
timer_init(NRF_TIMER0, TIMER_RELOAD_VALUE);
timer_start(NRF_TIMER0);
}
void tfm_plat_test_secure_timer_stop(void)
{
timer_stop(NRF_TIMER0);
}
void sample_partition_main(void)
{
psa_signal_t signals;
psa_irq_enable(TFM_SPIM4_IRQ_SIGNAL);
psa_irq_enable(TFM_GPIOTE0_IRQ_SIGNAL);
/*Start timer interrupt*/
psa_irq_enable(TFM_TIMER0_IRQ_SIGNAL);
tfm_plat_test_secure_timer_start();
/* Continually wait for one or more of the partition's RoT Service or
* interrupt signals to be asserted and then handle the asserted signal(s).
*/
while (1) {
signals = psa_wait(PSA_WAIT_ANY, PSA_BLOCK);
if (signals & TFM_GPIOTE0_IRQ_SIGNAL) {
gpiote0_handler();
}else if (signals & TFM_SPIM4_IRQ_SIGNAL) {
spim4_handler();
}else if (signals & TFM_TIMER0_IRQ_SIGNAL) {
timer0_handler();
} else {
psa_panic();
}
}
}
/*#####################################################################*/
Thanks
Yaduvir
Hi everyone,
If you are creating out-of-tree partitions, please assign c-flag 'CONFIG_TFM_BUILDING_SPE' to the partitions sources.
The reason is that FFM client header is used by both SPE and NSPE clients, and SPE would support multiple ABI methods and these methods can co-exist in the system, this flag can help the partition to choose correct ABI for FFM API.
Check here for an example:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11897/11/sec…
Or do you think choosing one ABI as the default ABI (default ABI owns the spec originally defined symbols) should work?
Any comments please feel free to raise.
BR.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Wednesday, October 20, 2021 3:12 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] [ATTENTION] SPM logic is under significant updating before End of Oct
Hi,
To support FFM 1.1 features (SFN mainly), the SPM logic is under significant updating till End of Oct, please:
- If you are doing release-targeted development, please based on the released tags.
- If you are developing with the latest master branch, please report bugs met. Our plan is to collect all bugs and fix them after this update, before the next release.
- Keen to receive your fixes and contributions. It would be very nice if you can do these.
All patches would go as a usual process, hence it should work for most of the configurations, except those not covered by the automation test. The platform related interfaces are not changing, hence no worry for platform owners.
Thanks!
/Ken
Hi Ken,
Thanks for the suggestions! Actually on the chip we are using (Nordic SoC), there is an event generator unit we can use directly without the needs to do hardware changes. I would like to try that approach.
The reason we can't do polling is that the events are generated during the enrollment process. I don't think that our biometric secure partition is reentrant while a process is onging, right? It is using just the single thread model.
Regards,
Jun
Message: 1
Date: Wed, 20 Oct 2021 05:43:23 +0000
From: Ken Liu <Ken.Liu(a)arm.com>
To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Sending events from TF-M to non-secure world?
Message-ID:
<DB9PR08MB676161D704B2D3D861283E6CF5BE9(a)DB9PR08MB6761.eurprd08.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hi Jun,
To trigger an interrupt by software, Register 'STIR' may help you.
The scenario you are describing is a practical use case hence it makes sense to think more about it.
The scenarios you are describing is more related to the programming model - As the SPE is working more like a library, the NS caller polling the status of secure services by service interfaces and updating local presenting are more straight (and simple).
And if you have involved a callback/event-based programming model into your secure service already (3rd party provided such a library, e.g.), you'll have to invent some mechanism to interactive with NS. From the Firmware Framework - M perspective, the peripheral is private to a partition, you can treat shared peripheral/memory as private resources to this partition, claim it in the manifest, and use it to communicate with NS. This shared peripheral (Aka MMIO in the specification) is private, it cannot be shared with other partitions.
More comments?
BR.
/Ken
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Li, Jun R via TF-M
Sent: Tuesday, October 19, 2021 10:42 PM
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Sending events from TF-M to non-secure world?
Hi Ken,
Thanks for the nice suggestions! I was thinking of using an interrupt from TF-M to NS world as well but that needs some hardware support, which should be fine since I'm still designing the device. Maybe there is a software interrupt solution?
Our application needs to put a biometric service inside TF-M and its enrollment process needs to send out some intermediate events to give the user some feedbacks. This is why I'm asking this question. I think TF-M can use an input buffer from NS world to store the new events and notify the NS world with the interrupt to fetch the new events. Sounds good?
Regards,
Jun
On 10/19/21, 00:23, "TF-M on behalf of tf-m-request(a)lists.trustedfirmware.org" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m-request(a)lists.trustedfirmware.org> wrote:
Send TF-M mailing list submissions to
tf-m(a)lists.trustedfirmware.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
or, via email, send a message with subject or body 'help' to
tf-m-request(a)lists.trustedfirmware.org
You can reach the person managing the list at
tf-m-owner(a)lists.trustedfirmware.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of TF-M digest..."
Today's Topics:
1. Re: Sending events from TF-M to non-secure world? (Ken Liu)
2. Inline asm syntax unified and symbol reference in IAR
toolchain (Ken Liu)
----------------------------------------------------------------------
Message: 1
Date: Tue, 19 Oct 2021 02:06:35 +0000
From: Ken Liu <Ken.Liu(a)arm.com>
To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Sending events from TF-M to non-secure world?
Message-ID:
<DB9PR08MB67613655A2ACA207C751C791F5BD9(a)DB9PR08MB6761.eurprd08.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hi Jun,
Basically, the service accessing model is a client-service model, hence the service won't call back to the client which makes the client a 'service'. Service can get client info by passed-in parameters and other SPM controlled channels.
Assuming you are using a Trustzone based hardware, the hardware provides the capability that calling back to NSPE, but it is not encouraged inside TF-M because it breaks the simplified model proposed by FF-M and difficulties the secure threat analysis - a simple case is that the secure context is blocked because it is waiting for NS returns.
If you do need to perform such operations, implement an interrupt based asynchronous mechanism is safer than software callbacks.
The most queried requirement we have met is someone querying if the execution can be delivered back to NSPE when secure IDLE is going to happen. Not sure if you are facing the similar, is it okay to share more details?
BR
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Li, Jun R via TF-M
Sent: Tuesday, October 19, 2021 12:20 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Sending events from TF-M to non-secure world?
Hi,
Anyone has idea how a service inside a secure partition can send out some events to the non-secure world? Does callback still work over IPC? It seems non-secure world can connect to a SP but not easy to do the other way.
Appreciate any comments or suggestions!
Jun
Intel Corporation @ SC, CA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.trustedfirmware.org/pipermail/tf-m/attachments/20211019/1ff875…>
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hey Andrew,
These are very valuable points! For us I think that we aim mainly for per key integrity and confidentiality on the key material and integrity only for the key metadata. Providing confidentiality for the whole keystore will need major changes in the PSA APIs and will be out of scope for us.
Providing per key confidentiality for the key material is a very straightforward change as you described. ITS will not need to change at all in this case, we will only modify the PSA crypto APIs.
Providing per key integrity for key metadata will need a bit more thinking since apart from the fields included in the psa_persistent_key_storage_format we will also need the fields from the psa_storage_info_t struct but this should not be a serious issue as well.
To conclude I think that we need to design the changes so that it is possible for platforms to implement these two requirments but we don't need to enforce them. I think that we need to have the flexibility to allow platforms to make their decisions on what they want to support depending on their needs. If, for example, a platform wants to support only confidentiality on the key material, they should be able to do that in my opinion.
Since we are discussing platform specific implementations, the IV or any additional data needed could be probably stored (hidden to the PSA APIs) inside a platform specific struct inside the psa_persistent_key_storage_format struct. This will minimize the storage requirements for each platform.
Regards,
George
________________________________
From: Kvamtrø, Frank Audun <frank.kvamtro(a)nordicsemi.no>
Sent: Wednesday, October 20, 2021 3:13 PM
To: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no>
Subject: Vs: [TF-M] Supporting encryption with ITS
________________________________
Fra: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> på vegne av Andrew Thoelke via TF-M <tf-m(a)lists.trustedfirmware.org>
Sendt: onsdag 20. oktober 2021 10:31
Til: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Kopi: nd <nd(a)arm.com>
Emne: Re: [TF-M] Supporting encryption with ITS
Hi,
Note that, by specification, ITS must provide confidentiality, integrity and replay protection for the data stored within it. However, if the platform already provides that protection via isolation/logical/physical mechanisms, then adding cryptographic protection provides some defence in depth, or may mitigate some forms of physical attack. In this case, it is not obvious what forms of cryptographic protection are needed, as cryptography is not providing the primary security properties for the ITS data.
As a result, I think the best design for this requirement will depend on the details of the protection that is required.
In this use case, which of the following types of cryptographic protection are needed:
1. Confidentiality of key material (the actual bits of the key data)
2. Confidentiality of key material and key metadata
3. Confidentiality of the full keystore
4. Per-key Integrity of key material
5. Per-key Integrity of key material and key metadata
6. Per-key Confidentiality and Integrity of key material and key metadata
7. Confidentiality and integrity of the full keystore
8. Rollback protection?
Per-key confidentiality, or confidentiality+integrity would be reasonably straight-forward to implement in a layer over the simple ITS storage – but would probably add IV or nonce+tag data to each key stored (assuming a HUK-derived encryption key is used). For just encryption, given the pseudo-random nature of secret keys – it might be possible to drop the need for random IV (and just use the client id + key id as an IV/nonce).
Full key store confidentiality or confidentiality+integrity requires much more complex design, as this aims to conceal and protect the identity of the keys that are stored, not just the key material and/or key metadata.
Regards,
Andrew
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Vasilakis, Georgios via TF-M
Sent: 19 October 2021 14:31
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Supporting encryption with ITS
Hello again, sorry for the second email by my formatting got lost in the first one unfortunately. Let me include the formatted context below:
Following the discussion regarding the encryption with ITS let's discuss a bit further the ideas discussed in the meeting.
1)Allow the protected storage to be used as a storage backend for persistent key storage in PSA crypto: This introduces the problem of reentrance that we discussed before. We cannot call crypto from the inside the PSA storage partition (either ITS of PS if we wanted to switch)
2)Do the encryption in the crypto partition instead of the ITS: This will require to create some platform specific encryption abstraction since we cannot have reentrance in PSA crypto as well. Meaning that we cannot call PSA crypto from PSA crypto. The main thing that needs to be solved in this solution is where can we store the metadata. The key itself can be derived from the HUK and does not need to be stored but the metadata need to be stored. These metadata can be stored by expanding the psa_storage_info_t struct or by introducing a new struct. The crypto storage apis will need to be modified to be aware of the extra information and handle them.
3)Put a frontend to ITS so that we select specific keys that need to be derived by the HUK. This is like the idea 2 I think in a concept level.
The previous two designs described in the mailing list was to refactor the ITS and the PS partitions to have a common "encryption" library and the idea of refactoring the ITS itself to have an encryption layer.
I personally prefer the solution 2 more than the other solutions. Moving the encryption in a higher level and using the ITS as a simple storage solution seems a cleaner approach. This will introduce a crypto abstraction layer (different than PS) but I don't consider it as a major disadvantage since all the crypto implementations in this scope will be very platform specific.
Let me know about your opinions on this, if there are no major objections, I am willing to design a solution and some header files to elaborate more on this design.
________________________________
From: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>>
Sent: Tuesday, October 19, 2021 3:18 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] Supporting encryption with ITS
Hello all,
Following the discussion regarding the encryption with ITS let's discuss a bit further the ideas discussed in the meeting.
Allow the protected storage to be used as a storage backend for persistent key storage in PSA crypto: This introduces the problem of reentrance that we discussed before. We cannot call crypto from the inside the PSA storage partition (either ITS of PS if we wanted to switch)
Do the encryption in the crypto partition instead of the ITS: This will require to create some platform specific encryption abstraction since we cannot have reentrance in PSA crypto as well. Meaning that we cannot call PSA crypto from PSA crypto. The main thing that needs to be solved in this solution is where can we store the metadata. The key itself can be derived from the HUK and does not need to be stored but the metadata need to be stored. These metadata can be stored by expanding the psa_storage_info_t struct or by introducing a new struct. The crypto storage apis will need to be modified to be aware of the extra information and handle them.
Put a frontend to ITS so that we select specific keys that need to be derived by the HUK. This is like the idea 2 I think in a concept level.
The previous two designs described in the mailing list was to refactor the ITS and the PS partitions to have a common "encryption" library and the idea of refactoring the ITS itself to have an encryption layer.
I personally prefer the solution 2 more than the other solutions. Moving the encryption in a higher level and using the ITS as a simple storage solution seems a cleaner approach. This will introduce a crypto abstraction layer (different than PS) but I don't consider it as a major disadvantage since all the crypto implementations in this scope will be very platform specific.
Let me know about your opinions on this, if there are no major objections, I am willing to design a solution and some header files to elaborate more on this design.
Regards,
George
________________________________
From: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>>
Sent: Wednesday, September 29, 2021 2:04 PM
To: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] Supporting encryption with ITS
Hello Sherry,
Thank you for the feedback!
Does the storage area on your device meet this requirement?
Yes, our devices can secure against read and write access through the dedicated peripherals (SPU + MPU).
Is the memory physically isolated?
If by that you mean if they are located outside of the chip then it is not. It is part of the package.
If not, I wonder why not uses the Protected Storage service instead?
The reason that we cannot use the protected storage service is that it is not supported as a storage backend by the PSA crypto APIs. Storing non-volatile keys right now using the PSA APIs uses ITS as a storage backend.
Your comments regarding storing the IV and the TAG in Protected Storage are, of course, valid. If we decide to use a common code base we will have to do changes in the design of both services to overcome these issues.
Overall, the motivation for encrypted ITS is based on the raising popularity of hardware-based attacks. The fact that right now we provide all the security measures needed does not mean that nothing will get compromised in the future. A security in depth approach seems more reasonable for such sensitive data.
I am happy to join the TF-M Tech forum this Thursday and discuss it further, yes!
Regards,
George
________________________________
From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>
Sent: Tuesday, September 28, 2021 12:20 PM
To: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: [TF-M] Supporting encryption with ITS
Hi George,
The ITS without encryption is not a compromised RoT. In the PSA Secure Storage API spec, the PSA Internal Trust Storage aims at providing a place for devices to store their most intimate secrets. Also
“”””””””””””””””””””
1. The storage underlying the PSA Internal Trusted Storage Service MUST be protected from read and modification by attackers with physical access to the device.
2. The storage underlying the PSA Internal Trusted Storage Service MUST be protected from direct read or write access from software partitions outside of the PSA Root of Trust (PRoT).
“”””””””””””””””””””
So, for internal trusted storage service, it requires the underlying storage itself should provide being read or write protection. The storage area should be a “trusted” area. Does the storage area on your device meet this requirement? Is the memory physically isolated? If not, I wonder why not uses the Protected Storage service instead?
For the design of adding encryption in ITS, in the PS partition, the `iv` and the encrypted object data are stored with the object file while the tag of each object is stored with the object table file. So, if encrypt the PS object in the ITS file system, how the PS partition get the `tag` of each object? After a rough thought, I think probably a standalone encryption for ITS is more reasonable.
As this is a relatively “big topic”, would you like to hold a discussion on the TF-M Tech forum if it is not limited by confidential information? The next Tech forum will be hold on this Thursday 3:00 PM UTC time.
Regards,
Sherry Zhang
From: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>>
Sent: Friday, September 24, 2021 8:52 PM
To: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] Supporting encryption with ITS
Hello Sherry,
Thank you for your input!
1. Our threat model is more concerned about attacks which can happen very early in the boot process, I think. A completely compromised RoT is not in our threat model.
2. I see that, ITS is supposed to store small objects. The storage overhead of adding encryption will be probably bigger than 20 bytes I think but the intention is to have this only as a configuration, not as the default option.
3. Agreed, a HAL API should be used for this.
Do you have any opinion on the design of it? Do you think that it adds value to do try to use a common design for the object handling of both PS and ITS or is it better to have it as a standalone thing for the ITS.
Regards,
George
________________________________
From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>
Sent: Friday, September 24, 2021 11:58 AM
To: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: [TF-M] Supporting encryption with ITS
Hi George,
Some comments from my side:
1. Internal trusted storage is part of the Root of Trust domain. If ITS storage device is attacked, then the code flash where the PSA Rot SP locates may also be attacked. Does the thread model of your system require the encryption in ITS?
2. The ITS service is intended to be used to interface to a small piece of storage. Encryption would increase the context for each ITS file. For example, similarly to PS object context, the `IV` which is used in encryption as well as the generated `tag` should be added into each file context. They total together can be about more than 20 bytes.
3. If the encryption is mandatory/ necessary required by the thread model of your system, as discussed, the PSA crypto service should not be called to avoid the circular. I think a HAL API for encryption may be created in ITS for platform implementation defined encryption/decryption.
Regards,
Sherry Zhang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vasilakis, Georgios via TF-M
Sent: Thursday, September 23, 2021 10:47 PM
To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; Fabian Schmidt <fabian.schmidt(a)nxp.com<mailto:fabian.schmidt@nxp.com>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: Re: [TF-M] Supporting encryption with ITS
Hey Gyorgy,
These are very valuable comments! I am aware of the circular dependency issue because the PSA apis are using the ITS as a storage backend. This, as you said, can be circumvented by using a software crypto library or an implementation specific API. So, for the encryption a flexible API can be used which can allow externals to use their own function calls.
Regarding the key storage, this is what I had in mind as well, using derived keys from the HUK. So that we don't need to store anything but the crypto metadata. Adding another layer of storage will raise more issues, I think.
________________________________
From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>
Sent: Thursday, September 23, 2021 4:30 PM
To: Fabian Schmidt <fabian.schmidt(a)nxp.com<mailto:fabian.schmidt@nxp.com>>; Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: [TF-M] Supporting encryption with ITS
Hi,
AFAIK the main reason for ITS not using encryption is the problem of circular dependency. ITS is used by crypto SP for key storage, so how will crypto fetch the key from ITS to decrypt ITS? You could use a software crypto implementation (another mbed-tls instance) in ITS, but where would you safely store the keys? If you have a two layer ITS, one for only storing the keys for the second instance, and a second, encrypted one, then you end up with something like ITS and PS.
You may not need a full blown on-chip FLASH device for ITS. If you have a HUK available, you can derive the same SP specific keys from that at each boot, and store these in RAM backed ITS. You won’t be able to store other keys in ITS in a persistent way of course, but for that you can use PS. Well, something along these lines.
Perhaps the TF-M team could help better if you could share some details on why your customer would need encrypted ITS. (A PSA for Cortex-A (TS) maintainer chiming in to a “not his business” discussion here 😉 )
/George
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Fabian Schmidt via TF-M
Sent: September 23, 2021 15:51
To: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: Re: [TF-M] Supporting encryption with ITS
Hi George,
I’m wondering if that would add value. To my understanding, ITS was never designed to be encrypted because of the way it’s supposed to be set up. (It’s Internal Trusted Storage.) I believe best practice is to place it in a “trusted” location, one that is ideally only accessible from Secure world, and also ideally on-die. If you then restrict outside access to the internal flash (JTAG, flash programmer ports,…), you’re pretty golden, in that no unauthorized party should be able to read from or write to the ITS.*
Let me know if I misunderstand anything about ITS or TrustZone, but that’s my view. Maybe I’m painting an idealized picture.
Greetings,
Fabian Schmidt
* at least short of a sophisticated physical attack or finding some loophole in TrustZone…
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vasilakis, Georgios via TF-M
Sent: Donnerstag, 23. September 2021 15:28
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [EXT] [TF-M] Supporting encryption with ITS
Caution: EXT Email
Hey all,
Lately the requirement for an encrypted ITS solution is being asked from our customers and I would like to have a discussion here on how we can design this in a reasonable way. The first thought that came to my mind was to add the functionality to the ITS flash-fs layer. This layer contains file metadata in the its_file_meta_t structure and it should be possible to expand this to include additional crypto metadata (conditionally). This seems to be the less invasive change to me, even though it will introduce some increased memory usage since supporting encryption will mean that we cannot read the data in chunks anymore, we will have to use static buffers.
At the same time, I looked at the PS partition since I knew that it has support for encryption. I believe that some core concepts of both solutions have similarities even though the code is quite different. For example, a file in ITS is similar to an object in PS and the (linear) list of file metadata in ITS is similar to the concept of the object table in PS. So, I think that it should be possible to design some generic-enough APIs that we can use for both the ITS and PS. Even though this will require some major refactoring in both partitions, it will decrease the code of these services which will probably decrease maintenance later.
What are your thoughts on this?
Regards,
George
Hi,
The next Technical Forum is planned on Thursday, October 28, 15:00-16:00 UTC (US time zone).
That session Chris Reed kindly agreed to present "Introduction to pyOCD" - the method to program and debug TF-M and Cortex-M MCUs, in general, using the open-source tool https://pyocd.io/
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
