SecTrust-RPL: A secure trust-aware RPL routing protocol for Internet of Things

Accepted Manuscript SecTrust-RPL: A secure trust-aware RPL routing protocol for Internet of Things David Airehrour, Jairo A. Gutierrez, Sayan Kumar Ray

PII: DOI: Reference:

S0167-739X(17)30658-1 https://doi.org/10.1016/j.future.2018.03.021 FUTURE 4033

To appear in:

Future Generation Computer Systems

Received date : 15 April 2017 Revised date : 21 December 2017 Accepted date : 10 March 2018 Please cite this article as: D. Airehrour, J.A. Gutierrez, S.K. Ray, SecTrust-RPL: A secure trust-aware RPL routing protocol for Internet of Things, Future Generation Computer Systems (2018), https://doi.org/10.1016/j.future.2018.03.021 This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.

SecTrust-RPL: A Secure Trust-Aware RPL Routing Protocol for Internet of Things David Airehrour Nelson Marlborough Institute of Technology Auckland, New Zealand

Jairo A. Gutierrez Auckland University of Technology Auckland, New Zealand

Sayan Kumar Ray Manukau Institute of Technology Auckland, New Zealand Keywords— RPL; SecTrust; SecTrust-RPL; Trust; Rank attacks; Sybil attacks. Abstract— The Routing Protocol for Low-Power and Lossy Networks (RPL), the de facto routing protocol for Internet of Things (IoT) offers little protection against various forms of routing attacks. An attacker can exploit the routing system of RPL to launch destructive and devastating attacks against an IoT network. Popular among these IoT attacks are Rank and Sybil attacks. To secure IoT networks from routing attacks, a time-based trust-aware RPL routing protocol (SecTrust-RPL) is proposed and implemented. The Secure Trust (SecTrust) trust system is embedded into the RPL routing protocol to provide protection against Rank and Sybil attacks. SecTrust-RPL uses a trust-based mechanism to detect and isolate attacks while optimizing network performance. The performance of SecTrust-RPL is compared with the standard RPL protocol. SecTrust-RPL protocol demonstrates its superior performance over the standard RPL protocol in the detection and isolation of Rank and Sybil attacks. The effectiveness and resilience of SecTrust-RPL is demonstrated through extensive simulation studies and testbed experiments. Based on SecTrust-RPL, we show as a proof-of-concept the viability of using trust as an effective security system for mitigating attacks in IoT networks.

1. INTRODUCTION The Internet of Things is a technological revolution that has emerged from previous technologies including Mobile Ad hoc NETworks (MANETs) and Wireless Sensor Networks (WSN) [1]. MANET is a network of free and mobile nodes (devices) communicating in an ad hoc manner without the aid of any centralized administrative infrastructure like access points or base stations. They are self-configuring, and could communicate to achieve the specific purpose for which they are set up. Therefore, they are referred to as Self-Organizing Networks (SONs) [2]. MANET nodes communicate in a peer-to-peer manner with directly connected neighbours. Due to their mobility and limited battery life, they are limited in their transmission power and bandwidth availability. Mobile nodes in ad hoc networks often cooperate to transmit data and route information to other nodes that they are not directly connected to each other hence, they act as routers where they compute routes and create routing tables of destination to other nodes. The Internet of Things (IoT) is the widespread use of systems, heterogeneous technologies and the evolving paradigm of the interconnectedness of devices, using TCP/IP protocols, around our physical environments [3]. The application of IoT could be found in many areas of the economy ranging from agriculture, building and management automation, industrial smart grids systems, water grids and smart cities. The sensors deployed in these kinds of networks are energy-constrained; they perform storage and computational functions while communicating over lossy channels. One of the fundamental driving forces of IoT is networking and particularly routing, which drives and facilitates the interconnection of devices [4]. A major consideration during IoT routing are: scalability, autonomy and secure communication and energy efficiency [5]. However, the unique characteristics of IoT networks make them vulnerable to attacks. Consequently, routing and secure data communication have become topical research concerns in IoT [6]. As noted by [7], routing and addressing are two important issues in IoT, which need to be dealt with since network topologies across several networks vary and the need for common understanding and uniformity is important for proper routing of a packet originating or arriving at an IoT enabled device. Undeniably, the roadmap to achieving ubiquitous IoT brings various challenges ranging from device integration, heterogeneity, scalability to mobility, routing, security and other specific challenges [8]. It is clear from the above that IoT security is an aspect that requires in-depth research work as the need to secure networks today have become imperative.

The focus of this research study is to propose a Trust-aware RPL Routing Protocol (SecTrust-RPL) for IoT that could detect and isolate routing attacks while providing acceptable network performance. SecTrust-RPL is a Trustbased RPL routing protocol predicated on our earlier proposed SecTrust framework. The SecTrust framework was presented in [9]. However, this study is a major revision to our work presented in [9] and a proposal for a secure Trust-aware RPL protocol based on the SecTrust framework. The contributions of this paper include: i. ii. iii. iv. v.

In our paper [9], a design was proposed, but no validation of our design was performed. This study proposes a revision of the framework proposed in [9]. The proposed SecTrust framework is mapped to the RPL routing protocol, which provides a new Trustaware RPL protocol (SecTrust-RPL). The effectiveness of SecTrust-RPL is compared against the standard RPL protocol using simulation under Rank and Sybil attacks. A simulation study is performed comparing SecTrust-RPL against the standard RPL protocol in delivering good network performance while under Rank and Sybil attacks. A testbed experimentation of SecTrust-RPL’s simulation study is performed to validate the simulation results presented.

The rest of the paper is organized as thus: Section 2 presents a discussion on RPL and security in RPL. Studies are further presented on Trust-based RPL routing protocols while a discussion on trust in IoT and the design considerations of our proposed trust-based system is presented. Section 3 describes our proposed Trust framework system (SecTrust) and its constituent parts. In section 4, SecTrust is embedded into RPL routing protocol (SecTrustRPL) and a simulation study is presented that compares SecTrust-RPL with the standard RPL. Section 5 provides a testbed experimentation of SecTrust-RPL and RPL. This experimentation serves as a validation of the simulation study presented in Section 4. In Section 6, a conclusion of our findings is presented with future extensions to our work. 2. RPL ROUTING PROTOCOL Routing Protocol for Low power and Lossy Networks (RPL), is the de facto IoT routing protocol for communication [10]. RPL operates by discovering routes as soon as it becomes operational. This attribute classifies it as a proactive routing protocol. On initiation, a RPL protocol creates a tree like topology called Directed Acyclic Graph (DAG) and every sensor node operating in a RPL network selects a parent node which acts like a packet gateway for that node [10]. Information regarding the topology of RPL is maintained as a graph-like structure called the Destination Oriented Directed Acyclic Graph (DODAG). The DODAG consists of paths from the sender nodes to the sink node. During routing, every node maintains its rank relative to its position in the DODAG tree, and every DODAG is populated with parent information. The parent information, which include control and route information are used for routing and network stability. The packets used by DODAG are DODAG Information Object (DIO) and DODAG Information Solicitation (DIS) for transmitting the DODAG information. Route path selection is a key factor for RPL, and unlike conventional routing protocols, RPL utilizes different factors to compute the best route path. Various routing metrics, route constraints and objective functions (OF) are among some factors used during routing. Routing decisions are based on specified OFs like hop count, energy minimization and latency amongst others. 2.1 Security in RPL The report specified by the IETF ROLL workgroup on RPL presents security requirements and goals for RPL, but no specific security models were proposed. The current RPL protocol standard [10] basically uses key management in applications for pre-configured devices. The key enables the authentication of devices joining the RPL network. A security design weakness in the IETF RPL standard is the lack of specification of how the authentication and secure network connection among sensor devices running security critical missions is defined. This exposes such devices to attacks. In fact, studies [11-13] have shown the RPL protocol to be vulnerable to several routing attacks including: Route Falsification, Byzantine, Rank, Routing Information Replay, Sybil, Selective Forwarding, Sinkhole, Blackhole, Greyhole and Version Number attacks. The security of Routing Over Low power and Lossy networks (ROLL) protocols was discussed by the authors in [12]. The authors discussed the threat analysis on ROLL and presented possible ways of addressing the threat challenges. In their study, they identified RPL threats by means of the ISO 7498-2 security reference model of [14]. The security reference model in [14] defines several features of good and secure communication such as confidentiality, integrity, access control, authentication, availability and non-repudiation. The model describes areas to protect and an identification of probable susceptible areas requiring defense that could compromise network security. The model provides for the categorization of threats and attacks that affect the confidentiality, integrity and availability of ROLL routing protocols. The authors in conclusion, proposed a ROLL security framework adapted to the 6LOWPAN environment. The framework addresses security properties that could be incorporated to enhance routing security in RPL. However, this necessitates thoughtful considerations since the methodology for achieving this, and the consequent impact extends beyond the boundaries of ROLL routing protocols.

