IoT Architecture and Systemic Challenges

Sensing Layer: Introduction and Challenges in End Nodes

Amidst the vast variety of IoT devices that surround humans, the most common are sensors, actuators, RFID readers, RFID tags, etc. These devices form a set of devices which are collectively termed as the sensing layer of IoT architecture. The critical contribution of this layer in IoT can be broadly summed up as sensing of ambient parameters and transmission of sensed data for processing in the next layers [8]. A few parameters that need to be considered in the sensing layer:

• a) Cost, Resource and Energy consumption: The devices are equipped with minimal energy resources and memory in order to reduce cost.
• b) Communication: The devices act as receiving ends of information and are designed to communicate with other devices on the network.
• c) Networks: WSNs (Wireless Sensor Networks) and WMNs (Wireless Mesh Networks) connect a unique category of things in a complex; wireless and autonomous networks are employed for data acquisition, transmission and operation.

Figure 1.5 explains the fundamentals of service-oriented architecture in an IoT network and also its interaction with the other layers of IoT infrastructure.

Coupled with synchronized computing and communication capabilities, IoT is attributed to tapping into the potential offered by these individual sensors, turning them from classic to smart. In this regard, the security of the end nodes of the sensing layer of this network becomes of prime importance, particularly owing to

FIGURE 1.5 Service-Oriented Architecture IoT.

the uncertainty regarding data controlling. In this regard, the foremost prerequisite for the security mechanism in the Internet of Things is to have the rationale to take its own decisions which includes approving a command to accept, execute or terminate it. However, the confines of “Things” set up for minimal energy consumption and limited memory pose an extended range of security vulnerabilities at the sensing layer and end-node.

Upon classifying the various insecurities and threats that the sensing layer of IoT faces, it is essential to follow a few security preconditions; these include:

• a) Security Prerequisites in IoT end nodes: confidentiality, integrity, privacy, access control, authentication, physical security protection and nonrepudiation.
• b) Security Prerequisites in the IoT sensing layer: device authentication, authentication of information source, availability, integrity and confidentiality.

In order to achieve the above-mentioned requirements in the sensing layer of the IoT network, a few actions suggested include:

• a) Creation of a trustworthy data sensing system and reinstating privacy and confidentiality of all devices in a network.
• b) Identification of the source of users forensically as well as tracing them.
• c) Designing the software or firmware at IoT to secure end nodes.
• d) Administer security standards for all IoT devices.

Threat Based on Network Layer

For the optimum utilization of data procured in the sensing layer, it is equally important to transmit data among the IoT infrastructure. The network layer, therefore, provides the necessary medium to exchange information.

For smooth functioning and coordination among IoT devices, proper arrangement, organization and management of networks is important for which certain prerequisites include:

• a) Effective network management such as wireless networks, fixed networks or mobile networks.
• b) Energy efficiency within network layer.
• c) QoS requirements.
• d) Maintenance of privacy, confidentiality and security.
• e) Mechanism for mining and searching.

Among the above-mentioned requirements, maintenance of privacy, confidentiality and security lies within the purview of the chapter and its importance is critical based on the complexity and mobility. Although existing security protocols and frameworks have provided security against threats and vulnerabilities until now, there exist a multitude of concerns that need to be addressed:

• 1) Broad security provisions: Provisions to ensure confidentiality, integrity and privacy for group authentication, protection of keys and availability of data.
• 2) Protection against privacy leakage: The location and complexity of certain devices in an IoT network often troubles the developers fearing the susceptibility of attacks upon sensitive data like user identity and credentials.
• 3) Secure communication: For an IoT system to exist, it must be fortified against attacks and reinforced with robustness, trustworthiness and confidentiality.
• 4) Fake network message: Creating fake signals corner and propagating miscom- munication among devices from the entire network.
• 5) Overconnection: A highly connected network is also at risk due to two main reasons:
  • a) High network congestion caused by signaling authentication on a bandwidth which may lead to a DoS attack.
  • b) Intensive resource consumption caused by key operations and key security.
• 6) MITM attack: The attacks carried out independently by attackers over networks to forge a private connection while the attacker is controlling the entire conversation.

Although the innovations and technology available have been able to keep major threats at bay until recently, the growing influence of attackers has sent shockwaves across the globe. A series of steps in the following directions could help to provide greater security in the future:

• a) Stringent authentication/ authorization process.
• b) Secure transport encryption.

Service-Layer Based Threats

