Software Updates Over CAN as an Attack Vector

Why Software Updates Are a Threat Surface

Frame-level attacks succeed for the duration of a bus session. Update-channel attacks succeed for the lifetime of the device. Once an attacker can flash arbitrary code into a node, every system parameter and even every cryptographic key on that node is in their hands, every defensive shell on that node can be silenced, and every later "secure" frame the node emits is signed by them. From the rest of the bus's perspective, the compromised node is still legitimate. Update tampering also persists across power cycles, factory resets that the malicious firmware mishandles, and most diagnostic procedures, until someone reflashes the device through a trusted channel, which presupposes the trusted channel still exists.

Standardized Bootloading Without Standardized Security

CANopen (CiA 710) defines firmware-download protocols at the application layer. An Object for security is reserved, but its implementation is not defined. The intent is interoperability: a CANopen download tool from one vendor can update a CANopen device from another. That is the right design goal for a fieldbus standard. It is also the wrong design goal to answer security with: the published profiles do not by themselves require authentication, encryption, or version-rollback protection. Authentication and confidentiality are layered on top of the standard exchange by the manufacturer, or they are not present at all.

The Plain-HEX Shipping Pattern

The most common pattern in industrial CAN for a long time was this: the manufacturer publishes a firmware update as a plain Intel-HEX file, distributed over a website or email, alongside a generic CAN download tool. The device's bootloader speaks the standard download protocol and writes whatever image it receives. There is no signature on the HEX file, no encryption in flight, no version-monotonicity check at the bootloader, and no audit trail of who attempted to flash what. Anyone with bus access can flash arbitrary code: a service engineer, a supply-chain insider, a post-deployment add-on device, or an attacker who phished the support team's distribution channel.

Concrete Attack Patterns

• Arbitrary code execution. Replace the firmware with an attacker-controlled image. The device subsequently runs attacker code with full hardware authority. Extracts keys; exfiltrates data; pivots into the rest of the bus.
• Rollback to a vulnerable image. Flash an older signed-but-vulnerable firmware to bypass a fix the manufacturer already shipped. Particularly relevant when only signing is done and version monotonicity is not enforced.
• Replay of a captured legitimate update. Capture a legitimate update exchange on the bus, then replay it later out of context, for example after the manufacturer has shipped a patch. If freshness is not bound into the update transaction the device cannot tell.
• Partial-image corruption. Interrupt or fuzz the download to brick the unit or leave it in a half-flashed state with corrupt cryptographic key storage. A denial-of-service variant where the unit is field-unreachable until physical recovery.
• Update-channel as exfiltration. The update protocol's read-back primitives can be turned into an arbitrary memory read against an unhardened bootloader, lifting keys or device-secret data without ever flashing.

Where Remote Entry Becomes an Update-Distribution Surface

Many Remote Attacks do not require physical bus access. The remote-service gateways, diagnostic ports, and wireless maintenance links are usually how legitimate updates are pushed in the first place. That makes the same paths an attractive route for malicious updates: a compromised cloud back-end, a stolen service-tool credential, or a man-in-the-middle on a maintenance channel can drive the update protocol exactly as the manufacturer would. The threat moves from "attacker has soldered onto the wires" to "attacker has the same access the service team has".

Mitigations

CVSS Scoring for Update-Channel Attacks

The CVSS baseline depends on whether the update path is locally bus-attached or remotely reachable. For a directly bus-attached update channel against an unprotected bootloader, the attack vector is AV:P as elsewhere on classical CAN, but the integrity and availability impacts are higher than the per-frame baseline because firmware tampering is irreversible from the bus side: the device runs attacker code afterwards. For an update path exposed via a remote-service gateway or maintenance back-end, the attack vector is AV:N and the confidentiality impact follows whatever the firmware itself can access.
See CVSS for CAN for how mitigations adjust the score.

Frequently Asked Questions

Why is the firmware update channel a threat surface separate from frame injection?

Frame injection lets an attacker imitate one node for the duration of the bus session. Compromising the firmware update channel lets the attacker replace the code that runs on the target permanently, including any cryptographic keys it holds. The blast radius and persistence are categorically different, even though the underlying bus access can be the same. The mitigation is also different: see Secure Bootloader.

Is the CANopen firmware-download protocol inherently insecure?

The exisitng CiA 710 standardized download protocol solves interoperability, not security. Authentication, encryption, and rollback protection are layered on top by the manufacturer. A device that implements the download exchange but ships unsigned plain-HEX firmware satisfies the protocol while leaving the security properties at zero.

Does shipping plain Intel-HEX firmware fail the EU CRA?

CRA Article 13(2)(c) requires that vulnerabilities can be addressed through security updates and that those updates can be applied safely. A plain-HEX update channel that any party with bus access can drive cannot be applied safely in the regulatory sense, and the same channel becomes the manufacturer's vulnerability-introduction surface. Most CRA conformity assessments will flag this.