IEEE TRANSACTIONS ON SMART GRID, VOL. 2, NO.

4, DECEMBER 2011 707

UBAPV2G: A Unique Batch Authentication Protocol

for Vehicle-to-Grid Communications
Huaqun Guo, Senior Member, IEEE, Yongdong Wu, Feng Bao, Hongmei Chen, and Maode Ma

Abstract—“Vehicle-to-grid” (V2G) power will be a new green

energy scheme in which electric or plug-in hybrid vehicles com-
municate with the smart grid to sell demand response services
by either delivering electricity into the grid or by throttling their
charging rate. Due to high vehicular speed, sporadic connection,
limited communication range, and large volume of data that
need to be transmitted, V2G communications have the crucial
requirements of fast authentication and encryption/decryption.
This paper proposes a unique batch authentication protocol
UBAPV2G that takes into account the characteristics of vehicle
communication. The performance analysis shows that UBAPV2G
can achieve less authentication delay, less computational cost,
and less communication traffic, and security analysis shows that
UBAPV2G is strong enough to defend against security attacks.
The experimental results also demonstrate that UBAPV2G can
achieve less authentication delay for large number of packets.
Thus, UBAPV2G protocol is suitable for the stringent requirement
of real time V2G communications.
Index Terms—Communication, power control, protocols, secu-
rity, vehicles. Fig. 1. System block diagram for V2G.

I. INTRODUCTION
of the time, their batteries could be used to let electricity flow

V EHICLE-TO-GRID (V2G) describes a system in which

electric or plug-in hybrid vehicles communicate with the
smart grid to sell demand response services by either delivering
electricity into the grid or by throttling their charging rate [1],
[2]. For example, electric vehicles (EVs) have the energy source
within them and power electronics capable of producing the 60
Hz AC electricity that can be used to power offices and homes.
V2G power will be a new scheme that adds the connections
to allow this electricity to flow from vehicles to power lines.
Vehicles pack a lot of power and one typical EV can put out
over 10 kW, the average draw of 10 houses [3].
For the proper operation of the grid, generation must be con-
tinuously matched with load. A mismatch causes the grid fre-
quency to deviate from the desired nominal operating point of
60 Hz. The power grid operator must continuously fine-tune
the balance between the generation of power and consumption
(load). Regulation is used for the last bit of fine turning needed
to balance generation, load and interchanges, and is continu-
ously calculated and dispatched by the smart grid control center.
V2G will enable EVs or hybrid EVs with battery to plug into the
power grid. Since most vehicles are parked an average of 95%
Manuscript received October 15, 2010; revised April 14, 2011; accepted
June 05, 2011. Date of publication November 09, 2011; date of current version
November 23, 2011. Paper no. TSG-00179-2010.
H. Q. Guo, Y. D. Wu and F. Bao are with Institute for Infocomm Research,
A*STAR, Singapore 138632 (e-mail: guohq@i2r.a-star.edu.sg; wydong@i2r.a-
star.edu.sg; baofeng@i2r.a-star.edu.sg).
H. M. Chen and M. D. Ma are with Nanyang Technological University, Sin-
gapore (e-mail: CHEN0489@e.ntu.edu.sg; Maode_Ma@pmail.ntu.edu.sg).
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/TSG.2011.2168243
from the vehicles to the power lines and back. The ability of
the V2G car’s battery to act like a sponge provides a solution
for utilities. Currently, utilities pay million dollars to generating
stations that help balance the grid. It is estimated that the value
for utilities of using a car’s battery instead could be up to $4000
a year per car [4], [5]. Thus, V2G will greatly reduce the cost to
balance the grid.
The scenario of V2G is shown in Fig. 1. EVs are equipped
with a bidirectional grid power interface and wireless connec-
tivity, allowing power flow to or from the EVs. An aggregator is
developed to represent a middleman between the control center
and EVs. The control center monitors the real-time power gen-
eration and load. If it discovers the mismatch between them ex-
ceeds a threshold, the control center will send the electricity re-
quirement to the aggregators. Each aggregator will then send out
messages to call the EVs within a certain distance. The EVs will
respond to the aggregator if EVs want to take action according
to the electricity requirement, i.e., selling back the electricity
to the power grid or charging the battery. As shown in Fig. 1,
the wireless communications will involve the aggregator, EVs,
and the control center. Global positioning system (GPS) signals
from satellites are used to determine the location of EVs and
guide the EVs to charging/discharging stations.
Power regulation is procured for each hour of the day as
power capacity can ramp up and down from a nominal genera-
tion level. Thus, the EVs must respond promptly to power com-
mands and arrive at the charging/discharging station in time.
Only the validated EVs with right power frequency and temper-
ature are allowed to plug into the grid.
Information from the smart grid control center to the aggre-
gator includes power commands, charging rate and time, and
so on. Information from the aggregator to vehicles includes