Upon sensing and transmission, the data procured requires operation while utilizing and integrating services of hardware and software platforms. The service layer hence aptly touted to be the middleware technology is designed according to the application requirements, application programming interface and service protocols to the standards of service providers, vendors and organizations. This layer is responsible for integration, analysis, security, management of UI and event-processing services [9] To render these services, the following steps are taken:

• a) Service detection: Locating the optimum infrastructure necessary to conduct services efficiently;
• b) Service combination and integration: To further broaden the scope of interaction among services and draw out more reliable ones is achieved by interaction by scheduling or recreating;
• c) Authentication Management: Focus is laid upon verification of trusted devices through other services;
• d) Service APIs: These help to improve interconnections between services.

To tackle the numerous challenges and threats, developers and corporations have contributed relentlessly to offer solutions to augment and improve services within the connected network. The ambitious SOCRADES integration architecture aims to ameliorate the interactions between application and service layers efficiently [11]. The “things” in the interconnection of devices are often limited to delivering services while exploiting these devices for discovery of networks, exchange of metadata and asynchronous publish and subscribe events [12]. In Peris-Lopez et al. (2006) [13], to increase the interoperability of loosely coupled devices and distributed applications, representational state transfer is set up. In Hernandez-Castro et al. (2013) [14], a service-provisioning process is introduced in the service layer that could strengthen ties and buttress cooperation between applications and services.

In light of the above-mentioned challenges and solutions offered to counter them, it is imperative to understand that certain security precautions, requirements and protocols, if undertaken, could shield against attacks in the service layer. A few of them are:

• a) Dedicated authorization methods for service verification, authentication of groups, protection of privacy and integrity for the upkeep and storage of keys;
• b) Protection against privacy leakage and location tracking;
• c) Tracking services involving unauthorized use and unsubscribed services;
• d) Prevention of potential threats like DoS attacks, node identification masquerade, replay attacks, service information manipulation and communication and services repudiation.

The solutions offered in this section broadly cover the solutions from major potential security threats.

In spite of the solutions offered, there remain a few open challenges that need to be addressed when creating an IoT application or services:

• a) Securing data transference between layers;
• b) Securing service management.

Application Interface Layer

This interface is the most visible and interactive layer of the IoT network and encompasses a myriad of utility-based implementations ranging from radio frequency identification based tracking to intelligent home management that are enabled via standardized protocols and other technologies [15]. Application maintenance requires certain security preconditions such as:

• a) Safety-based isolation.
• b) Secure methodologies for acquisition of software and updates.
• c) Patches for augmenting security.
• d) Verification means for the administrators.
• e) Integrated platform for enhancement of security.

Different layers of IoT architecture require the following in order to sustain security in communication between the layers:

• a) Maintaining the three tenets of security (privacy, confidentiality and integrity) for inter-layer communication.
• b) Verification and approval of administrators cross layer.
• c) Isolation of critical data.

The following regulations could prove to be helpful in designing security solutions:

• a) The safety of these nodes should be attended carefully as most of the nodes in question are unsupervised.
• b) Energy efficiency of nodes is of utmost importance while designing security solutions considering their large numbers.

Cross-Layer Challenges

Across all layers of IoT architecture through which the data is shared, certain standards are to be maintained to ensure that the network remains secure and fully interoperable. With the growing number of things in the network, it is the prerogative of the users to ascertain that their data is guaranteed protection against challenges among layers of the architecture.

The security needs across layers are virtually the amalgamation of the challenges faced across the IoT network:

a) Security protection in terms of design and execution time;

• b) Ensuring high privacy standards to protect personal data through enhancement technologies;
• c) Reinstating trust in IoT architecture

Challenge to Implementation of Blockchain in IoT

Absence of IoT-Centric Consensus Protocol

A consensus protocol is a technique or a set of rules and regulations that make all the full nodes finalize on an arrangement over the sequence of transactions. There are various categories of consensus protocols being currently utilized in a variety of blockchain applications, for example, PoS, Proof of Work (PoW), Practical Byzantine Fault Tolerance (PBFT), etc. A few of the commonly used consensus protocols are deliberated upon in the following paragraphs of this chapter. Makdhoom [ 16] shows the contrariety of a few of the widely known and used blockchain consensus protocols in a thorough and exhaustive manner. The established consensus protocols such as Proof of Stake (PoS), Proof of Work (PoW), IOTA. Proof of Elapsed Time (PoET) are fabricated for permissionless blockchains, with an emphasis on financial transactions, whereas PoS and PoET have the potential to be used in permissioned blockchains.

