VIRTUAL ENERGY BASED ENCRYPTION AND KEYING
By: Hari Manasa
Tags: Encryption, Keying, Virtual, Programming, Virtual Energy

INTRODUCTION

Rapidly developed WSN technology is no longer nascent and will be used in a variety of application scenarios. Typical application areas include environmental, military, and commercial enterprises. For example, in a battlefield scenario, sensors may be used to detect the location of enemy sniper fire or to detect harmful chemical agents before they reach troops. In another potential scenario, sensor nodes forming a network under water could be used for oceanographic data collection, pollution monitoring, assisted navigation, military surveillance, and mine reconnaissance operations. Future improvements in technology will bring more sensor applications into our daily lives and the use of sensors will also evolve from merely capturing data to a system that can be used for real-time compound event alerting.

EXISTING SYSTEM:

An existing Dynamic Energy-based Encoding and Filtering framework to detect the injection of false data into a sensor network. Dynamic Energy-based that each sensed event report be encoded using a simple encoding scheme based on a keyed hash. The key to the hashing function dynamically changes as a function of the transient energy of the sensor, thus requiring no need for re-keying. Depending on the cost of transmission vs. computational cost of encoding, it may be important to remove data as quickly as possible. Accordingly, DEEF can provide authentication at the edge of the network or authentication inside of the sensor network. Depending on the optimal configuration, as the report is forwarded, each node along the way verifies the correctness of the encoding probabilistically and drops those that are invalid. We have evaluated DEEF’s feasibility and performance through analysis our results show that DEEF, without incurring transmission overhead.

2. PROPOSED SYSTEM:

VEBEK is a secure communication framework where sensed data is encoded using a scheme based on a permutation code generated via the RC4 encryption mechanism. The key to the RC4 encryption mechanism dynamically changes as a function of the residual virtual energy of the sensor. Thus, a one-time dynamic key is employed for one packet only and different keys are used for the successive packets of the stream. The intermediate nodes along the path to the sink are able to verify the authenticity and integrity of the incoming packets using a predicted value of the key generated by the sender’s virtual energy, thus requiring no need for specific rekeying messages. Our results show that VEBEK, without incurring transmission overhead (increasing packet size or sending control messages for rekeying), is able to eliminate malicious data from the network in an energy efficient manner. The encoding operation is essentially the process of permutation of the bits in the packet, according to the dynamically created permutation code via the RC4 encryption mechanism. The key to RC4 is created by the previous module (virtual energy-based keying module). The purpose of the crypto module is to provide simple confidentiality of the packet header and payload while ensuring the authenticity and integrity of sensed data without incurring transmission overhead of traditional schemes. However, since the key generation and handling process is done in another module, VEBEK’s flexible architecture allows for adoption of stronger encryption mechanisms in lieu of encoding. We also show that our framework performs better than other comparable schemes in the literature with an overall 60–100 percent improvement in energy savings without the assumption of a reliable medium access control layer.

HARDWARE REQUIREMENTS:

System : Pentium IV 2.4 GHz.

Hard Disk : 40 GB.

Floppy Drive : 1.44 Mb.

Monitor : 15 VGA Color.

Mouse : Logitech.

Ram : 512 Mb.

SOFTWARE REQUIREMENTS:

Operating System : Windows XP Professional

Coding Language : Visual C# .Net.

3. MODULE DESCRIPTION:

VIRTUAL ENERGY-BASED KEYING:

The virtual energy-based keying module of the VEBEK framework is one of the primary contributions of this paper. It is essentially the method used for handling the keying process. It produces a dynamic key that is then fed into the crypto module.

In VEBEK, each sensor node has a certain virtual energy value when it is first deployed in the network. Sensor nodes traverse several functional states. The states mainly include node-stay-alive, packet reception, transmission, encoding, and decoding. As each of these actions occurs, the virtual energy in a sensor node is depleted. The current value of the virtual energy in the node is used as the key to the key generation function.

VEBEK’s virtual energy-based keying module ensures that each detected packet2 is associated with a new unique key generated based on the transient value of the virtual energy. After the dynamic key is generated, it is passed to the crypto module, where the desired security services are implemented.

