Mohamed Ali Kandi

Messaoud Djamel Eddine Kouicem

Samir Doudou

Hicham Lakhlef

Abdelmadjid Bouabdallah

Yacine Challal

Messaoud Doudou

A decentralized blockchain-based key management protocol for heterogeneous and dynamic IoT devices

Keywords: Internet of Things, Security, Key Management, Blockchain, Smart contract

come   L'archive ouverte pluridisciplinaire

INTRODUCTION

The Internet of Things (IoT) consists of extending connectivity beyond standard devices (computers, tablets, smartphones. . . etc.) to all everyday objects. This gives rise to a network made up of a large number of heterogeneous devices, which are able to automatically communicate and collaborate with each other. The IoT makes possible the development of a large number of applications that have the potential to improve our lives. Smart homes, for example, involve using smart devices to ensure comfort, convenience and energy efficiency to the homeowners. Autonomous vehicles are able to automatically exchange data to maintain traffic flow and avoid crashes.

Most of the IoT devices are nevertheless limited by their small physical size and suffer from a lack of resources in terms of storage, computation, communication and energy [START_REF] Kim | Seda: Secure overthe-air code dissemination protocol for the internet of things[END_REF]. For these reasons, many challenges are slowing down the development of this emerging technology. Securing communication is considered as one of the most difficult and the most important [START_REF] Group | IoT Developer Survey[END_REF]. Cryptography is a powerful tool used to provide security services. It is based on secret parameters, called keys, that are usually known only to authorized entities. The proper management of keys is essential to guarantee the effectiveness of cryptography.

• MA. Kandi is with IRIT, Université Paul Sabatier, Toulouse, France.

Email: mohamed-ali.kandi@irit.fr A Key Management (KM ) system includes all the operations involving the handling of cryptographic keys: generation, storage, distribution and replacement [START_REF] Vijayakumar | Key management and key distribution for secure group communication in mobile and cloud network[END_REF]. Most of the existing KM solutions are proposed for traditional Internet or Wireless Sensor Networks (WSNs). They rarely consider heterogeneous and dynamic networks such as the IoT. The solutions used in traditional Internet are usually based on asymmetric cryptography. This implies intensive computing, which makes them impractical on the IoT constrained devices [START_REF] Yousefpoor | Dynamic key management algorithms in wireless sensor networks: A survey[END_REF]. The solutions proposed for WSNs are indeed lighter [START_REF] Tsai | Key management in Internet of Things via Kronecker product[END_REF][START_REF] Zhan | A novel key generation method for wireless sensor networks based on system of equations[END_REF][START_REF] Zhang | Key establishment scheme for wireless sensor networks based on polynomial and random key predistribution scheme[END_REF] as they generally use symmetric cryptography. However, they consider that the network is homogeneous, unlike IoT, and do not balance the loads between the nodes. They do not take into account the difference in capability of devices and impose the same overheads on all of them. Thus, while a negligible part of the resources of powerful devices is used by the protocol, those of the constrained ones maybe barely or even not enough. This exhausts the resources of the constrained devices, which can significantly degrade the network performance and shorten its lifetime. It may also happen that some constrained nodes cannot support the overheads at all, while others can handle much more.

Furthermore, most of the existing solutions store the keys in the device memories before deployment. This key pre-distribution is more suitable for static networks, whose members do not change frequently. It is however difficult to add new members after deployment in the case of dynamic networks such as the IoT. On the other hand, the other solutions that dynamically update the keys upon a change in the network rely on a centralized entity [START_REF] Tiloca | GREP: A group rekeying protocol based on member join history[END_REF]. This entity becomes a single point of failure and the main target of attacks. If it fails, the entire system stops operating, and when it is attacked, the whole network is compromised.

To address these issues, we propose a novel decentralized blockchain-based KM protocol for heterogeneous and dynamic networks. Our solution considers the heterogeneity of the IoT devices and balances the loads between them according to their capabilities. By using a bit more of the resources of powerful devices, our protocol becomes lighter for the constrained ones. This improves the network performance and increase its lifetime. Our solution is therefore both efficient and highly scalable in the IoT heterogeneous networks. It also dynamically and securely updates the keys upon a network change. To overcome the disadvantages of centralized approaches, we propose a decentralized architecture based on blockchain. This technology is used as a trustworthy and secure ledger, managed by multiple participants, to ensure the traceability of the update of keys. Thus, the failure of a participant will not prevent the system from working and its capture will not jeopardize the security of the whole network. The main contributions of our work can be summarized in the following major points:

• We present a state of the art of the existing KM schemes and classify them according to several parameters. • We introduce a novel decentralized blockchain-based KM protocol for heterogeneous and dynamic networks:

-We propose algorithms that balance the loads between the heterogeneous devices according to their capabilities. We also opted for hybrid encryption, which consists of combining symmetric (for constrained devices) and asymmetric (for powerful devices) encryption to take advantages of each and overcome its disadvantages. -We propose a decentralization based on blockchain and smart contracts to automatically and securely distribute new keys to the members upon a network change. We also design a lightweight consensus algorithm that takes into account the capability of the blockchain participants for block validation.

• We analyze and compare our solution with existing schemes. We prove that our solution avoids the single point of failure problem and fulfills the IoT requirements in terms of security and performance (Table 1). • We propose an implementation on real IoT platforms to validate our theoretical and simulation results. The remainder of this paper is organized as follows. In section 2, we discuss the related works. In section 3, we recall the basic concepts of blockchain technology. In section 4, we detail our solution. In section 5, we present the security analysis. In section 6, we evaluate the performance of our solution. In section 7, we conclude our work.

RELATED WORKS

The main role of a KM system is to establish secure links between nodes by providing them with secret cryptographic keys. These keys are used, along with cryptographic algorithms, to secure communication. Although different KM protocols have been proposed, each of them presents its own limitations. None of them meets all the IoT requirements in terms of security and performance. These requirements are summarized in Table 1. They depend on the mode of communication of the IoT devices: device-to-device and group communication.In device-to-device communication (such as Vehicle-to-Vehicle communication), a device addresses a specific other one in a peer-to-peer manner. In group communication (such as Vehicle-to-Everything communication), a device communicates with multiple or all the nodes at the same time. These devices usually participate in the same service and thereby have a common interest.

Classification criteria

To properly characterize the existing KM protocols and to clearly identify the remaining challenges to be overcome, we classify them according to different criteria: key cryptography, key type, distribution method and load balancing. We discuss each category and explain its weaknesses.

Key cryptography

The KM protocols can be classified into symmetric and asymmetric schemes. Symmetric approaches [5, 7, 10, 11, 15, 16, 21, 25-28, 33, 39, 44, 51, 56, 57, 60-63, 72, 74] involve the use of the same key for ciphering and deciphering the exchanged messages. They usually require affordable computing capability and reasonable computing time. However, their effectiveness depends on the secrecy of these shared keys. The management and distribution of these keys generally require an amount of storage and communication growing with the size of the network. Symmetric approaches are efficient, but not scalable. Asymmetric approaches [START_REF] Alagheband | Dynamic and secure key management model for hierarchical heterogeneous sensor networks[END_REF][START_REF] Ayuso | Optimization of Public Key Cryptography (RSA and ECC) for 16-bits Devices based on 6LoWPAN[END_REF][START_REF] Chatterjee | An improved ID-Based key management scheme in wireless sensor network[END_REF][START_REF] Liu | On emerging family of elliptic curves to secure internet of things: ECC comes of age[END_REF][START_REF] Mall | ECL-EKM: An enhanced Certificateless Effective Key Management protocol for dynamic WSN[END_REF][START_REF] Qin | An efficient identity-based key management scheme for wireless sensor networks using the bloom filter[END_REF][START_REF] Rahman | Private key agreement and secure communication for heterogeneous sensor networks[END_REF][START_REF] Seo | Effective key management in dynamic wireless sensor networks[END_REF][START_REF] Singh | A New Key Management Scheme for Wireless Senm Networks using an Elliptic Curve[END_REF][START_REF] Wan | IBKES: Efficient Identity-Based Key Exchange with Scalability for Wireless Sensor Networks Using Algebraic Signature[END_REF][START_REF] Wang | An Authentication Key Agreement Scheme for Heterogeneous Sensor Network Based on Improved Counting Bloom Filter[END_REF] use two different keys: a public key which may be disseminated widely and a private key which is known only by the owner. One is always calculated from the other so that if the first is used for encryption, the second is used for decryption. Using these algorithms, no secret key exchange is required and a device only needs to store its own keys. However, their effectiveness depends on the difficulty of guessing the private key from the public one [START_REF] Tseng | A Lightweight Leakage-Resilient Identity-Based Mutual Authentication and Key Exchange Protocol for Resource-limited Devices[END_REF]. These algorithms are then based on computing power. Asymmetric approaches are scalable, but not efficient.

