You are currently viewing a new version of our website. To view the old version click .
MDPIMDPI
Search all articles
Sensors
Download PDF
  • Article
  • Open Access

21 April 2023

Guidance Framework for Developing IoT-Enabled Systems’ Cybersecurity

,
and
Centre Universitaire d’Informatique, Geneva School of Economics and Management, University of Geneva, Route de Drize 7, CH-1227 Carouge, Switzerland
*
Author to whom correspondence should be addressed.
Sensors2023, 23(8), 4174;https://doi.org/10.3390/s23084174
This article belongs to the Special Issue Communication, Security, and Privacy in IoT
Version Notes
Order Reprints

Abstract

Internet of Things (IoT) faces security concerns different from existing challenges in conventional information systems connected through the Internet because of their limited resources and heterogeneous network setups. This work proposes a novel framework for securing IoT objects, the key objective of which is to assign different Security Level Certificates (SLC) for IoT objects according to their hardware capabilities and protection measures implemented. Objects with SLCs, therefore, will be able to communicate with each other or with the Internet in a secure manner. The proposed framework is composed of five phases, namely: classification, mitigation guidelines, SLC assignment, communication plan, and legacy integration. The groundwork relies on the identification of a set of security attributes, termed security goals. By performing an analysis on common IoT attacks, we identify which of these security goals are violated for specific types of IoT. The feasibility and application of the proposed framework is illustrated at each phase using the smart home as a case study. We also provide qualitative arguments to demonstrate how the deployment of our framework solves IoT specific security challenges.

1. Introduction

As a result of the development of two emerging technologies, Radio Frequency Identification (RFID) and Wireless Sensor Networks (WSNs), the notion of Internet of Things (IoT) was proposed in 1999 by Kouicem et al. [1]. The fundamental goal of IoT is to smoothly integrate real-world devices into the digital realm by utilising already installed infrastructure such as switches, routers, and gateways. To this end, a number of IoT objects equipped with sensors, actuators, and connectivity protocols have been deployed in multiple domains to offer an enormous business value for customers, organisations, and governments. For instance, smart watches, smart home appliances, and smartphones are examples of IoT diverse applications, all of which were created with the goal of improving the customers’ quality of life and productivity [2]. However, the aforementioned applications and IoT in general have encountered many security and privacy problems, the common examples of which are side-channel attacks, unauthorised conversation, routing attacks, and unexpected use of IoT data [3]. Due to two key characteristics, securing IoT is a complex task in comparison with traditional cybersecurity. The first difference is the IoT objects’ variation in their size and processing power. The second difference is their connectivity capabilities. It is, therefore, possible to apply traditional security mechanisms (e.g., Advanced Encryption Standard (AES)) directly to powerful objects such as smart phones. In contrast, power constrained objects, for instance smart light bulbs, may not be able to apply such techniques directly without some modifications due to their limited resources in terms of battery life, memory storage, and computational power. To this end, a number of of solutions have been proposed in the literature and can be broadly divided into four categories: (i) gateway-based solutions [4,5,6], (ii) IoT stack-based solutions [7,8,9,10], (iii) middleware-based solutions [11,12,13], and (iv) risk-based certifications [14,15,16].
Despite the benefits of using such solutions for addressing some IoT security concerns (e.g., secure communication), they have drawbacks. For instance, using a gateway for securing IoT objects is a matter of compromise. On the one hand, it can be used to address some of security issues such as updating objects’ firmware and providing a secure key management method between IoT objects and the gateway [17]. On the other hand, it introduces a single point of failure in both security and operation. Moreover, flexibility and scalability will be reduced and hindered, as the development of a new IoT application or IoT object requires changes to be implemented into the gateway [18]. Risk-based certification solutions are trying to overcome many limitations such as the possibility of more flexible decisions to decrease time-to-market and provide all involved stakeholders with the same tools for security assessment. The approach is different in its essence as it focuses on the risk analysis and device exposure to potential threats, as well as potential consequences severity.
The absence of frameworks that generally outline accepted security and privacy policies for IoT assets (physical objects, protocols, data at rest, and software suggested in our prior work [19]), as well as their protection measures, is another contributing issue. Such guidelines and their suitable implementation techniques would pave the road for IoT stakeholders such as developers and manufacturers to build secure IoT systems by integrating such guidelines into their systems from the start. In spite of the importance of such frameworks of security and privacy guidelines for IoT to enhance its security and privacy by design, a few research studies have been proposed in this regard [20].
Nevertheless, framework-based solutions require more efforts not only to address their limitations (e.g., poor implementation see Section 2), but also to go beyond such limitations and contribute to make them more secure and reliable. To this end, we develop a novel framework by which different Security Level Certificates (SLCs) are assigned to IoT objects based on their hardware capabilities and existing protection measures. Our framework allows IoT objects to protect themselves either independently when it fulfils the top-tier SLCs or through a dependency association between IoT objects, where a lower tier SLC IoT object is indirectly protected by a higher tier SLC. A detailed explanation of our framework is presented in Section 3.
The main contributions of this work are the following:
  • Mapping of IoT attacks and security goals violation.
  • Identification of most common limitation of existing frameworks for IoT security and privacy.
  • Formalisation of a secure IoT framework, capable to assign different SLCs to IoT objects based on their hardware and communication capabilities.
  • Showcasing feasibility of the proposed framework in the context of a smart home.
The remainder of this paper is structured as follows. In Section 2, a review of ongoing security challenges, most relevant IoT attacks and the existing cybersecurity frameworks against security and privacy threats together with their limitations are analysed. Section 3 outlines our research methodology to reason the ground work for the proposed framework for securing IoT objects and presents the formal specification of the SLC framework. Section 4 features a case study to verify SLC methodology feasibility. Section 5, discusses mitigations for IoT specific attacks and threats and the limitations with the application of SLC. The concluding remarks as well as future work is described in Section 6.

3. Methodology

This section is dedicate to the proposed methodology through which different SLCs are assigned to IoT objects based on their hardware capabilities as well as their implemented protection measures such as Intrusion Detection System (IDS), side channel protection, and secure storage schemes. IoT objects equipped with SLC1 or SLC2 indicate that they will have weak protection measures (e.g., Data Link Layer Security (DLLS)) and limited hardware resources. Hence, these objects will neither be deployed in unattended areas, nor will they be connected directly to the Internet. Such objects will depend heavily on objects with SLC3 (acting as gateways) to protect them and manage their communication to the Internet. In contrary, IoT objects armed with SLC3 or SLC4 or SLC5 indicate that they will have strong protection mechanisms (e.g., blockchain-based solutions) and powerful hardware resources. These objects, thus, can be deployed in uncontrolled environments and more importantly can be connected directly to the Internet and protect themselves autonomously. Moreover, Security Level Certificates Framework (SLC Framework) states the communication plan in which different IoT objects can communicate securely with each other or with the Internet based on their SLCs. The proposed framework consists of five main phases, which are described below. An overview of the overall methodology is depicted in Figure 1.
Figure 1. An overview of the proposed methodology.

3.1. Phase 1: Classification

In this phase, IoT assets along with their associated attacks and countermeasures are attributed a specific layer, enabling association to relevant attack vector. At the second step, each IoT object is classified into different category based on their hardware capabilities.

3.1.1. Asset Layer Attribution

Due to the complexity of IoT ecosystem composed of so many enabler technologies (e.g, WSN and 6LoWPAN), it is essential to recognise precisely IoT assets to be able to protect them. To contribute to such objective, many IoT Reference Models (RMs) have been proposed in the literature, such as a three-level model [67], a five-level model [68], and a seven-level model [69]. Even though such RMs simplify the complexity of IoT by breaking it into different layers, they do not address the required building blocks for their layers or levels, which can be used by IoT developers to easily construct their systems. Toward this end, a novel building-blocked RM for IoT was introduced in our earlier work in [19], and IoT assets were divided into four main component layers:
  • Physical layer: consists of computing nodes (RFID readers and sensor nodes) and RFID tags.
  • Communication layer: includes all IoT protocols covering all IoT stack and the existing network infrastructures (e.g., routers and switches).
  • Data at rest layer: involves data stored either in IoT objects or on the Cloud Storage Service (CSS)
  • Software layer: is composed of IoT middleware, IoT applications, and IoT OSs.
It is worth mentioning that the process of identifying all possible attacks and threats against each IoT asset and also recognising their suitable protection mechanisms has been already investigated in the same work. Asset layer attribution procedure is static and is performed once for the initial classification.

