A Survey of Security and Privacy Issues in V2X Communication Systems

1.1 Overview

• V2X spans vehicle, infrastructure, pedestrian, network, and infrastructure-to-network communication, with expected safety and transport benefits.NHTSA projects safety gains from V2V, while the EC lists travel-time, efficiency, accident-rate, and fuel benefits from C-ITS.Source: §1.1 · p. 2
• Growing vehicle software and connectivity enlarge the attack surface, while CAN lacks authentication and message-integrity protection and unprotected authenticated links can expose driver privacy.Privacy-preserving pseudonyms bring their own security and safety challenges, and proposed mitigations are not necessarily adopted by standards bodies.Source: §1.1 · p. 3

1.2 Methodology and Contributions

• The survey reviews security and privacy research and standardization from the ETSI ITS perspective, emphasizing EU projects while placing EU–US differences in context.It identifies standardization gaps, including issues associated with C-V2X smartphone integration, and offers recommendations and potential solutions for further investigation.Source: §1.2 · p. 4

1.3 Document Organization

• The paper moves from related work and technology standards through security management and threat analysis to detailed gap analysis, root causes, recommendations, and conclusions.Figure 2 maps the security and privacy topics covered in the paper.Source: §1.3 · p. 4

2.1 Survey Papers

• Earlier surveys cover specific topics such as misbehavior detection, authentication, certificate revocation, and security approaches for DSRC and C-V2X.The paper groups surveys into general vehicular-network work, work spanning DSRC and C-V2X, and C-V2X-focused surveys.Source: §2.1 · pp. 5–6
• Unlike those surveys, this work targets fundamental ETSI ITS standard gaps and security and privacy issues not previously discussed in related surveys.Prior work commonly analyzes threats, requirements, and proposed solutions within particular security areas.Source: §2.1 · pp. 6–7

2.2 European Union Research Actions

• Earlier EU projects addressed security and privacy, and some likely helped shape ETSI specifications that appeared from 2012 onward.Examples include SeVeCom’s pseudonym-change mechanism, PRECIOSA’s privacy-by-design work, and EVITA’s secure onboard architecture.Source: §2.2 · pp. 7–8
• More recent EU projects emphasize V2X technology demonstrations, but the analyzed 5G-PPP projects omit security considerations and often leave communication assumptions unclear.The authors’ gap analysis draws on those project documents, ETSI ITS specifications, and research papers, identifying security gaps and conflicts with V2X aims.Source: §2.2 · p. 8

3 V2X TECHNOLOGIES

• The survey introduces IEEE- and 3GPP-specified V2X standards to frame how their security aspects differ.Shared features are outside this survey’s scope.Source: §3 · p. 8

3.1 IEEE standard

• IEEE 802.11p’s OCB mode supports WLAN-based V2X, with IEEE 1609 and ETSI ITS defining upper-layer protocols for DSRC and ITS-G5.The intended uses are short-range V2V and V2I communications, including links to roadside units.Source: §3.1 · pp. 8–9

3.2 3GPP standard

• 3GPP C-V2X builds on LTE and later 5G, combining short-range PC5 sidelink with long-range Uu communication.PC5 was defined for LTE in TS 23.285, with equivalent 5G functionality in TS 23.287.Source: §3.2 · p. 9

3.3 Differences between ITS-G5/DSRC and C-V2X

• The survey uses ITS-G5 for the IEEE-based standard and C-V2X for the 3GPP standard when comparing their conceptual differences.ITS-G5 initially focused on vehicle-centered V2V and V2I, while C-V2X also encompasses cellular-network and pedestrian communication.Source: §3.3 · p. 9, §3.3.1 · p. 9

3.3.1 Two different target scenarios.

• ITS-G5 V2X centers on vehicles and roadside units, whereas C-V2X also includes mobile networks and smartphone-equipped pedestrians or cyclists.The C-V2X model therefore includes V2V, V2I, V2N, and V2P; ITS-G5 uses V2X for V2V and V2I.Source: §3.3.1 · pp. 9–10

3.3.2 Specific Issues with ITS-G5.

• IEEE 802.11 OCB has reliability and performance problems in vehicular settings, including collision and fading risks, traffic-load effects, and severe hidden-terminal problems in broadcast.Unicast acknowledgments can also cause head-of-line blocking when an acknowledgment is prevented; cellular resource management can address some performance issues at a latency cost.Source: §3.3.2 · p. 10

3.4 ISO standard

