Internet-of-Things (IoT) are everywhere in our daily life. They are used in our homes, in restaurants, at the factories, installed outdoors to control and to report the weather changes, prevent fires, and many more. However, all these may come at risks of security breaches and privacy issues.
To secure the IoT devices, many research works have been conducted, see , , . Numerous countermeasures were proposed and applied to protect IoT. However, with the advent of hardware attacks in the last decade, achieving a high level of security has become more difficult, and attackers can easily bypass many types of protection [4, 5, 6].
Figure 1. Security aspects for embedded system
Developing a safe and efficient data protection mechanisms from scratch Fig. 1 is a time-consuming and costly endeavor. However, the current generations of ARM microcontrollers offer a solid hardware foundation for building security mechanisms. Initially developed for ARM family of CPUs, TrustZone technology was later adopted to MCU implementations of ARM architecture. Software libraries that implement security-related operations based on ARM TrustZone are readily available for Linux family of OSes including those used in Android-based smartphones. The issue is that these libraries are typically developed for CPUs (not MPUs) and are bound to a particular Secure Operating System. This makes it difficult to apply them to microcontroller’s constrained environment where clock speeds are orders of magnitude lower, and RAM available for use is severely limited.
There are several attempts to develop a TrustZone-based security solution for MCU-based systems:
But these solutions are either proprietary (thus, unavailable for an independent source code security review) or have technical limitations.
mTower is an experimental industrial standard-compliant implementation of GlobalPlatform Trusted Execution Environment (GP TEE) APIs based on ARM TrustZone for Cortex-M23/33/35p/55 microcontrollers. From the very beginning, mTower has been designed to have a tiny RAM footprint and to avoid the use of time-consuming operations. The source code of mTower is available at https://github.com/Samsung/mTower
Secure applications that utilize TrustZone protection on MCUs live in two interacting environments: Non-Secure World (NW) and Secure World (SW). The Non-Secure World part is typically a standard RTOS and a number of applications that use the TEE Normal World library containing API functions to interact with the Secure World. The corresponding Secure World is essentially a set of event handlers that are executed in a hardware-protected area of RAM under control of a specially-designed operating system. Secure World processes calls, received from Non-Secure World, and then operates with sensitive data such as cryptographic keys, passwords, user’s identification. Common operations, performed by Secure World of the application, include data encryption/decryption, user authentication, key generation, or digital signing.
Figure 2. mTower architecture
Boot sequence of mTower consists of 3 stages Fig. 2: BL2 that performs initial configuration, BL3.2 that loads and initializes Secure World part of the software, and BL3.3 that is responsible for Non-Secure World part. At each stage, the integrity of the firmware and digital signatures are checked. After the two parts are successfully loaded, control is transferred to the FreeRTOS, whose applications can call handlers from the Secure World. The interaction between the worlds is implemented in accordance with the GP TEE specifications:
• TEE Client API Specification describes the communication between NW applications (Non-Secure Apps) and Trusted Applications (Secure Apps/Libs) residing in the SW;
• TEE Internal Core API Specification describes the internal operations of Trusted Applications (TAs).
Note that most of the source code of these specifications are ported from reference implementation provided by OP-TEE, to make the code easier to maintain and more recognizable by community. Trusted Applications (TAs) that were created for Cortex-A CPU following GlobalPlatform TEE API specifications, can run under mTower with minimal modifications of their source code. mTower repository contains hello_world, aes and hotp demo Trusted Applications that were ported to mTower from OP-TEE examples.
mTower's modular architecture allows for build-time configuration of the required features to optimize memory footprint and performance. Originally, resource management for mTower was based on FreeRTOS real-time operating system. It can be replaced by any other realtime operating systems if needed.
Figure 3. Supported devices
mTower runs on Nuvoton M2351 board that is based on ARM Cortex-M23 and V2M-MPS2-QEMU based on ARM Cortex-M33.
Note that QEMU-based M33 emulation allows for quick start with mTower without having the actual hardware at hand. There are also plans to support other platforms based on ARM Cortex-M23/33/35p/55 family of MCUs.
After completing the full implementation of GP TEE APIs, we plan to provide support for dynamic loading and secure remote update of Trusted Applications. The extension of Resource Manager to provide secure access to H/W is now under discussion. We also consider adding a set of instrumentation hooks in mTower code to simplify GP TEE specification compliance evaluation, performance measurements, assessment and debugging of Trusted Applications.
mTower has been developed to address security requirements for low-cost IoT devices. It provides a way to port GP TEE-compliant Trusted Applications from full-features CPU-based ARM chip to MCU-based systems.
mTower is suitable for research and commercial applications that make use of ARM TrustZone hardware security on MCU-based systems. It can be interesting for:
• Internet-of-Things (IoT) and Smart Home appliance developers
• embedded system developers in general
• computer security specialists
Another mTower target application is using it as a platform for developing secure applications for Edge devices. It allows to evaluate and fine-tune security-related perforamce overhead to address the target operational requirements and provide strong security guarantees. We hope that mTower will contribute to TrustZone-based security adoption for low-cost IoT.
We welcome everyone’s feedback about the mTower. Independent assessment reviews would also be helpful (most recent ones ended up with CVE-2022-36621, CVE-2022-36622, CVE-2022- [40757-40762]). The project is open for everyone willing to make source code contribution.
 Yang, Y.; Wu, L.; Yin, G.; Li, L.; Zhao, H. A Survey on Security and Privacy Issues in Internet-of-Things. IEEE Internet Things J. 2017, 4, 1250–1258
 Deogirikar, J. Security Attacks inIoT: A Survey. In Proceedings of the 2017 International Conference on I-SMAC (IoT in Social, Mobile, Analytics and Cloud) (I-SMAC), Palladam, India, 10–11 February 2017; pp. 32–37.
 Lu, Y.; Xu, L. Da Internet of Things (IoT) Cybersecurity Research: A Review of Current Research Topics. IEEE Internet Things J. 2018
 Timmers, N.; Spruyt, A.; Witteman, M. Controlling PC on ARM Using Fault Injection. In Proceedings of the 2016 Workshop on Fault Diagnosis and Tolerance in Cryptography (FDTC), Santa Barbara, CA, USA, 16 August 2016; pp. 25–35.
 Martín, H.; Korak, T.; Millán, E.S.; Hutter, M. Fault Attacks on STRNGs: Impact of Glitches, Temperature, and Underpowering on Randomness. IEEE Trans. Inf. Forensics Secur. 2015, 10, 266–277.
 Qiao, Y.; Lu, Z.; Liu, H.; Liu, Z. Clock Glitch Fault Injection Attacks on an FPGA AES Implementation. J. Electrotechnol. Electr. Eng. Manag. 2017, 1, 23–27.