Maissa Dammak
email: maissa.dammak@u-bourgogne.fr

Sidi Mohammed Senouci

Mohamed Ayoub Messous

Mohamed Houcine Elhdhili
email: mohamedhoucine.elhdhili@ensi-uma.tn

Christophe Gransart

Decentralized Lightweight Group Key Management for Dynamic Access Control in IoT Environments

Keywords: IoT, Group Key Management, Access Control, Scalability, Dynamic environment, Security, Group communication. I

Rapid growth of Internet of Things (IoT) devices dealing with sensitive data has led to the emergence of new access control technologies in order to maintain this data safe from unauthorized use. In particular, a dynamic IoT environment, characterized by a high signaling overhead caused by subscribers' mobility, presents a significant concern to ensure secure data distribution to legitimate subscribers. Hence, for such dynamic environments, group key management (GKM) represents the fundamental mechanism for managing the dissemination of keys for access control and secure data distribution. However, existing access control schemes based on GKM and dedicated to IoT are mainly based on centralized models, which fail to address the scalability challenge introduced by the massive scale of IoT devices and the increased number of subscribers. Besides, none of the existing GKM schemes supports the independence of the members in the same group. They focus only on dependent symmetric group keys per subgroup communication, which is inefficient for subscribers with a highly dynamic behavior. To deal with these challenges, we introduce a novel Decentralized Lightweight Group Key Management architecture for Access Control in the IoT environment (DLGKM-AC). Based on a hierarchical architecture, composed of one Key Distribution Center (KDC) and several Sub Key Distribution Centers (SKDCs), the proposed scheme enhances the management of subscribers' groups and alleviate the rekeying overhead on the KDC. Moreover, a new master token management protocol for managing keys dissemination across a group of subscribers is introduced. This protocol reduces storage, computation, and communication overheads during join/leave events. The proposed approach accommodates a scalable IoT architecture, which mitigates the single point of failure by reducing the load caused by rekeying at the core network. DLGKM-AC guarantees secure group communication by preventing collusion attacks and ensuring backward/forward secrecy. Simulation results and analysis of the proposed scheme show considerable resource gain in terms of storage, computation, and communication overheads.

multitude of digital devices to the Internet [START_REF] Zanella | Internet of Things for Smart Cities[END_REF]. Recently, IoT devices are progressively becoming a large part of people's daily lives. They are widely used in various kinds of applications, such as environmental sensing and industrial monitoring (e.g., smart city, smart hotel, smart office, industry 4.0) [START_REF] Zanella | Internet of Things for Smart Cities[END_REF]. A generic IoT network architecture, as shown in Fig. 1, is composed of a set of physical objects (i.e., smart things) that are interconnected to exchange and collect data over the Internet.

[2] has predicted that, by 2025, more than 41.6 billion connected IoT devices will be used worldwide. These smart things form a diverse and heterogeneous network of interconnected physical objects with a wide range of functionalities and requirements; one essential feature being data collection. The vast majority of IoT devices have minimal resources, in terms of computation, communication, and storage, preventing them from efficiently performing cryptographic operations, thus rising more security challenges. Indeed, large scale IoT deployments still face serious security issues that still need to be addressed, such as authentication, privacy preservation, and data integrity [START_REF] Dammak | Token-Based Lightweight Authentication to Secure IoT Networks[END_REF] [START_REF] Panagiotis | Securing the Internet of Things: Challenges, threats, and solutions[END_REF].

In order to safeguard IoT data from tampering and unauthorized access, an appropriate scheme for access control is more crucial than ever. To ensure this, GKM is one promising approach, which would be used to provide access control to data streams for legitimate users only [START_REF] Panagiotis | Securing the Internet of Things: Challenges, threats, and solutions[END_REF]. In other words, it consists of creating a group key that will be shared between a device's group and its current subscribers, such that the device can encrypt its data, and only the subscribers can decrypt it. This mechanism is suitable for IoT environments as it does not require a trusted third entity. This can be achieved through a publish-subscribe messaging model, such as MQTT [START_REF] Banks | MQTT version 3.1. 1[END_REF].

Given the dynamic nature of IoT environments, where member's group can intermittently join and leave the system (e.g., reservation IoT systems), safeguarding IoT data from unauthorized access represents a primordial security issue. Therefore, enforcing access control is reduced to solving the GKM problem. Moreover, in order to guarantee backward and forward secrecy, the shared keys need to be changed whenever a new member joins or an existing one leaves its group [START_REF] Almajed | Simple and Effective Secure Group Communications in Dynamic Wireless Sensor Networks[END_REF]. To efficiently reduce the overhead keys management, resulting mainly from rekeying, GKM is extensively studied in the literature [START_REF] Cheikhrouhou | Secure Group Communication in Wireless Sensor Networks: A survey[END_REF]. Most of the existing GKM schemes are not suitable for IoT applications. Indeed, existing GKM for IoT applications are designed to manage communication within a single group, and the GKM schemes introduced for access control in the IoT environment are mostly based on a centralized access management architecture. Consequently, they are not suitable for a scalable and dynamic IoT environment comprising multiple groups. In fact, many users can subscribe to numerous services offered by different IoT devices and change their interest frequently over time. Thus, maintaining an efficient GKM in a dynamic IoT environment remains a challenging issue due to the rekeying process that affects all members in the same group for joining/leaving events. Therefore, all members should update their shared group access keys. Hence, an efficient group key mechanism should be introduced to reduce the rekeying dependence of members in the same group, and thus reducing overhead.

To solve the rekeying dependence, minimize resulting overhead and achieve scalable access management for dynamic IoT environment, this work introduces a new Decentralized Lightweight Group Key Management Architecture for Access Control named DLGKM-AC. We consider in our use-case, in the context of the European project PARFAIT [28], an extensive reservation system for franchise hotels. In this scenario, key cards and smartphones might be interchangeably used to give access permissions for guests in different rooms. They can also be used to control the usage of various facilities according to room classes' and purchased services. When a guest checks out, and the room becomes vacant, the devices should stop sending the room's information and receiving information from other devices.

The main idea of DLGKM-AC is to create an efficient and flexible mechanism to secure distribution of contents to eligible subscribers. A hierarchical scheme comprising a central Key Distribution Center (KDC) and several Sub Key Distribution Centers (SKDCs) to manage groups of subscribers and to mitigate the single point of failure issue is introduced. Key management tasks in DLGKM-AC are offloaded to several SKDCs, which allow enhancing the system's performances in terms of computation and communication by reducing the overhead caused by membership changes (join/leave). The KDC manages device groups, while each SKDC manages user groups, which provides scalability for our DLGKM-AC. Furthermore, DLGKM-AC introduces a new key management mechanism that allows reducing the rekeying dependence of users in the same group. DLGKM-AC is a scalable and flexible access management protocol that is based on the GKM mechanism.

It improves the computation capability, the storage capacity, and the communication overhead. The main contributions and novelties of this paper are summarized as follows: -Presenting a new lightweight decentralized keys distribution architecture to ensure forwarding valuable and sensitive information to legitimate users in a scalable and secure manner, -Designing a rekeying mechanism suitable for multiple groups of IoT devices and various users' groups whenever memberships change, which ensures a flexible access management system, -Presenting a master token management algorithm that creates and updates a master token and multiple slave tokens for handling user groups, which achieves the independence of user during the rekeying process, -Ensuring security requirements, backward and forward secrecy even with changes in users and devices membership, and resisting to the collusion attack, -Minimizing computational and storage overheads for users and IoT devices, and also communication overhead for the overall system, which is proved through extensive analytical study and simulation work.

The remainder of this paper is structured as follows: First, related work is described in Section II. Then, we discuss the necessary background related to our scheme in Section III before presenting the overall system architecture, attacker model and different system requirements in Section IV. The proposed DLGKM-AC for IoT is introduced in Section V. Security and performance analysis in terms of storage, communication and computation overheads are summarized in Section VI. Finally, conclusions and future works are given in Section VII.

II. RELATED WORK The dynamic nature of group communications makes safeguarding data from unauthorized access a significant challenge. The larger problem of access control is reduced to GKM, where a group key is shared by the group members to define the access permissions. Table I summarizes and classifies existing GKM solutions based on different attributes and criteria as follow: (i) Environment of its application, such as wired Internet [START_REF] Almajed | Simple and Effective Secure Group Communications in Dynamic Wireless Sensor Networks[END_REF], wireless sensor networks (WSN) [START_REF] Porambage | Group key establishment for enabling secure multicast communication in wireless sensor networks deployed for IoT applications[END_REF][9] [START_REF] Park | Key management for multiple multicast groups in wireless networks[END_REF], ad hoc networks [START_REF] Mehdizadeh | Lightweight decentralized multicast-unicast key management method in wireless ipv6 networks[END_REF], wireless body area networks (WBAN) [START_REF] Tan | A Secure and Efficient Group Key Management Protocol with Cooperative Sensor Association in WBANs[END_REF] and IoT environment [START_REF] Kung | GroupIt: Lightweight Group Key Management for Dynamic IoT Environments[END_REF] [START_REF] Abdmeziem | A decentralized batchbased group key management protocol for mobile internet of things (dbgk)[END_REF]. (ii) Network model that could be centralized, decentralized or distributed. (iii)the used Cryptography types, and essential security services (iv) backward secrecy and (v) forward secrecy, where shared keys need to be updated whenever a new member joins, or an existing one leaves its group. (vi) Key independence to ensure the independence of keys from each other. (vii) Vulnerability to collusion attack (collaboration of adversaries to compromise a communication) for which rekeying is important to maintain security. However, this process may cause a lot of key management overhead and leads to (viii) Single point of failure, especially in a (ix) Scalable environment that supports (x) Multiple group services and composed of (xi) Dynamic publishers and dynamic subscribers. Hence, ensuring (xii) Subscribers' independence makes subscribers of one group independent from the entire group in the rekeying process of the group key after a join/leave event in the group. Authors in [START_REF] Cheikhrouhou | Secure Group Communication in Wireless Sensor Networks: A survey[END_REF] surveyed numerous key distribution schemes over wireless networks and classified them into centralized, decentralized, and distributed schemes. Centralized schemes use only one server known as the key distribution server (KDC) for creating and distributing encryption keys. Distributed schemes do not have a specific KDC; they rather generate group key either in a collaborative manner between the group members or by one member. Moreover, each member must keep track of the other members to make robust communication. Besides, membership change events (join/leave) cause a high processing and communication overheads [START_REF] Karuturi | Foundations of Group Key Management-Framework, Security Model and a Generic Construction[END_REF], which may lead to a congestion problem in a dynamic IoT environment. In contrast, decentralized schemes divide the system into several subgroups, thus, reducing the load on the KDC and offering a solution to scalability issues. Furthermore, a subgroup manager is responsible for keeping track of the group's members, which may reduce computation and storage overhead on members.

