A secure interconnection model for IPv6 enabled ... - Semantic Scholar

A secure interconnection model for IPv6 enabled Wireless Sensor Networks Jorge Granjal, Edmundo Monteiro, Jorge Sá Silva University of Coimbra, Portugal {jgranjal,edmundo,sasilva}@dei.uc.pt Abstract—The usage of IPv6 on Wireless Sensor Networks (WSNs) can enable the integration of existing and new sensing applications with the Internet, therefore contributing to a major evolution towards the realization of the internet of things. We believe this vision to be realizable only if security is properly addressed. Although many proposals do exist in the literature to address specific security issues on sensor networks, a new security model and security mechanisms are needed to support the secure integration of IP enabled WSNs with the Internet. Such a security model should allow for end-to-end security and should be able to provide mechanisms that allow for the flexible adaptation of security to the resource limitations of sensor nodes. We propose and evaluate a new secure interconnection model and security mechanisms to enable the secure integration of IP enabled WSNs with the Internet. Our model introduces 6lowpan security headers to enable end-to-end security between sensor nodes and hosts in the Internet, while also providing mechanisms to selectively control the energy expended with security operations on the WSN. Although the usage of security at the network layer on WSNs is not consensual, we believe that its proper design and implementation can bring a substantial contribution to the evolution of the Internet. Index Terms—wireless sensor networks, 6lowpan, application security profiles, AH, ESP

I. INTRODUCTION The optimization of communication and processing operations accordingly to the scarcity of the available energy has motivated most of the research efforts in the field of Wireless Sensor Networks (WSNs) [1]. Traditional communication architectures proposed for WSNs usually collapse networking layers in order to optimize energy usage. Many proposals have been presented where the layers have been turned upside down, intermingled, or where the network itself processes the data produced by the sensor nodes. We realize therefore that the existing proposals are mostly optimized for local deployments, and are usually closed and non-scalable. More recently, the research community is leaning toward more layered and open network architectures such as IP, looking for the benefits of modularity and separation or concerns, and even industry based standards such as ZigBee are adopting IP. Although not a consensual solution, the usage of IP on WSNs presents several benefits: IP enables a common network programming interface to support direct communications between Internet hosts and sensor nodes, provides the capability of enabling the integration of existing

applications with sensor nodes, and is able to bring physical sensing capabilities to the Internet as we know it today, enabling WSNs as an important component of new ubiquitous and heterogeneous communication environments. Even for WSNs not integrated with the Internet, IP can enable sensor nodes to communicate with any other device without any additional hardware of software. The 6lowpan group of the IETF is currently working on the definition of an adaptation layer to allow the transport of IPv6 packets on IEEE 802.15.4 networks [2]. While looking at how security is addressed in 6lowpan we realize that, although there are some recommendations regarding the development of security mechanisms for 6lowpan WSNs [3], the problem on how to securely integrate IPv6-enabled WSNs with the Internet is currently an open issue. In current WSN deployments sensor nodes are usually isolated from the Internet, and a gateway is employed that interfaces with the Internet and provides indirect access to data gathered from sensor nodes. We realize that 6lowpan provides for integration contexts that are much more interesting and ambitious, enabling sensing applications to transparently appear as part of the Internet communications infrastructure. In this paper we propose and evaluate a secure interconnection model and 6lowpan compressed security headers to address these issues. The paper proceeds as follows. Section II introduces our proposed interconnection model and its internal operations are discussed in greater detail in Section III. Section IV describes the compressed security headers we propose for the 6lowpan adaptation layer and that constitute one major component of the proposed model. Section V evaluates the model accordingly to predefined application security profiles, and finally Section VI concludes the paper. II. A NEW SECURE INTERCONNECTION MODEL A. Security and functional requirements One first goal of our model is to provide fundamental security properties such as confidentiality, authentication, integrity, non-repudiation and access control. As cryptographic operations deeply influence the lifetime of WSNs, the mechanisms used in this context should be able to be employed accordingly to the security requirements of different sensing application. Regarding the cryptographic algorithms employed, it is also desirable that they are standard enough to provide compatibility with mechanisms adopted for the Internet. Regarding the need for end-to-end security we realize that, even with the best link layer security mechanisms available in the WSN, the data is no longer secure once it leaves the wireless link. Link layer security (for example using AES available with the CC2420 chip) also only provides

