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.
FAQ
Q: Classic CAN has no authentication or encryption by design. Does that mean CAN frames can never be secured, or are there practical countermeasures?
A: CAN's lack of authentication, encryption, and session semantics is part of its original 1980s design contract, so you cannot retrofit end-to-end cryptographic security onto classic CAN without changing the protocol or the ECUs. In practice, countermeasures are layered around the bus rather than on it: gateway filtering and segmentation to isolate domains, intrusion detection systems (IDS) that model normal frame timing and identifier usage, message authentication codes carried in CAN FD payloads where bandwidth allows (e.g., SecOC-style approaches), and strict control of which units can bridge to the bus. The realistic goal is to shrink the attack surface and detect injection, not to make every CAN frame confidential.
Q: Why is compromising the infotainment head unit or telematics box (TCU) considered so dangerous if those units are not safety-critical?
A: Because those units are the bridge between external interfaces (Wi-Fi, Bluetooth, cellular, OTA) and the internal CAN segments. Once an attacker has code execution on a head unit or TCU, they inherit the trust model of every ECU reachable through that gateway, and can inject frames claiming to be any node. This is exactly the pattern in the 2015 Jeep Cherokee research and the later keyless-relay and CAN-injection thefts: the remote or physical entry point matters mainly because it gets the attacker close enough to speak CAN.
Q: Automotive Ethernet offers far more bandwidth than CAN, but the article mentions a 'best-effort' reliability limit. What does that mean for safety-critical traffic?
A: Standard Ethernet is best-effort: no guaranteed delivery latency or ordering, and congestion can delay frames. For control traffic that needs deterministic timing, the industry adds mechanisms on top — time-sensitive networking (TSN) features such as time-aware scheduling, traffic shaping, and redundancy (e.g., 802.1CB frame replication), plus static VLAN segmentation and priority tagging. The key point is that Ethernet's raw model does not provide the timeliness guarantees CAN gave for free; those guarantees must be engineered and verified per traffic class, and the security posture (segmentation, filtering, monitoring) has to be designed alongside them.
Q: LIN has no cryptographic protection at all. Is that acceptable, and what is the actual risk?
A: For LIN's cost point (single-wire, up to 20 kbit/s, body functions like window lifts and mirrors), cryptographic protection is not practical, and the accepted control is architectural: LIN is treated as a leaf network behind a CAN gateway, protected by gateway filtering and physical access control. The realistic threat is indirect — a compromised LIN slave such as a door module used as a foothold, or LIN traffic used to fingerprint vehicle state. The risk is managed by containment, not by securing LIN itself.
Q: Given the mix of CAN, LIN, FlexRay, MOST, and Ethernet in one vehicle, where should security effort be concentrated?
A: Concentrate on the boundaries and the bridges. The highest-value targets are the external interfaces (telematics, Wi-Fi, Bluetooth, OTA) and the gateways that connect domains, because a compromise there translates directly into bus-level trust. From there, prioritize segmentation and filtering between domains, monitoring/IDS on the control buses, and hardening of any ECU that can transmit on a safety-relevant segment. Legacy leaf buses like LIN and MOST are lower priority in themselves but matter as footholds and as sources of state information, so they should be isolated and monitored rather than individually cryptographically protected.
💬 Join the discussion on our forum: Share your thoughts or ask questions
