On Wide-Area IoT Networks, Lightweight Security and Their Applications—A Practical Review

Abstract

The Internet of Things (IoT) allows users to collect sensor data, control devices, and analyze collected data over the Internet. IoT devices are located in diverse environments and support many applications. To protect IoT systems from cyber threats, Confidentiality, Integrity, and Authentication—the CIA triad—must be supported. However, IoT devices have limited energy and computational resources. Lightweight encryption algorithms have been proposed for IoT, and have been reviewed by previous studies. Some cover communication protocols, while others cover lightweight security or review the challenges in implementing a secure IoT system. The aim of this literature review is to combine the first two topics: communication protocols and lightweight security. They will be approached from a practitioner’s standpoint. Several applications are provided that help readers with a minor background in security to understand these technologies and which elements of the CIA triad have more priority. This paper describes wide-area IoT networks, such as LoRAWAN, Sigfox, and NB-IoT, and their security. It also describes applications throughout the world, and how to enhance their security by implementing emerging lightweight security—specifically, approaches to make well-known ciphers such as Advanced Encryption Standard (AES) and Elliptic Curve Cryptography (ECC) more lightweight.

1. Introduction

The concept of adopting the Internet of Things (IoT) in the industry emerged in 2010, although the definition of the IoT term was introduced in 1999, when radio-frequency identification (RFID) tags were used in supply chains [1]. The prevailing belief among the community was that IoT would be merely another acronym among others in computer networks. However, engineers who had experience in wireless sensor networks (WSNs) or embedded systems could identify their work as IoT. According to Ferrag [2], the research on IoT security received attention later, around 2014.

Each IoT device has a different function depending on the application domain. Each application domain, in turn, has a different security requirement. Traditional industries or new start-up companies advertise small-scale devices that can be utilized in several applications, such as asset tracking, surveillance, healthcare, environmental monitoring, and industrial control systems (ICS). The rapid advancement and growing adoption of IoT devices in several industries exceedingly require users to be familiar with such technologies to overcome the roadblocks of implementation in IoT application domains. Consequently, several questions need to be addressed: What are the requirements for a small-scale IoT device to operate? How can the device and its data be protected from malicious users? Which should come first—confidentiality, integrity, or availability (CIA triad) [3]—for different applications?

For instance, ICS systems are increasingly using IoT [4], such as in electricity production, transmission, and distribution [5]. They must reliably transfer data between field devices and control centers. Because they control physical processes, one can assume that the integrity and availability of the data and control commands are more important. On the other hand, confidentiality is more important in systems that carry sensitive information, such as healthcare.

Figure 1 illustrates the idea of how different applications (e.g., manufacturing, food industries, smart cities, transportation, logistics, energy, and healthcare) have different security requirements in terms of the CIA triad and safety, which can determine the type of IoT communication protocol and encryption features that it will support. This in turn can always be updated based on the latest technologies or modified security requirements.

1.1. IoT System Implementation Challenges

Every IoT application, either industrial or consumer, is subject to cyber security threats. False data injections (FDI) in industrial control systems can have large impacts on the physical processes [6,7]. Consumer devices are vulnerable to various attacks [8,9], such as surveillance video cameras, which can reveal sensitive information through unauthorized video recording and location tracking [10].

The term massive data is commonly applied to IoT, such as in the work by [5], which describes how smart meters and phasor measurement units (PMUs) use cellular communications to send their periodic reports to the control center. When all these data are transmitted over the Internet, a question arises as to how it is protected.

Security adds overhead, such as the extra delay in performing the encryption operation, extra messages to exchange keys, and the added bytes at the end of the message to provide integrity. An important question is whether this overhead impacts the availability and safety of these systems.

According to Schneier [11], cryptography is used to provide secrecy, authentication, and integrity. This is accomplished through protocols that define a series of well-defined steps that all the parties must agree to follow during the communication process. To provide secrecy, cryptographic protocols usually employ hybrid crypto-systems, which have symmetric and public-key encryption algorithms.

Symmetric algorithms use a session key to encrypt the plaintext and decrypt the ciphertext. In public-key algorithms, each node has a key pair, one public and one private. The public key can be sent to other nodes, which they use to encrypt the plaintext. Only the node that has the corresponding private key can decrypt the ciphertext. Most of the time, public-key algorithms are used to safely distribute the session key (some call this key encipherment), and the regular exchange of messages uses symmetric encryption. In addition, these hybrid crypto-systems generate digital signatures or message integrity codes (MICs) to ensure the authenticity of the parties and the integrity of the data.

However, hybrid crypto-systems in IoT devices are a challenge because these devices have limited power, memory, and computational resources [12]. For example, public-key encryption is a mathematically demanding encryption scheme with a high computational cost [13]. Additionally, cryptographic protocols require large keys, which require memory and computing to store and generate keys. To distribute keys, encrypt plaintext, decrypt the ciphertext, and verify digital signatures, we require time, which causes processing delays that can impact the physical process being monitored or controlled. For all these reasons, lightweight cryptographic protocols are necessary to protect IoT systems from malicious users while utilizing as few of the end device’s resources as possible.

1.2. Current Work Contributions

This paper reviews the latest lightweight security schemes for IoT by stressing the context behind the IoT applications and their priorities in terms of the CIA triad. These will help the reader to understand IoT’s multifold security algorithms, especially the lightweight versions of standard ciphers such as Advanced Encryption Standard (AES) and Elliptic Curve Cryptography (ECC). They will be explained in a clear, practical way, through the viewpoint of:

• The IoT device, its communication protocols, and security features;
• The application domain and how each application adopts the security features.

In other words, the focus of this review is on the device, its hardware and firmware, the security keys that are programmed in the device, and the network to which it is connected. There are different aspects of hardware security that can be addressed, from the design, manufacturing, and creation of the embedded system with a microcontroller, field programmable gate array (FPGA), and printed circuit board (PCB), as shown in Figure 2. The focus is the customer end of the device creation, as shown on the right side of Figure 2. This is when the node becomes ready to be connected to a network, and be a part of an IoT system.

Another significant contribution of this work is to review lightweight security protocols based on well-established encryption algorithms, considering different application domains or types of industries. Additionally, this paper considers IoT systems that cover long distances. As a result, the smart devices can be placed in diverse environments. For this reason, the infrastructure and security solutions of a few low-power wide-area networks (LPWA) are explained, in addition to how they are used in different industries around the world.

In summary, these are our main contributions:

• Apply the CIA triad to explain standard communication protocols as well as lightweight cryptography, in different application domains. The goal is to explain a few protocols in detail while focusing on low-energy and long-range communication technologies.
• Provide a tutorial on IoT lightweight security that is accessible to even non-technical readers. This will illustrate the trade-offs of different protocols for different applications, and provide a good foundation for IoT communications.
• Explain and classify lightweight security approaches for AES and ECC algorithms. They are compared to older security techniques, in terms of primitives such as key sizes, number of encryption cycles, and hardware architectures.
• Bridge the gap between hardware and application developers, telecommunication providers, and customers, on the topic of IoT security’s operational priorities and how to apply lightweight security protocols. The main goal is to promote innovation towards the widespread implementation of open IoT systems.

In 2012, in the early days of IoT, the vision of an open IoT eco-system was introduced. It means a system in which different companies or entities contribute to the system’s different parts. It was first described in [13], which is one of the earliest reviews on IoT. It explains the main characteristics of an IoT system, such as device heterogeneity, scalability, and energy-optimized solutions.

The remainder of this paper is organized as follows. A detailed literature review of IoT and lightweight security is provided in Section 2. Section 3 reviews and explains the communication protocols and security features of three LPWA communication protocols and their security capabilities. Section 4 presents recent studies that make cryptographic protocols more lightweight, mostly at the hardware level. To conclude this paper, Section 5 discusses some lessons learned from this review and future work.

2. Literature Review on IoT and Lightweight Security Protocols

This section provides a detailed review of previous studies on IoT and lightweight security protocols. First, a brief background on the IoT network architecture has been provided to make understanding the details of each work easier. Subsequently, this section reviews related work in the field of IoT and security. In particular, the review presented in this paper focuses on communication protocols and lightweight security, which spans three different categories of related work, namely:

Category 1: standardized communications protocols for IoT;

Category 2: lightweight solutions for IoT;

Category 3: the challenges, trends, and requirements in implementing a secure IoT system.

The first category focuses on surveys about standardized communication protocols for IoT, from the application to data link and physical layers of the network stack. The second category covers research studies that describe or propose lightweight encryption and authentication solutions for IoT. The last category is concerned with analyzing the research papers that discuss the challenges and the requirements in implementing IoT in different fields. For these reasons, the communication protocols and lightweight algorithms that will be addressed later in this study are positioned against these three categories of related work.

More specifically, this paper concentrates on providing a review of previous studies on IoT and lightweight security protocols and it directly relates to the first two categories, noting that the research works developed for these two categories also serve as input to the third category of related works.

For each category,

Table 1. Standardized protocols for IoT.

Reference	Year	Topic
Liyanage et al. [14]	2020	Discusses the evolution of IoT, the taxonomy, and proposed architectures, probes the various efforts for the standardization of IoT, and illustrates some IoT applications.
Florea et al. [15]	2017	Discusses application layer protocols (CoAP, MQTT), service discovery protocols (mDNS, DNS-SD, uBonjour), infrastructure protocols (IEEE 802.15.4, 6LoWPAN, LoRaWAN), and smart home systems with wireless sensors and robot assistants that use IEEE 802.15.4, 6LoWPAN, CoAP.
Dragomir et al. [16]	2016	Standardized IoT communication protocols are explained in detail, with analysis of their security in terms of integrity, confidentiality, authentication, and protection against replay attacks.
Deshmukh et al. [17]	2017	Communication protocols at each OSI (Open Systems Interconnection) layer. Briefly describes a few communication protocols used for IoT and whether they support security at the respective layer.
Ferrag et al. [2]	2017	Review of forty authentication protocols in four environments, M2M, IoV, IoE, and IoS, that are evaluated under thirty-five attacks. Countermeasures and formal security verification techniques are also addressed.
Malik et al. [18]	2019	Secure key generation and distribution (or key bootstrapping) in the context of IoT applications and constrained devices. With a focus on low-power and short-distance technologies, it reviews how public-key algorithms and authentication protocols are being adapted for IoT.
Dizdarevic et al. [19]	2019	Application layer protocols for IoT in the context of specific challenges in fog and cloud computing integration.
Glaroudis et al. [20]	2020	Discusses IoT application protocols—MQTT, CoAP, XMPP, AMQP, DDS protocol, including HTTP-based applications, and the WebSocket protocol—within the context of IoT systems in agriculture, which must be reliable.

,

Table 2. Lightweight solutions for IoT.

Reference	Year	Topic
Khan et al. [21]	2021	Discusses the idea of proxy re-encryption, where nodes at the edge networks can apply more robust security algorithms. Introduces end-through-nodes-to-end security. Compares several lightweight solutions.
Agrawal et al. [22]	2019	Reviews seventeen lightweight authenticated encryption (LAE) algorithms dating back to 2010. The algorithms are compared in terms of hardware implementation and software speed.
Singh et al. [23]	2017	Compares lightweight block ciphers and hash functions in terms of the number of rounds, key size, and block size. Introduces primitives that evaluate whether an encryption algorithm is lightweight.
Lara-Nino et al. [24]	2018	Explains the foundations of ECC in detail. Reviews ECC solutions that are suited for IoT devices. Defines criteria to identify if an ECC algorithm is lightweight or not.
Gunathilake et al. [25]	2019	Reviews practical and theoretical lightweight cryptography (LWC). Several block ciphers are compared against AES. Moreover, they review papers about the security of LoRaWAN.
Nabeel et al. [26]	2019	Advantages and drawbacks of lightweight hash function families. A comparison of permutations and transformation functions used in different lightweight hash families.
Patil et al. [27]	2020	Discusses baby monitoring camera security. Algorithms such as AES, PRESENT, and an ECC-based algorithm are presented as lightweight solutions for these systems.
Cazorla et al. [28]	2013	Very useful overview of seventeen lightweight block ciphers, potential attacks against them, and a comparison of their memory requirements and performance (cycles/byte).

and

Table 3. Papers about challenges and requirements in implementing IoT.

Reference	Year	Topic
Nguyena et al. [29]	2015	Challenges and requirements in building a secure IoT system. A taxonomy of different security protocols proposed for wireless sensor networks and IoT with respect to key bootstrapping mechanisms.
Noor and Hassan [30]	2019	State of IoT security research, relevant tools, and modeling tools and simulators. The challenges in applying security mechanisms in IoT.
Rachit et al. [9]	2021	Compares protocols and standards used in IoT. Overview of the latest security research trends for IoT security.
Frustaci et al. [31]	2018	How to design IoT security. A taxonomic analysis from the perspective of IoT system model: perception, transportation, and application layers.
Hou et al. [32]	2019	A three-dimensional approach to IoT security, i.e., one-stop, multi-stop, and end application dimensions.
Patel and Doshi [33]	2019	IoT applications in different fields. IoT architecture layers, security requirements, and threats related to each layer.
Deep et al. [34]	2020	The security and privacy issues in IoT systems at each layer in the protocol stack, with challenges, existing security solutions, and key distribution.
Hamad et al. [35]	2020	Cloud-based IoT security and applications. Security requirements in terms of access control, integrity, and authentication.
Serror et al. [36]	2021	Assessment of the security challenges for industrial IoT, including vulnerabilities, risks, threats. Mapping of existing solutions and challenges.
Dehghantanh et al. [37]	2019	Overview of cybersecurity and digital forensic challenges related to big data and IoT. A cyber defense triage process for IoT infrastructure.
Xu et al. [38]	2014	IoT from the perspective of industrial applications. The technologies used in industries: identification, service management, and access.
Miorandi et al. [13]	2012	One of the earliest IoT surveys. Overview of IoT, where it can be used (application fields or services), and the technologies that enable these services.

indicate the reference, the publication year, and the topics discussed in each study. Additionally,

Table 4. Lightweight solutions for IoT.

Block Cipher	Year	Block Size (Bits)	Key Size (Bits)	Rounds	Cazorla [28]	Agrawal [22]	Singh [23]	Khan [21]	Gunathilake [25]	ISO Std
SPECK	2013	64	96	26		✓		✓	✓
SIMON	2013	64	96	26		✓		✓	✓
TWINE	2013	64	80/128	36	✓		✓	✓	✓
KLEIN	2012	64	64/80/96	12/16/20	✓
LED	2011	64	64/128	32/48	✓			✓	✓
LBlock	2011	64	80	32	✓				✓
Piccolo	2011	64	80/128	25/31	✓				✓
KATAN and KTANTAN	2009	32/48/64	80	254	✓
PRESENT	2007	64	80/128	31	✓	✓	✓	✓	✓	✓
CLEFIA	2007	128	128	18	✓	✓				✓
DESL and DESXL	2007	64	184	16	✓		✓
HIGHT	2006	64	128	32	✓		✓	✓	✓
mCrypton	2006	64	64/96/128	12	✓
IDEA	2006	64	128	85	✓
NOEKEON	2000	128	128	16	✓
SKIPJACK	1999	64	80	32	✓
AES	1998	128	128/192/256	10/12/14	✓	✓	✓	✓	✓
TEA and XTEA	1997	64	128	64	✓		✓	✓
RC5	1995	64	128	1–255			✓		✓

focuses on lightweight encryption algorithms—more specifically, symmetric block ciphers—that have been proposed for IoT devices.

2.1. Building Blocks

Figure 3 shows an IoT system’s building blocks: end nodes such as sensors/actuators; base stations or gateways; central servers, also known as network servers; and cloud applications. It shows how an IoT system sends its small data packets from the IoT device to the user application in the cloud.

Base stations and network servers are located in an IP-based core network and are connected to each other through back-haul links [39], such as point-to-point Ethernet or multi-protocol layer switching (MPLS) links or wireless links such as cellular, microwave, or satellite. When receiving data packets from the end nodes, the network server’s responsibility is to check the packets’ integrity. If the end node is not an intruder, it also removes duplicate packets. This server then sends the packet to an application server that users access through the internet. For download packets, the network server stores data from the user application to later send them to the end devices.

In most IoT systems, downlink transmissions are delay-tolerant and do not represent the typical data flow; therefore, security on the uplink is emphasized, i.e., from device to cloud. In the example network shown in Figure 3, the communication networks that provide connectivity to the sensors and actuators are located in outdoor fields or large industrial areas, such as low-power wide-area (LPWA) networks. Reviewing their physical, data link, and network layer protocols will allow us to understand their security protocols.

Cloud services consist of software applications that analyze the data collected by an IoT system, provide visual user-friendly information on the real-time status of the system, and, in some cases, send control commands back to the actuator end nodes [6]. They provide data storage and computational resources, thus reducing the need for computation at the end nodes [40]. This is also true for the base station and network server nodes, as they have more resources than the end nodes and can be used to provide security at different segments of the network. Many papers refer to the base station/gateway and network server as devices located in edge and fog computing [19,21] nodes, respectively.

Although cloud services, which are located in remote networks, provide opportunities for security threats, this topic is not addressed in detail in this review. More details on cloud services can be found in a collection of studies on the issue of big data and privacy [37]. These studies cover the problem of the large volume of devices, which generate lots of data, and how to protect the privacy of these data. They also address how to ensure the authenticity of the data and the device and who can access the data.

2.2. Standardized Protocols for IoT

Table 1 presents a summary of eight studies that discuss standardized protocols for IoT. Next, the main contributions of each paper are summarized.

Liyanage et al. [14] focused on IoT security and emphasized the recent research on authentication. They explained in detail the architecture of IoT and its layers. They reviewed a three-layered architecture that includes, from the bottom, the perception, network, and application layers. The perception layer includes the sensors and devices and how they are connected, while the network layers offer services such as routing, data encapsulation, and service discovery. The application layer includes protocols to support requests/responses, publish/subscribe exchanges, and RESTful interfaces (where REST stands for representation state transfer and is commonly used for machines and computers to retrieve data on a Web server). The application layer also uses transport layer protocols such as a transmission control protocol (TCP) and user datagram protocol (UDP). They can provide security with a transport layer security (TLS) protocol.

In addition, Liyanage et al. [14] described different IoT applications and classified them either as collaborative aware (e.g., smart home, smart city, industrial internet) or information aggregation (smart energy, healthcare, wearable devices). As an IoT use case, they described a smart home system with wireless sensor nodes and robot assistants that use communication standards such as IEEE 802.15.4, 6LoWPAN, and a constrained application protocol (CoAP). However, security is addressed concisely in their paper.

Similarly referencing a layered architecture, Florea et al. [15] reviewed standardized protocols for IoT, according to the layers that they operate:

• Data link layer protocols such as IEEE 802.15.4 and long-range WAN (LoRaWAN).
• Network layer protocols such as 6LoWPAN, which allows devices to connect to IPv6 routers with compressed IP headers.
• Application layer protocols: they compare CoAP, which runs over UDP, and message queuing telemetry transport (MQTT), which runs over TCP.
• Domain name service (DNS) protocols translate between a domain name and an IP address since smart devices can join and leave the network at any time. Multicast domain name service (mDNS) supports multiple devices in the same DNS query, DNS service discovery (DNS-SD) discovers devices that provide a certain service, and UBonjour combines mDNS and DNS-SD.

Dragomir et al. [16] analyzed security requirements such as confidentiality, origin authentication, integrity, and protection against replay attacks, and how these are supported by standardized protocols. They focused on communication protocols for IoT at different layers of the protocol stack. The physical and data link communication protocols surveyed include IEEE 802.15.4, Bluetooth Low Energy, Zigbee, Wi-Fi, Near Field Communications (NFC), LoRaWAN, and Z-Wave. At the network layer, they reviewed 6LowPAN and IP Security (IPSec). They also reviewed application layer protocols such as CoAP, MQTT and Advanced Message Queueing Protocol (AMQP), eXtensible Messaging and Presence Protocol (XMPP), and how they can be integrated with transport layer security protocols, such as TLS or Datagram TLS (DTLS), in the case of CoAP, which runs on UDP.

They also addressed a full IoT protocol stack called Thread, which is owned by a consortium of industries including Google and ARM. The authors conclude that some protocols, such as IEEE 802.15.4 and LoRaWAN at the lower layers and CoAP and MQTT at the application layer, are better for resource-constrained devices. However, they proposed two points as future works that require the analysis of these standard protocols considering other security requirements, such as resilience and understanding how the security features of each protocol “transfer to practical applications” [16], which is addressed in this review.

Deshmukh and Sonavane [17] provided a brief comparison of communication protocols such as IEEE 802.15.4, 6LoWPAN, and IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), and security mechanisms available to protect these standards at each layer of the communication stack. They briefly mentioned security parameters based on the CIA triad for each layer, but no specific protocols are mentioned at all layers except for the 6LoWPAN adaptation layer.

Ferrag et al. [2] provided a comprehensive and systematic review of recent studies on authentication protocols for IoT in four environments: Machine-to-Machine (M2M), Internet of Vehicles (IoV), Internet of Energy (IoE), and Internet of Sensors (IoS). First, they surveyed a large number of studies published between 2010 and 2016 and discussed them in chronological order. Many reviews about the security of IoT systems started being published between 2014 and 2015. Second, they described several types of cryptosystems that are being used for authentication. Among them, some use Elliptic Curve Cryptography (ECC), an asymmetric encryption system that has a public and a private key and can be used for M2M, IoV, and IoS authentication and key distribution. Finally, they described more than forty authentication protocols that provide authentication in those four IoT scenarios, and compared their advantages and limitations. Most of the schemes are not standardized and they cover specific tasks, such as what happens in the registration phase when the smart device joins the network. The schemes surveyed were not necessarily lightweight schemes.

Malik et al. [18] addressed the issue of security key generation and distribution among IoT devices, which are known as key bootstrapping methods. This study focused on public-key cryptography, which, they argued, is more scalable and provides more protection against cyber threats. Traditional key bootstrapping algorithms, such as IP security/Internet Key Exchange (IPSec/IKE), TLS, or DTLS, require a lot of resources from IoT devices. Thus, they reviewed key bootstrapping in the context of IoT applications. First, they analyzed the standard IoT security protocols, layer by layer:

• IEEE802.15.4 at the physical/data link layer, which does not specify a key management protocol.
• IPv6LowPAN, which they reference as an adaptation layer that allows IPv6 packets to be carried over IEEE 802.15.4 frames.
• IPv6 Routing Protocol for Low Power and Lossy Networks (RPL) is the routing protocol at the network layer, along with its two security modes: preinstalled keys, or authenticated mode, where nodes such as routers obtain keys from a certification authority (CA).
• CoAP at the application layer and DTLS, which has different authentication modes, such as pre-shared keys, raw public keys, and certificate mode. When COAP is used with DTLS, it is recommended to use raw public keys, which means that the public keys are pre-programmed in the devices at the time of manufacturing. All devices in the same network know the other devices’ public keys.

Second, the study [18] classified several new proposals based on the key delivery mechanism and the authentication modes, such as raw public key, certificate-based vs. certificate-less, and identity-based. Most of the new protocols are lightweight versions of existing protocols, such as Diffie–Hellman and ECC (ECDH) for key agreement, or some type of compression, such as the new idea of using implicit certificates, where all components of a certificate are superimposed on each other. Among them, the Elliptic Curve Qu-Vanstone (ECQV) is a common type of implicit certificate.

Dizdarevic et al. [19] presented a review of communication protocols in the application layer, including MQTT, AMQP, XMPP, Data Distribution Service (DDS), HTTP, and CoAP. They addressed specific challenges in the context of fog and cloud computing.

A similar emphasis on application layer protocols is given in [20], which investigated test results obtained in 2017–2020 for IoT applications that use MQTT, CoAP, XMPP, AMQP, DDS, the Representational State Transfer (REST) interface using HTTP, and the WebSocket protocols. However, they focused on agricultural IoT applications, such as precision farming. It is very relevant to this review because it illustrates how IoT communication protocols and their security are used in different applications. According to [20], “effective throughput and reliability are of major importance for smart farming since unreliable data can lead to inaccurate decisions and inappropriate automated procedures.” Thus, when the CIA triad is considered, it shows that data integrity and availability (which are related to the reliability of the system) are the highest-priority factors for smart farming applications. The authors analyzed the application layer protocols by using performance indicators such as latency, energy and bandwidth requirements, throughput, reliability, security, and developers’ preferences. They concluded that MQTT outperforms the others and is, at the same time, the most deployed application protocol for the IoT farming systems that they reviewed. MQTT runs over TCP protocols, which are very reliable, and re-transmits messages that are lost or corrupted. For security, MQTT would have to use TLS, which is heavy for constrained devices and is probably not adopted in most of the applications reviewed. One application protocol that is considered the most secure is XMPP, which includes a built-in TLS protocol, and also has a dedicated authentication function called the Simple Authentication Security Layer (SASL) that verifies a device’s credentials. However, according to the study [16], XMPP is recommended for gateway nodes, not smart devices.

