S-BAN: Secure Blockchain-Based Anonymous Networking Strategy for Privacy-Preserving DSM

Demand-side management (DSM) is an essential tool in smart power grids to enable efficient energy utilization. In DSM, customers send their fine-grained energy consumption data to the utility company (UC). This fine-grained data can reveal private information about the customers. Hence, many privacy-preserving proposals are made to overcome such a threat. However, existing mechanisms do not satisfy both customer anonymity and data unlinkability. To address this limitation, we propose a blockchain-based anonymous networking strategy called (BAN) that uses group signatures and unique random identifiers on top of a blockchain network to provide the desirable features. However, our security analysis reveals that adopting anonymous signatures on top of blockchains opens the door to other forms of cyber-attacks, such as denial-of-service (DoS), man-in-the-middle (MitM), and traffic analysis attacks. Hence, we propose a secure BAN (S-BAN) network that upgrades the BAN to enable secure and privacy-preserving DSM. The S-BAN is based on a novel onion routing with blockchain interconnected servers strategy (ORBITS). Our implementation of the proposed strategy demonstrates low computation and communication overheads. The S-BAN can handle messages from up to 12,000 customers in a DSM period of 15 minutes.


I. INTRODUCTION
In traditional power grids, energy generation follows the demand, which is inefficient from environmental and investment perspectives.Demand-side management (DSM) allows the modern power grid to incentivize customers to decrease or increase their consumption to follow energy generation.For instance, DSM programs saved 29.9 TWh in 2017 [1].Enabling DSM programs requires two-way communication between customers and the utility company (UC) so that customers send their fine-grained energy consumption data to the UC, and the UC replies with messages to control the customers' consumption based on the available energy.
The associate editor coordinating the review of this manuscript and approving it for publication was Zijian Zhang .
DSM programs are classified into price-based DSM and direct load control (DLC) DSM.In price-based DSM, the UC sets the electricity price according to the difference between customers' total consumption and the amount of electricity generation.If the consumption approaches the electricity generation, the UC increases the electricity price and vice versa [2], which discourages or encourages customer energy consumption.On the other hand, in DLC-based DSM, the appliances of each customer are divided into three categories: (a) adjustable (e.g., air conditioners), (b) time-shiftable (e.g., dishwasher), and (c) fixed (e.g., TV).Customers concatenate the devices' consumption in each category and send the data to the UC, which replies by a control signal including an energy adjustment value for the adjustable appliances and/or a time-shift value for the time-shiftable devices [3].However, all DSM programs threaten customers' privacy.Analyzing the consumption data released by customers can reveal private information about customers' behavior like the presence inside the house and the currently used appliances [4].Hence, a privacy-preserving networking strategy is essential to motivate more customers to enroll in such DSM programs.

A. RELATED WORK AND LIMITATIONS
Privacy-preserving DSM strategies in the literature can be divided into (a) data privacy and (b) user privacy.Data privacy means the customers' identities are known to all entities in the system, while the consumption data is hidden.On the other hand, user privacy means all entities can access consumption data without knowing the data owners.Data privacy is achieved by differential privacy, homomorphic encryption, or rechargeable batteries.Differential privacy is used in [5] where customers add noise to their energy consumption value before sending it to the UC.Unfortunately, higher noise values need to be added to achieve a higher level of customer privacy due to the trade-off between customer privacy and data accuracy in differential privacy as discussed in [6].The authors in [7] employ homomorphic encryption in price-based DSM.The technique suffers from a singlepoint-of-failure since an aggregator aggregates the encrypted data and sends the result to the UC.The authors in [8] use recharging batteries to protect the customers' privacy in price-based and DLC-based DSM.Customers randomly charge and discharge their batteries so that the electricity drawn from the grid is not their actual consumption.Such a strategy is efficient; however, rechargeable batteries with sufficient capacities are expensive and trigger environmental concerns.On the other hand, since the data is available to all the customers in the user privacy approaches, the involved techniques must support customer anonymity and data unlinkability to achieve privacy preservation.The anonymity offered by the blockchain encouraged researchers to use this technology to develop privacy-preserving DSM strategies.For instance, the authors in [9] and [10] and in [11] and [12] used blockchain to develop price-based and DLCbased DSM strategies, respectively.However, blockchain technology, which associates public/private keys pair for each user, cannot achieve data unlinkability.

B. BLOCKCHAIN MOTIVATION
DSM strategies require privacy-preserving two-way communication between customers and the UC.Dedicated messages between two entities (a customer and the UC) require: (i) each entity to know the identity of the other for point-to-point communication or (ii) a trusted third party to forward the messages from one entity to the other.The first requirement does not support a privacy-preserving DSM, and the trusted third party in the latter method presents a single-point-offailure.A blockchain-based DSM strategy can address these issues.First, each customer sends its energy consumption data anonymously using its public key to the UC.The UC processes the messages received from all customers and prepares the responses.Second, since the UC does not know the customers' identities to send the response to each customer, it broadcasts all the responses using a distributed ledger technology (DLT) that includes the UC and all the customers.Blockchain adds more features to the DSM application than other DLTs.The immutability offered by blockchain increases the trust between the customers and the UC because each customer has a copy of the immutable ledger that includes the electricity consumption data and the UC price/control signals to all the customers.Moreover, blockchain can deploy different DSM programs as smart contracts to run the system autonomously.
Blockchain networks can be a public, consortium, or private.In the public blockchain, anyone can have access to the network by either sending messages (which are called transactions in the blockchain) or participating in the consensus process (verification process of different transactions).For many reasons, using a public blockchain is not practical in the DSM application.First, the UC owns the electricity infrastructure and has a board of investors; hence, any UC will not agree to share the role of taking decisions with public members.Second, the DSM application requires that all customers send their electricity consumption data and receive the response from the UC within a maximum DSM period of τ (e.g., τ = 15 minutes [13]).This τ requirement cannot be satisfied in a public blockchain as the heavy computation needed for consensus protocols in public blockchains (e.g., proof-ofwork [14]) take a long time.On the other hand, in consortium and private blockchains, specific users can join the network.Moreover, the consensus process is done by a predetermined number of nodes.Hence, lightweight consensus protocols are adopted [15], which alleviate the computational time concern to satisfy the requirement of τ .The difference between private and consortium blockchains is that only one entity has the privilege of verifying transactions and adding blocks in private networks, while a group of entities can have this privilege in consortium blockhains.This work considers a single UC; hence, a private blockchain is adopted.

