Security Challenges and Innovations in Automobile - A2V and A2I Systems and Connected Vehicles - Research Report

This is a research report on the security challenges of automobile-to-vehicle (A2V) and automobile-to-infrastructure (A2I) communication in connected vehicles. It has an abstract, stated aims and objectives, a literature review that separates what the evidence has established from what it has left open, and a discussion of what the risks mean for the companies building these systems. The structure, aims and argument are the student's; the evidence in the literature review has been re-sourced to the primary documents listed under Sources and References. A section on the regulation now in force follows the report.

A word on terminology before you read it. The published literature calls these systems vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I). This report was submitted using the terms A2V and A2I for the same two channels, so the body keeps that wording while the reference list keeps the titles of the cited papers exactly as they were published.

For a related report on urban transport technology, read our smart city transportation report. For the computing side of connected systems, see the report on mobile cloud computing.

What Are A2V and A2I Systems?

A2V and A2I are the two channels of vehicle communication. A2V lets cars exchange position, speed and hazard messages directly with one another. A2I connects the car to roadside equipment: signals, variable signs, toll points and traffic management systems. Both are prerequisites for cooperative driving, and both widen the attack surface of the vehicle.

A2V against A2I: the two channels compared

Point of comparison	A2V (car to car)	A2I (car to roadside)
What is exchanged	A2V (car to car) Position, speed and hazard warnings between vehicles	A2I (car to roadside) Signals, signs, toll and traffic-management data between the car and roadside units
Who it depends on	A2V (car to car) Other vehicles that meet for seconds and separate	A2I (car to roadside) A roadside unit and the network behind it
How far it is deployed	A2V (car to car) Further, because it needs no roadside equipment	A2I (car to roadside) Less far, because roadside units cost money to install and maintain
Where trust breaks	A2V (car to car) No fixed structure to trust; revoked credentials may go unchecked out of coverage	A2I (car to roadside) A fixed target: a hacked roadside unit can spread wrong traffic and safety messages to every vehicle it serves

What Are the Main Security Challenges in Connected Vehicles?

The main challenges are authenticity, availability and privacy, and they map onto the classic security triad. Authenticity: a forged message can change how other vehicles behave. Availability: a denial-of-service attack removes the data cars depend on for safety decisions. Privacy: position and route data identifies a driver. The literature reviewed below addresses the first two far more than the third.

Research Project on the Security Challenges of A2V and A2I

What the evidence has settled and what is still open

Point of comparison	What the evidence shows	What is still open
Attack surface	What the evidence shows Remote control of braking and steering demonstrated on an unmodified production car in 2015	What is still open Every new interface reopens the assessment; R155 requires it to be kept current
Software updates	What the evidence shows Without over-the-air updates, the 2015 fix meant a 1.4 million vehicle recall by posted USB drive	What is still open Keeping a fleet patched to end of life; R156 sets the process, not the engineering
Denial of service	What the evidence shows Flooding and black-hole attacks are classified in the survey literature and detectable with lightweight authentication	What is still open Protection against an internal attacker holding valid credentials
On-board computing	What the evidence shows The overhead and latency of each cryptographic method have been measured	What is still open Which level of protection fits inside the latency budget of a safety message
Privacy	What the evidence shows Pseudonyms and anonymous identities have been proposed	What is still open Revoking a misbehaving vehicle without exposing its owner; far less studied than availability

Abstract

This report examines the security challenges of automobile-to-vehicle and automobile-to-infrastructure communication. The topic was chosen because both channels are now being built into production vehicles, which makes their weaknesses a practical problem rather than a theoretical one. The report sets out the security challenges recorded in the literature and in the documented attacks on production vehicles, identifies which of them that evidence has settled and which it has left open, and considers what the answers mean for the companies bringing these systems to market.

Introduction

