Secure and Privacy-Friendly Local Electricity Trading and Billing in Smart Grid

01/25/2018 ∙ by Aysajan Abidin, et al. ∙ 0

This paper proposes two decentralised, secure and privacy-friendly protocols for local electricity trading and billing, respectively. The trading protocol employs a bidding algorithm based upon secure multiparty computations and allows users to trade their excess electricity among themselves. The bid selection and calculation of the trading price are performed in a decentralised and oblivious manner. The billing protocol is based on a simple privacy-friendly aggregation technique that allows suppliers to compute their customers' monthly bills without learning their fine-grained electricity consumption data. We also implemented and tested the performance of the trading protocol with realistic data. Our results show that it can be performed for 2500 bids in less than five minutes in the on-line phase, showing its feasibility for a typical electricity trading period of 30 minutes.



There are no comments yet.


page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

The Smart Grid (SG) is an electricity grid supporting bidirectional communication between various entities and components in the grid. One of these components is a Smart Meter (SM) that allows real-time grid management [1], thus improving the efficiency and reliability of the grid, and the seamless integration of various green energy sources such as Renewable Energy Sources (RESs) (e.g., solar panels) into the distribution grid. When these RESs generate more electricity than needed by their owners, the excess electricity is fed back to the grid. Currently, households get some compensation from their suppliers for such excess electricity at a regulated, low price. However, households with such excess electricity may be interested in selling directly to other consumers at a competitive price for monetary gains. Enabling that would also incentivise households to own RESs.

To address this, a local electricity market that allows RES owners to trade their excess electricity with other households in their neighbourhood has been proposed in [2]. However, such a local electricity market has user privacy risks, since users’ bids and offers reveal private information about their lifestyle [3]. Although there are various proposals for an electricity trading market that allows users to trade with each other, none of them addresses the privacy concerns. The security and privacy concerns in such a local market have been analysed in [2]. However, no concrete solution has been proposed. In this work, we not only propose a concrete secure and privacy-friendly solution for such a market, but also implement and evaluate its performance using realistic data. This work extends our previous research [4] in improving the bid-matching algorithm and providing a solution for privacy-friendly billing.

Our specific contributions include:

  • a decentralised protocol for local electricity trading that allows the market to identify the selected bids, calculate the clearance price, and compute the total amount of electricity traded by the users belonging to each individual supplier in an oblivious and secure manner;

  • a concrete time-of-use privacy-friendly billing protocol that allows suppliers to calculate their users’ monthly bills without accessing their fine-grained metering data; and

  • an implementation, evaluation and analysis of the proposed protocols using realistic metering data.

The rest of this paper is organised as follows: Section 2 presents the related work. Section 3 elaborates on the preliminaries. In Section 4 and 5, we present our proposed protocols and analyse their security, respectively. Section 6 gives the details on our implementation and simulation results. Finally, Section 7 concludes the paper.

2 Related Work

Preserving users’ privacy in SG has already been recognised as an important issue by the research community [5, 6]. Below we provide a brief overview of state-of-the-art privacy-friendly protocols for electricity trading and billing.

2.1 Privacy-friendly Protocols for Electricity Trading

Various local electricity trading models have already been proposed [7, 8]. Bayram et al. [9] gave an overview of such models, whereas Zhang et al. [10] summarised existing local electricity trading projects. Mengelkamp et al. [11] evaluated several market designs and bidding strategies to demonstrate that all the evaluated market scenarios offer economic advantages for the participating users. Mustafa et al. [2] performed a security analysis of such a local trading market and raised the security and privacy concerns associated with it.

There are already various solutions that partially address these concerns. Mengelkamp et al. [12] designed a local electricity market on a private blockchain. They presented a proof-of-concept model including a simulation of a local blockchain-based energy market that allows users to bilaterally trade energy within their community. Kang et al. [13] proposed a similar trading mechanism among electric vehicles using a consortium blockchain technology combined with an iterative double auction mechanism designed to maximize social welfare. Aitzhan and Svetinovic [14] implemented a decentralised electricity trading system using combination of blockchain technology, multi-signatures, and anonymous encrypted messaging as a proof-of-concept. Their system provides identity privacy of participating users and transaction security. Mihaylov et al. [15] proposed a virtual currency, called NRGcoin, to convert locally produced energy directly to NRGcoins. In their proposed scheme, each local distribution system operator independently determines for each time slot the rates for energy consumption and production in the neighbourhood, based on the supply-demand balance at that current time slot.

Rahman et al. [16] proposed a secure bidding protocol for incentive-based demand response system. However, their protocol is not fully privacy-friendly as the bidding manager, acts like a trusted party and learns all users’ bids. Kounelis et al. [17] introduced a platform named Helios that allows users to exchange energy in a decentralised manner using a blockchain technology and smart contracts. Uludag et al. [18] proposed a distributed bidding system where only the winning bidder is disclosed to a service provider, whereas the bids of the other bidders are kept private. The same authors extended their solution to facilitate multi-winner auction mechanism [19]. Although these solutions provide security and verifiability as they are based on the blockchain technology, they do not fully address users’ privacy concerns as transactions could be traced and linked to users.

