5 Elements to a Secure Embedded System – Part #1 Hardware-Based Isolation

Nearly every embedded system requires some level of security, whether its just the basics to lock down the programming port or something more complex to protect a connected device from hackers. For many developers, securing their device can be intimidating especially given that 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 that form the foundation for a secure system, the five elements every developer should be looking to implement are:

I originally thought I would cover all of these in one blog, but I quickly realized in order for the reader to really understand these topics, they will certainly all require a full blog each. So over the next month or so, we will dive into each of these topics in greater detail in order to understand how to create a solid security foundation from which a system can be built. 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 see the entire memory map. If a hacker is able to gain access to a single area in memory, they are able to completely own the system with very little effort.

The idea behind isolation is that with the application being 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 without having 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.

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 or through the use of single core isolation technology such as Arm’s TrustZone.

Second, no matter which primary isolation technique is used, developers can further break-up their application into further isolation units in several ways. First, many processors are now including memory protection units (MPUs) 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.

Third, 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.

Finally, 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).

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 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.

Conclusions

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.  

RELATED ARTICLES:

Jacob Beningo is an embedded software consultant who currently works with clients in more than a dozen countries to dramatically transform their businesses by improving product quality, cost and time to market. He has published more than 200 articles on embedded software development techniques, is a sought-after speaker and technical trainer, and holds three degrees which include a Masters of Engineering from the University of Michigan. Feel free to contact him at [email protected], at his website, and sign-up for his monthly Embedded Bytes Newsletter.