Building a Chain of Trust on an Automotive ECU

A chain of trust is only a chain if every link is verified by the one before it. On an automotive ECU that means an immutable root, a verified bootloader, a verified application and a runtime that can prove the identity of the messages it acts on.

Secure boot within a startup budget

The constraint that catches teams out is not cryptography, it is time. A body controller may have tens of milliseconds before it must respond on the bus. Verifying a large application image serially against that budget is not viable, so verification is usually staged: verify the minimum needed to reach a safe state, then continue verification in the background before enabling privileged functions.

Key hierarchies that survive production

• Separate keys by purpose — boot verification, secure communication, diagnostics and debug should never share material
• Plan provisioning at end of line before you plan the cryptography; a hierarchy that cannot be injected safely is not a hierarchy
• Design rotation and revocation up front, because retrofitting them across a deployed fleet is close to impossible

SecOC and the freshness problem

Secure Onboard Communication adds authentication and freshness to bus messages. Authentication is straightforward; freshness management across ECUs that boot at different times, and across a bus that may lose synchronisation, is the part that requires design attention. Decide early how a receiver behaves when freshness cannot be verified — and make sure that behaviour is safe rather than merely convenient.