Efficient, Flexible and Secure Group Key Management Protocol for Dynamic IoT Settings

Many Internet of Things (IoT) scenarios require communication to and data acquisition from multiple devices with similar functionalities. For such scenarios, group communication in the form of multicasting and broadcasting has proven to be effective. Group Key Management (GKM) involves the handling, revocation, updation and distribution of cryptographic keys to members of various groups. Classical GKM schemes perform inefficiently in dynamic IoT environments, which are those wherein nodes frequently leave or join a network or migrate from one group to another over time. Recently, the `GroupIt' scheme has been proposed for GKM in dynamic IoT environments. However, this scheme has several limitations such as vulnerability to collusion attacks, the use of computationally expensive asymmetric encryption and threats to the backward secrecy of the system. In this paper, we present a highly efficient and secure GKM protocol for dynamic IoT settings, which maintains forward and backward secrecy at all times. Our proposed protocol uses only symmetric encryption, and is completely resistant to collusion attacks. Also, our protocol is highly flexible and can handle several new scenarios in which device or user dynamics may take place, e.g., allowing a device group to join or leave the network or creation or dissolution of a user group, which are not handled by schemes proposed in prior literature. We evaluate the performance of the proposed protocol via extensive mathematical analysis and numerical computations, and show that it outperforms the GroupIt scheme in terms of the communication and computation costs incurred by users and devices.


I. INTRODUCTION
The number of Internet connected entities was approximately 27 billion in 2019, and is expected to rapidly reach the enormous number of 75 billion by 2025 [1]. The modern Internet is a global network of intelligent devices ranging from traditionally connected devices such as desktop and laptop computers and smartphones to objects of daily use such as watches and spectacles, electronic home appliances (even window shutters), sensing and actuating devices such as patients' medical sensors and industrially deployed temperature sensors and machinery [2]. The introduction of IPv6 addresses [3] has made it possible for all these devices to connect to the Internet and has helped in automation of tasks, decreased the need for human intervention, increased accessibility and convenience in functionality and data acquisition. The ability to connect resource-constrained devices such as sensors and actuators as well as everyday objects to the Internet has led to the notion of the Internet of Things (IoT) [4].
A. Kabra, S. Kumar and G. S. Kasbekar are with the Department of Electrical Engineering, Indian Institute of Technology Bombay, Mumbai, India. Their email addresses are adhirathkabra@gmail.com, ism.sumit@gmail.com and gskasbekar@ee.iitb.ac.in, respectively.
Compared to traditional devices such as desktop computers and laptops, IoT devices have low computational and storage power. As a result, they are not able to run the protocols traditionally used to achieve secure communications in the Internet, e.g., those that use public key cryptography [5]. At the same time, confidentiality and message-integrity of data communicated by and to IoT devices is essential. It may relate to the geographical coordinates of a user, medication provided to a patient, customized use of home appliances, parameters and commands exchanged by industrial machinery or security alarms. This broad range of essential functions, without sufficient security, can potentially result in huge losses. Hence, it is crucial to design effective security mechanisms for resourceconstrained IoT devices. A review of prior research literature in which security mechanisms for the IoT are proposed is provided in Section II.
Many present-day scenarios require communication to and data acquisition from multiple devices with similar functionalities, e.g., medical sensors, Industrial Wireless Sensor Network nodes and nodes installed in smart homes. For such scenarios, group communication in the form of multicasting and broadcasting has proven to be effective [6]. Group Key Management (GKM) involves the handling, revocation, updation and distribution of cryptographic keys to members of various groups in a communication network [7]. GKM can be adopted in a centralized or distributed manner [8]. Centralized GKM schemes involve a centralized entity like a Key Distribution Center, which generates keys and performs the aforementioned functions. On the other hand, in distributed GKM schemes, nodes are clustered into several groups and cluster heads are assigned to manage keys locally [9]. However, the latter approach incurs high computational costs; as a result, most research, including this paper, is based on the centralized approach. Now, classical GKM schemes perform inefficiently in dynamic IoT environments, which are those wherein nodes frequently leave or join a network or migrate from one group to another over time [10]. In such scenarios, whenever changes occur in the network, keys need to be updated and distributed in such a way that backward and forward secrecy [7] is maintained. Apart from this, the use of asymmetric cryptography in dynamic IoT environments limits the overall scalability of the system. Therefore, a GKM scheme based on symmetric cryptography is needed that can scale well in dynamic settings.
One major goal of such a GKM scheme is to exercise access control over the network [10]. Specifically, a set of users, also called subscribers, send data to and receive data from an IoT device. For example, these users may be nursing staff appointed for a patient, who wish to obtain periodic vital sign data from medical sensors deployed on the patient's body. It is of utmost importance to provide confidentiality and integrity of arXiv:2008.06890v1 [cs.NI] 16 Aug 2020 messages, as well as avoid any unauthorized access. Sharing a group key between a device and its subscribers is an effective way to impose such access control. However, as users join, leave or migrate between groups (e.g., a nurse is allocated to or deallocated from a patient or allocated to a different patient), real-time GKM is desired to fulfill the security requirements.
In this paper, we present a centralized GKM scheme for dynamic IoT environments, which maintains forward and backward secrecy at all times. Our scheme only employs resource-constrained network friendly symmetric encryption, due to which the centralized controller can efficiently handle a large number of subscription changes, node entries and exits at any given time. Moreover, our scheme is designed in such a way that no user outside the network can collude with a registered device and deduce group secrets. In our scheme, we have also made provisions for new scenarios in which device or user dynamics may take place, e.g., allowing a device group to join or leave the network or creation or dissolution of a user group, which were not provided by schemes proposed in prior literature [10]; this makes our proposed scheme more flexible in handling dynamics. Finally, via mathematical analysis and numerical computations, we evaluate the performance of the proposed scheme and show that it outperforms the GKM scheme proposed for dynamic IoT environments in prior work [10].
The rest of the paper is organized as follows. In Section II, we review the prior research literature on security in the IoT and GKM. Section III describes our system model, problem formulation and reviews some relevant background. In Section IV, we briefly describe the GKM scheme 'GroupIt' proposed for dynamic IoT environments in [10] and identify its limitations. Our proposed GKM scheme is described in Section V. In Section VI, a mathematical analysis of the performance of the proposed scheme in terms of storage, computation and communication costs is provided. In Section VII, we provide a numerical computations based performance evaluation of the proposed scheme. Finally, we provide conclusions and directions for future research in Section VIII.

II. RELATED WORK
Security in the IoT has gained significant attention in the research community-surveys of various enabling technologies for the IoT (e.g., RFID, Zigbee, MQTT, CoAP), including security aspects, are provided in [5], [11], [12]. The IEEE standard 802.15.4 defines rules for the physical and medium access control (PHY and MAC) layers, aimed at providing low cost, low power and low data rate wireless connectivity among constrained devices [13]. The Internet Engineering Task Force (IETF) has also developed protocols for various layers to support the IoT [14]. IPv6 over Low power Wireless Personal Area Networks (6LoWPAN) [15], an IETF standard, is one of the technologies adopting 802.15.4. It acts as a gateway between the Internet and constrained devices, performing various tasks such as header compression, fragmentation and reassembly of IPv6 packets from the Internet into sizes that can be sent over constrained networks using 802.15.4. The Routing Protocol for Low Power and Lossy Networks (RPL) is another IETF standard, designed for routing over constrained networks. DTLS header compression and TLS-DTLS mapping [16] have also been proposed to increase the allowed application-layer payload. The design of secure protocols for various IoT standards is a topic of recent research [5].
Multifactor authentication has been extensively studied in the past decade and a plethora of schemes have been proposed for various IoT settings. In [17], a novel 2-factor authentication scheme for any remote user to securely connect with a given sensor node is presented. Wireless Sensor Networks (WSNs) form an integral part of the IoT. In [3], the authors propose an efficient and lightweight 3-factor authentication and key establishment scheme, based on Biohashing and the Rabin Cryptosystem, for WSNs to securely connect to the Internet. Elliptic Curve Cryptography has also found novel applications in designing keying protocols for constrained network architectures [18]- [21]. Online validation of public key certificates is another problem in the field of IoT security. In [22], the authors introduced a protocol that employs a cryptographically generated address for bootstrapping to secure the join and certificate issuance mechanisms.
Over the years, several highly efficient Group Key Establishment (GKE) schemes have been proposed. GKE refers to one-time authentication and key agreement among two or more parties in a group who wish to exchange messages. In [23], a lightweight key distribution protocol for Industrial IoT, based on the Chinese Remainder Theorem, which requires only a single message transmission, and provides backward and forward secrecy is proposed. In [24], the authors explored the use of Physical Unclonable Functions with appropriate guarantees as a tool for GKE. In [25], a context based GKE protocol, in which devices calculate a fingerprint from their surrounding context and generate a shared secret among them, was proposed. However, recent literature has shown a shift towards Group Key Management (GKM) in the IoT. Complementing GKE, GKM deals with the updation, revocation and distribution of established cryptographic keys in a group. In [7], a broad survey and comparison of several centralized, decentralized and distributed GKM protocols was provided. The authors compared various mechanisms proposed in the research literature for GKM, including LKH, OFT, ELK and MARKS. In [6], the authors proposed a novel batch based centralized approach to efficiently manage group keys in generic ad hoc networks, while limiting the computational and communication costs due to group membership changes caused by users joining and leaving. They handle such membership changes and events of explicit membership revocation at different pre-assigned times by partitioning time into fixed length intervals. Our scheme, on the other hand, allows more flexibility for users by removing the need to alter memberships at pre-assigned times. In [8], a Logical Neighbor Tree (LNT) based approach to distribute key update messages in the events of membership changes is proposed. The proposed scheme reduces the key update latency from O(n) to O(log(n)), where n is the number of group members. Unlike equally ranked group entities in our protocol, their scheme includes a group controller for each group, which is responsible for local security inside the respective groups.
In [26], the Logical Key Hierarchy (LKH) approach in which keys are arranged in a hierarchy and a Key Distribution Center maintains and updates all the keys was proposed. It makes use of symmetric key encryption to multicast key update messages to group members, which are located at the leaf nodes of a logical tree; the communication cost of this scheme is of the order of O(log(n)), where n is the number of nodes in the network. As we will see later, we have also used LKH as a basic mechanism to form groups in our model. Later, [27] presented a Topological Key Hierarchy (TKH) scheme for WSNs as an alternative to LKH. TKH generates a key tree by using the underlying sensor network topology and considering subtree-based key tree separation. A basic difference from LKH is that topologically adjacent entities share similar key material, and therefore, receive similar rekeying messages. Recently in [28], the authors proposed a logical tree based secure mobility management scheme (LT-SMM) using mobile service computing for the IoT. The model includes a group head for each group, which is computationally more capable than other nodes in the group. Although using the LKH scheme as in our proposed protocol, their main focus is on reducing excessive rekeying when a node only migrates from one group to another-coordinating the group heads through the Base Station helps in exchanging key material, and completing the migration process with a small overhead for the migrating node.
The closest to our research is the work [10], which, to the best of our knowledge, is the only paper in prior work that proposes a GKM scheme for dynamic IoT environments. In [10], a system model that consists of several groups of users, which selectively subscribe to a desired subset of device groups and collect data, was considered. The authors proposed a two-tier GKM scheme, GroupIt, to handle frequent subscription changes. They leveraged the LKH scheme and the Chinese Remainder Theorem (CRT) to reduce the communication overhead incurred due to node entry and exit events. While the CRT manages keys shared between the centralized controller and groups, LKH handles key distribution within groups. In [10], it is claimed that the GroupIt scheme achieves forward and backward secrecy, as well as a low probability of collusion attacks. However, in this paper, we propose a scheme that outperforms the GroupIt scheme in several respects; in particular, our scheme completely eliminates collusion attacks and is more efficient since, in contrast to the GroupIt scheme, it does not use asymmetric encryption. Moreover, our proposed GKM scheme is more flexible than GroupIt since the former handles new scenarios in which device or user dynamics may take place, e.g., allowing a device group to join or leave the network or creation or dissolution of a user group; GroupIt does not explicitly handle any of the above scenarios. Finally, we show via a combination of mathematical analysis and numerical computations that our proposed scheme outperforms GroupIt in terms of the computation and communication cost incurred by users as well as devices.
III. MODEL, PROBLEM FORMULATION AND BACKGROUND We describe the system model and adversarial model in Sections III-A and III-B, respectively. Then in Section III-C, we provide a brief overview of the LKH scheme, which we use as a part of our proposed scheme. There are five DGs, DG 1 , . . . , DG 5 , and n UGs, UG 1 , . . . , UGn. UG 1 subscribes only to DG 1 , UG 2 subscribes to DG 1 , DG 2 and DG 3 , and so on.

A. System Model
The system consists of a Key Distribution Center (KDC), IoT devices and subscribers (users). Henceforth, the terms "user" and "subscriber" are used interchangeably. The KDC is a trusted centralized entity that generates, distributes and updates key material for all devices and users. The KDC is assumed to have high computational and storage capability; hence, while quantifying the protocol's efficiency, we focus on the computational and storage costs incurred by the devices and users. Each IoT device collects the required data and periodically sends it to its subscribers. For instance, devices (sensors) attached to a patient's body may periodically send the patient's vital signs to their subscribers (authorized nurses).
One or more devices of similar functionality or security classification are grouped together into a "Device Group" (DG). Also, one or more users are grouped together into a "Subscriber Group" (SG). Each user (respectively, device) belongs to exactly one SG (respectively, DG). Each SG is subscribed to one or more DGs. In particular, a SG is a group of users subscribing to a specific subset of DGs. Thus, if there are P DGs, then there are 2 P − 1 possible SGs, corresponding to different non-empty subsets of the collection of the P DGs.
Each user or device in the network has to authenticate itself and have a secret key established with the KDC before becoming part of any group. Also, each user or device group has its own group key, initially provided by the KDC. Each device can exchange encrypted data with its subscribed users using a key that is known only to the KDC and the communicating parties, called the "device key" of the device. Fig. 1 illustrates the system model.
Our objective is to design a GKM scheme that enables efficient updation or revocation of the cryptographic keys assigned to different users and devices in the network when changes take place in the network such that forward and backward secrecy is maintained at all times. Recall that by forward (respectively, backward) secrecy, we mean that a leaving (respectively, joining) user is prevented from decrypting messages exchanged after (respectively, before) it leaves (respectively, joins) the group [7]. The possible scenarios in which key material needs to be updated or revoked are as follows: A user or a device joining or leaving the network, addition or removal of a DG, a user occupying an empty SG and an existing user leaving the last spot in a SG. Also, we seek to design a GKM scheme that minimizes the computational, communication and storage costs incurred to the users and devices in the network when changes take place in the network.
Similar to most prior works in GKM, we make the following assumptions. First, all network entities use the same cipher suite and keys are sufficiently large [18]. Second, the system is reactive to tampering; therefore, any node capture or compromise will be detected in practically small time, resulting in appropriate revocation and updation of device and user key material. Different approaches such as mobility based [29] and control theoretic [30] modelling have been presented in prior work to detect and revoke compromised nodes. Finally, we assume that the message integrity of all communication exchanged during the network operation is protected using standard mechanisms (e.g., message authentication codes) [5].

B. Adversarial Model
In our model, the adversary may be a node outside the network, a malicious user belonging to one of the user groups, or a corrupted device that tries to access data belonging to other devices. If the adversary is a user belonging to the network, it may try to either compromise forward or backward secrecy or access the data trasmitted by devices to which it is not subscribed. The adversary aims to breach access control and decrypt the periodic data transmitted by devices, which it is not authorized to access, either by illegitimately gaining access to key material or colluding with devices existing in the network.

C. Logical Key Hierarchy (LKH)
LKH is a centralized GKM technique designed for achieving secure and efficient rekeying and message transmissions within a group [26], while providing forward and backward secrecy. LKH provides methods to update the cryptographic keys shared within a group when a node joins or leaves the group. Moreover, it helps to multicast messages to different nodes in the group while incurring a low communication cost.
Under the LKH scheme, a KDC maintains a tree of keys [7] as shown in Fig. 2. A group arranged in an LKH tree structure has all its members occupying the leaf nodes of the tree. Each node of the tree other than the leaves and the root is associated with a key called the Key Encryption Key (KEK). Also, the root node is associated with a key called the group key. A member knows all the KEKs belonging to its ancestors in the tree and the group key. For example, node L122 in Fig. 2 knows the KEKs corresponding to N12 and N1 and the group key. Note that each member stores at most log 2 (k) KEKs, where k is the number of group members. Apart from this, every member also has a secret key shared with the KDC.
An LKH tree structure helps to reduce the communication cost incurred in sending multicast messages from the KDC to group members. In the example in Fig. 2, if a message is to be sent to the nodes L111, L112, L121 and L122, then a single multicast encrypted with the KEK corresponding to the common ancestor N1 can be sent under LKH; this is significantly more efficient than the transmission of four separate unicast messages encrypted using the different secret keys shared between the KDC and the four recipient nodes.
The KDC is responsible for updating the group secrets in the events of member entry or exit so as to maintain  backward and forward secrecy. Consider the LKH tree shown in Fig. 3(a). When a new node L22 joins the group, the KDC first establishes a secret key with it. This is followed by creation or updation of all the keys corresponding to the ancestors of the joining node L22 in the new LKH tree shown in Fig. 3(b) (i.e., the KEK corresponding to N2 and the group key) so as to maintain backward secrecy. The KDC then sends the newly created KEK of N2 and the updated group key to L22 using the secret key shared between the KDC and L22, and to other affected members who share a common ancestor with L22 using efficient multicasts using shared KEKs or secret keys. In this example, the KDC sends the new KEK of N2 and the group key to L21 using the shared secret key between the KDC and L21, and sends the updated group key to L11 and L12 using the KEK corresponding to N1.
Similarly, if an existing member leaves the group, as shown in Fig. 4, all its ancestral KEKs and the group key need to be updated to maintain forward secrecy. The KDC sends the updated KEKs and/ or the group key to the remaining members using suitable shared KEKs or secret keys. In this example, after L112 leaves, the KDC sends the updated KEK corresponding to N1 and the group key to L11 using the shared secret key between the KDC and L11, and to L121 and L122 using the KEK corresponding to N12. It also sends the updated group key to L21 and L22 using the KEK corresponding to N2.
IV. REVIEW AND LIMITATIONS OF GROUPIT SCHEME In Section IV-A, we briefly review the GroupIt scheme proposed for dynamic IoT environments in [10] and in Section IV-B, we discuss its limitations.

A. GroupIt
GroupIt is a scheme designed for GKM in a dynamic IoT environment. The system model for which GroupIt is designed is the same as the one described in Section III-A. GroupIt uses LKH and the Chinese Remainder Theorem (CRT) to limit the communication overhead incurred for key updation due to node entry and exit events. While the CRT manages keys between the KDC and groups, LKH handles key distribution within a group.
To initialize, the KDC generates secret keys for all users and devices and the LKH KEKs and group keys for all SGs and DGs, and distributes them to the respective users and devices. Each device is associated with a unique ID, and each DG is associated with a secret Traffic Encryption Key (TEK), both of which are known to each user subscribed to the device. In this way, the user can calculate the device key, which is a function of the device ID and TEK of the device group, for each device to which it is subscribed. The authors enlist four scenarios, discussed below, in which key material (group key, KEKs, TEKs) needs to be updated, and provide the corresponding steps to achieve forward and backward secrecy. For all these cases, LKH is used to update the group key and KEKs within a SG or DG.
1) New User (U i ) Joins a Group SG x : First, the KDC establishes a secret key with the new user. It also notifies all the DGs subscribed by SG x , and the users subscribed to those DGs to hash-update their TEKs. Hash update refers to the application of a cryptographic hash function [5] to the TEK, so that backward secrecy can be achieved. Then, the KEKs within SG x are updated as per the LKH join algorithm described in Section III-C. Finally, the new user is provided the required key material using the secret key established between the KDC and the new user.
2) Existing User (U i ) Leaves a Group SG x : The KDC first updates the group key of SG x . Then, for each DG that was subscribed to by the leaving user, it broadcasts to the other users, updated TEKs and methods to update the device IDs of the devices, using double encryption, i.e., two layers of encryption, first using an asymmetric key on the message and then encrypting the output with a symmetric key TEK. Finally, the new TEKs and device IDs are sent to the devices subscribed to by the leaving user.
3) New Device Joins a Group: First, the KDC establishes a secret key with the joining device. Then, it updates the group key and the KEKs of its DG. Finally, the ID of the new device is shared with the users subscribed to it.

4) Existing Device Leaves a Group:
The KDC first broadcasts over the network that the device is no longer available, and then updates the group key and KEKs for the other devices in the group.
B. Limitations of GroupIt 1) Employment of Asymmetric Encryption: When an existing user leaves a SG, the KDC broadcasts doubly encrypted messages to the other users, each containing update methods for a DG subscribed to by the leaving user. The inner layer of this encryption requires asymmetric decryption by the other users. This has a significant computational cost [31].
2) Collusion Attacks: The device keys are derived from device IDs and TEKs of the DGs. If the device ID is not updated when a user subscribed to the device leaves, and the leaving user colludes with a device having the new TEK, then they can combine their knowledge to derive the other devices' new device keys. GroupIt has a non-zero probability that these device IDs will not be updated when a user leaves.
3) Erroneous Steps of Key Updation: To achieve backward secrecy, the LKH group key of the SG must be updated when a new user joins the SG. But the scheme does not account for such a key update. Also, when an existing user leaves, the KEKs of the SG are not updated. Due to this, the new group key can be compromised by being revealed to the leaving user. Moreover, in the double encryption performed when a user leaves, the old TEK is available with the leaving user and it does not add to the forward secrecy of the system, since the user can easily decrypt the outer layer of encryption even after leaving.
4) Low Flexibility: GroupIt does not explicitly handle the cases when a new DG joins, an old DG leaves, a new user occupies an empty SG, and an existing user leaves the last occupied spot in a SG.
V. PROPOSED GKM SCHEME Our proposed GKM scheme is described in the following subsections.

A. Setup and Pre-deployment
Users (respectively, devices) in a SG (respectively, DG) are arranged in an LKH tree structure and occupy the leaf nodes of the tree (see Fig. 5). Also, the SGs themselves are part of a bigger (outer) LKH structure, which we refer to as the 'uLKH', as shown in Fig. 6; we refer to a KEK in the outer LKH structure as a 'uKEK'. When we say that a SG is assigned a set of uKEKs, it means that each user in the SG is assigned that set of uKEKs. In the example in Fig. 6, all users in SG 111 and SG 112 have uKEK 11 , uKEK 1 and the group key, uN, corresponding to the root, uNode. Note that uN can be used to securely broadcast a message to all the users in the network. The group key, uN, and the uKEKs together enable the KDC to multicast messages to multiple SGs. In the example in Fig. 6,  if a message is to be sent to SG 111 , SG 112 , SG 121 and SG 122 , then the KDC will simply encrypt it with uKEK 1 and multicast the message to the four groups.
The device key for a device j is defined as: where h(·) is a cryptographic hash function, ID j is a secret and n j is a nonce, both ID j and n j are shared between device j and the KDC, and || denotes a concatenation. Each device j encrypts messages containing its periodic data using DK j and multicasts it to all the SGs subscribed to device j. Each user subscribed to a device j knows its device key DK j .
At the beginning of the network operation, the KDC performs the following actions: • Establishes secret keys with each user and device.
• Generates and distributes the group key GK y for each device group DG y . • Generates and distributes the group key SK x for each subscriber group SG x . • Generates and distributes the KEKs for the LKH tree of each SG and DG. • Generates the device IDs and nonces for all devices, distributes them to the respective devices and computes the device keys for all devices. • Distributes the device key of each device j to all the SGs subscribed to device j. • Generates and distributes the uKEKs and the group key for the outer SG tree.

B. When a New User Joins
When a new user U i joins a non-empty user group SG x , the following actions are performed: • The KDC establishes a secret key with the new user U i . • The KDC sends a broadcast message that all devices from the DGs to which SG x subscribes and the old users from SGs subscribed to those DGs should hash update the device keys, say DK j , and that the users in SG x should hash update the group key SK x . The above updates are performed as follows: This ensures backward secrecy. • The KDC sends the updated KEKs, say KEK s, corresponding to the ancestors of U i in the new LKH tree of SG x to the members of SG x encrypted by the appropriate secret keys or shared KEKs. • The KDC sends the updated uKEKs, say uKEK s, of the outer LKH tree to the SGs having a common ancestor with SG x , encrypted by the appropriate group keys or shared uKEKs. • The KDC shares the relevant secret information (DK j , SK x , KEK s, uKEK s) with the new user U i .

C. When an Existing User Leaves
Suppose an existing user leaves its SG, say SG x , but SG x continues to be non-empty. Then a simple hash updation of secret information will not suffice, and therefore, the following procedure is adopted. The exit of the user not only affects the SG, SG x , from which the user left, but also the SGs that subscribe to the devices to which the leaving user subscribed, called the "concerned SGs". As a result, we first update the uKEKs in the outer LKH tree and then send the updated device keys using them to the concerned SGs. The following actions are performed: • The KDC sends a message to the devices subscribed to by the leaving user to update their nonces. The nonce can be simply incremented by one, i.e., n j = n j + 1. This update does not require any unicast communication between the KDC and the devices, thus helping in limiting the communication cost. The new device key is calculated in the same way as before by the devices: This helps in achieving forward secrecy. • The KDC sends the updated KEKs for the users having a common ancestor with the leaving user in the LKH tree of SG x and the updated group key, SK x , to the appropriate members of SG x , encrypted by appropriate secret keys or KEKs. • The KDC sends the updated uKEKs to the SGs having a common ancestor with SG x in the outer LKH tree, encrypted by the appropriate group keys or shared uKEKs. • For each DG subscribed to by SG x , the KDC sends a multicast containing the updated device keys to the SGs subscribed to the DG, using the appropriate updated uKEKs.

D. When a New Device Joins
The new device, say D k , is added to one of the DGs, say DG y . The KDC creates a secret identity, ID k , and a secret nonce, n k , for D k . The following actions are performed: • The KDC establishes a secret key with the device, provides it with ID k and n k , and both the KDC and the device D k derive the device key as follows: • The KDC sends a message to the existing devices in DG y to hash update their group key: GK y = h(GK y ). This helps in achieving backward secrecy. • The KDC sends the updated KEKs corresponding to the ancestors of D k in the LKH tree of DG y to the appropriate devices in DG y , encrypted by appropriate secret keys or shared KEKs. • The KDC securely multicasts the device key DK k to the SGs subscribed to DG y using the appropriate uKEKs.

E. When an Existing Device Leaves
Suppose an existing device, say D k , leaves a DG, say DG y , but DG y continues to be non-empty. Then the following actions are performed: • The KDC sends a broadcast message to all SGs indicating that device D k is no longer available. This broadcast message is sent using the group key of the outer LKH tree, i.e., the key, uN, corresponding to the root uNode. • The KDC sends the updated KEKs and the updated group key, GK y , of the LKH tree of DG y to the appropriate members of DG y , encrypted using the appropriate secret keys or shared KEKs.

F. When a New User Occupies an Empty Group
When a new user, say U i , joins an empty SG, say SG x , the following actions are taken: • The KDC establishes a secret key with the user U i .
• The KDC creates a new LKH tree for the group SG x and derives its group key SK x . • The KDC sends a broadcast message announcing that all devices to which SG x subscribes and the old users subscribed to those devices should hash update the device keys: DK j = h(DK j ). This helps in achieving backward secrecy. • The KDC modifies the outer LKH structure, uLKH, to add SG x to it; in particular, the KDC sends the updated uKEKs, say uKEK s, and the updated group key, say uN , corresponding to uNode to the SGs having a common ancestor with SG x , encrypted by the appropriate group keys or shared uKEKs. • The KDC shares the relevant secret information (DK j , SK x , uKEK , uN ) with the user U i , by encrypting it using the secret key shared between the KDC and user U i .

G. When an Existing User Leaves the Last Spot in a SG
When an existing user leaves the last spot in a SG, say SG x , the LKH tree keys of the SG need not be updated since new keys are derived if and when the SG starts re-populating. Nevertheless, we need to update the uKEKs in the outer LKH tree and then send device keys using them to the concerned SGs as in Section V-C. The following actions are performed: • The KDC sends a message to the devices subscribed to by the leaving user to update their nonces as in Section V-C: n j = n j + 1. The new device key will be DK j = h(ID j ||n j ). This helps in achieving forward secrecy. • The KDC sends the updated uKEKs to the SGs having a common ancestor with SG x , encrypted by appropriate group keys or shared uKEKs. • For each DG subscribed to by the leaving user, the KDC sends a multicast containing the updated device keys to the SGs subscribed to the DG, using the updated uKEKs.

H. When a New DG Joins
Recall that a SG is a group of users subscribing to a specific subset of DGs. So when a new DG joins, the possible number of SGs will change from 2 P − 1 to 2 P +1 − 1, where P is the number of DGs before the new DG joined, i.e., it will approximately double. Also, a given SG may be split into two unique SGs-one with users with the same subscriptions as the original SG, and the other with users who opt to additionally subscribe to the new DG.
This splitting is performed as follows: in the outer LKH tree, the two newly formed SGs become child nodes of the node corresponding to the original SG. In the example in Fig. 7, when SG 12 splits, SG 121 and SG 122 become child nodes of the node corresponding to SG 12 . Also, the group key of SG 12 becomes the uKEK for both the child nodes after splitting; this uKEK is uKEK 12 in Fig. 7. As a result, splitting does not necessitate updation of uKEKs to maintain forward or backward secrecy. However, we observe that the inner LKH trees of the newly formed SGs need to be constructed appropriately based on which users from the original SG opt to subscribe to the new DG. The KDC constructs these inner LKH trees, securely sends their KEKs and group keys to the newly formed SGs, and sends, to the newly formed SGs that subscribe to the newly joined DG, the device keys of the devices of the DG. The splitting of a SG can cost heavy communication overhead to the network; however, since in practice, a new DG would only rarely join the network, this overhead would be small. We will later show that even under this rare event, the per user computation is small under our proposed protocol (see Sections VI-B.7 and VI-C.7). The following actions are performed: • For each SG that splits into two SGs, the KDC modifies the outer LKH tree by making the new SGs the child nodes of the original SG's node as explained above. • Whenever a SG is split into two SGs, the KDC constructs the inner LKH trees of the two SGs appropriately and securely distributes the group keys and KEKs of the newly formed SGs to the members of the SGs. Fig. 7. The figure on the left (respectively, right) shows the outer LKH tree before (respectively, after) SG 12 splits into two SGs-SG 121 and SG 122 . The group key of SG 12 becomes the uKEK, uKEK 12 , for the users in the two SGs.
• The KDC arranges the devices of the new DG in a LKH tree and generates its group key and KEKs. • As in Section V-D, the KDC establishes a secret key, creates a secret identity and a nonce for each of the devices in the newly joined DG. • The KDC provides each of the devices in the newly joined DG with the respective individual (identity and nonce) and group (group key and KEKs) secrets using the established shared secret keys between the devices and the KDC. Then the KDC as well as the devices derive the device keys. • Whenever a SG is split into two SGs, the KDC securely multicasts, to the members of the newly formed SG that subscribes to the newly joined DG, the device keys of the devices of the DG, using the group key of the inner LKH tree of the SG.

I. When an Existing DG Leaves
This case is exactly opposite to the case when a new DG joins (Section V-H). In particular, recall that a SG is a group of users subscribing to a specific subset of DGs. So when an existing DG leaves, the possible number of SGs will change from 2 P − 1 to 2 P −1 − 1, where P is the number of DGs before the existing DG leaves, i.e., it will approximately halve. Also, merging of pairs of SGs may be needed. Specifically, suppose before the DG left, there were two SGs, SG X and SG Y , which subscribed to the same set of DGs, except that SG X (respectively, SG Y ) subscribed (respectively, did not subscribe) to the leaving DG. Then after the DG leaves, SG X and SG Y will be subscribed to the same set of DGs and hence need to be merged, forming a bigger SG, say SG XY . Under our proposed protocol, this merging is performed as follows. The inner LKH tree structures of SG X and SG Y are not changed; also, the root nodes (corresponding to group keys) of the two SGs become children (corresponding to KEKs) of the new root node of SG XY . Fig. 8 shows the inner LKH trees of two SGs, SG X and SG Y , before merging and Fig. 9 shows the inner LKH tree of the new SG, SG XY , formed after merging. The nodes (root nodes) corresponding to the group keys, SK X and SK Y , of the two SGs become child nodes, corresponding to the KEKs KEK X0 and KEK Y0 , respectively, of the new root node corresponding to the group key SK XY . Also, SK XY can simply be the hash of the group key of the bigger group out of SG X and SG Y , say SG Y . Additionally, similar to Section V-G, the LKH tree keys of the leaving DG need not be updated since new keys are derived if and when the DG starts re-populating. Also, the KDC sends a broadcast message to all SGs that the devices in the leaving DG are no longer available. For each instance of merging of two SGs, SG X and SG Y , into a bigger SG, SG XY , the following actions are performed: • The KDC arranges the LKH trees of the two SGs as shown in Fig. 9, and the KDC and users in the bigger SG, SG Y , calculate the new group key of the merged group SG XY as SK XY = h(SK Y ). • The KDC securely multicasts SK XY to all the users of the subscriber group SG X by encrypting it using the key KEK X0 . Also, unlike Section V-H, modification of the outer LKH tree post-merging is, in general, non-trivial and depends on which pairs of SGs are merged. The KDC constructs the new outer LKH tree obtained after merging, and securely distributes its updated uKEKs to all the SGs using appropriate uKEKs or group keys. Although this may incur significant communication cost, since the leaving of an existing DG would typically be a rare event in practice, the resulting overhead would be small. Also, the per user computational cost incurred when an existing DG leaves is small (see Sections VI-B.8 and VI-C.8).

J. Collusion
In [10], the authors discussed about a possible collusion attack, which can occur under their proposed scheme, GroupIt, wherein a leaving user colludes with an existing device. This happens because the old user is aware of the device IDs of all the subscribed devices and the existing device knows the updated TEK. They can combine their knowledge to derive the other devices' new device keys. However, in our proposed scheme, users are not aware of any device's ID. Even if a user knows the device keys of all its subscribed devices, whenever a user leaves, the device keys are updated as explained in Section V-C and Section V-G. Hence, there is no possibility of a collusion attack under our proposed scheme. Fig. 9. The figure shows the inner LKH tree of the group SG XY obtained by merging of the SGs SG X and SG Y . Note that SK XY is securely multicast to U X1 , U X2 , U X3 and U X4 by encrypting it using KEK X0 .

K. Discussion
Throughout, we have focused on designing a lightweight, flexible and secure GKM scheme. The incorporation of the outer LKH tree structure in the proposed scheme makes key distribution (especially that of device keys) across SGs highly efficient. Unlike GroupIt, which uses asymmetric encryption, the use of only symmetric encryption under our proposed scheme has also added to its efficiency. Also, we have provided increased flexibility by including the ability to handle the cases where a new DG joins, an old DG leaves, a new user occupies an empty SG, and an existing user leaves the last occupied spot in a SG in our proposed scheme; note that GroupIt does not explicitly handle any of the above events. We have also achieved better security as compared to GroupIt by maintaining forward and backward secrecy during all events of user and group dynamics, as well as completely preventing collusion attacks.

VI. PERFORMANCE ANALYSIS
In Sections VI-A, VI-B, and VI-C, we analyze the storage, communication, and computational costs, respectively, of our proposed protocol and compare them with those under the GroupIt protocol. Table I lists the notation used in this and the next section.

A. Storage
Under our proposed protocol, a user of group SG x stores at most Y x M max device keys (the total number of DGs subscribed to by the user multiplied by the maximum number of devices in a DG, since there is a key for each device in each subscribed DG), at most log(N x ) KEKs (for multicast communication within SG x ), one secret key (for message communication between the KDC and the user), one group key (for multicast messages between the KDC and the users of SG x ), and at most P uKEKs, which includes the key corresponding to the root uNode (for message communication using the outer LKH tree keys). On the other hand, a device of group DG y stores one ID and one nonce (for device key generation), at most log(M y ) KEKs (for multicast communication within DG y ), one secret key (for message communication between the KDC and the device), and one group key (for multicast communication between the KDC and devices of DG y ).
In GroupIt, a user of group SG x stores at most Y x M max device IDs, Y x TEKs, at most log(N x ) KEKs, one secret key, and one group key. On the other hand, a device of group DG y stores one ID, at most log(M y ) KEKs, one secret key, one TEK, and one group key.
We can see that in terms of storage, both our proposed protocol and GroupIt have a similar overhead for devices, and depending on the values of P and Y x , GroupIt may marginally outperform the proposed protocol with respect to the costs borne by the users.
B. Communication 1) New User Joining Group SG x : Under our proposed protocol, the KDC establishes one secret key with the user, sends one broadcast message for the updation of device keys and the group key of SG x , at most log(N x ) multicasts to update KEKs, at most P multicasts to update uKEKs and one unicast to share key material. Under GroupIt, the KDC establishes one secret key with the user, sends one broadcast message to update TEK, at most log(N x ) multicasts to update KEKs and one unicast to share key material. The communication cost under our proposed protocol is higher than that under GroupIt; however, this is because of the provision of backward secrecy under our proposed protocol, but not under GroupIt (see Section IV-B.3).
2) Existing User Leaving Group SG x : Under our proposed protocol, the KDC sends one broadcast message to the devices subscribed to by the leaving user for the updation of device keys, at most log(N x ) multicasts to update KEKs and the group key, at most P multicasts to update uKEKs and Y x P multicasts for the updation of device keys with the remaining users. Under GroupIt, the KDC sends at most log(N x ) multicasts to update KEKs and the group key, at most Y x M max multicasts and Y x broadcasts for devices subscribed to by the leaving user and users subscribed to those devices to update their TEKs, respectively, and at most Y x log(M max ) multicasts to update device IDs. Hence, the proposed protocol is highly efficient in terms of communication overhead when an existing user leaves. This efficiency further improves if the number of devices within a DG increases or if the SG is subscribed to a large number of DGs. Through our solution, we have also eliminated the possibility of collusion, which exists under the GroupIt protocol (see Section IV-B2).
3) New Device Joining Group DG y : Under our proposed protocol, the KDC establishes one secret key with the device, sends one unicast containing the ID and nonce, one multicast for other members of the DG to update the group key, at most log(M y ) multicasts to update KEKs and at most L y multicasts for delivering the device's key to its subscribed users. Under GroupIt, the KDC establishes one secret key with the device, sends one multicast for other members of the DG to update the group key, at most log(M y ) multicasts to update KEKs, one broadcast containing the device's ID for the subscribed users and one unicast to share key material with the new device. We can see that if L y > 1, then depending on the positions of the SGs subscribed to the DG of the new device in the outer LKH tree, GroupIt may have a lower communication cost in this case as compared to our proposed scheme. 4) Existing Device Leaving Group DG y : Both under our proposed protocol and GroupIt, the KDC sends one broadcast notifying about the exit of the device, and at most log(M y ) multicasts to update the KEKs and group key of the devices in DG y . 5) New User Occupying an Empty SG: Under our proposed protocol, the KDC establishes one secret key with the user, sends one broadcast message for the updation of device keys with the users who have common subscriptions with the new user, at most P multicasts to update uKEKs and one unicast to share key material with the new user. GroupIt does not explicitly handle this scenario.
6) Existing User Leaves the Last Spot in Group SG x : Under our proposed protocol, the KDC sends one broadcast message to the devices subscribed to by the leaving user for the updation of device keys, at most P multicasts to update uKEKs and Y x P multicasts for the updation of device keys with the remaining users. Again, GroupIt does not explicitly handle this scenario. 7) New Device Group DG y Joins: We saw earlier that depending on which users subscribe to DG y , the communication cost for KEK updates may vary. In the worst case scenario, for a subscriber group SG x , of which every alternate member, going from left to right in its inner LKH tree, opts for this subscription, the KDC needs to send N x unicasts encrypted with the respective shared secret keys, one to each member of the two groups formed after SG x splits. The unicasts contain KEKs and group keys for the newly formed SG that does not subscribe to DG y , and they contain KEKs, group keys and the new devices' keys for the newly formed SG that subscribes to DG y . Additionally, under our proposed protocol, the KDC performs M y key establishments, one with each of the devices of the new DG, and sends M y corresponding unicasts containing IDs, nonces, group key and KEKs. GroupIt does not explicitly handle this scenario.
8) An Existing DG Leaves: Under our proposed protocol, the KDC sends one broadcast notifying about the exit of the DG. For each instance of merging of two SGs, the KDC sends one multicast to the users of the bigger SG to hash their group key, and sends one multicast to the users of the smaller SG containing the new group key. We also observe that the number of uKEK updates required depends on the positions of different SGs in the outer LKH tree, and in the worst case scenario, the KDC sends one multicast to the members of each SG after merging, containing the updated uKEKs encrypted by the respective group keys. As before, GroupIt does not handle this scenario. 9) Summary: We observe that when a new user joins, our proposed protocol requires more multicasts than GroupIt to update uKEKs, which helps in achieving backward secrecy under our proposed protocol, which is not provided under GroupIt. However, GroupIt is significantly outperformed by our scheme when an existing user leaves, owing to the use of symmetric encryptions under our proposed protocol, unlike under GroupIt, which uses asymmetric encryption. In case of a device joining or leaving, both schemes have similar communication overhead.

C. Computation
In this section, we analyze the computational costs per user and per device.
1) New User Joining Group SG x : Under our proposed protocol, a device needs to perform one hash to update its device key. Each existing user performs one hash to update the group key, at most Y x M max hashes to update device keys and two symmetric decryptions to update KEKs and uKEKs, whereas the new user performs one symmetric decryption to get the key material. Under GroupIt, each device needs to perform two hashes to update its device key. Each existing user performs O(log(N x )) symmetric decryptions to update KEKs, whereas the new user performs one symmetric decryption to get the key material. Hence, our proposed protocol outperforms GroupIt in terms of the computational cost for both devices and users.
2) Existing User Leaving Group SG x : Under our proposed protocol, a device needs to perform one hash to derive the new device key. Each remaining user performs two symmetric decryptions to update KEKs and uKEKs, and Y x symmetric decryptions to get the updated device keys. Under GroupIt, a device needs to perform two symmetric decryptions and two hashes to derive the device keys. Each remaining user performs two symmetric and one asymmetric decryptions to gain KEKs and update information, and at most Y x M max hashes to derive the new device keys. It is evident that our proposed protocol significantly improves upon GroupIt in terms of the overhead for devices, and also eliminates the need for asymmetric decryption, which is computationally expensive, for users.
3) New Device Joining: Under both our proposed protocol and GroupIt, the new device performs one symmetric decryption and one hash to derive its device key, whereas each existing device performs one hash to update the group key and one symmetric decryption to get the updated KEKs. Each subscribed user under our protocol performs one symmetric decryption to get the new device's device key, while it needs to perform an additional hash computation under GroupIt. 4) Existing Device Leaving: Under both our proposed protocol and GroupIt, each remaining device needs to perform one symmetric decryption to get the updated KEKs and group key, and users need not perform any computation.

5) New User
Occupying an Empty User Group SG x : Under our proposed protocol, each device needs to perform one hash to update the device key. Each user having common subscriptions with the new user performs Y x M max hashes to update device keys and each user in a SG having a common ancestor with SG x performs one symmetric decryption to update uKEKs, whereas the new user performs one symmetric decryption to get the key material. GroupIt does not explicitly handle this scenario.
6) Existing User Leaving the Last Spot in Group SG x : Under our proposed protocol, each device needs to perform one hash to derive the new device key. Each user in an SG having a common ancestor with SG x performs one symmetric decryption to update uKEKs, and Y x symmetric decryptions to get the updated device keys. Again, GroupIt does not explicitly handle this scenario. 7) New DG Joining: Under our proposed protocol, each user that occupies a new leaf node in an inner LKH tree after splitting of an SG performs one symmetric decryption to get the updated KEKs, group keys and new devices' keys (if subscribed). Each device in the new DG needs to perform one symmetric decryption and one hash to get the key material and derive its device key. GroupIt does not handle this scenario.
8) An Existing DG Leaving: Under our proposed protocol, for every instance of merging of two SGs, each of the users in the bigger SG performs one hash, while each of the users in the smaller SG performs one symmetric decryption to get the new group key. A user needs to perform at most one symmetric decryption to get the updated uKEKs. As before, GroupIt does not handle this scenario. 9) Summary: Evidently, our proposed scheme outperforms GroupIt in every user join or leave scenario. When a new user joins, our scheme requires only two symmetric decryptions per user, in contrast to GroupIt, for which this number of decryptions scales with N x . When a user leaves, under our proposed protocol, devices need not perform any decryptions, whereas they perform two decryptions each under GroupIt. Users also gain a significant advantage under our proposed protocol since asymmetric decryption is not required. Also, in case of a new device joining, our proposed protocol marginally outperforms GroupIt in terms of the computation costs borne by users.

VII. NUMERICAL RESULTS
In this section, via numerical computations, we compare the performance of our protocol with that of GroupIt for the events of user joining and leaving a group SG x , in terms of the communication cost (Section VII-A) and computation cost (Section VII-B). Suppose there are P = 10 DGs and Q = 2 P − 1 = 1023 SGs. Also, suppose each DG contains M devices, each SG contains N users, each SG is subscribed to Y DGs and L SGs are subscribed to each DG. Note that since Q = 2 P − 1, the number of SGs subscribed to each DG will be 2 P −1 ; therefore, L = 512.
In [32], the performances of Advanced Encryption Standard (AES), the SHA-256 cryptographic hash function, and Elliptical Curve Cryptography (ECC) in commercial and research sensor nodes were compared. This study shows that ECC is much more computationally intensive as compared to AES, which is, in turn, more computionally intensive than SHA-256. As in [10], for concreteness, we assume that hashing (Hash) using SHA-256 takes T 0 = 460 ns, encryption (Enc) or decryption (Dec) using AES-256 of block size 64 takes T 1 = 800 ns = 1.74T 0 , and asymmetric decryption (AsyDec) using ECC-224 takes T 2 = 114000 ns = 247.83T 0 . Note that these absolute values are for a particular processor; however, the relative trends that we observe in the following numerical results hold for other processors as well.

A. Communication Cost
We now calculate the number of messages exchanged when a user leaves group SG x , as a function of the aforementioned variables. The following equations are derived from Section VI-B.2.
First, we fix N = 100 and M = 20, and vary the number of DGs subscribed to by the leaving user (Y ). Under our proposed scheme, the number of messages exchanged is: Under GroupIt, the number of messages exchanged is: The communication costs for both the protocols are depicted in Fig. 10. Evidently, our scheme outperforms GroupIt as the number of messages required is low and does not depend on the value of Y . However, for GroupIt, it increases linearly in Y .
Next, we fix Y = 3 and M = 20 and vary N . The number of messages exchanged under our proposed scheme is: Again, as shown in Fig. 11, our proposed protocol has lower communication cost than GroupIt.
Next, we fix Y = 3 and N = 100 and vary the number of devices in each DG (M ). Under our proposed protocol, the number of messages exchanged is: On the other hand, under GroupIt, the number of messages exchanged is: 3 Broadcasts + (7 + 3 log(M ) ) Multicasts + 3M Unicasts.

B. Computation Cost
We now study the computational costs borne by users and devices in the network under the proposed protocol and GroupIt when a new user joins and when an existing user leaves. We fix Y = 3 in the rest of this section. The following computational costs are derived from Sections VI-C.1 and VI-C.2.
First, when a new user joins SG x , the total computational load for all devices under the proposed protocol is: For GroupIt, the load is:  Both the above costs are plotted versus M in Fig. 13. Thus, when a new user joins SG x , the computational load for devices under our proposed protocol is half that under GroupIt. Now, when a new user joins SG x , the total computational load for all users under our proposed protocol is:   Fig. 15 shows that our proposed protocol significantly outperforms GroupIt in terms of the total computational load for all devices in the case when a user leaves SG x . This is due to the introduction of 'nonces' as a part of the device key calculation in our proposed protocol, which eliminates the requirement to perform any decryption operation during device key updates. Finally, we consider the computational load incurred by users when an existing user leaves SG x . Under our proposed protocol, the total computational cost incurred by all the users is:  y-axis is on a log scale). The plot shows that our proposed protocol outperforms GroupIt by several orders of magnitude. This gain is achieved due to the use of symmetric encryptions under our proposed protocol in place of asymmetric double encryption, as well as due to the introduction of the outer LKH tree structure in our protocol.
VIII. CONCLUSIONS AND FUTURE WORK We presented a highly efficient and secure GKM protocol for dynamic IoT settings, which maintains forward and backward secrecy at all times. Our proposed protocol uses only symmetric encryption, and is completely resistant to collusion attacks. Also, our protocol is highly flexible and can handle several new scenarios in which device or user dynamics may take place, e.g., allowing a device group to join or leave the network or creation or dissolution of a user group, which are not handled by the GroupIt scheme. We evaluated the performance of the proposed protocol via extensive mathematical analysis and numerical computations, and showed that it outperforms the GroupIt scheme in terms of the communication and computation costs incurred by users and devices. In this paper, we used the LKH scheme for GKM within SGs and DGs as well as by constructing an outer LKH tree structure, of which all the SGs are a part. One interesting direction for future work is to improve the performance of our proposed protcool by replacing LKH with other GKM schemes proposed in prior work such as OFT, ELK, MARKS etc.