The distribution of encryption keys in the different mentioned GKM architectures is further ensured by using two main cryptographic types (symmetric and asymmetric). Two fundamental and efficient GKM schemes were proposed: The Logical Key Hierarchy (LKH) [START_REF] Harney | Logical key hierarchy protocol[END_REF] and the One-way Function Tree (OFT) [START_REF] Balenson | Key management for large dynamic groups: One-way function trees and amortized initialization[END_REF] based on symmetric keys (traffic key and encryption key) to distribute the updated encryption keys. In contrast to LKH, all the OFT implementations suffer from collusion attacks and increase devices' computational overhead for obtaining group keys. Hence, OFT is far from ideal in an IoT environment, where the communicating devices may have limited computational power.

Additionally, [START_REF] Ding | An Extended Framework of Privacy-Preserving Computation with Flexible Access Control[END_REF] [21] schemes provided fine-grained access control Attribute-Based Encryption (ABE) to manage keys' update. However, ABE is a cumbersome mechanism that relies on asymmetric cryptography, which is unsuitable for running on resource-constrained IoT devices [START_REF] Wang | Performance Evaluation of Attribute-Based Encryption: Toward Data Privacy in the IoT[END_REF]. Besides, asymmetric encryption mechanisms are also used in key management schemes [START_REF] Sciancalepore | Key management protocol with implicit certificates for iot systems[END_REF] [START_REF] Tseng | FGAC-NDN: Fine-Grained Access Control for Named Data Networks[END_REF]. Specifically, Porambage et al. [START_REF] Porambage | Group key establishment for enabling secure multicast communication in wireless sensor networks deployed for IoT applications[END_REF] proposed a group key establishment protocol for multicast communication by using the Elliptic Curve Cryptographic (ECC) operations. Even though, the latter are known to be suitable for resource-constrained devices; their protocol does not efficiently manage the rekeying process. Furthermore, all previous mentioned schemes are designed for single multicast groups, but users may subscribe to multiple services. To ensure many multicast groups, Park et al. [START_REF] Park | Key management for multiple multicast groups in wireless networks[END_REF] accommodate various services' groups. Their scheme addressed rekeying in the wireless mobile environment, which is based on a centralized architecture and a LKH mechanism to manage multiple communications. Likewise, Mapoka et al. [START_REF] Mapoka | A New Multiple Service Key Management Scheme for Secure Wireless Mobile Multicast[END_REF] proposed using a distribution list of the session key and key update slot for each subgroup. This list is centrally managed by a node called the area key distributor. The proposed protocol alleviates the 1affect-n phenomenon and transmission overhead of the core network, but it does not ensure the forward secrecy. Hence, Zhong et al. [START_REF] Zhong | Multiple multicast group key management for the Internet of People[END_REF] proposed another protocol called area based multiple GKM that securely provides services when users migrate to different wireless networks, which ensures forward secrecy. Nonetheless, its high overhead, due to revocation events, makes it unsuitable for dynamic IoT environments.

To address the rekeying issue in the IoT environment, Tsai et al. [START_REF] Tsai | Key management in internet of things via kronecker product[END_REF] proposed a lightweight symmetric key establishment based on the Kronecker product. However, their protocol does not consider the key update when users or devices join or leave the system, which lacks forward and backward secrecy. Furthermore, Abdmeziem et al. [START_REF] Abdmeziem | A decentralized batchbased group key management protocol for mobile internet of things (dbgk)[END_REF] proposed a decentralized batch-based group key that includes several subgroups managed by key servers. This scheme considered long term and short-term keys per group, which are common to all nodes. Nevertheless, [START_REF] Abdmeziem | A decentralized batchbased group key management protocol for mobile internet of things (dbgk)[END_REF] does not ensure communication between multiple groups and it requires large storage and computation resources. Their work was enhanced to decrease the communication overhead by adopting a Distributed Batchbased Group Key [START_REF] Abdmeziem | Fault-Tolerant and Scalable Key Management Protocol for IoT-Based Collaborative Groups[END_REF]. It is based on polynomial cryptography to set up the key for collaborative groups in the IoT environment. However, these schemes are limited for managing communications in one group and do not consider communications between different groups and services. Kung et al. [START_REF] Kung | GroupIt: Lightweight Group Key Management for Dynamic IoT Environments[END_REF] took advantage of the Chinese Remainder Theorem (CRT) based construction proposed by Park et al. [START_REF] Park | Key management for multiple multicast groups in wireless networks[END_REF] to accommodate multiple device groups. They established a twotier centralized system KDC, where each group (devices or users) runs LKH to handle updates of keys efficiently. However, communication within a user group is based on symmetric group key, which leads to the dependence between all its members. Therefore, after each event (triggered by a join/leave user operation), the rekeying process induces all the members in the entire group to update their group key, and thus, increases the computation overhead.

In summary, and as mentioned in Table I, existing GKM solutions do not support the independence of members in the III. PRELIMINARIES In this section, we briefly present the background and the main mechanisms used in our approach. We first describe the LKH scheme used for efficient key management of different device groups (DGs). Then, we present the Master Key Encryption (MKE) based Generalized Chinese Remainder Theorem (GCRT) that is used for managing multiple user groups (UGs) and various users.

A. Logical key Hierarchy

LKH uses a tree structure to manage the distribution of keys. This method reduces communication costs by multicasting multiple key-encryption keys O(logn) for n devices per group [START_REF] Harney | Logical key hierarchy protocol[END_REF]. LKH structure is composed of devices located at the leaf nodes of the tree and a central control center called KDC, which maintains the keys' virtual tree. Each leaf node shares a secret key with the KDC. The root of the tree holds the group Key (GK), and the internal nodes hold Key Encryption Keys (KEK). KEKs are known by each device in the leaf nodes within the same subtree rooted to a specific internal node. Furthermore, KEKs compose a Path key (PKt), which is used later to update group keys efficiently. In a complete tree with n devices, each device stores log(2n+1) keys [START_REF] Harney | Logical key hierarchy protocol[END_REF]. To manage the group communication within IoT devices groups, we use the LKH scheme. Since, multiple users may subscribe to the same IoT device group, it would be more efficient if all these devices and all their subscribed users share a group key for encryption. Traffic Encryption Key (TEK) is a traffic key used to encrypt data published by a device group to its subscribers. This traffic key should be efficiently updated when a new user joins, or an old one leaves to ensure forward and backward secrecy. To do so, we explain the key management scheme used to manage communication with users in the next subsection.

B. Master Key Encryption (MKE)

Users subscribe to many DGs in the system to get data. For this purpose, each user gets all TEKs of DGs to which it is subscribed. Otherwise, the users may subscribe to the same DGs, which would lead to an increase in the overhead when an old user unsubscribes, or a new one subscribes. Thus, managing group communication with users is essential to reduce the cost of updating TEK after each join/leave event.

In this context, we define the concept of master key encryption (MKE), which is a key management scheme based on GCRT. MKE permits multiple decryption keys to decrypt the same message encrypted by an encryption key [START_REF] Park | Key management for multiple multicast groups in wireless networks[END_REF]. The main idea of the master key encryption scheme is to generate one master key and several slave keys, where the master key encrypts a message that can be decrypted by all legitimate salve keys. The MKE scheme can alleviate the rekeying cost resulting from the symmetric cryptography. Hence, Park et al. [START_REF] Park | Key management for multiple multicast groups in wireless networks[END_REF] have proposed a general MKE algorithm to lessen the rekeying cost of the group key using a master key.

Theorem 1: Let {p1, p2,… , pN, q1, q2,…,qN} a set of safe prime numbers. If all public keys satisfy the following condition, 𝑒 ! ≡ 𝑒 " ≡ ⋯ ≡ 𝑒 # 𝑚𝑜𝑑(4), Then, there exists a unique master key, 𝑒 $ modulo 4𝑥 ! 𝑦 ! 𝑥 " 𝑦 " … 𝑥 # 𝑦 # , where 𝑥 % = (𝑝 % -1)/2 and 𝑦 % = (𝑞 % -1)/2, 1 ≤ i ≤ N.

Theorem Proof: consider there are N public/private slave key pairs (𝑒 % , 𝑑 % ), 𝑖 ≤ 𝑁 with (𝑝 % , 𝑞 % ) being the ith safe prime number pair, and one master key pair(𝑒 $ , 𝑑 $ ). For simplicity, we now consider the modulus of the prime pairs ∅(𝑝 % 𝑞 % ) = (𝑝 % -1)(𝑞 % -1) are mutually prime to each other. For a plaintext P and a ciphertext C, the master key should satisfy:

