PaperlayerView exact revision on arXiv

Source-linked AI summary

Cyberattacks and Countermeasures For In-Vehicle Networks

Emad Aliwa, Omer Rana, Charith Perera, Peter Burnap

arXiv:2004.10781v1cs.CR

TL;DR

Connected vehicles broaden the attack surface of CAN, a widely used protocol lacking built-in security and constrained by limited bandwidth, frame size, ECU resources, and real-time requirements. The paper surveys attacks and evaluates cryptographic and IDS approaches before comparing mitigation strategies and identifying future directions. It concludes that edge ECUs and CAN FD can support stronger protections while preserving compatibility or adding embedded security capabilities.

  • Problem

    CAN lacks built-in authentication and encryption, while connected-vehicle interfaces widen entry points and constrained vehicular resources complicate protection.

  • Method

    The paper surveys IVN attacks, classifies cryptographic and IDS approaches, and compares them by constraints, hardware, CAN-bus changes, mitigation types, and validation methods.

  • Results

    The survey identifies attack patterns and evaluates protections across cryptography, IDS, machine learning, hardware, protocol behavior, and deployment constraints.

  • Takeaways & Limitations

    Edge ECUs can manage authentication, encryption, and IDS with limited CAN modifications, while CAN FD can embed stronger security mechanisms and support higher payloads and bit rates.

  • Takeaways & Limitations

    Current countermeasures must accommodate CAN's limited payload, constrained ECUs, broadcast key distribution, replay freshness, and real-time sensitivity.

Abstract

from arXiv · show

As connectivity between and within vehicles increases, so does concern about safety and security. Various automotive serial protocols are used inside vehicles such as Controller Area Network (CAN), Local Interconnect Network (LIN) and FlexRay. CAN bus is the most used in-vehicle network protocol to support exchange of vehicle parameters between Electronic Control Units (ECUs). This protocol lacks security mechanisms by design and is therefore vulnerable to various attacks. Furthermore, connectivity of vehicles has made the CAN bus not only vulnerable from within the vehicle but also from outside. With the rise of connected cars, more entry points and interfaces have been introduced on board vehicles, thereby also leading to a wider potential attack surface. Existing security mechanisms focus on the use of encryption, authentication and vehicle Intrusion Detection Systems (IDS), which operate under various constrains such as low bandwidth, small frame size (e.g. in the CAN protocol), limited availability of computational resources and real-time sensitivity. We survey In-Vehicle Network (IVN) attacks which have been grouped under: direct interfaces-initiated attacks, telematics and infotainment-initiated attacks, and sensor-initiated attacks. We survey and classify current cryptographic and IDS approaches and compare these approaches based on criteria such as real time constrains, types of hardware used, changes in CAN bus behaviour, types of attack mitigation and software/ hardware used to validate these approaches. We conclude with potential mitigation strategies and research challenges for the future.

1 Introduction

Connected vehicles have a widening attack surface, while CAN lacks built-in security and remains vulnerable to attacks affecting safety-critical functions. The survey reviews protocols, cryptographic and IDS protections, mitigation strategies, and future research challenges.

  • CAN vulnerabilities: Successful attacks can control vehicle functions including brakes, lights, steering, and gears.The paper notes evidence from laboratory environments and real vehicles.
  • Threat landscape: Connected vehicles expose in-vehicle networks through internal interfaces, infotainment systems, wireless links, and sensors.Reported entry points include OBD-2, USB, CD players, Wi-Fi, Bluetooth, mobile networks, keyless fobs, and tyre-pressure sensors.
  • Survey scope: The survey describes serial bus protocols, evaluates cryptographic and IDS approaches, compares mitigation strategies, and identifies future cybersecurity research challenges.Its scope includes both protection mechanisms and their constraints in vehicular environments.
  • Survey scope: The paper organizes later discussion around protocol context, CAN architecture, connected-car components, and attacks through interfaces, telematics, infotainment, and sensors.These sections provide the structure for the review.

2 Automotive Serial Bus Protocols

