Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things

ARTICLE IN PRESS

JID: COMPNW

[m3Gdc;August 22, 2015;20:28]

Computer Networks xxx (2015) xxx–xxx

Contents lists available at ScienceDirect

Computer Networks journal homepage: www.elsevier.com/locate/comnet

Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things Somia Sahraoui∗, Azeddine Bilami

Q1

LaSTIC Laboratory, Computer Science Department, University of Batna, Algeria

a r t i c l e

i n f o

Article history: Received 7 February 2015 Revised 29 July 2015 Accepted 13 August 2015 Available online xxx

Q2

1 2 3 4 5 6 7 8 9 10

Keywords: Internet of things IoT Wireless sensor networks End-to-end security Host Identity protocol 6LoWPAN compression Distributed HIP base exchange

a b s t r a c t The Internet of Things (IoT) is an emerging and promising paradigm that can be considered as an extension of the Internet to interconnect all kinds of smart objects around us to provide a pervasive (or ubiquitous) information access. Wireless Sensor Networks (WSNs), as a vital component of the IoT, allow the representation of the dynamic characteristics of the real world in the Internet’s virtual world. Thus, sensor nodes are henceforth considered as Internet hosts and, may act as web servers or clients. The maturity of the Internet of Things is arguably linked to communications security and end-users privacy protection. However, the material and technological heterogeneity as well as the asymmetric nature of the communications between the sensor nodes and the classical Internet hosts are making security a challenging problem. In this context, many recent works focus on leveraging IP-based security protocols for IoT, after adapting them to WSN’s constraints commonly by messages compression or by computational-load distribution techniques. In this paper we propose a 6LoWPAN (IPv6 over Low power Wireless Personal Area Networks) compression for the header of HIP (Host Identity Protocol) packets, as well as, an adapted distribution scheme of security computational load in HIP Base EXchange (HIP-BEX). To achieve extremely lightweight end-to-end (E2E) security, we combine both proposed compression and distribution models for HIP in WSN’s side, in the IoT. The evaluation results show clearly that the proposed solution, named Compressed and Distributed HIP (CD-HIP), is sufficiently energy efficient with a slight security establishment delay, and a good level of compatibility with the standard HIP. © 2015 Published by Elsevier B.V.

1. Introduction The future Internet (or Internet of Everything (IoE) as Cisco denominates it [1]) is intended to connect all smart objects surrounding us in our daily life, for smarter living conditions and improved quality of service in different application domains, such as smart transport systems, smart cities and smart health care, through ambient communications and the remote control facilities. Furthermore, it is forecasted that up to 50 billion of machines and objects will be connected by 2020 [1], where the connected objects may be ∗

Corresponding author. Tel.: +213 033 813 202. E-mail addresses: [email protected] (S. Sahraoui), abilami@ yahoo.fr (A. Bilami).

any device equipped with sensor or Radio Frequency IDentification (RFID) tag, smart phones, tablets and so on. The IoT [2], as an integrated part in the future Internet, refers to a mixture of the basic technologies (mainly: WSNs and RFID) and standard protocols and mechanisms, for a unique identification and virtual representation of the connected objects in the web of everything. This novel trend brings a third dimension to the Internet connection: anytime, anywhere and anything. Thereby, new types of interactions occur [3], such as: Human to Thing (H2T) and Thing to Thing (T2T, also called Machine to Machine (M2M) interactions), which concretizes the principle of the pervasive Internet. Wireless sensor networks [4] play a significant role in the Internet of things, they are even considered among the most important enabling technologies. WSNs link the physical

http://dx.doi.org/10.1016/j.comnet.2015.08.002 1389-1286/© 2015 Published by Elsevier B.V.

Please cite this article as: S. Sahraoui, A. Bilami, Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.08.002

11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

JID: COMPNW 2

26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86

ARTICLE IN PRESS

[m3Gdc;August 22, 2015;20:28]

S. Sahraoui, A. Bilami / Computer Networks xxx (2015) xxx–xxx

world with the wide digital world of the Internet by the representation of the dynamic characteristics (i.e. temperature, vibration, pressure, etc.) of the smart objects in the Internet. The connection of WSNs to the Internet enables the exploitation of sensing reports (that are often massive) in web applications and services, which is possible with the elastic storage and processing services brought by cloud computing, and which leads to a ubiquitous access to WSN’s data. The integration of WSNs in the Internet is often realized across the adoption of adapted extensions of the standard communication protocols of the Internet (TCP/IP based protocols), which guarantees interoperability, transparency and flexibility of the integration. In such a case, sensor nodes become IP hosts and can communicate with any other object or ordinary Internet host and therefore, the communication is direct and bidirectional as well. IPv6 (Internet Protocol version 6) [5] that has an immense space of available addresses, and deals with security and quality of service (QoS) issues is used in the Internet of things. In this context, several working groups of the IETF (Internet Engineering Task Force) have addressed the issue of integrating WSNs in the Internet via the specification and the standardization of lightweight solutions that are compliant with IP-based standards, and projecting them in WSNs side. 6LoWPAN [6] is an adaptation layer, developed and standardized by one of such working groups. Such an adaptation layer renders possible the communication of IPv6 packets over IEEE 802.15.4 enabled WSNs, through header compression and packets fragmentation techniques. Consequently, the communication costs are significantly reduced and IPv6 packets can fit within the IEEE 802.15.4 frames, where the network’s MTU (Maximum Transmission Unit) is about 127 bytes compared to 1280 bytes of minimum MTU in IPv6 networks. Thanks to this relevant standardization, WSNs can be considered as real IPv6 networks. Accordingly, WSNs are henceforth called 6LoWPANs. Certainly, IPv6 fragments need for an efficient and energy-aware routing scheme to route them within the 6LoWPAN network. For this reason, the Routing over Low power and Lossy networks group (RoLL) has investigated the routing task in IPv6-enabled WSNs. Their researches led up to the development of RPL (Routing Protocol for Low power and lossy networks) [7] the IPv6 routing protocol for low power and lossy networks (LLNs) that are limited in energy, storage and processing resources, quite like WSNs. RPL forms a dynamic and optimized topology with loops avoidance to allow an appropriate routing of the IPv6 fragments to and from the sensor nodes with the consideration of several QoS metrics. Also, from an applicative perspective, the Constrained RESTful environments (CoRE) research group has defined an adapted standard that brings web services for WSNs in the context of IoT by means of protocol CoAP (Constrained Application Protocol) [8]. In the case of isolated WSNs, the communication and security solutions were tightly tailored to realize the tradeoff between a lower energy cost and a good level of efficiency. This goal had been reached in the majority of the cases, since the inter-sensors communication was generally homogenous, and sensors within the same network had similar constraints. Achieving such a trade-off in the Internet of things seems to be more difficult, due to the dominant heterogeneity with its various forms especially, those

which are related to resources availability in the involved entities. In classical applications of WSNs, where the Internet were used only as a transporting medium of sensing reports to the task manager, adversaries were obliged to access the network physically, so that they could successfully attack it. By opening WSNs to the Internet, security and privacy problems get amplified as WSNs in such a case are prone also to external threats that may be launched remotely by any malicious host in the Internet. Indeed, the main source of vulnerabilities of the integration of WSNs to the Internet is the asymmetric nature of the communications between constrained sensor nodes situated in a lossy wireless network and, powerful Internet hosts that belong to less constrained networks. Notably, the necessity of the fragmentation of long incoming IPv6 packets, present another source of vulnerability [9], since it opens the door to several forms of Denial of Service (DoS) attacks. End-to-end security is a mandatory pattern in the Internet security. This mechanism relies on the protection measures implemented on the terminal hosts for enabling safe end-to-end communications. End-to-end security can be ensured at different levels in the TCP/IP model (i.e. in network, transport or application layers). In WSNs isolated from the Internet, end-to-end security was not truly necessary, since intermediate nodes should access the sensed data included in the received messages for aggregation and energy-saving purposes. Once WSNs are connected to the Internet, endto-end security becomes essential, as the information being exchanged between sensor nodes and Internet hosts, is generally sensitive and/or private enough, especially in some IoT applications that are tightly linked to critical infrastructures and strategic services such as the distribution of water and electricity, or other applications that handle private information about individuals, such as their location and movements, or their health status. However, the particular constraints imposed on WSNs, especially scarce resources, prevent the direct projection of the robust and well-approved security standard solutions, initially developed to the Internet. So, adaptation acts are strongly encouraged. Recently, researchers have intensively investigated this issue, by trying to find suitable techniques that allow the extension of existent IP-based secure protocols to Internet-integrated WSNs. The proposed solutions focus generally on messages compression in order to minimize the communication overhead, and in few cases, they focus on computation acceleration or distribution techniques to ameliorate the adaptability of Internet’s standard security protocols to WSNs constraints. In this paper, we propose an efficient strategy to achieve lightweight end-to-end security in the IoT. The proposed solution targets HIP protocol, which seems to be more advantageous for IoT deployments as it inherently, facilitates endusers mobility and provides a good level of location privacy, by means of identifier/locator split. Our work consists of a combination of a relevant 6LoWPAN compression model for HIP header, as well as, a secure distribution model for the security load of HIP’s session establishment process. To the best of our knowledge, this is the first work that combines the compression with the computational load distribution techniques, at least for HIP protocol, to ensure lightweight endto-end security in the Internet of things.

Please cite this article as: S. Sahraoui, A. Bilami, Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.08.002

87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147

JID: COMPNW

ARTICLE IN PRESS S. Sahraoui, A. Bilami / Computer Networks xxx (2015) xxx–xxx

156

The remainder of the paper is structured as follows: in Section 2, we present an extensive review of the proposed solutions in the literature to deal with end-to-end security issue in the IoT. In Sections 3, we state the problematic and motivations leading to the proposed work. In Section 4, we present in detail our proposals for efficient and lightweight end-to-end security in the IoT and then, we discuss in Section 5, the performance evaluation results. Finally, in Section 6, we summarize and conclude our work.

157

2. Related work and analysis

158

164

This section covers a review of the proposed solutions that deal with end-to-end security issue in the Internet of things. These solutions attempt to adapt the classical and the well-known set of IP-based security protocols so that we can safely apply them to the constrained WSNs, in the IoT. We distinguish four classes of solutions operating in different levels of the TCP/IP model.

165

2.1. TLS based solutions

166