𝑃 & ! ≡ 𝑃 & " 𝑚𝑜𝑑 (𝑝 % 𝑞 % ) (1) 𝐶 ' ! ≡ 𝐶 ' " 𝑚𝑜𝑑 (𝑝 % 𝑞 % ), 1 ≤ 𝑖 ≤ 𝑁
(2) According to Euler's theorem, the necessary condition for the equation above is:

𝑒 $ ≡ 𝑒 % 𝑚𝑜𝑑 <∅(𝑝 % 𝑞 % )= , 𝑑 $ ≡ 𝑑 % 𝑚𝑜𝑑 (∅(𝑝 % 𝑞 % ))
The set of safe prime numbers satisfies the following condition:

𝑒 ! ≡ 𝑒 " ≡ ⋯ ≡ 𝑒 # 𝑚𝑜𝑑(4).
Then, there exist a unique master key,

𝑒 $ mod(4𝑥 ! 𝑦 ! 𝑥 " 𝑦 " … 𝑥 # 𝑦 # ), where 𝑥 % = (𝑝 % - 1)/2 and𝑦 % = (𝑞 % -1)/2, 1 ≤ i ≤ N
, solution of a system congruence that can be calculated by the GCRT as follows:

𝑒 $ = ∑ 𝑒 % 𝑀[𝑖] 𝑁[𝑖] # %(! , Where 𝑀[𝑖] = <∏ 𝑥 ) 𝑦 ) # )(! = ∕ 𝑥 % 𝑦 % and 𝑁[𝑖] is an integer such that 𝑀[𝑖] 𝑁[𝑖] ≡ 1𝑚𝑜𝑑(4𝑥 % 𝑦 % ).
Based on theorem 1, [START_REF] Park | Key management for multiple multicast groups in wireless networks[END_REF] proposes a general MKE algorithm, which generates and modifies the master key and the key pairs, respectively. In our proposed scheme, we take advantage of this algorithm and propose an optimized algorithm for membership renewal and revocation. This algorithm is described in the DLGKM-AC scheme section. In the following, we define the system model and its underlying requirements.

IV. SYSTEM MODEL

In this paper, we propose a decentralized group key management scheme where the numbers of users and devices Fig. 2. Proposed network model change frequently. Before presenting the solution, we introduce the overall system, the attacker model and the system requirements. The architecture of the proposed network model, shown in Fig. 2, illustrates a typical three-tier scheme used for a smart hotel for our use case scenario. The entire system considers three essential layers: publishers, subscribers and group key manager.

§ The publisher layer contains IoT devices, such as smart door locks or IP cameras, collecting and sending data to subscribers. These constrained IoT devices have limited computation, storage and energy resources. § The subscriber layer is composed of a set of users that want to get access to data of the publisher layer. A user can be a device owner with legitimate, full and permanent control or a guest user with only limited access. A user communicates and receives data from IoT devices via his/her smartphone. § The group key manager layer is responsible for generating the system parameters and managing group members by providing required encryption keys used to control the access to data. The group key manager in our system is considered as a fully trusted third party.

The intended approach considers a dynamic reservation system in an IoT environment, where both the number of users and IoT devices might frequently change over time. Indeed, a user may join or leave at any time. Likewise, an IoT device can be introduced in or removed from the system at any time. Thus, it is crucial to manage the distribution of encryption keys to secure both group communication and data transmission from possible threats that will be defined in the next subsection.

A. Threat model

The proposed GKM system model may confront different type of attacks that may threaten the security of the network. Thus, we define the attacker capabilities in compromising the GKM access control scheme based on the active insider and active outsider adversary models. An attacker A may be either an outsider, who has no access to any IoT device, or an insider who attempts to increase the access possibility. For example, a revoked user who has no longer access to future communication and yet tries to retrieve information on access policies to extend access scope. Another example is an attacker A that aims to extract sensitive information, such as the encryption key, to break the current encryption scheme and get access to data without proper permissions. A may cooperate with other members in the system to derive keys that he/she cannot obtain individually, which is known as a collision attack. Besides, the attacker may also be a compromised device, where he/she may masquerade as a legitimate communication partner before initiating communication with other participant in the network to gain access to data that are unknown to him. However, he cannot compromise or break the cryptographic primitives.

B. System requirements

Several requirements are identified and discussed for effective GKM. Generally speaking, an efficient and practical GKM should address the following requirements [START_REF] Panagiotis | Securing the Internet of Things: Challenges, threats, and solutions[END_REF] [12]: a. Security requirement

In order to ensure transmitted data security, in a dynamic IoT environment, the system should achieve some services. On the one hand, it should avoid any leaving member from decrypting the future exchanged messages, to maintain forward secrecy. On the other hand, new members that join the system should be prevented from decrypting the previous communications to guarantee backward secrecy. Forward/backward secrecy are accomplished through an efficient key updating process, where all keys should be completely independent from each other in order to safeguard the key independence security service.

b. Efficient functioning requirement

The efficient functioning of key management protocols is justified by a minimum overhead cost of different metrics. First, it reduces the number of keys stored on both users and IoT devices, which results in low storage overhead. Second, it decreases the required computation power from users, IoT devices and servers, which increases the efficiency by reducing the system response time. Finally, it minimizes the number of exchanged messages on the system, which raises the flexibility of the overall system and thus achieves a low communication cost.

c. Performance requirement

The performance is mainly related to factors that affect group communication. It includes the scalability, which determines the capability to handle variable group sizes and high membership changes. Besides, key management schemes suffer from the 1-affects-n phenomenon, where a failure of a single server leads to the collapse of the whole system. Hence, it is essential to avoid this phenomenon and assure the availability in a large and scalable system.

V. PROPOSED DLGKM-AC SCHEME DESCRIPTION

In this section, we introduce the proposed scheme, and we explain how it handles member's joining and revocation events. A. Overview DLGKM-AC is composed of three essential layers, shown in Fig. 3. The upper and lower layers define groups of devices (DGs) and users (UGs), respectively. In contrast, the middle layer defines the decentralized controller, KDC, which is responsible for key management between and within groups. environment is a decentralized architecture of servers, which is composed of one KDC and several SKDC. The number of SKDC is not fixed and depends on the IoT application needs. More specifically, the number of SKDC is influenced by the characteristics of SKDC like storage, computation capacities, and the number of registered users KDC is the central server that relates publishers to the rest of the system, and it manages the keys' update process within DGs. Further, KDC has a backup server that maintains the last updated version of keys in the system, which is sent to the backup periodically after the rekeying process. Besides, SKDCs manage the group communication within UGs, where users frequently join and leave the system. Hence, the decentralized aspect of the controller, where SKDCs are used, allows reducing the load on the KDC. Multiple user groups are under the control of one SKDC depending on users' localization, which solves the problem of single-point failure (SKDC failure) and ensures the scalability of the system. Besides, we assume that the decentralized KDC can establish a one-time secure channel with users and devices, which can be used to authenticate and configure a newly joined user/device (e.g., by installing a shared secret key) before sharing with them the encryption keys. We can summarize the different encryption keys in our scheme into two main categories: (i) Traffic Encryption Key (TEK) and (ii) Key Encryption Key (KEK). The traffic keys are used to encrypt/decrypt data, while the keyencryption keys are used to encrypt/decrypt traffic keys to distribute them securely. Table II Definition: Let U = {U ! , U " , … , U * }, n ≤ N be the universe of users controlled by one SKDC. Each user in a network can subscribe to one or more services of device groups DGs among a total of M (DG) denoted by {DG ! , DG " , … , DG + }. Let UG ⊂ U be the set of users who subscribe to the same set of DGs during the same time T. Let {UG ! , UG " , … , UG , } be the set of user groups UGs. Here, each UG possesses an ID defined as follows:

𝐼𝐷 ! = $𝐴 !,# | 1 ≤ 𝑗 ≤ 𝑀| 𝑏 𝜖 [0,1] 2 , 𝐼𝐷 ! = 3 𝐴 !,$ = 0 , 𝑈𝐺 𝑖𝑠 𝑛𝑜𝑡 𝑠𝑢𝑏𝑠𝑐𝑟𝑖𝑏𝑒𝑑 𝑡𝑜 𝑡ℎ𝑒 𝐷𝐺 ! 𝐴 !,% = 1, 𝑈𝐺 𝑖𝑠 𝑠𝑢𝑏𝑠𝑐𝑟𝑖𝑏𝑒𝑑 𝑡𝑜 𝑡ℎ𝑒 𝐷𝐺 ! A.
(3)

B. Scheme construction

In this section, we detail the structure of the proposed scheme and explain how to manage group keys according to users and devices changes efficiently. Our system can be divided into five parts: (i) Initialization, (ii) device group registration, (iii) User group registration, (iv) Dynamic changes in users' membership (Join/Leave), and (v) IoT device changes (Join/Leave). We give a brief description of all used symbol in Table III.

a. Initialization

The group key manager performs the initialization, and it includes both SKDCs and KDC initialization.

i. KDC initialization

KDC runs MkeyGen algorithm based on GCRT, to generate a master key and several salve keys to communicate with several SKDCs under its control. Besides, when a new SKDC is added to the system, KDC has to run the MkeyGen algorithm to generate a slave key for the new SKDC and update its master key. Moreover, KDC establishes a secure channel with devices and users, and creates DGs and assigns UGs to SKDC. We consider an example of architecture with 4 DGs and 6 UGs in Fig. 3.

ii. SKDC initialization

Each SKDC in the system runs algorithm 1, the master key generation algorithm named MkeyGen, to initialize the system for many users. Let N be the maximum number of slave keys provided by SKDC. First of all, the SKDC generates a master key (𝒆 𝑴 , 𝒅 𝑴 ) and a set of N public-private key pairs, named slave keys, 𝑆𝐾 = {(𝒆 𝒊 , 𝒅 𝒊 ); 𝟏 ≤ 𝒊 ≤ 𝑵} through MkeyGen.

SKDC defines a function f which maps a pair key from a set of slave keys to {0, 1}as follows: 𝑓: 𝑆à {0,1}, where

𝑓: 3 𝑓 ((𝒆 𝒊 , 𝒅 𝒊 )) = 1 , ((𝒆 𝒊 , 𝒅 𝒊 ) 𝑖𝑠 𝑎𝑠𝑠𝑖𝑔𝑛𝑒𝑑 𝑡𝑜 𝑎 𝑢𝑠𝑒𝑟) 𝑓 ((𝒆 𝒊 , 𝒅 𝒊 )) = 0 , ((𝒆 𝒊 , 𝒅 𝒊 )𝑖𝑠 𝑛𝑜𝑡 𝑎𝑠𝑠𝑖𝑔𝑛𝑒𝑑 𝑡𝑜 𝑎𝑛𝑦 𝑢𝑠𝑒𝑟) (4)
After the generation of master and slave keys, SKDC initializes all pair keys using (4) as follows: 𝟏 ≤ 𝒊 ≤ 𝑵,𝑓((𝒆 𝒊 , 𝒅 𝒊 )) = 0.

b. Device Groups registration

Multiple IoT DGs are established, and each DG accommodates devices with similar attributes (i.e., security levels, localization...). KDC generates KEKs for devices in each DG. First, KDC sets a binary LKH tree for the universe of devices in each DG, which will be used to distribute updated keys to devices. In the tree, each intermediate node holds a KEK. A set of KEKs on the path nodes from a leaf to the root are called Path Keys (PKt). The LKH tree is constructed by KDC as follows: § Devices in DG are assigned to the leaf nodes of the tree.

Random keys DKj are generated and assigned securely to each leaf node. § The root node holds group key GK to communicate with devices and TEK to encrypt data of DG. § Each device Dj in DG receives the path keys PKt from the root node to the parent node of the tree, securely. Then, the path keys will be used as KEKs to encrypt the group key by the KDC in each rekeying process and to distribute updated encryption keys to leaf nodes.

c. User Groups registration

In this phase, multiple user groups UGK are constructed, and each UGK accommodates rk users with the same interest for a period T. Each user Ui in UGK is authenticated before joining the system and shares a secret key UKi with SKDC. The SKDC assigns a user group ID denoted by 𝐼𝐷 /0 # = X𝐴 ),2 | 1 ≤ 𝑗 ≤ 𝑀| 𝑏 𝜖 [0,1] _ using (3), where j defines DGj, and b outlines the user group subscription to the corresponding DGj when b=1. Otherwise, when b=0, this means that the user group is not subscribed to the corresponding DGj.

The communication within user groups is based on Master Token Encryption (MTE), which reduces the communication and computational complexities. Besides, MTE also supports efficient key updating. Therefore, SKDC conducts MTokenGen (algorithm 2) to generate the group key MTK and a set SK of slave tokens STs for UGK. Then, each user member Ui in UGK receives a ST through a secure unicast.

The SKDC adds user group information <𝐼𝐷 /0 # , 𝑀𝑇 3 , 𝑆 3 , 𝑟 3 , 𝑇= to the list of active user groups. Subscribers and IoT devices can join or leave the communication session over time. Hence, the keys should be changed in each join and leave event. Therefore, dynamic membership management is a critical component of any security architecture to ensure the backward and forward secrecy, which will be detailed in the next subsection.

d. User membership changes (join/leave)

In this section, the key updating scheme is illustrated according to two events; namely, the user join event, and the user leave event. In order to describe the keys' update process of DLGKM-AC, and for simplicity, we consider the case of a user that joins/leaves the user group UG1, where users are subscribed to DG1, DG2, and DG4.

i. When a user joins a group: Consider a user Ujoin that joins an existing group UGK; few steps are necessary as introduced below: First, Ujoin should register to SKDC after being authenticated. Then, Ujoin obtains a shared secret key UKjoin with SKDC. Subsequently, SKDC conducts JoKeyUpdate algorithm to update the group key MTK, eM, and generates a new slave token ST for the new user Ujoin. It is noticed that the existing users in the joined UGK can decrypt newly sent messages, encrypted with the new MTK, using their STs. After that, SKDC runs the JoKeyDistribute algorithm to distribute the rekeying message distribution process in the system when a user Ujoin joins UGK. First, SKDC notifies the KDC about the joining event, and then, SKDC notifies all users subscribed to the same device groups through a multicast message, to update TEKj by using a hash function.

Consequently, old users update TEKj to minimize the communication overhead in the system. Hence, the new user cannot access to previous exchanged data. Finally, SKDC sends the updated keys to the new user Ujoin through a unicast message, including his ST key. Suppose a user U4 wants to get access to DG1, DG2, and DG4, as shown in Fig. 4, meanwhile U4 needs to get these traffic keys TEK1, TEK2, TEK4. For that, U4 requests to join UG1 after being authenticated and authorized. First, SKDC creates a shared secret key UK4 with U4; then, it multicasts a notification based on the identities of user groups subscribed to the same device group to update TEK1, TEK2, TEK4, so that the new user cannot access to previous exchanged data.

Besides, SKDC updates the group key MT1' of UG1 as mentioned in JoKeyUpdate algorithm to protect previous communications between users and SKDC from intruders, and generates a new ST for U4, while existing users of UG1 still be able to decrypt data of new group key MT1'. Moreover, devices of DG1, DG2, and DG3 update TEK'1=h(TEK1), TEK'2=h(TEK2), TEK'4=h(TEK4). Finally, ST and updated TEK'1, TEK'2, TEK'4 keys are sent, in unicast, to the new user U4 by the SKDC. The protocol steps are given in the JoKeyDistribute algorithm.

ii.

When a user leaves a group: In this phase, assume that a user Uleave leaves a group UGK. Thus, he is not allowed to obtain the exchanged messages after revocation to ensure the forward secrecy. Hence, SKDC conducts the LeKeUpdate algorithm to update the group key MTK, eM, and user group information. Otherwise, the updating of the master key MTK is ensured by deleting the ST of the leaving user, while the remaining slave tokens are valid to decrypt data of the new MTK. After that, SKDC runs the algorithm LeKeyDistribute to distribute the necessary rekeying message in the whole network when user Uleave leaves UGK. Firstly, a user Uleave announces his willing to leave the system to SKDC, which verifies the request and unicasts a message to KDC to signal a leave event. Then, KDC updates all TEKj to which Uleave was subscribed according to the group identity 𝐼𝐷 /0 # by generating new TEKj based on the updating method (TEKj |random processes of KDC), and then, KDC broadcasts the new TEKs to SKDCs. At that point, SKDC enforces an access control level for the user group using its IDUG; b𝑇𝐸𝐾 ) 4&5 , ∀ 𝑗 e𝐴 ),2 = 1 𝑜𝑓𝑈𝐺 3 ]. Thus, according to IDUG, SKDC encrypts the updated 𝑇𝐸𝐾 ) 4&5 using the corresponding MT of UG and encrypts the results with the master key of SKDC. Consequently, the message is broadcasted to all corresponding users. Notice that only users with a valid ST can decrypt the new 𝑇𝐸𝐾 ) 4&5 .

Suppose a user U3 leaves the group UG1, as shown in Fig. 5. Thus, she/he unsubscribes from DG1, DG2, and DG4, which leads to losing the access privilege to those DGs. Since the data of DG1, DG2, and DG4 should not be visible to this user anymore, TEK1, TEK2, TEK4 should be updated to meet the requirements of the forward secrecy [START_REF] Banks | MQTT version 3.1. 1[END_REF].

First, SKDC updates MT1'' of the UG1, while all users of this left group still get access to their previous STs. Then, KDC broadcasts the newly generated TEKs encrypted message (TEKi, DKj'|update methods, i=1,2,4)MK to SKDCs. After, SKDC transmits TEK1', TEK2', TEK4' via an encrypted message with MT1'' securely to UG, based on the user group identity. The remaining users decrypt, with their STs, the message to handle the updated information. Finally, devices in groups DG1, DG2, and DG4 get the new TEKs keys encrypted with KEK and GK, sent in multicast by the KDC, to prevent a leaving user from obtaining additional data. The steps are defined in the LeKeyDistribute algorithm. In order to describe the update key process of DLGKM-AC during IoT device join/leave events, we consider the case of the device group DG1, which publishes data to the user groups UG1, UG3, UG4, UG6 based on their group identity.

i.

When an IoT device joins a group: Consider the update procedure of an IoT device Djoin joining a DG. Therefore, the KDC runs the DeJoKeUpdate algorithm. First, KDC shares a secret key with Djoin that joins the device group DGy. Then, KDC updates the necessary part of the LKH tree in which the device resides, multicasts to the existing devices a notification to upgrade the group key GK. Finally, KDC sends to Djoin the PKt and TEK of the DGy through unicast. Suppose a new device D4 joining the system. D4 is assigned to the device group DG1 as shown in Fig. 6.

KDC notifies devices of DG1 to update GK'1=h(GK1) and creates a shared secret key D4 with device 4 to send necessary information TEK'1, GK'1, KEK2 encrypted with the secret key of D4 through a unicast communication. Finally, KDC sends KEK2 to D3. The protocol steps are defined in the DeJoKeUpdate Algorithm.

ii.

When an IoT device leaves a group: When a device Dleave leaves a DG, the KDC rearranges the LKH tree structure in the group and runs the DeLeKeUpdate algorithm. Thus, KDC multicasts an updated group key GK' to the remaining devices encrypted with KEKs, which defines the LKH tree of the leaved DG. Then, KDC broadcasts a message to announce that Dleave is no longer a valid device.

As shown in Fig. 6, when device D2 leaves the group DG1, KDC makes a new device group key (GK'1|update method) and multicasts it to D1 and D3. The protocol steps are defined in the DeLeKeUpdate Algorithm.

VI. SECURITY ANALYSIS

In this section, we analyze the proposed scheme effectiveness in terms of forward and backward secrecy and resistance to the collusion attack.

A. Forward Security

In this section, we analyze the forward security property of the proposed protocol.

Theorem 1: The proposed group key management scheme between SKDC and users provides forward security against an adversary. In other words, the revoked user cannot get access to the ongoing communication.

Proof: Consider the case that the key pair <𝑒 ) , 𝑑 ) = should be revoked when user Uj leaves the group UGK. The SKDC updates 𝑒 $ and 𝑒 $ # . Thus, the master key of UGK satisfies ( 1) and (2):

𝑃 & ! # $ ≡ 𝑃 & " 𝑚𝑜𝑑 (𝑝 % 𝑞 % ) (1)
𝐶 ' ! # $ ≡ 𝐶 ' " 𝑚𝑜𝑑 (𝑝 % 𝑞 % ); ∀ 𝑖 𝜖 [1, 𝑟 3 ], 𝑖 ≠ 𝑗 (2) At the data source, the plaintext P is encrypted as 𝑃 J $ % & 𝑚𝑜𝑑 (∏ ∅(𝑝 K 𝑞 K ) L KM!N% ) = 𝐶 * .
After receiving the new ciphertext 𝐶 * , each user in the group can decrypt it with its individual private key 𝐶 * P ' 𝑚𝑜𝑑 (𝑝 K 𝑞 K ) = 𝑃 , ∀ 𝑖 ≠ 𝑗. Although the left user from UGK knows the old keys €𝑒 ! , 𝑑 ! •, he/she cannot obtain the correct plaintext from the ciphertext 𝐶 * through the old keys

𝐶 * P ( 𝑚𝑜𝑑 (𝑝 ! 𝑞 ! ) = 𝑃 * ≠ 𝑃.
Theorem 2: The proposed group key management scheme between KDC and IoT devices provides forward security against an adversary. In other words, the revoked IoT device cannot get access to the current communication.

Proof: This theorem is analyzed through the game 𝐺 ! . Let 𝐴 ! be an adversary by colluding with the left IoT device Dj in the device group DGK. It is worth that 𝐴 ! obtains all information stored in left IoT device <𝐷𝐾 ) , 𝐺𝐾 3 , 𝑇𝐸𝐾, 𝐾𝐸𝐾𝑠= and wants to derive the current group key, 𝐺𝐾 3 8 . After the IoT device is revoked, KDC is responsible for updating the LKH tree of DGk, likewise updating the path key from the revoked leaf node to the root node {𝐾𝐸𝐾 % 𝜖 𝑃𝐾 9 𝑜𝑓 𝐷 ) } which are used to encrypt and broadcast the 𝐺𝐾 3 8 to the remaining devices. Thus, 𝐴 ! cannot decrypt the keying message and get 𝐺𝐾 3 8 . Therefore, our protocol provides forward secrecy in DG.

