Securing Vehicle-to-Everything (V2X) Communication Platforms

03/12/2020
by   Monowar Hasan, et al.
0

Modern vehicular wireless technology enables vehicles to exchange information at any time, from any place, to any network – forms the vehicle-to-everything (V2X) communication platforms. Despite benefits, V2X applications also face great challenges to security and privacy – a very valid concern since breaches are not uncommon in automotive communication networks and applications. In this survey, we provide an extensive overview of V2X ecosystem. We also review main security/privacy issues, current standardization activities and existing defense mechanisms proposed within the V2X domain. We then identified semantic gaps of existing security solutions and outline possible open issues.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

01/04/2019

Cyber Security Challenges and Solutions for V2X Communications: A Survey

In recent years, vehicles became able to establish connections with othe...
10/09/2019

An Extended Survey on Vehicle Security

The advanced electronic units with wireless capabilities inside modern v...
02/14/2018

A Security Credential Management System for V2X Communications

The US Department of Transportation (USDOT) issued a proposed rule on Ja...
06/11/2020

Threats and Countermeasures of Cyber Security in Direct and Remote Vehicle Communication Systems

Traffic management, road safety, and environmental impact are important ...
01/06/2020

Security and Privacy Challenges in Upcoming Intelligent Urban Micromobility Transportation Systems

Micromobility vehicles are gaining popularity due to their portable natu...
04/08/2021

A Survey on Security Issues of 5G NR: Perspective of Artificial Dust and Artificial Rain

5G NR (New Radio) incorporates concepts of novel technologies such as sp...
01/21/2020

VeSPA: Vehicular Security and Privacy-preserving Architecture

Standardization and harmonization efforts have reached a consensus towar...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

Modern vehicular networks have emerged to facilitate intelligent ground transportation systems. Communication technologies in automobiles connect the various elements such as vehicles, pedestrians, infrastructures, roads, cloud computing service platforms, etc. to each other. This has given raise to the concept of V2X (vehicle-to-everything) communications. V2X communications uses recent generation of networking technology to facilitate vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-pedestrian (V2P) and vehicle-to-cloud (V2C) connections (see Fig. 1 for a high-level illustration). V2X communication technology is expected to improve traffic efficiency, reducing traffic incidents and road pollution, saving resources, etc. [14, 171]. Common use-cases for V2X applications include (but not limited to) [158, 14, 24, 171]: road safety (e.g., traffic jam/incident reporting, collision warning and collision avoidance), cooperative automated driving, infotainment services (e.g., traffic information services), etc.As with all complex connected computing platforms, extra computing capabilities in vehicles increase the exposure to potential vulnerabilities and also the likelihood of future attacks. Despite the fact that V2X communication aims to provide a robust and resilient transportation infrastructure, V2X technologies (both existing as well as expected future developments) also pose new security challenges. For example, a malicious vehicle can send false observation about the road (say traffic jam or an accident) and bias other vehicles to believe its incorrect observation – as a result other vehicles are forced to change their behavior (say slow-down or reroute). Attack detection (and mitigation) is essential for widely deployed V2X systems, considering the fact that attackers may have physical access to a subset of the system. Attacks to vehicular communication systems can cause data loss, component failure and also damage environment/infrastructures. Therefore securing V2X communicating platforms is crucial for the design, implementation and wide-scale deployment of such technology.

Fig. 1: An illustration of V2X communication: V2X-enabled vehicles are communicating with other vehicles and infrastructures (called RSU [road-side unit]). An in-vehicle communication unit, known as on-board unit (OBU) is attached with the vehicular control system and act as an external communication interface with other entities (e.g., vehicles/RSUs, etc.).

Methodology and Contributions

While prior research[120, 122] identifies some V2X security vulnerabilities and recommends potential mitigation techniques, there is an absence of a comprehensive summary of security challenges, standardization activities and existing solutions. In this paper we investigate V2X security challenges and summarize existing solutions in a comprehensive manner. We study over 150 papers crawled from major online literature archives (Google Scholar, IEEE Xplore, ACM Digital Library, Scopus, ScienceDirect, Wiley Online Library) published in the last 25 years (1994-2019) and identify the security issues and potential countermeasures related to V2X context. We exclude the papers that are not directly related to vehicular (communication) security domain (for instance those that are applicable to more general purpose wireless/sensor networks and/or mobile adhoc networks, e.g., MANETs). We limit our study on abnormal system behavior to artifacts of malicious intent (e.g., not due to hardware or component failures). We also primarily focus on the security aspects of V2X communications and provide necessary pointers for the other areas (such as radio access mechanisms, resource allocation, interference management, etc.), when needed. In this survey we present the following contributions.

  • An in-depth discussion of V2X technologies and security/privacy standardization activities (Section II).

  • Classification and summary of potential security threats for modern V2X applications (Section IV).

  • A taxonomy of misbehavior detection approaches (Section V) as well as a comprehensive analysis and discussion of the state-of-the-art V2X security solutions (Sections VI and VII).

We also discuss possible open issues (Section VIII), summarize multiple industry/academic/government initiatives for securing V2X communications (Section IX-A) and compare our work with related surveys (Section IX-B).

Ii V2X Platform : An Overview

This section provides an overview of V2X communication interfaces (Section II-A) and discuss various network/communication models (Section II-B).

Ii-a Communication Interfaces

The internal architecture of a vehicle is interconnected with ECUs (electronic control units – embedded computing platform that monitor/control automotive systems) coupled with sensors and actuators. The communication between the vehicle and the outside world such as other vehicles or roadside units (RSUs) is performed via external interfaces (see Fig. 1). These vehicular external interfaces are attached to the telematics control unit (TCU) – also referred to as on-board unit (OBU)111In this paper we use the terms ‘OBU’ and ‘vehicle’ interchangeably. – an ECU that provides wireless connectivity [41, 93]. A vehicle control unit coordinates with the OBU to collect and disseminate vehicular data [135]. The current standards for V2X communication are DSRC (dedicated short range communication) [84] in the United States, C-ITS (cooperative intelligent transport systems) [38] in Europe and ITS Connect [77] in Japan. Both DSRC and C-ITS operating in the 5.9 GHz ITS band while ITS Connect operating in 760 MHz band (refer to Section II-B1 for details). An alternative to DSRC/C-ITS is the next generation of cellular wireless mobile telecommunications technology (see Section II-B2

). OBUs can also be equipped with interfaces for long-range communication. These long-range wireless channels can be classified as

broadcast channels (signals can be broadcast to multiple vehicles without knowledge of the receiver’s address) and addressable channels (where messages are sent to vehicles with specific addresses.) [26]. Examples of broadcast channels include the global navigation satellite system (GNSS), traffic message/satellite radio receivers, etc. Addressable channels are typically used for long-range voice/data transmissions and are intended to be used for cellular communications for mobile broadband [93].

Fig. 2: A high level schematic of a generic V2X packet format.

Ii-B Network and Communication Model

V2X communication systems [110] consist of vehicle-to-vehicle (V2V), vehicle-to-pedestrian (V2P), vehicle-to-infrastructure (V2I), vehicle-to-cloud (V2C), vehicle-to-network (V2N) as well as vehicle-to-infrastructure-to-vehicle (V2I2V) communications. This can either use: (a) a technology based on IEEE 802.11p standard [70] (operating in the 5.9 GHz frequency) or (b) a long-term evolution (LTE) based technology. The entities in the network can communicate with each other (i) directly (e.g., using 802.11p-based technologies or LTE PC5/Sidelink interface) and/or (ii) by using LTE Uu interface (uplink and downlink).

Ii-B1 IEEE 802.11p-based V2X Communications

As mentioned in the previous section, the IEEE 802.11p-based adhoc V2X communication approaches are DSRC [84] in the United States and C-ITS [38] in Europe and ITS Connect in Japan222In Section III-B, we present the security standardization efforts in detail.. This IEEE 802.11p-based V2X communication technology is mature and is already deployed in several countries [132]. Networking patterns for V2X communications are mainly broadcast and unicast/multicast as information messages [156] – thus suitable for a wide range of V2X applications such as large-scale traffic optimization, cooperative cruise control, lane change warnings etc. For certain applications (e.g., over-the-air software/security credential updates, traffic and fuel management333For instance, using signal phase and time (SPaT) messages [141] RSU units can inform incoming vehicles about traffic light changes (e.g., green/red) – allowing more efficient fuel management., non-safety applications such as infotainment/multimedia streaming, etc.) communication with infrastructure components, i.e., via RSUs can help in increasing the communication range and connectivity with back-end infrastructures as well as the Internet. The physical transmission (PHY) and medium access control (MAC) for both DSRC and C-ITS are same, e.g., based on IEEE 802.11p amendment standards [70] for vehicular networks. ITS Connect is based on the ARIB STD-T109 standard [10] that is similar to the IEEE 802.11p [70] for PHY and MAC layers. The technical approaches of DSRC and C-ITS have many similarities and will be the focus of this paper. As mentioned earlier, both DSRC and C-ITS operate in the 5.9 GHz band. In the United States the communication channels range from 5.825 GHz to 5.925 GHz and the spectrum is subdivided into 10 MHz channels while the European spectrum allocation is sub-divided into several parts: (i) a 30 MHz dedicated primary frequency band for safety and traffic efficiency applications (class A); (ii) 20 MHz for non-safety applications (class B); (iii) shared channels for radio local area networks (class C); and (iv) a set of reserved channels for future use (class D). In Japan, ITS Connect operates in the 760 MHz band where 9 MHz bandwidth from 755.5 MHz to 764.5 MHz is assigned for both V2V and V2I services using ITS Connect. In order to support V2X communication the syntax and semantics of V2X messages have been defined by standardization bodies. For DSRC, the basic safety message (BSM) [134] conveys core state information about the transmitting vehicle such as position, dynamics, status, etc. The BSM is a two-part message – the first (default) part is periodic (sent at a rate maximum rate of 10 Hz) and the second part is event-driven (e.g., for emergency braking, traffic jams, etc.) and included in the next periodic BSM message. The C-ITS equivalent of BSM are the periodic cooperative awareness message (CAM) and the (event-driven) decentralized environmental notification message (DENM) [140]. The event-driven BSM messages are suitable for local neighborhoods (e.g., single hop broadcast) where DENMs can be used for specific geographical areas (e.g., multiple hops geocast). BSM, CAM, as well as DENM do not use encryption, i.e., they are transmitted unencrypted [134, 140]. Figure 2 depicts a generic V2X packet format. For a detailed overview of V2X communication models, protocol stack and standardization activities we refer the reader to related work [107].

Ii-B2 LTE-based V2X Communications

LTE-V2X [139] allows vehicles to communication with each other with or without relying on base stations. 3GPP (3rd generation partnership project) Release 12 specifies proximity services (ProSe) for device-to-device (D2D) communications that enables exchange of data over short distances through a direct communication link (sidelink) based on PC5 interface (mode 1 and mode 2) and public safety is one of the target services of LTE-D2D [103]. LTE-V2X is an extension of 3GPP D2D functionality [65]. 3GPP Release 14 extends the ProSe functionality for LTE-V2X by using the LTE-Uu interface (uplink and downlink) and the new PC5 interface (mode 3 and mode 4). LTE-V2X PC5 operates in the following two new modes (see Fig. 3): (a) mode 3 (scheduled resource allocation mode): LTE-V2X PC5 mode 3 is V2X communication using sidelink with sidelink scheduling by base stations (e.g., scheduling is done via Uu links); (b) mode 4 (autonomous resource selection mode): LTE-V2X PC5 mode 4 is V2X communication using sidelink with autonomous sidelink resource selections by the vehicles without the help of base stations  [1, 24]. Both modes use PC5 for V2X communication among vehicles. In addition, mode 3 uses Uu interface for sidelink scheduling information between vehicles and base station.

Fig. 3: LTE-V2X communication modes: (a) Uu-based LTE-V2X (left): vehicles are communicating with traditional uplink (UL) and downlink (DL) channels using base station; (b) PC5-based LTE-V2X (right): vehicles use sidelinks (SL) to communicate each other with or without assistance from base stations using UL and DL for scheduling sidelink resources.

When compared to DSRC/C-ITS, the claim is that LTE-V2X systems will to provide larger coverage [139, 24]. In prior work [24, 162, 172, 14, 160, 40, 5] researchers study and compare the adhoc V2X communications (e.g., DSRC/C-ITS) with LTE-V2X in terms of radio resource allocation, performance, standardization, use-cases, deployment issues, interoperability, etc. It is worth noting that, unlike the mature DSRC/C-ITS platforms, LTE-V2X technologies are still under development and the necessary trials/testing to support large number of vehicles in real environments for safety applications is not yet available [40, 161]. In this paper, we primarily focus on the security issues for the V2X communications based on DSRC/C-ITS – although we believe that many of those schemes can be transferred to LTE-V2X with limited (or no) modifications. We also discuss the security challenges and current solutions for LTE-V2X communication systems (Section VIII-B).

Iii Existing Architectures for Securing V2X Communications

In this section we present existing cryptographic solutions for V2X security (Section III-A) and briefly discuss about various standardization efforts (Section III-B). We mainly focus on direct V2X communication scenarios.

Iii-a Public Key Infrastructure

For securing V2X communications (e.g., to ensure message integrity and authenticity), the common approach is to use asymmetric cryptography using a public key infrastructure (PKI) for the management of security credentials [59, 21, 140]. PKI enables secure exchange of messages over the network. Each vehicle is provided an asymmetric key pair and a certificate. The certificate contains the public key with V2X specific attributes such as ID and is signed by the key issuing authority – this way vehicles are registered as valid V2X participants. PKI includes the following key elements: (a) a trusted party, e.g., root certificate authority (RCA), that provides services to authenticate the identity of entities; (b) a registration authority certified by an RCA that issues certificates for specific uses permitted by the RCA; (c) a database that stores certificate requests and issues/revokes certificates and (d) an in-vehicle certificate storage – to save the issued certificates and private keys.

Fig. 4: Schematic of a generic V2X PKI.

In Fig. 4 we illustrate a high-level PKI for V2X communications [52]. The communication node (e.g., vehicle and RSU) is an end-entity of the system that requests certificates from the PKI and communicates with other end-entities. The RCA is the root of trust for all certificates. It delivers certificates to the authorization entities to issue certificates to the communication nodes. The distribution center provide up-to-date trust information necessary to validate that received information obtained from a legitimate and authorized PKI authority. The operator registers communication nodes and updates necessary information in the authorization entities.

Iii-B Standardization Efforts for V2X Security

In the United States the major standardization development organizations (SDO) active in the V2X domain are IEEE and SAE (Society of Automotive Engineers). In Europe, the relevant SDOs are ETSI (European Telecommunications Standards Institute) and CEN (European committee for standardization). Dedicated working groups within standardization organizations and vehicle manufacturers are working on addressing security and privacy issues for V2X systems, viz., the IEEE 1609.2 working group, SAE DSRC technical committee, CAMP-VSC (crash avoidance metrics partnership–vehicle safety communications) consortium in United States and the ETSI-TC-ITS-WG5 working group in Europe addressing security and privacy issues for V2X systems[45, 162]. Standardization groups in Europe and United States are separately building V2X security architectures based on PKI (see related work [60] for details). CAMP-VSC defines “misbehavior” as the willful or inadvertent transmission of incorrect data within the vehicular network and provides mechanisms to detect such transmissions [167]. The team conceptualizes five local misbehavior detection (LMBD) methods (to identify misbehavior within a V2V network) and three threshold-based global misbehavior detection (GMBD) methods (identifying misbehavior at the vehicle-level using in-vehicle algorithms and processing). The misbehavior detection techniques use a security credential management system (SCMS) and a misbehavior authority (MA) to identify anomolous vehicles. An OBU can send misbehavior reports (MBRs) to SCMS that is based on BSM metadata, for instance: (a) the time and location where the MBR was created; (b) the LMBD method that caused the MBR creation and (c) some combination of the start and stop time and location of the suspected misbehavior (depending on the LMBD method).

