Secure Boot and the Manufacturing Chain: Implementation and Impact

December 09, 2025

Blog

Let’s consider the general case where the development team and the manufacturer are two separate entities, possibly different companies in different countries. We will focus on products based on Arm processors.

This is the last piece of the secure boot series brought to you by The Embedded Kit. In this article we will focus on how to bring your design to manufacturing.

We need to prevent confidential information leaks, and in the context of this secure boot article series, we will specifically consider the private keys used for securing the boot.

For these reasons, we need a third-party signing entity, as shown in the following diagram:

1. The development team designs the software image

The development team designs a software image that integrates secure boot. They test the whole mechanism using development keys. These keys cannot be trusted as they are not secret at all. And the team finally delivers an image to the signing entity.

They also provide tools and documentation for the signing entity to be able to sign with other keys. Signing with other keys generally also means inserting related public keys into the software image.

2. Signature by the signing entity

The signing entity may be an individual or a department that owns private keys and keeps them in a vault (physical or digital), for confidentiality.

In our first article on how to enable secure boot on Linux-based platforms, we talked about a chain of trust made of the root key (ROOTKEY) and a user key SWK1. In this example, the signing entity must do the following steps over the software image:

• Insert the public key of SWK1 into the bootloader
• Sign the bootloader with ROOTKEY
• Sign the kernel and rootfs with SWK1
• Compute the hash of the public key of ROOTKEY, that will be burned to the OTP bits of the products

For doing these, they will use the tools and documentation provided by the development team. For signing the bootloader, MPU or SOC vendors provide specific tools that match their specific chips. For example, NXP provides Code Signing Tool (CST), and STMicroelectronics provides STM32CubeIDE.

The keys ROOTKEY and SWK1 are generally stored in a digital vault, and signing with them can be done through a PKCS#11 interface. The private keys can never be extracted, but they can still be used by sending a request saying: “sign this data with the key labelled SWK1”, for instance.

With a tool like openssl, the command line looks like this:

openssl pkeyutl \
        -engine pkcs11 -keyform engine \
        -sign -inkey "pkcs11:object=SWK1;pin-value=1234" \
        -in rootfs.img -out rootfs.img.sig

The resulting software image and hash shall be delivered to the manufacturer.

3. Product provisioning by the manufacturer

The manufacturer must provision each product with the software image and the hash of the ROOTKEY.

The software image gets installed on the storage medium of the product (eMMC, NOR, NAND, SSD, ...).

The ROOTKEY hash gets burnt into the OTP bits of the processor. This cannot be undone or modified, so you better get it right for each product in a reliable manner.

A typical set of commands in u-boot for an imx8m processor is:

# Fuse the hash

fuse prog -y 6 0 0xDADD030D

fuse prog -y 6 1 0x8B5D3EA7

fuse prog -y 6 2 0x4EC5A321

fuse prog -y 6 3 0x836FF123

fuse prog -y 7 0 0x6578C108

fuse prog -y 7 1 0xE7483AAB

fuse prog -y 7 2 0x51FE0260

fuse prog -y 7 3 0x25F904DA

 

# Close the device

fuse prog -y 1 3 0x02000000

 

Additional actions might be taken such as disabling JTAG access.

After that, the manufacturing line should verify that the product boots correctly.

To go further

We have seen an overview of manufacturing steps for products with secure boot.

To go further, you need to consider more topics, such as key rolling. Do you need to change ROOTKEY and SWK1 on the products during their life? Do you need to change these during the manufacturing process, and have different keys for different batches of products?

Besides, the way to handle secure boot from the processor’s perspective greatly depends on the processor vendor. From a developer’s perspective, it would be nice to have some standardization there, to facilitate access to this technology.

Other topics have not been covered, such as provisioning end products with specific credentials such as Wi-Fi passwords. These require additional security mechanisms (encryption, ...).

Lastly, we did not talk about protection against supply chain attacks, where attackers attempt to insert backdoors in software images that get shipped within manufactured products. This is nonetheless something that vendors should definitely take care of via a security risk assessment because of the Cyber Resilience Act.