This service lets customers order modules from Espressif such that they are pre-programmed with all the Matter-specific security configurations, firmware, and other device-unique credentials and certificates that should be flashed on the modules. This saves organizations hassle and time from building their own manufacturing scripts and back-and-forth with factory lines.

Initially, we had been running a VID-scoped PAA (Product Attestation Authority). Now, Espressif is an approved signing authority for a Non-VID scoped PAA (Product Attestation Authority) also called as Open PAA.

What does being a non-VID scoped PAA mean?

Effectively, we can now support workflows that we previously were not able to support, viz:

• Secure Matter Manufacturing in your Factory (Matter DACs and device-unique data)
• Upgrading in-field devices to support Matter by generating and delivering DACs securely

Matter Manufacturing in your Factory

We announced support for Accelerated Matter Manufacturing last year. This allowed organizations to accelerate the manufacturing of their Matter devices, by allowing Espressif to pre-program the Device Attestation certificates (DACs), the firmware, and security configurations on modules before being shipped out.

One request we kept getting was a provision to perform this manufacturing in the customer’s factory of choice. This is now possible with our latest update. We are currently working with select customers to enable their factories to perform Matter manufacturing by themselves. If you are interested in this, please reach out to us for the next steps.

The most important part of this is having the ability to securely deliver cryptographically signed Device Attestation Certificates (DACs) to the modules without their private key ever leaving the module.

The typical workflow is shown in the following diagram.

Upgrading In-field Devices to Matter

We also support delivering of DACs to in-field devices, that wish to now incorporate Matter support. For this scenario, it is essential that the in-field devices have a mutually authenticated secure connection to some device cloud platform. The cloud platform is expected to act as the trust broker for the in-field devices. The secure DAC delivery in this case happens as shown in the following diagram.

If you are working on building Matter products, please reach out to us to check how this aligns with your product deployment workflow.

Matter: Improvements to Espressif DAC Provisioning Service was originally published in The ESP Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

ESP-AT

ESP-AT allows the ESP32-P4 to connect with external wireless modules using AT commands. It’s a simple and effective way to integrate wireless connectivity without extensive software development.

Advantages:
- Simple and easy to use, with a well-established AT command interface
- Supports a wide range of WiFi and Bluetooth features
- Readily available and widely used in the Espressif ecosystem
- Some minor customization is possible on the AT interface to add new commands.

Limitations:
- Limited to basic connectivity functions, with less flexibility for advanced applications
- Low performance in terms of throughput, QoS as well as latency

Applications and Scenarios:
- Suitable for simple IoT devices or applications with basic connectivity requirements
- Ideal for quick prototyping or projects where a straightforward, out-of-the-box solution is preferred

ESP-Hosted-FG

ESP-Hosted-FG provides a standard 802.3 (Ethernet) network interface to the host. This setup ensures the microcontroller can handle more complex or demanding processes without compromising wireless performance.

Advantages:
- Provides flexibility in choosing different interfaces based on the performance requirement of the application
- Supports advanced wireless features compared to ESP-AT like VLAN, Multiple Network interfaces, Network and performance tuning configurations, etc.
- Source code in open-source and the slave can be customized to utilize other features of the SoC like peripherals, GPIOs, etc.

Limitations:
- Requires additional development effort to integrate the ESP-Hosted solution with the main application
- May have higher resource requirements compared to ESP-AT

Applications and Scenarios:
- Suitable for complex IoT devices or applications that demand advanced wireless features
- Useful for applications that require high-performance or resource-intensive wireless feature

ESP-Extconn

ESP-Extconn provides external wireless connectivity(Wi-Fi & Bluetooth) for ESP chips that do not have built-in wireless capabilities. This component's APIs are compatible with the Wi-Fi and Bluetooth component APIs in the ESP-IDF.

Advantages:
- Provides the most flexible and extensible connectivity solution
- Allows for ease of integration with the main application logic due to familiarity with the ESP-IDF wireless components APIs.

Limitations:
- Requires more development effort compared to the other solutions.
- There may be higher resource requirements for the host
- It has zero flexibility in terms of customization of co-processor functionality.

Applications and Scenarios:
- Ideal for applications where the main application logic needs to be tightly integrated with the connectivity features
- Useful for projects that require a high degree of flexibility and configurability in the connectivity solution

Comparison of the different solutions:

Choosing the Right Solution

When selecting a connectivity solution for the ESP32-P4, consider the following factors:

1. Connectivity Requirements: Assess the specific wireless and connectivity needs of your application. If basic Wi-Fi and Bluetooth features are sufficient, ESP-AT may be the most suitable choice. For more advanced wireless requirements, ESP-Hosted or ESP-Extconn may be better options.

2. Application Complexity: If your main application logic is straightforward and can be easily combined with the connectivity tasks, ESP-AT may be the simplest solution. For complex applications that require a clear separation between the main logic and connectivity, ESP-Hosted or ESP-Extconn may be more appropriate.

3. Development Resources: If you have a smaller team or limited development resources, ESP-AT may be the easiest solution to integrate. ESP-Hosted and ESP-Extconn require more development effort but offer greater flexibility and configurability.

4. Performance Constraints: For high-performance applications, the trade-offs between the solutions should be carefully evaluated. ESP-AT may be more resource-efficient, while ESP-Hosted and ESP-Extconn will provide better performance and throughput.

5. Interface Considerations: ESP-Hosted provides flexibility to choose from SDIO, SPI, and UART interfaces for your connectivity solution based on the performance requirement of the application.

6. Co-processor resource usage: If there is a requirement to use other features of the co-processor like GPIOs, peripherals, etc., ESP-Hosted provides the most flexibility in terms of customization of the slave as to the requirement. If using the ESP-AT, users can create custom AT commands for some basic operations.

By considering these factors, you can determine the most suitable connectivity solution for your ESP32-P4-based application, ensuring the optimal balance between ease of use, flexibility, and performance.

Wireless Connectivity Solutions for ESP32-P4 was originally published in The ESP Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

[If you have been following the Espressif blogs and announcements, you must already be aware of ESP RainMaker and its various features. If not, please check out the info here so that you get an idea about what ESP RainMaker is before you proceed further.]

Admin users in ESP RainMaker can look at some basic node data like type, model, firmware version, etc. and push OTA firmware upgrades. They can view additional diagnostics data if linked with ESP Insights. However, there was no way for them to send some data to the nodes. The set params operations were available to only end users.

The command — response framework introduced in ESP RainMaker now provides a new way to communicate with the nodes. It is available to admin as well as end users (both, primary and secondary). It also provides better access control on node side and allows more reliable communication with explicit error reporting from the firmware.

Workflow

A high level workflow is shown here:

To explain in short,

• Client generates request payload and sends to cloud.
• Cloud assigns it a request id and returns it back to the client, which can then be used to track the status.
• The request is forwarded to the node right away if it is online or is sent later if the node is offline at that time.
• The response of the node is tracked against the request id so that the status can be queried by the client.

You can read more about the specifications here.

Advantages

This new framework enables many new use cases and workflows

