2. IoT Security Challenges
Lack of a secure development (SC1): functional requirements are the primary emphasis of both conventional software engineering procedures and IoT systems engineering techniques. With IoT systems, however, security is rarely a top priority throughout the software development process because the installation of functional features receives more attention, leaving security requirements to be addressed once the product is finished, according to El-Attar and Abdul-Ghani 
. Hence, this type of approach is inadequate, and IoT systems must include security standards or recommendations into them from the ground up. In order to do this, the authors have already put up a thorough list of security and privacy standards for IoT assets, particularly for physical items and protocols 
Tight resource constraints (SC2): different hardware limitations in terms of processing speed, storage capacity, and battery life may apply to IoT gadgets. Which is why, given the hardware capabilities of some IoT objects such as mobile phones and tablets, conventional security techniques such as AES can be applied directly to those devices. For instance, according to Taleby et al. 
, the Windows 10 Mobile employs the same security features (such as the Windows Hello mechanism) as the Windows 10 and Windows 11 Operating System (OS) for personal computers to provide protection against emerging security threats. Nevertheless, ordinary IoT gadgets (e.g., presence sensors and smoke detectors) can not implement such techniques.
Features specific design (SC3): the majority of IoT items were created with specific purposes and environments in mind. Building similar defensive mechanisms for various IoT gadgets that operate in heterogeneous contexts and provide a variety of activities and services is therefore not practical. Jeongnyeo 
established mitigation approaches for IoT devices based on three key elements: (i) functionality, (ii) attributes, and (iii) capabilities.
Changes in security requirements (SC4): depending on the state of a larger system in which an IoT device is a part, the security needs for that object may change. One might imagine that a modern car has multiple embedded smart components. The state of the car has a significant role in determining which of these components needs to be secured the most. For instance, the anti-lock braking device is the most important one when the automobile is moving. On the other hand, if the car is stationary the most crucial one is a glass break detector device 
Update mechanisms (SC5): the update procedures of IoT objects have a significant impact on their security. For example, an IoT object meant to receive updates locally may need less security measures than an IoT object designed to receive updates remotely. It implies that any device that needs to securely update its firmware via a network should first establish a secure channel with the server and then verify the accuracy of a new firmware image. However, when it comes to local firmware updates, just the legitimacy of the individual installing newly released firmware into the object must always be verified 
. According to El Jaouhari and Bouvet 
, the challenges are still ranging from interoperability issues with a lack of standardisation efforts, to the actual device management and establishment of the trust chain for the secure Firmware Over-The-Air process.
Objects’ mobility (SC6): the mobility of IoT objects is one of their key characteristics, with security greatly depending on its location, whether static or dynamic. For various reasons, a dynamic object requires additional security measures in comparison to a static one. The dynamic object might be linked to unidentified assets that show up in various situations. Therefore, according to Sen 
, such object should be equipped with distinctive safeguards such as an end-to-end security to protect its communications with other objects, tamper-proofing techniques to avert physical attacks, side-channel analysis to avoid data leakage, and a secure firmware update method. Whereas the static object might constantly be connected to trusted assets, which are in charge of guaranteeing its security.
Importance of IoT objects (SC7): the importance of an IoT object affects its security. For instance, in a WSN, a sink node requires more defensive strategies than sensor nodes because it manages the entire network in addition to gathering, aggregating, and processing data from sensor nodes. The malicious WSN nodes that continuously send undesirable signals toward the sink node or a base station could, according to Yang et al. 
, halt the entire network.
Uncontrolled environment (SC8): because some IoT objects may be deployed in remote locations and left unattended, they are vulnerable to physical attacks, such as malicious manipulation of Integrated Circuits (ICs) 
. An attacker could clone the IoT device, steal it for further research to determine their security characteristics or steal secret keys stored on it 
3. IoT Attacks Vector
In the state of the art, conventional security goals have been divided into three main groups: (i) Confidentiality, (ii) Integrity, and (iii) Availability, referred to as the Confidentiality, Integrity, and Availability (CIA). Confidentiality is achieved through a set of rules that limits access to only authorised objects or users. Integrity, in the context of IoT, is also of paramount importance, as it assures the accuracy and completeness of IoT data. IoT availability is an indispensable requirement as well, since it ensures the availability of IoT objects along with their data to its users. In spite of the popularity of CIA, it fails to deal with novel threats appearing in a collaborative environment 
. Toward this end, Cherdantseva and Hilton 
suggest a thorough set of security goals, known as the Information, Assurance, and Security (IAS) octave, by investigating a huge amount of information in the literature in terms of security. An overview of the security goals proposed by the IAS octave, along with their definitions and abbreviations in link with IoT environment is presented in Table 1
Table 1. IoT Security goals as defined by IAS octave.
Researchers enumerate common attacks against IoT and investigate their violated security goals. The selection of the attacks is based on the previous work 
, cross-linked with the latest surveys 
. More specifically, researchers annotate with ‘
’ symbol when a security goal in question is violated by the described attack. The summary is outlined in Table 2
Table 2. Violated security goals per attack.
Eavesdropping (AT1): intentionally listening to packets over communication links is called eavesdropping, and it is a powerful attack against communication channels if packets are not encrypted during transmission. The main goal of such attack is to intercept, read, and alter the communication packets. Three security goals, namely CONF, NREP, and PRIV, are affected by this type of attacks. The CONF and PRIV security goals are violated, since the attacker is indirectly revealing some private information by listening to communication channels that are not encrypted nor well protected. The NREP is compromised, as the attacker could recognise a private key of an object or a sender in case of a weak cryptographic algorithm and thus use such key to sign some packets and send them to other objects or recipients without revealing his/her true identity.
Physical attacks (AT2): IoT objects may be deployed in various environments where supervision of the objects is not always possible, making them susceptible to physical attacks. These attacks include, but are not limited to, vandalising circuits, modifying OS, and extracting valuable cryptographic information. In this type of attack, all security goals can be violated, as the attacker potentially has full control over the IoT object. As demonstrated by Deogirikar and Vidhate 
, not only can the attacker physically harm the IoT device, but also cause damage to a bigger IT system.
Side-channel attacks (AT3): as IoT objects execute their normal functions, there is a risk that critical information may be revealed (e.g., the secret keys). This type of attacks may happen because of the lack of secure techniques of processing and storing IoT data (e.g., storing unencrypted data directly on IoT objects). It is also worth mentioning that IoT objects may be vulnerable when not equipped with secure wireless protocols to transmit data. For example, an electromagnetic wave emitted by an object may reveal sensitive data about both the object and its users, according to 
. Three security goals (CONF, INTG, and PRIV) are directly affected by this attack. The CONF and PRIV are violated as the attacker could reveal sensitive data about the object and its users by analysing its side-exposed features, such as algorithms and power consumption. Having discovered some security parameters (e.g., encryption keys), the attacker could modify, for instance, the transmitted data.
Malicious object insertion (AT4): maliciously adding an object to the existing set of objects by duplicating another object’s identification number to either corrupt the packets or misdirect them is the main goal of this attack. Therefore, this type of attack may cause a huge drop in the network performance, directly affecting AVAL and TRST security goals. Moreover, upon arrival of messages at a replica, an attacker could not only gain access to different security parameters (e.g., encryption keys), but also revoke authorised objects, since the attacker could execute an object-revocation protocol exposing CONF, NREP, and PRIV. In summary, this attack violates all security goals, as the attacker has capability to misdirect, drop, decrypt, and corrupt the messages.
Routing attacks (AT5): in 
, the authors illustrate several attacks such as Gray hole, sybil, and worm hole designed specifically to target how IoT packets are directed. The consequences of such attacks include, but are not limited to, dropping, spoofing, and misdirecting packets. The simplest form of such attacks is known as modifying attack in which routing information is illegally manipulated by an attacker. The CONF, INTG, and PRIV security goals are violated as the attacker is indirectly capable of disturbing routing paths and spoofing packets. ACNT is also affected as the attacker could drop or misdirect some messages. Finally, NREP and ACNT are endangered as the attacker has a capability to disrupt the delivery of the packets.
Malicious firmware (AT6): several manufacturers such as Apple and Sony have been using Over-the-air (OTA) methods to update their objects which were already being deployed in power grids, smart homes, smart cars, and more. Due to the large number of IoT objects that require updates, a trusted server has been used by manufacturers to publish or push newly released updates of their objects. This method, however, is vulnerable to a single point of failure because of Denial of Service (DoS) attacks and a huge number of valid update requests sent simultaneously to the server. This attack violates all security goals as the attacker has full control over IoT objects.
4. Mitigation Techniques
The following section presents the summary and classification of existing mitigation techniques relevant for the selected attack vector presented previously. Table 3 outlines the analytical correlation between each mitigation technique and related attack.
Table 3. Attack vector correlation to mitigation techniques.
Link layer security (MT1): IP-based communication in IoT is mainly reliant on IPv6 networking for Low power Wireless Personal Area Networks (6LoWPAN) 
, which is dependant on the IEEE 802.15.4 link layer and provides hop-to-hop security. It implies, that each object in the communication link should be trusted without authentication, as well as key management, time-synchronised communications, and reply protection. To address the lack of reply protection as well as time-synchronised communication, the IEEE 802.15.4e extension (modification) was introduced in 2012 by the IETF 
. It is critical to understand that link layer security cannot safeguard packets once they leave its network. Several security solutions have been offered to address this issue. Roman et al. 
suggest a wireless sensor network key management system. This type of solution increases security at the link layer. According to ArchRock Corporation 
, PhyNET secures a link between a border router and nodes using IPsec in a tunnel paradigm. Transport layer security (MT2): end-to-end security can be provided by both Transport Layer Security (TLS) and Secure Sockets Layer (SSL). Because they enable authentication, key exchange mechanisms, confidentiality, and integrity, these systems have been widely utilised to secure communications over the traditional Internet. TLS and SSL, however, cannot be utilised directly for IoT for two reasons. First, TLS is used over TCP, which is not an appropriate approach for IoT gadgets due to their restricted resources. Second, TLS/SSL session establishment and key exchange necessitate a series of packet exchanges. SSL and TLS, on the other hand, have been recommended as IoT security solutions. Hong et al. 
presented an SSL-based security solution for smart objects. According to their findings, a full SSL handshake, including packet exchanges, takes 2 s to complete. Datagram Transport Layer security (DTLS) is introduced to provide security means similar to TLS; however, it is built on top of UDP. Kothmayr et al. 
present a two-way authentication mechanism for IoT, which is strongly reliant on existing Internet standards, particularly the DTLS protocol. This technique was implemented through the exchange of x.509 certificates containing RSA keys and an authenticated DTLS handshake.
Network layer security(MT3): these methods are divided into two categories: 6LoWPAN and Routing Protocol for Low-Power and Lossy Networks (RPL). The IETF has standardised 6LoWPAN as a network layer protocol. It allows Internet access for resource-constrained objects thanks to a header compression method. 6LoWPAN, on the other hand, does not offer security mechanisms or key management. Kothmayr et al. 
present unique compressed security headers appropriate for 6LoWPAN to provide end-to-end network layer security. Such security headers make it easier to integrate 6LoWPAN with IP Security architecture. Raza et al. 
propose an IPsec extension appropriate for 6LoWPAN to provide IPsec-based security for IoT items. In terms of energy usage, processing time, and packet size, 6LoWPAN/IPsec is a suitable solution for securing IoT items, as opposed to link layer security. RPL is a network layer protocol that is also IETF-standardised. It explains the RPL packets sent over ICMPv6 between Low-Power and Lossy Network (LLN) objects. Within the LLN, these packets constitute a routing table. The RPL specification defines three types of security: unsecured, authenticated, and preinstalled.
Firmware update methods (MT4): are either remote or direct. A server node broadcasts the availability of a new version of a firmware for remote update. The announcement of the update is forwarded, by any node with the latest update, to all nodes in its vicinity. Nodes compare their current firmware to the new version and initiates the upgrade, if needed, with the advertiser. For security, all requests, answers, and data packets should be authenticated and encrypted. Law et al. 
point out specifically that possible disruptions from DoS attacks should be dealt with at each stage of this complex process. Lastly, an end user attempting to install manually a firmware should be authorised and authenticated.
Intrusion detection system (MT5): the primary goal is to ensure that general policies are not violated through the usage of a continual monitoring procedure. By tracking aberrant requests to objects, it gives a reliable approach to counteract both battery-draining and sleep deprivation attacks. Saiful Islam Mamun et al. 
reflects on the continuing research for monitoring edge nodes and counteract potential attacks at this level.
Side channel protection (MT6): provides an effective approach for detecting both hardware Trojans and malicious software on IoT devices 
. The presence of a Trojan in an IoT object or circuit affects its components, the most frequent of which being power and gates and has the potential to alter heat distribution on the IC. The survey from Sadhu et al. 
, highlights the feasibility of detecting rogue firmware through side-channel analysis.
Decommissioning methods (MT7): eventually IoT objects will reach a point when they must be decommissioned; thus, these objects must be withdrawn and cannot be reintroduced to the network. Notwithstanding the relevance of decommissioning in addressing various security and privacy issues, there has been little research and development in this area. Smart Card Alliance 
has proposed two options for decommissioning. To begin, the objects can be reset to their factory default settings. Apart for the minimum security parameters, this option deletes all data in such objects. The second option is to prevent blocked objects from re-joining a network until their statuses on the server have been updated.
Secure bootstrapping (MT8): Heer et al. 
state the importance of the architecture impacting the secure bootstrapping technique implementations. Using a Diffie–Hellman algorithm, two IoTs can agree on a shared secret in a distributed architecture. Numerous protocols, including TLS, DTLS, Host Identity Protocol (HIP), and IKEv2, can be used to complete a key exchange and set up security parameters without a trusted party. Nonetheless, putting such methods into practice on severely limited objects is quite challenging. Many research initiatives have been suggested as solutions to this problem, including Diet HIP 
and human memorable passwords, which build trust relationships between IoT products and gateways 
Blockchain solutions (MT9): aim to build transactions or communications between objects in a distributed architecture without the requirement for centralised trust entities, and they has influenced the world of cryptocurrencies. Once a transaction is validated using such technology, it cannot be disputed. Notwithstanding the advantages of the blockchain, its integration into the IoT has a number of obstacles that must be overcome, such as bandwidth consumption, partial anonymity, tremendous processing capabilities examined by 
, and most crucially, time latency.
Hardware-based solutions (MT10): according to Mosenia and Jha 
altering the circuit is one of the best defences against physical, side channel, and Trojan attacks. Employed countermeasures against side-channel assaults are shielding, adding randomised delay and noise. Tamper-proofing mechanisms may be added to IoT products to increase protection against physical attacks. Lastly, Hristozov et al. 
describes a promising hardware-based run-time attestation approach, whereby an item attests its firmware by a remote entity.
Deduplication schemes (MT11): enforce redundant IoT data is be kept once, and links to the duplicates—not the copies themselves—are provided. Because of this, such an approach can be employed as a fallback plan 
. Hence, it is both necessary and difficult to build safe deduplication techniques that can identify identical data copies and store them just once. In order to do this, a number of data deduplication strategies have been put forth in the literature. Based on the location at which data deduplication is completed, these techniques can be broadly divided into two categories (server-side and client-side) 
Anonymisation schemes (MT12): k-anonymity, l-diversity, and t-closeness are the three major categories. K-anonymity is a strategy that protects data holders’ privacy when they release their data. It ensures that each person’s information cannot be recognised from a group of at least k(-1) persons. L-diversity is proposed to reduce K-anonymity inability to avoid both homogeneity and background attacks. Machanavajjhala et al. 
presented a l-diversity privacy strategy that may be used to prevent a variety of assaults (e.g., homogeneity attack). Furthermore, they conduct an experimental assessment to demonstrate that the suggested approach is realistic and can be effectively applied. Li et al. 
proposed the term t-closeness to address the inadequacies of k-anonymity and l-diversity related with attribute inspiration. The authors recommended that the distribution of sensitive information in each set must be close to or connected to the dispersion of sensitive information in the whole database.
Transient data storage (MT13): few studies have focused on handling transitory IoT data created during system executions. The significance of transitory data originates from the processing of data during system execution to form new data views, which may be maintained in storage for user requirements or discarded, and therefore it may lessen hazards connected with such data. Narendra et al. 
suggested a method for handling transitory IoT data that allows such data to be processed, stored, and maintained.
Secure storage schemes (MT14): may be used to prevent IoT data breaches and are divided into two types: cryptographic and non-cryptographic techniques. Jiang et al. 
provides an example of a cryptographic-based system based on Shamir’s secret sharing mechanism for storing data. Storer et al. 
presented a non-cryptographic approach, introducing POST-SHAREDS, a storage format that provides long-term security for IoT data without the need of encryption methods. The security of such a strategy stems from separating data into so many segments and dispersing it over several storage locations.
Searchable encryption (MT15): from the domain homomorphic encryption, another method for protecting data in IoT storage is to conduct information retrieval on encrypted data, known as Searchable Encryption (SE). The basic principle is that an object should index and encrypt its data before sending it, along with an index, to a server. To search for data, the object must produce a trapdoor via which the server may directly run search operations on encrypted data, and encrypt its output as well.
Monitoring and auditing (MT16): is crucial, especially when it comes to preventing data breaches. In order to monitor servers, agents, files, and their configurations, Anand 
have presented a centralised monitoring strategy for cloud applications. This technique offers multi-level notifications, redundancy, and automated recovery to overcome the drawbacks of a centralised monitoring approach, which include scalability and, most critically, a single point of failure. A scalable monitoring system for clouds has been put forth by Brinkmann et al. 
, proposing a sparse management tree that includes a number of parameters and their data gathering protocols. The authors also examine the drawbacks of current intrusion detection technologies and look at the potential of virtual machine level intrusion detection.
Recovery strategy (MT17): despite the significance of providing high availability and disaster recovery for IoT storage, the state of the art only has a few research suggestions. The issue of uploading IoT data from a collection of various sensors and the production of various replicas of this data on distributed storage in the cloud has been examined by Kumar et al. 
. The availability of numerous distributed data centres, sometimes known as mini-clouds, is a prerequisite for data recovery strategies.
Access control methods (MT18): can be categorised into four groups: (i) Attribute-Based Encryption (ABE), (ii) Discretionary Access Control (DAC), (iii) Mandatory Access Control (MAC), and (iv) Role-Based Access Control (RBAC). The system administrator will have the ability to control the responsibilities and rights of the customers after integrating MAC into an IoT system. Further allowing the system administrator to alter access policies and denying users access to the network. Sensitive systems, such as those used by the military and research institutions, can include this kind of access technique 
. Customers will be able to change the access rules for any items if DAC is integrated into an IoT system. If an attacker is able to access a client account, this strategy is quite risky. As a result, giving a consumer complete access to the IoT system is not a good idea. Customers can acquire access to resources based on their roles and responsibilities in the system if RBAC is implemented into an IoT system. ABE enables flexible one-to-many encryption without knowing who would access the information. It also highlights the fine-grained access approach for outsourced data. In ABE, a customer is identified by a collection of attributes that may be used to determine the client’s access policy.
Secure IoT OSs (MT19): designing and building a specific IoT environment OS is critical for providing object security at all levels. Javed et al. 
conducted an in-depth analysis of existing techniques and validated security as a missing component that must be addressed immediately. Their assessment verified open problems, such as the provision of data integrity, authentication, and access procedures.
SDN-based solutions (MT20): primary goal of such technology is to separate the network control plan from the data plan. This type of separation would allow for dynamic network administration, centralised setup, and network control 
. Objects (e.g., routers, gateways, and switches) in the SDN paradigm cannot make control choices (e.g., forwarding tables), but they may learn such decisions from a centralised entity known as an SDN controller. SDN is a viable approach for addressing various IoT security concerns due to its centralised design.
Application layer security (MT21): depends heavily on the needs of the individual IoT system and application protocol. MQ Telemetry Transport (MQTT) and Constrained Application Protocol (CoAP) are the most relevant in terms of data collection in this context, whereas Advanced Message Queuing Protocol (AMQP), Data Distribution Service (DDS) and Extensible Messaging and Presence Protocol (XMPP) are appropriate for specific service requirements, namely business messaging, instant messaging, online presence detection, and real-time exchanges 
. Aside from issues related to improving application layer security with CoAP, several research works have addressed some common issues such as the lack of mapping techniques between TLS and DTLS, the absence of digital certificates and public-keys, and, most importantly, the enforcement of object security with CoAP 
5. Framework-Based Solutions
Researchers review the existing frameworks of security and privacy guidelines along with their shortcomings. Although the development of a comprehensive set of security and privacy guidelines, covering all IoT assets, is currently an indispensable requirement for building secure IoT systems, a few frameworks equipped with such guidelines have been proposed, which researchers briefly present in the following paragraphs.
Perera et al. 
suggest a list of privacy guidelines for IoT middleware and applications and their data at rest. Such guidelines include, but are not limited to, reducing data granularity, blocking repeated queries, and distributing data storage. However, they do not propose guidelines for different IoT assets such as physical objects (computing nodes and RFID), protocols, and OSs. Moreover, they do not address attacks and threats against IoT, nor do they identify suitable protection measures to implement their guidelines.
, the Broadband Internet Technical Advisory Group (BITAG), suggests an abstract list of security and privacy guidelines (e.g., encrypting communications) for some of IoT assets (computing nodes, applications, and protocols). That said, BITAG neither provides a thorough set of guidelines, nor do they recognise proper security mechanisms to carry out the guidelines. Moreover, attacks and threats against IoT are left untouched.
Open Web Application Security Project (OWASP) proposes a list of security and privacy guidelines for some IoT assets (computing nodes, applications) 
. Nevertheless, the OWASP does not identify attacks and threats against IoT, nor does it discuss the required security techniques to apply its guidelines.
Abdulghani et al. 
propose a comprehensive list of security and privacy guidelines only for IoT data at rest, such as searching on encrypted data, ensuring authorised access, encrypting data storage, and minimising duplicated copies. Moreover, the authors investigate all possible attacks and threats against data at rest and identify a set of protection measures which can be used to implement their guidelines. Moreover, they show the link between their guidelines, attacks, and mitigation techniques.
, the IoT Security Foundation (IoTSF) proposes a complete list of security and privacy guidelines for all IoT assets, except RFID tags. Nevertheless, IoTSF does not address attacks and threats against IoT, nor does it distinguish suitable implementation techniques to accomplish its guidelines.
A comprehensive list of security and privacy guidelines for some IoT assets (computing nodes, RFID, and protocols) is proposed in 
. The authors also investigate all possible attacks and threats against them. Furthermore, they identify proper protection measures to implement their guidelines. Not only that, they also show the link between their proposed guidelines, attacks, and protection measures.
, the authors first state the importance of defining security requirements for IoT objects based on three factors: (i) functionality, (ii) capabilities, and (iii) characteristics. Then, they investigate security threats as well as vulnerabilities of IoT objects, and more importantly they utilise the classification of IoT objects capabilities into different classes to suggest a list of security requirements suitable for each class.
Risk-based security certification is conceptually distinct from existing methods used to address security and privacy issues in the IoT ecosystem because it changes the emphasis from verifying the precise security level to the possible exposure to security vulnerabilities. Baldini et al. 
have provided a certification framework aiming to address the shortcomings of existing Common Criteria certification scheme based on ISO/IEC 15408 standard. The proposed certification process is composed of several steps, ranging from risk analysis and labelling, vulnerability patterns identification to the execution of the test suites. However, in comparison with previously presented frameworks, this approach is prone to be domain specific and heavily depends on the operational context to generate the necessary models and tests.
In a similar direction of the risk-based IoT labelling, Matheu-García et al. 
have proposed a security certification methodology targeting all stakeholders to be able to access the security solutions based on ISO 31000 and ISO 29119. The developed framework demonstrated its applicability in a scenario on automation of security testing with corresponding benchmarking analysis. The focus of such methodology, similarly, is also given to the vulnerability analysis and correlation with a profile or security label. The scope of the common attacks shielding is not explicitly referenced, nor are the targeted guidelines for security and privacy issues provided.