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

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

3. Sustainable software operation

4. EE ARR 2004 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

5. EE ARR 2004 SOS Dynamic Software Re-Configuration  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 Hardware Abstraction Module Communication Memory Manager Static SOS Kernel Dynamic Loadable Binary Modules Dynamic Loadable Binary Modules  Remotely insert binary modules into a running kernel  Software reconfiguration without interrupting system operation  No stop and re-boot unlike differential patching  Superior performance over virtual machines

6. EE ARR 2004 Inter-Module Communication 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 Post Message Buffer Module AModule BModule A Module Function Pointer Table Indirect Function Call Module B

7. EE ARR 2004 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 Module A System Jump Table Hardware System Call High Priority Message Buffer HW Specific API Interrupt System Messages SOS Kernel

8. EE ARR 2004 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

9. EE ARR 2004 Sensor Manager  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 Periodic Access getData Sensor Manager Module AModule B I2C MagSensor ADC dataReady Signal Data Ready Polled Access

10. EE ARR 2004 Programming Model  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 #include #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; }

11. EE ARR 2004 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/http://compilers.cs.ucla.edu/avrora/

12. EE ARR 2004 Easily Portable Operating System 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 MicaZMica2 iBadge

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

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

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

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

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

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

19. EE ARR 2004 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

20. EE ARR 2004 Reputation based framework for sensor networks (RFSN) How do nodes trust each other? How do nodes trust the information provided by other nodes? 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 Proposed solution: Form a similar community of trustworthy nodes in the network over time

21. EE ARR 2004  Sensor network already follow a community model  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 Why this approach?

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

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

24. EE ARR 2004 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

25. EE ARR 2004 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

26. EE ARR 2004 References 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) SOS - Download now and try it !! Anonymous CVS Access CVSROOT = anon@cvs.nesl.ucla.edu:/Volumes/Vol1/neslcvs/CVS Password = “anon” Module = “sos”

27. EE ARR 2004  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! Source Authentication Adversaries use valid keys to authenticate bogus data Cryptography fails!

28. EE ARR 2004 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 move beyond cryptography

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

30. EE ARR 2004 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

31. Sensor “Network” Security

32. EE ARR 2004 Sense-Response Applications

33. EE ARR 2004 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

34. EE ARR 2004 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 = H KI (x1 || y1 || id1 || x2 || y2 || id2) Key-set up phase Normal system Vulnerable periodErase KI at this point No valid keys can be generated here

35. EE ARR 2004 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