In summary, some trends can be observed in these studies, with concern the types of communication technologies used at the device level. Thus, Figure 4 shows the distribution of protocols by layer. These observations are from the eight studies previously reviewed and represent commonly adopted technologies in IoT:

• For the physical and data link protocols that are described in Table 1, it can be concluded that IEEE 802.15.4 and LoRaWAN are the most adopted protocols. For instance, IEEE 802.15.4 has been described in five of the eight papers, i.e., around 24% of the papers. IEEE 802.15.4 is a good example of short-range IoT and LoRaWAN for long-range applications. Moreover, the IEEE 802.15.4 security architecture provides a foundation for other protocols, such as Zigbee, BLE, and LoRaWAN.
• At the network layer, the consensus is 6LoWPAN as the main protocol used in the adaptation layer. The routing protocol RPL is mentioned in a few studies, but not as often as 6LoWPAN.
• At the application layer, there is a close tie between CoAP and MQTT. Although it is shown in Figure 4 that the percentage of CoAP is slightly higher, several studies, such as [27], which described a more specific application domain, mentioned that MQTT is definitely one of the most popular application layer protocols for IoT.

2.3. Lightweight Solutions for IoT

Table 2 contains a summary of seven studies that describe or propose lightweight solutions for IoT. Beginning with Khan et al. [21], their study is about the IoT communications model:

• Smart devices such as sensors and actuators.
• Edge computing networks are composed of smartphones, Wi-Fi routers, or LoRa gateways. They support device mobility and process data closer to the smart device.
• Fog computing networks have more powerful routers, industrial switches, and servers.
• Cloud computing components such as the Amazon Web Services (AWS) cloud platform, where data are stored, visualized, and analyzed.

At different levels of this IoT communication model, security protocols must be adapted to support the different capabilities that the communication equipment has. For example, a gateway in the edge computing system has more processing power and energy to run encryption algorithms than a sensor node. They also use the term constrained networks, such as a private network inside an organization where smart devices are located. These networks may not require robust security algorithms, whereas security requirements increase as the data become close to the edge, fog, and cloud computing, i.e., towards unconstrained networks and the public internet. Thus, the authors review previous works on the idea of proxy re-encryption, where edge nodes act as proxy nodes and re-encrypt the data with more secure algorithms. They name this an end-through-nodes-to-end security model, where smart devices use lightweight encryption protocols, and then the edge nodes use more robust encryption protocols. This is one important relation to this paper because the authors take into account the issue of device’s resource asymmetry (i.e., depending on where the device is located in the IoT communication model) as an essential requirement for IoT security.

Additionally, Khan et al. [21] compared several new solutions for lightweight cryptographic algorithms and their advantages, drawbacks, and vulnerabilities, followed by an analysis of their security features in terms of the CIA triad. For example, one of the solutions analyzed uses a mix of encryption algorithms such as the Elliptic Curve Discrete Logarithmic Protocol (ECDLP) to generate the session key, the Diffie–Hellman (DH) public/private key algorithm to distribute the session key, and the Tiny Encryption Algorithm (TEA) as the symmetric algorithm to encrypt the actual data packets with the session key. According to the study by Khan [21], it prevents the issue of key equivalence attack of TEA, but it adds complexity because it requires periodic updates of the private key.

Agrawal et al. [22] reviewed lightweight authentication encryption (AE) algorithms, which provide both confidentiality and integrity by encrypting the data and creating a hash value. This hash value can be called a message authentication code (MAC) or message integrity code (MIC). For traditional computer applications, the standard that provides authenticated encryption is Advanced Encryption Standard-Galois/Counter Mode (AES-GCM) [41]. Although there are standards for lightweight encryption algorithms, such as ISO/IEC 29192’s block ciphers—PRESENT, CLEFIA, and LEA—the authors argue that there are no standards for lightweight AE algorithms. Nonetheless, the authors compare a variety of AE schemes dating back to 2010. In particular, these are algorithms proposed at the 2014 Competition for Authenticated Encryption: Security, Applicability, and Robustness (CAESAR). Their types vary: some are based on (a) sponge functions (or key-less algorithms), (b) stream ciphers, (c) block ciphers, and (d) hash functions. Then, the performance of these different AE algorithms is compared in terms of hardware implementation (e.g., gate equivalent area, power consumption) and software speed (e.g., number of CPU cycles per byte).

Singh et al. [23] defined the primitives that make an encryption algorithm lightweight and presented examples of lightweight cryptographic algorithms, such as block ciphers and hash functions. Several block ciphers were compared in terms of key size, block size, and the number of rounds. PRESENT, the ISO/IEC 29192 standard, is presented as one having a 64-bit block size and simpler substitution round, using a 4-bit substitution box (S-Box) or lookup table. In addition, they discussed solutions for symmetric and asymmetric lightweight algorithms for IoT. For asymmetric algorithms or public-key cryptography, Elliptic Curve Cryptography (ECC) is recommended for IoT systems because it requires a smaller key size (160 bits) compared to traditional algorithms such as Rivest, Shamir, Adleman (RSA) keys (1024-bit). Finally, they provided a high-level example of a sensor in a smart home and a flowchart on how to decide which encryption algorithm to adopt based on the sensor’s battery, memory space, and computational power.

Lara-Nino et al. [24] discussed Elliptic Curve Cryptography (ECC) in the context of lightweight solutions, or Elliptic Curve Lightweight Cryptography (ECLC). ECC security relies on the difficulty to solve the Elliptic Curve Discrete Logarithm Problem (ECDLP). To make an ECDLP difficult to solve, there are certain properties that standardized elliptic curve functions have. However, their implementations are not feasible for resource-constrained devices. The authors reviewed elliptic curves that are better suited for IoT devices. They presented the types of applications in which ECLC algorithms are implemented, such as e-health, wireless sensor networks, and the smart grid. They also specified the criteria for ECC-based systems to be classified as lightweight. Finally, they proposed a design methodology that guides the implementation of ECLC solutions.

Gunathilake et al. [25] described state-of-the-art Lightweight Cryptography (LWC) and how it can improve the security and privacy of IoT devices with low processing, battery, and memory resources. First, it classifies LWC in terms of lightweight block ciphers, lightweight stream ciphers, lightweight hashes, high performance systems, and low-resource devices (similar to the primitives in Singh’s paper [23]). As lightweight stream ciphers, they mention the Grain v1, MICKEY v2, and Trivium algorithms. For block ciphers, they indicated that CLEFIA and PRESENT are promising block ciphers for IoT applications. In a comparison table of LWC with traditional AES, the authors ranked the security of several block ciphers. In this comparison, the RC5 algorithm, with a 64-bit block size and a 128-bit key, ranked the most secure against software vulnerabilities, while PRESENT, with a 64-bit block size and an 80-bit key, ranked second considering hardware vulnerabilities. They also reviewed practical papers that analyze the security of LoRaWAN, such as proposals to reduce the power needed to run the encryption operations in LoRa motes, improve its key management scheme, or modify AES to use less memory.

Nabeel et al. [26] reviewed several lightweight hash function families, their contributions, and their drawbacks. Among them, there is a hash function using the advanced encryption standard (AES). However, these functions require fixed-size data blocks, which is not recommended for IoT because of the small blocks of data that IoT devices typically send.

Patil et al. [27] discussed the security of smart gadgets such as baby monitoring cameras, by focusing on their vulnerabilities. They cited several attacks in which the main security flaws are weak passwords or the use of the default password that comes with the embedded device when purchased. In addition to the weak authentication scheme, most of these systems lack an encryption protocol and have vulnerabilities in their Web applications. Then, the authors described in detail lightweight encryption algorithms that could be implemented to protect such systems, such as AES, PRESENT, and their own scheme based on ECC. In particular, the block cipher algorithm PRESENT [42] is clearly explained in Patil’s paper [27] and can be a good candidate for such gadgets.

An excellent overview of several lightweight block ciphers is presented in [28]. The authors described each algorithm very clearly and succinctly. They also provided references to cryptanalysis (or cyberattack) attempts to break these algorithms. One of them in particular, the IDEA lightweight block cipher, has no known cyberattacks or vulnerabilities. However, others, such as KLEIN, SKIPJACK, and Noekeon, were considered “risky”. Overall, they concluded that all the other block ciphers described in their paper provide good security to sensor nodes. Then, they analyzed the algorithms in terms of memory requirements and performance in cycles per bytes by implementing an embedded C code for the MSP430 microcontroller from Texas Instruments. The smallest read-only memory (ROM) requirement was for TEA and XTEA, while the KATAN family had the largest memory requirement. For performance, and taking into account code size and number of cycles, they concluded that Piccolo, TWINE, XTEA, and AES had the best performance among the seventeen algorithms surveyed.

To show most of the lightweight block ciphers in chronological order, Table 3 lists all block ciphers surveyed by [28] and other Type 2 papers summarized in this section. It also includes information about them, such as the block size, key size, and the number of rounds. For a good overview of each one of them, the algorithms are well explained in [28].

2.4. Challenges and Requirements in Implementing IoT

Table 4 presents a summary of several research papers that overview the challenges and the requirements in implementing IoT. Next, the notable points of each one of these papers are summarized.

Nguyena et al. [29] presented an overview of the challenges and requirements in building a secure IoT system. They gave a taxonomy and compared different security protocols proposed for wireless sensor networks and IoT with respect to how they employ key bootstrapping mechanisms. They provided a review of ongoing research initiatives in the field of security for IoT, which they categorized into two types: solutions that rely on asymmetric key schemes (or public-key encryption) and key management solutions that pre-distribute symmetric keys.

Noor and Hassan [30] reviewed the development of IoT security research from 2016 to 2018. In particular, they discussed the challenges in applying security mechanisms in IoT and its attack vectors.

Another study by Rachit et al. [9] identified the latest security risks for IoT systems. It first described some communication protocols at various layers of the protocol stack, from Bluetooth Low Energy (BLE) at the physical/data link layer to MQTT at the application layer, and their security features and vulnerabilities. The security attacks described in the paper are classified in terms of protocol-based attacks, such as pre-shared key attacks and sniffing attacks, or data-based attacks, such as hash collision (to attack the integrity of the data) and denial of service (to attack the availability of the data or service), but no particular application is referenced. They also compared other research works in terms of confidentiality, integrity, and availability, but these works and techniques are presented only at a high level. In particular, one new method uses ECC and fully homomorphic encryption (FHE) to improve integrity, and another one uses MQTT and a Robot Operating System (ROS) to improve authentication for robotic systems in industrial settings. As future trends, the authors presented Artificial Intelligence (AI), blockchain, and Elliptic Curve Cryptography (ECC) as key technologies that should be integrated into IoT security schemes.

Frustaci et al. [31] discussed the current status and how to design IoT security. They reviewed the IoT security panorama, by providing a taxonomic analysis from the perspective of the three layers of the IoT system model: (1) perception; (2) transportation; and (3) application layers.

Hou et al. [32] investigated IoT security from data perspectives by combining the concept of IoT architectures with data life cycles. They proposed a three-dimensional approach to exploring IoT security with the one-stop, multi-stop, and end application dimensions. They also analyzed the latest developments in IoT security.

Patel and Doshi [33] studied IoT applications in different fields and IoT architecture layers, including basic functionalities, devices, protocols, and security threats at each layer. They also discussed topics on IoT security requirements and cyberattacks.

Deep et al. [34] investigated security and privacy issues in IoT systems at each layer in the IoT protocol stack, and they identified the underlying challenges and security requirements. A brief overview was given on existing security solutions to safeguard IoT systems at each layer.

Hamad et al. [35] reviewed cloud-based IoT security solutions and communication between IoT devices and applications from 2013 to 2019. They discussed open issues for securing cloud-based IoT systems. Then, they analyzed security requirements in terms of access control, integrity, and authentication.

Serror et al. [36] discussed security challenges for Industrial IoT of Internet 4.0. One important difference when using IoT in industrial settings is that the machines, or the equipment to be sensed or controlled, have a long life span. Most of them can last for more than ten years. Compared to the lifetime of a computer or a smartphone, ten years is a very long time. Some of these machines may not be compatible with newer operating systems or technologies, and their embedded software must be continually guarded and supported to ensure that the availability of the industrial system is not compromised. The authors also discussed the scale of the IoT systems in industrial settings. Thus, they described security goals and challenges in protecting such industrial systems, considering safety and production requirements.

