Formal Analysis of C-ITS PKI Protocols

Mounira Msahli

1 a

, Pascal Lafourcade

2 b

and Dhekra Mahmoud

Universit

e Clermont Auvergne, CNRS, LIMOS, F-63000 Clermont, France

ecom Paris, LTCI, IP Paris, France

Keywords:

C-ITS Protocols, Formal Veriﬁcation, Authentication, Privacy, Security, ProVerif.

Abstract:

Vehicular networking is gaining a lot of popularity and attraction from among the industry and academic

research communities in the last decade. The communication between vehicles will lead to more efﬁcient and

secured roads because we will be able to provide information about trafﬁc and road conditions to vehicle’s

drivers. However, ensuring the security of these networks and devices still remains a main major concern

to guarantee the expected services. Secure Public Key Infrastructure (PKI) represents a common solution

to achieve many security and privacy requirements. Unfortunately, current Cooperative Intelligent Transport

Systems (C-ITS) PKI protocols were not veriﬁed in terms of security and privacy. In this paper, we propose a

security analysis of C-ITS PKI protocols in the symbolic model using ProVerif. We formally modeled C-ITS

PKI protocols based on the speciﬁcations given in the ETSI standard. We model C-ITS PKI protocols and

formalize their security properties in the applied Pi-calculus. We used an automatic privacy veriﬁer UKano to

analyse Enrolment protocol. We found attacks on authentication properties, in Authorization and Validation

protocols when considering a dishonest Authorization Authority (AA). We analysed proof results and we ﬁxed

identiﬁed attacks by introducing new parameters in protocol request.

1 INTRODUCTION

Connected vehicles are considered as a dynamic mo-

bile communication system allowing gathering, shar-

ing, processing, computing, and secure exchange

of information between vehicles and infrastructure.

These connected vehicles enable the evolution to next

generation Intelligent Transportation Systems(ITSs)

(Lamssaggad et al., 2021) (Severino et al., 2023). In

(Contreras-Castillo et al., 2017), the authors give an-

other deﬁnition of IoV; it is a platform that enables

the exchange of information between the car and its

surroundings through different communication me-

dia. Therefore, IoV is viewed as a wide area of vehic-

ular network offering connectivity to a large number

of online services and components. This concept ex-

tends the communication spaces of Infrastructure to

Vehicles (I2V). It emphasis the interaction among ve-

hicles and its network infrastructure. Connected road

users have to exchange data on their positions, status,

speed, driving directions and the required information

to enable them to interact and to coordinate their be-

havior accordingly and safely. In complex trafﬁc sit-

https://orcid.org/0000-0003-0331-493X

https://orcid.org/0000-0002-4459-511X

uations, for example, exchanged data facilitates vehi-

cle navigation, reduces wait time and avoids delays.

Many papers have discussed the security of C-ITS

and have presented attacks using vulnerabilities de-

tected, or likely to happen, in the C-ITS system. Ex-

amples of these attacks include the Sybil Attack, Lo-

cation tracking attack, False message injection, Re-

play attack, Jamming attack and Trafﬁc analysis at-

tack (Lamssaggad et al., 2021) (Zhang et al., 2014)

(Lu et al., 2019) (Szegedy et al., 2013). Accessing

certain ITS services requires the use of PKI based au-

thentication solution(Haidar et al., 2017). Main se-

curity standards did not address a complete detailed

secure end-to-end mechanism to send requests to the

PKI and receive the associated responses (Monteu-

uis et al., 2017). But, in literature, we could ﬁnd

several research works dealing with credential man-

agement for vehicular network. For example, the au-

thors of (Simplicio et al., 2018) give an improved key

management solution using butterﬂy key expansion

process. Recently, the European Telecommunication

Standards Institute (ETSI) has standardized technical

speciﬁcations and all requirements of communication

protocol within the C-ITS PKI in the ETSI TS 102

941 standard (ETSI, ).

198

Msahli, M., Lafourcade, P. and Mahmoud, D.

Formal Analysis of C-ITS PKI Protocols.

DOI: 10.5220/0012766100003767

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 21st International Conference on Security and Cryptography (SECRYPT 2024), pages 198-210

ISBN: 978-989-758-709-2; ISSN: 2184-7711

The C-ITS Trust Model (Lone et al., 2022) as de-

ﬁned in Certiﬁcate Policy for Deployment and Oper-

ation of European Cooperative Intelligent Transport

Systems (C-ITS) (Platform, 2018) is based on a mul-

tiple root CAs architecture, where the root CA cer-

tiﬁcates are transmitted periodically to the Trust List

Manager (TLM). The TLM issues the European Cer-

tiﬁcate Trust List that provides trust in the approved

root CAs to all PKI participants. This Trust Model in-

sures interoperability among several vehicular PKIs.

The main inconvenience drawback of this Trust

Model is its centralization. The TLM shall retrieves

RCAs from different PKIs to put it in one Certiﬁcate

Trut List (CTL). Then to distribute the CTL periodi-

cally and regularly to all concerned relevant PKIs.

One home C-ITS PKI is composed of three au-

thorities:

• Root Certiﬁcation Authority (Root CA), is the

highest level certiﬁcation authority in the certiﬁ-

cation hierarchy. It is used to sign certiﬁcates for

subordinate authorities (EA and AA).

• Enrolment Authority (EA), is responsible for the

life cycle management of Enrolment Certiﬁcates

(EC), which are long-term certiﬁcates used for the

authentication of C-ITS stations to Authorisation

Authority. EA has the duty to verify the canonical

ID of the station sending a request.

• Authorization Authority (AA), is responsible for

issuing and monitoring the use of Authorization

Tickets (AT), which are short-lived anonymized

certiﬁcates used by the corresponding C-ITS sta-

tion to access permitted ITS services.

As mentioned in Figure 1, the ETSI TS 102 941

standard aims to specify a Public Key Infrastructure

protocol for Intelligent Transport System. The pro-

tocol has made one of its requirement to provide pri-

vacy to stations (mostly vehicles). According to the

standard, privacy is provided in two dimensions (rel-

atively to other stations, but also relatively to authori-

ties themselves).

Ultimately, the sectioning into three authorities is

meant to provide privacy to the stations. The enrol-

ment authority does not know the key the station is

going to use to sign messages on the network, and

therefore can’t track its activity. The authorization au-

thority shouldn’t be able to link AT request between

them, i.e., it doesn’t know if a request comes from a

previously known station, or a new one. Therefore, an

