The instrument cluster attack: how a dashboard lies

A dashboard that shows whatever it is told

The instrument cluster attack is worth studying because it is unspectacular in method and unsettling in implication. There is no exploit chain, no firmware bypass, no physical tampering. An attacker with access to the vehicle's CAN bus injects well-formed messages carrying false values, and the cluster faithfully displays them: a state of charge that is wrong, a speed that is wrong, a warning that never lights. Nothing on the vehicle objects, because from the vehicle's point of view nothing is wrong.

It is a small demonstration that teaches a large lesson about why UN R155 exists. The cluster is doing exactly what it was designed to do — render the values it receives — and that is the problem. When the network carrying those values cannot say who sent them, honest display of dishonest data is the inevitable result.

Why the CAN bus allows it

The CAN protocol has no built-in authentication. Every node on the bus can transmit, every node can read, and a frame carries no proof of who originated it. This was a reasonable engineering choice for a closed, trusted in-vehicle network in an earlier era; it is a liability now that vehicles are connected and diagnostic ports are reachable. The instrument cluster attack is one instance of the broader family of CAN bus attacks — injection, spoofing and fuzzing — that all trace to the same root: no authentication on the wire.

The mechanics are simple enough to describe in a table.

Step	What the attacker does	Why it works
Identify	Find the CAN IDs the cluster reads for speed, SoC, warnings	Bus traffic can be observed and mapped
Craft	Build frames with those IDs carrying false values	Frame format is public; values are plausible
Inject	Transmit the crafted frames onto the bus	Any node may transmit; no sender check
Display	Cluster renders the false values	Cluster trusts whatever it receives
Silence	Diagnostics report nothing	Frames are well-formed and in range

The last row is the important one. The reason no fault is raised is not an oversight in the diagnostic logic — it is that the diagnostic logic is looking for the wrong thing. It watches for malformed frames, missing signals and out-of-range values. A crafted frame is none of those. It is a correct message with a false payload, and there is no field in it that betrays the lie.

The lesson: authentication and monitoring must be designed in

The attack cannot be patched away at the cluster. The cluster is not broken. What is missing sits at the network and architecture level, and it has to be designed in rather than bolted on:

• Message authentication. Mechanisms such as CAN message authentication codes let a receiver verify that a frame came from a legitimate sender and was not altered. This is the direct answer to injection, though it carries bus-load and key-management cost that has to be planned.
• Segmentation and gateways. A gateway that separates the diagnostic and external-facing domains from the critical vehicle bus limits where an attacker can inject at all, shrinking the reachable surface.
• Monitoring. Detecting anomalous traffic — duplicated IDs, implausible transmission patterns, frames from the wrong domain — gives the vehicle and the fleet a way to notice what static fault detection cannot. This is the vehicle-SOC side of the problem, and it is why UN R155 expects monitoring to continue after approval.

None of these is free, and the right combination depends on the vehicle's architecture and its risk picture. That determination is the job of the TARA, and confirming that the chosen mitigation actually holds is the job of a vehicle penetration test run against a representative bench.

Where it sits in UN R155

This attack maps directly onto the UN R155 Annex 5 threat catalogue, under the communication-channels category — spoofing of messages and injection onto the in-vehicle network. That mapping is what makes the demonstration useful in a compliance context rather than merely alarming. A programme cannot claim the threat is mitigated on paper and leave it there; Annex 5 pairs threats with mitigations, and the assessor will want evidence that the mitigation was implemented and verified.

A bench demonstration provides exactly that evidence, in both directions. If crafted frames still change the cluster, the mitigation does not hold and the finding is concrete and reproducible. If message authentication rejects the crafted frames, the demonstration is the proof that the control works. Either way, the worked example turns an abstract Annex 5 line into something an assessor can see.

Why the small demonstration matters

Programmes sometimes treat the cluster attack as a party trick — visually striking, low real-world consequence, since a false speed reading is not by itself catastrophic. That misreads it. The point is not the specific lie on the dashboard; it is that the same unauthenticated bus carries messages that do matter, and the same technique reaches them. A dashboard that can be made to lie is a proof that the network trusts its inputs, and a network that trusts its inputs is one an attacker can steer. The cluster is simply the most legible place to show it.

The AutoSifu view

We use worked demonstrations like this to tie an Annex 5 threat to a verified control, so a claimed mitigation becomes evidence rather than an assertion. On a single route with CIRT — compliance, solutioning and CoC/VTA support — the demonstration and its remediation are closed with the approval body in the room, which is where an unauthenticated bus stops being a talking point and becomes a closed finding.