Type of Keys

The KM protocols can be classified into network and pairwise key schemes. Network key approaches entail using the same key by all members. They are scalable as they require little storage. However, they are not suitable for device-todevice communication as they lack resilience. Indeed, each device can decrypt the communication of the other ones.

The best known schemes are: Logical Key Hierarchy (LKH) and Exclusion Basic System (EBS). LKH schemes [START_REF] Wong | Secure group communications using key graphs[END_REF] consist of using a tree structure to reduce the communication cost during the process of rekeying. EBS schemes [START_REF] Eltoweissy | Dynamic key management in sensor networks[END_REF] are based on combinatorial optimization to choose a compromise between the number of keys stored on devices and that of messages exchanged during the rekeying process. Pairwise key approaches consist of using several keys instead of one. They are resilient as capturing a member does not jeopardize the others. However, they are not well suitable for group communication as the same message must be encrypted and sent several times. Pairwise key approaches can be deterministic or probabilistic. Deterministic schemes [START_REF] Baburaj | Polynomial and multivariate mapping-based triple-key approach for secure key distribution in wireless sensor networks[END_REF][START_REF] Choi | The best keying protocol for sensor networks[END_REF][START_REF] Tsai | Key management in Internet of Things via Kronecker product[END_REF] establish a direct secure link between each pair of devices. They guarantee a total connectivity coverage, but are not scalable. Indeed, each device stores as many keys as there are members in the network. Probabilistic schemes [START_REF] Bechkit | A highly scalable key pre-distribution scheme for wireless sensor networks[END_REF][START_REF] Choi | Location-based key management strong against insider threats in wireless sensor networks[END_REF][START_REF] Yu | A robust group-based key management scheme for wireless sensor networks[END_REF][START_REF] Zhan | A novel key generation method for wireless sensor networks based on system of equations[END_REF][START_REF] Zhang | Key establishment scheme for wireless sensor networks based on polynomial and random key predistribution scheme[END_REF] require less storage, but do not guarantee a total connectivity coverage. Intermediate devices are necessary to establish secure links, which requires additional computation and communication [START_REF] Zhan | A novel key generation method for wireless sensor networks based on system of equations[END_REF].

Load balancing

The KM solutions can be classified into homogeneous and heterogeneous schemes. Most of the existing solutions are homogeneous as they impose the same costs on all the nodes. While a negligible amount of resources is sufficient for some, others will not have enough. This exhausts the resources of the constrained devices, which can significantly degrade network performance and shorten its lifetime. Homogeneous schemes lack efficiency and scalability in heterogeneous networks. Heterogeneous schemes balance the costs between the nodes according to their capabilities. By using a bit more of the resources of powerful devices, the constrained ones are more likely to support the costs. Some protocols [START_REF] Alagheband | Dynamic and secure key management model for hierarchical heterogeneous sensor networks[END_REF][START_REF] Athmani | EDAK: An efficient dynamic authentication and key management mechanism for heterogeneous WSNs[END_REF][START_REF] Kausar | Scalable and efficient key management for heterogeneous sensor networks[END_REF][START_REF] Rahman | Private key agreement and secure communication for heterogeneous sensor networks[END_REF] divide the network into two classes only (powerful and constrained devices), while others [START_REF] Kandi | A versatile Key Management protocol for secure Group and Deviceto-Device Communication in the Internet of Things[END_REF][START_REF] Kandi | An Efficient Multi-Group Key Management Protocol for Heterogeneous IoT Devices[END_REF] automatically adapt to the network state.

Distribution method

The KM protocols can be classified into pre-distribution and post-distribution schemes. Pre-distribution approaches [START_REF] Baburaj | Polynomial and multivariate mapping-based triple-key approach for secure key distribution in wireless sensor networks[END_REF][START_REF] Bechkit | A highly scalable key pre-distribution scheme for wireless sensor networks[END_REF][START_REF] Choi | Location-based key management strong against insider threats in wireless sensor networks[END_REF][START_REF] Choi | The best keying protocol for sensor networks[END_REF][START_REF] Tsai | Key management in Internet of Things via Kronecker product[END_REF][START_REF] Zhan | A novel key generation method for wireless sensor networks based on system of equations[END_REF][START_REF] Zhang | Key establishment scheme for wireless sensor networks based on polynomial and random key predistribution scheme[END_REF] involve the storage of keys in the device memories before deployment. These methods are not suitable for dynamic networks as they lack flexibility. It is difficult to add new members to the network afterwards or revoke those that get compromised. Post-distribution approaches [15, 16, 21, 24-28, 33, 56, 60, 61, 68] rely on a trusted authority to dynamically provide keys to the nodes and to update them upon a network change. This method poses a risk of unavailability and has a low level of resilience.

The centralized entity may indeed become a single point of failure and the main target of attacks.

Proposed classification

To identify the challenges that related works still face in the IoT, we propose a classification of these protocols. Thus, we use the following notation to refer to a class of Key Management solutions: typ cry KM loa dis . The abbreviation "cry" refers to the key cryptography. It can take two values "sym" for symmetric protocols and "asy" for the asymmetric ones. The abbreviation "typ" indicates whether pairwise keys, "pai ", or a network wide key, "net", is used. The abbreviation "dis" can be replaced by "pre" for the protocols that are based on pre-distribution and by "pos" for post-distribution schemes. The abbreviation "loa" specifies whether the load balancing adopted by the scheme is homogeneous, "hom", or heterogeneous, "het". Finally, the notation "hyb" is used, to replace any of the above-mentioned notations, when a scheme is based on a hybridization of two categories.

In Table 2, we introduce a classification of the existing solutions based on the criteria and the notations presented above. We discuss each of the existing classes and present its weaknesses. We therefore see that none of them meet all the IoT requirements. For this reason, we propose a new solution belonging to the class hyb hyb KM het pos and we show that it is more suitable for the IoT. To overcome the drawbacks of a centralized approach, we also propose a decentralization of our protocol based on the blockchain technology and smart contracts.

BACKGROUND OF BLOCKCHAIN

A blockchain is a decentralized and secure storage technology. Its name derives from the fact that it is composed of a chain of blocks, each storing a set of transactions (which is the storage unit) and the cryptographic hash of the previous block. Every participant within a blockchain network takes part in the management of data. The whole system is therefore controlled by the members of a peerto-peer network. Since these collaborative parties do not necessarily trust each other, the blockchain offers mechanisms allowing them to reach common consensus [START_REF] Wen | Attacks and countermeasures on blockchains: A survey from layering perspective[END_REF]. Consensus algorithms guarantee that the data cannot be altered without the agreement of most of the participants. Examples of well know consensus algorithms are Proofof-Work (PoW) [START_REF] Nakamoto | Bitcoin: A peer-to-peer electronic cash system[END_REF], Proof-of-Stake (PoS) [START_REF] Vasin | Blackcoin's proof-of-stake protocol v2[END_REF] and Practical Byzantine Fault Tolerance Algorithm (PBFT) [START_REF] Castro | Practical Byzantine fault tolerance[END_REF]).

The blockchain architectures can be classified into three categories [START_REF] Zhang | Towards secure and privacy-preserving data sharing in e-health systems via consortium blockchain[END_REF]: public, consortium and private. In a public architecture (e.g. Bitcoin and Ethereum), the data is accessible and can be managed by anyone who wants to join. A large number of participants makes data more secure, but the operation of validation usually requires a lot of resources. In a private architecture (e.g. Ripple and Tendermint), the data is accessible and can be managed only by authorized users from a specific organization. With a limited number of participants, it is less difficult to alter the data, but the management is more efficient. In a consortium architecture (e.g. Quorum and Hyperledger), the data is accessible and can be managed by authorized users from several organizations. A blockchain has four main features [START_REF] Ma | Privacy-Oriented Blockchain-based Distributed Key Management Architecture for Hierarchical Access Control in the IoT Scenario[END_REF][START_REF] Viriyasitavat | Blockchain characteristics and consensus in modern business processes[END_REF]: decentralization, immutability, traceability and security.