B. Comparison with related work, Existing research proposals regarding the secure integration of WSNs with the Internet are mostly based on the usage of modified implementations of the SSL protocol. The Sizzle security architecture [4] proposes the usage of SSL employing gateways and a proprietary communications protocol on the WSN. In Sizzle HTTPS servers available on sensor nodes are mapped to particular ports on the gateway, and connections from Internet hosts terminate at the gateway. SSNAIL [5] employs the same cryptographic primitives as Sizzle but eliminates the usage of a security gateway. We realize that for both proposals, SSL presents the limitation of only being able to protect communications for SSL-enabled sensing applications and also being unable to be adapted to different sensing application security requirements. Another proposal can be found in ContikiSec [6], which introduces the usage of security profiles for WSN communications using the Contiki operating system [7]. ContikiSec only provides security at the link layer, thus being unable to support end-to-end secure communications. In Table 1 we compare the discussed proposals with our model, identified as SIMWSN (Secure Interconnection Model for WSNs). TABLE I SECURE INTERCONNECTION PROPOSALS FOR IP ENABLED WSNS SSNAIL Sizzle ContikiSec SIMWSN Authentication Key exchange Key size(s) Data encryption Hashing Access control Layer Gateway usage End-to-end sec. IDS App. profiles

ECDSA ECDH 160 RC4 MD5, SHA1 None SSL No Yes No No

ECDSA ECDH 160 RC4 MD5, SHA1 Gateway SSL Yes Yes No No

CMAC None 128 AES CMAC None Link No No No 3 modes

ECDSA ECDH 128 to 256 AES, 3DES SHA1, SHA2 Gateway Network Yes Yes (IPv6) Yes Yes

C. Functional overview Figure 1 illustrates the operational scenario of SIMWSN, where one or more security gateways are employed that can also operate as sink nodes for associated WSNs. In each WSN, IPv6 addresses are managed accordingly to the rules defined in 6lowpan [2], and gateways support both IPv6 and 6to4 tunneling on the Internet interface.

WSN1

IPv6 client

Internet

KMS, IDS, Security

Other important requirements are also addressed by our model. One requirement is that mechanisms should be available that allow the enforcement of security perimeters. Redundancy should also be provided for critical security management operations, as long as particular deployments allow it. Also, due to the high level of exposure of nodes in most sensing applications, intrusion detection mechanisms are required. As we describe later in the paper, our model is validated using several critical application scenarios defined for an oil refinery in Portugal. These scenarios are provided by the GINSENG research project [8], a European Union FP7 project that addresses the goal of creating WSNs that are able to meet application specific performance and security targets. GINSENG also provides GINMAC, a TDMA based MAC layer that our model is able to use and beneficiate from, as explained later in the paper.

Our model combines the usage of ECC (Elliptic Curve Cryptography) public authentication and key-exchange with symmetric encryption and data hashing. ECC has already been proved to be an appropriate choice for WSN [4], and is also our choice to support authentication. Our ECC implementation employs 160-bit curve secp160r1, as it provides the same security as RSA with 1024-bit keys, while requiring less memory and energy. Data encryption is supported by AES/CCM or 3DES, using three different key sizes. As encryption operations are very energy demanding for sensor nodes, key size can be adjusted accordingly to the security requirements of particular sensing applications. Data hashing is supported by SHA1 and SHA2. As we describe next, security gateways are employed to enforce security perimeters and to support security operations that are computationally heavy. For deployment environments where more than one security gateway can be employed, the model also provides redundancy for critical security management operations.

Shared Backbone

confidentiality and integrity over a single hop. Although the usage of security at the network layer for WSNs is not consensual, we believe that such mechanisms can be beneficial for many scenarios, as long as an appropriate architecture exists that is able to provide acceptable compromises between security levels and resources required from sensor nodes.

Gateway/ sink node IPv6/4 6to4

WSN2

WSN3

IPv4 client Gateway/ Sink node IPv6/4 6to4

