Quality RTOS & Embedded Software

LIBRARIES
WHAT'S NEW
New FreeRTOS Long Term Support version now available.
FreeRTOS Extended Maintenance Program (EMP) registration now open.
FreeRTOS-Plus-TCP v3.0.0 released:
Featured FreeRTOS IoT Integrations:
Delta Over-the-Air Updates:

Featured FreeRTOS IoT Reference Integration
Targeting an NXP i.MX RT1060 MCU and EdgeLock® SE050 Secure Element

 

Introduction

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 on the i.MX RT1060 Evaluation Kit (i.MX RT1060-EVK) with an i.MX RT1060 Arm® Cortex®-M7 MCU and the EdgeLock® SE050 Development Kit (OM-SE050) for hardware-based root of trust.


i.MX RT1060 Evaluation Kit

EdgeLock® SE050 Development Kit

 

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.

The secure 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 coreMQTT library.

 

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 signing verification.

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 images.

 

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.