One way to avoid this privacy leakage is to use Multiparty Computation (MPC) [20]. Aly and Van Vyve  [21] proposed an MPC-based auction mechanism that allows suppliers and generators to trade electricity on the day-ahead market in a secure and oblivious manner. Abidin et al. [4] proposed an algorithm to match the supply and demand bids of a local electricity market in a privacy-friendly manner. However, they did not provide any solution for billing users.

2.2 Privacy-friendly Protocols for Billing

Petrlic [22] proposed each SM to have a trusted module so that the SM can act as a tamper-resistance device, and calculate its user’s bills. Molina-Markham et al. [23] proposed to use zero-knowledge proofs to allow SMs to calculate their monthly bills without providing suppliers with metering data, while allowing them to verify the bills. Jawurek et al. [24] proposed each SM to have a plug-in component that generates signed commitments of metering data which are used by the supplier to verify the user’s bill. A similar approach was also proposed by Rial and Danezis [25]. However, instead of having a plug-in component, the authors suggest to have a more powerful user device which could deal with more complex electricity tariffs. Danezis et al. [26] improved the protocol in [24]. In their protocol, each SM adds some random noise to its final bill, so that the supplier can not deduct any useful information about the user’s consumption pattern from the bill itself.

Data aggregation is another privacy-preserving technique. The existing work mainly utilises homomorphic cryptographic schemes [27, 28, 29] or MPC [30] to aggregate metering data used for operational purposes. Bilogrevic et al. [31] proposed a privacy-friendly aggregation of user profile data. Their protocol allows users to trade personal attributes obliviously. We employ a similar technique that allows the users to report the amount of electricity they traded at the local electricity market in a privacy-preserving manner, in order to obtain the right amount of compensation from their contracted suppliers.

Unlike the aforementioned work, we propose a decentrilised, efficient and privacy-friendly protocol that allows local electricity trading among users. We extend the work presented in [4] by including (i) a more detailed protocol description, (ii) a formalised security analysis, and (iii) a protocol for efficient and privacy-friendly user billing.

3 Preliminaries

This section briefly describes the system model, the local electricity market, threat model, the assumptions and requirements introduced in [2] on which our protocols are based.

3.1 System Model

A local electricity market includes the following entities (see Fig. 1). Renewable Energy Sources (RESs) are local sources of electricity, e.g., solar panels, located on users’ premises. The electricity generated by RESs is consumed by their owners, but surplus electricity is injected into the grid. Smart Meters (SMs) are advanced metering devices which measure the amount of electricity flowing from the grid to the house and vice versa. Users consume electricity and are billed for this. Suppliers are responsible for supplying electricity to all users who could not get a sufficient amount of electricity from their own RES or on the local market. They are also obliged to buy the electricity which their customers did not trade on the market but still injected into the grid. The trading platform manages the trades. It consists of servers run by parties with competing interests.

We further classify the entities involved in our model as

Dealers, Computational parties (Evaluators) and Output parties. Dealers are any subset of parties in charge of providing the input data and distributing them among the computational parties. In our protocols, the input data is provided directly by the bidders, i.e., users via their SMs. Evaluators are the subset of parties performing the computations in a distributed manner. They operate on the data received from the dealers. Output Parties are any subset of parties that have access to the output data – the results of the computations performed by the evaluators. At the end of the computation stage, the evaluators send the output data to the correct output parties. Note that some output data may be made public to all parties, while others only revealed to a specific subset, e.g., the suppliers.

The selection and the number of evaluators depend solely on the application and it could be as many as the number of parties involved in the computation. This approach, however, would be costly in terms of performance. Thus, in our model we choose to have three computational parties. We assume that one party comes from the RES owners (bidders), one from the suppliers and a third one from a local authority, so the need for a trusted trading platform is eliminated, while the security and correctness of the trading operations are still guaranteed.

Figure 1: A local electricity trading market.

3.2 Local Electricity Market Operation Overview

We briefly describe the local electricity market proposed by Mustafa et al. [2]. It consists of the following steps.

  • Bid submission: Prior to each trading period, users submit their bids to the trading platform. Each bid consists of the amount of electricity the user is willing to sell or buy during the trading period and for what price per unit.

  • Trading price & winners selection: The trading platform performs a double auction to determine the trading price, the amount of electricity traded, and the auction winners.

  • Informing users and suppliers: The platform informs (i) the users about the amount of electricity they traded and the trading price, and (ii) the suppliers about the amount of electricity agreed to be traded by their respective users.

  • Delivering electricity: During the electricity trading period the auction winners export (or import) the amount of electricity they traded on the local market.

  • Calculating rewards and costs: At the end of the trading period, each SM measures its user’s imported and exported electricity for this period, which are used to calculate the users’ rewards or costs.

  • Settling payments: Once the suppliers receive the imported and exported electricity values from their customers’ SMs, they use them in conjunction with the users’ trades for the trading period and the trading price to adjust the customers’ bills in order to reflect the effect of the users participating in the local electricity trading market.