C. CHALLENGES AND CONTRIBUTIONS
Attacks on the existing blockchain architectures can be classified into three categories according to the layer under attack.There are application, consensus, and network layers attacks [16].These attacks differ according to the type of the blockchain (i.e., private or public).Private blockchains do not suffer from consensus layer attacks because dedicated miners control the validation process.On the other hand, application and network layer attacks have a higher impact on private blockchains due to the limited number of participating entities.For example, linking data to the same public key and traffic analysis to link the data to its customer are privacy threats on application and network layers, respectively.In a private blockchain, an attacker with acceptable capabilities can perform both attacks, since the number of customers is limited.Existing blockchain-based DSM strategies have not presented an effective framework that tackles the aforementioned concerns.Hence, a novel blockchain architecture is required to address such challenges while maintaining high throughput and low storage requirements.
In this paper, we carried out the following contributions to propose a secure DSM networking strategy: • We propose a blockchain-based anonymous network called BAN based on group signatures instead of public/private key pairs.The BAN relies on distributed random numbers to work as identifiers.Using group signatures and random identifiers helps in achieving customer anonymity and data unlinkability.Hence, the BAN is secure against privacy threats on the application layer.
• We investigate the vulnerabilities of the BAN network by testing it against different attacks and found that the BAN is secure against external attackers.However, we found that internal attackers can successfully launch either a denial-of-service (DoS), a distributed DoS (DDoS), or a man-in-the-middle (MitM) attack.Moreover, we showed that BAN is not secure against a network layer attack that tracks the customer's IP address using traffic analysis.
• We propose a novel onion routing with blockchain interconnected servers technique called ORBITS and integrate it with some phases of the BAN network to secure it against vulnerabilities in application and network layers.Unlike the ToR network, the ORBITS allows specific entities to send a dedicated number of transactions each period while protecting their identities.We refer to the complete framework with the secure-BAN (S-BAN).
• We implemented both the BAN and the S-BAN networks using Python.Experimental results demonstrate the security and privacy preservation of the S-BAN strategy with acceptable computation and communication overheads.The rest of this paper is organized as follows.Section II describes the system model and functionality along with the security objectives.Section III describes the BAN network and evaluates its performance.The vulnerabilities of the BAN network are discussed in Section IV.Section V describes the operation of the S-BAN network and its performance evaluation.The conclusion is given in Section VI.

II. SYSTEM MODEL AND DESIGN OBJECTIVES
This section presents the system model under consideration, the required functionalities, and the security objectives.

A. SYSTEM MODEL
The system, shown in Fig. 1, includes a certificate authority (CA), the UC, customers, and a bank with the following roles.• Certificate Authority (CA): It generates all the cryptographic material needed by all the entities in the proposed strategy.It does not participate in the blockchain network.
• Bank: It completes customers' electricity bill payment process without participating in the blockchain network.
• Utility Company (UC): It validates the transactions and generates a block that includes the demand responses.
• Customer: It has a smart meter that collects and sends the consumption data (every τ minutes) according to the predefined plan between the customer and the UC.The time is divided into slots of equal duration τ (DSM period).At the beginning of τ , customers send their consumption data to the UC in a time duration of τ 1 .Moreover, within time duration τ 2 , the UC processes the data, prepares responses, and broadcasts these responses to the customers who process these responses (τ = τ 1 + τ 2 ).Customers should receive their response signals before the beginning of the next DSM period.

B. THREAT MODEL
The proposed strategy aims to mitigate the following threats: 1) EXTERNAL ATTACKERS 1) Eavesdroppers trying to know the consumption of particular customers.2) Attackers who aim to manipulate the data, delay the DSM responses, or threaten the network availability.

2) INTERNAL ATTACKERS
1) The UC collects the customers' electricity consumption values and honestly processes the data.However, it is curious to extract private information about some customers.2) Malicious customers target the network with attacks aiming to delay the DSM responses, threaten the network availability, or know the consumption of other customers.
146138 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

C. FUNCTIONALITY AND SECURITY OBJECTIVES
The aim is to achieve the following functionalities: (F1) The customers should be able to send their electricity consumption to the UC in a privacy-preserving manner every DSM period τ .(F2) The UC should have the flexibility of applying either DLC or price-based DSM on the customers.(F3) The UC should be able to collect the billing information of all customers.(F4) The UC should be able to audit the reported electricity consumption of a chosen group of customers without revealing their identity.(F5) The customer should be able to pay the bill without revealing its identity.Moreover, the proposed strategy aims to achieve the following security objectives:

III. BLOCKCHAIN-BASED ANONYMOUS NETWORKING STRATEGY (BAN)
We first present the BAN strategy that targets functionalities F1 -F5 and security objectives S1 -S4.Then, we investigate its performance in terms of the computation and communication overheads at each node.Section IV explores the BAN's vulnerabilities to address security objectives S5 -S7.

A. BAN NETWORKING STRATEGY
The BAN consists of five phases entitled initialization, consumption reports, demand response, billing and auditing, and payment.A detailed discussion of the phases is as follows.

1) INITIALIZATION PHASE
This phase takes place during network setup where all the cryptographic materials used throughout the rest of the phases are generated.In this phase, the UC creates a public/private key pair (PK/SK) and sends PK to the CA that generates a certificate cert to bind PK to the UC.Then, the UC sends to the CA the number of expected customers N to generate their keys according to the group signature scheme introduced in [17].The CA runs the KeyGen(N ) function described in [17] to calculate (a) the group key (κ), (b) N private keys (ϒ n ∀n ∈ {1, . . ., N }), and (c) a manager private key χ .The CA sends κ to the UC, while each customer n has to contact the CA to get κ and its private key (ϒ n ).The CA stores the manager key χ in a secure database.The communications between the CA and any entity (UC or any customer) are done over secure channels.

