43 / 84
Figure 5:
When using TrustZone,
developers end up with a multi-project
workspace where one project is specifically
for the secure code and the other is for
the user code. (Image source: Keil)
Figure 6:
A TrustZone application starts execution from the secure state and
enters the non-secure state once the root of trust has been established. The
non-secure state can only make function calls to exposed functions within the
secure code, otherwise an exception is thrown. (Image source: Keil)
the system boots, the application
will switch from the secure state to
the non-secure and execute what
is known as the user code. At this
point, the application executes just
like any other embedded application.
The main difference is that the non-
secure code can only access secure
functions and callbacks through a
secure gateway (Figure 6).
If the user application attempts to
access secure code, memory or
peripherals without going through
the secure gateway, an exception
will be generated. Undoubtedly this
means that either there is a bug
in the software, or in a production
environment, a hacker is attempting
to access the system. At this point,
the code can then decide how it
should thwart the attack, such as
restarting the system to remove any
injected code that may be running in
the non-secure SRAM.
Tips and tricks for securing
an embedded application
with TrustZone
There are many techniques that can
help improve embedded security.
Below are several tips and tricks
that will help developers interested
in using the Armv8-M architecture
with TrustZone:
Use the secure zone during reset
to establish a root of trust and a
trusted execution environment.
Put security critical tasks, libraries,
and keys into the secure zone.
Let the user code be placed in the
non-secure zone.
To keep things simple, put the
RTOS kernel in one place, either the
secure or the non-secure zone.
Use the MPU in the secure and
non-secure zones to improve process
isolation.
Minimizing the code in the secure
zone can help to minimize the secure
codes attack surface.
Make sure that secure code clears
any secret information from unbanked
registers before initiating a transition
from the secure to non-secure state.
Conclusion
Securing a microcontroller-based
application for the IoT is important
but tricky. Security starts at the
hardware level, but many traditional
microcontroller families running
Cortex-M0+, Cortex-M3/4/7 cores
may lack the features necessary
to successfully secure the device.
Developers can now leverage the
new Armv8-M architecture on the
Cortex-M23 and Cortex-M33 cores to
secure their embedded applications
using a rising number of processors
using the architecture.
New-Tech Magazine Europe l 43