Decentralization consists of distributing computation and storage over multiple entities. This solves the single point of failure problem and makes compromising the system difficult. Immutability means that the stored data are permanent and unalterable. This brings more trust between parties and more data integrity. Traceability allows to track the origin of each transaction. This helps to prevent from tampering with the records. Finally, the blockchain uses cryptography to secure data.

Smart contracts are autonomous and irrevocable computer programs stored in the blockchain [START_REF] Christidis | Blockchains and smart contracts for the internet of things[END_REF]. They can be automatically run by its participants to execute the settlement of a contract between organizations, people or objects. Although the idea was introduced in 1994, by Nick Szabo, it has not been put into practice until the appearance of the blockchain. It is precisely this technology that has eliminated the need for a trusted third-party.

KM and Blockchain:

The term blockchain first appeared in Nakamoto's Bitcoin paper describing a new decentralized cryptocurrency [START_REF] Nakamoto | Bitcoin: A peer-to-peer electronic cash system[END_REF]. It started then to be used in various applications. Recently, researchers began to take interest in using it to decentralize the KM . The authors of [START_REF] Lei | Blockchain-based dynamic key management for heterogeneous intelligent transportation systems[END_REF][START_REF] Lei | A secure key management scheme for heterogeneous secure vehicular communication systems[END_REF] proposed a blockchain-based KM system to secure group communication in intelligent transportation systems. In [START_REF] Ma | Privacy-Oriented Blockchain-based Distributed Key Management Architecture for Hierarchical Access Control in the IoT Scenario[END_REF], a blockchain was used to decentralize the KM for Hierarchical Access Control in the IoT. The authors of [START_REF] Azees | BBAAS: Blockchain-based anonymous authentication scheme for providing secure communication in VANETs[END_REF][START_REF] Liu | Bua: A blockchain-based unlinkable authentication in vanets[END_REF] proposed blockchain-based authentication schemes for providing secure communication in VANETs. However, most of the existing works do not consider the device-to-device communication and use the proof-of-work [START_REF] Nakamoto | Bitcoin: A peer-to-peer electronic cash system[END_REF] consensus algorithm. Our solution secures both device-to-device and group communication. It is also based on a version of proofof-stake [START_REF] Vasin | Blackcoin's proof-of-stake protocol v2[END_REF] that takes into account the capability of the blockchain participants. Proof-of-stake is known to be far less energy-intensive than proof-of-work [START_REF] Saleh | Blockchain without waste: Proof-of-stake[END_REF].

Category

Reference Discussion pai sym KM hom pre [START_REF] Bechkit | A highly scalable key pre-distribution scheme for wireless sensor networks[END_REF][START_REF] Choi | The best keying protocol for sensor networks[END_REF][START_REF] Tsai | Key management in Internet of Things via Kronecker product[END_REF][START_REF] Yu | A robust group-based key management scheme for wireless sensor networks[END_REF][START_REF] Zhan | A novel key generation method for wireless sensor networks based on system of equations[END_REF][START_REF] Zhang | Key establishment scheme for wireless sensor networks based on polynomial and random key predistribution scheme[END_REF] [+] This category is efficient for secure device-to-device communication in static networks, whose members do not change frequently.

[-] This category neither considers group communication nor the dynamic and heterogeneous nature of the IoT.

pai sym KM hom post [START_REF] Baburaj | Polynomial and multivariate mapping-based triple-key approach for secure key distribution in wireless sensor networks[END_REF] [+] These categories are efficient for secure device-to-device communication in dynamic networks.

pai sym KM hom hyb [START_REF] Choi | Location-based key management strong against insider threats in wireless sensor networks[END_REF][START_REF] Singh | A dynamic key management paradigm for secure wireless ad hoc network communications[END_REF] [-] These categories do not consider group communication and lack scalabilty in heterogeneous networks containing limited-resource devices.

pai sym KM het pre [START_REF] Lu | A framework for a distributed key management scheme in heterogeneous wireless sensor networks[END_REF] [+] This category is efficient and scalable for secure device-to-device communication in heterogeneous networks.

[-] This category does not consider neither group communication nor the dynamic nature of the IoT.

pai sym KM het hyb [START_REF] Du | An effective key management scheme for heterogeneous sensor networks[END_REF] [+] This category is efficient and scalable for secure device-to-device communication in heterogeneous and dynamic networks.

[-] This category does not consider group communication. [-] These categories do not consider the device-to-device communication and lack scalabilty in heterogeneous networks containing limited-resource devices.

net sym KM het post [START_REF] Hendaoui | UAP: A unified authentication platform for IoT environment[END_REF][START_REF] Lei | A secure key management scheme for heterogeneous secure vehicular communication systems[END_REF] [+] This category is efficient and scalable for secure group communication in heterogeneous and dynamic networks.

[-] This category does not consider the device-to-device communication.

hyb sym KM hom pre [START_REF] Hosen | A robust key management scheme based on node hierarchy for wireless sensor networks[END_REF] [+] This category is efficient for secure device-to-device and group communication in static networks.

[-] This category does not consider the heterogeneous and dynamic nature of the IoT.

hyb sym KM hom hyb [START_REF] Priyadharshini | Efficient Key Management System Based Lightweight Devices in IoT[END_REF][START_REF] Zhang | Key establishment scheme for wireless sensor networks based on polynomial and random key predistribution scheme[END_REF] [+] This category is efficient for secure device-to-device, and group communication in dynamic networks.

[-] This category lacks scalabilty in heterogeneous networks containing limited-resource devices.

pai asy KM hom post [START_REF] Chatterjee | An improved ID-Based key management scheme in wireless sensor network[END_REF][START_REF] Liu | On emerging family of elliptic curves to secure internet of things: ECC comes of age[END_REF][START_REF] Qin | An efficient identity-based key management scheme for wireless sensor networks using the bloom filter[END_REF][START_REF] Seo | Effective key management in dynamic wireless sensor networks[END_REF][START_REF] Singh | A New Key Management Scheme for Wireless Senm Networks using an Elliptic Curve[END_REF][START_REF] Wan | IBKES: Efficient Identity-Based Key Exchange with Scalability for Wireless Sensor Networks Using Algebraic Signature[END_REF][START_REF] Wang | An Authentication Key Agreement Scheme for Heterogeneous Sensor Network Based on Improved Counting Bloom Filter[END_REF] [+] This category is scalable for secure device-to-device communication in dynamic networks.

[-] This category does not consider neither group communication nor the heterogeneous nature of the IoT. Also, being based on asymmetric encryption, it is not suitable for the IoT constrained devices.

pai asy KM het hyb [START_REF] Rahman | Private key agreement and secure communication for heterogeneous sensor networks[END_REF] [+] This category is scalable for secure device-to-device communication in dynamic and heterogeneous networks.

[-] This category does not consider group communication. Also, being based on asymmetric encryption, it is not suitable for the IoT constrained devices.

pai hyb KM hom pre [START_REF] Thevar | Energy efficient geographical key management scheme for authentication in mobile wireless sensor networks[END_REF] [+] This category is efficient for secure device-to-device communication in static networks.

[-] This category neither considers group communication nor the dynamic and heterogeneous nature of the IoT.

pai hyb KM het post [START_REF] Mall | ECL-EKM: An enhanced Certificateless Effective Key Management protocol for dynamic WSN[END_REF] [+] This category is efficient for secure device-to-device communication in heterogeneous and dynamic networks.

[-] This category does not consider group communication.

OUR SOLUTION

Our solution takes into account the heterogeneity of the IoT devices and balances the loads between them according to their capabilities. It also automatically and securely provides new keys to the devices upon a network change. To securely decentralize the KM , our solution is based on the blockchain technology and smart contracts. Thus, our solution is organized into two layers (Figure 1). The node layer organizes the nodes into logical sets and provides them with cryptographic keys. The blockchain layer manages the blockchain and its participants to overcome the disadvantages of centralized approaches. Before we detail these two layers, we start by classifying our solution according to the criteria presented in the related works section.

Fig. 1: Architecture of our solution.

