A Novel Architectural Framework on IoT Ecosystem, Security Aspects and Mechanisms: A Comprehensive Survey

For the past few years, the Internet of Things (IoT) technology continues to not only gain popularity and importance, but also witnesses the true realization of everything being smart. With the advent of the concept of smart everything, IoT has emerged as an area of great potential and incredible growth. An IoT ecosystem centers around innovation perspective which is considered as its fundamental core. Accordingly, IoT enabling technologies such as hardware and software platforms as well as standards become the core of the IoT ecosystem. However, any large-scale technological integration such as the IoT development poses the challenge to ensure secure data transmission. Perhaps, the ubiquitous and the resource-constrained nature of IoT devices and the sensitive and private data being generated by IoT systems make them highly vulnerable to physical and cyber threats. In this paper, we re-define an IoT ecosystem from the core technologies view point. We propose a modified three layer IoT architecture by dividing the perception layer into elementary blocks based on their attributed functions. Enabling technologies, attacks and security countermeasures are classified under each layer of the proposed architecture. Additionally, to give the readers a broader perspective of the research area, we discuss the role of various state-of-the-art emerging technologies in the IoT security. We present the security aspects of the most prominent standards and other recently developed technologies for IoT which might have the potential to form the yet undefined IoT architecture. Among the technologies presented in this article, we give a special interest to one recent technology in IoT domain. This technology is named IQRF that stands for Intelligent Connectivity using Radio Frequency. It is an emerging technology for wireless packet-oriented communication that operates in sub-GHz ISM band (868 MHz) and which is intended for general use where wireless connectivity is needed, either in a mesh network or point-to-point (P2P) configuration. We also highlighted the security aspects implemented in this technology and we compare it with the other already known technologies. Moreover, a detailed discussion on the possible attacks is presented. These attacks are projected on the IoT technologies presented in this article including IQRF. In addition, lightweight security solutions, implemented in these technologies, to counter these threats in the proposed IoT ecosystem architecture are also presented. Lastly, we summarize the survey by listing out some common challenges and the future research directions in this field.


27
Portable and smart embedded devices have become an indis-28 pensable part of our day-to-day life. They are widely used in 29 standards, we present the security mechanisms implemented 84 in IQRF technology to secure its data. 85 Major contributions of this article can be resumed in two 86 points: 87 (1) We re-define the three layered architecture comprising 88 Perception Layer (L p ), Network Layer (L n ) and Appli- 89 cation Layer (L a ) as IoT mainly operates on these lay-90 ers. In the new architecture we divide L p into three 91 blocks namely Perception Sensor Block (PB s ), Percep- 92 tion Application Block (PB a ) and Perception Network 93 Block (PB n ). We also add an Edge Block (B e ) which is an 94 intermediate block that acts as a bridge between the IoT 95 device network and the Internet as illustrated in Figure 1. 96 Few justifications behind the division of the L p into three 97 separate blocks are:

98
(a) Adding PB s will help in controlling the nodes 99 and in data acquisition. At this block IoT devices 100 measure the physical quantities of the place where 101 they are located and convert them into digital 102 signals to be transmitted and analyzed at upper 103 layers.

