From CAN to Automotive Ethernet: A Security-Focused Survey of In-Vehicle Network Protocols and Threats

From CAN to Automotive Ethernet: A Security-Focused Survey of In-Vehicle Network Protocols and Threats

Modern vehicles are no longer mechanical products with a few electronic control units (ECUs) bolted on. A mid-range 2024 passenger car carries 70–150 ECUs, several kilometers of wiring, and a growing number of external interfaces — telematics units, Wi-Fi hotspots, Bluetooth hands-free stacks, OTA update channels, and increasingly, lidar and camera pipelines that push gigabytes per second across the chassis. The network that glues these systems together has therefore become a security boundary, not just a wiring convenience. This survey maps the in-vehicle protocol landscape from CAN and LIN through FlexRay, MOST, and Automotive Ethernet, then examines the reliability and timeliness limits of Ethernet's best-effort model and the concrete threats and countermeasures facing connected vehicles today.

Why the Bus Matters: The Security Model Starts at the Physical Layer

Classic CAN was designed in the 1980s for deterministic, low-cost, fault-tolerant control messaging. It has no authentication, no encryption, no source-address verification beyond the 11-bit or 29-bit identifier, and no concept of a session. Any node that can reach the bus can transmit a frame claiming to be any ECU. This is not a bug in a particular implementation; it is the design contract. Every security discussion about in-vehicle networks must start from that fact.

The practical consequence is that the attack surface is layered. A remote compromise of the infotainment head unit or telematics box (TCU) is valuable to an attacker primarily because those units sit on, or bridge to, the CAN bus. Once a frame can be injected, the attacker inherits the trust model of every ECU on that segment. The 2015 Jeep Cherokee research by Miller and Valasek, and the 2022–2023 wave of keyless-relay and CAN-injection thefts in North America and Europe, are the same story told at different points in the kill chain: get code or a physical connection near the bus, then speak CAN.

Protocol Landscape: Capability, Cost, and Security Posture

LIN: The Cheap Subnet

Local Interconnect Network is a single-wire, master–slave bus running at up to 20 kbit/s, used for body functions — window lifts, mirror adjustment, seat position, rain sensors. It is deliberately minimal: one master schedules all frames, no arbitration, no collision handling. From a security standpoint LIN is almost always a leaf network attached to a CAN gateway, and its threat value is indirect. The realistic risk is a compromised LIN slave (for example, a door module) being used as a foothold, or LIN traffic being used to fingerprint vehicle state. There is no meaningful cryptographic protection on LIN and none is practical at that cost point; the correct control is gateway filtering and physical access control.

CAN and CAN FD: Still the Backbone of Control

Classic CAN delivers up to 1 Mbit/s with 8-byte payloads and priority-based arbitration that gives deterministic worst-case latency for high-priority frames. CAN FD raises the data phase to 2–8 Mbit/s with up to 64-byte payloads, which matters for flashing and for larger sensor messages, but it does not add security. The relevant properties for a security review are:

• Broadcast by default. Every frame is visible to every node on the segment; there is no confidentiality.
• Identifier-based routing. Arbitration IDs act as message names, so spoofing a high-priority ID (e.g., a brake or steering-related frame) is trivial once bus access exists.
• No freshness or replay protection. A captured frame can be replayed indefinitely unless the application layer implements counters or MACs.
• Bus-off as a denial-of-service primitive. An attacker transmitting dominant bits can force error counters up and take legitimate nodes offline.

Countermeasures that actually ship today are mostly gateway-centric: deep packet inspection and rate limiting at the central gateway, IDS rules that flag unexpected IDs, frequency anomalies, or payload entropy, and secure boot plus HSM-backed key storage on the ECUs that can afford it. SecOC (Secure Onboard Communication, standardized in AUTOSAR) adds a truncated MAC and freshness counter to CAN frames, but the overhead — typically 8–12 bytes of the 64-byte FD payload, plus per-frame crypto cost — forces a trade-off between protected frames and bus load. In practice, OEMs protect a prioritized subset of safety-critical frames rather than the whole bus.

FlexRay: Deterministic but Niche

FlexRay offers 10 Mbit/s, time-triggered static segments plus a dynamic segment, and dual-channel redundancy for fault tolerance. It was the choice for steer-by-wire, active suspension, and some powertrain applications in the 2010s. It is deterministic and robust, but expensive per node and complex to configure. Security-wise it is no better than CAN — no authentication, no encryption — and its static schedule means an attacker who understands the cycle timing can insert frames into the dynamic segment with predictable effect. FlexRay adoption is now flat to declining as OEMs consolidate onto Ethernet backbones with CAN FD at the edges.

MOST: The Infotainment Legacy

