0. 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

1. Aggregation in Sensor Networks
Sensor networks are used widely for many applications such as environments monitoring and real-time traffic analysis. Sensors begin to sense from the environment around and send sensed data back to base station after they are deployed into the designated area. In the old fashion way, every sensors sends its data back to base station via secure channel by using symmetric cryptography, however, this kind of method is very expensive in communication cost. Every sensor sends it own message, and the message goes all the way through many other sensors which are in the path from the sender to the base station. To conserve the energy, people introduce in-network aggregation in sensor networks. Some sensor nodes become aggregators. A aggregator collects data from sensor nodes which belong to its own group, process the data locally, and then send only the result back to base station. Base station collects all the data from aggregators and answers queries from upper applications.
7/11/05, ICPS

2. 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.
In in-network processing, only the processed information is returned to the base station, the base station no longer get data from any single sensor node. In this way, less data need to be transmit in the network and less energy consumed.
Examples:
Counting the number of nodes in a network. Every aggregator only return the number of its children. Base station sums the results from all aggregators.
Computing the average temperature of the area. Every aggregator gets the average value of temperatures of its children and return it to its parents such as base station. Base station only gets one value from each of these aggregators, and no longer knows a specific value of a single node.
So, for every query, the base station only gets a final result from the return values from aggregators, one of which is only one value. As a result, the base station no longer has a history record of the value of any nodes. If the application want to change the query on a past event, it doesn’t have the corresponding data.
7/11/05, ICPS

3. 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
But using In Network Processing we have a problem because the base station does not store the history data anymore- at any time it gets intermediate results from aggregators. It does not have the single value from any single node.
This is a problem if we want to query a history event - we cannot just locate the history record locally. We need to ask again. So, Where to store the history data is a problem
Ex At time t1 Later at t2
But at current time t3 if you want to know previous time t1, since the base station does not have hist data, must ask the sensor nodes again
So the sensor nodes need to store temporary local data for this kind of past event queries
In our paper we have designed a mechanism to protect this kind of temporary local data on sensor nodes.
7/11/05, ICPS

4. 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.
Because sensor nodes work in hostile env, it is possible that sensor nodes will be compromised physically by adversary
So how to protect the local stored data when s node is physically compro is a problem. We know that if an s-node is physically compromised, then all the data stored in the sensor node is compromised because it is physically captured.
And also if we encrypt the data by some keys and also store the key locally, then it is useless because the adversary can get the keys very easily and decrypt the local data. So we cannot store the encryption key locally.
When a sensor node is physically compromised by an adversary. All the encrypted data and keys are compromised. So if the key used to encrypt data is stored locally on sensor nodes, the encryption of data is useless. So we need a method to escrow the key to another place and only store the encrypted data locally.
When the encrypted data needs to be decrypted, the sensor node gets the decrypt key from other parties. Every time you query the sensor node, it needs to encrypt the data that it collected from the env. The sensor node also need to use the key at any time point, so our method is to use forward security mechanism.
The seed key is escrowed and you forget about it.
Evolve the seed key to the second key which is in the sensor node
And 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 to the third key and you delete the second key.
each new key can’t be used to decrypt the data encrypted with the old key.
Thus, 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

5. 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

6. 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.
When the encrypted data needs to be decrypted, the sensor node gets the decrypt key from other parties. Every time you query the sensor node, it needs to encrypt the data that it collected from the env. The sensor node also need to use the key at any time point, so our method is to use forward security mechanism.
The seed key is escrowed and you forget about it.
Evolve the seed key to the second key which is in the sensor node
And when you receive a query node, then use the second key to encrypt the data in the sensor
Then, when you receive another query, you evolve the second to the third key and you delete the second key.
each new key can’t be used to decrypt the data encrypted with the old key.
Thus, 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. 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
Now, for the encryption, step one in previous slide, we must use some Key Manag. Schemes.
The key management is divided into three phases
For the first two phases we use other researchers workIn the key pre-distribution phase, every sensor node and base station create a symmetric key. This key is for secure communication between individual node and base station. It is used to encrypt the messages in second phase. In other words, it is used for secret keys bootstrapping.
In the delegation phase, base station use sensor nodes’ individual keys to encrypt messages for delegation of authorization, which includes a symmetric key generated by base station for aggregation between individual sensor nodes and aggregators. Base station encrypts the aggregation key using an A-node’s secret key and an S-node’s secret key and sends them to this A-node and S-node respectively. In this way this A-node and S-node can construct an aggregation relation.
In the key refreshment phase, we use forward secure key evolving to refresh the aggregation keys periodically. For an A-node and an S-node, both of them will refresh their keys periodically. So at the same time, their keys are the same. The key can be refreshed as every query happens or every fixed time period.
7/11/05, ICPS