Figure 1. SIMWSN operational scenario

SIMWSN allows for end-to-end security in transport mode, as with IPSec for traditional IP environments, or alternatively a security gateway can be configured to protect a connected WSN from the Internet. In this scenario, the security gateway allows hosts on the Internet to connect indirectly to sensor nodes on the WSN. A node on the Internet connects to the security gateway using IPSec in tunnel mode or without security, while security on the WSN side is achieved with tunnel mode or just by using the mechanisms available with IEEE 802.15.4. In our model security gateways are assumed to be powerful (PC-like) nodes when compared to sensor nodes. Security gateways also enforce security perimeter defense by filtering IP communications between the Internet and sensor nodes. Gateways employ a shared communication backbone (using IEEE802.3 or IEEE802.11) to synchronize information related to security management, namely information regarding

identification of sensor nodes, key management, intrusion detection, and application security profiles. This information is necessary to support redundancy for security management operations. III. MODEL CROSS-LAYER OPERATION Figures 2 and 3 illustrate the internal operations of the model for a sensor node and a security gateway, respectively. We proceed by describing the main components of our model. A. Security manager On a security gateway, this component is responsible for the enforcement of security profiles for associated WSNs. Each application security profile defines key usage parameters (key refreshment frequency and symmetric encryption key size), the symmetric encryption algorithm to use, the filtering policy, and configuration parameters for intrusion detection. Each security gateway also maintains a list of 160-bit ECC public-keys for wireless sensor nodes. Each key is sent to the correspondent sensor node by the security manager during node bootstrap, via the Key Management System (KMS). The security manager on the gateway also disconnects misbehaving sensor nodes, upon notifications received from the Intrusion Detection System (IDS) module. Physical sensing Applications

Node manager

UDP/TCP

IDS

6lowpan/ Network GINSENG MAC IEEE 802.15.4 PHY

IEEE 802.15.4 Radio

IDS local/ global Traffic control

Security manager

KMS

IPv6 6lowpan

IPv4/IPv6/6to4

GINSENG MAC

IEEE 802.3/11 MAC

IEEE 802.15.4 IEEE 802.3/11 PHY PHY

Security manager

Figure 3. Model cross-layer operations on a security gateway KMS

Figure 2. Model cross-layer operations on a wireless sensor node

When running on wireless sensor nodes, the security manager is responsible for the application and monitoring of security-related configuration and running parameters. The security manager informs the KMS component about the key size to use and the frequency of key refreshment. It is also responsible for the setup of the appropriate cipher suite in the context of the 6lowpan compressed security headers, as we describe later in the paper. Each sensor node also runs an IDS component that notifies the security manager whenever some suspect behavior is detected on its neighborhood. After receiving such a notification, the security manager informs its peer on the associated gateway. The security manager on the sensor node also participates on the disconnection of the node from the WSN, upon a request received from a gateway. The disconnection is performed by notifying the Traffic Control (TC) module on the sensor node. When using the GINMAC layer, a TDMA slot supports communications between

gateways and sensor nodes regarding all security management operations, including key management and intrusion detection. B. Key Management On a security gateway, the KMS module supports Internet Key Exchange (IKE) negotiations with Internet hosts and transmits 160-bit ECC public-keys to wireless sensor nodes. This key allows a sensor node to authenticate itself using the ECC ECDSA public-key authentication algorithm. If the deployment scenario requires it, this key can also be pre-programmed on the sensor. Other aspect fundamental to security and related to the usage of application security profiles is that, during normal network operation, keys must be renewed on sensor nodes. For example, the AES/CCM algorithm completely loses its security if the same Initialization Vector (IV) is reused with the same key [10]. After ECC ECDSA authentication, the ECC ECDH algorithm is used to derive a session key that is used to encrypt communications. The size of the key and the frequency of key renewal are enforced by the KMS component on the gateway, accordingly to the application security profile selected and instructions from the security manager. The KMS component on sensor nodes receives the 160-bit ECC key of the node during node bootstrap, together with information regarding encryption key size and the frequency of key-renegotiation. Key size is defined accordingly to a security profile, and applies to the key employed with AES/CCM or 3DES. C. Intrusion Detection Intrusion detection is an important component of our model, because security at the network layer alone cannot protect the WSN from internal attacks. As intrusion detection for WSNs is a vast area of research per se, it is important to define precisely what we expect from this component in our model. When employing the GINMAC layer, a failing node is considered to be a node that in some way doesn‟t follow the temporal and synchronization requirements defined by the TDMA operational model. Each sensor node employs a monitoring module that is able to scan network traffic departing or entering the local node and other sensor nodes in its neighborhood. This module just functions as a remote probe that scans network traffic and notifies the Intrusion Detection Module (IDS) component running on the security gateway (via the security manager module running on the sensor node) whenever some anomalous communication is detected. Complex IDS algorithms are implemented exclusively on security gateways and allow to identify (and disconnect) misbehaving sensor nodes from the WSN. D. Node manager This component provides auxiliary information to the other components of the model, regarding the status of the node. Information regarding the availability of resources (energy, memory and processor usage) on the sensor node is important so that security operations can be adapted accordingly. The security manager on the node can also use information provided by this component to inform the security manager on

