The type and functionality of a sensor determines the extent to which it could contribute to scoping out secure threats, as well as the extent to which it could inform potential implications should it be compromised [5]. 

For partially autonomous vehicles, sensors only assist the driver to obtain some information and the vehicle is still monitored and controlled by the driver. Even for Google’s driverless car that operates autonomously at most times, the driver will take over of control immediately if the automation system cannot process dangerous situations. Therefore, the impact of attacks on these sensors may be mitigated by the driver’s surveillance or management. Even so, autonomous vehicles significantly depend on these various types of sensors to perceive the surroundings and the status of the vehicles to assist driving or automatically drive by itself. For example, Paper [9] utilized multiple sensors such as radar, LIDAR, and cameras to perform autonomous lane changing. Paper [10] reviews vision-based autonomous driving systems. Paper [11] proposes an effective empirical formula solution to assist autonomous driving in a GPS-denied environment. Paper [12] provide a survey on intelligent tires for tire–road interaction recognition. Paper [13] proposed a localization system for autonomous driving using gyroscopes and accelerometers. In the future, fully autonomous vehicle will completely operate without driver involvement. Thus, attacks on these sensors will cause serious issues, and calls for more attention.

In-vehicle networks are composed of diverse types of bus systems, mainly including CAN, LIN, FlexRay, and MOST. Due to the specific characteristics of each type of bus system, each type possesses distinct vulnerabilities [24]. These bus systems connect diverse types of ECUs together, therefore, any type of bus controller can send messages to any other existing ECU. Among these bus systems, the CAN bus works as the backbone of the in-vehicle network to receive many control messages and deliver them to the corresponding ECU. Therefore, we analyzed the security issues of CAN. Typically, the CAN bus can be categorized into two types: CAN-C and CAN-HIS buses; each of them is designed with distinct functions. Due to the lack of encryption, authentication, and authorization on the CAN bus, all messages on the bus are transmitted in plaintext; neither source or destination address is included in the message format. Therefore, attacks on the CAN bus include eavesdropping and traffic analysis, jamming and DoS, and malicious modification or injection. For attacks aimed at manipulating certain functions of a vehicle, such as steering and braking, the attacker needs access to the CAN bus and to modify messages on the CAN bus or directly inject malicious messages into the bus. In the past, the in-vehicle system was sealed from the outside and the CAN bus can only be accessed on special occasions with the help of special tools; for example, the maintenance technician uses an OBD-II scanner to diagnose the system. Recently, the increased connectivity of vehicles increased the chances that the in-vehicle network is accessed, which exposed the CAN bus to more types of attacks. For example, the attack successfully accessed the CAN bus and sent messages on the bus remotely from the cellular connection [3].

Much work has been undertaken to boost CAN bus security. Generally, these measures can be categorized into two types: (1) cryptography [24,25,26,27], which originated from (a) controller authentication and (b) message encryption; and (2) firewall and physical separation.

(1a) Authentication requires that only authorized controllers can communicate over the bus systems. A general way to ensure authentication combining unsymmetrical and symmetric keys is presented in [24]. (1b) Encryption of the CAN message typically involves the data field [27]. The sender and receiver ECUs synchronously manage a sequence number. The sender can use the number and encryption algorithm, such as AES-128, to generate cipher text. After receiving the message, the receiver can decrypt the message and verify the source. In practice, implementing a real-time cryptographic solution can cause an overhead of extra computation and data transfer time. Thus, a clear trade-off between security, functionality, and efficiency should be taken into consideration.

(2) Firewall and physical separation. An effective way to prevent malicious attacks through an OBD-II port is to set up a firewall on the central gateway to filter the outside communication between the port and inside network [28,29]. However, implementation of a firewall usually requires more cost, and results in communication overhead, which should be within the consideration of the design. Physically separating the infotainment system from the main system inside networks can prevent certain types of attacks. The messages as well as the multimedia interfaces should be forbidden from interfering with the main system during normal driving operation. However, considering that several functions and components cooperate with each other to implement a complicated module, concerns regarding separation exist that the complicated operations on vehicles will be impacted.