3.1.2. IoT Objects Categorisation

In the IoT environment, different types of IoT objects that vary from tiny and lightweight objects (e.g, light bulbs) to powerful objects (e.g, smart phones) are being connected to the Internet or each other to achieve specific tasks. It is therefore unwise to suggest common implementation techniques for all of them, since some objects, for instance light bulbs, would not be able to run them due to their limited resources. Therefore, there is a need to classify IoT objects into different categories based on their hardware capabilities. SLC Framework classifies IoT objects into five categories based on four primary factors: (i) Central Processing Unit (CPU), (ii) memory, (iii) power consumption, and (iv) on-board data storage.
Each factor has a specific weight criteria, and is given a priority in the presented order of appearance. SLC Framework dictates that Category 1 IoT object has minimal hardware capabilities, while IoT object of Category 5 has very powerful processing equipment. IoT objects categorisation procedure is use-case specific and must be tailored for each ecosystem to which framework is applied. An overview of objects classification along with a real example for each category is presented in Table 5.
Table 5. Classification of IoT objects based on their hardware capabilities.

3.2. Phase 2: Mitigation Guidelines

In this phase, a set of security and privacy guidelines are proposed for each asset layer, attributed in Phase 1.

3.2.1. Physical Layer

This layer is susceptible to several attacks and threats, the most popular of which are physical attacks, object replication attacks, side-channel attacks, and Hardware Trojan attacks. The guidelines specific to this layer can be utilised at the early stages of systems development life cycles. For example, one guideline recommends that a hardware secure boot process should be integrated into each IoT object. If such a guideline is implemented by developers or manufacturers, it will prevent such object from running malicious code. Table 6 highlights the suggested security and privacy guidelines together with the reasoning and recommended mitigation implementation techniques, based on our previous research [19].
Table 6. A summary of the suggested guidelines for physical layer along with their countermeasures.

3.2.2. Communication Layer

Similarly, this layer is vulnerable to several attacks including, but not limited to, side channel attacks, malicious packet modification, routing attacks, malicious node injection, and eavesdropping. In general, it is advised to equip each IoT object with mitigation techniques such as Network layer security, Application layer security, and transport layer security, to prevent malicious packets modification. An overview of the proposed guidelines for communication layer, along with their purpose and protection measures is presented in Table 7.
Table 7. A summary of the suggested guidelines for communication layer along with their countermeasures.

3.2.3. Data at Rest Layer

Data at rest either on IoT objects or in the cloud is also susceptible to different attacks, such as misuse of data remnants, linkage attacks, data manipulation, insider attacks, side-channel attacks, and homogeneity attacks. To lessen such attacks, security and privacy guidelines can be implemented by either IoT developers, manufactures, and providers from ground up so that IoT data stored by their applications is fully protected. The prevention of IoT data leakage, for instance, requires IoT stakeholders to implement a set of techniques into their systems at the start such as monitoring and auditing schemes, SE, anonymisation schemes, and transient data storage. Table 8 outlines our suggested guidelines at this layer, along with their reasoning and mitigation implementation techniques, based on our previous findings [32].
Table 8. A summary of the suggested guidelines for data at rest layer along with their countermeasures.

3.2.4. Software Layer

This layer, composed of IoT application, OSs, and middleware, is also vulnerable to many attacks and threats such as DoSs attacks, Structured Query Language (SQL) injection attacks, weak authentications, malicious requests, and viruses. Having integrated access control mechanisms into IoT applications, OSs, and middleware, such software will be able to prevent malicious requests coming from either adversaries or malicious objects. A summary of our proposed guidelines for this layer, along with their purpose and protection measures is presented in Table 9.
Table 9. A summary of the suggested guidelines for software layer along with their countermeasures.

3.3. Phase 3: SLC Assignment

In this phase, an outline of SLCs classification methodology used in SLC Framework is presented, which is a static procedure common to any SLC Framework application. However, the second procedure, the assignment of SLCs to IoT objects, is use-case specific and dynamic by its nature.

3.3.1. SLCs Classification

Classifying SLCs is a fundamental requirement, and it stems from two primary reasons. One is that IoT objects come in different sizes and hardware capabilities. In general, most of IoT objects have limited resources, but this is not always the case since some objects may have powerful hardware resources. Thus, it is impractical to assign common mitigation techniques for all IoT objects. The other reason depends on the environment at which IoT objects are being deployed and operated. Objects operating in a controlled area will require less protection measures as they will always be connected to trusted objects and will always be monitored by human beings or security cameras. On the other hand, objects operating in an uncontrolled environment will need more protection measures, since they will neither be connected to trusted objects, nor will be monitored by human beings or security cameras. To this end, all protection measures suggested to implement our proposed guidelines for previously mentioned IoT assets are classified into five groups known as SLCs, starting from SLC1 to SLC5. The number attached to each SLC indicates its security level, which is very weak at SLC1 and very strong in SLC5. This is because SLC1 includes only two protection measures (MT1: Link layer security and MT8: Secure bootstrapping), whereas SLC5 includes almost all mitigation techniques. It is worth noting that the process of assigning and issuing SLCs depends heavily on entities (e.g., IoT manufacturers or IoT developers) that implement our framework. More importantly, it is assumed that such entities are trusted and authenticated so that they will neither issue nor assign fake SLCs. An overview of SLCs classification used in our suggested framework along with their mitigation techniques is presented in Table 10.
Table 10. SLCs classification according to the implementation of the mitigation techniques.
SLC1: this type of SLC implements two mitigation techniques, MT1 and MT8, namely link layer security and secure bootstrapping. Thus, IoT objects with SLC1 are able to encrypt and decrypt packets only at data link layer because of DLLS. In other words, they are capable to provide hop-to-hop security and join or rejoin gateways securely (objects with SLC2) due to their secure bootstrapping techniques. Lacking hardware-based solutions to prevent physical attacks and end-to-end security techniques (e.g., Transport layer security) to provide secure communication channels, objects with SLC1 can neither be deployed in an uncontrolled environment, nor can be connected to the Internet directly. Furthermore, objects with SLC1 are not able to store data locally as they lack secure methods of storing IoT data. They also are not able to update their firmware autonomously since they do not have secure firmware update methods, and they depend on objects with SLC2 to do so. Moreover, objects with SLC1 depend on objects with SLC2 to register their SLCs in objects with SLC5, responsible for tracking of SLCs for all objects.
SLC2: has five mitigation techniques, such as MT1: Link layer security, MT2: Transport layer security, MT3: Network layer security, and MT4: Firmware update methods. IoT objects with SLC2 have capabilities to encrypt and decrypt packets at data link, transport, and network layers. That said, IoT objects with SLC2 can only communicate with the Internet through objects with SLC3, as objects with SLC2 do not have side channel protection measures to prevent data leakage and IDSs to detect malicious packets. In other words, such objects can not connect directly to the Internet. Since such objects have firmware update methods, they are be able to update their firmware by connecting objects with SLC4, which are responsible for managing firmware updates inSLC Framework. Like objects with SLC1, objects with SLC2 are not deployed in an uncontrolled area because they lack required security techniques (e.g., tamper-proofing methods) to prevent physical attacks. Furthermore, objects with SLC2can not store data locally due to the absence of secure techniques to do so. Unlike objects with SLC1, objects with SLC2 are capable to register their SLCs in objects with SLC5 and also communicate with other objects securely, as they have end-to-end security techniques (e.g., Network layer security and Transport layer security).
SLC3: this type of SLC is integrated with 14 mitigation techniques such as MT2: Transport layer security, MT4: Firmware update methods, MT5: Intrusion detection system, and MT19: Secure OS. IoT objects with SLC3 are able to connect directly to the Internet and also manage communication between objects with SLC1 and SLC2 and the Internet. This is because objects with SLC3 are armed with the required protection measures such as end-to-end security techniques, side channel protection methods, secure OSs, and more importantly IDSs to detect malicious packets. Unlike objects with SLC1 and SLC2, IoT objects with SLC3 can not only to deploy and operate in unattended areas, but also to update their firmware by connecting objects with SLC4. Furthermore, IoT objects with SLC3 store their data or data coming from objects with SLC2 temporally on their data storage after simple data processing to offer quick response to objects with SLC2, as they are equipped with transient data storage techniques. Nevertheless, IoT objects with SLC3 lack secure data destruction as well as recovery mechanisms. To this end, such objects store data just for a short period of time (e.g., per an hour). However, such objects communicate with objects with SLC5 to store their data for a long time, as they have suitable protection measures (e.g., secure storage sachems, recovery strategy, and deduplication schemes) to prevent data at rest breaches.
SLC4: this type of SLC will be equipped with 15 protection measures. IoT objects with SLC4 are responsible for managing firmware updates of the all IoT objects equipped with different SLCs. More importantly, objects with SLC4 utilise blockchain-based solutions such as smart contracts proposed in [85] to manage secure IoT firmware updates for all IoT objects participating in SLC Framework. As a consequence, manufacturers, who implemented the framework, can create smart contracts for the newly-developed firmware versions and push them to all objects with SLC4. Having pushed the smart contracts to the blockchain network formed by different objects equipped with SLC4, objects with SLC2, SLC3, and SLC5 are able autonomously query objects with SLC4 and therefore download the latest versions of firmware available for them. That said, time latency to register each smart contract to the blockchain network may take a long time (e.g., 10 min per transaction), but this is not an issue since objects’ firmware updates may be released once per month or week. As objects with SLC4 are used to store the latest versions of objects’ firmware and are equipped with secure decommissioning methods to securely destruct their data when reaching their end-of-life stages to prevent data breaches (e.g., misuse of data remnants).
SLC5: this type of SLC includes all our suggested mitigation techniques, except transient data storage and IDS. As IoT objects with SLC5 are equipped with blockchain-based solutions, such objects are responsible for registering and tracking of all SLCs into their chain. Such objects, however, are not responsible for assigning and validating SLCs, since this process will be archived by entities implemented our framework from the early stages of their systems development processes. Each object in the framework (except object with SLC1) have to register its SLC in object with SLC5. This step is an indispensable requirement for many reasons. One is that objects are not able to change their SLCs, since they are allowed to register their SLCs once in objects with SLC5. Another reason is that it eases the communication process among objects with different SLCs, as their public keys will be accessible by all the objects (except objects with SLC1). The other reason is that it detects malicious objects with fake SLCs, as each object is able to verify the SLC of another object by checking its SLC in the chain in objects with SLC5. More importantly, fake objects are placed in a revocation list by objects with SLCs5, and all objects (except object with SLC1) are then notified to stop communication. Like objects with SLC4, objects with SLC5 are able to deploy and operate in uncontrolled environments, and can destroy their data in a proper way. Unlike objects with SLC4, these objects will provide a recovery strategy of their data, and most importantly are responsible for integrating legacy objects.
It is clear that the framework provides a common method by which all objects (except objects with SLC1) are able to communicate with each other securely. This is because objects with SLC3, SLC4, and SLC5 implement the same protection measures in Transport layer security and Network layer security.
Furthermore, cost-effectiveness is an important factor when it comes to securing IoT devices from cyberthreats and implementing appropriate countermeasures, especially since these systems frequently have limited hardware resources. To make the most use of limited resources, countermeasures must be prioritised depending on their effectiveness and resource requirements. Resources can be allocated more efficiently by focusing on the most critical countermeasures. Furthermore, it is encouraged to employ lightweight security protocols that do not create an undue cost on the system. Protocols such as TLS, lightweight cryptography, and CoAP are excellent examples of such lightweight security measures. Finally, implementing security by design is crucial for ensuring that security is an integral part of the IoT system. By incorporating security from the design stage, countermeasures can be implemented without introducing significant changes to the system, which can be costly and time-consuming. By adopting these strategies, IoT systems can better balance the need for security with resource constraints.

