1

Privacy-preserving and Collusion-ResistantCharging Coordination Schemes for Smart Grids

Mohamed Baza,Marbin Pazos-Revilla, Mahmoud Nabil, Ahmed Sherif Member IEEE ,Mohamed Mahmoud Member IEEE , and Waleed Alasmary Member, IEEE,

Abstract—Energy storage units (ESUs), including electric vehicles and home batteries, enable attractive features in the future smartgrid. In this paper, we propose centralized and decentralized privacy-preserving and collusion-resistant charging coordinationschemes. The centralized charging coordination (CCC) scheme is used in case there is a robust communication infrastructure thatconnects the ESUs to a charging coordinator (CC) run by the utility, whereas the decentralized charging coordination (DCC) scheme isuseful in case of remote areas or isolated microgrids in which a robust communication to the utility is not available or considered costly.In the CCC scheme, each ESU should acquire anonymous and unlinkable tokens from the CC to authenticate their charging requestsand send them to the CC via a local aggregator. Having done that, if the CC and the aggregator collude, they cannot identify senders ofthe charging requests. Moreover, by sending multiple charging requests with random time-to-complete-charging (TCC) and the batterystate-of-charge (SoC) by each ESU that follow a truncated normal distribution (instead of only one request), the CC cannot link thecharging requests data sent from the same ESU at different time slots to preserve privacy. After receiving the charging requests, theCC runs an optimization technique to compute charging schedules to maximize the amount of power delivered to the ESUs before thecharging requests expire without exceeding the maximum charging capacity. In the DCC scheme, charging is coordinated in adistributed way using data aggaregation technique. The idea is that each ESU selects some ESUs as proxies, and share a secret maskwith each proxy. Then, each ESU adds a mask to its charging request and encrypt it using homomorphic encryption, so that byaggregating all requests all masks are nullified and the total charging demand for each priority level is known so that each ESU cancompute its charging schedule. Due to using the masking technique, DCC is secure against collusion. The results of extensiveexperiments and simulations confirm that our schemes are efficient, secure, and can preserve ESU owners’ privacy.

Index Terms—Privacy-preservation, Energy storage units, Charging coordination, Collusion attacks, Smart grid.

F

1 INTRODUCTION

ENERGY storage units (ESUs), including home batteriesand electric vehicles (EVs), will play a major role in

the future smart grid [1]. They can store energy whenthere is a surplus in energy generation and inject energyto the grid when the demand is high to balance the energydemand and supply, which in turn enhances the power gridresilience [2]. Moreover, ESUs can also facilitate the use ofrenewable energy generators by storing the excess energygenerated [3]. Moreover, ESUs can also help electricity con-sumers to reduce their electricity bills by charging fromthe grid during low-tariff periods and power the housesduring high-tariff periods. However, despite these benefits,ESUs pose several challenges that should be addressed forsmoothing their integration with the power grid [4].

• Mohamed Baza and Mohamed Mahmud are with the Department of Elec-trical & Computer Engineering, Tennessee Tech University, Cookeville,TN 38505 USA.E-mails: mibaza42@students.tntech.edu, mmahmoud@tntech.edu.

• Marbin Pazos-Revilla is with Department of Computer Science andEngineering, University of South Florida, Tampa, FL, USA E-mail:marbin@usf.edu

• Mahmoud Nabil is is with the Department of Electrical & ComputerEngineering, North Carolina A&T University, Greensboro, NC, 27401USA. E-mail: mnmahmoud@ncat.edu

• Ahmed Sherif is with School of Computing Sciences and Com-puter Engineering, University of Southern Mississippi, USA. E-mail:ahmed.sherif@usm.edu

• Waleed Alasmary is with Department of Computer Engineering,Umm Al-Qura University, Makkah, Saudi Arabia. E-mail: wsas-mary@uqu.edu.sa

Manuscript received November xx, 2018; revised November xx, 2018.

The simultaneous uncoordinated charging of ESUs mayresult in lack of balance between the charging demand andthe energy supply. For example, after work hours, mostof the EVs’ owners usually return home and plug in theirEVs to charge. The uncoordinated charging may result instressing the distribution system, causing instability to thegrid [5], and could lead to a power outage in severe cases.To avoid such consequences, there is a substantial need fora charging coordination mechanism [6]. Typically, in a chargingcoordination mechanism, ESUs need to send charging re-quests that have data such as the time-to-complete-charging(TCC), the battery state-of-charge (SoC), and the amountof required charging to a charging controller (CC). Then,these data can be used to compute priority indices (i.e.,charging priority) so that ESUs with the highest prioritiesshould charge first without exceeding the maximum charg-ing capacity, while other ESUs charging is deferred to futuretime slot [2]. Unfortunately, the data that should be reportedto the CC can reveal sensitive information about the ESUsowners such as the location of an EV’s owner, when he/shereturns home, whether he/she is on travel, etc. To the bestof our knowledge, many schemes were presented in theliterature to deal with coordinated ESUs charging issues [5]–[11], but they do not take the privacy issue into consideration.

In this paper, we propose two privacy-preservingand collusion-resistant charging coordination schemes:Centralized Charging Coordination (CCC) scheme, andDecentralized Charging Coordination (DCC). The CCCscheme is designed to work in smart grids in which there is a

arX

iv:1

905.

0466

6v3

[cs

.CR

] 2

0 Fe

b 20

20

2

robust communication infrastructure that connects the ESUsto the utility. In this case, ESUs are connected to the maingrid and charging coordination should be performed at thegrid operators’ level. On the other hand, the DCC is de-signed to work on remote areas such as isolated microgrids(island mode). The isolated microgrids are not connected tothe main grid due to their remoteness or failure to connectto the main grid. In the DCC, various sources of distributedenergy generators including renewable energy sources arethe only solution to meet the energy needs of the isolatedmicrogrids consumers, and the microgrid should functionautonomously [3].

In the CCC, each ESU should use anonymous and un-linkable tokens from the CC to authenticate its chargingrequests and send them to a local aggregator. The tokens aregenerated using partial blind signature so that even if theCC and the aggregator collude, they cannot expose sender’strue identity. However, the CC can link charging requests indifferent time slots to the same sender ESU because ESUssend requests with linkable (i.e., close) TCC and SoC valuesin consecutive time slots. By linking charging requests ofan ESU, the CC can collect information that can be used toidentify the ESU owner and as a result the ESU’s ownerprivacy can be violated. To prevent this linkability, eachESU sends multiple charging requests with random TCCand SoC (instead of one request) that follow a truncatednormal distribution while maintaining the charging priorityof the ESU. By doing so, the CC cannot link the chargingrequests sent from the same ESU in different time slots topreserve privacy and the charging priority of the ESU ismaintained. Then, upon receiving charging requests, theCC prioritizes the requests by running an optimizationtechnique to maximize the power delivered to the ESUsbefore the charging requests expire while not exceeding themaximum charging capacity. Note that, this paper focuseson the privacy and security issues, and other researchworks have already studied the optimization techniques forcharging coordination [1], [3], [5]–[11]. While these schemescan be used with our scheme, we used a modified versionof optimization technique for knapsack problem for thepurpose of evaluations [12].

In DCC scheme, one node (or more) is selected as anaggregating node. Each ESU selects a set of ESUs called proxiesand share a mask with each one. Each ESU then adds themask to their charging requests, encrypts them using ho-momorphic encryption, and sends them to the aggregatingnode. By aggregating all requests, masks are nullified andonly the total charging demand for each priority level isknown. By this way, the aggregating node cannot know thecharging requests of the ESUs to preserve privacy. Then,the aggregating node broadcasts the aggregated chargingdemand. If the demand is higher than the total chargingcapacity, the ESUs that have higher priority should chargewithout exceeding the charging capacity.

Our main contributions and the challenges the paperaims to address can be summarized as follows.• We studied the probability of linkability attacks by the

CC in the centralized scheme using SoC and/or TCC.The results indicate that the CC can use SoC/TCC tolink charging requests to a specific ESU successfullywhich violates the ESU owner’s privacy.

• A privacy-preserving CCC scheme is proposed. Col-lusion attacks between the CC and the local aggrega-tor/ESUs is mitigated by using anonymous and un-linkable tokens. Also, linkability attacks are mitigated,and thus the CC cannot learn whether two chargingrequests of different time-slots are from the same ESUor not.

• A privacy-preserving DCC scheme is proposed. Thecharging coordination can be performed without theneed for a central party that can access the individualESUs data (TCC and SoC). The scheme is also secureagainst collusion attacks that aim to reveal an ESU data.

• Extensive simulations and analysis are conducted toevaluate the proposed schemes. The results indicatethat our schemes can coordinate charging activitieswhile preserving ESUs owners’ privacy and securingthem against collusion attacks.

The rest of the paper is organized as follows. We describethe network and threat models, followed by the designgoals of our schemes in Section 2. In Section 3, we discusspreliminaries used by our schemes. Then, the centralizedand decentralized schemes are presented in Sections 4 and 5respectively. Detailed security and privacy analysis are pro-vided in Section 6. In Section 7, we discuss performanceevaluations for our schemes. Section 8 presents the relatedwork. Finally, we give concluding remarks in Section 9.

2 NETWORK/THREAT MODELS AND DESIGNGOALS

In this section, we present the considered network modelsfollowed by the adversary and threat models, and then, weintroduce the design goals of our schemes.

2.1 Network ModelsAs illustrated in Fig. 1, the network model of the CCCscheme has a number of communities and CC. Each commu-nity has a group of ESUs and one aggregator. The storageunits can be EVs or batteries installed in homes. The CCcannot communicate with the storage units directly, but thishas to be done via the aggregators. The ESUs send chargingrequests to the aggregator to forward them to the CC. TheCC prepares charging schedules and send them back to theESUs via local aggregators.