104
(b) Adding PB a will help differentiate high-level 105 applications such as smart cities, smart trans-106 portation, smart grid etc. defined at the Applica-107 tion Layer of an IoT ecosystem than low-level 108 application protocols such as Constrained Applica- 109    even seven layer architecture [18]. The most basic among 193 these architectures is the three layer architecture [15]. This 194 architecture defines the main idea of IoT and was introduced 195 at its early stages of research. It consists of L p , L n and L a . 196 In this paper, we adopt the three layer architecture. We pro-197 pose to divide the L p into three blocks namely PB s , PB n and 198 PB a . We add B e that connects the PB n to the Network Layer of 199 the layered IoT architecture as illustrated in Figure 1. Layers 200 and blocks are explained further in this section. To show 201 the relationship (mapping) between layers or blocks and the 202 real world implementations and technologies, a component-203 wise IoT architecture is added besides the layer-wise IoT 204 architecture as shown in Figure 1b. 205 The layer-wise IoT architecture can be seen as a gener-206 alized framework for device networking. It is based on the 207 concept of splitting up a communication system into several 208 abstract layers, each one stacked upon the previous one. Each 209 layer of the architecture handles a specific task and communi-210 cates with its neighbouring layers. Therefore, the data flows 211 vertically along the layers, from L p up to the Application 212 Layer and down in the opposite direction and horizontally 213 from the PB s , to the PB a , and in opposite direction. Similar to 214 the layer-wise architecture, the components-wise architecture 215 shown in Figure 1b consists of three logical levels: IoT 216 devices, edge devices and infrastructure/cloud. IoT devices 217 (things) are nodes with direct connection to the physical 218 world providing information or actuating on the environ-219 ment in which they are placed. IoT devices may be sensors 220 or actuators typically resource-constrained, mobile or static 221 and connected to each other through a wired or a wireless 222 links. Edge devices are typically part of the wired network 223 infrastructure, most of the time static and located close to IoT 224 devices that need a bridging to Internet. Unlike IoT devices, 225 edge devices may have significant computational resources 226 such as CPU, memory and communication interface. There-227 fore, computation tasks can be done at this level in case short 228 delays are required or the communication with the cloud 229 might causes a bottleneck problem. Moreover, gateways or 230 border routers are a typical examples of edge devices. The 231 cloud is a complete set of tools to connect, process, store, 232 and analyze data coming from IoT devices through the edge 233 devices. It is rich in computation power, however there may 234 be significant delays to IoT devices due to the bottleneck 235 problem. Moreover, using the cloud is important for aggre-236 gating data and drawing insights from that data to build up 237 applications such as smart cities, smart homes, connected 238 cars, smart agriculture, energy management, smart shopping, 239 etc. On the other side, the component-wise architecture illus-240 trated in Figure 1b shows two types of IoT networks, IPv4-241 based networks and IPv6-based networks. As IPv4 protocol 242 is not originally designed for the IoT and is inherently limited 243 to about 4 Billion addresses, most of the devices in IPv4-244 based IoT applications are not directly addressed with an IP 245 address. They are rather set in groups of devices (networks) 246 connected to each other in a mesh, star or tree topology using 247 certain communication protocols (Protocol X) and connected 248 to the Internet through an IPv4 gateway. In the near future, 249 vast number of things connected to the Internet will need an 250 IPv6 address since the IPv4 address space will be effectively 251 consumed [41]. Accordingly, IPv6 addressing is now desir-252 able as it provides 2 128   are popular types of perception IoT nodes or sensors [5]. 298 Moreover, sensors might be deployed at unattended remote 299 locations. Therefore, they are exposed to physical attacks 300 such as physical tampering, node capture, and eavesdropping.

