Security for Wireless Sensor Networks: A Review

SAS 2009 – IEEE Sensors Applications Symposium New Orleans, LA, USA - February 17-19, 2009

Security for Wireless Sensor Networks: A Review Michael Healy, Thomas Newe, Elfed Lewis Optical Fibre Sensors Research Centre, Department of Electronic and Computer Engineering, University of Limerick, Limerick, Ireland. [email protected] Abstract—Due to the sensitive nature of the data gathered by many wireless sensor networks (WSNs) it is becoming critical that this data be protected. However, due to the constrained nature of the resources available on sensor nodes, traditional wireless networking security solutions are not viable due to their processing requirements, power consumption, speed and communications overhead. We review the threats and attacks faced by WSNs and then the current state of the art of dedicated WSN security protocols are examined and compared, focusing on their relative strengths and weaknesses. Keywords-wireless sensor networks; security; threats; attacks; performance; sensor nodes

I.

INTRODUCTION

Ideally a full security solution for wireless sensor networks would include three features; preventative, detective and reactive measures [1]. Preventative measures, as the name suggests, prevent attacks, or at the very least make attacks much more difficult. This is the most widely researched area and utilizes fairly standard cryptographic primitives to provide authentication, integrity and confidentiality. It is often very difficult to detect when an attack is underway in WSNs because it is not easy to distinguish between an attack and a network failure, which is why detective measures are required. It is important that the network, be it the nodes themselves, the base station or the end user can distinguish between these two possibilities in order to allow reactive measures to be taken. Employing these reactive measures when not required greatly limits the usefulness of the network. Reactive measures come in a number of forms. Firstly it can be as simple as shutting down the network by sending a command to every node in the network (correctly authenticated of course) telling them to disable all communication for a period of time, and ignore any communication for the same period. This makes the attacker’s job much more difficult while preserving the nodes energy resources, with the hope that eventually the attacker will go away and normal service can be resumed. Another simple option is to allow the network to function as normal, giving the attacker no clue of detection, but ignoring any transmissions until the attacker is dealt with. These two methods provide resilience, as the network can

recover once the attack subsides, but a determined, patient attacker can disable the network for as long as required. More complicated reactive measures involve modifying the level of security when an attack is under way, only disabling infiltrated portions of a network, neutralizing attacks or even counter attacking. Implementing these measures on wireless sensor nodes is complicated by computational, memory and energy resource constraints. As a result security for WSNs is a trade off between what is required, what is desirable, and what is realistically achievable. The final major difficulty in securing WSNs arises from the fact that they are unattended. This gives the attacker a very free reign to perform many attacks that are not viable in any other type of network. These include physical attacks, node replication attacks and attacks on the often necessary remote management interface. II.

THREATS

Wireless sensor networks are more vulnerable to malicious attacks than traditional wireless networks. Threats to WSNs can be classed in a number of ways, based on the capabilities of the attacker, the level of access by the attacker and the level of intervention by the attacker. Firstly, an attacker can utilize devices with the same capabilities as the sensor nodes in the network, either by introducing sensor nodes to the networks deployment area or subverting some of the nodes in the network under attack. With this approach the scope of attacks is limited as the attacker only has the same resources as the nodes under attack, especially in terms of energy and processing power. The alternative is that the attacker uses a personal computer/laptop, or potentially an even more powerful dedicated device, equipped with the appropriate radio, which can possibly transmit at a much higher power level than the radios on the sensor motes. This option opens up many more avenues of attack due to the much greater energy supply, processing power, memory and much lower communication latency. Defending against this class of attacker is the primary difficulty when trying to secure a sensor network. Attacks can also be classed as being outsider or insider attacks. With an outsider attack, an attacker does not become part of the network. An outsider attacker can choose to

9781-4244-2787-1/09/$25.00 ©2009 IEEE Authorized licensed use limited to: SUNY Buffalo. Downloaded on April 04,2010 at 17:25:39 EDT from IEEE Xplore. Restrictions apply.

passively eavesdrop on the network communication, which is very difficult to detect. However using a sufficiently strong cipher to preserve confidentiality is generally the only defense needed against this type of attack. An outsider attacker can also actively influence the communication channel. This can be done by interrupting (i.e. jamming) or modifying network packets or injecting false packets into the network. Authentication, integrity and replay protection techniques can detect and prevent modification and injection of packets. Interruption attacks, while often easy to detect, are difficult to defend against, especially when dealing with a PC/laptop class attacker. An insider attack involves running malicious code on nodes that are valid members of the network. In this case the attacker often has access to at least some legitimate secret cryptographic keys used in the network. The only defense against an insider attack is to detect these malicious nodes, generally a very difficult problem, revoke the keys they know, and ignore any future communication originating at these nodes. A problem faced by WSNs that is not faced by other ad-hoc wireless networks is ability of the attacker to gain physical access to the sensor nodes. This is the case due to the unattended and accessible nature of WSN deployments. This physical access opens up a number of attacks, including reprogramming the sensor nodes with malicious code, retrieving secret information, such as cryptographic keys, from the nodes or even just physically destroying the nodes. The only defense against the first two attacks is to use tamper proof hardware but this is both very expensive and generally not very effective against a determined attacker [2]. The only defense against physically destroying the nodes is to encase the nodes in strong, destruction resistant enclosures, but this solution is usually cost prohibitive, not to mention the effect such cases can have on radio communication or the operation of the sensors themselves. III.

ATTACKS

Attacks against wireless sensor networks can be either noninvasive or invasive. Non-invasive attacks generally consist of side channel attacks such as power, timing or frequency based attacks. There is not much work published about side channel attacks that target WSNs specifically, but many of the problems found with other embedded systems, such as timing attacks against MAC generation or encryption, could be used against sensor nodes.

a number of node class devices or a single powerful device. Whichever way the jamming is performed, the sensor network can be rendered ineffective with relatively little effort by the attacker. DOS attacks can also be preformed at the data link layer. One possibility is to violate the communication protocol, be it 802.15.4 or Zigbee or whatever, by continually transmitting messages in order to generate collisions. As such collisions would require retransmissions by the effected node it is possible to deplete the power of targeted nodes or a targeted area of a network. Network layer DOS attacks involve attacking the routing protocol. A transport layer DOS attack is also possible, but is very dependent on the transport layer protocol in place on the network. B.

Attacks on Information in Transit The most common attacks against WSNs are on information in transit between nodes. Information in transit is vulnerable to eavesdropping, modification, injection, interruption, and traffic analysis. As already mentioned, eavesdropping, modification and injection can be prevented using well established confidentiality, authentication, integrity and replay protection protocols. Traffic analysis can potentially be a big problem in WSNs allowing an attacker to map the routing layout of a network, enabling very tightly targeted attacks to disrupt chosen portions of a network for greatest effect. C.

Node Replication Attack A node replication attack involves an attacker inserting a new node into a network which has been cloned from an existing node, such cloning being a relatively simple task with current sensor node hardware. This new node can act exactly like the old node or it can have some extra behavior, such as transmitting information of interest directly to the attacker. The problem with the second situation is obvious, but the first situation can have a subtle, but still very disruptive, influence on the network, possibly causing routing algorithms, data aggregation algorithms or querying algorithms to fail.

Invasive attacks are much more common and the more important of these are described in the following sections.

A node replication attack is particularly serious when the base station is cloned. However, as for many deployments, the base station is both in a secure location and much more powerful than the rest of the sensor nodes, so cloning it is much more difficult.

A.

Denial of Service Wireless sensor networks are particularly susceptible to denial of service (DOS) attacks because of the existence of PC/laptop class attackers.

D.

Routing Attacks As with almost all networks there are a number of attacks that target the routing protocol of WSNs, all of which are necessarily insider attacks.

At the physical layer a DOS attack simply involves constantly transmitting a signal that interferes with the radio frequencies being used by the sensor network. This jamming can be either constant or intermittent and can be performed by

1) Selective Forwarding: A malicious node can choose to forward some packets and drop other packets in order to shape the results of the overall sensor readings of the network. This

Authorized licensed use limited to: SUNY Buffalo. Downloaded on April 04,2010 at 17:25:39 EDT from IEEE Xplore. Restrictions apply.

method can also be used to set up routing trees to suit the attacker. 2) Sybil Attack: A sybil attack involves a single malicious node masquerading with multiple identities. This single node can then have a serious impact on fault-tolerant schemes such as distributed storage, data aggregation and multi-path routing. 3) Wormhole Attack: A wormhole attack occurs when a malicious node tunnels packets it receives over a separate low latency channel to another point in the sensor network. This attack can confuse routing, data aggregation and sensor querying protocols. 4) Sinkhole Attack: Sinkhole attacks involve attracting network packets to a malicious node by using false routing information in order to make selective forwarding or wormhole attacks more effective. 5) False Routing Information: By feeding false routing information to the other nodes in the network a malicious node can potentially reshape the entire network. There are a number of possible reasons for doing this, including exhausting the resources of particular nodes, creating routing loops, increasing latency, etc. IV.

EXISTING SECURITY SOLUTIONS

A number of security suites already exist that are at least some way appropriate for use in WSNs, and combat some of the threats to these networks. We review some of the more popular and more suitable solutions here. A.

802.15.4 The 802.15.4 standard [3] provides link layer security services. 802.15.4 has three modes of operation, unsecured, an Access Control List (ACL) mode and secured mode. In unsecured mode, as the name implies, no security services are provided. In ACL mode the device maintains a list of devices with which it can communicate. Any communication from devices not on the list is ignored. However, it must be noted that this mode offers no cryptographic security so it is trivial for the message source address to be spoofed. Secured mode offers seven security suites and depending on which is used any of four security services are offered, these being access control, data encryption, frame integrity and sequential freshness. One cryptographic algorithm, AES-128, is employed for all security suites, which allows for a very small implementation. For high security the full 128-bit message integrity code (MIC) can be added to each transmitted message but the MIC can be truncated to 64 or 32 bits to trade security for shorter message length. Evaluation: As the 802.15.4 security suites should be implemented on the radio chips all the necessary cryptographic computations are performed in hardware, thus reducing energy consumption.

different keying models [4] but these limitations can be overcome by higher level protocols. Overall the 802.15.4 standard contains well designed security features, which, if implemented correctly, can be used as a good base for building higher level, fully featured security suites. B. Zigbee The Zigbee [5] security architecture builds on the AES encryption and security modes offered by the underlying 802.15.4 data link layer by using AES-CCM* mode as well as defining key types and describing key setup and maintenance. As Zigbee leverages 802.15.4’s security model it offers the same four security services provided by 802.15.4 as described in the last section. AES-CCM* mode employed by Zigbee is an extension of the AES-CCM mode that is used in 802.15.4. AES-CCM* provides all the features of the standard AES-CCM modes and additionally offers encryption only and integrity only capabilities. Applying a security suite to a Zigbee frame adds an auxiliary header after the Zigbee network header, and also adds a message integrity code (MIC) after the payload field, as described in [5]. Zigbee uses the concept of a “trust centre” to manage the security of a network. This trust centre, normally a Zigbee network coordinator, is trusted by every device on the network and has three main roles: to authenticate devices that request to join the network, to maintain and distribute keys, and to enable end-to-end security between devices. Evaluation Using the Zigbee security suites has a high overhead in term of message size, increasing message length by up to 30 bytes. This is significant in term of message latency and power consumption, especially if an application sends many small messages. While the Zigbee security suites have not yet seen much scrutiny a number of fundamental problem have been found with the specification [6]. Firstly it is possible for an attacker to prevent delivery of a packet but still send a valid acknowledgement to the sending node. Secondly if AES-CTR mode is used, i.e. encryption only, an effective denial of service attack can be carried out by sending just one malicious packet. If the frame counter and key sequence counter of the malicious packet are both set to their maximum values the receiver will reject any further packets from that address. It is possible to do this because of the lack of message integrity in this mode. The payload of the malicious packet can be anything, including garbage that cannot be decrypted by the receiver. Finally there are a number of cases where the nonce reuse is a possibility, either due to power failure or due to multiple access control list entries using the same key.

There have been some problems found with some of the optional security modes and with the feasibility of supporting


C.

Bluetooth The Bluetooth specification [7] defines link layer, hop-tohop security, with the aim of providing authentication, confidentiality and authorization.

a major factor in this is, as already mentioned, the fact that the popularity of Bluetooth has resulted in it garnering a much higher level of interest from security researchers than the other such solutions is this field.

The most basic security mechanism in Bluetooth is the ability of a device to be discoverable or non-discoverable. When a device is in discoverable mode it will respond do a broadcast request from another device looking for Bluetooth devices in range. When a device is non-discoverable it will only respond to messages sent to its own specific address. If an attacker does not know a devices address it is much harder to attack that device.

D.

Bluetooth provides three modes of security. In mode 1, unsecured mode, all security functionality is completely disabled, allowing any device to connect and use any of the available services. Security mode 2 is the service-level security mode. In this mode security procedures are only initiated after a channel is established at the data link layer and a centralized security manager controls access to services and devices. This is the only mode that provides authorization, i.e. is a particular device allowed to have access to a specified service. Varying security policies can be defined to restrict access for applications operating in parallel that have differing security requirements. Security mode 3, the link-level security mode, initiates security procedures before any channel is established using a built-in security mechanism. This mode can provide authentication (unidirectional or mutual) and confidentiality. Confidentiality in Bluetooth is based on a stream cipher, the key stream being generated using a cryptographic algorithm based on linear feedback shift registers. Evaluation Due to the massive number of Bluetooth equipped devices currently on the market, primarily mobile phones, Bluetooth security has come under intense scrutiny in recent years. Most of the flaws found in Bluetooth security to date have been due to implementation issues as opposed to specification issues. However Karygiannis and Owens [8] detail a range of specification limitations which are a major contributing factor to these implementation problems. Poorly implemented Bluetooth stacks have allowed a number of attacks with names such as bluesnarfing, bluebugging and bluejacking. Bluesnarfing allows an attacker to covertly gain access to a Bluetooth-enabled device for the purpose of retrieving information stored on the device, bluebugging involves an attacker using the commands of a device without notifying or alerting the devices authorized user and bluejacking is when unsolicited, and usually unwelcome, data is transferred to a Bluetooth device, often advertisements or offensive messages. The only major Bluetooth attack that does not rely on implementation issues is against the pairing procedure. It has been shown that there is a method to retrieve the pin number being used for pairing, using a passive attack that is fast enough to be practical [8]. Overall there are more successful attacks against Bluetooth security than the other security suites described here. However

