Privacy-Preserving Electricity Billing System Using Functional Encryption †

: The development of smart meters that can frequently measure and report power consumption has enabledelectricity providers to offer various time-varying rates, including time-of-use and real-time pricing plans. High-resolution power consumption data, however, raise serious privacy concerns because sensitive information regarding an individual’s lifestyle can be revealed by analyzing these data. Although extensive research has been conducted to address these privacy concerns, previous approaches have reduced the quality of measured data. In this paper, we propose a new privacy-preserving electricity billing method that does not sacriﬁce data quality for privacy. The proposed method is based on the novel use of functional encryption. Experimental results on a prototype system using a real-world smart meter device and data prove the feasibility of the proposed method.


Introduction
The traditional electricity metering and billing method, in particular for residential consumers, involved installing simple electromechanical meters that could be read manually.Meters were typically read monthly, and customers were charged a rate proportional to their monthly usage.In this situation, the only option an electricity provider could offer was a "flat" or "fixed" rate, with only slight variations such as increasing the unit price as consumption increases over the course of the billing period [1].A typical implementation of this policy is a "tiered" rate plan [2].
With the development and extensive deployment of smart meters, however, providers are now offering various time-varying rates.The time-of-use (TOU) rate plan divides the day into time periods and sets a different rate for each period [1].There are other pricing variations as well, such as critical peak pricing (CPP) and peak-time rebates (PTR).The most advanced type of plan is real-time pricing (RTP), which allows price change per hour or even half hour [1,3].The billing formula for these nonflat rates can be simplified as follows: where n is the number of unit time periods per billing period, r i is the electricity price for time period i, and u i is the amount of electricity consumed in time period i.Alternatively, the electricity charge can be represented as the inner product: of two n-dimensional vectors, r = (r 0 , . . ., r n−1 ) and u = (u 0 , . . ., u n−1 ).
When smart meters measure and report power consumption data more frequently, consumers can adopt more fine-grained plans regarding their usage.Currently deployed smart meters already deliver load data with very high resolution, e.g., at five-minute intervals [4].However, these detailed power consumption data raise serious privacy concerns, because personal data can be inferred from the energy use profiles measured by smart meters [5].Recent advances in non-intrusive appliance load monitoring (NIALM) and disaggregation techniques make it possible to extract the energy consumption statistics of an individual appliance from aggregated data involving many appliances [6][7][8][9][10][11][12][13].Although the primary goal of these algorithms is to provide the consumer with useful energy feedback, such NIALM analyses might be misused, compromising privacy by monitoring the consumer's appliance usage patterns [14].Advanced NIALM analysis can reveal significant information regarding the persons in a household, such as their presence, sleep schedule, and meal times [15].In extreme cases, if the sampling interval is sufficiently small, even the television channel that is being watched can be identified, along with audiovisual content [16].According to the quantitative analysis in Reference [14], to guarantee that all appliances are privacy-safe, the measurement interval of a smart meter should be at least one hour, which is significantly longer than the time resolution of state-of-the-art smart meters.
Consequently, there has been extensive research to resolve this privacy issue [17][18][19].Previous approaches can be classified into the following three categories: (i) Providing only low-resolution data, i.e., data with decreased time granularity [14,17,18,20], (ii) perturbation or obfuscation of the measured data by adding controlled noise [21][22][23], and (iii) aggregation of data from multiple smart meters using a trusted third party [21], masking [24,25], or additive homomorphic encryption [23,26,27].However, all of the above methods essentially reduce the quality of the measured data.Consequently, they cannot be used for granular billing that requires high-resolution metering data from a single smart meter.As such, there is a tradeoff between the functionality of smart meters and the privacy of customers.
In this paper, we aim at achieving both functionality and privacy by taking a completely different approach to privacy-preserving billing methods.Our method allows a smart meter to send the provider all measured data with full granularity and without privacy leaks.Our proposal is based on the novel use of a recently developed advanced cryptographic primitive, viz. the functional encryption (FE) algorithm [28][29][30].Using the proposed system, a smart meter encrypts the measured consumption data u = (u 0 , . . ., u n−1 ) and sends them to the electricity provider.The provider is provided with a restricted decryption key associated with r = (r 0 , . . ., r n−1 ), with which it cannot directly recover u, and only obtains the weighted sum (Equation ( 2)).This approach naturally resolves the privacy issue because the provider never sees the individual consumption statistic u i for each time period.To verify the feasibility of the proposed method, we implemented a prototype billing system composed of a smart meter, a provider's billing server, and a regulatory agency.In particular, we used an off-the-shelf smart meter device to represent a real-world scenario.The proposed system does not require special-purpose hardware.It is realized merely through a software update of the smart meter.Our experimental results with real measurement data prove that the proposed system performs well with currently deployed smart meters, eliminating the need to decrease data granularity.According to the experimental results, only 0.5 s are required for the entire procedure, including the tasks for the smart meter to encrypt the consumption data u and for the provider to compute the weighted sum.It should be noted that the proposed method does not render previous methods obsolete; rather, it can be combined for advanced services.For example, it may be possible to use the new method for billing and either an aggregation or perturbation method for power generation and distribution network control.