authorization authority trying to track the activity of a

station should be lost as soon as the station renew its

AT (or uses multiple AT simultaneously).

The different C-ITS PKI communications (re-

quests/responses) are ruled by speciﬁc protocols,

C-ITS station

EA AA

RCA

Enrolment Validation

Enrolment Veriﬁcation

AT Request

AT Response

EC Request

EC Response

Certiﬁcate Certiﬁcate

Secure

Communication

Figure 1: C-ITS PKI architecture.

which are referred as C-ITS PKI protocols (Salin

and Lundgren, 2023). This protocol is already im-

plemented and used in European C-ITS system and

needs a formal validation in order to avoid signiﬁ-

cant security and privacy concerns (Yoshizawa et al.,

2023) (Chi et al., 2023). In this paper, we aim

to verify the resistance of this protocol to passive

and active (security and privacy) attacks using for-

mal veriﬁcation tools like AVISPA (Armando et al.,

2005), ProVerif (Blanchet, 2016), Scyther (Basin

et al., 2018) and Tamarin (Meier et al., 2013).

For the rest of this work, we choose the proto-

col veriﬁer ProVerif (Barbosa et al., 2021) (Blanchet,

2014) and Ukano (Hirschi et al., 2019a), the auto-

matic privacy veriﬁer, as formal veriﬁcation tools. In

fact, ProVerif takes as input a protocol description in

the applied Pi-Calculus, which is translated to a set

of Horn clauses. ProVerif is fully automatic: the user

only gives the speciﬁcation of the protocol and the

property to verify.

Contribution. In this paper, we present a new for-

malization for the C-ITS PKI protocols. We model

C-ITS PKI protocol abstractly as three-party. When

a C-ITS station requests an AT, the protocol involves

two separate authorities. To the best of our knowl-

edge, we present the ﬁrst formalization of several se-

curity properties for C-ITS PKI protocol. We catego-

rize it into two main classes: (a) Authentication prop-

erties, including Request Origin Authentication, Re-

quest Authorship, and Response Authenticity, (b) Pri-

vacy properties and pseudonym indistinguishability.

We develop our formal framework in the applied Pi-

calculus wherein we propose a model for the C-ITS

PKI’s protocol and deﬁne all our properties. We val-

idate our approach by analyzing: 1) Enrolment pro-

tocol, 2) Authorization protocol, and 3) Validation

protocol. We model all exchanges in the applied Pi-

Formal Analysis of C-ITS PKI Protocols

199

calculus for veriﬁcation using ProVerif. Our security

analysis reveals several weaknesses in the second and

the third protocols when dishonest parties collaborate

with the attacker. We propose simple ﬁxes to over-

come those weaknesses.

The road-map of the paper is as follows: in Sec-

tion 2, we give the related work. In Section 4, we

model C-ITS PKI protocols and its security properties

using the applied Pi-calculus. We verify symbolically

the security and the privacy of three C-ITS PKI pro-

tocols and we discuss our results in Section 5 and 6.

The conclusion is provided in Section 8.

Table 1: Notation Table.

Notation Deﬁnition

EA Enrolment Authority

idEA Enrolment Authority’s identiﬁer

pkEA EA’s public key

AA Authorization Authority

idAA Authorization Authority’s identiﬁer

pkAA AA’s public key

AT Authorization Ticket

EC Enrolment Credential

S ITS Station

idS Station’s identity

skS Station’s secret key

pkS Station’s public key

pkS

Public key of Station S

sskS Station’s private key used to sign

spkS Public key corresponding to private key sskS

k Symmetric key

n Nonce

pkV Station’s public key appearing on AT

skV Secret key corresponding to pkV

As Authority receiving certiﬁcate request

Aa Authority contacted by As

req

Identiﬁer of a request

res

Identiﬁer of a response

CP CITS PKI protocol instance

T LM Trust List Manager

CT L Certiﬁcate Trust List

CRL Certiﬁcate Revocation List

2 RELATED WORK

All C-ITS communications: Vehicle to Vehicle or Ve-

hicle to Infrastructure or Vehicle to Everything could

be a source of attack. In literature, several V2X pro-

tocols were veriﬁed using formal security tools. Boj-

jagani et al have designed a new IoV secure paradigm

called AKAP IoV. The new scheme gives a mutual au-

thentication, and key management among all VANET

actors. The security level of AKAP-IoV was formally

veriﬁed with Scyther and Tamarin tools(Bojjagani

et al., 2022).Sutrala et al in(Sutrala et al., 2020) have

designed a new conditional privacy preserving batch

veriﬁcation-based authentication in IoV. The security

of proposed scheme were veriﬁed against a passive

and active adversary through various security analy-

sis.

Yashar and Vahid have proposed a security analy-

sis of Secure Mutual Authentication Scheme and Key

Exchange Protocol in Fog (SMAK-IoV). The authors

used the Automated Validation of Internet Security

Protocols and Applications (AVISPA) tool to verify

its security. The results show that SMAK-IoV is re-

sistant to active and passive attacks.(Salami and Kha-

jehvand, 2020).

(Yu et al., 2020) have demonstrated with formal

validation tool that the proposed IoV-SMAP protocol

can resist to security attacks and provides anonymity,

and authentication.

In this paper, the main approach for protocol ver-

iﬁcation that we have adopted in our work is the

symbolic model. Thanks to Needham and Shroeder

(Needham and Schroeder, 1978) and Dolev and Yao

(Dolev and Yao, 1983) (Lafourcade et al., 2009),

cryptographic primitives are represented by function

symbols and considered black boxes, messages are

terms on these primitives, and the adversary is re-

stricted to computing using only these primitives

(Blanchet, 2014).

Verifying Protocols Symbolically. There exist nu-

merous methodologies to formally verify protocols.

Our work makes use of a particular modeling tech-

nique called ”symbolic model” (Blanchet, 2014) that

abstracts messages (including keys, nonces...) as

terms and cryptographic primitives as black-box func-

tions. Functions are related to each other through an

equational theory, for example an encryption func-

tion enc and a decryption function dec could be re-

lated through the equation dec(enc(m, k), k) = m with

k being a key and m a message. The attacker is

able to intercept, modify and apply any functions to

build terms using the equational theory, then send it

to participants. In short, the network is the attacker.

This model is commonly referred to as the Dolev-Yao

model (Dolev and Yao, 1983). One of the tool devel-

oped to automate the study of protocols in the sym-