2.2 Secure RPL Routing Protocols Related work on securing the RPL protocol have been put forward to address the security challenges in RPL. These studies have adopted diverse techniques in enhancing the security of RPL protocol. The authors in [15] provided a detailed analysis of internal RPL attacks, with focus on the RPL Rank property. An internal attacker who has compromised a node within a RPL network could randomly inject route packets with malicious intents. The Rank property in RPL is used to prevent routing loops and minimize route control overhead and, to promote route optimization. Furthermore, the paper presented variants of the RPL Rank property attack and their impact on the performance of RPL networks. The authors in their findings, identified that a key limitation in RPL protocol was that the details of the control messages of a parent-node is unknown by a child-node. The details exposed to a child-node are just what it needs to decide what parent to select from the list of potential parents. This leaves the child-node from adequately assessing the services a potential parent-node could offer. This implies that the selection of a malicious parent-node will mean such child-node will be unable to reach the sink node and have its packets compromised. The authors in their conclusion did not propose any framework for assessing parental node behaviour or activities, but they however, recommended the integration of a monitoring system into RPL that could assist a child-node observe, evaluate and select parents that are trustworthy. A study of internal attacks is presented in [16]. The study shows that an internal attacker could create a Sybillike replica of the RPL DODAG root node with similar reachability like the original DODAG root node. This attack is perpetrated to undermine the RPL network. An attacker sends higher RPL instance version number to masquerade as the DODAG root node so it could create a route topology around itself. Thus, a higher RPL instance version is broadcast by the attacker, which induces a section of nodes in the original RPL network to join the newly created, but fake DODAG root node. This situation provides the attacker with the opportunity to snoop and manipulate nodes under it. To address this attack, the authors in [16] proposed the use of a RPL instance version number with a Rank authentication system built on one-way hash chains that associates the RPL instance version numbers with the authentication scheme. The system provides a promising protection against RPL version number attacks transmitting higher RPL instance version numbers or sending spuriously low DIO Rank values. Although the paper provides a good evaluation of network performance with respect to time, nevertheless, the authors failed to address the impact of their system on the battery power, the constrained memory and the limited CPU cycle that typical IoT sensor nodes are made of. Other related research works presented are summarized in Table 1. Table 1 provides a summary of secure RPL routing protocols that have addressed different RPL routing related attacks. Their techniques and weaknesses are also highlighted. From the discussions above and Table 1 presented below, it can be observed that Rank and Sinkhole attacks are among the common RPL attacks. Another type of attack on RPL that has not being discussed in this study is the Sybil attack. Rank and Sybil attacks are among the most damaging attacks that compromise the RPL protocol [3]. A brief discussion is presented below on Rank and Sybil attacks since these attacks are addressed in this study.  Rank Attacks In a Rank attack, a malicious node advertises a spuriously beneficial routing path by changing its rank thereby attracting neighbour nodes to route their traffic through it. Packets routed through this malicious node are either routed to other colluding attacking nodes like Blackhole or Selective Forwarding nodes with the aim of dropping the packets, selectively forwarding packets to other destinations, or for the purpose of divulging confidential information of the network [15]. The success of a Rank attack depends largely on the collaborative nature of the attacks (e.g., a Rank attack node colluding with a Blackhole or a Sybil attack which drops or falsifies the route information in order to disrupt the network route topology).  Sybil Attacks Sybil attacks are subtle attacks. A malicious node perpetrating this type of attack could masquerade as several entities. To advance its attacks, a Sybil node could further launch Byzantine attacks on the network. This creates an illusion that there are many malicious nodes operating within the network thus, overwhelming the network and thereby disrupting the topology of the network [17]. Although several techniques have been proposed to address the security vulnerabilities in RPL protocol, from the survey of literature presented above and the summary presented in Table 1, these techniques display various weaknesses that makes them inadequate to the nature of the resource-constrained IoT sensor nodes. A promising concept however, that is actively being researched in addressing security vulnerabilities in RPL protocol is the concept of Trust.

Table 1: Summary of Secure RPL Routing Protocol Protocol/References

Techniques

A Secure Routing Protocol Based on RPL for Internet of Things [18]

RPL Rank threshold with hash chain authentication

New trust metric for the RPL routing protocol [19]

A Trust-based RPL objective function computation

Low false alarm rate RPL network monitoring system by considering timing inconstancy between the rank measurements [20] Strong authentication countermeasures using dynamic keying for sinkhole and distance spoofing attacks in smart grid networks [21] InDReS: An Intrusion Detection and response system for Internet of Things with 6LoWPAN [22]

Use of timestamp to detect RPL rank inconsistencies.

Attacks addressed Rank and Sinkhole attacks

Brief description A RPL protocol to minimize the rank manipulation impact using the concept of rank threshold limits and hash chain authentication

Weaknesses Protocol uses cryptography with hash chain authentication, which is computationally expensive. In addition, nodes are vulnerable to insider attacks that promote Blackhole and Selective forwarding attacks

Rank falsification attacks in RPL and secure exchange of routing path between nodes Rank version attack

A trust-based design in which a node's behaviour and the trust along a path is used in determining a secure and optimal routing path. A low false alarm RPL network monitoring system for the detection of Rank inconsistencies using timestamps on route packets

Increased computation leading to communication overhead and energy consumption. No simulation to validate design proposed.

Cryptography and data mining techniques

Sinkhole and distance spoofing attacks

Unable to detect anomalous requests from compromised nodes in the network that can be used to perpetrate attacks.

Statistical probability

Sinkhole attacks

A specification-based IDS for detecting attacks on RPL-based network topology [23]

Specificationbased

Detects Rank, Sinkhole, Local Repair, Neighbor, and DIS attacks.

A secure smart grid communication system using encrypted authentication system and key-compromising detection through data mining methods A probabilistic constraintbased specification model of an intrusion detection response system to defend against Sinkhole attacks in RPL networks. A rule-based attack detection system for routing attacks on RPL protocol.

Real time intrusion and wormhole attack detection in Internet of Things [24]

Anomaly-based

Wormhole attack

An intrusion detection system that uses node location, received signal strength, and neighbour node information to detect Wormhole attacks

Does not provide a system to guard against the falsification of the time-stamp by malicious nodes.

Prone to much false positive alerts and energy node depletion.

It detects but does not isolate malicious nodes from the network. Prone to high falsepositive alerts. Also, high energy consumption as the number of nodes increase. Requires strategic placement for efficient detection. In a mobile environment, this will prove ineffective against attackers. Energy overhead increases as the number of nodes increase

2.3 Trust and Trust as Defence Mechanism Trust could be defined as the relationship between two parties - the trustor and the trustee. The trustor is willing to rely on the trustee to perform some set of actions on its behalf. Therefore, the trustor evaluates the trustee to assess its trustworthiness to perform the said actions. The concept of trust in the social sciences have been used extensively and attributed to relationships among persons, entities, objects or actions. In sensor networks, trust is a topical area of research, which is being used to assess the trustworthy character of a node [25]. The trustworthy character of a node is predicated on a node’s behaviour in the network towards its neighbours. The trustworthy character of a sensor node is measured in terms of the following: reliability, confidence level, belief, integrity and dependability. These properties are empirically quantified and cumulatively aggregated to give a node a weighted value as a representation of its trust rating in the network. According to the authors in [25], a node’s trust value is an index that defines the reputation of a node, which shows a computable range of values as an expression of the positive or negative experiences of a node’s observed behaviour over a period of time while having a direct or indirect interaction or relationship with its neighbor(s).

Trust Management in IoT has been proposed and demonstrated as an important concept in the development of a stable and secure IoT network configuration. Trust Management can be used to improve the security of nodes especially when the number of nodes expand to proportions that cannot be managed either by a central coordinating unit or when the communication among nodes must traverse several network media. Trust evaluates the trustworthiness of a node and the quality of services a node could render to its neighbour. Quality of services like aiding in decision making process for secure and optimal route decisions. In addition, rewards and penalty can be implemented to enforce trustworthy compliance of nodes [26]. The resource constraint nature of IoT sensor nodes makes cryptographic solution an unsuitable option for them hence, making them susceptible to compromises. Contrariwise, Trust Management does not possess the many complex encryptions and hashing procedures as presented in cryptographic solutions. This makes Trust Management a viable option for improving security in IoT nodes. In addition, Trust Management provides a system for the continuous observation of the performance and behavioural patterns of nodes, evaluate their trustworthiness, and discover trustworthy nodes to collaborate with. To advance this further, the authors of [27] have presented some unique benefits of using Trust Management system, which are listed below.   

A Trust Management system offers different levels of access control to a network based on the assessed quality of service provided by the evaluated node, which other security schemes may not provide. A Trust Management system helps in the isolation of malicious actors while providing trustworthy routing paths. Trust Management helps improve other traditional security systems by using the Trust system of evaluation to ensure that only trusted nodes participate in the authentication, authorization or key management during secure communications.

2.3.1 Trust-based RPL Routing Protocol Trust-based RPL routing protocols have been proposed to enhance the security of RPL protocol. Various trust metrics have been developed and embedded into the RPL protocol to enhance its security during routing decisions. Table 2 presents some Trust-based RPL routing protocols with attacks addressed, trust-based technique used, weaknesses, and validation method. Based on the study summaries presented in Tables 1 and 2 some design considerations for an effective trust-aware RPL protocol is discussed in the next section. 2.3.2 Design Considerations for a Trust-Aware RPL Routing Protocol This section presents design considerations in our proposed Secure Trust RPL protocol. The design goals are based on the need to have a secure and efficient system that could scale even on a large IoT network. The design considerations include:  Detection and Isolation of Attacks The most important task of any secure information system is to guarantee the confidentiality, integrity, availability and authenticity of the information transmitted. This issue becomes challenging in IoT networks, where the devices are resource constrained, and due to the lossy nature of the wireless transmission media. This research focuses on the detection and isolation of insider attacks that are rather more difficult to detect as the malicious nodes form part of the network and are privy to every detail of the network process.  Improved Network Throughput The detection and isolation of attacks in a network though very important, should not however, impose undue overhead on network performance. There should be acceptable network performance measurement. In this study, packet loss rates are measured to determine how well our proposed system can deliver good network performance while isolating attacks in comparison to the standard RPL protocol. Other network performance measurements were also investigated however, for brevity they are not presented here.  Scalability and Adaptability The ability of a protocol to scale on large networks makes it a viable option for consideration and adoption. Our proposed protocol is expected to work well on large IoT networks. The scalability and adaptability of the proposed SecTrust-RPL are tested through simulation studies and testbed experimentations under the proposed attacks. The IoT sensor nodes are assumed to be stationary during testing.