Vehicles use CAN, LIN, and FlexRay for distinct in-vehicle communication needs, with CAN most widely used for critical functions. Their differing speed, cost, reliability, and real-time requirements shape protocol selection.

  • Protocol overview: CAN, FlexRay, and LIN are the three key serial protocols used for in-vehicle communication.The paper focuses its attacks, vulnerabilities, and countermeasures review primarily on CAN because it is most widely used.
  • CAN: CAN supports critical powertrain, engine-management, anti-brake, and transmission functions and provides real-time access.Classical CAN reaches 1 Mbps; CAN FD supports up to 8 Mbps and payloads up to 64 bytes.
  • Vehicle domains: Powertrain and chassis domains require real-time responses for engine, transmission, braking, suspension, and steering functions.Body functions generally do not require real-time response, while telematics and infotainment manage communication, information, and entertainment services.
  • Protocol selection: High-speed CAN serves real-time and safety-related domains, whereas LIN and low-speed CAN serve less-critical functions at lower cost.Domain requirements differ in performance, quality, and response time.
  • Review focus: The paper provides protocol context before focusing its security analysis on CAN.A figure and table cover CAN, CAN FD, LIN, and FlexRay.
  • LIN and FlexRay: LIN is a low-cost, low-bit-rate protocol for non-critical applications, while FlexRay targets high-bit-rate, redundant, fault-tolerant, safety-critical functions.FlexRay supports up to 10 Mbps and applications such as braking-by-wire and steering-by-wire; LIN supports 1–20 kbps.

3 Controller Area Network (CAN)

CAN is the dominant in-vehicle protocol for exchanging data between ECUs, but its design lacks authentication and other security mechanisms, exposing connected vehicles to attacks. This section describes CAN framing, CAN FD, protocol layers, and related automotive security standards and projects.

  • CAN fundamentals: CAN uses a two-wire, multi-master serial bus to exchange messages between ECUs, but it does not provide source addresses or message authentication.Classical CAN and CAN FD are standardized under ISO 11898; message identifiers determine frame priority and content.
  • CAN fundamentals: Classical CAN includes 11-bit standard and 29-bit extended identifiers, with payloads of up to 8 bytes.The extended format supports more message identifiers and therefore more potential nodes.
  • CAN frame structure: A CAN frame contains header, control, data, and trailer fields supporting identification, payload delivery, error detection, acknowledgement, and frame separation.The trailer includes a 15-bit CRC, ACK, EOF, and inter-frame spacing fields.
  • CAN FD: CAN FD extends CAN for higher throughput and larger payloads, supporting up to 64 bytes of data and speeds up to 8Mbps.It is available in standard and extended identifier forms and is standardized in the ISO 11898 series.
  • Frame types: CAN supports data, remote, error, and overload frames, and its broadcast design delivers transmitted frames to all connected nodes.Nodes use remote frames to request data, while error and overload frames signal bus or receiver conditions.

4 Connected Car Environment

Connected vehicles expose CAN-linked systems through telematics, infotainment, direct interfaces, wireless links, and sensors. These entry points support services but create opportunities for remote and physical attacks.

  • Connected vehicle components: Connected cars use telematics, infotainment, driver-assistance, and Vehicle-2-X systems to provide communication, navigation, entertainment, and safety services.Interfaces include Wi-Fi, Bluetooth, GPS, mobile data, cameras, LiDAR, and DSRC.
  • Wireless interfaces: Bluetooth, Wi-Fi, and cellular interfaces introduce demonstrated vulnerabilities into connected vehicles.The paper cites attacks involving Bluetooth connections, Wi-Fi hotspots, and cellular interfaces.
  • Direct interfaces: The mandatory OBD-2 port directly connects to the CAN bus and can support both physical and wireless attacks, including denial of service and malicious message injection.A customized board connected through OBD-2 used SMS messages to inject data into the CAN bus.
  • Vehicle interfaces: GPS and CD-player interfaces can provide attack paths because they connect to vehicle systems and may allow data injection, sniffing, or other cyberattacks.The paper reports GPS data retrieval through an unprotected port and attacks involving a CD player connected to the internal network.
  • Sensors and access systems: Sensors and keyless-entry systems can be jammed or manipulated, affecting CAN data, vehicle behavior, and access to the vehicle.Reported examples include incorrect sensor values, LiDAR and camera jamming, and attacks against key-fob signals.

5 Vulnerability of In-Vehicle CAN bus