Our solution automatically provides keys to the nodes and updates them upon a network change, meaning that is a post-distribution approach. It is heterogeneous as it balances the loads between the devices according to their capabilities. Regarding the type of keys used, our solution combines pairwise and network key schemes to secure the two communication modes of the IoT: device-to-device and group communication. Finally, our solution is a hybridization of symmetric and asymmetric encryption to take advantages of each and overcome its disadvantages. Symmetric encryption is mainly used in layer 1, while asymmetric encryption is only used in layer 2. The main notations, that are used in multiple sections of the paper, are summarized in Table 3.

Notation Definition u, v

Examples of nodes cu

The capability of u in number of keys n

The number of nodes in the network S , T

Examples of node sets mS , mT

The size of the sets S and T mcS , mcT

The minimum capability of the sets S and T p

The number of sets in the network

Layer 1: Node Management

The first layer of our solution manages the nodes. It organizes them into logical sets and provides them with cryptographic keys. These keys can be classified into two categories: Data Encryption Keys (DEKs) and Key Encryption Keys (KEKs). The DEKs are used by nodes to encrypt the data exchanged between them. They include the network key (used to secure group communication) and the pairwise keys (used to secure device-to-device communication). The KEKs are used to secure the communication between the KM and the nodes in order to protect the DEKs. The aim is to ensure the backward and forward secrecy (for group communication) and to secure the distribution of keys (for device-to-device communication).

Let us consider a node u that belongs to a set S . The keys it holds are summarized in Table 4. We denote by p the number of sets in the network and by m S the number of nodes in S . In this case, u manages m S -1 pairwise node keys, p -1 pairwise set keys, one network key, one node key and one set key. The number of keys u has to handle is therefore proportional to the sum p + m S . On this basis, we propose set management algorithms to balance the loads between the heterogeneous devices according to their capabilities. Unlike homogeneous protocols, where the sets are uniformly organized, our solution determines the size of a set S (m S ) based on the capability (mc S ) of its weakest member. Thus, each set must verify the following inequality:

∀S , mcS ≥ p + mS (1)
Key Type Notation Description Data Encryption Key (DEK )

Ku,v
This is a pairwise node key used by u to secure the device-todevice communication with v (v ∈ S ). A node has as many of these keys as there are members in its set

K S ,T

Set Management

The set management consists of organizing nodes into logical sets while minimizing the number of keys they store. The aim is to improve the protocol scalability without significant loss of resilience, efficiency or network connectivity.

To satisfy the inequality 1, a minimum capability mc S is attributed to each set S when created. We then assign at most mc S -p nodes to the set. A node u, that can handle c u keys, is assigned to S only if mc S is the nearest value less than c u . In this case, u will manage p + m S keys, in the worst case. Since c u ≥ mc S and mc S ≥ p + m S then c u ≥ p + m S . In other words, u will always be able to support the costs. Moreover, thanks to this assignment strategy, the loads are well balanced between the nodes according to their capabilities. Considering the fact that a set cannot be empty, any node should be able to store at least p keys. For this reason, the value of p must be minimized.

Since the value of p or m S increases after the assignment, it may happen that some nodes will not be able to handle their keys anymore. In this case, their sets are split into two sets with the same minimum capability. Their size being divided in two, the members of these sets will again be able to handle the keys. Note that a set cannot be split if it contains only one node. In this case, the set is removed and its member is revoked.

Regarding the choice of the set minimum capabilities, the difficulty lies in the fact that sets are created and removed as and when required and that the abilities of nodes are not known a priori. We tried different increasing sequences and found that the loads are well balanced and p is minimized if the sequence grows exponentially. We then selected powers of two as an example of sequence. The network may be partitioned so that a minimum capability is the double of the preceding one.

The set management is based on two algorithms: Assignment and Reorder Algorithms. First, the Assignment Algorithm is run when nodes join the network and assigns them to the right sets. It creates new ones when it is necessary and may split others so that the inequality 1 remains always satisfied. On the other hand, the Reorder Algorithm is executed after a node leaves the network to reduce the number of sets. It then removes those that become empty and merges others to the possible extent. Figure 2 shows an example of a network partitioned using powers of two. The inequality 1 is satisfied for all the sets and the value of p is minimal.

Fig. 2: Example of a network partitioned into three sets.

Assignment Algorithm

The Assignment Algorithm (Algorithm 1) is run when a node u joins the network. The algorithm takes as input c u , the number of keys u can handle, and assigns it to a set S according to the input value. To achieve this, the algorithm manipulates a list of sets, ls, of size p. Each of its items contains the ID of a set, its minimum capability, its size and the IDs of its members.

Algorithm 1: Assignment Algorithm

Input : c u = capability of the node u 1 Round down c u to the nearest power of two mc u ; 2 Find in ls a set S so that mc S = mc u ;

Set creation:

Creating a new set S consists of assigning it a unique ID, sid S , a key, K S , and a pairwise set key for each set T of the network. Each of these pairwise set keys, K S ,T , is encrypted using the key of the set associated to it and sent to its members (message CM ).

CM : KM → T :< sid S , K S ,T K T > Set splitting: Splitting S consists first of creating a new set T (mc T = mc S ). The mS 2 last nodes that have joined S are then moved to T . We denote by S + the set S after being splitted and by f the first node of S to join T , i.e. ∀u ∈ S + , nid u < nid f and ∀v ∈ T , nid v ≥ nid f .

The algorithm determines first sid T . Next, to ensure the forward secrecy, it randomly generates two refresh keys, K R1 and K R2 . Then, using the KDF , it computes K S + and K T (Formulas 2 and 3). After that, all the pairwise keys associated to two nodes which no longer belong to the same set are removed. Also, for each set U (including S ), a pairwise set key K T ,U is created.

K S + = KDF (K S ||K R1 ) (2)
K T = KDF (K S ||K R2 ) (3)
Furthermore, the algorithm sends the message SM1 to each node u ∈ S (nid u < nid f ). The message is encrypted by means of the node secret key and contains K R1 . It also sends the message SM2 to each node v ∈ T (nid v ≥ nid f ) encrypted using the node secret key. SM2 contains K R2 . Finally, the message SM3 is sent to each set U (U ̸ = S and U ̸ = T ). It is encrypted by means of the set key and contains K T ,U .

SM1 : KM → u :< {uid f , K R1 )} K u > SM2 : KM → v :< {uid f , K R2 } K v > SM3 : KM → U :< K T ,U K U > 4.1.1.2

. Reorder Algorithm

The Reorder Algorithm (Algorithm 2) is run, after a node leaves the network, to reduce the number of sets. The algorithm takes as input a percentage of merging, pcm, and removes or merges sets if it is possible. Note that the more the value of pcm increases, the more the threshold, thr , below which a set must be merged increases. Thus, this parameter allows us to choose the best compromise between the merging's cost and the value of p.

Set removal:

Removing a set S consists of deleting its ID, sid S , its key, K S , and all the pairwise set keys associated to it. The message RM , containing the ID of the set, is then sent to each remaining set so that its members can remove the pairwise set key they share with the nodes of S .

RM : KM → T :< {sid S } K T >

Set merging:

Merging S and T consists of three steps. A new set is first created (following the steps presented above). Next, the members of S and T are moved to the new set. New pairwise keys are then generated for every pair of nodes u, v (u ∈ S and v ∈ T ) and sent to them (Messages MM1 and MM2 ). These messages are encrypted by means of the node keys. They contain the new cognate ID and the pairwise key associated to it. Finally, the two sets S and T are removed (following the steps presented above).

MM1 : KM → u :< {nid v , K u,v } Ku > MM2 : KM → v :< {nid u , K u,v } Kv >

Rekeying upon joining

When a node u joins the network, the KM starts by running the Assignment Algorithm to select a set S that matches its capability. It determines then the node ID and uses the RNG to generate a secret code and the keys associated to it (Formulas 4 and 5). To ensure backward secrecy, the KM also randomly generates the K R and uses it with the KDF to update the keys that u will share with other members of the network (Formulas 6, 7 and 8).

Ku,v = RNG(), ∀v ∈ S (4) Ku = RNG() (5)
K S ,T + = KDF (K S ,T ||KR), ∀T ∈ N (6)
K + G = KDF (KG ||KR) (7) K S + = KDF (K S ||KR) (8)
After that the keys are generated and updated, they are distributed by the KM on the appropriate nodes (Figure 3). Thus, it sends to each node v of the set S the unicast message RM1 encrypted by means of the node secret key, K v . The message contains the ID of the joining node (nid u ) and the pairwise node key, K u,v , associated to it. The KM also broadcasts for each set T (including S ) the message RM2 encrypted using K T , the current set key of T . The message contains the ID of S (sid s ) and K R . Finally, the KM provides u, using a key agreement method, with its secret key, the new set key, the pairwise node keys to share with its cognates and all the new pairwise set keys associated to S . After the keys distribution, the KM discards K R .

