How to design secure SoCs, Part III: Secure Boot

By KiviCore | May 26, 2025  

As embedded systems become more powerful and interconnected, security at every stage of system operation becomes critical. In previous articles, we discussed secure SoC architectures and key management. This part of the series focuses on secure boot: a foundational mechanism to ensure that only trusted code is executed when the system powers on.

What is Secure Boot and why is it needed

Boot-time vulnerabilities pose critical risk to system integrity. Without a secure boot mechanism, malicious firmware can execute before any protective controls are in place, bypassing traditional security checks entirely.  This early execution grants attackers unrestricted access to low-level system resources, enabling them to implant persistent backdoors, compromise hardware functions, or exfiltrate sensitive data - all without detection by conventional software-based defenses.

Secure boot serves as a fundamental security mechanism, acting as the first line of defense by ensuring that only trusted and authenticated code is executed right from the moment the device is powered on.

Benefits of secure boot in ASIC SoCs:

• Protection against malware, rootkits, and bootkits: By verifying digital signatures, secure boot prevents unauthorized or malicious software from loading and executing during startup. This is particularly effective against bootkits and rootkits that gain low-level access.
• Prevention of unauthorized firmware updates: It ensures that only updates signed by trusted entities, such as the device manufacturer, can be installed, preventing exploitation through malicious firmware.
• Mitigation of supply chain attacks: By verifying authenticity and integrity at boot time, secure boot helps ensure only trusted components are present, even if compromised during manufacturing or distribution.
• Establishes a trusted foundation: It plays a crucial role in establishing a trusted foundation upon which other security mechanisms within the SoC can rely to ensure the operating system and subsequent security software have not been tampered with.

Core Components of the Secure Boot Process

Secure boot is a security standard designed to ensure the integrity of a system's boot process by verifying the digital signatures of key software components, including the bootloader, firmware, and operating system. The principle is to allow only code that has been signed by trusted entities to be executed during the startup sequence. This process effectively prevents unauthorized or malicious software from compromising the system early in the boot process. Cryptographic techniques are employed to confirm that only trusted software is loaded and executed.

Chain of Trust - The Step-by-Step Verification Process

This concept is central to secure boot. It starts with an inherently trusted component that verifies the next component. This component is also known as Root Of Trust (RoT). If it is valid, the system executes it, and this component, in turn, verifies the subsequent one. This sequential step-by-step verification continues until the operating system and applications are loaded, ensuring every piece of software executed is validated.  

Hardware Root of Trust (HRoT): The Anchor of Security

The HRoT serves as the immutable foundation upon which the entire chain of trust is built. It is a set of hardware-based security functions that are inherently trusted and cannot be modified or bypassed by software. This trust is often anchored in a specific piece of hardware within the SoC designed to be secure by its very nature.

Key characteristics of HRoT:

• Immutability: Typically resides in Read-Only Memory (ROM) or One-Time Programmable (OTP) memory, ensuring the initial boot code is unalterable after manufacturing. This prevents attackers from tampering the very first stage of the boot process.
• Primary function: To verify the integrity and authenticity of the next bootable image by checking its digital signature against a trusted public key securely stored within the HRoT.
• Other functions: May also manage cryptographic keys or provide a secure environment for initial device configuration. 

The HRoT is typically a fixed-function, immutable element. Additional secure processing components, such as secure enclaves or hardware security modules, may support programmable functions built on top of the HRoT

Cryptographic Techniques used in Boot Process - Ensuring Authenticity, Integrity & Confidentiality

Cryptographic techniques provide essential mechanisms in the secure boot process in SoCs, to ensure that only trusted and authentic software is executed from the moment the device powers on. 

The table illustrates how cryptographic techniques such as digital signatures like RSA and ECDSA, and secure hash algorithms are fundamental to secure boot to ensure the authenticity and integrity of software components. These foundations are integrated into SoCs by verifying signatures against public keys stored in a Hardware Root of Trust, often accelerated by dedicated hardware for efficient boot performance.

Secure Boot Firmware: Orchestrating the Process

The entire process in an SoC is typically managed by dedicated secure boot firmware, responsible for orchestrating the verification of each stage of the boot process. The secure boot firmware itself should be stored in an immutable memory, such as ROM or a write-protected region of flash memory, to prevent it from being compromised. 

A typical secure boot sequence in a SoC might involve the following steps:

1. Boot ROM: The system starts execution from the immutable memory containing the initial secure boot code, trusted public key, and the root of trust . 
2. Load and authenticate first stage bootloader: secure boot code loads the first stage bootloader (FSBL) from internal or external memory. It verifies the signature of the bootloader using the trusted public key.
3. First stage bootloader executes: Once authenticated, the FSBL initializes basic hardware and loads the next stage, a second stage bootloader (SSBL) or OS loader.
4. Verify second stage bootloader / OS image: The FSBL validates the next component’s signature using the established chain of trust. Each stage verifies the next before transferring control.
5. Configure runtime protections: As boot progresses, memory protections like MMU or MPU, access control, and isolation mechanisms such as TrustZone are enabled.
6. Load and verify operating system / application: The final stage (OS kernel and/or main application) is loaded and verified before execution.
7. Transfer Control to verified OS / application: Execution is handed over only after full integrity checks are passed. Optionally, measured boot logs each hash for later attestation.

This multi-stage approach ensures that each critical component of the boot process is verified before it is executed, building a robust chain of trust from the hardware up to the operating system. The additional steps involved in cryptographic verification can introduce an overhead, increasing the time it takes for the system to boot. 

Techniques to minimize boot time overhead:

• Hardware acceleration: Dedicated hardware accelerators for cryptographic operations can significantly speed up the computationally intensive tasks of hashing and signature verification. 
• Efficient software implementations: Optimized boot sequences and software implementations can also help in minimizing any perceived delays.

Conclusion

In conclusion, secure boot is essential for ensuring the security and integrity of ASIC-based embedded systems. It establishes a chain of trust from power-on, preventing unauthorized code from executing and mitigating risks like malware and rootkits. Key elements like the chain of trust, hardware root of trust (HRoT), cryptography techniques, and secure firmware work together to create a strong security foundation. While secure boot may add some boot-time overhead, its security benefits far outweigh the impact, which can be minimized with hardware acceleration. As embedded systems become more interconnected, adopting secure boot is crucial for building trustworthy, resilient devices.