Table 2: Trust-based RPL Routing Protocols Protocol

Techniques

Attacks addressed

Brief description

Weaknesses

Trust-based RPL for the Internet of Things [28]

Use of trustworthiness among RPL nodes

Internal and External RPL attacks

No specific attacks are addressed and no simulation or testbed experiment was performed to verify the effectiveness of the Trust-based RPL protocol.

New Trust Metric for the RPL Routing Protocol [19]

Introduction of a trust metric system in the DIO of RPL.

Addresses trustbased issues during route path construction and maintenance among RPL nodes

A node computes the trust values of its direct neighbors based on direct trustworthiness of a node and the feedback received from neighbour nodes. Using the sum of these two parameters the average trust value of a RPL node is computed and a parent node is selected. A trust-based secure RPL protocol enhancement scheme, which deals with the trust inference issues in RPL during the construction and maintenance of routing paths from each node.

Towards A Trust Computing Architecture for RPL in Cyber Physical Systems [29]

Trust establishment and key exchange mechanism among RPL nodes

Network availability and integrity, tamper-proofing routing packets from attacks

The design of trust establishment and key exchange system in RPLbased networks using a Trust Platform Module that provides keys among authenticated nodes to communicate in secure mode

SpecificationBased IDS for Detecting Attacks on RPL-Based Network Topology [30]

Semi-auto profiling specification technique for RPL specification

Neighbor, Rank, Local Repair, Sinkhole and DIS attacks

The development of a profiling system through the deployment of cluster node heads for the defense against various intrusion attacks among nodes in a RPL network.

Trust-Based Neighbor Unreachability Detection for RPL [31]

A cross-layer Trust-based Neighbor Unreachability Detection mechanism

Improves network reachability and availability.

Secure parent node selection scheme in route construction to exclude attacking nodes from RPL network [32]

A Trust-based threshold mechanism for node evaluation

Rank attack

Implementation of a Trust-based Neighbor Unreachability Detection scheme to improve network availability in a RPL network by using trust management system to specify solicitation from neighbours A RPL protocol secure parent selection based on a trust threshold selection in which, malicious rank attacking nodes see no merits to attribute false ranks to themselves to attract other nodes

Strong authentication countermeasures using dynamic keying for sinkhole and distance spoofing attacks in smart grid networks [21]

Key encryption and data mining

Sinkhole and Distance spoofing attacks

A RPL based protocol for smartgrid networks which implements an encrypted authentication system between nodes, and key compromises through data mining

Additional layer of computation and communication overhead through the extension of DIO. Does not address known attacks like Blackhole, Rank, Sybil attacks. System depends largely on a TPM module, which is a single point of failure, and if compromised or unavailable, grounds the RPL network. It also adds additional cryptographic processing on already constrained nodes. Profiles node activities based on the false-positive node behaviour which is prone to false alarms; Cluster heads could be compromised; Prone to good-mouthing and badmouthing attacks. No specific attacks addressed, and trust parameters are not adaptable due to changing network dynamics

Validation Method Design proposed with no validation performed

Simulation

Simulation

Design proposed with no validation performed

Simulation

Susceptible to attacks like Sybil and Blackhole attacks

Simulation

System susceptible to internal node compromises; not suitable for battery powered RPL networks

Simulation

3. THE SECTRUST SYSTEM SecTrust is a Trust-based framework for secure communication in IoT. It is a security framework that promotes secure communication, identifies and isolates malicious actors from the network. Although it is proposed as a secure communication framework for IoT, it is however a framework that finds relevance in Recommendation systems

like e-commerce, online shopping and the social media systems. In this study, the SecTrust framework is applied to RPL routing protocol in order to provide secure routing. SecTrust computes and evaluates the trustworthy behaviour of a node. A node’s trustworthiness in SecTrust is characterized through the evaluation of its neighbouring nodes while providing services (recommendations and indirect trust values) to its neighbour nodes. This trustworthiness reflects the level of reliability or dependability (trust) that a peer node in the network has on its directly connected neighbour. The trustworthiness of a node is evaluated as a time based successful packet exchange between nodes, and the positive packet acknowledgements with a continuous observation of linked nodes. The design of SecTrust system has been proposed and presented in our previous published paper [9]. In the SecTrust framework, every node computes the trustworthiness of its direct neighbours based on the computed direct trust value and the recommended trust value. While neighbours with greater trust values are chosen for secure routing, nodes with lower trust values are categorised either as malicious, compromised, or perhaps selfish nodes that seek to preserve their resources such as battery power. The proposed system is made up of five processes: trust calculation process, trust monitoring process, detection and isolation of malicious nodes, trust rating process and trust backup/recuperation process. Figure 3 provides a flowchart design of the SecTrust framework highlighting all five processes. SecTrust uses the concept of fuzzy threshold based trust broadcast [33]. The concept is to broadcast trustworthy nodes throughout the network by, i) maintaining effective communication only among trusted nodes and, ii) ensuring the broadcast of only trustworthy information to neighbour nodes in the network. SecTrust ensures this by validating the trustworthy nature of every forwarding node in the network and by securing the source of route information transmitted. Furthermore, a method is provided to rank the best trust formation to optimize the performance of secure trust-based routing among IoT nodes. The SecTrust system observes various trust properties while assigning different weights to them. It is particularly important that more weight be attributed to the evaluation of a node at the current time rather than its observable history. This is prompted in order to defeat malicious nodes that may seek to build a good reputation over time and then later begin to perpetrate their malicious activities. The SecTrust system demonstrates that trust converges to the extremes (i.e. highly trusted nodes tend to maintain high trust values while malicious nodes tend to low trust values). Finally, a repository of nodes with high trust values are formed, and due to the penalty introduced for misbehaving nodes, the trust value between any two adjoining nodes that do not optimally trust each other tends to zero. A detailed description of the trust processes and its components are presented in the section following. 3.1 Design of SecTrust SecTrust is a composition of five systemic processes that operate in unison to provide secure route information among IoT nodes. A description of the inner workings of each process is discussed. 3.1.1 Trust Calculation Process In this process, a trustor node evaluates a trustee node, and it uses the trust value derived to judge if the trustee node is sufficiently reliable of fulfilling an assigned mission as assessed by the trust threshold system in Table 3. More specifically, the trust computation represents reliability, dependability, competence, and successful positive interactions or positive recommendations on performance of tasks sent by nodes from direct or indirect interactions with other nodes [34]. Direct and recommended trust relationships could exist between two or more nodes. Each node gathers the direct and recommended trust values of directly (Direct trust) and indirectly (recommended trust) linked neighbours. We offer a definition of terms and the trust types used. Neighbour: Given a node Ni, a neighbour to Ni is any set of nodes that are within a communication distance to Ni, such that it could offer a route path to the sink node. Direct trust: This is the belief a node has towards its directly connected neighbour of its reliability and capacity to perform the request sent to it. When a node establishes a communication link with its neighbour, it is said to be directly linked. The direct trust of a node is given as the likelihood of a successful interaction between nodes in order to determine a node’s packet forwarding behaviour to the right destination. As illustrated in Figure 2, in a relationship between two nodes, Ni and Nj, node Ni, keeps three records of every neighbour node, which include:   

PSij(t), the total number of packets sent to Nj by Ni. PFji(t), the total number of packets forwarded by Nj on behalf of Ni. t, time during evaluation of node j.

Node i

Direct(T)i,j

Direct(T)j,m

Node j

Node  m

Recommended(T) i,m Direct trust Recommended trust

Figure 2. Direct and Recommended trusts relationship description

Therefore, the likelihood of positive interactions or feedback between Ni and Nj, is given by DT(Ni,Nj), which evaluates whether Nj will be sufficiently truthful to forward packets on behalf of Ni. β defines the penalty weight attached to any misbehaving node. The β value is initially set at 0.01, but increases with increase in the misbehaviour of a node. In this study, β was set to 0.01, which represents 1% of a perfect trust value of 1.0 while the penalty increment is set at half the value (0.005). Therefore, if a node is evaluated, and its trust value is below the acceptable threshold for secure communication as defined in Table 3, then the β value increases to 0.015. This progressively reduces the trust value of a misbehaving node hence, isolating it from being considered for routing decisions. The penalty equation is given in Equation 1 while the direct trust computation is expressed in Equation 2. (1)

0.005   ,





(2)

 

Recommended trust: This is the confidence in the ability of a node to decide whether another node is consistent and dependable in the given trust class and in its honesty when recommending it to other distant nodes. For packet transmission to nodes that are 2-hops and beyond, a node depends on the recommended trust, in this case a node depends on the neighbour of its neighbours (indirectly linked). The recommended trust value of a node is computed as shown in Equation 3 below. ,

,

∗

,

 

(3)

