1. 1 Sensor Networks Security and Privacy in Sensor Networks Haowen Chan and Adrian Perrig SPINS Adrian Perrig, Robert Szewczyk, J.D. Tygar, Victor Wen and David E. Culler Denis Golosov & Evgenya Borisenko

2. 2 Security and Privacy In Sensor Networks Outline What is a sensor network? Sensor networks’ applications Security threats  Sensor node compromise  Eavesdropping  Privacy of sensed data  Denial-of-service attacks  Malicious use of sensor networks

3. 3 What is a Sensor Network? Sensor – tiny device with an ability to sense a specific property: measure heat, moisture, pressure etc. Sensors have limited resources in terms of:  Computing power.  Memory.  Energy Supply. http://gc.sfc.keio.ac.jp/class/2003_gc00001/slides/15/index_34.html

4. 4 What is a Sensor Network? Sensor network – a network of many sensors which is formed around a base station. Communication medium – wireless broadcast. Can be spread in various environments. www.smartspaces.csiro.au

5. 5 Sensor networks’ applications Smart spaces: climate sensing and control in office buildings and home environmental sensing systems for temperature, light, moisture and motion. Emergency response information: sensor networks will collect information about structural integrity of buildings, pollution levels, etc. Sensor information must be collected and passed in secure ways to emergency response personnel. Energy management: sensors can help avoiding critical conditions in power supply.

6. 6 Sensor networks’ applications Medical monitoring: we envision a future where individuals with some types of medical conditions receive a constant monitoring through sensors. Battlefield management: remote sensors can allow accurate collection of information about current battlefield conditions as well as giving appropriate information to soldiers and vehicles in the battlefield. http://www.intel.com/pressroom/archive/rele ases/

7. 7 Sensor networks’ applications Traffic monitoring: installed along major highways, the digital sensor network gathers lane-by-lane data on travel speeds, lane occupancy, and vehicle counts. These basic data elements make it possible to calculate average speeds and travel times. http://www.mobilitytechnologies.com/ntdc/

8. 8 Sensor networks’ applications http://www.hardvision.ru/?dir=allabout&doc= sensors_net

9. 9 Security Threats Sensor node compromise Each node represents a potential point of attack, making it impractical to monitor and protect each individual sensor. Attackers can induce the network to accept them as legitimate nodes. Sensor networks need capabilities to ensure secure operation even in presence of small number malicious nodes.

10. 10 Security Threats Eavesdropping In wireless network, it's possible to access private information by monitoring transmissions between nodes. Possible Solutions:  End-to-end encryption – impractical due to nature of sensor node hardware.  Hop-by-hop encryption – adversary controlling a node eliminates encryption effectiveness for any communications directed through the compromised node.  Need for more robust routing protocols or multipath routing.

11. 11 Security Threats Privacy of sensed data Adversaries can use even seemingly innocuous data to derive sensitive information. Sensor networks aggravate the privacy problem because they make large volumes of information easily available through remote access. Prevention:  Data encryption.  Process queries in the sensor network in a distributed manner so that no single node can observe the query results in their entirety.

12. 12 Security Threats Denial-Of-Service Attacks Types of attack:  Radio jamming.  Transmitting useless communication in order to induce battery exhaustion.  Compromised node could create a routing loop that will eventually exhaust all nodes on the loop. Prevention:  Spread-spectrum communication or frequency hopping can counteract jamming attacks.  Authentication can prevent injected messages from being accepted by the network.  Authenticated routing.

13. 13 Security Threats Malicious use of sensor networks Criminals might want to use sensor networks for illegal purposes.  For example: Thieves can spread sensors on the grounds of a private home to detect the inhabitants’ presence. Prevention:  Sensor detectors is a possible defense against such attacks. Should be able to detect the presence of potentially hostile wireless communications within the area.

14. 14 SPINS Outline Introduction System Assumptions Requirements for Sensor Network Security Notation SPINS Security Building Blocks Evaluation Applications Questions and Comments

15. 15 Introduction The goal of this work is to propose a general security infrastructure that is applicable to a variety of sensor networks. SPINS Building Blocks:  μTESLA – authentication for data broadcast.  SNEP – data confidentiality, two-party data authentication, integrity and freshess. Also aims at:  Energy efficiency by minimizing communication.

16. 16 System Assumptions Before we outline the security requirements and present our security infrastructure, we need to define the system architecture and the trust requirements. Sensor Hardware Communication architecture. Trust requirements. Design guidelines.

17. 17 System Assumptions Sensor Hardware CPU: 8-bit, 4 MHz Storage:  8KB instructions flash.  512 bytes of RAM  512 bytes of EEPROM. Communication: 10 Kpbs Radio. Available code space: 4500 bytes. OS: TinyOS

18. 18 System Assumptions Communication Architecture Broadcast is the fundamental communication primitive. Network forms around one of more base stations. Nodes establish a routing forest with base station at the root of every tree. Routing topology is formed using periodic transmission of beacons. Each node can forward a packet towards a base station. Base station accesses individual nodes using source routing. Communication patterns  Node to base station (sensor readings).  Base station to node (specific requests).  Base station to all nodes (routing beacons, queries, reprogramming the entire network).