2) CONSUMPTION REPORTS PHASE
Each customer n periodically (with period τ ) sends a message to the UC, including its consumption at time t, C nt , according to the predefined plan between customer n and the UC, a unique random number R nt , a timestamp t n , and the signature σ nt .The consumption C nt is a single value of the aggregate consumption if the customer is on a price-based DSM.However, if the customer is on a DLC plan, C nt is a vector including the aggregate consumption of (a) all adjustable appliances in the house (e.g., air conditioners), (b) all time-shiftable appliances (e.g., washing machine, electric vehicles, etc.), and (c) all other appliances (e.g., computers, lights, etc.).R nt is generated so that different customers cannot generate the same number at the same timestamp.Moreover, the numbers generated by the same customer at different timestamps cannot be linked together.
For R nt to be unique for different customers, we included the private key ϒ in its generation.Moreover, we included a hash value and a counter to ensure that the generated numbers could not be linked over time.Hence, R nt is calculated as where K nt is a pseudo-random number and Q nt is a counter value.Using only a pseudo-random number as R nt can lead to linking the generated numbers since random numbers generated by pseudo-random number generation algorithms could be linked together using machine learning models [18].Accordingly, the consumption message is given by After receiving the messages from the customers, the UC validates each message by verifying the signature.If the signature is from a legitimate member of the group, the UC accepts the message, otherwise, the message is rejected.Hence, the functionality (F1) is successfully performed.

3) DEMAND RESPONSE PHASE
In this phase, the UC generates a response corresponding to each consumption message received in the previous phase.The generated transaction consists of a response S nt , to the consumption in nt , the same random number R nt sent in nt , a timestamp t r , and the UC's signature σ r .S nt is a price in the case of price-based DSM or a control signal in the case of DLC-based DSM.Hence, the response transaction nt is given by ( A response block is generated with N response transactions.The block includes an index I , hash of the previous block H I −1 , and a set of N transactions nt , n = {1, . . ., N }, i.e., By the end of this phase, the functionality (F2) is performed.

4) BILLING AND AUDITING PHASE
By the end of month m, each customer n calculates its bill by adding its aggregate consumption at the same time instant each day till the end of the month.Afterward, each customer uses the announced electricity price by the UC to calculate its bill.This gives a billing message that includes the bill amount B nm , a new random number Rnm , a timestamp t nm , and the customer's signature σ nm .The billing message nm is given by Hence, the functionality (F3) is performed.Afterward, the UC validates the billing messages by verifying the signatures.The UC can audit any billing transaction since the customers provided the aggregate consumption.To audit, the UC generates a query using the same Rnm used for billing, a timestamp t a , and a signature σa , i.e., na = Rnm || t a || σa . ( The UC collects all the auditing transactions into a block of ( N ) transactions.The block consists of an index, hash of the previous block, and the set of N audit queries, i.e., Upon receiving the audit block, each customer checks the random numbers and compares them with the one it previously sent in the billing message of Eq. ( 4).If a customer finds its random number in the audit block, it prepares an audit-response message and sends it to the UC.The message includes the set of random numbers R n = {R nt ∀t ∈ m} along with its corresponding timestamps T n = {t n ∀t ∈ m}, a timestamp t na , and the customer's signature, i.e.
The UC validates the messages by verifying the signatures.If valid, the UC calculates the bill for the aggregate consumption sent in Eq. ( 7) and compares it with the reported bill in Eq. ( 4).If the UC finds any customer cheating on the electricity bill, it reports the audit-response message of this customer to the CA to reveal the customer's identity.Hence, the functionality (F4) is achieved.
The UC prepares the billing transactions for the honest N customers.These transactions include the same data as the billing messages sent by the customers, but with a new billing timestamp t b and with the UC's signature, i.e.
The UC generates a billing block for all the honest customers ( N | N ≤ N ).The block includes an index, the hash of the previous block, and a set of N billing transactions, i.e.,

5) PAYMENT PHASE
Finally, the UC sends the billing transactions to the bank.Each customer pays the bill amount to the bank after mentioning the corresponding random number Rnm .The bank reports the random numbers corresponding to the unpaid bills to the UC.The UC with the help of the CA can reveal the identity of the customers that did not pay the bill after a specific period of time.Hence, the functionality (F5) is achieved.

B. PERFORMANCE EVALUATION METHOD
Existing blockchain platforms (e.g., Ethereum, Hyperledger Fabric, . .., etc.) do not allow for modifications in the blockchain design to introduce the group signature on top of the blockchain network.Hence, the BAN is implemented from scratch on Python using a 1.8 GHz processor device with a 7 GB RAM.The Charm-Crypto library [19] is used to develop the cryptographic materials.
The commonly used metrics to evaluate the performance of a blockchain network are throughput, latency, and ledger size [20].The throughput is the number of published blocks within a given time.For the BAN, the block generation time can give a good indication of the throughput.The latency is the time between sending the transaction and receiving the corresponding response signal.For the BAN, latency represents the time between the customer's submission of the consumption report and receiving the UC response signal.Since blockchain is a peer-to-peer network, an endto-end delay model can describe the expected delay.The latency associated with the consumption and response reports matters the most since the total delay should not exceed τ (the DSM period) so that the DSM program functions properly.However, the billing and auditing delays are not time-sensitive.

