AMI introduces substantial benefits and opportunities to our society, but it also raises challenges concerning privacy as a side effect. For example, fine-grained smart metering data and control messages provide utility companies with the information about ongoing electricity status. However, if misused, these data significantly increase the probability of leaking customers’ privacy including personal information, daily activities, individual behaviors, etc., more frequently [4] as shown in Figure 1.

Some pioneer studies, e.g. [5] , explore means to identify major appliance usages in a building by examining the power usage data collected every 15 minutes within 24 hours. This exposes its residents’ daily activities.

To address privacy risks and concerns, most existing researches are more focused on hiding power usage data that is recorded at smart meter ends or unicasted in NAN via encryption schemes [6,7] or perturbation means [8] or extra battery [9]; but they did not take the HAN and BAN and their characteristics into account.

This paper aims to develop an efficient privacy preservation scheme for Communications in Smart Buildings (CSB) in the smart grid, which is still an unexploited area. CSB [3] are consisted of BAN and HAN where resourceconstrained wireless networks such as Zigbee [10] and Wi-Fi [11] are deployed. In CSB, not only unicast but broadcast/multicast is popularly utilized due to wireless communications’ characteristics. In our viewpoint, the major challenges to preserve privacy in CSB include:

Ÿ  Requirement of efficient privacy-preserving schemes which should be specifically designed for smart buil-

dings;

Ÿ  Safeguarding of not only unicast but broadcast/multicast for both BAN and HAN in an efficient way;

Ÿ  Preservation of not only power usage data but other messages in CSB such as power control commands, events, alarms and so on.

We propose a reliable, fault-tolerant, and efficient privacy preserving architecture for CSB in this paper. Our specific contributions are:

Privacy Leakage Modeling: To our best knowledge, this paper is the first to systematically study privacy leakages for CSB. Furthermore, from an adversary’s perspective, we practically enumerate privacy threats and illustrate corresponding examples.

Architecture for Privacy Preservation Scheme: Again, we are the first to propose a privacy preservation architecture which is specifically designed for CSB. We analyze the fundamental characteristics of smart buildings, investigate benefits from cryptographic methods and carefully design the most suitable cryptographic components to protect the messages transmitted in smart buildings.

New Group Key Scheme: Directly using the existing raw group key schemes in BAN poses a formidable challenge, namely the need of efficient and reliable group key management for CSB. 1) The nature of smart grid ranks reliability, safety and availability as the highest priorities

[12]. Therefore, group key schemes should heavily emphasize the built-in availability as well as minimize the down time during its operation; 2) Most smart devices are equipped with low-capacity devices and limited memory which tends to be restricted in their computation and storage capability. Our group key scheme’s contributions are: a) Hybrid architecture with reliability and self-heaing services to incorporate the centralized and the contributory group key scheme in order to achieve fault-tolerance. b) Efficiency is ensured via individual rekeying for members joining and batch rekeying for member leaving at the end of an interval. For even more efficiency, the key tree is organized using special constructs such the fixed and the child key trees.

Experimental Validation: Finally, we implement our scheme on emulated smart devices and key servers as well as simulate it on Network Simulator 2 (NS2) [13]. The experimental results demonstrate that our solution incurs dramatically less computational costs and communication overheads when compared to the state-of-the-art methods.

As depicted in Figure 2, a smart building communication system comprises of components as follows [3]:

Three communication modes are utilized in SGC: unicast, multicast and broadcast [15]. Interactive messages are exchanged via one or more of them. SHNs or smart meters use unicast mode to report metering data such as power usage data, status, and events to utility companies. In contrast, power companies or the smart building control center deploys multicast or broadcast technology to forward control commands to one or more HANs or even the entire BAN in the smart building. Furthermore, DR information including remote load control messages and pricing information and alarms is multicast to correspondding DR project participants.

In terms of the delay limit for message delivery, we realize that different countries and areas may have their own regulations while accomplishing the multicast/broadcast technologies used in smart buildings. Their values differ. Without lost generality, we follow the standard of State Grid Corporation of China, the time limit of which is defined as less than 15 s [15]. Other countries may set different time limits but it will not impact our solution significantly.