· Since a sensor node will be either forwarding some other sensor’s data or injecting its own data into the network, the set of actions and their associated energies for VEBEK includes packet reception (Erx), packet transmission (Etx), packet encoding (Eenc), packet decoding (Edec) energies, and the energy required to keep a node alive in the idle state (Ea). Specifically, the transient value of the virtual energy, Ev, is computed by decrementing the total of these predefined associated costs, Evc, from the previous virtual energy value.

In VEBEK, each sensor node has a certain virtual energy value when it is first deployed in the network. After deployment, sensor nodes traverse several functional states. The states mainly include node-stay-alive, packet reception, transmission, encoding, and decoding. As each of these actions occur, the virtual energy in a sensor node is depleted. The current value of the virtual energy, Evc, in the node is used as the key to the key generation function, F. During the initial deployment, each sensor node will have the same energy level Eini, therefore, the initial key, K1, is a function of the initial virtual energy value and an initialization vector (IV ). The IV s are predistributed to the sensors. Subsequent keys, Kj, are a function of the current virtual energy, Evc, and the previous key Kj_1. VEBEK’s virtual energy-based keying module ensures that each detected packet2 is associated with a new unique key generated based on the transient value of the virtual energy. After the dynamic key is generated, it is passed to the crypto module, where the desired security services are implemented.

TABLE 1: Notations Used

The process of key generation is initiated when data is sensed; thus, no explicit mechanism is needed to refresh or update keys. Moreover, the dynamic nature of the keys makes it difficult for attackers to intercept enough packets to break the encoding algorithm. The details are given in Algorithm 1. As mentioned above, each node computes and updates the transient value of its virtual energy after performing some actions. Each action (or state traversal) on a node is associated with a certain predetermined cost. Since a sensor node will be either forwarding some other sensor’s data or injecting its own data into the network, the set of actions and their associated energies for VEBEK includes packet reception (Erx), packet transmission (Etx), packet encoding (Eenc), packet decoding (Edec) energies, and the energy required to keep a node alive in the idle state (Ea).Specifically, the transient value of the virtual energy, Ev, is computed by decrementing the total of these predefined associated costs, Evc, from the previous virtual energy value.

Algorithm 1. Compute Dynamic Key

1: Compute Dynamic Key (Evc, IDclr)

2: begin

3: j <- txIDpower(clr)base(cnt)

4: if j =1 then

5: Kj <-F(Eini,IV)

6: else

7: Kj <- F(K(j_1), Evc)

8: end if

9: return Kj

10: end

The exact procedure to compute virtual cost, Evc, slightly differs if a sensor node is the originator of the data or the forwarder (i.e., receiver of data from another sensor). In

order to successfully decode and authenticate a packet, a receiving node must keep track of the energy of the sending node to derive the key needed for decoding. In VEBEK, the operation of tracking the energy of the sending node at the receiver is called watching and the energy value that is associated with the watched sensor is called Virtual Perceived Energy (Ep)

More formal definitions for watching are given as follows:

Definition 1

Given a finite number of sensor nodes, N(N={1, . . .,N}), deployed in a region, watching is defined as a node’s responsibility for monitoring and filtering packets coming from a certain (configurable) number of sensor nodes, r, where r <=N. <. is used to denote the watching operation.

Definition 2

Given a sensor node i, the total number of watched nodes, r, which the node is configured to watch, constitutes a watching list, WLi for node i and WLi =(1, 2, . . . ; r). Node i watches node k if IDk belongs WLi.

Deciding which nodes to watch and how many depends on the preferred configuration of the VEBEK authentication algorithm, which we designate as the operational mode of the framework. Specifically, we propose two operational

modes VEBEK-I and VEBEK-II.

When an event is detected by a source sensor, that node has remained alive for t units of time since the last event (or since the network deployment if this is the first event detected). After detection of the event, the node sends the l-bit length packet toward the sink. In this case, the following is the virtual cost associated with the source node:

Evc = l * (etx + eenc) + t * ea + Esynch:

In the case where a node receives data from another node, the virtual perceived energy value can be updated by decrementing the cost associated with the actions performed