8. 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.
When the encrypted data needs to be decrypted, the sensor node gets the decrypt key from other parties. Every time you query the sensor node, it needs to encrypt the data that it collected from the env. The sensor node also need to use the key at any time point, so our method is to use forward security mechanism.
The seed key is escrowed and you forget about it.
Evolve the seed key to the second key which is in the sensor node
And when you receive a query node, then use the second key to encrypt the data in the sensor
Then, when you receive another query, you evolve the second to the third key and you delete the second key.
each new key can’t be used to decrypt the data encrypted with the old key.
Thus, 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

9. Past Data Recovery Past data encryption and decryption
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
For the second part, which is past data recovery, FOR LEGITIMATE DATA QUERY
Now, in the scheme described so far, it is difficult for a node to recover past data, since every key is destroyed after it is expired. When a node attempts to access its history data, it needs the specific key used att the time the data was encrypted. Because the keys are forward secure, it is theoretically impossible to restore the previous keys from the current key. Therefore, the node needs to know the first key, called the seed key, to which it can then apply the appropriate updates to obrain the key used to encrypt the history data
Therefore, the node needs to know the seed key.
Since the seed key cannot be stored locally in the node because of the node capture problem, since the adversary can use the seed key to generate all the secret keys, the seed key cannot be stored at the base and the aggregator nodes for similar reasons.
The straightforward method of storing the seed key is to store it on a trusted third party sensor node. However, this sensor node may become a bottleneck or a central point of failure in the whole system.
A more secure scheme without a central third party is preferable.
SECRET SHARING OF THE SEED KEY CAN BE USED
TWO METHODS WE PROPOSE: THEY USE SECRET SHARING TO DIVIDE THE SEED KEY AMONG SEVERAL SENSOR NODES BUT RECONSTRUCT IT IN DIFFERENT PLACES, INCLUDING SENSOR DODES AND AGGREGATORS.
WE DISCUSS THESE TWO METHODS AND COMPARE SECURITY AND PERFORMANCE.
7/11/05, ICPS

10. 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.
It is a threshold secret sharing
So if we want to share a secret among n parties and we want to let k of them reconstruct this secret, we pick a random k-1 degree polynomial
And a0 is the secret we want to share
Now we evaluate d1=p1 and dn=pn and then send di to ith neighbor
K of them can solve this polynomial and get the coefficients of a0 to ak-1
Because a0 is the secret we want to share, so k of them can get the secret
We use to share and reconstruct the seed key.
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. If the threshold is k, then randomly pick a k-1 degree polynomial. So using k different values can solve this k-1 degree polynomial and get a_0. “a_0” is the secret needs to be divided.
We use Shamir’s secret sharing method in this scheme. One node divides its seed key into Nne shares and sends them to its Nne neighbors. In this scheme, k of its
Nne neighbors together can restore the seed key. When the node wants to restore its seed key, it will send requests to all of its neighbors and get responses fromthose neighbors who think it is uncompromised and secure.
Note: How to judge whether a node is compromised is outside the scope of this work
7/11/05, ICPS

11. 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
We use to refresh the secret key periodically
Forward security mechanism can be described as this function.
Advantages: if a key is evolved, adver cannot use current key to get previous key - like hashing fn
But if you have the first key, then you can reconstruct every key you evolved.
In our mechanism, we first share the seed key to the other neighbors and then we delete the local key
And then we evolve this key time by time and if at any time the adver get the current key, it cannot get the previous key So it cannot decr\ypt local data
If legitimate user, can reconstruct the seed key and then use the seed key to recons all previous keys.
FS.key is the function to generate the first symmetric secret key. In every period out of t total time periods, a new secret key is used for encryption and decryption. At the end of every period, FS.upd uses a one-way function to derive the next key from the current key and in the process overwrite the current key. FS.enc and FS.dec are used to encrypt and decrypt messages with the current secret key. The total number of time periods is t. The appropriate interval for key refreshment is application specific.
The advantage of forward security is that if the adversary compromises the secret key at some point, it can’t deduce the previous used key for previous time periods by using this compromised secret key. But it can deduce the following keys used in later period. So if the legitimate user want to decrypt the message encrypted with previous keys, it needs to evolve the first seed key to the time period when the data was encrypted. So forward security can guarantee the security of time before the exposure, but can’t protect the security of time after the 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

