Identifying Cybersecurity
Focus Areas in Connected Cars
Based on WP.29 UN R155
Attack Vectors and Beyond
Numaan Huq, Rainer Vosseler, Yurika Baba

Contents
TREND MICRO LEGAL DISCLAIMER
The information provided herein is for general informationand educational purposes only. It is not intended andshould not be construed to constitute legal advice. The
information contained herein may not be applicable to all
situations and may not reflect the most current situation.

4
Introduction

Nothing contained herein should be relied on or acted
upon without the benefit of legal advice based on theparticular facts and circumstances presented and nothingherein should be construed otherwise. Trend Microreserves the right to modify the contents of this document
at any time without prior notice.
Translations of any material into other languages are

9
Threat Modeling the Connected
Car Ecosystem

intended solely as a convenience. Translation accuracy
is not guaranteed nor implied. If any questions arise
related to the accuracy of a translation, please refer tothe original language official version of the document. Any
discrepancies or differences created in the translation are
not binding and have no legal effect for compliance orenforcement purposes.

20
Evolution of Threats Against
Connected Cars

Although Trend Micro uses reasonable efforts to include
accurate and up-to-date information herein, Trend Micromakes no warranties or representations of any kind as
to its accuracy, currency, or completeness. You agree
that access to and use of and reliance on this document
and the content thereof is at your own risk. Trend Microdisclaims all warranties of any kind, express or implied.

28
Additional Areas of Focus forConnected Car Security

Neither Trend Micro nor any party involved in creating,producing, or delivering this document shall be liable
for any consequence, loss, or damage, including direct,
indirect, special, consequential, loss of business profits,or special damages, whatsoever arising out of access to,use of, or inability to use, or in connection with the use ofthis document, or any errors or omissions in the content
thereof. Use of this information constitutes acceptance for

35
Mitigating UN R155-DefinedThreatsuse in an “as is” condition.

Published byTrend Micro Research
Written by

Numaan Huq,
Rainer Vosseler,
Yurika Baba
Stock image used under license from
Shutterstock.com

For Raimund Genes (1963 – 2017)40
Conclusion

The UNECE World Forum for Harmonization of Vehicle Regulations(WP.29), is a worldwide regulatory forum within the institutional frameworkof the UNECE Inland Transport Committee.1 They published the“Uniform provisions concerning the approval of vehicles with regards tocybersecurity and cybersecurity management systems.”2 This document,
which is known as UN Regulation No. 155, contains seven high-level and
30 sub-level descriptions of vulnerabilities and threats, including 69 attack
vectors directly affecting vehicle cybersecurity.
For this research paper, we calculated the severity levels of the attack
vectors listed in UN Regulation No. 155, using the industry standard
DREAD threat model. We also studied the connected car ecosystem andpredicted how it will evolve with the rollout of high-speed 5G networks.
We then recalculated the DREAD threat model to show how threat severity
will evolve over the next five to 10 years. Finally, we highlighted focus
areas and cyberattack vectors not included in the regulation, but which
will likely necessitate defenses against in the future. All this was done tohelp stakeholders better determine how to prioritize, plan, and act against
these attack vectors.

Introduction
The regulatory frameworks developed by the World Forum WP.29 allows for the market introduction of
innovative vehicle technologies while improving global vehicle safety.3 In the 181st session of the World
Forum for the Harmonization of Vehicle Regulations, the ECE/TRANS/WP.29/2020/79 “Proposal for a new
UN Regulation on uniform provisions concerning the approval of vehicles with regards to cybersecurity
and cybersecurity management systems” was adopted, and became binding on January 22, 2021.4 This
proposal was formally published as UN regulation No. 155 (also called UN R155), “Uniform provisions
concerning the approval of vehicles with regards to cybersecurity and cybersecurity management
systems,” on March 2021.5
Annex 5 of the UN Regulation No. 155 contains seven high-level and 30 sub-level descriptions ofvulnerabilities and threats that include 69 attack vectors directly affecting vehicle cybersecurity. These
attack vectors include threats against back-end servers, vehicle communication channels, external
connectivity and connections, and software update procedures. Car manufacturers, suppliers, governmentorganizations (at both the local and federal levels), third-party service providers, and all other stakeholders’cooperation and efforts are necessary for the successful implementation of the regulation.
One of the first courses of action for stakeholders with regard to this regulation will be to sort these attack
vectors according to their expected threat severity levels. This paper does that by using the industry
standard DREAD threat model. We calculated the severity levels of the attack vectors listed in UN
Regulation No. 155. We also studied the connected car ecosystem as it exists today, and predicted how
the ecosystem will evolve with the global rollout of high-speed 5G networks. Applying these predictions,
we recalculated the DREAD threat model to show how threat severity will shift in the next five to 10 years.
Finally, we highlighted focus areas and cyberattack vectors that we deemed missing from the WP.29
document, but which will also require protection against future cyberattacks.

4 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

The Connected Car Ecosystem
As rapid scientific and technological innovations shape our world, autonomous vehicles are expected
to be on the road as everyday transportation within the next decade or two. Semi-autonomous vehicles
that communicate with cloud services, other vehicles, and road infrastructure to improve vehicle safety,
assist with driving decisions, and provide access to cloud services will also become commonplace. As
5G networks rollout globally, connected cars will heavily utilize the low-latency, high-bandwidth, andnetwork slicing features of 5G. The 5G network backbone, together with advances in Artificial Intelligence(AI) and Machine Learning (ML) applications that process both onboard and in-cloud data, will bring fullyautonomous vehicles one step closer to reality. With all of this to look forward to in the near future, it is

oth

RDS

lite

tel

eto

X

Sa

Blu

V2

e

bil

Mo

,W

i-F

i

important to first define what connected cars are.

eSIM

V2V

Back-end
cloud services

Vehicle internal network
Powertrain

Communications

Body
controlPowermanagement

ChassisSafetyEngine control
unit

Head
unit

Door
locks

Hybridpowertrain

Adaptive
suspension

CamerasystemTractioncontrol

Mobileconnection

Climatecontrol

Battery
management

Electronicstability control

Radar/LidarPowersteering

Telematics

Powerwindow

Energyrecovery

Active steering

Airbags

ACC, etc.

GPS, etc.

Sunroof, etc.

Actuators, etc.

Active bodycontrol, etc.

Tire pressure
monitoring system,
etc.

Figure 1. Technologies and functionalities that form the internal network of a connected car

Today’s cars already come with an incredible amount of connected technologies. New car models typicallyrun more than 100 million lines of code. Even the most basic cars have at least 30 Electronic Control Units(ECU), while luxury vehicles can have more than 100 ECUs connected across a labyrinth of different
digital buses, such as Controller Area Network (CAN), FlexRay, Local Interconnect Network (LIN), Media
Oriented Systems Transport (MOST), and Ethernet, each operating at different speeds, carrying different
types of data, and enabling connections across different parts of the car.6

5 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

The modern car already receives satellite data for playing radio stations and getting GPS coordinates.
In the future, cars will have cellular-satellite connectivity for data, which is especially useful when driving
through regions with poor cellular coverage. Most new car models have a built-in eSIM, which is used totransmit telematics data, communicate with back-end cloud servers, create Wi-Fi hotspots, get real-timetraffic information, transmit location for E911, and other functions. With the introduction of Apple CarPlay
and Android Auto, mobile phone connectivity in cars has transformed from making phone calls and having
address book access to a full-on system that gives users access to applications, maps, music, calls,
messaging, etc. Radio Data System (RDS) is used to embed small amounts of data in FM broadcasts.
Using RDS-TMC (Traffic Messaging Channel), cars can also receive real-time traffic alerts, which aredisplayed in the head unit (the car’s infotainment hub). In-car Bluetooth and Wi-Fi connectivity are alreadycommon — drivers’ mobile phones connect via Bluetooth to the head unit for playing music, making
hands-free phone calls, share the phone’s address book, etc. Cars like Tesla can connect to the home
Wi-Fi to download over-the-air (OTA) software updates.7 Vehicle-to-everything (V2X) communications
includes vehicle-to-vehicle, vehicle-to-infrastructure, vehicle-to-network, vehicle-to-pedestrian, vehicleto-device, and vehicle-to-grid communications. In the future, autonomous vehicles will rely heavily on V2X
to safely navigate the roads.
Figure 2 shows what we envision a cloud-connected vehicular architecture to look like. The head unit
supports running applications. A software middleware layer abstracts the electrical and electronics (E/E)
architecture of the car and makes it easier for developers to build architecture-agnostic car-based apps.
The middleware programmatically speaks with the gateway ECU and provides application programming
interface (API) access to apps that need to send messages to the individual ECUs. The bus switch will
route the frames to the target ECUs. The apps talk to the OEM cloud (car manufacturer cloud) or thirdparty cloud services (e.g., Netflix) via a tethered cellular connection from the mobile phone or using thebuilt-in eSIM. Depending on the E/E architecture of the car, the gateway ECU can also communicate
directly with cloud services. As cars become smarter and better connected, we will see car-specific apps
being developed and T1, T2, and OEM versions of apps will emerge. OEM apps will probably not need
middleware to access the gateway ECU, or might even be able to communicate with the bus switch
directly.

6 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

3rd party cloudOEM cloudTelecommunications box (TCB)eSIM
Cellular
3G/4G/5G
Bus switch

Head unit

CAN

ECU1

ECU1

... ECUA

CAN

ECU1

ECU1

... ECUB

LIN

ECU1

ECU1

... ECUX

MOST

ECU1

ECU1

... ECUY

Application

EthernetswitchMiddleware

Gateway ECU

Figure 2. The cloud-connected ecosystem of a connected car

The advent of 5G standalone (SA), which no longer relies on existing LTE infrastructure, will play a big
part in the connected car ecosystem. Thus, it is realistic to expect the E/E architecture to evolve and takeadvantage of next-generation 5G networks. Key 5G technologies that will be important to connectedcars include software-defined networking (SDN); Network slicing to separate applications and quality ofservice (QoS); beamforming for fast communications; 5G machine learning (ML) and artificial intelligence(AI) applications; multi-user multiple input multiple output; high availability (99.999%) and low latency(1 millisecond); support for a high density of connected devices and ultra-high speeds; and low-power
consumption.
Head unit/
Central controller