1) END-TO-END DELAY MODEL a: UC NODE
It receives fine-grained messages from the customers and broadcasts a block to all the customers including the DSM response on each message.The UC experiences the following delays: a propagation delay T RX g,n−UC while receiving the consumption-report messages, a processing delay T RX p,UC while processing these messages, and a transmission delay T TX T,UC while broadcasting the response block.The propagation delay T RX g,n−UC is the time taken by the message to travel from the customer to the UC through the transmission medium.It is calculated as a ratio of the distance between customer n and the UC, D n−UC , to the propagation speed of the message in the given medium, v.
Moreover, we assume the UC receives the messages from all customers within τ 1 according to a Poisson process with a fixed service time.The service here refers to the time taken to (a) verify a group signature, T GV , and (b) insert an RSA signature using the UC's private key for DSM response transactions, T S .Hence, we modeled the processing delay of the UC node as an M/D/1 queue.The average waiting time of a message at the UC node, T W is divided into the time the message will wait for other messages to be processed T W,O and the processing time T p of the message [?]db@prasad2015comparison. Hence, the average waiting time of a message in an M/D/1 queue model with a message arrival rate of λ and a service rate of µ is where ρ is the system utilitzation and service rate µ is the reciprocal of the service time.
The transmission delay T TX T,UC is the time taken to broadcast the block to all the customers.Broadcasting the block to a single customer can be calculated as the ratio between the size of the generated block M ˜ I (Eq.( 3)) to the data rate of the communication channel r in bits per second (bps).Hence, the total delay at the UC node to receive and process N messages and broadcast the response block is calculated as The customer sends a message with the fine-grained data to the UC (in the consumption reports phase) and receives the response block (in the demand response phase).When transmitting a message, customer n is subjected to only a processing delay T TX p,n and a transmission delay T T,n .The processing delay is the time taken to generate the random number R nt , T R nt , and the time taken to sign the message using the group signature scheme, T GS .The transmission delay is calculated as the ratio of the size of the generated consumption message (Eq.( 1)), M nt in bits, to the data rate of the communication channel r in bps.Hence, the transmission delay of each customer is calculated as follows When receiving the message, customer n is subjected to a processing delay T RX p,n and a propagation delay T g,UC−n .T RX p,n is calculated as the time taken to search for the corresponding random number R nt in the list of transactions in the response block, T RS , and the time taken to verify the UC signature on the transaction, T V .The propagation delay T g,UC−n is the ratio of the distance between the UC and customer n, D n−UC in meters, to the propagation speed v in bps.Hence, the receiving delay of customer n is calculated as follows To summarize, first, the customer introduces T TX n to transmit its consumption message, this is the time duration τ 1 within the DSM period τ .Then, the utility introduces T UC to receive and process the messages from all the customers, and create and broadcast the response block.Finally, the customer experiences T RX n to receive the response signal.The summation of T UC and T RX n is the time duration τ 2 within τ .

C. EXPERIMENTAL RESULTS
The performance of the BAN strategy is evaluated by measuring the computation and communication overheads at the UC and the customers at different phases.

1) COMPUTATION OVERHEADS a: CUSTOMER COMPUTATION OVERHEADS
The computation overheads per customer are given in Eq. ( 12) (while transmitting a message, which is equivalent to τ 1 ) and Eq. ( 13) (while receiving a response block, which is added to the UC delay to calculate τ 2 ).The implementation overheads of these cryptographic operations are summarized in Table 1.A communication link with data rate r is 100 Mbps is assumed, which is the average Internet speed at all the states in USA [22], the distance between the UC and any customer D n−UC is assumed 1000 km, the propagation speed is 3 × 10 8 ms, and the message size is calculated using the information in Table 2.Moreover, to search for R nt in a block of transactions, we used the jump search algorithm [23] with time complexity of O( √ N ).An example of the corresponding delay (T RS ) is given in Table 1 for a response block that includes 500 transactions.The summation of the delays of Eq. ( 12) is around 35 ms (i.e., τ 1 = 35 ms).Moreover, the summation of the delays in Eq. ( 13) is around 15 ms, which will be added to the UC delays that are calculated next to determine τ 2 .

b: UC COMPUTATION OVERHEADS
The computation overheads at the UC are given by Eq. (11).The processing time T RX p,UC is calculated for different number of customers N , where µ is calculated as mentioned in Eq. ( 10) and λ varies with the number of customers N .We adopted the same data rate values r and the distance between the UC and any customer D n−UC as mentioned before.Fig. 3 shows the computation overheads of the UC while varying the number of customers N in the BAN.The overheads increases linearly with N giving promising results such that a total of 500 customers are served in 27 seconds.Hence, the UC delay is the dominant value in calculating τ 2 (another value is 15 ms).Moreover, τ 2 is dominant in calculating τ , since τ 1 is 35 ms.Hence, a total of 500 customers can have a DSM period τ = 15 minutes since the end-to-end delay is 27sec < τ = 15 minutes.

2) COMMUNICATION OVERHEADS a: CUSTOMER COMMUNICATION OVERHEADS
The sizes of the data sent by each customer are shown in Table 2.The size of the consumption report message (Eq.( 1)) is the summation of its components' sizes 2 + 24 + 13 + 408 = 447 bytes.
146142 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

b: UC COMMUNICATION OVERHEADS
These are calculated by measuring the block size while varying the number of customers in the system, as shown in Fig. 4. The figure shows a storage requirement of 0.5 MB for a single block of 500 customers.Hence, the storage requirement for a single customer or the UC to save the ledger for a month equals 30 × 0.5( 24×60 τ ) MB, such that τ is in minutes.For example, with τ = 15 minutes, the size of the ledger will be 1.44 GB.The customer can have the ledger data of the latest 2 months and delete all the old data before that to save extra space.

D. BAN SECURITY ANALYSIS
BAN uses the group signature and random number identifiers to ensure the privacy of the customers.In detail, no entity included in the BAN can identify the identity of a customer using the group signature, hence, the security requirement (S1) is satisfied.Besides, no entity in the BAN can link two messages to the same customer, hence, the security requirement (S2) is successfully satisfied.Moreover, the immutability and transparency of the blockchain ensures that no entity can change the previously published data on the BAN ledger without being detected and both the consumption and corresponding bills of all the customers are available to all the entities on the BAN.Hence, security objectives (S3) and (S4) are satisfied using the blockchain technology in BAN.