3.3.2. SLC Attribution

As we have classified IoT objects based on their hardware capabilities into five categories (see Table 5) and SLCs based on their mitigation techniques into five levels (see Table 10), it is crucial to present the link between them. SLC Framework defines that IoT objects in Category 1 have limited hardware resources, therefore they can only implement SLC1, as it has only two mitigation techniques. However, such objects will not be able to implement SLC3, or SLC4, or SLC5 due to their limited resources. Similarly, IoT objects in Category 2 are capable to implement either SLC1 and SLC2, as they have required hardware capabilities to do so. Unlike objects in Category 1 and Category 2, objects in Category 5 have powerful hardware resources to implement any one of SLCs.
It is worth stressing that the process of assigning SLCs to IoT objects must be performed with caution. This is because the improper assignment of SLCs to IoT objects may lead to instantiation of insecure objects despite having strong hardware capabilities. For instance, assigning SLC1 or SLC2 to objects in Category 5. Table 11 states the SLCs that are suitable for each category.
Table 11. Assigning SLCs to IoT objects.

3.3.3. SLC Implementation

In regard to the implementation and to address security concerns in IoT devices with limited memory resources, it is necessary to integrate SLCs within the firmware of devices that have low hardware capabilities for IoT objects identified as SLC1 to SLC4. However, for SLC5 devices which have strong hardware capabilities, the security level assignment can be added during the framework deployment by the developer. This allows for a more efficient use of memory resources within IoT devices and ensures that they are able to communicate securely with other devices in the network or with the Internet.

3.4. Phase 4: Communication Plan

Defining a communication plan between objects, in our framework, depends heavily on their SLCs to minimise the risks associated with weak links and also reduce unexpected used of IoT data. To this end, object with SLC1 can only communicate with objects with SLC2 due to their weak protection measures. Not only that, such objects are not able to communicate with objects having the same SLCs as these objects may have different link layer protocols (e.g, IEEE 802.15.4 and Bluetooth). To do so, they depend on objects with SLC2 to perform a required translation between these protocols. Unlike objects with SLC1, objects with SLC2 can communicate with all objects in the framework as long as objects with SLC3, SLC4, and SLC5 operate the same algorithms or mechanisms implemented by objects with SLC2, in their Transport layer security and Network layer security. Nevertheless, such objects can not communicate with the Internet without using object with SLC3. Unlike objects with SLC1 and SLC2, objects with SLC3, SLC4, and SLC5 can communicate with the Internet and more importantly communicate with all objects easily (except objects with SLC1). Table 12 summarises the proposed communication plan among IoT objects equipped with SLCs.
Table 12. The suggested communication plan.

3.5. Phase 5: Legacy Integration

The integration of legacy objects, i.e., IoT objects not supporting the SLC Framework, with supported objects is a fundamental requirement towards achieving compatibility in IoT. Toward this end, we propose a method that will allow legacy objects to communicate with supported objects in a secure manner.
Figure 2 illustrates an example on the integration of the legacy objects with objects developed according to our suggested framework. First, a legacy object, if it in the range of the network, tries to communicate with the SLC Framework’ objects, except for objects with SLC1 and SLC2 due to their restricted communication plan (illustrated with arrow 4 in red). Second, upon receiving the request from the legacy object, our object first checks if that object has a SLC. If not, it sends the request to any objects with SLC5, as they are responsible for integrating legacy objects with our objects (illustrated by arrow 1 and 2 in green). Third, an object with SLC5 suggests a set of algorithms that should be implemented in a transport layer of the legacy object to enable communication with other objects with an end-to-end security (arrow 3 in green). If the legacy object lacks such algorithms or is not able to implement them, this legacy object is rejected. In summary, a legacy object is able to communicate with objects with SLC3 and above as long as it uses the same protection measures in its transport layer implemented by those objects.
Figure 2. Integration the legacy objects with our framework.

4. Case Study: Smart Home

This section illustrates how SLC Framework can be utilised to develop a secure smart home system as a simplified case study to present more clearly the benefits of the suggested framework. Nevertheless, the proposed methodology is domain agnostic, and thus it can be applied in other IoT domains. SLC Framework consists of static and case-specific procedures, and validation of the second type of procedures is demonstrated below through the presentation of the necessary execution steps to be performed by IoT developers or software engineers.

4.1. Step 1

First, all IoT objects operating in smart homes are identified and then classified according to Phase 1 of SLC Framework. With the advent of IoT vision in which most of the physical objects around us are connected to the Internet, the number of IoT objects functioning in smart homes will be almost endless [19]. Such objects include, but are not limited to, light-bulbs, smart switches, microwaves, dishwashers, TVs, projectors, and smart phones. To this end, we classify smart home objects into eight groups such as smart detectors, household objects, and consumer objects. Furthermore, each object is attributed category level, as per IoT Objects Categorisation procedure, which depends on hardware capabilities as well as their functionalities and location. For instance, consumer objects have very powerful resources and can be used in multiple purposes (e.g., control other objects), while smart detectors have very limited resources, and their main objectives are to detect changes inside the smart home (e.g., detect motion), also depicted in Figure 3.
Figure 3. Smart home objects’ categorisation.