TLS (Transport Layer Security) [10] is the most widely used security protocol for Internet applications. It is especially designed to operate on reliable transport services, like TCP, and to create an optional secure connection between an Internet host and a web server. For doing so, TLS specifies an authenticated handshake that involves asymmetric cryptographic operations. During the handshake process, the two parties negotiate the necessary information for session establishment such as cipher suite and the shared secret on which is based the generation of keys. The negotiation is realized essentially, via the exchange of ClientHello, ServerHello and ClientKeyExchange messages. Even though TLS responds efficiently to the security needs (such as two-way authentication and integrity), it is not suitable for WSNs because of the heaviness of its handshake process, which is energy requiring when applied as it is. From that, some research works have addressed the possibility of adapting TLS to WSNs. Authors in [11] are among the first to propose TLS for securing communications between Internet hosts and sensor nodes in e-health applications. The solution is named Tiny 3-TLS, and it focuses on the adaptation of basic TLS handshake so that it can be fairly supported by WSNs connected to the Internet via proxy. The principle of the proposed adaptation consists of the introduction of a third party (represented by the base station) between the terminal sensor node and the remote Internet host. This secure gateway assists the constrained sensor nodes to establish TLS connections with outsider entities. The solution accepts two possible scenarios depending on whether the gateway is partially trusted or fully trusted. According to the first case, the assistant entity will only help the two terminal parties to establish a shared secret that is unknown to it. This is not the case with the second scenario where the gateway shares the session secret with the sensor node and the distant client, in addition to the participation in the handshake process. Additionally, Tiny 3-TLS uses ECC (Elliptic Curve Cryptography) for smaller key sizes and lower computational overhead. Authors claim that their solution provides efficient end-to-end security in its two versions, while discharging the constrained sensors

148 149 150 151 152 153 154 155

159 160 161 162 163

167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204

[m3Gdc;August 22, 2015;20:28] 3

from the complicated tasks in the TLS handshake. However, the communication overhead as well as packets fragmentation rate would be considerable due to the absence of messages compression. In another side, the centralized nature of the solution (the accreditation of one unique intermediate gateway) presents a major source of weakness and fault tolerance problems. In [12] authors propose a solution to enable end-to-end secure communications in the IoT. The proposition consists of a collaborative key transporting and agreement in TLS handshake. The assumed scenario implies a set of powerful neighboring proxies to which the constrained sensor node delegates the most complicated computational tasks in the handshake, such as the key transportation and derivation. All communications in the network, including the communication between the end-sensor node and the proxies, are protected using RSA security measures. Even though the solution reduces the computational overhead for highly constrained sensors, some relevant considerations still have to be taken into account, like the susceptible network overhead that may result from the important amount of exchanged messages required for the distribution system. Additionally, transactions with the proxies have to be strictly reliable. Likewise, any information loss may lead to a session teardown incident. Moreover, as WSNs are prone to nodes compromising threats, the behaviors of all proxies should be monitored in order to prevent hostile nodes from compromising network’s security. At this stage, it is necessary to mention that the common shortcoming of TLS-based solutions resides in the fact that TLS and any other protocol that manages communications reliability and in-sequence packets delivery, is not suitable for unreliable and highly constrained environments, quite like WSNs.

205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238

2.2. DTLS based solutions

239

DTLS (Datagram Transport Layer Security) [13] is the UDPbased variant of TLS protocol and is intended to provide endto-end protection for communications based on datagramoriented transporting service. Since UDP is more suitable for WSNs than TCP (where nodes have to deal with heavy congestion control, retransmissions, etc.) and as CoAP relies on it, numerous solutions target DTLS protocol to fulfill the security requirement for IoT’s applications. In [14] authors propose to apply DTLS in the IoT where the main principle of the proposition is to use DTLS as it is defined. However, like TLS, DTLS is quite heavy and complicated because it uses several sub-protocols and requires a lot of signaling messages, in addition to the asymmetric cryptography used in its security handshake. In order to overcome such problems, the solution suggests that the sensor nodes adopt the Trusted Platform Module (TPM) module, which is a hardware accelerator of RSA cryptographic operations. This solution has the advantage that it does not alter the standard protocol. However, the major shortcoming of this solution is that it is not aware about the severe energy constraint of the sensor nodes. Besides that, the proposed solution is purely hardware and consequently, it is expensive enough. In [15,16], authors propose 6LoWPAN compression for DTLS headers. The sub-protocols concerned by the

240

Please cite this article as: S. Sahraoui, A. Bilami, Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.08.002

241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263

JID: COMPNW 4

264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322

ARTICLE IN PRESS

[m3Gdc;August 22, 2015;20:28]

S. Sahraoui, A. Bilami / Computer Networks xxx (2015) xxx–xxx

compression are the basic protocol and ClientHello and ServerHello messages in handshake protocol. The communication scenario assumes that even the Internet hosts communicating with sensor nodes in the 6LoWPAN use DTLS. The proposed solution reduces significantly the communication costs in terms of energy dissipation and network overhead. But the computational cost of the cryptographic primitives remains very important on end-sensor nodes, especially if we consider the automatic key agreement mode. Additionally, the assumed scenario occurs rarely, as ordinary Internet hosts use usually TLS. Authors in [17] propose a solution that uses DTLS to secure end-to-end communications between a sensor node and an Internet host, while protecting the 6LoWPAN network against DoS attacks that may be launched by malicious Internet hosts that intend to overload the sensor node by forcing it to open too many sessions, which leads to an excessive consumption of memory and energetic resources, causing the unavailability of the service. This protection is materialized by the introduction of peer authentication at network level between the base station and the Internet host. As DTLS is poorly supported in classical Internet, authors assume that TLS is used in the Internet host side, and since the proposed solution involves DTLS in the 6LoWPAN network side, the base station should perform message mapping between TLS and DTLS according to well-determined rules. Although the delegation of translation task to the powerful base station (that is supposed to be a fully-trusted center), the constrained sensors handle long DTLS messages with the same sizes and the same computational complexity, which is a major drawback of the solution. In [18], a security adaptation framework is proposed for DTLS. In addition to header compression proposed in [15], the framework supports constrained device-friendly session resumption, and compact certificates based on ECC for efficient authentication and key agreement. The framework includes also a hardware acceleration engine to tackle the computational complexity of public key cryptography within the constrained smart objects. This solution promotes the adaptability of DTLS security for the IoT by means of a mixture of software and hardware techniques. 2.3. IKEv2/IPsec based solutions In this class of solutions, IPsec (Internet Protocol security) [19] protocol is used to guarantee end-to-end security at network layer for the IoT. IPsec represents a secure encapsulation for the standard IP and can operate in transport (for end-to-end security) or tunnel (gateway-to-gateway protection) modes. Authors in [20] propose to use IPsec protocol in its transport mode for the IoT. The solution presents a 6LoWPAN compression extension to support the compression of the headers of IPsec’s sub-protocols AH (Authentication Header) [21] and ESP (Encapsulating Security Payload) [22] which provide respectively the authentication, integrity and data confidentiality services for IP datagrams. Commonly, IPsec protocol is coupled with IKE (Internet Key Exchange) [19] protocol that operates in application layer and manages the negotiation of security associations (SA) (including cryptographic keys, ciphering algorithms, authentication algorithms) that will be used later in the secure

exchange of IP dtagrams between two hosts. We note also that the key exchange in IKE can be either static (configuration with pre-shared keys) or automatic (dynamic security establishment across the exchange of messages and performing complex computations). Authors have considered in their solution the static mode, where symmetric keys are manually pre-loaded into the communicating entities, in order to avoid the heaviness of the automatic mode. Since IKE in automatic mode is more flexible and scalable and consequently more adapted to IoT environments, authors specify in [23] a 6LoWPAN compression extension to support the compression of IKE headers, in order to mitigate the communication energetic costs while benefiting from the automatic key exchange of the protocol. However, the computational costs remain very important for the constrained sensor nodes, regarding the complex asymmetric cryptographic operations required for the computation of the session key. Moreover, the compressed IKE has not been evaluated with the proposed compressed IPsec, for optimal efficiency of the communication energy. In the same context, authors in [24] propose to entrust all the required computational primitives in IKE to the base station to offload the terminal sensor nodes from the heaviness of the IKE’s security. Nevertheless, the proposed solution suffers from fake sink vulnerability, in addition to the exposure to serious fault tolerance problems when the base station undergoes any hardware or software failure. Note that in such a case, no connection with the external Internet hosts is possible for all the WSN nodes. In order to deal with the expensive application of IKE with the automatic mode, in the IoT, authors propose in [12] a collaborative scheme that distributes the computational load over a set of powerful assistant proxies to amortize the related energy consumption. The proposed solution shares the same drawbacks with the collaborative TLS solution that we have already discussed in the TLS based solutions.

323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358

2.4. HIP based solutions

359

HIP (Host Identity Protocol) [25,26] protocol is an alternative solution to IKE/IPsec. HIP operates just above the IP layer and introduces a host identification scheme that decouples the identification from location information. Accordingly, applications reference hosts by their identifiers, generated cryptographically, instead of the corresponding IP addresses that inform about the physical location of the hosts. Thereby, HIP facilitates the mobility and ensures anonymous locations for end users, which is generally highly recommended in the majority of the applications of the Internet of things. HIP defines a security handshake mechanism called Base Exchange (HIP-BEX). This mechanism establishes dynamically security associations between HIP peers in the Internet. Only four messages are needed for secret key negotiation (the semantics and the contents of such messages, as well as, the scenario of HIP-BEX are discussed in detail, in further sections). Moreover, each HIP peer should have a public key serving as a host identifier (HI), whose private counterpart is known and used only by its legitimate owner. These two keys are useful for identity proofing and authentication aims. Once HIP security session is established, the end-parties can start exchanging data, securely using ESP

360

Please cite this article as: S. Sahraoui, A. Bilami, Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.08.002

361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381

JID: COMPNW

ARTICLE IN PRESS

[m3Gdc;August 22, 2015;20:28]

S. Sahraoui, A. Bilami / Computer Networks xxx (2015) xxx–xxx

382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442

[27] sub-protocol of IPsec protocol and the session secret key negotiated with HIP. In fact, HIP-BEX mechanism involves heavy asymmetric cryptographic operations and for this reason, it cannot be supported as it is by constrained sensor nodes. Therefore, several solutions have been proposed to lighten HIP and, make it more adapted. In [28], authors proposed HIP Diet Exchange (HIP-DEX) to reduce the computational cost of HIP-BEX by introducing elliptic curve cryptography in Diffie– Hellman policy ECDH (Elliptic Curve Diffie–Hellman). Only one public key is needed to compute the session key and to identify the HIP peer. Therefore, the detention of the session key is sufficient enough to authenticate the node and to prove its legitimacy. Although the proposed solution seems quite simple and lightweight, the alteration of message formats in the standard HIP, by eliding certain fields, may introduce incompatibility problems during session establishment with Internet hosts using the original HIP. Moreover, ECC (Elliptic Curve Cryptography) operations adopted by Diet-HIP are still onerous for severely constrained sensors. In [29], authors propose a trivial and intuitive variant of HIP protocol when it is running on WSN side. LHIP (Lightweight HIP) keeps the same syntax of HIP-BEX messages and, provides a security mechanism that focuses only on hash functions to check the integrity of the exchanged messages. Accordingly, the fields carrying keys and other security information are maintained and communicated in the messages but, they are ignored by the peers. While being compatible with the standard HIP, LHIP security is judged weak as it omits primordial security mechanisms as the mutual authentication and key exchange. To deal with the computational complexity of HIP-BEX’s primitives, authors in [30] propose to distribute the most expensive operations in the secret key generation over a group of closer and less constrained proxies. The authorization and authentication of the involved proxies are performed using one-way hash functions. Each proxy computes a sub part Ki of the entire session key K, in a parallel fashion, and delivers it to the terminal sensor node. This later will then accumulate all received sub keys to obtain the final secret. The solution has the advantage of reducing considerably the processing costs. However, the communication energy costs in the WSN rise importantly, as there is an important amount of uncompressed messages to be exchanged. Another drawback of the solution revolves around the difficulty of managing the reliability of the communications with the proxies, and the complexity of monitoring the behaviors of the proxies themselves. We underline also that the proposed distribution model is explicit to the external Internet host; this latter is aware of the interposed assisting nodes (it receives and sends information from and to them), which is not really convenient. Even though HIP (or Diet-HIP) requires few signaling messages to set up a secure connection between two terminals in the Internet, these messages are very long and we cannot ignore the expensive cost in terms of energy consumption and fragmentation/reassembly rate resulting from the communication of such messages within a 6LoWPAN network. In order to overcome this problem, authors in [31] propose a compressed layer for Diet-HIP, named Slimfit. Some fields in the header and in signaling parameters are concerned by the compression so that the communication cost can be as re-

