Securing embedded systems has become a critical task for developers. It is nearly impossible to turn on the news and not hear about yet another major security breach. So how do you implement the design methodologies necessary to secure your embedded systems using Arm TrustZone for the new Arm Cortex-M processor?
We recently participated in a Q&A session during the highly-popular webinar on “A guide to securing your IoT device with Arm TrustZone for Cortex-M,” presented by Jacob Beningo (CEO of Beningo Embedded Group). He started with a comprehensive overview of TrustZone, showing actual use cases where TrustZone has been successfully used to secure applications. He then offered guidance on best practices for securing an embedded system, as well as recommendations for your next steps.
If you like sneak peeks and live tutorials, you’ll enjoy Jacob’s hands-on demonstration of the new Nuvoton M2351, which is the first Cortex-M processor to support TrustZone. He used Arm Keil MDK to demonstrate how to get TrustZone up and running on both hardware, and also in simulation, using a virtual processor.
View webinar recording
If this webinar interests you, register for our next webinar on Wednesday, 7 March titled “A deeper dive into Armv8-M and TrustZone.” This will be a technical deep-dive into the Armv8-M Architecture, the basis for the Cortex-M23 and Cortex-M33 processors. To reserve your spot, or simply find out more, please select the time zone below that best suits you.
Webinar now passed.
Q: Is secure storage always included secure side on Cortex-M-devices if the device has TrustZone enabled? If not, where is secure storage located? The reason for asking is because on the Cortex-A architecture, TrustZone typically relies on flash in non-secure world to store the actual data.
A: You can use your secure flash space to store secure data that is non-accessible from the non-secure world. Some standard Cortex-M based parts also may have special regions designed for secure storage. For example, if you look at some of the new STMicroelectronics parts, they include a secure memory storage for keys and other secure data.
Q: How does the secure area and non-secure areas communicate with each other? (if they have to)
A: The secure region has access to everything in the microcontroller including the non-secure regions. The non-secure region can only make function calls into the secure region. The functions that can be called from the non-secure world are specified through an interface so that a secure gateway or veneer region is created so that only that specific memory location can be executed in secure space. Attempting to dereference any areas not specified causes an exception to occur.
Q: Is there a way to prevent a debugger from debugging secure world?
A: Yes. If you compile your secure code into a library and distribute that library or just flash the library onto a microcontroller in the secure space, anyone working in the non-secure world will not be able to see the code in the secure region or the secure data. So, if you are debugging non-secure code, you won't be able to see the secure world.
Q: Is there an overhead in terms of power and performance? Also, when transitioning back to secure are registers restored?
A: The performance hit is 3 clock cycles which will result in minimal power overhead. It depends though how often your application is switching between the zones. When switching from secure to non-secure, the non-banked registered are cleared in order to prevent exposing any information to the non-secure world.
Q: What are the main differences in comparison to use a MPU?
A: There is hardware isolation between the secure and non-secure region and only specific function executable regions are made available in the secure region. The secure and non-secure world can still both have an MPU.