Media Oriented Systems Transport (MOST25/MOST50/MOST150) is a ring topology optimized for audio, video, and control in infotainment. It is a closed ecosystem with proprietary tooling, which historically limited both attack research and attacker interest. The security-relevant issue is architectural: the MOST ring often connects the head unit, amplifier, and instrument cluster, and a compromised head unit can inject control messages into the ring. As infotainment migrates to Ethernet AVB/TSN, MOST is being retired, but fleets will carry it for another decade.

Automotive Ethernet: The New Backbone and Its Limits

100BASE-T1 and 1000BASE-T1 (single twisted pair, unshielded, up to 15 m and 40 m respectively with defined link budgets) have become the standard backbone for domain and zonal architectures. The attraction is bandwidth (100 Mbit/s to multi-gigabit), IP-based tooling, and the ability to carry camera, lidar, and OTA traffic on the same physical infrastructure as control data, with VLANs and TSN providing isolation and scheduling.

The critical caveat is that standard Ethernet is best-effort. Switches buffer and drop under congestion; there is no inherent guarantee of latency or delivery. Automotive profiles address this with IEEE 802.1Qav (credit-based shaper), 802.1Qbv (time-aware shaper / scheduled traffic), 802.1AS (gPTP time synchronization), and frame preemption (802.1Qbu/802.3br). These work, but they are configuration-heavy and fragile: a misconfigured gate control list, a clock drift beyond the gPTP sync budget, or an unexpected burst from a non-TSN-aware source can destroy the determinism that safety functions depend on. For a brake-by-wire or steer-by-wire path, the design rule is that Ethernet carries the data only where the end-to-end worst-case latency has been validated under fault and congestion injection — and where a fallback (a direct CAN path or a redundant channel) exists.

Security on Automotive Ethernet is a mixed picture. On the positive side, IP gives you TLS, IPsec, MACsec (802.1AE) on switch-to-switch links, VLAN segmentation, and 802.1X port authentication — real, standardized tools that CAN lacks. On the negative side, the same IP stack brings the entire history of network attacks: ARP spoofing, DHCP starvation, rogue switches, DNS rebinding, and the management-plane weaknesses of embedded TCP/IP stacks. A vehicle Ethernet backbone is a small data center with an unusual threat model, and it must be treated as such.

Threat Model: What Actually Gets Attacked

Verifiable public research and incident data point to a consistent set of attack classes:

• Physical bus access. The OBD-II port, aftermarket dongles, and exposed harnesses remain the cheapest attack path. CAN injection via the OBD port or a spliced harness is well documented and used in real thefts.
• Keyless entry relay and CAN injection. Relay attacks against passive entry, and direct CAN frame injection to defeat immobilizers, have driven insurance losses in the UK and North America. These are not theoretical; they are commodity attacks sold as tools.
• Telematics and infotainment compromise. The TCU and head unit are internet-facing. Cellular modem stacks, Bluetooth stacks, and Wi-Fi hotspots are the entry points; the pivot to CAN is the objective.
• Bluetooth and Wi-Fi attack surface. Hands-free profiles (HFP), phone book access (PBAP), and personal area networking (PAN) profiles expose parsers to malformed input. The Bluetooth PAN profile, which lets devices form ad-hoc networks or reach a remote network through a network access point, is a reminder that convenience features can create routing paths that were never in the threat model. Any Bluetooth stack in the vehicle should be treated as an untrusted input source and isolated from safety domains.
• OTA and diagnostic channels. Update signing, rollback protection, and diagnostic authentication (e.g., challenge-response on UDS) are the controls that determine whether a compromised backend or a rogue tester can reflash an ECU.

What is often overstated in vendor marketing is remote full-vehicle takeover. Public demonstrations have shown it is possible under specific conditions, but the practical, repeatable, monetizable attacks are physical-access and relay attacks. A security program that ignores the OBD port while chasing remote exploits is misallocating effort.

Countermeasures That Hold Up in Production

The following controls are the ones with real deployment evidence and measurable effect:

• Zonal gateway with allow-listed routing. A central or zonal gateway that forwards only known ID/message pairs between domains, with rate limits and payload sanity checks, blocks the majority of injection attempts that cross domains. This is the single highest-leverage control.
• SecOC on prioritized frames. Protect safety-critical and actuation frames with MAC and freshness counters; accept the bus-load cost on a selected subset rather than attempting full coverage.
• Intrusion detection at the gateway and in the TCU. Rule-based IDS (unknown IDs, frequency anomalies, payload entropy, bus-off events) plus lightweight ML models for CAN traffic. False-positive tuning is the hard part; budget for it.
• HSM and secure boot on every internet-reachable ECU. Key storage, secure boot chain, and signed OTA are table stakes for the TCU, head unit, and gateway.
• Network segmentation. VLANs and firewall rules on the Ethernet backbone; physical separation of safety domains from infotainment; no direct routing from the TCU to the powertrain domain.
• MACsec on backbone links and 802.1X port authentication. Prevents rogue switch insertion and link-level eavesdropping on the Ethernet backbone.
• Diagnostic hardening. Authentication on UDS security access, session timeouts, and logging of diagnostic sessions.