IV. SECURITY EVALUATION OF THE BAN AGAINST INTERNAL ATTACKERS
The BAN strategy is protected against external attackers in the application layer, and here we focus on internal attackers.A complete privacy-preserving system encourages attackers to perform malicious behaviors the system without being traced.Accordingly, upgrading the BAN is a must to alleviate several malicious acts that can be launched due to the privacy-preservation nature of the network.The presence of malicious registered customers in the system can introduce additional delays or affect the availability of the DSM functionality using DoS or DDoS attacks.Moreover, malicious registered customers can succeed in performing a MitM attack and impersonate other honest customers for their benefit.In addition, the UC, any customer, or even any eavesdropper monitoring the network can track the IP address of a specific customer sending a report message, which threatens the customer's privacy.To evaluate the performance of the BAN against different attacks, we performed a case study based on the Dyersburg Electric System that serves 12, 000 customers [24].This represents the average number of customers for many UCs in Tennessee, USA.Moreover, according to the SmartGrid/AEIC AMI Interoperability Standard [25], each smart meter sends the fine-grained data in a period of 5, 15, 30, or 60 minutes.The 15 minutes is the most commonly used DSM period [13].Hence, we set the DSM period τ to 15 minutes.

A. DOS ATTACK
The customers' anonymity and the data unlinkability can encourage malicious registered customers to perform a DoS attack on the BAN.The DoS attack here could occur when a customer sends many transactions to the UC so that the processing time of these transactions requires more time than the DSM period τ .Accordingly, customers will not receive the control signal before the start of the next DSM period, hence, the DSM program will fail.An example of this DoS attack is shown in Fig. 5 at τ = 15 minutes.The time taken from sending customer report messages to receiving the demand response block is calculated for different customers N .The calculation is based on adding Eq.( 12) to calculate τ 1 and Eq. ( 11) and Eq. ( 13) to calculate τ 2 .The BAN can handle up to 13, 000 messages within τ = 15 minutes.For any number of messages greater than 13, 000, the processing time will exceed the threshold of 15 minutes, causing a DoS.Hence, the BAN capacity (maximum number of served customers) at τ = 15 is 13, 000.If a customer sends multiple messages, causing the number of messages to exceed 13, 000, the processing time will exceed 15 minutes, and the DSM program will fail.In the same way, Table 3 shows the BAN capacity without causing DoS at different DSM periods τ .

B. DDOS ATTACK
A malicious registered customer can recruit other devices to act as zombies.These devices can use the private key of this malicious customer, the group key, and all the information sent by the CA in the initialization phase to sign messages as a legitimate user in group.If the total number of messages sent by all the customers and the zombies exceed the threshold value shown in Table 3 for the given DSM period τ , a successful DDoS attack is performed.

C. MITM ATTACK
A maliciously registered customer can intercept the communication between another customer and the UC and manipulates the data.For example, as shown in Fig. 6, malicious customer 3 intercepts the consumption report message sent by customer 2 and manipulates the consumption by adding C to the total value.Moreover, customer 3 decreases its consumption by the same value and signs the new data using the anonymous group signature, and sends it to the UC.The UC cannot detect this malicious act as it accepts the message since it is signed by a malicious member of the group using a valid group signature.Customer 3 can repeat this all over the month and send two billing messages to the UC (again while intercepting the messages sent by customer 2).As a result, the UC will charge customer 2 with a larger bill, while the bill of customer 3 is much less than its actual consumption.

D. IP TRACEABILITY
Privacy preservation is much more challenging in permissioned (private or consortium) blockchain networks than permissionless (public) ones.This is because in permissioned blockchain networks, all the users have to register to get access to the network, hence, the anonymity of a user is limited by the number of users registered in the network.Moreover, any entity with reasonable capabilities can eavesdrop on all the entities and track the traffic flow within the whole network.IP traceability and network analysis deanonymization have been discussed in the literature.For example, Alex and Sergei in [26] and [27] successfully deanonymized their own transactions in Bitcoin and Zcash.
Their technique focused on clustering the networks and trace the traffic flow within different clusters.Clustering here was essential as [26] and [27] focused on public blockchain networks, while in the case of private and consortium networks, the attack is easier to be implemented.

V. S-BAN: SECURE-BAN STRATEGY
The IP traceability problem due to analyzing network traffic is critical in BAN since it is based on a private blockchain.This is because (a) there is a limited number of customers in the network and (b) all the customers are within a close geographical area (e.g., neighborhood/city), which decreases the effort done by any attacker to analyze the whole network.Moreover, securing the BAN against insider DoS and DDoS attacks requires the ability to ensure that each customer sends only a single message when needed without any attempt to push the processing time to exceed τ by sending several messages at the same time.Moreover, to avoid the insider MitM attack, each customer must be authenticated.All the aforementioned issues are challenging under the condition of keeping the privacy of the customers preserved.
Different ways are proposed in the literature to protect a network from IP traceability.For instance, the authors in [28] used a proxy server to anonymize the static IP addresses of customers.However, this proxy server presents a single-point-of-failure.Hence, in the instance the server is compromised, the identities of the customers are revealed.
Motivated by the identity protection procedures adopted by the Bitcoin project [29], the onion routing (Tor) network [30] can be employed to address the IP traceability problem.This is needed to handle the communications from the registered customers to the UC (e.g., to deliver the customer messages).However, the communication from the UC to the customers (i.e., in broadcasting the blocks) does not suffer from privacy threats because the identity of the UC is already known to all the entities.While the Tor network can protect customers from IP traceability, it will not protect the BAN from DoS, DDoS, or MitM attacks.Hence, we are motivated to upgrade the BAN to attain a secure-BAN (S-BAN).

