After the Getting Started material from the previous weeks, today we are ready to investigate TrustZone®. We all remember TrustZone® – it is that magic piece of embedded IP that miraculously solves all of our IOT security problems – right? It’s true that TrustZone® is an embedded component related to security, but not in the way that you think.

Before we get stuck into all the fancy technical details, let us at first stop and think about some of the challenges that we face with embedded systems, and what can be done about them. This week I simply address the topic: What is TrustZone® and Why do we need it??

More highly-integrated microcontrollers have driven the need for more embedded flash memory onchip, and a trend towards external QSPI memories (see i.MXRT10xx Crossover processors from NXP). 2MByte embedded flash is not unusual in 3Q2019. And where does all this software come from? OK, some of it will be written by us as the embedded software professionals, but it is likely that a good percentage is written by someone else. Who? Well think about FreeRTOS, mbed-TLS, peripheral drivers from SDK… even the boot ROM in modern microcontrollers is (by definition) not written by us.

The providers of that software may have reasons to keep their intellectual property hidden from us. Of course, if the microcontroller contains ROM-based functions then you will want to call them, but at the same time, the software provider may want to limit your ability to reverse-engineer the code. That might be because the ROM contains valuable IP, or because it contains some security secret or ‘secret sauce’ that must be hidden from us.

Take a look at this example:

The green icons on the right-hand side of the diagram represent ROM-based software services installed inside the microcontroller by the supplier/vendor of the mcu. These could be a security library, or a secure bootloader, or licensed software such as a wireless stack or audio DSP algorithms. In each case, the supplier may want to limit our access to the software in such a way that we are able to call the functions in the ROM, but not read the memory (instructions or data) used by the ROM functions.

Our user-code – shown as main() in the red box on the left-hand side – is capable of calling the functions in ROM, but has no other access to the memory owned by the secure ROM. In effect, we have two isolated systems. As the user we have ownership of the non-secure (red) world, the supplier has ownership of the secure (green) world and transitioning between the two worlds is policed by the TrustZone® security extension for the ARMv8-M architecture.

As we’ll learn, TrustZone® casts its shadow over most aspects of our embedded system – memory areas, memory attributes, stacks, NVIC, exceptions and even peripheral features such as GPIO. There is lots to learn and I’ll cover these topics in the next few weeks.

For now, observe that a microcontroller utilising TrustZone® is going to be architected as 2 separate projects. The first project (the ‘secure world’ project) starts up the microcontroller, publishes functions and starts the non-secure world. The second project contains the non-secure world and has access (limited by TrustZone®) to certain parts of the secure world project. Of course, in the case where the microcontroller has a secure-world ROM, we will not be given that MCUXpresso IDE project. Instead we will be given the address of the function table and the calling conventions. But there will still be two projects: our non-secure project and the ‘secret’ one that the supplier did not publish.

I’ve published the video Why do we need TrustZone®? on the embeddedpro® YouTube channel, and you can catch up on my earlier videos there. Don’t forget to subscribe, and you can leave comments in the channel and leave comments in this blog.

Here is this week’s video: