IEEE TRANSACTIONS ON INTELLIGENT TRANSPORTATION SYSTEMS, VOL. 19, NO.
4, APRIL 2018 1065
Reliable Cooperative Authentication
for Vehicular Networks
Hyo Jin Jo, In Seok Kim, and Dong Hoon Lee, Fellow, IEEE
Abstract— Vehicular ad-hoc networks (VANETs) have been
researched with regard to enhance driver’s safety and comfort.
In VANETs, all vehicles share their status and road condi-
tions with neighboring nodes by periodically generating safety
messages. To provide reliable VANET services, message authenti-
cation is an important feature. In particular, anonymous message
authentication has attracted considerable interest, because peri-
odic broadcast messages from a vehicle can be used to track its
location. Unfortunately, previously proposed anonymous message
authentication protocols had serious practical shortcomings,
including high communication, authentication, and revocation
costs, as well as reliability issues. Thus, in this paper, we propose
an anonymous authentication protocol based on a cooperative
authentication method. The proposed method does not require
mode synchronization between cooperative and non-cooperative
authentication. In addition, we design a two-layer pseudo-identity
generation method and construct a key update tree for efficient
revocation. Simulations show that our protocol does not result
in packet losses caused by authentication overheads, even when
the vehicle density is 200/km2 .
Index Terms— Anonymity, cooperative authentication,
vehicular Ad-hoc NETworks, revocation.
I. I NTRODUCTION
V EHICULAR Ad-hoc NETworks (VANETs) have become
a popular research field following the development of
wireless communication technologies. These networks can be
used to increase driver safety and comfort by providing a
vehicular communication system. VANETs are typically com-
posed of On-Board Units (OBUs), Road Side Units (RSUs),
and a Trusted Authority (TA). In the VANET environment, an
OBU is assumed to be installed in each vehicle and RSUs
are assumed to be deployed on roads. According to Dedicated
Short-Range Communications (DSRC) [1], each vehicle has
to broadcast a beacon message every 100 to 300 ms to nearby
vehicles and to RSUs, sharing information on, for example,
traffic (e.g., speed, acceleration, and deceleration), as well as
Manuscript received December 7, 2015; revised November 13, 2016 and
April 17, 2017; accepted May 29, 2017. Date of publication June 20, 2017;
date of current version March 28, 2018. This work was supported by the ICT
R&D Program “Development of Safety Transmission Technology Between
Automotive ECU” of MSIP/IITP under Grant B0101-16-0553. The Associate
Editor for this paper was C. F. Mecklenbräuker. (Corresponding author:
Dong Hoon Lee.)
H. J. Jo is with the Department of Computer and Information
System, University of Pennsylvania, Philadelphia, PA USA (e-mail:
hyojinjo86@gmail.com).
I. S. Kim and D. H. Lee are with the Center for Information Security
Technologies, Korea University, Seoul 136701, South Korea (e-mail:
iskim11@korea.ac.kr; donghlee@korea.ac.kr).
Color versions of one or more of the figures in this paper are available
online at http://ieeexplore.ieee.org.
Digital Object Identifier 10.1109/TITS.2017.2712772
1524-9050 © 2017 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
geometric and accident notifications. Mobility and the self-
organization of the network structure are also main features
of VANETs. Since vehicle- and road-related factors, such as
vehicle density and the presence of obstacles, may lead to
unstable communications among vehicles, several studies have
examined how to provide reliable communication [2], [3],
and [4].
However, a flexible wireless environment and periodic
broadcast messages on VANETs can also pose security threats,
including malicious data injection attacks, data replay attacks,
and location tracking. To thwart these attacks, many crypto-
graphic methods have been proposed. Among them, privacy-
preserving message authentication is a fundamental issue in
VANETs, and many privacy-preserving protocols have been
proposed in [5]–[19].
Calandriello et al. [5] and Jung et al. [6] use pseudonym-
based authentication schemes to enable vehicles to remain
anonymous. However, in these schemes, distributing the revo-
cation list (RL) is time consuming because the RL is expected
to be large. According to [7], an RL should include infor-
mation related to 2.5 million pseudonyms if 100 OBUs are
revoked, and each OBU has 25,000 pseudonyms. The delay
caused by RL management (i.e., RL distribution and updates)
could affect the availability of VANETs. In [8], every vehicle
uses its own dummy identity, which is unique and generated
by a trusted authority. However, the use of a single unique
identity cannot prevent it from being linked to a vehicle.
Although group signature-based protocols in [9]–[11] have
been proposed to reduce the size of the RL, these protocols are
not suitable for use in VANETs because the group-signature
schemes have high signature verification and revocation costs.
The bilinear pairing operation, which is typically used in
the verification and revocation processes of group signature
schemes, may cause long authentication delays. In order
to minimize the authentication and revocation management
overhead, trusted device-based authentication protocols have
been proposed by [12] and [13]. However, installing a trusted
device on every vehicle may limit the deployment of VANETs.
To ensure efficient anonymous message authentica-
tion without a trusted device, RSU-aided authentica-
tion protocols [14]–[16] and cooperative authentication
protocols [17]–[19] have been proposed. The former uses
the computation power of RSUs to efficiently authenticate
messages, while the latter makes all vehicles authenticate mes-
sages cooperatively by sharing their own verification results
with nearby vehicles. However, these methods have several
problems. The protocols in [14] and [15] require that RSUs
be deployed in all regions, otherwise authentication will not
1066 IEEE TRANSACTIONS ON INTELLIGENT TRANSPORTATION SYSTEMS, VOL. 19, NO. 4, APRIL 2018
be performed properly. In the protocol in [16] and [18], each
RSU, acting as a group manager, issues a group-member key
for each vehicle, which means that RSUs can trace the trajec-
tories of vehicles. The protocol in [17] has revocation prob-
lems related to the size of the RL, because it also uses a large
number of pseudonyms to ensure privacy. Then, the methods
in [18] and [19] might not perfectly verify all messages,
because authentication mode synchronization between cooper-
ative and non-cooperative methods presents a difficult problem
owing to unpredictable road conditions. In other words, the
cooperative authentication methods proposed in [18] and [19]
are able to verify all messages only in the case of high
vehicle density on the road; if the vehicle density is low, these
protocols may affect the reliability of authentication, because
it is possible for several messages to be considered valid
without authentication. These protocols can also be exploited
by modification attacks on location information because they
select messages for verification based on location information.
In addition, [7] and [19] use a group key distribution technique
for efficient revocation. However, their group key distribution
methods have security problems, which are explained in detail
in Sections II and V.
In this paper, we introduce a reliable cooperative authentica-
tion protocol that offers efficient revocation. Our contributions
are as follows.
A. Contributions
• To solve RL management problems (the distribution
and renewal of RL) that originate from the use of
pseudonyms, we design a two-layered pseudonym gen-
eration method based on a keyed hash chain. The keyed
hash chain and two-layer pseudonym generation method
can reduce the size of the RL and the management cost
of the RL, respectively. In addition, we adopt a secure
group key distribution protocol that can eliminate the RL
distribution process between RSUs and OBUs.
• We propose a basic cooperative authentication method
that does not require authentication mode synchronization
between non-cooperative and cooperative authentication.
Furthermore, we extend our method to improve the
authentication performance. In our simulation, we find
that the improved method does not result in message
losses, when the vehicle density is set to 200/K m 2, while
the message loss ratios of basic cooperative authentication
and non-cooperative authentication are about 25 % and
37%, respectively.
The remainder of the paper is organized as follows: Related
works are discussed in Section II. Section III introduces our
network model and the requirements for our work. The pro-
posed protocol is presented in Section IV. In Section V and VI,
we evaluate and compare our protocol to others in terms of
security and performance. Finally, Section VII concludes the
paper.
II. R ELATED W ORKS
In order to construct secure VANETs, many studies focus on
security and privacy. In [20], a large set of anonymous public
and private key pairs is preloaded on an OBU to provide both
message authentication and anonymity. Each private key is
used to sign beacon messages during a short predefined inter-
val. However, managing the certificate revocation list (CRL)
is challenging, because revoking a vehicle’s certificate causes
a large number of pre-loaded certificates to be revoked. To
solve the problems with certificates, protocols using a large set
of pseudo-identities have been proposed. Unfortunately, these
protocols also have problems, in this case related to distribut-
ing large RLs. In [21], the size of the RL is reduced using a
hash chain. However, this method cannot be applied directly
to V2V communication because the RL should be periodically
distributed to, and managed by vehicles. The RL management
overhead, including updating and sorting the RL, can be an
additional burden on vehicles. To remove this overhead from
vehicles, a two-layered pseudonym generation method using
a hash chain has been proposed by [22]. This protocol also
allows an unrevoked vehicle to update its own certificates
using a semi-trusted entity, such as an RSU, by adopting proxy
re-signature cryptographic technology. Although this method
does not require that vehicles perform RL management, three
bilinear pairing operations are performed on a vehicle to verify
the certificates of neighboring nodes.
Group-signature-based approaches have also been pro-
posed for anonymous message authentication in [9]–[11].
In [9] and [10], a vehicle must check the revocation status
of anonymous signatures to avoid verifying signatures from
revoked vehicles. Unfortunately, this method requires 3 × n
bilinear pairing operations if there are n revoked vehicles
in the RL. The protocol in [11] also requires n bi-linear
pairing operations. Thus, group signature-based approaches
can cause long authentication delays. As another approach,
RSU-aided message authentication protocols have been pro-
posed for efficient authentication in [14]–[16]. The protocols
in [14] and [15] require that RSUs authenticate all beacon
messages, which are generated from their own domain, and
report the authentication results to the vehicles in their own
domain. However, these protocols cannot work if RSUs do
not cover all areas. In [16], RSUs issue group keys to
vehicles after authenticating them based on their real identities.
Although this method can reduce revocation costs, the location
of a vehicle can be traced by an RSU. The batch verification
method in [23] can also reduce the message authentication
time. However, an additional operation is required to find
invalid signatures if a batch contains such signatures.
Recently, cooperative authentication protocols ([17]–[19])
and group key (GK) distribution protocols ( [7], [19]) were
proposed for efficient authentication and revocation. The pro-
tocols in [17]–[19] take advantage of the fact that each
vehicle can cooperate in the message verification processes by
selectively verifying its received signatures and by reporting
its own verification results to neighboring vehicles, because
vehicles in same area possess nearly the same set of messages.
However, the protocols in [18] and [19] do not consider
how to synchronize the authentication mode among vehicles.
Mode synchronization between a non-cooperative authentica-
tion mode and a cooperative authentication mode is difficult,
because the number of nodes in each vehicle’s communication
JO et al.: RELIABLE COOPERATIVE AUTHENTICATION FOR VEHICULAR NETWORKS
Fig. 1. System model.
range is not fully predictable. If vehicles in the same area are
not synchronized with the same mode, some messages may
not be verified at all. (Detailed explanations are presented
in Section V). The protocol in [17] causes a huge size of
the revocation list because each vehicle uses many pseudo
identities. This means that all pseudo identities of a revoked
vehicle are added to a revocation list, even if one node is
revoked.
Reference [7] and [19] proposed efficient revocation pro-
tocols using MAC (Message Authentication Code) values.
In their methods, a group key is issued to valid vehicles by
RSUs or by a trusted authority. Then, vehicles generate MAC
values on their messages using the group key. Vehicles that do
not generate valid MAC values are considered to be revoked.
However, the key distribution protocols have problems. In the
initialization of [7], a trusted authority issues update keys to
vehicles, selected probabilistically from a secret pool of keys.
Then, the trusted authority selects a non-compromised key,
shared by the majority of the non-revoked OBUs, from the key
pool whenever the key update process occurs. The selected
key is used to encrypt a key-update message, including a
new group key. When non-revoked vehicles do not have the
non-compromised key, they request the transmission of a new
group key from a vehicle with the non-compromised key.
However, this key request process could fail if there are no
vehicles that have the non-compromised key in areas where
the key request occurred. In [19], a secret polynomial used
for key updates can be disclosed by collusion attacks, as
described in [24]. For secure key distribution, several protocols
have been proposed in [25]–[27]. Although the protocols
in [25] and [26] can distribute a group key securely, the former
may cause a single point of failure in the trusted authority,
whereas the latter can generate heavy traffic for a key update
if many group members exist. Moreover, the protocol in [27]
has a security flaw, which is described in [28].
III. S YSTEM M ODEL AND R EQUIREMENTS
In this section, we present the system model and the
requirements for the proposed protocol.
A. System Model
As shown in Fig. 1, the proposed system model for VANETs
consists of a TA, RSUs, and OBUs [29]. Their clocks are
assumed to be loosely synchronized using an existing method,
such as GPS-based time synchronization.
1067
• Trusted Authority (TA): The TA generates and manages
the certificates of RSUs. Additionally, it issues a large
set of pseudo-identities and the corresponding private
keys to vehicles via secure channels, such as Transport
Layer Security (TLS). Public information, such as public
parameters, is managed by the TA. We assume that a
TA cannot be compromised because it is responsible for
generating and managing the secret values of VANETs.
• Road Side Unit (RSU): RSUs are assumed to be
deployed in many areas. We assume that RSUs are semi-
trusted entities [30] that perform their expected roles.
However, they may be compromised. Thus, they should
be monitored and managed by TA using the existing
methods such as the evaluation system [31], [32] and
remote attestation [33], [34] because information stored
in RSUs might be leaked into the public domain.
• An On Board Unit (OBU): OBUs periodically broadcast
a beacon message. Each OBU is preloaded with a large
set of pseudo-identities and corresponding private keys,
which should be securely issued/updated periodically.
(e.g., annual car inspections [35])
According to [36], there are two types of communication
networks. The first includes wired connections between the
TA and RSUs. The second includes wireless connections for
V2I (vehicle-to-infrastructure) and V2V (vehicle-to-vehicle)
communication. We assume that the TA and RSUs are con-
nected securely using TLS. However, V2V and V2I com-
munication are considered to be insecure channels because
of dynamic wireless communication configurations caused by
unpredictable movements of vehicles.
1) Adversary Model: We assume a polynomial-time adver-
sary who can compromise RSUs and OBUs. The adversary
can also control communication channels (e.g., modification,
injection, eavesdrop, deletion of data in the network). We fur-
ther assume that the majority of vehicles and RSUs are
honest. If there are malicious nodes, they can be detected
by neighboring honest nodes and revoked by the TA. The
specifics of the detection mechanisms, such as the evaluation
system [31], [32] and remote attestation [33], [34], are beyond
the scope of this study.
B. System Requirements
In this section, we identify the following requirements for
the proposed system.
• Message integrity and source authentication: In VANETs,
all messages should be transmitted without being
changed, and each message should be verified, to confirm
its origin.
• Conditional privacy preservation: Beacon messages,
including a vehicle’s location, may be used for illegal
tracking. Thus, the real identity of a vehicle should be
hidden (anonymity) and unlinkable (unlinkability) from a
receiver. On the other hand, the real identity of a vehicle
should be traced and linkable by the TA (traceability) in
order to deal with exceptional situations, such as liability
investigations.
• Revocation: When vehicle misbehavior is detected, the
misbehaving vehicle(s) should be excluded from the
1068 IEEE TRANSACTIONS ON INTELLIGENT TRANSPORTATION SYSTEMS, VOL. 19, NO. 4, APRIL 2018