5

duced as possible. The evaluation results prove that the proposed compression model allows a lower packet fragmentation rate and less energy consumption. However, the solution still suffers from compatibility problems with the standard HIP (as mentioned above) in addition to the computational complexity that remains relatively important, when it is completely handled by constrained sensor nodes. Another drawback lies in the fact that the given compression is not standardized according to the 6LoWPAN compression rules. Another Diet-HIP-based security solution is proposed in [32]. In addition to HIP-DEX key exchange process, the solution relies on another lightweight key management scheme named AMIKEY (Adapted Multimedia Internet KEYing) [33] to generate pair-wise keys. It is assumed in the solution that each IoT domain has a central manager. Thus, each smart device in the IoT domain establishes a secure session with the domain manager using HIP-DEX handshake. AMIKEY allows the smart devices to set up end-to-end security sessions between them. Indeed, the communication costs may be important since the Internet-connected sensor has to exchange several uncompressed signaling messages. Also, the adoption of two security mechanisms (HIP-DEX and AMIKEY) may be computationally expensive for the IoT devices. In Table 1, we summarize through the comparison, the principal characteristics of the proposed works defined in each class of solutions. The comparison criteria encompass the main adaptation technique adopted by the solution to make possible the projection of the basic IP security protocol into WSNs, and whether the adaptation style is software or hardware, as well as, the induced adaptation cost. The reviewed solutions are also compared based on the induced communication and the computational costs, and if the solution demands translations to be performed by the border router 6BR, in the case of the employment of incompatible protocols (in WSN and Internet). We consider also the amount of required signaling messages in the solution, and if the protection of the whole WSN and/or the terminal sensor nodes (servers) against DoS attacks are supported. Finally, we observe a no less important criterion that is the fault tolerance feature in each solution.

443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482

3. Motivations and problem statement

483

In this section we present the motivations behind the election of HIP as an infrastructure of our proposals for efficient end-to-end security in the Internet of things. Then, we express the problematic and the major shortcomings of the existing solutions leading to the proposed solution. For effective end-to-end security of the transactions between sensor nodes and ordinary Internet hosts in the future Internet, we suggest the adoption of HIP/IPsec (ESP) security protocols. The arguments of this suggestion are:

484

• With identification/location information split, HIP inherently facilitates end-users mobility and ensures a good level of location privacy, which is highly recommended in many IoT deployments, as in health care and military applications. Such beneficial features are not defined in other non-HP security protocols, which rely for the identification of the peers on the corresponding IP addresses that explicitly inform about the physical locations.

Please cite this article as: S. Sahraoui, A. Bilami, Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.08.002

485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500

ARTICLE IN PRESS

JID: COMPNW 6

[m3Gdc;August 22, 2015;20:28]

S. Sahraoui, A. Bilami / Computer Networks xxx (2015) xxx–xxx

Table 1 General comparison between the existing solutions for end-to-end security in the IoT. E2E security solution

Basic protocol

Operational layer

Main adaptation technique

Adaptation style

Adaptation cost

Communication cost

Computational cost

Translation in the 6BR

Amount of signalling messages

Protection against DoS attacks

Fault tolerance

[11]

TLS

Transport

Software

__

+

_

x

+

Server only

__

[12]

IKE & TLS DTLS

Application & transport Transport

_

[14]

Security delegation Security distribution Security acceleration Header compression message mapping between TLS and DTLS Header compression & security acceleration Header compression Security delegation Adoption of ECC cryptography Security degradation Security distribution Messages compression Lightweight key management

[15-16]

DTLS

Transport

[17]

DTLS

Transport

[18]

DTLS

Transport

[20-23]

IPsec & IKE

[24]

IKE

Application & network Application

[28]

HIP

HIP layer

[29]

HIP

HIP layer

[30]

HIP

HIP layer

[31]

HIP

HIP layer

[32]

HIP

HIP layer

Software

__

++

__

++

Server only

Hardware

++

+

_

x

+

Server only

Software

__

_

++

x

+

Server only

Software

__

+

++

xx

+

Server & WSN

Software & hardware

+

_

_

x

+

Server only

Software

__

_

++

+

Server only

Software

__

+

__

+

Server only

Software

__

+

+

_

Server only

Software

__

+

__

_

Not supported

Software

__

++

__

Software

__

_

+

Software

+

++

+

x

x

__

__

+

Server only

_

_

Server only

_

+

Server only

_

Where +, ++, _, _ _, x, xx denote respectively: important, very important, low, very low, may be required, required.

501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532

• HIP provides a flexible key agreement mechanism that demands a slight amount of messages to be exchanged between the peers (only four messages). This is not the case with other protocols, such as DTLS that may require the exchange of more than ten signaling messages in the security handshake. • The adoption of HIP to secure WSNs applications is recently gaining attention [34,35]. • Enabling end-to-end data security in network layer by means of IPsec protocol (whether it is coupled with HIP or IKE) allows securing all types of transported traffic. In other words, IPsec can be employed to secure applications that are founded on TCP or UDP with no need for undesirable translations between incompatible security protocols, in the gateway. Despite its various advantages, HIP protocol cannot be adopted as it is by WSNs since it was initially tailored for unconstrained IP networks. Indeed, the communication of long messages and the computation of the expensive asymmetric cryptographic operations for establishing the security association between HIP peers, present the main sources of high energy dissipation, memory overloading and processing resources exhausting. Consequently, the development of some relevant adaptation schemes for HIP protocol has been necessary to safely extend it to the constrained IP-enabled networks, like 6LoWPAN networks, in the Internet of things. In fact, all HIP-based solutions (even the other solutions) focus ideally either on messages compression or on the distribution and the delegation of the computational load introduced by the key agreement process to deal with communication overhead or security complexity, respectively. Therefore, these solutions are insufficient as they do not

provide an optimized adaptability and effective energy and scarce resources awareness. In order to address this problem, we propose in the current work, two appropriate adaptation techniques: a 6LoWPAN compression model for HIP header as well as, an efficient distribution system of HIP security. These two mechanisms are further combined together for an optimized adaptability, constraints awareness and reduced energetic costs for HIP protocol, in Internet-integrated WSNs. 4. The proposed solutions for lightweight end-to-end security in the IoT The material and technological heterogeneity in the Internet of things creates a serious obstacle for the generalization of the approved security solutions of today’s Internet to encompass all joining networks, such as WSNs. In this work, we propose two solutions to tackle the heterogeneity in terms of communication and computational capabilities between Internet hosts and sensor nodes in the IoT, while ensuring effective end-to-end security. In this section, we detail our proposals that involve an optimal 6LoWPAN compression model for HIP header, and an efficient distribution scheme for the HIP’s key exchange HIPBEX. For an extremely lightweight end-to-end security, we propose to combine the two mechanisms in HIP when it is running on the WSN side. The resulting protocol variant is named CD-HIP for Compressed and Distributed HIP. Indeed, when designing end-to-end security solutions for the Internet of things, a special care should be taken to preserve the robustness of the security while dealing with constraints-awareness. In other words, a tradeoff between security and energy efficiency should be realized. Moreover,

Please cite this article as: S. Sahraoui, A. Bilami, Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.08.002

533 534 535 536 537 538 539 540

541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562

JID: COMPNW

ARTICLE IN PRESS S. Sahraoui, A. Bilami / Computer Networks xxx (2015) xxx–xxx

563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618

any alterations that could be carried on IP-based security protocols (HIP in our case), in order to make them suitable for WSNs, should not affect the compatibility with the original standard protocols which are still operational in the Internet. This will further enable the avoidance of translations between different protocols by an interposed proxy which breaks and contradicts the principle of the end-to-end security. So, the three main requirements that should be fulfilled when tailoring end-to-end security solutions for the Internet of things are: • Robust end-to-end security. • Constraints awareness and energy reservation. • Compatibility with the standard IP-based security protocols. 4.1. The proposed 6LoWPAN compression for HIP header The compression is an important and efficient optimization technique. Currently in the Internet of things, this technique is indispensable to overcome the big differences in capabilities of IP networks and WSNs, especially in terms of traffic admission ability and the maximum possible size of the protocol data unit in both networks (minimal MTU of 1280 bytes in IPv6 networks and only 127 bytes in IEEE 802.15.4 based 6LoWPANs). In this context, the 6LoWPAN adaptation layer specifies how IPv6 datagrams can be compressed and fragmented so that they could safely fit in Internet-integrated WSNs. Thus, the compression/decompression and the fragmentation/reassembly of all incoming/outgoing IPv6 packets are performed by the 6LoWPAN Border Router (6BR). The compression technique has several interesting advantages, among which we cite: • Minimal communication overhead: the compressed packets have a reduced length and a lower amount of information will be communicated. • Lower energy consumption for the communication of the compressed messages. • Short communication delays. • Lower packet fragmentation rates: the reduced sizes of the compressed packets help to mitigate the fragmentation frequency. • Reduced need for storage space. • Optimization of the effective throughput: by the revocation of unnecessary control information from packet’s header, data throughput will be eventually improved since a significant space in the message will be free to contain the applicative data. The first part of our solution represents a proposition of the first 6LoWPAN compression extension for HIP header to reduce the communication costs of HIP packets in WSNs. In this section we highlight this solution but before doing so, we give at first an overview of 6LoWPAN compression principles then, we discuss the compressibility of HIP header. 4.1.1. Overview of 6LoWPAN compression The IPv6 header (40 bytes) carries a substantial amount of compressible fields (IPv6 source and destination addresses, next header, length, and many others [36]), that can be either

[m3Gdc;August 22, 2015;20:28] 7