CloudGroup 1

Group 2... Group N

Group Cloud

ECU1

ECU1

ECU1

ECU1

ECU2

ECU2

ECU2

ECU2

ECU3

ECU3

ECUN

ECU3

... ECUX... ECUY... ECUZ... ECUN

Figure 3. Cloud-based car E/E architecture

7 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

Connected cars will need very low latency vs. big bandwidth fast data rates. Network slicing and SDN canhelp separate the high data rate applications in the car from the ultra-low latency applications. This meansthat in the future, OEMs will be able to move certain ECU functions of the car to the cloud. Moving ECUs tothe cloud has advantages, such as having a simplified E/E architecture with fewer ECUs to manage inside
the car and massively expanded processing power using cloud computing. It could also allow expanded
road situational awareness beyond that of local limits of around a 500-meter radius; the ability to flexibly
add new and innovative applications using incremental OTA updates; improve fuel, battery, and emissions
efficiency; expand and flexibly control road load capacity from an intelligent transportation system’s (ITS)
point-of-view; easy integration with third-party service providers such as revenue-generating services like
Uber, which operates the car in autonomous mode; and access to distributed cloud servers plus a fullcoverage low-latency network, which means attackable surfaces are more resistant to malicious attacks— it will be extremely difficult for attackers to compromise the distributed backend servers and knockoffline all the 5G network nodes surrounding the vehicles.

8 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and BeyondThreat Modeling the Connected
Car Ecosystem
Threat modeling is a useful and established technique software developers use to assess the security
risks in their code. Other than software, threat modeling can also be applied to systems, and therefore canalso be used to assess the security of industrial control systems (ICS). Threat modeling is a systematicway of classifying, identifying, and quantifying the risk presented by each threat that is being evaluated.8
In this section, we analyze the 69 attack vectors listed in Annex 5, Table A1 of the UN Regulation No. 155
document9 using the industry standard DREAD threat model.

Methodology: The DREAD Threat Model
Threat modeling allows us to apply a structured approach to security and address first the top threats that
can have the greatest potential impact on the application.10 One type of threat modeling is qualitative risk
analysis, which is opinion based; this means it uses rating values to evaluate the risk level. The DREAD
threat model can be used to perform qualitative risk analysis.11 Using the DREAD threat model, we arrived
at the risk rating for the given threats by answering the following questions:•

Damage potential: How great is the damage to the assets?

•

Reproducibility: How easy is it to reproduce the attack?

•Exploitability: How easy is it to launch an attack?

•Affected users: As a rough percentage, how many users are affected?

•

Discoverability: How easy is it to find an exploitable weakness?

9 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and BeyondWe use the following risk rating table shown in Table 1 for our risk analysis:High (3)Medium (2)Low (1)D

The attacker subverts the systemand can inflict serious damage.

The attacker subverts the systemand can inflict moderate damage.

The attacker subverts the systemand can inflict minor damage

R

The attack can be reproduced
every time.

The attack can be reproduced,
but only within set limitations.

The attack is very difficult
to reproduce, even with fullknowledge of the security hole.

E

The attack requires little or noknowledge of the system in order
to exploit it.

The attack requires a skilled
operator with fundamental
knowledge of the system in order
to exploit it.

The attack requires an extremely
skilled operator with in-depth
knowledge of the system in order
to exploit it.

A

Majority of the everyday users
will be affected by the attack.

A good portion of everyday users
will be affected by the attack.

A very small percentage ofeveryday users will be affectedby the attack.

D

Published information readily
explains the attack. Vulnerabilities
are found in the most commonlyused applications & systems.

Vulnerabilities are not common
and only found in certain
applications & systems. It requires
skills to discover exploitableweaknesses.

Extremely difficult to discovervulnerabilities, and they are very
difficult to weaponize. Extremely
difficult to attack the applications& systems.

Table 1. The DREAD threat model

After answering the DREAD questions for a given threat, the risk rating is calculated by adding the rating
values. The overall risk is rated as:•High if the score is between 12 and 15•

Medium if the score is between 8 and 11•

Low if the score is between 5 and 7

Annex 5, Table A1 of the UN Regulation No. 155 document lists 69 attack vectors directly affecting
vehicle cybersecurity.12 We analyzed these 69 attack vectors and threat modeled them using DREAD
so stakeholders (OEMs, suppliers, government and regulatory organizations, and third-party service
providers, etc.) can determine the order in which to prioritize threats. We assigned scores for realistic
extreme scenarios to the attack vectors and calculated their risk ratings.
Note that we maintained the same section numbers used in the UN Regulation No. 155 or ECE/TRANS/
WP.29/2020/79 document regardless of the sequence. The numbering follows the sequence in the UN
Regulation No. 155 document.

10 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and BeyondThreats Regarding Back-End Servers Related to
Vehicles in the Field
Top-level threat
1. Back-end servers used asa means to attack a vehicle orextract data

Threat Example

D

R

E

A

D

Rating

1.1 Abuse of privileges by staff(insider attack)

3

3

2

2

2

High

1.2 Unauthorized internet accessto the server

3

2

2

2

2

Medium

1.3 Unauthorized physical accessto the server

3

3

2

2

2

High

3

2

2

2

2

Medium

2. Services from back-end
server being disrupted,
affecting the operation of avehicle2.1 Attack on back-end serverstops it functioning

3. Vehicle related data held on
back-end server being lost or
compromised (data breach)

3.1 Abuse of privileges by staff(insider attack)

3

3

2

2

2

High

3.2 Loss of information in the
cloud

3

2

2

2

2

Medium

3.3 Unauthorized internet accessto the server

3

2

2

2

2

Medium

3.4 Unauthorized physical accessto the server

3

3

2

2

2

High

3.5 Information breach byunintended sharing of data

3

1

2

2

3

MediumTable 2. Threat rating for threats in back-end servers related to vehicles in the field

These are our observations from the threat modeling we had done on the section describing “Threats
regarding back-end servers related to vehicles in the field,” Section 4.3.1 in Table A1:•

When attackers have privileged access or actual physical access to the back-end servers, it would be
extremely difficult to defend these systems — essentially a checkmate for defenses.

•

Not all servers will be vulnerable, because of varying levels of system patching. It is also rare (but not
improbable) for sensitive backend servers to be exposed and discoverable online.

•

Even if there is data loss in the cloud, exploiting the data supply can be tricky. Damage potential,
therefore, depends on the data stolen and its likelihood of misuse.

•

Even if a backend server is compromised, a total fleet-wide cyberattack would be highly unlikely, but
again, not impossible.

11 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and BeyondThreats to Vehicles Regarding Their
Communication Channels
Top-level threat
4. Spoofing of messages ordata received by the vehicle

5. Communication channels
used to conduct unauthorized
manipulation, deletion or otheramendments to vehicle heldcode/data

6. Communication channels
permit untrusted/ unreliable
messages to be accepted orare

7. Information can be readily
disclosed

8. Denial of Service attacks via
communication channels to
disrupt vehicle functions

Threat Example

D

R

E

A

D

Rating4.1 Spoofing of messages byimpersonation (e.g. 802.11p V2X
or GNSS messages)

3

1

1

1

1

Low

4.2 Sybil attack (vehicle pretends
to have more than one identity)

3

2

1

1

1

Medium

5.1 Communications channels
permit code injection (e.g.
tampered software binary injectedin the communication stream)

3

1

1

1

1

Low

5.2 Communications channels
permit the manipulation of vehicle
held data/code

3

1

1

1

1

Low

5.3 Communications channels
permit overwrite of vehicle held
data/code

3

1

1

1

1

Low

5.4 Communications channels
permit erasure of vehicle held
data/code

3

1

1

1

1

Low

5.5 Communications channels
permit introduction of data/code
to the vehicle

3

1

1

1

1

Low

6.1 Accepting information from anunreliable or untrusted source

3

1

1

2

2

Medium

6.2 Man in the middle attack/session hijacking

3

1

1

1

2

Medium

6.3 Replay attack (to downgrade
ECU firmware or gateway
firmware inside the car)

3

1

1

1

1

Low

7.1 Interception of information/interfering radiations/monitoring
communications

1

2

2

1

2

Medium

7.2 Gaining unauthorized accessto files or data

1

2

2

2

2

Medium

8.1 Sending a large numberof garbage data to vehicle
information system, so that it isunable to provide services in thenormal manner

3

2

2

3

2

High

8.2 Black hole attack (block
messages between vehicles to
disrupt communications)

2

2

1

1

1

Low

12 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and BeyondTop-level threat

Threat Example

D

R

E

A

D

Rating9. An unprivileged user is able
to gain privileged access tovehicle systems

9.1 An unprivileged user is able
to gain privileged access, forexample root access

3

1

1

1

1

Low

10. Viruses embedded incommunication media are able
to infect vehicle systems

10.1 Virus embedded incommunication media infects
vehicle systems

3

1

1

1

1

Low

11. Messages received by thevehicle) or transmitted within it,
contain malicious content

11.1 Malicious internal (e.g. CAN)
messages transmitted on car bus

3

1

1

1

1

Low

11.2 Malicious V2X messages(e.g. I2V or V2V messages)

3

2

2

1

2

Medium

11.3 Malicious diagnostic
messages

3

1

1

1

1

Low

11.4 Malicious proprietary
messages (e.g. those sent from
OEM or T1/T2 suppliers)

3

2

2

2

2

MediumTable 3. Threat rating for threats regarding communication channels

These are our observations from the threat modeling section “Threats to vehicles regarding theircommunication channels,” listed in Table A1, Section 4.3.2:•

Sybil attacks (wherein a vehicle pretends to have more than one identity so that other vehicles in the
network would be unable to verify if the received data originates from one or multiple vehicles) on theroad have a limited threat radius.

•

Spoofing of messages by impersonation (e.g. 802.11P, V2X, or GNSS messages) will need to be ahighly targeted attack to succeed.

•

Highly skilled hackers are needed to attack communication channels and it is very difficult to attack
fleets. Published case studies on remote attacks against Jeep, Tesla, and Mercedes demonstrated
that this is a difficult attack to achieve.13•