301
The acquired data at the PB s is transferred to the PB a . Perception Application Block PB a comprises of application 304 protocols that handle the communication either between gate-305 ways and the Network Layer in case of IPv4 IoT applications, 306 or between resource-constrained devices (end nodes) and 307 the Network Layer in case of IPv6 IoT applications. There 308 are several application protocols at this block including, 309 but not limited to CoAP, MQTT, XMPP and AMQP [47]. 310 For instance, non-IP networks are connected to the Net-311 work Layer behind an IPv4 gateway and the application 312 protocol may be installed on the gateway itself. While in 313 networks where devices support IPv6 protocol e.g. 6LoW-314 PAN networks, devices are addressed directly with an IPv6 315 address and the application protocol may be installed on the 316 device itself. Data after being treated at this block is sent to 317 the PB n . Perception Network Block PB n comprises of the networking 320 part of WSNs. At this block the communication is usually 321 done in wireless mode, for instance as in IEEE 802.15.4 net-322 works. Moreover, the PB n forwards data from IoT devices 323 to the Edge Block to be sent later to the Network Layer [5]. 324 In the PB n , routing is the key responsibility. Therefore, 325 proactive routing protocols such as Wireless Routing Proto-326 col (WRP), Topology Dissemination Based on Reverse-Path 327 Forwarding Protocol (TBRPF) and reactive routing protocols 328 such as Temporarily Ordered Routing Algorithm (TORA), 329 Energy-aware Temporarily Ordered Routing Algorithm (E-330 TORA), Routing Protocol for Low-Power and Lossy Net-331 works (RPL) are used to find and maintain optimal rout-332 ing paths in IoT WSNs [48]. RPL is a promising routing 333 protocol in IEEE 802.11.4 networks that uses 6LoWPAN 334 protocol. The Network Layer is the core layer of IoT ecosystem archi-349 tecture. This layer is also called transport layer as information 350 routing is the main function of this layer. Hence, this layer 351 aims to transmit the data collected from the (L p ) to any spe-352 cific information processing system through Internet using 353 technologies such as Wi-Fi, LTE, 3G/4G/5G etc. ensuring 354 while active tags can be read from farther distances depending 407 on the application. When RFID reader is equipped with an 408 appropriate communication protocol allowing its connectiv-409 ity to the Internet, the distributed RFID readers can iden-410 tify, track and monitor tagged objects globally. This is the 411 so- protection from skimming, availability, authenticity, integrity, 429 anonymity, forward secrecy and technology scalability. How-430 ever, building an RFID security mechanism is a big concern 431 due to fact that the RFID devices are limited in terms of 432 computational capabilities, unreliable communication and 433 less power [57]. Additionally, many types of attacks on 434 RFID systems, either physical-based or software-based can 435 be mentioned including but not limited to, eavesdropping, 436 relay attacks, traffic analysis, spoofing, denial of service 437 (DoS), tag removal, back-end attacks, jamming, blocking, 438 tag destruction, malware tag content changes, replay attack 439 and tag cloning [60]. RFID security policy to mitigate secu-440 rity and privacy risk relies either on (a) Physical methods 441 such as electrostatic shielding (Faraday Cage), blocker tag 442 where it constantly sends fake tag serial numbers to con-443 ceal the order number of other tags, reader frequency mod-444 ification, tag frequency modification and kill order mech-445 anism, (b) The code mechanism which is designing and 446 achieving a code protocol that fits with RFID security 447 requirements such as hash-lock schemes, or (c) Both of 448 them [61]. CoAP is an IoT application layer protocol created by the 452 Constrained RESTful Environments (CoRE) working group 453 in the Internet Engineering Task Force (IETF) standardization 454 body. This group aims to design a Representational State 455 Transfer (REST) architecture to be supportable by the con-456 strained devices with limited computation, storage and com-457 munication capabilities. CoAP is a UDP-based specialized 458 web transfer protocol for use with constrained nodes and 459 constrained networks e.g., low-power and lossy networks. 460 VOLUME 10, 2022  The mandatory security mechanism to implement for CoAP 481 is the DTLS. Other applications may use another security 482 mechanism such as IP security (IPsec). Therefore, in CoAP, are shared in advance between the communicating parties 501 to establish DTLS link. Depending on the deployed cipher 502 suite, the use of PSKs is better than the use of a public key 503 which makes DTLS useful in constrained devices networks. 504 Additionally, in this mode there is a list of PSKs and each 505 key may include one or more nodes that can be used to 506 communicate with. Thus, a system selects an appropriate key 507 and then establishes a DTLS session. Nodes in this mode must 508 support at least the TLS_PSK_WITH_AES_128_CCM_8 509 cipher suite [67]. This suite provides authentication using 510 PSK (Symmetric) and 8 byte authentication tag. Third 511 mode is the Raw Public Key (RPK) where it is assumed 512 that nodes have an asymmetric key pair installed with 513 no certificate. The asymmetric key pair or RPK can be 514 generated and installed during the manufacturing process. 515 However, nodes willing to use the RPK need to support the 516 cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM 517 _8 [67]. Fourth mode is called Certificate where each node 518 has an asymmetric key pair with a X.509 certificate that binds 519 it to its authority name and is signed by a third party (trusted 520 root). Nodes in this mode must support the same cipher suite 521 as RPK mode. Moreover, in this mode, a node has also a 522 list of trusted roots for certificate validation. However, this 523 security mode requires the availability and usage of a security 524 infrastructure. MQTT is an application layer transport protocol suitable for 534 M2M and IoT communication. This open Client Server pub-535 lish/subscribe protocol standardized by OASIS is designed 536 to be simple and lightweight messaging protocol suited to 537 be used by the constrained devices in low-bandwidth and 538 unreliable networks. Moreover, MQTT protocol has been 539 widely implemented across a variety of industries since it 540 is has been designed. The architecture of MQTT consists 541 of a publisher, a subscriber and a broker [69]. Publishers, 542 for instance sensors, put the data on the broker which plays 543 the role of an intermediary from which subscribers such as 544 applications interested in topics take the data that has been 545 published by the sensors. In its conception, MQTT contains 546 some of the key characteristics: (i) Some of them can be 547 related to the publish/subscribe pattern which provides the 548 ability of sending a message by one publisher to many sub-549 scribers (one-to-many), (ii) MQTT supports different Quality 550 of Service (QoS) levels viz. the first level (QoS 0) related 551 to message's best efforts delivery. Even though some of the 552 messages can be lost, at most one of them has to reach the 553 destination, the second level (QoS 1) at least one message 554 has to arrive at the destination but duplication can happen, 555 and the third level (QoS 2) where messages have to reach the 556 destination but exactly once, therefore there is no duplication 557 (iii) Messaging transport is independent than the continent of 558 the payload, (iv) MQTT has less transport overhead and pro-  • Message confidentiality, this is done through a 609 symmetric-key encryption mechanism to keep the mes-610 sage abstract for the interceptor. In order to have dif-611 ferent cipher-texts for the same message, a unique 612 nonce is used at each packet encryption. Moreover, 613 when the Time Slotted Channel Hopping (TSCH) mode 614 is disabled, the nonce is generated uniquely for each 615 re-transmission ensuring that old communications can-616 not be reused in replay attacks. However, the replay 617 protection is not provided in IEEE 802.15.4 when TSCH 618 mode is enabled.