One of the key advantages is that it allows admins to send some data or commands to the nodes, which was earlier not possible. Moreover, on the firmware side, you can specify which type of users (admin, primary, secondary user) should have access to the commands, giving better access control. Eg. You may allow admins and secondary users to reboot a device, but only primary users will be able to reset the Wi-Fi. You can let only primary users to create schedules, but not admins or secondary users.

Another major advantage is that you can trigger a command even when a node is offline. This allows to push certain configurations and other information at any time and let the nodes get them whenever they come back online.

The framework not only provides reliable information about delivery of commands to a node, but also lets users check the status (Eg. request timed out, value out of bounds, operation not permitted, etc.)

We hope that this new framework will unlock new use cases and workflows. Do give this a try by looking into the docs and let us know if you find this useful. Command-response sample usage is also available in the led_light example

Command — Response Framework in ESP RainMaker was originally published in The ESP Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

The secure boot feature is especially important as it allows only authorised firmware to run on the MCUs. ESP IDF has made enabling secure boot very easy. However, managing the secure boot keys is still the developer’s responsibility. Some questions that commonly come up for our customers include:

• How to generate the secure boot key?
• Where to store the key securely, is it stored on the developer’s machine or a server?
• How to protect the key from leakage? What if our engineers leave the organisation?
• How do I know which key is programmed on a device, so I don’t accidentally upgrade with the incorrect keys?
• How to manage a fleet of devices with similar firmware but different secure boot keys?

The recent addition of “Secure Signing” feature in ESP RainMaker addresses all its concerns. It offers a way to

• generate and manage keys
• simplify signing bootloader and firmware images before device manufacturing
• supports transparently “Auto Signing” before deploying OTA firmware upgrades

Auto Sign for OTA

The auto-signing feature in ESP RainMaker allows developers to just upload their unsigned firmware to ESP RainMaker, and deploy an OTA firmware upgrade. The ESP RainMaker backend transparently handles the signing with the correct keys during OTA firmware upgrades.

If your fleet includes devices that use distinct keys for key verification, ESP RainMaker will ensure that the correctly signed firmware goes to the right device.

The developer no more needs to keep track of the keys (or should even have the visibility of the keys), making the fleet management simpler.

Additionally, since the key management is handled in the cloud, this decouples the development activity from the device-management activity, providing better role based separation.

Key Management

The secure boot signing keys are created and maintained in the cloud with ESP RainMaker. The private key itself is not accessible to the user but can be used only for signing requests. On private deployments, RainMaker uses a FIPS compliant HSM for added security. Access control, for who can trigger signing requests, ensures that only authorised persons in your organisation can utilise this for signing firmware images. This adds another layer of security to the system.

First-Time Signing

Once the signing key is created in ESP RainMaker, you need to sign the firmware images (bootloader and firmware) that gets flashed on your production devices. This is achieved by uploading unsigned images of secure-boot enabled bootloader and firmware and getting them signed for the first time.

ESP RainMaker provides detailed instruction for flashing and setting up your SoC with the appropriate security configurations for secure boot.

The secure signing feature is available in public as well as private RainMaker deployments. Use backend release 2.1.0 or later and frontend release 2.0.1 or later for this.

Check out more usage details in the ESP RainMaker docs. Go ahead and use this to secure your RainMaker powered IoT devices. Let us know (at esp-rainmaker-support@espressif.com) if you have any queries.

Secure boot with auto-signing in ESP RainMaker OTA was originally published in The ESP Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s been about 8 months since we launched ESP ZeroCode. For all these months, continuous interest and customer activity has kept us busy. Let’s look at some of the highlights of what’s new with ESP ZeroCode.

Customer Interest

Over 11,000 users across 125 countries have visited ESP ZeroCode, building various kinds of Matter-enabled products. Every week we get numerous queries and requests for samples or product-related queries. Many of these have now become products that have completed certification and selling in their respective market places.

Along the way we have Matter-certified over 100 ESP ZeroCode powered devices.

Quality

We have been rigorously conducting automated QA tests and making continuous fixes in the ZeroCode firmware. These include a variety of tests including,

• long-duration tests over 30 days
• tests under network stress and RF interference
• tests with multiple simultaneous ecosystem operations
• OTA and rollback tests

Overall the test framework runs over 1000 tests, and most of these are run for over 50 different products.

Numerous issues for memory footprint, corner cases, commissioning/uncommissioning have been identified and fixed.

Product Enhancements

We now support 2 different solution types through ESP ZeroCode.

• single-chip solution: This is the typical solution that we launched with, which today, runs on Wi-Fi (ESP32-C3, ESP32-C2, ESP32) and Thread (ESP32-H2). This solution is the most cost optimised solution and is recommended for all lighting categories.
• two-chip (hosted) solution: Our ESP ZeroCode ExL is a hosted solution that is ideal for Appliances. Appliances often consider connectivity through a “connectivity co-processor”, and work with it over a UART interface. Our two-chip solution addresses the typical Appliance scenarios, particularly MQTT connectivity to cloud platforms (AWS IoT). Read more about it here: Announcing ESP ZeroCode ExL.

We also extended our portfolio of partnerships. All ESP ZeroCode products can now be easily certified with all of the following ecosystem programs:

• Works with Alexa
• Works with Apple Home
• Works with Google Home
• Works with Home Assistant
• Works with SmartThings

We also collaborated with Amazon with Alexa Connect Kit (ACK) for Matter and created ZeroCode devices using the ACK for Matter. Through the ESP ZeroCode portal, you can now choose ACK for Matter as a solution for the firmware of your devices.

Device Catalogue

As Matter standard evolved from v1.0 to v1.1 and v1.2, it kept introducing support for new device types. We have kept pace with the standard’s evolution and have been incorporating newer device types and a variety of device drivers in our product catalogue.

Today, with ESP ZeroCode, you can quickly build the following Matter-enabled products:

• Window Blinds (automatic and manual calibration)
• Sockets: 1, 2, 3, 4 channel
• Power outlets: 1, 2, 3, 4 channel
• LED Lights with options for RGB, RGBW, RGBWW, RGBCW and RGBCCT with the following drivers are supported: WS2812, PWM, BP5758D, BP5758D, BP1658CJ, BP1658CJ, SM2135E, SM2135E, SM2135EH, SM2135EH, SM2135EGH, SM2135EGH, SM2335EGH
• Filament bulbs, Candle bulb, Reflector bulb, Downlights, Flat Panels (Full Colour, Tunable White)
• Dimmers
• Appliances (hosted mode solutions) like Thermostat, Air Conditioner, Laundry Washer, and Refrigerator

All the above device types are available on both Wi-Fi as well as Thread/802.15.4 transport.

Richer Customisations

With the introduction of text mode configurability, ESP ZeroCode now allows richer set of customisations.

You can now create multi-channel outlets or sockets. You can also create multi-endpoint device types, like a socket and a light in the same accessory and such.

A variety of driver specific customisations have been included. A few of these include,

• Various configurations for lightbulbs, viz: current, gamma, low power
• Configuring indicator colours and patterns for all the device states, viz: setup mode, device ready, network disconnected
• The state of the device after turning the power on, viz: power, brightness, colour
• Factory reset trigger mechanism

