Nearly every embedded system requires some level of security, whether it’s just the basics to lock down the programming port or something more complex to protect a connected device from hackers. For many developers, creating secure embedded systems can be intimidating. Many embedded developers don’t come from a security background and have to learn security concepts on the fly. When it comes to establishing the primary elements for a secure system, there are five key elements:

• Hardware based isolation
• A Root-of-Trust (RoT)
• A secure boot solution
• A secure bootloader
• Secure storage

I originally thought I would cover all of these in one blog, but I quickly realized that I could not do each topic justice with just a few sentences.  For the reader to really understand these topics, they will certainly all require a full blog each. So over the next several months or so, we will dive into each of these topics in greater detail.  In today’s post, we are going to explore hardware based isolation.

Element #1 – Hardware Based Isolation

When it comes to security, the key concept that should reverberate through a developers mind is that security begins with isolation. Developers need to isolate their applications into different domains that each have their own privileges and access to only specific areas of memory. In a traditional embedded system, many applications are architected such that any software module or component can access the entire memory map. If a hacker is able to gain access to a single module in memory, they are able to completely own the system with very little effort.

The idea behind isolation is that with the application is broken up into separate security domains. If a hacker is able to gain access to one area in memory, they won’t be able to access other areas of memory. If they want that access, they have to invest further time and effort to figure out how to break through the isolation barrier. The best way to implement isolation in an embedded system is to implement hardware based isolation, which comes in several different forms and should all be used together.

Isolation Tool #1 – Processor Architecture

First, for applications where security is essential, developers should be using a microcontroller that has hardware based isolation to separate the application execution environment into two distinct environments; secure and non-secure environments. The secure region handles peripherals, memory, and functions that are critical to securing the device. The non-secure environment is the traditional, rich execution environment. In a modern microcontroller, this isolation is achieved in two ways, either through the use of multicore processors like the Cypress PSoC 64 or through the use of single core isolation technology such as Arm’s TrustZone.

Multicore microcontrollers achieve hardware based isolation by having one microcontroller core dedicated to the secure processing environment and one to the non-secure processing environment. This can be seen easily in the image below:

TrustZone on the other hand is just a single core which switches between the secure processing environment and the non-secure processing environment. TrustZone does require a few clock cycles to switch between the environments, but allows a developer to use a single core.

Both single and multicore solutions are interesting and providing the first hardware based isolation layer.

Isolation Tool #2 – Memory Protection Units (MPUs)

The second isolation layer in many secure applications, no matter which primary isolation technique is used, is to further break-up an application using a memory protection units (MPUs). MPUs have become a common tool in microcontrollers because they can be used in security applications and to improve application robustness. In fact, many microcontrollers designed for secure solutions will have MPU’s in both the secure and nonsecure execution environments.

The MPU can be used to create additional boundaries within the memory map that force functions and tasks to only use the memory within their particular process. If for some reason these functions try to access memory outside their assigned region, the MPU will detect the memory violation and fire an exception. The MPU can be used to create secure tasks and partitions, which further isolate the application components.

Isolation Tool #3 – SMPU’s and PPU’s

The final tool to aid in hardware based isolation are SMPU’s and PPU’s.  There are some microcontrollers that are including additional layers of security that allow a developer to share memory contents. These are known as shared memory protection units (SMPU’s). An SMPU can distinguish between different protection contexts within the processor including the differences between secure and nonsecure accesses. These contexts can be extremely useful to develop varying levels of security and access within an application.

Developers can also leverage peripheral protection units (PPUs). A PPU manages access to different peripheral blocks such as a UART, SPI, USB, etc. These accesses can occur within different security contexts that are controlled by SMPU’s that in turn are protecting the context within various MPU contexts that are running on potentially two different cores within the microcontroller! (Or within two hardware isolated regions within a single processor).

Conclusions

When developing a secure embedded system, a developer can leverage these different mechanisms to build barriers and isolate code which makes it much more difficult for hackers to access the system. In fact, I’ve even seen and heard of future security offerings from chip vendors that will allow developers to easily break their execution environments up into many small execution environments in what can be considered execution containers. It’ll be interesting to see over the next several years how sophisticated and capable these schemes will become and if developers implement them, how much more secure their systems will become.

The first element available to developers to implement security within an embedded system is break their application up into hardware isolated execution environments. The hardware based isolation puts up a barrier that makes it more difficult and time consuming for hackers to get full access to a system and the data that is contained on it. Hardware based isolation starts by breaking the execution environment up into secure and nonsecure execution environments and then each of these environments can be broken up further through the use of MPUs, SMPUs and PPUs.

In the next part, we will discuss a system Root-of-Trust, what it is, what it means to developers and some mechanisms we can use to create one.