3.3 Threat Model and Assumptions

The trading platform is an honest-but-curious entity. It follows the protocol specifications, but it may attempt to learn individual users’ bids. Users, suppliers and external entities are malicious. Users may try to modify data sent by their (or other users’) SMs in an attempt to gain financial advantage, whereas suppliers may try to learn and modify users’ bids in an attempt to influence the electricity trading price on the market. They may eavesdrop data in transit trying to learn confidential data and/or modify the data in an attempt to disrupt the SG.

We make the following assumptions: (i) each entity (e.g., SM) has a unique identity, (ii) SMs are tamper-evident, (iii) all entities are time synchronised, (iv) the communication channels between entities are secure and authentic, and (v) users are rational - they try to buy electricity for the cheapest price but sell excess electricity at the highest possible price.

3.4 Privacy Requirements

Our protocols should satisfy the following requirements:

  • Confidentiality of bids: No entity (except the bid originator) should have access to the content of bids.

  • Auction winner privacy: The identity of a trading user (auction winner) should not be disclosed to any entity.

  • Minimum data disclosure: Suppliers should access only the aggregate data traded by their consumers.

  • User privacy: Suppliers should access only the monthly bill of all their customers (including the trading users).

3.5 Multiparty Computation (MPC)

Secure MPC allows any set of mutually distrustful parties to compute any function such that no party learns more than their original input and what can be inferred from the output. In short, parties want to compute , where corresponds to the secret input of party , in a distributed fashion with guaranteed correctness such that learns only and what can be inferred from . Furthermore, by using arithmetic circuits, any functionality can be constructed on MPC. Notice that any oblivious functionality built in this way would be as secure as the underlying MPC protocols used for its execution. For our protocol design we make use of the following well-known functionality construction: secure comparison [32], secure sorting [33] and secure permutation [34].

Symbol Meaning
     -th time slot
     -th user
     -th user’s bill for
     electricity volume in absolute terms from the -th bid
     unit price enclosed in the -th bid
     binary value corresponding to the -th bid: indicates a demand bid and a supply bid
     unique supplier identifier where is the set of all suppliers. Moreover, is encoded in a vector, i.e, on the -th position corresponds to the suppliers unique identifier, and otherwise, for all .
     bid’s unique identifier from the -th bid
     volume of electricity traded on the market for
     trading price (price of the lowest supply bid) for
     binary value: bid accepted, bid rejected
     set of the volume of electricity traded by supplier affiliation where stands for the summation of all the accepted bids from users affiliated to the supplier , for all
Table 1: Notation.

3.6 Notations

We use square brackets to denote either encrypted or secretly shared values, e.g., . Assignments that are a result of any securely implemented operation are represented by the use of the infix operator, e.g., . This extends to any operation over securely distributed data, as its result would be of a secret nature too. Vectors are denoted by capital letters. For a vector, say , represents its -th element and its size. The bids originated by SMs are considered as input data. Each bid is a tuple and is the vector of all bids. Table 1 lists the notations used in the paper.

We assume all bid elements belong to , where M is a sufficiently large prime so that no overflow occurs, and the number of bids or at least an upper bound on them is publicly known. Any other data related to the bid is kept secret. Note that in case the protocol admits a single supply and a single demand bid per SM, the computation of this upper bound is trivial. Markets could opt for enforcing all participants’ SMs to submit a bid regardless of whether they participate or not at the market clearance. Let be a sufficiently big number such that it is greater than any input value from the users, but . In this scenario, non-participating SMs would have to replace their input values by and accordingly.

4 Privacy-friendly Protocols for Local Electricity Trading and User Billing

In this section, we propose two novel protocols for privacy-friendly electricity trading and billing, respectively.

4.1 Electricity Trading Protocol

Our trading protocol covers the first three steps of the local electricity market summarised in Section 3.2, namely Bid submission, Trading price & winners selection and Informing users and suppliers. Prior to the description of these steps, we first introduce the time-frame of the trading. Private bids for trading period have to be submitted before the beginning of . The auction for is computed at period and the outcome is announced to the users and suppliers before the end of . This is done to allow suppliers to trade in the wholesale market during so that they can adjust their wholesale deals according to the local market outcome.

4.1.1 Bid submission (for )