gives the recommended trust value node Ni has towards , In the context of Figure 2 and Equation 3, , ) and nodes j and Nm, which is computed as the product of the direct trust values between nodes i and j ( , ). In SecTrust, a node can have a precise trust judgement regarding its next hop neighbours using m( observation, eavesdropping and snooping methods. For nodes beyond 1-hop, a node must depend on the trustworthy recommender nodes for accurate trust evaluation toward the distant node of interest. SecTrust’s aggregation of recommendations is based on a weighted calculation of direct trust values between linked nodes as shown in Equation 3. Additionally, a trust aggregation system is used by the trustor node to compute the trust value of its neighbour node at time t, with the objective of measuring at runtime the computed trust value of its neighbour node against the threshold of the trust tuple provided in Table 3. A novelty in the design of SecTrust system, besides its use of direct observations and recommendations for trust computation and aggregation, is its ability to make adaptive changes relative to the prevailing environmental conditions. As an example, with nodes moving at high speeds in a network, computing direct trust may become very ineffective due to nodes joining and leaving the network at a very fast pace. Under this condition, the trust system can subjectively reduce the weight related to direct trust while increasing the weight associated with recommended trust in order to have a more realistic assessment of the trust values of nodes. This feature however, is not demonstrated in this study.

Trust monitoring and  update Trust maintenance  database

Trust monitoring  system

Trust monitoring 

Topology creation

Deploy attack nodes

Compute direct 

Trust calculation

trust

Compute  recommended trust

Compute total trust

 Trust backup/recuperation Node battery  depleted?

Yes

Set timer for node  recovery

Yes

No

Detection and isolation  of malicious nodes

Node recovery  timer met?

Case decision for  malicious node  detection

Calculate node  trust value

Update trust  table Sybil

Rank

Filter malicious  node(s)

Trust rating process

Select non‐malicious  nodes as trusted  nodes

Case decision on  ranking of trusted  nodes for routing

Select nodes in order of  trust magnitude (case 1)

Use proximity to destination  for nodes of same trust  value (case 2)

Use FIFO for a tie of cases 1  and 2 or any other  conditions

Update trust table

Forward ranked trusted  nodes for routing decision

Figure 3. SecTrust system

and observation

Start

3.1.2 Trust Monitoring Update Process This process is an observatory and update phase where every node gathers the trust information of their immediate and distant neighbours based on (a) direct relationships and (b) the recommendations between the nodes. The Monitoring system also updates the trust values of nodes. In updating the trust values of a node, SecTrust employs two methods namely: periodic trust update and reactive trust update. 

The periodic trust update is based on a given time when trust values are re-computed to have an up-todate trust value. For this study, we have adopted the RPL protocol implementation of the trickle timer for sending DIO messages.



The reactive trust update method is intended for the spatially connected and distributed nodes that trigger route updates and are hence, reactive based on their sparse communication links. This method is useful when SecTrust system is implemented in distributed system for which the communication between nodes become sparse. An example could be in an online shopping system or a social network system.

The frequent update of the trust database can impact a routing protocol’s performance hence, to mitigate this, SecTrust assumes in this study RPL’s implementation of its routing table update as the basis for its trust update. A low frequent trust update rate will mean that some node actions will not be captured and as result, a low trust convergence rate will result in the network. Contrariwise, if the trust update rate becomes too frequent, it may take up excessive network resources like the energy, memory and CPU cycles of node and thus, culminate in a shortened network lifetime for the battery powered sensors nodes. 3.1.3 Trust Rating Process The SecTrust design proposes the concept of a threshold-based trust rating system. The idea is to use highquality trusted nodes for secure communications (routing decisions). After the trust values, have been determined, and for proper judgement, a trust rating system is further adopted in order to rank the highest to the lowest trust values obtained during the trust calculation process. This helps in delivering only highly rated (trusted) nodes for the purpose of secure communication. This further helps in detecting and eliminating misbehaving nodes, which seek to adjust their trust values maliciously (e.g. Rank, Wormhole and Grey hole attacks). To estimate the trust values, we develop a five-tuple trust level system and deduce its trust degree by using fuzzy judgment. A five tuple trust level is used for the trust evaluation of a node, and it is defined thus: V =[v1, v2, v3, v4, v5].This is expressive of the trust levels as: [“no trust”,”poor trust”,“fair trust”,”good trust”,“complete trust”] respectively and this is represented in Table 3. Table 3: A five-tuple trust level band

Five tuple (V) v1 v2 v3 v4 v5

Trust level No trust Poor trust Fair trust Good trust Complete trust

Range of positive relations (%) ≥ 0 and ≤ 25 ≥ 26 and ≤ 50 ≥ 51 and ≤ 75 ≥ 76 and ≤ 90 ≥ 91 and ≤ 100

SecTrust considers nodes in the v4 and v5 tuple as good nodes for secure communication while nodes in the v3 tuple could have some mixed-element behaviour. However, v3 is only used for secure communication in the absence of v4 and v5 node category. SecTrust does not rely on nodes in the v2, and v1 tuple. In general, SecTrust avoids as much as possible using nodes with classifications of v3, v2, and v1 for secure communications. 3.1.4 Detection and Isolation of Attacks Process The most important task of any secure information system is to guarantee the confidentiality, integrity, availability and authenticity of the information transmitted. This issue becomes challenging especially in IoT networks where the devices are constrained, number of devices are numerous, and because of the lossy nature of the wireless transmission. This study focuses on the detection and isolation of insider attacks that are rather more difficult to detect because the malicious nodes form part of the network and are privy to every detail of the network process. Specifically, this study focuses on Rank and Sybil attacks, which have been discussed in Section 2. SecTrust uses node overhearing (promiscuous mode) and monitoring methods to determine anomalous route traffic towards a node as possible indication of a rank attack or colluding attack. In addition, to detect and isolate a Sybil attack node, attaching a higher weight to the current trust value of a node rather than attributing more weight to its observable history will help defend against a Sybil node trying to subvert the network with fake identities, even if the node behaves initially well from the beginning. A Sybil node masquerading as a new node when evaluated by a trustor node will have a low trust value, since it has not built up any reputation and its packet forwarding behaviour cannot be determined.

The static topology of the network allows for the location information of all sensors to be predetermined, which communicated via the location mechanism in the network. Since every node is stationary, the location mechanism is used to determine the identity of every node during broadcast. Also, a masquerading node displaying multiple identities will similarly be evaluated as per the current identity. Finally, with no observable good packet forwarding behaviour, its trust value remains less than the threshold required for secure communications. Even when a node tries to build up its reputation by initially forwarding packets to their destination, as soon as the node begins to misbehave, it will be detected quite early since the evaluation of trust is periodic and time-based. 3.1.5

Trust Backup/Recuperation Process

It is possible that some nodes could become selfish due to some peculiar reasons including: depleted battery, collision and signal interferences, temporary network link loss and thus the trust system could list them as malicious and/or insecure even though they are trustworthy nodes. This could lead to the nodes having low trust values hence, their elimination from being considered for secure routing decisions or communications. The operation of SecTrust in isolating these nodes is quite expected, since these nodes will still behave selfishly in conserving their battery energy or becoming unreliable due to lossy links. The trust backup/recuperation process takes care of this, by observing the isolated nodes over a time period, so they could recoup their depleted resources. Once they meet the given conditions, they could boost their trust values over time and consequently, get integrated for secure routing/ communication considerations, else they will be considered insecure and their trust values will remain low. Situation arises when a new node or a node that has recouped from its energy depletion is introduced into the network. In either case, such a node is initially assigned a median trust value in the v3 tuple ((51+75)/2 = 63). A v4 and v5 trust tuple value is not assigned to a node in this category so that a Sybil attacker may not exploit this opportunity to change its identity in the network while retaining a trust value that permits it to be malicious. Hence, our affirmation in Section 3.1.3 that SecTrust avoids as much as possible using nodes in the v3, v2 and v1 tuple. The new or energized nodes are considered for secure communication only when their neighbours in the v4 and v5 tuple have become energy constrained, or are the next highest trusted nodes, or the only border nodes to other network segments. This obviously tasks the resources of trusted nodes in the network, but ensuring security is the preference of the SecTrust framework. 3.2 SecTrust-RPL: Embedding SecTrust in RPL Routing Protocol InstantContiki 3.0 is a simulation platform that implements the RPL routing protocol (ContikiRPL) as specified in RFC 6550 [10, 35]. It is implemented using two objective functions namely: Minimum Rank with Hysteresis Objective Function (MRHOF) and Objective Function zero (OF0). This research work specifies its own objective function in ContikiRPL using the SecTrust system discussed in Section 3.0. The integration of SecTrust system into RPL routing protocol creates a new trust-aware and secure RPL routing protocol. This new protocol we have termed SecTrust-RPL. SecTrust-RPL embeds the SecTrust system in Figure 3 into the ContikiRPL as its trust engine so that routing decisions, malicious node detection and isolation are purely based on the trust among nodes. All nodes in the SecTrust-RPL independently process the trust relationship between them, using the SecTrust process engine so they could make their decisions about routing their data through their neighbour nodes in the network. Although trust levels among nodes develop and evolve over time, in SecTrust-RPL, a greater weight is placed on the current value (time-based) of the trust of a node. This ensures that a malicious node, although consistent in its good behaviour in the past, but decides to become malicious will quickly be detected and isolated from the network. Figure 4 shows the algorithmic procedure implemented in SecTrust-RPL for the selection of trusted parents. It gives the computation of node trust values and a trust-based selection of parents. The algorithm in Figure 4 uses the ETXpath metric as provided for in the RFC6651 draft [36]. In addition, the algorithm ensures the rank order of nodes are maintained as specified in [10]. In the Algorithm 1 of Figure 4, the ETX_Limit shows the highest ETX value deemed as the best potential parent. The N1.DT is the minimum difference of the computed trust value (as given in the trust equation of Algorithm 1) for a node to initiate the optimal parent swap. The values discussed above present a configurable level of hysteresis in performing preferred parents change. Additionally, algorithm 1 recurrently searches for the node with the highest trust value node routing path throughout all routes having minimum ETX values. To ensure there no loops, a node does not consider its neighbours having greater rank as its optional parents. During RPL operation, a comparison is made between nodes based on the expected transmission count (ETX) and the rank of the nodes. These are normal RPL operations to determine preferred parents and routing decisions. However, during routing decisions, the rank and trust values of nodes are computed and sorted in descending order of trust magnitude while maintaining the rank ordering based on the RPL standard specified in [10]. In this way, the trust values become embedded for routing decisions during RPL routing while maintaining rank consistency among IoT nodes. This thus, achieves the combined values of providing optimal routing decision and the selection of only trusted nodes in the RPL network.

However, during trust computation and evaluation of a neighbour node, when a malicious parent is detected, the child node re-aligns itself with another parent from its potential parent list. In doing this however, the trust threshold (Table 3) is used for selection of a trusted parent while also maintaining the rank order as specified in RPL. Furthermore, Figures 5 and 6 give the algorithm for the detection and isolation of Rank and Sybil nodes respectively, while Figure 7 shows the SecTrust-RPL implementation with the SecTrust engine being at the core of node selection. It can be observed from Figure 7 that all computations and decisions flow through the trust engine. In the RPL implementation of SecTrust, recommendation was not used as part of the trust computation mechanism. This is because in a RPL network, a child-node only knows its parent, but is unaware of its grandparent. Furthermore, the non-utilization of the Recommendation attribute also helps in isolating Sybil-like attackers that may wish to exploit the Recommendation attribute of SecTrust’s system when implemented in RPL protocol. This way a Sybil operation under SecTrust-RPL becomes extremely difficult. In addition, node location was used in the detection of Sybil nodes since all nodes were stationary. Finally, the performance of SecTrust-RPL was compared with the standard RPL routing protocol. The standard RPL protocol was used for comparison based on the reasons below: i. ii.

This study has researched several secure RPL routing protocols and to the best of our knowledge, there is none, for all intents and purposes, that addresses simultaneously Rank and Sybil attacks in an IoT environment. From i) and Table 2 above, this study has considered few Trust-based secure RPL routing protocols for possible comparison, however, their application was either not appropriate for smart building or smart home environments, or these protocols did not address the attacks that this research study undertakes. In addition, some of the protocols considered were most appropriately applied in studies that considered mobility, disaster/emergency and agricultural scenarios, which this study does not cover.