B. Backward Security

In this section, we analyze the backward security property of the proposed protocol.

Theorem 3: The proposed group key management scheme between SKDC and users provides backward security against an adversary. In other words, the newly joined user cannot get access to previous communications. Proof: Suppose a new user Uj joining a group UGK with the key pair <𝑒 ) , 𝑑 ) =. The previous data source P is encrypted as

𝑃 & ! # 𝑚𝑜𝑑 <∏ ∅(𝑝 % 𝑞 % ) # %:)(! = = 𝐶, and the master key of UGK satisfies ∀ 𝑖 𝜖 [1, 𝑟 3 ] 𝑎𝑛𝑑 𝑖 ≠ 𝑗: 𝑃 & ! # ≡ 𝑃 & " 𝑚𝑜𝑑 (𝑝 % 𝑞 % ), 𝐶 ' ! # ≡ 𝐶 ' " 𝑚𝑜𝑑 (𝑝 % 𝑞 % );
The SKDC updates 𝑒 $ and 𝑒 $ # such that the master key of UGK satisfies ∀ 𝑖 𝜖 [1, 𝑟 3 ] 𝑎𝑛𝑑 𝑖 = 𝑗:

𝑃 & ! # $ ≡ 𝑃 & " 𝑚𝑜𝑑 (𝑝 % 𝑞 % ), 𝐶 ' ! # $ ≡ 𝐶 ' " 𝑚𝑜𝑑 (𝑝 % 𝑞 % );
Thus, the user joining the group UGK with the pairs keys <𝑒 ) , 𝑑 ) =, cannot obtain the correct previous plaintext from the ciphertext 𝐶 through the new keys because 𝐶 ' % 𝑚𝑜𝑑 (𝑝 ) 𝑞 ) ) = 𝑃 * ≠ 𝑃.

