The Impact of Java and Public Key Cryptography in Wireless Sensor ...

The Fourth International Conference on Wireless and Mobile Communications

The Impact of Java and Public Key Cryptography in Wireless Sensor Networking David Boyle and Thomas Newe Optical Fiber Sensors Research Centre, University of Limerick, Ireland {david.boyle, thomas.newe}@ul.ie typical mote and research platform for the development and application of WSNs in recent years is the Crossbow “MICAz” [3], programmed in network embedded systems C (nesC) [4], affected via the TinyOS operating system [5]. Applications of such WSNs are diverse in their range, encompassing military, medical, environmental, industrial and commercial areas [6]. As the plethora of application scenarios continues to expand, the need to secure the sensed and disseminated data continues also. The security requirements of an application design depend largely on the sensitivity of this transmitted data. Consider applications in the medical field, in which it is a legal prerequisite that all physiological patient data is kept confidential, or a military application; where privacy and security of the network are crucial to its success. Security concerns, in tandem with concerns relating to power management, network discovery, control and routing, collaborative signal and information processing, and tasking and querying, are all areas currently under research, and combine to inhibit the widespread deployment of WSN technology in many application fields [7]. Sun Microsystems have developed a WSN platform that runs Java code “on-the-metal” of their motes, known as Sun SPOTs [8,9]. There are many advantages to removing the need for a traditional operating system, but the major advantage in implementing a Java based system is the number of people to whom this technology will now be accessible. There are far superior numbers of Java programmers around the globe than there are C programmers, not to mention those capable of developing in nesC. The shift in trend to developing WSNs through Java has been further substantiated by the conversion of the Moteiv Corporation to Sentilla in late 2007, discontinuing their previous Tmote, based on nesC and TinyOS, in favor of developing a new Java powered Sentilla Tmote [10], which is currently

Abstract The evolution of Wireless Sensor Networks continues through the arrival of the Java development environment. More intuitive to a wider range of developers, and incorporating more powerful hardware; a number of residual research problems facing designers of Wireless Sensor Networks have been addressed. The objective of this paper is to introduce and provide some exposure to the latest development environment available for Wireless Sensor Networking, illustrate what achievements have already been made, and their immediate impact in the field. In particular, the problem of securing a potential deployment has been one of the major inhibitors to the widespread implementation of sensor networks; a problem which has been thoroughly addressed in the design of the Sun platform. This solution comes in the guise of a fully implemented and operational Public Key Infrastructure. This paper critiques the security services provided; whilst considering current knowledge pertaining to the security of Wireless Sensor Networks, in conjunction with the advantages of such a system and the opportunities it provides.

1. Introduction

W

IRELESS Sensor Networks (WSNs) can be defined as groups of independent nodes, communicating wirelessly over limited frequency and bandwidth [1]. The initial novelty of WSNs in comparison to traditional sensor networks was that they depended on dense deployment and coordination to successfully execute their tasks. This method of distributed sensing allowed for closer placement to the phenomena to be achieved than is possible using a single sensor, when the exact location of a particular event is unknown [2]. Originally based on Microeletromechanical Systems (MEMS), sensor networks continue to evolve. A

978-0-7695-3274-5/08 $25.00 © 2008 IEEE DOI 10.1109/ICWMC.2008.64

288

Authorized licensed use limited to: Korea Advanced Institute of Science and Technology. Downloaded on August 26, 2009 at 02:16 from IEEE Xplore. Restrictions apply.

the widespread deployment that has threatened since its conception and early development. The rest of this section will be devoted to illustrating the various similarities between this platform and previous ones, with a focus on the system architecture, communications protocol and security provided.

in limited beta release. The objectives of this paper are to provide additional exposure to the latest development platforms for WSNs, reiterate the current standing on security provision for WSNs and to describe current research and goals of our work in the area of security for WSNs. Section 2 will provide a comparative technical analysis of the Sun SPOT platform. Section 3 will review the current knowledge pertaining to security in WSNs. Section 4 documents the provision of security through Java. It is designed to illustrate the relative ease and benefits of implementation in comparison to previous platforms. This section will also consider implementing the appropriate mechanisms in the Java WSN domain, and describe what can be achieved. Finally, a conclusion and some ongoing/future work will be presented.