TinySec TinySec [9] is a link layer security architecture for wireless sensor networks, implemented for the TinyOS operating system. In order to overcome the processor, memory and energy constraints of sensor nodes TinySec leverages the inherent sensor network limitations, such as low bandwidth and relatively short lifetime for which the messages need to remain secure, to choose the parameters of the cryptographic primitives used. TinySec has two modes of operation: authenticated encryption (TinySec-AE) and authentication only (TinySecAuth). With authenticated encryption, TinySec encrypts the data payload and authenticates the packet with a message authentication code (MAC). The MAC is computed over the encrypted data and the packet header. In authentication only mode, TinySec authenticates the entire packet with a MAC, but the data payload is not encrypted. An important feature of TinySec is its ease of use and transparency, as many application developers will either implement the security features incorrectly or leave out any security entirely if the security API is difficult to use. TinySec solves this problem by integrating into TinyOS at a low level. Evaluation TinySec adds 3.03% to the overall energy consumption when using TinySec-Auth mode, and 9.1% when using TinySec-AE mode. This extra energy consumption can be explained by the increased packet length imposed by TinySec along with the cryptographic computations that are required. While TinySec has been well designed for its target application domain it still suffers from a number of limitations. The primary limitation is that no key exchange mechanisms are included. TinySec uses a single network wide shared key and it is left up to the application developer to change this key as appropriate and distribute new keys to all nodes. This is not a simple task and is odds with one of the major features of TinySec; its ease of use and transparency. If an application developer ignores this issue, which is likely, the use of TinySec will give a false sense of security as any such shared key cannot be expected to remain secret for very long in sensor networks where an adversary has physical access to sensor nodes. The other major limitation of TinySec is its limited platform support; the official release of TinySec as included in version 1 of TinyOS only works on the MICA2 mote, a 7 year old device which is no longer being manufactured. E.

MiniSec MiniSec [10] is a secure network layer protocol that claims to have lower energy consumption than TinySec while achieving a level of security which matches that of Zigbee. A major feature of MiniSec is that it uses offset codebook (OCB) mode as its block cipher mode of operation, which offers authenticated encryption with only one pass over the


message data. Normally two passes are required for both secrecy and authentication. Another major benefit of using OCB mode is that the ciphertext is the same length as the plaintext, disregarding the additional fixed length tag, four bytes in MiniSec’s case, so padding or ciphertext stealing is not necessary. Another primary feature MiniSec has over the other security suites mentioned here is strong replay protection without the transmission overhead of sending a large counter with each packet or the problems associated with synchronized counters if packets are dropped. To achieve this MiniSec has two modes of operation, one for unicast packets MiniSec-U, and one for broadcast packets, MiniSec-B as explained in [10]. Evaluation MiniSec has been implemented for the TelosB family of motes and only adds 3 extra bytes per packet. MiniSec’s authors claim that MiniSec has about one third the energy consumption of TinySec, but as MiniSec and TinySec are only available for different mote platforms it has been difficult to confirm this claim. The trade off required to achieve the high level of security with such low energy overhead is increased memory requirements, which for many WSN applications will not pose a problem. The current release of MiniSec also suffers from some implementation flaws which artificially limit the length of the 802.15.4 packets by overloading the length field, a mistake TinySec’s designers also made. Furthermore MiniSec overloads a bit in the packet header that CC2420 datasheet specifies as reserved and should always be set to zero. This can lead to unpredictable operation if MiniSec requires this field to be set to 1. As with TinySec, MiniSec does not include any key exchange and key management mechanisms as part of its current implementation despite the fact that each node requires two unique keys for every node it participates in unicast communication with. As a result applying appropriate key management protocols is by far the most difficult part of using MiniSec for any application. Also, key management aside, as MiniSec is not integrated into the TinyOS build environment it is currently not as easy to use as TinySec. In conclusion, while MiniSec brings some interesting ideas to providing energy efficient security to wireless sensor networks it still requires some work, especially in terms of implementation details, before it can be considered viable for practical deployments.

comparison with the other security suites mentioned here. While never actually specified Spins appears to be designed as a network level, end-to-end security protocol, but most of the design, particularly SNEP, is applicable to link layer, hop-tohop protocol. SNEP is showing its age as it has a number of limitations compared with some of the other protocols aimed at the same application space, TinySec and MiniSec in particular. SNEP adds 8 bytes of overhead to each message sent, which is more than TinySec or MiniSec. SNEP does include replay protection, which TinySec lacks but it is much more vulnerable to dropped packets than MiniSec. While in theory µTESLA is a very suitable scheme for broadcast authentication in WSNs, in practice it presents a number of serious complications due to the need for tight time synchronization between nodes and also the problem of choosing the time period between key disclosures has no straight forward solution. As with every other scheme already mentioned, Spins does not include any key management mechanisms for exchanging, updating or revoking keys. G.

