To broaden the scope of features and security of Arduino’s products, we have decided to create a brand new bootloader that is based on MCUboot. This is a brief overview of everything you should be aware of.

Introduction to MCUboot

MCUboot is an safe bootloader solution that provides secure and reliable authenticating firmware as well as a safe firmware updates mechanism, as well as many additional features, including updates encryption, rollback of update and bootstrap for applications.

MCUboot is not dependent on any specific hardware or operating system. As at the time of writing, these operating systems are available: Zephyr mynewt, nuttx and Mbed.

The focus of our work has been keeping it easy and reuse the original OTA design to be used for Arduino boards.

Base blocks for MCUboot

To access the microcontroller’s flash, MCUboot uses the driver layer of the operating system. MCUboot is able to boot multiple images, so its configuration is challenging; for a simple MCUboot configuration, two flash areas need to be specified.

• SLOT 0,0 represents the flash portion that contains the image currently used by the application;
• SLOT 1 represents the flash portion that contains the image of the update application.

A second flash area is required to support MCUboot’s swap scratch known as SCRATCH.

To switch between slots 1 and 0 MCUboot provides a variety of algorithms.

• Overwrite It is the most basic method of upgrading that is supported by MCUBoot. It is simply copying SLOT 1 onto SLOT 0. Rollback is not supported however it is the quickest method for upgrading an image.
• Swap Scratch The method of upgrading is based on an additional flash area in which data is temporarily saved when images swap. With this method, we have the ability to retrieve the original application image in case there is a problem with the new version. One of the biggest negatives to this upgrade technique is the wear-out of the flash, since the scratch area is written on and erased several times during the swap.
• Swap Move Instead of an external scratch space, this upgrade technique makes use of extra space in SLOT 0. The major benefit for swap movement over swap scratch lies in lower wear rate of the flash.

In order to be able to carry out every operation and check, MCUboot needs to store some metadata in the image of the application. This is accomplished using an application called imgtool which process the binary image of the application by reserving space, and then adding all the information required for image verification. It also helps create an error-tolerant swap.

If we examine an image slot more depth, we can divide it into the following flash zones:

• Header Most commonly used to show the length of other components of the slot: size of the header as well as the code size and TLV size. It also indicates the load address for the application as well as the slot magic number that is used to determine if the MCUboot is compatible image.
• Coding The application’s binary.
• TLV The sequence of tuples that have the tag’s length as well as value. Examples include key hash, image hash, signature of image.
• Trailer is used to keep track of the status of swaps when swapping images.

Arduino MCUboot OTA design

To support Arduino OTA, the update file is stored in memory and then processed by the bootloader to allow the application to be updated. In the case of Portenta products the file is put in the second section that is the boards QSPI flash. That means our SLOT 1 is placed into the QSPI flash. The default method for swapping it uses involves swap scratch. The scratch region, which is mapped to a file named scratch.bin, is stored in the QSPI flash. When encrypted images are used, firmware copies from external memory are encrypted by standard, MCUboot will decode an upgrade and takes charge of offsets required prior to writing it to the scratch area. To protect data, another step is taken to ensure data security by that re-encrypts the entire scratch data prior to writing it to SLOT 1. When images are reversed, data stored in internal memory that was not encrypted is encrypted prior to being written into SLOT 1.

NOTE: Using this flash layout, you can load updates over the Internet or mount the device as a mass storage or through it’s DFU interface.

If a fresh update is available and is marked as pending during the next reset MCUboot will handle changing the slots and then applying the latest image to the application.

Aspects of security

MCUboot utilizes two keys for the image signature verification as well as image encryption. To verify the signature of an image, it is the private key that’s utilized to use the imgtool to verify the update, while this key, the public one is utilized by MCUboot to verify the update.

To secure images, The elliptic curvature integrated encryption scheme (ECIES) is utilized with secp256r1’s ephemeral keys and an random AES key to secure the image.

In both instances, MCUboot must be aware of it’s part of the input keys. So, they are stored in flash memory along with the binary bootloader.

In a closer look at the bootloader flash sector , we will discover the following information:

In default, keys aren’t loaded into flash and the bootloader cannot start any sketch. After the keys have been loaded, MCUboot will always check the image’s signature and only boot legitimate sketches. If an encrypted update is identified through reading the TLVs MCUboot will detach keys to decrypt file on the fly before transferring it to an internal flash.

The post Introducing the Arduino secure boot appeared first on Arduino Blog.