Quality RTOS & Embedded Software

LIBRARIES
WHAT'S NEW
FreeRTOS Extended Maintenance Program (EMP) registration now open.
FreeRTOS-Plus-TCP v3.0.0 released:
Featured FreeRTOS IoT Integrations:
Delta Over-the-Air Updates:
December 2021 Releases:

Featured FreeRTOS IoT Integration
Targeting an Espressif ESP32-C3 RISC-V MCU with Digital Signature Peripheral

 

Introduction

The demo project documented on this page demonstrates how to integrate modular FreeRTOS software with hardware enforced security to help create secure cloud connected applications. The project is pre- configured to run on the ESP32-C3-DevKitM-1 IoT development board which includes an ESP32-C3 microcontroller (MCU).

The ESP32-C3 is a single-core RISC-V MCU with Wi-Fi and Bluetooth 5 (LE) connectivity. It comes with the Digital Signature (DS) peripheral and HMAC (Hashed-based Message Authentication Code) peripherals for more secure device identity.

Secure Boot on the ESP32-C3 helps ensure only trusted software runs on the device, and flash encryption protects information by converting the contents of the ESP32-C3's off-chip flash memory into a secret form (encryption) that cannot be understood without correctly transforming it back into its original construction (decryption).

 

Demonstrated security best practices

 

Preventing unauthorized software from running on the device

Ensuring that a device boots using only software that is trusted by the Original Equipment Manufacturer (OEM) helps keep a device secure. Secure Boot protects a device from running any unauthorized (i.e. unsigned) code; it checks that each piece of software that is being booted is trusted by the OEM. The demo uses Espressif's Secure Boot V2. Secure Boot on the ESP32-C3 involves a first stage bootloader (which is stored in unchangeable ROM) and a second stage bootloader. The first stage bootloader loads the second stage bootloader, which in turn loads the application binary. An RSA private key is utilized to sign the second stage bootloader and the application binary. Signing the bootloader image with this private key ensures that the image has not been tampered with after it was signed because, if it were, signature verification using the corresponding public key would fail.

This RSA private key must be kept secret as malicious actors who gain access to the key can use it to provide unauthorized binaries. The RSA private key is generated and stored outside the device on the OEM's premises (which could be a secure build machine or a remote signing server) and is never accessed by the device. The corresponding public key is stored in the signature blocks that are appended to the bootloader and application images. A hash of the public key is stored in an eFuse.

An eFuse can be programmed only once and provides a way to store information in an unchangeable manner. The ESP32-C3 has a number of eFuse blocks which can be used by the OEM to store system and security parameters. Each signature block contains the signature of the corresponding image, in addition to the public key. The hash of the public key in the eFuse is used to verify that the public key in the image's signature block is valid.

Secure Boot consists of the following steps:

  1. When the first stage bootloader loads the second stage bootloader, it verifies the second stage bootloader's signature block and image.Image verification includes comparision of the hash of the public key embedded in the second stage bootloader's signature block with the public key hash stored in eFuse, as well as using the public key to verify the signature of the bootloader image. If verification is successful, the second stage bootloader is executed.
  2. When the second stage bootloader loads an application image, it similarly verifies the application's signature block and image in the manner described above. If the verification is successful, the application image is executed. Refer to the ESP-IDF programming guide on Secure Boot V2 for more details.
 

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. Securing the identity of a device during secure TLS communication is made possible in the ESP32-C3 via the Digital Signature (DS) peripheral which allows use of the unique RSA private key employed in a TLS connection, while keeping it secret by not making it accessible by software outside of the DS peripheral.

In order to prevent its exposure, the private key used in a TLS connection is AES-encrypted and stored in flash, and can only be read by the DS peripheral, i.e. only by hardware. The DS peripheral utilizes the Hash-based Message Authentication Code (HMAC) module and an eFuse to generate the key required to encrypt the private key. HMAC is used for key derivation and in turn it utilizes a selected eFuse block as its input key. This key in the eFuse is a randomly generated, 256 bit value (generated on the OEM's host system) which is burned into a chosen eFuse block during the operation to configure the DS peripheral by the OEM. Refer to the ESP-IDF programming guide on the DS peripheral as well as this DS technical reference manual for a detailed description of how the DS peripheral works.

 

Secure TLS communication with mutual authentication

Communication between the device and the AWS IoT Core MQTT broker is encrypted by using TLS version 1.2. See Transport security in AWS IoT for details. The demo uses the DS Peripheral, encrypted flash, the HMAC module, and the eFuse integrated in the ESP32-C3 SoC to store and use the X.509 TLS client certificate and its associated RSA private key. These are used to establish a TLS connection with the AWS IoT Core MQTT broker using the coreMQTT library.

 

Secure over-the-air updates (OTA)

To enable remote patching of security vulnerabilities and bug fixes, the demo includes Over the Air (OTA) updates using the AWS IoT OTA service for FreeRTOS, which includes Code Signing for AWS IoT. A firmware image must be digitally signed with a private key before an OTA update to ensure that it is from a reliable source and has not been tampered with. The private key is generated as part of the OTA setup process and stored with AWS Certificate Manager which is accessible only to the OEM. The corresponding public key certificate, which is used to verify the signed image, is embedded in the application binary that runs on the device and thus cannot be altered.

The OTA client software on the ESP32-C3 uses the AWS IoT OTA library. When it receives notification of a pending OTA update, the device downloads the new image into a secondary OTA flash partition on the ESP32-C3. The OTA client then performs code signature verification of the entire image to confirm the author by using the public key certificate, and to guarantee that the code was not tampered with or corrupted since it was signed. Refer to the ESP-IDF programming guide on OTA for more details.

 

Libraries used by this demo

This demo uses:

The "core" and "FreeRTOS for AWS" libraries meet the LTS code quality standards, including memory safety proofs.

 

Getting started with the demo

Visit the FreeRTOS/iot-reference-esp32c3 GitHub repository to get started. The example source code, list of features, and instructions on how to build and run the demo can be found in the repository.

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