Life after the line: what a vehicle's root of trust has to survive

Most root-of-trust decisions in a vehicle are made once, on the production line, in the few seconds it takes to provision a key. Then the vehicle leaves the factory, and that decision has to hold for the next twenty years, in an environment its maker no longer controls. A laptop is replaced in four years and a server in five. A car is still on the road, and still connected, long after the engineers who chose its root of trust have moved on.

In The Automotive 20-Year Vulnerability Window we looked at one threat across that life: a quantum computer that can recover a key stored in a vehicle security module long before the vehicle is retired. This post is about everything else that happens to the vehicle in those twenty years, and why a stored key is the wrong foundation for that too.

Twenty years is a long time for a secret

A conventional root of trust is a secret: a key injected at the factory and kept in protected storage. Everything the vehicle proves about itself, for its whole life, depends on that secret staying secret. Look at what it has to survive.

• An attacker who can own the target. Anyone can buy the same ECU from a salvage yard and keep it on a bench for months. Side-channel and fault-injection attacks that are impractical against a server in a locked data center are a weekend project against a part you own. Where a key or key-derivation secret is shared across a model line, one extraction becomes a fleet-wide problem.
• The provisioning trail. Somewhere, a supplier or factory system generated or recorded those keys. That trail has to stay protected for the life of every vehicle it touched, through supplier changes, mergers and exits.
• Cryptography that ages. NIST published its first finalized post-quantum standards in 2024, and the vehicle will still be driving when the quantum threat matures. As The Automotive 20-Year Vulnerability Window explains, a new algorithm protects the math, not the key still sitting in memory.
• Parts that change. ECUs are replaced, refurbished and sometimes counterfeited. A copied key in a cloned module looks exactly like the genuine part to anything that only checks the key.
• Software that changes. Over-the-air updates arrive many times over the vehicle's life, and each one has to land on the right, genuine hardware.
• Owners that change. Credentials issued to one owner, fleet or service provider have to be revoked and reissued without touching the root.

Regulation now expects all of this to be managed for the whole life of the vehicle. UN R155 requires a cybersecurity management system that covers the vehicle lifecycle, UN R156 requires a managed process for software updates, and ISO/SAE 21434 carries cybersecurity engineering from concept through operation to decommissioning.

A vehicle's root of trust is chosen in seconds on the line and has to hold for twenty years in the hands of strangers. It should not depend on a secret staying secret for that long.

What a long-life root of trust has to do

Change the foundation and most of that list changes with it. When the identity is derived from a physical property of the silicon itself, there is no stored key at the root of the vehicle.

• Nothing to steal, even with years of bench time. The identity is never stored, so there is nothing to read out or copy, nothing for a quantum computer to solve, and it fails closed under physical attack. Owning the part does not mean owning its identity.
• No secret to guard after the factory. Enrollment does not create a secret that someone has to protect for twenty years. A breach of a supplier system in year nine does not quietly undo every vehicle built in year one.
• Owners and services change; the silicon does not. Access issued to an owner, a fleet or a service provider can be revoked and reissued at every handover. The identity underneath never has to be re-provisioned, because it was never provisioned in the first place.
• Genuine parts, proven. Every module proves it is the genuine part, wherever it was installed. A clone cannot reproduce the silicon, so a counterfeit and a genuine ECU stop looking the same.
• Updates bound to the right hardware. With policy-gated execution, update keys, software and models are released only to a module that proves it is the approved one.
• Evidence that lasts. A signed, tamper-evident record of what ran on which module stays checkable years later, for an incident review, a recall or a dispute.

The models will change more often than the car

The software-defined vehicle is also an inference platform. Central compute with dedicated NPUs runs perception and driver-assistance models, and those models will be retrained and replaced many times over the life of one vehicle. Each update raises the same two questions: is this model going to the genuine compute module it was approved for, and, after an incident, which model version was actually running on which hardware at that moment?

A stored key answers neither question well once it has been on the road for a decade. A root in the silicon of the compute module answers both. Model weights are released only to hardware that proves itself, and every inference run can be tied to the module that ran it and the model it ran. For the Identity Core, that root is built into the compute silicon itself, so it ships in the vehicle from the first wafer.

What it does not replace

A silicon-intrinsic root of trust does not replace secure boot, automotive security modules, a secure software supply chain or the engineering discipline of ISO/SAE 21434. It does not fix a vulnerable ECU application. It gives all of those a foundation that does not depend on a stored secret, and that stays trustworthy for as long as the vehicle is on the road.

The question to ask

For every ECU and compute module you ship this year, ask one question: what has to stay secret, and for how long? If the answer is "a key, for the life of the vehicle", that is the exposure. A root of trust that comes from the silicon removes it.

For the quantum side of the same argument, read The Automotive 20-Year Vulnerability Window.

Sources

• UN Regulation No. 155: Cyber security and cyber security management system, UNECE
• UN Regulation No. 156: Software update and software update management system, UNECE
• ISO/SAE 21434:2021, Road vehicles: Cybersecurity engineering, ISO
• Announcing approval of three Federal Information Processing Standards for post-quantum cryptography, NIST, August 2024