When you think of an embedded system (e.g., an industrial plant, an IoT device, or an automotive control system), it quickly becomes clear that the boot phase is one of the most critical phases of all. This is where the foundation is laid for whether your device starts up securely or offers a target for attack. This is precisely why the topic of secure boot is so relevant in the field of embedded systems today. Equally important—but often less well understood—is the concept of authenticated boot. In this article, I will show you how the two methods differ, when each method is appropriate, and how to implement them (including code examples).
The aim of this article is to provide you with a practical, understandable, and action-oriented overview so that you can decide whether secure boot, authenticated boot, or both are the right solution for your project.
Fundamentals & Understanding
To ensure we are all on the same page, let’s first take a look at the terms and mechanisms involved.
What is Secure Boot?
- Secure Boot ensures that only signed and trusted software is executed during the boot process.
- It starts with a Root of Trust (RoT) – e.g., stored public keys in One-Time-Programmable (OTP) eFuses or a Secure Element.
- This is followed by the initiation of a chain of trust: the bootloader verifies the kernel, and the kernel verifies the user software, if applicable.
- An example in embedded systems: an MCU bootloader reads flash, checks the signature with the published public key – if incorrect → boot stops or switches to secure mode.
What is authenticated boot?
With authenticated boot, the integrity status of the software is checked before it is executed. The system verifies the authenticity of the firmware (e.g., via a digital signature or hash check), but does not necessarily stop the startup process if something is wrong. Instead, it can:
- set an error code,
- store a security status in flash or EEPROM, or
- send a diagnostic message to the higher-level system (e.g., gateway or central ECU).
This keeps the system operational, but it is known that potentially compromised firmware is being executed.
Comparison and key terms
- Root of Trust (RoT): The unchangeable starting point (e.g., BootROM, eFuse) for establishing trust.
- Chain of Trust: Each stage verifies the next – e.g., BootROM → Bootloader → Kernel → Apps.
- Firmware Integrity: Ensuring that firmware is unchanged and authentic.
- Bootloader Security: The bootloader is critical software – it must start securely, verify, and encrypt if necessary.
Practical implementation
Now it’s getting specific: You want to implement Secure Boot or Authenticated Boot in an embedded project – how do you proceed?
1. Hardware Preparation
- Ensure that your SoC or microcontroller offers a BootROM or hardware root of trust. Example: An ARM Cortex-M with OTP eFuses, or an SoC with a secure boot function.
- Store the public keys or hashes of the trusted firmware in an unalterable location (e.g., eFuses, secure element).
- If necessary, activate debug interface shutdown and protection mechanisms (e.g., disable JTAG) to prevent additional attacks.
2. Secure Boot Process (Code Example)
Assuming: A simple BootROM loads a bootloader from flash, checks signature with RSA. (Pseudo-C)
// BootROM: Step 1 – public key already programmed
extern const uint8_t public_key[]; // in BootROM, OTP
int verify_signature(const uint8_t* image, size_t len, const uint8_t* sig);
// BootROM main function
void bootrom_main(void) {
uint8_t* bootloader = (uint8_t*) FLASH_BASE;
size_t bl_len = get_length(bootloader);
uint8_t* signature = (uint8_t*) (FLASH_BASE + bl_len);
if (verify_signature(bootloader, bl_len, signature) != 0) {
// Signature invalid – no boot
error_halt();
}
// Signature valid – jump to bootloader
jump_to(bootloader);
}
This code shows the core idea: The BootROM is part of the Root of Trust; it checks the bootloader before it is executed.
3. Authenticated boot process (code example)
bool verify_signature(uint8_t* firmware, size_t len, uint8_t* signature) {
return crypto_verify_signature(firmware, len, signature, PUBLIC_KEY);
}
void authenticated_boot() {
bool valid = verify_signature(firmware_image, firmware_len, firmware_sig);
if (!valid) {
log_dtc("Firmware authentication failed");
set_boot_status(AUTH_FAIL);
} else {
set_boot_status(AUTH_OK);
}
// Boot will continue regardless
start_firmware();
}
In practice, such a mechanism is often implemented in the ROM code of the microcontroller, e.g., in Infineon AURIX, NXP S32K, or Renesas RH850.
4. Combined scenarios & embedded use cases
- In the automotive industry, e.g., for ECUs: Secure Boot is used to ensure that only approved firmware is started.
- In IoT nodes, Authenticated Boot can be useful: The device sends measured values and regularly verifies its start status – if there is a deviation, an alarm is triggered instead of immediate blocking.
- Typical procedure for Secure Boot in embedded systems:
- BootROM (in SoC) checks bootloader signature.
- Bootloader checks kernel/firmware image.
- Firmware checks applications or loads via secure update mechanism.
- Updates are signed and protected against rollback.
5. Typical setup: Key management
- Generate key pairs (private at the manufacturer, public part in the device).
- Use asymmetric methods (e.g., RSA or ECC) for signing.
- Secure storage of private keys in the production process.
- Secure storage of the public key in the device (e.g., OTP eFuse, Secure Element).
- Maintenance of key rotation or revocation: If a private key is compromised, this must be taken into account in the field.
Common mistakes & risks
When implementing Secure Boot or Authenticated Boot, you will often encounter the following pitfalls – here in bullet points:
- Keys can be stored in flash memory: If a public key or, even worse, the private key is stored in external flash memory, an attacker can manipulate it.
- No hardware root of trust available: If your BootROM is not truly immutable, the entire chain of trust is broken.
- Anti-rollback protection error: Firmware can be reset or an old version loaded if no protection is in place.
- Missing debug lock: Leaving JTAG or other debug interfaces open helps attackers interfere with the boot process.
- Confusion between authenticated and secure boot: If you think, “I have authenticated boot, so I’m secure” – but in reality, it does not prevent unauthorized firmware from running. E.g. > “While secure boot prevents the boot of non-trusted software, authenticated boot detects non-trusted software but does not prevent its boot.”
- Performance/resource issues: In embedded systems with limited memory or slow CPUs, complex signature checks can delay startup.
How can you avoid them?
- Ensure you have a solid hardware basis with an unalterable BootROM or secure element.
- Implement clear processes for key management, approval processes, and firmware updates.
- Test scenarios with error modes (“invalid signature,” “old firmware”) and ensure that the system responds appropriately (e.g., boot stops or shuts down safely).
- Clearly document whether your system blocks Secure Boot or only measures Authenticated Boot—and communicate this to stakeholders.
Best practices & recommendations for action
Here are my specific recommendations for your embedded projects:
Start early with boat security design
Decide during the architecture phase whether secure boot or authenticated boot is required. Hardware constraints, costs, and target platform influence the choice.
Use a genuine Root of Trust component
A BootROM or Secure Element that cannot be altered forms the foundation of security. Without RoT, the chain of trust breaks down.
Implement a clean chain of trust
BootROM → Bootloader → Firmware → Applications. Each stage checks the next. Pay attention to clear transitions and signatures.
Secure keys and signatures correctly
Private keys must never be in the field. Public keys must be immutable in the device. Anti-rollback, key rotation, and secure storage are mandatory.
Choose the right method: Blocking vs. measuring
If you want maximum security (e.g., automotive, medical technology): Secure Boot (blocking).
If flexibility and monitoring are more important (e.g., IoT with remote monitoring): Authenticated Boot (measuring) may be sufficient.
Implement secure update mechanisms
Sign updates, check versions, prevent downgrades. Self-update should be part of boot security.
Test error scenarios and attacks
Simulate compromised firmware, manipulated signature, open debug interface. Check how your system reacts.
Document and communicate your boat security strategy
Stakeholders (e.g., suppliers, regulatory authorities) should understand whether Secure Boot or Authenticated Boot is used, what the measures are, and what security measures apply.
Conclusion
As you can see, the boot phase in embedded systems is by no means trivial – it is a key attack vector and should therefore be handled in a conscious and structured manner. Secure Boot provides a strong barrier against untrustworthy software, while Authenticated Boot offers a more flexible solution with measurement and monitoring capabilities.
But for real security, you need more: root of trust, chain of trust, key management, updates – all of these belong together. If you consider these issues early in the design phase, you can avoid major problems later on.
And what’s next? In the future, the topic of “boot security” will continue to evolve: Multi-core and heterogeneous SoCs pose new challenges (e.g., formal verification of boot primitives). Remote attestation and secure supply chains are also gaining importance, especially in the context of Industry 4.0 and networked embedded devices. So if you implement a solid boot security strategy today, you will be well positioned to meet future requirements.