A. S-BAN ARCHITECTURE
The S-BAN uses a novel onion routing with blockchain interconnected servers technique called (ORBITS).It is used during the period τ 1 (the time taken by a customer to send a customer report message to the UC) to ensure the protection of the customers' IP addresses from traceability and to detect any attempt of an insider DoS, DDoS, or MitM attacks.
The idea of ORBITS is based on onion routing with end-toend encryption.This means that the network is built on a set of servers S = {S 1 , S 2 , . . ., S K }.Each customer in each DSM period τ randomly chooses a number of L servers from the set S to construct a path to send its customer report message to the UC.In the same path, each server in each time slot 146144 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
must authenticate itself to the server in the next time slot.Any entity (e.g., CA, private companies, or a customer) can apply to be a server that serves in the ORBITS.Customers can have discounts on their electricity bills for acting as servers.Other entities can have financial gains by being servers in ORBITS.Since the servers are not trusted (as any entity can act as a server in ORBITS), all the servers in S are connected to a private blockchain network with a UC node.The UC node monitors the behavior of the servers to ensure that they do not perform any malicious act (i.e., participate in any of the attacks described in Section IV).Hence, ORBITS is based on end-to-end encryption routing, server authentication, and a blockchain to monitor the servers' behavior.

1) END-TO-END ENCRYPTION ROUTING
The time period τ 1 is divided into a predetermined number of L time slots.At each consumption report period τ 1 within the DSM period τ , customer n randomly chooses a path of L different servers (P n = {S 1 i , . . ., S L j }, i, j = 1, 2, . . ., K , i ̸ = j) such that S 1 i and S L j are servers i and j chosen at time slots 1 and L, respectively.Then, the customer should prepare a layer of encryption for each server in the path and another layer of encryption for the UC.This gives a total of L + 1 layers of encryptions.Each encryption layer is performed using the AES encryption.The symmetric key of this encryption is exchanged using the RSA-based key encapsulation mechanism (RSA-KEM) [31].RSA-KEM uses RSA encryption between the sender (i.e., the customer) and the receiver (i.e., a server or the UC) to exchange the key.The sender generates a fresh AES key k and encrypts it with the public key of the receiver using RSA encryption, resulting in the cipher c k .Then, the sends c k to the receiver, which decrypts it with its private key to get k.Algorithm 1 summarizes the steps taken by customer n to generate a single layer of encryption for the server in time slot l, ∀ l ∈ {1, . . ., L} and the UC, where M n,t,X l is the dedicated message of customer n to the entity (server or the UC) X l and IP X l+1 is the IP of the entity (server or the UC) in the next time slot l + 1. Customer n repeats the algorithm L + 1 times to generate the final message.
First, customer n generates the message for the UC.Hence, the inputs to Algorithm 1 are: (i) the message to the UC, M n,t,X l = M n,t,UC = nt and (ii) a null value for the IP of the next server as the UC is the destination i.e., IP X l+1 = Null.Then, customer n generates a fresh AES encrytion key k n,t,UC with the UC using the RES-KEM mechanism as described in line 2 and encrypts the key with the public key of the UC as described in line 3. Afterwards, it encrypts the message M n,t,X l with k n,t,UC as described in line 4. Finally, it adds a timestamp and signs the whole data (dedicated message after encryption, the encryption of the fresh key, and the timestamp) as described in line 5.The whole data along with the signature is used as the dedicated message for the server before the UC in the path (i.e., the server in time slot L).The same procedure is repeated L times for the L servers in the time slots.

Algorithm 1 ORBITS Message Generation Process by Customer n at Each Consumption Report Interval τ 1
Input: M n,t,X l , IP X (l+1) Output: M n,t,X l+1 1 Preparing the Message: M n,t,X l || IP X (l+1) 2 Generate a fresh AES key: k n,t,X l 3 RSA Encryption: R n,t,X l = Enc PK X l (k n,t,X l ) 4 AES Encryption: A n,t,X l ← Enc k n,t,X (M n,t,X || IP X (l+1) ) 5 Group Sign: σ n,t,X l = Sign(A n,t,X l || R n,t,X l || tn ) 6 Server Message after Encryption: 2) SERVER AUTHENTICATION Before data transmission, each server must authenticate itself to the next server.For example, before server i at time slot L − 1, S L−1 i , sends the message M n,S L ,t to server j at time slot L, S L j , it must authenticate itself first.Hence, S L−1 i encrypts the message with its private key.Therefore, a malicious customer cannot send messages to the servers at different time slots to achieve a DoS attack.

3) ORBITS BLOCKCHAIN
After generating the total encrypted message (after L + 1 encryptions), customer n sends the message to the first server in the path S 1 j .The first server checks that the IP address IP n of customer n is in the set of IP addresses registered with the UC.This is done using a bloom filter [32] designed by the UC and distributed to all the servers.Bloom filter here is the best choice as it is the most efficient way to search in a previously known list.If IP n is valid, the server S 1 j accepts the message from customer n and adds IP n to the set of IP addresses IP j that sent messages during the first time slot.Afterward, the first server generates a transaction including the set of IP addresses IP j it received the consumption messages from.This transaction is given by where j represents a server receiving messages in time slot 1.Despite the first server knowing the IP addresses of the customers that chose it as an entry server, this does not present a privacy threat to these customers.This is because the server does not know the complete path, hence, it cannot link a message that arrives at the UC to its original customer.Also, the server does not know the content of the message because it is encrypted in L+1 layers.The UC node first verifies the signatures on different transactions received from all the servers.If valid, it checks that all the received IP addresses are different and belong to registered customers in the UC using the bloom filter that is distributed to the servers.If a server sends an IP in its list that does not belong to a registered customer, this means that this server is malicious.If more than one server sends the same IP address, the UC node sends separate requests to these servers to forward the messages received from this same IP address.Afterward, the UC node checks the signature on the messages.If it is a valid signature of a registered customer (group signature verification), it sends messages to the CA to reveal the identity of the customer for a malicious act.If any of the messages do not include a valid signature of a registered customer, the UC node excludes the server that sends the fake signature from the list of ORBITS servers.Finally, the UC node generates a block including all the transactions received from all the servers.The generated block is given by where I OR is the block index (i.e., starts by zero for the genesis block) and H I OR−1 is the hash of the previous block (i.e., it is empty in the genesis block).
At each time slot l (1 < l ≤ L), each server S l j sends a transaction including the number of messages ζ j it during this time slot.The generated transaction is given by Upon receiving the transactions from the servers, the UC node verifies the signatures on the transactions and checks that the total number of transactions received by all the servers equals the number of customers in the system.If valid, the UC node generates a new block with all the received transactions, otherwise, it sends separate messages to all the servers to send all the messages received by other servers in this time slot.The UC node checks the messages until it finds the malicious server.Similarly, the UC node generates a block including all the transactions received from all the servers as follows In all time slots, the UC node can detect any malicious act from any entity in the system.Since all the messages are authenticated to both the customers and the servers, any malicious act could be traced back to the attacking entity.An attacking server is easily detected by the UC and excluded from the whole network.Moreover, the identity of any malicious customer is revealed with the help of the CA and can be excluded from the network as well.
A small-scale description of the system model of ORBITS is shown in Fig. 7.This description consists of 8 customers and 4 servers.The number of time slots L is 2 time slots.Hence, each customer chooses a path of 2 servers every DSM period τ .Moreover, in each time slot, the servers send the data needed to the UC node for monitoring (IP addresses from which they receive the messages in the first time slot and the number of messages they received in the second time slot).
It is important to highlight that the steps of the ORBITS strategy take place during the consumption report phase of the BAN.Hence, the data that will be encrypted L + 1 times is the consumption report message, nt , in Eq. (1).All the other BAN phases will follow as explained in Section III.Moreover, any entity can be a server in the ORBITS; hence, the ORBITS blockchain is essential to overcome any malicious act.Furthermore, the block shared on the ORBITS blockchain in the first time slot must include the IP addresses received by each server.As a result, any malicious act by a customer to perform a DoS or DDoS attack is detected.Finally, the other blocks in the ORBITS must include only the number of messages each server receives.This detects any malicious act by any server (e.g., a malicious server sends fake messages to other servers).Hence, the blocks shared on the ORBITS blockchain detect the malicious act on the spot and can exclude the malicious entity without affecting the DSM program.

