Featured FreeRTOS IoT Reference Integration
Targeting an NXP i.MX RT1060 MCU and EdgeLock® SE050 Secure Element
These demos show how to integrate the
Long-Term Support (LTS) FreeRTOS kernel and libraries
with hardware enforced security to help create more secure cloud connected applications. The projects are preconfigured to run
i.MX RT1060 Evaluation Kit
(i.MX RT1060-EVK) with an
i.MX RT1060 Arm® Cortex®-M7 MCU
EdgeLock® SE050 Development Kit
(OM-SE050) for hardware-based root of trust.
Demonstrated security features and functions
Preventing unauthorized software from running on the device
A secure boot process is designed to help ensure that firmware images running on the board were cryptographically signed by
the original equipment manufacturer (OEM). Code signing is done with RSA key pairs. The private key of a pair, a secret
key known only to the OEM, is used to sign images. The public key is programmed into the device, and can be used to
verify that an image was signed by the private key.
The boot process demonstrated has three stages, as described in the Featured FreeRTOS IoT Integrations page.
Figure 1: Security architecture
The first stage bootloader is built into the i.MX RT1060 in ROM and is cannot be modified. The second stage bootloader,
from the open source project
MCUboot, is included as a buildable project in
the reference integration repository. The third
stage is an application, built on FreeRTOS. The repository includes multiple application projects, each demonstrating
different ways to use AWS IoT services.
The first stage bootloader can verify the digital signature of the second stage bootloader, and establish that it can be
trusted using the public key from a secure store. The second stage bootloader verifies the signature on the application
image. In this way it establishes trust for the application before it runs it. The instructions in the
"Create Signing keys for the Bootloader" and "Create a Signed Application Image" sections of the
Getting Started Guide
include steps to generate the necessary
keys, embed the public key in MCUboot, and sign the application executable.
The public key used to verify MCUboot must also be protected. The iMX RT1060 has one-time programmable (OTP)
fuses to enable this. An array of OTP fuses are used to implement a very small storage area that can only be programmed one
time. This storage area records the boot configuration including a hash of the public code signing keys used to validate code
signatures. Initially, the boot configuration is set to an "open" mode, allowing any code to be loaded and run on the device.
Once the boot configuration fuses are programmed for the "closed" mode, only a signed image of MCUboot can be run,
and it is impossible to return to the open mode. This one-way transition should be performed on all production devices.
This open configuration is convenient for development, so the reference integration's Getting Started Guide explains how
to sign firmware images, but leaves the boot configuration open.
Keeping device identity and secrets secure
Devices that connect to AWS IoT are uniquely identified by a TLS Client Certificate using a private key to prevent devices
from impersonating one another. The device's unique private key must be kept secret to prevent unauthorized access and
communication. The EdgeLock SE050, a separate peripheral from the main processor, implements a secure storage
system for a client certificate and its associated private key. Each SE050 comes with a unique client certificate and
associated private key already programmed. See the "device certificate and private key" in figure 1 above. The SE050 does not
include an interface for reading out the private key, so only this single device can prove it owns the client certificate.
Unlike the private key, the client certificate is public information that can be extracted from the SE050. The Getting Started
Guide explains how to read the client certificate through a serial interface, which you will need to do to register the
evaluation kit's identity with your AWS account.
Transport Layer Security (TLS)
protocol requires clients to prove their ownership of a client certificate using its
associated private key. Since the private key is confined to the SE050, the reference integration code provides an
implementation of the
PKCS #11 API,
which allows the required cryptographic operations to be performed on the SE050,
without direct access to the key.
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 demos use the EdgeLock SE050 secure element which comes with a unique
client certificate and associated private key already programmed. The client certificate can be retrieved without exposing the private key, and registered with AWS IoT to establish TLS connection with the AWS IoT Core MQTT broker using the
Over the air (OTA) updates
The reference integration includes a demo of Over the Air (OTA) updates to enable remote patching of security
vulnerabilities and bug fixes. This demo uses the
AWS IoT OTA service for FreeRTOS
to deploy new images through the
cloud. The OTA client software, from the
AWS IoT OTA library, runs in a background task and waits to receive
notifications from the cloud that new firmware images are available. Upon receiving a notification, the device downloads
the new image, and the device then reboots to run the new image.
The OTA demo uses two features of the reference integration to improve robustness and security: primary and secondary
firmware image slots, and signed OTA images.
The MCUboot secondary boot loader divides flash memory into three regions. One is for the bootloader itself, and the other
two are used as primary and secondary firmware image slots. Only one firmware slot is active at a time. When the OTA
library downloads a new firmware image, it stores the update in the inactive slot, leaving the active firmware untouched.
This allows MCUboot to fall back to the older firmware if something goes wrong with the new one, like a failed code
In addition to the code signature verification in the secure boot system, the OTA service and its client library add their own
code signing and verification steps to the image download process. As with the public keys used to validate images in
secure boot, the public key used to validate OTA signatures must be stored on each IoT device, and should be
protected from changes. The reference integration code shows how to store this key in the SE0050.
Memory safety proofs
The "core" FreeRTOS libraries comply with documented code quality criteria, including memory safety proofs that run on
each code check-in.
What the demo applications do
The reference integration includes demo applications that connect to the AWS IoT Core MQTT broker through the i.MX
RT1060's Ethernet connector. The applications carry out common IoT device functionality, including exchanging MQTT
messages with the cloud, and using the AWS IoT OTA service for FreeRTOS to download and install new firmware
Getting started with the demos
The README.md file in the root of this project's Git repo provides instructions on downloading the source code
and the GSG.md provides step by step instructions on how to build and run the demo. Visit the
FreeRTOS/iot-reference-nxp-rt1060 Git repository
to get started.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.