2.3. Communications Protocol As can be seen in Table 1, the Sun SPOT employs the CC2420 radio transceiver. This is IEEE 802.15.4 compliant [11], as are the Sun SPOTS. This is the industry standard for low-rate wireless personal area networks (LR-WPAN), and its power conservation objectives compliment the same design goal as the ARM processor used in the motes. Only the standard is supported (i.e. the PHY and MAC layers) by Sun, but the potential exists to implement higher layers of a communications protocol; ZigBee [12], for example, would sit above these layers, and there is nothing to prevent this from being done. There is, however, a LowPAN layer, that sits above the IEEE 802.15.4 layers, implemented in the SPOT motes. This layer has the immediate implication of incompatibility between SPOTs and other motes (which do not have the layer) with respect to wireless communication. This layer is designed to extend connectivity of the SPOTs, by allowing them to have IPv6 capabilities [13]. A layer modeled after LowPAN that sits directly on the IEEE 802.15.4 layers implemented in the motes would allow for wireless communication between the Sun SPOTs and motes.

2. Sun SPOT 2.1. Comparative Specifications Table 1. Mote comparison

µC

MICAz

Sun SPOT

Atmega128 (8 bit)

ARM920T (32 bit)

RAM

4 kB

512 kB

Program Memory

512 kB

4 MB

Radio

CC2420

CC2420

OS

TinyOS

None

nesC

Java

Language

2.4. Comparison The 32 bit microprocessor present in the SPOT motes is far more powerful than that of any other WSN mote available to date. There is also much greater memory available. It is obvious that there are significant advantages to having greater processing power and available memory. The major difference lies in the development environment. The Java programming environment, specifically the Squawk VM (a small virtual machine based on JME), provides the ability to run applications “on the metal”, thus reducing overhead and improving performance. These applications can be developed using open source development tools such as Netbeans or Eclipse; which are industry standard IDEs. Rapid application development, a design goal of the Sun SPOT project, is a reality in this environment. Applications of these motes have developed at an incredible pace, compared to their emergence based on

In the SPOT development kits a host of sensors are provided; including accelerometers, light and temperature sensors on the development board.

2.2. Background Sun Small Programmable Object Technology (Sun SPOT) began as an “exploration of wireless transducer technologies” in late 2003, before it was patented in 2006 by Sun Microsystems, and released in development kit form in 2007 [9]. It was designed for “out of the box” functionality, contrary to previous WSN development environments. Easily programmable in a Java environment; this platform could provide the technology with a means to achieve

289

Authorized licensed use limited to: Korea Advanced Institute of Science and Technology. Downloaded on August 26, 2009 at 02:16 from IEEE Xplore. Restrictions apply.

legacy motes. A sample of these can be found on the project website [9]. Physically, a Sun SPOT is larger than the average WSN mote. The configuration of the mote could be significantly changed, and its size considerably reduced for development for a particular application scenario.

Protocol (SNEP), providing confidentiality through encryption and authentication and µTESLA for broadcast authentication. Employing a pre-deployed master key in each of the nodes, from which independent keys could be derived via a pseudorandom function, the RC5 block cipher for encryption in CTR mode, a message authentication code (MAC) for authentication (CBC-MAC) and µTESLA for broadcast authentication, the first comprehensive solution for securing WSNs in a lightweight manner was created. In 2004, Karlof et al. declared that SNEP was neither fully implemented nor fully specified, and proposed its replacement: TinySec. This provided similar services to SPINS; including access control and integrity through authentication and confidentiality through encryption. Further flexibility was added through the option of providing authentication only, without encryption. In the final specification, the Skipjack block cipher was prescribed, operating in CBC mode, for encryption, and CBC-MAC for authentication. Any keying mechanism could be used in this system. The success of this security architecture was cemented through its distribution with official releases of TinyOS version 1.x, and its adoption as a link layer basis for many research projects, and in industry by companies such as Bosch. There have been numerous architectures and protocols designed for optimal WSN implementation based upon similar keying and cryptographic procedures. LEAP, for example, emerged with a number of novel and WSN specific keying protocols, but upon full implementation (known as LEAP+) it became very similar to what was previously available. LEAP+ employed a pre-deployed master key, through which others could be created, used RC5 for encryption and CBC-MAC for authentication, and µTESLA for broadcast authentication. Built upon the lower layers defined by the IEEE 802.15.4 standard, the ZigBee specification (2005) specifies a flexible security suite. It is based on the same principles as before, but optionally employs the Rijndael cipher (specified in NIST FIPS pub. 197). CBC-MAC is used for authentication, in conjunction with the Rijndael cipher (in counter mode), operating in a mode known as CCM. It introduces the concept of a Trust Center; a role played by the ZigBee coordinator, which authenticates devices wishing to join the network, maintains and distributes network keys, and enables end-to-end security between devices. A more in-depth consideration of these security architectures can be found in [14].

