Security for Sensor Networks

1. SecurityforSensor Networks By: Prateek Arora By Prateek Arora

2. Introduction • A sensor network consists of many spatially distributed sensors called nodes, which are used to monitor or detect phenomena at different locations, such as temperature changes, vibration, pressure, movement or pollutant levels. • Each sensor is intended to be physically small and inexpensive, thus making it possible to produce and deploy them in large numbers. By Prateek Arora

3. How does it work? • A sensor is equipped with a radio transceiver, a small microcontroller, and an energy source, usually a battery. • In order to meet the objective of the sensors being small and low-cost, resources in terms of energy, memory, computational speed and bandwidth are severely constrained. By Prateek Arora

4. How does it work? (contd.) • The sensors use each other to transport data to a monitoring entity. Because each sensor has a limited energy supply, sensors must conserve their energy if the network is to last a long time. • Sensor networks are applied in a wide variety of areas, such as video surveillance, traffic monitoring, air traffic control, robotics, cars, home monitoring and manufacturing and industrial automation. One typical application in environmental monitoring is Sensor Web. By Prateek Arora

5. Applications By Prateek Arora

6. Applications (contd.) By Prateek Arora

7. Applications (contd.) By Prateek Arora

8. Sensor Network vs Ad-Hoc • Improvements in wireless networking and micro-electro-mechanical systems (MEMS) are contributing to the formation of a new computing domain – distributed sensor networks. • These ad-hoc networks of small, fully programmable sensors will be used in a variety of applications: on the battlefield, as medical devices, in equipment maintenance and in perimeter security systems. By Prateek Arora

9. Sensor Network vs Ad-Hoc (contd.) • These distributed sensor networks are characterized by limited power supplies, low bandwidth, small memory sizes and a different traffic model. • The traffic model of mobile ad-hoc networks is typically many-to-many whereas the traffic model of a sensor network is more of a hierarchical model and/or many to one. By Prateek Arora

10. Sensor Network vs Ad-Hoc (contd.) • Generally, MEMS are significantly more resource constrained than typical “mobile” or “handheld” devices. A node in a sensor network may or may not have computing requirements. • In the case where computations are required, if the cost of a communication is less than the cost of the computation, the computation may be replaced by a request to a computationally robust central location. By Prateek Arora

11. Threats • The threat to a sensor network is different from the threat to a mobile ad-hoc network. • As such, existing network security mechanisms, including those developed for Mobile Ad-Hoc Networks, are a poor fit for this domain. • So far, much research has focused on making sensor networks feasible and useful, and has not concentrated on security. • Research into authentication and confidentiality mechanisms designed specifically for sensor data and network control protocols is needed. • Given the fact that little prior work exists in this space, there is a need both to identify the problems and challenges and propose solution techniques. By Prateek Arora

12. Threats (contd.) • Like their mobile ad-hoc counterparts sensor networks lack a fixed infrastructure and the topology is dynamically deployed. • Addressing the security of mobile ad-hoc networks, Yi pointed out that if the routing protocol can be subverted and messages altered in transit, then no amount of security on the data packets can mitigate a security threat at the application layer. • Consequently, “Security Aware Ad-hoc Routing” (SAR) was introduced. SAR characterizes and explicitly represents the trust values and relationships associated with ad-hoc nodes and use these values to make secure routing decisions. By Prateek Arora

13. Security Aware Ad-hoc Routing (SAR) • They address two problems: • Ensuring that data is routed through a secure route composed of trusted nodes. • The security of the information in the routing protocol. • To motivate their scenario, they use the example of two military generals wishing to communicate via an ad hoc network using a generic form of the Ad-Hoc On Demand Distance Vector Routing (AODV) protocol. • They employ a route discovery protocol where only nodes with a security metric equivalent to the sender and receiver participate in the routing process. Their work appears to be based on the Bell-La Padula Confidentiality Model. Their model, however, is dependent on self-enforcement where nodes with a lower than required security level voluntarily opt out of participating in the hop-by-hop routing process. By Prateek Arora

14. SPINS • Perrig introduced “SPINS: Security Protocols for Sensor Networks” comprised of Sensor Network Encryption Protocol (SNEP) and μTESLA. • SPINSpresents an architecture where the base station accesses nodes using source routing. By Prateek Arora

15. SNEP • SNEP providesthe following important baseline security primitives: Data confidentiality, two-party data authentication, and data freshness. • Aparticularly hard problem with SNEP is to provide efficient broadcast authentication,which is an important mechanism for sensor networks. By Prateek Arora