RM1 : KM → v :< {nidu , Ku,v } Kv > (∀v ∈ S) RM2 : KM → T :< {sidS , KR} K T > (∀T ∈ N )
When a network node receives the rekeying messages, it decrypts them using its node and set keys. It then stores the new keys and updates those that it will share with the joining node (Formulas 6, 7 and 8).

Rekeying upon leaving

When a node u leaves a set S or is evicted because it gets compromised, the KM runs the Reorder Algorithm if a set removal or merging is possible. Next, the KM removes the node's key and all the pairwise keys associated to it. The same steps as for the node joining are then followed to update the keys known by u (Formulas 6, 7 and 8).

Next, the KM distributes the new keys to the appropriate nodes (Figure 3). Thus, it sends, to each node v of the set S , the unicast message RM3 encrypted by means of the node key, K v . The message contains the ID of the leaving node and K R . The KM also broadcasts, for each set T (T ̸ = S ), the message RM4 to provide its members with K R . The message RM4 is encrypted using K T , the current set key of T .

RM3 : KM → v :< {nidu , KR} Kv > (∀v ∈ S, v ̸ = u) RM4 : KM → T :< {sidS , KR} K T > (∀T ∈ N, T ̸ = S)
When a network node receives a rekeying message, it decrypts it using its node or set key. It then removes the keys associated to the leaving node and updates those that it shared with it (Formulas 6, 7 and 8). Fig. 3: Rekeying upon a network change.

Layer 2: Blockchain Management

The main purpose of this layer is to decentralize the KM using the blockchain technology and smart contracts. Note that any type of architecture can be used (since the secret keys are not stored in the blockchain), but a private or a consortium blockchain remains preferable in an application such as the KM . We introduce into the network IoT gateways (or BPs for Blockchain Participants) that generate, validate and store transactions upon a network change.

The BPs act as intermediaries between the nodes and the blockchain (Figure 1). The aim is to not involve any additional cost on nodes, except those imposed by Layer 1. When a node wishes to join the network, it sends a request to a BP . If the transaction corresponding to this request is validated by the other BPs and is correctly added to the blockchain, the node is attached to the gateway that initiates the joining process. It will remain attached to it until the node moves, leaves the network or when the BP fails or gets compromised (see section 4.2.3). Meanwhile, the BP manages (generates, stores and updates) the keys associated to the node. The BP also sends to the node the rekeying messages, so that it can update its keys.In case a new shared key needs to be created (e.g., the group key or a set key), the BPs can directly and securely exchange it.

A blockchain transaction is the storage unit that corresponds to a specific event, which is a rekeying operation in our case. Any BP that executes in order the operations stored in the blockchain should have the same organization in sets. As shown in Figure 4, a transaction contains the following information:

• The rekeying operation (join, leave, evict...); • The node ID; • The node capability;

• The ID of the set of the node;

• The encrypted cryptographic hash of the node's secret code (see section 4.2.3); • The refresh key used to update the keys.

Transaction management upon network change

When a BP receives a join/leave request, it first uses layer 1 for set and node management. The algorithms and operations performed (e.g. Assignment and Reorder Algorithms) are transformed into smart contracts. The aim is to ensure that, for a certain join/leave request, any BP should obtain the same result. Before distributing the keys, the layer 1 calls the layer 2 to generate, validate and store a transaction in the blockchain. If the transaction corresponding to the current rekeying operation is correctly stored in the blockchain, the layer 2 informs the layer 1. The BP can then distribute the generated keys on the appropriate nodes after ciphering them using the KEKs (Figure 5).

(1) Transaction generation: When the layer 2 receives the information from the first layer about a rekeying operation, it starts by generating the corresponding transactions. A single transaction is sufficient for most rekeying operations. However, more than one transaction may be generated in some cases. Indeed, in the case of a set merging, we need to generate transactions for node leaving, set removal and set creation. The layer 2 then stores these transactions in its memory pool of temporary transactions and broadcasts them to all the BPs. Note that the communication between the BPs is ciphered using asymmetric encryption.

(2) Transaction verification: When a BP receives a transaction, it uses the smart contracts to verify its correctness. In the case of a node joining, the BP runs again the assignment algorithm to confirm that the node was assigned to the right set. It also checks if the node ID and the hash of the secret code have not already been used for another network node. On the other hand, if a node leaves the network or is evicted, the BP checks if the leaving node is actually a network member. It also verifies if there is a match between the node ID, the set ID and the cryptographic hash of the node's secret code. If the BP judges that the transaction is correct, it adds it to its memory pool.

(3) Transaction validation: After a certain period of time (cp) or when the size of the memory pool reaches a certain threshold (ct), the BPs run a consensus algorithm (see next section). The aim is to achieve a consensus between them on whether the content of the memory pool can be included to the blockchain. If all the BPs agree that a block of transactions can be added to the blockchain and when it is correctly stored, these transactions become valid. The layer 1 is therefore informed so that it can distribute the generated keys on the appropriate nodes.

Consensus Algorithm

We introduce a lightweight consensus algorithm for transaction validation. This is a proof-of-stake version that takes into account the capability of the blockchain participants, i.e. the BP 's capability determines its chance to validate the next block. In order not to favor the more powerful BPs, more parameters are included into the selection process: confidence and age. The level of confidence is initialized to a certain value, increased over time and decreased when an incorrect transaction from a BP is detected. The age of a BP represents the time elapsed between the last time it validated a block and a given time. This gives chance to the weak BPs to participate in the validation process when their age is high enough.

Our Consensus Algorithm (Algorithm 3) can be executed either periodically (the period is cp) or when the number of transaction in the memory pool reaches a certain threshold (ct). For each block, a validator (the BP that forges the block) is randomly elected by including a weighting according to the capabilities of BPs and the other abovementioned parameters (the higher the capability, the confidence and the age of a BP , the higher its chance to be elected). To achieve this, all BPs generate random numbers and exchange them with each other. Each of them combines all these random values by adding them, for example, or by applying another common mathematical function. The resulting value, being common to all, can be used by BPs to perform a weighted random draw and thereby elect the same validator. This validator groups the transactions contained in its memory pool to forge the new block, signs it then broadcasts it. The other unelected BPs wait for the new block and check its content once received. All the BPs, including the validator, store the block in their copy of the blockchain and remove the validated transactions from their memory pool. Finally, they update the validator parameters. They reset its age and modify its level of confidence depending on whether an error is detected or not.

Algorithm 3: Consensus Algorithm

Blockchain interest

The blockchain is used as a trustworthy ledger that ensures the traceability of the updating of keys. Thus, in addition to securely distribute the KM and ensure consistency between the different BPs, the use of blockchain offers functionalities that a centralized solution cannot provide.

System availability: When a BP fails or when it is a target of malicious attacks (such as DoS attacks), the nodes attached to it become orphans. Each of them sends then a rejoin request to an other BP . When a BP receives a rejoin request, it agrees with the sender on new KEKs so they can securely communicate. After that, the node sends the hash of its secret code to be able to get authenticated. The BP consults the blockchain and checks if the hash received corresponds to that of the node. The node in question is the only one able to generate the hash of its secret code. Moreover, the hashes stored in the blockchain are encrypted using a key known only by the authorized BPs. Therefore, the BP can conclude that the node sending the request is legitimate. If it is the case, the node is then attached to this gateway without having to add new transactions to the blockchain (Figure 6). This makes the operation more efficient. More importantly, the failure of a BP does not prevent the system from working. Therefore, our solution solves the single point of failure problem, especially as no BP knows all the keys.

Node mobility: As when a BP fails, a node can use its secret code to get authenticated with another BP if its actual BP is no longer in range. The node then sends a rejoin request to a BP which is within reach. When the BP receives the rejoin request, it sends to the node new KEKs to secure their communication. The node sends then the hash of its secret code to get authenticated. The BP consults the blockchain and checks if the hash received corresponds to that of the node.If it is the case, the node is attached to this gateway without adding new transactions to the blockchain (Figure 6). This makes the mobility operation more efficient. Our protocol is therefore well suitable for dynamic networks.