Dehghantanha and Choo [37] tried to cover the problem of the large volume of devices, which generate lots of data: how to protect the privacy of these data; ensure their authenticity and which device generated them; and cloud security and who can access the data. Many papers in this collection focus on forensics, i.e., how to use data analytics to process large security logs to detect intrusions, and other topics related to data mining and cloud storage.

Xu et al. [38] explained IoT from the perspective of industrial applications. They reviewed different applications of IoT, such as healthcare, firefighting, mining industries, food services, and logistics and supply chains. They also reviewed at a high level some of the technologies used in these industries, such as identification technologies, communications and networking, service management, and access.

Finally, Miorandi et al. [13] provided a holistic view of IoT. They reviewed where it can be used (application fields or services) and the technologies that enable these services. Among the many topics addressed in [13], the security topic of public-key encryption was briefly noted and the authors acknowledged the high computational cost of such encryption schemes. It is worth mentioning their vision of an open IoT ecosystem in which different companies or entities contribute to the different parts of the system.

Using the knowledge gained from this literature review and the viewpoint of a practitioner, the direction that this paper will take is as follows:

-

Next, this paper reviews the physical and data link layer technologies and how they provide security given the type of application. The type of application field determines the IoT system’s security requirements in terms of what is more important to be provided: confidentiality, integrity, availability, and/or safety. After reviewing the first category of papers (Section 2.2), trends are identified regarding which communication protocols are being adopted for IoT systems. Among them, LoRAWAN, NB-IoT, and Sigfox are the physical and data link layer protocols that will be explained in detail in Section 3 from the point of view of the CIA triad and IoT applications. They have been cited in the first category of papers and are adopted in the industry.

-

Regarding the second category of papers, which showed a variety of new lightweight encryption protocols, Section 4 focuses on AES encryption and recent research studies that aim to make AES more suitable for IoT devices. AES is a popular algorithm for regular computer systems, and because it is such a well-established standard, it is practical to review how AES encryption is being adapted for IoT systems. Another encryption algorithm that has been mentioned in several category 2 and 3 papers is ECC, which is a public-key encryption algorithm typically used for key distribution that has great potential for industry; however, ECC is computationally intensive. Thus, Section 4 in this paper also discusses approaches to make ECC more lightweight for IoT systems.

3. Long-Range, Low-Power IoT Communication Protocols and Their Security

Although it has been observed in Section 2.3 that there are many lightweight encryption algorithms and some of them, such as CLEFIA and PRESENT, are part of standards such as ISO/IEC 29192, most IoT communication protocols use the Advanced Encryption Standard (AES) [43] to provide confidentiality, authentication, and integrity. A good example is the IEEE 802.15.4 physical and data link layer protocol. It provides seven security levels, based on AES-128, with 128-bit blocks:

• security level zero means no security;
• security levels one to three provide only integrity and authentication by generating different sizes of message integrity code (MIC);
• security level four provides only confidentiality and security;
• security levels five to seven provide integrity, authentication, and confidentiality.

In addition, other industry standards are based on IEEE 802.15.4, such as Zigbee and LoRaWAN [16].

AES is a symmetric cipher that encrypts data in blocks of 16 bytes or 128 bits. Different confidentiality modes of operation use AES as the cipher function. There are five modes of operation [44,45]: Counter mode (CTR), Cipher Block Chaining (CBC), Electronic Code Book (ECB), Cipher Feedback (CFB), and Output Feedback (OFB).

The AES-CTR mode, for example, is used in most standard IoT communication protocols, such as IEEE 802.15.4, to provide confidentiality. It does not require the plaintext data to be a multiple of the 128-bit or 16-byte block size. Therefore, it is good for smaller data packets. In the AES-CTR mode, the encryption and decryption functions are the same operations.

Here, we describe how AES-CTR mode works. First, each input block is a counter value T₁, T₂, ... T_n, where n is the number of blocks into which the plaintext has been divided (P₁, P₂, ... P_n). It is important that each counter value is different from any other [45], and also for the different inputs or plaintext. The AES encryption operations are then applied to each counter value and generate an output block O₁, O₂, ... O_n, as in Equation (1). Finally, a logical XOR operation is performed between the output block O_i and the plaintext block P_i to create the ciphertext block C_i, as in Equation (2).

O_i = AES128_encrypt(Key, T_i)

(1)

C_i = P_i XOR O_i

(2)

where T_i is the ith counter value and P_i is the ith plaintext block.

As explained in Schneier [11], “XORing the same value twice restores the original”. Thus, the same output block O_i can be used to decrypt the ciphertext using XOR. This is shown in Equation (3). Moreover, the same hardware or software is used to generate the output block because the same AES encryption function is used for encryption and decryption. This simplifies the security implementation in the IoT device.

C_i = P_i XOR O_i and P_i = C_i XOR O_i

(3)

There are also two other benefits to resource-constrained devices. The encryption of different blocks of data can be done in parallel and be pre-calculated since the counter values can be obtained in advance of the plaintext data [44,45].

On the other hand, the AES Cipher Block Chaining (CBC mode) is used to compute the message authentication code (MAC), or message integrity code (MIC). The AES-CBC mode is also known as AES cipher-based MAC (CMAC) mode [46]. In general, MIC is used to validate the integrity of the data at the receiving node, and MAC is used to ascertain the origin of data, but each can take both roles. The MAC or MIC is a one-way hash function that uses a secret key [11]. It is verified by the receiving node at the core network. For instance, the gateway node receives a frame from the sensor node, and then calculates the MIC using the received frame as input. If the calculated MIC value is the same as the MIC that was received with the frame, the packet is accepted.

According to [22], there are different approaches to providing authenticated encryption, which means to encrypt, authenticate the origin, and protect the integrity of the data. These steps can happen in different sequences:

• Encrypt-and-MAC (E&M), where the encrypted data and the MAC are generated independently.
• Encrypt-then-MAC (EtM), where the encryption is done first, and then the MAC is calculated using the encrypted data as one of the inputs.
• MAC-then-Encrypt (MtE), where the MAC is produced first, and then it is encrypted together with the rest of the data.

How are these approaches applied in IoT networks? To find out, this paper reviews three IoT communication architectures: LoRaWAN, NB-IoT, and Sigfox. To understand how they compare with other IoT communication protocols, Figure 5 shows a comparison of the different communication networks in terms of distance, data rate, and how much power they consume. This paper addresses the security of low-power wide-area networks (LPWA), which are in the upper left quadrant.

Typical applications of short-distance communication networks, such as RFID, IEEE 802.15.4, Zigbee, and BLE, are IoT systems in smart buildings, homes, and factories. Other short-distance communication technologies such as Wi-Fi and 5G are not considered low-power but they are widely used in these smart home/building scenarios and industrial environments.

Long-distance and low-power applications are well suited for IoT projects for smart cities, agriculture, transportation, and energy utilities. The distance factor makes security even more important since the IoT devices are placed over a large geographic area. The low data rate means that these devices save energy by sending small packets.

Next, each protocol is explained in detail based on the methods they adopt to provide confidentiality, integrity, authentication, and their frame structures.

3.1. LoRaWAN

A long-range wide-area network (LoRaWAN) provides security at the network and application layers. The link layer protocol authenticates LoRaWAN sensor nodes, or motes, and provides integrity to the data frame. The application layer protocol provides confidentiality to the message end-to-end, by transferring encrypted data from the mote to the application server. To explain the context of this network and its security, we next describe some fundamentals of LoRa networks.

Architecture. LoRaWAN is a proprietary protocol devised by the LoRa Alliance [47] that uses a free spectrum within the Industrial Scientific and Medical (ISM) band. LoRa has two parts [48]: the LoRa physical layer standard, and the LoRaWAN network protocol.

• Within the LoRa physical layer specification, LoRaWAN uses different ISM bands depending on the geographic region. In North America, LoRa uses 72 uplink channels and eight downlink channels in the 902–928 MHz ISM band [25]. The channels are modulated using Chirp-Spread Spectrum (CSS) with multiple Spreading Factors (SF). SFs are chosen depending on the application since different SFs provide different transmission rates, which can vary from 300 bps to 50 kbps [49]. Higher SFs are associated with lower data rates. The advantage of a spread spectrum is that multiple nodes can transmit at the same time within the same physical channel. LoRaWAN nodes can initiate transmission at any time using a random-access mode similar to unslotted ALOHA networks [50].
• LoRa network topology has in the uplink the gateways or base stations (BS), which relay data packets from motes to a network server at the core IP network [51]. The server performs security functions, such as authentication, checking the packets’ integrity, and removing duplicate packets. For the downlink, i.e., from the application server to the mote, the network server usually stores data from the user application to send to end devices.
• The downlink and uplink transmissions depend on the type of LoRaWAN motes [47]:
• Class A devices are battery-powered devices that “wake up” to send data. All transmissions are initiated by the device in the uplink. These devices conserve energy; however, they experience the longest downlink latency because they can only receive downlink data after an uplink transmission.
• Class B devices are battery-powered actuators that have scheduled receive windows. They listen for commands to perform an action. Because of the receive windows, these devices have low downlink latency while still being energy-efficient.
• Class C devices in Class C are actuators that are not restricted by battery life and require the fastest response time. The receive window is always open, except when there is an uplink transmission.

Security. LoRaWAN uses the EtM approach, i.e., Encrypt-then-MAC. Based on IEEE 802.15.4 data link layer security, LoRa encrypts the application data using AES Cipher block chaining message authentication code (AES-CCM) mode, which is a combination of the AES Counter (AES-CTR) mode for confidentiality, and the cipher block chaining (AES-CBC) mode to generate a message authentication code (MAC) for integrity and authentication. The network server can verify the CMAC of the LoRA frame. However, only the application server can decrypt the frame’s payload.

A typical LoRa frame includes the frame header, a device identifier called DevAddr, a frame counter C, the encrypted data payload EP, and the MAC or MIC at the end. The frame header has fields such as frame type, protocol version, acknowledgments, mode of operation, commands, and adaptive data rate signaling, and it is used only between the device and the network server [52].

To provide confidentiality, the payload is encrypted with AES-CTR mode using the Application Session Key (AppSKey). As in Equation (4), the frame counter C and device identifier DevAddr are also taken as inputs to the AES-CTR mode. Thus, the variable-length message payload P is combined with the DevAddr and frame counter C, each consisting of 32 bits, to create the encrypted payload EP. The frame counter C helps to keep the encrypted payload unique to avoid replay attacks. The encrypted payload EP will be transmitted all the way, end-to-end, to the application server, which has the AppSKey to decrypt it.

EP = AES128_encrypt(AppSKey, DevAddr|C|P)

(4)

To provide integrity and authentication, the frame that now has the encrypted payload EP, together with the frame headers, DevAddr, and frame counter C, are used as inputs to the AES-CMAC algorithm with a Network Session Key (NwkSKey) to calculate the MIC, which is 32 bits long, as shown in Equation (5). The least significant four bytes of the CMAC are used in the frame.

cmac = AES128_cmac(NwkSKey, Frame Header|DevAddr|C|EP)

(5)

In summary, the MIC provides integrity and authentication for the frames transported over the link layer, from the LoRa mote to the network server which has the NwkSkey to verify the MIC. On the other hand, the AES-encrypted payload is carried all the way to the application server, providing end-to-end confidentiality.

Applications. How are the security features of LoRaWAN being used in real applications? Since LoRaWAN has great coverage and capacity for outdoor applications [48], many example applications of LoRa are in fields and farms. There are several examples of LoRa in cattle tracking in different parts of the world, from reindeer tracking over wide areas in Finland [53] to cow activity tracking over areas of tens of kilometers in Uruguay [54]. In these cases, each animal carries a LoRa mote (e.g., an ear tag), with accelerometers to monitor their movement. One project, Cattle Traxx [55], uses LoRaWAN as an infrastructure-mesh network, with solar-powered gateways. These gateways relay information to each other until they reach one that is connected to the internet.

However, there are not many details about the security features of LoRa for the cattle monitoring application in Uruguay [54], where the SX1276 LoRa module used was developed by Semtech. The authors describe the radio transmission details of this module, the development of the embedded module with the accelerometer sensors, and the power savings and range (approximately 11 km). According to Semtech [56], the SX1276 supports end-to-end AES-128 data encryption. One assumption is that the cattle data are encrypted end-to-end to the user application in the cloud, although the topology of this application shows only the LoRa gateway and a server for data analysis on the other end. There are no details of LoRa’s Join, Network, and Application Servers, which help devices to obtain the session keys, such as NwkSKey and AppSKey.