B. ORBITS SECURITY REQUIREMENTS
There are some security requirements that must be satisfied in the ORBITS network to protect it from some threats.These security requirements are: (1) the minimum number of time slots L and (2) the service queue structure.

1) THE MINIMUM NUMBER OF TIME SLOTS
The minimum number of servers used in a single path in Tor network is 3 [30].This is because the first server knows the sender and the third server knows the destination.Hence, a server is added in between that does not know the sender or the destination.This is for a system that needs to achieve both sender and receiver anonymity.In the DSM application, only the sender (customer) anonymity is required while the receiver is always the UC.Hence, a minimum of 2 servers should be used in a single path.Accordingly, each customer chooses a minimum of 2 servers as its path from the set of S servers registered in the list of ORBITS servers.The number of servers in the path is equivalent to the number of time slots.Hence, a minimum of 2 time slots is needed to ensure the anonymity of the customer.

2) THE SERVICE QUEUE STRUCTURE
Any entity eavesdropping the network can decrease the anonymity of the customers by analysing the network traffic.To overcome this limitation, the servers randomly process the messages by adopting the random order service queue structure (ROS) [33].This means that the servers processes the received messages in random order, which eliminates the traceability due to traffic analysis.

C. IMPLEMENTATION DETAILS
We implemented the S-BAN to secure the system against IP traceability, MitM, DoS, and DDos attacks.The implementation is done using the same device and Python library described in Section III-B.During the implementation, we deployed up to 10 servers within 2 time slots (i.e., 2 servers are employed per path).The computation and communication complexity added by the S-BAN are discussed next.
146146 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
3 ).In time slot 1, the IP addresses that will send messages to the servers, according to the chosen paths, are written under each server (e.g., server 1 receives messages from customers 1 and 2).The number of messages that each server receives in the time slot 2 is written under each server (e.g., server 1 will receive 2 messages, since it is the second server in 2 paths).

1) S-BAN COMPUTATION COMPLEXITY
This is measured at both the customer side and each server or the UC side.

a: CUSTOMER COMPUTATION OVERHEADS
The message generation described in Section V-A1 shows that for the UC and each server, the customer has to perform AES encryption, RSA encryption, and sign with its key using group signature.Hence, the customer computation complexity for message generation is summarized in Table 4.Note that all these operations are repeated for each server in the path and for the UC.Hence, the total computation time is the sum of the time taken to perform the operations in Table 4 times 3, which gives 132 ms delay.

b: EACH SERVER AND THE UC COMPUTATION OVERHEADS
Each server and the UC have to reverse the customer's operations.Hence, each server and the UC has to perform group signature verification, AES decryption, and RSA decryption.In addition, each server has to authenticate the server in the previous time slot and authenticate itself to the server in the next slot.Accordingly, the server encrypts the message with its private key, and the receiver can decrypt the message with the sender's public key.The decryption operation authenticates the previous server, while the encryption operation authenticates the server to the server in the next time slot.The RSA encryption is used instead of the RSA signature due to the low time complexity of the RSA encryption.Moreover, each server uses a bloom filter to ensure that the IP they received the message from is included in the set of customers' IP addresses (IP).Having total number of N IP addresses and assuming a false positive probability of 10 −5 , we used the equations in [32] to calculate that a bloom filter of 287, 552 bits is needed with 17 hash function operations to check the existence of an IP in a list N = 12, 000 IP addresses.
We calculated the total computation overhead of the S-BAN network by changing the number of time slots from 2 to 10.In addition, we varied the number of servers used in each time slot (by varying the total number of servers in ORBITS K ) from 2 to 10.The total time taken by a message to be served by all the servers in the ORBITS network in each case is as shown in Fig. 8.The results show that there is an increase in the time duration needed to perform the servers' operations as the number of time slots L increases.However, increasing the total number of servers in the system is important.For example, as shown in Fig. 8, the time taken to complete the operations while having 2 servers in 3 time slots is much higher than the time needed while having 8 servers in 6 time slots.This is because by having more servers K , the number of customers that are served per server decreases.Hence, more servers is better to decrease the delay caused by the ORBITS.