Node sleeping: To save energy, a node can sleep if it does not have a work in progress. During sleeping, the node turns off its radio and will not the rekeying messages. Note that these messages contain the refresh keys that allow the nodes to update their keys. Thus, the sleeping node will not have the opportunity to update its keys. However, when it wakes up, it will need the new keys to be able to securely communicate with the other nodes. It will then send to its BP a rekey request containing the last refresh key it received. Since all the refresh keys are stored in the blockchain, the BP can retrieve and send to the node the refresh keys it missed. It will then be able to update its keys without having to add new transactions to the blockchain.

SECURITY ANALYSIS

In this section, we analyze the security of our solution and prove that it secures the two modes of IoT communication.

Threat model

A malicious device can be inside or outside the network [START_REF] Baracaldo | G-sir: an insider attack resilient geo-social access control framework[END_REF] and may jeopardize the security of both modes of communication (Figure 7). An outsider node can store the messages exchanged between the nodes (group communication) and decipher them when it joins the network. An evicted member can also pose a threat to the network, if it is still able to decipher the future communications. If a node or a BP inside the network is captured, it may try to decrypt the device-to-device communication of the other nodes. We assume that the blockchain is tamper proof (protected against P2P attacks such as eclipse or hijacking attacks). An attacker can not alter its content unless it has a capability that exceeds 51 % of the overall network capacity, which is practically unlikely [START_REF] George | Proof of Stake: Consensus of the Future[END_REF]. Fig. 7: Threat model and countermeasures

Backward secrecy

We prove that a joining node cannot access the current or previous shared (network, set and pairwise set) keys.

Proposition 1: Backward secrecy is guaranteed as the joining node never gets knowledge of the old keys.

Proof: Let us consider a node u that joins a set S . The KM starts by updating the keys mentioned above. Before u can actually join the network, the KM rekeys all current members of the network, by means of messages RM1 and RM2 . These messages are encrypted using the node and set keys, respectively. Since none of these keys are known by u, it is excluded from the process of rekeying.

Forward secrecy and collusion resistance

We prove that leaving nodes cannot access the new shared (network, set and pairwise set) keys or any future incarnation of them, even if they cooperate.

Proposition 2: Our solution guarantees the forward secrecy and resists to collusion after nodes leaving, since they do not have access to the new security material.

Proof: Let us consider a node u that leaves a set S . The KM rekeys the nodes by means of the messages RM3 and RM4 , respectively. The former is encrypted using the node keys and the latter by means of the set keys. Since none of these keys are known by u, the leaving node is excluded from the process of rekeying. Furthermore, as these keys are independent of each other, u can not collude with other evicted nodes to decipher the rekeying messages.

Resilience against node capture

Although our solution is heterogeneous, a homogeneous distribution allows us to evaluate resilience against node capture with no significant lack of generality. The n nodes (n > 1 ) of the network are then uniformly distributed in p sets of m members each, i.e. p = m = √ n

Theoretical analysis

We study the rate of compromised links after node capture. Lemma 1: A node can decrypt a number of links D:

D = n -1 + ( √ n -1 )(n - √ n) = ( √ n -1 )(n + 1 ) (9)
Proof: A node can decrypt the communications linking it to the n -1 other nodes as well as the links between its √ n -1 cognates and the n -√ n other nodes. Proposition 3: The percentage of links that a compromised node can decipher is equal to:

P = D T = 2 (n + 1 ) ( √ n + 1 )n → 0 , as n → ∞ (10)
Proof: From lemma 1 and the fact that the total number of links in a network of n nodes is equal to

T = C 2 n = n(n-1 )

2

, we obtain this percentage. Proposition 4: The capture of the whole network cannot succeed unless all the nodes are compromised.

Proof: Deciphering all the intra-set communications requires the knowledge of all the pairwise node keys associated to it. This is only possible if all the set members are captured. Also, deciphering all the inter-set communications requires the knowledge of all the pairwise set keys. This is only possible if at least a member of each set is captured. Deciphering all the communications is then possible if and only if all the nodes of each set are captured.

Comparison

We compare our solution to the deterministic scheme presented in [START_REF] Choi | The best keying protocol for sensor networks[END_REF]. Providing a perfect resilience, none of the other solutions can do better. Figure 8 shows that, using our solution, the rate of compromised links due to node capture is negligible for large networks like the IoT. It is even comparable to the percentage provided by the perfectly resilient scheme. We also showed that the compromise of the whole network requires the capture of all its members. Our solution provides then a good level of resilience. Fig. 8: Resilience against node capture.

Resilience against BP capture

We assume that nodes are uniformly distributed on a number of BPs equal r (i.e. n r nodes are attached to each BP ). This allows us to evaluate resilience against BP capture without a significant lack of generality.

Theoretical analysis

We study the rate of compromised links after BP capture.

Proposition 5: The percentage of links that a compromised BP can decipher is equal to:

P = D T = 2nr -n -r (n -1 )r 2 → 2r -1 r 2 , as n → ∞ (11)
Proof: A BP is responsible for the generation of the keys associated to the nodes attached to it. Therefore, if it gets compromised, it will be able to decipher the n 2r ( n r -1 ) links between them. It will also be able to decipher the communications between its n r nodes and the n -n r other members of the network. It can then decrypt a total number of links equal to D = n 2r ( n r -1 ) + n r (n -n r ). Proposition 6: The capture of the whole network cannot succeed unless all the BPs are compromised.

Proof: As shown in proposition 4, deciphering all the communications requires the knowledge of all the pairwise keys. This is possible only if all the BPs are captured.

Comparison

In previous works [START_REF] Kandi | A Key Management Protocol for Secure Device-to-Device Communication in the Internet of Things[END_REF][START_REF] Kandi | A versatile Key Management protocol for secure Group and Deviceto-Device Communication in the Internet of Things[END_REF], we assumed that the KM itself is secure and that only the nodes can be compromised. In this paper, we propose a decentralization based on the blockchain as in practice the central entity can be captured. Thanks to the blockchain features, the KM is securely decentralized so that the compromise of a BP has no effect on the others. Thus, compared to the solution based on a centralized entity [START_REF] Kandi | A Key Management Protocol for Secure Device-to-Device Communication in the Internet of Things[END_REF][START_REF] Kandi | A versatile Key Management protocol for secure Group and Deviceto-Device Communication in the Internet of Things[END_REF], which once captured the whole network is compromised, only a part (Proposition 5) is captured using this decentralized version (Figure 9). We showed that the rate of compromised links is inversely proportional to the number of BPs. In other words, the more we increase the number of BPs, the more resilient is our solution. In the next section, we analyze the effect of this parameter on the network performance to help the reader to choose the best compromise between resilience and performance.

APPLICATION AND PERFORMANCE EVALUATION

To give a concrete overview of the performance of our solution, we consider the example of a smart city. This choice is motivated by the fact that a smart city contains a huge number of heterogeneous devices (servers, computers, smartphones, gateways, sensors...etc) spread across the city to provide various services to the benefit of society (healthcare, intelligent transportation system...etc.). These devices can use the two communication modes of the IoT (deviceto-device and group communication).

Theoretical analysis

We study the overheads of our solution on nodes and BPs.

Property 1: The storage cost on the members of a set S is proportional to p + m S . It is of the order of n r on the BPs. Proof: A node of a set S stores m S -1 pairwise node keys, p -1 pairwise set keys, one network key, one node key and one set key. The storage overhead on nodes is therefore proportional to the sum p + m S . If we choose not to store the pairwise node keys (which are used for device-to-device communication between the nodes) in the BP memories, the largest number of keys to store will then be that of the node keys of the members attached to it. The BP will then store a total number of keys proportional to n r . Property 2: The calculation cost of an operation related to a set S is proportional to p + m S on nodes and BPs.

Proof: Regardless of the rekeying operation performed (e.g. node joining S or node leaving S ), a node can, in the worst case, update all the keys it knows. The calculation cost on nodes is then proportional to the storage, which has been proven to be of the order of p + m S . Furthermore, a BP updates the keys which are or will be known by the node in question. The calculation overhead on the BP is therefore also proportional to the storage cost on nodes. Regarding the Assignment and Reorder Algorithms, they loop through the list of sets in the worst case, which is of size p.

Property 3: The communication cost is O(1 ) on nodes. The communication overhead of an operation related to a set S is proportional to p + m S on the BPs.