Iii-B1 V2X Security Standards

IEEE has introduced a standard for V2X communications – WAVE (wireless access in vehicular environments) [72, 100]. Above the protocol stack, V2X performance requirements are specified by SAE (e.g., in the SAE J2945/1 standard [134]) that is used primarily in the United States. ETSI has also developed standards for V2X communications, e.g., ETSI-ITS (ETSI intelligent transport system) that includes an overall architecture, a protocol stack as well as security requirements and mechanisms [140]. In this section we mainly focus on the standardization of WAVE/DSRC and ETSI-ITS since they are the most dominant technologies for actual deployment [39]. Figure 7 depicts the protocol stacks with core networking and security standards for V2X communications in United States (Fig. (a)a) and Europe (Fig. (b)b).

(a)
(b)
Fig. 7: Protocol stack and related core standards for V2X communications: (a) in United States (SAE 2945/1); (b) in Europe (ETSI-ITS).

The SAE 2945/1 standard [134] uses a PKI-based SCMS [21] for V2X security. The standard also requires mechanisms to protect privacy: the certificate is changed after a variable length of time and the entries in the BSM messages (that may be used to identify/track the vehicle) are randomized whenever a certificate is changed. The V2X message security is complaint with the IEEE 1609.2 security service standard [71] that defines security data structures, secure message formats and the processing of those secure messages within the WAVE platform. The key features of the IEEE 1609.2 standard include: (a) wireless communication scheme between V2X devices and PKI; (b) certificate validity and revocation schemes and (c) privacy (e.g., vehicle/user identity) preservation. For an overview of the IEEE 1609.2 standard we refer the readers to the related work [185, Ch. 21]. Security services of the IEEE 1609.2 standard support traditional cryptography mechanisms. The service for message authenticity and integrity is based on digital signatures. Signing and verification are performed using a public key digital signature algorithm. For instance, the sender computes a signature using the elliptic curve digital signature algorithm (ECDSA) and the receiver verifies the signature using the associated certificate. For transporting symmetric encryption keys, the standard uses an asymmetric encryption scheme based on the elliptic curve integrated encryption scheme (ECIES). The standard also defines the types of certificate authorities (CAs), formats of the certificates and certificate revocation lists (CRLs). The distribution of all security certificates (including CRLs) is performed by the SCMS. ETSI defines architectures that applications can use to meet their security requirements [140]. In order to get access to the communication infrastructure and services, a vehicle first contacts an enrolment authority (EA) and authenticates itself. The EA replies with a set of pseudonymous certificates (to preserve the true identity of the vehicle as a privacy measure). These certificates validate that the vehicle can be trusted to function correctly within the network. To request permission for accessing a service, the vehicle contacts an authorisation authority (AA) using one of the pseudonymous certificates (that represents a temporary identity). The vehicle then receives a set of certificates in response (one for each requested service). Vehicles can only access a service if the AA authorizes it to use that service. The ETSI certificate format for V2X communications is also currently based on IEEE 1609.2. The ETSI-ITS security standards were divided into several technical reports/specifications that describe (a) the security architecture and management, (b) trust and privacy models, (c) threat vulnerability and risk analysis, (d) messages and certificates formats and finally, (e) PKI models and mapping with IEEE 1609.2. A summary of the ETSI-ITS security standardization activities is available in earlier work [106]. It is worth mentioning there exist services that are proposed by ETSI but not fully supported (or under development) in the SAE/IEEE (see Table I). A qualitative comparison of IEEE 1609.2 and ETSI-ITS standard is presented in prior research [60, 37]. ITS Forum in Japan also provides guidelines to ensure V2X security [75]: (a) use of encryption (i.e., chosen from the CRYPTREC [73] list of cryptographic techniques) to verify authenticity of the sender and the integrity of the messages; (b) if cryptographic keys have been leaked, the protocol must provide necessary countermeasures to minimize impact (and prevent further spread) and (c) information that stored in the vehicles/RSUs must be protected.

Security service ETSI-ITS IEEE 1609.2
Session management By maintaining a security association Not fully supported (on the fly association by identifying trust hierarchy)
Reply protection Timestamp message and insert/validate sequence number Timestamp message
Plausibility validation Supported by data/parameter validation Basic support (based on geographic location or message expiry time)
Misbehavior reporting Not-supported Not supported
TABLE I: Security service compatibility in ETSI and SAE/IEEE

Iii-B2 Harmonization Efforts

There were two harmonization task groups (HTG) established by the United States and Europian international standards harmonization working group [78]: (a) HTG1 – to harmonize security standards (e.g., from CEN, ETSI and IEEE) and promote cooperative V2X interoperability; and (b) HTG3 – to harmonize communications protocols. The goal of HTGs was to provide feedback for SDOs and identify areas where policy and/or regulatory actions can help to improve V2X security [45]. The harmonization efforts were completed in 2013 [76] and the reports/recommendations are publicly available online [22, 35].

Iv Security Threats in V2X Systems

Security threats to V2X systems depend on attacker’s capabilities and methods available to access the target (e.g., vehicle, RSU and communication channels). Incentives to destabilize V2X systems include [148]: (a) physical damage/vandalism (e.g., denial of service, causing an accident, undesired road congestion by traffic rerouting, etc.); (b) financial incentives (e.g., steal user’s private information, extract OEM intellectual properties, insurance fraud, etc.); and (c) non-monetary (e.g., enhancement of attackers traffic conditions, improved attacker reputation, etc.).

Iv-a Attack Variants

We first enumerate the attacker models that are used in the literature [129, 17, 34]. Various attacks to V2X systems can be active or passive – in the case of active attacks, the adversary actively interacts with the system while the passive attackers would eavesdrop on critical data (such as private key, certificates, sensor information, etc.) without directly interacting with the system and/or disrupting normal behavior. Examples of active attacks include false code/data injection, denial-of-service (DoS), alteration of transmitted data (e.g., GPS spoofing, broadcast/transaction tampering [92]), etc. In the V2X context, passive attacks could threaten a user’s privacy since it is possible to link V2X messages and vehicle movements to individuals. Attacks can be performed offline, e.g., when the system is not operational – these types of attacks often require physical access to the device. Online attacks, in contrast, can be performed by exploiting hardware/software/communication bugs at runtime. The attacker could be: (i) an authenticated member of the network allowed to communicate with other members and/or has system-level access444Not necessarily physical access to the system. (internal) – these attackers behave according to the underlying protocol but send false/tampered information or (ii) may not have valid credential/system access (external) – rather passively eavesdrop on the communication to infer sensitive information.

Iv-B V2X Attack Classifications

We now briefly review potential attacks on the V2X systems (see Fig. 11 for a high-level illustration). While there exist prior surveys [60, 136, 164] that discuss possible attacks for vehicular networks, in this paper we primarily focus on attacks that can be performed within the scope of existing V2X security mechanisms. In Tables III and II we summarize the possible attacks for V2X systems. The major attacks we focus on: (a) DoS (Section IV-B1), (b) Sybil (Section IV-B2) and (c) false data injection (Section IV-B3).

Attack Communication Scenario Remarks
Broadcast Multi-hop
Jamming Limited by the attacker’s communication range
Data flooding No routing/forwarding is involved in broadcast of BSM/CAM
Sybil Vehicles may forward wrong (DENM) messages received from Sybil node in multi-hop scenarios
Message replay Reduces network throughput especially for multi-hop scenarios

Legends:

(a) ✓The attack poses threats to the communication scenario and

(b) ✗The attack does not disrupt the communication scenario .

TABLE II: Attacks in Different Communication Scenarios
(a)
(b)
(c)
Fig. 11: Possible attacks scenarios of V2X with malicious (black) and victim (blue) vehicles: (a) DoS attacks: 1⃝ attacker floods message packets and 2⃝ jams the communication channel; (b) Sybil attacks: adversary creates two fake identities and send false messages; (c) false data injection: attacker sends incorrect information (e.g., about location, sensor data, object/pedestrian info, etc.).
Attacks Variants Network Stack
DoS:
   Routing-based Active, online, internal Network
   Flooding Active, online, internal Application, network
   Jamming Active, online, external Physical
Sybil Active, online, external/internal Application, transport, network, data link
False data injection Active, online, internal Application, transport, network, data link, physical
TABLE III: Major Threats to V2X Systems

Iv-B1 DoS Attacks

DoS attacks can happen in different layers of the network where an adversary sends more requests than the system can handle. For instance, an attacker could try to shutdown/disrupt the network established by RSUs and stop communication between vehicles and/or RSUs [136]. In a distributed DoS (DDoS) attack [154] malicious nodes launch attacks from different locations thus making it harder to detect. In the physical layer, an important type of DoS attack is the jamming attack [6] (refer to the related work [124] for detailed classification) where the attacker disrupts the communication channel (e.g., by electromagnatic interference) and can filter/limit incoming messages. Jamming functions well only in geographically restricted areas, i.e., say within the range of the attacker(s) wireless device. We also note that most jamming/DoS attacks on the PHY level (IEEE 802.11p) or the bands around 5.9 GHz are always restricted by the range of the attacker(s) and do not impact V2X communications everywhere. Jamming attack does not require any particular knowledge of the semantics of the exchanged messages [164]. Although jamming attacks are not specific to V2X systems (i.e., can be a threat for any wireless network), such attacks can increase the latency in the V2X communications and reduce the reliability of the network [125]. In the network layer, routing-based DoS attacks such as JellyFish attack [4] exploits vulnerabilities in congestion control protocols and the attacker delays or (periodically) drops packets (albeit does not violate protocol specifications). Packet dropping is catastrophic for safety-related applications – for instance, a vehicle involved in a traffic accident should propagate warning messages, but other vehicles could be prevented from receiving these warning messages by an attacker who intentionally drops/miss-routes packets. Another variant is the intelligent cheater attack [136] where an adversary obeys the routing protocol specifications but misbehaves intermittently. Such attacks require long term monitoring for detection [4] that could be impracticable for V2X scenario due to high mobility. Flooding attacks [136] such as data flooding (e.g., where an attacker creates bogus data packets and sends it to their neighbors) can make the network resources (e.g., bandwidth, power, etc.) unavailable to legitimate users. We note that these routing-based attacks can only be performed to multi-hop communication networks (e.g., not single-hop direct communications such as broadcasting BSM).

Iv-B2 Sybil Attacks

This is a well-known harmful attack in wireless vehicular networks where a vehicle pretends to have more than one identify (e.g., multiple certified key-pairs) either at the same time or in succession [182]. Sybil attackers may also launch DoS attacks, waste network bandwidth, destabilize the overall network and pose threats to safety [136, 11]. For instance, if a malicious vehicle changes its identity, it may use multiple pseudonyms to appear as a different, moving vehicle or make it appear that the road is congested (even though it is not) and send incorrect information about the road conditions to neighbouring vehicles/RSUs. A Sybil attacker could also use the pseudo-identities to maliciously boost the reputation/trust score (e.g., that use to measure how much neighbors can rely on information send by a given vehicle ), etc. of specific vehicles or, conversely, reduce the score of legitimate vehicles [164].

Iv-B3 False Data Injection

A rogue vehicle could generate false traffic/safety messages or incorrect traffic estimation information (that differs from real-world information) and broadcast it to the network with the intention of disrupting road traffic or triggering a collision 

[42, 136]. Sybil attackers can claim their existence at multiple locations and can thus inject false information in the network. By GPS spoofing an attacker could inject false position information by using GPS simulators and the victim vehicles may end up accepting these generated, fake, (but stronger than original) signals. Incorrect data such as falsified location information could decrease message delivery efficiency by up to approximately 90% [99]. Researchers have shown that cooperative adaptive cruise control (CACC) – an important V2X use-case – is specifically vulnerable to false data injection attacks [163, 7]. Another type of false data injection is replay attack where an attacker re-transmits messages to exploit the conditions at the time when the original message was sent (e.g., the attacker stores the event information and will resend it later, even though it is no longer valid) [59, 136]. For instance, in location-based replay attacks the attacker records an authenticated message at a location , transmits it quickly to a location (and re-broadcasts it at ). Similarly, in time-based replay attacks, an adversary records a valid message at time and replays it later (at the same location) at another time . For replay protection, there exist mechanisms such as: (a) including a time stamp in every message – say by using a global navigation satellite system (GNSS) [137] and/or (b) digitally signing and including sequence numbers [100, 106], etc. The V2X standards [72, 140] also provide mechanisms for replay protection: the maximum transmission delay of single-hop messages would need to be verified by receiving stations and messages with an outdated timestamp (or a future timestamp) should be considered as not plausible. Replay attacks in multi-hop V2X communication (i.e., DENMs) are related to routing misbehavior (e.g., where the attacker may deviate from the routing protocol and reroute messages to specific vehicles and/or drop messages) [60, 136]. While replay attacks (specially for multi-hop communications) can affect network throughput, support of infrastructures such as RSUs (and base stations for C-V2X) can reduce the impact of routing misbehavior [164].

V Misbehavior in V2X Communications