The universal problem with these consensus protocols is the probabilistic nature of the consensus process and that it fails to terminate in a perdurable committed block. This further explains their vulnerability to blockchain forks [17]. One of the major contributors to deferred transaction verification is an absolute absence of consensus finality that is not at all sustainable for the various real / near-real-time IoT systems that demand instantaneous transaction verification and completion. Furthermore, examining the various consensus protocols, we find that a certain type of hardware is required by PoET in which the region allocating wait time necessitates being a trusted entity.

A number of ambiguities are yet to be resolved when it comes to IOTA since it is still in the open beta testing phase particularly regarding its performance efficacy and security. A number of questions pertaining to whether IOTA would be an effective micro-payment method or its compatibility with contracts as in HFB (Hyperledger- Fabric blockchains) and Ethereum and its capability of providing data confidentiality are still unanswered.

Meanwhile, a number of other consensus protocols like the Delegated Byzantine Fault Tolerance (DBFT), Practical Byzantine Fault Tolerance (PBFT), HoneyBadger et al. are based on the Byzantine Fault Tolerance (BFT) protocol which is a group of state machine reduplication protocols. By replicating the services on a multitude of nodes it provides security against arbitrary faults. Despite BFT being the preferred protocol for permissioned-type blockchains, it has several shortcomings. BFT- based protocols have a high vulnerability toward DoS attacks owing to their languid timing assumptions with the exception of HoneyBadger BFT [18]. Not only does the feeble synchrony negatively alters the system’s productivity, but the liveness characteristic of languid synchronous protocols is also unsuccessful as the feeble timing assumptions get contravened when vitriolic networks launch DoS attacks.

Scalability pertaining to the number of validator nodes is another challenge that comes with BFT-based protocols as the testing mechanism is not usually implemented post 20 nodes [19]. This shortcoming can be overcome by executing Algorand [20] that implements a system of random selection of a small-sized committee for every step of the consensus protocol to address scalability. This random selection is done through the mechanism of Verifiable Random Functions (VRF). Committee size is contingent on two constraints in Algorand:

i. 1 / 2g + b < Tstep.rstep

ii. g> Tstep.rstep

Where

g = number of honest committee members; b = number of malicious committee members;

T = number of votes required for consensus; т = expected committee size.

Furthermore, BFT-based consensus protocols are proficient in obscuring non- deterministic faults that eventuate at f=(n-1) / 3 replicas, where

/ = number of faulty nodes n = number of total nodes

Proof of Work (PoW) and BFT-based consensus protocols differ largely on the basis of availability which is an important necessity in IoT systems. On one hand where PoW does not determine whether a certain unresolved transaction will be present in the next bloc or not, PBFT on the other turns out to be particularly exorbitant when it comes to message complexity. Hence the sustainability of a huge number of IoT systems should be the focus of any future solution that is based on blockchain and should also be in accordance with the wireless communication rules of the particular country.

Transaction validation rules, fault tolerance and transmission complexity are some of the aspects that need to be enhanced if consensus-based protocols are to be applied in IoT-based systems.

Transaction Validation Rules

Figure l .6 represents the transaction verification and completion procedure in bitcoin. The working protocol for this functions on a specific set of regulations encompassing the authentication of transaction format and correct signatures and then followed by a mechanism that checks whether the specified transaction has been previously spent or not [21]. In comparison, Ethereum has a different process for transaction validation. As Figure 1.7 depicts, Ethereum verifies signatures, gas, nonce, account balance of sender’s account and the format.

FIGURE 1.6 Transaction validation rules in Bitcoin.

Due to the vulnerability of IoT systems toward cyber attacks, it raises an important conundrum as to whether or not the present regulations for transaction verification of blockchain are compatible with the IoT system. This problem is further augmented due to the fact that IoT systems, for the most part, consist of heterogeneous devices and applications that send data in a distinct range of values. These devices being highly vulnerable can be infected even through generic malware attacks that would consequently also be used by a botnet for even more attacks. Hence, the transaction verification regulations of blockchain may not be appropriate for IoT systems.

Scalability Challenges

When it comes to discussing the challenges with respect to the scalability of integrating blockchain in IoT systems, two major issues arise—storage capacity and the inherent latency of blockchain. The scalability affects both the size and the consensus procedure. For instance, if the number of users increases it will directly result in the rise of transactions as well. Consequently, the consensus protocol affects the delay in transaction validation. These challenges are discussed at length in the following paragraphs of this chapter.