the gateway about the level of available energy and memory, thus enabling a clean shutdown of a sensor node reaching the end of its lifetime. IV. BRINGING SECURITY TO 6LOWPAN A. Where does it fit The introduction of security at the network layer for WSNs is an important contribution of our model. To achieve this, we must start by examining the data payload available when using the 6lowpan adaptation layer with IEEE 802.15.4. The available space depends on the security mechanisms employed at the link layer and is 81 bytes for the AES-CCM-128 mode (using 21 bytes for security), 89 bytes for AES-CCM-64 (using 13 bytes for security), and 93 bytes for AES-CCM-32 (using only 9 bytes for security). Without security at the link layer, the available payload space is 102 bytes. These values also allows us also to realize that any security mechanism created for 6lowpan must be validated against its computational and energy impact on sensor nodes when dealing with data payloads of between 81 and 102 bytes. B. How can we build it Security extensions for 6lowpan packets represent one major component of our secure interconnection model and represent, as far as we know, the first proposal towards the introduction of security at the network layer for IPv6 enabled WSNs. Of course, the successful adoption of such security extensions will also require proper key management support. 1) New LowPAN IPv6 addressing header types In 6lowpan, header compression allows the representation of IPv6 addresses and other control information, and is where we integrate our new compressed security headers. Accordingly to the specification of the 6lowpan adaptation layer [2], the first two bits of the first byte are used to define the header dispatch. Table II describes the new values defined for the header dispatch to identify the new security headers. We maintain the first two bits as „01‟, as this indicates that an IPv6 (compressed or uncompressed) address follows in the packet. After this prefix the following bits identify the presence of an AH or ESP compressed header in transport or tunnel mode, together with the addressing modes available at 6lowpan (uncompressed address, HC1 or HC1g compression). TABLE II NEW COMPRESSED ESP/AH 6LOWPAN SECURITY HEADER TYPES Header dispatch/type of addressing

Usage description

01 001xxx 01 010xxx 01 011xxx 01 100xxx

AH in transport mode AH in tunnel mode ESP in transport mode ESP in tunnel mode

2) Usage in tunnel and transport modes Figure 4 illustrates the usage of the two new 6lowpan compressed security headers in transport and tunnel mode.

802.15.4 Header

802.15.4 Header

Mesh Header

Header dispacth

Header Uncompressed/ Fragment dispacth HC1/HC1g Header AH/ESP IPv6 address Transport

Header Uncompressed/ dispacth HC1/HC1g AH/ESP IPv6 GW address Tunnel

Uncompressed/ HC1/HC1g IPv6 address

AH/ESP HC Header

(HC2)+IPv6 Payload

AH/ESP HC Header

(HC2)+IPv6 Payload

Figure 4. Security in transport mode (above) and tunnel mode (below)

