The four-step process—analyze, architect, implement, and certify—gives you a framework to use as you make decisions from idea to production to guarantee that your IoT device has an adequate level of security applied. Based on Arm’s Platform Security Architecture contribution and supported by security assessment labs, the PSA Certified IoT Security Framework.
A Secure Processing Environment (SPE) is a fundamental part of the Arm Platform Security Architecture (PSA), which uses security by separation to safeguard critical assets and code. Trusted Firmware-M (TF-M) provides a reference design of an SPE for Arm M-profile architectures.
Along with providing protected storage, encryption, and attestation, TF-M also offers security services to the application.
The Secure and Non-secure Processing Environments are divided into Trusted and Non-Trusted worlds using hardware-enforced TrustZone technology, which is included nRF5340 and nRF9160 (which use the Armv8-M architecture).
The majority of nRF9160 and nRF5340 apps and samples as of nRF Connect SDK 2.0.0 have TF-M enabled by default. Take a look at the release notes for the nRF Connect SDK v2.0.0. You may learn a lot about the practical application of TF-M by starting with the provided applications and examples.
Separation provides security
The Platform Security Architecture is built on the idea of security through isolation. The device’s security level is raised by adding a layer of isolation by separating security-critical firmware from the application firmware.
For all use cases, sensitive assets including private data, cryptographic keys, login passwords, and firmware must be protected against tampering and exposure. The simplest way to do this is to limit the firmware and hardware that has access to them and to isolate these assets from the firmware and hardware that support the application.”
Utilizing TrustZone and the creation of two images, a Non-Secure and Secure image, security by separation is accomplished while developing for the nRF5340 and nRF9160 using the nRF Connect SDK. The primary user application runs on the Non-Secure image and uses libraries from the nRF Connect SDK together with Zephyr RTOS. The Trusted Firmware-M (TF-M) development system is integrated with the nRF Connect SDK, and it offers a Secure image as well as security services to the user application.
With Security by Separation, the two divided sides are frequently referred to as:
- Secure Processing Environment” and “Non-Secure Processing Environment (SPE)
- Secure as well as Non-Secure
- Trusted vs. Untrusted
The whole firmware architecture of programs using the nRF Connect SDK that implement TF-M is shown in the accompanying image, along with an explanation of its capabilities and guiding principles.
The functional application firmware as we often know it is represented by the Main User Application, Libraries (Including Network Stack, Middleware, etc.), and the Zephyr RTOS visible under the Non-Secure Processing Environment (NSPE).
As shown in the Secure Processing Environment (SPE), the bootloader and Trusted Firmware-M components are separate from the Non-Secure Processing Environment and implement security-critical functions.
Through the use of TrustZone and other hardware memory protection capabilities, various degrees of isolation between the environments may be attained.
Images in Secure and Unsecure Formats
Consider a simple application created with the nRF Connect SDK that uses I2C and UART peripherals and aims to store sensitive information (secrets) in flash memory while utilizing an I2C peripheral to interact with a security-critical external device.
The User Application has access to the whole flash memory address space as well as all peripherals in the absence of security via separation.
In this situation, application firmware defects or flaws might expose access to the memory and/or peripherals that you wish to keep secure.
Separation offers security.
The security level of the preceding example may be raised using Trusted Firmware-M. Secrets can be kept in memory off-limits to User Applications by using the PSA Secure Storage API given by TF-M. Additionally, the I2C peripheral can be marked as Secure, blocking access from Non-Secure applications and providing only a specific interface to the User Application. A door might be locked or unlocked, for instance, or the value of a sensor could be retrieved. However, only under particular circumstances determined by the code operating in the TF-M partition that is connected with the User Application could these actions be performed by the User Application.
Chain of Trust
A Root of Trust can serve as the foundation for a Chain of Trust. The Secure bootloader chain literature provides further details on the Chain of Trust and how it is formed during boot.
The Immutable RoT and the Updatable RoT are just two of the RoTs in the Chain of Trust that are mentioned in the PSA Security Model(1).
Both immutable and updateable RoT
TBSA-M (Trusted Base System Architecture for M) Specification(1):
“An Immutable RoT” is a device made up of hardware, non-modifiable firmware, and factory-installed data.
The Immutable RoT in the nRF5340 and nRF9160 comprises an Immutable Bootloader in addition to several hardware peripherals like the KMU and the OTP.
The remaining parts of the SPE, as shown below, are the Updatable RoT. This comprises, among other things, the secure partition manager (SPM), the root of trust services, and the second-stage bootloader.
Functional API for PSA
The Secure image cannot be directly accessed by the Non-Secure image.
Instead, to access the Platform RoT Services and a portion of the Application RoT Services, the Non-Secure image can utilize the PSA Functional API.
A Non-Secure Callable Interface is used to expose the PSA Functional APIs to the Non-Secure side.
The Non-Secure program, for instance, can use the PSA generate random() function to obtain a secure random number created from the Secure picture.