Proof: Regardless of the rekeying operation performed, a node receives a constant number of messages. The communication cost on nodes is therefore independent of all parameters (i .e.O(1 )). Also, a BP sends a unicast message to each of the m S members of S and broadcasts a message for each of the other p -1 sets, in the worst case. A BP sends then a number of messages proportional to p + m S .

Experiments

For our experiments, we used a laptop and IoT motes. Given the limited number of physical motes available to us, some are Cooja motes. For scaling up even more, a simulator (written in Python) sends requests for the tests in which the number of devices exceeds 100 (Figure 10). The experiments are carried out following these assumptions:

• We use AES-128 for encryption involving nodes and AES-256 for BPs. Indeed, some of the nodes support only AES-128. We use ECC [START_REF] Keerthi | An Algorithmic Approach to Formally Verify an ECC Library[END_REF] for the key exchange between BPs and for signing the blocks. We plan to propose a new lightweight key exchange method in future works. For now, we store a temporary key in the nodes before deployment to secure the first exchange. • We rely on storage to assess the capabilities of nodes.

Indeed, the communication for nodes is O(1 ) and the calculation depends on storage. The keys (128 bits long) are stored in the Flash memory of the nodes. • The simulated requests are uniformly distributed on the BPs and their capabilities follow a uniform distribution between 64 and a maximum value noted C MAX .

Number of sets

We deduce from the theoretical study that our solution's overheads mainly depend on the number of sets. Thus, we start by analyzing the evolution of p according to the algorithms' inputs. The aim is to present an overview on how to minimize this value. We study the effect of three parameters on the value of p: the number of nodes (n), the nodes maximum capability (C MAX ) and the percentage of merging (pcm). Each time we set two parameters to default values and vary the third one. The default values of the three parameters are 1024000 , 0 .4 and 256000 , respectively. Note that only the request simulator is used in this part of the experiments.

Starting with n, the results (Figure 11a) show that, regardless of the network size the number of sets remains reasonable. Even when n exceeds one million, the value of p does not exceed a few dozen. This makes our solution scalable since the constrained nodes manage a reasonable number of keys. Next, we analyze the effect of C MAX , the maximum capability of the simulated requests. The results (Figure 11b) show that the more powerful the nodes, the smaller the value of p. This is because powerful devices are able to manage more keys and can be assigned to larger sets. Note that the larger the sets, the more their number decreases. Therefore, the constrained nodes are more likely to support the overheads. Even when the maximum capability is small, value of p remains reasonable for a network containing over a million nodes. Finally, we study the effect of pcm. The results (Figure 11c) show that the greater the percentage of merging, the smaller the value of p. Therefore, the merging operation actually reduces the number of sets and makes our solution lighter for the constrained devices. Most of the costs imposed by set merging are on the BPs and have no significant influence on the nodes performance.

Overheads on the BPs

After studying the evolution of the number of sets, we analyze the overheads of our solution on the BPs (the blockchain overhead). We assume that, unlike nodes, the BPs have enough storage and focus on their response time. It is the time separating the reception of a join or leave request from the sending of a response to the node. We analyze the effect of three parameters on the response time (of the first and the last of simultaneous requests): the number of BPs (r ), the number of simultaneous requests (nst) and the consensus period (cp). Each time we set two parameters to default values and we vary the third. The default values are 8 , 100 and 100ms, respectively. The size of the memory pool (ct) is set to the number of BPs (r ).

Note that the request simulator as well as the physical and Cooja motes are used in this part of the experiments. Starting with r , the results (Figure 11d) show that the more the number of BPs increases, the more the processing time of one request rises. This can be explained by the fact that there is more communication between BPs. However, if more than one request are received at the same time, we notice a decrease in the response time (of the last request) before it starts going up again. This is because several BPs can process different requests at the same time. However, after a certain threshold (8 BPs with our means), the time lost due to communications covers the time saved thanks to parallelism. Next, we analyze the effect of nst. The results (Figure 11e) show that the more the system receives simultaneous requests, the more the response time increases, especially for the last node. Note that with our means, more than 1000 requests are processed per minute. Finally, we study the effect of cp (Figure 11f). The best results are obtained when the period to forge new blocks is neither too short nor too long (10ms with our means). If it is too short, there will be a lot of unnecessary message exchanges, while the memory pool is empty. Conversely, when this period is too long, the processing time of a request increases.

Overheads on nodes

Now, we evaluate the performance of our solution on the nodes. We used the 100 Cooja and physical motes in this part of the experiments. They are all within the reach of the BPs (routing is therefore not necessary) and belong to the same network. After all the nodes joined the network, we obtained the set distribution shown in Figure 12. Note that the sets 4 and 5 result from the split of the sets 2 and 1 , respectively. Furthermore, we used PowerTrace for the execution time and the energy consumption. It is a Contiki built-in tool that reports the resource utilization of a node (with an accuracy of 94 % [START_REF] Dunkels | Powertrace: Network-level power profiling for low-power wireless networks[END_REF]) and prints the statistics to the console. However, This tool is not supported by MicaZ. Therefore, we only present the storage cost on these motes.

Storage overhead on nodes:

The program, the values of the initialized variables and the cryptographic keys are stored in the flash memory, while the data are saved in RAM. The choice of storing the keys in the flash memory was motivated by the fact that some of the motes (especially MicaZ) have a very limited RAM. The number of keys stored in nodes varies depending on weather our heterogeneous seting (proportional to the node capacities) is used or not (i.e. nodes hold n keys). The percentage of memory occupation is presented in Table 5. The results show that, although the network is neither too large nor too heterogeneous, our heterogeneous seting reduces the storage on nodes. The occupation of the MicaZ RAM may seem important. However, the basic communication program, which consists of periodically sending and receiving unicast messages (without broadcast and AES encryption), occupies 67 % of the RAM. In other words, a large part of the memory is used by other processes. The part of the memory used by our protocol remains reasonable, especially considering the very limited MicaZ RAM. In [START_REF] Rizki | Efficient Group Key Management for Internet of Things[END_REF], the network is composed of 15 TelosB motes only and yet 96 .3 % (against 63 .26 % using our solution) of their flash memory and 74 .92 % (against 47 .15 % using our solution) of their RAM are occupied. Our solution requires then less storage on TelosB.

Execution time on nodes: The evaluation of the computing cost of our solution concerns two operations a node may perform: key installation and key update. Key installation corresponds to the operation by which a new node, which has just join the network, processes the Key Manager's messages and stores the keys assigned to it in its memory. Key update is the operation by which a network node updates its keys upon a network change. For this operation, we consider both cases where a set is split or not. The execution time of any of these operations corresponds to the time separating the reception of a message from a BP and the end of its processing. The execution times on nodes are presented in Table 6. The results were obtained using Powertrace. This tool is not supported on MicaZ. Therefore, we only present the execution time on the other motes. Energy consumption by nodes: For energy consummation, we consider the same operations as in the previous section (key installation and key update with or without set split). The energy consumed by a node includes calculations and communications. We then used Powertrace to evaluate the energy consumption of our solution per second. The results are presented in Table 7 In Table 8, we present an estimate of the lifespan of 2xAA batteries using our solution. The lifespan is calculated, for each type of node, according to the average value of the quantity of energy it consumes. The results are obtained assuming that the nodes are constantly receiving a rekeying message per second. Although some authors (such as those of [START_REF] Bechkit | A highly scalable key pre-distribution scheme for wireless sensor networks[END_REF][START_REF] Mall | ECL-EKM: An enhanced Certificateless Effective Key Management protocol for dynamic WSN[END_REF][START_REF] Omar | Efficient and energy-aware key management framework for dynamic sensor networks[END_REF]) evaluate the energy consummation of their Key Management protocols, they are based on theoretical models (an example can be found in [START_REF] Heinzelman | Energy-efficient communication protocol for wireless microsensor networks[END_REF]) and cannot be compared to our experimental results. In the absence of similar works presenting the results of an implementation on the same IoT motes we used, our results can be compared to those presented in [START_REF] Sonhan | Sample Data for powertrace using CM5000 motes[END_REF]. The authors used Powertrace to estimate the energy consumption of TelosB motes when sending ipv6 packets (while we used the lightweight Rime Stack). Since communication is the operation that consumes the most energy, these results can be compared to the energy consumption of our solution, even if they do not consider the overheads related to the Key Management.

Comparison