Another application of LoRa in India that has two purposes, agriculture and health monitoring, helps small farmers who reside in mountainous areas [57]. This work also uses Semtech’s chips, SX1278, and it covers distances for LoRa nodes within a few kilometers of the gateway. The LoRa gateway sends data to the network server, which authenticates the end nodes, decrypts the data, and functions as an MQTT server.

A recent example of LoRa deployment is in South Korea, where tens of LoRa gateways and numerous sensor nodes have been installed along approximately 300 km of a highway [58]. This system employs different types of sensors, to indicate if the guardrails are in good condition and to track the parking spaces in rest areas.

3.2. NB-IoT

Narrowband (NB) IoT is defined by the Third Generation Partnership Project (3GPP) and is often called a Cellular IoT (CIoT) technology [59,60] that operates within the licensed spectrum. It is closely related to the Long-Term Evolution (LTE) cellular standard but it is catered to low-power devices and aims to improve coverage [61,62,63].

Architecture. To describe the NB-IoT architecture and the differences between LTE and NB-IoT, this section describes its architecture for both physical and network layers. As for naming conventions, in an NB-IoT network, there is the user equipment (UE), which is the IoT device; the enhanced NodeB (eNodeB), which is the base station; and the Evolved Packet Core (EPC) IP network, which resembles the fog network in an IoT system, as in the IoT network model discussed in Khan’s survey [21].

In the physical layer, NB-IoT uses the same channel multiplexing technologies as LTE: in the downlink, Orthogonal Frequency Division Multiple-Access (OFDMA), and in the uplink, Single-Carrier Frequency Division Multiple-Access (SC-FDMA). The channel to be multiplexed can be either 200~KHz or 180~KHz, depending on the NB-IoT radio interface’s three modes [61].

• Stand-alone mode operates on a separate Global System for Mobile (GSM) communications channel, with a bandwidth of 200 kHz.
• Guard-band mode operates on the side bands of the LTE channel, with 180 kHz bandwidth, and it uses one physical resource block (PRB) of the LTE band.
• In-band mode operates in the LTE band and it also uses one PRB, at 180 kHz bandwidth. From a cellular provider’s point of view, the latter mode is considered the best option, because it maximizes the provider’s channel assignments [61].

These modes define the larger channel, or macro-channel, in which NB-IoT operates. To allow multiple users to send uplink data, these NB-IoT macro-channels are divided into narrow micro-channels of 15 kHz or 3.75 kHz [63,64]. For 3GPP Release 13, NB-IoT supports uplink data rates of 16.9 kbps (single-tone) and 66 kbps (multi-tone), while Release 14 specifies uplink data rates of up to 159 kbps. Multi-tone uses 15 kHz channels, but the higher data rates depend on good coverage.

Another difference between LTE and NB-IoT is that NB-IoT uses data re-transmissions [64]. This is called coverage enhancement (CE). It helps to support a large number of nodes over a wide area, even when packet losses are high. There are three CE levels: level zero for normal coverage, level one for poor coverage, and level two for extremely poor coverage. The base station broadcasts the received power thresholds according to the CE level. Based on this power level and the current signal strength, the device decides whether the data frames should be transmitted several times. The higher the CE level, the higher the number of repeated transmissions, because re-transmissions of the same frame increase the chances that one of them is received by the base station.

As opposed to the random access in LoRaWAN, the NB-IoT uplink micro-channel needs to be scheduled by the service provider. Whenever the UE device needs to send data, it sends a request through a physical random access channel (PRACH) to the eNodeB. Then, the service provider’s EPC network assigns one of the narrow-band channels for the device to transmit, which is the narrowband physical uplink shared channel (NPUSCH).

In the network layer, two operation modes are defined [63,65,66]:

• Power Saving Mode (PSM) allows the UE to enter a sleep mode, from which it can wake itself up at any time to transmit data.
• Extended Discontinuous Reception (eDRX), in which the UE enters sleep mode from which it wakes up periodically. These wake-up periods are synchronized with the network, which sends control messages to the device to tell it to return to idle mode, receive data, or request to transmit data.

The NB-IoT core network has different servers for signaling and data. There is an application server that processes the uplink and downlink packets. For instance, the eNodeB may receive duplicate packets, which are removed by the application server.

Moreover, over the wireless link, between UE and eNodeB, data packets can be transmitted without an IP header. The data are encapsulated directly in the data link frame header, which results in smaller packets.

Security. How is the security provided at the link layer? First, during the connection phase, the UE and eNodeB agree on a security mode to provide confidentiality and another security mode to help protect the integrity of the data. They may be the same or different. Each can have one of four values [67]: no cipher algorithm, SNOW 3G, AES, or ZUC encryption.

Assuming AES encryption, the frame shown in Figure 6 shows that NB-IoT provides security using MAC-then-Encrypt (MtE). First, NB-IoT calculates the MAC-I (or MIC). As in Equation (6), it uses AES in Cipher-based MAC (CMAC) mode [68], which works as in AES-CBC mode. It divides the message into blocks of 128 bits, and each block is used in an XOR operation with the following block [46]. The message bits, plus a 32-bit frame counter, a 1-bit direction bit (uplink or downlink), and a 5-bit radio bearer identifier (ID), are inputs to generate the 32-bit MAC-I. The key used in this step is the integrity key K_RRCint, which is created at the Radio Resource Control (RRC) sub-layer.

Cmac = AES128_cmac(K_RRCint, Count|Dir|ID|Msg)

(6)

Then, the entire message, including the 32-bit MAC-I, goes through the AES-CTR encryption procedure, as in Equation (7). The encryption key also comes from the Radio Resource Control sub-layer. Encryption key K_RRCenc is used to encrypt signaling messages, while key K_Upenc encrypts regular data packets. All keys are 128 bits long. AES-CTR mode encrypts a random 128-bit key using a 128-bit counter value, where the Home Subscriber Server (HSS) at the EPC sets the first 96 bits [44]. The inputs to the AES-128 CTR algorithm are a 32-bit frame counter, a direction bit, a 5-bit radio bearer identifier (ID), and the block length (Equation (7)). This produces the encrypted keystream, which will be XORed with the plaintext block, to generate the final encrypted frame or ciphertext, as in Equation (8).

Keystream = AES128_enc(K_Upenc, Count|Dir|ID|Length)

(7)

Ciphertext = (message|MAC-I) XOR Keystream

(8)

The ciphertext is then transmitted over the radio link. Therefore, NB-IoT security provides integrity and confidentiality at the link layer using the MAC-then-Encrypt (MtE) strategy.

It is also possible that NB-IoT uses the SNOW 3G encryption algorithm [69]. The SNOW 3G algorithm is defined by the European Telecommunications Standards Institute (ETSI). In SNOW 3G, a Linear Feedback Shift Register (LFSR) consisting of sixteen 32-bit registers is used to generate input values to a Finite State Machine (FSM). The output of the FSM is then used in an XOR operation with the data in the least significant register of the LFSR to generate a stream of keys that are used to encrypt the message [70]. SNOW 3G is also used for integrity and authentication.

In the next hop, between eNodeB and the application server at the EPC, the application data are encapsulated into an IP/UDP header. Although the Transport Control Protocol (TCP) is supported, the more lightweight UDP transport protocol is preferred. Network layer encryption such as an IP Security (IPSec) protocol [71] is used, as in an example shown for NB-IoT in [49] where a virtual private network tunnel is used between the core network server and the user application in the cloud. Moreover, Datagram Transport Layer Security (DTLS) over UDP is an option at the application layer. Based on Khan’s [21] approach of “end-through-node-to-end encryption”, NB-IoT adopts a similar strategy, since the server at the EPC, which has more resources than the UE, will then encrypt the data end-to-end to the cloud using a robust encryption algorithm such as IPSec or DTLS.

Applications. NB-IoT works well in indoor and outdoor applications [48]. Smart metering in Automated Metering Infrastructure (AMI) networks is an example of an IoT system [72] where smart meters send real-time reports to an electrical utility. With NB-IoT, smart meters can send data directly to a server at the utility company. Since NB-IoT supports data payloads up to 128 bytes, it can be used for smart meter reports, which may require on average 300 bytes on each smart meter uplink message [5].

Furthermore, 3GPP provides a table of different applications in the context of a smart city, which includes infrastructure services such as water, gas, electricity, transportation, and waste management.

Table 5. Smart city applications that utilize NB-IoT, according to 3GPP.

Application	Message Frequency	Message Size
Waste management	1 per hour	50 bytes
Bike renting	4 per hour	50 bytes
Gas meter	4 per hour	100 bytes
Parking	1 per hour	100 bytes
Water meter	1 per day	200 bytes
Electricity meter	1 every 4 h	300 bytes
Pollution monitoring	1 per hour	1000 bytes

, adapted from [67], provides examples of sensors, the frequency of the messages that they send, and how large the messages are when using NB-IoT.

3.3. C-UNB/Sigfox

The Cooperative-Ultra Narrow Band (C-UNB) standard is a cellular IoT technology specified by 3GPP in the technical report TR45.820 [59]. A similar technology called triple-diversity UNB (3D-UNB) was developed by a French company named Sigfox, which uses the ISM spectrum. In the United States, it uses the 902 MHz band. As illustrated in Figure 5, both C-UNB and Sigfox are LPWA networks that provide wide-area connectivity, low data rates, and ad-hoc access protocols to serve a large number of IoT devices.

Architecture. At the physical layer, C-UNB uses macro-channels, such as 200 kHz GSM channels, or the sidebands of LTE channels, similar to NB-IoT. In this way, C-UNB uplink channels are created by dividing a 200 kHz macro-channel into narrowband channels, or micro-channels. The bandwidth of each micro-channel is just a few hundred a Hertz, being one of the slowest data rates in LPWA, and for this reason, it is called ultra- narrowband. Assuming that the uplink bit rate is estimated to be 300 bps and the modulation scheme is Differential Binary Phase Shift Keying (D-BPSK), the required bandwidth of each micro-channel is 600 Hz, i.e., two times the bit rate. The C-UNB downlink also employs micro-channels. The downlink bit rate is higher, at 600 bps.

Similarly, the Sigfox radio link has micro-channels with 600 Hz of bandwidth both in the downlink and uplink, where the downlink uses Gaussian Frequency Shift Keying (GFSK) and the uplink uses D-BPSK modulation. The total bandwidth needed in the uplink and downlink is 192 kHz for each macro-channel, which provides 320 micro-channels in the uplink and downlink.

The triple diversity in the 3D-UNB of Sigfox means diversity in space, time, and frequency. Frequency diversity comes from such a large number of micro-channels, which allows hundreds of devices to transmit at the same time. In the capacity analysis done in [48], Sigfox connections showed less than a 1% failure rate for outdoor users, assuming that each user had eight IoT devices. Time diversity means that the devices transmit the same message three times, one after the other, each on a different random micro-channel. Space diversity means that base stations in adjacent cells listen to the same 192 kHz macro-channel. Thus, packet collisions are avoided [72].

IoT devices, or end-points, transmit mostly in the uplink because the end-points sleep to save battery. Whenever a Sigfox end-point needs to send data, it randomly selects a micro-channel to transmit data. Thus, both C-UNB and 3D-UNB networks use a contention-based data link protocol, similar to unslotted ALOHA [50]. When an uplink packet is received, the base station sends an acknowledgment using the same micro-channel of the uplink message. If a collision is detected, i.e., two devices transmit in the same micro-channel and no acknowledgment is received, then the frame is re-transmitted. In the C-UNB specification, the uplink frame header has a repetition counter, which can have values equal to one, two, or three [72]. For mobile autonomous reporting (MAR) applications, it is assumed to need at most two repetitions. Three repetitions are said to be normal for exception reports (e.g., alarms).

For Sigfox networks, the maximum payload sizes are fixed at twelve bytes in the uplink. No IP headers are used, i.e., the application data are encapsulated directly by the frame header. The end-point device is identified using a four-byte identification number. The twelve-byte packet keeps messages small and reduces the chances of packet collisions.

Security. An important element in C-UNB and Sigfox is the C-UNB server, similar to the one shown in Figure 3. A C-UNB server is a relay agent that receives and stores data from the cloud and sends data when the device wakes up. The C-UNB server listens for the device’s uplink transmissions, acknowledges them, and sends any stored data at the same time. It also removes duplicate packets and performs security checks. It checks the authentication information sent by the devices and verifies that the frames have not been modified in transit. To accomplish this, it employs a lightweight approach, but no specific encryption algorithm is specified. A C-UNB frame header has a two-byte MIC, which is computed using the device’s identity information together with the frame’s sequence number and payload bits, using a secret key that is shared by the device and the C-UNB server. The same MIC is used in the downlink acknowledgment frame.