bolic model is ProVerif (Blanchet, 2016) (Lafourcade

and Puys, 2015). It takes as input a protocol mod-

eled using a variant of pi-calculus, and is then able to

search for attacks that break expected properties on it.

Unlinkability. One of the privacy feature that the

protocol under study claims to offer is privacy through

unlinkability (Baelde et al., 2020a) (Comon and Kout-

sos, 2017) (Baelde et al., 2020b) (Hirschi et al.,

2019b) . There exists numerous possible formals def-

SECRYPT 2024 - 21st International Conference on Security and Cryptography

200

initions for unlinkability. Here, we are going to use

the deﬁnition proposed in (Hirschi and et al, 2016),

since it ﬁts quite well the expectations of our protocol.

In our context, this deﬁnition means that an attacker

should not be able to distinguish a situation where a

station makes several requests to the PKI, and a sit-

uation where several stations make a single request.

If this property is respected, we can easily conclude

that an attacker cannot link messages coming from the

same origin. In our case, we will use the main contri-

bution introduced in (Hirschi and et al, 2016), a the-

orem that allows us to prove unlinkability by proving

easier properties: if a protocol respects frame opacity

and well-authentication.

Frame Opacity. Roughly means that there is no

relations visible to the attacker between messages;

they are indistinguishable to randomness, and well-

authentication means that any attempt by an attacker

to tamper with the messages in order to leak infor-

mation behind a conditional (say an authenticity test)

should fail.

3 THREAT MODEL

In this section, we consider the critical threats of our

considered assumptions. Using the Dolev–Yao threat

model, source and destination entities can exchange

messages via exposed and insecure communication

channel which is the internet. In our context, we

consider the semi-honest malicious adversary threat

model. Vehicles or C-ITS stations and PKI author-

ities are not considered as trusted entities. We con-

sider that all entities will follow the speciﬁed proto-

col in the real world as indicated in the ETSI stan-

dard[9], which implies that data structure of sent or

received messages will not be changed. In our case,

we consider that the adversary is able to eavesdrop,

modify, replay, inject, or delete messages. The ad-

versary could be a vehicle that replay requests or Au-

thorisation authority that generate a response without

the authorization validation. Here, the adversary can

attempt ”impersonation attacks” and ”replay attacks”.

4 MODELING C-ITS PKI

PROTOCOLS

4.1 Model

In this section, we model C-ITS PKI protocols in

the applied Pi-calculus (Abadi et al., 2017). To per-

As Aa

......... ......... .........

request

validation

Aa’s response

response

Authority

Figure 2: C-ITS PKI Protocols.

form the automatic protocol veriﬁcation (Avalle et al.,

2014), we use ProVerif (Blanchet, 2016) tool. Hon-

est parties are modeled as processes in the applied

Pi-calculus. They can exchange messages on public

or private channels, create keys or fresh random val-

ues and perform tests and cryptographic operations,

which are modeled as functions on terms with respect

to an equational theory describing their properties.

The attacker has total control of the network

(Dolev and Yao, 1983); messages may be read, mod-

iﬁed, deleted or injected. Under the assumption of

perfect cryptography, the attacker is only able to per-

form cryptographic operations when he is in posses-

sion of the right keys. C-ITS PKI protocol speciﬁes

the processes executed by a station S requesting a cer-

tiﬁcate to certiﬁcation authorities As or Aa. We do not

make assumptions about which authority issues the

requested certiﬁcate. We only specify which author-

ity is being contacted by the station. We suppose that

As is the authority contacted by the station and thus

receiving the certiﬁcate request. Aa is the authority

contacted by As for either a validation of the certiﬁ-

cate request or for simply issuing it.

Deﬁnition 4.1 (C-ITS PKI protocol). A C-ITS PKI

protocol is a tuple (S, As,Aa) where S is the process

executed by the station; As is the process executed by

the authority contacted by the station and Aa is the

process executed by the authority contacted by As.

Deﬁnition 4.2 (C-ITS PKI instance). In C-ITS PKI

protocol, a C-ITS PKI instance is a closed process

CP = ν ˜n · (Sσ

idS

pkS

|As|Aa), where ˜n is the set of

all restricted names; Sσ

idS

pkS

is the process run by

the station, the substitutions σ

idS

and σ

pkS

specify the

identity and the key to be certiﬁed respectively, and

As (resp. Aa) is the process run by the certiﬁcation

authority As (resp. Aa).

Formal Analysis of C-ITS PKI Protocols

201

4.2 Security Properties

The ETSI TS 102 941 standard introduces a major

security requirement for C-ITS stations which is Pri-

vacy. The standard states that a C-ITS PKI pro-

tocol guarantees a C-ITS station’s privacy when its

pseudonym (or the short term certiﬁcate) could not be

linked to its real identity. The architecture of the PKI

actually separates the authorities involved in issuing

pseudonym certiﬁcates (one for verifying ownership

of an EC and the other for issuing certiﬁcates) to pro-

vide needed privacy for a C-ITS station. Neither EA

nor AA should be able to link a pseudonym certiﬁcate

to a user’s real identity and neither EA nor AA should

be able to link two (or more) pseudonym certiﬁcates

to the same user.

To formalize the security properties required by

C-ITS PKI protocols, we introduce a privacy prop-

erty meant to prevent authorities or a third party from

linking a station’s pseudonym to its identity. We

also introduce three authentication properties meant

to ensure the association of the station’s identity to its

pseudonym.

Authentication. In the following, idS is the station

identity, pkS is the station’s key to be certiﬁed, id

req

is an identiﬁer of the certiﬁcate request generated by

the station and id

res

is an identiﬁer of the certiﬁcate re-

sponse received by the station. Let set

= {idS, pkS},

p1 ∈ set

and p2 ∈ set

\ p1. We deﬁne the following

events:

• req(p

, p

, id

req

) is the event inserted into the S

process at the location where a station S generates

a certiﬁcate request id

req

• f or(p

, id

req

) is the event inserted into the As pro-

cess at the location where As receives, accepts,

and generates the corresponding request for Aa.

• val(p

, id

req

, id

res

) is the event inserted into the Aa

process where Aa receives and accepts the request

coming from As.

• res(p

, p

, id

req

, id

res

) is the event inserted into the

S process where a station receives and accepts a

certiﬁcate response.

Events have the following structure ”on every

trace, the event e

is preceded by the event e

”. Here,

the authentication concerns the source of the certiﬁ-

cate request.

Deﬁnition 4.3 (Request Origin Authentication).

The C-ITS PKI protocol ensures Request Origin