619
• Replay protection means that if an adversary eavesdrops 620 on a legitimate message, record it, and resend it to the 621 receiver attempting a relay attack, this can be detected 622 by the receiver using the MIC incremented by the sender 623 for each packet.

624
In IEEE 802.15.4, the security requirements must be 625 explicitly specified by the application in which this stan-626 dard is implemented by choosing one of the security suits 627 summarized in Table.   master key is the basis for long-term security between the 696 two devices, and may be used to generate link key, (ii) 697 Link key is a key that is shared exclusively between only 698 two peer entities present at ZAPL layer within a ZigBee This main components of this technology are a transceiver 712 module (TR), an operating system (OS) and a gateway. 713 The IQRF TR module is an intelligent electronic board 714 containing a communication device, a micro-controller and 715 other optional components. Moreover, IQRF TR modules are 716 end devices (nodes) in every IQRF wireless network. IQRF 717 OS provides access to the TR module resources such as pro-718 cessor, memory, peripherals and communication interfaces. 719 This operating system is installed on the micro-controller of 720 each IQRF TR module. Additionally, IQRF OS contains a 721 large number of functions for communication and network 722 services such as bounding, routing and devices discovery. 723 Therefore, IQRF OS represents the network layer of the 724 IQRF wireless networks supporting peer-to-peer and mesh 725 networking. IQRF gateway called Gateway Daemon (GWD) 726 is an interface to LAN and Internet connectivity (cloud). 727 The IQRF GWD is a project that provides open-source 728 components for building IQRF Gateways [9], [77]. Fur-729 thermore, IQRF uses in its TRs modules for communica-730 tion the low-power, low-data rate RF transceiver named ST 731 SPIRIT1 [78]. In addition to its communication capabilities, 732 SPIRIT1 includes an AES 128-bit encryption co-processor 733 providing the basic ground for IQRF to implement its security 734 mechanisms.

735
In IQRF networks, encryption is the way to prevent 736 unauthorized access and protect sensitive data. Hence, all 737 encryption schemes in IQRF networks utilizes AES 128-Bit 738 standard. IQRF technology uses three different encryption 739 mechanisms. First, access encryption which is used to secure 740 all sensitive wireless operations such as bounding and main-741 tenance. Bounding is one of the most critical operations from 742 the security point of view. I this operation, all sensitive data 743 such as network keys (used in network encryption), node ID 744 and node address are exchanged. Therefore this phase has to 745 be well protected. To do so, an access key is generated from 746 a 16 bytes user specified password. The generated access 747 key along with AES 128-Bit in Electronic Codebook (ECB) 748 mode is used for data access encryption. Second, network 749 encryption which is deployed during normal network opera-750 tions. Therefore, all packets circulating in IQRF network are 751 encrypted. In this encryption mechanism, the AES 128-Bit 752 standard with 16 bytes network encryption key and additional 753 Cipher Block Chaining (CBC) proprietary algorithm is used. 754 Unlike access encryption key, the network encryption key is 755 derived from a 192 bits long, unique, and randomly gener-756 ated password by the manufacturer and stored in all IQRF 757 TRs. However, in a given IQRF network, only the password 758 stored in the coordinator is used to generate the network 759 encryption key. Third, user encryption mechanism which is 760 taking in account routing constraints such as Expected Num-815 ber of Transmissions (ETX), the current amount of battery 816 and other functions during the topology construction. There-817 fore, a logical topology is built over a physical infrastructure 818 and this specifies an RPL instance defining an OF for a set 819 of one or more DODAGs. Each node in the network has 820 an assigned rank number (Rank). This number defines the 821 distance in terms of hops of that node from the root node. 822 Rank may also be seen as a function of the routing metric or it 823 may be calculated with respect to other constraints. Moreover, 824 a Rank of a node strictly increases or strictly decreases 825 depending on the node's position relative to DODAG root. 826 In addition, the rank helps the protocol to avoid routing loops 827 by computing node's position relative to other nodes and to 828 the DODAG root.