VANETs. If group key-based revocation is used, it should TABLE I

satisfy the following properties. N OTATION
- Forward secrecy: RSU-aided group key distribution
should provide forward secrecy. In other words, when
group members leave or are revoked, they should not
obtain a new group key.
- Resistance to colluding attacks: Revoked group mem-
bers should not obtain a new group key, even if they
collude with each other.
• Reliability: All beacon messages should be verified. If
there is a possibility that some malicious messages are
accepted by receivers without verification, these mali-
cious messages will degrade the reliability of the system.
• Availability: According to DSRC [1], the broadcast period
of each vehicle is 300 ms. If 25 to 100 vehicles are within
a communication range, each receiver should verify 75 to
300 messages within one second. Additionally, revocation
checking of these messages should be performed. Thus,
the system needs a lightweight authentication protocol to
support efficient revocation.

IV. P ROPOSED S CHEME

In this section, we present the proposed scheme, which is
composed of six parts.
• Setup: TA and RSUs initialize their secret values and
public parameters.
• Registration: A large set of pseudo identities and the cor-
responding secret keys are distributed to all valid vehicles.
In particular, in this part, a new two-layered pseudonym
generation using a keyed hash chain is designed. The use
of a keyed hash chain can reduce the management of the
revocation list.
• Management of revocation lists: The TA generates revo-
cation lists and distribute them to RSUs.
• Generation and distribution of group keys and update
keys: The TA periodically generates a group key (G K )
and distributes it to all RSUs. The G K is used for
revocation checks to reduce the management overhead
of the revocation lists. The RSUs construct an update
key tree, which is composed of a b-tree and n-trees. To
minimize the size of an update message, update keys are
generated using the C-basic chain scheme in [37]. Finally,
the RSUs distribute the group key and update keys to
vehicles that pass within range.
• Message authentication for V2V: Vehicles authenticate
beacon messages cooperatively. To send authentication
results to neighboring nodes, each vehicle sends a report
indicating valid messages, which have been verified suc-
cessfully, to its neighboring nodes. Mode synchronization
between a cooperative mode and a non-cooperative mode Fig. 2 shows an overview of our scheme. The notation used
is not required, as in [17]. In addition, a new delayed in this paper is presented in Table 1.
cooperative method is proposed to improve message
authentication performance.
• Management of a group key and update keys: Whenever A. Setup
a group key or update keys need to be updated, RSUs In the setup process, the TA initializes its own secret values
distribute an update message to all vehicles within in their and public parameters, and all RSUs generate their own
domain. private keys and corresponding public keys.
JO et al.: RELIABLE COOPERATIVE AUTHENTICATION FOR VEHICULAR NETWORKS
Fig. 2. Overview of the proposed scheme.
- TA Setup
1) The TA randomly chooses a secret key x ∈ R Z p and
computes the public key Ppub = x P. Then, the TA
generates its own tracing key tk, which is used to
generate pseudo-identities. (Let F be a finite field, C be
an elliptic curve defined over F, and P be an element
of a large prime order p in C.)
2) The TA chooses cryptographic hash functions H1 :
{0, 1}∗ → Z p , H2 : {0, 1}∗ → Z p , and H3,key :
{0, 1}∗ × key → {0, 1}n , H4,key : {0, 1}∗ × key →
{0, 1}n , h : {0, 1}∗ → {0, 1}n .
3) The TA sets the time interval (L t w ) and the number
of time slots (Nt s ) for one time window. Then, the
TA divides a time domain into several time windows,
according to L t w . Each time window includes Nt s
time slots, which last for L t s = L tw
Nts . A vehicle Vi
can only use one pseudo-identity in one time slot. Both
L t w and Nt s are parameters used for location privacy.
The shorter the L t w and the larger the Nt s that the TA
sets, the better location privacy is preserved, because the
valid time of one pseudo-identity is reduced. Let T W j
denote the j th time window, and T S j,k denote the kth
time slots at T W j (1 ≤ k ≤ Nt s ).
4) The TA sets the number of pseudo-identities (N pid ),
which will be used at N pid time windows by one vehicle.
- RSU Setup
1) All RSUs generate a signing/verification key pair
(SK R SUi , VK R SUi ) for use in a digital signature (e.g.,
ECDSA).
2) Then, RSUs receive certificates (Cer t R SUi ) on their
public parameters from the TA; Cer t R SUi includes
I D R SUi and VK R SUi .
After completing the setup process, the TA pub-
lishes the tuple (H1(), H2 (), H3,key (), H4,key (), h(), Ppub ,
L t w ,Nt s ,F,C,P, p) as the public parameters.
1069
Fig. 3. Generation of pseudo-identities.
B. Registration
In our protocol, the TA issues a large set of pseudo-
identities and corresponding secret keys to each vehicle during
a vehicle inspection [35]. These values must be delivered via a
secure channel, such as TLS or physical access channels. The
TA performs the following process to register each vehicle
(|| denotes concatenation):
1) A vehicle Vi sends its own IDVi to the TA.
2) Then, the TA generates a random value seedVi
and a revocation key RK Vi . It computes revocation
j
values RVi, j = H3,R K V (seedVi ) and RVi, j,k =
i
K Vi (RVi, j ), (1 ≤ j ≤ N pid , 1 ≤ k ≤ NT S ). Then,
k
H4,R
it generates pseudo-identities. There are two types of
pseudo-identities: one is for the time window, the other
is for the time slot.
PIDti,wj = TW j ||E t k (IDVi ⊕ RVi, j )||RVi, j
PIDti,sj,k = TS j,k ||E t k (IDVi ⊕ RVi, j,k )||RVi, j,k
(1 ≤ j ≤ N pid , 1 ≤ k ≤ NT S ). (1)
The total number of pseudo-identities issued to the
vehicle Vi is N pid × NT S .
3) The TA picks two random values ri, j ,ri, j,k ∈ Z∗p .
Subsequently, it computes the following parameters:
Ri, j = ri, j P,
ci, j = H1 (Ppub , P I Di,t wj , Ri, j )
si, j = ri, j − ci, j x mod P
Ri, j,k = ri, j,k P,
ci, j,k = H1 (Ppub , P I Di,t sj,k , Ri, j,k )
si, j,k = ri, j,k − ci, j,k x mod P
(1 ≤ j ≤ N P I D , 1 ≤ k ≤ NT S ). (2)
4) The TA sends all values (P I Di,t wj , P I Di,t sj,k , ci, j , si, j ,
ci, j,k , and si, j,k ), without Ri, j and Ri, j,k generated in
2) and 3), to Vi via a secure channel.
After completing the registration process, the TA saves IDVi ,
seedVi , and RK Vi in its own database. Fig. 3 shows the
generation processes for the pseudo-identities.
C. Management of Revocation Lists
1) Revocation List Issues & Updating
The TA adds RVi, j −δ and RVi, j of PIDti,wj and RK Vi to
its own revocation list if a new vehicle Vi is revoked
1070 IEEE TRANSACTIONS ON INTELLIGENT TRANSPORTATION SYSTEMS, VOL. 19, NO. 4, APRIL 2018
Fig. 4. Example of a logical key tree used for updates.
at T W j (δ is a pre-defined system parameter). Then,
the TA broadcasts the revocation list to all RSUs at
T W j . The RSU can update the revocation value RVi, j +1
from RVi, j using RK Vi and H3,key () at T W j +1 . Here,
RVi, j −δ is used for the group key update, which is
explained in the next section.
2) Revocation List Checking
In T W j , given PIDti,wj = TW j || E t k (IDi ⊕ RVi, j )
||RVi, j , from Vi , an RSU checks whether the RVi, j
exists in the revocation list. If the revocation list includes
RVi, j , PIDti,wj is considered to be the revoked pseudo-
identity.
D. Generation and Distribution of
Group Key and Update Keys
- Generation of a Group key & Update keys
1) The TA generates a group key G K , which it periodically
transmits to all RSUs via a secure channel. The lifetime
of a G K is a system parameter.
2) Then, each RSU generates update keys, which will be
used to transmit a new G K . These keys are assigned
to vehicles, in order, that pass by the domain of the
RSU. In the process of generating update keys, the
RSU constructs an update tree using a b-tree (height
= h) and n-trees using Algorithms 1 and 2 to reduce
the transmission overheads of the encrypted broadcast
message, which includes a new G K . (Algorithm 2 is
based on the C-Basic Chain scheme in [37].) Fig. 4
shows an example of tree construction.
- Distribution of a Group Key and Update Keys
When Vi meets a new RSU, a key distribution process between
Vi and the RSU is performed, as follows:
1) RSUi generates a random value t ∈ Z p and com-
putes T = t P and Sig S K RSUi (T ||ID R SUi ). Then, RSUi
periodically broadcasts its own ID R SUi , T i me R SUi T ,
Sig S K RSUi (T ||T i me R SUi ||ID R SUi ), and Cer t RSUi to its
own domain. When Vi passes by RSUi , it receives
this broadcast message at T W j and checks whether
the ID R SUi is new. If the ID R SUi is new, Vi validates
Cer t R SUi and Sig S K RSUi (T ||ID R SUi ) and performs time
synchronization with RSUi using T i me R SUi .
2) If the validation of Cer t R SUi and Sig S K RSUi (T ||ID R SUi )
is successful, Vi generates a random value, t  ∈ Z p , and
computes T  = t  P, e = H2 (Ppub , P I Di,t wj , T  , T, ci, j ),
and π = t  − esi, j . Then, it computes a session
key κ = t  T = t  t P and performs encryption
E κ (P I Di,t wj ||ci, j ||π). Finally, Vi transmits a message,
including E κ (P I Di,t wj ||ci, j ||π) and T  , to RSUi .
3) After receiving the message from Vi , RSUi computes
the session key κ = t T  = tt  P and decrypts the
message. Then, it checks whether RVi, j of P I Di,t wj is
included in the revocation list. If P I Di,t wj is not revoked,
P I Di,t wj , ci, j , T  , and π are verified using the following
formula:
e = H2 (Ppub , P I Di,t wj , T  , T, ci, j )
ci, j = H1(Ppub , P I Di,t wj , ci, j Ppub + e−1 (T  − π P)).
(3)
4) If the verification is successful, RSUi assigns Vi as
γ
a leaf node L Nα of the update key tree in the fol-
lowing order: 1 ≤ γ ≤ 2h , 1 ≤ α ≤ n where
h is the height of a b-tree, and n is the number of
nodes in a n-tree. Then, RSUi forms a set, includ-
ing update keys, composed of two parts, BU K h,β ∗
γ
and NU K α,∗ (obtained using Algorithms 1 and 2).
An example of an update key set is shown in Fig. 4.
Finally, RSUi generates E κ (G K ||BU K h,β ∗ ||NU K γ )
α,∗
∗ ||NU K γ )), and
and Sig S K RSUi (T  ||E κ (G K ||BU K h,β α,∗
transmits these values to Vi .
5) After receiving T  , E κ (G K ||BU K h,β ∗ || NU K γ ),
α,∗
 ∗ γ
and Sig S K RSUi (T ||E κ (G K ||BU K h,β || NU K α,∗ )), Vi
∗ ||NU K γ )).
verifies Sig S K RSUi (T  ||E κ (G K ||BU K h,β α,∗
If the verification is successful, Vi decrypts
∗ ||NU K γ ) to obtain the group
E κ (G K ||BU K h,β
α,∗
key G K and the sets of update keys, BU K h,β ∗ and
γ
NU K α,∗ .
After the key distribution, RSUi stores the pair (P I Di,t wj
γ
and L Nβ ) in its database. If there are transmission errors, a
vehicle should send a re-transmission request to RSUi .
E. Message Authentication for V2V
In this section, we propose our cooperative message authen-
tication protocol.
- Generation of Beacon Messages
Each vehicle periodically broadcasts a beacon message. In our
protocol, both a signature algorithm [38] and a message
authentication code algorithm are applied to each beacon
message. The detailed processes are described as follows:
1) In time slot T S j,k , a non-revoked vehicle Vi generates
a beacon message Mi . Then, Vi chooses a random
JO et al.: RELIABLE COOPERATIVE AUTHENTICATION FOR VEHICULAR NETWORKS 1071

value r ∈ Z p and computes R = r P, e = Algorithm 2: Generate Keys for n-ary Tree

H2 (Ppub , P I Di,t sj,k , Mi , Ctri , R, ci, j,k ), and π = r − Input : The number of leaf nodes in n-ary tree: n,
esi, j,k . Here, Ctri is a message counter that is initialized the height of b-tree: h,
to zero whenever P I Di,t sj,k changes. The length of hash chain: c
2) After generating Mi , R, e, and π, Vi computes the γ γ
Output: Update keys of n-ary tree: NU K α,β , NU K α,∗
message authentication code M AC G K (P I Di,t sj,k ||ci, j,k ||
π||Mi ||Ctri ||R) using G K . Finally, Vi broadcasts
P I Di,t sj,k , ci, j,k , π, Mi , R, and M AC G K (P I Di,t sj,k || for γ ← 1, 2h do
ci, j,k ||π||Mi ||Ctri ||R) to neighboring vehicles.
for α ← 1, n − c + 1 do
γ
Generate a random value NU K α,α ← {0, 1}128
Algorithm 1: Generate Param & Keys for b-Tree Generate chain values
γ γ
Input : Average daily traffic of RSU’s domain NU K α,α+1 = h(NU K α,α ),
γ
Output: The number of required nodes in RSU’s trees: NU K α,α+2 = h 2 (NU K α,α ),
γ γ
N, …, NU K α,α+c−1 = h c−1 (NU K α,α )
the height of b-tree: h, end for
the number of leaf nodes in n-ary tree: n,
∗
update keys of b-tree: BU K α,β , BU K h,β for α ← n − c + 2, n do
γ
Generate a random value NU K α,α
Set the number of the required node N Generate chain values
N = 2h × n ≈ average daily traffic γ γ
NU K α,α+1 = h(NU K α,α ),
γ γ
NU K α,α+2 = h (NU K α,α ),
2
for α ← 0, h do γ γ
…, NU K α,n−1 = h n−1−α (NU K α,α )
for β ← 1, 2α do
end for
Generate random values
BU K α,β ← {0, 1}128
end for
end for
end for
Assign key sets
for γ ← 1, 2h do
Assign key sets
for α ← 1, n do
for β ← 1, 2h do
∗ ← all keys on the path from the node (h, β) if α ≥ c
BU K h,β γ
NU K α,∗ ←
to root γ γ γ
NU K α−c+1,α , NU K α−c+2,α , . . . , NU K α,α
end for
else
γ
NU K α,∗ ← NU K 1,α
k
, NU K 2,α k
, . . . , NU K α,α
k
- Cooperative Verification of Beacon Messages end for
In cooperative verification, each vehicle shares its verification end for
result by reporting it. Each vehicle uses two processes for
message verification: a beacon verification process, and a
report verification process. The process times are set to BT
and RT , respectively. These values are predefined system Because the minimum number of verified messages
parameters; their sum should be less than or equal to the during the beacon verification period is set to N B , Vi
beacon period (i.e., 300 ms). Beacon messages and report recursively performs the above decision process and
messages are stored in their own queues (i.e., a beacon queue, the verification process until the authenticated messages
and a report queue). reach N B . Here, N B is the value necessary to respond
• Basic cooperative authentication to beacon messages more rapidly when the vehicle
density is low. If N B is not defined, vehicles always
1) In the beacon verification process, vehicles near Vi
await verification reports, even though they can verify
decide whether to authenticate M AC G K (P I Di,t sj,k ||
all beacon messages without these reports.
ci, j,k ||π||Mi ||Ctri ||R) with probability Pv when Vi
2) At the end of the beacon verification process,
broadcasts a beacon message Mi . If several vehicles
all vehicles broadcast their reports, which include
decide to authenticate, and authentication is successful,
their own verification results. For example,
they consider P I Di,t sj,k to be a valid pseudo-identity.
in time slot T S j,k , Vi generates Repor t =
Then, they perform the following signature verification: t s , Ctr ),(P I D t s
(P I Dα, j,k α β, j,k , Ctr β ) if the messages
corresponding to P I Dα, ts and P I Dβ, ts are
e = H2(Ppub , P I Di,t sj,k , Mi , Ctri , R, ci, j,k ) j,k j,k
successfully verified. Then, Vi chooses a random
ci, j,k = H1(Ppub , P I Di,t sj,k , ci, j,k Ppub +e−1 (R−π P)). value r  ∈ Z p and generates a signature value
(4) (R  = r  P, e = H2(Ppub , P I Di,t sj,k , Repor t, R  , ci, j,k ),
1072 IEEE TRANSACTIONS ON INTELLIGENT TRANSPORTATION SYSTEMS, VOL. 19, NO. 4, APRIL 2018
and π = r  − esi, j,k ) and a MAC value
(M AC G K (P I Di,t sj,k ||ci, j,k ||π||Repor t||Ctri ||R  )).
Finally, Vi broadcasts its own report, including the
corresponding signature value and MAC value.
3) After the beacon verification process, vehicles perform
the report verification process during RT . In this
process, vehicles verify N R reports, in order. In addition,
Vi verifies both the remaining messages that have not
been covered by reports and all new beacon messages
received during RT .
• Delayed cooperative authentication
1) In the beacon verification process of delayed cooperative
authentication, the verification targets are beacon mes-
sages generated in the present beacon verification period
and the previous report verification period. In other
words, the vehicles select beacon messages generated
during the previous report verification period and during
the present beacon verification period with probabil-
ity Pv . Then, they verify the selected messages. The
number of verified messages should be greater than or
equal to N B .
2) This step is identical to step 2) of the basic cooperative
authentication.
3) After the beacon verification process, vehicles perform
the report verification process during RT . In this
process, vehicles verify N R reports, in order. Then,
Vi verifies the remaining messages that have not been
covered by reports. In this step, vehicles do not verify
the beacon messages received during report RT ; these
messages will be verified in the next beacon verification
Algorithm 3: Generate BU K N
Input : Rev_info (or expired_info), b-tree, the height
of b-tree (h)
Output: The set of non-compromised keys BU K N
Form a compromised (or expired) key set K ∗
K ∗ ← all keys are on the path from revoked leaf nodes
to root
(or all keys are on the path from expired leaf nodes to
root)
Make empty set BU K N
MakeIndex (BU K 0,1 , K ∗ , BU K N )
return BU K ∗
Function MakeIndex(BU K α,β , K ∗ , BU K N )
if BU K α,β ∈ K ∗ then
BU K N ← BU K α,β
break
else if BU K α=h,β then
MakeIndex (BU K α+1,(β×2)−1, K ∗ , BU K N )
MakeIndex (BU K α+1,β×2 , K ∗ , BU K N )
end Function
Case 1: If there are no new revoked vehicles among those
that have already received G K , RSUi encrypts G K new with
BU K 0,1 , as follows (r ev_i n f o is set to none):
process.
.
In basic cooperative authentication, if a vehicle receives
many beacon messages during the report verification process,
several beacon messages may be not authenticated within
the report verification time. In contrast, in delayed cooper-
ative authentication, the authentication operations of beacon
messages received during report verification are delayed. We
simulate this delay and evaluate how it affects authentication
in Section VI.
F. Management of a Group Key and Update Keys
r ev_i n f o : none, E BU K 0,1 (G K new )
Case 2: If there are new revoked vehicles among the
vehicles that have already received G K , RSUi finds the leaf
nodes of the n-ary trees to which the revoked vehicles belong.
Then, RSUi finds all revoked keys on the path from the
revoked leaf nodes to the root node, and generates a random
update parameter (u_ par am) that will be used to update the
compromised keys. Finally, RSUi encrypts both G K new and
the update parameter with non-compromised keys in the b-tree
and n-ary trees, as follows (r ev_i n f o indicates the revoked
leaf nodes):
- Update of a Group Key
RSUs broadcast an update message for a new group key,
G K new , when the previous group key G K needs to be updated.
The update message is composed of two parts: r ev_i n f o,
indicating the indexes of revoked vehicles in its own domain;
and the encrypted message, including both G K new and an
update parameter. When G K new is transmitted from TA at
T W j , RSUi checks whether the pseudo-identities of vehicles
passing by RSUi from T W j −δ to T W j are included in the
revocation list. Because the revocation list at T W j includes
both P I Di,t wj −δ and P I Di,t wj of a revoked vehicle Vi , RSUi
can exclude the revoked vehicle that has received G K during
T W j −δ ∼ T W j from the update of G K new .
After checking the pseudo-identities, RSUi generates an
update message to transmit G K new . The generation of the
update message is divided into two cases.
r ev_i n f o : {L Nαγ11 , L Nαγ22 , . . .}
E B1 (G K new ||u_ par am), E B2 (G K new ||u_ par am), . . . ,
E N1 (G K new ||u_ par am), E N2 (G K new ||u_ par am), . . .
Bi ∈ BU K N (i th element ofBU K N ),
Ni ∈ NU K N (i th element ofNU K N ).
To find non-compromised keys BU K N and NU K N , RSUi
executes Algorithms 3 and 4, respectively. After G K new has
been updated, RSUi and all non-revoked vehicles should
update the compromised keys using an XOR operation with
u_ par am. Examples of group key update messages are pre-
sented in Fig. 5. If a vehicle does not receive the update
message owing to a transmission error, it can obtain the
message from its neighboring nodes that have received the
message.
JO et al.: RELIABLE COOPERATIVE AUTHENTICATION FOR VEHICULAR NETWORKS
Fig. 5. Examples of group key update messages.
Algorithm 4: Generate NU K N
Input : Rev_info, n-ary tree, the height of b-tree (h),
the length of hash chain (c)
Output: The set of non-compromised keys NU K N
for γ ← 1, 2h do
γ γ
Find disjoint intervals (Iα1 ,α1 , . . . , Iαm ,αm )
An interval consists of non-revoked vehicles in the n-ary
tree
(The union of all disjoint intervals covers all
non-revoked nodes)
If there is a length of intervals > c
partition those intervals into several disjoint
sub-intervals using c
(the length of the last sub-interval is less than c)
γ γ
NU K N ← (NU K α1 ,β1 , . . . , NU K αm ,βm )
end for
return NU K N
- Renewal of Update Keys
If all update keys in the update tree are assigned to vehi-
cles, the RSUs should update the b-tree and n-ary trees to
accommodate new vehicles. First, RSUi removes the oldest
n-ary tree and generates a new n-ary tree. Then, it finds all
keys in the b-tree that existed in parent nodes of the removed
n-ary tree. Because these keys are considered to be expired
keys, RSUi generates a new update parameter and performs
an XOR operation between the expired keys of the b-tree with
the new parameter. Additionally, RSUi encrypts the parameter
1073
with the non-expired keys obtained from Algorithm 3 in order
to broadcast this encrypted value to non-expired vehicles that
have already had expired keys. The non-expired vehicles can
update the expired keys using an XOR operation with the
update parameter. In future studies, an algorithm that balances
the key trees, as accomplished by the algorithm in [39], should
be applied to the proposed method to minimize the cost of the
group key renewal process.
V. S ECURITY A NALYSIS
A. Message Integrity and Source Authentication
In our protocol, each vehicle sends the signature
R = r P, ci, j,k = H1(Ppub , P I Di,t sj,k , Ri, j,k ), and
π = r − esi, j,k (e = H2 (Ppub , P I Di,t sj,k , M, R, ci, j,k )) for a
beacon message to its neighbor. By verifying the signature,
the receiver can ensure both the integrity and the origin
of the message. If an adversary wants to forge the signa-
ture, he/she must obtain si, j,k from π. This means that the
adversary must compute r from R to obtain si, j,k . However,
this violates the elliptic curve discrete logarithm problem1
(ECDLP). Another attack approach is to find a collision
pair of H2 (), such as H2(Ppub , P I Di,t sj,k , M, R, ci, j,k ) =
H2(Ppub , P I Di,t sj,k , M  , R, ci, j,k ) (M = M  ). However, H2(),
the cryptographic hash function, is assumed to be secure
against collision attacks. Thus, our protocol provides message
integrity and source authentication.
B. Conditional Privacy Preservation
• Anonymity and unlinkability
Anonymity: In our protocol, each vehicle uses its own
pseudo-identities to sign beacon and report messages.
1 Given two points, P and x P, on an elliptic curve E, find x, where x ∈
Z ∗ p, and p is a large prime order in E.
1074 IEEE TRANSACTIONS ON INTELLIGENT TRANSPORTATION SYSTEMS, VOL. 19, NO. 4, APRIL 2018
For example, Vi uses PIDti,wj = TW j ||E t k (IDVi ⊕
RVi, j )||RVi, j and PIDti,sj,k = TS j,k ||E t k (IDVi ⊕
RVi, j,k )||RVi, j,k . Because PIDti,wj and PIDti,sj,k reveal no
information related to true identity, neighboring vehicles
and RSUs cannot learn the true identity from periodic
beacon and report messages. If an adversary wants to
obtain the identity from pseudo-identities, he/she would
need to decrypt E t k (IDVi ⊕ RVi, j ) or E t k (IDVi ⊕ RVi, j,k ).
However, it is difficult for the adversary to obtain IDVi
from PIDti,wj or PIDti,sj,k , because the encryption key tk is
the secret value of TA, and the encryption algorithm E()
(e.g., AES) is assumed to be secure against cryptanalysis.
Unlinkability: In our protocol, an eavesdropper can only
link PIDti,sj,k during T S j,k , because vehicles use different
pseudo-identities at every time slot. Even though RSUs
are compromised, the adversary only links PIDti,wj during
T W j . If the adversary wants to link pseudo-identities,
he/she must find relations such as RVi, j → RVi, j +1
or RVi, j,k → RVi, j,k+1 . However, it is difficult to
compute RVi, j +1 = H3,R K Vi (RVi, j ) or RVi, j,k+1 =
H3,R K Vi (RVi, j,k ) without RK i ; RK i is securely managed
by the TA.
• Conditional traceability and linkability
In dispute cases, such as a liability investigation or
misbehaving node tracking, the TA is able to trace the
real identity of a vehicle Vi using tk, as follows:
PIDti,wj → Dt k (E t k (IDVi ⊕ RVi, j )) ⊕ RVi, j = IDVi
PIDti,sj,k → Dt k (E t k (IDVi ⊕ RVi, j,k )) ⊕ RVi, j,k = IDVi .
(5)
In addition, the TA can link the pseudo-identities of
vehicle Vi using RK Vi , as follows:
PIDti,wj → PIDti,wj +1 (RVi, j +1 = H3,R K Vi (RVi, j ))
PIDti,sj,k → PIDti,sj,k+1 (RVi, j,k+1 = H3,R K Vi (RVi, j,k )).
(6)
C. Revocation
• Revocation for V2I communication
To support revocation for V2I communication, our proto-
col periodically distributes revocation lists to the RSUs.
For example, a revocation list at T W j includes revoked
information RVi, j −δ and RVi, j of PIDti,wj and RK Vi , if
Vi is revoked. Thus, the RSUs can check the revocation
status of a pseudo-identity using the revocation list.
• Revocation for V2V communication
In our protocol, a vehicle Vi performs the revocation
operation using MAC authentication. Because G K , which
is used for MAC generation, is distributed only to unre-
voked vehicles by the RSUs, the revoked vehicles cannot
generate valid MAC values for their messages.
In addition, we propose a secure G K update process to
exclude newly revoked vehicles that have received a G K
from the distribution of G K new . Our group key update
process satisfies the following properties:
Fig. 6. Example of road condition.
- Forward secrecy & resistance to colluding attack: If G K
is revealed by revoked vehicles, the RSUs perform a
group key update process. In the proposed key update,
an adversary cannot obtain G K new from an update mes-
sage because BU K ∗ and NU K ∗ , which are used for
the encryption of G K new , are only stored in unrevoked
vehicles. Even though revoked vehicles collude with each
other, they cannot obtain valid update keys used for the
encryption of G K new
D. Reliability
To provide efficient authentication, the protocols
in [17]–[19] and our protocol use a cooperative authentication
method. Cooperative authentication methods are divided into
two approaches. The first is the failure report-based approach,
which reports the indexes of invalid beacon messages. The
second is the success report-based approach, which reports
indexes of valid beacon messages. While the protocol in [17]
and our protocol periodically broadcast success reports to
provide verification results for valid beacon messages, the
studies in [18] and [19] broadcast failure reports whenever
the verification of a beacon message fails. In general, the
failure report-based approach has the following authentication
mode synchronization problem:
• Authentication mode synchronization: When a failure
report-based cooperative authentication method is used,
authentication mode synchronization can become an issue
due to unpredictable traffic. For example, as shown
in Fig. 6, vehicle A is set to use a cooperative authentica-
tion mode because the number of neighboring vehicles is
greater than a pre-defined threshold. However, vehicles B,
C, and D are set to use a non-cooperative authentication
mode because of the low traffic density. In this case,
vehicle A might not completely verify all messages,
because vehicles B, C, and D do not cooperate with
vehicle A. This method affects the reliability of VANETs,
because certain malicious messages without verification
could be considered valid.
JO et al.: RELIABLE COOPERATIVE AUTHENTICATION FOR VEHICULAR NETWORKS
Thus, we adopt the success report-based cooperative authenti-
cation method, where the authentication mode synchronization
problem can be solved because all vehicles report their results
to their neighboring nodes, and then verify uncovered mes-
sages by reports.
E. Availability
The protocols in [17]–[19] and our protocol can improve
the efficiency of the authentication by employing cooperative
authentication. Specifically, the protocols in [18] and [19] use
location information to evenly distribute the authentication
load. In these protocols, a receiver computes the distance to
the message senders using location information in the received
beacon message. Next, the receiver attempts to determine
whether it is the verifier of the message by comparing the
distance values of its neighbors. However, the verifier selection
algorithm based on location information can be exploited by a
modification attack on the location information. For example,
as shown in Fig. 6, vehicle D sends as many malicious
location messages to vehicle A as possible; it uses different
location information for each beacon message for its own
modified message to be selected as verification targets by
vehicle A. This attack can cause vehicle A to consume its own
computation power verifying malicious messages. Thus, this
modification attack can affect the availability of authentication
protocols of [18] and [19]. In contrast, our protocol and the
protocol in [17] are secure against modification attacks on
location information because these protocols randomly select
target messages for verification.
VI. P ERFORMANCE E VALUATION
In this section, we present the time required to perform
a point multiplication and a bilinear pairing operation on an
elliptic curve, and evaluate our protocol performance using
the Pairing-Based Cryptography Library (PBC) [40] and the
Network Simulator (NS2) [41]. We divide the performance
evaluation into three parts: 1) revocation, 2) group key distri-
bution and update, and 3) V2V communication authentication.
- Implementation
We implement a point multiplication and bilinear pairing
operation on an elliptic curve to measure the operation
time. Measurement is conducted on an Intel Core i5-2500
(at 3.3 GHz). In our implementation, the times required to
perform a point multiplication (Tmul ) and bilinear pairing
(T par ) operation on an elliptic curve are 1.95 ms and 22 ms,
respectively (using the Type F parameters of the PBC library).
Lightweight operations, such as the cryptographic hash func-
tion, are ignored, because they are negligible compared to the
measured operations.
A. Evaluation of Revocation Overhead
It is important to check a revocation list before verifying
signatures. This means that checking a revocation list must
also be performed efficiently.
Revocation using a group signature algorithm in [9] and [10]
requires 3 × n bilinear pairing operations if there are n revoked
1075
Fig. 7. Roadmap for simulation.
vehicles in the RL. The protocol of [18] using a different
group signature algorithm also requires 2 × n bilinear pair-
ing operations. According to our implementation result, their
revocation processes take roughly 11 minutes and 7.3 minutes,
respectively, if 10, 000 vehicles are revoked. In anonymous
authentication in [5], [6], and [17], revocation requires RL
management overhead because the size of the RL increases
linearly with both the number of pseudo-identities, which are
assigned one vehicle, and the number of revoked vehicles.
To remove the RL management overhead from vehicles, a self-
pseudonym generation method using a proxy re-signature
algorithm is proposed in [22]. Although this method does
not require that vehicles perform RL management, vehicles
should perform three bilinear pairing operations to check
revocation. Furthermore, RSUs should generate all revoked
pseudo-identities of a revoked vehicle at once. If a vehicle Vi
is revoked and it has l pseudo-identities, RL includes a 4-tuple
< n, m, Si,n
1 , S2
i,l−m+1 >, where n and m indicate the start and
end times of a revocation period for Vi , and Si,n1 and S 2
i,l−m+1
are the seed values used for generating Vi ’s revoked-identities.
Then, the RSUs should compute all pseudo-identities from n
to m, P I Di,k (n ≤ k ≤ m), in advance, because pseudo-
identities are calculated from P I Di,k = h(Si,k 1 ⊕ S2
i,l−k+1 ),
where Si,k = h (Si,n ) and Si,l−k+1 = h m−k (Si,l−m+1
1 k−n 1 2 2 )
(h() is a cryptographic hash function). In other words, since
2
Si,l−k+1 = h m−k (Si,l−m+1
2 ) is a reverse hash chain, computing
2
the first value of Si,l−n+1 requires computing all values of
2
Si,l−k+1 (n + 1 ≤ k ≤ m).
However, in our protocol, we use a group key based
revocation method, which only requires MAC operations for
checking revocation. In addition, our method can update a
revocation list by keyed-hash operations whenever an update is
needed. This does not require that the RSUs generate and store
all revoked pseudo-identities of a revoked vehicle in advance.
Thus, our method is more efficient than the existing methods
in [5], [6], [9], [10], [17], [18], [21] and [22].
B. Evaluation of Group Key Distribution and Update
- Group Key Distribution
In our protocol, the RSUs distribute the G K to non-revoked
vehicles in their own domains. To evaluate the performance
1076 IEEE TRANSACTIONS ON INTELLIGENT TRANSPORTATION SYSTEMS, VOL. 19, NO. 4, APRIL 2018
TABLE II
S IMULATION PARAMETERS
of the G K distribution, we analyze the computation and
communication overhead.
• Computation overhead
When a vehicle Vi receives Sig S K RSUi (T ||ID R SUi ) and
Cer t RSUi from RSUi , Vi verifies them. Then, Vi com-
putes a session key κ = t  T = t  t P and generates a
signature (T  = t  P, e = H2 (Ppub , P I Di,t wj , T  , T, ci, j ),
and π = t − esi, j ). According to [7], ECDSA signature
verification requires 2 Tmul . Consequently, the total com-
putation time of Vi is 6 Tmul .
RSUi also verifies a signature (ci, j,k and π) of Vi and
computes the session key κ = t T  = tt  P. Then, it gen-
erates an ECDSA signature on the distribution message
of G K (ECDSA signature generation requires 1 Tmul ).
Overall, 4 Tmul is required for RSUi to perform G K
distribution.
• Communication overhead
The flows of the group key distribution process are
composed of two messages; we do not consider the
first message from the RSU because this is a periodic
broadcast message. The total size of the two messages
is 1,976 bytes if we choose the AES-128 algorithm, the
Type F parameter of the PBC (160 bits element of G 1 ),
set the height (h) of the update tree to 14, and set the
chain length to 100. (The output length of H1(), H2(),
H3 (), and H4 () is set to 20 bytes.)
Based on the computation and communication overhead,
we evaluated the average computation time and end-to-end
transmission delay for different numbers of vehicles in the
communication range of the RSU. The road scenario and
parameters for the simulation are given in Fig. 7 and TABLE 2,
respectively. The simulation results for the transmission delay
of G K are shown in TABLE. III; this table shows that the
transmission delay is significantly shorter than the computation
delay. Through the simulation results, we find that RSUs
can distribute G K to one vehicle within roughly 39.2 ms,
even when there are 100 vehicles. (Computation time for
Vi = 23.4 ms, computation time for RSUi = 15.6 ms, and
average end-to-end delay ≈ 0.2 ms.) Because the computation
performed on the vehicles can be processed in parallel, we
estimate that all vehicles can receive G K within roughly 1.6 s
when 100 vehicles request G K from RSUi .
- Group Key Update
In the GK update, the update overhead of an RSU is deter-
mined by the number of revoked nodes that have received the
TABLE III
GK T RANSMISSION T IME ( MS )
previous GK from the RSU. If there is no revoked node, an
RSU performs one symmetric encryption operation such as
AES, and generates a digital signature for an update message.
In addition, a vehicle performs one symmetric decryption
operation and verifies the signature (we ignore the XOR
operation, which is a negligible operation compared to the
others). If there exist revoked nodes that have received the
previous G K from the RSU, the overhead of the RSU
increases linearly with the number of revoked nodes, while
the overhead of a vehicle is the same as the case in which
there is no revoked node.
The worst case overhead for an RSU is related to the
generation method of the update key-tree. According to [37],
ri +  NiC+ri  is the worst case scenario of disjoint intervals
of the C-basic chain scheme, which is used to generate the
update key-tree, where:
Ni : Total number of vehicles in the i th leaf node of the b-tree
ri : The number of revoked vehicles in the Ni
C: The length of the hash chain used to generate update keys
In the GK update, the worst case W of disjoint intervals is that
all revoked nodes are uniformly distributed in all leaf nodes
Ni of the b-tree. Thus, we can obtain the following equation
(h is the height of b-tree):
h

