**5. Real-time key management algorithm**

The proposed security algorithm [11] is designed for the purpose of safely transferring keys and synchronous nodes in WMN. In sections 5.1 and 5.2, we will present our key management method based on Adi Shamir's algorithm; the synchronization between nodes by real-time clock helps our keys prevent different types of external attacks. We also present a protocol used for transferring those keys in WMN; this protocol will focus on preventing man-in-middle attack and detecting other abnormal activities in this network.

### **5.1 Real-time clock key management**

The conventional key management methods are easy to be attacked by various attacks such as eavesdropping keys and data, de-authentication, and denial-ofservice (DoS). Therefore, we propose to use real-time clock to change continuously private key in key management of each node and synchronize all nodes in WMN, so these nodes will be completely independent of each other. One of those nodes is the network time protocol (NTP) server, and the others are NTP clients. Using the WMN model, the NTP data are transferred quickly enough for synchronization. At a certain point, the nodes will together create a unique key, and every group of n keys is required to reconstruct the same secret for the encryption and decryption.

The process of the proposed method is reversely compared with Adi Shamir's method as shown in **Figure 1**. In the proposed method, the private key is created first instead of the master key. Therefore, the secret will not be detected when the attacker attacks on any node. Besides that, this secret is constantly changed by using a real-time clock module, and thus this makes it more difficult for attackers to be successful in penetrating the network (**Figure 2**).

Private key is generated by a unique value depending on each device—MAC address. A threshold level is required for this process. This parameter will be set depending on the number and installation location of nodes in WMN. The process of private key generation is shown in **Figure 3**.

**Figure 1.** *Adi Shamir's secret sharing scheme.*

**Figure 2.**

*Proposed secret sharing scheme.*

### **Figure 3.**

*The process of private key generation.*

Reconstructed secret is implemented after each node has enough keys. It is received from nodes in WMN by simple BATMAN protocol which we will talk about in the next section. Lagrange interpolating polynomial was used for our purpose [12]. This is described by the following equations:

For i = (1:node).

$$\mathcal{S} = \left(\mathcal{S} + f(\boldsymbol{\varkappa\_i}) \prod\_{m=0, \boldsymbol{m} \neq i}^{k-1} (\boldsymbol{\varkappa\_m}) \left/ (\mathbb{X}\_m - \mathbb{X}\_i) \right.\right) \tag{4}$$

If we use this original Lagrange interpolating polynomial, there is a security problem: attackers can gain a lot of information about S with every couple key (*xi, f* (*xi*)). They have numbers to guess from instead of an infinite number of natural numbers by using normal basic methods to solve this set of equations.

This problem can be fixed by using finite field arithmetic in a field of size p ∈ Ρ:p > S,p > n. We calculated the couple keys as (*xi, f*(*xi*) *mod p*) instead of (*xi, f*(*xi*)). The lower one sets p, the lower the number of possible values that the attackers have to guess from to set S. Therefore, we made a small change to our key generation function and reconstruction function by the following equations:

$$\mathcal{S} = \left(\mathcal{S} + p + \mathcal{y}; \prod\_{k=1 \land k \neq i}^{k=nod \epsilon} (-\infty\_k)\mathcal{S}\right) \bmod p \tag{5}$$

$$\delta \times \left(\prod\_{k=1 \land k \neq i}^{k \colon nade} (\boldsymbol{\pi}\_i - \boldsymbol{\pi}\_k) \right) \bmod p = 1 \tag{6}$$

**49**

**Figure 5.**

nodes.

**Figure 4.**

*Modified BATMAN protocol.*

our protocol.

node 2 is too long to establish a link.

*Proposed security protocol header frame.*

*Key Management Techniques for Wireless Mesh Network DOI: http://dx.doi.org/10.5772/intechopen.83399*

While BATMAN advance protocol works as a communicate protocol for sending and receiving data in WMN and detecting node nearby with the same WMN, our proposed protocol uses list neighbor nodes of each node in WMN to work for our purpose. Every node sends its private key frequently to neighbor nodes; an authenticated address list has to be created and checked. This work can be easily done by designing a customized package frame on raw debug socket interface (**Figure 5**).

• Encrypt the data by secret which is reconstructed with keys of nearby neighbor

• Send private key over a man-in-middle node by our frame to increase range of

In order to reach these goals, we combine our protocol and scheme into a multi-

**Figures 7** and **8** show an example of development with three nodes; node 1 is within the communication range of the others, but the distance between node 0 and

To prevent man-in-middle attack as we have mentioned before, we encrypt the node's keys each time they are transferred to the other node, so there is a problem on how the requesting node can receive exactly that key with this method. We add a

• Warn all nodes in the network when there is an intrusion attack in network.

The objectives of proposed security protocol are the following:

thread program with the flow graph as shown in **Figure 6**.