In CSB, different communication modes demonstrate varied hardness while protecting privacy. Privacy preserving schemes can be easily accomplished for unicast communication technologies even for resource-limited wireless network communication technologies. The reason is that currently deployed wireless networks such as Zigbee [10] or Wi-Fi [11] are utilizing pair-wise keys and encryption algorithms in design. However, it is still a challenge for multicast communication technologies in CSB due to CSB’s own characteristics and specific requirements. The SHNs in a HAN, for example, have to share their messages or statuses or events with each other to achieve some collaborative tasks: a DR project, for example, requires an apartment in the building decrease its power consumption to a defined limit at peak time. However, how the customer-side power management in the apartment complete the goal is out of the DR project’s knowledge. In this case, the SHNs in the apartment need work with each other to reduce the electricity consumption but meanwhile satisfy customers’ comfortableness. It does not conflict with the privacy protection since SHNs in the same HAN belongs to the identical owner. However, these messages cannot be captured by other devices which deployed in the same buildings but different apartment. Otherwise, the privacy leakages discussed in Section 4.2 occur.

However, designing an appropriate privacy preserving scheme for multicast/broadcast in CSB is a challenging task. It should protect aforementioned scenarios and meanwhile overcome the restrictions listed below:

1) Requirement of suitable cryptographic schemes for multicast: current wireless network e.g. Zigbee or Wi-Fi mainly utilizes the pair-wise key scheme and encryption algorithms to protect messages. It is suitable for unicast communications but not for multicast ones. Designing privacy preserving schemes specifically for multicast communications in CSBs is highly demanded.

2) Limited resources for receivers: The receivers, i.e., SHNs or smart meters, are usually equipped with lowend processors and limited amount of memory, both of which hamper the execution of heavy computing operations.

3) Constraints on communication channels: Wireless channels present low-bandwidth. Light-weight communication cost is desirable.

4) Huge volumes of data: the amount of data for smart building communications will be a significant increase in the future. Hence, the solution needs to be efficient and scalable.

5) Delay-tolerance: Data forwarded in smart building communications cannot be delayed for more than 15 s.

6) Vital demands for reliability and fault protection: The nature of smart building highly demands reliability and availability. Hence, to minimize the total outage/fault times, fault-tolerance services are essential.

To satisfy smart grids’ privacy-preserving requirement for multicast communications, a common and efficient solution is to deploy a symmetric group key shared by all multicast participants (group members), e.g. SHNs, smart meters, etc. in the same HAN (group). With the support of this shared key (group key), multicast communication data in the same HAN can be encrypted and decrypted. Outsiders, e.g. SHNs in other HANs cannot peek. Therefore, a group key management protocol that computes the symmetric group key and forwards the partial keys to all legitimate SHNs in the HAN is critical to the privacy preservation scheme for the multicast communication in smart buildings.

Rekey Strategies: When one or more SHN (group member) leaves or joins the HAN (group), the group key should be updated so that only current group members contain the group key. This procedure is called rekey. There are two kinds of rekey strategies: individual rekey and periodical batch rekey. The former rekeys the group key for every group membership update such as joining/ leaving. The later processes the joining and leaving requests in a batch at the end of each rekey interval.

In this paper, we utilize individual rekeying to process join request and periodical rekeying to process leaving requests because: 1) In smart grids, most SHNs and the smart meter which play group member roles have stationary membership. The group membership change events e.g. joining/leaving are rare; 2) We use one-way hash operation to update the group key when a SHN joins. Since one way hash function is efficient, the rekey operation cost is light; 3) Periodical rekeying introduces a vulnerability window but also leads efficiency. Considering that some SHNs show low-end processing capacity, the tradeoff between performance and security is reasonable; 4) Periodic rekeying introduces group key refresh at the end of the time interval even there are no membership changes. This promotes the security level.

Group Key Management Architecture: In view of architecture, group key management schemes can be broadly classified into two categories, namely, centralized and contributory: In a typical centralized group key management scheme e.g. Logical Key Hierarchy (LKH) [16], a trusted third party, known as the key server, is responsible to generate, to encrypt and to distribute the symmetric group key, partial keys and individual keys to all other group members. It has the advantages of efficiency of the symmetric key encryption/decryption. However, it suffers from the following drawbacks. 1) Since all group secrets are generated and stored in one place, the key server could present itself as an attractive attack target for adversaries. 2) The key server can become the single point of failure/bottleneck. In contrast, in contributory group key management schemes e.g. Tree-based Group Diffie-Hellman (TGDH) [17], every group member contributes to the group key generation. It has the advantage of fault-tolerance. However, for group membership changes, it lacks scalability in terms of computational cost. For example, TGDH has the following drawbacks. 1) Every group member performs the expensive DiffieHellman key exchange with times exponentiation operations for every group membership update where n is the group size. 2) Every sponsor should sign and forward a large number of rekeying multicast messages to update a group key. It results in expensive communication overhead and computational costs.