2.5. Security The area of security has been addressed comprehensively in the design of the Sun SPOT. Although there are mechanisms in place under the IEEE 802.15.4 standard, and hardware encryption (AES 128) provided by the CC2420 radio, the developers have implemented an Elliptic Curve Cryptography based security mechanism, resulting from concerns related to those security mechanisms and their own expertise in the area. This mechanism will be examined thoroughly in the next sections; with respect to previous security provisions for WSNs and other public key infrastructures (PKIs) that could be considered.

3. WSN Security The problem of securing WSNs has been one of the most important and challenging research areas in the field since the beginning. There have been many efforts to secure applications effectively, employing a diverse range of security mechanisms. The resource constrained nodes have raised issues with power consumption, latency, processor usage and memory requirements; all of which have been at a premium in wireless sensor devices to date. Varying applications require flexibility in the levels of security provided; given that there is always a resource consumption trade-off present when security is invoked. This section considers the various efforts to date, including predeployed, symmetric and public (asymmetric) keying schemes, and suggests the best possible solutions available.

3.1. Symmetric Key Algorithms Initially, a pre-deployed keying mechanism, employing a symmetric key algorithm, was thought to be the optimal solution for securing WSNs. Given the limited resources and lack of in-depth research in the field, this was a reasonable assumption, and suitable for early deployments of WSNs. The SPINS suite of security protocols was proposed in 2002; the suite optimized for sensor networks. It was comprised of two building blocks; Secure Network Encryption

290

Authorized licensed use limited to: Korea Advanced Institute of Science and Technology. Downloaded on August 26, 2009 at 02:16 from IEEE Xplore. Restrictions apply.

The choice of security architecture is being narrowed as information and knowledge increases in the field. Given that it is a well known fact that the same levels of security can be achieved for much smaller key sizes in ECC when compared with RSA; the former is the obvious choice should a designer wish to implement a PKI. Considering the symmetric architectures, the security operations carried out in the ZigBee security suite are the most efficient (AES cipher and CBC for authentication). It is argued that ECC is a good match for AES, as they scale linearly, and the subject of security in WSNs could now come down to the decision of implementing an AES or ECC architecture, in conjunction with further optimization.

3.2. Public Key Infrastructures (PKI) Conventionally considered to be too computationally expensive for implementation in WSNs, there has been a lot of research into employing PKIs to address this problem. Given the lack of the aforementioned resources, and the fact that symmetric key algorithms can be hundreds to thousands of times faster than their asymmetric counterparts, focus was placed on the symmetric key algorithms for securing WSNs. Although this was the case, there have been a number of successful implementations of PKIs for securing WSNs. An early implementation of this security architecture was known as EccM. This was designed to address the shortcomings of the TinyOS secret key infrastructure (TinySec). It specified the use of Elliptic Curve Cryptography over F2P to achieve the smaller key sizes necessary for the MICA2 mote; the platform upon which this work was carried out. It proved that an operational PKI is feasible for WSNs, but also that optimization needed to be implemented at this stage. TinyECC is another variation of an elliptic curve based scheme for WSNs. Developed for more recent motes, including the MICAz, it is optimized for use with the TinyOS platform, via a number of optimization techniques, and uses ECC over FP, contrary to EccM. Included in this architecture is flexibility; as it is a configurable library for ECC operations in WSNs, allowing a designer to implement the appropriate scheme optimal to the application (execution time, resource consumption etc.). Traditional internet based security schemes had been thought to be too complex to run on WSNs. This was disproven, however, in 2005, when Gupta et al. released an end-to-end security architecture suitable for use with WSNs. In addition to proving the feasibility of implementing PKIs in WSNs; by using elliptic curve cryptography, they also managed to create a complete secure web server stack that can run on extremely limited resources. Nicknamed Sizzle, this small HTTPS stack was implemented on multiple generations of the Berkeley/Crossbow motes; the devices allowed to be monitored and controlled securely via a web browser. This is significant, as this is the security architecture used in the Sun SPOT WSN platform. Further investigation of this architecture is provided in the next section.

4. Sun SPOT Security Security considerations have been thoroughly addressed in the design of the Sun SPOT mote. Included in the design of these motes is ECC technology (actually developed at Sun Labs); which empowers the previously mentioned small-footprint, secure web server stack, called Sizzle. This section will investigate the operation of this security architecture; what it is and how it is implemented. Also considered is the invocation of other security primitives in the Java programming environment.