SenSec SenSec [12] is another link-layer security protocol which is heavily based on TinySec but still has a number of significant differences. It is worth noting that the design of SenSec was motivated by the problems encountered while trying to use TinySec for a specific WSN deployment. However a number of the design choices were driven by the needs of this particular deployment and may not be generally applicable. SenSec has currently only been implemented for the mica2 platform. Evaluation SenSec can be seen as an evolution of TinySec with marginally lower power consumption, due to one pass encryption and authentication, and a higher level of security, again only slightly. However evolution is not always necessarily a good thing. SenSec is not as flexible as TinySec as it does not offer an authentication only mode and it is not as easy to use either as it is not integrated into the TinyOS distribution. SenSec also fails to address most of the major limitations of TinySec mentioned above, such as the lack of freshness checks and replay protection, no built in key exchange mechanisms and a lack of support for a variety of platforms.

F.

H.

Evaluation As SPINS was never fully implemented, or even fully specified, it is difficult to perform an evaluation or accurate

Evaluation The idea of a node being able to dynamically modify the security services it provides in order to save resources is potentially beneficial, but due to implementation limitations of SecureSense it is difficult to determine if it is a practical

Spins Spins [11] is the oldest proposed security suites for wireless sensor networks and consists of two building blocks: secure network encryption protocol (SNEP) and micro, timed, streaming, loss-tolerant authentication protocol (µTESLA). SNEP provides data confidentiality, two party authentication and data freshness. µTESLA provides efficient broadcast authentication.

SecureSense SecureSense [13] differs from the other security suites mentioned here because it enables a sensor node to dynamically modify its security controls based upon requirements from the application as well as observations about the external environment.


solution and even whether or not it provides any real energy savings. AMSecure AMSecure [14] is a link layer security suite which provides message confidentiality, authentication, integrity, replay protection and semantic security. AMSecure was designed for use on micaz and telos motes, both of which use the CC2420 radio chip, which is 802.15.4 compatible. AMSecure uses the security features of the Texas Instruments CC2420 radio chip in order to provide all of its security services. An interface is provided to allow security aware applications to manage the keys being used. AMSecure support should be very easy to add existing TinyOS applications as it fits into the TinyOS active messaging stack without any need to modify the higher layer protocols or applications.

The authors wish to thank the following for their financial support:

I.

Evaluation From the limited information that is available AMSecure can be considered to have a high level of security as it uses the AES cipher, which is generally held to be much more secure than RC5 or Skipjack, the ciphers almost every other suite described here uses. Also as hardware accelerated AES cryptography is utilized AMSecure should be competitive in terms of power consumption and speed.

[2]

[3]

[4]

[5]

[7]

J.

[8]

Evaluation Sizzle has very impressive code size, memory usage and speed for the services it provides, the only serious unknown is the effect it has on power consumption as no figures are given for this. While the original version of Sizzle was implemented for mica2 and mica2dot sensor motes, the only version currently available for evaluation is included in the Java software development kit for the SUN Spot motes. As the SUN Spots are much more powerful devices than almost any other sensor motes currently available the performance of Sizzle on this platform, in terms of energy consumption, cannot be considered a suitable benchmark. V.

[6]

[9]

[10]

[11]

[12]

[13]

[14]

CONCLUSIONS

While each of the security solutions discussed here can be used go part of the way to effectively securing a WSN, there is currently no one solution that can be “plugged-in” to an application to provide all the necessary security primitives.

SFI Research Frontiers Programme grant number 05/RFP/CMS0071.

•

The Embark Initiative and Intel, who fund this research through the Irish Research Council for Science, Engineering and Technology (IRCSET) postgraduate Research Scholarship Scheme. REFERENCES

[1]

