## 6 Security Solutions
### Communication Security
#### 6.2.2 End-to-End Network Security  
Considering the functional security requirements, such as global identification, mobility, and multiplicity of smart objects, the Host Identity Protocol (HIP) [117] can be a suitable solution for mutual authentication and key establishment between two communicating peers. The HIP introduces an additional layer (Host Identity layer) between the transport layer and the IP layer to resolve the problems caused by the dual role of an IP address: identifier and locator. However, the HIP cannot be applied directly to the resource-constrained IoT devices and networks because the authentication process of HIP requires communicating devices to perform computation-intensive cryptographic operations. Various lightweight versions of the conventional HIP are proposed to make HIP suitable for IoT systems. In the following sections, we provide a survey on these HIP-based security schemes. **HIP-Based Exchange (HIP-BEX):** HIP-BEX [117] enables communicating devices to perform mutual authentication and establish session keys. We present the authentication and key establishment process in Figure 18. In HIP-BEX, communicating devices identify and authenticate themselves by using cryptographically protected host identifiers (HIs) and the RSA cryptography. Four types of messages are exchanged between an Initiator (a sender) and a Responder (a receiver). The Initiator starts the communication by sending an I1 message. The Responder replies with an R1 message, which contains a puzzle, the Responder's DH public value (\(DH_{R}\)) and host identifier (\(HI_{R}\)), and an RSA signature. The Initiator verifies the signature and authenticates the Responder. The Initiator also solves the puzzle and computes a DH session key (\(K_{DH}\)) using the DH public value \(DH_{R}\). The Initiator sends an I2 message that consists of the solution, the Initiator's DH public value (\(DH_{I}\)) and host identifier (\(HI_{I}\)), and a signature. The Responder validates the signature  
Figure 17: Device hierarchy. \begin{table}
\begin{tabular}{c c c c c c} \hline \hline \multirow{2}{*}{**Property**} & \multicolumn{3}{c}{**Constrained/Intanet**} & \multicolumn{3}{c}{**Public/Internet**} \\ \cline{2-7}  & **Things-to-Things** & **Things-to-Coord.** & **Coord.-to-Gateway** & **Gateway-to-Cloud** &
\begin{tabular}{c} **Cloud-to-** \\ **Controller/User** \\ \end{tabular} \\ \hline Data Size & \textless{}1 KB & \textless{}1 MB & \textless{}512 MB & \textless{}1 GB & \textless{}1 GB \\ \hline \multirow{2}{*}{Cryptography} & \multirow{2}{*}{ECC-160/224} & \multirow{2}{*}{ECC-224/256} & ECC-256/384 & ECC-384/512 & ECC-384/512 & ECC-384/512 \\  & & & RSA-2048/3072 & RSA-2048/3072/7680 & RSA-2048/3072/7680 \\ \hline Key Exchange & ECDH & ECDH & ECDH/DH & ECDH/DH & ECDH/DH \\ \hline Enc/Dec & AES-112/128 & AES-128/192 & AES-128/192 & AES-192/256 & AES-192/256 \\ \hline Hash & MD5/SHA-1 & SHA-1 & SHA-2/SHA-3 & SHA-2/SHA-3 & SHA-2/SHA-3 \\ \hline Signature & ECDSA & ECDSA & ECDSA/DSA/RSA & ECDSA/DSA/RSA & ECDSA/DSA/RSA \\ \hline \hline \end{tabular}
\end{table} 
Table 8: Recommendations on cryptographic primitives to be used at different IoT components [160]. and authenticates the Initiator. Next, the Responder computes the \(K_{DH}\) using the Initiator's DH public value \(DH_{I}\). Finally, the Responder replies with an R2 message that includes a signed MAC calculated with the \(K_{DH}\) confirmation. Hence, a shared secret is established between HIP peers. Figure 18: HIP-Based Exchange (HIP-BEX). In HIP-BEX, both the Initiator and the Responder have to perform resource-intensive cryptographic operations involved in the computation of DH public and session keys. As shown in Figure 18b, modular exponentiation operations, such as \(g^{a}\pmod{p}\), \(g^{b}\pmod{p}\), and \(g^{ab}\pmod{p}\), have the highest computation overhead on the IoT device. Additionally, there are computation costs for signature generation and verification that cannot be ignored for highly resource-limited devices.