The CAN bus is vulnerable because its broadcast, unsegmented design lacks authentication, encryption, and integrity protections. Attackers can exploit interfaces or learned message behavior to sniff, inject, replay, fuzz, impersonate ECUs, or deny service.

  • CAN architecture: All ECUs share an unsegmented broadcast bus, allowing nodes to send and receive the same messages.This architecture exposes bus traffic broadly and enables arbitrary nodes to interact with shared communications.
  • Protocol vulnerabilities: CAN lacks authentication and encryption, enabling message poisoning, data sniffing, and denial-of-service attacks.Any ECU can observe broadcast frames, while arbitration priority can be abused to dominate bus access.
  • Attack trends: 7 times more vehicle cyberattacks occurred in 2019 than in 2010, while attacks doubled from 2018 to 2019.The paper classifies vulnerable points as direct, indirect, short-range, and long-range attack paths.
  • Attack entry points: Attacks have used OBD-2, wireless interfaces, infotainment systems, and keyless entry to control or disrupt vehicle functions.Reported targets include speed, brakes, steering, wheels, and other ECUs or components.
  • Attack types: CAN attacks include sniffing, fuzzing, frame falsification, injection, denial of service, and ECU impersonation.These attacks exploit missing authentication, integrity checking, encryption, or the arbitration mechanism.
  • Traffic analysis: Attackers can reverse engineer observed CAN traffic to learn ECU identifiers, payload ranges, and transmission rates, then imitate ECU behavior.This knowledge supports targeted message generation and increased CAN traffic.

6 CAN bus Security Mechanisms

CAN security mechanisms combine cryptography, authentication, protocol redesign, and additional hardware or monitoring components. Their feasibility is constrained by CAN’s limited capacity, latency requirements, computational resources, compatibility, and implementation cost.

  • Evaluation framework: The survey evaluates cryptographic and IDS countermeasures by attack coverage, overhead, utilization, hardware, software, metrics, and test environment.It compares approaches used inside and outside vehicles.
  • Countermeasure classes: Security approaches include encryption, authentication, and CAN redesign through field replacement, message splitting, or added nodes and components.These mechanisms must avoid overloading the limited-capacity CAN bus.
  • Design constraints: CAN security must address limited frame size, low response speed, broadcast exposure, absent confidentiality, integrity and authentication, backward compatibility, and ECU resource limits.These constraints shape both software and hardware countermeasure designs.
  • Cryptographic mechanisms: Lightweight MACs, session keys, preloaded keys, and Hardware Security Modules can provide authentication, integrity, freshness, and replay resistance under ECU constraints.Small MAC tags preserve CAN payload space, while HSMs can improve encryption and decryption time.
  • Authentication limits: MAC authentication protects integrity and authenticity but does not provide confidentiality, leaving traffic exposed to sniffing and reverse engineering.The paper therefore identifies combined MAC and encryption as necessary for broader protection.
  • Trade-offs: Existing authentication proposals trade off compatibility, bus load, latency, hardware cost, and attack coverage.Examples include message splitting, CAN+ requirements, changed headers, delayed authentication, and dedicated hardware.

6.4 CAN Frame Encryption

CAN frame encryption approaches target confidentiality alongside authentication, replay resistance, and access control, using software, dedicated hardware, dynamic keys, and CAN FD extensions. Their main trade-offs involve frame compatibility, bus load, hardware changes, and payload overhead.

  • Encryption and authentication: One encryption-and-authentication approach prevents sniffing and injection but sends multiple frames per CAN ID, increasing latency and bus load.The approach provides integrity and authenticity while sacrificing communication efficiency.
  • Hardware-based protection: A dedicated ECU server can authenticate ECUs and distribute keys, but PUF-enabled hardware requires modifications that are infeasible for current vehicle networks.The approach was tested using a Xilinx Kintex KC705 FPGA and an embedded PUF.
  • Dynamic-key encryption: CANTrack uses dynamic symmetric keys to encrypt the 8byte payload without modifying the message ID, and testing showed prevention of sniffing, replay, and spoofing attacks.The message ID remains available for CAN arbitration.
  • CAN FD approaches: CAN FD security architectures use key management, encryption, authentication, freshness, and gateway-based access control.One design uses 16 bytes of HMAC-SHA256 tags and AES-128 encryption for the remaining 47 bytes, validated with CAN-FD boards and CANoe.
  • CAN FD approaches: A secure CAN FD design uses public and private keys, ECU groups, and a gateway to verify session keys and forward frames between CAN sub-buses.The design allocates 36bytes to data payload and 28bytes to the cryptographic tag.
  • Lightweight authentication: Chaskey provides lower latency than HMAC-SHA1 on a 32-bit microcontroller while focusing on message authentication rather than confidentiality.The implementation uses a 128bit key, 4bytes of counters, a 16-byte MAC tag, and 43 bytes of payload.

6.5 In-Vehicle Intrusion Detection Systems

