Secure Boot: ECU Firmware Integrity & ISO/SAE 21434 Cybersecurity

Introduction

With the rapid integration of software-driven features (Over-The-Air updates, Infotainment, Autonomous driving functions, etc.) into modern vehicles, the attack surface for cyber security threats has expanded significantly. Cyber-attacks can target a vehicle’s software at many points, and one of the most critical areas is the ECU’s startup phase.

Secure Boot is a security concept designed to validate the integrity and authenticity of the software running on the control unit. The primary objective of Secure Boot is to perform the cryptographic verification of every software component before execution on the ECU, ensuring that the software has not been tampered with by an attacker.

Secure Boot Procedure

Secure Boot establishes a Chain of Trust by sequentially verifying the integrity and authenticity of each software layer prior to execution. To achieve this, the boot sequence is anchored in an isolated Hardware Root of Trust, typically a Hardware Security Module (HSM) or a comparable secure hardware element. Cryptographic keys used for verification are stored and used exclusively inside this hardware boundary, and they are never exposed to the rest of the system, which makes it very difficult for an attacker to extract or misuse them.

A typical Secure Boot procedure is as follows:

‍

Secure Boot validates the firmware during the start-up phase. To safeguard applications during run-time, additional controls can be implemented, such as program flow monitoring, partial runtime integrity checks that reapply the same hash-based or MAC-based principles used in Secure Boot.

Software Authentication

To validate the integrity and authenticity of the software running on the ECU, the following cryptographic methods can be used.

1. MAC-Based Validation: Uses a symmetric key algorithm (AES-CMAC), where the same secret key is used to both generate and verify the MAC value. This secret key must be shared with the ECU to verify the software image and is stored securely inside the HSM. At every boot process, the HSM recomputes the MAC value over the desired input message and compares it against the reference MAC value.
This input message can originate from a cryptographic hash algorithm (e.g., SHA-256). At every boot process, a hash of the current software image is computed, fed into MAC calculation and the output is compared against a stored reference value, to detect any software tampering. This reference must be stored at a memory location that an attacker cannot modify, e.g. the HSM.

2. Signature-Based Validation: Uses a public/private key pair. The signature is generated once, at the time the OEM signs the software by computing a hash of the software image, signing it with the private key, and appending it to the software image. In practice, this check is performed once, during the software update, as verifying a signature requires more computation time. For every subsequent boot, the ECU recomputes the hash or MAC value over the current software image and compares it against the reference value stored in the HSM, which is faster than verifying the signature. The private key is the only element that must be kept secret, ideally in the OEM’s Key Management System (KMS). This per-boot check does not replace the signature as the trust anchor, it only reconfirms that the software still matches what the OEM originally signed. Unlike the shared secret key in MAC-based validation, the private key never has to be present on the ECU at all, which is what continues to set signature-based validation apart.

Secure Boot Implementation Concerns

There are several concerns that must be addressed during Secure Boot implementation.

1. Rollback Protection: Secure Boot shall prevent older, potentially less secure software versions from being executed on the ECU. This can be achieved by using monotonic counters and freshness values, stored in protected memory as well as in the software image, which can only increase. However, there is an exception: a rollback is feasible in the special case where older software is re-compiled and re-signed, and the counter is increased correctly. As signing requires the private key, the most important secret in the system, whoever performs it must already possess that key, so the rollback is assumed to be intentional rather than malicious.

2. Key Management System (KMS): The KMS itself must be secured against cyber-attacks. A weak implementation, for example, poor key generation, reusing the same key across ECUs in a vehicle network, or insufficient access control, can expose the secret or private keys that Secure Boot depends on and also impacts the security of every ECU that relies on them. It is also important to be aware of, or be able to read, the key version stored on the unit. If this is unknown, the software may end up being signed with the wrong key version, leading to failed signature verification due to a key mismatch and leaving the ECU stuck on its current software or even more fatal in a soft-bricked state.

3. Debug Protection: OEMs shall ensure that JTAG and other debug interfaces are locked in production units, to prevent sensitive information from being extracted using debugger tools.

4. Boot-Up Time: OEMs shall ensure that the Secure Boot process is completed within an acceptable time window. If it takes too long, it can trigger unexpected behavior, for example a watchdog reset if the watchdog is not serviced in time.

Conclusion

Secure Boot is not an optional security enhancement. UN Regulation No. 155 requires a cybersecurity management system for vehicle type approval, and ISO/SAE 21434 sets the cybersecurity engineering process behind it, which makes boot-time integrity verification a practical necessity for any modern vehicle that depends on software-defined functionality. By verifying the integrity and authenticity of all software before it executes on the system, Secure Boot prevents compromised or malicious software from being executed on the ECU, closing off one of the most fundamental attack vectors in automotive cybersecurity.

However, Secure Boot is only as strong as its supporting implementation. Implemented correctly, alongside the concerns outlined above, Secure Boot forms a foundational layer that helps prevent cyber-attacks and protects the safety of everyone who depends on it.

‍

‍