16. μTESLA • μTESLA is to provide authentication to data broadcasts. • μTESLA is a new protocol which provides authenticated broadcast for severely resource-constrained environments. • It is the “micro” version of the Timed, Efficient, Streaming, Loss-tolerant Authentication Protocol, providing authenticated streaming broadcast. By Prateek Arora

17. How does SNEP work? • In SNEP each nodejshares a unique master key Kjwith the base station. This master key is used to derive all other keys. • For data encryption SNEP employs a one time encryption key produced by using a key derived from Kjand an incremental counter (message indicator) as inputs to the RC5 cryptographic algorithm. By Prateek Arora

18. How does SNEP work? • The RC5 algorithm outputs a binary string that is used as the one time key. The message is XORed with the one time key, transmitted and the counter is incremented in preparation for the next message. • The base station, aware of the node’s counter value and the derived key, produces the identical one time key, XORs the encrypted message with the one time key to produce the clear text. By Prateek Arora

19. A Prototype Sensor Network • At UC Berkeley, in Cory Hall of EECS buildings, a prototype networks of small sensor devices is created under the SmartDust program. By Prateek Arora

20. Prototype (contd.) • This prototype consists of nodes, small battery powered devices, that communicate with a more powerful base station, which in turn is connected to an outside network. • By design, these sensors are inexpensive, low-power devices. As a result, they have limited computational and communication resources. • The sensors form a self-organizing wireless network (see Figure 1) and form a multihop routing topology. Typical applications may periodically transmit sensor readings for processing. By Prateek Arora

21. Prototype (contd.) • Figure 1 shows the organization of a typical SmartDust sensor network. • The network forms around one or more base stations, which interface the sensor network to the outside network. The sensor nodes establish a routing forest, with a base station at the root of every tree. Periodic transmission of beacons allows nodes to create a routing topology. • Each node can forward a message towards a base station, recognize packets addressed to it, and handle message broadcasts. The base station accesses individual nodes using source routing. • We assume that the base station has capabilities similar to the network nodes, except that it has enough battery power to surpass the lifetime of all sensor nodes, sufficient memory to store cryptographic keys, and means for communicating with outside networks. By Prateek Arora

22. Prototype (contd.) • In the sensor applications developed so far, there has been limited local exchange and data processing. The communication patterns within our network fall into three categories: • Node to base station communication, e.g. sensor readings. • Base station to node communication, e.g. specific requests. • Base station to all nodes, e.g. routing beacons, queries or reprogramming of the entire network. • Our security goal is to address primarily these communication patterns, though we do show how to adapt our baseline protocols to other communication patterns, i.e. node to node or node broadcast. By Prateek Arora

23. Results of prototype experiment • Table 1 summarizes the performance characteristics of these devices. • At 4MHz, they are slow and underpowered (the CPU has good support for bit and byte level I/O operations, but lacks support for many arithmetic and some logic operations). They are only 8-bit processors and communication is slow at 10 Kbps. • The operating system is particularly interesting for these devices. For this prototype TinyOS was used. This small, event-driven operating system consumes almost half of 8KB of instruction flash memory, leaving just 4500 bytes for security and the application. By Prateek Arora

24. By Prateek Arora

25. Inference of results for security • It is hard to imagine how significantly more powerful devices could be used without consuming large amounts of power. The energy source on our devices is a small battery, so we are stuck with relatively limited computational devices. • Similarly, since communication over radio will be the most energy-consuming function performed by these devices, we need to minimize communications overhead. By Prateek Arora

26. Inference (contd.) • The limited energy supplies create tensions for security: • On the one hand, security needs to limit its consumption of processor power; • On the other hand, limited power supply limits the lifetime of keys (battery replacement is designed to reinitialize devices and zero out keys). By Prateek Arora

27. Is sensor security possible? • The constraints as per inferences made through the prototype make it impractical to use the majority of the current secure algorithms, which were designed for powerful workstations. • For example, the working memory of a sensor node is insufficient to even hold the variables (of sufficient length to ensure security) that are required in asymmetric cryptographic algorithms (e.g. RSA, Diffie-Hellman), let alone perform operations with them. By Prateek Arora