by the sending node using the following cost equation. Thus, assuming that the receiving node has the initial virtual energy value of the sending node and that the packet is successfully received and decoded associated with a given source sensor, k, the virtual cost of the perceived energy is computed as follows:

Ekp= l * (erx + edec + etx + eenc) + t * 2 * ea;

where in both the equations, the small es refer to the one bit energy costs of the associated parameter.However, Esynch refers to a value to synchronize the source with the watcher-forwarders toward the sink as watcher-forwarder nodes spend more virtual energy due to packet reception and decoding operations, which are not present in source nodes.

Hence, Esynch = l * (erx + edec) + ea * t. The watching concept is illustrated with an example in Fig. 1.

Fig.1 An illustration of the watching concept with forwarding.

In the above figure, there is one source sensor node, A, and other nodes B, C, and D are located along the path to the sink. Every node watches its downstream node, i.e., B watches A (B <_ A), C watches B (C <_ B), and D watches C (D <_ C). All the nodes have the initial virtual energy of 2,000 mJ and as packets are inserted into the network from the source node (A) overtime, nodes decrement their virtual energy values. For instance, as shown in Fig. 1, node A starts with the value of 2,000 mJ as the first key to encode the packet (key generation based on the virtual energies is explained in the crypto module). Node A sends the first packet and decrements its virtual energy to 1,998 mJ. After node B receives this first packet, it uses the virtual perceived energy value (Ep = 2;000 mJ) as the key to decode the packet, and updates its Ep (1,998 mJ) after sending the packet. When the packet travels up to the sink, the virtual energy becomes a shared dynamic cryptic credential among the nodes.

RESOURCE CRYPTO MODULE:

The crypto module in VEBEK employs a simple encoding process, which is essentially the process of permutation of the bits in the packet according to the dynamically created permutation code generated via RC4. The encoding is a simple encryption mechanism adopted for VEBEK.

However, VEBEK’s flexible architecture allows for adoption of stronger encryption mechanisms in lieu of encoding. Last, the forwarding module handles the process of sending or receiving of encoded packets along the path to the sink. After the dynamic key is generated, it is passed to the crypto module, where the desired security services are implemented.

The process of key generation is initiated when data is sensed; thus, no explicit mechanism is needed to refresh or update keys. Moreover, the dynamic nature of the keys makes it difficult for attackers to intercept enough packets to break the encoding algorithm.

Due to the resource constraints of WSNs, traditional digital signatures or encryption mechanisms requiring expensive cryptography is not viable. The scheme must be simple, yet effective. Thus, in this section, we introduce a simple encoding operation. The encoding operation is essentially the process of permutation of the bits in the packet, according to the dynamically created permutation code via the RC4 encryption mechanism.

Due to the resource constraints of WSNs, traditional digital signatures or encryption mechanisms requiring expensive cryptography is not viable. The scheme must be simple, yet effective. Thus, in this section, we introduce a simple encoding operation. The encoding operation is essentially the process of permutation of the bits in the packet, according to the dynamically created permutation code via the RC4 encryption mechanism. The key to RC4 is created by the previous module (virtual energy-based keying module). The purpose of the crypto module is to provide simple confidentiality of the packet header and payload while ensuring the authenticity and integrity of sensed data without incurring transmission overhead of traditional schemes. However, since the key

generation and handling process is done in another module, VEBEK’s flexible architecture allows for adoption of stronger encryption mechanisms in lieu of encoding.

The packets in VEBEK consists of the ID (i-bits), type (t-bits) (assuming each node has a type identifier), and data (d-bits) fields. Each node sends these to its next hop.

However, the sensors’ ID, type, and the sensed data are transmitted in a pseudorandom fashion according to the result of RC4. More specifically, the RC4 encryption algorithm takes the key and the packet fields (byte-bybyte) as inputs and produces the result as a permutation code as depicted in Fig. 2. The concatenation of each 8-bit output becomes the resultant permutation code. As mentioned earlier, the key to the RC4 mechanism is taken rom the core virtual energy-based keying module, which is responsible for generating the dynamic key according to the residual virtual energy level. The resultant permutation code is used to encode the (ID/type/data) message. Then, an additional copy of the ID is also transmitted in the clear along with the encoded message. The format of the final packet to be transmitted becomes Packet= [ID{ID; type; datag}k] where {x}k constitutes encoding x with key k. Thus, instead of the traditional approach of sending the hash value (e.g., message digests and message authentication codes) along with the information to be sent, we use the result of the permutation code value locally. When the next node along the path to the sink receives the packet, it generates the local permutation