A modern vehicle is no longer a purely mechanical system. It runs on millions of lines of code spread across tens of processors (Checkoway et al., 2011), and an increasing amount of that code exists in order to exchange data with something outside the car. Two of those exchanges are the subject of this report. A2V is the wireless sharing of information between vehicles, typically safety warnings, position, speed and hazard alerts (Alnasser, Sun and Jiang, 2019). A2I is the wireless exchange of information between the vehicle and the road infrastructure. It is intended to avoid or reduce accidents and improve mobility, and it has been deployed less widely than A2V because of the cost of installing and maintaining the roadside equipment (Malik et al., 2019).

Both channels are prerequisites for automated driving, and both extend the boundary of the vehicle to include whatever it is talking to. That is the source of the security problem: every message a car accepts from outside is an input an attacker would like to control. ENISA's review of smart-car security makes the same point in one sentence, that V2V and V2I interfaces "largely expand the potential attack surface and attack vectors" (ENISA, 2019). This report sets out the security challenges reported in the literature on these two systems, and then considers the implications for the vehicle manufacturers, their suppliers and the wider automotive industry.

Research Aims and Objectives

Aims

The aim of the research is to identify the security challenges in automobile-to-vehicle and automobile-to-infrastructure communication, and to assess how well the current literature addresses them.

Objectives

• To set out the security challenges reported in automotive A2V and A2I systems.
• To identify the gaps in the literature on A2V and A2I security.
• To assess the prospects for A2V and A2I systems given those gaps.

Literature Review

The review draws on two kinds of source: the academic literature on vehicular network security, and the primary documents that record what happened when a production vehicle was attacked and how regulators responded. It is organised in three parts: the challenges reported, the developments the same evidence records, and the questions it leaves open.

Challenges and Problems in A2V and A2I Technology

Five security challenges recur across the literature on A2V and A2I systems.