4.2. Step 2

Next case-specific procedure to be followed is stemming from Phase 3 of the SLC Framework. Here each object is assigned an SLC. Considering the grouping schema proposed in previous step, objects belonging to the same group can have different SLC. For instance, smart detectors will have SLC1, whereas camera objects have SLC2 or SLC3. The process of assigning SLCs for each group depends on many factors: (i) hardware capabilities, and (ii) location at which such objects are being deployed.
To this end, smart detectors, for example, are equipped with SLC1, since such objects have very limited resources, no direct Internet access, are deployed inside homes, and, more importantly, have weak protection measures (MT1 and MT8). In contrast, consumer objects in smart homes according to our framework have either SLC4 for smart phones or SLC5 for laptops. This is because such objects (e.g., phones and laptops) have very powerful resources, and they are equipped with most of our suggested mitigation techniques. More importantly, objects with SLC4 have unique responsibilities compared to objects with SLC5. Objects with SLC5 are equipped with blockchain solutions to register and track SLCs for all smart home objects, detect fake SLCs, maintain a revocation list, and integrate the legacy objects into smart home, while objects with SLC4 are responsible for managing firmware updates of the all smart home objects, as they have required protection measures to do so.
It is worth mentioning that smart home objects in SLC Framework are not only used to achieve their specific tasks, but also to carry out other responsibilities due to their SLCs. For example, the main purpose for a smart TV is to allow its users, without the need to connect the TV antenna, to access to several channels which provide movies, music, and programs. Apart from providing such specific task, the smart TV has other responsibilities, such as managing communication between objects with SLC2 (e.g., smart heath objects) and the Internet, since the TV has required techniques to carry out such responsibilities.
Table 13 summarises the process of classifying smart home objects into different categories, along with their mitigation techniques required for each SLC. It is worth noting the assumption on the hardware capabilities of each smart home classification in this case study such as smart detectors, smart health, and customer objects. One can note that all smart home objects have a set of mitigation techniques through which previously mentioned attacks against IoT such as AT1, AT2, AT3, and AT5 are mitigated. A detailed explanation of how the framework will lesson such attacks is presented in Section 5.2.
Table 13. A summary of smart home object classification, along with SLCs.

4.3. Step 3

This step is dedicated to the definition of a secure communication plan among smart home objects, the main purpose of which is to prevent unexpected use of smart home data. Although smart home objects are classified into several groups, such objects are able to interact with each according to the suggested communication plan, which depends entirely on objects’ SLCs. For example, smart detectors equipped with SLC1 are able to communicate with indoor security cameras, energy and lighting, smart health, and household appliance, as long as such objects are located within the coverage area of smart detectors signals. Nevertheless, smart detectors can not communicate with smart phones and tablets, laptops, gateways, and the Internet.
An overview of the communication plan in which smart home objects can communicate securely with each other, the Internet, and legacy objects is presented in Table 14.
Table 14. The suggested communication plan for smart home objects.

4.4. Step 4

Finally, the last step is dedicated to the illustration on the smart home seamless and secure integration of the legacy objects. A legacy object inside the smart home will attempt to interact with any objects such as gateways and consumer objects in smart home except objects with SLC1 and SLC 2 (e.g., smart detectors and smart health) due to their limited communication plan. However, the legacy objects are not able to communicate with smart home objects with SLC3 (home entertainment), SLC4 (phones and tablets), and SLC5 (laptops), unless they first communicate with objects with SLC5 and then receive their SLCs from them.

5. Discussion and Future Work

A summary of the previously mentioned research proposals is presented in Table 4, along with our intended objectives. It is not so difficult to recognise their limitations while going through them. This article, therefore, is directed to overcome those shortcomings that can be categorised as follows: (i) the lack of a thorough set of security and privacy guidelines for IoT assets, (ii) the absence of proper mitigation techniques to carry out such guidelines, (iii) the need of attack investigations related to IoT systems, (iv) the necessity of mitigation techniques classification as well as IoT objects classification, and (v) the need of a communication plan so that IoT objects will be able to communicate securely with each other or with the Internet.
In what follows, an illustration on how SLC Framework alleviates the attacks and threats against IoT and solves some IoT security challenges.

5.1. Analysis on IoT Security Challenges

In this part, qualitative arguments are offered to illustrate how the proposed framework can be used to address previously discussed IoT security challenges.
Lack of a secure development (SC1): SLC Framework’s Phase 2 is explicitly addressing this challenge. More specifically, a set of security and privacy guidelines is proposed, covering all IoT assets (physical objects, protocols, data at rest, and software), along with their appropriate mitigation implementation techniques. Integrating such guidelines and techniques by developers or manufacturers into their IoT systems or products from the early stages of development (life cycles) will lead to develop secure system, which in turn improves security and privacy by design for IoT.
Tight resource constraints (SC2): it is unrealistic to assign common protection measures for IoT objects, since such objects may come in different sizes, varying from resource-limited objects such as motion detectors to resource-rich ones such as smart phones. Smart phones, for example, can implement traditional security mechanisms, while it seems to be very difficult to apply such techniques in motion detectors without some modifications. To this point, the classification of objects into five categories, as per Phase 1 of the proposed framework is based on their hardware capabilities. Furthermore, different mitigation techniques are assigned accordingly in Phase 2 of the SLC Framework. For instance, objects in Category 1 implement only a few protection measures suitable to their limited resources, whereas objects in Category 5 implement almost all suggested protection measures due to their powerful hardware capabilities.
Designed for specific Tasks (SC3): being designed to carry out specific tasks and deployed in different environments, IoT objects require different mitigation techniques. In other words, it is wise to assign different protection measures to IoT objects based on their main functions or tasks. To this end, the proposed framework assigns different protection measures to IoT objects based on their tasks and hardware resources, as dictated by Phase 2 and Phase 3. For example, as the main goal of objects with SLC5 is to register and keep track of all SLCs, such objects thus are equipped with blockchain solutions to do so. In contrary, objects with SLC1, SLC2, and SLC3 are not armed with such solutions, as they are not designed to accomplish such goal.
Update mechanisms (SC5): as the security of IoT objects relies on a method in which such objects receive their newly released updates either locally or remotely, the proposed framework thus assigns different mitigation techniques for IoT objects as per Phase 3. For example, objects with SLC1 will not have firmware update methods, as they depend entirely on objects with SLC2 to update their firmware, while other objects with SLC2, SLC3, SLC4, and SLC5 will be equipped with such techniques to independently update their firmware.
Objects’ mobility (SC6): since the location of IoT objects either static or dynamic plays a key role in defining their security requirements, our framework therefore assigns different mitigation techniques for such objects based on their mobility. For instance, objects with SLC1 and SLC2 have a few protection measures, as they always interact with each other or with objects through SLC3. On the other hand, objects with SLC3, SLC4, and SLC5 have more mitigation techniques due to their communication with each other, the Internet, and legacy objects.
Uncontrolled environment (SC8): the environment at which IoT objects will be deployed and operated plays a key role in determining their proper mitigation techniques. To this point, IoT objects are classified broadly into two groups: objects operating in controlled environments and objects operating in uncontrolled areas. Thus, objects operating in controlled areas such as objects with SLC1 and SLC2 have a few mitigation techniques, as such objects always are deployed in attended areas and are monitored by human beings or security cameras to prevent physical attacks. In contrast, objects with SLC3, SLC4, and SLC5 have more protection measures to prevent physical attacks, as such objects may be deployed in unattended environments.
Although most of IoT security challenges presented in Section 2.1 have been addressed in our suggested framework, two security challenges, namely (SC4) ‘Changes in security requirements’ and (SC7) ‘The importance of IoT objects’, are left untouched. We do believe that such challenges can be addressed by developers or software engineers during the analysis phase of an IoT system’s requirements.

5.2. Attack and Threats Mitigation by SLC Framework