Shorter Time To Market

A number of optimisations in our manufacturing and certification processes have been made to provide the shortest production time.

In the fastest case, some of our customers have gone from concept to production-start (including certification) within 3 weeks.

All in all, we are taking great strides to make ESP ZeroCode the fastest, most secure and robust tool to launch Matter products. If you are looking to develop and maintain your own Matter-enabled products, with your specific customisation, please head over to ESP ZeroCode to get started.

For additional information about ESP ZeroCode, check out this podcast:

What’s New with ESP ZeroCode was originally published in The ESP Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

ESP32 series of SoCs supports multiple security features like trusted boot, flash encryption, secure storage etc. There are also dedicated peripherals to support use-cases like HMAC and digital signature. For most of these features the eFuse storage in the ESP32-C3 is responsible for storing the private keys and also the configuration bits.

eFuse memory is one time programmable and hence care must be taken whilst enabling the security features. eFuse programming being an irreversible operation, it is desired to have some playground available to first try out security features (e.g., under emulator) and then move to the real hardware.

This article talks about exercising different security features in ESP32-C3 under QEMU (emulator).

QEMU

QEMU, which stands for Quick EMUlator, is an open-source virtualization tool that allows users to create and run virtual machines (VMs) on a host system. It can emulate various architectures, including x86, ARM, RISCV, and others, enabling users to run operating systems and software designed for different hardware platforms.

Espressif has been developing a system-level emulation of RISC-V based ESP32-C3 using QEMU and its latest release supports all the security features for ESP32-C3. Binary compatibility has been maintained to directly run the firmware built for ESP32-C3 target under QEMU.

Emulator approach provides an advantage to iterate various security configurations without risk of bricking the hardware. Once the workflow is established under QEMU, it can be easily adapted for the real hardware.

How does QEMU help in trying out the security features?

QEMU is a system-level emulator composed of instruction set emulation, memory and MMU emulation, and peripheral emulation. It also supports various virtual disk formats and networking configurations as well.

This helps us to emulate the complete hardware SoC that includes peripherals emulation as well. Peripherals like eFuses, XTS-AES, RSA play a key role in supporting security features.

We will deep-dive into how to use these emulated host files while using QEMU in the upcoming sections.

Trying out the security features

Espressif’s security guide mentions two workflows for enabling the security features:

• Internal first boot-up workflow
• Host-based workflow

We will use a demo example which enabled and allows us to try out all the supported security features:

• Secure Boot V2
• Flash Encryption
• NVS Encryption (using the HMAC based workflow)

Let us check out the boot internal first boot-up workflow:

Installing QEMU release versions

1. You can get compiled QEMU binaries in its releases section. Download your platform-specific release binary for ESP32-C3 (qemu-riscv32-softmmu-esp_develop-) or you could use the below commands directly to download and extract the package in the Downloads directory:

# Linux
wget https://github.com/espressif/qemu/releases/download/esp-develop-8.2.0-20240122/qemu-riscv32-softmmu-esp_develop_8.2.0_20240122-x86_64-linux-gnu.tar.xz -P ~/Downloads
tar xvf ~/Downloads/qemu-riscv32-softmmu-esp_develop_8.2.0_20240122-x86_64-linux-gnu.tar.xz -C ~/Downloads

# MacOS (M1 silicon)
wget https://github.com/espressif/qemu/releases/download/esp-develop-8.2.0-20240122/qemu-riscv32-softmmu-esp_develop_8.2.0_20240122-aarch64-apple-darwin.tar.xz -P ~/Downloads
tar xvf ~/Downloads/qemu-riscv32-softmmu-esp_develop_8.2.0_20240122-aarch64-apple-darwin.tar.xz -C ~/Downloads

You could also consider adding it to your environment’s $PATH variable for ease of use. For example, in case of Linux/MacOS, if after extracting the downloaded release file is in the Downloads directory, you may run following command:

export PATH=$PATH:~/Downloads/qemu/bin

2. In case you are interested in trying out the development versions you could also opt for cloning and building Espressif’s GitHub QEMU fork using the configuration instructions mentioned in the documentation.

3. In case you are using ESP-IDF’s master branch for developing your firmware, the easiest way to install the QEMU is getting the release binaries that are packaged with ESP-IDF (master) using the following command:

python $IDF_PATH/tools/idf_tools.py install qemu-riscv32

The above command exports the path to the ESP-IDF packaged QEMU release binaries into your $PATH variable as well.

Internal first boot-up workflow

In this workflow, the security features are incrementally enabled during the first boot up by the bootloader.

1. Clone the demo project

In a new terminal window, activate the ESP-IDF environment, using the . ./export.sh as mentioned in the ESP-IDF installation section.

Use the following commands to clone the demo project:

git clone https://github.com/Harshal5/esp-idf-security-example.git
cd esp-idf-security-example

2. Enable the security related configs

Starting off with the first step, set project target to esp32c3 by entering the command:

idf.py set-target esp32c3

The project we are using already has all the security configs listed below enabled by default (sdkconfig.defaults), so you do not need to enable them by yourselves.

Security-related configs that have been enabled:

# Secure Boot related configs
CONFIG_SECURE_SIGNED_ON_BOOT=y
CONFIG_SECURE_SIGNED_ON_UPDATE=y
CONFIG_SECURE_SIGNED_APPS=y

CONFIG_SECURE_BOOT_V2_RSA_ENABLED=y
CONFIG_SECURE_SIGNED_APPS_RSA_SCHEME=y
CONFIG_SECURE_BOOT=y
CONFIG_SECURE_BOOT_V2_ENABLED=y
CONFIG_SECURE_BOOT_BUILD_SIGNED_BINARIES=y
CONFIG_SECURE_BOOT_SIGNING_KEY="secure_boot_signing_key.pem"
CONFIG_SECURE_BOOT_FLASH_BOOTLOADER_DEFAULT=y

# Flash Encryption related configs
CONFIG_SECURE_FLASH_ENC_ENABLED=y
CONFIG_FLASH_ENCRYPTION_ENABLED=y
CONFIG_SECURE_FLASH_ENCRYPTION_MODE_RELEASE=y
CONFIG_SECURE_FLASH_HAS_WRITE_PROTECTION_CACHE=y
CONFIG_SECURE_FLASH_ENCRYPT_ONLY_IMAGE_LEN_IN_APP_PART=y
CONFIG_SECURE_FLASH_CHECK_ENC_EN_IN_APP=y
CONFIG_SECURE_ENABLE_SECURE_ROM_DL_MODE=y

# NVS Encryption related configs
CONFIG_NVS_ENCRYPTION=y
CONFIG_NVS_SEC_KEY_PROTECT_USING_HMAC=y
CONFIG_NVS_SEC_HMAC_EFUSE_KEY_ID=3

Setting these configs assume that we have a pre-generated secure boot key named secure_boot_signing_key.pem, flash encryption key would be generated by the device (esp32c3), and an HMAC key (say hmac_key.bin) that would be used to derive the NVS encryption key needs to be pre-burnt in the eFuse KEY_BLOCK3.

The secure boot signing key being an RSA key, can be generated using the command:

