Secure Boot Implementation for Automotive ECUs: Chain of Trust from ROM to Application

Secure Boot is the load-bearing control behind the cybersecurity of every modern ECU. If the chain of trust holds from power-on, an attacker who replaces firmware fails to boot the vehicle; if the chain breaks anywhere — root key, signature algorithm, rollback policy, debug port — the ECU runs the attacker's code and every other control downstream becomes irrelevant. This post is the implementation view: how the chain is built, how the keys are managed, where the attacks land, and how the resulting work products map into ISO/SAE 21434 Clause 10 and UNECE R155 Annex 5.

Why Secure Boot matters more in vehicles than in IT

IT systems get patched. Vehicles get serviced. The same firmware runs in tens of thousands of identical ECUs, each of them physically reachable by a sufficiently determined attacker, each of them in service for fifteen to twenty years. Three properties of the automotive context shape the Secure Boot design that an enterprise design does not have to plan for:

• Physical access is realistic. Removing the ECU and probing it on a bench is a routine attack. The threat model cannot exclude the OBD-II port, the diagnostic connector, or the unsoldered chip.
• Long lifetimes. Cryptographic decisions made in 2026 must hold against attackers in 2041. Algorithm agility and post-quantum readiness are procurement requirements, not research curiosities.
• Supply chain. Firmware crosses ownership boundaries between OEM, Tier-1 supplier, silicon vendor, and contract manufacturer. Each handoff is a place the chain could be subverted; Secure Boot is the runtime check that the firmware loaded is the firmware that was signed.

Chain of trust fundamentals

A Secure Boot chain has four typical stages: an immutable ROM, a first-stage bootloader, a second-stage bootloader, and the application image. Each stage verifies the signature of the next stage against a public key it inherited from the stage above. The root of the chain is a public key fused into one-time-programmable storage at silicon manufacture and read by ROM at every power-on.

Key management and hierarchy

The signing key hierarchy mirrors the chain of trust but lives in the OEM's key-management infrastructure rather than on the vehicle. A typical hierarchy: a hardware-fused root public key in the ECU; an offline OEM root signing key whose public part the fused key represents; intermediate signing keys for firmware classes (bootloader, application, calibration); per-ECU diversified keys for any per-unit cryptographic state. The root's private key never leaves an offline HSM; signing ceremonies are scheduled events with dual control. The intermediate keys do the day-to-day signing and rotate on a defined schedule. The fused public key in the ECU is the only thing that cannot be rotated in the field — choose it deliberately and back it with PQC where the hardware allows.

Signature schemes for automotive Secure Boot

Implementation patterns

Fixed root of trust (ROM and fuses)

The dominant pattern. The ROM is mask-programmed at silicon manufacture; the root public key is fused (or, more commonly, the SHA-256 hash of the root public key is fused, with the key itself supplied as part of the FSBL package). At power-on, ROM reads the fuses, hashes the supplied key, compares, then verifies the FSBL signature with the supplied key. Tamper-evidence comes from the fuses; immutability comes from the mask ROM.

Measured Boot (TPM-style measurement log)

In addition to verifying each stage, the boot code records a hash of each loaded image into a measurement log held by the HSM or a TPM. A remote verifier can later request the log and decide whether the chain of measurements matches an expected reference. Measured Boot is complementary to Verified Boot, not a substitute: Verified Boot blocks bad images; Measured Boot records what was loaded.

Secure debug (auth-gated JTAG/SWD)

Production debug ports are either fused-off or gated by an authenticated challenge-response. The challenge comes from the silicon, the response is signed with a key the OEM controls, and only valid responses unlock the debug interface. This pattern preserves the ability to do field diagnostics while removing the alternative path that would bypass Secure Boot entirely.

AUTOSAR Classic integration

On AUTOSAR Classic, two work items integrate with the platform: the Flash Bootloader (FBL), which is responsible for receiving update images and managing flash, and the Secure Boot Manager (SBM), which performs the verifications along the chain. Vendor BSW packages typically supply both, keyed to the silicon's HSM. The SBM enforces the minimum-version check against the rollback counter and invokes the HSM through the AUTOSAR Crypto Stack — Csm, CryIf, Crypto Driver — for the signature verification itself.

AUTOSAR Adaptive integration