As shown in Fig. 2, the network model of the DCCscheme has only ESUs that can communicate with otherESUs using one-hop or multihop communication proto-cols [13]. In multihop communication, some ESUs can actas routers to relay other ESUs messages. As shown inthe figure, each ESU should send its individual chargingdemand to aggregating node (s) to aggreagte them andreturn aggregated charging demand. Then, each ESU cancompute its priority index and use it to compute its chargingschedules. An aggregating node ESU is responsible forreceiving charging requests from other ESUs, aggregate anddecrypt them, and finally broadcast the aggregated message.The scheme can be run by one aggregating ESU that changeseach time the scheme is run to distribute the computationoverhead on the ESUs. Multiple (or all) ESUs can also actas aggregating nodes to ensure that the aggregation of thecharging demands are done properly.

3

Communicationlayer

e.g.,LTE/5G

Communityk

Aggregator Aggregator

CC

----

Community1

----

ChargingschedulesChargingrequests

Fig. 1: Network model for the CCC.

Aggregatingnodes

⋮

⋮ ⋮

⋮

Individualchargingrequest

Aggregatedchargingdemand

Fig. 2: Network model for the DCC.

2.2 Adversary and Threat Models

In both CCC and DCC, the attackers are interested ingathering private information about ESUs owners. Theseinformation include whether the owner is on travel, whenhe/she returns home, and other daily activities.

The attackers in the CCC scheme can be the aggre-gator, the CC, ESUs, or external eavesdroppers who maypassively snoop on the communications to learn sensitiveinformation. Attackers can work individually or collude tolaunch stronger attacks to reveal SoC/TCC of specific ESUs.Also, the CC can launch a linkability attack using the SoCand/or TCC of charging requests to infer an ESU sensitiveinformation.

In the DCC scheme, the attackers can be ESUs includingaggregating nodes, or eavesdroppers that eavesdrop on thecommunications of the ESUs and try to figure out somesensitive information on ESUs’ owners. The attackers canwork individually or collude to launch stronger attacks.

TABLE 1: Notations

Notation Description

B(m) Blined message m

σcd(B(m))

Partially blinded signature on message mwhere c is the common appended message,and d is the signer’s private key.

Kv↔cc

Shared symmetric key between an ESU v andthe CC

UvThe charging priority of an ESU v

PCC , SccThe CC public/private key pair

τ(`)v

A charging token ` of an ESU v

PK(`)v /SK

(`)v

A public/private key pair for each token

Sv , Tv SoC/TCC of an ESU v

R(j)v

A charging request j from an ESU v

R(j,k)v

Individual n charging requests of the requestR

(j)v , 1 ≤ k ≤ n

S(j,k)v , T (j,k)

v , U(j,k)v

SoC, TCC, priority for R(j,k)v

Sc(j,k)v

Charging schedule of an ESU v at a time slot j

q,G1, G2, P, e Public parameters of bilinear pairing

(N, g), δPublic/private key of homomorphicencryption

vA Aggregating node

2.3 Design Goals

Our schemes should achieve the following important fea-tures.• Privacy-preserving charging coordination. A charging co-

ordination scheme should compute charging schedulesthat charge the highly prioritized requests and deterother requests to future time slots without exceedingthe maximum charging capacity, and without revealingany sensitive information about ESUs owners.

• Resistance to collusion attacks. Our schemes should besecure against collusion attacks, i.e., if any collude, theyshould not obtain SoC/TCC of a victim ESU.

• Resistance to linkability attacks. No one including the CCand the aggregating nodes should be able to link charg-ing requests and the corresponding SoC/TCC sent froman ESU at different time slots.

• Data integrity and authenticity. The integrity and authen-ticity of the charging requests should be verified.

3 PRELIMINARIES

In this section, we present the necessary background onbilinear pairing, partial blind signature, and paillier cryp-tosystem that will be used in this paper. Notations used inthe paper are given in Table. 1.

3.1 Bilinear Pairing

Let G1 be a cyclic additive group with generator P andorder of prime q, and G2 be a cyclic multiplicative groupwith the same order. Let e: G1×G1→ G2 be a bilinear mapwith the following properties.• Bilinearity: e(aP, bQ) = e(P,Q)ab, where P,Q ∈G1, anda, b ∈ Z∗q .

4

• Non-degeneracy: There exists P,Q ∈G1 such that e(P,Q)6= 1.

• Computability: There is an efficient algorithm to com-pute e(P,Q) for all P,Q ∈ G1.

3.2 Partial Blind Signature

Blind signature is a cryptosystem in which a sender of amessage is able to get the signature on this message fromthe singing party while concealing the content of the mes-sage. Partial blind signature (PBS) is a special case of blindsignature in which the signer can include information thatis known to both singer and sender in the signed message,such as a time or date [14]. A brief description of the PBSproposed in [15] is given as follows.

1) The signer picks an element d ∈R Z∗q as the private keyand computes public key Ppub = dP , where P is thegenerator of a cyclic additive group G1.

2) The requester randomly chooses a number r ∈R Z∗q andcomputes B(m) = Ho(m||c) + r(H(c)P + Ppub), whereB(m) is the blinded messagem,H is hash function suchthat H0: {0,1}∗ → Z∗q , H0 is hash function such that H:{0,1}∗ → G1, and c is the common information e.g.,date. Then, the requester sends B(m) to the signer.

3) The signer sends back σcd(B(m)) = (H(c) + d)−1B(m)to the requester.

4) The requester applies unblinded operation B−1 usingthe secret key r to σcd(B(m)) to obtain the signer’ssignature σcd(m) as follows.

B−1(σcd(B(m))

)= σcd(B(m))− rP

=Ho(m‖c)H(c) + d

= σcd(m) (1)

Finally, the requester can use m‖σcd(m) to authenticateitself anonymously and the signer can accept the signatureby checking:

e(H(c)P + Ppub, σcd(m))

?= e(P,Ho(m||c))

3.3 Paillier Cryptosystem

Paillier cryptosystem [16] is one of the popular techniquesto achieve homomorphic additive encryption. In Pailliercryptosystem, if two messages m1 and m2 are encryptedas Ek(m1) and Ek(m2) with the same key k, to obtainthe ciphertext of the summation of m1 and m2, the twociphertexts of m1 and m2 are multiplied, i.e.,

Ek(m1) · Ek(m2) = Ek(m1 +m2)

Typically, Paillier cryptosystem is composed of the follow-ing phases: key generation, encryption, and decryption.

1) Key Generation: two large and independent prime num-bers p and q are selected randomly, and δ = lcm(p −1, q−1) and N = p ·q are computed where δ is the leastcommon multiple of p − 1 and q − 1. Then, a functionL(x) = x−1

N is defined, a generator g = (1 +N) is cho-sen, and µ =

(L(gδ mod N2

))−1mod N is computed.

The public key is (N, g), and the private key is (δ, µ).

2) Encryption: Given message m ∈ Z∗N , and a randomnumber r ∈ Z∗N2 , the ciphertext can be computed asfollows:

C = E(m) = gm · rN mod N2

3) Decryption: Given a ciphertext C, where C ∈ Z∗N2 , wecan compute the plaintext message as

m = L(Cδ mod N2

)· µ mod N

4 THE CCC SCHEME

In this section, we discuss and evaluate charging requestlinkability attacks, and then we discuss in details our CCCscheme.

4.1 Linkability AttacksIn the CCC scheme, the CC should access the SoC and TCCof ESUs’ charging requests to compute the charging sched-ules. However, since the CC has these data over severaltime slots for all the ESUs, it could link charging requestssent from the same ESU, which would violate the privacyof the ESUs’s owners. This attack is known as a linkabilityattack. Typically, the CC can link an ESU charging requestsbecause the SoC/TCC of the ESU requests are related. Forexample, if an ESU does not charge in a time slot, the SoCof the next time slot should at most equal by the energyconsumption amount. Therefore, the two SoCs can be linkedby approximating the consumption amount and finding therequest that has the closest SoC value.

To show the effectiveness of the linkability attack basedonly on the SoC/TCC values, we use Matlab to simulatethe attacks and run experiments. The simulation parametersare set as follows. The maximum charging capacity of acommunity is 1000 KW, the maximum charging capacity ofan ESU was set to 100 KW, and the number of ESUs is 150.TCC and SoC are selected randomly based on a uniformdistribution from {1, · · · , 48} in time slots and [1, 50] KWrespectively. Three attacks are simulated to link chargingrequests to the same ESU. Attack 1 uses only SoC to linkrequests, Attack 2 uses only TCC, and Attack 3 uses both SoCand TCC. Two cases are simulated in all attacks includinglow-resolution and high-resolution values for SoC. For thelow-resolution case, the change in reported SoC is relativelysmall (i.e., takes integer values) in consecutive time slots.For the high-resolution case, the change in SoC takes therange of decimal values. Also, we define the probabilityof a successful linkabilty attack as the ratio between thesuccessfully linked ESUs between time slot j and time slotj+ 1 to the total number of ESUs at time slot j. For examplein case of Attack 1, two ESUs at time slot j and j + 1 aresaid to be linked if the Euclidean distance between theirrespective SoC in the two consecutive time slots is less thancertain threshold (i.e., the average energy consumption of anESU in a time slot). Similarly, TTC or a combination betweenSoC and TCC can be used to determine the probability ofa successful linkabilty attack. In all experiments, 100 runswere performed, and the average values were taken.

As shown in Fig. 3, for a low resolution of SoC, chargingrequest linkability attack can experience considerable levels

5

20 40 60 80 100 120 1400.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Attack 1Attack 2Attack 3

Fig. 3: The probability of successful linkability attacks withlow resolution of SoC.

20 40 60 80 100 120 1400.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Attack 1Attack 2Attack 3

Fig. 4: The probability of successful linkability attacks withhigh resolution of SoC.

