## 5 Conclusions and Future Work  
Our first goal in writing this review was to help our research team to understand hardware security for IoT systems. This is from the perspective of IoT devices, as first shown in Figure 2, and their communication technologies. Moreover, this review explains how IoT communication networks support the CIA triad, by implementing either traditional symmetric or asymmetric encryption algorithms. It also reviews lightweight adaptations of these schemes, or completely new algorithms, such as in [2; 18; 22]. Below are some lessons learned, followed by an example application for IoT practitioners. * **Implement encryption-only functions at the device. ** For the smart device and the link between the device and the gateway, it simplifies the computation at the device if it supports only the encryption operation. This is practical because, in many IoT systems, the device sends data in the uplink. In this way, even if the device needs to receive encrypted data, a server or base station can use the decryption operation, as in the over-the-air-authentication in LoRa when the Join Server sends a Join Accept message encrypted using the AES-128 ECB decrypt operation. When the device receives the data, it applies the corresponding encryption operation to recover the plaintext. This can be a good approach to reducing the IoT device's complexity. * **Evaluate link layer security based on how private or how public your network is. ** Some studies, such as [21], argue that in most cases the link between the smart device and the gateway at the edge network is a \"safe haven\", because it is in a protected physical site or a private network. Therefore, security is extremely important in the public domain network, or the commodity internet, that connects the gateway to the application server in the cloud. While this applies to some manufacturing and energy utility networks, not all IoT systems have a protected wireless network to operate on. Many IoT applications, such as Sigfox and Zigbee, support different levels of security. For instance, Sigfox supports clear mode or encryption mode, while Zigbee has multiple levels of security. Therefore, this last-mile link needs to be carefully evaluated to choose an appropriate security level to be implemented in this network. * **Hybrid block-stream lightweight ciphers are a promising solution for IoT. ** Table 3 presents lightweight block ciphers based on surveys that we reviewed. The most recent algorithm mentioned is from 2013 with SIMON and SPECK, which were created by the National Security Agency (NSA). PRESENT and CLEFIA are two standards that have been mentioned in several papers since they are included in the ISO/IEC 29192 lightweight cryptography standard. In current communication technologies for IoT, such as LoRa, C-UNB/Sigfox, and NB-IoT, we saw the dominance of AES-128 in CTR mode, which was created in the late 1990s. As described in this paper, there have been several efforts to implement lightweight versions of AES as hardware platforms, such as in FPGA, either to reduce gate area implementation, adopt smaller keys, or take fewer rounds to reduce its complexity. However, to the best of our knowledge, there is not much evidence of the widespread implementation of the lightweight encryption algorithms listed in Table 3. One possible reason is that stream ciphers are better suited to resource-constrained devices, as they encrypt bit by bit instead of in blocks of bits. In hardware, series operations can be implemented with fewer hardware resources (i.e., fewer registers or flip-flops) than parallel operations, although series operations are slower than parallel ones, as explained in Section 4.1.8. Hence, stream ciphers tend to have series-like implementations, whereas block ciphers resemble more parallel operations, with blocks of bits processed all at the same time. Although our survey did not cover stream ciphers, Trivium, Grain, and MICKEY are mentioned as popular stream ciphers.