IoT & Wireless

Security is no longer optional. Explore 5 ways to simplify IoT security

Security is not something that can be bolted into software or a device several weeks before a product launch. Security needs to be designed into an embedded system from the moment the development project begins – it is now a primary system requirement and driver. While there are several different architectures and methodologies developers can use to secure their devices, an intriguing solution that is gaining wide acceptance is Arm TrustZone for Cortex-M processors. In this article, we will examine five reasons developers should use Arm TrustZone to secure their IoT devices.

Reason #1 – Security from the silicon up

When considering a security solution for an IoT device, it’s important to start from the ground up, which for IoT developers is from the silicon up. What I mean by this is that it’s critical that the processor being used has been designed with security in mind. Processors that support TrustZone such as the Arm Cortex-M23 and Cortex-M33 processors have been designed in exactly this way. If you examine the architecture for one of these processors that include TrustZone support, you’ll find important security features:

Hardware-based isolation

  • Stack pointer limit registers
  • Secure interrupts and memory regions
  • Secure boot
  • Security-aware debugging

The security features that are supported at the silicon level provide the foundation from which a security solution can be implemented.

 

 

Figure 1 – Example features that are provided in the Armv8-M architecture. (Source: Arm)

Reason #2 – Trusted execution environment

An essential component to securing an IoT device is the ability to set up a trust execution environment. Arm TrustZone provides real-time, deterministic hardware isolation that separates the run-time environment into Secure and Non-secure domains. This allows developers to isolate secure code, such as:

  • Cryptographic libraries
  • Private keys
  • Secure peripherals
  • Secure API’s

This secure code can be placed into a trusted execution environment that is isolated from the general user application code.

A TrustZone-enabled processor will boot into the Secure domain immediately from power-on. This allows the developer to establish a secure boot sequence and a chain of trust before jumping to the user application.

 

 

Figure 2 – Arm TrustZone enabled processors boot into a secure firmware project which allows the application to develop a chain of trust before ever starting the user application that executes in the Non-secure domain. (Source: Arm)

Reason #3 – A familiar programming model

When developers start talking about adding security to a device, it’s not unheard of for them to get a little squeamish. Security is new to many Cortex-M developers, and a major concern is what model they need to follow to implement a secure solution. Developers working with TrustZone will find that the programmers’ model is extremely familiar to them. First, they will find that writing application code for the Non-secure domain is identical to the way they have always written their software. Second, software development for the Secure code region will also be familiar with a few added twists. These twists include the ability to assign memory regions and interrupts to Secure or Non-secure execution domains along with creating a veneer layer which acts as a secure gateway between Non-secure callable functions and the Non-secure execution domain.

 

 

Figure 3 – Developers working with TrustZone will find the programming model they are already used to with a few minor twists. (Source: Arm)

Reason #4 – Design momentum

TrustZone for Cortex-M processors has been rapidly gaining momentum. In the past year, there have been many silicon vendors that have announced or released Armv8-M processors that support TrustZone. This momentum is quickly shifting developers from ad-hoc, custom security solutions that cover minimal use cases, too much more secure systems that adhere to the principles that have been laid out in the Arm Platform Security Architecture (PSA).

 

Reason #5 – Peace of mind

Developers who are looking at securing their devices using TrustZone have the peace of mind that TrustZone technology is a proven technology that has been securing devices in the Cortex-A processor family for more than a decade. The move to the Cortex-M series has improved the technology by making it more deterministic so that it fits within the real-time processor domain. TrustZone also fits within the Arm Platform Security Architecture (PSA). The PSA guides designers through the minefield of security, offering a way to achieve consistent security across connected devices. It is a constantly evolving, common foundation with key principles, best practices and deliverables that can be adopted across the entire IoT ecosystem. The deliverables include example threat models, security analysis, hardware and firmware architecture specifications and open-source firmware reference implementation.

Security has become an essential component of developing an embedded system. Arm TrustZone and the Platform Security Architecture provide developers with the building blocks needed to develop a secure solution from the silicon up, while still maintaining that familiar programming model that developers are used to.

To learn more about TrustZone and how to use it to secure your embedded system, check out the Arm TrustZone for Armv8-M Community where you can explore the technology features of the newly released Armv8-M processors. Alternatively, visit my TrustZone Technology Primer for the latest blogs and videos on how to design embedded systems using TrustZone for Armv8-M.

----------------------

Jacob Beningo is an embedded software consultant, advisor and educator who currently works with clients in more than a dozen countries to dramatically transform their software, systems and processes. Feel free to contact him at [email protected], at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter here.

 

 

The editorial staff had no role in this post's creation.