1949-3053/$26.00 © 2011 IEEE

708
power commands, charging rate and time, charging/discharging
station location, off-board chargers in the EV supply equipment
(EVSE), etc., while the information from the aggregator to the
control center may include number of EVs in charging/dis-
charging station, charging/discharging station location, charge
start time and end time, charge level kW, etc.
The responding information from a vehicle includes vehicle
ID, vehicle type, battery state-of-charge, temperature (too hot
is not wanted), frequency ( 58 HZ is not wanted), user prefer-
ence (discharge time, charged time, power discharged/charged
by 10%, 20%, or 50%), vehicle location, vehicle speed (how
fast to plug in), driving pattern/history (very sensitive informa-
tion), cordset type in EV, metering data for actual power flow
(demand/supply, e.g. charging/discharging time, current, utility
power rates, etc.), and charging station location ID, while re-
quests from vehicles may be, for example, arrive at 6 P.M. and
want to immediate charge and leave at 7 P.M., or arrive home at
7 P.M. and could be used for grid regulation.
From the above, it is clear that a lot of information is ex-
changed among the control center, the aggregator and vehicles.
Thus, the security requirements consist of source authentication,
message integrity, replay attack resistance, privacy protection,
etc.
Unlike other communication networks, the V2G communica-
tion has its own characteristics that the vehicular network dif-
fers in size, vehicular speed, as well as relevance of their ge-
ographic positions. Due to high vehicular speed, sporadic con-
nection, limited communication range, and large volume of data
that need to be transmitted, V2G communications have the cru-
cial requirements of fast authentication and encryption/decryp-
tion. Thus, the unique authentication scheme will be researched,
developed and evaluated so as to meet the stringent requirement
of real time V2G communications.
In this paper, we propose and design a unique batch authen-
tication protocol for V2G communications (UBAPV2G) that
takes into account the characteristics of vehicle communica-
tions. The main idea is that instead of verifying each packet for
each individual vehicle, the aggregator waits for an interval time
to receive the multiple responses from a batch of vehicles. The
aggregator then verifies the received batch of packets with only
one signature verification, and then broadcasts a signed confir-
mation packet to inform the batch of vehicles with only one sig-
nature. After that, the aggregator processes the next batch of
packets received. The aggregator repeats this procedure until it
finishes the power command.
The rest of the paper is organized as follows. Section II de-
scribes the related work. Section III introduces our design of
UBAPV2G authentication protocol, while Section IV analyzes
the V2G system to show the advantages of UBAPV2G. The
security analysis of UBAPV2G is described in Section V and
the experimental results are presented in Section VI. Finally,
Section VII draws our conclusions.
II. RELATED WORK
A. V2G
In 1995, Amory Lovins first proposed grid power from fuel
cell EVs; in 1997, Kempton and Letendre presented a paper
on vehicle-to-grid; in 2000, Nissan filed a patent of Household
Power Supply Using EV; and DaimlerChrysler and the Electric
Power Research Institute (EPRI) in 2001 and General Motors
IEEE TRANSACTIONS ON SMART GRID, VOL. 2, NO. 4, DECEMBER 2011
Fig. 2. Format of a signed message.
(GM) in 2002 proposed to use cars to power homes, stationary
power, or as power source [6]. In 2002 and 2003, AC Propul-
sion presented its demonstration projects of grid regulation an-
cillary service with a battery electric vehicle [7] and develop-
ment and evaluation of a plug-in HEV (hybrid EV) with ve-
hicle-to-grid power flow [8]. A V2G project at the University
of Delaware has been conducting ongoing research with goals
to educate about the environmental and economic benefits of
V2G and enhance the product market [3], [5]. In 2010, EPRI and
GM collaborated on a project of exchanging off-peak charging
and demand response information between smart grid and EVs
[9]. Other research institutes and companies are the Pacific Gas
& Electric Company, Google, Xcel Energy, the National Re-
newable Energy Laboratory, and the University of Warwick [5],
[10]. Those projects mainly focus on grid regulation, business
model, and power electronics. They pay little or no attention on
requirements of real-time and information security. According
to IOActive researchers, the smart grid could be taken down by
a cyberattack [11] that could allow hackers to access the net-
work and cut power.
B. Vehicle Communication Standard
In the area of vehicle communication, Dedicated Short Range
Communication (DSRC) is a short to medium range wireless
protocol specifically designed for automotive use. It supports
both public safety and private operations for vehicle-to-infra-
structure (V2I) and vehicle-to-vehicle (V2V) communication
environments. DSRC is a complement to cellular communi-
cations by providing very high data transfer rates in circum-
stances where minimizing latency in the communication link
and isolating relatively small communication zones are impor-
tant [12]. The DSRC standards and communication stack in-
clude IEEE 802.11p and IEEE 1609—Family of Standards for
Wireless Access in Vehicular Environments (WAVE) [13], [14].
IEEE 802.11p is a draft amendment to the IEEE 802.11 standard
to add wireless access in the vehicular environment. This tech-
nology is working in the 5.9 GHz band (United States and Eu-
rope) or 5.8 GHz band (Japan). The WAVE standards define an
architecture and a complementary, standardized set of services
and interfaces that collectively enable secure vehicular wireless
communications. The IEEE 1609 Family of WAVE Standards
consists of IEEE P1609.1—Resource Manager, IEEE P1609.
2—Security Services for Applications and Management Mes-
sages, IEEE P1609.3—Networking Services, and IEEE P1609.
4—Multi-Channel Operations [15].
In IEEE 1609.2, to authenticate a message’s sender and
achieve the message’s integrity, onboard units (OBUs) and road
side units (RSUs) should sign the messages with their private
keys before sending the messages. The format of a signed
message is shown in Fig. 2, where a 69-byte message attached
with a 125-byte certificate and a 56-byte Elliptic Curve Digital
Signature Algorithm (ECDSA) signature [16].
GUO et al.: UBAPV2G: A UNIQUE BATCH AUTHENTICATION PROTOCOL FOR VEHICLE-TO-GRID COMMUNICATIONS 709