In this paper, we are willing to propose hybrid architecture which combines both centralized and contributory group key schemes in such a way that it takes advantage of both centralized one’s efficiency and contribute one’s reliability to protect the privacy of smart grid multicast service.

The crux of the group key management scheme in TGDH is to use a binary key tree for group key updates. Let be a binary tree in which every node is represented by where h is its height (level) and i is its index. Each node in the binary tree, has two keys, and. The node key associated with node

is and its blinded key.

Each node in the tree is either a leaf or a parent of two nodes. Each leaf represents a group member which generates, a random integer. It can be treated as the leaf node’s node key. The node key of an internal node, is derived from keys of its children, and:

The node key of the root is the group key. While a group member joins, the shallowest leftmost leaf node in the key tree is selected as the sponsor and acts as the sibling for the new group member. When a group member leaves, the sponsor is the shallowest leftmost leaf node of the sub-tree rooted as the leaving member’s sibling node. The sponsor is responsible for updating its secret random integer, and all keys on its key path. Then, the sponsor multicasts all updated blinded keys, based on which, other members update keys on their key paths and compute the new group key. Refer to [17] for details about how the sponsor is selected, how key material is prepared among all members and how group key is calculated for each participant.

In the group key scheme, security channels between two parties/members are required. Its purpose is to deliver secret messages between them. For example, when a new group member joins, the sponsor needs to establish the secure channel with the new group member. In our solution, it is fulfilled by a shared key between them: we adapt an ID-based key agreement [18] to generate the secret key.

1) Set-up Following the RSA algorithm, TC (trusted key generation center) generates and publishes but keeps secret.

2) Key generation For an authorized user A, TC assigns it randomly generated ID, and computes;

For an authorized user B, TC assigns it randomly generated ID, , and computes;

TC issues (n, g, e, ID_q, s_q) to user A and (n, g, e, ID_b, s_b) to user B via secure channel.

3) Key Agreement Step 1:

A randomly generates an integer, and, computes

B randomly generates an integer, and, computes

Step 2:

A and B exchange and via authenticated channels;

Step 3:

A and B computes formula (4) and (5) respectively:

Adversary Model: Like other researches in areas of privacy preservations [6,19,20] we follow the semi-honest adversary model in which smart devices (e.g. SHNs, smart meters, etc.) obey regulations of the smart buildings. Meanwhile they are also curious about messages they learn (or share) and have the intension to combine these information if possible. Therefore, any participating smart devices should relay packets and also intend to uncover other HANs’ privacy by studying sensitive messages received.

Security Assumption: We assume that smart devices such as smart meters, etc. are tamper-resistant. Furthermore, we also assume the availability of the TC and the key server deployed in smart buildings or utilities. Moreover, we assume that device attestations are deployed to validate SHNs, smart meters, etc.

Scope: Our scheme mainly focuses on the confidentiality service to protect privacy in multicast. In terms of unicast, the pair-wise key schemes are already implemented in wireless networks e.g. Zigbee. Efficient encryption algorithms e.g. AES are utilized in sensor networks as well. We will use them in our solution directly rather than proposing new components. The authentication and integrity services guaranteed by digital signatures and one-way hash functions are also important but beyond our paper’s scope.

Privacy threats occur when an adversary associates customers’ power usage data and buildings’ control commands with their daily activities e.g. breakfast, laundry, wakeup cycles, etc. [21] .

Privacy for residence occupancy: An appliance control command can let an adversary infer that the resident is presence or absence (also referred as absence privacy).

Example I: A remote control command is sent to “” aiming to shut down the air conditioner when the local temperature outdoor is high (e.g. >104˚F/40˚C). Eve can probably infer that residents living in “” may possible be absence and he then takes risks to break in.

Privacy for appliance ownership: The history of appliance control commands let an adversary compile a list of household appliances and surmise the lack one.

Example II: Alice had sent home the remote appliance control commands associated with heaters, dish washers or dryers but otherwise air conditioners. Eve extrapolates that it is highly possible for Alice to not own an air conditioner yet. The commercial information is valuable.

Privacy for personal activities model: The appliance control commands can let the adversary generalize the residence’s activity model.