It takes place before the start of and consists of two tasks: bidding and randomisation.

  • Bidding: Each dealer, i.e., SM, prepares its individual bid and sends (parts of) it to the computational parties, i.e., the trading platform. The preparation takes into account various factors such as available (or required) extra electricity, market conditions, as well as the type of underlying cryptographic primitives used in the protocol. In the case of using a secret sharing scheme as the primitive, each dealer generates shares of its bid using a linear secure secret sharing scheme of choice, e.g.,the scheme in [35]. The number of generated shares is equal to the number of the computational parties, three in our case. This is the only input required from the dealers. Then, they send the corresponding shares of their bids to the respective computational parties for evaluation.

  • Randomisation: To randomly permute the dealers’ input, upon reception, each computational party multiplies each share (ciphertext) with a column of a randomised permutation matrix. These matrices can be precomputed in an “offline phase”. This can be achieved by the intervention of a trusted dealer that is not directly involved at any level of the computations [36]. The amount and the purpose of the randomly generated numbers depend on the underlying security model and primitives used by the market. Since the permutation matrix generation used by Bogdanov et al. [37] can be executed “offline”, we use this technique in our protocol.

4.1.2 Trading price & winners selection (for )

It takes place at period and consists of a single task: the market clearance.

  • Market Clearance: The computational parties calculate the trading price and the traded electricity volume, and identify the accepted and rejected bids in a data-oblivious fashion. Algorithm 1 gives a detailed overview of our privacy-friendly market clearance. The computational parties calculates the trading price , the volume of electricity traded and the vector of adjudicated demand and supply bids . They do it by obliviously calculating the aggregation of the demand bids , and then iterating over the set of all bids in using their volume to match . To access the vector of accepted supply bids, it is enough to compute . To find the vector of accepted demand bids, it is sufficient to calculate .

Input: Vector of bid tuples
Output: Trading price , volume of traded electricity [], vector of accepted bids of size , vector of aggregated volume traded by supplier of size
1 for  to  do
4 end for
8 for  to  do
12          for  to  do
15          end for
19 end for
Algorithm 1 Market Clearance

4.1.3 Informing users and suppliers (for )

It takes place before the start of and consists of two tasks: informing users and suppliers, respectively.

  • Informing users: To hide the order of the bids, the computational parties shuffle again the vector of all bids , together with the associated vector . Then, they use the open operation of the underlying MPC primitive on the trading price (for ) and on all the bids , for all . The computational parties then send the shares corresponding to the tuple to the dealer (SM/user) that originated the bid identified by . The SM then reconstructs the shares and learns if the bid was accepted or rejected, as well as the trading price .

  • Informing suppliers: The computational parties send the shares of the volume aggregation , for all , to the corresponding suppliers which reconstruct these shares to learn their corresponding aggregate volumes of electricity traded by their customers for . The suppliers also learn the market trading price .

Correctness: The general goal of the protocol is to compute the trading price and to identify the accepted and rejected bids for each trading period. Any supply bid below the trading price, and any demand bid above this price is automatically accepted. The market equilibrium is identified when the price of a given supply allocation surpasses the price of the next cheapest available demand allocation.

In our protocol (see Algorithm 1), we sort all the bids regardless of whether they are demand or supply bids. We then identify and select bids until the aggregate demand () is matched (note that to maintain secrecy we iterate over the set of all bids) choosing the bids in ascending order of price. If a supply bid is selected, this implies that there is no supply bid that could be allocated to reduce , and hence is not part of the market clearance. Using cancels the supply bid’s effect over , and provides us with sufficient tools to identify it. The opposite occurs when a demand bid is selected. The bids that were used to reduce can be identified, and correspond to all the supply and demand bids with prices below and above the trading price, respectively. From this, the set of accepted bids follows. The trading price is set to the price of the last selected supply bid.

Complexity: The complexity of the protocol grows linearly with the number of bids. The complexity of Algorithm 1 is . Note that the number of suppliers rarely varies over time, and is of a limited size. As an additional note, secure vector permutation can be achieved in , where is the size of the vector. Moreover, the sorting method used by our protocol can achieve .

4.2 Privacy-Friendly Billing Protocol

As mentioned before, the suppliers use the imported and exported electricity values from their customers’ SMs, in conjunction with the users’ trades for the trading period and the trading price, to adjust the customers’ bills. However, providing such information to the suppliers poses privacy threats. Therefore, we propose the following private reporting mechanism that both facilitates the calculation of the correct bill and preserves the users’ privacy.

Let be the total number of trading a user has done at the local market during a billing period (i.e., there are trading periods at the local market during one billing period). Then each user has a vector of values which correspond to the user’s bill at each period . These values can be calculated by the SM locally, using the total amount of electricity measured at each period and the amount of electricity traded at that period. The goal is to report s in such a manner that it preserves the privacy of the values but still allows the supplier to calculate the user’s monthly bill, .

Let and be as before. Then, in each billing period, each user randomly selects elements , for such that . At the end of each trading period, masks as . The user then sends to the supplier. Upon receiving all , from , the supplier computes the monthly bill for the user as