2) BAN COMMUNICATION COMPLEXITY
The communication complexity is evaluated at the customer and each server sides.

D. S-BAN PERFORMANCE EVALUATION
In S-BAN, the time taken by a customer to send the customer report message to the UC τ 1 is the summation of the delay added by customer n while generating the message (i.e., 132 ms for 2 time slots and the UC as calculated before) and the delay added by the servers in the path P n to process the message and send the ORBITS's transactions in each time slot (i.e., 1.84 minutes as shown in Fig. 8 in case of deploying 10 servers in 2 time slots).Hence, τ 1 increased from 35 ms in the BAN to around 1.85 minutes in the S-BAN.On the other hand, τ 2 in S-BAN is the same as τ 2 in the BAN.This increase in τ 1 , caused by the ORBITS network, decreased the total capacity of the S-BAN when compared to the BAN.For a DSM period τ = 15 minutes, the capacity of the S-BAN is 12, 000 customers.This is calculated as follows: (i) the delay caused by the customer to generate 3 layers of encryption, (ii) the delay of processing a total of (12, 000/10) × 3 customer messages for (12, 000/10) customer messages per server in 3 time slots, and (iii) the delay caused by processing and generating the DSM block.Such that the delays (i) and (ii) represents τ 1 , while the delay (iii) represents τ 2 .Despite, the S-BAN loses 7.7% of the BAN capacity (from 13, 000 in BAN to 12, 000 in S-BAN) after adding the ORBITS, the S-BAN is secured against many cyber-attacks.It should be highlighted that in order to keep the same number of customers, we can increase the DSM period τ .

E. SECURITY ANALYSIS
In addition to the security objectives that are satisfied by the BAN (from S1 to S4), the S-BAN strategy with the help of the ORBITS network is secure against different cyber-attacks:

1) DOS AND DDOS
The entry servers in the ORBITS ensure that each customer sends only one message and the UC monitors this via the ORBITS blockchain.Hence, any customer acts maliciously by sending many is detected.Moreover, the UC monitors the number of messages each server receives in each time slot.Hence, any server is detected if acted maliciously, which satisfies the security objective (S5).

2) MITM ATTACK
Messages from the customers are authenticated with the group signature (using the group key and the private key of the customer).Besides, the ORBITS's servers authenticate each other in each time slot.The entry servers in ORBITS ensures that each customer sends only one message to the UC using the IP of the customer, hence, the MitM attack discussed in Section IV due to the group signature anonymity cannot occur, which satisfies the security objective (S6).
146148 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

3) IP TRACEABILITY
The proposed ORBITS network with the random processing order of the servers ensures that no entity can track a message to its customer using traffic analysis.Hence, security objective (S7) is satisfied.

4) REPLAY ATTACKS
Each message either from the customer to a server, between servers, or from a server to the UC includes a timestamp.The timestamp along with the message are authenticated with the private key of the message sender, hence, the proposed system is secure against any replay attack.

VI. CONCLUSION
In this paper, we proposed a privacy-preserving DSM strategy based on blockchain network (BAN).The performance evaluation showed the promising performance of the BAN with a capacity of up to 13, 000 customers in a DSM period of 15 minutes, with a storage requirement of 1.44 GB per customer.The security analysis showed that the BAN is secure against external attackers.However, the BAN had vulnerabilities that can encourage malicious customers to attack the system.We proposed a secure BAN (S-BAN) strategy that can protect the BAN against different attacks.We studied the performance of the and its impact on the performance of the BAN showing that, while sacrificing only 7.7% of the network capacity for the same τ value, the security of the network against external attackers is significantly improved.

FIGURE 1 .
FIGURE 1. Illustration of the system model under consideration.
(S1) Customer's Anonymity: No entity should be able to reveal the identity of any customer sending any message on the network at any time instant.(S2) Data Unlinkability: No entity should be able to connect two transactions to the same customer.(S3) Protection against Message Tampering: No entity should be able to manipulate the ledger data.(S4) Transparency: Any entity (except the CA) should have a copy of all the consumption and billing data.(S5) Protection against DoS and DDoS attacks: The network should be protected against any DoS or DDoS attack threatening network availability.(S6) Protection against MitM attack: Any internal or external attacker should not be able to impersonate any entity in the network.(S7) Protection against IP traceability: No entity can track a customer's message to its sender.
Fig 2 summarizes the phases of the BAN.

FIGURE 2 .
FIGURE 2. Illustration of the five phases of the proposed networking strategy.

FIGURE 3 .TABLE 2 .
FIGURE 3. Illustration of the UC computation delay versus the number of customers.

FIGURE 4 .
FIGURE 4. Illustration of a block size while varying the number of customers.

FIGURE 5 .
FIGURE 5. Illustration of the maximum number of messages the system can handle at a DSM period τ = 15 minutes.

FIGURE 7 .
FIGURE 7. Illustration of the system model of the ORBITS network using 4 servers over L = 2 time slots.The paths chose by the customers are written under each one (e.g., customer 1 chooses server 1 in time slot, S 1 1 , and server 3 in time slot 2, S 2 3 ).In time slot 1, the IP addresses that will send messages to the servers, according to the chosen paths, are written under each server (e.g., server 1 receives messages from customers 1 and 2).The number of messages that each server receives in the time slot 2 is written under each server (e.g., server 1 will receive 2 messages, since it is the second server in 2 paths).

FIGURE 8 .
FIGURE 8. Illustration of the computation overhead of all the servers by varying the numbers of servers and the number of time slots.

FIGURE 9 .
FIGURE 9. Illustration of the communication overhead of the generated message versus the number of time slots.

FIGURE 10 .
FIGURE 10.Illustration of the block sizes in the ORBITS at different time slots.

TABLE 1 .
Computation overheads of customer n in the BAN strategy.

TABLE 3 .
The maximum capacity of the BAN at different DSM period τ .
FIGURE 6. Illustration of launching MitM attack on BAN.

TABLE 4 .
Consumer computation complexity for each encryption layer (each time slot) in message generation.

TABLE 5 .
Server computation complexity at each time slot.