As can be seen in the previous Figure, security in transport mode can be achieved with the inclusion of an appropriate header dispatch field and a 6lowpan security header right after the IPv6 header. In this case only the payload is encrypted and the packet is delivered directly to the final destination node (sensor node or Internet host). In the second scenario, a gateway is identified by its address at the beginning of the packet and the security header (AH or ESP) protects the entire original packet. In both usage modes HC2 compression is used normally as defined in 6lowpan, together with data from specific transport layer protocols. From the point of view of security, compressed data is part of the protected payload. 3) New compressed 6lowpan security headers Figure 5 illustrates the format of our new proposed security headers, the AH HC (compressed) and ESP HC 6lowpan headers. The definition of both headers also considered recommendations from RFC4309, a document that discusses the usage of AES/CCM in the context of IPSec. The next header field is reduced to two bits, allowing the specification of the next header as TCP, UDP or ICMPv6. The Secure Parameters Index (SPI) field identifies the security association that the packet belongs to. The sequence number field is used to provide protection against replay attacks. We consider two bytes for both fields to be appropriate for most WSNs application requirements and transmission rates. 2 bits

3 bits

2 bytes

2 bytes

Variable

Variable

SPI

Sequence Number

Authentication Data

Payload Data

Next Payload Header Lenght 2 bytes SPI

2 bytes

8 bytes

Variable

2 bits

Variable

Sequence Number

IV

Payload Data

Next Header

ICV

Figure 5. AH (above) and ESP (below) compressed security headers

The payload length in the AH compressed header describes the entire length of the Authentication Header in units of 32-bit words. For ESP, the encrypted payload starts with an explicitly transmitted IV of 8 bytes. The encrypted payload follows the IV, and finally the Integrity Check Value (ICV) is appended. The ICV field size can vary accordingly to the encryption algorithm employed and the level of integrity and authentication protection required, both derived from the active application security profile. For AES/CCM this field requires 8, 12 or 16 bytes [11]. When using AES/CCM the encrypted payload must also be padded to be a multiple of four bytes. The restrictions on the payload space available on the 6lowpan network layer allow us to consider security transport mode to be the ideal for WSNs. Also, we consider ESP to be more useful than AH, as ESP provides both encryption and authentication of network packets.

4) Identification of appropriate cipher suites The IP security architecture specification [13] allows end systems to select the most appropriate cryptographic algorithms from a pool of available alternatives. This is relevant to the definition of our model, as it opens the door for the adoption of flexible security mechanisms to be adapted on the WSN accordingly to particular application security requisites. We therefore evaluate the feasibility of employing different cryptographic suites accordingly to their requirements of resources from real sensor nodes. V. EVALUATION OF THE PROPOSED MODEL A. On the usage of network payload We start by evaluating the requirements on the usage of the new compressed security headers considering the space required from the network payload. Without considering authentication data, our AH 6lowpan header requires 37 bits. The ESP header, without considering the encrypted payload and authentication data fields, requires 96 bits. The difference is due essentially to the usage of the IV field in the ESP header. It is important to consider the usage of these headers accordingly to the various compression scenarios allowed by 6lowpan. In the unicast link-local communications scenario, HC1 and HC2 are able to compress an IPv6/UDP header to a minimum of 7 bytes. An intermediate compression scenario occurs when communications are with a node outside the IPv6 link-local scope, and in this case at least 64 bits must be carried inline for the 6lowpan address (derived from the IEEE 802.15.4 address). The worst case occurs for communications established with sensor nodes outside the local LoWPAN, since in this case the IPv6 source address prefix and the full IPv6 destination address must be carried in the 6lowpan header. Table III illustrates the available data payload after the application of the compressed security headers. TABLE III AVAILABLE NETWORK PAYLOAD (IN BITS) WITH 6LOWPAN SECURITY HEADERS 6lowpan compression scenario

Available payload

Link-local unicast Outside of link-local scope Outside of LoWPAN

720 (AH), 664 (ESP) 712 (AH), 656 (ESP) 520 (AH), 464 (ESP)

The results illustrated in the previous Table consider only the usage of security in transport mode and that IEEE802.15.4 security is not activated. The most useful communication scenario for future interconnection environments is certainly when communications are with hosts outside of the LoWPAN. This is also the most demanding scenario in terms of usage of the available space at the network payload, but we can see that AH and ESP in transport mode still leaves enough payload space to support end-to-end network layer communications. B. On the requirements of resources from sensor nodes In our evaluation study we consider the usage of AES/CCM available on sensor node hardware (using the CC2420 chip), and as an alternative we also evaluate the usage of 3DES together with SHA1 and SHA2. All the cryptographic