829
RPL protocol supports four control messages: (i) DODAG 830 Information Solicitation (DIS) sent by a node requesting 831 information about any nearby DODAGs for purpose to join 832 an existing DODAG, (ii) DODAG Information Object (DIO), 833 a message that shares information from an existing DODAG 834 such as the Rank of a node, the current RPL Instance, the IPv6 835 address of the root, etc. DIO is a response to DIS request, 836 (iii) Destination Advertisement Object (DAO) message that 837 can be used by a node to report its parents to the DODAG 838 root. The DODAG root can assemble together downward 839 along the DODAG to a particular node using DAO parent 840 sets from each node in the route, (iv) DAO acknowledgment 841 (DAO-ACK), a unicast packet sent by a node parent or a 842 DODAG root that received a DAO message as a confirmation 843 to reception, and (v) Consistency Check (CC) message which 844 is used for nodes to resynchronize using CC messages and 845 ensure that message's counter value is not repeated. CC can 846 be sent by a node to protect against replay attacks. RPL uses in 847 it's control messages the Internet Control Message Protocol 848 (ICMPv6) header [82] followed by a message body where 849 the security field can be enabled. Unlike routing protocols 850 that broadcast control messages at fixed time interval causing 851 energy wastage and may present energy hole threat for the 852 network, RPL adapts the DIO messages sending intervals to 853 the frequency of changes of the network topology. Therefore, 854 in non-mobile and stable networks, RPL control messages are 855 rarely sent [83], [84].

856
RPL protocol defines a secured version of its control 857 messages. Hence, setting the most significant bit (MSB) in 858 the RPL message field named Code will identify whether 859 or not the security is enabled for the RPL message (DIS, 860 DIO, DAO or DAOACK). If the security is chosen to be 861 enabled, a security field of four bytes is added to the message 862 right after the ICMPv6 header. Moreover, RPL provides few 863 security mechanisms to ensure network data confidentiality 864 and integrity. In fact, RPL security mechanisms can be seen 865 as three possible security modes, (i) unsecured mode where 866 the exchange security relies on the security of other layers if 867 any is implemented; (ii) pre-installed mode where nodes fully 868 join the network with a pre-shared key and; (iii) authenticated 869 mode where nodes join the network only as leafs waiting 870 for an authentication authority to provide a second key to 871 be fully connected to the network [85]. It is specified in 872 RPL specification document [83] that the encryption for RPL  IPv4 was not taken into consideration while designing the 920 IPv4 protocol, some security alternatives were developed.

921
The Secure Sockets Layer (SSL) is one of them and used to 922 secure web browsing, data transfers and e-mails [89]. The use 923 of IPSec in IPv6 will not make IPv6 more secure than IPv4 924 as this security mechanism is available for both of them. The 925 need of Key Management Infrastructure (KMI) is vital for the 926 use of IPSec to make the implementations of IPv4 and IPv6 927 more practical. In addition to that, establishing a KMI is not 928 an easy task as it requires complicated mechanisms of trust 929 and key management [86]. The Support Layer [90] that provides support for the require-932 ments of diversified applications via intelligent comput-933 ing techniques, for instance cloud computing, middleware, 934 service support etc. is merged with the Application Layer 935 in the proposed IoT ecosystem architecture. Additionally, 936 the Application Layer consists of applications and services 937 including but not limited to intelligent transportation, health-938 care, intelligent traffic, smart environment, smart home, 939 etc., [90]. The security of IoT applications merely is not a part 940 of this paper, but also we focus on the security of the cloud in 941 an IoT ecosystem.