Hacked or compromised Wi-Fi routers or femtocells can be used for Man-in-the-Middle (MiTM)
attacks.

•

Intercepting information, interfering with radiations, monitoring communications, and gaining
unauthorized access to files or data are all typically passive attacks that don’t affect road safety.

•

Denial of service (DoS) or distributed denial of service (DDoS) attacks can cause widespread
uncontrolled damage in the connected car ecosystem.

•

Blackhole attacks, which block messages between vehicles to disrupt communications, become
especially disruptive in L5 autonomous vehicles where drivers are not in control.

13 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond•Malware attacks (using viruses, worms, bots, etc.) will need middleware that interfaces with vehicle
systems to become a real threat. Malware attacks would be very difficult to execute without
middleware.14•

Compromised ITS infrastructure can be leveraged for spreading malicious infrastructure-to-Vehicle(I2V) or V2X messages; it’s basically a data supply chain attack against the ecosystem. This canbe critical, since the data supply chain essentially equates to the data lifecycle which involves thegeneration and procurement of data for an organization.15

Threats to Vehicles Regarding Their Update
Procedures
Top-level threat

Threat Example

D

R

E

A

D

Rating12. Misuse or compromise of
update procedures

12.1 Compromise of over the air
software update procedures

3

2

2

3

1

Medium12.2 Compromise of local/
physical software updateprocedures

3

3

2

2

2

High

12.3 The software is manipulated
before the update process (and istherefore corrupted), although theupdate process is intact

3

2

2

3

1

Medium

12.4 Compromise cryptographic
keys of software provider to doinvalid update

3

2

2

3

1

Medium13.1 Denial of Service attack
against update server or network
to prevent rollout of criticalsoftware updates and/or unlockof customer specific features

1

2

3

3

3

High

13. It is possible to denylegitimate updates

Table 4. Threat rating for threats regarding vehicle update procedures

These are our observations from the threat modeling section “Threats to vehicles regarding their updateprocedures,” Section 4.3.3 in Table A1:•

Compromising the OTA software update procedure is a data supply chain attack.

•Compromising the local and/or physical software update procedure could be the work of a rogue
dealership/garage, or an insider working at the dealership/garage.

•

Fortunately, not much harm would be done if vehicles cannot be updated. Typically, the new firmware
will not be loaded into memory and have its update process started, until the full download iscompleted and the hash value is calculated and confirmed.

14 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and BeyondThreats to Vehicles Regarding Unintended
Human Actions Facilitating a Cyberattack
Top-level threat

Threat Example

D

R

E

A

D

Rating15. Legitimate actors are able
to take actions that would
unwittingly facilitate a cyberattack

15.1 Innocent victims being
tricked into taking an action tounintentionally load malware or
enable an attack

2

2

1

1

1

Low

15.2 Defined security procedures
are not followed

3

2

2

1

1

MediumTable 5. Threat rating for threats regarding unintended human actions

These are our observations from the threat modeling section “Threats to vehicles regarding unintended
human actions facilitating a cyberattack,” Section 4.3.4 in Table A1:•

Innocent victims getting tricked into unintentionally loading malware is a classic phishing attack.
Compromising the head unit is easier than overwriting firmware or installing malware.

•

Any negligence in following the correct manufacturer-defined security procedures for operations orvehicle servicing can lead to exploitation and the vehicle getting compromised.

Threats to Vehicles Regarding Their External
Connectivity and Connections
Top-level threat
16. Manipulation of theconnectivity of vehicle
functions enables a cyberattack

17. Manipulation of theconnectivity of vehicle
functions enables a cyberattack

Threat Example

D

R

E

A

D

Rating16.1 Manipulation of functions
designed to remotely operate
systems, such as remote key,
immobilizer, and charging pile

3

2

3

2

3

High

16.2 Manipulation of vehicle
telematics (e.g. manipulate
temperature measurement ofsensitive goods, remotely unlock
cargo doors)

2

2

2

1

2

Medium16.3 Interference with short range
wireless systems or sensors

2

3

3

1

3

High

17.1 Corrupted applications, or
those with poor software security,used as a method to attack
vehicle systems

3

2

1

2

1

Medium15 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and BeyondTop-level threat
18. Devices connected toexternal interfaces e.g. USB
ports, OBD port, used asa means to attack vehicle
systems

Threat Example

D

R

E

A

D

Rating18.1 External interfaces such as
USB or other ports used as apoint of attack

3

2

1

1

2

Medium18.2 Media infected with a virus
connected to a vehicle system

3

1

1

1

1

Low

18.3 Diagnostic access (e.g.
dongles in OBD port) used
to facilitate an attack, e.g.
manipulate vehicle parameters(directly or indirectly)

3

2

1

1

2

MediumTable 6. Threat rating for threats regarding vehicle external connectivity and connections

Our observations from the threat modeling section “Threats to vehicles regarding their external connectivity
and connections,” Section 4.3.5 in Table A1:•

Car thieves are already doing signal capture-relay-replay attacks against wireless car key fobs.

•

Electronic jamming of radio frequency (RF) is an easily executed, low-skill attack vector.

•

To attack the USB and OBD ports, attackers will need physical access to the vehicle interior.

•

Manipulating vehicle telematics is a bigger problem for commercial vehicles versus passenger cars,
especially if the forged telematics can be used to hijack a commercial vehicle and steal goods orchange the temperature settings and spoil any fresh goods being transported

Threats to Vehicle Data/CodeTop-level threat

Threat Example

D

R

E

A

D

Rating

19. Extraction of vehicle data/code

19.1 Extraction of copyright orproprietary software from vehicle
system

3

1

1

2

1

Medium19.2 Unauthorized access of theowner’s privacy information suchas personal identity, payment
information, address book,location, vehicle electronic ID,
etc.

3

1

2

1

2

Medium19.3 Extraction of cryptographic
keys

3

1

1

2

1

Medium16 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and BeyondTop-level threat

Threat Example

D

R

E

A

D

Rating20.1 Illegal/unauthorized changes
to vehicle’s electronic ID

2

2

2

2

2

Medium20.2 Identity fraud

2

2

2

2

2

Medium20.3 Action to circumventmonitoring systems (e.g. hacking/tampering/blocking of messages
such as ODR Tracker data, or
number of runs)

2

1

1

1

1

Low

20.4 Data manipulation to falsify
vehicle’s driving data

2

2

2

2

2

Medium20.5 Unauthorized changes tosystem diagnostic data

2

1

1

1

1

Low

21. Erasure of data/code

21.1 Unauthorized deletion/
manipulation of system even logs

2

2

3

2

3

High

22. Introduction of malware

22.1 Introduce malicious softwareor malicious software activity

3

2

3

3

3

High

23. Introduction of new
software or overwrite existing
software23.1 Fabrication of software of
the vehicle control system or
information system

3

2

2

3

2

High

24. Disruption of systems or
operations

24.1 Denial of service, e.g.
flooding internal network with
CAN messages, or by provoking
faults on an ECU via a high rate ofmessaging

3

1

1

1

1

Low

25.1 Unauthorized accessof falsify the configuration
parameters of vehicle’s key
functions such as brake data,
airbag deployed threshold, etc.

3

3

2

1

3

High

25.2 Unauthorized access offalsify the charging parameters,such as charging voltage,
charging power, battery
temperature, etc.

3

3

2

1

3

High

20. Manipulation of vehicle
data/code

25. Manipulation of vehicle
parameters

Table 7. Threat rating for threats related to the vehicle data/code.

Our observations from the threat modeling section “Threats to vehicles data/code,” Section 4.3.6 in Table
A1:•

Past case studies of hacking Jeep, Tesla, and Mercedes have demonstrated that the extraction of
firmware from the vehicle is extremely difficult and requires a highly skilled operator.

•

The most likely way of stealing Personally Identifiable Information (PII) is to either compromise thevehicle’s head unit OS using a chain of exploits or compromise the OEM/third-party cloud services.

17 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond•The extraction of cryptographic keys requires reverse-engineering the extracted ECU firmware.

•

Manipulating vehicle data/code needs a reliable attack method, which would most likely involve cloudservices.

•

Many of the attacks, like erasing data/code, introducing new software, or overwriting software, ismore effective as a server-side attack i.e., doing a fleetwide attack versus attacking individual vehicles•

Manipulating vehicle parameters can have serious consequences for vehicle safety and can most
likely be achieved using commercial OBD-II tools

Potential Vulnerabilities That Could Be
Exploited if Not Sufficiently Protected orHardenedTop-level threat

Threat Example

D

R

E

A

D

Rating26. Cryptographic technologies
can be compromised or are
insufficiently applied

26.1 Combination of shortencryption keys and long periodof validity enables attacker tobreak encryption

3

2

1

1

1

Medium26.2 Insufficient use of
cryptographic algorithms toprotect sensitive systems

3

2

1

1

1

Medium26.3 Using already or soon to
be deprecated cryptographic
algorithms

3

2

1

1

1

Medium

27. Part or supplies could
be compromised to permit
vehicles to be attacked

27.1 Hardware or software,engineered to enable an attack
or fails to meet design criteria tostop an attack

3

3

2

1

2

Medium

28. Software or hardware
development permits
vulnerabilities

28.1 Software bugs. The
presence of software bugs can bea basis for potential exploitable
vulnerabilities.

3

2

2

1

2

Medium28.2 Using remainders fromdevelopment can permit accessto ECUs or permit attackers togain higher privilege

3

3

2

2

2

High

29.1 Superfluous internet ports
left open, providing access to
network systems

3

2

1

3

1

Medium29.2 Circumvent network
separation to gain control

3

2

2

1

1

Medium

29. Network design introduces
vulnerabilities

18 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and BeyondTop-level threat

Threat Example

D

R

E

A

D

Rating31. Unintended transfer of data
can occur

31.1 Information breach. Personal
data may be leaked when the carchanges user

2

2

2

1

3

Medium

32. Physical manipulation ofsystems can enable an attack

32.1 Manipulation of electronic
hardware

3

2

3

1

2

Medium32.1 Replacement of authorized
electronic hardware

3

2

3

