“Used in combination, hardware-based encryption and secure storage provide the essential capabilities needed to implement secure Internet of Things (IoT) designs. However, once deployed, IoT devices face multiple threats that can compromise these devices, launch instant attacks, or create more subtle and advanced persistent threats.

“

Used in combination, hardware-based encryption and secure storage provide the essential capabilities needed to implement secure Internet of Things (IoT) designs. However, once deployed, IoT devices face multiple threats that can compromise these devices, launch instant attacks, or create more subtle and advanced persistent threats.

This article describes how developers can enhance the security of IoT devices using a root of trust built on the underlying security mechanisms, available as software on secure processors from manufacturers such as Maxim Integrated, Microchip Technology, NXP Semiconductors, and Silicon Labs Execution provides a trusted environment.

What is a root of trust and why do you need a root of trust?

Encryption methods and security keys are key enablers for the security of any connected device. As described in Parts 1 and 2 of this article series, they provide the basic mechanisms used by higher-level protocols to protect data and communications. Protecting the system itself requires developers to address vulnerabilities that can affect system operation and software execution in embedded systems.

In a typical embedded system, a system reset due to a power failure or critical software anomaly eventually causes the software boot process to reload the firmware image from non-volatile memory. Typically, a software reboot is an important safety mechanism for restoring system functionality that has been accidentally or intentionally destabilized. In connected systems, hackers use various black hat tools to compromise software, and security experts often recommend rebooting to counter intrusions that affect software execution. For example, in 2018, the FBI advised consumers and business owners to reboot their routers to stop the massive hacking campaign that occurred.

In fact, rebooting does not guarantee system integrity. After rebooting with a stolen firmware image, the system remains under the hacker’s control. To mitigate such threats, developers need to ensure that their software runs on a chain of trust that is built on the root of trust established at boot and extends to all levels of the software execution environment. Achieving this level of security is critically dependent on ensuring that trusted firmware is used to start the boot process.

Verify Firmware Image for Secure Boot

In an embedded system, the host processor loads the firmware image from flash into main memory and begins execution (or directly from flash with execute-in-chip (XIP) capability). If a hacker has stolen the firmware image, the boot process will cause the system to be hijacked.

To verify the integrity of the firmware before booting, developers use a code-signing process that starts early in the supply chain. In a secure facility, the system’s firmware image is signed using a private-public key pair created using a cryptographically robust algorithm such as Elliptic Curve Digital Signature Algorithm (ECDSA). Although the private key never leaves the facility, the system public key is shipped with the system. During the boot process, the processor uses this system public key to verify the firmware signature before using the image.

Of course, in the above process, the public key itself is vulnerable, and when extended, this leaves the system firmware vulnerable to unauthorized replacement. If the public key continues to be unprotected in the embedded system, hackers may replace it with the public key of a private key-public key pair that they generate themselves. If they replace the system’s firmware image with malicious firmware signed by the relevant private key they own, the compromised firmware signature will go through the verification process and continue the boot process, resulting in the system being hijacked.

Thus, the security system relies on a valid public key preconfigured in the secure element within the security facility. Security ICs such as Maxim Integrated’s DS28C36 and Microchip Technology’s ATECC608A not only securely store traditional secure elements, but also securely execute authentication algorithms such as ECDSA for firmware signature authentication.

For example, the host processor can send firmware to the DS28C36 over the serial interface before booting. The DS28C36 then uses the system public key previously preconfigured in the secure facility to verify that the firmware signature was indeed created by the associated private key in the same secure facility. Finally, the DS28C36 sends the verification result to the host processor, which proceeds to load the firmware image if the signature is valid (Figure 1).

A more secure boot process protects firmware images to eliminate problems caused by stolen keys or images. Through the use of secure storage and cryptographic accelerators, efficient secure boot functionality is built into a growing number of processors, including Silicon Laboratories’ Gecko Series 2 processors, NXP’s LPC55S69JBD100, Maxim Integrated’s MAX32520, and Microchip Technology’s ATSAML11D16A, to name a few . With these capabilities, such a secure processor can provide the required root of trust to create a trusted environment for system and application software execution.

