1

Sensor Networks

Security and Privacy in Sensor NetworksHaowen Chan and Adrian Perrig

SPINSAdrian Perrig, Robert Szewczyk, J.D. Tygar, Victor Wen and David E. Culler

Denis Golosov & Evgenya Borisenko

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

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

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

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

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/releases/

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

Sensor networks’ applications

http://www.hardvision.ru/?dir=allabout&doc=sensors_net

9

Security ThreatsSensor 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

Security ThreatsEavesdropping

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

Security ThreatsPrivacy 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

Security ThreatsDenial-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

Security ThreatsMalicious 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

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

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

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

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

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

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

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

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

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

Notation A,B are principals, such as communicating nodes. NA is a nonce generated by A.

XAB denotes the master secret (symmetric) key which is shared between A and B. XAB = XBA.

KAB and KBA denote the secret encryption keys shared between A and B. A and B derive the encryption key from the master secret key XAB based on the direction of the communication: KAB = FXAB and KBA = FXAB, 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 XAB based on the direction of the communication: K’AB = FXAB and K’BA = FXAB, where F is a PRF.

24

Notation {M}KAB is the encryption of message M with the encryption key KAB.

MAC(K’AB,M) denotes the computation of the message authentication code (MAC) of message M, with MAC key K’AB.

{M}(KAB,IV) denotes the encryption of message M, with key KAB, and the initialization vector IV which is used in encryption modes such as cipher-block chaining (CBC).

25

SPINS building blocks - SNEPKeys: XAS is a key shared between base

station and the node.

FK(x) = MAC(K, x) is a pseudo-random function. Counter C is incremented after each pseudo-random block we generate MAC(Xrand,C).

This allows more code reuse.

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

SPINS building blocks - SNEPMessage 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

SPINS building blocks - SNEPMessage 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

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

SPINS building blocks - SNEPEncrypted 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}(KAB,CA), MAC(K’ABCA || {D} (KAB,CA)) (1)

Strong freshness If one needs strong freshness it can send a nonce. The following

protocol should suffice (RA - request msg; RB - response msg):A→ B: NA, RA

B →A: {RB}(KBA,CB), MAC(K’BA,NA || CB || {RB}(KBA,CB)).If MAC verifies correctly, A knows that B sent the response after A sent a request.

Note: 1st message can be sent using SNEP (as in (1)) if confidentiality and authentication are required.

31

SPINS building blocks - SNEP

To bootstrap the counter values initially, we use the following protocol:A →B: CA

B →A: CB, MAC(K’BACA || CB)A →B: MAC(K’AB,CA || CB) Both parties use their counters as a nonce.

If party A realizes that the counter CB of party B is not synchronized any more, we can use the following protocol:A →B: NA

B →A: CB, MAC(K’BA,NA || CB).

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

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

SPINS building blocks - μTESLA Sender setup:

The sender first generates a a one-way key chain by successively

applying a one-way function F: Kj = F(Kj+1).

Broadcasting authenticated packets:Similar to TESLA, keys for time interval Ki 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

SPINS building blocks - μTESLABootstrapping a new receiver:

Need to provide it with a key from key chain and synchronize time.

A receiver R sends a nonce NR in the request message to the sender S. The sender S replies with a message containing its current time TS, a key Ki of the one-way key chain used in a past interval i, the starting time Ti of interval i, the duration Tint of a time interval, and the disclosure delay δ:M →S: NM

S →M: TS | Ki | Ti | Tint | δ MAC(KMS,NM | TS | Ki | Ti | Tint | δ).

The MAC uses the secret key shared by the node and base station (XAS) to authenticate the data. Here we use MAC instead of digital signature scheme as in TESLA.

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

EvaluationPerformance

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

EvaluationCode 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

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

ApplicationsNode-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 SKAB 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, XAS and XBS respectively. The following protocol achieves secure key agreement as well as strong key freshness:

A→ B: NA,A,

B →S: NA,NB,A,B,MAC(K’BS,NA|NB|A|B)

S → A: {SKAB}KSA,MAC(K’SA,NA|B|{SKAB}KSA)

S → B: {SKAB}KSB,MAC(K’SB,NA|B|{SKAB}KSB)

40

ApplicationsNode-to-node key agreement

SNEP ensures confidentiality of established session key SKAB, as well as message authentication so we are sure that it was generated by the base station.

MAC in the 2nd 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

Questions and Comments

Thank You!