Preliminaries: Function-Hiding Inner Product Functional Encryption
Functional encryption (FE)is an encryption schemethat supports operations on encrypted data [28,29].In FE schemes, the owner of the master key can delegate arbitrary secret keys that allow decryptors to learn only specific functions of the data.For example, given a ciphertext of a message x and a secret key restricted to a function f , the decryptor only receives the value f (x), and does not learn anything about x.If the data x of FE are represented as a vector and the function f is defined as the inner product of x with a predefined vector v, then a decryptor can recover the inner product v, x by inputting the ciphertext of vector x and the restricted secret key associated with v.This FE scheme is called an inner product encryption (IPE) scheme [30][31][32][33][34].
Some IPE schemes provide an additional property, viz.function hiding.In these schemes, both x and v are kept secret from the decryptor, even though the decryptor possesses the secret key associated with v.In 2015, Bishop et al. first proposed function-hiding inner product encryption (FHIPE), which considered these capabilities [31].Moreover, extensive research is currently under way to improve the performance of the FHIPE [30,[32][33][34].In this paper, we used the practical scheme Π IPE proposed by Kim et al. in 2018 [30].The Π IPE scheme consists of four probabilistic polynomial time (PPT) algorithms, Setup, KeyGen, Encrypt and Decrypt, as follows.For more details regarding the operations using bilinear groups, refer to Reference [30].

•
Setup(1 λ ) → (pp, msk): Given a security parameter λ, the setup algorithm Setup outputs the public parameters pp and the master secret key msk corresponding to λ.More precisely, the setup algorithm samples an asymmetric bilinear group (G 1 , G 2 , G T , q, e), where G 1 and G 2 are two distinct groups of prime order q, and e : G 1 × G 2 → G T is a function that maps two elements from G 1 and G 2 onto a target group G T , also of prime order q.The setup algorithm then chooses generators g 1 ∈ G 1 and g 2 ∈ G 2 .Next, the algorithm samples B ← GL n (Z q ), where GL n (Z q ) is the general linear group of (n × n) matrices over Z q .Throughout the paper, bold uppercase letters, e.g., B, refer to matrices.Then, the algorithm sets B = det(B) • (B −1 ) , where det(B) and (B −1 ) denote the determinant of B and the transpose matrix of B −1 , respectively.Finally, the setup algorithm outputs the public parameters pp = (G 1 , G 2 , G T , q, e) and the master secret key msk = (pp, g 1 , g 2 , B, B ). • KeyGen(msk, v) → SK v : Given the master secret key msk and a vector v = (v 0 , . . ., v n−1 ), the key generation algorithm KeyGen chooses a uniformly random element α ∈ Z q and outputs a secret key: ).
Note that the second component of SK v is a vector of group elements.That is, according to the notation in Reference [30], for a group element g ∈ G 1 and a row vector u = (u 0 , . . ., u n−1 ), g u denotes the vector of group elements, (g u 0 , . . ., g u n−1 ).• Encrypt(msk, x) → CT x : Given the master secret key msk and an input vector x = (x 0 , . . ., x n−1 ), the encryption algorithm Encrypt chooses a uniformly random element β ∈ Z q and outputs a ciphertext: ).
• Decrypt(pp, SK v , CT x ) → z: Given the public parameters pp, a secret key , the decryption algorithm Decrypt computes: Then, the algorithm checks whether there exists z, such that (D 1 ) z = D 2 , and either outputs z or an error symbol implying that decryption is impossible.If there is such z, it satisfies z = v, x .In other words, z is the inner product of v and x.
An important property of the above FHIPE is that the decryptor computes z = v, x from SK v and CT x but does not learn anything about either v or x.It should be noted that the roles of KeyGen and Encrypt are symmetric.This symmetry is used to design our system, as explained in the next section (see Section 3.3).