suites evaluated in our experimental study are part of the set of mandatory algorithms for the IP security architecture [13]. Our analysis on the resources required from wireless sensor nodes for running AES, 3DES, SHA1 and SHA2 [12] employed real sensor hardware and is, as far as our knowledge goes, the first study concerning the feasibility of employing security extensions for 6lowpan/IPv6 packets on WSNs. We measured the maximum energy and processing time required to encrypt a 128-byte packet (above the maximum of 102 bytes available for 6lowpan with IEEE 802.15.4 in the best case). The experimental results were obtained for AES and 3DES using 192-bit keys, SHA1 using 160-bit keys and SHA2 using 512-bit keys. Our tests were conducted on MicaZ sensor nodes, powered by an ATMEL ATmega 128L 8-bit microprocessor running at 16 MHz, with 128k bytes of EEPROM memory to store executable code and 4k bytes of internal SRAM memory for temporary storage during program execution. Communications on the MicaZ run at 2.4 GHz and data can be transmitted at the rate of 250kbps. Our measurement values were obtained by testing each encryption algorithms running on NesC applications with the TinyOS operating system with 6lowpan support. The values obtained for the encryption of a single 6lowpan network layer packet in terms of the required processing time and energy are presented in Table IV. We considered the availability of 3000mV/h of energy on a sensor when using two new AA-type batteries. TABLE IV COMPUTATIONAL TIME AND ENERGY REQUIRED FOR THE ENCRYPTION OF A SINGLE 6LOWPAN NETWORK LAYER PACKET Encryption algorithm AES 3DES SHA1 SHA2

Time required for encryption (ms) 800 890 26 360

Energy required for encryption (mV/h) 0.0031 0.00352 0.00003 0.00098

From the values presented in the previous Table, we are able to verify that AES is more appropriate to support the compressed ESP 6lowpan header. Also, as AES/CCM is available at the link layer, it can save code space and memory when compared to 3DES. In respect to AH, SHA1 is clearly the best choice. We also consider that the higher integrity and authentication levels obtained with SHA2 do not justify the energy required from real sensor nodes. In Figure 6 we illustrate sensor nodes lifetime expectancy for different rates of secured 6lowpan packets processed per hour.

Figure 6. WSN node lifetime for different processing rates

From the previous Figure we note that AES/CCM and 3DES-SHA1 present very similar performance regarding their impact on sensor node lifetime. As AES provides superior security and is readily available at the link layer we consider AES/CCM to be the best choice for our compressed ESP 6lowpan header. We also note that 3DES-SHA2 is clearly the less interesting option, meaning that the increased security provided by SHA2 does not compensate its impact on sensor node lifetime. It is also important to note that node lifetime dramatically decreases for applications requiring high transmission rates. This is an important aspect to consider when planning for the usage of security at the network layer in specific WSN deployment environments. Another important analysis to conduct is to what extent our proposed compressed security headers affect data transmission rate. Referring to the values presented in Table IV, we are able to conclude that AES represents a bottleneck in the data transmission rate for applications requiring the protection of more than 4500 IP/6lowpan packets per hour. For 3DES with SHA1 this limit is of 3930 packets per hour, and for 3DES with SHA2 it drops to 2880 packets per hour. The previously described evaluation studies allow us to verify that the usage of our compressed ESP 6lowpan security header is a viable option, especially when using AES/CCM for WSN applications requiring low or moderate data rates. In order to validate our model in the context of GINSENG, three critical applications have been defined and are described in Table V. This Table describes the security profiles for the three applications, together with estimated node lifetime values, calculated accordingly to each profile and using the experimentally obtained values previously discussed.