The ECU is a kind of embedded system in a vehicle used to monitor the real-time state of the corresponding component and feedback the status parameters to the bus system. Meanwhile, the ECU processes the information exchanged from the bus system and takes control of operations to adapt the vehicle’s behavior. The number of ECUs ranges from about 40 in compact cars to about 90 in luxury cars. According to their functions, ECUs are loosely categorized into four types: powertrain, chassis, infotainment, and body control [30]. There are some key ECUs, such as EBCM, playing a critical role in manipulating a vehicle’s behavior; compromising them will directly kill the vehicle and endanger the driver’s safety [31]. In practice, many ECUs are coupled with each other to achieve some complicated control functions [5]. Thus, attacking a single ECU has the potential to impact large control functionality of the vehicle.

Attacks on ECUs might result from compromising a vehicle’s sensor network or exploiting the control module directly through diverse types of connectivity. As Paper [32] provided, a comprehensive guide of ECU vulnerabilities regarding different attack surfaces exist in many popular vehicles in the U.S. Specific attacks on ECUs include fuzzing, phishing, DoS [5], etc. A fuzzing attack aims at finding vulnerabilities by sending random packets to the ECU. Phishing attacks involve masquerading a trusted entity to gain sensitive information and compromise the system. The driver might be tricked by the phisher into flashing the firmware, which will cause permanent damage. In most cases, a fuzzing attack is the first step in creating a phishing attack. Typically, ECUs are configured when a vehicle is manufactured, and have a long lifetime. Therefore, other exploits on ECUs involve overwriting firmware and flashing ECU [31]. The firmware can be modified or replaced by performing a physical and valid update via an OBD port. Recently, an ECU update over the air (OTA) has been proposed [33,34], which would expose more security risks.

CVs adopt wireless communication to allow vehicles, roadside units, and mobile devices to communicate with each other and exchange critical information. In essence, CV is a kind of distributed system and imposes severe security and privacy challenges. It is anticipated that vehicle connectivity coupled with AV will revolutionize transportation systems, improve safety, and reduce costs, emissions, and energy consumption. In fact, the adoption of diverse types of vehicle connectivity on AV enables the exposure of potential vulnerabilities of the vehicle and results in a heightened risk of cyber-attacks on the CAV.

Bluetooth is a type of short-range communication (typically tens of meters) and was proposed to be applicable for the communications of CVs in some certain situations. For example, at a traffic intersection, Bluetooth can be used for connecting vehicle communication to avoid potential accidents [36]. Another scene is that Bluetooth may be applicable to V2P communication due to its low energy consumption, considering that pedestrian users in V2P usually have the limit on power saving of the device. However, as Bluetooth is natively developed for short-range low-speed transmission, it would be challenging when it is applied in highly mobile vehicles’ communication, which has the requirements of high transmission data.

In recent years, a few techniques have even been used to enhance the security of Bluetooth communication, including frequency hopping, a pre-shared key for authentication, and encryption [37]. Even so, some security risks cannot be avoided, yet, when Bluetooth is used in vehicles’ connectivity. In nature, how to handle the native security risks caused by the frequent iteration, various versions of Bluetooth, and pairing methods would be challenging. As a matter of fact, the reason why Bluetooth is so convenient to use in the first place is that it constantly broadcasts information such that nearby devices can be alerted to its presence. Thus, setting the Bluetooth device to “undiscoverable” mode would be a securer measure.

Bluetooth devices can form piconets, and multiple piconets through sharing the same devices can join to form a scatternet. If an entity is compromised, it is possibly going to infect other piconets or the scatternet, which finally damages multiple entities in the V2X connection. In addition, the MAC address of a Bluetooth device is usually unique and traceable, which may expose the vehicle to traceability attacks [6]. Even though a Bluetooth PIN is used between the paired Bluetooth devices to implement authentication, it is vulnerable to brute-force decryption, interception, and injection of a fake PIN [38]. What is worse, the compromised device can inject malicious messages into the paired vehicle and damage its functions. In [39], the authors showed how a user device connected to a vehicle through Bluetooth launches an attack on the vehicle. In [40,41], the authors investigated how Bluetooth-enabled devices are extremely vulnerable within and beyond the vehicle domain.