completely elided or just reduced by means of the compression. Note that the hop limit (1-byte) is the only field that is generally not concerned by the compression. Also, if an IPv6 address is not completely elided, it may be reduced either to 64 bits extended or 16 bits short IEEE 802.15.4 addresses. In fact, the 6LoWPAN standard defines a set of rules that should be respected. Systematically, the compressed header must be preceded by encoding bytes (generally one unique byte) used to identify the protocol header and to encode the set of its compressible fields. These encoding bytes are directly followed by the reduced and the uncompressed fields. The resulting compressed header includes fewer and only necessary information and consequently, the header size decreases considerably. Indeed, the 6LoWPAN compressed IPv6 header can be reduced down to 2 bytes (1-byte dispatch, 1-byte IP Header Compression (IPHC) encoding) in the case of single hop communications within the same 6LoWPAN network, and can reach till 7 bytes (1-byte dispatch, 1-byte IPHC encoding, 1-byte Hop Limit, 2-bytes source address, 2bytes destination address) in case of multiple IP hops communications between two communicating sensor nodes in the same sub-network. When one of the two communicating entities is outside the 6LoWPAN, the header size may reach 21 bytes (1-byte dispatch, 1-byte IPHC encoding, 1-byte Hop Limit, 2-bytes source/destination address [37], 16-bytes destination/source address). Fig. 1 depicts the discussed best cases of the 6LoWPAN compressed IPv6 header. The 6LoWPAN compression mechanism does not concern only the IPv6 header, but it may concern also its extension headers [36,20] and the next headers, like UDP header that can be compressed from 8 bytes to 5 bytes. Since UDP header does not include a next header field, it was necessary to compress headers of upper layer protocols, like DTLS and IKE, as part of UDP payload. This 6LoWPAN compression variant is named 6LoWPAN-GHC [38]. 4.1.2. HIP header compressibility HIP protocol defines eight types of messages, four of them (I1, R1, I2, R2) are mandatory for the HIP-BEX process. The role, the semantics, and the exchange order of these four HIP messages are discussed in detail, in Section 4.2.2. The remaining HIP messages (UPDATE, NOTIFY, CLOSE, CLOSE_ACK) are used for various purposes. HIP UPDATE massage is used to update some information related to the HIP session (e.g. we may imagine an update message carrying information that the HIP peer should combine with the current session key so that to renew it). A HIP host sends the optional notification message (NOTIFY) to report eventual protocol errors or negotiation failure between the two peers. This message carries parameters that give more information about the notified problem. To announce session closing, a host prepares and sends CLOSE message. Upon the reception of CLOSE message, the host replies by a closing acknowledgement message (CLOSE_ACK) and it discards the session in question. Note that no data messages can be exchanged through the closed session and for any further secure communication between the HIP peers, a new HIP session must be established. All HIP packets have a fixed header of 40 bytes. The typical HIP header structure is illustrated in Fig. 2. The HIP header has an important size and contains considerable unnecessary and redundant information. Indeed,

Please cite this article as: S. Sahraoui, A. Bilami, Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.08.002

619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678

ARTICLE IN PRESS

JID: COMPNW 8

[m3Gdc;August 22, 2015;20:28]

S. Sahraoui, A. Bilami / Computer Networks xxx (2015) xxx–xxx

Dispatch (1 byte)

IPHC-encoding (1 byte)

(a) Dispatch (1 byte)

IPHC-encoding (1 byte)

Hop-limit (1 byte)

Source-addr (2 bytes)

Destination-addr (2 bytes)

(b) Dispatch (1 byte)

IPHC-encoding (1 byte)

Hop-limit (1 byte)

Source-addr (2 bytes)

Destination-addr (16 bytes)

Source-addr (16 bytes)

Destination-addr (2 bytes)

(c) Dispatch (1 byte)

IPHC-encoding (1 byte)

Hop-limit (1 byte)

(d) Fig. 1. The 6LoWPAN compressed IPv6 header with (a) local direct communication, (b) local multihop communication, (c) the source belongs to the 6LoWPAN network and the destination is outside the network (d) the source is outside the 6LoWPAN network and the destination is inside the network.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4567 890 1 Next header Header length Checksum

0

Packet type VER. Controls

RES.

1

Sender’s Host Identy Tag (HIT) (128 bits)

Receiver’s Host Identy Tag (HIT) (128 bits)

Fig. 2. The fixed header of HIP packets.

679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705

the header length field that reveals the length of HIP header (excluding the first 8 bytes) and HIP parameters. This information is static for each type of HIP packet, and can be deduced from lower layers (e.g. MAC layer) by cumulating the lengths of the frames (precisely, the lengths of the MAC service data units) corresponding to the same HIP packet, with the subtraction of the excluded 8 bytes. Consequently, the header length byte can be compressed. The protocol version field (VER.) can be revoked because we suppose that the HIP peers use the latest stable version (version 2 currently). In the case of different versions, we may still assume that all 6LoWPAN nodes use the same version of the protocol HIP. In this case, the version field could be safely compressed in all outgoing packets (generated by the sensor nodes) and carried unchanged in the incoming packets (arriving from Internet side). In our solution, we consider only the first supposition when the peers use the same and latest stable version. Additionally, the three reserved bits (RES.), which are reserved for future use and always set to zero, can be eliminated. Thus, the incoming IPv6 datagrams carrying the HIP packets will be fragmented in the 6LoWPAN layer. So, it will be unnecessary to keep the original checksum value. Consequently, checksum field can be removed from HIP header in WSN side, and its computation and verification may be delegated to the 6BR. Also, the communication error checking for each related 6LoWPAN fragment is implicitly supported

in the FCS (Frame Check Sequence) field of the encapsulating MAC frame. Only one bit (A-bit) is used in the controls bit array (16 bits). This bit indicates whether the host identifier information is anonymous in the current HIP packet and whether it should be stored or not by the peer. As we attend to extend HIP to a constrained environment (WSNs), it is typically more convenient to revoke the management of the anonymous entities, in order to avoid the likely induced overhead. Accordingly, the entire array can be safely removed. The two fixed bits 0 and 1 in the header serve for compatibility management and must be set only in implementations adhering to particular specifications and therefore, they can be eliminated. The remaining compressible fields in the header are the sender’s and the receiver’s HIT (Host Identity Tag) fields that are both 128 bits long. The HIT is a concise representation of the Host Identifier, it has the same length as an IPv6 address and allows the applications operating over IPv6 to function transparently over HIP. HIT is made up of three subparts, which are: (1) a fixed 28 bits serving for the distinction of HIT from an Ipv6 address and, (2) the HIT generation algorithm indicator (4 bits). (3) The rest of 96 bits representing a hash value of the host identifier information using the corresponding generating algorithm. According to [30], HIT fields can be reduced to 96 bits, by omitting the HIT prefix (the first 32 bits) and maintaining only the relevant hash value. The

Please cite this article as: S. Sahraoui, A. Bilami, Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.08.002

706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732

ARTICLE IN PRESS

JID: COMPNW

[m3Gdc;August 22, 2015;20:28]

S. Sahraoui, A. Bilami / Computer Networks xxx (2015) xxx–xxx

11001

NH

S-HIT

R-HIT

5 bits

1 bit

1 bit

1 bit

Fig. 3. The proposed 6LoWPAN encoding byte for HIP Next Header Compression.

733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783

sender’s HIT can even be completely elided in R1 and I2 messages (see Fig. 6) which carry the source host identifier information. The packet type field is always carried in-line with five bits long, rather than seven bits, as there are eight types of HIP messages, where the maximal value is 19 (the packet type values in I1, R1, I2, and R2 messages are respectively 1,2,3, and 4. With UPDATE, NOTIFY, CLOSE, and CLOSE_ACK, the packet type field takes the values 16, 17, 18, and 19 respectively). 4.1.3. The proposed 6LoWPAN compression model Logically, HIP header is considered as IPv6 extension header. Therefore, we propose a 6LoWPAN Next Header Compression for HIP header (LOWPAN_NHC_ HIP). The proposed encoding byte of the compressed HIP header is defined in Fig. 3. • The first five bits represent the NHC ID (Next Header Compression IDentifier) field. We set its value to 11001. In fact, the NHC ID bits serve for the unique identification of the compressed HIP header among all the already existing compressed 6LoWPAN headers of the different protocols (IPv6, UDP, IPsec, DTLS, IKE). According to the 6LoWPAN standard [38], there is no restriction on the length or the value of the NHC ID. However, we should guarantee its uniqueness to avoid the possible identification confusions. The NHC ID 11001 is not currently attributed in the 6LoWPAN standard (the existent ID values are: 011 and 11110 for IPv6 and UDP compressed headers respectively [38]. 11011 for UDP payload compression [16]. 1110101 and 1110110 for ESP and AH headers compression [20]. 1000, 1001, 1010 and 1011 for DTLS headers compression [15]. 1101 for IKE 6LoWPAN compression [23]). • NH (next header): if 0: the next header field is removed: the case when HIP header is the final header, as specified in [25–26] and it is generally the case. Otherwise, if set to 1, the next header field is carried in-line; there is an extension header or data following the HIP header, as clarified in [39]. • S-HIT (sender’s HIT): if 0 the sender’s HIT field is reduced to 96 bits. Otherwise, if 1, the field is skipped (in R1 or I2 packets). • R-HIT (receiver’s HIT): always set to 0, to indicate that the receiver’s HIT field is compressed to 96 bits. The standard structure of HIP packets with the proposed header compression model is represented in Fig. 4. Indeed, the compression and the decompression of HIP packets are both handled by the border router. Upon the reception of each HIP packet from an Internet host, the border router checks at first, the validity of its checksum. If the computed checksum does not match with the received one then, the packet is rejected. Otherwise, if the checksum is valid, the border router removes the fields and bits concerned by the

9

compression from the HIP header, as dictated in the proposed compression model. After a successful header compression, the entire HIP packet is then split into several small fragments according to the 6LoWPAN fragmentation rules [6]. Finally, the 6BR communicates the resulting HIP fragments in the WSN towards their final destination. Conversely, when the border router receives a compressed HIP packet, typically divided into numerous frames, from a sensor node, it reassembles the fragments corresponding to that same HIP packet. Then, it decompresses the related header in order to construct the original uncompressed HIP header, containing all the bypassed fields. Systematically, the 6BR adds the header length field containing the appropriate length, and expands the packet type field to its full size (7 bits). Also, the border router appends the protocol version information (HIP version 1 in our case), the reserved bits and the two fixed bits (0 and 1). At this stage, the border router computes the checksum as dictated by the standard [25,26], and places its value in the checksum field (16 bits). It adds also the controls bit array with the bit A set to 0 because we do not manage the anonymity of the host identifiers in the WSN, like previously clarified in Section (4.1.2). Thus, the sender’s and receiver’s HITs are both re-extended to 128 bits long by adding the HIT prefix information. Finally, the HIP packet is ready to be communicated over the Internet to reach its final destination (the remote Internet host acting as a HIP peer). The compression and the decompression mechanisms are illustrated in Fig. 5. Table 2 summarizes the effect of the proposed compression on each field of the HIP header. Table 3 presents the communication overhead of HIP header with and without the proposed compression model, as well as the related proportional gains. The proposed 6LoWPAN compression for HIP header presents a beneficial solution for decreasing significantly the communication overhead, memory footprint, as well as energy dissipation. This results from the minimal overall amount of communicated and stored information in the compressed HIP messages. Indeed, from Table 2, we realize that HIP header can be reduced to 13 bytes in R1 and I2 messages and can reach till 25 bytes in all remaining HIP messages, the table below compares the communication overhead for HIP header communication in both cases: with and without the proposed header compression scheme. The proposed 6LoWPAN compression model provides an important proportional gain of 52% in terms of the communicated bytes in the HIP-BEX handshake. For the overall HIP packets communication, the gain comes around 45%, which is therefore, acceptable enough. 4.2. The proposed distribution scheme for HIP base exchange The compression alone is not sufficient for a full lightweight adaptation of IP-based end-to-end security protocols for WSNs because of the involved heavy cryptographic operations required for the secure session establishment. As we are interested in our work to HIP protocol as a basic infrastructure, we propose in the second part of our solution an adapted distribution scheme for HIP key agreement (the HIP Base Exchange: HIP-BEX). The purpose of the distribution is to disperse the expensive cryptographic load in order to