of success. For instance, the average probability of successis above 0.75, 0.65, and 0.95 for Attack 1, Attack 2 and Attack3, respectively in case of 20 ESUs. While it reaches 0.2 inthe case of Attack 1 when the number of ESUs increases to140, or below 0.2 in the case of Attack 2, however, whenthe combination of SoC and TCC is used in Attack 3, thelikelihood of success is considerably higher, reaching valuesof over 0.8. This is because as more ESUs submit requests,the likelihood of similarity among requests increases, whichexplains the drop in the success rate of linkability attacks asthe number of ESUs increases.

For high-resolution values of SoC, it can be clearly seenfrom Fig. 4 that the success rate of the attacks increases con-siderably compared to the low-resolution SoC cases givenin Fig. 3. This is noticeable especially for Attack 3, where thesuccess probability reaches 0.97 even with a high number ofESUs as 140. In the case of Attack 2, the success probability isnot significantly affected compared to Fig. 3. This behaviouris attributed to smaller values of TCC comparing to those

ESUv CC

msg1 := ID‖Bv(M(`)v )‖TS‖σv

msg2 := σ(v,`)cc

(Bv(M(`)

v

))

Fig. 5: Token acquisition.

of SoC. With a larger set of possible values for SoC, itbecomes easier to single out distinct pairs of requests. Thiscontributed to the increased level of success of the likabilityattack, either when SoC is used by itself, or in combinationwith TCC.

It can be concluded that Attack 1 is always more success-ful than Attack 2 because SoC has a larger range of valuesthan TCC. This makes it easier for the CC to link requestssent from an ESU as there is more range of values eachrequest can take. Also, Attack 3 is always more successfulthan Attacks 1 and Attack 2 because Attack 3 can benefit fromthe range of values of SoC and the additional information ofTCC that can contribute to the success of the attack. More-over, the results of the above experiments demonstrate thatthe number of requests submitted from a community wouldneed to be sufficiently large in order to make data linka-bility attack unsuccessful. Motivated by these results, in ourscheme, each ESU sends multiple charging requests (insteadof only one) and by properly selecting the SoC/TCC of theESUs’ requests, these requests should have close values ofSoC/TCC to make linkability unsuccessful but SoC/TCCshould also maintain the priority level of the ESU.

4.2 Overview of the CCC scheme

The CCC scheme consists of four phases. First, in theacquisition of tokens phase, an ESU acquires a number ofcryptographic tokens from the CC to anonymously au-thenticate itself to the CC. Then, in the charging requestssubmission phase, ESUs use the tokens to send their chargingrequests to the local aggregator. Then, for efficiency, in theverification of charging requests and signature aggregation phase,the aggregator should verify all the received signatures,aggregate them, and send one signature to the CC. Finally,in the computing charging schedules phase, the CC compute thecharging schedules and return them back to the aggregators.

4.3 Acquisition of Tokens

In this phase, each ESU acquires a number of cryptographictokens from the CC. These tokens are used to anonymouslyauthenticate the ESU and also help it to share a key with theCC to encrypt the charging schedules. Acquisition of tokensis illustrated in Fig. 5.

Assume that the CC has a public/private key pair{PCC , Scc}. Each ESU v acquires m tokens. For each token,v generates a public/private key pair PK(`)

v /SK(`)v , where

1 ≤ ` ≤ m, and computes [K(`)v↔cc]Pcc which denotes a

symmetric key K(`)v↔cc encrypted by the CC public key (Pcc)

6

ESU v CCAgg

msg3 := τ(l)vi ‖r(j,k)vi ‖TS‖σ(`)

vi

msg4 :=M(`)vi )‖r(j,k)vi , · · · ,M(`)

vN )‖r(j,k)vN

‖σagg‖σAgg

msg5 = {Scv1 , Scv2 , · · · }‖σCC

msg5 = {Scv1 , Scv2 , · · · }‖σCC

Fig. 6: Charging request submission and charging schedules.

Then, v should send msg1 to the CC that is:

msg1 := ID‖Bv(M(`)v )‖TS‖σv,

where ID is the ESU real identity, M(`)v =

PK(`)v ‖[K(`)

v↔cc]PKcc , Bv(M(`)v ) is the blinded message of

M(`)v , TS is the time-stamp, and σv is the signature on

the whole message. Note that σv reveals the associated vreal identity and appending the time-stamp as part of therequest to protect against packet replay attack.

Then, once the CC receives msg1, it verifies the au-thenticity of the request by verifying the signature σv . Inaddition, it checks that the request time-stamp matches thecurrent time. If all the verifications succeed, the CC signsthe request and sends a partially-blind-signature msg2 backto the ESU as follows

msg2 := σ(v,`)cc

(Bv(M(`)

v

)).

Note that appended common message of the PBS c =TE‖IDg where TE is the token’s expiry date and (IDg) isthe identifier of the community. Then, v applies unblindedoperation B−1

v to obtain the signature on the tokenM(`)v as

follows

B−1v

(σ(v,`)cc

(Bv(M(`)

v

)))= σ(v,`)

cc

(M(`)

v

)

Finally, v uses the following token denoted as τ (`)v

τ (`)v =M(`)

v ‖σ(v,`)cc

(M(`)

v

),

to authenticate itself anonymously to its local aggregatorand the CC.

4.4 Charging Requests Submission

In this subsection, we discuss how an ESU sends theircharging requests to the CC anonymously while mitigatinglinkability attacks. Exchanged messages of charging requestsubmission and scheduling phases are illustrated in Fig. 6.

4.4.1 Computing SoC/TCC of Charging RequestsThe priority of an ESU v in a given time-slot can be mathe-matically expressed using its SoC and TCC as follows.

Uv = α1(1− Sv) + α2F (Tv), (2)

Where F (Tv) is a decreasing function of TCC (Tv) with arange of [0, 1] such that F (Tv) = 0 for long TCC and equals1 for short TCC, and SoC value (Sv) ∈ [0, 1] with Sv = 1 fora completely charged ESU. Both α1 and α2 are weights thatare appropriately chosen to give relative importance for Svand F (Tv), with α1 + α2 = 1.

Our strategy to mitigate linkablity attacks is as follows.For a charging request denoted asR(j)

v where j is the currenttime-slot, v creates n individual requests, and each requestis denoted as R(j,k)

v where (1 ≤ k ≤ n). Each request R(j,k)v

should be sent independently during the same time slot.To calculate the SoC and TCC of each request, v first usesits SoC S

(j)v and TCC T (j)

v at the time slot j to computea priority U

(j)v using Eq. 2. Then, using U

(j)v , it computes

n random priorities {U (j,1)v , · · · , U (j,n)

v } for each individualrequest R(j,k)

v . Finally, for each individual priority U(j,k)v ,

it calculates random tuples of S(j,k)v and T (j,k)

v that canachieve the priority U (j,k)

v using Eq. 2.To implement the idea, let the ESU priority U

(j)v

at a time slot j. To generate n individual priorities{U (j,1)

v , · · · , U (j,n)v }, the following conditions need to be

satisfied for each individual priority U (j,k)v :

C.1: It needs to be random or have different values inorder to mitigate the linkability attacks.C.2: It needs to be close or equal to U

(j)v . This to

ensure that each individual request R(j,k)v has the same

importance to be served as the original request R(j)v so

that the charging performance is not affected.C.3: It needs to be in the range [0,1] as we deal with itas a probabilistic value.

Thus, to achieve previous requirements mathematically,each individual priority U (j)

v can be sampled from the PDFof a truncated normal distribution [17] for the followingreasons. Firstly, by sampling, a random value is selectedfrom the PDF of the truncated normal distribution (C.1).Secondly, most probably the values in truncated normal dis-tribution are close to the distribution mean (C.2). Thirdly, itis bounded from a and bwhich can be mapped to [0, 1] (C.3).Accordingly, the PDF of the truncated normal distributionwith variance s and mean µ can be used. Details on howan ESU can sample from a truncated normal distribution isgiven in Appendix A.

Fig. 7, shows the probability distribution of the functionat different values for the priority Uv including 0.2, 0.4,and 0.9 and at different value for s. As shown in Fig. 7a,when s = 0.4, there are overlaps between the distributionsof different Uv . This helps in making linkability attacks difficultsince ESUs with different priority levels will have requests withclose priorities. As illustrated in Fig. 7b and 7c, varying thevalues of s results in values of U (j,k)

v that are either moredensely concentrated around U

(j)v , as in Fig. 7b, or more

dispersed as in Fig. 7c. The large values of s result in

7

(a) at s = 0.4. (b) at s = 0.05. (c) at s = 0.85.

Fig. 7: Probability mass function of ESU priority at different values of the variance (s).

Algorithm 1: Pseudocode for computing SoC and TCCof individual charging requests1 Input: U(j)

v , n, σ1, σ2

2 Uv [ ]: Array of randomly generated priorities3 Sv [ ]: Array of SoC of individual charging requests4 Tv[ ]: Array of TCC of individual charging requests5 for k = 1 to n-1 do

// Random U(j,k)v selection based on U(j)

v usingtruncated normal distribution

6 U(j,k)v = Random_Priority_Selection(U(j)

v )// Computing SoC of individual charging requests

7 if (k=1) then8 Sv [k] = rand(Sv);9 else10 Sv [k] = rand(Sv-

∑n−1k=1Sv[k]);

11 end// Computing TCC of individual charging requests

12 T (j,k)v = σ2/(Uv-(σ1×S(j,k)

v ))13 end

// Computing SoC and TCC of last charging request14 Sj,nv = Sjv -

∑n−1k=1S

j,kv

15 U(j,n)v = Random_Priority_Selection(U(j)

v )16 T (j,n)

v = σ2/(U(j)v -(σ1×S(j,n)

v ))17 Output (S(j,k)

v [ ],T (j,k)v [ ])

dispersed priority values, and as a consequence, linking twocharging requests with an ESU becomes harder. However,with large values of s, this will cause priorities to havea wide range of possible values, and as a consequence,the ESU’s charging requests would not maintain prioritiesU

(j,k)v close to U

(j)v , causing the charging performance to

decrease.

Finally, Algorithm 1 gives a summary of how ESUscan compute their SoC/TCC. An ESU v selects prioritiesU

(j,k)v for each individual request ofR(j,k)

v using the randomselection from the truncated normal distribution (See line 6in Algorithm 1). Then, it uses each priorityU (j,k)

v to computerandom S

(j,k)v and T (j,k)

v (See line 5-13 in Algorithm 1). Notethat SoC and TCC for each request are computed randomlyso that (1) S

(j,k)v and T (j,k)

v give U(j,k)v using Eq. 2, and

(2)∑ni=1 S

(j,k)v = S

(j)v . Then, T (j,k)

v associated with S(j,k)v

is computed using Eq. 2 (See line 12 in Algorithm 1).Lastly, the last request S(j,n)

v is computed to maintain theequality (

∑ni=1 S

(j,k)v = S

(j)v ) (See line 14 in Algorithm 1),

with random priority selection of the request’s priority andcorresponding T (j,n)

v (See line 16 in Algorithm 1).

4.4.2 Submitting Charging Requests to the Aggregator

After an ESU vi computes the requests SoC and TCC, itshould use the anonymous tokens previously acquired fromthe CC to compose the charging requests and send them toits local aggregator. To do that, vi sends its charging requestto the aggregator by sending msg3

msg3 := τ (`)vi ‖r(j,k)

vi ‖TS‖σ(`)vi .

Where msg3 contains a token τ (`)vi =M(`)

vi ‖σ(v,`)cc (M(`)

vi ),r

(j,k)vi = [S

(j,k)vi ‖T (j,k)

vi ]K

(`)vi↔cc

that is the SoC and TCCencrypted with the a shared secret key, time-stamp, andsignature of the ESU on the entire message. Note that thesignature should be done using a secret key that corre-sponds to a public key included in the token.

4.5 Verification of Charging Requests and SignatureAggregation

When the charging requests reach the aggregator (and laterthe CC), they need to be verified for authenticity and in-tegrity. As the number of ESUs in individual communitiesincreases, the number of requests also increases, and thusmore computation is needed for verifying each requestsignature. What makes the problem worse is that each ESUsends multiple requests. Therefore, to reduce communica-tion overhead, once the aggregator receives ESUs’ requestsof its community, it should aggregate the tokens signaturesas follows.

According to the formula in (1), the CC signature of atoken τ (`)

vi takes the following form.

σ(v,`)cc (M(`)

vi ) =Ho(M(`)

vi ‖c)H(c) + Scc

Then, once the aggregator receives N token signature,it aggregates them into one aggregated signature (σagg) asfollows.

8

σagg =N∑

i=1

σ(v,`)cc (M(`)

vi )

=Ho(M(`)

v1 ‖c) + · · ·+ Ho(M(`)vN ‖c))

H(c) + Scc

=

∑Ni=1Ho(M

(`)vi ‖c)

H(c) + Scc(3)

Then, the aggregator sends msg4 to the CC.

msg4 :=M(`)vi ‖r(j,k)

vi , · · · ,M(`)vN ‖r(j,k)

vN ‖σagg‖σAgg.It is important to note that msg4 contains all charging

requests within a specific time slot. Also, it contains theaggregator’ signature on the entire message σAgg .

4.6 Computing Charging SchedulesIn this phase, once the CC receives the charging requestsand their aggregated signature, it verifies the aggregatedsignature σagg by checking the following equality:

e(H(c)P + Pcc, σagg)?= e(P,

N∑

i=1

H0(M(`)vi ‖c)) (4)

Also, to detect token reuse, a table of previously usedtokens should be stored at the CC side. This table shouldinclude the hash of used tokens. Then, the CC checkswhether the received tokens in msg4 are reused. If allthese verifications succeed, the CC proceeds computing thecharging schedules of the requests using their SoC and TCCas follows.

Assume a community is connected to an electric bus witha maximum loading limit of C and full charging request ofan ESU v is (Pv). Our goal is to let ESUs with high prioritiesto charge at the present time slot, while other ESUs chargingrequests can be postponed to future time slots. The chargingcoordination problem determine whether an ESU v chargesin the current time slot (yv) and the charging amount (pv) soas to charge the ESUs with the highest priorities. Therefore,the charging coordination problem can be formulated as

maxyv,pv

∑

v∈VyvUv

s.t. 0 ≤ pv ≤ Pv ∀v ∈ V,∑

v∈Vyvpv ≤ C,

yv ∈ {0, 1}.

(5)

Problem (5) is a mixed integer program (MIP) as itinvolves a real variable pv and a binary variable yv , whichmakes it NP-complete. For a large size problem (i.e., a largecommunity with many ESUs), it is hard to solve (5) inreal-time. Instead of solving the MIP in (5), we resort toan integer program (IP) formulation, which is less complexthan (5), and is given by

maxyv∈{0,1}

∑

v∈VyvUv

s.t.∑

v∈VyvPv ≤ C.

(6)

Algorithm 2: ESU Charging Coordination Mechanism

Input: V, Uv and Pv ∀v ∈ V;Initialization: yv = 0 ∀v ∈ V, A = {}, CR ← C;

Sort all ESUs in V such that U1P1≥ U2

P2. . . ≥ UV

PVand store the result in A;for v ∈ A doif Pv ≤ CR then

yv = 1;pv = Pv;CR = CR − PV ;A = A− \{v};

end ifend forL = argmax

AUv;

yL = 1;pL = CR;Output: X and P.

According to (6), if an ESU is scheduled to charge duringthe current time slot, it receives its full charging request (Pv)in the current (single) time slot. The scheduling problemin (6) can be mapped to an optimization problem referredto as the knapsack problem [12]. In the knapsack problem,there is a knapsack with limited capacity and a set of itemseach with a given value (priority) and weight. The goal isto choose a subset of items to be packed in the knapsack,such that the total value is maximized while the knapsackcapacity limitation is respected. The charging coordinationproblem can be mapped to a knapsack problem as follows.First, the ESUs are mapped to the items. Then, the ESUpriority Uv is equivalent to the item value. And, the ESUcharging demand Pv is equivalent to the item weight. Fi-nally, the charging capacity limitation C is equivalent tothe knapsack capacity. A greedy algorithm for solving theknapsack problem in polynomial time complexity can beused to schedule ESU charging during a given time slot[12]. Hence, the charging coordination mechanism can bedescribed using Algorithm 2, which is executed by the CC.

Once the CC finalizes the charging coordination, it pre-pares the charging schedules {Sc(j,k)

v1 , Sc(j,k)v2 , · · · }, where

(Sc(j,k)v = PK

(`)v , [yv, pv]K(`)

v↔cc) should be encrypted using

the one-time key (K(`)v↔cc) sent by the ESU. Then, the CC

sends the following message msg5 to the aggregator

msg5 = {Sc(j,k)v1 , Sc(j,k)

v2 , · · · }‖σCC .

Finally, once the aggregator received msg5, it broadcaststhe message to the community. Each ESU knows its chargingschedule that corresponds to the public key included inthe charging schedule. Then, it can determine to charge bydecrypting the schedule using the shared secret key.

5 THE DCC SCHEME

In this section, we first give an overview to our schemeand then we discuss charging requests submission andaggregation, and charging schedules computation.

9

5.1 OverviewThe DCC scheme runs in a fully distributed way whereseveral ESUs should run the scheme to collect the totalamount of power and in the same time coordinate chargingdemands. However, the challenge is how a group of ESUscan collect individual requests, aggregate them, disseminatethe aggregated demands, and compute the charging sched-ules without support from infrastructure and with protec-tion against collusion attacks. In other words, although theESUs are not trusted, they should run the scheme securelyand without leaking sensitive information. In each timeslot, a number of ESUs are selected to act as aggregatingESUs. Each ESU selects a set of ESUs called proxies andshare a mask with each one. Each ESU then adds the maskto its charging request, encrypts it using homomorphicencryption, and sends it to the aggregating node as shownin Fig. 8. After that, the aggregating nodes decrypt theciphertext of the aggregated message of the ESUs requestsand broadcast it to the community ESUs but without beingable to access each ESU demand to preserve privacy. Then,charging schedules are calculated locally by each ESU toknow whether it can charge in the time slot and the amountof power it can charge. Note that, unlike the CCC scheme, inthe DCC, each ESU sends only one charging request in eachtime slot since no one have access to the charging demandof a specific ESU and only the total aggregated demand isknown.

To illustrate the idea, each request is represented as anfield element that can be encrypted using Paillier Cryp-tosystem. Each charging request message is divided intopriority levels (e.g., L1 ∈ [0, 0.1), L2 ∈ [0.1, 0.2), · · · , andL10 ∈ [0.9, 1]), and each priority level has a set of associatedbits that are used to report the amount of charging powerthe ESU needs if it has the priority level of the set. Forinstance, as in Fig. 9, consider for simplicity a field elementof size 1000 bits, and 10 priority levels L1 to L10, then afield element can be divided into 10 set of bits each of themis of size 100 bits. Also, consider a request from an ESU v1

denoted as R1 = 5 KW, and the priority of an ESU calculatedusing Eq. 2 lies in level L1, the ESU will use the rightmost 100 bits to write its charging needs and all other bitsshould be set as zero. Note that since all messages should beaggregated and to avoid arithmetic overflow, each prioritylevel should be assigned sufficient bits to avoid adding acarry for the next priority level. By this way, the aggregatedmessage gives the total charging demand for each prioritylevel (See RT in Fig. 9).

5.2 Charging Requests Submission and AggregationIn this phase, ESUs submits their charging messages to theaggregating node.

First, each ESU vi should generate a public/private keypair Yvi and xvi , where the private key xvi

R← Z∗q , the publickey is Yvi = xviP , q is a large prime number, and P isthe generator of a cyclic additive group G1. Also, the ag-gregating node should generate public key (NvA , gvA) andcorresponding private key δvA for homomorphic encryptionscheme, and broadcast the public key. Then, each ESU vichooses a shared secret mask svi with a group of ESUs calledproxies such that the ESU vi shares a mask svi,j with proxy

( + )�����

�1,1�1,1

�1,2

�1,3

�1,1

�2,2

�2,1

�2,3

(+

)

����

� �1,2 �1,2

(

+

)

�����

�1,3

�1,3

( + )

�����

�2,1 �2,1

(+

)

�����

�2,2�2,2

Aggregatingnode

( ) = ( )∑�=1

2

∑�=1

3

��,���,� ∑�=1

3

��,�Aggregatedchargingrequests=

Where, ( ) = ( ) = 0∑�=1

3

�1,� ∑�=1

3

�2,�

Group1Group2

(

+

)

� ��

� �

� 2,3

� 2,3

Fig. 8: Illustrative example of the data masking technique.By aggregating all requests, all masks are nullified andthe total charging demand for each priority level can becomputed.

Prioritylevels

�1

�2

��

⋮

0.1 10.2 ⋯ ⋯

5 0 0

⋯

0.30 0 0

0 0 21 0 0 0

20 * 74 * * *

8 0 0 0 0 0

0 0 25 0 0 0

70 00

0 0 0

51

0

0 28 0 00

�3

�4

�5 0 0

0

�6

�7

0

⋯

IndividualESU

srequests

Aggregatedrequests

Fig. 9: Charging requests structure and the data aggregationtechnique. The sum of the bits at i-th column represents thetotal charging demand needed by ESUs at a priority levelLi. For simplicity, the charging requests are represented indecimal rather than binary.

ESU vj for 1 ≤ j ≤ k where k is the number of proxy ESUssuch that

svi =k∑

j=1

svi,j

Then, to report a charging message Rjvi at a time slot j,each ESU vi uses the public key of the aggregating node’shomomorphic encryption (NvA , gvA ) and a random numberr ∈ Z∗n where r is known to all ESUs (e.g., r = H(date‖SN)where H is a hash function, date is the current date, andSN is a counter for the time slot of the day) to compute Cjviwhich is the encryption of Rjvi as follows.

10

Cjvi = gRjvivA r(NvA+svi ) mod N2

vA .

After that, the ESU signs Cjvi after appending a timestamp by computing σvi = xviH

(Cjvi‖TS

). The ESU sends

to the aggregating node the following packet Cjvi‖TS‖σvi .After the n ESUs in the neighborhood report their mes-

sages to the aggregating node, it verifies the charging mes-sage’s signatures with less overhead (fewer number of pair-ing operations), using a batch verification technique [18]. Inthis technique, instead of verifying n individual signatures,the signatures can be batched and one verification processis executed. The signatures are valid if e (P,

∑ni=1 σvi) =∏n

i=1 e(Yvi , H

(Cjvi‖TS

)). The proof for this is as follows:

e

(P,

n∑

i=1

σvi

)= e

(P,

n∑

i=1

xviH(Cjvi‖TS

)).

=n∏

i=1

e(P, xviH

(Cjvi‖TS

))

=n∏

i=1

e(Yvi , H

(Cjvi‖TS

))

Finally, if the signature verification succeeds, the aggre-gating node should aggregate the ciphertexts as follows:

CjT = Cjv1 × Cjv2 × . . .× Cjvn= g

Rjv1vA r(NvA+si) mod N2

vA × . . .× gRjvnvA r(NvA+sn) mod N2

vA

= g∑ni=1 R

jvi

vA × r∑ni=1 svi × r(n)N

= g∑ni=1 R

jvi

vA × r0 × r(n)N = g∑ni=1 R

jvi

vA × r(n)N

Then, the aggregating node should use its private key(δvA) to decrypt CjT and obtain the total aggregated chargingdemand RjT =

∑ni=1R

ji at a time slot j by computing

L

(CδvAT mod N2

vA

)L

(gδvAvA

mod N2vA

) mod NvA . By aggregating all the mes-

sages, the set of bits that correspond to a priority level Li,gives the total charging demand needed by all the ESUs inthe community that have a priority level Li.

It is important to note that the purpose of adding a maskby an ESU vi and removing it by other proxy ESUs messagesis to:

1) Prevent vA from knowing the demand of one ESU be-cause given Cjvi = gR

jvi rN+si , vA cannot use its private

key to decrypt the message because the exponent of rshould be N , but given CjT = g

∑ni=1 R

jvi (rn)N , vA can

decrypt this message using its private key. Note thatrn or r does not make a difference in the decryptionbecause both are random numbers.

2) Protect against collusion attack since to get the chargingdemand of an ESU vi, vA has to collude with allthe proxy ESUs to obtain svi,j for j = {1, 2, ..., k} tocompute svi and then compute Rjvi as follows:

r−sviCjvi = gRjvi rN+svi r−svi = gR

jvi rN

Then, vA uses its private key to decrypt gRjvi rN to obtain

Rjvi .

For simplicity, it is assumed that there is only one aggre-gating node, but the scheme can easily be extended to havemultiple aggregating nodes. Therefore, if one aggregatingnode is not trusted in reporting the total demand correctly,aggregation can be performed by more than one aggre-gating node and the total demand can be broadcasted bythe aggregating nodes. Also, the aggregating nodes shouldcontinuously change to distribute the decryption overheadon other community nodes.

5.3 Charging Schedules ComputationAfter vA computes the aggregated charging message (RjT ≤Cj), the aggregating node broadcasts it to all the ESUs.Then, if RjT ≤ Cj , where Cj is the maximum chargingcapacity, then all requests are granted to charge since thereis enough energy to serve the demands of all the ESUs. IfRjT > Cj , then ESUs with highest priority should chargewithout exceeding the maximum capacity Cj . This is doneas follows. Assume Li is the priority level at which ESUs cancharge. Each ESU comparesCj to the total charging demandof priority levels, from the highest level to the lowest level,until it finds the first level Li at which the total accumulateddemand is greater than or equal to the maximum chargingcapacity. In other words, Li is the lowest priority level thatguarantees the condition

∑Lmaxl=Li

R(j,l)T ≤ Cj , where Lmax is

the maximum priority level, and R(j,l)T is the total charging

demand of a priority level at a time slot j. If the totalcharge capacity is equal to the total charging demand ofthese priority levels, then all the ESUs that have prioritylevel greater than or equal to Li can charge and the otherESUs do not charge in this time. If the power demand ofall the sets from the highest priority to priority level Li isgreater than the total charging capacity, then all the ESUsthat have priority greater than Li should charge and forfull utilization of the available charging power capacity. Theremaining power is charged by the ESUs of priority level Li.The power Evi that an ESU vi of the priority level Li shouldcharge is given by:

Evi = ∆× Rjvi

R(j,Li)T

, (7)

where R(j,Li)T is the demand energy by the ESUs with

priority level Li, and ∆ is given by

∆ = Cj −Lmax∑

l=Li

R(j,l)T . (8)

To illustrate the idea of charging schedules computation,we present a numerical example using ten ESUs and acommunity capacity C of 300KW. Table 2 gives the powerdemands and priorities of each ESU that are selected arbi-trarily. Table 3 gives the corresponding charging requests ofall ESUs. Once the aggregating node vA computes the totalcharging message (As shown in the last row of Table 3), thetotal demand is broadcasted to all ESUs in the community.After receiving this message, each ESU finds the prioritylevel Li, and determine whether they can charge or cannotcharge, to reduce their charging demands by using Eq. 7. Inthis example, Li is level 4, since

∑10l=4R

(l)T = 210KW, and

11

TABLE 2: Demand and final charging schedules.

ESU viPower demand

(KW) (Ri)Priority (U ) Level (L)

1 10 0.333 42 30 0.250 33 50 1 104 60 0.166 25 90 0.333 46 20 0.143 27 5 0.143 28 40 0.500 69 20 1 1010 70 0.200 3

Total 395

TABLE 3: Charging packets and priority levels.

ESU L10 L9 L8 L7 L6 L5 L4 L3 L2 L1

1 0 0 0 0 0 0 10 0 0 02 0 0 0 0 0 0 0 30 0 03 50 0 0 0 0 0 0 0 0 04 0 0 0 0 0 0 0 0 60 05 0 0 0 0 0 0 90 0 0 06 0 0 0 0 0 0 0 0 20 07 0 0 0 0 0 0 0 0 5 08 0 0 0 0 40 0 0 0 0 09 20 0 0 0 0 0 0 0 0 0

10 0 0 0 0 0 0 0 70 0 0RT 70 0 0 0 40 100 0 100 85 0

TABLE 4: Initial and final charging.

ESU viOriginaldemand (Ri) Schedule (Ei)

1 10 102 30 273 50 504 60 05 90 906 20 07 5 08 40 409 20 2010 70 63

Total 395 300

including level 3 would result in exceeding the capacitysince

∑10l=3R

(l)T = 310KW. By using the formula in 8, ∆ =

300KW - 210KW = 90KW. Because priority level 3 is the firstlevel exceeding the capacity, all ESUs with at least level 4can charge. Additionally, those at level 3 i.e., ESUs 2 and 10compute the amount of energy they can charge according touse formula in 7 as follows,

Ev2 = 90× 30

310= 27, Ev10 = 90× 70

310= 63,

and those with level 2 or below, should not charge in thecurrent time slot and need to submit new charging requestsin the next time slot.

Finally, Table 4 gives the charging schedules, where thesecond column gives the initial charging request, and thethird column gives the charging schedule including theamount of power each ESU can charge.

6 SECURITY AND PRIVACY ANALYSIS

In this section, we discuss and analyze the security andprivacy of our schemes.

6.1 CCC scheme6.1.1 Resistance to Linkabilty AttacksBy submitting multiple requests with random SoC and TCCinstead of only one request, it is hard for the CC to linkrequests sent from the same ESU using SoC and TCC.However, since the priorities of requests of an ESU are pro-portional to its priority, the CC could use this information toattempt linkability attacks on charging requests. However,due to the probabilistic nature of priorities of the chargingrequests, the priorities of the charging requests of differentESUs may overlap which can confuse the CC and make thelinkability difficult.

In order to assess our scheme under various linkabilityattack scenarios, different linkablity attacks are consideredin our evaluation; (i) Using both SoC and TCC; and (ii)Using charging requests priorities.

We have used Matlab to evaluate success probability ofdifferent linkability attacks. We set the number of ESUs to80, and the community charging capacity was set at 1000kW.We set the ESUs battery capacity to 100 kW, and the SoC ofeach ESU battery is a random number uniformly distributedin [0, 1]. The TCC range was set to a random number in{1, · · · , 48} and a total of 30 time slots are simulated. Thevalues of α1 and α2 were selected as 0.9 and 0.1 respectively.

The simulations results depicted in Fig. 10a presentsthe probability of successful linkability attack using SoCand TTC. It can be clearly seen that our scheme reducesthe ability of CC to launch a successful linkability attackusing SoC and TTC at different time slots. Also, as thenumber of requests per ESUs increases, as the probabilityof successfully linking charging requests decreases. Thisis because as the number of requests per ESU increases,as the overlap between charging requests increase makinglinkability attack less successful.

In case of using priorities of ESUs to launch linkability at-tacks, Fig. 10b shows that low success probability comparedto the previous case, i.e., using SoC and TCC. This is becauseof using of short-range values of priorities and the use of thenon linear priority function ( Eq. 2) that transforms the SoCand TCC values into priority values that could be close toeach other. Also, in case of an increasing number of requestsper ESU, results show similar performance since our schemeensures priority of several requests overlap, making it veryhard to the CC to use the priority to link charging requestsof ESUs at different time slots.

6.1.2 Resistance to Other Attacks• Resistance to collusion attacks. By using PBS during the

acquisition of anonymous tokens, each ESU can anony-mously authenticate its charging requests sent to theaggregator without the need to reveal its real identity.If the CC and the aggregator collude, they cannot inferthe SoC/TCC of an ESU because the CC signature onthe tokens is not linkable. Moreover, by using a one-time generated identity that is not linkable to an ESU,the privacy of the ESUs is preserved.

12

0 10 20 30 40 50 60 70 800

0.2

0.3

0.4

0.5

0.6

Our scheme (with five requests)Our scheme (with three requests)One request

(a) Using both SoC and TTC of charging requests.

0 10 20 30 40 50 60 70 800

0.2

0.4

0.6

0.8

1

Our scheme (with five requests)

Our scheme (with three requests)

One Request

(b) Using charging request’s priority.

Fig. 10: Evaluation of linkability attacks using different cases.

• Data authentication. All the messages in our scheme areauthenticated to ensure that legitimate ESUs send thosemessages. This authentication is done using signatures.Each ESU obtains anonymous tokens signed by the CC.The CC verifies the signature once a token is usedalong with a charging request. This signature on theanonymous token guarantees that the request is sentby a legitimate ESU member of a community, as onlylegitimate ESUs in this community could obtain validtokens from the CC because the ESU should sign toobtain tokens.

• Resistance to replay attacks and token reuse. To preventreplay attacks, all the messages in our scheme have asigned fresh timestamp. In addition, since the CC keepsa record of previously used tokens by storing their hashvalues; if an ESU attempts to reuse a token, the CC candetect and discard this request.

• Confidentiality of charging schedules. The SoC and TCCare encrypted with a secret key that is only known tothe CC and the ESU that sends the charging request.Also, the encryption key is encrypted by the CC’spublic key and the ciphertext is sent to the CC. Thisensures that only the CC can decrypt the ciphertextand use the symmetric encryption key when sendingthe charging schedule back to the ESU. By this way,only ESUs can know their charging schedules.

6.2 DCC scheme

• Privacy preservation. In DCC, any ESU cannot knowcharging report messages of other ESUs. This is doneby aggregation and secret masks addition. By using ag-gregation, only the total charging report can be known.Also, due to the aggregation technique, the aggregatingnode (s) cannot link charging requests to a specific ESUowner in consecutive time slots. By this way, linkabiltyin the DCC is mitigated.

• Resistance to collusion attacks. By using secret masks tomask the ESUs’ messages, the aggregating node thatknows the private key of the homomorphic encryptionscheme has to collude with a number of ESUs (proxyESUs) to decrypt the message, using the mask sharedwith the proxy ESUs. With using enough number ofproxy ESUs, the attack can be infeasable because thehead ESU has to collude with a large number of proxy

ESUs. To evaluate the protection against collusion, wedefine a probability formula. If m ESUs are maliciousnodes colluding with the aggregating node from a totalof n ESUs in the community, with m > δ, and δ is thenumber of proxy ESUs, the probability of vA colludingwith all δ ESUs out of a total of n ESUs, follows ahypergeometric distribution. The probability distribu-tion function (PDF) of the hypergeometric probabilitydistribution is given by:

pdf(x|n,m, λ) =

(mx

)(n−mλ−x

)(nλ

)

where x is the number of malicious ESUs included inthe selection of λ ESUs out of n ESUs. This probabilitydistribution corresponds to the number of successfulselections of λ proxies among m malicious ESUs.The probability of the vA colluding with all λ proxynodes is plotted in Fig. 11 based on various values of mand λ, where the number of ESUs in the network is n= 300. From Fig. 11, it can be clearly seen that when anESU selects λ = 4 proxies, roughly 1% out of the totalnumber of ESUs in the community, and the numberof malicious ESUs is m = 100, or 30% of the total nESUs, the probability of revealing a charging demandof an ESU by vA is 0.07, the probability of revealinga charging demand of an ESU drops to 0.01 for thecase of selecting 8 proxy ESUs. As the number of proxiesincreases, it becomes more difficult for vA to recover thecharging demands of the ESUs. Note that if the number ofproxies selected is λ = 16, the probability of recoveringa charging demand by vA becomes around zero. Thisis under the assumption that there are already 100malicious nodes colluding with vA, which in realityis a very large number. If the number of maliciousESUs is increased to 200, or 66% of the total ESUsin the community, then the probability of revealing acharging request data by the vA becomes one. If furtherprotection is needed, then the number of proxy ESUs shouldbe increased.

7 PERFORMANCE EVAULATIONS

In this section, we evaluate the charging coordinationschemes followed by the communication and computaionoverheads.

13

0 50 100 150 2000

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

=4=8=16

Fig. 11: Probability of revealing a charging request data bycolluding with λ proxies.

7.1 Charging Coordination7.1.1 Metrics and BaselinesIn both schemes, we consider charging index as the perfor-mance metric for charging coordination. Charging index isdefined as the number of ESUs with charging requests thatexpire without fully charging. Lower values of this metricindicate higher ESU charging energy and hence efficientutilization of the energy resources and smarter schedulingof ESUs charging. We compare our charging coordinationschemes with first come first serve (FCFS) benchmark. Inthis approach, the ESU that requests charging first getscharged first.

For both schemes, the capacity C is assumed to be1,000kW, with the priority of each charging request perESU is computed using Eq. 2 with TCC values are selectedrandomly from 1 to 48, and SoC values are selected ran-domly from 1 to 100kW. For the DCC, ten different levels ofpriorities are used, where the levelL1 corresponds to [0, 0.1),level L2 corresponds to [0.1, 0.2), and so on until L10, whichcorresponds to the range of priorities [0, 1]. The numberof ESUs was varied with increments of one in each run,ranging from 1 to 80, and 30 time slots were considered. Forthe CCC and DCC, 100 runs were performed over a periodof 30 time slots and the average is presented.

7.1.2 CCC SchemeFig. 12a gives the number of ESUs that do not fully chargebefore TCC expires versus the number of ESUs. It can beseen that as the number of charging requests increases,our scheme outperforms the FCFS scheme. This perfor-mance improvement is noticeably more significant whenthe number of ESUs increases to larger numbers. With theparameters used, the improvement starts when the numberof ESUs is 20. This is attributed to the fact that unlike FCFSscheme, our scheme prioritizes the requests and charge thehigh priority requests before they expire.

7.1.3 DCC SchemeFig. 12b gives the number of ESUs that were not ableto charge before their charging request expired. It can be

observed that the proposed DCC outperforms FCFS, byallowing a greater number of ESUs to charge with theavailable energy resources. An increase in the number ofESUs without full charge is observed when 20 ESUs com-pete for the available allocated community capacity. This isbecause DCC scheme charges the high priorty requests first.The number of ESUs leaving without full charge in FCFSis greater than that of the proposed scheme because ourscheme uses priority to select the ESUs that should chargefirst, FCFS charges based on the time of arrival of the ESU’srequest. Additionally, with larger increments of the numberof ESUs, the performance gap widens considerably betweenthe two schemes.

7.2 Communication OverheadWe assume for the DCC that the average number of levels inthe charging message by each ESU is 20, each level identifierrequires 5 bytes, and the time-stamp requires 8 bytes. Oursignature scheme uses elliptic curve cryptography that hassmaller key sizes than the Rivest–Shamir–Adleman (RSA)scheme for the same security level. The security strength of224-bit key in ECC is equivalent to that of 2048-bit key inthe RSA cryptosystem [19]. Using an elliptic curve additivegroup of order 224 bits, the signature’s size is 56 bytes [20].Using these numbers, we calculate the size of packets in ourschemes.

7.2.1 CCC SchemeThe size of the one-time public key is 56 bytes, assumingthat the order of q is 224 bits and 56 bytes for the one-timesymmetric key that is encrypted by the CC public key. Inthe acquisition of tokens phase in Fig. 5, an ESU needs tosend msg1 that has 56 bytes for the blinded token message,8 bytes for the time stamp, and signature. The total size ofthe packet is 120 bytes. The CC should reply with msg2 thatcontains partial blind signature that is 65 bytes. In Fig. 6,a charging request msg3 contains 112 bytes for the token,56 for the BPS, 16 bytes for ciphertext of SoC and TCC,8 bytes for the time-stamp and 56 bytes for its signatureon the whole message. The total size of msg3 is 248 bytes.msg4 contains all charging requests within a time-slot. msg4

contains N tokens as well as the PBS of CC signatureon each token, and the cipher-text of SoC and TTC, i.e.,N × (112 + 16), also it contains 56 for aggregated signatureand 56 for the aggregator’s signature on the whole message.Therefore, the total size of msg4 is given as function of num-ber of requestsN within a time a slot as: 128×N+112 bytes.Finally, msg5 contains all charging schedules within a time-slot. It contains the schedule encrypted by the symmetrickey of the ESU (16 bytes) and a signature on the wholemessage (56 bytes). Therefore, the total size of msg5 as afunction of N is given as N × 16 + 56 bytes.

7.2.2 DCC SchemeIn DCC, the size of the packet that is sent from a aggregatingnode to publicize the public keys is 164 bytes. The size of thehomomorphic encryption ciphertext is equal to double N . Ifwe choose N to be 2048 bits, then the ciphertext size equalsto 512 bytes. The charging report packet includes the homo-morphic encryption, timestamp, and the ESU signature. Thetotal packet size is 576 bytes.

14

0 10 20 30 40 50 60 70 800

10

20

30

40

50

60

5 Requests3 Requests1 RequestFCFS 1 Req.

(a) CCC scheme.

0 10 20 30 40 50 60 70 800

10

20

30

40

50

60

One RequestFCFS 1 Req.

(b) DCC scheme.

Fig. 12: Charging coordination evaluation.

7.3 Computation OverheadWe measured the computation time of the multiplication,pairing, and exponentiation operations using Python charmcryptographic library [21] running on Intel Cor i5-7300HQCPU 2.50GHz × 4 with 8 GB Ram. We used supersingularelliptic curve with the asymmetric Type 3 pairing of size 224bits (MNT224 curve) for bilinear pairing. Our measurementsindicate that the multiplication (Mul), exponentiation (Exp),and pairing (Pair) operations take 0.005, 9, and 4.4 ms,respectively. Note that the addition operation takes rela-tively very short time so it can be neglected. For symmetricencryption, using AES-128, the encryption operation (Enc)takes 0.0203 ms while the decryption operation (Dec) takes0.0078 ms.

7.3.1 CCC SchemeIn the acquisition of tokens phase, an ESU needs 5 ×Mul=0.025 ms. The CC needs 1 × Mul + 1 × Pair = 4.45ms. To send a charging request to the aggregator, an ESUneeds 1 × Mul + 1 × EnC = 0.025 ms. Upon receivingcharging requsets N , the aggreagor needs to verify a batchof signatures rather than verifying individual signatures.Batch and individual signature verifications require N + 1and 2N pairing operations, respectively. Finally, the CCneeds to verify the aggregated signature that need N + 1pairing operations andN decryption (Dec) operation. Then,preparing the charging schedules take N × Enc. Therefore,the total is (N + 1) × Pair + N × (Enc + Dnc) = 4.4 × Nms.

7.3.2 DCC SchemeIn DCC, the computation overhead is as follows.• ESUs: Each ESU encrypts its charging report that needs

one exponential and one multiplication operations tosign its message. The ESU takes 10.15 ms to composeits charging report packet.

• The aggregating node: verifies a batch of signaturesrather than verifying individual signatures. Batch andindividual signature verifications requireN+1 and 2Npairing operations, respectively. The aggregating nodedecrypts the aggregated charging messages by com-puting one exponential operation. Thus, to aggregateand sign i charging report, the aggregating node needs3× i× 4.4 = 13.2i ms.

8 RELATED WORK

Several works have investigated the problem of chargingcoordination in the smart grid, such as [5]–[11], [22]–[24],but they do not take privacy into consideration. In [22], adistributed Vehicle-to-grid (V2G) control system is proposedto satisfy the EVs charging requirements. Tushar et. al. [23]propose an energy management technique to encourageEVs’ owners to participate in energy trading based on agame theoretic approach. Sortomme et. al. [24] proposedan algorithm to optimize energy and ancillary servicesscheduling. The algorithm maximizes profits to the EVswhile providing additional system flexibility and peak loadshaving to the utility and low costs of EV charging to thecustomer.

Although several privacy-preserving schemes have beenproposed for the smart grid [18], [25]–[27], the privacyproblem we address in this paper is different. In [25], aprivacy preserving communication protocol for power in-jection in smart grid have been proposed. The aggregatorcollects masked bids from the storage units and sends theaggregated bid to the utility company rather than sendingindividual bids. The proposed scheme cannot be used forcharging coordination because the CC needs the ESUs’individual charging demands. In [28], an authenticationprotocol for EVs has been proposed to protect the locationof the EVs. Li et. al. [29] proposed an anonymous andauthenticated reporting scheme for EVs.

Unlike [28] and [29] that address the privacy problemfor EVs on roads and charging stations, we consider differ-ent network model by addressing the problem for energyunits of communities. In [27], the authors used a dataobfuscation mechanism and proposed secure and efficientalgorithms to distribute obfuscation values within an AMInetwork. In, a decentralized charging coordination has beenproposed based on the blockchain to enable a transparent,reliable charging coordination among ESUs. However, whileblockchain can reduce the reliance on intermediaries, thescheme cannot be used where there is no reliable commu-nication, e.g., in remote areas. Also, other schemes haveconsidered security and privacy issues

9 CONCLUSION

In this paper, two privacy-preserving and collusion-resistantcharging coordination schemes for smart grid have been

15

proposed. Analysis, simulations, and experiments were con-ducted to study different attacks and evaluate the proposedschemes. The results indicate that the schemes are secureagainst the considered attacks, the communication andcomputation overheads are acceptable, and an improvedperformance compared with FCFS charging coordinationespecially at large charging demand scenario. In the CCCscheme, by acquiring anonymous and unlinkable tokensfrom the CC, ESUs can authenticate their charging requestsanonymously and therefore a collusion attack between theCC and aggregator is mitigated. In addition, by sendingmultiple charging requests with random TCC and SoC thatfollow a truncated normal distribution, the CC can knowenough data to run our charging coordination scheme, butit cannot link the data to particular ESUs. In the DCCscheme, charging is coordinated in a distributed way usingdata aggregation technique and homomorphic encryption topreserve ESUs’ owners privacy. Moreover, more protectionagainst collusion attacks can be achieved by increasing thenumber of proxy ESUs.

APPENDIX ASAMPLING FROM TRUNCATED NORMAL DISTRIBU-TION

The PDF of the truncated normal distribution can givenby [17].

ψ(µ, s, a, b;x) =

0 if x ≤ aφ( x−µs )

s(Φ( b−µs )−Φ( a−µs ))if a < x < b

0 if b ≤ x(9)

Where µ and s are the mean and variance, and a and bspecify the lower and upper truncation interval. In addition,φ and Φ are the PDF and CDF of the standard normaldistribution respectively that are given as follows

φ (x) =1√2πe−x

2/2, (10)

Φ (x) =1

2

(1 + erf

(x√2

)), (11)

where erf is the standard error function [30].To sample from the PDF of truncated normal distribu-

tion (i.e., Eq. 9), we can use inverse transform samplingmethod [31]. In this method, we first calculate the CDFof Eq. 9 then we get the inverse function of the CDF.Subsequently, we sample form known distribution such asuniform distribution and substituting the sample in theinverse function of the CDF. Thus, we can get a samplefrom the truncated normal distribution. This can be doneas follows.

First, the CDF of truncated normal distribution in (9) canbe given by

Ψ(µ, s, a, b;x) =

0 if x ≤ aΦ( x−µs )−Φ( a−µs )Φ( b−µs )−Φ( a−µs )

if a < x < b

1 if b ≤ x(12)

To sample from a truncated normal distribution, weassume we have some function rand() which is a sourceof uniform random numbers in the range [0,1] which weuse to apply the inverse CDF function as follows:

p = rand()

x = Ψ−1(µ, s, a, b; p)

where Ψ−1 can be calculated from Eq. 12 to get x

x = Φ−1(Φ(a− µs

) + p ∗ (Φ(b− µs

) + Φ(a− µs

))) ∗ s+ µ

Here Φ−1(y) is given by√

2 erf −1(2y − 1).1

REFERENCES

[1] J. Wang, G. R. Bharati, S. Paudyal, O. Ceylan, B. P. Bhattarai,and K. S. Myers, “Coordinated electric vehicle charging withreactive power support to distribution grids,” IEEE Transactionson Industrial Informatics, vol. 15, no. 1, pp. 54–63, Jan 2019.

[2] M. Mahmoud, M. Ismail, P. Akula, K. Akkaya, E. Serpedin, andK. Qaraqe, “Privacy-aware power charging coordination in futuresmart grid,” Proc. of 2016 IEEE Wireless Communications and Net-working Conference (WCNC), Doha, Qatar, April 2016.

[3] Y. Yang, Q. Jia, G. Deconinck, X. Guan, Z. Qiu, and Z. Hu,“Distributed coordination of ev charging with renewable energy ina microgrid of buildings,” IEEE Transactions on Smart Grid, vol. 9,no. 6, pp. 6253–6264, Nov. 2019.

[4] W. Tang, S. Bi, and Y. J. Zhang, “Online charging schedulingalgorithms of electric vehicles in smart grid: An overview,” IEEEcommunications Magazine, vol. 54, no. 12, pp. 76–83, Dec. 2016.

[5] V. del Razo and H.-A. Jacobsen, “Smart charging schedules forhighway travel with electric vehicles,” IEEE Transactions on Trans-portation Electrification, vol. 2, no. 2, pp. 160–173, June 2016.

[6] S. Yang, S. Zhang, and J. Ye, “A novel online scheduling algorithmand hierarchical protocol for large-scale ev charging coordina-tion,” IEEE Access, pp. 101 376–101 387, 2019.

[7] S. Zou, Z. Ma, X. Liu, and I. Hiskens, “An efficient game for coor-dinating electric vehicle charging,” IEEE Transactions on AutomaticControl, vol. 62, no. 5, pp. 2374–2389, May 2017.

[8] R. A. Verzijlbergh, M. O. W. Grond, Z. Lukszo, J. G. Slootweg,and M. D. Ilic, “Network impacts and cost savings of controlledev charging,” IEEE Transactions on Smart Grid, vol. 3, no. 3, pp.1203–1212, 2012.

[9] Z. Ma, D. S. Callaway, and I. A. Hiskens, “Decentralized chargingcontrol of large populations of plug-in electric vehicles,” IEEETransactions on Control Systems Technology, vol. 21, no. 1, pp. 67–78, 2011.

[10] M. F. Shaaban, M. Ismail, E. F. El-Saadany, and W. Zhuang, “Real-time pev charging/discharging coordination in smart distributionsystems,” IEEE Transactions on Smart Grid, vol. 5, no. 4, pp. 1797–1807, 2014.

[11] M. Wang, M. Ismail, X. Shen, E. Serpedin, and K. Qaraqe, “Spa-tial and temporal online charging/discharging coordination formobile pevs,” IEEE Wireless Communications, vol. 22, no. 1, pp.112–121, 2015.

[12] H. Kellerer, U. Pferschy, and D. Pisinger, “Knapsack problems,”Springer, Berlin, 2004.

[13] M. Mahmoud and X. Shen, “A secure payment scheme with lowcommunication and processing overhead for multihop wirelessnetworks,” IEEE Transactions on Parallel and Distributed Systems,vol. 24, no. 2, pp. 209–224, 2013.

[14] T. Okamoto, Efficient Blind and Partially Blind Signatures WithoutRandom Oracles. Berlin, Heidelberg: Springer Berlin Heidelberg,2006, pp. 80–99. [Online]. Available: https://doi.org/10.1007/11681878 5

[15] F. Zhang, R. Safavi-Naini, and W. Susilo, “Efficient verifiably en-crypted signature and partially blind signature from bilinear pair-ings,” in International Conference on Cryptology in India. Springer,2003, pp. 191–204.

1. [32]–[44]

16

[16] P. Paillier, “Public-key cryptosystems based on composite degreeresiduosity classes,” in Advances in Cryptology — EUROCRYPT ’99,J. Stern, Ed. Berlin, Heidelberg: Springer Berlin Heidelberg, 1999,pp. 223–238.

[17] J. Burkardt, “The truncated normal distribution,” Department ofScientific Computing Website, Florida State University, 2014.

[18] R. Lu, X. Liang, X. Li, X. Lin, and X. Shen, “Eppa: An efficientand privacy-preserving aggregation scheme for secure smart gridcommunications,” IEEE Transactions on Parallel and DistributedSystems, vol. 23, no. 9, pp. 1621–1631, Sept 2012.

[19] A. K. Lenstra and E. R. Verheul, “Selecting cryptographic keysizes,” in International Workshop on Public Key Cryptography.Springer, 2000, pp. 446–465.

[20] M. Raya and J.-P. Hubaux, “Securing vehicular ad hoc networks,”Journal of computer security, vol. 15, no. 1, pp. 39–68, 2007.

[21] J. A. Akinyele, C. Garman, I. Miers, M. W. Pagano, M. Rushanan,M. Green, and A. D. Rubin, “Charm: a framework for rapidlyprototyping cryptosystems,” Journal of Cryptographic Engineering,vol. 3, no. 2, pp. 111–128, 2013.

[22] Y. Ota, H. Taniguchi, T. Nakajima, K. M. Liyanage, J. Baba, andA. Yokoyama, “Autonomous distributed V2G (vehicle-to-grid)satisfying scheduled charging,” IEEE Transactions on Smart Grid,vol. 3, no. 1, pp. 559–564, 2012.

[23] W. Tushar, J. Zhang, D. Smith, H. Poor, and S. Thiebaux, “Priori-tizing consumers in smart grid: A game theoretic approach,” IEEETransactions on Smart Grid, vol. 5, no. 3, pp. 1429–1438, May 2014.

[24] E. Sortomme and M. El-Sharkawi, “Optimal scheduling of vehicle-to-grid energy and ancillary services,” IEEE Transactions on SmartGrid, vol. 3, no. 1, pp. 351–359, March 2012.

[25] P. Akula, M. Mahmoud, K. Akkaya, and M. Song, “Privacy-preserving and secure communication scheme for power injectionin smart grid,” Proc. of IEEE International Conference on Smart GridCommunications, 2015.

[26] A. Alsharif, M. Nabil, M. Mahmoud, and M. Abdallah, “Privacy-preserving collection of power consumption data for enhancedAMI networks,” Proceedings of the 25th International Conference onTelecommunications (ICT), June 2018.

[27] S. Tonyali, O. Cakmak, K. Akkaya, M. Mahmoud, and I. Guvenc,“Secure data obfuscation scheme to enable privacy-preservingstate estimation in smart grid ami networks,” IEEE Internet ofThings Journal, vol. 3, no. 5, pp. 709–719, 2015.

[28] H. Li, G. Dan, and K. Nahrstedt, “Portunes: Privacy-preservingfast authentication for dynamic electric vehicle charging,” Proc. ofIEEE International Conference on Smart Grid Communications (Smart-GridComm), pp. 920–925, Nov 2014.

[29] H. Li, G. Dan, and K. Nahrstedt, “Lynx: Authenticated anonymousreal-time reporting of electric vehicle information,” Proc. of IEEESmartGridComm, Miami, Florida, 2015.

[30] Wikipedia, error function. [Online]. Available: https://en.wikipedia.org/wiki/Error function

[31] L. Devroye, “Sample-based non-uniform random variate genera-tion,” in Proc. of the 18th conference on Winter simulation. ACM,1986, pp. 260–265.

[32] M. Baza, M. Nabil, M. Ismail, M. Mahmoud, E. Serpedin, andM. Rahman, “Blockchain-based privacy-preserving charging co-ordination mechanism for energy storage units,” arXiv preprintarXiv:1811.02001, 2019.

[33] M. Baza, N. Lasla, M. Mahmoud, G. Srivastava, and M. Abdallah,“B-ride: Ride sharing with privacy-preservation, trust and fairpayment atop public blockchain,” IEEE Transactions on NetworkScience and Engineering, 2019.

[34] M. Baza et al., “Blockchain-based firmware update scheme tailoredfor autonomous vehicles,” Proc. of the IEEE Wireless Communica-tions and Networking Conference (WCNC), Marrakech, Morocco, April2019.

[35] M. Baza, A. Salazar, M. Mahmoud, M. Abdallah, and K. Akkaya,“On sharing models instead of the data for smart health applica-tions,” Proc. of IEEE International Conference on Informatics, IoT, andEnabling Technologies (ICIoT’20), Doha, Qatar, 2020.

[36] M. Baza et al., “Detecting sybil attacks using proofs of work andlocation in vanets,” arXiv preprint arXiv:1904.05845, 2019.

[37] M. Baza, M. Mahmoud, G. Srivastava, W. Alasmary, and M. You-nis, “A light blockchain-powered privacy-preserving organizationscheme for ride sharing services,” Proc. of the IEEE 91th VehicularTechnology Conference (VTC-Spring), Antwerp, Belgium, May 2020.

[38] W. Al Amiri, M. Baza, M. Mahmoud, W. Alasmary, and K. Akkaya,“Privacy-preserving smart parking system using blockchain and

private information retrieval,” Proc. of the IEEE International Confer-ence on Smart Applications, Communications and Networking (Smart-Nets 2019), 2020.

[39] M. Baza et al., “Blockchain-based charging coordination mecha-nism for smart grid energy storage units,” Proc. Of IEEE Interna-tional Conference on Blockchain, Atlanta, USA, July 2019.

[40] A. Shafee and M. Baza, “Mimic learning to generate a shareablenetwork intrusion detection model,” Proc. of the IEEE ConsumerCommunications & Networking Conference,Las Vegas, USA, 2020.

[41] M. Baza, j. Baxter, N. Lasla, M. Mahmoud, M. Abdallah, andM. Younis, “Incentivized and secure blockchain-based firmwareupdate and dissemination for autonomous vehicles,” Transporta-tion and Power Grid in Smart Cities: Communication Networks andServices, 2020.

[42] M. Baza et al., “An efficient distributed approach for key manage-ment in microgrids,” Proc. of the Computer Engineering Conference(ICENCO), Egypt, pp. 19–24, 2015.

[43] W. Al Amiri, M. Baza, M. Mahmoud, W. Alasmary, and K. Akkaya,“Towards secure smart parking system using blockchain tech-nology,” Proc. of 17th IEEE Annual Consumer Communications &Networking Conference (CCNC), Las vegas, USA, 2020.

[44] M. Baza et al., “Blockchain-based distributed key managementapproach tailored for smart grid,” Combating Security Challengesin the Age of Big Data, 2020.