System Model
Figure 1 shows the proposed system model.We considered a system involving three parties: An energy service provider (ESP), a smart meter, and a regulatory agency (RA).The ESP is a company that wants to collect electricity charges in return for the electricity used by smart meter owners.The smart meter is a device that periodically reports the power consumption of its owner, who agrees to pay the electricity charges, yet prefers to hide power usage patterns from the ESP.Because electric power companies are generally monopolies, it is common for RAs to approve prices for electricity [35].Our model reflects this situation and considers the RA to be a trusted third party with the following roles: (i) Generating the master secret key and public parameters for FHIPE at the registration stage of a smart meter, and (ii) encoding the electricity price for each time period according to the request of the ESP.We remark that the security of the proposed system relies on the trusted RA.That is, if the RA is compromised, the privacy of users may be invaded.Therefore, appropriate technical measures should be provided to protect the RA.In addition, we should consider the possibility that the RA might collude with the ESP.However, as the examples of RA, we considered government agencies such as the Korea Electricity Regulatory Commission or the US Federal Energy Regulatory Commission [36,37].These government agencies aim to protect consumers' rights and interests [36] and assist consumers in obtaining economically efficient, safe, reliable, and secure energy services at a reasonable cost through appropriate regulatory and market means [37].Therefore, it is reasonable to assume that they would not collude with the ESP.Because RA is a trusted party, it never deviates from the protocol.We assume that the smart meter is tamper-proof, and accurately measures and reports the electricity usage.Finally, we assume that ESP is honest-but-curious, i.e., it performs the billing protocol honestly and correctly, but might try to extract useful information about the electricity usage patterns if the data from the smart meter are not encrypted.

Representation of Power Consumption Data
For our billing system, we generalized the billing Formulas (1) and (2) as follows.We first defined a reporting period as the time interval at which the smart meter reports the measured data to the ESP.This is not necessarily the same as the measurement interval.Therefore, let n be the number of measurements of power consumption data in each reporting period.For example, if the length of a reporting period is two hours and the measurement interval is 15 min, then n = 8.Let u i be the electricity consumption measured at the i-th measurement interval in a reporting period.Let r i be the electricity rate at the i-th interval.Then, the electricity charge c for this reporting period can be determined by the inner product: of the rate vector r = (r 0 , . . ., r n−1 ) with the consumption vector u = (u 0 , . . ., u n−1 ).

Redefining the Roles of KeyGen and Encrypt
In this paper, we used the FHIPE scheme proposed in Reference [30].As explained in Section 2, the algorithms KeyGen(msk, v) and Encrypt(msk, x) hide the vectors v and x, respectively, from the decryptor.Although KeyGen was named "key generation" and its result SK v was defined as a secret key associated with v, SK v can also be viewed as a ciphertext of v.Then, the decryption algorithm essentially computes the inner product of the two hidden vectors v and x given the two input ciphertexts SK v and CT x .This property was already mentioned in Reference [30] as a building block to construct a general two-input functional encryption.In Reference [38] (the full version of [30]), KeyGen and Encrypt were redefined as "left" and "right" encryption algorithms, respectively.Moreover, it was estimated in Reference [30] that the speed of KeyGen was faster than that of Encrypt by 1.8 to 5.3 times.Because it is reasonable to assume that the smart meter is the most resource-constrained among the three parties in Figure 1, we designed our protocol such that the smart meter can hide the measured power consumption data vector by performing the lighter KeyGen algorithm (i.e., the left encryption ), instead of Encrypt (i.e., the right encryption).

Proposed Privacy-Preserving Electricity Billing Protocol
In this section, we present the privacy-preserving electricity billing protocol, Π PPB , for our system.The protocol comprises two stages: The registration stage and the reporting stage.

Registration Stage of Proposed Protocol
Figure 2 shows the registration stage of our protocol.This stage begins with the RA performing the Setup algorithm of FHIPE.That is, the RA generates a master secret key msk and public parameters pp satisfying the security parameter λ for the smart meter.Next, the RA sets an identifier ID and n, the number of measurements of power consumption per reporting period.In addition, the measurement interval, m, is also set.For example, if the measurement interval m is 15 min and n = 8, the reporting period will be two hours.This information is also stored in the smart meter.The above process is performed when the smart meter is deployed and is marked with the red dotted box in Figure 2. Next, for every billing period, e.g., a month, the smart meter subscribes to an electricity rate plan P and transmits the tuple (ID, pp, n, m, P) to the ESP.Subscriptions to rate plans can be changed as often as desired after deployment.In this paper, we considered the electricity rate plans capable of dividing a day into multiple time periods, as with TOU or RTP.Finally, the ESP stores the tuple (ID, pp, n, m, P).