The proposed framework that addresses the most important IoT-specific attacks and threats and a brief analysis for each previously presented attack in Section 2.2 is discussed in the next paragraphs.
Eavesdropping (AT1): to mitigate such attacks, our framework prevents any object from sending and receiving its data or packets over unencrypted channels. This can be observed through mitigation techniques included in all suggested SLCs. For instance, objects with SLC1 implement DLLS to send/receive their data in encrypted format to/from objects with SLC2. Similarly, objects with SLC2, SLC3, SLC4, and SLC5 implement either Transport layer security or Network layer security to provide end-to-end secure communication channels between them.
Physical attacks (At2): to lessen this type of attacks, SLC Framework divides its objects based on their environments into two categories: controlled and uncontrolled environments. Objects with SLC1 and SLC2 always are deployed in controlled areas to prevent physical attacks despite not having mitigation techniques to do so, as such objects are always monitored by either people or security cameras. On the other hand, objects with SLC3, SLC4, and SLC5 can be deployed in uncontrolled environments, as they are equipped with hardware-based solutions such as tamper-proofing techniques to mitigate physical attacks.
Side-channel attacks (AT3): to alleviate such attacks, our framework integrates side-channel protection techniques into objects with SLC3, SLC4, and SLC5, whereas objects with SLC1 and SLC2 are be vulnerable to side-channel attacks. However, this is not an issue as these objects are not connected directly to the Internet, nor they are deployed in uncontrolled environments, according to the proposed methodology.
Malicious object insertion (AT4): to this end, the suggested framework forces its objects with different SLCs to first register their SLCs in objects with SLC5. It is worth repeating that objects with SLC5 are shielded with blockchain-based solutions so that other objects such as objects with SLC2, SLC3, and SLC4 are able to track all registered objects and therefore detect the malicious ones. For example, suppose that an object with fake SLC3 tries to communicate with an object with SLC2. The object with SLC2 have to check if the object is trying to communicate with has a genuine SLC3 by contacting any object with SLC5. If not, which is the case in this example, the object with SLC2 will not communicate with it and will notify any object with SLC5 about this incident.
Routing attacks (AT5): to lessen such attacks, the proposed framework compels the majority of its objects to apply Network layer security to prevent such attacks. For instance, objects with SLC2, SLC3, SLC4, and SLC5 have such mitigation techniques against routing attacks. In contrast, objects with SLC1 are vulnerable to such attacks, as they only implement two mitigation techniques. However, the suggested communication plan plays a key role to mitigate such threat, as it restricts the communication of objects with SLC1 to only objects with SLC2. More importantly, communication links or channels between objects with SLC1 and object with SLC 2 are encrypted using link layer security.
Malicious firmware (AT6): to mitigate this types of attacks, SLC Framework utilises blockchain-based solutions (e.g., pushed-based firmware update proposed in [86]) to update their objects securely. Manufacturers, by implemented the framework, will be able to build smart contracts for newly developed firmware versions and will push them to all objects with SLC4. During the update process, some objects with SLC4, called miners, will verify the integrity of pushed firmware, as they will be equipped with consensus protocol. Once the smart contracts are verified by miners, objects with SLC2, SLC3, and SLC5 will be able to send requests to objects with SLC4 and therefore download the latest versions of firmware available for them.

5.3. Limitations of the Study

The risks associated with the insider threats in our framework can be recognised in two processes: issuing and assigning SLCs and firmware updates. As the process of assigning and issuing SLCs depends heavily on entities (e.g, developers or manufacturers) implementing the framework, it is therefore vulnerable to malicious insider threats. It is possible that a developer who is responsible for issuing SLCs could accidentally or intentionally either alter the setting of SLCs or assign SLCs to wrong IoT objects. This is because security of our methodology relies heavily on its communication plan, which in turn depends on SLCs. The object with SLC1 is always connected to objects with SLC2, and is deployed in controlled areas, whereas the object with SLC3 communicates with all objects (except object with SLC1) and is deployed in uncontrolled environments.
Similarly, the blockchain-based firmware update scheme (smart contract and consensus mechanism) utilised in our framework is also susceptible to malicious insider threats despite its benefits in terms of verifying the firmware integrity and preventing DoS attacks. This is because our methodology assumes that all newly released firmware updates are pushed or published by a trustworthy manufacturer. However, this is not always the case because of two reasons. One is that the manufacturer may be compromised by an attacker, and therefore he could use manufacturer’s private keys to sign updates and push them into objects with SLC4. The other reason is that an employee at manufacturer, attacker, may be able (due to given access rights) to send malicious updates from the manufacturer’s server to all objects with SLC5.

5.4. Future Work

As the security requirements within an IoT network may change over time, the proposed framework should be able to adapt accordingly. While this is ongoing work, the current strategy is to use SLC5-enabled IoT devices as servers for certificate validation and device management functions. It ensures the highest level of security and eliminates the risk of a single point of failure. As security requirements change over time, these servers can be used to update and maintain the security of connected devices, ensuring that they remain secure and up to date. Overall, this approach would provide a scalable and efficient solution for managing the security of large-scale IoT deployments. The development of new communication techniques and attack methods is a constant concern for IoT security. To address this, dynamic SLC assignment and machine learning algorithms can be used to enhance the security posture of IoT systems. Dynamic SLC assignment assigns SLCs to IoT objects based on their current security state, ensuring that each object is given the appropriate SLC based on its capabilities and protection measures. Additionally, machine learning algorithms can be incorporated to continuously monitor the IoT system for new threats and adapt the security framework accordingly. This approach ensures that the framework remains up-to-date and effective in addressing new types of attacks.

6. Conclusions

The main goal of this paper is to develop a secure framework for IoT that allows different IoT objects to communicate securely with each other or with the Internet based on their SLCs. First, a classification of IoT objects into five categories based on their hardware capabilities is performed. Objects in Category 1 indicate that they have very limited resources, whereas objects in Category 5 have very powerful hardware capabilities. Second, the mitigation techniques are mapped for different types of objects with the layered approach. Third, each IoT object is assigned SLC, based on their hardware capabilities. SLC1 indicates that object has weak protection measures, while SLC5 implies strong protection measures implemented. Fourth, a communication plan that allows objects not only to communicate securely with each other but also with the Internet is proposed. Moreover, such a plan prevents unexpected use of IoT data. The integration approach of the SLC Framework with legacy objects is concluding the methodology. The proposed framework also can be used to address IoT-specific attacks and solve some of IoT security challenges. To demonstrate the feasibility and application of the suggested framework, an exemplification of the smart-home use case is provided. The future efforts will be focused on the protection against an insider attacker, since it is the main threat to the presented methodology. Moreover, penetration tests on the actual IoT objects equipped with the proposed SLCs are envisioned to evaluate the performance penalty as well as security benefits of using such framework.

Author Contributions

Conceptualisation, H.A.A., A.C. and N.A.N.; methodology, H.A.A.; formal analysis, H.A.A.; writing—original draft preparation, H.A.A.; writing—review and editing, A.C. and N.A.N.; visualisation, N.A.N.; supervision, A.C. and N.A.N.; All authors have read and agreed to the published version of the manuscript.

Funding

This work has received funding from the Swiss State Secretariat for Education, Research and Innovation (SERI) and the Innosuisse—Swiss Innovation Agency and was co-funded by the European Union under grant agreement No 101097267. Views and opinions expressed are, however, those of the author(s) only and do not necessarily reflect those of the European Union or CINEA. Neither the European Union nor the granting authority can be held responsible for them.

Data Availability Statement

Not applicable.

Conflicts of Interest

The authors declare no conflict of interest.

Abbreviations

The following abbreviations are used in this manuscript:
6LoWPANIPv6 networking for Low power Wireless Personal Area Networks
ABEAttribute-Based Encryption
AESAdvanced Encryption Standard
AMQPAdvanced Message Queuing Protocol
BITAGBroadband Internet Technical Advisory Group
CIAConfidentiality, Integrity, and Availability
CoAPConstrained Application Protocol
CPUCentral Processing Unit
CSSCloud Storage Service
DACDiscretionary Access Control
DDSData Distribution Service
DLLSData Link Layer Security
DoSDenial of Service
DTLSDatagram Transport Layer security
HIPHost Identity Protocol
IASInformation, Assurance, and Security
ICIntegrated Circuit
IDSIntrusion Detection System
IoTInternet of Things
IoTSFIoT Security Foundation
LLNLow-Power and Lossy Network
MACMandatory Access Control
MQTTMQ Telemetry Transport
OSOperating System
OTAOver-the-air
OWASPOpen Web Application Security Project
PUFPhysical Unclonable Function
RBACRole-Based Access Control
RFIDRadio Frequency Identification
RMReference Model
RPLRouting Protocol for Low-Power and Lossy Networks
SDNSoftware Defined Network
SESearchable Encryption
SLCSecurity Level Certificate
SLCFramework Security Level Certificates Framework
SQLStructured Query Language
SSLSecure Sockets Layer
TLSTransport Layer Security
WSNWireless Sensor Network
XMPPExtensible Messaging and Presence Protocol