Sigfox’s radio specification [73] describes security from device to base station. The payload can be sent encrypted or in clear mode. If encryption is selected, Sigfox takes an approach similar to LoRa’s EtM approach, where the payload is first encrypted and then the MAC is calculated. In either encrypted or clear mode, all frames will have a message authentication code (MAC), known as UL_AUTH, which is two to five bytes long.

The payload encryption is performed with AES-CTR with a 128-bit encryption key K_e. The CTR value is generated by combining the twelve-bit message counter (MC), the eight-bit roll-over counter (RoC), and the device ID, as in Equation (9). The CTR value is updated for every frame. The result of the AES encryption, the CTR value with the key K_e, will be used as an input to the XOR logical operation with the message payload bits (the plaintext) to generate the encrypted payload (Equation (10)). Since Sigfox messages are small, with twelve bytes of payload, the AES-CTR mode works well because it allows any size of plaintext to be encrypted.

Keystream = AES-128_enc(K_e, ID|RoC|MC)

(9)

EP = Plaintext XOR Keystream

(10)

where EP is the encrypted payload.

Then, the Sigfox header is attached to the encrypted payload. Next, the UL_AUTH field is calculated. To calculate the UL_AUTH, the end-points use the frame’s sequence number, device identification, and encrypted payload bits (Equation (11)). The key is a 128-bit AES authentication key Ka, and AES-128 in Cipher Block Chaining (CBC) mode is used. The AES-CBC mode generates a 128-bit MIC, but only two to five of the most significant bytes are used as the UL_AUTH.

cmac = AES-128_cmac(K_a, MC|ID|EP)

(11)

Application Domains. Sigfox networks support different applications. For instance, asset tracking is a popular use of Sigfox end-points, which are installed in trolleys and trucks. Smart farming and monitoring of the environment are also example applications where end-points send measurements to the cloud.

In the context of an automated metering infrastructure (AMI) network, a previous research study evaluated ultra-narrowband systems using a network simulator (NS-3) [74]. They simulated the physical and link layers of a C-UNB device and base station, using the application protocol called Device Language Message Specification—Companion Specification for Energy Metering (DLSM-COSEM). Although the C-UNB architecture provides frequency and spatial diversity, the amount of data sent by the smart meters was too large for the small packets. This required that the DLSM-COSEM payloads be fragmented, which resulted in a high collision rate in the simulations.

Among the several IoT systems that use Sigfox, the design of a novel application for the mining industry is presented in [75]. It monitors tailing dams where mine residues are deposited, using sensors such as a tensiometer and soil moisture and temperature sensor. They called it TD-DAQ or tailing dam data acquisition. This application encompasses the fields of geology, waste management, and civil engineering, which makes it very unique and important for the safety of mining operations. Moreover, this system, which was deployed in South Africa, is one more example of the global reach of IoT. When checking the security of the TD-DAQ system, it was not clear from the paper describing the TD-DAQ whether Sigfox was used in encryption mode or clear mode, or whether some additional application layer encryption was developed by the authors.

3.4. Summary of LPWA Networks

In summary, Figure 6 and

Table 6. Summary of LPWA networks’ communication and security properties.

Communications	LoRaWAN	NB-IoT	C-UNB/Sigfox
Uplink Rate	0.3–50 kbps	159 kbps (Rel14)	0.6 kbps
Spectrum	ISM band	licensed	ISM band
Channel Bandwidth	125, 250, 500 kHz	180, 200 kHz	192 kHz
One Micro-Channel	125 kHz	15 or 3.75 kHz	0.6 kHz
Number of Uplink Channels	72	12, 48	320
Uplink Access	random (ClassA)	scheduled	random
Uplink Packet Size	51 bytes	128 bytes	12 bytes
Security	LoRaWAN	NB-IoT	C-UNB/Sigfox
Strategy	Encrypt-then-MAC	MAC-then-Encrypt	Encrypt-then-MAC
Confidentiality	AES-CTR	AES-CTR, SNOW, ZUC	AES-CTR
Authentication	AES-CMAC	AES-CMAC, SNOW, ZUC	AES-CMAC
Integrity—MIC Size	32 bits	32 bits	16 bits
Replay Protection	32-bit counter	32-bit counter	12-bit counter

highlight the LPWA networks’ characteristics. There are many similarities. The payload sizes are very small, with the largest being 128 bytes in NB-IoT. Both LoRaWAN and Sigfox use a license-free spectrum, and the devices initiate uplink transmissions at random. Their performance depends on the number of devices per base station, the time for which the data are in the air (thus, small packet sizes are used), and the number of uplink data channels available. To support wide coverage areas and avoid losing packets, NB-IoT and Sigfox send the same message several times.

As for security, the three LPWA network architectures use 128-bit AES-CTR mode for encryption and AES-CMAC for message authentication. AES-CTR mode has the following benefits: the same hardware or software can be used to encrypt and decrypt data and pre-processing can be done prior to encrypting the IoT device’s data. According to [44], CTR mode makes a block cipher more versatile, as the block cipher becomes more similar to a stream cipher.

In some cases, these architectures provide end-to-end confidentiality using the Encrypt-then-MAC approach; in other cases, the MAC-then-Encrypt strategy is adopted, which is not end-to-end.

4. Emerging Lightweight Security Approaches

This section presents emerging techniques for lightweight AES and ECC. They are categorized in terms of the following security primitives [23]:

• Lightweight block cipher, which includes smaller block and key sizes, simpler rounds, and key schedules.
• Lightweight hash function, with enhancements such as smaller inputs and smaller outputs.
• High-performance system and whether it has a custom CPU or crypto-arrays to perform encryption tasks in parallel.
• Low-resource device in terms of software or hardware implementations.

Using these security primitives,

Table 7. Emerging lightweight approaches for IoT that are based on AES and ECC encryption.

	Block Cipher Primitives			High Performance			Implementation
	Small Block	Small Key	Simple Round	Key Schedule	Custom CPU	Crypto Array	Software	Hardware
LightAES for FPGA [76]				✓		✓		✓
LPADA [77]					✓			✓
LAES [78]			✓					✓
ALE [79]			✓	✓	✓			✓
Masked AES [80]				✓				✓
AES-64 [81]	✓	✓		✓			✓
ISA [82]					✓		✓	✓
Quark [83]					✓			✓
ECC WaterMark [84]		✓					✓
ECIOT [85]		✓	✓				✓
ECC Accel. [86]								✓

categorizes a few emerging lightweight schemes, and which areas they propose improvements for. Each of these schemes is explained next.

4.1. Symmetric Encryption—Lightweight AES Approaches

For IoT systems, researchers are working to develop lightweight versions of AES. The AES algorithm is a symmetric cipher. Decryption can be achieved by performing the inverse of these operations and the same secret key.

4.1.1. Lightweight AES for FPGA

AES transformations can be done in hardware or software. When it is implemented in hardware, it typically uses field programmable array (FPGA) integrated circuits. An example of lightweight AES implementation in FPGA is presented in [76], whose main objective was to reduce the latency of the AES transformations by reducing the number of clock cycles of AES transformations.

The AES transformations include substitution and permutation transformations. Each round of encryption consists of four AES transformations, in the order shown in Figure 7. In each round, a unique key is used. These round keys are obtained through key expansion based upon the first cipher key [43]. Before the first round begins, the AddRoundKey transformation is performed between the 16-byte block (which is a four-by-four-byte matrix) and the cipher key. Then, all four transformations are performed in the following order: SubBytes, ShiftRows, MixColumns, and AddRoundKey. Each round has four transformations, except for the final round, which consists of only the last three transformations.

The authors in [76] programmed the SubBytes transformation to be done in a parallel manner. Because SubBytes operates independently on each byte of the four-by-four state matrix using a substitution table called S-Box, they propose to substitute multiple bytes in the matrix in parallel. Moreover, the S-Box can either be stored in the device’s memory or be generated based on equations explained in the Federal Information Processing Standard (FIPS) 197 AES standard [43]. In the work proposed in [76], the S-Box is pre-calculated and used as a look-up table to substitute multiple bytes at the same time.

A second parallel operation that they propose is the MixColumns transformation, which performs linear transformations on each column of the state matrix. In the MixColumns transformation, each column of the state matrix is a vector that is multiplied by a fixed four-by-four matrix, resulting in a new column in the state matrix. The authors explain that the multiplications on each column can be done in parallel.

Another design choice proposed in [76] was to calculate the round key at every round, instead of calculating the complete key schedule prior to the encryption and storing all keys in memory. This is mainly to save memory storage.

These techniques mainly address the lightweight primitives of hardware improvements at the FPGA level for low-resource devices, to reduce delays and save memory space. The parallel operations of SubBytes and MixColumns transformations can be considered a type of system performance primitive, as crypto-array operations. Round key calculations at each cycle can be considered as simpler round keys in the block cipher primitive, as shown in Table 7.

4.1.2. Low-Power AES Data Encryption Architecture (LPADA)

Used in LoRaWAN, the Low-Power AES Data Encryption Architecture (LPADA) [77] is also an AES encryption hardware solution combined with custom CPU techniques to reduce power consumption and ensure a ten-year battery life for LoRaWAN devices. LPADA reduces the power required to perform AES transformations at LoRaWAN motes, using the following three methods to conserve power:

• Low-power S-Box: an ultra-low-power Content Addressable Memory (CAM) stores the S-Box as a look-up table in memory, the contents of which are generated before a data substitution begins. To improve the speed and reduce power in the SubBytes transformation, two approaches are adopted together in LPADA. The first is that the
• CAM uses parallel searching techniques to reduce delays in the SubBytes operation. Second, a low-power CAM architecture is used to discharge entries in the look-up table that do not match the search data. Power management techniques also ensure that the S-Box portion of the memory remains powered at all times to avoid losing its contents.
• Power-gating technique: to reduce power consumption, this technique means that the power supply to certain logic circuits in the FPGA, which are built using transistors, is turned off. This power-gating technique is done in LPADA using P-type metal oxide semiconductor transistors (PMOS), which can switch off power to all components of the AES circuit when in sleep mode. The exception for this is the S-Box, for which power is maintained.
• Dynamic power management (DPM) method: consists of three operation modes that control supply voltages and clock frequencies based on the device’s state. These modes include active, idle, and sleep modes. The active mode consists of all components receiving power and a clock when the device is performing an action request, such as an encryption operation. In idle mode, which is controlled by a five-minute timer, all components receive power while their clock rates are gated to reduce dynamic power consumption. This means that the clock rates are reduced to a lower value or set to zero. If an action request is not made within the five-minute timer interval, the device will enter sleep mode when power to all circuits is switched off, except for the S-Box.

These three power reduction methods employed by the LPADA architecture work together to extend the battery life of LoRa motes, while executing the AES algorithm. These methods are mostly about the AES transformations and hardware improvements to conserve power and can be reproduced for not only LoRA devices but for other communication protocols that use AES.

Another contribution of LPADA is to LoRa’s key management scheme, as it tries to improve the way in which encryption keys are updated in LoRaWAN networks when a device rejoins the network. LoRa’s key management protocol defines how LoRa motes obtain the AppSKey and NwkSKey, used in Equations (4) and (5). At manufacturing, three values are programmed in the mote: a 128-bit key called AppKey and two global device identifiers, or extended unique identifiers (EUI), called AppEUI and DevEUI [87]. When a new device joins the LoRaWAN network, the AppKey and DevEUI are used to create an application session key (AppSKey) and a network session key (NwkSKey). They exchange messages with a Join Server, which is an additional server in LoRa’s networks to the Network Server and Application Server. The Join Server also knows the AppKey, DevEUI, and AppEUI.

When the device sends a Join request to the Join Server, the DevEUI together with an application identifier (AppEUI) and a 128-bit AES application key (AppKey) are required to establish a secure connection via over-the-air activation (OTAA). This request message is not encrypted, but it has an MIC that is calculated using these three values, plus the frame header and a DevNonce value, which is a random number. The Join Accept message is encrypted by the Join Server using the AES-128 ECB decrypt operation. It is also a Mac-then- Encrypt (MtE) message. The Join Server uses the decrypt operation because the LoRa mote supports AES encryption but not decryption. This keeps the mote simpler.

When the Join Accept message is encrypted at the LoRa mote, the session keys NwkSKey and AppSKey are generated at the device. The Join Server also generates these two keys and sends them to the Network and Application Servers.