As another type of short range communication, Wi-Fi satisfies some types of V2X communications with the advantages of low cost and the ease of deployment [42]. In [43], Wi-Fi and WiMax provide viable solutions for V2V and V2I communications. Some researchers even suggested using Wi-Fi directly to facilitate the relaying of information from one vehicle to another [44,45,46]. The built-in Wi-Fi module or Wi-Fi enabled mobile device in a vehicle allows the vehicle to approach the internet when it is moving into the coverage of Wi-Fi hotspots, which is referred as the Drive-Through Internet. With the increasing deployment of the urban-scale WLAN (i.e., Google Wi-Fi in the city of Mountain View), the Drive-Through Internet would rapidly increase, which could provide a complementary solution to V2X with low cost. In actual design, some technologies are applied to enhance Wi-Fi capabilities to fit the high-speed and secure requirements of vehicular communications, such as Multiple-Input Multiple-Output (MIMO). Recent advances in Passpoint/Hotspot 2.0 provide Wi-Fi with some secure connectivity [47], which makes Wi-Fi more competitive in V2X communications.

Even so, Wi-Fi was not originally designed for a high-mobility environment; the stringent V2X service requirements impose some challenges on the reliability, robustness, and security of Wi-Fi-based V2X connectivity [48,49]. In terms of security, high vehicle mobility yields a very short connect time to the AP, while Wi-Fi communication usually requires a long establishing procedure. Time spent in Wi-Fi association, authentication, and IP configuration before actual data transmission cannot be negligible. For instance, if cryptography (i.e., Wi-Fi Protected Access, WPA) is applied in Wi-Fi communication, it will generate a considerable delay, up to 250ms, which is fatal to the safety-related application in VANET. In addition, Wi-Fi is typically set as the “discoverable” mode for users’ search and connection as Bluetooth, thus, it requires a large bandwidth to guarantee the high transmission, which provides opportunities for attackers to launch attacks such as cracking, DoS, and karma attack [50]. Especially, with security-enhanced WAP2 being cracked recently [28], it must raise more attention and research efforts to enable Wi-Fi in connected vehicles’ communication.

Cellular networks are considered a potential source that can guarantee the mobility and seamless connection in V2V and V2I. Existing solutions to connect vehicles together through widely deployed cellular infrastructure can be divided into two modes: brought-in and built-in [49]. The brought-in connectivity refers to that users in a vehicle tether their own smart phone to the vehicle’s infotainment system such that the vehicle gains immediate access to the internet and some duplicate functions of a smartphone. Incidentally, built-in connectivity integrates the cellular module into a vehicle’s on-board infotainment system, and the internet connection relies on a built-in module. C-V2X is a part of the overall 3GPP process to advance cellular systems from 4G to 5G technologies. Starting from Release 14 published by 3GPP, the LTE Direct and LTE broadcast laid the foundation for C-V2X, while after Release 16+, the 5G technology built new capabilities for C-V2X networks and augmented C-V2X direct communications over time [51,52]. As Khanh, Quy Vu et al. highlighted in [53], the power of 5G enables cellular and mobile communication networks to connect to hundreds of billions of devices with extreme-high throughput and extreme-low latency, including IoT, smart-connected vehicles, smart cities, smart agriculture, smart retail, and intelligent transportation systems. Built on many existing cellular infrastructures, the C-V2X service covers large areas, and has a high penetration rate and low cost to potentially support the high-bandwidth demands and QoS-sensitive requirements of vehicular applications.

C-V2X defines multi-types of services, including V2V, V2P and V2I, and V2N, and two modes of transmission, including network-based communication and direct communication [54]. It is also designed for both in-coverage and out-of-coverage services. C-V2X direct communications can support active safety and enhance situational awareness by detecting and exchanging information using low-latency transmission in the 5.9 GHz ITS band for vehicle-to-vehicle (V2V) as well as V2I and V2P scenarios. In practice, C-V2X needs to address some technical challenges, such as a high Doppler effect, resource scheduling, and synchronization [55].

