Trusted Execution Framework: practical use-cases (high-level overview)

[ioannisg]

Introduction

This issue intends to list the practical use-case within the Trusted Execution paradigm.
By having a high-level description of each relevant use-case (requirements & challenges), we can facilitate the design of the Trusted Execution framework as part of Zephyr Project.

Use-case description

High-level description only:

1. Secure Bootloader

   • Two images are loaded on the MCU: Secure bootloader and Non-Secure Zephyr RTOS + Application
   • MCU boots in Secure mode, from Secure bootloader. Bootloader verifies the Non-secure firmware.
   • After security attributions are configured, the bootloader prepares to boot to the Non-Secure image.
   • Most of MCU resources (memory, peripherals, IRQs etc.) are allocated to the Non-Secure Zephyr firmware. Certain resources are allocated to Secure bootloader (e.g. secure memory, secure peripherals)
   • secure image is not used after booting into non-secure image, however:
     • functions can still be called (e.g. libraries)
     • security faults are handled

2. Secure storage

   • One composite image, or two separate images are loaded on the MCU.
   • Zephyr RTOS and user application runs in non-secure mode
   • Application uses secure libraries (stored in secure image or in secure areas of the composite image
     and accessible by non-secure callable entry functions) to perform secure storage operations (e.g. store critical data, keys, certificates etc. in the secure regions)
   • non-secure callable region shall be minimized, to remove wasted memory for the interface between the two security domains.

[d3zd3z]

In order for secure storage to be useful, the secure side must also have code for operations that make use of that secure data. For example, if we store a private key, there needs to be an operation to sign something using that key. There shouldn't be a way of getting the key out.

[d3zd3z]

non-secure callable region shall be minimized, to remove wasted memory for the interface between the two security domains.

Ideally, I think the secure veneers could just be an 'sg' followed by a jump to the implementation on secure side. The seem to end up being full functions in the current implementation of tfm, though.

[carlescufi]

No longer relevant

[nkaramolegos]

i would like to store secure a private key in the device flash (nrf 52840-dk). I am bit confused does zephyr supports something like this?