where S is the secret value which we need for authentication in WMN. Pair of x and y serves as a key to reconstruct secret as we have presented.

### **5.2 Proposed security protocol**

The protocol which we use for our key management scheme is based on the BATMAN protocol—an efficient protocol used to establish connection in WMN. **Figure 4** describes how our protocol works.

*Key Management Techniques for Wireless Mesh Network DOI: http://dx.doi.org/10.5772/intechopen.83399*

**Figure 4.** *Modified BATMAN protocol.*

*Wireless Mesh Networks - Security, Architectures and Protocols*

[12]. This is described by the following equations:

*<sup>S</sup>* <sup>=</sup> (*<sup>S</sup>* <sup>+</sup> *<sup>f</sup>*(*xi*)∏*m*=0∧*m*≠*<sup>i</sup>*

*S* = (*S* + *p* + *y*.∏

**Figure 4** describes how our protocol works.

δ × (∏

**5.2 Proposed security protocol**

For i = (1:node).

*The process of private key generation.*

**Figure 3.**

**Figure 2.**

*Proposed secret sharing scheme.*

Reconstructed secret is implemented after each node has enough keys. It is received from nodes in WMN by simple BATMAN protocol which we will talk about in the next section. Lagrange interpolating polynomial was used for our purpose

*k*−1

If we use this original Lagrange interpolating polynomial, there is a security problem: attackers can gain a lot of information about S with every couple key (*xi, f* (*xi*)). They have numbers to guess from instead of an infinite number of natural numbers by using normal basic methods to solve this set of equations. This problem can be fixed by using finite field arithmetic in a field of size p ∈ Ρ:p > S,p > n. We calculated the couple keys as (*xi, f*(*xi*) *mod p*) instead of (*xi, f*(*xi*)). The lower one sets p, the lower the number of possible values that the attackers have to guess from to set S. Therefore, we made a small change to our key generation function and reconstruction function by the following equations:

> *k*=1∧*k*≠*i k*=*node*

where S is the secret value which we need for authentication in WMN. Pair of x

The protocol which we use for our key management scheme is based on the BATMAN protocol—an efficient protocol used to establish connection in WMN.

*k*=1∧*k*≠*i k*=*node*

and y serves as a key to reconstruct secret as we have presented.

(*xm*)/(*xm* − *xi*)) (4)

(−*xk*).δ) mod *p* (5)

(*xi* − *xk*)) mod *p* = 1 (6)

**48**

While BATMAN advance protocol works as a communicate protocol for sending and receiving data in WMN and detecting node nearby with the same WMN, our proposed protocol uses list neighbor nodes of each node in WMN to work for our purpose. Every node sends its private key frequently to neighbor nodes; an authenticated address list has to be created and checked. This work can be easily done by designing a customized package frame on raw debug socket interface (**Figure 5**).

The objectives of proposed security protocol are the following:


In order to reach these goals, we combine our protocol and scheme into a multithread program with the flow graph as shown in **Figure 6**.

**Figures 7** and **8** show an example of development with three nodes; node 1 is within the communication range of the others, but the distance between node 0 and node 2 is too long to establish a link.

To prevent man-in-middle attack as we have mentioned before, we encrypt the node's keys each time they are transferred to the other node, so there is a problem on how the requesting node can receive exactly that key with this method. We add a


**Figure 5.**

*Proposed security protocol header frame.*

### **Figure 6.**

*Proposed program flow graph.*

**51**

time field work.

**Figure 8.**

*Secret reconstruction of node 0.*

**5.3 System implementation**

*Key Management Techniques for Wireless Mesh Network DOI: http://dx.doi.org/10.5772/intechopen.83399*

new field "hop count" to our header frame. This field is used for counting the number of nodes which will help the packet from the requester to be transferred to the destination. Then the destination will take that value to encrypt its key <hop count> time s before sending it to the source who requested for more keys. The "key used for encrypting key" is also generated by real-time method; it must be known by all nodes between source and destination to ensure that the decryption on those nodes is correct. Another issue is the case that an intrusion node tries to decrypt more than one time to get the value of encrypted key. In order to solve this issue, we set hop count value equal to 0 so the intrusion node does not know how many times it has to decrypt for getting the key. Only the owner of the key knows this hop count value. The process of the key encryption with hop count values is shown in **Figure 9**. Because of the delay when transferring the data, it is hard to synchronize the nodes in WMN with our real-time method; the encryption will be incorrect with only NTP system. Thus, we use a buffer at each node in WMN and a field to tell the delay time the request packet sends from the source to destination. When the destination receives the frame, it can send the key it generated at the time the source sends out its request packet; the buffer has responsibility to record all the key value in a minute latest. Therefore, if the delay value in WMN is over 1 minute, requester cannot receive the key from destination. **Figure 10** shows how the buffer and delay