Reporting Stage of Proposed Protocol
Figure 3 shows the reporting stage of our protocol.This stage should only be performed after completing the registration stage.In the reporting stage, the smart meter measures electricity consumption u = (u 0 , . . ., u n−1 ) during a certain reporting period rp.Specifically, the smart meter measures the consumption n times during rp and represents the measured data to vector u.The smart meter then encodes this vector to U using the EncodeUsage algorithm, which is defined as EncodeUsage(msk, u) = KeyGen(msk, u).That is, EncodeUsage performs the left encryption algorithm of FHIPE using the master secret key msk.Next, the smart meter transmits the tuple (ID, rp, U) to the ESP.Upon receiving the tuple, the ESP generates an n-dimensional rate vector r = (r 0 , . . ., r n−1 ) for rp according to the rate plan P and transmits ID and r to the RA.The RA checks whether the claimed rate r is reasonable and approves r by encoding it using msk associated with ID.For this purpose, the RA performs EncodeRate, which is defined as EncodeRate(msk, r) = Encrypt(msk, r).That is, EncodeRate performs the right encryption algorithm of FHIPE.Note that EncodeRate does not need to be done for every reporting period unless the rate changes frequently.In this case, EncodeRate can be performed once in advance, and the result R can be used for many reporting periods.However, we designed our protocol, as shown in Figure 3, to cover even the most dynamic rate plans (e.g., RTP) where the price changes in real time.Smart meter users can optimize their power usage while continuously monitoring real-time price fluctuations during the reporting period.Immediately after the end of the reporting period, the ESP generates a rate vector r that reflects the tariff for the most recent reporting period.Upon receiving the approval from the RA, i.e., the encoded rate R, the ESP calculates the electricity charge c by performing the FHIPE decryption using pp, U, and R. Finally, the ESP adds the charge c for the reporting period rp to the bill of the smart meter, which has ID as an identifier.This stage is performed once each reporting period.
Importantly, the ESP does not learn anything about individual u i even though it is given U and can recover the charge (Equation ( 3)) by decrypting U.That is, our security objective is met according to the nature of FHIPE, which is proven in the next section.The FHIPE scheme [30] also protects r i from a decryptor through right encryption.However, we do not require this property because r does not need to be secret.In fact, it is generated by the decryptor itself, viz. the ESP, in our protocol.

Security Analysis
In this section, we review the security properties of the Π IPE scheme proposed in Reference [30] and prove the security of the proposed method using reduction from Π IPE .