References

  1. Kouicem, D.E.; Bouabdallah, A.; Lakhlef, H. Internet of things security: A top-down survey. Comput. Netw. 2018, 141, 199–221. [Google Scholar] [CrossRef]
  2. Riahi Sfar, A.; Natalizio, E.; Challal, Y.; Chtourou, Z. A roadmap for security challenges in the Internet of Things. Digit. Commun. Netw. 2018, 4, 118–137. [Google Scholar] [CrossRef]
  3. Deogirikar, J.; Vidhate, A. Security attacks in IoT: A survey. In Proceedings of the International Conference on IoT in Social, Mobile, Analytics and Cloud, I-SMAC 2017, Palladam, Tamil Nadu, India, 10–11 February 2017; pp. 32–37. [Google Scholar] [CrossRef]
  4. Chang, C.T.; Chang, C.Y.; Shih, K.P.; Martinez, R.D.B.; Chen, P.T.; Chen, Y.D. An IoT multi-interface gateway for building a smart space. Open J. Soc. Sci. 2015, 3, 56–60. [Google Scholar] [CrossRef]
  5. Rodriguez, J.D.; Schreckling, D.; Posegga, J. Addressing data-centric security requirements for IOT-based systems. In Proceedings of the 2016 International Workshop on Secure Internet of Things, SIoT 2016, Heraklion, Greece, 26–30 September 2018; pp. 1–10. [Google Scholar] [CrossRef]
  6. Treadway, J. Using an IoT Gateway to Connect the ’Things’ to the Cloud. 2016. Available online: https://www.techtarget.com/iotagenda/feature/Using-an-IoT-gateway-to-connect-the-Things-to-the-cloud (accessed on 13 March 2023).
  7. Raza, S.; Trabalza, D.; Voigt, T. 6LoWPAN compressed DTLS for CoAP. In Proceedings of the IEEE International Conference on Distributed Computing in Sensor Systems, DCOSS 2012, Hangzhou, China, 16–18 May 2012; pp. 287–289. [Google Scholar] [CrossRef]
  8. Hartke, K. Practical Issues with Datagram Transport Layer Security in Constrained Environments; DICE Working Group: Beaverton, OR, USA, 2014; pp. 1–23. [Google Scholar]
  9. Sethi, M.; Arkko, J.; Keranen, A. End-to-end security for sleepy smart object networks. In Proceedings of the Conference on Local Computer Networks, LCN, Clearwater Beach, FL, USA, 22–25 October 2012; pp. 964–972. [Google Scholar] [CrossRef]
  10. Kothmayr, T.; Schmitt, C.; Hu, W.; Brunig, M.; Carle, G. A DTLS based end-to-end security architecture for the Internet of Things with two-way authentication. In Proceedings of the Conference on Local Computer Networks, LCN, Clearwater Beach, FL, USA, 22–25 October 2012; pp. 956–963. [Google Scholar] [CrossRef]
  11. Medvedev, A.; Zaslavsky, A.; Khoruzhnikov, S.; Grudinin, V. Interoperability and open-source solutions for the internet of things. Lect. Notes Comput. Sci. 2015, 9001, 169–182. [Google Scholar] [CrossRef]
  12. Fremantle, P.; Scott, P. A survey of secure middleware for the internet of things. Peerj Comput. Sci. 2017, 3, e114. [Google Scholar] [CrossRef]
  13. Renner, T.; Kliem, A.; Kao, O. The device cloud—Applying cloud computing concepts to the internet of things. In Proceedings of the 2014 IEEE International Conference on Ubiquitous Intelligence and Computing, 2014 IEEE International Conference on Autonomic and Trusted Computing, 2014 IEEE International Conference on Scalable Computing and Communications and Associated Workshops, Bali, Indonesia, 9–12 December 2014; pp. 396–401. [Google Scholar] [CrossRef]
  14. Baldini, G.; Skarmeta, A.; Fourneret, E.; Neisse, R.; Legeard, B.; Le Gall, F. Security certification and labelling in Internet of Things. In Proceedings of the 2016 IEEE 3rd World Forum on Internet of Things, WF-IoT 2016, Reston, VA, USA, 12–14 December 2016; pp. 627–632. [Google Scholar] [CrossRef]
  15. Matheu-García, S.N.; Hernández-Ramos, J.L.; Skarmeta, A.F.; Baldini, G. Risk-based automated assessment and testing for the cybersecurity certification and labelling of IoT devices. Comput. Stand. Interfaces 2019, 62, 64–83. [Google Scholar] [CrossRef]
  16. Matheu, S.N.; Hernández-Ramos, J.L.; Skarmeta, A.F.; Baldini, G. A survey of cybersecurity certification for the internet of things. ACM Comput. Surv. 2021, 53, 1–36. [Google Scholar] [CrossRef]
  17. Moosavi, S.R.; Gia, T.N.; Rahmani, A.M.; Nigussie, E.; Virtanen, S.; Isoaho, J.; Tenhunen, H. SEA: A secure and efficient authentication and authorization architecture for IoT-based healthcare using smart gateways. In Proceedings of the 6th International Conference on Ambient Systems, Networks and Technologies (ANT-2015), the 5th International Conference on Sustainable Energy Information Technology (SEIT-2015), London, UK, 2–5 June 2015; Volume 52, pp. 452–459, ISSN 18770509. [Google Scholar] [CrossRef]
  18. Turab, N.M. Internet of Things: A Survey of Existing architectural models and their security Protocols. Int. J. Comput. Sci. Netw. Secur. 2017, 17, 197–205. [Google Scholar]
  19. Abdul-Ghani, H.A.; Konstantas, D. A comprehensive study of security and privacy guidelines, threats, and countermeasures: An IoT perspective. J. Sens. Actuator Netw. 2019, 8, 22. [Google Scholar] [CrossRef]
  20. Sadhu, P.K.; Yanambaka, V.P.; Abdelgawad, A. Internet of things: Security and solutions survey. Sensors 2022, 22, 7433. [Google Scholar] [CrossRef]
  21. El-Attar, M.; Abdul-Ghani, H.A. Using security robustness analysis for early-stage validation of functional security requirements. Requir. Eng. 2016, 21, 1–27. [Google Scholar] [CrossRef]
  22. Taleby, M.; Li, Q.; Rabbani, M.; Raza, A. A survey on smartphones security: Software vulnerabilities, malware, and attacks. Int. J. Adv. Comput. Sci. Appl. 2017, 8. [Google Scholar] [CrossRef]
  23. Yoon, S.; Kim, J.; Jeon, Y. Security considerations based on classification of IoT device capabilities. In Proceedings of the SERVICE COMPUTATION 2017: The Ninth International Conferences on Advanced Service Computing, Athens, Greece, 19–23 February 2017; pp. 1–63, ISBN 978-1-61208-528-9. [Google Scholar]
  24. Shon, T. In-vehicle Networking/Autonomous vehicle security for internet of Things/Vehicles. Electronicsweek 2021, 10, 637. [Google Scholar] [CrossRef]
  25. Bettayeb, M.; Nasir, Q.; Talib, M.A. Firmware update attacks and security for IoT devices. In Proceedings of the ArabWIC 6th Annual International Conference Research Track, Rabat, Morocco, 7–9 March 2019; ACM: New York, NY, USA, 2019; pp. 1–6. [Google Scholar] [CrossRef]
  26. El Jaouhari, S.; Bouvet, E. Secure firmware over-the-air updates for IoT: Survey, challenges, and discussions. Internet Things 2022, 18, 100508. [Google Scholar] [CrossRef]
  27. Sen, J. Security in wireless sensor networks. In Wireless Sensor Networks: Current Status and Future Trends; CPC Press: Boca Raton, FL, USA, 2016; pp. 407–460. ISBN 9781466506084. [Google Scholar]
  28. Yang, G.; Dai, L.; Wei, Z. Challenges, threats, security issues and new trends of underwater wireless sensor networks. Sensors 2018, 18, 3907. [Google Scholar] [CrossRef]
  29. Ender, M.; Swierczynski, P.; Wallat, S.; Wilhelm, M.; Knopp, P.M.; Paar, C. Insights into the mind of a trojan designer: The challenge to integrate a trojan into the bitstream. In Proceedings of the 24th Asia and South Pacific Design Automation Conference, Tokyo, Japan, 21–24 January 2019; ACM: Tokyo, Japan, 2019; pp. 112–119. [Google Scholar] [CrossRef]
  30. Sathyadevan, S.; Achuthan, K.; Doss, R.; Pan, L. Protean Authentication Scheme—A Time-Bound Dynamic KeyGen Authentication Technique for IoT Edge Nodes in Outdoor Deployments. IEEE Access 2019, 7, 92419–92435. [Google Scholar] [CrossRef]
  31. Cherdantseva, Y.; Hilton, J. A reference model of information assurance & security. In Proceedings of the 2013 International Conference on Availability, Reliability and Security, ARES 2013, Regensburg, Germany, 2–6 September 2013; pp. 546–555. [Google Scholar] [CrossRef]
  32. Abdulghani, H.A.; Nijdam, N.A.; Collen, A.; Konstantas, D. A study on security and privacy guidelines, countermeasures, threats: IoT data at rest perspective. Symmetry 2019, 11, 774. [Google Scholar] [CrossRef]
  33. Mohsen Nia, A.; Sur-Kolay, S.; Raghunathan, A.; Jha, N.K. Physiological information leakage: A new frontier in health information security. IEEE Trans. Emerg. Top. Comput. 2015, 4, 321–334. [Google Scholar] [CrossRef]
  34. Montenegro, G.; Kushalnagar, N.; Hui, J.; Culler, D. Transmission of IPv6 Packets over IEEE 802.15.4 Networks, RFC 4944; RFC Editor: Fremont, CA, USA, 2007; pp. 1–30. [Google Scholar] [CrossRef]
  35. Watteyne, T.; Palattella, M.; Grieco, L. Using IEEE 802.15. 4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement; RFC 7554; RFC Editor: Fremont, CA, USA, 2015; pp. 1–23. [Google Scholar] [CrossRef]
  36. Roman, R.; Alcaraz, C.; Lopez, J.; Sklavos, N. Key management systems for sensor networks in the context of the Internet of Things. Comput. Electr. Eng. 2011, 37, 147–159. [Google Scholar] [CrossRef]
  37. ArchRock Corporation. Phynet n4x Series. 2008. Available online: https://urgentcomm.com/2008/11/01/sensor-nodes-handle-harsh-environments/ (accessed on 13 March 2023).
  38. Hong, S.; Kim, D.; Ha, M.; Bae, S.; Park, S.; Jung, W.; Kim, J.E. SNAIL: An IP-based wireless sensor network approach to the Internet of things. IEEE Wirel. Commun. 2010, 17, 34–42. [Google Scholar] [CrossRef]
  39. Raza, S.; Duquennoy, S.; Höglund, J.; Roedig, U.; Voigt, T. Secure communication for the Internet of Things-a comparison of link-layer security and IPsec for 6LoWPAN. Secur. Commun. Netw. 2014, 7, 2654–2668. [Google Scholar] [CrossRef]
  40. Law, Y.W.; Zhang, Y.; Jin, J.; Palaniswami, M.; Havinga, P. Secure rateless deluge: Pollution-resistant reprogramming and data dissemination for wireless sensor networks. Eurasip J. Wirel. Commun. Netw. 2011, 1–22. [Google Scholar] [CrossRef]
  41. Saiful Islam Mamun, M.; Sultanul Kabir, A.; Sakhawat Hossen, M.; Hayat Khan, M. Policy based intrusion detection and response system in hierarchical WSN architecture. arXiv 2012, arXiv:1209.1678. [Google Scholar] [CrossRef]
  42. Hu, K.; Nowroz, A.N.; Reda, S.; Koushanfar, F. High-sensitivity hardware trojan detection using multimodal characterization. In Proceedings of the Design, Automation and Test in Europe, DATE, Grenoble, France, 18–22 March 2013; pp. 1271–1276, ISSN 15301591. [Google Scholar] [CrossRef]
  43. Alliance, A.S.C. Embedded hardware security for IoT applications. In A Smart card Alliance Internet of Things Security Council White Paper; Technical Report December 2016; Smart Card Alliance, CA, USA; Available online: https://www.securetechalliance.org/wp-content/uploads/Embedded-HW-Security-for-IoT-WP-FINAL-December-2016.pdf (accessed on 13 March 2023).
  44. Heer, T.; Garcia-Morchon, O.; Hummen, R.; Keoh, S.L.; Kumar, S.S.; Wehrle, K. Security challenges in the IP-based Internet of Things. Wirel. Pers. Commun. 2011, 61, 527–542. [Google Scholar] [CrossRef]
  45. Moskowitz, H.; Komu, M. HIP Diet EXchange (DEX) draft-ietf-hip-dex-18. Hip 2020, 5, 1. [Google Scholar]
  46. Jung, S.W.; Jung, S. Secure bootstrapping and rebootstrapping for resource-constrained thing in internet of things. Int. J. Distrib. Sens. Netw. 2015, 11, 174383. [Google Scholar] [CrossRef]
  47. Conoscenti, M.; Vetro, A.; De Martin, J.C. Blockchain for the Internet of Things: A systematic literature review. In Proceedings of the IEEE/ACS International Conference on Computer Systems and Applications, AICCSA, Agadir, Morocco, 29 November–2 December 2016; pp. 1–6. [Google Scholar] [CrossRef]
  48. Mosenia, A.; Jha, N.K. A comprehensive study of security of internet-of-things. IEEE Trans. Emerg. Top. Comput. 2017, 5, 586–602. [Google Scholar] [CrossRef]
  49. Hristozov, S.; Heyszl, J.; Wagner, S.; Sigl, G. Practical runtime attestation for tiny IoT devices. In Proceedings of the Proceedings 2018 Workshop on DECENTRALIZED IoT Security and Standards, San Diego, CA, USA, 18 February 2018. [Google Scholar] [CrossRef]
  50. Rashid, F.; Miri, A.; Woungang, I. A secure data deduplication framework for cloud environments. In Proceedings of the 2012 10th Annual International Conference on Privacy, Security and Trust, PST 2012, Paris, France, 16–18 July 2012; pp. 81–87. [Google Scholar] [CrossRef]
  51. Yu, S.; Guo, S. Big data concepts, theories, and applications. In Big Data Concepts, Theories, and Applications; Springer International Publishing: Cham, Switzerland, 2016; pp. 1–437. [Google Scholar] [CrossRef]
  52. Machanavajjhala, A.; Kifer, D.; Gehrke, J.; Venkitasubramaniam, M. L-diversity: Privacy beyond k-anonymity. ACM Trans. Knowl. Discov. Data 2007, 1, 3. [Google Scholar] [CrossRef]
  53. Li, N.; Li, T.; Venkatasubramanian, S. t-closeness: Privacy beyond k-anonymity and l-diversity. In Proceedings of the 2007 IEEE 23rd International Conference on data Engineering, Istanbul, Turkey, 14–20 April 2006; pp. 106–115. [Google Scholar]
  54. Narendra, N.C.; Nayak, S.; Shukla, A. Managing large-scale transient data in IoT systems. In Proceedings of the 2018 10th International Conference on Communication Systems and Networks, COMSNETS 2018, Bengaluru, India, 3–7 January 2018; Volume 2018, pp. 565–568. [Google Scholar] [CrossRef]
  55. Jiang, H.; Shen, F.; Chen, S.; Li, K.C.; Jeong, Y.S. A secure and scalable storage system for aggregate data in IoT. Future Gener. Comput. Syst. 2015, 49, 133–141. [Google Scholar] [CrossRef]
  56. Storer, M.W.; Greenan, K.M.; Miller, E.L.; Voruganti, K. POTSHARDS: Secure long-term storage without encryption. In Proceedings of the 2007 USENIX Annual Technical Conference, Santa Clara, CA, USA, 17–22 June 2007; pp. 143–156, ISBN 9998888776. [Google Scholar]
  57. Anand, M. Cloud monitor: Monitoring applications in cloud. In Proceedings of the IEEE Cloud Computing for Emerging Markets, CCEM 2012, Bangalore, India, 11–12 October 2012; pp. 58–61. [Google Scholar] [CrossRef]
  58. Brinkmann, A.; Fiehe, C.; Litvina, A.; Lück, I.; Nagel, L.; Narayanan, K.; Ostermair, F.; Thronicke, W. Scalable monitoring system for clouds. In Proceedings of the 2013 IEEE/ACM 6th International Conference on Utility and Cloud Computing, UCC 2013, Dresden, Germany, 9–12 December 2013; pp. 351–356. [Google Scholar] [CrossRef]
  59. Kumar, A.; Narendra, N.C.; Bellur, U. Uploading and replicating internet of things (IoT) data on distributed cloud storage. In Proceedings of the 2016 IEEE 9th International Conference on Cloud Computing (CLOUD), San Francisco, CA, USA, 27 June–2 July 2016; pp. 670–677. [Google Scholar] [CrossRef]
  60. Jayant, D.B.; Swapnaja, A.U.; Sulabha, S.A.; Dattatray, G.M. Analysis of DAC MAC RBAC access control based models for security. Int. J. Comput. Appl. 2014, 104, 6–13. [Google Scholar] [CrossRef]
  61. Javed, F.; Afzal, M.K.; Sharif, M.; Kim, B.S. Internet of things (IoT) operating systems support, networking technologies, applications, and challenges: A comparative review. IEEE Commun. Surv. Tutor. 2018, 20, 2062–2100. [Google Scholar] [CrossRef]
  62. Granjal, J.; Monteiro, E.; Silva, J.S. Application-layer security for the WoT: Extending CoAP to support end-to-end message security for internet-integrated sensing applications. In Proceedings of the Lecture Notes in Computer Science (Including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), St. Petersburg, Russia, 5–7 June 2013; Volume 7889, pp. 140–153, ISSN 03029743. [Google Scholar] [CrossRef]
  63. Perera, C.; McCormick, C.; Bandara, A.K.; Price, B.A.; Nuseibeh, B. Privacy-by-design framework for assessing internet of things applications and platforms. In Proceedings of the ACM International Conference Proceeding Series, Stuttgart, Germany, 7–9 November 2016; pp. 83–92. [Google Scholar] [CrossRef]
  64. Broadband Internet Technical Advisory Group. Internet of things (IoT) security and privacy recommendations: A uniform agreement report. In Broadband Internet Technical Advisory Group Technical Working Group Report; Technical Report November 2016; Broadband Internet Technical Advisory Group: Denver, CO, USA; Available online: https://www.bitag.org/report-internet-of-things-security-privacy-recommendations.php (accessed on 13 March 2023).
  65. OWASP Internet of Things. Available online: https://owasp.org/www-project-internet-of-things/ (accessed on 13 March 2023).
  66. IoT Security Foundation (IoTSF). IoT Security Compliance Framework Release 2.1; Technical report; IoT Security Foundation: Livingston, UK, 2020. [Google Scholar]
  67. Gubbi, J.; Buyya, R.; Marusic, S.; Palaniswami, M. Internet of Things (IoT): A vision, architectural elements, and future directions. Future Gener. Comput. Syst. 2013, 29, 1645–1660. [Google Scholar] [CrossRef]
  68. Atzori, L.; Iera, A.; Morabito, G. The Internet of Things: A survey. Comput. Netw. 2010, 54, 2787–2805. [Google Scholar] [CrossRef]
  69. Green, J. The internet of things reference model. In Internet Things World Forum; CISCO: San Jose, CA, USA, 2014; pp. 1–12. ISBN 9781479959402. [Google Scholar]
  70. Pierce, L.; Tragoudas, S. Multi-level secure JTAG architecture. In Proceedings of the 2011 IEEE 17th International On-Line Testing Symposium, IOLTS 2011, Athens, Greece, 13–15 July 2011; pp. 208–209. [Google Scholar] [CrossRef]
  71. Moriyama, D.; Matsuo, I.; Yung, M. PUF-Based RFID authentication secure and private under memory leakage. Cryptol. ePrint Arch. 2013, 712. [Google Scholar]
  72. Doddapaneni, K.; Lakkundi, R.; Rao, S.; Kulkarni, S.G.; Bhat, B. Secure FoTA object for IoT. In Proceedings of the 2017 IEEE 42nd Conference on Local Computer Networks Workshops, LCN Workshops 2017, Singapore, 9 October 2017; pp. 154–159. [Google Scholar] [CrossRef]
  73. Mauw, S.; Piramuthu, S. A PUF-based authentication protocol to address ticket-switching of RFID-tagged items. In Lecture Notes in Computer Science; Springer: Berlin/Heidelberg, Germany, 2013; Volume 7783, pp. 209–224. ISSN 03029743. [Google Scholar] [CrossRef]
  74. Dofe, J.; Frey, J.; Yu, Q. Hardware security assurance in emerging IoT applications. In Proceedings of the IEEE International Symposium on Circuits and Systems, Montreal, QC, Canada, 22–25 May 2016; pp. 2050–2053, ISSN 02714310. [Google Scholar] [CrossRef]
  75. Tomić, I.; McCann, J.A. A survey of potential security issues in existing wireless sensor network protocols. IEEE Internet Things J. 2017, 4, 1910–1923. [Google Scholar] [CrossRef]
  76. Granjal, J.; Monteiro, E.; Silva, J.S. Network-layer security for the Internet of Things using TinyOS and BLIP. Int. J. Commun. Syst. 2014, 27, 1938–1963. [Google Scholar] [CrossRef]
  77. Granjal, J.; Monteiro, E.; Silva, J.S. Security in the integration of low-power Wireless Sensor Networks with the Internet: A survey. Ad Hoc Netw. 2015, 24, 264–287. [Google Scholar] [CrossRef]
  78. Otte, P.; de Vos, M.; Pouwelse, J. TrustChain: A sybil-resistant scalable blockchain. Future Gener. Comput. Syst. 2020, 107, 770–780. [Google Scholar] [CrossRef]
  79. Gonzalez, C.; Charfadine, S.M.; Flauzac, O.; Nolot, F. SDN-based security framework for the IoT in distributed grid. In Proceedings of the 2016 International Multidisciplinary Conference on Computer and Energy Science, SpliTech 2016. University of Split, FESB, Split, Croatia, 13–15 July 2016; pp. 1–5. [Google Scholar] [CrossRef]
  80. Yan, Z.; Wang, M.; Li, Y.; Vasilakos, A.V. Encrypted data management with deduplication in cloud computing. IEEE Cloud Comput. 2016, 3, 28–35. [Google Scholar] [CrossRef]
  81. Xu, Y.; Qin, X.; Yang, Z.; Yang, Y.; Huang, C. An algorithm of k-anonymity for data releasing based on fine-grained generalization. J. Inf. Comput. Sci. 2012, 9, 3071–3080. [Google Scholar]
  82. Bokefode, J.D.; Bhise, A.S.; Satarkar, P.A.; Modani, D.G. Developing A secure cloud storage system for storing IoT data by applying role based encryption. Procedia Comput. Sci. 2016, 89, 43–50. [Google Scholar] [CrossRef]
  83. Sun, W.; Yu, S.; Lou, W.; Hou, Y.T.; Li, H. Protecting your right: Verifiable attribute-based keyword search with fine-grained owner-enforced search authorization in the cloud. IEEE Trans. Parallel Distrib. Syst. 2016, 27, 1187–1198. [Google Scholar] [CrossRef]
  84. Yu, Z.; Au, M.H.; Xu, Q.; Yang, R.; Han, J. Towards leakage-resilient fine-grained access control in fog computing. Future Gener. Comput. Syst. 2018, 78, 763–777. [Google Scholar] [CrossRef]
  85. Yohan, A.; Lo, N.W. An over-the-blockchain firmware update framework for IoT devices. In Proceedings of the DSC 2018—2018 IEEE Conference on Dependable and Secure Computing, Kaohsiung, Taiwan, 10–13 December 2018; pp. 1–8. [Google Scholar] [CrossRef]
  86. Yohan, A.; Lo, N.W.; Achawapong, S. Blockchain-based firmware update framework for internet-of-things environment. In Proceedings of the Conf. Information and Knowledge Engineering, Athens, Las Vegas, NV, USA, 30 July–2 August 2018; pp. 151–155. [Google Scholar]
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Article Metrics

Citations

Article Access Statistics

Journal Statistics
Multiple requests from the same IP address are counted as one view.
Download PDF
Improving Pedestrian Safety Using Ultra-Wideband Sensors: A Study of Time-to-Collision Estimation
Previous
Optimized Classification of Intelligent Reflecting Surface (IRS)-Enabled GEO Satellite Signals
Next