The random elements elements function as one-time masks so that s do not reveal information about s, for .

5 Security Analysis

We analyse the security of our trading protocol (cf. Section 4.1) in the Universal Composability framework [38]. In this framework, the ideal functionality of MPC is modeled as Arithmetic Black Box (ABB) [39].

Definition 1 (ABB Functionality ).

The ideal functionality for MPC is defined as follows:

  • : Receive a value and store .

  • : Create a share of .

  • : Compute and store .

  • : Compare and , and return if and 1 otherwise.

  • : Check if ; return if , 0 otherwise.

  • : Sample and store .

  • : Given an input return a random permutation of it.

  • : Send the value to all players.

Addition and scalar multiplication are denoted by their corresponding conventional symbols and .

ABB can be thought of as a generic procedure for secure distributed computation, and provides us with abstraction of the details of MPC operations and of secret sharing. Any number of players can send their private input to ABB to compute any computable function on their private inputs. The computation results are stored in the internal state of ABB to be used in the subsequent computations. Stored values are only made public if enough number of players agree to it.

Definition 2 (UC-security [40]).

A real protocol is UC-secure if, for any adversary , there exists a simulator for which no environment

can distinguish with a non-negligible probability if it is interacting with

and or S and the ideal functionality .

Definition 3 (Universal Composition [40]).

Let and be two protocols such that -UC-emulates and -UC-emulates , when using as a subroutine. Then -UC-emulates , when using as a subroutine.

Definition 4 (Ideal Functionality of the Local Electricity Market ).

Given a set of private input bids, the ideal functionality computes the trading price, the winners, and the aggregate data of winners per supplier, without learning anything but the trading price.

Theorem 1.

Let be the local electricity trading protocol presented in Section 4.1. Then securely emulates .


The proof is a straightforward application of the Universal Composition Theorem 3, since (i) each ABB operation UC-emulates its corresponding ideal functionality and (ii) the local electricity trading protocol consists only of the ABB operations that are securely composable. ∎

6 Experimentation Results

In this section we provide the details of the implementation of our local electricity trading protocol and the results of its evaluation under realistic scenario configurations. Next we elaborate on the data generation process, the experimentation settings and the results.

6.1 Data Generation

For our experiments, we used realistic data from Belgium. First we picked a time slot and date, i.e., 13:00h-13:30h on 5-th of May 2016, during which 2382 MW solar electricity was generated in Belgium by solar panels with total capacity 2953 MW [41] – on average each solar panel has produced electricity approximately equal to 81.66% of its capacity. The average electricity consumption data of a Belgian household during the same time slot was 0.637 kW [42]

. Thus, for each user we generated a random consumption data for this time slot with mean equal to the average consumption data, i.e., 0.637, standard deviation equal to 0.20 and variance equal to 0.04. Then, we randomly chose 30% of the users to have installed a solar panel at their homes, and each of the solar panels is randomly assigned one of the following electricity generation capacities: 2.3, 3.6 or 4,7 kW. After that, we randomly generated the electricity output of each solar panel during this time slot with a mean equal to the capacity of the given solar panel multiplied with the efficiency factor for the time slot, i.e., 81.66%, standard deviation equal to 0.20 and variance equal to 0.04. Once we generated the electricity consumption and generation data for each user with a solar panel, we simply subtracted the latter from the first value to find the amount of excess electricity each user has.

We assumed that there are 10 different suppliers available in the market and randomly assigned a supplier to each user. The retail electricity sell price of the suppliers is set to  €/kWh and the retail buy price is set to  €/kWh. For the bid price selection we used the following rational steps. We divided the retail electricity sell and buy price difference into nine ranges each including several (overlapping) prices, e.g., range 2 includes three prices: , and  €/kWh, whereas range 7 includes four prices: , , and  €/kWh. Then, for each user, depending on how much excess electricity he/she has for sell or he/she wants to buy, we picked randomly one of the prices from the appropriate price range. For selecting the appropriate price range we assumed that the users are rational, i.e., if they have a lot of excess electricity to sell, they would choose a lower asking price, so they could sell it all. In contrast, if they have a little excess electricity to sell, they would ask for a higher price since selling it for a cheap price will not allow them to make a high profit by selling it at the market compared to selling it directly to the supplier.

In summary, for each user we generated the following data items: unique user ID, amount of electricity for the bid, bid price, indicator if the bid is a supply or demand bid, and ID of the user’s contracted supplier.

6.2 Characteristics, Settings and Environment

We executed our experimentation using the MPC Toolkit proposed in [43] which is based on BGW [44]. This library includes all the underlying crypto primitives and other sub-protocols we report on, together with our own introduced code. The library was compiled with NTL (Number Theory Library) [45] that itself was compiled using GMP (GNU Multiple Precision Library). These two libraries are used for the modulo arithmetic that is extensively used by the underlying MPC protocols. Each instance of the prototype comprises two CPU threads. One manages message exchanges exclusively and the other executes the protocol and the related cryptographic tasks. The application itself is not memory demanding, with each instance requiring approximately MB of allocated memory at any time, during our most memory demanding test which included 2500 bids.