Storage Capacity

Typically, blockchain does not have the capacity to contain a huge amount of information, whereas a smart city IoT system containing hundreds and hundreds of end nodes has the ability to produce a large amount of data in a very small duration

FIGURE 1.7 Transaction Validation Rules Ethereum.

of time which needs to be processed to extricate data for a multitude of uses. The integrability of IoT devices is further limited due to the necessity of storing the entire blockchain through the full and miner nodes. Furthermore, the impediments on resource-limited devices to perform as validator nodes is augmented with the perpetual expansion in blockchain’s size which subsequently increases the storage necessities. The synchronization time rises as well, as each new user/device is added to the network. Hence it becomes extremely challenging to produce such a mechanism that encompasses both the constraint resources of IoT and the advantages of blockchain.

Inherent Latency Blockchain

The requirement for an enhancement in the transaction verification duration of realtime IoT systems like Industrial Control System (ICS), smart vehicles, Wireless Sensor Network (WSN), intelligent transportation systems, et al. without making concessions on its safety and efficiency has risen in demand.

For instance in the Proof of Work (PoW) based blockchain, the transaction verification duration is reduced if the block production duration lessens. However, a transaction needs to wait for more verifications to realize the identical strength of security because of the reduced complications in mining the block. Furthermore, a rise in the dissipation of computational resources is incurred due to the increase in the stability

FIGURE 1.8 Disadvantages of Bigger Block.

of blocks. It is believed that the throughput of a bitcoin blockchain can be augmented if the block size compounds from 1 MB to 2 MB. However, it is the larger block that utilizes a larger duration of time to transmit in the network.

Figure 1.8 illustrates the disadvantages of implementing bigger blocks. Furthermore, the number of full nodes is influenced by the expansion in the block size as an increased amount of resources are hence necessitated to store the entire blockchain which consequently factors into a swift development of the blockchain size. To conclude, it can be said that there is a clear trade-off between the degree of reliability and execution efficacy. A distributed network will have performance issues and a centralized network will harbor trust issues.

IoT Device Integration Challenges

Even though only Ethereum and Hyperledger-Fabric are a few of the only blockchain techs that incorporate smart contracts and distributed applications, they have a major shortcoming vis-a-vis execution of smart contracts in an Ethereum Virtual Machine (eVM) does not transmit in a direct fashion with the rest of the world. Hence, we make use of the web3.js library as an interfacing mechanism. Consequently, a safe decentralized database is one of the useful utilizations of blockchain.

As the present situation is with regard to the threats in IoT devices as they can be undermined without much difficulty, the integrity of IoT systems will always remain a matter of concern. Furthermore, the data can be further compromised due to an infectious code implemented remotely or simply due to a software/hardware malfunction or even human interference. These errors are not determined by the system unless they are specifically tested for such kinds of failures, modifications or misconfigurations. At present, the sole accessible solution is Orcalize [22] which takes information from third-party sources like IPFS and WolframAlpha. The provision of a Proof-Of- Authentication is mandated to establish the authenticity of the data provided.

Unfortunately, Orcalize is not compatible with IoT devices and hence their integration becomes even more difficult. Therefore, the requirement of an additional clientinterfacing software between blockchain and the IoT device will introduce more computational and memory expenditure. Hence, a lot of attention needs to be paid to ensure that an IoT device can have a vast variety of interchanges with blockchain.

Protection of Devices against Malware and Content Execution Attacks

The protection of devices against malware and content execution attacks has a dual aspect to it—ransomware and malware. Ransomware, however, has minimal effect on a distributed ledger as the network contains the error-free copy of the ledger even though some of the nodes may get affected. On the other hand, malware has the capacity to infiltrate the network with counterfeit/unauthentic data through a compromised node. Since the sensors have situation-based data which is challenging to authenticate with older transactions as opposed to in bitcoin, it becomes extremely difficult for the nodes to verify any transaction/data. Henceforth, for the detection of malicious and counterfeit nodes, the existence of malware detection software is a necessity in such blockchain-based IoT systems.

Secure and Synchronized Software Updates

IoT devices and their applications continue to be in operation for an extended period of time due to their analytical functionalities with the absence of any software or firmware upgrades and hence are very prone to cyber attacks. Even though because of the localized and distributed framework of blockchain, at present, synchronized firmware and software updates cannot be assured, the need for such a mechanism is increasing day by day.