12. 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).
Now we introduce the 2 methods used for past data recovery
The difference between method I and method II is mainly on the place where we share and reconstruct the secret key needed to decrypt the past data.
Method I is on S-nodes, method II is on A-nodes.
For the first method, First we share the secret key with the sensor neighbors, then evolve the current key to a new key and delete the old key. For this sharing, an S-node, first it uses shamir’s secret sharing scheme to share its aggregation key to all of its neighbors.
And then the sensor nodes repeat the update function of the forward secure mechanism and every time destroy old key and evolve to a new key.
And when we want to reconstruct the seed key, the sensor nodes send a message to all the neighbors and every neighbor, after it receives the message, they send back a response based on whether they think this node is compromised or not.
And then if the sensor node can collect enough messages to reconstruct the seed key, it reconstructs the seed key and can decrypt the local history data and send to the aggregator again.
===
Then for the first time period, it uses this key to encrypt data and store them locally. After the usage of this current key, in the second period, this S-node evolves this key. Then this S-node no longer possesses the previous key, and it can’t decrypt the data it encrypted in the last period. And after its new key are used, this S-node evolves it again. Then again and again.
1. Sharing and updating seed key
2. Reconstructing seed key
7/11/05, ICPS

13. Past Data Recovery Method I
Past data authentication: If S compromised, may send false values to A
S-node
A-node
And authentication for the past data for this method
Suppose tj is the time point before ti.
Suppose that at time tj, the S-node sensed data Mtj, encrypted it with the current key and sent it to A-node.
Then the A-node decrypts the message into the original message mtj, and uses the MAC function to get the hash value of the message and store this hash value locally. and then deletes the message.
Because this hash value is very small it will not cost them much memory in aggregator. Then this hash value can be used to authenticate the data sent by the sensor node later.
So at time ti, which is the time later than tj, we need to get the local history data at tj.
So the S-node first reconstructs the seed key
and then evolves this key to the Dktj
and then we use this key to decrypt the data to get the message.
And the sensor node uses the key to get the hash value for this message and then send this hash value and the messge again to the aggregator.
So the aggregator now can compare the new hash value to the old hash value.
If they are equal, then this message is true, if not, this message is false.
If the S-node is compromised, it may send the false value to the A-node.
In our scheme, if the compromised S-node doesn’t have the key for tj, then it can’t decrypt the data, so it can’t fool the A-node. If the compromised S-node does have the key for tj, it can’t generate the correct the same hash value of different message. So it still can’t fool the A-node. In this way, A-node can authenticate whether the past data is correct.
-----
received a query on past data tj, it then asked its neighbors for key shares. After its neighbors sent back the key shares, it reconstruct the seed key and evolve it to time point tj, then use this key to decrypt the local stored data Ctj. Then it use this key to hash the message, send the original (data at time tj) message along with the hash value encrypted with current secret key Kti to the A-node. A-node compare the hash value it stored locally with the hash value received from the S-node to decide whether the S-node is fraud.
7/11/05, ICPS

14. 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:
To analyze the security and performance of this first method, we consider the probability of one node being compromised because we consider the prob of one link bet s and A being com.
Suppose there are n nodes in the sensor network, and m nodes have been compromised. The probability that one
Node being compromised is the prob that more than the threshold of its neighbors have been compromised.
So here the threshold is NIR and then the prob should be this formula
If j is the current number of current compromised neighbors, and we choose j from the number of all compromised neighbors timesm over n is the prob of one node being compromised and j of them are compromised and one minus m over n is the probability of one node not being compromised and there are N the number of neighbor nodes minus j nodes are not being compromised. So this formula is the prob that more than nir neighbors have been compromised.
So this is the prob of the security of one link bet one s node and the ag, which is the security of the aggreg key, is compromised.
So for the increase ratio of the number of messages, we use beta to denote the increased ratio.
Nn is the number of messages queries on past data minus No which is the number of original messages needed without queries on past data over the no
Let k be the number of queires
Alpha is the number queries which attempt to access past data or “a” is the percentage of past data queries.
So the result is that the number of messages is related to the percentage of the past data queries -If we have high percentage of past data queries, then the number of messages will be higher.
and also it is related on the number of neighbors every node has. If every node has many neighbors, then the messages we need to reconstruct the key will be higher.
k(1-a)M is the number of messages for those normal queries. For Node Ni, the number of messages needed to restore
the seed key from pieces held by neighbors is Nine +Nirep.
So, the number of messages increased by queries on past data is related to the number of neighbors of every nodes and the ratio of queries on past data.
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

15. Past Data Recovery Method II
Key sharing and refreshment of an A-node
Inmethod 1, the recoveryd of past daya occurs on s nodes. Drawback: dramatic increase in no of msgs required based on no of queries.
Alternate method designed to reduce no of mmsgs.
In method II, the difference is that we recover data (share the key and reconstruct the key) on aggregators.
Since number of aggregators is much less than the number of sensor nodes, the number of messages we need for the key sharing is much less.
So the process is same:
The Aggr first share key with its neighbors, maybe other aggr or sensor nodes and then the aggregators refresh the key locally. Still use the same shamir’s secret sharing scheme to share the seed key and send key shares to this A-node’s neighbors.
When the past event query happens, the A-node asks its neighbors for the key shares to reconstruct its seed key and decrypt the data received from S-nodes.
To recover the secret key, the agg sends a message to all its neighbors and the neighbors will respond with their share. And if agg can collect enough share from its neighbor, can reconstruct the key
Because normally the number of A-nodes is much less than the number of S-nodes. Reconstructing aggregation keys on A-nodes can decrease the number of messages used in sharing keys and reconstructing keys.
However, an A-node is more important then an S-node, because an A-node manage a group of S-nodes. So if an A-node is compromised means a group of S-nodes are compromised as well.
7/11/05, ICPS