Please cite this article as: S. Sahraoui, A. Bilami, Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.08.002

784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843

ARTICLE IN PRESS

JID: COMPNW 10

[m3Gdc;August 22, 2015;20:28]

S. Sahraoui, A. Bilami / Computer Networks xxx (2015) xxx–xxx

LOWPAN _NHC_ HIP Packet type (8 bits) (5 bits) Sender’s HIT (96 bits) Receiver’s HIT (96 bits) HIP parameters (variable)

Compressed HIP header

(a) LOWPAN_IPHC (16 bits) Source address LOWPAN _NHC_ HIP

Hop Limit Source address (8 bits) (16 bits) Destination address (16 bits) Packet type Sender’s HIT

Sender’s HIT

Receiver’s HIT

Receiver’s HIT

HIP parameters

Compressed IPv6 header

HIP packet (compressed header + parameters)

(b) Fig. 4. The proposed 6LoWPAN compressed HIP header within (a) the HIP packet and (b) the compressed IPv6/HIP datagram. The IPv6 header is compressed according to the case of a local multiple IP hops communication between the two communicating entities.

Fig. 5. Schematization of the communication of HIP packets to (1) and from (2) the WSN in the context of the IoT, with the proposed compression model. Table 2 HIP header fields before and after the proposed 6LoWPAN compression. HIP header field

Length before compression (bits)

Length after compression (bits)

Next header Header length Packet type VER. RES. 0,1 Checksum Controls Sender HIT Receiver HIT Header length

8 8 7 4 3 2 16 16 128 128 40 bytes

0 or 8 0 5 0 0 0 0 0 0 or 96 96 Min = 13 bytes, Max = 25 bytes

Table 3 Total HIP header communication overhead with and without the proposed 6LoWPAN compression.

HIP-BEX (four packets) All HIP packets (eight packets)

Without compression (bytes)

With compression (bytes)

Proportional gain (%)

160 320

76 176

52 45

Please cite this article as: S. Sahraoui, A. Bilami, Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.08.002

JID: COMPNW

ARTICLE IN PRESS S. Sahraoui, A. Bilami / Computer Networks xxx (2015) xxx–xxx

[m3Gdc;August 22, 2015;20:28] 11

HIP Responder

HIP Initiator

I1 R1 : puzzle, DHR (A), HIR, sign Check sign, find solution Compute session key b (A mod p) I2 : sol, DHI (B), HII, sign

Check sign, Check solution Compute session key a (B mod P) Compute MAC_Ksession R2 : MAC(sessionKey), sign Check sign Chek MAC

Fig. 6. HIP-BEX handshake process.

844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874

offload the terminal sensor nodes which are severely resource-constrained (limited energy, low memory and computational power), and also render the security cost much more reasonable. 4.2.1. Overview of Diffie–Hellman key agreement Before detailing the HIP-BEX scenario and the proposed distribution, it is worthy to give at first a brief overview of the core mechanism to which the HIP key agreement refers for the generation of a shared secret key between the HIP peers. This mechanism is Diffie–Hellman protocol [40], the most popular dynamic key agreement protocol in IP-based networks. Before establishing the secret, the protocol requires that two entities Alice and Bob negotiate on a prime (p) according to well-determined criteria, and a generator (g). Then, Alice and Bob choose randomly and independently the initial secrets a and b (their values are expected to be sufficiently large) and compute their public keys A = (ga mod p) and B =(gb mod p). Thereafter, each entity communicates its public key to the other so that they could generate the final session secret key through the computation of (Ba mod p) and (Ab mod p) by Alice and Bob respectively, according to the asymmetric cryptographic basis. The robustness and the security of Diffie–Hellman key exchange process comes from the difficulty and the computational impossibility of deriving the secret key by malicious eavesdroppers having as information g, p, ga and gb , this is why these measures are not protected by their owners and can be communicated in clear, which presents major advantage of the protocol. 4.2.2. HIP base exchange The standard HIP provides an authenticated key agreement mechanism, named HIP Base EXchange (HIP-BEX),

based on Diffie–Hellman key exchange protocol. The HIP-BEX allows HIP peers to negotiate a shared secret that will be thereafter used to secure communications from end to end. The HIP-BEX scenario is illustrated in Fig. 6. First, the initiator peer initiates the exchange by sending the message I1 that is empty (it carries only the HIP header). On the reception of I1, the responder replies by R1 message that includes its Diffie–Hellman public key (DH), as well as, its host identifier (HI) and a cryptographic puzzle used to prevent DoS attacks. For peer authentication, the message is signed using the private key corresponding to HI public key. Upon the reception of the R1 message, and after the verification of the message signature, the initiator computes the Diffie–Hellman session key then, it sends a signed message I2, in which it gives the puzzle’s solution, in addition to its relevant cryptographic information (DH and HI). Once I2 message is received by the responder, this last checks the validity of the signature and the puzzle’s solution. After that, it computes the secret key and proves the ownership of the secret key to the initiator via a MAC (Message Authentication Code) derived from the computed secret key, and communicated in a final message R2. The Initiator, in its turn, checks the signature of R2 message and verifies the consistency of the MAC code, which leads (if all goes well) to session key validation. It is worth mentioning that even though the signatures of HIP messages have a non-negligible computation overhead, Diffie–Hellman computations that are required for the generation of the Diffie–Hellman public keys and the Diffie–Hellman session key, are the slowest and the most energy consuming operations in the HIP-BEX process [41,42]. From this point of view, and for compatibility and interoperability reasons, we continue to utilize the standard HIP-BEX in our solution, with

Please cite this article as: S. Sahraoui, A. Bilami, Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.08.002

875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907

JID: COMPNW 12

ARTICLE IN PRESS

[m3Gdc;August 22, 2015;20:28]

S. Sahraoui, A. Bilami / Computer Networks xxx (2015) xxx–xxx

Fig. 7. The network model assumed in the proposed solution.

908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946

unchanged security parameters for WSNs, while alleviating its computational heaviness. 4.2.3. Network model and assumptions In our solution, we consider a heterogeneous 6LoWPAN network connected to the Internet. We assume the existence of three types of operational entities: • One 6LoWPAN border router (6BR) entity playing the role of a fully trusted edge router and the relay point between the two networks (6LoWPAN and the Internet). • RFD (Reduced Function Device) nodes: highly resourceconstrained sensor nodes, which may not support the expensive asymmetric cryptographic primitives. • FFD (Full Function Device) nodes: trusted powerful and unconstrained nodes, which are situated in the neighborhood of RFD nodes. These nodes are able to perform complicated computational tasks, to mitigate the heterogeneity in the computational capabilities between RFD nodes and the regular Internet hosts. FFD nodes may have 6BR resources similarities and may be mains powered. Also, they should be covered by the topology that constructs the routing protocol RPL, and included in the communication paths linking the final RFDs and the 6BR. We underline that if no FFD node is interposed between an RFD node and the 6BR (if for example they are directly connected or if the FFD node is excluded from the network due to a breakdown), the 6BR, in this case, behaves as an FFD node for this RFD sensor node. Fig. 7 illustrates the considered network model. 4.2.4. The proposed distribution model The HIP key agreement process involves expensive computational operations for both the initiator and the responder. The fact that the terminal entities are often computationally heterogeneous in the IoT, it is strongly necessary to introduce an efficient mechanism that lightens the security overhead in the WSNs part. The central idea of the proposed distribution mechanism for HIP security handshake (HIP-BEX) is to securely and transparently introduce a trusted third party between the terminal sensor node and the remote peer. This third

party is represented by a powerful collaborator node (FFD in the 6LoWPAN), which collaborates with the end-sensor node to decentralize and balance the computational load. This is achieved by the delegation of the most CPU-requiring cryptographic operations in HIP-BEX to the HIP collaborator node. The operation of the proposed distribution model is divided in three main phases: the initial phase, end-to-end security establishment phase and intrusion detection phase. 4.2.4.1. Initialization phase. This phase initiates and prepares the involved entities, as well as, the required security credential for the proposed distribution model in the network bootstrapping. The initialization phase includes the network deployment, and the safe pre-charging of the shared network key in all network nodes (performed by a network administrator), according to the MAC layer security defined by the standard IEEE 802.15.4 [43]. This key serves for further in-network authentications and for the protection of the internal communications between end-sensors and the assisting nodes. Besides, the network shared key can be refreshed periodically, in order to resist to key-recovery and leakage threats that expose the network to intrusion risks. At this stage, it is important to note that this phase concerns only the 6LoWPAN network and the Internet hosts are not aware of what happens on the inside. That is to say that the proposed distribution is transparent to any outsider Internet host and only the 6LoWPAN nodes are aware of it. 4.2.4.2. Security establishment phase. In this phase, the Internet host and the terminal sensor node establish the HIP security association, according to the proposed collaborative HIPBEX. By considering a powerful Internet host initiator and a constrained sensor node responder, the proposed scheme is as described in Fig. 8. At first, the collaborator node (FFD) and the terminal sensor node (RFD) perform the mandatory mutual authentication, since they will exchange sensitive security information, by proofing the possession of the pre-shared network key. Also, the critical keying material being communicated between the two nodes is protected and ciphered using the same key.

Please cite this article as: S. Sahraoui, A. Bilami, Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.08.002

947 948 949 950 951 952 953 954

955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972

973 974 975 976 977 978 979 980 981 982 983 984 985

JID: COMPNW

ARTICLE IN PRESS

[m3Gdc;August 22, 2015;20:28]

S. Sahraoui, A. Bilami / Computer Networks xxx (2015) xxx–xxx

13

Fig. 8. The proposed secure distribution scheme for the computational load in HIP Base Exchange.

986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008

On the reception of I1 message, and after a successful authentication, the sensor node (the HIP responder) sends securely the required material for the computation of its Diffie– Hellman public key, to the collaborator. This last computes the public key A (see Fig. 8) and sends it to the corresponding sensor node. It is worthy to note that the computation of A may be done in proactive manner just after the mutual authentication. In this case, the HIP responder communicates the initial secret (a) to the collaborator beforehand, and the risk of secret extraction by a third malicious party will be relatively higher. Furthermore, once the secret is retrieved, the session key will be easily found (the attacker will just have to intercept I2 message and compute Ba mod p). For this reason, it is preferable to opt for a reactive computation of A, just after the reception of the initialization message I1. Moreover, on-demand computation of A will not considerably affect the HIP session establishment delay as the collaborator is more powerful and performs the delegated Diffie–Hellman computations much more rapidly than the terminal sensor node. At this stage, the responder prepares and communicates the R1 message signed to the initiator. While transiting from the initiator towards the corresponding responder in the 6LoWPAN, I2 message stops at the collaborator node that

