FreeRTOS boost with secure microcontroller deals
Following a deal with STMicroelectronics, Amazon has also developed cloud integrations for its FreeRTOS real time operating system with secure microcontrollers from NXP using ARM and Espressif using RISC-V.
The FreeRTOS IoT integrations with the Amazon Web Services (AWS) cloud are designed for improved security using a combination of FreeRTOS software and a partner-provided board with hardware security features.
- ST to launch its first neural microcontroller with NPU
- Espressif moves exclusively to RISC-V
- Glow neural network compiler for crossover MCUs
- i.MX RT crossover controller with Time-Sensitive Networking
The integrations for the NXP i.MX RT1060 and the Espressif ESP-C3 (above) only run software approved by the original equipment manufacturer (OEM) with a verifiable, per-device identity when authenticating to cloud services. This helps keep network data secure using cryptography and the Transport Layer Security (TLS) protocol and allows the software to stay up to date with the latest, publicly available security fixes through the lifetime of the device.
Each FreeRTOS IoT integration implements a basic IoT demo application that connects to the AWS IoT Core MQTT broker to exchange messages with the cloud. The application can also download updates to its own image from the cloud. The source code demonstrates security best practices in software, and shows how to integrate hardware security features to achieve even stronger security assurance.
Each of these integrations includes code that demonstrates how to use hardware features that support secure operation. Each board has two key capabilities implemented in its hardware: keeping critical code unchanged, and keeping cryptographic keys hidden. This core functionality is designed to create a hardware-based root of trust, a foundation that supports software security features. The FreeRTOS IoT integration software builds a more secure boot process, a verifiable device identity, and a firmware update system on top of it.
Secure boot ensures that when a device starts, the application software is checked for authenticity before it starts running. Each FreeRTOS IoT integration board embeds an unchangeable boot loader directly in hardware. This boot loader is the first code that runs when the device starts, and it can be trusted because it can’t be modified due to a security vulnerability or operational mistake. The boot loader’s only job is to validate the authenticity of the OEM supplied firmware image, and then run it if the image is authentic.
The validation step uses a pair of cryptographic keys to implement a code-signing system. The details of the code-signing process vary across boards, but each implementation accomplishes the same thing– the OEM can ensure that only their own firmware will run on the board. An OEM cryptographically signs their firmware images using a private code-signing key, and the bootloader uses the corresponding public key to verify the signature. The private code-signing key is secret, and known only to the OEM. Therefore, only the OEM can sign new firmware images with this key. The public key is not secret, and can be stored on each device. The reference boards each provide a way to program the public code-signing key and then permanently freeze its value.
The board-specific documentation provided by the manufacturer includes a description of a simplified boot process with only one boot loader. The integrations add a second stage boot loader into the process, between the first stage boot loader in hardware, and the OEM firmware. The fundamentals of the two-stage process are the same. The first stage boot loader verifies a signature on the second stage boot loader, and the second stage loader verifies the OEM firmware signature. This two-stage boot allows the first boot loader to be extremely small, reducing cost and reducing the chances of building an unfixable bug into hardware. Since the second stage is a software image, it can be larger and can implement more features. For example, the second stage boot loaders can support two OEM firmware slots, one for the current firmware, and one for an update image.
Secure, per-device identity and TLS
All devices that connect with AWS IoT are uniquely identified by a TLS Client Certificate. The client certificate tells the cloud which device it is talking to. Each device stores a unique TLS private key. Using a feature of the TLS protocol called Mutual Authentication, the device uses its private key to prove that it is the owner of its client certificate. (The authentication is mutual because TLS always verifies the identity of the server with another certificate.) For this system to be secure, each device must have its own unique certificate, and the private key must not leak outside the device. Each of the reference boards provides a secure store that holds the private key and never allows it to be read, even by software running on the same board! The FreeRTOS IoT integration software shows how to make TLS work without direct access to the private key.
Over the Air (OTA) updates
The demo applications use the AWS IoT OTA library to receive updates from the AWS IoT OTA service for FreeRTOS. The OTA client software runs in a background task, waiting for update messages from the cloud. When an update notification arrives, the OTA client downloads the new image from the cloud, and validates the code-signing signature on the image. If the signature is valid, the new firmware image is marked as the active image, and the board is rebooted.
- NXP i.MX RT1060 Arm Cortex-M7 MCU with EdgeLock SE050 Secure Element
- STMicroelectronics STM32U5 Arm Cortex-M33 MCU with TrustZone and TF-M
- Espressif ESP32-C3 RISC-V MCU with Digital Signature Peripheral (DSP)
Other articles on eeNews Europe
- Kontron set to launch Raspberry Pi4 system
- Semiconductor market heads for severe downturn says analyst
- Tachyum plans 3nm Universal processor
- Intel takes on Nvidia, GraphCore with Gaudi2 AI chip