## 5 Proposed Protocol
### Combining LEACH-Based Security Protocol with ESPDA
Driving a pairwise session key from a mutual secret key and the nonce of the **adv** message freshens against replay attacks. Figure 7: The proposed protocol. * The **CK_req** message  
The data integrity feature for **CK_req** to protect the list of nodes that are needed for the cluster key is provided via MAC. The use of a secret key shared between the requesting CH and the BS provides source authentication, whereas data freshness is achieved by including the counter that the CH shared with the BS in the computation of the shared secret key. * The **CK_rep** message  
Digital signature provides both data integrity and source authentication for the whole message. Data confidentiality is provided via encryption. As the BS encrypts the cluster key for each node listed in **CK_req** message using each corresponding mutual secret key, it also guarantees that the cluster key comes from the authorized BS. The BS also includes counters it shares with each node for the computation of the shared secret key in order to provide data freshness. * The **sched_seed_permut** message  
Data integrity is provided using MAC. The use of cluster keys provides source authentication. Because all nodes in the cluster share the cluster key, anyone in that cluster can generate and broadcast a fake **sched_seed_permut** message in order to disrupt the communication and data aggregation. Therefore in order to prevent this from happening, it is very important to authenticate nodes that join a cluster. Data confidentiality of the pattern seed and NOVSF-BH mapping permutation are provided through encryption. A cluster counter is included in the MAC computation to provide data freshness. * The **pattern_code** message  
Data integrity is provided via MAC. The use of a mutual secret key between the CH and each cluster member guarantees the source authentication. As **pattern_code** message is the message sent at the beginning of the steady-state phase; we include a timestamp in the computation of the mutual secret key between each node and the CH to mark the beginning this phase. This provides data freshness for every new steady-state phase because our protocol works on multiple steady-state phases. As in every steady state-phase there is more than one communication between clusters and the CH, so we include the counter every node shares with the CH in the MAC computation to provide data freshness. * The **selected_nodes** message  
Data integrity is provided via MAC. Source authentication is provided using a cluster key. Like the **sched_seed_permut** message case where anyone having the cluster key can generate and broadcast fake **selected nodes** messages, the prevention depends on the source authentication feature of the **join_req** message. * The **data** message  
Data integrity and source authentication are available for communication between cluster members and the CH, and between the CH and the BS via the identity-based key agreement. Data integrity is provided via MAC. The use of a mutual secret key guarantees the source authentication of the message. Data confidentiality features are available via encryption. For the **data** message transmitted within the cluster, its data freshness is provided by including the counter every node shares with the CH in the MAC computation, whereas data freshness for the **data** messages sent by the CH to the BS is provided by including the counter the CH shares with the BS in the mutual session secret key computation. Table 2 summarizes those approaches we use to fulfill the security requirement for the proposed protocol.