Algorithm 1: Trust computation and trusted parent selection Let N1 ← one available item in the NeighbourList[ ] Let N2 ← another item next to N1 in the NeighbourList[ ] Compute ,





 

while node not in MaliciousClassList do If (N1.ETX<= ETX_Limit) & (N2.ETX<=ETX_Limit) If (N1.Rank <= Rank_Self) & (N2.Rank <= Rank_Self) Preferred_Parent = N1.DT(Ni,Nj) > N2.DT(Ni,Nj) ? N1:N2; else if (N1.Rank <= Self_Rank)||(N2.Rank <= Self_Rank) Preferred_Parent = N1.Rank < N2.Rank ? N1 : N2 else Preferred_Parent = NULL; end if else If (N1.ETX <= ETX_Limit) || (N2.ETX <= ETX_Limit) Preferred_Parent = N1.ETX <= N2.ETX ? N1 : N2; else Preferred_Parent = NULL; end if end while return Preferred_Parent End. //of program. Figure 4. Trusted parent computation and selection in SecTrust-RPL

Algorithm 2: Rank Attack Detection and Isolation Begin Input: NeighbourNodeList[1..n] Input: Potential_Parents offers[1..j] Input: Preferred_Parent // derived from Algorithm 1 Beta → 0.01 Inc → 0.005 From potential parents offer received [1..j] For i= 1,j begin //check for rank validity of potential parent offers against NeighbourNodeList[1..n] if (Potential_Parent(i).DIO_seq == NeighbourNodeList.DIO_seq if (Potential_Parent(i).rank == NeighbourNodeList.rank) return Preferred_Parent //Preferred parent is as in Algorithm 1 else // Rank attack node, do not use it begin chkbeta (Preferred_Parent, Beta, Inc) //increment penalty by 0.005 Insert node in MaliciousClassList[]; Preferred_Parent = NULL; //search for a new parent end; //of begin end if end if end; return Preferred_Parent End. //of Program Figure 5. Algorithm for the detection and isolation of Rank attacks

Algorithm 3: Sybil Detection and Isolation Begin //of Sybil Detection Input: Preferred_Parent // derived from Algorithm 1 Input: Potential_Parents offers received [1..j] Beta → 0.01 Inc → 0.005 For i= 1,j begin //check validity of potential parent against node’s database if (potentialparent(i).DT(trustvalue) >= Threshold_Trust_value begin If (Potential_Parent(i).ipaddress == NodeList[1..j].ipaddress && Potential_Parent(i).location(x,y) == NodeList[1.j].location(x,y)) //Retain preferred parent as selected in trust parent algorithm else //node is sybil, isolate it begin Preferred_Parent = NULL; chkbeta (Preferred_Parent, Beta, Inc) //increment penalty by 0.0 end end if end; //of begin end if end; //of begin return Preferred_Parent End. //of program Figure 6. Algorithm for the detection and isolation of Sybil attacks

Figure 7. RPL protocol operational flowchart with SecTrust engine used for secure routing and rank consistency maintenance

4. SIMULATION STUDY This study emulates a smart IoT sensor deployment and hence, we have designed and adapted a smart home topology. The topology has 30 sky motes (sensor nodes) deployed out of which 3 are attack motes. We assumed that at any point a maximum of 10% of the total nodes could serve as attacking nodes and hence, the use of 3 attacking sensor motes in the designed topology. This, in our opinion, emulates a typical smart home of today, in which a network of 20 to 30 nodes are common. In a typical smart home today, a network of 20 to 30 nodes are common although, according to predictions, this in the future could arguably increase to 250 nodes for any typical smart home [37]. Since we have a predefined location size, the sensor devices are evenly distributed throughout the building while maintaining the root or sink node at the centre of the home. Figure 8 shows topological view of the smart home with an even distribution of the sensor nodes while three attacker nodes are located outside the building. The sink node is shown as a square-shaped unit, the sender nodes as hexagonal units and the attacker nodes are equally represented as hexagonal units located outside the building. The attacker nodes are planted outside the perimeter of the smart home to illustrate a real case scenario where a hacker could plant these high-powered sensors in order to remotely gain access and infiltrate the internal network of the building. For this study, the Unit Disk Graph Medium (UDGM) with distance loss has been adopted as it provides a realworld emulation of the lossy links and shared media collision among wireless sensor nodes. Additionally, a comparison is made between the proposed SecTrust-RPL and the standard RPL protocol based on the Minimum Rank with Hysteresis Objective Function (MRHOF) implementation. This implementation of RPL (MRHOF) protocol is specifically chosen for comparison with our work since the MRHOF (RPL) has been shown to have better performance than the Objective Function zero (OF0) implementation of RPL (OF0-RPL) [38, 39]. A mote output log file is created to measure the details of all routing communication during simulation over a 60-minute simulation period. Table 4 presents the different simulation parameters used. An initial start delay of 5 seconds is allocated for the RPL network to converge, which is a sufficient convergence time for a RPL network having 10 to 100 nodes. Thus, packets analysed are packets after network convergence is achieved. The RPL operation mode was set to “No Downward” routes since in the smart home simulation the interest is on using multipoint to point traffic for the evaluation of our study (that is, sender nodes transmitting their packet to the sink node). Since these nodes are lossy by nature, the reception ratio (RX) was set at a variable range of 30% to 100%. This study assumes the transmission ratio (TX) for all nodes was set at 100%, which shows a loss-free transmission as we do not need to introduce losses at the radio transmission end, but only at the reception end. However, for the attacker nodes, their transmission and reception was set to 100%. This is the real coverage range of most sensor radios in the market today. Also, the interference range was set at 55m. The Link Failure model, models the packet transmission range as an ideal disk whereby all sensor nodes outside the disk range are not able to receive any packets whereas sensor nodes within the disk’s range receive packets. Interferences are treated as attenuating factors during transmission while interfered packets are regarded as lost packets when the interference distance becomes larger than the transmission distance. In addition, the success ratio of the receiver and transceiver can be defined before and during tests in Cooja. Therefore, the success of the transmission or reception of packets are predicated on the SUCCESS_RATIO_TX and SUCCESS_RATIO_RX probabilities in Cooja. Nevertheless, SUCCESS_RATIO_TX is deemed unsuccessful when all nodes do not receive a sent packet while SUCCESS_RATIO_RX is considered unsuccessful when a destination node does not receive a packet specifically sent to it. This study uses this model since it provides a real-world emulation of the lossy links and shared media collision among wireless sensor nodes. 4.1 Simulation Results The network shown in Figure 8, has 30 nodes and each node sends a 46-byte packet (30 bytes of data and 16 bytes of frame header detail) to the server (sink) after every 1 minute and this after an initial start delay of 5 seconds RPL convergence time. During RPL communication among nodes, sender nodes transmit packets to the sink node with the following stamp on each packet sent: time, source ID, packet type (sent or received), destination ID, sequence number and data size. 4.1.1 Rank Attack Implementation In the Rank attack implementation of the simulation, a malicious node maintains a good behaviour for about 5 to 10 seconds, after which it commences its attack by broadcasting spuriously low Rank values during every RPL trickle timer cycle. This portrays the malicious node as having a better route path which attracts its neighbours to it, thereby creating unoptimized route paths. The RPL protocol standard specifies that a Rank value increases in a downward fashion to prevent routing loops and unoptimized route paths. The unoptimized route paths causes RPL to invoke local and global repairs every so often. This greatly degrades the RPL network and exhausts the energy power of nodes. 4.1.2 Sybil Attack Implementation To provide a real-word simulation of Sybil attacks in a RPL network, a Sybil node maintains an initial good behaviour in the network for a set time of 5 to 10 seconds. The Sybil node broadcasts low, spurious Rank to attract

