USD

IoT Security Fundamentals—Part 4: Mitigating Runtime Threats

By Stephen Evanczuk

Contributed By Digi-Key's North American Editors

Editor’s Note: Despite the proliferation of IoT devices, securing these devices remains an on-going concern, to the degree that security challenges can be a barrier to adoption of connected devices in Industrial IoT (IIoT) and mission-critical applications where corporate and personal data may be compromised in the event of a successful attack. Securing IoT applications can be daunting, but in reality IoT device security can be built upon a few relatively straightforward principles that are supported by hardware security devices. By following well-established security practices, these concerns can be addressed. This multi-part series provides practical guidance to help developers ensure best practices are followed from the outset. Part 1 discusses the cryptographic algorithms underlying secure designs. Part 2 discusses the role of private keys, key management, and secure storage in secure IoT designs. Part 3 examines the mechanisms built into secure processors to mitigate other types of threats to IoT devices. Here, Part 4 identifies and shows how to apply security mechanisms in advanced processors to help ensure the isolation needed to mitigate attacks on the runtime environment of IoT devices. Part 5 describes how IoT security continues from IoT devices through higher level security measures used to connect those devices to IoT cloud resources.

Hardware-based cryptography with secure storage provide the foundation required to implement secure IoT designs. Secure boot and secure firmware over-the-air (FOTA) update use this foundation to build a root of trust for software execution. Nevertheless, an Internet of Things (IoT) device requires continued protection from software that can accidentally or intentionally compromise secure resources accessed by a software application and system code being executed in the runtime environment.

This article describes how developers can use security mechanisms integrated into some processors from NXP Semiconductors, STMicroelectronics, and others to more effectively protect systems from threats that occur during software execution.

How runtime software can be subverted

As discussed in earlier parts of this series, ciphers, secure key storage, and secure boot and firmware update provide necessary building blocks for IoT security. Although these capabilities are critical contributors to overall IoT device security, they can present an incomplete solution to attacks designed to subvert runtime software in connected systems. Ideally, attempts to penetrate the lines of defense provided by these mechanisms would fail thanks to the trusted environment built on the root of trust created through secure boot. In practice, systems built with these robust security capabilities can be—and have been—compromised by attacks that inject a piece of corrupt code or malware into the system.

Using a wide variety of methods, hackers can exploit security vulnerabilities in one part of a system to attack other parts. Buffer overflow attacks, for example, exploit software applications that allow large input data streams to write past the intended buffer area. If that overflow data contains code, the processor could later execute it, providing hackers with an entry point to further attacks. Using these and other methods, hackers gradually widen their penetration into broader parts of a system.

Vulnerabilities can exist in any software component in any layer of a system's software stack. As developers work to create more functionally-rich systems, the need for more software components increases the chance that their systems will suffer more vulnerabilities. At the same time, the variety of vulnerabilities found in software continues to grow. For example, the authoritative Common Vulnerabilities and Exposures (CVE®) List of publicly known cybersecurity vulnerabilities showed a 15% year-over-year increase in Q1 2020.

Tiers of protection protect critical software

Threat mitigation is a constant battle between black hat hackers and white hat security specialists. Although threats will continue to appear, developers can significantly harden security in their designs by taking advantage of methods designed to isolate the multiple different software processes required in a typical application. For years, secure systems have been built upon a tiered protection approach. In this classical approach, concentric rings of protection provide increasing levels of isolation in a system. Applications running on the outermost layer are restricted from accessing device drivers and system services in inner layers, which are in turn restricted from accessing the software kernel in the innermost layer (Figure 1).

Diagram of a tiered protection approachFigure 1: Secure software systems protect applications, drivers, and operating system kernels in rings of protection that present progressively greater protection. (Image source: Wikipedia)

Intel x86 devices starting with the 80286, now available from Rochester Electronics, supported four levels, designated using a selector register that included a two-bit requested privilege level (RPL) field. Modern processor architectures such as Arm's® TrustZone have significantly extended security capabilities through a variety of mechanisms designed to isolate user processes during runtime. Developers can find this kind of tiered protection capability in a number of embedded systems processors including:

Arm TrustZone for Cortex-M brings enhanced security capabilities to Arm Cortex-M embedded system processors, such as the NXP LPC55S69JBD100K and STMicroelectronics’ STM32L552VET6. TrustZone for Cortex-A provides similar capabilities for Arm Cortex-A-based application processors such as the NXP i.MX 8M Mini MIMX8MM6DVTLZAA and STMicroelectronics’ STM32MP157AAC3T.