Authentication is the primary step to ensure security in VANET, and much existing work proposed different techniques to provide authentication in VANET [29,62,63,64]. Usually, the symmetric key method is significantly faster than the digital signatures; however, the symmetric key method cannot provide non-repudiation [65]. Unsymmetrical keys can provide authentication and non-repudiation, but they may cause computation complexity and communication overhead [66], as well as privacy exposure [67]. Therefore, efficient unsymmetrical authentication with privacy preservation is needed. In recent years, group signature has been applied in VAENT to protect a vehicle’s anonymity besides authentication [68,69]. The main limitation of this approach is the computation complexity and communication overhead to distribute group keys [69,70]. In addition, a manager is needed to distribute the key to a new member when it joins the group or revoke the key when the member leaves. Invalid and malicious signers should be identified in time, while forward privacy should be protected at the same time [71,72]. Therefore, how to manage the key in a group signature is still challenging.

Privacy protection (e.g., vehicle’s location and trajectory) has been a top challenge in VANET [73]. Many approaches have been proposed to implement effective strategies of pseudonym changing [74,75,76,77,78]. However, the simple changing of a pseudonym is not sufficient to defend against pseudonym linking attacks, especially semantic linking, which can predict the next position of a vehicle and link the vehicle’s new pseudonym and the original one [79]. Currently, encryption or radio silence is suggested to defend against the semantic linking attack. However, encryption is ineffective against internal passive adversaries [74], and radio silence may negatively affect safety-related applications in VANET [80]. Therefore, a highly effective and reliable pseudonym change strategy is still needed to protect a vehicle’s privacy from semantic linking attack. In addition, a unified framework and metric is needed to quantify the privacy protection level, which will contribute to evaluating new privacy protection mechanisms [81,82,83].

Trust usually works as a complementary defense to cryptography in some specific situations. Specifically, trust mainly deals with inside attackers (e.g., passive attacks) and has little negative impact on message treatment and transmission delays, and thus, can be applied in both delay-sensitive and delay-tolerant traffic [84,85]. Even so, some issues should be considered when applying trust management in VANET security. Most exiting models assume that the adversary has stable and continuous behavior. However, smart attacks (e.g., an insider user becomes malicious) may become aware of the trust rule and can alternate between legal and illegal behaviors. Therefore, new trust models should adaptively detect such types of ‘unstable’ dishonest behaviors or entities. On the other hand, how to handle the location and identity privacy while ensuring efficient and reliable message dissemination is still one of the open issues in existing models [84].

Within the communication range of an RSU, multiple vehicles nodes may communicate with its neighbors via V2V or via V2I through RSU. As a result, the nodes will contend for the radio resources of the single RSU. When traffic density and message dissemination increase, the RSU may become saturated. Therefore, it is critical to make the communication near the RSU both secure and scalable. In practice, a challenging scheduling problem arises when RSU serves as a centralized scheduler for all the nodes within its coverage. On the other hand, RSU will possess great power to allocate resources to different nodes. It registers much private and secure information of each node within its range. Therefore, valid measures should be taken to block the power abuse of RSU, to prevent RSU from unfairly allocating resources to a certain node, and to maliciously invade or disclose the privacy of a node within its range.

Either C-V2X or VANET represents a promising solution to support V2X communication. At the moment, VANET has the advantage. The 5.9 GHz band made available in the U.S. more than a decade ago remains reserved for it, the EU also intended to make 802.11p the basis of the radio standard for safety-related messages between vehicles within ITS-G5. However, Qualcomm, which supports DSRC and offered second-generation 802.11p DSRC chips in the past, introduced its first C-V2X commercial solution in 2017; China appears ready to mandate C-V2X for C-ITS and safety-related services. No matter which one will become the standard to support V2X finally, the security issues in both types of networks should be well considered before they are widely developed to support CAV application.