other nearby nodes to itself. The Sybil node further acquires the address details of the nodes (MAC and IP addresses). The Sybil node begins a periodic, but random modification of its identity by re-using identities found in the network, which are fake identities. This generates conflict on identities in the network, sparking local and global RPL repairs, which leads to network degradation, legitimate nodes not having access to network resources (resource starvation) and ultimately the exhaustion of network nodes. Packet sequence IDs are matched to ensure that packets sent are received by the sink node. A sent packet sequence ID that could not be matched to a corresponding received sequence ID by the sink node, is either not sent by the malicious node or affected by the lossy network link. We perhaps may have eliminated lossy network links because we made nodes to have strong reachability to their neighbours. Moreover, we examined the packets not forwarded by the malicious nodes and they corresponded to the packets that did not reach the sink node. A complete log of sent and received packets were analysed and the results are discussed in Section 4.2. In addition, multiple simulation runs were performed to confirm and verify results obtained under the given configuration settings.

Storage

Kitchen

Bed room 1 Dining area Living room

Toilet Bed room 3 Bathroom

Hall way

Bathroom

Bed room 2

Toilet

Legend

Controller sink node

Sender node

Malicious node

Figure 8. A topological representation of a smart home with 27 nodes in communication and 3 attacking nodes

Table 4: Network simulation settings and parameters Parameters Value Simulation tool Contiki/Cooja 3.0 Simulation coverage area 70m x 70m Total number of nodes 30 3 (Nodes 28, 29 and Malicious nodes 30) Malicious to legitimate node 1 : 10 ratio Node deployment environment Smart building RX Ratio 30-100% TX Ratio 100% TX Range 50m Interference Range 55m Routing Protocols RPL and SecTrust-RPL Network protocol IP based Start Delay 5 seconds Simulation Time 60 minutes Link failure model UDGM with distance

4.2 SecTrust-RPL vs MRHOF-RPL under Rank Attacks This section presents the simulation results of the comparison between MRHOF-RPL and SecTrust-RPL under Rank attacks. The Rank attack nodes (28, 29 and 30) were manually activated between 5 to 10 seconds during RPL operation.

4.2.1 Detection and Isolation of Attack Nodes From the result shown in Figure 9, it can be observed that SecTrust-RPL could successfully detect and isolate the Rank attacks during routing operations. In the first five minutes 103 attacks were detected. However, the attacks detected decrease progressively as the simulation progressed. This is clearly understandable since RPL, being a proactive routing protocol, inundates the network with control and route information before the network converges. This results in the transmission of more control and route packets, which the malicious nodes could take advantage of in order to perpetrate their malicious behaviour. In fact, the attacker nodes were programmed to take advantage of the proactive routing nature of RPL by performing an initial inundation of DIOs with spurious rank values. Conversely, MRHOF-RPL neither could detect nor isolate the Rank attacks as it does not have any mechanism to do so. In RPL routing, a node selects its preferred parent by examining potential parents with lower rank values than itself. This low-rank consistency is maintained among nodes to eliminate routing loop. Thus, a node rank change occurs when a child-node re-aligns itself to another preferred parent-node with a lower rank value. A Rank attacker exploits this feature in RPL by advertising itself with better rank value to its neighbours so as to attract and deceive these neighbouring nodes. The neighbouring nodes in turn, detach themselves from their parents and instead select the malicious node as their new preferred parent. This results in the creation of segmented RPL networks that are separated from the sink node. Figure 10 shows a comparison of the frequency of node rank changes between the MRHOF-RPL and SecTrust-RPL. MRHOF-RPL shows significantly higher vulnerability to node rank changes in comparison to SecTrust-RPL, depicting a vulnerability to Rank attacks. SecTrust-RPL, on the other hand, consistently maintained low node rank changes throughout the simulation period.

Figure 9. Rank attack detected by SecTrust-RPL during simulation

Figure 10. Simulation study comparison of frequency of node rank changes

   

4.2.2 Network performance Even though the SecTrust-RPL detects and isolates malicious nodes (Rank attacks) within the network, it becomes imperative that SecTrust-RPL should not impose undue overhead on the network performance. We present below a measurement of packet transmission delay and packet loss rate to examine how SecTrust-RPL performs against MRHOF-RPL in maintaining reasonable levels of network performances while isolating Rank attacks in the RPL network. Figure 11 compares the packet loss percentage between the two protocols during RPL routing operation under Rank attacks. While the packet loss rate of SecTrust-RPL protocol averaged between 22 – 23%, the range was quite high (60-100%) for MRHOF-RPL. This again is due to the network segmentation that has resulted into a higher packet loss in MRHOF-RPL. SecTrust-RPL thus, better provides promising defence against Rank attacks.

Figure 11. Packet loss rate comparison between MRHOF-RPL and SecTrust-RPL

4.3 SecTrust-RPL vs MRHOF-RPL under Sybil Attacks This section compares the performance of MRHOF-RPL and SecTrust-RPL under Sybil attacks. The Sybil attack nodes (28, 29 and 30) were manually activated between 5 to 10 seconds after RPL operation commenced. 4.3.1 Detection and Isolation of Attack Nodes From the result shown in figure 12, SecTrust-RPL could detect and isolate the Sybil attacks during routing operations. In the first 5 minutes of RPL operation, 338 attacks were detected while the attacks decreased progressively. Throughout the remaining simulation time detection of Sybil attacks was fairly at a constant range (94 – 145). When a Sybil attacker assumes the identity of another node in the network, since its trustworthiness is based on the location identification of nodes, and the real-time trust computation and not on past behaviour, the Sybil node falls short of what is needed for secure routing. Conversely, MRHOF-RPL could not be detect nor isolate any Sybil attacks since it indeed has no mechanism for performing this. Figure 13 shows a comparison of the frequency of node rank changes between the MRHOF-RPL and SecTrustRPL. MRHOF-RPL showed higher node rank changes over SecTrust-RPL especially node 24 which had frequency rank changes of up to 1,822; an indication of a high level of vulnerability to Sybil attacks. SecTrust-RPL consistently maintained low node rank changes throughout the simulation time of 60 minutes.

 

Figure 12. Detection and isolation of Sybil attacks in the RPL network

 

  Figure 13. Simulation study comparison of frequency of node rank changes

4.3.2 Network Performance In Figure 14, a comparison is presented of the packet loss rate of MRHOF-RPL and SecTrust-RPL under Sybil attacks. From the figure the packet loss rate of MRHOF-RPL is significantly higher than in SecTrust-RPL. While MRHOF-RPL maintained a steady rate of 60-100% packet loss rate, in SecTrust-RPL it ranged between 15 – 25%. Nodes 3, 8, 10, 11, 16, 17, 19, 23 and 25 had a loss rate of 100% in MRHOF-RPL. This is an indication of the susceptibility of MRHOF-RPL, which is due to the resource starvation of the Sybil attacks. On the other hand, SecTrust-RPL is better shielded against Sybil attacks as evident from the simulation results.

        Figure 14. Packet loss rate comparison between MRHOF-RPL and SecTrust-RPL

5.

TESTBED EXPERIMENT

In this section, we present a practical deployment of a small-scale smart home testbed of SecTrust-RPL using XM1000 motes to study its performance. Previous research has shown that although in a simulation environment most IoT-based smart home systems perform well and results obtained are reliable, this is often not true when such experiments are carried out in real-world scenarios [40]. A key motivation of this testbed experiment is to validate the simulation results obtained for SecTrust-RPL as presented in Section 4. For the testbed experiment, we have used the PhD Research Lab (in WT Building, Level 4) of Auckland University of Technology to represent a smart home environment. Figure 15 shows the smart home layout of the testbed in the lab with 14 XM1000 mote sensors deployed for the experiment, out of which, 11 were sender motes, 2 were malicious motes and the remaining is a sink mote connected to the desktop PC running the Contiki/Cooja emulation program. The sender and malicious motes were evenly distributed across the research lab.

Figure 15. A topology view of 14 XM1000 mote deployment consisting of 1 sink mote attached to a desktop PC, 11 sender nodes and 2 malicious motes

5.1 IoT Hardware and Software Platform The hardware of choice for this testbed study is the AS-XM1000 mote. The XM1000 is a new generation of mote module which is based on the “TelosB” platform [41], which is same as the Tmote SKY used in Contiki. The XM1000 mote (Figure 15) is based on the CC2420 single-chip radio with 2.4 GHz IEEE 802.15.4 compliant RF transceiver developed specifically for low-power wireless applications using low voltages. It supports open-source operating systems and applications such as TinyOS and Contiki, and it has been deployed in several academic and scientific studies [42, 43]. The design of the XM1000 is built on the standard IEEE 802.15.4 2.4-GHz transceiver. It also comes equipped with an enhanced 116Kb-EEPROM and 8Kb-RAM while being embedded with humidity, temperature and light sensors.

Figure 15. AS-XM1000 mote used for testbed experiment [44]

5.2 Testbed Setup In the testbed, three mote types namely, the UDP sink, the UDP sender and the attacking malicious motes, were deployed over a 30 m x 30 m (approximately) coverage area. All motes were stationary and could communicate with the UDP sink since all motes were under the coverage area of the UDP sink mote. In all, 1 sink mote, 11 sender motes and 2 attacker motes were deployed using the XM1000 motes. Table 5 summarizes the testbed parameters used.

Table 5: Network testbed settings and parameters Parameters Testbed platform Testbed coverage area Total number of XM1000 motes Malicious nodes Malicious to legitimate node ratio Mote deployment environment RX Ratio TX Ratio TX Range Interference Range Routing Protocols Network protocol Start Delay of Attack Nodes Testbed testing time

Value Contiki/Cooja 3.0 30m x 30m 14 2 (Nodes 13 and 14) 1 : 10 (approx.) Smart building 30-100% 100% 50m 55m MRHOF-RPL and SecTrust-RPL IP based 5 seconds 60 minutes over a 3-day period