The biggest weakness of AMSecure lies in its lack of portability. Due to the fact that it relies so heavily on the CC2420 security operations it would prove difficult to port to a platform that uses a different radio chip. Sizzle Sizzle [15] is a secure web server designed to run on sensor mote class devices and is the first end-to-end security architecture for wireless sensor networks. A secure sockets layer (SSL) and hypertext transfer protocol (HTTP) stack has been implemented using elliptic curve cryptography (ECC) for the asymmetric public-key operations required by SSL.

•

[15]

Y. W. Law, J. Doumen, and P. Hartel, "Benchmarking Block Ciphers for Wireless Sensor Networks," in IEEE International Conference on Mobile Ad-hoc and Sensor Systems (MASS'04), Fort Lauderdale, Florida, USA, 2004, pp. 447-456. R. Anderson and M. Kuhn, "Tamper Resistance - a Cautionary Note," in The Second USENIX Workshop on Electronic Commerce, Oakland, California, USA, 1996, pp. 1-11. 802.15.4: Wireless Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (LRWPANs). (2003) New York: IEEE Standards Association. N. Sastry and D. Wagner, "Security Considerations for IEEE 802.15.4 Networks," in 2004 ACM workshop on Wireless Security (WiSe '04), Philadelphia, Pennsylvania, USA, 2004, pp. 32-42. ZigBee Specification v1.0: ZigBee Specification (2005), San Ramon, CA, USA: ZigBee Alliance. http://www.zigbee.org/en/spec_download/download_request.asp Rui Silva, Serafim Nunes “Security Issues on ZigBee” (2005), http://rtcm.inescn.pt/fileadmin/rtcm/WorkShop_22_Jul_05/s2_Security_ Issues_on_ZigBee.pdf. accessed: 5 January 2009. Bluetooth Special Interest Group (2008), http://www.bluetooth.com accessed: 11 June 2008. T. Karygiannis and L. Owens, "Wireless Network Security: 802.11, Bluetooth, and Handheld Devices," National Institute of Standards and Technology NIST_SP_800-48, November 2002. C. Karlof, N. Sastry, and D. Wagner, "TinySec: a link layer security architecture for wireless sensor networks," in 2nd international conference on Embedded networked sensor systems, Baltimore, MD, USA, 2004, pp. 162 - 175. M. Luk, G. Mezzour, A. Perrig, and V. Gligor, "MiniSec: A Secure Sensor Network Communication Architecture," in IEEE International Conference on Information Processing in Sensor Networks (IPSN'07), Cambridge, Massachusetts, USA, 2007. A. Perrig, R. Szewczyk, J. D. Tygar, V. Wen, and D. E. Culler, "SPINS: security protocols for sensor networks," Wireless Networks, vol. 8, pp. 521-534, September 2002. T. Li, H. Wu, X. Wang, and F. Bao, "SenSec: Sensor Security Framework for TinyOS," in Second International Workshop on Networked Sensing Systems (INSS'05), San Diego, California, USA, 2005. Q. Xue and A. Ganz, "Runtime Security Composition for Sensor Networks (Secure Sense)," in IEEE 58th Vehicular Technology Conference (VTC'03), Orlando, Florida, USA, 2003, pp. 2976-2980. A. D. Wood and J. A. Stankovic, "AMSecure: Secure Link-layer communication in TinyOS for IEEE 802.15.4-based Wireless Sensor Networks," in 4th International Conference on Embedded Networked Sensor Systems (SenSys'06), Boulder, Colorado, USA, 2006, pp. 395396. V. Gupta, M. Millard, S. Fung, Y. Zhu, N. Gura, H. Eberle, and S. C. Shantz, "Sizzle: A Standards-Based End-to-End Security Architecture for the Embedded Internet," in Third IEEE International Conference on Pervasive Computing and Communications (PERCOM), Kauai Island, Hawaii, USA, 2005, pp. 247-256.

ACKNOWLEDGMENT