19. 19 System Assumptions Trust requirements We assume that individual sensors are untrusted. Design goal: compromise of a node doesn’t spread to other nodes. Compromise of base station can render the entire sensor network useless. Sensor nodes ultimately trust the base station. Each nodes shares a master key with the base station. We must assume that each nodes trusts itself. We trust local clock to be accurate (or have a small drift) (Note: necessary for μTESLA).

20. 20 System Assumptions Design Guidelines Sensor node hardware poses severe limitations: Because of limited computation resources we cannot afford asymmetric cryptography. Common stated between the parties is exploited to reduce communication overhead. Due to limited memory, all cryptographic primitives are constructed out of single block cipher. block cipher – a symmetric cipher which encrypts a message by breaking it down into blocks and encrypting each block.

21. 21 Security Requirements Data Confidentiality  Sensor network shouldn’t leak it’s readings to neighboring networks. Data Freshness  Must insure that each message is fresh.  Two-types of freshness: Weak – provides partial message ordering. Used for sensor measurements. Strong – provides total order on a request-response pair and allows delay estimation. Used for time synchronization within the network.

22. 22 Security Requirements Data Authentication  Allows the receiver to verify that the data really was sent by the claimed sender.  Possible solutions: Symmetric mechanism is not good for broadcast networks. Asymmetric mechanism is too computationally expensive.  Solution: asymmetry will be achieved using delayed key disclosure and one-way function key chains. Data Integrity  Is achieved through Data Authentication which is a stronger property.

23. 23 Notation A,B are principals, such as communicating nodes. N A is a nonce generated by A. X AB denotes the master secret (symmetric) key which is shared between A and B. X AB = X BA. K AB and K BA denote the secret encryption keys shared between A and B. A and B derive the encryption key from the master secret key X AB based on the direction of the communication: K AB = F X AB and K BA = F X AB, where F is a Pseudo-Random Function (PRF). K’ AB and K’ BA denote the secret MAC keys shared between A and B. A and B derive the encryption key from the master secret key X AB based on the direction of the communication: K’ AB = F X AB and K’ BA = F X AB, where F is a PRF.

24. 24 Notation {M} K AB is the encryption of message M with the encryption key K AB. MAC(K’ AB,M) denotes the computation of the message authentication code (MAC) of message M, with MAC key K’ AB. {M}( K AB,IV ) denotes the encryption of message M, with key K AB, and the initialization vector IV which is used in encryption modes such as cipher-block chaining (CBC).

25. 25 SPINS building blocks - SNEP Keys:  X AS is a key shared between base station and the node.  F K (x) = MAC(K, x) is a pseudo- random function. Counter C is incremented after each pseudo-random block we generate MAC(X rand,C).  This allows more code reuse.

26. 26 SPINS building blocks - SNEP SNEP Encryption All cryptographic primitives are implemented from one block cipher (RC5). Encryption function: We use (CRT) mode of block ciphers. CTR mode is a stream cipher. CTR requires a counter for operation:  Sender and receiver share the same counter. Base keeps counter for each node.  To resynchronize counters use SNEP with strong freshness. This ensures semantic security! Wikipedia

27. 27 SPINS building blocks - SNEP Message Authentication and integrity: MAC function: CBC-MAC will be used. In CBC (cipher block chaining) mode, each plaintext block is XORed with the previous ciphertext block before being encrypted. Same plaintext block can encrypt to different ciphertext blocks depending on its context in the overall message. Wikipedia

28. 28 SPINS building blocks - SNEP Message Authentication and integrity:  Assuming a message M, an encryption key K, and a MAC key K’, we use the following construction: {M} K,MAC(K’, {M} K ). It prevents the nodes from decrypting erroneous ciphertext, which is a potential security risk.  Since MAC is used to check both authentication and integrity of messages, it eliminates the need for mechanisms such as CRC.

29. 29 SPINS building blocks - SNEP Replay protection  Counter value in the MAC prevents replay of messages. Weak freshness  If the message verifies correctly, receiver knows that it must have been sent after the previous message it received correctly (that had a lower counter values). Low Communication Overhead  Counter state is kept at each end point.  Overall, add only 8 bytes per message.

30. 30 SPINS building blocks - SNEP Encrypted data format  The encrypted data has the following format: E = {D} (K,C), where D is the data, the encryption key is K, and the counter is C.  The MAC is M = MAC(K’,C||E).  The complete message that A sends to B is A→ B: {D} (K AB,C A ), MAC(K’ AB C A || {D} (K AB,C A ) ) (1) Strong freshness  If one needs strong freshness it can send a nonce. The following protocol should suffice (R A - request msg; R B - response msg): A→ B:N A, R A B →A:{R B } (K BA,C B ), MAC(K’ BA,N A || C B || {R B } (K BA,C B ) ). If MAC verifies correctly, A knows that B sent the response after A sent a request.  Note: 1 st message can be sent using SNEP (as in (1)) if confidentiality and authentication are required.