1

2

Medium32.1 Manipulation of theinformation collected by a sensor

3

2

3

1

2

MediumTable 8. Threat rating for potential vulnerabilities that could be exploited if not sufficiently protected

Our observations from the threat modeling section Potential vulnerabilities that could be exploited if not
sufficiently protected or hardened (Table A1 Section 4.3.7):•

Compromised cryptographic keys are a significant threat when they can be used to load malicious
firmware into compromised ECUs.

•

After-market tuning tools are pretty common, especially rigs for ECU flashing for unlocking features.

•

Not changing the admin password would be gross security negligence on the part of the OEMs.

•

Cars will need a data reset option to protect the owner’s data similar to mobile phones. This isespecially useful when transferring vehicle ownership or if the vehicle gets stolen.

•

Multiple case studies published over the years against brands like Jeep, Tesla, Mercedes, Lexus, etc.,
discuss using exploit chains to compromise the head unit. This is different from compromising thevehicle ECUs and is typically the preceding step to compromising the ECUs.

19 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

Evolution of Threats Against
Connected Cars
The DREAD threat modeling exercise was done by applying current technologies; hacker tools, techniques,and procedures (TTPs); and learnings from published research in the car hacking domain. The goal of
our threat modeling exercise was to help stakeholders prioritize which attack scenarios to address firstand develop protective countermeasures for. In the next decade, especially with the global rollout of 5G
networks, the available technology stack and hacker TTPs are going to significantly change, thus threat
profiles will also change. To visualize this, we made predictions about the evolution of the connected
car ecosystem and then studied how the DREAD threat modeling changes. Based on past studies,16 we
predict the following will happen in the next decade:1. V2X communications will become mainstream and will be used by L3 to L5 autonomous vehicles.
2. The data supply chain will become a critical component in the operations and safety of connectedcars and will be powered by fast and reliable networks.
3. The numbers of L3 and L4 autonomous vehicles on the road will dramatically increase. We also
expect to see L5 vehicles on the road within a decade.
4. With reliable 5G networks, some ECU functions from the vehicle’s E/E systems will be migrated to thecloud for efficiency and simplification of the onboard E/E architecture.
5. The head unit will support a large third-party app ecosystem (similar to mobile phones), and will
provide middleware access to the vehicle’s E/E systems.
6. Middleware access for apps to the vehicle’s E/E systems will enable connected cars to offer innovative
add-on features such as autonomous ride-sharing and coordinated grocery pickups.
7. ML and AI applications hosted in cloud servers will be used extensively for traffic shaping and roadway
capacity predictions.
8. Using the growing library of third-party apps, the connected car will become fully integrated withusers’ digital lives such as banking, office applications, and entertainment.
9. As the “all-digital, feature-rich” connected car becomes a reality, criminals will invent innovative ways
to monetize the connected car’s physical and digital resources
20 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and BeyondGiven these broad evolutions in the connected car space, we attempted to predict how the DREAD
threat modeling that we did will change. We need to keep in mind that the available TTPs will also evolve.
Hacking techniques that, at present, require highly skilled hackers (with in-depth specialized knowledge),
may be achieved using simple plug-and-play dongles purchased from a dark web marketplace or evendone wirelessly over the internet.
The goal for the updated threat modeling is to discover shifts in the threat profile and help stakeholders
develop long-term plans for addressing these threats. The risk evaluation process we followed is listed
here:•

We went over all the threat vectors listed in UN Regulation No. 155 to determine which ones will beaffected by our nine predictions.

•Threat vectors like 15.2 (Defined security procedures are not followed), 27.1 (Hardware or software
engineered to enable an attack fails to meet design criteria to stop an attack), and 32.1 (Manipulation/
replacement of hardware/information) are deliberately ambiguous, meaning the nature of the threat
does not fundamentally evolve when we apply our predictions. We have thus excluded these threats
from our follow-up threat modeling.

•

We focused mainly on the Low and Medium threats, and attempted to determine if the risk rating willchange or remains static, and explain why.

•

We applied the DREAD modeling to our selected threat vectors to determine their new risk ratings.

•

Threat vectors that already scored High in our risk assessment were skipped over as we didn’t expect
the risk rating to decrease.

•

Attack vectors 1.1 to 1.3, 2.1, and 3.1 to 3.5 were skipped over because the nine predictions we madeon the evolution of the connected cars do not directly affect those attack vectors.

Threat Examples

D

R

E

A

D

New

Old

Notes
Custom hardware sold in
deepweb markets used inattacks. Attacking V2X protocol

4.1 Spoofing of
messages byimpersonation (e.g.
802.11p V2X or GNSS
messages)

3

2

2

2

2

MediumLow

4.2 Sybil attack (vehicle
pretends to have morethan one identity)

3

2

2

2

2

MediumMedium

5.1 Communications
channels permit code
injection (e.g. tampered
software binary injectedin the communication
stream)

3

2

2

2

1

MediumLow

Custom hardware sold in
deepweb markets used inattacks. Attacking V2X protocol
Criminals use sold-as-readykit/service to execute these
attacks. Attacking bus protocols

21 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and BeyondThreat Examples
5.2 Communications
channels permit the
manipulation of vehicle
held data/code

D

3

R

2

E

2

A

2

D

1

New

MediumOld

Low

5.3 Communications
channels permit
overwrite of vehicle held
data/code

3

2

2

2

1

MediumLow

5.4 Communications
channels permit erasureof vehicle held data/code

3

2

2

2

1

MediumLow

5.5 Communications
channels permit
introduction of data/code
to the vehicle
6.1 Accepting
information from anunreliable or untrusted
source6.2 Man in the middle
attack/session hijacking
6.3 Replay attack(to downgrade ECU
firmware or gateway
firmware inside the car)

3

2

2

2

1

Medium

Low

3

2

3

2

2

High

Medium

3

2

3

2

2

High

Medium

3

2

3

1

2

MediumLow

7.1 Interception of
information/interferingradiations/monitoring
communications

1

2

2

2

2

MediumMedium

7.2 Gaining unauthorizedaccess to files or data

1

2

2

2

2

MediumMedium

8.2 Black hole attack(block messages
between vehicles to
disrupt communications)

3

2

3

2

2

High

Low

Notes
Criminals use sold-as-readykit/service to execute these
attacks. Attacking bus protocols
Criminals use sold-as-readykit/service to execute these
attacks. Attacking bus protocols
Criminals use sold-as-readykit/service to execute these
attacks. Attacking bus protocols
Criminals use sold-as-readykit/service to execute these
attacks. Attacking bus protocols
This is easier to pull off withkits/service as they’re not
meddling with complex internals
Can be done with routers or
femtocells and a dedicatedsold-as-ready kit/service
Drawing parallel to replay
attacks used to mimic fobs andunlock, start, and steal cars
This is a passive attack which
doesn’t affect road safety

This is a passive attack which
doesn’t affect road safety
Attack become disruptive withmore L3-L5 vehicles on the roadand mass V2X adoption
Middleware will make it easy
to access car’s E/E systems aswell get root privileges

9.1 An unprivileged user
is able to gain privileged
access, for example root
access

3

2

3

2

2

High

Low

10.1 Virus embedded incommunication media
infects vehicle systems

3

2

3

2

2

High

Low

Middleware exploits will makevirus infection easy and giveaccess to E/E systems

11.1 Malicious internal(e.g. CAN) messages
transmitted on car bus

3

2

3

2

2

High

Low

Virus infection via middleware
exploit access E/E systems &injects malicious messages

22 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and BeyondThreat Examples

D

R

E

A

D

New

Old

Notes

11.2 Malicious V2X
messages (e.g. I2V or
V2V messages)

3

2

3

2

2

High

MediumUses sold-as-ready kit/service
to execute these attacks.
Transmits fake V2X messages

3

2

3

2

2

High

Low

Virus infection via middleware
exploit access E/E systems &injects malicious messages

11.3 Malicious diagnostic
messages

Uses sold-as-ready kit/service
to execute these attacks.
Transmits fake V2X messages

11.4 Malicious
proprietary messages(e.g. those sent from
OEM or T1/T2 suppliers)

3

2

3

2

2

High

Medium12.1 Compromise of over
the air software updateprocedures

3

2

2

2

2

MediumMediumDepending on the OTA updatesource (3rd party or OEM or T1)
the risks fluctuate

Medium

Hacking the data supply chain
is a difficult task. This attack
would assume a major OEM or
T1 supplier got compromised,
in which case the entire
connected car fleet is at risk

12.3 The software ismanipulated before theupdate process (andis therefore corrupted),although the updateprocess is intact
12.4 Compromise
cryptographic keys ofsoftware provider to doinvalid update15.1 Innocent victims(e.g. owner, operator, or
maintenance engineer)
being tricked into
taking an action tounintentionally loadmalware or enable anattack
16.2 Manipulation ofvehicle telematics (e.g.
manipulate temperature
measurement of sensitive
goods, remotely unlock
cargo doors)
17.1 Corrupted
applications, or thosewith poor software
security, used as amethod to attack vehicle
systems
18.1 External interfaces
such as USB or otherports used as a point of
attack

3

3

3

2

3

3

2

2

2

2

2

2

2

2

3

2

3

3

3

3

2

1

2

1

1

1

2

2

3

2

MediumMediumHigh

MediumHigh

MediumMediumLow

MediumMediumMedium

Hacking the data supply chain
is a difficult task

Phishing attacks that exploit
head unit middleware toaccess the E/E systems will be
extremely dangerous

This attack is more dangerous
for commercial vehicles thanpassenger cars, and the risk
remains unchanged because
telematics won’t change vehicle
safetyCorrupted applications or
unsecure applications used to
exploit head unit middlewareand get access the vehicle‘s
E/E system
Attackers need physical accessto the ports inside the car to
attack successfully

23 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and BeyondThreat Examples

D

R

E

A

D

New

Old

Notes

18.2 Media infected witha virus connected to avehicle system

3

2

3

1

2

MediumLow

Attackers need physical accessto the inside of the car to attack
successfully