checks its signature using the initiator’s public HIP host identifier (HI) and computes the session secret key on behalf of the responder (sensor node). Thereafter, the collaborator encrypts (using the network shared key) and communicates the computed Diffie–Hellman secret with the puzzle’s solution carried in I2, to the responder so that it verifies whether the solution matches with the corresponding puzzle. Finally, the responder computes the MAC value from the session key to confirm its correctness and sends the R2 message signed to the initiator. We underline that both R1 and R2 packets are signed using the responder’s private key (the private part of its HI). We note also that the communication between the collaborator and the responder is supposed reliable. As WSN nodes are subject to compromising risks, the collaborator may be compromised to alter or spy on the communication between the HIP initiator and the responder. To prevent this possible problem, we propose an optional countermeasure to be undertaken by the HIP peers to conceal the final session key from the collaborator. After getting the Diffie–Hellman session key, the HIP peers may eventually opt for the combination of this key with seed-key information. The seed would be for example, intelligently extracted from HIP host identifiers (HI) of the

Please cite this article as: S. Sahraoui, A. Bilami, Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.08.002

1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031

JID: COMPNW 14

1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050

ARTICLE IN PRESS S. Sahraoui, A. Bilami / Computer Networks xxx (2015) xxx–xxx

initiator and the responder, just to avoid the exchange of additional control messages. One possible method for the generation of the seed can be inspired from FHSS (Frequency Hopping Spread Spectrum) technique where, the transmitter and the receiver both agree, in advance, on a pseudo-random sequence corresponding to frequency channels on which the carrier will be spread for secure (and interference-resistant) communication. Accordingly, the HIP peers agree on a pseudo-random sequence representing the parts of the concatenation of the two HIP host identifiers. The corresponding parts should be properly linked to form the seed key. Note that it is better to define variable sizes for the several parts to reinforce the seed generation procedure. Finally, the combination of the obtained seed with the initial HIP session key can be done with a trivial cryptographic operation (e.g. XOR). This way, it will be difficult for the collaborator to guess the right seed even though it knows the public host identifiers (HI) of the HIP peers. Thus, the final HIP session key would be like:

HIPSessionKey = DHSessionKey ⊕ seed. 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089

[m3Gdc;August 22, 2015;20:28]

(1)

In addition to the advantages related to the collaborative feature that relieves the sensor node from the most expensive computational primitives in the HIP-BEX handshake (mainly the Diffie–Hellman exponentiations: ga and (gb mod p)a where the initial secret a is expected to be sufficiently large). The proposed system has another advantage residing in its transparency; the distribution is hidden to the external Internet host (in our case the initiator), in order to preserve the end-to-end security handshake image. 4.2.4.3. Intrusion detection phase. The use of the authentication technique to proof the legitimacy of the collaborator and the terminal sensor node, according to the cryptographic rules, serves for excluding any outsider adversary, which may attempt to impersonate a legitimate node (collaborator or ordinary sensor), to steal the session key, and likely exercise one or more possible attacks such as: the eavesdropping, replay attack and session hijacking. However, the mutual authentication alone does not provide an optimized security for the distribution model as WSN nodes deployed in an unattended area, and connected to the Internet, are likely prone to be compromised either physically or through running malware codes coming from the Internet. The compromised nodes attempt to exercise internal attacks, which are harmful because the internal attackers have the required security material, such as ciphering/authentication algorithms, the cryptographic keys, and benefit from any other permissions and responsibilities in the network (data reporting, making routing decision, data relaying, etc.) quite like the legitimate nodes, while behaving in malicious ways. In our case, the collaborating node and the terminal sensor node (the HIP responder) both carry the risk of being compromised, but the worst-case scenario happens when the collaborator node is affected. In such a case, it is possible that the underlying legitimate sensor nodes will be prevented from establishing HIP sessions with any outsider entities. In our solution, we suppose that internally, the WSN is equipped with a robust Intrusion Detection System (IDS), like the one proposed in [44], to deal with internal attacks and

also to detect and isolate any possible compromised terminal 1090 sensor node or collaborator in the 6LoWPAN network. 1091 5. Performance evaluation and results

1092

We have conducted our evaluations in Cooja network simulator [45] of Contiki operating system, version 2.5. We have considered a 6LoWPAN network composed of 100 emulated Tmote Sky sensors (RFDs), equipped with MSP430 microcontroller CPU running at 3.9 MHz, 10 kB of RAM, 48 kB of ROM and an IEEE 802.15.4 radio interface. The network nodes are stationary and randomly deployed. The performed simulations can be divided into two parts: • We first evaluate the proposed header compression model. • We further conduct a deep assessment on CD-HIP.

1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103

In our evaluations, we mainly focus on the quantification 1104 of sensor node’s energy consumption to perform both HIP 1105 packets communication and secret key derivation. To esti- 1106 mate the energy consumption, Contiki OS defines a module 1107 named Energest [46] that gives the time spent in CPU, com- 1108 munications (transmission and listening), and low power 1109 mode (LPM). A general formula of the estimation of energy 1110 consumption is presented in Eq. (2), 1111

Energy(mJ) =

T × Current × Voltage. STicks

(2)

To obtain the consumed energy (in mJ) by a sensor node to perform a given task (computation or wireless communication), we have to multiply the elapsed time (in seconds) for achieving that task by the current draw and the supply voltage. The Energest module provides time (T) in ticks, and in order to get the elapsed time in seconds, we must divide it (T) by the amount of ticks that a timer generates in 1 s (STicks). In Contiki 2.5, the timer produces 32,768 ticks per second. On the other hand, the current and the voltage are both platform-dependent. With a Tmote Sky sensor, the voltage is 3 V and the wireless transceiver draws a current of 20 mA for listening and 17.7 mA for radio transmissions. The current draw for CPU is about 1.8 mA and in low power mode, the current draw is 0.0545 mA. The wireless communication currents (20 mA for listening and 17.7 mA for radio transmission) are much more important than the CPU current (1.8 mA) that is why communications are more expensive in terms of energy consumption than the computational primitives. 5.1. Evaluation of the proposed HIP header compression model We evaluate at first the energetic gain of the proposed 6LoWPAN compression model for HIP. The communication energy is computed with the following equation, where Tx and Tr are respectively the transmission time and the listening time.



EnergyComm(mJ) =

(T x × 17.7mA) + (Tr × 20mA)



1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135

32768 ×3V.

(3)

Table 4 summarizes the energy consumption results for HIP header communication in both cases: with and without the proposed 6LoWPAN compression model. This evaluation

Please cite this article as: S. Sahraoui, A. Bilami, Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.08.002

1136 1137 1138

ARTICLE IN PRESS

JID: COMPNW

[m3Gdc;August 22, 2015;20:28]

S. Sahraoui, A. Bilami / Computer Networks xxx (2015) xxx–xxx

15

Table 4 Review of the energetic cost of HIP header communication. HIP-BEX packets (mJ)

With compression Without compression

All HIP packets (mJ)

1Hop

4Hops

8Hops

1Hop

4Hops

8Hops

9.032 17.225

34.128 67.8

70.234 136.803

29.237 55.368

114.971 221.47

230.031 442.946

160

With proposed 6LoWPAN compression Without compression

140 Energy (mJ)

120 100 80

0 1 hop

4 hops

8 hops

(a) 500

With proposed 6LoWPAN compression Without compression

450

Energy (mJ)

400 350 300 250 200 150 100 50 0 1 hop

4 hops

8 hops

(b) Fig. 9. Communication overhead of HIP header with (a) HIP-BEX handshake packets and (b) all HIP packets.

1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153

takes on packets exchanged during the HIP-BEX phase, as well as, the communication of the all HIP packets. Fig. 8 depicts the obtained results. Fig. 9 depicts the obtained results. The evaluation results show that with the proposed compression model, HIP header communication overhead becomes extremely lightweight in both cases: the communication of HIP-BEX messages and all HIP packets. This is especially obvious when the communication between the terminal sensor node and the border router is in multi-hop. The obtained results show also that without compression, even with only one HIP session establishment, the communication energetic costs, as well as, the induced network overhead are important, particularly in the case of multi-hop communications between the 6LoWPAN border router and the HIP responder (end-sensor node). Thus, the more the

amount of HIP sessions being established with WSN nodes 1154 increases, the more the impact of the communication of un- 1155 compressed HIP packets is expected to be considerable. 1156 Following this expectation, we have evaluated the total 1157 of energy dissipation in the WSN for the communication of 1158 HIP header during HIP-BEX phase with two additional HIP 1159 messages that are necessary for session closing (CLOSE and 1160 CLOSE_ACK messages). The number of established HIP ses- 1161 sions is variable and increasing, while the solicited HIP re- 1162 sponders (terminal sensor nodes) are linked to the 6BR with 1163 various distances (communication hops). Fig. 10 presents the 1164 obtained results. 1165 We can see from Fig. 10 that each time the amount of es- 1166 tablished HIP sessions in the 6LoWPAN network rises, the en- 1167 ergy overhead related to the communication of HIP header 1168

Please cite this article as: S. Sahraoui, A. Bilami, Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.08.002

ARTICLE IN PRESS

JID: COMPNW 16

[m3Gdc;August 22, 2015;20:28]

S. Sahraoui, A. Bilami / Computer Networks xxx (2015) xxx–xxx

800

With proposed 6LoWPAN compression

700

Without compression

Energy (mJ)

600 500 400 300 200 100 0 2

4

6

8

10

Amount of established HIP sessions Fig. 10. General communication overhead of HIP header for session establishment in the 6LoWPAN network.

1169 1170 1171 1172

1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207