TABLE I 3) checking whether

LIST OF PARAMETERS FOR SIGNATURE VERIFICATION

If the above is valid, then the signature is verified.

D. Batch Verification
References [18]–[24] use an efficient cryptographic primitive
called batch signature, which supports simultaneously verifying
the signature of any number of packets. The batch signature is
suitable for a same source (same sender) to sign a batch packets
using the same private key. For example, a DSA batch verifi-
cation protocol is proposed in [18], in which the signer gener-
ates signatures through interactions with the verifier, and then
the verifier validates these signatures at one time based on
the batch verification criterion. Another secure interactive batch
verification protocol is proposed in [19], which works correctly
by grouping the same base terms together, and then adding the
Our scheme will comply with the above DSRC standard. exponent terms together. Thus, it also means using the same pri-
However, in IEEE 802.11P, the theoretical communication vate key (same sender) to sign a batch of packets. In addition,
range is 1000 m. Because of the dynamic characteristics of this scheme requires a pre-computation for the whole batch of
vehicle with high speed, the connection time between the ve- signatures, and hence it is inefficient in the case of V2G com-
hicle and the aggregator is very short. Thus, the characteristics munication.
of vehicle communication will be taken into consideration to One of DSA variant is proposed in [20] to process batch
design the unique authentication protocol between the vehicles verification. It works correctly if it groups the same base terms
and the aggregator. together and add the exponent terms together. This scheme also
increases the modular exponential calculations and multiplica-
C. DSA Signature tions, which largely increases the authentication time. Another
We use DSA signature [17] for the batch authentication. multiple DSA-type digital signatures authentication scheme
Some parameters are defined as in Table I. proposed in [21] is not the interactive scheme. However, this
Before sending a message , a vehicle generates a signature batch verification scheme cannot be true if it groups the same
by: base terms together and add the exponent terms together, which
1) selecting a random integer with ; means the batch verification process will never hold true in this
2) computing case.
There are also some work reported in the area of signature
aggregation that they aggregate the signatures along a tree to-
ward the root [25], or aggregate signature along a chain [26].
3) computing The topic of secure aggregation in vehicular ad hoc networks
(VANETs) in [27] presents concatenated signatures, onion sig-
natures, and hybrid signatures which are suitable for message
4) computing aggregation and group communications.
The characteristic of V2G communications is different from
the above work. In the V2G communications, the vehicles di-
rectly communicate with the aggregator without forming a tree
When computing , the string obtained from shall be or a group so as to meet the stringent requirement of real time
converted to an integer. communications. In addition, the transmitted packets may be
Thus, the signature for is . from the different vehicles, or may be from the same vehicle
After the aggregator receives the packet with signature, it can if this vehicle has more information to inform the aggregator
verify the signature by three steps: and hence packetizes the information into multiple packets. In
1) checking whether and ; If either con- other words, the senders of packets can be different or can be
dition is violated, the signature shall be rejected as invalid. the same. Therefore, we need to design the unique batch au-
If valid, go to next step. thentication protocol which is suitable for V2G communica-
2) computing tions. In our previous work [28], we proposed a secure wire-
less communication platform for EV-to-grid research in which
we used a hybrid authentication protocol to authenticate mes-
sages one-by-one. In this paper, we address the authentication
issue using the batch authentication technique with the aim to
improve the performance.
710
III. UBAPV2G PROTOCOL
A. Generic Construction
As is well known that existing digital signature algorithms
are computationally expensive, the straightforward approach of
verifying each packet and signing a confirmed packet individu-
ally raises a serious overhead for the critical time requirement
of V2G communications.
UBAPV2G uses a unique batch authentication protocol,
which supports simultaneously verifying the signature of a
batch of packets. In particular, when the aggregator receives
packets: , , where is the data
payload, is the corresponding signature, and is a positive
number. We can then put them into an algorithm
If the output is , the aggregator knows that the packets
are authentic, and otherwise not.
B. Batch Authentication Technique With UBAPV2G
Since the reviewed batch verification algorithms are not suit-
able, we modified the DSA algorithm to make the batch verifi-
cation scheme suitable for V2G communication.
The signature of a message is computed according to the
following equations:
In our UBAPV2G batch authentication scheme, after re-
ceiving a batch of packets
aggregator verifies their signatures with only one signature
verification by:
1) checking whether and ; If either con-
dition is violated, the signature shall be rejected as invalid.
If valid, go to next step.
2) computing
3) checking whether
If the above is valid, then the signature is verified.
We can simplify the left side as
From (1), we can know that the UBAPV2G batch authen-
tication protocol only do times of addition operation,
time of power operation, and times of multiplication
IEEE TRANSACTIONS ON SMART GRID, VOL. 2, NO. 4, DECEMBER 2011
operation. For one-by-one authentication, the aggregator veri-
fies the signature one packet by one packet. Thus, it needs to
do times of power operation and times of multiplication
operation for packets. Therefore, the UBAPV2G batch au-
thentication protocol reduces the computational time since the
time consuming with power operation is bigger than that with
addition operation.
If one packet in the batch is not valid, then the batch protocol
will verify the signatures for half batch of packets first, then 1/4
batch, then 1/8 batch In the end, the aggregator will find out
the invalid packet. In our design, we assume that the invalid
packets are very rare.
C. UBAPV2G Protocol
The detail of UBAPV2G protocol is illustrated in Fig. 3 and
is elaborated below. In our scheme, all parties share a common
trust point in that they both use the same certificate authority to
have their certificates signed. In the following procedure, is
the message concatenation operation, which appends in a spe-
cial format; and are to encrypt or decrypt the
message using the public key and the private key re-
spectively; and is cipher text.
1) The aggregator forms a power command according
to electricity requirement, generates a signature for
according to DSA signature, attaches its certificate
and then broadcasts it via a concatenated message:
to call the EVs within a certain distance.
2) A nearby vehicle receives the message, verifies the at-
tached certificate and then uses the aggregator’s public key
which is in the attached certificate to verify the aggre-
gator’s signature and confirm that the message is from the
aggregator.
, the 3) The vehicle collects its real-time information that the
aggregator needs together with the timestamp , gen-
erates a signature according to DSA signature and at-
taches its certificate , encrypts it using the aggregator’s
public key , and finally sends it to the aggregator
The encryption is used to protect the sensitive information
and privacy of the vehicle, while the timestamp is
used to prevent replay attack.
4) The aggregator receives the first responding Packet 1 from
the vehicle and decrypts it
5) Steps 2 to 3 are repeated by vehicles who respond to the
aggregator’s call.
Step 4 is repeated by the aggregator to receive packets from
the responding vehicles. Within the interval time, the ag-
gregator receives the last responding Packet , and the ag-
gregator decrypts it using its private key
(1)
6) When the aggregator waits for the interval time to receive
a batch of packets, the aggregator also verifies the signa-
tures starting from the first packet, which means during
GUO et al.: UBAPV2G: A UNIQUE BATCH AUTHENTICATION PROTOCOL FOR VEHICLE-TO-GRID COMMUNICATIONS
Fig. 3. Illustration of the batch authentication protocol.
the interval time, the aggregator does the same way as
one-by-one authentication. (Note: in the performance anal-
ysis of the next session, we will not include this because it
is the same as one-by-one authentication.)
7) After the interval time, the aggregator uses the batch au-
thentication technique, which is described in the previous
subsection, to authenticate the batch of remainder packets,
which are received in its buffer. After the aggregator vali-
dates that the vehicle’s responding information is suitable
for power requirement, it generates a confirmation packet
and its signature . Finally, the aggregator broad-
casts the signed confirmation packet to inform the batch of
vehicles to go to a targeted discharging/charging station.
8) The aggregator processes the next batch of packets until it
finishes the power command.
In the scheme, the interval time can be tuned so that the ar-
rived vehicles can receive the response within the reasonable
delay.
IV. PERFORMANCE ANALYSIS OF V2G SYSTEM
A. Analysis of a Basic V2G System
Based on 8 lanes, 1000 m of theoretical communication range
with DSRC protocol, and the assumed 5 m occupying space of
a vehicle, we obtain the maximum number of vehicles within
the communication range of the aggregator as 3200. Thus, the
queue delay of signature verification is worthy to be explored.
In this section, we present a mathematical model to analyze a
basic V2G system.
The operation of the V2G can be described as follows. When
a vehicle responds the power command from the aggregator, it
signs a corresponding packet with its signature, encrypts it using
the public key of the aggregator, and then sends it to the aggre-
gator. After the aggregator receives the packet, it decrypts the
packet using its private key, verifies the vehicle’s signature and
validates the power status of vehicle, then generates a confir-
mation packet and signs it with its signature, and finally sends
the signed confirmation packet to inform that vehicle to go to a
targeted discharging/charging station. The aggregator processes
the packets from vehicles on the first-come first-service base.
If there are many vehicles respond to the aggregator’s call, the
711
responding packets from vehicles will form a queue in the in-
coming buffer of the aggregator. Then, the aggregator receives
and decrypts one packet from its incoming queue, and then pro-
cesses the packet (verify, validate, generate, sign, and send).
We assume that the arrival process of vehicles are indepen-
dent Poisson with rate . So our analysis model is similar to
an M/G/1 queuing system for reservations and polling [29].
One typical example of reservation and polling is a communi-
cation channel that can be accessed by several spatially sepa-
rated users; however, only one user can transmit successfully
on the channel at any one time. The communication resource
of the channel can be divided over time into a portion used for
packet transmissions and another portion used for reservation
or polling messages that coordinate the packet transmissions. In
other words, the time axis is divided into data intervals, where
actual data are transmitted, and reservation intervals, used for
scheduling future data.
In our V2G system, the aggregator’s receiving and decrypting
interval is similar to the reservation interval and the packet pro-
cessing interval is similar to the data interval in reservations and
polling system. A packet is received and decrypted first and then
it is processed and a confirmation packet is transmitted out.
The service rate is given by . The first and second mo-
ments of the packet data interval are and , re-
spectively. The utilization factor is . Let be the du-
ration of the reservation interval and assume that successive
reservation intervals are independent and identically distributed
random variables with the first and second moments and ,
respectively.
When the packet arrives at the system, any packet being
processed or received/decrypted and any packet before the
packet must be served completely first before the packet is
served. In other words, the packet must wait in queue for the
residual time until the end of the current packet processing
or reservation interval. ( is the residual service time seen by
the packet. By this we mean that if packet is being pro-
cessed or received/decrypted when the packet arrives, is
the remaining time until packet ’s service time is complete. If
no packet is in service, then is zero.) The packet must also
wait for the processing of the packets currently in the queue
before the packet. Finally, the packet must wait during
the next reservation interval , say, in which its reservation
will be made (Fig. 4). Thus, according to the queue theory, the
expected waiting time in queue is
Since the packet processing (verify, validate, generate, sign,
and send) is same for all vehicles, the data intervals of all vehi-
cles have equal average length. Thus
We define as the overhead or retrieval time for receiving
and decrypting a packet. We consider the retrieval interval for
each packet is a constant . We then have
712
Fig. 4. Calculation of the waiting time.
The total time at the aggregator for receiving/decrypting a
responding packet, processing it and sending a signed confirma-
tion packet to the vehicle is
From the above analysis, the total time at the aggregator is
increased as the vehicles arrival rate increases, and as the ser-
vice rate decreases. In the above basic V2G system, the aggre-
gator verifies every packet, then generates and signs a confirma-
tion packet, and finally sends the signed confirmation packet to
every verified vehicle. This creates considerable security over-
head, especially in terms of message size, verifying and signa-
ture generation delay. In the next subsection, we analyze a batch
V2G system with UBAPV2G.
B. Analysis of a Batch V2G System With UBAPV2G
In UBAPV2G, after the aggregator sends out the power com-
mand to call for vehicles, it waits for an interval time to receive
the multiple responses from a batch of vehicles. During the pro-
cessing (data) interval, the aggregator verifies the batch of ve-
hicles’ signatures with only one signature verification and vali-
dates the power status of vehicles, and then generates a confir-
mation packet and signs it with its signature; and finally broad-
casts the signed confirmation packet to inform the batch of ve-
hicles to go to a targeted discharging/charging station.
Similarly, we assume independent Poisson arrival process for
vehicles with rate . We then assume that the batch size is
packets which are received by the aggregator. For the batch of
packets, the aggregator verifies the batch of vehicles’ signa-
tures with only one signature verification, and then generates
IEEE TRANSACTIONS ON SMART GRID, VOL. 2, NO. 4, DECEMBER 2011
TABLE II
PERFORMANCE COMPARISON
and transmits only a confirmation packet with only one sig-
nature to inform the batch of vehicles. Thus, the service rate
.
Similarly, we can derive the total time at the aggregator
using UBAPV2G batch authentication protocol is
From the above analysis, the UBAPV2G protocol can reduce
the total time for the aggregator to process a batch of packets
and transmit a confirmed packet to inform a batch of vehicles.
Therefore, UBAPV2G reduces the authentication delay.
C. Computational Cost
Referring to Batch Authentication Technique with
UBAPV2G in Section III, UBAPV2G protocol reduces
the computational time. In addition, the aggregator sign a con-
firmation packet only one time to inform a batch of vehicles,
while one-by-one scheme needs sign time a confirmation
packet individually to inform the batch of vehicles. Thus,
the computational cost in UBAPV2G is less than that in the
one-by-one authentication scheme.
D. Communication Traffic
For the one-by-one authentication scheme, the aggregator
needs to send times a confirmation packet to inform the
batch of vehicles individually. With UBAPV2G scheme, the
aggregator only sends one time a confirmation packet to inform
the batch of vehicles at same time. Thus, UBAPV2G reduces
the communication traffic from the aggregator.
In summary, the performance comparison between our
scheme and one-by-one scheme is listed in Table II.
V. SECURITY ANALYSIS
In this section, we analyze the proposed scheme in terms of
message authentication, message integrity, reply attack resis-
tance, and privacy.
Message Authentication: With our scheme, the exchanged
message is signed using the sender’s private key. Thus, the re-
ceiver can know the identity of the message sender, and there-
fore, the message is authenticated.
Message Integrity: If an adversary tampers with a message,
the aggregator cannot decrypt the message, and therefore, the
intercepted message will be ignored and message integrity is
ensured. Due to the nature of message authentication and in-
tegrity, typical attacks, such as bogus attack and impersonation
attack can be also prevented.
GUO et al.: UBAPV2G: A UNIQUE BATCH AUTHENTICATION PROTOCOL FOR VEHICLE-TO-GRID COMMUNICATIONS 713

