Building Sustainable and High Integrity Sensor Networks

1. Building Sustainable and High IntegritySensor Networks An Overview of NESL Research Activities Ram Kumar and Mani Srivastava NETWORKED AND EMBEDDED SYSTEMS LAB (http://nesl.ee.ucla.edu) Funding acknowledgements – DARPA, NSF, ONR

2. Research @ NESL Networked Embedded Systems Energy Efficient Operation High Integrity Operation Applications Mobile Networked Embedded Systems Sustainable Operation EE ARR 2004

3. Sustainable software operation

4. Sustainable software operation • Require uninterrupted operation indefinitely • Post-deployment software updates are common • Customizing the system to the environment • Feature upgrades • Bug removal • Re-tasking of the system • Re-programming a deployed system is hard • System deployed in inhospitable terrains • Contains a large number of nodes • Remote reprogramming is essential for sustainability EE ARR 2004

5. Dynamic Loadable Binary Modules Dynamic Loadable Binary Modules Static SOS Kernel Hardware Abstraction Module Communication Memory Manager SOS Dynamic Software Re-Configuration • Remotely insert binarymodules into arunning kernel • Software reconfiguration without interrupting system operation • No stop and re-boot unlike differential patching • Superior performance over virtual machines • Design challenges • Dealing with severe resource constraints • Only 4 KB of RAM and 15 mW of active power consumption • Reliable operation of the dynamically evolving system EE ARR 2004

6. Inter-Module Message Passing Asynchronous communication Messages dispatched by a two-level priority scheduler Suited for services with long latency For e.g. – FFT Computation Inter-Module Function Calls Synchronous communication Kernel stores pointers to functions registered by modules Blocking calls with low latency Type-safe runtime function binding For e.g. – Neighborhood Information Module A Module B Module A Module B Indirect Function Call Post Module Function Pointer Table Message Buffer Inter-Module Communication EE ARR 2004

7. Module A System Call System Messages High Priority Message Buffer System Jump Table SOS Kernel Interrupt HW Specific API Hardware Module Kernel Interaction • Kernel provides system services and access to hardware • Kernel jump table re-directs system calls from modules to kernel handlers • Upgrade kernel independent of the module • Hardware interrupts and messages from the kernel to modules are dispatched through a high priority message buffer • Low latency • Concurrency safe operation EE ARR 2004

8. Memory Management • Modules need memory to store state information • Problems with static allocation • Worst case memory allocation – every variable is global • Problems with general purpose memory allocation • Non-deterministic execution delay • Suffers from external fragmentation • Use fixed-partition dynamic memory allocation • Memory allocated in blocks of fixed sizes • Constant allocation time • Low overhead • Memory management features • Guard bytes for run-time memory over-flow checks • Ownership tracking of memory blocks • Garbage Collection - Automatic free-up upon completion of usage EE ARR 2004

9. Enables sharing of sensor data between multiple modules Presents a uniform data access API to many diverse sensors Underlying device specific drivers register with the sensor manager Device specific sensor drivers control Calibration Data interpolation Sensor drivers are loadable Enables post-deployment configuration of sensors Enables hot-swapping of sensors on a running node Module A Module B Polled Access Periodic Access Signal Data Ready Sensor Manager getData dataReady MagSensor ADC I2C Sensor Manager EE ARR 2004

10. Programming Model #include <sos.h> #define MOD_ID 10 #define TIMER_PERIOD 10 //ms typedef struct{ uint16_t temp_val; } mod_state_t; int8_t mod_handler (void *state, Message *msg) { mod__state_t *s = (mod_state_t *) state; switch (msg->type){ case MSG_INIT: s->temp_val = 0; ker_timer_start(MOD_ID, 0, TIMER_REPEAT, TIMER_PERIOD); break; case INT_TIMER_TIMEOUT: s->temp_val = ker_sensor_poll(TEMP_SENSOR); break; default: return -EINVAL; } return SOS_OK; } • Program modules in C • SOS dispatches messages • Addressed by module ID • Pointer to module state • Modules handle messages • Switch on message type • Special message types • Initialization message • Timer timeout message • Final message • System calls API EE ARR 2004

11. Network Simulation Support • Source code Level Network Simulation • Pthread simulates hardware concurrency • UDP simulates perfect radio channel • Supports user defined topology and heterogeneous software configuration • Useful for verifying the functional correctness • Avrora: Instruction Level Simulation • Instruction cycle accurate simulation • Simple perfect radio channel • Useful for verifying timing information • See http://compilers.cs.ucla.edu/avrora/ EE ARR 2004

12. Supported micro controllers Atmel Atmega128 4 Kb RAM 128 Kb FLASH Oki ARM 32 Kb RAM 256 Kb FLASH Supported Radio Stacks RFM radio stack Chipcon CC1000 stack IEEE 802.15.4 MAC Chipcon CC2420 radio Easily Portable Operating System MicaZ Mica2 iBadge EE ARR 2004

13. High Integrity Sensor Networks How can the end-user rely on the information provided to it by the sensor network?

14. Why does misbehavior take place? Information returned may be distorted Noise: unavoidable • In sensing • In communication Fault: Persistent,transient,intermittent malfunction Malicious attacks: External attacker, compromised nodes EE ARR 2004

15. ???? ???? Where does misbehavior take place? Collaborative and local data processing Sensing Networking Cryptography Key Establishment Cryptographic frameworks Secure routing …… Is Network Security enough? EE ARR 2004

16. I detected a car at (x,y) It was a false alarm. No such car! I detected a car at (x,y) I detected a car at (x,y) Misbehavior while routing information I detected a car at (x,y) Misbehavior even while generating information I detected a car at (x,y) Decentralized decision making EE ARR 2004

17. Data aggregation f (67°, …, 68°) Network basestation 67° where f (x1, …, xn) = (x1 + … + xn) / n 64° 69° 71° 68° Computing the average temperature EE ARR 2004

18. Data aggregation + An Attack result is drastically affected f (67°, …, 1,000°) Network basestation 67° where f (x1, …, xn) = (x1 + … + xn) / n 64° 69° 71° 68° X 1,000° Computing the average temperature EE ARR 2004

19. Limitations of network security • Distributed collaborative signal processing • Network security →Make sure that only authenticated nodes participate. • Network security cannot→ Verify if nodes function properly • Distributed data gathering • Network security can → Ensure message integrity, confidentiality, secure relaying • Network security cannot → data authentication EE ARR 2004

20. Embedded in every social network is a web of trust • How does human societies evolve? • Principle of reciprocal altruism • Be nice to others who are nice to you • When faced with uncertainties • Trust them who have the reputation of being trustworthy Reputation based framework for sensor networks (RFSN) How do nodes trust each other? How do nodes trust the information provided by other nodes? Proposed solution: Form a similar community of trustworthy nodes in the network over time EE ARR 2004

21. Why this approach? • Sensor network already follow a communitymodel • Individual nodes do not have any utility • Collaborative information gathering, data processing and relaying • Missing element is trust…. • Nodes are constrained and they collaborate with every node • Internal adversaries exploit this very fact ! • Faulty sensors results in equally detrimental effects • RFSN incorporates intelligence into nodes • Exposes trust as an explicit metric ! • Cooperate with ONLY those nodes that are trustworthy EE ARR 2004

22. Watchdog mechanism Trust Behavior Reputation Second hand information Node level skeleton structure of RFSN • Observe the action of other nodes – Watchdog mechanism • Develop a perception of other nodes over time – Reputation • Predict their future behavior – Trust • Cooperate/Non-cooperate with trustworthy nodes – Behavior • Share experiences to facilitate community growth – Second hand information EE ARR 2004

23. Watchdog mechanism Trust Behavior Reputation Second hand information Protocol Development Monitoring Data Analysis Statistics…. Cryptography Decision theory Integration of approaches Development of high integrity sensor networks will be a combination of techniques from different fields EE ARR 2004

24. Summary • Wireless sensor networks have moved from laboratory test-beds to the real world • Posing new system design challenges • Sustainability • High Integrity • Energy efficiency • Nature of the domain demands novel solutions • System design, algorithms, applications EE ARR 2004

25. The NESL Team • Faculty • Mani B Srivastava • Ph.D Students • D. Jea, A. Kansal, G. Kulkarni, S. Ganeriwal, C.C. Han, H. Park, V. Raghunathan, R. Rengaswamy, R. Shea, A. Somasundara, V. Tsiatsis • M.S. Students • P. Aghera, R. Balani, A. Dixit, J. Friedman, J. Hsu, D. Lee, H. Shim, B. Vasu • Post-Doc/Industrial Visitor • K Fujii • Recent Alumni • Ph. D • A. Boulis, A. Savvides • M.S • Y. C. Kuan EE ARR 2004

26. References SOS - Download now and try it !! Anonymous CVS Access CVSROOT = anon@cvs.nesl.ucla.edu:/Volumes/Vol1/neslcvs/CVS Password = “anon” Module = “sos” Paper Reference • S. Ganeriwal, M. B. Srivastava, “Reputation-based framework for high integrity sensor networks,” Accepted in ACM Security for Ad-hoc and Sensor Networks (SASN 2004) EE ARR 2004

27. Source Authentication Adversaries use valid keys to authenticate bogus data Cryptography fails! • Different from message integrity • Checks if the data which node wants to provide is correct or not. • What if the data generated by the nodes is itself bogus? • Building blocks work on the premise of correct information • Timing synchronization, Localization, Calibration etc. • What about network programming? • Attacker could replay old programs. • SOS – Insertion of modules at runtime. • A buggy module can bring down the whole system! EE ARR 2004

28. Overview • Traditional network security mechanisms • Cryptography and authentication • Concentrates on providing secure relaying of data • Traditional mechanisms need to be tweaked • Existing solutions not portable • Develop solutions for the novel nature of sensor networks • Key establishment and management • Challenges - Scale, ad-hoc deployment, internal adversaries,… • PAKE– Approach of deriving the keys at runtime • But…. • Is developing customized cryptographic solutions for sensor networks enough? • Need to movebeyond cryptography EE ARR 2004

29. Authenticated Report Generation (ARG) Final report by node i: {i, E, T, MACi, MAClm ,…} Self Report by node i: {i, E, T, MACij,….} s.t. j  Neighbors of i MAClm acts as testimony for nodes l and m Node j checks using MACij EE ARR 2004

30. Prototype Implementation on motes • Developed over top of TinySec. • Feasible– Consumes only 809 bytes in RAM • Fast – MAC calculation requires just 1.2 ms • Efficient – Code developed in modular form • Tested scenarios • False negative attacks – Avoid missed events • Falsification – Generate bogus final report • Impersonation and Sybil – Use fake identities • Suppression – Don’t generate the self report • False Positive attacks – Avoid false alarms • Restricts the colluding abilities of adversaries • Nodes can only cheat about events close by • Provides automatic evasive mechanism • Reveals the identity of malicious nodes EE ARR 2004

31. Sensor “Network” Security

32. Sense-Response Applications EE ARR 2004

33. Problem Formulation • Local collaboration – Generate one final report • Security Implications • False negative attacks (False alarms) → Wastage of resources. • False positive attacks → Missed events • Attackers • Internally compromised nodes • Approach • Introduce explicit authentication mechanisms • Node-to-node authentication • Base station-to-node authentication Transmitting each message all the way to the base station wastes resources EE ARR 2004

34. Key-set up phase Normal system Vulnerable period Erase KI at this point No valid keys can be generated here Physical Attributes based Key Establishment (PAKE) • Post-deployment derivation • Derive the keys at runtime based on unique physical properties of the node • Focus on where and who reported the intrusion • Bind the cryptographic keys to location and identity • Use ONE global secret key that provides system secret • Pairwise key establishment! K12 = HKI(x1 || y1 || id1 || x2 || y2 || id2) EE ARR 2004

35. Evaluation • Pros • Scalable scheme – Easily extensible for large scale networks • Distributed and implicit - No exchange of keys over wireless links • Completely random keys • Resilient to external adversaries • Cons • Applicable to static sensor networks • Cannot allow runtime addition of new nodes • Improvements • Use higher layer abstractions such as regions. • Allows for constrained mobility of nodes • Comes at the cost of security • Use some high-end nodes • Act as proxies for runtime key establishment EE ARR 2004