Electric vehicles (EVs) are expected to account for almost 60% of global passenger vehicle sales by 2040. The associated e-powertrain components and software (SW) are also evolving in design, complexity, and security for these futuristic vehicles, constantly watching out to protect intelligent computerised systems such as EVs from hackers and malicious actors.
It is estimated that nearly a trillion connected cars will be on road by 2030 with new features and connectivity being added with ever increasing potential for cyber-attacks. As the number of EV manufacturers has grown from a handful to more than 50 over the last decade (counting both traditional OEMs and start-ups), new features and functionality are being given priority from the sales and marketing teams, overriding concerns being expressed by Chief Information Security Officers (CISOs) or Cybersecurity or Functional Safety (FuSa) teams.
Though it is anticipated that the new UNECE certification for cybersecurity will improve this imbalance, it still does not appropriately address the rate of attacks of almost once every 39 seconds on connected vehicles. Recent figures dubiously indicate that cybercrime is more profitable at $ 600 billion than the global, illegal drug trade at $ 400 billion, with 75 records stolen every second and traded in more than 6,000 online criminal marketplaces for ransomware.
For OEMs, proactively preventing cyber-attacks and complying with UNECE regulations mandated for all new vehicle types after July 2022 and all new vehicles after July 2024 is still a better proposition than justifying the downstream costs, expensive recalls, and software patches/ updates. However, taking over cybersecurity software and related operations is a daunting task for automotive OEMs as most of them are dependent on suppliers for components/ software, do not have familiarity or in-house expertise or dedicated personnel or role clarity between different SW development teams.
As vehicles become increasingly intelligent and evolve towards connected, autonomous, and electric vehicles (CAEVs), the vehicle functions are growing increasingly dependent on effective, efficient, and most importantly, secure communications. As higher levels of autonomous driving are achieved in vehicles, moving away from the traditional Advanced Driving Assistance Systems (ADAS), enormous amount of data is exchanged between the on-board sensors, Electronic Control Units (ECUs), and control centres to fulfil efficient and optimal driving, vehicle coordination, effective path planning and route/energy optimisation.
An added requirement for EVs would be scheduling of bi-directional charging and discharging together with route planning and traffic control. In these scenarios, Vehicular Communications Networking (VCN) & Wireless Vehicle Integration of different applications, as shown in Figure 1 [1] play an important role. The wireless system design must be carefully tailored for core vehicle functions and in turn the design of vehicle functions must account for the wireless limitations as well.
The Internet of Vehicles (IoVs), also known as connected vehicles, is a wide network that includes multiple entities such as vehicles, pedestrians, cyclists, sensors, etc. and aims to enhance traffic safety and driving efficiency, improve driving experience, and prevent accidents. IoVs employ different communication technologies such as IEEE 802.11p WAVE, cellular technologies, etc. which are being increasingly applied on autonomous and electric vehicles.
As range anxiety, optimal battery performance, and dynamic (nearest) charging station availability are the key requirements for EV customers, many organisations have been working on developing simulated platforms and energy maps for CAEVs that will be used to propose innovative services for the optimisation of battery consumption through the study of multiple routes, thermal management, and prediction of battery performance.
The IoV or specifically IoEV (Internet of Electric Vehicles) enables vehicles to communicate with on-board sensors (internal to vehicle) and with other entities such as vehicles, servers, humans, traffic signals, and charging stations (external to vehicle).
A representative IoEV communication architecture is shown in Figure 2 [2], which includes V2S protocol for internal environment as well as V2X and EVSE2X for external environment. The IoEV architecture aims to integrate information and communication technologies for CAEVs to improve battery efficiency, traffic control, route optimisation, thermal management, dynamic charging station information, and the re-charge time.
CAEVs regularly communicate with backend server and provide real time information such as vehicle ID, location, battery cell temperature, State of Charge (SOC), HVAC status, distance to empty (DTE), distance to destination, etc. The server can analyse this information and superimpose the data with road infrastructure information (potholes, crevices, speed bumps, etc.), road traffic (accident, traffic congestion, etc.), and weather condition (rain, snow, thunderstorm, etc.) to construct an energy map that contains data related to EV energy consumption.
This map can be used by automotive OEMs or data analytics service providers to propose innovative services to CAEVs such as lowest energy path to reach destination, nearest available charging stations, optimal thermal management etc.
The IoEV architecture comprises multiple V2X (V2S, V2V, V2I, V2N, V2H) and EVSE2X (EVSE2EV and EVSE2N) communications for internal and external environment to CAEVs.
i) Vehicle-to-Sensor on-board (V2S) connects a vehicle with the embedded sensors in a wired or wireless network to monitor and acquire real-time information about the vehicle state and the surrounding environment. This data is communicated to relevant ECUs for further processing and action. The sensors and the ECUs can communicate either in wired networking formats such as Local Interconnect Network (LIN), Controller Area Network (CAN), FlexRay and Media Oriented Systems Transport (MOST) or in wireless mode such as Device-to-Device (D2D) out-band mode (Zigbee, WiFi Direct, Bluetooth, Ultrawideband, etc.), as shown in Figure 3 [3]. Wireless communications are found to be the most appropriate solution for V2S due to less complexity and low cost.
ii) V2V (Vehicle-to-Vehicle) communication allows vehicles to communicate and interact with each other. The best-known technologies that ensure V2V connection are the IEEE 802.11p standard (DSRC/ WAVE) and D2D communication, alternately known as Proximity Services (ProSe). The advantage of D2D is it allows two devices/ vehicles to communicate with each other in the licensed cellular bandwidth with or without Base Station (BS) involvement. Research has shown that 802.11p performs better than D2D communications in terms of packet reception probability and packet inter-reception time, especially in high traffic density situations.
iii) V2R (Vehicle-to-road Infrastructure) or V2I (Vehicle-to Infrastructure) connects vehicles with the infrastructure such as Road-Side-Units (RSUs), traffic signals, road signs, and sensors along a road to help monitor traffic and road conditions. The V2R communications also utilise IEEE 802.11p standard (DSRC/ WAVE) or D2D protocol.
iv) V2I (Vehicle-to-Internet) or V2N (Vehicle to Network) provides a direct communication between vehicles and the Internet based on cellular technologies (3G, 4G, 5G), roadside WiFi access point (AP) and satellite. Mobile Femtocell (MFemtocell) or mobile small cell has been introduced to meet the high mobility of the Intelligent Transportation Systems (ITS), refer Figure 4 [4].
MFemtocell combines both mobile relay and Femtocell technologies with the aim to speed up internet access. MFemtocells can be defined as small cells that are embedded inside the vehicles to communicate with users within the vehicle, while large antenna arrays are located outside the vehicle to communicate with the Base Station (BS). The use of MFemtocell is essential for the establishment of V2N connection. The 5G technology is superior to 3G and 4G and has been proved to be perfectly meeting the requirements of wireless vehicular networks for V2X communications.
v) V2H (Vehicle-to-Human) or Vehicle-to-Pedestrian (V2P) communication works mainly on cellular technologies (3G, 4G, and 5G) and connects both vehicles and humans (passengers, drivers, etc.) via smart devices (smartphone, tablet, smart watch, etc.) using Apple CarPlay or Google Android of Open Automotive Alliance (OAA) or Near Field Communication (NFC).
vi) Electric Vehicle to Electric Vehicle Supply Equipment (EV2EVSE) communication connects EVs to the electric charging stations using IEC 61851-24:2014 (or IEC 61851-23) standard protocol for the control of conductive charging of battery, with an AC input voltage up to 1,000 V AC or DC input voltage up to 1,500 V DC.
vii) Electric Vehicle Supply Equipment to Network (EVSE2N) enables communication between electric charging station and the internet (control centre, etc.) using cellular technologies such as WiMAX (based on IEEE 802.16 standard) for wireless links of IoT, IoV, and IoEV at broadband speeds.
Cybersecurity Issues in IoVs/IoEVs
For effective communication with and between CAEVs, they must exchange lots of information with the data servers such as vehicle ID, location, battery SOC, HVAC status, distance to travel, etc., which might be subject to many types of attacks such as Denial of Service (DoS), modification, eavesdropping, spoofing, false data injection, privacy attacks, etc.
A schematic of potential cyber vulnerabilities is presented in Figure 5 [3]. These attacks can affect correct operation of the servers and provide false estimation of SOC, prediction of energy consumption, and wrong location of nearby charging station. An overview of security issues, the cyber-attacks that CAEVs may have to face, and the impact they have on the IoEV architecture are presented next.
As CAEVs communicate through wired or wireless networks, hackers also attempt hacking using either or both means.
i) Mobile app hacks: As app developers and automotive OEMs are increasingly using mobile phones to access remote controls and feature changes in vehicles, hackers are gaining access to the vehicles using these apps, which may also result in compromise on personal data. Critical vulnerabilities have been found in several apps that have been downloaded by millions of mobile phone users/ vehicle owners. In many cases, these apps have been found to be of low security, lacking basic defence mechanisms, wherein the users have been tricked by hackers into providing access to sensitive/ personal information. The hackers could then lock/ unlock the vehicle, access real-time information of the vehicle, remotely turn on/ off the ignition, etc.
ii) Malware in disguise: Another way hackers can gain access to vehicles is through unprotected Bluetooth devices and MP3 players, disguising a potential virus or malware as a music track and compromising the system, when users unknowingly download and play it. This malware could also find its way into vehicles through Bluetooth connection between smart phones and vehicle systems. It has been found that hackers study the data patterns of the users (driving behaviour, music tastes, routine visits to gyms, favourite restaurants, etc.) to build the database and look for privacy violation opportunities.
iii) Server hacks: The server hacks are extremely dangerous and sensitive that can give attackers access to lots of information on connected mobile apps, sales data, user profiles, and even information of all the vehicles connected to the server, potentially causing a debilitating domino effect on fleet operators, dealers, car rental agencies, e-commerce delivery companies, sales routes, etc.
Cybersecurity Issues in IoEV Architecture (Wired & Wireless VCN)
Cyber-attacks on Wired & Wireless Communication Networks in IoEV architecture are detailed below in terms of V2X and EVSE2X communication networks.
A) Vehicle to Sensor (V2S) Communication Attacks
i) Wired communications attacks enable the hackers to control the vehicle networks such as CAN, LIN, MOST, FlexRay etc., resulting in Denial of Service (DoS), increasing vulnerability to malware, and negatively impacting the essential connected services.
ii) Wireless Sensor Networks attacks can be carried out through multiple avenues such as Tyre Pressure Monitoring System (TPMS) or In-Vehicle Infotainment (IVI) System etc., adversely impacting the In-Vehicle Networking (IVN) by spreading through different vehicle sensors indicating temperature, position, current, voltage, speed, etc. and different IVN nodes. The jamming attacks may prevent data acquisition or provide wrong information from sensors to relevant ECUs and subsequently to the data server, severely impacting the performance of CAEVs. The attacks may also provide inaccurate or misleading information to the driver, directly affecting the safety of the vehicles and the occupants.
iii) False data injection attack: In this type of attack, false data may be injected about battery SOC, temperature, vehicle speed, voltage, wheel torque etc., which in turn may provide false data to the relevant ECUs and the data server. This may give false sense of security to the driver & the occupants (e.g., wrong range and charging station information) and impact the performance and safety of the vehicle.
iv) GPS deception:This type of attack, shown in Figure 6 [5], misleads the data server or ECUs or the driver by providing false location and GPS information resulting in wrong route calculation, inaccurate charging station information, misleading distance to destination, etc. Combined with inaccurate battery consumption prediction and wrong route information, CAEVs may not be able to get correct battery energy consumption or the most reliable route. This problem may become acute in remote places or rural areas, which may not have charging stations or supporting infrastructure.
v) Denial of Service (DoS): In this attack, an ECU may be bombarded or overloaded with spurious, unwanted messages and rendered incapable to collect information from sensors or send information to the data server, causing Denial of Service (DoS).
B) Vehicle to Vehicle (V2V) Communication Attacks
There are several attacks in V2V communication framework. Some of them include:
i) Selfish attack: A CAEV may be tricked in this type of attack to defy the commands and refuse to cooperate with other CAEVs to relay information to the server. Further, as the selfish attack spreads to multiple nodes, depending on the routing protocol, there will be severe breakdown in communication between CAEVs and data server or among different CAEVs.
ii) Modification attack: In this attack, the content of the messages between CAEVs and the data server may get tampered with or modified. Important information such as battery SOC, distance to destination and nearby charging station location may be tampered with giving wrong/ misleading information to the driver and even stranding a vehicle with little or no charge. As the attacker can even modify/ falsify the data/ information exchange between CAEVs and the server such as cell temperature, SOC, vehicle speed, location, etc., it adversely affects the construction of on-board energy map and directly impacts the optimal battery management and operational efficiency of the CAEV.
iii) Sybil attack: In this attack, a malicious node may present itself under multiple identities in different locations (such as charging stations) and carry out false data injection into the network resulting in wrong/ inaccurate decisions by the server and suboptimal performance of CAEVs and ITS, as shown in Figure 7 [3]. An attacker may inform the legitimate drivers that the road ahead is congested while it may be free. Accordingly, the Sybil attack may prevent the server to receive real-time data about a particular road segment. The Sybil attack may provide wrong/ misleading information about a charging station, potentially causing the driver to make wrong decision. Additionally, the Sybil attack may also not allow the driver to reach the next charging station.
iv) False data injection attack: In this attack, shown in Figure 8 [3], an infected node may send false information to nearby vehicles or to the server on real-time position, cell temperature, SOC, HVAC status etc., resulting in inaccurate energy calculations, wrong energy management, and inefficient operation of CAEVs.
v) Eavesdropping: As the title indicates, in this attack, an unauthorised node can eavesdrop on sensitive information about the vehicle (ID, real-time position, driver habits, etc.), which may lead to compromise on data privacy or identity theft.
vi) Black Hole attack: In this attack, a CAEV is put into an illusion that it belongs to the shortest path to intercept the transmitted packets. The hacker may drop the message and refuse to broadcast it, resulting in a denial of service (DoS) attack on the system, while on the other hand the system could not actually collect enough information (due to lack of broadcast) to make accurate decisions such as energy predictions, optimal route calculations, etc.
vii) Gray Hole attack (selective forwarding attack) is an extension of Black Hole attack, with similar behaviour/ consequences. However, the Gray Hole attack is more severe than the Black Hole attack as the attacker can selectively drop messages, causing illusion/ wrong impression to the CAEV and its driver. For example, the malicious node may decide to forward all kinds of messages except traffic-safety messages or requests for energy-consumption prediction, creating false sense of security.
viii) Wormhole attack: Here, the hacker intends to revoke legitimate links between vehicles or route any exchanged data through the attacker. Thus, malicious entities that are situated in completely different geographical locations may collude in order to forward packets to unauthorised area, bypassing the actual intent. In this attack, when an attacker receives a message in a well-defined network point, it encapsulates the message and forwards it to another attacker to reintroduce this message in the network. Thus, more and more malicious entities take control of the network, seriously impacting the data exchange and network functionality.
ix) Denial of Service (DoS) attack: In this case, the attacker prevents the system to perform either partially or entirely and in addition also prevents CAEVs to communicate with each other or the server.
C) Vehicle to Infrastructure (V2I) Communication Attacks
For effective communications with each other and the server, CAEVs must obtain unique IPv6 addresses that indicate their unique IDs. ITS uses a stateless address auto-configuration (GeoSAC), which is a scalable address auto-configuration for Vehicular Ad hoc Network (VANET) using geographic networking concepts. Each IPv6 address of a CAEV constitutes a network prefix that is sent by a Roadside Unit (RSU), which is essentially a router in the ITS and an Extended Unique Identifier-64 (EUI-64) formatted interface that is encoded in 64 bits.
The EUI-64 interface identifier is derived from the Media Access Control (MAC) address of the vehicle. Each RSU periodically sends a Router Advertisement (RA) that contains the IPv6 prefix to all vehicles located in its geographical area. Below, we detail out the attacks on ITS router discovery, where RSU sends RAs to all the CAEVs irrespective of whether they are in the coverage area of RSU or not.
Different communication attacks on V2I network are given below.
i) Replay attack: As shown in Figure 9 [2], the affected vehicle of this attack replays an old router advertisement to other CAEVs. Hence, the affected vehicles can no longer connect to the legitimate RSU and as the vehicles travel further, they are unable to connect to the next IPv6 address, which is incorrect (RA1 vs RA2 and RSU1 vs RSU2). The replay attack will prevent the sever from collecting information from vehicles and to update the energy map in vehicles, thus impacting their performance.
ii) Router Advertisement Attack: In RA attack, an infected node (vehicle) can forge an RA message with an invalid next hop address preventing the nodes of neighbouring vehicles to connect to the Internet and thus to the server. As can be seen in Figure 10, no communication can be established between the vehicles and the RSU or the data server. In another variant of RA attack, false data injection (FDI) is carried out with invalid prefix in the RA, adversely impacting the CAEVs and the ITS.
iii) Privacy attacks: In this attack, a malicious node on the internet can create a cartographical map of a vehicle using the prefix sent by the RSU in the RA message associated with a geographical area. This node can then easily track a vehicle based on this temporary address with implications on privacy and potential identity theft.
iv) RSU spoofing: In this attack, a malicious node tries to spoof the IP address of the RSU and send an invalid prefix. As the impacted vehicle is configured with an invalid temporary address (CoA), there is a marked impact on the mobility & performance.
v) Denial of Service (DoS) attack: In IoEV architecture, there is a possibility of DoS attack on the IPv6 Duplicate Address Detection (DAD) feature that ensures that all the IP addresses assigned on a particular segment are unique. The attacker falsifies response to all address duplication detection messages that the requested IPv6 address has already been taken, when in fact the victim node will never be able to obtain an IPv6 address – results in Denial of Service (DoS).
D) Vehicle to Network (V2N) Communication Attacks
Hackers can carry out multiple attacks including DoS attacks as V2N communications that are based on cellular technologies (3G, 4G, 5G), roadside WiFi access point (AP), and satellite are vulnerable. In DoS attack on a roadside WiFi AP, the attacker can send a large number of simultaneous messages to the AP causing message bombardment, which can saturate the memory and the bandwidth of the WiFi AP causing Denial of Service.
Hackers can carry out many attacks on MOBIKE (MOBility extension to Internet Key Exchange), which is an extension of Internet Key Exchange version 2 (IKEv2) and is also the most important security protocol used by mobile femtocell. As MOBIKE allows key data exchange between the Mobile Femtocell and the core network and IP multihoming without re-establishing all SAs (Security Association) and IPsec tunnels, it is vulnerable to attacks such as Denial of Service (DoS), Man-in-the-Middle (MiTM) and spoofing. In spoofing attacks, hackers can confuse the IPv6 addresses and the CAEV location, denying exchange of information with the data server and impacting the operational efficiency of CAEVs.
An additional attack by hackers could be on Home eNodeB, or HeNB, which is the 3GPP's term for an LTE femtocell or Small Cell. A HeNB performs the same function of an eNodeB (an element of an LTE Radio Access Network) but is optimised for deployment for smaller coverage than macro eNodeB, such as indoor premises and public hotspots. A HeNB can be subject to several attacks, including physical attacks, configuration attacks, protocol attacks, denial of service (DoS) attacks, and privacy attacks.
In physical attacks, the hacker can modify or replace HeNB components. In configuration attacks, the hacker can carry out misconfiguration of the Access Control List (ACL) of the targeted HeNB. In protocol attacks, the hacker can also include Man-in-the-Middle (MiTM) attacks on HeNB. In DoS attacks, the hacker can deny service on mobile operator’s core network. In privacy attacks, the hacker can tamper with user data and do identity theft. Additionally, attackers can also tamper with radio resource management of the HeNB node, causing the HeNB node to provide incorrect radio resource information.
As cellular technologies are evolving, the 5G networks are perceived as a revolution for V2N communications. Vehicles can connect to the 5G cellular network via direct links with the mmWave small cells or by relay via other devices using D2D communication when Line-Of-Sight (LOS) communications are not available. Despite advances in 5G networks, hackers can still carry out eavesdropping and privacy attacks on the mmWave and the D2D communications by installing receivers on the roads, identifying the source of the transmitted packets, and dynamically tracking the vehicle. Additionally, as 5G networks cater to Massive Machine Type Communication (MMTC) and can support Ultra-Dense Networks (UDNs), CAEVs using 5G networks are vulnerable to jamming attacks.
E) Vehicle to EVSE (V2EVSE) Communication Attacks
Common EVSE connector standards include SAE J1772 Level 1 and Level 2, SAE J1772 CCS, CHAdeMO, and GB/T 27930. The maximum power delivery for Level 1, Level 2, CCS, and CHAdeMO are 1.92 KW, 19.2 KW, 400 KW, and 400 KW, respectively. While the primary communication for Level 1 and Level 2 is Pulse Width Modulation (PWM), it is Power Line Communication (PLC) for CCS, and Controller Area Network (CAN) for CHAdeMO protocol.
In Figure 11 [6], different EVSE cybersecurity measures are shown, which touch upon firmware updates, on-site power management, and third-party updates catering to different charging protocols.
Physical Access Risks to EVSEs: The most obvious threats to EVSE are physical access risks. Physical access to the EVSE control boards through external ports, including USB or serial interfaces, leads to risks that could place EVSE firmware or Personally Identifiable Information (PII) related to the vehicle at risk.
By gaining physical access to the EVSE control board, attackers can modify charge controller firmware or gain access to configuration files or tamper with data exchange with servers. Through physical access, an attacker can access the configuration files or the communication between an EVSE and web server and could also acquire personal information, such as billing history and customer identification.
EVSE companies can mitigate physical access risks to all EVSE by – a) removing all jacks that are externally accessible from the EVSE unit; b) incorporating strong encryption of the controller boards in the EVSE and including flash memory and board-to-board communication; c) including a tampering alarm or signal to the service provider, and d) employing secure coding practices and auditing the source code.
Remote Access Risks to EVSEs: Using remote access, EVSE units sometimes coordinate and share information with a vendor through wireless communications. The remote services include firmware updates, customer verification, and payment processing, which may be exposed to remote hacks. The hackers may access customer information or firmware, stored on file transfer protocol (FTP) or database servers.
Alternately, personal data stored on a database or used by a web server may be acquired using either Standardised Query Language (SQL) injections or cross-site scripting (XSS). Additionally, malicious firmware may be uploaded to unsecure FTP sites and potentially compromise the operation of the EVSE.
Using SAE J1772 CCS protocol, an EVSE can supply DC power directly to the vehicle’s traction battery, circumventing the vehicle’s internal rectifier. The direct DC charging of the battery calls for more extensive communication protocol between the EVSE and EV comprising a seven-layer open system interconnection (OSI) architecture. The specific ISO-15118-2 standard focuses on five of these layers, including network, transport, session, presentation, and application.
As per ISO-15118 standard, CCS-type EVSE can operate in offline, semi-online, or online mode, charging EVs in public or private environments. Public environments are charge station spots meant for public charging, and private environments are confined to fleet owner, facility, or personal usage, and are typically in secure locations. Transport Layer Security (TLS) enables secure communication between the EV and EVSE through an encrypted channel in which the EV provides authentication for the EVSE. This ensures the data stream maintains both integrity and confidentiality.
Cyber-attacks on CCS-type EVSE include spoofing, tampering, MiTM, eavesdropping, and DoS. Risk mitigations for CCS charging protocol include – a) unilaterally authenticated TLS communication; b) highly protected storage of digital certificates and private/ public keys; c) usage of secure digital signature and encryption for all vulnerable messages, and d) usage of secure RFID standard implementation.
Conclusion
The IoEV architecture facilitates wired and wireless communication networks for CAEVs to exchange information with each other and the data server using V2X and EVSE2X protocols. For dynamic energy map construction, optimal battery performance and driving range, and connected services, it is imperative for CAEVs to constantly exchange data over secure communication channels with other vehicles and the data server.
Over the years, cybersecurity teams in automotive world have been identifying, quarantining, and proactively preventing many attacks such as DoS, FDI, modification, eavesdropping, sybil, blackhole, privacy, etc. to provide connected services to CAEVs and ensure optimal driving range, battery performance, and semi-autonomous driving capabilities.
Manufacturers can mitigate cybersecurity risks associated with CAEVs by:
- Resorting to a safe operational mode if erroneous sensor data is detected, such as alerts and driver intervention with SAE automation levels 1 through 3;
- Using secure communication infrastructure, such as Dedicated Short-Range Communication (DSRC) and including instruction detection and prevention systems like firewalls, secure shell verification of the network and the device, key management, private access point names, and password cryptography;
- Incorporating secure authorisation and authentication, encryption, and network segmentation for safety-critical messages and OTA updates in modern vehicles.
Future Work
As it is important to carry out risk quantification based on specific risk metrics, it is important to first establish the appropriate risk metrics. There is no clear rating system akin to 5-star crash rating system for vehicles (frontal, rear, side pole, offset deformable barrier, etc.) or energy rating system for appliances (A/C units, refrigerators, washing machines). Also, customers by default expect automatic compliance with cybersecurity standards and regular updates/ SW patches to address potential weak spots for hackers to exploit.
Researchers continue to develop an adaptive security strategy that handles V2S inside the vehicle and V2X (V2V, V2I, V2N) outside the vehicle separately. For V2S communication internal to the vehicle, the risk metrics are identified based on type of sensor, available energy, battery status, cell chemistry, nearby electric charging stations etc. For V2X risk identification external to the vehicle, the adaptive security decisions must consider the type of available network (cellular network, Wi-Fi, 802.11p, WiFi AP, satellite etc.), energy level of the battery, available electric charging stations, etc.
References
[1] Cheng, X. et. al, “5G-Enabled Vehicular Communications & Networking,” Springer Nature Switzerland AG2019, https://doi.org/10.1007/978-3-030-02176-4
[2] Fraiji, Y. et. al, “Cybersecurity issue of Internet of Electric Vehicles,” 2018 IEEE Wireless Communications and Networking Conference (WCNC, DOI: 10.1109/WCNC.2018.8377181
[3] El-Rewini, Z. et. al, “Cybersecurity challenges in vehicular communications,” Vehicular Communications, Vol. 23, June 2020, 100214, https://doi.org/10.1016/j.vehcom.2019.100214
[4] Chekkouri, A. S. et. al, “Connected vehicles in an intelligent transport system,” Vehicular Communications and Networks, Vol. 23, June 2020, 100214, Elsevier Ltd. 2015, pp. 193-221. https://doi.org/10.1016/B978-1-78242-211-2.00010-6
[5] Parkinson, S. et. al, “Cyber threats facing autonomous and connected vehicles: Future Challenges,” Vehicular Communications, IEEE Transactions on Intelligent Transportation Systems, March 2017, https://doi.org/10.1109/TITS.2017.2665968
[6] Hodge, C. et. al, “Vehicle cybersecurity threats and mitigation approaches,” 2019 National Renewable Energy Laboratory. NREL/TP-5400-74247. https://www.nrel.gov/docs/fy19osti/74247.pdf
About the Author: Dr Arunkumar M Sampath heads Electric Vehicle projects at Tata Consultancy Services (TCS) in Chennai. His interests include hybrid and electric vehicles, connected and autonomous vehicles, cybersecurity, extreme fast charging, functional safety, advanced air mobility (AAM), AI, ML, data analytics, and data monetisation strategies.