Secure Boot

What is secure boot?

Secure boot is a chain of verification that runs when an ECU powers up. The root of trust verifies the first bootloader stage, that stage verifies the next, and so on up to the application, each step checking a cryptographic signature or hash before handing over control. If a stage fails verification, the ECU refuses to run it and either halts, stays in the bootloader or enters a restricted recovery state. The result is that only software the manufacturer signed starts normally.

The cryptography usually runs in an HSM or a protected ROM, so the public keys or hashes used for verification are held where application software cannot change them.

Where is it defined?

There is no single secure boot standard; it is a design pattern realised with the microcontroller vendor’s security hardware, AUTOSAR crypto services and project-specific key management. ISO/SAE 21434 treats boot integrity as part of the security concept and architecture of an item. UN R156 requires that software version identification and update integrity be protected, which in practice relies on a verified boot and image check on the ECU.

What it means in practice

Secure boot is the base of the trust chain. SecOC keys, secure diagnostic credentials and any claim that the running software is the approved version all assume that the code which uses them is itself genuine. If secure boot is missing or can be skipped, an attacker who writes modified firmware can defeat the controls above it, because those controls run inside the software they are supposed to protect.

From outside the ECU, secure boot is hard to observe directly. What a tester can look at is adjacent: whether the diagnostic download path enforces session and SecurityAccess before writing an image, whether an interrupted or malformed download leaves the ECU recoverable, and which version identifiers the ECU reports. Confirming that the boot chain actually rejects a modified image is firmware reverse engineering and penetration-test work.

How AutoST tests it

AutoST tests the diagnostic and bus-facing path around secure boot, not the boot verification itself. It checks whether RequestDownload (0x34) and the transfer services require the correct session and SecurityAccess, probes robustness under malformed or oversized TransferData, and reads version and identification data identifiers. It does not verify signatures, extract keys or attack the boot ROM; that is reverse engineering and penetration-test work.

Common misunderstandings

Secure boot does not prevent writing firmware; it governs whether that firmware runs. A single stage that skips verification breaks the whole chain. And secure boot protects startup integrity, not confidentiality or runtime memory safety, which need their own measures.