sensors Article
Source Authentication for Code Dissemination Supporting Dynamic Packet Size in Wireless Sensor Networks † Daehee Kim 1 , Dongwan Kim 2, * and Sunshin An 1 1 2
* †
Department of Electronics Engineering, Korea University, Seoul 02841, Korea;
[email protected] (D.K.);
[email protected] (S.A.) Division of Network Business, Samsung Electronics Co., Ltd., Suwon 16677, Korea Correspondence:
[email protected]; Tel.: +82-10-2704-1909 This paper is an extended version of the paper entitled “Source authentication schemes for reprogramming with variable packet size in wireless sensor networks”, presented at 12th IEEE SECON, Seattle, WA, USA, 22–25 June 2015; pp. 148–150.
Academic Editor: Rongxing Lu Received: 12 March 2016; Accepted: 5 July 2016; Published: 9 July 2016
Abstract: Code dissemination in wireless sensor networks (WSNs) is a procedure for distributing a new code image over the air in order to update programs. Due to the fact that WSNs are mostly deployed in unattended and hostile environments, secure code dissemination ensuring authenticity and integrity is essential. Recent works on dynamic packet size control in WSNs allow enhancing the energy efficiency of code dissemination by dynamically changing the packet size on the basis of link quality. However, the authentication tokens attached by the base station become useless in the next hop where the packet size can vary according to the link quality of the next hop. In this paper, we propose three source authentication schemes for code dissemination supporting dynamic packet size. Compared to traditional source authentication schemes such as µTESLA and digital signatures, our schemes provide secure source authentication under the environment, where the packet size changes in each hop, with smaller energy consumption. Keywords: code dissemination; wireless sensor networks; dynamic packet size; source authentication
1. Introduction Code dissemination is a main building block of reprogramming which allows over-the-air software updates in wireless sensor networks (WSNs). Since WSNs are mostly deployed in unattended and hostile environments, secure code dissemination is essential to prevent attackers from injecting malicious code into the WSN. There have been a lot of works on secure code dissemination [1–13] whose main goal is to provide source authentication, which implies that each sensor node must be able to assure that the received code image is really sent by a base station (BS) and not modified in transit. They attain this goal by applying existing source authentication schemes, such as µTESLA [14], digital signatures and the hash chains, into code dissemination. Recently, a few cross-layer approaches using link estimation have been suggested to improve energy efficiency in WSNs. DPLC [15] provides a lightweight dynamic packet length control scheme based on an accurate link estimation method which leads to low transmission overhead. ECD [16] is a code dissemination scheme supporting dynamic packet size and accurate sender selection based on link quality. Plena [17] is a packet length adaptation scheme using error estimating codes. Theses dynamic packet size control schemes can significantly improve the energy efficiency of code dissemination. However, it is not easy to guarantee source authentication for these schemes since the packet size can be changed in each hop depending on the link quality. All well-known existing source Sensors 2016, 16, 1063; doi:10.3390/s16071063
www.mdpi.com/journal/sensors
Sensors 2016, 16, 1063
2 of 22
authentication schemes for WSNs, such as µTESLA, digital signatures and the hash chains, support only fixed-size packets in every hop during code dissemination. In this paper, we propose three source authentication schemes for code dissemination supporting per-hop dynamic packet size, which implies that original packets in the first hop can be split or merged in the other hop depending on the link quality. Our paper starts from the fact that code dissemination schemes supporting dynamic packet size can optimize the energy efficiency by reducing transmission overhead based on the link quality. Under this environment, our schemes reinforce the security, especially source authentication which guarantees both authenticity and integrity for a new code image. According to our survey on existing works, source authentication for code dissemination supporting dynamic packet size has never been researched earlier. In this paper, three source authentication schemes are suggested as follows: ‚ ‚ ‚
Simple packet aggregation (SPA) Message authentication codes (MACs) based source authentication (MBSA) Bloom filter based source authentication (BFBSA)
These schemes are very efficient in terms of computation overhead since they mainly perform lightweight hash operations and require only one public key cryptographic operation during code dissemination. In addition, our schemes can work with any code dissemination scheme supporting dynamic packet size. The main contributions of the paper are as follows. ‚
‚
‚
We identify the problem of existing source authentication schemes which does not support code dissemination with per-hop dynamic packet size. According to our survey on existing works, our work is the first attempt to delve into source authentication for code dissemination with dynamic packet size. We propose three source authentication schemes to address the proposed problem with smaller energy consumption. We accomplish our objective by combining a variety of cryptographic functions such as the hash functions, digital signatures, and the Bloom filter. We analyze our work in terms of security and performance. More specifically, we discuss the authenticity, resilience to node capture attacks and denial-of-service (DoS) attacks in detail, and then present performance analysis with regard to computation and communication overhead.
Compared with our previous work [18], this paper has three major extensions which include the extensive survey on related works, the clear definition of the problem, and the detailed analysis on computation and communication overhead of our work. The rest of the paper is organized as follows: in Section 2, we describe the related works in detail. Section 3 defines the problem to be resolved in this paper. Some preliminaries prior to our proposal are presented in Section 4. In Section 5, we propose three source authentication schemes in detail. After analyzing our schemes in Sections 6 and 7, Section 8 concludes the paper. 2. Related Work One of the most popular code dissemination protocols in WSNs is Deluge [19], which is the de facto standard [1,4,5,10,12,13] and has already been implemented in TinyOS. As shown in Figure 1a, Deluge splits the code image into fixed-size pages, each of which is then divided into fixed-size packets for pipelining and spatial multiplexing. Deluge uses a three-way handshake to transmit these packets for reliable delivery. The sender first broadcasts an advertisement (ADV) which includes the current version of the code image and page information. Upon receiving the ADV, the receiver sends a request (REQ) back to the sender for the specific page. The sender then begins to transmit data packets (DATAs) for the requested page. If the receiver does not receive all packets within the page successfully, it asks the sender for lost packets by sending a REQ indicating the specific lost packets within the page. Figure 1b shows the operation of Deluge. Even though Deluge itself supports fixed-size packets only and does not take security into account, most of non-secure and secure code dissemination protocols are built on the basis of Deluge.
Sensors 2016, 16, 1063
3 of 22
To enhance the energy efficiency, a few works on dynamic packet size control have been introduced 2016, 1063 There is definitely a tradeoff between using large-size packets in the good channel 3 of 22 in Sensors the field of16, WSNs. condition to reduce the header overhead and using small-size packets in the bad channel condition condition to reduce packet error rates (PER). DPLC [15] is an iterative algorithm to find an to channel reduce packet error rates (PER). DPLC [15] is an iterative algorithm to find an optimal packet size optimal packet size using the lightweight and accurate link estimation method. ECD [16] adapts the using the lightweight and accurate link estimation method. ECD [16] adapts the packet size depending packet size depending on the 1-hop link quality for efficient code dissemination. Plena [17] is a on the 1-hop link quality for efficient code dissemination. Plena [17] is a packet size adaptation scheme packet size adaptation scheme using error estimating codes for WSNs. All of these schemes using error estimating codes for WSNs. All of these schemes significantly conserve energy by adapting significantly conserve energy by adapting the packet size to the link quality. By integrating these the packet size to the link quality. By integrating these schemes with existing code dissemination schemes with existing code dissemination protocols such as Deluge, we can build an adaptive code protocols such asscheme Deluge,which we can build an adaptive code dissemination scheme dynamically dissemination dynamically adjusts the packet size depending onwhich the link quality, adjusts the packet size depending on the link quality, thereby reducing the energy consumption. As it thereby reducing the energy consumption. As it will be clarified in Section 3, our goal is to provide will be clarified in Section our new goal kinds is to provide source authentication these kinds code source authentication for3, these of code dissemination schemes for where thenew packet sizeofcan dissemination schemes where the packet size can be different in each hop. be different in each hop.
Figure 1. An illustration of Deluge: (a) The structure of pages and packets; (b) The operation of Figure 1. An illustration of Deluge: (a) The structure of pages and packets; (b) The operation of three-way handshake. three-way handshake.
Source authentication in WSNs has been addressed by μTESLA [14] and digital signatures. Source authentication in WSNs hasbybeen and digital signatures. μTESLA provides source authentication usingaddressed a one-wayby keyµTESLA chain and[14] a delayed key disclosure µTESLA provides source authentication by using a one-way key chainafter and broadcasting a delayed key disclosure technique. Since the BS only knows the current key which is disclosed messages, the receivers the messages from theisreal BS by after verifying the one-way key asthe technique. Sincecan the assure BS onlythat knows the currentare key which disclosed broadcasting messages, h(K i+1 ) = K i where K i and K i+1 are a previous key and a current key, respectively. μTELSA is very receivers can assure that the messages are from the real BS by verifying the one-way key as h(Ki+1 ) = Ki efficient since it only performs symmetric key cryptographic operations. However, μTESLA have a it where Ki and Ki+1 are a previous key and a current key, respectively. µTELSA is very efficient since critical shortcoming thatkey it must buffer all messages until the key µTESLA is distributed, it isshortcoming subject to only performs symmetric cryptographic operations. However, have athus critical DoS attacks which fill the buffer of the receiver by flooding it with false messages. Furthermore, that it must buffer all messages until the key is distributed, thus it is subject to DoS attacks which fill theofintermediate do notitknow the key, they cannot adjust thesince packet which means thesince buffer the receiver nodes by flooding with false messages. Furthermore, thesize intermediate nodes that μTESLA only supports fixed-size packets in each hop. do not know the key, they cannot adjust the packet size which means that µTESLA only supports Digital signatures provide source authentication by simply signing each message with the fixed-size packets in each hop. private key of the BS. The receivers can assure the authenticity by verifying the received message Digital signatures provide source authentication by simply signing each message with the private with the public key of the BS. In contrast to μTESLA, digital signatures provide immediate key of the BS. The receivers can assure the authenticity by verifying the received message with the authentication, thus they are strong to DoS attacks since there is no need to buffer messages. public key of the BS. In contrast to µTESLA, digital signatures provide immediate authentication, thus However, digital signatures are still heavy to resource-constrained sensor nodes even though they are strong DoSshowed attacks that sincepublic-key there is nocryptography need to buffer(PKC) messages. However, digital signatures Wander et al.to[20] is feasible on the sensor node byare still heavy to resource-constrained nodes even et for al. [20] thatimage public-key using elliptic curve cryptographysensor (ECC). Using onethough digital Wander signature the showed entire code as cryptography (PKC) is feasible on the sensor node by using elliptic curve cryptography (ECC). presented in [21] can be a candidate for providing source authentication because it not only Using one digital signature for the entire code signatures image as presented in [21] variable-size can be a candidate addresses the computation overhead of digital but also supports packets.for providing source because it not only addresses thecode computation overhead of digital However, since authentication the digital signature is computed over the entire image, it cannot be verified signatures but alsoinsupports packets. received, However,which sinceleads the digital computed until all packets the codevariable-size image are completely to the signature following is problems. over theifentire code image, it cannot be verified until all packets in the image are completely First, the verification fails, all packets must be discarded because thecode receiver cannot identify which each packet is correct or not. Thisproblems. incurs the First, wasteifofthe theverification energy which is the important received, which leads to the following fails, allmost packets must be resourcebecause in WSNs. attacker can easily the receiver by or making theincurs bufferthe of waste the discarded theSecond, receiveran cannot identify whichdisable each packet is correct not. This receiver full by sending a lot of spoofed messages since the receiver does not identify each packet of the energy which is the most important resource in WSNs. Second, an attacker can easily disable the and thus keep all messages to make up the entire code image.
Sensors 2016, 16, 1063
4 of 22
receiver by making the buffer of the receiver full by sending a lot of spoofed messages since the receiver does not identify each packet and thus keep all messages to make up the entire code image. Sensors 2016, 16, 1063 4 of 22 Due to the property that a code image is available prior to dissemination, existing secure code dissemination schemes in WSNs provide source authentication in a different way from µTESLA Due to the property that a code image is available prior to dissemination, existing secure code anddissemination digital signatures byinusing functions as the hash or the hash tree. schemes WSNshash provide sourcesuch authentication in achain different wayMerkle from μTESLA Secure uses a hash chain as depicted Figure 2. hash Afterchain the code is hash divided andDeluge digital [1] signatures by using hash functions in such as the or theimage Merkle tree.into packets in the same way as Deluge, the hash is computed from the last packet and appended to the Secure Deluge [1] uses a hash chain as depicted in Figure 2. After the code image is divided into endpackets of the previous packet. The procedure is repeated until the the hash the first is computed. in the same way as Deluge, the hash is computed from lastonpacket andpacket appended to the Theend firstofhash (h1,1 in Figure 2)The is then transmitted in advance after signing private of the BS. the previous packet. procedure is repeated until the hash on thewith firstapacket is key computed. Thereceiving first hashthe (h1,1message, in Figure the 2) isreceiver then transmitted in advance signing with a private key of Upon verifies the digital after signature and stores the hash inthe order BS. Upon receiving the message, the receiver verifies the digital signature and stores the hash in to use for authenticating the subsequent packet. The subsequent packet is verified by comparing order to use for authenticating the subsequent packet. The subsequent packet is verified by the previously received hash and the hash on the currently received packet as h1,1 = h(Pkt1,1 |h1,2 ). comparing previously hashonly andone thedigital hash signature on the currently receivedhash packet as Secure Deluge isthe highly efficientreceived since it uses and inexpensive functions. h 1,1 = h(Pkt1,1|h1,2). Secure Deluge is highly efficient since it uses only one digital signature and Secure Deluge also provides immediate authentication unlike µTESLA, and it has lower overhead than inexpensive hash functions. Secure Deluge also provides immediate authentication unlike μTESLA, other existing secure code dissemination schemes because other existing secure code dissemination and it has lower overhead than other existing secure code dissemination schemes because other schemes have additional overhead such as the Merkle hash tree and one-way key chains for enhanced existing secure code dissemination schemes have additional overhead such as the Merkle hash tree features such as confidentiality and loss-resilience. However, Secure Deluge is still vulnerable to DoS and one-way key chains for enhanced features such as confidentiality and loss-resilience. However, attacks in Deluge case of isout-of-order packet delivery does not providepacket sourcedelivery authentication Secure still vulnerable to DoS attacks and in case of out-of-order and does for not the variable-size packets. provide source authentication for the variable-size packets.
Figure 2. An example of Secure Deluge.
Figure 2. An example of Secure Deluge.
Seluge [2] provides immediate authentication for code dissemination packets using a Merkle
Seluge provides immediate authentication code dissemination using a Merkle hash hash tree[2]which includes the hash images of for packets in page 1. Thepackets packets in page 1 are treeauthenticated which includes packets in pagehash 1. The packets in page 1 are authenticated by the thehash hashimages imagesof of the Merkle tree, and the subsequent packets are by chain liketree, Secure Sluice [3] ispackets similar are to Secure Deluge except that the authenticated hash images by of the hash Merkle hash andDeluge. the subsequent authenticated by the hash Sluice theDeluge. page-level hashes while Secure DelugeDeluge uses theexcept packet-level hashes. However, the chain like uses Secure Sluice [3] is similar to Secure that Sluice uses the page-level page-level hashes Deluge are more vulnerable to DoS attacks than the packet-level hashes hashes since packets hashes while Secure uses the packet-level hashes. However, the page-level are more must be buffered for making up a page. Tan et al. [4] provides not only immediate authentication vulnerable to DoS attacks than the packet-level hashes since packets must be buffered for making theTan hash also confidentiality by encrypting each packetusing with athe session derived up ausing page. et chain al. [4]but provides not only immediate authentication hash key chain but also from the hash chain. LR-Seluge [5] enhances loss resilience on the basis of Seluge by using a confidentiality by encrypting each packet with a session key derived from the hash chain. LR-Seluge [5] fixed-rate erasure code. DiCode [6] is almost the same as Seluge but it supports the distributed enhances loss resilience on the basis of Seluge by using a fixed-rate erasure code. DiCode [6] is almost control for code dissemination which means that multiple authorized network users are allowed to the same as Seluge but it supports the distributed control for code dissemination which means that update a code image without involving the BS. Tan et al. [7] uses multiple one-way key chains multiple authorized users are allowedpacket to update a code image without the BS. instead of the hashnetwork chain to provide immediate authentication. It does not useinvolving even one PKC Tan operation, et al. [7] uses multiple one-way key chains instead of the hash chain to provide immediate packet but it incurs key distribution overhead and the communication overhead due to large authentication. does not even one PKC operation, it incurs distribution overhead and packet size. ItSDRP [8] use is almost identical to DiCodebut except thatkey SDRP uses identity-based the cryptography communication overhead duefor to authenticating large packet size. SDRP [8] is almost identical to DiCode except rather than RSA the Merkle hash tree. Deng et al. [9] also takes a thatsimilar SDRP uses identity-based cryptography rather than RSA for authenticating the Merkle hash approach to Seluge by using the Merkle hash tree. Bohli et al. [10] provides an efficienttree. source combining the Merkle hash tree and thethe hash chain.hash Flexicast provides Deng et al.authentication [9] also takesby a similar approach to Seluge by using Merkle tree.[11] Bohli et al. [10]
Sensors 2016, 16, 1063 Sensors 2016, 16, 1063
5 of 22 5 of 22
provides an efficientauthentication source authentication by combining the Merkleand hash tree and the hash chain. an energy-efficient through authenticated fingerprints network-wide attestation. Flexicast [11] provides an energy-efficient authentication through authenticated fingerprints and Chen et al. [12] provides source authentication by using the Merkle hash tree and provides network-wide attestation. Chen etXORs al. [12]coding provides authentication using SecNRCC the Merkle[13] hash confidentiality through effective andsource multiple one-way hashbychains. tree and provides confidentiality throughwith effective XORs coding and multiple one-way hash chains. provides an immediate authentication confidentiality consideration by combining the hash SecNRCC authentication with confidentiality consideration by combining tree and[13] the provides one-way an keyimmediate chain. SIMAGE [22] is a secure code dissemination which adapts to the quality through dynamickey packet sizing. Even [22] if SIMAGE provides confidentialitywhich and integrity thelink hash tree and the one-way chain. SIMAGE is a secure code dissemination adapts to neighboring it does notsizing. provide source authentication. Allconfidentiality of these schemes, thebetween link quality through nodes, dynamic packet Even if SIMAGE provides and which integrity we have discussed in this section, do not provide source authentication for code dissemination between neighboring nodes, it does not provide source authentication. All of these schemes, which we supporting packet do size each hop. In authentication contrast to these schemes, our works have discusseddynamic in this section, notinprovide source for existing code dissemination supporting providepacket efficient source authentication for code dissemination supportingour per-hop dynamic size in each hop. In contrast to these existing schemes, worksdynamic providepacket efficient size. source authentication for code dissemination supporting per-hop dynamic packet size. ProblemDefinition Definition 3. 3.Problem This paperisismotivated motivated by by recent recent works packet size control in WSNs which tries tries to This paper workson ondynamic dynamic packet size control in WSNs which minimize the energy consumption by dynamically adapting packet size depending on the link to minimize the energy consumption by dynamically adapting packet size depending on the link quality [15–17,22,23]. Large packets can improve the energy efficiency by keeping the overhead of quality [15–17,22,23]. Large packets can improve the energy efficiency by keeping the overhead of the header low, but at the same time large packets can reduce the energy efficiency by raising PER. the header low, but at the same time large packets can reduce the energy efficiency by raising PER. In contrast, the use of small packets leads to low PER, but is not good in terms of the header In contrast, the use of small packets leads to low PER, but is not good in terms of the header overhead. overhead. Therefore, these works adjust the packet size appropriately depending on the link quality. Therefore, these works adjust the packet size appropriately depending on the link quality. Another important aspect of code dissemination is to guarantee the authenticity of the Another important aspect of code dissemination is to guarantee the authenticity of the distributing distributing node (e.g., BS) and the integrity of the code image which is normally ensured by the node (e.g., BS) and the integrity of the code imagesignatures, which is normally by theby authentication authentication tokens, such as MACs and digital attached ensured to each packet the source tokens, such as MACs and digital signatures, attached to each packet by the source node. It is important node. It is important to note that source authentication, not intermediate nodes authentication, is to required note thatduring sourcecode authentication, not intermediate nodes authentication, is required during code dissemination since the sensor nodes are vulnerable to node capture attacks. dissemination since the sensor nodes are vulnerable to node capture attacks. When applying existing When applying existing source authentication schemes into code dissemination supporting dynamic source authentication schemesarises into code dissemination dynamic a newinproblem packet size, a new problem as shown in Figure supporting 3 since the packet sizepacket can besize, different each arises hop.as shown in Figure 3 since the packet size can be different in each hop.
Figure The problemofofexisting existingsource sourceauthentication authentication schemes supporting Figure 3. 3. The problem schemesin incode codedissemination dissemination supporting dynamic packet size. dynamic packet size.
The BS first determines the packet size on the basis of the link quality between the BS and the The BS first determines the packet size on the basis of the link quality between the BS and the sensor node 1. Once the packet size is determined, the BS generates an authentication token which sensor nodethe 1. authenticity Once the packet size is determined, the BS generates authentication tokentowhich provides and the integrity of the packet, and sends theantoken with the packet the provides the authenticity and the integrity of the packet, and sends the token with the packet to the node 1. Upon receiving the packet, the node 1 verifies the authentication token using a shared key node 1. the Upon receiving theaccording node 1 verifies the authentication token using sharedtokey with BS or a public the keypacket, of the BS to the used cryptography. To forward thea packet with the BS or a public key of the BS according to the used cryptography. To forward the packet to1the the node 2, the node 1 determines the packet size depending on the link quality between the node node thenode node2.1In determines the packet size depending onisthe link quality between node and and2,the this case where the optimal packet size different from that of thethe first hop1as theshown node 2. this case optimal packet size isauthentication different fromtoken that of of the the BS first shown in In Figure 3, thewhere node 1the cannot generate a valid forhop theas packet in with Figure the node 1 cannot generate a valid authentication tokentoken of theisBS forknown the packet the3,optimal size since the key for generating an authentication only to thewith BS. the we key define the problem to be resolvedtoken in this paper as “providing optimalTherefore, size since the for generating an authentication is only known to the BS. source authentication where the packet size changes in eachsource hop during code Therefore, weunder definethe theenvironment problem to be resolved in this paper as “providing authentication dissemination in orderwhere to improve the energy efficiency.” under the environment the packet size changes in each hop during code dissemination in order
to improve the energy efficiency.”
Sensors 2016, 16, 1063
6 of 22
Sensors 2016, 16, 1063
6 of 22
4. Preliminaries
4. Preliminaries
4.1. Network Model for Code Dissemination 4.1. Dissemination WeNetwork assumeModel that for theCode underlying code dissemination scheme is Deluge. Additionally, we assume that the We code dissemination scheme employs a dynamicscheme packetis size control scheme which adjusts assume that the underlying code dissemination Deluge. Additionally, we assume that thepacket code dissemination employs dynamic packet size control which adjusts a a per-hop size based onscheme the link qualitya in order to enhance energyscheme efficiency such as DPLC, per-hop packet size based on the link quality in order to enhance energy efficiency such as DPLC, ECD, and Plena. Note that our schemes can be integrated with any kind of Deluge-based code ECD, and Plena. Note that the our packet schemes canis be integrated adjusted with any in kind of hop. Deluge-based code the dissemination schemes where size dynamically each For example, dissemination where to theobtain packetansize is dynamically adjusted in each example, the scheme in [23] canschemes be employed optimal packet size depending onhop. PERFor which is estimated scheme in [23] can be employed to obtain an optimal packet size depending on PER which is by the medium access control layer acknowledgements. Although both the medium access control estimated by the medium access control layer acknowledgements. Although both the medium and the message authentication code are abbreviated as MAC, we only use MAC as the message access control and the message authentication code are abbreviated as MAC, we only use MAC as authentication code to avoid confusion in the paper. Finally, it is important to note that our work can the message authentication code to avoid confusion in the paper. Finally, it is important to note that be applied to code dissemination with the fixed packet size as well as the dynamic packet size. our work can be applied to code dissemination with the fixed packet size as well as the dynamic A BS,size. which is a source in our work, is assumed to be responsible for securely disseminating packet a code image all sensor nodes the WSNis over multihop communications and always trustworthy. A BS, to which is a source in in our work, assumed to be responsible for securely disseminating a Eachcode node then authenticates the code image by verifying the authentication tokens. All cryptographic image to all sensor nodes in the WSN over multihop communications and always trustworthy. primitives, including hash functions, MACs and by digital signatures, are assumedtokens. to be secure. Each node then authenticates the code image verifying the authentication All We assume that an attacker’s goal ishash to inject a malicious code intosignatures, the WSNare in assumed order totoget cryptographic primitives, including functions, MACs and digital be the secure. Weofassume that attacker’s is toFurthermore, inject a malicious into the WSN in order get to information interest orandisable thegoal WSN. the code attacker is assumed to betoable the information interest or disablebut thenot WSN. Furthermore, the attacker is assumed to be able to compromise sensorofnodes physically, infinitely. compromise sensor nodes physically, but not infinitely.
4.2. Bloom Filter 4.2. Bloom Filter
The Bloom filter [24] is a space-efficient probabilistic data structure used to examine the The Bloom filter [24]inis the a space-efficient probabilistic data structure used of to m examine the membership of an element set. The Bloom filter consists of a bit array bits, initially membership of an element in the set. The Bloom filter consists of a bit array of m bits, initially all all set to 0, and k different hash functions used to map an element into one of positions in a bitset array to 0, and k different hash functions used to map an element into one of positions in a bit array with with a random uniform distribution. When adding an element to the Bloom filter, k hashes of an a random uniform distribution. When adding an element to the Bloom filter, k hashes of an element element are calculated using k hash functions and the bits on the position of k hashes are set to 1. are calculated using k hash functions and the bits on the position of k hashes are set to 1. To test To test whether an element is a member of the set, k hashes of an element are computed with k hash whether an element is a member of the set, k hashes of an element are computed with k hash functions. If any ofkkhashes hashesisis element is definitely a member of the functions. If anybit biton onthe theposition position of 0, 0, thethe element is definitely not anot member of the set. set. IfIfall allbits bitsare are1,1,the theelement elementisisregarded regardedasasa amember member of the set. Unfortunately, a false positive, of the set. Unfortunately, a false positive, indicating thatthat a non-member element cancan pass thethe membership indicating a non-member element pass membershiptest, test,can canoccur occurdue duetotothe thelimited limitedsize of the Bloom and the and duplicate occurrence of hashoffunctions between different elements. Figure 4 size of thefilter Bloom filter the duplicate occurrence hash functions between different elements. illustrates Bloom filter. Figure 4a illustrates a Bloom filter.
Figure 4. An example of the Bloom filter.
Figure 4. An example of the Bloom filter.
5. Proposed Source Authentication Schemes
5. Proposed Source Authentication Schemes
In this section, we propose three source authentication schemes for code dissemination In this section, we propose three source authentication for codesecurity dissemination supporting supporting dynamic packet size. Source authentication, theschemes most significant requirement for
dynamic packet size. Source authentication, the most significant security requirement for code
Sensors 2016, 16, 1063 Sensors 2016, 16, 1063
7 of 22
7 of 22
code dissemination in WSNs, ensures that a new code image is really sent by the BS and not altered dissemination in WSNs, ensures that a new code image is really sent by the BS and not altered in transit. in transit. Note that, for simplicity, we explain our schemes in the first hop which is between the BS Note that, for simplicity, we explain our schemes in the first hop which is between the BS and the neighbor and the neighbor node but this procedure continues to all sensor nodes in the WSN over multihop node but this procedure continues to all sensor nodes in the WSN over multihop communications. communications.
5.1. Simple Packet Aggregation (SPA) 5.1. Simple Packet Aggregation (SPA) The simplest way to support source authentication for code dissemination with variable packet The simplest way to support source authentication for code dissemination with variable packet sizesize is to aggregate packets as as depicted in Figure 5. We employ a Secure Deluge [1][1] which uses is simply to simply aggregate packets depicted in Figure 5. We employ a Secure Deluge which a hash chain. In this scheme, a source can precompute a hash value of the next packet and embed uses a hash chain. In this scheme, a source can precompute a hash value of the next packet and it in the current sincepacket a newsince code aimage is built prior theprior transmission. Then, a receiver embed it in packet the current new code image is to built to the transmission. Then, can a authenticate the next packet using the previously received hash value. receiver can authenticate the next packet using the previously received hash value.
Figure5. 5. An An example example of Figure of SPA. SPA.
When a new code image is available, a BS splits it into pages which are further divided into Whenwith a new codesize. image is available, a BS splits it into pages are further divided into packets a fixed All packets are indexed sequentially, and a which hash value is calculated using packets withpacket a fixedonsize. packets are The indexed a hash value calculated using the the next the All reverse order. hashsequentially, value is thenand appended to theisend of the current next packet on the reverse order. The hash value is then appended to the end of the current packet, packet, thereby forming a basic packet which is the basic unit to be transmitted as follows: thereby forming a basic packet which is the basic unit to be transmitted as follows: hi , j 1 H ( BPi , j 1 ), i[1, x ], j [1, y 1] Pkti , j ||hi , j 1 , $ ˇˇ HHpBP 1], y j P r1, y ´ 1s ( BPi1,1 ), iq,[1,ix P (1) ’ BP Pkti , ji,j ˇˇPkt hi,ji ,`j ||1h,i1,1 , hi,j`hi11,1“ r1,j xs, & i,j`1 ˇˇˇˇ Pkt , i x , j y j , BPi,j “ (1) Pkti,j hi`i , 1,1 hi`1,1 “ HpBPi`1,1 q, i P r1, x ´ 1s, j “ y ’ % Pkt , i “ x, j “ y i,j
Sensors 2016, 16, 1063
8 of 22
where Pkti,j is a j-th packet in Page i and hi,j is a hash value on the basic packet containing Pkti,j . x and y are the number of pages in the code image and the number of packets in one page, respectively. Finally, the hash of the first basic packet (h1,1 ) is signed by the BS with the BS’s private key to ensure source authentication. Figure 5a shows how to create basic packets with a hash value. Once basic packets are ready, the BS first sends a hash value on the first basic packet (h1,1 ) with a digital signature (sig(h1,1 )) to a neighbor node. The receiver first verifies the digital signature of the hash using a BS’s public key preloaded in each sensor node prior to deployment. If the digital signature is valid, the receiver stores the hash value which is used to authenticate the subsequent basic packet. The BS now transmits packets to the neighbor node by aggregating basic packets depending on the link quality as follows: BS Ñ ˚ :
ˇˇ ˇˇ ˇˇ ˇˇ rheaderˇˇ BPi,j ˇˇ BPi,j`1 ˇˇ¨ ¨ ¨ˇˇ BPi,j`n s
(2)
where n depends on the link quality. It is worth noting that the BS can send basic packets without aggregation in severe channel condition. Upon receiving an aggregated packet, the receiver splits it into the original basic packets. This is easy because each sensor node knows the length of a basic packet. After calculating the hash value on the first basic packet, the receiver compares it with the previously received hash value. Denoting the previously received hash value and the currently received basic packet by hi,j and BPi,j , the basic packet is considered valid if: hi,j ““ HpBPi,j q ,
i P r1, xs, j P r1, ys
(3)
where H is a hash function. If the hash values are the same, the basic packet is authenticated and the receiver assures that it comes from the real BS and is not modified during transmission. Finally, the hash value in the basic packet is stored to be used to authenticate the next packet. In the same way, all next packets can be verified. When all packets in one page are received, the receiver becomes a new sender. A new sender can send a packet by aggregating basic packets depending on the link quality. Figure 5b,c illustrates the process of aggregation and verification. The SPA scheme is very simple, but has the hash overhead per basic packet and supports only the multiples of the size of a basic packet. 5.2. MAC Based Source Authentication (MBSA) MBSA makes use of peer-to-peer MACs to support any variable-size packets. However, MACs do not provide authenticity of the BS, which means that MACs authenticate the corresponding node only rather than the BS. To provide an authenticity of the BS, we employ a hash chain per page. Note that the previous SPA scheme uses a hash chain per packet. In this scheme, a new code image is split into pages only unlike Deluge, after which all pages are indexed sequentially. Similar to the SPA scheme, a hash value on the next page is calculated and appended to the end of the page for the entire image, which together form a basic page as follows: # BPagei “
Pagei || hi`1 , Pagei ,
hi`1 “ HpBPagei`1 q, i P r1, x ´ 1s i“x
(4)
where Pagei is a i-th page and hi is a hash value on the basic page containing Pagei . x is the number of pages in the code image. Finally, the hash of the first page is signed by the BS with the BS’s private key. This is illustrated in Figure 6a. When sending a new code image, the BS first sends a hash value on the first basic page (h1 ) with a digital signature (sig(h1 )) to a neighbor node. The receiver verifies the digital signature of the hash using a BS’s public key and keeps the hash value which is used to authenticate the subsequent basic page. The BS then decides the packet size depending on the link quality and attaches a MAC to the end of the packet using a symmetric key between the BS and the receiver. It is important to note that each node is assumed to have a symmetric key with neighbor nodes using any kind of key distribution schemes.
Sensors 2016, 16, 1063 Sensors 2016, 16, 1063
9 of 22 9 of 22
Figure 6. 6. An Figure An example exampleofofMBSA. MBSA.
The resulting packet format for transmission in the MBSA scheme is expressed as follows: The resulting packet format for transmission in the MBSA scheme is expressed as follows: BS : [header || payloadi || MAC ( payloadi )] (5) BS Ñ ˚ : rheader||payload ||MACppayload qs (5) where payloadi is the part of the basic page which cani have any size. iFigure 6b illustrates how to send packets using MACs in the sender. Upon receiving a packet, the receiver node first verifies the where payloadi is the part of the basic page which can have any size. Figure 6b illustrates how to send attached MAC. If it is not valid, the packet is not from the sender, thus discarded. If the packet is packets using MACs in the sender. Upon receiving a packet, the receiver node first verifies the attached successfully verified as valid, it is parsed and kept in the internal buffer for making up a page. Once MAC. If it is not valid, the packet is not from the sender, thus discarded. If the packet is successfully all packets in one page are received, the hash of the total page is calculated and compared to the verified as valid, it is parsed and keptpage. in theThe internal making up a page.if:Once all packets in hash value included in the previous entire buffer page isfor considered authentic one page are received, the hash of the total page is calculated and compared to the hash value included hi H ( BPagei ),authentic i[1, xif: ] (6) in the previous page. The entire page is considered where hi is the previously received hash value for the i-th basic page and BPagei is the currently hi ““ HpBPage i Ppacket-level r1, xs i q, received i-th basic page. Figure 6c,d shows the procedure of verification using MACs (6) and page-level verification using the hash chain, respectively. where hi is the previously received hash value for the i-th basic page and BPagei is the currently The MBSA scheme supports source authentication for fully variable packet size by combining received i-th basic page. Figure 6c,d procedure of packet-levelvia verification using MACs both hop-by-hop authentication viashows MACsthe and source authentication a page-level hash chain.and page-level verification using the hash chain, respectively.
Sensors 2016, 16, 1063
10 of 22
The MBSA scheme supports source authentication for fully variable packet size by combining both hop-by-hop authentication via MACs and source authentication via a page-level hash chain. Since this scheme needs only one MAC for variable-size packet, this scheme has less communication overhead than the SPA scheme. Moreover, it is more efficient in terms of energy consumption because it supports fully variable packet size so that it can be optimized for the link quality. The disadvantage of this scheme is that it can be vulnerable to node capture attacks. In this case, attackers can forge malicious packets with the valid MAC. However, it can be easily detected by the page-level hash chain. 5.3. Bloom Filter Based Source Authentication (BFBSA) BFBSA takes advantage of a Bloom filter to verify the authenticity of packets. Like SPA, the BS splits a new code image into pages which are further divided into fixed-size packets called basic packets. It is important to note that basic packets in BFBSA is the same as packets while basic packets in SPA consist of packets and a hash value on the next basic packet. The BS then makes a m-bit length Bloom filter by applying k different hash functions to all basic packets as follows: # BFrHn pPkti,j qs “
1, 0,
n P r1, ks, i P r1, xs, j P r1, ys otherwise
(7)
where BF[] is a m-bit array indicating a Bloom filter and Hn is a hash function which maps packets into an integer with a range of 0 to m-1. When the Bloom filter is built, the BS broadcasts the entire Bloom filter to all sensor nodes together with a hash value on the first basic page (h1 ) after signing with a BS’s private key. It is important to note that h1 is used to verify authenticity and integrity of the page for defending against malicious packets due to false positive property of the Bloom filter. After each sensor node verifies a digital signature of the Bloom filter with a BS’s public key, it stores the Bloom filter to authenticate the subsequent packets. The BS now sends a new code image to the neighbor nodes with variable-size packets, depending on the link quality as follows: ˇˇ ˇˇ ˇˇ ˇˇ BS Ñ ˚ : rheaderˇˇ Pkti,j ˇˇ Pkti,j`1 ˇˇ¨ ¨ ¨ˇˇ Pkti,j`n s
(8)
where n depends on the link quality, and the last packet can be fragmented. It is important to note that unlike previous schemes, there is no overhead for each packet such as MACs and hash values. Upon receiving a packet, the receiver node splits it into basic packets, each of which is then verified using the Bloom filter with k different hash functions. The basic packet is considered authentic if it satisfies the following equation: BFrHn pPkti,j qs ““ 1,
@n P r1, ks
(9)
If it fails to pass the test, it definitely is not a valid packet. However, the authenticated packets might be forged packets due to false positive. To overcome this problem, we must adjust k and m appropriately which will be investigated in detail in Section 6. In addition, we add a hash value on the next page to the end of the last packet in each page. After receiving all packets in the page, the receiving node can verify the authenticity of the whole page with the hash value. This entire process is illustrated in Figure 7. This scheme incurs storage and communication overhead for the Bloom filter but has no communication overhead in each packet. In addition, this scheme can support fully variable-size packets.
Sensors 2016, 16, 1063 Sensors 2016, 16, 1063
11 of 22 11 of 22
Figure7. 7. An An example example of Figure of BFBSA. BFBSA.
6. Security Analysis 6. Security Analysis In this section, we evaluate our three source authentication schemes in terms of security aspects, In this section, we evaluate our three source authentication schemes in terms of security aspects, more specifically, authenticity, resilience to node capture attacks and DoS attacks. more specifically, authenticity, resilience to node capture attacks and DoS attacks. 6.1. SPA 6.1. SPA Security of the SPA scheme depends on the security of hash functions and digital signatures. In Security of functions the SPA scheme depends the security of hash functions digital signatures. general, hash are assumed to beon secure which means that given y, and it is computationally In infeasible general, hash functions are assumed to be secure which means that given y, it is computationally to find x such that h(x) = y. In addition, a BS is assumed to be always secure, thus the BS’s infeasible x suchexposed that h(x)to= attackers. y. In addition, a BS is assumed to besigned alwaysbysecure, the BS’s private to keyfind is never Hence, a digital signature the BSthus is always private key is never exposed to attackers. Hence, a digital signature signed by the BS is always secure secure which implies that any attacker cannot forge a valid digital signature of the BS. In the SPA which implies that any attacker cannot forge a valid digital signature of the BS. In the SPA scheme, scheme, every packet is authenticated by the previously received hash value. Since a hash function every packet istoauthenticated the previously received hash value. Since a hash function assumed is assumed be secure, the by adversary cannot fabric a malicious packet with the same hashisvalue as to be the adversary cannot fabric malicious with the same value asevery the previously thesecure, previously received hash value. In aother words,packet the SPA scheme canhash authenticate packet
Sensors 2016, 16, 1063
12 of 22
received hash value. In other words, the SPA scheme can authenticate every packet securely. Now let’s think about the case where a sensor node is captured and controlled by an adversary, who can access and extract all the materials (e.g., hi,j ) in the node. However, the only thing that the adversary can do is to drop packets since it is infeasible to fabric a malicious packet to have hi,j . If he modifies packets or injects malicious packets, it will be detected immediately through an invalid hash value. DoS attacks in the hash-chain based authentication scheme refers to the situation where the adversary try to make the buffer of receivers full by sending invalid packets repeatedly so that receivers get crippled. The SPA scheme is vulnerable to DoS attacks since it uses a hash chain containing the hash value of the next packet. If one packet is missing, all the subsequent packets cannot be authenticated and thus the buffer becomes full. 6.2. MBSA Since the MBSA scheme uses a page-level hash chain, it can authenticate each page just as the SPA scheme authenticates each packet. However, this page-level authentication is vulnerable to DoS attacks because it has to keep all received packets to make up a page. In this scheme, DoS attacks can be circumvented by hop-by-hop authentication using MACs with a symmetric key. If any node without a symmetric key attempts to inject malicious packets, it will be detected by the MAC. Unfortunately, this scheme is susceptible to node capture attacks. Once a sensor node is compromised, all information, including all symmetric keys with neighbor nodes, is disclosed to the adversary. Therefore, the adversary can easily inject malicious packets to the neighbors. However, this can be prevented by the page-level hash (hi ) since the adversary cannot fabricate a whole page which has hi . In summary, the MBSA scheme provides an immediate authentication using MACs, thus it is robust to DoS attacks as long as sensor nodes are not compromised. However, the MBSA scheme is weak to node capture attacks since compromised nodes can send forged packets to their neighbors, but the page-level hash constrains the effect within the page. 6.3. BFBSA Security of BFBSA depends on the probability of false positive. Given the number of basic packets, N, and a bit array of the Bloom filter with m bits, the probability p of false positive, with optimal k = (m/N)ln 2, is as follows [25]: m (10) p “ p0.6185q N Obviously, p decreases with lower N and higher m as shown in Figure 8. In code dissemination in WSNs, the number of basic packets, N, is predetermined according to the size of a new code image. Given N, the probability of false positive with regard to m is determined using (10). For example, we assume that N is set to 1000 packets. When m is configured as 1000 bits, p becomes 0.6185 which is very high. However, when m increases from 1000 bits to 10,000 bits, p becomes 0.0082 which is much less than 0.6185. Furthermore, when m is set to 100,000 bits, p is 1.36 ˆ 10´21 . This means that approximately 269 elements have to be generated for an attacker to fabric a false positive packet. Therefore, the BFBSA scheme can authenticate every packet securely with a proper configuration of m. We set m/N to 92 targeting at the false positive probability of 6.36 ˆ 10´20 which is assumed to be secure in [26]. In addition, even if a false positive occurs, it can be detected by the page-level hash. Regarding node capture attacks in BFBSA, compromised nodes cannot do anything but to discard packets since it is infeasible for them to build forged packets to pass the Bloom filter and the page-level hash. Moreover, BFBSA is resilient to DoS attacks since it provides an immediate authentication per packet.
Sensors 2016, 16, 1063
13 of 22
Sensors 2016, 16, 1063
13 of 22
Sensors 2016, 16, 1063
13 of 22
Figure8.8.The Theprobability probability of of false false positive Figure positivein inthe theBloom Bloomfilter. filter.
7. Performance Evaluation 7. Performance Evaluation 8. Thelimited probability of false positive the Bloom must filter. be minimized to reduce Since sensor nodes Figure have very resources, variousinoverhead Since sensor nodes have very limited resources, various overhead must be minimized to reduce energy consumption. In this section, we evaluate our proposed three source authentication schemes energy consumption. In this section, and we evaluate our proposed three source schemes Performance Evaluation in 7. terms of computation overhead communication overhead through anauthentication analytical approach. in We terms of computation overhead and communication overhead through an analytical approach. then compare the results with Secure Deluge, which provides authentication Since sensor nodes have very limited resources, various overhead mustsource be minimized to reducefor Wefixed-size then compare the results with Secure Deluge, which provides source authentication fixed-size packets and has lower overhead than existing well-known secure code dissemination energy consumption. In this section, we evaluate our proposed three source authentication for schemes packets and has lower overhead than existing well-known secure code dissemination protocols protocols in Section 2. and communication overhead through an analytical approach. as in termsasofpresented computation overhead presented in Section 2. the results with Secure Deluge, which provides source authentication for We then compare 7.1.fixed-size Environment for Performance Evaluation packets and has lower overhead than existing well-known secure code dissemination 7.1. Environment for Performance Evaluation protocols as presented in Section 2. The goal of the performance evaluation is to show that our proposed schemes can reduce The goal of the performance evaluation is code to show that our proposed schemes can reduce energy consumption when integrating with dissemination supporting dynamic packet energy size 7.1. Environment for Performance Evaluation consumption when integrating dissemination supporting packet link size according according to the link quality.with We code assume a simple 3-hop topologydynamic with different quality as to The goal the performance evaluation isistoassigned show that schemes can reduce in Figure where bit error3-hop rate (BER) to our eachproposed linkquality to indicate excellent (PRR: 9, theshown link quality. Weof9,assume a simple topology with different link as shown in Figure energy consumption when integrating with code dissemination supporting dynamic packet size 0.99),a fair (PRR:rate 0.75)(BER) and bad (PRR: 0.5)tolink quality when the packet size (PRR: is 133 bytes a where bit error is assigned each link to indicate excellent 0.99), that fair include (PRR: 0.75) according to the link quality. We assume a simple 3-hop topology with different link quality as PHY header (6 bytes) and a maximum medium access control protocol data unit (127 bytes) in IEEE and bad (PRR: 0.5) link quality when the packet size is 133 bytes that include a PHY header (6 bytes) shown in Figure 9, where a bit error rate (BER) is assigned to each link to indicate excellent (PRR: 802.15.4 [27] asmedium shown inaccess Figure 10. Weprotocol assumedata that unit code dissemination is performed[27] in sequential and a0.99), maximum bytes) size in IEEE as shown in fair (PRR: 0.75) and bad control (PRR: 0.5) link quality when(127 the packet is 133802.15.4 bytes that include a order, thus no collisions due todissemination channel contention occur ininthe simple 3-hop topology. We employ Figure 10. We assume that code is performed sequential order, thus no collisions due PHY header (6 bytes) and a maximum medium access control protocol data unit (127 bytes) in IEEE 802.15.4 as the occur medium access layer3-hop wheretopology. we use the beacon-enabled mode, and do use to IEEE channel in the simple We employ IEEE 802.15.4 thenot medium 802.15.4contention [27] as shown in Figure 10. We assume that code dissemination is performed inas sequential the acknowledgement as shown in Figure 10. In order to take the practical environment into access layerthus where we use the mode,occur and in dothe notsimple use the acknowledgement as shown order, no collisions duebeacon-enabled to channel contention 3-hop topology. We employ account, the duty cycle is set to 50%layer by setting theuse value of the macSuperframeOrder (SO) for the IEEE 802.15.4 as the medium access where we the beacon-enabled mode, and do not use in Figure 10. In order to take the practical environment into account, the duty cycle is set to 50% by superframe duration (SD)astoshown 6 and the value of (BO) for the environment beacon interval thethe acknowledgement in Figure 10.the InmacBeaconOrder order to take the practical into(BI) setting value of the macSuperframeOrder (SO) for the superframe duration (SD) to 6 and the value to 7 as shown in Figure 10.set Astoa 50% result, node packets as a long frame(SO) in the active the duty cycle by the setting thetransmits value theshown macSuperframeOrder the the of theaccount, macBeaconOrder (BO)isfor the beacon interval (BI) to 7ofas in Figure 10. As afor result, period while entering the sleep mode in theofinactive period. The(BO) longfor frame is the interval IEEE 802.15.4 superframe duration (SD) to 6 and the value the macBeaconOrder the beacon (BI) node transmits packets as a long frame in the active period while entering the sleep mode in the data where size10. of As medium access control protocol data unit (MPDU) is in larger than 18 to 7frame as shown in the Figure a result, the node transmits packets as a long frame the active inactive period. The long frame is the IEEE 802.15.4 data frame where the size of medium access bytes, followed by a longthe interframe spacing period. We employ the energy of TelosB period while entering sleep mode in the(LIFS) inactive period. The long frame is the model IEEE 802.15.4 control protocol unit is larger than 18 bytes, followed a long interframe spacing data frame the (MPDU) sizeused of medium access control databy unit (MPDU) is larger than 18(LIFS) [28], which is where adata commonly sensor node [15–17], asprotocol follows. period. We employ the energy model of TelosB [28], which is a commonly used sensor node [15–17], bytes, followed by a long interframe spacing (LIFS) period. We employ the energy model of TelosB E Erx Etx Emcu Eidle Esleep (11) as follows. [28], which is a commonly used sensor node [15–17], as follows. E “ EErxE` EEtx ` ` Eidle (11) EEmcu E E ` Esleep rx
tx
mcu
idle
sleep
Figure 9. Configuration for the performance evaluation. Figure 9. Configuration for the performance evaluation.
Figure 9. Configuration for the performance evaluation.
(11)
Sensors 2016, 16, 1063
14 of 22
Sensors 2016, 16, 1063
14 of 22
Sensors 2016, 16, 1063
14 of 22
Figure 10. The structure of IEEE 802.15.4 superframe in the performance evaluation. Figure 10. The structure of IEEE 802.15.4 superframe in the performance evaluation.
For the sake of simplicity, we do not consider the energy consumption for the transition Figure 10. IEEE 802.15.4 superframe in the performance For the sake of simplicity, we do consider the energy consumption forevaluation. the transition procedure among TX,The RX,structure and offofnot state, and assume that the CC2420 makes a transition toprocedure the off among TX, RX, and off state, and assume that the CC2420 makes a transition to the off state immediately state immediately after completing data transmission. Erx and Etx are the energy consumed when For the sake of simplicity, we do not consider the energy consumption for the transition afterthe completing data transmission. Erxand andthe Etxradio are the energy microcontroller microcontroller unit (MCU) is on is RX or TX,consumed Emcu is the when energythe consumed when procedure among TX, RX, and off state, and assume that the CC2420 makes a transition to the off MCUisis on on and and the idle is theEenergy consumed the MCU is idle theisradio unitthe (MCU) the radio radioisisoff, RXEor TX, energy when consumed when the and MCU on and mcu is the state immediately after completing data transmission. Erx and Etx are the energy consumed when is off, and Esleep is the energy consumed whenwhen the node is in the mode. otheriswords, Erx Eand the radio is off, Eidle is the energy consumed the MCU is sleep idle and theInradio off, and sleep is the microcontroller unit (MCU) is on and the radio is RX or TX, Emcu is the energy consumed when E tx are the energy consumption for receiving and transmitting the code image, and E mcu corresponds the energy consumed theisnode in the sleep mode. In other words, Erx and Etx are the energy the MCU is on and when the radio off, Eis idle is the energy consumed when the MCU is idle and the radio to the energy consumption for performing the cryptographic operations such as digital to signatures, consumption for receiving and transmitting code isimage, and Emode. energy mcu corresponds is off, and Esleep is the energy consumed when the node in the sleep In other words, the Erx and MACs and hashes. In addition, E idle is the energy consumption during the backoff period and the consumption for performing cryptographic such asthe digital signatures, and hashes. Etx are the energy consumption for receivingoperations and transmitting code image, and EMACs mcu corresponds LIFS in the active period, and Esleep is the energy consumption in the inactive period in Figure 10. In addition, Eidle isconsumption the energy consumption during the backoffoperations period andsuch the LIFS in thesignatures, active period, to the energy for performing cryptographic as digital The energy consumption in each mode is computed by multiplying the time in each mode with the and MACs Esleep isand thehashes. energyInconsumption period in Figure 10.the The energy consumption addition, Eidlein is the the inactive energy consumption during backoff period and the in supply voltage and the current in each mode of TelosB which is shown in Table 1. For example, Etx LIFS in the active period, and E sleep is the energy consumption in the inactive period in Figure 10. each mode is computed by multiplying the time in each mode with the supply voltage and the current for transmitting a 40-byte packet is (40 bytes × 32 μs) × 3 V × 19.5 mA = 74.88 μJ. The energy consumption in each mode is computed by multiplying the time in each mode with the in each mode of TelosB is shown in Table 1. For example, Etx for transmitting 40-byte We assume thatwhich the underlying code dissemination protocol is Deluge, and a apage size packet and a is supply voltage and the current in = each mode of TelosB which is shown in Table 1. For example, Etx (40 bytes ˆ 32 µs) ˆ 3 V ˆ 19.5 mA 74.88 µJ. packet size are configured to 1024 bytes and 22 bytes which are the default configurations of Deluge for transmitting a 40-byte packet is (40code bytesdissemination × 32 μs) × 3 V ×protocol 19.5 mA =is74.88 μJ. and a page size and assume Deluge, inWe TinyOS. Thethat sizethe of aunderlying code image to be disseminated is 10 kB, 20 kB and 30 kB. Additionally, the We assume that the underlying code dissemination protocol is Deluge, and a page size and a a packet size are configured to 1024 bytes and 22 bytes which are the default configurations of data Deluge underlying code dissemination protocol is assumed to be able to optimize the size of the packet size are configured to 1024 bytes and 22 bytes which are the default configurations of Deluge in TinyOS. size of a code image to be disseminated kB, 20 and 30 to kB.the Additionally, payloadThe in the medium access control service data unit is in 10 Figure 11 kB according given BER inthe in TinyOS. The size of a code image to be disseminated is 10 kB, 20 kB and 30 kB. Additionally, the terms ofcode the transmission overhead (TO) which is defined as to optimize the size of the data payload underlying dissemination protocol is assumed to be able underlying code dissemination protocol is assumed to be able to optimize the size of the data in the medium access control service dataservice unit indata Figure to the given BER in terms of the payload in the medium access control unit11 in according Figure 11 according to the given BER in transmission overhead (TO)overhead which is (TO) defined as is defined as terms of the transmission which
Figure 11. The format of IEEE 802.15.4 data frame. Figure 11. The format of IEEE 802.15.4 data frame.
Figure 11. The format of IEEE 802.15.4 data frame.
Sensors 2016, 16, 1063
15 of 22
Total amount o f bytes to be transmitted Payload sizepbytesq phdr`xq{ PRR hdr ` x “ “ x x¨p1´ BERq8phdr`xq d TOpxopt q “ 0 Find xopt Ñ dx b $ to minimize TOpxq & ´4¨hdr¨lnp1´BERq´ p4¨hdr¨lnp1´BERqq2 ´8¨hdr¨lnp1´BERq xopt “ 8¨lnp1´ BERq
TO pxq “
%
(12) i f xopt ă 110 i f xopt ě 110
110
where x is the size of the data payload in Figure 11, and hdr includes all headers in Figure 11 and all cryptographic overhead such as hashes and MACs. Since the total amount of the data payload, which is the size of the code image, is fixed in code dissemination, the total transmitted bytes decrease as TO becomes lower, thus reducing energy consumption. For the sake of simplicity, we assume that the optimal payload size, which minimizes TO in Equation (12), of each scheme in each link is predetermined by applying BER and hdr into Equation (12) as shown in Table 2. Each packet is lost in each hop with the probability of PER = 1 – PRR = 1 ´ (1 ´ BER)8L where L is a packet size, including the data payload and the header, in bytes. The lost packet is retransmitted according to the procedure of Deluge as shown in Figure 1b. It is important to note that all kinds of Deluge messages such as the ADV, the REQ and DATAs are transmitted as a long frame in the active period in Figure 10 since the MPDU size of all Deluge messages is larger than 18 bytes. Other parameters for the performance evaluation are summarized in Table 1. Table 1. Parameters for Performance Evaluation. Parameter
Value (B: Bytes)
Description
Lheader Lpage
23 B 1024 B
Lpaylod
variable
LADV
29 B
LREQ
32 B
the header size (PHY: 6 B, Medium Access Control: 11 B, Deluge: 6 B) the default page size of Deluge in TinyOS the payload size for DATAs (the default payload size of Deluge in TinyOS: 22 B) the size of the ADV (PHY header: 6 B, Medium Access Control header: 11 B, Deluge: 12 B) the size of the REQ (PHY header: 6 B, Medium Access Control header: 11 B, Deluge: 15 B) the hash size in SHA-1 the MAC size in HMAC the digital signature size in ECDSA-160 false positive of 6.36 ˆ 10´20 (m/N)ln 2 unit: kB the supply voltage in TelosB [28] the current when the MCU is on and the radio is TX in TelosB [28] the current when the MCU is on and the radio is RX in TelosB [28] the current when the MCU is on and the radio is off in TelosB [28] the current when the MCU is idle and the radio is off in TelosB [28] the current when the MCU is standby and the radio is off in TelosB [28] the parameters to determine SD and BI the duration of SIFS (short interframe spacing) the duration of LIFS (long interframe spacing) the backoff period. r is a random value between 0 and 3 the duration of the inactive period when SO and BO is 6 and 7 the time for transmitting one byte in TelosB the long frame period over which a ADV/REQ/DATA is transmitted frame size (bytes) ˆ byte transmission time (32 µs) the hash computation time in TelosB [29] the MAC computation time in TelosB [29] the signature verification time in TelosB [30]
Lhash LMAC Lsig m/N k code image size Vsup Itx Irx Imcu Iidle Isleep SO/BO TSIFS TLIFS Tbackoff Tinactive Tbyte
20 B 20 B 40 B 92 64 10/20/30 3V 19.5 mA 21.8 mA 1.8 mA 54.5 µA 5.1 µA 6/7 192 µs 640 µs R ˆ 320 µs 983,040 µs 32 µs
Tlong
variable
Thash TMAC Tsig
0.35 ms 0.71 ms 1.02 s
Sensors 2016, 16, 1063
16 of 22
Table 2. Optimal Payload Size. Scheme
hdr in Equation (12)
Payload Size (Bytes)
Secure Deluge SPA MBSA BFBSA
43 (header: 23, hash: 20) 63 (header: 23, hash: 40) 43 (header: 23, MAC: 20) 23 (header: 23)
22 44 90 110
(Fair)
Secure Deluge SPA MBSA BFBSA
43 (header: 23, hash: 20) 63 (header: 23, hash: 40) 43 (header: 23, MAC: 20) 23 (header: 23)
22 44 90 92
(Bad)
Secure Deluge SPA MBSA BFBSA
43 (header: 23, hash: 20) 63 (header: 23, hash: 40) 43 (header: 23, MAC: 20) 23 (header: 23)
22 22 72 56
BER
9.44 ˆ
10´6
(Excellent)
2.70 ˆ
10´4
6.51 ˆ
10´4
7.2. Computation Overhead We consider computation overhead needed for each node to authenticate an entire code image. Computation overhead per node in each scheme is as follows: basic CPSecureDeluge “ Csig ` Npkt ¨ Chash
(13)
basic CPSPA “ Csig ` Npkt ¨ Chash
(14)
tx CPMBSA “ Csig ` Npage ¨ Chash ` 2 ¨ Npkt ¨ C MAC
(15)
basic CPBFBSA “ Csig ` Npage ¨ Chash ` Npkt ¨ k ¨ Chash
(16)
where Csig , Chash and CMAC denote the computation overhead of digital signatures, hash operations and MAC operations, respectively. Npage is the number of pages, which is determined as basic is the number of packets in the entire code image, which is rcode image size { page sizes. Npkt tx is the number of packets transmitted actually computed as Npage ˆ rpage size { packet sizes. Npkt under the given link quality. k is the number of hash functions used in the Bloom filter. From Equations (13)–(16), we can derive the energy consumption due to computation overhead as follows: SecureDeluge
Emcu
basic “ Imcu ¨ Vsup ¨ Tsig ` Npkt ¨ Imcu ¨ Vsup ¨ Thash
(17)
SPA basic Emcu “ Imcu ¨ Vsup ¨ Tsig ` Npkt ¨ Imcu ¨ Vsup ¨ Thash
(18)
MBSA tx Emcu “ Imcu ¨ Vsup ¨ Tsig ` Npage ¨ Imcu ¨ Vsup ¨ Thash ` 2 ¨ Npkt ¨ Imcu ¨ Vsup ¨ TMAC
(19)
BFBSA basic Emcu “ Imcu ¨ Vsup ¨ Tsig ` Npage ¨ Imcu ¨ Vsup ¨ Thash ` Npkt ¨ k ¨ Imcu ¨ Vsup ¨ Thash
(20)
Since the computation overhead shows similar results in each link quality, we only present Figure 12 which shows the energy consumption for performing cryptographic operations in the bad channel condition. Obviously, computation overhead of the BFBSA scheme is the largest among all of schemes since BFBSA performs many more hash operations to verify the membership of each packet against the Bloom filter. It is worth noting that the computation overhead is constant in each hop regardless of the link quality because the lost packets can be retransmitted without computation.
Sensors 2016, 16, 1063 Sensors 2016, 16, 1063
17 of 22 17 of 22
Figure 12. Computation overhead in bad link quality. Figure 12. Computation overhead in bad link quality.
7.3. Communication Overhead 7.3. Communication Overhead In this subsection, the energy consumed for sending a code image to the neighbor node are In this subsection, the energy consumed for sending a code image to the neighbor node are computed and then compared with Secure Deluge. We first investigate the total bytes transmitted computed and then compared with Secure Deluge. We first investigate the total bytes transmitted for for an entire code image since communication overhead is very important in that it is directly an entire code image since communication overhead is very important in that it is directly related to related to energy consumption. When PRR is 1 which implies that no packet loss happens, total energy consumption. When PRR is 1 which implies that no packet loss happens, total transmitted transmitted bytes of each scheme is expressed as: bytes of each scheme is expressed as: CM Sec ureDeluge N basic (21) pkt ( L header L payload Lhash ) L sig N page ( L ADV L REQ ) basic CMSecureDeluge “ Npkt ¨ pLheader ` L payload ` Lhash q ` Lsig ` Npage ¨ pL ADV ` L REQ q (21) CM SPA N txpkt Lheader N basic (22) pkt ( L payload Lhash ) L sig N page ( L ADV L REQ ) tx CMSPA “ Npkt ¨L ` N basic ¨ pL payload ` Lhash q ` Lsig ` Npage ¨ pL ADV ` L REQ q (22) CM MBSA N txpkt header ( Lheader Lpkt MAC ) N page ( L page Lhash ) Lsig N page ( L ADV LREQ ) (23) tx CM MBSA “ Npkt ¨ pL ` L MAC q ` Npage ¨ pL page ` L q ` L ` Npage ¨ pL ADV ` L REQ q (23) CM BFBSA header N txpkt Lheader N page ( L page Lhash ) hash Lsig m sigN page ( L ADV LREQ ) (24) tx CMBFBSA “ Npkt ¨ Lheader ` Npage ¨ pL page ` Lhash q ` Lsig ` m ` Npage ¨ pL ADV ` L REQ q (24) , Lsig and LMAC denote the length of a header, a payload, a hash value, a where Lheader, Lpayload, Lhash where , Lsigrespectively. and LMAC denote the length of aare header, a payload, a hashtovalue, digital Lsignature and, L ahash MAC, All Deluge packets transmitted according IEEE header , Lpayload a802.15.4 digital presented signature and a MAC, All each Deluge packets are transmitted according to IEEE in Figure 10. respectively. In other words, packet is preceded by the backoff period and 802.15.4 presented in Figure 10. In other words, each packet is preceded by the backoff period and followed by the LIFS period. Therefore, the total energy consumption for sending one packet is followed LIFS period. Therefore, the total energy consumption for sending one packet is computedby as the follows: computed as follows: E pkt E backoff E txpkt E LIFS (25) I idle`VEsuppktT` I tx V sup Tbyte L pkt I idle V sup T LIFS backoff E pkt “ Ebacko ELIFS ff tx (25) “ Iidle ¨ Vsup ¨ Tbacko f f ` Itx ¨ Vsup ¨ Tbyte ¨ L pkt ` Iidle ¨ Vsup ¨ TLIFS where Ebackoff and ELIFS is the energy consumption during the backoff period and the LIFS period, respectively. consumption for during transmitting a packet withand thethe size of period, Lpkt. In Etxpkt Eis theis energy where E and the energy consumption the backoff period LIFS backoff
LIFS
pkt addition, theEreceiver node is assumed to be in the Rx state and thus the energy consumption can be respectively. tx is the energy consumption for transmitting a packet with the size of Lpkt . In addition, computed as I rx·Vsup·Trx where Trx is the duration over which the receiver node is in the RX state. the receiver node is assumed to be in the Rx state and thus the energy consumption can be computed Finally, Esleep energy consumption when the sender enters the inactive period in Figure as Irx ¨ Vsup ¨ T,rxwhich whereisTthe rx is the duration over which the receiver node is in the RX state. Finally, Esleep , 10, is calculated as I rx·Vsup·Tinactive. By considering all energy consumption not only for transmitting which is the energy consumption when the sender enters the inactive period in Figure 10, is calculated and the. code image but all also for the backoff period, the for LIFS period andand thereceiving inactive as Irxreceiving By considering energy consumption not only transmitting ¨ Vsup ¨ Tinactive period defined IEEE shown in Figure weperiod obtained consumption due in to the code image in but also802.15.4 for the as backoff period, the 10, LIFS andthe theenergy inactive period defined the communication overhead as shown in Figures 13–15, each of which corresponds to the excellent, IEEE 802.15.4 as shown in Figure 10, we obtained the energy consumption due to the communication fair and bad quality, respectively. overhead as link shown in Figures 13–15, each of which corresponds to the excellent, fair and bad link quality, respectively.
Sensors 2016, 16, 1063
18 of 22
Sensors 2016, 16, 1063
18 of 22
Sensors 2016, 16, 1063 Sensors 2016, 16, 1063
18 of 22 18 of 22
Figure 13. Communication overhead in excellent link quality. Figure 13. Communication overhead in excellent link quality. Figure 13. Communication overhead in excellent link quality. Figure 13. Communication overhead in excellent link quality.
Figure 14. Communication overhead in fair link quality. Figure 14. Communication overhead in fair link quality. Figure 14. Communication overhead in fair link quality. Figure 14. Communication overhead in fair link quality.
Figure 15. Communication overhead in bad link quality. Figure 15. Communication overhead in bad link quality. Figure 15. Communication overhead bad link quality. In excellent link Figure quality shown in Figure 13,in MBSA and BFBSA have lower 15.asCommunication overhead inSPA, bad link quality.
In excellentoverhead link quality as shown in Figure 13, SPA, MBSA have This lower communication than Secure Deluge by approximately 25.4%, and 55.4%BFBSA and 50.3%. is In excellent link quality as shown in Figure MBSA and though BFBSA have This lower communication overhead than adapt Secure by approximately 25.4%,even 55.4% and 50.3%. is because Secure Deluge cannot itsDeluge packet size to 13, the SPA, link quality larger packet In excellent link quality as shown in Figure 13, SPA, MBSA and BFBSA have lower communication communication overhead than Secure by approximately 25.4%, 55.4% and 50.3%. is because Secure Deluge cannot adapt itsDeluge packet size to quality. the linkMBSA quality even though larger This packet reduces communication overhead in the excellent link and BFBSA outperform SPA overhead than Secure Deluge by approximately 25.4%, 55.4% and 50.3%. This is because Securepacket Deluge because Secure Deluge cannot adapt its packet size to the link quality even though larger reduces communication in the excellent linkpacket quality. MBSA BFBSA outperform since MBSA and BFBSAoverhead can support fully variable size whileand SPA can only supportSPA the cannot adapt its packet size to support the link quality even though larger packet reduces communication reduces communication overhead in the excellent link MBSA and BFBSA outperform SPA since MBSA and BFBSA can fully variable packet size while SPA can only support the packet size of multiples of the basic packet. MBSA isquality. better than BFBSA since BFBSA need to overhead in the excellent link quality. MBSA and BFBSA outperform SPA MBSA and BFBSA since MBSA BFBSA canthe support fully variable packet sizethan while SPAsince can only support the packet size ofand multiples of the basic MBSA is better BFBSA since BFBSA need to N basic transmit a Bloom filter with size of packet. to guarantee a false positive probability of ( m / N ) pkt better packet size of multiples of the thesize basic packet. MBSA than since needofof tothe cantransmit support fully variable packet size while SPA can only support theBFBSA packetpositive size ofBFBSA multiples N basic is to a Bloom filter with of probability ( m / N ) −20 pkt Figure 14, SPA,guarantee MBSA anda false BFBSA outperforms Secure 6.36 × 10 . In fair link quality as shown inbasic basic MBSA is better BFBSA sinceBFBSA to transmit a Bloom filter with the of size transmit a Bloom with than the size of N to guarantee a false positive probability ( m / N ) need Q packet. U filter −20. In fair link quality as48.6% shownand inpktFigure SPA,that MBSA and between BFBSA outperforms Secure 6.36 × 10by Deluge approximately 18.6%, 42.2%. 14, Except the gap Secure Deluge and basic ´ 20 −20 of Deluge Npkt× 10ˆ guarantee false and positive probability ofthe 6.36 ˆ between 10 . In fair link quality .approximately In fair to link quality asa48.6% shown in Figure 14, SPA, MBSA and BFBSA outperforms Secure 6.36 bypm{Nq 18.6%, 42.2%. Except gap Secure Deluge and as proposed schemes decreases since a small-size packet inthat Secure Deluge results in higher PRR, Deluge by approximately 18.6%, 48.6% and 42.2%. Except that the gap between Secure Deluge and shown in Figure 14, SPA, MBSA and BFBSA outperforms Secure Deluge by approximately 18.6%, proposed schemes decreases since a small-size packet in Secure Deluge resultsDeluge in higher Figure 14 is similar to Figure 13. In bad link quality as shown in Figure 15, Secure andPRR, SPA proposed schemes decreases since a small-size packet in Secure Deluge results in higher PRR, 48.6% 42.2%. Except that the gap between Secure and proposed schemes decreases since Figure is similar to Figure 13. In bad link quality asDeluge shown in Figure 15,each Secure Deluge SPA has and the14same communication overhead since the optimal packet size of scheme is and identical Figure is similar to Figure 13. Inresults bad link quality as shown in 14 Figure 15,each Secure Deluge SPA a small-size packet in Secure Deluge in higher PRR, Figure is similar to scheme Figure 13. In bad link has the14 same communication overhead since the optimal packet size of is and identical has the same communication overhead since size of each scheme is identical quality as shown in Figure 15, Secure Deluge andthe SPAoptimal has thepacket same communication overhead since the
Sensors 2016, 16, 1063
19 of 22
Sensors 2016, 16, 1063
19 of 22
optimal packet size of each scheme is identical under bad link quality. MBSA and BFBSA has lower Sensors 2016, 16, 1063 19 of 22 under bad linkoverhead quality. MBSA and BFBSA hasby lower communication overhead than Secure communication than Secure Deluge approximately 36.1% and 36.5%. In this Deluge case, the by approximately 36.1% and 36.5%. In this case, the communication overhead of MBSA becomes communication of MBSA larger thancommunication BFBSA becauseoverhead the amount MAC Deluge overhead under bad linkoverhead quality. MBSA andbecomes BFBSA has lower thanofSecure larger than BFBSA because the amount of MAC overhead becomes larger as the packet size becomes larger as the packet becomes the Bloom filter size is regardless by approximately 36.1% andsize 36.5%. In thissmall case,whereas the communication overhead offixed MBSA becomes of becomes small whereas the Bloom filter size is fixed regardless of the packet size. Finally, the total amount of MAC overhead becomes larger as theoverhead packet size thelarger packetthan size.BFBSA Finally,because the totalthe communication overhead, summing communication in all communication overhead, summing communication overhead in all three hops, is shown in Figure becomes whereas the Bloom sizesee, is fixed regardless of less the packet size. Finally, the total three hops, small is shown in Figure 16. As filter you can our schemes have communication overhead than 16. As you can see, our schemes have less communication overhead than Secure Deluge regardless communication overhead, summing communication overhead in allthree threeschemes, hops, is shown in Figure Secure Deluge regardless of the size of the code image. Among our MBSA and BFBSA of the size of the code image. Among our three schemes, MBSA and BFBSA outperform SPA since 16. As youSPA can since see, our schemes have less communication overhead than Secure Deluge regardless outperform they can support fully variable size. MBSA hasoverhead lower communication they can support fully variable packet size. MBSA haspacket lower communication than BFBSA of the size of the code image. Among our three schemes, MBSA and BFBSA outperform since overhead than BFBSA needs large Bloom filter to reduce the false positiveSPA probability. since BFBSA needs a since large BFBSA Bloom filter toareduce the false positive probability. they can support fully variable packet size. MBSA has lower communication overhead than BFBSA since BFBSA needs a large Bloom filter to reduce the false positive probability.
Figure 16. Total communication overhead. Figure 16. Total communication overhead. Figure 16. Total communication overhead.
7.4. Total Energy Consumption 7.4. Total Energy Consumption Based on the results from previous subsections, we compute total energy consumption to show 7.4. Total Energy Consumption Based the results fromare previous subsections, wethan compute energy show that our on proposed schemes more energy-efficient Securetotal Deluge. In consumption each hop, oneto node Based on the schemes results from previous subsections, wethan compute total energy consumption to show that our proposed are more energy-efficient Secure Deluge. In each hop, one node sends a code image which is received by the other node while only one computation is performed that our proposed schemes are more energy-efficient than Secure Deluge. In each hop, one node sends a code image which received by the other nodeconsumption while only including one computation is performed in the receiver node only. is Figure 17 shows total energy communication and sends a code image which is received by the other node while only one computation is performed in the receiver node Figure 17 shows total energy consumption including and computation. SPA,only. MBSA and BFBSA consumes less energy than Secure Delugecommunication by approximately in the receiver node only. Figure 17 shows total energy consumption including communication and computation. less energy thanhop Secure by approximately 12.9%, 44.7%SPA, andMBSA 38.8%.and ThisBFBSA benefitconsumes become larger when the countDeluge increases and the link computation. SPA, MBSA and BFBSA consumes less energy than Secure Deluge by approximately quality varies dynamically. It isbecome important to note thatthe BFBSA consumes less energy than 12.9%, 44.7% andmore 38.8%. This benefit larger when hop count increases and the link 12.9%, 44.7% and 38.8%. This benefit become larger when the hop count increases and the link Secure Deluge despite high computation overhead because communication spends much more quality varies more dynamically. It is important to note that BFBSA consumes less energy than quality varies more dynamically. It is important to note that BFBSA consumes less energy than energy than despite computation. Secure Deluge high computation overhead because communication spends muchmuch moremore energy Secure Deluge despite high computation overhead because communication spends than computation. energy than computation.
Figure 17. Total energy consumption.
7.5. Discussion
Figure 17. Total energy consumption. Figure 17. Total energy consumption.
In this subsection, we discuss the results and clarify the limitations of our analysis. The goal of 7.5. Discussion 7.5.our Discussion performance evaluation is to show that our proposed schemes are more energy-efficient than In this subsection, we discuss the results and clarify the limitations of our analysis. The goal of existing whenwe integrating with adaptive code dissemination protocols which change the thisschemes subsection, discuss the results and clarify the limitations of our analysis. The goal ourInperformance evaluation is to show that our proposed schemes are more energy-efficient than of existing our performance evaluation is to show that our proposed schemes are more energy-efficient than schemes when integrating with adaptive code dissemination protocols which change the
Sensors 2016, 16, 1063
20 of 22
existing schemes when integrating with adaptive code dissemination protocols which change the packet size depending on the link quality. To take into account the effect of the various link quality, we defined a simple 3-hop topology where each hop is assigned a static BER to represent different link quality. We additionally assumed that no collisions due to channel contention occur in order to focus on the channel error which is the dominant factor for the adaptive code dissemination. Finally, we adopted TelosB as a representative platform and the operation of the CC2420 wireless transceiver is simplified by ignoring the transition time among TX, RX, and off state. Under these assumptions and simplifications, we showed that our proposed schemes outperform Secure Deluge which is a well-known secure code dissemination scheme using fixed-size packets. As shown in Section 7.3, our proposed schemes work well in all kinds of link quality by adapting the packet size to the link quality while Secure Deluge uses small fixed-size packets of 22 bytes which is only good for the bad link quality. It is very important to note that our performance evaluation is conducted under the following assumptions, which will be considered carefully when applying to the real-world environment. ‚ ‚ ‚ ‚ ‚
the use of a simple 3-hop topology with static link quality the assumption of no collisions due to channel contention the use of TelosB the simplification about the behavior of the CC2420 wireless transceiver the use of Deluge
We used a simple 3-hop topology where each hop is assigned a static BER for the sake of simplicity. To achieve broader applicability of our work, we must further consider the wide range of network configurations and the effect of more realistic link quality by applying our schemes to the real-world testbeds with a variety of network configurations, which is one of our future works. We also assumed that no collisions due to channel contention happen. Even if the system performance such as energy consumption will be degraded by collisions due to channel contention, the proposed schemes will be influenced by the channel error more than collisions since they focus on the design about dynamic packet size depending on the channel conditions. However, the impact of collisions must be taken into account in order to obtain more accurate results in the real-world environment. We used TelosB as a representative platform because TelosB is slightly out-of-date [28] but it is still commonly used in WSNs [15–17]. Since the energy consumption can be different according to the platforms, the new performance evaluation is required before applying our schemes to the new platform. For simplicity, we ignored the transition time of the CC2420 wireless transceiver, which will have impact on the energy consumption of the real sensor nodes but it is difficult to reflect the operation of transitions of the CC2420 without experiments. Thus, we must perform the real-world experiment to obtain the exact energy consumption of each sensor node, which is included in our future works. Finally, our proposed schemes are based on Deluge which is the de facto standard code dissemination protocol in WSNs. Even though our work can provide source authentication for other code disseminations with slight modifications, we do not consider other code dissemination protocols in this paper since our works are originally targeted at WSNs where Deluge is the de facto standard. 8. Conclusions In this paper, three source authentication schemes for code dissemination supporting dynamic packet size in WSNs have been proposed. According to our survey on existing works, source authentication for per-hop variable-size packets has never been researched earlier. Hence, our work gives a new opportunity to offer both energy efficiency and security by combining code dissemination with variable packet size and source authentication schemes together. Through the security analysis and the performance evaluation, we showed that all three schemes are superior to Secure Deluge in terms of security aspects and energy consumption which is summarized in Table 3, but each of our schemes has its own strengths and weaknesses. Hence, each of our schemes can be applied to the different environment. For example, if the possibility of node capture attacks is very low, MBSA is
Sensors 2016, 16, 1063
21 of 22
a best candidate due to its low energy consumption. On the other hand, if the required security level is high and each node has sufficient memory, BFBSA is a best candidate due to its robustness to attacks. Table 3. Comparisons of Source Authentication Schemes. Metric
Secure Deluge
SPA
MBSA
BFBSA
Authenticity DoS attacks Node capture attacks Packet size Computation overhead Communication overhead Storage overhead
yes weak robust fixed low high low
yes weak robust variable low modest low
yes robust weak fully variable low lowest low
yes robust robust fully variable high low high
As discussed in Section 7.5, our work has limitations that do not reflect all of the realistic environments, including the use of a simple 3-hop topology with static link quality, the assumption of no collisions due to channel contention and the simplification about the behavior of the CC2420 wireless transceiver. To overcome those limitations, we will further enhance the proposed schemes by performing real-world experiments under the various network configurations. Author Contributions: Daehee Kim wrote the paper, performed the performance evaluation, and analyzed the results. Dongwan Kim conceived and designed the main idea. Sunshin An supervised the entire process. Conflicts of Interest: The authors declare no conflict of interest.
References 1.
2.
3.
4. 5.
6. 7. 8. 9.
10. 11. 12.
Dutta, P.K.; Hui, J.W.; Chu, D.C.; Culler, D.E. Securing the deluge network programming system. In Proceedings of the 5th International Conference on Information Processing in Sensor Networks, Nashville, TN, USA, 19–21 April 2006; pp. 326–333. Hyun, S.; Ning, P.; Liu, A.; Du, W. Seluge: Secure and dos-resistant code dissemination in wireless sensor networks. In Proceedings of the 7th International Conference on Information Processing in Sensor Networks, St. Louis, MO, USA, 22–24 April 2008; pp. 445–456. Lanigan, P.E.; Gandhi, R.; Narasimhan, P. Sluice: Secure dissemination of code updates in sensor networks. In Proceedings of the 26th IEEE International Conference on Distributed Computing Systems (ICDCS 2006), Lisboa, Portugal, 4–7 July 2006; p. 53. Tan, H.; Ostry, D.; Zic, J.; Jha, S. A confidential and dos-resistant multi-hop code dissemination protocol for wireless sensor networks. Comput. Secur. 2013, 32, 36–55. [CrossRef] Zhang, R.; Zhang, Y. Lr-seluge: Loss-resilient and secure code dissemination in wireless sensor networks. In Proceedings of the 31st International Conference on Distributed Computing Systems (ICDCS), Minneapolis, MN, USA, 20–24 June 2011; pp. 497–506. He, D.; Chen, C.; Chan, S.; Bu, J. Dicode: Dos-resistant and distributed code dissemination in wireless sensor networks. IEEE Trans. Wirel. Commun. 2012, 11, 1946–1956. [CrossRef] Tan, H.; Zic, J.; Jha, S.K.; Ostry, D. Secure multihop network programming with multiple one-way key chains. IEEE Trans. Mob. Comput. 2011, 10, 16–31. He, D.; Chen, C.; Chan, S.; Bu, J. SDRP: A secure and distributed reprogramming protocol for wireless sensor networks. IEEE Trans. Ind. Electron. 2012, 59, 4155–4163. [CrossRef] Deng, J.; Han, R.; Mishra, S. Efficiently authenticating code images in dynamically reprogrammed wireless sensor networks. In Proceedings of the Fourth Annual IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOMW’06), Pisa, Italy, 13–17 March 2006; pp. 272–276. Bohli, J.-M.; Hessler, A.; Maier, K.; Ugus, O.; Westhoff, D. Dependable over-the-air programming. Ad Hoc Sens. Wirel. Netw. 2011, 13, 313–340. Lee, J.; Kim, L.; Kwon, T. Flexicast: Energy-efficient software integrity checks to build secure industrial wireless active sensor networks. IEEE Trans. Ind. Inf. 2016, 12, 6–14. [CrossRef] Chen, D.; He, D.; Chan, S. Security-enhanced reprogramming with xors coding in wireless sensor networks. In Information and Communications Security; Springer: Beijing, China, 2015; pp. 421–435.
Sensors 2016, 16, 1063
13.
14. 15. 16. 17. 18.
19.
20.
21. 22.
23.
24. 25. 26. 27.
28.
29. 30.
22 of 22
Xie, M.; Bhanja, U.; Wei, G.; Ling, Y.; Hassan, M.M.; Alamri, A. Secnrcc: A loss-tolerant secure network reprogramming with confidentiality consideration for wireless sensor networks. Concurr. Comput. Pract. Exp. 2015, 27, 2668–2680. [CrossRef] Perrig, A.; Szewczyk, R.; Tygar, J.D.; Wen, V.; Culler, D.E. Spins: Security protocols for sensor networks. Wirel. Netw. 2002, 8, 521–534. [CrossRef] Dong, W.; Chen, C.; Liu, X.; He, Y.; Liu, Y.; Bu, J.; Xu, X. Dynamic packet length control in wireless sensor networks. IEEE Trans. Wirel. Commun. 2014, 13, 1172–1181. [CrossRef] Wei, D.; Yunhao, L.; Zhiwei, Z.; Xue, L.; Chun, C.; Jiajun, B. Link quality aware code dissemination in wireless sensor networks. IEEE Trans. Parallel Distrib. Syst. 2014, 25, 1776–1786. Wei, D.; Jie, Y.; Pingxin, Z. Exploiting error estimating codes for packet length adaptation in low-power wireless networks. IEEE Trans. Mob. Comput. 2015, 14, 1601–1614. Kim, D.; An, S. Source authentication schemes for reprogramming with variable packet size in wireless sensor networks. In Proceedings of the 12th Annual IEEE International Conference on Sensing, Communication, and Networking (SECON), Seattle, WA, USA, 22–25 June 2015; pp. 148–150. Hui, J.W.; Culler, D. The dynamic behavior of a data dissemination protocol for network programming at scale. In Proceedings of the 2nd International Conference on Embedded Networked Sensor Systems, Baltimore, MD, USA, 3–5 November 2004; pp. 81–94. Wander, A.S.; Gura, N.; Eberle, H.; Gupta, V.; Shantz, S.C. Energy analysis of public-key cryptography for wireless sensor networks. In Proceedings of the Third IEEE International Conference on Pervasive Computing and Communications, Kaual Island, HI, USA, 8–12 March 2005; pp. 324–328. Rozenblit, M. Secure Software Distribution. In Proceedings of the IEEE Network Operations and Management Symposium, Kissimmee, FL, USA, 14–17 February 1994; pp. 486–496. Ramalingam, K.C.; Subramanian, V.; Uluagac, A.S.; Beyah, R. Simage: Secure and link-quality cognizant image distribution for wireless sensor networks. In Proceedings of the Global Communications Conference (GLOBECOM), Anaheim, CA, USA, 3–7 December 2012; pp. 616–621. Vuran, M.C.; Akyildiz, I.F. Cross-layer packet size optimization for wireless terrestrial, underwater, and underground sensor networks. In Proceedings of the 27th Conference on Computer Communications INFOCOM 2008, Phoenix, AZ, USA, 13–18 April 2008. Bloom, B.H. Space/time trade-offs in hash coding with allowable errors. Commun. ACM 1970, 13, 422–426. [CrossRef] Tarkoma, S.; Rothenberg, C.E.; Lagerspetz, E. Theory and practice of bloom filters for distributed systems. IEEE Commun. Surv. Tutor. 2012, 14, 131–155. [CrossRef] Ren, K.; Yu, S.; Lou, W.; Zhang, Y. Multi-user broadcast authentication in wireless sensor networks. IEEE Trans. Veh. Technol. 2009, 58, 4554–4564. [CrossRef] IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements—Part 15.4: Wireless Medium Access Control (Mac) and Physical Layer (Phy) Specifications for Low Rate Wireless Personal Area Networks (Wpans). Available online: http://ieeexplore.ieee.org/xpl/login.jsp? tp=&arnumber=1700009&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F11161%2F35824%2F01700009 (accessed on 8 July 2016). Polastre, J.; Szewczyk, R.; Culler, D. Telos: Enabling ultra-low power wireless research. In Proceedings of the Fourth International Symposium on Information Processing in Sensor Networks, Los Angeles, CA, USA, 15 April 2005; pp. 364–369. Lee, H.; Choi, Y.; Kim, H. Implementation of tinyhash based on hash algorithm for sensor network. World Acad. Sci. Eng. Technol. Int. J. Comput. Energ. Electron. Commun. Eng. 2007, 1, 1564–1568. Peter, S.; Langendorfer, P.; Piotrowski, K. Public key cryptography empowered smart dust is affordable. Int. J. Sens. Netw. 2008, 4, 130–143. [CrossRef] © 2016 by the authors; licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC-BY) license (http://creativecommons.org/licenses/by/4.0/).
