Secure Microcontrollers Address IoT Security

Security is increasingly something EEs need to be cognizant of in their component choices. Here's an overview of three secure microcontrollers.

There are currently billions—and that’s billions with a “B”—of internet-connected devices on the IoT worldwide in 2019 and the number is only increasing. Most of those points incorporate microcontrollers and every one of them represents an opening for the insertion of malware.

Once an IoT-based system has been breached at the level of an individual node, the trouble is only beginning. Think of that node, however small and unimportant it might be to the overall system, as a portal offering entry to a castle. Once the portal has been taken over by invaders, it provides the invaders with an opening from which it can do untold damage to the castle. 

To take our castle analogy one step further, the castle not only has a castle-wide defense system, but it also has strong forces at every potential entry point. That’s what’s been missing in IoT-based “castles” up to recently—there was, and is, robust system-wide security, but no defense at all at the gate.

The new generation of secure microcontrollers, in effect, militarizes the portals. They are no longer undefended, but rather provide robust defenses at the node level to supplement the system-wide malware defenses already in place.

 

 

Manufacturers of secure microcontrollers each have their own take on how to protect the IoT nodes they control and the macro-system that they are a part of.

Here are some examples of what they offer.

Microchip: SAML10/11

Microchip's SAM L10 and SAM L11 families of 32-bit MCUs are based on the Arm Cortex M23 Core, with 64 KB of flash memory and 16 KB of RAM. The company claims that they consume the lowest amount of power of any comparable MCUs on the market.

A central security element for the Microchip SAM L11 microcontroller is the TrustZone, which allows secure and non-secure code to run on a single MCU. The flash memory, SRAM, and data flash are each partitioned into secure and non-secure areas. 

This arrangement provides hardware isolation between a certified library, IP, and application code. The multiple software security domains allow only trusted software to gain access to critical memory, peripherals, and I/O channels.

 

Non-secure and secure (trusted) areas in memory. Image modified from Microchip

 

The security attribute of each region (trusted/secure or non-secure) will define the security state of the code stored in this region. Secure and non-secure addresses are used for different situations, namely whether the memory and peripherals in question are exposed to secure software or all software in general.

There is also an on-board cryptographic module that supports:

• Advanced encryption standard (AES)
• Galois Counter Mode (GCM)
• Secure hash algorithm

The secure boot and secure key storage support tamper detection. Bogus firmware updates are countered via the secure bootloader for safe and secure firmware updates.

 

Development Support 

The SAML11 Xplained Pro evaluation kit is purposed to help users evaluate and prototype systems that will be based on the SAML11.

 

The SAML11 Xplained Pro Evaluation Kit. Image from Microchip

STMicroelectronics

Because we have a more detailed description of the STM32G4 family in another article, here we’ll speak a bit more about the features that enhance the security of these devices.

The AES Core in the STM32G4 works off a secret 128 or 256-byte key to encrypt or decrypt data flowing out of or into STM32G4 devices. It takes a great load off the MPU, as encrypting and decrypting data consumes intensive computing when done entirely in software.

 

The AES Core in action. Screenshot from STMicroelectronics

 

Some of the types of transactions requiring encryption: 

• Secure networking routers
• Wireless communications
• Storage of smartcard data
• Secure financial transaction

The STM32G4’s Securable Memory Area is purposed to protect sensitive code and data (such as the keys) which can be executed only once at boot, and never again unless a new reset occurs. Once secured, any attempted accessing of this area of memory generates a read/write error, preventing access. 

This area in memory is critical in protecting the firmware and for safe firmware updates—a key feature in an age where firmware updates may dictate the lifespan of a component. The area is divided into two banks, with bank 1 allotted for secure firmware execution, while bank 2 is reserved for secure firmware upgrades.

The memory protection features can be categorized as follows:

• Readout Protection (RDP) prevents unauthorized reading of memory registers
• Proprietary Code Read Out Protection (PCROP) prevents unauthorized reading of IP code
• Write Protection (WRP) prevents malicious overwriting of memory contents
• Secure User Memory assures the safe execution of firmware

NXP Semiconductors

NXP’s LPC54S0xx family are powered by the Arm Cortex-M4 core, running at up to 180 MHz while drawing as little as 100 uA/MHz. The company has targeted it at human-machine interfaces and IoT applications.

The device’s security architecture is diagrammed below.

 

Security architecture block diagram for NXP’s LPC54S0xx family. Image from NXP

 

RNG (random number generation) is used for generating an unpredictable 32-bit number used for cryptographic applications 

AES, the encryption and decryption generator is a feature common to most secure MCUs, and the LPC54S0xx is no exception. In this device family’s case, the AES supports 128, 192 and 256-bit keys. 

OTP (one time programmable) memory consists of four banks of memory, each 128 bits in size. The first memory bank (OTP Bank 0) is reserved. OTP banks 1 and 2 are available for storing the AES keys. OTP bank 3 is used for customer programmable device configuration data such as secure boot. 

PUF (physical unclonable function) is a method of extracting a digital “fingerprint” based on the startup values of SRAM cells. There is some randomness, based on manufacturing variations. After processing, the true, hardware-based unique identification key of the MCU is obtained.

SHA (secure hash algorithm) the LPC54S0xx family employs the newer SHA-2 embodiment. Its purpose is message verification.

---

 

The reader will note many similarities between these three examples, but the devil is in the details. On examination, it’ll be noted that the data sheets we refer to in this article are exceptionally long and complex, and require a great deal of study before development can even begin.

This isn’t surprising, considering the wide-ranging difficulties that providing security at the MCU level entails. These devices are the gateways to macro-system, and these gateways must be open and accessible, but at the same time, they must be intelligent enough to keep out ‘troublemakers.” MCU security keeps on getting better, but so are the malefactors. It is an ongoing competition, with no end in sight.