Nordic Semiconductor recommends following the PSA Certified IoT Security Framework in your product development process. The four-step process of analyze, architect, implement, certify, provides a framework to guide your decisions from concept to production to ensure an appropriate level of security is implemented in your IoT device. The PSA Certified IoT Security Framework is based on the Platform Security Architecture contributed by Arm and backed by security evaluation laboratories.
Trusted Firmware-M (TF-M) provides a reference design of a Secure Processing Environment (SPE) for Arm M-profile architectures, the SPE is a foundational component of the Arm Platform Security Architecture (PSA) which relies on security by separation to protect sensitive assets and code. TF-M also provides security services to the application such as Protected Storage, Cryptography, and Attestation.
TrustZone technology included in Nordic Semiconductor nRF5340 and nRF9160 (which implement the Armv8-M architecture) provides hardware-enforced separation of the Secure and Non-secure Processing Environments into Trusted and Non-Trusted worlds.
From nRF Connect SDK 2.0.0, TF-M is enabled by default for most nRF9160 and nRF5340 applications and samples. See the nRF Connect SDK v2.0.0 Release Notes. The included applications and samples provide a good starting point for you to understand the practical implementation of TF-M.
DISCLAIMER: Currently, only the Minimal TF-M configuration is Supported. Configuring TF-M to use features beyond the minimal configuration is Experimental. For up-to-date support status see Trusted Firmware-M support for Latest
Table of Contents
Security by Separation
The concept of security by separation is the foundation of the Platform Security Architecture. Separating security critical firmware from the application firmware introduces a layer of isolation, increasing the security level of the device.
"All use cases rely on the protection of the sensitive assets, for example, private data, cryptographic keys, credentials, and firmware, from disclosure or modification. This is best achieved by limiting the firmware and hardware that has access to them and separating these assets from the application firmware and hardware."
(Trusted Base System Architecture for M (TBSA-M) Specification(1), section 3.1 Security by Separation)
When developing for nRF5340 and nRF9160 using nRF Connect SDK, security by separation is achieved by leveraging TrustZone and the build of two images, a Non-Secure, and Secure image. The Non-Secure image is the main user application, utilizing libraries within nRF Connect SDK and running Zephyr RTOS. The Secure image is provided by Trusted Firmware-M which provides security services to the user application, the TF-M build system is integrated with nRF Connect SDK.
With Security by Separation, the two separated sides are often referred to as the following:
- Non-Secure Processing Environment (NSPE) and Secure Processing Environment (SPE)
- Non-Secure and Secure
- Non-Trusted and Trusted
TF-M Architecture
The following figure gives an overview of functionality and principles in TF-M and the entire firmware architecture in applications implementing TF-M in nRF Connect SDK. This blog post will explain the functionality and purpose of these components.
The Main User Application, Libraries (Including Network Stack, middleware, etc..), and the Zephyr RTOS seen under the Non-Secure Processing Environment (NSPE) represent the functional application firmware as we normally know it.
Trusted Firmware-M and bootloader components seen under the Secure Processing Environment (SPE) are isolated from the Non-Secure Processing Environment and implement security-critical functionality.
Multiple levels of isolation can be achieved between the environments through a combination of TrustZone and other hardware memory protection features.
Secure and Non-Secure Images
No Security by Separation
As a case study, we can consider a basic application built in nRF Connect SDK using I2C and UART peripherals, where our I2C peripheral is used to interface with a security-critical external device and we wish to store sensitive data (secrets) in flash memory.
Without security by separation, the User Application has access to the entire flash memory address space and all peripherals.
In this scenario, it is possible for bugs or faults introduced in the application firmware to expose access to the memory and/or peripherals that you want to protect.
Security by Separation
Trusted Firmware-M can be used to increase the security level of the previous example. The PSA Secure Storage API exposed by TF-M can be used to store secrets in memory not accessible to the User Application. In addition, the I2C peripheral can be designated as Secure, preventing access from the Non-Secure application and only exposing a defined interface towards the User Application. For example, this interface may be defined to allow the User Application to perform a specific task such as retrieve the value of a sensor, or lock or unlock a door, only under certain conditions which are decided by the code running within the associated partition in TF-M.
See the TF-M secure peripheral partition sample for an example of how hardware peripherals can be separated with Secure/Non-Secure access restrictions.
Secure and Non-secure in nRF Connect SDK
When building for a board, you must choose a board name. As you may have seen when building, the variant can be "ns". For example, When building for the nRF9160DK, you can build for either nrf9160dk/nrf9160 or nrf9160dk/nrf9160/ns.
nrf9160dk/nrf9160: The application is built as a single image, without any separation.nrf9160dk/nrf9160/ns: The application will be built as a Non-Secure image. TF-M will automatically be built as the Secure image. The two images will be merged to form a combined image that will be used when programming or updating the device. See Processing environments for docs.
A common misunderstanding comes from the naming of the builds, because "ns" is short for "non-secure", it is easy to think that building for nrfd9160dk/nrf9160/ns is less secure. But it is indeed the other way around!
If your application firmware is built for the secure processing environment, everything in your application is inherently trusted and you will not have Security by Separation.
If your application firmware is built for the non-secure processing environment, TF-M firmware will automatically be included in the build. The non-trusted application firmware and the trusted TF-M firmware will both be included in the finished hex file, and you have Security by Separation.
Therefore, to get TF-M and the security it provides, you need to build the user application for nrf9160dk/nrf9160/ns.
Root of Trust (RoT)
One of the key concepts in Trusted Firmware-M is the Root of Trust (RoT).
"A RoT can be described as a set of implicitly trusted functions that the rest of the system or device can use to ensure security;"(2)
To learn more about the Root of Trust concept, see psacertified: What is a Root of Trust? and the PSA Security Model(1).
Chain of Trust
A Chain of Trust can be built on a Root of Trust. Further information on the Chain of Trust and how it is established during boot is available in the Secure bootloader chain documentation.
The PSA Security Model(1) refers to several RoT's along the Chain of Trust: such as the Immutable RoT and Updatable RoT.
Immutable RoT and Updatable RoT
From the Trusted Base System Architecture for M (TBSA-M) Specification(1):
"An Immutable RoT, which is the combination of hardware and non-modifiable firmware and data
installed during manufacturing"
In the nRF5340 and nRF9160, the Immutable RoT consists of an Immutable Bootloader, plus certain hardware peripherals such as the Key Management Unit (KMU) and One Time Programmable (OTP) memory.
The Updatable RoT is the remainder of the components in the SPE, as illustrated below. This includes amongst other the second stage bootloader, as well as the secure partition manager (SPM) and the root of trust services.
See the marked areas for immutable Rot and Updatable RoT in the Figure:
Immutable Bootloader and Second Stage Bootloader
Bootloaders ensure that all software being executed has been authorized and that your application is protected against running altered code.
In addition, a bootloader is required to perform security updates which fix eventual vulnerabilities or adds new security features.
Bootloader concepts and available bootloaders for the nRF Connect SDK are explained in our documentation on Bootloaders and Device Firmware Updates.
Root of Trust Services (RoT Services)
The SPE has a set of services available for use. These are known as RoT Services.
All RoT Services are available inside the Secure image.
RoT Services can be made available to the Non-Secure image through the Non-Secure Callable Interface, or in other words the PSA Certified API as referred to in the next section.
There are two types of RoT Services: Platform RoT Services and Application RoT Services.
Platform RoT Services
Defined by the PSA Security Model section 7(1), the Platform RoT Services is a set of mandatory RoT Services.
These are:
- Crypto: An RoT Service which provides an API to cryptographic operations, such as securely generating, storing, or accessing keys.
See the PSA Cryptography API and Cryptography samples. - Attestation: From Platform Security Model 1.1: 7.3 Initial Attestation Service(1):
"The Initial Attestation Service (IAS) provides a signed Initial Attestation Token (IAT). The IAT includes the state of
the Platform Root-of-Trust, including whether a debug state has been entered, and any claims made by AEP."
For an explanation of attestation, see Device Attestation and Entity Attestation Tokens Explained. - Internal Trusted Storage (ITS): A RoT Service which provides trusted storage of key material in internal flash.
Note that the PSA Crypto APIs provide functionality to manage keys stored in the PSA ITS. Therefore, there is no need to expose PSA ITS as a secure service to the Non-Secure image.
Application RoT Services
The Application RoT Services are application-specific services, meaning that they can be included if needed by the application.
Some Application RoT Services are pre-defined, but the application developer can add custom Application RoT Services.
- Protected Storage is an example of a pre-defined Application RoT Service.
See the PSA Storage API and Zephyr PSA Protected Storage Sample. - Our TF-M secure peripheral partition showcases how to create a custom Application RoT Service.
In the figure, a line separates Application RoT Services from the rest of the SPE. This separation will be covered in the section on Isolation Levels.
The main difference between this Protected Storage API and the ITS API is that ITS is only used from the SPE, while Protected Storage is exposed to the NSPE through the IPC.
See the PSA Storage API(1) for more information on the difference between those, especially 1.1 Use Cases and Rationale.
PSA Certified API
The PSA Certified APIs are explained in more detail in the blog-post Securing IoT products with PSA Certified APIs.
The Non-Secure image cannot access the Secure image directly.
Instead, the Non-Secure image can call on the PSA Certified API to get access to the Application RoT Services as well as a subset of the Platform RoT Services.
The PSA Certified APIs are exposed to the Non-Secure side using a Non-Secure Callable Interface.
For example, the Non-Secure application can call the psa_generate_random() to get a secure random number generated from the Secure image.
For details on the hardware implementation of this, see the Non-secure callable (NSC) region definition in flash.
TF-M Core
The Internal TF-M functionality responsible for isolation, communication and execution within SPE and with NSPE is referred to as TF-M Core.
The user application does not need to directly interface with TF-M Core as it automatically operates in the background of the TF-M implementation. For completeness sake, here is an overview of its functionalities:
- Use the TF-M Secure Partition Manager(SPM) to configure Secure/Non-Secure flash and memory.
- Use the TF-M Secure Partition Manager(SPM) to Initialize Secure/Non-Secure hardware peripherals
- Use the TF-M Inter-Process Communication (IPC) to allow communication between the Secure and Non-Secure images.
- Use the TF-M Inter-Process Communication (IPC) to allow communication between services inside the Secure images.
- Handles interrupts in a secure way. See Secure Interrupt Integration for more information.
The SPU Hardware Peripheral is utilized for this functionality in the nRF9160 and nRF5340.
More documentation on the TF-M Inter-Process Communication (IPC) can be found in the Trusted Base System Architecture for M (TBSA-M) Specification(1).
A visualization of the communication flow when using PSA Certified APIs can be seen from the arrows in the overview figure, also seen below:
Isolation Levels
Three PSA Isolation Levels are defined in the Trusted Base System Architecture for M (TBSA-M) Specification(1), section 4.3:
|
Isolation Level
|
Description
|
|---|
| Level 1 | SPE isolation Two security domains SPE is protected from access by Non-Secure application firmware and hardware |
| Level 2 |
Platform RoT isolation Three security domains In addition to Level 1, the Platform RoT is also protected from access by the Application RoT |
| Level 3 |
Maximum firmware isolation |
In other words:
- Level 1 Isolation is the Secure/Non-Secure separation described in the "Secure and Non-Secure Images" section.
- Level 2 Isolation means that the Application RoT Services are unable to access other parts of the SPE.
- Level 3 Isolation means that the Application RoT Services are unable to access other parts of the SPE and other Application RoT Services.
The isolation levels are shown in the TF-M Architecture diagram.
References
- Documentation on Arm Security Architectures can be found at https://www.arm.com/architecture/security-features/platform-security
- https://www.psacertified.org/blog/what-is-a-root-of-trust/