In-vehicle IDS deployments must balance detection capability with ECU cost, CAN-network placement, and constrained bus behavior. Approaches include host and network placement and exploit frame, timing, payload, and physical-layer features.

  • Deployment models: IDSs can be signature-based or anomaly-based, and can operate as Host-IDSs on ECUs or Network-IDSs as additional CAN nodes.The paper identifies OBD-2 dongles as an example of an added NIDS node.
  • Deployment models: Host-IDS deployment may require ECU changes and be less cost-effective, motivating additional-node NIDS placement on the CAN bus.The passage specifically gives an OBD-2 dongle as an example of an additional node.
  • Detection behavior: IDSs may passively report attacks or actively perform actions intended to prevent them.Detection can use deviations from fixed CAN-message intervals or ECU-specific signal and voltage profiles.
  • Detection features: CAN-frame sensors can inspect format, message location, payload range, frequency, and correlations among exchanged messages.These features support checks of message structure, subsystem origin, legitimate payload values, timing, and inter-message relationships.
  • Deployment models: Figures 13 and 14 illustrate alternative IDS positions, including IDS placement within the automotive CAN network and IDS integration as an ECU.The supplied captions identify the two deployment illustrations but do not state comparative outcomes.

6.6 IDS based on signature

Signature-based IDSs compare CAN traffic against predefined attack signatures and can achieve low false-positive detection. Their effectiveness depends on maintaining signatures and observing sufficient message content.

  • Signature-based detection: Signature-based IDSs detect attacks using a predefined list of attack signatures and are reported to have low false-positive rates.Their signature database must be updated when new attacks emerge.
  • Limitations: Maintaining signatures for known attacks and their variants can require a potentially large database.Real-time extraction of attack signatures for a moving vehicle can also introduce high latency.
  • Limitations: A CAN signature approach may have limited benefit when CAN-word length is unknown in advance.It may also miss attacks when the detector does not observe the first malicious portion of the exchanged data.

6.7 IDS based on Anomaly Detection

Anomaly-based IDSs learn or characterize normal CAN traffic using timing, frequency, payload, entropy, statistical, and sequential features. Reported methods detect several attack types, but low-volume injections remain a recurring challenge.

  • Overview: Anomaly-based IDS methods build models of abnormal traffic using statistical, machine-learning, rule-based, or physical-fingerprint techniques.These models aim to identify new patterns and predict attacks not previously observed.
  • Statistical features: Common statistical features include packet counts, inter-frame intervals, CAN-ID frequency, throughput, response time, Hamming distance, entropy, ANOVA, Z-score, and ARIMA.The surveyed approaches analyze timing, volume, identifiers, payloads, or sequential changes in CAN traffic.
  • Known limitations: CAN-ID frequency and timing methods can detect DoS and injection attacks, but may miss small-volume, payload-manipulation, or impersonated-ECU attacks.These limitations arise when forged messages do not sufficiently alter broadcast frequency or timing patterns.
  • Entropy methods: Entropy-based methods compare CAN-ID or payload variation with normal baselines, with class-specific analysis and optimized sliding windows improving reported detection accuracy.One entropy approach could not detect a small number of injected CAN messages, while another reported better accuracy than previous entropy-based IDSs.
  • Other statistical methods: Other surveyed methods use ANOVA, Hamming distance, quantized intervals, cumulative sums, ARIMA, Z-scores, and temporal-memory models for anomaly detection.The quantized-interval approach reported positive true/false positive and negative rates but acknowledged difficulty detecting low-volume injections; ARIMA and Z-score methods detected injections and dropped packets.

6.9 Machine Learning-based Approaches

Machine-learning IDSs learn normal or anomalous CAN behavior from traffic features and time series, using models ranging from SVMs and Bayesian networks to neural networks. Reported studies cover multiple attack types, while online deployment and validation remain important constraints.

  • Overview: Machine-learning IDSs learn normal versus anomalous CAN behavior and can process large traffic volumes with multiple features.Raw-data extraction and preprocessing are important because vehicle manufacturers may not publish detailed decoding specifications.
  • Model families: Unsupervised and time-series models include Hidden Markov Models, one-class SVMs, LSTM and RNN architectures, autoencoders, GANs, and CNNs.Bayesian approaches additionally model probabilistic relationships among variables and can support filtering, smoothing, and prediction.
  • Reported results: The enhanced one-class SVM was compared with Random Forest and classical one-class SVM using True Positive Rate, with better detection accuracy reported.The model learned normal behavior from unlabelled vehicle time-series data and detected deviations as anomalies.
  • Evaluation: Neural and autoencoder approaches were evaluated against attacks including DoS, frame fuzzification, spoofing, flooding, and malfunction attacks.Studies used raw CAN data, simulated environments, real-vehicle-derived data, or datasets containing attack traffic.
  • Deployment limitations: Cloud-based detection can provide substantial computational resources but may be limited to offline detection.A neural-network architecture for alerts, connected-car updates, and mitigation was presented as theoretical and not validated in real scenarios.