Theorem 4: The proposed group key management scheme between KDC and IoT device provides backward security against an adversary. In other words, the joined IoT device cannot get access to the previous communication.

Proof: Suppose a new IoT device Dj joins the device group DGK and has <𝐷𝐾 ) , 𝐺𝐾 3 , 𝑇𝐸𝐾, 𝐾𝐸𝐾𝑠= new keys. Thus, the group key GK cannot be derived by Dj. Meanwhile, knowing the secret key and the new 𝐺𝐾 3 8 , the newly joined device cannot learn anything about the previous group keys.

C. Resistance to Collusion Attack

In this section, we analyze the resistance to the collusion attack using the Random Oracle Model (ROM) standard [START_REF] Karuturi | Foundations of Group Key Management-Framework, Security Model and a Generic Construction[END_REF].

Theorem 5: The proposed GKM is collusion resistance secure. Proof: Let 𝐺 ;< be the adversarial game for collusion resistance. This game is played between two adversaries; one acts as the challenger 𝐶 ;< who interacts with the adversary 𝐴 ;< trying to win 𝐶 ;< . It is worth noting that 𝐶 ;< has the ability to simulate all the oracles 𝑂 )=%4 , 𝑂 >&?@& , 𝑂 ;%AB&<9C&9 and 𝑂 '&;<DA9 functions and output signed messages as a real signer. 𝐺 ;< consists of the following phases: Setup: 𝐶 ;< runs the MTokenGen algorithm for a random choice of ID by 𝐴 ;< . Rekeying operation is simulated after that, and the timeline is started (t=0). Queries: It is allowed to query the oracle 𝑂 )=%4 , 𝑂 >&?@& , 𝑂 ;%AB&<9C&9 and 𝑂 '&;<DA9 to control group dynamicity. Challenge: 𝐴 ;< issues one challenge query to 𝐶 ;< at time 𝑡 ;B?>>&4E& (which is the choice of the 𝐴 ;< ). Before responding to the challenge, 𝐶 ;< retrieves the set challenge Schallenge from the list Ls, and forms the of leaving members Lg, for all ID ∉ Schallenge. Then, for each identity ID ∉ Schallenge, 𝐶 ;< issues the query 𝑂 &C9<?;9 (ID) to obtain SID. Besides, 𝐶 ;< encrypts (TEK, ST, Schallenge) to get (Ai,b', TEK'), where Ai,b' defines the authorized receivers of TEK challenged with 𝐶 ;< . After, 𝐶 ;< chooses a bit b ∈ {0, 1} at random and sets Kb to TEK' and Kb-1 to a random TEK from the key space. Finally, it challenges with (Ai,b', K0, K1). Guess: 𝐴 ;< outputs a bit b' ∈ {0,1} as its guess. 𝐶 ;< passes on b' as its guess to 𝐴 ;< . The adversary advantage in winning the game is defined as 𝐴𝑑𝑣 03$ ;< = r𝑝𝑟[𝑏 8 = 𝑏] -! " r; hence, we can see that the advantage that 𝐴 ;< breaks the collision resistance of GKM is the same that 𝐶 ;< breaks chosen-ciphertext attack (CCA), meanwhile, breaks the encrypted messages (Ex. AES). Thus, if there exists no adversary who can break CCA security with non-negligible advantage, then there cannot be any adversary 𝐴 ;< , who can break the collision resistance of GKM with nonnegligible probability.

VII. PERFORMANCE ANALYSIS AND EVALUATION In this section, we analyze the performance of the proposed scheme in terms of storage overhead, computation overhead, and communication overhead. Then, we compare the results with existing methods. We also discuss the time complexity to renew the master token and revoke the slave token that we proposed for the communication with users in the same group.

A. Performance Analysis

This subsection presents the performance analysis of DLGKM-AC. In order to guarantee generality, we assume that IoT devices are equally distributed in each device group, and the LKH structures are all balanced binary trees.

a. Storage overhead

Storage overhead can be considered as the memory capacity required to maintain the keys. In this section, the storage overhead is formulated, both at each user in UGx and each device in DGy. A user belonging to UGx has a slave token ST, which is an asymmetric key AK, and as many symmetric keys (SK) TEKs as the number of DGs for which UGx is subscribed. Moreover, it has his secret key shared with SKDC. We can calculate the storage of keys for each user in UGx as follow using Eq (5):

𝑆𝑂 Q∈QS ) = 𝐴𝐾 + €∑ 𝐴 K,# T KN% + 1•𝑆𝐾 (5)
The analysis of a single d-degree key tree accommodating n member requires the tree depth denoted by 𝑓 ' (𝑛). It is known that 𝑓 ' (𝑛) is either L0 or L0 +1, where 𝐿 F = 𝑙𝑜𝑔 ' (𝑛). The authors of [START_REF] Park | Key management for multiple multicast groups in wireless networks[END_REF] made useful inequality [START_REF] Almajed | Simple and Effective Secure Group Communications in Dynamic Wireless Sensor Networks[END_REF] in order to analyze the storage overhead for key trees:

𝐸[𝑓 ' (𝑛)] ≤ 𝐸[𝑙𝑜𝑔 ' (𝑛)] + 1 ≤ 𝑙𝑜𝑔 ' 𝐸[𝑛] + 1, (6)
where the expectation, E[.], is taken over the distribution of n devices and the length of the branches on the key trees.

A device belonging to DGy, containing n devices, has a traffic key TEK, a group device key GK, and as many symmetric keys, including the KEKs and the individual key, as the length of the branch. As we consider that devices are distributed in binary trees, we can calculate the number of keys for each device in DGy using the following Eq [START_REF] Porambage | Group key establishment for enabling secure multicast communication in wireless sensor networks deployed for IoT applications[END_REF]:

𝑆𝑂 G∈G0 & = (log " 𝑛 + 3) × 𝑆𝐾 (7)

b. Computation overhead

The computational overhead can be measured as the total time consumption for encryption and decryption cost and processing requirement. This action takes place on the server, user as well as on the device sides, after each member (user/ IoT device) joining or leaving actions. We explain the different computation costs as follows:

i. When a user joins a subgroup x UGx: The SKDC assigns a slave token to Ujoin and updates the master token of UGx and its master key. The new user needs one symmetric decryption to gain the slave token ST, new TEK, and all DKs of the devices in the device groups to which they are subscribed. An existing user needs to do one hash function to update TEK. Finally, the devices need to perform one hash function to update their TEK and another hash function to derive their new device keys DK.

ii. When a user leaves a subgroup x UGx: The SKDC needs to update the master token of UGx and its master key in order to send TEK securely to users. The remaining user groups need to perform one asymmetric decryption and one symmetric decryption to gain the update information. Devices to which user groups are subscribed, need to do one symmetric decryption to obtain the update information TEK and DK.

iii.

When a device joins a device group y DGy: The old devices of the left device group require to do one hash function to update the device group key GKy. Since the GKM scheme of a group device based on LKH, the structure will change, and some devices need to decrypt O(log(n)) KEK update messages. While the new device needs only to decrypt one message sent from KDC to obtain KEKs. Users subscribed to the group joined by the new device require to decrypt the message sent by KDC to gain the new device key.

iv. When a device leaves a device group: The remaining devices execute one symmetric decryption to gain the new group key. While users subscribed to the leaving groups, they do not need to perform extra computation.

c. Communication overhead

This subsection evaluates the communication overhead of the new DLGKM-AC for the IoT environment, as shown in Table IV:

B. Performance Evaluation

In this section, we present experimental results for the DLGKM-AC scheme developed on MATLAB. We evaluate DLGKM-AC performances in terms of storage, computation, and communication overheads caused by rekeying. The rekeying transmission overhead corresponds to the additional signaling load after each join/leave event. We compare the new proposed DLGKM-AC scheme with two other key management solutions designed for access control between subscribers and publisher; a centralized scheme that support groups of publishers( GroupIT [START_REF] Kung | GroupIt: Lightweight Group Key Management for Dynamic IoT Environments[END_REF]) and a decentralized scheme does not support groups of publishers (SMGKM [START_REF] Mapoka | A New Multiple Service Key Management Scheme for Secure Wireless Mobile Multicast[END_REF]).

a. Storage overhead

The storage overhead is formulated at both sides, user, and IoT devices. To achieve a comparable security strength, we assume the symmetric encryption/decryption key length to AES-256 bits, the ECC-512 decryption key length to 512 bits. To calculate the storage overhead at the user, we consider two cases: case (1), where we vary the number of publishers DGs to which users are subscribed while fixing 20 users per UG, and case (2) where we change the number of users in each UG and consider the number of DGs settled to 4 and the number of devices fixed to 20 per DG.

Case (1): Through Fig. 7, we notice that, unlike existing solutions such as GroupIT [START_REF] Kung | GroupIt: Lightweight Group Key Management for Dynamic IoT Environments[END_REF] and SMGKM [START_REF] Mapoka | A New Multiple Service Key Management Scheme for Secure Wireless Mobile Multicast[END_REF], our scheme is less affected by the increase of DGs number to which users are subscribed. This can be explained by the fact that our scheme uses a decentralized architecture and divides IoT devices into groups which can alleviate the storage overhead compared to [START_REF] Kung | GroupIt: Lightweight Group Key Management for Dynamic IoT Environments[END_REF] and [START_REF] Mapoka | A New Multiple Service Key Management Scheme for Secure Wireless Mobile Multicast[END_REF].

Case (2): Fig. 8 shows that, in [START_REF] Kung | GroupIt: Lightweight Group Key Management for Dynamic IoT Environments[END_REF] [17] schemes, when the number of users increases, the storage on users increases too. Thus, the larger the number of users in each UG, the more these schemes incur users' storage overhead. In our scheme, the users are not affected by the number of users in their UG. This is explained by the use of the proposed MTE-based scheme for grouping users, which is not sensitive to the number of users in each UG. Hence, this can reduce the storage overhead per-user more efficiently. The storage on devices is not affected neither by the number of users nor by the number of devices in other different DGs because devices are considered just as data publishers. We can notice that devices are only affected by the number of devices of their group. Fig. 9 shows that [START_REF] Kung | GroupIt: Lightweight Group Key Management for Dynamic IoT Environments[END_REF] and our scheme have mainly the same storage. Otherwise, [START_REF] Mapoka | A New Multiple Service Key Management Scheme for Secure Wireless Mobile Multicast[END_REF] does not hold the notion of grouping the devices (publishers). Thus, storage on devices (publisher) is not affected by the number of devices in the same group.

b. Computation overhead

To evaluate the computation overhead, we simulate the cryptographic operations with Miracle Library. It is a cryptographic library designed for use in constrained environments in terms of computational power [START_REF] Abdmeziem | Fault-Tolerant and Scalable Key Management Protocol for IoT-Based Collaborative Groups[END_REF]. All simulations are implemented on a computer with the following features: an Intel i5-4200 CPU@ 2.5 GH with a physical memory of 8 GB; and Ubuntu 12.04 OS over VMware workstation 15. We provide the time cost for different cryptographic operations. As a result, we define Th = 2,445µs be the time for one hashing operation using SHA-256 function on a 64-byte block. Then, TEnc=TDec=2,7µs be respectively the time for one encryption/decryption operation using symmetric cryptography AES-256 encryption on a 64-bytes, and TECC=365,63µs represents the time for one elliptic curve cryptographic operation.

Since our protocol is designed for a dynamic IoT environment, the computational cost is measured based on leave and join operations of both users and devices. In the practical scenario, users frequently join or leave (subscribe or unsubscribe) UG. Hence, we focus on user leave/join events in the following subsection:

i.

Computation overhead when a user leaves a UG: Assume a user U of UGK leaves UGK. Thus, it is not allowed to obtain the rekeying message. Therefore, this operation is triggered by the server and transmitted to users and devices to ensure forward secrecy. We compare the computation cost as follows:

-Computation cost on the remaining users' side: We consider two cases. In the first case, we vary the number of publishers DGs to which users are subscribed while fixing 20 users per UG. Fig. 10 shows that our scheme is less affected by the number of DGs to which users are subscribed than solutions developed in [START_REF] Kung | GroupIt: Lightweight Group Key Management for Dynamic IoT Environments[END_REF] [START_REF] Mapoka | A New Multiple Service Key Management Scheme for Secure Wireless Mobile Multicast[END_REF]. The result explains that a decentralized architecture reduces the computation overhead resulting after a leave event. Otherwise, using SKDCs offload the computation overhead of updating keys in such an IoT environment. In the second case, we modify the number of users in each UG and consider the number of DGs fixed to 4 and the number of devices fixed to 20 per DG. Fig. 11 shows that, unlike our scheme, more the number of users in each UG is large, more the computation overhead is high in [START_REF] Kung | GroupIt: Lightweight Group Key Management for Dynamic IoT Environments[END_REF] [17] schemes. The proposed MTE algorithm for managing communication within user groups is one reason that explains why our proposed system has low computational cost while having a high number of users in UG. -Computation on the server-side: The group key updating time of SKDC was considered to prove the efficiency of our group key updating scheme based on CRT. Fig. 12 shows that, compared to traditional MKE, our solution consumes less time for the key updating when a user is revoked. Computation overhead when a user joins a UG: Assume a user U joining UGK. U should not be allowed to access previous communications. Thus, the rekeying operation is triggered. Hence, we compare the updating overhead when a user joins a group as follows:

-Computation cost on old users' side: We also consider two cases. In the first case, we vary the number of publishers DGs to which users of UG are subscribed while fixing 20 users per UG. Fig. 13 presents a comparison of the computation cost for old users of the joining user group UG. We note that our scheme is less affected by the number of DGs to which users are subscribed, than [13] [17] schemes. This outcome is explained by using subgroup controllers SKDCs to manage the update of keys and thus reducing computation for end-users. In the second case, we vary the number of users in each UG and consider 4 DGs and 20 devices per DG. Fig. 14 depicts the comparison of the update overhead when varying the number of users per group. We notice that our scheme is not affected by the number of users in the group as key management for user groups is based on MTE.

-Computation cost on new users' side: Fig. 15 presents the update overhead on a new user who joins a user group. Our scheme and [START_REF] Mapoka | A New Multiple Service Key Management Scheme for Secure Wireless Mobile Multicast[END_REF] present a negligible computation overhead compared to [START_REF] Kung | GroupIt: Lightweight Group Key Management for Dynamic IoT Environments[END_REF]. In fact, the new user needs only to decrypt received messages to get information. While in [START_REF] Kung | GroupIt: Lightweight Group Key Management for Dynamic IoT Environments[END_REF], a new user needs to compute the device keys to which he/she is subscribed.

-Computation cost on the server side: Fig. 16 shows the average time to update keys when there is a user joining operation. More specifically, the time needed to execute the JoKeyUpdate algorithm when varying the number of users per group. Unlike the traditional MKE, the execution time of our scheme increases slowly with the increase of the number of users per group. Computation overhead when a device joins/leaves a DG

In this subsection, we compare the overhead update triggered by device join and leave operations as follows: -The computation cost when a device joins DG: Fig. 17 depicts the update overhead when a device joins a device group. The overhead is measured on both the existing devices and the new device sides. We notice that the computation cost of the new device in our scheme is less than GroupIT. In contrast, the existing devices in DG present the same cost to get the updated keys. However, the cost in SMGKM is fixed as they do not consider grouping devices. -The computation cost when a device leaves DG: Fig. 18 depicts the update overhead when a device leaves a DG. The cost is measured on both the remaining devices of the group and the users subscribed to the DG. In our scheme, the users' computation cost is not affected by the operation of the leaving device, while, in [START_REF] Mapoka | A New Multiple Service Key Management Scheme for Secure Wireless Mobile Multicast[END_REF], it increases with the increase in the number of devices. The advantage of grouping devices explains this result. Moreover, remaining devices in our scheme have less computation cost compared to [START_REF] Kung | GroupIt: Lightweight Group Key Management for Dynamic IoT Environments[END_REF] because using a decentralized scheme reduces the reload on KDC, and thus, KDC reduces the reload on devices. 19 shows that [START_REF] Mapoka | A New Multiple Service Key Management Scheme for Secure Wireless Mobile Multicast[END_REF] scheme causes many rekeying messages when a user leaves a user group, and the number of devices is high. Therefore, [START_REF] Kung | GroupIt: Lightweight Group Key Management for Dynamic IoT Environments[END_REF] incurs much less communication overhead than [START_REF] Mapoka | A New Multiple Service Key Management Scheme for Secure Wireless Mobile Multicast[END_REF] but still causes little more communication overhead compared to our scheme, which is explained by using device groups and introducing MKE for grouping users.

VIII. CONCLUSION

A novel decentralized lightweight group key management for access control in a dynamic IoT environment named DLGKM-AC has been introduced in this paper. A hierarchical architecture is adopted using one KDC, for managing group keys and broadcasting update messages, and several SKDCs, for handling direct communication links between devices and users. Besides, a new master token encryption algorithm has been introduced in order to ensure members' independence in highly dynamic group communication. In DLGKM-AC, mobility is smoothly handled as we provide the backward and the forward secrecy with fewer rekeying operations. Furthermore, our protocol mitigates the 1-affects-n issue. Indeed, users can always get access to data even if one SKDC is affected. Extensive security analysis covering a wide range of desired security properties has also been provided. Additionally, performance analyses shows that our proposed scheme offers better performances by reducing storage, communication, and computation overheads. Finally, adopting a decentralized architecture increases scalability and reduces overhead for resource-constrained devices. As future work, to put it into practice via a proof-of-concept, we are already planning to deploy our architecture in a real-world setting, in the context of the European project PARFAIT [28], by constructing a physical network comprising a set of IoT devices and smartphones as users.

Fig. 1 .

 1 Fig.1. Generic IoT Environment

§Fig. 3 .

 3 Fig.3. Proposed system model

  TEKs, DKs, MT Output: new and updated keys ST, Ui, MT', TEKs', DKs' 1: SKDC 𝐮𝐧𝐢𝐜𝐚𝐬𝐭 Š⎯⎯⎯OE User i: establish a shared secret key with user i Ui 2: SKDC 𝐦𝐮𝐥𝐭𝐢𝐜𝐚𝐬𝐭 Š⎯⎯⎯⎯⎯OE All: Notify KDC, old users of the joined group and other user groups which subscribed to the same DG to update TEK'=h(TEK).

3 :

 3 KDC 𝐦𝐮𝐥𝐭𝐢𝐜𝐚𝐬𝐭 Š⎯⎯⎯⎯⎯OEDevices: update their key DK'=h(DK) 4: SKDC: update MT of this group joined 5: SKDC 𝐮𝐧𝐢𝐜𝐚𝐬𝐭 Š⎯⎯⎯OE User: [STi, DKs, TEK]UKi Algorithm 6 LeKeyDistribute Inputs: TEKs, DKs, MT Output: new generated keys MT', TEKs', DKs' 1: SKDC updates MT of the group UG has been left 2: SKDC 𝐮𝐧𝐢𝐜𝐚𝐬𝐭 Š⎯⎯⎯OEKDC: notify that UG has been left 3: KDC 𝐦𝐮𝐥𝐭𝐢𝐜𝐚𝐬𝐭 Š⎯⎯⎯⎯⎯OE SKDCs: (TEK'| DK')MK 4: KDC 𝐦𝐮𝐥𝐭𝐢𝐜𝐚𝐬𝐭 Š⎯⎯⎯⎯⎯OE Devices: (TEK')GK 5: SKDC 𝐦𝐮𝐥𝐭𝐢𝐜𝐚𝐬𝐭 Š⎯⎯⎯⎯⎯OE user groups UG: ((TEK')MT)MK