Our prototype was built in C++ following an object oriented approach, with modularity and composability in mind. It has an engine that separates communication and cryptographic tasks. Table 2 shows the detailed list of the primitives used in our implementation. All our tests were performed under a 3-party setting, with two available cores for each instance. We ran our tests starting with a baseline of a realistic scenario with 100 bids and then monotonically increasing the number of bids until they reached 2500 bids. Each test scenario was repeated times to reduce the impact of the noise. The values reported in the rest of this section correspond to those of the resulting averages. Finally, in all of our tests, bids have been randomly distributed between different suppliers. We executed our tests on a single 64-bit Linux server with 2*2*10-cores with Intel Xeon E5-2687W microprocessors at 3.1GHz and 25 MB of cache, and with memory of 256 GB.

Primitive Protocol
Sharing Shamir Secret Sharing [35]
Multiplication Gennaro et al. [46]
Inequality Test Catrina and Hoogh [32]
Random Bit Generation Damgård et al. [47]
Sorting: QuickSort Hamada et al. [33]
Permutation: Sorting Network Lai et al. [48]
Table 2: List of primitives used in our bidding protocol prototype

6.3 Results

Our trading protocol prototype requires bit randomization for the comparison methods. The task of generating such values could be executed beforehand, in an “offline” phase. The “online” phase would execute the remaining tasks and would utilise the randomization values generated during the “offline” phase. Figure 2 shows such breakdown for all the test scenarios considered. We measured the computational cost at every test instance. For the 2500 bids case, our prototype took 678.50 seconds for either sending or waiting to receive other parties’ messages (note that our prototype is synchronous) and 215.52 seconds for the remaining tasks, e.g., crypto primitives. In other words, approximately of the computational time was dedicated to transmission related tasks. Moreover, the asymptotic behaviour on the growth of the computational time seems to follow the behaviour included in the theoretical complexity analysis presented in Section 4.1

Table 3 shows a more complete breakdown of our results. In short, the 2500 bids instance total time on the online phase is less than 5 minutes, while when the offline phase is considered, it is less than 15 minutes. In both cases this is less than the typical 30 minutes duration of a trading period . Note that during our tests, approximately of the computational time was spent on sorting the bids. Although the number of suppliers rarely changes with time and it is relatively low, in our tests we used a fixed value of . Given that they are involved in the other stages of the protocol, their influence on the number of suppliers is quite limited. This means that our algorithm can be easily adjusted to other realistic scenarios without much overhead, for bigger suppliers settings.

As for the simple billing protocols, it is computationally cheap and does not incur any communication overhead. The only requirement is that in each billing period, each user (or SM) needs to choose random elements from such that they add up to .

Bids Number of Number of CPU time Online phase
com. rounds comparisons (in sec) (in sec)
Table 3: Overall Results
Figure 2: Numerical results for our trading protocol.

7 Conclusions

In this paper we proposed two privacy-friendly protocols for local electricity trading and billing, respectively, that allow users to trade their excess electricity among themselves as well as calculate their monthly bill. Our first protocol employs a bidding scheme based upon MPC, and the selection of the bids and the calculation of the electricity trading price are performed in a decentralised and oblivious manner. Our second protocol uses private data aggregation technique to calculate the users’ monthly bills locally and allows the suppliers to compute only the final monthly bill per customer, but not the individual metering data per time slot. We also implemented the trading protocol in C++ and tested its performance with realistic data. Our simulation results indicate its feasibility for a typical electricity trading period of, for example, 30 minutes, as the bidding protocol is performed for 2500 bids in less than five minutes in the online phase. Both of our protocols are efficient and practical enough to be deployed in real world.