increases considerably without compression. This is not the case with HIP header compression (according to the proposed solution) where the energy consumption rates increase slightly allowing substantial energetic gains. 5.2. Performance evaluation of CD-HIP CD-HIP performances are evaluated with the same conditions stated in Section 5, with the dissemination of 10 powerful collaborator nodes (FFDs) in the 6LoWPAN network. For the security material, we consider an initial Diffie–Hellman security credential of 1536 bits MODP group with 180 bits exponent size that ensures an acceptable security level [47]. For digital signatures that must be performed by the terminal sensor node (HIP responder), we make use of the ECDSA163 bits algorithm [48] with SHA-224. ECDSA (Elliptic Curve Digital Signature Algorithm) algorithms are supported in HIP implementations [26] and are advantageous in terms of computation time and energy consumption [42]. We used the Secure Hash Algorithm SHA-224 that belongs to the SHA-2 hash functions (SHA-224, SHA-256, SHA-384, and SHA-512) [49] that are more efficient and collision resistant than their predecessor SHA-1. Another reason for choosing SHA-224 algorithm is that it generates shorter hash values (coded on 224 bits). In addition, we employ the symmetric-key algorithm AES-128 (Advanced Encryption Standard with a 128-bit key) [50] that is sufficiently robust and provides high-level security for the protection of only the most security demanding information in the exchanged messages between end-sensor nodes and the assisting nodes. Note that AES is supported by IEEE 802.15.4-enabled WSNs for optional security in MAC layer [51]. So, we do not have to implement another security algorithm and overburden the mote’s memory. We compare CD-HIP with the standard HIP and the distributed HIP-BEX proposed in [30] (with four proxies). Thus, we compare our solution with its two partial solutions: the Compressed HIP (C-HIP) that refers to HIP implementing only the proposed compression model (without distribution), and the Distributed HIP (D-HIP) supporting only the proposed distribution model (without the proposed header

compression model). The evaluation criteria are based on the consumed energy by the terminal sensor node for the communication of HIP messages and for performing the required computations for session key derivation. Thus, the overall energy consumed by the proposed protocol (CD-HIP) is also estimated. Additionally, we consider in our evaluation the impact of our solution on the average delay of the security session establishment, and finally, we measure memory (ROM and RAM) requirements for CD-HIP. Table 5 reviews the obtained assessment results. 5.2.1. Energy consumption The energy consumption is a decisive and relevant performance evaluation criterion for the solutions developed for WSNs. Fig. 11 presents the energetic costs of the computational and communication primitives in CD-HIP and the other solutions. The communication cost is estimated as indicated previously (Eq. (3)) and the computational cost is computed according to the following equation where Tcpu is the time elapsed in CPU operations:

T cpu × 1.8mA × 3V. EnergyCompt(mJ) = 32768

1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226

(4)

From Fig. 11, we remark that the solutions that do not implement any compression mechanism (the standard HIP, Ben-Saied et al. solution [30] and D-HIP) have substantial communication costs. Nevertheless, Ben-Saied’s et al. solution has the most important amount due to the communication of many signaling messages between the terminal sensor node and the proxies during the distribution. Accordingly, the overall communication overhead is expected to be very important in case of frequent HIP session establishments with the connected WSN nodes. Also, any additional solution that can be implemented in order to deal with communication reliability of the distribution messages may increase the communication overhead. In C-HIP, the consumed energy for the communication of HIP packets (transmissions and receptions) is very low, thanks to the incorporation of the proposed header compression mechanism. However, the computational cost is considerable, quite like in the standard HIP, as all the heavy security operations (Diffie–Hellman computations) are performed by

Please cite this article as: S. Sahraoui, A. Bilami, Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.08.002

1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245

ARTICLE IN PRESS

JID: COMPNW

[m3Gdc;August 22, 2015;20:28]

S. Sahraoui, A. Bilami / Computer Networks xxx (2015) xxx–xxx

17

Table 5 Review of the obtained evaluation results. Protocol

Computational cost (mJ)

Communication cost (mJ)

Total energetic cost (mJ)

Average session delay (ms)

Standard HIP Ben-Saied et al. [30] C-HIP D-HIP CD-HIP

64.231 3.43 63.622 15.17 14.93

78.67 94.55 47.186 86.59 52.16

142.901 97.98 110.808 101.76 67.09

34275 20817 26992 19700 14056

100 90

Computational cost

80

Communication cost

Energy (mJ)

70

60 50 40 30 20 10 0 Standard HIP

Ben -Saied et al. [30]

C -HIP

D -HIP

CD -HIP

Fig. 11. The computational and communication energetic costs.

1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267

the terminal sensor node. In contrast, the CPU-related energetic costs are minimal in Ben-Saied et al. solution [30] due to the implementation of the security distribution mechanism that delegates the computation of Diffie–Hellman exponentiations and also the computation of HIP signatures to the collaborators. On the other hand, as the security computational load in our distribution model is distributed over the collaborator and the terminal sensor node, the computational costs with D-HIP and CD-HIP protocols that implement the proposed distribution model are reduced, and are related to the remaining cryptographic operations (mainly the computation of the signatures) that must be computed by the sensor node (HIP responder). For CD-HIP, the obtained results show improved energy consumption in both communication and computation, with a communication cost slightly greater than the one obtained with C-HIP. This is due to the mandatory exchange of the few additional messages that are required for the distribution process between the HIP responder and the collaborator. The total power consumption by the terminal sensor node for HIP security establishment is estimated with the following equation:

Energy(mJ) = EnergyComm + EnergyCompt. 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277

(5)

Note that we have not considered the energy dissipation during the low power mode because it has a negligible impact on the obtained results. Fig. 12 presents the overall energy consumed by the endsensor node in CD-HIP and the other solutions. By the combination of the two relevant adaptation techniques (the 6LoWPAN header compression and the cryptographic load distribution) in the standard HIP, the advantages of both techniques are also combined together. Therefore, the overall energy consumption is minimal and much more

reasonable, which makes CD-HIP an energy-efficient security 1278 protocol. 1279 5.2.2. Secure session establishment delay We evaluate CD-HIP performances also according to the average delay of security session establishment, in the 6LoWPAN network. This average delay is estimated regarding session delays measured in 1 hop, 4 and 8 communication hops between the terminal sensor nodes and the 6LoWPAN border router in the standard HIP, C-HIP, D-HIP. As the distributed system proposed in Ben-Saied et al. [30] focuses on a multipath relaying structure, the measured session delay for this solution is not an average. The obtained results are presented in Fig. 13. The short transit delay of the compressed HIP packets, and the accelerated secret key generation lead to decreasing sensibly, the session delay in CD-HIP. This is not the case with the remaining solutions that have long session delays as they require a long time to perform heavy cryptographic primitives in HIP-BEX mechanism, and/or communicate long uncompressed HIP packets. However, it is clearly remarkable that delays in C-HIP and standard HIP are much more important than in the distribution-supporting solutions because of the heaviness of the induced asymmetric cryptographic operations that are very slow. From these results, we deduce that CD-HIP is suitable for securing real-time applications in the IoT. 5.2.3. ROM and RAM overhead In order to quantify ROM and RAM occupation with our solution, we have used the msp430-size tool. From the results tabulated below, we find that CD-HIP presents a modest memory overhead about 11,7 kB of ROM and 2 kB of RAM,

Please cite this article as: S. Sahraoui, A. Bilami, Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.08.002

1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303

1304 1305 1306 1307 1308

ARTICLE IN PRESS

JID: COMPNW 18

[m3Gdc;August 22, 2015;20:28]

S. Sahraoui, A. Bilami / Computer Networks xxx (2015) xxx–xxx

160 Overall energy consumption

140

Energy (mJ)

120 100 80 60 40 20 0 Standard Ben-Saied HIP et al. [30]

C-HIP

D-HIP

CD-HIP

Fig. 12. The overall energy consumption.

40000 35000

Average session delay

30000

Delay (ms)

25000 20000 15000

10000 5000 0 Standard Ben-Saied C-HIP HIP et al. [30]

D-HIP

CD-HIP

Fig. 13. The average delay of session key establishment in CD-HIP. Table 6 RAM and ROM requirements for our solution.

1309 1310 1311 1312

Extension

ROM (bytes)

RAM (bytes)

Contiki OS Contiki with standard HIP Contiki with CD-HIP

32145 46525 (+14380) 43917 (+11772)

4979 7242 (+2263) 7096 (+2117)

thanks to the adoption of the proposed 6LoWPAN compression model. In fact, these results may be prohibitive for highly memory-constrained devices, like Tmote Sky and TeloseB platforms having both 10 kB of RAM, 48 kB of ROM. Never-

theless, we use such motes only for simulations and for a real implementation of our solution, we plan to adopt more powerful hardware platforms for sensors like Zolertia Z1 (8 kB of RAM, 92 kB of ROM) or WiSMote (16 kB of RAM, 128 kB of ROM) platforms, on which CD-HIP memory overhead appears with a slight footprint. Table 6 presents the memory requirements for CD-HIP.

1313

5.3. CD-HIP and the other HIP-based end-to-end security solutions in the IoT

1320

1314 1315 1316 1317 1318 1319

1321

In contrast to the existing HIP-based solutions which rely, 1322 in their best, either on compressing HIP packets with non- 1323 standardized compression or on a complicated distribution 1324

Table 7 Comparison between CD-HIP and other HIP-based solutions in the IoT. Protocol

Communication cost

Computational cost

Compatibility with standard HIP

[28] [29] [30] [31] [32] CD-HIP

Important Important Very important Low Important Low

Still important Very low Very low Still important Medium Low

Bad Good Good Bad Bad Good

Please cite this article as: S. Sahraoui, A. Bilami, Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.08.002

JID: COMPNW

ARTICLE IN PRESS S. Sahraoui, A. Bilami / Computer Networks xxx (2015) xxx–xxx

1331

policy for HIP-BEX. Our proposed strategy that combines an optimal 6LoWPAN compression model for HIP header with an efficient and well-adapted distribution model for HIP-BEX, allows reduced costs in both communication and computational primitives, while ensuring a good compatibility with the standard HIP. Table 7 compares CD-HIP with HIP-related solutions.

1332

6. Conclusion and future works

1333

1368

In this paper we have presented a novel HIP-based solution to ensure end-to-end security between the sensor nodes and the Internet hosts, in the context of the Internet of things, while efficiently considering the constraints of WSNs. The solution consists in an adaptation framework of the communication and computational costs of HIP protocol to the limited capabilities of the sensor nodes, for a robust and lightweight security. The proposed adaptation framework is composed of an optimal compression model for HIP header and a secure distribution system of the security load in HIP’s key agreement process (HIP-BEX). The compression model presents the first extension of the 6LoWPAN compression standard to support the compression of HIP header. The distribution model focuses on the safe delegation of the heaviest cryptographic operations in HIP-BEX to a powerful collaborator node, while keeping the distribution transparent to the external Internet host. The assessment results show clearly that our solution is sufficiently energy-efficient in both messages communication and security establishment. The obtained results show also that the session establishment delay in CD-HIP is significantly decreased, which is suitable for securing real-time applications in the IoT. Thus, CD-HIP has a small memory footprint and for an optimal efficiency, it can be used with the compressed ESP protocol, already proposed in [20], for further protection of the applicative data. Our solution can be enhanced so that the WSN could be protected against DoS attacks launched from the Internet, while allowing end-to-end security establishment with external entities. As a future work, we plan to improve the proposed solution by giving a special attention to trust issues [52]. Additionally, we may equip CD-HIP with a fault tolerance policy to overcome the possible failures of the operational entities in the compression and distribution mechanisms, which are respectively the border router and the collaborator nodes.

1369

Acknowledgment

1370 1371

This work is supported by MESRS through the CNEPRU B01320140103 project.

1372

References

1325 1326 1327 1328 1329 1330

1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367

1373 1374 1375 1376 1377 1378 1379 1380 1381 1382

[1] D.E Vans, The Internet of Things: How the Next Evolution of the Internet is Changing Everything, Cisco Internet Business Solutions Group (IBSG), 2011. [2] L. Atzori, A. Lera, G. Morabioto, The internet of things: a survey, Comput. Netw. 54 (15) (2010) 2787–2805. [3] O. Garcia-Morchon, S. Keoh, S. Kumar, R. Hummen, R. Struik, Security considerations in the IP-based internet of things, Draft-Garcia-CoreSecurity-04 (2012) March 26. [4] I.F. Akyildiz, W. Su, Y. Sankarasubramaniam, E. Cayirci, Wireless sensor networks: a survey, Comput. Netw. 38 (4) (2002) 393–422.

