github-actions[bot]
commented
2 days ago Hi @tomi-font! We appreciate you submitting your first issue for our open-source project. 🌟
Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙
Introduction
The aim is to introduce a subsystem that implements the Platform Security Architecture (PSA) Secure Storage API on platforms without Trusted Firmware-M (TF-M) or similar secure processing environment that implements the API.
The subsystem will allow securely storing data of any kind, with the actual security provided depending on what security features are available on a given platform.
It will also enable persistent storage of keys used in the PSA Crypto API, which is currently lacking because of the PSA Secure Storage API not being available on every platform.
Problem description
Zephyr has decided to adopt the PSA Crypto API as the single API to be used for cryptographic operations (#43712), and recent efforts have been made towards that goal.
The PSA Crypto API contains key management functions that must be called to be able to perform cryptographic operations that make use of keys. Under the hood, those key management functions call into the PSA Secure Storage API to store the key material to persistent storage.
In Zephyr, Mbed TLS is the PSA Crypto provider. However it doesn't provide the PSA Secure Storage API. So the current state is that, on platforms without PSA Secure Storage provider (such as TF-M), keys imported into PSA are kept in a volatile key store, which means that they must be imported into PSA after every power cycle. In practice it's worse than that: pretty much every use of PSA keys imports (and destroys) keys for every cryptographic operation. This is something that should change once Zephyr is able to take full advantage of the PSA Crypto API, to which a prerequisite is a PSA Secure Storage provider on all platforms.
Additionally, Zephyr currently doesn't have a (uniform) way to securely store data to non-volatile memory (NVM). Platforms with a PSA Secure Storage provider are already able to do that, but in a non-portable way that cannot be extended unconditionally to the whole codebase, which hurts its adoption for them as well.
Proposed change
The secure storage subsystem will provide an implementation of the PSA Secure Storage API on platforms that don't already have one.
Most of the initial proposed implementation already exists and lives in the nRF Connect SDK as the trusted storage library.
Detailed RFC
The intent is to have a customizable PSA Secure Storage provider so that different platforms and use cases can be accommodated.
To this end, the secure storage subsystem will be modular and configurable with different implementations, including custom ones.
Proposed change (detailed)
Below is a proposal of the initial architecture of the subsystem.
Exposed interface
The interface exposed to Zephyr and application code by the secure storage subsystem is the PSA Secure Storage API, which consists of the Protected Storage (PS) and the Internal Trusted Storage (ITS) APIs.
From there the subsystem takes on the task of securing and storing the data.
Securing of the data
This part is responsible for what happens with the data before it's written to and after it's read from NVM. It secures the data according to the configured implementation. The configuration, in turn, depends on what security features are available.
The default implementation uses authenticated encryption with associated data (AEAD), which ensures both the confidentiality and authenticity of the data. What algorithm is used, how the key is generated, and how nonces are provided are all separately configurable and custom implementations can replace the existing ones.
The AEAD scheme itself can be replaced by a custom implementation that handles the transformation and validation of the data.
Storage to NVM
This part is responsible for storing the data to and retrieving it from NVM.
The default implementation uses Zephyr's settings subsystem, a well-established means of storing and retrieving key-value pairs.
Just as with the data securing part, other implementations can be used, including custom ones that aren't in Zephyr itself, by implementing the relevant API (set/get/remove functions).
Dependencies
The PSA Crypto API is dependent on the Secure Storage API for a proper functioning. Having a PSA Secure Storage provider on all platforms will help Zephyr in its adoption of the PSA Crypto API.
Concerns and Unresolved Questions