Future work will include possible optimisation of the underlying MPC implementation of the trading protocol.


  • [1] H. Farhangi, “The path of the smart grid,” IEEE Power and Energy Magazine, vol. 8, no. 1, pp. 18–28, January 2010.
  • [2] M. A. Mustafa, S. Cleemput, and A. Abidin, “A local electricity trading market: Security analysis,” in IEEE PES ISGT-Europe, 2016, pp. 1–6.
  • [3] G. W. Hart, “Nonintrusive appliance load monitoring,” Proceedings of the IEEE, vol. 80, no. 12, pp. 1870–1891, 1992.
  • [4] A. Abidin, A. Aly, S. Cleemput, and M. A. Mustafa, “An MPC-based privacy-preserving protocol for a local electricity trading market,” in 15th Int. Conf. on Cryptology and Network Security (CANS 2016), ser. LNCS, vol. 10052.   Springer, 2016, pp. 615–625.
  • [5] P. McDaniel and S. McLaughlin, “Security and privacy challenges in the smart grid,” IEEE Security Privacy, vol. 7, no. 3, pp. 75–77, May 2009.
  • [6] G. Kalogridis, M. Sooriyabandara, Z. Fan, and M. A. Mustafa, “Toward unified security and privacy protection for smart meter networks,” Systems Journal, 2014.
  • [7] W. Lee, L. Xiang, R. Schober, and V. W. S. Wong, “Direct electricity trading in smart grid: A coalitional game analysis,” IEEE Journal on Selected Areas in Communications, vol. 32, no. 7, pp. 1398–1411, July 2014.
  • [8] W. Tushar, C. Yuen, D. B. Smith, and H. V. Poor, “Price discrimination for energy trading in smart grid: A game theoretic approach,” IEEE Transactions on Smart Grid, vol. 8, no. 4, pp. 1790–1801, July 2017.
  • [9] I. S. Bayram, M. Z. Shakir, M. Abdallah, and K. Qaraqe, “A survey on energy trading in smart grid,” in Signal and Information Processing (GlobalSIP), 2014 IEEE Global Conference on, Dec 2014, pp. 258–262.
  • [10] C. Zhang, J. Wu, C. Long, and M. Cheng, “Review of existing peer-to-peer energy trading projects,” Energy Procedia, vol. 105, pp. 2563 – 2568, 2017, 8th International Conference on Applied Energy, ICAE2016, 8-11 October 2016, Beijing, China.
  • [11] E. Mengelkamp, P. Staudt, J. Garttner, and C. Weinhardt, “Trading on local energy markets: A comparison of market designs and bidding strategies,” in 14th International Conference on the European Energy Market (EEM), June 2017, pp. 1–6.
  • [12] E. Mengelkamp, B. Notheisen, C. Beer, D. Dauer, and C. Weinhardt, “A blockchain-based smart grid: towards sustainable local energy markets,” Computer Science - Research and Development, Aug 2017.
  • [13] J. Kang, R. Yu, X. Huang, S. Maharjan, Y. Zhang, and E. Hossain, “Enabling localized peer-to-peer electricity trading among plug-in hybrid electric vehicles using consortium blockchains,” IEEE Transactions on Industrial Informatics, vol. PP, no. 99, pp. 1–10, 2017.
  • [14] N. Z. Aitzhan and D. Svetinovic, “Security and privacy in decentralized energy trading through multi-signatures, blockchain and anonymous messaging streams,” IEEE Transactions on Dependable and Secure Computing, vol. PP, no. 99, pp. 1–14, 2016.
  • [15] M. Mihaylov, S. Jurado, N. Avellana, K. V. Moffaert, I. M. de Abril, and A. Nowé, “Nrgcoin: Virtual currency for trading of renewable energy in smart grids,” in 11th International Conference on the European Energy Market (EEM14), May 2014, pp. 1–6.
  • [16] “Privacy-friendly secure bidding for smart grid demand-response,” Information Sciences, vol. 379, pp. 229–240, 2017.
  • [17] I. Kounelis, G. Steri, R. Giuliani, D. Geneiatakis, R. Neisse, and I. Nai-Fovino, “Fostering consumers’ energy market through smart contracts,” in International Conference in Energy and Sustainability in Small Developing Economies (ES2DE 2017), July 2017, pp. 1–6.
  • [18] S. Uludag, M. F. Balli, A. A. Selcuk, and B. Tavli, “Privacy-guaranteeing bidding in smart grid demand response programs,” in IEEE Globecom Workshops (GC Wkshps), Dec 2015, pp. 1–6.
  • [19] M. Balli, S. Uludag, A. Selcuk, and B. Tavli, “Distributed multi-unit privacy assured bidding (PAB) for smart grid demand response programs,” IEEE Tran. on Smart Grid, vol. PP, no. 99, pp. 1–9, 2017.
  • [20] A. C.-C. Yao, “Protocols for secure computations (extended abstract),” in 23rd Annual Symposium on Foundations of Computer Science.   IEEE, 1982, pp. 160–164.
  • [21] A. Aly and M. Van Vyve, “Practically efficient secure single-commodity multi-market auctions,” in Financial Cryptography, ser. LNCS.   Springer, 2016.
  • [22] R. Petrlic, “A privacy-preserving concept for smart grids,” in Sicherheit in vernetzten Systemen 18. DFN Workshop, ser. Books on Demand GmbH, 2010, pp. 1–14.
  • [23] A. Molina-Markham, P. Shenoy, K. Fu, E. Cecchet, and D. Irwin, “Private memoirs of a smart meter,” in 2nd Workshop on Embedded Sensing Systems for Energy-Efficiency in Building (BuildSys’10).   ACM, 2010, pp. 61–66.
  • [24] M. Jawurek, M. Johns, and F. Kerschbaum, “Plug-in privacy for smart metering billing,” in Privacy Enhancing Technologies, ser. LNCS.   Springer, 2011, vol. 6794, pp. 192–210.
  • [25] A. Rial and G. Danezis, “Privacy-preserving smart metering,” in 10th Workshop on Privacy in the Electronic Society (WPES’11).   ACM, 2011, pp. 49–60.
  • [26] G. Danezis, M. Kohlweiss, and A. Rial, “Differentially private billing with rebates,” in Information Hiding, ser. LNCS.   Springer, 2011, vol. 6958, pp. 148–162.
  • [27] F. Li, B. Luo, and P. Liu, “Secure information aggregation for smart grids using homomorphic encryption,” in SmartGridComm, 2010, pp. 327–332.
  • [28] M. A. Mustafa, N. Zhang, G. Kalogridis, and Z. Fan, “MUSP: Multi-service, user self-controllable and privacy-preserving system for smart metering,” in ICC, 2015.
  • [29] ——, “DEP2SA: A decentralized efficient privacy-preserving and selective aggregation scheme in advanced metering infrastructure,” IEEE Access, vol. 3, pp. 2828–2846, 2015.
  • [30] M. A. Mustafa, S. Cleemput, A. Aly, and A. Abidin, “An MPC-based protocol for secure and privacy-preserving smart metering,” in 2017 IEEE PES Innovative Smart Grid Technologies Conference Europe (ISGT-Europe), 2017, pp. 1–6.
  • [31] I. Bilogrevic, J. Freudiger, E. De Cristofaro, and E. Uzun, “What’s the gist? privacy-preserving aggregation of user profiles,” in Computer Security-ESORICS 2014.   Springer, 2014, pp. 128–145.
  • [32]

    O. Catrina and S. de Hoogh, “Secure multiparty linear programming using fixed-point arithmetic,” in

    ESORICS 2010, ser. LNCS, vol. 6345.   Springer, 2010, pp. 134–150.
  • [33] K. Hamada, R. Kikuchi, D. Ikarashi, K. Chida, and K. Takahashi, “Practically efficient multi-party sorting protocols from comparison sort algorithms,” in ICISC ’12, ser. LNCS, vol. 7839.   Springer, 2003, pp. 202–216.
  • [34] A. Czumaj, P. Kanarek, M. Kutylowski, and K. Lorys, “Delayed path coupling and generating random permutations via distributed stochastic processes,” in SODA’99.   SIAM, 1999, pp. 271–280.
  • [35] A. Shamir, “How to share a secret,” Commun. ACM, vol. 22, no. 11, pp. 612–613, 1979.
  • [36] I. Damgård, V. Pastro, N. P. Smart, and S. Zakarias, “Multiparty computation from somewhat homomorphic encryption,” in CRYPTO ’12, ser. LNCS, vol. 7417.   Springer, 2012, pp. 643–662.
  • [37] D. Bogdanov, S. Laur, and J. Willemson, “Sharemind: A Framework for Fast Privacy-Preserving Computations,” in ESORICS, ser. LNCS, vol. 5283.   Springer, 2008.
  • [38] R. Canetti, “Security and composition of multiparty cryptographic protocols,” Journal of Cryptology, vol. 13, no. 1, pp. 143–202, 2000.
  • [39] I. Damgård and J. B. Nielsen, “Universally composable efficient multiparty computation from threshold homomorphic encryption,” in CRYPTO, vol. 2729.   Springer, 2003, pp. 247–264.
  • [40] R. Canetti, “Security and composition of multiparty cryptographic protocols,” Journal of Cryptology, vol. 13, no. 1, pp. 143–202, 2000.
  • [41]
  • [42]
  • [43] A. Aly, “Network flow problems with secure multiparty computation,” Ph.D. dissertation, Universté catholique de Louvain, IMMAQ, 2015.
  • [44] M. Ben-Or, S. Goldwasser, and A. Wigderson, “Completeness theorems for non-cryptographic fault-tolerant distributed computation,” in STOC.   ACM, 1988, pp. 1–10.
  • [45] V. Shoup, “Ntl: A library for doing number theory,” 2001.
  • [46] R. Gennaro, M. O. Rabin, and T. Rabin, “Simplified VSS and fast-track multiparty computations with applications to threshold cryptography,” in PODC ’98.   ACM, 1998, pp. 101–111.
  • [47] I. Damgård, M. Fitzi, E. Kiltz, J. B. Nielsen, and T. Toft, “Unconditionally secure constant-rounds multi-party computation for equality, comparison, bits and exponentiation,” in TCC 2006, ser. LNCS, vol. 3876.   Springer, 2006, pp. 285–304.
  • [48] S. Laur, J. Willemson, and B. Zhang, “Round-efficient oblivious database manipulation,” in ISC 2011, ser. LNCS.   Springer, 2011, vol. 7001, pp. 262–277.