For each Arm series, TrustZone offers mechanisms that support secure boot and secure code, data, and memory, among other security features. Designed to support low-latency requirements of embedded systems, TrustZone for Cortex-M processors features performance enhancements including fast secure interrupts and fast hardware-based transitions between security states. This article describes TrustZone for Cortex-M processors focusing on a pair of processors representative of this class: NXP LPC55S69JBD100K and STMicroelectronics STM32L552VET6.

Processor operating modes enable extended protection

At the heart of the TrustZone architecture, processors can run in multiple operating modes that support the isolation of software processes and system resources. Processor “secure” and “non-secure” modes provide a way to isolate trusted processes from untrusted processes. Processor “handler” and “thread” modes provide a separate protection mechanism that offers further granularity in isolating processes and resources.

In the TrustZone architecture, a processor running in handler mode causes software to always run in privileged mode. As such, it is the recommended mode to use for running software such as a real-time operating system (RTOS) or accessing the boot image, secure keys, and other resources critical for system operation. In thread mode, software runs in unprivileged mode, but privileged processes can change the privilege level of software running in this mode. Thread mode is typically used for running application code.

Used in combination, secure/non-secure and handler/thread modes deliver the same sort of tiered protection as found in earlier systems supporting rings of protection. Using the STMicroelectronics STM32L552VET6, for example, developers can isolate trusted code with full privileges from untrusted code with minimal privileges (Figure 2).

Diagram of STMicroelectronics STM32L552VET6 TrustZone processorFigure 2: TrustZone processors such as the STMicroelectronics STM32L552VET6 provide a combination of processor modes that allow developers to isolate trusted system software such as boot images from untrusted application code such as third-party radio frequency (RF) communications stacks. (Image source: Digi-Key, from STMicroelectronics source material)

Isolation mechanisms integrated into these processors restrict each processor's ability to access different areas of program data memory. For example, when the NXP LPC55S6x core is in the secure state, it cannot access non-secure program memory, although it can still reach non-secure data memory. On the other hand, when the LPC55S6x core is running in the non-secure state, it can only access non-secure program memory and data memory (Figure 3).

Diagram of NXP’s LPC55S6x devicesFigure 3: Processors such as NXP’s LPC55S6x devices can ensure that the core is running in the secure state (S state) to read secure program memory (green) or in the non-secure state (NS state) to read non-secure program memory (red). (Image source: NXP Semiconductors)

When running in the secure state to execute trusted software, these processors cannot fetch instructions from non-secure program memory. Conversely, when running in the non-secure state to execute untrusted software such as application code, these processors cannot access code or data located in secure areas. Nevertheless, application code typically requires the ability to execute trusted code in secure libraries. TrustZone processors allow developers to meet this requirement by defining non-secure callable (NSC) memory regions that provide allowed entry points to secure libraries (Figure 4).

Diagram of non-secure callable regionsFigure 4: Non-secure callable regions provide secure entry points from non-secure to secure memory regions, allowing non-secure applications to execute functions in secure libraries. (Image source: STMicroelectronics)

Memory aliases enhance security

TrustZone processors like the NXP LPC55S69JBD100K and STMicroelectronics STM32L552VET6 manage execution by aliasing physical program memory into secure and non-secure memory spaces. For example, the STMicroelectronics STM32L552VET6 aliases code in flash and SRAM twice—once into a non-secure address range (0x0800_0000 to 0x0BFF_FFFF) and again into a secure address range (0x0C00_0000 to 0x0FFF_FFFF). Similarly, the NXP LPC55S69JBD100K aliases physical program memory into a non-secure space starting at 0x0000_0000 and also into a secure space starting at 0x1000_0000. Each of these processors uses a similar approach for other memory types and peripherals, aliasing them twice into secure and non-secure regions.

When the processor needs to access a memory location, the ability to access that location is determined by a security attribute generated by two hardware units:

  • Implementation Defined Attribution Unit (IDAU), which is a fixed hardware unit external to the processor core that provides a fixed security status of the memory map as defined by the manufacturer.
  • Secure Attribution Unit (SAU), which is a programmable unit integrated in the processor core used to define the security status of up to eight memory regions.

During system initialization, configuration routines running in secure mode define the security status of each region by setting a few SAU registers including:

  • SAU Region Number Register (SAU_RNR) to select a region for further operations
  • SAU Region Base Address Register (SAU_RBAR) to define the starting address of the region
  • SAU Region Limit Address Register (SAU_RLAR) to define the extent of the region