Comparison: Protocol Selection Guide

The table below summarizes the practical trade-offs for architects and for buyers evaluating platform claims.

• LIN — cost: lowest; bandwidth: 20 kbit/s; determinism: master-scheduled; security: none; use: body actuators. Do not put anything security-relevant on it.
• CAN / CAN FD — cost: low; bandwidth: 1 Mbit/s / up to 8 Mbit/s data phase; determinism: priority arbitration, well understood; security: none natively, SecOC optional; use: control and sensor networks at the edge.
• FlexRay — cost: high; bandwidth: 10 Mbit/s; determinism: time-triggered, strongest of the legacy buses; security: none; use: chassis and steer/brake-by-wire where already designed in.
• MOST — cost: medium-high; bandwidth: up to 150 Mbit/s; determinism: ring with reserved channels; security: closed ecosystem, no crypto; use: legacy infotainment.
• Automotive Ethernet (100/1000BASE-T1) — cost: medium; bandwidth: 100 Mbit/s to multi-gigabit; determinism: best-effort unless TSN configured and validated; security: TLS/IPsec/MACsec/802.1X available; use: backbone, cameras, lidar, OTA, zonal aggregation.

For a new zonal architecture, the defensible pattern is Ethernet backbone with TSN for time-critical flows, CAN FD at the zone edges for actuators and sensors, LIN for the cheapest body functions, and no FlexRay or MOST in new designs. For a buyer reading a spec sheet, the meaningful questions are: does the vehicle have a central gateway with domain isolation, is OTA signed and rollback-protected, and does the OEM publish a vulnerability disclosure policy and a security update cadence? Those three answers predict security posture far better than the bus technology list.

Performance and Timeliness: What to Validate

Ethernet's best-effort model is the most misunderstood item in automotive networking. The validation work that matters is not "does the link come up at 1 Gbit/s" but "what is the worst-case latency of a safety frame under congestion, fault, and attack." Concretely, a credible validation plan includes:

• gPTP sync accuracy under load — measure the offset between grandmaster and end stations with realistic traffic, not idle traffic.
• TSN gate schedule verification — inject bursts from non-TSN sources and confirm the scheduled windows still hold; test clock-drift and grandmaster-failover scenarios.
• Congestion and fault injection — rogue switch, duplicate frames, ARP storms, and link flaps; confirm the fallback path activates within the safety budget.
• SecOC overhead measurement — bus load and per-frame latency with MAC and freshness counters enabled on the protected subset.
• IDS false-positive rate — run the detector against months of real fleet traffic; a detector that fires on legitimate diagnostic sessions will be disabled by the service organization.

These are the benchmarks that separate a marketing claim from an engineered system. OEMs that publish them, or that let tier-one suppliers demonstrate them under fault injection, are the ones worth trusting.

Actionable Recommendations

For vehicle architects: Treat the gateway as a security device with its own threat model, CPU budget, and update path. Protect a prioritized subset of CAN frames with SecOC rather than attempting full coverage. Use Ethernet where bandwidth and IP tooling pay for themselves, but validate TSN determinism under fault injection before putting any safety function on it without a fallback. Isolate Bluetooth and Wi-Fi stacks in a domain that cannot route to safety buses.

For fleet operators and buyers: Ask for the OEM's vulnerability disclosure policy, the security update cadence, and whether OTA updates are signed with rollback protection. Prefer vehicles with a documented gateway isolation architecture. For aftermarket telematics, avoid devices that bridge directly to CAN without an allow-list; the OBD dongle is the most common physical attack vector in the field.

For developers and integrators: Assume every frame on CAN is attacker-controlled. Validate all payload lengths and ranges at the receiver. Implement freshness counters where replay matters. Test your Bluetooth and Wi-Fi parsers with malformed input as a matter of routine, and treat PAN-profile and hands-free features as untrusted network paths. Log diagnostic sessions and authenticate UDS security access.

The industry's direction is clear: Ethernet backbone, zonal gateways, CAN FD at the edges, and security controls layered at the gateway and the internet-facing ECUs. The protocols are converging; the security discipline is not automatic. The organizations that win will be the ones that treat the bus as an attack surface from the first line of the requirements document, not the ones that add a firewall after the first penetration test.

💬 Join the discussion on our forum: Share your thoughts or ask questions