3. Proposed scheme
3.1. Key Establishment Phase
3.1.2. Establishing Pairwise Shared Keys
Each node i can derives a master key as follows:
K f (i )
KI
i
=
.When each node i is deployed, it broadcast a HELLO message with nonce, and waits for Tmin which is the minimum time that an adversary needs to compromise a node. Each neighbor node j of node i who gets the HELLO message replies its node identity with message authentication code (MAC). Figure 3-1 demonstrates how HELLO message and reply message works.
: broadcast
i → i, Nonce
i: i
j → j , Nonce
j, MAC
K( Nonce
i, j , Nonce
j)
j
Figure 3-1: HELLO message and reply message
Since node i can compute Kj fromK , it is able to verify the reply message I sent by node j.
When node i have verified the identity of its neighbor node j, it computes pairwise shared key Kij with node j as follows:
K f (i )
Kj
ij
=
. Node j can also compute Kij independently.After generating the pairwise shared key with all its neighbor node j, it delete K and all the keysI Kj. So no other nodes can compute the pairwise shared key Kij anymore.
Since we each two neighbor nodes share a pairwise shared key, we make preparation for secure communication by this key. As point out in SPINS, a good security design is not to reuse the same cryptography key for different cryptography primitives; this prevents any potential interaction between the primitives that might
introduce a weakness. So we derive independent keys for our encryption and MAC operation from pairwise shared key as follows:
( 1 )
Kij transmission between each node i to base station. We still need two counters shared by the parties (one of each direction of communication) for the block cipher in counter mode. Since the counter values are not secret, we set these two counters as follows:
i i
Nonce
C =
,C
j= Nonce
jwhere Nonce and i Noncej just used before.3.2. Initialization Phase
Step1. Initially, each sensor node set its hop count to “infinite”
Step2. In the beginning, base station broadcast a hop count message with data
“Hop count=0”
Step3. When a node receives a hop count message, it compares its hop count value to that in hop count message. If hop count value x in the message is smaller than hop count value minus 1, then sets its hop count value to (x+1)
Step4. If hop count value is changed to y in step3, then the node broadcast a hop count message with data “Hop count=y”
At last, each node is aware of its minimum hop count to base station, and knows the hop count of all its neighbors. So, it is able to construct Farer
3.3. Bottleneck Node Finding Mechanism
Step1. First of all, every node contains one variable (Load Count (Li)) and two metrics (Farer Neighbor Metric, Lower Neighbor Metric). Initially, each node set its Load Count (Li) according to its data generating rate, and in Farer Neighbor Metric, it sets Path Load Count to 0 and sets IsBalanceable to False for those nodes that hop count number is grater than current node. In Lower Neighbor Metric, each column is set to be (Number of Lower Nodes
Li
_ _
_ ) which represents the Arrange Load of those nodes that hop count number is lower than current node. Figure 3-2 demonstrates variables maintained in a node, and figure 3-3 shows a Farer Neighbor Metric, and figure 3-4 shows a Lower Neighbor Metric.
Current ID Load Count
55 2 Figure 3-2: Node variable
Neighbor ID Path Load Count IsBalanceable
6 0 False 285 0 False
60 0 False Figure 3-3: Farer Neighbor Metric
Neighbor ID Arrange Load
57 1 74 1 Figure 3-4: Lower Neighbor Metric
Step2. Every node that has no farer neighbor is the starting point in this step.
When node i is going to send a message through node j where node j are lower neighbors of node i, it computes Path Load Count with
)
(Li•Pij and adds Route Path, Path Load Count, Max Load Count, and Max Load Node ID to the message, where Max Load Count is set to Load Count of node i (Li), and Max Load Node ID is set to node ID of node i. IsBalanceable is set true if current node has more than one lower neighbors, otherwise set false.
When route message (RM) is ready, then it is sent in secure manner as showed below.
Route Path Path Load Count
Max Load Count Max Load Node ID IsBalanceable Figure 3-5: Format of an Route Message (RM)
:
Figure 3-6: Secure transmission of Route Message
Step3. In this step, every intermediate node must receive all the route messages
intermediate node j, it gets the Path Load Count value within the message, and updates the value in its Farer Neighbor Metric. If Farer Neighbor Metric changes, node j has to recount its Load Count which is the summation of all Path Load Count in Farer Neighbor Metric
( =
∑
Count is grater than Max Load Count in route message, then changes Max Load Count and Max Load Node ID to current node. If IsBalanceable is false and current node has more than one lower neighbor, then change it to true. At last, node j adds its node ID to Route Path and changes Path Load Count to (Lj•Pjk)where k is all of its lower neighbors and then sends this message to node k.
Also, the route message is sent in secure manner as showed below.
:
Figure 3-7: Secure transmission on intermediate node
Step4. In this step, base station will get all routes, and every route contains a bottleneck node which has the maximum load on this route. So when a route message reaches base station, base station saves the Max Load Count, Max Load Node ID and Route Path to Bottleneck List which stored at base station.
BTNK ID Load Route Path
Figure 3-8: Bottleneck List
After this phase, base station knows the overall load of the whole network and those nodes that are most heavy loaded in each routing. Our goal is to balance the load of bottleneck node in order to make the energy usage of these nodes to be equal.
3.4. Load Balance Propagation Phase
Step1. Base station counts expected load of each bottleneck node followed by
this formulation: ⎟⎟
expected load to each bottleneck node by piggybacking.
Step2. When a bottleneck node is informed by base station with expected load, it compares its current load to the expected load, if current load is larger than expected load, then progresses Step3. If current load is smaller than expected load, then progresses Step4. Otherwise this node is load balanced.
Step3. In this step, because load of current node is heavier than expected load,
we need to reduce the load of this node. We inform the farer neighbors whose IsBalanceable flag is true by Reduce Message. Reduce Value in the Reduce Message is set according to the percentage of its load in Farer Neighbor Metric followed by formulation:
i =
where Nodej are nodes with IsBalanceable flag is true in Farer Neighbor Metric.
Reduce Message is sent to next node with secure encryption protocol just like showed below.
Node ID:10 Load: 60 Expected Load: 50 Neighbor ID Path Load Count IsBalanceable
6 10 False
285 20 True
60 30 True
Figure 3-9: Node variables and Far Neighbor Metric
Node ID:10 Neighbor ID:285 Reduce Value:4 Figure 3-10: Reduce Message to Neighbor 285
Node ID:10 Neighbor ID:60 Reduce Value:6 Figure 3-11: Reduce Message to Neighbor 60
: j
i → E
KijE,Ci{ RM }, MAC
KijMAC( C
i, E
KijE,Ci{ RM })
Figure 3-12 Secure transmission of reduce message
Step4. In this step, because load of current node is lighter than expected load, we want to increase the load of this node. We inform the farer neighbors whose IsBalanceable flag is true by Increase Message. Increase Value in the Increase Message is set according to the percentage of its load in Farer Neighbor Metric followed by formulation:
i =
where Nodej are nodes with IsBalanceable flag is true in Farer Neighbor Metric.
The same, Increase Message is sent to next node with secure encryption protocol just like showed below.
Node ID:10 Load: 60 Expected Load: 70 Neighbor ID Path Load Count IsBalanceable
6 10 False
285 20 True
60 30 True
Figure 3-13: Node variables and Far Neighbor Metric
Node ID:10 Neighbor ID:285 Increase Value:6 Figure 3-14: Increase Message(IM) to Neighbor 285
Node ID:10 Neighbor ID:60 Increase Value:4 Figure 3-15: Increase Message(IM) to Neighbor 60
: j
i → E
KijE,Ci{ IM }, MAC
KijMAC( C
i, E
KijE,Ci{ IM })
Figure 3-16: Secure transmission of reduce message
Step5. Every node that receives Reduce Message and Increase Message is able to balance load of lower neighbors. Node can change Arrange Load according to Reduce Value and Increase Value in the messages. Once sum of Reduce Value and sum of Increase Value are not equal, the node needs to send Reduce Message or Increase Message just like what we have done in step3 and step4, otherwise load balance is done.
Step6. Once load balancing message (Reduce Message and Increase Message) can not be able to propagate anymore, we can restart doing bottleneck finding mechanism for more balanced network or just stop to save the energy cost when applying these mechanisms according to the balance level that user wants.
3.5. Secure Data Transmission Phase
After bottleneck finding mechanism and load balance propagation phase is
purpose of balancing energy consumption of whole network. In this phase, if a node generates a message to base station, it chooses its next hop node according to the probability of Arrange Load. Probability of each lower neighbor being choose is addressed by the following formulation:
= ∑
where i is current node and k is each node in Lower Neighbor Metric of node i When next hop is chosen by the probability, then the message M it wants to send to base station will be transmitted through secure encryption protocol. We will show the secure encryption protocol below.
Neighbor ID Arrange Load 56 10 55 15 54 25
Figure 3-17: Load in Lower Neighbor Metric
56
Figure 3-18: Probability of choosing next hop
Message M with data D is going to send to base station by node i through node j:
: j
i → { }, ( , { })
,
,
M MAC C E M
E
i E ij MAC
ij i
E
ij C K i K C
K
where
:
M E
K{ D , Nonce
i}, MAC
K( E
KmE{ D , Nonce
i})
i mMAC
i mE
i
4. Evaluation
In this section, we use some different kinds of network as our experimentation environment. We will make some evaluations to show the total time of overall network connectivity of proposed scheme under different network conditions. For comparison, we choose some different kinds of secure routing schemes that trying to find minimum energy cost paths and an energy aware routing scheme without security transmission. As point out in [25], performance of AODV is similar to that of DSR, but AODV has more expensive routing overhead than DSR, so we cast aside AODV based secure routing for comparison. For secure routing scheme, SEAD is selected to be compared because of its DSDV routing based property and another chosen scheme is Ariadne which is based on DSR. For traditional routing scheme, we also compare to Energy Aware Routing [16] proposed by Rahul et al which is going to balance energy usage when selecting next hop.
4.1. Simulation Setup
We implement SEAD, Ariadne, Energy Aware Routing, and Energy-Balancing Secure Routing using Wireless Sensor Network Simulator, which is a JAVA based simulator. According to the spec of Crossbow MICAz [26], power consumption of radio-frequency transceiver and micro-controller computation are listed in Table 4.1.1.
According to the spec of TinyOS , the embedded operating system used on Micaz, we set a data message packet to be 30 bytes. Since the size of encrypted message is the same as the size of the plaintext, there is no packet overhead within encrypting operation. MAC operation adds 8 bytes to a message, but MAC gives up integrity
guarantees, so we don’t need extra 2 bytes of CRC. Thus, there is only 6 bytes packet overhead in MAC operation. We set nonce to be 2 bytes for a large enough value range. Table 4.1.2 shows packet overhead used in proposed scheme.
Component Energy Dissipation
Processor in Active Mode 24 mW
Processor in Sleep Mode 5 μW
Transceiver in Receive Mode 59.1 mW Transceiver in Transmit Mode 52.2 mW
Transceiver in Idle Mode 60 μW
Transceiver in Sleep Mode 3 μW
Table 4.1.1
Security operation/ component Packet overhead Symmetric-Key Encryption 0 bytes Message Authentication Code 6 bytes
Nonce 2 bytes
Table 4.1.2
MICAz uses two AA batteries for power supply. If we put two 1.5V 2000mAh AA batteries on MICAz, then the total energy of a MICAz node is2.16×104J. So initially, we put 500 sensor nodes in a 700m x 700m square filed with base station settled at the central of the field, and each node carries 2.16×104J energy.
Deployment of sensor nodes follows normal distribution with mean value set at base station and standard deviation is set 140. The communication range of each node is 70
meter.
4.2. Evaluation on normally distributed network
In this sub-section, we are going to evaluate the performance in the network which the node deployment is followed by normal distribution.
0 20000 40000 60000 80000 100000 120000 140000 160000 180000 200000
1
Total Routing Iteration Ariadne
SEAD
Energy Aware Routing
Energy-Balancing Secure Routing
Figure 4-1: Evaluation on initial conditions
Figure 4-1 shows the evaluation result on initial conditions. We from the result, we can see that the network lifetime of Energy-Balancing Secure Routing is about 4 times than that of Ariadne, and is about 2 to 3 times than that of SEAD. The comparison between Energy-Balancing Secure Routing and Energy Aware Routing is shown that the proposed scheme increases network lifetime about 10 to 20 percent.
0
Total Number of 1-Hop Node
Total Routing Iteration
Figure 4-2: Evaluation on different number of 1-hop node
We evaluate the performance when the number of 1-hop nodes increase. Here, 1-hop nodes means for the nodes with its minimum hop count to base station is 1, on the other hand, these are the nodes that are neighbors of base station. Figure 4-2 shows that when the number of 1-hop node increase, the proposed scheme can enlarge more total network lifetime. That’s because in the proposed scheme, the more 1-hop node we have, the more node we can perform energy balance propagation.
0
10000 20000 30000 40000 50000 Initial Energy Capacity
Figure 4-3 shows the evaluation result when the initial energy capacity is different. We observe that as the initial energy capacity increase, the enhancement of total network lifetime is more significant. That’s because the more energy that each node have, the more energy can be balanced. Although the present energy capacity of a MICAz node is about 30000 units in this figure, the evolution of sensor node will be design for larger energy capacity of a node. The propose scheme may be more flexible when the design of sensor node to be with more energy capacity.
0 50000 100000 150000 200000 250000 300000 350000
100 200 300 400 500 600 700 800 9001000
Total number of nodes
Ariadne
SEAD
Energy Aware Routing
Energy-Balancing Secure Routing
Figure 5: Evaluation on total number of nodes
Figure 4-4 illustrates the performance for a variable number of nodes. The results show that the total network lifetime significantly increases as the total number of nodes increase. Thus, our proposed scheme performs well in large scale networks.
Since real world applications utilizing wireless sensor networks may employ thousands of sensor nodes, the evaluation demonstrates that Energy-Balancing Secure Routing is suitable for this type of network deployment.
0 50000 100000 150000 200000 250000
0 70 140 210 280
Distance between base station and center of network
Total Routing Iteration
Ariadne
SEAD
Energy Aware Routing
Energy-Balancing Secure Routing
Figure 6: Evaluation on distance between base station and central of the network
Figure 4-5 demonstrates the situation on variety distance between base station and central of the network. The result shows that the total routing iterations decrease as distance between base station and central of the network drop off. That is because when base station far away from central of network, 1-hop neighbor will reduce significantly, and it is harder to balance the energy consumption caused by routing.
However, the evaluation shows that Energy-Balancing Secure Routing still perform better than other scheme because of no periodically broadcasting cost in the proposed scheme.
The evaluation shows that Energy-Balancing Secure Routing can prolong total time of overall network connectivity in a multiple times than present secure routing protocols, and is adaptable to the network environment with more 1-hop node. In the future, energy capacity of each sensor node will be design larger, and then the proposed scheme will perform better.
5. Security Analysis
In this section, we analyze the security in the proposed scheme. We first list the requirements for wireless sensor networks, and then discuss the protection of the requirements.
5.1. Security Requirements
We list the security properties required by wireless sensor network, and shows how they directly applicable in a typical wireless sensor network.
5.1.1. Semantic Security
In sensor networks, due to wireless communication property, eavesdropper can always get the transmitting messages on the air. [27] mentions that eavesdropper may be able to infer the message content from the encrypted messages if it sees multiple encryptions of the same plaintext. Semantic security is a strong security property that prevents eavesdroppers from getting information about the plaintext from multiple encrypted messages.
5.1.2. Data Confidentiality
A wireless sensor network should not leak sensor readings to neighboring networks. In many applications, nodes communicate highly sensitive data. The standard approach for keeping sensitive data secret is to encrypt the data with a secret key that only intended receivers possess, hence achieving data confidentiality.
5.1.3. Data Authentication
networks. Since an adversary can easily inject messages, the receiver needs to ensure that data used originates from a trusted source. Informally, data authentication allows a receiver to verify that the data really was sent by the claimed sender.
In two-party communication case, data authentication can be achieved through a purely symmetric mechanism: the sender and the receiver shared a secret key to compute a message authentication code (MAC) of all communicated data. When a message with a correct MAC arrives, the receiver knows that it must have been sent by the sender.
5.1.4. Data Integrity
In network communication, data integrity ensures the receiver that the received data is not altered in transit by an adversary. Data integrity can be achieved through data authentication, which is a stronger security property.
5.1.5. Data Freshness
Wireless sensor networks send message over time, so it is not enough to guarantee confidentiality and authentication; we must also ensure each message is fresh. Informally, data freshness implies that the data is recent, and it ensures that no adversary replayed old message.
5.2. Analysis
In this section, we are going to show how the proposed scheme provides semantic security, data authentication, data confidentiality, data integrity, replay protection and data freshness.
5.2.1. Semantic Security
A basic technique to achieve semantic security is randomization: Before encrypting the message with a chaining encryption function, the sender precedes the message with a random bit string. This prevents the attacker from inferring the plaintext-ciphertext pairs encrypted with the same key. However, sending the randomized data over a wireless channel requires more energy.
Alternatively, the proposed scheme constructs another cryptographic mechanism that achieves semantic security without additional transmission overhead. We use a counter pair shared by two communication parties for the block cipher in counter mode. Since the counter value is incremented after each message transmission, the same message is encrypted differently each time. Hence, the eavesdropper is not able to derive knowledge from all the encrypted messages flowing over the network.
5.2.2. Data Authentication and Data Integrity
In the proposed scheme, each two communication parties shares a pair of secret key for MAC operation. When receiver receives a message, it can use the MAC key pair of the claimed sender to verify the MAC is correct or not. Because on other nodes contain this MAC key pair, the correctness of the MAC verification can prove that the
In the proposed scheme, each two communication parties shares a pair of secret key for MAC operation. When receiver receives a message, it can use the MAC key pair of the claimed sender to verify the MAC is correct or not. Because on other nodes contain this MAC key pair, the correctness of the MAC verification can prove that the