ECC ECDH (128, 192 or 256-bit key). As expected, node lifetime for the different applications greatly varies with transmission rate. The obtained values for node lifetime again corroborate our conclusion on the feasibility of employing our compressed ESP header with AES, again preferably for WSN applications requiring moderate or low data rates. VI. CONCLUSION The integration of WSNs with the Internet opens the path for new applications and will certainly play an important part in shaping the Internet of the future. Our research efforts address the problem on how to secure such integration, trying to deal with two apparently contradictory objectives: carefully control the energy expended with security operations on sensor nodes, while achieving strong end-to-end security at the network layer. As with many other networking solutions designed for WSNs, we believe effective security at the network layer will require appropriate compromises accordingly to the characteristics of each application. Our work will proceed with the definition of the KMS and IDS components for the SIMWSN model. ACKNOWLEDGMENT The research leading to these results has received funding from the EU Seventh Framework Programme (FP7/20072013) under grant agreement n° 224282, Project GINSENG. The authors also thank the Communications and Telematics Group of the CISUC-University of Coimbra. REFERENCES

TABLE V NODE LIFETIME EXPECTANCY FOR DIFFERENT GINSENG APPLICATIONS

[1]

WSN Application

Production monitoring

Production control

Pipeline leak detection

Integrity Confidentiality Transmission rate (pph) Frequency of rekeying Suite for ESP Energy required (mV/h) Expected node lifetime (hours)

Medium Medium 720

High High 1440

Low Low 360

Medium

High

Low

AES-CCM-64 2.52

AES-CCM-128 5.04

AES-CCM-32 1.26

[5]

1190

595

2380

[6]

The production monitoring scenario is an indicatory system where sensors are deployed throughout the plant to monitor various aspects of production. In the production control scenario, information is received from the sensors and is used to make decisions and alter various aspects of production. In the Pipeline Leak Detection scenario, pipelines are surveyed for leaks. The values for the energy required and node lifetime expectancy are derived from the values obtained with our experimental study, considering that sensor nodes transmit at constant data rates. The integrity level defined for each application security profile determines the size of the MAC code employed using AES/CCM. The confidentiality level determines the size of the symmetric key to negotiate using

[2] [3] [4]

[7] [8] [9] [10]

[11]

[12]

[13]

J.P. Walters et al., “Wireless Sensor Network Security: A Survey,” Security in Distributed, Grid, and Pervasive Computing, Auerbach Publications, CRC Press, pp. 1-49. Montenegro, G., Kushalnagar, N. Hui, J. and Culler, D. “Transmission of IPv6 Packets over IEEE 802.15.4 Networks”. RFC 4944, Sep. 2007. Park, S., Kim, K., Haddad, W., Chakrabarti, S. and Laganier, J. “IPv6 over Low Power WPAN Security Analysis”, Internet Draft, Jul. 2009. Gupta, V. et al (2005), “Sizzle: A standards-based end-to-end security architecture for the embedded Internet”, Third IEEE International Conference on Pervasive Computing for the Embedded Internet. Jung, W. et al (2009), “SSL-based Lightweight Security of IP-based Wireless Sensor Networks”, International Conference on Advanced Information Networking and Applications Workshop. Casado, L. and Tsigas, P. (2009), “ContikiSec: A Secure Network Layer for Wireless Sensor Networks under the Contiki Operating System”. The Contiki Operating System, http://www.sics.se/contiki/. “GINSENG Research Project”; http://www.ict-ginseng.eu/. Walters, J. et al (2006) “Wireless Sensor Network Security: A Survey”, Security in Distributed, Grid, and Pervasive Computing. Habib, A. (2008), “Sensor Network Security Issues at the Network Layer”, 2nd International Conference on Advances in Space Technologies, Islamabad, Pakistan. Housley, R. “Using Advanced Encryption Standdard (AES) CCM Mode with IPSec Encapsulating Security Payload (ESP)”. RFC 4309, Internet Engineering Task Force, Dec. 2005. J. Granjal, R. Silva, E. Monteiro, J. Sa Silva, and F. Boavida, “Why is IPSec a viable option for wireless sensor networks,” Mobile Ad Hoc and Sensor Systems, 2008. MASS 2008. 5th IEEE International Conference on, 2008, pp. 802-807. S. Kent and K. Seo, “RFC 4301 - Secure Architecture for the Internet Protocol,” Dec. 2005; http://tools.ietf.org/html/rfc4301