Back to articles
IoT security remains the hot topic of the day. While discussions continue about the bigger picture, Arm TrustZone is a compelling technology for architected security at arguably the most vulnerable point in the chain, the ‘thing’ itself.
TrustZone is a suite of security extension IP for creating Trusted Execution Environments (TEE).
First available for devices using Cortex-A series cores, it has more recently become available in an optimized form for the new Cortex-M series based on the ARMv8 architecture:
- Cortex-M33
- Cortex-M23
- Cortex-M35-P (also offers physical tamper-resistance)
TrustZone technology for Cortex-M cores is a feature of Nordic Semiconductor’s nRF9160 System-in-Package (SiP) for cellular IoT applications.
Embedded is playing catch-up
Embedded IoT products are increasingly wireless. By their nature, such products are constrained in terms of computing and memory capacity and what can be done given cost realities.
This means communication stacks offer the primary means of entry into a system. Physically limiting and controlling what happens on the airwaves close to these devices, whether that is packet sniffing or attempts to inject non-benign communication events, isn't realistic.
Read more: IoT Security: It's time to talk
The constrained nature of such devices means we are trying to ‘build a fortress from pebbles’, so to speak. We must try to do the very best we can in limited conditions. Often this means cutting corners compared to other resource-rich areas of computing.
Personal computers, industrial PCs and Programmable Logic Controllers (PLCs) have the capacity to partition areas of memory with security credentials for system critical resources, and the same is true in the cloud. However, these things are not typically available to constrained embedded design.
Arm TrustZone enters the constrained MCU domain
TrustZone was introduced as part of the ARMv6 architecture. It has played an important role in designs using Arm’s Cortex-A processor cores, which include smartphones, tablets and high-end wearables.
The arrival of the ARMv8-M architectures for Cortex-M processor cores included TrustZone technology. At last, some of the same baked-in security that could be found in more sophisticated systems was available to the world's most popular embedded cores.
How TrustZone works
There are ‘secure’ worlds, and ‘non-secure’ worlds for code, memory and peripherals:
When instructed to run in the secure state, the CPU runs code from secure memory and can interface with secure peripherals. A classic example would be secure boot. From this point the CPU can be handed across to the non-secure state to execute ‘user code’ such as the application, protocol stacks, etc.
Once a root of trust is established, the non-secure elements can make function calls to the functions that exist in the secure world. The non-secure function calls can only access that which has been exposed for such purposes in the secure code.
In this way the CPU acts like two separate CPUs, each with their own resources. At any given point it is handling solely secure or non-secure operations, not both.
Stick to the essentials
Although this is not a developer’s guide to Trust Zone (we’ll post that on DevZone), there are a few good risk reduction practices worth mentioning here.
We must ensure that in a catastrophic situation we can recover and replace all code on a device. Everything outside of this task should be considered potentially fallible.
It’s important to remember that just because we put code into the secure side, it doesn't become robust and reliable. TrustZone doesn’t magically improve inherent quality. That’s the work of development and test teams.
Putting lots of software modules in the secure side increases risk, so our best advice is to keep things simple. Consider what’s needed for secure boot and root of trust establishment, crypto keys and so on. A secure OS and the Device Firmware Upgrade (DFU) mechanism should probably be there too.
Complemented by Arm CryptoCell
TrustZone technology incorporates a range of features for building secure systems. ARM TrustZone CryptoCell IP complements TrustZone and enables even greater separation of assets through hardware. CryptoCell offers extensive support for symmetric and asymmetric cryptographic services and building secure root-of-trust.
Read more: Key-based security for home automation
Changing your development approach
Development consists of building two separate projects: secure and non-secure, each with their own dependencies. These are then compiled into a single image in contiguous flash.
It isn’t a major change, but there are one or two things to watch out for whilst developing this way regarding hand-over mechanisms between the two worlds. Watch out for a Nordic DevZone blog on this topic.
TrustZone vs Secure Element
TrustZone can replace a secure element in designs, but it depends on the needs of the overall system.
A secure element is usually a physically tamper-proof device that acts as a secure repository for critical data such as crypto keys and sensitive data. Communication to and from a secure element is encrypted. Beyond handling the storage and sharing of these data with authorized functions, a secure element doesn't do much else.
This function can be performed with a high degree of security inside the TEE of a TrustZone system, although everything happens on the same device and in the same contiguous flash memory as the non-secure operations. TrustZone itself does not offer the physical anti-tamper protection of a secure element.
When to use TrustZone
First, and foremost, TrustZone should be used to build a root-of-trust for your system with everything needed for a secure boot and system recovery.
Beyond the emergency scenarios, imagine you’re designing a smartwatch that can collect and track health data and perform mobile payments. The watch needs a secure mechanism for identifying the user so that payment details can be securely released to the vendor.
As soon as a need to use the payment system is triggered, the SMC switches from the normal to the secure world and enables the payment app. This can involve a Secure PIN entry system or biometric check to ensure that the details are safe from hacking and the device can only be used by the trusted owner.
With TrustZone handling the user identity and payment systems, it becomes very difficult for the sensitive data to be hijacked. In this way, TrustZone allows devices to be more secure from the ground up.
Another use is Digital Rights Management (DRM) of online media, whereby the access information is kept within the secure world, so hackers can’t access the keys required to reverse engineer the system.
Security by design remains job one
TrustZone isn’t the last word in security and it’s no substitute for a secure-by-design product development process.
It does provide a secure basis to protect the most important aspects of the system, but you need to make sure that everything you build in the normal world is as secure as it can be to avoid inviting problems elsewhere.
You might feel that your device doesn’t handle sensitive data and so TrustZone is unnecessary. As the technology is available, implementing it into your system will protect not only your users and their data but also protect your devices from being hijacked.
TrustZone is a big step forward for designing with Arm’s Cortex-M series, bringing a level of security to single-chip designs not previously available at this level. It is a relative newcomer to Cortex-M and has been included in Nordic Semiconductor’s nRF9160 for cellular IoT, but you can expect to see TrustZone much more often in newer Cortex-M-based SoCs.
