https://www.mobilityoutlook.

com/features/cybersecurity-issues-in-connected-autonomous-electric-
vehicles-caevs/

Cybersecurity Issues In Connected, Autonomous,

Electric Vehicles (CAEVs)

Dr Arunkumar M Sampath
11 Jan 2022

10:00 AM

18 Min Read

As vehicles become increasingly intelligent and evolve towards CAEVs, the vehicle functions are
growing increasingly dependent on effective, efficient, and secure communications.
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.

Figure 1: Vehicular Communications Networking (VCN) & Wireless Vehicle Integration [1].

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).

Figure 2: IoEV Communication Architecture [2].

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.

Figure 3: Vehicular Sensing, Communication, and Controls framework [3].

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.
Figure 4: LTE-A networked femtocells for VANETs [4].

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.

Figure 5: Schematic of Cyber vulnerabilities in a vehicle [3].

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.
Figure 6: GPS Spoofing Attack [5].

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.

Figure 7: Sybil Attack [3].

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.
Figure 8: False Data Injection Attack [3].

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.

Figure 9: Replay Attack [2].

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.

Figure 10: Router Advertisement False Data Injection Attack [2].

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
Figure 11: EVSE Cybersecurity Measures [6].

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.