Secure Boot Process#

Introduction#

Secure Boot is a foundational component of platform security, and without it, other security aspects such as secure storage, secure transport, secure identity, and data confidentiality often can be subverted through the injection of malicious code.

Secure Boot works to ensure each piece of firmware is validated for authenticity and integrity before it is allowed to run. Each authenticated module can also validate additional modules before executing them, forming a chain of trust. If any module fails its security check, it is not allowed to run, and program control will typically stall in the validating module. In most lightweight IoT systems, the behavior of a Secure Boot failure is to cause the device to halt in the bootloader until an authentically signed image can be loaded onto it. While this may seem extreme, it is a better outcome than a smart light bulb being repurposed to mine crypto-currency, or a smart speaker being repurposed as a surveillance device on the end user’s private conversations.

The first link in the chain of trust is the root of trust. This is often the weakest link in the Secure Boot chain because the root of trust itself is not checked for authenticity or integrity. The security strength of the root of trust lies in its immutability. The strongest roots of trust have their firmware origin in ROM. In the SiWx917, the root of trust (i.e., security bootloader) is in ROM.

SiWx917 devices use a security bootloader, which runs from ROM on the Network Processor (NWP) core and an application bootloader which runs on the application core (M4). The security bootloader is responsible for verifying the integrity and authenticity of the NWP and M4 firmware in flash before allowing it to be loaded by the application bootloader.

Initializing PUF and Generating Intrinsic Keys in SiWx917#

The SiWx917 uses a physically unclonable function (PUF) circuit for creating a unique-per-device encryption key. The PUF on each device must be initialized to function. Once initialized, a PUF activation code is stored in the NWP flash. The activation code is 1192 bytes in size. During initialization, several so-called intrinsic keys are derived from the PUF. Each of these intrinsic keys is 256 bits in length and is stored in the form of a 52 byte key code in the NWP flash. The intrinsic keys relevant to secure boot are summarized in the table below.

ECDSA-P256 Secure Boot in SiWx917#

Firmware running on the SiWx917 can be validated for authenticity with a digital signature (ECDSA-P256), validated for integrity using a message integrity check (MIC), or both. The options can be set either in the MBR or in the device’s eFuses depending on the user’s development journey. Important points to note -

• If the secure_boot_enable eFuse is set for a particular core, the firmware image for the core must include a valid MIC.

• If the digital_signature_validation eFuse is set for a particular core, the firmware image must include a valid signature.

Silicon Labs recommends the use of ECDSA-P256 signatures for validating firmware images since this method is more secure than a MIC. ECDSA is a stronger method of protection since it uses an asymmetric key and the private signing key does not exist on the device. Using MIC only for validating firmware is a weaker method of protection since it uses a symmetric key that does exist on the device. If the key is leaked, unauthorized users will be able to calculate a valid MIC for their own firmware. However, if performance is critical, the use of a MIC for validating firmware offers some protection.

Once a firmware image has been built, an RPS file is created which can be flashed to the device. As part of the creation of the RPS file, a MIC can be calculated with the AES-CMAC algorithm using the OTA key. The OTA key for NWP is used to calculate the MIC for the NWP firmware and the M4 OTA key is used to calculate the MIC for the M4 firmware. In addition, a message digest can be produced from the firmware image using one of the supported hash algorithms, SHA2/256, SHA2/384 or SHA2/512. The message digest for M4 firmware is then signed to produce an ECDSA-P256 signature. The M4 private key is used to sign images for the M4 core and the NWP private key is used to sign images for the TA core. Signatures for either image are verified by the security bootloader using the corresponding M4 or NWP public key which is stored wrapped in flash on the device. The M4 core is held in reset until a valid image is loaded. Once the image is successfully verified, it can be loaded and allowed to run. If the image verification fails, the M4 core will be held in reset, halting execution.

Note: If the SiWx917 is operating with an unsigned firmware image at the time when secure boot is enabled, the device will continue to run that firmware image post-enablement of secure boot. All subsequent firmware upgrade images must be signed. Silicon Labs' recommends erasing any prior unsigned images on the device after enabling secure boot during manufacturing.

Security Bootloader#

The security bootloader executes from ROM, is accessed by the NWP core, and is maintained by Silicon Labs.

Upon reset, execution always begins with the security bootloader which performs the following functions:

1. Configures hardware based on the contents of the MBR and eFuse settings

2. Optionally, performs In-system programming (ISP) and firmware upgrades

3. Authenticates firmware in flash

4. Starts the application bootloader

Application Bootloader#

Once started by the security bootloader, the application bootloader, also executing from ROM, is accessed by the M4 core to load the M4 application and start executing it.

Flash Protection Levels#

The security bootloader provides 3 flash protection levels which can be used to secure different sections of the Flash for different purposes:

Anti-Rollback Protection#

Anti-rollback protection is designed to prevent the SiWx917 from downgrade attacks. Downgrade attacks exploit vulnerabilities that are patched in more recent versions of firmware by downgrading that firmware to an older version that contains known vulnerabilities. It is important to protect against downgrade attacks to ensure that if an issue is patched, it cannot be exploited again once the firmware is upgraded to a patched version. Anti-rollback protection can be enabled for the NWP or M4 core by setting the appropriate eFuse bit. See the eFuse Reference Table for more information. For a detailed description of how firmware updates are applied, please refer to section 3 of AN1431.

Firmware versions are composed as follows:

The version of any application upgrade is checked for the following before applying the upgrade:

• All 32 bits are checked to verify that the new image is greater than the currently installed image

• The security version is checked to verify that it is greater than the security version of the currently installed image

The application version, which contains Major, Minor and Build number versions (in the format Major:Minor:Build), is stored in the Flash Memory Controller (FMC). Firmware updates can take place when only the application version increases, the security version increases or both.

In case the anti-rollback check fails, the firmware update is not copied to the application space to replace the existing firmware and the existing firmware image continues to execute.

Once an image has been successfully loaded, OTP storage will be updated with the security version if the ‘antirollback’ eFuse has been set for the core that the image runs on. The security version of the current firmware for each core is stored separately in OTP. The security version is represented by setting the number of bits in OTP. For the NWP core, the security version can be between 1 and 128, for the M4 core, the security version can be between 1 and 64.

Example showing storage of security versions

Note: The MSB on the NWP core is bit 127, and the MSB on the M4 core is 63.

Authenticated Firmware Update Process#

The security bootloader can validate the ECDSA-P256 signature of update images using the appropriate public key and/or the MIC using the appropriate AES key. The keys used are summarized in Key Reference section. Update images can be delivered in RPS format. Refer to AN1431: SiWx917 SoC Firmware Update for additional information. In case a firmware upgrade is determined to be invalid, either because of an invalid signature or MIC or because the firmware version is too low, the upgrade will not be applied and the previous firmware image remains in place.