In V2X security literature researchers often use the term misbehavior [129, 130, 42, 136, 164]. This commonly refers to attacks that are executed by the malicious entity, e.g., a misbehaving node transmits erroneous data that it should not transmit when the system is behaving as expected. This is different than faulty nodes [98, 102, 83], i.e., when an entity produces incorrect or inaccurate data without malicious intent. While these definitions are not consistently used in literature, in this paper we use ‘misbehavior detection’ to refer to the uncovering of malicious entities. In the following, we (a) describe threat model and commons assumptions on adversarial capabilities (Section V-A and then (b) provide a summary of various misbehavior detection mechanisms (Section V-B).

V-a Threat Model

As we discussed in Section II, protection of wireless V2X communications by use of cryptographic credentials is a common approach. In the following we assume that the attacker has the credentials to communicate with other vehicles in the network (e.g., an internal attacker) and the attackers are able to distribute bogus information [133]. For instance, the attacker could send false information or conceal some information, tamper with its own message contents (e.g., event type/location, node position, etc.), generate false messages or bias another vehicle’s decisions (by sending erroneous messages). We also assume that the RSUs are trusted in general (although in Section VIII we discuss cases when we relax this assumption).

V-B Classification of Detection and Prevention Mechanisms

Fig. 12: Taxonomy of V2X misbehavior detection/prevention approaches. In Table IV we summarize how various classes of attacks can be detected by these approaches.

In Fig. 12 we illustrate various misbehavior detection/prevention approaches. V2X security approaches can broadly be characterized as proactive and reactive mechanisms [42, 164]. Proactive security refers to any kind of mechanism that enforces a security policy – say use of a PKI, digital signatures and certificates, tamper-proof hardware, etc.  This reduces the chances of bogus information exchange by unauthorized entities due to lack of credentials and can be maintained through a combination of infrastructure and tamper-proof hardware [82]. While these mechanisms reduce attack surfaces by detracting external attackers, insider attackers can generate legitimate false information. Such schemes also face scalability and complex management issues (e.g., key management, revocation, trust establishment in multi-hop communication). Reactive mechanisms can be enforced where the attacks cannot be prevented by proactive security policies. These mechanisms can be grouped into two classes: (a) entity-centric and (b) data-centric. Entity-centric approaches focus on identifying the misbehaving node generally based on trust establishment (say from past behavior/interactions) by using a PKI or in a cooperative manner (e.g., using signature verification). Data-centric approaches, in contrast, verify the correctness of the received data (instead of investigating the trustworthiness of the sender). Entity-centric detection approaches can be further subdivided into: (a) behavioral (e.g., observes patterns in the behavior of specific nodes at the protocol level) and (b) trust-based (e.g., evaluation of trust-score, often using a central authority to remove malicious nodes). Data-centric mechanisms are similar to intrusion detection in traditional computing systems that correlate the received information with the information already known from previous history/behavior. These approaches can be either: (a) plausibility-based (model-based approach that verifies if the information transmitted from a particular sender is consistent with the model) or (b) consistency-based (e.g., use information of packets – generally from multiple participants – to determine the trustworthiness of new data). We highlight that entity-centric and data-centric detection mechanisms are mostly orthogonal and often researchers propose to use combinations of both types. Depending on the scope, detection mechanisms can be: (a) local (e.g., performed locally, say by vehicle OBUs and not affected by detection mechanisms in other vehicles; or in the back-end by the RSUs) and/or (b) cooperative (detection relies on collaboration between vehicles/RSUs). In contrast to RSU-based mechanisms, OBU-based approaches do not need dedicated infrastructure (e.g., vehicles performing situation evaluation by themselves without any infrastructure). Researchers also proposed hybrid approaches where both RSU and OBUs are jointly involved in misbehavior detection (see Sections VI and VII). Behavioral and plausibility schemes generally operate locally while consistency and trust-based rely on cooperation among vehicles/RSUs to detect inconsistencies. Some consistency-based mechanisms can also be performed locally for more fine-grained detection with the cost of exposing them to Sybil attacks. We now briefly review the mechanisms to secure V2X communications from different classes of attacks (Sections VI and VII). Table IV summarizes the exiting solutions.

*The terms OBU-L, OBU-C and OBU-L/C represent whether a vehicle OBU performs decisions: (a) locally (OBU-L), (b) with the involvement of neighboring vehicles (OBU-C) or (c) using the combination of both (OBU-L/C). If any scheme requires assistance of infrastructure (CA, MA, etc. say for misbehavior reporting), we consider RSUs as the entry point to communicate with the back-end.

Reference Decision Involvement Approach Defense Against Key Idea Major Limitation(s)
Hamieh et al. [55], Lyamin et al. [109] OBU-L Entity-centric DoS (jamming) Detect patterns in radio interference to differentiate jamming and legitimate scenarios No attacker identification
Chuang et al. [30] OBU-C, RSU Entity-centric DoS (flooding, resource exhaustion) Use short-term key-pairs Extra message exchange overhead
He et al. [61], Studer et al. [151] RSU Entity-centric DoS (resource exhaustion) Use pre-authentication [61], alternative authentication mechanism with reduced memory/computation requirement [151] Increased communication latency
Hortelano et al. [64], Daeinabi et al. [33] OBU-L  [64], OBU-C and RSU [33] Entity-centric DoS (malicious packet dropping/forwarding) Predict the (expected) behavior of the neighbors by using a watchdog No privacy discussion and only detects malicious packet forwarding
Soryal et al. [146], Verma et al. [168, 169] RSU Entity-centric DoS (packet flooding) Monitor message exchange pattern Lack of scalability
Biswas et al. [18] RSU Entity-centric DDoS (packet flooding) Randomize message schedule of the RSU Does not work if the attacker can reproduce the randomized schedule
Hasrouny et al. [58] OBU-L/C, RSU Entity-centric DoS (packet flooding) Limit the number of accepted received messages by calculating a trust score Lack of implementation details and performance evaluation
Kerrache et al. [87] OBU-C, RSU Entity and data-centric DoS (packet flooding) Trust-based data verification and routing mechanism to eliminate misbehaving vehicles Stealthy attacker can bypass the detection mechanisms
Continued on next page.
TABLE IV: Summary of Misbehavior Detection Mechanisms for V2X Communications*

TABLE IV – Continued from previous page
Reference Decision Involvement Approach Defense Against Key Idea Major Limitation(s) Grover et al. [49] OBU-C Data-centric Sybil attack Compare neighbor-set of several vehicles over time Possible false-positive errors, no prevention for short-term Sybil attacks Hao et al. [57] OBU-C Data-centric Sybil attack Use correlation of mobility traces to identify Sybil nodes May not detect multiple Sybil attackers Golle et al. [46] OBU-C Data-centric Sybil attack Compare revived data with an expected model Require a suitable model to compare against, no validations or performance test is performed Guette et al. [51], Yao et al. [180] OBU-L Data-centric Sybil attack Link Sybil nodes through physical characteristics (e.g., RSSI) Infeasible with GPS errors [51], could be failed if attacker uses multiple radios [180] Ruj et al. [133] OBU-L, RSU Data-centric Sybil attack, position cheating Monitor and compare the messages with an expected behavioral model to analyze if such events are actually happened No validations or performance test, unrealistic assumptions Xiao et al. [177] OBU-C, RSU Entity-centric Sybil attack Analyze signal strengths of the received beacons No way to verify behavior of the ‘verifier’ vehicle Sowattana et al. [147] OBU-C Entity-centric Sybil attack Analyze validity of received beacons and generates trust score (of a given vehicle) through a voting mechanism Voting mechanism itself could be vulnerable to Sybil attack Park et al. [119] OBU-L, RSU Entity-centric Sybil attack Observe similarity of motion trajectories May not detect correctly for all scenarios (e.g., when two vehicles coming from opposite directions) Zhou et al. [186] RSU Entity-centric Sybil attack Link pseudonyms to common values using hash functions No privacy preservation for the central authority Hamed et al. [53] RSU Entity-centric Sybil attack Monitor mobility pattern of the vehicles Finding proper detection threshold, increase false positive/negative errors Chen et al. [27] OBU-C, RSU Entity-centric Sybil attack Exchange digital signature (that is periodically issued by the RSU) among neighbors and compare it with a reference trajectory Prone to false positive errors, high overhead, does not consider vehicle privacy Chang et al. [25] OBU-C, RSU Entity-centric Sybil attack Observe similarity of motion trajectories Potential false positives, geared towards urban networks only Lee et al. [94], Rahbari et al. [127] RSU Entity-centric Sybil attack Use session key-based certificates[94] or PKI/CA to compare reply messages received from RSU [127] Extra information exchange overhead (i.e., reduced throughput) Feng et al. [36] OBU-C, RSU Entity-centric Sybil attack Use short-term public key and pseudonyms Could collapse if RSUs/OBUs are compromised Chen et al. [28], Singh et al. [143] OBU-C [28], OBU-L and RSU [143] Entity-centric Sybil attack Use of specific certificates and cryptographically protected usage restriction of the credentials Extra computation/communication overhead Continued on next page.

TABLE IV – Continued from previous page
Reference Decision Involvement Approach Defense Against Key Idea Major Limitation(s) Kim et al. [88] OBU-C, RSU Entity-centric False event notification Filter messages based local sensor information and event specific data Highly application specific and depends on verified positions Cao et al. [23], Hsiao et al. [66], Petit et al. [121] OBU-C Entity-centric False event notification Determine the correctness of event reports through voting/consensus Weak attacker model, prone to Sybil attacks Ghosh et al. [43] OBU-L Data-centric False event notification Correlate future behavior from past events Requires specific driver behavior for validation (potential false positive/negative errors) Schmidt et al. [138] OBU-L/C Data-centric False data injection Build reputation through evaluating vehicle behavior Assumes a honest majority, no performance test Yang et al. [179] OBU-L, RSU Entity-centric False data injection Monitor vehicle behaviors by logging message transmissions Requires strong authentication and identification mechanism Lo et al. [105] OBU-L Data-centric False data injection Monitor sensor values/received messages and ensure validity using a rule database Shared rule database can leak information to the attackers Vora et al. [170] RSU Entity-centric Position cheating Perform position verification using multiple ‘verifier’ RSUs Vulnerable to targeted attacks Yan et al. [178] OBU-C Data-centric Position cheating Check consistency of messages from multiple sources (e.g., on-board radar, incoming traffic data, etc.) Performance overhead, lack of privacy Stübing et al. [150, 149], Jaeger et al. [79] OBU-L Data-centric Position cheating Analyze CAM message sequences and track the vehicles Computationally expensive, chances of (partial) privacy breach Sun et al. [155], Hubaux et al. [67] OBU-L [155], RSU [67] Data-centric Position cheating Verify position using physical properties (e.g., Doppler speed measurements  [155], speed of light [67], etc.) Additional hardware requirement [155], potential chances of replay attacks [67] Leinmüller et al. [97, 95, 96] OBU-C Data-centric Position cheating Verify positions by: (a) discarding packets if the distance is farther[97], (b) cooperatively exchange position information [95] (c) including additional checking [96] Limited detection capabilities Studer et al. [152] OBU-L Data-centric GPS spoofing Estimate current position based on previous calculations May cause approximation error Zaidi et al. [183] OBU-L Data-centric False data injection, Sybil attack Perform statistical analysis to analyze traffic flow Limited application scenario, Stealthy attacker may remain undetected Rawat et al. [128] OBU-L Entity-centric False data injection Predict vehicle behavior using Bayesian logic Potential classification errors, hard to obtain parameters Kerrache et al. [86] OBU-C, RSU Entity and Data-centric False data injection Obverve vehicle behavior by local and global trust scores May not work well if the adversarial behavior changes dynamically Raya et al. [130], Moore et al. [113] OBU-C Entity-centric False data injection Find deviations from normal/average behavior Prone to Sybil attacks, potential false positives Zhuo et al. [187] OBU-C, RSU Entity-centric False data injection Remove misbehaving insiders from local and global analysis Vulnerable to Sybil attacks

Vi DoS and Sybil Attack Detection

In this section we first present solutions to detect DoS attacks (Section VI-A) and then describe various approaches proposed in literature for Sybil attack detection (Section VI-B).

Vi-a DoS Detection/Mitigation

Since DoS attacks [131] can be implemented at varying layers, researchers proposed different solutions to detect/mitigate the changes of attacks. Jamming-based DoS attacks can be detected by behavioral mechanisms – for instance, by analyzing the patterns in radio interference [55] as well as by using statistical network traffic analysis and data mining methods [109]. The chances that (external) attackers to intrude/disrupt the system can also be reduced by using short-time private-public keys with a hash function [30]. He et al. [61] proposed to use a pre-authentication process before signature verification to prevent DoS attacks against signature-based authentication (where attackers broadcast forged messages with invalid signatures – leading to unnecessary signature verifications). Researchers also proposed alternatives to digital signatures – a new authentication method (called Tesla++) [151] that reduces the memory requirement at the receiver for authentication and can be used to limit the chances of resource (e.g., memory) exhaustion. A downside of these protocols is a high delay between message arrival and message authentication. Given the fact that the routing in V2X is predictable and standardized, network layer DoS attacks such as packet dropping can be detected by watchdog mechanisms [64] where each vehicle uses the idea of neighbor trust level (determined as the ratio of packets sent to the neighbor and the packets are forwarded by the neighbor). Packets may not be forwarded due to a collision and/or an attack. If a vehicle is repeatedly dropping packets (until a tolerance threshold is exceeded), the vehicle is considered as malicious – although the evaluation results show that it is difficult to find a global threshold (e.g., for deciding when misbehavior should be detected). Packet dropping/duplication can be prevented by clustering based monitoring [33] where a set of vehicles in a cluster (called verifiers) monitor the behavior of a (newly joined) vehicle. Vehicles that acted maliciously are blocked by certificate authority (CA) and are informed other vehicles. There exist mechanisms [146] to detect flooding-based DoS attacks by observing channel access patterns – for instance, by generating an adaptive threshold (that represents the maximum rate of messages any vehicle can send with respect to other vehicles). This approach may not be scalable for generic use-cases since the scheme is designed for vehicles communicating with a single RSU. Similar infrastructure-assisted mechanisms such as those proposed by Verma et al. [168, 169] can prevent DoS attacks by: (a) monitoring V2X messages (that checks the number of outstanding packets with a predetermined threshold within a certain window of time); or (b) by using a message marking policy where packets are marked by the edge routers (say RSUs) and if the sender IPs are found malicious, an alarm is sent to other vehicles. Recent work [18] proposed to randomize the RSU packet transmission schedule and a modification of the congestion control schemes to mitigate packet flooding-based DoS/DDoS attacks. Message flooding can also be detected by trust-based mechanisms [58, 87]. Hasrouny et al. [58] propose to calculate trust values of the vehicles that can limit the number of accepted received messages from neighbors – if a certain threshold is exceeded (which will be the case in DoS attack), a report is sent to the trusted entity, say misbehavior authority (MA) [21], to deactivate the attacker. The TFDD framework [87] can detect DoS and DDoS attacks in a distributed manner by trust establishment between vehicles. Each vehicle maintains local and global parameters (e.g., neighbor id, various message counters, trust score) in order to include/exclude neighbours from a local or global black-list. A globally blacklisted vehicle can be suspended from network operations by the trusted authority [184]. The proposed mechanism may not work for an intelligent, stealthy attacker whose (malicious) behavior may not remain stable throughout time.

Vi-B Detecting Sybil Attacks

Researchers proposed to detect Sybil attacks in V2X networks that can work either (i) without any infrastructural support [49, 57, 46, 182, 51, 133] (Section VI-B1) or (ii) with assistance from infrastructure (e.g., RSU, PKI, trusted authority) [177, 147, 25, 186, 27, 119, 53, 94, 127, 36, 143] (Section VI-B2).

Vi-B1 Infrastructure-less Sybil Detection

Grover et al. [49] suggest that the fake identities of the attacker must always be in the same vicinity (for better control over malicious nodes) and proposed a detection by comparing the tables of several neighboring vehicles over time. This scheme does not protect against Sybil attacks that have a short duration. The communication overhead and detection latency is high, and certain scenarios (e.g., traffic jams) may increase false positives or detection latency. Hao et al. [57] proposed a cooperative protocol that utilizes group signature (to preserve privacy) and correlation of mobility traces. The key idea is that vehicles around a possible attacker inform others by broadcasting warning messages with their partial signatures – a complete signature can be derived (and hence the attacker is identified) when the number of vehicles that report anomalies reaches a threshold. The protocol is not verified for the case of multiple Sybil attackers. A model-based approach, based on position verification, is proposed by Golle et al. [46] where each node contains a model of the network and checks the validity of the received data using local sensors (i.e., camera, infrared and radars). Data collected from the sensors can be used to distinguish between nodes. Inconsistencies can then be detected (i.e.,

in case of Sybil attacks), based on the proposed heuristic mechanism, by comparing the received data with the model. For instance, using a camera reading and exchanging data via a light spectrum a vehicle can verify whether a claimed position is true. Thus one can determine the real existence of the vehicle. However it is generally hard to obtain a generic model of the V2X network due to the dynamic nature and the proposed method is designed by considering high density road conditions only (

i.e., may not perform well for low density situations or roads where vehicle density varies over time). Researchers also proposed the identification of falsified positions by exploiting channel properties, for instance, by analyzing its signal strength distribution [182, 51, 177] or by observing RSSI (received signal strength indicator) measurements [180]. A Sybil detection approach [51] analyzes physical layer properties under the assumption that antennas, gains and transmission powers are fixed and known to all the vehicles in the network. The authors use received signal strength to determine the approximate distance to the sender and further verify the transmitted GPS position. A similar idea is also used [133] to verify locations by finding the co-relation between location, time and transmission duration (for both beacons and event messages). A post-event validation approach verifies specific event messages (by analyzing messages from other vehicles) and also pseudonym change mechanism is applied once a claimed event is detected as being malicious (e.g., that is detected by a lack of subsequent beacon messages from the same source). This scheme, however, can be exploited to revoke legitimate vehicles by an attacker with jamming capabilities (since they are based on physical-layer signal properties) [164]. Prior work [51, 133] also do not account for GPS errors in the model. A distributed mechanism, Voiceprint [180], was proposed to detect Sybil attacks by analyzing RSSI (received signal strength indicator)-based measurements (e.g., by performing a similarity measures between the RSSI of an attacker and its Sybil nodes over time). However Voiceprint may not detect attacks if an adversary uses more than one radio.

Vi-B2 RSU-assisted Sybil Detection

There exist mechanisms [177, 147, 25, 186, 27, 119, 53, 94, 127, 36, 143] to use a centralized authority (e.g., RSU) to detect Sybil nodes. In an earlier study Xiao et al. [177] verify claimed positions using signal strength metrics where vehicles are assigned three roles: (i) claimer (a vehicle claims a position using a beacon), (ii) witness, (a node receives a beacon and measures its proximity using the received signal strength that is then transmitted in subsequent beacons) and (iii) verifier (the vehicle that collects signal strength measurements to estimate and verify the position of a vehicle). RSUs issue signatures of vehicles in their proximity at a specific time along with a driving direction. When a beacon message is received, the verifier waits for a period of time (to collect previous measurements of the claimer from witness) and calculate an estimated position of the claimer. A similar idea is used in a consensus-based Sybil detection scheme [147]: each receiver validates the validity of received beacons by transmission range of those neighbors and generates a trust score using a voting scheme. The voting process itself, however, is vulnerable to the attack. Researchers also proposed [119] to use message timestaps (e.g., to find each vehicle’s recent trajectory and time) for Sybil detection that do not require any PKI. Before sending any messages, a vehicle first obtains a timestamp for the message from a nearby RSU. If a vehicle receives similar timestamp series from the same RSUs for a certain amount of time then that vehicle is considered as Sybil node. However two vehicles coming from opposite directions could be incorrectly marked as Sybil nodes since they will receive similar timestamps for a short time period. The P2DAP framework [186] detects Sybil attacks by identifying vehicles with different pseudonyms and propose an inherent linking between pseudonyms based on hash functions. For instance, a message is considered malicious if the tuple, (time, location, event type), is signed by the same vehicle with different pseudonyms. The (semi-trusted) RSUs are responsible for checking messages the linking and reports it to the central authority (that can resolve pseudonymity). However the ability to link arbitrary pseudonyms may be a privacy issue. Time and spatial granularity as well as event types needs to be standardized and also the central authority requires the complete knowledge of the network. Similar architecture was used in recent work [53]. It leverages the fact that two vehicles may not pass multiple RSUs at the same time. The authors proposed to detect Sybil nodes by monitoring mobility patterns of vehicles. This scheme requires a global view of the network and also the estimation of a proper detection threshold is not straightforward (may result in false positive/negative errors). Chen et al. [27] identify that Sybil nodes that originate from the same vehicle will always have similar trajectories over time. With this observation a new protocol uses special signatures (obtained from RSUs) that can be used to build a reference trajectory. Identities with identical recent trajectories are considered to be the same vehicle thus minimizing the effect of Sybil attacks. However there exists practical limitations: (a) bandwidth overhead for signature exchanges; (b) potential chances of DoS attacks – since each request requires a much larger response (e.g., the signatures) and (c) privacy violations – vehicles need to reveal their position traces (i.e., set of signatures) to verify themselves as non-Sybil nodes. The ideas were also extended in the privacy preserving Footprint framework [25] where cryptographically protected trajectories (consisting of special signatures) are requested by the vehicle from the RSUs. The trajectories for every message are used as an authentication mechanism that allows a vehicle to compute the Sybil nodes (e.g., when all trajectories that are suspiciously similar are coming from a same vehicle). Footprint protects vehicle privacy (e.g., from long-term tracking) since signatures of RSUs are time-dependent (and unpredictable). Another privacy-preserving protocol – DTSA[94] uses session key-based certificates where each vehicle’s (unique) ID is registered to a global server. The vehicles then generate anonymous IDs that are validated by a local server (and a local certificate is issued). Any receiving vehicle can verify the message by comparing the other vehicle’s true identity with the local server. This scheme may reduce network throughput since certification exchanges require a large amount of overhead data. Similar ideas exist in earlier work [127] that utilizes PKI and a local CA to detect Sybil attacks by comparing the reply message received from the RSU. More recent framework EBRS (event based reputation system) [36] proposed to use short-term public key and pseudonyms that needs to be validated by a trusted authority (e.g., by using RSUs). While EBRS can detect attacks from multiple sources, this framework may collapse if the RSUs and/or OBUs are compromised. Researchers also proposed to use anonymous credentials (i.e., a specific certificates) and a cryptographically protected usage restriction of the credentials – since the sender is allowed to use only one credential per time Sybil nodes then can be detected [28, 143]. However the performance overheads of these approaches are high compared to the ECDSA algorithm proposed in the standards [72, 140].

Vii Integrity Checking

The integrity of V2X communication can be verified from different contexts such as: (i) validating events (Section VII-A), (ii) checking message integrity (Section VII-B), (iii) location verification (Section VII-C) and (iv) reputation analysis (Section VII-D) as we discuss in the following.

Vii-a Event Validation

Kim et al. [88] propose a message filtering mechanism that combines parameters of messages into a single entity called the ‘certainty of event’ (CoE) curve. CoE represents the confidence level of a received message and is calculated by combining the data from various sources such as local sensors and RSUs and by using consensus mechanisms (e.g., messages from other vehicles and validation by infrastructure, if available). Message validity is defined using a threshold curve and false positives for events can be reduced when more evidence is obtained over time. While the mechanism is applied to the the emergency electronic break light application (e.g., that enables broadcasting self-generated emergency brake event information to nearby vehicles), it unclear how this scheme behaves for generic V2X applications (say for multiple lanes and urban settings where there may be some uncertainty about the vehicle paths) since it requires specific locations for the events. Besides, such CoE-based mechanisms could be vulnerable to Sybil attacks depending on how the information from other sources are captured. Researchers also proposed to determine the correctness of event reports through voting [23] – the key idea is develop an efficient way to collect signatures from a sufficient number of witnesses without adding too much (bandwidth) overheads on the wireless channel. If insufficient signatures are received, events may be missed completely (i.e., may cause false negative errors). A similar idea is also used by Hsiao et al. [66] where the senders collect a number of witnesses for each possible event. However this model enforces a specific message format and there is no deflation protection, i.e., the attacker can reduce the amount of signatures attached to the message and/or can hide events. A consensus-based mechanism is proposed [121] where each vehicle collects reports about the same event from neighboring vehicles until a certain threshold of supporting reports is passed (after which the message is considered to be trustworthy). The proposed method allows the system to reach a decision within a bounded waiting time and thus suitable for time/safety-critical applications (e.g., the decision whether to trust the warning about traffic accident that must be made early so that the vehicle can slow down or change lanes accordingly). Similar to the most consensus-based mechanisms, this approach also suffers from potential Sybil attacks. The idea of post-event detection [43] can also be used for event validation: for instance, in post-crash notification (PCN) applications, once a PCN message is sent drivers adapt their behavior to avoid crash site and this information (e.g., drivers behavior) can be used to identify whether the event was valid or not. The key idea is to use a technique (called root cause analysis) to detect which part of the event message was false (e.g., upon receiving a PCN alert, the vehicle analyzes the sender’s behaviors for a while and compares the actual trajectory and the expected trajectory). Such detection approaches suffer if the driver behavior models are fragile – although this may not be a limiting factor for autonomous driving where valid driver behavior will be more well-defined.

Vii-B Behavioral Analysis and Message Integrity Checking

The VEBAS (vehicle behavior analysis and evaluation scheme) protocol [138] allows the detection of unusual vehicle behavior by analyzing all messages received from neighboring vehicles. VEBAS uses a a trust-based mechanism, e.g., once a vehicle has collected information about surrounding vehicles, it will then broadcast the results (e.g., trust-scores) within the single hop neighborhood. This checking mechanism uses a combination of behavioral mechanisms (e.g., frequency of sending beacons) and physical parameters such as velocity and acceleration to determine the authenticity of a message. However VEBAS could be vulnerable since there is no mechanism the verify the correctness of the messages received from the neighbours. The MisDis protocol [179] ensures accountability of vehicle behaviour by recording all the (sent/received) messages for each vehicle peer in a secure log. Any vehicle can request the secure log of another vehicle and independently determine deviation from expected behavior. This protocol, however, requires strong identification and authentication mechanisms and there is no discussion about how the vehicle privacy is preserved. Also authors do not provide any performance evaluation of the proposed method. Lo et al. [105] propose a plausibility validation network (PVN) to protect the V2X applications from false data injection attacks (called illusion attacks) where attacker can indirectly manipulate messages (e.g., through sensor manipulation). The idea is to use a rule database (e.g., a database of rules specifies whether a given information should be considered valid or not) and a checking module that checks the plausibility of the received messages. Each message is evaluated with respect to its type (accident report, generic road condition) and the corresponding predefined rule set is retrieved from the rule database to check the value of the message element fields (e.g., timestamp, velocity). For instance, the plausibility of the timestamp field is checked by determining the minimum and maximum bounds e.g., the received timestamp must be earlier than the receiver’s current timestamp and later than the difference between the and the validity period of the message. A limitation of this approach is that since the rule database is shared, a malicious vehicle can generate valid messages to avoid detection.

Vii-C Location and GPS Signal Verification

Researchers used different techniques to predict the position and behavior of vehicles (e.g., whether they follow an expected pattern) in order to identify malicious vehicles. One idea is to verify node positions using two verifiers [170]: acceptors (distributed over the region) and rejecters (placed around acceptors in circular fashion) – say for a given region, by using multiple RSUs (rejectors) surrounding one (center) RSU (acceptor). If the message is first received by the acceptors, then they will verify that the vehicle is within the region. However a malicious vehicle can spoof its location when it resides within the region since the protocol does not verify the exact location of the nodes. Yan et al. [178] proposed to use on-board radar to detect the physical presence of vehicles (e.g., for applications such as a congestion alert system). The vehicles compare radar information (e.g., which vehicles are in proximity) with the GPS information received from other vehicles to isolate malicious nodes. The mechanism can prevent some variants of Sybil attacks, e.g., by calculating the similarity of radar information, reports from neighbours and oncoming traffic reports. There exist mechanisms [150, 79] to verify transmitted CAMs by analyzing the sequence of messages (e.g.,

to find the trajectory of each vehicle). By tracking a vehicle (say by using a Kalman filter

555Kalman filters can accurately predict the movement even under the influence of errors – for instance, they can be used to correct errors in GPS measurements [164].), the receiver can verify the location contained within each CAM. The idea is extended [149] to applications where the accuracy of the Kalman filter is poor (e.g., for special maneuvers or lane changes scenarios). A signature-based scheme [16] based on a plausibility checking is proposed where each vehicle is modelled as differently sized (and nested) rectangles – intersecting rectangles that belong to different vehicles indicate false position information. Since the readings from positioning systems (i.e.,

GPS) could be inaccurate, the probability of intersections is calculated by intrusion certainty (based on the number of observed intersections) and trust values (

e.g., using minimum-distance-moved concept [138] where any neighboring vehicle who is further than a given vehicle’s transmission range is considered more trustworthy). When intersects with another neighbor and the difference between trust levels of both vehicles is higher than a predefined threshold then the less trustworthy vehicle is considered to be malicious. While this method can detect false positions despite GPS errors, an attacker with larger transmission ranges (compared to other vehicles) can bypass this mechanism. Vehicle positions can be verified by physical properties such as Doppler speed measurements of the received signal [155]. The idea is to use the angle of arrival (AoA) and Doppler speed measurements. When this information is combined with the position information included in the message, the estimation error (calculated using an extended Kalman filter based approach) should not diverge unless the vehicle misbehaves by transmitting false location information. Another approach to verify vehicle position is distance bounding [20] – a technique to estimate distance using physical characteristics such the speed of light. Since light travels at a finite speed, an entity (e.g., RSU or other vehicle) can measure the (round-trip) time to receive a message and determine an upper bound on the vehicle distance. By using distance bounding mechanisms Hubaux et al. [67] show that RSUs can verify a vehicle’s location when: (i) three RSUs are positioned to form a triangle (for a two dimensional plane) or (ii) four RSUs form a triangular pyramid (for a three dimensional plane). In a similar direction, researchers proposed a data-centric mechanism to verify false position information using timestamps [133]. For example, when location information (timestamped at ) is received by a vehicle (located at ) at time , the receiver can verify the correctness of this information using the locations, speed of light and the difference between timestamps. A malicious vehicle cannot modify timestamps (say ) since the exact location between the attacker a receiver vehicle is unknown. When a false location is detected the receiver broadcasts this information to other vehicles (and perhaps to the CA via RSU). An attacker can send delayed responses to each RSU [67] (e.g., by using directed antennas), An alternative trust-based position verification approach is proposed where a vehicle discards packets if the included position information is further than the predefined maximum acceptance range threshold [97]. Since the recipient negatively weighs abnormal observations (e.g., the sender’s trust level is more affected by abnormal observations), after sending one bogus information packet a (malicious) vehicle is required to send correct information packets in order to regain its previous trust level. Similar ideas can be used by exchanging position beacons among neighbors [95], i.e., beacons received from neighbors are checked against received neighbor tables by comparing the (claimed) positions for a particular node in the beacon and the table. These mechanisms can be improved by (i) ignoring further beacons when too many of them are sent from one area (e.g., to limit the impact of potential Sybil attack) (ii) map-based verification (e.g., by assigning a plausibility value to the received beacons by comparing the location to the road map) and (iii) position claim overhearing (e.g., for geo-routing scenarios by comparing different overheard packets and respective destinations can provide indications of a false position in the past) [96]. All of these checks, however, may not perform well individually [165]. There exist mechanisms to detect GPS spoofing by dead reckoning, e.g., where the current position is calculated by using a previously determined position and known (or estimated) speeds over elapsed time [152]. While this method can detect spoofed GPS information, the calculated position is only an approximation. For details of GPS spoofing countermeasures and recent proposals we refer the readers to further related work [19, 137].

Vii-D Reputation Analysis and Revocation

Researchers have also proposed mechanisms such as statistical analysis and explicit voting to decide trustworthiness of the vehicles. Zaidi et al. [183] use statistical techniques to predict and explain the trends in traffic flow and determine whether or not a sender is malicious. Each vehicle estimates its own flow parameter (that should be similar for vehicles located closely to ) by using a model (that uses vehicle density per and the average speed of other vehicles in its vicinity). Vehicles exchange their own flow parameters, density values, speed and location information. For each received message, vehicles compare the average of the received parameters to its own calculated parameters – if the difference is lower than a predetermined threshold then the message is accepted; otherwise, the behavior of the sender is monitored (i.e., only accept messages until it is enough to perform a statistical test). The malicious vehicle will then be reported to other vehicles and isolated from the network. A stealthy attacker (one who manipulates values gradually), however, may remain undetected. An approach using Bayesian logic has proposed to compute the ‘probability of maliciousness’ of a vehicle for a time , given some observation  [128]. The idea relies on Bayesian reasoning, i.e., computing the probability of the vehicle being malicious given (e.g.,

by applying Bayes’ theorem). This scheme requires prior knowledge of the probability of reception of a particular message and the authors do not specify how these conditional probabilities can be obtained for generic V2X use-cases. The T-VNets framework 

[86] evaluates two trust parameters: (a) inter-vehicles trust (e.g., by combining data-centric evaluation of messages received from each neighbor) and (b) RSUs-to-vehicles trust (built by collecting reports from vehicles about their neighbor’s behaviors – to build a quasi-global historical and regional trust value). The authors propose to periodically exchange global trust values by adding the addition of new fields to the CAM messages. Besides, DENMs are used to dynamically calculate the trust for specific events (e.g., road hazards) – the events that have a lower trust value than a predefined threshold will not be broadcast by the vehicles. However the authors assume attackers always and persistently exhibit dishonest behavior throughout time and that may not be the case in practice. Raya et al. [130]

proposed LEAVE (local eviction of attackers by voting evaluators): an entropy-based measurement with k-means clustering to detect which neighbor differentiates from other neighbors (

e.g., a misbehaving vehicle) – say if high velocity information received from a neighboring (malicious) vehicle is contradictory to messages from the majority of vehicles (e.g., for a traffic jam situation) then the malicious vehicle will be detected. Vehicles exchange ‘accusations’ about potential attackers and the malicious vehicle can be evicted temporarily (by revoking its certificate). A core advantage of LEAVE is the reduced detection latency (since vehicle trust does not need to be built over time). A similar idea is also proposed by Moore et al. (called Stinger) [113] in which both the reporting as well as reported vehicles are temporarily prohibited from sending messages. Both LEAVE and Stinger protocols require an honest majority – if there exists too many compromised neighbors then they could present malicious behaviors as normal (e.g., vulnerable to Sybil attacks). Zhuo et al. [187] proposed a cooperative local and global eviction mechanism: SLEP (a so-called suicide-based eviction mechanism that is designed to discourage false accusations) and PRP (that uses trust level of each accuser to decide on permanent revocation) respectively, to remove misbehaving vehicles. The basic idea is that if a vehicle can detect bogus messages (say by comparing on-board sensor information about the event), it will broadcast a message accusing the potential attacker vehicle (and the neighboring vehicles will then ignore the messages from accused vehicle). In contrast to other work [130] a vehicle can use pseudonyms (i.e., to protect privacy) and can re-join the network after a successful accusation. Limitations of exiting revocation schemes include [104]: (a) they assume a local honest majority and if an attacker manages to create a local majority (that is the case of Sybil attacks) then it is possible to create false accusations (and falsely remove honest vehicles from the network) and (b) when pseudonyms are used (i.e., to protect user privacy) an attacker can use multiple pseudonyms in parallel to create a local majority. For voting-based schemes researchers therefore suggest not to use multiple pseudonyms in parallel (i.e., they should be prevented by the underlying pseudonym mechanism) [104].

Viii Discussion

In this section we briefly highlight open issues both for IEEE 802.11p-based (Section VIII-A) and LTE-based V2X communications (Section VIII-B). We then review security issues related to low-level protocols running within a vehicle (Section VIII-C).

Viii-a Open Issues and Design Considerations

As we mentioned in Section IV-B, the robustness of V2X technology (due to predefined packet authentication and use of timestamps) mitigates the severity of spoofing attacks (e.g., replay or man-in-the-middle attacks). While the use of digital signatures and PKIs have been widely studied and standardized for V2X communication, there is a gap between existing academic research and large scale practical testing of PKI for V2X applications. It requires further investigation and experiments to discover (and resolve) potential issues including ambiguous specifications in standards, equipment interoperability from different vendors and scalability [93]. There exists a trade-off between different aspects such as false positive rate, CRL size, complexity, RSU availability. In addition, most of the existing V2X security solutions are known for their high computation and delay overheads (see Sections VI and VII). We also observe that (a) experimental evaluation and benchmarking of these security solutions have only been conducted under limited operating conditions and (b) there exists a lack of evaluation, comparison and feasibility study for the existing methods. An important problem in V2X security solutions is that of configurations. For instance, after what threshold should a message/event/activity should be considered as malicious? This is itself an important research challenge since high false positive/negative rates can easily destabilize any security technique. There are still remain open questions regarding CRL distribution and pseudonym change strategies. Modern traffic analysis techniques can also examine traffic patterns and extract location information [181]. However, in order for an attacker to track a vehicle based on BSM/CAM, an attacker needs to follow the transmitter vehicle to be in close proximity. Pseudonyms may not be sufficient to prevent location tracking since an attacker can infer complete travel paths by combining pseudonyms and location information [174]. While most of the related work focuses on detecting misbehaving vehicles, designing efficient response mechanisms still an open issue – this is crucial especially for DoS/DDoS attacks where it is almost impossible to respond to the attack. Often solutions proposed in literature assume RSUs are fully trusted [146, 168, 169, 61, 151, 18, 177, 147, 25, 186, 27, 119, 53, 94, 127, 36, 143, 170]. This may not always be the case in practice since RSUs are deployed roadside and may be susceptible to physical attacks (e.g., sensor tampering, differential power analysis). Therefore, there is a requirement for layered defense mechanisms that consider potentially vulnerable RSUs. Another (perhaps less technical) challenge is that of widespread implementation (e.g., installation and maintenance) of V2X-compatible infrastructure and vehicular fleets – the costs for RSUs and the PKI could be one of the biggest obstacles for full V2X deployment [110].

Viii-B Security Issues for LTE-V2X

3GPP recognizes the need for user authentication (e.g., only authorized entities should be able to transmit data) and suggests the processing of messages whose data origin has been verified by the vehicle [3]. 3GPP also states that vehicle identity should not be long-term trackable or identifiable from its transmissions. To achieve this, permanent identities of the vehicles need to be properly protected (and also exposure minimized say by using pseudonyms). This is important since fake base-stations can force legitimate vehicles to share their IMSI (international mobile subscriber identity) and/or location information [117] and thus could be vulnerable to multiple classes of attacks (e.g., Sybil and data injection). While the use of temporary pseudonymous certificates (for vehicle authentication) provide a measure of privacy for DSRC/C-ITS, the association with a subscriber ID in LTE-V2X pose a threat of potential compromise of vehicle privacy, especially considering cellular network operators [110]. Although 3GPP Release 14 (TS33.185) [2] specifies security requirements for LTE-V2X, the specifications do not yet impose any privacy mechanisms for the LTE-V2X PC5 (leaves this to the regional regulators and operators). While 3GPP suggests changing and randomizing the layer 2 ID and IP address of the source (along with changing the application layer ID), there is no additional protection for the Uu apart from what current LTE networks support. There also exist unique issues of LTE-V2X (e.g., maliciously mimic and/or control behavior of the base stations) due to centralized control in Uu-based LTE-V2X and PC5 mode 3. For example, if an attacker gains control of base stations, the attacker can (a) fully control scheduling of Uu-links as well as sidelinks (PC5 mode 3), (b) allocate collided resources to vehicles to degrade the communication performance, (c) provide a wrong network configuration to the vehicles and (d) obtain location information. LTE-V2X PC5 mode 4 and DSRC/C-ITS, however, are not vulnerable to such issues as they operate in a fully distributed manner.

Viii-C Threats to Intra-vehicle Components and Countermeasures

Modern vehicles are equipped with a swarm of sensors, camera, radar, LiDAR that can be tampered by the adversary. Possible attack surfaces (i.e., from where the attack could originate) include [122]: (a) vehicle sensors, e.g., acoustic sensors, odometric sensors (such as wheel encoders, accelerometers, gyroscope), radar, LiDAR and vision systems (used for object detection), GPS modules (used for localization and positioning) and (b) in-vehicle user devices that can be connected to the infotainment system via Bluetooth/WiFi/USB. Although intra-vehicle (e.g., on-board) attacks are not directly related to communication/network security, such attacks could prevent the vehicle from operating normally and destabilize V2X communication networks. For instance, intra-vehicle attacks such as side-channel attacks can lead the attacker to infer the secret information (e.g., cryptographic keys) [80] or DoS attacks (e.g., that disables the steering/braking/LiDAR/camera system in an advanced driver assistance systems and automated driving systems) could disrupt the normal operation of the vehicle and/or pose threat to human safety [8, 112, 122, 129]. Recent work on the security of controller area networks (CANs) [62, 26, 89] – the in-vehicle communication bus used in some vehicles – has shown that they are vulnerable to such attacks. Given the fact that the vehicles in the V2X network can be connected to untrusted mediums such as Internet (e.g., by RSUs), and therefore, the sub-systems, ECUs/OBUs could be remotely compromised/controllable [112, 176, 74]. One way to address this problem is to use a central gateway that enables secure and reliable communications among a vehicle’s electronic systems [144, 12]. One of the major concerns for securing in-vehicle architecture is to protect the hardware and applications running inside ECUs. Researchers has proposed different techniques such as: (i) use of hardware security modules (HSMs) for secure boot, processing and storage [9]; (ii) various isolation mechanisms (e.g., by using virtualization, container, microkernel, etc.[48, 153]; (iii) hardware/software architecture for over-the-air (OTA) updates [69]; (iv) statistical analysis of ECU firmware images by reverse engineering to detect misbehaving ECUs [31], etc. to name but a few. Despite the isolation mechanisms, vehicles may still remain insecure due to implementation bugs and/or poor isolation policies. Besides, verification of policies/implementations requires enormous effort for such complex automotive platforms. Given the vulnerabilities of the CAN bus [26, 118, 115], a number of mechanisms have been proposed: (i) encrypting CAN messages and hiding system states to protect against selective DoS attacks [44]; (ii) use of authentication schemes (for both ECUs and CAN messages) to ensure their integrity [175, 116, 166, 50, 101, 126, 188]; (iii) use of asymmetric cryptography and certificates to authenticate ECUs and share symmetric keys [114]. Researchers have also studied the use of behavioral-based intrusion detection systems (IDS) for in-vehicle networks. However, building such IDS for in-vehicle networks is challenging due to the large number and heterogeneity of ECUs as well as due to limited information exposed by CAN messages (since they are specific to manufacturers and/or vehicle model) [93]. While there exist IDSes for in-vehicle networks (e.g., by utilizing message frequency [63, 145, 157], entropy [111]

, clock skew 

[29], observing cyber-physical contexts [173]) these systems may not be able to detect attacks involving sporadic/irregular CAN messages. Researchers also proposed to replace the CAN technology and use other alternatives such as Ethernet [15, 159, 56]. While earlier work focus on improving bandwidth and reducing latency/error rates, the impact of Ethernet on vehicle security is not thoroughly investigated and require further research. We also highlight that CAN will most likely remain as the most common in-vehicle networking technology over the next decade [56]. Replacing CAN will not solve all security/privacy issues and security measures (such as IDSes) built on top of CAN will remain applicable even when CAN has been replaced [93].

Ix V2X Security Projects and Related Work

The vehicular communication sector has been widely studied. In this section we first provide a list of main academic and industrial research projects actively working on various aspects of V2X security (Section IX-A). We then summarize related surveys that discuss security and privacy issues in the context of V2X applications (Section IX-B).

EVITA simTD OVERSEE PRESERVE ISE CAMP-VSC6
Project focusa OBS CNS OBS OBS and CNS CNS CNS
Objective On-board intrusion detection/prevention Secure V2X communications Secure and standardized communication/application platform Close-to-market security/privacy solution for inter-and-intra-vehicle networks Privacy-preserving message authentication Security credential management and misbivevior detection
Evaluation approach Proof-of-concept implementation Field trial, simulations, conceptualb Proof-of-concept implementation Proof-of-concept implementation, simulations Proof-of-concept implementation Conceptualb, prototype development (ongoing)
Reuse of existing projects No No Yesc Yesd No No
Use of PKI N/A Yes N/A Yes Yes Yes
Initiative European Union Germany European Union European Unione France United States
Status Completed (2008-2011) Completed (2008-2013) Completed (2010-2012) Completed (2011-2015) Completed (2014-2017) Ongoing (2016-present)

aScope of the security analysis – OBS: Intra-vehicle (on-board) security, CNS: Inter-vehicle (communication/networking) security.

bConceptual/analytical/architectural demonstration of the system components – not implemented/verified/tested on real systems.

cUsed the concept/implementation of hardware-based security module from EVITA project.

dReused various components from multiple past projects (e.g., EVITA, simTD, etc.)

eCAMP consortium was also a supporting partner of this project.

TABLE V: Qualitative Comparison of the Major V2X Security Projects in Europe and United States

Ix-a V2X Security Projects

During the last decade there has been the rise of several research and development projects focusing on securing V2X communications with a view to design, analyze and test suitable security mechanisms. Table V summarizes a comparative study of the various V2X security projects in the United States and Europe. The EVITA project666https://www.evita-project.org/ aims to develop a secure internal on-board architecture and on-board communications protocols to prevent and/or detect illegal tampering. It also considered legal requirements of on-board networks with respect to privacy, data protection and liability issues. The simTD project777http://www.simtd.de investigated the contribution of secure V2X systems for improving traffic safety and mobility using real-world field tests. The project developed different concepts, protocols, cryptographic procedures and privacy preserving mechanisms for the V2X field trials. The OVERSEE project888https://www.oversee-project.com/ proposed a secure, open in-vehicle platform, for the execution of OEM and non-OEM applications. This project aims to develop protected runtime environments (for the simultaneous and secure executions) by providing isolation between independent applications. It also proposes to provide a secure interface from the outside world to the internal network of the vehicle. The various security and privacy aspects (e.g., performance, scalability, and deployability) of future V2X systems is addressed in the PRESERVE project999https://www.preserve-project.eu/. PRESERVE was one of the main European projects that experimented with multiple V2X security/privacy solutions and the design and implementation efforts were proposed to the standardization bodies. The ISE project101010https://www.irt-systemx.fr/en/project/ise/ aims to design and implement a PKI system that is compatible with ETSI standard [106]. The CAMP (crash avoidance metrics partnership) VSC6 (vehicle safety communications 6) consortium proposed the detection of misbehavior (e.g., inadvertent transmission of incorrect data) in the V2X network both in local and network-level (e.g., using in-vehicle algorithms and processing as well as using a security credential management system (SCMS) [21]). This research prototype is now one of the leading candidates to support the establishment of PKI-based V2X security solution in the United States.

Ix-B Related Surveys

A number of surveys have been published on various aspects of the vehicular communications in the last decade. In prior work Saini et al. [135] provide a meta-survey of existing research for generic VANET (vehicular ad hoc network) domain. There also exists early research discussing application/platforms [142] and communication technologies [32]. However vehicular security and privacy aspects are not well studied. Prior work [89, 122, 120] briefly reviews the security and privacy issues of in-vehicle protocols (e.g., CAN) – although communication aspects and standardization activities are not discussed. Security and privacy issues in conventional vehicular networks have also been largely studied and there exist multiple surveys [42, 13, 136, 11, 108, 54, 59, 110, 93, 85, 81, 164] that discuss several aspects (e.g., functional requirements, protocols, vulnerabilities, etc.). In an early study [42] researchers survey various misbehavior (both faulty and malicious) detection approaches and countermeasures against spreading malicious data in the vehicular networks. However this work is primary focus on false data injection attacks and does not cover the broader scope of the field. Azees et al. [13] study VANETs as a special case of mobile ad-hoc network – a common view in the past – and does not cover the class of attacks against safety-critical systems (e.g., false data injection) as is the case for modern V2X applications. Recent work [136] also surveys detection mechanisms for various classes of vehicular communication attacks (e.g., DoS and network layer attacks). However the above work primarily focuses on routing-oriented attacks and defence mechanisms. Arshad et al. [11] summarize the false information detection techniques for generic VANETs. Lu et al. [108] survey anonymous authentication schemes and Hamida et al. [54] study challenges related to the secure and safe V2X applications for ETSI C-ITS standard – although their primary focus is on cryptographic countermeasures. In contrast our survey aims to provide a general overview of the security aspects of the modern V2X (e.g., DSRC/C-ITS as well as C-V2X) platforms/applications. Recent surveys by Hasrouny et al. [59] and MacHardy et al. [110] provide a broad overview of the V2X communication including different radio access technologies, standardization efforts, attack techniques as well as security issues. Le et al. [93] also studied the security and privacy requirements both, from intra- as well as inter-vehicle perspective. However, due to the very broad scope, all of the aforementioned work does not provide sufficient details on detection mechanisms. A survey of the existing trust models for VANETs has also been carried out [85]. Kamel et al. [81] study multiple misbehavior detection methods and then discuss their feasibility with respect to current standards, hardware/software requirements as well as with law compliance. Recent work [164] studies misbehavior detection mechanisms for V2X applications – although authors mainly focus on the DSRC/C-ITS context, and unlike us, they do not provide details about communication stacks, related security standards and challenges for emerging technologies such as LTE-V2X. We highlight that while prior work has covered a wide range of the security and privacy aspects, most of the previous surveys focus on some of the issues and do not provide broad view of the field. We believe our work complements prior surveys and provides a holistic overview of existing V2X security issues and possible countermeasures.

X Conclusion

In the near future V2X communication technology is expected to revolutionize the modern ground transportation system. With the emergence of this modern technology, V2X applications will potentially be targeted by the malicious entities (as evident by the recent real-world attacks on automotive systems [47, 26, 91, 123]) and there is a requirement of layered defence mechanism to improve the resiliency of such systems. In this survey we provided an overview of current V2X security standards, potential security threats and different detection approaches. While in this paper our primary focus in on V2X technology, the novel security mechanisms developed for V2X applications can be used to improve the security of broader safety-critical cyber-physical domains [68, 90]. We believe this research will be tangential and valuable to the academic/industry researchers, developers, systems engineers and standardization agencies working in systems security fields in general.

References

  • [1] 3GPP (2017) LTE; Service requirements for V2X services. Note: 3GPP TS 22.185 V14.3.0 Cited by: §II-B2.
  • [2] 3GPP (2017) Security aspect for LTE support of Vehicle-to-Everything (V2X) services. Note: 3GPP TS 33.185 V14.1.0 Cited by: §VIII-B.
  • [3] 3GPP (2017) Security aspect for LTE support of Vehicle-to-Everything (V2X) Services. Note: TS 33.185 V14.1.0 Cited by: §VIII-B.
  • [4] I. Aad, J. Hubaux, and E. W. Knightly (2004) Denial of service resilience in ad hoc networks. In ACM MobiCom, pp. 202–215. Cited by: §IV-B1.
  • [5] K. Abboud, H. A. Omar, and W. Zhuang (2016-12) Interworking of DSRC and cellular network technologies for V2X communications: a survey. IEEE T-VT 65 (12), pp. 9457–9470. External Links: Document, ISSN 0018-9545 Cited by: §II-B2.
  • [6] A. Alipour-Fanid, M. Dabaghchian, H. Zhang, and K. Zeng (2017) String stability analysis of cooperative adaptive cruise control under jamming attacks. In IEEE HASE, pp. 157–162. Cited by: §IV-B1.
  • [7] M. Amoozadeh, A. Raghuramu, C. Chuah, D. Ghosal, H. M. Zhang, J. Rowe, and K. Levitt (2015-06) Security vulnerabilities of connected vehicle streams and their impact on cooperative driving. IEEE Comm. Mag. 53 (6), pp. 126–132. Cited by: §IV-B3.
  • [8] J. Andrews, T. E. Humphreys, C. Bhat, R. W. Heath, L. Narula, C. Choi, J. Li, et al. (2017) Guidelines on CV networking information flow optimization for Texas.. Technical report University of Texas at Austin. Center for Transportation Research. Note: [Online]. Available: https://library.ctr.utexas.edu/ctr-publications/0-6845-1.pdf Cited by: §VIII-C.
  • [9] L. Apvrille, R. El Khayari, O. Henniger, Y. Roudier, H. Schweppe, H. Seudié, B. Weyl, and M. Wolf (2010) Secure automotive on-board electronics network architecture. In FISITA world auto. cong., Vol. 8. Cited by: §VIII-C.
  • [10] ARIB (2017) 700 MHz band intelligent transport systems. Note: ARIB STD-T109 Version 1.3 [Online]. Available: https://tinyurl.com/y49ae6dy Cited by: §II-B1.
  • [11] M. Arshad, Z. Ullah, N. Ahmad, M. Khalid, H. Criuckshank, and Y. Cao (2018) A survey of local/cooperative-based malicious information detection techniques in VANETs. EURASIP J. on W. Comm. & Net. 2018 (1), pp. 62. Cited by: §IV-B2, §IX-B.
  • [12] (2018) Automotive gateway: a key component to securing the connected car. Technical report NXP Semiconductors. Note: [Online]. Available: https://tinyurl.com/yyjcc25u Cited by: §VIII-C.
  • [13] M. Azees, P. Vijayakumar, and L. J. Deborah (2016) Comprehensive survey on security services in vehicular ad-hoc networks. IET Intelligent Transport Systems 10 (6), pp. 379–388. Cited by: §IX-B.
  • [14] (2018-Apr.) BASIC infrastructure message development and standards support for connected vehicles applications. Technical report Southwest Research Institute. Note: [Online]. Available: https://tinyurl.com/y8fhqca9 Cited by: §I, §II-B2.
  • [15] L. L. Bello (2011) The case for Ethernet in automotive communications. ACM SIGBED Rev. 8 (4), pp. 7–15. Cited by: §VIII-C.
  • [16] N. Bißmeyer, C. Stresing, and K. M. Bayarou (2010) Intrusion detection in vanets through verification of vehicle movement data. In IEEE VNC, pp. 166–173. Cited by: §VII-C.
  • [17] N. Bißmeyer (2014) Misbehavior detection and attacker identification in vehicular ad-hoc networks. Ph.D. Thesis, Technical University. Cited by: §IV-A.
  • [18] S. Biswas, J. Mišić, and V. Mišić (2012) DDoS attack on WAVE-enabled VANET through synchronization. In IEEE GLOBECOM, pp. 1079–1084. Cited by: TABLE IV, §VI-A, §VIII-A.
  • [19] S. Bittl, A. A. Gonzalez, M. Myrtus, H. Beckmann, S. Sailer, and B. Eissfeller (2015) Emerging attacks on VANET security based on GPS time spoofing. In IEEE CNS, pp. 344–352. Cited by: §VII-C.
  • [20] S. Brands and D. Chaum (1993) Distance-bounding protocols. In W. on the Theory and App. of Cryp. Tech., pp. 344–359. Cited by: §VII-C.
  • [21] B. Brecht, D. Therriault, A. Weimerskirch, W. Whyte, V. Kumar, T. Hehn, and R. Goudy (2018-Dec.) A security credential management system for V2X communications. IEEE T-ITS 19 (12), pp. 3850–3871. Cited by: §III-A, §III-B1, §VI-A, §IX-A.
  • [22] S. Cadzow, W. Hoefs, F. Kargl, R. Roy, S. Sill, and W. Whyte (2012-Nov.) EU-US standards harmonization task group report: feedback to standards development organizations–security. Technical report Note: [Online]. Available: https://rosap.ntl.bts.gov/view/dot/34172 Cited by: §III-B2.
  • [23] Z. Cao, J. Kong, U. Lee, M. Gerla, and Z. Chen (2008) Proof-of-relevance: filtering false data via authentic consensus in vehicle ad-hoc networks. In IEEE INFOCOM Wkrsp, pp. 1–6. Cited by: §V-B, §VII-A.
  • [24] (2018-Mar.) Cellular V2X communications towards 5G. Technical report 5G Americas. Note: [Online]. Available: https://tinyurl.com/y79bpv3b Cited by: §I, §II-B2, §II-B2.
  • [25] S. Chang, Y. Qi, H. Zhu, J. Zhao, and X. Shen (2012) Footprint: detecting sybil attacks in urban vehicular networks. IEEE TPDS 23 (6), pp. 1103–1114. Cited by: §V-B, §VI-B2, §VI-B, §VIII-A.
  • [26] S. Checkoway, D. McCoy, B. Kantor, D. Anderson, H. Shacham, S. Savage, K. Koscher, A. Czeskis, F. Roesner, T. Kohno, et al. (2011) Comprehensive experimental analyses of automotive attack surfaces. In USENIX Sec. Symp., Cited by: §X, §II-A, §VIII-C.
  • [27] C. Chen, X. Wang, W. Han, and B. Zang (2009) A robust detection of the Sybil attack in urban VANETs. In IEEE ICDCS, pp. 270–276. Cited by: §V-B, §VI-B2, §VI-B, §VIII-A.
  • [28] L. Chen, S. Ng, and G. Wang (2011) Threshold anonymous announcement in VANETs. IEEE JSAC 29 (3), pp. 605–615. Cited by: §V-B, §VI-B2.
  • [29] K. Cho and K. G. Shin (2016) Fingerprinting electronic control units for vehicle intrusion detection. In USENIX Sec.), pp. 911–927. Cited by: §VIII-C.
  • [30] M. Chuang and J. Lee (2014) TEAM: Trust-extended authentication mechanism for vehicular ad hoc networks. IEEE sys. journal 8 (3), pp. 749–758. Cited by: TABLE IV, §VI-A.
  • [31] M. Contag, G. Li, A. Pawlowski, F. Domke, K. Levchenko, T. Holz, and S. Savage (2017) How they did it: an analysis of emission defeat devices in modern automobiles. In IEEE S&P, pp. 231–250. Cited by: §VIII-C.
  • [32] R. Coppola and M. Morisio (2016) Connected car: technologies, issues, future trends. ACM CSUR 49 (3), pp. 46. Cited by: §IX-B.
  • [33] A. Daeinabi and A. G. Rahbar (2013) Detection of malicious vehicles (DMV) through monitoring in vehicular ad-hoc networks. Mult. tools and app. 66 (2), pp. 325–338. Cited by: TABLE IV, §VI-A.
  • [34] European Telecommunications Standards Institute ETSI TR 102 893 V1.2.1 – Threat, vulnerability and risk analysis (TVRA). Technical report Note: [Online]. Available: https://www.etsi.org/deliver/etsi_tr/102800_102899/102893/01.02.01_60/tr_102893v010201p.pdf Cited by: §IV-A.
  • [35] K. Evensen, H. Fischer, W. Hoefs, and J. Sill (2012-Nov.) EU-US standards harmonization task group report: feedback to ITS standards development organizations–communications. Technical report Note: [Online]. Available: https://rosap.ntl.bts.gov/view/dot/26509 Cited by: §III-B2.
  • [36] X. Feng, C. Li, D. Chen, and J. Tang (2017) A method for defensing against multi-source Sybil attacks in VANET. Peer-to-Peer Net. and App. 10 (2), pp. 305–314. Cited by: §V-B, §VI-B2, §VI-B, §VIII-A.
  • [37] B. Fernandes, J. Rufino, M. Alam, and J. Ferreira (2018) Implementation and analysis of IEEE and ETSI security standards for vehicular communications. Mob. Net. and App., pp. 1–10. Cited by: §III-B1.
  • [38] A. Festag (2014) Cooperative intelligent transport systems standards in Europe. IEEE Comm. Mag. 52 (12), pp. 166–172. Cited by: §II-A, §II-B1.
  • [39] A. Festag (2015) Standards for vehicular communication—from IEEE 802.11p to 5G. Elek. und Info. 132 (7), pp. 409–416. Cited by: §III-B1.
  • [40] A. Filippi, K. Moerman, V. Martinez, A. Turley, O. Haran, and R. Toledano (2017) IEEE 802.11p ahead of LTE-V2V for safety applications. Autotalks NXP. Cited by: §II-B2.
  • [41] I. Foster, A. Prudhomme, K. Koscher, and S. Savage (2015) Fast and vulnerable: a story of telematic failures. In USENIX WOOT, Cited by: §II-A.
  • [42] F. A. Ghaleb, A. Zainal, and M. A. Rassam (2015) Data verification and misbehavior detection in vehicular ad-hoc networks. J. Teknologi 73 (2), pp. 37–44. Cited by: §IV-B3, §V-B, §V, §IX-B.
  • [43] M. Ghosh, A. Varghese, A. Gupta, A. A. Kherani, and S. N. Muthaiah (2010) Detecting misbehaviors in VANET with integrated root-cause analysis. Ad Hoc Net. 8 (7), pp. 778–790. Cited by: §V-B, §VII-A.
  • [44] B. Glas, J. Guajardo, H. Hacioglu, M. Ihle, K. Wehefritz, and A. Yavuz (2012) Signal-based automotive communication security and its interplay with safety requirements. In Proc. of Emb. Sec. in Cars Conf., Cited by: §VIII-C.
  • [45] (2016) GLOBAL harmonization of connected vehicle communication standards. Note: MDOT and CAR Tech. Rep. [Online]. Available: https://tinyurl.com/y42rqhcp Cited by: §III-B2, §III-B.
  • [46] P. Golle, D. Greene, and J. Staddon (2004) Detecting and correcting malicious data in VANETs. In ACM VANET, pp. 29–37. Cited by: §V-B, §VI-B1, §VI-B.
  • [47] A. Greenberg (2015) Hackers remotely kill a jeep on the highway—with me in it. Wired 7, pp. 21. Cited by: §X.
  • [48] A. Groll, J. Holle, C. Ruland, M. Wolf, T. Wollinger, and F. Zweers (2009) OVERSEE - a secure and open communication and runtime platform for innovative automotive applications. In ESCAR, Cited by: §VIII-C.
  • [49] J. Grover, M. S. Gaur, V. Laxmi, and N. K. Prajapati (2011) A Sybil attack detection approach using neighboring vehicles in VANET. In ACM S, pp. 151–158. Cited by: §V-B, §VI-B1, §VI-B.
  • [50] B. Groza, S. Murvay, A. Van Herrewege, and I. Verbauwhede (2012) LiBrA-CAN: a lightweight broadcast authentication protocol for controller area networks. In Springer CANS, pp. 185–200. Cited by: §VIII-C.
  • [51] G. Guette and B. Ducourthial (2007) On the Sybil attack detection in VANET. In IEEE MASS, Vol. , pp. 1–6. Cited by: §V-B, §VI-B1, §VI-B.
  • [52] F. Haidar, A. Kaiser, and B. Lonc (2017) On the performance evaluation of vehicular pki protocol for v2x communications security. In IEEE VTC-Fall, pp. 1–5. Cited by: §III-A.
  • [53] H. Hamed, A. Keshavarz-Haddad, and S. G. Haghighi (2018) Sybil attack detection in urban VANETs based on RSU support. In Electrical Engineering (ICEE), Iranian Conference on, pp. 602–606. Cited by: §V-B, §VI-B2, §VI-B, §VIII-A.
  • [54] E. Hamida, H. Noura, and W. Znaidi (2015) Security of cooperative intelligent transport systems: standards, threats analysis and cryptographic countermeasures. MDPI Electronics 4 (3), pp. 380–423. Cited by: §IX-B.
  • [55] A. Hamieh, J. Ben-Othman, and L. Mokdad (2009) Detection of radio interference attacks in VANET. In IEEE GLOBECOM, pp. 1–5. Cited by: TABLE IV, §VI-A.
  • [56] P. Hank, T. Suermann, and S. Mueller (2012) Automotive ethernet, a holistic approach for a next generation in-vehicle networking standard. In Springer AMAA, pp. 79–89. Cited by: §VIII-C.
  • [57] Y. Hao, J. Tang, and Y. Cheng (2011) Cooperative Sybil attack detection for position based applications in privacy preserved VANETs. In IEEE GLOBECOM, pp. 1–5. Cited by: §V-B, §VI-B1, §VI-B.
  • [58] H. Hasrouny, C. Bassil, A. E. Samhat, and A. Laouiti (2017) Security risk analysis of a trust model for secure group leader-based communication in VANET. In Springer IWVSC, pp. 71–83. Cited by: TABLE IV, §VI-A.
  • [59] H. Hasrouny, A. E. Samhat, C. Bassil, and A. Laouiti (2017) VANET security challenges and solutions: a survey. Vehicular Communications 7, pp. 7–20. Cited by: §III-A, §IV-B3, §IX-B.
  • [60] H. Hasrouny, A. E. Samhat, C. Bassil, and A. Laouiti (2017) VANet security challenges and solutions: a survey. Elsevier Veh. Comm. 7, pp. 7–20. Cited by: §III-B1, §III-B, §IV-B3, §IV-B.
  • [61] L. He and W. T. Zhu (2012) Mitigating DoS attacks against signature-based authentication in VANETs. In IEEE CSAE, Vol. 3, pp. 261–265. Cited by: TABLE IV, §VI-A, §VIII-A.
  • [62] T. Hoppe, S. Kiltz, and J. Dittmann (2008) Security threats to automotive can networks–practical examples and selected short-term countermeasures. In EWICS SAFECOMP, pp. 235–248. Cited by: §VIII-C.
  • [63] T. Hoppe, S. Kiltz, and J. Dittmann (2009) Applying intrusion detection to automotive it-early insights and remaining challenges. JIAS 4 (6), pp. 226–235. Cited by: §VIII-C.
  • [64] J. Hortelano, J. C. Ruiz, and P. Manzoni (2010) Evaluating the usefulness of watchdogs for intrusion detection in VANETs. In IEEE ICC, Vol. , pp. 1–5. External Links: ISSN 2164-7038 Cited by: TABLE IV, §VI-A.
  • [65] M. Höyhtyä, O. Apilo, and M. Lasanen (2018) Review of latest advances in 3GPP standardization: D2D communication in 5G systems and its energy consumption models. MDPI Fut. Int. 10 (1), pp. 3. Cited by: §II-B2.
  • [66] H. Hsiao, A. Studer, R. Dubey, E. Shi, and A. Perrig (2011) Efficient and secure threshold-based event validation for VANETs. In ACM WiSec, pp. 163–174. Cited by: §V-B, §VII-A.
  • [67] J. Hubaux, S. Capkun, and J. Luo (2004) The security and privacy of smart vehicles. IEEE Sec. & Priv. (3), pp. 49–55. Cited by: §V-B, §VII-C.
  • [68] A. Humayed, J. Lin, F. Li, and B. Luo (2017) Cyber-physical systems security—a survey. IEEE IoT J. 4 (6), pp. 1802–1831. Cited by: §X.
  • [69] M. S. Idrees, H. Schweppe, Y. Roudier, M. Wolf, D. Scheuermann, and O. Henniger (2011) Secure automotive on-board protocols: a case of over-the-air firmware updates. In Int. W. on Comm. Tech. for Veh., pp. 224–238. Cited by: §VIII-C.
  • [70] (2010-07) IEEE standard for information technology– local and metropolitan area networks– specific requirements– part 11. IEEE Std 802.11p-2010 (), pp. 1–51. Cited by: §II-B1, §II-B.
  • [71] (2016) IEEE standard for wireless access in vehicular environments–security services for applications and management messages. IEEE Std 1609.2-2016 (), pp. 1–240. Cited by: §III-B1.
  • [72] (2016) IEEE standard for wireless access in vehicular environments–security services for applications and management messages. IEEE Std 1609.2-2016 (), pp. 1–240. Cited by: §III-B1, §IV-B3, §VI-B2.
  • [73] H. Imai and A. Yamagishi (2000) CRYPTREC project – Cryptographic evaluation project for the Japanese electronic government. In IACR Asiacrypt, pp. 399–400. Cited by: §III-B1.
  • [74] R. M. Ishtiaq Roufa, H. Mustafaa, S. O. Travis Taylora, W. Xua, M. Gruteserb, W. Trappeb, and I. Seskarb (2010) Security and privacy vulnerabilities of in-car wireless networks: a tire pressure monitoring system case study. In USENIX Sec. Symp., pp. 11–13. Cited by: §VIII-C.
  • [75] ITS Info-communications Forum of Japan (2013) Security guideline for driver assistance communications system. Note: ITS FORUM RC-009 Ver. 1.2 [Online]. Available: https://tinyurl.com/yxsba89n Cited by: §III-B1.
  • [76] ITS standards program: development activities. Note: https://www.standards.its.dot.gov/DevelopmentActivities/IntlHarmonization Cited by: §III-B2.
  • [77] ITU-R (2018) Intelligent transport systems (ITS) usage. Note: ITU-R M.2445-0 Cited by: §II-A.
  • [78] I. Ivanov, C. Maple, T. Watson, and S. Lee (2018) Cyber security standards and issues in V2X communications for Internet of vehicles. In Living in the Internet of Things: Cybersecurity of the IoT, Vol. , pp. 1–6. Cited by: §III-B2.
  • [79] A. Jaeger, N. Bißmeyer, H. Stübing, and S. A. Huss (2012) A novel framework for efficient mobility data verification in vehicular ad-hoc networks. Springer IJITSR 10 (1), pp. 11–21. Cited by: §V-B, §VII-C.
  • [80] S. Jain, Q. Wang, M. T. Arafin, and J. Guajardo (2018) Probing attacks on physical layer key agreement for automotive controller area networks. In IEEE AsianHOST, pp. 7–12. Cited by: §VIII-C.
  • [81] J. Kamel, A. Kaiser, I. B. Jemaa, P. Cincilla, and P. Urien (2018) Feasibility study of misbehavior detection mechanisms in cooperative intelligent transport systems (C-ITS). In IEEE VTC Spring, pp. 1–5. Cited by: §IX-B.
  • [82] G. Karagiannis, O. Altintas, E. Ekici, G. Heijenk, B. Jarupan, K. Lin, and T. Weil (2011) Vehicular networking: a survey and tutorial on requirements, architectures, challenges, standards and solutions. IEEE comm. surv. & tut. 13 (4), pp. 584–616. Cited by: §V-B.
  • [83] F. Kargl, P. Papadimitratos, L. Buttyan, M. Müter, E. Schoch, B. Wiedersheim, T. Thong, G. Calandriello, A. Held, A. Kung, et al. (2008) Secure vehicular communication systems: implementation, performance, and research challenges. IEEE Comm. Mag. 46 (11), pp. 110–118. Cited by: §V.
  • [84] J. B. Kenney (2011) Dedicated short-range communications (DSRC) standards in the United States. Proc. of the IEEE 99 (7), pp. 1162–1182. Cited by: §II-A, §II-B1.
  • [85] C. A. Kerrache, C. T. Calafate, J. Cano, N. Lagraa, and P. Manzoni (2016) Trust management for vehicular networks: an adversary-oriented overview. IEEE Access 4, pp. 9293–9307. Cited by: §IX-B.
  • [86] C. A. Kerrache, N. Lagraa, C. T. Calafate, J. Cano, and P. Manzoni (2016) T-VNets: A novel trust architecture for vehicular networks using the standardized messaging services of ETSI ITS. Elsevier Comp. Comm. 93, pp. 68–83. Cited by: §V-B, §VII-D.
  • [87] C. A. Kerrache, N. Lagraa, C. T. Calafate, and A. Lakas (2017) TFDD: A trust-based framework for reliable data delivery and DoS defense in VANETs. Veh. Comm. 9, pp. 254–267. Cited by: TABLE IV, §VI-A.
  • [88] T. H. Kim, A. Studer, R. Dubey, X. Zhang, A. Perrig, F. Bai, B. Bellur, and A. Iyer (2010) VANET alert endorsement using multi-source filters. In ACM VANET, pp. 51–60. Cited by: §V-B, §VII-A.
  • [89] P. Kleberger, T. Olovsson, and E. Jonsson (2011) Security aspects of the in-vehicle network in the connected car. In IEEE IV, pp. 528–533. Cited by: §VIII-C, §IX-B.
  • [90] C. Konstantinou, M. Maniatakos, F. Saqib, S. Hu, J. Plusquellic, and Y. Jin (2015) Cyber-physical systems: a security perspective. In IEEE ETS, pp. 1–8. Cited by: §X.
  • [91] K. Koscher, A. Czeskis, F. Roesner, S. Patel, T. Kohno, S. Checkoway, D. McCoy, B. Kantor, D. Anderson, H. Shacham, et al. (2010) Experimental security analysis of a modern automobile. In IEEE S&P, pp. 447–462. Cited by: §X.
  • [92] C. Laurendeau and M. Barbeau (2006) Threats to security in DSRC/WAVE. In AdHoc-Now, pp. 266–279. Cited by: §IV-A.
  • [93] V. H. Le, J. den Hartog, and N. Zannone (2018) Security and privacy for innovative automotive applications: a survey. Elsevier Comp. Comm. 132, pp. 17–41. Cited by: §II-A, §VIII-A, §VIII-C, §IX-B.
  • [94] B. Lee, E. Jeong, and I. Jung (2013) A DTSA (detection technique against a sybil attack) protocol using SKC (session key based certificate) on VANET. Int. J. Sec. its Appl 7 (3), pp. 1–10. Cited by: §V-B, §VI-B2, §VI-B, §VIII-A.
  • [95] T. Leinmüller, C. Maihöfer, E. Schoch, and F. Kargl (2006) Improved security in geographic ad hoc routing through autonomous position verification. In ACM VANET, pp. 57–66. Cited by: §V-B, §VII-C.
  • [96] T. Leinmüller, E. Schoch, F. Kargl, and C. Maihöfer (2010) Decentralized position verification in geographic ad hoc routing. Sec. and comm. net. 3 (4), pp. 289–302. Cited by: §V-B, §VII-C.
  • [97] T. Leinmüller, E. Schoch, and F. Kargl (2006) Position verification approaches for vehicular ad hoc networks. IEEE Wireless Comm. 13 (5), pp. 16–21. Cited by: §V-B, §VII-C.
  • [98] T. Leinmüller, E. Schoch, and C. Maihofer (2007) Security requirements and solution concepts in vehicular ad hoc networks. In IEEE WONS, pp. 84–91. Cited by: §V.
  • [99] T. Leinmüller and E. Schoch (2006) Greedy routing in highway scenarios: the impact of position faking nodes. In Proc. of WIT, Cited by: §IV-B3.
  • [100] Y. J. Li (2010) An overview of the DSRC/WAVE technology. In EAI Qshine, pp. 544–558. Cited by: §III-B1, §IV-B3.
  • [101] C. Lin, B. Zheng, Q. Zhu, and A. Sangiovanni-Vincentelli (2015) Security-aware design methodology and optimization for automotive systems. ACM TODAES 21 (1), pp. 18. Cited by: §VIII-C.
  • [102] X. Lin, R. Lu, C. Zhang, H. Zhu, P. Ho, and X. Shen (2008) Security in vehicular ad hoc networks. IEEE Comm. Mag. 46 (4), pp. 88–95. Cited by: §V.
  • [103] X. Lin, J. G. Andrews, A. Ghosh, and R. Ratasuk (2014) An overview of 3GPP device-to-device proximity services. IEEE Comm Mag 52 (4), pp. 40–48. Cited by: §II-B2.
  • [104] B. Liu, J. T. Chiang, and Y. Hu (2010) Limits on revocation in VANTEs. In Springer ACNS, pp. 38–52. Cited by: §VII-D.
  • [105] N. Lo and H. Tsai (2007) Illusion attack on VANET applications - A message plausibility problem. In IEEE Globecom Wkshps, pp. 1–8. Cited by: §V-B, §VII-B.
  • [106] B. Lonc and P. Cincilla (2016) Cooperative ITS security framework: standards and implementations progress in Europe. In IEEE WoWMoM, pp. 1–6. Cited by: §III-B1, §IV-B3, §IX-A.
  • [107] C. Lottermann, M. Botsov, P. Fertl, R. Müllner, G. Araniti, C. Campolo, M. Condoluci, A. Iera, and A. Molinaro (2015) Vehicular ad hoc networks: standards, solutions, and research. Springer. Cited by: §II-B1.
  • [108] Z. Lu, G. Qu, and Z. Liu (2018) A survey on recent advances in vehicular network security, trust, and privacy. IEEE Trans. Intell. Trans. Sys. (99), pp. 1–17. Cited by: §IX-B.
  • [109] N. Lyamin, D. Kleyko, Q. Delooz, and A. Vinel (2018) AI-based malicious network traffic detection in VANETs. IEEE Network 32 (6), pp. 15–21. Cited by: TABLE IV, §VI-A.
  • [110] Z. MacHardy, A. Khan, K. Obana, and S. Iwashina (2018) V2X access technologies: regulation, research, and remaining challenges. IEEE Comm. Surv. & Tut. 20 (3), pp. 1858–1877. Cited by: §II-B, §VIII-A, §VIII-B, §IX-B.
  • [111] M. Marchetti, D. Stabili, A. Guido, and M. Colajanni (2016)

    Evaluation of anomaly detection for in-vehicle networks through information-theoretic algorithms

    .
    In IEEE RTSI, pp. 1–6. Cited by: §VIII-C.
  • [112] C. Miller and C. Valasek (2014) A survey of remote automotive attack surfaces. Black Hat USA 2014, pp. 94. Cited by: §VIII-C.
  • [113] T. Moore, M. Raya, J. Clulow, P. Papadimitratos, R. Anderson, and J. Hubaux (2008) Fast exclusion of errant devices from vehicular networks. In IEEE SECON, Vol. , pp. 135–143. Cited by: §V-B, §VII-D.
  • [114] P. Mundhenk, A. Paverd, A. Mrowca, S. Steinhorst, M. Lukasiewycz, S. A. Fahmy, and S. Chakraborty (2017) Security in automotive networks: lightweight authentication and authorization. ACM TODAES 22 (2), pp. 25. Cited by: §VIII-C.
  • [115] P. Murvay and B. Groza (2017) DoS attacks on controller area networks by fault injections from the software layer. In ACM ARES, pp. 71. Cited by: §VIII-C.
  • [116] D. K. Nilsson and U. Larson (2009) A defense-in-depth approach to securing the wireless vehicle infrastructure.. JNW 4 (7), pp. 552–564. Cited by: §VIII-C.
  • [117] K. Norrman, M. Näslund, and E. Dubrova (2016) Protecting IMSI and user privacy in 5G networks. In ICST MOBIMEDIA, pp. 159–166. Cited by: §VIII-B.
  • [118] A. Palanca, E. Evenchick, F. Maggi, and S. Zanero (2017) A stealth, selective, link-layer denial-of-service attack against automotive networks. In SIG SIDAR DIMVA, pp. 185–206. Cited by: §VIII-C.
  • [119] S. Park, B. Aslam, D. Turgut, and C. C. Zou (2009) Defense against sybil attack in vehicular ad hoc network based on roadside unit support. In IEEE MILCOM, pp. 1–7. Cited by: §V-B, §VI-B2, §VI-B, §VIII-A.
  • [120] S. Parkinson, P. Ward, K. Wilson, and J. Miller (2017) Cyber threats facing autonomous and connected vehicles: future challenges. IEEE Trans. Intell. Trans. Sys. 18 (11), pp. 2898–2915. Cited by: §I, §IX-B.
  • [121] J. Petit, M. Feiri, and F. Kargl (2011) Spoofed data detection in VANETs using dynamic thresholds. In IEEE VNC, pp. 25–32. Cited by: §V-B, §VII-A.
  • [122] J. Petit and S. E. Shladover (2015) Potential cyberattacks on automated vehicles. IEEE Trans. Intell. Trans. Sys. 16 (2), pp. 546–556. Cited by: §I, §VIII-C, §IX-B.
  • [123] J. Petit, B. Stottelaar, M. Feiri, and F. Kargl (2015) Remote attacks on automated vehicles sensors: experiments on camera and LiDAR. Black Hat Europe 11, pp. 2015. Cited by: §X.
  • [124] O. Puñal, A. Aguiar, and J. Gross (2012) In VANETs we trust? Characterizing RF jamming in vehicular networks. In ACM VANET, pp. 83–92. Cited by: §IV-B1.
  • [125] O. Punal, C. Pereira, A. Aguiar, and J. Gross (2015) Experimental characterization and modeling of RF jamming attacks on VANETs. IEEE TVT 64 (2), pp. 524–540. Cited by: §IV-B1.
  • [126] A. Radu and F. D. Garcia (2016) LeiA: a lightweight authentication protocol for can. In ESORICS, pp. 283–300. Cited by: §VIII-C.
  • [127] M. Rahbari and M. A. J. Jamali (2011) Efficient detection of sybil attack based on cryptography in VANET. arXiv preprint arXiv:1112.2257. Cited by: §V-B, §VI-B2, §VI-B, §VIII-A.
  • [128] D. B. Rawat, B. B. Bista, G. Yan, and M. C. Weigle (2011) Securing vehicular ad-hoc networks against malicious drivers: a probabilistic approach. In IEEE CISIS, pp. 146–151. Cited by: §V-B, §VII-D.
  • [129] M. Raya and J. Hubaux (2007) Securing vehicular ad hoc networks. IOS J. of Comp. Sec. 15 (1), pp. 39–68. Cited by: §IV-A, §V, §VIII-C.
  • [130] M. Raya, P. Papadimitratos, I. Aad, D. Jungels, and J. Hubaux (2007) Eviction of misbehaving and faulty nodes in vehicular networks. IEEE JSAC 25 (8), pp. 1557–1568. Cited by: §V-B, §V, §VII-D.
  • [131] M. Razzaque, A. Salehi, and S. M. Cheraghi (2013) Security and privacy in vehicular ad-hoc networks: survey and the road ahead. In Springer Wireless Net. and Sec., pp. 107–132. Cited by: §VI-A.
  • [132] (2016-Oct.) ROADMAP to vehicle connectivity. Technical report SFB Consulting, LLC. Note: [Online]. Available: https://tinyurl.com/y2bzhn4u Cited by: §II-B1.
  • [133] S. Ruj, M. A. Cavenaghi, Z. Huang, A. Nayak, and I. Stojmenovic (2011) On data-centric misbehavior detection in VANETs. In IEEE VTC (Fall), pp. 1–5. Cited by: §V-A, §V-B, §VI-B1, §VI-B, §VII-C.
  • [134] SAE International SAE J2945/1: on-board system requirements for V2V safety communications. Note: [Online]. Available: https://saemobilus.sae.org/content/j2945/1_201603 Cited by: §II-B1, §III-B1, §III-B1.
  • [135] M. Saini, A. Alelaiwi, and A. E. Saddik (2015) How close are we to realizing a pragmatic VANET solution? a meta-survey. ACM CSUR 48 (2), pp. 29. Cited by: §II-A, §IX-B.
  • [136] F. Sakiz and S. Sen (2017) A survey of attacks and detection mechanisms on intelligent transportation systems: VANETs and IoV. Elsevier Ad Hoc Net. 61, pp. 33–50. Cited by: §IV-B1, §IV-B2, §IV-B3, §IV-B, §V, §IX-B.
  • [137] D. Schmidt, K. Radke, S. Camtepe, E. Foo, and M. Ren (2016) A survey and analysis of the GNSS spoofing threat and countermeasures. ACM CSUR 48 (4), pp. 64. Cited by: §IV-B3, §VII-C.
  • [138] R. K. Schmidt, T. Leinmüller, E. Schoch, A. Held, and G. Schäfer (2008) Vehicle behavior analysis to enhance security in VANETs. In IEEE V2VCOM, Cited by: §V-B, §VII-B, §VII-C.
  • [139] H. Seo, K. Lee, S. Yasukawa, Y. Peng, and P. Sartori (2016) LTE evolution for vehicle-to-everything services. IEEE comm. mag. 54 (6), pp. 22–28. Cited by: §II-B2, §II-B2.
  • [140] A. C. Serban, E. Poll, and J. Visser (2018) A security analysis of the ETSI ITS vehicular communications. In EWICS SAFECOMP, pp. 365–373. Cited by: §II-B1, §III-A, §III-B1, §III-B1, §IV-B3, §VI-B2.
  • [141] M. Seredynski, D. Khadraoui, and F. Viti (2015) Signal phase and timing (spat) for cooperative public transport priority measures. In ITS World Congress, Cited by: footnote 3.
  • [142] F. Simonot-Lion and Y. Trinquet (2009) Vehicle functional domains and their requirements. Taylor & Francis/CRC Press. Cited by: §IX-B.
  • [143] A. Singh and H. C. Fhom (2017-04) Restricted usage of anonymous credentials in vehicular ad hoc networks for misbehavior detection. Int. J. Inf. Secur. 16 (2), pp. 195–211. External Links: ISSN 1615-5262 Cited by: §V-B, §VI-B2, §VI-B, §VIII-A.
  • [144] (2018-Nov.) Solutions for smarter driving telematics and networking. Technical report STMicroelectronics. Note: [Online]. Available: https://tinyurl.com/y5weq9bg Cited by: §VIII-C.
  • [145] H. M. Song, H. R. Kim, and H. K. Kim (2016) Intrusion detection system based on the analysis of time intervals of can messages for in-vehicle network. In IEEE ICOIN, pp. 63–68. Cited by: §VIII-C.
  • [146] J. Soryal and T. Saadawi (2013) DoS attack detection in Internet-connected vehicles. In IEEE ICCVE, Vol. , pp. 7–13. External Links: ISSN 2378-1289 Cited by: TABLE IV, §VI-A, §VIII-A.
  • [147] C. Sowattana, W. Viriyasitavat, and A. Khurat (2017) Distributed consensus-based Sybil nodes detection in VANETs. In IEEE JCSSE, pp. 1–6. Cited by: §V-B, §VI-B2, §VI-B, §VIII-A.
  • [148] J. P. Stotz, N. Bißmeyer, F. Kargl, S. Dietzel, P. Papadimitratos, and C. Schleiffer (2011) PRESERVE D1.1 security requirements of vehicle security architecture. PRESERVE consortium, Deliverable. Cited by: §IV.
  • [149] H. Stübing, J. Firl, and S. A. Huss (2011) A two-stage verification process for Car-to-X mobility data based on path prediction and probabilistic maneuver recognition. In IEEE VNC, pp. 17–24. Cited by: §V-B, §VII-C.
  • [150] H. Stübing, A. Jaeger, C. Schmidt, and S. A. Huss (2010) Verifying mobility data under privacy considerations in car-to-x communication. In 17th ITS World Cong., Cited by: §V-B, §VII-C.
  • [151] A. Studer, F. Bai, B. Bellur, and A. Perrig (2009) Flexible, extensible, and efficient VANET authentication. IEEE JCN 11 (6), pp. 574–588. Cited by: TABLE IV, §VI-A, §VIII-A.
  • [152] A. Studer, M. Luk, and A. Perrig (2007) Efficient mechanisms to provide convoy member and vehicle sequence authentication in VANETs. In IEEE SecureComm, pp. 422–432. Cited by: §V-B, §VII-C.
  • [153] F. Stumpf, C. Meves, B. Weyl, and M. Wolf (2009) A security architecture for multipurpose ECUs in vehicles. In Joint VDI/VW Auto. Sec. Conf., Cited by: §VIII-C.
  • [154] I. A. Sumra, H. B. Hasbullah, and J. B. AbManan (2014) Effects of attackers and attacks on availability requirement in vehicular network: a survey. In IEEE ICCOINS, pp. 1–6. Cited by: §IV-B1.
  • [155] M. Sun, M. Li, and R. Gerdes (2017) A data trust framework for VANETs enabling false data detection and secure vehicle tracking. In IEEE CNS, Vol. , pp. 1–9. External Links: ISSN Cited by: §V-B, §VII-C.
  • [156] C. Suthaputchakun and Z. Sun (2011) Routing protocol in intervehicle communication systems: a survey. IEEE Comm. Mag. 49 (12). Cited by: §II-B1.
  • [157] A. Taylor, N. Japkowicz, and S. Leblanc (2015) Frequency-based anomaly detection for the automotive can bus. In IEEE WCICSS, pp. 45–49. Cited by: §VIII-C.
  • [158] F. A. Teixeira, V. F. e Silva, J. L. Leoni, D. F. Macedo, and J. M. Nogueira (2014) Vehicular networks using the IEEE 802.11 p standard: An experimental analysis. Elsevier Veh. Comm. 1 (2), pp. 91–96. Cited by: §I.
  • [159] S. Tuohy, M. Glavin, C. Hughes, E. Jones, M. Trivedi, and L. Kilmartin (2015) Intra-vehicle networks: a review. IEEE T-ITS 16 (2), pp. 534–545. Cited by: §VIII-C.
  • [160] A. Turley, K. Moerman, A. Filippi, and V. Martinez (2018) C-ITS: Three observations on LTE-V2X and ETSI ITS-G5—A comparison. NXP Semiconductors White Paper. Cited by: §II-B2.
  • [161] E. Uhlemann (2018) The battle of technologies or the battle of business models?[connected vehicles]. IEEE Veh. Tech. Mag. 13 (1), pp. 14–18. Cited by: §II-B2.
  • [162] (2016-Oct.) V2X cellular solutions. Technical report 5G Americas. Note: [Online]. Available: https://tinyurl.com/y4snwepn Cited by: §II-B2, §III-B.
  • [163] R. van der Heijden, T. Lukaseder, and F. Kargl (2017-11) Analyzing attacks on cooperative adaptive cruise control (CACC). In IEEE VNC, Vol. , pp. 45–52. External Links: ISSN 2157-9865 Cited by: §IV-B3.
  • [164] R. W. van der Heijden, S. Dietzel, T. Leinmüller, and F. Kargl (2018) Survey on misbehavior detection in cooperative intelligent transportation systems. IEEE Commu. Sur. & Tut.. Cited by: §IV-B1, §IV-B2, §IV-B3, §IV-B, §V-B, §V, §VI-B1, §IX-B, footnote 5.
  • [165] R. W. Van der Heijden, F. Kargl, O. M. Abu-Sharkh, et al. (2016) Enhanced position verification for VANETs using subjective logic. In IEEE VTC-Fall, pp. 1–7. Cited by: §VII-C.
  • [166] A. Van Herrewege, D. Singelee, and I. Verbauwhede (2011) CANAuth-a simple, backward compatible broadcast authentication protocol for can bus. In ECRYPT W. on Lightweight Crypt., Cited by: §VIII-C.
  • [167] Vehicle-to-vehicle communications misbehavior detection. Technical report Vehicle Safety Communications 6 (VSC6) Consortium. Note: [Online]. Available: https://tinyurl.com/y4ekd7k7 Cited by: §III-B.
  • [168] K. Verma, H. Hasbullah, and A. Kumar (2013) Prevention of DoS attacks in VANET. Wireless per. comm. 73 (1), pp. 95–126. Cited by: TABLE IV, §VI-A, §VIII-A.
  • [169] K. Verma and H. Hasbullah (2015) Bloom-filter based IP-CHOCK detection scheme for denial of service attacks in VANET. Sec. and Comm. Net. 8 (5), pp. 864–878. Cited by: TABLE IV, §VI-A, §VIII-A.
  • [170] A. Vora and M. Nesterenko (2006) Secure location verification using radio broadcast. IEEE TDSC 3 (4), pp. 377–385. Cited by: §V-B, §VII-C, §VIII-A.
  • [171] J. Wang, Y. Shao, Y. Ge, and R. Yu (2019) A survey of vehicle to everything (V2X) testing. MDPI Sensors 19 (2). Cited by: §I.
  • [172] X. Wang, S. Mao, and M. X. Gong (2017) An overview of 3GPP cellular vehicle-to-everything standards. ACM GetMobile 21 (3), pp. 19–25. Cited by: §II-B2.
  • [173] A. R. Wasicek, M. D. Pesé, A. Weimerskirch, Y. Burakova, and K. Singh (2017) Context-aware intrusion detection in automotive control systems. In ESCAR USA Conf., pp. 21–22. Cited by: §VIII-C.
  • [174] B. Wiedersheim, Z. Ma, F. Kargl, and P. Papadimitratos (2010) Privacy in inter-vehicular networks: why simple pseudonym change is not enough. In IEEE WONS, pp. 176–183. Cited by: §VIII-A.
  • [175] M. Wolf, A. Weimerskirch, and C. Paar (2006) Secure in-vehicle communication. In Springer Emb. Sec. in Cars, pp. 95–109. Cited by: §VIII-C.
  • [176] S. Woo, H. J. Jo, and D. H. Lee (2015) A practical wireless attack on the connected car and security protocol for in-vehicle CAN. IEEE Trans. on Int. Trans. Sys. 16 (2), pp. 993–1006. Cited by: §VIII-C.
  • [177] B. Xiao, B. Yu, and C. Gao (2006) Detection and localization of Sybil nodes in VANETs. In ACM DIWANS, pp. 1–8. Cited by: §V-B, §VI-B1, §VI-B2, §VI-B, §VIII-A.
  • [178] G. Yan, S. Olariu, and M. C. Weigle (2008) Providing VANET security through active position detection. Comput. comm. 31 (12), pp. 2883–2897. Cited by: §V-B, §VII-C.
  • [179] T. Yang, W. Xin, L. Yu, Y. Yang, J. Hu, and Z. Chen (2013) MisDis: An efficient misbehavior discovering method based on accountability and state machine in VANET. In Asia-Pacific Web Conf., pp. 583–594. Cited by: §V-B, §VII-B.
  • [180] Y. Yao, B. Xiao, G. Wu, X. Liu, Z. Yu, K. Zhang, and X. Zhou (2019) Multi-channel based sybil attack detection in vehicular ad hoc networks using rssi. IEEE TMC 18 (2), pp. 362–375. Cited by: §V-B, §VI-B1.
  • [181] E. Yeh, J. Choi, N. Prelcic, C. Bhat, and R. Heath (2017) Security in automotive radar and vehicular networks. Microwave Journal. Cited by: §VIII-A.
  • [182] B. Yu, C. Xu, and B. Xiao (2013) Detecting Sybil attacks in VANETs. J. of Par. and Dist. Comp. 73 (6), pp. 746–756. Cited by: §IV-B2, §VI-B1, §VI-B.
  • [183] K. Zaidi, M. B. Milojevic, V. Rakocevic, A. Nallanathan, and M. Rajarajan (2016) Host-based intrusion detection for VANETs: a statistical approach to rogue node detection. IEEE TVT 65 (8), pp. 6703–6714. Cited by: §V-B, §VII-D.
  • [184] J. Zhang, P. A. Porras, and J. Ullrich (2008) Highly predictive blacklisting.. In USENIX Sec. Symp., pp. 107–122. Cited by: §VI-A.
  • [185] T. Zhang and L. Delgrossi (2012) Vehicle safety communications: protocols, security, and privacy. Vol. 103, John Wiley & Sons. Cited by: §III-B1.
  • [186] T. Zhou, R. R. Choudhury, P. Ning, and K. Chakrabarty (2011) PDAP—Sybil attacks detection in vehicular ad hoc networks. IEEE JSAC 29 (3), pp. 582–594. Cited by: §V-B, §VI-B2, §VI-B, §VIII-A.
  • [187] X. Zhuo, J. Hao, D. Liu, and Y. Dai (2009) Removal of misbehaving insiders in anonymous VANETs. In ACM MSWiM, pp. 106–115. Cited by: §V-B, §VII-D.
  • [188] Q. Zou, W. K. Chan, K. C. Gui, Q. Chen, K. Scheibert, L. Heidt, and E. Seow (2017) The study of secure CAN communication for automotive applications. Technical report SAE Tech. Paper. Cited by: §VIII-C.