16. Past Data Recovery Method II
Past data authentication
A-node
S-node
So because the location of the reconstr of the key, the method of past data auth is different
At tj, the sensor node sends encrypted message to aggreg node.
At time tj, the A-node does the same thing as in method I, it decrypts the message, keyed-hashes the message to get its hash value, stores the hash value for future authentication, deletes the message, and evolves the secret key.
At time ti, S-node receives the past event query for time tjjj, just sends the local stored past data to A-node.
At time ti, the agg node wants the history data at time tj
And this time the sensor nodes just send the local encrypted data for time tj to agg
Then agg gets the encrypted data at time tj first and then reconstruct the key and use the key for time tj to decrypt again to get the plain text of data at time tj
And then the aggregator uses the hash fun to get a new hash value of this messge and compare new with old ha\sh value to determ if method is true or falsh.
Because the previous key is reconstructed in a different place, so the past data authentication method should be changed correspondingly.
Because the key is reconstructed on A-nodes, the S-nodes no longer need to worry about reconstructing the key and decrypting messages.
At time tj, the A-node does the same thing as in method I, it decrypts the message, keyed-hashes the message, stores the hash value for future authentication, deletes the message, and evolves the secret key.
At time ti, S-node receives the past event query, just sends the local stored past data to A-node.
A-node reconstructs the key, decrypts the data, gets the message, keyed-hashes the message, and compares the hash value to its own copy of hash value to determine whether the S-node is fraud.
If the S-node is compromised. It may send false data. It doesn’t have the correct key, so the data can’t be decrypt to correct message. Even if the S-node has the key, the message’s hash value can’t match the copy of A-node’s. So a compromised S-node can’t fool the A-node.
7/11/05, ICPS

17. 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:
When all the past data are restored on A-nodes, the seed keys shared by an A-node and its group members are shared among the A-node’s neighbors.
As a result, if enough of these neighbors are compromised, those seed keys will be compromised.
In method I, because all the seed keys are shared among each S-nodes’ neighbors, the compromise of neighbors of an S-node will only compromise the S-node itself. Thus, it is clear that the security of method II is not as rigorous as method I.
In method II, an entire group of S-nodes working with the same A-node can be compromised at the same time.
Performance:
In method II, because all the S-nodes don’t need to recover past data locally, they don’t need to send messages to their neighbors—only the A-nodes need to do so.
In method II, queries on past data are always distributed to a group of S-nodes simultaneously. Therefore, when an A-node requests all the seed keys from its neighbors, it can combine all the requests for different seed keys into one request, and a neighbor can respond with only one message that includes all the key shares it has.
Compared to method I, the extra messages are only among A-nodes and their neighbors, not among all the S-nodes and their neighbors. m<<n
7/11/05, ICPS

18. Comparison
Figure 2 is a comparison between these two methods. In Figure 2, we can observe that the probability of one group being compromised will decrease dramatically in method I when the number of sensor nodes in each group increases.
Here “r=2, ne=7” means that in secret key sharing, the threshold is 2 and the number of neighbors is 7. We consider three example combinations of these two parameters in this paper. LDP (Local Data Protection) I denotes method I from Section 4. LDP II denotes method II from this section. In method II, the probability of an A-node’s group being compromised is related to the number of this A-node’s neighbors instead of the number of its group members. Thus, when the size of an A-node’s group of sensor nodes is large, method I will provide better security. If all the sensor nodes in one group share the same neighbors in method I, then the probabilities of one group being compromised in the two methods are equal.
Fig.3 shows the probability of one link being compromised versus the number of compromised nodes for a network of 1,000 sensor nodes.
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.
From Figure 3, we can observe that the higher the threshold, the lower the probability of a link being compromised. We also can observe that 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

19. Future work: comparing security with other schemes
Red: Q-composite
Purple: Our method 1
Blue: random subset assignment method
Red is the q composite method
Purple our number one method
Blue the rs method
Fig.3 shows the probability of one link being compromised versus the number of compromised nodes for a network of 1,000 sensor nodes.
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.
From Figure 3, we can observe that the higher the threshold, the lower the probability of a link being compromised. We also can observe that 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.
Red is another system and blue is another system
Purple is our number one system
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 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

20. 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)
In this work we have distributed history-data storage
7/11/05, ICPS