Local Data Protection for In-Network Processing in Sensor Networks

Yi Ouyang, Zhengyi Le, James Ford and Fillia Makedon

The Dartmouth Experimental Visualization Laboratory

Computer Science DepartmentDartmouth College

Hanover, NH 03755

7/11/05, ICPS 2

Aggregation in Sensor Networks

7/11/05, ICPS 3

In-Network Processing Information is processed within the network, and only

the processed information is returned to the base station. This is called In-Network Processing or Aggregation.

Nodes collecting raw data from sensors (S-node) and then returning the aggregated results to base station are called Aggregators (A-node).

Example 1: Counting the number of nodes in a network of indeterminate size. A-nodes only return # of its children.

Base node adds up all intermediate results from A-nodes. Example 2: Computing the average temperature of the

area monitored by the network. The base station only gets one value from each of these

aggregators, and no longer knows a specific value of a single node.

7/11/05, ICPS 4

Problems: Past Event Queries & Storing History Data

Examples: At time t1, what is mean of the temperature from all sensors?

And later, at time t2, what is highest temperature of all sensors?

But at current time t3, what is highest temperature of all sensors at previous time t1?

Since the base station does not have history data, we must ask the sensor nodes again

=>to execute past event queries, we must store temporary local data in sensor nodes

=>designed a mechanism to protect this kind of temporary local data on sensor nodes

7/11/05, ICPS 5

Protecting Local Data How can we protect the locally stored data when an

s-node is physically compromised? If a sensor node is physically captured, then all the data

stored in this sensor node are compromised. If we encrypt the data with some keys but also store the

keys locally, then the adversary can get the keys and decrypt the local data.

=> we cannot store the encryption keys locally - send elsewhere =>a method to escrow the keys to another place and

only store the encrypted data locally. When the encrypted data needs to be decrypted, the sensor node gets

the decryption key from other parties. Every time you query a sensor node, it needs to encrypt the data

that it collected. Since sensor nodes also need the key at any time point, apply

forward security mechanism.

7/11/05, ICPS 6

Forward Security Mechanism Idea

1. The seed key is escrowed and you forget about it.2. Evolve the seed key to the second key which is in

the sensor node3. When you receive a query, then use the second key

to encrypt the data in the sensor4. Then, when you receive another query, you evolve

the second key to the third key and you delete the second key

n Thus:n Each new key can’t be used to decrypt the data

encrypted with the old key. n At any time point, a sensor node only stores a

current secret key and a bunch of data encrypted with previous keys which have been already deleted.

7/11/05, ICPS 7

Protecting Local Data (cont.)

1. Encrypt locally stored data With secret keys and a cryptography mechanism.

The key used to encrypt past data is not be stored locally. In our work: Secret keys are evolved by time periods.

An adversary can only get a current secret key, which is used to encrypt current data. It can’t decrypt a node’s past data with this key even if it captures this node physically.

2. Query past data securely A legitimate query from the base station should be able

to access (decrypt) the past data stored on sensor nodes.

We show how past data can be recovered securely from sensor nodes.

7/11/05, ICPS 8

Key Management for Local Data Encryption - Three Phases

Key pre-distribution phase [Perrig 02, Przydatek 03] : every sensor node and base station get a symmetric individual key The Base station has the Master key K and every sensor a unique id Every sensor node uses the secure keyed Message Authentication Code (MAC) function to get an Individual key MACK(IDNi)

Delegation of authorization and shared key establishment [Deng 03]: to maintain integrity and privacy during aggregation, the base station uses the sensor node individual key to encrypt the messages which are used to delegate the authorization

Base station creates and distributes new symmetric secret keys called aggregation keys shared between aggregators and their group sensor nodes.

KAiSj denotes the aggregation key shared between aggregator Ai and sensor node Sj.

Aggregation Key refreshment phase (our focus here) Aggregation keys periodically refreshed as application queries take place using forward secure key evolving

Store first key (Seed key) elsewhere; aggregation key evolves into a new key after every time it is used and local data are stored encrypted by this aggr. key

7/11/05, ICPS 9

Protecting Local Data (cont.)

1. Encrypt locally stored data With secret keys and a cryptography mechanism.

The key used to encrypt past data is not be stored locally. In our work: Secret keys are evolved by time periods.

An adversary can only get a current secret key, which is used to encrypt current data. It can’t decrypt a node’s past data with this key even if it captures this node physically.

2. Query past data securely for legitimate queries A legitimate query from the base station should be able