• Software that cannot be updated in the field. A vehicle without over-the-air update capability cannot be patched once a vulnerability is found, so the fix has to reach every car by hand. When Miller and Valasek (2015) showed that a 2014 Jeep Cherokee could be controlled through its cellular connection, the manufacturer recalled 1.4 million vehicles and posted each owner a USB drive carrying the update; owners who could not install it themselves could have a dealer do it at no charge (NHTSA, 2017). ENISA (2019) treats the update channel itself as an asset to be secured, because a compromised back-end server could push a malicious update to a whole fleet at once.
• Limited on-board computing. The units that send and receive vehicular messages have fixed processing budgets and tight latency limits, and security measures compete with them. Alnasser, Sun and Jiang (2019) report that symmetric key systems add delay in key distribution, that asymmetric cryptography is slower and adds latency, and that revocation in group-signature schemes needs high computation power and produces signatures too large to transmit over the air; the lightweight authentication schemes they review were designed around "resource constraints of on-board unit and latency limit".
• A wide and growing attack surface. Checkoway et al. (2011) tested the external interfaces of a production sedan and found exploitable entry points through the diagnostic port (via a mechanic's tool), the CD player, Bluetooth and the cellular telematics unit; the wireless channels allowed long-distance control, location tracking and audio capture from the cabin. Each supplier adds a component and each component adds a way in, which is why ENISA (2019) directs its security measures at suppliers as well as manufacturers: most of a car's components are built by suppliers to requirements the manufacturer defines.
• Safety consequences for occupants. Because A2V and A2I messages carry data used in safety decisions, a manipulated or lost message is not only a data problem. Miller and Valasek's remote attack reached the brakes and the steering of the target vehicle (Miller and Valasek, 2015), and Dong et al. (2020) simulate what an attack on the messages themselves does to a stream of connected vehicles: as the share of attacked vehicles and the severity of the attack rise, road capacity falls and the risk of rear-end collision rises, and an attack on reported position does more damage than an attack on reported speed.
• Denial of service. Flooding the channel saturates the receiving system so that genuine safety messages arrive late or not at all. Alnasser, Sun and Jiang (2019) rank attacks on availability as the most dangerous in a vehicular network because of their effect on safety-critical situations, and describe black-hole and grey-hole attacks in which a compromised node simply stops relaying packets; authentication keeps an outsider off the packet route, but the standard they review does not protect the network from an internal attacker holding valid credentials. Yasir and Croock (2020) propose a detection and blocking system for exactly this attack, tested on a simulated six-car network with lightweight authentication.

One further problem is specific to A2V. Vehicles that meet for seconds and then separate have no fixed structure to trust. The V2V review by El Zorkany, Yasser and Galal (2020) lists "defining management and technical structure of the communications-security system" among the open challenges, alongside the requirement that every connection between cars be authenticated and encrypted. In LTE-based V2X the same problem shows up as a gap in revocation: two units outside network coverage may go on communicating with a unit whose credentials have already been revoked, because neither can check (Alnasser, Sun and Jiang, 2019). A2I has the mirror-image problem. The roadside unit is a fixed target that serves every vehicle in range, and ENISA (2019) lists hacking a roadside unit to spread wrong traffic and safety messages among its attack scenarios for connected cars.

What the Selected Literature Says About Current Development

The papers selected for this review were chosen because they evaluate A2V and A2I systems rather than only describing them. Two developments stand out. The first is on the defensive side: work on detection rather than prevention alone. He et al. (2020) build a cyber-security framework for connected and autonomous vehicles around the UK's CAV cyber security principles, generate a communication-attack data set from it and train two classifiers on that data; the decision tree runs faster and is the one they recommend for detecting communication attacks. Detection matters because the attack surface cannot be closed entirely: the entry points Checkoway et al. (2011) found are also the features customers pay for.

The second is structural. The security of a vehicle's communication stack is distributed across a supply chain rather than held by one manufacturer, because most components are not produced by the manufacturer but by its suppliers to a set of requirements the manufacturer defines (ENISA, 2019). ENISA's good practices therefore begin with the supply chain: define the cyber-security aspects of every partnership along it and write security requirements into procurement. That structure is the reason a vulnerability in one supplier's module can appear across several makes at once. The Uconnect head unit at the centre of the Jeep attack was a supplier's product fitted across several of the manufacturer's brands (Miller and Valasek, 2015).

Areas the Current Literature Has Addressed

Three of the five challenges are documented with evidence rather than asserted. The first is the remote attack surface. It was demonstrated on a production car in 2011 and again in 2015, the second time without any modification to the vehicle and from anywhere in the United States (Checkoway et al., 2011; Miller and Valasek, 2015). The second is the consequence of vehicles that cannot be updated in the field: the 2015 recall is the measured cost, 1.4 million vehicles and a USB drive in the post (NHTSA, 2017). The third is denial of service, which the survey literature classifies and the simulation literature detects (Alnasser, Sun and Jiang, 2019; Yasir and Croock, 2020).

Each of these findings has since been written into regulation. UN Regulation No. 155 lists denial of service, compromise of the update procedure and attacks through back-end servers among the threats a manufacturer's risk assessment must consider (UNECE, 2021a, Annex 5), and UN Regulation No. 156 requires that the authenticity and integrity of software updates be protected and that a vehicle can be restored to its previous version or placed in a safe state if an update fails (UNECE, 2021b, paragraphs 7.2.1.1 and 7.2.2.1.1). A finding that a regulator has turned into a type-approval condition is, for the purposes of this review, addressed.

Areas and Issues that Have Not Been Addressed

Two questions are raised in the reviewed work but not answered. The first is how much security a resource-limited on-board unit can afford. The survey literature measures the overhead of each cryptographic method and notes that adding a further layer "will increase the overhead on the network", but it does not settle which level of protection fits inside the latency budget of a safety message; it lists the latency limit and the structure of the security model as open research questions (Alnasser, Sun and Jiang, 2019).

The second is privacy. Position and route data identifies a driver. The reviewed papers acknowledge this: the survey covers pseudonym schemes and anonymous identities as a way to revoke a misbehaving vehicle without exposing its owner (Alnasser, Sun and Jiang, 2019), and the V2V review states that safety messages must carry no personal data at all (El Zorkany, Yasser and Galal, 2020). Both are design recommendations rather than settled answers, and the same papers give far more space to availability and authenticity. That imbalance is the clearest gap in this literature.

Discussion of the Views of the Issues

The issues set out above are documented by the cited authors rather than inferred here, which matters for a report of this kind: each claim can be checked against the paper, the recall report or the regulation it came from. What the literature does not do is translate them into decisions, and that is where a management reading adds something.

Three implications follow. First, vehicle security is a product development decision with a deadline, because a vehicle's electronics are specified years before the car is sold and stay in service long after it. R155 names this the post-production phase and ends it only when no vehicle of the type is still operational (UNECE, 2021a, paragraph 2.7). Second, it is a supply chain decision, since the communication stack is assembled from components bought from several suppliers and a manufacturer can only require what it specifies (ENISA, 2019). Third, it is a reputational decision, because a demonstrated attack on a connected vehicle is reported as a safety story rather than a software story. The 2015 attack produced a recall filed under the safety-defect rules even though the manufacturer stated it had not determined that a defect existed (NHTSA, 2017).

The industry's response has been to manage the exposure rather than withdraw from connected driving. The manufacturer in the 2015 case patched the head unit, had the carrier close the open port on the cellular network and mailed the update to owners (NHTSA, 2017). ENISA's good practices, published four years later, set out the organisational version of the same response: assess the security controls at least once a year over the vehicle's lifecycle, deploy tested patches, and re-check the security assumptions every six months (ENISA, 2019). That is the commercially rational response to a risk that cannot be eliminated: the features are what customers are buying, so the work goes into managing the exposure they create.

Summarisation of the Future Direction

On the evidence reviewed here, security work becomes a recurring cost across the life of a vehicle instead of a one-off development task. A vehicle that can be updated has to be monitored for as long as it is on the road, and under R155 the outcome of that monitoring is something the manufacturer reports to the approval authority at least once a year (UNECE, 2021a, paragraph 7.4.1). Two things follow for the industry. The measure of a manufacturer's security is shifting from the product to the process that maintains it, and the evidence a manufacturer needs is shifting with it, from test results to records of what was monitored, detected and fixed.

The gap this report identifies, the imbalance between work on authenticity and availability and work on privacy, is a reasonable subject for further research. The more immediate question for a manufacturer is how it demonstrates compliance. The next section sets out what is now required.

What Does Regulation Now Require of Connected Vehicles?

A certified management system, not just a secure product. UN Regulation No. 155 makes a cyber security management system a condition of vehicle type approval, and the processes it certifies cover the development, production and post-production phases, so the obligation continues after the last vehicle of the type has been built. It was published in the Official Journal of the European Union on 9 March 2021 (OJ L 82, pp. 30-59).

The regulation defines the management system as "a systematic risk-based approach defining organisational processes, responsibilities and governance to treat risk associated with cyber threats to vehicles and protect them from cyberattacks" (paragraph 2.3). That matters for the literature gap identified above. The studies reviewed in this report treat vehicle security as an engineering problem, which was reasonable when they were written. Under R155 it is also a type-approval problem: a manufacturer must show a regulator that it has processes for identifying risks to a vehicle type, treating them, testing the vehicle before approval, keeping the risk assessment current, and monitoring for, detecting and responding to attacks once vehicles are on the road (paragraph 7.2.2.2). The vehicle type itself must carry measures that detect and prevent attacks, support the manufacturer's monitoring and keep forensic data for analysing attempted or successful attacks (paragraph 7.3.7). A report written now should therefore separate the technical countermeasures from the governance obligations, because they are assessed by different people and on different evidence.

Two companion documents complete the picture. UN Regulation No. 156, published alongside R155, requires a software update management system and sets conditions for over-the-air updates: the update's authenticity and integrity must be protected, the vehicle must be able to restore the previous version or enter a safe state if an update fails, and where executing an update while driving would not be safe the manufacturer must show how it prevents the vehicle being driven during the update (UNECE, 2021b, paragraphs 7.2.1.1, 7.2.2.1.1 and 7.2.2.3). ISO/SAE 21434:2021 is the engineering standard behind both: it "specifies engineering requirements for cybersecurity risk management regarding the concept, product development, production, operation, maintenance, and decommissioning" of a vehicle's electrical and electronic systems (ISO, 2021).

R155 applies to vehicles in categories M and N, to category O vehicles fitted with at least one electronic control unit, and to L6 and L7 vehicles equipped with automated driving from level 3 onwards (paragraph 1). Whether and when a given market requires it for every new vehicle, rather than for new vehicle types, depends on how that market has adopted the regulation, so check the current position for the jurisdiction your assignment is about rather than quoting a single date.

More samples like this are in our computer science assignment samples and business assignment samples. This report sits between two of our services, because it is a management report on a computing subject: see MBA assignment help for the discussion and recommendations side and computer science assignment help for the technical side. Report writing help covers the format itself. The commercial side of the same industry, including the NHTSA investigation into Tesla's driver-assistance software opened in October 2025, is covered in our SWOT analysis of Tesla.

Other management samples: root cause analysis with a fishbone diagram, Boohoo versus Next customer journey analysis, cross-cultural differences in business practice and communication and investment analysis, ratios and diversification.

Need a research report on connected vehicle security, with aims, a literature review and a stated gap? Message us on WhatsApp with the brief, the word count and the deadline.

Sources and References

• UNECE (2021a) UN Regulation No. 155: uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system [2021/387], OJ L 82, 9 March 2021, pp. 30-59. eur-lex.europa.eu.
• UNECE (2021b) UN Regulation No. 156: uniform provisions concerning the approval of vehicles with regards to software update and software update management system [2021/388], OJ L 82, 9 March 2021, pp. 60-74. eur-lex.europa.eu.
• ISO (2021) ISO/SAE 21434:2021 Road vehicles: cybersecurity engineering. Geneva: International Organization for Standardization. iso.org.
• Miller, C. and Valasek, C. (2015) Remote exploitation of an unaltered passenger vehicle, 10 August 2015. illmatics.com.
• NHTSA (2017) Part 573 safety recall report 15V-461: Chrysler (FCA US LLC), radio software security vulnerabilities, report as amended 13 July 2017 (recall opened July 2015). static.nhtsa.gov.
• Checkoway, S., McCoy, D., Kantor, B., Anderson, D., Shacham, H., Savage, S., Koscher, K., Czeskis, A., Roesner, F. and Kohno, T. (2011) Comprehensive experimental analyses of automotive attack surfaces. Proceedings of the 20th USENIX Security Symposium. autosec.org.
• ENISA (2019) ENISA good practices for security of smart cars, November 2019. enisa.europa.eu.
• Alnasser, A., Sun, H. and Jiang, J. (2019) Cyber security challenges and solutions for V2X communications: a survey. Computer Networks, 151, pp.52-67. doi.org/10.1016/j.comnet.2018.12.018; open-access version at arxiv.org/abs/1901.01053.
• Malik, R.Q. et al. (2019) Mapping and deep analysis of vehicle-to-infrastructure communication systems. IEEE Access, 7, pp.126753-126772. doi.org/10.1109/ACCESS.2019.2927611.
• Dong, C., Wang, H., Ni, D., Liu, Y. and Chen, Q. (2020) Impact evaluation of cyber-attacks on traffic flow of connected and automated vehicles. IEEE Access, 8, pp.86824-86835. doi.org/10.1109/ACCESS.2020.2993254.
• He, Q., Meng, X., Qu, R. and Xi, R. (2020) Machine learning-based detection for cyber security attacks on connected and autonomous vehicles. Mathematics, 8(8), 1311. doi.org/10.3390/math8081311.
• Yasir, M.N. and Croock, M.S. (2020) Cyber DoS attack-based security simulator for VANET. International Journal of Electrical and Computer Engineering, 10(6), pp.5832-5843. doi.org/10.11591/ijece.v10i6.pp5832-5843.
• El Zorkany, M., Yasser, A. and Galal, A.I. (2020) Vehicle to vehicle "V2V" communication: scope, importance, challenges, research directions and future. The Open Transportation Journal, 14(1). doi.org/10.2174/1874447802014010086.