code to decode the packet.

Fig. 2. An illustration of the use of RC4 encryption mechanism in VEBEK.

Another significant step in the crypto module involves how the permutation code dictates the details of the encoding and decoding operations over the fields of the packet when generated by a source sensor or received by a forwarder sensor. Specifically, the permutation code P can be mapped to a set of actions to be taken on the data stream combination. As an example, the actions and their corresponding bit values can include simple operations such as shift, interleaving, taking the 1’s complement, etc. Other example operations can be seen in Table 2.

TABLE 2: Example Encoding Operations

Figure 3 Illustration of a sample encoding operation. (a) i + t + d bit string before permutation. (b) Example encoding operations. © Example permutation code value. (d) i + t + d bit string after permutation.

For example, if a node computed the following permutation code P={1100100101}, the string in Fig. 5a becomes the string in Fig. 3d before it is transmitted. The receiver will perform the same operations (since the inputs to RC4 are stored and updated on each sensor) to accurately decode the packet. To ensure correctness, the receiver compares the plaintext ID with the decoded ID. Moreover, although it is theoretically possible (1 in 2power(i+t+d) for a hacker to accurately inject data, it becomes increasingly unlikely as the packet grows. The benefits of this simple encoding scheme are: 1) since there is no hash code or message digest to transmit, the packet size does not grow, avoiding bandwidth overhead on an already resource-constrained network, thus increasing the network lifetime, 2) the technique is simple, thus ideal for devices with limited resources (e.g., PDAs), and 3) the input to the RC4 encryption mechanism, namely, the key, changes dynamically without sending control messages to rekey.

NETWORKING MODULE:

Client-server computing or networking is a distributed application architecture that partitions tasks or workloads between service providers (servers) and service requesters, called clients. Often clients and servers operate over a computer network on separate hardware. A server machine is a high-performance host that is running one or more server programs which share its resources with clients. A client also shares any of its resources; Clients therefore initiate communication sessions with servers which await (listen to) incoming requests.

FORWARDING

The forwarding module is responsible for the sending of packets (reports) initiated at the current node (source node) or received packets from other sensors (forwarding nodes) along the path to the sink. The reports traverse the network through forwarding nodes and finally reach the terminating node, the sink.

The final module in the VEBEK communication architecture is the forwarding module. The forwarding module is responsible for the sending of packets (reports) initiated at the current node (source node) or received packets from other sensors (forwarding nodes) along the path to the sink. The reports traverse the network through forwarding nodes and finally reach the terminating node, the sink. The operations of the forwarding module are explained in this section.

3.3.1 Source Node Algorithm

When an event is detected by a source node, the next step is for the report to be secured. The source node uses the local virtual energy value and an IV (or previous key value if not the first transmission) to construct the next key. As discussed earlier, this dynamic key generation process is primarily handled by the VEBEK module. The source sensor fetches the current value of the virtual energy from the VEBEK module. Then, the key is used as input into the RC4 algorithm inside the crypto module to create a permutation code for encoding the {ID/type/data} message. The encoded message and the cleartext ID of the originating node are transmitted to the next hop (forwarding node or sink) using the following format: [ID,{ID,type,data}Pc], where {x}basePc constitutes encoding x with permutation code Pc. The local virtual energy value is updated and stored for use with the transmission of the next report.

3.3.2 Forwarder Node Algorithm

Once the forwarding node receives the packet it will first check its watch-list to determine if the packet came from a node it is watching. If the node is not being watched by the current node, the packet is forwarded without modification or authentication. Although this node performed actions on the packet (received and forwarded the packet), its local virtual perceived energy value is not updated. This is done to maintain synchronization with nodes watching it further up the route. If the node is being watched by the current node, the forwarding node checks the associated current virtual energy record (Algorithm 2) stored for the sending node and extracts the energy value to derive the key. It then authenticates the message by decoding the message and comparing the plaintext node ID with the encoded node ID. If the packet is authentic, an updated virtual energy value is stored in the record associated with the sending node. If the packet is not authentic it is discarded. Again, the virtual energy value associated with the current sending node is only updated if this node has performed encoding on the packet.