espsecure.py generate_signing_key --version 2 secure_boot_signing_key.pem

whereas the NVS encryption key being an AES key can be created using the command:

dd if=/dev/random of=hmac_key.bin bs=1 count=32

3. Generate the flash image

Once we are done with the configurations, we need to build the firmware using the command:

idf.py build

that would create the bootloader, partition-table, and the application images individually in the build directory.

The QEMU flash image should be generated by merging the boot loader, partition-table and the application binary images present in the project'sbuild directory of the project. A straightforward way to generate such a flash image is by using the esptool.py merge_bin command with the parameter flash_args file, which contains the entries of all the binary images that are needed to be flash using the command idf.py flash.

Use the below command to generate a complete flash image (flash_image) for the firmware:

(cd build; esptool.py --chip esp32c3 merge_bin --fill-flash-size 4MB -o flash_image.bin @flash_args)

As we have already enabled the config CONFIG_SECURE_BOOT_FLASH_BOOTLOADER_DEFAULT, the bootloader entry gets added into the flash_args file, which is needed because as mentioned in secure boot guide, bootloader does not get flashed by default with the idf.py flash command when secure boot is enabled.

4. Get the eFuses file ready

A simple eFuses file could be created using:

dd if=/dev/zero bs=1K count=1 of=build/qemu_efuse.bin

This command creates a 1KB (1024 bytes) file, which is the total size of ESP32-C3 eFuse blocks, filled with zeros.

Now you have your eFuse file ready and you can view the eFuses summary by running QEMU ESP32-C3 in download mode and attaching the above generated eFuses file. Run QEMU in the download mode using the following command in the terminal in which we have updated the PATH variable:

qemu-system-riscv32 -nographic \
                    -machine esp32c3 \
                    -global driver=esp32c3.gpio,property=strap_mode,value=0x02 \
                    -drive file=build/qemu_efuse.bin,if=none,format=raw,id=efuse \
                    -global driver=nvram.esp32c3.efuse,property=drive,value=efuse \
                    -serial tcp::5555,server,nowait

(Once you run the above command you will be able to see the version of the QEMU binary in such format QEMU 8.2.0 monitor. Make sure the version is ≥ 8.2.0)

Once QEMU is up running in the download mode, you should be able to check the eFuses summary using espefuse.py in the ESP-IDF environment terminal window:

export ESPPORT=socket://localhost:5555

espefuse.py -p $ESPPORT --before=no_reset summary

Note: While running QEMU in the download mode the serial output can be redirected to a TCP port. As done in the above QEMU command we have used port 5555, thus you need to set the variable ESPPORT to socket://localhost:5555 or use the port directly for all the related operations.

You should now be able to view an empty or clean eFuses summary similar to a physical hardware chip.

You would also need to set the ECO version as required. For example, if an ESP32-C3 v0.3 is to be used, you need to set the eFuse WAFER_VERSION_MINOR_LO to value 3.

espefuse.py -p $ESPPORT --before=no_reset burn_efuse WAFER_VERSION_MINOR_LO 3

Finally burn the HMAC key in KEY_BLOCK3 with the key purpose HMAC_UP that would be used for NVS encryption:

espefuse.py -p $ESPPORT --before=no_reset burn_key BLOCK_KEY3 hmac_key.bin HMAC_UP

Once you are done with burning all the required eFuses, you need to close QEMU by entering the “quit” command.

5. Run the firmware using QEMU

We are now ready to run the firmware by running QEMU in the boot mode using the command:

qemu-system-riscv32 -nographic \
                    -M esp32c3 \
                    -drive file=build/flash_image.bin,if=mtd,format=raw \
                    -drive file=build/qemu_efuse.bin,if=none,format=raw,id=efuse \
                    -global driver=nvram.esp32c3.efuse,property=drive,value=efuse \
                    -serial mon:stdio

Note: Supply the same merged flash image and the updated eFuses file generated in the previous steps.

As we have used stdio as output destination to the serial port, we should now be able to see the following success logs of enabling secure boot, flash encryption and NVS encryption respectively along with their corresponding eFuses burned in the eFuse file, and the merged flash_image being encrypted:

> qemu-system-riscv32 -nographic \
                    -M esp32c3 \      
                    -drive file=build/flash_image.bin,if=mtd,format=raw \       
                    -drive file=build/qemu_efuse.bin,if=none,format=raw,id=efuse \
                    -global driver=nvram.esp32c3.efuse,property=drive,value=efuse \
                    -serial mon:stdio
       