Fig. 4 .

 4 Fig.4. Structure inside UG1 when U4 joins

  KEKs, GK Output: new keys KEKs', GK.' 1: KDC 𝐛𝐫𝐨𝐚𝐝𝐜𝐚𝐬𝐭 Š⎯⎯⎯⎯⎯OEAll: "leaving device j is no longer available." 2: KDC 𝐦𝐮𝐥𝐭𝐢𝐜𝐚𝐬𝐭 Š⎯⎯⎯⎯⎯OEDG: update GK' and KEK's.

  KEKs, GK Output: new and updated keys DK, Dj, KEKs', GK' 1: KDC → device Dj: establish a shared secret key with the new device (Dj) 2: KDC 𝐦𝐮𝐥𝐭𝐢𝐢𝐜𝐚𝐬𝐭 Š⎯⎯⎯⎯⎯⎯OEold devices in DG: update group key GK'= h(GK) 3: KDC 𝐮𝐧𝐢𝐜𝐚𝐬𝐭 Š⎯⎯⎯OEdevices: update KEK' encrypted either by secret keys or shared KEK

Fig. 6 .

 6 Fig.6. Examples of structure updates for device join/leave.

Fig. 7 :Fig. 8 :

 78 Fig.7: Users' storage overhead while varying the number of devices

Fig. 9 :

 9 Fig.9: Devices storage overhead

Fig. 10 :

 10 Fig.10: Remaining user computation overhead varying devices' number (leave)

Fig. 11 :

 11 Fig. 11: Remaining user computation overhead varying users' number (leave)

Fig. 12 :

 12 Fig.12: Server time update on the leaving event ii.Computation overhead when a user joins a UG: Assume a user U joining UGK. U should not be allowed to access previous communications. Thus, the rekeying operation is triggered. Hence, we compare the updating overhead when a user joins a group as follows:-Computation cost on old users' side: We also consider two cases. In the first case, we vary the number of publishers DGs to which users of UG are subscribed while fixing 20 users per UG. Fig.13presents a comparison of the computation cost for old users of the joining user group UG. We note that our scheme is less affected by the number of DGs to which users are subscribed, than[13] [17] schemes. This outcome is explained by using subgroup controllers SKDCs to manage the update of keys and thus reducing computation for end-users.

Fig. 13 :

 13 Fig.13: Old user computation overhead varying the devices' number (join)

Fig. 16 :

 16 Fig.16: Server time update on the joining event

Fig. 17 :

 17 Fig.17: Computation overhead: device join

Fig. 18 :

 18 Fig.18: Computation overhead: device leave c. Communication overhead To evaluate the communication overhead of the new proposed DLGKM-AC for the IoT environment, we analyze the number of updating keys messages transmitted when a user leaves a UG. Fig.19shows that[START_REF] Mapoka | A New Multiple Service Key Management Scheme for Secure Wireless Mobile Multicast[END_REF] scheme causes many rekeying messages when a user leaves a user group, and the number of devices is high. Therefore,[START_REF] Kung | GroupIt: Lightweight Group Key Management for Dynamic IoT Environments[END_REF] incurs much less communication overhead than[START_REF] Mapoka | A New Multiple Service Key Management Scheme for Secure Wireless Mobile Multicast[END_REF] but still causes little more communication overhead compared to our scheme, which is explained by using device groups and introducing MKE for grouping users.

Fig. 14 :

 14 Fig.14: Old user computation overhead varying the users' number (join)

Fig. 19 :

 19 Fig. 19: Communication overhead: the leave event