Example III: Alice always remotely turns on his air conditioner half an hour earlier before arriving at home. Eve finds that theses control commands are sent out at 5:30 pm from every Tuesday to Thursday but, 6:30 pm every Monday. Eve can draw Alice’s life pattern in the future based on it.

In this paper, we present a privacy preserving multicast for CSB via using an efficient, reliable, and periodic group key management scheme. As depicted in Figure 3, a server in the control center of the building plays the Key Server role. It generates a group key tree, , for every HAN,.

We assume that there are HANs in the smart building. Therefore, there are group key trees, and group keys generated in. The multicasts key material associated with each group key tree to SHNs that belong to where. The SHNs, after receiving the key material, will calculate its group key. Afterward, multicast messages toward are encrypted by the group key,. SHNs inside can decrypt cipher text but other SHNs outside cannot since they do not obtain. The encryption algorithm can be AES, which is out of the scope of this paper.

In the centralized group key scheme, a server in the control center of the building plays the key server’s role since it is equipped with powerful computation capacity. Following TGDH, for each HAN, the server generates the symmetric group key, partial keys, individual keys,

key path and key tree which are forwarded to the corre sponding group members—SHNs and smart meters in a HAN,. It takes advantages of symmetric key encryption/decryption’s efficiency but the key server is the single-point failure: when it is out of control, the centralized group key scheme ceases and therefore reliability cannot be provided. In contrast, a contributory group key scheme is fault-tolerant. But it is expensive in both computation and communication. Consequently, low-capacity SHNs and smart meters and limited wireless communication channels, e.g., Zigbee, cannot afford the cost.

A naïve/straightforward method to fix this problem is to install one set of centralized scheme and one set of contributory scheme simultaneously on every smart device to guarantee both fault-tolerance and efficiency. However, deployments of two sets of schemes not only make the system more complicated but require more resources such as storages.

In this paper, we propose a hybrid protocol which combines the advantages of the centralized approach’s efficiency and the contributory scheme’s fault tolerance. The basic idea behind the hybrid architecture is that when the key server is off-line, then group key management will utilize a contributory scheme. If the key server is on-line, there will be two possibilities. If all the group members are able to access the key server (no partitioning of the group), a centralized scheme e.g. LKH is used in which the key server is responsible for calculating and delivering the intermediate keys associated with the binary key tree since the key server is deemed to have a high processing capability. On the other hand, if the group is partitioned (some of the members are not able to access the key server), then a combination of the two schemes is used—the members with access to the key server use the centralized scheme while the others use the contributory scheme. Both of them follow the TGDH key tree to update the node keys and blinded keys associated with the nodes on the binary key tree.

Figures 4(a) and (b) demonstrate the required components for implementing the centralized and the contributory key management schemes, respectively. The key tree structure follows that of TGDH or of binary tree-based LKH (TGDH is a binary tree-based LKH in terms of key tree structure). In both centralized and contributory group key scheme, the key tree structure maintenance components within the key server or the group members modify their key tree structures according to the group member joining or leaving.

Generally, the centralized scheme is the primary mechanism: the key server maintains and distributes the key tree. Every group member, e.g. SHNs and the smart meter in the same HAN, receives and stores its key path. Once the key server fails, a contributory scheme takes in charge automatically—every SHN and smart meter in the

same HAN, cooperates with each other to manage the group key and the key tree as well. When the key server restores, every meter delivers its latest key path to the gateway via secure channels. The scheme is controlled in centralized way again. Thus, self-healing is ensured. Since both centralized and contributory key management use the same key tree structure, no rekey operations are processed and no rekey messages are forwarded to implement the switch between the centralized scheme and the contributory scheme. Due to space limit, we will not address each component listed in Figures 4(a) and (b) in detail.

In this subsection, we address our key tree structure, how to arrange nodes in a key tree while members join/leave and how to compute the shared group key for key server and each group member as well.

Like [16,17,22], our scheme uses a binary key tree in which every node is associated with a node key and a blinded key. Each leaf node represents one and only one group member. The node key of a leaf node is also called individual key.

According to our observation, we find that the stationary smart devices will not leave as long as it is legal, works in a good condition and no plan to be replaced. Therefore, even they appear not online sometimes because of device out-of-control or its jammed communication channel, we still do not mark it as leaving. Furthermore, since some roaming devices e.g. customer’s PEV intends to return, its node still stays in the key tree and no leaving request should be sent out. They are treated as stationary nodes. However, other devices e.g. rented smart appliance cannot be treated as stationary nodes. Expired/ broken/compromised SHNs. are marked as leaving and will finally be deleted in rekeying process.