• ISO 26262 covers automotive functional safety, while ISO/SAE 21434 sets a lifecycle cybersecurity-engineering process and ISO 39001 addresses road-traffic-safety management.ISO/SAE 21434 remains abstract, does not prescribe implementation details, and excludes autonomous vehicles and non-vehicle systems such as RSUs.Source: §3.4 · pp. 10–11

4 SECURITY MANAGEMENT SYSTEM OVERVIEW

• Both the EU and US security management systems are based on PKI and focus particularly on managing certificates for ITS-Stations.The section establishes their similarities and differences as a baseline for later discussion.Source: §4 · p. 11

4.1 ETSI C-ITS and IEEE 1609.2

• The US certificate management system is SCMS, specified in IEEE 1609.2, while ETSI TS 102 940 defines the overall C-ITS security-management architecture.Figure 3 presents the system entities and their relationships, including reference points such as S1 and S2.Source: §4.1 · p. 11, Table 3 · p. 12, Figure 3 · p. 12

4.2 Differences between ETSI C-ITS and IEEE 1609.2

• The EU and US systems differ in their certificate-management architectures and the extent of functional and ownership separation.The section frames these differences between ETSI ITS and IEEE 1609.2 (SCMS).Source: §4.2 · p. 11, §4.2.1 · pp. 11–12

4.2.1 Architectural Principles of Security Management.

• ETSI ITS requires additional design and implementation beyond its standard to match SCMS’s separation of functions and ownership; SCMS requires multiple organizations to collude to identify a vehicle.SCMS uses purpose-specific Registration Authority and Linkage Authorities.Source: §4.2.1 · pp. 11–12

4.2.2 Revocation of ITS-S Certificates.

• ETSI ITS relies on passive revocation by denying a vehicle further certificates, whereas SCMS actively revokes pseudonyms through a CRL.SCMS’s Misbehaving Authority correlates reports and, after confirmation, obtains linkage seeds through the Pseudonym CA, Registration Authority, and Linkage Authorities; vehicles use CRL entries to identify revoked certificates.Source: §4.2.2 · pp. 12–13

4.2.3 Certificate Issuing and Usage Schemes.

• Neither SCMS nor ETSI ITS specifications explicitly set the certificate-change period within a week, although that period affects tracking and identification vulnerability.The ETSI pseudonym-management report lists schemes with pools of 10–100 certificates; IFAL uses one pseudonym at a time without reuse.Source: §4.2.3 · p. 13

• The attack-and-threat inventory is presented as the authors’ view and is explicitly not exhaustive.The authors note that new attack types may emerge in the future.Source: §5 · p. 13, Table 4 · p. 14
• Adversaries’ different motivations and goals relate to the CIA triad: confidentiality, integrity, and availability.The passage contrasts an individual hacker’s disruption with an organized crime group’s potential aim to cause chaos and damage.Source: §5 · p. 13
• Threats include reduced confidentiality through tracking and identification, reduced integrity through false messages, and reduced availability through denial of service.Source: §5 · pp. 13–14

6 SECURITY ISSUE: PRIVACY PROTECTION

• Privacy protection is required by EU regulations, but privacy measures must not impede safety functions that rely on V2X communications.Source: §6 · p. 14

6.1 Privacy and Vehicle Operation

• Benign vehicles retain others’ certificates for verification, but ETSI leaves stale-certificate deletion and forensic retention unresolved, making privacy exposure implementation-dependent.Source: §6.1 · p. 15

6.2 Applicability of Privacy 1: Vehicle Types and Usages

• ETSI TS 102 941 does not tailor privacy measures to vehicle use or type, although individual, business, and public vehicles may warrant different protection; resale also requires erasing prior-owner data.The paper names unused ATs, navigation history, and paired smartphones, and suggests a simple vehicle-UI process for erasure.Source: §6.2 · pp. 15–16

6.3 Applicability of Privacy 2: Non-Vehicle ITS-S

• ETSI's certificate-management description is vehicle-centric; whether and how RSUs need or manage pseudonyms is unspecified.Source: §6.3 · p. 16

6.4 Privacy and Cooperative Awareness

• CAM position and vehicle attributes can link pseudonyms to vehicles; Escher et al. report tracking up to 80%.Strict one-time pseudonym use still does not ensure unlinkability when multiple vehicles observe and share changes via cloud, and increases pseudonym-management and storage demands.Source: §6.4 · pp. 16–17

6.5 Privacy vs. Road Safety

