1 / 21

Local Data Protection for In-Network Processing in Sensor Networks

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 Department Dartmouth College Hanover, NH 03755. Aggregation in Sensor Networks. In-Network Processing.

hall
Download Presentation

Local Data Protection for In-Network Processing in Sensor Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 Department Dartmouth College Hanover, NH 03755

  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 • The seed key is escrowed and you forget about it. • Evolve the seed key to the second key which is in the sensor node • When you receive a query, then use the second key to encrypt the data in the sensor • Then, when you receive another query, you evolve the second key to the third key and you delete the second key • Thus: • Each new key can’t be used to decrypt the data encrypted with the old key. • 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.) • 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. • 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-distributionphase [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. • KAiSjdenotes the aggregation key shared between aggregator Ai and sensor node Sj. • Aggregation Key refreshmentphase (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.) • 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. • 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 Recovery In 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 decryption Key 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 Dito 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 key FS.upd: uses one-way fn to derive the next key from the current key Fs.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 • Shares seed key with all neighbors (Shamir). • Evolves to a new key, deletes the old key (Forward Secure Mechanism). 1. Sharing and updating seed key 2. Reconstructing 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 Nirof 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. A-node S-node Past Data Recovery Method II • Past data authentication 7/11/05, ICPS

  18. Security and Performance • Security: The probability of compromising a sensor nodegroup: • 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) 7/11/05, ICPS

More Related