Algorithm 2.

Forwarding Node Algorithm with Communication Error Handling

1: Forwarder(currentNode,WatchedNode,UpstreamNode)

2: begin

3: i <-currentNode; enc <-0;WLi<- WatchList

4: k <-WatchedNode; src<- 0; j<- 0

5: Erxi , {IDclr, {msg}K} ReceivePacket()

6: if IDclr belongs WLi then

7: while (keyFound = 0)and(j <= threshold) do

8: Ekpi <- Fetch Virtual Energy(I, IDclr, enc, src)

9: K <-ComputeDynamicKey(Ekpi,IDclr)

10: Pc<- RC4(K,IDclr)

11: Edeci, MsgID decode(Pc, {msg}K)

12: if IDclr = MsgID then

13: keyFound<- true

14: else

15: j++

16: Ekpi<-Ekpi_ Etxi _ Eenci _ Erxi _ Edeci _ 2 _ Eai

17: end if

18: end while

19: if keyFound = true then

20: if j > 1 then

21: reEncode <- true

22: else

23: if Ebi > 0 then

24: reEncode <- true

25: else

26: reEncode <- false

27: end if

28: end if

29: if reEncode =true then

30: enc <- 1

31: Ebi <- Fetch Virtual Energy (I, IDclr, enc; src)

32: K <- ComputeDynamicKey(Ebi, IDclr)

33: Pc <- RC4(K, IDclr)

34: Eenci , {msg}Pc <- encode (Pc, msg)

35: packet <- (IDclr, {msg}Pc)

36: Etxi <- ForwardPacket()

37: Ebi <- Ebi _ Etxi _ Eenci _ Erxi _ Edeci _ 2 _ Eai

38: else

39: ForwardPacket() //Without any modification

40: end if

41: else

42: DropPacket() //Packet not valid

43: end if

44: else

45: ForwardPacket() //Without any modification

46: end if

47: end

Addressing Communication Errors via Virtual Bridge Energy

In VEBEK, to authenticate a packet, a node must keep track of the virtual energy of the sending node to derive the key needed for decoding. Ideally, once the authenticating node has the initial virtual energy value of the sending node, the value can be updated by decrementing the cost associated with the actions performed by the sending node using the cost equations defined in the previous sections on every successful packet reception. However, communication errors may cause some of the packets to be lost or dropped. Some errors may be due to the deployment region (e.g.,

underwater shadow zones) while operating on unreliable underlying protocols (e.g., medium access control protocol). For instance, ACK or data packets can be lost and the sender may not be able to determine which one actually was lost. Moreover, malicious packets inserted by attackers who impersonate legitimate sensors will be dropped intentionally by other legitimate sensors to filter the bad data out of the network. In such communication errors or intentional packet drop cases, the virtual energy value used to encode the next data packet at the sending node may differ from the virtual energy value that is stored for the sending node at its corresponding watching node. Specifically, the node that should have received the dropped packet and the nodes above that node on the path to the sink lose synchronization with the nodes below (because the upper portion never sees the lost packet and does not know to decrement the virtual energy associated with servicing the lost transmission). If another packet was to be forwarded by the current watching node using its current virtual energy, the upstream node(s) that watch this particular node would discard the packet. Thus, this situation needs to be resolved for proper functioning of the VEBEK framework.

To resolve potential loss of packets due to possible communication errors in the network, all the nodes are configured to store an additional virtual energy value, which we refer to as the Virtual Bridge Energy, Ebi , value to allow resynchronization (bridging) of the network at the next watching sensor node that determines that packets

were lost.

Definition 3

Given a node, i, bridging is defined as the process of encoding the incoming packet coming from any sensor node in WLi for the upstream sensor node, j, with the key generated using the local copy of Ebi .

That is, as subsequent packets generated from the node of interest pass through the next watching node, the next watching node will decode the packet with the virtual