to access (decrypt) the past data stored on sensor nodes. When the encrypted data needs to be decrypted, the sensor

node gets the decrypt key from other parties We show how past data can be recovered securely from

sensor nodes.

7/11/05, ICPS 10

Past Data RecoveryIn the scheme described so far, it is difficult for a node to recover

past data, since every key is destroyed after it has expired - need seed key to get the specific key used at time t that data was encrypted!

Past data encryption and decryptionKey sharing: use secret sharing to divide the seed aggregation key among several sensor nodes, and reconstruct it when needed to retrieve the past data. (Shamir’s secret sharing to divide ag.key)

Key refreshment: periodically refresh the aggregation keys, which are used to encrypt past data. (Forward secure key evolving)

Key recovery- 2 methods: seed key can be reconstructed from the neighbors and then recover key

Either in sensor nodes Or in aggregators.

Past data authentication Authenticate the queried past data sent from S-nodes

7/11/05, ICPS 11

Key Sharing: Use Shamir’s Secret Sharing

Shamir’s secret sharing scheme can divide a secret into several pieces, and send them to different parties.

This scheme supports using a threshold as a parameter to determine at least how many pieces are needed to reconstruct the original secret. Assume the threshold is k.

Then pick a random k -1 degree polynomial p(x) = a0 + a1x + . . . + ak-1xk-1

Evaluate: D1 = p(1), . . . ,Di = p(i), . . . ,Dn = p(n) Send Di to the i th neighbor

Thus, K neighbors can solve this polynomial and get the coefficients of a0 to ak-1

When the node wants to restore its seed key, it will send requests to all of its neighbors and get responses from those neighbors who think it is uncompromised and secure.

7/11/05, ICPS 12

Key Refreshment: Use Forward Secure Key Evolving

(Used to refresh the secret key) FS = (FS.key, FS.enc, FS.dec, FS.upd, t)

Secret exposure

FS: fn to generate first symmetric keyFS.upd: uses one-way fn to derive the next key from the current keyFs.enc, FS.dec; used to encrypt/decrypt msgs with current secret key

7/11/05, ICPS 13

Past Data Recovery Method I

Past Data Encryption and Decryption: Key sharing & refreshment of S-nodes

1. Shares seed key with all neighbors (Shamir).

2. Evolves to a new key, deletes the old key (Forward Secure Mechanism).

2. Reconstructing seed key1. Sharing and updating seed key

7/11/05, ICPS 14

Past Data Recovery Method I

Past data authentication: If S compromised, may send false values to A

S-node

A-node

7/11/05, ICPS 15

Security and Performance

There are n nodes in the sensor network, and m nodes have been compromised. The probability that one node will be compromised is the probability that more than Nir of its neighbors have been compromised.

The increase in the number of messages due to past data queries:

So, the number of messages increased by queries on past data is related to the percentage of queries on past data and to the number of neighbors of every node has.

7/11/05, ICPS 16

Past Data Recovery Method II Key sharing and refreshment of an A-node

7/11/05, ICPS 17

Past Data Recovery Method II Past data authentication

A-nodeS-node

7/11/05, ICPS 18

Security and Performance

Security: The probability of compromising a sensor node group:

Method I:

Method II:

Performance: The sensor network has m A-nodes. The increase ratio of number of messages:

7/11/05, ICPS 19

Comparison

7/11/05, ICPS 20

Future work: comparing security with other schemes

Red: Q-composite

Purple: Our method 1

Blue: random subset assignment method

For the q-composite and random subset assignment key predistribution approaches, we use a key ring size of 200 and a probability of key-setup of 0.33. We can observe that(a) the higher the threshold, the lower the probability of a link being compromised and (b) if a suitable threshold is selected (e.g. r=5, ne=7), the security of our scheme is better than random subset assignment. In this scenario, the probability of a link being compromised increases more slowly in our scheme after more than 470 nodes have been compromised.

7/11/05, ICPS 21

Conclusion Distributed history-data storage- compared 2 methods

The history data are more securely stored locally on sensor nodes, which can distribute the burden of storing, instead of aggregators.

Designed forward-secure past data queries Even if an adversary compromises the aggregation key between a sensor node and its aggregator, it can only get the data transmitted during the current time period.

Method to authenticate the history data recovered with Forward-secure data authentication

An adversary can’t make up false data even it has physically captured a sensor node and acquired the current aggregation key.

Compared the trade-off results between communication cost and security (first method higher security but higher communication cost)

Comparison between two methods (sensor vs Aggr based)