We compare our solution to the existing protocols proposed for device-to-device (PKS [START_REF] Choi | The best keying protocol for sensor networks[END_REF], Trade [START_REF] Ruj | Pairwise and triple key distribution in wireless sensor networks with applications[END_REF], UKP [START_REF] Bechkit | A highly scalable key pre-distribution scheme for wireless sensor networks[END_REF], Kronecker [START_REF] Tsai | Key management in Internet of Things via Kronecker product[END_REF]) and group communication (MGKMP [START_REF] Kandi | An Efficient Multi-Group Key Management Protocol for Internet of Things[END_REF] and GREP [START_REF] Tiloca | GREP: A group rekeying protocol based on member join history[END_REF]). We also compare our consensus algorithm to Tendermint, which is based on PBFT [START_REF] Inc | Tendermint[END_REF].

Efficiency and scalability

We take as example a TelosB node, which can theoretically store up to 1536 keys of 256 bits (ignoring the other node's memory requirements). For the node to support the storage cost of our solution, it must be able to store at least p keys. The percentage of storage must then be greater than P o = p 1536 . The authors of GREP, MGKMP, Trade and Kronecker show that the storage of their solutions is proportional to O( √ n). The memory rate required to store these √ n keys is P r = √ n 1536 . Finally, the nodes storage cost of PKS is of the order of n. The percentage of memory required is P n = n 1536 .

We compare the variation of these percentages according to n (Figure 13a). The results show that our solution requires less storage on a TelosB than the other protocols. Indeed, regardless of network size, the value of P o is smaller than P r and P n . More importantly, if the network contains 1536 nodes, the total memory of the TelosB will be used to store all the keys of PKS, while 1 % of its storage capability is enough if our solution is used. This is because storage cost is well balanced between the nodes according to their capabilities. Thus, by using a bit more of the resources of powerful devices, our solution becomes much lighter for the constrained ones. It can then operate on much larger heterogeneous networks.

Connectivity, mobility and flexibility

While the probability that two neighboring nodes share a common key does not exceed 0 .25 in Trade and is approximately lower bounded by 0 .632 in UKP, it is always equal to 1 using our solution. Moving devices will also always share keys with their new neighbours. Indeed, each pair of communicators share a pairwise node or set key and can establish a direct secure link. Our solution provides then good connectivity and mobility. Note that when connectivity and mobility are low, some communicators rely on intermediate nodes to establish a secure link. This reduces the efficiency of the protocol.

Some schemes [START_REF] Choi | Location-based key management strong against insider threats in wireless sensor networks[END_REF][START_REF] Yu | A robust group-based key management scheme for wireless sensor networks[END_REF] are based on the deployment knowledge to maximize the network connectivity. The application of this method is nevertheless restrictive if the deployment knowledge is not possible. It is therefore clear that the KM we propose is more flexible as the division into sets is logical and operates well regardless of the position of nodes. Furthermore, regardless of their category, most of the existing schemes for device-to-device communication are based on key pre-distribution. These schemes suffer from poor flexibility as it is hard to add new nodes to the network. Our solution, on the other hand, supports the dynamic deployment of nodes thanks to its rekeying mechanism. Indeed, we previously showed that nodes can join and leave the network at any time without jeopardizing the security of the network. Our solution is therefore more flexible. proportional to the nodes' storage capability, using our solution. We consider then a network of 10000 nodes and analyze the variation of the calculation and storage cost according to the node's capability (number of keys it can handle), for the three protocols. Note that the percentage of storage capability that we choose using our solution is 5 % (i.e. only 5 % of the real capability of the node is used). The results are plotted in Figures 13b. We take as example two nodes u 1 and u 2 that can store 200 and 1800 keys, respectively. For both nodes, 5% of their memory is used by our solution, in the worst case. MGKMP and GREP, on the other hand, use 50% of the former and 5% of the latter. As the calculation overhead on node depends on the storage, these protocols quickly exhausts the resources of u 1 , while u 2 has much more. More importantly, the nodes having a capability lower than 100 can not even store all the keys, while our solution uses 5% of their memory only. Thus, although the overheads imposed by MGKMP and GREP are lower than that of our solution for powerful devices (capability greater than 1000 ), they are much greater for the weak ones.

Consensus Algorithm

We mainly choose Tendermint for two reasons. First, it is a powerful blockchain engine based on the PBFT consensus algorithm [START_REF] Inc | Tendermint[END_REF]. Using Tendermint, solving a puzzle is not required to enter the next block. Therefore, compared to some of the most used consensus algorithms (e.g. PoW), PBFT reduces computation and thereby the energy consumption. Second, the application layer of Tendermint can be written in any programming language. This facilitates the integration of our solution (written in Python) to this environment. The other parameters that are not related to the consensus algorithms (such as the key size, the assignment algorithm and the material used) are the same in both cases (using our consensus algorithm and PBFT of Tendermint). The obtained results are plotted in Figure 13c. They show that regardless of the number of BPs, the process of a request is always faster using our solution.

CONCLUSION

In this paper, we proposed a novel decentralized blockchain-based Key Management protocol for heterogeneous and dynamic networks. Our solution balances the loads between the nodes according to their capabilities. We proved that this makes it efficient and highly scalable. Furthermore, our solution automatically and securely distribute new keys to the members upon a network change. To overcome the disadvantages of centralized approaches, we used the blockchain technology and smart contracts. We showed that the system will continue to operate even if an entity fails and that the compromise of an entity will not jeopardize the security of the whole network. Finally, we proposed an implementation on real IoT platforms to validate the theoretical analysis and the results of simulations. In future woks, we intend to propose a novel lightweight key agreement method to securely and efficiently distribute keys on the limited-constrained nodes.

Algorithm 2 : 3 else 4 thr 5 if m S < thr then 6 Find

 23456 Reorder Algorithm Input : pcm = percentage of merging 1 foreach set S that a node has left do 2 if m S = 0 then Remove S ; ← pcm.(mc S -p); T such as m T < thr and mc T = mc S ; 7 if a set T is found in ls then 8 Merge S and T ;

Fig. 4 :

 4 Fig. 4: Example of a blockchain transaction.

Fig. 6 :Fig. 5 :

 65 Fig. 6: Rejoin exchange.

Fig. 9 :

 9 Fig. 9: Resilience against BP capture.

  The laptop is an Intel Core i7 with 4GB RAM. The motes (based on Contiki) are of 5 types: 22 Exp5438 [17], 22 MicaZ [40], 12 Openmotes [43], 22 TelosB [54] and 22 Z1 [71]. To join the network, the devices send requests to the BPs. The BPs process the requests and send rekeying messages to nodes.

Fig. 10 :

 10 Fig. 10: Experimental platform.

Fig. 11 :

 11 Fig. 11: Experimental results.

Fig. 12 :

 12 Fig. 12: Network partitioning.

6. 3 Fig. 13 :

 313 Fig. 13: Comparison results.

TABLE 1 :

 1

Key Management requirements for the IoT.

TABLE 2 :

 2

Classification of existing solutions.

  Assign u to S ; 7 Update ls; 8 while ∃ T for which mc t < p + m t do

	3 if no set is found then
	4	Create a new one S ;
	5 end
	6

9

Split T ; 10 end

1

  Generate a random number and broadcast it; 2 Wait for the random numbers of the other BPs; 3 Combine the received numbers into one value; 4 Use this shared value to elect a validator; 5 if the BP is the validator then

	6	Forge the new block;
	7	Sign the block;
	8	Broadcast the block;
	9 else
	10	Wait for the block from the validator;
	11	Check the block and its transactions;
	12 end
	13 Store the block in the blockchain;

[START_REF] Dunkels | Powertrace: Network-level power profiling for low-power wireless networks[END_REF]

Remove validated transactions from memory pool; 15 Update the validator parameters;

TABLE 5 :

 5 Storage overhead on nodes.

TABLE 6 :

 6 Execution time on nodes.

  .

	Exp5438	3.2 mJ	3.95 mJ	8.41 mJ
	OpenMote	4.38 mJ	4.52 mJ	10.03 mJ
	TelosB	2.32 mJ	4.22 mJ	9.83 mJ
	Z1	3.7 mJ	4.38 mJ	9.46 mJ

TABLE 7 :

 7 Energy consumption by nodes.

TABLE 8 :

 8 Battery life.

ACKNOWLEDGMENTS

This work was carried out and funded by Heudiasyc UMR CNRS 7253 and the Labex MS2T.