We consider a WMN consisting of sensor nodes that can work as base stations which

will help non-mesh clients communicate together (**Figure 11**). In this experiment,

**Figure 7.** *Secret reconstruction of node 1.*

*Key Management Techniques for Wireless Mesh Network DOI: http://dx.doi.org/10.5772/intechopen.83399*

*Wireless Mesh Networks - Security, Architectures and Protocols*

**50**

**Figure 7.**

**Figure 6.**

*Proposed program flow graph.*

*Secret reconstruction of node 1.*

**Figure 8.** *Secret reconstruction of node 0.*

new field "hop count" to our header frame. This field is used for counting the number of nodes which will help the packet from the requester to be transferred to the destination. Then the destination will take that value to encrypt its key <hop count> time s before sending it to the source who requested for more keys. The "key used for encrypting key" is also generated by real-time method; it must be known by all nodes between source and destination to ensure that the decryption on those nodes is correct. Another issue is the case that an intrusion node tries to decrypt more than one time to get the value of encrypted key. In order to solve this issue, we set hop count value equal to 0 so the intrusion node does not know how many times it has to decrypt for getting the key. Only the owner of the key knows this hop count value. The process of the key encryption with hop count values is shown in **Figure 9**.

Because of the delay when transferring the data, it is hard to synchronize the nodes in WMN with our real-time method; the encryption will be incorrect with only NTP system. Thus, we use a buffer at each node in WMN and a field to tell the delay time the request packet sends from the source to destination. When the destination receives the frame, it can send the key it generated at the time the source sends out its request packet; the buffer has responsibility to record all the key value in a minute latest. Therefore, if the delay value in WMN is over 1 minute, requester cannot receive the key from destination. **Figure 10** shows how the buffer and delay time field work.

### **5.3 System implementation**

We consider a WMN consisting of sensor nodes that can work as base stations which will help non-mesh clients communicate together (**Figure 11**). In this experiment,

**Figure 9.**

*Encryption of the key with hop count value.*

### **Figure 10.**

*How the buffer and delay time field work.*

we bridge wireless local area network interface and mesh network interface together instead of putting WLAN behind the firewall in order to make our work easier, because we only check if our scheme works perfectly on data link layer not on network layer.

Our test security program has already been installed on every sensor node, and we put them in distance. As our scheme, node 1 receives private key from nodes 2 and 3, combined with its key to reconstruct the original secret which is used to encrypt data. This encrypted data is sent to one of the clients of node 4; after decrypting, we compare the decrypted with the original data to see if our scheme works completely. Another parameter which we have to check is secret after reconstruction. We will list all those parameters in the next section.

### **5.4 Results**

In this experiment, we set secret—public key of WMN equal exactly to minute value of UTC time zone. Therefore, the time on every sensor node must be set at the

**53**

**Figure 11.** *System model.*

**Table 1.**

*Secret reconstruction analysis.*

our case are clients of nodes 1 and 3.

network and in particular wireless mesh network.

*Key Management Techniques for Wireless Mesh Network DOI: http://dx.doi.org/10.5772/intechopen.83399*

same value. **Table 1** shows the keys (decrypted keys) collected by node 1 needed for secret reconstruction analysis at the different time. We put a simple function for our experiment secret as follows: Secret = Hour value + Minute value. We executed our program on three nodes in this experiment. This program shows us the value of generated key of each node, the number of bad nodes this security detected, and the time and the secret which was reconstructed at that time. **Figure 12** shows all those results of all three nodes at the time 22:06. Each node has a different private key from the others based on its MAC address. But all of them have the same secret at a certain time. Secret is reconstructed exactly as the origin with at least three private keys of WMN. Therefore, we can run to the next step—data encryption—and original and decrypted data are the same in both transmitter and receiver if it works correctly, in

**Time Key 1 (Hex) Key 2 (Hex) Key 3 (Hex) Secret(Dec)**

19:45 96 C4 85 F4 26 18 64 19:51 EC C4 FB F4 E5 18 70 22:06 8C C4 6C F4 D5 18 28

After reconstructing the secret completely, data which are sent from node 1 will be encrypted by this secret. Both encrypted data and decrypted data are shown. This data is captured at one of the non-mesh clients of wireless local area network node 4. We had also checked if the keys are secured when they are transmitted in our model (four nodes with maximum hops equal to 2). Then, we used an external node which worked as a monitor node to capture the raw package to check if the keys are encrypted. We tested our methods to face types of attacks mainly in general wireless

Firstly, we test our network model with eavesdropping attacks. We use ESP8266 kits to collect all the data from our network; the entire data was encrypted; we also tried to collect private keys from authenticated nodes in this network to reconstruct *Key Management Techniques for Wireless Mesh Network DOI: http://dx.doi.org/10.5772/intechopen.83399*