6.10 IDS based on Physical Characteristics

Physical-characteristic IDS approaches profile ECU-specific signals, voltage signatures, or clock behavior to detect anomalous CAN traffic. These methods complement signature and machine-learning IDS approaches, which differ in their data and attack-detection requirements.

  • Physical-layer approaches: Physical-layer IDS builds profiles of each ECU’s signals and voltage signatures, then compares traffic against those profiles for anomalies.The approach targets unusual physical-layer characteristics associated with over-current, DoS, and error-frame retransmission attacks.
  • Physical-layer approaches: Clock-based IDS fingerprints ECUs by measuring the periodic frequency of messages they transmit and establishing baseline clock behavior.
  • IDS comparison: Signature-based IDS can achieve low false positives, but requires extracted attack signatures and may struggle with previously unseen CAN attacks.
  • IDS comparison: Unsupervised machine learning can classify patterns and detect anomalies in unlabeled raw CAN data after addressing the need to make large data volumes meaningful.

7 Limitations with Current Approaches

Current in-vehicle security approaches must reconcile CAN’s constrained protocol and ECU resources with real-time detection and deployment requirements. Key boundaries include implementation compatibility, computational capacity, latency, training data, and prevention capability.

  • Cryptographic approaches: CAN cryptography must account for limited payload capacity, computationally constrained ECUs, broadcast communication, key distribution, and data freshness.
  • Cryptographic approaches: Hardware cryptography can improve real-time processing but requires updating numerous ECUs, is incompatible with current vehicles, and may impose significant implementation cost.The paper notes vehicles typically contain about 70 ECUs.
  • Cryptographic approaches: Software cryptography avoids additional hardware, but existing approaches have not generally been validated across the large number of ECUs found in vehicles.
  • Cryptographic approaches: Encryption and authentication face latency and payload constraints, while altering CAN frame behavior can create ECU incompatibility and additional complexity.
  • Intrusion Detection System: IDS development is constrained by the absence of a global attack-signature database, the danger of collecting attack signatures on moving vehicles, and the difficulty of maintaining signatures for emerging attacks.
  • Intrusion Detection System: IDS validation is limited by unrepresentative computational testbeds, and machine-learning or deep-learning methods may require hardware unavailable in current ECUs.
  • Intrusion Detection System: Deep-learning IDS can incur high detection latency, making cloud-based offline detection dependent on stable connectivity and potentially unsuitable for real-time passenger safety.
  • Intrusion Detection System: Host-based IDS deployment can be costly and incompatible, whereas an OBD-2 network-node dongle can be more feasible without CAN-bus modification.

8 Conclusion

The conclusion contrasts cryptography’s resource and timing demands with IDS’s passive operation, then proposes edge devices and CAN FD as practical directions. It also emphasizes protecting external interfaces that can inject data into internal CAN networks.

  • Conclusion: Encryption is difficult on classical CAN because current ECUs have limited resources, CAN has small payloads and low bit rates, and real-time decisions cannot tolerate added delay.
  • Conclusion: IDS operates passively without changing network or protocol specifications, although deep-learning IDS may require computational resources unavailable inside vehicles.
  • Conclusion: Edge ECU devices can manage authentication, encryption, and plug-in IDS functions through OBD-2, telematics, and infotainment interfaces with limited CAN-bus modification.
  • Conclusion: CAN FD offers higher data rates, larger payloads, and support for embedded cryptography, enabling integration of IDS, encryption, authentication, firewalls, and access controls.
  • Conclusion: Telematics, infotainment, wireless sensors, and DSRC for V2V and V2I require protection because they can provide entry points for data injection into internal CAN networks.
  • Conclusion: CAN remains widely used in electric and autonomous vehicles, sustaining cybersecurity interest despite newer bus architectures and CAN improvements such as CAN FD and CAN XL.
Loading 2004.10781v1…