[m3Gdc;August 22, 2015;20:28] 19

[5] S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, Request for Comments 2460 (1998). [6] G. Montenegro, N. Kushalnagar, J. Hui, D. Culler, Transmission of IPv6 packets over IEEE 802.15.4 networks, Request for Comments 4944 (2007). [7] T. Winter, P. Thubert, A.B. randt, J. Hui, R. Kelseky, P. Levis, K. Pister, R. Struik, J.P. Vasseur, R. Alexander, RPL: IPv6 routing protocol for lowpower and lossy networks, Request for Comments 6550 (2012). [8] Z. Shelby, K. Kartke, C. Bormann, B. Frank, Constrained application protocol (CoAP), Draft-Ietf-Core-Coap-12 (2012). [9] R. Hummen, J. Hiller, H. Wirtez, M. Henze, H. Shafagh, K. Wehrle, 6LoWPAN fragmentation attacks and mitigation mechanisms, in: The Sixth ACM Conference on Security and Privacy in Wireless and Mobile Networks, 2013. [10] T. Dierks, C. Allen, The TLS protocol, Request for Comments 2246 (1999). [11] S. Fouladgar, B. Mainaud, K. Masmaudi, H. Afifi, Tiny 3-TLS: a trust delegation protocol for wireless sensor networks, Security and Privacy in Ad-Hoc and Sensor Networks (2006) 32–42. [12] Y. Ben-Saied, A. Olivereau, D. Zeghlache, M. Laurent, Lightweight collaborative key establishment scheme for the Internet of things, Comput. Netw. 64 (2014) 273–295. [13] E. Rescorla, N. Modadugu, Datagram transport layer security, Request for Comments 4347 (2006). [14] T. Kothmayr, W. Hu, C. Schmitt, M. Brunig, G. Carle, Poster, Securing the Internet of Things with DTLS, in: the 9th ACM Conference on Embedded Networked Sensor Systems, 2011, pp. 345–346. [15] S. Raza, D. Trabalza, T. Voigt, 6LoWPAN compressed DTLS for CoAP, in: The 8th IEEE International Conference on Distributed Computing in Sensor Systems, 2012, pp. 287–289. [16] S. Raza, H. Shafagh, K. Hewag, R. Hummen, Lithe: lightweight secure CoAP for the internet of things, IEEE Sens. J. 13 (10) (2013) 3711–3720. [17] T. Kothmayr, C. Schmitt, W. Hu, M. Brunig, G. Carle, DTLS based security and two-way authentication for the internet of things, Ad Hoc Netw. 11 (8) (2013) 2710–2723. [18] H. Shafagh, A. Hithnawi, Poster abstract: security comes first, a publickey cryptography framework for the internet of things, in: The 10th IEEE International Conference on Distributed Computing in Sensor Systems (DCOSS’14), 2014, pp. 135–136. [19] S. Frankel, S. Kishnan, IP security (IPsec) and internet key exchange (IKE) document roadmap, Request for Comments 6071 (2011). [20] S. Raza, T. Voigt, U. Roedig, 6LoWPAN extension for IPsec, in: The Interconnecting Smart Objects with the Internet Workshop, 2011. [21] S. Kent, IP authentication header, Request for Comments 4302 (2005). [22] S. Kent, IP encapsulating security payload (ESP), Request for Comments 4303 (2005). [23] S. Raza, T. Voigt, V. Jutvik, Lightweight IKEv2: a key management solution for both the compressed IPsec and the IEEE 802.15.4 Security, in: The IETF Workshop on Smart Object Security, Paris, 2012. [24] R. Bonetto, N. Bui, V. Lakkundi, A. Olivereau, Secure communication for smart IoT objects: protocol stacks, use cases and practical examples, in: World of Wireless, Mobile and Multimedia Networks (WoWMoM) IEEE International Symposium, San Francisco, 2012, pp. 1–7. [25] R. Moskowitz, P. Nikander, P. Jokela, T. Henderson, Host identity protocol, IETF RFC 5201 (2008). [26] R. Moskowitz, T. Heer, P. Jokela, T. Henderson, Host identity protocol version 2 (HIPv2), Request for Comments 7401 (2015). [27] P. Jokela, R. Moskowitz, J. Melen, Using the encapsulating security payload (ESP) transport format with the host identity protocol (HIP), Request for Comments 7402 (2015). [28] R. Moskowitz, HIP diet EXchange (DEX), Draftmoskowitz- hip-rg-dex05 (IETF work in progress) (2011). [29] T. Heer, LHIP lightweight authentication extension for HIP, Draft-heerhip-lhip-00 (IETF work in progress) (2007). [30] Y. Ben Saied, A. Olivereau, D-HIP: a distributed key exchange scheme for HIP-based internet of things, in: IEEE International Symposium on World of Wireless Mobile and Multimedia Networks (WoWMoM), San Francisco, 2012, pp. 1–7. [31] R. Hummen, J. Hiller, M. Henze, K. Wehrle, Slimfit – a HIP DEX compression layer for the IP-based internet of things, in: IEEE WiMob 2013 Workshop IoT, Lyon, 2013, pp. 259–266. [32] F.V. Meca, J.H. Ziegeldorf, P.M. Sanchez, O.G. Morchon, HIP security architecture for the IP-based internet of things, in: 2013 27th International Conference on Advanced Information Networking and Applications Workshops, Barcelona, 2013, pp. 1331–1336. [33] R. Alexander, T. Tsao, Adapted multimedia internet KEYing (AMIKEY): an extension of multimedia internet KEYing (MIKEY) methods for generic LLN environments, IETF, Internet-Draft (2012).

Please cite this article as: S. Sahraoui, A. Bilami, Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.08.002

1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460

JID: COMPNW 20

1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503

ARTICLE IN PRESS

[m3Gdc;August 22, 2015;20:28]

S. Sahraoui, A. Bilami / Computer Networks xxx (2015) xxx–xxx

[34] D. Kuptsov, B. Nechaev, A. Gurtov, Securing medical sensor network with HIP, in: Wireless Mobile Communication and Healthcare, Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, 2012, pp. 150–157. [35] A. Khurri, D. Kuptsov, A. Gurtov, On application of host identity protocol in wireless sensor networks, in: IEEE 7th International Conference on Mobile Ad hoc and Sensor Systems (MASS), San Francisco, CA, 2010, pp. 345–358. [36] J. Hui, P. Thubert, Compression format for IPv6 datagrams in low power and lossy networks (6LoWPAN), Draft-ietf-6lowpan-hc-15 (2011). [37] S. Yang, S. Park, E.J. Lee, J.H. Ryu, B.S. Kim, H.S. Kim, Dual addressing scheme in IPv6 over IEEE 802.15.4 wireless sensor networks, ETRI J. 30 (5) (2008). [38] C. Bormann, 6LoWPAN generic compression of headers and header-like payloads, Internet- draft-bormann-6lowpan-ghc-04 (2012). [39] G. Camarillo, J. Melen, Host identity protocol (HIP) immediate carriage and conveyance of upper-layer protocol signaling (HICCUPS), IETF RFC 6078 (2011). [40] E. Rescorla, Diffie-Hellman key agreement method, Request for Comments 2631 (1999). [41] J. Großschadl, A. Szekely, S. Tillich, The energy cost of cryptographic key establishment in wireless sensor networks, in: The 2nd ACM Symposium on Information, Computer and Communications Security (ASIACCS), Singapore, 2007, pp. 380–382. [42] G. Ateniese, G. Bianchi, A. Capossele, C. Petrioli, Low-cost standard signatures in wireless sensor networks: a case for reviving precomputation techniques? in: 20th Annual Network & Distributed System Security Symposium (NDSS), San Diego, 2013. [43] V.B. Misic, J. Fang, J. Misic, MAC layer security of 802.15.4-compliant networks, in: IEEE International Conference on Mobile Adhoc and Sensor Systems, 2005. [44] S. Raza, L. Wallgren, T. Voigt, SVELTE: real-time intrusion detection in the internet of things, Ad Hoc Netw. 11 (8) (2013) 2661–2674. [45] A. Sehgal, Using the Contiki Cooja Simulator (2013). [46] A. Dunkels, F. Osterlind, N. Tsiftes, Z. He, Software-based on-line energy estimation for sensor nodes, in: 4th Workshop Embedded Netw. Sensors, New York, 2007, pp. 28–32. [47] T. Kivinen, M. Kojo, More modular exponential (MODP) Diffie-Hellman groups for internet key exchange (IKE), Request for Comments 3526 (2003). [48] T. Pornin, Deterministic usage of the digital signature algorithm (DSA) and elliptic curve digital signature algorithm (ECDSA), Request for Comments 6979 (2013).

[49] S. Turner, Using SHA2 algorithms with cryptographic message syntax, Request for Comments 5754 (2010). [50] P.D. Khambre, S.S. Simbhare, P.S. Chavan, Secure data in wireless sensor network via AES (advanced encryption standard), Int. J. Comput. Sci. Inform. Technol. (IJCSIT) 3 (2) (2012) 3588–3592. [51] S. Saleem, S. Ullah, K.S. Kwak, A Study of IEEE 802.15.4 security framework for wireless body area networks, Sensors 2011 (2011) 1383–1395. [52] S. Sicari, A. Rizzardi, L.A. Grieco, A. Coen-Porisini, Security, privacy and trust in internet of things: the road ahead, Comput. Netw. 76 (2015) 146–164.

1504 1505 1506 1507 1508 1509 1510 1511 1512 1513

Somia Sahraoui is a Ph.D. student and a member of LaSTIC laboratory in the Computer Science Department, University of Batna. She received the Master degree in Networks Engineering and Communication, in 2012. Her research interests are mainly focused on communication security in Wireless Sensor Networks and the Internet of Things.

1514 1515 1516 1517 1518 1519 1520 1521

Azeddine Bilami received the Ph.D. degree in 2005. He is currently serving as a Full Professor and the Head of LaSTIC laboratory at the Computer Science Department, University of Batna. His research interests include TCP/IP and Internet, Cloud computing, security, mobility and quality of service in wireless and mobile networks, highperformance parallel architectures and multiprocessors, system-on-chip architectures. Professor Bilami has authored and coauthored more than twenty journal and conference articles in his research expertise. He serves as a technical program committee in many national and international conferences, such as SNIB, IFIP, CRATT, AWICT, CIIA. He also serves as a member of steering committee and International Advisory Committee of NGNS and IPAC international conferences. In addition, Professor Bilami is a reviewer in several international journals, including Computer Communications (Elsevier) and International Arab Journal of Information Technology. His research interests are currently focused on security in Wireless Sensor Networks and the Internet of Things.

1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541

Please cite this article as: S. Sahraoui, A. Bilami, Efficient HIP-based approach to ensure lightweight end-to-end security in the internet of things, Computer Networks (2015), http://dx.doi.org/10.1016/j.comnet.2015.08.002