## 6 Security Solutions
### Communication Security
#### 6.2.3 End-to-End Transport Security  
The application layer protocol CoAP [71] is primarily designed for resource-constrained devices. As such, most IoT devices adopt CoAP instead of HTTP for device-to-device communications [161]. CoAP runs on the connectionless UDP to achieve multicast supports, such as group communications, as well as to avoid packet fragmentation, loss, and re-transmission, and message delivery delays in lossy networks. CoAP relies on DTLS [35] to achieve authentication, key management, and connection protection. As shown in Table 10, various authentication protocols, such as pre-shared key, raw public key, and digital certificates, are supported by the DTLS. The conventional DTLS schemes require numerous message exchanges to set up a secure connection. As such, IoT devices that operate in a lossy network cannot adopt the DTLS schemes as-is. Various lightweight versions of the DTLS are proposed for the constrained devices and networks, which reduce communication and computation overheads from IoT nodes. In this section, first, we survey the DTLS-based security methods designed for IoT systems. Next, we provide an analytical comparison between these security systems. **Certificate-based DTLS:** Previous research [128] proposed a certificate-based DTLS scheme for mutual authentication. The proposed scheme uses X.509 certificate and relies on the RSA cipher suite for communication security. To achieve mutual authentication, communicating peers first exchange their certificates and then validate the authenticity of the certificates by using the RSA signature verification method. The proposed scheme ensures tamper-proof generation and storage of keying materials, such as RSA keys and X.509 certificates, with the help of a TPM chip [106] embedded with an IoT device. The TPM \begin{table}
\begin{tabular}{l l l c c c c c} \hline \hline
**Scheme** & **Approach** & **Key Exchange** & **I** & **R** & **S** & **CO** & **MR** & **CC** \\ \hline HIP-DEX [121] & Standalone & Elliptic Curve [PERSON] & \(\bigstar\)\(\bigstar\)\(\bigstar\)\(\bigstar\)\(\bigstar\)\(\bigstar\)\(\bigstar\)\(\bigstar\)\(\bigstar\) & \(\bigstar\)\(\bigstar\)\(\bigstar\) & \(\bigstar\)\(\bigstar\) & \(\bigstar\)\(\bigstar\) & Maximum \\ \hline Slimfit [120] & Standalone & Elliptic Curve [PERSON] & \(\bigstar\)\(\bigstar\)\(\bigstar\)\(\bigstar\)\(\bigstar\) & \(\bigstar\)\(\bigstar\)\(\bigstar\) & \(\bigstar\)\(\bigstar\)\(\bigstar\) & \(\bigstar\)\(\bigstar\)\(\bigstar\) & \\ \hline HIP-PSK [122] & Standalone & Pre-Shared key & \(\bigstar\)\(\bigstar\) & \(\bigstar\)\(\bigstar\) & \(\bigstar\)\(\bigstar\) & \(\bigstar\)\(\bigstar\) & \\ \hline D-HIP [118] & Collaborative & Diffie Hellman & \(\bigstar\)\(\bigstar\)\(\bigstar\) & \(\bigstar\)\(\bigstar\)\(\bigstar\) & \(\bigstar\)\(\bigstar\) & \(\bigstar\)\(\bigstar\) & \\ \hline HIP-TEX [119] & Collaborative & Public Key & \(\bigstar\)\(\bigstar\)\(\bigstar\)\(\bigstar\) & \(\bigstar\)\(\bigstar\)\(\bigstar\) & \(\bigstar\)\(\bigstar\)\(\bigstar\) & \(\bigstar\)\(\bigstar\)\(\bigstar\) & Minimum \\ \hline LHIP [126] & Standalone & Not Available & \(\bigstar\)\(\bigstar\)\(\bigstar\)\(\bigstar\)\(\bigstar\)\(\bigstar\)\(\bigstar\)\(\bigstar\) & \(\bigstar\)\(\bigstar\)\(\bigstar\) & \(\bigstar\)\(\bigstar\)\(\bigstar\) & Minimum \\ \hline \hline \end{tabular}
\end{table} 
Table 9: A comparison between HIP-based schemes. Notations used for the security properties are: I = Interoperability, S = Scalability, R = Resiliency, CO = Communication Overhead, MR = Memory Requirement, and CC = Computation Complexity. A security property can have three difference values: high (\(\bigstar\)\(\bigstar\)\(\bigstar\)\(\bigstar\)), medium (\(\bigstar\)\(\bigstar\)), and low (\(\bigstar\)). A value is assigned to a security property based on a HIP scheme’s performance to support that property. chip also provides hardware support for faster RSA operation.