4.1. Elliptic Curve Cryptography Elliptic Curve Cryptography (ECC) is a public-key cryptosystem that operates over points on an elliptic curve, contrary to conventional public-key systems that operate directly on large integers. The Elliptic Curve Discrete Logarithmic Problem (ECDLP) is what makes ECC more efficient than other established public-key systems. An elliptic curve is a plane curve defined by the equation:

y 2 = x3 − 4x + 4

(1)

The primary operation in ECC, in cryptographic terms, is scalar point multiplication. This is performed through a combination of point additions and point doublings. Scalar point multiplication computes:

Q = kP ,

(2)

where a point, P, is multiplied by an integer, k, which results in another point on the curve, Q. The ECDLP states that given P and Q = kP, it is difficult to find k. A base point, G, is fixed for each curve. The random large integer, k, acts as a private key; while the result of multiplying k by the base point, G, returns the

3.3. The Security Decision

291

Authorized licensed use limited to: Korea Advanced Institute of Science and Technology. Downloaded on August 26, 2009 at 02:16 from IEEE Xplore. Restrictions apply.

corresponding public key. The best known method for solving this problem is computationally infeasible for large values of k, and the running time is fully exponential, compared to RSA or DSA, which have sub-exponential solving speeds. Additional credence has been added to the use of ECC as it was approved by NIST for government use in the United States (FIPS Pub 186-2).

The certificate created is an X.509; created using the public key of the SPOT, and signed using the private key of the SDK. X.509 is an ITU-T standard for PKIs. It specifies standard formats for public key certificates, among other things.

4.4. Implications What is provided through the Sun SPOT platform is a secure development environment that is relatively transparent to the user. Effectively, they have implemented a standard security architecture for their platform. This had not been achieved in wireless sensor networking to date. Additionally, it has been implemented using a PKI; which operates comfortably within the resource consumption parameters for feasible utility in WSNs.

4.2. Sizzle Derived from “Slim” SSL (Secure Sockets Layer), Sizzle is employed to secure communications for this platform. It is based on the use of the simple HTTP request-and-response protocol used over SSL; referred to as HTTPS. This enables the established security properties of SSL to be used for the embedded internet, or WSNs. SSL itself provides encryption, source authentication and integrity protection; all of which are required for successful secured communication in WSNs. Previously described, the encryption portion of this architecture is performed using ECC (although SSL is capable of supporting different cryptographic algorithms). An ECDH-ECDSA handshake is employed to generate an agreed cipher suite and validate the public keys of the devices. Some of the overhead involved in public key operation is avoided through the reuse of previously established master secrets. This process is known as “session resumption” or “session caching”.

4.5. Evaluation The arrival of this development environment has addressed a number of the widespread concerns relating to WSNs: Strength of Security: The next generation architecture that has been implemented is on a par with current Internet standard solutions. It has been standardized by NIST, ANSI, IEEE and IETF, and is continuing to gain more support and momentum. Scalability: Key management has been of great concern in WSNs. This state of the art mechanism can reduce concerns regarding this, as key management is extended from the previously described ownership model. Resource Consumption: It is reported that using the sleep mode in an application, the battery life of the development kit mote can last up to 900 days. Considering the ideals of WSNs in relation to one-use devices, this is within the bounds of acceptability. There is room for improvement in the area. Speed/Efficiency: There is no visible latency; however this may differ with larger scale network deployments. Node Tampering: Given the architecture, it should be impossible to insert a malicious node into the network, as this would require reprogramming of the node. The adversary would need access to the SDK in order to achieve this.

4.3. Sun SPOT Motes Based on numerous security considerations, it was decided that a security architecture other than the one provided under the IEEE 802.15.4 should be implemented. When initially connected, the mote and the host establish a public-private key pair. Before a Sun SPOT is associated with any “owner”, it has no public key. The first user to deploy an application to that device automatically transfers a public key to the mote. Only the owner may now make any changes to the device. This is enforced by digitally signing the deployed application with the owner’s private key, and verifying the signature via the trusted public key stored. Similarly, secure communication between motes belonging to the same owner is enforced as each SPOT uses its certificate to identify itself. This certificate is generated and sent to the SPOT along with the certificate of the users SDK.

4.6. Residual Concerns The security of the host machine which contains the private key of the SDK, in plaintext, is assumed. This may be of concern to a potential designer. It may be

292

Authorized licensed use limited to: Korea Advanced Institute of Science and Technology. Downloaded on August 26, 2009 at 02:16 from IEEE Xplore. Restrictions apply.

possible to physically extract information from a SPOT, should an adversary capture one. A primary concern is the possibility that a key could become available to an adversary by some means; this would put the entire network at risk of attack.