18.3 Diagnostic access(e.g. dongles in OBDport) used to facilitate an
attack, e.g. manipulate
vehicle parameters(directly or indirectly)
19.1 Extraction of
copyright or proprietary
software from vehicle
system19.2 Unauthorizedaccess of the owner’s
privacy information suchas personal identity,
payment information,
address book, location,
vehicle electronic ID, etc.
19.3 Extraction of
cryptographic keys
20.1 Illegal/unauthorizedchanges to vehicle’s
electronic ID
20.2 Identity fraud

3

3

2

1

3

1

1

2

2

1

MediumMediumMediumMediumAttackers need physical accessto the inside of the car to attack
successfully

Extracting the firmware is
still possibly difficult, but
unnecessary if there is
middleware
Exploiting the middleware in
the head unit will make this afairly easy attack to execute,the other way would be tocompromise OEM or T1/T2
cloud services

2

2

2

2

2

MediumMedium

3

1

1

2

1

MediumMediumThis requires reverse
engineering the extracted ECU’s
firmware or middleware stack

3

2

2

2

2

High

MediumAttacks will facilitate serious
crimes being committed using
hacked autonomous vehicles

2

2

2

2

2

MediumMediumStealing a vehicle’s identity andusing it to access paid services
Need to access the ECU via
the head unit middleware to
execute this type of attacks.
This attack targets manipulating
data and doesn’t really increaseroad risks

20.3 Action to circumventmonitoring systems(e.g. hacking/tampering/
blocking of messages
such as ODR Tracker
data, or number of runs)

2

2

2

1

2

MediumLow

20.4 Data manipulation
to falsify vehicle’s driving
data

2

2

2

1

2

MediumMediumNeed to access the ECU via
the head unit middleware to
execute this type of attacks.

20.5 Unauthorizedchanges to system
diagnostic data

2

2

2

1

2

MediumLow

Need to access the ECU via
the head unit middleware to
execute this type of attacks.

24.1 Denial of service,e.g. flooding internal
network with CAN
messages, or by
provoking faults on an
ECU via a high rate ofmessaging

3

2

3

2

2

High

Low

Exploiting vulnerabilities in
the head unit’s middleware
stack to access the vehicle’s
E/E systems and flood databuses with malicious or uselessmessages

24 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and BeyondThreat Examples
26.1 Combination ofshort encryption keys
and long period ofvalidity enables attacker
to break encryption

D

3

R

2

E

2

A

2

D

1

New

MediumOld

Notes

MediumThis requires reverse
engineering the extracted ECU’s
firmware or middleware stack.
Extent of victim depends on
how many car models have thisflaw and OTA schedules
This requires reverse
engineering the extracted ECU’s
firmware or middleware stack

26.2 Insufficient use of
cryptographic algorithms
to protect sensitive
systems

3

2

2

2

1

MediumMedium26.3 Using already orsoon to be deprecatedcryptographic algorithms

3

2

2

2

1

MediumMediumThis requires reverse
engineering the extracted ECU’s
firmware or middleware stack

MediumSoftware bugs are the maincause of vulnerabilities. With
increased use of softwarein smart cars, this increases
the risk of complex chains ofvulnerabilities being exploited

28.1 Software bugs. The
presence of software
bugs can be a basis forpotential exploitable
vulnerabilities.
29.1 Superfluous internet
ports left open, providing
access to network
systems
29.2 Circumvent network
separation to gain control
31.1 Information breach.
Personal data may beleaked when the carchanges user

3

2

2

3

2

High

3

2

2

3

2

High

Medium

3

2

2

1

2

MediumMedium

2

2

2

2

2

MediumMediumThird-party cloud services could
be targeted as means to accessthe car’s network
Very narrow attacking scope.
Easier to exploit vulnerability in
middleware to subvert
Second-hand cars will need adata reset option like mobile
phones to prevent thisTable 9. Reevaluated risk ratings after applying our predictions on the evolution of connected cars

By applying our connected car evolution predictions to the WP.29 attack vectors and then evaluatingthem through threat modeling, we observed the following changes:•

Affected users increase as V2X and connected car technology usage become mainstream.

•

The reproducibility of the attacks improves with new developments in off-the-shelf technology.

•

The exploitability, or the minimum skills needed by an attacker, decreases. For example, car thieves
can now easily perform signal capture-relay-replay attacks against wireless car key fobs using off-theshelf technology purchased from dark web marketplaces. The signal replay attack has transformed
from requiring expert level skills to anyone with basic technical know-how can now execute this.

•Discoverability of vulnerabilities and weaknesses becomes easier as many of the attacks have gonefrom theoretical to mainstream and then were weaponized and made available for purchase25 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

Overall Summary
In a nutshell, immediate focus should be placed on backend and data security. While in the future, risk at
the communication channel will dramatically increase. We see this happening because vehicles are boundto be better connected via APIs both internally and externally. That being said, our recommendations are
to design security with an understanding of the backends, APIs, and prioritizing data security from the
beginning.

25%

43%

22%

Low

High

High

Current

Future53%

57%

MediumMediumFigure 4. A comparison between current and future percentages of risks that fall under each of the threeclassification levels (low, medium, high).

Current High

Future High
Backend27%

33%

Communication
Channels

7%

33%

Vehicle Data/Code
13%
7%

23%

External Connectivity

10%

Hardening Sufﬁciency

10%

Human Error

0%3%

Update Procedures

13%
35%

13%

0%

7%
0%

Figure 5. The current and predicted percentage of attack vectors turning
into high risk threats in each subsection

26 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

35%

The WP.29 UN-R155 document contains seven high-level and 30 sub-level descriptions of vulnerabilities
and threats that include 69 attack vectors. In our opinion, the following are the top five attack vectors thatneed to be given the highest priority:•

Back-end servers used as a means to attack a vehicle or extract data, 1.1 to 1.3 of section 4.3.1.

•

Denial of service attacks via communication channels to disrupt vehicle functions, 8.1 to 8.2 of section
4.3.2.

•

Hosted third-party software, such as entertainment applications, used as a means to attack vehicle
systems, 16.1 to 16.3 of section 4.3.5.

•

The extraction of vehicle data/code, 19.1 to 19.3 of section 4.3.6.

•

Software or hardware development, which permits vulnerabilities, 28.1 to 28.2 of section 4.3.7.

27 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

Additional Areas of Focus forConnected Car Security
We studied the list of attack vectors in the UN Regulation No. 155 document and cross-referenced themwith the predictions we published in our research papers on intelligent transport systems (ITS)17 andconnected cars18 to determine if there are additional attack vectors and/or focus areas that we can add oremphasize. It is important to note that the regulation primarily targets connected car safety and security,
while our past researches explored the entire ITS ecosystem where connected cars are one piece of abigger puzzle. In our past researches, we did cyberattack assessments that are outside the scope of theregulation, but still heavily influence the overall safety and security of connected cars. In a nutshell, there
is more than one way of attacking connected cars — which is the ultimate goal for malicious hackers. We
discuss here focus areas and attack vectors that stakeholders — OEMs, suppliers, government agencies,
third-party service providers, and the general public should be aware of.

Attack Vehicle Image Processing
Onboard image processing to determine the vehicle position, current road conditions, speed limits,traffic signs, and other visual data is a critical application in both semi- and fully autonomous vehicles.
Manufacturers like Tesla are only using the onboard camera network in their cars, versus using otherobstacle discovery technologies such as LIDAR, to autonomously navigate the roads.19, 20 On-board or
cloud-based image processors crunch through vast quantities of visual data in milliseconds to make splitsecond driving decisions on the road. There are published researches that demonstrate how researchers
were able to fool the vehicle’s cameras into misinterpreting roadway signs by adding small anomalies or
stickers to road signs.21, 22

28 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

Figure 6. Researchers successfully affecting the reading of roadway signs
Left image source: Hacking street signs with stickers could confuse self-driving cars from Ars Technica23
Right image source: Fooling a Real Car with Adversarial Traffic Signs by Nir Morgulis, Alexander Kreines,
Shachar Mendelowitz, and Yuval Weisglass24

Figure 7. Researchers affecting the reading of road signs as seen from the dashboard
Image source: Fooling a Real Car with Adversarial Traffic Signs, by Nir Morgulis, Alexander Kreines,
Shachar Mendelowitz, and Yuval Weisglass25

This is a very low-tech and easily executable attack against the vehicle’s onboard image processing
algorithms — and one that can have catastrophic consequences for road safety. Vehicle image processing
algorithms will need a heuristic approach to interpreting road signs to avoid such visual attacks and/or alarge onboard library of images to cross-reference against. But even those solutions have limitations as
vehicles travel all over the country and internationally, and are met with unforeseen road conditions. A
better approach would be to use cloud-based image processing. This solution would help when onboard
processors fail to interpret road signs inside of a minimum confidence level. The cloud-based approachgives vehicles access to greater processing power as well as a massive library of images to crossreference against. It is also not limited by the fixed processing hardware inside vehicles. Heavily crossreferenced images can be pushed OTA to all vehicles to bolster their onboard processing. However, this29 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

scenario assumes the existence of a nationwide low-latency high-speed 5G network. Therefore, until that
becomes a reality, vehicles will be susceptible to image processing attacks.

Compromised Roadway Infrastructure
Leveraged
Road-plying vehicles rely blindly on roadway infrastructure, such as traffic signals, messaging boards,
pedestrian signals, dynamic road barriers to manage the traffic flow. Based on our many years ofdriving experience, we inherently trust that these road infrastructures will work correctly. Most roadway
infrastructure today are network-connected to facilitate centralized management and control. This isachieved either via a direct network connection to central control or via cellular 3G/4G/LTE modems.
Roadway operators occasionally mistakenly leave these devices exposed online, which are easily
discoverable via internet scanning services such as Shodan.26 We discovered roadway infrastructurethat supports the National Transportation Communications for Intelligent Transportation System Protocol(NTCIP) and found exposed traffic signal controllers manufactured by Econolite (brand ASC/3). NTCIPsupported devices are a mixed bag consisting of traffic signals, dynamic message signs, environmental
sensors, CCTV, vehicle count stations, freeway ramp meters, video switches, transportation sensor
systems, field master stations for traffic signals, transit priority at traffic signals, and street lights.27

Figure 8. A list of exposed NTCIP devices in Shodan