Review of Security for the FHIPE Scheme Π IPE
Existing inner product encryption schemes, including the Π IPE scheme [30] we use, considered an indistinguishability notion of security [30][31][32][33][34]. Here, we review the security notion for Π IPE .In Reference [30], an experiment between a challenger and an adversary A that can make key generation and encryption oracle queries is defined as follows: ).Let b ∈ {0, 1}.The challenger computes (pp, msk) ← Setup(1 λ ), gives pp to the adversary A, and then responds to each oracle query type made by A in the following manner.
-Key generation oracle.On inputting a pair of vectors x 0 , x 1 ∈ Z n q \{0}, the challenger computes and returns SK ← KeyGen(msk, x b ).
-Encryption oracle.On inputting a pair of vectors y 0 , y 1 ∈ Z n q \{0}, the challenger computes and returns CT ← Encrypt(msk, y b ).
Eventually, A outputs a bit b , which is also the output of the experiment, denoted by Then, the security of an FHIPE scheme is defined using an indistinguishability notion as follows: Definition 2 (Admissibility of A [30]).For an adversary A, let Q 1 and Q 2 be the total number of key generation and encryption oracle queries made by A, respectively.For b ∈ {0, 1}, let x q \{0} be the corresponding vectors that A submits to the key generation and encryption oracles, respectively.We say that A is admissible if for all i ∈ [Q 1 ] and j ∈ [Q 2 ], and we have that: Definition 3 (IND-Security for IPE [30]).We define an inner product encryption scheme denoted as Π IPE = (Setup, KeyGen, Encrypt, Decrypt) as fully-secure if for all efficient and admissible adversaries A: To evaluate the proposed system with real-world data, we used measurement data collected by the Korea Electric Power Corporation (KEPCO) [43] from three sources, viz.an apartment building, a commercial building, and a factory.Each record in these datasets represents the daily electricity usage measured at 15-min intervals.The unit of measurement is kWh, and the valid digit of measured values is up to the second decimal place.Table 1 presents more details of the data, including the measured period, the number of records, minimum usage, maximum usage, and average usage.Along with the above data, we considered the rate plans proposed by KEPCO [44].The rate plans were TOU rate plans, and the rates were determined by the month ∈ {summer (June to August), spring/fall (March to May and September to October), winter (November to February)}, the hour in a day ∈ {the off-peak period of spring/summer/fall/winter (23:00-09:00), the shoulder period of spring/summer/fall (09:00-10:00, 12:00-13:00, 17:00-23:00), the shoulder period of winter (09:00-10:00, 12:00-17:00, 20:00-22:00), the peak period of spring/summer/fall (10:00-12:00, 13:00-17:00), the peak period of winter (10:00-12:00, 17:00-20:00, 22:00-23:00)}, and the purpose of electricity usage ∈ {general, industrial}.The range of the unit rate varied between 21.6 KRW/kWh and 244.1 KRW/kWh, and the valid digit was up to the first decimal place.We assumed that Datasets A and C used the general rate plan and that Dataset F used the industrial rate plan.We further assumed that the smart meter reported the electricity consumption data every two hours.That is, according to the definition in Section 3.2, the reporting period length was two hours.Because the measurement interval in all datasets was 15 min, the number of measured items per reporting period, i.e., the length of the consumption vector u, was n = 8.The rationale for setting the reporting period length at two ours was as follows.According to the analysis in Reference [14], the minimum interval to retain privacy is one hour, as mentioned in the introduction above.We thus provided a reasonable security margin by setting the interval as twice the minimum.
The power consumption amount recorded in the datasets listed in Table 1 and the above rates are represented with decimal fractions.Meanwhile, the operations of the FHIPE scheme [30] are only defined over integers.Therefore, to use the FHIPE operations properly without losing significant digits, u and r need to be quantized.For this purpose, u and r are converted to integer vectors before encoding.Because the valid digits in u are up to the second decimal place, the elements in u are quantized by u × 100.Similarly, r is quantized by performing r × 10, because the valid digits in the original r are up to the first decimal place.Then, the correct electricity charge is recovered by computing c/1000, i.e., z/1000.
Here, we present our experimental results.The experiments separately measured the execution times and data volume exchanged in the two stages: Registration and reporting.The experimental results for the execution time of the registration stage are presented in Table 2.Note that the performance of this stage depends on the security parameter λ and the vector size n, which also decides the dimension s of the matrices in the master secret key.We used the MNT 159 curve for bilinear group operations.It corresponds to λ = 80, which implies that the time complexity of the best-known attack algorithm to break the underlying FHIPE is roughly 2 80 .We set n = 8, as explained above.The measured times are the averages over 10,000 executions.The column Setup RA represents the time for the operation (msk, pp) ← Setup(1 λ ) by the RA.The columns Store RA , Store SM , and Store ESP represent the times to perform Store(ID, pp, msk, n, m) by the RA, Store(ID, pp, msk, n, m) by the smart meter, and Store(ID, pp, n, m, P) by the ESP, respectively.The Network column represents the overall network overhead for the registration stage.As shown in the table, the registration stage completed quickly, i.e., in less than 50 ms in total.Next, Table 3 presents the experimental results for the execution time of the reporting stage.The datasets listed in Table 1 and the above rate plans provide us with the electricity consumption vectors u and the rate vectors r, respectively, for the corresponding reporting periods.Because the length of a reporting period is 2 hours, the number of reports per day is 12.Because every record in the datasets corresponds to a single day's usage, the total number of reports for a dataset is calculated by #Records × 12.The columns Encode SM , Encode RA , and Decrypt ESP represent the time required for the operations U ← EncodeUsage(msk, u), R ← EncodeRate(msk, r), and c ← Decrypt(pp, U, R) in Figure 3, respectively.The figures in Table 3 were obtained by applying these operations for each reporting period and computing the 10% trimmed means (after eliminating outliers) over each dataset.We did not separately present the time for generating r in the table because it was negligible.That is, its average execution time was less than 0.01 ms.However, it was counted in the total time.As shown in the table, the reporting stage can be completed in less than 1 s.Note that the EncodeUsage operation required more time than EncodeRate, even though the complexity of EncodeUsage, i.e., KeyGen, is lower than that of EncodeRate, i.e., Encrypt, according to Reference [30].This is because EncodeUsage was performed on a relatively resource-constrained device.This proves that our design strategy of assigning the smart meter KeyGen instead of Encrypt was effective.Finally, we evaluated the data volume exchanged among the involved entities in the two stages.Table 4 presents the experimental results for the packet sizes in each stage.In the table, Packet A→B represents the average size of the packet transmitted from A to B, including the network header and payload.According to the experimental results, all packets require only moderate bandwidth.The packet from the RA to the smart meter in the registration stage, which contains msk with two (n × n) matrices B and B , consumes the most traffic, but its size is smaller than 8KB.However, we have to examine the reporting stage more carefully because it is expected to occur more frequently than registration.In particular, we should also consider the situation where the ESP receives reports from multiple smart meters.As shown in Table 4, the data volume exchanged between one smart meter, the ESP, and the RA during a reporting stage is approximately 6 KB in total.If there are N smart meters, the amount of data exchanged in a reporting stage will be 6N KB.This capacity will be sufficient to cover a reasonable number of smart meters, but it should be verified though an implementation involving multiple smart meters.We leave this issue for future research.