• In the EEBL scenario, requiring DENM pseudonyms unlinkable from CAM can obscure the source from a vehicle that must brake, so the authors conclude the privacy requirement needs reconsideration.Source: §6.5 · pp. 17–18, Figure 4 · p. 18

6.6 Privacy and Use of Unicast

• In unicast, pseudonym changes expose linkability to the peer and require coordination; link-layer notifications maintain communication but violate endpoint unlinkability.Deferring changes until a session ends can preserve unlinkability and avoid mid-session communication loss, but reliable privacy-preserving unicast needs further consideration.Source: §6.6 · pp. 18–19

7.1 Certificate-Based Message Verification

• Unknown certificate digests or authorities can require a peer certificate request, delaying verification by several hundred milliseconds and leaving real-time message identification open.CAMs include a certificate at least once per second and may use a certificate digest in more frequent messages.Source: §7.1 · p. 19

7.2 Certificate Usage and Change Policy

• EU certificate management issues a set of authorization tickets (ATs) per week, but standards leave each ticket’s duration and the next-ticket selection mechanism unspecified, risking linkability.ATs are expected to change on the order of minutes; sub-optimal use can let adversaries link a certificate to a vehicle.Source: §7.2 · pp. 19–20

7.3 Certificate Reloading

• Certificate reloading is not specifically defined, and relying on roadside units (RSUs) is not universal because RSUs may not be available wherever needed.The survey calls for a workable way for legitimate vehicles to obtain new certificates without depending on an RSU.Source: §7.3 · p. 20
• Preloading three years of certificates can defer reloading but requires more storage and complicates revocation and handling certificates after deregistration or ownership transfer.An alternative is to store certificates for multiple weeks and request the next sets early, allowing retries if a network connection is unavailable.Source: §7.3 · p. 20
• A continuous flow of valid, contextually relevant certificates with memory efficiency remains an open challenge.The multi-week approach avoids end-of-cycle exhaustion without the large storage demands of three-year preloading.Source: §7.3 · p. 20

7.4 Certificate Revocation

• The US SCMS supports active certificate revocation, whereas ETSI ITS relies solely on passive revocation, which blocklists a vehicle when it requests certificate reloading.Active revocation covers misbehaviour handling as well as CRL generation and distribution.Source: §7.4.1 · p. 20, §7.4.2 · pp. 21–22

7.4.1 Active Revocation.

• CRLs must represent a vehicle’s current and future certificates compactly, yet their size remains a concern as the number of revoked vehicles grows.SCMS linkage values reduce revocation information per vehicle, but do not address CRL growth with the vehicle population.Source: §7.4.1 · pp. 20–21
• Vehicles may lack the latest CRL when needed, and standards do not define which revoked-vehicle entries are relevant for a particular vehicle’s routes and encounters.OCSP does not resolve the guaranteed-connectivity problem; missing a relevant revoked certificate can leave a vehicle unaware that it should reject that vehicle’s messages.Source: §7.4.1 · p. 21
• CRL entry removal remains open because entries may be needed to prevent stolen certificates and private keys from being reused, and retention depends on certificate preloading and reloading periods.The survey says IEEE 1609.2 needs to address this question.Source: §7.4.1 · p. 21

7.4.2 Passive Revocation.

• Passive revocation avoids CRL generation and distribution but leaves a gap between revocation and stopped communication; with one week of certificates, the gap can reach seven days.Longer reloading cycles extend the gap proportionally, while three-year preloading is mutually exclusive with passive revocation.Source: §7.4.2 · p. 22

7.5 Certificate Management of RSUs

• ETSI TS 102 940 does not specify whether RSUs need distinct certificate management despite their not strictly requiring pseudonyms for privacy protection.RSUs may still need pseudonyms to be distinguished while maintaining anonymity.Source: §7.5 · p. 22
• Longer-validity RSU pseudonyms could support identification, but would prolong the period in which stolen certificates could enable fake RSUs to send legitimate messages.The survey notes this concern is more pronounced in EU systems that rely solely on passive revocation.Source: §7.5 · p. 22

7.6 Certificate Management of VRUs

• VRU specifications address use cases and architecture, but leave VRU enrollment and VRU-specific certificate provisioning and pseudonym use outside their defined mechanisms.TS 103 300-2 remains at analysis level; TS 103 300-3 limits its security scope.Source: §7.6 · p. 23
• The vehicle-centric certificate system does not yet include VRUs, although smartphone-based VRUs need pseudonym certificates, stronger privacy protection, and a means of revocation.The survey identifies smartphones as a more accessible potential attack surface than vehicle onboard units.Source: §7.6 · p. 23
• A distinct smartphone management system could isolate smartphone-specific needs, but would require interconnection with vehicle and RSU systems and could involve multiple mobile network operators.Subscriber verification and cross-country roaming are among the considerations described.Source: §7.6 · p. 23