Adding SPI flash device
ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd5990,len:0x3b48
load:0x403cc710,len:0xb9c
load:0x403ce710,len:0x5b78
entry 0x403cc71a
I (1) boot: ESP-IDF v5.3-dev-2547-g8b3821ca67 2nd stage bootloader
I (2) boot: compile time Mar 14 2024 15:09:57
I (5) boot: chip revision: v0.3
I (7) boot.esp32c3: SPI Speed      : 80MHz
I (7) boot.esp32c3: SPI Mode       : SLOW READ
I (8) boot.esp32c3: SPI Flash Size : 2MB
I (11) boot: Enabling RNG early entropy source...
I (17) boot: Partition Table:
I (17) boot: ## Label            Usage          Type ST Offset   Length
I (18) boot:  0 nvs              WiFi data        01 02 0000e000 00006000
I (18) boot:  1 storage          Unknown data     01 ff 00014000 00001000
I (19) boot:  2 factory          factory app      00 00 00020000 00100000
I (19) boot:  3 nvs_key          NVS keys         01 04 00120000 00001000
I (20) boot:  4 custom_nvs       WiFi data        01 02 00121000 00006000
I (20) boot: End of partition table
I (22) esp_image: segment 0: paddr=00020020 vaddr=3c030020 size=0c1d8h ( 49624) map
I (36) esp_image: segment 1: paddr=0002c200 vaddr=3fc8b600 size=01548h (  5448) load
I (38) esp_image: segment 2: paddr=0002d750 vaddr=40380000 size=028c8h ( 10440) load
I (42) esp_image: segment 3: paddr=00030020 vaddr=42000020 size=21034h (135220) map
I (76) esp_image: segment 4: paddr=0005105c vaddr=403828c8 size=08c84h ( 35972) load
I (86) esp_image: segment 5: paddr=00059ce8 vaddr=00000000 size=062e8h ( 25320) 
I (93) esp_image: Verifying image signature...
I (95) secure_boot_v2: Secure boot V2 is not enabled yet and eFuse digest keys are not set
I (97) secure_boot_v2: Verifying with RSA-PSS...
I (103) secure_boot_v2: Signature verified successfully!
I (104) boot: Loaded app from partition at offset 0x20000
I (105) secure_boot_v2: enabling secure boot v2...
I (109) efuse: Batch mode of writing fields is enabled
I (110) esp_image: segment 0: paddr=00000020 vaddr=3fcd5990 size=03b48h ( 15176) 
I (114) esp_image: segment 1: paddr=00003b70 vaddr=403cc710 size=00b9ch (  2972) 
I (116) esp_image: segment 2: paddr=00004714 vaddr=403ce710 size=05b78h ( 23416) 
I (122) esp_image: Verifying image signature...
I (124) secure_boot_v2: Secure boot V2 is not enabled yet and eFuse digest keys are not set
I (125) secure_boot_v2: Verifying with RSA-PSS...
I (127) secure_boot_v2: Signature verified successfully!
I (127) secure_boot_v2: Secure boot digests absent, generating..
I (141) secure_boot_v2: Digests successfully calculated, 1 valid signatures (image offset 0x0)
I (141) secure_boot_v2: 1 signature block(s) found appended to the bootloader.
I (142) secure_boot_v2: Burning public key hash to eFuse
I (143) efuse: Writing EFUSE_BLK_KEY0 with purpose 9
I (208) secure_boot_v2: Digests successfully calculated, 1 valid signatures (image offset 0x20000)
I (209) secure_boot_v2: 1 signature block(s) found appended to the app.
I (210) secure_boot_v2: Application key(0) matches with bootloader key(0).
I (210) secure_boot_v2: Revoking empty key digest slot (1)...
I (211) secure_boot_v2: Revoking empty key digest slot (2)...
I (211) secure_boot_v2: blowing secure boot efuse...
I (212) secure_boot: Enabling Security download mode...
I (212) secure_boot: Disable hardware & software JTAG...
I (215) efuse: BURN BLOCK4
I (236) efuse: BURN BLOCK4 - OK (write block == read block)
I (236) efuse: BURN BLOCK0
I (256) efuse: BURN BLOCK0 - OK (all write block bits are set)
I (259) efuse: Batch mode. Prepared fields are committed
I (259) secure_boot_v2: Secure boot permanently enabled
I (260) boot: Checking flash encryption...
I (263) efuse: Batch mode of writing fields is enabled
I (264) flash_encrypt: Generating new flash encryption key...
I (265) efuse: Writing EFUSE_BLK_KEY1 with purpose 4
I (266) flash_encrypt: Disable UART bootloader encryption...
I (266) flash_encrypt: Disable UART bootloader cache...
I (266) flash_encrypt: Disable JTAG...
I (267) efuse: BURN BLOCK5
I (293) efuse: BURN BLOCK5 - OK (write block == read block)
I (293) efuse: BURN BLOCK0
I (313) efuse: BURN BLOCK0 - OK (all write block bits are set)
I (316) efuse: Batch mode. Prepared fields are committed
I (316) esp_image: segment 0: paddr=00000020 vaddr=3fcd5990 size=03b48h ( 15176) 
I (321) esp_image: segment 1: paddr=00003b70 vaddr=403cc710 size=00b9ch (  2972) 
I (322) esp_image: segment 2: paddr=00004714 vaddr=403ce710 size=05b78h ( 23416) 
I (329) esp_image: Verifying image signature...
I (331) secure_boot_v2: Verifying with RSA-PSS...
I (333) secure_boot_v2: Signature verified successfully!
I (479) flash_encrypt: bootloader encrypted successfully
I (492) flash_encrypt: partition table encrypted and loaded successfully
I (493) flash_encrypt: Encrypting partition 1 at offset 0x14000 (length 0x1000)...
I (505) flash_encrypt: Done encrypting
I (505) esp_image: segment 0: paddr=00020020 vaddr=3c030020 size=0c1d8h ( 49624) map
I (518) esp_image: segment 1: paddr=0002c200 vaddr=3fc8b600 size=01548h (  5448) 
I (520) esp_image: segment 2: paddr=0002d750 vaddr=40380000 size=028c8h ( 10440) 
I (524) esp_image: segment 3: paddr=00030020 vaddr=42000020 size=21034h (135220) map
I (558) esp_image: segment 4: paddr=0005105c vaddr=403828c8 size=08c84h ( 35972) 
I (567) esp_image: segment 5: paddr=00059ce8 vaddr=00000000 size=062e8h ( 25320) 
I (574) esp_image: Verifying image signature...
I (575) secure_boot_v2: Verifying with RSA-PSS...
I (577) secure_boot_v2: Signature verified successfully!
I (577) flash_encrypt: Encrypting partition 2 at offset 0x20000 (length 0x100000)...
I (3532) flash_encrypt: Done encrypting
I (3532) flash_encrypt: Encrypting partition 3 at offset 0x120000 (length 0x1000)...
I (3544) flash_encrypt: Done encrypting
I (3545) flash_encrypt: Setting CRYPT_CNT for permanent encryption
I (3548) efuse: BURN BLOCK0
I (3568) efuse: BURN BLOCK0 - OK (all write block bits are set)
I (3573) flash_encrypt: Flash encryption completed
I (3574) boot: Resetting with flash encryption enabled...
ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x3 (RTC_SW_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
Valid secure boot key blocks: 0
secure boot verification succeeded
load:0x3fcd5990,len:0x3b48
load:0x403cc710,len:0xb9c
load:0x403ce710,len:0x5b78
entry 0x403cc71a
I (3657) boot: ESP-IDF v5.3-dev-2547-g8b3821ca67 2nd stage bootloader
I (3658) boot: compile time Mar 14 2024 15:09:57
I (3662) boot: chip revision: v0.3
I (3664) boot.esp32c3: SPI Speed      : 80MHz
I (3664) boot.esp32c3: SPI Mode       : SLOW READ
I (3665) boot.esp32c3: SPI Flash Size : 2MB
I (3668) boot: Enabling RNG early entropy source...
I (3673) boot: Partition Table:
I (3673) boot: ## Label            Usage          Type ST Offset   Length
I (3674) boot:  0 nvs              WiFi data        01 02 0000e000 00006000
I (3674) boot:  1 storage          Unknown data     01 ff 00014000 00001000
I (3675) boot:  2 factory          factory app      00 00 00020000 00100000
I (3675) boot:  3 nvs_key          NVS keys         01 04 00120000 00001000
I (3676) boot:  4 custom_nvs       WiFi data        01 02 00121000 00006000
I (3676) boot: End of partition table
I (3678) esp_image: segment 0: paddr=00020020 vaddr=3c030020 size=0c1d8h ( 49624) map
I (3694) esp_image: segment 1: paddr=0002c200 vaddr=3fc8b600 size=01548h (  5448) load
I (3698) esp_image: segment 2: paddr=0002d750 vaddr=40380000 size=028c8h ( 10440) load
I (3704) esp_image: segment 3: paddr=00030020 vaddr=42000020 size=21034h (135220) map
I (3741) esp_image: segment 4: paddr=0005105c vaddr=403828c8 size=08c84h ( 35972) load
I (3752) esp_image: segment 5: paddr=00059ce8 vaddr=00000000 size=062e8h ( 25320) 
I (3761) esp_image: Verifying image signature...
I (3765) secure_boot_v2: Verifying with RSA-PSS...
I (3767) secure_boot_v2: Signature verified successfully!
I (3768) boot: Loaded app from partition at offset 0x20000
I (3769) secure_boot_v2: enabling secure boot v2...
I (3769) secure_boot_v2: secure boot v2 is already enabled, continuing..
I (3770) boot: Checking flash encryption...
I (3770) flash_encrypt: flash encryption is enabled (0 plaintext flashes left)
I (3771) boot: Disabling RNG early entropy source...
I (3776) cpu_start: Unicore app
I (3802) cpu_start: Pro cpu start user code
I (3802) cpu_start: cpu freq: 160000000 Hz
I (3803) app_init: Application information:
I (3803) app_init: Project name:     security
I (3803) app_init: App version:      26b03ca
I (3803) app_init: Compile time:     Mar 14 2024 15:09:53
I (3803) app_init: ELF file SHA256:  5ed173a2f...
I (3804) app_init: ESP-IDF:          v5.3-dev-2547-g8b3821ca67
I (3804) efuse_init: Min chip rev:     v0.3
I (3804) efuse_init: Max chip rev:     v1.99 
I (3804) efuse_init: Chip rev:         v0.3
I (3805) heap_init: Initializing. RAM available for dynamic allocation:
I (3806) heap_init: At 3FC8DCD0 len 00032330 (200 KiB): RAM
I (3806) heap_init: At 3FCC0000 len 0001C710 (113 KiB): Retention RAM
I (3806) heap_init: At 3FCDC710 len 00002950 (10 KiB): Retention RAM
I (3806) heap_init: At 50000010 len 00001FD8 (7 KiB): RTCRAM
I (3815) spi_flash: detected chip: gd
I (3815) spi_flash: flash io: dio
W (3816) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
I (3817) flash_encrypt: Flash encryption mode is RELEASE
I (3820) nvs_sec_provider: NVS Encryption - Registering HMAC-based scheme...
I (3821) sleep: Configure to isolate all GPIO pins in sleep state
I (3822) sleep: Enable automatic switching of GPIO sleep configuration
I (3827) main_task: Started on CPU0
I (3827) main_task: Calling app_main()

Example to check Flash Encryption status
This is esp32c3 chip with 1 CPU core(s), WiFi/BLE, silicon revision v0.3, 2MB external flash
FLASH_CRYPT_CNT eFuse value is 7
Flash encryption feature is enabled in RELEASE mode
Erasing partition "storage" (0x1000 bytes)
Writing data with esp_partition_write:
I (3827) example: 0x3fc8fa00   00 01 02 03 04 05 06 07  08 09 0a 0b 0c 0d 0e 0f  |................|
I (3827) example: 0x3fc8fa10   10 11 12 13 14 15 16 17  18 19 1a 1b 1c 1d 1e 1f  |................|
Reading with esp_partition_read:
I (3837) example: 0x3fc8fa20   00 01 02 03 04 05 06 07  08 09 0a 0b 0c 0d 0e 0f  |................|
I (3837) example: 0x3fc8fa30   10 11 12 13 14 15 16 17  18 19 1a 1b 1c 1d 1e 1f  |................|
Reading with esp_flash_read:
I (3837) example: 0x3fc8fa20   75 75 ca b0 e6 09 a7 c1  bd c0 8a 08 e3 24 25 47  |uu...........$%G|
I (3837) example: 0x3fc8fa30   a5 e7 94 b4 04 1e 55 d5  ff 04 c9 b8 55 a7 0a 7f  |......U.....U...|
I (3847) nvs: NVS partition "nvs" is encrypted.
I (3857) example: NVS partition "custom_nvs" is encrypted.
I (3857) main_task: Returned from app_main()

You can terminate the QEMU session, using control+A and then pressing X.

Just to verify:

As we have selected Flash Encryption Release mode, if you try checking out the eFuses summary by running QEMU in the download mode, you will come across the following error:

A fatal error occurred: Secure Download Mode is enabled. The tool can not read eFuses.

As you have the eFuses file with yourself, you can always modify it, and this opens a lot of possibilities to test your firmware with different eFuses combinations.

Future Work

Currently, you can quickly try out any ESP-IDF (master branch) based application using QEMU by just running the command idf.py qemu. This command handles all the intermediary steps like generation of eFuses file and the merged binary. But as of now it does not support using a pre-programmed eFuses file, instead it creates a new one for every instance of the run. We are trying to support usage of pre-programmed eFuses file as this will surely increase the user experience of using the emulator approach for such use-cases.

Summary

Thus, we have seen that the emulator approach surely provides an advantage to iterate over and debug various security configurations and speed up the testing process to finally develop a production-ready configuration that can be tested on the real hardware, without the risk of bricking it due to any misconfigurations.

In part 2 of this blog, we would go through the host-based workflow for enabling the security features using QEMU.

Till then, in case you are unsure about the boot loader boot workflow to enable security features, you could safely try it out using ESP32-C3 QEMU first to avoid any hardware damage.

We are actively working to enable support for any other remaining peripherals of an ESP32-C3 as well, do let us know your feedback and if you come across any issues, feel free to open a discussion/issue at our GitHub repository.

Trying out ESP32-C3’s security features using QEMU was originally published in The ESP Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

Targeted at C++ developers who want to create powerful applications using the ESP-IDF. The book explains step by step the complexities of IoT development with the ESP32. Vedat Ozan Oner, the author, is recognized for his passion for IoT, ability of making tricky topics easy to understand.

Content and Structure

The book is well-organized into twelve detailed chapters, each focusing on a specific area of ESP32 development. Starting with a basic introduction to IoT and the ESP32 platform in the first chapter and moving to advanced discussions on Machine Learning and Edge Impulse Development in later chapters, the book provides a step-by-step learning path. Oner introduces complex concepts like LittleFS or FlatBuffers at just the right time, allowing readers to build their knowledge gradually.

Who is it for?

While the book is a valuable source of information for students and hobbyist makers, the readers are expected to have a basic knowledge of software development. The book content breaks down complex concepts and code into smaller, manageable parts, which are then put together into larger applications. This approach makes the learning process smoother and shows how to apply theory to real-life projects.

Key Highlights

One of the book’s important points is coverage of security in IoT, a critical yet often neglected topic. Chapter 7 dives into essential security features needed for any large-scale IoT project, including secure boot processes and Over-the-Air (OTA) updates.

The chapters on Smart Home solutions and Machine Learning bring the book up to date with the latest trends in AI and IoT. These sections are especially notable, offering a peek into the future of IoT devices that are not just connected but also smart.

Practicality and Relevance

“Developing IoT Projects with ESP32” is packed with practical examples, source code, and advice that can be used right away in real projects. The use of diagrams and code snippets helps clarify complex topics, making this book a hands-on guide for developers looking to improve their IoT development skills.

Conclusion

Overall, “Developing IoT Projects with ESP32” is a comprehensive and current guide. Whether you are a student, a hobbyist maker or an experienced developer, this book is a valuable resource, offering insights into security, OTA, AI, and ML, ensuring that your IoT projects are not only functional but also secure and forward-looking.

Book review: Developing IoT Projects with ESP32 (2nd Edition) was originally published in The ESP Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

ESP ZeroCode allows device makers to instantly specify, build and launch connected products, right through their browsers. A wide variety of products such as lightbulbs, lighting fixtures, led strips, sockets, switches, roller blinds, refrigerators, laundry washers, thermostats and more are supported.

Articles

The various articles on ESP ZeroCode are available below:

• Matter based connected devices: Announcing ESP ZeroCode
• Appliances with Matter and Cloud Connectivity: Announcing ESP ZeroCode ExL Module
• What’s new with ESP ZeroCode

Podcast

ESP ZeroCode was originally published in The ESP Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

Announcing ESP ZeroCode ExL powered by AWS IoT ExpressLink — Simplifying Matter-compatible Cloud-connected Devices

As a part of our efforts to make the development of Matter protocol-enabled devices easy, Espressif announced ESP ZeroCode modules and ESP ZeroCode Console earlier this year. These ESP ZeroCode modules are well-suited for Matter connectivity for simple devices such as lighting fixtures, switches, sockets, blind controllers, and sensors. You can use ESP ZeroCode Console to configure, evaluate, and order ESP ZeroCode modules.

In continuation of these efforts, Espressif, in collaboration with Amazon Web Services (AWS), is glad to announce the ESP ZeroCode ExL connectivity module powered by AWS IoT ExpressLink. This module is based on Espressif’s ESP32-C6 system-on-chip (SoC) providing Wi-Fi 6, Bluetooth 5 (LE), and 802.15.4 connectivity. It contains built-in Matter and cloud connectivity software providing a simple AT commands-based serial interface to the host. With such a simplified integration, you can build Matter-compliant, secure IoT devices that connect to AWS IoT Core and other AWS services.

Why ESP ZeroCode ExL?

• When device makers want to build cloud-connected devices, they have to write and maintain a significant amount of software. It also needs a deep understanding of connectivity, security, OTA upgrades, and device management.
• The addition of the Matter protocol adds to this making the development, maintenance, and certification even more complex. The ESP ZeroCode ExL module moves this important yet undifferentiated workload onto a separate module, allowing device makers to easily build the hardware interfacing and business logic onto the host MCU.
• On the other hand, AWS IoT ExpressLink is designed and built with the best security and cloud connectivity practices and the Espressif implementation went through rigorous security and functionality testing.

The ESP ZeroCode ExL firmware by Espressif extends the AWS IoT ExpressLink with Matter protocol implementation. This significantly reduces the efforts and time required for building and maintaining connected products by device makers.

Target Devices

The Matter 1.2 specification adds support for new device types including appliances like refrigerators, laundry washers, air purifiers, and air conditioners. Additionally, some of the other device types are already supported such as dimmers, touch switches, and thermostats. Many of these types of devices have a dedicated MCU responsible for building the device logic. Also, cloud connectivity is a major feature for many of these device types especially in the appliance domain. ESP ZeroCode ExL offers simplified Matter and cloud connectivity for these devices and is even well-positioned for retrofitting existing designs to Matter-compliant and cloud-connected ones. It is important to note that ESP ZeroCode ExL can also enable Matter and cloud connectivity to devices beyond these types, supporting devices even with small, resource-constrained host MCUs.

Key Features

ESP ZeroCode ExL implements AWS IoT ExpressLink specification version 1.2 and Matter protocol specification version 1.2.

AWS IoT ExpressLink Features:

1. AWS IoT Core MQTT connectivity
2. AWS IoT Core Device Shadow support
3. AWS IoT Device Defender metrics
4. Self and Host OTA using AWS IoT OTA service
5. Pre-provisioned with X.509 certificates supporting Onboarding by Claim, Multi-Account Registration, JITP, and JITR methods
6. Power management support
7. Asynchronous event handling support

Matter protocol features

1. Matter over Wi-Fi with BLE-based commissioning support
2. Standard device types support as per Matter protocol specification 1.2 and 1.0 with pre-defined device types
3. Support for custom clusters
4. Support for Matter-specific events
5. Matter attributes updates, commands, and event handling support provided to the host
6. Matter OTA support for self and host OTA upgrades
7. Pre-provisioned with DAC certificates

Security

ESP ZeroCode ExL modules are security hardened with hardware root of trust based on Secure Boot and Digital Signature Peripheral. All the sensitive data such as device identity and Wi-Fi network credentials are encrypted and secured using hardware security features such as flash encryption, digital signature peripheral, and HMAC peripheral. ESP ZeroCode ExL firmware is tested with the AWS-provided regression test suite. Communication interfaces such as Wi-Fi, BLE, and serial interface are verified against memory corruption attacks. Secure OTA ensures only the trusted firmware gets executed on the module as well as on the host. These security features add significant value and make the job of device makers significantly easier.

Ready for Evaluation?

Espressif provides an easy evaluation through the ESP ZeroCode Console for the ESP ZeroCode ExL module. You can use any ESP32-C6 development board to quickly try out the functionality completely in the web browser. ESP ZeroCode Console supports a refrigerator, laundry washer, air conditioner, thermostat, and dimmer device types with ESP ZeroCode ExL module. We will be soon expanding on these device types.

If you need more information about ESP ZeroCode ExL modules, please reach out to us at zerocode@espressif.com and we will get back to you as quickly as we can.

ESP ZeroCode ExL Module powered by AWS IoT ExpressLink — Simplifying Matter-compatible… was originally published in The ESP Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

The “software bill of materials” (SBOM) has emerged as a key building block in software security and software supply chain risk management. An SBOM is a comprehensive list of all the software components, dependencies, and metadata associated with an application.

Espressif believes that this information is a key step towards ensuring the security of the connected devices. And as such, we have now enabled easy to use tools and solutions to track and analyze this information.

In this blog post, we shall look through the Espressif’s SBOM generator and analysis tool, ESP-IDF-SBOM.

SBOM

According to National Telecommunications and Information Administration’s (NTIA) SBOM FAQ, the official definition of SBOM goes as follows:

A Software Bill of Materials (SBOM) is a complete, formally structured list of components, libraries, and modules that are required to build (i.e., compile and link) a given piece of software and the supply chain relationships between them. These components can be open source or proprietary, free or paid, and widely available or restricted access.

Key data fields for each component includes:

• Supplier Name
• Component Name
• Version of the Component
• Other Unique Identifiers
• Dependency Relationship
• Author of SBOM Data
• Timestamp

SBOM data needs to be presented in consistent and digestible formats. Some formats to handle the data representation are SPDX, CycloneDX etc.

Simple conceptual SBOM tree for wifi_provisioning component from ESP-IDF looks like below:

SPDX

Software Package Data Exchange (SPDX) is an open standard for communicating software bill of materials (SBOM) information that supports accurate identification of software components, explicit mapping of relationships between components, and the association of security and licensing information with each component.

The image below outlines what data can be found in an SPDX document.

ESP-IDF-SBOM

ESP-IDF-SBOM is a SBOM generator tool. It generates SPDX format SBOM for ESP-IDF based applications. This tool also allows to check the generated SBOM for known security vulnerabilities against National Vulnerabilitiy Database (NVD).

SBOM Generator Workflow

Brief tool workflow goes like:

• Collect sbom.yml (a manifest file) files from dependant components
• Parse project description file generated by the ESP-IDF build system
• Generate SPDX report
• Scan generated SPDX against the CVE databse to generate final report

Getting Started

Install the tool and checkout its help:

$ pip install esp-idf-sbom
$ esp-idf-sbom --help

usage: esp-idf-sbom [-h] [-q] [-n] [-f] [-v] [-d] [--no-progress] {create,check,manifest} ...

ESP-IDF SBOM tool

positional arguments:
  {create,check,manifest}
                        sub-command help
    create              Create SBOM file based on the ESP-IDF project_description.json file.
    check               Check components/submodules in the ESP-IDF SBOM file for possible
                        vulnerabilities reported in the National Vulnerability Database.
    manifest            Commands operating atop of manifest files.

options:
  -h, --help            show this help message and exit
  -q, --quiet           By default auxiliary messages like errors, warnings, debug messages
                        or progress are reported to the standard error stream. With this
                        option set, all such messages are suppressed.
  -n, --no-colors       Do not emit color codes. By default color codes are used when stdout
                        or stderr is connected to a terminal.
  -f, --force-colors    Emit color codes even when stdout or stderr is not connected to a
                        terminal.
  -v, --verbose         Be verbose. Messages are printed to standard error output.
  -d, --debug           Print debug information. Messages are printed to standard error
                        output.
  --no-progress         Disable progress bar.

Generate the SBOM file:

$ cd esp-idf/examples/provisioning/wifi_prov_mgr
$ idf.py build
$ esp-idf-sbom create <project description file> --output-file prj.spdx

The project description file is a path to the project_description.json file, which is by default created by the ESP-IDF build system in the project's build directory.

Check SBOM against the security vulnerabilities:

$ esp-idf-sbom check prj.spdx

                                        Report summary                                         
┌───────────────────────────────────┬─────────────────────────────────────────────────────────┐
│ Date:                             │ 2023-10-10T08:21:39Z                                    │
│ Project name:                     │ project-wifi_prov_mgr                                   │
│ Project version:                  │ v5.2-dev-3250-g7d8f015a4c                               │
│ Vulnerability database:           │ NATIONAL VULNERABILITY DATABASE (https://nvd.nist.gov)  │
│ Generated by tool:                │ esp-idf-sbom (0.8.0)                                    │
│ Generated with command:           │ esp-idf-sbom check prj.spdx                             │
│ Number of scanned packages:       │ 57                                                      │
├───────────────────────────────────┼─────────────────────────────────────────────────────────┤
│ CRITICAL CVEs found:              │                                                         │
│ Packages affect by CRITICAL CVEs: │                                                         │
│ Number of CRITICAL CVEs:          │ 0                                                       │
├───────────────────────────────────┼─────────────────────────────────────────────────────────┤
│ HIGH CVEs found:                  │                                                         │
│ Packages affect by HIGH CVEs:     │                                                         │
│ Number of HIGH CVEs:              │ 0                                                       │
├───────────────────────────────────┼─────────────────────────────────────────────────────────┤
│ MEDIUM CVEs found:                │                                                         │
│ Packages affect by MEDIUM CVEs:   │                                                         │
│ Number of MEDIUM CVEs:            │ 0                                                       │
├───────────────────────────────────┼─────────────────────────────────────────────────────────┤
│ LOW CVEs found:                   │                                                         │
│ Packages affect by LOW CVEs:      │                                                         │
│ Number of LOW CVEs:               │ 0                                                       │
├───────────────────────────────────┼─────────────────────────────────────────────────────────┤
│ UNKNOWN CVEs found:               │                                                         │
│ Packages affect by UNKNOWN CVEs:  │                                                         │
│ Number of UNKNOWN CVEs:           │ 0                                                       │
├───────────────────────────────────┼─────────────────────────────────────────────────────────┤
│ All CVEs found:                   │                                                         │
│ All packages affect by CVEs:      │                                                         │
│ Total number of CVEs:             │ 0                                                       │
└───────────────────────────────────┴─────────────────────────────────────────────────────────┘


Packages with No Identified Vulnerabilities
                        
┏━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃        Package        ┃          Version          ┃                   CPE                   ┃
┡━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ project-wifi_prov_mgr │ v5.2-dev-3250-g7d8f015a4c │ cpe:2.3:a:espressif:esp-idf:5.2-dev-325 │
│                       │                           │       0-g7d8f015a4c:*:*:*:*:*:*:*       │
├───────────────────────┼───────────────────────────┼─────────────────────────────────────────┤
│         lwip          │           2.1.3           │ cpe:2.3:a:lwip_project:lwip:2.1.3:*:*:* │
│                       │                           │                :*:*:*:*                 │
├───────────────────────┼───────────────────────────┼─────────────────────────────────────────┤
│         cjson         │          1.7.16           │ cpe:2.3:a:cjson_project:cjson:1.7.16:*: │
│                       │                           │               *:*:*:*:*:*               │
├───────────────────────┼───────────────────────────┼─────────────────────────────────────────┤
│      protobuf-c       │           1.4.1           │ cpe:2.3:a:protobuf-c_project:protobuf-c │
│                       │                           │          :1.4.1:*:*:*:*:*:*:*           │
├───────────────────────┼───────────────────────────┼─────────────────────────────────────────┤
│       mbed_tls        │           3.4.1           │ cpe:2.3:a:arm:mbed_tls:3.4.1:*:*:*:*:*: │
│                       │                           │                   *:*                   │
├───────────────────────┼───────────────────────────┼─────────────────────────────────────────┤
│       freertos        │          10.4.3           │ cpe:2.3:o:amazon:freertos:10.4.3:*:*:*: │
│                       │                           │                 *:*:*:*                 │
└───────────────────────┴───────────────────────────┴─────────────────────────────────────────┘

...snip

Some highlights from the SBOM vulnerability check:

• wifi_prov_mgr application from ESP-IDF v5.2-dev was used for the exercise
• It is possible to scan the components which are not linked into final executable by adding --check-all-packages in the check command shown above
• It is also possible to generate the SBOM report for the ESP-IDF bootloader. Bootloader specific build description file can be found in the build/bootloader directory inside the project
• Some key components like RTOS, Networking Stack, TLS Stack etc. having Common Platform Enumeration entries have been highlighted in the above output
• Tool also displays information about other component and libraries (not shown in the above log) which are part of the build process

Report Format

This tool supports multiple formats for the generated output report like JSON, CSV etc. Please refer to the tool help for more details.

Compatibility

SPDX being a standard format for SBOM, also offers compatibility with the external tools. SBOM files generated from esp-idf-sbom can also be scanned using tools like cve-bin-tool. This offers an added advantage if you already have any external tools integrated in your system and want to take advantage of its specific features (e.g., more extended scan against different CVE databases).

Summary

To summarize, some key advantages of SBOM are:

• Forms inventory of the components building the software artifacts
• Lists software licenses, component versions and helps to keep them up-to-date
• Helps to perform security vulnerability analysis
• Becoming a pre-requisite in many security related certifications

ESP-IDF-SBOM tool is useful to generate SBOM for ESP-IDF based projects. The tool can also further help to scan and setup process for continuous security vulnerability scanning of the project.

We are actively working on to enable wider SBOM coverage across our software solutions and looking for feedback on the ESP-IDF-SBOM tool.

Please do try and share your experience!

Software Bill of Materials was originally published in The ESP Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.