Sink Mote Figure 16. (a) XM1000 sink mote connected to Contiki via a desktop PC and (b) An XM1000 mote deployed in the PhD Research lab communicating with the sink mote

5.2.1 Detection and Isolation of Attack Motes As mentioned earlier, the sink mote, which serves as the controller mote was connected to the USB interface of the Contiki desktop PC. The sink mote communicated with all the other motes deployed throughout the PhD Research Lab on level 4. Also, all data sent by the deployed motes were channelled through the controller mote (sink) into the Contiki platform where it was logged for analysis. Moreover, the Contiki Collect-View menu showed the routing communication topology of all the XM1000 motes between the source mote (sink) and the sender motes in the presence of malicious motes. Figures 16(a), 16(b) and 17 show the deployment of XM1000 motes communicating with the sink mote attached to a desktop PC.

Figure 17. XM1000 motes deployed in the PhD Research lab of the AUT WT building

5.3 SecTrust-RPL vs MRHOF-RPL under Rank Attacks The testbed experiment in Figure 18 shows the detection of Rank attacks over a 60-minute simulation time. The first five minutes had the highest detection rate of 63 malicious activity detections. The detection of attacks after the first 5 minutes maintained a rather steady pattern of 21 to 31 attack detections since there are fewer attacks being perpetrated by the malicious motes. However, MRHOF-RPL had no mechanism for detecting spurious rank advertisements made by malicious motes 13 and 14 during the experiment. This will further be proved with the mote rank changes of Figure 19 discussed next.

Figure 18. Rank attack detected by SecTrust-RPL during testbed experiment

Figure 19 shows the frequency of mote rank changes between MRHOF-RPL and SecTrust-RPL protocols during the experiment under the perpetrated Rank attacks of motes 13 and 14. MRHOF-RPL had higher mote rank changes, which ranged from 13 to 205. An indication that the network topology was under constant attack by malicious motes 13 and 14. However, SecTrust-RPL had much lower rank changes with zero rank changes on motes 5 and 8. The highest being 116 on mote 9, a value slightly higher than its corresponding equivalent under MRHOF-RPL where mote 9 had 99 mote rank changes. As a result of the lower frequency of mote rank changes, it is expected that the network stability and performance of SecTrust-RPL will be better over MRHOF-RPL. This is discussed in the next section.

Figure 19. Testbed Comparison of frequency of node rank changes

5.3.1 Network Performance Measures The packet loss rates in Figure 20 shows that SecTrust-RPL maintained a packet loss rate between 15% – 28% MRHOF-RPL had a packet loss rate of 60% – 73% during the RPL testbed experiment. It can be summarized from Figure 20 that the rank attack perpetrated by the malicious motes (13 and 14) had significant influence on MRHOFRPL network than on the SecTrust-RPL network.

  Figure 20. Packet loss rate comparison during the testbed experiment

5.4 SecTrust-RPL vs MRHOF-RPL under Sybil Attacks This section presents the experimental results of our testbed experiment between SecTrust-RPL and MRHOFRPL protocols under Sybil attacks using the deployed XM1000 motes. The network topology was captured and viewed using the sensor data collection menu of Contiki/Cooja during the testbed experiment. 5.4.1 Detection and Isolation of Attack Nodes Sybil attack nodes masquerade themselves thus creating an illusion of multiple identities within a network. The testbed experiment in Figure 21 shows the detection of Sybil attacks over a 60-minute simulation testing time with predominant Sybil activities within the first 25 minutes of experimentation. As anticipated, SecTrust-RPL could identify and isolate the malicious nodes from being considered during routing operations in most cases. The 30th to 60th minutes witnessed moderate Sybil attacks with SecTrust-RPL detecting these attacks. MRHOF-RPL however, could not detect nor defend against the masquerading malicious behaviour of the motes 13 and 14 all throughout the experimentation period.

Figure 21. Sybil attacks detection and isolation during the testbed experiment

Figure 22 shows the frequency of mote rank changes of MRHOF-RPL and SecTrust-RPL during the testbed experiment while under Sybil attacks from motes 13 and 14. MRHOF-RPL had higher mote rank changes which ranged between 21 and 151 while SecTrust-RPL had a range of 0 to 117 mote rank changes. In fact, in SecTrustRPL nodes 5, 10, 11 and 12 had no mote rank changes; an indication that SecTrust-RPL adequately detected and isolated the Sybil attacks and these motes where not compromised. Nonetheless, motes 6 and 8 under SecTrustRPL had significant amount of mote rank changes (117 and 114 respectively), an indication of the influence of Sybil activity against these motes. MRHOF-RPL however, experienced several Sybil attacks, which influenced the topology of its network and the frequent mote rank changes experienced by all the motes (see Figure 22).

Figure 22. Testbed Comparison of frequency of node rank changes

5.4.2 Network Performance Measures In the packet loss rates measured between MRHOF-RPL and SecTrust-RPL protocols, Figure 23 shows that the packet loss rate experienced by MRHOF-RPL exceeded that experienced by the SecTrust-RPL. MRHOF-RPL experienced packet loss rates as high as 73% on mote 11 while the maximum experienced by SecTrust-RPL was less than 28% on mote 11. Given the packet loss rate experienced by MRHOF-RPL protocol, it is clear the Sybil attacks perpetrated by malicious motes 13 and 14 had significant impact on the operational influence on MRHOFRPL protocol’s network, thereby affecting its security and network performance over and above SecTrust-RPL protocol’s network.

Figure 23. Packet loss rate comparison during the testbed experiment

6.

CONCLUSIONS

SecTrust-RPL is a RPL protocol based on the SecTrust system that uses trust for the evaluation of nodes to make optimal routing decisions while isolating malicious nodes in the network. It computes its trust by examining the successful packet exchange between nodes in order to determine their reliability to forward packets to other nodes within the RPL network. It has a malicious node detection and isolation procedure that detects and isolates suspicious nodes while optimizing throughput performance. A simulation study was carried out to show the efficacy of the SecTrust system by embedding it into the RPL protocol (SecTrust-RPL) and presenting simulation results to show its efficacy in defending against Rank and Sybil attacks. Furthermore, the paper reported on a set of testbed experiments of the performance of the SecTrust system embedded with the RPL protocol while comparing its performance against a standard implemented version in ContikiRPL. Testbed experiments were undertaken as a validation procedure of the simulation study carried out. The experimental data analysed shows SecTrust-RPL having superior defence characteristics against Rank and Sybil attacks in comparison to the standard RPL routing protocol. The inner working of SecTrust-RPL specifies that when a node with a depleted battery power decides to behave selfishly, it is not considered for secure routing communications. The node is placed under the “Trust Backup/Recuperation Routine”, and it is observed for recuperation for a possible integration into the network system. However, since the trust evaluation of a node is a time-based evaluation procedure, this node although a trusted node will have to earn its trust all over again at an opportuned time.

In our future work, we wish to extend the SecTrust-RPL to improve the integration of trusted nodes into the network that have recouped their battery power. In addition, SecTrust-RPL will be extended to address other colluding attacks like Rank/Blackhole, Rank/Sybil, Rank/Selective Forwarding attacks. Finally, the investigation and deployment of pre-trusted nodes and the maintenance of a record of battery depleted pre-trusted nodes that can be re-integrated into the network with their trust values after they have recovered their battery power. These pretrusted nodes will be administratively assigned for a balanced secure communication in the network. REFERENCES [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32]