30 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

Figure 9. Exposed Econolite ASC/3 traffic signal controllers in Shodan

Figure 10. Exposed traffic signal cameras in Shodan

These demonstrate the ease of discovering internet-exposed roadway infrastructure in Shodan, adding
to its risk is how they are also accessible to anyone from anywhere, creating a massive security hole. A
malicious attacker can mount a DDoS attack against these roadway infrastructures or exploit a vulnerability
to gain control of the device and cause dangerous road accidents. The overall cybersecurity of connectedcars extends beyond the inside of the car, meaning the whole ecosystem needs to be protected.28

Compromised App-API Supply Chain
It is fairly common for modern cars to have fully digital cockpits without analog dials and buttons andeverything is displayed or controlled using touchscreens and digital displays. The interior of the car looks
like a giant touchscreen phone, wherein many of these head units natively support a rich third-party app
ecosystem as well as Apple CarPlay and Android Auto. In addition to the apps that run on-board thevehicle, there are OEM-created apps installed on mobile phones that allow the driver to perform several

31 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

key functions such as locking and unlocking their car, starting and stopping the engine, controlling thetemperature inside the car, and locating their vehicle. These car apps access cloud services through amobile phone or the vehicle’s built-in eSIM.
The cloud is an API economy.29 One example of this API economy is the data flow when turning on aninternet-connected smart bulb via the Google Home App. Tapping the device’s power button on the
Google Home App sends a request to the Google Cloud, which then forwards the request to the bulb
manufacturer’s cloud, which finally sends the “turn on” command to the smart bulb. These actions are allaccomplished using APIs. Hence, it is not unrealistic to expect that a connected car’s cloud service makes
API calls to a T1 supplier’s cloud service, which in turn makes API calls to a T2 supplier’s cloud service,and so on. Any compromise in this cloud supply chain could adversely affect the connected car. This isprecisely what Qihoo 360’s SkyGo team demonstrated at Black Hat USA 2020.30

Figure 11. Illustrated control data stream used to compromise the cloud supply chain and control
autonomous vehicles
Image source: Security Research on Mercedes-Benz: From Hardware to Car Control by Guy Harpak,
Jiahao Li, and Minrui Yan31

The Sky-Go team successfully managed to access the Mercedes-Me (Mercedes-Benz’s vehicle
management App) backend servers that are serving the local Chinese market by physically removing an
eSIM from one of their test vehicles and connecting it to a 4G router with a flexible printed cable (FPC)
adapter. The 4G router then successfully obtained an intranet IP address from Mercedes’s ISP in China.
They next obtained a certificate from the ISP with which they were able to access the Mercedes-Me
backend servers.

32 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

Figure 12. Researchers having accessed car control commands after compromising
the cloud supply chain
Image source: Security Research on Mercedes-Benz: From Hardware to Car Control by Guy Harpak,
Jiahao Li, and Minrui Yan32

Once they gained access to the backend servers, they were able to use the APIs they extracted from the
Mercedes-Me app to send commands to any Mercedes-Me-enabled vehicle in China. This attack worked
because the Mercedes-Me backend servers did not authenticate the user requests it received from theapp. Although this is an extreme example of an API supply chain compromise that involved unauthorizedaccess to the backend servers, it does successfully demonstrate that this style of attack is possible
against connected cars and can potentially impact an entire fleet.

Figure 13. Researchers executing random malicious URLs in the head unit
Image source: Security Research on Mercedes-Benz: From Hardware to Car Control by Guy Harpak,
Jiahao Li, and Minrui Yan33
33 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and BeyondIn the same research paper, the SkyGo team demonstrated how they used a server-side request forgery(SSRF) attack against a third-party app installed in the vehicle’s head unit and get it to execute random
malicious URLs. These head units are commonly running customized versions of OS such as Linux and
QEMU, and thus are susceptible to common IT-style attacks such as SSRF, script injections via banners,
malvertising, SQL injections, XSS attacks, MitM, session hijacking, DNS spoofing, and many others.34
With the vehicle head units supporting app ecosystems, as well as being able to load both authorized andunauthorized (jailbroken phones) apps via Apple CarPlay and/or Android Auto, the App-API ecosystemaccessed by in-vehicle apps will quickly become a complicated security problem in the near future.

Social Engineering Attacks
Social engineering attacks use the art of deception for malicious end goals. These attacks are common in
the IT security world and include things like phishing, spear phishing, baiting, social media scams, scary
propositions, big news, and many others.35 Given the ways modern cars interact with mobile devices
and head units are all digital and touchscreen, it’s not inconceivable to find cybercriminals adapting theirsocial engineering toolkits to target connected car users.
A published research paper by Promon from 2016 shows how Tesla car owners were socially engineered
into installing a malicious app with the promise of a free meal at a nearby restaurant.36 The malicious app
replaced the Tesla app with itself using a privilege escalation attack. The malicious app mimicked thegenuine Tesla app and prompted the car’s owner to input their Tesla username and password, which theapp then exfiltrated to the attacker. The attacker can abuse the stolen credentials to unlock the target
vehicle, start the engine, and steal the car.
This is not an extreme example of a social engineering attack as most car manufacturers have createdapps for mobile phones that allow the driver to lock and unlock their vehicle, start and stop the engine,
control the temperature, and locate their vehicle. Most head units support Apple CarPlay and Android
Auto, which in turn support loading both authorized and unauthorized (on jailbroken phones) apps. The
authorized app list is limited, but by jailbreaking their phone, the driver can load any app from their phone
to the head unit.37, 38 This presents the perfect opportunity for cybercriminals to socially engineer drivers
into installing malicious apps that can then be loaded on the vehicle’s head unit and steal a wide rangeof data, such as vehicle location, saved credentials, access tokens or hashes from other apps, other PII,
and saved payment information.
Stealing data from a fleet of vehicles may become more profitable than stealing the physical vehicles
themselves. Malicious apps do not necessarily have to be loaded via jailbroken phones — the previous
section showed how the SkyGo research team successfully executed random malicious URLs via an
SSRF attack against an authorized third-party app installed in the vehicle’s head unit. Similar methods
can also be employed to remotely or drive-by install malicious apps or malware. If middleware abstracts
the E/E details of the vehicle and provides API access to apps to send messages to the ECUs, thenmalicious apps would be capable of potentially sending dangerous inputs to the ECUs while the vehicle
is moving, seriously jeopardizing everyone’s safety on the road.
34 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

Mitigating UN R155-DefinedThreats
In discussing the solution, let us first recap what connected cars are and the general progression of theirdevelopment. Connected cars are vehicles that have becomes a part of the ITS system, which consistsof a network and back-end system that functions as an information and communication technology (ICT)terminal. The development of connected cars will happen in this order:
1. The terminal or vehicle that originally ran as stand-alone units will be connected to the internet andstart to work by occasionally pulling out the necessary data from the back end.
2. It then starts to work with a more established connection to the internet and exchanging data in realtime.
3. Finally, many features and processes, even those traditionally performed by hardware, will move tothe cloud.
This is the same sequence that has happened within the IT world for the last few decades. However, we
expect the speed of this evolution to be much faster than that of IT, because we’ve already experienced
the development of IT. It should be noted, however, that this chain of events also applies to attackers.
In our previous research,39 we found that the connected car attack chain looks uncannily like typical
IT cyberattacks. The characteristic point is that after breaking through the entrance by exploiting avulnerability, attackers would then successfully use lateral movement to straddle multiple systems. This is
not surprising because connected vehicles share hardware, software, and communication protocols withthat of the IT world. We can expect them to share more similarities.
Given these similarities, we recommend applying several methods based on learnings and experiencesfrom the IT world and future threat predictions:
1. Connected car threat intelligence. It is built-in by integrating cyberthreat intelligence and automotive
threat intelligence. This is the baseline protection technology that can detect, analyze, thwart, andrespond to threats.

35 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

2. Multilayered security. The presence of a multilayered security solution would make it increasingly
difficult for attackers to succeed. No defense is impregnable to determined adversaries, but amultilayered approach increases the cost, the time, and the resources needed by a malicious actor tomount a successful attack.
3. Security covering a comprehensive ecosystem. Connected car security needs to be designedwith an integrated view of a comprehensive ecosystem, which is composed of an endpoint (vehicle),
network, and back end. These are critical areas to monitor in order to secure the end-to-end data
supply chain.
4. Vehicle Security Operations Center (VSOC). VSOC allows understanding the context of attacks
typically carried out by lateral movements spanning system to system by correlating notifications
from different components of a connected car ecosystem and then take the necessary actions orcountermeasures.

Phased Approach
Finally, how can stakeholders implement security that covers expansive connected car ecosystems? In
reality, security always comes as a trade-off and balance between benefits and cost.
Cybersecurity is an important business factor in connected cars, but it may not be possible to implement
all security solutions at once due to various restrictions. Therefore, it is necessary to determine the priorityof what to focus on and in what order, then determine the phased approach based on that prioritization.
At this time, considering the speed with which threats evolve parallel to the evolution of technology, we
recommend designing connected vehicles in a way that is oriented toward raising protection at a highspeed. The following figures illustrate our recommended phased approach.

36 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

Phase 1

AgentlessAgent Based

VSOC

Vehicle, Mobile, Backend

VSOC

The VSOC analyzes, correlates,and visualizes the threatsusing cybersecurity andautomotive threat intelligence.

• Endpoint security isimplemented; it protects inreal-time• Endpoint security sends
only the necessary logs to
the VSOC

The VSOC analyzes, correlates,and visualizes the threats fasterand at a deeper level with
sufﬁcient logs from theendpoints, withcybersecurity and automotive
threat intelligence.

Vehicle, Mobile, Backend

OEM sends logs to
VSOC using existingprocess/program.

Phase 2

Reactive Slow Protection, only shallow detection

Phase 3

Real-time Protection with detection

Agent and Network Based

Vehicle, Mobile,
Network, Backend• Endpoint security protects
in real-time• Monitors and protects atthe network level• Sends only necessary logs
to the VSOC

VSOC

The VSOC analyzes, correlates,and visualizes the threats fasterand at a deeper level with
sufﬁcient logs from theendpoints and network, withcybersecurity and automotive
threat intelligence.