942
The cloud provides to companies and users various capa-943 bilities such as computing power, storage capacity, services, 944 and running applications over the Internet. However, there are 945 several security concerns related to cloud computing which 946 are faced by both, the cloud providers and their customers. 947 A number IoT cloud providers presented in [91] and [92] 948 are emerging into the market. In this following paragraph we 949 present the security mechanisms of Amazon Web Services 950 cloud platform. AWS is a cloud computing platform with high scalability, 953 availability and dependability. AWS presents the necessary 954 tools for customers to run different kind of applications. 955 Confidentiality, Integrity, and Availability (CIA) are very 956 important for AWS to maintain the client's confidence and 957 trust. One of the security policies of AWS is the shared 958 security responsibility [93]. The security responsibility is 959 shared between the customer and the cloud service provider at 960 the moment where the customer moves its system and data to 961 the cloud. AWS is responsible of securing the infrastructure 962 where the cloud is installed and the customer is responsible 963 to put the data on the cloud or the connectivity to it. For 964 instance, configuration of certain security features on the 965 cloud such as user accounts and credentials, logging, and 966 TLS/SSL for data transmission is the responsibility of the 967 customer. Security configurations that has to be done by 968 the customer varies also depending on the selected cloud 969 services and the customer's data degree of sensitivity. On the 970 other hand AWS is responsible of protecting the global 971 infrastructure such as hardware, software, networking, and 972 facilities where all the offered AWS services are run. Pro-973 tecting the infrastructure hisas the highest priority for AWS.   Table 4 how the IoT enabling technologies presented 1030 in this paper may be affected by these attacks. Wireless sensor networks can quickly scale to large node con-1035 figurations. As the sensor nodes are low-cost, their hardware 1036 components are unprotected by a type of physical shielding 1037 that could prevent access to processing, memory, sensing or 1038 communication components. Therefore, placing unshielded 1039 sensor node in a hostile environment enables an adversary 1040 with a little effort to access the sensor's internal state and 1041 capture, replicate or insert a duplicated node in a chosen net-1042 work. Such attacks may cause dramatic consequences and the 1043 network might be corrupted by the adversary or disconnects 1044 a significant part of it [95]. Jamming attack belongs to one of the DoS attack class. 1053 It is an active attack, meaning that it can be responsible of 1054 modifying the data stream or a creation of false data stream. 1055 In this attack an adversary employs malicious nodes to disrupt 1056 the communication in an IoT perception network through 1057 interference. In resource-constrained network, these type of 1058 attacks affect negatively the limited resources of the devices, 1059 hence harming the network. Jamming attack can be classified 1060 into four types [97]: Constant jamming, where the attacker 1061 generates constant noise at the same frequency that the WSN 1062 operates; Deceptive jamming, where the attacker replaces 1063 the valid signals or fabricates instead of sending random 1064 bits; Random jamming, where the jammer node jams the 1065 network for a particular amount of time and turns off the 1066 radio and sleeps for the rest of time instead of being active 1067 continuously; and reactive jamming, where the jammer node 1068 stays quiet when the channel is idle and starts emitting radio 1069 signals as soon as it senses the channel activity. In this type of attack, the attacker intercepts the commu-1072 nication between two nodes and becomes the originator of 1073 messages. The receiver node can be tricked thinking that the 1074 received messages are from a legitimate source. An example 1075 of MiM attack is in RFID systems where the attacker places 1076 two fake nodes, one close to the tag and another one close to 1077 the reader whom it wants to be deceived. After intercepting 1078 the signal from the reader, the fake node close to the reader 1079 forwards the signal to the fake node near the tag without 1080 trying to identify the content of the messages. Similarly, the 1081 fake node close to the tag forwards the signal to the tag and 1082          In reconnaissance attack, an intruder collects data about hosts 1254 and other network devices and also interconnections of the 1255 victim's network and use it to perform other types of attacks. 1256 There are two types of methods that are used to launch a 1257 reconnaissance attack. Active methods consist of scanning 1258 techniques and passive methods such as data mining. One of 1259 the active methods is where the intruder pings the targeted 1260 network using ping probes to determine the victim's network 1261 IP addresses. Once the pinging is done, the intruder scans the 1262 ports usually using a software that can perform both actions, 1263 pinging and port scan. Although reconnaissance procedures 1264 are the same in both IPv4 and IPv6 networks, the size of 1265 the sub network (Subnet) in IPv6 (64 bits), which is much 1266 larger than the one in IPv4, makes IPv6 networks much 1267 more resistant to reconnaissance attacks than IPv4 networks 1268 and because of this the number of probes that the intruder 1269 must introduce is (2 64 ) which is practically impossible [89]. 1270 Even though IPv6 based networks are more immune against 1271 reconnaissance attacks, the multicast addresses defined in 1272 IPv6 specification document [80] can enable the intruder to 1273 perform attacks targeting some of the network's resource. In this type of attack, an adversary can spread a malicious 1277 code using different means such as downloading files on the 1278 Internet, emails or instantaneously attached files (pictures, 1279 docs, etc.). The worm replicates itself exponentially in the 1280 system or the network where it is sent or installed. With this 1281 action, the adversary tries to create damages in the targeted 1282 system by consuming storage space or network bandwidth. 1283 While with viruses the adversary generally aims to corrupt or 1284 modify files [96].