7.7 Certificate Usage in Multiple Communications

• Vehicles may communicate with platoon members while separately broadcasting basic service messages to surrounding vehicles, with different targets and purposes.The platoon example uses unicast or multicast alongside broadcast CAMs.Source: §7.7 · pp. 23–24
• Separate pseudonyms for different communication purposes can prevent the broadcast pseudonym from revealing the unicast pseudonym.The survey says this separation is especially relevant because broadcast does not provide confidentiality from observers.Source: §7.7 · p. 24
• GeoNetworking specifications discuss security functions but omit confidentiality for multicast user-plane traffic, while separate unicast pseudonyms could support encryption and remain unspecified.The survey identifies this as an open challenge across GeoNetworking and other key security specifications.Source: §7.7 · p. 24

8.1 Broadcast-Oriented Communication

• CAM and DENM broadcasts lack confidentiality, allowing passive observers to collect messages and detect long-term patterns associated with a pseudonym.Changing pseudonyms makes identifying the transmitting vehicle non-trivial, but does not prevent persistent observers from tracking a pseudonym's presence over time.Source: §8.1 · p. 24

8.2.1 Applicability of Confidential Protection.

• Confidentiality applies only to unicast, a minority of V2X communication; a proposed key-manager scheme therefore has limited applicability.The cited proposal adds symmetric-key encryption but overlooks that basic services use broadcast communication.Source: §8.2.1 · pp. 24–25
• Short-lived encounters can constrain unicast security-association handshakes: a 300-meter range yields 9 seconds with a vehicle moving at 120 km/hour, or 108 seconds at a 10 km/hour relative speed.Whether that interval suffices depends on the use case; IPsec or TLS confidentiality assumes a session between endpoints.Source: §8.2.2 · p. 25

8.2.2 Usability of Unicast Communication.

• Unicast is suitable for some long-range V2N and platooning cases, but other V2V or V2I encounters may end just after security-association setup.The authors recommend that ETSI ITS specifications guide when unicast is usable.Source: §8.2.2 · p. 25

9.1 Plausibility Validation and Misbehavior Detection

• Plausibility validation checks whether a message is reasonably genuine beyond verifying its digital-signature integrity, while misbehavior detection evaluates plausibility failures over time.The paper describes plausibility validation as a countermeasure against bogus or faulty messages and cautions that a single failure is unlikely to establish misbehavior.Source: §9.1 · p. 25, §9.1.1 · p. 26, §9.1.2 · p. 26

9.1.1 Determination of Plausibility.

• ETSI's plausibility definitions are too abstract for consistent criteria, although checks must be timely and confident enough for time-critical messages such as DENM.The authors propose a common minimum set of scenarios and expected judgments, allowing OEMs to add scenarios beyond that baseline.Source: §9.1.1 · p. 26

9.1.2 Misbehavior Detection.

• Misbehavior detection spans behavioral, trust-based, plausibility, and consistency categories, but collaborative models need enough nearby vehicles and data and assume an honest majority.A small proportion of malicious vehicles or faulty sensors can skew collaborative decisions.Source: §9.1.2 · p. 27
• Autonomous detection relies only on in-vehicle data, so combining categories may be needed across situations; the authors recommend a common approach or test set for comparison.A vehicle may decide differently if other vehicles possess information unavailable locally.Source: §9.1.2 · p. 27

9.2 Communication involving Vulnerable Road Users

• VRU messages need to represent transitions such as pedestrian-to-cyclist movement, which the specification's informative annex describes as nontrivial and requiring further research and standardization.VAM communicates VRU position and movement with vehicles or other VRUs.Source: §9.2 · p. 27

10.1 ITS-S Device-Dependent Trust Level

• Distinguishing RSUs from vehicles by device type could support different trust levels without compromising anonymity, and RSU-originated authoritative information may aid misbehavior detection.The authors note that the content definition for SubjectAssurance, which could fit this purpose, is outside IEEE 1609.2's scope; compromised RSUs could abuse elevated trust.Source: §10.1 · p. 28

10.2 Interconnection between Multiple Security Management Systems