Recommended Complete Real-time Protection with deep detection

Figure 14. Three recommended phases in developing security for the connected car

Trend Micro Solutions
To safeguard connected cars from the possibility of a successful attack, we prescribe a comprehensive
cybersecurity strategy that considers the entire connected car ecosystem composed of the vehicle,
network, back-end, and VSOC.40 Those solutions are backed-up by connected car threat intelligencebuilt by integrating automotive threat intelligence and cyberthreat intelligence from over 30 years of ourhistory enabling protection from this ever-growing threat.
Working with industry leaders, we understand that the requirements and optimal solutions for eachcustomer is different. Therefore, we provide customized solution for each customer. Trend Micro’s
customizable solution is not limited to technical solutions, and could, for example, include cybersecurity
training and vulnerability research. In collaboration with industry leader partners, we offer a solution to
support UN R155 compliance.
37 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

Management (VSOC)

In-vehicle

Network

Backend

Gateway

TCU, IVI

Mobile (Virtual)
Network Operator

Cloud/Datacenter

CAN BusAnomaly
Detection

Trend MicroTM
IoT Security for
Automotive

Trend MicroTM
Mobile Network
Security

Trend Micro
Cloud OneTM

Automotive-Cybersecurity Threat Intelligence

Trend MicroTM XDRFigure 15. A comprehensive protection against cyberattacks at four points: vehicle, network, backend,
and vehicle security operations center (VSOC).

For the Vehicle
Trend Micro IoT Security for Automotive provides multilayered security including system protection andapplication protection for critical devices connecting in-vehicle systems and outside networks, suchas telematic control units (TCU), IVIs, domain systems, and digital cockpits, while CAN Bus Anomaly
Detection monitors traffic in the CAN bus. It works as a sensor reporting critical logs to VSOC and HIDPS,
capable of filtering a tremendous amount of logs by ML models and threat expert rules to reduce network
bandwidth and resource consumptions at VSOC.

For the Network
Trend Micro Mobile Network Security (TMMNS) is a hybrid cybersecurity solution that ensures the network
security and identification integrity of vehicles connecting via cellular network. Based on the European
Telecommunication Standards Institute (ETSI) Network Functions Virtualization (NFV) framework, TMMNS
38 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

Network Protection offers VNF that can flexibly deploy at the mobile edge or core network for connectedcars to monitor traffic, detect, and take countermeasures with high performance and low latency. In themeantime, the TMMNS Endpoint Protection will identify the anomalous behavior and deny it access.
TMMNS Endpoint Protection is deployable on any subscriber identity module (SIM), such as physicalSIMs, eSIMs, and iSIMs, allowing users to harden vehicle security. TMMNS bridges the gap between
information and communication technologies (IT/CT) to provide comprehensive protection against
cyberattacks in 4G/LTE and 5G networks, covering the network and vehicle seamlessly.

For the Back End
Among the various connected technologies used by connected cars are applications and systems hosted
on back-end infrastructures. Many more of these applications and systems are bound to be built as the
adoption of connected cars continues to grow. The Trend Micro™ Cloud One™ security services platform
can be used to secure back-end cloud and data center environments without affecting performance.
Through the Trend Micro™ Zero Day Initiative™ program, it can detect and disclose vulnerabilities tokeep cloud environments and vehicle systems secure, especially since it is common for new and evolving
technologies to have known and unknown vulnerabilities. The platform also continuously analyzes andidentifies new malware, ransomware, and indicators of compromise that could be used in attacks. In
addition to ITS back-end systems, ITS endpoints need to be secured. The Trend Micro IoT Security™
solution can be used for this purpose, providing risk and anomaly detection and in-system protection fora wide range of IoT devices, including traffic lights and surveillance cameras.

For the VSOC
From our own experience, the following are the threats seen and pain points of most SOCs:•

Stealthy threats that continue to evade even the best of defenses•

Disconnected security layers with siloed tools and data sets that make it difficult to correlate
information and detect critical threats•

Too many alerts and overloaded organizations that don’t have the time or resources to conduct athorough investigation
Consolidated visibility into an organization’s current security status, trending over time, is hard tocome by and limits the ability to know what to focus on and where action should be taken

To ensure that the VSOC is able to correlate events quickly and effectively, the Trend Micro™ XDR®
analyzes, correlates, and visualizes events from the endpoint, the network, and the back end, withindividual notifications for each. It provides a comprehensive look at events alongside vital contextual
data, thereby helping organizations identify and thwart threats.

39 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

Conclusion
More than 125 million passenger cars with embedded connectivity are forecasted to ship worldwide
between 2018 and 2022,41 and the annual production of semi and fully autonomous vehicles are expected
to reach more than 14 million by 2025.42 The sheer volume of network-connected cars will both create
and expand new attack surfaces for the ITS ecosystem. Connected cars will be connected via 5G or
Direct Short-Range Communications (DSRC) (implemented using 802.11p or 802.11bd) to V2X and will
become one of the heaviest users of cloud infrastructure. Future vehicles will have functions from their
E/E architecture migrated to the cloud and communicating back to the vehicles via high-speed, lowlatency networks. Connected cars with their all-digital cockpits will support a rich ecosystem of thirdparty apps that will provide a host of innovative functionalities to both drivers and passengers. This opens
up many interesting attack scenarios against connected cars via cloud infrastructure attacks or throughE/E architecture agnostic middleware and cloud APIs.
Given the high level of expectations for connected cars and their potential exploitability, it is crucial toensure that automotive cybersecurity technologies stay well ahead of adversary TTPs. This is the Red
Queen hypothesis at play: a never-ending arms race with our competitors, the cybercriminals.
In this research paper, our assessment and insights about the attack vectors (listed in the UN Regulation
No. 155) against connected cars had a two-fold goal. First, we wanted to inform the various stakeholders
about the threats and challenges they are going to face on the roadways in the next couple of years andwhich threats they should prioritize. Second, identifying and addressing the cybersecurity risks faced byconnected cars in their early development stages gives us the opportunity to influence both legislative
and technological developments in this domain. We threat modeled the attack vectors listed in the UN
Regulation No. 155 by applying current technologies, hacker TTPs, and learnings from published researchin the car hacking domain. Within the next decade, especially with the global rollout of 5G networks, theavailable technology stack and TTPs are going to significantly change, and thus the threat profiles will
also shift. Finally, while the WP.29 document already lists an impressive array of cyberattack vectors, we
discovered additional attack vectors and focus areas that also need protection to ensure the overall safety
and security of connected cars.
In conclusion, the UN Regulation No. 155 and similar initiatives are the correct regulatory step forward toensure safe and secure roads, but it also needs to be flexible so that they can easily adapt with fast paced
technological developments and changes in human behavioral patterns.
40 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and BeyondReferences
1

United Nations. (n.d.). UNECE. “WP.29 - Introduction.” Accessed on July 26, 2021, at https://unece.org/wp29-introduction.

2

United Nations. (n.d.). UNECE. “Uniform provisions concerning the approval of vehicles with regards to cyber security andcyber security management system.” Accessed on July 26, 2021, at https://unece.org/sites/default/files/2021-03/R155e.pdf.

3

United Nations. (n.d.). UNECE. “WP.29 - Introduction.” Accessed on July 26, 2021, at https://unece.org/wp29-introduction.

4

United Nations. (June 24, 2020). UNECE. “Virtual meeting of the (WP.29) World Forum for the Harmonization of Vehicle
Regulations (181st session).” Accessed on July 26, 2021, at https://unece.org/transport/events/virtual-meeting-wp29-worldforum-harmonization-vehicle-regulations-181st-session.

5

United Nations. (n.d.). UNECE. “Uniform provisions concerning the approval of vehicles with regards to cyber security andcyber security management system.” Accessed on July 26, 2021, at https://unece.org/sites/default/files/2021-03/R155e.pdf.

6

Bob O’Donnell. (June 28, 2016). USA Today. “Your average car is a lot more code-driven than you think.” Accessed on July26, 2021, at https://www.usatoday.com/story/tech/columnist/2016/06/28/your-average-car-lot-more-code-driven-than-youthink/86437052/.

7

Irwin Bambrah. (Dec. 16, 2020). Tesloid. “How to update Model 3 software when there is no Wifi?” Accessed on Aug. 20,
2021, at https://tesloid.ca/2020/12/16/how-to-update-tesla-model-3-software-when-there-is-no-wifi/.

8

John Cusimano. (2011). SCADA Hacker. “Assessing the Security of ICS Using Threat Modeling.” Accessed on July 26, 2021,
at https://scadahacker.com/howto/howto-threatmodeling.html.

9

United Nations. (June 23, 2020). UNECE. “Proposal for a new UN Regulation on uniform provisions concerning the approvalof vehicles with regards to cyber security and cyber security management system.” Accessed on July 26, 2021, at https://
undocs.org/ECE/TRANS/WP.29/2020/79.