31. 31 SPINS building blocks - SNEP To bootstrap the counter values initially, we use the following protocol: A →B: C A B →A: C B, MAC(K’ BA C A || C B ) A →B: MAC(K’ AB,C A || C B ) Both parties use their counters as a nonce. If party A realizes that the counter C B of party B is not synchronized any more, we can use the following protocol: A →B: N A B →A: C B, MAC(K’ BA,N A || C B ). To prevent a potential denial-of-service (DoS) attack:  The nodes can switch to sending the counter with each encrypted message they send.  Attach another short MAC to the message that does not depend on the counter. Counter Exchange Protocol

32. 32 SPINS building blocks - μTESLA Why not TESLA:  Uses digital signatures.  Add overhead of ~24 bytes per packet. Standard sensor node messages are 30 bytes long.  One-way key chain does not fit into memory of sensor node. Instead μTESLA:  μTESLA uses only symmetric mechanisms.  μTESLA discloses key once per epoch. Instead of per packet.  μTESLA restricts number of authenticated senders.

33. 33 SPINS building blocks - μTESLA Sender setup: The sender first generates a a one-way key chain by successively applying a one-way function F: K j = F(K j+1 ). Broadcasting authenticated packets: Similar to TESLA, keys for time interval K i are revealed at interval (i + δ). Note: Key disclosure time delay should be greater than any reasonable round trip time between the sender and the receivers. Authenticating broadcast packets: Similar to TESLA.

34. 34 SPINS building blocks - μTESLA Bootstrapping a new receiver: Need to provide it with a key from key chain and synchronize time. A receiver R sends a nonce N R in the request message to the sender S. The sender S replies with a message containing its current time T S, a key K i of the one-way key chain used in a past interval i, the starting time T i of interval i, the duration T int of a time interval, and the disclosure delay δ: M →S: N M S →M: T S | K i | T i | T int | δ MAC(K MS,N M | T S | K i | T i | T int | δ). The MAC uses the secret key shared by the node and base station (X AS ) to authenticate the data. Here we use MAC instead of digital signature scheme as in TESLA.

35. 35 SPINS building blocks - μTESLA Node broadcasting authenticated data: Challenges:  Cannot store or compute key chain.  Broadcast of disclosed keys is expensive. Solutions:  Node broadcasts the data through the base station.  Node broadcasts the data. Base station supplies it with keys and broadcasts disclosed keys for other nodes. It also bootstraps new receivers.

36. 36 Evaluation Performance  The limiting factor is the amount of buffering. µTESLA is configured with 4 messages – disclosure interval dictates a buffer space for 3 messages plus we need an additional buffer to use this primitive in a more flexible way. Due to memory limitations, we cannot use a bigger buffer. Security Issues  SPINS does not deal completely with compromised nodes, merely insures that compromised sensor does not reveal the keys of all sensors in the network.  SPINS doesn’t deal with DoS attacks in the network.

37. 37 Evaluation Code size  Together crypto library and the protocol consume 2Kb. Energy costs – energy overhead:  If we accept routing beacons as necessary, than μTESLA key disclosure is nearly free. If one decides that routing beacons are not necessary than overhead of key disclosure will be one message per interval, regardless of the traffic on the network. 71%Data transmission 20%MAC transmission 7%Nonce transmission (freshness) 2%MAC and encryption computation

38. 38 Applications Authenticated routing – based on μTESLA  Possible approach: Check if we received beacon in the current epoch. If it’s a “new” beacon – mark originator as parent. Send new beacon with ID changed to itself. Routing depends on receipt of a beacon, not its contents.  Using μTESLA: We can use key disclosure packets as routing beacons. Reception of μTESLA packet guarantees that the packet originated at the base station and that its fresh. Makes it impossible for an attacker to reroute arbitrary links within sensor network. Combine transmission of key with network maintenance.

39. 39 Applications Node-to-node key agreement  Problem: resources are too limited for public key cryptography. Solution: use base station as a trusted agent for key setup.  Assume that the node A wants to establish a shared secret session key SK AB with node B. Since A and B do not share any secrets, they need to use a trusted third party S, which is the base station in our case. In our trust setup, both A and B share a master secret key with the base station, X AS and X BS respectively. The following protocol achieves secure key agreement as well as strong key freshness: A→ B: N A,A, B →S: N A,N B,A,B,MAC(K’ BS,N A |N B |A|B) S → A: {SK AB }K SA,MAC(K’ SA,N A |B|{SK AB } K SA ) S → B: {SK AB }K SB,MAC(K’ SB,N A |B|{SK AB } K SB )

40. 40 Applications Node-to-node key agreement  SNEP ensures confidentiality of established session key SK AB, as well as message authentication so we are sure that it was generated by the base station.  MAC in the 2 nd message helps to defend base station from DoS attacks, it sends two messages to A and B if it received legitimate request from one of the nodes.  Base station does most of the transmission work – save energy.

41. 41 Questions and Comments Thank You!