Provide a root of trust with secure boot

These secure processors provide secure boot options designed to ensure the integrity of the firmware image on which the root of trust is based. For example, Silicon Laboratories’ EFR32MG21A and EFR32BG22 Gecko Series 2 processors build this root of trust through a multi-stage boot process based on a hardware secure element and a virtual secure element (VSE), respectively (Figure 2).

In the EFR32MG21A, a dedicated processor core provides cryptographic functions and a hardware secure element for secure key storage. Supported by this dedicated feature, the processor initiates the boot process using code stored in read-only memory (ROM) to verify the first-level bootloader (FSB) code. After verification is complete, the FSB code runs, which in turn verifies the code signature of the second-level bootloader (SSB). The boot sequence continues with the verified SSB, which in turn verifies the signature of the application code, which typically includes system-level code and higher-level application code. Finally, the verified application code runs and the system continues to perform operations according to the application’s requirements.

Since the process starts with ROM code and only runs the verified FSB, SSB and application code, this method will result in a verified chain of trust to execute the code. Since the first link in this chain of trust relies on unmodifiable ROM code, each subsequent link in the chain of trust continues this trusted environment. At the same time, this approach also allows developers to safely update application code, even first- and second-level bootstrap code. As long as each code package provides a verified signature, the trusted environment remains intact.

Processors that use a root of trust to provide this secure boot typically support multiple modes and options. For example, Silicon Laboratories’ Gecko Series 2 processors offer more robust certificate-based secure boot capabilities.

A certificate can be used in regular public key infrastructure (PKI) transactions and consists of a public key and a reference to one or more related certificates that ultimately point to a root certificate granted by a certificate authority (CA). Each certificate in this chain is used to validate the certificate below it, forming a chain of trust based on a trusted CA. During the authentication phase of Transport Layer Security (TLS), browsers rely on this chain of trust to confirm the identity of the web server. Embedded systems can use certificates in the same way to confirm the identity of a bootloader or application code source. Here, the multi-level bootstrapping process is performed as previously described, but requires additional verification of the credentials associated with each level (Figure 3).

Other processors such as NXP’s LPC55S69JBD100 support several different firmware image options. In addition to signed firmware images, these processors also support boot images that use the Device Identifier Composition Engine (DICE) industry standard from the Trusted Computing Organization. A third option allows developers to store the image in a special area of ​​the processor’s flash memory that supports PRINCE encryption, a low-latency block encryption capable of achieving security comparable to other encryptions in a much smaller silicon area strength. PRINCE encryption is implemented in the LPC55S69JBD100, a technology that performs real-time decryption of encrypted code or data stored in the processor-specific PRINCE flash area. Since the key used for decryption is only accessible to the PRINCE encryption engine, the decryption process remains secure. In effect, these keys are protected by a Key Encryption Key (KEK) generated by the LPC55S69JBD100’s Physically Unclonable Function (PUF). (See Part 2 for more information on PUF and KEK usage.)

This approach enables developers to store more firmware images, a capability needed to provide a firmware over-the-air (FOTA) update method for IoT devices without the risk of “closing” the device. If the processor can only use one location to store the firmware image, a flawed firmware image can leave the processor in an indeterminate or locked state, locking or blocking the device. By storing the firmware image in the PRINCE-enabled flash area of ​​the LPC55S69JBD100, developers can use a fallback strategy of restoring the last working version of the firmware if the new version boots into a non-working state.

Because all of these new firmware images must pass the signature verification checks required during the base boot process, developers can take advantage of secure FOTA to add new features or fix bugs without affecting the system or its chain of trust.

Summarize

System- and application-level security requires an execution environment that allows only authorized software to run. While code signature verification is an essential feature for implementing such environments, security systems also need to leverage a more comprehensive feature set to build the necessary chain of trust to ensure that trusted software is executed. The foundation of these trusted environments is the root of trust, which can be provided through the secure boot mechanism supported by the secure processor. Using such processors, developers can implement secure IoT devices that are resistant to attacks that attempt to disrupt software execution in a system or hijack a system entirely.