Included in its STM32Cube MCU software package for the STM32L5 series, STMicroelectronics provides multiple template files that demonstrate use of processor features including SAU configuration. As shown in Listing 1, developers can define these regions for each configuration parameter using a macro (SAU_INIT_REGION(n)) that sets the register values in a SAU structure used when configuration settings are written to the device.

Copy
/*
//   <e>Initialize SAU Region 0
//   <i> Setup SAU Region 0 memory attributes
*/
#define SAU_INIT_REGION0    1
 
/*
//     <o>Start Address <0-0xFFFFFFE0>
*/
#define SAU_INIT_START0     0x0C03E000      /* start address of SAU region 0 */
 
/*
//     <o>End Address <0x1F-0xFFFFFFFF>
*/
#define SAU_INIT_END0       0x0C03FFFF      /* end address of SAU region 0 */
 
/*
//     <o>Region is
//         <0=>Non-Secure
//         <1=>Secure, Non-Secure Callable
*/
#define SAU_INIT_NSC0       1
/*
//   </e>
*/
 
/*
//   <e>Initialize SAU Region 1
//   <i> Setup SAU Region 1 memory attributes
*/
#define SAU_INIT_REGION1    1
 
/*
//     <o>Start Address <0-0xFFFFFFE0>
*/
#define SAU_INIT_START1     0x08040000      /* start address of SAU region 1 */
 
/*
//     <o>End Address <0x1F-0xFFFFFFFF>
*/
#define SAU_INIT_END1       0x0807FFFF      /* end address of SAU region 1 */
 
/*
//     <o>Region is
//         <0=>Non-Secure
//         <1=>Secure, Non-Secure Callable
*/
#define SAU_INIT_NSC1       0
/*
//   </e>
*/
   .
   .
   .
**
  \brief   Setup a SAU Region
  \details Writes the region information contained in SAU_Region to the
           registers SAU_RNR, SAU_RBAR, and SAU_RLAR
 */