28. Challenges • A particular challenge is broadcasting authenticated data to the entire sensor network. Current proposals for authenticated broadcast are impractical for sensor networks. • Most proposals rely on asymmetric digital signatures for the authentication, which are impractical for multiple reasons (e.g. long signatures with high communication overhead of 50-1000 bytes per packet, very high overhead to create and verify the signature). • Furthermore, previously proposed purely symmetric solutions for broadcast authentication are impractical: Gennaro and Rohatgi’s initial work required over 1 Kbyte of authentication information per packet, and Rohatgi’s improved k-time signature scheme requires over 300 bytes per packet. By Prateek Arora

29. Challenges (contd.) • It has been proposed the authenticated streaming broadcast TESLA protocol to counter these challenges. • TESLA is efficient for the Internet with regular desktop workstations, but does not scale down to our resource-starved sensor nodes. • So, we extend and adapt TESLA such that it becomes practical for broadcast authentication for sensor networks. We call this new protocol μTESLA. By Prateek Arora

30. Possible solutions • As per the measurements under the SmartDust program show that adding security to a highly resource-constrained sensor network is feasible. • The possible solutions include an authenticated routing protocol and a two-party key agreement protocol, and demonstrates that our security building blocks greatly facilitate the implementation of a complete security solution for a sensor network. • Given the severe hardware and energy constraints, we must be careful in the choice of cryptographic primitives and the security protocols in the sensor networks. By Prateek Arora

31. Solutions (contd.) TRUST REQUIREMENTS: • Generally, the sensor networks may be deployed in un-trusted locations. • While it may be possible to guarantee the integrity of each node through dedicated secure microcontrollers, it is felt that such an architecture is too restrictive and does not generalize to the majority of sensor networks. Instead, we assume that individual sensors are un-trusted. • Our goal is to design the SPINS key setup so a compromise of a node does not spread to other nodes. • Basic wireless communication is not secure. Because it is broadcast, any adversary can eavesdrop on the traffic, and inject new messages or replay and change old messages. Hence, SPINS does not place any trust assumptions on the communication infrastructure, except that messages are delivered to the destination with nonzero probability. By Prateek Arora

32. Solutions (contd.) • Other requirements of possible solutions:- • Data Confidentiality: • A sensor network should not leak sensor readings to neighboring networks. In many applications (e.g. key distribution) nodes communicate highly sensitive data. • The standard approach for keeping sensitive data secret is to encrypt the data with a secret key that only intended receivers possess, hence achieving confidentiality. By Prateek Arora

33. Solutions (contd.) • Other requirements of possible solutions:- • Data Authentication: • An adversary can easily inject messages, so the receiver needs to make sure that the data used in any decision-making process originates from the correct source. Informally, data authentication allows a receiver to verify that the data really was sent by the claimed sender. By Prateek Arora

34. Solutions (contd.) • Other requirements of possible solutions:- • Data Integrity: • In communication, data integrity ensures the receiver that the received data is not altered in transit by an adversary. In SPINS, we achieve data integrity through data authentication, which is a stronger property. By Prateek Arora

35. Solutions (contd.) • Other requirements of possible solutions:- • Data Freshness: • Data freshness implies that the data is recent, and it ensures that no adversary replayed old messages. • We identify two types of freshness: • Weak freshness, which provides partial message ordering, but carries no delay information. • Strong freshness, which provides a total order on a request-response pair, and allows for delay estimation. • Weak freshness is required by sensor measurements, while strong freshness is useful for time synchronization within the network. By Prateek Arora

36. Conclusion • Since Sensor networks is still an up coming technology, so most of the research has been dedicated towards making it more efficient. Although, many researchers have suggested their own security protocols in their papers but, almost all of the suggested solutions are based on SPINS protocol. By Prateek Arora

37. Questions? • What does SPINS stands for? • Everywhere, all what is mentioned is, SPINS: Security Protocol for Sensor Networks. • What are SPINS security building block? • To achieve the security requirements we have designed and implemented two security building blocks: SNEP and μTESLA. • SNEP provides data confidentiality, two-party data authentication, integrity, and freshness. • μTESLA provides authentication for data broadcast. We bootstrap the security for both mechanisms with a shared secret key between each node and the base station. • What are basic requirements for a possible solutions to the threats to sensor network? • Data Authentication, Data Integrity, Data Freshness, and Data Freshness. By Prateek Arora

38. References • http://www.google.co.in • http://www.csee.umbc.edu/cadip/2002Symposium/sensor-ids.pdf • http://www.ece.cmu.edu/~adrian/projects/mc2001/mc2001.pdf By Prateek Arora