V. CURRENT SECURITY MECHANISMS IN IoT ECOSYSTEM 1290
A secure and efficient implementation of an IoT ecosystem 1291 needs to take in account three primary security and pri-1292 vacy goals; Confidentiality, Integrity and Availability (CIA). 1293 Confidentiality, which is roughly equivalent to privacy is an 1294 important feature in an IoT ecosystem. This feature ensures 1295 the protection of data such as patient's data, private infor-1296 mation and secret keys from unauthorized access or to be 1297 maintenance and upgrades. It is also ensured by providing 1318 adequate communication bandwidth for critical systems and 1319 take in account the bottlenecks problems. Redundancy and 1320 making backups are also important concepts when it comes 1321 to providing a reliable IoT ecosystem. Moreover, fast and 1322 adaptive recovery of IoT system from unusual situations such 1323 as attacks or natural disasters or another worse scenario is 1324 essential [113].

1325
Developing a secure IoT ecosystem and taking into account 1326 possible security risks is very difficult task. Therefore, the 1327 Open Web Application Security Project (OWASP) defines 1328 the broadly agreed ten rules representing the most critical 1329 security risks to an IoT ecosystem [114]. This helps the man-1330 ufacturers, developers and consumers to better understand the 1331 security risks associated with IoT. Moreover, it helps users to 1332 make better security decisions when building, deploying or 1333 assessing the technology. The conventional cryptographic methods might not be suit-1412 able for IoT devices due to their resource-constrained 1413 nature. Moreover, the conventional algorithms may incur 1414 too high latency or cause high power consumption for 1415 such devices. Therefore, lightweight cryptography is the 1416 required technology ensuring security of end-to-end com-1417 munication, low power consumption and adaptability in 1418 resource-constrained environments. However, there are three 1419 major challenges that need to be considered when deploy-1420 ing cryptographic security solutions to IoT devices [123]. 1421 First is the overhead of security solutions which must be 1422 reduced to fit with the resource-constrained nature of IoT. 1423 Second is the power consumption of security solutions 1424 which must be minimal. Third is the security solution per-1425 formance that should be acceptable to support application 1426 needs. The aforementioned challenges motivate researchers 1427 to find a lightweight cryptographic primitives applicable and 1428 can secure pervasive resource-constrained devices such as 1429 RFID tags and wireless sensor nodes. The National Insti-  In an IoT network, a secure routing protocol is required 1503 to only guarantee message availability. However, messages 1504 integrity and confidentiality can be handled at higher lay-1505 ers. To prevent routing attacks, several routing protocols 1506 for WSN and Wireless Ad-hoc Networks (WANET) are 1507 proposed in the literature. Secure multi-hop routing for IoT 1508 communications (SMRP) [139] is an idea of merging the 1509 node's authentication process when joining the network with 1510 the routing process providing IoT network security without 1511 incurring significant overheads. Authors in this work deduce 1512 that SMRP produces a secure multi-hop IoT network without 1513 performance degradation when compared to the Optimized 1514 Link State Routing Protocol (OLSR). Another secure rout-1515 ing protocol named Two-way acknowledgment-based trust 1516 (2-ACKT) is proposed in [140]. This protocol calculates 1517 the trust based on the link layer acknowledgment (LLACK) 1518 in IEEE 802.15.4 MAC and a two hop acknowledgment 1519 from the downstream neighbor. A framework based on 1520 block-chain to identify and report malicious nodes try-1521 ing to tamper a Low-power and Lossy Network (LLN) 1522 configuration information is proposed in [141]. SCOTRES 1523 scheme [142] is also proposed to be integrated with the 1524 Dynamic Source Routing (DSR) to secure routing func-1525 tionality in the network layer of WSN or WANET. This 1526 protocol is proposed to be deployed in network with low 1527 mobility.    inter-operable IoT as defined in [143] and [45]. The 6LoW-  At the PB a , DTLS can be used to secure applications running 1586 under CoAP protocol or TLS for applications using MQTT 1587 instead. IEEE 802.15.4 security primitives can also be used 1588 within the 6LoWPAN adaptation layer. Due to the limited 1589 resources on the IoT devices, a lightweight cryptography is 1590 required ensuring security to end-to-end communication and 1591 low power consumption. At higher layers such as the Network 1592 Layer and the Application Layer, IPsec and SSL/TLS are used 1593 respectively. Researchers working in this field have enormous 1594 scope in building a robust IoT ecosystem that can be trusted 1595 by the end users. Alternatively, to explore implementing 1596 ''zero trust'' approach into devices while maintaining effec-1597 tive security controls is another research direction. Some 1598 of the key research areas include trusted ecosystems and 1599 mutual authentication, provisioning of highly scalable device 1600 identities, and designing public key infrastructure from the 1601 production floor to the end-user.