On AUTOSAR Adaptive (POSIX-class compute), the responsibilities shift. Platform Health Management (PHM) handles startup configuration verification; the platform's own boot firmware (often a UEFI-derived chain or a vendor secure boot) anchors the trust before Adaptive itself starts. Application-level integrity continues to flow through the KeyM/Csm equivalents. The principle is the same: every stage verifies the next; the chain has no field-replaceable root. For the Classic-versus-Adaptive split see our companion piece on AUTOSAR Classic vs Adaptive.

Signature verification flow

The diagram below shows the verification a Secure Boot Manager performs at every stage transition. The same flow runs on power-on (FSBL → SSBL → application) and on OTA install (incoming image → application).

Attack vectors and mitigations

Public research on Secure Boot attacks converges on six classes. Each has a corresponding mitigation that mature designs implement; missing any of them tends to predict the fastest path to compromise.

• Voltage and clock glitching: the attacker injects a transient at the moment the verification routine is checking the result. Mitigation: hardware countermeasures in the HSM (voltage monitors, clock-integrity checks), redundant verification with diverging code paths, and a fail-secure design that treats anomalies as failure.
• Fault injection (laser, EM): precision attacks on specific instructions. Mitigation: constant-time cryptographic primitives, redundant hash and signature verification, sensors in the HSM package.
• ROM bugs: defects in mask-programmed code cannot be patched. Mitigation: rigorous review and Penetration Testing of ROM before tape-out, recovery firmware that can compensate for narrow ROM defects via FSBL-side checks.
• Rollback: the attacker re-flashes a previously signed but later-vulnerable image. Mitigation: monotonic counter in fused storage, minimum-version check enforced by SBM not just by manifest.
• Pre-Secure-Boot UART/JTAG: debug interfaces active before the chain locks down. Mitigation: fuse-disabled or auth-gated debug, with the gate active before any external interface is enabled.
• Supply-chain firmware substitution: a bad image is signed before it reaches the OEM. Mitigation: disciplined PKI ceremony, air-gapped signing, dual control, and SBOM verification at the OEM ingress.

Rollback protection in detail

Rollback protection is the control most often partially implemented. Two artefacts must be present: a monotonic counter held in fused or anti-rollback hardware storage that cannot be decremented, and a minimum-version field in every signed manifest. The Secure Boot Manager reads the stored counter, compares against the manifest's version, rejects the image if it is below the stored minimum, and after successful boot updates the counter to max(stored, manifest.version). The check belongs in the SBM. Designs that rely solely on the manifest declaring a minimum version are bypassed by the attacker re-using an older legitimately signed manifest.

Secure Boot at scale

Three operational concerns dominate when Secure Boot moves from prototype to fleet:

• Factory provisioning. Per-ECU diversification at end-of-line is non-negotiable; a single shared key across a part number is a single-point compromise. The provisioning flow itself must be authenticated against the tester, logged, and reproducible for audit.
• Recovery key escrow. An OEM that cannot recover from a lost intermediate key has either lost the fleet or accepted permanent vulnerability; both are unacceptable. Escrow under dual-control and offline HSM custody is the standard answer.
• OTA compatibility. The OTA pipeline must produce images that traverse the same chain as factory- flashed firmware. A separate signing key for OTA is a red flag; it usually indicates the chain has not been reasoned through from boot ROM to OTA package.

ISO/SAE 21434 and UNECE R155 mapping

The Secure Boot architecture document, the key-management specification, the verification report, and the threat-vs- mitigation table together produce the Clause 10 evidence ISO/SAE 21434 expects (WP-10-01 cybersecurity controls specification, WP-10-04 cybersecurity verification report). Against UNECE R155, the same artefacts directly address Annex 5 firmware-modification threats. The HSM that performs the verifications is documented separately (see our companion post on HSM integration for automotive ECUs); the Secure Boot work products reference it. For the broader R155 view see ISO/SAE 21434 vs UNECE R155; for the work-product map see the ISO/SAE 21434 Work Products checklist.

Take-aways

Secure Boot is not a feature; it is the foundation every other ECU cybersecurity control rests on. The architectural decisions that matter — root key choice, signature scheme, rollback policy, debug gating, post-quantum readiness — are made before silicon is locked. Programmes that treat Secure Boot as an integration task discover late that the silicon cannot meet the verification latency, the key-management infrastructure was not procured, and the rollback counter has nowhere to live. Programmes that treat it as an architecture decision pay the cost once and move on.

Agnile Technologies designs and verifies Secure Boot implementations across the major automotive silicon families, from chain-of-trust architecture through key- management infrastructure and Penetration Testing of the resulting design. Work products map directly to ISO/SAE 21434 Clause 10 and UNECE R155 Annex 5.