[3] Crossbow Technologies Inc. (2007) MICAz [online], available: http://www.xbow.com/Products/Product_pdf_files/Wireless_ pdf/6020-0060-01_A_MICAz.pdf [accessed 11 Mar 2008] [4] Gay, D., Levis, P., von Behren, R., Welsh, M., Brewer, E. and Culler, D. (2003) ‘The nesC Language: A Holistic Approach to Network Embedded Systems’, PLDI Conference on Programming Language Design and Implementation, San Diego, California, USA, 09-11 June 2003, New York, USA: ACM Press, 1-11. [5] Levis, P., Madden, S., Gay, D., Polastre, J., Szewczyk, R., Woo, A., Brewer, E., Culler, D. (2004) ‘The Emergence of Networking Abstractions and Techniques in TinyOS’, Proceedings of the First Symposium on Networked Systems Design and Implementation, 29th-31st March, 2004, San Francisco, CA, USA. [6] Garcia-Hernandez, C. F., Ibarguengoytia-Gonzalez, P. H. and Perez-Diaz, J. A. (2007) ‘Wireless Sensor Networks and Applications: A Survey’, IJCSNS International Journal of Computer Science and Network Security, 7(3), 264-273. [7] Chee-Yee Chong, and Kumar, S. P. (2003), “Sensor Networks: Evolution, Opportunities, and Challenges”, Proceedings of the IEEE, Vol. 91, No. 8, August 2003: IEEE, 1247-1256. [8] Tow, R., and Laurel, B. (2008) Sun “SPOT” Wireless Sensor Networks [online], available: http://www.tauzero.com/Rob_Tow/Sun-SPOTS-SensorNetworks.html [accessed 11 Mar 2008]. [9]Sun Microsystems, Inc. (2008) Project Sun SPOT: Sun Small Programmable Object Technology [online], available: http://www.sunspotworld.com/ [accessed 11 Mar 2008]. [10] Sentilla Corporation (2007) Pervasive Computing Solutions [online], available: http://www.sentilla.com/ [accessed 11 Mar 2008]. [11] IEEE 802.15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for LowRate Wireless Personal Area Networks (LR-WPANs) (2003), 3 Park Avenue, New York, USA: IEEE. [12] ZigBee Specification v1.0: ZigBee Specification (2005), San Ramon, CA, USA: ZigBee Alliance. [13] Arch Rock Corporation (2007) Arch Rock IP/6LoWPAN Overview: An IPv6 Network Stack for Wireless Sensor Networks [online], available: http://www.archrock.com/downloads/Arch_Rock_6LoWPA N-Whitepaper.pdf [accessed 11 Mar 2008]. [14] Boyle, D., Newe, T. (2008) ‘Securing Wireless Sensor Networks: Security Architectures’, Journal of Networks JNW, 3(1), 65-77 [accessed 11 Mar 2008].

5. Conclusion Java enabled motes are paving the way for truly pervasive computing. Far more intelligent applications can be built, more rapidly, and by a greater demographic. This is one of the explicit advantages of employing a Java based development environment. Additionally, implementing the Sun SPOTs as the basis for a WSN implies that users are automatically deploying a relatively secure application. This had been a concern in the past, as designers may not have implemented a correctly secured network. The advantage of developing WSNs through Java is further emphasized by the abandonment of the TinyOS platform by Sentilla (formerly the Moteiv Corporation), who were one of the major contributors and innovators, in favor of the Java development environment. They have also cited the potential for more rapid development and widespread deployment of WSNs given this new environment.

6. Future Work Further investigation into the performance of the cipher suite provided by the Sun SPOT platform is under way. There is potential to implement various other cipher suites, resulting from the ease of implementation of cryptographic protocols under the Java platform. Of interest will be the performance of the AES-CCM* suite. For now, this may have to be implemented behind the existing security architecture for evaluation purposes. More powerful processors and expanded memory will accommodate greater algorithms, but in keeping with the design goals of wireless sensor networks, the most robust yet lightweight solutions, in terms of resource consumption, will continue to be sought, with extended network lifetime the primary goal.

References [1] Akyildiz, I. F., Su, W., Sankarasubramaniam, Y., Cayirci, E. (2002) ‘A Survey on Sensor Networks’, IEEE Communications Magazine, 40(8), 102-114. [2] Bharathidasan, A., Anand, V., Ponduru, S. (2001), Sensor Networks: An Overview, Department of Computer Science, University of California, Davis 2001. Technical Report

293

Authorized licensed use limited to: Korea Advanced Institute of Science and Technology. Downloaded on August 26, 2009 at 02:16 from IEEE Xplore. Restrictions apply.