Secure Boot and the Cyber Resilience Act

From the Cyber Resilience Act, manufacturers that build devices with digital components conclude that they have to ensure the authenticity and integrity of the firmware running on the device. Otherwise attackers may modify the firmware to extract secret information from or deploy ransomware on the users' devices.

Therefore, manufacturers add Secure Boot to the requirements to ensure that their customers' devices only execute firmware that has been authorized by the manufacturers.

The Rockchip RK3588

Lately the Rockchip RK3588 has attracted attention for embedded and industrial Linux use cases. The main reasons are the high performance, especially in multimedia applications, claims about the long-term availability, and the growing upstream support.

Several of our customers chose to evaluate or build devices around Rockchip SoCs.

Secure Boot on RK3588

The RK3588 includes the necessary hardware support for Secure Boot. Before starting an image, the BootROM may verify the signature of a provided firmware against an immutably hardware-persisted public key.

During system boot, the BootROM verifies the public RSA key in the firmware image against a hash that is stored in OTP eFuses. That key validates the signature of the firmware image header. Because the header contains a hash of the bootloader payload, the bootloader is now trusted and executed. This behavior is hard-coded in the BootROM and cannot be changed.

The build server is responsible for signing the firmware images with the private key of an RSA key pair under the control of the manufacturer. This signature proves that the manufacturer approved this firmware image for execution on their devices.

When the devices are manufactured, the hash of the public key is immutably written into the OTP eFuses of the produced device. This step ensures that the BootROM only accepts firmware that is signed by the manufacturers private key.

Continued chain-of-trust decisions are outside the RK3588 hardware. Device manufacturers may use their preferred verification mechanisms to ensure the authenticity of later stages.

Requirements for Manufacturing Environment

In order to ensure the integrity of this chain-of-trust, device manufacturers must meet several requirements in production.

The private signing key must be stored confidential and accessed only by authorized personnel. If the private key is leaked to unauthorized persons, they may be able to execute modified firmware on the devices. Furthermore, backups of the private key are essential, because without it, releasing further firmware updates is impossible. Therefore, it's advisable to store the key in an HSM (Hardware Security Module).

Manufacturers must ensure the integrity of writing the public key hash into the SoC's OTP eFuses. If that process is compromised, an attacker could write hist key hash and deploy hist malicious firmware.

Hardware Limitations of the RK3588

Cause the root-of-trust is fixed in the BootROM, the RK3588 has several immutable hardware limitations.

The OTP eFuses allow to store only a single root key hash. Revoking or rotating a signing key is not possible, and images cannot be signed by multiple keys. The signing key is a single point of failure.

The BootROM supports only RSA-2048 and RSA-4096, which may be obsolete against future quantum attacks.

The Rockchip Downstream Solution

Rockchip published the Rockchip Linux Secure Boot Developer Guide which documents the hardware behavior of Secure Boot on RK3588, and Rockchip suggestion how to implement the chain-of-trust up to Linux.

I am convinced that the chain-of-trust implementation after the hardware verification should not be prescribed by the hardware vendor, I will focus on the hardware and BootROM related tools.

Rockchip provides the binary rk_sign_tool for code signing. As a closed binary, the tool exposes the risk of eventual bit-rot or abandonment. In this case, updating deployed devices becomes difficult.

To my knowledge, the rk_sign_tool lacks support for storing the private key on an HSM, which reduces the security of the key material. As the rk_sign_tool is a closed, users cannot not add HSM support to it themselves.

In the downstream flow, U-Boot is responsible for writing the public key hash to the OTP. As U-Boot automatically enables secure boot during boot, a manufacturer requires a separate image for enabling Secure Boot. This image is outside the usual test cycle and complicates the manufacturing process.

Secure Boot with barebox on RK3588

To address the drawbacks of the downstream solution, we reimplemented Rockchip's Secure Boot tooling and integrated it into more commonly used open source projects. This facilitates the integration into common developer and manufacturing workflows.

The rkimage tool replaces the rk_sign_tool for signing the firmware images. It embeds the public key into the image header and adds the signature. The barebox build system uses rkimage to automatically create signed barebox images. You may also use it to re-sign existing U-Boot images to entirely avoid the rk_sign_tool.

barebox provides the rksecure command to enable Secure Boot and lock devices. That explicit command enables complex factory processes, because it may be called at any stage during the manufacturing process. The same barebox image that is used for manufacturing can be used on locked and unlocked devices and even in development, which simplifies testing and development. However, enabling Secure Boot at runtime requires OP-TEE support via the rk_secure_boot PTA.

Follow the barebox manual to build signed images and lock devices.

Future Work

Currently, barebox supports Rockchip Secure Boot only for RK3588, but the implementation can be extended to other Rockchip SoCs as well. rkimage may sign Rockchip firmware out-of-the-box if the image header is the same as on RK3588.

Writing the public key hash into OTP eFuses requires extending the Rockchip OTP implementation in the OP-TEE OS to support the necessary SoCs.

The signing tools are not integrated into U-Boot, yet. rkimage can re-sign existing U-Boot images, but requires additional steps after the U-Boot build process. One could port the signing code from rkimage to the respective tools in U-Boot.

U-Boot is not able to interact with the rk_secure_boot PTA. One may add a driver for the rk_secure_boot PTA to U-Boot or implement a Linux user space application to have more options to enable Rockchip Secure Boot at runtime.

Conclusion

The Rockchip Secure Boot in barebox differs in details from Rockchip's proposed and documented solution. The barebox implementation focuses on the hardware interaction to provide better flexibility and maintainability. It is important to understand the differences between the approaches used in barebox and proposed by Rockchip when deploying Secure Boot with barebox on a Rockchip SoC.