T. Watteyne, A. Molinaro, M. G. Richichi, and M. Dohler, "From MANET To IETF ROLL Standardization: A Paradigm Shift in WSN Routing Protocols," Communications Surveys & Tutorials, IEEE, vol. 13, pp. 688-707, 2011. M. Ilyas, The handbook of ad hoc wireless networks. Boca Raton: CRC Press, 2003. D. Airehrour, J. Gutierrez, and S. K. Ray, "Secure routing for internet of things," J. Netw. Comput. Appl., vol. 66, pp. 198-213, 2016. D. Miorandi, S. Sicari, F. De Pellegrini, and I. Chlamtac, "Internet of things: Vision, applications and research challenges," Ad Hoc Networks, vol. 10, pp. 1497-1516, 2012. T. K. L. Hui, R. S. Sherratt, and D. D. Sánchez, "Major requirements for building Smart Homes in Smart Cities based on Internet of Things technologies," Future Generation Computer Systems, 2017. K. Machado, D. Rosário, E. Cerqueira, A. A. F. Loureiro, A. Neto, and J. N. d. Souza, "A routing protocol based on energy and link quality for Internet of Things applications," Sensors (Basel, Switzerland), vol. 13, pp. 1942-1964, 2013. D. Giusto, The Internet of things: 20th Tyrrhenian workshop on digital communications. New York: Springer, 2010. J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami, "Internet of Things (IoT): A vision, architectural elements, and future directions," Future Generation Computer Systems, vol. 29, pp. 1645-1660, 2013. D. Airehrour, J. Gutierrez, and S. K. Ray, "A Lightweight Trust Design for IoT Routing," in 2016 IEEE 14th Intl Conf on Pervasive Intelligence and Computing, 2016, pp. 552-557. T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, J. Vasseur, and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks," Internet Engineering Task Force (IETF) 2012. L. Wallgren, S. Raza, and T. Voigt, "Routing Attacks and Countermeasures in the RPL-Based Internet of Things," International Journal of Distributed Sensor Networks, vol. 2013, p. 11, 2013. T. Tsao, R. Alexander, M. Dohler, V. Daza, A. Lozano, and M. Richardson, "A Security Threat Analysis for the Routing Protocol for Low-power and lossy networks (RPLs)," Internet Engineering Task Force (IETF)2015. A. Mayzaud, A. Sehgal, R. Badonnel, I. Chrisment, and J. Schönwälder, "A Study of RPL DODAG Version Attacks," in Monitoring and Securing Virtualized Networks and Services. vol. 8508, A. Sperotto, G. Doyen, S. Latré, M. Charalambides, and B. Stiller, Eds., ed: Springer Berlin Heidelberg, 2014, pp. 92-104. D. B. Parker, "Restating the foundation of information security," Computer Audit Update, vol. 1991, pp. 2-15, 1991. L. Anhtuan, J. Loo, A. Lasebae, A. Vinel, C. Yue, and M. Chai, "The Impact of Rank Attack on Network Topology of Routing Protocol for Low-Power and Lossy Networks," Sensors Journal, IEEE, vol. 13, pp. 3685-3692, 2013. A. Dvir, T. Holczer, and L. Buttyan, "VeRA-version number and rank authentication in rpl," in Mobile Adhoc and Sensor Systems (MASS), 2011 IEEE 8th International Conference on, 2011, pp. 709-714. M. A. Jan, P. Nanda, X. He, and R. P. Liu, "A Sybil attack detection scheme for a forest wildfire monitoring application," Future Generation Computer Systems, 2017. G. Glissa, A. Rachedi, and A. Meddeb, "A Secure Routing Protocol Based on RPL for Internet of Things," in 2016 IEEE Global Communications Conference (GLOBECOM), 2016, pp. 1-7. N. Djedjig, D. Tandjaoui, F. Medjek, and I. Romdhani, "New trust metric for the RPL routing protocol," in 2017 8th International Conference on Information and Communication Systems (ICICS), 2017, pp. 328-335. T. Matsunaga, K. Toyoda, and I. Sasase, "Low false alarm rate RPL network monitoring system by considering timing inconstancy between the rank measurements," in 2014 11th International Symposium on Wireless Communications Systems (ISWCS), 2014, pp. 427-431. C. Taylor and T. Johnson, "Strong authentication countermeasures using dynamic keying for sinkhole and distance spoofing attacks in smart grid networks," in 2015 IEEE Wireless Communications and Networking Conference (WCNC), 2015, pp. 1835-1840. M. Surendar and A. Umamakeswari, "InDReS: An Intrusion Detection and response system for Internet of Things with 6LoWPAN," in 2016 International Conference on Wireless Communications, Signal Processing and Networking (WiSPNET), 2016, pp. 1903-1908. A. Le, J. Loo, K. K. Chai, and M. Aiash, "A specification-based IDS for detecting attacks on RPL-based network topology," Information, vol. 7, p. 25, 2016. P. Pongle and G. Chavan, "Real time intrusion and wormhole attack detection in internet of things," International Journal of Computer Applications, vol. 121, 2015. Z. Yan, P. Zhang, and A. V. Vasilakos, "A survey on trust management for Internet of Things," Journal of Network and Computer Applications, vol. 42, pp. 120-134, 2014. F. Ishmanov, A. S. Malik, S. W. Kim, and B. Begalov, "Trust management system in wireless sensor networks: design considerations and research challenges," Transactions on Emerging Telecommunications Technologies, vol. 26, pp. 107-130, 2015. R. A. Shaikh, H. Jameel, B. J. d'Auriol, H. Lee, S. Lee, and Y.-J. Song, "Group-based trust management scheme for clustered wireless sensor networks," IEEE transactions on parallel and distributed systems, vol. 20, pp. 1698-1712, 2009. N. Djedjig, D. Tandjaoui, and F. Medjek, "Trust-based RPL for the Internet of Things," in 2015 IEEE Symposium on Computers and Communication (ISCC), 2015, pp. 962-967. S. Seeber, A. Sehgal, B. Stelte, G. D. Rodosek, and J. Schönwälder, "Towards a trust computing architecture for RPL in Cyber Physical Systems," in Proceedings of the 9th International Conference on Network and Service Management (CNSM 2013), 2013, pp. 134-137. A. Le, J. Loo, Y. Luo, and A. Lasebae, "Specification-based IDS for securing RPL from topology attacks," in 2011 IFIP Wireless Days (WD), 2011, pp. 1-3. S. O. Guclu, T. Ozcelebi, and J. J. Lukkien, "Trust-Based Neighbor Unreachability Detection for RPL," in 2016 25th International Conference on Computer Communication and Networks (ICCCN), 2016, pp. 1-6. K. Iuchi, T. Matsunaga, K. Toyoda, and I. Sasase, "Secure parent node selection scheme in route construction to exclude attacking nodes from RPL network," in 2015 21st Asia-Pacific Conference on Communications (APCC), 2015, pp. 299-303.

[33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44]

C. Dai and W. Gong, "Model of Services Trust Threshold Assess Based on Fuzzy Theory," in 2010 2nd International Conference on E-business and Information System Security, 2010, pp. 1-4. J. Luo, X. Liu, and M. Fan, "A trust model based on fuzzy recommendation for mobile ad-hoc networks," Computer Networks, vol. 53, pp. 2396-2407, 2009. Thingsquare. (2016, June, 2016). Contiki: The Open Source OS for the Internet of Things, . Available: http://www.contikios.org/download.html Internet Engineering Task Force (IETF), "Routing Metrics Used for Path Calculation in Low-Power and Lossy Network," vol. RFC 6551 ed: Internet Engineering Task Force (IETF), 2012. A. Dunkels, B. Gronvall, and T. Voigt, "Contiki - A Lightweight and Flexible Operating System for Tiny Networked Sensors," presented at the Proceedings of the 29th Annual IEEE International Conference on Local Computer Networks, 2004. H. Altwassi, M. Qasem, M. B. Yassein, and A. Al-Dubai, "Performance evaluation of RPL objective functions," in IEEE Conference on Pervasive Intelligence and Computing (CIT/IUCC/DASC/PICOM), Liverpool, UK 2015. Q. Q. Abuein, M. B. Yassein, M. Q. Shatnawi, L. Bani-Yaseen, O. Al-Omari, M. Mehdawi, and H. Altawssi, "Performance Evaluation of Routing Protocol (RPL) for Internet of Things," International Journal of Advanced Computer Science and Applications, vol. 7, 2016. H. Ghayvat, S. Mukhopadhyay, X. Gui, and N. Suryadevara, "WSN-and IOT-Based Smart Homes and Their Extension to Smart Buildings," Sensors, vol. 15, pp. 10350-10379, 2015. Willow Technologies Ltd., "TELOSB Mote Platform," ed, 2017. A. Reinhardt and D. Burgstahler, "Exploiting platform heterogeneity in wireless sensor networks by shifting resource-intensive tasks to dedicated processing nodes," in World of Wireless, Mobile and Multimedia Networks (WoWMoM), 2013 IEEE 14th International Symposium and Workshops on a, 2013, pp. 1-9. S. Jarupadung, "Event processing in wireless sensor networks. ," Masters, University of Surrey, 2015. Advanticsys, "XM1000," in XM1000 Mote, ed, 2016.

Authors Bios      David Airehrour is a PhD student at the Auckland University of Technology, Auckland, New Zealand.  He  received  his  BSc  and  MSc  degree  in  Computer  Science  from  the  University  of  Benin  and  the  Bayero  University,  Nigeria  respectively.  His  current  research  focuses  on  secure  trust‐based  routing  for  Internet  of  Things,  Attacks  mitigation  in  sensor  networks  and  trusted  routing  for  sensor  networks. His other research interests include mobile computing, network security, wireless sensor  networks, information processing and trust management.       Jairo A. Gutiérrez is Deputy Head of the School of Engineering, Computer and Mathematical Sciences  at  Auckland  University  of  Technology  in  New  Zealand.    He  received  a  Systems  and  Computing  Engineering  degree  from  Universidad  de  Los  Andes  in  Colombia,  a  Master’s  degree  in  Computer  Science  from  Texas  A&M  University,  and  a  Ph.D.  in  Information  Systems  from  the  University  of  Auckland.  His  current  research  is  on  network  management  systems,  networking  security,  viable  business models for IT‐enabled enterprises, next‐generation networks and cloud computing systems.      Sayan  Kumar  Ray  received  the  Bachelor  of  Computer  Science  and  Engineering  from  Gulbarga  University, India, Master of Technology in Computer Science and Engineering from the University of  Calcutta, India, and Ph.D. in Computer Science from the University of Canterbury, New Zealand. He  was  a  Design  Engineer  with  Tait  Communications,  New  Zealand,  where  he  was  involved  in  researching  on  the  LTE  and  3GPP  Evolved  Packet  Core  network.  He  is  currently  the  Leader  of  Programme  Development  in  Information  Technology  and  a  Senior  Lecturer  with  the  Faculty  of  Business  and  Information  Technology  at  Manukau  Institute  of  Technology,  New  Zealand.  His  research  interests  are  in  5G  networks,  LTE‐Advanced/LTE‐Unlicensed,  spectrum  sharing,  mobility  and handover, disaster management networks, and Internet of Things.                                             

     

  David Aiirehrour   

  Gutiérrez  Jairo A. G  

  Sayan Ku umar Ray 

Title: SecTrust-RPL: A Secure Trust-Aware RPL Routing Protocol for Internet of Things Highlights 

A  Trust‐aware  RPL  routing  protocol  for  IoT,  which  detects  and  isolates  Rank  and  Sybil  attacks while providing good network performance. 



The design of proposed secure trust system (SecTrust).  



Trust system embedded in RPL routing protocol (SecTrust‐RPL).  



Simulation study presented to compare performance of SecTrust‐RPL and RPL protocols. 



Testbed experiments presented to validate simulation study.