10 Microsoft. (July 14, 2010). Microsoft. “Chapter 3 Threat Modeling.” Accessed on July 26, 2021, at https://msdn.microsoft.
com/en-us/library/aa302419.aspx.
11 Dawid Czagan. (May 21, 2014). Infosec. “Qualitative Risk Analysis with the DREAD Model.” Accessed on July 26, 2021, at
https://resources.infosecinstitute.com/topic/qualitative-risk-analysis-dread-model/.
12 United Nations. (June 23, 2020). UNECE. “Proposal for a new UN Regulation on uniform provisions concerning the approvalof vehicles with regards to cyber security and cyber security management system.” Accessed on July 26, 2021, at https://
undocs.org/ECE/TRANS/WP.29/2020/79.
13 Numaan Huq, Craig Gibson, Vladimir Kropotov, and Rainer Vosseler. (Feb. 16, 2021). Trend Micro. “Cybersecurity forConnected Cars – Exploring Risks in 5G, Cloud, and Other Connected Technologies.” Accessed on July 26, 2021, at https://www.trendmicro.com/vinfo/us/security/news/internet-of-things/in-transit-interconnected-at-risk-cybersecurity-risks-ofconnected-cars.
14 Numaan Huq, Craig Gibson, Vladimir Kropotov, and Rainer Vosseler. (Feb. 16, 2021). Trend Micro. “Cybersecurity forConnected Cars – Exploring Risks in 5G, Cloud, and Other Connected Technologies.” Accessed on July 26, 2021, at https://www.trendmicro.com/vinfo/us/security/news/internet-of-things/in-transit-interconnected-at-risk-cybersecurity-risks-ofconnected-cars.
15 InetSoft. (n.d.). InetSoft. “InetSoft Webinar: The Data Supply Chain - Its Definition and How to Use It.” Accessed on July 26,
2021, at https://www.inetsoft.com/business/solutions/definition_of_data_supply_chain/.
16 Numaan Huq, Craig Gibson, Vladimir Kropotov, and Rainer Vosseler. (Feb. 16, 2021). Trend Micro. “Cybersecurity forConnected Cars – Exploring Risks in 5G, Cloud, and Other Connected Technologies.” Accessed on July 26, 2021, at https://www.trendmicro.com/vinfo/us/security/news/internet-of-things/in-transit-interconnected-at-risk-cybersecurity-risks-ofconnected-cars.
17 Numaan Huq, Rainer Vosseler, and Morton Swimmer. (Oct. 24, 2017). Trend Micro. “Cyberattacks Against Intelligent
Transportation Systems.” Accessed on Aug. 2, 2021, at https://www.trendmicro.com/vinfo/us/security/news/internet-ofthings/high-tech-highways-securing-the-future-of-transportation.

41 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

18 Numaan Huq, Craig Gibson, Vladimir Kropotov, and Rainer Vosseler. (Feb. 16, 2021). Trend Micro. “Cybersecurity forConnected Cars – Exploring Risks in 5G, Cloud, and Other Connected Technologies.” Accessed on July 26, 2021, at https://www.trendmicro.com/vinfo/us/security/news/internet-of-things/in-transit-interconnected-at-risk-cybersecurity-risks-ofconnected-cars.
19 German Sharabok. (Sep. 2, 2020). Towards Data Science. “Why Tesla Won’t Use LIDAR.” Accessed on Aug. 2, 2021, at
https://towardsdatascience.com/why-tesla-wont-use-lidar-57c325ae2ed5.
20 AutoPilot Review. (April 27, 2019). YouTube. “Elon Musk on Cameras vs LiDAR for Self Driving and Autonomous Cars.”Accessed on Aug. 2, 2021, at https://www.youtube.com/watch?v=HM23sjhtk4Q.
21 Nir Morgulis, Alexander Kreines, Shachar Mendelowitz, and Yuval Weisglass. (June 30, 2019). Research Gate. “Fooling a
Real Car with Adversarial Traffic Signs.” Accessed on Aug. 2, 2021, at https://www.researchgate.net/publication/334161359_
Fooling_a_Real_Car_with_Adversarial_Traffic_Signs.
22 Jonathan Gitlin. (Sept. 2, 2017). Ars Technica. “Hacking street signs with stickers could confuse self-driving cars.” Accessedon Aug. 2, 2021, at https://arstechnica.com/cars/2017/09/hacking-street-signs-with-stickers-could-confuse-self-driving-cars/.
23 Jonathan Gitlin. (Sept. 2, 2017). Ars Technica. “Hacking street signs with stickers could confuse self-driving cars.” Accessedon Aug. 2, 2021, at https://arstechnica.com/cars/2017/09/hacking-street-signs-with-stickers-could-confuse-self-driving-cars/.
24 Nir Morgulis, Alexander Kreines, Shachar Mendelowitz, and Yuval Weisglass. (June 30, 2019). Research Gate. “Fooling a
Real Car with Adversarial Traffic Signs.” Accessed on Aug. 2, 2021, at https://www.researchgate.net/publication/334161359_
Fooling_a_Real_Car_with_Adversarial_Traffic_Signs.
25 Nir Morgulis, Alexander Kreines, Shachar Mendelowitz, and Yuval Weisglass. (June 30, 2019). Research Gate. “Fooling a
Real Car with Adversarial Traffic Signs.” Accessed on Aug. 2, 2021, at https://www.researchgate.net/publication/334161359_
Fooling_a_Real_Car_with_Adversarial_Traffic_Signs.
26 Shodan. (n.d.). Shodan. “Shodan.” Accessed on Aug. 2, 2021, at https://www.shodan.io/.
27 National Transportation Communications for Intelligent Transportation System (ITS) Protocol (NTCIP). (2009). NTCIP. “National
Transportation Communications for ITS Protocol .” Accessed on Aug. 2, 2021, at https://www.ntcip.org/file/2018/11/
NTCIP9001v0406r.pdf.
28 National Transportation Communications for Intelligent Transportation System (ITS) Protocol (NTCIP). (2009). NTCIP.
“National Transportation Communications for ITS Protocol.” Accessed on Aug. 2, 2021, at https://www.ntcip.org/file/2018/11/
NTCIP9001v0406r.pdf.
29 Kelly Sheridan. (March 6, 2020). Dark Reading. “7 Cloud Attack Techniques You Should Worry About.” Accessed on Aug. 2,
2021, at https://www.darkreading.com/cloud/7-cloud-attack-techniques-you-should-worry-about/d/d-id/1337259?image_number=7.
30 Guy Harpak, Jiahao Li, and Minrui Yan. (Aug. 6, 2020). Black Hat USA 2020. “Security Research on Mercedes-Benz: From
Hardware to Car Control.” Accessed on Aug. 2, 2021, at https://i.blackhat.com/USA-20/Thursday/us-20-Yan-SecurityResearch-On-Mercedes-Benz-From-Hardware-To-Car-Control-wp.pdf.
31 Guy Harpak, Jiahao Li, and Minrui Yan. (Aug. 6, 2020). Black Hat USA 2020. “Security Research on Mercedes-Benz: From
Hardware to Car Control.” Accessed on Aug. 2, 2021, at https://i.blackhat.com/USA-20/Thursday/us-20-Yan-SecurityResearch-On-Mercedes-Benz-From-Hardware-To-Car-Control.pdf.
32 Guy Harpak, Jiahao Li, and Minrui Yan. (Aug. 6, 2020). Black Hat USA 2020. “Security Research on Mercedes-Benz: From
Hardware to Car Control.” Accessed on Aug. 2, 2021, at https://i.blackhat.com/USA-20/Thursday/us-20-Yan-SecurityResearch-On-Mercedes-Benz-From-Hardware-To-Car-Control.pdf.
33 Guy Harpak, Jiahao Li, and Minrui Yan. (Aug. 6, 2020). Black Hat USA 2020. “Security Research on Mercedes-Benz: From
Hardware to Car Control.” Accessed on Aug. 2, 2021, at https://www.blackhat.com/us-20/briefings/schedule/#securityresearch-on-mercedes-benz-from-hardware-to-car-control-20746.
34 Sébastien Dudek. (March 18, 2019). Synacktiv. “Modmob tools and tricks: Using cheap tools and tricks to attack
mobile devices in practice.” Accessed on Aug. 2, 2021, at https://www.synacktiv.com/ressources/Troopers_NGI_2019Modmobtools_and_tricks.pdf.
35 Trend Micro. (n.d.). Trend Micro. “Social engineering.” Accessed on Aug. 2, 2021, at https://www.trendmicro.com/vinfo/us/
security/definition/social-engineering.

42 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

36 Promon. (Nov. 23, 2016). Promon. “Tesla cars can be stolen by hacking the app.” Accessed on Aug. 2, 2021, at https://
promon.co/security-news/hacking-tesla-app-stolen-car/.
37 iPodHacks142. (July 17, 2019). iPodHacks142. “How to Use ANY App with Apple CarPlay.” Accessed on Aug. 2, 2021, at
https://www.ipodhacks142.com/how-to-use-any-app-with-apple-carplay/.
38 Tomasz Grobelny. (Dec. 17, 2020). Opensource. “How to hack Android Auto to display custom content.” Accessed on Aug. 2,
2021, at https://opensource.com/article/20/12/android-auto-open-source.
39 Numaan Huq, Craig Gibson, and Rainer Vosseler. (Aug. 18, 2020). Trend Micro. “Driving Security Into Connected Cars: Threat
Model and Recommendations.” Accessed on Aug. 2, 2021, at https://www.trendmicro.com/vinfo/us/security/news/internetof-things/the-cybersecurity-blind-spots-of-connected-cars.
40 Trend Micro. (n.d.). Trend Micro. “Connected Car Security.” Accessed on Aug. 23, 2021, at https://www.trendmicro.com/
en_us/business/solutions/iot/connected-car.html.
41 Internet of Business. (2020). Internet of Business. “Connected cars report: 125 million vehicles by 2022, 5G coming.”
Accessed on Aug. 2, 2021, at https://internetofbusiness.com/worldwide-connected-car-market-to-top-125-million-by-2022/.
42 Nick Michell. (Dec. 5, 2016). Cities of Today. “Self-driving cars to reach 14.5 million by 2025, says new study.” Accessed on
Aug. 2, 2021, at https://cities-today.com/self-driving-car-production-reach-14-5-million-2025-says-new-study/.

43 | Identifying Cybersecurity Focus Areas in Connected Cars Based on WP.29 UN R155 Attack Vectors and Beyond

TREND MICROTM RESEARCH
Trend Micro, a global leader in cybersecurity, helps to make the world safe for exchanging digital information.
Trend Micro Research is powered by experts who are passionate about discovering new threats, sharing key insights, and supporting
efforts to stop cybercriminals. Our global team helps identify millions of threats daily, leads the industry in vulnerability disclosures,and publishes innovative research on new threat techniques. We continually work to anticipate new threats and deliver thoughtprovoking research.
www.trendmicro.com©2021
by Trend Micro,
Incorporated.
All rights
reserved.
Trend MicroandBased
the Trend
Micro t-balllogo aretrademarks
or registeredtrademarks of
44 | Identifying
Cybersecurity
Focus
Areas
in Connected
Cars
on WP.29
UN R155
AttackVectorsand Beyond
Trend Micro, Incorporated. All other product or company names may be trademarks or registered trademarks of their owners.