This process repeats when a LoRa device joins a new network or loses the session key information. However, in the LPADA architecture, a new key updating procedure is proposed in which a new key update request is sent from the mote to the Join Server. This encrypted message uses the old AppSKey as the plaintext, with some other values. Then, the key update answer message is also encrypted by the Join Server using AES-128. However, this new LPADA key update method has a disadvantage. It will require that the LoRa mote supports AES decryption operations, so that it can decrypt the key update answer message. Although they are the same transformations of AES as in Figure 7A, they are called in reverse order and require more complex logic at the firmware level.

4.1.3. Lightweight AES (LAES)

Another lightweight AES (LAES) [78] proposal removes the MixColumns transformation and replaces it with a 128-bit permutation table. This permutation operation uses a fixed table that re-arranges the columns in the state matrix. MixColumns is a non-linear transformation on the columns of the state matrix, and the authors argue that the permutation operation is another non-linear operation, albeit less complex to implement in hardware than MixColumns. In this way, when using a 128-bit key, after the first AddRoundKey, the nine rounds include SubBytes, ShiftRows, Permutation, and AddRoundKey transformations (Figure 8).

This variation in the AES round schedule aims to improve overall performance in terms of throughput, namely the number of bits processed per time. Performance efficiency is calculated by dividing the throughput by the area of the FPGA circuit.

The benefits of the proposed LAES algorithm include improved operational frequency, increased throughput, reduced footprint area, and improved performance efficiency. As shown in Table 7, LAES can be considered as both a hardware improvement for low-resource devices and a lightweight block cipher with simpler rounds because it replaces the MixColumns transformation with a simpler non-linear operation.

4.1.4. Authenticated Lightweight Encryption (ALE)

Authenticated Lightweight Encryption (ALE) [79] is a new AES-128 mode of operation, which can be compared with the high-performance authenticated encryption scheme called Offset Codebook (OCB) mode that is also used with AES block cipher. However, the designers of ALE argue that ALE requires less memory and a smaller circuit than OCB.

ALE supports both encryption and authentication/integrity by generating a message authentication code (MAC) while it encrypts the data. It is a single-pass scheme because the encryption and authentication are done in the same AES rounds. On the other hand, strategies such as Encrypt-then-MAC (EtM), which were reviewed earlier, require two AES operations, or two passes: first, plaintext data go through all AES rounds, and then the encrypted data plus header fields have to go through all AES rounds to generate the MAC.

Moreover, ALE’s design relies on a nonce (i.e., a random number used once) and associated data, in addition to the message, which is divided into blocks of 128 bits and an equally sized master key k. Associated data are data that do not need to be encrypted, but need to have an MAC calculated. For these reasons, ALE is considered a single-pass authenticated encryption with associated data (AEAD) algorithm.

The design of ALE is novel compared to the previous AES lightweight schemes described in this section. ALE not only optimizes its hardware architecture by using parallel MixColumns and a high-performance S-Box, but it also reduces the number of AES rounds in most operations. It decreases the encryption from ten rounds to four, including a simpler four-round key schedule.

ALE also can be considered a hybrid scheme, as it is referenced in the survey by Agrawal et al. [22]. ALE’s hybrid nature comes from mixing block cipher and stream cipher operations since it uses features from the LEX streaming cipher [88], where a block cipher outputs (or leaks) bits as it encrypts. The way that ALE works is that, while it encrypts the associated data using four AES rounds, it leaks sixteen bytes (128 bits) of data, which are then XORed with the first message or plaintext block to create the ciphertext, and so on. There is an initialization phase to generate the key state and data state. Then, the data state is used as input to create the associated data, also using four AES rounds. This simplified explanation shows how AES can be used using less rounds.

When ALE is implemented in an application-specific integrated circuit (ASIC) or chip, in terms of the circuit size, ALE is compared to a stream cipher called ASC-1 [89]. ALE is roughly half the size of ASC-1’s implementation, but its speed is around 4.5 times faster than that of ASC-1. The algorithm requires only 2500 gate equivalents (GEs) of area, which is significantly smaller than that of the lightweight implementations for AES-OCB and AES-CCM. In the use of parallel software using Intel’s AES new instructions (AES-NI), ALE significantly outperforms AES-GCM, AES-CCM, and ASC-1. Given its hardware efficiency and high performance, it is regarded as an all-round AEAD algorithm.

4.1.5. Lightweight Masked AES Implementation

Hardware-level attacks on IoT devices happen when a malicious user obtains access to the physical device, i.e., the embedded system with its FPGA modules and microcontrollers. The malicious user then performs a side channel attack (SCA) in order to obtain the encryption key or the plaintext. SCA exploits the physical properties of the device, such as power dissipation, delays, temperature, or electromagnetic emissions. When power dissipation is exploited, this attack is called a correlation power analysis (CPA). For AES encryption, CPA attacks may target the S-Box circuitry used in the SubBytes transformation. The lightweight masked AES approach proposed in [80] aims to prevent the power dissipation analysis by a malicious user. This scheme is illustrated in Figure 7C.

In general, CPA attacks can be prevented using the idea of a masked AES. It means that some random data are added during the encryption process. This hides the real values of the plaintext blocks and the AES state matrix as they go through the substitution box (S-Box). The traditional masked AES approach is to add random data to the plaintext before the first round of encryption. However, Yu et al. [80] proposed to add fixed random data to each round key, so that every round will have a false key. These random data are called intermediate data I_c and the false round keys are called K_f0, K_f1, … K_fm, where m is the number of rounds. Usually, m is ten rounds for a 128-bit AES key. Thus, in Table 7, this scheme is classified as a change in the round key schedule. Although the number of rounds is the same, they adapted the key by adding the intermediate data I_c to the key in each round.

In addition, when the last encryption round ends, there is a reconstruction circuit to remove the masked data and recover the correct ciphertext. The proposal in [80] created a reconstruction circuit using a new type of XOR gate that is based on a technology called Wave Dynamic Differential Logic (WDDL) [90], which helps to prevent a CPA attack. WDDL gates can be implemented using standard gates, so they can be used in either FPGAs or dedicated ASICs. With WDDL, the signal transitions consume the same amount of power; therefore, it becomes harder for attacks to inspect the signals and the operations they go through by looking at the device’s power consumption.

4.1.6. Sixty-Four-Bit AES Key Schedule

The key schedule is the process that generates a different key for each AES round. The original key is usually called the master key. For AES, the master key length can have 128, 192, or 256 bits. The key schedule creates several 128-bit keys. It operates in 32-bit (or 4-byte) words, which correspond to four columns in the key matrix.

In the case of a 128-bit master key, the first column of the round key is generated as follows:

• The RotWord transformation is applied to the last column of the previous round key. It performs one circular upwards shift of all bytes within the column.
• The SubBytes transformation is applied using the S-Box.
• The sum of the resulting four bytes, the first column of the previous round key, and the round constant generates the first column of the new round key.

Then, this updated first column is added to the second column of the previous round in order to update the second column. The updated second column is added to the third column of the previous round to update the third column. This process is repeated for the fourth column as well.

These operations on the key follow three basic strategies: linear transformation using permutation (RotWord), masking with constants (using round constants), and applying some non-linear components such as the S-Box. This type of key schedule helps to add diffusion to the encryption process as it becomes harder to find the relationship between the input plaintext and output ciphertext.

This robust AES key schedule has been modified in [81], which has 64-bit keys and 64-bit blocks of data. They also made some changes to the transformation that happens in the key schedule. Their algorithm includes the following changes:

• The round constants are different random numbers generated at each round (r₀, r₁, …, r₇), where each r_i is one byte.
• The master key is XORed with the round constants (r₀, r₁, …, r₇) to create a newKey.
• Each byte of the newKey is XORed with each other to generate 32 bytes (k₀ to k₃₁). For the bytes that are in a position that is a multiple of eight (e.g., 8, 16, or 24), a special transformation occurs using the SubBytes transformation with the four-bit S-Box from the PRESENT algorithm. Then, a modified MixColums is implemented, followed by another SubBytes transformation with the same four-bit S-Box. These temporary values are also XORed with the bytes of the newKey.
• At the end of each round of key generation, there is also a round constant reverse array (r₇, r₆, …, r₀), which is used in an XOR operation. This reverse array is XORed with the newKey values to generate the new round key.

This algorithm has been tested in software using MATLAB. According to the authors, it has an important property called the avalanche effect. In their simulation results, when they change one bit of the master key, they compare how different each round key is from the previous round key for ten rounds. For certain bit change scenarios, the average change in the bits of the round key was as good as 38 bits. In another case, the average was an approximately 29-bit difference. This shows that almost half of the 64-bit key bits are changed when the master key is changed. In addition to the smaller key, this avalanche effect is an important property to guarantee that this new AES scheme is robust.

4.1.7. ISA Extension for AES and SM4

An ISA is an instruction set architecture, where very low-level code (such as assembly code) defines operations closely related to given microprocessor architecture. In the work by Saarinen [82], a new ISA extension was created for the open-source architecture called RISC-V. For this reason, this new AES lightweight approach is classified in Table 7 as a custom CPU for increased performance. Another reason is that it is a hardware and software platform that applies to low-power devices.

The ISA extension proposed in [82] not only supports AES but also SM4, an encryption algorithm that is widely adopted in China. SM4 is also a 128-bit block cipher with a 128-bit key. It uses a non-linear transformation similar to the SubBytes transformation.

Most CPU architectures, such as Intel and ARM, have instructions to support AES encryption. However, they use a type of parallel processing using single instruction, multiple data (SIMD) registers that may not be available in less powerful CPUs. Thus, the work in [82] proposes a new architecture. It has two source registers, a destination register, and instructions that incorporate several AES transformations. For instance, the instruction AES-FN-ENC performs all the following tasks as a single instruction for one byte of the 16-byte block:

• Selects a byte for the source register rs₂;
• Performs one S-Box look-up (SubBytes);
• Performs part of the MixColumns operation;
• Rotates this resulting byte (ShiftRows);
• Performs logic XOR of the result with rs₁ which has the round key.

This instruction is considered sixteen times per AES round to take care of the block of data. It also requires operations to fetch the round key for this cycle. These operations not only improve performance but are more robust against side channel attacks such as attacks that spy on the timing of the operations. The authors in [82] argue that the time is constant for all the proposed instructions.

Additional instructions are defined for the decryption rounds and final round (AES-FN_DEC and AES-FN-REV). There are also instructions for the SM4 cipher, such as SM4-FN-ENC for SM4 encryption and decryption. The added hardware is very small and this scheme can also be combined with a masked AES scheme.

4.1.8. Quark-AES

A study performed by Yu and Aagaard [83] compared several AES hardware implementations at the CPU level on ASICs. The authors explain that although AES is not a lightweight encryption algorithm, several implementations accomplish a compact low-area implementation.

The metric used to compare area in ASICs and FPGAs is called a gate equivalency (GE) metric. Even using a standard metric, it is difficult to compare different AES hardware implementations. However, they reviewed several implementations from 2001 to 2017. For instance, in 2001, shortly after AES became a standard, a 32-bit architecture was proposed. It performed the encryption and decryption operations in the same hardware, it was implemented using 5400 GE, and the latency was 54 clock cycles. The next implementations focused on completing operations using an 8-bit architecture. One of the recent implementations that was benchmarked in this paper used only 1947 GEs and it is considered a subatomic AES with less than 2000 GEs. However, the latency was 336 clock cycles.

It is clear that the comparisons in [83] addressed an important trade-off, between area and latency. One recommended technique is that AES encryption transformations and key expansion should be done in serial versus parallel. While parallel operations (as seen in a few AES implementations described in the previous sections) are faster, they require duplicate hardware to execute multiple steps at the same time.

On the other hand, when AES transformations are performed in serial order, designers can save in area but the latency is increased. For instance, the ShiftRows transformation can be executed in serial instead of parallel order. Additionally, to facilitate a serial implementation, the authors explain that some AES transformations can be done out of order, e.g., the order of the ShiftRows transformation and the SubBytes transformation can be changed without affecting the result.

Finally, after comparing three different low-area AES implementations and their architectures, the authors proposed their eight-bit implementation, called Quark-AES. They use only one S-Box for encryption and key expansion; they use a lightweight MixColumns approach that is a serial version of MixColumns that needs only two registers, and every component is serial. They implemented Quark-AES on an ST 65 nm processor and were able to use only 1960 GEs, with a latency of 216 clock cycles to encrypt and decrypt.

4.2. Asymmetric Encryption—Lightweight ECC Approaches