Replay Attack Resistance: With a replay attack, an adversary

eavesdrops a message and then replays the intercepted message
to pretend to be a legitimate vehicle. Since a timestamp is at-
tached with each exchanged message, and all vehicles and the
aggregator keeps time synchronization. Assume that an adver-
sary eavesdrops a message, and launches a replay attack at time
. Because the time period , where
is a mutually agreed transmission and propagation delay, the re-
ceiver will discard the message. Therefore, our scheme is robust
to against the replay attack.
Privacy: A vehicle encrypts the responding information using
the aggregator’s public key to protect the privacy of the vehicle
so that if an adversary eavesdrops the message, the adversary
cannot know the detail information of the vehicle and therefore,
the privacy of the vehicle is protected.

VI. EXPERIMENTAL RESULTS Fig. 5. Comparison of authentication delay.

We implement our proposed UBAPV2G scheme, and carry
out experiments to compare with the one-by-one authentication
scheme in terms of authentication delay.
The specifications of the aggregator computer (server) are
a 2.56GHz Pentium 4 CPU with 512MB RAM and 100Mb/s
LAN, while the specifications of the vehicle computer (client)
are a Pentium-M1.6GHz CPU and 54Mb/s 802.11g wireless
router. Both programs are written in C language and run on
Ubuntu 10.04 operating systems [30]. Both the client and the
server adopt the multithreaded programming so that transmit-
ting and receiving can be performed in parallel.
A. One-by-One Authentication Scheme
With the server and client connecting using UDP protocol,
the client and the server create socket respectively.
In the vehicle client side:
1) The client generates various number of packets to be sent
to the server per second. (Note that we use one client to
simulate the multiple vehicles that some of packets may
be sent by the different vehicles, and some may be sent by
the same vehicles. All packets are treated the same.)
2) In the transmitting thread function, the client sends the
packets to the server one by one.
3) In the receiving thread function, the client receives confir-
mation packets from the server.
4) The duration time taken from the client sending the first
packet to receiving the last confirmation packet from the
server for the last packet is recorded. We define this du-
ration time as the authentication delay for the one-by-one
authentication scheme.
In the server side:
1) In the receiving thread function, the server runs an endless
while loop to receive packets from the client.
2) In the transmitting thread function, each time the server
receives a packet, it decrypts it and then processes it, and
finally sends a confirmation packet back to the client.
B. UBAPV2G Scheme
With the client and server connecting using UDP protocol,
the client and the server create socket respectively.
Client side:
1) In the transmitting thread function, the client sends the
packets to the server one by one, which is the same as the
one-by-one authentication scheme.
2) In the receiving thread function, the client also checks if
there’s any confirmation packet from the server. If it re-
ceives the confirmation packet, it prints out.
3) The duration time taken from the client sending the first
packet to receiving the last confirmation packet from the
server for the last batch of packets is recorded. We de-
fine this duration time as the authentication delay for our
UBAPV2G scheme.
Server Side:
1) In the receiving thread function, the server runs an endless
while loop to receive packets from client and decrypt them.
2) In the transmitting thread function, when the first packet
receives, the server set a timer as the interval time. During
the interval time, the aggregator also verifies the signatures
starting from the first packet. While time out, it processes
the batch of remainder packets received in its buffer with
only one signature verification and then sends a signed con-
firmation packet back to the client. The sever continues
processing the next batch of packets.
C. Authentication Delay
We carry out the tests using the above one-by-one scheme
and UBAPV2G scheme respectively. The experimental results
are shown in Fig. 5. When the number of packets transmitted
is small, the authentication delay in UBAPV2G scheme is
same as one-by-one authentication. The reason is that when
the number of packets is small, the server can process in
time using one-by-one authentication scheme. Thus, the batch
authentication is not taken action.
However, when the number of packets transmitted is big,
the authentication delay in UBAPV2G scheme is smaller
than the one-by-one scheme. As shown in Fig. 5, the higher
the number of packets is, the better performance UBAPV2G
scheme achieves. The reason is that when the number of
packets is big, the server cannot process packets in time using
one-by-one scheme such that there is the queuing delay. But
with UBAPV2G scheme, according to the previous analysis,
the total time at the aggregator using UBAPV2G scheme is
714
reduced. Thus, the UBAPV2G achieves better performance.
The higher the number of packets is, the bigger the batch size
is, and hence the more time the UBAPV2G can reduce.
In summary, UBAPV2G can reduce the authentication delay
when a large number of packets respond to the aggregator’s call.
VII. CONCLUSIONS
In this paper, we present the UBAPV2G batch authentica-
tion protocol for V2G communication that takes into account the
characteristics of vehicle communications. Instead of verifying
each packet for each individual vehicle, the aggregator checks
a batch of responses from a batch of vehicles with only one sig-
nature verification, and then broadcasts a signed confirmation
packet to inform the batch of vehicles with only one signature.
We describe the batch signature technique with UBAPV2G and
the detail design of UBAPV2G protocol. We analyze the basic
V2G system and the batch V2G system with UBAPV2G pro-
tocol to show that UBAPV2G can reduce authentication delay,
and analysis also shows that UBAPV2G can achieve less com-
putational cost and less communication traffic compared with
the one-by-one authentication scheme. The security analysis
shows that UBAPV2G protocol is secure against the security at-
tacks. The experimental results also prove that UBAPV2G can
achieve less authentication delay for large number of packets.
Thus, UBAPV2G protocol is suitable for the stringent require-
ment of real time V2G communications.
REFERENCES
[1] C. J. Cleveland and C. Morris, Dictionary of Energy. Amsterdam,
The Netherlands: Elsevier, 2006, p. 473.
[2] Pacific Gas & Electric, “Pacific Gas and Electric Company energizes
Silicon Valley with vehicle-to-grid technology,” Apr. 2007, retrieved
Dec. 16, 2009 [Online]. Available: http://www.pge.com/about/news/
mediarelations/newsreleases/q2_2007/070409.shtml
[3] V2G Home, “What is V2G?” [Online]. Available: http://www.udel.
edu/V2G/, retrieved Dec. 14, 2009
[4] “Car prototype generates electricity, and cash,” Sci. Daily Dec.
9, 2007 [Online]. Available: http://www.sciencedaily.com/re-
leases/2007/12/071203133532.htm,, retrieved Dec. 16, 2009
[5] “Vehicle-to-grid,” [Online]. Available: http://en.wikipedia.org/wiki/
Vehicle-to-grid, retrieved Dec. 16, 2009
[6] A. Cocconi, “Connected cars: Battery electrics & plug in hybrids,” pre-
sented at the Seattle Electric Vehicle to Grid Forum, V2G Tech. Symp.,
Seattle, WA, Jun. 6, 2005.
[7] A. N. Brooks, “Final report vehicle-to-grid demonstration project: Grid
regulation ancillary service with a battery electric vehicle,” AC Propul-
sion Rep., Dec. 2002.
[8] T. B. Gage, “Final report development and evaluation of a plug-in hev
with vehicle-to-grid power flow,” AC Propulsion Rep., Dec. 2003.
[9] J. Halliwell, “Overview of some EPRI smart charging projects and
communications infrastructure related efforts,” IEEE1809 Webinar,
Feb. 18, 2010.
IEEE TRANSACTIONS ON SMART GRID, VOL. 2, NO. 4, DECEMBER 2011
[10] J. Motavalli, “Power to the people: Run your house on a Prius,” New
York Times Sep. 2, 2007 [Online]. Available: http://www.nytimes.com/
2007/09/02/automobiles/02POWER.html, retrieved Dec. 16, 2009
[11] R. McMillan, “Power grid is found susceptible to cyberattack,” IDG
News Service, Mar. 21, 2009.
[12] L. Armstrong, What is DSRC [Online]. Available: http://www.leearm-
strong.com/DSRC/DSRCHomeset.htm, retrieved Sep. 2, 2008
[13] H. Q. Guo, “Introduction: An emerging area of vehicular networks and
data exchange,” in Automotive Informatics and Communicative Sys-
tems: Principles in Vehicular Networks and Data Exchange. Her-
shey, NY: Information Science Reference, 2009, pp. 1–11.
[14] D. Jiang and L. Delgrossi, “IEEE 802.11p: Towards an international
standard for wireless access in vehicular environments,” in Proc.
IEEE Veh. Technol. Conf. (VTC Spring), Singapore, May 2008, pp.
2036–2040.
[15] Family of Standards for Wireless Access in Vehicular Environments
(WAVE), IEEE 1609, Sep. 25, 2009, ITS Standards Fact Sheets.
[16] IEEE Trial-Use Standard for Wireless Access in Vehicular Environ-
ments—Security Services for Applications and Management Messages,
IEEE Standard 1609.2-2006, Jul. 2006.
[17] Digital Signature Standard (DSS), Federal Information Processing
Standards Publication, FIPS PUB 186-3, National Institute of Stan-
dards and Technology, Jun. 2009.
[18] D. Naccache, D. M’Raihi, D. Rapheali, and S. Vaudenay, “Can DSA be
improved: Complexity trade-offs with the digital signature standard,”
in Pre-Proc. Eurocrypt 1994, pp. 85–94.
[19] L. Harn, “DSA type secure interactive batch verification protocols,”
Electron. Lett., vol. 31, no. 4, pp. 257–258, 1995.
[20] M. Bellare, J. A. Garay, and T. Rabin, “Fast batch verification for mod-
ular exponentiation and digital signatures,” in Proc. Adv. Cryptol. (EU-
ROCRYPT), May 1998, pp. 236–250.
[21] L. Harn, “Batch verifying multiple DSA-type digital signatures,” Elec-
tron. Lett., vol. 34, no. 9, pp. 870–871, 1998.
[22] Y. Zhou and Y. Fang, “Multimedia broadcast authentication based on
batch signature,” IEEE Commun. Mag., vol. 45, no. 8, pp. 72–77, Aug.
2007.
[23] Y. Zhou, X. Zhu, and Y. Fang, “MABS: Multicast authentication based
on batch signature,” IEEE Trans. Mobile Comput., vol. 9, no. 7, pp.
982–993, Jul. 2010.
[24] C. Boyd and C. Pavlovski, “Attacking and repairing batch verification
schemes,” in Proc. 6th Int. Conf. Theory Appl. Cryptol. Inf. Security
Adv. Cryptol. (ASIACRYPT ’01), Dec. 2000, pp. 58–71.
[25] L. Yang, J. Han, Y. Qi, and Y. Liu, “Identification-free batch authen-
tication for RFID tags,” in Proc. IEEE Int. Conf. Netw. Protocols
(ICNP), Kyoto, Japan, Oct. 2010.
[26] D. Boneh, C. Gentry, B. Lynn, and H. Shacham, “A survey of two
signature aggregation techniques,” CryptoBytes Tech. Newslett., vol.
6, no. 2, Summer, 2003, RSA Laboratories.
[27] M. Raya, A. Aziz, and J. Hubaux, “Efficient secure aggregation
in VANETs,” in Proc. 3rd ACM Int. Workshop Veh. Ad Hoc Netw.
(VANET), Los Angeles, CA, Sep. 2006.
[28] H. Q. Guo, F. Yu, W. C. Wong, V. Suhendra, and Y. D. Wu, “Secure
wireless communication platform for EV-to-grid research,” in Proc.
6th Int. Wirel. Commun. Mobile Comput. Conf. (IWCMC), Caen,
France, Jun. 28–Jul. 2 2010, pp. 21–25.
[29] D. Bertsekas and R. Gallager, Data Network. Englewood Cliffs, NJ:
Prentice-Hall, 1992.
[30] Ubuntu 10.04 Operating Systems [Online]. Available: http://www.
ubuntu.com/
Authors’ photographs and biographies not available at the time of publication.