The layout of the key tree is demonstrated in Figure 5(a), in which the fixed key tree, contains all stationary smart devices. The rest group members are located in the subtree. Notice that is’s sibling and at the same time, the child key tree, is part of. stores the new incoming smart devices, e.g., newly installed SHNs.

In our scheme, to lessen member’s waiting time, a joining request is processed immediately. All leaving requests are handled at the end of the rekeying time interval for the sake of efficiency. This may introduce trivial vulnerability but it is affordable. The reason is that the nature of smart grids informs us that almost all smart devices are stationary and membership changes rarely happen. Therefore, the rekeying interval (e.g. 60 minutes) defined in our scheme is sufficiently secure.

Individual Rekeying for Joining Member:

New joining group members should contain its attributes: stationary or non-stationary. The former will be inserted into the fixed key tree,. The later is associated with nodes representing rented SHNs. It will be inserted into the main key tree at the group key initiation phase. After then, new member will be inserted at child key tree,. The insertion point for, or is its corresponding shallowest leftmost nodes. Meanwhile, every current group member calculates the new group key via one way hash function where is the current group key and the new one. The new member receives from the sponsor via secure channels e.g. ID-based DiffieHellman. Refer to TGDH about how the sponsor node delivers partial keys to the new member.

Batch Rekeying for Leaving Member:

When a group member is going to leave as it is malfunctioning, legacy or expelled, the group key need to be updated at the end of the rekeying interval. The child key tree, , may be moved to replace a leaving leaf node’s place if any, for sake of computation efficiency. For details, suppose that the group member M_i, is represented by the leaf which leaves the group. Four cases follow:

Case 1: If is not available, our leave protocol is the same as that of TGDH.

Case 2: If is available and is within, the key tree structure stays the same.

Cases 3 and 4: If is available and is not within, there are two possibilities, moving which is shown as Figure 5(a), or not. The leaf node’s position and computational cost decide whether should be moved. If moving cannot result in the performance gain, should stay. This scenario is called case 3. Otherwise, should be moved to take’s position and is cut off. It is called case 4.

For example, Figure 5(b) is the original key tree. Figure 5(c) shows that leaves. Since is not within and moving costs less, rooted at is moved to replace the position of node. The former node is cut off. As its left child node is removed, node is deleted.’s right node

is renamed as and promoted to its parent’s position. Figure 5(d) demonstrates that, when leaves, need not be moved since is within.

During our implementation, we utilize ID-based DiffieHellman key exchange agreement introduced in Section 2.4 to calculate the node key for intermediate nodes in the key tree. It can protect our scheme against the Manin-the-Middle attack.

We implement the adapted ID-based key agreement by C language based on Pairing-Based Cryptography (PBC) library [23] built on the GNU Multiple Precision arithmetic (GMP) library [24]: GMP library provides arbitrary precision arithmetic APIs which are invoked by PBC to support pairing-based cryptosystem. Our implementation has been executed on Virtual Machine hosted by Oracle’s VirtualBox. Here is the detailed configuretion of VM-OS: Ubuntu 11.10; Memory: 4GB; Processor: Intel Core i5-M560 2.67GHz; and HDD 7.9 GB.

The goals of our experiments are to estimate the performance of our group key scheme specifically focusing schemes. Furthermore, it can help us determine the performance gains or additional cost introduced by our scheme at different scenarios.

As the group key security has already been formally proved in TGDH, LKH, etc., we will not discuss them in this paper due to limited space.

The realization of our scheme presents an exciting conesquence to preserve privacy multicast communications in smart buildings since: 1) The hybrid architecture to accommodate the centralized and contributory schemes and individual rekey for member joining are designed for multicast in CSB. It presents not only the efficiency but also the availability; 2) The periodic rekeying scheme and the centralized scheme provide receivers (SHNs or smart meters) the lightweight operations to calculate their new group keys; 3) The hybrid architecture reduces the communication overhead by around 50% while the key server is out-line; 4) Our scheme provides a fault tolerance architecture against single point failures; 5) Most importantly, a couple of novel rekeying algorithms e.g. the child key tree, the fixed key tree, etc. are proposed, designed and implemented for rekeying schemes in practice; 6) Despite that our scheme introduces delay, it still complies with the delay limit, 15 s.