Elliptic Curve Cryptography (ECC) is an asymmetric encryption algorithm that uses public and private keys. It is sometimes considered a lightweight approach to data security because it provides similar security to traditional public-key algorithms (such as RSA and Diffie Hellman) but with a much smaller key size. In other words, it “provides the highest strength per key bit”, according to [18]. For example, a 283-bit elliptic curve public key is said to provide the same level of security as a 3072-bit RSA public key or a 128-bit key in a symmetric cipher [91,92]. Smaller key sizes allow ECC to utilize less memory, which is good for devices with limited power and storage. However, standardized ECC algorithms are computationally demanding. According to [24], they were “not thought to be realized in constrained environments”.

ECC keys can be much smaller than those in traditional public-key ciphers because of the elliptic curves’ complex nature. The elliptic curves that have been recommended by the National Institute for Standards and Technology (NIST) follow the Weierstrass normal form [92], as in Equation (12).

y² = x³ + ax + b

(12)

In the plotted elliptic curve in Figure 9, each value on the x axis corresponds to two points on the y axis [24].

The two ECC protocols that are explored in this section are elliptic curve Diffie–Hellman (ECDH) for session key distribution and the elliptic curve digital signature algorithm (ECDSA) for authentication. Their applications are discussed, as well as two adaptations of ECC for IoT devices.

4.2.1. Elliptic Curve Diffie–Hellman

An application of ECC is the elliptic curve Diffie–Hellman key exchange protocol. ECDH allows the sender and receiver to generate a secret elliptic curve point that is used to create a session key for symmetric encryption [93]. ECDH is similar to the original Diffie–Hellman key exchange protocol. It relies on the difficulty of solving the discrete logarithm problem. This problem requires exponential computational complexity and relies on the principle of one-way functions, which are easy to compute in one direction but difficult to reverse [11]. ECDH, however, utilizes the inherent difficulty of finding the discrete logarithm of elliptic curve elements from a publicly shared base point rather than large integers [94]. This means a higher level of complexity. This variant of the discrete logarithm problem is called the Elliptic Curve Discrete Logarithm Problem (ECDLP) [92].

Figure 10 illustrates how ECDH works, assuming that it is implemented for a LoRA-based IoT system. First, the sender (i.e., the gateway) and receiver (i.e., the application server) agree on an elliptic curve over a finite field E(F_q). The field size q is derived from a prime number p. They must also agree on a co-factor h and a base point G. The sender then selects a private key a that is a random integer within the range {1, …, n − 1}, where n is the order of the subgroup consisting of the real points of the curve E(F_q).

As in the first row of Figure 10, the scalar multiplication of the private key a with the base point G generates the sender’s public key H_a, thus completing the sender’s key pair (H_a, a). The receiver generates a key pair (H_b, b) using the same procedure.

Then, the gateway and server exchange their public keys H_a and H_b over the network. After the gateway receives the server’s public key, it generates the session key K by multiplying the server’s public key H_b with its private key a (this multiplication is shown in the third column, the first row of Figure 10). The server also generates the same session key K using the gateway’s public key H_a and its private key b. At this point, both parties have remotely agreed on a shared session key K = abG [95]. Key K will be used to encrypt the subsequent messages using a symmetric encryption algorithm such as AES or PRESENT.

4.2.2. Elliptic Curve Digital Signature

ECDSA is an alternative to the digital signature algorithm (DSA) due to the smaller key sizes associated with ECC [96,97]. ECDSA’s reduced key size can be used in IoT gateways to authenticate IoT devices and verify the integrity of the messages [98].

ECDSA begins with the sender generating a hash value e of the message m. A hash value is a one-way function that generates a fixed-size, unique value for the input message. This hash value is then truncated to k bits in length, where k is equal to the order of the subgroup generated by the base point G. This truncated hash is represented as z.

The sender then uses the key pair (H_a, a) generated during the ECDH key exchange to generate the signature s, which is calculated using Equation (13).

s = a⁻¹(z + r ∗ a)

(13)

where the value r represents the x coordinate of the point that serves as the sender’s public key H_a modulo k, and a⁻¹ is the multiplicative inverse of a modulo k. The signature is then placed into a pair (r, s), which is sent to the receiver with the encrypted message for verification.

The receiver begins verification by decrypting the received message to obtain the plaintext message m. The receiver then calculates the hash value e using the same procedure as the sender. After the hash value is truncated to obtain z, two values (x₁ and x₂) are calculated as in Equations (14) and (15).

x₁ = s⁻¹ z mod(n)

(14)

x₂ = s⁻¹ r mod(n)

(15)

These two values are used in Equation (16) to obtain the point (x,y).

(x,y) = x₁ G + x₂ H_a,

(16)

where H_a is the sender’s public key. If the condition r = x mod(n) is met, then the signature is verified. Otherwise, it is invalid.

4.2.3. ECC Applications in IoT

As with many other public-key algorithms, ECC is used with symmetric encryption algorithms to make a hybrid crypto-system. For example, ECDH helps to generate and deliver the session key for a symmetric key algorithm, which will be used by the sender and receiver to encrypt the data packets [99]. ECDH is one of the many key bootstrapping procedures described in [18], which reviewed nine algorithms that incorporated ECC as the public-key algorithm.

An example of ECC applications can be found in the e-health record network (EHR). EHR requires strong security protocols to protect sensitive patient data. A proposed EHR security solution is the lightweight distributed access control system with keyword search (LDAC-KS) [100]. ECC was chosen in this system because it provides security equivalent to RSA but with smaller key sizes.

Because of its lightweight nature and strong security, ECC has been adapted to create other protocols [85], which aim to make ECC accessible for IoT devices. Below are some examples, which have also been summarized in Table 7.

• ECC Watermark: This is a modified version of the ECC algorithm, where the ECDH key exchange protocol is combined with a new authentication method. ECC Watermark replaces ECDSA with a fragile zero watermarking technique [84]. The watermark is generated during the encryption phase by the sender, who generates a hash of the packet’s source IP address, protocol field, and destination IP address using the sender’s private key. The generated watermark is appended to the packet’s payload. This method utilizes a private-key hash function rather than elliptic curve multiplication operations for signature generation, thus avoiding the complexity of the multiplicative inverse operation. This can be considered a lightweight hash with a smaller output, which is the watermark that is appended to the packet.
• ECIOT: Elliptic Curve Internet of Things (ECIOT) [85] utilizes the ECDH key exchange protocol so that the sender and receiver can establish a session key K. The ECIOT protocol then performs an XOR operation using as inputs K and the data. In summary, ECIOT encrypts and decrypts data with the simple XOR operation, after ECDH generates the shared key K. This can be considered a simpler round of encryption, where one logical operation constitutes one round of the encryption process.
• Lightweight Elliptic Curve Accelerator: The work proposed in [86] is the hardware architecture of an accelerator that performs the scalar multiplication that generates the public key of ECDH. The private key a multiplies the base point G to generate the public key H_a = aG. This means that the base point G is added a number of times. The design goal of the proposed hardware accelerator is to reduce the hardware footprint, or area of the FPGA, to implement this scalar multiplication efficiently.

4.3. Digital Fingerprinting

Spoofing is an IoT system’s security vulnerability, which means malicious devices masquerading as authentic end nodes [101]. If attackers can discover the device’s physical address (such as a serial number or a media access control (MAC) address) or its end point identification number, attackers can assume the identity of the device, to intercept messages or inject false data into the IoT system.

One way to detect these attacks is to use digital fingerprinting, which authenticates communication devices. Similar to identifying humans by their fingerprints, devices can be identified by the network’s server. This server must be able to ascertain the identity of the device that originated the message so that it can be trusted by the user application.

The three LPWA communication networks discussed in Section 3 generate a message integrity code (MIC), which they attach to the data that travel over the air interface, from the device to the core network. This MIC is their way of fingerprinting and authenticating their devices, as they use the node’s identification number and a secret key to generate the MIC. The MIC also uses information such as payload data and a frame counter to help the server to check that the data are not corrupted.

Beyond authentication and integrity, fingerprinting is also useful for tasks such as device tracking, resource allocation, and performance tuning, according to [101], which proposed one method of fingerprinting that passively collects data from the physical and data link layers to authenticate the device’s identity.

Passive data collection means obtaining information without introducing additional traffic to the network. For example, a server can profile Bluetooth Low Energy (BLE) devices at the hardware level by collecting advertisement packets. Because the speed at which a node sends advertisement packets is specific to the hardware device, the server analyzes some properties of the incoming data, such as the delay interval between packets and the channel switching sequence, thus providing a fingerprint for the device [102]. As an alternate method to encryption algorithms, this type of fingerprinting can be used to authenticate low-resource IoT devices as software platforms. It was also added to our lightweight primitives in Table 7.

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. One of the new algorithms covered here, the Authenticated Lightweight Encryption (ALE), uses a hybrid approach by mixing AES and a stream cipher called LEX. In a way, AES-CTR was also considered to resemble a stream cipher [44]. Thus, this leads us to continue our research to further investigate hybrid lightweight ciphers, which combine block and stream cipher properties.
• Leverage more robust devices at the edge to implement public-key encryption. Although many survey papers, such as [2,18,24], mention several schemes that use or adapt ECC as a key delivery and authentication method, Lara-Nino et al. [86] proposed a new hardware architecture to implement the scalar multiplication to generate the session keys; it is still unclear if ECC keys can be generated and all the calculations performed at the smart devices. One study made it very clear how ECC-based lightweight cryptography [94] can be used in practical IoT systems. It included experiments in a testbed where ECC was used at the edge, in the gateways, such as Wi-Fi access points or a Sigfox base station. Such devices connect the IoT devices to the public internet. Located at the edge network, they support the smart device’s mobility and can process the smart device’s data (such as filtering sensor data). The proposed scheme uses ECDH as the public/private-key algorithm and to generate the session key for the AES symmetric encryption. Thus, a strong end-to-end encryption exists between the gateway and the application server. The authors explain that the smart device uses a “low key” to encrypt data to the gateway at the edge to provide a minimum level of security. This resembles the proposal by Khan et al. [21], who advocated for applying security at the more powerful nodes that reside at the edge or fog network of the IoT system, which they call ”end-through-node-to-end encryption”.
• Customize or augment the application layer security of standard communication protocols. The only communication technology reviewed in this paper that provided end-to-end encryption was LoRaWAN. Even using LoRa, it is recommended to implement one’s own application-level encryption to provide the required level of end-to-end confidentiality for one’s application. The next application example explains this idea well, in which we use Zigbee but implement our own application layer security scheme in a hybrid FPGA/microcontroller module to protect the data.

Example Application. This review is part of a larger research project, which is developing different IoT prototypes. One of them is a vehicle-to-vehicle (V2V) communication system, which is an automated system of a lead–follow vehicle. One of its applications could be logistics. Based on our first lesson learned, we have communication in one direction only, with the lead car supporting only encryption and the follow car supporting only decryption. Based on our second lesson learned, this system’s network environment is not a safe network and does not have any physical protections.

In this V2V prototype system, the standard IoT communication technology is Zigbee. It has enough bandwidth to support the frequent updates sent from the lead car to follow the vehicle within a short distance. To control the following vehicle, the delay between updates should be less than 10 ms. Therefore, this application has strong confidentiality and real-time requirements. Processing delays due to security algorithms can impact the proposed operation of the system.

As for security, the V2V system currently uses security level zero at the link layer. To compensate for this, a new application layer security protocol is being developed. The micro-controller used in this project is the Mixed Signal Processor 432 (MSP432) from Texas Instruments, which is an ARM-based micro-controller that supports AES encryption. To allow us to customize the application layer security, a hybrid ARM-FPGA module is being developed that will allow us to experiment with additional algorithms at the hardware level.

In this prototype, there is an issue to solve in regard to the AES master key. Currently, it is hard-coded in both the lead and follow cars. The next phase of this project should support one of the key delivery methods surveyed in [18]. Additional work is needed on the authentication, to ensure that a rogue lead car does not take over the system.

In summary, this is an example of an IoT prototype system. It shows an application that uses available techniques described in this review and related studies. It also shows some of the challenges in securing the key at the device and ensuring that the latency and block size do not impact the control of the vehicles.

In future work, the concepts discussed in this paper will be evaluated in the V2V prototype. One potential approach is to implement in our hybrid ARM-FPGA module a mix of two lightweight AES concepts studied in this paper: the authenticated AES approach and hybrid stream cipher LEX. The authenticated AES would use four rounds of encryption, with LEX using the masked AES approach of using false keys at the four rounds. Another approach is to implement in the FPGA module one of the ISO/IEC 29192 lightweight standards, such as the PRESENT block cipher.