• Cross-border misbehavior handling requires management systems to coordinate: Country B must notify the vehicle's issuing system in Country A, which can revoke certificates and report back.For active revocation, Country B's system also needs notification to distribute the resulting CRL to vehicles in its territory; ETSI ITS specifications do not cover these interactions.Source: §10.2 · pp. 28–29, Figure 5 · p. 29

10.3 Multiple Security Management Systems for Different ITS-S Types

• ETSI TS 102 940 does not clearly specify management of different ITS-S types, including government-managed RSUs and consumer-owned smartphones used in V2P.The authors call for appropriate specification of smartphone management as legitimate ITS system membership.Source: §10.3 · p. 29

10.4 Absence of Consideration on Post-Quantum Cryptography Technologies

• Long vehicle lifetimes make a migration strategy to post-quantum certificates relevant, but secure updates or hardware replacements during that lifetime remain a challenge.The paper identifies migration as uncharted territory involving both vehicles and underlying infrastructure.Source: §10.4 · pp. 29–30
• A code-based quantum-resistant signature example increases public-key and signature size from 0.1KB to 190KB, making five years of preloaded certificates impractical or impossible.The authors say this would shift reliance toward on-demand authorization-ticket reloading.Source: §10.4 · p. 30

Root cause 1: Conflicting or Insufficient Specification

• Conflicting or insufficient specifications can leave security aspects inconsistent or to implementation choice; the authors recommend baseline test cases, data, and decision criteria.They also identify broader needs to resolve privacy, anonymity, and safety conflicts and clarify interworking among management systems.Source: §11 · pp. 30, 32

Root cause 2: Characteristics of Vehicular Communication Environment

• Dynamic topology and short-range links can disrupt longer direct communications, so the authors recommend realistic broadcast and unicast expectations and clearer pseudonym-use guidance.Peer-to-peer networking is also proposed as a potential avenue for greater fault tolerance, alongside direct sensor perception for autonomous-vehicle safety.Source: §11 · pp. 31–32

Root cause 3: Broadcast Based Communication

• Broadcast CAM and DENM are receivable by any entity and lack confidentiality, leaving eavesdropping possible; the authors recommend exploring broadcast confidentiality or pseudonymity alternatives.The paper also points to efficient credential and trust management at scale.Source: §11 · p. 32

Root cause 4: Implementation-Dependent Ambiguity

• Implementation-dependent choices can produce differing real-world effectiveness, so uncovered choices should be documented with their possible consequences.The authors note that specifying every aspect may not be realistic.Source: §11 · p. 32

Root cause 5: Certificate Usage and Management for Vehicles

• Vehicle pseudonym-certificate usage, change rules, and reloading are insufficiently defined; recommendations include clarifying these rules and investigating HSM or TEE support for scalable trust management.The paper also calls for efficient cryptographic credential management at scale.Source: §11 · pp. 32–33

Root cause 6: Certificate Management of Non-Vehicle ITS-S Types

• RSU pseudonym use and smartphone ITS-S management remain unspecified, so the authors recommend defining management, enrollment, authorization, certificate, and revocation practices for these device types.Smartphones are consumer-owned generic platforms rather than dedicated-purpose OBUs or RSUs.Source: §11 · p. 33

Root cause 7: RSU Infrastructure Dependency

• Because RSU availability depends on gradual, region-specific deployment and is not guaranteed, the authors recommend alternatives that work without ubiquitous RSUs.The proposed approach would still use RSUs when available.Source: §11 · p. 33

Root cause 8: MNO Involvement and Dependency

• ETSI does not specify whether ITS management systems and mobile network operators must coordinate over VRU smartphone access; the authors recommend defining whether interaction is needed and its message contents.They identify coordination with standards bodies such as 3GPP.Source: §11 · p. 33

12 CONCLUSION AND FUTURE WORK

• The paper integrates EU and US ITS standards, V2X-related EU projects, and research papers to identify security gaps, with a focus on ETSI ITS specifications.Source: §12 · p. 33
• Unresolved gaps can make real-world vehicular communication unreliable, insecure, or unusable, potentially leading to accidents, injuries, or property loss.The authors also warn that implementation-specific solutions can vary in effectiveness.Source: §12 · pp. 33–34
• Table 6 lists recommended actions for ETSI ITS specifications.Source: Table 6 · p. 34
• The authors conclude that ITS security solutions based solely on PKI leave areas to reconsider and require additional approaches to secure vehicular communication.They connect this need to the cyber-physical risk of physical damage from a sub-optimal system.Source: §12 · p. 34