__STATIC_INLINE void TZ_SAU_Setup (void)
{
 
#if defined (__SAUREGION_PRESENT) && (__SAUREGION_PRESENT == 1U)
 
  #if defined (SAU_INIT_REGION0) && (SAU_INIT_REGION0 == 1U)
    SAU_INIT_REGION(0);
  #endif
   .
   .
   .
#define SAU_INIT_REGION(n) \
    SAU->RNR  =  (n                                     & SAU_RNR_REGION_Msk); \
    SAU->RBAR =  (SAU_INIT_START##n                     & SAU_RBAR_BADDR_Msk); \
    SAU->RLAR =  (SAU_INIT_END##n                       & SAU_RLAR_LADDR_Msk) | \
                ((SAU_INIT_NSC##n << SAU_RLAR_NSC_Pos)  & SAU_RLAR_NSC_Msk)   | 1U
 

Listing 1: Included in templates in STMicroelectronics’ STM32Cube MCU software package for the STM32L5 series, this snippet shows how developers define memory regions and their associated security status. (Code source: STMicroelectronics)

The IDAU and SAU work in concert to determine if the memory location is accessible, returning the highest security level of the two. As a processor works with the memory alias corresponding to its secure/non-secure operating state, the security attribute generated by the combination of the IDAU and SAU ensures accessibility only to regions with the matching security level (Figure 5).

Diagram of NXP LPC55S69JBD100K IDAU and SAU (click to enlarge)Figure 5: In the NXP LPC55S69JBD100K, the IDAU and SAU combine to generate a security attribute for each memory alias, effectively removing code not allowed to run out of each respective region. (Image source: NXP Semiconductors)

For example, when the NXP LPC55S69JBD100K is operating in secure mode, the security attribute generated by the IDAU and SAU will prevent access to non-secure applications contained in the secure alias of a block of physical memory, effectively eliminating that non-secure code from the secure alias. Conversely, when the processor is operating in non-secure mode, the IDAU and SAU security attribute will effectively eliminate secure applications from the resulting non-secure alias.

Setting privilege and access control

While the IDAU and SAU directly enforce secure and non-secure access restrictions, they work with secure and non-secure memory protection units (MPUs) to determine the access rights associated with the target resource (Figure 6).

Diagram of NXP LPC55S69JBD100K TrustZone processorFigure 6: In TrustZone processors such as the NXP LPC55S69JBD100K illustrated here, the security attribute generated by the SAU and IDAU combines with settings managed by secure and non-secure MPUs to deliver privilege level along with security level. (Image source: NXP Semiconductors)

Built into these processors, the MPU provides fine-grain access control of memory resources. In the STMicroelectronics STM32L552VET6, for example, the MPU supports a variety of access rights that differ when the processor is running in privileged handler mode or in unprivileged thread mode (Table 1).

Table of STMicroelectronics STM32L552VET6 privileged vs unprivileged modesTable 1: The STMicroelectronics STM32L552VET6 allows developers to use its MPU to define different levels of access that operate differently in privileged and unprivileged mode. (Table source: STMicroelectronics)

Among those attributes, the Execute Never (XN) attribute enables developers to ensure that the processor never attempts to execute code from the associated memory region, providing another level of runtime protection. For example, in systems running code directly from flash, developers can set the XN attribute for unused SRAM regions to eliminate any possibility that the system would be compromised even if malware injection attacks succeed with those areas.

Extending protection to more peripherals and memory

The IDAU, SAU, and MPU features of these processors provide a flexible foundation for protecting runtime execution of both system software and applications, but these capabilities are limited to the processor itself. Processors such as the NXP LPC55S69JBD100K and STMicroelectronics STM32L552VET6 carry the secure and privilege capabilities over to other memory systems and interfaces through a variety of approaches.

For its STM32L552VET6, STMicroelectronics complements the native TrustZone mechanism with its own global TrustZone controller (GTZC) designed to protect peripherals, embedded SRAM, and external memories (Figure 7).

Diagram of STMicroelectronics STM32L552VET6 processorFigure 7: The STMicroelectronics STM32L552VET6 processor integrates a global TrustZone controller (GTZC) that extends security protection to peripherals and memory not included in the native TrustZone framework. (Image source: STMicroelectronics)

In the NXP LPC55S69JBD100K, the privilege attribute (HPRIV) and secure attribute (HNONSEC) are carried across the internal Advanced High-performance Bus (AHB) matrix to reach Memory Protection Checkers (MPCs), Peripheral Protection Checkers (PPCs), and Master Security Wrappers (MSWs) for other bus masters (Figure 8).

Diagram of NXP LPC55S69JBD100KFigure 8: In the NXP LPC55S69JBD100K, the privilege and security levels are transmitted to additional hardware units that apply these attributes to operations involving memory, peripherals, and other bus masters. (Image source: NXP Semiconductors)

Although it is important to have an understanding of the underlying mechanisms for software isolation and system protection, developers can take advantage of development support to quickly apply these capabilities in their own designs.

STMicroelectronics provides its STM32L552E-EV, STM32L562E-DK, and NUCLEO-L552ZE-Q evaluation boards as a rapid prototyping platform for building applications based on its STM32L5 processors. The company's STM32CubeIDE integrated development environment (IDE) provides a comprehensive environment for software programming, and its STM32CubeProgrammer offers both graphical user interface (GUI) and command line interface (CLI) versions for programming internal and external memories. Using this tool, developers can, for example, define secure regions in flash memory (Figure 9).

Image of STMicroelectronics STM32CubeProgrammerFigure 9: The STMicroelectronics STM32CubeProgrammer offers a simple approach for defining secure regions in flash memory. (Image source: STMicroelectronics)

For rapid development of systems based on NXP’s LPC55S69 processors, developers can build designs on the NXP LPC55S69-EVK evaluation board. For system configuration and software programming, the NXP MCUXpresso IDE provides a comprehensive platform for creating applications based on NXP LPC55S69 processors.

Conclusion

IoT security depends on fundamental security mechanisms for cryptography and secure storage, as well as capabilities for building applications on a root of trust based on hardware security mechanisms. Although these are all necessary for security, they are rarely sufficient to counter ongoing threats designed to exploit vulnerabilities in system runtime environments. Using tiered protection mechanisms available in a growing array of processors, developers can build secure IoT devices better able to mitigate these threats and reduce or eliminate their impact on IoT applications.

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of Digi-Key Electronics or official policies of Digi-Key Electronics.

About this author

Stephen Evanczuk

Stephen Evanczuk has more than 20 years of experience writing for and about the electronics industry on a wide range of topics including hardware, software, systems, and applications including the IoT. He received his Ph.D. in neuroscience on neuronal networks and worked in the aerospace industry on massively distributed secure systems and algorithm acceleration methods. Currently, when he's not writing articles on technology and engineering, he's working on applications of deep learning to recognition and recommendation systems.

About this publisher

Digi-Key's North American Editors