Quality RTOS & Embedded Software

Featured FreeRTOS IoT Integrations:
Extended Maintenance Plan (EMP):
Delta Over-the-Air Updates:
December 2021 Releases:
FreeRTOS LTS libraries:

Featured FreeRTOS IoT Integration
Targeting an STM32U5 Arm Cortex-M33 MCU



This demo shows how to integrate modular FreeRTOS software with hardware enforced security to help create more secure cloud connected applications. The projects are preconfigured to run on the B-U585-IOT02A IoT discovery kit which includes an STM32U5 microcontroller (MCU).

The STM32U5 is an Arm® Cortex®-M33 MCU and includes Arm TrustZone technology to help protect critical security code and data with hardware-enforced isolation built into the CPU. There are two projects, one without and one with TrustZone enabled. The MCU also provides built-in security functions, some of which are used in this demo such as secure boot, secure storage, and a True Random Number Generator (TRNG). The STM32U5 has been independently certified to PSA Level 3 and SESIP Level 3.


Demonstrated security features and functions


Reducing the potential for attack by isolating critical security firmware and data

Isolating security critical components from normal application firmware and data helps to reduce the potential for attack. The TrustZone enabled project utilizes ARM Trusted Firmware M (TF-M), leveraging Arm TrustZone technology and providing isolation between code running in the Non-Secure Processing Environment (NSPE) and code running in the Secure Processing Environment (SPE).

In the TrustZone enabled project, the secure environment runs the following services, which are critical to the security of the system as described in the Featured FreeRTOS Integrations page:

  • Secure boot
  • Private key and secrets storage
  • Crypto operations such as key generation and signing

The remaining applications, FreeRTOS kernel, and other tasks such as OTA and the MQTT Agent are run in the non-secure environment. The OTA library interacts with the secure TF-M firmware update APIs to install new images.

The STM32CubeIDE provides build support for the TrustZone project, which generates two separate secure and non-secure binaries which are individually signed and verified using separate keys.


Keeping device identity and secrets secure

Secure Transport Layer Security (TLS) communication requires senders and receivers to be authenticated by establishing their identity. A device's unique private key and its corresponding client certificate are used to identify and authenticate a device. The private key must be kept secret to prevent unauthorized access and communication.

The device ECDSA public/private key pair is generated using the built-in NIST SP 800-90B compliant TRNG to achieve uniqueness. The key pair is used to generate TLS client certificate. The key pair and the certificate are stored in the Internal Trusted Storage within TF-M, with the private key is created with a flag that prevents exporting it from the SPE. Private key generation and verification operations are performed via calls to the ARM PSA Cryptography APIs, allowing cryptographic operations to be performed on the key stored in secure storage and is isolated from the application running in non-secure environment.


Secure TLS communication with mutual authentication

Communication between the device and the AWS IoT Core MQTT broker is encrypted using TLS version 1.2. See Transport security in AWS IoT for details. The ARM PSA Cryptography APIs allow TLS code to run in the NSPE without direct access to the TLS client certificate's associated private key.


Secure over the air updates (OTA)

The STM32U5 platform has a dual bank flash memory with a total size two megabytes. Available flash memory is divided into two banks of size 1MB each, with one bank used for current firmware images, and the second bank used to stage the new firmware images. Each bank of the memory is further partitioned into secure and non-secure regions, with separate read and write protected flash areas for secure side access.

Firmware updates for TrustZone enabled projects are implemented by integrating the FreeRTOS OTA library with the PSA Trusted Firmware Update API as the PAL. Secure and non-secure executables are updated separately. Anti-rollback protection and root of trust validation are done in the unchangeable (immutable) BL2 bootloader.

Each of the secure image and non-secure image partitions are divided into primary and secondary slots. The new image is downloaded, validated, and staged into the secondary slot initially. On the next reset following the new image installation, the bootloader performs a swap of the current image running in the primary slot with the new image in the secondary slot. The swap is performed by copying a few chunks at a time, using a scratch area as a temporary buffer. Following the swap and a successful signature verification, the new image boots up and performs tests for sanity. These tests include successfully connecting to AWS IoT and a version upgrade validation for anti-rollback protection. If the tests are successful, the new image is confirmed and the old image in the secondary slot is erased to prevent any rollback. If the test fails, the bootloader rolls back to the old image to bring the system back to a known good state.


Anti-Rollback protection

Anti-Rollback protection prevents downgrading the device to an older version of its software that has been deprecated due to security concerns. Anti-rollback protection is achieved using the MCUboot and TF-M Security Counter Implementation.

For each secure and non-secure region, updates must have a security counter value which is greater than or equal to the current security counter for that region. During a firmware update, an image with a security counter lower than the current image's security counter will result in rejection of the update, and the bootloader will revert to the previous image for that region. The security counter is incremented after a successful firmware update.


Memory safety proofs

The "core" FreeRTOS libraries comply with documented code quality criteria, including memory safety proofs that run on each code check-in.


Getting started with the demo

The demos connect to AWS IoT using Wi-Fi, and then use the coreMQTT-Agent library to publish environment and motion sensor data that is available on the development board. They demonstrate use of the OTA service for FreeRTOS, Device Shadow, and Device Defender AWS IoT services. The example source code, list of features, and instructions on how to build and run the demo can be found in the FreeRTOS/iot-reference-stm32u5 GitHub repository.

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.