1603
The integration of IoT devices into the Internet is challenging 1604 as they are characterized differently from the traditional inter-1605 net devices, more specifically characteristics such as power 1606 consumption, computational power and storage capacity. 1607 Moreover, IoT enabling technologies and standardized proto-1608 cols presented in this paper enable IoT resource-constrained 1609 devices to be integrated to IPv6 Internet. 1610 In this paper we have proposed a modified three layer 1611 architecture of an IoT ecosystem by dividing the Perception 1612 Layer into three blocks. The reason behind this is to dif-1613 ferentiate high-level applications from low-level application 1614 protocols both of which are often placed at the Application 1615 Layer of the IoT architecture. Another reason is to differen-1616 tiate IoT LLNs with the Internet in such a way that the pro-1617 posed architecture gives a better classification of the enabling 1618 technologies, threats and countermeasures.

1619
The paper highlighted some of the key technologies, 1620 protocols and standards with their native security challenges, 1621 concerns and resolutions. By combining these technologies 1622 and standards, a secure layer-wise IoT architecture is estab-1623 lished and a secured 6LoWPAN stack can be formed in future 1624 as extension. He is currently an Associate Professor and the 2126 Head of the SmartSecLab, School of Economics, 2127 Innovation and Technology, Kristiania University 2128 College, Oslo, Norway. His work in academia and 2129 industry is widely related to the application of AI 2130 for cybersecurity, detection of computer viruses, 2131 network attacks, and the protection of IoT devices. 2132 He is currently leading ENViSEC and SecureUAV projects that were granted 2133 EU Horizon2020 cascading funding from NGI programs. He is an Affiliated 2134 Member of the Malware Lab and Digital Forensics Group, Norwegian 2135 University of Science and Technology. From before, he was involved as 2136 a cybersecurity researcher in the EUIPO framework related to malware 2137 analysis on copyright-infringing websites. He also serves as a nominated European and national projects. Today he holds a professorship within 2158 electrical engineering. He has next to his academic career also been working 2159 with truly innovative projects which are also a part of his additional skills. 2160 He is a person that identifies the need within an industry, market segment 2161 or culture, and spot opportunity in it. More importantly, he has also the 2162 ability to identify needs before implemented in the market, develop and refine 2163 solutions, take chances, push the envelope, and create meaning. He is special-2164 ized within information security, e-health, autonomous systems, biometric 2165 systems, wireless communications, the IoT, and digital fundamentals micro-2166 controllers. His Ph.D. research interests include smart mobile technologies 2167 and also biometrics with specialization on behavioral biometric recognition 2168 in mobile devices.