TABLE .

 .

	I: COMPARISON OF EXISTING GKM SCHEMES [11] [9] [20] [21] [22] [13] WSN CC IoT Cent Cent Cent Sym , Asym ABE Sym, Asym No Yes No Yes Yes every join/leave event. Specifically, they focus only on [10] (i)Environment WBAN (ii)Network model Cent (iii)Cryptography type Sym , P (iv)Forward secrecy Yes (v)Backward secrecy Yes symmetric group key per subgroup communication. Consequently, the rekeying performance is decreased when the number of subscribers is high and varies frequently. Moreover, lesser attention is paid to achieve efficient and scalable GKM for access control among a dynamic IoT environment, where Yes same group, where each member needs to update its key after many users (subscribers) can subscribe to different IoT services	[17] [18] WSN Decent Sym, Asym No	[8] IPv6 Decent Sym Yes	[14] IoT Decent Sym Yes	[25] [26] IoT Distr Asym Yes
	and frequently change their interest over time. Hence,
	throughout this paper, we propose a flexible access
	management protocol that is based on the GKM mechanism.
	More specifically, to the best of our knowledge, a new
	decentralized GKM to secure group communication, offers the
	scalable feature in a dynamic IoT environment, alleviates the
	rekeying overhead caused by the member changes, and
	reduces the load on the KDC.

  functionalities, security levels, localization, etc. When a new IoT device joins the system, it is assigned to precisely one of the existing DGs. The LKH structure achieves the group communication within a DG. § User groups UGs: DLGKM-AC for IoT environment creates user groups (UGs) based on user's interest and reservation's period. Each user joins one of those UGs, and encryption keys are distributed using the MKE technique within a UG.

§ Decentralized group key manager: DLGKM-AC for IoT

  presents the different keys used in this paper.

TABLE II SUMMARY

 II OF DIFFERENT TYPES OF KEYS

	Traffic Encryption	• TEK: encrypts data of DG
	Keys (encrypt data)	• DK: encrypts data of one device
	Key Encryption	• KEK & GK encrypt and distribute TEK
	Key (encrypt traffic key)	within a DG • MT encrypts updated TEK keys to users
		in SKDC
		• ST decrypts updated TEK keys in UG

TABLE III SUMMARY

 III OF SYMBOLS AND THEIR DESCRIPTION Hash Function, Encryption function using encryption key K.

	Symbol Description
	TEK	Traffic Encryption Key
	KEK	Key Encryption Key
	M	Total number of Device Groups
	N	Total number of Slave Keys under SKDC
	(eM,dM)	Master Key
	(ei,di)	Slave Key
	MT, ST	Master Token, Slave Token
	DGy	Device Group y
	DKj	Shared secret key between device j and KDC
	UGx	User Group x
	UKi	Shared secret key between user i and SKDC
	GKy	Group Key for device group y
	PKt	Path Key
	h(.),[.]K

Algorithm 1

 1 Master Key Generation MKeyGen Inputs: A set of safe prime numbers 𝒑 𝟏 , 𝒑 𝟐 , … , 𝒑 𝑵 , 𝒒 𝟏 , 𝒒 𝟐 , … , 𝒒 𝑵 . Output: One master key 𝒆 𝑴 and N slave public-private key pairs 𝑺 = {(𝒆 𝒊 , 𝒅 𝒊 ) ; 𝟏 ≤ 𝒊 ≤ 𝑵} Number of user r, Time T, 𝐞 𝑴 , S Output: 𝑴𝑻 𝑲 Master Token of 𝑼𝑮 𝑲 and list 𝑺 𝑲 1: 𝐞 𝑴 𝑲 = 𝐞 𝑴 ; 𝑴𝑻 𝑲 = €𝒆 𝑴 𝑲 + 𝑻• 𝑼𝑮 𝑲 information (𝑰𝑫, 𝑴𝑻 𝑲 , 𝑺 𝑲 , 𝒓 𝑲 , 𝑻)and (𝒆 𝑴 , 𝑺). Output: updated 𝑴𝑻 3 𝑲 , 𝑺′ 𝑲 , 𝒓′ 𝑲 , 𝒆′ 𝑴 and 𝑺′. A new user joins the UGK 1: Find 𝒆 𝒊 from 𝑺 = {(𝒆 𝒊 , 𝒅 𝒊 ) | 𝟏 ≤ 𝐢 ≤ 𝐍} where 𝒇((𝒆 𝒊 , 𝒅 𝒊 )) = 𝟎 //𝒆 𝒊

		Algorithm 2 Master Token Generation MTokenGen
	1: 𝑺 = { };	Inputs: 2: 𝑪𝒐𝒎𝒑 = 𝟎;
	2: 𝑭𝒐𝒓 𝒊 = 𝟏 𝒕𝒐 𝑵 𝝋 𝒊 = (𝒑 𝒊 -𝟏) × (𝒒 𝒊 -𝟏); 𝒙 𝒊 = (𝒑 𝒊 -𝟏)/𝟐; 𝒚 𝒊 = (𝒒 𝒊 -𝟏)/𝟐; 𝒆 𝒊 = 𝟒 × 𝑹𝒂𝒏𝒅𝒐𝒎 + 𝟏; 𝒅 𝒊 = 𝒆 𝒊 𝟐(𝒙 𝒊 .𝟏)(𝒚 𝒊 .𝟏) -𝟏 𝒎𝒐𝒅 𝟒𝒙 𝒊 𝒚 𝒊 ; 𝑺 = 𝑺 + {(𝒆 𝒊 , 𝒅 𝒊 )}; 𝑬𝒏𝒅 𝑭𝒐𝒓	3: 𝑺 𝑲 = { }; // Select 𝑺 𝑲 = {𝒆 𝒊 𝟏𝑲 , 𝒆 𝒊 //𝒆 𝒊 𝟏𝑲 = 𝒆 𝒊 assigned to user in 𝑼𝑮 𝑲 a list of slave 𝒓𝑲 }. 𝟐𝑲 , … , 𝒆 𝒊 4: While (Comp <r) do Select a random (𝒆 𝒊 , 𝒅 𝒊 ) from 𝑺 = {(𝒆 𝒊 , 𝒅 𝒊 ) | 𝟏 ≤ 𝐢 ≤ 𝐍} keys for 𝑼𝑮 𝑲 , 5: If 𝒇((𝒆 𝒊 , 𝒅 𝒊 )) == 𝟎 Then
	3: 𝒑𝒓𝒐𝒅𝒖𝒄𝒕 = 𝟏; 4: 𝑭𝒐𝒓 𝒊 = 𝟏 𝒕𝒐 𝑵 𝒑𝒓𝒐𝒅𝒖𝒄𝒕 = 𝒑𝒓𝒐𝒅𝒖𝒄𝒕 × (𝒙 𝒊 𝒚 𝒊 );	𝑺 𝑲 = 𝑺 𝑲 + {(𝒆 𝒊 , 𝒅 𝒊 )}; 𝒇((𝒆 𝒊 , 𝒅 𝒊 )) = 𝟏; 𝒄𝒐𝒎𝒑 + +;
	𝑬𝒏𝒅 𝑭𝒐𝒓	End if
	5: 𝑭𝒐𝒓 𝒊 = 𝟏 𝒕𝒐 𝑵	End while
	𝑴[𝒊] = 𝒏/(𝒙 𝒊 𝒚 𝒊 );	6: For i = 1 to N
	𝑵[𝒊] = 𝑴[𝒊](𝒙 𝒊 -𝟏)(𝒚 𝒊 -𝟏) -𝟏 𝒎𝒐𝒅 (𝒙 𝒊 𝒚 𝒊 );	If 𝒆 𝒊 ∉ 𝑺 𝑲 = {𝒆 𝒊	𝟏𝑲 , 𝒆 𝒊	𝟐𝑲 , … , 𝒆 𝒊	𝒓𝑲 }
	𝑬𝒏𝒅 𝑭𝒐𝒓	Then
	6: 𝒆 𝑴 = 𝟎; 7: 𝑭𝒐𝒓 𝒊 = 𝟏 𝒕𝒐 𝑵	𝐞 𝑴 End if
	𝒆 𝑴 = (𝒆 𝑴 + (𝒆 𝒊 × 𝑴[𝒊] × 𝑵[𝒊]));	End For
	𝑬𝒏𝒅 𝑭𝒐𝒓	7: Algorithm 3 JoKeyUpdate
		Inputs:

𝑲 = 𝐞 𝑴 𝒌 -𝐞 𝒊 𝐌[𝐢] 𝑵[𝒊] ; {𝒋𝒐𝒊𝒏}𝑲 = 𝒆 𝒊 , 𝐢𝐬 𝐚𝐝𝐝𝐞𝐝 𝐭𝐨 𝑺 𝑲 2:𝑺′ 𝑲 = {𝒆 𝒊 𝟏𝑲 , 𝒆 𝒊 𝟐𝑲 , … , 𝒆 𝒊 𝒓𝑲 } + $𝒆 𝒊 {𝒋𝒐𝒊𝒏}𝑲 2 3:𝒓′ 𝑲 = 𝒓 𝑲 + 𝟏; 4:𝒆 𝑴 𝑲 = (𝑴𝑻 𝑲 -𝑻); 5:𝐞′ 𝑴 𝑲 = 𝐞 𝑴 𝒌 + 𝒆 𝒊 {𝒋𝒐𝒊𝒏}𝑲 𝐌[𝐢] 𝑵[𝒊] ; 6:𝑴𝑻′ 𝑲 = €𝒆′ 𝑴 𝑲 + 𝑻•;

C. Gransart is with IFSTTAR/COSYS/LEOST laboratory, Villeneuve d'Ascq, France (e-mail: christophe.gransart@ifsttar.fr).

NB: CC: cloud computing, cent: centralized, decent: decentralized, Sym: symmetric, asym: asymmetric, P: polynomial, ABE: Attribute Based Encryption

ACKNOWLEDGMENT

This work is achieved as part of the European project ITEA PARFAIT [28], which is partially funded by FEDER (European Regional Development Fund), BPIFRANCE, and the BFC region (Bourgogne-Franche-Comté).

ACRONYM TABLE