Overview

Secure Boot is a key technology for ensuring the security of IoT devices. Its core purpose is to ensure that devices only run authorized firmware, preventing malicious code injection or illegal firmware tampering. The core method utilizes asymmetric encryption private key signing and public key verification technology: developers use private keys to sign firmware; chips use public keys during startup to verify signatures, thereby ensuring firmware integrity and authenticity.

When the device powers on, the Boot ROM code internally solidified in the chip automatically checks whether the firmware about to run has a legitimate digital signature: If verification passes, the firmware source is confirmed as trusted, and the system continues executing the subsequent startup process; if verification fails, the firmware is considered untrusted, sensitive states are cleared, and startup is terminated.

This process is implemented through the “Chain of Trust” mechanism - the trust relationship starts from tamper-proof hardware (ROM) and extends to the final application firmware through step-by-step signature verification. This ensures that all firmware is trusted throughout the entire operational lifecycle.

Ameba series ICs support different signature algorithms:

RTL8721DxRTL8720ERTL8710ERTL8726ERTL8713ERTL8730ERTL8721F

Algorithm Type	Algorithm Parameters
EdDSA	ed25519

After understanding the signature algorithms supported by Ameba series ICs, the following section introduces the principles and complete process of Secure Boot.

Secure Boot Principles and Process

Secure Boot starts from the ROT composed of Boot ROM + OTP and is passed level by level. The figure below shows the complete Secure Boot usage process:

Secure Boot involves three stages: development, mass production, and runtime, completed by different participants at different times:

• Development Stage (completed by developers):

  • Generate asymmetric key pairs: private keys must be strictly kept confidential, and public key hash values are calculated.

  • Generate signed firmware: use private keys to digitally sign the original firmware, generating a Manifest containing metadata such as public keys, signatures, and original firmware hashes. The Manifest and original firmware are combined to generate signed firmware.

• Mass Production Stage (completed by production line):

  • Burn public key hash values and enable bits: burn the public key hash values generated during the development stage to fixed addresses in the chip OTP. Also burn the Secure Boot enable bit to enable the Secure Boot function.

  • Burn signed firmware: burn the signed firmware generated during the development stage to the chip’s Flash storage.

• Runtime Stage (executed by chip): after the device powers on, Boot ROM verifies the signatures and integrity of firmware at all levels level by level based on the public key hash in OTP. If verification passes, startup continues; if verification fails, sensitive information is cleared and startup is terminated.

Secure Boot Solution

Ameba SDK provides a complete out-of-the-box Secure Boot solution. All complex signature verification mechanisms have been implemented in the SDK, and developers do not need to write code themselves, only needing to configure the SDK according to the user guide. The figure below shows the signature verification process in the chip’s multi-level startup:

Ameba series ICs adopt a multi-level startup process, sequentially executing the following three independent firmware:

• First Stage - Boot ROM: the first code executed after the device powers on is the chip’s internal ROM, which is physically tamper-proof. Boot ROM reads the Bootloader and its Manifest from Flash, uses the OTP public key hash to verify the public key and signature in the Manifest. Then it verifies the Bootloader firmware hash stored in the Manifest. After verification passes, it jumps to execute the Bootloader; if it fails, it clears sensitive states and terminates startup.

• Second Stage - Bootloader: a bootloader loaded from Flash, responsible for loading and security verification of subsequent firmware. Bootloader first verifies the signature of the Key Certificate. The certificate contains the application firmware’s public key hash and also allows adding multiple sets of custom public key hash values. After verification passes, Bootloader extracts the public key hash used to verify application firmware from the certificate, then uses that public key hash to verify the application firmware’s Manifest, and finally calculates and compares the application firmware’s hash value.

• Third Stage - Application: a user application that runs directly, not responsible for firmware verification.

The first two startup stages both execute in the ARM Secure world. Compared with single-level verification, the three-level verification architecture adopted by Ameba has the following advantages:

• Key Isolation: Bootloader and application firmware use different key pairs. Even if the application firmware key is leaked, Bootloader remains secure.

• Flexible Updates: application firmware keys are stored in certificates, allowing application key updates without modifying OTP.

• Permission Separation: developers can maintain application keys, while OEM manufacturers control Bootloader keys, achieving permission separation.