Discussion
In this paper, we proposed a privacy-preserving electricity billing method using FHIPE.To our knowledge, this is the first method that does not sacrifice data granularity for privacy.We implemented a prototype billing system composed of a smart meter, an ESP, and an RA.The experimental results with real measurement data show that the power consumption data of a smart meter can be reported to a service provider and accumulated for invoicing in less than 1 s and in a privacy-preserving manner.This proves the feasibility of the proposed system.
We remark that although our experiment was done with TOU, where the rates do not change frequently, the proposed method can be just as effectively applied to RTP, because the performance of our cryptographic operations-e.g., EncodeRate and Decrypt-does not depend on whether the values of r i are identical or distinct.
We finally remark that for advanced services, the proposed method may be combined with other privacy-preserving protocols.For example, consider a situation where the ESP wants to use the collected data for a real-time load shedding purpose apart from billing.In this case, the ESP requires fine-grained readings, i.e., each u i , to control power generation and distribution in real time, which is not possible with the proposed method.However, note that for this real-time control purpose, the electricity usage data from each individual smart meter are not necessary, but the aggregate data from multiple smart meters in a certain geographic region are sufficient.Therefore, we may adopt the previous research results aiming at spatially aggregating data from multiple smart meters in a cluster.For example, the method in Reference [23] aggregates spatial consumption of smart meters using a modified version of the Paillier homomorphic encryption [45].In the spatial consumption aggregation protocol proposed in Reference [23], each smart meter j performs a modified Paillier encryption E pk (u j i ) using a public key pk, where u j i is the measurement of smart meter j (0 ≤ j ≤ N − 1) in the i-th interval (0 ≤ i ≤ n − 1).Then, any smart meter can play the role of an aggregator and aggregates the encrypted data from N smart meters into ∏ N−1 j=0 E pk (u , where D sk denotes decryption using the private key sk.This protocol can be combined with ours as follows: The key pair can be set up in the registration stage of the proposed method, and aggregation may be performed in the reporting stage.However, the aggregation should be performed n times in each reporting period.It is also possible to set independent reading granularity for each purpose, e.g., 15 min for billing and 5 min for real-time control.However, to realize the combination of the proposed method and spatial aggregation protocol, many practical issues, such as optimal parameter-tuning to make the most of the limited resource of a smart meter, should be addressed through implementation and experiments.We leave these issues for future research.

Figure 2 .
Figure 2. Registration stage of our protocol.

Figure 3 .
Figure 3. Reporting stage of our protocol.

Figure 4 .
Figure 4. Component modules of proposed system.
j i ).According to the property of the Paillier cryptosystem,D sk ∏ N−1 j=0 E pk (u j i ) = ∑ N−1 j=0 u j i

Table 2 .
Breakdown of execution time of the registration stage (milliseconds).

Table 3 .
Breakdown of execution time of the reporting stage (milliseconds).

Table 4 .
Data volume exchanged among the entities in the two stages (bytes).