## 3 Literature Reviews
### LEACH-Based Secure Routing Protocols
#### 3.3.1 Sleach  
SLEACH is the first protocol that attempts to add security to LEACH. Figure 2 summarizes this protocol.  
Additional symbols denote:  
\(k_{X}\): Symmetric key shared by node \(X\) and BS;  
\(mac_{k}(\,)\): MAC calculated using key \(k\);  
\(\|\): Concatenation operator;  
**sec_adv**, **mac_array**: String identifier for message type;  
\(V\): An array of node ids, the legitimate CHs list;  
\(c_{X}\): Counter shared by node \(X\) and BS.  
Prior to deployment each sensor node \(X\) is loaded with two keys: key \(X_{X}\), a master symmetric key that node \(X\) shares with the BS; and key \(k_{j}\), a group key that is shared by all members in the network.  
Figure 2: SLEACH protocol.  
From \(X_{X}\), the key holders derive \(k_{X}\) for message authentication code (MAC) computation and verification. \(k_{j}\) is the last key of a key sequence \(S\) generated by applying a one-way hash function \(f\) recursively to an initial key \(k_{0}\) (\(S=k_{0},k_{1},...,k_{j-1},k_{j}\) where \(f\big{(}k_{j-1}\big{)}=k_{j}\) ). At the beginning BS keeps \(S\) secret, but then it will reveal the last element \(k_{j}\) to the network periodically. SLEACH uses \(\mu\)TESLA to do broadcast authentication.  
In the first step of the setup phase, CH candidates broadcast a modified advertisement **sec_adv** message to the network. This message contains the CH's id and the MAC of the CH's id, **sec_adv** and its counterpart. CH calculates the MAC using the \(k_{H}\) shared with BS. Upon receiving advertisement messages, each node stores the ids of CHs. On the BS side, when it receives any advertisement message, it verifies the MAC of the message. If the message is valid, the BS puts the corresponding CH's id into the list \(V\) of legitimate CHs.  
After compiling the list \(V\), BS broadcasts the list along with its MAC computed with \(k_{j-1}\). BS then reveals \(k_{j-1}\) after some time. Every node then verifies the validity of \(k_{j-1}\) (\(f\big{(}k_{j-1}\big{)}\) should equal \(k_{j}\)) and checks if the id of the chosen CH candidate is in the list of the legitimate CHs.  
Then in the second step, each node sends its join request **join_req** to a legitimate CH in which it wants to join. In the last step of the setup phase, CHs broadcast a schedule message **sched** containing TDMA time slots to their cluster members.  
Having done the cluster formation, network enters the steady-state phase. This starts with a cluster member sending its sensor reading to its CH according to the time slot assigned for it. The message is shown in step 4. It contains the sender's id, its sensor reading, and the MAC of its id and the counter calculated using the key shared with the BS.  
After collecting the data, CH then aggregatesthem. It creates a message containing its id, aggregated data and the MAC of them both. It also includes its counter shared with the BS in the MAC computation. Then it sends this message to the BS. This is shown in step 5.1.  
Another message from a CH to BS is the MAC array of its cluster members **mac_array**. Step 5.2 shows this message. MACs pairs are taken from the message in step 4.  
In the final step BS verifies every MAC of the sensor nodes. If any MAC is invalid, BS drops the whole packet and sends back the list of illegitimate sensors to the corresponding CHs, so they can blacklist them for the next round.