2
Ni + ri
W = (ri +  ). (7)
C
i=1
For example, provided that h = 10, C = 10, and Ni = 100,
ri = 1, (1 ≤ i ≤ 2h ), W is 11,264. This means that
an RSU performs 11,264 symmetric encryption operations
for 11,264 disjoint intervals. If the AES-128 algorithm is
used, the time required for 11,264 encryption on an i5-2500
(at 3.3GHz) is less than 500 ms, and the transmission size
is 176 kilobytes (KB).
C. Evaluation of Message Authentication
- Parameter Settings
To evaluate the message loss ratio, which originates from
the message authentication delay, suitable parameters for the
simulation should be set. Specifically, setting the verification
probability of beacon messages (Pv ) and the maximum number
of verified reports (N R ) is important for the evaluation of coop-
erative authentication. To find accurate values of Pv and N R ,
we analyze the probability that an arbitrary unverified message
is not covered by reports, based on the verification probabil-
ity Pv . Suppose that all vehicles of one domain receive an
identical beacon message set, and verify beacon messages with
Pv during BT , and N R reports during RT . The analytic
probability Pr a (A) can be represented as follows. (Let A be
JO et al.: RELIABLE COOPERATIVE AUTHENTICATION FOR VEHICULAR NETWORKS
Fig. 8. The probability of unverified messages versus the verification
probability of beacon message.
Fig. 9. The probability of un-verified messages versus the vehicle density
NB
(Pv = |M| , if N B ≥ |M|, Pv is set to 1, and |M| indicates the number of the
beacon messages generated during B T ).
the event that an arbitrary unverified message is not covered
by the reports.)
Pr a (A) = (1 − Pv ) N R . (8)
We plot Pr a (A) versus Pv and N R in Fig 9. This figure
shows that Pr a (A) is lower than 0.1 if Pv is set to 0.25 and
N R is set to 10 or 15. In addition, we set the minimum number
of verified messages N B to 25.2
However, vehicles might have slightly different message sets
because of their different communication ranges. Thus, we
also simulate the case in which all vehicles have different
message sets to obtain the simulated probability Pr s (A). In the
simulation, the beacon broadcast interval, BT , and RT are
set to 300 ms, 200 ms, and 100 ms, respectively. Here, Pr s (A)
can be represented as shown in equation (9):
No. o f uncover ed messages by r epor ts
Pr s (A) = .
No. o f messages not veri f i ed duri ng BT
(9)
2 We assume that the number of vehicles is 25 at low density [42], [43].
1077
Fig. 10. Message loss ratio versus the vehicle density.
Fig. 9 shows the relationships among Pr a (A), Pr s (A),
N B , N R , and vehicle density. This figure shows that Pr s (A)
is slightly higher than Pr a (A), because the vehicles cannot all
have the same beacon message set.
- Message Loss Ratio
We compared the message loss ratio of the non-cooperative,
the basic cooperative, and the delayed cooperative authenti-
cation methods using the parameters obtained from the above
simulation results. According to [7], each vehicle should verify
each message within 300 ms after reception in order to
respond to various road conditions as accurately and quickly
as possible. Thus, the average message loss ratio is defined as
the ratio of messages not processed within 300 ms after being
received.
Fig. 10 shows the average message loss ratio of the non-
cooperative, the basic cooperative [17], and the delayed coop-
erative authentication methods versus vehicle density. While
message losses occurred in the non-cooperative case, the basic
cooperative (BT = 200 ms, RT = 100 ms), and the
delayed cooperative (BT = 200 ms, RT = 100 ms)
authentication methods, the delayed cooperative authentication
method (BT = 100 ms, RT = 100 ms) can authenticate
all messages without message losses. From the simulation
results, we know that the decision on when to verify beacon
messages, generated during RT , is an important cause of
message losses, because RT is a short period in which to
verify both N R report messages and the new beacon messages.
Although setting BT to 100 ms requires that vehicles report
their verification results every 200 ms, this choice helps
vehicles to authenticate all beacon messages without message
losses.
D. Discussion
For fast message authentication of VANETs, several pro-
tocols have been proposed. Among them, the cooperative
authentication method is promising because VANET nodes
can share their computation power for the purpose of message
authentication. However, existing cooperative authentication
protocols in [17]–[19] have issues, as shown in Table IV.
1078 IEEE TRANSACTIONS ON INTELLIGENT TRANSPORTATION SYSTEMS, VOL. 19, NO. 4, APRIL 2018
TABLE IV
C OMPARISON OF C OOPERATIVE AUTHENTICATION P ROTOCOLS
According to Table IV, the protocols in [18] and [19] suf-
fer from the mode synchronization problem and location
modification attacks. In these protocols, RSUs can also link
vehicle’s pseudo-identities. Although the protocol in [17] does
not suffer from the mode synchronization problem or the
location modification attack, it does suffer from the revocation
management problem. The revocation management overhead,
which includes updating and sorting revocation lists, can be an
additional burden on vehicles, because every revoked vehicle
has a large set of pseudo-identities. In addition, the protocol
in [17] suffers packet losses when the vehicle density is
200/km 2, as shown in Fig. 11, because it does not provide
the delayed authentication mode. Thus, we believe that our
proposed protocol is an effective option for message authen-
tication in VANETs.
VII. C ONCLUSION
We proposed an anonymous message authentication proto-
col for the safe transmission of messages in VANETs. For
efficient authentication, we adopted a cooperative authenti-
cation technique. Although several cooperative authentication
protocols are based on failure reports for efficiency, we chose
the success report based on the cooperative authentication
method. The benefit of using the success report is that there is
no synchronization problem between the non-cooperative and
cooperative modes. Using a security analysis and simulation,
we find that our protocol does not require mode synchroniza-
tion, nor does it result in message losses, even when the vehicle
density is set to 200/km 2 . In addition, we can reduce the over-
head of RL management using two-layered pseudo-identities.
Furthermore, we presented a key management architecture for
efficient revocation. Using a binary tree and an n-ary tree can
reduce the transmission size of update messages for a new
group key. In future, we will design a novel key management
framework, including self-healing functionality to preserve the
success of group key updates, even when there are vehicles
that miss the update messages.
R EFERENCES
[1] Dedicated Short Range Communications (DSRC) Home, accessed on
Jun. 13, 2017. [Online]. Available: http://www.its.dot.gov/dsrc/
[2] H. Alshaer and E. Horlait, “Emerging client-server and ad-hoc approach
in inter-vehicle communication platform,” in Proc. IEEE 60th Veh.
Technol. Conf. (VTC-Fall), vol. 6. Sep. 2004, pp. 3955–3959.
[3] H. Alshaer and E. Horlait, “An optimized adaptive broadcast scheme for
inter-vehicle communication,” in Proc. IEEE 61th Veh. Technol. Conf.
(VTC-Fall), vol. 5. May 2005, pp. 2840–2844.
[4] H. Alshaer, “Securing vehicular ad-hoc networks connectivity with road-
side units support,” in Proc. IEEE 8th GCC Conf. Exhibit. (GCCCE),
Feb. 2015, pp. 1–6.
[5] G. Calandriello, P. Papadimitratos, J.-P. Hubaux, and A. Lioy, “Efficient
and robust pseudonymous authentication in VANET,” in Proc. 4th
ACM Int. Workshop Veh. Ad Hoc Netw., New York, NY, USA, 2007,
pp. 19–28.
[6] C. D. Jung, C. Sur, Y. Park, and K.-H. Rhee, “A robust conditional
privacy-preserving authentication protocol in VANET,” in Security and
Privacy in Mobile Information and Communication Systems (Lecture
Notes of the Institute for Computer Sciences, Social Informatics and
Telecommunications Engineering), vol. 17. Berlin, Germany: Springer,
2009, pp. 35–45.
[7] A. Wasef and X. Shen, “EMAP: Expedite message authentication
protocol for vehicular ad hoc networks,” IEEE Trans. Mobile Comput.,
vol. 12, no. 1, pp. 78–89, Jan. 2013.
[8] P. Vijayakumar, M. Azees, A. Kannan, and L. J. Deborah, “Dual authen-
tication and key management techniques for secure data transmission in
vehicular ad hoc networks,” IEEE Trans. Intell. Transp. Syst., vol. 17,
no. 4, pp. 1015–1028, Apr. 2016.
[9] X. Lin, X. Sun, P.-H. Ho, and X. Shen, “GSIS: A secure and privacy-
preserving protocol for vehicular communications,” IEEE Trans. Veh.
Technol., vol. 56, no. 6, pp. 3442–3456, Nov. 2007.
[10] L. Zhang, Q. Wu, A. Solanas, and J. Domingo-Ferrer, “A scalable
robust authentication protocol for secure vehicular communications,”
IEEE Trans. Veh. Technol., vol. 59, no. 4, pp. 1606–1617, May 2010.
[11] L. Zhang, Q. Wu, B. Qin, J. Domingo-Ferrer, and B. Liu, “Practical
secure and privacy-preserving scheme for value-added applications in
VANETs,” Comput. Commun., vol. 71, pp. 50–60, Nov. 2015.
[12] F. Wang, Y. Xu, H. Zhang, Y. Zhang, and L. Zhu, “2FLIP: A
two-factor lightweight privacy-preserving authentication scheme for
VANET,” IEEE Trans. Veh. Technol., vol. 65, no. 2, pp. 896–911,
Feb. 2016.
[13] P. Vijayakumar, M. Azees, and L. J. Deborah, “CPAV: Computation-
ally efficient privacy preserving anonymous authentication scheme for
vehicular ad hoc networks,” in Proc. IEEE 2nd Int. Conf. Cyber Secur.
Cloud Comput., Nov. 2015, pp. 62–67.
[14] Y. Jiang, M. Shi, X. Shen, and C. Lin, “BAT: A robust signature scheme
for vehicular networks using binary authentication tree,” IEEE Trans.
Wireless Commun., vol. 8, no. 4, pp. 1974–1983, Apr. 2009.
[15] C. Zhang, X. Lin, R. Lu, and P.-H. Ho, “RAISE: An efficient RSU-aided
message authentication scheme in vehicular communication networks,”
in Proc. ICC, May 2008, pp. 1451–1457.
[16] J. Shao, X. Lin, R. Lu, and C. Zuo, “A threshold anonymous authenti-
cation protocol for VANETs,” IEEE Trans. Veh. Technol., vol. 65, no. 3,
pp. 1711–1720, Mar. 2016.
[17] X. Lin and X. Li, “Achieving efficient cooperative message authentica-
tion in vehicular ad hoc networks,” IEEE Trans. Veh. Technol., vol. 62,
no. 7, pp. 3339–3348, Sep. 2013.
[18] Y. Hao, Y. Cheng, C. Zhou, and W. Song, “A distributed key manage-
ment framework with cooperative message authentication in VANETs,”
IEEE J. Sel. Areas Commun., vol. 29, no. 3, pp. 616–629, Mar. 2011.
[19] X. Zhu, S. Jiang, L. Wang, and H. Li, “Efficient privacy-preserving
authentication for vehicular ad hoc networks,” IEEE Trans. Veh.
Technol., vol. 63, no. 2, pp. 907–919, Feb. 2014.
[20] M. Raya and J.-P. Hubaux, “Securing vehicular ad hoc networks,”
J. Comput. Secur., vol. 15, no. 1, pp. 39–68, 2007.
[21] H. J. Jo, J. H. Paik, and D. H. Lee, “Efficient privacy-preserving authen-
tication in wireless mobile networks,” IEEE Trans. Mobile Comput.,
vol. 13, no. 7, pp. 1469–1481, Jul. 2014.
[22] Y. Sun, R. Lu, X. Lin, X. Shen, and J. Su, “An efficient pseudony-
mous authentication scheme with strong privacy preservation for vehic-
ular communications,” IEEE Trans. Veh. Technol., vol. 59, no. 7,
pp. 3589–3603, Sep. 2010.
[23] P. Vijayakumar, S. Bose, and A. Kannan, “Improved HARN batch digital
signature algorithm for multicast authentication,” J. Discrete Math. Sci.
Cryptography, vol. 17, nos. 5–6, pp. 435–442, 2014.
[24] W. Du and M. He, “Self-healing key distribution with revocation and
resistance to the collusion attack in wireless sensor networks,” in
Provable Security (Lecture Notes in Computer Science), vol. 5324,
J. Baek, F. Bao, K. Chen, and X. Lai, Eds. Berlin, Germany: Springer,
2008, pp. 345–359.
JO et al.: RELIABLE COOPERATIVE AUTHENTICATION FOR VEHICULAR NETWORKS
[25] P. Vijayakumar and M. Azees, “CEKD: Computationally efficient key
distribution scheme for vehicular ad-hoc networks,” Austral. J. Basic
Appl. Sci., vol. 10, no. 2, pp. 171–175, 2016.
[26] P. Vijayakumar, S. Bose, and A. Kannan, “Chinese remainder theorem
based centralised group key management for secure multicast commu-
nication,” Inf. Secur., vol. 8, no. 3, pp. 179–187, May 2014.
[27] P. Vijayakumar, S. Bose, and A. Kannan, “Centralized key distribution
protocol using the greatest common divisor method,” Comput. Math.
Appl., vol. 65, no. 9, pp. 1360–1368, 2013.
[28] A. Peinado, Flaws in the Application of Number Theory in Key Distri-
bution Schemes for Multicast Networks. Cham, Switzerland: Springer,
2016, pp. 181–187.
[29] M. Azees, P. Vijayakumar, and L. J. Deborah, “Comprehensive survey
on security services in vehicular ad-hoc networks,” IET Intell. Transp.
Syst., vol. 10, no. 6, pp. 379–388, 2016.
[30] L. Zhang, C. Hu, Q. Wu, J. Domingo-Ferrer, and B. Qin, “Privacy-
preserving vehicular communication authentication with hierarchical
aggregation and fast response,” IEEE Trans. Comput., vol. 65, no. 8,
pp. 2562–2574, Aug. 2016.
[31] U. Khan, S. Agrawal, and S. Silakari, “A detailed survey on misbehavior
node detection techniques in vehicular ad hoc networks,” in Information
Systems Design and Intelligent Applications, vol. 339. New Delhi, India:
Springer, 2015, pp. 11–19.
[32] N. Kumar and N. Chilamkurti, “Collaborative trust aware intelligent
intrusion detection in VANETs,” Comput. Electr. Eng., vol. 40, no. 6,
pp. 1981–1996, 2014.
[33] K. Kostiainen, N. Asokan, and J.-E. Ekberg, “Practical property-based
attestation on mobile devices,” in Trust Trustworthy Computing (Lecture
Notes in Computer Science), vol. 6740, J. M. McCune, B. Balacheff,
A. Perrig, A.-R. Sadeghi, A. Sasse, and Y. Beres, Eds. Berlin, Germany:
Springer, 2011, pp. 78–92.
[34] W. Xu, X. Zhang, H. Hu, G.-J. Ahn, and J.-P. Seifert, “Remote attestation
with domain-based integrity model and policy analysis,” IEEE Trans.
Depend. Sec. Comput., vol. 9, no. 3, pp. 429–442, May 2012.
[35] A. Studer, E. Shi, F. Bai, and A. Perrig, “TACKing together effi-
cient authentication, revocation, and privacy in VANETs,” in Proc.
6th Annu. IEEE Commun. Soc. Conf. Sensor, Mesh Ad Hoc Commun.
Netw. (SECON), Jun. 2009, pp. 1–9.
[36] Q. Wang, P. Fan, and K. B. Letaief, “On the joint V2I and V2V
scheduling for cooperative VANETs with network coding,” IEEE Trans.
Veh. Technol., vol. 61, no. 1, pp. 62–73, Jan. 2012.
[37] J. H. Cheon, N. S. Jho, M. H. Kim, and E. S. Yoo, “Skipping, cascade,
and combined chain schemes for broadcast encryption,” IEEE Trans.
Inf. Theory, vol. 54, no. 11, pp. 5155–5171, Nov. 2008.
[38] R. W. Zhu, G. Yang, and D. S. Wong, “An efficient identity-based key
exchange protocol with KGS forward secrecy for low-power devices,”
Theor. Comput. Sci., vol. 378, no. 2, pp. 198–207, 2007.
[39] P. Vijayakumar, S. Bose, and A. Kannan, “Rotation based secure
multicast key management for batch rekeying operations,” Netw. Sci.,
vol. 1, no. 1, pp. 39–47, 2012.
1079
[40] PBC (Pairing-Based Cryptography) Library, accessed on Jun. 13, 2017.
[Online]. Available: http://crypto.stanford.edu/pbc/
[41] The Network Simulator—NS-2, accessed on Jun. 13, 2017. [Online].
Available: http://www.isi.edu/nsnam/ns/
[42] M. Boban, G. Misek, and O. K. Tonguz, “What is the best achievable
QoS for unicast routing in VANETs?” in Proc. IEEE GLOBECOM
Workshops, Nov. 2008, pp. 1–10.
[43] H. J. Huang and J. Wang, “Vehicle density based forwarding protocol
for safety message broadcast in VANET,” Sci. World J., vol 2014,
Art. no. 584164, Jul. 2014.
Hyo Jin Jo received the B.S. degree in indus-
trial engineering and the Ph.D. degree in informa-
tion security from Korea University, Seoul, South
Korea, in 2009 and 2016, respectively. He is a
Post-Doctoral Researcher with the Department of
Computer and Information System, University of
Pennsylvania, Philadelphia, PA, USA. His research
interests include cryptographic protocols in authen-
tication, applied cryptography, security and privacy
in ad hoc networks, and smart car security.
In Seok Kim received the B.S. degree in computer
science from Hongik University, Seoul, in 1973;
the M.S. degree in information security from the
Graduate School of Information Security, Dong Guk
University, Seoul, in 2003; and the Ph.D. degree
in information security from the Graduate School
of Information Security, Korea University, in 2008.
He is a Professor with the Graduate School of
Information Security, Korea University. His research
interests include security information in electronic
financial services.
Dong Hoon Lee (F’06) received the B.S. degree
from the Department of Economics, Korea Univer-
sity, Seoul, in 1985, and the M.S. and Ph.D. degrees
in computer science from University of Oklahoma,
Norman, in 1988 and 1992, respectively. He is a
Professor with the Graduate School of Information
Security, Korea University. His research interests
include the design and analysis of cryptographic
protocols.