perceived energy key of the originating node and re encode the packet with the virtual bridge energy key, thus, the network will be kept synchronized. It is important to note

that once this value is activated for a watched node, it will be always used for packets coming from that node and used even if an error does not occur for the later transmissions of the same watched node. The watching node always updates and uses this parameter to keep the network bridged. Another pertinent point is the determination of packet loss by the first upstream watching node who will bridge the network. The VEBEK framework is designed to avoid extra messages and not increase the packet size to determine packet loss in the network. Thus, the next watching node tries to find the correct value of the virtual perceived energy for the key within a window of virtual energies. For this, a sensor is configured with a certain VirtualKeySearchThreshold value. That is, the watching node decrements the predefined virtual energy value from the current perceived energy at most virtualKeySearchThreshold times. When the node extracts the key successfully, it records the newest perceived energy value and associates it with the sender node (lines 7–18 in Algorithm 2). This approach may also be helpful in severe packet loss cases (i.e., bursty errors) by just properly configuring the virtualKeySearchThreshold value. However, if the watcher node exhausts all of the virtual energies within the threshold, it then classifies the packet as malicious. The combined use of virtual perceived and bridge energies assure the continued synchronization of the network as whole. The forwarding node algorithm including the handling of communication errors is shown in Algorithm 2.

CONCLUSION

Communication is very costly for wireless sensor networks WSNs) and for certain WSN applications. Independent of the goal of saving energy, it may be very important to minimize the exchange of messages (e.g., military scenarios). To address these concerns, we presented a secure communication framework for WSNs called Virtual Energy- Based Encryption and Keying.

We have evaluated VEBEK’s feasibility and performance through both theoretical analysis and simulations. Our results show that different operational modes of VEBEK can be configured to provide optimal performance in a variety of network configurations depending largely on the application of the sensor network. We also compared the energy performance of our framework with other en route malicious data filtering schemes. Our results show that VEBEK performs better than others while providing support for communication error handling, which was not the focus of earlier studies.

REFERENCES

[1] I.F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, “Wireless Sensor Networks: A Survey,” Computer Networks, vol. 38, no. 4, pp. 393–422, Mar. 2002.

[2] C. Vu, R. Beyah, and Y. Li, “A Composite Event Detection in Wireless Sensor Networks,” Proc. IEEE Int’l Performance, Computing, and Comm. Conf. (IPCCC ’07), Apr. 2007.

[3] S. Uluagac, C. Lee, R. Beyah, and J. Copeland, “Designing Secure Protocols for Wireless Sensor Networks,” Wireless Algorithms, Systems, and Applications, vol. 5258, pp. 503–514, Springer, 2008.

[4] Crossbow Technology, http://www.xbow.com, 2008. [5] G.J. Pottie and W.J. Kaiser, “Wireless Integrated Network Sensors,” Comm. ACM, vol. 43, no. 5, pp. 51–58, 2000.

[5] R. Roman, C. Alcaraz, and J. Lopez, “A Survey of Cryptographic Primitives and Implementations for Hardware-Constrained Sensor Network Nodes,” Mobile Networks and Applications, vol. 12, no. 4, pp. 231–244, Aug. 2007.

[6] H. Hou, C. Corbett, Y. Li, and R. Beyah, “Dynamic Energy-Based Encoding and Filtering in Sensor Networks,” Proc. IEEE Military Comm. Conf. (MILCOM ’07), Oct. 2007.

[7] L. Eschenauer and V.D. Gligor, “A Key-Management Scheme for Distributed Sensor Networks,” Proc. Ninth ACM Conf. Computer and Comm. Security, pp. 41–4, 2002.

[8] M. Eltoweissy, M. Moharrum, and R. Mukkamala, “Dynamic Key Management in Sensor Networks,” IEEE Comm. Magazine, vol. 44, no. 4, pp. 122–130, Apr. 2006.

[9] M. Zorzi and R. Rao, “Geographic Random Forwarding (GeRaF) for Ad Hoc and Sensor Networks: Multihop Performance,” IEEE Trans. Mobile Computing, vol. 2, no. 4, pp. 337–348, Oct.-Dec. 2003.