## 5 Proposed Protocol
### Combining LEACH-Based Security Protocol with ESPDA  
Based on the previous security requirements, a protocol that considers security in the cluster formation, routing mechanism and data aggregation process is proposed. This protocol is summarized by Figure 7. Like the LEACH protocol, the proposed protocol works in rounds and has two phases, the setup phase and steady-state phase. Before we jump into the explanation on how the proposed protocol addresses those security requirements, the description of counter management in our system is provided first. In order to provide data freshness, we introduce three types of counters. They are counters shared between a node and the BS, a counter that is shared between two nodes in the network and a cluster counter which is shared within a certain cluster. These counters are incremented every time a successful communication takes place between two involved parties whether individual parties or a group. In resetting the counter, the exception is the cluster counter, which is created every time a new cluster is formed and destroyed at the end of a round. The proposed protocol depicted in Figure 7 summarizes how those security requirements are met. The step by step explanation below gives a description of our protocol:  
* The **adv** message  
In order to provide data integrity and source authentication for **adv** messages, we use a digital signature. This approach is different from the SLEACH approach. SLEACH uses MAC to provide data integrity and \(\mu\)TESLA to provide authentication for the CH sending the **adv**. It uses \(\mu\)TESLA with the help of the BS because SLEACH does not have pairwise keys between nodes that can help any node in the network authenticate the CH directly, so the BS, on behalf of any other node in the network, authenticates the CH. It then issues a list of legitimate CHs to the network. Compared to SLEACH, the proposed protocol's approach has less communication overhead. In the proposed protocol, every node can directly authenticate a CH after receiving the **adv** message while in SLEACH the process of source authentication is indirect. Every node has to wait for the BS. Furthermore, if SLEACH's approach is adopted, then we need to provide the key chain management mechanism. Rekeying is needed to update the key chain so the process of \(\mu\)TESLA broadcast authentication can still be maintained. Therefore we avoid adopting the SLEACH approach. Though SecLEACH does not provide a data integrity feature for the **adv** message, it does provide a source authentication feature. By employing a random key pre-distribution mechanism, SecLEACH cuts down the communication overhead suffered by SLEACH. The use of a shared common key later on verifies the identity of the counterpart which also imposes a source authentication service. Thus weuse identity-based key agreement to avoid storing a lot of keys and having orphan nodes in the network. For **adv** message data freshness we use nonce, which ensures freshness for **adv** messages. Where the various additional symbols denote:  
\[ \begin{array}{ll}\textit{nonce}&:&\text{A random number used once};\\ \textit{Sig}_{S_{X}}(u,v,...)&:\text{A digital signature computed using private key of node }X,\text{ the }S_{X},\text{ and based on inputs }(u,v,...);\\ K_{X,Y},\text{ }K_{X}&:&\text{A mutual secret key of node }X\text{ and }Y,\text{ and of node }X\text{ and the BS, respectively,}\\ &\text{computed using ID-based non-interactive key agreement scheme};\\ hash()&:&\text{A hash function};\\ C_{X},\textit{cluster\_ctr},\textit{ctr}_{X};\text{ A counter node }X\text{ shared with BS, a cluster key counter of a certain cluster }j,\\ &\text{and a counter node }X\text{ shared with its CH, respectively}.\end{array} \]  
* The **join_req** message  
The data integrity of this message is provided through MAC. The use of a pairwise session key between the CH and the sender gives the message source authentication features.