Authentication if each occurrence of the event

val(p

, id

req

, id

res

) is preceded by an occurrence of

the event f or(p

, id

req

) and req(p

, p

, id

req

Deﬁnition 4.4 (Request Authorship). a C-ITS PKI

protocol ensures Request Authorship if each event

val(p

, id

req

, id

res

) is preceded by a distinct occur-

rence of the event req(p

, p

, id

req

Our third property concerns the authenticity of a

certiﬁcate response. Since As needs to contact Aa

before responding to the station, this property en-

sures that whenever a station receives a certiﬁcate re-

sponse, As has already contacted Aa and that Aa has

responded.

Deﬁnition 4.5 (Response Authenticity). A C − IT S

PKI protocol ensures Response Authenticity if for

every occurrence of the event res(p

, p

, id

req

, id

res

)

there is an earlier distinct occurrence of the event

val(p

, id

req

, id

res

Privacy We model privacy property as observa-

tional equivalence (Blanchet, 2016). We use the

labelled bisimilarity to express the equivalence be-

tween two processes. Informally, two processes are

equivalent when an observer can not distinguish them

apart.Let CP

[ ] be the process CP without S. Our pri-

vacy property concerns the Indistinguishability of the

pseudonyms requested by the same station.

Deﬁnition 4.6 (Pseudonym Indistinguishability). A

C − IT S PKI protocol ensures pseudonym indistin-

guishability if, for any C-ITS PKI process CP, any

station with identity idS and any two pseudonyms

pkS

and pkS

, we have:

[Sσ

idS

pkS

] ≈

[Sσ

idS

pkS

]

This property states that two processes with two

different

pseudonyms executed by the same station have to be

observationally equivalent until the end of the proto-

col. This property requires that the authority knows

idS to be honest. Otherwise, the property is trivially

violated when the authority reveals the station’s iden-

tity to the attacker.

4.3 Equational Theory

To capture the behaviour of the cryptographic primi-

tives, we use the following equational theory:

sdec(senc(x, y, z), y, z) = x (1)

adec(aenc(x, pk(y)), y) = x (2)

checksign(sign(x, y), pk(y)) = x (3)

checkhash(x, hash(x)) = true (4)

checkhmac(hmac(x, y), x, y) = true (5)

SECRYPT 2024 - 21st International Conference on Security and Cryptography

202

Equation (1) states that a message encrypted with

a symmetric key and another encryption parameter

can only be decrypted using those same parame-

ters. This equation is used to abstractly model the

AES −CCM encryption scheme in our case. The sec-

ond equation 2 states that a message x encrypted with

a public key can be decrypted using the corresponding

secret key. Equation 3 models the veriﬁcation of a sig-

nature using the corresponding public key. Equation

(4) models the veriﬁcation of a hashed value. Since

we model a hash function as a one way function, one

needs to know the message and the hashed value of

the message to check the integrity of message. Equa-

tion (5) is about the veriﬁcation of hmac.

5 ENROLMENT PROTOCOL:

SECURITY ANALYSIS

Enrolment protocol aims at authenticating and en-

rolling a station by issuing an EC to be used during

the authorization phase. It is presented as a two-party

protocol involving a C-ITS station requesting an EC

and an enrolment authority responding by delivering

or not the requested EC.

5.1 Description

S EA

......................

← {{⟨id

, spk

⟩}

ssk

}

← ⟨id

, {x

}

⟨k,n⟩

, {k}

, n⟩

← {⟨h(x

), RC, cert⟩}

← ⟨n

′

, {y

}

⟨k,n

′

⟩

Figure 3: Enrolment Protocol.

Enrolment Request. To create an enrolment re-

quest, the C-ITS station begins by creating an In-

nerECRequest containing its canonical identiﬁer idS,

its veriﬁcation public key spkS to be included in the

certiﬁcate, the certiﬁcate format and the requested

subject attributes. Then, a signed data structure is

formed by signing the InnerECRequest with the pri-

vate key sskS corresponding to the veriﬁcation public

key spkS for a proof of possession. Another signed

data structure x

is created by re-signing the indi-

cated structure with the canonical private key skS.

Finally, the C-ITS station encrypts its signed data

with AES −CCM using a freshly generated symmet-

ric key k and a nonce n. The station sends its en-

crypted and signed enrolment request along with the

encrypted symmetric key (encrypted with EA’s public

key), the used nonce and EA’s public certiﬁcate iden-

tiﬁer idEAv (see Fig.3).

Enrolment Response. When EA receives an enrol-

ment request, it begins by deciphering the encrypted

symmetric key k. Then, it decrypts the encrypted data

structure, checks the signatures performed by the C-

ITS station after verifying its identity and retrieves the

veriﬁcation public key spkS. If the veriﬁcation suc-

ceeds, EA creates an Enrolment Credential cert and

sets to 0 its response code RC, which corresponds to

a positive response. EA creates an InnerECResponse

containing the request hash, a response code and a

certiﬁcate (in case of a positive response). Then, a

signed data is generated by signing the InnerECRe-

sponse with the private key skEA. The data is ﬁnally

encrypted with AES −CCM using the same symmet-

ric key k used to encrypt the request and a freshly

generated nonce n

′

(see Fig. 3).

5.2 Model in the Applied Pi-Calculus

We expressed the behaviour of the participants using

the processes depicted in Figures 4 and 5.

1: (* private keys and identiﬁers *)

2: ν idS · ν skS · ν idEA · ν skEA·

3: (* public keys *)

4: let pkEA = pk(skEA) in let pkS = pk(skS) in

5: (* public key disclosure *)

6: out(c, pkEA)·

7: (* Station process — Enrolment Authority pro-

cess *)

8: ( !ν sskS · P

| !P

)

Figure 4: The main process.

5.3 Analysis

In addition to ProVerif, we have used the auto-

matic privacy veriﬁer UKano (Hirschi et al., 2019a)

which checks the unlinkability and the anonymity

of two-party protocols by verifying two properties

namely Frame-Opacity and Well-Authentication.

Informally, Frame-Opacity requires that in any

Formal Analysis of C-ITS PKI Protocols

203

1: let InnerECRequest = (idS, pk(sskS)) in

2: let x

= sign(sign(InnerECRequest, sskS), skS)

3: ν k.ν n.

4: let x

= senc(x

, k, n) in

5: let x

= aenc(k, pkEA) in

6: out(c, (idEA, x

, x

, n)).

7: in(c, (x

, x

))

8: let (x

, x

) =

checksign(sdec(x

, k, x

), pkEA) in

9: if checkhash((idEA, x

, x

, n), x

) = true then

10: if x

= true then

11: if checksign(x

, pkEA) = pk(sskS) then 0

1: in(c, (y

, y

, y3)).

2: if y

= idEA then

3: let k = adec(y

, skEA) in

4: let y

= sdec(y

, k, y

) in

5: let (= idS, spkS) = getmess(getmess(y4)) in

6: if checksign(checksign(y

, pkS), spkS) = (idS,

spkS) then

7: let InnerECResponse =

(hash((idEA, y

, y

)),

true,sign(spkS, skEA)) in

8: νn.

9: out(c, (senc(sign(InnerECResponse, skEA),

k, n), n)

Figure 5: Station and Enrolment Authority processes.

execution of the protocol, the attacker should not be

able to distinguish the outputs from pure randomness.

Well-Authentication prevents the attacker from

obtaining valid information through the outcome

of any conditionals. Hirschi et al. demonstrated

that Frame-Opacity and Well-Authentication imply

unlinkability and anonymity (Hirschi et al., 2019a).

We present the results of our analysis of Enrol-

ment protocol’s security properties in Table 2.

Table 2: Results of authentication and privacy properties’

analysis.

Property Result Time

Request Authorship ✓ < 1 s

Response Authenticity ✓ < 1 s

Pseudonym Indistinguishability ✓ < 1 s

Well-Authentication ✓ < 1 s

Frame Opacity × < 1 s

Authentication. Since Enrolment protocol involves

only a single authority, we do not need to check Re-

quest Origin Authentication property. Instead, we

only check Request Authorship and Response Au-

thenticity properties. In fact, when Request Author-

ship holds, Request Origin Authentication is trivially

veriﬁed.

Privacy. Since Enrolment Authority knows both the

identity of the station and the certiﬁed key, we do not

need to check pseudonym indistinguishability with

regard to Enrolment Authority. We only check this

property with regard to an external attacker and we

found that it is veriﬁed. Moreover, we used the auto-

matic privacy veriﬁer UKano which checks automat-

ically unlinkability and anonymity of both the station

and Enrolment Authority by checking Frame-Opacity

and Well-Authentication. We found that Enrolment

protocol fails when checking Frame Opacity. In fact,

the identity of EA is sent in plain text in the enrolment

request and since UKano checks the anonymity and

the unlinkability of both the sender and the receiver,

it is obvious that Enrolment protocol does not guaran-

tee the privacy of EA. We do not consider this as an

attack because the standard does not claim to preserve

anonymity nor unlinkability of EA. However, since

every C-ITS station is associated to a single EA, an

attacker would collect data about stations belonging

to the same manufacturer and this may reveal some

information about the stations’ identity or private in-

formation.

6 AUTHORIZATION-

VALIDATION PROTOCOL:

SECURITY ANALYSIS

The Authorization-Validation protocol is presented in

two steps in the ETSI standard (see ﬁgure 6). Firstly,

the C-ITS station requests an AT from the authority

AA, which could responds positively if the station is

eligible to get the requested certiﬁcate or with a nega-

tive response if not. The validation protocol involves

two authorities AA and EA. AA requests the valida-

tion of EA to deliver or not the requested certiﬁcate

by the station. EA responds positively if the author-

ity is able to authenticate the station and if the station

is permitted to get access to the requested services.

Otherwise, it responds negatively.

We have modeled this protocols as one single

three-party protocol, i.e., the response of AA in the

Authorization protocol depends on the response of

EA in the Validation protocol.

SECRYPT 2024 - 21st International Conference on Security and Cryptography

204

S AA EA

........... ........... ...........

KeyTag ← hmac(pkV, hkey)

← {{h(⟨id

, KeyTag⟩)}

sskS

}

⟨k

⟩

ecSignature ← ⟨n

, {k

}

, x

⟩

← {⟨pkV, hkey, ⟨id

, KeyTag⟩, ecSignature⟩}

⟨k

⟩

← ⟨n

, {k

}

, x

⟩

← {⟨ecSignature, ⟨id

, KeyTag⟩⟩}

← ⟨n

, {k

}

, y

⟩

z ← ⟨n

, {{⟨h(y

), RC⟩}

}

⟨k

⟩

← ⟨n

, {{⟨h(x

), RC, AT⟩}

}

⟨k

⟩

Figure 6: Authorization Protocol.

6.1 Description

AV P

1: (* private keys *)

2: ν sskS · ν skAA ·ν skEA·

3: (* public keys *)

4: let spkS = pk(sskS) in let pkAA =

5: pk(skAA) in let pkEA = pk(skEA) in

6: (* public keys disclosure *)

7: out(c, pkAA) · out(c, pkEA)·

8: (* Station — Authorization Authority — En-

rolment Authority *)

9: (!νskV · P

| ! P

)

Figure 7: The main process.

Authorization-Validation protocol aims at authorizing

an enrolled station to use services privately over the

network to obtain an AT. We describe it as a three-

party protocol involving a C-ITS station, an Autho-

rization Authority and an Enrolment Authority. In

short, the C-ITS station sends an AT request to AA

which checks the validity of the request and then

sends a validation request to EA. EA authenticates

the station and sends its response to AA. The AA re-

sponds to the station accordingly.

Table 3: Results of security properties’ analysis. Property*

is the property checked with dishonest Authorization Au-

thority.

Property Result Time

Request Origin Authentication ✓ < 1 s

Request Authorship × < 1 s

Response Authenticity ✓ < 1 s

Request Origin Authentication* × < 1 s

Request Authorship* × < 1 s

Response Authenticity* × < 1s

Pseudonym Indistinguishability ✓ < 1 s

Authorization Request. To create an authorization

request, the C-ITS station should ﬁrst generate a key

pair (skV, pkV) such that pkV is to be provided to the

AA included in the AT. It should also generate a ran-

dom key hmac − key to calculate a tag on pkV using

an hmac function. We refer to this tag as KeyTag.

Next, the station creates a SharedATRequest struc-

ture containing idEA identifying the EA to be con-

tacted for validation, the KeyTag, the certiﬁcate for-

mat, and the requested subject attributes. Then, the

station signs the hash of the SharedATRequest with

its private enrolled key sskS and creates an encrypted

data structure using AES − CCM and the EA public

Formal Analysis of C-ITS PKI Protocols

205

1: let pkV = pk(skV) in

2: νhkey.

3: let KeyTag = hmac(pkV, hkey) in

4: let x

= (idEA, KeyTag) in

5: let x

= sign(hash(x

), sskS) in

6: νk

.νn

7: let ecSignature =

(senc(x

, k

, n

), aenc(k

, pkEA), n

) in

8: let AT Request = (pkV, hkey, x

, ecSignature)

9: νk

.νn

10: let k

= aenc(k

, pkAA) in

11: let AuthorizationReq =

(idAA, senc(AT Request, k

, n

), k

, n

)

12: out(c, AuthorizationReq)·

13: in(c, (x

, x

))

14: let (hr, res, AT ) = checksign(sdec(x

, k

, x

pkAA) in

15: if checkhash(AuthorizationReq, hr) = true

then

16: if res = true then

17: if checksign(AT, pkAA) = pkV then 0

Figure 8: Station’s process.

encryption key pkEA. Let ecSignature be the signed

and encrypted SharedATRequest. The station builds

an InnerATRequest structure containing pkV, hmac-

key, the SharedATRequest, and the ecSignature. The

InnerATRequest is later encrypted and sent to the AA

along with the encryption parameters.

Authorization-Validation Request. AA decrypts

the authorization request and obtains the InnerATRe-

quest. It checks the value of KeyTag. If the tag is not

valid, it responds negatively. If not, it forwards the

ecSignature and SharedATRequest to the correspond-

ing EA after signing and encrypting its message.

Authorization-Validation Response. EA decrypts

the Authorization-Validation request and checks the

signature of AA. Then, it decrypts the ecSignature

and checks the hash of the SharedATRequest. Finally,

it checks the signature of the station over the hash of

SharedATRequest and veriﬁes whether it is enrolled

or not and if it has permission to access the desired

subject attributes. If the veriﬁcation succeeds, EA

creates an Authorization Validation Response struc-

ture containing the request hash, a positive response

code (= 0), and the conﬁrmed subject attributes. This

structure is then signed, encrypted, and sent to AA.

Authorization Response. Based on the KeyTag

veriﬁcation and EA’s response, AA creates an Au-

thorizationResponse structure containing the request

hash, a response code and an AT. It signs it and en-

crypts it using the symmetric key sent by the station

and a freshly generated nonce.

6.2 Model in the Applied Pi-Calculus

We expressed the behaviour of our participants using

the processes depicted in Figures 7, 8, 9 and 10.

Authentication. First, we analyze the authentica-

tion properties using honest parties in ProVerif and

ﬁnd that Request Origin Authentication and Response

Authorship are successfully veriﬁed. However, Re-

quest Authorship property is not veriﬁed because, the-

oretically, an external attacker could replay a valida-

tion request sent by the Authorization Authority until

the request is no longer accepted by the Enrolment

Authority. We do not consider this as an attack be-

cause the ETSI TS 102 731 (ETSI, 2010) standard

suggested a countermeasure by providing Replay Pro-

tection services based on a timestamp. We have also

analyzed the same properties considering a dishonest

Authorization Authority and found attacks on all au-

thentication properties.

Attack Against Request Origin Authentication.

We suppose that an enrolled C-ITS station has re-

quested an AT with pkV, spkS and ecSignature param-

eters from a dishonest Authorization Authority which

did not forward its request to the corresponding Enrol-

ment Authority but instead kept those parameters in

memory. A dishonest Authorization Authority could

easily modify requests by injecting saved data from

previous requests. AA could use the identity of any

C-ITS station to create Authorization Tickets without

its consent and without even its knowledge. For ex-

ample, in case of misbehaving the pseudonym of the

vehicle could be linked to a false C-ITS station iden-

tity. We recall that structures in the C-ITS standard

are set up with a generation time. Therefore, this at-

tack remains valid until the expiry time of saved struc-

tures. The sequence diagram of this attack is depicted

in Figure 11.

Attack Against Response Authenticity. First,

Authorization-Validation protocol does not provide

any means for a C-ITS station to verify authoriza-

tion response authenticity. Authorization responses

come without any proof on whether or not they have

been approved by Enrolment Authority. Authoriza-

tion Authority may respond negatively to a valid AT

SECRYPT 2024 - 21st International Conference on Security and Cryptography

206

1: in(c, (y

, y

)·

2: if y

= idAA then

3: let k

= adec(y

, skAA) in

4: let (pkV, hmac − key, SharedAT Request, ecSignature) = sdec(y

, k

, y

) in

5: let (idEA, KeyTag) = SharedATRequest in

6: if checkhmac(KeyTag, pkV, hmac − key) = true then

7: νk · νn·

8: let k

= aenc(k, pkEA) in

9: let ValidationReq = (idEA, senc(sign((KeyTag, ecSignature), skAA), k, n), k

, n) in

10: out(c,ValidationReq)

11: in(c, (y

, y

))

12: if checksign(sdec(y

, k, y

), pkEA) = (hash(ValidationReq),true) then

13: let AT = sign(pkV, skAA) in

14: let AuthorizationResponse = (hash((y

, y

)),true, AT) in νn

15: out(c, (senc(sign(AuthorizationResponse, pkAA), k

, n

), nS))

Figure 9: Authorization Authority’s process.

1: in(c, (z

, z

))·

2: if z

= idEA then

3: let k = adec(z

, skEA) in

4: let requestSigned = sdec(z

, k, z

) in

5: let (KeyTag, ecSignature) = checksign(requestSigned, pkAA) in

6: let (z

, z

) = ecSignature in

7: if checkhash(KeyTag, checksign(sdec(z

, adec(z

, skEA), z

), spkS)) = true then νn·

8: out(c, (senc(sign((hash((z

, z

)),true), skEA), k, n), n))

Figure 10: Enrolment Authority’s process.

S AA EA

........... ........... ...........

KeyTag ← hmac(pkV, hkey)

← {{h(⟨id

, KeyTag⟩)}

sskS

}

⟨k

⟩

ecSignature ← ⟨n

, {k

}

, x

⟩

← {⟨pkV, hkey, ⟨id

, KeyTag⟩, ecSignature⟩}

⟨k

⟩

← ⟨n

, {k

}

, x

⟩

← {⟨ecSignature

′

, ⟨id

′

, KeyTag

′

⟩⟩}

← ⟨n

, {k

}

, y

⟩

Figure 11: Attack against request origin authentication.

request whereas Enrolment Authority (EA) has al-

ready approved it. Secondly, It is undeniable that

Authorization Authority could deliver Authorization

Tickets to any C-ITS station. In the description of

the Authorization-Validation protocol, Authorization

Authority has total control over Authorization Tick-

ets issuing. Therefore, it may respond positively to

an AT request without forwarding a validation request

to AA. This means that Authorization Authority may

deliver an AT to a non-enrolled or a revoked C-ITS

station. The sequence diagram of this attack is de-

picted in Figure 12. To ﬁx this attack, we propose to

Formal Analysis of C-ITS PKI Protocols

207

S AA

........... ...........

KeyTag ← hmac(pkV, hkey)

← {{h(⟨id

, KeyTag⟩)}

sskS

}

⟨k

⟩

ecSignature ← ⟨n

, {k

}

, x

⟩

← {⟨pkV, hkey, ⟨id

, KeyTag⟩, ecSignature⟩}

⟨k

⟩

← ⟨n

, {k

}

, x

⟩

← {⟨ecSignature, ⟨id

, KeyTag⟩⟩}

← ⟨n

, {k

}

, y

⟩

← ⟨n

, {{⟨h(x

), RC, AT⟩}

}

⟨k

⟩

Figure 12: Attack against response authenticity.

include, in the certiﬁcate response, a response from

EA intended for the station. Since the station has al-

ready shared a fresh symmetric key with EA, we use

this key to encrypt EA’s response which includes the

KeyTag along with a response code.

Attack Against Request Authorship. Violating

this property seems void of any real threat when

dealing with honest participants; an external attacker

would only replay the validation request sent by AA

and get an encrypted response from EA. Moreover,

as previously mentioned, the Replay Protection Ser-

vices may reject a replayed request. But in the case

of a dishonest AA, the threat becomes very serious

as it could generate validation requests based on pre-

vious received requests and would encrypt them with

freshly generated parameters so that they would not

be detectable by the Replay Protection Services. For

example, AA may deliver an AT for its own use by

replaying a previous validation-authorization request

with an enrolled C-ITS station parameter. This sce-

nario may seem unrealistic because a dishonest AA

could easily generate an AT for its own use. But

when AA obtains a validation from EA, means that

the protocol has been ”theoretically” executed hon-

estly. Such misbehavior has fewer chances of being

disclosed or reported.

7 RECOMMENDATIONS

To ﬁx the attack against response authenticity, we pro-

pose to include, in the certiﬁcate response, a response

from EA intended for the station. Since the station has

already shared a fresh symmetric key with EA, we use

this key to encrypt EA’s response which includes the

KeyTag along with a response code.

To repair the attack against request authorship, we

propose that the EA compare received KeyTag to a

list of recently received KeyTags. The KeyTag is used

to verify the freshness and to establish the direct link

between the vehicle and the EA. If a same one has

been used recently, EA rejects the validation.

8 CONCLUSION

Protocols in vehicular network are susceptible to var-

ious and several security threats and attacks. In fact,

sensitive information can be transmitted using a risky

and insecure channel. In this paper, we formally

analysed C-ITS PKI protocols in the symbolic model

based on the applied Pi-calculus using Pro-Verif and

Ukano veriﬁcation tools. Therefore, we used the au-

tomated veriﬁcation tool ProVerif. We formally mod-

eled C-ITS PKI protocols based on the speciﬁcations

given in the ETSI standard. We used an automatic pri-

vacy veriﬁer UKano to analyse all PKI protocols. We

found attacks on authentication properties, in Autho-

rization and Validation protocols when considering

a dishonest Authorization Authority (AA). We ﬁxed

two attacks by including a response (KeyTag) from

Enrolment Authority EA to the C-ITS station in the

certiﬁcate response. Via this work, we demonstrated

that the actual European security and interoperabil-

ity and ETSI PKI architecture and protocols for C-

ITS used in different European countries suffer from

several security problems that could be veriﬁed and

SECRYPT 2024 - 21st International Conference on Security and Cryptography

208

resolved. As a future work, more simulation can be

performed using the SUMO tool or NS3 to verify pro-

posed solutions. We could extend formal veriﬁcation

to other V2X protocols.

REFERENCES

Abadi, M., Blanchet, B., and Fournet, C. (2017). The ap-

plied pi calculus: Mobile values, new names, and se-

cure communication. Journal of the ACM (JACM),

65(1):1–41.

Armando, A., Basin, D., Boichut, Y., Chevalier, Y., Com-

pagna, L., Cu

ellar, J., Drielsma, P. H., H

eam, P.-

C., Kouchnarenko, O., Mantovani, J., et al. (2005).

The avispa tool for the automated validation of in-

ternet security protocols and applications. In Inter-

national conference on computer aided veriﬁcation,

pages 281–285. Springer.

Avalle, M., Pironti, A., and Sisto, R. (2014). Formal veriﬁ-

cation of security protocol implementations: a survey.

Formal Aspects of Computing, 26(1):99–123.

Baelde, D., Delaune, S., and Moreau, S. (2020a). A method

for proving unlinkability of stateful protocols. In 2020

IEEE 33rd Computer Security Foundations Sympo-

sium (CSF), pages 169–183. IEEE.

Baelde, D., Delaune, S., and Moreau, S. (2020b). A Method

for Proving Unlinkability of Stateful Protocols. PhD

thesis, Irisa.

Barbosa, M., Barthe, G., Bhargavan, K., Blanchet, B.,

Cremers, C., Liao, K., and Parno, B. (2021). Sok:

Computer-aided cryptography. In 42nd IEEE Sympo-

sium on Security and Privacy, SP 2021, San Fran-

cisco, CA, USA, 24-27 May 2021, pages 777–795.

IEEE.

Basin, D., Cremers, C., and Meadows, C. (2018). Model

checking security protocols. In Handbook of Model

Checking, pages 727–762. Springer.

Blanchet, B. (2014). Automatic veriﬁcation of security pro-

tocols in the symbolic model: The veriﬁer proverif.

Foundations of Security Analysis and Design VII,

8604(3):54–87.

Blanchet, B. (2016). Modeling and verifying security proto-

cols with the applied pi calculus and proverif. Founda-

tions and Trends® in Privacy and Security, 1(1-2):1–

135.

Bojjagani, S., Reddy, Y. P., Anuradha, T., Rao, P. V., Reddy,

B. R., and Khan, M. K. (2022). Secure authentica-

tion and key management protocol for deployment of

internet of vehicles (iov) concerning intelligent trans-

port systems. IEEE Transactions on Intelligent Trans-

portation Systems, 23(12):24698–24713.

Chi, L., Msahli, M., Memmi, G., and Qiu, H. (2023).

Public-attention-based adversarial attack on trafﬁc

sign recognition. In 2023 IEEE 20th Consumer

Communications & Networking Conference (CCNC),

pages 740–745. IEEE.

Comon, H. and Koutsos, A. (2017). Formal computa-

tional unlinkability proofs of rﬁd protocols. In 2017

IEEE 30th Computer Security Foundations Sympo-

sium (CSF), pages 100–114. IEEE.

Contreras-Castillo, J., Zeadally, S., and Guerrero-Iba

nez,

J. A. (2017). Internet of vehicles: architecture, pro-

tocols, and security. IEEE internet of things Journal,

5(5):3701–3709.

Dolev, D. and Yao, A. (1983). On the security of public key

protocols. IEEE Transactions on information theory,

29(2):198–208.

ETSI, T. Etsi ts 102 941 v1. 1.1-intelligent transport sys-

tems (its); security; trust and privacy management,”

standard, tc its, 2012.

ETSI, T. (2010). Etsi ts 102 731 v1. 1.1-intelligent transport

systems (its); security; security services and architec-

ture. Standard, TC ITS.

Haidar, F., Kaiser, A., and Lonc, B. (2017). On the per-

formance evaluation of vehicular pki protocol for v2x

communications security. In 2017 IEEE 86th vehic-

ular technology conference (VTC-Fall), pages 1–5.

IEEE.

Hirschi, L., Baelde, D., and Delaune, S. (2019a). A method

for unbounded veriﬁcation of privacy-type properties.

Journal of Computer Security, 27(3):277–342.

Hirschi, L., Baelde, D., and Delaune, S. (2019b). A method

for unbounded veriﬁcation of privacy-type properties.

Journal of Computer Security, 27(3):277–342.

Hirschi, L. and et al, B. (2016). A method for verifying

privacy-type properties: the unbounded case. In 2016

IEEE Symposium on Security and Privacy (SP), pages

564–581. IEEE.

Lafourcade, P. and Puys, M. (2015). Performance eval-

uations of cryptographic protocols veriﬁcation tools

dealing with algebraic properties. In International

Symposium on Foundations and Practice of Security,

pages 137–155. Springer.

Lafourcade, P., Terrade, V., and Vigier, S. (2009). Compar-

ison of cryptographic veriﬁcation tools dealing with

algebraic properties. In International Workshop on

Formal Aspects in Security and Trust, pages 173–185.

Springer.

Lamssaggad, A., Benamar, N., Haﬁd, A. S., and Msahli, M.

(2021). A survey on the current security landscape

of intelligent transportation systems. IEEE Access,

9:9180–9208.

Lone, F. R., Verma, H. K., and Sharma, K. P. (2022). Rec-

ommender credibility-based trust model for secure

v2x communication. In 2022 5th International Con-

ference on Computational Intelligence and Networks

(CINE), pages 1–6. IEEE.

Lu, Z., Qu, G., and Liu, Z. (2019). A survey on recent

advances in vehicular network security, trust, and pri-

vacy. IEEE Transactions on Intelligent Transportation

Systems, 20(2):760–776.

Meier, S., Schmidt, B., Cremers, C., and Basin, D. (2013).

The tamarin prover for the symbolic analysis of se-

curity protocols. In International conference on com-

puter aided veriﬁcation, pages 696–701. Springer.

Monteuuis, J. P., Hammi, B., Salles, E., Labiod, H.,

Blancher, R., Abalea, E., and Lonc, B. (2017). Se-

curing pki requests for c-its systems. In 2017 26th In-

Formal Analysis of C-ITS PKI Protocols

209

ternational Conference on Computer Communication

and Networks (ICCCN), pages 1–8. IEEE.

Needham, R. M. and Schroeder, M. D. (1978). Using en-

cryption for authentication in large networks of com-

puters. Communications of the ACM, 21(12):993–999.

Platform, C.-I. (2018). Certiﬁcate policy for deploy-

ment and operation of european cooperative intelli-

gent transport systems (c-its). Journal of Computer

Security, RELEASE 1.1.

Salami, Y. and Khajehvand, V. (2020). Smak-iov: se-

cure mutual authentication scheme and key exchange

protocol in fog based iov. Journal of Computer &

Robotics, 13(1):11–20.

Salin, H. and Lundgren, M. (2023). A gap analysis of the

adoption maturity of certiﬁcateless cryptography in

cooperative intelligent transportation systems. Jour-

nal of Cybersecurity and Privacy, 3(3):591–609.

Severino, R., Sim

ao, J., Datia, N., and Serrador, A. (2023).

Protecting hybrid its networks: A comprehensive se-

curity approach. Future Internet, 15(12):388.

Simplicio, M. A., Cominetti, E. L., Patil, H. K., Ricardini,

J. E., and Silva, M. V. M. (2018). The uniﬁed but-

terﬂy effect: Efﬁcient security credential management

system for vehicular communications. In 2018 IEEE

Vehicular Networking Conference (VNC), pages 1–8.

IEEE.

Sutrala, A. K., Bagga, P., Das, A. K., Kumar, N., Rodrigues,

J. J., and Lorenz, P. (2020). On the design of condi-

tional privacy preserving batch veriﬁcation-based au-

thentication scheme for internet of vehicles deploy-

ment. IEEE Transactions on Vehicular Technology,

69(5):5535–5548.

Szegedy, C., Zaremba, W., Sutskever, I., Bruna, J., Er-

han, D., Goodfellow, I., and Fergus, R. (2013). In-

triguing properties of neural networks. arXiv preprint

arXiv:1312.6199.

Yoshizawa, T., Singel

ee, D., Muehlberg, J. T., Delbruel, S.,

Taherkordi, A., Hughes, D., and Preneel, B. (2023). A

survey of security and privacy issues in v2x communi-

cation systems. ACM Computing Surveys, 55(9):1–36.

Yu, S., Lee, J., Park, K., Das, A. K., and Park, Y. (2020).

Iov-smap: Secure and efﬁcient message authentica-

tion protocol for iov in smart city environment. IEEE

access, 8:167875–167886.

Zhang, K., Liang, X., Lu, R., and Shen, X. (2014). Sybil at-

tacks and their defenses in the internet of things. IEEE

Internet of Things Journal, 1(5):372–383.

SECRYPT 2024 - 21st International Conference on Security and Cryptography

210