The anatomy of security microcontrollers for IoT

A study from ABI Research estimated that less than four percent of IoT devices sold last year featured embedded security. At the same time, the market research firm forecasts that, by 2020, nearly 25% of cyber attacks will target IoT devices, making the security MCUs a hot potato.

But what is a security MCU? Many MCUs claim to offer security features, but a closer look reveals that it’s mostly lip service. This article digs deeper into the traits that define a security MCU. It will delve into the properties and features that distinguish a secure MCU from one that just makes a claim.

Let’s begin with the MCU suppliers’ quest to complement their hardware-based security solutions with an extra layer of security for bolstering defence against software vulnerabilities and network-based attacks.

Tale of two collaborations

The advent of endpoint devices operating at the network edge calls for secure over-the-air (OTA) firmware updates. The RX651 microcontrollers from Renesas address this reprogramming requirement by integrating Trusted Secure IP (TSIP) and trusted flash area protection, which enables flash firmware updates in the field through secure network communications.

The TSIP offers robust key management, encrypted communication, and tampering detection to ensure strong security against external threats such as eavesdropping, tampering, and viruses (Figure 1). Likewise, the integrated dual bank flash memory makes it easier for device manufacturers to execute in-the-field firmware updates securely and reliably.

Above: Figure 1. A view of the security building blocks (centre right) in the RX651 microcontroller. (Image source: Renesas Electronics)

The dual bank flash enables embedded system designers to realise the high root-of-trust levels through a combination of TSIP for protecting the encryption keys and encryption hardware accelerators such as AES, 3DES, RSA, SHA, and TRNG. Then there’s code flash area protection to safeguard the boot code from unauthorised reprogramming.

Next, Renesas has partnered with Secure Thingz, an embedded systems security expert, for the secure provisioning of its RX family of 32-bit microcontrollers. For that, Renesas will support the Secure Deploy architecture that Secure Thingz has created to simplify the security implementations across design and manufacturing value chains.

Another MCU supplier that has teamed up with an embedded security solution provider is STMicroelectronics. The chipmaker is collaborating with Arilou Information Security Technologies to create a multi-layer security arrangement in which hardware and software can complement each other to monitor the data streams and detect communication anomalies.

Above: Figure 2. This is how the IDPS software detects the traffic and other roadside anomalies. (Image source: Arilou)

STMicro’s SPC58 Chorus series of 32-bit automotive microcontrollers embed a Hardware Security Module (HSM) that protects sensitive security information such as cryptographic keys and thus ensures protection against intrusion via communication buses in automotive body and gateway applications. HSMs provide the hardware-based root of trust to facilitate secure communications, OTA updates, and secure boot.

Now ST has added Arilou’s Intrusion Detection and Prevention system (IDPS) software to its SPC58 Chorus series of automotive MCUs to detect traffic anomalies and form an extra layer of protection against cyber attacks (Figure 2). IDPS is a software solution designed to monitor the controller area network (CAN) bus and detect anomalies in the communication patterns of electronic control units (ECUs) in automotive designs.

Specialised security MCUs

The above section has outlined MCUs that integrate security capabilities to counter physical and remote attacks. This section will explain specialised security MCUs, often called secure elements, that act as a companion chip to the main MCU while being linked over an I2C or single-wire interface.

Secure elements, which support MCUs without security features, are based on purpose-built hardware to provide a security framework against a wide array of threats. They are simple, cheap, and offload the main MCU or CPU from security related tasks such as key storage, cryptographic acceleration, etc. That’s why they are also known as security co-processors.

Above: Figure 3. The block diagram of the ATECC608A secure element. (Image: Microchip Technology)

In a secure element, all security building blocks work under a common boundary, which isolates authentication keys from software and thus prevents hackers from carrying out attacks like power cycling, clock glitches, and side-channel attacks. The uploading of security keys and certificates in secure elements at factories also prevents IP theft, design cloning, and product counterfeiting.

Take, for instance, Microchip’s ATECC608A secure element (Figure 3), which features a random number generator (RNG) for unique key generation while complying with the latest requirements from the National Institute of Standards and Technology (NIST). It also features cryptographic accelerators like AES-128, SHA-256, and ECC P-256 for mutual authentication.

Finally, secure ROM for key storage facilitates an immutable environment that’s hard for hackers and spoofs to alter, and thus prevents tampering and side-channel attacks. Collectively, the ATECC608A offers services ranging from secure boot to OTA validation to secure key storage and transfer for the IoT and cloud service authentication.

Another low-cost MCU specialising in security implementations is Microchip’s SAM L11 (Figure 4), which protects power constrained IoT nodes from threats like fault injection and side-channel attacks. It abstracts low-level security details with a modular GUI that enables developers to pick and choose relevant security features, and that’s how it simplifies the embedded security implementation.

Above: Figure 4. Four security use cases employing the SAM L11 security microcontroller. (Image: Microchip Technology)

The security features that the SAM L11 abstracts include third-party provisioning services. It also incorporates Arm’s TrustZone technology that isolates secure and non-secure code within a microcontroller. Moreover, the SAM L11 streamlines IoT node’s security needs while connecting with cloud services like Amazon Web Services (AWS).

NXP’s LPC5500 microcontroller, targeted at IoT edge applications, is another example of security-based MCUs. It utilises device-unique keys to create an immutable hardware root of trust. The keys can be locally generated by an SRAM-based physically unclonable function (PUF) that permits closed-loop transactions between the end-user and the OEM. That operation eliminates the need for third-party key handling.

Specialised security tools

While security-centric MCUs like the ATECC608A encompass security building blocks to facilitate a trusted ecosystem, they don’t address software isolation. Now, at a time when the amount of software running on MCUs is continuously growing, developers need to protect a large codebase from malicious attacks.

The IoT devices, for example, have protocol stacks for WiFi, Bluetooth, TLS, etc., and the corruption of protocol stacks can impact device operation even without hackers stealing the security keys. That calls for a separation of mission-critical code from non-mission-critical code and places the critical software in a secure environment.

Above: Figure 5. The basic framework of TrustZone technology for isolating software into secure and non-secure zones. (Image source: Arm)

Arm’s TrustZone environment (Figure 5) separates mission-critical code and protocol stacks from complex operating system (OS) software and large codebases, and thus prevents firmware backdoors into security key storage areas. It creates multiple software security domains to restrict access to the specific memory, peripherals, and I/O components inside the microcontroller.

All three security MCUs, mentioned above, the ATECC608A, SAM L11, and LPC5500 (Figure 6), have incorporated TrustZone technology to separate secure and non-secure code. Furthermore, the ATECC608A secure element can work with any TrustZone-enabled microcontroller.

Here, it’s also worth mentioning that security MCUs and TrustZone technology complement each other in a sense that TrustZone requires hardware protection, and security MCUs such as the ATECC608A and SAM L11 facilitates that within an IoT design setting. On the other hand, TrustZone helps create a compact software environment in the MCU-centric embedded designs.

Conclusion

The anatomy of security MCUs shows how they simplify the embedded security implementation during the design phase and how they bypass the steep learning curve in terms of security technology expertise. These specialised MCUs also bring down the cost overhead and power consumption, two major considerations in highly constrained IoT designs.

Above: Figure 6. The TrustZone technology in the LPC5500 microcontroller comes bundled with the Arm Cortex M-33 processor, shown on the top left part of the diagram. (Image source: NXP)

At a time when the inception of IoT devices is outpacing the rate at which these connected designs are securely deployed, security MCUs offer a viable path for confronting cyber threats on multiple fronts. They offer a simplified solution that comes equipped with a security design ecosystem to facilitate point-and-click development environments.